GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6373

Internet Engineering Task Force (IETF) L. Andersson, Ed. Request for Comments: 6373 Ericsson Category: Informational L. Berger, Ed. ISSN: 2070-1721 LabN

                                                          L. Fang, Ed.
                                                                 Cisco
                                                         N. Bitar, Ed.
                                                               Verizon
                                                          E. Gray, Ed.
                                                              Ericsson
                                                        September 2011
      MPLS Transport Profile (MPLS-TP) Control Plane Framework

Abstract

 The MPLS Transport Profile (MPLS-TP) supports static provisioning of
 transport paths via a Network Management System (NMS) and dynamic
 provisioning of transport paths via a control plane.  This document
 provides the framework for MPLS-TP dynamic provisioning and covers
 control-plane addressing, routing, path computation, signaling,
 traffic engineering, and path recovery.  MPLS-TP uses GMPLS as the
 control plane for MPLS-TP Label Switched Paths (LSPs).  MPLS-TP also
 uses the pseudowire (PW) control plane for pseudowires.  Management-
 plane functions are out of scope of this document.
 This document is a product of a joint Internet Engineering Task Force
 (IETF) / International Telecommunication Union Telecommunication
 Standardization Sector (ITU-T) effort to include an MPLS Transport
 Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
 (PWE3) architectures to support the capabilities and functionalities
 of a packet transport network as defined by the ITU-T.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.

Andersson, et al. Informational [Page 1] RFC 6373 MPLS-TP Control Plane Framework September 2011

 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6373.

Copyright Notice

 Copyright (c) 2011 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1. Introduction ....................................................3
    1.1. Scope ......................................................4
    1.2. Basic Approach .............................................4
    1.3. Reference Model ............................................6
 2. Control-Plane Requirements ......................................9
    2.1. Primary Requirements .......................................9
    2.2. Requirements Derived from the MPLS-TP Framework ...........18
    2.3. Requirements Derived from the OAM Framework ...............20
    2.4. Security Requirements .....................................25
    2.5. Identifier Requirements ...................................25
 3. Relationship of PWs and TE LSPs ................................26
 4. TE LSPs ........................................................27
    4.1. GMPLS Functions and MPLS-TP LSPs ..........................27
         4.1.1. In-Band and Out-of-Band Control ....................27
         4.1.2. Addressing .........................................29
         4.1.3. Routing ............................................29
         4.1.4. TE LSPs and Constraint-Based Path Computation ......29
         4.1.5. Signaling ..........................................30
         4.1.6. Unnumbered Links ...................................30
         4.1.7. Link Bundling ......................................30
         4.1.8. Hierarchical LSPs ..................................31
         4.1.9. LSP Recovery .......................................31
         4.1.10. Control-Plane Reference Points (E-NNI,
                 I-NNI, UNI) .......................................32
    4.2. OAM, MEP (Hierarchy), MIP Configuration and Control .......32
         4.2.1. Management-Plane Support ...........................33
    4.3. GMPLS and MPLS-TP Requirements Table ......................34

Andersson, et al. Informational [Page 2] RFC 6373 MPLS-TP Control Plane Framework September 2011

    4.4. Anticipated MPLS-TP-Related Extensions and Definitions ....37
         4.4.1. MPLS-TE to MPLS-TP LSP Control-Plane Interworking ..37
         4.4.2. Associated Bidirectional LSPs ......................38
         4.4.3. Asymmetric Bandwidth LSPs ..........................38
         4.4.4. Recovery for P2MP LSPs .............................38
         4.4.5. Test Traffic Control and Other OAM Functions .......38
         4.4.6. Diffserv Object Usage in GMPLS .....................39
         4.4.7. Support for MPLS-TP LSP Identifiers ................39
         4.4.8. Support for MPLS-TP Maintenance Identifiers ........39
 5. Pseudowires ....................................................39
    5.1. LDP Functions and Pseudowires .............................39
         5.1.1. Management-Plane Support ...........................40
    5.2. PW Control (LDP) and MPLS-TP Requirements Table ...........40
    5.3. Anticipated MPLS-TP-Related Extensions ....................44
         5.3.1. Extensions to Support Out-of-Band PW Control .......44
         5.3.2. Support for Explicit Control of PW-to-LSP Binding ..45
         5.3.3. Support for Dynamic Transfer of PW
                Control/Ownership ..................................45
         5.3.4. Interoperable Support for PW/LSP Resource
                Allocation .........................................46
         5.3.5. Support for PW Protection and PW OAM
                Configuration ......................................46
         5.3.6. Client Layer and Cross-Provider Interfaces
                to PW Control ......................................47
    5.4. ASON Architecture Considerations ..........................47
 6. Security Considerations ........................................47
 7. Acknowledgments ................................................48
 8. References .....................................................48
    8.1. Normative References ......................................48
    8.2. Informative References ....................................51
 9. Contributing Authors ...........................................56

1. Introduction

 The Multiprotocol Label Switching Transport Profile (MPLS-TP) is
 defined as a joint effort between the International Telecommunication
 Union (ITU) and the IETF.  The requirements for MPLS-TP are defined
 in the requirements document, see [RFC5654].  These requirements
 state that "A solution MUST be defined to support dynamic
 provisioning of MPLS-TP transport paths via a control plane".  This
 document provides the framework for such dynamic provisioning.  This
 document is a product of a joint Internet Engineering Task Force
 (IETF) / International Telecommunication Union Telecommunication
 Standardization Sector (ITU-T) effort to include an MPLS Transport
 Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
 (PWE3) architectures to support the capabilities and functions of a
 packet transport network as defined by the ITU-T.

Andersson, et al. Informational [Page 3] RFC 6373 MPLS-TP Control Plane Framework September 2011

1.1. Scope

 This document covers the control-plane functions involved in
 establishing MPLS-TP Label Switched Paths (LSPs) and pseudowires
 (PWs).  The control-plane requirements for MPLS-TP are defined in the
 MPLS-TP requirements document [RFC5654].  These requirements define
 the role of the control plane in MPLS-TP.  In particular, Section 2.4
 of [RFC5654] and portions of the remainder of Section 2 of [RFC5654]
 provide specific control-plane requirements.
 The LSPs provided by MPLS-TP are used as a server layer for IP, MPLS,
 and PWs, as well as other tunneled MPLS-TP LSPs.  The PWs are used to
 carry client signals other than IP or MPLS.  The relationship between
 PWs and MPLS-TP LSPs is exactly the same as between PWs and MPLS LSPs
 in an MPLS Packet Switched Network (PSN).  The PW encapsulation over
 MPLS-TP LSPs used in MPLS-TP networks is also the same as for PWs
 over MPLS in an MPLS network.  MPLS-TP also defines protection and
 restoration (or, collectively, recovery) functions; see [RFC5654] and
 [RFC4427].  The MPLS-TP control plane provides methods to establish,
 remove, and control MPLS-TP LSPs and PWs.  This includes control of
 Operations, Administration, and Maintenance (OAM), data-plane, and
 recovery functions.
 A general framework for MPLS-TP has been defined in [RFC5921], and a
 survivability framework for MPLS-TP has been defined in [RFC6372].
 These documents scope the approaches and protocols that are the
 foundation of MPLS-TP.  Notably, Section 3.5 of [RFC5921] scopes the
 IETF protocols that serve as the foundation of the MPLS-TP control
 plane.  The PW control plane is based on the existing PW control
 plane (see [RFC4447]) and the PWE3 architecture (see [RFC3985]).  The
 LSP control plane is based on GMPLS (see [RFC3945]), which is built
 on MPLS Traffic Engineering (TE) and its numerous extensions.
 [RFC6372] focuses on the recovery functions that must be supported
 within MPLS-TP.  It does not specify which control-plane mechanisms
 are to be used.
 The remainder of this document discusses the impact of the MPLS-TP
 requirements on the GMPLS signaling and routing protocols that are
 used to control MPLS-TP LSPs, and on the control of PWs as specified
 in [RFC4447], [RFC6073], and [MS-PW-DYNAMIC].

1.2. Basic Approach

 The basic approach taken in defining the MPLS-TP control-plane
 framework includes the following:
    1) MPLS technology as defined by the IETF is the foundation for
       the MPLS Transport Profile.

Andersson, et al. Informational [Page 4] RFC 6373 MPLS-TP Control Plane Framework September 2011

    2) The data plane for MPLS-TP is a standard MPLS data plane
       [RFC3031] as profiled in [RFC5960].
    3) MPLS PWs are used by MPLS-TP including the use of targeted
       Label Distribution Protocol (LDP) as the foundation for PW
       signaling [RFC4447].  This also includes the use of Open
       Shortest Path First with Traffic Engineering (OSPF-TE),
       Intermediate System to Intermediate System (IS-IS) with Traffic
       Engineering (ISIS-TE), or Multiprotocol Border Gateway Protocol
       (MP-BGP) as they apply for Multi-Segment Pseudowire (MS-PW)
       routing.  However, the PW can be encapsulated over an MPLS-TP
       LSP (established using methods and procedures for MPLS-TP LSP
       establishment) in addition to the presently defined methods of
       carrying PWs over LSP-based PSNs.  That is, the MPLS-TP domain
       is a PSN from a PWE3 architecture perspective [RFC3985].
    4) The MPLS-TP LSP control plane builds on the GMPLS control plane
       as defined by the IETF for transport LSPs.  The protocols
       within scope are Resource Reservation Protocol with Traffic
       Engineering (RSVP-TE) [RFC3473], OSPF-TE [RFC4203] [RFC5392],
       and ISIS-TE [RFC5307] [RFC5316].  Automatically Switched
       Optical Network (ASON) signaling and routing requirements in
       the context of GMPLS can be found in [RFC4139] and [RFC4258].
    5) Existing IETF MPLS and GMPLS RFCs and evolving Working Group
       Internet-Drafts should be reused wherever possible.
    6) If needed, extensions for the MPLS-TP control plane should
       first be based on the existing and evolving IETF work, and
       secondly be based on work by other standard bodies only when
       IETF decides that the work is out of the IETF's scope.  New
       extensions may be defined otherwise.
    7) Extensions to the control plane may be required in order to
       fully automate functions related to MPLS-TP LSPs and PWs.
    8) Control-plane software upgrades to existing equipment are
       acceptable and expected.
    9) It is permissible for functions present in the GMPLS and PW
       control planes to not be used in MPLS-TP networks.
   10) One possible use of the control plane is to configure, enable,
       and generally control OAM functionality.  This will require
       extensions to existing control-plane specifications that will
       be usable in MPLS-TP as well as MPLS networks.

Andersson, et al. Informational [Page 5] RFC 6373 MPLS-TP Control Plane Framework September 2011

   11) The foundation for MPLS-TP control-plane requirements is
       primarily found in Section 2.4 of [RFC5654] and relevant
       portions of the remainder of Section 2 of [RFC5654].

1.3. Reference Model

 The control-plane reference model is based on the general MPLS-TP
 reference model as defined in the MPLS-TP framework [RFC5921] and
 further refined in [RFC6215] on the MPLS-TP User-to-Network and
 Network-to-Network Interfaces (UNI and NNI, respectively).  Per the
 MPLS-TP framework [RFC5921], the MPLS-TP control plane is based on
 GMPLS with RSVP-TE for LSP signaling and targeted LDP for PW
 signaling.  In both cases, OSPF-TE or ISIS-TE with GMPLS extensions
 is used for dynamic routing within an MPLS-TP domain.
 Note that in this context, "targeted LDP" (or T-LDP) means LDP as
 defined in RFC 5036, using Targeted Hello messages.  See Section
 2.4.2 ("Extended Discovery Mechanism") of [RFC5036].  Use of the
 extended discovery mechanism is specified in Section 5 ("LDP") of
 [RFC4447].
 From a service perspective, MPLS-TP client services may be supported
 via both PWs and LSPs.  PW client interfaces, or adaptations, are
 defined on an interface-technology basis, e.g., Ethernet over PW
 [RFC4448].  In the context of MPLS-TP LSP, the client interface is
 provided at the network layer and may be controlled via a GMPLS-based
 UNI, see [RFC4208], or statically provisioned.  As discussed in
 [RFC5921] and [RFC6215], MPLS-TP also presumes an NNI reference
 point.
 The MPLS-TP end-to-end control-plane reference model is shown in
 Figure 1.  The figure shows the control-plane protocols used by MPLS-
 TP, as well as the UNI and NNI reference points, in the case of a
 Single-Segment PW supported by an end-to-end LSP without any
 hierarchical LSPs.  (The MS-PW case is not shown.)  Each service
 provider node's participation in routing and signaling (both GMPLS
 RSVP-TE and PW LDP) is represented.  Note that only the service end
 points participate in PW LDP signaling, while all service provider
 nodes participate in GMPLS TE LSP routing and signaling.

Andersson, et al. Informational [Page 6] RFC 6373 MPLS-TP Control Plane Framework September 2011

     |< ---- client signal (e.g., IP / MPLS / L2) -------- >|
       |< --------- SP1 ---------- >|< ------- SP2 ----- >|
         |< ---------- MPLS-TP End-to-End PW --------- >|
           |< -------- MPLS-TP End-to-End LSP ------ >|
 +---+   +---+  +---+  +---+  +---+   +---+  +---+  +---+   +---+
 |CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2|
 +---+   +---+  +---+  +---+  +---+   +---+  +---+  +---+   +---+
      UNI                          NNI                   UNI
 GMPLS
  TE-RTG,  |<-----|------|------|-------|------|----->|
  & RSVP-TE
 PW LDP   |< ---------------------------------------- >|
  Figure 1.  End-to-End MPLS-TP Control-Plane Reference Model
   Legend:
        CE:            Customer Edge
        Client signal: defined in MPLS-TP Requirements
        L2:            Any layer 2 signal that may be carried
                       over a PW, e.g., Ethernet
        NNI:           Network-to-Network Interface
        P:             Provider
        PE:            Provider Edge
        SP:            Service Provider
        TE-RTG:        GMPLS OSPF-TE or ISIS-TE
        UNI:           User-to-Network Interface
   Note: The MS-PW case is not shown.
 Figure 2 adds three hierarchical LSP segments, labeled as "H-LSPs".
 These segments are present to support scaling, OAM, and Maintenance
 Entity Group End Points (MEPs), see [RFC6371], within each provider
 domain and across the inter-provider NNI.  (H-LSPs are used to
 implement Sub-Path Maintenance Elements (SPMEs) as defined in
 [RFC5921].)  The MEPs are used to collect performance information,
 support diagnostic and fault management functions, and support OAM
 triggered survivability schemes as discussed in [RFC6372].  Each
 H-LSP may be protected or restored using any of the schemes discussed
 in [RFC6372].  End-to-end monitoring is supported via MEPs at the
 end-to-end LSP and PW end points.  Note that segment MEPs may be co-
 located with MIPs of the next higher-layer (e.g., end-to-end) LSPs.
 (The MS-PW case is not shown.)

