summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5921.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5921.txt')
-rw-r--r--doc/rfc/rfc5921.txt3139
1 files changed, 3139 insertions, 0 deletions
diff --git a/doc/rfc/rfc5921.txt b/doc/rfc/rfc5921.txt
new file mode 100644
index 0000000..eaf69dd
--- /dev/null
+++ b/doc/rfc/rfc5921.txt
@@ -0,0 +1,3139 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Bocci, Ed.
+Request for Comments: 5921 Alcatel-Lucent
+Category: Informational S. Bryant, Ed.
+ISSN: 2070-1721 D. Frost, Ed.
+ Cisco Systems
+ L. Levrau
+ Alcatel-Lucent
+ L. Berger
+ LabN
+ July 2010
+
+
+ A Framework for MPLS in Transport Networks
+
+Abstract
+
+ This document specifies an architectural framework for the
+ application of Multiprotocol Label Switching (MPLS) to the
+ construction of packet-switched transport networks. It describes a
+ common set of protocol functions -- the MPLS Transport Profile (MPLS-
+ TP) -- that supports the operational models and capabilities typical
+ of such networks, including signaled or explicitly provisioned
+ bidirectional connection-oriented paths, protection and restoration
+ mechanisms, comprehensive Operations, Administration, and Maintenance
+ (OAM) functions, and network operation in the absence of a dynamic
+ control plane or IP forwarding support. Some of these functions are
+ defined in existing MPLS specifications, while others require
+ extensions to existing specifications to meet the requirements of the
+ MPLS-TP.
+
+ This document defines the subset of the MPLS-TP applicable in general
+ and to point-to-point transport paths. The remaining subset,
+ applicable specifically to point-to-multipoint transport paths, is
+ outside the scope of this document.
+
+ This document is a product of a joint Internet Engineering Task Force
+ (IETF) / International Telecommunication Union Telecommunication
+ Standardization Sector (ITU-T) effort to include an MPLS Transport
+ Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
+ (PWE3) architectures to support the capabilities and functionalities
+ of a packet transport network as defined by the ITU-T.
+
+
+
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 1]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc5921.
+
+Copyright Notice
+
+ Copyright (c) 2010 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 2]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. Motivation and Background . . . . . . . . . . . . . . . . 4
+ 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.3.1. Transport Network . . . . . . . . . . . . . . . . . . 7
+ 1.3.2. MPLS Transport Profile . . . . . . . . . . . . . . . . 7
+ 1.3.3. MPLS-TP Section . . . . . . . . . . . . . . . . . . . 7
+ 1.3.4. MPLS-TP Label Switched Path . . . . . . . . . . . . . 7
+ 1.3.5. MPLS-TP Label Switching Router . . . . . . . . . . . . 8
+ 1.3.6. Customer Edge (CE) . . . . . . . . . . . . . . . . . . 10
+ 1.3.7. Transport LSP . . . . . . . . . . . . . . . . . . . . 10
+ 1.3.8. Service LSP . . . . . . . . . . . . . . . . . . . . . 10
+ 1.3.9. Layer Network . . . . . . . . . . . . . . . . . . . . 10
+ 1.3.10. Network Layer . . . . . . . . . . . . . . . . . . . . 10
+ 1.3.11. Service Interface . . . . . . . . . . . . . . . . . . 10
+ 1.3.12. Native Service . . . . . . . . . . . . . . . . . . . . 11
+ 1.3.13. Additional Definitions and Terminology . . . . . . . . 11
+ 2. MPLS Transport Profile Requirements . . . . . . . . . . . . . 11
+ 3. MPLS Transport Profile Overview . . . . . . . . . . . . . . . 12
+ 3.1. Packet Transport Services . . . . . . . . . . . . . . . . 12
+ 3.2. Scope of the MPLS Transport Profile . . . . . . . . . . . 13
+ 3.3. Architecture . . . . . . . . . . . . . . . . . . . . . . . 14
+ 3.3.1. MPLS-TP Native Service Adaptation Functions . . . . . 14
+ 3.3.2. MPLS-TP Forwarding Functions . . . . . . . . . . . . . 15
+ 3.4. MPLS-TP Native Service Adaptation . . . . . . . . . . . . 16
+ 3.4.1. MPLS-TP Client/Server Layer Relationship . . . . . . . 16
+ 3.4.2. MPLS-TP Transport Layers . . . . . . . . . . . . . . . 17
+ 3.4.3. MPLS-TP Transport Service Interfaces . . . . . . . . . 18
+ 3.4.4. Pseudowire Adaptation . . . . . . . . . . . . . . . . 25
+ 3.4.5. Network Layer Adaptation . . . . . . . . . . . . . . . 28
+ 3.5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 33
+ 3.6. Generic Associated Channel (G-ACh) . . . . . . . . . . . . 33
+ 3.7. Operations, Administration, and Maintenance (OAM) . . . . 36
+ 3.8. Return Path . . . . . . . . . . . . . . . . . . . . . . . 38
+ 3.8.1. Return Path Types . . . . . . . . . . . . . . . . . . 39
+ 3.8.2. Point-to-Point Unidirectional LSPs . . . . . . . . . . 39
+ 3.8.3. Point-to-Point Associated Bidirectional LSPs . . . . . 40
+ 3.8.4. Point-to-Point Co-Routed Bidirectional LSPs . . . . . 40
+ 3.9. Control Plane . . . . . . . . . . . . . . . . . . . . . . 40
+ 3.10. Inter-Domain Connectivity . . . . . . . . . . . . . . . . 43
+ 3.11. Static Operation of LSPs and PWs . . . . . . . . . . . . . 43
+ 3.12. Survivability . . . . . . . . . . . . . . . . . . . . . . 44
+ 3.13. Sub-Path Maintenance . . . . . . . . . . . . . . . . . . . 45
+ 3.14. Network Management . . . . . . . . . . . . . . . . . . . . 47
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . 48
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
+
+
+
+Bocci, et al. Informational [Page 3]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 50
+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 51
+
+1. Introduction
+
+1.1. Motivation and Background
+
+ This document describes an architectural framework for the
+ application of MPLS to the construction of packet-switched transport
+ networks. It specifies the common set of protocol functions that
+ meet the requirements in [RFC5654], and that together constitute the
+ MPLS Transport Profile (MPLS-TP) for point-to-point transport paths.
+ The remaining MPLS-TP functions, applicable specifically to point-to-
+ multipoint transport paths, are outside the scope of this document.
+
+ Historically, the optical transport infrastructure -- Synchronous
+ Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical
+ Transport Network (OTN) -- has provided carriers with a high
+ benchmark for reliability and operational simplicity. To achieve
+ this, transport technologies have been designed with specific
+ characteristics:
+
+ o Strictly connection-oriented connectivity, which may be long-lived
+ and may be provisioned manually, for example, by network
+ management systems or direct node configuration using a command
+ line interface.
+
+ o A high level of availability.
+
+ o Quality of service.
+
+ o Extensive Operations, Administration, and Maintenance (OAM)
+ capabilities.
+
+ Carriers wish to evolve such transport networks to take advantage of
+ the flexibility and cost benefits of packet switching technology and
+ to support packet-based services more efficiently. While MPLS is a
+ maturing packet technology that already plays an important role in
+ transport networks and services, not all MPLS capabilities and
+ mechanisms are needed in, or consistent with, the transport network
+ operational model. There are also transport technology
+ characteristics that are not currently reflected in MPLS.
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 4]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ There are thus two objectives for MPLS-TP:
+
+ 1. To enable MPLS to be deployed in a transport network and operated
+ in a similar manner to existing transport technologies.
+
+ 2. To enable MPLS to support packet transport services with a
+ similar degree of predictability to that found in existing
+ transport networks.
+
+ In order to achieve these objectives, there is a need to define a
+ common set of MPLS protocol functions -- an MPLS Transport Profile --
+ for the use of MPLS in transport networks and applications. Some of
+ the necessary functions are provided by existing MPLS specifications,
+ while others require additions to the MPLS tool-set. Such additions
+ should, wherever possible, be applicable to MPLS networks in general
+ as well as those that conform strictly to the transport network
+ model.
+
+ This document is a product of a joint Internet Engineering Task Force
+ (IETF) / International Telecommunication Union Telecommunication
+ Standardization Sector (ITU-T) effort to include an MPLS Transport
+ Profile within the IETF MPLS and PWE3 architectures to support the
+ capabilities and functionalities of a packet transport network as
+ defined by the ITU-T.
+
+1.2. Scope
+
+ This document describes an architectural framework for the
+ application of MPLS to the construction of packet-switched transport
+ networks. It specifies the common set of protocol functions that
+ meet the requirements in [RFC5654], and that together constitute the
+ MPLS Transport Profile (MPLS-TP) for point-to-point MPLS-TP transport
+ paths. The remaining MPLS-TP functions, applicable specifically to
+ point-to-multipoint transport paths, are outside the scope of this
+ document.
+
+1.3. Terminology
+
+ Term Definition
+ ---------- ----------------------------------------------------------
+ AC Attachment Circuit
+ ACH Associated Channel Header
+ Adaptation The mapping of client information into a format suitable
+ for transport by the server layer
+ APS Automatic Protection Switching
+ ATM Asynchronous Transfer Mode
+ BFD Bidirectional Forwarding Detection
+ CE Customer Edge
+
+
+
+Bocci, et al. Informational [Page 5]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ CL-PS Connectionless - Packet Switched
+ CM Configuration Management
+ CO-CS Connection Oriented - Circuit Switched
+ CO-PS Connection Oriented - Packet Switched
+ DCN Data Communication Network
+ EMF Equipment Management Function
+ FCAPS Fault, Configuration, Accounting, Performance, and
+ Security
+ FM Fault Management
+ G-ACh Generic Associated Channel
+ GAL G-ACh Label
+ LER Label Edge Router
+ LSP Label Switched Path
+ LSR Label Switching Router
+ MAC Media Access Control
+ MCC Management Communication Channel
+ ME Maintenance Entity
+ MEG Maintenance Entity Group
+ MEP Maintenance Entity Group End Point
+ MIP Maintenance Entity Group Intermediate Point
+ MPLS Multiprotocol Label Switching
+ MPLS-TP MPLS Transport Profile
+ MPLS-TP P MPLS-TP Provider LSR
+ MPLS-TP PE MPLS-TP Provider Edge LSR
+ MS-PW Multi-Segment Pseudowire
+ Native The traffic belonging to the client of the MPLS-TP network
+ Service
+ OAM Operations, Administration, and Maintenance (see
+ [OAM-DEF])
+ OSI Open Systems Interconnection
+ OTN Optical Transport Network
+ PDU Protocol Data Unit
+ PM Performance Monitoring
+ PSN Packet Switching Network
+ PW Pseudowire
+ SCC Signaling Communication Channel
+ SDH Synchronous Digital Hierarchy
+ S-PE PW Switching Provider Edge
+ SPME Sub-Path Maintenance Element
+ SS-PW Single-Segment Pseudowire
+ T-PE PW Terminating Provider Edge
+ TE LSP Traffic Engineered Label Switched Path
+ VCCV Virtual Circuit Connectivity Verification
+
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 6]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+1.3.1. Transport Network
+
+ A Transport Network provides transparent transmission of user traffic
+ between attached client devices by establishing and maintaining
+ point-to-point or point-to-multipoint connections between such
+ devices. The architecture of networks supporting point-to-multipoint
+ connections is outside the scope of this document. A Transport
+ Network is independent of any higher-layer network that may exist
+ between clients, except to the extent required to supply this
+ transmission service. In addition to client traffic, a Transport
+ Network may carry traffic to facilitate its own operation, such as
+ that required to support connection control, network management, and
+ Operations, Administration, and Maintenance (OAM) functions.
+
+ See also the definition of packet transport service in Section 3.1.
+
+1.3.2. MPLS Transport Profile
+
+ The MPLS Transport Profile (MPLS-TP) is the subset of MPLS functions
+ that meet the requirements in [RFC5654]. Note that MPLS is defined
+ to include any present and future MPLS capability specified by the
+ IETF, including those capabilities specifically added to support
+ transport network requirements [RFC5654].
+
+1.3.3. MPLS-TP Section
+
+ MPLS-TP sections are defined in [DATA-PLANE]. See also the
+ definition of "section layer network" in Section 1.2.2 of [RFC5654].
+
+1.3.4. MPLS-TP Label Switched Path
+
+ An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP that uses a
+ subset of the capabilities of an MPLS LSP in order to meet the
+ requirements of an MPLS transport network as set out in [RFC5654].
+ The characteristics of an MPLS-TP LSP are primarily that it:
+
+ 1. Uses a subset of the MPLS OAM tools defined in [OAM-FRAMEWORK].
+
+ 2. Supports 1+1, 1:1, and 1:N protection functions.
+
+ 3. Is traffic engineered.
+
+ 4. May be established and maintained via the management plane, or
+ using GMPLS protocols when a control plane is used.
+
+ 5. Is either point-to-point or point-to-multipoint. Multipoint-to-
+ point and multipoint-to-multipoint LSPs are not supported.
+
+
+
+
+Bocci, et al. Informational [Page 7]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ 6. It is either unidirectional, associated bidirectional, or co-
+ routed bidirectional (i.e., the forward and reverse components of
+ a bidirectional LSP follow the same path, and the intermediate
+ nodes are aware of their association). These are further defined
+ in [DATA-PLANE].
+
+ Note that an MPLS LSP is defined to include any present and future
+ MPLS capability, including those specifically added to support the
+ transport network requirements.
+
+ See [DATA-PLANE] for further details on the types and data-plane
+ properties of MPLS-TP LSPs.
+
+ The lowest server layer provided by MPLS-TP is an MPLS-TP LSP. The
+ client layers of an MPLS-TP LSP may be network-layer protocols, MPLS
+ LSPs, or PWs. The relationship of an MPLS-TP LSP to its client
+ layers is described in detail in Section 3.4.
+
+1.3.5. MPLS-TP Label Switching Router
+
+ 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,
+ 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
+ these roles on a given LSP.
+
+ Note that the use of the term "router" in this context is historic
+ and neither requires nor precludes the ability to perform IP
+ forwarding.
+
+1.3.5.1. Label Edge Router
+
+ An MPLS-TP Label Edge Router (LER) is an LSR that exists at the
+ endpoints of an LSP and therefore pushes or pops the LSP label, i.e.,
+ does not perform a label swap on the particular LSP under
+ consideration.
+
+1.3.5.2. MPLS-TP Provider Edge Router
+
+ 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
+ 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
+ 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] (see
+ below). A PE that pushes or pops an LSP label is an LER for that
+ LSP.
+
+
+
+
+Bocci, et al. Informational [Page 8]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ The term Provider Edge refers to the node's role within a provider's
+ network. A provider edge router resides at the edge of a given
+ MPLS-TP network domain, in which case it has links to another MPLS-TP
+ network domain or to a CE, except for the case of a pseudowire
+ switching provider edge (S-PE) router, which is not restricted to the
+ edge of an MPLS-TP network domain.
+
+1.3.5.3. MPLS-TP Provider Router
+
+ 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
+ switches LSPs that carry client traffic, but does not adapt client
+ traffic and encapsulate it to be carried over an MPLS-TP LSP. The
+ term Provider Router refers to the node's role within a provider's
+ network. A provider router does not have links to other MPLS-TP
+ network domains.
+
+1.3.5.4. Pseudowire Switching Provider Edge Router (S-PE)
+
+ RFC 5659 [RFC5659] defines an S-PE as:
+
+ A PE capable of switching the control and data planes of the
+ preceding and succeeding PW segments in an MS-PW. The S-PE
+ terminates the PSN tunnels of the preceding and succeeding
+ segments of the MS-PW. It therefore includes a PW switching point
+ for an MS-PW. A PW switching point is never the S-PE and the T-PE
+ for the same MS-PW. A PW switching point runs necessary protocols
+ to set up and manage PW segments with other PW switching points
+ and terminating PEs. An S-PE can exist anywhere a PW must be
+ processed or policy applied. It is therefore not limited to the
+ edge of a provider network.
+
+ Note that it was originally anticipated that S-PEs would only be
+ deployed at the edge of a provider network where they would be
+ used to switch the PWs of different service providers. However,
+ as the design of MS-PW progressed, other applications for MS-PW
+ were recognized. By this time S-PE had become the accepted term
+ for the equipment, even though they were no longer universally
+ deployed at the provider edge.
+
+1.3.5.5. Pseudowire Terminating Provider Edge (T-PE) Router
+
+ RFC 5659 [RFC5659] defines a T-PE as:
+
+ A PE where the customer-facing attachment circuits (ACs) are bound
+ to a PW forwarder. A terminating PE is present in the first and
+ last segments of an MS-PW. This incorporates the functionality of
+ a PE as defined in RFC 3985.
+
+
+
+Bocci, et al. Informational [Page 9]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+1.3.6. Customer Edge (CE)
+
+ A Customer Edge (CE) is the client function that sources or sinks
+ 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
+ a single link.
+
+1.3.7. Transport LSP
+
+ A Transport LSP is an LSP between a pair of PEs that may transit zero
+ or more MPLS-TP provider routers. When carrying PWs, the Transport
+ LSP is equivalent to the PSN tunnel LSP in [RFC3985] terminology.
+
+1.3.8. Service LSP
+
+ A service LSP is an LSP that carries a single client service.
+
+1.3.9. Layer Network
+
+ A layer network is defined in [G.805] and described in [RFC5654]. A
+ layer network provides for the transfer of client information and
+ independent operation of the client OAM. A layer network may be
+ described in a service context as follows: one layer network may
+ provide a (transport) service to a higher client layer network and
+ may, in turn, be a client to a lower-layer network. A layer network
+ is a logical construction somewhat independent of arrangement or
+ composition of physical network elements. A particular physical
+ network element may topologically belong to more than one layer
+ network, depending on the actions it takes on the encapsulation
+ associated with the logical layers (e.g., the label stack), and thus
+ could be modeled as multiple logical elements. A layer network may
+ consist of one or more sublayers.
+
+1.3.10. Network Layer
+
+ This document uses the term Network Layer in the same sense as it is
+ used in [RFC3031] and [RFC3032]. Network-layer protocols are
+ synonymous with those belonging to Layer 3 of the Open System
+ Interconnect (OSI) network model [X.200].
+
+1.3.11. Service Interface
+
+ The packet transport service provided by MPLS-TP is provided at a
+ service interface. Two types of service interfaces are defined:
+
+ o User-Network Interface (UNI) (see Section 3.4.3.1).
+
+ o Network-Network Interface (NNI) (see Section 3.4.3.2).
+
+
+
+Bocci, et al. Informational [Page 10]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ A UNI service interface may be a Layer 2 interface that carries only
+ network layer clients. MPLS-TP LSPs are both necessary and
+ sufficient to support this service interface as described in
+ Section 3.4.3. Alternatively, it may be a Layer 2 interface that
+ carries both network-layer and non-network-layer clients. To support
+ this service interface, a PW is required to adapt the client traffic
+ received over the service interface. This PW in turn is a client of
+ the MPLS-TP server layer. This is described in Section 3.4.2.
+
+ An NNI service interface may be to an MPLS LSP or a PW. To support
+ this case, an MPLS-TP PE participates in the service interface
+ signaling.
+
+1.3.12. Native Service
+
+ The native service is the client layer network service that is
+ transported by the MPLS-TP network, whether a pseudowire or an LSP is
+ used for the adaptation (see Section 3.4).
+
+1.3.13. Additional Definitions and Terminology
+
+ Detailed definitions and additional terminology may be found in
+ [RFC5654] and [ROSETTA-STONE].
+
+2. MPLS Transport Profile Requirements
+
+ The requirements for MPLS-TP are specified in [RFC5654], [RFC5860],
+ and [NM-REQ]. This section provides a brief reminder to guide the
+ reader. It is not normative or intended as a substitute for these
+ documents.
+
+ MPLS-TP must not modify the MPLS forwarding architecture and must be
+ based on existing pseudowire and LSP constructs.
+
+ Point-to-point LSPs may be unidirectional or bidirectional, and it
+ must be possible to construct congruent bidirectional LSPs.
+
+ 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.
+
+ 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
+ LSPs and/or pseudowires both in the absence or presence of a dynamic
+ control plane. When static provisioning is used, there must be no
+ dependency on dynamic routing or signaling.
+
+ OAM and protection mechanisms, and forwarding of data packets, must
+ be able to operate without IP forwarding support.
+
+
+
+Bocci, et al. Informational [Page 11]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ 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
+ case, information gained from the OAM functions is used to initiate
+ path recovery actions at either the PW or LSP layers.
+
+3. MPLS Transport Profile Overview
+
+3.1. Packet Transport Services
+
+ One objective of MPLS-TP is to enable MPLS networks to provide packet
+ transport services with a similar degree of predictability to that
+ found in existing transport networks. Such packet transport services
+ exhibit a number of characteristics, defined in [RFC5654]:
+
+ o In an environment where an MPLS-TP layer network is supporting a
+ client layer network, and the MPLS-TP layer network is supported
+ by a server layer network then operation of the MPLS-TP layer
+ network must be possible without any dependencies on either the
+ server or client layer network.
+
+ o The service provided by the MPLS-TP network to a given client will
+ not fall below the agreed level as a result of the traffic loading
+ of other clients.
+
+ o The control and management planes of any client network layer that
+ uses the service is isolated from the control and management
+ planes of the MPLS-TP layer network, where the client network
+ layer is considered to be the native service of the MPLS-TP
+ network.
+
+ o Where a client network makes use of an MPLS-TP server that
+ provides a packet transport service, the level of coordination
+ required between the client and server layer networks is minimal
+ (preferably no coordination will be required).
+
+ o The complete set of packets generated by a client MPLS(-TP) layer
+ network using the packet transport service, which may contain
+ packets that are not MPLS packets (e.g., IP or CLNS
+ (Connectionless Network Service) packets used by the control/
+ management plane of the client MPLS(-TP) layer network), are
+ transported by the MPLS-TP server layer network.
+
+ o The packet transport service enables the MPLS-TP layer network
+ addressing and other information (e.g., topology) to be hidden
+ from any client layer networks using that service, and vice-versa.
+
+
+
+
+
+
+Bocci, et al. Informational [Page 12]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ These characteristics imply that a packet transport service does not
+ support a connectionless packet-switched forwarding mode. However,
+ this does not preclude it carrying client traffic associated with a
+ connectionless service.
+
+3.2. Scope of the MPLS Transport Profile
+
+ Figure 1 illustrates the scope of MPLS-TP. MPLS-TP solutions are
+ primarily intended for packet transport applications. MPLS-TP is a
+ strict subset of MPLS, and comprises only those functions that are
+ necessary to meet the requirements of [RFC5654]. This includes MPLS
+ functions that were defined prior to [RFC5654] but that meet the
+ requirements of [RFC5654], together with additional functions defined
+ to meet those requirements. Some MPLS functions defined before
+ [RFC5654] such as Equal Cost Multi-Path (ECMP), LDP signaling when
+ used in such a way that it creates multipoint-to-point LSPs, and IP
+ forwarding in the data plane are explicitly excluded from MPLS-TP by
+ that requirements specification.
+
+ Note that MPLS as a whole will continue to evolve to include
+ additional functions that do not conform to the MPLS Transport
+ Profile or its requirements, and thus fall outside the scope of
+ MPLS-TP.
+
+ |<============================== MPLS ==============================>|
+ { Post-RFC5654 }
+ { non-Transport }
+ { Functions }
+ |<========== Pre-RFC5654 MPLS ===========>|
+ { ECMP }
+ { LDP/non-TE LSPs }
+ { IP forwarding }
+
+ |<======== MPLS-TP ============>|
+ { Additional }
+ { Transport }
+ { Functions }
+
+ Figure 1: Scope of MPLS-TP
+
+ MPLS-TP can be used to construct packet networks and is therefore
+ applicable in any packet network context. A subset of MPLS-TP is
+ also applicable to ITU-T-defined packet transport networks, where the
+ transport network operational model is deemed attractive.
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 13]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+3.3. Architecture
+
+ MPLS-TP comprises the following architectural elements:
+
+ o A standard MPLS data plane [RFC3031] as profiled in [DATA-PLANE].
+
+ o Sections, LSPs, and PWs that provide a packet transport service
+ for a client network.
+
+ o Proactive and on-demand Operations, Administration, and
+ Maintenance (OAM) functions to monitor and diagnose the MPLS-TP
+ network, as outlined in [OAM-FRAMEWORK].
+
+ o Control planes for LSPs and PWs, as well as support for static
+ provisioning and configuration, as outlined in [CP-FRAMEWORK].
+
+ o Path protection mechanisms to ensure that the packet transport
+ service survives anticipated failures and degradations of the
+ MPLS-TP network, as outlined in [SURVIVE-FWK].
+
+ o Control-plane-based restoration mechanisms, as outlined in
+ [SURVIVE-FWK].
+
+ o Network management functions, as outlined in [NM-FRAMEWORK].
+
+ The MPLS-TP architecture for LSPs and PWs includes the following two
+ sets of functions:
+
+ o MPLS-TP native service adaptation
+
+ o MPLS-TP forwarding
+
+ The adaptation functions interface the native service (i.e., the
+ client layer network service) to MPLS-TP. This includes the case
+ where the native service is an MPLS-TP LSP.
+
+ The forwarding functions comprise the mechanisms required for
+ forwarding the encapsulated native service traffic over an MPLS-TP
+ server layer network, for example, PW and LSP labels.
+
+3.3.1. MPLS-TP Native Service Adaptation Functions
+
+ The MPLS-TP native service adaptation functions interface the client
+ layer network service to MPLS-TP. For pseudowires, these adaptation
+ functions are the payload encapsulation described in Section 4.4 of
+ [RFC3985] and Section 6 of [RFC5659]. For network layer client
+ services, the adaptation function uses the MPLS encapsulation format
+ as defined in [RFC3032].
+
+
+
+Bocci, et al. Informational [Page 14]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ The purpose of this encapsulation is to abstract the data plane of
+ the client layer network from the MPLS-TP data plane, thus
+ contributing to the independent operation of the MPLS-TP network.
+
+ MPLS-TP is itself a client of an underlying server layer. MPLS-TP is
+ thus also bounded by a set of adaptation functions to this server
+ layer network, which may itself be MPLS-TP. These adaptation
+ functions provide encapsulation of the MPLS-TP frames and for the
+ transparent transport of those frames over the server layer network.
+ The MPLS-TP client inherits its Quality of Service (QoS) from the
+ MPLS-TP network, which in turn inherits its QoS from the server
+ layer. The server layer therefore needs to provide the necessary QoS
+ to ensure that the MPLS-TP client QoS commitments can be satisfied.
+
+3.3.2. MPLS-TP Forwarding Functions
+
+ The forwarding functions comprise the mechanisms required for
+ forwarding the encapsulated native service traffic over an MPLS-TP
+ server layer network, for example, PW and LSP labels.
+
+ MPLS-TP LSPs use the MPLS label switching operations and Time-to-Live
+ (TTL) processing procedures defined in [RFC3031], [RFC3032], and
+ [RFC3443], as profiled in [DATA-PLANE]. These operations are highly
+ optimized for performance and are not modified by the MPLS-TP
+ profile.
+
+ In addition, MPLS-TP PWs use the SS-PW and optionally the MS-PW
+ forwarding operations defined in [RFC3985] and [RFC5659].
+
+ Per-platform label space is used for PWs. Either per-platform, per-
+ interface, or other context-specific label space [RFC5331] may be
+ used for LSPs.
+
+ MPLS-TP forwarding is based on the label that identifies the
+ transport path (LSP or PW). The label value specifies the processing
+ operation to be performed by the next hop at that level of
+ 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
+ forwarder. The only event that interrupts a swap operation is TTL
+ expiry. This is a fundamental architectural construct of MPLS to be
+ taken into account when designing protocol extensions (such as those
+ for OAM) that require packets to be sent to an intermediate LSR.
+
+ Further processing to determine the context of a packet occurs when a
+ swap operation is interrupted in this manner, or a pop operation
+ exposes a specific reserved label at the top of the stack, or the
+
+
+
+
+
+Bocci, et al. Informational [Page 15]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ 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].
+
+ MPLS-TP supports Quality of Service capabilities via the MPLS
+ Differentiated Services (Diffserv) architecture [RFC3270]. Both
+ E-LSP and L-LSP MPLS Diffserv modes are supported.
+
+ Further details of MPLS-TP forwarding can be found in [DATA-PLANE].
+
+3.4. MPLS-TP Native Service Adaptation
+
+ This document describes the architecture for two native service
+ adaptation mechanisms, which provide encapsulation and demultiplexing
+ for native service traffic traversing an MPLS-TP network:
+
+ o A PW
+
+ o An MPLS LSP
+
+ MPLS-TP uses IETF-defined pseudowires to emulate certain services,
+ for example, Ethernet, Frame Relay, or PPP / High-Level Data Link
+ Control (HDLC). A list of PW types is maintained by IANA in the
+ "MPLS Pseudowire Type" registry. When the native service adaptation
+ is via a PW, the mechanisms described in Section 3.4.4 are used.
+
+ An MPLS LSP can also provide the adaptation, in which case any native
+ service traffic type supported by [RFC3031] and [RFC3032] is allowed.
+ Examples of such traffic types include IP packets and MPLS-labeled
+ packets. Note that the latter case includes TE-LSPs [RFC3209] and
+ LSP-based applications such as PWs, Layer 2 VPNs [RFC4664], and Layer
+ 3 VPNs [RFC4364]. When the native service adaptation is via an MPLS
+ label, the mechanisms described in Section 3.4.5 are used.
+
+3.4.1. MPLS-TP Client/Server Layer Relationship
+
+ The relationship between the client layer network and the MPLS-TP
+ server layer network is defined by the MPLS-TP network boundary and
+ the label context. It is not explicitly indicated in the packet. In
+ terms of the MPLS label stack, when the native service traffic type
+ is itself MPLS-labeled, then the S bits of all the labels in the
+ MPLS-TP label stack carrying that client traffic are zero; otherwise,
+ the bottom label of the MPLS-TP label stack has the S bit set to 1.
+ In other words, there can be only one S bit set in a label stack.
+
+ The data-plane behavior of MPLS-TP is the same as the best current
+ practice for MPLS. This includes the setting of the S bit. In each
+ case, the S bit is set to indicate the bottom (i.e., innermost) label
+
+
+
+Bocci, et al. Informational [Page 16]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ in the label stack that is contiguous between the MPLS-TP LSP and its
+ payload, and only one label stack entry (LSE) contains the S bit
+ (Bottom of Stack bit) set to 1. Note that this best current practice
+ differs slightly from [RFC3032], which uses the S bit to identify
+ when MPLS label processing stops and network layer processing starts.
+
+ The relationship of MPLS-TP to its clients is illustrated in
+ Figure 2. Note that the label stacks shown in the figure are divided
+ between those inside the MPLS-TP network and those within the client
+ network when the client network is MPLS(-TP). They illustrate the
+ smallest number of labels possible. These label stacks could also
+ include more labels.
+
+ PW-Based MPLS Labeled IP
+ Services Services Transport
+ |------------| |-----------------------------| |------------|
+
+ Emulated PW over LSP IP over LSP IP
+ Service
+ +------------+
+ | PW Payload |
+ +------------+ +------------+ (CLIENTS)
+ |PW 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)|
+ +------------+ +------------+ +------------+ +------------+
+ |LSP Lbl(S=0)| . . .
+ +------------+ . . . (MPLS-TP)
+ . . . .
+ .
+ .
+
+~~~~~~~~~~~ denotes Client <-> MPLS-TP layer boundary
+
+ Figure 2: MPLS-TP - Client Relationship
+
+3.4.2. MPLS-TP Transport Layers
+
+ An MPLS-TP network consists logically of two layers: the Transport
+ Service layer and the Transport Path layer.
+
+ The Transport Service layer provides the interface between Customer
+ Edge (CE) nodes and the MPLS-TP network. Each packet transmitted by
+ a CE node for transport over the MPLS-TP network is associated at the
+ receiving MPLS-TP Provider Edge (PE) node with a single logical
+ point-to-point connection at the Transport Service layer between this
+
+
+
+Bocci, et al. Informational [Page 17]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ (ingress) PE and the corresponding (egress) PE to which the peer CE
+ is attached. Such a connection is called an MPLS-TP Transport
+ Service Instance, and the set of client packets belonging to the
+ native service associated with such an instance on a particular CE-PE
+ link is called a client flow.
+
+ The Transport Path layer provides aggregation of Transport Service
+ Instances over MPLS-TP transport paths (LSPs), as well as aggregation
+ of transport paths (via LSP hierarchy).
+
+ Awareness of the Transport Service layer need exist only at PE nodes.
+ MPLS-TP Provider (P) nodes need have no awareness of this layer.
+ Both PE and P nodes participate in the Transport Path layer. A PE
+ terminates (i.e., is an LER with respect to) the transport paths it
+ supports, and is responsible for multiplexing and demultiplexing of
+ Transport Service Instance traffic over such transport paths.
+
+3.4.3. MPLS-TP Transport Service Interfaces
+
+ An MPLS-TP PE node can provide two types of interface to the
+ Transport Service layer. The MPLS-TP User-Network Interface (UNI)
+ provides the interface between a CE and the MPLS-TP network. The
+ MPLS-TP Network-Network Interface (NNI) provides the interface
+ between two MPLS-TP PEs in different administrative domains.
+
+ When MPLS-TP is used to provide a transport service for, e.g., IP
+ services that are a part of a Layer 3 VPN, then packets are
+ transported in the same manner as specified in [RFC4364].
+
+3.4.3.1. User-Network Interface
+
+ The MPLS-TP User-Network interface (UNI) is illustrated in Figure 3.
+ The UNI for a particular client flow may or may not involve signaling
+ between the CE and PE, and if signaling is used, it may or may not
+ traverse the same attachment circuit that supports the client flow.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 18]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ : User-Network Interface : MPLS-TP
+ :<-------------------------------------->: Network <----->
+ : :
+ -:------------- --------------:------------------
+ : | | : Transport |
+ : | | Transport : Path |
+ : | | Service : Mux/Demux |
+ : | | Control : -- |
+ : | | Plane : | | Transport|
+ : ---------- | Signaling | ---------- : | | Path |
+ :|Signaling |_|___________|_|Signaling | : | | --------->
+ :|Controller| | | |Controller| : | | |
+ : ---------- | | ---------- : | | --------->
+ : :......|...........|......: : | | |
+ : | Control | : | | Transport|
+ : | Channel | : | | Path |
+ : | | : | | --------->
+ : | | : | | -+----------->TSI
+ : | | Transport : | | | --------->
+ : | Client | Service : | | | |
+ : | Traffic | Data Plane : | | | |
+ : ---------- | Flows | -------------- | | |Transport|
+ :|Signaling |-|-----------|-|Client/Service|-| |- Path |
+ :|Controller|=|===========|=| Traffic | | | --------->
+ : ---------- | | | Processing |=| |===+===========>TSI
+ : | | | -------------- | | --------->
+ : |______|___________|______| : | | |
+ : | Data Link | : | | |
+ : | | : -- |
+ : | | : Transport |
+ : | | : Service |
+ : | | : Data Plane|
+ --------------- ---------------------------------
+ Customer Edge Node MPLS-TP Provider Edge Node
+
+
+ TSI = Transport Service Instance
+
+ Figure 3: MPLS-TP PE Containing a UNI
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 19]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ --------------From UNI-------> :
+ -------------------------------------------:------------------
+ | | Client Traffic Unit : |
+ | Link-Layer-Specific | Link Decapsulation : Service Instance |
+ | Processing | & : Transport |
+ | | Service Instance : Encapsulation |
+ | | Identification : |
+ -------------------------------------------:------------------
+ :
+ :
+ -------------------------------------------:------------------
+ | | : Service Instance |
+ | | : Transport |
+ | Link-Layer-Specific | Client Traffic Unit : Decapsulation |
+ | Processing | Link Encapsulation : & |
+ | | : Service Instance |
+ | | : Identification |
+ -------------------------------------------:------------------
+ <-------------To UNI --------- :
+
+ Figure 4: MPLS-TP UNI Client-Server Traffic Processing Stages
+
+ Figure 4 shows the logical processing steps involved in a PE both for
+ traffic flowing from the CE to the MPLS-TP network (left to right),
+ and from the network to the CE (right to left).
+
+ In the first case, when a packet from a client flow is received by
+ the PE from the CE over the data-link, the following steps occur:
+
+ 1. Link-layer-specific pre-processing, if any, is performed. An
+ example of such pre-processing is the PREP function illustrated
+ in Figure 3 of [RFC3985]. Such pre-processing is outside the
+ scope of MPLS-TP.
+
+ 2. The packet is extracted from the data-link frame, if necessary,
+ and associated with a Transport Service Instance. At this point,
+ UNI processing has completed.
+
+ 3. A transport service encapsulation is associated with the packet,
+ if necessary, for transport over the MPLS-TP network.
+
+ 4. The packet is mapped to a transport path based on its associated
+ Transport Service Instance, the transport path encapsulation is
+ added, if necessary, and the packet is transmitted over the
+ transport path.
+
+
+
+
+
+
+Bocci, et al. Informational [Page 20]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ In the second case, when a packet associated with a Transport Service
+ Instance arrives over a transport path, the following steps occur:
+
+ 1. The transport path encapsulation is disposed of.
+
+ 2. The transport service encapsulation is disposed of and the
+ Transport Service Instance and client flow identified.
+
+ 3. At this point, UNI processing begins. A data-link encapsulation
+ is associated with the packet for delivery to the CE based on the
+ client flow.
+
+ 4. Link-layer-specific postprocessing, if any, is performed. Such
+ postprocessing is outside the scope of MPLS-TP.
+
+3.4.3.2. Network-Network Interface
+
+ The MPLS-TP NNI is illustrated in Figure 5. The NNI for a particular
+ Transport Service Instance may or may not involve signaling between
+ the two PEs; and if signaling is used, it may or may not traverse the
+ same data-link that supports the service instance.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 21]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ : Network-Network Interface :
+ :<--------------------------------->:
+ : :
+ ------------:------------- -------------:------------
+ | Transport : | | : Transport |
+ | Path : Transport | | Transport : Path |
+ | Mux/Demux : Service | | Service : Mux/Demux |
+ | -- : Control | | Control : -- |
+ | | | : Plane |Sig- | Plane : | | |
+ |TP | | : ---------- | naling| ---------- : | | TP|
+ <--- | | :|Signaling |_|_______|_|Signaling |: | | --->
+ TSI<-+- | | :|Controller| | | |Controller|: | | |
+ <--- | | | : ---------- | | ---------- : | | --->
+ | | | | : :......|.......|......: : | | |
+ | | | | : |Control| : | | |
+ |TP | | | : |Channel| : | | TP|
+ <--- | | | : | | : | | --->
+ | | | | : | | : | | -+->TSI
+ <--- | | | : Transport | | Transport : | | | --->
+ | | | | : Service |Service| Service : | | | |
+ | | | | : Data Plane |Traffic| Data Plane : | | | |
+ | | | | ------------- | Flows | ------------- | | | |
+ |TP -| |-| Service |-|-------|-| Service |-| |- TP|
+ <--- | | | Traffic | | | | Traffic | | | --->
+ TSI<=+===| |=| Processing |=|=======|=| Processing |=| |===+=>TSI
+ <--- | | ------------- | | ------------- | | --->
+ | | | : |______|_______|______| : | | |
+ | | | : | Data | : | | |
+ | -- : | Link | : -- |
+ | : | | : |
+ -------------------------- --------------------------
+ MPLS-TP Provider Edge Node MPLS-TP Provider Edge Node
+
+
+ TP = Transport Path
+ TSI = Transport Service Instance
+
+ Figure 5: MPLS-TP PE Containing an NNI
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 22]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ :
+ --------------From NNI-------> :
+ --------------------------------------------:------------------
+ | | Service Traffic Unit : |
+ | Link-Layer-Specific | Link Decapsulation : Service Instance |
+ | Processing | & : Encapsulation |
+ | | Service Instance : Normalization |
+ | | Identification : |
+ --------------------------------------------:------------------
+ :
+ :
+ --------------------------------------------:------------------
+ | | : Service Instance |
+ | | : Identification |
+ | Link-Layer-Specific | Service Traffic Unit : & |
+ | Processing | Link Encapsulation : Service Instance |
+ | | : Encapsulation |
+ | | : Normalization |
+ --------------------------------------------:------------------
+ <-------------To NNI --------- :
+
+ Figure 6: MPLS-TP NNI Service Traffic Processing Stages
+
+ Figure 6 shows the logical processing steps involved in a PE for
+ traffic flowing both from the peer PE (left to right) and to the peer
+ PE (right to left).
+
+ In the first case, when a packet from a Transport Service Instance is
+ received by the PE from the peer PE over the data-link, the following
+ steps occur:
+
+ 1. Link-layer specific pre-processing, if any, is performed. Such
+ pre-processing is outside the scope of MPLS-TP.
+
+ 2. The packet is extracted from the data-link frame if necessary,
+ and associated with a Transport Service Instance. At this point,
+ NNI processing has completed.
+
+ 3. The transport service encapsulation of the packet is normalized
+ for transport over the MPLS-TP network. This step allows a
+ different transport service encapsulation to be used over the NNI
+ than that used in the internal MPLS-TP network. An example of
+ such normalization is a swap of a label identifying the Transport
+ Service Instance.
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 23]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ 4. The packet is mapped to a transport path based on its associated
+ Transport Service Instance, the transport path encapsulation is
+ added, if necessary, and the packet is transmitted over the
+ transport path.
+
+ In the second case, when a packet associated with a Transport Service
+ Instance arrives over a transport path, the following steps occur:
+
+ 1. The transport path encapsulation is disposed of.
+
+ 2. The Transport Service Instance is identified from the transport
+ service encapsulation, and this encapsulation is normalized for
+ delivery over the NNI (see Step 3 above).
+
+ 3. At this point, NNI processing begins. A data-link encapsulation
+ is associated with the packet for delivery to the peer PE based
+ on the normalized Transport Service Instance.
+
+ 4. Link-layer-specific postprocessing, if any, is performed. Such
+ postprocessing is outside the scope of MPLS-TP.
+
+3.4.3.3. Example Interfaces
+
+ This section considers some special cases of UNI processing for
+ particular transport service types. These are illustrative, and do
+ not preclude other transport service types.
+
+3.4.3.3.1. Layer 2 Transport Service
+
+ In this example the MPLS-TP network is providing a point-to-point
+ Layer 2 transport service between attached CE nodes. This service is
+ provided by a Transport Service Instance consisting of a PW
+ established between the associated PE nodes. The client flows
+ associated with this Transport Service Instance are the sets of all
+ Layer 2 frames transmitted and received over the attachment circuits.
+
+ The processing steps in this case for a frame received from the CE
+ are:
+
+ 1. Link-layer specific pre-processing, if any, is performed,
+ corresponding to the PREP function illustrated in Figure 3 of
+ [RFC3985].
+
+ 2. The frame is associated with a Transport Service Instance based
+ on the attachment circuit over which it was received.
+
+ 3. A transport service encapsulation, consisting of the PW control
+ word and PW label, is associated with the frame.
+
+
+
+Bocci, et al. Informational [Page 24]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ 4. The resulting packet is mapped to an LSP, the LSP label is
+ pushed, and the packet is transmitted over the outbound interface
+ associated with the LSP.
+
+ For PW packets received over the LSP, the steps are performed in the
+ reverse order.
+
+3.4.3.3.2. IP Transport Service
+
+ In this example, the MPLS-TP network is providing a point-to-point IP
+ transport service between CE1, CE2, and CE3, as follows. One point-
+ to-point Transport Service Instance delivers IPv4 packets between CE1
+ and CE2, and another instance delivers IPv6 packets between CE1 and
+ CE3.
+
+ The processing steps in this case for an IP packet received from CE1
+ are:
+
+ 1. No link-layer-specific processing is performed.
+
+ 2. The IP packet is extracted from the link-layer frame and
+ associated with a Service LSP based on the source MAC address
+ (CE1) and the IP protocol version.
+
+ 3. A transport service encapsulation, consisting of the Service LSP
+ label, is associated with the packet.
+
+ 4. The resulting packet is mapped to a tunnel LSP, the tunnel LSP
+ label is pushed, and the packet is transmitted over the outbound
+ interface associated with the LSP.
+
+ For packets received over a tunnel LSP carrying the Service LSP
+ label, the steps are performed in the reverse order.
+
+3.4.4. Pseudowire Adaptation
+
+ MPLS-TP uses pseudowires to provide a Virtual Private Wire Service
+ (VPWS), a Virtual Private Local Area Network Service (VPLS), a
+ Virtual Private Multicast Service (VPMS), and an Internet Protocol
+ Local Area Network Service (IPLS). VPWS, VLPS, and IPLS are
+ described in [RFC4664]. VPMS is described in [VPMS-REQS].
+
+ If the MPLS-TP network provides a layer 2 interface (that can carry
+ both network-layer and non-network-layer traffic) as a service
+ interface, then a PW is required to support the service interface.
+ The PW is a client of the MPLS-TP LSP server layer. The architecture
+ for an MPLS-TP network that provides such services is based on the
+ MPLS [RFC3031] and pseudowire [RFC3985] architectures. Multi-segment
+
+
+
+Bocci, et al. Informational [Page 25]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ pseudowires may optionally be used to provide a packet transport
+ service, and their use is consistent with the MPLS-TP architecture.
+ The use of MS-PWs may be motivated by, for example, the requirements
+ specified in [RFC5254]. If MS-PWs are used, then the MS-PW
+ architecture [RFC5659] also applies.
+
+ Figure 7 shows the architecture for an MPLS-TP network using single-
+ segment PWs. Note that, in this document, the client layer is
+ equivalent to the emulated service described in [RFC3985], while the
+ Transport LSP is equivalent to the Packet Switched Network (PSN)
+ tunnel of [RFC3985].
+
+ |<----------------- Client Layer ------------------->|
+ | |
+ | |<-------- Pseudowire -------->| |
+ | | encapsulated, packet | |
+ | | transport service | |
+ | | | |
+ | | Transport | |
+ | | |<------ LSP ------->| | |
+ | V V V V |
+ V AC +----+ +-----+ +----+ AC V
+ +-----+ | | PE1|=======\ /========| PE2| | +-----+
+ | |----------|.......PW1.| \ / |............|----------| |
+ | CE1 | | | | | X | | | | | CE2 |
+ | |----------|.......PW2.| / \ |............|----------| |
+ +-----+ ^ | | |=======/ \========| | | ^ +-----+
+ ^ | +----+ ^ +-----+ +----+ | ^
+ | | Provider | ^ Provider | |
+ | | Edge 1 | | Edge 2 | |
+ Customer | | P Router | Customer
+ Edge 1 | TE LSP | Edge 2
+ | |
+ | |
+ Native service Native service
+
+ Figure 7: MPLS-TP Architecture (Single Segment PW)
+
+ Figure 8 shows the architecture for an MPLS-TP network when multi-
+ segment pseudowires are used. Note that as in the SS-PW case,
+ P-routers may also exist.
+
+
+
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 26]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ |<--------------------- Client Layer ------------------------>|
+ | |
+ | Pseudowire encapsulated, |
+ | |<---------- Packet Transport Service ------------->| |
+ | | | |
+ | | Transport Transport | |
+ | AC | |<-------- LSP1 --------->| |<--LSP2-->| | AC |
+ | | V V V V V V | |
+ V | +----+ +-----+ +----+ +----+ | V
+ +---+ | |TPE1|===============\ /=====|SPE1|==========|TPE2| | +---+
+ | |----|......PW1-Seg1.... | \ / | ......X...PW1-Seg2......|----| |
+ |CE1| | | | | X | | | | | | |CE2|
+ | |----|......PW2-Seg1.... | / \ | ......X...PW2-Seg2......|----| |
+ +---+ ^ | |===============/ \=====| |==========| | | ^+---+
+ | +----+ ^ +-----+ +----+ ^ +----+ |
+ | | ^ | |
+ | TE LSP | TE LSP |
+ | P-router |
+ Native Service Native Service
+
+
+ PW1-segment1 and PW1-segment2 are segments of the same MS-PW,
+ while PW2-segment1 and PW2-segment2 are segments of another MS-PW.
+
+ Figure 8: MPLS-TP Architecture (Multi-Segment PW)
+
+ The corresponding MPLS-TP protocol stacks including PWs are shown in
+ Figure 9. In this figure, the Transport Service layer [RFC5654] is
+ identified by the PW demultiplexer (Demux) label, and the Transport
+ Path layer [RFC5654] is identified by the LSP Demux Label.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 27]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ +-------------------+ /===================\ /===================\
+ | Client Layer | H OAM PDU H H OAM PDU H
+ /===================\ H-------------------H H-------------------H
+ H PW Encap H H GACh H H GACh H
+ H-------------------H H-------------------H H-------------------H
+ H PW Demux (S=1) H H PW Demux (S=1) H H GAL (S=1) H
+ H-------------------H H-------------------H H-------------------H
+ H Trans LSP Demux(s)H H Trans LSP Demux(s)H H Trans LSP Demux(s)H
+ \===================/ \===================/ \===================/
+ | Server Layer | | Server Layer | | Server Layer |
+ +-------------------+ +-------------------+ +-------------------+
+
+ User Traffic PW OAM LSP OAM
+
+ Note: H(ighlighted) indicates the part of the protocol stack considered
+ in this document.
+
+ Figure 9: MPLS-TP Label Stack Using Pseudowires
+
+ PWs and their associated labels may be configured or signaled. See
+ Section 3.11 for additional details related to configured service
+ types. See Section 3.9 for additional details related to signaled
+ service types.
+
+3.4.5. Network Layer Adaptation
+
+ MPLS-TP LSPs can be used to transport network-layer clients. This
+ document uses the term Network Layer in the same sense as it is used
+ in [RFC3031] and [RFC3032]. The network-layer protocols supported by
+ [RFC3031] and [RFC3032] can be transported between service
+ interfaces. Support for network-layer clients follows the MPLS
+ architecture for support of network-layer protocols as specified in
+ [RFC3031] and [RFC3032].
+
+ With network-layer adaptation, the MPLS-TP domain provides either a
+ unidirectional or bidirectional point-to-point connection between 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
+ MPLS-TP node. As shown in Figure 10, there is an attachment circuit
+ between the CE node on the left and its corresponding provider edge
+ (PE) node (which provides the service interface), a bidirectional LSP
+ across the MPLS-TP network to the corresponding PE node on the right,
+ and an attachment circuit between that PE node and the corresponding
+ CE node for this service.
+
+ The attachment circuits may be heterogeneous (e.g., any combination
+ of SDH, PPP, Frame Relay, etc.) and network-layer protocol payloads
+ arrive at the service interface encapsulated in the Layer 1 / Layer 2
+
+
+
+Bocci, et al. Informational [Page 28]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ encoding defined for that access link type. It should be noted that
+ the set of network-layer protocols includes MPLS, and hence MPLS-
+ encoded packets with an MPLS label stack (the client MPLS stack) may
+ appear at the service interface.
+
+ The following figures illustrate the reference models for network-
+ layer adaptation. The details of these figures are described further
+ in the following paragraphs.
+
+ |<------------- Client Network Layer --------------->|
+ | |
+ | |<----------- Packet --------->| |
+ | | Transport Service | |
+ | | | |
+ | | | |
+ | | Transport | |
+ | | |<------ LSP ------->| | |
+ | V V V V |
+ V AC +----+ +-----+ +----+ AC V
+ +-----+ | | PE1|=======\ /========| PE2| | +-----+
+ | |----------|..Svc LSP1.| \ / |............|----------| |
+ | CE1 | | | | | X | | | | | CE2 |
+ | |----------|..Svc LSP2.| / \ |............|----------| |
+ +-----+ ^ | | |=======/ \========| | | ^ +-----+
+ ^ | +----+ ^ +-----+ +----+ | | ^
+ | | Provider | ^ Provider | |
+ | | Edge 1 | | Edge 2 | |
+ Customer | | P Router | Customer
+ Edge 1 | TE LSP | Edge 2
+ | |
+ | |
+ Native service Native service
+
+ Figure 10: MPLS-TP Architecture for Network-Layer Clients
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 29]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ |<--------------------- Client Layer ------------------------>|
+ | |
+ | |
+ | |<---------- Packet Transport Service ------------->| |
+ | | | |
+ | | Transport Transport | |
+ | AC | |<-------- LSP1 --------->| |<--LSP2-->| | AC |
+ | | V V V V V V | |
+ V | +----+ +-----+ +----+ +----+ | V
++---+ | | PE1|===============\ /=====| PE2|==========| PE3| | +---+
+| |----|......svc-lsp1.... | \ / | .....X....svc-lsp1......|----| |
+|CE1| | | | | X | | | | | | |CE2|
+| |----|......svc-lsp2.... | / \ | .....X....svc-lsp2......|----| |
++---+ ^ | |===============/ \=====| |==========| | | ^+---+
+ | +----+ ^ +-----+ +----+ ^ +----+ |
+ | | ^ ^ | |
+ | TE LSP | | TE LSP |
+ | P-router | |
+Native Service (LSR for | Native Service
+ T'port LSP1) |
+ |
+ LSR for Service LSPs
+ LER for Transport LSPs
+
+ Figure 11: MPLS-TP Architecture for Network Layer Adaptation, Showing
+ Service LSP Switching
+
+ Client packets are received at the ingress service interface. The PE
+ pushes one or more labels onto the client packets that are then label
+ switched over the transport network. Correspondingly, the egress PE
+ pops any labels added by the MPLS-TP networks and transmits the
+ packet for delivery to the attached CE via the egress service
+ interface.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 30]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ /===================\
+ H OAM PDU H
+ +-------------------+ H-------------------H /===================\
+ | Client Layer | H GACh H H OAM PDU H
+ /===================\ H-------------------H H-------------------H
+ H Encap Label H H GAL (S=1) H H GACh H
+ H-------------------H H-------------------H H-------------------H
+ H SvcLSP Demux H H SvcLSP Demux (S=0)H H GAL (S=1) H
+ H-------------------H H-------------------H H-------------------H
+ H Trans LSP Demux(s)H H Trans LSP Demux(s)H H Trans LSP Demux(s)H
+ \===================/ \===================/ \===================/
+ | Server Layer | | Server Layer | | Server Layer |
+ +-------------------+ +-------------------+ +-------------------+
+
+ User Traffic Service LSP OAM LSP OAM
+
+
+ Note: H(ighlighted) indicates the part of the protocol stack considered
+ in this document.
+
+ Figure 12: MPLS-TP Label Stack for IP and LSP Clients
+
+ In the figures above, the Transport Service layer [RFC5654] is
+ identified by the Service LSP (SvcLSP) demultiplexer (Demux) label,
+ and the Transport Path layer [RFC5654] is identified by the Transport
+ (Trans) LSP Demux Label. Note that the functions of the
+ Encapsulation Label (Encap Label) and the Service Label (SvcLSP
+ Demux) shown above may alternatively be represented by a single label
+ stack entry. Note that the S bit is always zero when the client
+ layer is MPLS-labeled. It may be necessary to swap a service LSP
+ label at an intermediate node. This is shown in Figure 11.
+
+ Within the MPLS-TP transport network, the network-layer protocols are
+ carried over the MPLS-TP network using a logically separate MPLS
+ label stack (the server stack). The server stack is entirely under
+ the control of the nodes within the MPLS-TP transport network and it
+ is not visible outside that network. Figure 12 shows how a client
+ network protocol stack (which may be an MPLS label stack and payload)
+ is carried over a network layer client service over an MPLS-TP
+ transport network.
+
+ A label may be used to identify the network-layer protocol payload
+ type. Therefore, when multiple protocol payload types are to be
+ carried over a single service LSP, a unique label stack entry needs
+ to be present for each payload type. Such labels are referred to as
+ "Encapsulation Labels", one of which is shown in Figure 12. An
+ Encapsulation Label may be either configured or signaled.
+
+
+
+
+Bocci, et al. Informational [Page 31]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ Both an Encapsulation Label and a Service Label should be present in
+ the label stack when a particular packet transport service is
+ supporting more than one network-layer protocol payload type. For
+ example, if both IP and MPLS are to be carried, then two
+ Encapsulation Labels are mapped on to a common Service Label.
+
+ Note: The Encapsulation Label may be omitted when the service LSP is
+ supporting only one network-layer protocol payload type. For
+ example, if only MPLS labeled packets are carried over a service,
+ then the Service Label (stack entry) provides both the payload type
+ indication and service identification. The Encapsulation Label
+ cannot have any of the reserved label values [RFC3032].
+
+ Service labels are typically carried over an MPLS-TP Transport LSP
+ edge-to-edge (or transport path layer). An MPLS-TP Transport LSP is
+ represented as an LSP Transport Demux label, as shown in Figure 12.
+ Transport LSP is commonly used when more than one service exists
+ between two PEs.
+
+ Note that, if only one service exists between two PEs, the functions
+ of the Transport LSP label and the Service LSP Label may be combined
+ into a single label stack entry. For example, if only one service is
+ carried between two PEs, then a single label could be used to provide
+ both the service indication and the MPLS-TP Transport LSP.
+ 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
+ Transport LSP.
+
+ As noted above, the Layer 2 and Layer 1 protocols used to carry the
+ network-layer protocol over the attachment circuits are not
+ transported across the MPLS-TP network. This enables the use of
+ different Layer 2 and Layer 1 protocols on the two attachment
+ circuits.
+
+ At each service interface, Layer 2 addressing needs to be used to
+ ensure the proper delivery of a network-layer packet to the adjacent
+ node. This is typically only an issue for LAN media technologies
+ (e.g., Ethernet) that have Media Access Control (MAC) addresses. In
+ cases where a MAC address is needed, the sending node sets the
+ destination MAC address to an address that ensures delivery to the
+ 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
+ destination MAC address to an address that ensures delivery to the
+ CE. The specific address used is technology type specific and is not
+ specified in this document. In some technologies, the MAC address
+ will need to be configured.
+
+
+
+
+
+Bocci, et al. Informational [Page 32]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ Note that when two CEs, which peer with each other, operate over a
+ network layer transport service and run a routing protocol such as
+ IS-IS or OSPF, some care should be taken to configure the routing
+ protocols to use point-to-point adjacencies. The specifics of such
+ configuration is outside the scope of this document. See [RFC5309]
+ for additional details.
+
+ The CE-to-CE service types and corresponding labels may be configured
+ or signaled.
+
+3.5. Identifiers
+
+ Identifiers are used to uniquely distinguish entities in an MPLS-TP
+ network. These include operators, nodes, LSPs, pseudowires, and
+ their associated maintenance entities. MPLS-TP defined two types of
+ sets of identifiers: those that are compatible with IP, and those
+ that are compatible with ITU-T transport-based operations. The
+ definition of these sets of identifiers is outside the scope of this
+ document and is provided by [IDENTIFIERS].
+
+3.6. Generic Associated Channel (G-ACh)
+
+ For correct operation of OAM mechanisms, it is important that OAM
+ packets fate-share with the data packets. In addition, in MPLS-TP it
+ is necessary to discriminate between user data payloads and other
+ types of payload. For example, a packet may be associated with a
+ Signaling Communication Channel (SCC) or a channel used for a
+ protocol to coordinate path protection state. This is achieved by
+ carrying such packets in either:
+
+ o A generic control channel associated to the LSP, PW, or section,
+ with no IP encapsulation, e.g., in a similar manner to
+ Bidirectional Forwarding Detection for Virtual Circuit
+ Connectivity Verification (VCCV-BFD) with PW ACH encapsulation
+ [RFC5885]).
+
+ o An IP encapsulation where IP capabilities are present, e.g., PW
+ ACH encapsulation with IP headers for VCCV-BFD [RFC5885] or IP
+ encapsulation for MPLS BFD [RFC5884].
+
+ MPLS-TP makes use of such a generic associated channel (G-ACh) to
+ support Fault, Configuration, Accounting, Performance, and Security
+ (FCAPS) functions by carrying packets related to OAM, a protocol used
+ to coordinate path protection state, SCC, MCC or other packet types
+ in-band over LSPs, PWs, or sections. The G-ACh is defined in
+ [RFC5586] and is similar to the Pseudowire Associated Channel
+ [RFC4385], which is used to carry OAM packets over pseudowires. The
+ G-ACh is indicated by an Associated Channel Header (ACH), similar to
+
+
+
+Bocci, et al. Informational [Page 33]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ the Pseudowire VCCV control word; this header is present for all
+ sections, LSPs, and PWs that make use of FCAPS functions supported by
+ the G-ACh.
+
+ As specified in [RFC5586], the G-ACh must only be used for channels
+ that are an adjunct to the data service. Examples of these are OAM,
+ a protocol used to coordinate path protection state, MCC, and SCC,
+ but the use is not restricted to these services. The G-ACh must not
+ be used to carry additional data for use in the forwarding path,
+ i.e., it must not be used as an alternative to a PW control word, or
+ to define a PW type.
+
+ At the server layer, bandwidth and QoS commitments apply to the gross
+ traffic on the LSP, PW, or section. Since the G-ACh traffic is
+ indistinguishable from the user data traffic, protocols using the
+ G-ACh need to take into consideration the impact they have on the
+ user data with which they are sharing resources. Conversely,
+ capacity needs to be made available for important G-ACh uses such as
+ protection and OAM. In addition, the security and congestion
+ considerations described in [RFC5586] apply to protocols using the
+ G-ACh.
+
+ Figure 13 shows the reference model depicting how the control channel
+ is associated with the pseudowire protocol stack. This is based on
+ the reference model for VCCV shown in Figure 2 of [RFC5085].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 34]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ +-------------+ +-------------+
+ | Payload | < FCAPS > | Payload |
+ +-------------+ +-------------+
+ | Demux / | < ACH for PW > | Demux / |
+ |Discriminator| |Discriminator|
+ +-------------+ +-------------+
+ | PW | < PW > | PW |
+ +-------------+ +-------------+
+ | PSN | < LSP > | PSN |
+ +-------------+ +-------------+
+ | Physical | | Physical |
+ +-----+-------+ +-----+-------+
+ | |
+ | ____ ___ ____ |
+ | _/ \___/ \ _/ \__ |
+ | / \__/ \_ |
+ | / \ |
+ +--------| MPLS-TP Network |---+
+ \ /
+ \ ___ ___ __ _/
+ \_/ \____/ \___/ \____/
+
+ Figure 13: PWE3 Protocol Stack Reference Model Showing the G-ACh
+
+ PW-associated channel messages are encapsulated using the PWE3
+ encapsulation, so that they are handled and processed in the same
+ manner (or in some cases, an analogous manner) as the PW PDUs for
+ which they provide a control channel.
+
+ Figure 14 shows the reference model depicting how the control channel
+ is associated with the LSP protocol stack.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 35]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ +-------------+ +-------------+
+ | Payload | < FCAPS > | Payload |
+ +-------------+ +-------------+
+ |Discriminator| < ACH on LSP > |Discriminator|
+ +-------------+ +-------------+
+ |Demultiplexer| < GAL on LSP > |Demultiplexer|
+ +-------------+ +-------------+
+ | PSN | < LSP > | PSN |
+ +-------------+ +-------------+
+ | Physical | | Physical |
+ +-----+-------+ +-----+-------+
+ | |
+ | ____ ___ ____ |
+ | _/ \___/ \ _/ \__ |
+ | / \__/ \_ |
+ | / \ |
+ +--------| MPLS-TP Network |---+
+ \ /
+ \ ___ ___ __ _/
+ \_/ \____/ \___/ \____/
+
+ Figure 14: MPLS Protocol Stack Reference Model Showing the LSP
+ Associated Control Channel
+
+3.7. Operations, Administration, and Maintenance (OAM)
+
+ The MPLS-TP OAM architecture supports a wide range of OAM functions
+ to check continuity, to verify connectivity, to monitor path
+ performance, and 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 tool-set is able to operate without relying on a
+ dynamic control plane or IP functionality in the data path. 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. Since MPLS-TP can operate in
+ environments where IP is not used in the forwarding plane, the
+ default mechanism for OAM demultiplexing in MPLS-TP LSPs and PWs is
+ the Generic Associated Channel (Section 3.6). Forwarding based on IP
+ addresses for OAM or user data packets is not required for MPLS-TP.
+
+ [RFC4379] and BFD for MPLS LSPs [RFC5884] have defined alert
+ mechanisms that enable an MPLS LSR to identify and process MPLS OAM
+ packets when the OAM packets are encapsulated in an IP header. These
+ alert mechanisms are based on TTL expiration and/or use an IP
+ destination address in the range 127/8 for IPv4 and that same range
+ embedded as IPv4-mapped IPv6 addresses for IPv6 [RFC4379]. When the
+
+
+
+Bocci, et al. Informational [Page 36]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ OAM packets are encapsulated in an IP header, these mechanisms are
+ the default mechanisms for MPLS networks (in general) for identifying
+ MPLS OAM packets, although the mechanisms defined in [RFC5586] can
+ also be used. MPLS-TP is able to operate in environments where IP
+ forwarding is not supported, and thus the G-ACh/GAL is the default
+ mechanism to demultiplex OAM packets in MPLS-TP in these
+ environments.
+
+ MPLS-TP supports a comprehensive set of OAM capabilities for packet
+ transport applications, with equivalent capabilities to those
+ provided in SONET/SDH.
+
+ MPLS-TP requires [RFC5860] that a set of OAM capabilities is
+ available to perform fault management (e.g., fault detection and
+ localization) and performance monitoring (e.g., packet delay and loss
+ measurement) of the LSP, PW, or section. The framework for OAM in
+ MPLS-TP is specified in [OAM-FRAMEWORK].
+
+ MPLS-TP OAM packets share the same fate as their corresponding data
+ packets, and are identified through the Generic Associated Channel
+ mechanism [RFC5586]. This uses a combination of an Associated
+ Channel Header (ACH) and a G-ACh Label (GAL) to create a control
+ channel associated to an LSP, section, or PW.
+
+ OAM and monitoring in MPLS-TP is based on the concept of maintenance
+ entities, as described in [OAM-FRAMEWORK]. A Maintenance Entity (ME)
+ can be viewed as the association of two Maintenance Entity Group End
+ Points (MEPs). A Maintenance Entity Group (MEG) is a collection of
+ one or more MEs that belongs to the same transport path and that are
+ maintained and monitored as a group. The MEPs that form an ME limit
+ the OAM responsibilities of an OAM flow to within the domain of a
+ transport path or segment, in the specific layer network that is
+ being monitored and managed.
+
+ A MEG may also include a set of Maintenance Entity Group Intermediate
+ Points (MIPs).
+
+ 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 stack
+ entry for the G-ACh packet, as per the traceroute mode of LSP Ping
+ [RFC4379] and the vccv-trace mode of [SEGMENTED-PW]. Note that this
+ 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., following restoration using a facility bypass LSP. In these
+ cases, tools to trace the path of the LSP may be used to determine
+ the appropriate setting for the TTL to reach a specific MIP.
+
+
+
+
+
+Bocci, et al. Informational [Page 37]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ Within an LSR or PE, MEPs and MIPs can only be placed where MPLS
+ layer processing is performed on a packet. The MPLS architecture
+ mandates that MPLS layer processing occurs at least once on an LSR.
+
+ Any node on an LSP can send an OAM packet on that LSP. Likewise, any
+ node on a PW can send OAM packets on a PW, including S-PEs.
+
+ An OAM packet can only be received to be processed at an LSP
+ endpoint, a PW endpoint (T-PE), or on the expiry of the TTL in the
+ LSP or PW label stack entry.
+
+3.8. Return Path
+
+ 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. Although this section describes the
+ case of an MPLS-TP LSP, it is also applicable to a PW.
+
+ In this description, U and D are LSRs that terminate MPLS-TP LSPs
+ (i.e., LERs), and Y is an intermediate LSR along the LSP. Note that
+ U is the upstream LER, and D is the downstream LER with respect to a
+ particular direction of an LSP. This reference model is shown in
+ Figure 15.
+
+ LSP LSP
+
+ U ========= Y ========= D
+
+ LER LSR LER
+
+ ---------> Direction of user traffic flow
+
+ Figure 15: Return Path Reference Model
+
+ The following cases are described for the various types of LSPs:
+
+ Case 1 Return path packet transmission from D to U
+
+ Case 2 Return path packet transmission from Y to U
+
+ Case 3 Return path packet transmission from D to Y
+
+ Note that a return path may not always exist (or may exist but be
+ disabled), and that packet transmission in one or more of the above
+ cases may not be possible. In general, the existence and nature of
+ return paths for MPLS-TP LSPs is determined by operational
+ provisioning.
+
+
+
+Bocci, et al. Informational [Page 38]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+3.8.1. Return Path Types
+
+ 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:
+
+ a. The LSP between U and D is bidirectional, and therefore D has a
+ path via the MPLS-TP LSP to return traffic back to U, 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 distinct Data Communication Network
+ (DCN) (provided, for example, by the method specified in [RFC5718]);
+ or it may be via one or more other MPLS-TP LSPs.
+
+3.8.2. Point-to-Point Unidirectional LSPs
+
+ Case 1 If an in-band return path is required to deliver traffic from
+ D back to U, it is 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 D to U is
+ required. Note that the two directions of such an LSP may
+ have differing bandwidth allocations and QoS characteristics.
+ The discussion below for such LSPs applies.
+
+ As an alternative, an out-of-band return path may be used.
+
+ 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 D is known to have a return path to
+ U, then Y can arrange to deliver return traffic to U by first
+ sending it to D along the original LSP. The mechanism by
+ which D recognizes 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 D has a return path to U, then (in a
+ manner analogous to the previous case) D can arrange to
+
+
+
+Bocci, et al. Informational [Page 39]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ deliver return traffic to Y by first sending it to U along
+ that return path. The mechanism by which U recognizes the
+ need for and performs this forwarding operation is protocol
+ specific.
+
+3.8.3. Point-to-Point Associated Bidirectional LSPs
+
+ For Case 1, D has a natural in-band return path to U, 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 preferred for return
+ traffic. Out-of-band return paths, however, are also applicable,
+ primarily as an alternative means of delivery in case the in-band
+ return path has failed.
+
+3.9. Control Plane
+
+ A distributed dynamic control plane may be used to enable dynamic
+ service provisioning in an MPLS-TP network. Where the requirements
+ specified in [RFC5654] can be met, the MPLS Transport Profile uses
+ existing standard control-plane protocols for LSPs and PWs.
+
+ Note that a dynamic control plane is not required in an MPLS-TP
+ network. See Section 3.11 for further details on statically
+ configured and provisioned MPLS-TP services.
+
+ Figure 16 illustrates the relationship between the MPLS-TP control
+ plane, the forwarding plane, the management plane, and OAM for point-
+ to-point MPLS-TP LSPs or PWs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 40]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ +------------------------------------------------------------------+
+ | |
+ | Network Management System and/or |
+ | |
+ | Control Plane for Point-to-Point Connections |
+ | |
+ +------------------------------------------------------------------+
+ | | | | | |
+ .............|.....|... ....|.....|.... ....|.....|............
+ : +---+ | : : +---+ | : : +---+ | :
+ : |OAM| | : : |OAM| | : : |OAM| | :
+ : +---+ | : : +---+ | : : +---+ | :
+ : | | : : | | : : | | :
+ \: +----+ +--------+ : : +--------+ : : +--------+ +----+ :/
+ --+-|Edge|<->|Forward-|<---->|Forward-|<----->|Forward-|<->|Edge|-+--
+ /: +----+ |ing | : : |ing | : : |ing | +----+ :\
+ : +--------+ : : +--------+ : : +--------+ :
+ ''''''''''''''''''''''' ''''''''''''''' '''''''''''''''''''''''
+
+ Note:
+ 1) NMS may be centralized or distributed. Control plane is
+ distributed.
+ 2) 'Edge' functions refers to those functions present at
+ the edge of a PSN domain, e.g., native service processing or
+ classification.
+ 3) The control plane may be transported over the server
+ layer, an LSP, or a G-ACh.
+
+ Figure 16: MPLS-TP Control Plane Architecture Context
+
+ The MPLS-TP control plane is based on existing MPLS and PW control
+ plane protocols, and is consistent with the Automatically Switched
+ Optical Network (ASON) architecture [G.8080]. MPLS-TP uses:
+
+ o Generalized MPLS (GMPLS) signaling ([RFC3945], [RFC3471],
+ [RFC3473]) for LSPs, and
+
+ o Targeted LDP (T-LDP) signaling ([RFC4447], [SEGMENTED-PW],
+ [DYN-MS-PW]) for pseudowires.
+
+ MPLS-TP requires that any control-plane traffic be capable of being
+ carried over an out-of-band signaling network or a signaling control
+ channel such as the one described in [RFC5718]. Note that while
+ T-LDP signaling is traditionally carried in-band in IP/MPLS networks,
+ this does not preclude its operation over out-of-band channels.
+ References to T-LDP in this document do not preclude the definition
+ of alternative PW control protocols for use in MPLS-TP.
+
+
+
+
+Bocci, et al. Informational [Page 41]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ PW control (and maintenance) takes place separately from LSP tunnel
+ signaling. The main coordination between LSP and PW control will
+ occur within the nodes that terminate PWs. The control planes for
+ PWs and LSPs may be used independently, and one may be employed
+ without the other. This translates into the four possible scenarios:
+ (1) no control plane is employed; (2) a control plane is used for
+ both LSPs and PWs; (3) a control plane is used for LSPs, but not PWs;
+ (4) a control plane is used for PWs, but not LSPs. The PW and LSP
+ control planes, collectively, need to satisfy the MPLS-TP control
+ plane requirements reviewed in the MPLS-TP Control Plane Framework
+ [CP-FRAMEWORK]. When client services are provided directly via LSPs,
+ all requirements must be satisfied by the LSP control plane. When
+ client services are provided via PWs, the PW and LSP control planes
+ operate in combination, and some functions may be satisfied via the
+ PW control plane, while others are provided to PWs by the LSP control
+ plane.
+
+ 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 signaled by its own control
+ protocol.
+
+ The distributed MPLS-TP control plane may provide the following
+ functions:
+
+ o Signaling
+
+ o Routing
+
+ o Traffic engineering and constraint-based path computation
+
+ In a multi-domain environment, the MPLS-TP control plane supports
+ different types of interfaces at domain boundaries or within the
+ domains. These include the User-Network Interface (UNI), Internal
+ Network-Network Interface (I-NNI), and External Network-Network
+ Interface (E-NNI). Note that different policies may be defined that
+ control the information exchanged across these interface types.
+
+ The MPLS-TP control plane is capable of activating MPLS-TP OAM
+ functions as described in the OAM section of this document
+ Section 3.7, e.g., for fault detection and localization in the event
+ of a failure in order to efficiently restore failed transport paths.
+
+ The MPLS-TP control plane supports all MPLS-TP data-plane
+ connectivity patterns that are needed for establishing transport
+ paths, including protected paths as described in Section 3.12.
+
+
+
+
+Bocci, et al. Informational [Page 42]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ Examples of the MPLS-TP data-plane connectivity patterns are LSPs
+ utilizing the fast reroute backup methods as defined in [RFC4090] and
+ ingress-to-egress 1+1 or 1:1 protected LSPs.
+
+ The MPLS-TP control plane provides functions to ensure its own
+ survivability and to enable it to recover gracefully from failures
+ and degradations. These include graceful restart and hot redundant
+ configurations. Depending on how the control plane is transported,
+ varying degrees of decoupling between the control plane and data
+ plane may be achieved. In all cases, however, the control plane is
+ logically decoupled from the data plane such that a control-plane
+ failure does not imply a failure of the existing transport paths.
+
+3.10. Inter-Domain Connectivity
+
+ A number of methods exist to support inter-domain operation of
+ MPLS-TP, including the data-plane, OAM, and configuration aspects,
+ for example:
+
+ o Inter-domain TE LSPs [RFC4726]
+
+ o Multi-segment Pseudowires [RFC5659]
+
+ o LSP stitching [RFC5150]
+
+ o Back-to-back attachment circuits [RFC5659]
+
+ An important consideration in selecting an inter-domain connectivity
+ mechanism is the degree of layer network isolation and types of OAM
+ required by the operator. The selection of which technique to use in
+ a particular deployment scenario is outside the scope of this
+ document.
+
+3.11. Static Operation of LSPs and PWs
+
+ 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. Note that the path of an LSP or PW may be
+ dynamically computed, while the LSP or PW itself is established
+ through static configuration.
+
+
+
+
+
+
+Bocci, et al. Informational [Page 43]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+3.12. Survivability
+
+ The survivability architecture for MPLS-TP is specified in
+ [SURVIVE-FWK].
+
+ A wide variety of resiliency schemes have been developed to meet the
+ various network and service survivability objectives. For example,
+ as part of the MPLS/PW paradigms, MPLS provides methods for local
+ repair using back-up LSP tunnels ([RFC4090]), while pseudowire
+ redundancy [PW-REDUNDANCY] supports scenarios where the protection
+ for the PW cannot be fully provided by the underlying LSP (i.e.,
+ where the backup PW terminates on a different target PE node than the
+ working PW in dual-homing scenarios, or where protection of the S-PE
+ is required). Additionally, GMPLS provides a well-known set of
+ control-plane-driven protection and restoration mechanisms [RFC4872].
+ MPLS-TP provides additional protection mechanisms that are optimized
+ for both linear topologies and ring topologies and that operate in
+ the absence of a dynamic control plane. These are specified in
+ [SURVIVE-FWK].
+
+ Different protection schemes apply to different deployment topologies
+ and operational considerations. Such protection schemes may provide
+ different levels of resiliency, for example:
+
+ o two concurrent traffic paths (1+1).
+
+ o one active and one standby path with guaranteed bandwidth on both
+ paths (1:1).
+
+ o one active path and a standby path the resources of which are
+ shared by one or more other active paths (shared protection).
+
+ The applicability of any given scheme to meet specific requirements
+ is outside the scope of this document.
+
+ The characteristics of MPLS-TP resiliency mechanisms are as follows:
+
+ o Optimized for linear, ring, or meshed topologies.
+
+ o Use OAM mechanisms to detect and localize network faults or
+ service degenerations.
+
+ o Include protection mechanisms to coordinate and trigger protection
+ switching actions in the absence of a dynamic control plane.
+
+ o MPLS-TP recovery schemes are applicable to all levels in the
+ MPLS-TP domain (i.e., section, LSP, and PW) providing segment and
+ end-to-end recovery.
+
+
+
+Bocci, et al. Informational [Page 44]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ o MPLS-TP recovery mechanisms support the coordination of protection
+ switching at multiple levels to prevent race conditions occurring
+ between a client and its server layer.
+
+ o MPLS-TP recovery mechanisms can be data-plane, control-plane, or
+ management-plane based.
+
+ o MPLS-TP supports revertive and non-revertive behavior.
+
+3.13. Sub-Path Maintenance
+
+ In order to monitor, protect, and manage a portion (i.e., segment or
+ concatenated segment) of an LSP, a hierarchical LSP [RFC3031] can be
+ instantiated. A hierarchical LSP instantiated for this purpose is
+ called a Sub-Path Maintenance Element (SPME). Note that by
+ definition an SPME does not carry user traffic as a direct client.
+
+ An SPME is defined between the edges of the portion of the LSP that
+ needs to be monitored, protected or managed. The SPME forms an
+ MPLS-TP Section [DATA-PLANE] that carries the original LSP over this
+ portion of the network as a client. OAM messages can be initiated at
+ the edge of the SPME and sent to the peer edge of the SPME or to a
+ MIP along the SPME by setting the TTL value of the LSE at the
+ corresponding hierarchical LSP level. A P router only pushes or pops
+ a label if it is at the end of a SPME. In this mode, it is an LER
+ for the SPME.
+
+ For example, in Figure 17, two SPMEs are configured to allow
+ monitoring, protection, and management of the LSP concatenated
+ segments. One SPME is defined between LER2 and LER3, and a second
+ SPME is set up between LER4 and LER5. Each of these SPMEs may be
+ monitored, protected, or managed independently.
+
+ |<============================= LSP =============================>|
+
+ |<---- Carrier 1 ---->| |<---- Carrier 2 ---->|
+
+ |LER1|---|LER2|---|LSR|---|LER3|-------|LER4|---|LSR|---|LER5|---|LER6|
+
+ |====== SPME =========| |====== SPME =========|
+ (Carrier 1) (Carrier 2)
+
+ Note 1: LER2, LER3, LER4, and LER5 are with respect to the SPME,
+ but LSRs with respect to the LSP.
+ Note 2: The LSP terminates in LERs outside of Carrier 1 and
+ Carrier 2, for example, LER1 and LER6.
+
+ Figure 17: SPMEs in Inter-Carrier Network
+
+
+
+Bocci, et al. Informational [Page 45]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ The end-to-end traffic of the LSP, including data traffic and control
+ traffic (OAM, Protection Switching Control, management and signaling
+ messages) is tunneled within the hierarchical LSP by means of label
+ stacking as defined in [RFC3031].
+
+ The mapping between an LSP and a SPME can be 1:1, in which case it is
+ similar to the ITU-T Tandem Connection Element [G.805]. The mapping
+ can also be 1:N to allow aggregated monitoring, protection, and
+ management of a set of LSP segments or concatenated LSP segments.
+ Figure 18 shows a SPME that is used to aggregate a set of
+ concatenated LSP segments for the LSP from LERx to LERt and the LSP
+ from LERa to LERd. Note that such a construct is useful, for
+ example, when the LSPs traverse a common portion of the network and
+ they have the same Traffic Class.
+
+ The QoS aspects of a SPME are network specific. [OAM-FRAMEWORK]
+ provides further considerations on the QoS aspects of OAM.
+
+ |LERx|--|LSRy|-+ +-|LSRz|--|LERt|
+ | |
+ | |<---------- Carrier 1 --------->| |
+ | +-----+ +---+ +---+ +-----+ |
+ +--| |---| |---| |----| |--+
+ |LER1 | |LSR| |LSR| |LER2 |
+ +--| |---| |---| |----| |--+
+ | +-----+ +---+ + P + +-----+ |
+ | |============ SPME ==============| |
+ |LERa|--|LSRb|-+ (Carrier 1) +-|LSRc|--|LERd|
+
+ Figure 18: SPME for a Set of Concatenated LSP Segments
+
+ SPMEs can be provisioned either statically or using control-plane
+ signaling procedures. The make-before-break procedures which are
+ supported by MPLS allow the creation of a SPME on existing LSPs in-
+ service without traffic disruption, as described in [SURVIVE-FWK]. A
+ SPME can be defined corresponding to one or more end-to-end LSPs.
+ New end-to-end LSPs that are tunneled within the SPME can be set up,
+ which may require coordination across administrative boundaries.
+ Traffic of the existing LSPs is switched over to the new end-to-end
+ tunneled LSPs. The old end-to-end LSPs can then be torn down.
+
+ Hierarchical label stacking, in a similar manner to that described
+ above, can be used to implement Sub-Path Maintenance Elements on
+ pseudowires, as described in [OAM-FRAMEWORK].
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 46]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+3.14. Network Management
+
+ The network management architecture and requirements for MPLS-TP are
+ specified in [NM-FRAMEWORK] and [NM-REQ]. These derive from the
+ generic specifications described in ITU-T G.7710/Y.1701 [G.7710] for
+ transport technologies. They also incorporate the OAM requirements
+ for MPLS Networks [RFC4377] and MPLS-TP Networks [RFC5860] and expand
+ on those requirements to cover the modifications necessary for fault,
+ configuration, performance, and security in a transport network.
+
+ 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
+ which a management system manages the NE. The Management
+ Communication Channel (MCC), realized by the G-ACh, provides a
+ logical operations channel between NEs for transferring management
+ information. The Network Management System (NMS) can be used to
+ provision and manage an end-to-end connection across a network.
+ Maintenance operations are run on a connection (LSP or PW) in a
+ manner that is independent of the provisioning mechanism. Segments
+ may be created or managed by, for example, Netconf [RFC4741], SNMP
+ [RFC3411], or CORBA (Common Object Request Broker Architecture)
+ interfaces, but not all segments need to be created or managed using
+ the same type of interface. Where an MPLS-TP NE is managed by an
+ NMS, at least one of these standard management mechanisms is required
+ for interoperability, but this document imposes no restriction on
+ which of these standard management protocols is used. In MPLS-TP,
+ the EMF needs to support statically provisioning LSPs for an LSR or
+ 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
+ enable the supervision, detection, validation, isolation, correction,
+ and alarm handling of abnormal conditions in the MPLS-TP network and
+ its environment. FM needs to provide for the supervision of
+ transmission (such as continuity, connectivity, etc.), software
+ processing, hardware, and environment. Alarm handling includes alarm
+ severity assignment, alarm suppression/aggregation/correlation, alarm
+ reporting control, and alarm reporting.
+
+ Configuration Management (CM) provides functions to control,
+ identify, collect data from, and provide data to MPLS-TP NEs. In
+ addition to general configuration for hardware, software protection
+ switching, alarm reporting control, and date/time setting, the EMF of
+ the MPLS-TP NE also supports the configuration of maintenance entity
+ identifiers (such as Maintenance Entity Group Endpoint (MEP) ID and
+ MEG Intermediate Point (MIP) ID). The EMF also supports the
+ configuration of OAM parameters as a part of connectivity management
+ to meet specific operational requirements. These may specify whether
+
+
+
+Bocci, et al. Informational [Page 47]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ the operational mode is one-time on-demand or is periodic at a
+ specified frequency.
+
+ The Performance Management (PM) functions within the EMF of an
+ MPLS-TP NE support the evaluation and reporting of the behavior of
+ the NEs and the network. One particular requirement for PM is to
+ provide coherent and consistent interpretation of the network
+ behavior in a hybrid network that uses multiple transport
+ technologies. Packet loss measurement and delay measurements may be
+ collected and used to detect performance degradation. This is
+ reported via fault management to enable corrective actions to be
+ taken (e.g., protection switching) and via performance monitoring for
+ Service Level Agreement (SLA) verification and billing. Collection
+ mechanisms for performance data should be capable of operating on-
+ demand or proactively.
+
+4. Security Considerations
+
+ The introduction of MPLS-TP into transport networks means that the
+ security considerations applicable to both MPLS [RFC3031] and PWE3
+ [RFC3985] apply to those transport networks. When an MPLS function
+ is included in the MPLS transport profile, the security
+ considerations pertinent to that function apply to MPLS-TP.
+ Furthermore, when general MPLS networks that utilize functionality
+ outside of the strict MPLS Transport Profile are used to support
+ packet transport services, the security considerations of that
+ additional functionality also apply.
+
+ For pseudowires, the security considerations of [RFC3985] and
+ [RFC5659] apply.
+
+ MPLS-TP nodes that implement the G-ACh create a Control Channel (CC)
+ associated with a pseudowire, LSP, or section. This control channel
+ can be signaled or statically configured. Over this control channel,
+ control channel messages related to network maintenance functions
+ such as OAM, signaling, or network management are sent. Therefore,
+ three different areas are of concern from a security standpoint.
+
+ The first area of concern relates to control plane parameter and
+ status message attacks, that is, attacks that concern the signaling
+ of G-ACh capabilities. MPLS-TP Control Plane security is discussed
+ in [RFC5920].
+
+ A second area of concern centers on data-plane attacks, that is,
+ attacks on the G-ACh itself. MPLS-TP nodes that implement the G-ACh
+ mechanisms are subject to additional data-plane denial-of-service
+ attacks as follows:
+
+
+
+
+Bocci, et al. Informational [Page 48]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ An intruder could intercept or inject G-ACh packets effectively
+ disrupting the protocols carried over the G-ACh.
+
+ An intruder could deliberately flood a peer MPLS-TP node with
+ G-ACh messages to deny services to others.
+
+ A misconfigured or misbehaving device could inadvertently flood a
+ peer MPLS-TP node with G-ACh messages that could result in denial
+ of services. In particular, if a node has either implicitly or
+ explicitly indicated that it cannot support one or all of the
+ types of G-ACh protocol, but is sent those messages in sufficient
+ quantity, it could result in a denial of service.
+
+ To protect against these potential (deliberate or unintentional)
+ attacks, multiple mitigation techniques can be employed:
+
+ G-ACh message throttling mechanisms can be used, especially in
+ distributed implementations that have a centralized control-plane
+ processor with various line cards attached by some control-plane
+ data path. In these architectures, G-ACh messages may be
+ processed on the central processor after being forwarded there by
+ the receiving line card. In this case, the path between the line
+ card and the control processor may become saturated if appropriate
+ G-ACh traffic throttling is not employed, which could lead to a
+ complete denial of service to users of the particular line card.
+ Such filtering is also useful for preventing the processing of
+ unwanted G-ACh messages, such as those which are sent on unwanted
+ (and perhaps unadvertised) control channel types.
+
+ A third and last area of concern relates to the processing of the
+ actual contents of G-ACh messages. It is necessary that the
+ definition of the protocols using these messages carried over a G-ACh
+ include appropriate security measures.
+
+ Additional security considerations apply to each MPLS-TP solution.
+ These are discussed further in [SEC-FRAMEWORK].
+
+ The security considerations in [RFC5920] apply.
+
+5. IANA Considerations
+
+ IANA considerations resulting from specific elements of MPLS-TP
+ functionality will be detailed in the documents specifying that
+ functionality.
+
+ This document introduces no additional IANA considerations in itself.
+
+
+
+
+
+Bocci, et al. Informational [Page 49]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+6. Acknowledgements
+
+ The editors wish to thank the following for their contributions to
+ this document:
+
+ o Rahul Aggarwal
+
+ o Dieter Beller
+
+ o Malcolm Betts
+
+ o Italo Busi
+
+ o John E Drake
+
+ o Hing-Kam Lam
+
+ o Marc Lasserre
+
+ o Vincenzo Sestito
+
+ o Nurit Sprecher
+
+ o Martin Vigoureux
+
+ o Yaacov Weingarten
+
+ o The participants of ITU-T SG15
+
+7. References
+
+7.1. Normative References
+
+ [G.7710] ITU-T, "Common equipment management function
+ requirements", ITU-T Recommendation G.7710/Y.1701,
+ July 2007.
+
+ [G.805] ITU-T, "Generic Functional Architecture of Transport
+ Networks", ITU-T Recommendation G.805, November
+ 1995.
+
+ [RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
+ "Multiprotocol Label Switching Architecture", RFC
+ 3031, January 2001.
+
+ [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
+ Farinacci, D., Li, T., and A. Conta, "MPLS Label
+ Stack Encoding", RFC 3032, January 2001.
+
+
+
+Bocci, et al. Informational [Page 50]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
+ Vaananen, P., Krishnan, R., Cheval, P., and J.
+ Heinanen, "Multi-Protocol Label Switching (MPLS)
+ Support of Differentiated Services", RFC 3270, May
+ 2002.
+
+ [RFC3473] Berger, L., "Generalized Multi-Protocol Label
+ Switching (GMPLS) Signaling Resource ReserVation
+ Protocol-Traffic Engineering (RSVP-TE) Extensions",
+ RFC 3473, January 2003.
+
+ [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-
+ to-Edge (PWE3) Architecture", RFC 3985, March 2005.
+
+ [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
+ Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
+ May 2005.
+
+ [RFC4385] Bryant, S., Swallow, G., Martini, L., and D.
+ McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3)
+ Control Word for Use over an MPLS PSN", RFC 4385,
+ February 2006.
+
+ [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and
+ G. Heron, "Pseudowire Setup and Maintenance Using
+ the Label Distribution Protocol (LDP)", RFC 4447,
+ April 2006.
+
+ [RFC4872] Lang, J., Rekhter, Y., and D. Papadimitriou,
+ "RSVP-TE Extensions in Support of End-to-End
+ Generalized Multi-Protocol Label Switching (GMPLS)
+ Recovery", RFC 4872, May 2007.
+
+ [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual
+ Circuit Connectivity Verification (VCCV): A Control
+ Channel for Pseudowires", RFC 5085, December 2007.
+
+ [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS
+ Generic Associated Channel", RFC 5586, June 2009.
+
+7.2. Informative References
+
+ [CP-FRAMEWORK] Andersson, L., Berger, L., Fang, L., Bitar, N.,
+ Takacs, A., Vigoureux, M., Bellagamba, E., and E.
+ Gray, "MPLS-TP Control Plane Framework", Work in
+ Progress, March 2010.
+
+
+
+
+
+Bocci, et al. Informational [Page 51]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ [DATA-PLANE] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport
+ Profile Data Plane Architecture", Work in Progress,
+ July 2010.
+
+ [DYN-MS-PW] Martini, L., Bocci, M., Balus, F., Bitar, N., Shah,
+ H., Aissaoui, M., Rusmisel, J., Serbest, Y., Malis,
+ A., Metz, C., McDysan, D., Sugimoto, J., Duckett,
+ M., Loomis, M., Doolan, P., Pan, P., Pate, P.,
+ Radoaca, V., Wada, Y., and Y. Seo, "Dynamic
+ Placement of Multi Segment Pseudo Wires", Work in
+ Progress, October 2009.
+
+ [G.8080] ITU-T, "Architecture for the automatically switched
+ optical network (ASON)", ITU-T Recommendation
+ G.8080/Y.1304, 2005.
+
+ [IDENTIFIERS] Bocci, M. and G. Swallow, "MPLS-TP Identifiers",
+ Work in Progress, March 2010.
+
+ [NM-FRAMEWORK] Mansfield, S., Ed., Gray, E., Ed., and H. Lam, Ed.,
+ "MPLS-TP Network Management Framework", Work in
+ Progress, February 2010.
+
+ [NM-REQ] Mansfield, S. and K. Lam, "MPLS TP Network
+ Management Requirements", Work in Progress, October
+ 2009.
+
+ [OAM-DEF] Andersson, L., Helvoort, H., Bonica, R., Romascanu,
+ D., and S. Mansfield, "The OAM Acronym Soup", Work
+ in Progress, June 2010.
+
+ [OAM-FRAMEWORK] Busi, I., Ed., Niven-Jenkins, B., Ed., and D. Allan,
+ Ed., "MPLS-TP OAM Framework", Work in Progress,
+ April 2010.
+
+ [PW-REDUNDANCY] Muley, P., "Pseudowire (PW) Redundancy", Work in
+ Progress, May 2010.
+
+ [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.
+
+
+
+
+
+Bocci, et al. Informational [Page 52]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL)
+ Processing in Multi-Protocol Label Switching (MPLS)
+ Networks", RFC 3443, January 2003.
+
+ [RFC3471] Berger, L., "Generalized Multi-Protocol Label
+ Switching (GMPLS) Signaling Functional Description",
+ RFC 3471, January 2003.
+
+ [RFC3945] Mannie, E., "Generalized Multi-Protocol Label
+ Switching (GMPLS) Architecture", RFC 3945, October
+ 2004.
+
+ [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual
+ Private Networks (VPNs)", RFC 4364, February 2006.
+
+ [RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and
+ S. Matsushima, "Operations and Management (OAM)
+ Requirements for Multi-Protocol Label Switched
+ (MPLS) Networks", RFC 4377, February 2006.
+
+ [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-
+ Protocol Label Switched (MPLS) Data Plane Failures",
+ RFC 4379, February 2006.
+
+ [RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2
+ Virtual Private Networks (L2VPNs)", RFC 4664,
+ September 2006.
+
+ [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A
+ Framework for Inter-Domain Multiprotocol Label
+ Switching Traffic Engineering", RFC 4726, November
+ 2006.
+
+ [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC
+ 4741, December 2006.
+
+ [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 L. Martini, "Requirements
+ for Multi-Segment Pseudowire Emulation Edge-to-Edge
+ (PWE3)", RFC 5254, October 2008.
+
+ [RFC5309] Shen, N. and A. Zinin, "Point-to-Point Operation
+ over LAN in Link State Routing Protocols", RFC 5309,
+ October 2008.
+
+
+
+Bocci, et al. Informational [Page 53]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS
+ Upstream Label Assignment and Context-Specific Label
+ Space", RFC 5331, August 2008.
+
+ [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M.,
+ Sprecher, N., and S. Ueno, "Requirements of an MPLS
+ Transport Profile", RFC 5654, September 2009.
+
+ [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
+ Segment Pseudowire Emulation Edge-to-Edge", 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.
+
+ [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements
+ for Operations, Administration, and Maintenance
+ (OAM) in MPLS Transport Networks", RFC 5860, May
+ 2010.
+
+ [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G.
+ Swallow, "Bidirectional Forwarding Detection (BFD)
+ for MPLS Label Switched Paths (LSPs)", RFC 5884,
+ June 2010.
+
+ [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional
+ Forwarding Detection (BFD) for the Pseudowire
+ Virtual Circuit Connectivity Verification (VCCV)",
+ RFC 5885, June 2010.
+
+ [RFC5920] Fang, L., Ed., "Security Framework for MPLS and
+ GMPLS Networks", RFC 5920, July 2010.
+
+ [ROSETTA-STONE] Sprecher, N., "A Thesaurus for the Terminology used
+ in Multiprotocol Label Switching Transport Profile
+ (MPLS-TP) drafts/RFCs and ITU-T's Transport Network
+ Recommendations.", Work in Progress, May 2010.
+
+ [SEC-FRAMEWORK] Fang, L. and B. Niven-Jenkins, "Security Framework
+ for MPLS-TP", Work in Progress, March 2010.
+
+ [SEGMENTED-PW] Martini, L., Nadeau, T., Metz, C., Bocci, M., and M.
+ Aissaoui, "Segmented Pseudowire", Work in Progress,
+ June 2010.
+
+
+
+
+
+
+Bocci, et al. Informational [Page 54]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+ [SURVIVE-FWK] Sprecher, N. and A. Farrel, "Multiprotocol Label
+ Switching Transport Profile Survivability
+ Framework", Work in Progress, June 2010.
+
+ [VPMS-REQS] Kamite, Y., JOUNAY, F., Niven-Jenkins, B., Brungard,
+ D., and L. Jin, "Framework and Requirements for
+ Virtual Private Multicast Service (VPMS)", Work in
+ Progress, October 2009.
+
+ [X.200] ITU-T, "Information Technology - Open Systems
+ Interconnection - Basic reference Model: The Basic
+ Model", ITU-T Recommendation X.200, 1994.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 55]
+
+RFC 5921 MPLS Transport Profile Framework July 2010
+
+
+Authors' Addresses
+
+ Matthew Bocci (editor)
+ Alcatel-Lucent
+ Voyager Place, Shoppenhangers Road
+ Maidenhead, Berks SL6 2PJ
+ United Kingdom
+
+ EMail: matthew.bocci@alcatel-lucent.com
+
+
+ Stewart Bryant (editor)
+ Cisco Systems
+ 250 Longwater Ave
+ Reading RG2 6GB
+ United Kingdom
+
+ EMail: stbryant@cisco.com
+
+
+ Dan Frost (editor)
+ Cisco Systems
+
+ EMail: danfrost@cisco.com
+
+
+ Lieven Levrau
+ Alcatel-Lucent
+ 7-9, Avenue Morane Sulnier
+ Velizy 78141
+ France
+
+ EMail: lieven.levrau@alcatel-lucent.com
+
+
+ Lou Berger
+ LabN Consulting, L.L.C.
+
+ EMail: lberger@labn.net
+
+
+
+
+
+
+
+
+
+
+
+
+Bocci, et al. Informational [Page 56]
+