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 2 of 4, p. 9 to 27
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 9 
2.  Control-Plane Requirements

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

2.1.  Primary Requirements

   These requirements are based on Section 2 of [RFC5654]:

      1. Any new functionality that is defined to fulfill the
         requirements for MPLS-TP must be agreed within the IETF through
         the IETF consensus process as per [RFC4929] and Section 1,
         paragraph 15 of [RFC5654].

      2. The MPLS-TP control-plane design should as far as reasonably
         possible reuse existing MPLS standards ([RFC5654], requirement
         2).

      3. The MPLS-TP control plane must be able to interoperate with
         existing IETF MPLS and PWE3 control planes where appropriate
         ([RFC5654], requirement 3).

      4. The MPLS-TP control plane must be sufficiently well-defined to
         ensure that the interworking between equipment supplied by
         multiple vendors will be possible both within a single domain
         and between domains ([RFC5654], requirement 4).

      5. The MPLS-TP control plane must support a connection-oriented
         packet switching model with traffic engineering capabilities
         that allow deterministic control of the use of network
         resources ([RFC5654], requirement 5).

      6. The MPLS-TP control plane must support traffic-engineered
         point-to-point (P2P) and point-to-multipoint (P2MP) transport
         paths ([RFC5654], requirement 6).

Top      Up      ToC       Page 10 
      7. The MPLS-TP control plane must support unidirectional,
         associated bidirectional and co-routed bidirectional point-to-
         point transport paths ([RFC5654], requirement 7).

      8. The MPLS-TP control plane must support unidirectional point-to-
         multipoint transport paths ([RFC5654], requirement 8).

      9. The MPLS-TP control plane must enable all nodes (i.e., ingress,
         egress, and intermediate) to be aware about the pairing
         relationship of the forward and the backward directions
         belonging to the same co-routed bidirectional transport path
         ([RFC5654], requirement 10).

     10. The MPLS-TP control plane must enable edge nodes (i.e., ingress
         and egress) to be aware of the pairing relationship of the
         forward and the backward directions belonging to the same
         associated bidirectional transport path ([RFC5654], requirement
         11).

     11. The MPLS-TP control plane should enable common transit nodes to
         be aware of the pairing relationship of the forward and the
         backward directions belonging to the same associated
         bidirectional transport path ([RFC5654], requirement 12).

     12. The MPLS-TP control plane must support bidirectional transport
         paths with symmetric bandwidth requirements, i.e., the amount
         of reserved bandwidth is the same in the forward and backward
         directions ([RFC5654], requirement 13).

     13. The MPLS-TP control plane must support bidirectional transport
         paths with asymmetric bandwidth requirements, i.e., the amount
         of reserved bandwidth differs in the forward and backward
         directions ([RFC5654], requirement 14).

     14. The MPLS-TP control plane must support the logical separation
         of the control plane from the management and data planes
         ([RFC5654], requirement 15).  Note that this implies that the
         addresses used in the control plane are independent from the
         addresses used in the management and data planes.

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

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

     17. The presence of a control plane must not be required for static
         provisioning of MPLS-TP transport paths ([RFC5654], requirement
         19).

     18. The MPLS-TP control plane must permit the coexistence of
         statically and dynamically provisioned/managed MPLS-TP
         transport paths within the same layer network or domain
         ([RFC5654], requirement 20).

     19. The MPLS-TP control plane should be operable in a way that is
         similar to the way the control plane operates in other
         transport-layer technologies ([RFC5654], requirement 21).

     20. The MPLS-TP control plane must avoid or minimize traffic impact
         (e.g., packet delay, reordering, and loss) during network
         reconfiguration ([RFC5654], requirement 24).

     21. The MPLS-TP control plane must work across multiple homogeneous
         domains ([RFC5654], requirement 25), i.e., all domains use the
         same MPLS-TP control plane.

     22. The MPLS-TP control plane should work across multiple non-
         homogeneous domains ([RFC5654], requirement 26), i.e., some
         domains use the same control plane and other domains use static
         provisioning at the domain boundary.

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

     24. The MPLS-TP control plane must include support of ring
         topologies that may be deployed with arbitrary interconnection
         and support of rings of at least 16 nodes ([RFC5654],
         requirements 27.A, 27.B, and 27.C).

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

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

