[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-abfb-mpls-tp-control-plane-framework) 00 01 02 03 04 05 06 RFC 6373

Internet Draft                             Loa Andersson, Ed. (Acreo AB)
Category: Informational                           Lou Berger, Ed. (LabN)
Expiration Date: September 22, 2010             Luyuan Fang, Ed. (Cisco)
                                              Nabil Bitar, Ed. (Verizon)

                                                          March 22, 2010

                    MPLS-TP Control Plane Framework

              draft-ietf-ccamp-mpls-tp-cp-framework-00.txt

Abstract

   The MPLS Transport Profile (MPLS-TP) supports static provisioning
   of transport paths via a Network Management System (NMS), and
   dynamic provisioning of transport paths via a control plane. This
   document provides the framework for MPLS-TP dynamic provisioning,
   and covers control plane addressing, routing, path computation,
   signaling, traffic engineering,, and path recovery.  MPLS-TP uses
   GMPLS as the control plane for MPLS-TP LSPs and provides for
   compatibility with MPLS.  The control plane for Pseudowires (PWs)
   is also covered by this document.  Management plane functions such
   as manual configuration and the initiation of LSP setup are out of
   scope of this document.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on September 22, 2010







Andersson, et al              Informational                     [Page 1]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


Copyright and License Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   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    Conventions Used In This Document  ......................   3
    1.2    Scope  ..................................................   3
    1.3    Basic Approach  .........................................   4
    1.4    Reference Model  ........................................   5
    2      Control Plane Requirements  .............................   8
    2.1    Primary Requirements  ...................................   8
    2.2    MPLS-TP Framework Derived Requirements  .................  17
    2.3    OAM Framework Derived Requirements  .....................  18
    2.4    Security Requirements  ..................................  21
    3      Relationship of PWs and TE LSPs  ........................  21
    4      TE LSPs  ................................................  22
    4.1    GMPLS Functions and MPLS-TP LSPs  .......................  22
    4.1.1  In-Band and Out-Of-Band Control and Management  .........  22
    4.1.2  Addressing  .............................................  23
    4.1.3  Routing  ................................................  23
    4.1.4  TE LSPs and Constraint-Based Path Computation  ..........  24
    4.1.5  Signaling  ..............................................  24
    4.1.6  Unnumbered Links  .......................................  25
    4.1.7  Link Bundling  ..........................................  25
    4.1.8  Hierarchical LSPs  ......................................  25
    4.1.9  LSP Recovery  ...........................................  26
    4.1.10 Control Plane Reference Points (E-NNI, I-NNI, UNI)  .....  26
    4.2    OAM, MEP (Hierarchy) Configuration and Control  .........  26
    4.2.1  Management Plane Support  ...............................  27
    4.3    GMPLS and MPLS-TP Requirements Table  ...................  28
    4.4    Anticipated MPLS-TP Related Extensions and Definitions  .  31
    4.4.1  MPLS to MPLS-TP Interworking  ...........................  31
    4.4.2  Associated Bidirectional LSPs  ..........................  31
    4.4.3  Asymmetric Bandwidth LSPs  ..............................  31
    4.4.4  Recovery for P2MP LSPs  .................................  32
    4.4.5  Test Traffic Control and other OAM functions  ...........  32
    4.4.6  Diffserv Object usage in GMPLS  .........................  32
    5      Pseudowires  ............................................  32



Andersson, et al              Informational                     [Page 2]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


    5.1    General reuse of existing PW control plane mechanisms  ..  35
    5.2    Signaling  ..............................................  35
    5.3    Recovery (Redundancy)  ..................................  35
    6      Network Managment Considerations  .......................  35
    7      Security Considerations  ................................  35
    8      IANA Considerations  ....................................  36
    9      Acknowledgments  ........................................  36
   10      References  .............................................  36
   10.1    Normative References  ...................................  36
   10.2    Informative References  .................................  38
   11      Authors' Addresses  .....................................  43



1. Introduction

   The MPLS Transport Profile (MPLS-TP) is being defined in a joint
   effort between the International Telecommunications Union (ITU) and
   the IETF.  The requirements for MPLS-TP are defined in the
   requirements document, see [RFC5654].  These requirements state that
   "A solution MUST be provided to support dynamic provisioning of MPLS-
   TP transport paths via a control plane."  This document provides the
   framework for such dynamic provisioning.

   This document is a product of a joint Internet Engineering Task Force
   (IETF) / International Telecommunications Union Telecommunications
   Standardization Sector (ITU-T) effort to include an MPLS Transport
   Profile within the IETF MPLS and PWE3 architectures to support the
   capabilities and functionalities of a packet transport network as
   defined by the ITU-T.


1.1. Conventions Used In This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


1.2. 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, Sections
   2.4 and portions of the remainder of Section 2 of [RFC5654] provide



Andersson, et al              Informational                     [Page 3]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


   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 a Packet switched network (PSN). The PW encapsulation over MPLS-TP
   LSPs used in MPLS-TP networks is the same as for PWs over MPLS in an
   MPLS network. MPLS-TP also defines protection and restoration (or,
   collectively, recovery) functions. The MPLS-TP control plane provides
   methods to establish, remove and control MPLS-TP LSPs and PWs.  This
   includes control of data plane, OAM and recovery functions.

   A general framework for MPLS-TP has been defined in [TP-FWK], and a
   survivability framework for MPLS-TP has been defined in [TP-SURVIVE].
   These document scope the approaches and protocols that will be used
   as the foundation for MPLS-TP.  Notably, Section 3.5 of [TP-FWK]
   scopes the IETF protocols that serve as the foundation of the MPLS-TP
   control plane.  The PW control plane is based on the existing PW
   control plane, see [RFC4447], and the PW end-to-end (PWE3)
   architecture, see [RFC3985].  The LSP control plane is based on
   Generalized MPLS (GMPLS), see [RFC3945], which is built on MPLS
   Traffic Engineering (TE) and its numerous extensions. [TP-SURVIVE]
   focuses on LSPs, and the protection 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 MPLS-TP
   requirements on the signaling that is used to provision PWs as
   specified in [RFC4447]. This document also discusses the impact of
   the MPLS-TP requirements on the GMPLS signaling and routing protocols
   that is used to provision MPLS-TP LSPs.


1.3. Basic Approach

   The basic approach taken in defining the MPLS-TP Control Plane
   framework is:

      1) MPLS technology as defined by the IETF is the foundation for
         the MPLS Transport Profile.
      2) The data plane for MPLS and MPLS-TP is identical, i.e. any
         extensions defined for MPLS-TP is also applicable to MPLS.
         Additionally, the same encapsulation used for MPLS over any
         layer 2 network is also used for MPLS-TP.
      3) MPLS PWs are used as-is by MPLS-TP including the use of
         targeted-LDP as the foundation for PW signaling [RFC4447],
         OSPF-TE, ISIS-TE or MP-BGP as they apply for Multi-
         Segment(MS)-PW routing. However, the PW can be encapsulated
         over an MPLS-TP LSP (established using methods and procedures
         for MPLS-TP LSP establishment) in addition to the presently



Andersson, et al              Informational                     [Page 4]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


         defined methods of carrying PWs over LSP based packet switched
         networks (PSNs). That is, the MPLS-TP domain is a packet
         switched network from a PWE3 architecture aspect [RFC3985].
      4) The MPLS-TP LSP control plane builds on the GMPLS control plane
         as defined by the IETF for transport LSPs, the protocols within
         scope are RSVP-TE [RFC3473], OSPF-TE [RFC4203][RFC5392], and
         ISIS-TE [RFC5307][RFC5316].  ASON/ASTN signaling and routing
         requirements in the context of GMPLS can be found in [RFC4139]
         and [RFC4258].
      5) Existing IETF MPLS and GMPLS RFCs and evolving Working Group
         Internet-Drafts should be reused wherever possible.
      6) If needed, extensions for the MPLS-TP control plane should
         first be based on the existing and evolving IETF work, secondly
         based on work by other Standard bodies only when IETF decides
         that the work is out of the IETF's scope. New extensions may be
         defined otherwise.
      7) Extensions to the GMPLS control plane may be required in order
         to fully automate MPLS-TP functions.
      8) Control-plane software upgrades to existing MPLS enabled
         equipment is acceptable and expected.
      9) It is permissible for functions present in the GMPLS control
         plane to not be used in MPLS-TP networks, e.g. the possibility
         to merge LSPs.
     10) One possible use of the control plane is to configure, enable
         and empower OAM functionality.  This will require extensions to
         existing control plane specifications which will be usable in
         MPLS-TP as well as MPLS networks.
     11) MPLS-TP requirements are primarily defined in Section 2.4 and
         relevant portions of the remainder Section 2 of [RFC5654].


1.4. Reference Model

   The control plane reference model is based on the general MPLS-TP
   reference model as defined in the MPLS-TP framework [TP-FWK]. Per the
   MPLS-TP framework [TP-FWK], the MPLS-TP control plane is based on
   GMPLS with RSVP-TE for LSP signaling and LDP for PW signaling.  In
   both cases, OSPF-TE or ISIS-TE with GMPLS extensions is used for
   dynamic routing.

   From a service perspective, client interfaces are provided for both
   the PWs and LSPs.  PW client interfaces are defined on an interface
   technology basis, e.g., Ethernet over PW [RFC4448]. In the context of
   MPLS-TP LSP, the client interface is expected to be provided via a
   GMPLS based UNI, see [RFC4208], or statically provisioned.  As
   discussed in [TP-FWK], MPLS-TP also presumes an LSP NNI reference
   point.

   The MPLS-TP end-to-end control plane reference model is shown in
   Figure 1.  It shows the control plane protocols used by MPLS-TP, as
   well as the UNI and NNI reference points.



Andersson, et al              Informational                     [Page 5]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


      |< ---- client signal (IP / MPLS / L2 / PW) ------------ >|
        |< --------- 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

   TE-RTG    |< ---------------- >|< --- >|< ---------- >|
   RSVP-TE

      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
          PE:            Provider Edge
          SP:            Service Provider
          TE-RTG:        OSPF-TE or ISIS-TE
          UNI:           User to Network Interface

   Figure 2 adds three hierarchical LSP segments, labeled as "H-LSPs".
   These segments are present to support scaling, OAM and MEPs within
   each provider and across the inter-provider NNI.  The MEPs are used
   to collect performance information, support diagnostic functions, and
   support OAM triggered survivability schemes as discussed in [TP-
   SURVIVE], and each H-LSP may be protected using any of the schemes
   discussed in [TP-SURVIVE]. End-to-end monitoring is supported via
   MEPs at the End-to-End LSP end-points.  Note that segement MEPs end-
   points are collocated with MIPs of the next higher-layer (e.g., end-
   to-end) LSPs.
















