--- 1/draft-ietf-ccamp-mpls-tp-cp-framework-05.txt 2011-02-10 15:14:17.000000000 +0100 +++ 2/draft-ietf-ccamp-mpls-tp-cp-framework-06.txt 2011-02-10 15:14:17.000000000 +0100 @@ -1,33 +1,34 @@ Internet Draft Loa Andersson, Ed. (Ericsson) Category: Informational Lou Berger, Ed. (LabN) -Expiration Date: July 7, 2011 Luyuan Fang, Ed. (Cisco) +Expiration Date: August 7, 2011 Luyuan Fang, Ed. (Cisco) Nabil Bitar, Ed. (Verizon) Eric Gray, Ed. (Ericsson) - January 7, 2011 + February 7, 2011 MPLS-TP Control Plane Framework - draft-ietf-ccamp-mpls-tp-cp-framework-05.txt + draft-ietf-ccamp-mpls-tp-cp-framework-06.txt 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 LSPs. MPLS-TP also uses - the Pseudowire (PW) control plane for Pseudowires (PWs). - Management plane functions are out of scope of this document. + GMPLS as the control plane for MPLS-TP Label Switched Paths + (LSPs). MPLS-TP also uses the Pseudowire (PW) control plane for + Pseudowires (PWs). 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. This Informational Internet-Draft is aimed at achieving IETF Consensus before publication as an RFC and will be subject to an IETF @@ -51,21 +52,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - This Internet-Draft will expire on July 7, 2011 + This Internet-Draft will expire on August 7, 2011 Copyright and License 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 @@ -89,71 +90,72 @@ 2.5 Identifier Requirements ................................ 24 3 Relationship of PWs and TE LSPs ........................ 25 4 TE LSPs ................................................ 26 4.1 GMPLS Functions and MPLS-TP LSPs ....................... 26 4.1.1 In-Band and Out-Of-Band Control ........................ 26 4.1.2 Addressing ............................................. 28 4.1.3 Routing ................................................ 28 4.1.4 TE LSPs and Constraint-Based Path Computation .......... 28 4.1.5 Signaling .............................................. 29 4.1.6 Unnumbered Links ....................................... 29 - 4.1.7 Link Bundling .......................................... 30 + 4.1.7 Link Bundling .......................................... 29 4.1.8 Hierarchical LSPs ...................................... 30 - 4.1.9 LSP Recovery ........................................... 31 + 4.1.9 LSP Recovery ........................................... 30 4.1.10 Control Plane Reference Points (E-NNI, I-NNI, UNI) ..... 31 4.2 OAM, MEP (Hierarchy), MIP Configuration and Control .... 31 4.2.1 Management Plane Support ............................... 32 4.3 GMPLS and MPLS-TP Requirements Table ................... 33 4.4 Anticipated MPLS-TP Related Extensions and Definitions . 36 4.4.1 MPLS-TE to MPLS-TP LSP Control Plane Interworking ...... 36 4.4.2 Associated Bidirectional LSPs .......................... 36 4.4.3 Asymmetric Bandwidth LSPs .............................. 37 4.4.4 Recovery for P2MP LSPs ................................. 37 4.4.5 Test Traffic Control and other OAM functions ........... 37 - 4.4.6 DiffServ Object usage in GMPLS ......................... 38 + 4.4.6 DiffServ Object usage in GMPLS ......................... 37 4.4.7 Support for MPLS-TP LSP Identifiers .................... 38 4.4.8 Support for MPLS-TP Maintenance Identifiers ............ 38 5 Pseudowires ............................................ 38 5.1 LDP Functions and Pseudowires .......................... 38 + 5.1.1 Management Plane Support ............................... 39 5.2 PW Control (LDP) and MPLS-TP Requirements Table ........ 39 - 5.3 Anticipated MPLS-TP Related Extensions ................. 41 + 5.3 Anticipated MPLS-TP Related Extensions ................. 42 5.3.1 Extensions to Support Out-of-Band PW Control ........... 42 - 5.3.2 Support for Explicit Control of PW-to-LSP Binding ...... 42 + 5.3.2 Support for Explicit Control of PW-to-LSP Binding ...... 43 5.3.3 Support for Dynamic Transfer of PW Control/Ownership ... 43 - 5.3.4 Interoperable Support for PW/LSP Resource Allocation ... 43 + 5.3.4 Interoperable Support for PW/LSP Resource Allocation ... 44 5.3.5 Support for PW Protection and PW OAM Configuration ..... 44 - 5.3.6 Client Layer and Cross-Provider Interfaces to PW Control.. 45 + 5.3.6 Client Layer and Cross-Provider Interfaces to PW Control ...45 5.4 ASON Architecture Considerations ....................... 45 6 Security Considerations ................................ 45 7 IANA Considerations .................................... 46 8 Acknowledgments ........................................ 46 9 References ............................................. 46 9.1 Normative References ................................... 46 9.2 Informative References ................................. 49 10 Authors' Addresses ..................................... 54 1. Introduction - The MPLS Transport Profile (MPLS-TP) is being defined in a joint - effort between the International Telecommunications Union (ITU) and - the IETF. The requirements for MPLS-TP are defined in the - requirements document, see [RFC5654]. These requirements state that - "A solution MUST be provided to support dynamic provisioning of MPLS- - TP transport paths via a control plane." This document provides the - framework for such dynamic provisioning. + The Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) + is defined as a joint effort between the International + Telecommunications Union (ITU) and the IETF. The requirements for + MPLS-TP are defined in the requirements document, see [RFC5654]. + These requirements state that "A solution MUST be provided 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 Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport - Profile within the IETF MPLS and PWE3 architectures to support the - capabilities and functions of a packet transport network as defined - by the ITU-T. + Profile within the IETF MPLS and Pseudo Wire Emulation Edge-to-Edge + (PWE3) architectures to support the capabilities and functions of a + packet transport network as defined by the ITU-T. 1.1. Scope This document covers the control plane functions involved in establishing MPLS-TP Label Switched Paths (LSPs) and Pseudowires (PWs). The control plane requirements for MPLS-TP are defined in the MPLS-TP requirements document [RFC5654]. These requirements define the role of the control plane in MPLS-TP. In particular, Section 2.4 of [RFC5654] and portions of the remainder of Section 2 of [RFC5654] provide specific control plane requirements. @@ -161,107 +163,125 @@ The LSPs provided by MPLS-TP are used as a server layer for IP, MPLS and PWs, as well as other tunneled MPLS-TP LSPs. The PWs are used to carry client signals other than IP or MPLS. The relationship between PWs and MPLS-TP LSPs is exactly the same as between PWs and MPLS LSPs in an MPLS Packet Switched Network (PSN). The PW encapsulation over MPLS-TP LSPs used in MPLS-TP networks is also the same as for PWs over MPLS in an MPLS network. MPLS-TP also defines protection and restoration (or, collectively, recovery) functions, see [RFC5654] and [RFC4427]. The MPLS-TP control plane provides methods to establish, remove and control MPLS-TP LSPs and PWs. This includes control of - data plane, OAM and recovery functions. + Operations, Administration and Maintenance (OAM), data plane, and + recovery functions. A general framework for MPLS-TP has been defined in [RFC5921], and a survivability framework for MPLS-TP has been defined in [TP-SURVIVE]. These documents scope the approaches and protocols that are the foundation of MPLS-TP. Notably, Section 3.5 of [RFC5921] scopes the IETF protocols that serve as the foundation of the MPLS-TP control plane. The PW control plane is based on the existing PW control plane, see [RFC4447], and the PW end-to-end (PWE3) architecture, see [RFC3985]. The LSP control plane is based on Generalized MPLS (GMPLS), see [RFC3945], which is built on MPLS Traffic Engineering (TE) and its numerous extensions. [TP-SURVIVE] focuses on the recovery functions that must be supported within MPLS-TP. It does not specify which control plane mechanisms are to be used. The remainder of this document discusses the impact of the MPLS-TP requirements on the GMPLS signaling and routing protocols that are used to control MPLS-TP LSPs, and on the control of PWs as specified - in [RFC4447], [SEGMENTED-PW], and [MS-PW-DYNAMIC]. + in [RFC4447], [RFC6073], and [MS-PW-DYNAMIC]. 1.2. Basic Approach The basic approach taken in defining the MPLS-TP Control Plane - framework is: + framework includes the following: 1) MPLS technology as defined by the IETF is the foundation for the MPLS Transport Profile. + 2) The data plane for MPLS-TP is a standard MPLS data plane [RFC3031] as profiled in [RFC5960]. - 3) MPLS PWs are used by MPLS-TP including the use of targeted LDP - as the foundation for PW signaling [RFC4447]; and OSPF-TE, - ISIS-TE or MP-BGP as they apply for Multi-Segment(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 packet switched networks (PSNs). - That is, the MPLS-TP domain is a packet switched network from a - PWE3 architecture perspective [RFC3985]. + + 3) MPLS PWs are used by MPLS-TP including the use of targeted + Label Distribution Protocol (LDP) as the foundation for PW + signaling [RFC4447]; and 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 packet switched networks (PSNs). That is, the MPLS-TP + domain is a packet switched network from a PWE3 architecture + perspective [RFC3985]. + 4) The MPLS-TP LSP control plane builds on the GMPLS control plane as defined by the IETF for transport LSPs. The protocols - within scope are RSVP-TE [RFC3473], OSPF-TE [RFC4203][RFC5392], - and ISIS-TE [RFC5307][RFC5316]. ASON signaling and routing - requirements in the context of GMPLS can be found in [RFC4139] - and [RFC4258]. + within scope are Resource Reservation Protocol with Traffic + Engineering (RSVP-TE) [RFC3473], OSPF-TE [RFC4203][RFC5392], + and ISIS-TE [RFC5307][RFC5316]. Automatically Switched Optical + Network (ASON) signaling and routing requirements in the + context of GMPLS can be found in [RFC4139] and [RFC4258]. + 5) Existing IETF MPLS and GMPLS RFCs and evolving Working Group Internet-Drafts should be reused wherever possible. + 6) If needed, extensions for the MPLS-TP control plane should first be based on the existing and evolving IETF work, secondly 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 MPLS-TP LSP and PW related functions. + 8) Control plane software upgrades to existing equipment is 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 which will be usable in MPLS-TP as well as MPLS networks. + 11) The foundation for MPLS-TP control plane requirements is primarily found in Section 2.4 of [RFC5654] and relevant portions of the remainder Section 2 of [RFC5654]. 1.3. Reference Model The control plane reference model is based on the general MPLS-TP - reference model as defined in the MPLS-TP framework [RFC5921]. Per - the MPLS-TP framework [RFC5921], the MPLS-TP control plane is based - on GMPLS with RSVP-TE for LSP signaling and targeted LDP for PW - signaling. In both cases, OSPF-TE or ISIS-TE with GMPLS extensions - is used for dynamic routing within an MPLS-TP domain. + reference model as defined in the MPLS-TP framework [RFC5921] and + further refined in MPLS-TP User-to-Network and Network-to-Network + Interfaces (UNI and NNI, respectively), [TP-UNI]. Per the MPLS-TP + framework [RFC5921], the MPLS-TP control plane is based on GMPLS with + RSVP-TE for LSP signaling and targeted LDP for PW signaling. In both + cases, OSPF-TE or ISIS-TE with GMPLS extensions is used for dynamic + routing within an MPLS-TP domain. Note that in this context, "targeted LDP" (or T-LDP) means LDP as defined in RFC 5036, using Targeted Hello messages. See Section 2.4.2 ("Extended Discovery Mechanism") of [RFC5036]. Use of the extended discovery mechanism is specified in [RFC4447] Section 5 ("LDP"). From a service perspective, MPLS-TP client services may be supported via both PWs and LSPs. PW client interfaces, or adaptations, are defined on an interface technology basis, e.g., Ethernet over PW [RFC4448]. In the context of MPLS-TP LSP, the client interface is provided at the network layer and may be controlled via a GMPLS based UNI, see [RFC4208], or statically provisioned. As discussed in - [RFC5921], MPLS-TP also presumes an LSP NNI reference point. + [RFC5921] and [TP-UNI], 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. @@ -282,40 +302,41 @@ 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 - End Points (MEPs), see [TP-OAM], within each provider domain and - across the inter-provider NNI. (H-LSPs are used to implement Sub- - Path Maintenance Elements (SPMEs) as defined in [RFC5921].) The MEPs - are used to collect performance information, support diagnostic and - fault management functions, and support OAM triggered survivability - schemes as discussed in [TP-SURVIVE]. Each H-LSP may be protected or - restored using any of the schemes discussed in [TP-SURVIVE]. End-to- - end monitoring is supported via MEPs at the End-to-End LSP and PW end - points. Note that segment MEPs may be collocated with MIPs of the - next higher-layer (e.g., end-to-end) LSPs. (The MS-PW case is not - shown.) + Entity End Points (MEPs), see [TP-OAM], within each provider domain + and across the inter-provider NNI. (H-LSPs are used to implement + Sub-Path Maintenance Elements (SPMEs) as defined in [RFC5921].) The + MEPs are used to collect performance information, support diagnostic + and fault management functions, and support OAM triggered + survivability schemes as discussed in [TP-SURVIVE]. Each H-LSP may be + protected or restored using any of the schemes discussed in [TP- + SURVIVE]. End-to-end monitoring is supported via MEPs at the End-to- + End LSP and PW end points. Note that segment MEPs may be collocated + with MIPs of the next higher-layer (e.g., end-to-end) LSPs. (The MS- + PW case is not shown.) |< ------- client signal (e.g., IP / MPLS / L2) ----- >| |< -------- SP1 ----------- >|< ------- SP2 ----- >| |< ----------- MPLS-TP End-to-End PW -------- >| |< ------- MPLS-TP End-to-End LSP ------- >| |< -- H-LSP1 ---- >|<-H-LSP2->|<- H-LSP3 ->| +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ |CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2| +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ UNI NNI UNI @@ -341,23 +362,24 @@ 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 end point + MEP: Maintenance entity end point MIP: Maintenance intermediate point NNI: Network to Network Interface + P: Provider PE: Provider Edge SP: Service Provider TE-RTG: GMPLS OSPF-TE or ISIS-TE Note: The MS-PW case is not shown. While not shown in the Figures above, the MPLS-TP control plane must support the addressing separation and independence between the data, control and management planes. Address separation between the planes is already included in GMPLS. Such separation is also already @@ -447,50 +469,53 @@ of the control plane from the management and data plane, and no assumptions should be made about the state of the data plane channels from information about the control or management plane channels when they are running out-of-band [RFC5654, requirement 16]. 16. A control plane must be defined to support dynamic provisioning and restoration of MPLS-TP transport paths, but its use is a network operator's choice [RFC5654, requirement 18]. - 17. A control plane must not be required to support the static + 17. The presence of a control plane must not be required for static provisioning of MPLS-TP transport paths. [RFC5654, requirement 19]. 18. The MPLS-TP control plane must permit the coexistence of statically and dynamically provisioned/managed MPLS-TP transport paths within the same layer network or domain [RFC5654, requirement 20]. 19. The MPLS-TP control plane should be operable in a way that is similar to the way the control plane operates in other transport-layer technologies [RFC5654, requirement 21]. 20. The MPLS-TP control plane must avoid or minimize traffic impact (e.g. packet delay, reordering and loss) during network reconfiguration [RFC5654, requirement 24]. 21. The MPLS-TP control plane must work across multiple homogeneous - domains [RFC5654, requirement 25]. + domains [RFC5654, requirement 25], i.e., all domains use the + same MPLS-TP control plane. 22. The MPLS-TP control plane should work across multiple non- - homogeneous domains [RFC5654, requirement 26]. + homogeneous domains [RFC5654, requirement 26], i.e., some + domains use the same control plane and other domains use static + provisioning at the domain boundary. 23. The MPLS-TP control plane must not dictate any particular physical or logical topology [RFC5654, requirement 27]. 24. The MPLS-TP control plane must include support of ring topologies which may be deployed with arbitrarily interconnection, support rings of at least 16 nodes [RFC5654, - requirement 27.A. and 27.B]. + requirement 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 @@ -519,22 +544,22 @@ MPLS-TP layer network [RFC5654, requirement 33]. 31. The MPLS-TP control plane must allow the autonomous operation of the layers of a multi-layer network that includes an MPLS-TP layer [RFC5654, requirement 34]. 32. The MPLS-TP control plane must allow the hiding of MPLS-TP layer network addressing and other information (e.g. topology) from client layer networks. However, it should be possible, at the option of the operator, to leak a limited amount of - summarized information (such as SRLGs or reachability) between - layers [RFC5654, requirement 35]. + summarized information, such as Shared Risk Link Groups (SRLGs) + or reachability, between layers [RFC5654, requirement 35]. 33. The MPLS-TP control plane must allow for the identification of a transport path on each link within and at the destination (egress) of the transport network. [RFC5654, requirement 38 and 39]. 34. The MPLS-TP control plane must allow for the use of P2MP server (sub)layer capabilities as well as P2P server (sub)layer capabilities when supporting P2MP MPLS-TP transport paths [RFC5654, requirement 40]. @@ -547,489 +572,488 @@ associated with a transport path to be increased without impacting the existing traffic on that transport path provided enough resources are available [RFC5654, requirement 42]. 37. The MPLS-TP control plane should support the reserved bandwidth of a transport path to be decreased without impacting the existing traffic on that transport path, provided that the level of existing traffic is smaller than the reserved bandwidth following the decrease [RFC5654, requirement 43]. - 38. Requirement removed. - - 39. The control plane for MPLS-TP must fit within the ASON - architecture. The ITU-T has defined an architecture for + 38. The control plane for MPLS-TP must fit within the ASON (control + plane) architecture. The ITU-T has defined an architecture for Automatically Switched Optical Networks (ASON) in G.8080 [ITU.G8080.2006] and G.8080 Amendment 1 [ITU.G8080.2008]. An interpretation of the ASON signaling and routing requirements in the context of GMPLS can be found in [RFC4139] and [RFC4258] [RFC5654, Section 2.4., Paragraph 2 and 3]. - 40. The MPLS-TP control plane must support control plane topology + 39. The MPLS-TP control plane must support control plane topology and data plane topology independence [RFC5654, requirement 47]. - 41. A failure of the MPLS-TP control plane must not interfere with + 40. A failure of the MPLS-TP control plane must not interfere with the delivery of service or recovery of established transport paths [RFC5654, requirement 47]. - 42. The MPLS-TP control plane must be able to operate independent + 41. The MPLS-TP control plane must be able to operate independent of any particular client or server layer control plane [RFC5654, requirement 48]. - 43. The MPLS-TP control plane should support, but not require, an + 42. The MPLS-TP control plane should support, but not require, an integrated control plane encompassing MPLS-TP together with its server and client layer networks when these layer networks belong to the same administrative domain [RFC5654, requirement 49]. - 44. The MPLS-TP control plane must support configuration of + 43. The MPLS-TP control plane must support configuration of protection functions and any associated maintenance (OAM) functions [RFC5654, requirement 50 and 7]. - 45. The MPLS-TP control plane must support the configuration and + 44. The MPLS-TP control plane must support the configuration and modification of OAM maintenance points as well as the activation/deactivation of OAM when the transport path or transport service is established or modified [RFC5654, requirement 51]. - 46. The MPLS-TP control plane must be capable of restarting and + 45. The MPLS-TP control plane must be capable of restarting and relearning its previous state without impacting forwarding [RFC5654, requirement 54]. - 47. The MPLS-TP control plane must provide a mechanism for dynamic + 46. The MPLS-TP control plane must provide a mechanism for dynamic ownership transfer of the control of MPLS-TP transport paths from the management plane to the control plane and vice versa. The number of reconfigurations required in the data plane must be minimized (preferably no data plane reconfiguration will be required) [RFC5654, requirement 55]. Note, such transfers cover all transport path control functions including control of recovery and OAM. - 48. The MPLS-TP control plane must support protection and + 47. The MPLS-TP control plane must support protection and restoration mechanisms, i.e., recovery [RFC5654, requirement 52]. Note that the MPLS-TP Survivability Framework document, [TP- SURVIVE], provides additional useful information related to recovery. - 49. The MPLS-TP control plane mechanisms should be identical (or as + 48. The MPLS-TP control plane mechanisms should be identical (or as similar as possible) to those already used in existing transport networks to simplify implementation and operations. However, this must not override any other requirement [RFC5654, requirement 56 A]. - 50. The MPLS-TP control plane mechanisms used for P2P and P2MP + 49. The MPLS-TP control plane mechanisms used for P2P and P2MP recovery should be identical to simplify implementation and operation. However, this must not override any other requirement [RFC5654, requirement 56 B]. - 51. The MPLS-TP control plane must support recovery mechanisms that + 50. The MPLS-TP control plane must support recovery mechanisms that are applicable at various levels throughout the network including support for link, transport path, segment, concatenated segment and end-to-end recovery [RFC5654, requirement 57]. - 52. The MPLS-TP control plane must support recovery paths that meet + 51. The MPLS-TP control plane must support recovery paths that meet the SLA protection objectives of the service [RFC5654, requirement 58]. Including: a. Guarantee 50ms recovery times from the moment of fault detection in networks with spans less than 1200 km. - b. Protection of up to 100% of the traffic on the protected - path. + b. Protection of 100% of the traffic on the protected path. c. Recovery must meet SLA requirements over multiple domains. - 53. The MPLS-TP control plane should support per transport path + 52. The MPLS-TP control plane should support per transport path Recovery objectives [RFC5654, requirement 59]. - 54. The MPLS-TP control plane must support recovery mechanisms that + 53. The MPLS-TP control plane must support recovery mechanisms that are applicable to any topology [RFC5654, requirement 60]. - 55. The MPLS-TP control plane must operate in synergy with + 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, WDM) to avoid race conditions between the layers [RFC5654, requirement 61]. - 56. The MPLS-TP control plane must support recovery and reversion + 55. The MPLS-TP control plane must support recovery and reversion mechanisms that prevent frequent operation of recovery in the event of an intermittent defect [RFC5654, requirement 62]. - 57. The MPLS-TP control plane must support revertive and non- + 56. The MPLS-TP control plane must support revertive and non- revertive protection behavior [RFC5654, requirement 64]. - 58. The MPLS-TP control plane must support 1+1 bidirectional + 57. The MPLS-TP control plane must support 1+1 bidirectional protection for P2P transport paths [RFC5654, requirement 65 A]. - 59. The MPLS-TP control plane must support 1+1 unidirectional + 58. The MPLS-TP control plane must support 1+1 unidirectional protection for P2P transport paths [RFC5654, requirement 65 B]. - 60. The MPLS-TP control plane must support 1+1 unidirectional + 59. The MPLS-TP control plane must support 1+1 unidirectional protection for P2MP transport paths [RFC5654, requirement 65 C]. - 61. The MPLS-TP control plane must support the ability to share + 60. The MPLS-TP control plane must support the ability to share protection resources amongst a number of transport paths [RFC5654, requirement 66]. - 62. The MPLS-TP control plane must support 1:n bidirectional - protection for P2P transport paths, and this should be the - default for 1:n protection [RFC5654, requirement 67 A]. + 61. The MPLS-TP control plane must support 1:n bidirectional + protection for P2P transport paths. Bidirectional 1:n + protection should be the default for 1:n protection [RFC5654, + requirement 67 A]. - 63. The MPLS-TP control plane must support 1:n unidirectional + 62. The MPLS-TP control plane must support 1:n unidirectional protection for P2MP transport paths [RFC5654, requirement 67 B]. - 64. The MPLS-TP control plane may support 1:n unidirectional + 63. The MPLS-TP control plane may support 1:n unidirectional protection for P2P transport paths [RFC5654, requirement 65 C]. - 65. The MPLS-TP control plane may support extra-traffic [RFC5654, - note after requirement 67]. + 64. The MPLS-TP control plane may support the control of extra- + traffic type traffic [RFC5654, note after requirement 67]. - 66. The MPLS-TP control plane should support 1:n (including 1:1) + 65. The MPLS-TP control plane should support 1:n (including 1:1) shared mesh recovery [RFC5654, requirement 68]. - 67. The MPLS-TP control plane must support sharing of protection + 66. The MPLS-TP control plane must support sharing of protection resources such that protection paths that are known not to be required concurrently can share the same resources [RFC5654, requirement 69]. - 68. The MPLS-TP control plane must support the sharing of resources + 67. The MPLS-TP control plane must support the sharing of resources between a restoration transport path and the transport path being replaced [RFC5654, requirement 70]. - 69. The MPLS-TP control plane must support restoration priority so + 68. The MPLS-TP control plane must support restoration priority so that an implementation can determine the order in which transport paths should be restored [RFC5654, requirement 71]. - 70. The MPLS-TP control plane must support preemption priority in + 69. The MPLS-TP control plane must support preemption priority in order to allow restoration to displace other transport paths in the event of resource constraints [RFC5654, requirement 72 and 86]. - 71. The MPLS-TP control plane must support revertive and non- + 70. The MPLS-TP control plane must support revertive and non- revertive restoration behavior [RFC5654, requirement 73]. - 72. The MPLS-TP control plane must support recovery being triggered + 71. The MPLS-TP control plane must support recovery being triggered by physical (lower) layer fault indications [RFC5654, requirement 74]. - 73. The MPLS-TP control plane must support recovery being triggered + 72. The MPLS-TP control plane must support recovery being triggered by OAM [RFC5654, requirement 75]. - 74. The MPLS-TP control plane must support management plane + 73. The MPLS-TP control plane must support management plane recovery triggers (e.g., forced switch, etc.) [RFC5654, requirement 76]. - 75. The MPLS-TP control plane must support the differentiation of + 74. The MPLS-TP control plane must support the differentiation of administrative recovery actions from recovery actions initiated by other triggers [RFC5654, requirement 77]. - 76. The MPLS-TP control plane should support control plane + 75. The MPLS-TP control plane should support control plane restoration triggers (e.g., forced switch, etc.) [RFC5654, requirement 78]. - 77. The MPLS-TP control plane must support priority logic to + 76. The MPLS-TP control plane must support priority logic to negotiate and accommodate coexisting requests (i.e., multiple requests) for protection switching (e.g., administrative requests and requests due to link/node failures) [RFC5654, requirement 79]. - 78. The MPLS-TP control plane must support the association of + 77. The MPLS-TP control plane must support the association of protection paths and working paths (sometimes known as protection groups) [RFC5654, requirement 80]. - 79. The MPLS-TP control plane must support pre-calculation of + 78. The MPLS-TP control plane must support pre-calculation of recovery paths [RFC5654, requirement 81]. - 80. The MPLS-TP control plane must support pre-provisioning of + 79. The MPLS-TP control plane must support pre-provisioning of recovery paths [RFC5654, requirement 82]. - 81. The MPLS-TP control plane must support the external commands + 80. The MPLS-TP control plane must support the external commands defined in [RFC4427]. External controls overruled by higher priority requests (e.g., administrative requests and requests due to link/node failures) or unable to be signaled to the remote end (e.g. because of a protection state coordination fail) must be ignored/dropped [RFC5654, requirement 83]. - 82. The MPLS-TP control plane must permit the testing and + 81. The MPLS-TP control plane must permit the testing and validation of the integrity of the protection/recovery transport path [RFC5654, requirement 84 A]. - 83. The MPLS-TP control plane must permit the testing and + 82. The MPLS-TP control plane must permit the testing and validation of protection/restoration mechanisms without triggering the actual protection/restoration [RFC5654, requirement 84 B]. - 84. The MPLS-TP control plane must permit the testing and + 83. The MPLS-TP control plane must permit the testing and validation of protection/restoration mechanisms while the working path is in service [RFC5654, requirement 84 C]. - 85. The MPLS-TP control plane must permit the testing and + 84. The MPLS-TP control plane must permit the testing and validation of protection/restoration mechanisms while the working path is out of service [RFC5654, requirement 84 D]. - 86. The MPLS-TP control plane must support the establishment and + 85. The MPLS-TP control plane must support the establishment and maintenance of all recovery entities and functions [RFC5654, requirement 89 A]. - 87. The MPLS-TP control plane must support signaling of recovery + 86. The MPLS-TP control plane must support signaling of recovery administrative control [RFC5654, requirement 89 B]. - 88. The MPLS-TP control plane must support protection state + 87. The MPLS-TP control plane must support protection state coordination (PSC). Since control plane network topology is independent from the data plane network topology, the PSC supported by the MPLS-TP control plane may run on resources different than the data plane resources handled within the recovery mechanism (e.g. backup) [RFC5654, requirement 89 C]. - 89. When present, the MPLS-TP control plane must support recovery + 88. When present, the MPLS-TP control plane must support recovery mechanisms that are optimized for specific network topologies. These mechanisms must be interoperable with the mechanisms defined for arbitrary topology (mesh) networks to enable protection of end-to-end transport paths [RFC5654, requirement 91]. - 90. When present, the MPLS-TP control plane must support the + 89. When present, the MPLS-TP control plane must support the control of ring topology specific recovery mechanisms [RFC5654, Section 2.5.6.1]. - 91. The MPLS-TP control plane must include support for + 90. The MPLS-TP control plane must include support for differentiated services and different traffic types with traffic class separation associated with different traffic [RFC5654, requirement 110]. - 92. The MPLS-TP control plane must support the provisioning of + 91. The MPLS-TP control plane must support the provisioning of services that provide guaranteed Service Level Specifications (SLS), with support for hard ([RFC3209] style) and relative ([RFC3270] style) end-to-end bandwidth guarantees [RFC5654, requirement 111]. - 93. The MPLS-TP control plane must support the provisioning of + 92. The MPLS-TP control plane must support the provisioning of services which are sensitive to jitter and delay [RFC5654, requirement 112]. 2.2. MPLS-TP Framework Derived Requirements The following additional requirements are based on [RFC5921], [TP- P2MP-FWK] and [RFC5960]: - 94. Per-packet equal cost multi-path (ECMP) load balancing is - currently outside the scope of MPLS-TP [TP-DATA-PLANE , section + 93. Per-packet equal cost multi-path (ECMP) load balancing is + currently outside the scope of MPLS-TP [RFC5960 , section 3.1.1., paragraph 6]. - 95. Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by - default. [TP-DATA-PLANE , section 3.1.1., paragraph 7]. + 94. Penultimate hop popping (PHP) must be disabled on MPLS-TP LSPs + by default. [RFC5960 , section 3.1.1., paragraph 7]. - 96. The MPLS-TP control plane must support both E-LSP and L-LSP - MPLS DiffServ modes as specified in [RFC3270] [TP-DATA-PLANE , + 95. The MPLS-TP control plane must support both E-LSP and L-LSP + MPLS DiffServ modes as specified in [RFC3270] [RFC5960 , section 3.3.2., paragraph 12]. - 97. Both single-segment, see [RFC3985], and multi-segment PWs, see + 96. Both single-segment, see [RFC3985], and multi-segment PWs, see [RFC5659], shall be supported by the MPLS-TP control plane. MPLS-TP shall use the definition of multi-segment PWs as defined by the IETF [RFC5921, section 3.4.4]. - 98. The MPLS-TP control plane must support the control of PWs and + 97. The MPLS-TP control plane must support the control of PWs and their associated labels [RFC5921, section 3.4.4]. - 99. The MPLS-TP control plane must support network layer clients, + 98. The MPLS-TP control plane must support network layer clients, i.e., clients whose traffic is transported over an MPLS-TP network without the use of PWs [RFC5921, section 3.4.5]. a. The MPLS-TP control plane must support the use of network layer protocol-specific LSPs and labels. [RFC5921, section 3.4.5.] b. The MPLS-TP control plane must support the use of a client service-specific LSPs and labels. [RFC5921, section 3.4.5.] - 100. The MPLS-TP control plane for LSPs is based on the GMPLS + 99. The MPLS-TP control plane for LSPs must be based on the GMPLS control plane. More specifically, GMPLS RSVP-TE [RFC3473] and related extensions are used for LSP signaling, and GMPLS OSPF- TE [RFC5392] and ISIS-TE [RFC5316] are used for routing [RFC5921, section 3.9]. - 101. The MPLS-TP control plane for PWs is based on the MPLS control - plane for PWs, and more specifically, targeted LDP (T-LDP) - [RFC4447] is used for PW signaling [RFC5921, section 3.9., + 100. The MPLS-TP control plane for PWs must be based on the MPLS + control plane for PWs, and more specifically, targeted LDP (T- + LDP) [RFC4447] is used for PW signaling [RFC5921, section 3.9., paragraph 5]. - 102. The MPLS-TP control plane must ensure its own survivability and + 101. The MPLS-TP control plane must ensure its own survivability and to enable it to recover gracefully from failures and degradations. These include graceful restart and hot redundant configurations [RFC5921, section 3.9., paragraph 16]. - 103. The MPLS-TP control plane must support linear, ring and meshed + 102. The MPLS-TP control plane must support linear, ring and meshed protection schemes [RFC5921, section 3.12., paragraph 3]. - 104. The MPLS-TP control plane must support the control of SPMEs + 103. The MPLS-TP control plane must support the control of SPMEs (hierarchical LSPs) for new or existing end-to-end LSPs [RFC5921, section 3.12., paragraph 7]. 2.3. OAM Framework Derived Requirements The following additional requirements are based on [RFC5860] and [TP- OAM]: - 105. The MPLS-TP control plane must support the capability to + 104. The MPLS-TP control plane must support the capability to enable/disable OAM functions as part of service establishment [RFC5860, section 2.1.6., paragraph 1]. Note that OAM functions are applicable regardless of the label stack depth (i.e., level of LSP hierarchy or PW) [RFC5860, section 2.1.1., paragraph 3]. - 106. The MPLS-TP control plane must support the capability to + 105. The MPLS-TP control plane must support the capability to enable/disable OAM functions after service establishment. In such cases, the customer must not perceive service degradation as a result of OAM enabling/disabling [RFC5860, section 2.1.6., paragraph 1 and 2]. - 107. The MPLS-TP control plane must support dynamic control of any + 106. The MPLS-TP control plane must support dynamic control of any of the existing IP/MPLS and PW OAM protocols (e.g., LSP-Ping [RFC4379], MPLS-BFD [RFC5884], VCCV [RFC5085], and VCCV-BFD [RFC5885]) [RFC5860, section 2.1.4., paragraph 2]. - 108. The MPLS-TP control plane must allow for the ability to support + 107. The MPLS-TP control plane must allow for the ability to support experimental OAM functions. These functions must be disabled by default [RFC5860, section 2.2., paragraph 2]. - 109. The MPLS-TP control plane must support the choice of which (if + 108. The MPLS-TP control plane must support the choice of which (if any) OAM function(s) to use and to which PW, LSP or Section it applies [RFC5860, section 2.2., paragraph 3]. - 110. The MPLS-TP control plane must allow (e.g., enable/disable) + 109. The MPLS-TP control plane must allow (e.g., enable/disable) mechanisms that support the localization of faults and the notification of appropriate nodes. [RFC5860, section 2.2.1., paragraph 1]. - 111. The MPLS-TP control plane may support mechanisms that permit + 110. The MPLS-TP control plane may support mechanisms that permit the service provider to be informed of a fault or defect affecting the service(s) it provides, even if the fault or defect is located outside of his domain [RFC5860, section 2.2.1., paragraph 2]. - 112. Information exchange between various nodes involved in the + 111. Information exchange between various nodes involved in the MPLS-TP control plane should be reliable such that, for example, defects or faults are properly detected or that state changes are effectively known by the appropriate nodes [RFC5860, section 2.2.1., paragraph 3]. - 113. The MPLS-TP control plane must provide functionality to control + 112. The MPLS-TP control plane must provide functionality to control an End Point's ability to monitor the liveness of a PW, LSP, or Section [RFC5860, section 2.2.2., paragraph 1]. - 114. The MPLS-TP control plane must provide functionality to control + 113. The MPLS-TP control plane must provide functionality to control an End Point's ability to determine whether or not it is connected to specific End Point(s) by means of the expected PW, LSP, or Section [RFC5860, section 2.2.3., paragraph 1]. a. The MPLS-TP control plane must provide mechanisms to control an End Point's ability to perform this function proactively [RFC5860, section 2.2.3., paragraph 2]. b. The MPLS-TP control plane must provide mechanisms to control an End Point's ability to perform this function on-demand [RFC5860, section 2.2.3., paragraph 3]. - 115. The MPLS-TP control plane must provide functionality to control + 114. The MPLS-TP control plane must provide functionality to control diagnostic testing on a PW, LSP or Section [RFC5860, section 2.2.5., paragraph 1]. a. The MPLS-TP control plane must provide mechanisms to control the performance of this function on-demand [RFC5860, section 2.2.5., paragraph 2]. - 116. The MPLS-TP control plane must provide functionality to enable + 115. The MPLS-TP control plane must provide functionality to enable an End Point to discover the Intermediate (if any) and End Point(s) along a PW, LSP or Section, and more generally to trace (record) the route of a PW, LSP or Section [RFC5860, section 2.2.4., paragraph 1]. a. The MPLS-TP control plane must provide mechanisms to control the performance of this function on-demand [RFC5860, section 2.2.4., paragraph 2]. - 117. The MPLS-TP control plane must provide functionality to enable + 116. The MPLS-TP control plane must provide functionality to enable an End Point of a PW, LSP or Section to instruct its associated End Point(s) to lock the PW, LSP or Section [RFC5860, section 2.2.6., paragraph 1]. a. The MPLS-TP control plane must provide mechanisms to control the performance of this function on-demand [RFC5860, section 2.2.6., paragraph 2]. - 118. The MPLS-TP control plane must provide functionality to enable + 117. The MPLS-TP control plane must provide functionality to enable an Intermediate Point of a PW or LSP to report, to an End Point of that same PW or LSP, a lock condition indirectly affecting that PW or LSP [RFC5860, section 2.2.7., paragraph 1]. a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively [RFC5860, section 2.2.7., paragraph 2]. - 119. The MPLS-TP control plane must provide functionality to enable + 118. The MPLS-TP control plane must provide functionality to enable an Intermediate Point of a PW or LSP to report, to an End Point of that same PW or LSP, a fault or defect condition affecting that PW or LSP [RFC5860, section 2.2.8., paragraph 1]. a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively [RFC5860, section 2.2.8., paragraph 2]. - 120. The MPLS-TP control plane must provide functionality to enable + 119. The MPLS-TP control plane must provide functionality to enable an End Point to report, to its associated End Point, a fault or defect condition that it detects on a PW, LSP or Section for which they are the End Points [RFC5860, section 2.2.9., paragraph 1]. a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively [RFC5860, section 2.2.9., paragraph 2]. - 121. The MPLS-TP control plane must provide functionality to enable + 120. The MPLS-TP control plane must provide functionality to enable the propagation, across an MPLS-TP network, of information pertaining to a client defect or fault condition detected at an End Point of a PW or LSP, if the client layer mechanisms do not provide an alarm notification/propagation mechanism [RFC5860, section 2.2.10., paragraph 1]. a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively [RFC5860, section 2.2.10., paragraph 2]. - 122. The MPLS-TP control plane must provide functionality to enable + 121. The MPLS-TP control plane must provide functionality to enable the control of quantification of packet loss ratio over a PW, LSP or Section [RFC5860, section 2.2.11., paragraph 1]. a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively and on-demand [RFC5860, section 2.2.11., paragraph 4]. - 123. The MPLS-TP control plane must provide functionality to control + 122. The MPLS-TP control plane must provide functionality to control the quantification and reporting of the one-way, and if appropriate, the two-way, delay of a PW, LSP or Section [RFC5860, section 2.2.12., paragraph 1]. a. The MPLS-TP control plane must provide mechanisms to control the performance of this function proactively and on-demand [RFC5860, section 2.2.12., paragraph 6]. - 124. The MPLS-TP control plane must support the configuration of OAM - functional components which include MEs and MEGs as - instantiated in MEPs, MIPs and SPMEs [TP-OAM, section 3.6]. + 123. The MPLS-TP control plane must support the configuration of OAM + functional components which include Maintenance Entities (MEs) + and Maintenance Entity Groups (MEGs) as instantiated in MEPs, + MIPs and SPMEs [TP-OAM, section 3.6]. - 125. For dynamically established transport paths, the control plane + 124. For dynamically established transport paths, the control plane must support the configuration of OAM operations [TP-OAM, 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., CV, LM etc.) are @@ -1037,138 +1061,139 @@ 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. - 126. The MPLS-TP control plane must support the control of the loss + 125. The MPLS-TP control plane must support the control of the loss of continuity (LOC) traffic block consequent action [TP-OAM, section 5.1.2., paragraph 4]. - 127. For dynamically established transport paths that have a - proactive CC-V function enabled, the control plane must support - the signaling of the following MEP configuration information - [TP-OAM, section 5.1.3]: + 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 [TP-OAM, section + 5.1.3]: a. The MPLS-TP control plane must provide mechanisms to configure the MEG identifier to which the MEP belongs. b. The MPLS-TP control plane must provide mechanisms to configure a MEP's own identity inside a MEG. c. The MPLS-TP control plane must provide mechanisms to configure the list of the other MEPs in the MEG. d. The MPLS-TP control plane must provide mechanisms to configure the CC-V transmission rate / reception period (covering all application types). - 128. The MPLS-TP control plane must provide mechanisms to configure + 127. The MPLS-TP control plane must provide mechanisms to configure the generation of Alarm Indication Signal (AIS) packets for each MEG [TP-OAM, section 5.3., paragraph 9]. - 129. The MPLS-TP control plane must provide mechanisms to configure + 128. The MPLS-TP control plane must provide mechanisms to configure the generation of Locked Report (LKR) packets for each MEG [TP- OAM, section 5.4., paragraph 9]. - 130. The MPLS-TP control plane must provide mechanisms to configure + 129. The MPLS-TP control plane must provide mechanisms to configure the use of proactive Packet Loss Measurement (LM), and the - transmission rate and PHB class associated with the LM OAM - packets originating from a MEP [TP-OAM, section 5.5.1., - paragraph 1]. + transmission rate and Per-hop Behavior (PHB) class associated + with the LM OAM packets originating from a MEP [TP-OAM, section + 5.5.1., paragraph 1]. - 131. The MPLS-TP control plane must provide mechanisms to configure + 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 [TP-OAM, section 5.6.1., paragraph 1]. - 132. The MPLS-TP control plane must provide mechanisms to configure + 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 [TP-OAM, section 5.7.1., paragraph 1]. - 133. The MPLS-TP control plane should provide mechanisms to control + 132. The MPLS-TP control plane should provide mechanisms to control the use of on-demand CV packets [TP-OAM, 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 [TP-OAM, 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 [TP-OAM, section 6.1.1, paragraph 2]. c. The MPLS-TP control plane should provide mechanisms to configure the PHB of on-demand CV packets [TP-OAM, section 6.1.1, paragraph 3]. - 134. The MPLS-TP control plane should provide mechanisms to control + 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. [TP-OAM, section 6.2.1.] - 135. The MPLS-TP control plane should provide mechanisms to control + 134. The MPLS-TP control plane should provide mechanisms to control the use of Throughput estimation [TP-OAM, section 6.3.1]. - 136. The MPLS-TP control plane should provide mechanisms to control + 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. [TP-OAM, section 6.5.1.] 2.4. Security Requirements There are no specific MPLS-TP control plane security requirements. The existing framework for MPLS and GMPLS security is documented in [RFC5920] and that document applies equally to MPLS-TP. 2.5. Identifier Requirements The following are requirements based on [TP-IDENTIFIERS]: - 137. The MPLS-TP control plane must support MPLS-TP point to point + 136. The MPLS-TP control plane must support MPLS-TP point to point tunnel identifiers of the forms defined in [TP-IDENTIFIERS, Section 5.1]. - 138. The MPLS-TP control plane must support MPLS-TP LSP identifiers + 137. The MPLS-TP control plane must support MPLS-TP LSP identifiers of the forms defined in [TP-IDENTIFIERS, Section 5.2], and the mappings to GMPLS as defined in [TP-IDENTIFIERS, Section 5.3]. - 139. The MPLS-TP control plane must support Pseudowire path + 138. The MPLS-TP control plane must support Pseudowire path identifiers of the form defined in [TP-IDENTIFIERS, Section 6.]. - 140. The MPLS-TP control plane must support MEG_IDs for LSPs and PWs + 139. The MPLS-TP control plane must support MEG_IDs for LSPs and PWs as defined in [TP-IDENTIFIERS, Section 7.1.1]. - 141. The MPLS-TP control plane must support IP compatible MEG_IDs + 140. The MPLS-TP control plane must support IP compatible MEG_IDs for LSPs and PWs as defined [TP-IDENTIFIERS, Section 7.1.2]. - 142. The MPLS-TP control plane must support MEP_IDs for LSPs and PWs + 141. The MPLS-TP control plane must support MEP_IDs for LSPs and PWs of the forms defined in [TP-IDENTIFIERS, Section 7.2.1]. - 143. The MPLS-TP control plane must support IP based MEP_IDs for + 142. The MPLS-TP control plane must support IP based MEP_IDs for MPLS-TP LSP of the forms defined in [TP-IDENTIFIERS, Section 7.2.2.1]. - 144. The MPLS-TP control plane must support IP based MEP_IDs for + 143. The MPLS-TP control plane must support IP based MEP_IDs for Pseudowires of the form defined in [TP-IDENTIFIERS, Section 7.2.2.2]. 3. Relationship of PWs and TE LSPs The data plane relationship between PWs and LSPs is inherited from standard MPLS and is reviewed in the MPLS-TP Framework [RFC5921]. Likewise, the control plane relationship between PWs and LSPs is inherited from standard MPLS. This relationship is reviewed in this document. The relationship between the PW and LSP control planes in @@ -1246,21 +1271,21 @@ o In-band This term is used to refer to cases where control plane traffic is sent in the same communication channel used to transport associated user data or management traffic. IP, MPLS, and Ethernet networks are all examples where control traffic is typically sent in-band with the data traffic. An example of this case in the context of MPLS-TP is where control plane traffic is sent via the MPLS Generic Associated Channel (G-ACh), see [RFC5586], using the same LSP as controlled user traffic. - o Out-of-band, in-fiber + 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) which carries controlled user traffic. o Out-of-band, aligned topology @@ -1289,30 +1314,30 @@ 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. Some expect the G-ACh to be used - extensively in MPLS-TP networks to support the MPLS-TP control (and - management) planes. + band, independent topology. G-ACh is likely to be used extensively + in MPLS-TP networks to support the MPLS-TP control (and management) + planes. 4.1.2. Addressing MPLS-TP reuses and supports the addressing mechanisms supported by MPLS. The MPLS-TP Identifiers document, see [TP-IDENTIFIERS], provides additional context on how IP addresses are used within MPLS- - TP. MPLS, and consequently, MPLS-TP uses the IPv4 and IPv6 address + 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 @@ -1345,37 +1370,37 @@ as support for the other functions discussed in this section. Both MPLS and GMPLS path computation allow for the restriction of path selection based on the use of Explicit Route Objects (EROs) and other LSP attributes, see [RFC3209] and [RFC3473]. In all cases, no specific algorithm is standardized by the IETF. This is anticipated to continue to be the case for MPLS-TP LSPs. 4.1.4.1. Relation to PCE - Path Computation Element (PCE) Based approaches, see [RFC4655], may + Path Computation Element (PCE)-based approaches, see [RFC4655], may be used for path computation of a GMPLS LSP, and consequently an MPLS-TP LSP, across domains and in a single domain. In cases where PCE is used, the PCE Communication Protocol (PCEP), see [RFC5440], - will be used to communicate PCE requests and responses. MPLS-TP - specific extensions to PCEP are currently out of scope of the MPLS-TP - project and this document. + will be used to communicate PCE related requests and responses. MPLS- + TP specific extensions to PCEP are currently out of scope of the + MPLS-TP project and this document. 4.1.5. Signaling GMPLS signaling is defined in [RFC3471] and [RFC3473], and is based on RSVP-TE [RFC3209]. CR-LDP based GMPLS, [RFC3472] is no longer - under active development within the IETF, i.e., it is deprecated, and - must not be used for MPLS-TP. In general, all RSVP-TE extensions - that apply to MPLS may also be used for GMPLS and consequently MPLS- - TP. Most notably this includes support for P2MP signaling as defined - in [RFC4875]. + under active development within the IETF, i.e., it is deprecated, see + [RFC3468], and must not be used for MPLS and consequently also MPLS- + TP. In general, all RSVP-TE extensions that apply to MPLS may also + be used for GMPLS and consequently MPLS-TP. Most notably this + includes support for P2MP signaling as defined in [RFC4875]. GMPLS signaling includes a number of MPLS-TP required functions. Notably support for out-of-band control, bidirectional LSPs, and independent control and data plane fault management. There are also numerous other GMPLS and MPLS extensions that can be used to provide specific functions in MPLS-TP networks. Specific references are provided below. 4.1.6. Unnumbered Links @@ -1388,21 +1413,21 @@ 4.1.7. Link Bundling Link bundling provides a local construct that can be used to improve scaling of TE routing when multiple data links are shared between node pairs. Link bundling for MPLS and GMPLS networks is defined in [RFC4201]. Link bundling may be used in MPLS-TP networks and its use is at the discretion of the network operator. 4.1.8. Hierarchical LSPs - This section reuses text from [HIERARCHY-BIS]. + This section reuses text from [RFC6107]. [RFC3031] describes how MPLS labels may be stacked so that LSPs may be nested with one LSP running through another. This concept of Hierarchical LSPs (H-LSPs) is formalized in [RFC4206] with a set of protocol mechanisms for the establishment of a hierarchical LSP that can carry one or more other LSPs. [RFC4206] goes on to explain that a hierarchical LSP may carry other LSPs only according to their switching types. This is a function of the way labels are carried. In a packet switch capable (PSC) network, @@ -1435,28 +1460,29 @@ GMPLS defines RSVP-TE extensions in support for end-to-end GMPLS LSPs recovery in [RFC4872], and segment recovery in [RFC4873] . GMPLS segment recovery provides a superset of the function in end-to-end recovery. End-to-end recovery can be viewed as a special case of segment recovery where there is a single recovery domain whose borders coincide with the ingress and egress of the LSP, although specific procedures are defined. 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 [TP-SURVIVE], is signaled + Recovery for MPLS-TP LSPs, as discussed in [TP-SURVIVE], is signaled using the mechanism defined in [RFC4872] and [RFC4873]. Note that when MEPs are required for the OAM CC function and the MEPs exist at LSP transit nodes, each MEP is instantiated at a hierarchical LSP end point, and protection is provided end-to-end for the hierarchical LSP. (Protection can be signaled using either [RFC4872] or [RFC4873] defined procedures.) The use of Notify messages to trigger protection switching and recovery is not required in MPLS-TP as this function is expected to be supported via OAM. However, its use is not precluded. 4.1.10. Control Plane Reference Points (E-NNI, I-NNI, UNI) @@ -1466,22 +1492,22 @@ (I-NNI). In the MPLS-TP context, some operators may choose to deploy signaled interfaces across user-to-network (UNI) interfaces and across inter-provider, external network-to-network (E-NNI), interfaces. Such support is embodied in [RFC4208] for UNIs and [RFC5787] for routing areas in support of E-NNIs. This work may require extensions in order to meet the specific needs of an MPLS-TP UNI and E-NNI. 4.2. OAM, MEP (Hierarchy), MIP Configuration and Control - MPLS-TP is being defined to support a comprehensive set of MPLS-TP - OAM functions. The MPLS-TP control plane will not itself provide OAM + MPLS-TP is defined to support a comprehensive set of MPLS-TP OAM + functions. The MPLS-TP control plane will not itself provide OAM functions, but it will be used to instantiate and otherwise control MPLS-TP OAM functions. Specific OAM requirements for MPLS-TP are documented in [RFC5860]. This document also states that it is also 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 underway, e.g., [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT]. Many OAM functions occur on a per-LSP basis, are typically in-band, @@ -1492,22 +1518,25 @@ 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 (MIB), [TE- MIB]; the MPLS-TE MIB, [RFC3812]; the MPLS LSR MIB, [RFC3813]; the - GMPLS TE MIB [RFC4802]; and the GMPLS LSR MIB, [RFC4803]. These MIBs - may be used in MPLS-TP networks. + GMPLS TE MIB [RFC4802]; and the GMPLS LSR MIB, [RFC4803]. These MIB + modules may be used in MPLS-TP networks. A general overview of MPLS- + TP related MIB modules can be found in [TP-MIB]. Network management + requirements for MPLS-based transport networks are provided in + [RFC5951] 4.2.1.1. Recovery Triggers The GMPLS control plane allows for management plane recovery triggers and directly supports control plane recovery triggers. Support for control plane recovery triggers is defined in [RFC4872] which refers to the triggers as "Recovery Commands". These commands can be used with both end-to-end and segment recovery, but are always controlled on an end-to-end basis. The recovery triggers/commands defined in [RFC4872] are: @@ -1504,49 +1533,54 @@ 4.2.1.1. Recovery Triggers The GMPLS control plane allows for management plane recovery triggers and directly supports control plane recovery triggers. Support for control plane recovery triggers is defined in [RFC4872] which refers to the triggers as "Recovery Commands". These commands can be used with both end-to-end and segment recovery, but are always controlled on an end-to-end basis. The recovery triggers/commands defined in [RFC4872] are: + a. Lockout of recovery LSP + b. Lockout of normal traffic + c. Forced switch for normal traffic + d. Requested switch for normal traffic + e. Requested switch for recovery LSP Note that control plane triggers are typically invoked in response to a management plane request at the ingress. 4.2.1.2. Management Plane / Control Plane Ownership Transfer In networks where both control plane and management plane are - provided, LSP provisioning can be bone either by control plane or + provided, LSP provisioning can be done either by control plane or management plane. As mentioned in the requirements section above, it must be possible to transfer, or handover, a management plane created LSP to the control plane domain and vice versa. [RFC5493] defines 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 control plane LSP related operation, that is, it must be possible from the NMS to have a clear - view of the life, (traffic hit, action performed, signaling etc.) of + view of the life (traffic hit, action performed, signaling, etc.) of a given LSP. The LSP handover procedure for MPLS-TP LSPs is supported via [RFC5852]. 4.3. GMPLS and MPLS-TP Requirements Table The following table shows how the MPLS-TP control plane requirements can be met using the existing GMPLS control plane (which builds on the MPLS control plane). Areas where additional specifications are required are also identified. The table lists references based on the control plane requirements as identified and numbered above in @@ -1576,228 +1610,225 @@ | 18 | [RFC3945], [RFC4202] + proper vendor implementation | | 19 | [RFC3945], [RFC4202] | | 20 | [RFC3473] | | 21 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], | | | [RFC5151] | | 22 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], | | | [RFC5151] | | 23 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 24 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 25 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307], | - | | [HIERARCHY-BIS] | + | | [RFC6107] | | 26 | [RFC3473], [RFC4875] | | 27 | [RFC3473], [RFC4875] | | 28 | [RFC3945], [RFC3471], [RFC4202] | | 29 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 30 | [RFC3945], [RFC3471], [RFC4202] | | 31 | [RFC3945], [RFC3471], [RFC4202] | | 32 | [RFC4208], [RFC4974], [RFC5787], [RFC6001] | | 33 | [RFC3473], [RFC4875] | | 34 | [RFC4875] | | 35 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | | 36 | [RFC3473], [RFC3209] (Make-before-break) | | 37 | [RFC3473], [RFC3209] (Make-before-break) | | 38 | | - | 39 | [RFC4139], [RFC4258], [RFC5787] | - | 40 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | - | 41 | [RFC3473], [RFC5063] | - | 42 | [RFC3945], [RFC3471], [RFC4202], [RFC4208] | - | 43 | [RFC3945], [RFC3471], [RFC4202] | - | 44 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | - | 45 | [HIERARCHY-BIS], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | - | 46 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] | - | 47 | [RFC5493] | - | 48 | [RFC4872], [RFC4873] | - | 49 | [RFC3945], [RFC3471], [RFC4202] | - | 50 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) | - | 51 | [RFC4872], [RFC4873] | - | 52 | [RFC4872], [RFC4873] + proper vendor implementation | - | 53 | [RFC4872], [RFC4873], [GMPLS-PS] | - | 54 | [RFC4872], [RFC4873] | - | 55 | [RFC3473], [RFC4872], [RFC4873], [GMPLS-PS] | + | 38 | [RFC4139], [RFC4258], [RFC5787] | + | 39 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | + | 40 | [RFC3473], [RFC5063] | + | 41 | [RFC3945], [RFC3471], [RFC4202], [RFC4208] | + | 42 | [RFC3945], [RFC3471], [RFC4202] | + | 43 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | + | 44 | [RFC6107], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | + | 45 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] | + | 46 | [RFC5493] | + | 47 | [RFC4872], [RFC4873] | + | 48 | [RFC3945], [RFC3471], [RFC4202] | + | 49 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) | + | 50 | [RFC4872], [RFC4873] | + | 51 | [RFC4872], [RFC4873] + proper vendor implementation | + | 52 | [RFC4872], [RFC4873], [GMPLS-PS] | + | 53 | [RFC4872], [RFC4873] | + | 54 | [RFC3473], [RFC4872], [RFC4873], [GMPLS-PS] | | | Timers are a local implementation matter | - | 56 | [RFC4872], [RFC4873], [GMPLS-PS] + | + | 55 | [RFC4872], [RFC4873], [GMPLS-PS] + | | | implementation of timers | - | 57 | [RFC4872], [RFC4873], [GMPLS-PS] | + | 56 | [RFC4872], [RFC4873], [GMPLS-PS] | + | 57 | [RFC4872], [RFC4873] | | 58 | [RFC4872], [RFC4873] | | 59 | [RFC4872], [RFC4873] | - | 60 | [RFC4872], [RFC4873] | - | 61 | [RFC4872], [RFC4873], [HIERARCHY-BIS] | - | 62 | [RFC4872], [RFC4873] | - | 63 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) | + | 60 | [RFC4872], [RFC4873], [RFC6107] | + | 61 | [RFC4872], [RFC4873] | + | 62 | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) | + | 63 | [RFC4872], [RFC4873] | | 64 | [RFC4872], [RFC4873] | | 65 | [RFC4872], [RFC4873] | - | 66 | [RFC4872], [RFC4873] | - | 67 | [RFC4872], [RFC4873], [HIERARCHY-BIS] | - | 68 | [RFC4872], [RFC4873] | - | 69 | [RFC3473], [RFC4872], [RFC4873] | - | 70 | [RFC3473] | - | 71 | [RFC3473], [RFC4872], [GMPLS-PS] | - | 72 | [RFC3473], [RFC4872] | - | 73 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | + | 66 | [RFC4872], [RFC4873], [RFC6107] | + | 67 | [RFC4872], [RFC4873] | + | 68 | [RFC3473], [RFC4872], [RFC4873] | + | 69 | [RFC3473] | + | 70 | [RFC3473], [RFC4872], [GMPLS-PS] | + | 71 | [RFC3473], [RFC4872] | + | 72 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | + | 73 | [RFC4426], [RFC4872], [RFC4873] | | 74 | [RFC4426], [RFC4872], [RFC4873] | | 75 | [RFC4426], [RFC4872], [RFC4873] | | 76 | [RFC4426], [RFC4872], [RFC4873] | | 77 | [RFC4426], [RFC4872], [RFC4873] | - | 78 | [RFC4426], [RFC4872], [RFC4873] | - | 79 | [RFC4426], [RFC4872], [RFC4873] + vendor implementation | + | 78 | [RFC4426], [RFC4872], [RFC4873] + vendor implementation | + | 79 | [RFC4426], [RFC4872], [RFC4873] | | 80 | [RFC4426], [RFC4872], [RFC4873] | - | 81 | [RFC4426], [RFC4872], [RFC4873] | + | 81 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) | | 82 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) | | 83 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) | | 84 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) | - | 85 | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5) | - | 86 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | + | 85 | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | + | 86 | [RFC4872], [RFC4873] | | 87 | [RFC4872], [RFC4873] | - | 88 | [RFC4872], [RFC4873] | + | 88 | [RFC4872], [RFC4873], [TP-RING] | | 89 | [RFC4872], [RFC4873], [TP-RING] | - | 90 | [RFC4872], [RFC4873], [TP-RING] | - | 91 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) | - | 92 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | - | 93 | [RFC3945], [RFC3473], [RFC2210], [RFC2211], [RFC2212] | - | 94 | Generic requirement on data plane (correct implementation)| - | 95 | [RFC3473], [NO-PHP] | - | 96 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) | + | 90 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) | + | 91 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] | + | 92 | [RFC3945], [RFC3473], [RFC2210], [RFC2211], [RFC2212] | + | 93 | Generic requirement on data plane (correct implementation)| + | 94 | [RFC3473], [NO-PHP] | + | 95 | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) | + | 96 | PW only requirement, see PW Requirements Table (5.2) | | 97 | PW only requirement, see PW Requirements Table (5.2) | - | 98 | PW only requirement, see PW Requirements Table (5.2) | - | 99 | [RFC3945], [RFC3473], [HIERARCHY-BIS] | - | 100 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] + | + | 98 | [RFC3945], [RFC3473], [RFC6107] | + | 99 | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] + | | | [RFC5392] and [RFC5316] | - | 101 | PW only requirement, see PW Requirements Table (5.2) | - | 102 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] | - | 103 | [RFC4872], [RFC4873], [TP-RING] | - | 104 | [RFC3945], [RFC3473], [HIERARCHY-BIS] | - | 105 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | - | 106 | [RFC3473], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | - | 107 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | - | 108 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | - | 109 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | + | 100 | PW only requirement, see PW Requirements Table (5.2) | + | 101 | [RFC3473], [RFC4203], [RFC5307], [RFC5063] | + | 102 | [RFC4872], [RFC4873], [TP-RING] | + | 103 | [RFC3945], [RFC3473], [RFC6107] | + | 104 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | + | 105 | [RFC3473], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | + | 106 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | + | 107 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | + | 108 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | + | 109 | [RFC3473], [RFC4872], [RFC4873] | | 110 | [RFC3473], [RFC4872], [RFC4873] | - | 111 | [RFC3473], [RFC4872], [RFC4873] | - | 112 | [RFC3473], [RFC4783] | - | 113 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | + | 111 | [RFC3473], [RFC4783] | + | 112 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] | + | 113 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | | 114 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | - | 115 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | - | 116 | [RFC3473] | - | 117 | [RFC4426], [RFC4872], [RFC4873] | - | 118 | [RFC3473], [RFC4872], [RFC4873] | - | 119 | [RFC3473], [RFC4783] | - | 120 | [RFC3473] | - | 121 | [RFC3473], [RFC4783] | + | 115 | [RFC3473] | + | 116 | [RFC4426], [RFC4872], [RFC4873] | + | 117 | [RFC3473], [RFC4872], [RFC4873] | + | 118 | [RFC3473], [RFC4783] | + | 119 | [RFC3473] | + | 120 | [RFC3473], [RFC4783] | + | 121 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | | 122 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | - | 123 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | - | 124 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT], [HIERARCHY-BIS] | - | 125 - | | - | 136 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | + | 123 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT], [RFC6107] | + | 124 - | | + | 135 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5) | + | 136a | [RFC3473] | + | 136b | [RFC3473] + (See Sec. 4.4.7) | | 137a | [RFC3473] | | 137b | [RFC3473] + (See Sec. 4.4.7) | - | 138a | [RFC3473] | - | 138b | [RFC3473] + (See Sec. 4.4.7) | - | 139 | PW only requirement, see PW Requirements Table (5.2) | - | 140 - | | - | 144 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.8) | + | 138 | PW only requirement, see PW Requirements Table (5.2) | + | 139 - | | + | 143 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.8) | +=======+===========================================================+ + Table 1: GMPLS and MPLS-TP Requirements Table + 4.4. Anticipated MPLS-TP Related Extensions and Definitions This section identifies the extensions and other documents that have been identified as likely to be needed to support the full set of MPLS-TP control plane requirements. 4.4.1. MPLS-TE to MPLS-TP LSP Control Plane Interworking While no interworking function is expected in the data-plane to support the interconnection of MPLS-TE and MPLS-TP networking, this is not the case for the control plane. MPLS-TE networks typically use LSP signaling based on [RFC3209] while MPLS-TP LSPs will be - signaled using GMPLS RSVP-TE, i.e., [RFC3473]. The data plane of - - [RFC5145] identifies a set of solutions that are aimed to aid in the - interworking of MPLS-TE and GMPLS control planes. This work will - serve as the foundation for a formal definition of MPLS to MPLS-TP - control plane interworking. + signaled using GMPLS RSVP-TE, i.e., [RFC3473]. [RFC5145] identifies + a set of solutions that are aimed to aid in the interworking of MPLS- + TE and GMPLS control planes. [RFC5145] work will serve as the + foundation for a formal definition of MPLS to MPLS-TP control plane + interworking. 4.4.2. Associated Bidirectional LSPs GMPLS signaling, [RFC3473], supports unidirectional, and co-routed bidirectional point-to-point LSPs. MPLS-TP also requires support for associated bidirectional point-to-point LSPs. Such support will require an extension or a formal definition of how the LSP endpoints supporting an associated bidirectional service will coordinate the two LSPs used to provide such a service. Per requirement 11, transit nodes that support an associated bidirectional service should be aware of the association of the LSPs used to support the service when both LSPs are supported on that transit node. There are several existing protocol mechanisms on which to base such support, including, but not limited to: o GMPLS calls, [RFC4974]. o The ASSOCIATION object, [RFC4872]. - o The LSP_TUNNEL_INTERFACE_ID object, [HIERARCHY-BIS]. + o The LSP_TUNNEL_INTERFACE_ID object, [RFC6107]. 4.4.3. Asymmetric Bandwidth LSPs [RFC5467] defines support for bidirectional LSPs which have different (asymmetric) bandwidth requirements for each direction. This RFC can be used to meet the related MPLS-TP technical requirement, but this RFC is currently an Experimental RFC. To fully satisfy the MPLS-TP requirement this document will need to become a Standards Track RFC. 4.4.4. Recovery for P2MP LSPs The definitions of P2MP, [RFC4875], and GMPLS recovery, [RFC4872] and [RFC4873], do not explicitly cover their interactions. MPLS-TP requires a formal definition of recovery techniques for P2MP LSPs. Such a formal definition will be based on existing RFCs and may not - require any new protocol mechanisms, but nonetheless, must be + 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 works in progress that extend - the OAM related control capabilities of GMPLS. These extensions - cover a portion, 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 (if any) - OAM function(s) to use (including support to select experimental OAM - functions) and what OAM functionality to run, including, continuity - check (CC), connectivity verification (CV), packet loss and delay - quantification, and diagnostic testing of a service. As OAM - configuration is directly linked to data plane OAM, it is expected - that [CCAMP-OAM-EXT] will evolve in parallel with the specification - of data plane OAM functions. These documents do not yet cover the - implications of SPMEs, including both dynamic creation and dynamic - OAM function control. + [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT] are examples of OAM-related + control extensions to GMPLS. These extensions cover a portion, 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 (if any) OAM function(s) to + use (including support to select experimental OAM functions) and what + OAM functionality to run, including, continuity check (CC), + connectivity verification (CV), packet loss and delay quantification, + and diagnostic testing of a service. Such support may be included in + the listed documents or in other documents. 4.4.6. DiffServ Object usage in GMPLS - [RFC3270] and [RFC4124] define support for DiffServ enabled MPLS + [RFC3270] and [RFC4124] define support for DiffServ-enabled MPLS LSPs. While [RFC4124] references GMPLS signaling, there is no - explicit discussion on the use of the DiffServ related objects in + 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 [TP-IDENTIFIERS]. One form is based on existing GMPLS fields. The other form is based on either the globally unique Attachment Interface Identifier (AII) defined in [RFC5003], or the M.1400 defined the ITU Carrier Code (ICC). 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 + 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 @@ -1830,26 +1861,34 @@ 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 this latter case, a T-PE in a client network is a T-PE performing the adaptation of the native service to MPLS and an MPLS-TP network performs pseudowire switching. The SS-PW signaling control plane is based on targeted LDP (T-LDP) with specific procedures defined in [RFC4447]. The MS-PW signaling control plane is also based on T-LDP as allowed for in [RFC5659], - [SEGMENTED-PW] 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 + [RFC6073] and [MS-PW-DYNAMIC]. An MPLS-TP network shall use the same + PW signaling protocols and procedures for placing SS-PWs and MS-PWs. + This will leverage existing technology as well as facilitate interoperability with client networks with native attachment circuits or PW segments that are switched across an MPLS-TP network. +5.1.1. Management Plane Support + + There is no MPLS-TP requirement for a standardized management + interface to the MPLS-TP control plane. A general overview of MPLS- + TP related MIB modules can be found in [TP-MIB]. Network management + requirements for MPLS-based transport networks are provided in + [RFC5951]. + 5.2. PW Control (LDP) and MPLS-TP Requirements Table The following table shows how the MPLS-TP control plane requirements can be met using the existing LDP control plane for Pseudowires (targeted LDP). Areas where additional specifications are required are also identified. The table lists references based on the control plane requirements as identified and numbered above in section 2. 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. @@ -1879,102 +1918,103 @@ | 19-26 | [RFC3985], [RFC4447], [RFC5659], implementation | | 27 | [RFC4448], [RFC4816], [RFC4618], [RFC4619], [RFC4553] | | | [RFC4842], [RFC5287] | | 28 | [RFC3985] | | 29-31 | [RFC3985], [RFC4447] | | 32 | [RFC3985], [RFC4447], [RFC5659], See Section 5.3.6. | | 33 | [RFC4385], [RFC4447], [RFC5586] | | 34 | [PW-P2MPR], [PW-P2MPE] | | 35 | [RFC4863] | | 36-37 | [RFC3985], [RFC4447], See Section 5.3.4 | - | 38 | | - | 39 | Provided by TP-LSPs | - | 40 | [RFC3985], [RFC4447], + TP-LSPs | - | 41 | [RFC3478] | - | 42-43 | [RFC3985], [RFC4447] | - | 44-45 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.5 | - | 46 | [RFC3985], [RFC4447], [RFC5659] + TP-LSPs | - | 47 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.3 | - | 48 | [PW-RED], [PW-REDB] | - | 49-50 | [RFC3985], [RFC4447], + TP-LSPs, implementation | - | 51-53 | Provided by TP-LSPs, and Section 5.3.5 | - | 54-56 | [RFC3985], [RFC4447], See Section 5.3.5 | - | 57 | [PW-RED], [PW-REDB] | + | 38 | Provided by TP-LSPs | + | 39 | [RFC3985], [RFC4447], + TP-LSPs | + | 40 | [RFC3478] | + | 41-42 | [RFC3985], [RFC4447] | + | 43-44 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.5 | + | 45 | [RFC3985], [RFC4447], [RFC5659] + TP-LSPs | + | 46 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.3 | + | 47 | [PW-RED], [PW-REDB] | + | 48-49 | [RFC3985], [RFC4447], + TP-LSPs, implementation | + | 50-52 | Provided by TP-LSPs, and Section 5.3.5 | + | 53-55 | [RFC3985], [RFC4447], See Section 5.3.5 | + | 56 | [PW-RED], [PW-REDB] | | | revertive/non-revertive behavior is a local matter for PW | - | 58-59 | [PW-RED], [PW-REDB] | - | 60-82 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 | - | 83-84 | [RFC5085], [RFC5586], [RFC5885] | - | 85-90 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 | - | 91-96 | [RFC3985], [RFC4447], + TP-LSPs, implementation | - | 97 | [RFC4447], [MS-PW-DYNAMIC] | - | 98 | [RFC4447] | - | 99 - | | - | 100 | Not Applicable to PW | - | 101 | [RFC4447] | - | 102 | [RFC3478] | - | 103 | [RFC3985], + TP-LSPs | - | 104 | Not Applicable to PW | + | 57-58 | [PW-RED], [PW-REDB] | + | 59-81 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 | + | 82-83 | [RFC5085], [RFC5586], [RFC5885] | + | 84-89 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 | + | 90-95 | [RFC3985], [RFC4447], + TP-LSPs, implementation | + | 96 | [RFC4447], [MS-PW-DYNAMIC] | + | 97 | [RFC4447] | + | 98 - | | + | 99 | Not Applicable to PW | + | 100 | [RFC4447] | + | 101 | [RFC3478] | + | 102 | [RFC3985], + TP-LSPs | + | 103 | Not Applicable to PW | + | 104 | [PW-OAM] | | 105 | [PW-OAM] | - | 106 | [PW-OAM] | - | 107 - | | + | 106 - | | + | 108 | [RFC5085], [RFC5586], [RFC5885] | | 109 | [RFC5085], [RFC5586], [RFC5885] | - | 110 | [RFC5085], [RFC5586], [RFC5885] | | | fault reporting and protection triggering is a local | | | matter for PW | - | 111 | [RFC5085], [RFC5586], [RFC5885] | + | 110 | [RFC5085], [RFC5586], [RFC5885] | | | fault reporting and protection triggering is a local | | | matter for PW | - | 112 | [RFC4447] | - | 113 | [RFC4447], [RFC5085], [RFC5586], [RFC5885] | + | 111 | [RFC4447] | + | 112 | [RFC4447], [RFC5085], [RFC5586], [RFC5885] | + | 113 | [RFC5085], [RFC5586], [RFC5885] | | 114 | [RFC5085], [RFC5586], [RFC5885] | - | 115 | [RFC5085], [RFC5586], [RFC5885] | - | 116 | path traversed by PW is determined by LSP path, see | + | 115 | path traversed by PW is determined by LSP path, see | | | GMPLS and MPLS-TP Requirements Table, 4.3 | - | 117 | [PW-RED], [PW-REDB], administrative control of redundant | + | 116 | [PW-RED], [PW-REDB], administrative control of redundant | | | PW is a local matter at the PW head-end | - | 118 | [PW-RED], [PW-REDB], [RFC5085], [RFC5586], [RFC5885] | - | 119 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 | - | 120 | [RFC4447] | - | 121 - | | - | 126 | [RFC5085], [RFC5586], [RFC5885] | - | 127 - | | - | 131 | [PW-OAM] | - | 132 | Section 5.3.5 | + | 117 | [PW-RED], [PW-REDB], [RFC5085], [RFC5586], [RFC5885] | + | 118 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5 | + | 119 | [RFC4447] | + | 120 - | | + | 125 | [RFC5085], [RFC5586], [RFC5885] | + | 126 - | | + | 130 | [PW-OAM] | + | 131 | Section 5.3.5 | + | 132 | [PW-OAM] | | 133 | [PW-OAM] | - | 134 | [PW-OAM] | - | 135 | Section 5.3.5 | - | 136 | [PW-OAM] | + | 134 | Section 5.3.5 | + | 135 | [PW-OAM] | + | 136 | Not Applicable to PW | | 137 | Not Applicable to PW | - | 138 | Not Applicable to PW | - | 139 | [RFC4447], [RFC5003], [MS-PW-DYNAMIC] | - | 140 - | | - | 144 | [PW-OAM] | + | 138 | [RFC4447], [RFC5003], [MS-PW-DYNAMIC] | + | 139 - | | + | 143 | [PW-OAM] | +=======+===========================================================+ + Table 2: PW Control (LDP) and MPLS-TP Requirements Table + 5.3. Anticipated MPLS-TP Related Extensions - The same control protocol and procedures will be reused as much as - possible. However, when using PWs in MPLS-TP, a set of new - requirements are defined which may require extensions of the existing - control mechanisms. This section clarifies the areas where extensions - are needed based on the PW Control Plane related requirements - documented in [RFC5654]. + 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 are defined which may require extensions of + the existing control mechanisms. This section clarifies the areas + where extensions are needed based on the PW Control Plane related + requirements documented in [RFC5654]. - See the table in the section above for a list of how requirements - defined in [RFC5654] are expected to be addressed. + Table 2 lists how requirements defined in [RFC5654] are expected to + be addressed. The baseline requirement for extensions to support transport applications is that any new mechanisms and capabilities must be able to interoperate with existing IETF MPLS [RFC3031] and IETF PWE3 [RFC3985] control and data planes where appropriate. Hence, extensions of the PW Control Plane must be in-line with the - procedures defined in [RFC4447], [SEGMENTED-PW] and [MS-PW-DYNAMIC]. + procedures defined in [RFC4447], [RFC6073] and [MS-PW-DYNAMIC]. 5.3.1. Extensions to Support Out-of-Band PW Control For MPLS-TP, it is required that the data and control planes can be both logically and physically separated. That is, the PW Control Plane must be able to operate out-of-band (OOB). This separation ensures, among other things, that in the case of control plane failures the data plane is not affected and can continue to operate normally. This was not a design requirement for the current PW Control Plane. However, due to the PW concept, i.e., PWs are @@ -2002,33 +2042,29 @@ 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 signal initiation end to inform the targeted LSR (at the signal termination end) which LSP the resulting PW is to be bound to, 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. - If the control plane is physically separated from the forwarder, the - control plane must be able to program the forwarders with necessary - information. - - For transport services, it may be required that bidirectional traffic - 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, S-PEs, or a T-PE and an S-PE. The unidirectional LSPs in both - directions are not required to follow congruent paths, and therefore - both directions of a PW may not follow congruent paths, i.e., they - are associated bidirectional paths. The only requirement in [RFC5659] - is that a PW or a PW segment shares the same T-PEs in both - directions, and same S-PEs in both directions. + For transport services, MPLS-TP requires support for bidirectional + traffic which 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, S-PEs, or a T-PE and an S-PE. The unidirectional + LSPs in both directions are not required to follow congruent paths, + and therefore both directions of a PW may not follow congruent paths, + i.e., they are associated bidirectional paths. The only requirement + in [RFC5659] is that a PW or a PW segment shares the same T-PEs in + both directions, and 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 @@ -2085,32 +2121,32 @@ REDB] that define - respectively - how to establish redundant Pseudowires and how to indicate which is in use. Additional work may be required. Protection switching may be triggered manually by the operator, or as a result of loss of connectivity (detected using the mechanisms of [RFC5085] and [RFC5586]), or service degradation (detected using mechanisms yet to be defined). Automated protection switching is just one of the functions for which - a transport service require OAM. OAM is generally referred to as + 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 is only used - either a limited number of times, or over a short period of time - when explicitly enabled (for diagnostics, for example). PW OAM currently consists of connectivity verification defined by [RFC5085]. Work is currently in progress to extend PW OAM to include bidirectional forwarding detection (BFD) in [RFC5885], and work has - begun on extending BFD to include performance related monitor + 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 @@ -2134,22 +2170,24 @@ - 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 - security issues, see the MPLS/GMPLS security framework [RFC5920]. + sections. For a general discussion on MPLS- and GMPLS-related + security issues, see the MPLS/GMPLS security framework [RFC5920]. As + mentioned above in Section 2.4., there are no specific MPLS-TP + control plane security requirements. This document also identifies a number of needed control plane extensions. It is expected that the documents that define such extensions will also include any appropriate security considerations. 7. IANA Considerations There are no new IANA considerations introduced by this document. 8. Acknowledgments @@ -2294,22 +2332,23 @@ [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., Berger, L., "A Framework for MPLS in Transport Networks", RFC 5921, July 2010. [RFC5960] Frost, D., Bryant, S., Bocci, M., "MPLS Transport Profile Data Plane Architecture", RFC 5960, August 2010. [TP-IDENTIFIERS] Bocci, M., Swallow, G., "MPLS-TP Identifiers", work in progress, draft-ietf-mpls-tp-identifiers. - [TP-OAM] Busi, I., Ed., Niven-Jenkins, B., Ed., "MPLS-TP OAM - Framework and Overview", work in progress, + [TP-OAM] Busi, I., Ed., Allan, D., Ed., "Operations, + Administration and Maintenance Framework for MPLS-based + Transport Networks", work in progress, draft-ietf-mpls-tp-oam-framework. [TP-SURVIVE] Sprecher, N., et al., "Multiprotocol Label Switching Transport Profile Survivability Framework", work in progress, draft-ietf-mpls-tp-survive-fwk. 9.2. Informative References [CCAMP-OAM-FWK] A. Takacs, D. Fedyk, and J. He, "OAM Configuration Framework and Requirements for GMPLS RSVP-TE", @@ -2318,25 +2357,20 @@ [CCAMP-OAM-EXT] Bellagamba, E., et.al., "RSVP-TE Extensions for MPLS-TP OAM Configuration", work in progress, draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext. [GMPLS-PS] Takacs, A., et al, "GMPLS RSVP-TE Recovery Extension for data plane initiated reversion and protection timer signalling", work in progress, draft-takacs-ccamp-revertive-ps. - [HIERARCHY-BIS] Shiomoto, K, Ed., Farrel, A, Ed., "Procedures for - Dynamically Signaled Hierarchical Label Switched - Paths", work in progress, - draft-ietf-ccamp-lsp-hierarchy-bis. - [TE-MIB] T Otani, et.al., "Traffic Engineering Database Management Information Base in support of MPLS-TE/GMPLS", work in progress, draft-ietf-ccamp-gmpls-ted-mib. [MS-PW-DYNAMIC] L. Martini, M Bocci, and F Balus "Dynamic Placement of Multi Segment Pseudo Wires", work in progress, draft-ietf-pwe3-dynamic-ms-pw. [ITU.G8080.2006] International Telecommunications Union, "Architecture for the automatically switched @@ -2368,20 +2402,24 @@ draft-raggarwa-pwe3-p2mp-pw-encaps. [PW-P2MPR] Jounay, F., et al, "Requirements for Point-to-Multipoint Pseudowire", work in progress, draft-ietf-pwe3-p2mp-pw-requirements. [RFC3270] Le Faucheur, F., et al, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002. + [RFC3468] Andersson, L., Swallow, G., "The Multiprotocol Label + Switching (MPLS) Working Group decision on MPLS + signaling protocols", RFC 3468, February 2003. + [RFC3472] Ashwood-Smith, P., Ed, Berger, L. Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003. [RFC3477] Kompella, K., Rekhter, Y., "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. [RFC3478] Leelanivas, M., Rekhter, Y., Aggarwal, R., "Graceful @@ -2516,36 +2554,52 @@ Label Switched Paths (LSPs)", RFC 5884, June 2010. [RFC5885] Nadeau, T. and C. Pignataro, "Bidirectional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV)", RFC 5885, June 2010. [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. + [RFC5951] Lam, K., Mansfield, S., Gray, E., "Network Management + Requirements for MPLS-based Transport Networks", RFC + 5951, September 2010. + [RFC6001] Papadimitriou, D., et al, "Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 6001, October 2010. - [SEGMENTED-PW] Martini, L., Nadeau, T., and Duckett M., "Segmented - Pseaudowire", work in progress, - draft-ietf-pwe3-segmented-pw. + [RFC6073] Martini, L., Metz, C., Nadeau, T., Bocci, M., Aissaoui, M., + "Segmented Pseudowire", RFC 6073, January 2011. + + [RFC6107] Shiomoto, K., Farrel, A., "Procedures for Dynamically + Signaled Hierarchical Label Switched Paths", RFC 6107, + February 2011. + + [TP-MIB] Farrel, A., King, D., Mahalingam, V., Ryoo, J., Koushik, + K., "Multiprotocol Label Switching Transport Profile + (MPLS-TP) MIB-based Management Overview", work in + progress, draft-ietf-mpls-tp-mib-management-overview. [TP-P2MP-FWK] D. Frost, M. Bocci, and L. Berger, "A Framework for Point-to-Multipoint MPLS in Transport Networks", draft-fbb-mpls-tp-p2mp-framework. [TP-RING] Weingarten, Y., Ed., "MPLS-TP Ring Protection", work in progress, draft-weingarten-mpls-tp-ring-protection. + [TP-UNI] Bocci, M., Levrau, L., Frost, D., "MPLS Transport Profile + User-to-Network and Network-to-Network Interfaces", work + in progress, draft-ietf-mpls-tp-uni-nni. + 10. 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 @@ -2580,11 +2633,11 @@ Martin Vigoureux Alcatel-Lucent Email: martin.vigoureux@alcatel-lucent.fr Elisa Bellagamba Ericsson Farogatan, 6 164 40, Kista, Stockholm, SWEDEN Email: elisa.bellagamba@ericsson.com -Generated on: Fri, Jan 07, 2011 2:44:55 PM +Generated on: Thu, Feb 10, 2011 9:01:05 AM