Top      Up      ToC       Page 12 
     27. The MPLS-TP control plane must support multiple client layers
         (e.g., MPLS-TP, IP, MPLS, Ethernet, ATM, Frame Relay, etc.)
         ([RFC5654], requirement 30).

     28. The MPLS-TP control plane must provide a generic and extensible
         solution to support the transport of MPLS-TP transport paths
         over one or more server-layer networks (such as MPLS-TP,
         Ethernet, Synchronous Optical Network / Synchronous Digital
         Hierarchy (SONET/SDH), Optical Transport Network (OTN), etc.).
         Requirements for bandwidth management within a server-layer
         network are outside the scope of this document ([RFC5654],
         requirement 31).

     29. In an environment where an MPLS-TP layer network is supporting
         a client-layer network, and the MPLS-TP layer network is
         supported by a server-layer network, then the control-plane
         operation of the MPLS-TP layer network must be possible without
         any dependencies on the server or client-layer network
         ([RFC5654], requirement 32).

     30. The MPLS-TP control plane must allow for the transport of a
         client MPLS or MPLS-TP layer network over a server MPLS or
         MPLS-TP layer network ([RFC5654], requirement 33).

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

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

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

     34. The MPLS-TP control plane must allow for the use of P2MP server
         (sub-)layer capabilities as well as P2P server (sub-)layer
         capabilities when supporting P2MP MPLS-TP transport paths
         ([RFC5654], requirement 40).

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

Top      Up      ToC       Page 13 
     36. The MPLS-TP control plane should support the reserved bandwidth
         associated with a transport path to be increased without
         impacting the existing traffic on that transport path, provided
         enough resources are available ([RFC5654], requirement 42)).

     37. The MPLS-TP control plane should support the reserved bandwidth
         of a transport path being decreased without impacting the
         existing traffic on that transport path, provided that the
         level of existing traffic is smaller than the reserved
         bandwidth following the decrease ([RFC5654], requirement 43).

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

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

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

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

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

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

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

Top      Up      ToC       Page 14 
     45. The MPLS-TP control plane must be capable of restarting and
         relearning its previous state without impacting forwarding
         ([RFC5654], requirement 54).

     46. The MPLS-TP control plane must provide a mechanism for dynamic
         ownership transfer of the control of MPLS-TP transport paths
         from the management plane to the control plane and vice versa.
         The number of reconfigurations required in the data plane must
         be minimized; preferably no data-plane reconfiguration will be
         required ([RFC5654], requirement 55).  Note, such transfers
         cover all transport path control functions including control of
         recovery and OAM.

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

         Note that the MPLS-TP survivability framework document
         [RFC6372] provides additional useful information related to
         recovery.

     48. The MPLS-TP control-plane mechanisms should be identical (or as
         similar as possible) to those already used in existing
         transport networks to simplify implementation and operations.
         However, this must not override any other requirement
         ([RFC5654], requirement 56 A).

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

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

     51. The MPLS-TP control plane must support recovery paths that meet
         the Service Level Agreement (SLA) protection objectives of the
         service ([RFC5654], requirement 58).  These include:

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

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

         c. Recovery must meet SLA requirements over multiple domains.

Top      Up      ToC       Page 15 
     52. The MPLS-TP control plane should support per-transport-path
         recovery objectives ([RFC5654], requirement 59).

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

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

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

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

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

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

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

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

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

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

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

Top      Up      ToC       Page 16 
     64. The MPLS-TP control plane may support the control of extra-
         traffic type traffic ([RFC5654], note after requirement 67).

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

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

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

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

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

     70. The MPLS-TP control plane must support revertive and non-
         revertive restoration behavior ([RFC5654], requirement 73).

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

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

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

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

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

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

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

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

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

     80. The MPLS-TP control plane must support the external commands
         defined in [RFC4427].  External controls overruled by higher
         priority requests (e.g., administrative requests and requests
         due to link/node failures) or unable to be signaled to the
         remote end (e.g., because of a protection state coordination
         fail) must be ignored/dropped ([RFC5654], requirement 83).

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

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

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

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

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

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

Top      Up      ToC       Page 18 
     87. The MPLS-TP control plane must support protection state
         coordination.  Since control-plane network topology is
         independent from the data-plane network topology, the
         protection state coordination supported by the MPLS-TP control
         plane may run on resources different than the data-plane
         resources handled within the recovery mechanism (e.g., backup)
         ([RFC5654], requirement 89 C).

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

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

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

     91. The MPLS-TP control plane must support the provisioning of
         services that provide guaranteed Service Level Specifications
         (SLSs), with support for hard ([RFC3209] style) and relative
         ([RFC3270] style) end-to-end bandwidth guarantees ([RFC5654],
         requirement 111).

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

