Request for Comments: 4426 B. Rajagopalan, Ed.
Category: Standards Track D. Papadimitriou, Ed.
March 2006
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery Functional Specification
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document presents a functional description of the protocol
extensions needed to support Generalized Multi-Protocol Label
Switching (GMPLS)-based recovery (i.e., protection and restoration).
Protocol specific formats and mechanisms will be described in
companion documents.
Table of Contents
1. Introduction ................................................. 2
1.1. Conventions Used in This Document ...................... 3
2. Span Protection .............................................. 3
2.1. Unidirectional 1+1 Dedicated Protection ................ 4
2.2. Bi-directional 1+1 Dedicated Protection ................ 5
2.3. Dedicated 1:1 Protection with Extra Traffic ............ 6
2.4. Shared M:N Protection .................................. 8
2.5. Messages ............................................... 10
2.5.1. Failure Indication Message ..................... 10
2.5.2. Switchover Request Message ..................... 11
2.5.3. Switchover Response Message .................... 11
2.6. Preventing Unintended Connections ...................... 12
3. End-to-End (Path) Protection and Restoration ................. 12
3.1. Unidirectional 1+1 Protection .......................... 12
3.2. Bi-directional 1+1 Protection .......................... 12
3.2.1. Identifiers .................................... 13
3.2.2. Nodal Information .............................. 14
3.2.3. End-to-End Failure Indication Message .......... 14
3.2.4. End-to-End Failure Acknowledgement Message ..... 15
3.2.5. End-to-End Switchover Request Message .......... 15
3.2.6. End-to-End Switchover Response Message ......... 15
3.3. Shared Mesh Restoration ................................ 15
3.3.1. End-to-End Failure Indication and
Acknowledgement Message ........................ 16
3.3.2. End-to-End Switchover Request Message .......... 16
3.3.3. End-to-End Switchover Response Message ......... 17
4. Reversion and Other Administrative Procedures ................ 17
5. Discussion ................................................... 18
5.1. LSP Priorities During Protection ....................... 18
6. Security Considerations ...................................... 19
7. Contributors ................................................. 20
8. References ................................................... 21
8.1. Normative References ................................... 21
8.2. Informative References ................................. 22
1. Introduction
A requirement for the development of a common control plane for both
optical and electronic switching equipment is that there must be
signaling, routing, and link management mechanisms that support data
plane fault recovery. In this document, the term "recovery" is
generically used to denote both protection and restoration; the
specific terms "protection" and "restoration" are used only when
differentiation is required. The subtle distinction between
protection and restoration is made based on the resource allocation
done during the recovery period (see [RFC4427]).
A label-switched path (LSP) may be subject to local (span), segment,
and/or end-to-end recovery. Local span protection refers to the
protection of the link (and hence all the LSPs marked as required for
span protection and routed over the link) between two neighboring
switches. Segment protection refers to the recovery of an LSP
segment (i.e., an SNC in the ITU-T terminology) between two nodes,
i.e., the boundary nodes of the segment. End-to-end protection
refers to the protection of an entire LSP from the ingress to the
egress port. The end-to-end recovery models discussed in this
document apply to segment protection where the source and destination
refer to the protected segment rather than the entire LSP. Multiple
recovery levels may be used concurrently by a single LSP for added
resiliency; however, the interaction between levels affects any one
direction of the LSP results in both directions of the LSP being
switched to a new span, segment, or end-to-end path.
Unless otherwise stated, all references to "link" in this document
indicate a bi-directional link (which may be realized as a pair of
unidirectional links).
Consider the control plane message flow during the establishment of
an LSP. This message flow proceeds from an initiating (or source)
node to a terminating (or destination) node, via a sequence of
intermediate nodes. A node along the LSP is said to be "upstream"
from another node if the former occurs first in the sequence. The
latter node is said to be "downstream" from the former node. That
is, an "upstream" node is closer to the initiating node than a node
further "downstream". Unless otherwise stated, all references to
"upstream" and "downstream" are in terms of the control plane message
flow.
The flow of the data traffic is defined from ingress (source node) to
egress (destination node). Note that for bi-directional LSPs, there
are two different data plane flows, one for each direction of the
LSP. This document presents a protocol functional description to
support Generalized Multi-Protocol Label Switching (GMPLS)-based
recovery (i.e., protection and restoration). Protocol-specific
formats, encoding, and mechanisms will be described in companion
documents.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
In addition, the reader is assumed to be familiar with the
terminology used in [RFC3945], [RFC3471] and referenced as well as
[RFC4427].
2. Span Protection
Consider a (working) link i between two nodes A and B. There are two
fundamental models for span protection. The first is referred to as
1+1 protection. Under this model, a dedicated link j is pre-assigned
to protect link i. LSP traffic is permanently bridged onto both
links i and j at the ingress node, and the egress node selects the
signal (i.e., normal traffic) from i or j, based on a selection
function (e.g., signal quality). Under unidirectional 1+1 span
protection (Section 2.1), each node A and B acts autonomously to
select the signal from the working link i or the protection link j.
Under bi-directional 1+1 span protection (Section 2.2) the two nodes
A and B coordinate the selection function such that they select the
signal from the same link, i or j.
Under the second model, a set of N working links are protected by a
set of M protection links, usually with M =< N. A failure in any of
the N working links results in traffic being switched to one of the M
protection links that is available. This is typically a three-step
process: first the data plane failure is detected at the egress node
and reported (notification), then a protection link is selected, and
finally, the LSPs on the failed link are moved to the protection
link. If reversion is supported, a fourth step is included, i.e.,
return of the traffic to the working link (when the working link has
recovered from the failure). In Section 2.3, 1:1 span protection is
described. In Section 2.4, M:N span protection is described, where
M =< N.
2.1. Unidirectional 1+1 Dedicated Protection
Suppose a bi-directional LSP is routed over link i between two nodes
A and B. Under unidirectional 1+1 protection, a dedicated link j is
pre-assigned to protect the working link i. LSP traffic is
permanently bridged on both links at the ingress node, and the egress
node selects the normal traffic from one of the links, i or j. If a
node (A or B) detects a failure of a span, it autonomously invokes a
process to receive the traffic from the protection span. Thus, it is
possible that node A selects the signal from link i in the B to A
direction of the LSP, and node B selects the signal from link j in
the A to B direction.
The following functionality is required for 1+1 unidirectional span
protection:
o Routing: A single TE link encompassing both working and
protection links SHOULD be announced with a Link Protection
Type "Dedicated 1+1", along with the bandwidth parameters for
the working link. As the resources are consumed/released, the
bandwidth parameters of the TE link are adjusted accordingly.
Encoding of the Link Protection Type and bandwidth parameters
in IS-IS is specified in [RFC4205]. Encoding of this
information in OSPF is specified in [RFC4203].
o Signaling: The Link Protection object/TLV SHOULD be used to
request "Dedicated 1+1" link protection for that LSP. This
object/TLV is defined in [RFC3471]. If the Link Protection
object/TLV is not used, link selection is a matter of local
policy. No additional signaling is required when a fail-over
occurs.
o Link management: Both nodes MUST have a consistent view of the
link protection association for the spans. This can be done
using the Link Management Protocol (LMP) [RFC4204], or if LMP
is not used, this MUST be configured manually.
2.2. Bi-directional 1+1 Dedicated Protection
Suppose a bi-directional LSP is routed over link i between two nodes
A and B. Under bi-directional 1+1 protection, a dedicated link j is
pre-assigned to protect the working link i. LSP traffic is
permanently duplicated on both links, and under normal conditions,
the traffic from link i is received by nodes A and B (in the
appropriate directions). A failure affecting link i results in both
A and B switching to the traffic on link j in the respective
directions. Note that some form of signaling is required to ensure
that both A and B start receiving traffic from the protection link.
The basic steps in 1+1 bi-directional span protection are as follows:
1. If a node (A or B) detects the failure of the working link (or
a degradation of signal quality over the working link), it
SHOULD begin receiving on the protection link and send a
Switchover Request message reliably to the other node (B or A,
respectively). This message SHOULD indicate the identity of
the failed working link and provide other relevant information.
2. Upon receipt of the Switchover Request message, a node MUST
begin receiving from the protection link and send a Switchover
Response message to the other node (A or B, respectively).
Because both the working/protect spans are exposed to routing
and signaling as a single link, the switchover SHOULD be
transparent to routing and signaling.
The following functionality is required for 1+1 bi-directional span
protection:
o The routing procedures are the same as in 1+1 unidirectional.
o The signaling procedures are the same as in 1+1 unidirectional.
o In addition to the procedures described in 1+1
(unidirectional), a Switchover Request message MUST be used to
signal the Switchover Request. This can be done using LMP
[RFC4204]. Note that GMPLS-based mechanisms MAY not be
necessary when the underlying span (transport) technology
provides such a mechanism.
2.3. Dedicated 1:1 Protection with Extra Traffic
Consider two adjacent nodes, A and B. Under 1:1 protection, a
dedicated link j between A and B is pre-assigned to protect working
link i. Link j may be carrying (pre-emptable) Extra Traffic. A
failure affecting link i results in the corresponding LSP(s) being
restored to link j. Extra Traffic being routed over link j may need
to be pre-empted to accommodate the LSPs that have to be restored.
Once a fault is isolated/localized, the affected LSP(s) must be moved
to the protection link. The process of moving an LSP from a failed
(working) link to a protection link must be initiated by one of the
nodes, A or B. This node is referred to as the "master". The other
node is called the "slave". The determination of the master and the
slave may be based on configured information or protocol specific
requirements.
The basic steps in dedicated 1:1 span protection (ignoring reversion)
are as follows:
1. If the master detects/localizes a link failure event, it
invokes a process to allocate the protection link to the
affected LSP(s).
2. If the slave detects a link failure event, it informs the
master of the failure using a failure indication message. The
master then invokes the same procedure as (1) to move the LSPs
to the protection link. If the protection link is carrying
Extra Traffic, the slave stops using the span for the Extra
Traffic.
3. Once the span protection procedure is invoked in the master, it
requests the slave to switch the affected LSP(s) to the
protection link. Prior to this, if the protection link is
carrying Extra Traffic, the master stops using the span for
this traffic (i.e., the traffic is dropped by the master and
not forwarded into or out of the protection link).
4. The slave sends an acknowledgement to the master. Prior to
this, the slave stops using the link for Extra Traffic (i.e.,
the traffic is dropped by the slave and not forwarded into or
out of the protection link). It then starts sending the normal
traffic on the selected protection link.
5. When the master receives the acknowledgement, it starts sending
and receiving the normal traffic over the new link. The
switchover of the LSPs is thus completed.
Note: Although this mechanism implies more traffic dropped than
necessary, it is preferred over possible misconnections during the
recovery process.
From the description above, it is clear that 1:1 span protection may
require up to three signaling messages for each failed span: a
failure indication message, an LSP Switchover Request message, and an
LSP Switchover Response message. Furthermore, it may be possible to
switch multiple LSPs from the working span to the protection span
simultaneously.
The following functionality is required for dedicated 1:1 span
protection:
o Pre-emption MUST be supported to accommodate Extra Traffic.
o Routing: A single TE link encompassing both working and
protection links is announced with a Link Protection Type
"Dedicated 1:1". If Extra Traffic is supported over the
protection link, then the bandwidth parameters for the
protection link MUST also be announced. The differentiation
between bandwidth for working and protect links is made using
priority mechanisms. In other words, the network MUST be
configured such that bandwidth at priority X or lower is
considered Extra Traffic.
If there is a failure on the working link, then the normal
traffic is switched to the protection link, pre-empting Extra
Traffic if necessary. The bandwidth for the protection link
MUST be adjusted accordingly.
o Signaling: To establish an LSP on the working link, the Link
Protection object/TLV indicating "Dedicated 1:1" SHOULD be
included in the signaling request message for that LSP. To
establish an LSP on the protection link, the appropriate
priority (indicating Extra Traffic) SHOULD be used for that
LSP. These objects/TLVs are defined in [RFC3471]. If the Link
Protection object/TLV is not used, link selection is a matter
of local policy.
o Link management: Both nodes MUST have a consistent view of the
link protection association for the spans. This can be done
using LMP [RFC4204] or via manual configuration.
o When a link failure is detected at the slave, a failure
indication message MUST be sent to the master informing the
node of the link failure.
2.4. Shared M:N Protection
Shared M:N protection is described with respect to two neighboring
nodes, A and B. The scenario considered is as follows:
o At any point in time, there are two sets of links between A and
B, i.e., a working set of N (bi-directional) links carrying
traffic subject to protection and a protection set of M (bi-
directional) links. A protection link may be carrying Extra
Traffic. There is no a priori relationship between the two
sets of links, but the value of M and N MAY be pre-configured.
The specific links in the protection set MAY be pre-configured
to be physically diverse to avoid the possibility of failure
events affecting a large proportion of protection links (along
with working links).
o When a link in the working set is affected by a failure, the
normal traffic is diverted to a link in the protection set, if
such a link is available. Note that such a link might be
carrying more than one LSP, e.g., an OC-192 link carrying four
STS-48 LSPs.
o More than one link in the working set may be affected by the
same failure event. In this case, there may not be an adequate
number of protection links to accommodate all of the affected
traffic carried by failed working links. The set of affected
working links that are actually restored over available
protection links is then subject to policies (e.g., based on
relative priority of working traffic). These policies are not
specified in this document.
o When normal traffic must be diverted from a failed link in the
working set to a protection link, the decision as to which
protection link is chosen is always made by one of the nodes, A
or B. This node is considered the "master" and it is required
to both apply any policies and select specific protection links
to divert working traffic. The other node is considered the
"slave". The determination of the master and the slave MAY be
based on configured information, protocol-specific
requirements, or as a result of running a neighbor discovery
procedure.
o Failure events are detected by transport layer mechanisms, if
available (e.g., SONET Alarm Indication Signal (AIS)/Remote
Defect Indication (RDI)). Since the bi-directional links are
formed by a pair of unidirectional links, a failure in the link
from A to B is typically detected by B, and a failure in the
opposite direction is detected by A. It is possible for a
failure to simultaneously affect both directions of the bi-
directional link. In this case, A and B will concurrently
detect failures, in the B-to-A direction and in the A-to-B
direction, respectively.
The basic steps in M:N protection (ignoring reversion) are as
follows:
1. If the master detects a failure of a working link, it
autonomously invokes a process to allocate a protection link to
the affected traffic.
2. If the slave detects a failure of a working link, it MUST
inform the master of the failure using a failure indication
message. The master then invokes the same procedure as above
to allocate a protection link. (It is possible that the master
has itself detected the same failure, for example, a failure
simultaneously affecting both directions of a link.)
3. Once the master has determined the identity of the protection
link, it indicates this to the slave and requests the
switchover of the traffic (using a "Switchover Request"
message). Prior to this, if the protection link is carrying
Extra Traffic, the master stops using the link for this traffic
(i.e., the traffic is dropped by the master and not forwarded
into or out of the protection link).
4. The slave sends a "Switchover Response" message back to the
master. Prior to this, if the selected protection link is
carrying traffic that could be pre-empted, the slave stops
using the link for this traffic (i.e., the traffic is dropped
by the slave and not forwarded into or out of the protection
link). It then starts sending the normal traffic on the
selected protection link.
5. When the master receives the Switchover Response, it starts
sending and receiving the traffic that was previously carried
on the now-failed link over the new link.
Note: Although this mechanism implies more traffic dropped than
necessary, it is preferred over possible misconnections during the
recovery process.
From the description above, it is clear that M:N span restoration
(involving LSP local recovery) MAY require up to three messages for
each working link being switched: a failure indication message, a
Switchover Request message, and a Switchover Response message.
The following functionality is required for M:N span restoration:
o Pre-emption MUST be supported to accommodate Extra Traffic.
o Routing: A single TE link encompassing both sets of working and
protect links should be announced with a Link Protection Type