draft-ietf-ccamp-gmpls-recovery-analysis-01.txt   draft-ietf-ccamp-gmpls-recovery-analysis-02.txt 
CCAMP Working Group CCAMP GMPLS P&R Design Team CCAMP Working Group CCAMP GMPLS P&R Design Team
Internet Draft Internet Draft
Category: Informational Dimitri Papadimitriou (Editor) Category: Informational Dimitri Papadimitriou (Editor)
Expiration Date: November 2003 Eric Mannie (Editor) Expiration Date: March 2004 Eric Mannie (Editor)
May 2003 September 2003
Analysis of Generalized MPLS-based Recovery Mechanisms Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based
(including Protection and Restoration) Recovery Mechanisms (including Protection and Restoration)
draft-ietf-ccamp-gmpls-recovery-analysis-01.txt draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of Drafts. Internet-Drafts are draft documents valid for a maximum of
skipping to change at line 37 skipping to change at line 37
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
For potential updates to the above required-text see: For potential updates to the above required-text see:
http://www.ietf.org/ietf/1id-guidelines.txt http://www.ietf.org/ietf/1id-guidelines.txt
1. Abstract Abstract
This document provides an analysis grid that can be used to This document provides an analysis grid to evaluate, compare and
evaluate, compare and contrast the numerous Generalized MPLS contrast the Generalized Multi-Protocol Label Switching (GMPLS)
(GMPLS)-based recovery mechanisms currently proposed at the CCAMP protocol suite capabilities with respect to the recovery mechanisms
Working Group. A detailed analysis of each of the recovery phases is currently proposed at the IETF CCAMP Working Group. A detailed
provided using the terminology defined in a companion document. This analysis of each of the recovery phases is provided using the
document focuses on transport plane survivability and recovery terminology defined in a companion document. This document focuses
issues and not on control plane resilience and related aspects. on transport plane survivability and recovery issues and not on
control plane resilience and related aspects.
D.Papadimitriou et al. - Internet Draft - Expires November 2003 1 D.Papadimitriou et al. - Internet Draft - Expires March 2004 1
1. Table of Content
Status of this Memo .............................................. 1
Abstract ......................................................... 1
1. Table of Content .............................................. 2
2. Contributors .................................................. 3
3. Introduction .................................................. 4
4. Fault Management .............................................. 4
4.1 Failure Detection ............................................ 4
4.2 Failure Localization and Isolation ........................... 7
4.3 Failure Notification ......................................... 7
4.4 Failure Correlation .......................................... 9
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 ........................................ 11
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 ..... 15
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 ........................................... 19
5.5.3 Pre-planned LSP Restoration ............................... 21
5.5.4 LSP Segment Restoration ................................... 22
6. Normalization ................................................ 22
6.1 Wait-To-Restore (WTR) ....................................... 22
6.2 Revertive Mode Operation .................................... 23
6.3 Orphans ..................................................... 23
7. Hierarchies .................................................. 24
7.1 Horizontal Hierarchy (Partitions) ........................... 24
7.2 Vertical Hierarchy (Layers) ................................. 25
7.3 Escalation Strategies ....................................... 26
7.4 Disjointness ................................................ 27
7.4.1 SRLG Disjointness ......................................... 27
8. Recovery Mechanisms Analysis ................................. 28
8.1 Fast Convergence (Detection/Correlation and Hold-off Time) .. 29
8.2 Efficiency (Recovery Switching Time) ........................ 29
8.3 Robustness .................................................. 30
8.4 Resource Optimization ....................................... 31
8.4.1 Recovery Resource Sharing ................................. 32
8.4.2 Recovery Resource Sharing and SRLG Recovery ............... 33
8.4.3 Recovery Resource Sharing, SRLG Disjointness and Admission. 34
9. Summary and Conclusions ...................................... 35
10. Security Considerations ..................................... 35
11. Acknowledgments ............................................. 36
12. Intellectual Property Considerations ........................ 37
13. References .................................................. 38
13.1 Normative References ....................................... 38
D.Papadimitriou et al. - Internet Draft - Expires March 2004 2
13.2 Informative References ..................................... 38
14 Author's Address ............................................. 40
2. 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 Restoration design team joint effort. Besides the editors, the and 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)
Rm. D1-3C22 - 200 S. Laurel Ave. 200 S. Laurel Ave.
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
E-mail: dbrungard@att.com E-mail: dbrungard@att.com
Sudheer Dharanikota (Consult) Sudheer Dharanikota (Consult)
E-mail: sudheer@ieee.org E-mail: sudheer@ieee.org
Jonathan P. Lang (Consult) Jonathan P. Lang (Rincon Networks)
E-mail: jplang@ieee.org E-mail: 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
E-mail: gli@research.att.com E-mail: gli@research.att.com
Eric Mannie (Consult) Eric Mannie (Consult)
E-mail: eric_mannie@hotmail.com E-mail: eric_mannie@hotmail.com
skipping to change at line 96 skipping to change at line 155
Sunnyvale, CA 94089, USA Sunnyvale, CA 94089, USA
E-mail: yakov@juniper.net E-mail: yakov@juniper.net
Conventions used in this document: 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 document are to be interpreted as described in RFC-2119 [2]. this document are to be interpreted as described in RFC-2119 [2].
Any other recovery-related terminology used in this document Any other recovery-related terminology used in this document
conforms to the one defined in [CCAMP-TERM]. The reader is also conforms to the one defined in [TERM]. The reader is also assumed to
assumed to be familiar with the terminology developed in [GMPLS- be familiar with the terminology developed in [GMPLS-ARCH], [RFC-
ARCH], [RFC-3471], [GMPLS-RTG] and [LMP]. 3471], [RFC-3473], [GMPLS-RTG] and [LMP].
D.Papadimitriou et al. - Internet Draft - Expires November 2003 2 D.Papadimitriou et al. - Internet Draft - Expires March 2004 3
3. Introduction 3. Introduction
This document provides an analysis grid to evaluate, compare and This document provides an analysis grid to evaluate, compare and
contrast the numerous Generalized MPLS (GMPLS) based recovery contrast the Generalized MPLS (GMPLS) protocol suite capabilities
mechanisms currently proposed in the CCAMP Working Group. Here, the with respect to the recovery mechanisms currently proposed at the
focus will only be on transport plane survivability and recovery IETF CCAMP Working Group. Here, the focus will only be on transport
issues and not on control plane resilience related aspects. Although plane survivability and recovery issues and not on control plane
the recovery mechanisms described in this document impose different resilience related aspects. Although the recovery mechanisms
requirements on GMPLS-based recovery protocols, the protocol(s) described in this document impose different requirements on GMPLS-
specifications will not be covered in this document. Though the based recovery protocols, the protocol(s) specifications will not be
concepts discussed here are technology independent, this document covered in this document. Though the concepts discussed here are
will implicitly focus on Sonet/SDH and pre-OTN technologies except technology independent, this document will implicitly focus on
when specific details need to be considered (for instance, in the Sonet/SDH [T1.105]/[G.707], Optical Transport Networks (OTN) [G.709]
case of failure detection). Details for applicability to other and pre-OTN technologies except when specific details need to be
technologies such as Optical Transport Networks (OTN) [G.709] will considered (for instance, in the case of failure detection).
be covered in a future release of this document.
In the present release, a detailed analysis is provided for each of In the present release, a detailed analysis is provided for each of
the recovery phases as identified in [CCAMP-TERM]. These phases the recovery phases as identified in [TERM]. These phases define the
define the sequence of generic operations that need to be performed sequence of generic operations that need to be performed when a
when a LSP/Span failure (or any other event generating such LSP/Span failure (or any other event generating such failures)
failures) occurs: occurs:
- Phase 1: Failure detection - Phase 1: Failure detection
- Phase 2: Failure localization and isolation - Phase 2: Failure localization and isolation
- Phase 3: Failure notification - Phase 3: Failure notification
- Phase 4: Recovery (Protection/Restoration) - Phase 4: Recovery (Protection/Restoration)
- Phase 5: Reversion (normalization) - Phase 5: Reversion (normalization)
Failure detection, localization and notification phases together are Failure detection, localization and notification phases together are
referred to as fault management. Within a recovery domain, the referred to as fault management. Within a recovery domain, the
entities involved during the recovery operations are defined in entities involved during the recovery operations are defined in
[CCAMP-TERM]; these entities include ingress, egress and [TERM]; these entities include ingress, egress and intermediate
intermediate nodes. nodes. The term "recovery mechanism" is used to cover both
protection and restoration mechanisms. Specific terms such as
In this document, 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 protection and restoration are only used when differentiation is
required. Likewise the term "failure" is used to represent both required. Likewise the term "failure" is used to represent both
signal failure and signal degradation. In addition, a clear signal failure and signal degradation.
distinction is made between partitioning (horizontal hierarchy) and
layering (vertical hierarchy) when analyzing hierarchical recovery In addition, a clear distinction is made between partitioning
mechanisms including disjointness related issues. We also introduce (horizontal hierarchy) and layering (vertical hierarchy) when
the dimensions from which each of the recovery mechanisms described analyzing the different hierarchical recovery mechanisms including
in this document can be further analyzed and provide an analysis disjointness related issues. The dimensions from which each of the
grid with respect to these dimensions. Last, we conclude by recovery mechanisms detailed in this document can be analyzed are
introduced to assess the current GMPLS protocol capabilities and the
potential need for further extensions. This document concludes by
detailing the applicability of the current GMPLS protocol building detailing the applicability of the current GMPLS protocol building
blocks for recovery purposes. blocks for recovery purposes.
4. Fault Management 4. Fault Management
4.1 Failure Detection 4.1 Failure Detection
D.Papadimitriou et al. - Internet Draft - Expires November 2003 3 D.Papadimitriou et al. - Internet Draft - Expires March 2004 4
Transport failure detection is the only phase that can not be Transport failure detection is the only phase that can not be
achieved by the control plane alone since the latter needs a hook to achieved by the control plane alone since the latter needs a hook to
the transport plane to collect the related information. It has to be the transport plane to collect the related information. It has to be
emphasized that even if failure events themselves are detected by emphasized that even if failure events themselves are detected by
the transport plane, the latter, upon failure condition, MUST the transport plane, the latter, upon 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 [RFC-3471]) or Link Management GMPLS signalling capabilities (see [RFC-3471] and [RFC-3473]) or
Protocol capabilities (see [LMP], Section 6). Link Management Protocol capabilities (see [LMP], 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: monitors the integrity of the continuity of a trail
(i.e. section or path). This operation is performed by monitoring (i.e. section or path). This operation is performed by monitoring
the presence/absence of the signal. Examples are Loss of Signal the presence/absence of the signal. Examples are Loss of Signal
(LOS) detection for the physical layer, Unequipped (UNEQ) Signal (LOS) detection for the physical layer, Unequipped (UNEQ) Signal
detection for the path layer, Server Signal Fail Detection (e.g. detection for the path layer, Server Signal Fail Detection (e.g.
skipping to change at line 210 skipping to change at line 268
- Payload type: checks that compatible adaptation functions are used - Payload type: checks that compatible adaptation functions are used
at the source and the sink. This is normally done by adding a at the source and the sink. This is normally done by adding a
signal type identifier at the source adaptation function and signal type identifier at the source adaptation function and
comparing it with the expected identifier at the sink. For comparing it with the expected identifier at the sink. For
instance, the payload signal label and the corresponding payload instance, the payload signal label and the corresponding payload
signal mismatch detection. signal mismatch detection.
- Signal Quality: monitors the performance of a signal. For - Signal Quality: monitors the performance of a signal. For
instance, if the performance falls below a certain threshold a instance, if the performance falls below a certain threshold a
D.Papadimitriou et al. - Internet Draft - Expires November 2003 4 D.Papadimitriou et al. - Internet Draft - Expires March 2004 5
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).
- 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
(OTS, OMS and OTUk) and at optical/digital path layers (OCh and (i.e. Optical Transmission Section (OTS), Optical Multiplex Section
ODUk). Interested readers are referred to the ITU-T Recommendations (OMS) and Optical channel Transport Unit (OTU)) and at the optical/
[G.798] and [G.709] for more details. digital path layers (i.e. Optical Channel (OCh) and Optical channel
Data Unit (ODU)). Interested readers are referred to the 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 are co-located. The following detection, and reporting entities (see [TERM]) are co-located. The
example illustrates the scenario where the failure detection and following example illustrates the scenario where the failure
reporting entities are not co-located. detecting and reporting entities (see [TERM]) 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 reported to the PXC control plane. This can be
provided by using [LMP-WDM] extensions that delivers IP message- provided by using [LMP-WDM] extensions that delivers IP message-
based communication between the PXC and the OLS control plane. Also, based communication between the PXC and the OLS control plane. Also,
since PXCs are framing format independent, failure conditions can since PXCs are independent of the framing format, failure conditions
only be triggered either by detecting the absence of the optical can only be triggered either by detecting the absence of the optical
signal or by measuring its quality. These mechanisms are generally signal or by measuring its quality. These mechanisms are generally
less reliable than electrical (digital) ones. Both types of less reliable than electrical (digital) ones. Both types of
detection mechanisms are out of the scope of this document. If the detection mechanisms are outside the scope of this document. If the
intermediate OLS supports electrical (digital) mechanisms, using the intermediate OLS supports electrical (digital) mechanisms, using the
LMP communication channel, these failure conditions are reported to LMP communication channel, these failure conditions are reported to
the PXC and subsequent recovery actions 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
makes the OLS-PXC composed system appearing as a single logical turn the OLS-PXC composed system into a single logical entity
entity allowing considering for such entity the same failure allowing the consideration of the same failure management mechanisms
management mechanisms as for any other O/E/O 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 anymore on a condition where the optical signal is not detected any longer on
given interface's receiver.
D.Papadimitriou et al. - Internet Draft - Expires November 2003 5 D.Papadimitriou et al. - Internet Draft - Expires March 2004 6
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 condition.
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 reporting entities are on the same node (e.g., Sonet/SDH and reporting entities are on the same node (e.g., Sonet/SDH
equipment, Opaque cross-connects, and, with some limitations, equipment, Opaque cross-connects, and, with some limitations,
Transparent cross-connects, etc.) Transparent cross-connects, etc.)
- Non co-located detecting and reporting entities: - Non co-located detecting and reporting entities:
- 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 (AIS), communication between them (e.g., Server Signal Failures (Alarm
etc.) Indication Signal (AIS)), etc.)
- 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 [LMP]).
4.2 Failure Localization and Isolation 4.2 Failure Localization and Isolation
Failure localization provides to the deciding entity information Failure localization provides to the deciding entity information
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 take 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.5). This is consuming failure isolation (see also Section 4.5). This is
particularly the case when edge-to-edge LSP recovery (edge referring particularly the case when edge-to-edge LSP recovery (edge referring
to a sub-network end-node for instance) is performed based on a to a sub-network end-node for instance) is performed based on a
simple failure notification (including the identification of the simple failure notification (including the identification of the
working LSPs under failure condition). In this case, a more accurate working LSPs under failure condition). In this case, a more accurate
skipping to change at line 316 skipping to change at line 375
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 unavailable (via the transport plane), the control
plane level where dedicated signaling messages can be used. When plane level where dedicated signaling messages can be used. When
performed at the control plane level, a protocol such as LMP (see performed at the control plane level, a protocol such as LMP (see
[LMP], Section 6) can be used for failure localization purposes. [LMP], 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 a 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 2) to inform the
recovery deciding entities (which can correspond to any intermediate
D.Papadimitriou et al. - Internet Draft - Expires November 2003 6 D.Papadimitriou et al. - Internet Draft - Expires March 2004 7
or end-point of the failed LSP/span) that the corresponding service deciding entities (which can correspond to any intermediate or end-
is not available. In general, these deciding entities will be the point of the failed LSP/span) that the corresponding service is not
ones taking the appropriate recovery decision. When co-located with available. In general, these deciding entities will be the ones
the recovering entity, these entities will also perform the taking the appropriate recovery decision. When co-located with the
recovering entity, these entities will also perform the
corresponding recovery action(s). corresponding recovery action(s).
Failure notification can be either provided by the transport or by Failure notification can be either provided 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
skipping to change at line 348 skipping to change at line 407
the service is no longer available. 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 status, 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 a protection type (such as those defined in directly initiate either a certain type of protection switching
[CCAMP-TERM]) via the transport plane or a restoration type/scheme (such as those described in [TERM]) via the transport plane or
via the management plane. The difference between recovery type and restoration actions via the management plane.
scheme is detailed in Section 5.4.
On the other hand, using a failure notification mechanism through On the other hand, using a failure notification mechanism through
the control plane would provide the possibility to trigger either a the control plane would provide the possibility to trigger 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 [RFC-3471], notification message exchanges Moreover, as specified in [RFC-3473], 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
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. status 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 most efficient subsequent recovery action will be taken (in the most efficient subsequent recovery action will be taken (in
D.Papadimitriou et al. - Internet Draft - Expires November 2003 7 D.Papadimitriou et al. - Internet Draft - Expires March 2004 8
most of the recovery types and schemes this action is even most of the recovery types and schemes this action is even
deterministic) at the recovering entities. Remember here that deterministic) at the recovering entities. Remember here that
these entities can be either intermediate or end-points through these entities can be either intermediate or end-points through
which normal traffic flows. Based on local policy, intermediate which normal traffic flows. Based on local policy, intermediate
nodes may not use this information for subsequent recovery actions nodes may not use this information for subsequent recovery actions
(see for instance the APS protocol phases as described in [CCAMP- (see for instance the APS protocol phases as described in [TERM]).
TERM]). In addition, since fast notification is a mechanism In addition, since fast notification is a mechanism running in
running in collaboration with the existing signalling (see for collaboration with the existing GMPLS signalling (see [RFC-3473])
instance, [RFC-3473]), it allows intermediate nodes to stay that also allows intermediate nodes to stay informed about the
informed about the status of the working LSP/spans under failure status of the working LSP/spans under failure condition.
condition.
The trade-off here is to define what information the LSP/span end- The trade-off here is to define what information the LSP/span end-
points (more precisely, the deciding entity) needs in order for points (more precisely, the deciding entity) needs in order for
the recovering entity to take the best recovery action: if not the recovering entity to take the best recovery action: if not
enough information is provided, the decision can not be optimal enough information is provided, the decision can not be optimal
(note that in this eventuality, the important issue is to quantify (note that in this eventuality, the important issue is to quantify
the level of sub-optimality), if too much information is provided the level of sub-optimality), if too much information is provided
the control plane may be overloaded with unnecessary information the control plane may be overloaded with unnecessary information
and the aggregation/correlation of this notification information and the aggregation/correlation of this notification information
will be more complex and time consuming to achieve. Note that a will be more complex and time consuming to achieve. Note that a
skipping to change at line 422 skipping to change at line 479
suppression (i.e. alarm suppression) is provided in order to limit suppression (i.e. alarm suppression) is provided in order to limit
flooding in case of multiple and/or correlated failures appearing flooding in case of multiple and/or correlated failures appearing
at several locations in the network. at several locations in the network.
- Alarm correlation and aggregation (at the failure detecting - Alarm correlation and aggregation (at the failure detecting
node) implies a consistent decision based on the conditions for node) implies a consistent decision based on the conditions for
which a trade-off between fast convergence (at detecting node) and which a trade-off between fast convergence (at detecting node) and
fast notification (implying that correlation and aggregation fast notification (implying that correlation and aggregation
occurs at receiving end-points) can be found. occurs at receiving end-points) can be found.
4.5 Correlating Failure Conditions 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 result into
reporting multiple failures (such as individual LSP failures) reporting multiple failures (such as individual LSP failures)
conditions. These can be grouped (i.e. correlated) to reduce the conditions. These can be grouped (i.e. correlated) to reduce the
number of failure conditions communicated on the reporting channel, number of failure conditions communicated on the reporting channel,
for both in-band and out-of-band failure reporting. for both in-band and out-of-band failure reporting.
D.Papadimitriou et al. - Internet Draft - Expires November 2003 8 D.Papadimitriou et al. - Internet Draft - Expires March 2004 9
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 [LMP-WDM]) or when using Signal Failure/
Degrade Group in the Sonet/SDH context. 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, it can be advisable to provide a per-node configurable
failure correlation time. The detailed selection criteria for this failure correlation time. The detailed selection criteria for this
time interval are outside of the scope of this document. time 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 (for instance, a fiber cut), each one containing a set of failure (for instance, a fiber cut), each one containing a set of
information on the failed working resources (for instance, the information on the failed working resources (for instance, the
individual lambda LSP flowing through this fiber). This allows for a individual lambda LSP flowing through this fiber). This allows for a
more prompt response but can potentially overload the control plane more prompt response but can potentially overload the control plane
due to a large amount of failure notifications. 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 For both protection and restoration, and when applicable, recovery
resources are provisioned using GMPLS signalling capabilities. Thus, resources are provisioned using GMPLS signalling capabilities. Thus,
these are control plane-driven actions (topological and resource- these are control plane-driven actions (topological and resource-
constrained) that are always performed in this context. constrained) that are always performed in this context.
The following table gives 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 Schemes 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
Note: in the LSP/span protection context control plane actions can Note: in the context of LSP/span protection, control plane actions
be performed either for operational purposes and/or synchronization can be performed either for operational purposes and/or
purposes (vertical synchronization between transport and control synchronization purposes (vertical synchronization between transport
plane) and/or notification purposes (horizontal synchronization and control plane) and/or notification purposes (horizontal
between nodes at control plane level). This suggests the selection synchronization between end-nodes at control plane level). This
of the responsible plane (in particular for protection switching) suggests the selection of the responsible plane (in particular for
during the provisioning phase of the protected/protection LSP. protection switching) during the provisioning phase of the
protected/protection LSP.
2. LSP/span Restoration Schemes 2. LSP/span Restoration
D.Papadimitriou et al. - Internet Draft - Expires November 2003 9 D.Papadimitriou et al. - Internet Draft - Expires March 2004 10
- 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 in/dependent mechanisms
The present recovery mechanisms analysis applies in fact to any The present recovery mechanisms analysis applies in fact to any
circuit oriented data plane technology with discrete bandwidth circuit oriented data plane technology with discrete bandwidth
increments (like Sonet/SDH, G.709 OTN, etc.) being controlled by a increments (like Sonet/SDH, G.709 OTN, etc.) being controlled by a
GMPLS-based distributed control plane. GMPLS-based 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 lists pro and cons for each of them in versus another. They just list pro and cons for each of them in
order to determine the mechanisms that GMPLS-based recovery must order to determine the mechanisms that GMPLS-based recovery must
deliver to overcome their cons and take benefits of their pros in deliver to overcome their cons and take benefits of their pros in
their respective applicability context. their respective 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 considerations.
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")
presents mainly the following advantages: present mainly the following advantages:
- benefits from a simpler architecture making it more suitable for - benefits from a simpler architecture making it more suitable for
mesh-based recovery types and schemes (on a per channel basis). mesh-based recovery types and schemes (on a per channel basis).
- when providing suppression of intermediate node transponders (vs. - when providing suppression of intermediate node transponders (vs.
use of non-standard masking of upstream failures) 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 upper layer driven edge nodes giving the possibility to initiate recovery actions
recovery actions. driven by upper layers.
The main disadvantage comes from the lack of interworking due to the The main disadvantage comes from the lack of interworking due to the
large amount of failure management (in particular failure large amount of failure management (in particular failure
notification 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 since corresponding detection technologies are under
specification. specification.
5.2.3 Sonet/SDH Recovery 5.2.3 Sonet/SDH Recovery
D.Papadimitriou et al. - Internet Draft - Expires November 2003 10 D.Papadimitriou et al. - Internet Draft - Expires March 2004 11
Some of the advantages of Sonet/SDH and more generically any TDM Some of the advantages of Sonet/SDH [T1.105]/[G.707] and more
transport plane recovery are that they provide: generically any 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 are
standardized (see [G.841]) and can operate across protected standardized (see [G.841]) and can operate across protected
domains and interwork (see [G.842]). domains 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 be recovered with respect to coarser optical channel (or whole can 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 layer 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,
(Dedicated SNCP or Shared Protection Rings) has a reduced typically, dedicated Sub-Network Connection Protection (SNCP) or
flexibility with respect to the somewhat more complex and shared protection rings, has reduced flexibility and resource
more resource efficient mesh-based recovery types and schemes. efficiency with respect to the (somewhat more complex) meshed
recovery.
- Inefficient use of spare capacity: Sonet/SDH protection is largely - Inefficient use of spare capacity: Sonet/SDH protection is largely
applied for ring topologies, where spare capacity often remains applied to ring topologies, where spare capacity often remains
idle, making the efficiency of bandwidth usage an 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 element management systems capabilities. elements and the capabilities of the element management systems
(justifying thus the development of GMPLS-based distributed
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 Signalling
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 i.e. in-fiber or out-of-fiber (through a dedicated physically
diverse control network referred to as the Data Communication diverse control network referred to as the Data Communication
Network or DCN). The potential impact of the usage of an in-fiber Network or DCN). The potential impact of the usage of an in-fiber
(signalling) transport mechanism is briefly considered here. (signalling) transport mechanism is briefly considered here.
In-fiber transport mechanism can be further subdivided into in-band In-fiber transport mechanism 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 signalling reduces to the consideration of
a logically versus physically embedded control plane topology with a 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, since we assume that IP terminating control channels document, it is assumed that at least one IP control channel between
between nodes must be continuously available to enable the exchange each pair of adjacent nodes is continuously available to enable the
of recovery-related information and messages, one considers that in exchange of recovery-related information and messages. Thus, in
either case (i.e. in-band or out-of-band) at least one logical either case (i.e. in-band or out-of-band) at least one logical or
channel or one physical channel between nodes is always available.
D.Papadimitriou et al. - Internet Draft - Expires March 2004 12
physical control channel between each pair of nodes is always
expected to be available.
D.Papadimitriou et al. - Internet Draft - Expires November 2003 11
Therefore, the key issue when using in-fiber signalling is whether Therefore, the key issue when using in-fiber signalling is whether
we can assume independence between the fault-tolerance capabilities one can assume independence between the fault-tolerance capabilities
of control plane and the failures affecting the transport plane of 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 by dedicating a separate optical supervisory channel (OSC, signaling by dedicating a separate optical supervisory channel (OSC,
see [G.709] and [G.874]) to transport the overhead and other control see [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- versus Bi-directional Failures
skipping to change at line 643 skipping to change at line 706
Notification Notification
t2 <--------...--------x x--------...--------> t2 <--------...--------x x--------...-------->
Up Notification Down Notification Up Notification Down Notification
------- ------- ------- ------- ------- ------- ------- -------
| | | |Tx Rx| | | | | | | |Tx Rx| | | |
| NodeA |----...----| NodeB |xxxxxxxxx| NodeC |----...----| NodeD | | NodeA |----...----| NodeB |xxxxxxxxx| NodeC |----...----| NodeD |
| |----...----| |xxxxxxxxx| |----...----| | | |----...----| |xxxxxxxxx| |----...----| |
------- ------- ------- ------- ------- ------- ------- -------
D.Papadimitriou et al. - Internet Draft - Expires March 2004 13
t0 F <<<<<<< >>>>>>> F t0 F <<<<<<< >>>>>>> F
D.Papadimitriou et al. - Internet Draft - Expires November 2003 12
t1 x <-------------> x t1 x <-------------> x
Notification Notification
t2 <--------...--------x x--------...--------> t2 <--------...--------x x--------...-------->
Up Notification Down Notification Up Notification Down Notification
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 Fig. 1 (Fig.
2), node C sends a notification message to node B (while node B 2), node C sends a notification message to node B (while node B
sends a notification message to node A). To ensure reliable sends a notification message to node C). To ensure reliable
failure notification, a dedicated acknowledgment message can be failure notification, a dedicated acknowledgment message can be
returned back to the sender node. 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 perform their correlation. In impacted by the failure occurrences may perform their correlation.
case of unidirectional failure, node B only receives the In case of unidirectional 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. However, in case of bi-directional operation is negligible. In case of bi-directional failure, node B
failure, node B (and node C) must correlate the received (and node C) has to correlate the received notification message
notification message from node C (node B, respectively) with the from node C (node B, respectively) with the corresponding locally
corresponding locally detected information. detected information.
- 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 local recovery actions were not hold-off time, after which the local recovery actions (see Section
successful, the following occurs. In case of unidirectional 5.3.4) were not successful, the following occurs. In case of
failure and depending on the directionality of the connection, unidirectional failure and depending on the directionality of the
node B should send an upstream notification message to the ingress LSP, node B should send an upstream notification message (see
node A or node C should send a downstream notification to the [RFC-3473]) to the ingress node A and node C may send a downstream
egress node D. However, in such a case only node A (node D, notification message (see [RFC-3473]) to the egress node D.
respectively) referred to as the master and node D, to as the However, in such a case only node A referred to as the "master"
slave per [CCAMP-TERM], would initiate a edge to edge recovery (node D being then referred to as the "slave" per [TERM]), would
action. Note that the connection terminating node (i.e. node D or initiate an edge to edge recovery action. Note that the other LSP
node A) may be optionally notified. end-node (i.e. node D in this case) may be optionally notified
using a downstream notification message (see [RFC-3473]).
In case of bi-directional failure, node B may send an upstream In case of bi-directional failure, node B should send an upstream
notification message to the ingress node A or node C a downstream notification message (see [RFC-3473]) to the ingress node A and
notification to the egress node D. However, due to the dependence node C may send a downstream notification message (see [RFC-3473])
on the connection directionality, only ingress node A or egress to the egress node D. However, due to the dependence on the LSP
node D would initiate an edge to edge recovery action. Note that directionality, only ingress node A would initiate an edge to edge
the connection terminating node (i.e. node D or node A) should be recovery action. Note that the other LSP end-node (i.e. node D in
also notified of this event using upstream and downstream fast this case) should also be notified of this event using a
notification (see [RFC-3471]). For instance, if a connection downstream notification message (see [RFC-3473]). For instance, if
directed from D to A is under failure condition, only the an LSP directed from D to A is under failure condition, only the
notification sent from node C to D would initiate a recovery notification message sent from node C to D would initiate a
action. Here as well, per [CCAMP-TERM], the deciding (and recovery action and, in this case, per [TERM], the deciding and
recovering) node D is referred to as the "master" while the node A recovering node D is referred to as the "master" while node A is
is referred to as the "slave" (i.e. recovering only entity). referred to as the "slave" (i.e. recovering only entity).
D.Papadimitriou et al. - Internet Draft - Expires March 2004 14
Note: The determination of the master and the slave may be based Note: The determination of the master and the slave may be based
D.Papadimitriou et al. - Internet Draft - Expires November 2003 13
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 notification In the above scenarios, the path followed by the upstream and
messages does not have to be the same as the one followed by the downstream notification messages does not have to be the same as the
failed LSP (see [RFC-3471], for more details on the notification one followed by the failed LSP (see [RFC-3473] for more details on
message exchange). The important point, concerning this mechanism, the notification message exchange). The important point, concerning
is that either the detecting/reporting entity (i.e. the nodes B and this mechanism, is that either the detecting/reporting entity (i.e.
C) are also the deciding/recovery entity or the detecting/reporting the nodes B and C) is also the deciding/recovery entity or the
entities are simply intermediate nodes in the subsequent recovery detecting/reporting entity is simply an intermediate node in the
process. One refers to local recovery in the former case and to subsequent recovery process. One refers to local recovery in the
edge-to-edge recovery in the latter one. former case and to edge-to-edge recovery in the latter one (see also
Section 5.3.4).
5.3.3 Partial versus Full Span Recovery 5.3.3 Partial versus Full Span Recovery
When given span carries more than one LSPs or LSP segments, an When a given span carries more than one LSPs or LSP segments, an
additional aspect must be considered during span failure carrying additional aspect must be considered. In case of span failure, the
several LSPs. These LSPs can be either individually recovered or LSPs it carries can be either individually recovered or recovered as
recovered as a group (aka bulk LSP recovery) or independent sub- a group (aka bulk LSP recovery) or independent sub-groups. The
groups. The selection of this mechanism would be triggered selection of this mechanism would be triggered independently of the
independently of the failure notification granularity when failure notification granularity when correlation time windows are
correlation time windows are used and simultaneous recovery of used and simultaneous recovery of several LSPs can be performed
several LSPs can be performed using single request. Moreover, using a single request. Moreover, criteria by which such sub-groups
criteria by which such sub-groups can be formed are outside of the can be formed are outside of the scope of this document.
scope of this document.
An additional complexity arises in case of (sub-)group LSP recovery. Additional complexity arises in the case of (sub-)group LSP
Between a given node pair, the LSPs a given (sub-)group contains may recovery. Between a given pair of nodes, the LSPs that a given (sub-
have been created from different source (i.e. initiator) nodes )group contains may have been created from different source nodes
toward different destinations nodes. Consequently the failure (i.e. initiator) and directed toward different destinations nodes.
notification messages sub-sequent to a bi-directional span failure Consequently the failure notification messages sub-sequent to a bi-
affecting several LSPs (or the whole group of LSPs it carries) are directional span failure affecting several LSPs (or the whole group
not necessarily directed toward the same initiator nodes. In of LSPs it carries) are not necessarily directed toward the same
particular these messages may be directed to both the upstream and initiator nodes. In particular these messages may be directed to
downstream nodes to the failure. Therefore, such span failure may both the upstream and downstream nodes to the failure. Therefore,
trigger recovery actions to be performed from both sides (i.e. both such span failure may trigger recovery actions to be performed from
from the upstream and the downstream node to the failure). In order both sides (i.e. both from the upstream and the downstream node to
to facilitate the definition of the corresponding recovery the failure). In order to facilitate the definition of the
mechanisms (and their sequence), one assumes here as well, that per corresponding recovery mechanisms (and their sequence), one assumes
[CCAMP-TERM] the deciding (and recovering) entity, referred to as here as well, that per [TERM] the deciding (and recovering) entity,
the "master" is the only initiator of the recovery of the whole LSP referred to as the "master" is the only initiator of the recovery of
(sub-)group. 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 [CCAMP-TERM] are quite generic and The recovery definitions given in [TERM] are quite generic and apply
apply for link (or local span) and LSP recovery. The major for link (or local span) and LSP recovery. The major difference
difference between LSP, LSP Segment and span recovery is related to between LSP, LSP Segment and span recovery is related to the number
the number of intermediate nodes that the signalling messages have of intermediate nodes that the signalling messages have to travel.
to travel. Since nodes are not necessarily adjacent in case of LSP Since nodes are not necessarily adjacent in case of LSP (or LSP
(or LSP Segment) recovery, signalling message exchanges from the Segment) recovery, signalling message exchanges from the reporting
reporting to the deciding/recovery entity will have to cross several to the deciding/recovery entity may have to cross several
intermediate nodes. In particular, this applies for the notification
messages due to the number of hops separating the failure occurrence
D.Papadimitriou et al. - Internet Draft - Expires November 2003 14 D.Papadimitriou et al. - Internet Draft - Expires March 2004 15
location from their destination. This results in an additional intermediate nodes. In particular, this applies for the notification
propagation and forwarding delay. Note that the former delay may in messages due to the number of hops separating the location of a
certain circumstances be non-negligible e.g. in case of copper out- failure occurrence from its destination. This results in an
of-band network one has to consider approximately 1 ms per 200km. additional propagation and forwarding delay. Note that the former
delay may in certain circumstances be non-negligible; e.g. in case
of copper out-of-band network, approximately 1 ms per 200km.
Moreover, the recovery mechanisms applicable to end-to-end LSP and Moreover, the recovery mechanisms applicable to end-to-end LSPs and
to the segments (i.e. edge-to-edge recovery) that may compose an to the segments that may compose an end-to-end LSP (i.e. edge-to-
end-to-end LSP 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 will be the ingress of each of these segments. Therefore, message will be the ingress/egress of each of these segments.
taking into account the mechanism described in Section 5.3.2, Therefore, using the mechanisms described in Section 5.3.2, failure
failure notification can be first exchanged between the LSP segments notification messages can be first exchanged between terminating
terminating points and after expiration of the hold-off time points of the LSP segment and after expiration of the hold-off time
directed toward end-to-end LSP terminating points. be directed toward 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, LSP restoration's performance can be enhanced by a failed Also, performance of LSP restoration can be enhanced by a failed
working LSP's source node launching a new recovery attempt if an working LSP's source node initiating 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 restoration success rate and produce large increases in the restoration success rate and ability
availability, especially at high loads, while not adding to initiate successful LSP restoration attempts, especially at high
significantly to the long-term average recovery time. Allowing loads, while not adding significantly to the long-term average
additional attempts produces only small additional gains in recovery time. Allowing additional attempts produces only small
performance. This suggests using additional (intermediate) crankback additional gains in performance. This suggests using additional
signalling when using dynamic LSP restoration (described in Section (intermediate) crankback signalling when using dynamic LSP
5.5.2 - case 2). Details on crankback signalling are outside of restoration (described in Section 5.5.2 - case 2). Details on
scope of the present document. crankback signalling are outside the scope of the present document.
5.4 Difference between Recovery Type and Scheme 5.4 Difference between Recovery Type and Scheme
Section 4.6 of [CCAMP-TERM] defines the basic LSP/span recovery [TERM] defines the basic LSP/span recovery types. This section
types. The purpose of this section is to describe the recovery describes the recovery schemes that can be built using these
schemes that can be built using these recovery types. In brief, a recovery types. In brief, a recovery scheme is defined as the
recovery scheme is defined as the combination of several ingress- combination of several ingress-egress node pairs supporting a given
egress node pairs supporting a given recovery type (from the set of recovery type (from the set of the recovery types they allow).
the recovery types they allow). Several examples are provided here Several examples are provided here to illustrate the difference
to illustrate the difference between recovery types such as 1:1 or between recovery types such as 1:1 or M:N and recovery schemes such
M:N and recovery schemes such as (1:1)^n or (M:N)^n referred to as as (1:1)^n or (M:N)^n referred to as shared-mesh recovery.
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 applied between at most n different ingress-egress node pairs. is applied between at most n different ingress-egress node pairs.
Here, at most n pairs of disjoint working and recovery LSPs/spans
D.Papadimitriou et al. - Internet Draft - Expires November 2003 15 D.Papadimitriou et al. - Internet Draft - Expires March 2004 16
Here, at most n pairs of disjoint working and recovery LSPs/spans
share at most n times a common resource. Since the working LSPs/ share at most n times a common resource. Since the working LSPs/
spans are mutually disjoint, simultaneous requests for use of the spans are mutually disjoint, simultaneous requests for use of the
shared (common) resource will only occur in case of simultaneous shared (common) resource will only occur in case of simultaneous
failures, which is less likely to happen. failures, which is less likely to happen.
For instance, in the (1:1)^2 common 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 working LSPs A-B-C and F-G-H instance the following topology with the working LSPs A-B-C and F-G-
and recovery LSPs A-D-E-C and F-D-E-H sharing a common D-E link H and their respective recovery LSPs A-D-E-C and F-D-E-H that share
resource. a 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 expected that GMPLS capabilities would support only (i.e. it is not mandated that GMPLS capabilities would support
this scheme). The exponent, n, indicates the number of times a M:N this 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,
expect that here disjointness applies to the N working LSPs/spans except that here disjointness applies to the N working LSPs/spans
and to the M recovery LSPs/spans while sharing at most n times M and to the M recovery LSPs/spans while sharing at most n times M
common resources. common resources.
In both schemes, one may see the following at the LSP level: we have In both schemes, it results a "group" of sum{n=1}^N N{n} working
a "group" of sum{n=1}^N N{n} working LSPs and a pool of shared LSPs and a pool of shared recovery resources, not all of which are
recovery resources, not all of which are available to any given available to any given working LSP. In such conditions, defining a
working path. In such conditions, defining a metric that describes metric that describes the amount of overlap among the recovery LSPs
the amount of overlap among the recovery LSPs would give some would give some indication of the group's ability to handle
indication of the group's ability to handle multiple simultaneous simultaneous failures of multiple LSPs.
failures.
For instance, in the simple (1:1)^n case situation if n recovery For instance, in the simple (1:1)^n case, if n recovery LSPs in a
LSPs in a (1:1)^n group overlap, then it can handle only single (1:1)^n group overlap, then it can handle only single failures; any
failures; any multiple working LSP failures will cause at least one simultaneous failure of multiple working LSPs will cause at least
working LSP to be denied automatic recovery. But if one consider for one working LSP to be denied automatic recovery. But if one consider
instance, a (2:2)^2 group in which there are two pairs of for instance, a (2:2)^2 group in which there are two pairs of
overlapping recovery LSPs, then two LSPs (belonging to the same overlapping recovery LSPs, then two LSPs (belonging to the same
pair) can be simultaneously recovered. The latter case can be pair) can be simultaneously recovered. The latter case can be
illustrated as follows: 2 working LSPs A-B-C and F-G-H and 2 illustrated by the following topology with 2 pairs of working LSPs
recovery LSPs A-D-E-C and F-D-E-H sharing the two common D-E link A-B-C and F-G-H and their respective recovery LSPs A-D-E-C and F-D-
resources. E-H that share two common D-E link resources.
D.Papadimitriou et al. - Internet Draft - Expires November 2003 16 D.Papadimitriou et al. - Internet Draft - Expires March 2004 17
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
reinforced by exchanging working LSP related information during the enforced by exchanging information related to working LSPs during
recovery LSP signalling. Specific issues related to the combination the recovery LSP signaling. Specific issues related to the
of shared (discrete) bandwidth and disjointness for recovery schemes combination of shared (discrete) bandwidth and disjointness for
are described in Section 8.4.2. recovery schemes 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
LSPs/spans recovery time and ratio depend on the proper recovery LSP LSPs/spans recovery time and ratio depend on the proper recovery LSP
provisioning (meaning pre-provisioning when performed before failure provisioning (meaning pre-provisioning when performed before failure
occurrence) and the level of recovery resources overbooking (i.e. occurrence) and the level of recovery resources overbooking (i.e.
over-provisioning). A proper balance of these two mechanisms will over-provisioning). A proper balance of these two operations will
result in a desired LSP/span recovery time and ratio when single or result in the desired LSP/span recovery time and ratio when single
multiple failure(s) occur(s). or multiple failure(s) occur(s). Note also that these operations are
mostly performed during the network planning phases.
The different options for LSP (pre-)provisioning and overbooking are
classified here below to structure the analysis of the different
recovery mechanisms.
1. Pre-Provisioning
Proper recovery LSP pre-provisioning will help to alleviate the
failure of the working LSPs (due to the failure of the resources
that carry these LSPs). As an example, one may compute and establish
the recovery LSP either end-to-end or segment-per-segment, to
protect a working LSP from multiple failure events affecting
link(s), node(s) and/or SRLG(s). The recovery LSP pre-provisioning
options can be classified (as shown in the below figure) as follows:
(1) the recovery path can be either pre-computed or computed
on-demand.
(2) when the recovery path is pre-computed, it can be either pre-
signaled (implying recovery resource reservation) or signaled
on-demand.
(3) when the recovery resources are pre-reserved, they can be either
pre-selected or selected on-demand.
Recovery LSP provisioning phases: Recovery LSP provisioning phases:
(1) Route Computation --> On-demand D.Papadimitriou et al. - Internet Draft - Expires March 2004 18
(1) Path Computation --> On-demand
| |
| |
--> Pre-Computed --> Pre-Computed
| |
| |
(2) Signalling --> On-demand (2) Signalling --> 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
recovery times. The following sections will consider the above-
mentioned pre-provisioning options when analyzing the different
recovery mechanisms.
2. Overbooking
There are many mechanisms available that allow the overbooking of
the recovery resources. This overbooking can be done per LSP (such
as the example mentioned above), per link (such as span protection)
or even per domain. In all these cases, the level of overbooking, as
shown in the below figure, can be classified as dedicated (such as
1+1 and 1:1), shared (such as 1:N and M:N) or unprotected (and thus
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.)
| |
| |
+----- 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)
D.Papadimitriou et al. - Internet Draft - Expires November 2003 17 Also, when using shared recovery, one may support preemptible extra-
In this figure, we present a classification of different options traffic; the recovery mechanism is then expected to allow preemption
under LSP (pre-)provisioning and overbooking. Although these of this low priority traffic in case of recovery resource contention
operations are mostly performed during network planning and (pre-) during recovery operations. The following sections will consider the
provisioning phases using GMPLS signaling capabilities, we keep them above-mentioned overbooking options when analyzing the different
in analyzing the recovery types. recovery mechanisms.
Proper LSP/span (pre-)provisioning will help in alleviating many of
the failures. As an example, one may compute and establish the
working and the recovery paths either end-to-end or segment-per-
segment, to protect an LSP from multiple failure events affecting
link(s), node(s) and/or SRLG(s). Such working and recovery LSP/span
provisioning can be categorized, as shown in the above figure, as
follows:
(1) the recovery path (i.e. route) can be either pre-computed or
computed on demand.
(2) when the recovery path is pre-computed: pre-signaled (implying
recovery resource reservation) or signaled on demand.
(3) and when the recovery resources are pre-signaled, they can be
either pre-selected or selected on-demand.
Note that these different options give rise to different LSP/span
recovery times. The following subsections will consider all the
above-mentioned (pre-)provisioning scenarios when analyzing the
different recovery mechanisms.
There are many mechanisms available allowing the overbooking of the
recovery resources. This overbooking can be done per LSP (such as
the example mentioned above), per link (such as span protection) or
per domain (such as ring topologies). In all these cases the level
of overbooking, as shown in the above figure, can be classified as
dedicated (such as 1+1 and 1:1), shared (such as 1:N and M:N) or
unprotected (i.e. restorable if enough recovery resources are
available).
When using shared restoration, one may support preemptable (preempt
low priority connections in case of resource contention) extra-
traffic. In this document, we consider all the above-mentioned
overbooking mechanisms in analyzing the corresponding recovery
scheme.
5.5.2 LSP Restoration Mechanisms 5.5.2 LSP Restoration
First, we define the following times to provide a quantitative D.Papadimitriou et al. - Internet Draft - Expires March 2004 19
estimation about the time performance of the different LSP The following times are defined to provide a quantitative estimation
restoration mechanisms (also referred to as LSP re-routing): about the time performance of the different LSP restoration
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: 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
D.Papadimitriou et al. - Internet Draft - Expires November 2003 18
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
LSPs paths between a given source/destination is pre-computed and LSP paths between a given pair of source/destination end-points is
after failure occurrence one of these paths is selected for the pre-computed and after a failure occurrence one of these paths is
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 as equivalently time correlation and notification are considered (for a given failure
consuming for all the mechanisms described here below: event) as equally time consuming for all the mechanisms described
here 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 (i.e. route). As such, one can occur(s) based on a pre-computed path. As such, one can define this
define this as an "LSP re-provisioning" mechanism. Here, one or more as an "LSP re-provisioning" mechanism. Here, one or more (disjoint)
(disjoint) routes for the restoration path are computed (and paths for the restoration LSP are computed (and optionally pre-
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. As a result, there is no guarantee restoration path before failure occurrence. As a result, there is no
that a restoration connection 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
when a dedicated computation is performed for each working LSP to to Trs when a dedicated computation is performed for each working
Trs. LSP.
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, one or more (disjoint) explicit routes failure(s) occur(s). Here, after failure occurrence, one or more
for the restoration path are dynamically computed and one is (disjoint) paths for the restoration LSP are dynamically computed
selected after failure. As such, one can define this as a complete and one is selected. As such, one can define this as a complete "LSP
"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. As a result, there is no guarantee restoration path before failure occurrence. As a result, there is no
that a restoration connection 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
D.Papadimitriou et al. - Internet Draft - Expires March 2004 20
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 or not.
D.Papadimitriou et al. - Internet Draft - Expires November 2003 19
1. With resource reservation and without resource pre-selection 1. With resource reservation and without resource pre-selection
An end-to-end restoration path is pre-selected from a set of one or Before failure occurrence, an end-to-end restoration path is pre-
more pre-computed (disjoint) explicit route before failure. 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 (i.e. signaled) at each node but resources are not resources at each node but these resources are not selected.
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 different working LSP that are not dedicated or shared between multiple restoration LSPs whose working
expected to fail simultaneously. Local node policies can be applied LSPs are not expected to fail simultaneously. Local node policies
to define the degree to which these resources are shared across can be applied to define the degree to which these resources can be
independent failures. shared across independent failures. Also, since a restoration scheme
is considered, resource sharing should not be limited to restoration
LSPs starting and ending at the same ingress and egress nodes.
Therefore, each node participating to this scheme is expected to
receive some feedback information on the sharing degree of the
recovery resource(s) that this scheme involves.
Upon failure detection, signaling is initiated along the restoration Upon failure detection/notification message reception, signaling is
path to select the resources, and to perform the appropriate initiated along the restoration path to select the resources, and to
operation at each node entity involved in the restoration connection perform the appropriate operation at each node crossed by the
(e.g. cross-connections). restoration LSP (e.g. cross-connections). If lower priority LSPs
were established using the restoration resources, they MUST be
preempted when the restoration LSP is activated.
The expected total restoration time T is thus 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 takes 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
An end-to-end restoration path is pre-selected from a set of one or Before failure occurrence, an end-to-end restoration path is pre-
more pre-computed (disjoint) explicit route before failure. 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 not cross-connected. Such that AND select resources at each node but these resources are not
the selection of the recovery resources is fixed at the control committed at the data plane level. Such that the selection of the
plane level. However, no cross-connections are performed along the recovery resources is committed at the control plane level only, no
restoration path. cross-connections are performed along the restoration path.
In this case, the resources reserved for each restoration LSP may In this case, the resources reserved and selected for each
only be shared between different working LSPs that are not expected restoration LSP may be dedicated or even shared between multiple
to fail simultaneously. Since a restoration scheme is considered restoration LSPs whose associated working LSPs are not expected to
here, the sharing degree should not be limited to working (and
recovery) LSPs starting and ending at the same ingress and egress
nodes. Therefore, one expects to receive some feedback information
on the recovery resource sharing degree at each node participating
to the recovery scheme.
Upon failure detection, signaling is initiated along the restoration D.Papadimitriou et al. - Internet Draft - Expires March 2004 21
path to activate the reserved and selected resources and to perform fail simultaneously. Local node policies can be applied to define
the appropriate operation at each node involved in the restoration the degree to which these resources can be shared across independent
connection (e.g. cross-connections). failures. Also, since a restoration scheme is considered, resource
sharing should not be limited to restoration LSPs starting and
ending at the same ingress and egress nodes. Therefore, each node
participating to this scheme is expected to receive some feedback
information on the sharing degree of the recovery resource(s) that
this scheme involves.
Upon failure detection/notification message reception, signaling is
initiated along the restoration path to activate the reserved and
selected resources, and to perform the appropriate operation at each
node crossed by the restoration LSP (e.g. cross-connections). If
lower priority LSPs were established using the restoration
resources, they MUST be preempted when the restoration LSP is
activated.
The expected total restoration time T is thus equal to Ta (post- The expected total restoration time T is thus 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 takes 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).
D.Papadimitriou et al. - Internet Draft - Expires November 2003 20
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.
It should be also noted that using the horizontal hierarchical Also, by using the horizontal hierarchy approach described in
approach described in Section 7.1, that a given end-to-end LSP can Section 7.1, an end-to-end LSP can be recovered by multiple recovery
be recovered by multiple recovery mechanisms applied on a segment mechanisms applied on an LSP segment basis (e.g. 1:1 edge-to-edge
basis (e.g. 1:1 edge-to-edge LSP protection in a metro network and LSP protection in a metro network and M:N edge-to-edge protection in
M:N edge-to-edge protection in the core). These mechanisms are the core). These mechanisms are ideally independent and may even use
ideally independent and may even use different failure localization different failure localization and notification mechanisms.
and notification mechanisms.
6. Normalization 6. Normalization
Normalization is defined as the mechanism allowing switching normal Normalization is defined as the mechanism allowing switching of
traffic from the recovery LSP/span to the working LSP/span normal traffic from the recovery LSP/span to the working LSP/span
previously under failure condition. previously under failure condition. Use of normalization is at the
discretion of the recovery domain policy. Normalization (also
Use of normalization is under the discretion of the recovery domain referred to as reversion) may impact the normal traffic (a second
policy. Normalization (also referred to as reversion) may impact the hit) depending on the normalization mechanism used.
normal traffic (a second hit) depending on the normalization
mechanism used.
If normalization is supported 1) the LSP/span must be returned to If normalization is supported 1) the LSP/span must be returned to
the working LSP/span when the failure condition clears 2) capability the working LSP/span when the failure condition clears 2) the
to de-activate (turn-off) the use of reversion should be provided. capability to de-activate (turn-off) the use of reversion should be
De-activation of reversion should not impact the normal traffic provided. De-activation of reversion should not impact the normal
regardless if currently using the working or recovery LSP/span. traffic regardless of whether currently using the working or
recovery LSP/span.
D.Papadimitriou et al. - Internet Draft - Expires March 2004 22
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 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 operation due to an intermittent defect (e.g. BER recovery switching operations due to an intermittent defect (e.g.
fluctuating around the SD threshold). 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 of 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. The WTR timer may be either a fixed period, or provide for set. The WTR timer may be either a fixed period, or provide for
incremental longer periods before retrying. An SF or SD condition on incrementally longer periods before retrying. An SF or SD condition
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).
D.Papadimitriou et al. - Internet Draft - Expires November 2003 21
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, signalling must maintain the normal traffic on the
skipping to change at line 1157 skipping to change at line 1236
However, deactivation (cancellation) of the wait-to-restore timer However, deactivation (cancellation) of the wait-to-restore timer
may occur in case of 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 can particular situation occurs when the previously working LSP/span
not be recovered such that normal traffic can not be switched back. cannot be recovered such that normal traffic can not be switched
In such a case, the LSP/span under failure condition (also referred back. In such a case, the LSP/span under failure condition (also
to as "orphan") must be cleared i.e. removed from the pool of referred to as "orphan") must be cleared i.e. removed from the pool
resources allocated for normal traffic. Otherwise, potential de- of resources 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 signalling protocol capabilities
and behavior different mechanisms are to be expected here. and behavior different mechanisms are expected here.
D.Papadimitriou et al. - Internet Draft - Expires March 2004 23
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: wait for the elapsing of the clear-out be used for that purpose: either wait for the elapsing of the clear-
time interval, or initiate a deletion from the ingress or the egress out time interval, or initiate a deletion from the ingress or the
node, or trigger the initiation of deletion from an entity (such as egress node, or trigger the initiation of deletion from an entity
an EMS or NMS) capable to react on the reception of an appropriate (such as an EMS or NMS) capable to react on the reception of an
notification message. appropriate 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
each) transport layers within so-called "IP/MPLS-over-optical" each) transport layers within so-called "IP/MPLS-over-optical"
networks. However, each layer has certain recovery features and one networks. However, each layer has certain recovery features and one
needs to determine the exact impact of the interaction between the needs to determine the exact impact of the interaction between the
recovery mechanisms provided by these layers. recovery mechanisms provided by these layers.
Hierarchies are used to build scalable complex systems. Abstraction Hierarchies are used to build scalable complex systems. Abstraction
is used as a mechanism to build large networks or as a technique for is used as a mechanism to build large networks or as a technique for
enforcing technology, topological or administrative boundaries. The enforcing technology, topological or administrative boundaries. The
same hierarchical concept can be applied to control the network same hierarchical concept can be applied to control the network
D.Papadimitriou et al. - Internet Draft - Expires November 2003 22
survivability. In general, it is expected that the recovery action survivability. In general, it is expected that the recovery action
is taken by the recoverable LSP/span closest to the failure in order is taken by the recoverable LSP/span closest to the failure in order
to avoid the multiplication of recovery actions. Moreover, recovery to avoid the multiplication of recovery actions. Moreover, recovery
hierarchies can be also bound to control plane logical partitions hierarchies can be also bound to control plane logical partitions
(e.g. administrative or topological boundaries). Each of them may (e.g. administrative or topological boundaries). Each of them may
apply different recovery mechanisms. apply different recovery mechanisms.
In brief, commonly accepted ideas are generally that the lower In brief, the commonly accepted ideas are generally that the lower
layers can provide coarse but faster recovery while the higher layers can provide coarse but faster recovery while the higher
layers can provide finer but slower recovery. Moreover, it is also layers can provide finer but slower recovery. Moreover, it is also
desirable to avoid that similar layers with functional overlaps to desirable to avoid that similar layers with functional overlaps to
optimize network resource utilization and processing overhead. In optimize network resource utilization and processing overhead. In
this context, this section intends to analyze these hierarchical this context, this section intends to analyze these hierarchical
aspects including the physical (passive) layer(s). 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), LSP segment or even an end-to-end LSP. Moreover, an span), LSP segment or even an end-to-end LSP. Moreover, an
administrative domain may consist of a single recovery domain or can administrative domain may consist of a single recovery domain or can
be partitioned into several smaller recovery domains. The operator be partitioned into several smaller recovery domains. The operator
can partition the network into recovery domains based on physical can partition the network into recovery domains based on physical
network topology, control plane capabilities or various traffic network topology, control plane capabilities or various traffic
engineering constraints. engineering 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-
D.Papadimitriou et al. - Internet Draft - Expires March 2004 24
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 a very challenging task to combine in a coordinated manner the
different recovery capabilities available across the path (i.e. different recovery capabilities available across the path (i.e.
switching capable) and section layers to ensure that certain network switching capable) and section layers to ensure that certain network
survivability objectives are met for the different services survivability objectives are met for the different services
supported by the network. 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 lower the layer the faster the notification and switching
- The higher the layer the finer the granularity of the recoverable - The higher the layer the finer the granularity of the recoverable
entity and therefore the granularity of the recovery resource entity and therefore the granularity of the recovery resource
(and subsequently its sharing ratio)
D.Papadimitriou et al. - Internet Draft - Expires November 2003 23 Moreover, in the context of this analysis, a vertical hierarchy
Therefore, in the scope 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
- Potentially, recovery capabilities with different temporal - Potentially, 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.
Here below we extend a little bit more on (4), (2) being covered in Here below we briefly extend on (4), (2) being covered in [RFC
[RFC 3386]. On the other hand (1) is extensively covered at the MPLS 3386]. On the other hand (1) is extensively covered at the MPLS
Working Group, and (3) at the PWE3 Working Group. Working Group, and (3) at the PWE3 Working Group.
In SDH/Sonet environments, one typically considers the VT_SPE/LOVC In SDH/Sonet 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, VT_SPE/LOVC LSP using the
underlying STS_SPE/HOVC LSPs as links, for instance. In OTN, the underlying STS_SPE/HOVC LSPs as links, for instance. In OTN, the
ODUk path layers will lie on the OCh path layer i.e. the ODUk LSPs ODUk path layers will lie on the OCh path layer i.e. the ODUk LSPs
using the underlying OCh LSPs as OTUk links. Note here that lower using the underlying OCh LSPs as OTUk links. Note here that lower
layer LSPs may simply be provisioned and not necessarily dynamically layer 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 signalling),
for instance an optical channel LSP, appears at the OTUk layer as a for instance an optical channel LSP, appears at the OTUk layer as a
link, typically controlled by a link management protocol such as link, controlled by a link management protocol such as LMP.
LMP.
The first key issue with multi-layer recovery is that achieving The first key issue with multi-layer recovery is that achieving
control plane individual or bulk LSP recovery will be as efficient individual or bulk LSP recovery will be as efficient as the
as the underlying link (local span) recovery. In such a case, the underlying link (local span) recovery. In such a case, the span can
span can be either protected or unprotected, but the LSP it carries be either protected or unprotected, but the LSP it carries MUST be
MUST be (at least locally) recoverable. Therefore, the span recovery (at least locally) recoverable. Therefore, the span recovery process
process can either be independent when protected (or restorable), or can be either independent when protected (or restorable), or
triggered by the upper LSP recovery process. The former requires triggered by the upper LSP recovery process. The former case
coordination in order to achieve subsequent LSP recovery. Therefore,
D.Papadimitriou et al. - Internet Draft - Expires March 2004 25
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
(pre-determined for instance by the hold-off timer), a failure (for instance, a pre-determined coordination when using a hold-off
notification may propagate from one layer to the next within a timer), a failure notification may propagate from one layer to the
recovery hierarchy. This can cause "collisions" and trigger next one within a recovery hierarchy. This can cause "collisions"
simultaneous recovery actions that may lead to race conditions and and trigger simultaneous recovery actions that may lead to race
in turn, reduce the optimization of the resource utilization and/or conditions and in turn, reduce the optimization of the resource
generate global instabilities in the network (see [MANCHESTER]). utilization and/or generate global instabilities in the network (see
Therefore, a consistent and efficient escalation strategy is needed [MANCHESTER]). Therefore, a consistent and efficient escalation
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 Therefore, one can expect that the definition of the recovery
mechanisms and protocol(s) is technology independent such that they mechanisms and protocol(s) is technology-independent such that they
can be consistently implemented at different layers; this would in can be consistently implemented at different layers; this would in
turn simplify their global coordination. Moreover, as mentioned in turn simplify their global coordination. Moreover, as mentioned in
[RFC 3386], some looser form of coordination and communication [RFC-3386], some looser form of coordination and communication
D.Papadimitriou et al. - Internet Draft - Expires November 2003 24
between (vertical) layers such a consistent hold-off timer between (vertical) layers such a consistent hold-off timer
configuration (and setup through signalling during the working LSP configuration (and setup through signalling during the working LSP
establishment) can be considered in this context, allowing establishment) can be considered, allowing the synchronization
synchronization between recovery actions performed across these between recovery actions performed across these layers.
layers.
Note: Recovery Granularity Note: 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 for 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 only recover the whole section or the individual connections it
transports whereas IP/MPLS layer(s) can recover individual packet transports whereas the IP/MPLS control plane can recover individual
LSPs or groups of packet LSPs. packet LSPs or groups of packet LSPs and this independently of their
granularity. On the other side, the recovery granularity at the sub-
Obviously, the recovery granularity at the sub-wavelength (i.e. wavelength level (i.e. Sonet/SDH) can be provided only when the
Sonet/SDH) level can be provided only when the network includes network includes devices switching at the same granularity (and thus
devices switching at the same granularity level (and thus not with not with optical channel level). Therefore, the network layer can
optical channel switching capable devices). Therefore, the network deliver control-plane driven recovery mechanisms on a per-LSP basis
layer can deliver control-plane driven recovery mechanisms on a per- if and only if these LSPs have their corresponding switching
LSP basis if and only if the LSPs class has the corresponding granularity supported at the transport plane level.
switching capability 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 the upper layer one.
Therefore we can inhibit or hold-off higher layer recovery. However Therefore we can inhibit or hold-off higher layer recovery. However
this assumption is not entirely true. Consider a Sonet/SDH based this assumption is not entirely true. Consider for instance a
protection mechanism (with a less than 50 ms protection switching Sonet/SDH based protection mechanism (with a less than 50 ms
time) lying on top of an OTN restoration mechanism (with a less than protection switching time) lying on top of an OTN restoration
200 ms restoration time). Therefore, this assumption should be (at mechanism (with a less than 200 ms restoration time). Therefore,
least) clarified as: lower layer recovery types and schemes are this assumption should be (at least) clarified as: lower layer
faster than upper level one but only if the same type of recovery
mechanism is used at each layer (assuming that the lower layer one D.Papadimitriou et al. - Internet Draft - Expires March 2004 26
is faster). recovery mechanism is expected to be faster than upper level one 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 timer in order to temporarily set the higher layer recovery off timer in order to temporarily set the higher layer recovery
action in a "standby mode". Note that the a priori information action in a "standby mode". Note that the a priori information
exchange between layers concerning their efficiency is not within exchange between layers concerning their efficiency is not within
the current scope of this document. Nevertheless, the coordination the current scope of this document. Nevertheless, the coordination
functionality between layers must be configurable and tunable. functionality between layers must be configurable and tunable.
D.Papadimitriou et al. - Internet Draft - Expires November 2003 25
An example of coordination between the optical and packet layer An example of coordination between the optical and packet layer
control plane enables for instance letting the optical layer control plane enables for instance the optical layer performing the
performing the failure management operations (in particular, failure failure management operations (in particular, failure detection and
detection and notification) while giving to the packet layer control notification) while giving to the packet layer control plane the
plane the authority to perform the recovery actions. In case of authority to decide and perform the recovery actions. In case the
packet layer unsuccessful recovery action, fallback at the optical packet layer recovery action is unsuccessful, fallback at the
layer can be subsequently performed. optical layer can be subsequently performed.
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 must 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 suggests also recovery mechanisms incorporating a The same reference 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 updates. Moreover, at certain layers, some of these recovery status updates. Moreover, some of these recovery operations can be
operations can be pre-assigned, e.g. a particular link will be pre-assigned (on a per-link basis) to a certain layer, e.g. a given
handled by the packet layer while another will be handled by the link will be recovered at the packet layer while another will be
optical layer. recovered 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 guarantee working and recovery LSPs/Spans disjointness. Due to not guarantee their complete disjointness. Due to the common
the common physical layer topology (passive), additional physical layer topology (passive), additional hierarchical concepts
hierarchical concepts such as the Shared Risk Link Group (SRLG) and such as the Shared Risk Link Group (SRLG) and mechanisms such as
mechanisms such as SRLG diverse path computation must be developed SRLG diverse path computation must be developed to provide complete
to provide a complete working and recovery LSP/span disjointness working and recovery LSP/span disjointness (see [IPO-IMP], [GMPLS-
(see [IPO-IMP], [GMPLS-RTG] and [CCAMP-SRLG]). Otherwise, a failure RTG] and [CCAMP-SRLG]). Otherwise, a failure affecting the working
affecting the working LSP/span would also potentially affect the LSP/span would also potentially affect the recovery LSP/span; one
recovery LSP/span resources, one refers to such event as a common refers to such an event as "common failure".
failure.
7.4.1 SRLG Disjointness 7.4.1 SRLG Disjointness
D.Papadimitriou et al. - Internet Draft - Expires March 2004 27
A Shared Risk Link Group (SRLG) is defined as the set of optical A Shared Risk Link Group (SRLG) is defined as the set of optical
spans (or links or optical lines) sharing a common physical resource spans (or links or optical lines) sharing a common physical resource
(for instance, fiber links, fiber trunks or cables) i.e. sharing a (for instance, fiber links, fiber trunks or cables) i.e. sharing a
common risk. For instance, a set of links L belongs to the same SRLG common risk. For instance, a set of links L belongs to the same SRLG
s, if they are provisioned over the same fiber link f. s, if they are provisioned over the same fiber link 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 of the resources covered by each of them. one 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
D.Papadimitriou et al. - Internet Draft - Expires November 2003 26
individual SRLG s of the individual links composing this LSP. individual SRLG s of the individual links composing this LSP.
SRLG disjointness for LSP: SRLG disjointness for LSP:
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. 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 to that SRLG. belonging to that SRLG.
Therefore, the SRLG disjointness for LSPs can be defined as Therefore, the SRLG disjointness for LSPs can be defined as
skipping to change at line 1429 skipping to change at line 1502
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 common SRLGs between the
sets of SRLGs they individually cover is disjoint from set S. sets of SRLGs they individually cover is disjoint from set S.
The impact on recovery is obvious: SRLG disjointness is a necessary The impact on recovery is obvious: SRLG disjointness is a necessary
(but not a sufficient) condition to ensure optical network (but not a sufficient) condition to ensure optical 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/span 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
itself SRLG disjoint from each of the working LSP/span. itself SRLG-disjoint from each of the working LSPs/spans.
8. Recovery Type/Scheme Analysis 8. Recovery Mechanisms Analysis
In order to provide a structured analysis of the recovery types and In order to provide a structured analysis of the recovery mechanisms
schemes, the following dimensions can be considered: detailed in the previous sections, the following dimensions can be
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 (this implies fast failure
detection and correlation mechanisms) and fast recovery decision detection and correlation mechanisms) and fast recovery decision
independently of the number of failures occurring in the optical independently of the number of failures occurring in the optical
network (implying also a fast failure notification). network (implying also a fast failure notification).
D.Papadimitriou et al. - Internet Draft - Expires March 2004 28
2. Efficiency (scalability): minimize the switching time required 2. Efficiency (scalability): minimize the switching time required
for LSP/span recovery independently of number of LSPs/spans being for LSP/span recovery independently of the number of LSPs/spans
recovered (this implies an efficient failure correlation, a fast being recovered (this implies an efficient failure correlation, a
failure notification and timely efficient recovery mechanism(s)). fast failure notification and time-efficient recovery
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 LSP/span 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 optimize the sharing degree of the recovery referred to as optimizing the sharing degree of the recovery
resources. resources.
D.Papadimitriou et al. - Internet Draft - Expires November 2003 27
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 out of 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 going in opposite directions. For instance, it is obvious aspects or mutually conflicting. For instance, it is obvious that
that providing a 1+1 LSP recovery type minimizes the LSP downtime providing a 1+1 LSP protection minimizes the LSP downtime (in case
(in case of failure) while being non-scalable and recovery resource of failure) while being non-scalable and consuming recovery resource
consuming without enabling any extra-traffic. without enabling any extra-traffic.
The following sections provide an analysis of the recovery types The following sections provide an analysis of the recovery phases
(and schemes) proposed in [CCAMP-TERM] with respect to the and mechanisms detailed in the previous sections with respect to the
dimensions described above and assess the current GMPLS dimensions described here above to assess the current GMPLS protocol
capabilities. In turn, this allows evaluating the need for further suite capabilities and applicability. In turn, this allows the
GMPLS signalling or routing extensions. evaluation of the potential need for further GMPLS signaling and
routing 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 elapsing time between the failure detection/
correlation and hold-off time, point at which the recovery switching correlation and hold-off time, point at which the recovery switching
actions are initiated. This point has been already discussed in actions are initiated. This point has been detailed in Section 4.
Section 4.
8.2 Efficiency (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. Since protection implies
pre-assignment (and cross-connection) of the protection resources, pre-assignment (and cross-connection) of the protection resources,
in general, protection recover faster than restoration. in general, protection recover faster than restoration.
Span restoration (since using control plane) is also likely to be Span restoration is likely to be slower than most span protection
slower than most span protection types; however this greatly depends types; however this greatly depends on the efficiency of the span
on the span restoration signalling efficiency. LSP Restoration with restoration signalling. LSP restoration with pre-signaled and pre-
pre-signaled and pre-selected recovery resources is likely to be selected recovery resources is likely to be faster than fully
faster than fully dynamic LSP restoration, especially because of the dynamic LSP restoration, especially because of the elimination of
elimination of any potential crank-back during the recovery LSP any potential crankback during the recovery LSP establishment.
establishment.
If one excludes the crank-back issue, the difference between dynamic D.Papadimitriou et al. - Internet Draft - Expires March 2004 29
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 of 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 path computation time in different scenarios determine the average and maximum path computation time in different
and to the operator to decide whether or not dynamic restoration is scenarios and to the operator to decide whether or not dynamic
advantageous over pre-planned schemes depending on the network restoration is advantageous over pre-planned schemes depending on
environment. This difference depends also on the flexibility the network environment. This difference depends also on the
provided by pre-planned restoration with respect to dynamic one: the flexibility provided by pre-planned restoration versus dynamic
former implies a limited number of failure scenarios (that can be restoration: the former implies a somewhat limited number of failure
due for instance to local storage limitation). This, while the scenarios (that can be due, for instance, to local storage capacity
latter enables an on-demand path computation based on the limitation). The latter enables on-demand path computation based on
information received through failure notification and as such more the information received through failure notification message and as
robust with respect to the failure scenario scope. such is more robust with respect to the failure scenario scope.
D.Papadimitriou et al. - Internet Draft - Expires November 2003 28
Moreover, LSP segment restoration, in particular, dynamic Moreover, LSP segment restoration, in particular, dynamic
restoration (i.e. no path pre-computation so none of the recovery restoration (i.e. no path pre-computation so none of the recovery
resource is pre-signaled) will generally be faster than an end-to- resource is pre-reserved) will generally be faster than end-to-end
end LSP recovery. However, local LSP restoration assumes that each LSP restoration. However, local LSP restoration assumes that each
LSP segment end-point has enough computational capacity to perform LSP segment end-point has enough computational capacity to perform
this operation while end-to-end requires only that LSP end-points this operation while end-to-end LSP restoration requires only that
provides this path computation capability. LSP end-points provides this path computation capability.
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 [RFC 3386]. mechanisms have been proposed through a separate effort [RFC-3386].
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 less flexibility for multiple failure recovery resources gives in the case of multiple failure scenarios
scenarios than no recovery resource pre-selection. For instance, if less flexibility than no recovery resource pre-selection. For
failures occur that affect two LSPs sharing a common link along instance, if failures occur that affect two LSPs sharing a common
their restoration paths, then only one of these LSPs can be link along their restoration paths, then only one of these LSPs can
recovered. This occurs unless the restoration path of at least one be recovered. This occurs unless the restoration path of at least
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 LSP 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 resource must be fully
D.Papadimitriou et al. - Internet Draft - Expires March 2004 30
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 recovery LSP can be of simultaneous failure of the working and the recovery LSP can be
reduced by computing a new recovery path whenever a failure occurs reduced. This, by computing a new recovery path whenever a failure
along one of the recovery LSPs or by computing a new recovery path occurs along one of the recovery LSPs or by computing a new recovery
and provision the corresponding LSP whenever a failure occurs along path and provision the corresponding LSP whenever a failure occurs
a working LSP/span. Both methods enable to maintain the number of along a working LSP/span. Both methods enable the network to
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 reserved (i.e. signaled) recovery resources within a given shared of pre-reserved (i.e. signaled) recovery resources within a given
resource pool: as the amount of recovery resources sharing degree 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 to reserve the adequate amount of
D.Papadimitriou et al. - Internet Draft - Expires November 2003 29
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 utilization perspective, protection schemes are often classified
with respect to their degree of sharing recovery resources with with respect to their degree of sharing recovery resources with
respect to the working entities. Moreover, non-permanent bridging respect to the working entities. Moreover, non-permanent bridging
protection types allow (under normal conditions) for extra-traffic protection types allow (under normal conditions) for extra-traffic
over the recovery resources. over the recovery resources.
From this perspective 1) 1+1 LSP/Span protection is the more From this perspective 1) 1+1 LSP/Span protection is the most
resource consuming protection type since it doesn't allow for any resource consuming protection type since not allowing for any extra-
extra-traffic 2) 1:1 LSP/span protection type requires dedicated traffic 2) 1:1 LSP/span recovery requires dedicated recovery
recovery LSP/span allowing carrying extra preemptible traffic 3) 1:N LSP/span allowing for extra-traffic 3) 1:N and M:N LSP/span recovery
and M:N LSP/span recovery types require 1 (or M, respectively) require 1 (M, respectively) recovery LSP/span (shared between the N
recovery LSP/span (shared between the N working LSP/span) while working LSP/span) allowing for extra-traffic. Obviously, 1+1
allowing carrying extra preemptible traffic. Obviously, 1+1 protection precludes and 1:1 recovery does not allow for any
protection precludes and 1:1 recovery type does not allow for recovery LSP/span sharing whereas 1:N and M:N recovery do allow
recovery LSP/span sharing whereas 1:N and M:N recovery types do sharing of 1 (M, respectively) recovery LSP/spans between N working
allow sharing of 1 (M, respectively) recovery LSP/spans between N LSP/spans. However, despite the fact that 1:1 LSP recovery precludes
working LSP/spans. the sharing of the recovery LSP, the recovery schemes (see Section
5.4) that can be built from it (e.g. (1:1)^n) 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.
However, despite the fact that the 1:1 recovery type does not allow On the other hand, when using LSP restoration with pre-signaled
recovery LSP/span sharing, the recovery schemes (see Section 5.4) resource reservation, the amount of reserved restoration capacity is
that can be built from them (e.g. (1:1)^n) do allow for sharing of determined by the local bandwidth reservation policies. In LSP
recovery resources these entities includes. In addition, the restoration schemes with re-provisioning, a pool of spare resources
flexibility in the usage of shared recovery resources (in can be defined from which all resources are selected after failure
particular, shared links) may be limited because of network topology occurrence for the purpose of restoration path computation. The
restrictions, e.g. fixed ring topology for traditional enhanced degree to which restoration schemes allow sharing amongst multiple
protection schemes.
On the other hand, in restoration with pre-signaled resource D.Papadimitriou et al. - Internet Draft - Expires March 2004 31
reservation, the amount of reserved restoration capacity is independent failures is then directly inferred from the size of the
determined by the local bandwidth reservation policies. In resource pool. Moreover, in all restoration schemes, spare resources
restoration schemes with re-provisioning, a pool of restoration can be used to carry preemptible traffic (thus over preemptible
resource can be defined from which all (spare) restoration resources LSP/span) when the corresponding resources have not been committed
are selected after failure occurrence for recovery path computation for LSP/span recovery purposes.
purpose. The degree to which restoration schemes allow sharing
amongst multiple independent failures is then directly dictated by
the size of the restoration pool. Moreover, in all restoration
schemes, spare resources can be used to carry preemptible traffic
(thus over preemptible LSP/span) when the corresponding resources
have not been committed 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 degree to which the network is survivable is determined by the the network survivability level is determined by the policy that
policy that defines the amount of reserved (shared) recovery defines the amount of shared recovery resources and by the maximum
resources and the maximum sharing degree allowed. sharing degree allowed for these recovery resources.
D.Papadimitriou et al. - Internet Draft - Expires November 2003 30
8.4.1. Recovery Resource Sharing 8.4.1. Recovery Resource Sharing
When recovery resources are shared over several LSP/Spans, [GMPLS- When recovery resources are shared over several LSP/Spans, the use
RTG], the use of the Maximum Reservable Bandwidth, the Unreserved of the Maximum Reservable Bandwidth, the Unreserved Bandwidth and
Bandwidth and the Maximum LSP Bandwidth Link sub-TLVs provides the the Maximum LSP Bandwidth (see [GMPLS-RTG]) provides the information
information needed to obtain the optimization of the network needed to obtain the optimization of the network resources allocated
resources allocated for shared recovery purposes. for shared recovery purposes.
The Maximum Reservable Bandwidth is defined as the maximum link The Maximum Reservable Bandwidth is defined as the Maximum Link
capacity but may be greater in case of link over-subscription. The Bandwidth but it may be greater in case of link over-subscription.
Unreserved Bandwidth (per priority) is defined as the bandwidth not The Unreserved Bandwidth (at priority p) is defined as the bandwidth
yet reserved on a given TE link (initial value at each priority not yet reserved on a given TE link (its initial value for each
level corresponds to the Maximum Reservable Bandwidth). Last, the priority p corresponds to the Maximum Reservable Bandwidth). Last,
Maximum LSP Bandwidth (per priority) is defined as the smaller of the Maximum LSP Bandwidth (at priority p) is defined as the smaller
Unreserved Bandwidth and Maximum Reservable Bandwidth. of Unreserved Bandwidth (at priority p) and Maximum Link Bandwidth.
Here, one generally considers a recovery resource sharing ratio (or Here, one generally considers a recovery resource sharing degree (or
degree) in order to globally optimize the shared recovery resource ratio) to globally optimize the shared recovery resource usage. The
usage. The distribution of the bandwidth utilization per (bundled) distribution of the bandwidth utilization per TE link can be
TE link can be inferred from the per-priority bandwidth pre- inferred from the per-priority bandwidth pre-allocation. By using
allocation. This by using the Maximum LSP Bandwidth and the the Maximum LSP Bandwidth and the Maximum Reservable Bandwidth, the
Unreserved Bandwidth (see [GMPLS-RTG]), the amount of resources amount of (over-provisioned) resources that can be used for shared
(over-provisioned) for shared recovery purposes is known from the recovery purposes is known from the IGP.
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 capacity) and the Maximum LSP greater than the Maximum Link Bandwidth) and the Maximum LSP
Bandwidth (in the present case, this value corresponds to the Bandwidth per TE link i as the Maximum Shareable Bandwidth or
Unreserved Bandwidth) per TE link i as the Maximum Sharable max_R[i]. Within this quantity, the amount of bandwidth currently
Bandwidth or max_R[i]. Within this quantity, the amount of bandwidth allocated for shared recovery per TE link i is defined as R[i]. Both
currently allocated for shared recovery per TE link i is defined as quantities are expressed in terms of discrete bandwidth units (and
R[i]. Both quantities are expressed in terms of component link thus, the Minimum LSP Bandwidth is of one bandwidth unit).
bandwidth unit (and thus equivalently, the Min LSP Bandwidth is of
one bandwidth unit).
From these definitions, it results that the usage of this The knowledge of this information available per TE link can be
information available per TE link can be considered in order to exploited in order to optimize the usage of the resources allocated
optimize the usage of the resources allocated (per TE link) for per TE link for shared recovery. If one refers to r[i] as the actual
shared recovery. If one refers to r[i] as the actual bandwidth per bandwidth per TE link i (in terms of discrete bandwidth units)
TE link i (in terms of per component bandwidth unit) committed for committed for shared recovery, then the following quantity must be
shared recovery, then the following quantity must be maximized over maximized over the potential TE link candidates: sum {i=1}^N [(R{i}
the potential TE link candidates: sum {i=1}^N [(R{i} - r{i})/(t{i} - r{i})/(t{i} b{i})] or equivalently: sum {i=1}^N [(R{i} -
b{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 bandwidth unit). In
this formula, N is the total number of links traversed by a given
LSP, t[i] the Maximum Bandwidth per TE link i and b[i] the sum per
TE link i of the bandwidth committed for working LSPs and other
recovery LSPs (thus except "shared bandwidth" LSPs). The quantity
[(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
max_R[i] or for which r[i] = 0 are pruned during shared recovery
D.Papadimitriou et al. - Internet Draft - Expires November 2003 31 D.Papadimitriou et al. - Internet Draft - Expires March 2004 32
path computation as well as TE links for which max_R[i] = r[i] which r{i})/r{i}] with R{i} >= 1 and r{i} >= 1 (in terms of per component
can simply not be shared. bandwidth unit). 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 per TE link i of the bandwidth committed for
working LSPs and other recovery LSPs (thus except "shared bandwidth"
LSPs). The quantity [(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 max_R[i] or for which r[i] = 0 are pruned during
shared recovery path computation as well as TE links for which
max_R[i] = r[i] which can 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 ----- |
| ----- | | ----- |
- ----- |max_R - ----- |max_R
----- | ----- |
-------- TE link Capacity - ------ | - Maximum Bandwidth -------- TE link Capacity - ------ | - Maximum TE Link Bandwidth
----- |r ----- v ----- |r ----- v
----- <------ b ------> - ---------- Unreserved Bandwidth ----- <------ b ------> - ---------- Maximum LSP Bandwidth
----- ----- ----- -----
----- ----- ----- -----
----- ----- ----- -----
----- ----- ----- -----
----- ----- <--- Min 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 LSP information or a detailed distribution of the bandwidth per LSP information or any detailed distribution of the bandwidth
allocation per component link (or individual ports). Such approach allocation per component link or individual ports or even any per-
is referred to as a Partial Information Routing approach where per- priority shareable recovery bandwidth information (using a dedicated
priority bandwidth TE Link advertisements allow for the same sub-TLV). The latter would provide the same capability than the
capability as if a dedicated unreserved recovery bandwidth sub-TLV already defined Maximum LSP bandwidth per-priority information. Such
was defined (as suggested in [KODIALAM]). The latter shows that the approach is referred to as a Partial (or Aggregated) Information
difference obtained with a Full Information Routing approach (where Routing as described for instance in [KODIALAM1] and [KODIALAM2].
the set of working and recovery LSPs using a given link is known at They show that the difference obtained with a Full (or Complete)
each node) is fairly close. Information Routing approach (where for the whole set of working and
recovery LSPs, the amount of bandwidth units they use per-link is
Moreover, it has also been demonstrated that the Partial Information known at each node and for each link) is clearly negligible. The
Routing approach can be extended to resource shareability with latter approach is detailed in [GLI], for instance. Note also that
respect to the number of times each SRLG is protected by a recovery both approaches rely on the deterministic knowledge (at different
resource, in particular an LSP (see also Section 8.4.2). This degrees) of the network topology and resource usage status.
extended method is described in [BOUILLET]. By flooding this
aggregated information using a link-state routing protocol, recovery
path computation and selection for SRLG diverse recovery LSPs can be
optimized with respect to resource sharing giving a performance
difference of less than 5% (and so negligible) compared to a Full
Information Flooding approach. The latter is detailed in [GLI], for
instance. Note also that all these methods rely on deterministic
knowledge (at different degrees) of the network topology and
resource usage status.
For GMPLS-based recovery purposes, the Partial Information Routing Moreover, extending the GMPLS signalling capabilities can enhance
approach can be further enhanced by extending GMPLS signalling the Partial Information Routing approach. This, by allowing working
capabilities. This, by allowing the working LSP related information LSP related information and in particular, its path (including link
and in particular, its explicit route to be exchanged over the and node identifiers) to be exchanged with the recovery LSP request
recovery LSP in order to enable more efficient admission control at to enable more efficient admission control at upstream nodes of
ingress nodes of shared resources, in particular links. shared recovery resources, in particular links (see Section 8.4.3).
D.Papadimitriou et al. - Internet Draft - Expires November 2003 32 D.Papadimitriou et al. - Internet Draft - Expires March 2004 33
8.4.2 Recovery Resource Sharing and SRLG Recovery 8.4.2 Recovery Resource Sharing and SRLG Recovery
As stated in the previous section, resource shareability can also be Resource shareability can also be maximized with respect to the
maximized with respect to the number of times each SRLG is protected number of times each SRLG is protected by a recovery resource (in
by a recovery resource. particular, a shared TE link) and methods can be considered for
avoiding contention of the shared recovery resources in case of
single SRLG failure. These methods enable for the sharing of
recovery resources between two (or more) recovery LSPs if their
respective working LSPs are mutually disjoint with respect to link,
node and SRLGs. A single failure then does not simultaneously
disrupt several (or at least two) working LSPs.
Methods can be considered for avoiding contention for the shared For instance, [BOUILLET] shows that the Partial Information Routing
recovery resources during a single SRLG failure (see Section 5). approach can be extended to cover recovery resource shareability
These allow the sharing of common reserved recovery resource between with respect to SRLG recoverability (i.e. the number of times each
two (or more) recovery LSPs (only) if their respective working LSPs SRLG is recoverable). By flooding this aggregated information per TE
are mutually disjoint with respect to link, node or SRLG. A single link, path computation and selection of SRLG-diverse recovery LSPs
failure then does not disrupt several (at least two) working LSPs can be optimized with respect to the sharing of recovery resource
simultaneously. reserved on each TE link giving a performance difference of less
than 5% (and so negligible) compared to the corresponding Full
Information Flooding approach (see [GLI]).
For this purpose, additional extensions to [GMPLS-RTG] in support of For this purpose, additional extensions to [GMPLS-RTG] in support of
path computation for shared mesh restoration would potentially be path computation for shared mesh recovery have been often considered
considered. First, the information about the recovery resource in the literature. TE link attributes would include, among other,
sharing on a TE link such as the current number of recovery LSPs the current number of recovery LSPs sharing the recovery resources
sharing the recovery resources (pre-)allocated on the TE link (see reserved on the TE link and the current number of SRLGs recoverable
also Section 8.4.1) and the current number of SRLGs recoverable by by this amount of (shared) recovery resources reserved on the TE
this amount of shared recovery resource on this TE link, may be link. The latter is equivalent to the current number of SRLGs that
considered. The latter is equivalent to the total number of SRLGs the recovery LSPs sharing the recovery resource reserved on the TE
that the (recovery) LSPs sharing the recovery resources shall link shall recover. Then, if explicit SRLG recoverability is
recover. Then, if SRLG recoverability is considered, the explicit considered an additional TE link attribute including the explicit
list of SRLGs recoverable by the recovery resources shared on the TE list of SRLGs recoverable by the shared recovery resource reserved
link together with their respective sharable recovery bandwidth (see on the TE link and their respective shareable recovery bandwidth.
also Section 8.4.1) may be considered. The latter information is The latter information is equivalent to the shareable recovery
equivalent to the maximum sharable recovery bandwidth per SRLG (or bandwidth per SRLG (or per group of SRLGs) which implies to consider
per group of SRLG) which implies to consider a decreasing amount of a decreasing amount of shareable bandwidth and SRLG list over time.
sharable bandwidth and SRLG list over time.
Compared to the case of recovery resource sharing only regardless of
SRLG recoverability (as described in Section 8.4.1), the additional
TE link information considered here would potentially allow for
better path computation and selection (at distinct ingress node)
during SRLG-disjoint LSP provisioning in a shared meshed recovery
scheme. However, due to the lack of results of evidence for better
efficiency (see also Section 8.4.1) and due to the complexity that
such extensions would in turn generate, these extensions are not
further considered in the scope of the present analysis. For
instance, a per (group of) SRLG maximum shareable recovery bandwidth
is restricted by the length that the corresponding (sub-)TLV may
take and thus the number of SRLGs that it can include. Therefore,
the corresponding parameters SHOULD not be translated into GMPLS
routing (or even signalling) protocol extensions for recovery
purposes.
However, the next section will demonstrate that the exchange of the Compared to the case of recovery resource sharing only (regardless
path (including link and node identifiers) of the working LSP over of SRLG recoverability, as described in Section 8.4.1), this
the recovery LSP path helps in achieving shared recovery resources additional TE link attributes would potentially deliver better path
admission control. computation and selection (at distinct ingress node) for shared mesh
recovery purposes. However, due to the lack of results of evidence
for better efficiency and due to the complexity that such extensions
would generate, they are not further considered in the scope of the
present analysis. For instance, a per-SRLG group minimum/maximum
shareable recovery bandwidth is restricted by the length that the
corresponding (sub-)TLV may take and thus the number of SRLGs that
it can include. Therefore, the corresponding parameter SHOULD not be
translated into GMPLS routing (or even signalling) protocol
extensions in the form of TE link sub-TLV.
D.Papadimitriou et al. - Internet Draft - Expires November 2003 33 D.Papadimitriou et al. - Internet Draft - Expires March 2004 34
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, through C only, B creates Node A creates a working LSP to D (A-C-D), B creates simultaneously
simultaneously a working LSP to D through C and a recovery LSP a working LSP to D (B-C-D) and a recovery LSP (B-E-F-D) to the same
(through E and F) to the same destination. Then, A decides to create destination. Then, A decides to create a recovery LSP to D (A-E-F-
a recovery LSP to D, but since C to D span carries both working LSPs D), but since the C-D span carries both working LSPs, node E should
node E should either assign a dedicated resource for this recovery either assign a dedicated resource for this recovery LSP or reject
LSP or if it has already reached its maximum shared recovery this request if the C-D span has already reached its maximum
bandwidth level reject this request. Otherwise, in the latter case a recovery bandwidth sharing ratio. Otherwise, in the latter case, C-D
C-D span failure would imply that one of the working LSP would not span failure would imply that one of the working LSP would not be
be recoverable. recoverable.
Consequently, node E must have the required information (implying Consequently, node E must have the required information to perform
for instance, that the explicit route followed by the working LSPs admission control for the recovery LSP requests it processes
to be carried with the corresponding recovery LSP request) in order (implying for instance, that the path followed by the working LSP is
to perform an admission control for the recovery LSP requests. 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
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
same resources on the link E-F. This, if the link E-F has not yet
reached its maximum recovery bandwidth sharing ratio. In this
example, one assumes that the node failure probability is negligible
compared to the link failure probability.
Moreover, node E may securely (if its maximum shared recovery To achieve this, the path followed by the working LSP is transported
bandwidth ratio has not been reached yet for this link) accept the with the recovery LSP request and examined at each upstream node of
recovery LSP request and logically assign the same resource to these potentially shareable links. Admission control is performed using
LSPs. This if and only if it can guarantee that A-C-D and B-C-D are the interface identifiers (included in the path) to retrieve in the
SRLG disjoint over the C-D span (one considers here in the scope of TE DataBase the list of SRLG Ids associated to each of the working
this example, node failure probability as negligible). To achieve LSP links. If the working LSPs (A-C-D and B-C-D) have one or more
this, the explicit route of the working LSP (and transported over link or SRLG id in common (in this example, one or more SRLG id in
the recovery path) is examined at each shared link ingress node. The common over the span C-D) node E should not assign the same resource
latter uses the interface identifier as index to retrieve in the TE over link E-F to the recovery LSPs (A-E-F-D and B-E-F-D). Otherwise,
link State DataBase (TE LSDB) the SRLG id list associated to the one of these working LSPs would not be recoverable in case of C-D
links of the working LSPs. If these LSPs have one or more SRLG id in span failure.
common (in this example, one or more SRLG id in common over C-D),
then node E should not assign the same resource to the recovery
LSPs. Otherwise one of these working LSPs would not be recoverable
in case of C-D span failure.
There are some issues related to this method, the major one being There are some issues related to this method, the major one being
the number of SRLG Ids that a single link can cover (more than 100, the number of SRLG Ids that a single link can cover (more than 100,
in complex environments). Moreover, when using link bundles, this in 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 because the SRLG sub-TLV corresponding to a link bundle
D.Papadimitriou et al. - Internet Draft - Expires March 2004 35
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 [MPLS-BUNDLE]). belonging to this bundle (see [GMPLS-RTG] and [MPLS-BUNDLE]).
D.Papadimitriou et al. - Internet Draft - Expires November 2003 34
In order to overcome this specific issue, an additional mechanism In order to overcome this specific issue, an additional mechanism
may consist of querying the nodes where such an information would be may consist of querying the nodes where such an 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 (tightly related to the sequence of the recovery solving this issue is tightly related to the sequence of the
operations and since per component flooding of SRLG identifiers recovery operations. Per component flooding of SRLG identifiers
would impact the link state routing protocol scalability), may rely would deeply impact the scalability of the link state routing
on the usage of an on-line accessible network management system. protocol. Therefore, one may rely on the usage of an on-line
accessible network management system.
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)
skipping to change at line 1892 skipping to change at line 1954
-------------------------------------------------------------------- --------------------------------------------------------------------
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. signalling) and selection is referred to as
LSP protection. LSP 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. signalling) 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
D.Papadimitriou et al. - Internet Draft - Expires March 2004 36
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. signalling) and without resource selection is
D.Papadimitriou et al. - Internet Draft - Expires November 2003 35
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 as LSP re-routing, which is full when recovery LSP path to as LSP re-routing, which is full when recovery LSP path
computation occurs after failure occurrence. computation occurs after failure occurrence.
Thus, the term pre-planned refers here to recovery resource pre- The term pre-planned refers thus to recovery LSP path pre-
computation, signaling (reservation) and a priori selection computation, signaling (reservation), and a priori resource
(optional), but not cross-connection. Also, the shared-mesh recovery selection (optional), but not cross-connection. Also, the shared-
scheme can be view as a particular case of 2a) and 3a) using the mesh recovery scheme can be viewed as a particular case of 2a) and
additional constraint described in section 8.4.3. 3a) using the additional constraint described in Section 8.4.3.
The implementation of these recovery mechanisms and their The implementation of these recovery mechanisms requires only
corresponding phases requires only extensions to GMPLS signalling considering extensions to GMPLS signalling protocols (i.e. [RFC-
protocols (i.e. [RFC3471] and [RFC3473]). The present analysis 3471] and [RFC-3473]). These GMPLS signalling extensions should
demonstrates (in Section 8) that no GMPLS routing extensions are mainly focus in delivering (1) recovery LSP pre-provisioning for the
expected in order for GMPLS to provide any of these recovery types cases 1a, 2a and 3a, (2) LSP failure notification, (3) recovery LSP
and schemes. These GMPLS signalling extensions should mainly focus switching action(s), and (4) reversion mechanisms.
in delivering 1) recovery LSP pre-provisioning (only for the cases
1a, 2a and 3a) 2) failure notification 3) recovery switching actions Moreover, the present analysis (see Section 8) shows that no GMPLS
and 4) reversion mechanisms. routing extensions are expected to efficiently implement any of
these recovery types and schemes.
10. Security Considerations 10. Security Considerations
This document does not introduce or imply any specific security This document does not introduce any additional security issue or
consideration. imply any specific security consideration from [GMPLS-ARCH].
11. Acknowledgments 11. Acknowledgments
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, Richard Rabbat
(Fujitsu), David Griffith (NIST) and Lyndon Ong (Ciena) for their (Fujitsu Labs), David Griffith (NIST) and Lyndon Ong (Ciena) for
useful comments. their useful comments.
12. Intellectual Property Considerations 12. Intellectual Property Considerations
This section is taken from Section 10.4 of [RFC2026]. This section is taken from Section 10.4 of [RFC2026].
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 or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
D.Papadimitriou et al. - Internet Draft - Expires March 2004 37
claims of rights made available for publication and any assurances claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat. can be obtained from the IETF Secretariat.
D.Papadimitriou et al. - Internet Draft - Expires November 2003 36
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 which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
13. References 13. References
13.1 Normative References 13.1 Normative References
[CCAMP-TERM] E.Mannie and D.Papadimitriou (Editors), "Recovery
(Protection and Restoration) Terminology for GMPLS,"
Internet Draft, Work in progress, draft-ietf-ccamp-
gmpls-recovery-terminology-02.txt, May 2003.
[GMPLS-ARCH] E.Mannie (Editor) et al., "Generalized MPLS [GMPLS-ARCH] E.Mannie (Editor) et al., "Generalized MPLS
Architecture," Work in progress, draft-ietf-ccamp- Architecture," Work in progress, draft-ietf-ccamp-
gmpls-architecture-07.txt, May 2003. gmpls-architecture-07.txt, May 2003.
[GMPLS-RTG] K.Kompella (Editor) et al., "Routing Extensions in [GMPLS-RTG] K.Kompella (Editor) et al., "Routing Extensions in
Support of Generalized MPLS," Work in Progress, draft- Support of Generalized MPLS," Work in Progress, draft-
ietf-ccamp-gmpls-routing-05.txt, August 2002. ietf-ccamp-gmpls-routing-06.txt, June 2003.
[LMP] J.P.Lang (Editor) et al., "Link Management Protocol [LMP] J.P.Lang (Editor) et al., "Link Management Protocol
(LMP) v1.0," Internet Draft, Work in progress, draft- (LMP)," Work in progress, draft-ietf-ccamp-lmp-09, May
ietf-ccamp-lmp-09.txt, May 2003. 2003.
[LMP-WDM] A.Fredette and J.P.Lang (Editors), "Link Management [LMP-WDM] A.Fredette and J.P.Lang (Editors), "Link Management
Protocol (LMP) for DWDM Optical Line Systems," Work in Protocol (LMP) for DWDM Optical Line Systems," Work in
progress, draft-ietf-ccamp-lmp-wdm-02.txt, March 2003. progress, draft-ietf-ccamp-lmp-wdm-02.txt, March 2003.
[MPLS-BUNDLE]K.Kompella et al., "Link Bundling in MPLS Traffic
Engineering," Work in progress, draft-ietf-mpls-bundle-
04.txt, August 2002.
[RFC-2026] S.Bradner, "The Internet Standards Process -- Revision [RFC-2026] S.Bradner, "The Internet Standards Process -- Revision
3," BCP 9, IETF RFC 2026, October 1996. 3," BCP 9, IETF RFC 2026, October 1996.
[RFC-2119] S.Bradner, "Key words for use in RFCs to Indicate [RFC-2119] S.Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, IETF RFC 2119, March 1997. Requirement Levels," BCP 14, IETF RFC 2119, March 1997.
[RFC-3471] L.Berger (Editor) et al., "Generalized MPLS - Signaling [RFC-3471] L.Berger (Editor) et al., "Generalized MPLS - Signaling
Functional Description," IETF RFC 3471, January 2003. Functional Description," IETF RFC 3471, January 2003.
[RFC-3473] L.Berger (Editor) et al., "Generalized MPLS Signaling - [RFC-3473] L.Berger (Editor) et al., "Generalized MPLS Signaling -
RSVP-TE Extensions," IETF RFC 3473, January 2003. RSVP-TE Extensions," IETF RFC 3473, January 2003.
[TERM] E.Mannie and D.Papadimitriou (Editors), "Recovery
(Protection and Restoration) Terminology for GMPLS,"
Work in progress, draft-ietf-ccamp-gmpls-recovery-
terminology-02.txt, May 2003.
D.Papadimitriou et al. - Internet Draft - Expires March 2004 38
13.2 Informative References 13.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.
[CCAMP-LI] G.Li et al. "RSVP-TE Extensions For Shared-Mesh [CCAMP-LI] G.Li et al. "RSVP-TE Extensions For Shared-Mesh
Restoration in Transport Networks," Internet Draft, Restoration in Transport Networks," Work in progress,
draft-li-shared-mesh-restoration-01.txt, November 2001.
D.Papadimitriou et al. - Internet Draft - Expires November 2003 37
Work in progress, draft-li-shared-mesh-restoration-
01.txt, November 2001.
[CCAMP-LIU] H.Liu et al. "OSPF-TE Extensions in Support of Shared
Mesh Restoration," Internet Draft, Work in progress,
draft-liu-gmpls-ospf-restoration-00.txt, October 2002.
[CCAMP-SRLG] D.Papadimitriou et al., "Shared Risk Link Groups [CCAMP-SRLG] D.Papadimitriou et al., "Shared Risk Link Groups
Encoding and Processing," Internet Draft, Work in Encoding and Processing," Internet Draft, draft-
progress, draft-papadimitriou-ccamp-srlg-processing- papadimitriou-ccamp-srlg-processing-01.txt, November
01.txt, November 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, pp. 70-76, August 1998. 8, pp. 70-76, August 1998.
[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 Network (OTN)," Recommendation G.709, Transport Network (OTN)," Recommendation G.709,
February 2001 (and Amendment n1, October 2001). February 2001 (and Amendment n1, October 2001).
[G.783] ITU-T, "Characteristics of Synchronous Digital [G.783] ITU-T, "Characteristics of Synchronous Digital
Hierarchy (SDH) Equipment Functional Blocks," Hierarchy (SDH) Equipment Functional Blocks,"
Recommendation G.783, October 2000. Recommendation G.783, October 2000.
[G.798] ITU-T, "Characteristics of Optical Transport Network [G.806] ITU-T, "Characteristics of Transport Equipment -
(OTN) Equipment Functional Blocks," Recommendation
G.798, January 2002.
[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.826] ITU-T, "Performance Monitoring," Recommendation G.826, [G.808.1] ITU-T, "Generic Protection Switching - Linear trail and
February 1999.
[G.808.1] ITU-T, "Generic Protection Switching Linear trail and
Subnetwork Protection," Draft Recommendation (work in Subnetwork Protection," Draft Recommendation (work in
progress), Version 0.5, January 2003. progress), Version 0.5, January 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 1998. October 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.
[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.
D.Papadimitriou et al. - Internet Draft - Expires November 2003 38 [IPO-IMP] J.Strand and A.Chiu, "Impairments and Other Constraints
[KODIALAM] M.Kodialam and T.V.Lakshman, "Restorable Dynamic On Optical Layer Routing," Work in Progress, draft-
D.Papadimitriou et al. - Internet Draft - Expires March 2004 39
ietf-ipo-impairments-05.txt, May 2003.
[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
Restorable Bandwidth-Guaranteed Tunnels using
Aggregated Network Resource Usage Information," IEEE/
ACM 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 Evolution
of Transport Network Survivability," IEEE of Transport Network Survivability," IEEE
Communications Magazine, August 1999. Communications Magazine, August 1999.
[MPLS-OSU] S.Seetharaman et al., "IP over Optical Networks: A [MPLS-OSU] S.Seetharaman et al., "IP over Optical Networks: A
Summary of Issues," Internet Draft, Work in Progress, Summary of Issues," Work in Progress, draft-osu-ipo-
draft-osu-ipo-mpls-issues-02.txt, April 2001. mpls-issues-02.txt, April 2001.
[RFC-3386] W.Lai, D.McDysan, J.Boyle, et al., "Network Hierarchy [RFC-3386] W.Lai, D.McDysan, J.Boyle, et al., "Network Hierarchy
and Multi-layer Survivability," IETF RFC 3386, November and Multi-layer Survivability," IETF RFC 3386, November
2002. 2002.
[RFC-3469] V. Sharma and F. Hellstrand (Editors), "Framework for [RFC-3469] V. Sharma and F. Hellstrand (Editors), "Framework for
Multi-Protocol Label Switching (MPLS)- based Recovery," Multi-Protocol Label Switching (MPLS)- based Recovery,"
IETF RFC 3469, February 2003. IETF RFC 3469, February 2003.
[T1.105] ANSI, "Synchronous Optical Network (SONET): Basic [T1.105] ANSI, "Synchronous Optical Network (SONET): Basic
skipping to change at line 2108 skipping to change at line 2174
Eric Mannie (Consult) Eric Mannie (Consult)
E-mail: eric_mannie@hotmail.com E-mail: eric_mannie@hotmail.com
Dimitri Papadimitriou (Alcatel) Dimitri Papadimitriou (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
E-mail: dimitri.papadimitriou@alcatel.be E-mail: dimitri.papadimitriou@alcatel.be
D.Papadimitriou et al. - Internet Draft - Expires November 2003 39 D.Papadimitriou et al. - Internet Draft - Expires March 2004 40
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. "Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
skipping to change at line 2137 skipping to change at line 2203
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
D.Papadimitriou et al. - Internet Draft - Expires November 2003 40 D.Papadimitriou et al. - Internet Draft - Expires March 2004 41
 End of changes. 

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