2.2.  Requirements Derived from the MPLS-TP Framework

   The following additional requirements are based on [RFC5921],
   [TP-P2MP-FWK], and [RFC5960]:

     93. Per-packet Equal Cost Multi-Path (ECMP) load balancing is
         currently outside the scope of MPLS-TP ([RFC5960], Section
         3.1.1, paragraph 6).

     94. Penultimate Hop Popping (PHP) must be disabled on MPLS-TP LSPs
         by default ([RFC5960], Section 3.1.1, paragraph 7).

Top      Up      ToC       Page 19 
     95. The MPLS-TP control plane must support both E-LSP (Explicitly
         TC-encoded-PSC LSP) and L-LSP (Label-Only-Inferred-PSC LSP)
         MPLS Diffserv modes as specified in [RFC3270], [RFC5462], and
         Section 3.3.2, paragraph 12 of [RFC5960].

     96. Both Single-Segment PWs (see [RFC3985]) and Multi-Segment PWs
         (see [RFC5659]) shall be supported by the MPLS-TP control
         plane.  MPLS-TP shall use the definition of Multi-Segment PWs
         as defined by the IETF ([RFC5921], Section 3.4.4).

     97. The MPLS-TP control plane must support the control of PWs and
         their associated labels ([RFC5921], Section 3.4.4).

     98. The MPLS-TP control plane must support network-layer clients,
         i.e., clients whose traffic is transported over an MPLS-TP
         network without the use of PWs ([RFC5921], Section 3.4.5).

         a. The MPLS-TP control plane must support the use of network-
            layer protocol-specific LSPs and labels ([RFC5921], Section
            3.4.5).

         b. The MPLS-TP control plane must support the use of a client-
            service-specific LSPs and labels ([RFC5921], Section 3.4.5).

     99. The MPLS-TP control plane for LSPs must be based on the GMPLS
         control plane.  More specifically, GMPLS RSVP-TE [RFC3473] and
         related extensions are used for LSP signaling, and GMPLS OSPF-
         TE [RFC5392] and ISIS-TE [RFC5316] are used for routing
         ([RFC5921], Section 3.9).

    100. The MPLS-TP control plane for PWs must be based on the MPLS
         control plane for PWs, and more specifically, targeted LDP (T-
         LDP) [RFC4447] is used for PW signaling ([RFC5921], Section
         3.9, paragraph 5).

    101. The MPLS-TP control plane must ensure its own survivability and
         be able to recover gracefully from failures and degradations.
         These include graceful restart and hot redundant configurations
         ([RFC5921], Section 3.9, paragraph 16).

    102. The MPLS-TP control plane must support linear, ring, and meshed
         protection schemes ([RFC5921], Section 3.12, paragraph 3).

    103. The MPLS-TP control plane must support the control of SPMEs
         (hierarchical LSPs) for new or existing end-to-end LSPs
         ([RFC5921], Section 3.12, paragraph 7).

