Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification
draft-ietf-ccamp-gmpls-recovery-functional-04
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4426.
|
|
|---|---|---|---|
| Authors | Dimitri Papadimitriou , Dr. Bala Rajagopalan , Jonathan Lang | ||
| Last updated | 2013-03-02 (Latest revision 2005-03-30) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 4426 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Alex D. Zinin | ||
| Send notices to | kireeti@juniper.net, adrian@olddog.co.uk |
draft-ietf-ccamp-gmpls-recovery-functional-04
Network Working Group Jonathan P. Lang, Ed.
Internet Draft Bala Rajagopalan, Ed.
Category: Standards Track Dimitri Papadimitriou, Ed.
Expiration Date: October 2005
April 2005
Generalized Multi-Protocol Label Switching (GMPLS) Recovery
Functional Specification
draft-ietf-ccamp-gmpls-recovery-functional-04.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
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.
Lang, J., Rajagopalan, B., et al - Standards Track 1
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
Table of Content
Status of this Memo .............................................. 1
Abstract ......................................................... 1
Table of Content ................................................. 2
Contributors ..................................................... 2
1. Conventions ................................................... 3
2. Introduction .................................................. 3
3. Span Protection ............................................... 4
3.1 Unidirectional 1+1 dedicated protection ...................... 5
3.2 Bi-directional 1+1 dedicated protection ...................... 6
3.3 Dedicated 1:1 protection with Extra Traffic .................. 6
3.4 Shared M:N protection ........................................ 8
3.5 Messages .................................................... 10
3.5.1 Failure Indication Message ................................ 11
3.5.2 Switchover Request Message ................................ 11
3.5.3 Switchover Response Message ............................... 12
3.6 Preventing Unintended Connections ........................... 12
4. End-to-End (Path) Protection and Restoration ................. 12
4.1 Unidirectional 1+1 Protection ............................... 12
4.2 Bi-directional 1+1 Protection ............................... 12
4.2.1 Identifiers ............................................... 13
4.2.2 Nodal Information ......................................... 13
4.2.3 End-to-End Failure Indication Message ..................... 14
4.2.4 End-to-End Failure Acknowledgment Message ................. 14
4.2.5 End-to-End Switchover Request Message ..................... 15
4.2.6 End-to-End Switchover Response Message .................... 15
4.3 Shared Mesh Restoration ..................................... 15
4.3.1 End-to-End Failure Indication and Acknowledgment .......... 16
4.3.2 End-to-End Switchover Request Message ..................... 16
4.3.3 End-to-End Switchover Response Message .................... 16
5. Reversion and other Administrative Procedures ................ 16
6. Discussion ................................................... 17
6.1 LSP Priorities During Protection ............................ 17
7. Security Considerations ...................................... 18
8. IANA Considerations .......................................... 19
9. Editor's Addresses ........................................... 19
10. References .................................................. 19
10.1 Normative References ....................................... 19
10.2 Informative References ..................................... 20
Intellectual Property Statement ................................. 21
Disclaimer of Validity .......................................... 21
Copyright Statement ............................................. 21
Contributors
This document was the product of many individuals working together
in the CCAMP WG Protection and Restoration design team. The
following are the authors that contributed to this document:
Deborah Brungard (AT&T)
200 S. Laurel Ave.
Middletown, NJ 07748, USA
EMail: dbrungard@att.com
Lang, J., Rajagopalan, B., et al - Standards Track 2
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
Sudheer Dharanikota
EMail: sudheer@ieee.org
Jonathan P. Lang (Sonos)
506 Chapala Street
Santa Barbara, CA 93101, USA
EMail: jplang@ieee.org
Guangzhi Li (AT&T)
180 Park Avenue,
Florham Park, NJ 07932, USA
E-mail: gli@research.att.com
Eric Mannie
EMail: eric_mannie@hotmail.com
Dimitri Papadimitriou (Alcatel)
Francis Wellesplein, 1
B-2018 Antwerpen, Belgium
EMail: dimitri.papadimitriou@alcatel.be
Bala Rajagopalan (Intel Broadband Wireless Division)
2111 NE 25th Ave.
Hillsboro, OR 97124, USA
EMail: bala.rajagopalan@intel.com
Yakov Rekhter (Juniper)
1194 N. Mathilda Avenue
Sunnyvale, CA 94089, USA
EMail: yakov@juniper.net
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 [GMPLS-ARCH], [RFC3471] and referenced as well
as [TERM].
2. 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 only used when
differentiation is required. The subtle distinction between
protection and restoration is made based on the resource allocation
done during the recovery period (see [TERM]).
Lang, J., Rajagopalan, B., et al - Standards Track 3
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
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
becomes affecting 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.
3. 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 3.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 3.2) the two
Lang, J., Rajagopalan, B., et al - Standards Track 4
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
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 3.3, 1:1 span protection is
described. In Section 3.4, M:N span protection is described, where M
=< N.
3.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 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 [GMPLS-ISIS].
Encoding of this information in OSPF is specified in [GMPLS-
OSPF].
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) [LMP], or if
LMP is not used, this MUST be configured manually.
Lang, J., Rajagopalan, B., et al - Standards Track 5
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
3.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 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 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). Since 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
[LMP]. Note that GMPLS-based mechanisms MAY not be necessary
when the underlying span (transport) technology provides
such a mechanism.
3.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 (preemptable) 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 preempted to accommodate the LSPs that have to be restored.
Lang, J., Rajagopalan, B., et al - Standards Track 6
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
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: though 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 Link Protection Type
"Dedicated 1:1". If Extra Traffic is supported over the
Lang, J., Rajagopalan, B., et al - Standards Track 7
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
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, preempting 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 [LMP] 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.
3.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 that failure events affect 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
Lang, J., Rajagopalan, B., et al - Standards Track 8
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
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 themselves 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 that a failure simultaneously
affects 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 preempted, the slave stops
using the link for this traffic (i.e., the traffic is
Lang, J., Rajagopalan, B., et al - Standards Track 9
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
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: though 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 Link Protection
Type "Shared M:N". If Extra Traffic is supported over set of
the protection links, then the bandwidth parameters for the
set of protection links MUST also be announced. The
differentiation between bandwidth for working and protect
links is made using priority mechanisms.
If there is a failure on a working link, then the affected
LSP(s) MUST be switched to a protection link, preempting
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 "Shared M:N" 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.
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 For link management, both nodes MUST have a consistent view
of the link protection association for the links. This can
be done using LMP [LMP] or via manual configuration.
3.5 Messages
The following messages are used in local span protection procedures.
These messages SHOULD be delivered reliably. Therefore, the protocol
mechanisms used to deliver these messages SHOULD provide sequencing,
Lang, J., Rajagopalan, B., et al - Standards Track 10
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
acknowledgment and retransmission. The protocol SHOULD also handle
situations where the message(s) can not be delivered.
The messages described in the following subsections are abstract,
their format and encoding will be described in separate documents.
3.5.1 Failure Indication Message
This message is sent from the slave to the master to indicate the
identities of one or more failed working links. This message MAY not
be necessary when the transport plane technology itself provides for
such a notification.
The number of links included in the message would depend on the
number of failures detected within a window of time by the sending
node. A node MAY choose to send separate failure indication messages
in the interest of completing the recovery for a given link within
an implementation-dependent time constraint.
3.5.2 Switchover Request Message
Under bi-directional 1+1 span protection, this message is used to
coordinate the selecting function at both nodes. This message is
originated at the node that detected the failure.
Under dedicated 1:1 and shared M:N span protection, this message is
used as an LSP switchover request. This message is sent from the
master node to the slave node (reliably) to indicate that the LSP(s)
on the (failed) working link can be switched to an available
protection link. If so, the ID of the protection link as well as the
LSP labels (if necessary) MUST be indicated. These identifiers used
MUST be consistent with those used in GMPLS signaling.
A working link may carry multiple LSPs. Since the normal traffic
carried over the working link is switched to the protection link, it
MAY be possible for the LSPs on the working link to be mapped to the
protection link without re-signaling each individual LSP. For
example, if link bundling [BUNDLE] is used where the working and
protect links are mapped to component links, and the labels are the
same on the working and protection links, it MAY be possible to
change the component links without needing to re-signal each
individual LSP. Optionally, the labels MAY need to be explicitly
coordinated between the two nodes. In this case, the switchover
request message SHOULD carry the new label mappings.
The master may not be able to find protection links to accommodate
all failed working links. Thus, if this message is generated in
response to a Failure Indication message from the slave then the set
of failed links in the message MAY be a sub-set of the links
received in the Failure Indication message. Depending on time
constraints, the master may switch the normal traffic from the set
of failed links in smaller batches. Thus, a single failure
indication message MAY result in the master sending more than one
Switchover Request message to the same slave node.
Lang, J., Rajagopalan, B., et al - Standards Track 11
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
3.5.3 Switchover Response Message
This message is sent from the slave to the master (reliably) to
indicate the completion (or failure) of switchover at the slave. In
this message, the slave MAY indicate that it cannot switch over to
the corresponding free link for some reason. The master and slave in
this case notify the user (operator) of the failed switchover. A
notification of the failure MAY also be used as a trigger in an end-
to-end recovery.
3.6 Preventing Unintended Connections
An unintended connection occurs when traffic from the wrong source
is delivered to a receiver. This MUST be prevented during protection
switching. This is primarily a concern when the protection link is
being used to carry Extra Traffic. In this case, it MUST be ensured
that the LSP traffic being switched from the (failed) working link
to the protection link is not delivered to the receiver of the
preempted traffic. Thus, in the message flow described above, the
master node MUST disconnect (any) preempted traffic on the selected
protection link before sending the Switchover Request. The slave
node MUST also disconnect preempted traffic before sending the
Switchover Response. In addition, the master node SHOULD start
receiving traffic for the protected LSP from the protection link.
Finally, the master node SHOULD start sending protected traffic on
the protection link upon receipt of the Switchover Response.
4. End-to-End (Path) Protection and Restoration
End-to-end path protection and restoration refer to the recovery of
an entire LSP from the initiator to the terminator. Suppose the
primary path of an LSP is routed from the initiator (Node A) to the
terminator (Node B) through a set of intermediate nodes.
The following subsections describe three previously proposed end-to-
end protection schemes and the functional steps needed to implement
them.
4.1 Unidirectional 1+1 Protection
A dedicated, resource-disjoint alternate path is pre-established to
protect the LSP. Traffic is simultaneously sent on both paths and
received from one of the functional paths by the end nodes A and B.
There is no explicit signaling involved with this mode of
protection.
4.2 Bi-directional 1+1 Protection
A dedicated, resource-disjoint alternate path is pre-established to
protect the LSP. Traffic is simultaneously sent on both paths; under
normal conditions, the traffic from the working path is received by
nodes A and B (in the appropriate directions). A failure affecting
Lang, J., Rajagopalan, B., et al - Standards Track 12
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
the working path results in both A and B switching to the traffic on
the protection path in the respective directions.
Note that this requires coordination between the end nodes to switch
to the protection path.
The basic steps in bi-directional 1+1 path protection are as
follows:
o Failure detection: There are two possibilities for this.
1. A node in the working path detects a failure event.
Such a node MUST send a failure indication message
towards the upstream or/and downstream end node of the
LSP (node A or B). This message MAY be forwarded along
the working path, or routed over a different path if
the network has general routing intelligence.
Mechanisms provided by the data transport plane MAY
also be used for this, if available.
2. The end nodes (A or B) detect the failure themselves
(e.g., loss of signal).
o Switchover: The action when an end node detects a failure in
the working path is as follows: Start receiving from the
protection path; at the same time, send a switchover request
message to the other end node to enable switching at the
other end.
The action when an end node receives a switchover request
message is as follows:
- Start receiving from the protection path; at the same
time, send a switchover response message to the other
end node.
GMPLS signaling mechanisms MAY be used to (reliably) signal the
failure indication message, as well as the switchover request and
response message. These messages MAY be forwarded along the
protection path if no other routing intelligence is available in the
network.
4.2.1 Identifiers
LSP Identifier: A unique identifier for each LSP. The LSP Identifier
is within the scope of the Source ID and Destination ID.
Source ID: ID of the source (e.g., IP address).
Destination ID: ID of the destination (e.g., IP address).
4.2.2 Nodal Information
Lang, J., Rajagopalan, B., et al - Standards Track 13
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
Each node that is on the working or protection path of an LSP MUST
have knowledge of the LSP identifier. If the network does not
provide routing intelligence, nodal information MAY also include
previous and next nodes in the LSP so that restoration-related
messages can be forwarded properly. When, the network provides
general routing intelligence, messages MAY be forwarded along paths
different than that of the LSP.
At the end-point nodes, the working and protection paths MUST be
associated. The association of these paths MAY be either provisioned
using signaling, or MAY be configured when LSP provisioning does not
involve signaling (e.g., provisioning through a management system).
The related association information MUST remain until the LSP is
explicitly de-provisioned.
4.2.3 End-to-End Failure Indication Message
This message is sent (reliably) by an intermediate node towards the
source of an LSP. For instance, such a node might have attempted
local span protection and failed. This message MAY not be necessary
if the data transport layer provides mechanisms for the notification
of LSP failure by the endpoints (i.e. if LSP endpoints are co-
located with a corresponding data (transport) maintenance/recovery
domain).
Consider a node that detects a link failure. The node MUST determine
the identities of all LSPs that are affected by the failure of the
link, and send an end-to-end failure indication message to the
source of each LSP. For scalability reasons, failure indication
messages MAY contain the identity and the status of multiple LSPs
rather than a single one. Each intermediate node receiving such a
message MUST forward the message to the appropriate next node such
that the message would ultimately reach the LSP source. However,
there is no requirement that this message flows towards the source
along the same path as the failed LSP. Furthermore, if an
intermediate node is itself generating a failure indication message,
there SHOULD be a mechanism to suppress all but one source of
failure indication messages. Finally, the failure indication message
MUST be sent reliably from the node detecting the failure to the LSP
source. Reliability MAY be achieved, for example, by re-transmitting
the message until an acknowledgement is received. However,
retransmission of failure indication messages SHOULD not cause
further message drops. This MAY be achieved through the appropriate
configuration and use of congestion and flow control mechanisms.
4.2.4 End-to-End Failure Acknowledgment Message
This message is sent by the source node to acknowledge the receipt
of an End-to-End failure indication message. This message is sent to
the originator of the failure indication message. The acknowledge
message SHOULD be sent for each failure indication message received.
Each intermediate node receiving the failure acknowledgment message
MUST forward it towards the destination of the message. However,
Lang, J., Rajagopalan, B., et al - Standards Track 14
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
there is no requirement that this message flows towards the
destination along the same path as the failed LSP.
This message MAY not be required if other means of ensuring reliable
message delivery are used.
4.2.5 End-to-End Switchover Request Message
This message is generated by the source node receiving an indication
of failure in an LSP. It is sent to the LSP destination, and it
carries the identifier of LSP being restored. The End-to-End
Switchover Request message MUST be sent reliably from the source to
the destination of the LSP.
4.2.6 End-to-End Switchover Response Message
This message is sent by the destination node receiving an End-to-End
Switchover Request message towards the source of the LSP. This
message SHOULD identify the LSP being switched over. This message
MUST be transmitted in response to each End-to-End Switchover
Request message received and MAY indicate either a positive or
negative outcome.
4.3 Shared Mesh Restoration
Shared mesh restoration refers to schemes under which protection
paths for multiple LSPs share common link and node resources. Under
these schemes, the protection capacity is pre-reserved, i.e., link
capacity is allocated to protect one or more LSPs but explicit
action is required to instantiate a specific protection LSP. This
requires restoration signaling along the protection path. Typically,
the protection capacity is shared only amongst LSPs whose working
paths are physically diverse. This criterion can be enforced when
provisioning the protection path. Specifically, provisioning-related
signaling messages may carry information about the working path to
nodes along the protection path. This can be used as call admission
control to accept/reject connections along the protection path based
on the identification of the resources used for the primary path.
Thus, shared mesh restoration is designed to protect an LSP after a
single failure event, i.e., a failure that affects the working path
of at most one LSP sharing the protection capacity. It is possible
that a protection path may not be successfully activated when
multiple, concurrent failure events occur. In this case, shared mesh
restoration capacity may be claimed for more than one failed LSP and
the protection path can be activated only for one of them (at most).
For implementing shared mesh restoration, the identifier and nodal
information related to signaling along the control path are as
defined for 1+1 protection in Sections 4.2.1 and 4.2.2. In addition,
each node MUST also keep (local) information needed to establish the
data plane of the protection path. This information MUST indicate
the local resources to be allocated, the fabric cross-connect to be
established to activate the path, etc. The precise nature of this
Lang, J., Rajagopalan, B., et al - Standards Track 15
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
information would depend on the type of node and LSP (the GMPLS
signaling document describes different type of switches [RFC3471]).
It would also depend on whether the information is fine or coarse-
grained. For example, fine-grained information would indicate pre-
selection of all details pertaining to protection path activation,
such as outgoing link, labels, etc. Coarse-grained information, on
the other hand, would allow some details to be determined during
protection path activation. For example, protection resources may be
pre-selected at the level of a TE link, while the selection of the
specific component link and label occurs during protection path
activation.
While the coarser specification allows some flexibility in selection
of the precise resource to activate, it also brings in more
complexity in decision making and signaling during the time-critical
restoration phase. Furthermore, the procedures for the assignment of
bandwidth to protection paths MUST take into account the total
resources in a TE link so that single-failure survivability
requirements are satisfied.
4.3.1 End-to-End Failure Indication and Acknowledgment Message
The End-to-End failure indication and acknowledgement procedures and
messages are as defined in Sections 4.2.3 and 4.2.4.
4.3.2 End-to-End Switchover Request Message
This message is generated by the source node receiving an indication
of failure in an LSP. It is sent to the LSP destination along the
protection path, and it identifies the LSP being restored. If any
intermediate node is unable to establish cross-connects for the
protection path, then it is desirable that no other node in the path
establishes cross-connects for the path. This would allow shared
mesh restoration paths to be efficiently utilized.
The End-to-End Switchover message MUST be sent reliably from the
source to the destination of the LSP along the protection path.
4.3.3 End-to-End Switchover Response Message
This message is sent by the destination node receiving an End-to-End
Switchover Request message towards the source of the LSP, along the
protection path. This message SHOULD identify the LSP that is being
switched over. Prior to activating the secondary bandwidth at each
hop along the path, Extra Traffic (if used) MUST be dropped and not
forwarded
This message MUST be transmitted in response to each End-to-End
Switchover Request message received.
5. Reversion and other Administrative Procedures
Reversion refers to the process of moving an LSP back to the
original working path after a failure is cleared and the path is
Lang, J., Rajagopalan, B., et al - Standards Track 16
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
repaired. Reversion applies both to local span and end-to-end path
protected LSPs. Reversion is desired for the following reasons.
First, the protection path may not be optimal as compared to the
working path from a routing and resource consumption point of view.
Second, moving an LSP to its working path allows the protection
resources to be used to protect other LSPs. Reversion has the
disadvantage of causing a second service disruption. Use of
reversion is at the option of the operator. Reversion implies that a
working path remains allocated to the LSP that was originally routed
over it even after a failure. It is important to have mechanisms
that allow reversion to be performed with minimal service disruption
to the customer. This can be achieved using a "bridge-and-switch"
approach (often referred to as make-before-break).
The basic steps involved in bridge-and-switch are:
1. The source node commences the process by "bridging" the
normal traffic onto both the working and the protection
paths (or links in the case of span protection).
2. Once the bridging process is complete, the source node sends
a Bridge and Switch Request message to the destination,
identifying the LSP and other information necessary to
perform reversion. Upon receipt of this message, the
destination selects the traffic from the working path. At
the same time, it bridges the transmitted traffic onto both
the working and protection paths.
3. The destination then sends a Bridge and Switch Response
message to the source confirming the completion of the
operation.
4. When the source receives this message, it switches to
receive from the working path, and stops transmitting
traffic on the protection path. The source then sends a
Bridge and Switch Completed message to the destination
confirming that the LSP has been reverted.
5. Upon receipt of this message, the destination stops
transmitting along the protection path and de-activates the
LSP along this path. The de-activation procedure should
remove the crossed connections along the protection path
(and frees the resources to be used for restoring other
failures.
Administrative procedures other than reversion include the ability
to force a switchover (from working to protection or vice versa),
and locking out switchover, i.e., preventing an LSP from moving from
working to protection administratively. These administrative
conditions have to be supported by signaling.
6. Discussion
6.1 LSP Priorities During Protection
Under span protection, a failure event could affect more than one
working link and there could be fewer protection links than the
number of failed working links. Furthermore, a working link may
Lang, J., Rajagopalan, B., et al - Standards Track 17
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
contain multiple LSPs of varying priority. Under this scenario, a
decision must be made as to which working links (and therefore LSPs)
should be protected. This decision MAY be based on LSP priorities.
In general, a node might detect failures sequentially, i.e., all
failed working links may not be detected simultaneously, but only
sequentially. In this case, as per the proposed signaling
procedures, LSPs on a working link MAY be switched over to a given
protection link, but another failure (of a working link carrying
higher priority LSPs) may be detected soon afterwards. In this case,
the new LSPs may bump the ones previously switched over the
protection link.
In the case of end-to-end shared mesh restoration, priorities MAY be
implemented for allocating shared link resources under multiple
failure scenarios. As described in Section 4.3, more than one LSP
can claim shared resources under multiple failure scenarios. If such
resources are first allocated to a lower priority LSP, they MAY have
to be reclaimed and allocated to a higher priority LSP.
7. Security Considerations
There are number of security threats that MAY be experienced due to
the exchange of messages and information as detailed in this
document. Some examples include interception, spoofing, modification
and replay of control messages. Therefore, following security
requirements are applicable to the mechanisms of this document.
o Signaling MUST be able to provide authentication, integrity,
and protect against replay attacks.
o Privacy and confidentiality is not required. Only
authentication is required to ensure that the signaling
messages are originating from the right place and have not
been modified in transit.
o Protection of the identity of the data plane end-points (in
failure indication messages) is not required
The consequences of poorly secured protection may increase the risk
of triggering recovery actions under false failure indication
messages including LSP identifiers that are not under failure. Such
information could subsequently trigger initiation of "false"
recovery actions while there are no reasons to do so. Additionally,
if the identification of the LSP is tampered from a failure
indication message recovery actions will involve nodes for which the
LSPs do not indicate any failure condition or for which no failure
indication message has been received. The consequences of such
actions is unpredictable and MAY lead to de-synchronisation between
the control and the data plane but also increase the risk of
misconnections. Moreover, the consequences of poorly applied
protection may increase the risk of misconnection. In particular,
when Extra Traffic is involved, it is easily possible to deliver the
wrong traffic to wrong destination. Similarly, an intrusion that
sets up what appears to be a valid protection LSP and then causes a
fault may be able to divert traffic.
Lang, J., Rajagopalan, B., et al - Standards Track 18
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
Moreover, tampering with routing information exchange may also have
an effect on traffic engineering. Therefore, any mechanisms used for
securing and authenticating the transmission of routing information
SHOULD be applied in the present context.
8. IANA Considerations
This document defines no new code points and requires no action by
IANA.
9. Editors' Addresses
Jonathan P. Lang
Sonos, Inc.
506 Chapala Street
Santa Barbara, CA 93101
EMail: jplang@ieee.org
Bala Rajagopalan
Intel Broadband Wireless Div.
2111 NE 25th Ave.
Hillsboro, OR 97124
Phone: +1 503 712-9291
EMail: bala.rajagopalan@intel.com
Dimitri Papadimitriou
Alcatel
Francis Wellesplein, 1
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
10. References
10.1 Normative References
[BUNDLE] Kompella, K., Rekhter, Y. and Berger, L., "Link
Bundling in MPLS Traffic Engineering", draft-ietf-mpls-
bundle-06.txt (work in progress).
[GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A. et al, "IS-IS
Extensions in Support of Generalized MPLS", draft-ietf-
isis-gmpls-extensions-16.txt (work in progress).
[GMPLS-OSPF] Kompella, K., Rekhter, Y., Banerjee, A. et al, "OSPF
Extensions in Support of Generalized MPLS", draft-ietf-
ccamp-ospf-gmpls-extensions-09.txt (work in progress).
[LMP] Lang, J., Ed., "Link Management Protocol (LMP) v1.0",
Internet Draft, draft-ietf-ccamp-lmp-10.txt (work in
progress).
[RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
Lang, J., Rajagopalan, B., et al - Standards Track 19
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) - Signaling Functional Description,"
RFC 3471, January 2003.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
10.2 Informative References
[TERM] Mannie, E., Papadimitriou, D., Ed., "Recovery
(Protection Internet Draft, draft-ietf-gmpls-recovery-
terminology-06.txt, (work in progress).
Lang, J., Rajagopalan, B., et al - Standards Track 20
draft-ietf-ccamp-gmpls-recovery-functional-04.txt April 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lang, J., Rajagopalan, B., et al - Standards Track 21