Andersson, et al. Informational [Page 7] RFC 6373 MPLS-TP Control Plane Framework September 2011

     |< ------- client signal (e.g., IP / MPLS / L2) ----- >|
       |< -------- SP1 ----------- >|< ------- SP2 ----- >|
         |< ----------- MPLS-TP End-to-End PW -------- >|
           |< ------- MPLS-TP End-to-End LSP ------- >|
           |< -- H-LSP1 ---- >|<-H-LSP2->|<- H-LSP3 ->|
 +---+   +---+  +---+  +---+  +---+   +---+  +---+  +---+   +---+
 |CE1|-|-|PE1|--|P1 |--|P2 |--|PE2|-|-|PEa|--|Pa |--|PEb|-|-|CE2|
 +---+   +---+  +---+  +---+  +---+   +---+  +---+  +---+   +---+
      UNI                          NNI                   UNI
         .....                                      .....
 End2end |MEP|--------------------------------------|MEP|
 PW OAM  '''''                                      '''''
         .....                .....   .....         .....
 End2end |MEP|----------------|MIP|---|MIP|---------|MEP|
 LSP OAM '''''                '''''   '''''         '''''
         ..... ..... ..... ......... ......... ..... .....
 Segment |MEP|-|MIP|-|MIP|-|MEP|MEP|-|MEP|MEP|-|MIP|-|MEP|
 LSP OAM ''''' ''''' ''''' ''''''''' ''''''''' ''''' '''''
 H-LSP GMPLS
  TE-RTG   |<-----|------|----->||<---->||<-----|----->|
  &RSVP-TE (within an MPLS-TP network)
 E2E GMPLS
  TE-RTG   |< ------------------|--------|------------>|
  &RSVP-TE
 PW LDP    |< ---------------------------------------- >|
   Figure 2.  MPLS-TP Control-Plane Reference Model with OAM
   Legend:
        CE:            Customer Edge
        Client signal: defined in MPLS-TP Requirements
        E2E:           End-to-End
        L2:            Any layer 2 signal that may be carried
                       over a PW, e.g., Ethernet
        H-LSP:         Hierarchical LSP
        MEP:           Maintenance Entity Group End Point
        MIP:           Maintenance Entity Group Intermediate Point
        NNI:           Network-to-Network Interface
        P:             Provider
        PE:            Provider Edge
        SP:            Service Provider
        TE-RTG:        GMPLS OSPF-TE or ISIS-TE
   Note: The MS-PW case is not shown.

Andersson, et al. Informational [Page 8] RFC 6373 MPLS-TP Control Plane Framework September 2011

 While not shown in the figures above, the MPLS-TP control plane must
 support the addressing separation and independence between the data,
 control, and management planes.  Address separation between the
 planes is already included in GMPLS.  Such separation is also already
 included in LDP as LDP session end point addresses are never
 automatically associated with forwarding.

2. Control-Plane Requirements

 The requirements for the MPLS-TP control plane are derived from the
 MPLS-TP requirements and framework documents, specifically [RFC5654],
 [RFC5921], [RFC5860], [RFC6371], and [RFC6372].  The requirements are
 summarized in this section, but do not replace those documents.  If
 there are differences between this section and those documents, those
 documents shall be considered authoritative.

2.1. Primary Requirements

 These requirements are based on Section 2 of [RFC5654]:
    1. Any new functionality that is defined to fulfill the
       requirements for MPLS-TP must be agreed within the IETF through
       the IETF consensus process as per [RFC4929] and Section 1,
       paragraph 15 of [RFC5654].
    2. The MPLS-TP control-plane design should as far as reasonably
       possible reuse existing MPLS standards ([RFC5654], requirement
       2).
    3. The MPLS-TP control plane must be able to interoperate with
       existing IETF MPLS and PWE3 control planes where appropriate
       ([RFC5654], requirement 3).
    4. The MPLS-TP control plane must be sufficiently well-defined to
       ensure that the interworking between equipment supplied by
       multiple vendors will be possible both within a single domain
       and between domains ([RFC5654], requirement 4).
    5. The MPLS-TP control plane must support a connection-oriented
       packet switching model with traffic engineering capabilities
       that allow deterministic control of the use of network
       resources ([RFC5654], requirement 5).
    6. The MPLS-TP control plane must support traffic-engineered
       point-to-point (P2P) and point-to-multipoint (P2MP) transport
       paths ([RFC5654], requirement 6).

Andersson, et al. Informational [Page 9] RFC 6373 MPLS-TP Control Plane Framework September 2011

    7. The MPLS-TP control plane must support unidirectional,
       associated bidirectional and co-routed bidirectional point-to-
       point transport paths ([RFC5654], requirement 7).
    8. The MPLS-TP control plane must support unidirectional point-to-
       multipoint transport paths ([RFC5654], requirement 8).
    9. The MPLS-TP control plane must enable all nodes (i.e., ingress,
       egress, and intermediate) to be aware about the pairing
       relationship of the forward and the backward directions
       belonging to the same co-routed bidirectional transport path
       ([RFC5654], requirement 10).
   10. The MPLS-TP control plane must enable edge nodes (i.e., ingress
       and egress) to be aware of the pairing relationship of the
       forward and the backward directions belonging to the same
       associated bidirectional transport path ([RFC5654], requirement
       11).
   11. The MPLS-TP control plane should enable common transit nodes to
       be aware of the pairing relationship of the forward and the
       backward directions belonging to the same associated
       bidirectional transport path ([RFC5654], requirement 12).
   12. The MPLS-TP control plane must support bidirectional transport
       paths with symmetric bandwidth requirements, i.e., the amount
       of reserved bandwidth is the same in the forward and backward
       directions ([RFC5654], requirement 13).
   13. The MPLS-TP control plane must support bidirectional transport
       paths with asymmetric bandwidth requirements, i.e., the amount
       of reserved bandwidth differs in the forward and backward
       directions ([RFC5654], requirement 14).
   14. The MPLS-TP control plane must support the logical separation
       of the control plane from the management and data planes
       ([RFC5654], requirement 15).  Note that this implies that the
       addresses used in the control plane are independent from the
       addresses used in the management and data planes.
   15. The MPLS-TP control plane must support the physical separation
       of the control plane from the management and data plane, and no
       assumptions should be made about the state of the data-plane
       channels from information about the control- or management-
       plane channels when they are running out-of-band ([RFC5654],
       requirement 16).

Andersson, et al. Informational [Page 10] RFC 6373 MPLS-TP Control Plane Framework September 2011

   16. A control plane must be defined to support dynamic provisioning
       and restoration of MPLS-TP transport paths, but its use is a
       network operator's choice ([RFC5654], requirement 18).
   17. The presence of a control plane must not be required for static
       provisioning of MPLS-TP transport paths ([RFC5654], requirement
       19).
   18. The MPLS-TP control plane must permit the coexistence of
       statically and dynamically provisioned/managed MPLS-TP
       transport paths within the same layer network or domain
       ([RFC5654], requirement 20).
   19. The MPLS-TP control plane should be operable in a way that is
       similar to the way the control plane operates in other
       transport-layer technologies ([RFC5654], requirement 21).
   20. The MPLS-TP control plane must avoid or minimize traffic impact
       (e.g., packet delay, reordering, and loss) during network
       reconfiguration ([RFC5654], requirement 24).
   21. The MPLS-TP control plane must work across multiple homogeneous
       domains ([RFC5654], requirement 25), i.e., all domains use the
       same MPLS-TP control plane.
   22. The MPLS-TP control plane should work across multiple non-
       homogeneous domains ([RFC5654], requirement 26), i.e., some
       domains use the same control plane and other domains use static
       provisioning at the domain boundary.
   23. The MPLS-TP control plane must not dictate any particular
       physical or logical topology ([RFC5654], requirement 27).
   24. The MPLS-TP control plane must include support of ring
       topologies that may be deployed with arbitrary interconnection
       and support of rings of at least 16 nodes ([RFC5654],
       requirements 27.A, 27.B, and 27.C).
   25. The MPLS-TP control plane must scale gracefully to support a
       large number of transport paths, nodes, and links.  That is, it
       must be able to scale at least as well as control planes in
       existing transport technologies with growing and increasingly
       complex network topologies as well as with increasing bandwidth
       demands, number of customers, and number of services
       ([RFC5654], requirements 53 and 28).
   26. The MPLS-TP control plane should not provision transport paths
       that contain forwarding loops ([RFC5654], requirement 29).

Andersson, et al. Informational [Page 11] RFC 6373 MPLS-TP Control Plane Framework September 2011

   27. The MPLS-TP control plane must support multiple client layers
       (e.g., MPLS-TP, IP, MPLS, Ethernet, ATM, Frame Relay, etc.)
       ([RFC5654], requirement 30).
   28. The MPLS-TP control plane must provide a generic and extensible
       solution to support the transport of MPLS-TP transport paths
       over one or more server-layer networks (such as MPLS-TP,
       Ethernet, Synchronous Optical Network / Synchronous Digital
       Hierarchy (SONET/SDH), Optical Transport Network (OTN), etc.).
       Requirements for bandwidth management within a server-layer
       network are outside the scope of this document ([RFC5654],
       requirement 31).
   29. In an environment where an MPLS-TP layer network is supporting
       a client-layer network, and the MPLS-TP layer network is
       supported by a server-layer network, then the control-plane
       operation of the MPLS-TP layer network must be possible without
       any dependencies on the server or client-layer network
       ([RFC5654], requirement 32).
   30. The MPLS-TP control plane must allow for the transport of a
       client MPLS or MPLS-TP layer network over a server MPLS or
       MPLS-TP layer network ([RFC5654], requirement 33).
   31. The MPLS-TP control plane must allow the autonomous operation
       of the layers of a multi-layer network that includes an MPLS-TP
       layer ([RFC5654], requirement 34).
   32. The MPLS-TP control plane must allow the hiding of MPLS-TP
       layer network addressing and other information (e.g., topology)
       from client-layer networks.  However, it should be possible, at
       the option of the operator, to leak a limited amount of
       summarized information, such as Shared Risk Link Groups (SRLGs)
       or reachability, between layers ([RFC5654], requirement 35).
   33. The MPLS-TP control plane must allow for the identification of
       a transport path on each link within and at the destination
       (egress) of the transport network ([RFC5654], requirements 38
       and 39).
   34. The MPLS-TP control plane must allow for the use of P2MP server
       (sub-)layer capabilities as well as P2P server (sub-)layer
       capabilities when supporting P2MP MPLS-TP transport paths
       ([RFC5654], requirement 40).
   35. The MPLS-TP control plane must be extensible in order to
       accommodate new types of client-layer networks and services
       ([RFC5654], requirement 41).

Andersson, et al. Informational [Page 12] RFC 6373 MPLS-TP Control Plane Framework September 2011

   36. The MPLS-TP control plane should support the reserved bandwidth
       associated with a transport path to be increased without
       impacting the existing traffic on that transport path, provided
       enough resources are available ([RFC5654], requirement 42)).
   37. The MPLS-TP control plane should support the reserved bandwidth
       of a transport path being decreased without impacting the
       existing traffic on that transport path, provided that the
       level of existing traffic is smaller than the reserved
       bandwidth following the decrease ([RFC5654], requirement 43).
   38. The control plane for MPLS-TP must fit within the ASON
       (control-plane) architecture.  The ITU-T has defined an
       architecture for ASONs in G.8080 [ITU.G8080.2006] and G.8080
       Amendment 1 [ITU.G8080.2008].  An interpretation of the ASON
       signaling and routing requirements in the context of GMPLS can
       be found in [RFC4139], [RFC4258], and Section 2.4, paragraphs 2
       and 3 of [RFC5654].
   39. The MPLS-TP control plane must support control-plane topology
       and data-plane topology independence ([RFC5654], requirement
       47).
   40. A failure of the MPLS-TP control plane must not interfere with
       the delivery of service or recovery of established transport
       paths ([RFC5654], requirement 47).
   41. The MPLS-TP control plane must be able to operate independent
       of any particular client- or server-layer control plane
       ([RFC5654], requirement 48).
   42. The MPLS-TP control plane should support, but not require, an
       integrated control plane encompassing MPLS-TP together with its
       server- and client-layer networks when these layer networks
       belong to the same administrative domain ([RFC5654],
       requirement 49).
   43. The MPLS-TP control plane must support configuration of
       protection functions and any associated maintenance (OAM)
       functions ([RFC5654], requirements 50 and 7).
   44. The MPLS-TP control plane must support the configuration and
       modification of OAM maintenance points as well as the
       activation/deactivation of OAM when the transport path or
       transport service is established or modified ([RFC5654],
       requirement 51).

Andersson, et al. Informational [Page 13] RFC 6373 MPLS-TP Control Plane Framework September 2011

   45. The MPLS-TP control plane must be capable of restarting and
       relearning its previous state without impacting forwarding
       ([RFC5654], requirement 54).
   46. The MPLS-TP control plane must provide a mechanism for dynamic
       ownership transfer of the control of MPLS-TP transport paths
       from the management plane to the control plane and vice versa.
       The number of reconfigurations required in the data plane must
       be minimized; preferably no data-plane reconfiguration will be
       required ([RFC5654], requirement 55).  Note, such transfers
       cover all transport path control functions including control of
       recovery and OAM.
   47. The MPLS-TP control plane must support protection and
       restoration mechanisms, i.e., recovery ([RFC5654], requirement
       52).
       Note that the MPLS-TP survivability framework document
       [RFC6372] provides additional useful information related to
       recovery.
   48. The MPLS-TP control-plane mechanisms should be identical (or as
       similar as possible) to those already used in existing
       transport networks to simplify implementation and operations.
       However, this must not override any other requirement
       ([RFC5654], requirement 56 A).
   49. The MPLS-TP control-plane mechanisms used for P2P and P2MP
       recovery should be identical to simplify implementation and
       operation.  However, this must not override any other
       requirement ([RFC5654], requirement 56 B).
   50. The MPLS-TP control plane must support recovery mechanisms that
       are applicable at various levels throughout the network
       including support for link, transport path, segment,
       concatenated segment, and end-to-end recovery ([RFC5654],
       requirement 57).
   51. The MPLS-TP control plane must support recovery paths that meet
       the Service Level Agreement (SLA) protection objectives of the
       service ([RFC5654], requirement 58).  These include:
       a. Guarantee 50-ms recovery times from the moment of fault
          detection in networks with spans less than 1200 km.
       b. Protection of 100% of the traffic on the protected path.
       c. Recovery must meet SLA requirements over multiple domains.

Andersson, et al. Informational [Page 14] RFC 6373 MPLS-TP Control Plane Framework September 2011

   52. The MPLS-TP control plane should support per-transport-path
       recovery objectives ([RFC5654], requirement 59).
   53. The MPLS-TP control plane must support recovery mechanisms that
       are applicable to any topology ([RFC5654], requirement 60).
   54. The MPLS-TP control plane must operate in synergy with
       (including coordination of timing/timer settings) the recovery
       mechanisms present in any client or server transport networks
       (for example, Ethernet, SDH, OTN, Wavelength Division
       Multiplexing (WDM)) to avoid race conditions between the layers
       ([RFC5654], requirement 61).
   55. The MPLS-TP control plane must support recovery and reversion
       mechanisms that prevent frequent operation of recovery in the
       event of an intermittent defect ([RFC5654], requirement 62).
   56. The MPLS-TP control plane must support revertive and non-
       revertive protection behavior ([RFC5654], requirement 64).
   57. The MPLS-TP control plane must support 1+1 bidirectional
       protection for P2P transport paths ([RFC5654], requirement 65
       A).
   58. The MPLS-TP control plane must support 1+1 unidirectional
       protection for P2P transport paths ([RFC5654], requirement 65
       B).
   59. The MPLS-TP control plane must support 1+1 unidirectional
       protection for P2MP transport paths ([RFC5654], requirement 65
       C).
   60. The MPLS-TP control plane must support the ability to share
       protection resources amongst a number of transport paths
       ([RFC5654], requirement 66).
   61. The MPLS-TP control plane must support 1:n bidirectional
       protection for P2P transport paths.  Bidirectional 1:n
       protection should be the default for 1:n protection ([RFC5654],
       requirement 67 A).
   62. The MPLS-TP control plane must support 1:n unidirectional
       protection for P2MP transport paths ([RFC5654], requirement 67
       B).
   63. The MPLS-TP control plane may support 1:n unidirectional
       protection for P2P transport paths ([RFC5654], requirement 65
       C).

Andersson, et al. Informational [Page 15] RFC 6373 MPLS-TP Control Plane Framework September 2011

   64. The MPLS-TP control plane may support the control of extra-
       traffic type traffic ([RFC5654], note after requirement 67).
   65. The MPLS-TP control plane should support 1:n (including 1:1)
       shared mesh recovery ([RFC5654], requirement 68).
   66. The MPLS-TP control plane must support sharing of protection
       resources such that protection paths that are known not to be
       required concurrently can share the same resources ([RFC5654],
       requirement 69).
   67. The MPLS-TP control plane must support the sharing of resources
       between a restoration transport path and the transport path
       being replaced ([RFC5654], requirement 70).
   68. The MPLS-TP control plane must support restoration priority so
       that an implementation can determine the order in which
       transport paths should be restored ([RFC5654], requirement 71).
   69. The MPLS-TP control plane must support preemption priority in
       order to allow restoration to displace other transport paths in
       the event of resource constraints ([RFC5654], requirements 72
       and 86).
   70. The MPLS-TP control plane must support revertive and non-
       revertive restoration behavior ([RFC5654], requirement 73).
   71. The MPLS-TP control plane must support recovery being triggered
       by physical (lower) layer fault indications ([RFC5654],
       requirement 74).
   72. The MPLS-TP control plane must support recovery being triggered
       by OAM ([RFC5654], requirement 75).
   73. The MPLS-TP control plane must support management-plane
       recovery triggers (e.g., forced switch, etc.) ([RFC5654],
       requirement 76).
   74. The MPLS-TP control plane must support the differentiation of
       administrative recovery actions from recovery actions initiated
       by other triggers ([RFC5654], requirement 77).
   75. The MPLS-TP control plane should support control-plane
       restoration triggers (e.g., forced switch, etc.) ([RFC5654],
       requirement 78).

Andersson, et al. Informational [Page 16] RFC 6373 MPLS-TP Control Plane Framework September 2011

   76. The MPLS-TP control plane must support priority logic to
       negotiate and accommodate coexisting requests (i.e., multiple
       requests) for protection switching (e.g., administrative
       requests and requests due to link/node failures) ([RFC5654],
       requirement 79).
   77. The MPLS-TP control plane must support the association of
       protection paths and working paths (sometimes known as
       protection groups) ([RFC5654], requirement 80).
   78. The MPLS-TP control plane must support pre-calculation of
       recovery paths ([RFC5654], requirement 81).
   79. The MPLS-TP control plane must support pre-provisioning of
       recovery paths ([RFC5654], requirement 82).
   80. The MPLS-TP control plane must support the external commands
       defined in [RFC4427].  External controls overruled by higher
       priority requests (e.g., administrative requests and requests
       due to link/node failures) or unable to be signaled to the
       remote end (e.g., because of a protection state coordination
       fail) must be ignored/dropped ([RFC5654], requirement 83).
   81. The MPLS-TP control plane must permit the testing and
       validation of the integrity of the protection/recovery
       transport path ([RFC5654], requirement 84 A).
   82. The MPLS-TP control plane must permit the testing and
       validation of protection/restoration mechanisms without
       triggering the actual protection/restoration ([RFC5654],
       requirement 84 B).
   83. The MPLS-TP control plane must permit the testing and
       validation of protection/restoration mechanisms while the
       working path is in service ([RFC5654], requirement 84 C).
   84. The MPLS-TP control plane must permit the testing and
       validation of protection/restoration mechanisms while the
       working path is out of service ([RFC5654], requirement 84 D).
   85. The MPLS-TP control plane must support the establishment and
       maintenance of all recovery entities and functions ([RFC5654],
       requirement 89 A).
   86. The MPLS-TP control plane must support signaling of recovery
       administrative control ([RFC5654], requirement 89 B).

Andersson, et al. Informational [Page 17] RFC 6373 MPLS-TP Control Plane Framework September 2011

   87. The MPLS-TP control plane must support protection state
       coordination.  Since control-plane network topology is
       independent from the data-plane network topology, the
       protection state coordination supported by the MPLS-TP control
       plane may run on resources different than the data-plane
       resources handled within the recovery mechanism (e.g., backup)
       ([RFC5654], requirement 89 C).
   88. When present, the MPLS-TP control plane must support recovery
       mechanisms that are optimized for specific network topologies.
       These mechanisms must be interoperable with the mechanisms
       defined for arbitrary topology (mesh) networks to enable
       protection of end-to-end transport paths ([RFC5654],
       requirement 91).
   89. When present, the MPLS-TP control plane must support the
       control of ring-topology-specific recovery mechanisms
       ([RFC5654], Section 2.5.6.1).
   90. The MPLS-TP control plane must include support for
       differentiated services and different traffic types with
       traffic class separation associated with different traffic
       ([RFC5654], requirement 110).
   91. The MPLS-TP control plane must support the provisioning of
       services that provide guaranteed Service Level Specifications
       (SLSs), with support for hard ([RFC3209] style) and relative
       ([RFC3270] style) end-to-end bandwidth guarantees ([RFC5654],
       requirement 111).
   92. The MPLS-TP control plane must support the provisioning of
       services that are sensitive to jitter and delay ([RFC5654],
       requirement 112).

2.2. Requirements Derived from the MPLS-TP Framework

 The following additional requirements are based on [RFC5921],
 [TP-P2MP-FWK], and [RFC5960]:
   93. Per-packet Equal Cost Multi-Path (ECMP) load balancing is
       currently outside the scope of MPLS-TP ([RFC5960], Section
       3.1.1, paragraph 6).
   94. Penultimate Hop Popping (PHP) must be disabled on MPLS-TP LSPs
       by default ([RFC5960], Section 3.1.1, paragraph 7).

Andersson, et al. Informational [Page 18] RFC 6373 MPLS-TP Control Plane Framework September 2011

   95. The MPLS-TP control plane must support both E-LSP (Explicitly
       TC-encoded-PSC LSP) and L-LSP (Label-Only-Inferred-PSC LSP)
       MPLS Diffserv modes as specified in [RFC3270], [RFC5462], and
       Section 3.3.2, paragraph 12 of [RFC5960].
   96. Both Single-Segment PWs (see [RFC3985]) and Multi-Segment PWs
       (see [RFC5659]) shall be supported by the MPLS-TP control
       plane.  MPLS-TP shall use the definition of Multi-Segment PWs
       as defined by the IETF ([RFC5921], Section 3.4.4).
   97. The MPLS-TP control plane must support the control of PWs and
       their associated labels ([RFC5921], Section 3.4.4).
   98. The MPLS-TP control plane must support network-layer clients,
       i.e., clients whose traffic is transported over an MPLS-TP
       network without the use of PWs ([RFC5921], Section 3.4.5).
       a. The MPLS-TP control plane must support the use of network-
          layer protocol-specific LSPs and labels ([RFC5921], Section
          3.4.5).
       b. The MPLS-TP control plane must support the use of a client-
          service-specific LSPs and labels ([RFC5921], Section 3.4.5).
   99. The MPLS-TP control plane for LSPs must be based on the GMPLS
       control plane.  More specifically, GMPLS RSVP-TE [RFC3473] and
       related extensions are used for LSP signaling, and GMPLS OSPF-
       TE [RFC5392] and ISIS-TE [RFC5316] are used for routing
       ([RFC5921], Section 3.9).
  100. The MPLS-TP control plane for PWs must be based on the MPLS
       control plane for PWs, and more specifically, targeted LDP (T-
       LDP) [RFC4447] is used for PW signaling ([RFC5921], Section
       3.9, paragraph 5).
  101. The MPLS-TP control plane must ensure its own survivability and
       be able to recover gracefully from failures and degradations.
       These include graceful restart and hot redundant configurations
       ([RFC5921], Section 3.9, paragraph 16).
  102. The MPLS-TP control plane must support linear, ring, and meshed
       protection schemes ([RFC5921], Section 3.12, paragraph 3).
  103. The MPLS-TP control plane must support the control of SPMEs
       (hierarchical LSPs) for new or existing end-to-end LSPs
       ([RFC5921], Section 3.12, paragraph 7).

Andersson, et al. Informational [Page 19] RFC 6373 MPLS-TP Control Plane Framework September 2011

2.3. Requirements Derived from the OAM Framework

 The following additional requirements are based on [RFC5860] and
 [RFC6371]:
  104. The MPLS-TP control plane must support the capability to
       enable/disable OAM functions as part of service establishment
       ([RFC5860], Section 2.1.6, paragraph 1.  Note that OAM
       functions are applicable regardless of the label stack depth
       (i.e., level of LSP hierarchy or PW) ([RFC5860], Section 2.1.1,
       paragraph 3).
  105. The MPLS-TP control plane must support the capability to
       enable/disable OAM functions after service establishment.  In
       such cases, the customer must not perceive service degradation
       as a result of OAM enabling/disabling ([RFC5860], Section
       2.1.6, paragraphs 1 and 2).
  106. The MPLS-TP control plane must support dynamic control of any
       of the existing IP/MPLS and PW OAM protocols, e.g., LSP-Ping
       [RFC4379], MPLS-BFD [RFC5884], VCCV [RFC5085], and VCCV-BFD
       [RFC5885] ([RFC5860], Section 2.1.4, paragraph 2).
  107. The MPLS-TP control plane must allow for the ability to support
       experimental OAM functions.  These functions must be disabled
       by default ([RFC5860], Section 2.2, paragraph 2).
  108. The MPLS-TP control plane must support the choice of which (if
       any) OAM function(s) to use and to which PW, LSP or Section it
       applies ([RFC5860], Section 2.2, paragraph 3).
  109. The MPLS-TP control plane must allow (e.g., enable/disable)
       mechanisms that support the localization of faults and the
       notification of appropriate nodes ([RFC5860], Section 2.2.1,
       paragraph 1).
  110. The MPLS-TP control plane may support mechanisms that permit
       the service provider to be informed of a fault or defect
       affecting the service(s) it provides, even if the fault or
       defect is located outside of his domain ([RFC5860], Section
       2.2.1, paragraph 2).
  111. Information exchange between various nodes involved in the
       MPLS-TP control plane should be reliable such that, for
       example, defects or faults are properly detected or that state
       changes are effectively known by the appropriate nodes
       ([RFC5860], Section 2.2.1, paragraph 3).

Andersson, et al. Informational [Page 20] RFC 6373 MPLS-TP Control Plane Framework September 2011

  112. The MPLS-TP control plane must provide functionality to control
       an end point's ability to monitor the liveness of a PW, LSP, or
       Section ([RFC5860], Section 2.2.2, paragraph 1).
  113. The MPLS-TP control plane must provide functionality to control
       an end point's ability to determine whether or not it is
       connected to specific end point(s) by means of the expected PW,
       LSP, or Section ([RFC5860], Section 2.2.3, paragraph 1).
       a. The MPLS-TP control plane must provide mechanisms to control
          an end point's ability to perform this function proactively
          ([RFC5860], Section 2.2.3, paragraph 2).
       b. The MPLS-TP control plane must provide mechanisms to control
          an end point's ability to perform this function on-demand
          ([RFC5860], Section 2.2.3, paragraph 3).
  114. The MPLS-TP control plane must provide functionality to control
       diagnostic testing on a PW, LSP or Section ([RFC5860], Section
       2.2.5, paragraph 1).
       a. The MPLS-TP control plane must provide mechanisms to control
          the performance of this function on-demand ([RFC5860],
          Section 2.2.5, paragraph 2).
  115. The MPLS-TP control plane must provide functionality to enable
       an end point to discover the Intermediate Point(s) (if any) and
       end point(s) along a PW, LSP, or Section, and more generally to
       trace (record) the route of a PW, LSP, or Section ([RFC5860],
       Section 2.2.4, paragraph 1).
       a. The MPLS-TP control plane must provide mechanisms to control
          the performance of this function on-demand ([RFC5860],
          Section 2.2.4, paragraph 2).
  116. The MPLS-TP control plane must provide functionality to enable
       an end point of a PW, LSP, or Section to instruct its
       associated end point(s) to lock the PW, LSP, or Section
       ([RFC5860], Section 2.2.6, paragraph 1).
       a. The MPLS-TP control plane must provide mechanisms to control
          the performance of this function on-demand ([RFC5860],
          Section 2.2.6, paragraph 2).

Andersson, et al. Informational [Page 21] RFC 6373 MPLS-TP Control Plane Framework September 2011

  117. The MPLS-TP control plane must provide functionality to enable
       an Intermediate Point of a PW or LSP to report, to an end point
       of that same PW or LSP, a lock condition indirectly affecting
       that PW or LSP ([RFC5860], Section 2.2.7, paragraph 1).
       a. The MPLS-TP control plane must provide mechanisms to control
          the performance of this function proactively ([RFC5860],
          Section 2.2.7, paragraph 2).
  118. The MPLS-TP control plane must provide functionality to enable
       an Intermediate Point of a PW or LSP to report, to an end point
       of that same PW or LSP, a fault or defect condition affecting
       that PW or LSP ([RFC5860], Section 2.2.8, paragraph 1).
       a. The MPLS-TP control plane must provide mechanisms to control
          the performance of this function proactively ([RFC5860],
          Section 2.2.8, paragraph 2).
  119. The MPLS-TP control plane must provide functionality to enable
       an end point to report, to its associated end point, a fault or
       defect condition that it detects on a PW, LSP, or Section for
       which they are the end points ([RFC5860], Section 2.2.9,
       paragraph 1).
       a. The MPLS-TP control plane must provide mechanisms to control
          the performance of this function proactively ([RFC5860],
          Section 2.2.9, paragraph 2).
  120. The MPLS-TP control plane must provide functionality to enable
       the propagation, across an MPLS-TP network, of information
       pertaining to a client defect or fault condition detected at an
       end point of a PW or LSP, if the client-layer mechanisms do not
       provide an alarm notification/propagation mechanism ([RFC5860],
       Section 2.2.10, paragraph 1).
       a. The MPLS-TP control plane must provide mechanisms to control
          the performance of this function proactively ([RFC5860],
          Section 2.2.10, paragraph 2).
  121. The MPLS-TP control plane must provide functionality to enable
       the control of quantification of packet loss ratio over a PW,
       LSP, or Section ([RFC5860], Section 2.2.11, paragraph 1).
       a. The MPLS-TP control plane must provide mechanisms to control
          the performance of this function proactively and on-demand
          ([RFC5860], Section 2.2.11, paragraph 4).

Andersson, et al. Informational [Page 22] RFC 6373 MPLS-TP Control Plane Framework September 2011

  122. The MPLS-TP control plane must provide functionality to control
       the quantification and reporting of the one-way, and if
       appropriate, the two-way, delay of a PW, LSP, or Section
       ([RFC5860], Section 2.2.12, paragraph 1).
       a. The MPLS-TP control plane must provide mechanisms to control
          the performance of this function proactively and on-demand
          ([RFC5860], Section 2.2.12, paragraph 6).
  123. The MPLS-TP control plane must support the configuration of OAM
       functional components that include Maintenance Entities (MEs)
       and Maintenance Entity Groups (MEGs) as instantiated in MEPs,
       MIPs, and SPMEs ([RFC6371], Section 3.6).
  124. For dynamically established transport paths, the control plane
       must support the configuration of OAM operations ([RFC6371],
       Section 5).
       a. The MPLS-TP control plane must provide mechanisms to
          configure proactive monitoring for a MEG at, or after,
          transport path creation time.
       b. The MPLS-TP control plane must provide mechanisms to
          configure the operational characteristics of in-band
          measurement transactions (e.g., Connectivity Verification
          (CV), Loss Measurement (LM), etc.) at MEPs (associated with
          a transport path).
       c. The MPLS-TP control plane may provide mechanisms to
          configure server-layer event reporting by intermediate
          nodes.
       d. The MPLS-TP control plane may provide mechanisms to
          configure the reporting of measurements resulting from
          proactive monitoring.
  125. The MPLS-TP control plane must support the control of the loss
       of continuity (LOC) traffic block consequent action ([RFC6371],
       Section 5.1.2, paragraph 4).
  126. For dynamically established transport paths that have a
       proactive Continuity Check and Connectivity Verification (CC-V)
       function enabled, the control plane must support the signaling
       of the following MEP configuration information ([RFC6371],
       Section 5.1.3):
       a. The MPLS-TP control plane must provide mechanisms to
          configure the MEG identifier to which the MEP belongs.

Andersson, et al. Informational [Page 23] RFC 6373 MPLS-TP Control Plane Framework September 2011

       b. The MPLS-TP control plane must provide mechanisms to
          configure a MEP's own identity inside a MEG.
       c. The MPLS-TP control plane must provide mechanisms to
          configure the list of the other MEPs in the MEG.
       d. The MPLS-TP control plane must provide mechanisms to
          configure the CC-V transmission rate / reception period
          (covering all application types).
  127. The MPLS-TP control plane must provide mechanisms to configure
       the generation of Alarm Indication Signal (AIS) packets for
       each MEG ([RFC6371], Section 5.3, paragraph 9).
  128. The MPLS-TP control plane must provide mechanisms to configure
       the generation of Lock Report (LKR) packets for each MEG
       ([RFC6371], Section 5.4, paragraph 9).
  129. The MPLS-TP control plane must provide mechanisms to configure
       the use of proactive Packet Loss Measurement (LM), and the
       transmission rate and Per-Hop Behavior (PHB) class associated
       with the LM OAM packets originating from a MEP ([RFC6371],
       Section 5.5.1, paragraph 1).
  130. The MPLS-TP control plane must provide mechanisms to configure
       the use of proactive Packet Delay Measurement (DM), and the
       transmission rate and PHB class associated with the DM OAM
       packets originating from a MEP ([RFC6371], Section 5.6.1,
       paragraph 1).
  131. The MPLS-TP control plane must provide mechanisms to configure
       the use of Client Failure Indication (CFI), and the
       transmission rate and PHB class associated with the CFI OAM
       packets originating from a MEP ([RFC6371], Section 5.7.1,
       paragraph 1).
  132. The MPLS-TP control plane should provide mechanisms to control
       the use of on-demand CV packets ([RFC6371], Section 6.1).
       a. The MPLS-TP control plane should provide mechanisms to
          configure the number of packets to be transmitted/received
          in each burst of on-demand CV packets and their packet size
          ([RFC6371], Section 6.1.1, paragraph 1).
       b. When an on-demand CV packet is used to check connectivity
          toward a target MIP, the MPLS-TP control plane should
          provide mechanisms to configure the number of hops to reach
          the target MIP ([RFC6371], Section 6.1.1, paragraph 2).

Andersson, et al. Informational [Page 24] RFC 6373 MPLS-TP Control Plane Framework September 2011

       c. The MPLS-TP control plane should provide mechanisms to
          configure the PHB of on-demand CV packets ([RFC6371],
          Section 6.1.1, paragraph 3).
  133. The MPLS-TP control plane should provide mechanisms to control
       the use of on-demand LM, including configuration of the
       beginning and duration of the LM procedures, the transmission
       rate, and PHB associated with the LM OAM packets originating
       from a MEP ([RFC6371], Section 6.2.1).
  134. The MPLS-TP control plane should provide mechanisms to control
       the use of throughput estimation ([RFC6371], Section 6.3.1).
  135. The MPLS-TP control plane should provide mechanisms to control
       the use of on-demand DM, including configuration of the
       beginning and duration of the DM procedures, the transmission
       rate, and PHB associated with the DM OAM packets originating
       from a MEP ([RFC6371], Section 6.5.1).

2.4. Security Requirements

 There are no specific MPLS-TP control-plane security requirements.
 The existing framework for MPLS and GMPLS security is documented in
 [RFC5920], and that document applies equally to MPLS-TP.

2.5. Identifier Requirements

 The following are requirements based on [RFC6370]:
  136. The MPLS-TP control plane must support MPLS-TP point-to-point
       tunnel identifiers of the forms defined in Section 5.1 of
       [RFC6370].
  137. The MPLS-TP control plane must support MPLS-TP LSP identifiers
       of the forms defined in Section 5.2 of [RFC6370], and the
       mappings to GMPLS as defined in Section 5.3 of [RFC6370].
  138. The MPLS-TP control plane must support pseudowire path
       identifiers of the form defined in Section 6 of [RFC6370].
  139. The MPLS-TP control plane must support MEG_IDs for LSPs and PWs
       as defined in Section 7.1.1 of [RFC6370].
  140. The MPLS-TP control plane must support IP-compatible MEG_IDs
       for LSPs and PWs as defined in Section 7.1.2 of [RFC6370].
  141. The MPLS-TP control plane must support MEP_IDs for LSPs and PWs
       of the forms defined in Section 7.2.1 of [RFC6370].

Andersson, et al. Informational [Page 25] RFC 6373 MPLS-TP Control Plane Framework September 2011

  142. The MPLS-TP control plane must support IP-based MEP_IDs for
       MPLS-TP LSP of the forms defined in Section 7.2.2.1 of
       [RFC6370].
  143. The MPLS-TP control plane must support IP-based MEP_IDs for
       Pseudowires of the form defined in Section 7.2.2.2 of
       [RFC6370].

3. Relationship of PWs and TE LSPs

 The data-plane relationship between PWs and LSPs is inherited from
 standard MPLS and is reviewed in the MPLS-TP framework [RFC5921].
 Likewise, the control-plane relationship between PWs and LSPs is
 inherited from standard MPLS.  This relationship is reviewed in this
 document.  The relationship between the PW and LSP control planes in
 MPLS-TP is the same as the relationship found in the PWE3 Maintenance
 Reference Model as presented in the PWE3 architecture; see Figure 6
 of [RFC3985].  The PWE3 architecture [RFC3985] states: "The PWE3
 protocol-layering model is intended to minimize the differences
 between PWs operating over different PSN types".  Additionally, PW
 control (maintenance) takes place separately from LSP signaling.
 [RFC4447] and [MS-PW-DYNAMIC] provide such extensions for the use of
 LDP as the control plane for PWs.  This control can provide PW
 control without providing LSP control.
 In the context of MPLS-TP, LSP tunnel signaling is provided via GMPLS
 RSVP-TE.  While RSVP-TE could be extended to support PW control much
 as LDP was extended in [RFC4447], such extensions are out of scope of
 this document.  This means that the control of PWs and LSPs will
 operate largely independently.  The main coordination between LSP and
 PW control will occur within the nodes that terminate PWs or PW
 segments.  See Section 5.3.2 for an additional discussion on such
 coordination.
 It is worth noting that the control planes for PWs and LSPs may be
 used independently, and that one may be employed without the other.
 This translates into four possible scenarios: (1) no control plane is
 employed; (2) a control plane is used for both LSPs and PWs; (3) a
 control plane is used for LSPs, but not PWs; (4) a control plane is
 used for PWs, but not LSPs.
 The PW and LSP control planes, collectively, must satisfy the MPLS-TP
 control-plane requirements reviewed in this document.  When client
 services are provided directly via LSPs, all requirements must be
 satisfied by the LSP control plane.  When client services are
 provided via PWs, the PW and LSP control planes can operate in
 combination, and some functions may be satisfied via the PW control
 plane while others are provided to PWs by the LSP control plane.  For

Andersson, et al. Informational [Page 26] RFC 6373 MPLS-TP Control Plane Framework September 2011

 example, to support the recovery functions described in [RFC6372],
 this document focuses on the control of the recovery functions at the
 LSP layer.  PW-based recovery is under development at this time and
 may be used once defined.

4. TE LSPs

 MPLS-TP uses Generalized MPLS (GMPLS) signaling and routing, see
 [RFC3945], as the control plane for LSPs.  The GMPLS control plane is
 based on the MPLS control plane.  GMPLS includes support for MPLS
 labeled data and transport data planes.  GMPLS includes most of the
 transport-centric features required to support MPLS-TP LSPs.  This
 section will first review the features of GMPLS relevant to MPLS-TP
 LSPs, then identify how specific requirements can be met using
 existing GMPLS functions, and will conclude with extensions that are
 anticipated to support the remaining MPLS-TP control-plane
 requirements.

4.1. GMPLS Functions and MPLS-TP LSPs

 This section reviews how existing GMPLS functions can be applied to
 MPLS-TP.

4.1.1. In-Band and Out-of-Band Control

 GMPLS supports both in-band and out-of-band control.  The terms "in-
 band" and "out-of-band", in the context of this document, refer to
 the relationship of the control plane relative to the management and
 data planes.  The terms may be used to refer to the control plane
 independent of the management plane, or to both of them in concert.
 The remainder of this section describes the relationship of the
 control plane to the management and data planes.
 There are multiple uses of both terms "in-band" and "out-of-band".
 The terms may relate to a channel, a path, or a network.  Each of
 these can be used independently or in combination.  Briefly, some
 typical usage of the terms is as follows:
 o  In-band
    This term is used to refer to cases where control-plane traffic is
    sent in the same communication channel used to transport
    associated user data or management traffic.  IP, MPLS, and
    Ethernet networks are all examples where control traffic is
    typically sent in-band with the data traffic.  An example of this
    case in the context of MPLS-TP is where control-plane traffic is
    sent via the MPLS Generic Associated Channel (G-ACh), see
    [RFC5586], using the same LSP as controlled user traffic.

Andersson, et al. Informational [Page 27] RFC 6373 MPLS-TP Control Plane Framework September 2011

 o  Out-of-band, in-fiber (same physical connection)
    This term is used to refer to cases where control-plane traffic is
    sent using a different communication channel from the associated
    data or management traffic, and the control communication channel
    resides in the same fiber as either the management or data
    traffic.  An example of this case in the context of MPLS-TP is
    where control-plane traffic is sent via the G-ACh using a
    dedicated LSP on the same link (interface) that carries controlled
    user traffic.
 o  Out-of-band, aligned topology
    This term is used to refer to the cases where control-plane
    traffic is sent using a different communication channel from the
    associated data or management traffic, and the control traffic
    follows the same node-to-node path as either the data or
    management traffic.
    Such topologies are usually supported using a parallel fiber or
    other configurations where multiple data channels are available
    and one is (dynamically) selected as the control channel.  An
    example of this case in the context of MPLS-TP is where control-
    plane traffic is sent along the same nodal path, but not
    necessarily the same links (interfaces), as the corresponding
    controlled user traffic.
 o  Out-of-band, independent topology
    This term is used to refer to the cases where control-plane
    traffic is sent using a different communication channel from the
    associated data or management traffic, and the control traffic may
    follow a path that is completely independent of the data traffic.
    Such configurations are a superset of the other cases and do not
    preclude the use of in-fiber or aligned topology links, but
    alignment is not required.  An example of this case in the context
    of MPLS-TP is where control-plane traffic is sent between
    controlling nodes using any available path and links, completely
    without regard for the path(s) taken by corresponding management
    or user traffic.
 In the context of MPLS-TP requirements, requirement 14 (see Section 2
 above) can be met using out-of-band in-fiber or aligned topology
 types of control.  Requirement 15 can only be met by using out-of-
 band, independent topology.  G-ACh is likely to be used extensively
 in MPLS-TP networks to support the MPLS-TP control (and management)
 planes.

Andersson, et al. Informational [Page 28] RFC 6373 MPLS-TP Control Plane Framework September 2011

4.1.2. Addressing

 MPLS-TP reuses and supports the addressing mechanisms supported by
 MPLS.  The MPLS-TP identifiers document (see [RFC6370]) provides
 additional context on how IP addresses are used within MPLS-TP.
 MPLS, and consequently MPLS-TP, uses the IPv4 and IPv6 address
 families to identify MPLS-TP nodes by default for network management
 and signaling purposes.  The address spaces and neighbor adjacencies
 in the control, management, and data planes used in an MPLS-TP
 network may be completely separated or combined at the discretion of
 an MPLS-TP operator and based on the equipment capabilities of a
 vendor.  The separation of the control and management planes from the
 data plane allows each plane to be independently addressable.  Each
 plane may use addresses that are not mutually reachable, e.g., it is
 likely that the data plane will not be able to reach an address from
 the management or control planes and vice versa.  Each plane may also
 use a different address family.  It is even possible to reuse
 addresses in each plane, but this is not recommended as it may lead
 to operational confusion.  As previously mentioned, the G-ACh
 mechanism defined in [RFC5586] is expected to be used extensively in
 MPLS-TP networks to support the MPLS-TP control (and management)
 planes.

4.1.3. Routing

 Routing support for MPLS-TP LSPs is based on GMPLS routing.  GMPLS
 routing builds on TE routing and has been extended to support
 multiple switching technologies per [RFC3945] and [RFC4202] as well
 as multiple levels of packet switching within a single network.  IS-
 IS extensions for GMPLS are defined in [RFC5307] and [RFC5316], which
 build on the TE extensions to IS-IS defined in [RFC5305].  OSPF
 extensions for GMPLS are defined in [RFC4203] and [RFC5392], which
 build on the TE extensions to OSPF defined in [RFC3630].  The listed
 RFCs should be viewed as a starting point rather than a comprehensive
 list as there are other IS-IS and OSPF extensions, as defined in IETF
 RFCs, that can be used within an MPLS-TP network.

4.1.4. TE LSPs and Constraint-Based Path Computation

 Both MPLS and GMPLS allow for traffic engineering and constraint-
 based path computation.  MPLS path computation provides paths for
 MPLS-TE unidirectional P2P and P2MP LSPs.  GMPLS path computation
 adds bidirectional LSPs, explicit recovery path computation, as well
 as support for the other functions discussed in this section.
 Both MPLS and GMPLS path computation allow for the restriction of
 path selection based on the use of Explicit Route Objects (EROs) and
 other LSP attributes; see [RFC3209] and [RFC3473].  In all cases, no

Andersson, et al. Informational [Page 29] RFC 6373 MPLS-TP Control Plane Framework September 2011

 specific algorithm is standardized by the IETF.  This is anticipated
 to continue to be the case for MPLS-TP LSPs.

4.1.4.1. Relation to PCE

 Path Computation Element (PCE)-based approaches, see [RFC4655], may
 be used for path computation of a GMPLS LSP, and consequently an
 MPLS-TP LSP, across domains and in a single domain.  In cases where
 PCE is used, the PCE Communication Protocol (PCEP), see [RFC5440],
 will be used to communicate PCE-related requests and responses.
 MPLS-TP-specific extensions to PCEP are currently out of scope of the
 MPLS-TP project and this document.

4.1.5. Signaling

 GMPLS signaling is defined in [RFC3471] and [RFC3473] and is based on
 RSVP-TE [RFC3209].  Constraint-based Routed LDP (CR-LDP) GMPLS (see
 [RFC3472]) is no longer under active development within the IETF,
 i.e., it is deprecated (see [RFC3468]) and must not be used for MPLS
 nor MPLS-TP consequently.  In general, all RSVP-TE extensions that
 apply to MPLS may also be used for GMPLS and consequently MPLS-TP.
 Most notably, this includes support for P2MP signaling as defined in
 [RFC4875].
 GMPLS signaling includes a number of MPLS-TP required functions --
 notably, support for out-of-band control, bidirectional LSPs, and
 independent control- and data-plane fault management.  There are also
 numerous other GMPLS and MPLS extensions that can be used to provide
 specific functions in MPLS-TP networks.  Specific references are
 provided below.

4.1.6. Unnumbered Links

 Support for unnumbered links (i.e., links that do not have IP
 addresses) is permitted in MPLS-TP and its usage is at the discretion
 of the network operator.  Support for unnumbered links is included
 for routing using OSPF [RFC4203] and IS-IS [RFC5307], and for
 signaling in [RFC3477].

4.1.7. Link Bundling

 Link bundling provides a local construct that can be used to improve
 scaling of TE routing when multiple data links are shared between
 node pairs.  Link bundling for MPLS and GMPLS networks is defined in
 [RFC4201].  Link bundling may be used in MPLS-TP networks, and its
 use is at the discretion of the network operator.

Andersson, et al. Informational [Page 30] RFC 6373 MPLS-TP Control Plane Framework September 2011

4.1.8. Hierarchical LSPs

 This section reuses text from [RFC6107].
 [RFC3031] describes how MPLS labels may be stacked so that LSPs may
 be nested with one LSP running through another.  This concept of
 hierarchical LSPs (H-LSPs) is formalized in [RFC4206] with a set of
 protocol mechanisms for the establishment of a hierarchical LSP that
 can carry one or more other LSPs.
 [RFC4206] goes on to explain that a hierarchical LSP may carry other
 LSPs only according to their switching types.  This is a function of
 the way labels are carried.  In a packet switch capable network, the
 hierarchical LSP can carry other packet switch capable LSPs using the
 MPLS label stack.
 Signaling mechanisms defined in [RFC4206] allow a hierarchical LSP to
 be treated as a single hop in the path of another LSP.  This
 mechanism is also sometimes known as "non-adjacent signaling", see
 [RFC4208].
 A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link
 created from an LSP and advertised in the same instance of the
 control plane that advertises the TE links from which the LSP is
 constructed.  The LSP itself is called an FA-LSP.  FA-LSPs are
 analogous to MPLS-TP Sections as discussed in [RFC5960].
 Thus, a hierarchical LSP may form an FA such that it is advertised as
 a TE link in the same instance of the routing protocol as was used to
 advertise the TE links that the LSP traverses.
 As observed in [RFC4206], the nodes at the ends of an FA would not
 usually have a routing adjacency.
 LSP hierarchy is expected to play an important role in MPLS-TP
 networks, particularly in the context of scaling and recovery as well
 as supporting SPMEs.

4.1.9. LSP Recovery

 GMPLS defines RSVP-TE extensions in support for end-to-end GMPLS LSPs
 recovery in [RFC4872] and segment recovery in [RFC4873].  GMPLS
 segment recovery provides a superset of the function in end-to-end
 recovery.  End-to-end recovery can be viewed as a special case of
 segment recovery where there is a single recovery domain whose
 borders coincide with the ingress and egress of the LSP, although
 specific procedures are defined.

Andersson, et al. Informational [Page 31] RFC 6373 MPLS-TP Control Plane Framework September 2011

 The five defined types of recovery defined in GMPLS are:
  1. 1+1 bidirectional protection for P2P LSPs
  2. 1+1 unidirectional protection for P2MP LSPs
  3. 1:n (including 1:1) protection with or without extra traffic
  4. Rerouting without extra traffic (sometimes known as soft

rerouting), including shared mesh restoration

  1. Full LSP rerouting
 Recovery for MPLS-TP LSPs, as discussed in [RFC6372], is signaled
 using the mechanism defined in [RFC4872] and [RFC4873].  Note that
 when MEPs are required for the OAM CC function and the MEPs exist at
 LSP transit nodes, each MEP is instantiated at a hierarchical LSP end
 point, and protection is provided end-to-end for the hierarchical
 LSP.  (Protection can be signaled using either [RFC4872] or [RFC4873]
 defined procedures.)  The use of Notify messages to trigger
 protection switching and recovery is not required in MPLS-TP, as this
 function is expected to be supported via OAM.  However, its use is
 not precluded.

4.1.10. Control-Plane Reference Points (E-NNI, I-NNI, UNI)

 The majority of RFCs about the GMPLS control plane define the control
 plane from the context of an internal Network-to-Network Interface
 (I-NNI).  In the MPLS-TP context, some operators may choose to deploy
 signaled interfaces across User-to-Network Interfaces (UNIs) and
 across inter-provider, external Network-to-Network Interfaces
 (E-NNIs).  Such support is embodied in [RFC4208] for UNIs and in
 [RFC5787] for routing areas in support of E-NNIs.  This work may
 require extensions in order to meet the specific needs of an MPLS-TP
 UNI and E-NNI.

4.2. OAM, MEP (Hierarchy), MIP Configuration and Control

 MPLS-TP is defined to support a comprehensive set of MPLS-TP OAM
 functions.  The MPLS-TP control plane will not itself provide OAM
 functions, but it will be used to instantiate and otherwise control
 MPLS-TP OAM functions.
 Specific OAM requirements for MPLS-TP are documented in [RFC5860].
 This document also states that it is required that the control plane
 be able to configure and control OAM entities.  This requirement is
 not yet addressed by the existing RFCs, but such work is now under
 way, e.g., [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT].
 Many OAM functions occur on a per-LSP basis, are typically in-band,
 and are initiated immediately after LSP establishment.  Hence, it is
 desirable that such functions be established and activated via the

Andersson, et al. Informational [Page 32] RFC 6373 MPLS-TP Control Plane Framework September 2011

 same control-plane signaling used to set up the LSP, as this
 effectively synchronizes OAM with the LSP lifetime and avoids the
 extra overhead and potential errors associated with separate OAM
 configuration mechanisms.

4.2.1. Management-Plane Support

 There is no MPLS-TP requirement for a standardized management
 interface to the MPLS-TP control plane.  That said, MPLS and GMPLS
 support a number of standardized management functions.  These include
 the MPLS-TE/GMPLS TE Database Management Information Base [TE-MIB];
 the MPLS-TE MIB [RFC3812]; the MPLS LSR MIB [RFC3813]; the GMPLS TE
 MIB [RFC4802]; and the GMPLS LSR MIB [RFC4803].  These MIB modules
 may be used in MPLS-TP networks.  A general overview of MPLS-TP
 related MIB modules can be found in [TP-MIB].  Network management
 requirements for MPLS-based transport networks are provided in
 [RFC5951].

4.2.1.1. Recovery Triggers

 The GMPLS control plane allows for management-plane recovery triggers
 and directly supports control-plane recovery triggers.  Support for
 control-plane recovery triggers is defined in [RFC4872], which refers
 to the triggers as "Recovery Commands".  These commands can be used
 with both end-to-end and segment recovery, but are always controlled
 on an end-to-end basis.  The recovery triggers/commands defined in
 [RFC4872] are:
    a. Lockout of recovery LSP
    b. Lockout of normal traffic
    c. Forced switch for normal traffic
    d. Requested switch for normal traffic
    e. Requested switch for recovery LSP
 Note that control-plane triggers are typically invoked in response to
 a management-plane request at the ingress.

4.2.1.2. Management-Plane / Control-Plane Ownership Transfer

 In networks where both the control plane and management plane are
 provided, LSP provisioning can be done either by the control plane or
 management plane.  As mentioned in the requirements section above, it
 must be possible to transfer, or handover, a management-plane-created
 LSP to the control-plane domain and vice versa.  [RFC5493] defines

Andersson, et al. Informational [Page 33] RFC 6373 MPLS-TP Control Plane Framework September 2011

 the specific requirements for an LSP ownership handover procedure.
 It must be possible for the control plane to provide the management
 plane, in a reliable manner, with the status or result of an
 operation performed by the management plane.  This notification may
 be either synchronous or asynchronous with respect to the operation.
 Moreover, it must be possible for the management plane to monitor the
 status of the control plane, for example, the status of a TE link,
 its available resources, etc.  This monitoring may be based on
 queries initiated by the management plane or on notifications
 generated by the control plane.  A mechanism must be made available
 by the control plane to the management plane to log operation of a
 control-plane LSP; that is, it must be possible from the NMS to have
 a clear view of the life (traffic hit, action performed, signaling,
 etc.) of a given LSP.  The LSP handover procedure for MPLS-TP LSPs is
 supported via [RFC5852].

4.3. GMPLS and MPLS-TP Requirements Table

 The following table shows how the MPLS-TP control-plane requirements
 can be met using the existing GMPLS control plane (which builds on
 the MPLS control plane).  Areas where additional specifications are
 required are also identified.  The table lists references based on
 the control-plane requirements as identified and numbered above in
 Section 2.
 +=======+===========================================================+
 | Req # | References                                                |
 +-------+-----------------------------------------------------------+
 |    1  | Generic requirement met by using Standards Track RFCs     |
 |    2  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307]     |
 |    3  | [RFC5145] + Formal Definition (See Section 4.4.1)         |
 |    4  | Generic requirement met by using Standards Track RFCs     |
 |    5  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307]     |
 |    6  | [RFC3471], [RFC3473], [RFC4875]                           |
 |    7  | [RFC3471], [RFC3473] +                                    |
 |       |    Associated bidirectional LSPs (See Section 4.4.2)      |
 |    8  | [RFC4875]                                                 |
 |    9  | [RFC3473]                                                 |
 |   10  | Associated bidirectional LSPs (See Section 4.4.2)         |
 |   11  | Associated bidirectional LSPs (See Section 4.4.2)         |
 |   12  | [RFC3473]                                                 |
 |   13  | [RFC5467] (Currently Experimental; See Section 4.4.3)     |
 |   14  | [RFC3945], [RFC3473], [RFC4202], [RFC4203], [RFC5307]     |
 |   15  | [RFC3945], [RFC3473], [RFC4202], [RFC4203], [RFC5307]     |
 |   16  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307]     |
 |   17  | [RFC3945], [RFC4202] + proper vendor implementation       |
 |   18  | [RFC3945], [RFC4202] + proper vendor implementation       |
 |   19  | [RFC3945], [RFC4202]                                      |

Andersson, et al. Informational [Page 34] RFC 6373 MPLS-TP Control Plane Framework September 2011

 |   20  | [RFC3473]                                                 |
 |   21  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307],    |
 |       |     [RFC5151]                                             |
 |   22  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307],    |
 |       |     [RFC5151]                                             |
 |   23  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307]     |
 |   24  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307]     |
 |   25  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307],    |
 |       |     [RFC6107]                                             |
 |   26  | [RFC3473], [RFC4875]                                      |
 |   27  | [RFC3473], [RFC4875]                                      |
 |   28  | [RFC3945], [RFC3471], [RFC4202]                           |
 |   29  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307]     |
 |   30  | [RFC3945], [RFC3471], [RFC4202]                           |
 |   31  | [RFC3945], [RFC3471], [RFC4202]                           |
 |   32  | [RFC4208], [RFC4974], [RFC5787], [RFC6001]                |
 |   33  | [RFC3473], [RFC4875]                                      |
 |   34  | [RFC4875]                                                 |
 |   35  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307]     |
 |   36  | [RFC3473], [RFC3209] (Make-before-break)                  |
 |   37  | [RFC3473], [RFC3209] (Make-before-break)                  |
 |   38  | [RFC4139], [RFC4258], [RFC5787]                           |
 |   39  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307]     |
 |   40  | [RFC3473], [RFC5063]                                      |
 |   41  | [RFC3945], [RFC3471], [RFC4202], [RFC4208]                |
 |   42  | [RFC3945], [RFC3471], [RFC4202]                           |
 |   43  | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]    |
 |   44  | [RFC6107], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]               |
 |   45  | [RFC3473], [RFC4203], [RFC5307], [RFC5063]                |
 |   46  | [RFC5493]                                                 |
 |   47  | [RFC4872], [RFC4873]                                      |
 |   48  | [RFC3945], [RFC3471], [RFC4202]                           |
 |   49  | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) |
 |   50  | [RFC4872], [RFC4873]                                      |
 |   51  | [RFC4872], [RFC4873] + proper vendor implementation       |
 |   52  | [RFC4872], [RFC4873], [GMPLS-PS]                          |
 |   53  | [RFC4872], [RFC4873]                                      |
 |   54  | [RFC3473], [RFC4872], [RFC4873], [GMPLS-PS]               |
 |       |     Timers are a local implementation matter              |
 |   55  | [RFC4872], [RFC4873], [GMPLS-PS] +                        |
 |       |     implementation of timers                              |
 |   56  | [RFC4872], [RFC4873], [GMPLS-PS]                          |
 |   57  | [RFC4872], [RFC4873]                                      |
 |   58  | [RFC4872], [RFC4873]                                      |
 |   59  | [RFC4872], [RFC4873]                                      |
 |   60  | [RFC4872], [RFC4873], [RFC6107]                           |
 |   61  | [RFC4872], [RFC4873]                                      |
 |   62  | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) |

Andersson, et al. Informational [Page 35] RFC 6373 MPLS-TP Control Plane Framework September 2011

 |   63  | [RFC4872], [RFC4873]                                      |
 |   64  | [RFC4872], [RFC4873]                                      |
 |   65  | [RFC4872], [RFC4873]                                      |
 |   66  | [RFC4872], [RFC4873], [RFC6107]                           |
 |   67  | [RFC4872], [RFC4873]                                      |
 |   68  | [RFC3473], [RFC4872], [RFC4873]                           |
 |   69  | [RFC3473]                                                 |
 |   70  | [RFC3473], [RFC4872], [GMPLS-PS]                          |
 |   71  | [RFC3473], [RFC4872]                                      |
 |   72  | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]    |
 |   73  | [RFC4426], [RFC4872], [RFC4873]                           |
 |   74  | [RFC4426], [RFC4872], [RFC4873]                           |
 |   75  | [RFC4426], [RFC4872], [RFC4873]                           |
 |   76  | [RFC4426], [RFC4872], [RFC4873]                           |
 |   77  | [RFC4426], [RFC4872], [RFC4873]                           |
 |   78  | [RFC4426], [RFC4872], [RFC4873] + vendor implementation   |
 |   79  | [RFC4426], [RFC4872], [RFC4873]                           |
 |   80  | [RFC4426], [RFC4872], [RFC4873]                           |
 |   81  | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5)   |
 |   82  | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5)   |
 |   83  | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5)   |
 |   84  | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5)   |
 |   85  | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]    |
 |   86  | [RFC4872], [RFC4873]                                      |
 |   87  | [RFC4872], [RFC4873]                                      |
 |   88  | [RFC4872], [RFC4873], [TP-RING]                           |
 |   89  | [RFC4872], [RFC4873], [TP-RING]                           |
 |   90  | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) |
 |   91  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307]     |
 |   92  | [RFC3945], [RFC3473], [RFC2210], [RFC2211], [RFC2212]     |
 |   93  | Generic requirement on data plane (correct implementation)|
 |   94  | [RFC3473], [NO-PHP]                                       |
 |   95  | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) |
 |   96  | PW only requirement; see PW Requirements Table (5.2)      |
 |   97  | PW only requirement; see PW Requirements Table (5.2)      |
 |   98  | [RFC3945], [RFC3473], [RFC6107]                           |
 |   99  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] +   |
 |       |      [RFC5392] and [RFC5316]                              |
 |  100  | PW only requirement; see PW Requirements Table (5.2)      |
 |  101  | [RFC3473], [RFC4203], [RFC5307], [RFC5063]                |
 |  102  | [RFC4872], [RFC4873], [TP-RING]                           |
 |  103  | [RFC3945], [RFC3473], [RFC6107]                           |
 |  104  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]                          |
 |  105  | [RFC3473], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]               |
 |  106  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]                          |
 |  107  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5)       |
 |  108  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]                          |
 |  109  | [RFC3473], [RFC4872], [RFC4873]                           |

Andersson, et al. Informational [Page 36] RFC 6373 MPLS-TP Control Plane Framework September 2011

 |  110  | [RFC3473], [RFC4872], [RFC4873]                           |
 |  111  | [RFC3473], [RFC4783]                                      |
 |  112  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]                          |
 |  113  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5)       |
 |  114  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5)       |
 |  115  | [RFC3473]                                                 |
 |  116  | [RFC4426], [RFC4872], [RFC4873]                           |
 |  117  | [RFC3473], [RFC4872], [RFC4873]                           |
 |  118  | [RFC3473], [RFC4783]                                      |
 |  119  | [RFC3473]                                                 |
 |  120  | [RFC3473], [RFC4783]                                      |
 |  121  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5)       |
 |  122  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5)       |
 |  123  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT], [RFC6107]               |
 | 124 - |                                                           |
 |   135 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5)       |
 |  136a | [RFC3473]                                                 |
 |  136b | [RFC3473] + (See Sec. 4.4.7)                              |
 |  137a | [RFC3473]                                                 |
 |  137b | [RFC3473] + (See Sec. 4.4.7)                              |
 |  138  | PW only requirement; see PW Requirements Table (5.2)      |
 | 139 - |                                                           |
 |   143 | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.8)       |
 +=======+===========================================================+
             Table 1: GMPLS and MPLS-TP Requirements Table

4.4. Anticipated MPLS-TP-Related Extensions and Definitions

 This section identifies the extensions and other documents that have
 been identified as likely to be needed to support the full set of
 MPLS-TP control-plane requirements.

4.4.1. MPLS-TE to MPLS-TP LSP Control-Plane Interworking

 While no interworking function is expected in the data plane to
 support the interconnection of MPLS-TE and MPLS-TP networking, this
 is not the case for the control plane.  MPLS-TE networks typically
 use LSP signaling based on [RFC3209], while MPLS-TP LSPs will be
 signaled using GMPLS RSVP-TE, i.e., [RFC3473].  [RFC5145] identifies
 a set of solutions that are aimed to aid in the interworking of MPLS-
 TE and GMPLS control planes.  [RFC5145] work will serve as the
 foundation for a formal definition of MPLS to MPLS-TP control-plane
 interworking.

Andersson, et al. Informational [Page 37] RFC 6373 MPLS-TP Control Plane Framework September 2011

4.4.2. Associated Bidirectional LSPs

 GMPLS signaling, [RFC3473], supports unidirectional and co-routed,
 bidirectional point-to-point LSPs.  MPLS-TP also requires support for
 associated bidirectional point-to-point LSPs.  Such support will
 require an extension or a formal definition of how the LSP end points
 supporting an associated bidirectional service will coordinate the
 two LSPs used to provide such a service.  Per requirement 11, transit
 nodes that support an associated bidirectional service should be
 aware of the association of the LSPs used to support the service when
 both LSPs are supported on that transit node.  There are several
 existing protocol mechanisms on which to base such support,
 including, but not limited to:
    o  GMPLS calls [RFC4974].
    o  The ASSOCIATION object [RFC4872].
    o  The LSP_TUNNEL_INTERFACE_ID object [RFC6107].

4.4.3. Asymmetric Bandwidth LSPs

 [RFC5467] defines support for bidirectional LSPs that have different
 (asymmetric) bandwidth requirements for each direction.  That RFC can
 be used to meet the related MPLS-TP technical requirement, but it is
 currently an Experimental RFC.  To fully satisfy the MPLS-TP
 requirement, RFC 5467 will need to become a Standards Track RFC.

4.4.4. Recovery for P2MP LSPs

 The definitions of P2MP, [RFC4875], and GMPLS recovery, [RFC4872] and
 [RFC4873], do not explicitly cover their interactions.  MPLS-TP
 requires a formal definition of recovery techniques for P2MP LSPs.
 Such a formal definition will be based on existing RFCs and may not
 require any new protocol mechanisms but, nonetheless, must be
 documented.

4.4.5. Test Traffic Control and Other OAM Functions

 [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT] are examples of OAM-related
 control extensions to GMPLS.  These extensions cover a portion of,
 but not all, OAM-related control functions that have been identified
 in the context of MPLS-TP.  As discussed above, the MPLS-TP control
 plane must support the selection of which OAM function(s) (if any) to
 use (including support to select experimental OAM functions) and what
 OAM functionality to run, including Continuity Check (CC),

Andersson, et al. Informational [Page 38] RFC 6373 MPLS-TP Control Plane Framework September 2011

 Connectivity Verification (CV), packet loss, delay quantification,
 and diagnostic testing of a service.  Such support may be included in
 the listed documents or in other documents.

4.4.6. Diffserv Object Usage in GMPLS

 [RFC3270] and [RFC4124] define support for Diffserv-enabled MPLS
 LSPs.  While [RFC4124] references GMPLS signaling, there is no
 explicit discussion on the use of the Diffserv-related objects in
 GMPLS signaling.  A (possibly Informational) document on how GMPLS
 supports Diffserv LSPs is likely to prove useful in the context of
 MPLS-TP.

4.4.7. Support for MPLS-TP LSP Identifiers

 MPLS-TP uses two forms of LSP identifiers, see [RFC6370].  One form
 is based on existing GMPLS fields.  The other form is based on either
 the globally unique Attachment Interface Identifier (AII) defined in
 [RFC5003] or the ITU Carrier Code (ICC) defined in ITU-T
 Recommendation M.1400.  Neither form is currently supported in GMPLS,
 and such extensions will need to be documented.

4.4.8. Support for MPLS-TP Maintenance Identifiers

 MPLS-TP defines several forms of maintenance-entity-related
 identifiers.  Both node-unique and global forms are defined.
 Extensions will be required to GMPLS to support these identifiers.
 These extensions may be added to existing works in progress, such as
 [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT], or may be defined in independent
 documents.

5. Pseudowires

5.1. LDP Functions and Pseudowires

 MPLS PWs are defined in [RFC3985] and [RFC5659], and provide for
 emulated services over an MPLS Packet Switched Network (PSN).
 Several types of PWs have been defined: (1) Ethernet PWs providing
 for Ethernet port or Ethernet VLAN transport over MPLS [RFC4448], (2)
 High-Level Data Link Control (HDLC) / PPP PW providing for HDLC/PPP
 leased line transport over MPLS [RFC4618], (3) ATM PWs [RFC4816], (4)
 Frame Relay PWs [RFC4619], and (5) circuit Emulation PWs [RFC4553].
 Today's transport networks based on Plesiochronous Digital Hierarchy
 (PDH), WDM, or SONET/SDH provide transport for PDH or SONET (e.g.,
 ATM over SONET or Packet PPP over SONET) client signals with no
 payload awareness.  Implementing PW capability allows for the use of
 an existing technology to substitute the Time-Division Multiplexing

Andersson, et al. Informational [Page 39] RFC 6373 MPLS-TP Control Plane Framework September 2011

 (TDM) transport with packet-based transport, using well-defined PW
 encapsulation methods for carrying various packet services over MPLS,
 and providing for potentially better bandwidth utilization.
 There are two general classes of PWs: (1) Single-Segment Pseudowires
 (SS-PWs) [RFC3985] and (2) Multi-segment Pseudowires (MS-PWs)
 [RFC5659].  An MPLS-TP network domain may transparently transport a
 PW whose end points are within a client network.  Alternatively, an
 MPLS-TP edge node may be the Terminating PE (T-PE) for a PW,
 performing adaptation from the native attachment circuit technology
 (e.g., Ethernet 802.1Q) to an MPLS PW that is then transported in an
 LSP over an MPLS-TP network.  In this way, the PW is analogous to a
 transport channel in a TDM network, and the LSP is equivalent to a
 container of multiple non-concatenated channels, albeit they are
 packet containers.  An MPLS-TP network may also contain Switching PEs
 (S-PEs) for a Multi-Segment PW whereby the T-PEs may be at the edge
 of an MPLS-TP network or in a client network.  In the latter case, a
 T-PE in a client network performs the adaptation of the native
 service to MPLS and the MPLS-TP network performs pseudowire
 switching.
 The SS-PW signaling control plane is based on targeted LDP (T-LDP)
 with specific procedures defined in [RFC4447].  The MS-PW signaling
 control plane is also based on T-LDP as allowed for in [RFC5659],
 [RFC6073], and [MS-PW-DYNAMIC].  An MPLS-TP network shall use the
 same PW signaling protocols and procedures for placing SS-PWs and
 MS-PWs.  This will leverage existing technology as well as facilitate
 interoperability with client networks with native attachment circuits
 or PW segments that are switched across an MPLS-TP network.

5.1.1. Management-Plane Support

 There is no MPLS-TP requirement for a standardized management
 interface to the MPLS-TP control plane.  A general overview of MPLS-
 TP-related MIB modules can be found in [TP-MIB].  Network management
 requirements for MPLS-based transport networks are provided in
 [RFC5951].

5.2. PW Control (LDP) and MPLS-TP Requirements Table

 The following table shows how the MPLS-TP control-plane requirements
 can be met using the existing LDP control plane for pseudowires
 (targeted LDP).  Areas where additional specifications are required
 are also identified.  The table lists references based on the
 control-plane requirements as identified and numbered above in
 Section 2.

Andersson, et al. Informational [Page 40] RFC 6373 MPLS-TP Control Plane Framework September 2011

 In the table below, several of the requirements shown are addressed
 -- in part or in full -- by the use of MPLS-TP LSPs to carry
 pseudowires.  This is reflected by including "TP-LSPs" as a reference
 for those requirements.  Section 5.3.2 provides additional context
 for the binding of PWs to TP-LSPs.

Andersson, et al. Informational [Page 41] RFC 6373 MPLS-TP Control Plane Framework September 2011

 +=======+===========================================================+
 | Req # | References                                                |
 +-------+-----------------------------------------------------------+
 |    1  | Generic requirement met by using Standards Track RFCs     |
 |    2  | [RFC3985], [RFC4447], Together with TP-LSPs (Sec. 4.3)    |
 |    3  | [RFC3985], [RFC4447]                                      |
 |    4  | Generic requirement met by using Standards Track RFCs     |
 |    5  | [RFC3985], [RFC4447], Together with TP-LSPs               |
 |    6  | [RFC3985], [RFC4447], [PW-P2MPR], [PW-P2MPE] + TP-LSPs    |
 |    7  | [RFC3985], [RFC4447], + TP-LSPs                           |
 |    8  | [PW-P2MPR], [PW-P2MPE]                                    |
 |    9  | [RFC3985], end-node only involvement for PW               |
 |   10  | [RFC3985], proper vendor implementation                   |
 |   11  | [RFC3985], end-node only involvement for PW               |
 | 12-13 | [RFC3985], [RFC4447], See Section 5.3.4                   |
 |   14  | [RFC3985], [RFC4447]                                      |
 |   15  | [RFC4447], [RFC3478], proper vendor implementation        |
 |   16  | [RFC3985], [RFC4447]                                      |
 | 17-18 | [RFC3985], proper vendor implementation                   |
 | 19-26 | [RFC3985], [RFC4447], [RFC5659], implementation           |
 |   27  | [RFC4448], [RFC4816], [RFC4618], [RFC4619], [RFC4553]     |
 |       | [RFC4842], [RFC5287]                                      |
 |   28  | [RFC3985]                                                 |
 | 29-31 | [RFC3985], [RFC4447]                                      |
 |   32  | [RFC3985], [RFC4447], [RFC5659], See Section 5.3.6        |
 |   33  | [RFC4385], [RFC4447], [RFC5586]                           |
 |   34  | [PW-P2MPR], [PW-P2MPE]                                    |
 |   35  | [RFC4863]                                                 |
 | 36-37 | [RFC3985], [RFC4447], See Section 5.3.4                   |
 |   38  | Provided by TP-LSPs                                       |
 |   39  | [RFC3985], [RFC4447], + TP-LSPs                           |
 |   40  | [RFC3478]                                                 |
 | 41-42 | [RFC3985], [RFC4447]                                      |
 | 43-44 | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.5       |
 |   45  | [RFC3985], [RFC4447], [RFC5659] + TP-LSPs                 |
 |   46  | [RFC3985], [RFC4447], + TP-LSPs - See Section 5.3.3       |
 |   47  | [PW-RED], [PW-REDB]                                       |
 | 48-49 | [RFC3985], [RFC4447], + TP-LSPs, implementation           |
 | 50-52 | Provided by TP-LSPs, and Section 5.3.5                    |
 | 53-55 | [RFC3985], [RFC4447], See Section 5.3.5                   |
 |   56  | [PW-RED], [PW-REDB]                                       |
 |       | revertive/non-revertive behavior is a local matter for PW |
 | 57-58 | [PW-RED], [PW-REDB]                                       |
 | 59-81 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5  |
 | 82-83 | [RFC5085], [RFC5586], [RFC5885]                           |
 | 84-89 | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5  |
 | 90-95 | [RFC3985], [RFC4447], + TP-LSPs, implementation           |
 |   96  | [RFC4447], [MS-PW-DYNAMIC]                                |

Andersson, et al. Informational [Page 42] RFC 6373 MPLS-TP Control Plane Framework September 2011

 |   97  | [RFC4447]                                                 |
 |  98 - |                                                           |
 |   99  | Not Applicable to PW                                      |
 |  100  | [RFC4447]                                                 |
 |  101  | [RFC3478]                                                 |
 |  102  | [RFC3985], + TP-LSPs                                      |
 |  103  | Not Applicable to PW                                      |
 |  104  | [PW-OAM]                                                  |
 |  105  | [PW-OAM]                                                  |
 | 106 - |                                                           |
 |   108 | [RFC5085], [RFC5586], [RFC5885]                           |
 |  109  | [RFC5085], [RFC5586], [RFC5885]                           |
 |       | fault reporting and protection triggering is a local      |
 |       | matter for PW                                             |
 |  110  | [RFC5085], [RFC5586], [RFC5885]                           |
 |       | fault reporting and protection triggering is a local      |
 |       | matter for PW                                             |
 |  111  | [RFC4447]                                                 |
 |  112  | [RFC4447], [RFC5085], [RFC5586], [RFC5885]                |
 |  113  | [RFC5085], [RFC5586], [RFC5885]                           |
 |  114  | [RFC5085], [RFC5586], [RFC5885]                           |
 |  115  | path traversed by PW is determined by LSP path; see       |
 |       | GMPLS and MPLS-TP Requirements Table, Section 4.3         |
 |  116  | [PW-RED], [PW-REDB], administrative control of redundant  |
 |       | PW is a local matter at the PW head-end                   |
 |  117  | [PW-RED], [PW-REDB], [RFC5085], [RFC5586], [RFC5885]      |
 |  118  | [RFC3985], [RFC4447], [PW-RED], [PW-REDB], Section 5.3.5  |
 |  119  | [RFC4447]                                                 |
 | 120 - |                                                           |
 |   125 | [RFC5085], [RFC5586], [RFC5885]                           |
 | 126 - |                                                           |
 |   130 | [PW-OAM]                                                  |
 |  131  | Section 5.3.5                                             |
 |  132  | [PW-OAM]                                                  |
 |  133  | [PW-OAM]                                                  |
 |  134  | Section 5.3.5                                             |
 |  135  | [PW-OAM]                                                  |
 |  136  | Not Applicable to PW                                      |
 |  137  | Not Applicable to PW                                      |
 |  138  | [RFC4447], [RFC5003], [MS-PW-DYNAMIC]                     |
 | 139 - |                                                           |
 |   143 | [PW-OAM]                                                  |
 +=======+===========================================================+
       Table 2: PW Control (LDP) and MPLS-TP Requirements Table

Andersson, et al. Informational [Page 43] RFC 6373 MPLS-TP Control Plane Framework September 2011

5.3. Anticipated MPLS-TP-Related Extensions

 Existing control protocol and procedures will be reused as much as
 possible to support MPLS-TP.  However, when using PWs in MPLS-TP, a
 set of new requirements is defined that may require extensions of the
 existing control mechanisms.  This section clarifies the areas where
 extensions are needed based on the requirements that are related to
 the PW control plane and documented in [RFC5654].
 Table 2 lists how requirements defined in [RFC5654] are expected to
 be addressed.
 The baseline requirement for extensions to support transport
 applications is that any new mechanisms and capabilities must be able
 to interoperate with existing IETF MPLS [RFC3031] and IETF PWE3
 [RFC3985] control and data planes where appropriate.  Hence,
 extensions of the PW control plane must be in-line with the
 procedures defined in [RFC4447], [RFC6073], and [MS-PW-DYNAMIC].

5.3.1. Extensions to Support Out-of-Band PW Control

 For MPLS-TP, it is required that the data and control planes can be
 both logically and physically separated.  That is, the PW control
 plane must be able to operate out-of-band (OOB).  This separation
 ensures, among other things, that in the case of control-plane
 failures the data plane is not affected and can continue to operate
 normally.  This was not a design requirement for the current PW
 control plane.  However, due to the PW concept, i.e., PWs are
 connecting logical entities ('forwarders'), and the operation of the
 PW control protocol, i.e., only edge PE nodes (T-PE, S-PE) take part
 in the signaling exchanges: moving T-LDP out-of-band seems to be,
 theoretically, a straightforward exercise.
 In fact, as a strictly local matter, ensuring that targeted LDP
 (T-LDP) uses out-of-band signaling requires only that the local
 implementation is configured in such a way that reachability for a
 target LSR address is via the out-of-band channel.
 More precisely, if IP addressing is used in the MPLS-TP control
 plane, then T-LDP addressing can be maintained, although all
 addresses will refer to control-plane entities.  Both the PWid
 Forwarding Equivalence Class (FEC) and Generalized PWid FEC Elements
 can possibly be used in an OOB case as well.  (Detailed evaluation is
 outside the scope of this document.)  The PW label allocation and
 exchange mechanisms should be reused without change.

Andersson, et al. Informational [Page 44] RFC 6373 MPLS-TP Control Plane Framework September 2011

5.3.2. Support for Explicit Control of PW-to-LSP Binding

 Binding a PW to an LSP, or PW segments to LSPs, is left to nodes
 acting as T-PEs and S-PEs or a control-plane entity that may be the
 same one signaling the PW.  However, an extension of the PW signaling
 protocol is required to allow the LSR at the signal initiation end to
 inform the targeted LSR (at the signal termination end) to which LSP
 the resulting PW is to be bound, in the event that more than one such
 LSP exists and the choice of LSPs is important to the service being
 setup (for example, if the service requires co-routed bidirectional
 paths).  This is also particularly important to support transport
 path (symmetric and asymmetric) bandwidth requirements.
 For transport services, MPLS-TP requires support for bidirectional
 traffic that follows congruent paths.  Currently, each direction of a
 PW or a PW segment is bound to a unidirectional LSP that extends
 between two T-PEs, two S-PEs, or a T-PE and an S-PE.  The
 unidirectional LSPs in both directions are not required to follow
 congruent paths, and therefore both directions of a PW may not follow
 congruent paths, i.e., they are associated bidirectional paths.  The
 only requirement in [RFC5659] is that a PW or a PW segment shares the
 same T-PEs in both directions and the same S-PEs in both directions.
 MPLS-TP imposes new requirements on the PW control plane, in
 requiring that both end points map the PW or PW segment to the same
 transport path for the case where this is an objective of the
 service.  When a bidirectional LSP is selected on one end to
 transport the PW, a mechanism is needed that signals to the remote
 end which LSP has been selected locally to transport the PW.  This
 would be accomplished by adding a new TLV to PW signaling.
 Note that this coincides with the gap identified for OOB support: a
 new mechanism is needed to allow explicit binding of a PW to the
 supporting transport LSP.
 The case of unidirectional transport paths may also require
 additional protocol mechanisms, as today's PWs are always
 bidirectional.  One potential approach for providing a unidirectional
 PW-based transport path is for the PW to associate different
 (asymmetric) bandwidths in each direction, with a zero or minimal
 bandwidth for the return path.  This approach is consistent with
 Section 3.8.2 of [RFC5921] but does not address P2MP paths.

5.3.3. Support for Dynamic Transfer of PW Control/Ownership

 In order to satisfy requirement 47 (as defined in Section 2), it will
 be necessary to specify methods for transfer of PW ownership from the
 management to the control plane (and vice versa).

Andersson, et al. Informational [Page 45] RFC 6373 MPLS-TP Control Plane Framework September 2011

5.3.4. Interoperable Support for PW/LSP Resource Allocation

 Transport applications may require resource guarantees.  For such
 transport LSPs, resource reservation mechanisms are provided via
 RSVP-TE and the use of Diffserv.  If multiple PWs are multiplexed
 into the same transport LSP resources, contention may occur.
 However, local policy at PEs should ensure proper resource sharing
 among PWs mapped into a resource-guaranteed LSP.  In the case of
 MS-PWs, signaling carries the PW traffic parameters [MS-PW-DYNAMIC]
 to enable admission control of a PW segment over a resource-
 guaranteed LSP.
 In conjunction with explicit PW-to-LSP binding, existing mechanisms
 may be sufficient; however, this needs to be verified in detailed
 evaluation.

5.3.5. Support for PW Protection and PW OAM Configuration

 Many of the requirements listed in Section 2 are intended to support
 connectivity and performance monitoring (grouped together as OAM), as
 well as protection conformant with the transport services model.
 In general, protection of MPLS-TP transported services is provided by
 way of protection of transport LSPs.  PW protection requires that
 mechanisms be defined to support redundant pseudowires, including a
 mechanism already described above for associating such pseudowires
 with specific protected ("working" and "protection") LSPs.  Also
 required are definitions of local protection control functions, to
 include test/verification operations, and protection status signals
 needed to ensure that PW termination points are in agreement as to
 which of a set of redundant pseudowires are in use for which
 transport services at any given point in time.
 Much of this work is currently being done in documents [PW-RED] and
 [PW-REDB] that define, respectively, how to establish redundant
 pseudowires and how to indicate which is in use.  Additional work may
 be required.
 Protection switching may be triggered manually by the operator, or as
 a result of loss of connectivity (detected using the mechanisms of
 [RFC5085] and [RFC5586]), or service degradation (detected using
 mechanisms yet to be defined).
 Automated protection switching is just one of the functions for which
 a transport service requires OAM.  OAM is generally referred to as
 either "proactive" or "on-demand", where the distinction is whether a
 specific OAM tool is being used continuously over time (for the
 purpose of detecting a need for protection switching, for example) or

Andersson, et al. Informational [Page 46] RFC 6373 MPLS-TP Control Plane Framework September 2011

 is only used -- either a limited number of times or over a short
 period of time -- when explicitly enabled (for diagnostics, for
 example).
 PW OAM currently consists of connectivity verification defined by
 [RFC5085].  Work is currently in progress to extend PW OAM to include
 bidirectional forwarding detection (BFD) in [RFC5885], and work has
 begun on extending BFD to include performance-related monitor
 functions.

5.3.6. Client-Layer and Cross-Provider Interfaces to PW Control

 Additional work is likely to be required to define consistent access
 by a client-layer network, as well as between provider networks, to
 control information available to each type of network, for example,
 about the topology of an MS-PW.  This information may be required by
 the client-layer network in order to provide hints that may help to
 avoid establishment of fate-sharing alternate paths.  Such work will
 need to fit within the ASON architecture; see requirement 38 above.

5.4. ASON Architecture Considerations

 MPLS-TP PWs are always transported using LSPs, and these LSPs will
 either have been statically provisioned or signaled using GMPLS.
 For LSPs signaled using the MPLS-TP LSP control plane (GMPLS),
 conformance with the ASON architecture is as described in Section 1.2
 ("Basic Approach"), bullet 4, of this framework document.
 As discussed above in Section 5.3, there are anticipated extensions
 in the following areas that may be related to ASON architecture:
  1. PW-to-LSP binding (Section 5.3.2)
  2. PW/LSP resource allocation (Section 5.3.4)
  3. PW protection and OAM configuration (Section 5.3.5)
  4. Client-layer interfaces for PW control (Section 5.3.6)
 This work is expected to be consistent with ASON architecture and may
 require additional specification in order to achieve this goal.

6. Security Considerations

 This document primarily describes how existing mechanisms can be used
 to meet the MPLS-TP control-plane requirements.  The documents that
 describe each mechanism contain their own security considerations
 sections.  For a general discussion on MPLS- and GMPLS-related

Andersson, et al. Informational [Page 47] RFC 6373 MPLS-TP Control Plane Framework September 2011

 security issues, see the MPLS/GMPLS security framework [RFC5920].  As
 mentioned above in Section 2.4, there are no specific MPLS-TP
 control-plane security requirements.
 This document also identifies a number of needed control-plane
 extensions.  It is expected that the documents that define such
 extensions will also include any appropriate security considerations.

7. Acknowledgments

 The authors would like to acknowledge the contributions of Yannick
 Brehon, Diego Caviglia, Nic Neate, Dave Mcdysan, Dan Frost, and Eric
 Osborne to this work.  We also thank Dan Frost in his help responding
 to Last Call comments.

8. References

8.1. Normative References

 [RFC2210]  Wroclawski, J., "The Use of RSVP with IETF Integrated
            Services", RFC 2210, September 1997.
 [RFC2211]  Wroclawski, J., "Specification of the Controlled-Load
            Network Element Service", RFC 2211, September 1997.
 [RFC2212]  Shenker, S., Partridge, C., and R. Guerin, "Specification
            of Guaranteed Quality of Service", RFC 2212, September
            1997.
 [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
            Label Switching Architecture", RFC 3031, January 2001.
 [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
            and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
            Tunnels", RFC 3209, December 2001.
 [RFC3471]  Berger, L., Ed., "Generalized Multi-Protocol Label
            Switching (GMPLS) Signaling Functional Description", RFC
            3471, January 2003.
 [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
            Switching (GMPLS) Signaling Resource ReserVation Protocol-
            Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
            January 2003.
 [RFC3478]  Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful
            Restart Mechanism for Label Distribution Protocol", RFC
            3478, February 2003.

Andersson, et al. Informational [Page 48] RFC 6373 MPLS-TP Control Plane Framework September 2011

 [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
            (TE) Extensions to OSPF Version 2", RFC 3630, September
            2003.
 [RFC4124]  Le Faucheur, F., Ed., "Protocol Extensions for Support of
            Diffserv-aware MPLS Traffic Engineering", RFC 4124, June
            2005.
 [RFC4202]  Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
            Extensions in Support of Generalized Multi-Protocol Label
            Switching (GMPLS)", RFC 4202, October 2005.
 [RFC4203]  Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
            in Support of Generalized Multi-Protocol Label Switching
            (GMPLS)", RFC 4203, October 2005.
 [RFC4206]  Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
            Hierarchy with Generalized Multi-Protocol Label Switching
            (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
 [RFC4385]  Bryant, S., Swallow, G., Martini, L., and D. McPherson,
            "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for
            Use over an MPLS PSN", RFC 4385, February 2006.
 [RFC4447]  Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
            G. Heron, "Pseudowire Setup and Maintenance Using the
            Label Distribution Protocol (LDP)", RFC 4447, April 2006.
 [RFC4448]  Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
            "Encapsulation Methods for Transport of Ethernet over MPLS
            Networks", RFC 4448, April 2006.
 [RFC4842]  Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig,
            "Synchronous Optical Network/Synchronous Digital Hierarchy
            (SONET/SDH) Circuit Emulation over Packet (CEP)", RFC
            4842, April 2007.
 [RFC4863]  Martini, L. and G. Swallow, "Wildcard Pseudowire Type",
            RFC 4863, May 2007.
 [RFC4872]  Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
            Ed., "RSVP-TE Extensions in Support of End-to-End
            Generalized Multi-Protocol Label Switching (GMPLS)
            Recovery", RFC 4872, May 2007.
 [RFC4873]  Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
            "GMPLS Segment Recovery", RFC 4873, May 2007.

Andersson, et al. Informational [Page 49] RFC 6373 MPLS-TP Control Plane Framework September 2011

 [RFC4929]  Andersson, L., Ed., and A. Farrel, Ed., "Change Process
            for Multiprotocol Label Switching (MPLS) and Generalized
            MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 4929,
            June 2007.
 [RFC4974]  Papadimitriou, D. and A. Farrel, "Generalized MPLS (GMPLS)
            RSVP-TE Signaling Extensions in Support of Calls", RFC
            4974, August 2007.
 [RFC5063]  Satyanarayana, A., Ed., and R. Rahman, Ed., "Extensions to
            GMPLS Resource Reservation Protocol (RSVP) Graceful
            Restart", RFC 5063, October 2007.
 [RFC5151]  Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-
            Domain MPLS and GMPLS Traffic Engineering -- Resource
            Reservation Protocol-Traffic Engineering (RSVP-TE)
            Extensions", RFC 5151, February 2008.
 [RFC5287]  Vainshtein, A. and Y(J). Stein, "Control Protocol
            Extensions for the Setup of Time-Division Multiplexing
            (TDM) Pseudowires in MPLS Networks", RFC 5287, August
            2008.
 [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
            Engineering", RFC 5305, October 2008.
 [RFC5307]  Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
            in Support of Generalized Multi-Protocol Label Switching
            (GMPLS)", RFC 5307, October 2008.
 [RFC5316]  Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
            Support of Inter-Autonomous System (AS) MPLS and GMPLS
            Traffic Engineering", RFC 5316, December 2008.
 [RFC5392]  Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
            Support of Inter-Autonomous System (AS) MPLS and GMPLS
            Traffic Engineering", RFC 5392, January 2009.
 [RFC5467]  Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J.
            Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
            Switched Paths (LSPs)", RFC 5467, March 2009.
 [RFC5586]  Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
            "MPLS Generic Associated Channel", RFC 5586, June 2009.
 [RFC5654]  Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
            Sprecher, N., and S. Ueno, "Requirements of an MPLS
            Transport Profile", RFC 5654, September 2009.

Andersson, et al. Informational [Page 50] RFC 6373 MPLS-TP Control Plane Framework September 2011

 [RFC5860]  Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
            "Requirements for Operations, Administration, and
            Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
            May 2010.
 [RFC5921]  Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
            L., and L. Berger, "A Framework for MPLS in Transport
            Networks", RFC 5921, July 2010.
 [RFC5960]  Frost, D., Ed., Bryant, S., Ed., and M. Bocci, Ed., "MPLS
            Transport Profile Data Plane Architecture", RFC 5960,
            August 2010.
 [RFC6370]  Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
            Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
 [RFC6371]  Busi, I., Ed., and D. Allan, Ed., "Operations,
            Administration, and Maintenance Framework for MPLS-Based
            Transport Networks", RFC 6371, September 2011.
 [RFC6372]  Sprecher, N., Ed., and A. Farrel, Ed., "MPLS Transport
            Profile (MPLS-TP) Survivability Framework", RFC 6372,
            September 2011.

8.2. Informative References

 [CCAMP-OAM-EXT]
            Bellagamba, E., Ed., Andersson, L., Ed., Skoldstrom, P.,
            Ed., Ward, D., and A. Takacs, "Configuration of Pro-Active
            Operations, Administration, and Maintenance (OAM)
            Functions for MPLS-based Transport Networks using RSVP-
            TE", Work in Progress, July 2011.
 [CCAMP-OAM-FWK]
            Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
            extensions for OAM Configuration", Work in Progress, July
            2011.
 [GMPLS-PS] Takacs, A., Fondelli, F., and B. Tremblay, "GMPLS RSVP-TE
            Recovery Extension for data plane initiated reversion and
            protection timer signalling", Work in Progress, April
            2011.
 [ITU.G8080.2006]
            International Telecommunication Union, "Architecture for
            the automatically switched optical network (ASON)", ITU-T
            Recommendation G.8080, June 2006.

Andersson, et al. Informational [Page 51] RFC 6373 MPLS-TP Control Plane Framework September 2011

 [ITU.G8080.2008]
            International Telecommunication Union, "Architecture for
            the automatically switched optical network (ASON)
            Amendment 1", ITU-T Recommendation G.8080 Amendment 1,
            March 2008.
 [MS-PW-DYNAMIC]
            Martini, L., Ed., Bocci, M., Ed., and F. Balus, Ed.,
            "Dynamic Placement of Multi Segment Pseudowires", Work in
            Progress, July 2011.
 [NO-PHP]   Ali, z., et al, "Non Penultimate Hop Popping Behavior and
            out-of-band mapping for RSVP-TE Label Switched Paths",
            Work in Progress, August 2011.
 [PW-OAM]   Zhang, F., Ed., Wu, B., Ed., and E. Bellagamba, Ed., "
            Label Distribution Protocol Extensions for Proactive
            Operations, Administration and Maintenance Configuration
            of Dynamic MPLS Transport Profile PseudoWire", Work in
            Progress, August 2011.
 [PW-P2MPE] Aggarwal, R. and F. Jounay, "Point-to-Multipoint Pseudo-
            Wire Encapsulation", Work in Progress, March 2010.
 [PW-P2MPR] Jounay, F., Ed., Kamite, Y., Heron, G., and M. Bocci,
            "Requirements and Framework for Point-to-Multipoint
            Pseudowire", Work in Progress, July 2011.
 [PW-RED]   Muley, P., Ed., Aissaoui, M., Ed., and M. Bocci,
            "Pseudowire Redundancy", Work in Progress, July 2011.
 [PW-REDB]  Muley, P., Ed., and M. Aissaoui, Ed., "Preferential
            Forwarding Status Bit", Work in Progress, March 2011.
 [RFC3270]  Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
            P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
            Protocol Label Switching (MPLS) Support of Differentiated
            Services", RFC 3270, May 2002.
 [RFC3468]  Andersson, L. and G. Swallow, "The Multiprotocol Label
            Switching (MPLS) Working Group decision on MPLS signaling
            protocols", RFC 3468, February 2003.
 [RFC3472]  Ashwood-Smith, P., Ed., and L. Berger, Ed., "Generalized
            Multi-Protocol Label Switching (GMPLS) Signaling
            Constraint-based Routed Label Distribution Protocol (CR-
            LDP) Extensions", RFC 3472, January 2003.

Andersson, et al. Informational [Page 52] RFC 6373 MPLS-TP Control Plane Framework September 2011

 [RFC3477]  Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
            in Resource ReSerVation Protocol - Traffic Engineering
            (RSVP-TE)", RFC 3477, January 2003.
 [RFC3812]  Srinivasan, C., Viswanathan, A., and T. Nadeau,
            "Multiprotocol Label Switching (MPLS) Traffic Engineering
            (TE) Management Information Base (MIB)", RFC 3812, June
            2004.
 [RFC3813]  Srinivasan, C., Viswanathan, A., and T. Nadeau,
            "Multiprotocol Label Switching (MPLS) Label Switching
            Router (LSR) Management Information Base (MIB)", RFC 3813,
            June 2004.
 [RFC3945]  Mannie, E., Ed., "Generalized Multi-Protocol Label
            Switching (GMPLS) Architecture", RFC 3945, October 2004.
 [RFC3985]  Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation
            Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
 [RFC4139]  Papadimitriou, D., Drake, J., Ash, J., Farrel, A., and L.
            Ong, "Requirements for Generalized MPLS (GMPLS) Signaling
            Usage and Extensions for Automatically Switched Optical
            Network (ASON)", RFC 4139, July 2005.
 [RFC4201]  Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
            in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
 [RFC4208]  Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
            "Generalized Multiprotocol Label Switching (GMPLS) User-
            Network Interface (UNI): Resource ReserVation Protocol-
            Traffic Engineering (RSVP-TE) Support for the Overlay
            Model", RFC 4208, October 2005.
 [RFC4258]  Brungard, D., Ed., "Requirements for Generalized Multi-
            Protocol Label Switching (GMPLS) Routing for the
            Automatically Switched Optical Network (ASON)", RFC 4258,
            November 2005.
 [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
            Label Switched (MPLS) Data Plane Failures", RFC 4379,
            February 2006.
 [RFC4426]  Lang, J., Ed., Rajagopalan, B., Ed., and D. Papadimitriou,
            Ed., "Generalized Multi-Protocol Label Switching (GMPLS)
            Recovery Functional Specification", RFC 4426, March 2006.

Andersson, et al. Informational [Page 53] RFC 6373 MPLS-TP Control Plane Framework September 2011

 [RFC4427]  Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery
            (Protection and Restoration) Terminology for Generalized
            Multi-Protocol Label Switching (GMPLS)", RFC 4427, March
            2006.
 [RFC4553]  Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-
            Agnostic Time Division Multiplexing (TDM) over Packet
            (SAToP)", RFC 4553, June 2006.
 [RFC4618]  Martini, L., Rosen, E., Heron, G., and A. Malis,
            "Encapsulation Methods for Transport of PPP/High-Level
            Data Link Control (HDLC) over MPLS Networks", RFC 4618,
            September 2006.
 [RFC4619]  Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed.,
            "Encapsulation Methods for Transport of Frame Relay over
            Multiprotocol Label Switching (MPLS) Networks", RFC 4619,
            September 2006.
 [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
            Computation Element (PCE)-Based Architecture", RFC 4655,
            August 2006.
 [RFC4783]  Berger, L., Ed., "GMPLS - Communication of Alarm
            Information", RFC 4783, December 2006.
 [RFC4802]  Nadeau, T., Ed., and A. Farrel, Ed., "Generalized
            Multiprotocol Label Switching (GMPLS) Traffic Engineering
            Management Information Base", RFC 4802, February 2007.
 [RFC4803]  Nadeau, T., Ed., and A. Farrel, Ed., "Generalized
            Multiprotocol Label Switching (GMPLS) Label Switching
            Router (LSR) Management Information Base", RFC 4803,
            February 2007.
 [RFC4816]  Malis, A., Martini, L., Brayley, J., and T. Walsh,
            "Pseudowire Emulation Edge-to-Edge (PWE3) Asynchronous
            Transfer Mode (ATM) Transparent Cell Transport Service",
            RFC 4816, February 2007.
 [RFC4875]  Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
            Yasukawa, Ed., "Extensions to Resource Reservation
            Protocol - Traffic Engineering (RSVP-TE) for Point-to-
            Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May
            2007.

Andersson, et al. Informational [Page 54] RFC 6373 MPLS-TP Control Plane Framework September 2011

 [RFC5003]  Metz, C., Martini, L., Balus, F., and J. Sugimoto,
            "Attachment Individual Identifier (AII) Types for
            Aggregation", RFC 5003, September 2007.
 [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
            "LDP Specification", RFC 5036, October 2007.
 [RFC5085]  Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire
            Virtual Circuit Connectivity Verification (VCCV): A
            Control Channel for Pseudowires", RFC 5085, December 2007.
 [RFC5145]  Shiomoto, K., Ed., "Framework for MPLS-TE to GMPLS
            Migration", RFC 5145, March 2008.
 [RFC5440]  Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
            Element (PCE) Communication Protocol (PCEP)", RFC 5440,
            March 2009.
 [RFC5493]  Caviglia, D., Bramanti, D., Li, D., and D. McDysan,
            "Requirements for the Conversion between Permanent
            Connections and Switched Connections in a Generalized
            Multiprotocol Label Switching (GMPLS) Network", RFC 5493,
            April 2009.
 [RFC5659]  Bocci, M. and S. Bryant, "An Architecture for Multi-
            Segment Pseudowire Emulation Edge-to-Edge", RFC 5659,
            October 2009.
 [RFC5787]  Papadimitriou, D., "OSPFv2 Routing Protocols Extensions
            for Automatically Switched Optical Network (ASON)
            Routing", RFC 5787, March 2010.
 [RFC5852]  Caviglia, D., Ceccarelli, D., Bramanti, D., Li, D., and S.
            Bardalai, "RSVP-TE Signaling Extension for LSP Handover
            from the Management Plane to the Control Plane in a GMPLS-
            Enabled Transport Network", RFC 5852, April 2010.
 [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
            "Bidirectional Forwarding Detection (BFD) for MPLS Label
            Switched Paths (LSPs)", RFC 5884, June 2010.
 [RFC5885]  Nadeau, T., Ed., and C. Pignataro, Ed., "Bidirectional
            Forwarding Detection (BFD) for the Pseudowire Virtual
            Circuit Connectivity Verification (VCCV)", RFC 5885, June
            2010.
 [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
            Networks", RFC 5920, July 2010.

Andersson, et al. Informational [Page 55] RFC 6373 MPLS-TP Control Plane Framework September 2011

 [RFC5951]  Lam, K., Mansfield, S., and E. Gray, "Network Management
            Requirements for MPLS-based Transport Networks", RFC 5951,
            September 2010.
 [RFC6001]  Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard,
            D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol
            Extensions for Multi-Layer and Multi-Region Networks
            (MLN/MRN)", RFC 6001, October 2010.
 [RFC6073]  Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
            Aissaoui, "Segmented Pseudowire", RFC 6073, January 2011.
 [RFC6107]  Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for
            Dynamically Signaled Hierarchical Label Switched Paths",
            RFC 6107, February 2011.
 [RFC6215]  Bocci, M., Levrau, L., and D. Frost, "MPLS Transport
            Profile User-to-Network and Network-to-Network
            Interfaces", RFC 6215, April 2011.
 [TE-MIB]   Miyazawa, M., Otani, T., Kumaki, K., and T. Nadeau,
            "Traffic Engineering Database Management Information Base
            in support of MPLS-TE/GMPLS", Work in Progress, July 2011.
 [TP-MIB]   King, D., Ed., and M. Venkatesan, Ed., "Multiprotocol
            Label Switching Transport Profile (MPLS-TP) MIB-based
            Management Overview", Work in Progress, August 2011.
 [TP-P2MP-FWK]
            Frost, D., Ed., Bocci, M., Ed., and L. Berger, Ed., "A
            Framework for Point-to-Multipoint MPLS in Transport
            Networks", Work in Progress, July 2011.
 [TP-RING]  Weingarten, Y., Ed., "MPLS-TP Ring Protection", Work in
            Progress, June 2011

9. Contributing Authors

 Attila Takacs
 Ericsson
 1. Laborc u.
 Budapest 1037
 HUNGARY
 EMail: attila.takacs@ericsson.com
 Martin Vigoureux
 Alcatel-Lucent
 EMail: martin.vigoureux@alcatel-lucent.fr

Andersson, et al. Informational [Page 56] RFC 6373 MPLS-TP Control Plane Framework September 2011

 Elisa Bellagamba
 Ericsson
 Farogatan, 6
 164 40, Kista, Stockholm
 SWEDEN
 EMail: elisa.bellagamba@ericsson.com

Authors' Addresses

 Loa Andersson (editor)
 Ericsson
 Phone: +46 10 717 52 13
 EMail: loa.andersson@ericsson.com
 Lou Berger (editor)
 LabN Consulting, L.L.C.
 Phone: +1-301-468-9228
 EMail: lberger@labn.net
 Luyuan Fang (editor)
 Cisco Systems, Inc.
 111 Wood Avenue South
 Iselin, NJ 08830
 USA
 EMail: lufang@cisco.com
 Nabil Bitar (editor)
 Verizon
 60 Sylvan Road
 Waltham, MA 02451
 USA
 EMail: nabil.n.bitar@verizon.com
 Eric Gray (editor)
 Ericsson
 900 Chelmsford Street
 Lowell, MA 01851
 USA
 Phone: +1 978 275 7470
 EMail: Eric.Gray@Ericsson.com

Andersson, et al. Informational [Page 57]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6373.txt · Last modified: 2011/09/21 17:36 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki