--- 1/draft-ietf-ccamp-mpls-tp-cp-framework-03.txt 2010-11-22 15:16:37.000000000 +0100 +++ 2/draft-ietf-ccamp-mpls-tp-cp-framework-04.txt 2010-11-22 15:16:37.000000000 +0100 @@ -1,34 +1,33 @@ Internet Draft Loa Andersson, Ed. (Ericsson) Category: Informational Lou Berger, Ed. (LabN) -Expiration Date: April 15, 2011 Luyuan Fang, Ed. (Cisco) +Expiration Date: May 19, 2011 Luyuan Fang, Ed. (Cisco) Nabil Bitar, Ed. (Verizon) Eric Gray, Ed. (Ericsson) - October 15, 2010 + November 19, 2010 MPLS-TP Control Plane Framework - draft-ietf-ccamp-mpls-tp-cp-framework-03.txt + draft-ietf-ccamp-mpls-tp-cp-framework-04.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 control plane for Pseudowires (PWs). Management plane - functions such as manual configuration and the initiation of LSP - setup are out of scope of this document. + 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 @@ -52,21 +51,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 April 15, 2011 + This Internet-Draft will expire on May 19, 2011 Copyright and License Notice Copyright (c) 2010 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 @@ -85,51 +84,51 @@ 2 Control Plane Requirements ............................. 9 2.1 Primary Requirements ................................... 9 2.2 MPLS-TP Framework Derived Requirements ................. 18 2.3 OAM Framework Derived Requirements ..................... 19 2.4 Security Requirements .................................. 24 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 ............................................. 27 + 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 .......................................... 29 - 4.1.8 Hierarchical LSPs ...................................... 29 + 4.1.8 Hierarchical LSPs ...................................... 30 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 ............................... 31 - 4.3 GMPLS and MPLS-TP Requirements Table ................... 32 + 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 .............................. 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 ......................... 37 - 4.4.7 Support for MPLS-TP LSP Identifiers .................... 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.2 PW Control (LDP) and MPLS-TP Requirements Table ........ 39 5.3 Anticipated MPLS-TP Related Extensions ................. 41 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.3 Support for Dynamic Transfer of PW Control/Ownership ... 43 5.3.4 Interoperable Support for PW/LSP Resource Allocation ... 43 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 @@ -166,21 +165,21 @@ 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. 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 document scope the approaches and protocols that are the + 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. @@ -213,24 +212,24 @@ and ISIS-TE [RFC5307][RFC5316]. 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 GMPLS control plane may be required in order - to fully automate MPLS-TP LSP related functions. - 8) Control plane software upgrades to existing (G)MPLS enabled - equipment is acceptable and expected. + 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]. @@ -581,21 +580,23 @@ 46. 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 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]. + 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 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 @@ -827,29 +828,30 @@ 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 is based on the GMPLS control plane - for MPLS-TP LSPs. 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 + 100. The MPLS-TP control plane for LSPs is 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 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., paragraph 5]. + 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., + paragraph 5]. 102. 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 protection schemes [RFC5921, section 3.12., paragraph 3]. 104. The MPLS-TP control plane must support the control of SPMEs @@ -1251,21 +1253,21 @@ This term is used to refer to the cases where control plane traffic is sent using a different communication channel from the associated data or management traffic, and the control traffic follows the same node-to-node path as either the data or management traffic. Such topologies are usually supported using a parallel fiber or other configurations where multiple data channels are available and one is (dynamically) selected as the control channel. An example of this case in the context of MPLS-TP is where control - plane traffic is sent along the same node pairs, but not + plane traffic is sent along the same nodal path, but not necessarily the same links (interfaces), as the corresponding controlled user traffic. o Out-of-band, independent topology This term is used to refer to the cases where control plane traffic is sent using a different communication channel from the associated data or management traffic, and the control traffic may follow a path that is completely independent of the data traffic. @@ -1682,21 +1685,21 @@ +=======+===========================================================+ 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-lane to + 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. @@ -2564,11 +2567,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, Oct 15, 2010 2:54:52 PM +Generated on: Thu, Nov 18, 2010 10:42:13 AM