RFC 6373
MPLS Transport Profile (MPLS-TP) Control Plane Framework
RFC 6373: MPLS Transport Profile (MPLS-TP) Control Plane Framework 🎀
okay bestie, this is RFC 6373, and it's giving the control plane framework for MPLS-TP 💅 It came out in September 2011 from the IETF (Internet Engineering Task Force) 🌈 The category is Informational, so it's not a Standards Track spec ✨ The ISSN is 2070-1721. The editors are L. Andersson (Ericsson), L. Berger (LabN), L. Fang (Cisco), N. Bitar (Verizon), and E. Gray (Ericsson), all marked as Ed. 🫶 It doesn't list anything it obsoletes or updates 🍓
Abstract 🦋
okay so MPLS-TP can set up its transport paths in two ways. One is static provisioning through a Network Management System (NMS) 🧚 The other is dynamic provisioning through a control plane 💖 This doc is the framework for the dynamic way. It covers control-plane addressing, routing, path computation, signaling, traffic engineering, and path recovery ✨ MPLS-TP uses GMPLS as its control plane for MPLS-TP Label Switched Paths (LSPs) 🔥 and it uses the pseudowire (PW) control plane for pseudowires 🌸 Management-plane functions are out of scope here, so don't come looking for them 🙈
This doc is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort 👑 The goal is to put an MPLS Transport Profile inside the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures. That way it can support the capabilities and functionalities of a packet transport network as defined by the ITU-T 💜
Status of This Memo 📜
This doc is not an Internet Standards Track spec. It's published for informational purposes 🍓
This doc is a product of the Internet Engineering Task Force (IETF). 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 all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741 💀
Info about the current status of this document, any errata, and how to give feedback can be found at http://www.rfc-editor.org/info/rfc6373 ✨
Copyright Notice ©️
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, since they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🎀
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. Scope ......................................................4
1.2. Basic Approach .............................................4
1.3. Reference Model ............................................6
2. Control-Plane Requirements ......................................9
2.1. Primary Requirements .......................................9
2.2. Requirements Derived from the MPLS-TP Framework ...........18
2.3. Requirements Derived from the OAM Framework ...............20
2.4. Security Requirements .....................................25
2.5. Identifier Requirements ...................................25
3. Relationship of PWs and TE LSPs ................................26
4. TE LSPs ........................................................27
4.1. GMPLS Functions and MPLS-TP LSPs ..........................27
4.1.1. In-Band and Out-of-Band Control ....................27
4.1.2. Addressing .........................................29
4.1.3. Routing ............................................29
4.1.4. TE LSPs and Constraint-Based Path Computation ......29
4.1.5. Signaling ..........................................30
4.1.6. Unnumbered Links ...................................30
4.1.7. Link Bundling ......................................30
4.1.8. Hierarchical LSPs ..................................31
4.1.9. LSP Recovery .......................................31
4.1.10. Control-Plane Reference Points (E-NNI,
I-NNI, UNI) .......................................32
4.2. OAM, MEP (Hierarchy), MIP Configuration and Control .......32
4.2.1. Management-Plane Support ...........................33
4.3. GMPLS and MPLS-TP Requirements Table ......................34
4.4. Anticipated MPLS-TP-Related Extensions and Definitions ....37
4.4.1. MPLS-TE to MPLS-TP LSP Control-Plane Interworking ..37
4.4.2. Associated Bidirectional LSPs ......................38
4.4.3. Asymmetric Bandwidth LSPs ..........................38
4.4.4. Recovery for P2MP LSPs .............................38
4.4.5. Test Traffic Control and Other OAM Functions .......38
4.4.6. Diffserv Object Usage in GMPLS .....................39
4.4.7. Support for MPLS-TP LSP Identifiers ................39
4.4.8. Support for MPLS-TP Maintenance Identifiers ........39
5. Pseudowires ....................................................39
5.1. LDP Functions and Pseudowires .............................39
5.1.1. Management-Plane Support ...........................40
5.2. PW Control (LDP) and MPLS-TP Requirements Table ...........40
5.3. Anticipated MPLS-TP-Related Extensions ....................44
5.3.1. Extensions to Support Out-of-Band PW Control .......44
5.3.2. Support for Explicit Control of PW-to-LSP Binding ..45
5.3.3. Support for Dynamic Transfer of PW
Control/Ownership ..................................45
5.3.4. Interoperable Support for PW/LSP Resource
Allocation .........................................46
5.3.5. Support for PW Protection and PW OAM
Configuration ......................................46
5.3.6. Client Layer and Cross-Provider Interfaces
to PW Control ......................................47
5.4. ASON Architecture Considerations ..........................47
6. Security Considerations ........................................47
7. Acknowledgments ................................................48
8. References .....................................................48
8.1. Normative References ......................................48
8.2. Informative References ....................................51
9. Contributing Authors ...........................................561. Introduction ✨
The Multiprotocol Label Switching Transport Profile (MPLS-TP) is a joint effort between the International Telecommunication Union (ITU) and the IETF 🌈 The requirements for MPLS-TP live in the requirements doc, see [RFC5654] 💅 Those requirements say "A solution MUST be defined to support dynamic provisioning of MPLS-TP transport paths via a control plane" 🔥 That's the whole reason this doc exists, so it's giving purpose 💖 This doc provides the framework for that dynamic provisioning. It's also a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures, so it can support the capabilities and functions of a packet transport network as defined by the ITU-T ✨
1.1. Scope 🎀
okay so this doc covers the control-plane functions involved in setting up MPLS-TP Label Switched Paths (LSPs) and pseudowires (PWs) 🦋 The control-plane requirements for MPLS-TP are defined in the MPLS-TP requirements doc [RFC5654], which spells out the role of the control plane in MPLS-TP. Specifically, Section 2.4 of [RFC5654] and parts of the rest of Section 2 of [RFC5654] lay out the specific control-plane requirements 🧚
The LSPs from MPLS-TP act as a server layer for IP, MPLS, and PWs, plus other tunneled MPLS-TP LSPs 💜 PWs are used to carry client signals other than IP or MPLS 🍓 The relationship between PWs and MPLS-TP LSPs is exactly the same as between PWs and MPLS LSPs in an MPLS Packet Switched Network (PSN). The PW encapsulation over MPLS-TP LSPs in MPLS-TP networks is also the same as for PWs over MPLS in an MPLS network 🫶 MPLS-TP also defines protection and restoration (or, collectively, recovery) functions, see [RFC5654] and [RFC4427] 🛡️ The MPLS-TP control plane provides methods to establish, remove, and control MPLS-TP LSPs and PWs. That includes control of Operations, Administration, and Maintenance (OAM), data-plane, and recovery functions 👑
A general framework for MPLS-TP has been defined in [RFC5921], and a survivability framework for MPLS-TP has been defined in [RFC6372] 🌸 These docs scope the approaches and protocols that are the foundation of MPLS-TP. Notably, Section 3.5 of [RFC5921] scopes the IETF protocols that serve as the foundation of the MPLS-TP control plane ✨ The PW control plane is based on the existing PW control plane (see [RFC4447]) and the PWE3 architecture (see [RFC3985]). The LSP control plane is based on GMPLS (see [RFC3945]), which is built on MPLS Traffic Engineering (TE) and its numerous extensions 🔥 [RFC6372] focuses on the recovery functions that must be supported within MPLS-TP. It does not specify which control-plane mechanisms are to be used 🙈
The rest of this document looks at how the MPLS-TP requirements affect the GMPLS signaling and routing protocols used to control MPLS-TP LSPs, and how they affect the control of PWs as specified in [RFC4447], [RFC6073], and [MS-PW-DYNAMIC] 💖
1.2. Basic Approach 🧠
okay so here's the game plan for the MPLS-TP control-plane framework 💅 the basic approach has a bunch of pieces, and they all fit together like a perfect outfit:
- MPLS technology as defined by the IETF is the foundation for the MPLS Transport Profile. 🎀
- The data plane for MPLS-TP is a standard MPLS data plane [RFC3031] as profiled in [RFC5960]. 💜
- MPLS PWs are used by MPLS-TP, including the use of targeted Label Distribution Protocol (LDP) as the foundation for PW signaling [RFC4447]. This also includes the use of Open Shortest Path First with Traffic Engineering (OSPF-TE), Intermediate System to Intermediate System (IS-IS) with Traffic Engineering (ISIS-TE), or Multiprotocol Border Gateway Protocol (MP-BGP) as they apply for Multi-Segment Pseudowire (MS-PW) routing. However, the PW can be encapsulated over an MPLS-TP LSP (established using methods and procedures for MPLS-TP LSP establishment) in addition to the presently defined methods of carrying PWs over LSP-based PSNs. That is, the MPLS-TP domain is a PSN from a PWE3 architecture perspective [RFC3985]. 🦋
- The MPLS-TP LSP control plane builds on the GMPLS control plane as defined by the IETF for transport LSPs. The protocols within scope are Resource Reservation Protocol with Traffic Engineering (RSVP-TE) [RFC3473], OSPF-TE [RFC4203] [RFC5392], and ISIS-TE [RFC5307] [RFC5316]. Automatically Switched Optical Network (ASON) signaling and routing requirements in the context of GMPLS can be found in [RFC4139] and [RFC4258]. 🌸
- Existing IETF MPLS and GMPLS RFCs and evolving Working Group Internet-Drafts should be reused wherever possible. ♻️
- If needed, extensions for the MPLS-TP control plane should first be based on the existing and evolving IETF work, and secondly be based on work by other standard bodies only when IETF decides that the work is out of the IETF's scope. New extensions may be defined otherwise. 🌈
- Extensions to the control plane may be required in order to fully automate functions related to MPLS-TP LSPs and PWs. ⭐
- Control-plane software upgrades to existing equipment are acceptable and expected. 🔥
- It is permissible for functions present in the GMPLS and PW control planes to not be used in MPLS-TP networks. 🙈
- One possible use of the control plane is to configure, enable, and generally control OAM functionality. This will require extensions to existing control-plane specifications that will be usable in MPLS-TP as well as MPLS networks. 🧚
- The foundation for MPLS-TP control-plane requirements is primarily found in Section 2.4 of [RFC5654] and relevant portions of the remainder of Section 2 of [RFC5654]. 👑
1.3. Reference Model 🗺️
the control-plane reference model is based on the general MPLS-TP reference model as defined in the MPLS-TP framework [RFC5921] and further refined in [RFC6215] on the MPLS-TP User-to-Network and Network-to-Network Interfaces (UNI and NNI, respectively). per the MPLS-TP framework [RFC5921], the MPLS-TP control plane is based on GMPLS with RSVP-TE for LSP signaling and targeted LDP for PW signaling. in both cases, OSPF-TE or ISIS-TE with GMPLS extensions is used for dynamic routing within an MPLS-TP domain. 💖
note that in this context, "targeted LDP" (or T-LDP) means LDP as defined in RFC 5036, using Targeted Hello messages. see Section 2.4.2 ("Extended Discovery Mechanism") of [RFC5036]. use of the extended discovery mechanism is specified in Section 5 ("LDP") of [RFC4447]. 🔍
from a service perspective, MPLS-TP client services may be supported via both PWs and LSPs. PW client interfaces, or adaptations, are defined on an interface-technology basis, e.g., Ethernet over PW [RFC4448]. in the context of MPLS-TP LSP, the client interface is provided at the network layer and may be controlled via a GMPLS-based UNI, see [RFC4208], or statically provisioned. as discussed in [RFC5921] and [RFC6215], MPLS-TP also presumes an NNI reference point. 🫶
the MPLS-TP end-to-end control-plane reference model is shown in Figure 1. the figure shows the control-plane protocols used by MPLS-TP, as well as the UNI and NNI reference points, in the case of a Single-Segment PW supported by an end-to-end LSP without any hierarchical LSPs. (The MS-PW case is not shown.) each service provider node's participation in routing and signaling (both GMPLS RSVP-TE and PW LDP) is represented. note that only the service end points participate in PW LDP signaling, while all service provider nodes participate in GMPLS TE LSP routing and signaling. 💅
|< ---- client signal (e.g., IP / MPLS / L2) -------- >|
|< --------- SP1 ---------- >|< ------- SP2 ----- >|
|< ---------- MPLS-TP End-to-End PW --------- >|
|< -------- MPLS-TP End-to-End LSP ------ >|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
UNI NNI UNI
GMPLS
TE-RTG, |<-----|------|------|-------|------|----->|
& RSVP-TE
PW LDP |< ---------------------------------------- >|
Figure 1. End-to-End MPLS-TP Control-Plane Reference Model
Legend:
CE: Customer Edge
Client signal: defined in MPLS-TP Requirements
L2: Any layer 2 signal that may be carried
over a PW, e.g., Ethernet
NNI: Network-to-Network Interface
P: Provider
PE: Provider Edge
SP: Service Provider
TE-RTG: GMPLS OSPF-TE or ISIS-TE
UNI: User-to-Network Interface
Note: The MS-PW case is not shown.Figure 2 adds three hierarchical LSP segments, labeled as "H-LSPs". these segments are present to support scaling, OAM, and Maintenance Entity Group End Points (MEPs), see [RFC6371], within each provider domain and across the inter-provider NNI. (H-LSPs are used to implement Sub-Path Maintenance Elements (SPMEs) as defined in [RFC5921].) The MEPs are used to collect performance information, support diagnostic and fault management functions, and support OAM triggered survivability schemes as discussed in [RFC6372]. Each H-LSP may be protected or restored using any of the schemes discussed in [RFC6372]. End-to-end monitoring is supported via MEPs at the end-to-end LSP and PW end points. Note that segment MEPs may be co-located with MIPs of the next higher-layer (e.g., end-to-end) LSPs. (The MS-PW case is not shown.) 🦋✨
|< ------- client signal (e.g., IP / MPLS / L2) ----- >|
|< -------- SP1 ----------- >|< ------- SP2 ----- >|
|< ----------- MPLS-TP End-to-End PW -------- >|
|< ------- MPLS-TP End-to-End LSP ------- >|
|< -- H-LSP1 ---- >|<-H-LSP2->|<- H-LSP3 ->|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
UNI NNI UNI
..... .....
End2end |MEP|--------------------------------------|MEP|
PW OAM ''''' '''''
..... ..... ..... .....
End2end |MEP|----------------|MIP|---|MIP|---------|MEP|
LSP OAM ''''' ''''' ''''' '''''
..... ..... ..... ......... ......... ..... .....
Segment |MEP|-|MIP|-|MIP|-|MEP|MEP|-|MEP|MEP|-|MIP|-|MEP|
LSP OAM ''''' ''''' ''''' ''''''''' ''''''''' ''''' '''''
H-LSP GMPLS
TE-RTG |<-----|------|----->||<---->||<-----|----->|
&RSVP-TE (within an MPLS-TP network)
E2E GMPLS
TE-RTG |< ------------------|--------|------------>|
&RSVP-TE
PW LDP |< ---------------------------------------- >|
Figure 2. MPLS-TP Control-Plane Reference Model with OAM
Legend:
CE: Customer Edge
Client signal: defined in MPLS-TP Requirements
E2E: End-to-End
L2: Any layer 2 signal that may be carried
over a PW, e.g., Ethernet
H-LSP: Hierarchical LSP
MEP: Maintenance Entity Group End Point
MIP: Maintenance Entity Group Intermediate Point
NNI: Network-to-Network Interface
P: Provider
PE: Provider Edge
SP: Service Provider
TE-RTG: GMPLS OSPF-TE or ISIS-TE
Note: The MS-PW case is not shown.while not shown in the figures above, the MPLS-TP control plane must support the addressing separation and independence between the data, control, and management planes. Address separation between the planes is already included in GMPLS. Such separation is also already included in LDP as LDP session end point addresses are never automatically associated with forwarding. 🌟
2. Control-Plane Requirements 🎀
the requirements for the MPLS-TP control plane are derived from the MPLS-TP requirements and framework documents, specifically [RFC5654], [RFC5921], [RFC5860], [RFC6371], and [RFC6372]. The requirements are summarized in this section, but do not replace those documents. If there are differences between this section and those documents, those documents shall be considered authoritative. 📚
2.1. Primary Requirements 💜
these requirements are based on Section 2 of [RFC5654]:
- Any new functionality that is defined to fulfill the requirements for MPLS-TP must be agreed within the IETF through the IETF consensus process as per [RFC4929] and Section 1, paragraph 15 of [RFC5654]. 🫶
- The MPLS-TP control-plane design should as far as reasonably possible reuse existing MPLS standards ([RFC5654], requirement 2). ♻️
- The MPLS-TP control plane must be able to interoperate with existing IETF MPLS and PWE3 control planes where appropriate ([RFC5654], requirement 3). 🤝
- The MPLS-TP control plane must be sufficiently well-defined to ensure that the interworking between equipment supplied by multiple vendors will be possible both within a single domain and between domains ([RFC5654], requirement 4). 🏳️🌈
- The MPLS-TP control plane must support a connection-oriented packet switching model with traffic engineering capabilities that allow deterministic control of the use of network resources ([RFC5654], requirement 5). 🌷
- The MPLS-TP control plane must support traffic-engineered point-to-point (P2P) and point-to-multipoint (P2MP) transport paths ([RFC5654], requirement 6). 🛤️
- The MPLS-TP control plane must support unidirectional, associated bidirectional and co-routed bidirectional point-to-point transport paths ([RFC5654], requirement 7). ↔️
- The MPLS-TP control plane must support unidirectional point-to-multipoint transport paths ([RFC5654], requirement 8). 📡
- okay bestie, the MPLS-TP control plane must make sure every node (ingress, egress, and intermediate) knows which forward and backward directions pair up to form the same co-routed bidirectional transport path 🦋 ([RFC5654], requirement 10).
- the MPLS-TP control plane must help edge nodes (ingress and egress) know which forward and backward directions pair up in the same associated bidirectional transport path 💅 ([RFC5654], requirement 11).
- the MPLS-TP control plane should let common transit nodes know the same forward/backward pairing for an associated bidirectional transport path 🌸 ([RFC5654], requirement 12).
- the MPLS-TP control plane must support bidirectional transport paths with symmetric bandwidth, meaning the reserved bandwidth is the same in both the forward and backward directions 🎀 ([RFC5654], requirement 13).
- the MPLS-TP control plane must support bidirectional transport paths with asymmetric bandwidth, meaning the reserved bandwidth is different in the forward and backward directions ✨ ([RFC5654], requirement 14).
- the MPLS-TP control plane must keep itself logically separate from the management and data planes ([RFC5654], requirement 15). ngl this one is so important 🧚 It means the addresses used in the control plane are independent from the addresses used in the management and data planes.
- the MPLS-TP control plane must be physically separable from the management and data planes, and no assumptions should be made about the state of the data-plane channels based on information from the control-plane or management-plane channels when those run out-of-band 🌈 ([RFC5654], requirement 16).
- a control plane must be defined to support dynamic provisioning and restoration of MPLS-TP transport paths, but whether you actually use it is the network operator's call 👑 ([RFC5654], requirement 18).
- the presence of a control plane must not be required for static provisioning of MPLS-TP transport paths 🍓 ([RFC5654], requirement 19).
- the MPLS-TP control plane must allow statically and dynamically provisioned/managed MPLS-TP transport paths to coexist within the same layer network or domain 💜 ([RFC5654], requirement 20).
- the MPLS-TP control plane should work in a way that feels similar to how the control plane works in other transport-layer technologies 🫶 ([RFC5654], requirement 21).
- the MPLS-TP control plane must avoid or minimize traffic impact (like packet delay, reordering, and loss) during network reconfiguration 😭 ([RFC5654], requirement 24).
- the MPLS-TP control plane must work across multiple homogeneous domains ([RFC5654], requirement 25), meaning all the domains use the same MPLS-TP control plane 🔥.
- the MPLS-TP control plane should work across multiple non-homogeneous domains ([RFC5654], requirement 26), meaning some domains use the same control plane while other domains use static provisioning at the domain boundary 🦋.
- the MPLS-TP control plane must not dictate any particular physical or logical topology ([RFC5654], requirement 27) 💖.
- the MPLS-TP control plane must include support for ring topologies that can be deployed with arbitrary interconnection, and support rings of at least 16 nodes ([RFC5654], requirements 27.A, 27.B, and 27.C) 💍.
- the MPLS-TP control plane must scale gracefully to support a large number of transport paths, nodes, and links 📈. That means it must scale at least as well as control planes in existing transport technologies, even as topologies grow more complex and as bandwidth demands, number of customers, and number of services increase ([RFC5654], requirements 53 and 28) 🌸.
- the MPLS-TP control plane should not provision transport paths that contain forwarding loops ([RFC5654], requirement 29) 🙈.
- the MPLS-TP control plane must support multiple client layers (e.g., MPLS-TP, IP, MPLS, Ethernet, ATM, Frame Relay, etc.) ([RFC5654], requirement 30) 🌈.
- the MPLS-TP control plane must provide a generic and extensible solution for carrying MPLS-TP transport paths over one or more server-layer networks (such as MPLS-TP, Ethernet, Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH), Optical Transport Network (OTN), etc.) ✨. Requirements for bandwidth management within a server-layer network are outside the scope of this document ([RFC5654], requirement 31).
- in an environment where an MPLS-TP layer network is supporting a client-layer network, and that MPLS-TP layer network is itself supported by a server-layer network, the control-plane operation of the MPLS-TP layer network must be possible without any dependencies on the server or client-layer network ([RFC5654], requirement 32) 🧚.
- the MPLS-TP control plane must allow a client MPLS or MPLS-TP layer network to be transported over a server MPLS or MPLS-TP layer network ([RFC5654], requirement 33) 🎀.
- the MPLS-TP control plane must allow the autonomous operation of the layers in a multi-layer network that includes an MPLS-TP layer ([RFC5654], requirement 34) 👑.
- the MPLS-TP control plane must allow the MPLS-TP layer network's addressing and other information (e.g., topology) to be hidden from client-layer networks 🙈. However, it should be possible, at the option of the operator, to leak a limited amount of summarized information, such as Shared Risk Link Groups (SRLGs) or reachability, between layers ([RFC5654], requirement 35).
- the MPLS-TP control plane must allow a transport path to be identified on each link within the transport network and at its destination (egress) ([RFC5654], requirements 38 and 39) 🔍.
- the MPLS-TP control plane must allow the use of P2MP server (sub-)layer capabilities as well as P2P server (sub-)layer capabilities when supporting P2MP MPLS-TP transport paths ([RFC5654], requirement 40) 🦋.
- the MPLS-TP control plane must be extensible so it can accommodate new types of client-layer networks and services ([RFC5654], requirement 41) 🌟.
- the MPLS-TP control plane should support increasing the reserved bandwidth of a transport path without impacting the existing traffic on that path, provided enough resources are available ([RFC5654], requirement 42)).
- the MPLS-TP control plane should support decreasing the reserved bandwidth of a transport path without impacting the existing traffic on that path, provided the existing traffic is smaller than the reserved bandwidth after the decrease ([RFC5654], requirement 43) 💅.
- the control plane for MPLS-TP must fit within the ASON (control-plane) architecture 🌸. The ITU-T defined an architecture for ASONs in G.8080 [ITU.G8080.2006] and G.8080 Amendment 1 [ITU.G8080.2008]. An interpretation of the ASON signaling and routing requirements in the context of GMPLS can be found in [RFC4139], [RFC4258], and Section 2.4, paragraphs 2 and 3 of [RFC5654].
- the MPLS-TP control plane must support control-plane topology and data-plane topology independence ([RFC5654], requirement 47) 🦋.
- a failure of the MPLS-TP control plane must not interfere with the delivery of service or the recovery of established transport paths ([RFC5654], requirement 47) 😭.
- the MPLS-TP control plane must be able to operate independently of any particular client- or server-layer control plane ([RFC5654], requirement 48) 🌈.
- the MPLS-TP control plane should support, but not require, an integrated control plane covering MPLS-TP together with its server- and client-layer networks when those layer networks belong to the same administrative domain ([RFC5654], requirement 49) 🫶.
- the MPLS-TP control plane must support configuration of protection functions and any associated maintenance (OAM) functions ([RFC5654], requirements 50 and 7) 👑.
- the MPLS-TP control plane must support configuring and modifying OAM maintenance points, as well as activating and deactivating OAM, when a transport path or transport service is established or modified ([RFC5654], requirement 51) 💖.
- the MPLS-TP control plane must be capable of restarting and relearning its previous state without impacting forwarding ([RFC5654], requirement 54) 🍓.
- the MPLS-TP control plane must provide a mechanism for dynamic ownership transfer of control of MPLS-TP transport paths from the management plane to the control plane, and vice versa 🧚. The number of reconfigurations required in the data plane must be minimized; preferably, no data-plane reconfiguration will be required ([RFC5654], requirement 55). Note, such transfers cover all transport path control functions, including control of recovery and OAM.
- the MPLS-TP control plane must support protection and restoration mechanisms, i.e., recovery ([RFC5654], requirement 52) 🔥.
Note that the MPLS-TP survivability framework document [RFC6372] provides additional useful information related to recovery 🌸.
- the MPLS-TP control-plane mechanisms should be identical (or as similar as possible) to those already used in existing transport networks to simplify implementation and operations 💅. However, this must not override any other requirement ([RFC5654], requirement 56 A).
- the MPLS-TP control-plane mechanisms used for P2P and P2MP recovery should be identical to simplify implementation and operation 🎀. However, this must not override any other requirement ([RFC5654], requirement 56 B).
- the MPLS-TP control plane must support recovery mechanisms that apply at various levels throughout the network, including link, transport path, segment, concatenated segment, and end-to-end recovery ([RFC5654], requirement 57) 🌈.
- the MPLS-TP control plane must support recovery paths that meet the Service Level Agreement (SLA) protection objectives of the service ([RFC5654], requirement 58) ✨. These include:
a. Guarantee 50-ms recovery times from the moment of fault detection in networks with spans less than 1200 km.
b. Protection of 100% of the traffic on the protected path.
c. Recovery must meet SLA requirements over multiple domains.
- the MPLS-TP control plane should support per-transport-path recovery objectives ([RFC5654], requirement 59) 👑✨.
- okay so the MPLS-TP control plane must support recovery mechanisms that work for any topology 🗺️ ([RFC5654], requirement 60).
- the MPLS-TP control plane must operate in synergy with the recovery mechanisms in any client or server transport network (for example, Ethernet, SDH, OTN, Wavelength Division Multiplexing (WDM)) 🤝. That includes coordinating timing and timer settings, so the layers don't race each other and cause chaos 💀 ([RFC5654], requirement 61).
- the MPLS-TP control plane must support recovery and reversion mechanisms that stop recovery from firing over and over when a defect is intermittent 🙅♀️ ([RFC5654], requirement 62).
- the MPLS-TP control plane must support both revertive and non-revertive protection behavior 🔁 ([RFC5654], requirement 64).
- the MPLS-TP control plane must support 1+1 bidirectional protection for P2P transport paths 💖 ([RFC5654], requirement 65 A).
- the MPLS-TP control plane must support 1+1 unidirectional protection for P2P transport paths 💜 ([RFC5654], requirement 65 B).
- the MPLS-TP control plane must support 1+1 unidirectional protection for P2MP transport paths 🌸 ([RFC5654], requirement 65 C).
- the MPLS-TP control plane must support sharing protection resources across a number of transport paths 🫶 ([RFC5654], requirement 66).
- the MPLS-TP control plane must support 1:n bidirectional protection for P2P transport paths. Bidirectional 1:n protection should be the default for 1:n protection, no debate ✨ ([RFC5654], requirement 67 A).
- the MPLS-TP control plane must support 1:n unidirectional protection for P2MP transport paths 🦋 ([RFC5654], requirement 67 B).
- the MPLS-TP control plane may support 1:n unidirectional protection for P2P transport paths 🌈 ([RFC5654], requirement 65 C).
- the MPLS-TP control plane may support the control of extra-traffic type traffic 🧚 ([RFC5654], note after requirement 67).
- the MPLS-TP control plane should support 1:n (including 1:1) shared mesh recovery 🕸️ ([RFC5654], requirement 68).
- the MPLS-TP control plane must support sharing protection resources so that protection paths known not to be needed at the same time can share the same resources 🍓 ([RFC5654], requirement 69).
- the MPLS-TP control plane must support sharing resources between a restoration transport path and the transport path it is replacing 🤍 ([RFC5654], requirement 70).
- the MPLS-TP control plane must support restoration priority, so an implementation can decide the order in which transport paths get restored 📋 ([RFC5654], requirement 71).
- the MPLS-TP control plane must support preemption priority, so restoration can push other transport paths aside when resources run short 👑 ([RFC5654], requirements 72 and 86).
- the MPLS-TP control plane must support both revertive and non-revertive restoration behavior 🔄 ([RFC5654], requirement 73).
- the MPLS-TP control plane must support recovery being triggered by physical (lower) layer fault indications ⚡ ([RFC5654], requirement 74).
- the MPLS-TP control plane must support recovery being triggered by OAM 🔍 ([RFC5654], requirement 75).
- the MPLS-TP control plane must support management-plane recovery triggers (e.g., forced switch, etc.) 🎛️ ([RFC5654], requirement 76).
- the MPLS-TP control plane must support telling administrative recovery actions apart from recovery actions started by other triggers 🏷️ ([RFC5654], requirement 77).
- the MPLS-TP control plane should support control-plane restoration triggers (e.g., forced switch, etc.) 🎀 ([RFC5654], requirement 78).
- the MPLS-TP control plane must support priority logic to negotiate and handle requests that coexist (i.e., multiple requests) for protection switching (e.g., administrative requests and requests due to link/node failures) 🥇 ([RFC5654], requirement 79).
- the MPLS-TP control plane must support associating protection paths with working paths (sometimes known as protection groups) 💞 ([RFC5654], requirement 80).
- the MPLS-TP control plane must support pre-calculation of recovery paths 🧮 ([RFC5654], requirement 81).
- the MPLS-TP control plane must support pre-provisioning of recovery paths 📦 ([RFC5654], requirement 82).
- the MPLS-TP control plane must support the external commands defined in [RFC4427]. External controls that are overruled by higher priority requests (e.g., administrative requests and requests due to link/node failures), or that cannot be signaled to the remote end (e.g., because of a protection state coordination fail), must be ignored/dropped 🙈 ([RFC5654], requirement 83).
- the MPLS-TP control plane must permit testing and validation of the integrity of the protection/recovery transport path 🔬 ([RFC5654], requirement 84 A).
- the MPLS-TP control plane must permit testing and validation of protection/restoration mechanisms without actually triggering the protection/restoration 🧪 ([RFC5654], requirement 84 B).
- the MPLS-TP control plane must permit testing and validation of protection/restoration mechanisms while the working path is in service 🟢 ([RFC5654], requirement 84 C).
- the MPLS-TP control plane must permit testing and validation of protection/restoration mechanisms while the working path is out of service 🔴 ([RFC5654], requirement 84 D).
- the MPLS-TP control plane must support establishing and maintaining all recovery entities and functions 🏗️ ([RFC5654], requirement 89 A).
- the MPLS-TP control plane must support signaling of recovery administrative control 📣 ([RFC5654], requirement 89 B).
- the MPLS-TP control plane must support protection state coordination. Since control-plane network topology is independent of the data-plane network topology, the protection state coordination supported by the MPLS-TP control plane may run on resources different from the data-plane resources handled within the recovery mechanism (e.g., backup) 🧠 ([RFC5654], requirement 89 C).
- when present, the MPLS-TP control plane must support recovery mechanisms that are optimized for specific network topologies. These mechanisms must be interoperable with the mechanisms defined for arbitrary topology (mesh) networks, so end-to-end transport paths can be protected 🤝 ([RFC5654], requirement 91).
- when present, the MPLS-TP control plane must support control of ring-topology-specific recovery mechanisms 💍 ([RFC5654], Section 2.5.6.1).
- the MPLS-TP control plane must include support for differentiated services and different traffic types, with traffic class separation associated with different traffic 🛍️ ([RFC5654], requirement 110).
- the MPLS-TP control plane must support provisioning of services that provide guaranteed Service Level Specifications (SLSs), with support for hard ([RFC3209] style) and relative ([RFC3270] style) end-to-end bandwidth guarantees 💪 ([RFC5654], requirement 111).
- the MPLS-TP control plane must support provisioning of services that are sensitive to jitter and delay 🎵 ([RFC5654], requirement 112).
2.2. Requirements Derived from the MPLS-TP Framework ✨
The following additional requirements are based on [RFC5921], [TP-P2MP-FWK], and [RFC5960]:
- Per-packet Equal Cost Multi-Path (ECMP) load balancing is currently outside the scope of MPLS-TP 🚫 ([RFC5960], Section 3.1.1, paragraph 6).
- Penultimate Hop Popping (PHP) must be disabled on MPLS-TP LSPs by default 🙅 ([RFC5960], Section 3.1.1, paragraph 7).
- the MPLS-TP control plane must support both E-LSP (Explicitly TC-encoded-PSC LSP) and L-LSP (Label-Only-Inferred-PSC LSP) MPLS Diffserv modes, as specified in [RFC3270], [RFC5462], and Section 3.3.2, paragraph 12 of [RFC5960] 🌟.
- both Single-Segment PWs (see [RFC3985]) and Multi-Segment PWs (see [RFC5659]) shall be supported by the MPLS-TP control plane. MPLS-TP shall use the definition of Multi-Segment PWs as defined by the IETF ([RFC5921], Section 3.4.4) 🧵.
- the MPLS-TP control plane must support the control of PWs and their associated labels ([RFC5921], Section 3.4.4) 🏷️.
- the MPLS-TP control plane must support network-layer clients, i.e., clients whose traffic is transported over an MPLS-TP network without the use of PWs ([RFC5921], Section 3.4.5) 🌐. a. the MPLS-TP control plane must support the use of network-layer protocol-specific LSPs and labels ([RFC5921], Section 3.4.5). b. the MPLS-TP control plane must support the use of client-service-specific LSPs and labels ([RFC5921], Section 3.4.5).
- the MPLS-TP control plane for LSPs must be based on the GMPLS control plane. More specifically, GMPLS RSVP-TE [RFC3473] and related extensions are used for LSP signaling, and GMPLS OSPF-TE [RFC5392] and ISIS-TE [RFC5316] are used for routing ([RFC5921], Section 3.9) 🛤️.
- the MPLS-TP control plane for PWs must be based on the MPLS control plane for PWs. More specifically, targeted LDP (T-LDP) [RFC4447] is used for PW signaling ([RFC5921], Section 3.9, paragraph 5) 📡.
- the MPLS-TP control plane must ensure its own survivability and be able to recover gracefully from failures and degradations. These include graceful restart and hot redundant configurations ([RFC5921], Section 3.9, paragraph 16) 🛟.
- the MPLS-TP control plane must support linear, ring, and meshed protection schemes ([RFC5921], Section 3.12, paragraph 3) 🕸️.
- the MPLS-TP control plane must support control of SPMEs (hierarchical LSPs) for new or existing end-to-end LSPs ([RFC5921], Section 3.12, paragraph 7) 🪆.
2.3. Requirements Derived from the OAM Framework 🔍
The following additional requirements are based on [RFC5860] and [RFC6371]:
- the MPLS-TP control plane must support the capability to enable/disable OAM functions as part of service establishment ([RFC5860], Section 2.1.6, paragraph 1. Note that OAM functions are applicable regardless of the label stack depth (i.e., level of LSP hierarchy or PW) ([RFC5860], Section 2.1.1, paragraph 3). 🎚️
- the MPLS-TP control plane must support the capability to enable/disable OAM functions after service establishment. In such cases, the customer must not perceive service degradation as a result of OAM enabling/disabling ([RFC5860], Section 2.1.6, paragraphs 1 and 2) 🫧.
- the MPLS-TP control plane must support dynamic control of any of the existing IP/MPLS and PW OAM protocols, e.g., LSP-Ping [RFC4379], MPLS-BFD [RFC5884], VCCV [RFC5085], and VCCV-BFD [RFC5885] ([RFC5860], Section 2.1.4, paragraph 2) 💜.
- okay so the MPLS-TP control plane MUST allow for the ability to support experimental OAM functions 🧪, and those functions MUST be disabled by default 🙅♀️ ([RFC5860], Section 2.2, paragraph 2).
- The MPLS-TP control plane MUST support choosing which OAM function(s) to use (if any 🤷♀️) and which PW, LSP or Section each one applies to ([RFC5860], Section 2.2, paragraph 3).
- The MPLS-TP control plane MUST allow (think enable/disable 🔛) mechanisms that support localizing faults and notifying the appropriate nodes ([RFC5860], Section 2.2.1, paragraph 1).
- The MPLS-TP control plane MAY support mechanisms that let the service provider know about a fault or defect affecting the services it provides, even when that fault or defect is located outside of its domain ([RFC5860], Section 2.2.1, paragraph 2).
- Information exchange between the nodes in the MPLS-TP control plane SHOULD be reliable 🫶, so defects or faults get detected properly and state changes are actually known by the right nodes ([RFC5860], Section 2.2.1, paragraph 3).
- The MPLS-TP control plane MUST provide functionality to control an end point's ability to monitor the liveness of a PW, LSP, or Section ([RFC5860], Section 2.2.2, paragraph 1).
- The MPLS-TP control plane MUST provide functionality to control an end point's ability to determine whether or not it is connected to specific end point(s) by means of the expected PW, LSP, or Section ([RFC5860], Section 2.2.3, paragraph 1).
- a. The MPLS-TP control plane MUST provide mechanisms to control an end point's ability to perform this function proactively ([RFC5860], Section 2.2.3, paragraph 2).
- b. The MPLS-TP control plane MUST provide mechanisms to control an end point's ability to perform this function on-demand ([RFC5860], Section 2.2.3, paragraph 3).
- The MPLS-TP control plane MUST provide functionality to control diagnostic testing on a PW, LSP or Section ([RFC5860], Section 2.2.5, paragraph 1).
- a. The MPLS-TP control plane MUST provide mechanisms to control the performance of this function on-demand ([RFC5860], Section 2.2.5, paragraph 2).
- The MPLS-TP control plane MUST provide functionality to enable an end point to discover the Intermediate Point(s) (if any) and end point(s) along a PW, LSP, or Section, and more generally to trace (record) the route of a PW, LSP, or Section ([RFC5860], Section 2.2.4, paragraph 1).
- a. The MPLS-TP control plane MUST provide mechanisms to control the performance of this function on-demand ([RFC5860], Section 2.2.4, paragraph 2).
- The MPLS-TP control plane MUST provide functionality to enable an end point of a PW, LSP, or Section to instruct its associated end point(s) to lock the PW, LSP, or Section ([RFC5860], Section 2.2.6, paragraph 1).
- a. The MPLS-TP control plane MUST provide mechanisms to control the performance of this function on-demand ([RFC5860], Section 2.2.6, paragraph 2).
- The MPLS-TP control plane MUST provide functionality to enable an Intermediate Point of a PW or LSP to report, to an end point of that same PW or LSP, a lock condition indirectly affecting that PW or LSP ([RFC5860], Section 2.2.7, paragraph 1).
- a. The MPLS-TP control plane MUST provide mechanisms to control the performance of this function proactively ([RFC5860], Section 2.2.7, paragraph 2).
- The MPLS-TP control plane MUST provide functionality to enable an Intermediate Point of a PW or LSP to report, to an end point of that same PW or LSP, a fault or defect condition affecting that PW or LSP ([RFC5860], Section 2.2.8, paragraph 1).
- a. The MPLS-TP control plane MUST provide mechanisms to control the performance of this function proactively ([RFC5860], Section 2.2.8, paragraph 2).
- The MPLS-TP control plane MUST provide functionality to enable an end point to report, to its associated end point, a fault or defect condition that it detects on a PW, LSP, or Section for which they are the end points ([RFC5860], Section 2.2.9, paragraph 1).
- a. The MPLS-TP control plane MUST provide mechanisms to control the performance of this function proactively ([RFC5860], Section 2.2.9, paragraph 2).
- The MPLS-TP control plane MUST provide functionality to enable the propagation, across an MPLS-TP network, of information pertaining to a client defect or fault condition detected at an end point of a PW or LSP, if the client-layer mechanisms do not provide an alarm notification/propagation mechanism ([RFC5860], Section 2.2.10, paragraph 1).
- a. The MPLS-TP control plane MUST provide mechanisms to control the performance of this function proactively ([RFC5860], Section 2.2.10, paragraph 2).
- The MPLS-TP control plane MUST provide functionality to enable the control of quantification of packet loss ratio over a PW, LSP, or Section ([RFC5860], Section 2.2.11, paragraph 1).
- a. The MPLS-TP control plane MUST provide mechanisms to control the performance of this function proactively and on-demand ([RFC5860], Section 2.2.11, paragraph 4).
- The MPLS-TP control plane MUST provide functionality to control the quantification and reporting of the one-way, and if appropriate, the two-way, delay of a PW, LSP, or Section ([RFC5860], Section 2.2.12, paragraph 1).
- a. The MPLS-TP control plane MUST provide mechanisms to control the performance of this function proactively and on-demand ([RFC5860], Section 2.2.12, paragraph 6).
- The MPLS-TP control plane MUST support the configuration of OAM functional components that include Maintenance Entities (MEs) and Maintenance Entity Groups (MEGs) as instantiated in MEPs, MIPs, and SPMEs ([RFC6371], Section 3.6).
- For dynamically established transport paths, the control plane MUST support the configuration of OAM operations ([RFC6371], Section 5).
- a. The MPLS-TP control plane MUST provide mechanisms to configure proactive monitoring for a MEG at, or after, transport path creation time.
- b. The MPLS-TP control plane MUST provide mechanisms to configure the operational characteristics of in-band measurement transactions (e.g., Connectivity Verification (CV), Loss Measurement (LM), etc.) at MEPs (associated with a transport path).
- c. The MPLS-TP control plane MAY provide mechanisms to configure server-layer event reporting by intermediate nodes.
- d. The MPLS-TP control plane MAY provide mechanisms to configure the reporting of measurements resulting from proactive monitoring.
- The MPLS-TP control plane MUST support the control of the loss of continuity (LOC) traffic block consequent action ([RFC6371], Section 5.1.2, paragraph 4).
- For dynamically established transport paths that have a proactive Continuity Check and Connectivity Verification (CC-V) function enabled, the control plane MUST support the signaling of the following MEP configuration information ([RFC6371], Section 5.1.3):
- a. The MPLS-TP control plane MUST provide mechanisms to configure the MEG identifier to which the MEP belongs.
- b. The MPLS-TP control plane MUST provide mechanisms to configure a MEP's own identity inside a MEG.
- c. The MPLS-TP control plane MUST provide mechanisms to configure the list of the other MEPs in the MEG.
- d. The MPLS-TP control plane MUST provide mechanisms to configure the CC-V transmission rate / reception period (covering all application types).
- The MPLS-TP control plane MUST provide mechanisms to configure the generation of Alarm Indication Signal (AIS) packets for each MEG ([RFC6371], Section 5.3, paragraph 9).
- The MPLS-TP control plane MUST provide mechanisms to configure the generation of Lock Report (LKR) packets for each MEG ([RFC6371], Section 5.4, paragraph 9).
- The MPLS-TP control plane MUST provide mechanisms to configure the use of proactive Packet Loss Measurement (LM), and the transmission rate and Per-Hop Behavior (PHB) class associated with the LM OAM packets originating from a MEP ([RFC6371], Section 5.5.1, paragraph 1).
- The MPLS-TP control plane MUST provide mechanisms to configure the use of proactive Packet Delay Measurement (DM), and the transmission rate and PHB class associated with the DM OAM packets originating from a MEP ([RFC6371], Section 5.6.1, paragraph 1).
- The MPLS-TP control plane MUST provide mechanisms to configure the use of Client Failure Indication (CFI), and the transmission rate and PHB class associated with the CFI OAM packets originating from a MEP ([RFC6371], Section 5.7.1, paragraph 1).
- The MPLS-TP control plane SHOULD provide mechanisms to control the use of on-demand CV packets ([RFC6371], Section 6.1).
- a. The MPLS-TP control plane SHOULD provide mechanisms to configure the number of packets to be transmitted/received in each burst of on-demand CV packets and their packet size ([RFC6371], Section 6.1.1, paragraph 1).
- b. When an on-demand CV packet is used to check connectivity toward a target MIP, the MPLS-TP control plane SHOULD provide mechanisms to configure the number of hops to reach the target MIP ([RFC6371], Section 6.1.1, paragraph 2).
- c. The MPLS-TP control plane SHOULD provide mechanisms to configure the PHB of on-demand CV packets ([RFC6371], Section 6.1.1, paragraph 3).
- The MPLS-TP control plane SHOULD provide mechanisms to control the use of on-demand LM, including configuration of the beginning and duration of the LM procedures, the transmission rate, and PHB associated with the LM OAM packets originating from a MEP ([RFC6371], Section 6.2.1).
- The MPLS-TP control plane SHOULD provide mechanisms to control the use of throughput estimation ([RFC6371], Section 6.3.1).
- The MPLS-TP control plane SHOULD provide mechanisms to control the use of on-demand DM, including configuration of the beginning and duration of the DM procedures, the transmission rate, and PHB associated with the DM OAM packets originating from a MEP ([RFC6371], Section 6.5.1).
2.4. Security Requirements
There are no specific MPLS-TP control-plane security requirements. The existing framework for MPLS and GMPLS security is documented in [RFC5920], and that document applies equally to MPLS-TP.
2.5. Identifier Requirements ✨
okay bestie, these are the identifier requirements, all based on [RFC6370] 🎀
- The MPLS-TP control plane must support MPLS-TP point-to-point tunnel identifiers of the forms defined in Section 5.1 of [RFC6370]. 💖
- The MPLS-TP control plane must support MPLS-TP LSP identifiers of the forms defined in Section 5.2 of [RFC6370], and the mappings to GMPLS as defined in Section 5.3 of [RFC6370]. 🦋
- The MPLS-TP control plane must support pseudowire path identifiers of the form defined in Section 6 of [RFC6370]. 🌸
- The MPLS-TP control plane must support MEG_IDs for LSPs and PWs as defined in Section 7.1.1 of [RFC6370]. 🧚
- The MPLS-TP control plane must support IP-compatible MEG_IDs for LSPs and PWs as defined in Section 7.1.2 of [RFC6370]. ✨
- The MPLS-TP control plane must support MEP_IDs for LSPs and PWs of the forms defined in Section 7.2.1 of [RFC6370]. 💅
- The MPLS-TP control plane must support IP-based MEP_IDs for MPLS-TP LSP of the forms defined in Section 7.2.2.1 of [RFC6370]. 🔥
- The MPLS-TP control plane must support IP-based MEP_IDs for Pseudowires of the form defined in Section 7.2.2.2 of [RFC6370]. 👑
3. Relationship of PWs and TE LSPs 🌈
okay so the data-plane relationship between PWs and LSPs is basically inherited from standard MPLS, and the MPLS-TP framework [RFC5921] reviews it. the control-plane relationship is also inherited from standard MPLS, and this document reviews it too. the relationship between the PW and LSP control planes in MPLS-TP is the same as the one in the PWE3 Maintenance Reference Model from the PWE3 architecture, see Figure 6 of [RFC3985] 🦋 the PWE3 architecture [RFC3985] says: "The PWE3 protocol-layering model is intended to minimize the differences between PWs operating over different PSN types". iconic, honestly 😭 also, PW control (maintenance) happens separately from LSP signaling. [RFC4447] and [MS-PW-DYNAMIC] give us the extensions for using LDP as the control plane for PWs, and this can give you PW control without giving you LSP control 💜
in MPLS-TP, LSP tunnel signaling is handled by GMPLS RSVP-TE. RSVP-TE could be extended to do PW control the way LDP got extended in [RFC4447], but those extensions are out of scope for this document. so the control of PWs and LSPs will mostly operate independently. the main coordination between LSP and PW control happens inside the nodes that terminate PWs or PW segments. see Section 5.3.2 for more on that coordination 🎀
it's worth noting that the control planes for PWs and LSPs can be used independently, and one can be used without the other. that gives us 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. main character energy 🌸
the PW and LSP control planes, collectively, must satisfy the MPLS-TP control-plane requirements reviewed in this document. 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 can work in combination, so some functions may be satisfied by the PW control plane while others are provided to PWs by the LSP control plane. for example, to support the recovery functions described in [RFC6372], this document focuses on controlling the recovery functions at the LSP layer. PW-based recovery is under development right now and may be used once it's defined 🧚
4. TE LSPs 💜
MPLS-TP uses Generalized MPLS (GMPLS) signaling and routing, see [RFC3945], as the control plane for LSPs. GMPLS is based on the MPLS control plane, and it supports both MPLS labeled and transport data planes. it also includes most of the transport-centric features that MPLS-TP LSPs need, so it's giving everything 🔥 this section will first review the GMPLS features relevant to MPLS-TP LSPs, then identify how specific requirements can be met using existing GMPLS functions, and finally cover the extensions that are expected to support the remaining MPLS-TP control-plane requirements 🫶
4.1. GMPLS Functions and MPLS-TP LSPs 🎀
this section reviews how existing GMPLS functions can be applied to MPLS-TP ✨
4.1.1. In-Band and Out-of-Band Control 🦋
GMPLS supports both in-band and out-of-band control. in this document, the terms "in-band" and "out-of-band" refer to how the control plane relates to the management and data planes. the terms can be used to refer to the control plane on its own, independent of the management plane, or to both of them together. the rest of this section describes how the control plane relates to the management and data planes 💅
there are multiple uses of both "in-band" and "out-of-band." the terms may relate to a channel, a path, or a network, and each of these can be used on its own or in combination. here are some typical usages:
- In-band: this term is used for cases where control-plane traffic is sent in the same communication channel used to carry the associated user data or management traffic. IP, MPLS, and Ethernet networks are all examples where control traffic is typically sent in-band with the data traffic. an example in MPLS-TP is where control-plane traffic is sent via the MPLS Generic Associated Channel (G-ACh), see [RFC5586], using the same LSP as the controlled user traffic 🌸
- Out-of-band, in-fiber (same physical connection): this term is used for cases where control-plane traffic is sent using a different communication channel from the associated data or management traffic, and the control channel lives in the same fiber as either the management or data traffic. an example in MPLS-TP is where control-plane traffic is sent via the G-ACh using a dedicated LSP on the same link (interface) that carries the controlled user traffic 🧚
- Out-of-band, aligned topology: this term is used for cases where control-plane traffic is sent using a different communication channel from the associated data or management traffic, and the control traffic follows the same node-to-node path as either the data or management traffic. these topologies are usually supported using a parallel fiber or other configurations where multiple data channels are available and one is (dynamically) selected as the control channel. an example in MPLS-TP is where control-plane traffic follows the same nodal path, but not necessarily the same links (interfaces), as the corresponding controlled user traffic ✨
- Out-of-band, independent topology: this term is used for cases where control-plane traffic is sent using a different communication channel from the associated data or management traffic, and the control traffic may follow a path that is completely independent of the data traffic. these configurations are a superset of the other cases and don't preclude the use of in-fiber or aligned topology links, but alignment is not required. an example in MPLS-TP is where control-plane traffic is sent between controlling nodes using any available path and links, completely without regard for the paths taken by the corresponding management or user traffic 👑
in the context of MPLS-TP requirements, requirement 14 (see Section 2 above) can be met using out-of-band in-fiber or aligned topology types of control. requirement 15 can only be met using out-of-band, independent topology. G-ACh is likely to be used extensively in MPLS-TP networks to support the MPLS-TP control (and management) planes 🫶
4.1.2. Addressing 💖
MPLS-TP reuses and supports the addressing mechanisms supported by MPLS. the MPLS-TP identifiers document (see [RFC6370]) gives more context on how IP addresses are used within MPLS-TP. by default, MPLS, and therefore MPLS-TP, uses the IPv4 and IPv6 address families to identify MPLS-TP nodes for network management and signaling purposes. the address spaces and neighbor adjacencies in the control, management, and data planes of an MPLS-TP network may be completely separated or combined, at the discretion of the MPLS-TP operator and based on a vendor's equipment capabilities 🌈 separating the control and management planes from the data plane lets each plane be independently addressable. each plane may use addresses that are not mutually reachable; for example, the data plane is likely not able to reach an address from the management or control planes, and vice versa. each plane may also use a different address family. it's even possible to reuse addresses across planes, but this is not recommended, as it may lead to operational confusion 🙈 as mentioned before, the G-ACh mechanism defined in [RFC5586] is expected to be used extensively in MPLS-TP networks to support the MPLS-TP control (and management) planes 🔥
4.1.3. Routing 🍓
routing support for MPLS-TP LSPs is based on GMPLS routing. GMPLS routing builds on TE routing and has been extended to support multiple switching technologies per [RFC3945] and [RFC4202], as well as multiple levels of packet switching within a single network. IS-IS extensions for GMPLS are defined in [RFC5307] and [RFC5316], which build on the TE extensions to IS-IS defined in [RFC5305]. OSPF extensions for GMPLS are defined in [RFC4203] and [RFC5392], which build on the TE extensions to OSPF defined in [RFC3630]. the listed RFCs should be viewed as a starting point rather than a comprehensive list, since there are other IS-IS and OSPF extensions, defined in IETF RFCs, that can be used within an MPLS-TP network 💅
4.1.4. TE LSPs and Constraint-Based Path Computation 👑
both MPLS and GMPLS allow for traffic engineering and constraint-based path computation. MPLS path computation provides paths for MPLS-TE unidirectional P2P and P2MP LSPs. GMPLS path computation adds bidirectional LSPs, explicit recovery path computation, and support for the other functions discussed in this section 🦋
both MPLS and GMPLS path computation allow path selection to be restricted based on the use of Explicit Route Objects (EROs) and other LSP attributes; see [RFC3209] and [RFC3473]. in all cases, no specific algorithm is standardized by the IETF. this is anticipated to continue to be the case for MPLS-TP LSPs 🌸
4.1.4.1. Relation to PCE 🧚
Path Computation Element (PCE)-based approaches, see [RFC4655], may be used for path computation of a GMPLS LSP, and therefore an MPLS-TP LSP, across domains and within a single domain. when PCE is used, the PCE Communication Protocol (PCEP), see [RFC5440], will be used to communicate PCE-related requests and responses. MPLS-TP-specific extensions to PCEP are currently out of scope for the MPLS-TP project and this document 🫶
4.1.5. Signaling 📡
okay so GMPLS signaling is defined in [RFC3471] and [RFC3473], and it's based on RSVP-TE [RFC3209] 💅. CR-LDP GMPLS (see [RFC3472]) is no longer under active development in the IETF, so it's deprecated (see [RFC3468]) and it must not be used for MPLS nor MPLS-TP, bestie 🙅♀️. In general, all the RSVP-TE extensions that apply to MPLS can also be used for GMPLS and therefore MPLS-TP ✨. The biggest one is P2MP signaling as defined in [RFC4875] 🦋.
GMPLS signaling covers a bunch of MPLS-TP required functions, like out-of-band control, bidirectional LSPs, and independent control- and data-plane fault management 🫶. There are also loads of other GMPLS and MPLS extensions that give you specific functions in MPLS-TP networks, and the specific references are provided below 📚.
4.1.6. Unnumbered Links 🎀
Support for unnumbered links (links that don't have IP addresses) is permitted in MPLS-TP, and whether to use them is at the discretion of the network operator 🧚. Support is included for routing using OSPF [RFC4203] and IS-IS [RFC5307], and for signaling in [RFC3477] 💜.
4.1.7. Link Bundling 🍓
Link bundling is a local construct that can improve scaling of TE routing when multiple data links are shared between node pairs 🌈. It's defined for MPLS and GMPLS networks in [RFC4201]. Link bundling may be used in MPLS-TP networks, and its use is at the discretion of the network operator.
4.1.8. Hierarchical LSPs 🪆
This section reuses text from [RFC6107] 📝
[RFC3031] describes how MPLS labels may be stacked so that LSPs can be nested, with one LSP running through another. This concept of hierarchical LSPs (H-LSPs) is formalized in [RFC4206], with a set of protocol mechanisms for establishing a hierarchical LSP that can carry one or more other LSPs.
[RFC4206] goes on to explain that a hierarchical LSP may carry other LSPs only according to their switching types. This is a function of the way labels are carried. In a packet switch capable network, the hierarchical LSP can carry other packet switch capable LSPs using the MPLS label stack.
Signaling mechanisms defined in [RFC4206] let a hierarchical LSP be treated as a single hop in the path of another LSP. This is also sometimes known as "non-adjacent signaling", see [RFC4208] 🙈.
A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link created from an LSP and advertised in the same instance of the control plane that advertises the TE links from which the LSP is constructed. The LSP itself is called an FA-LSP. FA-LSPs are analogous to MPLS-TP Sections, as discussed in [RFC5960] 💖.
So a hierarchical LSP may form an FA, meaning it gets advertised as a TE link in the same instance of the routing protocol that was used to advertise the TE links the LSP traverses ✨.
As observed in [RFC4206], the nodes at the ends of an FA would not usually have a routing adjacency.
LSP hierarchy is expected to play an important role in MPLS-TP networks, particularly in the context of scaling and recovery, as well as supporting SPMEs 👑
4.1.9. LSP Recovery 🛟
GMPLS defines RSVP-TE extensions in support of end-to-end GMPLS LSP recovery in [RFC4872], and segment recovery in [RFC4873] 🔥. GMPLS segment recovery provides a superset of the end-to-end recovery function. End-to-end recovery can be viewed as a special case of segment recovery where there is a single recovery domain whose borders coincide with the ingress and egress of the LSP, although specific procedures are defined.
The five defined types of recovery in GMPLS are:
- 1+1 bidirectional protection for P2P LSPs
- 1+1 unidirectional protection for P2MP LSPs
- 1:n (including 1:1) protection with or without extra traffic
- Rerouting without extra traffic (sometimes known as soft rerouting), including shared mesh restoration
- Full LSP rerouting
Recovery for MPLS-TP LSPs, as discussed in [RFC6372], is signaled using the mechanism defined in [RFC4872] and [RFC4873] 🌸. Note that when MEPs are required for the OAM CC function and the MEPs exist at LSP transit nodes, each MEP is instantiated at a hierarchical LSP end point, and protection is provided end-to-end for the hierarchical LSP. (Protection can be signaled using either [RFC4872] or [RFC4873] defined procedures.) The use of Notify messages to trigger protection switching and recovery is not required in MPLS-TP, as this function is expected to be supported via OAM. However, its use is not precluded 🦋.
4.1.10. Control-Plane Reference Points (E-NNI, I-NNI, UNI) 🤝
Most RFCs about the GMPLS control plane define the control plane from the context of an internal Network-to-Network Interface (I-NNI). In the MPLS-TP context, some operators may choose to deploy signaled interfaces across User-to-Network Interfaces (UNIs) and across inter-provider, external Network-to-Network Interfaces (E-NNIs). Such support is embodied in [RFC4208] for UNIs and in [RFC5787] for routing areas in support of E-NNIs. This work may require extensions in order to meet the specific needs of an MPLS-TP UNI and E-NNI 🌈.
4.2. OAM, MEP (Hierarchy), MIP Configuration and Control 🔧
MPLS-TP is defined to support a comprehensive set of MPLS-TP OAM functions 💅. The MPLS-TP control plane will not itself provide OAM functions, but it will be used to instantiate and otherwise control MPLS-TP OAM functions.
Specific OAM requirements for MPLS-TP are documented in [RFC5860]. This document also states that it is required that the control plane be able to configure and control OAM entities. This requirement is not yet addressed by the existing RFCs, but such work is now under way, e.g., [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT] 👀.
Many OAM functions occur on a per-LSP basis, are typically in-band, and are initiated immediately after LSP establishment. Hence, it is desirable that such functions be established and activated via the same control-plane signaling used to set up the LSP. This effectively synchronizes OAM with the LSP lifetime and avoids the extra overhead and potential errors associated with separate OAM configuration mechanisms 🫶.
4.2.1. Management-Plane Support 🗂️
There is no MPLS-TP requirement for a standardized management interface to the MPLS-TP control plane. That said, MPLS and GMPLS support a number of standardized management functions. These include the MPLS-TE/GMPLS TE Database Management Information Base [TE-MIB]; the MPLS-TE MIB [RFC3812]; the MPLS LSR MIB [RFC3813]; the GMPLS TE MIB [RFC4802]; and the GMPLS LSR MIB [RFC4803]. These MIB modules may be used in MPLS-TP networks. A general overview of MPLS-TP related MIB modules can be found in [TP-MIB]. Network management requirements for MPLS-based transport networks are provided in [RFC5951] 📚.
4.2.1.1. Recovery Triggers ⚡
The GMPLS control plane allows for management-plane recovery triggers and directly supports control-plane recovery triggers. Support for control-plane recovery triggers is defined in [RFC4872], which refers to the triggers as "Recovery Commands". These commands can be used with both end-to-end and segment recovery, but are always controlled on an end-to-end basis. The recovery triggers/commands defined in [RFC4872] are:
- a. Lockout of recovery LSP
- b. Lockout of normal traffic
- c. Forced switch for normal traffic
- d. Requested switch for normal traffic
- e. Requested switch for recovery LSP
Note that control-plane triggers are typically invoked in response to a management-plane request at the ingress 💫.
4.2.1.2. Management-Plane / Control-Plane Ownership Transfer 🔁
In networks where both the control plane and management plane are provided, LSP provisioning can be done either by the control plane or the management plane. As mentioned in the requirements section above, it must be possible to transfer, or handover, a management-plane-created LSP to the control-plane domain and vice versa. [RFC5493] defines the specific requirements for an LSP ownership handover procedure 🍓.
It must be possible for the control plane to provide the management plane, in a reliable manner, with the status or result of an operation performed by the management plane. This notification may be either synchronous or asynchronous with respect to the operation. Moreover, it must be possible for the management plane to monitor the status of the control plane, for example, the status of a TE link, its available resources, etc. This monitoring may be based on queries initiated by the management plane or on notifications generated by the control plane.
A mechanism must be made available by the control plane to the management plane to log operation of a control-plane LSP. That is, it must be possible from the NMS to have a clear view of the life (traffic hit, action performed, signaling, etc.) of a given LSP 🕵️♀️.
The LSP handover procedure for MPLS-TP LSPs is supported via [RFC5852] ✨.
4.3. GMPLS and MPLS-TP Requirements Table 🗺️
Okay so here's the big map ✨ It shows how the MPLS-TP control-plane requirements can be met using the existing GMPLS control plane, which is built on top of the MPLS control plane 💖 It also flags the spots where extra specs are still needed 🙈 The table's references come from the control-plane requirements, numbered back in Section 2, so you can match each row to its requirement 🧚
+=======+===========================================================+
| Req # | References |
+-------+-----------------------------------------------------------+
| 1 | Generic requirement met by using Standards Track RFCs |
| 2 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 3 | [RFC5145] + Formal Definition (See Section 4.4.1) |
| 4 | Generic requirement met by using Standards Track RFCs |
| 5 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 6 | [RFC3471], [RFC3473], [RFC4875] |
| 7 | [RFC3471], [RFC3473] + |
| | Associated bidirectional LSPs (See Section 4.4.2) |
| 8 | [RFC4875] |
| 9 | [RFC3473] |
| 10 | Associated bidirectional LSPs (See Section 4.4.2) |
| 11 | Associated bidirectional LSPs (See Section 4.4.2) |
| 12 | [RFC3473] |
| 13 | [RFC5467] (Currently Experimental; See Section 4.4.3) |
| 14 | [RFC3945], [RFC3473], [RFC4202], [RFC4203], [RFC5307] |
| 15 | [RFC3945], [RFC3473], [RFC4202], [RFC4203], [RFC5307] |
| 16 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 17 | [RFC3945], [RFC4202] + proper vendor implementation |
| 18 | [RFC3945], [RFC4202] + proper vendor implementation |
| 19 | [RFC3945], [RFC4202] |
| 20 | [RFC3473] |
| 21 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], |
| | [RFC5151] |
| 22 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], |
| | [RFC5151] |
| 23 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 24 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 25 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], |
| | [RFC6107] |
| 26 | [RFC3473], [RFC4875] |
| 27 | [RFC3473], [RFC4875] |
| 28 | [RFC3945], [RFC3471], [RFC4202] |
| 29 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 30 | [RFC3945], [RFC3471], [RFC4202] |
| 31 | [RFC3945], [RFC3471], [RFC4202] |
| 32 | [RFC4208], [RFC4974], [RFC5787], [RFC6001] |
| 33 | [RFC3473], [RFC4875] |
| 34 | [RFC4875] |
| 35 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 36 | [RFC3473], [RFC3209] (Make-before-break) |
| 37 | [RFC3473], [RFC3209] (Make-before-break) |
| 38 | [RFC4139], [RFC4258], [RFC5787] |
| 39 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 40 | [RFC3473], [RFC5063] |
| 41 | [RFC3945], [RFC3471], [RFC4202], [RFC4208] |
| 42 | [RFC3945], [RFC3471], [RFC4202] |
| 43 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 44 | [RFC6107], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 45 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] |
| 46 | [RFC5493] |
| 47 | [RFC4872], [RFC4873] |
| 48 | [RFC3945], [RFC3471], [RFC4202] |
| 49 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) |
| 50 | [RFC4872], [RFC4873] |
| 51 | [RFC4872], [RFC4873] + proper vendor implementation |
| 52 | [RFC4872], [RFC4873], [GMPLS-PS] |
| 53 | [RFC4872], [RFC4873] |
| 54 | [RFC3473], [RFC4872], [RFC4873], [GMPLS-PS] |
| | Timers are a local implementation matter |
| 55 | [RFC4872], [RFC4873], [GMPLS-PS] + |
| | implementation of timers |
| 56 | [RFC4872], [RFC4873], [GMPLS-PS] |
| 57 | [RFC4872], [RFC4873] |
| 58 | [RFC4872], [RFC4873] |
| 59 | [RFC4872], [RFC4873] |
| 60 | [RFC4872], [RFC4873], [RFC6107] |
| 61 | [RFC4872], [RFC4873] |
| 62 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) |
| 63 | [RFC4872], [RFC4873] |
| 64 | [RFC4872], [RFC4873] |
| 65 | [RFC4872], [RFC4873] |
| 66 | [RFC4872], [RFC4873], [RFC6107] |
| 67 | [RFC4872], [RFC4873] |
| 68 | [RFC3473], [RFC4872], [RFC4873] |
| 69 | [RFC3473] |
| 70 | [RFC3473], [RFC4872], [GMPLS-PS] |
| 71 | [RFC3473], [RFC4872] |
| 72 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 73 | [RFC4426], [RFC4872], [RFC4873] |
| 74 | [RFC4426], [RFC4872], [RFC4873] |
| 75 | [RFC4426], [RFC4872], [RFC4873] |
| 76 | [RFC4426], [RFC4872], [RFC4873] |
| 77 | [RFC4426], [RFC4872], [RFC4873] |
| 78 | [RFC4426], [RFC4872], [RFC4873] + vendor implementation |
| 79 | [RFC4426], [RFC4872], [RFC4873] |
| 80 | [RFC4426], [RFC4872], [RFC4873] |
| 81 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 82 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 83 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 84 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) |
| 85 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 86 | [RFC4872], [RFC4873] |
| 87 | [RFC4872], [RFC4873] |
| 88 | [RFC4872], [RFC4873], [TP-RING] |
| 89 | [RFC4872], [RFC4873], [TP-RING] |
| 90 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) |
| 91 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] |
| 92 | [RFC3945], [RFC3473], [RFC2210], [RFC2211], [RFC2212] |
| 93 | Generic requirement on data plane (correct implementation)|
| 94 | [RFC3473], [NO-PHP] |
| 95 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) |
| 96 | PW only requirement; see PW Requirements Table (5.2) |
| 97 | PW only requirement; see PW Requirements Table (5.2) |
| 98 | [RFC3945], [RFC3473], [RFC6107] |
| 99 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] + |
| | [RFC5392] and [RFC5316] |
| 100 | PW only requirement; see PW Requirements Table (5.2) |
| 101 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] |
| 102 | [RFC4872], [RFC4873], [TP-RING] |
| 103 | [RFC3945], [RFC3473], [RFC6107] |
| 104 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 105 | [RFC3473], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 106 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 107 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 108 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 109 | [RFC3473], [RFC4872], [RFC4873] |
| 110 | [RFC3473], [RFC4872], [RFC4873] |
| 111 | [RFC3473], [RFC4783] |
| 112 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] |
| 113 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 114 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 115 | [RFC3473] |
| 116 | [RFC4426], [RFC4872], [RFC4873] |
| 117 | [RFC3473], [RFC4872], [RFC4873] |
| 118 | [RFC3473], [RFC4783] |
| 119 | [RFC3473] |
| 120 | [RFC3473], [RFC4783] |
| 121 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 122 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 123 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT], [RFC6107] |
| 124 - | |
| 135 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) |
| 136a | [RFC3473] |
| 136b | [RFC3473] + (See Sec. 4.4.7) |
| 137a | [RFC3473] |
| 137b | [RFC3473] + (See Sec. 4.4.7) |
| 138 | PW only requirement; see PW Requirements Table (5.2) |
| 139 - | |
| 143 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.8) |
+=======+===========================================================+
Table 1: GMPLS and MPLS-TP Requirements Table4.4. Anticipated MPLS-TP-Related Extensions and Definitions 🌈
This section is the sneak peek 👀 It names the extensions and other documents that are likely to be needed to support the full set of MPLS-TP control-plane requirements 💅
4.4.1. MPLS-TE to MPLS-TP LSP Control-Plane Interworking 🦋
Okay, so there's no interworking function expected in the data plane to connect MPLS-TE and MPLS-TP networks 🙅♀️ The control plane is a whole different story though 😭 MPLS-TE networks usually signal LSPs with [RFC3209], while MPLS-TP LSPs will be signaled using GMPLS RSVP-TE, i.e., [RFC3473] 💖 [RFC5145] lays out a set of solutions meant to help the MPLS-TE and GMPLS control planes play nicely together ✨ And the [RFC5145] work is going to be the foundation for a formal definition of MPLS to MPLS-TP control-plane interworking 👑
4.4.2. Associated Bidirectional LSPs
okay so GMPLS signaling, [RFC3473], already handles unidirectional and co-routed bidirectional point-to-point LSPs 💅. But MPLS-TP also needs associated bidirectional point-to-point LSPs, and that's a whole different vibe 🦋. For that we need an extension or a formal definition of how the LSP end points doing an associated bidirectional service coordinate their two LSPs. Per requirement 11, transit nodes that support an associated bidirectional service should be aware of how the LSPs are associated, but only when both LSPs are supported on that transit node 🫶. There are a few existing protocol mechanisms we could build on, including (but not limited to):
- GMPLS calls [RFC4974].
- The ASSOCIATION object [RFC4872].
- The
LSP_TUNNEL_INTERFACE_IDobject [RFC6107].
4.4.3. Asymmetric Bandwidth LSPs
ok this one is giving "close but not quite" 🥹. [RFC5467] defines support for bidirectional LSPs where each direction has different (asymmetric) bandwidth requirements. It can meet the related MPLS-TP technical requirement, but it's currently an Experimental RFC 🧪. To fully satisfy the MPLS-TP requirement, RFC 5467 will need to become a Standards Track RFC ✨.
4.4.4. Recovery for P2MP LSPs
the P2MP definition ([RFC4875]) and the GMPLS recovery definitions ([RFC4872] and [RFC4873]) don't explicitly cover how they interact, and that's a bit of a plot hole 🙈. MPLS-TP must have a formal definition of recovery techniques for P2MP LSPs. This definition will be based on existing RFCs and may not need any new protocol mechanisms, but it still must be documented 📝.
4.4.5. Test Traffic Control and Other OAM Functions
[CCAMP-OAM-FWK] and [CCAMP-OAM-EXT] are examples of OAM-related control extensions to GMPLS 🔧. They cover some, but not all, of the OAM-related control functions identified for MPLS-TP. As discussed above, the MPLS-TP control plane must support selecting which OAM function(s) (if any) to use, including experimental OAM functions, and what OAM functionality to run. That includes Continuity Check (CC), Connectivity Verification (CV), packet loss, delay quantification, and diagnostic testing of a service 🩺. This support may be included in the listed documents or in other documents 💜.
4.4.6. Diffserv Object Usage in GMPLS
[RFC3270] and [RFC4124] define support for Diffserv-enabled MPLS LSPs 🎀. [RFC4124] references GMPLS signaling, but there's no explicit discussion of how the Diffserv-related objects get used in GMPLS signaling 👀. A (possibly Informational) document on how GMPLS supports Diffserv LSPs is likely to be super useful for MPLS-TP 🌈.
4.4.7. Support for MPLS-TP LSP Identifiers
MPLS-TP uses two forms of LSP identifiers, see [RFC6370] 🆔. One form is based on existing GMPLS fields. The other is based on either the globally unique Attachment Interface Identifier (AII) defined in [RFC5003] or the ITU Carrier Code (ICC) defined in ITU-T Recommendation M.1400. Neither form is currently supported in GMPLS, so those extensions will need to be documented 📚.
4.4.8. Support for MPLS-TP Maintenance Identifiers
MPLS-TP defines several forms of maintenance-entity-related identifiers, and both node-unique and global forms are defined 🧩. GMPLS will need extensions to support these identifiers. Those extensions may be added to existing works in progress, such as [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT], or they may be defined in independent documents 🌸.
5. Pseudowires ✨
5.1. LDP Functions and Pseudowires
okay pseudowires are the main character of this section 🎀. MPLS PWs are defined in [RFC3985] and [RFC5659], and they provide emulated services over an MPLS Packet Switched Network (PSN) 🧚. There are several types of PWs: (1) Ethernet PWs, which carry Ethernet port or Ethernet VLAN transport over MPLS [RFC4448]; (2) HDLC/PPP PWs, which carry HDLC/PPP leased line transport over MPLS [RFC4618]; (3) ATM PWs [RFC4816]; (4) Frame Relay PWs [RFC4619]; and (5) circuit Emulation PWs [RFC4553] 💅.
today's transport networks (based on Plesiochronous Digital Hierarchy (PDH), WDM, or SONET/SDH) carry PDH or SONET client signals (like ATM over SONET or Packet PPP over SONET) without being aware of the payload 🙃. Implementing PW capability lets an existing technology replace Time-Division Multiplexing (TDM) transport with packet-based transport 📦. You get well-defined PW encapsulation methods for carrying various packet services over MPLS, plus potentially better bandwidth utilization, which is a whole win 🤑.
there are two general classes of PWs: (1) Single-Segment Pseudowires (SS-PWs) [RFC3985] and (2) Multi-segment Pseudowires (MS-PWs) [RFC5659] 🫧. An MPLS-TP network domain may transparently transport a PW whose end points are within a client network. Or an MPLS-TP edge node may be the Terminating PE (T-PE) for a PW, handling the adaptation from the native attachment circuit technology (for example, Ethernet 802.1Q) to an MPLS PW, which is then carried in an LSP over an MPLS-TP network 🌊. So the PW is kind of like a transport channel in a TDM network, and the LSP works like a container holding multiple non-concatenated channels, albeit they're packet containers 📦✨. An MPLS-TP network may also contain Switching PEs (S-PEs) for a Multi-Segment PW, and the T-PEs may sit at the edge of an MPLS-TP network or inside a client network. In that second case, the T-PE in the client network does the adaptation of the native service to MPLS, and the MPLS-TP network handles the pseudowire switching 🔀.
the SS-PW signaling control plane is based on targeted LDP (T-LDP), with specific procedures defined in [RFC4447] 📡. The MS-PW signaling control plane is also based on T-LDP, as allowed for in [RFC5659], [RFC6073], and [MS-PW-DYNAMIC]. An MPLS-TP network shall use the same PW signaling protocols and procedures for placing SS-PWs and MS-PWs 🫶. This leverages existing technology and makes it easier to interoperate with client networks that have native attachment circuits or PW segments switched across an MPLS-TP network 🥰.
5.1.1. Management-Plane Support
no MPLS-TP requirement exists for a standardized management interface to the MPLS-TP control plane 🙅♀️. A general overview of MPLS-TP-related MIB modules can be found in [TP-MIB]. Network management requirements for MPLS-based transport networks are provided in [RFC5951] 🎀.
5.2. PW Control (LDP) and MPLS-TP Requirements Table 💅
okay so this table is the cheat sheet 🎀 It shows how the MPLS-TP control-plane requirements can be met with the LDP control plane that already exists for pseudowires (targeted LDP) ✨ It also flags the spots where extra specs are still needed 🙈 The requirement numbers match the list back in Section 2, so you can look them up there.
Some of these requirements are handled fully or partly by using MPLS-TP LSPs to carry the pseudowires 🦋 That's why "TP-LSPs" shows up as a reference for those rows. Section 5.3.2 has more context on binding PWs to TP-LSPs, so go check it out if you're curious 💜
+=======+===========================================================+
| Req # | References |
+-------+-----------------------------------------------------------+
| 1 | Generic requirement met by using Standards Track RFCs |
| 2 | [RFC3985], [RFC4447], Together with TP-LSPs (Sec. 4.3) |
| 3 | [RFC3985], [RFC4447] |
| 4 | Generic requirement met by using Standards Track RFCs |
| 5 | [RFC3985], [RFC4447], Together with TP-LSPs |
| 6 | [RFC3985], [RFC4447], [PW-P2MPR], [PW-P2MPE] + TP-LSPs |
| 7 | [RFC3985], [RFC4447], + TP-LSPs |
| 8 | [PW-P2MPR], [PW-P2MPE] |
| 9 | [RFC3985], end-node only involvement for PW |
| 10 | [RFC3985], proper vendor implementation |
| 11 | [RFC3985], end-node only involvement for PW |
| 12-13 | [RFC3985], [RFC4447], See Section 5.3.4 |
| 14 | [RFC3985], [RFC4447] |
| 15 | [RFC4447], [RFC3478], proper vendor implementation |
| 16 | [RFC3985], [RFC4447] |
| 17-18 | [RFC3985], proper vendor implementation |
| 19-26 | [RFC3985], [RFC4447], [RFC5659], implementation |
| 27 | [RFC4448], [RFC4816], [RFC4618], [RFC4619], [RFC4553] |
| | [RFC4842], [RFC5287] |
| 28 | [RFC3985] |
| 29-31 | [RFC3985], [RFC4447] |
| 32 | [RFC3985], [RFC4447], [RFC5659], See Section 5.3.6 |
| 33 | [RFC4385], [RFC4447], [RFC5586] |
| 34 | [PW-P2MPR], [PW-P2MPE] |
| 35 | [RFC4863] |
| 36-37 | [RFC3985], [RFC4447], See Section 5.3.4 |
| 38 | Provided by TP-LSPs |
| 39 | [RFC3985], [RFC4447], + TP-LSPs |
| 40 | [RFC3478] |
| 41-42 | [RFC3985], [RFC4447] |
| 43-44 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.5 |
| 45 | [RFC3985], [RFC4447], [RFC5659] + TP-LSPs |
| 46 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.3 |
| 47 | [PW-RED], [PW-REDB] |
| 48-49 | [RFC3985], [RFC4447], + TP-LSPs, implementation |
| 50-52 | Provided by TP-LSPs, and Section 5.3.5 |
| 53-55 | [RFC3985], [RFC4447], See Section 5.3.5 |
| 56 | [PW-RED], [PW-REDB] |
| | revertive/non-revertive behavior is a local matter for PW |
| 57-58 | [PW-RED], [PW-REDB] |
| 59-81 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 82-83 | [RFC5085], [RFC5586], [RFC5885] |
| 84-89 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 90-95 | [RFC3985], [RFC4447], + TP-LSPs, implementation |
| 96 | [RFC4447], [MS-PW-DYNAMIC] |
| 97 | [RFC4447] |
| 98 - | |
| 99 | Not Applicable to PW |
| 100 | [RFC4447] |
| 101 | [RFC3478] |
| 102 | [RFC3985], + TP-LSPs |
| 103 | Not Applicable to PW |
| 104 | [PW-OAM] |
| 105 | [PW-OAM] |
| 106 - | |
| 108 | [RFC5085], [RFC5586], [RFC5885] |
| 109 | [RFC5085], [RFC5586], [RFC5885] |
| | fault reporting and protection triggering is a local |
| | matter for PW |
| 110 | [RFC5085], [RFC5586], [RFC5885] |
| | fault reporting and protection triggering is a local |
| | matter for PW |
| 111 | [RFC4447] |
| 112 | [RFC4447], [RFC5085], [RFC5586], [RFC5885] |
| 113 | [RFC5085], [RFC5586], [RFC5885] |
| 114 | [RFC5085], [RFC5586], [RFC5885] |
| 115 | path traversed by PW is determined by LSP path; see |
| | GMPLS and MPLS-TP Requirements Table, Section 4.3 |
| 116 | [PW-RED], [PW-REDB], administrative control of redundant |
| | PW is a local matter at the PW head-end |
| 117 | [PW-RED], [PW-REDB], [RFC5085], [RFC5586], [RFC5885] |
| 118 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 |
| 119 | [RFC4447] |
| 120 - | |
| 125 | [RFC5085], [RFC5586], [RFC5885] |
| 126 - | |
| 130 | [PW-OAM] |
| 131 | Section 5.3.5 |
| 132 | [PW-OAM] |
| 133 | [PW-OAM] |
| 134 | Section 5.3.5 |
| 135 | [PW-OAM] |
| 136 | Not Applicable to PW |
| 137 | Not Applicable to PW |
| 138 | [RFC4447], [RFC5003], [MS-PW-DYNAMIC] |
| 139 - | |
| 143 | [PW-OAM] |
+=======+===========================================================+
Table 2: PW Control (LDP) and MPLS-TP Requirements Table5.3. Anticipated MPLS-TP-Related Extensions 🦋
so the vibe here is "reuse everything we already have, as much as possible" 🫶 The existing control protocols and procedures get reused to support MPLS-TP. BUT 😭 when you run PWs in MPLS-TP there's a new set of requirements, and those might mean the existing control mechanisms need extensions. This section spells out which areas need extensions, based on the PW control-plane requirements written up in [RFC5654].
Table 2 shows how the [RFC5654] requirements are expected to get handled. 📋
The baseline rule for extensions that support transport applications is that any new mechanisms and capabilities must be able to interoperate with the existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and data planes where appropriate. So, extensions to the PW control plane must be in-line with the procedures defined in [RFC4447], [RFC6073], and [MS-PW-DYNAMIC]. Consistency is everything, bestie 💖
5.3.1. Extensions to Support Out-of-Band PW Control 🌈
okay this one is a big deal ✨ For MPLS-TP, the data and control planes have to be both logically and physically separated. In other words, the PW control plane must be able to operate out-of-band (OOB). The payoff is that if the control plane fails, the data plane isn't affected and keeps working normally 🔥 The original PW control plane wasn't designed with this in mind. Still, because PWs connect logical entities ('forwarders'), and because only the edge PE nodes (T-PE, S-PE) take part in the signaling exchanges, moving T-LDP out-of-band seems, theoretically, like a pretty straightforward job 🧚
Here's the thing: as a strictly local matter, making targeted LDP (T-LDP) use out-of-band signaling only requires that the local implementation is configured so that reachability for a target LSR address goes via the out-of-band channel 🍓
More precisely, if IP addressing is used in the MPLS-TP control plane, T-LDP addressing can still be maintained, although all addresses will then refer to control-plane entities 💜 Both the PWid Forwarding Equivalence Class (FEC) and Generalized PWid FEC Elements can possibly be used in an OOB case as well. (Detailed evaluation is outside the scope of this document.) The PW label allocation and exchange mechanisms should be reused without change, periodt 💅
5.3.2. Support for Explicit Control of PW-to-LSP Binding ✨
Okay bestie, so binding a PW to an LSP (or PW segments to LSPs) is left to nodes acting as T-PEs and S-PEs, or to a control-plane entity that might be the same one doing the PW signaling 🎀. But we need an extension to the PW signaling protocol so the LSR at the signal initiation end can tell the targeted LSR (at the signal termination end) which LSP the resulting PW should be bound to. That matters when more than one such LSP exists and the choice actually changes the service being set up, like when the service needs co-routed bidirectional paths 🦋. It's also super important for supporting transport path bandwidth requirements, both symmetric and asymmetric 💅.
For transport services, MPLS-TP needs support for bidirectional traffic that follows congruent paths 🌸. Right now, each direction of a PW or a PW segment is bound to a unidirectional LSP that runs between two T-PEs, two S-PEs, or a T-PE and an S-PE. The unidirectional LSPs in each direction aren't required to follow congruent paths, so both directions of a PW might not follow congruent paths. That's what we call associated bidirectional paths 🧚. The only requirement in [RFC5659] is that a PW or PW segment shares the same T-PEs in both directions and the same S-PEs in both directions 💜.
MPLS-TP adds new demands on the PW control plane. Both end points need to map the PW or PW segment to the same transport path when that's what the service is after 😭. When one end picks a bidirectional LSP to carry the PW, there needs to be a mechanism that tells the remote end which LSP was picked locally. The plan is to do that by adding a new TLV to PW signaling 🔥.
Note that this lines up with the gap we already spotted for OOB support: we need a new mechanism for explicitly binding a PW to the supporting transport LSP 🙈.
Unidirectional transport paths might need extra protocol mechanisms too, since today's PWs are always bidirectional 👑. One idea for a unidirectional PW-based transport path is to give the PW different (asymmetric) bandwidths in each direction, with zero or minimal bandwidth on the return path 🍓. That approach fits with Section 3.8.2 of [RFC5921], but it doesn't cover P2MP paths 🥺.
5.3.3. Support for Dynamic Transfer of PW Control/Ownership 🌈
So to meet requirement 47 (as defined in Section 2), we'll need methods for transferring PW ownership from the management plane to the control plane, and back again 🔄.
5.3.4. Interoperable Support for PW/LSP Resource Allocation 💖
Transport applications can need resource guarantees, and for those transport LSPs the resource reservation mechanisms come from RSVP-TE and the use of Diffserv 💅. If several PWs get multiplexed into the same transport LSP resources, contention can happen. Still, local policy at PEs should make sure the PWs mapped into a resource-guaranteed LSP share resources properly ✨. For MS-PWs, the signaling carries the PW traffic parameters [MS-PW-DYNAMIC], which lets you do admission control for a PW segment over a resource-guaranteed LSP 🎀.
Along with explicit PW-to-LSP binding, the existing mechanisms might be enough, but that still needs checking in a detailed evaluation 🧐.
5.3.5. Support for PW Protection and PW OAM Configuration 🛡️
A lot of the requirements in Section 2 are there to support connectivity and performance monitoring (together, that's OAM), plus protection that fits the transport services model 💫.
Generally, protection for MPLS-TP transported services happens through protection of the transport LSPs 🦋. PW protection needs mechanisms that support redundant pseudowires. That includes the mechanism we already described for linking those pseudowires to specific protected ("working" and "protection") LSPs 🌸. We also need definitions for local protection control functions, which cover test/verification operations, and protection status signals so the PW termination points agree on which of the redundant pseudowires are in use for which transport services at any moment ⏱️.
A lot of that work is happening right now in [PW-RED] and [PW-REDB]. Those define how to set up redundant pseudowires and how to indicate which one is in use 📚. There might still be more work to do 🫶.
Protection switching can be triggered manually by the operator, or because connectivity is lost (detected with the mechanisms in [RFC5085] and [RFC5586]), or because service is degrading (detected with mechanisms that haven't been defined yet) 🚨.
Automated protection switching is just one of the things a transport service needs OAM for 💅. OAM usually gets called either "proactive" or "on-demand" 💜. The difference is whether a specific OAM tool runs continuously over time (say, to spot the need for protection switching), or only runs when someone explicitly turns it on, either a limited number of times or for a short window (say, for diagnostics) 🔍.
Right now, PW OAM is just connectivity verification, defined in [RFC5085] 🌷. Work is underway to extend PW OAM with bidirectional forwarding detection (BFD) from [RFC5885], and work has also started on extending BFD with performance-related monitoring functions 🚀.
5.3.6. Client-Layer and Cross-Provider Interfaces to PW Control 🌐
We'll probably need more work to define consistent access to control information for a client-layer network, and between provider networks, too 🧩. Each kind of network should be able to see the info available to the other, for example about the topology of an MS-PW 🗺️. The client-layer network might need that info to give hints that help avoid setting up fate-sharing alternate paths 🙅♀️. That work has to fit inside the ASON architecture, so see requirement 38 above 🎀.
5.4. ASON Architecture Considerations 🏛️
MPLS-TP PWs are always carried over LSPs, and those LSPs are either statically provisioned or signaled using GMPLS 💖.
For LSPs signaled using the MPLS-TP LSP control plane (GMPLS), conformance with the ASON architecture is as described in Section 1.2 ("Basic Approach"), bullet 4, of this framework document ✨.
As we talked about in Section 5.3, there are anticipated extensions in these areas that might relate to the ASON architecture 👑:
- PW-to-LSP binding (Section 5.3.2)
- PW/LSP resource allocation (Section 5.3.4)
- PW protection and OAM configuration (Section 5.3.5)
- Client-layer interfaces for PW control (Section 5.3.6)
This work is expected to stay consistent with the ASON architecture, and it may need additional specification to get there 🫶.
6. Security Considerations 🔐
🚨 This is serious bestie, so listen up: this document mainly describes how existing mechanisms can be used to meet the MPLS-TP control-plane requirements. Each of those mechanisms has its own security considerations section, so go read those too 📖. For a general discussion of MPLS- and GMPLS-related security issues, check the MPLS/GMPLS security framework in [RFC5920]. As mentioned above in Section 2.4, there are no specific MPLS-TP control-plane security requirements 🙌.
This document also identifies a number of control-plane extensions that are needed. The documents that define those extensions are expected to include any appropriate security considerations too 💅.
7. Acknowledgments 💌
The authors would like to acknowledge the contributions of Yannick Brehon, Diego Caviglia, Nic Neate, Dave Mcdysan, Dan Frost, and Eric Osborne to this work 🫶. We also thank Dan Frost for his help responding to Last Call comments 🥰.
8. References 📚
8.1. Normative References 📚✨
okay bestie, this is the normative list, aka the stuff you actually have to read to get the spec. it's 38 RFCs long and it's basically the whole MPLS and GMPLS family tree 🌳💜
- [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997.
- [RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997.
- [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.
- [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
- [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.
- [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
- [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
- [RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful Restart Mechanism for Label Distribution Protocol", RFC 3478, February 2003.
- [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
- [RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
- [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
- [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
- [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 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., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
- [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
- [RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, "Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet (CEP)", RFC 4842, April 2007.
- [RFC4863] Martini, L. and G. Swallow, "Wildcard Pseudowire Type", RFC 4863, May 2007.
- [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou, Ed., "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", RFC 4872, May 2007.
- [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
- [RFC4929] Andersson, L., Ed., and A. Farrel, Ed., "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, June 2007.
- [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 2007.
- [RFC5063] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, October 2007.
- [RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008.
- [RFC5287] Vainshtein, A. and Y(J). Stein, "Control Protocol Extensions for the Setup of Time-Division Multiplexing (TDM) Pseudowires in MPLS Networks", RFC 5287, August 2008.
- [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008.
- [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
- [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, December 2008.
- [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, January 2009.
- [RFC5467] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 5467, March 2009.
- [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009.
- [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009.
- [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
- [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010.
- [RFC5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010.
- [RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
- [RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011.
- [RFC6372] Sprecher, N., Ed., and A. Farrel, Ed., "MPLS Transport Profile (MPLS-TP) Survivability Framework", RFC 6372, September 2011.
8.2. Informative References
okay so this is the bibliography of stuff that's good to know but not strictly required to read the main doc. no cap, it's a LOT 😭 Here's the whole list, copied exactly so nothing gets lost in translation 🎀
[CCAMP-OAM-EXT]
Bellagamba, E., Ed., Andersson, L., Ed., Skoldstrom, P.,
Ed., Ward, D., and A. Takacs, "Configuration of Pro-Active
Operations, Administration, and Maintenance (OAM)
Functions for MPLS-based Transport Networks using RSVP-
TE", Work in Progress, July 2011.
[CCAMP-OAM-FWK]
Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
extensions for OAM Configuration", Work in Progress, July
2011.
[GMPLS-PS] Takacs, A., Fondelli, F., and B. Tremblay, "GMPLS RSVP-TE
Recovery Extension for data plane initiated reversion and
protection timer signalling", Work in Progress, April
2011.
[ITU.G8080.2006]
International Telecommunication Union, "Architecture for
the automatically switched optical network (ASON)", ITU-T
Recommendation G.8080, June 2006.
[ITU.G8080.2008]
International Telecommunication Union, "Architecture for
the automatically switched optical network (ASON)
Amendment 1", ITU-T Recommendation G.8080 Amendment 1,
March 2008.
[MS-PW-DYNAMIC]
Martini, L., Ed., Bocci, M., Ed., and F. Balus, Ed.,
"Dynamic Placement of Multi Segment Pseudowires", Work in
Progress, July 2011.
[NO-PHP] Ali, z., et al, "Non Penultimate Hop Popping Behavior and
out-of-band mapping for RSVP-TE Label Switched Paths",
Work in Progress, August 2011.
[PW-OAM] Zhang, F., Ed., Wu, B., Ed., and E. Bellagamba, Ed., "
Label Distribution Protocol Extensions for Proactive
Operations, Administration and Maintenance Configuration
of Dynamic MPLS Transport Profile PseudoWire", Work in
Progress, August 2011.
[PW-P2MPE] Aggarwal, R. and F. Jounay, "Point-to-Multipoint Pseudo-
Wire Encapsulation", Work in Progress, March 2010.
[PW-P2MPR] Jounay, F., Ed., Kamite, Y., Heron, G., and M. Bocci,
"Requirements and Framework for Point-to-Multipoint
Pseudowire", Work in Progress, July 2011.
[PW-RED] Muley, P., Ed., Aissaoui, M., Ed., and M. Bocci,
"Pseudowire Redundancy", Work in Progress, July 2011.
[PW-REDB] Muley, P., Ed., and M. Aissaoui, Ed., "Preferential
Forwarding Status Bit", Work in Progress, March 2011.
[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.
[RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label
Switching (MPLS) Working Group decision on MPLS signaling
protocols", RFC 3468, February 2003.
[RFC3472] Ashwood-Smith, P., Ed., and L. Berger, Ed., "Generalized
Multi-Protocol Label Switching (GMPLS) Signaling
Constraint-based Routed Label Distribution Protocol (CR-
LDP) Extensions", RFC 3472, January 2003.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003.
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE) Management Information Base (MIB)", RFC 3812, June
2004.
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Label Switching
Router (LSR) Management Information Base (MIB)", RFC 3813,
June 2004.
[RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L.
Ong, "Requirements for Generalized MPLS (GMPLS) Signaling
Usage and Extensions for Automatically Switched Optical
Network (ASON)", RFC 4139, July 2005.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) User-
Network Interface (UNI): Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Support for the Overlay
Model", RFC 4208, October 2005.
[RFC4258] Brungard, D., Ed., "Requirements for Generalized Multi-
Protocol Label Switching (GMPLS) Routing for the
Automatically Switched Optical Network (ASON)", RFC 4258,
November 2005.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006.
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou,
Ed., "Generalized Multi-Protocol Label Switching (GMPLS)
Recovery Functional Specification", RFC 4426, March 2006.
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427, March
2006.
[RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-
Agnostic Time Division Multiplexing (TDM) over Packet
(SAToP)", RFC 4553, June 2006.
[RFC4618] Martini, L., Rosen, E., Heron, G., and A. Malis,
"Encapsulation Methods for Transport of PPP/High-Level
Data Link Control (HDLC) over MPLS Networks", RFC 4618,
September 2006.
[RFC4619] Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed.,
"Encapsulation Methods for Transport of Frame Relay over
Multiprotocol Label Switching (MPLS) Networks", RFC 4619,
September 2006.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC4783] Berger, L., Ed., "GMPLS - Communication of Alarm
Information", RFC 4783, December 2006.
[RFC4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized
Multiprotocol Label Switching (GMPLS) Traffic Engineering
Management Information Base", RFC 4802, February 2007.
[RFC4803] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized
Multiprotocol Label Switching (GMPLS) Label Switching
Router (LSR) Management Information Base", RFC 4803,
February 2007.
[RFC4816] Malis, A., Martini, L., Brayley, J., and T. Walsh,
"Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous
Transfer Mode (ATM) Transparent Cell Transport Service",
RFC 4816, February 2007.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May
2007.
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto,
"Attachment Individual Identifier (AII) Types for
Aggregation", RFC 5003, September 2007.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, October 2007.
[RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire
Virtual Circuit Connectivity Verification (VCCV): A
Control Channel for Pseudowires", RFC 5085, December 2007.
[RFC5145] Shiomoto, K., Ed., "Framework for MPLS-TE to GMPLS
Migration", RFC 5145, March 2008.
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[RFC5493] Caviglia, D., Bramanti, D., Li, D., and D. McDysan,
"Requirements for the Conversion between Permanent
Connections and Switched Connections in a Generalized
Multiprotocol Label Switching (GMPLS) Network", RFC 5493,
April 2009.
[RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi-
Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
October 2009.
[RFC5787] Papadimitriou, D., "OSPFv2 Routing Protocols Extensions
for Automatically Switched Optical Network (ASON)
Routing", RFC 5787, March 2010.
[RFC5852] Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., and S.
Bardalai, "RSVP-TE Signaling Extension for LSP Handover
from the Management Plane to the Control Plane in a GMPLS-
Enabled Transport Network", RFC 5852, April 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., Ed., and C. Pignataro, Ed., "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.
[RFC5951] Lam, K., Mansfield, S., and E. Gray, "Network Management
Requirements for MPLS-based Transport Networks", RFC 5951,
September 2010.
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard,
D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol
Extensions for Multi-Layer and Multi-Region Networks
(MLN/MRN)", RFC 6001, October 2010.
[RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
[RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for
Dynamically Signaled Hierarchical Label Switched Paths",
RFC 6107, February 2011.
[RFC6215] Bocci, M., Levrau, L., and D. Frost, "MPLS Transport
Profile User-to-Network and Network-to-Network
Interfaces", RFC 6215, April 2011.
[TE-MIB] Miyazawa, M., Otani, T., Kumaki, K., and T. Nadeau,
"Traffic Engineering Database Management Information Base
in support of MPLS-TE/GMPLS", Work in Progress, July 2011.
[TP-MIB] King, D., Ed., and M. Venkatesan, Ed., "Multiprotocol
Label Switching Transport Profile (MPLS-TP) MIB-based
Management Overview", Work in Progress, August 2011.
[TP-P2MP-FWK]
Frost, D., Ed., Bocci, M., Ed., and L. Berger, Ed., "A
Framework for Point-to-Multipoint MPLS in Transport
Networks", Work in Progress, July 2011.
[TP-RING] Weingarten, Y., Ed., "MPLS-TP Ring Protection", Work in
Progress, June 20119. Contributing Authors 💖
and last but not least, the people who helped write this 🫶 Here are the contributing authors, exactly as listed:
Attila Takacs
Ericsson
1. Laborc u.
Budapest 1037
HUNGARY
EMail: attila.takacs@ericsson.com
Martin Vigoureux
Alcatel-Lucent
EMail: martin.vigoureux@alcatel-lucent.fr
Elisa Bellagamba
Ericsson
Farogatan, 6
164 40, Kista, Stockholm
SWEDEN
EMail: elisa.bellagamba@ericsson.comAuthors' Addresses 💌
okay bestie, these are the five editors who wrangled RFC 6373 into shape, and they're all getting their flowers 🌸 Here are their contact details, exactly as they appear in the original:
Loa Andersson (editor)
Ericsson
Phone: +46 10 717 52 13
EMail: loa.andersson@ericsson.com
Lou Berger (editor)
LabN Consulting, L.L.C.
Phone: +1-301-468-9228
EMail: lberger@labn.net
Luyuan Fang (editor)
Cisco Systems, Inc.
111 Wood Avenue South
Iselin, NJ 08830
USA
EMail: lufang@cisco.com
Nabil Bitar (editor)
Verizon
60 Sylvan Road
Waltham, MA 02451
USA
EMail: nabil.n.bitar@verizon.com
Eric Gray (editor)
Ericsson
900 Chelmsford Street
Lowell, MA 01851
USA
Phone: +1 978 275 7470
EMail: Eric.Gray@Ericsson.comthat's the whole crew 💖 🦋
📦 where this page comes from
- ietf: rfc6373 2011-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms