draft-ietf-mpls-tp-framework-08.txt   draft-ietf-mpls-tp-framework-09.txt 
MPLS Working Group M. Bocci, Ed. MPLS Working Group M. Bocci, Ed.
Internet-Draft Alcatel-Lucent Internet-Draft Alcatel-Lucent
Intended status: Informational S. Bryant, Ed. Intended status: Informational S. Bryant, Ed.
Expires: July 26, 2010 D. Frost Expires: August 1, 2010 D. Frost
Cisco Systems Cisco Systems
L. Levrau L. Levrau
Alcatel-Lucent Alcatel-Lucent
L. Berger L. Berger
LabN LabN
January 22, 2010 January 28, 2010
A Framework for MPLS in Transport Networks A Framework for MPLS in Transport Networks
draft-ietf-mpls-tp-framework-08 draft-ietf-mpls-tp-framework-09
Abstract Abstract
This document specifies an architectural framework for the This document specifies an architectural framework for the
application of Multiprotocol Label Switching (MPLS) to the application of Multiprotocol Label Switching (MPLS) to the
construction of packet-switched equivalents of traditional circuit- construction of packet-switched transport networks. It describes a
switched carrier networks. It describes a common set of protocol common set of protocol functions - the MPLS Transport Profile
functions - the MPLS Transport Profile (MPLS-TP) - that supports the (MPLS-TP) - that supports the operational models and capabilities
operational models and capabilities typical of such networks, typical of such networks, including signalled or explicitly
including signaled or explicitly provisioned bi-directional provisioned bi-directional connection-oriented paths, protection and
connection-oriented paths, protection and restoration mechanisms, restoration mechanisms, comprehensive Operations, Administration and
comprehensive Operations, Administration and Maintenance (OAM) Maintenance (OAM) functions, and network operation in the absence of
functions, and network operation in the absence of a dynamic control a dynamic control plane or IP forwarding support. Some of these
plane or IP forwarding support. Some of these functions are defined functions are defined in existing MPLS specifications, while others
in existing MPLS specifications, while others require extensions to require extensions to existing specifications to meet the
existing specifications to meet the requirements of the MPLS-TP. requirements of the MPLS-TP.
This document defines the subset of the MPLS-TP applicable in general This document defines the subset of the MPLS-TP applicable in general
and to point-to-point paths. The remaining subset, applicable and to point-to-point paths. The remaining subset, applicable
specifically to point-to-multipoint paths, are out of scope of this specifically to point-to-multipoint paths, are out of scope of this
document. document.
This document is a product of a joint Internet Engineering Task Force This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunications Union Telecommunications (IETF) / International Telecommunications Union Telecommunications
Standardization Sector (ITU-T) effort to include an MPLS Transport Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and PWE3 architectures to support the Profile within the IETF MPLS and PWE3 architectures to support the
skipping to change at page 2, line 21 skipping to change at page 2, line 21
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 26, 2010. This Internet-Draft will expire on August 1, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 18 skipping to change at page 2, line 51
1.1. Motivation and Background . . . . . . . . . . . . . . . . 4 1.1. Motivation and Background . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1. Transport Network . . . . . . . . . . . . . . . . . . 6 1.3.1. Transport Network . . . . . . . . . . . . . . . . . . 6
1.3.2. MPLS Transport Profile . . . . . . . . . . . . . . . . 7 1.3.2. MPLS Transport Profile . . . . . . . . . . . . . . . . 7
1.3.3. MPLS-TP Section . . . . . . . . . . . . . . . . . . . 7 1.3.3. MPLS-TP Section . . . . . . . . . . . . . . . . . . . 7
1.3.4. MPLS-TP Label Switched Path . . . . . . . . . . . . . 7 1.3.4. MPLS-TP Label Switched Path . . . . . . . . . . . . . 7
1.3.5. MPLS-TP Label Switching Router (LSR) and Label 1.3.5. MPLS-TP Label Switching Router (LSR) and Label
Edge Router (LER) . . . . . . . . . . . . . . . . . . 7 Edge Router (LER) . . . . . . . . . . . . . . . . . . 7
1.3.6. Customer Edge (CE) . . . . . . . . . . . . . . . . . . 8 1.3.6. Customer Edge (CE) . . . . . . . . . . . . . . . . . . 8
1.3.7. Additional Definitions and Terminology . . . . . . . . 8 1.3.7. Edge-to-Edge LSP . . . . . . . . . . . . . . . . . . . 8
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 1.3.8. Service LSP . . . . . . . . . . . . . . . . . . . . . 8
1.3.9. Layer Network . . . . . . . . . . . . . . . . . . . . 8
1.3.10. Additional Definitions and Terminology . . . . . . . . 8
1.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 9
2. MPLS Transport Profile Requirements . . . . . . . . . . . . . 11 2. MPLS Transport Profile Requirements . . . . . . . . . . . . . 11
3. MPLS Transport Profile Overview . . . . . . . . . . . . . . . 12 3. MPLS Transport Profile Overview . . . . . . . . . . . . . . . 12
3.1. Packet Transport Services . . . . . . . . . . . . . . . . 12 3.1. Packet Transport Services . . . . . . . . . . . . . . . . 12
3.2. Scope of the MPLS Transport Profile . . . . . . . . . . . 13 3.2. Scope of the MPLS Transport Profile . . . . . . . . . . . 13
3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. MPLS-TP Client Adaptation Functions . . . . . . . . . 14 3.3.1. MPLS-TP Client Adaptation Functions . . . . . . . . . 14
3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 15 3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 15
3.4. MPLS-TP Native Services . . . . . . . . . . . . . . . . . 16 3.4. MPLS-TP Native Services . . . . . . . . . . . . . . . . . 16
3.4.1. MPLS-TP Client/Server Relationship . . . . . . . . . . 17 3.4.1. MPLS-TP Client/Server Relationship . . . . . . . . . . 17
3.4.2. Pseudowire Adaptation . . . . . . . . . . . . . . . . 18 3.4.2. Pseudowire Adaptation . . . . . . . . . . . . . . . . 18
3.4.3. Network Layer Adaptation . . . . . . . . . . . . . . . 21 3.4.3. Network Layer Adaptation . . . . . . . . . . . . . . . 21
3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 25 3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 25
3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 25 3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 25
3.7. Operations, Administration and Maintenance (OAM) . . . . . 28 3.7. Operations, Administration and Maintenance (OAM) . . . . . 28
3.7.1. OAM Architecture . . . . . . . . . . . . . . . . . . . 29 3.8. LSP Return Path . . . . . . . . . . . . . . . . . . . . . 30
3.7.2. OAM Functions . . . . . . . . . . . . . . . . . . . . 32 3.8.1. Return Path Types . . . . . . . . . . . . . . . . . . 31
3.8. Control Plane . . . . . . . . . . . . . . . . . . . . . . 33 3.8.2. Point-to-Point Unidirectional LSPs . . . . . . . . . . 31
3.8.1. PW Control Plane . . . . . . . . . . . . . . . . . . . 35 3.8.3. Point-to-Point Associated Bidirectional LSPs . . . . . 32
3.8.2. LSP Control Plane . . . . . . . . . . . . . . . . . . 35 3.8.4. Point-to-Point Co-Routed Bidirectional LSPs . . . . . 32
3.9. Static Operation of LSPs and PWs . . . . . . . . . . . . . 36 3.9. Control Plane . . . . . . . . . . . . . . . . . . . . . . 32
3.10. Survivability . . . . . . . . . . . . . . . . . . . . . . 36 3.10. Inter-domain Connectivity . . . . . . . . . . . . . . . . 34
3.11. Path Segment Tunnels . . . . . . . . . . . . . . . . . . . 38 3.11. Static Operation of LSPs and PWs . . . . . . . . . . . . . 35
3.11.1. Provisioning of PST . . . . . . . . . . . . . . . . . 39 3.12. Survivability . . . . . . . . . . . . . . . . . . . . . . 35
3.12. Network Management . . . . . . . . . . . . . . . . . . . . 39 3.13. Path Segment Tunnels . . . . . . . . . . . . . . . . . . . 36
4. Security Considerations . . . . . . . . . . . . . . . . . . . 40 3.13.1. Provisioning of PST . . . . . . . . . . . . . . . . . 37
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 3.14. Pseudowire Segment Tunnels . . . . . . . . . . . . . . . . 38
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 3.15. Network Management . . . . . . . . . . . . . . . . . . . . 38
7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 42 4. Security Considerations . . . . . . . . . . . . . . . . . . . 39
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
8.1. Normative References . . . . . . . . . . . . . . . . . . . 42 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
8.2. Informative References . . . . . . . . . . . . . . . . . . 45 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 40
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
8.1. Normative References . . . . . . . . . . . . . . . . . . . 40
8.2. Informative References . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
1.1. Motivation and Background 1.1. Motivation and Background
This document describes an architectural framework for the This document describes an architectural framework for the
application of MPLS to the construction of packet-switched transport application of MPLS to the construction of packet-switched transport
networks. It specifies the common set of protocol functions that networks. It specifies the common set of protocol functions that
meet the requirements in [RFC5654], and that together constitute the meet the requirements in [RFC5654], and that together constitute the
MPLS Transport Profile (MPLS-TP) for point-to-point paths. The MPLS Transport Profile (MPLS-TP) for point-to-point paths. The
skipping to change at page 6, line 23 skipping to change at page 6, line 23
OTN Optical Transport Network OTN Optical Transport Network
cl-ps Connectionless - Packet Switched cl-ps Connectionless - Packet Switched
co-cs Connection Oriented - Circuit Switched co-cs Connection Oriented - Circuit Switched
co-ps Connection Oriented - Packet Switched co-ps Connection Oriented - Packet Switched
OAM Operations, Administration and Maintenance OAM Operations, Administration and Maintenance
G-ACh Generic Associated Channel G-ACh Generic Associated Channel
GAL Generic Alert Label GAL Generic Alert Label
MEP Maintenance End Point MEP Maintenance End Point
MIP Maintenance Intermediate Point MIP Maintenance Intermediate Point
APS Automatic Protection Switching APS Automatic Protection Switching
SCC Signaling Communication Channel SCC Signalling Communication Channel
MCC Management Communication Channel MCC Management Communication Channel
EMF Equipment Management Function EMF Equipment Management Function
FM Fault Management FM Fault Management
CM Configuration Management CM Configuration Management
PM Performance Management PM Performance Management
LSR Label Switching Router LSR Label Switching Router
MPLS-TP PE MPLS-TP Provider Edge LSR MPLS-TP PE MPLS-TP Provider Edge LSR
MPLS-TP P MPLS-TP Provider LSR MPLS-TP P MPLS-TP Provider LSR
PW Pseudowire PW Pseudowire
Adaptation The mapping of client information into a format suitable Adaptation The mapping of client information into a format suitable
skipping to change at page 7, line 45 skipping to change at page 7, line 45
5. Is either point-to-point or point-to-multipoint. Multipoint to 5. Is either point-to-point or point-to-multipoint. Multipoint to
point and multipoint to multipoint LSPs are not permitted. point and multipoint to multipoint LSPs are not permitted.
Note that an MPLS LSP is defined to include any present and future Note that an MPLS LSP is defined to include any present and future
MPLS capability, including those specifically added to support the MPLS capability, including those specifically added to support the
transport network requirements. transport network requirements.
1.3.5. MPLS-TP Label Switching Router (LSR) and Label Edge Router (LER) 1.3.5. MPLS-TP Label Switching Router (LSR) and Label Edge Router (LER)
Editor's Note: These terms are here for clarity - but this is not the
authoritative definition - (need to find a definition)
An MPLS-TP Label Switching Router (LSR) is either an MPLS-TP Provider An MPLS-TP Label Switching Router (LSR) is either an MPLS-TP Provider
Edge (PE) router or an MPLS-TP Provider (P) router for a given LSP, Edge (PE) router or an MPLS-TP Provider (P) router for a given LSP,
as defined below. The terms MPLS-TP PE router and MPLS-TP P router as defined below. The terms MPLS-TP PE router and MPLS-TP P router
describe logical functions; a specific node may undertake only one of describe logical functions; a specific node may undertake only one of
these roles on a given LSP. these roles on a given LSP.
Note that the use of the term "router" in this context is historic Note that the use of the term "router" in this context is historic
and neither requires nor precludes the ability to perform IP and neither requires nor precludes the ability to perform IP
forwarding. forwarding.
1.3.5.1. MPLS-TP Provider Edge (PE) Router 1.3.5.1. MPLS-TP Provider Edge (PE) Router
An MPLS-TP Provider Edge (PE) router is an MPLS-TP LSR that adapts An MPLS-TP Provider Edge (PE) router is an MPLS-TP LSR that adapts
client traffic and encapsulates it to be transported over an MPLS-TP client traffic and encapsulates it to be transported over an MPLS-TP
LSP. Encapsulation may be as simple as pushing a label, or it may LSP. Encapsulation may be as simple as pushing a label, or it may
require the use of a pseudowire. An MPLS-TP PE exists at the require the use of a pseudowire. An MPLS-TP PE exists at the
interface between a pair of layer networks. For an MS-PW, an MPLS-TP interface between a pair of layer networks. For an MS-PW, an MPLS-TP
PE may be either an S-PE or a T-PE, as defined in [RFC5659]. PE may be either an S-PE or a T-PE, as defined in [RFC5659].
A layer network is defined in [G.805].
1.3.5.2. MPLS-TP Provider (P) Router 1.3.5.2. MPLS-TP Provider (P) Router
An MPLS-TP Provider router is an MPLS-TP LSR that does not provide An MPLS-TP Provider router is an MPLS-TP LSR that does not provide
MPLS-TP PE functionality for a given LSP. An MPLS-TP P router MPLS-TP PE functionality for a given LSP. An MPLS-TP P router
switches LSPs which carry client traffic, but does not adapt client switches LSPs which carry client traffic, but does not adapt client
traffic and encapsulate it to be carried over an MPLS-TP LSP. traffic and encapsulate it to be carried over an MPLS-TP LSP.
1.3.5.3. Label Edge Router (LER)
An LSR that exists at the endpoints of an LSP and therefore pushes or
pops a label, i.e. does not perform a label swap on the particular
LSP under consideration.
1.3.6. Customer Edge (CE) 1.3.6. Customer Edge (CE)
A Customer Edge (CE) is the client function sourcing or sinking A Customer Edge (CE) is the client function sourcing or sinking
native service traffic to or from the MPLS-TP network. CEs on either native service traffic to or from the MPLS-TP network. CEs on either
side of the MPLS-TP network are peers and view the MPLS-TP network as side of the MPLS-TP network are peers and view the MPLS-TP network as
a single point-to-point or point-to-multipoint link. a single point-to-point or point-to-multipoint link.
1.3.7. Additional Definitions and Terminology 1.3.7. Edge-to-Edge LSP
An Edge-to-Edge LSP is an LSP between a pair of PEs that may transit
zero of more provider LSRs.
1.3.8. Service LSP
A service LSP is an LSP that caries a single client service.
1.3.9. Layer Network
A layer network is defined in [G.805] and described in [RFC5654].
1.3.10. Additional Definitions and Terminology
Detailed definitions and additional terminology may be found in Detailed definitions and additional terminology may be found in
[RFC5654]. [RFC5654].
1.4. Applicability 1.4. Applicability
MPLS-TP can be used to construct packet transport networks and is MPLS-TP can be used to construct packet transport networks and is
therefore applicable in any packet transport network context. It is therefore applicable in any packet transport network context. It is
also applicable to subsets of a packet network where the transport also applicable to subsets of a packet network where the transport
network operational model is deemed attractive. The following are network operational model is deemed attractive. The following are
skipping to change at page 9, line 14 skipping to change at page 9, line 27
2. MPLS-TP provided by a network that also supports non-MPLS-TP LSPs 2. MPLS-TP provided by a network that also supports non-MPLS-TP LSPs
and PWs (i.e. both LSPs and PWs that conform to the transport and PWs (i.e. both LSPs and PWs that conform to the transport
profile and those that do not, exist between the PEs), acting as profile and those that do not, exist between the PEs), acting as
a server for other layer 1, layer 2 and layer 3 networks a server for other layer 1, layer 2 and layer 3 networks
(Figure 2). (Figure 2).
3. MPLS-TP as a server layer for client layer traffic of IP or MPLS 3. MPLS-TP as a server layer for client layer traffic of IP or MPLS
networks which do not use functions of the MPLS transport networks which do not use functions of the MPLS transport
profile. For MPLS traffic, the MPLS-TP server layer network uses profile. For MPLS traffic, the MPLS-TP server layer network uses
PW switching or LSP stitching at the PE that terminates the PW switching [RFC5659] or LSP stitching [RFC5150] at the PE that
MPLS-TP server layer (Figure 3). - See notes in word document - terminates the MPLS-TP server layer (Figure 3).
ref = rfc5150
These models are not mutually exclusive. These models are not mutually exclusive.
MPLS-TP LSP, provided by a network that only supports MPLS-TP, acting as MPLS-TP LSP, provided by a network that only supports MPLS-TP, acting as
a server for other layer 1, layer 2 and layer 3 networks. a server for other layer 1, layer 2 and layer 3 networks.
|<-- L1/2/3 -->|<-- MPLS-TP-->|<-- L1/2/3 -->| |<-- L1/2/3 -->|<-- MPLS-TP-->|<-- L1/2/3 -->|
Only Only
MPLS-TP MPLS-TP
skipping to change at page 11, line 18 skipping to change at page 11, line 18
|<-- MPLS ---->|<-- MPLS-TP-->|<--- MPLS --->| |<-- MPLS ---->|<-- MPLS-TP-->|<--- MPLS --->|
Only Only
+---+ +----+ Non-TP +----+ MPLS-TP +----+ Non-TP +----+ +---+ +---+ +----+ Non-TP +----+ MPLS-TP +----+ Non-TP +----+ +---+
|CE1|---|T-PE|====LSP===|S-PE|====LSP===|S-PE|====LSP===|S-PE|---|CE2| |CE1|---|T-PE|====LSP===|S-PE|====LSP===|S-PE|====LSP===|S-PE|---|CE2|
+---+ +----+ +----+ +----+ +----+ +---+ +---+ +----+ +----+ +----+ +----+ +---+
(PW switching) (PW switching) (PW switching) (PW switching)
(a) [ Eth ] [ Eth ] [ Eth ] [ Eth ] [ Eth ] (a) [ Eth ] [ Eth ] [ Eth ] [ Eth ] [ Eth ]
[PW Seg't] [PW Seg't] [PW Seg't] [ PW Seg ] [ PW Seg ] [ PW Seg ]
[ LSP ] [-TP LSP ] [ LSP ] [ LSP ] [-TP LSP ] [ LSP ]
|<-- MPLS ---->|<-- MPLS-TP-->|<--- MPLS --->| |<-- MPLS ---->|<-- MPLS-TP-->|<--- MPLS --->|
Only Only
+---+ +----+ Non-TP +----+ MPLS-TP +----+ Non-TP +----+ +---+ +---+ +----+ Non-TP +----+ MPLS-TP +----+ Non-TP +----+ +---+
|CE1|---| PE |====LSP===| PE |====LSP===| PE |====LSP===| PE |---|CE2| |CE1|---| PE |====LSP===| PE |====LSP===| PE |====LSP===| PE |---|CE2|
+---+ +----+ +----+ +----+ +----+ +---+ +---+ +----+ +----+ +----+ +----+ +---+
(LSP stitching) (LSP stitching) (LSP stitching) (LSP stitching)
skipping to change at page 12, line 9 skipping to change at page 12, line 9
Point to point LSPs may be unidirectional or bi-directional, and it Point to point LSPs may be unidirectional or bi-directional, and it
must be possible to construct congruent Bi-directional LSPs. must be possible to construct congruent Bi-directional LSPs.
MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR and it MPLS-TP LSPs do not merge with other LSPs at an MPLS-TP LSR and it
must be possible to detect if a merged LSP has been created. must be possible to detect if a merged LSP has been created.
It must be possible to forward packets solely based on switching the It must be possible to forward packets solely based on switching the
MPLS or PW label. It must also be possible to establish and maintain MPLS or PW label. It must also be possible to establish and maintain
LSPs and/or pseudowires both in the absence or presence of a dynamic LSPs and/or pseudowires both in the absence or presence of a dynamic
control plane. When static provisioning is used, there must be no control plane. When static provisioning is used, there must be no
dependency on dynamic routing or signaling. dependency on dynamic routing or signalling.
OAM, protection and forwarding of data packets must be able to OAM, protection and forwarding of data packets must be able to
operate without IP forwarding support. operate without IP forwarding support.
It must be possible to monitor LSPs and pseudowires through the use It must be possible to monitor LSPs and pseudowires through the use
of OAM in the absence of control plane or routing functions. In this of OAM in the absence of control plane or routing functions. In this
case information gained from the OAM functions is used to initiate case information gained from the OAM functions is used to initiate
path recovery actions at either the PW or LSP layers. path recovery actions at either the PW or LSP layers.
3. MPLS Transport Profile Overview 3. MPLS Transport Profile Overview
skipping to change at page 12, line 51 skipping to change at page 12, line 51
layer is considered to be the native service of the MPLS-TP layer is considered to be the native service of the MPLS-TP
network. network.
o Where a client network makes use of an MPLS-TP server that o Where a client network makes use of an MPLS-TP server that
provides a packet transport service, the level of co-ordination provides a packet transport service, the level of co-ordination
required between the client and server layer networks is minimal required between the client and server layer networks is minimal
(preferably no co-ordination will be required). (preferably no co-ordination will be required).
o The complete set of packets generated by a client MPLS(-TP) layer o The complete set of packets generated by a client MPLS(-TP) layer
network using the packet transport service, which may contain network using the packet transport service, which may contain
packets that are not MPLS packets (e.g. IP or CNLS packets used packets that are not MPLS packets (e.g. IP or CLNS packets used
by the control/management plane of the client MPLS(-TP) layer by the control/management plane of the client MPLS(-TP) layer
network), are transported by the MPLS-TP server layer network. network), are transported by the MPLS-TP server layer network.
o The packet transport service enables the MPLS-TP layer network o The packet transport service enables the MPLS-TP layer network
addressing and other information (e.g. topology) to be hidden from addressing and other information (e.g. topology) to be hidden from
any client layer networks using that service, and vice-versa. any client layer networks using that service, and vice-versa.
These characteristics imply that a packet transport service does not These characteristics imply that a packet transport service does not
support a connectionless packet-switched forwarding mode. However, support a connectionless packet-switched forwarding mode. However,
this does not preclude it carrying client traffic associated with a this does not preclude it carrying client traffic associated with a
skipping to change at page 13, line 27 skipping to change at page 13, line 27
3.2. Scope of the MPLS Transport Profile 3.2. Scope of the MPLS Transport Profile
Figure 4 illustrates the scope of MPLS-TP. MPLS-TP solutions are Figure 4 illustrates the scope of MPLS-TP. MPLS-TP solutions are
primarily intended for packet transport applications. MPLS-TP is a primarily intended for packet transport applications. MPLS-TP is a
strict subset of MPLS, and comprises only those functions that are strict subset of MPLS, and comprises only those functions that are
necessary to meet the requirements of [RFC5654]. This includes MPLS necessary to meet the requirements of [RFC5654]. This includes MPLS
functions that were defined prior to [RFC5654] but that meet the functions that were defined prior to [RFC5654] but that meet the
requirements of [RFC5654], together with additional functions defined requirements of [RFC5654], together with additional functions defined
to meet those requirements. Some MPLS functions defined before to meet those requirements. Some MPLS functions defined before
[RFC5654] such as Equal Cost Multi-Path, LDP signaling used in such a [RFC5654] such as Equal Cost Multi-Path, LDP signalling used in such
way that it creates multipoint-to-point LSPs, and IP forwarding in a way that it creates multipoint-to-point LSPs, and IP forwarding in
the data plane are explicitly excluded from MPLS-TP by that the data plane are explicitly excluded from MPLS-TP by that
requirements specification. requirements specification.
Note that MPLS as a whole will continue to evolve to include Note that MPLS as a whole will continue to evolve to include
additional functions that do not conform to the MPLS Transport additional functions that do not conform to the MPLS Transport
Profile or its requirements, and thus fall outside the scope of Profile or its requirements, and thus fall outside the scope of
MPLS-TP. MPLS-TP.
|<============================== MPLS ==============================>| |<============================== MPLS ==============================>|
skipping to change at page 14, line 11 skipping to change at page 14, line 11
{ Additional } { Additional }
{ Transport } { Transport }
{ Functions } { Functions }
Figure 4: Scope of MPLS-TP Figure 4: Scope of MPLS-TP
3.3. Architecture 3.3. Architecture
MPLS-TP comprises the following architectural elements: MPLS-TP comprises the following architectural elements:
o A standard MPLS data plane [RFC3031] as profiled in
[draft-fbb-mpls-tp-data-plane].
o Sections, LSPs and PWs that provide a packet transport service for o Sections, LSPs and PWs that provide a packet transport service for
a client network. a client network.
o Proactive and on-demand Operations, Administration and Maintenance o Proactive and on-demand Operations, Administration and Maintenance
(OAM) functions to monitor and diagnose the MPLS-TP network, such (OAM) functions to monitor and diagnose the MPLS-TP network, such
as connectivity check, connectivity verification, performance as connectivity check, connectivity verification, performance
monitoring and fault localisation. monitoring and fault localisation.
o Optional control planes for LSPs and PWs, as well as support for o Optional control planes for LSPs and PWs, as well as support for
static provisioning and configuration. static provisioning and configuration.
skipping to change at page 15, line 48 skipping to change at page 15, line 51
operation to be performed by the next hop at that level of operation to be performed by the next hop at that level of
encapsulation. A swap of this label is an atomic operation in which encapsulation. A swap of this label is an atomic operation in which
the contents of the packet after the swapped label are opaque to the the contents of the packet after the swapped label are opaque to the
forwarder. The only event that interrupts a swap operation is TTL forwarder. The only event that interrupts a swap operation is TTL
expiry. This is a fundamental architectural construct of MPLS to be expiry. This is a fundamental architectural construct of MPLS to be
taken into account when designing protocol extensions that require taken into account when designing protocol extensions that require
packets (e.g. OAM packets) to be sent to an intermediate LSR. packets (e.g. OAM packets) to be sent to an intermediate LSR.
Further processing to determine the context of a packet occurs when a Further processing to determine the context of a packet occurs when a
swap operation is interrupted in this manner, or a pop operation swap operation is interrupted in this manner, or a pop operation
exposes a specific reserved label at the top of the stack. Otherwise exposes a specific reserved label at the top of the stack, or the
the packet is forwarded according to the procedures in [RFC3032]. packet is received with the GAL Section 3.6 at the top of stack.
Otherwise the packet is forwarded according to the procedures in
[RFC3032].
Point-to-point MPLS-TP LSPs can be either unidirectional or Point-to-point MPLS-TP LSPs can be either unidirectional or
bidirectional. bidirectional.
It must be possible to configure an MPLS-TP LSP such that the forward It must be possible to configure an MPLS-TP LSP such that the forward
and backward directions of a bidirectional MPLS-TP LSP are co-routed, and backward directions of a bidirectional MPLS-TP LSP are co-routed,
i.e. follow the same path. The pairing relationship between the i.e. follow the same path. The pairing relationship between the
forward and the backward directions must be known at each LSR or LER forward and the backward directions must be known at each LSR or LER
on a bidirectional LSP. on a bidirectional LSP.
skipping to change at page 16, line 39 skipping to change at page 16, line 44
Only the Pipe and Short Pipe DiffServ tunnelling and TTL processing Only the Pipe and Short Pipe DiffServ tunnelling and TTL processing
models described in [RFC3270] and [RFC3443] are supported in MPLS-TP. models described in [RFC3270] and [RFC3443] are supported in MPLS-TP.
3.4. MPLS-TP Native Services 3.4. MPLS-TP Native Services
This document describes the architecture for two types of native This document describes the architecture for two types of native
service adaptation: service adaptation:
o A PW: PW Demultiplexer and PW encapsulation o A PW: PW Demultiplexer and PW encapsulation
o An MPLS Label o An MPLS Label (for example carrying a layer 2 VPN [RFC4664], a
layer 3 VPN [RFC4364], or a TE-LSP [RFC3209])
o An IP packet
A PW provides any emulated service that the IETF has defined to be A PW provides any emulated service that the IETF has defined to be
provided by a PW, for example Ethernet, Frame Relay, or PPP/HDLC. A provided by a PW, for example Ethernet, Frame Relay, or PPP/HDLC. A
registry of PW types is maintained by IANA. When the client registry of PW types is maintained by IANA. When the client
adaptation is via a PW, the mechanisms described in Section 3.4.2 are adaptation is via a PW, the mechanisms described in Section 3.4.2 are
used. used.
An MPLS LSP Label can also be used as the adaptation, in which case An MPLS LSP Label can also be used as the adaptation, in which case
any client supported by [RFC3031] is allowed, for example a MPLS LSP, any client supported by [RFC3031] is allowed, for example a MPLS LSP,
PW, or IP. When the client adaptation is via an MPLS label, the PW, or IP. When the client adaptation is via an MPLS label, the
mechanisms described in Section 3.4.3 are used. mechanisms described in Section 3.4.3 are used.
3.4.1. MPLS-TP Client/Server Relationship 3.4.1. MPLS-TP Client/Server Relationship
The MPLS-TP client server relationship is defined by the MPLS-TP The MPLS-TP client server relationship is defined by the MPLS-TP
network boundary and the label context. It is not explicitly network boundary and the label context. It is not explicitly
indicated in the packet. In terms of the MPLS label stack, when the indicated in the packet. In terms of the MPLS label stack, when the
client traffic type of the MPLS-TP network is an MPLS LSP or a PW, client traffic type of the MPLS-TP network is an MPLS LSP or a PW,
then the S bit of all the labels in the MPLS-TP label stack are zero, then the S bits of all the labels in the MPLS-TP label stack carrying
otherwise the bottom label of the MPLS-TP label stack has the S bit that client traffic are zero; otherwise the bottom label of the
set to one ( i.e. there can only one S bit set in a label stack). MPLS-TP label stack has the S bit set to one (i.e. there can only one
S bit set in a label stack).
The data plane behaviour of MPLS-TP is the same as the best current The data plane behaviour of MPLS-TP is the same as the best current
practise for MPLS. This includes the setting of the S-Bit. In each practise for MPLS. This includes the setting of the S-Bit. In each
case, the S-bit is set to indicate the bottom (i.e. inner-most) label case, the S-bit is set to indicate the bottom (i.e. inner-most) label
in the label stack that is contiguous between the MPLS-TP server and in the label stack that is contiguous between the MPLS-TP server and
the client layer. Note that this best current practise differs the client layer. Note that this best current practise differs
slightly from [RFC3032] which uses the S-bit to identify when MPLS slightly from [RFC3032] which uses the S-bit to identify when MPLS
label processing stops and network layer processing starts. label processing stops and network layer processing starts.
The relationship of MPLS-TP to its clients is illustrated in The relationship of MPLS-TP to its clients is illustrated in
Figure 5. Figure 5.
PW-Based MPLS Labelled PW-Based MPLS Labelled IP
Services Services Services Services Transport
|-----------------------------| |----------------------------| |------------| |-----------------------------| |------------|
Emulated PW over LSP IP over LSP IP Emulated PW over LSP IP over LSP IP
Service Service
+------------+ +------------+
| PW Payload | | PW Payload |
+------------+ +------------+ (CLIENTS) +------------+ +------------+ (CLIENTS)
|PW Lbl(S=1) | | IP | |PW Lbl(S=1) | | IP |
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| PW Payload | |LSP Lbl(S=0)| |LSP Lbl(S=1)| | IP | | PW Payload | |LSP Lbl(S=0)| |LSP Lbl(S=1)| | IP |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|PW Lbl (S=1)| |LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=1)| |PW Lbl (S=1)| |LSP Lbl(S=0)| |LSP Lbl(S=0)| |LSP Lbl(S=1)|
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+ +------------+
|LSP Lbl(S=0)| |LSP Lbl(S=0)|
+------------+ (MPLS-TP) +------------+ (MPLS-TP)
~~~~~~~~~~~ = Client - MPLS-TP layer boundary ~~~~~~~~~~~ denotes Client <-> MPLS-TP layer boundary
Note that in the PW over LSP case the client may omit its LSP Label if Note that in the PW over LSP case the client may omit its LSP Label if
penultimate hop popping has been agreed with its peer penultimate hop popping has been agreed with its peer
Figure 5: MPLS-TP - Client Relationship Figure 5: MPLS-TP - Client Relationship
The data plane behaviour of MPLS-TP is the same as the best current The data plane behaviour of MPLS-TP is the same as the best current
practise for MPLS. This includes the setting of the S-Bit. In each practise for MPLS. This includes the setting of the S-Bit. In each
case, the S-bit is set to indicate the bottom (i.e. inner-most) label case, the S-bit is set to indicate the bottom (i.e. inner-most) label
skipping to change at page 18, line 47 skipping to change at page 18, line 47
Note that the label stacks shown above are divided between those Note that the label stacks shown above are divided between those
inside the MPLS-TP Network and those within the client network when inside the MPLS-TP Network and those within the client network when
the client network is MPLS(-TP). They illustrate the smallest number the client network is MPLS(-TP). They illustrate the smallest number
of labels possible. These label stacks could also include more of labels possible. These label stacks could also include more
labels. labels.
3.4.2. Pseudowire Adaptation 3.4.2. Pseudowire Adaptation
The architecture for an MPLS-TP network that provides PW emulated The architecture for an MPLS-TP network that provides PW emulated
services is based on the MPLS [RFC3031] and pseudowire [RFC3985] services is based on the MPLS [RFC3031] and pseudowire [RFC3985]
architectures. If multi-segment pseudowires are used to provide a architectures. Multi-segment pseudowires may optionally be used to
packet transport service, motivated by, for example, the requirements provide a packet transport service, and their use is consistent with
specified in [RFC5254], then the MS-PW architecture [RFC5659] also the MPLS-TP architecture. The use of MS-PWs may be motivated by, for
applies. example, the requirements specified in [RFC5254]. If MS-PWs are
used, then the MS-PW architecture [RFC5659] also applies.
Figure 6 shows the architecture for an MPLS-TP network using single- Figure 6 shows the architecture for an MPLS-TP network using single-
segment PWs. segment PWs.
|<--------------- Emulated Service ----------------->| |<--------------- Emulated Service ----------------->|
| | | |
| |<-------- Pseudowire -------->| | | |<-------- Pseudowire -------->| |
| | encapsulated, packet | | | | encapsulated, packet | |
| | transport service | | | | transport service | |
| | | | | | | |
skipping to change at page 21, line 25 skipping to change at page 21, line 25
+-------------------+ +-------------------+ +-------------------+ +-------------------+ +-------------------+ +-------------------+
User Traffic PW OAM LSP OAM User Traffic PW OAM LSP OAM
Note: H(ighlighted) indicates the part of the protocol stack we are Note: H(ighlighted) indicates the part of the protocol stack we are
considering in this document. considering in this document.
Figure 8: MPLS-TP Layer Network using Pseudowires Figure 8: MPLS-TP Layer Network using Pseudowires
PWs and their underlying labels may be configured or signaled. See PWs and their underlying labels may be configured or signaled. See
Section 3.9 for additional details related to configured service Section 3.11 for additional details related to configured service
types. See Section 3.8 for additional details related to signaled types. See Section 3.9 for additional details related to signaled
service types. service types.
3.4.2.1. Pseudowire Bases Services 3.4.2.1. Pseudowire Bases Services
When providing a Virtual Private Wire Service (VPWS) , Virtual When providing a Virtual Private Wire Service (VPWS) , Virtual
Private Local Area Network Service (VPLS), Virtual Private Multicast Private Local Area Network Service (VPLS), Virtual Private Multicast
Service (VPMS) or Internet Protocol Local Area Network Service (IPLS) Service (VPMS) or Internet Protocol Local Area Network Service (IPLS)
pseudowires must be used to carry the client service. VPWS, VLPS, pseudowires must be used to carry the client service. VPWS, VLPS,
and IPLS are described in [RFC4664]. VPMS is described in and IPLS are described in [RFC4664]. VPMS is described in
[I-D.ietf-l2vpn-vpms-frmwk-requirements] [I-D.ietf-l2vpn-vpms-frmwk-requirements]
3.4.3. Network Layer Adaptation 3.4.3. Network Layer Adaptation
MPLS-TP LSPs can be used to transport network layer clients. The MPLS-TP LSPs can be used to transport network layer clients. This
network layer protocols supported by [RFC3031] and supported in document uses the term Network Layer in the same sense as it is used
[RFC3032] can be transported between service interfaces. Examples in [RFC3031] and [RFC3032]. The network layer protocols supported by
are shown in Figure 5 above. Support for network layer clients [RFC3031] and [RFC3032] can be transported between service
follows the MPLS architecture for support of network layer protocols interfaces. Examples are shown in Figure 5 above. Support for
as defined in and supported in [RFC3032][RFC3031] and supported in network layer clients follows the MPLS architecture for support of
[RFC3032]. network layer protocols as specified in [RFC3031] and [RFC3032].
With network layer adaptation, the MPLS-TP domain provides either a With network layer adaptation, the MPLS-TP domain provides either a
uni-directional or bidirectional point-to-point connection between uni-directional or bidirectional point-to-point connection between
two PEs in order to deliver a packet transport service to attached two PEs in order to deliver a packet transport service to attached
customer edge (CE) nodes. For example, a CE may be an IP, MPLS or customer edge (CE) nodes. For example, a CE may be an IP, MPLS or
MPLS-TP node. As shown in Figure 9, there is an attachment circuit MPLS-TP node. As shown in Figure 9, there is an attachment circuit
between the CE node on the left and its corresponding provider edge between the CE node on the left and its corresponding provider edge
(PE) node which provides the service interface, a bidirectional LSP (PE) node which provides the service interface, a bidirectional LSP
across the MPLS-TP network to the corresponding PE node on the right, across the MPLS-TP network to the corresponding PE node on the right,
and an attachment circuit between that PE node and the corresponding and an attachment circuit between that PE node and the corresponding
CE node for this service. CE node for this service.
The attachment circuits may be heterogeneous (e.g., any combination The attachment circuits may be heterogeneous (e.g., any combination
of SDH, PPP, Frame Relay, etc.) and network layer protocol payloads of SDH, PPP, Frame Relay, etc.) and network layer protocol payloads
arrive at the service interface encapsulated in the Layer1/Layer2 arrive at the service interface encapsulated in the Layer1/Layer2
encoding defined for that access link type. It should be noted that encoding defined for that access link type. It should be noted that
the set of network layer protocols includes MPLS and hence MPLS the set of network layer protocols includes MPLS and hence MPLS
encoded packets with an MPLS label stack (the client MPLS stack), may encoded packets with an MPLS label stack (the client MPLS stack), may
appear at the service interface. appear at the service interface.
|<------------- Client Network Layer-------------->| |<------------- Client Network Layer ------------->|
| | | |
| |<---- Pkt Xport Service --->| | |<---- Pkt Xport Service --->| |
| | | | | | | |
| | |<-- PSN Tunnel -->| | | | | |<-- PSN Tunnel -->| | |
| V V V V | | V V V V |
V AC +----+ +---+ +----+ AC V V AC +----+ +---+ +----+ AC V
+-----+ | |PE1 | | | |PE2 | | +-----+ +-----+ | |PE1 | | | |PE2 | | +-----+
| | |LSP | | | | | | | | | | | |LSP | | | | | | | | |
| CE1 |----------| |========X=========| |----------| CE2 | | CE1 |----------| |========X=========| |----------| CE2 |
| | ^ |IP | | ^ | | ^ | | | ^ | | | | ^ |IP | | ^ | | ^ | | | ^ | |
+-----+ | | | | | | | | | | | | +-----+ +-----+ | | | | | | | | | | | | +-----+
^ | +----+ | +---+ | +----+ | | ^ ^ | +----+ | +---+ | +----+ | | ^
skipping to change at page 23, line 47 skipping to change at page 23, line 47
the control of the nodes within the MPLS-TP transport network and it the control of the nodes within the MPLS-TP transport network and it
is not visible outside that network. Figure 10 shows how a client is not visible outside that network. Figure 10 shows how a client
network protocol stack (which may be an MPLS label stack and payload) network protocol stack (which may be an MPLS label stack and payload)
is carried over a network layer client service over an MPLS-TP is carried over a network layer client service over an MPLS-TP
transport network. transport network.
A label per network layer protocol payload type that is to be A label per network layer protocol payload type that is to be
transported is required. When multiple protocol payload types are to transported is required. When multiple protocol payload types are to
be carried over a single service a unique label stack entry must be be carried over a single service a unique label stack entry must be
present for each payload type. Such labels are referred to as present for each payload type. Such labels are referred to as
"Encapsulation Labels", one of which is shown in A label per network "Encapsulation Labels", one of which is shown in Figure 10.
layer protocol payload type that is to be transported is required. Encapsulation Label may be either configured or signaled.
Such labels are referred to as "Encapsulation Labels", one of which
is shown in Figure 10. Encapsulation Label is either configured or
signaled. Encapsulation Labels are either configured or signaled.
Both an Encapsulation Label and a Service Label should be present in Both an Encapsulation Label and a Service Label should be present in
the label stack when a particular packet transport service is the label stack when a particular packet transport service is
supporting more than one network layer protocol payload type. For supporting more than one network layer protocol payload type. For
example, if both IP and MPLS are to be carried, as shown in Figure 9, example, if both IP and MPLS are to be carried, as shown in Figure 9,
then two Encapsulation Labels are mapped on to a common Service then two Encapsulation Labels are mapped on to a common Service
Label. Label.
The Encapsulation Label may be omitted when the transport service is Note: The Encapsulation Label may be omitted when the transport
supporting only one network layer protocol payload type. For service is supporting only one network layer protocol payload type.
example, if only MPLS labeled packets are carried over a service, For example, if only MPLS labeled packets are carried over a service,
then the Service Label (stack entry) provides both the payload type then the Service Label (stack entry) provides both the payload type
indication and service identification. indication and service identification.
Service labels are typically carried over an MPLS-TP LSP edge-to-edge Service labels are typically carried over an MPLS-TP LSP edge-to-edge
(or transport path layer). An MPLS-TP edge-to-edge LSP is (or transport path layer). An MPLS-TP edge-to-edge LSP is
represented as an LSP Demux label as shown in Figure 10. An edge-to- represented as an LSP Demux label as shown in Figure 10. An edge-to-
edge LSP is commonly used when more than one service exists between edge LSP is commonly used when more than one service exists between
two PEs. The edge-to-edge LSP may be omitted when only one service two PEs.
Note, the edge-to-edge LSP may be omitted when only one service
exists between two PEs. For example, if only one service is carried exists between two PEs. For example, if only one service is carried
between two PEs then a single Service Label could be used to provide between two PEs then a single Service Label could be used to provide
both the service indication and the MPLS-TP edge-to-edge LSP. both the service indication and the MPLS-TP edge-to-edge LSP.
Alternatively, if multiple services exist between a pair of PEs then Alternatively, if multiple services exist between a pair of PEs then
a per-client Service Label would be mapped on to a common MPLS-TP a per-client Service Label would be mapped on to a common MPLS-TP
edge-to-edge LSP. edge-to-edge LSP.
As noted above, the layer 2 and layer 1 protocols used to carry the As noted above, the layer 2 and layer 1 protocols used to carry the
network layer protocol over the attachment circuits are not network layer protocol over the attachment circuits are not
transported across the MPLS-TP network. This enables the use of transported across the MPLS-TP network. This enables the use of
skipping to change at page 25, line 5 skipping to change at page 25, line 4
adjacent node. That is the CE sets the destination MAC address to an adjacent node. That is the CE sets the destination MAC address to an
address that ensures delivery to the PE, and the PE sets the address that ensures delivery to the PE, and the PE sets the
destination MAC address to an address that ensures delivery to the destination MAC address to an address that ensures delivery to the
CE. The specific address used is technology type specific and is not CE. The specific address used is technology type specific and is not
covered in this document. In some technologies the MAC address will covered in this document. In some technologies the MAC address will
need to be configured (Examples for the Ethernet case include a need to be configured (Examples for the Ethernet case include a
configured unicast MAC address for the adjacent node, or even using configured unicast MAC address for the adjacent node, or even using
the broadcast MAC address when the CE-PE service interface is the broadcast MAC address when the CE-PE service interface is
dedicated. The configured address is then used as the MAC dedicated. The configured address is then used as the MAC
destination address for all packets sent over the service interface.) destination address for all packets sent over the service interface.)
Note that when two CEs, which peer with each other, operate over a Note that when two CEs, which peer with each other, operate over a
network layer transport service run a routing protocol such as IS-IS network layer transport service run a routing protocol such as IS-IS
or OSPF some care should be taken to configure the routing protocols or OSPF some care should be taken to configure the routing protocols
to use point- to-point adjacencies .The specifics of such to use point- to-point adjacencies .The specifics of such
configuration is outside the scope of this document. See [RFC5309] configuration is outside the scope of this document. See [RFC5309]
for additional details. for additional details.
The CE to CE service types and corresponding labels may be configured The CE to CE service types and corresponding labels may be configured
or signaled . See Section 3.9 for additional details related to or signaled . See Section 3.11 for additional details related to
configured service types. See Section 3.8 for additional details configured service types. See Section 3.9 for additional details
related to signaled service types. related to signaled service types.
3.5. Identifiers 3.5. Identifiers
Identifiers are used to uniquely distinguish entities in an MPLS-TP Identifiers are used to uniquely distinguish entities in an MPLS-TP
network. These include operators, nodes, LSPs, pseudowires, and network. These include operators, nodes, LSPs, pseudowires, and
their associated maintenance entities. their associated maintenance entities.
[I-D.ietf-mpls-tp-identifiers] defines a set of identifiers that are [I-D.ietf-mpls-tp-identifiers] defines a set of identifiers that are
compatible with existing MPLS control plane identifiers, as well as a compatible with existing MPLS control plane identifiers, as well as a
set of identifiers that may be used when no IP control plane is set of identifiers that may be used when no IP control plane is
available. available.
3.6. Generic Associated Channel (G-ACh) 3.6. Generic Associated Channel (G-ACh)
For correct operation of the OAM it is important that the OAM packets For correct operation of the OAM it is important that the OAM packets
fate-share with the data packets. In addition in MPLS-TP it is fate-share with the data packets. In addition in MPLS-TP it is
necessary to discriminate between user data payloads and other types necessary to discriminate between user data payloads and other types
of payload. For example, a packet may be associated with a Signaling of payload. For example, a packet may be associated with a
Communication Channel (SCC), or a channel used for Automatic Signalling Communication Channel (SCC), or a channel used for
Protection Switching (APS) data. This is achieved by carrying such Automatic Protection Switching (APS) data. This is achieved by
packets on a generic control channel associated to the LSP, PW or carrying such packets on a generic control channel associated to the
section. LSP, PW or section.
MPLS-TP makes use of such a generic associated channel (G-ACh) to MPLS-TP makes use of such a generic associated channel (G-ACh) to
support Fault, Configuration, Accounting, Performance and Security support Fault, Configuration, Accounting, Performance and Security
(FCAPS) functions by carrying packets related to OAM, APS, SCC, MCC (FCAPS) functions by carrying packets related to OAM, APS, SCC, MCC
or other packet types in-band over LSPs or PWs. The G-ACh is defined or other packet types in-band over LSPs or PWs. The G-ACh is defined
in [RFC5586] and is similar to the Pseudowire Associated Channel in [RFC5586] and is similar to the Pseudowire Associated Channel
[RFC4385], which is used to carry OAM packets over pseudowires. The [RFC4385], which is used to carry OAM packets over pseudowires. The
G-ACh is indicated by a generic associated channel header (ACH), G-ACh is indicated by a generic associated channel header (ACH),
similar to the Pseudowire VCCV control word; this header is present similar to the Pseudowire VCCV control word; this header is present
for all Sections, LSPs and PWs making use of FCAPS functions for all Sections, LSPs and PWs making use of FCAPS functions
skipping to change at page 27, line 7 skipping to change at page 27, line 6
data that they are sharing resources with. Conversely, capacity must data that they are sharing resources with. Conversely, capacity must
be made available for important G-ACh uses such as protection and be made available for important G-ACh uses such as protection and
OAM. In addition, protocols using the G-ACh must conform to the OAM. In addition, protocols using the G-ACh must conform to the
security and congestion considerations described in [RFC5586]. security and congestion considerations described in [RFC5586].
Figure 11 shows the reference model depicting how the control channel Figure 11 shows the reference model depicting how the control channel
is associated with the pseudowire protocol stack. This is based on is associated with the pseudowire protocol stack. This is based on
the reference model for VCCV shown in Figure 2 of [RFC5085]. the reference model for VCCV shown in Figure 2 of [RFC5085].
+-------------+ +-------------+ +-------------+ +-------------+
| Payload | < Service / FCAPS > | Payload | | Payload | < FCAPS > | Payload |
+-------------+ +-------------+ +-------------+ +-------------+
| Demux / | < CW / ACH for PWs > | Demux / | | Demux / | < ACH for PW > | Demux / |
|Discriminator| |Discriminator| |Discriminator| |Discriminator|
+-------------+ +-------------+ +-------------+ +-------------+
| PW | < PW > | PW | | PW | < PW > | PW |
+-------------+ +-------------+ +-------------+ +-------------+
| PSN | < LSP > | PSN | | PSN | < LSP > | PSN |
+-------------+ +-------------+ +-------------+ +-------------+
| Physical | | Physical | | Physical | | Physical |
+-----+-------+ +-----+-------+ +-----+-------+ +-----+-------+
| | | |
| ____ ___ ____ | | ____ ___ ____ |
| _/ \___/ \ _/ \__ | | _/ \___/ \ _/ \__ |
| / \__/ \_ | | / \__/ \_ |
| / \ | | / \ |
+--------| MPLS/MPLS-TP Network |---+ +--------| MPLS/MPLS-TP Network |---+
\ / \ /
\ ___ ___ __ _/ \ ___ ___ __ _/
\_/ \____/ \___/ \____/ \_/ \____/ \___/ \____/
Figure 11: PWE3 Protocol Stack Reference Model including the G-ACh Figure 11: PWE3 Protocol Stack Reference Model showing the G-ACh
PW associated channel messages are encapsulated using the PWE3 PW associated channel messages are encapsulated using the PWE3
encapsulation, so that they are handled and processed in the same encapsulation, so that they are handled and processed in the same
manner (or in some cases, an analogous manner) as the PW PDUs for manner (or in some cases, an analogous manner) as the PW PDUs for
which they provide a control channel. which they provide a control channel.
Figure 12 shows the reference model depicting how the control channel Figure 12 shows the reference model depicting how the control channel
is associated with the LSP protocol stack. is associated with the LSP protocol stack.
+-------------+ +-------------+ +-------------+ +-------------+
| Payload | < Service > | Payload | | Payload | < FCAPS > | Payload |
+-------------+ +-------------+ +-------------+ +-------------+
|Discriminator| < ACH on LSP > |Discriminator| |Discriminator| < ACH on LSP > |Discriminator|
+-------------+ +-------------+ +-------------+ +-------------+
|Demultiplexer| < GAL on LSP > |Demultiplexer| |Demultiplexer| < GAL on LSP > |Demultiplexer|
+-------------+ +-------------+ +-------------+ +-------------+
| PSN | < LSP > | PSN | | PSN | < LSP > | PSN |
+-------------+ +-------------+ +-------------+ +-------------+
| Physical | | Physical | | Physical | | Physical |
+-----+-------+ +-----+-------+ +-----+-------+ +-----+-------+
| | | |
| ____ ___ ____ | | ____ ___ ____ |
| _/ \___/ \ _/ \__ | | _/ \___/ \ _/ \__ |
| / \__/ \_ | | / \__/ \_ |
| / \ | | / \ |
+--------| MPLS/MPLS-TP Network |---+ +--------| MPLS/MPLS-TP Network |---+
\ / \ /
\ ___ ___ __ _/ \ ___ ___ __ _/
\_/ \____/ \___/ \____/ \_/ \____/ \___/ \____/
Figure 12: MPLS Protocol Stack Reference Model including the LSP Figure 12: MPLS Protocol Stack Reference Model showing the LSP
Associated Control Channel Associated Control Channel
3.7. Operations, Administration and Maintenance (OAM) 3.7. Operations, Administration and Maintenance (OAM)
MPLS-TP must be able to operate in environments where IP is not used MPLS-TP must be able to operate in environments where IP is not used
in the forwarding plane. Therefore, the default mechanism for OAM in the forwarding plane. Therefore, the default mechanism for OAM
demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated demultiplexing in MPLS-TP LSPs and PWs is the Generic Associated
Channel (Section 3.6). Forwarding based on IP addresses for user or Channel (Section 3.6). Forwarding based on IP addresses for user or
OAM packets is not required for MPLS-TP. OAM packets is not required for MPLS-TP.
skipping to change at page 29, line 22 skipping to change at page 29, line 23
detection and localisation) and performance monitoring (e.g. packet detection and localisation) and performance monitoring (e.g. packet
delay and loss measurement) of the LSP, PW or section. The framework delay and loss measurement) of the LSP, PW or section. The framework
for OAM in MPLS-TP is specified in [I-D.ietf-mpls-tp-oam-framework]. for OAM in MPLS-TP is specified in [I-D.ietf-mpls-tp-oam-framework].
MPLS-TP OAM packets share the same fate as their corresponding data MPLS-TP OAM packets share the same fate as their corresponding data
packets, and are identified through the Generic Associated Channel packets, and are identified through the Generic Associated Channel
mechanism [RFC5586]. This uses a combination of an Associated mechanism [RFC5586]. This uses a combination of an Associated
Channel Header (ACH) and a Generic Alert Label (GAL) to create a Channel Header (ACH) and a Generic Alert Label (GAL) to create a
control channel associated to an LSP, Section or PW. control channel associated to an LSP, Section or PW.
3.7.1. OAM Architecture
OAM and monitoring in MPLS-TP is based on the concept of maintenance OAM and monitoring in MPLS-TP is based on the concept of maintenance
entities, as described in [I-D.ietf-mpls-tp-oam-framework]. A entities, as described in [I-D.ietf-mpls-tp-oam-framework]. A
Maintenance Entity can be viewed as the association of two Maintenance Entity can be viewed as the association of two
Maintenance End Points (MEPs) (see example in Figure 13 ). Another Maintenance End Points (MEPs). A Maintenance Entity Group (MEG) is a
OAM construct is referred to as Maintenance Entity Group (MEG), which collection of one or more MEs that belongs to the same transport path
is a collection of one or more MEs that belongs to the same transport and that are maintained and monitored as a group. The MEPs that form
path and that are maintained and monitored as a group. The MEPs that an ME limit the OAM responsibilities of an OAM flow to within the
form an ME should be configured and managed to limit the OAM domain of a transport path or segment, in the specific layer network
responsibilities of an OAM flow within the domain of a transport path that is being monitored and managed.
or segment, in the specific layer network that is being monitored and
managed.
Each OAM flow is associated with a single ME. Each MEP within an ME
resides at the boundaries of that ME. An ME may also include a set
of zero or more Maintenance Intermediate Points (MIPs), which reside
within the Maintenance Entity. Maintenance End Points (MEPs) are
capable of sourcing and sinking OAM flows, while Maintenance
Intermediate Points (MIPs) can only sink or respond to OAM flows from
within a MEG, or originate notifications as a result of specific
network conditions.
========================== End to End LSP OAM ==========================
..... ..... ..... .....
''''' ''''' ''''' '''''
|<-------- Carrier 1 --------->| |<--- Carrier 2 ----->|
---- --- --- ---- ---- --- ----
NNI | | | | | | | | NNI | | | | | | NNI
| | | | | | | | | | | | | |
---- --- --- ---- ---- --- ----
==== Segment LSP OAM ====== == Seg't == === Seg't LSP OAM ===
(Carrier 1) LSP OAM (Carrier 2)
(inter-carrier)
..... ..... ..... .......... .......... ..... .....
|MEP|---|MIP|---|MIP|--|MEP||MEP|---|MEP||MEP|--|MIP|----|MEP|
''''' ''''' ''''' '''''''''' '''''''''' ''''' '''''
<------------ ME ----------><--- ME ----><------- ME -------->
Note: MEPs for End-to-end LSP OAM exist outside of the scope
of this figure.
Figure 13: Example of MPLS-TP OAM showing end-to-end and segment OAM
Figure 14 illustrates how the concept of Maintenance Entities can be
mapped to sections, LSPs and PWs in an MPLS-TP network that uses MS-
PWs.
Native |<-------------------- PW15 --------------------->| Native
Layer | | Layer
Service | |<-PSN13->| |<-PSN3X->| |<-PSNXZ->| | Service
(AC1) V V LSP V V LSP V V LSP V V (AC2)
+----+ +-+ +----+ +----+ +-+ +----+
+---+ |TPE1| | | |SPE3| |SPEX| | | |TPEZ| +---+
| | | |=========| |=========| |=========| | | |
|CE1|------|........PW1.....X..|...PW3...|.X......PW5........|-----|CE2|
| | | |=========| |=========| |=========| | | |
+---+ | 1 | |2| | 3 | | X | |Y| | Z | +---+
+----+ +-+ +----+ +----+ +-+ +----+
|<- Subnetwork 123->| |<- Subnetwork XYZ->|
.------------------- PW15 PME -------------------.
.---- PW1 PTCME ----. .---- PW5 PTCME ---.
.---------. .---------.
PSN13 LME PSNXZ LME
.--. .--. .--------. .--. .--.
Sec12 SME Sec23 SME Sec3X SME SecXY SME SecYZ SME
TPE1: Terminating Provider Edge 1 SPE2: Switching Provider Edge 3
TPEX: Terminating Provider Edge X SPEZ: Switching Provider Edge Z
.---. ME . MEP ==== LSP .... PW
SME: Section Maintenance Entity
LME: LSP Maintenance Entity
PME: PW Maintenance Entity
Figure 14: MPLS-TP OAM architecture showing PWs, LSPs and Sections An ME may also include a set of Maintenance Intermediate Points
(MIPs). Maintenance End Points (MEPs) are capable of sourcing and
sinking OAM flows, while Maintenance Intermediate Points (MIPs) can
only sink or respond to OAM flows from within a MEG, or originate
notifications as a result of specific network conditions.
The following MPLS-TP MEs are specified in The following MPLS-TP MEs are specified in
[I-D.ietf-mpls-tp-oam-framework]: [I-D.ietf-mpls-tp-oam-framework]:
o A Section Maintenance Entity (SME), allowing monitoring and o A Section Maintenance Entity (SME), allowing monitoring and
management of MPLS-TP Sections (between MPLS LSRs). management of MPLS-TP Sections (between MPLS LSRs).
o A LSP Maintenance Entity (LME), allowing monitoring and management o A LSP Maintenance Entity (LME), allowing monitoring and management
of an end-to-end LSP (between LERs). of an edge-to-edge LSP (between LERs).
o A PW Maintenance Entity (PME), allowing monitoring and management o A PW Maintenance Entity (PME), allowing monitoring and management
of an end-to-end SS/MS-PWs (between T-PEs). of an edge-to-edge SS/MS-PWs (between T-PEs).
o An LSP Tandem Connection Maintenance Entity (LTCME). o An LSP Tandem Connection Maintenance Entity (LTCME).
A G-ACH packet may be directed to an individual MIP along the path of A G-ACH packet may be directed to an individual MIP along the path of
an LSP or MS-PW by setting the appropriate TTL in the label for the an LSP or MS-PW by setting the appropriate TTL in the label for the
G-ACH packet, as per the traceroute mode of LSP Ping [RFC4379] and G-ACH packet, as per the traceroute mode of LSP Ping [RFC4379] and
the vccv-trace mode of[I-D.ietf-pwe3-segmented-pw]. Note that this the vccv-trace mode of[I-D.ietf-pwe3-segmented-pw]. Note that this
works when the location of MIPs along the LSP or PW path is known by works when the location of MIPs along the LSP or PW path is known by
the MEP. There may be circumstances where this is not the case, e.g. the MEP. There may be circumstances where this is not the case, e.g.
following restoration using a facility bypass LSP. In these cases, following restoration using a facility bypass LSP. In these cases,
skipping to change at page 32, line 29 skipping to change at page 30, line 29
that this must occur at least once. that this must occur at least once.
MEPs may only act as a sink of OAM packets when the label associated MEPs may only act as a sink of OAM packets when the label associated
with the LSP or PW for that ME is popped. MIPs can only be placed with the LSP or PW for that ME is popped. MIPs can only be placed
where an exception to the normal forwarding operation occurs. A MEP where an exception to the normal forwarding operation occurs. A MEP
may act as a source of OAM packets wherever a label is pushed or may act as a source of OAM packets wherever a label is pushed or
swapped. For example, on an MS-PW, a MEP may source OAM within an swapped. For example, on an MS-PW, a MEP may source OAM within an
S-PE or a T-PE, but a MIP may only be associated with a S-PE and a S-PE or a T-PE, but a MIP may only be associated with a S-PE and a
sink MEP can only be associated with a T-PE. sink MEP can only be associated with a T-PE.
3.7.2. OAM Functions The MPLS-TP OAM architecture supports a wide range of OAM functions
to check continuity, to verify connectivity and to monitor the
preformance of the path, to generate, filter and manage local and
remote defect alarms. These functions are applicable to any layer
defined within MPLS-TP, i.e. to MPLS-TP Sections, LSPs and PWs.
The MPLS-TP OAM architecture supports a wide range of OAM functions, The MPLS-TP OAM tool-set must be able to operate without relying on a
including the following: dynamic control plane or IP functionality in the datapath. In the
case of an MPLS-TP deployment in a network in which IP functionality
is available, all existing IP/MPLS OAM functions, e.g. LSP-Ping, BFD
and VCCV, may be used.
o Continuity Check 3.8. LSP Return Path
o Connectivity Verification Management, control and OAM protocol functions may require response
packets to be delivered from the receiver back to the originator of a
message exchange. This section provides a summary of the return path
options in MPLS-TP networks.
o Performance Monitoring (e.g. packet loss and delay measurement) In this discussion we assume that A and B are terminal LSRs (i.e.
LERs) for an MPLS-TP LSP and that Y is an intermediate LSR along the
LSP. In the unidirectional case, A is taken to be the upstream and B
the downstream LSR with respect to the LSP. We consider the
following cases for the various types of LSPs:
o Alarm Suppression 1. Packet transmission from B to A
o Remote Integrity 2. Packet transmission from Y to A
These functions are applicable to any layer defined within MPLS-TP, 3. Packet transmission from B to Y
i.e. to MPLS-TP Sections, LSPs and PWs.
The MPLS-TP OAM tool-set must be able to operate without relying on a Note that a return path may not always exist, and that packet
dynamic control plane or IP functionality in the datapath. In the transmission in one or more of the above cases may not be possible.
case of an MPLS-TP deployment in a network in which IP functionality In general the existence and nature of return paths for MPLS-TP LSPs
is available, all existing IP/MPLS OAM functions, e.g. LSP-Ping, BFD is determined by operational provisioning.
and VCCV, may be used.
One use of OAM mechanisms is to detect link failures, node failures 3.8.1. Return Path Types
and performance outside the required specification which then may be
used to trigger recovery actions, according to the requirements of
the service.
3.8. Control Plane There are two types of return path that may be used for the delivery
of traffic from a downstream node D to an upstream node U either:
Editors note: This section will be updated based on text supplied by a. D maintains an MPLS-TP LSP back to U which is specifically
the control plane framework draft editors. designated to carry return traffic for the original LSP, or
b. D has some other unspecified means of directing traffic back to
U.
The first option is referred to as an "in-band" return path, the
second as an "out-of-band" return path.
There are various possibilities for "out-of-band" return paths. Such
a path may, for example, be based on ordinary IP routing. In this
case packets would be forwarded as usual to a destination IP address
associated with U. In an MPLS-TP network that is also an IP/MPLS
network, such a forwarding path may traverse the same physical links
or logical transport paths used by MPLS-TP. An out-of-band return
path may also be indirect, via a network management system; or it may
be via one or more other MPLS-TP LSPs.
3.8.2. Point-to-Point Unidirectional LSPs
Case 1 In this situation, either an in-band or out-of-band return
path may be used to deliver traffic from B back to A.
In the in-band case there is in essence an associated
bidirectional LSP between A and B, and the discussion for
such LSPs below applies. It is therefore recommended for
reasons of operational simplicity that point-to-point
unidirectional LSPs be provisioned as associated
bidirectional LSPs (which may also be co-routed) whenever
return traffic from B to A is required. Note that the two
directions of such an LSP may have differing bandwidth
allocations and QoS characteristics.
Case 2 In this case only the out-of-band return path option is
available. However, an additional out-of-band possibility is
worthy of note here: if B is known to have a return path to
A, then Y can arrange to deliver return traffic to A by first
sending it to B along the original LSP. The mechanism by
which B recognises the need for and performs this forwarding
operation is protocol-specific.
Case 3 In this case only the out-of-band return path option is
available. However, if B has a return path to A, then in a
manner analogous to the previous case B can arrange to
deliver return traffic to Y by first sending it to A along
that return path. The mechanism by which A recognises the
need for and performs this forwarding operation is protocol-
specific.
3.8.3. Point-to-Point Associated Bidirectional LSPs
For Case 1, B has a natural in-band return path to A, the use of
which is typically preferred for return traffic, although out-of-band
return paths are also applicable.
For Cases 2 and 3, the considerations are the same as those for
point-to-point unidirectional LSPs.
3.8.4. Point-to-Point Co-Routed Bidirectional LSPs
For all of Cases 1, 2, and 3, a natural in-band return path exists in
the form of the LSP itself, and its use is typically preferred for
return traffic. Out-of-band return paths, however, are also
applicable.
3.9. Control Plane
A distributed dynamic control plane may be used to enable dynamic A distributed dynamic control plane may be used to enable dynamic
service provisioning in an MPLS-TP network. Where the requirements service provisioning in an MPLS-TP network. Where the requirements
specified in [RFC5654] can be met, the MPLS Transport Profile uses specified in [RFC5654] can be met, the MPLS Transport Profile uses
existing standard control plane protocols for LSPs and PWs. existing standard control plane protocols for LSPs and PWs.
Note that a dynamic control plane is not required in an MPLS-TP Note that a dynamic control plane is not required in an MPLS-TP
network. See Section 3.9 for further details on statically network. See Section 3.11 for further details on statically
configured and provisioned MPLS-TP services. configured and provisioned MPLS-TP services.
Figure 15 illustrates the relationship between the MPLS-TP control Figure 13 illustrates the relationship between the MPLS-TP control
plane, the forwarding plane, the management plane, and OAM for point- plane, the forwarding plane, the management plane, and OAM for point-
to-point MPLS-TP LSPs or PWs. to-point MPLS-TP LSPs or PWs.
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| | | |
| Network Management System and/or | | Network Management System and/or |
| | | |
| Control Plane for Point to Point Connections | | Control Plane for Point to Point Connections |
| | | |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
skipping to change at page 34, line 32 skipping to change at page 33, line 32
''''''''''''''''''''''' ''''''''''''''' ''''''''''''''''''''''' ''''''''''''''''''''''' ''''''''''''''' '''''''''''''''''''''''
Note: Note:
1) NMS may be centralised or distributed. Control plane is 1) NMS may be centralised or distributed. Control plane is
distributed. distributed.
2) 'Edge' functions refers to those functions present at 2) 'Edge' functions refers to those functions present at
the edge of a PSN domain, e.g. NSP or classification. the edge of a PSN domain, e.g. NSP or classification.
3) The control plane may be transported over the server 3) The control plane may be transported over the server
layer, an LSP or a G-ACh. layer, an LSP or a G-ACh.
Figure 15: MPLS-TP Control Plane Architecture Context Figure 13: MPLS-TP Control Plane Architecture Context
The MPLS-TP control plane is based on a combination of the LDP-based The MPLS-TP control plane is based on existing MPLS and PW control
control plane for pseudowires [RFC4447] and the RSVP-TE-based control plane protocols. MPLS-TP uses Generalized MPLS (GMPLS) signalling
plane for MPLS-TP LSPs [RFC3471]. Some of the RSVP-TE functions that ([RFC3945], [RFC3471], [RFC3473]) for LSPs and Targetted LDP (T-LDP)
are required for MPLS-TP LSP signaling are based on Generalized MPLS [RFC4447] [I-D.ietf-pwe3-segmented-pw][I-D.ietf-pwe3-dynamic-ms-pw]
(GMPLS) ([RFC3945], [RFC3471], [RFC3473]). for pseudowires. When T-LDP is used as the PW control protocol,
MPLS-TP requires that it is capable of being carried over an out of
band signalling network or a signalling control channel [RFC5718].
References to T-LDP in this document do not preclude the definition
of alternative PW control protocols for use in MPLS-TP.
Note that if MPLS-TP is being used in a multi-layer network, a number
of control protocol types and instances may be used. This is
consistent with the MPLS architecture which permits each label in the
label stack to be allocated and signalled by its own control
protocol.
The distributed MPLS-TP control plane may provide the following The distributed MPLS-TP control plane may provide the following
functions: functions:
o Signaling o Signalling
o Routing o Routing
o Traffic engineering and constraint-based path computation o Traffic engineering and constraint-based path computation
In a multi-domain environment, the MPLS-TP control plane supports In a multi-domain environment, the MPLS-TP control plane supports
different types of interfaces at domain boundaries or within the different types of interfaces at domain boundaries or within the
domains. These include the User-Network Interface (UNI), Internal domains. These include the User-Network Interface (UNI), Internal
Network Node Interface (I-NNI), and External Network Node Interface Network Node Interface (I-NNI), and External Network Node Interface
(E-NNI). Note that different policies may be defined that control (E-NNI). Note that different policies may be defined that control
the information exchanged across these interface types. the information exchanged across these interface types.
The MPLS-TP control plane is capable of activating MPLS-TP OAM The MPLS-TP control plane is capable of activating MPLS-TP OAM
functions as described in the OAM section of this document functions as described in the OAM section of this document
Section 3.7, e.g. for fault detection and localisation in the event Section 3.7, e.g. for fault detection and localisation in the event
of a failure in order to efficiently restore failed transport paths. of a failure in order to efficiently restore failed transport paths.
The MPLS-TP control plane supports all MPLS-TP data plane The MPLS-TP control plane supports all MPLS-TP data plane
connectivity patterns that are needed for establishing transport connectivity patterns that are needed for establishing transport
paths, including protected paths as described in Section 3.10. paths, including protected paths as described in Section 3.12.
Examples of the MPLS-TP data plane connectivity patterns are LSPs Examples of the MPLS-TP data plane connectivity patterns are LSPs
utilising the fast reroute backup methods as defined in [RFC4090] and utilising the fast reroute backup methods as defined in [RFC4090] and
ingress-to-egress 1+1 or 1:1 protected LSPs. ingress-to-egress 1+1 or 1:1 protected LSPs.
The MPLS-TP control plane provides functions to ensure its own The MPLS-TP control plane provides functions to ensure its own
survivability and to enable it to recover gracefully from failures survivability and to enable it to recover gracefully from failures
and degradations. These include graceful restart and hot redundant and degradations. These include graceful restart and hot redundant
configurations. Depending on how the control plane is transported, configurations. Depending on how the control plane is transported,
varying degrees of decoupling between the control plane and data varying degrees of decoupling between the control plane and data
plane may be achieved. plane may be achieved.
3.8.1. PW Control Plane 3.10. Inter-domain Connectivity
An MPLS-TP network provides many of its transport services using A number of methods exist to support inter-domain operation of
single-segment or multi-segment pseudowires, in compliance with the MPLS-TP, for example:
PWE3 architecture ([RFC3985] and [RFC5659]). The setup and
maintenance of single-segment or multi-segment pseudowires uses the
Label Distribution Protocol (LDP) as per [RFC4447] and extensions for
MS-PWs ([I-D.ietf-pwe3-segmented-pw] and
[I-D.ietf-pwe3-dynamic-ms-pw]).
3.8.2. LSP Control Plane o Inter-domain TE LSPs [RFC4216]
MPLS-TP Provider Edge LSRs aggregate multiple pseudowires and carry o Multi-segment Pseudowires [RFC5659]
them across the MPLS-TP network through MPLS-TP tunnels (MPLS-TP
LSPs). Applicable functions from the Generalized MPLS (GMPLS)
([RFC3945]) protocol suite supporting packet-switched capable (PSC)
technologies are used as the control plane for MPLS-TP transport
paths (LSPs).
The LSP control plane includes: o LSP stitching [RFC5150]
o RSVP-TE for signaling o back-to-back ACs [RFC5659]
o OSPF-TE or ISIS-TE for routing An important consideration in selecting an inter-domain connectivity
RSVP-TE signaling in support of GMPLS, as defined in [RFC3473], is mechanism is the degree of layer network isolation and types of OAM
used for the setup, modification, and release of MPLS-TP transport required by the operator. The selection of which technique to use in
paths and protection paths. It supports unidirectional and a particular deployment scenario is outside the scope of this
bidirectional point-to-point LSPs as well as unidirectional point-to-
multipoint LSPs. The architecture for MPLS-TP supporting point-to-
multipoint packet transport services is out of scope of this
document. document.
The route of a transport path is typically calculated in the ingress 3.11. Static Operation of LSPs and PWs
node of a domain and the RSVP explicit route object (ERO) is utilised
for the setup of the transport path exactly following the given
route. GMPLS-based MPLS-TP LSPs must be able to inter-operate with
RSVP-TE-based MPLS-TE LSPs, as per [RFC5146]
OSPF and IS-IS for GMPLS ([RFC4203] and [RFC5307]) are used for
carrying link state routing information in an MPLS-TP network.
3.9. Static Operation of LSPs and PWs
An MPLS-TP LSP or PW may be statically configured without the support
of a dynamic control plane. This may be either by direct
configuration of the LSRs, or via a network management system.
Static operation is independent of a specific PW or LSP instance -
for example it should be possible for a PW to be statically
configured, while the LSP supporting it setup by a dynamic control
plane.
Persistent forwarding loops can cause significant additional resource
utilisation, above that budgeted for the transport path. Therefore,
when static configuration mechanisms are used, care must be taken to
ensure that loops do not form.
3.10. Survivability A PW or LSP may be statically configured without the support of a
dynamic control plane. This may be either by direct configuration of
the PEs/LSRs, or via a network management system. Static operation
is independent for a specific PW or LSP instance. Thus it should be
possible for a PW to be statically configured, while the LSP
supporting it is set up by a dynamic control plane. When static
configuration mechanisms are used, care must be taken to ensure that
loops are not created.
Editors note: This section will be updated based on text supplied by 3.12. Survivability
the survivability draft editors.
Survivability requirements for MPLS-TP are specified in Survivability requirements for MPLS-TP are specified in
[I-D.ietf-mpls-tp-survive-fwk]. [I-D.ietf-mpls-tp-survive-fwk].
A wide variety of resiliency schemes have been developed to meet the A wide variety of resiliency schemes have been developed to meet the
various network and service survivability objectives. For example, various network and service survivability objectives. For example,
as part of the MPLS/PW paradigms, MPLS provides methods for local as part of the MPLS/PW paradigms, MPLS provides methods for local
repair using back-up LSP tunnels ([RFC4090]), while pseudowire repair using back-up LSP tunnels ([RFC4090]), while pseudowire
redundancy [I-D.ietf-pwe3-redundancy] supports scenarios where the redundancy [I-D.ietf-pwe3-redundancy] supports scenarios where the
protection for the PW cannot be fully provided by the PSN layer (i.e. protection for the PW cannot be fully provided by the underlying LSP
where the backup PW terminates on a different target PE node than the (i.e. where the backup PW terminates on a different target PE node
working PW). Additionally, GMPLS provides a well known set of than the working PW in dual homing scenarios, or where protection of
control plane driven protection and restoration mechanisms [RFC4872]. the S-PE is required). Additionally, GMPLS provides a well known set
MPLS-TP provides additional protection mechanisms that are optimised of control plane driven protection and restoration mechanisms
for both linear topologies and ring topologies, and that operate in [RFC4872]. MPLS-TP provides additional protection mechanisms that
the absence of a dynamic control plane. These are specified in are optimised for both linear topologies and ring topologies, and
[I-D.ietf-mpls-tp-survive-fwk]. that operate in the absence of a dynamic control plane. These are
specified in [I-D.ietf-mpls-tp-survive-fwk].
Different protection schemes apply to different deployment topologies Different protection schemes apply to different deployment topologies
and operational considerations. Such protection schemes may provide and operational considerations. Such protection schemes may provide
different levels of resiliency, for example: different levels of resiliency, for example:
o Two concurrent traffic paths (1+1). o Two concurrent traffic paths (1+1).
o one active and one standby path with guaranteed bandwidth on both o one active and one standby path with guaranteed bandwidth on both
paths (1:1). paths (1:1).
skipping to change at page 38, line 5 skipping to change at page 36, line 29
o MPLS-TP recovery mechanisms support the coordination of protection o MPLS-TP recovery mechanisms support the coordination of protection
switching at multiple levels to prevent race conditions occurring switching at multiple levels to prevent race conditions occurring
between a client and its server layer. between a client and its server layer.
o MPLS-TP recovery mechanisms can be data plane, control plane or o MPLS-TP recovery mechanisms can be data plane, control plane or
management plane based. management plane based.
o MPLS-TP supports revertive and non-revertive behaviour. o MPLS-TP supports revertive and non-revertive behaviour.
3.11. Path Segment Tunnels 3.13. Path Segment Tunnels
In order to support the option to monitor, protect and manage a In order to monitor, protect and manage a portion of an LSP, a new
portion of an LSP, a new architectural element is defined, Path architectural element is defined. This the Path Segment Tunnel
Segment Tunnel (PST). A Path Segment Tunnel is an LSP defined and (PST). A PST is an LSP defined and used for the purposes of OAM
used for the purposes of OAM monitoring, protection or management of monitoring, protection or management of LSP segment or concatenated
LSP segment or concatenated LSP segments, and based on MPLS LSP segments, and based on MPLS hierarchical nested LSP defined in
hierarchical nested LSP defined in [RFC3031]. [RFC3031].
A PST is defined between the edges of the portion of the LSP that A PST is defined between the edges of the portion of the LSP that
needs to be monitored, protected or managed. Maintenance messages needs to be monitored, protected or managed. Maintenance messages
can be initiated at the edge of the PST and sent to the peer edge of can be initiated at the edge of the PST and sent to the peer edge of
the PST or to an intermediate point along the PST setting the TTL the PST or to an intermediate point along the PST setting the TTL
value at the PST level accordingly. value at the PST level accordingly.
For example in Figure 16, three PST are configured to allow For example in Figure 14, three PSTs are configured to allow
monitoring, protection and management of the LSP concatenated monitoring, protection and management of the LSP concatenated
segments. One PST is defined between PE1 and PE2, the second between segments. One PST is defined between PE1 and PE2, the second between
PE2 and PE3 and a third PST is set up between PE3 and PE4. Each of PE2 and PE3 and a third PST is set up between PE3 and PE4. Each of
these three PST may be monitored, protected, or managed these three PSTs may be monitored, protected, or managed
independently. independently.
========================== End to End LSP ============================= ========================== End to End LSP =============================
|<--------- Carrier 1 --------->| |<----- Carrier 2 ----->| |<--------- Carrier 1 --------->| |<----- Carrier 2 ----->|
---| PE1 |---| P |---| P |---| PE2 |-------| PE3 |---| P |---| PE4 |--- ---| PE1 |---| P |---| P |---| PE2 |-------| PE3 |---| P |---| PE4 |---
|============= PST =============|==PST==|========= PST =========| |============= PST =============|==PST==|========= PST =========|
(Carrier 1) (Carrier 2) (Carrier 1) (Carrier 2)
Figure 16: PSTs in inter-carrier network Figure 14: PSTs in inter-carrier network
The end-to-end traffic of the LSP, including data-traffic and control The end-to-end traffic of the LSP, including data-traffic and control
traffic (OAM, PSC, management and signaling messages) is tunneled traffic (OAM, Protection Switching Control, management and signalling
within the PST by means of label stacking as defined in [RFC3031]. messages) is tunneled within the PST by means of label stacking as
defined in [RFC3031].
The mapping between an LSP and a PST can be 1:1 which is similar to The mapping between an LSP and a PST can be 1:1, in which it is
the IUT-T Tandem Connection element [G.805] which defines a sub layer similar to the ITU-T Tandem Connection element [G.805]. The mapping
corresponding to a segment of a path and allows the monitoring of can also be 1:N to allow aggregated monitoring, protection and
that segment. The mapping can also be 1:N to allow scalable management of a set of LSP segments or concatenated LSP segments.
monitoring, protection and management of a set of segments or Figure 15 shows a PST which is used to aggregate a set of
concatenated LSP segments traversing the same portion of a network. concatenated LSP segments for the LSP from PEx to PEt and the LSP
Figure 2 shows a PST which is used to aggregate a set of concatenated from PEa to PEd. Note that such a construct is useful, for example,
LSP segments of the following LSPs: LSP from PEx to PEt and LSP from when the LSPs traverse a common portion of the network and they have
PEa to PEd. Note that such a construction may be useful if the LSPs the same Traffic Class.
traverse via a common portion of the network and have the same
constrains, such as the same set of requirements for QoS, etc.
|PEx|--|PEy|-+ +-|PEz|--|PEt| |PEx|--|PEy|-+ +-|PEz|--|PEt|
| | | |
| |<---------- Carrier 1 --------->| | | |<---------- Carrier 1 --------->| |
| +-----+ +---+ +---+ +-----+ | | +-----+ +---+ +---+ +-----+ |
+--| |---| |---| |----| |--+ +--| |---| |---| |----| |--+
| PE1 | | P | | P | | PE2 | | PE1 | | P | | P | | PE2 |
+--| |---| |---| |----| |--+ +--| |---| |---| |----| |--+
| +-----+ +---+ + P + +-----+ | | +-----+ +---+ + P + +-----+ |
| |============= PST ==============| | | |============= PST ==============| |
|PEa|--|PEb|-+ (Carrier 1) +-|PEc|--|PEd| |PEa|--|PEb|-+ (Carrier 1) +-|PEc|--|PEd|
Figure 17: PST for a Set of Concatenated LSP Segments Figure 15: PST for a Set of Concatenated LSP Segments
3.11.1. Provisioning of PST 3.13.1. Provisioning of PST
PSTs can be either provisioned statically or using control plane PSTs can be either provisioned statically or using control plane
signaling procedures. The make-before-break procedures which are signalling procedures. The make-before-break procedures which are
supported by MPLS allow the creation of a PST on existing LSPs in- supported by MPLS allow the creation of a PST on existing LSPs in-
service without traffic disruption. A PST can be defined service without traffic disruption. A PST can be defined
corresponding to one or more end-to-end tunneled LSPs. New end-to- corresponding to one or more end-to-end tunneled LSPs. New end-to-
end LSPs which are tunneled within the PST can be setup. Traffic of end LSPs which are tunneled within the PST can be setup. Traffic of
the existing LSPs is switched over to the new end-to-end tunneled the existing LSPs is switched over to the new end-to-end tunneled
LSPs. The old end-to-end LSPs can be tore down. LSPs. The old end-to-end LSPs can be tore down.
3.12. Network Management 3.14. Pseudowire Segment Tunnels
Pseudowire segment tunnels are for further study.
3.15. Network Management
The network management architecture and requirements for MPLS-TP are The network management architecture and requirements for MPLS-TP are
specified in [I-D.ietf-mpls-tp-nm-framework] and specified in [I-D.ietf-mpls-tp-nm-framework] and
[I-D.ietf-mpls-tp-nm-req]. These derive from the generic [I-D.ietf-mpls-tp-nm-req]. These derive from the generic
specifications described in ITU-T G.7710/Y.1701 [G.7710] for specifications described in ITU-T G.7710/Y.1701 [G.7710] for
transport technologies. It also incorporates the OAM requirements transport technologies. It also incorporates the OAM requirements
for MPLS Networks [RFC4377] and MPLS-TP Networks for MPLS Networks [RFC4377] and MPLS-TP Networks
[I-D.ietf-mpls-tp-oam-requirements] and expands on those requirements [I-D.ietf-mpls-tp-oam-requirements] and expands on those requirements
to cover the modifications necessary for fault, configuration, to cover the modifications necessary for fault, configuration,
performance, and security in a transport network. performance, and security in a transport network.
The Equipment Management Function (EMF) of an MPLS-TP Network Element The Equipment Management Function (EMF) of an MPLS-TP Network Element
(NE) (i.e. LSR, LER, PE, S-PE or T-PE) provides the means through (NE) (i.e. LSR, LER, PE, S-PE or T-PE) provides the means through
which a management system manages the NE. The Management which a management system manages the NE. The Management
Communication Channel (MCC), realised by the G-ACh, provides a Communication Channel (MCC), realised by the G-ACh, provides a
logical operations channel between NEs for transferring Management logical operations channel between NEs for transferring Management
information. For the management interface from a management system information. For the management interface from a management system
to an MPLS-TP NE, there is no restriction on which management to an MPLS-TP NE, there is no restriction on which management
protocol is used. The MCC is used to provision and manage an end-to- protocol is used. The MCC is used to provision and manage an end-to-
end connection across a network where some segments are created/ end connection across a network where some segments are created/
managed by, for example, Netconf or SNMP and other segments by XML or managed by, for example, Netconf [RFC4741] or SNMP [RFC3411] and
CORBA interfaces. Maintenance operations are run on a connection other segments by XML or CORBA interfaces. Maintenance operations
(LSP or PW) in a manner that is independent of the provisioning are run on a connection (LSP or PW) in a manner that is independent
mechanism. An MPLS-TP NE is not required to offer more than one of the provisioning mechanism. An MPLS-TP NE is not required to
standard management interface. In MPLS-TP, the EMF must be capable offer more than one standard management interface. In MPLS-TP, the
of statically provisioning LSPs for an LSR or LER, and PWs for a PE, EMF must be capable of statically provisioning LSPs for an LSR or
as well as any associated MEPs and MIPs, as per Section 3.9. LER, and PWs for a PE, as well as any associated MEPs and MIPs, as
per Section 3.11.
Fault Management (FM) functions within the EMF of an MPLS-TP NE Fault Management (FM) functions within the EMF of an MPLS-TP NE
enable the supervision, detection, validation, isolation, correction, enable the supervision, detection, validation, isolation, correction,
and alarm handling of abnormal conditions in the MPLS-TP network and and alarm handling of abnormal conditions in the MPLS-TP network and
its environment. FM must provide for the supervision of transmission its environment. FM must provide for the supervision of transmission
(such as continuity, connectivity, etc.), software processing, (such as continuity, connectivity, etc.), software processing,
hardware, and environment. Alarm handling includes alarm severity hardware, and environment. Alarm handling includes alarm severity
assignment, alarm suppression/aggregation/correlation, alarm assignment, alarm suppression/aggregation/correlation, alarm
reporting control, and alarm reporting. reporting control, and alarm reporting.
skipping to change at page 41, line 14 skipping to change at page 39, line 44
considerations of that additional functionality also apply. considerations of that additional functionality also apply.
For pseudowires, the security considerations of [RFC3985] and For pseudowires, the security considerations of [RFC3985] and
[RFC5659] apply. [RFC5659] apply.
Packets that arrive on an interface with a given label value should Packets that arrive on an interface with a given label value should
not be forwarded unless that label value is assigned to an LSP or PW not be forwarded unless that label value is assigned to an LSP or PW
to a peer LSR or PE that is reachable via that interface. to a peer LSR or PE that is reachable via that interface.
Each MPLS-TP solution must specify the additional security Each MPLS-TP solution must specify the additional security
considerations that apply. considerations that apply. This is discussed further in
[I-D.fang-mpls-tp-security-framework].
5. IANA Considerations 5. IANA Considerations
IANA considerations resulting from specific elements of MPLS-TP IANA considerations resulting from specific elements of MPLS-TP
functionality will be detailed in the documents specifying that functionality will be detailed in the documents specifying that
functionality. functionality.
This document introduces no additional IANA considerations in itself. This document introduces no additional IANA considerations in itself.
6. Acknowledgements 6. Acknowledgements
skipping to change at page 42, line 4 skipping to change at page 40, line 33
o Marc Lasserre o Marc Lasserre
o Vincenzo Sestito o Vincenzo Sestito
o Nurit Sprecher o Nurit Sprecher
o Martin Vigoureux o Martin Vigoureux
o Yaacov Weingarten o Yaacov Weingarten
o The participants of ITU-T SG15 o The participants of ITU-T SG15
7. Open Issues 7. Open Issues
This section contains a list of issues that must be resolved before This section contains a list of issues that must be resolved before
last call. last call.
o There is some text missing from the network layer clients section. o
Text is invited covering the use of out of band signaling
associated with the AC.
o Need text to address how the LSR next hop MAC address is
determined for Ethernet link layers when no IP (i.e. ARP) is
available. If statically configured, what is the default? 181209:
this will be addressed in the normative data plane draft
o Need to add section (Appendix) describing stack optizations for
LSP and PWs
o Add a section clarify what options are used for interdomain
operation e.g. inter-AS TE LSPs, MS-PW, LSP stitching, back-to-
back ACs
o Text reduction for the OAM, survivability and NM sections.
o Include summarised PST text
8. References 8. References
8.1. Normative References 8.1. Normative References
[G.7710] "ITU-T Recommendation [G.7710] "ITU-T Recommendation
G.7710/Y.1701 (07/07), G.7710/Y.1701 (07/07),
"Common equipment "Common equipment
management function management function
requirements"", 2005. requirements"", 2005.
skipping to change at page 43, line 49 skipping to change at page 42, line 12
Edge-to-Edge (PWE3) Edge-to-Edge (PWE3)
Architecture", RFC 3985, Architecture", RFC 3985,
March 2005. March 2005.
[RFC4090] Pan, P., Swallow, G., and [RFC4090] Pan, P., Swallow, G., and
A. Atlas, "Fast Reroute A. Atlas, "Fast Reroute
Extensions to RSVP-TE for Extensions to RSVP-TE for
LSP Tunnels", RFC 4090, LSP Tunnels", RFC 4090,
May 2005. May 2005.
[RFC4203] Kompella, K. and Y.
Rekhter, "OSPF Extensions
in Support of Generalized
Multi-Protocol Label
Switching (GMPLS)",
RFC 4203, October 2005.
[RFC4385] Bryant, S., Swallow, G., [RFC4385] Bryant, S., Swallow, G.,
Martini, L., and D. Martini, L., and D.
McPherson, "Pseudowire McPherson, "Pseudowire
Emulation Edge-to-Edge Emulation Edge-to-Edge
(PWE3) Control Word for Use (PWE3) Control Word for Use
over an MPLS PSN", over an MPLS PSN",
RFC 4385, February 2006. RFC 4385, February 2006.
[RFC4447] Martini, L., Rosen, E., El- [RFC4447] Martini, L., Rosen, E., El-
Aawar, N., Smith, T., and Aawar, N., Smith, T., and
skipping to change at page 44, line 40 skipping to change at page 42, line 45
May 2007. May 2007.
[RFC5085] Nadeau, T. and C. [RFC5085] Nadeau, T. and C.
Pignataro, "Pseudowire Pignataro, "Pseudowire
Virtual Circuit Virtual Circuit
Connectivity Verification Connectivity Verification
(VCCV): A Control Channel (VCCV): A Control Channel
for Pseudowires", RFC 5085, for Pseudowires", RFC 5085,
December 2007. December 2007.
[RFC5307] Kompella, K. and Y.
Rekhter, "IS-IS Extensions
in Support of Generalized
Multi-Protocol Label
Switching (GMPLS)",
RFC 5307, October 2008.
[RFC5462] Andersson, L. and R. Asati, [RFC5462] Andersson, L. and R. Asati,
"Multiprotocol Label "Multiprotocol Label
Switching (MPLS) Label Switching (MPLS) Label
Stack Entry: "EXP" Field Stack Entry: "EXP" Field
Renamed to "Traffic Class" Renamed to "Traffic Class"
Field", RFC 5462, Field", RFC 5462,
February 2009. February 2009.
[RFC5586] Bocci, M., Vigoureux, M., [RFC5586] Bocci, M., Vigoureux, M.,
and S. Bryant, "MPLS and S. Bryant, "MPLS
Generic Associated Generic Associated
Channel", RFC 5586, Channel", RFC 5586,
June 2009. June 2009.
8.2. Informative References 8.2. Informative References
[I-D.fang-mpls-tp-security-framework] Fang, L. and B. Niven-
Jenkins, "Security
Framework for MPLS-TP", dra
ft-fang-mpls-tp-security-
framework-00 (work in
progress), July 2009.
[I-D.ietf-bfd-mpls] Aggarwal, R., Kompella, K., [I-D.ietf-bfd-mpls] Aggarwal, R., Kompella, K.,
Nadeau, T., and G. Swallow, Nadeau, T., and G. Swallow,
"BFD For MPLS LSPs", "BFD For MPLS LSPs",
draft-ietf-bfd-mpls-07 draft-ietf-bfd-mpls-07
(work in progress), (work in progress),
June 2008. June 2008.
[I-D.ietf-l2vpn-vpms-frmwk-requirements] Kamite, Y., JOUNAY, F., [I-D.ietf-l2vpn-vpms-frmwk-requirements] Kamite, Y., JOUNAY, F.,
Niven-Jenkins, B., Niven-Jenkins, B.,
Brungard, D., and L. Jin, Brungard, D., and L. Jin,
skipping to change at page 47, line 8 skipping to change at page 45, line 13
progress), October 2009. progress), October 2009.
[I-D.ietf-pwe3-segmented-pw] Martini, L., Nadeau, T., [I-D.ietf-pwe3-segmented-pw] Martini, L., Nadeau, T.,
Metz, C., Duckett, M., Metz, C., Duckett, M.,
Bocci, M., Balus, F., and Bocci, M., Balus, F., and
M. Aissaoui, "Segmented M. Aissaoui, "Segmented
Pseudowire", draft-ietf- Pseudowire", draft-ietf-
pwe3-segmented-pw-13 (work pwe3-segmented-pw-13 (work
in progress), August 2009. in progress), August 2009.
[RFC3209] Awduche, D., Berger, L.,
Gan, D., Li, T.,
Srinivasan, V., and G.
Swallow, "RSVP-TE:
Extensions to RSVP for LSP
Tunnels", RFC 3209,
December 2001.
[RFC3411] Harrington, D., Presuhn,
R., and B. Wijnen, "An
Architecture for Describing
Simple Network Management
Protocol (SNMP) Management
Frameworks", STD 62,
RFC 3411, December 2002.
[RFC3443] Agarwal, P. and B. Akyol, [RFC3443] Agarwal, P. and B. Akyol,
"Time To Live (TTL) "Time To Live (TTL)
Processing in Multi- Processing in Multi-
Protocol Label Switching Protocol Label Switching
(MPLS) Networks", RFC 3443, (MPLS) Networks", RFC 3443,
January 2003. January 2003.
[RFC3945] Mannie, E., "Generalized [RFC3945] Mannie, E., "Generalized
Multi-Protocol Label Multi-Protocol Label
Switching (GMPLS) Switching (GMPLS)
Architecture", RFC 3945, Architecture", RFC 3945,
October 2004. October 2004.
[RFC4216] Zhang, R. and J. Vasseur,
"MPLS Inter-Autonomous
System (AS) Traffic
Engineering (TE)
Requirements", RFC 4216,
November 2005.
[RFC4364] Rosen, E. and Y. Rekhter,
"BGP/MPLS IP Virtual
Private Networks (VPNs)",
RFC 4364, February 2006.
[RFC4377] Nadeau, T., Morrow, M., [RFC4377] Nadeau, T., Morrow, M.,
Swallow, G., Allan, D., and Swallow, G., Allan, D., and
S. Matsushima, "Operations S. Matsushima, "Operations
and Management (OAM) and Management (OAM)
Requirements for Multi- Requirements for Multi-
Protocol Label Switched Protocol Label Switched
(MPLS) Networks", RFC 4377, (MPLS) Networks", RFC 4377,
February 2006. February 2006.
[RFC4379] Kompella, K. and G. [RFC4379] Kompella, K. and G.
skipping to change at page 47, line 43 skipping to change at page 46, line 27
(MPLS) Data Plane (MPLS) Data Plane
Failures", RFC 4379, Failures", RFC 4379,
February 2006. February 2006.
[RFC4664] Andersson, L. and E. Rosen, [RFC4664] Andersson, L. and E. Rosen,
"Framework for Layer 2 "Framework for Layer 2
Virtual Private Networks Virtual Private Networks
(L2VPNs)", RFC 4664, (L2VPNs)", RFC 4664,
September 2006. September 2006.
[RFC5146] Kumaki, K., "Interworking [RFC4741] Enns, R., "NETCONF
Requirements to Support Configuration Protocol",
Operation of MPLS-TE over RFC 4741, December 2006.
GMPLS Networks", RFC 5146,
March 2008. [RFC5150] Ayyangar, A., Kompella, K.,
Vasseur, JP., and A.
Farrel, "Label Switched
Path Stitching with
Generalized Multiprotocol
Label Switching Traffic
Engineering (GMPLS TE)",
RFC 5150, February 2008.
[RFC5254] Bitar, N., Bocci, M., and [RFC5254] Bitar, N., Bocci, M., and
L. Martini, "Requirements L. Martini, "Requirements
for Multi-Segment for Multi-Segment
Pseudowire Emulation Edge- Pseudowire Emulation Edge-
to-Edge (PWE3)", RFC 5254, to-Edge (PWE3)", RFC 5254,
October 2008. October 2008.
[RFC5309] Shen, N. and A. Zinin, [RFC5309] Shen, N. and A. Zinin,
"Point-to-Point Operation "Point-to-Point Operation
skipping to change at page 48, line 34 skipping to change at page 47, line 25
"Requirements of an MPLS "Requirements of an MPLS
Transport Profile", Transport Profile",
RFC 5654, September 2009. RFC 5654, September 2009.
[RFC5659] Bocci, M. and S. Bryant, [RFC5659] Bocci, M. and S. Bryant,
"An Architecture for Multi- "An Architecture for Multi-
Segment Pseudowire Segment Pseudowire
Emulation Edge-to-Edge", Emulation Edge-to-Edge",
RFC 5659, October 2009. RFC 5659, October 2009.
[RFC5718] Beller, D. and A. Farrel,
"An In-Band Data
Communication Network For
the MPLS Transport
Profile", RFC 5718,
January 2010.
Authors' Addresses Authors' Addresses
Matthew Bocci (editor) Matthew Bocci (editor)
Alcatel-Lucent Alcatel-Lucent
Voyager Place, Shoppenhangers Road Voyager Place, Shoppenhangers Road
Maidenhead, Berks SL6 2PJ Maidenhead, Berks SL6 2PJ
United Kingdom United Kingdom
Phone: Phone:
EMail: matthew.bocci@alcatel-lucent.com EMail: matthew.bocci@alcatel-lucent.com
 End of changes. 95 change blocks. 
339 lines changed or deleted 379 lines changed or added

This html diff was produced by rfcdiff 1.37c. The latest version is available from http://tools.ietf.org/tools/rfcdiff/