draft-ietf-ccamp-gmpls-recovery-analysis-05.txt   rfc4428.txt 
Network Working Group CCAMP GMPLS P&R Design Team Network Working Group D. Papadimitriou, Ed.
Internet Draft Request for Comments: 4428 Alcatel
Category: Informational Dimitri Papadimitriou (Editor) Category: Informational E. Mannie, Ed.
Expiration Date: October 2005 Eric Mannie (Editor) Perceval
March 2006
April 2005
Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based
Recovery Mechanisms (including Protection and Restoration) Recovery Mechanisms (including Protection and Restoration)
draft-ietf-ccamp-gmpls-recovery-analysis-05.txt Status of This Memo
Status of this Memo
This document is an Internet-Draft and is subject to all provisions This memo provides information for the Internet community. It does
of section 3 of RFC 3667. By submitting this Internet-Draft, each not specify an Internet standard of any kind. Distribution of this
author represents that any applicable patent or other IPR claims of memo is unlimited.
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 Copyright Notice
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 Copyright (C) The Internet Society (2006).
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 Abstract
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document provides an analysis grid to evaluate, compare, and
http://www.ietf.org/shadow.html. contrast the Generalized Multi-Protocol Label Switching (GMPLS)
protocol suite capabilities with the recovery mechanisms currently
proposed at the IETF CCAMP Working Group. A detailed analysis of
each of the recovery phases is provided using the terminology defined
in RFC 4427. This document focuses on transport plane survivability
and recovery issues and not on control plane resilience and related
aspects.
Copyright Notice Table of Contents
Copyright (C) The Internet Society (2005). All Rights Reserved. 1. Introduction ....................................................3
2. Contributors ....................................................4
3. Conventions Used in this Document ...............................5
4. Fault Management ................................................5
4.1. Failure Detection ..........................................5
4.2. Failure Localization and Isolation .........................8
4.3. Failure Notification .......................................9
4.4. Failure Correlation .......................................11
5. Recovery Mechanisms ............................................11
5.1. Transport vs. Control Plane Responsibilities ..............11
5.2. Technology-Independent and Technology-Dependent
Mechanisms ................................................12
5.2.1. OTN Recovery .......................................12
5.2.2. Pre-OTN Recovery ...................................13
5.2.3. SONET/SDH Recovery .................................13
5.3. Specific Aspects of Control Plane-Based Recovery
Mechanisms ................................................14
5.3.1. In-Band vs. Out-Of-Band Signaling ..................14
5.3.2. Uni- vs. Bi-Directional Failures ...................15
5.3.3. Partial vs. Full Span Recovery .....................17
5.3.4. Difference between LSP, LSP Segment and
Span Recovery ......................................18
5.4. Difference between Recovery Type and Scheme ...............19
5.5. LSP Recovery Mechanisms ...................................21
5.5.1. Classification .....................................21
5.5.2. LSP Restoration ....................................23
5.5.3. Pre-Planned LSP Restoration ........................24
5.5.4. LSP Segment Restoration ............................25
6. Reversion ......................................................26
6.1. Wait-To-Restore (WTR) .....................................26
6.2. Revertive Mode Operation ..................................26
6.3. Orphans ...................................................27
7. Hierarchies ....................................................27
7.1. Horizontal Hierarchy (Partitioning) .......................28
7.2. Vertical Hierarchy (Layers) ...............................28
7.2.1. Recovery Granularity ...............................30
7.3. Escalation Strategies .....................................30
7.4. Disjointness ..............................................31
7.4.1. SRLG Disjointness ..................................32
8. Recovery Mechanisms Analysis ...................................33
8.1. Fast Convergence (Detection/Correlation and
Hold-off Time) ............................................34
8.2. Efficiency (Recovery Switching Time) ......................34
8.3. Robustness ................................................35
8.4. Resource Optimization .....................................36
8.4.1. Recovery Resource Sharing ..........................37
8.4.2. Recovery Resource Sharing and SRLG Recovery ........39
8.4.3. Recovery Resource Sharing, SRLG
Disjointness and Admission Control .................40
9. Summary and Conclusions ........................................42
10. Security Considerations .......................................43
11. Acknowledgements ..............................................43
12. References ....................................................44
12.1. Normative References .....................................44
12.2. Informative References ...................................44
Abstract 1. Introduction
This document provides an analysis grid to evaluate, compare and This document provides an analysis grid to evaluate, compare, and
contrast the Generalized Multi-Protocol Label Switching (GMPLS) contrast the Generalized MPLS (GMPLS) protocol suite capabilities
protocol suite capabilities with respect to the recovery mechanisms with the recovery mechanisms proposed at the IETF CCAMP Working
currently proposed at the IETF CCAMP Working Group. A detailed Group. The focus is on transport plane survivability and recovery
analysis of each of the recovery phases is provided using the issues and not on control-plane-resilience-related aspects. Although
terminology defined in a companion document. This document focuses the recovery mechanisms described in this document impose different
on transport plane survivability and recovery issues and not on requirements on GMPLS-based recovery protocols, the protocols'
control plane resilience and related aspects. specifications will not be covered in this document. Though the
concepts discussed are technology independent, this document
implicitly focuses on SONET [T1.105]/SDH [G.707], Optical Transport
Networks (OTN) [G.709], and pre-OTN technologies, except when
specific details need to be considered (for instance, in the case of
failure detection).
D.Papadimitriou et al. - Expires October 2005 1 A detailed analysis is provided for each of the recovery phases as
identified in [RFC4427]. These phases define the sequence of generic
operations that need to be performed when a LSP/Span failure (or any
other event generating such failures) occurs:
Table of Content - Phase 1: Failure Detection
- Phase 2: Failure Localization (and Isolation)
- Phase 3: Failure Notification
- Phase 4: Recovery (Protection or Restoration)
- Phase 5: Reversion (Normalization)
Status of this Memo .............................................. 1 Together, failure detection, localization, and notification phases
Abstract ......................................................... 1 are referred to as "fault management". Within a recovery domain, the
Table of Content ................................................. 2 entities involved during the recovery operations are defined in
1. Contributors .................................................. 3 [RFC4427]; these entities include ingress, egress, and intermediate
2. Conventions used in this Document ............................. 4 nodes. The term "recovery mechanism" is used to cover both
3. Introduction .................................................. 4 protection and restoration mechanisms. Specific terms such as
4. Fault Management .............................................. 5 "protection" and "restoration" are used only when differentiation is
4.1 Failure Detection ............................................ 5 required. Likewise the term "failure" is used to represent both
4.2 Failure Localization and Isolation ........................... 7 signal failure and signal degradation.
4.3 Failure Notification ......................................... 8
4.4 Failure Correlation ......................................... 10
5. Recovery Mechanisms .......................................... 10
5.1 Transport vs. Control Plane Responsibilities ................ 10
5.2 Technology In/dependent Mechanisms .......................... 11
5.2.1 OTN Recovery .............................................. 11
5.2.2 Pre-OTN Recovery .......................................... 11
5.2.3 SONET/SDH Recovery ........................................ 12
5.3 Specific Aspects of Control Plane-based Recovery Mechanisms . 12
5.3.1 In-band vs. Out-of-band Signaling ......................... 12
5.3.2 Uni- vs. Bi-directional Failures .......................... 13
5.3.3 Partial vs. Full Span Recovery ............................ 15
5.3.4 Difference between LSP, LSP Segment and Span Recovery ..... 16
5.4 Difference between Recovery Type and Scheme ................. 16
5.5 LSP Recovery Mechanisms ..................................... 18
5.5.1 Classification ............................................ 18
5.5.2 LSP Restoration ........................................... 20
5.5.3 Pre-planned LSP Restoration ............................... 21
5.5.4 LSP Segment Restoration ................................... 22
6. Reversion .................................................... 23
6.1 Wait-To-Restore (WTR) ....................................... 23
6.2 Revertive Mode Operation .................................... 23
6.3 Orphans ..................................................... 24
7. Hierarchies .................................................. 24
7.1 Horizontal Hierarchy (Partitions) ........................... 25
7.2 Vertical Hierarchy (Layers) ................................. 25
7.2.1 Recovery Granularity ...................................... 27
7.3 Escalation Strategies ....................................... 27
7.4 Disjointness ................................................ 28
7.4.1 SRLG Disjointness ......................................... 28
8. Recovery Mechanisms Analysis ................................. 29
8.1 Fast Convergence (Detection/Correlation and Hold-off Time) .. 30
8.2 Efficiency (Recovery Switching Time) ........................ 30
8.3 Robustness .................................................. 31
8.4 Resource Optimization ....................................... 31
8.4.1 Recovery Resource Sharing ................................. 32
8.4.2 Recovery Resource Sharing and SRLG Recovery ............... 34
8.4.3 Recovery Resource Sharing, SRLG Disjointness and Admission. 35
9. Summary and Conclusions ...................................... 36
10. Security Considerations ..................................... 38
11. IANA Considerations ......................................... 38
12. Acknowledgments ............................................. 38
D.Papadimitriou et al. - Expires October 2005 2 In addition, when analyzing the different hierarchical recovery
13. References .................................................. 39 mechanisms including disjointness-related issues, a clear distinction
13.1 Normative References ....................................... 39 is made between partitioning (horizontal hierarchy) and layering
13.2 Informative References ..................................... 40 (vertical hierarchy). In order to assess the current GMPLS protocol
14. Editor's Address ............................................ 41 capabilities and the potential need for further extensions, the
Intellectual Property Statement ................................. 42 dimensions for analyzing each of the recovery mechanisms detailed in
Disclaimer of Validity .......................................... 42 this document are introduced. This document concludes by detailing
Copyright Statement ............................................. 42 the applicability of the current GMPLS protocol building blocks for
recovery purposes.
1. Contributors 2. Contributors
This document is the result of the CCAMP Working Group Protection This document is the result of the CCAMP Working Group Protection and
and Restoration design team joint effort. Besides the editors, the Restoration design team joint effort. Besides the editors, the
following are the authors that contributed to the present memo: following are the authors that contributed to the present memo:
Deborah Brungard (AT&T) Deborah Brungard (AT&T)
200 S. Laurel Ave. 200 S. Laurel Ave.
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
EMail: dbrungard@att.com EMail: dbrungard@att.com
Sudheer Dharanikota Sudheer Dharanikota
EMail: sudheer@ieee.org EMail: sudheer@ieee.org
Jonathan P. Lang (Sonos) Jonathan P. Lang (Sonos)
506 Chapala Street 506 Chapala Street
Santa Barbara, CA 93101, USA Santa Barbara, CA 93101, USA
EMail: jplang@ieee.org EMail: jplang@ieee.org
Guangzhi Li (AT&T) Guangzhi Li (AT&T)
180 Park Avenue, 180 Park Avenue,
Florham Park, NJ 07932, USA Florham Park, NJ 07932, USA
EMail: gli@research.att.com EMail: gli@research.att.com
Eric Mannie Eric Mannie
EMail: eric_mannie@hotmail.com Perceval
Rue Tenbosch, 9
1000 Brussels
Belgium
Phone: +32-2-6409194
EMail: eric.mannie@perceval.net
Dimitri Papadimitriou (Alcatel) Dimitri Papadimitriou (Alcatel)
Francis Wellesplein, 1 Francis Wellesplein, 1
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
EMail: dimitri.papadimitriou@alcatel.be EMail: dimitri.papadimitriou@alcatel.be
Bala Rajagopalan
Microsoft India Development Center
Hyderabad, India
Bala Rajagopalan (Intel Broadband Wireless Division) EMail: balar@microsoft.com
2111 NE 25th Ave.
Hillsboro, OR 97124, USA
EMail: bala.rajagopalan@intel.com
Yakov Rekhter (Juniper) Yakov Rekhter (Juniper)
1194 N. Mathilda Avenue 1194 N. Mathilda Avenue
Sunnyvale, CA 94089, USA Sunnyvale, CA 94089, USA
EMail: yakov@juniper.net
D.Papadimitriou et al. - Expires October 2005 3 EMail: yakov@juniper.net
2. Conventions used in this document 3. Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Any other recovery-related terminology used in this document
conforms to the one defined in [TERM]. The reader is also assumed to
be familiar with the terminology developed in [RFC3945], [RFC3471],
[RFC3473], [GMPLS-RTG] and [LMP].
3. Introduction
This document provides an analysis grid to evaluate, compare and
contrast the Generalized MPLS (GMPLS) protocol suite capabilities
with respect to the recovery mechanisms proposed at the IETF CCAMP
Working Group. The focus is on transport plane survivability and
recovery issues and not on control plane resilience related aspects.
Although the recovery mechanisms described in this document impose
different requirements on GMPLS-based recovery protocols, the
protocol(s) specifications will not be covered in this document.
Though the concepts discussed are technology independent, this
document implicitly focuses on SONET [T1.105]/SDH [G.707], Optical
Transport Networks (OTN) [G.709] and pre-OTN technologies except
when specific details need to be considered (for instance, in the
case of failure detection).
A detailed analysis is provided for each of the recovery phases as
identified in [TERM]. These phases define the sequence of generic
operations that need to be performed when a LSP/Span failure (or any
other event generating such failures) occurs:
- Phase 1: Failure detection
- Phase 2: Failure localization and isolation
- Phase 3: Failure notification
- Phase 4: Recovery (Protection/Restoration)
- Phase 5: Reversion (normalization)
Failure detection, localization and notification phases together are
referred to as fault management. Within a recovery domain, the
entities involved during the recovery operations are defined in
[TERM]; these entities include ingress, egress and intermediate
nodes. The term "recovery mechanism" is used to cover both
protection and restoration mechanisms. Specific terms such as
protection and restoration are only used when differentiation is
required. Likewise the term "failure" is used to represent both
signal failure and signal degradation.
In addition, a clear distinction is made between partitioning
(horizontal hierarchy) and layering (vertical hierarchy) when
analyzing the different hierarchical recovery mechanisms including
disjointness related issues. The dimensions from which each of the
recovery mechanisms detailed in this document can be analyzed are
D.Papadimitriou et al. - Expires October 2005 4 Any other recovery-related terminology used in this document conforms
introduced to assess the current GMPLS protocol capabilities and the to that defined in [RFC4427]. The reader is also assumed to be
potential need for further extensions. This document concludes by familiar with the terminology developed in [RFC3945], [RFC3471],
detailing the applicability of the current GMPLS protocol building [RFC3473], [RFC4202], and [RFC4204].
blocks for recovery purposes.
4. Fault Management 4. Fault Management
4.1 Failure Detection 4.1. Failure Detection
Transport failure detection is the only phase that can not be Transport failure detection is the only phase that cannot be achieved
achieved by the control plane alone since the latter needs a hook to by the control plane alone because the latter needs a hook to the
the transport plane to collect the related information. It has to be transport plane in order to collect the related information. It has
emphasized that even if failure events themselves are detected by to be emphasized that even if failure events themselves are detected
the transport plane, the latter, upon a failure condition, must by the transport plane, the latter, upon a failure condition, must
trigger the control plane for subsequent actions through the use of trigger the control plane for subsequent actions through the use of
GMPLS signalling capabilities (see [RFC3471] and [RFC3473]) or Link GMPLS signaling capabilities (see [RFC3471] and [RFC3473]) or Link
Management Protocol capabilities (see [LMP], Section 6). Management Protocol capabilities (see [RFC4204], Section 6).
Therefore, by definition, transport failure detection is transport Therefore, by definition, transport failure detection is transport
technology dependent (and so exceptionally, we keep here the technology dependent (and so exceptionally, we keep here the
"transport plane" terminology). In transport fault management, "transport plane" terminology). In transport fault management,
distinction is made between a defect and a failure. Here, the distinction is made between a defect and a failure. Here, the
discussion addresses failure detection (persistent fault cause). In discussion addresses failure detection (persistent fault cause). In
the technology-dependent descriptions, a more precise specification the technology-dependent descriptions, a more precise specification
will be provided. will be provided.
As an example, SONET/SDH (see [G.707], [G.783] and [G.806]) provides As an example, SONET/SDH (see [G.707], [G.783], and [G.806]) provides
supervision capabilities covering: supervision capabilities covering:
- Continuity: monitors the integrity of the continuity of a trail - Continuity: SONET/SDH monitors the integrity of the continuity of a
(i.e. section or path). This operation is performed by monitoring trail (i.e., section or path). This operation is performed by
the presence/absence of the signal. Examples are Loss of Signal monitoring the presence/absence of the signal. Examples are Loss
(LOS) detection for the physical layer, Unequipped (UNEQ) Signal of Signal (LOS) detection for the physical layer, Unequipped (UNEQ)
detection for the path layer, Server Signal Fail Detection (e.g. Signal detection for the path layer, Server Signal Fail Detection
AIS) at the client layer. (e.g., AIS) at the client layer.
- Connectivity: monitors the integrity of the routing of the signal - Connectivity: SONET/SDH monitors the integrity of the routing of
between end-points. Connectivity monitoring is needed if the signal between end-points. Connectivity monitoring is needed
the layer provides flexible connectivity, either automatically if the layer provides flexible connectivity, either automatically
(e.g. cross-connects) or manually (e.g. fiber distribution frame). (e.g., cross-connects) or manually (e.g., fiber distribution
An example is the Trail (i.e. section or path) Trace Identifier frame). An example is the Trail (i.e., section or path) Trace
used at the different layers and the corresponding Trail Trace Identifier used at the different layers and the corresponding Trail
Identifier Mismatch detection. Trace Identifier Mismatch detection.
- Alignment: checks that the client and server layer frame start can - Alignment: SONET/SDH checks that the client and server layer frame
be correctly recovered from the detection of loss of alignment. start can be correctly recovered from the detection of loss of
The specific processes depend on the signal/frame structure and alignment. The specific processes depend on the signal/frame
may include: (multi-)frame alignment, pointer processing and structure and may include: (multi-)frame alignment, pointer
alignment of several independent frames to a common frame start in processing, and alignment of several independent frames to a common
case of inverse multiplexing. Loss of alignment is a generic term. frame start in case of inverse multiplexing. Loss of alignment is
Examples are loss of frame, loss of multi-frame, or loss of a generic term. Examples are loss of frame, loss of multi-frame,
pointer. or loss of pointer.
D.Papadimitriou et al. - Expires October 2005 5 - Payload type: SONET/SDH checks that compatible adaptation functions
- Payload type: checks that compatible adaptation functions are used are used at the source and the destination. Normally, this is done
at the source and the destination. This is normally done by adding by adding a payload type identifier (referred to as the "signal
a payload type identifier (referred to as the "signal label") at label") at the source adaptation function and comparing it with the
the source adaptation function and comparing it with the expected expected identifier at the destination. For instance, the payload
identifier at the destination. For instance, the payload type type identifier is compared with the corresponding mismatch
identifier and the corresponding mismatch detection. detection.
- Signal Quality: monitors the performance of a signal. For - Signal Quality: SONET/SDH monitors the performance of a signal.
instance, if the performance falls below a certain threshold a For instance, if the performance falls below a certain threshold, a
defect - excessive errors (EXC) or degraded signal (DEG) - is defect -- excessive errors (EXC) or degraded signal (DEG) -- is
detected. detected.
The most important point is that the supervision processes and the The most important point is that the supervision processes and the
corresponding failure detection (used to initiate the recovery corresponding failure detection (used to initiate the recovery
phase(s)) result in either: phase(s)) result in either:
- Signal Degrade (SD): A signal indicating that the associated data - Signal Degrade (SD): A signal indicating that the associated data
has degraded in the sense that a degraded defect condition is has degraded in the sense that a degraded defect condition is
active (for instance, a dDEG declared when the Bit Error Rate active (for instance, a dDEG declared when the Bit Error Rate
exceeds a preset threshold). exceeds a preset threshold). Or
- Signal Fail (SF): A signal indicating that the associated data has - Signal Fail (SF): A signal indicating that the associated data has
failed in the sense that a signal interrupting near-end defect failed in the sense that a signal interrupting near-end defect
condition is active (as opposed to the degraded defect). condition is active (as opposed to the degraded defect).
In Optical Transport Networks (OTN) equivalent supervision In Optical Transport Networks (OTN), equivalent supervision
capabilities are provided at the optical/digital section layers capabilities are provided at the optical/digital section layers
(i.e. Optical Transmission Section (OTS), Optical Multiplex Section (i.e., Optical Transmission Section (OTS), Optical Multiplex Section
(OMS) and Optical channel Transport Unit (OTU)) and at the optical/ (OMS) and Optical channel Transport Unit (OTU)) and at the
digital path layers (i.e. Optical Channel (OCh) and Optical channel optical/digital path layers (i.e., Optical Channel (OCh) and Optical
Data Unit (ODU)). Interested readers are referred to the ITU-T channel Data Unit (ODU)). Interested readers are referred to the
Recommendations [G.798] and [G.709] for more details. ITU-T Recommendations [G.798] and [G.709] for more details.
The above are examples that illustrate cases where the failure The above are examples that illustrate cases where the failure
detection, and reporting entities (see [TERM]) are co-located. The detection and reporting entities (see [RFC4427]) are co-located. The
following example illustrates the scenario where the failure following example illustrates the scenario where the failure
detecting and reporting entities (see [TERM]) are not co-located. detecting and reporting entities (see [RFC4427]) are not co-located.
In pre-OTN networks, a failure may be masked by intermediate O-E-O In pre-OTN networks, a failure may be masked by intermediate O-E-O
based Optical Line System (OLS), preventing a Photonic Cross-Connect based Optical Line System (OLS), preventing a Photonic Cross-Connect
(PXC) from detecting upstream failures. In such cases, failure (PXC) from detecting upstream failures. In such cases, failure
detection may be assisted by an out-of-band communication channel detection may be assisted by an out-of-band communication channel,
and failure condition reported to the PXC control plane. This can be and failure condition may be reported to the PXC control plane. This
provided by using [LMP-WDM] extensions that delivers IP message- can be provided by using [RFC4209] extensions that deliver IP
based communication between the PXC and the OLS control plane. Also, message-based communication between the PXC and the OLS control
since PXCs are independent of the framing format, failure conditions plane. Also, since PXCs are independent of the framing format,
can only be triggered either by detecting the absence of the optical failure conditions can only be triggered either by detecting the
signal or by measuring its quality. These mechanisms are generally absence of the optical signal or by measuring its quality. These
less reliable than electrical (digital) ones. Both types of mechanisms are generally less reliable than electrical (digital)
detection mechanisms are outside the scope of this document. If the ones. Both types of detection mechanisms are outside the scope of
intermediate OLS supports electrical (digital) mechanisms, using the this document. If the intermediate OLS supports electrical (digital)
LMP communication channel, these failure conditions are reported to mechanisms, using the LMP communication channel, these failure
conditions are reported to
D.Papadimitriou et al. - Expires October 2005 6 the PXC and subsequent recovery actions are performed as described in
the PXC and subsequent recovery actions performed as described in Section 5. As such, from the control plane viewpoint, this mechanism
Section 5. As such from the control plane viewpoint, this mechanism turns the OLS-PXC-composed system into a single logical entity, thus
turn the OLS-PXC composed system into a single logical entity having the same failure management mechanisms as any other O-E-O
allowing the consideration of the same failure management mechanisms capable device.
for such entity as for any other O-E-O capable device.
More generally, the following are typical failure conditions in More generally, the following are typical failure conditions in
SONET/SDH and pre-OTN networks: SONET/SDH and pre-OTN networks:
- Loss of Light (LOL)/Loss of Signal (LOS): Signal Failure (SF) - Loss of Light (LOL)/Loss of Signal (LOS): Signal Failure (SF)
condition where the optical signal is not detected any longer on condition where the optical signal is not detected any longer on
the receiver of a given interface. the receiver of a given interface.
- Signal Degrade (SD): detection of the signal degradation over - Signal Degrade (SD): detection of the signal degradation over
a specific period of time. a specific period of time.
- For SONET/SDH payloads, all of the above-mentioned supervision - For SONET/SDH payloads, all of the above-mentioned supervision
capabilities can be used, resulting in SD or SF condition. capabilities can be used, resulting in SD or SF conditions.
In summary, the following cases apply when considering the In summary, the following cases apply when considering the
communication between the detecting and reporting entities: communication between the detecting and reporting entities:
- Co-located detecting and reporting entities: both the detecting - Co-located detecting and reporting entities: both the detecting and
and reporting entities are on the same node (e.g., SONET/SDH reporting entities are on the same node (e.g., SONET/SDH equipment,
equipment, Opaque cross-connects, and, with some limitations, Opaque cross-connects, and, with some limitations, Transparent
Transparent cross-connects, etc.) cross-connects, etc.)
- Non-co-located detecting and reporting entities:
- Non co-located detecting and reporting entities:
o with in-band communication between entities: entities are o with in-band communication between entities: entities are
physically separated but the transport plane provides in-band physically separated, but the transport plane provides in-band
communication between them (e.g., Server Signal Failures (Alarm communication between them (e.g., Server Signal Failures such as
Indication Signal (AIS)), etc.) Alarm Indication Signal (AIS), etc.)
o with out-of-band communication between entities: entities are o with out-of-band communication between entities: entities are
physically separated but an out-of-band communication channel is physically separated, but an out-of-band communication channel is
provided between them (e.g., using [LMP]). provided between them (e.g., using [RFCF4204]).
4.2 Failure Localization and Isolation 4.2. Failure Localization and Isolation
Failure localization provides to the deciding entity information Failure localization provides information to the deciding entity
about the location (and so the identity) of the transport plane about the location (and so the identity) of the transport plane
entity that detects the LSP(s)/span(s) failure. The deciding entity entity that detects the LSP(s)/span(s) failure. The deciding entity
can then make an accurate decision to achieve finer grained recovery can then make an accurate decision to achieve finer grained recovery
switching action(s). Note that this information can also be included switching action(s). Note that this information can also be included
as part of the failure notification (see Section 4.3). as part of the failure notification (see Section 4.3).
In some cases, this accurate failure localization information may be In some cases, this accurate failure localization information may be
less urgent to determine if it requires performing more time less urgent to determine if it requires performing more time-
consuming failure isolation (see also Section 4.4). This is consuming failure isolation (see also Section 4.4). This is
particularly the case when edge-to-edge LSP recovery (edge referring particularly the case when edge-to-edge LSP recovery is performed
to a sub-network end-node for instance) is performed based on a based on a simple failure notification (including the identification
simple failure notification (including the identification of the of the working LSPs under failure condition). Note that "edge"
working LSPs under failure condition). In this case, a more accurate refers to a sub-network end-node, for instance. In this case, a more
localization and isolation can be performed after recovery of these accurate localization and isolation can be performed after recovery
LSPs. of these LSPs.
D.Papadimitriou et al. - Expires October 2005 7
Failure localization should be triggered immediately after the fault Failure localization should be triggered immediately after the fault
detection phase. This operation can be performed at the transport detection phase. This operation can be performed at the transport
plane and/or, if unavailable (via the transport plane), the control plane and/or (if the operation is unavailable via the transport
plane level where dedicated signaling messages can be used. When plane) the control plane level where dedicated signaling messages can
performed at the control plane level, a protocol such as LMP (see be used. When performed at the control plane level, a protocol such
[LMP], Section 6) can be used for failure localization purposes. as LMP (see [RFC4204], Section 6) can be used for failure
localization purposes.
4.3 Failure Notification 4.3. Failure Notification
Failure notification is used 1) to inform intermediate nodes that an Failure notification is used 1) to inform intermediate nodes that an
LSP/span failure has occurred and has been detected 2) to inform the LSP/span failure has occurred and has been detected and 2) to inform
deciding entities (which can correspond to any intermediate or end- the deciding entities (which can correspond to any intermediate or
point of the failed LSP/span) that the corresponding service is not end-point of the failed LSP/span) that the corresponding service is
available. In general, these deciding entities will be the ones not available. In general, these deciding entities will be the ones
taking the appropriate recovery decision. When co-located with the making the appropriate recovery decision. When co-located with the
recovering entity, these entities will also perform the recovering entity, these entities will also perform the corresponding
corresponding recovery action(s). recovery action(s).
Failure notification can be either provided by the transport or by Failure notification can be provided either by the transport or by
the control plane. As an example, let us first briefly describe the the control plane. As an example, let us first briefly describe the
failure notification mechanism defined at the SONET/SDH transport failure notification mechanism defined at the SONET/SDH transport
plane level (also referred to as maintenance signal supervision): plane level (also referred to as maintenance signal supervision):
- AIS (Alarm Indication Signal) occurs as a result of a failure - AIS (Alarm Indication Signal) occurs as a result of a failure
condition such as Loss of Signal and is used to notify downstream condition such as Loss of Signal and is used to notify downstream
nodes (of the appropriate layer processing) that a failure has nodes (of the appropriate layer processing) that a failure has
occurred. AIS performs two functions 1) inform the intermediate occurred. AIS performs two functions: 1) inform the intermediate
nodes (with the appropriate layer monitoring capability) that a nodes (with the appropriate layer monitoring capability) that a
failure has been detected 2) notify the connection end-point that failure has been detected and 2) notify the connection end-point
the service is no longer available. that the service is no longer available.
For a distributed control plane supporting one (or more) failure For a distributed control plane supporting one (or more) failure
notification mechanism(s), regardless of the mechanism's actual notification mechanism(s), regardless of the mechanism's actual
implementation, the same capabilities are needed with more (or less) implementation, the same capabilities are needed with more (or less)
information provided about the LSPs/spans under failure condition, information provided about the LSPs/spans under failure condition,
their detailed status, etc. their detailed statuses, etc.
The most important difference between these mechanisms is related to The most important difference between these mechanisms is related to
the fact that transport plane notifications (as defined today) would the fact that transport plane notifications (as defined today) would
directly initiate either a certain type of protection switching directly initiate either a certain type of protection switching (such
(such as those described in [TERM]) via the transport plane or as those described in [RFC4427]) via the transport plane or
restoration actions via the management plane. restoration actions via the management plane.
On the other hand, using a failure notification mechanism through On the other hand, using a failure notification mechanism through the
the control plane would provide the possibility to trigger either a control plane would provide the possibility of triggering either a
protection or a restoration action via the control plane. This has protection or a restoration action via the control plane. This has
the advantage that a control plane recovery responsible entity does the advantage that a control-plane-recovery-responsible entity does
not necessarily have to be co-located with a transport not necessarily have to be co-located with a transport
maintenance/recovery domain. A control plane recovery domain can be maintenance/recovery domain. A control plane recovery domain can be
defined at entities not supporting a transport plane recovery. defined at entities not supporting a transport plane recovery.
Moreover, as specified in [RFC3473], notification message exchanges Moreover, as specified in [RFC3473], notification message exchanges
through a GMPLS control plane may not follow the same path as the through a GMPLS control plane may not follow the same path as the
D.Papadimitriou et al. - Expires October 2005 8
LSP/spans for which these messages carry the status. In turn, this LSP/spans for which these messages carry the status. In turn, this
ensures a fast, reliable (through acknowledgement and the use of ensures a fast, reliable (through acknowledgement and the use of
either a dedicated control plane network or disjoint control either a dedicated control plane network or disjoint control
channels) and efficient (through the aggregation of several LSP/span channels), and efficient (through the aggregation of several LSP/span
status within the same message) failure notification mechanism. statuses within the same message) failure notification mechanism.
The other important properties to be met by the failure notification The other important properties to be met by the failure notification
mechanism are mainly the following: mechanism are mainly the following:
- Notification messages must provide enough information such that - Notification messages must provide enough information such that the
the most efficient subsequent recovery action will be taken (in most efficient subsequent recovery action will be taken at the
most of the recovery types and schemes this action is even recovering entities (in most of the recovery types and schemes this
deterministic) at the recovering entities. Remember here that action is even deterministic). Remember here that these entities
these entities can be either intermediate or end-points through can be either intermediate or end-points through which normal
which normal traffic flows. Based on local policy, intermediate traffic flows. Based on local policy, intermediate nodes may not
nodes may not use this information for subsequent recovery actions use this information for subsequent recovery actions (see for
(see for instance the APS protocol phases as described in [TERM]). instance the APS protocol phases as described in [RFC4427]). In
In addition, since fast notification is a mechanism running in addition, since fast notification is a mechanism running in
collaboration with the existing GMPLS signalling (see [RFC3473]) collaboration with the existing GMPLS signaling (see [RFC3473])
that also allows intermediate nodes to stay informed about the that also allows intermediate nodes to stay informed about the
status of the working LSP/spans under failure condition. status of the working LSP/spans under failure condition.
The trade-off here is to define what information the LSP/span end- The trade-off here arises when defining what information the
points (more precisely, the deciding entity) needs in order for LSP/span end-points (more precisely, the deciding entities) need in
the recovering entity to take the best recovery action: if not order for the recovering entity to take the best recovery action:
enough information is provided, the decision can not be optimal If not enough information is provided, the decision cannot be
(note that in this eventuality, the important issue is to quantify optimal (note that in this eventuality, the important issue is to
the level of sub-optimality), if too much information is provided quantify the level of sub-optimality). If too much information is
the control plane may be overloaded with unnecessary information provided, the control plane may be overloaded with unnecessary
and the aggregation/correlation of this notification information information and the aggregation/correlation of this notification
will be more complex and time consuming to achieve. Note that a information will be more complex and time-consuming to achieve.
more detailed quantification of the amount of information to be Note that a more detailed quantification of the amount of
exchanged and processed is strongly dependent on the failure information to be exchanged and processed is strongly dependent on
notification protocol. the failure notification protocol.
- If the failure localization and isolation is not performed by one - If the failure localization and isolation are not performed by one
of the LSP/span end-points or some intermediate points, they of the LSP/span end-points or some intermediate points, the points
should receive enough information from the notification message in should receive enough information from the notification message in
order to locate the failure otherwise they would need to (re-) order to locate the failure. Otherwise, they would need to (re-)
initiate a failure localization and isolation action. initiate a failure localization and isolation action.
- Avoiding so-called notification storms implies that 1) the failure - Avoiding so-called notification storms implies that 1) the failure
detection output is correlated (i.e. alarm correlation) and detection output is correlated (i.e., alarm correlation) and
aggregated at the node detecting the failure(s) 2) the failure aggregated at the node detecting the failure(s), 2) the failure
notifications are directed to a restricted set of destinations (in notifications are directed to a restricted set of destinations (in
general the end-points) and that 3) failure notification general the end-points), and 3) failure notification suppression
suppression (i.e. alarm suppression) is provided in order to limit (i.e., alarm suppression) is provided in order to limit flooding in
flooding in case of multiple and/or correlated failures appearing case of multiple and/or correlated failures detected at several
at several locations in the network. locations in the network.
- Alarm correlation and aggregation (at the failure detecting
node) implies a consistent decision based on the conditions for
which a trade-off between fast convergence (at detecting node) and
D.Papadimitriou et al. - Expires October 2005 9 - Alarm correlation and aggregation (at the failure-detecting node)
fast notification (implying that correlation and aggregation implies a consistent decision based on the conditions for which a
occurs at receiving end-points) can be found. trade-off between fast convergence (at detecting node) and fast
notification (implying that correlation and aggregation occurs at
receiving end-points) can be found.
4.4 Failure Correlation 4.4. Failure Correlation
A single failure event (such as a span failure) can result into A single failure event (such as a span failure) can cause multiple
reporting multiple failures (such as individual LSP failures) failure (such as individual LSP failures) conditions to be reported.
conditions. These can be grouped (i.e. correlated) to reduce the These can be grouped (i.e., correlated) to reduce the number of
number of failure conditions communicated on the reporting channel, failure conditions communicated on the reporting channel, for both
for both in-band and out-of-band failure reporting. in-band and out-of-band failure reporting.
In such a scenario, it can be important to wait for a certain period In such a scenario, it can be important to wait for a certain period
of time, typically called failure correlation time, and gather all of time, typically called failure correlation time, and gather all
the failures to report them as a group of failures (or simply group the failures to report them as a group of failures (or simply group
failure). For instance, this approach can be provided using LMP-WDM failure). For instance, this approach can be provided using LMP-WDM
for pre-OTN networks (see [LMP-WDM]) or when using Signal Failure/ for pre-OTN networks (see [RFC4209]) or when using Signal
Degrade Group in the SONET/SDH context. Failure/Degrade Group in the SONET/SDH context.
Note that a default average time interval during which failure Note that a default average time interval during which failure
correlation operation can be performed is difficult to provide since correlation operation can be performed is difficult to provide since
it is strongly dependent on the underlying network topology. it is strongly dependent on the underlying network topology.
Therefore, it can be advisable to provide a per-node configurable Therefore, providing a per-node configurable failure correlation time
failure correlation time. The detailed selection criteria for this can be advisable. The detailed selection criteria for this time
time interval are outside of the scope of this document. interval are outside of the scope of this document.
When failure correlation is not provided, multiple failure When failure correlation is not provided, multiple failure
notification messages may be sent out in response to a single notification messages may be sent out in response to a single failure
failure (for instance, a fiber cut), each one containing a set of (for instance, a fiber cut). Each failure notification message
information on the failed working resources (for instance, the contains a set of information on the failed working resources (for
individual lambda LSP flowing through this fiber). This allows for a instance, the individual lambda LSP flowing through this fiber).
more prompt response but can potentially overload the control plane This allows for a more prompt response, but can potentially overload
due to a large amount of failure notifications. the control plane due to a large amount of failure notifications.
5. Recovery Mechanisms 5. Recovery Mechanisms
5.1 Transport vs. Control Plane Responsibilities 5.1. Transport vs. Control Plane Responsibilities
For both protection and restoration, and when applicable, recovery When applicable, recovery resources are provisioned, for both
resources are provisioned using GMPLS signalling capabilities. Thus, protection and restoration, using GMPLS signaling capabilities.
these are control plane-driven actions (topological and resource- Thus, these are control plane-driven actions (topological and
constrained) that are always performed in this context. resource-constrained) that are always performed in this context.
The following tables give an overview of the responsibilities taken The following tables give an overview of the responsibilities taken
by the control plane in case of LSP/span recovery: by the control plane in case of LSP/span recovery:
1. LSP/span Protection 1. LSP/span Protection
- Phase 1: Failure detection Transport plane - Phase 1: Failure Detection Transport plane
- Phase 2: Failure localization/isolation Transport/Control plane - Phase 2: Failure Localization/Isolation Transport/Control plane
- Phase 3: Failure notification Transport/Control plane - Phase 3: Failure Notification Transport/Control plane
- Phase 4: Protection switching Transport/Control plane - Phase 4: Protection Switching Transport/Control plane
- Phase 5: Reversion (normalization) Transport/Control plane - Phase 5: Reversion (Normalization) Transport/Control plane
D.Papadimitriou et al. - Expires October 2005 10
Note: in the context of LSP/span protection, control plane actions Note: in the context of LSP/span protection, control plane actions
can be performed either for operational purposes and/or can be performed either for operational purposes and/or
synchronization purposes (vertical synchronization between transport synchronization purposes (vertical synchronization between transport
and control plane) and/or notification purposes (horizontal and control plane) and/or notification purposes (horizontal
synchronization between end-nodes at control plane level). This synchronization between end-nodes at control plane level). This
suggests the selection of the responsible plane (in particular for suggests the selection of the responsible plane (in particular for
protection switching) during the provisioning phase of the protection switching) during the provisioning phase of the
protected/protection LSP. protected/protection LSP.
2. LSP/span Restoration 2. LSP/span Restoration
- Phase 1: Failure detection Transport plane - Phase 1: Failure Detection Transport plane
- Phase 2: Failure localization/isolation Transport/Control plane - Phase 2: Failure Localization/Isolation Transport/Control plane
- Phase 3: Failure notification Control plane - Phase 3: Failure Notification Control plane
- Phase 4: Recovery switching Control plane - Phase 4: Recovery Switching Control plane
- Phase 5: Reversion (normalization) Control plane - Phase 5: Reversion (Normalization) Control plane
Therefore, this document primarily focuses on provisioning of LSP Therefore, this document primarily focuses on provisioning of LSP
recovery resources, failure notification mechanisms, recovery recovery resources, failure notification mechanisms, recovery
switching, and reversion operations. Moreover some additional switching, and reversion operations. Moreover, some additional
considerations can be dedicated to the mechanisms associated to the considerations can be dedicated to the mechanisms associated to the
failure localization/isolation phase. failure localization/isolation phase.
5.2 Technology in/dependent mechanisms 5.2. Technology-Independent and Technology-Dependent Mechanisms
The present recovery mechanisms analysis applies in fact to any The present recovery mechanisms analysis applies to any circuit-
circuit oriented data plane technology with discrete bandwidth oriented data plane technology with discrete bandwidth increments
increments (like SONET/SDH, G.709 OTN, etc.) being controlled by a (like SONET/SDH, G.709 OTN, etc.) being controlled by a GMPLS-based
GMPLS-based distributed control plane. distributed control plane.
The following sub-sections are not intended to favor one technology The following sub-sections are not intended to favor one technology
versus another. They just list pro and cons for each of them in versus another. They list pro and cons for each technology in order
order to determine the mechanisms that GMPLS-based recovery must to determine the mechanisms that GMPLS-based recovery must deliver to
deliver to overcome their cons and take benefits of their pros in overcome their cons and make use of their pros in their respective
their respective applicability context. applicability context.
5.2.1 OTN Recovery 5.2.1. OTN Recovery
OTN recovery specifics are left for further considerations. OTN recovery specifics are left for further consideration.
5.2.2 Pre-OTN Recovery 5.2.2. Pre-OTN Recovery
Pre-OTN recovery specifics (also referred to as "lambda switching") Pre-OTN recovery specifics (also referred to as "lambda switching")
present mainly the following advantages: present mainly the following advantages:
- benefits from a simpler architecture making it more suitable for - They benefit from a simpler architecture, making it more suitable
mesh-based recovery types and schemes (on a per channel basis). for mesh-based recovery types and schemes (on a per-channel basis).
- when providing suppression of intermediate node transponders (vs. - Failure suppression at intermediate node transponders, e.g., use of
use of non-standard masking of upstream failures) e.g. use of
squelching, implies that failures (such as LoL) will propagate to squelching, implies that failures (such as LoL) will propagate to
edge nodes giving the possibility to initiate recovery actions edge nodes. Thus, edge nodes will have the possibility to initiate
driven by upper layers. recovery actions driven by upper layers (vs. use of non-standard
masking of upstream failures).
D.Papadimitriou et al. - Expires October 2005 11 The main disadvantage is the lack of interworking due to the large
The main disadvantage comes from the lack of interworking due to the amount of failure management (in particular failure notification
large amount of failure management (in particular failure protocols) and recovery mechanisms currently available.
notification protocols) and recovery mechanisms currently available.
Note also, that for all-optical networks, combination of recovery Note also, that for all-optical networks, combination of recovery
with optical physical impairments is left for a future release of with optical physical impairments is left for a future release of
this document since corresponding detection technologies are under this document because corresponding detection technologies are under
specification. specification.
5.2.3 SONET/SDH Recovery 5.2.3. SONET/SDH Recovery
Some of the advantages of SONET [T1.105]/SDH [G.707] and more Some of the advantages of SONET [T1.105]/SDH [G.707], and more
generically any TDM transport plane recovery are that they provide: generically any Time Division Multiplexing (TDM) transport plane
recovery, are that they provide:
- Protection types operating at the data plane level are - Protection types operating at the data plane level that are
standardized (see [G.841]) and can operate across protected standardized (see [G.841]) and can operate across protected domains
domains and interwork (see [G.842]). and interwork (see [G.842]).
- Failure detection, notification and path/section Automatic - Failure detection, notification, and path/section Automatic
Protection Switching (APS) mechanisms. Protection Switching (APS) mechanisms.
- Greater control over the granularity of the TDM LSPs/links that - Greater control over the granularity of the TDM LSPs/links that can
can be recovered with respect to coarser optical channel (or whole be recovered with respect to coarser optical channel (or whole
fiber content) recovery switching fiber content) recovery switching
Some of the limitations of the SONET/SDH recovery are: Some of the limitations of the SONET/SDH recovery are:
- Limited topological scope: Inherently the use of ring topologies, - Limited topological scope: Inherently the use of ring topologies,
typically, dedicated Sub-Network Connection Protection (SNCP) or typically, dedicated Sub-Network Connection Protection (SNCP) or
shared protection rings, has reduced flexibility and resource shared protection rings, has reduced flexibility and resource
efficiency with respect to the (somewhat more complex) meshed efficiency with respect to the (somewhat more complex) meshed
recovery. recovery.
- Inefficient use of spare capacity: SONET/SDH protection is largely - Inefficient use of spare capacity: SONET/SDH protection is largely
applied to ring topologies, where spare capacity often remains applied to ring topologies, where spare capacity often remains
idle, making the efficiency of bandwidth usage a real issue. idle, making the efficiency of bandwidth usage a real issue.
- Support of meshed recovery requires intensive network management - Support of meshed recovery requires intensive network management
development and the functionality is limited by both the network development, and the functionality is limited by both the network
elements and the capabilities of the element management systems elements and the capabilities of the element management systems
(justifying thus the development of GMPLS-based distributed (thus justifying the development of GMPLS-based distributed
recovery mechanisms.) recovery mechanisms.)
5.3 Specific Aspects of Control Plane-based Recovery Mechanisms 5.3. Specific Aspects of Control Plane-Based Recovery Mechanisms
5.3.1 In-band vs Out-of-band Signalling 5.3.1. In-Band vs. Out-Of-Band Signaling
The nodes communicate through the use of IP terminating control The nodes communicate through the use of IP terminating control
channels defining the control plane (transport) topology. In this channels defining the control plane (transport) topology. In this
context, two classes of transport mechanisms can be considered here context, two classes of transport mechanisms can be considered here:
i.e. in-fiber or out-of-fiber (through a dedicated physically in-fiber or out-of-fiber (through a dedicated physically diverse
diverse control network referred to as the Data Communication control network referred to as the Data Communication Network or
DCN). The potential impact of the usage of an in-fiber (signaling)
D.Papadimitriou et al. - Expires October 2005 12 transport mechanism is briefly considered here.
Network or DCN). The potential impact of the usage of an in-fiber
(signalling) transport mechanism is briefly considered here.
In-fiber transport mechanism can be further subdivided into in-band In-fiber transport mechanisms can be further subdivided into in-band
and out-of-band. As such, the distinction between in-fiber in-band and out-of-band. As such, the distinction between in-fiber in-band
and in-fiber out-of-band signalling reduces to the consideration of and in-fiber out-of-band signaling reduces to the consideration of a
a logically versus physically embedded control plane topology with logically- versus physically-embedded control plane topology with
respect to the transport plane topology. In the scope of this respect to the transport plane topology. In the scope of this
document, it is assumed that at least one IP control channel between document, it is assumed that at least one IP control channel between
each pair of adjacent nodes is continuously available to enable the each pair of adjacent nodes is continuously available to enable the
exchange of recovery-related information and messages. Thus, in exchange of recovery-related information and messages. Thus, in
either case (i.e. in-band or out-of-band) at least one logical or either case (i.e., in-band or out-of-band) at least one logical or
physical control channel between each pair of nodes is always physical control channel between each pair of nodes is always
expected to be available. expected to be available.
Therefore, the key issue when using in-fiber signalling is whether Therefore, the key issue when using in-fiber signaling is whether one
one can assume independence between the fault-tolerance capabilities can assume independence between the fault-tolerance capabilities of
of control plane and the failures affecting the transport plane control plane and the failures affecting the transport plane
(including the nodes). Note also that existing specifications like (including the nodes). Note also that existing specifications like
the OTN provide a limited form of independence for in-fiber the OTN provide a limited form of independence for in-fiber signaling
signaling by dedicating a separate optical supervisory channel (OSC, by dedicating a separate optical supervisory channel (OSC, see
see [G.709] and [G.874]) to transport the overhead and other control [G.709] and [G.874]) to transport the overhead and other control
traffic. For OTNs, failure of the OSC does not result in failing the traffic. For OTNs, failure of the OSC does not result in failing the
optical channels. Similarly, loss of the control channel must not optical channels. Similarly, loss of the control channel must not
result in failing the data channels (transport plane). result in failing the data channels (transport plane).
5.3.2 Uni- versus Bi-directional Failures 5.3.2. Uni- vs. Bi-Directional Failures
The failure detection, correlation and notification mechanisms The failure detection, correlation, and notification mechanisms
(described in Section 4) can be triggered when either a (described in Section 4) can be triggered when either a uni-
unidirectional or a bi-directional LSP/Span failure occurs (or a directional or a bi-directional LSP/Span failure occurs (or a
combination of both). As illustrated in Figure 1 and 2, two combination of both). As illustrated in Figures 1 and 2, two
alternatives can be considered here: alternatives can be considered here:
1. Uni-directional failure detection: the failure is detected on the 1. Uni-directional failure detection: the failure is detected on the
receiver side i.e. it is only is detected by the downstream node receiver side, i.e., it is detected by only the downstream node to
to the failure (or by the upstream node depending on the failure the failure (or by the upstream node depending on the failure
propagation direction, respectively). propagation direction, respectively).
2. Bi-directional failure detection: the failure is detected on the 2. Bi-directional failure detection: the failure is detected on the
receiver side of both downstream node AND upstream node to the receiver side of both downstream node AND upstream node to the
failure. failure.
Notice that after the failure detection time, if only control plane Notice that after the failure detection time, if only control-plane-
based failure management is provided, the peering node is unaware of based failure management is provided, the peering node is unaware of
the failure detection status of its neighbor. the failure detection status of its neighbor.
------- ------- ------- ------- ------- ------- ------- -------
| | | |Tx Rx| | | | | | | |Tx Rx| | | |
| NodeA |----...----| NodeB |xxxxxxxxx| NodeC |----...----| NodeD | | NodeA |----...----| NodeB |xxxxxxxxx| NodeC |----...----| NodeD |
| |----...----| |---------| |----...----| | | |----...----| |---------| |----...----| |
------- ------- ------- ------- ------- ------- ------- -------
D.Papadimitriou et al. - Expires October 2005 13
t0 >>>>>>> F t0 >>>>>>> F
t1 x <---------------x t1 x <---------------x
Notification Notification
t2 <--------...--------x x--------...--------> t2 <--------...--------x x--------...-------->
Up Notification Down Notification Up Notification Down Notification
Figure 1: Uni-directional failure detection
------- ------- ------- ------- ------- ------- ------- -------
| | | |Tx Rx| | | | | | | |Tx Rx| | | |
| NodeA |----...----| NodeB |xxxxxxxxx| NodeC |----...----| NodeD | | NodeA |----...----| NodeB |xxxxxxxxx| NodeC |----...----| NodeD |
| |----...----| |xxxxxxxxx| |----...----| | | |----...----| |xxxxxxxxx| |----...----| |
------- ------- ------- ------- ------- ------- ------- -------
t0 F <<<<<<< >>>>>>> F t0 F <<<<<<< >>>>>>> F
t1 x <-------------> x t1 x <-------------> x
Notification Notification
t2 <--------...--------x x--------...--------> t2 <--------...--------x x--------...-------->
Up Notification Down Notification Up Notification Down Notification
Figure 2: Bi-directional failure detection
After failure detection, the following failure management operations After failure detection, the following failure management operations
can be subsequently considered: can be subsequently considered:
- Each detecting entity sends a notification message to the - Each detecting entity sends a notification message to the
corresponding transmitting entity. For instance, in Fig. 1 (Fig. corresponding transmitting entity. For instance, in Figure 1, node
2), node C sends a notification message to node B (while node B C sends a notification message to node B. In Figure 2, node C
sends a notification message to node C). To ensure reliable sends a notification message to node B while node B sends a
failure notification, a dedicated acknowledgment message can be notification message to node C. To ensure reliable failure
returned back to the sender node. notification, a dedicated acknowledgement message can be returned
back to the sender node.
- Next, within a certain (and pre-determined) time window, nodes - Next, within a certain (and pre-determined) time window, nodes
impacted by the failure occurrences may perform their correlation. impacted by the failure occurrences may perform their correlation.
In case of unidirectional failure, node B only receives the In case of uni-directional failure, node B only receives the
notification message from node C and thus the time for this notification message from node C, and thus the time for this
operation is negligible. In case of bi-directional failure, node B operation is negligible. In case of bi-directional failure, node B
(and node C) has to correlate the received notification message has to correlate the received notification message from node C with
from node C (node B, respectively) with the corresponding locally the corresponding locally detected information (and node C has to
detected information. do the same with the message from node B).
- After some (pre-determined) period of time, referred to as the - After some (pre-determined) period of time, referred to as the
hold-off time, after which the local recovery actions (see Section hold-off time, if the local recovery actions (see Section 5.3.4)
5.3.4) were not successful, the following occurs. In case of were not successful, the following occurs. In case of uni-
unidirectional failure and depending on the directionality of the directional failure and depending on the directionality of the LSP,
LSP, node B should send an upstream notification message (see node B should send an upstream notification message (see [RFC3473])
[RFC3473]) to the ingress node A and node C may send a downstream to the ingress node A. Node C may send a downstream notification
notification message (see [RFC3473]) to the egress node D. message (see [RFC3473]) to the egress node D. However, in that
However, in such a case only node A referred to as the "master" case, only node A would initiate an edge to edge recovery action.
(node D being then referred to as the "slave" per [TERM]), would Node A is referred to as the "master", and node D is referred to as
initiate an edge to edge recovery action. Note that the other LSP the "slave", per [RFC4427]. Note that the other LSP end-node (node
end-node (i.e. node D in this case) may be optionally notified D in this case) may be optionally notified using a downstream
using a downstream notification message (see [RFC3473]). notification message (see [RFC3473]).
In case of bi-directional failure, node B should send an upstream In case of bi-directional failure, node B should send an upstream
notification message (see [RFC3473]) to the ingress node A. Node C
D.Papadimitriou et al. - Expires October 2005 14 may send a downstream notification message (see [RFC3473]) to the
notification message (see [RFC3473]) to the ingress node A and egress node D. However, due to the dependence on the LSP
node C may send a downstream notification message (see [RFC3473]) directionality, only ingress node A would initiate an edge-to-edge
to the egress node D. However, due to the dependence on the LSP recovery action. Note that the other LSP end-node (node D in this
directionality, only ingress node A would initiate an edge to edge case) should also be notified of this event using a downstream
recovery action. Note that the other LSP end-node (i.e. node D in notification message (see [RFC3473]). For instance, if an LSP
this case) should also be notified of this event using a directed from D to A is under failure condition, only the
downstream notification message (see [RFC3473]). For instance, if
an LSP directed from D to A is under failure condition, only the
notification message sent from node C to D would initiate a notification message sent from node C to D would initiate a
recovery action and, in this case, per [TERM], the deciding and recovery action. In this case, per [RFC4427], the deciding and
recovering node D is referred to as the "master" while node A is recovering node D is referred to as the "master", while node A is
referred to as the "slave" (i.e. recovering only entity). referred to as the "slave" (i.e., recovering only entity).
Note: The determination of the master and the slave may be based Note: The determination of the master and the slave may be based
either on configured information or dedicated protocol capability. either on configured information or dedicated protocol capability.
In the above scenarios, the path followed by the upstream and In the above scenarios, the path followed by the upstream and
downstream notification messages does not have to be the same as the downstream notification messages does not have to be the same as the
one followed by the failed LSP (see [RFC3473] for more details on one followed by the failed LSP (see [RFC3473] for more details on the
the notification message exchange). The important point, concerning notification message exchange). The important point concerning this
this mechanism, is that either the detecting/reporting entity (i.e. mechanism is that either the detecting/reporting entity (i.e., nodes
the nodes B and C) is also the deciding/recovery entity or the B and C) is also the deciding/recovery entity or the
detecting/reporting entity is simply an intermediate node in the detecting/reporting entity is simply an intermediate node in the
subsequent recovery process. One refers to local recovery in the subsequent recovery process. One refers to local recovery in the
former case and to edge-to-edge recovery in the latter one (see also former case, and to edge-to-edge recovery in the latter one (see also
Section 5.3.4). Section 5.3.4).
5.3.3 Partial versus Full Span Recovery 5.3.3. Partial vs. Full Span Recovery
When a given span carries more than one LSPs or LSP segments, an When a given span carries more than one LSP or LSP segment, an
additional aspect must be considered. In case of span failure, the additional aspect must be considered. In case of span failure, the
LSPs it carries can be either individually recovered or recovered as LSPs it carries can be recovered individually, as a group (aka bulk
a group (aka bulk LSP recovery) or independent sub-groups. The LSP recovery), or as independent sub-groups. When correlation time
selection of this mechanism would be triggered independently of the windows are used and simultaneous recovery of several LSPs can be
failure notification granularity when correlation time windows are performed using a single request, the selection of this mechanism
used and simultaneous recovery of several LSPs can be performed would be triggered independently of the failure notification
using a single request. Moreover, criteria by which such sub-groups granularity. Moreover, criteria for forming such sub-groups are
can be formed are outside of the scope of this document. outside of the scope of this document.
Additional complexity arises in the case of (sub-)group LSP Additional complexity arises in the case of (sub-)group LSP recovery.
recovery. Between a given pair of nodes, the LSPs that a given (sub- Between a given pair of nodes, the LSPs that a given (sub-)group
)group contains may have been created from different source nodes contains may have been created from different source nodes (i.e.,
(i.e. initiator) and directed toward different destinations nodes. initiator) and directed toward different destination nodes.
Consequently the failure notification messages sub-sequent to a bi- Consequently the failure notification messages following a bi-
directional span failure affecting several LSPs (or the whole group directional span failure that affects several LSPs (or the whole
of LSPs it carries) are not necessarily directed toward the same group of LSPs it carries) are not necessarily directed toward the
initiator nodes. In particular these messages may be directed to same initiator nodes. In particular, these messages may be directed
both the upstream and downstream nodes to the failure. Therefore, to both the upstream and downstream nodes to the failure. Therefore,
such span failure may trigger recovery actions to be performed from such span failure may trigger recovery actions to be performed from
both sides (i.e. both from the upstream and the downstream node to both sides (i.e., from both the upstream and the downstream nodes to
the failure). In order to facilitate the definition of the the failure). In order to facilitate the definition of the
corresponding recovery mechanisms (and their sequence), one assumes corresponding recovery mechanisms (and their sequence), one assumes
here as well, that per [TERM] the deciding (and recovering) entity, here as well that, per [RFC4427], the deciding (and recovering)
entity (referred to as the "master") is the only initiator of the
D.Papadimitriou et al. - Expires October 2005 15 recovery of the whole LSP (sub-)group.
referred to as the "master" is the only initiator of the recovery of
the whole LSP (sub-)group.
5.3.4 Difference between LSP, LSP Segment and Span Recovery 5.3.4. Difference between LSP, LSP Segment and Span Recovery
The recovery definitions given in [TERM] are quite generic and apply The recovery definitions given in [RFC4427] are quite generic and
for link (or local span) and LSP recovery. The major difference apply for link (or local span) and LSP recovery. The major
between LSP, LSP Segment and span recovery is related to the number difference between LSP, LSP Segment and span recovery is related to
of intermediate nodes that the signalling messages have to travel. the number of intermediate nodes that the signaling messages have to
Since nodes are not necessarily adjacent in case of LSP (or LSP travel. Since nodes are not necessarily adjacent in the case of LSP
Segment) recovery, signalling message exchanges from the reporting (or LSP Segment) recovery, signaling message exchanges from the
to the deciding/recovery entity may have to cross several reporting to the deciding/recovery entity may have to cross several
intermediate nodes. In particular, this applies for the notification intermediate nodes. In particular, this applies to the notification
messages due to the number of hops separating the location of a messages due to the number of hops separating the location of a
failure occurrence from its destination. This results in an failure occurrence from its destination. This results in an
additional propagation and forwarding delay. Note that the former additional propagation and forwarding delay. Note that the former
delay may in certain circumstances be non-negligible; e.g. in case delay may in certain circumstances be non-negligible; e.g., in a
of copper out-of-band network, approximately 1 ms per 200km. copper out-of-band network, the delay is approximately 1 ms per
200km.
Moreover, the recovery mechanisms applicable to end-to-end LSPs and Moreover, the recovery mechanisms applicable to end-to-end LSPs and
to the segments that may compose an end-to-end LSP (i.e. edge-to- to the segments that may compose an end-to-end LSP (i.e., edge-to-
edge recovery) can be exactly the same. However, one expects in the edge recovery) can be exactly the same. However, one expects in the
latter case, that the destination of the failure notification latter case, that the destination of the failure notification message
message will be the ingress/egress of each of these segments. will be the ingress/egress of each of these segments. Therefore,
Therefore, using the mechanisms described in Section 5.3.2, failure using the mechanisms described in Section 5.3.2, failure notification
notification messages can be first exchanged between terminating messages can be exchanged first between terminating points of the LSP
points of the LSP segment and after expiration of the hold-off time segment, and after expiration of the hold-off time, between
be directed toward terminating points of the end-to-end LSP. terminating points of the end-to-end LSP.
Note: Several studies provide quantitative analysis of the relative Note: Several studies provide quantitative analysis of the relative
performance of LSP/span recovery techniques. [WANG] for instance, performance of LSP/span recovery techniques. [WANG] for instance,
provides an analysis grid for these techniques showing that dynamic provides an analysis grid for these techniques showing that dynamic
LSP restoration (see Section 5.5.2) performs well under medium LSP restoration (see Section 5.5.2) performs well under medium
network loads but suffers performance degradations at higher loads network loads, but suffers performance degradations at higher loads
due to greater contention for recovery resources. LSP restoration due to greater contention for recovery resources. LSP restoration
upon span failure, as defined in [WANG], degrades at higher loads upon span failure, as defined in [WANG], degrades at higher loads
because paths around failed links tend to increase the hop count of because paths around failed links tend to increase the hop count of
the affected LSPs and thus consume additional network resources. the affected LSPs and thus consume additional network resources.
Also, performance of LSP restoration can be enhanced by a failed Also, performance of LSP restoration can be enhanced by a failed
working LSP's source node initiating a new recovery attempt if an working LSP's source node that initiates a new recovery attempt if an
initial attempt fails. A single retry attempt is sufficient to initial attempt fails. A single retry attempt is sufficient to
produce large increases in the restoration success rate and ability produce large increases in the restoration success rate and ability
to initiate successful LSP restoration attempts, especially at high to initiate successful LSP restoration attempts, especially at high
loads, while not adding significantly to the long-term average loads, while not adding significantly to the long-term average
recovery time. Allowing additional attempts produces only small recovery time. Allowing additional attempts produces only small
additional gains in performance. This suggests using additional additional gains in performance. This suggests using additional
(intermediate) crankback signalling when using dynamic LSP (intermediate) crankback signaling when using dynamic LSP restoration
restoration (described in Section 5.5.2 - case 2). Details on (described in Section 5.5.2 - case 2). Details on crankback
crankback signalling are outside the scope of the present document. signaling are outside the scope of this document.
5.4 Difference between Recovery Type and Scheme 5.4. Difference between Recovery Type and Scheme
D.Papadimitriou et al. - Expires October 2005 16 [RFC4427] defines the basic LSP/span recovery types. This section
[TERM] defines the basic LSP/span recovery types. This section describes the recovery schemes that can be built using these recovery
describes the recovery schemes that can be built using these types. In brief, a recovery scheme is defined as the combination of
recovery types. In brief, a recovery scheme is defined as the several ingress-egress node pairs supporting a given recovery type
combination of several ingress-egress node pairs supporting a given (from the set of the recovery types they allow). Several examples
recovery type (from the set of the recovery types they allow). are provided here to illustrate the difference between recovery types
Several examples are provided here to illustrate the difference such as 1:1 or M:N, and recovery schemes such as (1:1)^n or (M:N)^n
between recovery types such as 1:1 or M:N and recovery schemes such (referred to as shared-mesh recovery).
as (1:1)^n or (M:N)^n referred to as shared-mesh recovery.
1. (1:1)^n with recovery resource sharing 1. (1:1)^n with recovery resource sharing
The exponent, n, indicates the number of times a 1:1 recovery type The exponent, n, indicates the number of times a 1:1 recovery type is
is applied between at most n different ingress-egress node pairs. applied between at most n different ingress-egress node pairs. Here,
Here, at most n pairs of disjoint working and recovery LSPs/spans at most n pairs of disjoint working and recovery LSPs/spans share a
share at most n times a common resource. Since the working LSPs/ common resource at most n times. Since the working LSPs/spans are
spans are mutually disjoint, simultaneous requests for use of the mutually disjoint, simultaneous requests for use of the shared
shared (common) resource will only occur in case of simultaneous (common) resource will only occur in case of simultaneous failures,
failures, which is less likely to happen. which are less likely to happen.
For instance, in the common (1:1)^2 case, if the 2 recovery LSPs in For instance, in the common (1:1)^2 case, if the 2 recovery LSPs in
the group overlap the same common resource, then it can handle only the group overlap the same common resource, then it can handle only
single failures; any multiple working LSP failures will cause at single failures; any multiple working LSP failures will cause at
least one working LSP to be denied automatic recovery. Consider for least one working LSP to be denied automatic recovery. Consider for
instance the following topology with the working LSPs A-B-C and F-G- instance the following topology with the working LSPs A-B-C and F-G-H
H and their respective recovery LSPs A-D-E-C and F-D-E-H that share and their respective recovery LSPs A-D-E-C and F-D-E-H that share a
a common D-E link resource. common D-E link resource.
A---------B---------C A---------B---------C
\ / \ /
\ / \ /
D-------------E D-------------E
/ \ / \
/ \ / \
F---------G---------H F---------G---------H
2. (M:N)^n with recovery resource sharing 2. (M:N)^n with recovery resource sharing
The (M:N)^n scheme is documented here for the sake of completeness The (M:N)^n scheme is documented here for the sake of completeness
only (i.e. it is not mandated that GMPLS capabilities would support only (i.e., it is not mandated that GMPLS capabilities support this
this scheme). The exponent, n, indicates the number of times an M:N scheme). The exponent, n, indicates the number of times an M:N
recovery type is applied between at most n different ingress-egress recovery type is applied between at most n different ingress-egress
node pairs. So the interpretation follows from the previous case, node pairs. So the interpretation follows from the previous case,
except that here disjointness applies to the N working LSPs/spans except that here disjointness applies to the N working LSPs/spans and
and to the M recovery LSPs/spans while sharing at most n times M to the M recovery LSPs/spans while sharing at most n times M common
common resources. resources.
In both schemes, it results in a "group" of sum{n=1}^N N{n} working In both schemes, it results in a "group" of sum{n=1}^N N{n} working
LSPs and a pool of shared recovery resources, not all of which are LSPs and a pool of shared recovery resources, not all of which are
available to any given working LSP. In such conditions, defining a available to any given working LSP. In such conditions, defining a
metric that describes the amount of overlap among the recovery LSPs metric that describes the amount of overlap among the recovery LSPs
would give some indication of the group's ability to handle would give some indication of the group's ability to handle
simultaneous failures of multiple LSPs. simultaneous failures of multiple LSPs.
D.Papadimitriou et al. - Expires October 2005 17
For instance, in the simple (1:1)^n case, if n recovery LSPs in a For instance, in the simple (1:1)^n case, if n recovery LSPs in a
(1:1)^n group overlap, then it can handle only single failures; any (1:1)^n group overlap, then the group can handle only single
simultaneous failure of multiple working LSPs will cause at least failures; any simultaneous failure of multiple working LSPs will
one working LSP to be denied automatic recovery. But if one cause at least one working LSP to be denied automatic recovery. But
considers for instance, a (2:2)^2 group in which there are two pairs if one considers, for instance, a (2:2)^2 group in which there are
of overlapping recovery LSPs, then two LSPs (belonging to the same two pairs of overlapping recovery LSPs, then two LSPs (belonging to
pair) can be simultaneously recovered. The latter case can be the same pair) can be simultaneously recovered. The latter case can
illustrated by the following topology with 2 pairs of working LSPs be illustrated by the following topology with 2 pairs of working LSPs
A-B-C and F-G-H and their respective recovery LSPs A-D-E-C and F-D- A-B-C and F-G-H and their respective recovery LSPs A-D-E-C and
E-H that share two common D-E link resources. F-D-E-H that share two common D-E link resources.
A========B========C A========B========C
\\ // \\ //
\\ // \\ //
D =========== E D =========== E
// \\ // \\
// \\ // \\
F========G========H F========G========H
Moreover, in all these schemes, (working) path disjointness can be Moreover, in all these schemes, (working) path disjointness can be
enforced by exchanging information related to working LSPs during enforced by exchanging information related to working LSPs during the
the recovery LSP signaling. Specific issues related to the recovery LSP signaling. Specific issues related to the combination
combination of shared (discrete) bandwidth and disjointness for of shared (discrete) bandwidth and disjointness for recovery schemes
recovery schemes are described in Section 8.4.2. are described in Section 8.4.2.
5.5 LSP Recovery Mechanisms 5.5. LSP Recovery Mechanisms
5.5.1 Classification 5.5.1. Classification
The recovery time and ratio of LSPs/spans depend on proper recovery The recovery time and ratio of LSPs/spans depend on proper recovery
LSP provisioning (meaning pre-provisioning when performed before LSP provisioning (meaning pre-provisioning when performed before
failure occurrence) and the level of overbooking of recovery failure occurrence) and the level of overbooking of recovery
resources (i.e. over-provisioning). A proper balance of these two resources (i.e., over-provisioning). A proper balance of these two
operations will result in the desired LSP/span recovery time and operations will result in the desired LSP/span recovery time and
ratio when single or multiple failure(s) occur(s). Note also that ratio when single or multiple failures occur. Note also that these
these operations are mostly performed during the network planning operations are mostly performed during the network planning phases.
phases.
The different options for LSP (pre-)provisioning and overbooking are The different options for LSP (pre-)provisioning and overbooking are
classified below to structure the analysis of the different recovery classified below to structure the analysis of the different recovery
mechanisms. mechanisms.
1. Pre-Provisioning 1. Pre-Provisioning
Proper recovery LSP pre-provisioning will help to alleviate the Proper recovery LSP pre-provisioning will help to alleviate the
failure of the working LSPs (due to the failure of the resources failure of the working LSPs (due to the failure of the resources that
that carry these LSPs). As an example, one may compute and establish carry these LSPs). As an example, one may compute and establish the
the recovery LSP either end-to-end or segment-per-segment, to recovery LSP either end-to-end or segment-per-segment, to protect a
protect a working LSP from multiple failure events affecting working LSP from multiple failure events affecting link(s), node(s)
and/or SRLG(s). The recovery LSP pre-provisioning options are
D.Papadimitriou et al. - Expires October 2005 18 classified as follows in the figure below:
link(s), node(s) and/or SRLG(s). The recovery LSP pre-provisioning
options can be classified (in the below figure) as follows:
(1) the recovery path can be either pre-computed or computed (1) The recovery path can be either pre-computed or computed on-
on-demand. demand.
(2) when the recovery path is pre-computed, it can be either pre- (2) When the recovery path is pre-computed, it can be either pre-
signaled (implying recovery resource reservation) or signaled signaled (implying recovery resource reservation) or signaled
on-demand. on-demand.
(3) when the recovery resources are pre-signaled, they can be either (3) When the recovery resources are pre-signaled, they can be either
pre-selected or selected on-demand. pre-selected or selected on-demand.
Recovery LSP provisioning phases: Recovery LSP provisioning phases:
(1) Path Computation --> On-demand (1) Path Computation --> On-demand
| |
| |
--> Pre-Computed --> Pre-Computed
| |
| |
(2) Signalling --> On-demand (2) Signaling --> On-demand
| |
| |
--> Pre-Signaled --> Pre-Signaled
| |
| |
(3) Resource Selection --> On-demand (3) Resource Selection --> On-demand
| |
| |
--> Pre-Selected --> Pre-Selected
Note that these different options lead to different LSP/span Note that these different options lead to different LSP/span recovery
recovery times. The following sections will consider the above- times. The following sections will consider the above-mentioned
mentioned pre-provisioning options when analyzing the different pre-provisioning options when analyzing the different recovery
recovery mechanisms. mechanisms.
2. Overbooking 2. Overbooking
There are many mechanisms available that allow the overbooking of There are many mechanisms available that allow the overbooking of the
the recovery resources. This overbooking can be done per LSP (such recovery resources. This overbooking can be done per LSP (as in the
as the example mentioned above), per link (such as span protection) example mentioned above), per link (such as span protection), or even
or even per domain. In all these cases, the level of overbooking, as per domain. In all these cases, the level of overbooking, as shown
shown in the below figure, can be classified as dedicated (such as in the below figure, can be classified as dedicated (such as 1+1 and
1+1 and 1:1), shared (such as 1:N and M:N) or unprotected (and thus 1:1), shared (such as 1:N and M:N), or unprotected (and thus
restorable if enough recovery resources are available). restorable, if enough recovery resources are available).
Overbooking levels: Overbooking levels:
+----- Dedicated (for instance: 1+1, 1:1, etc.) +----- Dedicated (for instance: 1+1, 1:1, etc.)
| |
| |
D.Papadimitriou et al. - Expires October 2005 19
+----- Shared (for instance: 1:N, M:N, etc.) +----- Shared (for instance: 1:N, M:N, etc.)
| |
Level of | Level of |
Overbooking -----+----- Unprotected (for instance: 0:1, 0:N) Overbooking -----+----- Unprotected (for instance: 0:1, 0:N)
Also, when using shared recovery, one may support preemptible extra- Also, when using shared recovery, one may support preemptible extra-
traffic; the recovery mechanism is then expected to allow preemption traffic; the recovery mechanism is then expected to allow preemption
of this low priority traffic in case of recovery resource contention of this low priority traffic in case of recovery resource contention
during recovery operations. The following sections will consider the during recovery operations. The following sections will consider the
above-mentioned overbooking options when analyzing the different above-mentioned overbooking options when analyzing the different
recovery mechanisms. recovery mechanisms.
5.5.2 LSP Restoration 5.5.2. LSP Restoration
The following times are defined to provide a quantitative estimation The following times are defined to provide a quantitative estimation
about the time performance of the different LSP restoration about the time performance of the different LSP restoration
mechanisms (also referred to as LSP re-routing): mechanisms (also referred to as LSP re-routing):
- Path Computation Time: Tc - Path Computation Time: Tc
- Path Selection Time: Ts - Path Selection Time: Ts
- End-to-end LSP Resource Reservation Time: Tr (a delta for resource - End-to-end LSP Resource Reservation Time: Tr (a delta for resource
selection is also considered, the corresponding total time is then selection is also considered, the corresponding total time is then
referred to as Trs) referred to as Trs)
- End-to-end LSP Resource Activation Time: Ta (a delta for - End-to-end LSP Resource Activation Time: Ta (a delta for
resource selection is also considered, the corresponding total resource selection is also considered, the corresponding total
time is then referred to as Tas) time is then referred to as Tas)
The Path Selection Time (Ts) is considered when a pool of recovery The Path Selection Time (Ts) is considered when a pool of recovery
LSP paths between a given pair of source/destination end-points is LSP paths between a given pair of source/destination end-points is
pre-computed and after a failure occurrence one of these paths is pre-computed, and after a failure occurrence one of these paths is
selected for the recovery of the LSP under failure condition. selected for the recovery of the LSP under failure condition.
Note: failure management operations such as failure detection, Note: failure management operations such as failure detection,
correlation and notification are considered (for a given failure correlation, and notification are considered (for a given failure
event) as equally time consuming for all the mechanisms described event) as equally time-consuming for all the mechanisms described
here below: below:
1. With Route Pre-computation (or LSP re-provisioning) 1. With Route Pre-computation (or LSP re-provisioning)
An end-to-end restoration LSP is established after the failure(s) An end-to-end restoration LSP is established after the failure(s)
occur(s) based on a pre-computed path. As such, one can define this occur(s) based on a pre-computed path. As such, one can define this
as an "LSP re-provisioning" mechanism. Here, one or more (disjoint) as an "LSP re-provisioning" mechanism. Here, one or more (disjoint)
paths for the restoration LSP are computed (and optionally pre- paths for the restoration LSP are computed (and optionally pre-
selected) before a failure occurs. selected) before a failure occurs.
No reservation or selection of resources is performed along the No reservation or selection of resources is performed along the
restoration path before failure occurrence. As a result, there is no restoration path before failure occurrence. As a result, there is no
guarantee that a restoration LSP is available when a failure occurs. guarantee that a restoration LSP is available when a failure occurs.
The expected total restoration time T is thus equal to Ts + Trs or The expected total restoration time T is thus equal to Ts + Trs or to
to Trs when a dedicated computation is performed for each working Trs when a dedicated computation is performed for each working LSP.
LSP.
D.Papadimitriou et al. - Expires October 2005 20
2. Without Route Pre-computation (or Full LSP re-routing) 2. Without Route Pre-computation (or Full LSP re-routing)
An end-to-end restoration LSP is dynamically established after the An end-to-end restoration LSP is dynamically established after the
failure(s) occur(s). Here, after failure occurrence, one or more failure(s) occur(s). After failure occurrence, one or more
(disjoint) paths for the restoration LSP are dynamically computed (disjoint) paths for the restoration LSP are dynamically computed and
and one is selected. As such, one can define this as a complete "LSP one is selected. As such, one can define this as a complete "LSP
re-routing" mechanism. re-routing" mechanism.
No reservation or selection of resources is performed along the No reservation or selection of resources is performed along the
restoration path before failure occurrence. As a result, there is no restoration path before failure occurrence. As a result, there is no
guarantee that a restoration LSP is available when a failure occurs. guarantee that a restoration LSP is available when a failure occurs.
The expected total restoration time T is thus equal to Tc (+ Ts) + The expected total restoration time T is thus equal to Tc (+ Ts) +
Trs. Therefore, time performance between these two approaches Trs. Therefore, time performance between these two approaches
differs by the time required for route computation Tc (and its differs by the time required for route computation Tc (and its
potential selection time, Ts). potential selection time, Ts).
5.5.3 Pre-planned LSP Restoration 5.5.3. Pre-Planned LSP Restoration
Pre-planned LSP restoration (also referred to as pre-planned LSP re- Pre-planned LSP restoration (also referred to as pre-planned LSP re-
routing) implies that the restoration LSP is pre-signaled. This in routing) implies that the restoration LSP is pre-signaled. This in
turn implies the reservation of recovery resources along the turn implies the reservation of recovery resources along the
restoration path. Two cases can be defined based on whether the restoration path. Two cases can be defined based on whether the
recovery resources are pre-selected or not. recovery resources are pre-selected.
1. With resource reservation and without resource pre-selection 1. With resource reservation and without resource pre-selection
Before failure occurrence, an end-to-end restoration path is pre- Before failure occurrence, an end-to-end restoration path is pre-
selected from a set of pre-computed (disjoint) paths. The selected from a set of pre-computed (disjoint) paths. The
restoration LSP is signaled along this pre-selected path to reserve restoration LSP is signaled along this pre-selected path to reserve
resources at each node but these resources are not selected. resources at each node, but these resources are not selected.
In this case, the resources reserved for each restoration LSP may be In this case, the resources reserved for each restoration LSP may be
dedicated or shared between multiple restoration LSPs whose working dedicated or shared between multiple restoration LSPs whose working
LSPs are not expected to fail simultaneously. Local node policies LSPs are not expected to fail simultaneously. Local node policies
can be applied to define the degree to which these resources can be can be applied to define the degree to which these resources can be
shared across independent failures. Also, since a restoration scheme shared across independent failures. Also, since a restoration scheme
is considered, resource sharing should not be limited to restoration is considered, resource sharing should not be limited to restoration
LSPs starting and ending at the same ingress and egress nodes. LSPs that start and end at the same ingress and egress nodes.
Therefore, each node participating to this scheme is expected to Therefore, each node participating in this scheme is expected to
receive some feedback information on the sharing degree of the receive some feedback information on the sharing degree of the
recovery resource(s) that this scheme involves. recovery resource(s) that this scheme involves.
Upon failure detection/notification message reception, signaling is Upon failure detection/notification message reception, signaling is
initiated along the restoration path to select the resources, and to initiated along the restoration path to select the resources, and to
perform the appropriate operation at each node crossed by the perform the appropriate operation at each node crossed by the
restoration LSP (e.g. cross-connections). If lower priority LSPs restoration LSP (e.g., cross-connections). If lower priority LSPs
were established using the restoration resources, they must be were established using the restoration resources, they must be
preempted when the restoration LSP is activated. preempted when the restoration LSP is activated.
D.Papadimitriou et al. - Expires October 2005 21 Thus, the expected total restoration time T is equal to Tas (post-
The expected total restoration time T is thus equal to Tas (post- failure activation), while operations performed before failure
failure activation) while operations performed before failure occurrence take Tc + Ts + Tr.
occurrence takes Tc + Ts + Tr.
2. With both resource reservation and resource pre-selection 2. With both resource reservation and resource pre-selection
Before failure occurrence, an end-to-end restoration path is pre- Before failure occurrence, an end-to-end restoration path is pre-
selected from a set of pre-computed (disjoint) paths. The selected from a set of pre-computed (disjoint) paths. The
restoration LSP is signaled along this pre-selected path to reserve restoration LSP is signaled along this pre-selected path to reserve
AND select resources at each node but these resources are not AND select resources at each node, but these resources are not
committed at the data plane level. Such that the selection of the committed at the data plane level. So that the selection of the
recovery resources is committed at the control plane level only, no recovery resources is committed at the control plane level only, no
cross-connections are performed along the restoration path. cross-connections are performed along the restoration path.
In this case, the resources reserved and selected for each In this case, the resources reserved and selected for each
restoration LSP may be dedicated or even shared between multiple restoration LSP may be dedicated or even shared between multiple
restoration LSPs whose associated working LSPs are not expected to restoration LSPs whose associated working LSPs are not expected to
fail simultaneously. Local node policies can be applied to define fail simultaneously. Local node policies can be applied to define
the degree to which these resources can be shared across independent the degree to which these resources can be shared across independent
failures. Also, since a restoration scheme is considered, resource failures. Also, because a restoration scheme is considered, resource
sharing should not be limited to restoration LSPs starting and sharing should not be limited to restoration LSPs that start and end
ending at the same ingress and egress nodes. Therefore, each node at the same ingress and egress nodes. Therefore, each node
participating to this scheme is expected to receive some feedback participating in this scheme is expected to receive some feedback
information on the sharing degree of the recovery resource(s) that information on the sharing degree of the recovery resource(s) that
this scheme involves. this scheme involves.
Upon failure detection/notification message reception, signaling is Upon failure detection/notification message reception, signaling is
initiated along the restoration path to activate the reserved and initiated along the restoration path to activate the reserved and
selected resources, and to perform the appropriate operation at each selected resources, and to perform the appropriate operation at each
node crossed by the restoration LSP (e.g. cross-connections). If node crossed by the restoration LSP (e.g., cross-connections). If
lower priority LSPs were established using the restoration lower priority LSPs were established using the restoration resources,
resources, they must be preempted when the restoration LSP is they must be preempted when the restoration LSP is activated.
activated.
The expected total restoration time T is thus equal to Ta (post- Thus, the expected total restoration time T is equal to Ta (post-
failure activation) while operations performed before failure failure activation), while operations performed before failure
occurrence takes Tc + Ts + Trs. Therefore, time performance between occurrence take Tc + Ts + Trs. Therefore, time performance between
these two approaches differs only by the time required for resource these two approaches differs only by the time required for resource
selection during the activation of the recovery LSP (i.e. Tas - Ta). selection during the activation of the recovery LSP (i.e., Tas - Ta).
5.5.4 LSP Segment Restoration 5.5.4. LSP Segment Restoration
The above approaches can be applied on an edge-to-edge LSP basis The above approaches can be applied on an edge-to-edge LSP basis
rather than end-to-end LSP basis (i.e. to reduce the global recovery rather than end-to-end LSP basis (i.e., to reduce the global recovery
time) by allowing the recovery of the individual LSP segments time) by allowing the recovery of the individual LSP segments
constituting the end-to-end LSP. constituting the end-to-end LSP.
Also, by using the horizontal hierarchy approach described in Also, by using the horizontal hierarchy approach described in Section
Section 7.1, an end-to-end LSP can be recovered by multiple recovery 7.1, an end-to-end LSP can be recovered by multiple recovery
mechanisms applied on an LSP segment basis (e.g. 1:1 edge-to-edge mechanisms applied on an LSP segment basis (e.g., 1:1 edge-to-edge
LSP protection in a metro network and M:N edge-to-edge protection in LSP protection in a metro network, and M:N edge-to-edge protection in
the core). These mechanisms are ideally independent and may even use the core). These mechanisms are ideally independent and may even use
different failure localization and notification mechanisms. different failure localization and notification mechanisms.
D.Papadimitriou et al. - Expires October 2005 22
6. Reversion 6. Reversion
Reversion (a.k.a. normalization) is defined as the mechanism Reversion (a.k.a. normalization) is defined as the mechanism allowing
allowing switching of normal traffic from the recovery LSP/span to switching of normal traffic from the recovery LSP/span to the working
the working LSP/span previously under failure condition. Use of LSP/span previously under failure condition. Use of normalization is
normalization is at the discretion of the recovery domain policy. at the discretion of the recovery domain policy. Normalization may
Normalization (also referred to as reversion) may impact the normal impact the normal traffic (a second hit) depending on the
traffic (a second hit) depending on the normalization mechanism normalization mechanism used.
used.
If normalization is supported 1) the LSP/span must be returned to If normalization is supported, then 1) the LSP/span must be returned
the working LSP/span when the failure condition clears 2) the to the working LSP/span when the failure condition clears and 2) the
capability to de-activate (turn-off) the use of reversion should be capability to de-activate (turn-off) the use of reversion should be
provided. De-activation of reversion should not impact the normal provided. De-activation of reversion should not impact the normal
traffic regardless of whether currently using the working or traffic, regardless of whether it is currently using the working or
recovery LSP/span. recovery LSP/span.
Note: during the failure, the reuse of any non-failed resources Note: during the failure, the reuse of any non-failed resources
(e.g. LSP and/or spans) belonging to the working LSP/span is under (e.g., LSP and/or spans) belonging to the working LSP/span is under
the discretion of recovery domain policy. the discretion of recovery domain policy.
6.1 Wait-To-Restore (WTR) 6.1. Wait-To-Restore (WTR)
A specific mechanism (Wait-To-Restore) is used to prevent frequent A specific mechanism (Wait-To-Restore) is used to prevent frequent
recovery switching operations due to an intermittent defect (e.g. recovery switching operations due to an intermittent defect (e.g.,
BER fluctuating around the SD threshold). Bit Error Rate (BER) fluctuating around the SD threshold).
First, an LSP/span under failure condition must become fault-free, First, an LSP/span under failure condition must become fault-free,
e.g. a BER less than a certain recovery threshold. After the e.g., a BER less than a certain recovery threshold. After the
recovered LSP/span (i.e. the previously working LSP/span) meets this recovered LSP/span (i.e., the previously working LSP/span) meets this
criterion, a fixed period of time shall elapse before normal traffic criterion, a fixed period of time shall elapse before normal traffic
uses the corresponding resources again. This duration called Wait- uses the corresponding resources again. This duration called Wait-
To-Restore (WTR) period or timer is generally of the order of a few To-Restore (WTR) period or timer is generally on the order of a few
minutes (for instance, 5 minutes) and should be capable of being minutes (for instance, 5 minutes) and should be capable of being set.
set. The WTR timer may be either a fixed period, or provide for The WTR timer may be either a fixed period, or provide for
incrementally longer periods before retrying. An SF or SD condition incrementally longer periods before retrying. An SF or SD condition
on the previously working LSP/span will override the WTR timer value on the previously working LSP/span will override the WTR timer value
(i.e. the WTR cancels and the WTR timer will restart). (i.e., the WTR cancels and the WTR timer will restart).
6.2 Revertive Mode Operation 6.2. Revertive Mode Operation
In revertive mode of operation, when the recovery LSP/span is no In revertive mode of operation, when the recovery LSP/span is no
longer required, i.e. the failed working LSP/span is no longer in SD longer required, i.e., the failed working LSP/span is no longer in SD
or SF condition, a local Wait-to-Restore (WTR) state will be or SF condition, a local Wait-to-Restore (WTR) state will be
activated before switching the normal traffic back to the recovered activated before switching the normal traffic back to the recovered
working LSP/span. working LSP/span.
During the reversion operation, since this state becomes the highest During the reversion operation, since this state becomes the highest
in priority, signalling must maintain the normal traffic on the in priority, signaling must maintain the normal traffic on the
recovery LSP/span from the previously failed working LSP/span. recovery LSP/span from the previously failed working LSP/span.
Moreover, during this WTR state, any null traffic or extra traffic Moreover, during this WTR state, any null traffic or extra traffic
(if applicable) request is rejected. (if applicable) request is rejected.
D.Papadimitriou et al. - Expires October 2005 23 However, deactivation (cancellation) of the wait-to-restore timer may
However, deactivation (cancellation) of the wait-to-restore timer occur if there are higher priority request attempts. That is, the
may occur in case of higher priority request attempts. That is the
recovery LSP/span usage by the normal traffic may be preempted if a recovery LSP/span usage by the normal traffic may be preempted if a
higher priority request for this recovery LSP/span is attempted. higher priority request for this recovery LSP/span is attempted.
6.3 Orphans 6.3. Orphans
When a reversion operation is requested normal traffic must be When a reversion operation is requested, normal traffic must be
switched from the recovery to the recovered working LSP/span. A switched from the recovery to the recovered working LSP/span. A
particular situation occurs when the previously working LSP/span particular situation occurs when the previously working LSP/span
cannot be recovered such that normal traffic can not be switched cannot be recovered, so normal traffic cannot be switched back. In
back. In such a case, the LSP/span under failure condition (also that case, the LSP/span under failure condition (also referred to as
referred to as "orphan") must be cleared i.e. removed from the pool "orphan") must be cleared (i.e., removed) from the pool of resources
of resources allocated for normal traffic. Otherwise, potential de- allocated for normal traffic. Otherwise, potential de-
synchronization between the control and transport plane resource synchronization between the control and transport plane resource
usage can appear. Depending on the signalling protocol capabilities usage can appear. Depending on the signaling protocol capabilities
and behavior different mechanisms are expected here. and behavior, different mechanisms are expected here.
Therefore any reserved or allocated resources for the LSP/span under Therefore, any reserved or allocated resources for the LSP/span under
failure condition must be unreserved/de-allocated. Several ways can failure condition must be unreserved/de-allocated. Several ways can
be used for that purpose: either wait for the elapsing of the clear- be used for that purpose: wait for the clear-out time interval to
out time interval, or initiate a deletion from the ingress or the elapse, initiate a deletion from the ingress or the egress node, or
egress node, or trigger the initiation of deletion from an entity trigger the initiation of deletion from an entity (such as an EMS or
(such as an EMS or NMS) capable to react on the reception of an NMS) capable of reacting upon reception of an appropriate
appropriate notification message. notification message.
7. Hierarchies 7. Hierarchies
Recovery mechanisms are being made available at multiple (if not Recovery mechanisms are being made available at multiple (if not all)
each) transport layers within so-called "IP/MPLS-over-optical" transport layers within so-called "IP/MPLS-over-optical" networks.
networks. However, each layer has certain recovery features and one However, each layer has certain recovery features, and one needs to
needs to determine the exact impact of the interaction between the determine the exact impact of the interaction between the recovery
recovery mechanisms provided by these layers. mechanisms provided by these layers.
Hierarchies are used to build scalable complex systems. Abstraction
is used as a mechanism to build large networks or as a technique for
enforcing technology, topological or administrative boundaries by
hiding the internal details. The same hierarchical concept can be
applied to control the network survivability. Network survivability
is the set of capabilities that allow a network to restore affected
traffic in the event of a failure. Network survivability is defined
further in [TERM]. In general, it is expected that the recovery
action is taken by the recoverable LSP/span closest to the failure
in order to avoid the multiplication of recovery actions. Moreover,
recovery hierarchies can be also bound to control plane logical
partitions (e.g. administrative or topological boundaries). Each of
them may apply different recovery mechanisms.
In brief, the commonly accepted ideas are generally that the lower Hierarchies are used to build scalable complex systems. By hiding
layers can provide coarse but faster recovery while the higher the internal details, abstraction is used as a mechanism to build
layers can provide finer but slower recovery. Moreover, it is also large networks or as a technique for enforcing technology,
desirable to avoid similar layers with functional overlaps to topological, or administrative boundaries. The same hierarchical
concept can be applied to control the network survivability. Network
survivability is the set of capabilities that allow a network to
restore affected traffic in the event of a failure. Network
survivability is defined further in [RFC4427]. In general, it is
expected that the recovery action is taken by the recoverable
LSP/span closest to the failure in order to avoid the multiplication
of recovery actions. Moreover, recovery hierarchies also can be
bound to control plane logical partitions (e.g., administrative or
topological boundaries). Each logical partition may apply different
recovery mechanisms.
D.Papadimitriou et al. - Expires October 2005 24 In brief, it is commonly accepted that the lower layers can provide
optimize network resource utilization and processing overhead, since coarse but faster recovery while the higher layers can provide finer
repeating the same capabilities at each layer does not create any but slower recovery. Moreover, it is also desirable to avoid similar
added value for the network as a whole. In addition, even if a lower layers with functional overlaps in order to optimize network resource
layer recovery mechanism is enabled, doing so does not prevent the utilization and processing overhead, since repeating the same
additional provision of a recovery mechanism at the upper layer. The capabilities at each layer does not create any added value for the
inverse statement does not necessarily hold; that is, enabling an network as a whole. In addition, even if a lower layer recovery
upper layer recovery mechanism may prevent the use of a lower layer mechanism is enabled, it does not prevent the additional provision of
recovery mechanism. In this context, this section intends to analyze a recovery mechanism at the upper layer. The inverse statement does
these hierarchical aspects including the physical (passive) not necessarily hold; that is, enabling an upper layer recovery
layer(s). mechanism may prevent the use of a lower layer recovery mechanism.
In this context, this section analyzes these hierarchical aspects
including the physical (passive) layer(s).
7.1 Horizontal Hierarchy (Partitioning) 7.1. Horizontal Hierarchy (Partitioning)
A horizontal hierarchy is defined when partitioning a single-layer A horizontal hierarchy is defined when partitioning a single-layer
network (and its control plane) into several recovery domains. network (and its control plane) into several recovery domains.
Within a domain, the recovery scope may extend over a link (or Within a domain, the recovery scope may extend over a link (or span),
span), LSP segment or even an end-to-end LSP. Moreover, an LSP segment, or even an end-to-end LSP. Moreover, an administrative
administrative domain may consist of a single recovery domain or can domain may consist of a single recovery domain or can be partitioned
be partitioned into several smaller recovery domains. The operator into several smaller recovery domains. The operator can partition
can partition the network into recovery domains based on physical the network into recovery domains based on physical network topology,
network topology, control plane capabilities or various traffic control plane capabilities, or various traffic engineering
engineering constraints. constraints.
An example often addressed in the literature is the metro-core-metro An example often addressed in the literature is the metro-core-metro
application (sometimes extended to a metro-metro/core-core) within a application (sometimes extended to a metro-metro/core-core) within a
single transport layer (see Section 7.2). For such a case, an end- single transport layer (see Section 7.2). For such a case, an end-
to-end LSP is defined between the ingress and egress metro nodes, to-end LSP is defined between the ingress and egress metro nodes,
while LSP segments may be defined within the metro or core sub- while LSP segments may be defined within the metro or core sub-
networks. Each of these topological structures determines a so- networks. Each of these topological structures determines a so-
called "recovery domain" since each of the LSPs they carry can have called "recovery domain" since each of the LSPs they carry can have
its own recovery type (or even scheme). The support of multiple its own recovery type (or even scheme). The support of multiple
recovery types and schemes within a sub-network is referred to as a recovery types and schemes within a sub-network is referred to as a
multi-recovery capable domain or simply multi-recovery domain. "multi-recovery capable domain" or simply "multi-recovery domain".
7.2 Vertical Hierarchy (Layers) 7.2. Vertical Hierarchy (Layers)
It is a very challenging task to combine in a coordinated manner the It is very challenging to combine the different recovery capabilities
different recovery capabilities available across the path (i.e. available across the path (i.e., switching capable) and section
switching capable) and section layers to ensure that certain network layers to ensure that certain network survivability objectives are
survivability objectives are met for the different services met for the network-supported services.
supported by the network.
As a first analysis step, one can draw the following guidelines for As a first analysis step, one can draw the following guidelines for
a vertical coordination of the recovery mechanisms: a vertical coordination of the recovery mechanisms:
- The lower the layer the faster the notification and switching
- The higher the layer the finer the granularity of the recoverable - The lower the layer, the faster the notification and switching.
entity and therefore the granularity of the recovery resource
- The higher the layer, the finer the granularity of the recoverable
entity and therefore the granularity of the recovery resource.
Moreover, in the context of this analysis, a vertical hierarchy Moreover, in the context of this analysis, a vertical hierarchy
consists of multiple layered transport planes providing different: consists of multiple layered transport planes providing different:
- Discrete bandwidth granularities for non-packet LSPs such as OCh, - Discrete bandwidth granularities for non-packet LSPs such as OCh,
ODUk, STS_SPE/HOVC and VT_SPE/LOVC LSPs and continuous bandwidth ODUk, STS_SPE/HOVC, and VT_SPE/LOVC LSPs and continuous bandwidth
granularities for packet LSPs granularities for packet LSPs.
D.Papadimitriou et al. - Expires October 2005 25
- Potential recovery capabilities with different temporal - Potential recovery capabilities with different temporal
granularities: ranging from milliseconds to tens of seconds granularities: ranging from milliseconds to tens of seconds
Note: based on the bandwidth granularity we can determine four Note: based on the bandwidth granularity, we can determine four
classes of vertical hierarchies (1) packet over packet (2) packet classes of vertical hierarchies: (1) packet over packet, (2) packet
over circuit (3) circuit over packet and (4) circuit over circuit. over circuit, (3) circuit over packet, and (4) circuit over circuit.
Below we briefly expand on (4) only. (2) is covered in [RFC3386]. Below we briefly expand on (4) only. (2) is covered in [RFC3386]. (1)
(1) is extensively covered by the MPLS Working Group, and (3) by the is extensively covered by the MPLS Working Group, and (3) by the PWE3
PWE3 Working Group. Working Group.
In SONET/SDH environments, one typically considers the VT_SPE/LOVC In SONET/SDH environments, one typically considers the VT_SPE/LOVC
and STS SPE/HOVC as independent layers, VT_SPE/LOVC LSP using the and STS SPE/HOVC as independent layers (for example, VT_SPE/LOVC LSP
underlying STS_SPE/HOVC LSPs as links, for instance. In OTN, the uses the underlying STS_SPE/HOVC LSPs as links). In OTN, the ODUk
ODUk path layers will lie on the OCh path layer i.e. the ODUk LSPs path layers will lie on the OCh path layer, i.e., the ODUk LSPs use
using the underlying OCh LSPs as OTUk links. Note here that lower the underlying OCh LSPs as OTUk links. Note here that lower layer
layer LSPs may simply be provisioned and not necessarily dynamically LSPs may simply be provisioned and not necessarily dynamically
triggered or established (control driven approach). In this context, triggered or established (control driven approach). In this context,
an LSP at the path layer (i.e. established using GMPLS signalling), an LSP at the path layer (i.e., established using GMPLS signaling),
for instance an optical channel LSP, appears at the OTUk layer as a such as an optical channel LSP, appears at the OTUk layer as a link,
link, controlled by a link management protocol such as LMP. controlled by a link management protocol such as LMP.
The first key issue with multi-layer recovery is that achieving The first key issue with multi-layer recovery is that achieving
individual or bulk LSP recovery will be as efficient as the individual or bulk LSP recovery will be as efficient as the
underlying link (local span) recovery. In such a case, the span can underlying link (local span) recovery. In such a case, the span can
be either protected or unprotected, but the LSP it carries must be be either protected or unprotected, but the LSP it carries must be
(at least locally) recoverable. Therefore, the span recovery process (at least locally) recoverable. Therefore, the span recovery process
can be either independent when protected (or restorable), or can be either independent when protected (or restorable), or
triggered by the upper LSP recovery process. The former case triggered by the upper LSP recovery process. The former case
requires coordination to achieve subsequent LSP recovery. Therefore, requires coordination to achieve subsequent LSP recovery. Therefore,
in order to achieve robustness and fast convergence, multi-layer in order to achieve robustness and fast convergence, multi-layer
recovery requires a fine-tuned coordination mechanism. recovery requires a fine-tuned coordination mechanism.
Moreover, in the absence of adequate recovery mechanism coordination Moreover, in the absence of adequate recovery mechanism coordination
(for instance, a pre-determined coordination when using a hold-off (for instance, a pre-determined coordination when using a hold-off
timer), a failure notification may propagate from one layer to the timer), a failure notification may propagate from one layer to the
next one within a recovery hierarchy. This can cause "collisions" next one within a recovery hierarchy. This can cause "collisions"
and trigger simultaneous recovery actions that may lead to race and trigger simultaneous recovery actions that may lead to race
conditions and in turn, reduce the optimization of the resource conditions and, in turn, reduce the optimization of the resource
utilization and/or generate global instabilities in the network (see utilization and/or generate global instabilities in the network (see
[MANCHESTER]). Therefore, a consistent and efficient escalation [MANCHESTER]). Therefore, a consistent and efficient escalation
strategy is needed to coordinate recovery across several layers. strategy is needed to coordinate recovery across several layers.
Therefore, one can expect that the definition of the recovery One can expect that the definition of the recovery mechanisms and
mechanisms and protocol(s) is technology-independent such that they protocol(s) is technology-independent so that they can be
can be consistently implemented at different layers; this would in consistently implemented at different layers; this would in turn
turn simplify their global coordination. Moreover, as mentioned in simplify their global coordination. Moreover, as mentioned in
[RFC3386], some looser form of coordination and communication [RFC3386], some looser form of coordination and communication between
between (vertical) layers such a consistent hold-off timer (vertical) layers such as a consistent hold-off timer configuration
configuration (and setup through signalling during the working LSP (and setup through signaling during the working LSP establishment)
establishment) can be considered, allowing the synchronization can be considered, thereby allowing the synchronization between
between recovery actions performed across these layers. recovery actions performed across these layers.
D.Papadimitriou et al. - Expires October 2005 26
7.2.1 Recovery Granularity 7.2.1. Recovery Granularity
In most environments, the design of the network and the vertical In most environments, the design of the network and the vertical
distribution of the LSP bandwidth are such that the recovery distribution of the LSP bandwidth are such that the recovery
granularity is finer at higher layers. The OTN and SONET/SDH layers granularity is finer at higher layers. The OTN and SONET/SDH layers
can only recover the whole section or the individual connections it can recover only the whole section or the individual connections they
transports whereas the IP/MPLS control plane can recover individual transports whereas the IP/MPLS control plane can recover individual
packet LSPs or groups of packet LSPs and this independently of their packet LSPs or groups of packet LSPs independently of their
granularity. On the other side, the recovery granularity at the sub- granularity. On the other side, the recovery granularity at the
wavelength level (i.e. SONET/SDH) can be provided only when the sub-wavelength level (i.e., SONET/SDH) can be provided only when the
network includes devices switching at the same granularity (and thus network includes devices switching at the same granularity (and thus
not with optical channel level). Therefore, the network layer can not with optical channel level). Therefore, the network layer can
deliver control-plane driven recovery mechanisms on a per-LSP basis deliver control-plane-driven recovery mechanisms on a per-LSP basis
if and only if these LSPs have their corresponding switching if and only if these LSPs have their corresponding switching
granularity supported at the transport plane level. granularity supported at the transport plane level.
7.3 Escalation Strategies 7.3. Escalation Strategies
There are two types of escalation strategies (see [DEMEESTER]): There are two types of escalation strategies (see [DEMEESTER]):
bottom-up and top-down. bottom-up and top-down.
The bottom-up approach assumes that lower layer recovery types and The bottom-up approach assumes that lower layer recovery types and
schemes are more expedient and faster than the upper layer one. schemes are more expedient and faster than upper layer ones.
Therefore we can inhibit or hold-off higher layer recovery. However Therefore, we can inhibit or hold off higher layer recovery.
this assumption is not entirely true. Consider for instance a However, this assumption is not entirely true. Consider for instance
Sonet/SDH based protection mechanism (with a less than 50 ms a SONET/SDH based protection mechanism (with a protection switching
protection switching time) lying on top of an OTN restoration time of less than 50 ms) lying on top of an OTN restoration mechanism
mechanism (with a less than 200 ms restoration time). Therefore, (with a restoration time of less than 200 ms). Therefore, this
this assumption should be (at least) clarified as: lower layer assumption should be (at least) clarified as: the lower layer
recovery mechanism is expected to be faster than upper level one if recovery mechanism is expected to be faster than the upper level one,
the same type of recovery mechanism is used at each layer. if the same type of recovery mechanism is used at each layer.
Consequently, taking into account the recovery actions at the Consequently, taking into account the recovery actions at the
different layers in a bottom-up approach, if lower layer recovery different layers in a bottom-up approach: if lower layer recovery
mechanisms are provided and sequentially activated in conjunction mechanisms are provided and sequentially activated in conjunction
with higher layer ones, the lower layers must have an opportunity to with higher layer ones, the lower layers must have an opportunity to
recover normal traffic before the higher layers do. However, if recover normal traffic before the higher layers do. However, if
lower layer recovery is slower than higher layer recovery, the lower lower layer recovery is slower than higher layer recovery, the lower
layer must either communicate the failure related information to the layer must either communicate the failure-related information to the
higher layer(s) (and allow it to perform recovery), or use a hold- higher layer(s) (and allow it to perform recovery), or use a hold-off
off timer in order to temporarily set the higher layer recovery timer in order to temporarily set the higher layer recovery action in
action in a "standby mode". Note that the a priori information a "standby mode". Note that the a priori information exchange
exchange between layers concerning their efficiency is not within between layers concerning their efficiency is not within the current
the current scope of this document. Nevertheless, the coordination scope of this document. Nevertheless, the coordination functionality
functionality between layers must be configurable and tunable. between layers must be configurable and tunable.
An example of coordination between the optical and packet layer For example, coordination between the optical and packet layer
control plane enables for instance the optical layer performing the control plane enables the optical layer to perform the failure
failure management operations (in particular, failure detection and management operations (in particular, failure detection and
notification) while giving to the packet layer control plane the notification) while giving to the packet layer control plane the
authority to decide and perform the recovery actions. In case the authority to decide and perform the recovery actions. If the packet
packet layer recovery action is unsuccessful, fallback at the layer recovery action is unsuccessful, fallback at the optical layer
optical layer can be subsequently performed. can be performed subsequently.
D.Papadimitriou et al. - Expires October 2005 27
The top-down approach attempts service recovery at the higher layers The top-down approach attempts service recovery at the higher layers
before invoking lower layer recovery. Higher layer recovery is before invoking lower layer recovery. Higher layer recovery is
service selective, and permits "per-CoS" or "per-connection" re- service selective, and permits "per-CoS" or "per-connection" re-
routing. With this approach, the most important aspect is that the routing. With this approach, the most important aspect is that the
upper layer should provide its own reliable and independent failure upper layer should provide its own reliable and independent failure
detection mechanism from the lower layer. detection mechanism from the lower layer.
The same reference also suggests recovery mechanisms incorporating a [DEMEESTER] also suggests recovery mechanisms incorporating a
coordinated effort shared by two adjacent layers with periodic coordinated effort shared by two adjacent layers with periodic status
status updates. Moreover, some of these recovery operations can be updates. Moreover, some of these recovery operations can be pre-
pre-assigned (on a per-link basis) to a certain layer, e.g. a given assigned (on a per-link basis) to a certain layer, e.g., a given link
link will be recovered at the packet layer while another will be will be recovered at the packet layer while another will be recovered
recovered at the optical layer. at the optical layer.
7.4 Disjointness 7.4. Disjointness
Having link and node diverse working and recovery LSPs/spans does Having link and node diverse working and recovery LSPs/spans does not
not guarantee their complete disjointness. Due to the common guarantee their complete disjointness. Due to the common physical
physical layer topology (passive), additional hierarchical concepts layer topology (passive), additional hierarchical concepts, such as
such as the Shared Risk Link Group (SRLG) and mechanisms such as the Shared Risk Link Group (SRLG), and mechanisms, such as SRLG
SRLG diverse path computation must be developed to provide complete diverse path computation, must be developed to provide complete
working and recovery LSP/span disjointness (see [IPO-IMP] and working and recovery LSP/span disjointness (see [IPO-IMP] and
[GMPLS-RTG]). Otherwise, a failure affecting the working LSP/span [RFC4202]). Otherwise, a failure affecting the working LSP/span
would also potentially affect the recovery LSP/span; one refers to would also potentially affect the recovery LSP/span; one refers to
such an event as "common failure". such an event as "common failure".
7.4.1 SRLG Disjointness 7.4.1. SRLG Disjointness
A Shared Risk Link Group (SRLG) is defined as the set of links A Shared Risk Link Group (SRLG) is defined as the set of links
sharing a common risk (for instance, a common physical resource such sharing a common risk (such as a common physical resource such as a
as a fiber link or a fiber cable). For instance, a set of links L fiber link or a fiber cable). For instance, a set of links L belongs
belongs to the same SRLG s, if they are provisioned over the same to the same SRLG s, if they are provisioned over the same fiber link
fiber link f. f.
The SRLG properties can be summarized as follows: The SRLG properties can be summarized as follows:
1) A link belongs to more than one SRLG if and only if it crosses 1) A link belongs to more than one SRLG if and only if it crosses one
one of the resources covered by each of them. of the resources covered by each of them.
2) Two links belonging to the same SRLG can belong individually to 2) Two links belonging to the same SRLG can belong individually to
(one or more) other SRLGs. (one or more) other SRLGs.
3) The SRLG set S of an LSP is defined as the union of the 3) The SRLG set S of an LSP is defined as the union of the individual
individual SRLG s of the individual links composing this LSP. SRLG s of the individual links composing this LSP.
SRLG disjointness is also applicable to LSPs: SRLG disjointness is also applicable to LSPs:
The LSP SRLG disjointness concept is based on the following The LSP SRLG disjointness concept is based on the following
postulate: an LSP (i.e. sequence of links and nodes) covers an postulate: an LSP (i.e., a sequence of links and nodes) covers an
SRLG if and only if it crosses one of the links or nodes SRLG if and only if it crosses one of the links or nodes belonging
belonging to that SRLG. to that SRLG.
D.Papadimitriou et al. - Expires October 2005 28 Therefore, the SRLG disjointness for LSPs, can be defined as
Therefore, the SRLG disjointness for LSPs can be defined as
follows: two LSPs are disjoint with respect to an SRLG s if and follows: two LSPs are disjoint with respect to an SRLG s if and
only if they do not cover simultaneously this SRLG s. only if they do not cover simultaneously this SRLG s.
Whilst the SRLG disjointness for LSPs with respect to a set S of Whilst the SRLG disjointness for LSPs with respect to a set S of
SRLGs is defined as follows: two LSPs are disjoint with respect SRLGs, is defined as follows: two LSPs are disjoint with respect
to a set of SRLGs S if and only if the common SRLGs between the to a set of SRLGs S if and only if the set of SRLGs that are
sets of SRLGs they individually cover is disjoint from set S. common to both LSPs is disjoint from set S.
The impact on recovery is noticeable: SRLG disjointness is a The impact on recovery is noticeable: SRLG disjointness is a
necessary (but not a sufficient) condition to ensure network necessary (but not a sufficient) condition to ensure network
survivability. With respect to the physical network resources, a survivability. With respect to the physical network resources, a
working-recovery LSP/span pair must be SRLG disjoint in case of working-recovery LSP/span pair must be SRLG-disjoint in case of
dedicated recovery type. On the other hand, in case of shared dedicated recovery type. On the other hand, in case of shared
recovery, a group of working LSP/span must be mutually SRLG-disjoint recovery, a group of working LSP/spans must be mutually SRLG-disjoint
in order to allow for a (single and common) shared recovery LSP in order to allow for a (single and common) shared recovery LSP that
itself SRLG-disjoint from each of the working LSPs/spans. is itself SRLG-disjoint from each of the working LSPs/spans.
8. Recovery Mechanisms Analysis 8. Recovery Mechanisms Analysis
In order to provide a structured analysis of the recovery mechanisms In order to provide a structured analysis of the recovery mechanisms
detailed in the previous sections, the following dimensions can be detailed in the previous sections, the following dimensions can be
considered: considered:
1. Fast convergence (performance): provide a mechanism that 1. Fast convergence (performance): provide a mechanism that
aggregates multiple failures (this implies fast failure aggregates multiple failures (implying fast failure detection and
detection and correlation mechanisms) and fast recovery decision correlation mechanisms) and fast recovery decision independently
independently of the number of failures occurring in the optical of the number of failures occurring in the optical network (also
network (implying also a fast failure notification). implying a fast failure notification).
2. Efficiency (scalability): minimize the switching time required 2. Efficiency (scalability): minimize the switching time required for
for LSP/span recovery independently of the number of LSPs/spans LSP/span recovery independently of the number of LSPs/spans being
being recovered (this implies an efficient failure correlation, a recovered (this implies efficient failure correlation, fast
fast failure notification and time-efficient recovery failure notification, and time-efficient recovery mechanisms).
mechanism(s)).
3. Robustness (availability): minimize the LSP/span downtime 3. Robustness (availability): minimize the LSP/span downtime
independently of the underlying topology of the transport plane independently of the underlying topology of the transport plane
(this implies a highly responsive recovery mechanism). (this implies a highly responsive recovery mechanism).
4. Resource optimization (optimality): minimize the resource 4. Resource optimization (optimality): minimize the resource
capacity, including LSPs/spans and nodes (switching capacity), capacity, including LSPs/spans and nodes (switching capacity),
required for recovery purposes; this dimension can also be required for recovery purposes; this dimension can also be
referred to as optimizing the sharing degree of the recovery referred to as optimizing the sharing degree of the recovery
resources. resources.
5. Cost optimization: provide a cost-effective recovery type/scheme. 5. Cost optimization: provide a cost-effective recovery type/scheme.
However, these dimensions are either outside the scope of this However, these dimensions are either outside the scope of this
document such as cost optimization and recovery path computational document (such as cost optimization and recovery path computational
aspects or mutually conflicting. For instance, it is obvious that aspects) or mutually conflicting. For instance, it is obvious that
providing a 1+1 LSP protection minimizes the LSP downtime (in case providing a 1+1 LSP protection minimizes the LSP downtime (in case of
failure) while being non-scalable and consuming recovery resource
D.Papadimitriou et al. - Expires October 2005 29
of failure) while being non-scalable and consuming recovery resource
without enabling any extra-traffic. without enabling any extra-traffic.
The following sections provide an analysis of the recovery phases The following sections analyze the recovery phases and mechanisms
and mechanisms detailed in the previous sections with respect to the detailed in the previous sections with respect to the dimensions
dimensions described here above to assess the GMPLS protocol suite described above in order to assess the GMPLS protocol suite
capabilities and applicability. In turn, this allows the evaluation capabilities and applicability. In turn, this allows the evaluation
of the potential need for further GMPLS signaling and routing of the potential need for further GMPLS signaling and routing
extensions. extensions.
8.1 Fast Convergence (Detection/Correlation and Hold-off Time) 8.1. Fast Convergence (Detection/Correlation and Hold-off Time)
Fast convergence is related to the failure management operations. It Fast convergence is related to the failure management operations. It
refers to the elapsing time between the failure detection/ refers to the time elapsed between failure detection/correlation and
correlation and hold-off time, point at which the recovery switching hold-off time, the point at which the recovery switching actions are
actions are initiated. This point has been detailed in Section 4. initiated. This point has been detailed in Section 4.
8.2 Efficiency (Recovery Switching Time) 8.2. Efficiency (Recovery Switching Time)
In general, the more pre-assignment/pre-planning of the recovery In general, the more pre-assignment/pre-planning of the recovery
LSP/span, the more rapid the recovery is. Since protection implies LSP/span, the more rapid the recovery is. Because protection implies
pre-assignment (and cross-connection) of the protection resources, pre-assignment (and cross-connection) of the protection resources, in
in general, protection recover faster than restoration. general, protection recovers faster than restoration.
Span restoration is likely to be slower than most span protection Span restoration is likely to be slower than most span protection
types; however this greatly depends on the efficiency of the span types; however this greatly depends on the efficiency of the span
restoration signalling. LSP restoration with pre-signaled and pre- restoration signaling. LSP restoration with pre-signaled and pre-
selected recovery resources is likely to be faster than fully selected recovery resources is likely to be faster than fully dynamic
dynamic LSP restoration, especially because of the elimination of LSP restoration, especially because of the elimination of any
any potential crankback during the recovery LSP establishment. potential crankback during the recovery LSP establishment.
If one excludes the crankback issue, the difference between dynamic If one excludes the crankback issue, the difference between dynamic
and pre-planned restoration depends on the restoration path and pre-planned restoration depends on the restoration path
computation and selection time. Since computational considerations computation and selection time. Since computational considerations
are outside the scope of this document, it is up to the vendor to are outside the scope of this document, it is up to the vendor to
determine the average and maximum path computation time in different determine the average and maximum path computation time in different
scenarios and to the operator to decide whether or not dynamic scenarios and to the operator to decide whether or not dynamic
restoration is advantageous over pre-planned schemes depending on restoration is advantageous over pre-planned schemes that depend on
the network environment. This difference depends also on the the network environment. This difference also depends on the
flexibility provided by pre-planned restoration versus dynamic flexibility provided by pre-planned restoration versus dynamic
restoration: the former implies a somewhat limited number of failure restoration. Pre-planned restoration implies a somewhat limited
scenarios (that can be due, for instance, to local storage capacity number of failure scenarios (that can be due, for instance, to local
limitation). The latter enables on-demand path computation based on storage capacity limitation). Dynamic restoration enables on-demand
the information received through failure notification message and as path computation based on the information received through failure
such is more robust with respect to the failure scenario scope. notification message, and as such, it is more robust with respect to
the failure scenario scope.
Moreover, LSP segment restoration, in particular, dynamic Moreover, LSP segment restoration, in particular, dynamic restoration
restoration (i.e. no path pre-computation so none of the recovery (i.e., no path pre-computation, so none of the recovery resource is
resource is pre-reserved) will generally be faster than end-to-end pre-reserved) will generally be faster than end-to-end LSP
LSP restoration. However, local LSP restoration assumes that each restoration. However, local LSP restoration assumes that each LSP
LSP segment end-point has enough computational capacity to perform segment end-point has enough computational capacity to perform this
this operation while end-to-end LSP restoration requires only that operation while end-to-end LSP restoration requires only that LSP
LSP end-points provides this path computation capability. end-points provide this path computation capability.
D.Papadimitriou et al. - Expires October 2005 30
Recovery time objectives for SONET/SDH protection switching (not Recovery time objectives for SONET/SDH protection switching (not
including time to detect failure) are specified in [G.841] at 50 ms, including time to detect failure) are specified in [G.841] at 50 ms,
taking into account constraints on distance, number of connections taking into account constraints on distance, number of connections
involved, and in the case of ring enhanced protection, number of involved, and in the case of ring enhanced protection, number of
nodes in the ring. Recovery time objectives for restoration nodes in the ring. Recovery time objectives for restoration
mechanisms have been proposed through a separate effort [RFC3386]. mechanisms have been proposed through a separate effort [RFC3386].
8.3 Robustness 8.3. Robustness
In general, the less pre-assignment (protection)/pre-planning In general, the less pre-assignment (protection)/pre-planning
(restoration) of the recovery LSP/span, the more robust the recovery (restoration) of the recovery LSP/span, the more robust the recovery
type or scheme is to a variety of single failures, provided that type or scheme is to a variety of single failures, provided that
adequate resources are available. Moreover, the pre-selection of the adequate resources are available. Moreover, the pre-selection of the
recovery resources gives in the case of multiple failure scenarios recovery resources gives (in the case of multiple failure scenarios)
less flexibility than no recovery resource pre-selection. For less flexibility than no recovery resource pre-selection. For
instance, if failures occur that affect two LSPs sharing a common instance, if failures occur that affect two LSPs sharing a common
link along their restoration paths, then only one of these LSPs can link along their restoration paths, then only one of these LSPs can
be recovered. This occurs unless the restoration path of at least be recovered. This occurs unless the restoration path of at least
one of these LSPs is re-computed or the local resource assignment is one of these LSPs is re-computed, or the local resource assignment is
modified on the fly. modified on the fly.
In addition, recovery types and schemes with pre-planned recovery In addition, recovery types and schemes with pre-planned recovery
resources, in particular LSP/spans for protection and LSPs for resources (in particular, LSP/spans for protection and LSPs for
restoration purposes, will not be able to recover from failures that restoration purposes) will not be able to recover from failures that
simultaneously affect both the working and recovery LSP/span. Thus, simultaneously affect both the working and recovery LSP/span. Thus,
the recovery resources should ideally be as disjoint as possible the recovery resources should ideally be as disjoint as possible
(with respect to link, node and SRLG) from the working ones, so that (with respect to link, node, and SRLG) from the working ones, so that
any single failure event will not affect both working and recovery any single failure event will not affect both working and recovery
LSP/span. In brief, working and recovery resource must be fully LSP/span. In brief, working and recovery resources must be fully
diverse in order to guarantee that a given failure will not affect diverse in order to guarantee that a given failure will not affect
simultaneously the working and the recovery LSP/span. Also, the risk simultaneously the working and the recovery LSP/span. Also, the risk
of simultaneous failure of the working and the recovery LSP can be of simultaneous failure of the working and the recovery LSPs can be
reduced. This, by computing a new recovery path whenever a failure reduced. It is reduced by computing a new recovery path whenever a
occurs along one of the recovery LSPs or by computing a new recovery failure occurs along one of the recovery LSPs or by computing a new
path and provision the corresponding LSP whenever a failure occurs recovery path and provision the corresponding LSP whenever a failure
along a working LSP/span. Both methods enable the network to occurs along a working LSP/span. Both methods enable the network to
maintain the number of available recovery path constant. maintain the number of available recovery path constant.
The robustness of a recovery scheme is also determined by the amount The robustness of a recovery scheme is also determined by the amount
of pre-reserved (i.e. signaled) recovery resources within a given of pre-reserved (i.e., signaled) recovery resources within a given
shared resource pool: as the sharing degree of recovery resources shared resource pool: as the sharing degree of recovery resources
increases, the recovery scheme becomes less robust to multiple increases, the recovery scheme becomes less robust to multiple
LSP/span failure occurrences. Recovery schemes, in particular LSP/span failure occurrences. Recovery schemes, in particular
restoration, with pre-signaled resource reservation (with or without restoration, with pre-signaled resource reservation (with or without
pre-selection) should be capable to reserve the adequate amount of pre-selection) should be capable of reserving an adequate amount of
resource to ensure recovery from any specific set of failure events, resource to ensure recovery from any specific set of failure events,
such as any single SRLG failure, any two SRLG failures etc. such as any single SRLG failure, any two SRLG failures, etc.
8.4 Resource Optimization 8.4. Resource Optimization
It is commonly admitted that sharing recovery resources provides It is commonly admitted that sharing recovery resources provides
network resource optimization. Therefore, from a resource network resource optimization. Therefore, from a resource
utilization perspective, protection schemes are often classified with
respect to their degree of sharing recovery resources with the
working entities. Moreover, non-permanent bridging protection types
allow (under normal conditions) for extra-traffic over the recovery
resources.
D.Papadimitriou et al. - Expires October 2005 31 From this perspective, the following statements are true:
utilization perspective, protection schemes are often classified
with respect to their degree of sharing recovery resources with
respect to the working entities. Moreover, non-permanent bridging
protection types allow (under normal conditions) for extra-traffic
over the recovery resources.
From this perspective 1) 1+1 LSP/Span protection is the most 1) 1+1 LSP/Span protection is the most resource-consuming protection
resource consuming protection type since not allowing for any extra- type because it does not allow for any extra traffic.
traffic 2) 1:1 LSP/span recovery requires dedicated recovery
LSP/span allowing for extra-traffic 3) 1:N and M:N LSP/span recovery 2) 1:1 LSP/span recovery requires dedicated recovery LSP/span
require 1 (M, respectively) recovery LSP/span (shared between the N allowing for extra traffic.
working LSP/span) allowing for extra-traffic. Obviously, 1+1
protection precludes and 1:1 recovery does not allow for any 3) 1:N and M:N LSP/span recovery require 1 (and M, respectively)
recovery LSP/span sharing whereas 1:N and M:N recovery do allow recovery LSP/span (shared between the N working LSP/span) allowing
sharing of 1 (M, respectively) recovery LSP/spans between N working for extra traffic.
LSP/spans. However, despite the fact that 1:1 LSP recovery precludes
the sharing of the recovery LSP, the recovery schemes (see Section Obviously, 1+1 protection precludes, and 1:1 recovery does not allow
5.4) that can be built from it (e.g. (1:1)^n) do allow sharing of for any recovery LSP/span sharing, whereas 1:N and M:N recovery do
its recovery resources. In addition, the flexibility in the usage of allow sharing of 1 (M, respectively) recovery LSP/spans between N
shared recovery resources (in particular, shared links) may be working LSP/spans. However, despite the fact that 1:1 LSP recovery
limited because of network topology restrictions, e.g. fixed ring precludes the sharing of the recovery LSP, the recovery schemes that
topology for traditional enhanced protection schemes. can be built from it (e.g., (1:1)^n, see Section 5.4) do allow
sharing of its recovery resources. In addition, the flexibility in
the usage of shared recovery resources (in particular, shared links)
may be limited because of network topology restrictions, e.g., fixed
ring topology for traditional enhanced protection schemes.
On the other hand, when using LSP restoration with pre-signaled On the other hand, when using LSP restoration with pre-signaled
resource reservation, the amount of reserved restoration capacity is resource reservation, the amount of reserved restoration capacity is
determined by the local bandwidth reservation policies. In LSP determined by the local bandwidth reservation policies. In LSP
restoration schemes with re-provisioning, a pool of spare resources restoration schemes with re-provisioning, a pool of spare resources
can be defined from which all resources are selected after failure can be defined from which all resources are selected after failure
occurrence for the purpose of restoration path computation. The occurrence for the purpose of restoration path computation. The
degree to which restoration schemes allow sharing amongst multiple degree to which restoration schemes allow sharing amongst multiple
independent failures is then directly inferred from the size of the independent failures is then directly inferred from the size of the
resource pool. Moreover, in all restoration schemes, spare resources resource pool. Moreover, in all restoration schemes, spare resources
can be used to carry preemptible traffic (thus over preemptible can be used to carry preemptible traffic (thus over preemptible
LSP/span) when the corresponding resources have not been committed LSP/span) when the corresponding resources have not been committed
for LSP/span recovery purposes. for LSP/span recovery purposes.
From this, it clearly follows that less recovery resources (i.e. From this, it clearly follows that less recovery resources (i.e.,
LSP/spans and switching capacity) have to be allocated to a shared LSP/spans and switching capacity) have to be allocated to a shared
recovery resource pool if a greater sharing degree is allowed. Thus, recovery resource pool if a greater sharing degree is allowed. Thus,
the network survivability level is determined by the policy that the network survivability level is determined by the policy that
defines the amount of shared recovery resources and by the maximum defines the amount of shared recovery resources and by the maximum
sharing degree allowed for these recovery resources. sharing degree allowed for these recovery resources.
8.4.1. Recovery Resource Sharing 8.4.1. Recovery Resource Sharing
When recovery resources are shared over several LSP/Spans, the use When recovery resources are shared over several LSP/Spans, the use of
of the Maximum Reservable Bandwidth, the Unreserved Bandwidth and the Maximum Reservable Bandwidth, the Unreserved Bandwidth, and the
the Maximum LSP Bandwidth (see [GMPLS-RTG]) provides the information Maximum LSP Bandwidth (see [RFC4202]) provides the information needed
needed to obtain the optimization of the network resources allocated to obtain the optimization of the network resources allocated for
for shared recovery purposes. shared recovery purposes.
The Maximum Reservable Bandwidth is defined as the Maximum Link The Maximum Reservable Bandwidth is defined as the Maximum Link
Bandwidth but it may be greater in case of link over-subscription. Bandwidth but it may be greater in case of link over-subscription.
D.Papadimitriou et al. - Expires October 2005 32
The Unreserved Bandwidth (at priority p) is defined as the bandwidth The Unreserved Bandwidth (at priority p) is defined as the bandwidth
not yet reserved on a given TE link (its initial value for each not yet reserved on a given TE link (its initial value for each
priority p corresponds to the Maximum Reservable Bandwidth). Last, priority p corresponds to the Maximum Reservable Bandwidth). Last,
the Maximum LSP Bandwidth (at priority p) is defined as the smaller the Maximum LSP Bandwidth (at priority p) is defined as the smaller
of Unreserved Bandwidth (at priority p) and Maximum Link Bandwidth. of Unreserved Bandwidth (at priority p) and Maximum Link Bandwidth.
Here, one generally considers a recovery resource sharing degree (or Here, one generally considers a recovery resource sharing degree (or
ratio) to globally optimize the shared recovery resource usage. The ratio) to globally optimize the shared recovery resource usage. The
distribution of the bandwidth utilization per TE link can be distribution of the bandwidth utilization per TE link can be inferred
inferred from the per-priority bandwidth pre-allocation. By using from the per-priority bandwidth pre-allocation. By using the Maximum
the Maximum LSP Bandwidth and the Maximum Reservable Bandwidth, the LSP Bandwidth and the Maximum Reservable Bandwidth, the amount of
amount of (over-provisioned) resources that can be used for shared (over-provisioned) resources that can be used for shared recovery
recovery purposes is known from the IGP. purposes is known from the IGP.
In order to analyze this behavior, we define the difference between In order to analyze this behavior, we define the difference between
the Maximum Reservable Bandwidth (in the present case, this value is the Maximum Reservable Bandwidth (in the present case, this value is
greater than the Maximum Link Bandwidth) and the Maximum LSP greater than the Maximum Link Bandwidth) and the Maximum LSP
Bandwidth per TE link i as the Maximum Shareable Bandwidth or Bandwidth per TE link i as the Maximum Shareable Bandwidth or
max_R[i]. Within this quantity, the amount of bandwidth currently max_R[i]. Within this quantity, the amount of bandwidth currently
allocated for shared recovery per TE link i is defined as R[i]. Both allocated for shared recovery per TE link i is defined as R[i]. Both
quantities are expressed in terms of discrete bandwidth units (and quantities are expressed in terms of discrete bandwidth units (and
thus, the Minimum LSP Bandwidth is of one bandwidth unit). thus, the Minimum LSP Bandwidth is of one bandwidth unit).
skipping to change at line 1763 skipping to change at page 38, line 4
thus, the Minimum LSP Bandwidth is of one bandwidth unit). thus, the Minimum LSP Bandwidth is of one bandwidth unit).
The knowledge of this information available per TE link can be The knowledge of this information available per TE link can be
exploited in order to optimize the usage of the resources allocated exploited in order to optimize the usage of the resources allocated
per TE link for shared recovery. If one refers to r[i] as the actual per TE link for shared recovery. If one refers to r[i] as the actual
bandwidth per TE link i (in terms of discrete bandwidth units) bandwidth per TE link i (in terms of discrete bandwidth units)
committed for shared recovery, then the following quantity must be committed for shared recovery, then the following quantity must be
maximized over the potential TE link candidates: maximized over the potential TE link candidates:
sum {i=1}^N [(R{i} - r{i})/(t{i} - b{i})] sum {i=1}^N [(R{i} - r{i})/(t{i} - b{i})]
or equivalently: sum {i=1}^N [(R{i} - r{i})/r{i}] or equivalently: sum {i=1}^N [(R{i} - r{i})/r{i}]
with R{i} >= 1 and r{i} >= 1 (in terms of per component with R{i} >= 1 and r{i} >= 1 (in terms of per component
bandwidth unit) bandwidth unit)
In this formula, N is the total number of links traversed by a given In this formula, N is the total number of links traversed by a given
LSP, t[i] the Maximum Link Bandwidth per TE link i and b[i] the sum LSP, t[i] the Maximum Link Bandwidth per TE link i, and b[i] the sum
per TE link i of the bandwidth committed for working LSPs and other per TE link i of the bandwidth committed for working LSPs and other
recovery LSPs (thus except "shared bandwidth" LSPs). The quantity recovery LSPs (thus except "shared bandwidth" LSPs). The quantity
[(R{i} - r{i})/r{i}] is defined as the Shared (Recovery) Bandwidth [(R{i} - r{i})/r{i}] is defined as the Shared (Recovery) Bandwidth
Ratio per TE link i. In addition, TE links for which R[i] reaches Ratio per TE link i. In addition, TE links for which R[i] reaches
max_R[i] or for which r[i] = 0 are pruned during shared recovery max_R[i] or for which r[i] = 0 are pruned during shared recovery path
path computation as well as TE links for which max_R[i] = r[i] which computation as well as TE links for which max_R[i] = r[i] that can
can simply not be shared. simply not be shared.
More generally, one can draw the following mapping between the More generally, one can draw the following mapping between the
available bandwidth at the transport and control plane level: available bandwidth at the transport and control plane level:
- ---------- Max Reservable Bandwidth - ---------- Max Reservable Bandwidth
| ----- ^ | ----- ^
|R ----- | |R ----- |
D.Papadimitriou et al. - Expires October 2005 33
| ----- | | ----- |
- ----- |max_R - ----- |max_R
----- | ----- |
-------- TE link Capacity - ------ | - Maximum TE Link Bandwidth -------- TE link Capacity - ------ | - Maximum TE Link Bandwidth
----- |r ----- v ----- |r ----- v
----- <------ b ------> - ---------- Maximum LSP Bandwidth ----- <------ b ------> - ---------- Maximum LSP Bandwidth
----- ----- ----- -----
----- ----- ----- -----
----- ----- ----- -----
----- ----- ----- -----
----- ----- <--- Minimum LSP Bandwidth ----- ----- <--- Minimum LSP Bandwidth
-------- 0 ---------- 0 -------- 0 ---------- 0
Note that the above approach does not require the flooding of any Note that the above approach does not require the flooding of any per
per LSP information or any detailed distribution of the bandwidth LSP information or any detailed distribution of the bandwidth
allocation per component link or individual ports or even any per- allocation per component link or individual ports or even any per-
priority shareable recovery bandwidth information (using a dedicated priority shareable recovery bandwidth information (using a dedicated
sub-TLV). The latter would provide the same capability than the sub-TLV). The latter would provide the same capability as the
already defined Maximum LSP bandwidth per-priority information. Such already defined Maximum LSP bandwidth per-priority information. This
approach is referred to as a Partial (or Aggregated) Information approach is referred to as a Partial (or Aggregated) Information
Routing as described for instance in [KODIALAM1] and [KODIALAM2]. Routing as described in [KODIALAM1] and [KODIALAM2]. They show that
They show that the difference obtained with a Full (or Complete) the difference obtained with a Full (or Complete) Information Routing
Information Routing approach (where for the whole set of working and approach (where for the whole set of working and recovery LSPs, the
recovery LSPs, the amount of bandwidth units they use per-link is amount of bandwidth units they use per-link is known at each node and
known at each node and for each link) is clearly negligible. The for each link) is clearly negligible. The Full Information Routing
latter approach is detailed in [GLI], for instance. Note also that approach is detailed in [GLI]. Note also that both approaches rely
both approaches rely on the deterministic knowledge (at different on the deterministic knowledge (at different degrees) of the network
degrees) of the network topology and resource usage status. topology and resource usage status.
Moreover, extending the GMPLS signalling capabilities can enhance Moreover, extending the GMPLS signaling capabilities can enhance the
the Partial Information Routing approach. This, by allowing working Partial Information Routing approach. It is enhanced by allowing
LSP related information and in particular, its path (including link working-LSP-related information and, in particular, its path
and node identifiers) to be exchanged with the recovery LSP request (including link and node identifiers) to be exchanged with the
to enable more efficient admission control at upstream nodes of recovery LSP request. This enables more efficient admission control
shared recovery resources, in particular links (see Section 8.4.3). at upstream nodes of shared recovery resources, and in particular,
links (see Section 8.4.3).
8.4.2 Recovery Resource Sharing and SRLG Recovery 8.4.2. Recovery Resource Sharing and SRLG Recovery
Resource shareability can also be maximized with respect to the Resource shareability can also be maximized with respect to the
number of times each SRLG is protected by a recovery resource (in number of times each SRLG is protected by a recovery resource (in
particular, a shared TE link) and methods can be considered for particular, a shared TE link) and methods can be considered for
avoiding contention of the shared recovery resources in case of avoiding contention of the shared recovery resources in case of
single SRLG failure. These methods enable for the sharing of single SRLG failure. These methods enable the sharing of recovery
recovery resources between two (or more) recovery LSPs if their resources between two (or more) recovery LSPs, if their respective
respective working LSPs are mutually disjoint with respect to link, working LSPs are mutually disjoint with respect to link, node, and
node and SRLGs. A single failure then does not simultaneously SRLGs. Then, a single failure does not simultaneously disrupt
disrupt several (or at least two) working LSPs. several (or at least two) working LSPs.
For instance, [BOUILLET] shows that the Partial Information Routing For instance, [BOUILLET] shows that the Partial Information Routing
approach can be extended to cover recovery resource shareability approach can be extended to cover recovery resource shareability with
with respect to SRLG recoverability (i.e. the number of times each respect to SRLG recoverability (i.e., the number of times each SRLG
SRLG is recoverable). By flooding this aggregated information per TE is recoverable). By flooding this aggregated information per TE
D.Papadimitriou et al. - Expires October 2005 34
link, path computation and selection of SRLG-diverse recovery LSPs link, path computation and selection of SRLG-diverse recovery LSPs
can be optimized with respect to the sharing of recovery resource can be optimized with respect to the sharing of recovery resource
reserved on each TE link giving a performance difference of less reserved on each TE link. This yields a performance difference of
than 5% (and so negligible) compared to the corresponding Full less than 5%, which is negligible compared to the corresponding Full
Information Flooding approach (see [GLI]). Information Flooding approach (see [GLI]).
For this purpose, additional extensions to [GMPLS-RTG] in support of For this purpose, additional extensions to [RFC4202] in support of
path computation for shared mesh recovery have been often considered path computation for shared mesh recovery have been often considered
in the literature. TE link attributes would include, among other, in the literature. TE link attributes would include, among others,
the current number of recovery LSPs sharing the recovery resources the current number of recovery LSPs sharing the recovery resources
reserved on the TE link and the current number of SRLGs recoverable reserved on the TE link, and the current number of SRLGs recoverable
by this amount of (shared) recovery resources reserved on the TE by this amount of (shared) recovery resources reserved on the TE
link. The latter is equivalent to the current number of SRLGs that link. The latter is equivalent to the current number of SRLGs that
the recovery LSPs sharing the recovery resource reserved on the TE will be recovered by the recovery LSPs sharing the recovery resource
link shall recover. Then, if explicit SRLG recoverability is reserved on the TE link. Then, if explicit SRLG recoverability is
considered an additional TE link attribute including the explicit considered, a TE link attribute would be added that includes the
list of SRLGs recoverable by the shared recovery resource reserved explicit list of SRLGs (recoverable by the shared recovery resource
on the TE link and their respective shareable recovery bandwidth. reserved on the TE link) and their respective shareable recovery
The latter information is equivalent to the shareable recovery bandwidths. The latter information is equivalent to the shareable
bandwidth per SRLG (or per group of SRLGs) which implies to consider recovery bandwidth per SRLG (or per group of SRLGs), which implies
a decreasing amount of shareable bandwidth and SRLG list over time. that the amount of shareable bandwidth and the number of listed SRLGs
will decrease over time.
Compared to the case of recovery resource sharing only (regardless Compared to the case of recovery resource sharing only (regardless of
of SRLG recoverability, as described in Section 8.4.1), this SRLG recoverability, as described in Section 8.4.1), these additional
additional TE link attributes would potentially deliver better path TE link attributes would potentially deliver better path computation
computation and selection (at distinct ingress node) for shared mesh and selection (at a distinct ingress node) for shared mesh recovery
recovery purposes. However, due to the lack of results of evidence purposes. However, due to the lack of evidence of better efficiency
for better efficiency and due to the complexity that such extensions and due to the complexity that such extensions would generate, they
would generate, they are not further considered in the scope of the are not further considered in the scope of the present analysis. For
present analysis. For instance, a per-SRLG group minimum/maximum instance, a per-SRLG group minimum/maximum shareable recovery
shareable recovery bandwidth is restricted by the length that the bandwidth is restricted by the length that the corresponding (sub-)
corresponding (sub-)TLV may take and thus the number of SRLGs that TLV may take and thus the number of SRLGs that it can include.
it can include. Therefore, the corresponding parameter should not be Therefore, the corresponding parameter should not be translated into
translated into GMPLS routing (or even signalling) protocol GMPLS routing (or even signaling) protocol extensions in the form of
extensions in the form of TE link sub-TLV. TE link sub-TLV.
8.4.3 Recovery Resource Sharing, SRLG Disjointness and Admission 8.4.3. Recovery Resource Sharing, SRLG Disjointness and Admission
Control Control
Admission control is a strict requirement to be fulfilled by nodes Admission control is a strict requirement to be fulfilled by nodes
giving access to shared links. This can be illustrated using the giving access to shared links. This can be illustrated using the
following network topology: following network topology:
A ------ C ====== D A ------ C ====== D
| | | | | |
| | | | | |
| B | | B |
| | | | | |
| | | | | |
------- E ------ F ------- E ------ F
Node A creates a working LSP to D (A-C-D), B creates simultaneously Node A creates a working LSP to D (A-C-D), B creates simultaneously a
a working LSP to D (B-C-D) and a recovery LSP (B-E-F-D) to the same working LSP to D (B-C-D) and a recovery LSP (B-E-F-D) to the same
D.Papadimitriou et al. - Expires October 2005 35
destination. Then, A decides to create a recovery LSP to D (A-E-F- destination. Then, A decides to create a recovery LSP to D (A-E-F-
D), but since the C-D span carries both working LSPs, node E should D), but since the C-D span carries both working LSPs, node E should
either assign a dedicated resource for this recovery LSP or reject either assign a dedicated resource for this recovery LSP or reject
this request if the C-D span has already reached its maximum this request if the C-D span has already reached its maximum recovery
recovery bandwidth sharing ratio. Otherwise, in the latter case, C-D bandwidth sharing ratio. In the latter case, C-D span failure would
span failure would imply that one of the working LSP would not be imply that one of the working LSP would not be recoverable.
recoverable.
Consequently, node E must have the required information to perform Consequently, node E must have the required information to perform
admission control for the recovery LSP requests it processes admission control for the recovery LSP requests it processes
(implying for instance, that the path followed by the working LSP is (implying for instance, that the path followed by the working LSP is
carried with the corresponding recovery LSP request). If node E can carried with the corresponding recovery LSP request). If node E can
guarantee that the working LSPs (A-C-D and B-C-D) are SRLG disjoint guarantee that the working LSPs (A-C-D and B-C-D) are SRLG disjoint
over the C-D span, it may securely accept the incoming recovery LSP over the C-D span, it may securely accept the incoming recovery LSP
request and assign to the recovery LSPs (A-E-F-D and B-E-F-D) the request and assign to the recovery LSPs (A-E-F-D and B-E-F-D) the
same resources on the link E-F. This, if the link E-F has not yet same resources on the link E-F. This may occur if the link E-F has
reached its maximum recovery bandwidth sharing ratio. In this not yet reached its maximum recovery bandwidth sharing ratio. In
example, one assumes that the node failure probability is negligible this example, one assumes that the node failure probability is
compared to the link failure probability. negligible compared to the link failure probability.
To achieve this, the path followed by the working LSP is transported To achieve this, the path followed by the working LSP is transported
with the recovery LSP request and examined at each upstream node of with the recovery LSP request and examined at each upstream node of
potentially shareable links. Admission control is performed using potentially shareable links. Admission control is performed using
the interface identifiers (included in the path) to retrieve in the the interface identifiers (included in the path) to retrieve in the
TE DataBase the list of SRLG Ids associated to each of the working TE DataBase the list of SRLG IDs associated to each of the working
LSP links. If the working LSPs (A-C-D and B-C-D) have one or more LSP links. If the working LSPs (A-C-D and B-C-D) have one or more
link or SRLG id in common (in this example, one or more SRLG id in link or SRLG ID in common (in this example, one or more SRLG id in
common over the span C-D) node E should not assign the same resource common over the span C-D), node E should not assign the same resource
over link E-F to the recovery LSPs (A-E-F-D and B-E-F-D). Otherwise, over link E-F to the recovery LSPs (A-E-F-D and B-E-F-D). Otherwise,
one of these working LSPs would not be recoverable in case of C-D one of these working LSPs would not be recoverable if C-D span
span failure. failure occurred.
There are some issues related to this method, the major one being There are some issues related to this method; the major one is the
the number of SRLG Ids that a single link can cover (more than 100, number of SRLG IDs that a single link can cover (more than 100, in
in complex environments). Moreover, when using link bundles, this complex environments). Moreover, when using link bundles, this
approach may generate the rejection of some recovery LSP requests. approach may generate the rejection of some recovery LSP requests.
This occurs when the SRLG sub-TLV corresponding to a link bundle This occurs when the SRLG sub-TLV corresponding to a link bundle
includes the union of the SRLG id list of all the component links includes the union of the SRLG id list of all the component links
belonging to this bundle (see [GMPLS-RTG] and [BUNDLE]). belonging to this bundle (see [RFC4202] and [RFC4201]).
In order to overcome this specific issue, an additional mechanism In order to overcome this specific issue, an additional mechanism may
may consist of querying the nodes where such an information would be consist of querying the nodes where the information would be
available (in this case, node E would query C). The main drawback of available (in this case, node E would query C). The main drawback of
this method is that, in addition to the dedicated mechanism(s) it this method is that (in addition to the dedicated mechanism(s) it
requires, it may become complex when several common nodes are requires) it may become complex when several common nodes are
traversed by the working LSPs. Therefore, when using link bundles, traversed by the working LSPs. Therefore, when using link bundles,
solving this issue is tightly related to the sequence of the solving this issue is closely related to the sequence of the recovery
recovery operations. Per component flooding of SRLG identifiers operations. Per-component flooding of SRLG identifiers would deeply
would deeply impact the scalability of the link state routing impact the scalability of the link state routing protocol.
protocol. Therefore, one may rely on the usage of an on-line Therefore, one may rely on the usage of an on-line accessible network
accessible network management system. management system.
D.Papadimitriou et al. - Expires October 2005 36
9. Summary and Conclusions 9. Summary and Conclusions
The following table summarizes the different recovery types and The following table summarizes the different recovery types and
schemes analyzed throughout this document. schemes analyzed throughout this document.
-------------------------------------------------------------------- --------------------------------------------------------------------
| Path Search (computation and selection) | Path Search (computation and selection)
-------------------------------------------------------------------- --------------------------------------------------------------------
| Pre-planned (a) | Dynamic (b) | Pre-planned (a) | Dynamic (b)
-------------------------------------------------------------------- --------------------------------------------------------------------
| | faster recovery | Does not apply | | faster recovery | Does not apply
| | less flexible | | | less flexible |
| 1 | less robust | | 1 | less robust |
| | most resource consuming | | | most resource-consuming |
Path | | | Path | | |
Setup ------------------------------------------------------------ Setup ------------------------------------------------------------
| | relatively fast recovery | Does not apply | | relatively fast recovery | Does not apply
| | relatively flexible | | | relatively flexible |
| 2 | relatively robust | | 2 | relatively robust |
| | resource consumption | | | resource consumption |
| | depends on sharing degree | | | depends on sharing degree |
------------------------------------------------------------ ------------------------------------------------------------
| | relatively fast recovery | less faster (computation) | | relatively fast recovery | less faster (computation)
| | more flexible | most flexible | | more flexible | most flexible
| 3 | relatively robust | most robust | 3 | relatively robust | most robust
| | less resource consuming | least resource consuming | | less resource-consuming | least resource-consuming
| | depends on sharing degree | | | depends on sharing degree |
-------------------------------------------------------------------- --------------------------------------------------------------------
1a. Recovery LSP setup (before failure occurrence) with resource 1a. Recovery LSP setup (before failure occurrence) with resource
reservation (i.e. signalling) and selection is referred to as reservation (i.e., signaling) and selection is referred to as LSP
LSP protection. protection.
2a. Recovery LSP setup (before failure occurrence) with resource 2a. Recovery LSP setup (before failure occurrence) with resource
reservation (i.e. signalling) and with resource pre-selection is reservation (i.e., signaling) and with resource pre-selection is
referred to as pre-planned LSP re-routing with resource pre- referred to as pre-planned LSP re-routing with resource pre-
selection. This implies only recovery LSP activation after selection. This implies only recovery LSP activation after
failure occurrence. failure occurrence.
3a. Recovery LSP setup (before failure occurrence) with resource 3a. Recovery LSP setup (before failure occurrence) with resource
reservation (i.e. signalling) and without resource selection is reservation (i.e., signaling) and without resource selection is
referred to as pre-planned LSP re-routing without resource pre- referred to as pre-planned LSP re-routing without resource pre-
selection. This implies recovery LSP activation and resource selection. This implies recovery LSP activation and resource
(i.e. label) selection after failure occurrence. (i.e., label) selection after failure occurrence.
3b. Recovery LSP setup after failure occurrence is referred to as 3b. Recovery LSP setup after failure occurrence is referred to as to
to as LSP re-routing, which is full when recovery LSP path as LSP re-routing, which is full when recovery LSP path
computation occurs after failure occurrence. computation occurs after failure occurrence.
The term pre-planned refers thus to recovery LSP path pre- Thus, the term pre-planned refers to recovery LSP path pre-
computation, signaling (reservation), and a priori resource computation, signaling (reservation), and a priori resource selection
selection (optional), but not cross-connection. Also, the shared- (optional), but not cross-connection. Also, the shared-mesh recovery
scheme can be viewed as a particular case of 2a) and 3a), using the
D.Papadimitriou et al. - Expires October 2005 37 additional constraint described in Section 8.4.3.
mesh recovery scheme can be viewed as a particular case of 2a) and
3a) using the additional constraint described in Section 8.4.3.
The implementation of these recovery mechanisms requires only The implementation of these recovery mechanisms requires only
considering extensions to GMPLS signalling protocols (i.e. [RFC3471] considering extensions to GMPLS signaling protocols (i.e., [RFC3471]
and [RFC3473]). These GMPLS signalling extensions should mainly and [RFC3473]). These GMPLS signaling extensions should mainly focus
focus in delivering (1) recovery LSP pre-provisioning for the cases in delivering (1) recovery LSP pre-provisioning for the cases 1a, 2a,
1a, 2a and 3a, (2) LSP failure notification, (3) recovery LSP and 3a, (2) LSP failure notification, (3) recovery LSP switching
switching action(s), and (4) reversion mechanisms. action(s), and (4) reversion mechanisms.
Moreover, the present analysis (see Section 8) shows that no GMPLS Moreover, the present analysis (see Section 8) shows that no GMPLS
routing extensions are expected to efficiently implement any of routing extensions are expected to efficiently implement any of these
these recovery types and schemes. recovery types and schemes.
10. Security Considerations 10. Security Considerations
This document does not introduce any additional security issue or This document does not introduce any additional security issue or
imply any specific security consideration from [RFC3945] to the imply any specific security consideration from [RFC3945] to the
current RSVP-TE GMPLS signaling, routing protocols (OSPF-TE, IS-IS- current RSVP-TE GMPLS signaling, routing protocols (OSPF-TE, IS-IS-
TE) or network management protocols. TE) or network management protocols.
However, the authorization of requests for resources by GMPLS- However, the authorization of requests for resources by GMPLS-capable
capable nodes should determining whether a given party, presumable nodes should determine whether a given party, presumably already
already authenticated, has a right to access the requested authenticated, has a right to access the requested resources. This
resources. This determination is typically a matter of local policy determination is typically a matter of local policy control, for
control, for example by setting limits on the total bandwidth made example, by setting limits on the total bandwidth made available to
available to some party in the presence of resource contention. Such some party in the presence of resource contention. Such policies may
policies may become quite complex as the number of users, types of become quite complex as the number of users, types of resources, and
resources and sophistication of authorization rules increases. This sophistication of authorization rules increases. This is
is particularly the case for recovery schemes that assume pre- particularly the case for recovery schemes that assume pre-planned
planned sharing of recovery resources, or contention for resources sharing of recovery resources, or contention for resources in case of
in case of dynamic re-routing. dynamic re-routing.
Therefore, control elements should match them against the local
authorization policy. These control elements must be capable of
making decisions based on the identity of the requester, as verified
cryptographically and/or topologically.
11. IANA Considerations
This document defines no new code points and requires no action by Therefore, control elements should match the requests against the
IANA. local authorization policy. These control elements must be capable
of making decisions based on the identity of the requester, as
verified cryptographically and/or topologically.
12. Acknowledgments 11. Acknowledgements
The authors would like to thank Fabrice Poppe (Alcatel) and Bart The authors would like to thank Fabrice Poppe (Alcatel) and Bart
Rousseau (Alcatel) for their revision effort, Richard Rabbat Rousseau (Alcatel) for their revision effort, and Richard Rabbat
(Fujitsu Labs), David Griffith (NIST) and Lyndon Ong (Ciena) for (Fujitsu Labs), David Griffith (NIST), and Lyndon Ong (Ciena) for
their useful comments. their useful comments.
Thanks also to Adrian Farrel for the thorough review of the Thanks also to Adrian Farrel for the thorough review of the document.
document.
D.Papadimitriou et al. - Expires October 2005 38
13. References
13.1 Normative References 12. References
[BUNDLE] K.Kompella et al., "Link Bundling in MPLS Traffic 12.1. Normative References
Engineering," Work in progress, draft-ietf-mpls-bundle-
06.txt, December 2004.
[GMPLS-RTG] K.Kompella (Editor) et al., "Routing Extensions in [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Support of Generalized Multi-Protocol Label Switching," Requirement Levels", BCP 14, RFC 2119, March 1997.
Work in Progress, draft-ietf-ccamp-gmpls-routing-
09.txt, October 2003.
[LMP] J.P.Lang (Editor) et al., "Link Management Protocol [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching
(LMP)," Work in progress, draft-ietf-ccamp-lmp-10.txt, (GMPLS) Signaling Functional Description", RFC 3471,
October 2003. January 2003.
[LMP-WDM] A.Fredette and J.P.Lang (Editors), "Link Management [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
Protocol (LMP) for Dense Wavelength Division (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Multiplexing (DWDM) Optical Line Systems," Work in Engineering (RSVP-TE) Extensions", RFC 3473, January
progress, draft-ietf-ccamp-lmp-wdm-03.txt, October
2003. 2003.
[RFC2026] S.Bradner, "The Internet Standards Process -- Revision [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
3," BCP 9, RFC 2026, October 1996. (GMPLS) Architecture", RFC 3945, October 2004.
[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC3471] L.Berger (Editor) et al., "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Functional
Description," RFC 3471, January 2003.
[RFC3473] L.Berger (Editor) et al., "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions," RFC
3473, January 2003.
[RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78, [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
RFC 3667, February 2004. in MPLS Traffic Engineering (TE)", RFC 4201, October
2005.
[RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
Technology", BCP 79, RFC 3668, February 2004. Extensions in Support of Generalized Multi-Protocol
Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC3945] E.Mannie (Editor) et al., "Generalized Multi-Protocol [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
Label Switching Architecture," RFC 3945, October 2004. 4204, October 2005.
[TERM] E.Mannie and D.Papadimitriou (Editors), "Recovery [RFC4209] Fredette, A., Ed. and J. Lang, Ed., "Link Management
(Protection and Restoration) Terminology for Protocol (LMP) for Dense Wavelength Division
Generalized Multi-Protocol Label Switching (GMPLS)," Multiplexing (DWDM) Optical Line Systems", RFC 4209,
Work in progress, draft-ietf-ccamp-gmpls-recovery- October 2005.
terminology-06.txt, April 2005.
D.Papadimitriou et al. - Expires October 2005 39 [RFC4427] Mannie E., Ed. and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for Generalized
Multi-Protocol Label Switching (GMPLS)", RFC 4427, March
2006.
13.2 Informative References 12.2. Informative References
[BOUILLET] E.Bouillet et al., "Stochastic Approaches to Compute [BOUILLET] E. Bouillet, et al., "Stochastic Approaches to Compute
Shared Meshed Restored Lightpaths in Optical Network Shared Meshed Restored Lightpaths in Optical Network
Architectures," IEEE Infocom 2002, New York City, June Architectures," IEEE Infocom 2002, New York City, June
2002. 2002.
[DEMEESTER] P.Demeester et al., "Resilience in Multilayer [DEMEESTER] P. Demeester, et al., "Resilience in Multilayer
Networks," IEEE Communications Magazine, Vol. 37, No. Networks," IEEE Communications Magazine, Vol. 37, No. 8,
8, pp. 70-76, August 1998. pp. 70-76, August 1998.
[GLI] G.Li et al., "Efficient Distributed Path Selection for [GLI] G. Li, et al., "Efficient Distributed Path Selection for
Shared Restoration Connections," IEEE Infocom 2002, New Shared Restoration Connections," IEEE Infocom 2002, New
York City, June 2002. York City, June 2002.
[IPO-IMP] J.Strand and A.Chiu, "Impairments and Other Constraints [IPO-IMP] Strand, J. and A. Chiu, "Impairments and Other
On Optical Layer Routing," Work in Progress, draft- Constraints on Optical Layer Routing", RFC 4054, May
ietf-ipo-impairments-05.txt, May 2003. 2005.
[KODIALAM1] M.Kodialam and T.V.Lakshman, "Restorable Dynamic [KODIALAM1] M.Kodialam and T.V.Lakshman, "Restorable Dynamic
Quality of Service Routing," IEEE Communications Quality of Service Routing," IEEE Communications
Magazine, pp. 72-81, June 2002. Magazine, pp. 72-81, June 2002.
[KODIALAM2] M.Kodialam and T.V.Lakshman, "Dynamic Routing of [KODIALAM2] M.Kodialam and T.V.Lakshman, "Dynamic Routing of
Restorable Bandwidth-Guaranteed Tunnels using Restorable Bandwidth-Guaranteed Tunnels using Aggregated
Aggregated Network Resource Usage Information," IEEE/ Network Resource Usage Information," IEEE/ ACM
ACM Transactions on Networking, pp. 399-410, June 2003. Transactions on Networking, pp. 399-410, June 2003.
[MANCHESTER] J.Manchester, P.Bonenfant and C.Newton, "The Evolution [MANCHESTER] J. Manchester, P. Bonenfant and C. Newton, "The
of Transport Network Survivability," IEEE Evolution of Transport Network Survivability," IEEE
Communications Magazine, August 1999. Communications Magazine, August 1999.
[RFC3386] W.Lai, D.McDysan, J.Boyle, et al., "Network Hierarchy [RFC3386] Lai, W. and D. McDysan, "Network Hierarchy and
and Multi-layer Survivability," RFC 3386, November 2002 Multilayer Survivability", RFC 3386, November 2002.
[RFC3469] V.Sharma and F.Hellstrand (Editors), "Framework for
Multi-Protocol Label Switching (MPLS)- based Recovery,"
RFC 3469, February 2003.
[T1.105] ANSI, "Synchronous Optical Network (SONET): Basic [T1.105] ANSI, "Synchronous Optical Network (SONET): Basic
Description Including Multiplex Structure, Rates, and Description Including Multiplex Structure, Rates, and
Formats," ANSI T1.105, January 2001. Formats," ANSI T1.105, January 2001.
[WANG] J.Wang, L.Sahasrabuddhe, and B.Mukherjee, "Path vs. [WANG] J.Wang, L.Sahasrabuddhe, and B.Mukherjee, "Path vs.
Subpath vs. Link Restoration for Fault Management in Subpath vs. Link Restoration for Fault Management in
IP-over-WDM Networks: Performance Comparisons Using IP-over-WDM Networks: Performance Comparisons Using
GMPLS Control Signaling," IEEE Communications Magazine, GMPLS Control Signaling," IEEE Communications Magazine,
pp. 80-87, November 2002. pp. 80-87, November 2002.
For information on the availability of the following documents, For information on the availability of the following documents,
please see http://www.itu.int please see http://www.itu.int
D.Papadimitriou et al. - Expires October 2005 40
[G.707] ITU-T, "Network Node Interface for the Synchronous [G.707] ITU-T, "Network Node Interface for the Synchronous
Digital Hierarchy (SDH)," Recommendation G.707, October Digital Hierarchy (SDH)," Recommendation G.707, October
2000. 2000.
[G.709] ITU-T, "Network Node Interface for the Optical [G.709] ITU-T, "Network Node Interface for the Optical Transport
Transport Network (OTN)," Recommendation G.709, Network (OTN)," Recommendation G.709, February 2001 (and
February 2001 (and Amendment no.1, October 2001). Amendment no.1, October 2001).
[G.783] ITU-T, "Characteristics of Synchronous Digital [G.783] ITU-T, "Characteristics of Synchronous Digital Hierarchy
Hierarchy (SDH) Equipment Functional Blocks," (SDH) Equipment Functional Blocks," Recommendation
Recommendation G.783, October 2000. G.783, October 2000.
[G.798] ITU-T, "Characteristics of optical transport network
hierarchy equipment functional block," Recommendation
G.798, June 2004.
[G.806] ITU-T, "Characteristics of Transport Equipment - [G.806] ITU-T, "Characteristics of Transport Equipment -
Description Methodology and Generic Functionality", Description Methodology and Generic Functionality",
Recommendation G.806, October 2000. Recommendation G.806, October 2000.
[G.808.1] ITU-T, "Generic Protection Switching - Linear trail and
Subnetwork Protection," Recommendation G.808.1,
December 2003.
[G.841] ITU-T, "Types and Characteristics of SDH Network [G.841] ITU-T, "Types and Characteristics of SDH Network
Protection Architectures," Recommendation G.841, Protection Architectures," Recommendation G.841, October
October 1998. 1998.
[G.842] ITU-T, "Interworking of SDH network protection [G.842] ITU-T, "Interworking of SDH network protection
architectures," Recommendation G.842, October 1998. architectures," Recommendation G.842, October 1998.
14. Editor's Addresses [G.874] ITU-T, "Management aspects of the optical transport
network element," Recommendation G.874, November 2001.
Eric Mannie Editors' Addresses
EMail: eric_mannie@hotmail.com
Dimitri Papadimitriou Dimitri Papadimitriou
Alcatel Alcatel
Francis Wellesplein, 1 Francis Wellesplein, 1
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491 Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be EMail: dimitri.papadimitriou@alcatel.be
D.Papadimitriou et al. - Expires October 2005 41 Eric Mannie
Perceval
Rue Tenbosch, 9
1000 Brussels
Belgium
Intellectual Property Statement Phone: +32-2-6409194
EMail: eric.mannie@perceval.net
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed to
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; nor does it represent that might or might not be available; nor does it represent that it has
it has made any independent effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the procedures with respect to rights in RFC on the procedures with respect to rights in RFC documents can be
documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
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.
D.Papadimitriou et al. - Expires October 2005 42 Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 355 change blocks. 
1152 lines changed or deleted 1075 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/