Top      Up      ToC       Page 20 
2.3.  Requirements Derived from the OAM Framework

   The following additional requirements are based on [RFC5860] and
   [RFC6371]:

    104. The MPLS-TP control plane must support the capability to
         enable/disable OAM functions as part of service establishment
         ([RFC5860], Section 2.1.6, paragraph 1.  Note that OAM
         functions are applicable regardless of the label stack depth
         (i.e., level of LSP hierarchy or PW) ([RFC5860], Section 2.1.1,
         paragraph 3).

    105. The MPLS-TP control plane must support the capability to
         enable/disable OAM functions after service establishment.  In
         such cases, the customer must not perceive service degradation
         as a result of OAM enabling/disabling ([RFC5860], Section
         2.1.6, paragraphs 1 and 2).

    106. The MPLS-TP control plane must support dynamic control of any
         of the existing IP/MPLS and PW OAM protocols, e.g., LSP-Ping
         [RFC4379], MPLS-BFD [RFC5884], VCCV [RFC5085], and VCCV-BFD
         [RFC5885] ([RFC5860], Section 2.1.4, paragraph 2).

    107. The MPLS-TP control plane must allow for the ability to support
         experimental OAM functions.  These functions must be disabled
         by default ([RFC5860], Section 2.2, paragraph 2).

    108. The MPLS-TP control plane must support the choice of which (if
         any) OAM function(s) to use and to which PW, LSP or Section it
         applies ([RFC5860], Section 2.2, paragraph 3).

    109. The MPLS-TP control plane must allow (e.g., enable/disable)
         mechanisms that support the localization of faults and the
         notification of appropriate nodes ([RFC5860], Section 2.2.1,
         paragraph 1).

    110. The MPLS-TP control plane may support mechanisms that permit
         the service provider to be informed of a fault or defect
         affecting the service(s) it provides, even if the fault or
         defect is located outside of his domain ([RFC5860], Section
         2.2.1, paragraph 2).

    111. Information exchange between various nodes involved in the
         MPLS-TP control plane should be reliable such that, for
         example, defects or faults are properly detected or that state
         changes are effectively known by the appropriate nodes
         ([RFC5860], Section 2.2.1, paragraph 3).

Top      Up      ToC       Page 21 
    112. The MPLS-TP control plane must provide functionality to control
         an end point's ability to monitor the liveness of a PW, LSP, or
         Section ([RFC5860], Section 2.2.2, paragraph 1).

    113. The MPLS-TP control plane must provide functionality to control
         an end point's ability to determine whether or not it is
         connected to specific end point(s) by means of the expected PW,
         LSP, or Section ([RFC5860], Section 2.2.3, paragraph 1).

         a. The MPLS-TP control plane must provide mechanisms to control
            an end point's ability to perform this function proactively
            ([RFC5860], Section 2.2.3, paragraph 2).

         b. The MPLS-TP control plane must provide mechanisms to control
            an end point's ability to perform this function on-demand
            ([RFC5860], Section 2.2.3, paragraph 3).

    114. The MPLS-TP control plane must provide functionality to control
         diagnostic testing on a PW, LSP or Section ([RFC5860], Section
         2.2.5, paragraph 1).

         a. The MPLS-TP control plane must provide mechanisms to control
            the performance of this function on-demand ([RFC5860],
            Section 2.2.5, paragraph 2).

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

         a. The MPLS-TP control plane must provide mechanisms to control
            the performance of this function on-demand ([RFC5860],
            Section 2.2.4, paragraph 2).

    116. The MPLS-TP control plane must provide functionality to enable
         an end point of a PW, LSP, or Section to instruct its
         associated end point(s) to lock the PW, LSP, or Section
         ([RFC5860], Section 2.2.6, paragraph 1).

         a. The MPLS-TP control plane must provide mechanisms to control
            the performance of this function on-demand ([RFC5860],
            Section 2.2.6, paragraph 2).

Top      Up      ToC       Page 22 
    117. The MPLS-TP control plane must provide functionality to enable
         an Intermediate Point of a PW or LSP to report, to an end point
         of that same PW or LSP, a lock condition indirectly affecting
         that PW or LSP ([RFC5860], Section 2.2.7, paragraph 1).

         a. The MPLS-TP control plane must provide mechanisms to control
            the performance of this function proactively ([RFC5860],
            Section 2.2.7, paragraph 2).

    118. The MPLS-TP control plane must provide functionality to enable
         an Intermediate Point of a PW or LSP to report, to an end point
         of that same PW or LSP, a fault or defect condition affecting
         that PW or LSP ([RFC5860], Section 2.2.8, paragraph 1).

         a. The MPLS-TP control plane must provide mechanisms to control
            the performance of this function proactively ([RFC5860],
            Section 2.2.8, paragraph 2).

    119. The MPLS-TP control plane must provide functionality to enable
         an end point to report, to its associated end point, a fault or
         defect condition that it detects on a PW, LSP, or Section for
         which they are the end points ([RFC5860], Section 2.2.9,
         paragraph 1).

         a. The MPLS-TP control plane must provide mechanisms to control
            the performance of this function proactively ([RFC5860],
            Section 2.2.9, paragraph 2).

    120. The MPLS-TP control plane must provide functionality to enable
         the propagation, across an MPLS-TP network, of information
         pertaining to a client defect or fault condition detected at an
         end point of a PW or LSP, if the client-layer mechanisms do not
         provide an alarm notification/propagation mechanism ([RFC5860],
         Section 2.2.10, paragraph 1).

         a. The MPLS-TP control plane must provide mechanisms to control
            the performance of this function proactively ([RFC5860],
            Section 2.2.10, paragraph 2).

    121. The MPLS-TP control plane must provide functionality to enable
         the control of quantification of packet loss ratio over a PW,
         LSP, or Section ([RFC5860], Section 2.2.11, paragraph 1).

         a. The MPLS-TP control plane must provide mechanisms to control
            the performance of this function proactively and on-demand
            ([RFC5860], Section 2.2.11, paragraph 4).

Top      Up      ToC       Page 23 
    122. The MPLS-TP control plane must provide functionality to control
         the quantification and reporting of the one-way, and if
         appropriate, the two-way, delay of a PW, LSP, or Section
         ([RFC5860], Section 2.2.12, paragraph 1).

         a. The MPLS-TP control plane must provide mechanisms to control
            the performance of this function proactively and on-demand
            ([RFC5860], Section 2.2.12, paragraph 6).

    123. The MPLS-TP control plane must support the configuration of OAM
         functional components that include Maintenance Entities (MEs)
         and Maintenance Entity Groups (MEGs) as instantiated in MEPs,
         MIPs, and SPMEs ([RFC6371], Section 3.6).

    124. For dynamically established transport paths, the control plane
         must support the configuration of OAM operations ([RFC6371],
         Section 5).

         a. The MPLS-TP control plane must provide mechanisms to
            configure proactive monitoring for a MEG at, or after,
            transport path creation time.

         b. The MPLS-TP control plane must provide mechanisms to
            configure the operational characteristics of in-band
            measurement transactions (e.g., Connectivity Verification
            (CV), Loss Measurement (LM), etc.) at MEPs (associated with
            a transport path).

         c. The MPLS-TP control plane may provide mechanisms to
            configure server-layer event reporting by intermediate
            nodes.

         d. The MPLS-TP control plane may provide mechanisms to
            configure the reporting of measurements resulting from
            proactive monitoring.

    125. The MPLS-TP control plane must support the control of the loss
         of continuity (LOC) traffic block consequent action ([RFC6371],
         Section 5.1.2, paragraph 4).

    126. For dynamically established transport paths that have a
         proactive Continuity Check and Connectivity Verification (CC-V)
         function enabled, the control plane must support the signaling
         of the following MEP configuration information ([RFC6371],
         Section 5.1.3):

         a. The MPLS-TP control plane must provide mechanisms to
            configure the MEG identifier to which the MEP belongs.

Top      Up      ToC       Page 24 
         b. The MPLS-TP control plane must provide mechanisms to
            configure a MEP's own identity inside a MEG.

         c. The MPLS-TP control plane must provide mechanisms to
            configure the list of the other MEPs in the MEG.

         d. The MPLS-TP control plane must provide mechanisms to
            configure the CC-V transmission rate / reception period
            (covering all application types).

    127. The MPLS-TP control plane must provide mechanisms to configure
         the generation of Alarm Indication Signal (AIS) packets for
         each MEG ([RFC6371], Section 5.3, paragraph 9).

    128. The MPLS-TP control plane must provide mechanisms to configure
         the generation of Lock Report (LKR) packets for each MEG
         ([RFC6371], Section 5.4, paragraph 9).

    129. The MPLS-TP control plane must provide mechanisms to configure
         the use of proactive Packet Loss Measurement (LM), and the
         transmission rate and Per-Hop Behavior (PHB) class associated
         with the LM OAM packets originating from a MEP ([RFC6371],
         Section 5.5.1, paragraph 1).

    130. The MPLS-TP control plane must provide mechanisms to configure
         the use of proactive Packet Delay Measurement (DM), and the
         transmission rate and PHB class associated with the DM OAM
         packets originating from a MEP ([RFC6371], Section 5.6.1,
         paragraph 1).

    131. The MPLS-TP control plane must provide mechanisms to configure
         the use of Client Failure Indication (CFI), and the
         transmission rate and PHB class associated with the CFI OAM
         packets originating from a MEP ([RFC6371], Section 5.7.1,
         paragraph 1).

    132. The MPLS-TP control plane should provide mechanisms to control
         the use of on-demand CV packets ([RFC6371], Section 6.1).

         a. The MPLS-TP control plane should provide mechanisms to
            configure the number of packets to be transmitted/received
            in each burst of on-demand CV packets and their packet size
            ([RFC6371], Section 6.1.1, paragraph 1).

         b. When an on-demand CV packet is used to check connectivity
            toward a target MIP, the MPLS-TP control plane should
            provide mechanisms to configure the number of hops to reach
            the target MIP ([RFC6371], Section 6.1.1, paragraph 2).

Top      Up      ToC       Page 25 
         c. The MPLS-TP control plane should provide mechanisms to
            configure the PHB of on-demand CV packets ([RFC6371],
            Section 6.1.1, paragraph 3).

    133. The MPLS-TP control plane should provide mechanisms to control
         the use of on-demand LM, including configuration of the
         beginning and duration of the LM procedures, the transmission
         rate, and PHB associated with the LM OAM packets originating
         from a MEP ([RFC6371], Section 6.2.1).

    134. The MPLS-TP control plane should provide mechanisms to control
         the use of throughput estimation ([RFC6371], Section 6.3.1).

    135. The MPLS-TP control plane should provide mechanisms to control
         the use of on-demand DM, including configuration of the
         beginning and duration of the DM procedures, the transmission
         rate, and PHB associated with the DM OAM packets originating
         from a MEP ([RFC6371], Section 6.5.1).

2.4. Security Requirements

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

2.5. Identifier Requirements

   The following are requirements based on [RFC6370]:

    136. The MPLS-TP control plane must support MPLS-TP point-to-point
         tunnel identifiers of the forms defined in Section 5.1 of
         [RFC6370].

    137. The MPLS-TP control plane must support MPLS-TP LSP identifiers
         of the forms defined in Section 5.2 of [RFC6370], and the
         mappings to GMPLS as defined in Section 5.3 of [RFC6370].

    138. The MPLS-TP control plane must support pseudowire path
         identifiers of the form defined in Section 6 of [RFC6370].

    139. The MPLS-TP control plane must support MEG_IDs for LSPs and PWs
         as defined in Section 7.1.1 of [RFC6370].

    140. The MPLS-TP control plane must support IP-compatible MEG_IDs
         for LSPs and PWs as defined in Section 7.1.2 of [RFC6370].

    141. The MPLS-TP control plane must support MEP_IDs for LSPs and PWs
         of the forms defined in Section 7.2.1 of [RFC6370].

Top      Up      ToC       Page 26 
    142. The MPLS-TP control plane must support IP-based MEP_IDs for
         MPLS-TP LSP of the forms defined in Section 7.2.2.1 of
         [RFC6370].

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

3. Relationship of PWs and TE LSPs

   The data-plane relationship between PWs and LSPs is inherited from
   standard MPLS and is reviewed in the MPLS-TP framework [RFC5921].
   Likewise, the control-plane relationship between PWs and LSPs is
   inherited from standard MPLS.  This relationship is reviewed in this
   document.  The relationship between the PW and LSP control planes in
   MPLS-TP is the same as the relationship found in the PWE3 Maintenance
   Reference Model as presented in the PWE3 architecture; see Figure 6
   of [RFC3985].  The PWE3 architecture [RFC3985] states: "The PWE3
   protocol-layering model is intended to minimize the differences
   between PWs operating over different PSN types".  Additionally, PW
   control (maintenance) takes place separately from LSP signaling.
   [RFC4447] and [MS-PW-DYNAMIC] provide such extensions for the use of
   LDP as the control plane for PWs.  This control can provide PW
   control without providing LSP control.

   In the context of MPLS-TP, LSP tunnel signaling is provided via GMPLS
   RSVP-TE.  While RSVP-TE could be extended to support PW control much
   as LDP was extended in [RFC4447], such extensions are out of scope of
   this document.  This means that the control of PWs and LSPs will
   operate largely independently.  The main coordination between LSP and
   PW control will occur within the nodes that terminate PWs or PW
   segments.  See Section 5.3.2 for an additional discussion on such
   coordination.

   It is worth noting that the control planes for PWs and LSPs may be
   used independently, and that one may be employed without the other.
   This translates into four possible scenarios: (1) no control plane is
   employed; (2) a control plane is used for both LSPs and PWs; (3) a
   control plane is used for LSPs, but not PWs; (4) a control plane is
   used for PWs, but not LSPs.

   The PW and LSP control planes, collectively, must satisfy the MPLS-TP
   control-plane requirements reviewed in this document.  When client
   services are provided directly via LSPs, all requirements must be
   satisfied by the LSP control plane.  When client services are
   provided via PWs, the PW and LSP control planes can operate in
   combination, and some functions may be satisfied via the PW control
   plane while others are provided to PWs by the LSP control plane.  For

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



(page 27 continued on part 3)

Next RFC Part