RFC 5921
A Framework for MPLS in Transport Networks
RFC 5921: A Framework for MPLS in Transport Networks ✨
okay bestie, this is RFC 5921 🎀 It came out in July 2010 and it's from the IETF (Internet Engineering Task Force). The Category is Informational 💅 which means it's published for information, not as an Internet Standards Track spec (more on that in the Status section, don't worry). The ISSN is 2070-1721 🦋
The authors are M. Bocci, Ed. (Alcatel-Lucent), S. Bryant, Ed. and D. Frost, Ed. (Cisco Systems), L. Levrau (Alcatel-Lucent), and L. Berger (LabN) 👑 Also, the header doesn't have any "Obsoletes" or "Updates" line, so this doc isn't listed as replacing or changing any earlier RFC 🙈
Abstract 💖
okay so this doc is basically a blueprint for using MPLS (Multiprotocol Label Switching) to build packet-switched transport networks 🦋 It defines a shared set of protocol functions called the MPLS Transport Profile (MPLS-TP), which is built for the way transport networks actually work. That means signaled or explicitly provisioned bidirectional connection-oriented paths, protection and restoration, super thorough Operations, Administration, and Maintenance (OAM) functions, and running the network without a dynamic control plane or IP forwarding support 🧚 Some of these functions already exist in MPLS specs, and others need extensions so they can meet the MPLS-TP requirements ✨
This doc only covers the part of MPLS-TP that applies in general and to point-to-point transport paths 💅 The rest, which is for point-to-multipoint transport paths, is outside the scope of this doc 🌸
It's also a joint effort between the IETF and the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) 🌈 The goal is to bring an MPLS Transport Profile into the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures so they can support what a packet transport network looks like as defined by the ITU-T 🫶
Status of This Memo 🌷
This doc is not an Internet Standards Track specification, it's published for informational purposes 💅
It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community ✨ It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 if you want the details 🙈
You can find info on the current status of this doc, any errata, and how to send feedback 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 doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the date this doc was published. Please read these carefully, because they explain your rights and restrictions for this doc 💅 Code Components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🫶
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
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.1. Normative References . . . . . . . . . . . . . . . . . . . 50
7.2. Informative References . . . . . . . . . . . . . . . . . . 511. Introduction ✨
1.1. Motivation and Background 🦋
okay so this doc describes an architectural framework for using MPLS to build packet-switched transport networks 💖 It lays out the common set of protocol functions that meet the requirements in [RFC5654], and together they make up the MPLS Transport Profile (MPLS-TP) for point-to-point transport paths 🫶 The rest of the MPLS-TP functions, the ones for point-to-multipoint transport paths, are outside the scope of this doc 🌸
Historically, the optical transport infrastructure, meaning Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) and Optical Transport Network (OTN), has given carriers a really high benchmark for reliability and operational simplicity 👑 To get there, transport technologies were built with some specific characteristics:
- Strictly connection-oriented connectivity, which may be long-lived and may be provisioned manually, for example by network management systems or by direct node configuration using a command line interface.
- A high level of availability.
- Quality of service.
- Extensive Operations, Administration, and Maintenance (OAM) capabilities.
Carriers want to evolve these transport networks so they can use the flexibility and cost benefits of packet switching and support packet-based services more efficiently 🧚 MPLS is a maturing packet technology that already plays an important role in transport networks and services, but not every MPLS capability and mechanism is needed in, or consistent with, the transport network operational model 😭 There are also transport technology characteristics that MPLS doesn't currently reflect 🙈
So MPLS-TP has two objectives:
- To enable MPLS to be deployed in a transport network and operated in a similar manner to existing transport technologies.
- To enable MPLS to support packet transport services with a similar degree of predictability to that found in existing transport networks.
To hit these objectives, we need a common set of MPLS protocol functions, an MPLS Transport Profile, for using MPLS in transport networks and applications 💅 Some of the necessary functions already exist in MPLS specs, and others need additions to the MPLS tool-set. Those additions should, wherever possible, also apply to MPLS networks in general, not just the ones that match the transport network model strictly 🌈
This doc 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, so they can support the capabilities and functionalities of a packet transport network as defined by the ITU-T 💜
1.2. Scope 🎀
Same vibe as the intro, bestie: this doc describes an architectural framework for applying MPLS to building packet-switched transport networks 💖 It specifies the common set of protocol functions that meet the requirements in [RFC5654], which 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 doc 🦋
Part 1 of 12 is done 🫶 Next up is Section 1.3 (Terminology), so stay tuned bestie 🧚
1.3. Terminology 📚✨
okay bestie, this is the acronym soup section 🍲 and honestly it's giving alphabet overload, but the table below has every term you'll see later, so screenshot it 📸 here's the full list, copied exactly:
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
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 Verification1.3.1. Transport Network 🚚
a Transport Network is basically the delivery service 💅 it provides transparent transmission of user traffic between attached client devices by setting up and keeping up point-to-point or point-to-multipoint connections between those devices. the architecture of networks that support point-to-multipoint connections is outside the scope of this document, so we're not going there today 🙈 a Transport Network is independent of any higher-layer network that might exist between clients, except to the extent needed to supply this transmission service. and on top of client traffic, it may carry its own traffic to help it run, like 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]. ngl this is the whole vibe: it's MPLS but curated 💜 also, MPLS is defined to include any present and future MPLS capability specified by the IETF, including the ones that were specifically added to support transport network requirements [RFC5654] ✨
1.3.3. MPLS-TP Section 🧵
MPLS-TP sections are defined in [DATA-PLANE]. also check out 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 so it can meet the requirements of an MPLS transport network as set out in [RFC5654]. the main characteristics of an MPLS-TP LSP are that it:
- Uses a subset of the MPLS OAM tools defined in [OAM-FRAMEWORK].
- Supports 1+1, 1:1, and 1:N protection functions.
- Is traffic engineered.
- May be established and maintained via the management plane, or using GMPLS protocols when a control plane is used.
- Is either point-to-point or point-to-multipoint. Multipoint-to-point and multipoint-to-multipoint LSPs are not supported 🚫
- 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 the ones specifically added to support the transport network requirements 🌈
see [DATA-PLANE] for more 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 between an MPLS-TP LSP and its client layers is explained 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, so a specific node may only take on one of these roles on a given LSP 👑
note that the word "router" in this context is historic and neither requires nor precludes the ability to perform IP forwarding. it's a naming thing, not a rule 🙃
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., it 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 so it can be transported over an MPLS-TP LSP. encapsulation can be as simple as pushing a label, or it may require the use of a pseudowire. an MPLS-TP PE sits 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 🎯
the term Provider Edge refers to the node's role within a provider's network. a provider edge router lives 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. the exception is 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 it doesn't 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 the following, and I'm keeping it word for word because it matters 🫡
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 the following 💅
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.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 they 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 it's 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]. it provides for the transfer of client information and independent operation of the client OAM. a layer network can be described in a service context like this: 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 the 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 so it 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 it's 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:
- User-Network Interface (UNI) (see Section 3.4.3.1).
- Network-Network Interface (NNI) (see Section 3.4.3.2).
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 is in turn 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's 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 ✨
okay so if you want the full details and extra terminology, go check out [RFC5654] and [ROSETTA-STONE] 📚🎀
2. MPLS Transport Profile Requirements 💖
bestie, the requirements for MPLS-TP are spelled out in [RFC5654], [RFC5860], and [NM-REQ] 🧚 this section is just a quick reminder to get you oriented. it's not normative and it's not meant to replace those docs, so don't treat it as the official word 💅
MPLS-TP must not modify the MPLS forwarding architecture and must be based on existing pseudowire and LSP constructs. no reinventing the wheel here, it's giving "build on what already works" 🔥
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. so the LSPs stay separate, and you should be able to spot it if they somehow don't 👀
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. the vibe is "works with or without the fancy automation" 🦋
OAM and protection mechanisms, and forwarding of data packets, must be able to operate without IP forwarding support. no IP forwarding needed, periodt 💜
it must be possible to monitor LSPs and pseudowires through the use of OAM in the absence of control-plane or routing functions. in that case, the info OAM gathers is used to kick off path recovery actions at either the PW or LSP layers. so even with no control plane, OAM is still out here doing its job 🛡️
3. MPLS Transport Profile Overview 🌸
3.1. Packet Transport Services 🎀
okay so one big goal of MPLS-TP is getting MPLS networks to give packet transport services with about the same predictability you'd get from existing transport networks. these services have a bunch of characteristics, which are defined in [RFC5654]:
- 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, operation of the MPLS-TP layer network must be possible without any dependencies on either the server or client layer network. main character energy, it stands on its own 👑
- the service the MPLS-TP network gives a given client will not fall below the agreed level because of the traffic loading of other clients. no dropping the ball for one client because another one is busy 💅
- the control and management planes of any client network layer that uses the service are 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. boundaries, honey 🫶
- 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). ideally zero drama between them 🌈
- 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. even the non-MPLS packets get a ride, like IP or CLNS packets from the client's own control and management plane 🧚
- 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. nobody sees the other's secrets, it's giving privacy 🙈
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. so it can carry connectionless traffic, it just doesn't do connectionless forwarding itself, ngl kinda subtle but iykyk 🦋
3.2. Scope of the MPLS Transport Profile 🍓
Figure 1 shows the scope of MPLS-TP. MPLS-TP solutions are mainly meant for packet transport applications. MPLS-TP is a strict subset of MPLS, and it only includes the functions needed to meet the requirements of [RFC5654]. that includes MPLS functions that were defined before [RFC5654] but still meet its requirements, plus extra functions defined to meet those requirements. some MPLS functions from before [RFC5654], like Equal Cost Multi-Path (ECMP), LDP signaling when it's used in a way that creates multipoint-to-point LSPs, and IP forwarding in the data plane, are explicitly excluded from MPLS-TP by that requirements spec. not everything gets an invite 💀
note that MPLS as a whole will keep evolving to add functions that don't conform to the MPLS Transport Profile or its requirements, and those fall outside the scope of MPLS-TP. MPLS grows, but MPLS-TP stays in its lane 🌸
|<============================== 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-TPMPLS-TP can be used to build packet networks, so it's applicable in any packet network context 🌈 a subset of MPLS-TP also applies to ITU-T-defined packet transport networks, where the transport network operational model is seen as attractive 💜
3.3. Architecture 🧚
MPLS-TP is made up of the following architectural elements:
- a standard MPLS data plane [RFC3031] as profiled in [DATA-PLANE]. the foundation, no notes ✨
- Sections, LSPs, and PWs that provide a packet transport service for a client network. the actual pipes 🎀
- proactive and on-demand Operations, Administration, and Maintenance (OAM) functions to monitor and diagnose the MPLS-TP network, as outlined in [OAM-FRAMEWORK]. the monitoring squad 👀
- control planes for LSPs and PWs, as well as support for static provisioning and configuration, as outlined in [CP-FRAMEWORK] 🔥
- 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] 🛡️
- control-plane-based restoration mechanisms, as outlined in [SURVIVE-FWK] 🦋
- network management functions, as outlined in [NM-FRAMEWORK] 💅
the MPLS-TP architecture for LSPs and PWs includes the following two sets of functions:
- MPLS-TP native service adaptation
- 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 are the mechanisms needed to forward 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] 🧚
the purpose of this encapsulation is to abstract the data plane of the client layer network from the MPLS-TP data plane, which helps the MPLS-TP network operate independently 🦋
MPLS-TP is itself a client of an underlying server layer. so MPLS-TP is also bounded by a set of adaptation functions to this server layer network, which may itself be MPLS-TP. these adaptation functions encapsulate the MPLS-TP frames and transparently transport them 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. so the server layer needs to provide the QoS necessary for the MPLS-TP client's QoS commitments to be satisfied. it's a whole chain of responsibility, bestie 🔥
3.3.2. MPLS-TP Forwarding Functions 💖
the forwarding functions are the mechanisms needed to forward 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 the MPLS-TP profile does not modify them 🚀
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 the next hop should perform 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 that you have to account for when designing protocol extensions (such as those for OAM) that need packets sent to an intermediate LSR 🧠💅
further processing to work out the context of a packet happens when a swap operation gets interrupted this way, when a pop operation exposes a specific reserved label at the top of the stack, or when the 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:
- a PW
- 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
okay so the relationship between the client layer network and the MPLS-TP server layer network 💖 is set by the MPLS-TP network boundary and the label context. it's not spelled out in the packet itself, so you have to work it out from those two things ✨
in terms of the MPLS label stack, when the native service traffic type is already MPLS-labeled, 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 its S bit set to 1. so basically, only one S bit can be set in a label stack, and that's the rule 🎀
the data plane of MPLS-TP works exactly like the best current practice for MPLS, including how the S bit gets set 🫶. the S bit marks the bottom (innermost) label in the label stack that's contiguous between the MPLS-TP LSP and its payload, and only one label stack entry (LSE) has the S bit (Bottom of Stack bit) set to 1 🌈. ngl this best current practice is a tiny bit different from [RFC3032], which uses the S bit to show where MPLS label processing stops and network layer processing starts 🙈
here's how MPLS-TP connects to its clients in Figure 2. the label stacks in the figure are split between the ones inside the MPLS-TP network and the ones inside the client network (when the client network is MPLS(-TP)) 🦋. they show the smallest possible number of labels, but these stacks could also have more labels, so don't be surprised 💅
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 Relationship3.4.2. MPLS-TP Transport Layers
an MPLS-TP network is made of two logical layers: the Transport Service layer and the Transport Path layer 🌸
the Transport Service layer is the bit that sits between the Customer Edge (CE) nodes and the MPLS-TP network 💜. every packet a CE sends for transport over the MPLS-TP network gets linked, at the receiving MPLS-TP Provider Edge (PE) node, to one logical point-to-point connection at the Transport Service layer. that connection runs between this (ingress) PE and the matching (egress) PE that the peer CE is plugged into ✨. this connection is called an MPLS-TP Transport Service Instance, and the set of client packets that belong to the native service tied to that instance on one specific CE-PE link is called a client flow 🎀
the Transport Path layer is where Transport Service Instances get aggregated over MPLS-TP transport paths (LSPs), and also where transport paths get aggregated (via LSP hierarchy) 🧚
only PE nodes need to know about the Transport Service layer 🫶. MPLS-TP Provider (P) nodes don't need any awareness of it at all 🙈. both PE and P nodes take part in the Transport Path layer. a PE terminates (i.e., is an LER with respect to) the transport paths it supports, and it's the one responsible for multiplexing and demultiplexing Transport Service Instance traffic over those paths 👑
3.4.3. MPLS-TP Transport Service Interfaces
an MPLS-TP PE node can offer two kinds of interface to the Transport Service layer 🌈. the MPLS-TP User-Network Interface (UNI) is the one between a CE and the MPLS-TP network 💅. the MPLS-TP Network-Network Interface (NNI) is the one between two MPLS-TP PEs that live in different administrative domains 🦋
when MPLS-TP is providing a transport service for things like IP services that are part of a Layer 3 VPN, packets get transported the same way as specified in [RFC4364] 💖
3.4.3.1. User-Network Interface
the MPLS-TP User-Network Interface (UNI) is shown in Figure 3 ✨. for a given client flow, the UNI may or may not involve signaling between the CE and PE 🌸. and if signaling does happen, it may or may not go over the same attachment circuit that carries the client flow 🫶
: 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 --------------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 StagesFigure 4 walks through the logical processing a PE does in both directions 🎀. the left-to-right flow is traffic going from the CE into the MPLS-TP network, and the right-to-left flow is traffic going from the network back to the CE 🔥
going CE → network, here's what happens when a packet from a client flow shows up at the PE from the CE over the data-link 💅:
- link-layer-specific pre-processing happens first, if there's any 🧚. an example is the PREP function shown in Figure 3 of [RFC3985]. this pre-processing is outside the scope of MPLS-TP, so no spoilers there 🙈
- the packet gets pulled out of the data-link frame if needed, and gets associated with a Transport Service Instance 🫶. at this point, UNI processing is done ✨
- a transport service encapsulation gets attached to the packet if it's needed for transport over the MPLS-TP network 🌸
- the packet gets mapped to a transport path based on its Transport Service Instance, the transport path encapsulation gets added if needed, and then the packet is sent over that transport path 🦋
going network → CE, when a packet tied to a Transport Service Instance arrives over a transport path, these steps happen 💜:
- the transport path encapsulation gets thrown away 🙈
- the transport service encapsulation gets thrown away too, and the Transport Service Instance and client flow get identified 🌈
- this is where UNI processing starts 👑. a data-link encapsulation gets attached to the packet for delivery to the CE, based on the client flow ✨
- link-layer-specific post-processing happens, if there's any. that post-processing is also outside the scope of MPLS-TP 💖
3.4.3.2. Network-Network Interface ✨
okay so the NNI is the spot where two PEs meet up 🫶 Figure 5 shows it. For a given Transport Service Instance, there may or may not be signaling between the two PEs, and if there is signaling, it may or may not ride the same data-link that carries the service instance. literally so flexible 💅
: 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
:
--------------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 StagesFigure 6 shows the logical processing steps a PE goes through for traffic coming from the peer PE (left to right) and traffic going to the peer PE (right to left). it's giving flowchart energy 🌸
In the first case, a packet from a Transport Service Instance shows up at the PE from the peer PE over the data-link, and then these steps happen:
- Link-layer specific pre-processing, if any, is performed. Such pre-processing is outside the scope of MPLS-TP.
- 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.
- 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.
- 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, a packet associated with a Transport Service Instance arrives over a transport path, and the steps go like this 🦋
- The transport path encapsulation is disposed of.
- 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).
- 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.
- 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 looks at a few special cases of UNI processing for specific transport service types. they're just illustrative 🧚 and they don't rule out other transport service types, so don't read them as the whole menu bestie 💜
3.4.3.3.1. Layer 2 Transport Service 🍓
in this example the MPLS-TP network gives a point-to-point Layer 2 transport service between attached CE nodes. the service is delivered by a Transport Service Instance made of a PW set up between the associated PE nodes. the client flows for this Transport Service Instance are all the Layer 2 frames sent and received over the attachment circuits. main character energy 👑
The processing steps for a frame received from the CE go like this:
- Link-layer specific pre-processing, if any, is performed, corresponding to the PREP function illustrated in Figure 3 of [RFC3985].
- The frame is associated with a Transport Service Instance based on the attachment circuit over which it was received.
- A transport service encapsulation, consisting of the PW control word and PW label, is associated with the frame.
- 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 run in the reverse order 🔁
3.4.3.3.2. IP Transport Service 💖
in this example the MPLS-TP network gives a point-to-point IP transport service between CE1, CE2, and CE3, and it works like this 🌈 One point-to-point Transport Service Instance delivers IPv4 packets between CE1 and CE2, and another instance delivers IPv6 packets between CE1 and CE3. two services, one network, zero drama 💅
The processing steps for an IP packet received from CE1 go like this:
- No link-layer-specific processing is performed.
- 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.
- A transport service encapsulation, consisting of the Service LSP label, is associated with the packet.
- 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 run in the reverse order. ✨
3.4.4. Pseudowire Adaptation ✨
okay so MPLS-TP can carry some really big services using pseudowires (PWs) 🎀 There are four main ones: a Virtual Private Wire Service (VPWS), a Virtual Private LAN Service (VPLS), a Virtual Private Multicast Service (VPMS), and an Internet Protocol Local Area Network Service (IPLS). VPWS, VLPS (the RFC spells it that way 🙈), and IPLS are covered in [RFC4664], and VPMS is covered in [VPMS-REQS].
If the MPLS-TP network gives you a layer 2 interface as a service, the kind that can carry both network-layer and non-network-layer traffic 🦋, then a PW is required to support that service interface. The PW is a client of the MPLS-TP LSP server layer. The architecture for this kind of network is built on the MPLS [RFC3031] and pseudowire [RFC3985] architectures, so it's giving tried and true 💅 Multi-segment pseudowires are optional for providing a packet transport service, and using them still fits the MPLS-TP architecture 🌸 If you do go the MS-PW route, you'll want the motivations from [RFC5254], and the MS-PW architecture [RFC5659] applies too.
Figure 7 shows the architecture for an MPLS-TP network that uses single-segment PWs. Quick note: in this document, the client layer is the same thing as the emulated service in [RFC3985], and the Transport LSP is the same thing as the Packet Switched Network (PSN) tunnel from that same RFC 🧚
|<----------------- 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 in use. Same as the SS-PW case, P-routers may also show up in the mix 🍓
|<--------------------- 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)Figure 9 shows the MPLS-TP protocol stacks with PWs in them. The Transport Service layer [RFC5654] is picked out by the PW demultiplexer (Demux) label, and the Transport Path layer [RFC5654] is picked out by the LSP Demux Label 🔥
+-------------------+ /===================\ /===================\
| 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 PseudowiresPWs and their associated labels can be configured or signaled, so you've got options 💖 For more on configured service types, check out Section 3.11. For signaled service types, see Section 3.9 🫶
3.4.5. Network Layer Adaptation ✨
okay so MPLS-TP LSPs can totally carry network-layer clients 🫶 "Network Layer" here means the same thing it means in [RFC3031] and [RFC3032]. Any network-layer protocol those two specs support can get moved between service interfaces, and the way it's supported just follows the MPLS architecture from those same docs 💜
So with network-layer adaptation, the MPLS-TP domain gives you a point-to-point connection between two PEs, either one-way or two-way, to deliver a packet transport service to the attached customer edge (CE) nodes 🦋 A CE can be an IP, MPLS, or MPLS-TP node, so it's giving flexibility. Figure 10 shows the setup: an attachment circuit from the CE on the left to its PE (that's the service interface), a bidirectional LSP across the MPLS-TP network to the PE on the right, and then another attachment circuit from that PE to its CE 🌸
|<------------- 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 ClientsThe attachment circuits can be totally different from each other (SDH, PPP, Frame Relay, whatever mix you want 🍓), and the network-layer payloads show up at the service interface wrapped in whatever Layer 1 / Layer 2 encoding that access link type uses. One thing to note: the set of network-layer protocols includes MPLS, so MPLS-encoded packets with an MPLS label stack (the client MPLS stack) can totally show up at the service interface too 🌈
Here are the reference models for network-layer adaptation. The details are explained in the paragraphs right after 😌
|<--------------------- 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 SwitchingClient packets come in at the ingress service interface 💖 The PE pushes one or more labels onto them, and then they get label switched across the transport network. On the way out, the egress PE pops off any labels that the MPLS-TP networks added and sends the packet on to the attached CE through the egress service interface ✨
/===================\
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 ClientsIn those figures, the Transport Service layer [RFC5654] is the one identified by the Service LSP (SvcLSP) demultiplexer (Demux) label 🦋 and the Transport Path layer [RFC5654] is identified by the Transport (Trans) LSP Demux Label 💅 Also, the Encapsulation Label (Encap Label) and the Service Label (SvcLSP Demux) functions can alternatively be represented by a single label stack entry 🧚 The S bit is always zero when the client layer is MPLS-labeled. And sometimes you need to swap a service LSP label at an intermediate node, which is what Figure 11 shows 👑
Inside the MPLS-TP transport network, the network-layer protocols get carried using a logically separate MPLS label stack (the server stack) 🫶 The server stack is entirely controlled by the nodes inside that transport network, and it's not visible outside it. Figure 12 shows how a client network protocol stack (which might be an MPLS label stack plus payload) gets carried over a network-layer client service across an MPLS-TP transport network 🌸
A label can be used to identify the network-layer protocol payload type 💜 So if you're carrying multiple payload types over one service LSP, each one needs its own label stack entry. Those labels are called "Encapsulation Labels" (one is shown in Figure 12), and they can be either configured or signaled 🎀
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 usually carried over an MPLS-TP Transport LSP edge-to-edge (the transport path layer) 🦋 A Transport LSP shows up as an LSP Transport Demux label, as you can see in Figure 12. A Transport LSP is commonly used when there's more than one service between two PEs 💖
Here's a fun bit: if there's only one service between two PEs, the Transport LSP label and the Service LSP label can be squished together into one label stack entry 🍓 So one label can give you both the service indication and the MPLS-TP Transport LSP. Or if there are multiple services between a pair of PEs, then each per-client Service Label gets mapped onto a common MPLS-TP Transport LSP 🌈
Also, as mentioned above, the Layer 2 and Layer 1 protocols that carry the network-layer protocol over the attachment circuits are NOT transported across the MPLS-TP network 😭 That's what lets the two attachment circuits use different Layer 2 and Layer 1 protocols ✨
At each service interface, Layer 2 addressing has to be used so the network-layer packet gets delivered properly to the adjacent node 🙈 This is usually only a thing for LAN media technologies (like Ethernet) that have Media Access Control (MAC) addresses. When a MAC address is needed, the sending node sets the destination MAC address to an address that makes sure delivery goes to the adjacent node. So the CE sets the destination MAC address to one that reaches the PE, and the PE sets its destination MAC address to one that reaches the CE. The specific address is technology-specific and isn't specified in this document, and in some technologies the MAC address will need to be configured 🌸
Quick heads up 🚨: when two CEs that peer with each other run over a network-layer transport service and use a routing protocol like IS-IS or OSPF, you should take some care to configure the routing protocols to use point-to-point adjacencies. The specifics of that configuration are outside the scope of this document, so check [RFC5309] for more details 💀
The CE-to-CE service types and their labels can be configured or signaled 💜
3.5. Identifiers 🪪
okay the big picture here: identifiers are how you uniquely tell entities apart in an MPLS-TP network 🦋 That covers operators, nodes, LSPs, pseudowires, and their associated maintenance entities. MPLS-TP defined two kinds of identifier sets: one set that's compatible with IP, and another that's compatible with ITU-T transport-based operations 👑 The definition of these identifier sets is outside the scope of this document and is provided by [IDENTIFIERS] 🫶
3.6. Generic Associated Channel (G-ACh) 💖
okay so, for OAM to actually work, OAM packets have to fate-share with the data packets 🫶 (basically they go through the same fate as the data). plus, in MPLS-TP you need to be able to tell user data payloads apart from other types of payload 👀. for example, a packet might belong to a Signaling Communication Channel (SCC) or to a channel used by a protocol that coordinates path protection state ✨. this is done by carrying those packets in either:
- 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]).
- 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 uses this generic associated channel (G-ACh) to support Fault, Configuration, Accounting, Performance, and Security (FCAPS) functions 🧚. it carries packets for OAM, a protocol used to coordinate path protection state, SCC, MCC, or other packet types, all 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), kind of like the Pseudowire VCCV control word 🦋. this header is present for all sections, LSPs, and PWs that make use of the 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 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. not me trying to use it as a shortcut 🙈
the G-ACh is for adjunct stuff only. it is not a sneaky way to push forwarding data or define a new PW type 💀
At the server layer, bandwidth and QoS commitments apply to the gross traffic on the LSP, PW, or section. since G-ACh traffic is indistinguishable from user data traffic, protocols using the G-ACh need to consider the impact they have on the user data they share resources with 🌈. the flip side is that capacity needs to be made available for important G-ACh uses such as protection and OAM 🔥. on top of that, the security and congestion considerations described in [RFC5586] apply to protocols using the G-ACh 😭.
Figure 13 shows the reference model for 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].
+-------------+ +-------------+
| 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-AChPW-associated channel messages are encapsulated using the PWE3 encapsulation, so they get handled and processed in the same manner (or in some cases, an analogous manner) as the PW PDUs they provide a control channel for 🎀.
Figure 14 shows the reference model for how the control channel is associated with the LSP protocol stack 🍓.
+-------------+ +-------------+
| 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 Channel3.7. Operations, Administration, and Maintenance (OAM) 🍓
okay this is the big one 👑 the MPLS-TP OAM architecture supports a wide range of OAM functions. they check continuity, verify connectivity, monitor path performance, and generate, filter, and manage local and remote defect alarms 🔔. these functions apply to any layer defined within MPLS-TP, so MPLS-TP sections, LSPs, and PWs all get the love 💜.
the MPLS-TP OAM tool-set can operate without relying on a dynamic control plane or IP functionality in the data path ✨. if an MPLS-TP deployment is in a network where IP functionality is available, all the existing IP/MPLS OAM functions (e.g., LSP Ping, BFD, and VCCV) may be used 🫶. but since MPLS-TP can run 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] defined alert mechanisms that let an MPLS LSR identify and process MPLS OAM packets when those 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 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, so the G-ACh/GAL is the default mechanism to demultiplex OAM packets in MPLS-TP in those environments 💅.
MPLS-TP supports a comprehensive set of OAM capabilities for packet transport applications, with capabilities equivalent 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 they're 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 belong 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 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 🎯. this follows the traceroute mode of LSP Ping [RFC4379] and the vccv-trace mode of [SEGMENTED-PW]. note that this works when the MEP knows where the MIPs are along the LSP or PW path 🗺️. there may be circumstances where that isn't the case, e.g., following restoration using a facility bypass LSP 😬. in those cases, tools to trace the path of the LSP may be used to figure out the right TTL setting to reach a specific MIP 🔍.
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 that 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 ✨
okay so sometimes management, control, and OAM stuff needs response packets to fly back from the receiver to whoever started the message exchange 💌 this section is basically the rundown of return path options in MPLS-TP networks 🦋. it's written about an MPLS-TP LSP, but it also applies to a PW 🫶
in this part, U and D are LSRs that terminate MPLS-TP LSPs (aka LERs) 💅, and Y is an intermediate LSR along the LSP 🧚. U is the upstream LER and D is the downstream LER for a particular direction of an LSP 🌸. here's the reference model in ASCII (Figure 15) 👑:
LSP LSP
U ========= Y ========= D
LER LSR LER
---------> Direction of user traffic flow
Figure 15: Return Path Reference Modelthese are the cases for the different 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
ngl, a return path may not always exist 😭 or it might exist but be disabled 🙈. and packet transmission in one or more of those cases might not be possible. in general, whether return paths exist for MPLS-TP LSPs and what they look like is decided by operational provisioning 🎀.
3.8.1. Return Path Types
there are two types of return path that can be used to deliver traffic from a downstream node D to an upstream node U 💜. either:
- a. the LSP between U and D is bidirectional, so D has a path via the MPLS-TP LSP to send traffic back to U, or
- b. D has some other unspecified means of directing traffic back to U 🌈
the first one is the "in-band" return path, and the second one is the "out-of-band" return path ✨.
out-of-band is giving a lot of options 🦋. for example, it could be based on ordinary IP routing. then packets just get forwarded as usual to an IP address associated with U 🫶. in an MPLS-TP network that's also an IP/MPLS network, that forwarding path might go over the same physical links or logical transport paths MPLS-TP uses 🔥. an out-of-band return path can also be indirect, going through a separate Data Communication Network (DCN) (set up, for example, by the method in [RFC5718]) 🧚, or it can go through 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 😭. but there's one more out-of-band possibility that's worth noting 👑: 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 too 💀. however, if D has a return path to U, then (in a manner analogous to the previous case) D can arrange to 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 🌈. using it is typically preferred for return traffic, though 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 are also applicable 🌸, mainly as an alternative way to deliver things 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 shows how the MPLS-TP control plane, the forwarding plane, the management plane, and OAM relate to each other for point-to-point MPLS-TP LSPs or PWs 🦋:
+------------------------------------------------------------------+
| |
| 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 Contextthe MPLS-TP control plane is based on existing MPLS and PW control plane protocols 💖, and it's consistent with the Automatically Switched Optical Network (ASON) architecture [G.8080] ✨. MPLS-TP uses:
- Generalized MPLS (GMPLS) signaling ([RFC3945], [RFC3471], [RFC3473]) for LSPs, and
- 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 🦋.
PW control (and maintenance) happens separately from LSP tunnel signaling 🧚. the main coordination between LSP and PW control happens 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 gives 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, together, 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 work together, so some functions may be satisfied via the PW control plane while others are provided to PWs by the LSP control plane 🫶.
if MPLS-TP is used in a multi-layer network, a bunch of control protocol types and instances may be involved 🔥. this matches the MPLS architecture, which allows 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 ✨:
- Signaling
- Routing
- 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) 🎀. different policies may be defined to control the information exchanged across these interface types 💖.
the MPLS-TP control plane can activate MPLS-TP OAM functions as described in the OAM section of this document Section 3.7 🧚, for example for fault detection and localization when something fails, so failed transport paths can be restored efficiently 🍓.
the MPLS-TP control plane supports all the MPLS-TP data-plane connectivity patterns needed to establish transport paths 💅, including protected paths as described in Section 3.12 👑.
examples of MPLS-TP data-plane connectivity patterns are LSPs using the fast reroute backup methods defined in [RFC4090] 🌸, and ingress-to-egress 1+1 or 1:1 protected LSPs 💜.
the MPLS-TP control plane provides functions to keep itself surviving 🫶 and to let it recover gracefully from failures and degradations 😭. these include graceful restart and hot redundant configurations 🔥. depending on how the control plane is transported, different degrees of decoupling between the control plane and data plane can be achieved 🌈. in all cases though, the control plane is logically decoupled from the data plane, so a control-plane failure does not imply a failure of the existing transport paths ✨.
3.10. Inter-Domain Connectivity 🦋
a bunch of methods exist to support inter-domain operation of MPLS-TP 🎀, including the data-plane, OAM, and configuration aspects 💖. for example:
- Inter-domain TE LSPs [RFC4726]
- Multi-segment Pseudowires [RFC5659]
- LSP stitching [RFC5150]
- Back-to-back attachment circuits [RFC5659]
an important thing to consider when picking an inter-domain connectivity mechanism is the degree of layer network isolation and the types of OAM the operator needs 🫶
which technique to use in a particular deployment scenario is outside the scope of this document 🧚 that's the vibe 💅✨
3.11. Static Operation of LSPs and PWs ✨
okay so, a PW or LSP can be set up statically, meaning there's no dynamic control plane doing the work 🎀. Either you configure the PEs/LSRs directly, or you do it through a network management system. 💅 Static operation is independent for each specific PW or LSP instance, so it should be possible for a PW to be statically configured while the LSP carrying it is set up by a dynamic control plane. 🦋 When you use static configuration, care must be taken to ensure that loops are not created 🙈. Also, the path of an LSP or PW may be dynamically computed, even though the LSP or PW itself is established through static configuration. The vibe is "mix and match," bestie 💖
3.12. Survivability
The survivability architecture for MPLS-TP is specified in [SURVIVE-FWK]. 🛡️
Okay, there are SO many resiliency schemes out there, all built for different network and service survivability goals 😭. For example, as part of the MPLS/PW paradigms, MPLS gives you ways to do local repair using back-up LSP tunnels ([RFC4090]). Then there's pseudowire redundancy [PW-REDUNDANCY], which covers cases where the underlying LSP can't fully protect the PW. That happens when the backup PW ends on a different target PE node than the working PW in dual-homing setups, or when the S-PE needs protecting. 🧚 GMPLS also has a well-known set of control-plane-driven protection and restoration mechanisms [RFC4872]. And MPLS-TP brings its own extra protection mechanisms, optimized for both linear and ring topologies, that work even without a dynamic control plane ✨. Those are specified in [SURVIVE-FWK] too, so go check it out 👑
Different protection schemes fit different deployment topologies and operational considerations. Some schemes give different levels of resiliency, like these:
- two concurrent traffic paths (1+1).
- one active and one standby path with guaranteed bandwidth on both paths (1:1).
- one active path and a standby path whose resources are shared by one or more other active paths (shared protection).
Whether any given scheme meets your specific requirements is outside the scope of this document 🙃 (not my problem, bestie).
So, the characteristics of MPLS-TP resiliency mechanisms are:
- Optimized for linear, ring, or meshed topologies.
- They use OAM mechanisms to detect and localize network faults or service degenerations. 🔍
- They include protection mechanisms to coordinate and trigger protection switching actions in the absence of a dynamic control plane.
- MPLS-TP recovery schemes apply to all levels in the MPLS-TP domain (section, LSP, and PW), giving you both segment and end-to-end recovery 🌈
- MPLS-TP recovery mechanisms support coordinating protection switching at multiple levels, which prevents race conditions between a client and its server layer. Iconic. 💜
- MPLS-TP recovery mechanisms can be data-plane, control-plane, or management-plane based.
- MPLS-TP supports revertive and non-revertive behavior.
3.13. Sub-Path Maintenance
Okay, so if you want to monitor, protect, and manage just a portion (a segment or a concatenated segment) of an LSP, you can instantiate a hierarchical LSP [RFC3031] 🧶. A hierarchical LSP set up 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. It's a helper, not the main character 🎀
An SPME is defined between the edges of the portion of the LSP that needs monitoring, protection, or management. 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 either 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's at the end of an SPME. In that mode, it's an LER for the SPME. Plot twist 😭
For example, in Figure 17, two SPMEs are set up so you can monitor, protect, and manage the concatenated segments of the LSP. One SPME runs between LER2 and LER3, and a second SPME runs between LER4 and LER5. Each of these SPMEs can 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 NetworkThe 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 using label stacking as defined in [RFC3031]. Label stacks are everything, bestie 🥞
The mapping between an LSP and an SPME can be 1:1, in which case it's similar to the ITU-T Tandem Connection Element [G.805]. The mapping can also be 1:N, which lets you aggregate monitoring, protection, and management across a set of LSP segments or concatenated LSP segments 🍓 Figure 18 shows an SPME used to aggregate a set of concatenated LSP segments for the LSP from LERx to LERt and the LSP from LERa to LERd. Such a construct is useful, for example, when the LSPs traverse a common portion of the network and have the same Traffic Class. Efficient and iconic 👑
The QoS aspects of an SPME are network specific. [OAM-FRAMEWORK] has 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 SegmentsSPMEs can be provisioned either statically or using control-plane signaling procedures 🧚. The make-before-break procedures supported by MPLS allow an SPME to be created on existing LSPs in-service, without traffic disruption, as described in [SURVIVE-FWK]. An 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 from the existing LSPs gets switched over to the new end-to-end tunneled LSPs, and then the old end-to-end LSPs can be torn down. Smooth transition, no drama 🦋
Hierarchical label stacking, done in a similar way to what's described above, can be used to implement Sub-Path Maintenance Elements on pseudowires, as described in [OAM-FRAMEWORK] 💜
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 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 needed for fault, configuration, performance, and security in a transport network 🌸
The Equipment Management Function (EMF) of an MPLS-TP Network Element (NE) (that's an 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 run on a connection (LSP or PW) in a way that's 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 use 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 doesn't restrict which of these standard management protocols gets 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 supervision of transmission (such as continuity, connectivity, and so on), 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 configuring maintenance entity identifiers (such as the Maintenance Entity Group Endpoint (MEP) ID and the MEG Intermediate Point (MIP) ID). The EMF also supports configuring OAM parameters as part of connectivity management to meet specific operational requirements. These may specify whether the operational mode is one-time on-demand or periodic at a specified frequency 🍭
The Performance Management (PM) functions within the EMF of an MPLS-TP NE support evaluating and reporting the behavior of the NEs and the network 📊. One particular PM requirement is to provide a coherent and consistent interpretation of network behavior in a hybrid network that uses multiple transport technologies. Packet loss and delay measurements may be collected and used to detect performance degradation. This gets reported via fault management so corrective actions (e.g., protection switching) can be taken, 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 🔐
okay so MPLS-TP brings MPLS into transport networks, which means the security considerations from both [RFC3031] and [RFC3985] (PWE3) come along for the ride 💅 If your MPLS transport profile includes some MPLS function, the security concerns for that function apply to MPLS-TP too. And if you're running general MPLS networks that use stuff outside the strict MPLS Transport Profile to carry packet transport services, the security considerations for that extra stuff apply as well 🫶
For pseudowires, you've got the security considerations of [RFC3985] and [RFC5659] to think about 🎀
Now here's the tea. MPLS-TP nodes that implement the G-ACh set up a Control Channel (CC) tied to a pseudowire, an LSP, or a section 🦋 That control channel can be signaled or statically configured. Over it, you send control channel messages for network maintenance, like OAM, signaling, or network management 📡 Which is exactly why there are three different areas of concern from a security standpoint 😭
The first area is control plane parameter and status message attacks. These are attacks on the signaling of G-ACh capabilities. For MPLS-TP Control Plane security, go read [RFC5920] 📖
The second area is data-plane attacks, meaning attacks on the G-ACh itself 💀 MPLS-TP nodes that implement G-ACh mechanisms are open to extra data-plane denial-of-service attacks, including:
- An intruder could intercept or inject G-ACh packets, which would disrupt 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 accidentally flood a peer MPLS-TP node with G-ACh messages, and that could result in denial of service. This is especially sneaky when a node has implicitly or explicitly said it can't support one or all of the G-ACh protocol types, but still gets those messages in big enough numbers. That alone can cause a denial of service 🙈
So how do you protect against these attacks, whether they're deliberate or unintentional? There are several mitigation techniques you can use:
- G-ACh message throttling can be used, especially in distributed implementations that have a centralized control-plane processor with various line cards attached through some control-plane data path. In those setups, G-ACh messages may get processed on the central processor after the receiving line card forwards them there. If you don't throttle G-ACh traffic properly, the path between the line card and the control processor can get saturated, and that could mean a complete denial of service for users of that particular line card 😱 Filtering is also handy for stopping unwanted G-ACh messages from being processed, like ones sent on unwanted (and maybe unadvertised) control channel types ✨
The third and last area of concern is the processing of the actual contents of G-ACh messages. The definitions of the protocols that run over a G-ACh need to include appropriate security measures for that 🔥
Additional security considerations apply to each MPLS-TP solution, and these are discussed further in [SEC-FRAMEWORK] 🧚
And finally, the security considerations in [RFC5920] apply here too 🌸
5. IANA Considerations 📋
IANA considerations that come from specific bits of MPLS-TP functionality will be spelled out in the documents that specify that functionality 🎀
This document doesn't introduce any additional IANA considerations on its own 💖
6. Acknowledgements 🫶
The editors want to thank these amazing people for their contributions to this document 🥹
- Rahul Aggarwal
- Dieter Beller
- Malcolm Betts
- Italo Busi
- John E Drake
- Hing-Kam Lam
- Marc Lasserre
- Vincenzo Sestito
- Nurit Sprecher
- Martin Vigoureux
- Yaacov Weingarten
- 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.[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 ✨
Okay bestie, here's the bonus reading list 📚🎀 These are the extra references the document points to, and every single one keeps its original details below.
[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.
[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.
[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.
[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.
[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.Authors' Addresses 💌
And finally, the squad behind this doc! 🫶 Here are the authors' addresses, exactly as they were, so you know exactly who to slide into the inbox 💅
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.netThat's the whole doc, bestie! 🌈✨ Every reference and every address is right there, and that's a wrap 🦋👑
📦 where this page comes from
- ietf: rfc5921 2010-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms