tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6373


MPLS Transport Profile (MPLS-TP) Control Plane Framework

Part 3 of 4, p. 27 to 39
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 27 
4. TE LSPs

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

4.1.  GMPLS Functions and MPLS-TP LSPs

   This section reviews how existing GMPLS functions can be applied to

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

   GMPLS supports both in-band and out-of-band control.  The terms "in-
   band" and "out-of-band", in the context of this document, refer to
   the relationship of the control plane relative to the management and
   data planes.  The terms may be used to refer to the control plane
   independent of the management plane, or to both of them in concert.
   The remainder of this section describes the relationship of the
   control plane to the management and data planes.

   There are multiple uses of both terms "in-band" and "out-of-band".
   The terms may relate to a channel, a path, or a network.  Each of
   these can be used independently or in combination.  Briefly, some
   typical usage of the terms is as follows:

   o  In-band
      This term is used to refer to cases where control-plane traffic is
      sent in the same communication channel used to transport
      associated user data or management traffic.  IP, MPLS, and
      Ethernet networks are all examples where control traffic is
      typically sent in-band with the data traffic.  An example of this
      case in the context of MPLS-TP is where control-plane traffic is
      sent via the MPLS Generic Associated Channel (G-ACh), see
      [RFC5586], using the same LSP as controlled user traffic.

Top      Up      ToC       Page 28 
   o  Out-of-band, in-fiber (same physical connection)
      This term is used to refer to cases where control-plane traffic is
      sent using a different communication channel from the associated
      data or management traffic, and the control communication channel
      resides in the same fiber as either the management or data
      traffic.  An example of this case in the context of MPLS-TP is
      where control-plane traffic is sent via the G-ACh using a
      dedicated LSP on the same link (interface) that carries controlled
      user traffic.

   o  Out-of-band, aligned topology
      This term is used to refer to the cases where control-plane
      traffic is sent using a different communication channel from the
      associated data or management traffic, and the control traffic
      follows the same node-to-node path as either the data or
      management traffic.

      Such topologies are usually supported using a parallel fiber or
      other configurations where multiple data channels are available
      and one is (dynamically) selected as the control channel.  An
      example of this case in the context of MPLS-TP is where control-
      plane traffic is sent along the same nodal path, but not
      necessarily the same links (interfaces), as the corresponding
      controlled user traffic.

   o  Out-of-band, independent topology
      This term is used to refer to the cases where control-plane
      traffic is sent using a different communication channel from the
      associated data or management traffic, and the control traffic may
      follow a path that is completely independent of the data traffic.

      Such configurations are a superset of the other cases and do not
      preclude the use of in-fiber or aligned topology links, but
      alignment is not required.  An example of this case in the context
      of MPLS-TP is where control-plane traffic is sent between
      controlling nodes using any available path and links, completely
      without regard for the path(s) taken by corresponding management
      or user traffic.

   In the context of MPLS-TP requirements, requirement 14 (see Section 2
   above) can be met using out-of-band in-fiber or aligned topology
   types of control.  Requirement 15 can only be met by using out-of-
   band, independent topology.  G-ACh is likely to be used extensively
   in MPLS-TP networks to support the MPLS-TP control (and management)

Top      Up      ToC       Page 29 
4.1.2. Addressing

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

4.1.3.  Routing

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

4.1.4.  TE LSPs and Constraint-Based Path Computation

   Both MPLS and GMPLS allow for traffic engineering and constraint-
   based path computation.  MPLS path computation provides paths for
   MPLS-TE unidirectional P2P and P2MP LSPs.  GMPLS path computation
   adds bidirectional LSPs, explicit recovery path computation, as well
   as support for the other functions discussed in this section.

   Both MPLS and GMPLS path computation allow for the restriction of
   path selection based on the use of Explicit Route Objects (EROs) and
   other LSP attributes; see [RFC3209] and [RFC3473].  In all cases, no

Top      Up      ToC       Page 30 
   specific algorithm is standardized by the IETF.  This is anticipated
   to continue to be the case for MPLS-TP LSPs.  Relation to PCE

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

4.1.5.  Signaling

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

   GMPLS signaling includes a number of MPLS-TP required functions --
   notably, support for out-of-band control, bidirectional LSPs, and
   independent control- and data-plane fault management.  There are also
   numerous other GMPLS and MPLS extensions that can be used to provide
   specific functions in MPLS-TP networks.  Specific references are
   provided below.

4.1.6.  Unnumbered Links

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

4.1.7.  Link Bundling

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

Top      Up      ToC       Page 31 
4.1.8.  Hierarchical LSPs

   This section reuses text from [RFC6107].

   [RFC3031] describes how MPLS labels may be stacked so that LSPs may
   be nested with one LSP running through another.  This concept of
   hierarchical LSPs (H-LSPs) is formalized in [RFC4206] with a set of
   protocol mechanisms for the establishment of a hierarchical LSP that
   can carry one or more other LSPs.

   [RFC4206] goes on to explain that a hierarchical LSP may carry other
   LSPs only according to their switching types.  This is a function of
   the way labels are carried.  In a packet switch capable network, the
   hierarchical LSP can carry other packet switch capable LSPs using the
   MPLS label stack.

   Signaling mechanisms defined in [RFC4206] allow a hierarchical LSP to
   be treated as a single hop in the path of another LSP.  This
   mechanism is also sometimes known as "non-adjacent signaling", see

   A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link
   created from an LSP and advertised in the same instance of the
   control plane that advertises the TE links from which the LSP is
   constructed.  The LSP itself is called an FA-LSP.  FA-LSPs are
   analogous to MPLS-TP Sections as discussed in [RFC5960].

   Thus, a hierarchical LSP may form an FA such that it is advertised as
   a TE link in the same instance of the routing protocol as was used to
   advertise the TE links that the LSP traverses.

   As observed in [RFC4206], the nodes at the ends of an FA would not
   usually have a routing adjacency.

   LSP hierarchy is expected to play an important role in MPLS-TP
   networks, particularly in the context of scaling and recovery as well
   as supporting SPMEs.

4.1.9.  LSP Recovery

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

Top      Up      ToC       Page 32 
   The five defined types of recovery defined in GMPLS are:

      - 1+1 bidirectional protection for P2P LSPs
      - 1+1 unidirectional protection for P2MP LSPs
      - 1:n (including 1:1) protection with or without extra traffic
      - Rerouting without extra traffic (sometimes known as soft
        rerouting), including shared mesh restoration
      - Full LSP rerouting

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

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

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

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

   MPLS-TP is defined to support a comprehensive set of MPLS-TP OAM
   functions.  The MPLS-TP control plane will not itself provide OAM
   functions, but it will be used to instantiate and otherwise control
   MPLS-TP OAM functions.

   Specific OAM requirements for MPLS-TP are documented in [RFC5860].
   This document also states that it is required that the control plane
   be able to configure and control OAM entities.  This requirement is
   not yet addressed by the existing RFCs, but such work is now under
   way, e.g., [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT].

   Many OAM functions occur on a per-LSP basis, are typically in-band,
   and are initiated immediately after LSP establishment.  Hence, it is
   desirable that such functions be established and activated via the

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

4.2.1.  Management-Plane Support

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

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

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

4.3.  GMPLS and MPLS-TP Requirements Table

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

   | Req # | References                                                |
   |    1  | Generic requirement met by using Standards Track RFCs     |
   |    2  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307]     |
   |    3  | [RFC5145] + Formal Definition (See Section 4.4.1)         |
   |    4  | Generic requirement met by using Standards Track RFCs     |
   |    5  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307]     |
   |    6  | [RFC3471], [RFC3473], [RFC4875]                           |
   |    7  | [RFC3471], [RFC3473] +                                    |
   |       |    Associated bidirectional LSPs (See Section 4.4.2)      |
   |    8  | [RFC4875]                                                 |
   |    9  | [RFC3473]                                                 |
   |   10  | Associated bidirectional LSPs (See Section 4.4.2)         |
   |   11  | Associated bidirectional LSPs (See Section 4.4.2)         |
   |   12  | [RFC3473]                                                 |
   |   13  | [RFC5467] (Currently Experimental; See Section 4.4.3)     |
   |   14  | [RFC3945], [RFC3473], [RFC4202], [RFC4203], [RFC5307]     |
   |   15  | [RFC3945], [RFC3473], [RFC4202], [RFC4203], [RFC5307]     |
   |   16  | [RFC3945], [RFC4202], [RFC3473], [RFC4203], [RFC5307]     |
   |   17  | [RFC3945], [RFC4202] + proper vendor implementation       |
   |   18  | [RFC3945], [RFC4202] + proper vendor implementation       |
   |   19  | [RFC3945], [RFC4202]                                      |

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

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

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

               Table 1: GMPLS and MPLS-TP Requirements Table

4.4.  Anticipated MPLS-TP-Related Extensions and Definitions

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

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

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

Top      Up      ToC       Page 38 
4.4.2.  Associated Bidirectional LSPs

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

      o  GMPLS calls [RFC4974].

      o  The ASSOCIATION object [RFC4872].

      o  The LSP_TUNNEL_INTERFACE_ID object [RFC6107].

4.4.3.  Asymmetric Bandwidth LSPs

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

4.4.4.  Recovery for P2MP LSPs

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

4.4.5.  Test Traffic Control and Other OAM Functions

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

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

4.4.6.  Diffserv Object Usage in GMPLS

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

4.4.7.  Support for MPLS-TP LSP Identifiers

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

4.4.8.  Support for MPLS-TP Maintenance Identifiers

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

(page 39 continued on part 4)

Next RFC Part