RFC 6373
MPLS Transport Profile (MPLS-TP) Control Plane Framework
Pages: 57
Informational
Informational
Part 2 of 4 – Pages 9 to 27
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).
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).
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).
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).
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).
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.
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).
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).
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).
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).
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).
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).
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).
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).
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.
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).
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].
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
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)