5. Applicability and Scope of Survivability in MPLS-TP
The MPLS-TP network can be viewed as two layers (the MPLS LSP layer
and the PW layer). The MPLS-TP network operates over data-link
connections and data-link networks whereby the MPLS-TP links are
provided by individual data links or by connections in a lower-layer
network. The MPLS LSP layer is a mandatory part of the MPLS-TP
network, while the PW layer is an optional addition for supporting
MPLS-TP survivability provides recovery from failure of the links and
nodes in the MPLS-TP network. The link defects and failures are
typically caused by defects or failures in the underlying data-link
connections and networks, but this section is only concerned with
recovery actions performed in the MPLS-TP network, which must recover
from the manifestation of any problem as a defect failure in the
This section lists the recovery elements (see Section 1) supported in
each of the two layers that can recover from defects or failures of
nodes or links in the MPLS-TP network.
| Recovery | MPLS LSP Layer | PW Layer |
| Element | | |
| Link | MPLS LSP recovery | The PW layer is not aware of |
| Recovery | can be used to | the underlying network. |
| | survive the failure | This function is not |
| | of an MPLS-TP link. | supported. |
| Segment/Span | An individual LSP | For an SS-PW, segment |
| Recovery | segment can be | recovery is the same as |
| | recovered to | end-to-end recovery. |
| | survive the failure | Segment recovery for an MS-PW|
| | of an MPLS-TP link. | is for future study, and |
| | | this function is now |
| | | provided using end-to-end |
| | | recovery. |
| Concatenated | A concatenated LSP | Concatenated segment |
| Segment | segment can be | recovery (in an MS-PW) is for|
| Recovery | recovered to | future study, and this |
| | survive the failure | function is now provided |
| | of an MPLS-TP link | using end-to-end recovery. |
| | or node. | |
| End-to-End | An end-to-end LSP | End-to-end PW recovery can |
| Recovery | can be recovered to | be applied to survive any |
| | survive any node or | node (including S-PE) or |
| | link failure, | link failure, except for |
| | except for the | failure of the ingress or |
| | failure of the | egress T-PE. |
| | ingress or egress | |
| | node. | |
| Service | The MPLS LSP layer | PW-layer service recovery |
| Recovery | is service- | requires surviving faults in |
| | agnostic. This | T-PEs or on Attachment |
| | function is not | Circuits (ACs). This is |
| | supported. | currently out of scope for |
| | | MPLS-TP. |
Table 1: Recovery Elements Supported
by the MPLS LSP Layer and PW Layer
Section 6 provides a description of mechanisms for MPLS-TP-LSP
survivability. Section 7 provides a brief overview of mechanisms for
6. Mechanisms for Providing Survivability for MPLS-TP LSPs
This section describes the existing mechanisms that provide LSP
protection within MPLS-TP networks and highlights areas where new
work is required.
6.1. Management Plane
As described above, a fundamental requirement of MPLS-TP is that
recovery mechanisms should be capable of functioning in the absence
of a control plane. Recovery may be triggered by MPLS-TP OAM fault
management functions or by external requests (e.g., an operator's
request for manual control of protection switching). Recovery LSPs
(and in particular Restoration LSPs) may be provisioned through the
The management plane may be used to configure the recovery domain by
setting the reference end-point points (which control the recovery
actions), the working and the recovery entities, and the recovery
type (e.g., 1:1 bidirectional linear protection, ring protection,
Additional parameters associated with the recovery process (such as
WTR and hold-off timers, revertive/non-revertive operation, etc.) may
also be configured.
In addition, the management plane may initiate manual control of the
recovery function. A priority should be set for the fault conditions
and the operator's requests.
Since provisioning the recovery domain involves the selection of a
number of options, mismatches may occur at the different reference
points. The MPLS-TP protocol to coordinate protection state, which
is specified in [MPLS-TP-LP], may be used as an in-band (i.e., data-
plane-based) control protocol to coordinate the protection states
between the end points of the recovery domain, and to check the
consistency of configured parameters (such as timers, revertive/non-
revertive behavior, etc.) with discovered inconsistencies that are
reported to the operator.
It should also be possible for the management plane to track the
recovery status by receiving reports or by issuing polls.
6.1.1. Configuration of Protection Operation
To implement the protection-switching mechanisms, the following
entities and information should be configured and provisioned:
o The end points of a recovery domain. As described above, these
end points border on the element of recovery to which recovery is
o The protection group, which, depending on the required protection
scheme, consists of a recovery entity and one or more working
entities. In 1:1 or 1+1 P2P protection, the paths of the working
entity and the recovery entities must be physically diverse in
every respect (i.e., not share any resources or physical
locations), in order to guarantee protection.
o As defined in Section 4.8, the SPME must be supported in order to
implement data-plane-based LSP segment recovery, since related
control messages (e.g., for OAM, Protection Path Coordination,
etc.) can be initiated and terminated at the edges of a path where
push and pop operations are enabled. The SPME is an end-to-end
LSP that in this context corresponds to the recovery entities
(working and protection) and makes use of the MPLS construct of
hierarchical nested LSP, as defined in [RFC3031]. OAM messages
and messages to coordinate protection state can be initiated at
the edge of the SPME and sent over G-ACH to the peer edge of the
SPME. It is necessary to configure the related SPMEs and map
between the LSP segments being protected and the SPME. Mapping
can be 1:1 or 1:N to allow scalable protection of a set of LSP
segments traversing the part of the network in which a protection
domain is defined.
Note that each of these LSPs can be initiated or terminated at
different end points in the network, but that they all traverse
the protection domain and share similar constraints (such as
requirements for QoS, terms of protection, etc.).
o The protection type that should be defined (e.g., unidirectional
1:1, bidirectional 1+1, etc.)
o Revertive/non-revertive behavior should be configured.
o Timers (such as WTR, hold-off timer, etc.) should be set.
6.1.2. External Manual Commands
The following external, manual commands may be provided for manual
control of the protection-switching operation. These commands apply
to a protection group; they are listed in descending order of
o Blocked protection action - a manual command to prevent data
traffic from switching to the recovery entity. This command
actually disables the protection group.
o Force protection action - a manual command that forces a switch of
normal data traffic to the recovery entity.
o Manual protection action - a manual command that forces a switch of
data traffic to the recovery entity only when there is no defect
in the recovery entity.
o Clear switching command - the operator may request that a previous
administrative switch command (manual or force switch) be cleared.
6.2. Fault Detection
Fault detection is a fundamental part of recovery and survivability.
In all schemes, with the exception of some types of 1+1 protection,
the actions required for the recovery of traffic delivery depend on
the discovery of some kind of fault. In 1+1 protection, the selector
(at the receiving end) may simply be configured to choose the better
signal; thus, it does not detect a fault or degradation of itself,
but simply identifies the path that is better for data delivery.
Faults may be detected in a number of ways depending on the traffic
pattern and the underlying hardware. End-to-end faults may be
reported by the application or by knowledge of the application's data
pattern, but this is an unusual approach. There are two more common
mechanisms for detecting faults in the MPLS-TP layer:
o Faults reported by the lower layers.
o Faults detected by protocols within the MPLS-TP layer.
In an IP/MPLS network, the second mechanism may utilize control-plane
protocols (such as the routing protocols) to detect a failure of
adjacency between neighboring nodes. In an MPLS-TP network, it is
possible that no control plane will be present. Even if a control
plane is present, it will be a GMPLS control plane [RFC3945], which
logically separates control channels from data channels; thus, no
conclusion about the health of a data channel can be drawn from the
failure of an associated control channel. MPLS-TP-layer faults are,
therefore, only detected through the use of OAM protocols, as
described in Section 6.4.1.
Faults may, however, be reported by a lower layer. These generally
show up as interface failures or data-link failures (sometimes known
as connectivity failures) within the MPLS-TP network, for example, an
underlying optical link may detect loss of light and report a failure
of the MPLS-TP link that uses it. Alternatively, an interface card
failure may be reported to the MPLS-TP layer.
Faults reported by lower layers are only visible in specific nodes
within the MPLS-TP network (i.e., at the adjacent end points of the
MPLS-TP link). This would only allow recovery to be performed
locally, so, to enable recovery to be performed by nodes that are not
immediately local to the fault, the fault must be reported (Sections
6.4.3 and 6.5.4).
6.3. Fault Localization
If an MPLS-TP node detects that there is a fault in an LSP (that is,
not a network fault reported from a lower layer, but a fault detected
by examining the LSP), it can immediately perform a recovery action.
However, unless the location of the fault is known, the only
practical options are:
o Perform end-to-end recovery.
o Perform some other recovery as a speculative act.
Since the speculative acts are not guaranteed to achieve the desired
results and could consume resources unnecessarily, and since end-to-
end recovery can require a lot of network resources, it is important
to be able to localize the fault.
Fault localization may be achieved by dividing the network into
protection domains. End-to-end protection is thereby operated on LSP
segments, depending on the domain in which the fault is discovered.
This necessitates monitoring of the LSP at the domain edges.
Alternatively, a proactive mechanism of fault localization through
OAM (Section 6.4.3) or through the control plane (Section 6.5.3) is
Fault localization is particularly important for restoration because
a new path must be selected that avoids the fault. It may not be
practical or desirable to select a path that avoids the entire failed
working path, and it is therefore necessary to isolate the fault's
6.4. OAM Signaling
MPLS-TP provides a comprehensive set of OAM tools for fault
management and performance monitoring at different nested levels
(end-to-end, a portion of a path (LSP or PW), and at the link level)
These tools support proactive and on-demand fault management (for
fault detection and fault localization) as well as performance
monitoring (to measure the quality of the signals and detect
To support fast recovery, it is useful to use some of the proactive
tools to detect fault conditions (e.g., link/node failure or
degradation) and to trigger the recovery action.
The MPLS-TP OAM messages run in-band with the traffic and support
unidirectional and bidirectional P2P paths as well as P2MP paths.
As described in [RFC6371], MPLS-TP OAM operates in the context of a
Maintenance Entity that borders on the OAM responsibilities and
represents the portion of a path between two points that is monitored
and maintained, and along which OAM messages are exchanged.
[RFC6371] refers also to a Maintenance Entity Group (MEG), which is a
collection of one or more Maintenance Entities (MEs) that belong to
the same transport path (e.g., P2MP transport path) and which are
maintained and monitored as a group.
An ME includes two MEPs (Maintenance Entity Group End Points) that
reside at the boundaries of an ME, and a set of zero or more MIPs
(Maintenance Entity Group Intermediate Points) that reside within the
Maintenance Entity along the path. A MEP is capable of initiating
and terminating OAM messages, and as such can only be located at the
edges of a path where push and pop operations are supported. In
order to define an ME over a portion of path, it is necessary to
The SPME is an end-to-end LSP that in this context corresponds to the
ME; it uses the MPLS construct of hierarchical nested LSPs, which is
defined in [RFC3031]. OAM messages can be initiated at the edge of
the SPME and sent over G-ACH to the peer edge of the SPME.
The related SPMEs must be configured, and mapping must be performed
between the LSP segments being monitored and the SPME. Mapping can
be 1:1 or 1:N to allow scalable operation. Note that each of these
LSPs can be initiated or terminated at different end points in the
network and can share similar constraints (such as requirements for
QoS, terms of protection, etc.).
With regard to recovery, where MPLS-TP OAM is supported, an OAM
Maintenance Entity Group is defined for each of the working and
6.4.1. Fault Detection
MPLS-TP OAM tools may be used proactively to detect the following
fault conditions between MEPs:
o Loss of continuity and misconnectivity - the proactive Continuity
Check (CC) function is used to detect loss of continuity between
two MEPs in an MEG. The proactive Connectivity Verification (CV)
allows a sink MEP to detect a misconnectivity defect (e.g.,
mismerge or misconnection) with its peer source MEP when the
received packet carries an incorrect ME identifier. For
protection switching, it is common to run a CC-V (Continuity Check
and Connectivity Verification) message every 3.33 ms. In the
absence of three consecutive CC-V messages, loss of continuity is
declared and is notified locally to the edge of the recovery
domain in order to trigger a recovery action. In some cases, when
a slower recovery time is acceptable, it is also possible to
lengthen the transmission rate.
o Signal degradation - notification from OAM performance monitoring
indicating degradation in the working entity may also be used as a
trigger for protection switching. In the event of degradation,
switching to the recovery entity is necessary only if the recovery
entity can guarantee better conditions. Degradation can be
measured by proactively activating MPLS-TP OAM packet loss
measurement or delay measurement.
o A MEP can receive an indication from its sink MEP of a Remote
Defect Indication and locally notify the end point of the recovery
domain regarding the fault condition, in order to trigger the
6.4.2. Testing for Faults
The management plane may be used to initiate the testing of links,
LSP segments, or entire LSPs.
MPLS-TP provides OAM tools that may be manually invoked on-demand for
a limited period, in order to troubleshoot links, LSP segments, or
entire LSPs (e.g., diagnostics, connectivity verification, packet
loss measurements, etc.). On-demand monitoring covers a combination
of "in-service" and "out-of-service" monitoring functions. Out-of-
service testing is supported by the OAM on-demand lock operation.
The lock operation temporarily disables the transport entity (LSP,
LSP segment, or link), preventing the transmission of all types of
traffic, with the exceptions of test traffic and OAM (dedicated to
the locked entity).
[RFC6371] describes the operations of the OAM functions that may be
initiated on-demand and provides some considerations.
MPLS-TP also supports in-service and out-of-service testing of the
recovery (protection and restoration) mechanism, the integrity of the
protection/recovery transport paths, and the coordination protocol
between the end points of the recovery domain. The testing operation
emulates a protection-switching request but does not perform the
actual switching action.
6.4.3. Fault Localization
MPLS-TP provides OAM tools to locate a fault and determine its
precise location. Fault detection often only takes place at key
points in the network (such as at LSP end points or at MEPs). This
means that a fault may be located anywhere within a segment of the
relevant LSP. Finer information granularity is needed to implement
optimal recovery actions or to diagnose the fault. On-demand tools
like trace-route, loopback, and on-demand CC-V can be used to
localize a fault.
The information may be notified locally to the end point of the
recovery domain to allow implementation of optimal recovery action.
This may be useful for the re-calculation of a recovery path.
The information should also be reported to network management for
6.4.4. Fault Reporting
The end points of a recovery domain should be able to detect fault
conditions in the recovery domain and to notify the management plane.
In addition, a node within a recovery domain that detects a fault
condition should also be able to report this to network management.
Network management should be capable of correlating the fault reports
and identifying the source of the fault.
MPLS-TP OAM tools support a function where an intermediate node along
a path is able to send an alarm report message to the MEP, indicating
the presence of a fault condition in the server layer that connects
it to its adjacent node. This capability allows a MEP to suppress
alarms that may be generated as a result of a failure condition in
the server layer.
6.4.5. Coordination of Recovery Actions
As described above, in some cases (such as in bidirectional
protection switching, etc.) it is necessary to coordinate the
protection states between the edges of the recovery domain.
[MPLS-TP-LP] defines procedures, protocol messages, and elements for
The protocol is also used to signal administrative requests (e.g.,
manual switch, etc.), but only when these are provisioned at the edge
of the recovery domain.
The protocol also enables mismatches to be detected between the
configurations at the ends of the protection domain (such as timers,
revertive/non-revertive behavior); these mismatches can subsequently
be reported to the management plane.
In the absence of suitable coordination (owing to failures in the
delivery or processing of the coordination protocol messages),
protection switching will fail. This means that the operation of the
protocol that coordinates the protection state is a fundamental part
of protection switching.
6.5. Control Plane
The GMPLS control plane has been proposed as the control plane for
MPLS-TP [RFC5317]. Since GMPLS was designed for use in transport
networks, and since it has been implemented and deployed in many
networks, it is not surprising that it contains many features that
support a high degree of survivability.
The signaling elements of the GMPLS control plane utilize extensions
to the Resource Reservation Protocol (RSVP) (as described in a series
of documents commencing with [RFC3471] and [RFC3473]), although it is
based on [RFC3209] and [RFC2205]. The architecture for GMPLS is
provided in [RFC3945], while [RFC4426] gives a functional description
of the protocol extensions needed to support GMPLS-based recovery
(i.e., protection and restoration).
A further control-plane protocol called the Link Management Protocol
(LMP) [RFC4204] is part of the GMPLS protocol family and can be used
to coordinate fault localization and reporting.
Clearly, the control-plane techniques described here only apply where
an MPLS-TP control plane is deployed and operated. All mandatory
MPLS-TP survivability features must be enabled, even in the absence
of the control plane. However, when present, the control plane may
be used to provide alternative mechanisms that may be desirable,
since they offer simple automation or a richer feature set.
6.5.1. Fault Detection
The control plane is unable to detect data-plane faults. However, it
does provide mechanisms that detect control-plane faults, and these
can be used to recognize data-plane faults when it is evident that
the control and data planes are fate-sharing. Although [RFC5654]
specifies that MPLS-TP must support an out-of-band control channel,
it does not insist that it be used exclusively. This means that
there may be deployments where an in-band (or at least an in-fiber)
control channel is used. In this scenario, failure of the control
channel can be used to infer that there is a failure of the data
channel, or, at least, it can be used to trigger an investigation of
the health of the data channel.
Both RSVP and LMP provide a control channel "keep-alive" mechanism
(called the Hello message in both cases). Failure to receive a
message in the configured/negotiated time period indicates a control-
plane failure. GMPLS routing protocols ([RFC4203] and [RFC5307])
also include keep-alive mechanisms designed to detect routing
adjacency failures. Although these keep-alive mechanisms tend to
operate at a relatively low frequency (on the order of seconds), it
is still possible that the first indication of a control-plane fault
will be received through the routing protocol.
Note, however, that care must be taken to ascertain that a specific
failure is not caused by a problem in the control-plane software or
in a processor component at the far end of a link.
Because of the various issues involved, it is not recommended that
the control plane be used as the primary mechanism for fault
detection in an MPLS-TP network.
6.5.2. Testing for Faults
The control plane may be used to initiate and coordinate the testing
of links, LSP segments, or entire LSPs. This is important in some
technologies where it is necessary to halt data transmission while
testing, but it may also be useful where testing needs to be
specifically enabled or configured.
LMP provides a control-plane mechanism to test the continuity and
connectivity (and naming) of individual links. A single management
operation is required to initiate the test at one end of the link,
while the LMP handles the coordination with the other end of the
link. The test mechanism for an MPLS packet link relies on the LMP
Test message inserted into the data stream at one end of the link and
extracted at the other end of the link. This mechanism need not
disrupt data flowing over the link.
Note that a link in the LMP may, in fact, be an LSP tunnel used to
form a link in the MPLS-TP network.
GMPLS signaling (RSVP) offers two mechanisms that may also assist
with fault testing. The first mechanism [RFC3473] defines the
Admin_Status object that allows an LSP to be set into "testing mode".
The interpretation of this mode is implementation-specific and could
be documented more precisely for MPLS-TP. The mode sets the whole
LSP into a state where it can be tested; this need not be disruptive
to data traffic.
The second mechanism provided by GMPLS to support testing is
described in [GMPLS-OAM]. This protocol extension supports the
configuration (including enabling and disabling) of OAM mechanisms
for a specific LSP.
6.5.3. Fault Localization
Fault localization is the process whereby the exact location of a
fault is determined. Fault detection often only takes place at key
points in the network (such as at LSP end points or at MEPs). This
means that a fault may be located anywhere within a segment of the
If segment or end-to-end protection is in use, this level of
information is often sufficient to repair the LSP. However, if finer
information granularity is required (either to implement optimal
recovery actions or to diagnose a fault), it is necessary to localize
the specific fault.
LMP provides a cascaded test-and-propagate mechanism that is designed
specifically for this purpose.
6.5.4. Fault Status Reporting
GMPLS signaling uses the Notify message to report fault status
[RFC3473]. The Notify message can apply to a single LSP or can carry
fault information for a set of LSPs, in order to improve the
scalability of fault notification.
Since the Notify message is targeted at a specific node, it can be
delivered rapidly without requiring hop-by-hop processing. It can be
targeted at LSP end points or at segment end points (such as MEPs).
The target points for Notify messages can be manually configured
within the network, or they may be signaled when the LSP is set up.
This enables the process to be made consistent with segment
protection as well as with the concept of Maintenance Entities.
GMPLS signaling also provides a slower, hop-by-hop mechanism for
reporting individual LSP faults on a hop-by-hop basis using PathErr
and ResvErr messages.
[RFC4783] provides a mechanism to coordinate alarms and other event
or fault information through GMPLS signaling. This mechanism is
useful for understanding the status of the resources used by an LSP
and for providing information as to why an LSP is not functioning;
however, it is not intended to replace other fault-reporting
GMPLS routing protocols [RFC4203] and [RFC5307] are used to advertise
link availability and capabilities within a GMPLS-enabled network.
Thus, the routing protocols can also provide indirect information
about network faults; that is, the protocol may stop advertising or
may withdraw the advertisement for a failed link, or it may advertise
that the link is about to be shut down gracefully [RFC5817]. This
mechanisms is, however, not normally considered to be fast enough for
use as a trigger for protection switching.
6.5.5. Coordination of Recovery Actions
Fault coordination is an important feature for certain protection
mechanisms (such as bidirectional 1:1 protection). The use of the
GMPLS Notify message for this purpose is described in [RFC4426];
however, specific message field values have not yet been defined for
Further work is needed in GMPLS for control and configuration of
reversion behavior for end-to-end and segment protection, and the
coordination of timer values.
6.5.6. Establishment of Protection and Restoration LSPs
The management plane may be used to set up protection and recovery
LSPs, but, when present, the control plane may be used.
Several protocol extensions exist that simplify this process:
o [RFC4872] provides features that support end-to-end protection
o [RFC4873] describes the establishment of a single, segment-
protected LSP. Note that end-to-end protection is a special case
of segment protection, and [RFC4872] can also be used to provide
o [RFC4874] allows an LSP to be signaled with a request that its
path exclude specified resources such as links, nodes, and shared
risk link groups (SRLGs). This allows a disjoint protection path
to be requested or a recovery path to be set up to avoid failed
o Lastly, it should be noted that [RFC5298] provides an overview of
the GMPLS techniques available to achieve protection in multi-
7. Pseudowire Recovery Considerations
Pseudowires provide end-to-end connectivity over the MPLS-TP network
and may comprise a single pseudowire segment, or multiple segments
"stitched" together to provide end-to-end connectivity.
The pseudowire may, itself, require protection, in order to meet the
service-level guarantees of its SLA. This protection could be
provided by the MPLS-TP LSPs that support the pseudowire, or could be
a feature of the pseudowire layer itself.
As indicated above, the functional architecture described in this
document applies to both LSPs and pseudowires. However, the recovery
mechanisms for pseudowires are for further study and will be defined
in a separate document by the PWE3 working group.
7.1. Utilization of Underlying MPLS-TP Recovery
MPLS-TP PWs are carried across the network inside MPLS-TP LSPs.
Therefore, an obvious way to provide protection for a PW is to
protect the LSP that carries it. Such protection can take any of the
forms described in this document. The choice of recovery scheme will
depend on the required speed of recovery and the traffic loss that is
acceptable for the SLA that the PW is providing.
If the PW is a Multi-Segment PW, then LSP recovery can only protect
the PW in individual segments. This means that a single LSP recovery
action cannot protect against a failure of a PW switching point (an
S-PE), nor can it protect more than one segment at a time, since the
LSP tunnel is terminated at each S-PE. In this respect, LSP
protection of a PW is very similar to link-level protection offered
to the MPLS-TP LSP layer by an underlying network layer (see Section
7.2. Recovery in the Pseudowire Layer
Recovery in the PW layer can be provided by simply running separate
PWs end-to-end. Other recovery mechanisms in the PW layer, such as
segment or concatenated segment recovery, or service-level recovery
involving survivability of T-PE or AC faults will be described in a
As with any recovery mechanism, it is important to coordinate between
layers. This coordination is necessary to ensure that actions
associated with recovery mechanisms are only performed in one layer
at a time (that is, the recovery of an underlying LSP needs to be
coordinated with the recovery of the PW itself). It also makes sure
that the working and protection PWs do not both use the same MPLS
resources within the network (for example, by running over the same
LSP tunnel; see also Section 4.9).
8. Manageability Considerations
Manageability of MPLS-TP networks and their functions is discussed in
[RFC5950]. OAM features are discussed in [RFC6371].
Survivability has some key interactions with management, as described
in this document. In particular:
o Recovery domains may be configured in a way that prevents one-to-
one correspondence between the MPLS-TP network and the recovery
o Survivability policies may be configured per network, per recovery
domain, or per LSP.
o Configuration of OAM may involve the selection of MEPs; enabling
OAM on network segments, spans, and links; and the operation of
OAM on LSPs, concatenated LSP segments, and LSP segments.
o Manual commands may be used to control recovery functions,
including forcing recovery and locking recovery actions.
See also the considerations regarding security for management and OAM
in Section 9 of this document.
9. Security Considerations
This framework does not introduce any new security considerations;
general issues relating to MPLS security can be found in [RFC5920].
However, several points about MPLS-TP survivability should be noted
o If an attacker is able to force a protection switch-over, this may
result in a small perturbation to user traffic and could result in
extra traffic being preempted or displaced from the protection
resources. In the case of 1:n protection or shared mesh
protection, this may result in other traffic becoming unprotected.
Therefore, it is important that OAM protocols for detecting or
notifying faults use adequate security to prevent them from being
used (through the insertion of bogus messages or through the
capture of legitimate messages) to falsely trigger a recovery
o If manual commands are modified, captured, or simulated (including
replay), it might be possible for an attacker to perform forced
recovery actions or to impose lock-out. These actions could
impact the capability to provide the recovery function and could
also affect the normal operation of the network for other traffic.
Therefore, management protocols used to perform manual commands
must allow the operator to use appropriate security mechanisms.
This includes verification that the user who performs the commands
has appropriate authorization.
o If the control plane is used to configure or operate recovery
mechanisms, the control-plane protocols must also be capable of
providing adequate security.
Thanks to the following people for useful comments and discussions:
Italo Busi, David McWalter, Lou Berger, Yaacov Weingarten, Stewart
Bryant, Dan Frost, Lievren Levrau, Xuehui Dai, Liu Guoman, Xiao Min,
Daniele Ceccarelli, Scott Bradner, Francesco Fondelli, Curtis
Villamizar, Maarten Vissers, and Greg Mirsky.
The Editors would like to thank the participants in ITU-T Study Group
15 for their detailed review.
Some figures and text on shared mesh protection were borrowed from
[MPLS-TP-MESH] with thanks to Tae-sik Cheung and Jeong-dong Ryoo.
[RFC4427] Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for
Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4427, March 2006.
[RFC4428] Papadimitriou, D., Ed., and E. Mannie, Ed., "Analysis
of Generalized Multi-Protocol Label Switching
(GMPLS)-based Recovery Mechanisms (including
Protection and Restoration)", RFC 4428, March 2006.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A.
Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS
Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 5307, October 2008.
[RFC5317] Bryant, S., Ed., and L. Andersson, Ed., "Joint Working
Team (JWT) Report on MPLS Architectural Considerations
for a Transport Profile", RFC 5317, February 2009.
[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant,
Ed., "MPLS Generic Associated Channel", RFC 5586, June
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M.,
Ed., Sprecher, N., and S. Ueno, "Requirements of an
MPLS Transport Profile", RFC 5654, September 2009.
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed.,
Levrau, L., and L. Berger, "A Framework for MPLS in
Transport Networks", RFC 5921, July 2010.
[RFC5950] Mansfield, S., Ed., Gray, E., Ed., and K. Lam, Ed.,
"Network Management Framework for MPLS-based Transport
Networks", RFC 5950, September 2010.
[RFC6371] Buci, I., Ed. and B. Niven-Jenkins, Ed., "A Framework
for MPLS in Transport Networks", RFC 6371, September
11.2. Informative References
[GMPLS-OAM] Takacs, A., Fedyk, D., and J. He, "GMPLS RSVP-TE
extensions for OAM Configuration", Work in Progress,
[MPLS-TP-LP] Weingarten, Y., Osborne, E., Sprecher, N., Fulignoli,
A., Ed., and Y. Weingarten, Ed., "MPLS-TP Linear
Protection", Work in Progress, August 2011.
[MPLS-TP-MESH] Cheung, T. and J. Ryoo, "MPLS-TP Shared Mesh
Protection", Work in Progress, April 2011.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture", RFC
3031, January 2001.
[RFC3386] Lai, W., Ed., and D. McDysan, Ed., "Network Hierarchy
and Multilayer Survivability", RFC 3386, November
[RFC3469] Sharma, V., Ed., and F. Hellstrand, Ed., "Framework
for Multi-Protocol Label Switching (MPLS)-based
Recovery", RFC 3469, February 2003.
[RFC4397] Bryskin, I. and A. Farrel, "A Lexicography for the
Interpretation of Generalized Multiprotocol Label
Switching (GMPLS) Terminology within the Context of
the ITU-T's Automatically Switched Optical Network
(ASON) Architecture", RFC 4397, February 2006.
[RFC4426] Lang, J., Ed., Rajagopalan, B., Ed., and D.
Papadimitriou, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Recovery Functional Specification",
RFC 4426, March 2006.
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A
Framework for Inter-Domain Multiprotocol Label
Switching Traffic Engineering", RFC 4726, November
[RFC4783] Berger, L., Ed., "GMPLS - Communication of Alarm
Information", RFC 4783, December 2006.
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, May 2007.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude
Routes - Extension to Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE)", RFC 4874, April 2007.
[RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL.,
Vigoureux, M., and D. Brungard, "Requirements for
GMPLS-Based Multi-Region and Multi-Layer Networks
(MRN/MLN)", RFC 5212, July 2008.
[RFC5298] Takeda, T., Ed., Farrel, A., Ed., Ikejiri, Y., and JP.
Vasseur, "Analysis of Inter-Domain Label Switched Path
(LSP) Recovery", RFC 5298, August 2008.
[RFC5817] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton,
"Graceful Shutdown in MPLS and Generalized MPLS
Traffic Engineering Networks", RFC 5817, April 2010.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC6373] Andersson, L., Ed., Berger, L., Ed., Fang, L., Ed.,
and Bitar, N., Ed, and E. Gray, Ed., "MPLS-TP Control
Plane Framework", RFC 6373, September 2011.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R.,
Romascanu, D., and S. Mansfield, "Guidelines for the
Use of the "OAM" Acronym in the IETF", BCP 161, RFC
6291, June 2011.
[ROSETTA] Van Helvoort, H., Ed., Andersson, L., Ed., and N.
Sprecher, Ed., "A Thesaurus for the Terminology used
in Multiprotocol Label Switching Transport Profile
(MPLS-TP) drafts/RFCs and ITU-T's Transport Network
Recommendations", Work in Progress, June 2011.
Nurit Sprecher (editor)
Nokia Siemens Networks
3 Hanagar St.
Neve Ne'eman B Hod
Hasharon, 45241 Israel
Adrian Farrel (editor)