diff options
Diffstat (limited to 'doc/rfc/rfc6373.txt')
| -rw-r--r-- | doc/rfc/rfc6373.txt | 3195 |
1 files changed, 3195 insertions, 0 deletions
diff --git a/doc/rfc/rfc6373.txt b/doc/rfc/rfc6373.txt new file mode 100644 index 0000000..9ad93a5 --- /dev/null +++ b/doc/rfc/rfc6373.txt @@ -0,0 +1,3195 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Andersson, Ed. +Request for Comments: 6373 Ericsson +Category: Informational L. Berger, Ed. +ISSN: 2070-1721 LabN + L. Fang, Ed. + Cisco + N. Bitar, Ed. + Verizon + E. Gray, Ed. + Ericsson + September 2011 + + + MPLS Transport Profile (MPLS-TP) Control Plane Framework + +Abstract + + The MPLS Transport Profile (MPLS-TP) supports static provisioning of + transport paths via a Network Management System (NMS) and dynamic + provisioning of transport paths via a control plane. This document + provides the framework for MPLS-TP dynamic provisioning and covers + control-plane addressing, routing, path computation, signaling, + traffic engineering, and path recovery. MPLS-TP uses GMPLS as the + control plane for MPLS-TP Label Switched Paths (LSPs). MPLS-TP also + uses the pseudowire (PW) control plane for pseudowires. Management- + plane functions are out of scope of this document. + + This document is a product of a joint Internet Engineering Task Force + (IETF) / International Telecommunication Union Telecommunication + Standardization Sector (ITU-T) effort to include an MPLS Transport + Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge + (PWE3) architectures to support the capabilities and functionalities + of a packet transport network as defined by the ITU-T. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + + + + + +Andersson, et al. Informational [Page 1] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/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, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +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 + + + +Andersson, et al. Informational [Page 2] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 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 ...........................................56 + +1. Introduction + + The Multiprotocol Label Switching Transport Profile (MPLS-TP) is + defined as a joint effort between the International Telecommunication + Union (ITU) and the IETF. The requirements for MPLS-TP are defined + in the requirements document, see [RFC5654]. These requirements + state that "A solution MUST be defined to support dynamic + provisioning of MPLS-TP transport paths via a control plane". This + document provides the framework for such dynamic provisioning. This + document is a product of a joint Internet Engineering Task Force + (IETF) / International Telecommunication Union Telecommunication + Standardization Sector (ITU-T) effort to include an MPLS Transport + Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge + (PWE3) architectures to support the capabilities and functions of a + packet transport network as defined by the ITU-T. + + + + +Andersson, et al. Informational [Page 3] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + +1.1. Scope + + This document covers the control-plane functions involved in + establishing MPLS-TP Label Switched Paths (LSPs) and pseudowires + (PWs). The control-plane requirements for MPLS-TP are defined in the + MPLS-TP requirements document [RFC5654]. These requirements define + the role of the control plane in MPLS-TP. In particular, Section 2.4 + of [RFC5654] and portions of the remainder of Section 2 of [RFC5654] + provide specific control-plane requirements. + + The LSPs provided by MPLS-TP are used as a server layer for IP, MPLS, + and PWs, as well as other tunneled MPLS-TP LSPs. The 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 used 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. This 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 documents 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 remainder of this document discusses the impact of the MPLS-TP + requirements on the GMPLS signaling and routing protocols that are + used to control MPLS-TP LSPs, and on the control of PWs as specified + in [RFC4447], [RFC6073], and [MS-PW-DYNAMIC]. + +1.2. Basic Approach + + The basic approach taken in defining the MPLS-TP control-plane + framework includes the following: + + 1) MPLS technology as defined by the IETF is the foundation for + the MPLS Transport Profile. + + + +Andersson, et al. Informational [Page 4] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 2) The data plane for MPLS-TP is a standard MPLS data plane + [RFC3031] as profiled in [RFC5960]. + + 3) 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]. + + 4) 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]. + + 5) Existing IETF MPLS and GMPLS RFCs and evolving Working Group + Internet-Drafts should be reused wherever possible. + + 6) 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. + + 7) Extensions to the control plane may be required in order to + fully automate functions related to MPLS-TP LSPs and PWs. + + 8) Control-plane software upgrades to existing equipment are + acceptable and expected. + + 9) It is permissible for functions present in the GMPLS and PW + control planes to not be used in MPLS-TP networks. + + 10) 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. + + + + + +Andersson, et al. Informational [Page 5] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 11) 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. + + + + + + + + + + + + +Andersson, et al. Informational [Page 6] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + |< ---- 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.) + + + + + + + +Andersson, et al. Informational [Page 7] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + |< ------- 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. + + + +Andersson, et al. Informational [Page 8] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 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]: + + 1. 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]. + + 2. The MPLS-TP control-plane design should as far as reasonably + possible reuse existing MPLS standards ([RFC5654], requirement + 2). + + 3. The MPLS-TP control plane must be able to interoperate with + existing IETF MPLS and PWE3 control planes where appropriate + ([RFC5654], requirement 3). + + 4. 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). + + 5. 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). + + 6. The MPLS-TP control plane must support traffic-engineered + point-to-point (P2P) and point-to-multipoint (P2MP) transport + paths ([RFC5654], requirement 6). + + + + + +Andersson, et al. Informational [Page 9] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 7. The MPLS-TP control plane must support unidirectional, + associated bidirectional and co-routed bidirectional point-to- + point transport paths ([RFC5654], requirement 7). + + 8. The MPLS-TP control plane must support unidirectional point-to- + multipoint transport paths ([RFC5654], requirement 8). + + 9. The MPLS-TP control plane must enable all nodes (i.e., ingress, + egress, and intermediate) to be aware about the pairing + relationship of the forward and the backward directions + belonging to the same co-routed bidirectional transport path + ([RFC5654], requirement 10). + + 10. The MPLS-TP control plane must enable edge nodes (i.e., ingress + and egress) to be aware of the pairing relationship of the + forward and the backward directions belonging to the same + associated bidirectional transport path ([RFC5654], requirement + 11). + + 11. The MPLS-TP control plane should enable common transit nodes to + be aware of the pairing relationship of the forward and the + backward directions belonging to the same associated + bidirectional transport path ([RFC5654], requirement 12). + + 12. The MPLS-TP control plane must support bidirectional transport + paths with symmetric bandwidth requirements, i.e., the amount + of reserved bandwidth is the same in the forward and backward + directions ([RFC5654], requirement 13). + + 13. The MPLS-TP control plane must support bidirectional transport + paths with asymmetric bandwidth requirements, i.e., the amount + of reserved bandwidth differs in the forward and backward + directions ([RFC5654], requirement 14). + + 14. The MPLS-TP control plane must support the logical separation + of the control plane from the management and data planes + ([RFC5654], requirement 15). Note that this implies that the + addresses used in the control plane are independent from the + addresses used in the management and data planes. + + 15. The MPLS-TP control plane must support the physical separation + of the control plane from the management and data plane, and no + assumptions should be made about the state of the data-plane + channels from information about the control- or management- + plane channels when they are running out-of-band ([RFC5654], + requirement 16). + + + + + +Andersson, et al. Informational [Page 10] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 16. A control plane must be defined to support dynamic provisioning + and restoration of MPLS-TP transport paths, but its use is a + network operator's choice ([RFC5654], requirement 18). + + 17. The presence of a control plane must not be required for static + provisioning of MPLS-TP transport paths ([RFC5654], requirement + 19). + + 18. The MPLS-TP control plane must permit the coexistence of + statically and dynamically provisioned/managed MPLS-TP + transport paths within the same layer network or domain + ([RFC5654], requirement 20). + + 19. The MPLS-TP control plane should be operable in a way that is + similar to the way the control plane operates in other + transport-layer technologies ([RFC5654], requirement 21). + + 20. The MPLS-TP control plane must avoid or minimize traffic impact + (e.g., packet delay, reordering, and loss) during network + reconfiguration ([RFC5654], requirement 24). + + 21. The MPLS-TP control plane must work across multiple homogeneous + domains ([RFC5654], requirement 25), i.e., all domains use the + same MPLS-TP control plane. + + 22. The MPLS-TP control plane should work across multiple non- + homogeneous domains ([RFC5654], requirement 26), i.e., some + domains use the same control plane and other domains use static + provisioning at the domain boundary. + + 23. The MPLS-TP control plane must not dictate any particular + physical or logical topology ([RFC5654], requirement 27). + + 24. The MPLS-TP control plane must include support of ring + topologies that may be deployed with arbitrary interconnection + and support of rings of at least 16 nodes ([RFC5654], + requirements 27.A, 27.B, and 27.C). + + 25. The MPLS-TP control plane must scale gracefully to support a + large number of transport paths, nodes, and links. That is, it + must be able to scale at least as well as control planes in + existing transport technologies with growing and increasingly + complex network topologies as well as with increasing bandwidth + demands, number of customers, and number of services + ([RFC5654], requirements 53 and 28). + + 26. The MPLS-TP control plane should not provision transport paths + that contain forwarding loops ([RFC5654], requirement 29). + + + +Andersson, et al. Informational [Page 11] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 27. The MPLS-TP control plane must support multiple client layers + (e.g., MPLS-TP, IP, MPLS, Ethernet, ATM, Frame Relay, etc.) + ([RFC5654], requirement 30). + + 28. The MPLS-TP control plane must provide a generic and extensible + solution to support the transport of 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). + + 29. In an environment where an MPLS-TP layer network is supporting + a client-layer network, and the MPLS-TP layer network is + supported by a server-layer network, then 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). + + 30. The MPLS-TP control plane must allow for the transport of a + client MPLS or MPLS-TP layer network over a server MPLS or + MPLS-TP layer network ([RFC5654], requirement 33). + + 31. The MPLS-TP control plane must allow the autonomous operation + of the layers of a multi-layer network that includes an MPLS-TP + layer ([RFC5654], requirement 34). + + 32. The MPLS-TP control plane must allow the hiding of MPLS-TP + layer network addressing and other information (e.g., topology) + 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). + + 33. The MPLS-TP control plane must allow for the identification of + a transport path on each link within and at the destination + (egress) of the transport network ([RFC5654], requirements 38 + and 39). + + 34. The MPLS-TP control plane must allow for 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). + + 35. The MPLS-TP control plane must be extensible in order to + accommodate new types of client-layer networks and services + ([RFC5654], requirement 41). + + + +Andersson, et al. Informational [Page 12] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 36. The MPLS-TP control plane should support the reserved bandwidth + associated with a transport path to be increased without + impacting the existing traffic on that transport path, provided + enough resources are available ([RFC5654], requirement 42)). + + 37. The MPLS-TP control plane should support the reserved bandwidth + of a transport path being decreased without impacting the + existing traffic on that transport path, provided that the + level of existing traffic is smaller than the reserved + bandwidth following the decrease ([RFC5654], requirement 43). + + 38. The control plane for MPLS-TP must fit within the ASON + (control-plane) architecture. The ITU-T has 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]. + + 39. The MPLS-TP control plane must support control-plane topology + and data-plane topology independence ([RFC5654], requirement + 47). + + 40. A failure of the MPLS-TP control plane must not interfere with + the delivery of service or recovery of established transport + paths ([RFC5654], requirement 47). + + 41. The MPLS-TP control plane must be able to operate independent + of any particular client- or server-layer control plane + ([RFC5654], requirement 48). + + 42. The MPLS-TP control plane should support, but not require, an + integrated control plane encompassing MPLS-TP together with its + server- and client-layer networks when these layer networks + belong to the same administrative domain ([RFC5654], + requirement 49). + + 43. The MPLS-TP control plane must support configuration of + protection functions and any associated maintenance (OAM) + functions ([RFC5654], requirements 50 and 7). + + 44. The MPLS-TP control plane must support the configuration and + modification of OAM maintenance points as well as the + activation/deactivation of OAM when the transport path or + transport service is established or modified ([RFC5654], + requirement 51). + + + + + +Andersson, et al. Informational [Page 13] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 45. The MPLS-TP control plane must be capable of restarting and + relearning its previous state without impacting forwarding + ([RFC5654], requirement 54). + + 46. The MPLS-TP control plane must provide a mechanism for dynamic + ownership transfer of the 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. + + 47. 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. + + 48. 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). + + 49. 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). + + 50. The MPLS-TP control plane must support recovery mechanisms that + are applicable at various levels throughout the network + including support for link, transport path, segment, + concatenated segment, and end-to-end recovery ([RFC5654], + requirement 57). + + 51. 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. + + + +Andersson, et al. Informational [Page 14] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 52. The MPLS-TP control plane should support per-transport-path + recovery objectives ([RFC5654], requirement 59). + + 53. The MPLS-TP control plane must support recovery mechanisms that + are applicable to any topology ([RFC5654], requirement 60). + + 54. The MPLS-TP control plane must operate in synergy with + (including coordination of timing/timer settings) the recovery + mechanisms present in any client or server transport networks + (for example, Ethernet, SDH, OTN, Wavelength Division + Multiplexing (WDM)) to avoid race conditions between the layers + ([RFC5654], requirement 61). + + 55. The MPLS-TP control plane must support recovery and reversion + mechanisms that prevent frequent operation of recovery in the + event of an intermittent defect ([RFC5654], requirement 62). + + 56. The MPLS-TP control plane must support revertive and non- + revertive protection behavior ([RFC5654], requirement 64). + + 57. The MPLS-TP control plane must support 1+1 bidirectional + protection for P2P transport paths ([RFC5654], requirement 65 + A). + + 58. The MPLS-TP control plane must support 1+1 unidirectional + protection for P2P transport paths ([RFC5654], requirement 65 + B). + + 59. The MPLS-TP control plane must support 1+1 unidirectional + protection for P2MP transport paths ([RFC5654], requirement 65 + C). + + 60. The MPLS-TP control plane must support the ability to share + protection resources amongst a number of transport paths + ([RFC5654], requirement 66). + + 61. 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 ([RFC5654], + requirement 67 A). + + 62. The MPLS-TP control plane must support 1:n unidirectional + protection for P2MP transport paths ([RFC5654], requirement 67 + B). + + 63. The MPLS-TP control plane may support 1:n unidirectional + protection for P2P transport paths ([RFC5654], requirement 65 + C). + + + +Andersson, et al. Informational [Page 15] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 64. The MPLS-TP control plane may support the control of extra- + traffic type traffic ([RFC5654], note after requirement 67). + + 65. The MPLS-TP control plane should support 1:n (including 1:1) + shared mesh recovery ([RFC5654], requirement 68). + + 66. The MPLS-TP control plane must support sharing of protection + resources such that protection paths that are known not to be + required concurrently can share the same resources ([RFC5654], + requirement 69). + + 67. The MPLS-TP control plane must support the sharing of resources + between a restoration transport path and the transport path + being replaced ([RFC5654], requirement 70). + + 68. The MPLS-TP control plane must support restoration priority so + that an implementation can determine the order in which + transport paths should be restored ([RFC5654], requirement 71). + + 69. The MPLS-TP control plane must support preemption priority in + order to allow restoration to displace other transport paths in + the event of resource constraints ([RFC5654], requirements 72 + and 86). + + 70. The MPLS-TP control plane must support revertive and non- + revertive restoration behavior ([RFC5654], requirement 73). + + 71. The MPLS-TP control plane must support recovery being triggered + by physical (lower) layer fault indications ([RFC5654], + requirement 74). + + 72. The MPLS-TP control plane must support recovery being triggered + by OAM ([RFC5654], requirement 75). + + 73. The MPLS-TP control plane must support management-plane + recovery triggers (e.g., forced switch, etc.) ([RFC5654], + requirement 76). + + 74. The MPLS-TP control plane must support the differentiation of + administrative recovery actions from recovery actions initiated + by other triggers ([RFC5654], requirement 77). + + 75. The MPLS-TP control plane should support control-plane + restoration triggers (e.g., forced switch, etc.) ([RFC5654], + requirement 78). + + + + + + +Andersson, et al. Informational [Page 16] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 76. The MPLS-TP control plane must support priority logic to + negotiate and accommodate coexisting requests (i.e., multiple + requests) for protection switching (e.g., administrative + requests and requests due to link/node failures) ([RFC5654], + requirement 79). + + 77. The MPLS-TP control plane must support the association of + protection paths and working paths (sometimes known as + protection groups) ([RFC5654], requirement 80). + + 78. The MPLS-TP control plane must support pre-calculation of + recovery paths ([RFC5654], requirement 81). + + 79. The MPLS-TP control plane must support pre-provisioning of + recovery paths ([RFC5654], requirement 82). + + 80. The MPLS-TP control plane must support the external commands + defined in [RFC4427]. External controls overruled by higher + priority requests (e.g., administrative requests and requests + due to link/node failures) or unable to be signaled to the + remote end (e.g., because of a protection state coordination + fail) must be ignored/dropped ([RFC5654], requirement 83). + + 81. The MPLS-TP control plane must permit the testing and + validation of the integrity of the protection/recovery + transport path ([RFC5654], requirement 84 A). + + 82. The MPLS-TP control plane must permit the testing and + validation of protection/restoration mechanisms without + triggering the actual protection/restoration ([RFC5654], + requirement 84 B). + + 83. The MPLS-TP control plane must permit the testing and + validation of protection/restoration mechanisms while the + working path is in service ([RFC5654], requirement 84 C). + + 84. The MPLS-TP control plane must permit the testing and + validation of protection/restoration mechanisms while the + working path is out of service ([RFC5654], requirement 84 D). + + 85. The MPLS-TP control plane must support the establishment and + maintenance of all recovery entities and functions ([RFC5654], + requirement 89 A). + + 86. The MPLS-TP control plane must support signaling of recovery + administrative control ([RFC5654], requirement 89 B). + + + + + +Andersson, et al. Informational [Page 17] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 87. The MPLS-TP control plane must support protection state + coordination. Since control-plane network topology is + independent from the data-plane network topology, the + protection state coordination supported by the MPLS-TP control + plane may run on resources different than the data-plane + resources handled within the recovery mechanism (e.g., backup) + ([RFC5654], requirement 89 C). + + 88. 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 to enable + protection of end-to-end transport paths ([RFC5654], + requirement 91). + + 89. When present, the MPLS-TP control plane must support the + control of ring-topology-specific recovery mechanisms + ([RFC5654], Section 2.5.6.1). + + 90. 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). + + 91. The MPLS-TP control plane must support the 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). + + 92. The MPLS-TP control plane must support the 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]: + + 93. Per-packet Equal Cost Multi-Path (ECMP) load balancing is + currently outside the scope of MPLS-TP ([RFC5960], Section + 3.1.1, paragraph 6). + + 94. Penultimate Hop Popping (PHP) must be disabled on MPLS-TP LSPs + by default ([RFC5960], Section 3.1.1, paragraph 7). + + + + + + +Andersson, et al. Informational [Page 18] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 95. 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]. + + 96. 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). + + 97. The MPLS-TP control plane must support the control of PWs and + their associated labels ([RFC5921], Section 3.4.4). + + 98. 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 a client- + service-specific LSPs and labels ([RFC5921], Section 3.4.5). + + 99. 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). + + 100. The MPLS-TP control plane for PWs must be based on the MPLS + control plane for PWs, and more specifically, targeted LDP (T- + LDP) [RFC4447] is used for PW signaling ([RFC5921], Section + 3.9, paragraph 5). + + 101. 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). + + 102. The MPLS-TP control plane must support linear, ring, and meshed + protection schemes ([RFC5921], Section 3.12, paragraph 3). + + 103. The MPLS-TP control plane must support the control of SPMEs + (hierarchical LSPs) for new or existing end-to-end LSPs + ([RFC5921], Section 3.12, paragraph 7). + + + + + +Andersson, et al. Informational [Page 19] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + +2.3. Requirements Derived from the OAM Framework + + The following additional requirements are based on [RFC5860] and + [RFC6371]: + + 104. 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). + + 105. 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). + + 106. 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). + + 107. The MPLS-TP control plane must allow for the ability to support + experimental OAM functions. These functions must be disabled + by default ([RFC5860], Section 2.2, paragraph 2). + + 108. The MPLS-TP control plane must support the choice of which (if + any) OAM function(s) to use and to which PW, LSP or Section it + applies ([RFC5860], Section 2.2, paragraph 3). + + 109. The MPLS-TP control plane must allow (e.g., enable/disable) + mechanisms that support the localization of faults and the + notification of appropriate nodes ([RFC5860], Section 2.2.1, + paragraph 1). + + 110. The MPLS-TP control plane may support mechanisms that permit + the service provider to be informed of a fault or defect + affecting the service(s) it provides, even if the fault or + defect is located outside of his domain ([RFC5860], Section + 2.2.1, paragraph 2). + + 111. Information exchange between various nodes involved in the + MPLS-TP control plane should be reliable such that, for + example, defects or faults are properly detected or that state + changes are effectively known by the appropriate nodes + ([RFC5860], Section 2.2.1, paragraph 3). + + + + +Andersson, et al. Informational [Page 20] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 112. 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). + + 113. 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). + + 114. 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). + + 115. 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). + + 116. 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). + + + + + + + + +Andersson, et al. Informational [Page 21] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 117. 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). + + 118. 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). + + 119. 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). + + 120. 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). + + 121. 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). + + + + + +Andersson, et al. Informational [Page 22] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 122. 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). + + 123. 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). + + 124. 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. + + 125. 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). + + 126. 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. + + + +Andersson, et al. Informational [Page 23] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 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). + + 127. 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). + + 128. 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). + + 129. 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). + + 130. 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). + + 131. 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). + + 132. 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). + + + +Andersson, et al. Informational [Page 24] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 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). + + 133. 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). + + 134. The MPLS-TP control plane should provide mechanisms to control + the use of throughput estimation ([RFC6371], Section 6.3.1). + + 135. 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 + + The following are requirements based on [RFC6370]: + + 136. The MPLS-TP control plane must support MPLS-TP point-to-point + tunnel identifiers of the forms defined in Section 5.1 of + [RFC6370]. + + 137. 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]. + + 138. The MPLS-TP control plane must support pseudowire path + identifiers of the form defined in Section 6 of [RFC6370]. + + 139. The MPLS-TP control plane must support MEG_IDs for LSPs and PWs + as defined in Section 7.1.1 of [RFC6370]. + + 140. The MPLS-TP control plane must support IP-compatible MEG_IDs + for LSPs and PWs as defined in Section 7.1.2 of [RFC6370]. + + 141. The MPLS-TP control plane must support MEP_IDs for LSPs and PWs + of the forms defined in Section 7.2.1 of [RFC6370]. + + + +Andersson, et al. Informational [Page 25] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 142. 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]. + + 143. 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 + + The data-plane relationship between PWs and LSPs is inherited from + standard MPLS and is reviewed in the MPLS-TP framework [RFC5921]. + Likewise, the control-plane relationship between PWs and LSPs is + inherited from standard MPLS. This relationship is reviewed in this + document. The relationship between the PW and LSP control planes in + MPLS-TP is the same as the relationship found in the PWE3 Maintenance + Reference Model as presented in the PWE3 architecture; see Figure 6 + of [RFC3985]. The PWE3 architecture [RFC3985] states: "The PWE3 + protocol-layering model is intended to minimize the differences + between PWs operating over different PSN types". Additionally, PW + control (maintenance) takes place separately from LSP signaling. + [RFC4447] and [MS-PW-DYNAMIC] provide such extensions for the use of + LDP as the control plane for PWs. This control can provide PW + control without providing LSP control. + + In the context of MPLS-TP, LSP tunnel signaling is provided via GMPLS + RSVP-TE. While RSVP-TE could be extended to support PW control much + as LDP was extended in [RFC4447], such extensions are out of scope of + this document. This means that the control of PWs and LSPs will + operate largely independently. The main coordination between LSP and + PW control will occur within the nodes that terminate PWs or PW + segments. See Section 5.3.2 for an additional discussion on such + coordination. + + It is worth noting that the control planes for PWs and LSPs may be + used independently, and that one may be employed without the other. + This translates into four possible scenarios: (1) no control plane is + employed; (2) a control plane is used for both LSPs and PWs; (3) a + control plane is used for LSPs, but not PWs; (4) a control plane is + used for PWs, but not LSPs. + + The PW and LSP control planes, collectively, 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 operate in + combination, and some functions may be satisfied via the PW control + plane while others are provided to PWs by the LSP control plane. For + + + +Andersson, et al. Informational [Page 26] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + example, to support the recovery functions described in [RFC6372], + this document focuses on the control of the recovery functions at the + LSP layer. PW-based recovery is under development at this time and + may be used once defined. + +4. TE LSPs + + MPLS-TP uses Generalized MPLS (GMPLS) signaling and routing, see + [RFC3945], as the control plane for LSPs. The GMPLS control plane is + based on the MPLS control plane. GMPLS includes support for MPLS + labeled data and transport data planes. GMPLS includes most of the + transport-centric features required to support MPLS-TP LSPs. This + section will first review the features of GMPLS relevant to MPLS-TP + LSPs, then identify how specific requirements can be met using + existing GMPLS functions, and will conclude with extensions that are + anticipated 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. The terms "in- + band" and "out-of-band", in the context of this document, refer to + the relationship of the control plane relative to the management and + data planes. The terms may be used to refer to the control plane + independent of the management plane, or to both of them in concert. + The remainder of this section describes the relationship of the + control plane to the management and data planes. + + There are multiple uses of both terms "in-band" and "out-of-band". + The terms may relate to a channel, a path, or a network. Each of + these can be used independently or in combination. Briefly, some + typical usage of the terms is as follows: + + o In-band + This term is used to refer to cases where control-plane traffic is + sent in the same communication channel used to transport + 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 of this + case in the context of MPLS-TP is where control-plane traffic is + sent via the MPLS Generic Associated Channel (G-ACh), see + [RFC5586], using the same LSP as controlled user traffic. + + + + +Andersson, et al. Informational [Page 27] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + o Out-of-band, in-fiber (same physical connection) + This term is used to refer to cases where control-plane traffic is + sent using a different communication channel from the associated + data or management traffic, and the control communication channel + resides in the same fiber as either the management or data + traffic. An example of this case in the context of MPLS-TP is + where control-plane traffic is sent via the G-ACh using a + dedicated LSP on the same link (interface) that carries controlled + user traffic. + + o Out-of-band, aligned topology + This term is used to refer to the 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. + + Such 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 of this case in the context of MPLS-TP is where control- + plane traffic is sent along the same nodal path, but not + necessarily the same links (interfaces), as the corresponding + controlled user traffic. + + o Out-of-band, independent topology + This term is used to refer to the 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. + + Such configurations are a superset of the other cases and do not + preclude the use of in-fiber or aligned topology links, but + alignment is not required. An example of this case in the context + of MPLS-TP is where control-plane traffic is sent between + controlling nodes using any available path and links, completely + without regard for the path(s) taken by 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 by 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. + + + + + + +Andersson, et al. Informational [Page 28] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + +4.1.2. Addressing + + MPLS-TP reuses and supports the addressing mechanisms supported by + MPLS. The MPLS-TP identifiers document (see [RFC6370]) provides + additional context on how IP addresses are used within MPLS-TP. + MPLS, and consequently MPLS-TP, uses the IPv4 and IPv6 address + families to identify MPLS-TP nodes by default for network management + and signaling purposes. The address spaces and neighbor adjacencies + in the control, management, and data planes used in an MPLS-TP + network may be completely separated or combined at the discretion of + an MPLS-TP operator and based on the equipment capabilities of a + vendor. The separation of the control and management planes from the + data plane allows each plane to be independently addressable. Each + plane may use addresses that are not mutually reachable, e.g., it is + likely that the data plane will not be able to reach an address from + the management or control planes and vice versa. Each plane may also + use a different address family. It is even possible to reuse + addresses in each plane, but this is not recommended as it may lead + to operational confusion. As previously mentioned, 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 as there are other IS-IS and OSPF extensions, as 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, as well + as support for the other functions discussed in this section. + + Both MPLS and GMPLS path computation allow for the restriction of + path selection based on the use of Explicit Route Objects (EROs) and + other LSP attributes; see [RFC3209] and [RFC3473]. In all cases, no + + + +Andersson, et al. Informational [Page 29] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 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 consequently an + MPLS-TP LSP, across domains and in a single domain. In cases where + 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 of the + MPLS-TP project and this document. + +4.1.5. Signaling + + GMPLS signaling is defined in [RFC3471] and [RFC3473] and is based on + RSVP-TE [RFC3209]. Constraint-based Routed LDP (CR-LDP) GMPLS (see + [RFC3472]) is no longer under active development within the IETF, + i.e., it is deprecated (see [RFC3468]) and must not be used for MPLS + nor MPLS-TP consequently. In general, all RSVP-TE extensions that + apply to MPLS may also be used for GMPLS and consequently MPLS-TP. + Most notably, this includes support for P2MP signaling as defined in + [RFC4875]. + + GMPLS signaling includes a number of MPLS-TP required functions -- + notably, support for out-of-band control, bidirectional LSPs, and + independent control- and data-plane fault management. There are also + numerous other GMPLS and MPLS extensions that can be used to provide + specific functions in MPLS-TP networks. Specific references are + provided below. + +4.1.6. Unnumbered Links + + Support for unnumbered links (i.e., links that do not have IP + addresses) is permitted in MPLS-TP and its usage is at the discretion + of the network operator. Support for unnumbered links is included + for routing using OSPF [RFC4203] and IS-IS [RFC5307], and for + signaling in [RFC3477]. + +4.1.7. Link Bundling + + Link bundling provides a local construct that can be used to improve + scaling of TE routing when multiple data links are shared between + node pairs. Link bundling for MPLS and GMPLS networks is defined in + [RFC4201]. Link bundling may be used in MPLS-TP networks, and its + use is at the discretion of the network operator. + + + + + +Andersson, et al. Informational [Page 30] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + +4.1.8. Hierarchical LSPs + + This section reuses text from [RFC6107]. + + [RFC3031] describes how MPLS labels may be stacked so that LSPs may + 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 the establishment of 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] allow a hierarchical LSP to + be treated as a single hop in the path of another LSP. This + mechanism 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]. + + Thus, a hierarchical LSP may form an FA such that it is advertised as + a TE link in the same instance of the routing protocol as was used to + advertise the TE links that 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 for end-to-end GMPLS LSPs + recovery in [RFC4872] and segment recovery in [RFC4873]. GMPLS + segment recovery provides a superset of the function in end-to-end + recovery. 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. + + + + +Andersson, et al. Informational [Page 31] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + The five defined types of recovery defined 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) + + The majority of 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 + + + +Andersson, et al. Informational [Page 32] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + same control-plane signaling used to set up the LSP, as 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 + 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 + + + +Andersson, et al. Informational [Page 33] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + 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 + + The following table shows how the MPLS-TP control-plane requirements + can be met using the existing GMPLS control plane (which builds on + the MPLS control plane). Areas where additional specifications are + required are also identified. The table lists references based on + the control-plane requirements as identified and numbered above in + Section 2. + + +=======+===========================================================+ + | 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] | + + + +Andersson, et al. Informational [Page 34] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + | 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) | + + + +Andersson, et al. Informational [Page 35] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + | 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] | + + + +Andersson, et al. Informational [Page 36] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + | 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 Table + +4.4. Anticipated MPLS-TP-Related Extensions and Definitions + + This section identifies the extensions and other documents that have + been identified as 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 + + While no interworking function is expected in the data plane to + support the interconnection of MPLS-TE and MPLS-TP networking, this + is not the case for the control plane. MPLS-TE networks typically + use LSP signaling based on [RFC3209], while MPLS-TP LSPs will be + signaled using GMPLS RSVP-TE, i.e., [RFC3473]. [RFC5145] identifies + a set of solutions that are aimed to aid in the interworking of MPLS- + TE and GMPLS control planes. [RFC5145] work will serve as the + foundation for a formal definition of MPLS to MPLS-TP control-plane + interworking. + + + + + + + +Andersson, et al. Informational [Page 37] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + +4.4.2. Associated Bidirectional LSPs + + GMPLS signaling, [RFC3473], supports unidirectional and co-routed, + bidirectional point-to-point LSPs. MPLS-TP also requires support for + associated bidirectional point-to-point LSPs. Such support will + require an extension or a formal definition of how the LSP end points + supporting an associated bidirectional service will coordinate the + two LSPs used to provide such a service. Per requirement 11, transit + nodes that support an associated bidirectional service should be + aware of the association of the LSPs used to support the service when + both LSPs are supported on that transit node. There are several + existing protocol mechanisms on which to base such support, + including, but not limited to: + + o GMPLS calls [RFC4974]. + + o The ASSOCIATION object [RFC4872]. + + o The LSP_TUNNEL_INTERFACE_ID object [RFC6107]. + +4.4.3. Asymmetric Bandwidth LSPs + + [RFC5467] defines support for bidirectional LSPs that have different + (asymmetric) bandwidth requirements for each direction. That RFC can + be used to meet the related MPLS-TP technical requirement, but it is + 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 definitions of P2MP, [RFC4875], and GMPLS recovery, [RFC4872] and + [RFC4873], do not explicitly cover their interactions. MPLS-TP + requires a formal definition of recovery techniques for P2MP LSPs. + Such a formal definition will be based on existing RFCs and may not + require any new protocol mechanisms but, nonetheless, 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. These extensions cover a portion of, + but not all, OAM-related control functions that have been identified + in the context of MPLS-TP. As discussed above, the MPLS-TP control + plane must support the selection of which OAM function(s) (if any) to + use (including support to select experimental OAM functions) and what + OAM functionality to run, including Continuity Check (CC), + + + + + +Andersson, et al. Informational [Page 38] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + Connectivity Verification (CV), packet loss, delay quantification, + and diagnostic testing of a service. Such 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. While [RFC4124] references GMPLS signaling, there is no + explicit discussion on the use of the Diffserv-related objects in + GMPLS signaling. A (possibly Informational) document on how GMPLS + supports Diffserv LSPs is likely to prove useful in the context of + 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 form 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, + and such 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. Both node-unique and global forms are defined. + Extensions will be required to GMPLS to support these identifiers. + These extensions may be added to existing works in progress, such as + [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT], or may be defined in independent + documents. + +5. Pseudowires + +5.1. LDP Functions and Pseudowires + + MPLS PWs are defined in [RFC3985] and [RFC5659], and provide for + emulated services over an MPLS Packet Switched Network (PSN). + Several types of PWs have been defined: (1) Ethernet PWs providing + for Ethernet port or Ethernet VLAN transport over MPLS [RFC4448], (2) + High-Level Data Link Control (HDLC) / PPP PW providing for 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 provide transport for PDH or SONET (e.g., + ATM over SONET or Packet PPP over SONET) client signals with no + payload awareness. Implementing PW capability allows for the use of + an existing technology to substitute the Time-Division Multiplexing + + + +Andersson, et al. Informational [Page 39] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + (TDM) transport with packet-based transport, using well-defined PW + encapsulation methods for carrying various packet services over MPLS, + and providing for potentially better bandwidth utilization. + + 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. Alternatively, an + MPLS-TP edge node may be the Terminating PE (T-PE) for a PW, + performing adaptation from the native attachment circuit technology + (e.g., Ethernet 802.1Q) to an MPLS PW that is then transported in an + LSP over an MPLS-TP network. In this way, the PW is analogous to a + transport channel in a TDM network, and the LSP is equivalent to a + container of multiple non-concatenated channels, albeit they are + packet containers. An MPLS-TP network may also contain Switching PEs + (S-PEs) for a Multi-Segment PW whereby the T-PEs may be at the edge + of an MPLS-TP network or in a client network. In the latter case, a + T-PE in a client network performs the adaptation of the native + service to MPLS and the MPLS-TP network performs 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 will leverage existing technology as well as facilitate + interoperability with client networks with native attachment circuits + or PW segments that are switched across an MPLS-TP network. + +5.1.1. Management-Plane Support + + There is no MPLS-TP requirement 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 + + The following table shows how the MPLS-TP control-plane requirements + can be met using the existing LDP control plane for pseudowires + (targeted LDP). Areas where additional specifications are required + are also identified. The table lists references based on the + control-plane requirements as identified and numbered above in + Section 2. + + + + + +Andersson, et al. Informational [Page 40] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + In the table below, several of the requirements shown are addressed + -- in part or in full -- by the use of MPLS-TP LSPs to carry + pseudowires. This is reflected by including "TP-LSPs" as a reference + for those requirements. Section 5.3.2 provides additional context + for the binding of PWs to TP-LSPs. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Andersson, et al. Informational [Page 41] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + +=======+===========================================================+ + | 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] | + + + +Andersson, et al. Informational [Page 42] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + | 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 Table + + + + + + +Andersson, et al. Informational [Page 43] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + +5.3. Anticipated MPLS-TP-Related Extensions + + Existing control protocol and procedures will be reused as much as + possible to support MPLS-TP. However, when using PWs in MPLS-TP, a + set of new requirements is defined that may require extensions of the + existing control mechanisms. This section clarifies the areas where + extensions are needed based on the requirements that are related to + the PW control plane and documented in [RFC5654]. + + Table 2 lists how requirements defined in [RFC5654] are expected to + be addressed. + + The baseline requirement for extensions to support transport + applications is that any new mechanisms and capabilities must be able + to interoperate with existing IETF MPLS [RFC3031] and IETF PWE3 + [RFC3985] control and data planes where appropriate. Hence, + extensions of the PW control plane must be in-line with the + procedures defined in [RFC4447], [RFC6073], and [MS-PW-DYNAMIC]. + +5.3.1. Extensions to Support Out-of-Band PW Control + + For MPLS-TP, it is required that the data and control planes can be + both logically and physically separated. That is, the PW control + plane must be able to operate out-of-band (OOB). This separation + ensures, among other things, that in the case of control-plane + failures the data plane is not affected and can continue to operate + normally. This was not a design requirement for the current PW + control plane. However, due to the PW concept, i.e., PWs are + connecting logical entities ('forwarders'), and the operation of the + PW control protocol, i.e., only edge PE nodes (T-PE, S-PE) take part + in the signaling exchanges: moving T-LDP out-of-band seems to be, + theoretically, a straightforward exercise. + + In fact, as a strictly local matter, ensuring that targeted LDP + (T-LDP) uses out-of-band signaling requires only that the local + implementation is configured in such a way that reachability for a + target LSR address is via the out-of-band channel. + + More precisely, if IP addressing is used in the MPLS-TP control + plane, then T-LDP addressing can be maintained, although all + addresses will 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. + + + + + + +Andersson, et al. Informational [Page 44] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + +5.3.2. Support for Explicit Control of PW-to-LSP Binding + + Binding a PW to an LSP, or PW segments to LSPs, is left to nodes + acting as T-PEs and S-PEs or a control-plane entity that may be the + same one signaling the PW. However, an extension of the PW signaling + protocol is required to allow the LSR at the signal initiation end to + inform the targeted LSR (at the signal termination end) to which LSP + the resulting PW is to be bound, in the event that more than one such + LSP exists and the choice of LSPs is important to the service being + setup (for example, if the service requires co-routed bidirectional + paths). This is also particularly important to support transport + path (symmetric and asymmetric) bandwidth requirements. + + For transport services, MPLS-TP requires support for bidirectional + traffic that follows congruent paths. Currently, each direction of a + PW or a PW segment is bound to a unidirectional LSP that extends + between two T-PEs, two S-PEs, or a T-PE and an S-PE. The + unidirectional LSPs in both directions are not required to follow + congruent paths, and therefore both directions of a PW may not follow + congruent paths, i.e., they are associated bidirectional paths. The + only requirement in [RFC5659] is that a PW or a PW segment shares the + same T-PEs in both directions and the same S-PEs in both directions. + + MPLS-TP imposes new requirements on the PW control plane, in + requiring that both end points map the PW or PW segment to the same + transport path for the case where this is an objective of the + service. When a bidirectional LSP is selected on one end to + transport the PW, a mechanism is needed that signals to the remote + end which LSP has been selected locally to transport the PW. This + would be accomplished by adding a new TLV to PW signaling. + + Note that this coincides with the gap identified for OOB support: a + new mechanism is needed to allow explicit binding of a PW to the + supporting transport LSP. + + The case of unidirectional transport paths may also require + additional protocol mechanisms, as today's PWs are always + bidirectional. One potential approach for providing a unidirectional + PW-based transport path is for the PW to associate different + (asymmetric) bandwidths in each direction, with a zero or minimal + bandwidth for the return path. This approach is consistent with + Section 3.8.2 of [RFC5921] but does not address P2MP paths. + +5.3.3. Support for Dynamic Transfer of PW Control/Ownership + + In order to satisfy requirement 47 (as defined in Section 2), it will + be necessary to specify methods for transfer of PW ownership from the + management to the control plane (and vice versa). + + + +Andersson, et al. Informational [Page 45] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + +5.3.4. Interoperable Support for PW/LSP Resource Allocation + + Transport applications may require resource guarantees. For such + transport LSPs, resource reservation mechanisms are provided via + RSVP-TE and the use of Diffserv. If multiple PWs are multiplexed + into the same transport LSP resources, contention may occur. + However, local policy at PEs should ensure proper resource sharing + among PWs mapped into a resource-guaranteed LSP. In the case of + MS-PWs, signaling carries the PW traffic parameters [MS-PW-DYNAMIC] + to enable admission control of a PW segment over a resource- + guaranteed LSP. + + In conjunction with explicit PW-to-LSP binding, existing mechanisms + may be sufficient; however, this needs to be verified in detailed + evaluation. + +5.3.5. Support for PW Protection and PW OAM Configuration + + Many of the requirements listed in Section 2 are intended to support + connectivity and performance monitoring (grouped together as OAM), as + well as protection conformant with the transport services model. + + In general, protection of MPLS-TP transported services is provided by + way of protection of transport LSPs. PW protection requires that + mechanisms be defined to support redundant pseudowires, including a + mechanism already described above for associating such pseudowires + with specific protected ("working" and "protection") LSPs. Also + required are definitions of local protection control functions, to + include test/verification operations, and protection status signals + needed to ensure that PW termination points are in agreement as to + which of a set of redundant pseudowires are in use for which + transport services at any given point in time. + + Much of this work is currently being done in documents [PW-RED] and + [PW-REDB] that define, respectively, how to establish redundant + pseudowires and how to indicate which is in use. Additional work may + be required. + + Protection switching may be triggered manually by the operator, or as + a result of loss of connectivity (detected using the mechanisms of + [RFC5085] and [RFC5586]), or service degradation (detected using + mechanisms yet to be defined). + + Automated protection switching is just one of the functions for which + a transport service requires OAM. OAM is generally referred to as + either "proactive" or "on-demand", where the distinction is whether a + specific OAM tool is being used continuously over time (for the + purpose of detecting a need for protection switching, for example) or + + + +Andersson, et al. Informational [Page 46] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + is only used -- either a limited number of times or over a short + period of time -- when explicitly enabled (for diagnostics, for + example). + + PW OAM currently consists of connectivity verification defined by + [RFC5085]. Work is currently in progress to extend PW OAM to include + bidirectional forwarding detection (BFD) in [RFC5885], and work has + begun on extending BFD to include performance-related monitor + functions. + +5.3.6. Client-Layer and Cross-Provider Interfaces to PW Control + + Additional work is likely to be required to define consistent access + by a client-layer network, as well as between provider networks, to + control information available to each type of network, for example, + about the topology of an MS-PW. This information may be required by + the client-layer network in order to provide hints that may help to + avoid establishment of fate-sharing alternate paths. Such work will + need to fit within the ASON architecture; see requirement 38 above. + +5.4. ASON Architecture Considerations + + MPLS-TP PWs are always transported using LSPs, and these LSPs will + either have been 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 discussed above in Section 5.3, there are anticipated extensions + in the following areas that may be related to 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 be consistent with ASON architecture and may + require additional specification in order to achieve this goal. + +6. Security Considerations + + This document primarily describes how existing mechanisms can be used + to meet the MPLS-TP control-plane requirements. The documents that + describe each mechanism contain their own security considerations + sections. For a general discussion on MPLS- and GMPLS-related + + + + + +Andersson, et al. Informational [Page 47] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + security issues, see the MPLS/GMPLS security framework [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 needed control-plane + extensions. It is expected that the documents that define such + extensions will also include any appropriate security considerations. + +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 in his help responding + to Last Call comments. + +8. References + +8.1. Normative References + + [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. + + + +Andersson, et al. Informational [Page 48] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + [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. + + + + +Andersson, et al. Informational [Page 49] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + [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. + + + +Andersson, et al. Informational [Page 50] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + [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 + + [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. + + + + +Andersson, et al. Informational [Page 51] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + [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. + + + + +Andersson, et al. Informational [Page 52] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + [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. + + + + + +Andersson, et al. Informational [Page 53] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + [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. + + + + + + +Andersson, et al. Informational [Page 54] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + [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. + + + +Andersson, et al. Informational [Page 55] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + [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 2011 + +9. Contributing Authors + + Attila Takacs + Ericsson + 1. Laborc u. + Budapest 1037 + HUNGARY + EMail: attila.takacs@ericsson.com + + Martin Vigoureux + Alcatel-Lucent + EMail: martin.vigoureux@alcatel-lucent.fr + + + +Andersson, et al. Informational [Page 56] + +RFC 6373 MPLS-TP Control Plane Framework September 2011 + + + Elisa Bellagamba + Ericsson + Farogatan, 6 + 164 40, Kista, Stockholm + SWEDEN + EMail: elisa.bellagamba@ericsson.com + +Authors' Addresses + + 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.com + + + + + + + + + + + +Andersson, et al. Informational [Page 57] + |