Andersson, et al              Informational                     [Page 6]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


       |< ------- client signal (IP / MPLS / L2 / PW) ------ >|
         |< -------- 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|----------------|MIP|---|MIP|---------|MEP|
   OAM     '''''                '''''   '''''         '''''
           ..... ..... ..... ......... ......... ..... .....
   Segment |MEP|-|MIP|-|MIP|-|MEP|MEP|-|MEP|MEP|-|MIP|-|MEP|
   OAM     ''''' ''''' ''''' ''''''''' ''''''''' ''''' '''''

   Seg.TE-RTG|< -- >|< -- >|< -- >||< -- >||< -- >|< -- >|
   RSVP-TE   (within the MPLS-TP domain)

   E2E TE-RTG|< ---------------- >|< ---- >|< --------- >|
   RSVP-TE

      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 end point
          MIP:           Maintenance intermediate point
          NNI:           Network to Network Interface
          PE:            Provider Edge
          SP:            Service Provider
          TE-RTG:        OSPF-TE or ISIS-TE

   While not shown in the Figures above, it is worth noting that the
   MPLS-TP control plane must support the addressing separation and
   independence between the data, control and management planes as shown
   in Figure 3 of [TP-FWK].  Address separation between the planes is
   already included in GMPLS.







Andersson, et al              Informational                     [Page 7]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


2. Control Plane Requirements

   The requirements for the MPLS-TP control plane are derived from the
   MPLS-TP requirements and framework documents, specifically [RFC5654],
   [TP-FWK], [TP-OAM-REQ], [TP-OAM], and [TP-SURVIVE].  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 [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] [RFC5654, Section
         1, Paragraph 15].

      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
         that interworking 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].

      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. All nodes (i.e., ingress, egress and intermediate) must 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].



Andersson, et al              Informational                     [Page 8]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


     10. Edge nodes (i.e., ingress and egress) must be aware about the
         pairing relationship of the forward and the backward directions
         belonging to the same associated bidirectional transport path
         [RFC5654, requirement 11].

     11. Transit nodes should be aware about 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 and management planes from the data plane
         [RFC5654, requirement 15]. Note that this implies that the
         addresses used in the management, control and data planes are
         independent.

     15. The MPLS-TP control plane must support the physical separation
         of the control and management planes from the data plane, and
         no assumptions should be made about the state of the data-plane
         channels from information about the control or management-plane
         channels when they are running out-of-band [RFC5654,
         requirement 16].

     16. A control plane must be defined to support dynamic provisioning
         and restoration of MPLS-TP transport paths, but its use is a
         network operator's choice [RFC5654, requirement 18].

     17. A control plane must not be required to support the static
         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].





Andersson, et al              Informational                     [Page 9]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


     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].

     22. The MPLS-TP control plane should work across multiple non-
         homogeneous domains [RFC5654, requirement 26].

     23. The MPLS-TP control plane must not dictate any particular
         physical or logical topology [RFC5654, requirement 27].

     24. The MPLS-TP control plane must include support of ring
         topologies which may be deployed with arbitrarily
         interconnection, support rings of at least 16 nodes [RFC5654,
         requirement 27.A. and 27.B.].

     25. The MPLS-TP control plane must support scale gracefully to
         support a large number of transport paths, nodes and links.
         That is it must be able to scale at least as well as control
         planes in existing transport technologies with growing and
         increasingly complex network topologies as well as with
         increasing bandwidth demands, number of customers, and number
         of services [RFC 5654, requirements 53 and 28].

     26. The MPLS-TP control plane should not provision transport paths
         which contain forwarding loops [RFC5654, requirement 29].

     27. The MPLS-TP control plane must support multiple client layers.
         (e.g.  MPLS-TP, IP, MPLS, Ethernet, ATM, FR, 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, SONET/SDH, 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].




Andersson, et al              Informational                    [Page 10]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


     31. The MPLS-TP control plane must allow the operation the layers
         of a multi-layer network that includes an MPLS-TP layer
         autonomously [RFC5654, requirement 34].

     32. The MPLS-TP control plane must allow the hiding of MPLS-TP
         layer network addressing and other information (e.g. topology)
         from client layer networks.  However, it should be possible, at
         the option of the operator, to leak a limited amount of
         summarized information (such as SRLGs or reachability) between
         layers [RFC5654, requirement 35].

     33. The MPLS-TP control plane must allow for the identification of
         a transport path on each link within and at the destination
         (egress) of the transport network. [RFC5654, requirement 38 and
         39].

     34. The MPLS-TP control plane must allow for P2MP capable server
         (sub-)layers.

     35. The MPLS-TP control plane must be extensible in order to
         accommodate new types of client layer networks and services
         [RFC5654, requirement 41].

     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 to be decreased without impacting the
         existing traffic on that transport path, provided that the
         level of existing traffic is smaller than the reserved
         bandwidth following the decrease [RFC5654, requirement 43].

     38. The MPLS-TP control plane must support an unambiguous and
         reliable means of distinguishing users' (client) packets from
         MPLS-TP control packets (e.g. control plane, management plane,
         OAM and protection switching packets) [RFC5654, requirement
         46].

     39. The control plane for MPLS-TP must fit within the ASON
         architecture.  The ITU-T has defined an architecture for
         Automatically Switched Optical Networks (ASON) in G.8080
         [ITU.G8080.2006] and G.8080 Amendment 1 [ITU.G8080.2008]. An
         interpretation of the ASON signaling and routing requirements
         in the context of GMPLS can be found in [RFC4139] and [RFC4258]
         [RFC5654, Section 2.4., Paragraph 2 and 3].







Andersson, et al              Informational                    [Page 11]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


     40. The MPLS-TP control plane must support control plane topology
         and data plane topology independence [RFC5654, requirement 47].

     41. A failure of the MPLS-TP control plane must not interfere with
         the deliver of service or recovery of established transport
         paths [RFC5654, requirement 47].

     42. The MPLS-TP control plane must be able to operate independent
         of any particular client or server layer control plane
         [RFC5654, requirement 48].

     43. The MPLS-TP control plane should support, but not require, an
         integrated control plane encompassing MPLS-TP together with its
         server and client layer networks when these layer networks
         belong to the same administrative domain [RFC5654, requirement
         49].

     44. The MPLS-TP control plane must support configuration of
         protection functions and any associated maintenance (OAM)
         functions [RFC5654, requirement 50 and 7].

     45. The MPLS-TP control plane must support the configuration and
         modification of OAM maintenance points as well as the
         activation/deactivation of OAM when the transport path or
         transport service is established or modified [RFC5654,
         requirement 51].

     46. The MPLS-TP control plane must be capable of restarting and
         relearning its previous state without impacting forwarding
         [RFC5654, requirement 54].

     47. The MPLS-TP control plane must provide a mechanism for dynamic
         ownership transfer of the control of MPLS-TP transport paths
         from the management plane to the control plane and vice versa.
         The number of reconfigurations required in the data plane must
         be minimized (preferably no data plane reconfiguration will be
         required) [RFC5654, requirement 55].

     48. The MPLS-TP control plane must support protection and
         restoration mechanisms, i.e., recovery [RFC5654, requirement
         52].

         Note that the MPLS-TP Survivability Framework document, [TP-
         SURVIVE], provides additional useful information related to
         recovery.

     49. The MPLS-TP control plane mechanisms should be identical (or as
         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].



Andersson, et al              Informational                    [Page 12]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


     50. The MPLS-TP control plane mechanisms used for P2P and P2MP
         recovery should be identical to simplify implementation and
         operation.  However, this must not override any other
         requirement [RFC5654, requirement 56 B].

     51. The MPLS-TP control plane must support recovery mechanisms that
         are applicable at various levels throughout the network
         including support for link, transport path, segment,
         concatenated segment and end-to-end recovery [RFC5654,
         requirement 57].

     52. The MPLS-TP control plane must support recovery paths that meet
         the SLA protection objectives of the service [RFC5654,
         requirement 58].  Including:

            a. Guarantee 50ms recovery times from the moment of fault
               detection in networks with spans less than 1200 km.

            b. Protection of up to 100% of the traffic on the protected
               path.

            c. Recovery must meet SLA requirements over multiple
               domains.

     53. The MPLS-TP control plane should support per transport path
         Recovery objectives [RFC5654, requirement 59].

     54. The MPLS-TP control plane must support recovery mechanisms that
         are applicable to any topology [RFC5654, requirement 60].

     55. The MPLS-TP control plane must operate in synergy with
         (including coordination of timing/timer settings) the recovery
         mechanisms present in any client or server transport networks
         (for example, Ethernet, SDH, OTN, WDM) to avoid race conditions
         between the layers [RFC5654, requirement 61].

     56. The MPLS-TP control plane must support recovery and reversion
         mechanisms that prevent frequent operation of recovery in the
         event of an intermittent defect [RFC5654, requirement 62].

     57. The MPLS-TP control plane must support revertive and non-
         revertive protection behavior [RFC5654, requirement 64].

     58. The MPLS-TP control plane must support 1+1 bidirectional
         protection for P2P transport paths [RFC5654, requirement 65 A].

     59. The MPLS-TP control plane must support 1+1 unidirectional
         protection for P2P transport paths [RFC5654, requirement 65 B].






Andersson, et al              Informational                    [Page 13]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


     60. The MPLS-TP control plane must support 1+1 unidirectional
         protection for P2MP transport paths [RFC5654, requirement 65
         C].

     61. The MPLS-TP control plane must support the ability to share
         protection resources amongst a number of transport paths
         [RFC5654, requirement 66].

     62. The MPLS-TP control plane must support 1:n bidirectional
         protection for P2P transport paths, and this should be the
         default for 1:n protection [RFC5654, requirement 67 A].

     63. The MPLS-TP control plane must support 1:n unidirectional
         protection for P2MP transport paths [RFC5654, requirement 67
         B].

     64. The MPLS-TP control plane may support 1:n unidirectional
         protection for P2P transport paths [RFC5654, requirement 65 C].

     65. The MPLS-TP control plane may support extra-traffic [RFC5654,
         note after requirement 67].

     66. The MPLS-TP control plane should support 1:n (including 1:1)
         shared mesh recovery [RFC5654, requirement 68].

     67. The MPLS-TP control plane must support sharing of protection
         resources such that protection paths that are known not to be
         required concurrently can share the same resources [RFC5654,
         requirement 69].

     68. The MPLS-TP control plane must support the sharing of resources
         between a restoration transport path and the transport path
         being replaced [RFC5654, requirement 70].

     69. The MPLS-TP control plane must support restoration priority so
         that an implementation can determine the order in which
         transport paths should be restored [RFC5654, requirement 71].

     70. The MPLS-TP control plane must support preemption priority in
         order to allow restoration to displace other transport paths in
         the event of resource constraints [RFC5654, requirement 72 and
         86].

     71. The MPLS-TP control plane may support revertive and non-
         revertive restoration behavior [RFC5654, requirement 73].

     72. The MPLS-TP control plane must support recovery being triggered
         by physical (lower) layer fault indications [RFC5654,
         requirement 74].





Andersson, et al              Informational                    [Page 14]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


     73. The MPLS-TP control plane must support recovery being triggered
         by OAM [RFC5654, requirement 75].

     74. The MPLS-TP control plane must support management plane
         recovery triggers (e.g., forced switch, etc.) [RFC5654,
         requirement 76].

     75. The MPLS-TP control plane must support the differentiation of
         administrative recovery actions from recovery actions initiated
         by other triggers [RFC5654, requirement 77].

     76. The MPLS-TP control plane should support control plane
         restoration triggers (e.g., forced switch, etc.) [RFC5654,
         requirement 78].

     77. The MPLS-TP control plane must support priority logic to
         negotiate and accommodate coexisting requests (i.e., multiple
         requests) for protection switching (e.g., administrative
         requests and requests due to link/node failures) [RFC5654,
         requirement 79].

     78. The MPLS-TP control plane must support the relationships of
         protection paths and protection-to-working paths (sometimes
         known as protection groups) [RFC5654, requirement 80].

     79. The MPLS-TP control plane must support pre-calculation of
         recovery paths [RFC5654, requirement 81].

     80. The MPLS-TP control plane must support pre-provisioning of
         recovery paths [RFC5654, requirement 82].

     81. 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 dropped [RFC5654, requirement 83].

     82. The MPLS-TP control plane must permit the testing and
         validation of the integrity of the protection/recovery
         transport path [RFC5654, requirement 84 A].

     83. The MPLS-TP control plane must permit the testing and
         validation of protection/ restoration mechanisms without
         triggering the actual protection/restoration [RFC5654,
         requirement 84 B].

     84. The MPLS-TP control plane must permit the testing and
         validation of protection/ restoration mechanisms while the
         working path is in service [RFC5654, requirement 84 C].




Andersson, et al              Informational                    [Page 15]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


     85. The MPLS-TP control plane must permit the testing and
         validation of protection/ restoration mechanisms while the
         working path is out of service [RFC5654, requirement 84 D].

     86. The MPLS-TP control plane must support the establishment and
         maintenance of all recovery entities and functions [RFC5654,
         requirement 89 A].

     87. The MPLS-TP control plane must support signaling of recovery
         administrative control [RFC5654, requirement 89 B].

     88. The MPLS-TP control plane must support protection state
         coordination (PSC). Since control plane network topology is
         independent from the data plane network topology, the PSC
         supported by the MPLS-TP control plane may run on resources
         different than the data plane resources handled within the
         recovery mechanism (e.g. backup).

     89. When present, the MPLS-TP control plane must support recovery
         mechanisms that are optimized for specific network topologies.
         These mechanisms must be interoperable with the mechanisms
         defined for arbitrary topology (mesh) networks to enable
         protection of end-to-end transport paths [RFC5654, requirement
         91].

     90. When present, the MPLS-TP control plane must support the
         control of ring topology specific recovery mechanisms [RFC5654,
         Section 2.5.6.1].

     91. The MPLS-TP control plane must include support for
         differentiated services and different traffic types with
         traffic class separation associated with different traffic
         [RFC5654, requirement 110].

     92. The MPLS-TP control plane must support the provisioning of
         services that provide guaranteed Service Level Specifications
         (SLS), with support for hard and relative end-to-end bandwidth
         guarantees [RFC5654, requirement 111].  [Editor's note: add
         reference to definition of hard and relative guarantees]

     93. The MPLS-TP control plane must support the provisioning of
         services which are sensitive to jitter and delay [RFC5654,
         requirement 112].











Andersson, et al              Informational                    [Page 16]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


2.2. MPLS-TP Framework Derived Requirements

   The following additional requirements are based on [TP-FWK]:
   [Editor's note: Need to update section (on document) to match split
   of P2P and P2MP now in [TP-FWK] and [TP-P2MP-FWK].)

     94. Per-packet equal cost multi-path (ECMP) load balancing is not
         applicable to MPLS-TP [TP-FWK, section 3.3.2, paragraph 9].

     95. Penultimate hop popping (PHP) is disabled on MPLS-TP LSPs by
         default. The applicability of PHP to both MPLS-TP LSPs and MPLS
         networks general providing packet transport services will be
         clarified in a future version. [TP-FWK, section 3.3.2,
         paragraph 10]

     96. The MPLS-TP control plane must support both E-LSP and L-LSP
         MPLS DiffServ modes as specified in [RFC3270] [TP-FWK, section
         3.3.2, paragraph 11].

     97. Both single-segment and multi-segment PWs shall be supported by
         the MPLS-TP control plane.  MPLS-TP shall use the definition of
         multi-segment PWs as defined by the IETF [TP-FWK, section
         3.4.2.].

     98. The MPLS-TP control plane must support the control of PWs and
         their associated labels [TP-FWK, section 3.4.2.].

     99. 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 [TP-FWK, section 3.4.3.].

            a. The MPLS-TP control plane must support the use of network
               layer protocol-specific LSPs and labels. [TP-FWK, section
               3.4.3.]

            b. The MPLS-TP control plane must support the use of a
               client service-specific LSPs and labels. [TP-FWK, section
               3.4.3.]

    100. The MPLS-TP control plane is based on the GMPLS control plane
         for MPLS-TP LSPs. More specifically, GMPLS RSVP-TE [RFC3473]
         and related extensions are used for LSP signaling, and GMPLS
         OSPF-TE [RFC5392] and ISIS-TE [RFC5316] are used for routing
         [TP-FWK, section 3.8.].

    101. The MPLS-TP control plane is based on the MPLS control plane
         for PWs, and more specifically, Targeted LDP (T-LDP) [RFC4447]
         is used for PW signaling [TP-FWK, section 3.8, paragraph 6].






Andersson, et al              Informational                    [Page 17]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


    102. The MPLS-TP LSP control plane must allow for interoperation
         with the MPLS-TE LSP control plane [TP-FWK, section 3.8.2.,
         paragraph 5].

    103. The MPLS-TP control plane must ensure its own survivability and
         to enable it to recover gracefully from failures and
         degradations.  These include graceful restart and hot redundant
         configurations [TP-FWK-06, section 3.8., paragraph 12].

    104. The MPLS-TP control plane must support linear, ring and meshed
         protection schemes [TP-FWK-06, section 3.10., paragraph 8].


2.3. OAM Framework Derived Requirements

   The following additional requirements are based on [TP-OAM-REQ] and
   [TP-OAM]:

    105. The MPLS-TP control plane must support the capability to
         enable/disable OAM functions as part of service establishment
         [TP-OAM-REQ, section 2.1.6., paragraph 1].

    106. 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 [TP-OAM-REQ, section
         2.1.6., paragraph 1 and 2].

    107. The MPLS-TP control plane must allow for the IP/MPLS and PW OAM
         protocols (e.g., LSP-Ping [RFC4379], MPLS-BFD [BFD-MPLS], VCCV
         [RFC5085] and VCCV-BFD [VCCV-BFD]) [TP-OAM-REQ, section 2.1.4.,
         paragraph 2].

    108. The MPLS-TP control plane must allow for the ability to support
         experimental OAM functions.  These functions must be disabled
         by default [TP-OAM-REQ, section 2.2., paragraph 2].

    109. 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 [TP-OAM-REQ, section 2.2., paragraph 3].

    110. The MPLS-TP control plane must provide a mechanism to support
         the localization of faults and the notification of appropriate
         nodes.  Such notification should trigger corrective (recovery)
         actions [TP-OAM-REQ, section 2.2.1., paragraph 1].

    111. The MPLS-TP control plane must allow 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 [TP-OAM-REQ, section 2.2.1., paragraph 2].




Andersson, et al              Informational                    [Page 18]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


    112. 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 [TP-OAM-
         REQ, section 2.2.1., paragraph 3].

    113. The MPLS-TP control plane must provide functionality to control
         an End Point to monitor the liveness, i.e., continuity check
         (CC), of a PW, LSP or Section [TP-OAM-REQ, section 2.2.2.,
         paragraph 1].

    114. 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), i.e., connectivity
         verification (CV), by means of the expected PW, LSP or Section
         [TP-OAM-REQ, section 2.2.3., paragraph 1].

    115. The MPLS-TP control plane must provide functionality to control
         diagnostic testing on a PW, LSP or Section [TP-OAM-REQ, section
         2.2.5., paragraph 1].

    116. The MPLS-TP control plane must provide functionality to enable
         an End Point to discover the Intermediate (if any) and End
         Point(s) along a PW, LSP or Section, and more generally to
         trace (record) the route of a PW, LSP or Section [TP-OAM-REQ,
         section 2.2.4., paragraph 1].

    117. 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. Note that lock
         corresponds to an administrative status in which it is expected
         that only test traffic, if any, and OAM (dedicated to the PW,
         LSP or Section) can be mapped on that PW, LSP or Section [TP-
         OAM-REQ, section 2.2.6., paragraph 1].  (This requirement
         duplicates a requirement stated above but is listed again to
         maintain alignment with [TP-OAM].)

    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 lock condition indirectly affecting
         that PW or LSP [TP-OAM-REQ, section 2.2.7., paragraph 1].

    119. 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 [TP-OAM-REQ, section 2.2.8., paragraph 1].

    120. 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 [TP-OAM-REQ, section 2.2.9.,



Andersson, et al              Informational                    [Page 19]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


         paragraph 1].

    121.  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 [TP-OAM-
         REQ, section 2.2.10., paragraph 1].

    122. The MPLS-TP control plane must provide functionality to enable
         the control of quantification of packet loss ratio over a PW,
         LSP or Section [TP-OAM-REQ, section 2.2.11., paragraph 1].

    123. 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 [TP-
         OAM-REQ, section 2.2.12., paragraph 1].

    124. The MPLS-TP control plane must support the configuration of
         MEPs.  [Editor's note: this set of requirements needs to be
         aligned with the current terminology in [TP-OAM].]

            a. The CC and CV functions operate between MEPs [TP-OAM,
               section 5.1., paragraph 3].

            b. All OAM packets coming to a MEP source are tunneled via
               label stacking, and therefore a MEP can only exist at the
               beginning and end of a sub-layer (i.e. at an LSP's
               ingress and egress nodes and never at an LSP's transit
               node) [TP-OAM, section 3.2., paragraph 10].

            c. The CC and CV functions may serve as a trigger for
               protection switching, see requirement 45 above.

            d. This implies that LSP hierarchy must be used in cases
               where OAM is used to trigger recovery [TP-OAM, section
               4., paragraph 5].

    125. The MPLS-TP control plane must support the signaling of the MEP
         identifier used in CC and CV [TP-OAM, section 5.1., paragraph
         4].

    126. The MPLS-TP control plane must support the signaling of the
         transmission period used in CC and CV [TP-OAM, section 5.1.,
         paragraph 6].

    127. [NOTE: Need to review NM frawework for derived requirments]







Andersson, et al              Informational                    [Page 20]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


2.4. Security Requirements

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


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 [TP-FWK].
   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 tunnel
   signaling.  [RFC3985] does allow for the extension of the (LSP)
   tunnel control plane to exchange information necessary to support
   PWs. [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.  As this
   coordination occurs within a single node, this coordination is a
   local matter and is out of scope of this document. 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
   the 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 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
   example, to support the recovery functions described in [TP-SURVIVE]
   this document focuses on the control of the recovery functions at the
   LSP layer.  PW based recovery is under development at this time and



Andersson, et al              Informational                    [Page 21]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


   may be used once defined.


4. TE LSPs

   MPLS-TP LSPs are controlled via Generalized MPLS (GMPLS) signaling
   and routing, see [RFC3945].  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 MPLS-TP LSP relevant features of GMPLS, then identify how
   specific requirements can be met using existing GMPLS functions and
   will conclude with extensions that are anticipated to support MPLS-
   TP.


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 and Management

   GMPLS supports both in-band and out-of-band control.  The terms in-
   band and out-of-band typically refer to the relationship of the
   management and control planes relative to the data plane.  The terms
   may be used to refer to the management plane independent of the
   control plane, or to both of them in concert.  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 are as follows:

     o In-band
       This term is used to refer to cases where management and/or
       control plane traffic is sent using or embedded in the same
       communication channel used to transport the associated data.  IP,
       MPLS, and Ethernet networks are all examples where control
       traffic is typically sent in-band with the data traffic.

     o Out-of-band, in-fiber
       This term is used to refer to cases where management and/or
       control plane traffic is sent using a different communication
       channel from the associated data traffic, and the
       control/management communication channel resides in the same
       fiber as the data traffic. Optical transport networks typically
       operate in an out-of-band in-fiber configuration.






Andersson, et al              Informational                    [Page 22]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


     o Out-of-band, aligned topology
       This term is used to refer to the cases where management and/or
       control plane traffic is sent using a different communication
       channel from the associated data traffic, and the
       control/management communication must follow the same node-to-
       node path as the data 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.

     o Out-of-band, independent topology
       This term is used to refer to the cases where management and/or
       control plane traffic is sent using a different communication
       channel from the associated data traffic, and the
       control/management communication may follow a path that is
       completely independent of the data traffic.  Such configurations
       do not preclude the use of in-fiber or aligned topology links,
       but alignment is not required.

   In the context of MPLS-TP, 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.  GMPLS routing and signaling can be used to
   support in-band and all of the out-of-band forms of control, see
   [RFC3945].


4.1.2. Addressing

   MPLS-TP reuses and supports the addressing mechanisms supported by
   MPLS.  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 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.


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 (PSC) within a single network.



Andersson, et al              Informational                    [Page 23]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


   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 an
   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, 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), see
   [RFC3209] and [RFC3473].  In all cases, no specific algorithm is
   standardized by the IETF.  This is anticipated to continue to be the
   case for MPLS-TP LSPs.


4.1.4.1. Relation to PCE

   Path Computation Element (PCE) Based approaches, see [RFC4655], may
   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
   the architecture is used the PCE Communication Protocol (PCECP), see
   [RFC5440], will be used to communicate PCE requests and responses.
   MPLS-TP specific extensions to PCECP are currently out of scope of
   the MPLS-TP project and this document.


4.1.5. Signaling

   GMPLS signaling is defined in [RFC3471] and [RFC3473], and is based
   on RSVP-TE, [RFC3209].  CR-LDP based GMPLS, [RFC3472] is no longer
   under active development within the IETF, i.e., is deprecated, and
   must not be used for MPLS-TP.  In general, all RSVP-TE extensions
   that apply to MPLS may also be used for GMPLS and consequently MPLS-
   TP.  Most notably this includes support for P2MP signaling as defined
   in [RFC4875].

   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.



Andersson, et al              Informational                    [Page 24]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


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 in [RFC4203] for OSPF and [RFC5307] for IS-IS, 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.


4.1.8. Hierarchical LSPs

   This section reuses text from [HIERARCHY-BIS].

   [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 is formalized in [RFC4206] with a set of protocol
   mechanisms for the establishment of a hierarchical LSP that can carry
   one or more other LSPs.

   [RFC4206] goes on to explain that a hierarchical LSP may carry other
   LSPs only according to their switching types. This is a function of
   the way labels are carried. In a packet switch capable (PSC) network,
   the hierarchical LSP can carry other PSC 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 known as "non-adjacent signaling."

   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.

   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.





Andersson, et al              Informational                    [Page 25]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


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.  The former can be viewed as a special case of segment
   recovery where there is a single recovery domain whose borders
   coincide with the ingress and egress of the LSP, although specific
   procedures are defined.

   The five defined types of recovery defined in MPLS-TP are:
     - 1+1 bidirectional protection for P2P LSPs
     - 1+1 unidirectional protection for P2MP LSPs
     - 1:n (including 1:1) protection with or without extra traffic
     - Rerouting without extra traffic (sometimes known as soft
       rerouting), including shared mesh restoration
     - Full LSP rerouting

   Recovery for MPLS-TP LSPs is signaled using the mechanism defined in
   [RFC4872] and [RFC4873].  Note that when MEPs are required for the
   OAM CC function each MEP (other than the ones co-resident with the
   ingress and egress) are instantiated via a hierarchical LSP and
   protection is always end-to-end.  (Which can be signaled using either
   [RFC4872] and [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, it's use is not precluded.


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

   The majority of GMPLS control plane related RFCs 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 (UNI) interfaces and
   across interprovider, external network-to-network (E-NNI),
   interfaces.  Such support is embodied in [RFC4208] for UNIs and
   [GMPLS-ASON] 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) Configuration and Control

   MPLS-TP is being defined to support a comprehensive set of MPLS-TP
   OAM functions. Specific OAM requirements for MPLS-TP are documented
   in [TP-OAM-REQ]. In addition to the actual OAM requirements, it is
   also required that the control plane be able to configure and control
   OAM entities. This requirement is not yet addressed by the existing
   RFCs, but such work is now underway, e.g., [CCAMP-OAM-FWK] and
   [CCAMP-OAM-EXT].



Andersson, et al              Informational                    [Page 26]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


   Many OAM functions occur on a per-LSP, and even in-band, basis and
   are initiated immediately after LSP establishment.  Hence, it is
   desirable that OAM is setup together with the establishment of the
   data path (i.e., with the same signaling). This way OAM setup is
   bound to connection establishment signaling, avoiding two separate
   management/configuration steps (connection setup followed by OAM
   configuration) which would increases delay, processing and more
   importantly may be prune to mis-configuration errors.

   It must be noted that although the control plane is used to establish
   OAM maintenance entities, OAM messaging and functions occur
   independently from the control plane. That is, in MPLS-TP OAM
   mechanisms are responsible for monitoring and initiating recovery
   actions (driving switches between primary and backup paths).


4.2.1. Management Plane Support

   There is no MPLS-TP requirement for a standardized management
   interface to the MPLS-TP control plane.  That said, MPLS and GMPLS
   support a number of standardized management functions.  These include
   the MPLS-TE/GMPLS TE Database Management Information Base (MIB), [TE-
   MIB]; the MPLS TE MIB, [RFC3812]; the MPLS LSR MIB, [RFC3813]; the
   GMPLS TE MIB [RFC4802]; and the GMPLS LSR MIB, [RFC4803].  These MIBs
   may be used in MPLS-TP networks.


4.2.1.1. Recovery Triggers

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

   Note that control plane triggers are typically invoked in response to
   a management plane request at the ingress.


4.2.1.2. Management Plane / Control Plane Ownership Transfer

   In networks where both control plane and management plane are
   provided, LSP provisioning can be bone either by control plane or
   management plane.  As mentioned in the requirements section above, it



Andersson, et al              Informational                    [Page 27]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


   must be possible to transfer, or handover, management plane created
   LSP to the control plane domain and vice-versa. [RFC5493] defines the
   specific requirements for an LSP ownership handover procedure. It
   must be possible for the control plane to notify, in a reliable
   manner, the management plane about the status/result of either
   synchronous or asynchronous, with respect to the management plane,
   operation performed.  Moreover it must be possible to monitor, via
   query or spontaneous notify, the status of the control plane object
   such as the TE Link status, the available resources, etc. A mechanism
   must be made available by the control plane to the management plane
   to log control plane LSP related operation, that is, it must be
   possible from the NMS to have a clear view of the life, (traffic hit,
   action performed, signaling etc.) of a given LSP. The LSP handover
   procedure for MPLS-TP LSPs is supported via [PC-SCP].


4.3. GMPLS and MPLS-TP Requirements Table

   The following table shows how the MPLS-TP control plane requirements
   can be met using existing the GMPLS control plane (which builds on
   top of 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]                                      |
   |   20  | [RFC3473]                                                 |
   |   21  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307],    |
   |       |     [RFC5151]                                             |



Andersson, et al              Informational                    [Page 28]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


   |   22  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307],    |
   |       |     [RFC5151]                                             |
   |   23  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307]     |
   |   24  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307]     |
   |   25  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307],    |
   |       |     [HIERARCHY-BIS]                                       |
   |   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], [GMPLS-ASON], [GMPLS-MLN]           |
   |   33  | [RFC3473], [RFC4875]                                      |
   |   34  | [RFC4875]                                                 |
   |   35  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307]     |
   |   36  | [RFC3473], [RFC3209] (Make-before-break)                  |
   |   37  | [RFC3473], [RFC3209] (Make-before-break)                  |
   |   38  | [RFC3945], [RFC4202], [RFC5718]                           |
   |   39  | [RFC4139], [RFC4258], [GMPLS-ASON]                        |
   |   40  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307]     |
   |   41  | [RFC3473]                                                 |
   |   42  | [RFC3945], [RFC3471], [RFC4202], [RFC4208]                |
   |   43  | [RFC3945], [RFC3471], [RFC4202]                           |
   |   44  | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]    |
   |   45  | [HIERARCHY-BIS], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]         |
   |   46  | [RFC3473], [RFC4203], [RFC5307], [RFC5063]                |
   |   47  | [PC-SCP]                                                  |
   |   48  | [RFC4872], [RFC4873]                                      |
   |   49  | [RFC3945], [RFC3471], [RFC4202]                           |
   |   50  | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) |
   |   51  | [RFC4872], [RFC4873]                                      |
   |   52  | [RFC4872], [RFC4873] + proper vendor implementation       |
   |   53  | [RFC4872], [RFC4873], [GMPLS-PS]                          |
   |   54  | [RFC4872], [RFC4873]                                      |
   |   55  | [RFC3473], [RFC4872], [RFC4873], [GMPLS-PS]               |
   |       |     Timers are a local implementation matter              |
   |   56  | [RFC4872], [RFC4873, [GMPLS-PS] +                         |
   |       |     implementation of timers                              |
   |   57  | [RFC4872], [RFC4873], [GMPLS-PS]                          |
   |   58  | [RFC4872], [RFC4873]                                      |
   |   59  | [RFC4872], [RFC4873]                                      |
   |   60  | [RFC4872], [RFC4873]                                      |
   |   61  | [RFC4872], [RFC4873], [HIERARCHY-BIS]                     |
   |   62  | [RFC4872], [RFC4873]                                      |
   |   63  | [RFC4872], [RFC4873] + Recovery for P2MP (see Sec. 4.4.4) |
   |   64  | [RFC4872], [RFC4873]                                      |
   |   65  | [RFC4872], [RFC4873]                                      |
   |   66  | [RFC4872], [RFC4873]                                      |
   |   67  | [RFC4872], [RFC4873], [HIERARCHY-BIS]                     |
   |   68  | [RFC4872], [RFC4873]                                      |



Andersson, et al              Informational                    [Page 29]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


   |   69  | [RFC3473], [RFC4872], [RFC4873]                           |
   |   70  | [RFC3473]                                                 |
   |   71  | [RFC3473], [RFC4872], [GMPLS-PS]                          |
   |   72  | [RFC3473], [RFC4872]                                      |
   |   73  | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]    |
   |   74  | [RFC4426], [RFC4872], [RFC4873]                           |
   |   75  | [RFC4426], [RFC4872], [RFC4873]                           |
   |   76  | [RFC4426], [RFC4872], [RFC4873]                           |
   |   77  | [RFC4426], [RFC4872], [RFC4873]                           |
   |   78  | [RFC4426], [RFC4872], [RFC4873]                           |
   |   79  | [RFC4426], [RFC4872], [RFC4873] + vendor implementation   |
   |   80  | [RFC4426], [RFC4872], [RFC4873]                           |
   |   81  | [RFC4426], [RFC4872], [RFC4873]                           |
   |   83  | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5)   |
   |   84  | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5)   |
   |   85  | [RFC4872], [RFC4873] + Testing control (See Sec. 4.4.5)   |
   |   86  | [RFC4872], [RFC4873], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]    |
   |   87  | [RFC4872], [RFC4873]                                      |
   |   88  | [RFC4872], [RFC4873]                                      |
   |   89  | [RFC4872], [RFC4873], [TP-RING]                           |
   |   90  | [RFC4872], [RFC4873], [TP-RING]                           |
   |   91  | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) |
   |   92  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307]     |
   |   93  | [RFC3945], [RFC3473], [RFC2210], [RFC2211], [RFC2212]     |
   |   94  | Generic requirement on data plane (correct implmentation) |
   |   95  | [RFC3473], [NO-PHP]                                       |
   |   96  | [RFC3270], [RFC3473], [RFC4124] + GMPLS Usage (See 4.4.6) |
   |   97  | [RFC3473] (See Section 3)                                 |
   |   98  | [RFC3473] (See Section 3)                                 |
   |   99  | [RFC3945], [RFC3473], [HIERARCHY-BIS]                     |
   |  100  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307] +   |
   |       |      [RFC5392] and [RFC5316]                              |
   |  101  | PW only requirement                                       |
   |  102  | [RFC5145] + Formal Definition (See Section 4.4.1)         |
   |  103  | [RFC3473], [RFC4203], [RFC5307], [RFC5063]                |
   |  104  | [RFC4872], [RFC4873], [TP-RING]                           |
   |  105  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]                          |
   |  106  | [RFC3473], [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]               |
   |  107  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]                          |
   |  108  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5)       |
   |  109  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]                          |
   |  110  | [RFC3473], [RFC4872], [RFC4873]                           |
   |  111  | [RFC3473], [RFC4872], [RFC4873]                           |
   |  112  | [RFC3473], [RFC4783]                                      |
   |  113  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]                          |
   |  114  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5)       |
   |  115  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5)       |
   |  116  | [RFC3473]                                                 |
   |  117  | [RFC4426], [RFC4872], [RFC4873]                           |
   |  118  | [RFC3473], [RFC4872], [RFC4873]                           |
   |  119  | [RFC3473], [RFC4783]                                      |



Andersson, et al              Informational                    [Page 30]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


   |  120  | [RFC3473]                                                 |
   |  121  | [RFC3473], [RFC4783]                                      |
   |  122  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5)       |
   |  123  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT] + (See Sec. 4.4.5)       |
   |  124  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT], [HIERARCHY-BIS]         |
   |  125  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]                          |
   |  126  | [CCAMP-OAM-FWK], [CCAMP-OAM-EXT]                          |
   |  127  | TBD                                                       |
   +=======+===========================================================+


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 to MPLS-TP Interworking

   [RFC5145] identifies a set of solutions that are aimed to aid in the
   interworking of MPLS-TE and GMPLS control planes.  This work will
   serve as the foundation for a formal definition of MPLS to MPLS-TP
   control plane interworking.


4.4.2. Associated Bidirectional LSPs

   GMPLS signaling, [RFC3473], supports unidirectional, and co-routed
   bidirectional point-to-point LSPs.  MPLS-TP also requires support for
   associated bidirectional point-to-point LSPs.  Such support will
   require an extension or a formal definition of how the LSP endpoints
   supporting an associated bidirectional service will coordinate the
   two LSPs used to provide such a service.  Per requirement 11, transit
   nodes that support an associated bidirectional service should be
   aware of the association of the LSPs used to support the service.
   GMPLS calls, [RFC4974], may serve as the foundation for this support.


4.4.3. Asymmetric Bandwidth LSPs

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








Andersson, et al              Informational                    [Page 31]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


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 works in progress that extend
   the OAM related control capabilities of GMPLS.  These extensions
   cover a portion, but not all OAM related control functions that have
   been identified in the context of MPLS-TP.  As discussed above, the
   MPLS-TP control plane must support the selection of which (if any)
   OAM function(s) to use (including support to select experimental OAM
   functions) and what OAM functionality to run, including, continuity
   check (CC), connectivity verification (CV), packet loss and delay
   quantification, and diagnostic testing of a service. As OAM
   configuration is directly linked to data plane OAM, it is expected
   that [CCAMP-OAM-EXT] will evolve in parallel with the specification
   of data plane OAM functions.


4.4.6. Diffserv Object usage in GMPLS

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


5. Pseudowires

   [Editor's note: This section is preliminary and will be
   edited/replaced in future versions.]

   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)
   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 PDH, WDM, or SONET/SDH provide
   transport for PDH or SONET (e.g., ATM over SONET or Packet PPP over



Andersson, et al              Informational                    [Page 32]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


   SONET) client signals with no payload awareness.  Implementing PW
   capability allows for the use of an existing technology to substitute
   the 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 types of PWs: (1) Single-Segment pseudowires (SS-PW),
   and (2) Multi-segment pseudowires (MS-PW) [SEGMENTED-PW].  An MPLS-TP
   domain may transparently transport a PW whose endpoints 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
   for transport over an MPLS-TP domain, with a GMPLS LSP or a hierarchy
   of LSPs transporting the PW between the T-PEs. 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. The MPLS-TP domain may also
   contain Switching PEs (S-PEs) for a multi-segment PW whereby the T-
   PEs may be at the edge of the MPLS-TP domain or in a client network.
   In this latter case, a T-PE in a client network is a T-PE performing
   the adaptation of the native service to MPLS and the MPLS-TP domain
   performs Pseudo-wire switching.

   SS-PW signaling control plane is based on LDP with specific
   procedures defined in [RFC4447]. [RFC5659], [SEGMENTED-PW] and [MS-
   PW-DYNAMIC] allow for static switching of multi-segment pseudowires
   in data and control plane and for dynamic routing and placement of an
   MS-PW whereby signaling is still based on Targeted LDP (T-LDP).  The
   MPLS-TP domain 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 segment that is
   switched across the MPLS-TP domain.

   The same control protocol and procedures are reused as much as
   possible. However, when using PWs in MPLS-TP, a set of new
   requirements are defined which may require extensions of the existing
   control mechanisms. This section identifies areas where extensions
   are needed based on the PW Control Plane related requirements
   documented in [RFC5654].

   The baseline requirement for extensions to support transport
   applications is that any new mechanisms and capabilities must be able
   to interoperate with existing IETF MPLS [RFC3031] and IETF PWE3
   [RFC3985] control and data planes where appropriate. Hence,
   extensions of the PW Control Plane must be in-line with the
   procedures defined in [RFC4447]], [SEGMENTED-PW] and [MS-PW-DYNAMIC].

   For MPLS-TP, it is required that the data and control planes are both
   logically and physically separated. That is, the PW Control Plane
   must be able to operate out-of-band (OOB). This separation ensures



Andersson, et al              Informational                    [Page 33]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


   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.

   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 FEC and Generalized
   PWid FEC Elements can possibly be used in an OOB case as well
   (Detailed evaluation is FFS). The PW Label allocation and exchange
   mechanisms can be possibly reused unchanged (Detailed evaluation is
   FFS). Binding a PW to an LSP, or PW segments to LSPs can be left to
   networks elements acting as T-PEs and S-PEs or a control plane entity
   that may be the same one signaling the PW. If the control plane is
   physically separated from the forwarder, the control plane must be
   able to program the forwarders with necessary information.

   For transport applications, it is mandatory that bidirectional
   traffic is following congruent paths. Today, each direction of a PW
   or a PW segment is bound to a unidirectional LSP that extends between
   two T-PEs, S-PEs, or a T-PE and an S-PE. The unidirectional LSPs in
   both directions are not required to follow congruent paths, and
   therefore both directions of a PW may not follow congruent paths. The
   only requirement today is that a PW or a PW segment shares the same
   T-PEs in both directions, and same S-PEs in both directions. This
   poses a new requirement on the PW Control Plane, namely to ensure
   that both ends map the PW to the same transport path. 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 likely can be accomplished
   by adding a new TLV to PW signaling. This coincides with the gap
   identified for OOB support: a new mechanism may be needed to
   explicitly bind PWs to the supporting transport LSP.

   Alternatively, two unidirectional LSPs may be used to support the PW.
   However, to meet the congruency requirement, the LSPs must be placed
   so that they are forced to follow the same path (switches and links).
   This maybe accomplished by placing one unidirectional TE-LSP in one
   direction at one endpoint, and forcing the other endpoint to setup a
   TE-LSP with an ERO that has the nodes/links in the reverse order from
   the RRO seen in the path message of the LSP in the reverse direction.
   In this case, when one endpoint selects an LSP to bind the PW to, it
   must identify to the remote end which LSP to bind the other direction
   of the PW to.

   Transport applications require resource guarantees. In the case of
   transport LSPs, resource reservation mechanisms are provided via
   RSVP-TE and the use of DiffServ. If multiple PWs are multiplexed into



Andersson, et al              Informational                    [Page 34]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


   the same transport LSP resources, contention may occur. However,
   local policy at PEs may 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.

   The PW control plane must be able to establish and configure all of
   the available features manageable for the PW, including protection
   and OAM entities and mechanisms. There is ongoing work on PW
   protection and MPLS-TP OAM.

   To summarize, the main areas identified for potential PW Control
   Plane extensions to support MPLS-TP are the following.

     o Move PW Control Plane out-of-band

     o Explicit control of PW to LSP binding

     o PW QoS

     o PW protection

     o PW OAM configuration and control


5.1. General reuse of existing PW control plane mechanisms

5.2. Signaling

5.3. Recovery (Redundancy)

6. Network Managment Considerations

   [Editor's note: TBD]


7. Security Considerations

   This primarily document describes how exiting mechanisms can be used
   to meet the MPLS-TP control plane requirements.  The documents that
   describe each mechanism contain their own security considerations
   sections.  For a general discussion on MPLS and GMPLS related
   security issues, see the MPLS/GMPLS security framework [MPLS-SEC].

   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.







Andersson, et al              Informational                    [Page 35]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


8. IANA Considerations

   There are no new IANA considerations introduced by this document.


9. Acknowledgments

   The authors would like to acknowledge the contributions of Yannick
   Brehon, Diego Caviglia, Nic Neate, and Dave Mcdysan to this work.


10. References

10.1. Normative References

   [RFC2210] Wroclawski, J., "The Use of RSVP with Integrated
              Services", RFC 2210, September 1997.

   [RFC2211] Wroclawski, J., "Specification of the Controlled Load
              Quality of Service", RFC 2211, September 1997.

   [RFC2212] Shenker, S., Partridge, C., and R Guerin, "Specification
              of Guaranteed Quality of Service", RFC 2212, September
              1997.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels," RFC 2119.

   [RFC3031] Rosen, E., Viswanathan, A., Callon, R.,
             "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., "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",
             January 2003.

   [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
            Engineering (TE) Extensions to OSPF Version 2", RFC 3630,
            September 2003.






Andersson, et al              Informational                    [Page 36]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


   [RFC4124] Le Faucheur, F., Ed. "Protocol Extensions for Support of
             Diffserv-aware MPLS Traffic Engineering", RFC 4124, June
             2005.

   [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
             Support of Generalized Multi-Protocol Label
             Switching(GMPLS)", RFC 4202, October 2005.

   [RFC4203] Kompella, K. and Y. Rekhter, "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.

   [RFC4447] Martini, L., Ed., "Pseudowire Setup and Maintenance
             Using the Label Distribution Protocol (LDP)", RFC
             4447, April 2006.

   [RFC4448] Martini, L., Ed., "Encapsulation Methods for
             Transport Ethernet over MPLS Network", RFC 4448,
             April 2006.

   [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D.,
             "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., Farrel, A.,
             "GMPLS Segment Recovery", RFC 4873, May 2007.

   [RFC4929] Andersson, L. and A. Farrel, "Change Process for
             Multiprotocol Label Switching (MPLS) and Generalized
             MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC
             4929, June 2007.

   [RFC4974] Papadimitriou, D., Farrel, A., "Generalized MPLS (GMPLS)
             RSVP-TE Signaling Extensions in Support of Calls", RFC
             4974, August 2007.

   [RFC5063] Satyanarayana, A., Ed., "Extensions to GMPLS Resource
             Reservation Protocol (RSVP) Graceful Restart", RFC 5063,
             September 2007.

   [RFC5305] Smit, H. and T. Li, "IS-IS Extensions for Traffic
             Engineering", RFC 5305, October 2008.






Andersson, et al              Informational                    [Page 37]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


   [RFC5307] Kompella, K. and Rekhter, Y., "IS-IS Extensions in
             Support of Generalized Multi-Protocol Label Switching
             (GMPLS)", RFC 5307, October 2008.

   [RFC5316] Chen, M., Zhang, R., and Duan, X., "ISIS Extensions
             in Support of Inter-Autonomous System (AS) MPLS and
             GMPLS Traffic Engineering", RFC 5316, December 2008.

   [RFC5392] Chen, M., Zhang, R., and Duan, X., "OSPF Extensions
             in Support of Inter-Autonomous System (AS) MPLS and
             GMPLS Traffic Engineering", RFC 5392, January 2009.

   [RFC5151] Farrel, A., Ed., "Inter-Domain MPLS and GMPLS Traffic
             Engineering -- Resource Reservation Protocol-Traffic
             Engineering (RSVP-TE) Extensions", RFC 5151, February 2008.

   [RFC5654] Niven-Jenkins, B., Et al, "Requirements of an MPLS
             Transport Profile", RFC 5654, September 2009.

   [RFC5467] Berger, L., Et al, "GMPLS Asymmetric Bandwidth
             Bidirectional Label Switched Paths (LSPs)", RFC 5467, March
             2009.

   [TP-FWK] Bocci, M., Ed., Et al, "A Framework for MPLS in
            Transport Networks", work in Progress,
            draft-ietf-mpls-tp-framework-10, February 2010.

   [TP-OAM] Busi, I., Ed., Niven-Jenkins, B., Ed., "MPLS-TP OAM
            Framework and Overview", work in Progress,
            draft-ietf-mpls-tp-oam-framework-04 December 2009.

   [TP-OAM-REQ] Vigoureux, M., Ward, D, and Betts, M., "Requirements for
                OAM in MPLS Transport Networks", work in progress,
                draft-ietf-mpls-tp-oam-requirements.

   [TP-SURVIVE] Sprecher, N., et al., "Multiprotocol Label
                Switching Transport Profile Survivability
                Framework", work in Progress,
                draft-ietf-mpls-tp-survive-fwk.


10.2. Informative References

   [BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
              "BFD For MPLS LSPs", draft-ietf-bfd-mpls, work in
              progress.

   [GMPLS-ASON] Papadimitriou, D., "OSPFv2 Routing Protocols
                Extensions for ASON Routing", work in progress,
                draft-ietf-ccamp-gmpls-ason-routing-ospf.




Andersson, et al              Informational                    [Page 38]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


   [GMPLS-MLN] Papadimitriou, D., et al, "Generalized Multi-Protocol
               Label Switching (GMPLS) Protocol Extensions for
               Multi-Layer and Multi-Region Networks (MLN/MRN)", work
               in progress, draft-ietf-ccamp-gmpls-mln-extensions.

   [GMPLS-PS] Takacs, A., et al, "GMPLS RSVP-TE Recovery Extension
              for data plane initiated reversion and protection timer
              signalling", draft-takacs-ccamp-revertive-ps, work in
              progress.


   [TP-P2MP-FWK]  D. Frost, M. Bocci, and L. Berger, "A Framework for
                  Point-to-Multipoint MPLS in Transport Networks",
                  draft-fbb-mpls-tp-p2mp-framework.

   [RFC4655] A. Farrel, J.-P. Vasseur, and J. Ash, "A Path
             Computation Element (PCE) -Based Architecture", RFC4655,
             August 2006.

   [RFC5440] JP. Vasseur and JL. Le Roux, "Path Computation Element
             (PCE) Communication Protocol (PCEP)", RFC5440, March
             2009.

   [RFC4875] R. Aggarwal, D. Papadimitriou, and S. Yasukawa,
             "Extensions to Resource Reservation Protocol - Traffic
             Engineering (RSVP-TE) for Point-to-Multipoint TE Label
             Switched Paths (LSPs)", RFC4875, May 2007.

   [RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumbered Links
             in Resource ReSerVation Protocol - Traffic Engineering
             (RSVP-TE)", RFC3477, January 2003.

   [RFC4201] K. Kompella and Y. Rekhter "Link Bundling in MPLS
             Traffic Engineering (TE)", RFC4201, October 2005.

   [RFC5145]  K. Shiomoto, "Framework for MPLS-TE to GMPLS Migration"
              RFC5145, March 2008.

   [CCAMP-OAM-FWK] A. Takacs, D. Fedyk, and J. He, "OAM Configuration
                   Framework and Requirements for GMPLS RSVP-TE"
                   draft-ietf-ccamp-oam-configuration-fwk, work in
                   progress.

   [CCAMP-OAM-EXT] Bellaganba, E., et.al., "RSVP-TE Extensions for
                   MPLS-TP OAM Configuration", work in progress,
                   draft-bellagamba-ccamp-rsvp-te-mpls-tp-oam-ext.








Andersson, et al              Informational                    [Page 39]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


   [HIERARCHY-BIS] Shiomoto, K, Ed., Farrel, A, Ed., "Procedures for
                   Dynamically Signaled Hierarchical Label Switched
                   Paths", draft-ietf-ccamp-lsp-hierarchy-bis, work
                   in progress, October 2009.

   [TE-MIB] T Otani, et.al., "Traffic Engineering Database Management
            Information Base in support of MPLS-TE/GMPLS",
            draft-ietf-ccamp-gmpls-ted-mib, work in progress.

   [MS-PW-DYNAMIC] L. Martini, M Bocci, and F Balus "Dynamic
                   Placement of Multi Segment Pseudo Wires",
                   draft-ietf-pwe3-dynamic-ms-pw-10, work in
                   progress, October 2009.

   [ITU.G8080.2006] International Telecommunications Union,
                    "Architecture for the automatically switched
                    optical network (ASON)", ITU- T Recommendation
                    G.8080, June 2006.

   [ITU.G8080.2008] International Telecommunications Union,
                    "Architecture for the automatically switched
                    optical network (ASON) Amendment 1", ITU-T
                    Recommendation G.8080 Amendment 1, March 2008.

   [MPLS-SEC] Fang, L., et al, "Security Framework for MPLS and
              GMPLS Networks", work in progress,
              draft-ietf-mpls-mpls-and-gmpls-security-framework.

   [NO-PHP] Ali, z., et al, "Non PHP Behavior and out-of-band mapping
            for RSVP-TE LSPs", work in progress,
            draft-ietf-mpls-rsvp-te-no-php-oob-mapping

   [PC-SCP] Caviglia, D, et al, "RSVP-TE Signaling Extension For
            The Conversion Between Permanent Connections And Soft
            Permanent Connections In A GMPLS Enabled Transport
            Network.", draft-ietf-ccamp-pc-spc-rsvpte-ext-07.txt,
            work in progress, February 2010.

   [SEGMENTED-PW] Martini, L., Nadeau, T., and Duckett M.,
                  "Segmented Pseaudowire", work in Progress,
                  draft-ietf-pwe3-segmented-pw-13.txt, August 2009.

   [RFC3270] Le Faucheur, F., et al, "Multi-Protocol Label
             Switching (MPLS) Support of Differentiated
             Services", RFC 3270, May 2002.

   [RFC3472] Ashwood-Smith, P., Ed, Berger, L. Ed., "Generalized
             Multi-Protocol Label Switching (GMPLS) Signaling
             Constraint-based Routed Label Distribution Protocol
             (CR-LDP) Extensions", RFC 3472, January 2003.




Andersson, et al              Informational                    [Page 40]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


   [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
             (LSR) Router Management Information Base (MIB)", RFC
             3813, June 2004.

   [RFC3945] Mannie, E., "Generalized Multi-Protocol Label
             Switching (GMPLS) Architecture", RFC 3945, October
             2004.

   [RFC3985] Bryant, S. and P. Pate, "Pseudowire Emulation Edge-
             to-Edge (PWE3) Architecture", RFC 3985, March 2005.

   [RFC4139] Papadimitriou, D., et al, "Requirements for
             Generalized MPLS (GMPLS) Signaling Usage and
             Extensions for Automatically Switched Optical
             Network (ASON)", RFC4139, July 2005.

   [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter,
             Y., "Generalized Multi-Protocol 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., et al, "Requirements for Generalized
             Multi-Protocol Label Switching (GMPLS) Routing for
             the Automatically Switched Optical Network (ASON)",
             RFC4258, November 2005.

   [RFC4379] Kompella, K. and G. Swallow, "Detecting
             Multi-Protocol Label Switched (MPLS) Data Plane
             Failures", RFC 4379, February 2006.

   [RFC4426] Lang, J., Rajagopalan B., and D.Papadimitriou, Editors,
             "Generalized Multiprotocol Label Switching (GMPLS)
             Recovery Functional Specification", RFC 4426, March 2006.

   [RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection
             and Restoration) Terminology for Generalized
             Multi-Protocol Label Switching (GMPLS)", RFC4427,
             March 2006.

   [RFC4553] Vainshtein, A., Ed., and Stein, YJ., Ed.,"Structure-
             Agnostic Time Division Multiplexing (TDM) over Packet
             (SAToP)", RFC 4553, June 2006.




Andersson, et al              Informational                    [Page 41]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


   [RFC4618] Martini, L., Rosen, E., Heron, G., and Malis, A.,
             "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 Malis, A., Ed.,
             "Encapsulation Methods for Transport of Frame Relay
             over Multiprotocol Label Switching (MPLS) Networks",
             September 2006.

   [RFC4783] Berger, L.,Ed., "GMPLS - Communication of Alarm
             Information", RFC 4763, December 2006.

   [RFC4802] T. D. Nadeu and A. Farrel, "Generalized Multiprotocol
             Label Switching (GMPLS) Traffic Engineering Management
             Information Base", RFC4802, Feb., 2007.

   [RFC4803] T. D. Nadeu and A. Farrel, "Generalized Multiprotocol
             Label Switching (GMPLS) Label Switching Router (LSR)
             Management Information Base", RFC4803, Feb., 2007.

   [RFC4816] Malis, A., Martini, L., Brayley, J., and Walsh, T.,
             "Pseudowire Emulation Edge-to-Edge (PWE3)
             Asynchronous Transfer Mode (ATM) Transparent Cell
             Transport Service", RFC 4816, February 2007.

   [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual
             Circuit Connectivity Verification (VCCV) : A Control
             Channel for Pseudowires", RFC 5085, December 2007.

   [RFC5493] Caviglia, D., et al, "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 Bryant, B., "An Architecture for
             Multi-Segment Pseudowire Emulation Edge-to-Edge",
             RFC 5659, October 2009.

   [RFC5718] Bellar, D., Farrel, A., "An In-Band Data Communication
             Network For the MPLS Transport Profile", RFC 5718, January
             2010.

   [TP-RING] Weingarten, Y., Ed., "MPLS-TP Ring Protection", work in
             progress, draft-weingarten-mpls-tp-ring-protection.








Andersson, et al              Informational                    [Page 42]

Internet-Draft draft-ietf-ccamp-mpls-tp-cp-framework-00.txt March 22, 2010


   [VCCV-BFD] Nadeau, T. and C. Pignataro, "Bidirectional
              Forwarding Detection (BFD) for the Pseudowire
              Virtual Circuit Connectivity Verification (VCCV)",
              draft-ietf-pwe3-vccv-bfd, work in progress.


11. 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.
   300 Beaver Brook Road
   Boxborough, MA 01719
   USA
   Email: lufang@cisco.com

   Nabil Bitar (editor)
   Verizon,
   40 Sylvan Rd.,
   Waltham, MA 02451
   Email:   nabil.n.bitar@verizon.com

   Attila Takacs
   Ericsson
   1. Laborc u.
   Budapest, HUNGARY 1037
   Email:   attila.takacs@ericsson.com

   Martin Vigoureux
   Alcatel-Lucent
   Email:   martin.vigoureux@alcatel-lucent.fr

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








Andersson, et al              Informational                    [Page 43]
Generated on: Mon Mar 22 09:11:17 PDT 2010


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/