RFC 6373
MPLS Transport Profile (MPLS-TP) Control Plane Framework
Pages: 57
Informational
Informational
Part 3 of 4 – Pages 27 to 39
4. TE LSPs
MPLS-TP uses Generalized MPLS (GMPLS) signaling and routing, see [RFC3945], as the control plane for LSPs. The GMPLS control plane is based on the MPLS control plane. GMPLS includes support for MPLS labeled data and transport data planes. GMPLS includes most of the transport-centric features required to support MPLS-TP LSPs. This section will first review the features of GMPLS relevant to MPLS-TP LSPs, then identify how specific requirements can be met using existing GMPLS functions, and will conclude with extensions that are anticipated to support the remaining MPLS-TP control-plane requirements.4.1. GMPLS Functions and MPLS-TP LSPs
This section reviews how existing GMPLS functions can be applied to MPLS-TP.4.1.1. In-Band and Out-of-Band Control
GMPLS supports both in-band and out-of-band control. The terms "in- band" and "out-of-band", in the context of this document, refer to the relationship of the control plane relative to the management and data planes. The terms may be used to refer to the control plane independent of the management plane, or to both of them in concert. The remainder of this section describes the relationship of the control plane to the management and data planes. There are multiple uses of both terms "in-band" and "out-of-band". The terms may relate to a channel, a path, or a network. Each of these can be used independently or in combination. Briefly, some typical usage of the terms is as follows: o In-band This term is used to refer to cases where control-plane traffic is sent in the same communication channel used to transport associated user data or management traffic. IP, MPLS, and Ethernet networks are all examples where control traffic is typically sent in-band with the data traffic. An example of this case in the context of MPLS-TP is where control-plane traffic is sent via the MPLS Generic Associated Channel (G-ACh), see [RFC5586], using the same LSP as controlled user traffic.
o Out-of-band, in-fiber (same physical connection)
This term is used to refer to cases where control-plane traffic is
sent using a different communication channel from the associated
data or management traffic, and the control communication channel
resides in the same fiber as either the management or data
traffic. An example of this case in the context of MPLS-TP is
where control-plane traffic is sent via the G-ACh using a
dedicated LSP on the same link (interface) that carries controlled
user traffic.
o Out-of-band, aligned topology
This term is used to refer to the cases where control-plane
traffic is sent using a different communication channel from the
associated data or management traffic, and the control traffic
follows the same node-to-node path as either the data or
management traffic.
Such topologies are usually supported using a parallel fiber or
other configurations where multiple data channels are available
and one is (dynamically) selected as the control channel. An
example of this case in the context of MPLS-TP is where control-
plane traffic is sent along the same nodal path, but not
necessarily the same links (interfaces), as the corresponding
controlled user traffic.
o Out-of-band, independent topology
This term is used to refer to the cases where control-plane
traffic is sent using a different communication channel from the
associated data or management traffic, and the control traffic may
follow a path that is completely independent of the data traffic.
Such configurations are a superset of the other cases and do not
preclude the use of in-fiber or aligned topology links, but
alignment is not required. An example of this case in the context
of MPLS-TP is where control-plane traffic is sent between
controlling nodes using any available path and links, completely
without regard for the path(s) taken by corresponding management
or user traffic.
In the context of MPLS-TP requirements, requirement 14 (see Section 2
above) can be met using out-of-band in-fiber or aligned topology
types of control. Requirement 15 can only be met by using out-of-
band, independent topology. G-ACh is likely to be used extensively
in MPLS-TP networks to support the MPLS-TP control (and management)
planes.
4.1.2. Addressing
MPLS-TP reuses and supports the addressing mechanisms supported by MPLS. The MPLS-TP identifiers document (see [RFC6370]) provides additional context on how IP addresses are used within MPLS-TP. MPLS, and consequently MPLS-TP, uses the IPv4 and IPv6 address families to identify MPLS-TP nodes by default for network management and signaling purposes. The address spaces and neighbor adjacencies in the control, management, and data planes used in an MPLS-TP network may be completely separated or combined at the discretion of an MPLS-TP operator and based on the equipment capabilities of a vendor. The separation of the control and management planes from the data plane allows each plane to be independently addressable. Each plane may use addresses that are not mutually reachable, e.g., it is likely that the data plane will not be able to reach an address from the management or control planes and vice versa. Each plane may also use a different address family. It is even possible to reuse addresses in each plane, but this is not recommended as it may lead to operational confusion. As previously mentioned, the G-ACh mechanism defined in [RFC5586] is expected to be used extensively in MPLS-TP networks to support the MPLS-TP control (and management) planes.4.1.3. Routing
Routing support for MPLS-TP LSPs is based on GMPLS routing. GMPLS routing builds on TE routing and has been extended to support multiple switching technologies per [RFC3945] and [RFC4202] as well as multiple levels of packet switching within a single network. IS- IS extensions for GMPLS are defined in [RFC5307] and [RFC5316], which build on the TE extensions to IS-IS defined in [RFC5305]. OSPF extensions for GMPLS are defined in [RFC4203] and [RFC5392], which build on the TE extensions to OSPF defined in [RFC3630]. The listed RFCs should be viewed as a starting point rather than a comprehensive list as there are other IS-IS and OSPF extensions, as defined in IETF RFCs, that can be used within an MPLS-TP network.4.1.4. TE LSPs and Constraint-Based Path Computation
Both MPLS and GMPLS allow for traffic engineering and constraint- based path computation. MPLS path computation provides paths for MPLS-TE unidirectional P2P and P2MP LSPs. GMPLS path computation adds bidirectional LSPs, explicit recovery path computation, as well as support for the other functions discussed in this section. Both MPLS and GMPLS path computation allow for the restriction of path selection based on the use of Explicit Route Objects (EROs) and other LSP attributes; see [RFC3209] and [RFC3473]. In all cases, no
specific algorithm is standardized by the IETF. This is anticipated to continue to be the case for MPLS-TP LSPs.4.1.4.1. Relation to PCE
Path Computation Element (PCE)-based approaches, see [RFC4655], may be used for path computation of a GMPLS LSP, and consequently an MPLS-TP LSP, across domains and in a single domain. In cases where PCE is used, the PCE Communication Protocol (PCEP), see [RFC5440], will be used to communicate PCE-related requests and responses. MPLS-TP-specific extensions to PCEP are currently out of scope of the MPLS-TP project and this document.4.1.5. Signaling
GMPLS signaling is defined in [RFC3471] and [RFC3473] and is based on RSVP-TE [RFC3209]. Constraint-based Routed LDP (CR-LDP) GMPLS (see [RFC3472]) is no longer under active development within the IETF, i.e., it is deprecated (see [RFC3468]) and must not be used for MPLS nor MPLS-TP consequently. In general, all RSVP-TE extensions that apply to MPLS may also be used for GMPLS and consequently MPLS-TP. Most notably, this includes support for P2MP signaling as defined in [RFC4875]. GMPLS signaling includes a number of MPLS-TP required functions -- notably, support for out-of-band control, bidirectional LSPs, and independent control- and data-plane fault management. There are also numerous other GMPLS and MPLS extensions that can be used to provide specific functions in MPLS-TP networks. Specific references are provided below.4.1.6. Unnumbered Links
Support for unnumbered links (i.e., links that do not have IP addresses) is permitted in MPLS-TP and its usage is at the discretion of the network operator. Support for unnumbered links is included for routing using OSPF [RFC4203] and IS-IS [RFC5307], and for signaling in [RFC3477].4.1.7. Link Bundling
Link bundling provides a local construct that can be used to improve scaling of TE routing when multiple data links are shared between node pairs. Link bundling for MPLS and GMPLS networks is defined in [RFC4201]. Link bundling may be used in MPLS-TP networks, and its use is at the discretion of the network operator.
4.1.8. Hierarchical LSPs
This section reuses text from [RFC6107]. [RFC3031] describes how MPLS labels may be stacked so that LSPs may be nested with one LSP running through another. This concept of hierarchical LSPs (H-LSPs) is formalized in [RFC4206] with a set of protocol mechanisms for the establishment of a hierarchical LSP that can carry one or more other LSPs. [RFC4206] goes on to explain that a hierarchical LSP may carry other LSPs only according to their switching types. This is a function of the way labels are carried. In a packet switch capable network, the hierarchical LSP can carry other packet switch capable LSPs using the MPLS label stack. Signaling mechanisms defined in [RFC4206] allow a hierarchical LSP to be treated as a single hop in the path of another LSP. This mechanism is also sometimes known as "non-adjacent signaling", see [RFC4208]. A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link created from an LSP and advertised in the same instance of the control plane that advertises the TE links from which the LSP is constructed. The LSP itself is called an FA-LSP. FA-LSPs are analogous to MPLS-TP Sections as discussed in [RFC5960]. Thus, a hierarchical LSP may form an FA such that it is advertised as a TE link in the same instance of the routing protocol as was used to advertise the TE links that the LSP traverses. As observed in [RFC4206], the nodes at the ends of an FA would not usually have a routing adjacency. LSP hierarchy is expected to play an important role in MPLS-TP networks, particularly in the context of scaling and recovery as well as supporting SPMEs.4.1.9. LSP Recovery
GMPLS defines RSVP-TE extensions in support for end-to-end GMPLS LSPs recovery in [RFC4872] and segment recovery in [RFC4873]. GMPLS segment recovery provides a superset of the function in end-to-end recovery. End-to-end recovery can be viewed as a special case of segment recovery where there is a single recovery domain whose borders coincide with the ingress and egress of the LSP, although specific procedures are defined.
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
same control-plane signaling used to set up the LSP, as this effectively synchronizes OAM with the LSP lifetime and avoids the extra overhead and potential errors associated with separate OAM configuration mechanisms.4.2.1. Management-Plane Support
There is no MPLS-TP requirement for a standardized management interface to the MPLS-TP control plane. That said, MPLS and GMPLS support a number of standardized management functions. These include the MPLS-TE/GMPLS TE Database Management Information Base [TE-MIB]; the MPLS-TE MIB [RFC3812]; the MPLS LSR MIB [RFC3813]; the GMPLS TE MIB [RFC4802]; and the GMPLS LSR MIB [RFC4803]. These MIB modules may be used in MPLS-TP networks. A general overview of MPLS-TP related MIB modules can be found in [TP-MIB]. Network management requirements for MPLS-based transport networks are provided in [RFC5951].4.2.1.1. Recovery Triggers
The GMPLS control plane allows for management-plane recovery triggers and directly supports control-plane recovery triggers. Support for control-plane recovery triggers is defined in [RFC4872], which refers to the triggers as "Recovery Commands". These commands can be used with both end-to-end and segment recovery, but are always controlled on an end-to-end basis. The recovery triggers/commands defined in [RFC4872] are: a. Lockout of recovery LSP b. Lockout of normal traffic c. Forced switch for normal traffic d. Requested switch for normal traffic e. Requested switch for recovery LSP Note that control-plane triggers are typically invoked in response to a management-plane request at the ingress.4.2.1.2. Management-Plane / Control-Plane Ownership Transfer
In networks where both the control plane and management plane are provided, LSP provisioning can be done either by the control plane or management plane. As mentioned in the requirements section above, it must be possible to transfer, or handover, a management-plane-created LSP to the control-plane domain and vice versa. [RFC5493] defines
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] |
| 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) |
| 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] |
| 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 Table4.4. Anticipated MPLS-TP-Related Extensions and Definitions
This section identifies the extensions and other documents that have been identified as likely to be needed to support the full set of MPLS-TP control-plane requirements.4.4.1. MPLS-TE to MPLS-TP LSP Control-Plane Interworking
While no interworking function is expected in the data plane to support the interconnection of MPLS-TE and MPLS-TP networking, this is not the case for the control plane. MPLS-TE networks typically use LSP signaling based on [RFC3209], while MPLS-TP LSPs will be signaled using GMPLS RSVP-TE, i.e., [RFC3473]. [RFC5145] identifies a set of solutions that are aimed to aid in the interworking of MPLS- TE and GMPLS control planes. [RFC5145] work will serve as the foundation for a formal definition of MPLS to MPLS-TP control-plane interworking.
4.4.2. Associated Bidirectional LSPs
GMPLS signaling, [RFC3473], supports unidirectional and co-routed, bidirectional point-to-point LSPs. MPLS-TP also requires support for associated bidirectional point-to-point LSPs. Such support will require an extension or a formal definition of how the LSP end points supporting an associated bidirectional service will coordinate the two LSPs used to provide such a service. Per requirement 11, transit nodes that support an associated bidirectional service should be aware of the association of the LSPs used to support the service when both LSPs are supported on that transit node. There are several existing protocol mechanisms on which to base such support, including, but not limited to: o GMPLS calls [RFC4974]. o The ASSOCIATION object [RFC4872]. o The LSP_TUNNEL_INTERFACE_ID object [RFC6107].4.4.3. Asymmetric Bandwidth LSPs
[RFC5467] defines support for bidirectional LSPs that have different (asymmetric) bandwidth requirements for each direction. That RFC can be used to meet the related MPLS-TP technical requirement, but it is currently an Experimental RFC. To fully satisfy the MPLS-TP requirement, RFC 5467 will need to become a Standards Track RFC.4.4.4. Recovery for P2MP LSPs
The definitions of P2MP, [RFC4875], and GMPLS recovery, [RFC4872] and [RFC4873], do not explicitly cover their interactions. MPLS-TP requires a formal definition of recovery techniques for P2MP LSPs. Such a formal definition will be based on existing RFCs and may not require any new protocol mechanisms but, nonetheless, must be documented.4.4.5. Test Traffic Control and Other OAM Functions
[CCAMP-OAM-FWK] and [CCAMP-OAM-EXT] are examples of OAM-related control extensions to GMPLS. These extensions cover a portion of, but not all, OAM-related control functions that have been identified in the context of MPLS-TP. As discussed above, the MPLS-TP control plane must support the selection of which OAM function(s) (if any) to use (including support to select experimental OAM functions) and what OAM functionality to run, including Continuity Check (CC),
Connectivity Verification (CV), packet loss, delay quantification, and diagnostic testing of a service. Such support may be included in the listed documents or in other documents.4.4.6. Diffserv Object Usage in GMPLS
[RFC3270] and [RFC4124] define support for Diffserv-enabled MPLS LSPs. While [RFC4124] references GMPLS signaling, there is no explicit discussion on the use of the Diffserv-related objects in GMPLS signaling. A (possibly Informational) document on how GMPLS supports Diffserv LSPs is likely to prove useful in the context of MPLS-TP.4.4.7. Support for MPLS-TP LSP Identifiers
MPLS-TP uses two forms of LSP identifiers, see [RFC6370]. One form is based on existing GMPLS fields. The other form is based on either the globally unique Attachment Interface Identifier (AII) defined in [RFC5003] or the ITU Carrier Code (ICC) defined in ITU-T Recommendation M.1400. Neither form is currently supported in GMPLS, and such extensions will need to be documented.4.4.8. Support for MPLS-TP Maintenance Identifiers
MPLS-TP defines several forms of maintenance-entity-related identifiers. Both node-unique and global forms are defined. Extensions will be required to GMPLS to support these identifiers. These extensions may be added to existing works in progress, such as [CCAMP-OAM-FWK] and [CCAMP-OAM-EXT], or may be defined in independent documents.
(page 39 continued on part 4)