RFC 6373: - The RFC Archive

RFC Home	Full RFC Index	Recent RFCs	RFC Standards	Best Current Practice	RFC Errata	1 April RFC

IETF RFC 6373

Last modified on Wednesday, September 21st, 2011

Permanent link to RFC 6373

Search GitHub Wiki for RFC 6373

Show other RFCs mentioning RFC 6373 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/RFC 6373. 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 [RFC 5654]. 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 [RFC 5654]. These requirements define the role of the control plane in MPLS-TP. In particular, Section 2.4 of [RFC 5654] and portions of the remainder of Section 2 of [RFC 5654] 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 [RFC 5654] and [RFC 4427]. 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 [RFC 5921], and a survivability framework for MPLS-TP has been defined in [RFC 6372]. These documents scope the approaches and protocols that are the foundation of MPLS-TP. Notably, Section 3.5 of [RFC 5921] 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 [RFC 4447]) and the PWE3 architecture (see [RFC 3985]). The LSP control plane is based on GMPLS (see [RFC 3945]), which is built on MPLS Traffic Engineering (TE) and its numerous extensions. [RFC 6372] 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 [RFC 4447], [RFC 6073], 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 [RFC 3031] as profiled in [RFC 5960]. 3) MPLS PWs are used by MPLS-TP including the use of targeted Label Distribution Protocol (LDP) as the foundation for PW signaling [RFC 4447]. 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 [RFC 3985]. 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) [RFC 3473], OSPF-TE [RFC 4203] [RFC 5392], and ISIS-TE [RFC 5307] [RFC 5316]. Automatically Switched Optical Network (ASON) signaling and routing requirements in the context of GMPLS can be found in [RFC 4139] and [RFC 4258]. 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 [RFC 5654] and relevant portions of the remainder of Section 2 of [RFC 5654]. 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 [RFC 5921] and further refined in [RFC 6215] on the MPLS-TP User-to-Network and Network-to-Network Interfaces (UNI and NNI, respectively). Per the MPLS-TP framework [RFC 5921], 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 [RFC 5036]. Use of the extended discovery mechanism is specified in Section 5 ("LDP") of [RFC 4447]. 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 [RFC 4448]. 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 [RFC 4208], or statically provisioned. As discussed in [RFC 5921] and [RFC 6215], 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 [RFC 6371], within each provider domain and across the inter-provider NNI. (H-LSPs are used to implement Sub-Path Maintenance Elements (SPMEs) as defined in [RFC 5921].) The MEPs are used to collect performance information, support diagnostic and fault management functions, and support OAM triggered survivability schemes as discussed in [RFC 6372]. Each H-LSP may be protected or restored using any of the schemes discussed in [RFC 6372]. 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 [RFC 5654], [RFC 5921], [RFC 5860], [RFC 6371], and [RFC 6372]. 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 [RFC 5654]: 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 [RFC 4929] and Section 1, paragraph 15 of [RFC 5654]. 2. The MPLS-TP control-plane design should as far as reasonably possible reuse existing MPLS standards ([RFC 5654], requirement 2). 3. The MPLS-TP control plane must be able to interoperate with existing IETF MPLS and PWE3 control planes where appropriate ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], requirement 5). 6. The MPLS-TP control plane must support traffic-engineered point-to-point (P2P) and point-to-multipoint (P2MP) transport paths ([RFC 5654], 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 ([RFC 5654], requirement 7). 8. The MPLS-TP control plane must support unidirectional point-to- multipoint transport paths ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], requirement 14). 14. The MPLS-TP control plane must support the logical separation of the control plane from the management and data planes ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], requirement 18). 17. The presence of a control plane must not be required for static provisioning of MPLS-TP transport paths ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], requirement 21). 20. The MPLS-TP control plane must avoid or minimize traffic impact (e.g., packet delay, reordering, and loss) during network reconfiguration ([RFC 5654], requirement 24). 21. The MPLS-TP control plane must work across multiple homogeneous domains ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], requirements 53 and 28). 26. The MPLS-TP control plane should not provision transport paths that contain forwarding loops ([RFC 5654], 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.) ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], requirement 40). 35. The MPLS-TP control plane must be extensible in order to accommodate new types of client-layer networks and services ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], 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 [RFC 4139], [RFC 4258], and Section 2.4, paragraphs 2 and 3 of [RFC 5654]. 39. The MPLS-TP control plane must support control-plane topology and data-plane topology independence ([RFC 5654], 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 ([RFC 5654], requirement 47). 41. The MPLS-TP control plane must be able to operate independent of any particular client- or server-layer control plane ([RFC 5654], 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 ([RFC 5654], requirement 49). 43. The MPLS-TP control plane must support configuration of protection functions and any associated maintenance (OAM) functions ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], requirement 52). Note that the MPLS-TP survivability framework document [RFC 6372] 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 ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], requirement 57). 51. The MPLS-TP control plane must support recovery paths that meet the Service Level Agreement (SLA) protection objectives of the service ([RFC 5654], 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 ([RFC 5654], requirement 59). 53. The MPLS-TP control plane must support recovery mechanisms that are applicable to any topology ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], requirement 62). 56. The MPLS-TP control plane must support revertive and non- revertive protection behavior ([RFC 5654], requirement 64). 57. The MPLS-TP control plane must support 1+1 bidirectional protection for P2P transport paths ([RFC 5654], requirement 65 A). 58. The MPLS-TP control plane must support 1+1 unidirectional protection for P2P transport paths ([RFC 5654], requirement 65 B). 59. The MPLS-TP control plane must support 1+1 unidirectional protection for P2MP transport paths ([RFC 5654], requirement 65 C). 60. The MPLS-TP control plane must support the ability to share protection resources amongst a number of transport paths ([RFC 5654], 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 ([RFC 5654], requirement 67 A). 62. The MPLS-TP control plane must support 1:n unidirectional protection for P2MP transport paths ([RFC 5654], requirement 67 B). 63. The MPLS-TP control plane may support 1:n unidirectional protection for P2P transport paths ([RFC 5654], 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 ([RFC 5654], note after requirement 67). 65. The MPLS-TP control plane should support 1:n (including 1:1) shared mesh recovery ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], requirements 72 and 86). 70. The MPLS-TP control plane must support revertive and non- revertive restoration behavior ([RFC 5654], requirement 73). 71. The MPLS-TP control plane must support recovery being triggered by physical (lower) layer fault indications ([RFC 5654], requirement 74). 72. The MPLS-TP control plane must support recovery being triggered by OAM ([RFC 5654], requirement 75). 73. The MPLS-TP control plane must support management-plane recovery triggers (e.g., forced switch, etc.) ([RFC 5654], requirement 76). 74. The MPLS-TP control plane must support the differentiation of administrative recovery actions from recovery actions initiated by other triggers ([RFC 5654], requirement 77). 75. The MPLS-TP control plane should support control-plane restoration triggers (e.g., forced switch, etc.) ([RFC 5654], 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) ([RFC 5654], requirement 79). 77. The MPLS-TP control plane must support the association of protection paths and working paths (sometimes known as protection groups) ([RFC 5654], requirement 80). 78. The MPLS-TP control plane must support pre-calculation of recovery paths ([RFC 5654], requirement 81). 79. The MPLS-TP control plane must support pre-provisioning of recovery paths ([RFC 5654], requirement 82). 80. The MPLS-TP control plane must support the external commands defined in [RFC 4427]. 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 ([RFC 5654], requirement 83). 81. The MPLS-TP control plane must permit the testing and validation of the integrity of the protection/recovery transport path ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 5654], requirement 84 D). 85. The MPLS-TP control plane must support the establishment and maintenance of all recovery entities and functions ([RFC 5654], requirement 89 A). 86. The MPLS-TP control plane must support signaling of recovery administrative control ([RFC 5654], 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) ([RFC 5654], 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 ([RFC 5654], requirement 91). 89. When present, the MPLS-TP control plane must support the control of ring-topology-specific recovery mechanisms ([RFC 5654], 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 ([RFC 5654], 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 ([RFC 3209] style) and relative ([RFC 3270] style) end-to-end bandwidth guarantees ([RFC 5654], requirement 111). 92. The MPLS-TP control plane must support the provisioning of services that are sensitive to jitter and delay ([RFC 5654], requirement 112). 2.2. Requirements Derived from the MPLS-TP Framework The following additional requirements are based on [RFC 5921], [TP-P2MP-FWK], and [RFC 5960]: 93. Per-packet Equal Cost Multi-Path (ECMP) load balancing is currently outside the scope of MPLS-TP ([RFC 5960], Section 3.1.1, paragraph 6). 94. Penultimate Hop Popping (PHP) must be disabled on MPLS-TP LSPs by default ([RFC 5960], 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 [RFC 3270], [RFC 5462], and Section 3.3.2, paragraph 12 of [RFC 5960]. 96. Both Single-Segment PWs (see [RFC 3985]) and Multi-Segment PWs (see [RFC 5659]) shall be supported by the MPLS-TP control plane. MPLS-TP shall use the definition of Multi-Segment PWs as defined by the IETF ([RFC 5921], Section 3.4.4). 97. The MPLS-TP control plane must support the control of PWs and their associated labels ([RFC 5921], 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 ([RFC 5921], Section 3.4.5). a. The MPLS-TP control plane must support the use of network- layer protocol-specific LSPs and labels ([RFC 5921], Section 3.4.5). b. The MPLS-TP control plane must support the use of a client- service-specific LSPs and labels ([RFC 5921], 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 [RFC 3473] and related extensions are used for LSP signaling, and GMPLS OSPF- TE [RFC 5392] and ISIS-TE [RFC 5316] are used for routing ([RFC 5921], 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) [RFC 4447] is used for PW signaling ([RFC 5921], 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 ([RFC 5921], Section 3.9, paragraph 16). 102. The MPLS-TP control plane must support linear, ring, and meshed protection schemes ([RFC 5921], 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 ([RFC 5921], 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 [RFC 5860] and [RFC 6371]: 104. The MPLS-TP control plane must support the capability to enable/disable OAM functions as part of service establishment ([RFC 5860], 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) ([RFC 5860], 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 ([RFC 5860], 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 [RFC 4379], MPLS-BFD [RFC 5884], VCCV [RFC 5085], and VCCV-BFD [RFC 5885] ([RFC 5860], 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 ([RFC 5860], 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 ([RFC 5860], 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 ([RFC 5860], 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 ([RFC 5860], 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 ([RFC 5860], 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 ([RFC 5860], 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 ([RFC 5860], 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 ([RFC 5860], 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 ([RFC 5860], 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 ([RFC 5860], Section 2.2.5, paragraph 1). a. The MPLS-TP control plane must provide mechanisms to control the performance of this function on-demand ([RFC 5860], 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 ([RFC 5860], Section 2.2.4, paragraph 1). a. The MPLS-TP control plane must provide mechanisms to control the performance of this function on-demand ([RFC 5860], 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 ([RFC 5860], Section 2.2.6, paragraph 1). a. The MPLS-TP control plane must provide mechanisms to control the performance of this function on-demand ([RFC 5860], 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 ([RFC 5860], Section 2.2.7, paragraph 1). a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively ([RFC 5860], 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 ([RFC 5860], Section 2.2.8, paragraph 1). a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively ([RFC 5860], 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 ([RFC 5860], Section 2.2.9, paragraph 1). a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively ([RFC 5860], 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 ([RFC 5860], Section 2.2.10, paragraph 1). a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively ([RFC 5860], 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 ([RFC 5860], 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 ([RFC 5860], 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 ([RFC 5860], 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 ([RFC 5860], 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 ([RFC 6371], Section 3.6). 124. For dynamically established transport paths, the control plane must support the configuration of OAM operations ([RFC 6371], 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 ([RFC 6371], 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 ([RFC 6371], 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 ([RFC 6371], 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 ([RFC 6371], 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 ([RFC 6371], 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 ([RFC 6371], 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 ([RFC 6371], Section 5.7.1, paragraph 1). 132. The MPLS-TP control plane should provide mechanisms to control the use of on-demand CV packets ([RFC 6371], 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 ([RFC 6371], 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 ([RFC 6371], 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 ([RFC 6371], 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 ([RFC 6371], Section 6.2.1). 134. The MPLS-TP control plane should provide mechanisms to control the use of throughput estimation ([RFC 6371], 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 ([RFC 6371], 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 [RFC 5920], and that document applies equally to MPLS-TP. 2.5. Identifier Requirements The following are requirements based on [RFC 6370]: 136. The MPLS-TP control plane must support MPLS-TP point-to-point tunnel identifiers of the forms defined in Section 5.1 of [RFC 6370]. 137. The MPLS-TP control plane must support MPLS-TP LSP identifiers of the forms defined in Section 5.2 of [RFC 6370], and the mappings to GMPLS as defined in Section 5.3 of [RFC 6370]. 138. The MPLS-TP control plane must support pseudowire path identifiers of the form defined in Section 6 of [RFC 6370]. 139. The MPLS-TP control plane must support MEG_IDs for LSPs and PWs as defined in Section 7.1.1 of [RFC 6370]. 140. The MPLS-TP control plane must support IP-compatible MEG_IDs for LSPs and PWs as defined in Section 7.1.2 of [RFC 6370]. 141. The MPLS-TP control plane must support MEP_IDs for LSPs and PWs of the forms defined in Section 7.2.1 of [RFC 6370]. 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 [RFC 6370]. 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 [RFC 6370]. 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 [RFC 5921]. 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 [RFC 3985]. The PWE3 architecture [RFC 3985] 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. [RFC 4447] 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 [RFC 4447], 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 [RFC 6372], 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 [RFC 3945], 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 [RFC 5586], 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 [RFC 6370]) 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 [RFC 5586] 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 [RFC 3945] and [RFC 4202] as well as multiple levels of packet switching within a single network. IS- IS extensions for GMPLS are defined in [RFC 5307] and [RFC 5316], which build on the TE extensions to IS-IS defined in [RFC 5305]. OSPF extensions for GMPLS are defined in [RFC 4203] and [RFC 5392], which build on the TE extensions to OSPF defined in [RFC 3630]. 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 [RFC 3209] and [RFC 3473]. 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 [RFC 4655], 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 [RFC 5440], 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 [RFC 3471] and [RFC 3473] and is based on RSVP-TE [RFC 3209]. Constraint-based Routed LDP (CR-LDP) GMPLS (see [RFC 3472]) is no longer under active development within the IETF, i.e., it is deprecated (see [RFC 3468]) 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 [RFC 4875]. 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 [RFC 4203] and IS-IS [RFC 5307], and for signaling in [RFC 3477]. 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 [RFC 4201]. 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 [RFC 6107]. [RFC 3031] 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 [RFC 4206] with a set of protocol mechanisms for the establishment of a hierarchical LSP that can carry one or more other LSPs. [RFC 4206] 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 [RFC 4206] 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 [RFC 4208]. A Forwarding Adjacency (FA) is defined in [RFC 4206] 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 [RFC 5960]. 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 [RFC 4206], 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 [RFC 4872] and segment recovery in [RFC 4873]. 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 [RFC 6372], is signaled using the mechanism defined in [RFC 4872] and [RFC 4873]. 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 [RFC 4872] or [RFC 4873] 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 [RFC 4208] for UNIs and in [RFC 5787] 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 [RFC 5860]. 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 [RFC 3812]; the MPLS LSR MIB [RFC 3813]; the GMPLS TE MIB [RFC 4802]; and the GMPLS LSR MIB [RFC 4803]. 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 [RFC 5951]. 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 [RFC 4872], 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 [RFC 4872] 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. [RFC 5493] 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 [RFC 5852]. 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 | [RFC 3945], [RFC 4202], [RFC 3473], [RFC 4203], [RFC 5307] | | 3 | [RFC 5145] + Formal Definition (See Section 4.4.1) | | 4 | Generic requirement met by using Standards Track RFCs | | 5 | [RFC 3945], [RFC 4202], [RFC 3473], [RFC 4203], [RFC 5307] | | 6 | [RFC 3471], [RFC 3473], [RFC 4875] | | 7 | [RFC 3471], [RFC 3473] + | | | Associated bidirectional LSPs (See Section 4.4.2) | | 8 | [RFC 4875] | | 9 | [RFC 3473] | | 10 | Associated bidirectional LSPs (See Section 4.4.2) | | 11 | Associated bidirectional LSPs (See Section 4.4.2) | | 12 | [RFC 3473] | | 13 | [RFC 5467] (Currently Experimental; See Section 4.4.3) | | 14 | [RFC 3945], [RFC 3473], [RFC 4202], [RFC 4203], [RFC 5307] | | 15 | [RFC 3945], [RFC 3473], [RFC 4202], [RFC 4203], [RFC 5307] | | 16 | [RFC 3945], [RFC 4202], [RFC 3473], [RFC 4203], [RFC 5307] | | 17 | [RFC 3945], [RFC 4202] + proper vendor implementation | | 18 | [RFC 3945], [RFC 4202] + proper vendor implementation | | 19 | [RFC 3945], [RFC 4202] | Andersson, et al. Informational PAGE 34 RFC 6373 MPLS-TP Control Plane Framework September 2011 | 20 | [RFC 3473] | | 21 | [RFC 3945], [RFC 4202], [RFC 3473], [RFC 4203], [RFC 5307], | | | [RFC 5151] | | 22 | [RFC 3945], [RFC 4202], [RFC 3473], [RFC 4203], [RFC 5307], | | | [RFC 5151] | | 23 | [RFC 3945], [RFC 4202], [RFC 3473], [RFC 4203], [RFC 5307] | | 24 | [RFC 3945], [RFC 4202], [RFC 3473], [RFC 4203], [RFC 5307] | | 25 | [RFC 3945], [RFC 4202], [RFC 3473], [RFC 4203], [RFC 5307], | | | [RFC 6107] | | 26 | [RFC 3473], [RFC 4875] | | 27 | [RFC 3473], [RFC 4875] | | 28 | [RFC 3945], [RFC 3471], [RFC 4202] | | 29 | [RFC 3945], [RFC 4202], [RFC 3473], [RFC 4203], [RFC 5307] | | 30 | [RFC 3945], [RFC 3471], [RFC 4202] | | 31 | [RFC 3945], [RFC 3471], [RFC 4202] | | 32 | [RFC 4208], [RFC 4974], [RFC 5787], [RFC 6001] | | 33 | [RFC 3473], [RFC 4875] | | 34 | [RFC 4875] | | 35 | [RFC 3945], [RFC 4202], [RFC 3473], [RFC 4203], [RFC 5307] | | 36 | [RFC 3473], [RFC 3209] (Make-before-break) | | 37 | [RFC 3473], [RFC 3209] (Make-before-break) | | 38 | [RFC 4139], [RFC 4258], [RFC 5787] | | 39 | [RFC 3945], [RFC 4202], [RFC 3473], [RFC 4203], [RFC 5307] | | 40 | [RFC 3473], [RFC 5063] | | 41 | [RFC 3945], [RFC 3471], [RFC 4202], [RFC 4208] | | 42 | [RFC 3945], [RFC 3471], [RFC 4202] | | 43 | [RFC 4872], [RFC 4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 44 | [RFC 6107], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 45 | [RFC 3473], [RFC 4203], [RFC 5307], [RFC 5063] | | 46 | [RFC 5493] | | 47 | [RFC 4872], [RFC 4873] | | 48 | [RFC 3945], [RFC 3471], [RFC 4202] | | 49 | [RFC 4872], [RFC 4873] + Recovery for P2MP (see Sec. 4.4.4) | | 50 | [RFC 4872], [RFC 4873] | | 51 | [RFC 4872], [RFC 4873] + proper vendor implementation | | 52 | [RFC 4872], [RFC 4873], [GMPLS-PS] | | 53 | [RFC 4872], [RFC 4873] | | 54 | [RFC 3473], [RFC 4872], [RFC 4873], [GMPLS-PS] | | | Timers are a local implementation matter | | 55 | [RFC 4872], [RFC 4873], [GMPLS-PS] + | | | implementation of timers | | 56 | [RFC 4872], [RFC 4873], [GMPLS-PS] | | 57 | [RFC 4872], [RFC 4873] | | 58 | [RFC 4872], [RFC 4873] | | 59 | [RFC 4872], [RFC 4873] | | 60 | [RFC 4872], [RFC 4873], [RFC 6107] | | 61 | [RFC 4872], [RFC 4873] | | 62 | [RFC 4872], [RFC 4873] + Recovery for P2MP (see Sec. 4.4.4) | Andersson, et al. Informational PAGE 35 RFC 6373 MPLS-TP Control Plane Framework September 2011 | 63 | [RFC 4872], [RFC 4873] | | 64 | [RFC 4872], [RFC 4873] | | 65 | [RFC 4872], [RFC 4873] | | 66 | [RFC 4872], [RFC 4873], [RFC 6107] | | 67 | [RFC 4872], [RFC 4873] | | 68 | [RFC 3473], [RFC 4872], [RFC 4873] | | 69 | [RFC 3473] | | 70 | [RFC 3473], [RFC 4872], [GMPLS-PS] | | 71 | [RFC 3473], [RFC 4872] | | 72 | [RFC 4872], [RFC 4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 73 | [RFC 4426], [RFC 4872], [RFC 4873] | | 74 | [RFC 4426], [RFC 4872], [RFC 4873] | | 75 | [RFC 4426], [RFC 4872], [RFC 4873] | | 76 | [RFC 4426], [RFC 4872], [RFC 4873] | | 77 | [RFC 4426], [RFC 4872], [RFC 4873] | | 78 | [RFC 4426], [RFC 4872], [RFC 4873] + vendor implementation | | 79 | [RFC 4426], [RFC 4872], [RFC 4873] | | 80 | [RFC 4426], [RFC 4872], [RFC 4873] | | 81 | [RFC 4872], [RFC 4873] + Testing control (See Sec. 4.4.5) | | 82 | [RFC 4872], [RFC 4873] + Testing control (See Sec. 4.4.5) | | 83 | [RFC 4872], [RFC 4873] + Testing control (See Sec. 4.4.5) | | 84 | [RFC 4872], [RFC 4873] + Testing control (See Sec. 4.4.5) | | 85 | [RFC 4872], [RFC 4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 86 | [RFC 4872], [RFC 4873] | | 87 | [RFC 4872], [RFC 4873] | | 88 | [RFC 4872], [RFC 4873], [TP-RING] | | 89 | [RFC 4872], [RFC 4873], [TP-RING] | | 90 | [RFC 3270], [RFC 3473], [RFC 4124] + GMPLS Usage (See 4.4.6) | | 91 | [RFC 3945], [RFC 4202], [RFC 3473], [RFC 4203], [RFC 5307] | | 92 | [RFC 3945], [RFC 3473], [RFC 2210], [RFC 2211], [RFC 2212] | | 93 | Generic requirement on data plane (correct implementation)| | 94 | [RFC 3473], [NO-PHP] | | 95 | [RFC 3270], [RFC 3473], [RFC 4124] + 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 | [RFC 3945], [RFC 3473], [RFC 6107] | | 99 | [RFC 3945], [RFC 4202], [RFC 3473], [RFC 4203], [RFC 5307] + | | | [RFC 5392] and [RFC 5316] | | 100 | PW only requirement; see PW Requirements Table (5.2) | | 101 | [RFC 3473], [RFC 4203], [RFC 5307], [RFC 5063] | | 102 | [RFC 4872], [RFC 4873], [TP-RING] | | 103 | [RFC 3945], [RFC 3473], [RFC 6107] | | 104 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | | 105 | [RFC 3473], [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 | [RFC 3473], [RFC 4872], [RFC 4873] | Andersson, et al. Informational PAGE 36 RFC 6373 MPLS-TP Control Plane Framework September 2011 | 110 | [RFC 3473], [RFC 4872], [RFC 4873] | | 111 | [RFC 3473], [RFC 4783] | | 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 | [RFC 3473] | | 116 | [RFC 4426], [RFC 4872], [RFC 4873] | | 117 | [RFC 3473], [RFC 4872], [RFC 4873] | | 118 | [RFC 3473], [RFC 4783] | | 119 | [RFC 3473] | | 120 | [RFC 3473], [RFC 4783] | | 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], [RFC 6107] | | 124 - | | | 135 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | | 136a | [RFC 3473] | | 136b | [RFC 3473] + (See Sec. 4.4.7) | | 137a | [RFC 3473] | | 137b | [RFC 3473] + (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 [RFC 3209], while MPLS-TP LSPs will be signaled using GMPLS RSVP-TE, i.e., [RFC 3473]. [RFC 5145] identifies a set of solutions that are aimed to aid in the interworking of MPLS- TE and GMPLS control planes. [RFC 5145] 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, [RFC 3473], 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 [RFC 4974]. o The ASSOCIATION object [RFC 4872]. o The LSP_TUNNEL_INTERFACE_ID object [RFC 6107]. 4.4.3. Asymmetric Bandwidth LSPs [RFC 5467] 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, [RFC 4875], and GMPLS recovery, [RFC 4872] and [RFC 4873], 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 [RFC 3270] and [RFC 4124] define support for Diffserv-enabled MPLS LSPs. While [RFC 4124] 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 [RFC 6370]. One form is based on existing GMPLS fields. The other form is based on either the globally unique Attachment Interface Identifier (AII) defined in [RFC 5003] 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 [RFC 3985] and [RFC 5659], 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 [RFC 4448], (2) High-Level Data Link Control (HDLC) / PPP PW providing for HDLC/PPP leased line transport over MPLS [RFC 4618], (3) ATM PWs [RFC 4816], (4) Frame Relay PWs [RFC 4619], and (5) circuit Emulation PWs [RFC 4553]. 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) [RFC 3985] and (2) Multi-segment Pseudowires (MS-PWs) [RFC 5659]. 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 [RFC 4447]. The MS-PW signaling control plane is also based on T-LDP as allowed for in [RFC 5659], [RFC 6073], 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 [RFC 5951]. 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 | [RFC 3985], [RFC 4447], Together with TP-LSPs (Sec. 4.3) | | 3 | [RFC 3985], [RFC 4447] | | 4 | Generic requirement met by using Standards Track RFCs | | 5 | [RFC 3985], [RFC 4447], Together with TP-LSPs | | 6 | [RFC 3985], [RFC 4447], [PW-P2MPR], [PW-P2MPE] + TP-LSPs | | 7 | [RFC 3985], [RFC 4447], + TP-LSPs | | 8 | [PW-P2MPR], [PW-P2MPE] | | 9 | [RFC 3985], end-node only involvement for PW | | 10 | [RFC 3985], proper vendor implementation | | 11 | [RFC 3985], end-node only involvement for PW | | 12-13 | [RFC 3985], [RFC 4447], See Section 5.3.4 | | 14 | [RFC 3985], [RFC 4447] | | 15 | [RFC 4447], [RFC 3478], proper vendor implementation | | 16 | [RFC 3985], [RFC 4447] | | 17-18 | [RFC 3985], proper vendor implementation | | 19-26 | [RFC 3985], [RFC 4447], [RFC 5659], implementation | | 27 | [RFC 4448], [RFC 4816], [RFC 4618], [RFC 4619], [RFC 4553] | | | [RFC 4842], [RFC 5287] | | 28 | [RFC 3985] | | 29-31 | [RFC 3985], [RFC 4447] | | 32 | [RFC 3985], [RFC 4447], [RFC 5659], See Section 5.3.6 | | 33 | [RFC 4385], [RFC 4447], [RFC 5586] | | 34 | [PW-P2MPR], [PW-P2MPE] | | 35 | [RFC 4863] | | 36-37 | [RFC 3985], [RFC 4447], See Section 5.3.4 | | 38 | Provided by TP-LSPs | | 39 | [RFC 3985], [RFC 4447], + TP-LSPs | | 40 | [RFC 3478] | | 41-42 | [RFC 3985], [RFC 4447] | | 43-44 | [RFC 3985], [RFC 4447], + TP-LSPs - See Section 5.3.5 | | 45 | [RFC 3985], [RFC 4447], [RFC 5659] + TP-LSPs | | 46 | [RFC 3985], [RFC 4447], + TP-LSPs - See Section 5.3.3 | | 47 | [PW-RED], [PW-REDB] | | 48-49 | [RFC 3985], [RFC 4447], + TP-LSPs, implementation | | 50-52 | Provided by TP-LSPs, and Section 5.3.5 | | 53-55 | [RFC 3985], [RFC 4447], 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 | [RFC 3985], [RFC 4447], [PW-RED], [PW-REDB], Section 5.3.5 | | 82-83 | [RFC 5085], [RFC 5586], [RFC 5885] | | 84-89 | [RFC 3985], [RFC 4447], [PW-RED], [PW-REDB], Section 5.3.5 | | 90-95 | [RFC 3985], [RFC 4447], + TP-LSPs, implementation | | 96 | [RFC 4447], [MS-PW-DYNAMIC] | Andersson, et al. Informational PAGE 42 RFC 6373 MPLS-TP Control Plane Framework September 2011 | 97 | [RFC 4447] | | 98 - | | | 99 | Not Applicable to PW | | 100 | [RFC 4447] | | 101 | [RFC 3478] | | 102 | [RFC 3985], + TP-LSPs | | 103 | Not Applicable to PW | | 104 | [PW-OAM] | | 105 | [PW-OAM] | | 106 - | | | 108 | [RFC 5085], [RFC 5586], [RFC 5885] | | 109 | [RFC 5085], [RFC 5586], [RFC 5885] | | | fault reporting and protection triggering is a local | | | matter for PW | | 110 | [RFC 5085], [RFC 5586], [RFC 5885] | | | fault reporting and protection triggering is a local | | | matter for PW | | 111 | [RFC 4447] | | 112 | [RFC 4447], [RFC 5085], [RFC 5586], [RFC 5885] | | 113 | [RFC 5085], [RFC 5586], [RFC 5885] | | 114 | [RFC 5085], [RFC 5586], [RFC 5885] | | 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], [RFC 5085], [RFC 5586], [RFC 5885] | | 118 | [RFC 3985], [RFC 4447], [PW-RED], [PW-REDB], Section 5.3.5 | | 119 | [RFC 4447] | | 120 - | | | 125 | [RFC 5085], [RFC 5586], [RFC 5885] | | 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 | [RFC 4447], [RFC 5003], [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 [RFC 5654]. Table 2 lists how requirements defined in [RFC 5654] 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 [RFC 3031] and IETF PWE3 [RFC 3985] control and data planes where appropriate. Hence, extensions of the PW control plane must be in-line with the procedures defined in [RFC 4447], [RFC 6073], 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 [RFC 5659] 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 [RFC 5921] 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 [RFC 5085] and [RFC 5586]), 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 [RFC 5085]. Work is currently in progress to extend PW OAM to include bidirectional forwarding detection (BFD) in [RFC 5885], 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 [RFC 5920]. 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 [RFC 2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC 2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997. [RFC 2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997. [RFC 3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC 3209] 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. [RFC 3471] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC 3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC 3478] 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 [RFC 3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC 4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005. [RFC 4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC 4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC 4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. [RFC 4385] 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. [RFC 4447] 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. [RFC 4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006. [RFC 4842] 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. [RFC 4863] Martini, L. and G. Swallow, "Wildcard Pseudowire Type", RFC 4863, May 2007. [RFC 4872] 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. [RFC 4873] 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 [RFC 4929] 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. [RFC 4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls", RFC 4974, August 2007. [RFC 5063] Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart", RFC 5063, October 2007. [RFC 5151] 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. [RFC 5287] 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. [RFC 5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008. [RFC 5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008. [RFC 5316] 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. [RFC 5392] 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. [RFC 5467] Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J. Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)", RFC 5467, March 2009. [RFC 5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed., "MPLS Generic Associated Channel", RFC 5586, June 2009. [RFC 5654] 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 [RFC 5860] 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. [RFC 5921] 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. [RFC 5960] Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010. [RFC 6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport Profile (MPLS-TP) Identifiers", RFC 6370, September 2011. [RFC 6371] Busi, I., Ed., and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011. [RFC 6372] 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. [RFC 3270] 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. [RFC 3468] Andersson, L. and G. Swallow, "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols", RFC 3468, February 2003. [RFC 3472] 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 [RFC 3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. [RFC 3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)", RFC 3812, June 2004. [RFC 3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, "Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)", RFC 3813, June 2004. [RFC 3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. [RFC 3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC 4139] 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. [RFC 4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. [RFC 4208] 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. [RFC 4258] Brungard, D., Ed., "Requirements for Generalized Multi- Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)", RFC 4258, November 2005. [RFC 4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. [RFC 4426] 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 [RFC 4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4427, March 2006. [RFC 4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure- Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006. [RFC 4618] 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. [RFC 4619] 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. [RFC 4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC 4783] Berger, L., Ed., "GMPLS - Communication of Alarm Information", RFC 4783, December 2006. [RFC 4802] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", RFC 4802, February 2007. [RFC 4803] Nadeau, T., Ed., and A. Farrel, Ed., "Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base", RFC 4803, February 2007. [RFC 4816] 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. [RFC 4875] 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 [RFC 5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto, "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007. [RFC 5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007. [RFC 5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, December 2007. [RFC 5145] Shiomoto, K., Ed., "Framework for MPLS-TE to GMPLS Migration", RFC 5145, March 2008. [RFC 5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC 5493] 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. [RFC 5659] Bocci, M. and S. Bryant, "An Architecture for Multi- Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, October 2009. [RFC 5787] Papadimitriou, D., "OSPFv2 Routing Protocols Extensions for Automatically Switched Optical Network (ASON) Routing", RFC 5787, March 2010. [RFC 5852] 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. [RFC 5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, June 2010. [RFC 5885] Nadeau, T., Ed., and C. Pignataro, Ed., "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010. [RFC 5920] 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 [RFC 5951] Lam, K., Mansfield, S., and E. Gray, "Network Management Requirements for MPLS-based Transport Networks", RFC 5951, September 2010. [RFC 6001] 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. [RFC 6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., and M. Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011. [RFC 6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, February 2011. [RFC 6215] 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 RFC TOTAL SIZE: 144259 bytes PUBLICATION DATE: Wednesday, September 21st, 2011 LEGAL RIGHTS: The IETF Trust (see BCP 78)

RFC-ARCHIVE.ORG

© RFC 6373: The IETF Trust, Wednesday, September 21st, 2011
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen