draft-ietf-ccamp-gmpls-recovery-analysis-03.txt   draft-ietf-ccamp-gmpls-recovery-analysis-04.txt 
CCAMP Working Group CCAMP GMPLS P&R Design Team
Network Working Group CCAMP GMPLS P&R Design Team
Internet Draft Internet Draft
Category: Informational Dimitri Papadimitriou (Editor) Category: Informational Dimitri Papadimitriou (Editor)
Expiration Date: October 2004 Eric Mannie (Editor) Expiration Date: March 2005 Eric Mannie (Editor)
April 2004 October 2004
Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based
Recovery Mechanisms (including Protection and Restoration) Recovery Mechanisms (including Protection and Restoration)
draft-ietf-ccamp-gmpls-recovery-analysis-03.txt draft-ietf-ccamp-gmpls-recovery-analysis-04.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 subject to all provisions
all provisions of Section 10 of RFC2026 [1]. of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering 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.
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts Internet-Drafts are draft documents valid for a maximum of six
as reference material or to cite them other than as "work in months and may be updated, replaced, or obsoleted by other documents
progress." at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at 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: Copyright Notice
http://www.ietf.org/ietf/1id-guidelines.txt
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document provides an analysis grid to evaluate, compare and This document provides an analysis grid to evaluate, compare and
contrast the Generalized Multi-Protocol Label Switching (GMPLS) contrast the Generalized Multi-Protocol Label Switching (GMPLS)
protocol suite capabilities with respect to the recovery mechanisms protocol suite capabilities with respect to the recovery mechanisms
currently proposed at the IETF CCAMP Working Group. A detailed currently proposed at the IETF CCAMP Working Group. A detailed
analysis of each of the recovery phases is provided using the analysis of each of the recovery phases is provided using the
terminology defined in a companion document. This document focuses terminology defined in a companion document. This document focuses
on transport plane survivability and recovery issues and not on on transport plane survivability and recovery issues and not on
control plane resilience and related aspects. control plane resilience and related aspects.
D.Papadimitriou et al. - Expires October 2004 1 D.Papadimitriou et al. - Expires March 2005 1
Table of Content Table of Content
Status of this Memo .............................................. 1 Status of this Memo .............................................. 1
Abstract ......................................................... 1 Abstract ......................................................... 1
Table of Content ................................................. 2 Table of Content ................................................. 2
1. Contributors .................................................. 3 1. Contributors .................................................. 3
2. Conventions used in this Document ............................. 3 2. Conventions used in this Document ............................. 3
3. Introduction .................................................. 4 3. Introduction .................................................. 4
4. Fault Management .............................................. 4 4. Fault Management .............................................. 4
4.1 Failure Detection ............................................ 4 4.1 Failure Detection ............................................ 4
4.2 Failure Localization and Isolation ........................... 7 4.2 Failure Localization and Isolation ........................... 7
4.3 Failure Notification ......................................... 7 4.3 Failure Notification ......................................... 7
4.4 Failure Correlation .......................................... 9 4.4 Failure Correlation .......................................... 9
5. Recovery Mechanisms .......................................... 10 5. Recovery Mechanisms .......................................... 10
5.1 Transport vs. Control Plane Responsibilities ................ 10 5.1 Transport vs. Control Plane Responsibilities ................ 10
5.2 Technology In/dependent Mechanisms .......................... 11 5.2 Technology In/dependent Mechanisms .......................... 11
5.2.1 OTN Recovery .............................................. 11 5.2.1 OTN Recovery .............................................. 11
5.2.2 Pre-OTN Recovery .......................................... 11 5.2.2 Pre-OTN Recovery .......................................... 11
5.2.3 Sonet/SDH Recovery ........................................ 11 5.2.3 SONET/SDH Recovery ........................................ 11
5.3 Specific Aspects of Control Plane-based Recovery Mechanisms . 12 5.3 Specific Aspects of Control Plane-based Recovery Mechanisms . 12
5.3.1 In-band vs. Out-of-band Signaling ......................... 12 5.3.1 In-band vs. Out-of-band Signaling ......................... 12
5.3.2 Uni- vs. Bi-directional Failures .......................... 13 5.3.2 Uni- vs. Bi-directional Failures .......................... 13
5.3.3 Partial vs. Full Span Recovery ............................ 15 5.3.3 Partial vs. Full Span Recovery ............................ 15
5.3.4 Difference between LSP, LSP Segment and 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.4 Difference between Recovery Type and Scheme ................. 16
5.5 LSP Recovery Mechanisms ..................................... 18 5.5 LSP Recovery Mechanisms ..................................... 18
5.5.1 Classification ............................................ 18 5.5.1 Classification ............................................ 18
5.5.2 LSP Restoration ........................................... 19 5.5.2 LSP Restoration ........................................... 19
5.5.3 Pre-planned LSP Restoration ............................... 21 5.5.3 Pre-planned LSP Restoration ............................... 21
skipping to change at line 101 skipping to change at line 108
8.1 Fast Convergence (Detection/Correlation and Hold-off Time) .. 29 8.1 Fast Convergence (Detection/Correlation and Hold-off Time) .. 29
8.2 Efficiency (Recovery Switching Time) ........................ 29 8.2 Efficiency (Recovery Switching Time) ........................ 29
8.3 Robustness .................................................. 30 8.3 Robustness .................................................. 30
8.4 Resource Optimization ....................................... 31 8.4 Resource Optimization ....................................... 31
8.4.1 Recovery Resource Sharing ................................. 32 8.4.1 Recovery Resource Sharing ................................. 32
8.4.2 Recovery Resource Sharing and SRLG Recovery ............... 34 8.4.2 Recovery Resource Sharing and SRLG Recovery ............... 34
8.4.3 Recovery Resource Sharing, SRLG Disjointness and Admission. 35 8.4.3 Recovery Resource Sharing, SRLG Disjointness and Admission. 35
9. Summary and Conclusions ...................................... 36 9. Summary and Conclusions ...................................... 36
10. Security Considerations ..................................... 37 10. Security Considerations ..................................... 37
11. Acknowledgments ............................................. 38 11. Acknowledgments ............................................. 38
12. Intellectual Property Considerations ........................ 38 12. References .................................................. 38
D.Papadimitriou et al. - Expires October 2004 2 D.Papadimitriou et al. - Expires March 2005 2
12.1 IPR Disclosure Acknowledgement ............................. 38 12.1 Normative References ....................................... 38
13. References .................................................. 39 12.2 Informative References ..................................... 39
13.1 Normative References ....................................... 39 13. Editor's Address ............................................ 41
13.2 Informative References ..................................... 40 Intellectual Property Statement ................................. 42
14 Editor's Address ............................................. 40 Disclaimer of Validity .......................................... 42
Copyright Statement ............................................. 42
1. Contributors 1. 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)
200 S. Laurel Ave. 200 S. Laurel Ave.
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
skipping to change at line 157 skipping to change at line 165
2. Conventions used in this document 2. 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 [RFC2119]. this document are to be interpreted as described in [RFC2119].
Any other recovery-related terminology used in this document Any other recovery-related terminology used in this document
conforms to the one defined in [TERM]. The reader is also assumed to conforms to the one defined in [TERM]. The reader is also assumed to
D.Papadimitriou et al. - Expires October 2004 3 D.Papadimitriou et al. - Expires March 2005 3
be familiar with the terminology developed in [GMPLS-ARCH], be familiar with the terminology developed in [GMPLS-ARCH],
[RFC3471], [RFC3473], [GMPLS-RTG] and [LMP]. [RFC3471], [RFC3473], [GMPLS-RTG] and [LMP].
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 Generalized MPLS (GMPLS) protocol suite capabilities contrast the Generalized MPLS (GMPLS) protocol suite capabilities
with respect to the recovery mechanisms currently proposed at the with respect to the recovery mechanisms proposed at the IETF CCAMP
IETF CCAMP Working Group. Here, the focus will only be on transport Working Group. The focus is on transport plane survivability and
plane survivability and recovery issues and not on control plane recovery issues and not on control plane resilience related aspects.
resilience related aspects. Although the recovery mechanisms Although the recovery mechanisms described in this document impose
described in this document impose different requirements on GMPLS- different requirements on GMPLS-based recovery protocols, the
based recovery protocols, the protocol(s) specifications will not be protocol(s) specifications will not be covered in this document.
covered in this document. Though the concepts discussed here are Though the concepts discussed are technology independent, this
technology independent, this document will implicitly focus on document implicitly focuses on SONET [T1.105]/SDH [G.707], Optical
Sonet/SDH [T1.105]/[G.707], Optical Transport Networks (OTN) [G.709] Transport Networks (OTN) [G.709] and pre-OTN technologies except
and pre-OTN technologies except when specific details need to be when specific details need to be considered (for instance, in the
considered (for instance, in the case of failure detection). case of failure detection).
A detailed analysis is provided for each of the recovery phases as A detailed analysis is provided for each of the recovery phases as
identified in [TERM]. These phases define the sequence of generic identified in [TERM]. These phases define the sequence of generic
operations that need to be performed when a LSP/Span failure (or any operations that need to be performed when a LSP/Span failure (or any
other event generating such failures) occurs: other event generating such failures) 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)
skipping to change at line 212 skipping to change at line 220
recovery mechanisms detailed in this document can be analyzed are recovery mechanisms detailed in this document can be analyzed are
introduced to assess the current GMPLS protocol capabilities and the introduced to assess the current GMPLS protocol capabilities and the
potential need for further extensions. This document concludes by 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. - Expires October 2004 4 D.Papadimitriou et al. - Expires March 2005 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 a failure condition, MUST the transport plane, the latter, upon a failure condition, must
trigger the control plane for subsequent actions through the use of trigger the control plane for subsequent actions through the use of
GMPLS signalling capabilities (see [RFC3471] and [RFC3473]) or Link GMPLS signalling capabilities (see [RFC3471] and [RFC3473]) or Link
Management Protocol capabilities (see [LMP], Section 6). 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.
AIS) at the client layer. AIS) at the client layer.
- Connectivity: monitors the integrity of the routing of the signal - Connectivity: monitors the integrity of the routing of the signal
between end-points. Connectivity monitoring is needed if between end-points. Connectivity monitoring is needed if
the layer provides flexible connectivity, either automatically the layer provides flexible connectivity, either automatically
(e.g. cross-connects controlled by the TMN) or manually (e.g. (e.g. cross-connects) or manually (e.g. fiber distribution frame).
fiber distribution frame). An example is the Trail (i.e. section An example is the Trail (i.e. section or path) Trace Identifier
or path) Trace Identifier used at the different layers and the used at the different layers and the corresponding Trail Trace
corresponding Trail Trace Identifier Mismatch detection. Identifier Mismatch detection.
- Alignment: checks that the client and server layer frame start can - Alignment: checks that the client and server layer frame start can
be correctly recovered from the detection of loss of alignment. be correctly recovered from the detection of loss of alignment.
The specific processes depend on the signal/frame structure and The specific processes depend on the signal/frame structure and
may include: (multi-)frame alignment, pointer processing and may include: (multi-)frame alignment, pointer processing and
alignment of several independent frames to a common frame start in alignment of several independent frames to a common frame start in
case of inverse multiplexing. Loss of alignment is a generic term. case of inverse multiplexing. Loss of alignment is a generic term.
Examples are loss of frame, loss of multi-frame, or loss of Examples are loss of frame, loss of multi-frame, or loss of
pointer. pointer.
- 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 destination. This is normally done by adding
signal type identifier at the source adaptation function and a payload type identifier (referred to as the "signal label") at
comparing it with the expected identifier at the sink. For the source adaptation function and comparing it with the expected
instance, the payload signal label and the corresponding payload identifier at the destination. For instance, the payload type
signal mismatch detection. identifier and the corresponding mismatch detection.
D.Papadimitriou et al. - Expires March 2005 5
- Signal Quality: monitors the performance of a signal. For - Signal Quality: monitors the performance of a signal. For
D.Papadimitriou et al. - Expires October 2004 5
instance, if the performance falls below a certain threshold a instance, if the performance falls below a certain threshold a
defect - excessive errors (EXC) or degraded signal (DEG) - is defect - excessive errors (EXC) or degraded signal (DEG) - is
detected. detected.
The most important point is that the supervision processes and the The most important point is that the supervision processes and the
corresponding failure detection (used to initiate the recovery corresponding failure detection (used to initiate the recovery
phase(s)) result in either: phase(s)) result in either:
- Signal Degrade (SD): A signal indicating that the associated data - Signal Degrade (SD): A signal indicating that the associated data
has degraded in the sense that a degraded defect condition is has degraded in the sense that a degraded defect condition is
skipping to change at line 318 skipping to change at line 325
detection mechanisms are outside 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
turn the OLS-PXC composed system into a single logical entity turn the OLS-PXC composed system into a single logical entity
allowing the consideration of the same failure management mechanisms allowing the consideration of the same failure management mechanisms
for such entity 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)
D.Papadimitriou et al. - Expires October 2004 6 D.Papadimitriou et al. - Expires March 2005 6
- Loss of Light (LOL)/Loss of Signal (LOS): Signal Failure (SF)
condition where the optical signal is not detected any longer on condition where the optical signal is not detected any longer on
the receiver of a given interface. the receiver of a given interface.
- Signal Degrade (SD): detection of the signal degradation over - Signal Degrade (SD): detection of the signal degradation over
a specific period of time. a specific period of time.
- For Sonet/SDH payloads, all of the above-mentioned supervision - For SONET/SDH payloads, all of the above-mentioned supervision
capabilities can be used, resulting in SD or SF condition. capabilities can be used, resulting in SD or SF 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:
o with in-band communication between entities: entities are o with in-band communication between entities: entities are
physically separated but the transport plane provides in-band physically separated but the transport plane provides in-band
communication between them (e.g., Server Signal Failures (Alarm communication between them (e.g., Server Signal Failures (Alarm
Indication Signal (AIS)), etc.) Indication Signal (AIS)), etc.)
o with out-of-band communication between entities: entities are o with out-of-band communication between entities: entities are
physically separated but an out-of-band communication channel is physically separated but an out-of-band communication channel is
skipping to change at line 374 skipping to change at line 381
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
D.Papadimitriou et al. - Expires October 2004 7 D.Papadimitriou et al. - Expires March 2005 7
Failure notification is used 1) to inform intermediate nodes that an Failure notification is used 1) to inform intermediate nodes that an
LSP/span failure has occurred and has been detected 2) to inform the LSP/span failure has occurred and has been detected 2) to inform the
deciding entities (which can correspond to any intermediate or end- deciding entities (which can correspond to any intermediate or end-
point of the failed LSP/span) that the corresponding service is not point of the failed LSP/span) that the corresponding service is not
available. In general, these deciding entities will be the ones available. In general, these deciding entities will be the ones
taking the appropriate recovery decision. When co-located with the taking the appropriate recovery decision. When co-located with the
recovering entity, these entities will also perform the recovering entity, these entities will also perform the
corresponding 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
occurred. AIS performs two functions 1) inform the intermediate occurred. AIS performs two functions 1) inform the intermediate
nodes (with the appropriate layer monitoring capability) that a nodes (with the appropriate layer monitoring capability) that a
failure has been detected 2) notify the connection end-point that failure has been detected 2) notify the connection end-point that
the service is no longer available. the service is no longer available.
skipping to change at line 428 skipping to change at line 435
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:
D.Papadimitriou et al. - Expires October 2004 8 D.Papadimitriou et al. - Expires March 2005 8
- 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
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 [TERM]). (see for instance the APS protocol phases as described in [TERM]).
In addition, since fast notification is a mechanism running in In addition, since fast notification is a mechanism running in
collaboration with the existing GMPLS signalling (see [RFC3473]) collaboration with the existing GMPLS signalling (see [RFC3473])
skipping to change at line 482 skipping to change at line 489
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.4 Failure Correlation 4.4 Failure Correlation
A single failure event (such as a span failure) can result into A single failure event (such as a span failure) can 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
D.Papadimitriou et al. - Expires October 2004 9 D.Papadimitriou et al. - Expires March 2005 9
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.
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
skipping to change at line 537 skipping to change at line 544
Note: in the context of LSP/span protection, control plane actions Note: in the context of LSP/span protection, control plane actions
can be performed either for operational purposes and/or can be performed either for operational purposes and/or
synchronization purposes (vertical synchronization between transport synchronization purposes (vertical synchronization between transport
and control plane) and/or notification purposes (horizontal and control plane) and/or notification purposes (horizontal
synchronization between end-nodes at control plane level). This synchronization between end-nodes at control plane level). This
suggests the selection of the responsible plane (in particular for suggests the selection of the responsible plane (in particular for
protection switching) during the provisioning phase of the protection switching) during the provisioning phase of the
protected/protection LSP. protected/protection LSP.
D.Papadimitriou et al. - Expires October 2004 10 D.Papadimitriou et al. - Expires March 2005 10
2. LSP/span Restoration 2. LSP/span Restoration
- Phase 1: Failure detection Transport plane - Phase 1: Failure detection Transport plane
- Phase 2: Failure localization/isolation Transport/Control plane - Phase 2: Failure localization/isolation Transport/Control plane
- Phase 3: Failure notification Control plane - Phase 3: Failure notification Control plane
- Phase 4: Recovery switching Control plane - Phase 4: Recovery switching Control plane
- Phase 5: Reversion (normalization) Control plane - Phase 5: Reversion (normalization) Control plane
Therefore, this document primarily focuses on provisioning of LSP Therefore, this document primarily focuses on provisioning of LSP
recovery resources, failure notification mechanisms, recovery recovery resources, failure notification mechanisms, recovery
switching, and reversion operations. Moreover some additional switching, and reversion operations. Moreover some additional
considerations can be dedicated to the mechanisms associated to the considerations can be dedicated to the mechanisms associated to the
failure localization/isolation phase. failure localization/isolation phase.
5.2 Technology in/dependent mechanisms 5.2 Technology 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 list 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
skipping to change at line 590 skipping to change at line 597
edge nodes giving the possibility to initiate recovery actions edge nodes giving the possibility to initiate recovery actions
driven by upper layers. 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
D.Papadimitriou et al. - Expires October 2004 11 D.Papadimitriou et al. - Expires March 2005 11
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
Some of the advantages of Sonet/SDH [T1.105]/[G.707] and more Some of the advantages of SONET [T1.105]/SDH [G.707] and more
generically any TDM transport plane recovery are that they provide: generically any 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 recovery are: Some of the limitations of the SONET/SDH recovery are:
- Limited topological scope: Inherently the use of ring topologies, - Limited topological scope: Inherently the use of ring topologies,
typically, dedicated Sub-Network Connection Protection (SNCP) or typically, dedicated Sub-Network Connection Protection (SNCP) or
shared protection rings, has reduced flexibility and resource shared protection rings, has reduced flexibility and resource
efficiency with respect to the (somewhat more complex) meshed efficiency with respect to the (somewhat more complex) meshed
recovery. recovery.
- Inefficient use of spare capacity: Sonet/SDH protection is largely - Inefficient use of spare capacity: SONET/SDH protection is largely
applied to ring topologies, where spare capacity often remains applied to ring topologies, where spare capacity often remains
idle, making the efficiency of bandwidth usage a real issue. idle, making the efficiency of bandwidth usage a real issue.
- Support of meshed recovery requires intensive network management - Support of meshed recovery requires intensive network management
development and the functionality is limited by both the network development and the functionality is limited by both the network
elements and the capabilities of the element management systems elements and the capabilities of the element management systems
(justifying thus the development of GMPLS-based distributed (justifying thus the development of GMPLS-based distributed
recovery mechanisms.) recovery mechanisms.)
5.3 Specific Aspects of Control Plane-based Recovery Mechanisms 5.3 Specific Aspects of Control Plane-based Recovery Mechanisms
skipping to change at line 645 skipping to change at line 652
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
D.Papadimitriou et al. - Expires October 2004 12 D.Papadimitriou et al. - Expires March 2005 12
respect to the transport plane topology. In the scope of this respect to the transport plane topology. In the scope of this
document, it is assumed that at least one IP control channel between document, it is assumed that at least one IP control channel between
each pair of adjacent nodes is continuously available to enable the each pair of adjacent nodes is continuously available to enable the
exchange of recovery-related information and messages. Thus, in exchange of recovery-related information and messages. Thus, in
either case (i.e. in-band or out-of-band) at least one logical or either case (i.e. in-band or out-of-band) at least one logical or
physical control channel between each pair of nodes is always physical control channel between each pair of nodes is always
expected to be available. expected to be available.
Therefore, the key issue when using in-fiber signalling is whether Therefore, the key issue when using in-fiber signalling is whether
one can assume independence between the fault-tolerance capabilities one can assume independence between the fault-tolerance capabilities
skipping to change at line 699 skipping to change at line 706
| |----...----| |---------| |----...----| | | |----...----| |---------| |----...----| |
------- ------- ------- ------- ------- ------- ------- -------
t0 >>>>>>> F t0 >>>>>>> F
t1 x <---------------x t1 x <---------------x
Notification Notification
t2 <--------...--------x x--------...--------> t2 <--------...--------x x--------...-------->
Up Notification Down Notification Up Notification Down Notification
D.Papadimitriou et al. - Expires October 2004 13 D.Papadimitriou et al. - Expires March 2005 13
------- ------- ------- ------- ------- ------- ------- -------
| | | |Tx Rx| | | | | | | |Tx Rx| | | |
| NodeA |----...----| NodeB |xxxxxxxxx| NodeC |----...----| NodeD | | NodeA |----...----| NodeB |xxxxxxxxx| NodeC |----...----| NodeD |
| |----...----| |xxxxxxxxx| |----...----| | | |----...----| |xxxxxxxxx| |----...----| |
------- ------- ------- ------- ------- ------- ------- -------
t0 F <<<<<<< >>>>>>> F t0 F <<<<<<< >>>>>>> F
t1 x <-------------> x t1 x <-------------> x
Notification Notification
skipping to change at line 754 skipping to change at line 761
In case of bi-directional failure, node B should send an upstream In case of bi-directional failure, node B should send an upstream
notification message (see [RFC3473]) to the ingress node A and notification message (see [RFC3473]) to the ingress node A and
node C may send a downstream notification message (see [RFC3473]) node C may send a downstream notification message (see [RFC3473])
to the egress node D. However, due to the dependence on the LSP to the egress node D. However, due to the dependence on the LSP
directionality, only ingress node A would initiate an edge to edge directionality, only ingress node A would initiate an edge to edge
recovery action. Note that the other LSP end-node (i.e. node D in recovery action. Note that the other LSP end-node (i.e. node D in
this case) should also be notified of this event using a this case) should also be notified of this event using a
downstream notification message (see [RFC3473]). For instance, if downstream notification message (see [RFC3473]). For instance, if
D.Papadimitriou et al. - Expires October 2004 14 D.Papadimitriou et al. - Expires March 2005 14
an LSP 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 message sent from node C to D would initiate a notification message sent from node C to D would initiate a
recovery action and, in this case, per [TERM], the deciding and recovery action and, in this case, per [TERM], the deciding and
recovering node D is referred to as the "master" while node A is recovering node D is referred to as the "master" while node A is
referred to as the "slave" (i.e. recovering only entity). referred to as the "slave" (i.e. recovering only entity).
Note: The determination of the master and the slave may be based Note: The determination of the master and the slave may be based
either on configured information or dedicated protocol capability. either on configured information or dedicated protocol capability.
In the above scenarios, the path followed by the upstream and In the above scenarios, the path followed by the upstream and
skipping to change at line 809 skipping to change at line 816
corresponding recovery mechanisms (and their sequence), one assumes corresponding recovery mechanisms (and their sequence), one assumes
here as well, that per [TERM] the deciding (and recovering) entity, here as well, that per [TERM] the deciding (and recovering) entity,
referred to as the "master" is the only initiator of the recovery of referred to as the "master" is the only initiator of the recovery of
the whole LSP (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 [TERM] are quite generic and apply The recovery definitions given in [TERM] are quite generic and apply
for link (or local span) and LSP recovery. The major difference for link (or local span) and LSP recovery. The major difference
D.Papadimitriou et al. - Expires October 2004 15 D.Papadimitriou et al. - Expires March 2005 15
between LSP, LSP Segment and span recovery is related to the number between LSP, LSP Segment and span recovery is related to the number
of intermediate nodes that the signalling messages have to travel. of intermediate nodes that the signalling messages have to travel.
Since nodes are not necessarily adjacent in case of LSP (or LSP Since nodes are not necessarily adjacent in case of LSP (or LSP
Segment) recovery, signalling message exchanges from the reporting Segment) recovery, signalling message exchanges from the reporting
to the deciding/recovery entity may have to cross several to the deciding/recovery entity may have to cross several
intermediate nodes. In particular, this applies for the notification intermediate nodes. In particular, this applies for the notification
messages due to the number of hops separating the location of a messages due to the number of hops separating the location of a
failure occurrence from its destination. This results in an failure occurrence from its destination. This results in an
additional propagation and forwarding delay. Note that the former additional propagation and forwarding delay. Note that the former
delay may in certain circumstances be non-negligible; e.g. in case delay may in certain circumstances be non-negligible; e.g. in case
skipping to change at line 864 skipping to change at line 871
[TERM] defines the basic LSP/span recovery types. This section [TERM] defines the basic LSP/span recovery types. This section
describes the recovery schemes that can be built using these describes the recovery schemes that can be built using these
recovery types. In brief, a recovery scheme is defined as the recovery types. In brief, a recovery scheme is defined as the
combination of several ingress-egress node pairs supporting a given combination of several ingress-egress node pairs supporting a given
recovery type (from the set of the recovery types they allow). recovery type (from the set of the recovery types they allow).
Several examples are provided here to illustrate the difference Several examples are provided here to illustrate the difference
between recovery types such as 1:1 or M:N and recovery schemes such between recovery types such as 1:1 or M:N and recovery schemes such
as (1:1)^n or (M:N)^n referred to as shared-mesh recovery. as (1:1)^n or (M:N)^n referred to as shared-mesh recovery.
D.Papadimitriou et al. - Expires October 2004 16 D.Papadimitriou et al. - Expires March 2005 16
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 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.
skipping to change at line 917 skipping to change at line 924
simultaneous failures of multiple LSPs. simultaneous failures of multiple LSPs.
For instance, in the simple (1:1)^n case, if n recovery LSPs in a For instance, in the simple (1:1)^n case, if n recovery LSPs in a
(1:1)^n group overlap, then it can handle only single failures; any (1:1)^n group overlap, then it can handle only single failures; any
simultaneous failure of multiple working LSPs will cause at least simultaneous failure of multiple working LSPs will cause at least
one working LSP to be denied automatic recovery. But if one one working LSP to be denied automatic recovery. But if one
considers for instance, a (2:2)^2 group in which there are two pairs considers for instance, a (2:2)^2 group in which there are two pairs
of overlapping recovery LSPs, then two LSPs (belonging to the same of 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
D.Papadimitriou et al. - Expires October 2004 17 D.Papadimitriou et al. - Expires March 2005 17
illustrated by the following topology with 2 pairs of working LSPs illustrated by the following topology with 2 pairs of working LSPs
A-B-C and F-G-H and their respective recovery LSPs A-D-E-C and F-D- A-B-C and F-G-H and their respective recovery LSPs A-D-E-C and F-D-
E-H that share two common D-E link resources. E-H that share two common D-E link resources.
A========B========C A========B========C
\\ // \\ //
\\ // \\ //
D =========== E D =========== E
// \\ // \\
// \\ // \\
skipping to change at line 970 skipping to change at line 977
link(s), node(s) and/or SRLG(s). The recovery LSP pre-provisioning link(s), node(s) and/or SRLG(s). The recovery LSP pre-provisioning
options can be classified (in the below figure) as follows: options can be classified (in the below figure) as follows:
(1) the recovery path can be either pre-computed or computed (1) the recovery path can be either pre-computed or computed
on-demand. on-demand.
(2) when the recovery path is pre-computed, it can be either pre- (2) when the recovery path is pre-computed, it can be either pre-
signaled (implying recovery resource reservation) or signaled signaled (implying recovery resource reservation) or signaled
on-demand. on-demand.
D.Papadimitriou et al. - Expires October 2004 18 D.Papadimitriou et al. - Expires March 2005 18
(3) when the recovery resources are pre-signaled, they can be either (3) when the recovery resources are pre-signaled, they can be either
pre-selected or selected on-demand. pre-selected or selected on-demand.
Recovery LSP provisioning phases: Recovery LSP provisioning phases:
(1) Path Computation --> On-demand (1) Path Computation --> On-demand
| |
| |
--> Pre-Computed --> Pre-Computed
| |
skipping to change at line 1022 skipping to change at line 1029
| |
+----- Shared (for instance: 1:N, M:N, etc.) +----- Shared (for instance: 1:N, M:N, etc.)
| |
Level of | Level of |
Overbooking -----+----- Unprotected (for instance: 0:1, 0:N) Overbooking -----+----- Unprotected (for instance: 0:1, 0:N)
Also, when using shared recovery, one may support preemptible extra- Also, when using shared recovery, one may support preemptible extra-
traffic; the recovery mechanism is then expected to allow preemption traffic; the recovery mechanism is then expected to allow preemption
of this low priority traffic in case of recovery resource contention of this low priority traffic in case of recovery resource contention
D.Papadimitriou et al. - Expires October 2004 19 D.Papadimitriou et al. - Expires March 2005 19
during recovery operations. The following sections will consider the during recovery operations. The following sections will consider the
above-mentioned overbooking options when analyzing the different above-mentioned overbooking options when analyzing the different
recovery mechanisms. recovery mechanisms.
5.5.2 LSP Restoration 5.5.2 LSP Restoration
The following times are defined to provide a quantitative estimation The following times are defined to provide a quantitative estimation
about the time performance of the different LSP restoration about the time performance of the different LSP restoration
mechanisms (also referred to as LSP re-routing): mechanisms (also referred to as LSP re-routing):
skipping to change at line 1076 skipping to change at line 1083
LSP. 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, after failure occurrence, one or more failure(s) occur(s). Here, after failure occurrence, one or more
(disjoint) paths for the restoration LSP are dynamically computed (disjoint) paths for the restoration LSP are dynamically computed
and one is selected. As such, one can define this as a complete "LSP and one is selected. As such, one can define this as a complete "LSP
re-routing" mechanism. re-routing" mechanism.
D.Papadimitriou et al. - Expires October 2004 20 D.Papadimitriou et al. - Expires March 2005 20
No reservation or selection of resources is performed along the No reservation or selection of resources is performed along the
restoration path before failure occurrence. As a result, there is no restoration path before failure occurrence. As a result, there is no
guarantee that a restoration LSP is available when a failure occurs. guarantee that a restoration LSP is available when a failure occurs.
The expected total restoration time T is thus equal to Tc (+ Ts) + The expected total restoration time T is thus equal to Tc (+ Ts) +
Trs. Therefore, time performance between these two approaches Trs. Therefore, time performance between these two approaches
differs by the time required for route computation Tc (and its differs by the time required for route computation Tc (and its
potential selection time, Ts). potential selection time, Ts).
5.5.3 Pre-planned LSP Restoration 5.5.3 Pre-planned LSP Restoration
skipping to change at line 1116 skipping to change at line 1123
is considered, resource sharing should not be limited to restoration is considered, resource sharing should not be limited to restoration
LSPs starting and ending at the same ingress and egress nodes. LSPs starting and ending at the same ingress and egress nodes.
Therefore, each node participating to this scheme is expected to Therefore, each node participating to this scheme is expected to
receive some feedback information on the sharing degree of the receive some feedback information on the sharing degree of the
recovery resource(s) that this scheme involves. recovery resource(s) that this scheme involves.
Upon failure detection/notification message reception, signaling is Upon failure detection/notification message reception, signaling is
initiated along the restoration path to select the resources, and to initiated along the restoration path to select the resources, and to
perform the appropriate operation at each node crossed by the perform the appropriate operation at each node crossed by the
restoration LSP (e.g. cross-connections). If lower priority LSPs restoration LSP (e.g. cross-connections). If lower priority LSPs
were established using the restoration resources, they MUST be were established using the restoration resources, they must be
preempted when the restoration LSP is activated. preempted when the restoration LSP is activated.
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
Before failure occurrence, an end-to-end restoration path is pre- Before failure occurrence, an end-to-end restoration path is pre-
selected from a set of pre-computed (disjoint) paths. The selected from a set of pre-computed (disjoint) paths. The
restoration LSP is signaled along this pre-selected path to reserve restoration LSP is signaled along this pre-selected path to reserve
AND select resources at each node but these resources are not AND select resources at each node but these resources are not
committed at the data plane level. Such that the selection of the committed at the data plane level. Such that the selection of the
D.Papadimitriou et al. - Expires October 2004 21 D.Papadimitriou et al. - Expires March 2005 21
recovery resources is committed at the control plane level only, no recovery resources is committed at the control plane level only, no
cross-connections are performed along the restoration path. cross-connections are performed along the restoration path.
In this case, the resources reserved and selected for each In this case, the resources reserved and selected for each
restoration LSP may be dedicated or even shared between multiple restoration LSP may be dedicated or even shared between multiple
restoration LSPs whose associated working LSPs are not expected to restoration LSPs whose associated working LSPs are not expected to
fail simultaneously. Local node policies can be applied to define fail simultaneously. Local node policies can be applied to define
the degree to which these resources can be shared across independent the degree to which these resources can be shared across independent
failures. Also, since a restoration scheme is considered, resource failures. Also, since a restoration scheme is considered, resource
sharing should not be limited to restoration LSPs starting and sharing should not be limited to restoration LSPs starting and
ending at the same ingress and egress nodes. Therefore, each node ending at the same ingress and egress nodes. Therefore, each node
participating to this scheme is expected to receive some feedback participating to this scheme is expected to receive some feedback
information on the sharing degree of the recovery resource(s) that information on the sharing degree of the recovery resource(s) that
this scheme involves. this scheme involves.
Upon failure detection/notification message reception, signaling is Upon failure detection/notification message reception, signaling is
initiated along the restoration path to activate the reserved and initiated along the restoration path to activate the reserved and
selected resources, and to perform the appropriate operation at each selected resources, and to perform the appropriate operation at each
node crossed by the restoration LSP (e.g. cross-connections). If node crossed by the restoration LSP (e.g. cross-connections). If
lower priority LSPs were established using the restoration lower priority LSPs were established using the restoration
resources, they MUST be preempted when the restoration LSP is resources, they must be preempted when the restoration LSP is
activated. 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).
5.5.4 LSP Segment Restoration 5.5.4 LSP Segment Restoration
skipping to change at line 1185 skipping to change at line 1192
6. Reversion 6. Reversion
Reversion (a.k.a. normalization) is defined as the mechanism Reversion (a.k.a. normalization) is defined as the mechanism
allowing switching of normal traffic from the recovery LSP/span to allowing switching of normal traffic from the recovery LSP/span to
the working LSP/span previously under failure condition. Use of the working LSP/span previously under failure condition. Use of
normalization is at the discretion of the recovery domain policy. normalization is at the discretion of the recovery domain policy.
Normalization (also referred to as reversion) may impact the normal Normalization (also referred to as reversion) may impact the normal
traffic (a second hit) depending on the normalization mechanism traffic (a second hit) depending on the normalization mechanism
used. used.
D.Papadimitriou et al. - Expires October 2004 22 D.Papadimitriou et al. - Expires March 2005 22
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) the the working LSP/span when the failure condition clears 2) the
capability to de-activate (turn-off) the use of reversion should be capability to de-activate (turn-off) the use of reversion should be
provided. De-activation of reversion should not impact the normal provided. De-activation of reversion should not impact the normal
traffic regardless of whether currently using the working or traffic regardless of whether currently using the working or
recovery LSP/span. recovery LSP/span.
Note: during the failure, the reuse of any non-failed resources Note: during the failure, the reuse of any non-failed resources
(e.g. LSP and/or spans) belonging to the working LSP/span is under (e.g. LSP and/or spans) belonging to the working LSP/span is under
the discretion of recovery domain policy. the discretion of recovery domain policy.
skipping to change at line 1240 skipping to change at line 1247
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 particular situation occurs when the previously working LSP/span
D.Papadimitriou et al. - Expires October 2004 23 D.Papadimitriou et al. - Expires March 2005 23
cannot be recovered such that normal traffic can not be switched cannot be recovered such that normal traffic can not be switched
back. In such a case, the LSP/span under failure condition (also back. In such a case, the LSP/span under failure condition (also
referred to as "orphan") must be cleared i.e. removed from the pool referred to as "orphan") must be cleared i.e. removed from the pool
of 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 expected here. and behavior different mechanisms are expected here.
Therefore any reserved or allocated resources for the LSP/span under Therefore any reserved or allocated resources for the LSP/span under
failure condition must be unreserved/de-allocated. Several ways can failure condition must be unreserved/de-allocated. Several ways can
skipping to change at line 1294 skipping to change at line 1301
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
D.Papadimitriou et al. - Expires October 2004 24 D.Papadimitriou et al. - Expires March 2005 24
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-
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
skipping to change at line 1338 skipping to change at line 1345
- Potential recovery capabilities with different temporal - Potential recovery capabilities with different temporal
granularities: ranging from milliseconds to tens of seconds granularities: ranging from milliseconds to tens of seconds
Note: based on the bandwidth granularity we can determine four Note: based on the bandwidth granularity we can determine four
classes of vertical hierarchies (1) packet over packet (2) packet classes of vertical hierarchies (1) packet over packet (2) packet
over circuit (3) circuit over packet and (4) circuit over circuit. over circuit (3) circuit over packet and (4) circuit over circuit.
Below we briefly expand on (4) only. (2) is covered in [RFC3386]. Below we briefly expand on (4) only. (2) is covered in [RFC3386].
(1) is extensively covered by the MPLS Working Group, and (3) by the (1) is extensively covered by the MPLS Working Group, and (3) by the
PWE3 Working Group. PWE3 Working Group.
In SDH/Sonet environments, one typically considers the VT_SPE/LOVC In SONET/SDH environments, one typically considers the VT_SPE/LOVC
and STS SPE/HOVC as independent layers, VT_SPE/LOVC LSP using the and STS SPE/HOVC as independent layers, 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, controlled by a link management protocol such as LMP. link, controlled by a link management protocol such as LMP.
D.Papadimitriou et al. - Expires October 2004 25 D.Papadimitriou et al. - Expires March 2005 25
The first key issue with multi-layer recovery is that achieving The first key issue with multi-layer recovery is that achieving
individual or bulk LSP recovery will be as efficient as the individual or bulk LSP recovery will be as efficient as the
underlying link (local span) recovery. In such a case, the span can underlying link (local span) recovery. In such a case, the span can
be either protected or unprotected, but the LSP it carries MUST be be either protected or unprotected, but the LSP it carries must be
(at least locally) recoverable. Therefore, the span recovery process (at least locally) recoverable. Therefore, the span recovery process
can be either independent when protected (or restorable), or can be either independent when protected (or restorable), or
triggered by the upper LSP recovery process. The former case triggered by the upper LSP recovery process. The former case
requires coordination to achieve subsequent LSP recovery. Therefore, requires coordination to achieve subsequent LSP recovery. Therefore,
in order to achieve robustness and fast convergence, multi-layer in order to achieve robustness and fast convergence, multi-layer
recovery requires a fine-tuned coordination mechanism. recovery requires a fine-tuned coordination mechanism.
Moreover, in the absence of adequate recovery mechanism coordination Moreover, in the absence of adequate recovery mechanism coordination
(for instance, a pre-determined coordination when using a hold-off (for instance, a pre-determined coordination when using a hold-off
timer), a failure notification may propagate from one layer to the timer), a failure notification may propagate from one layer to the
skipping to change at line 1385 skipping to change at line 1392
[RFC3386], some looser form of coordination and communication [RFC3386], some looser form of coordination and communication
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, allowing the synchronization establishment) can be considered, allowing the synchronization
between recovery actions performed across these layers. between recovery actions performed across these layers.
7.2.1 Recovery Granularity 7.2.1 Recovery Granularity
In most environments, the design of the network and the vertical In most environments, the design of the network and the vertical
distribution of the LSP bandwidth are such that the recovery distribution of the LSP bandwidth are such that the recovery
granularity is finer at higher layers. The OTN and Sonet/SDH layers granularity is finer at higher layers. The OTN and SONET/SDH layers
can only recover the whole section or the individual connections it can only recover the whole section or the individual connections it
transports whereas the IP/MPLS control plane can recover individual transports whereas the IP/MPLS control plane can recover individual
packet LSPs or groups of packet LSPs and this independently of their packet LSPs or groups of packet LSPs and this independently of their
granularity. On the other side, the recovery granularity at the sub- granularity. On the other side, the recovery granularity at the sub-
wavelength level (i.e. Sonet/SDH) can be provided only when the wavelength level (i.e. SONET/SDH) can be provided only when the
network includes devices switching at the same granularity (and thus network includes devices switching at the same granularity (and thus
not with optical channel level). Therefore, the network layer can not with optical channel level). Therefore, the network layer can
deliver control-plane driven recovery mechanisms on a per-LSP basis deliver control-plane driven recovery mechanisms on a per-LSP basis
if and only if these LSPs have their corresponding switching if and only if these LSPs have their corresponding switching
granularity supported at the transport plane level. granularity supported at the transport plane level.
7.3 Escalation Strategies 7.3 Escalation Strategies
There are two types of escalation strategies (see [DEMEESTER]): There are two types of escalation strategies (see [DEMEESTER]):
bottom-up and top-down. bottom-up and top-down.
D.Papadimitriou et al. - Expires October 2004 26 D.Papadimitriou et al. - Expires March 2005 26
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 for instance a this assumption is not entirely true. Consider for instance a
Sonet/SDH based protection mechanism (with a less than 50 ms Sonet/SDH based protection mechanism (with a less than 50 ms
protection switching time) lying on top of an OTN restoration protection switching time) lying on top of an OTN restoration
mechanism (with a less than 200 ms restoration time). Therefore, mechanism (with a less than 200 ms restoration time). Therefore,
this assumption should be (at least) clarified as: lower layer this assumption should be (at least) clarified as: lower layer
recovery mechanism is expected to be faster than upper level one if recovery mechanism is expected to be faster than upper level one if
the same type of recovery mechanism is used at each layer. 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.
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 the optical layer performing the control plane enables for instance the optical layer performing the
failure management operations (in particular, failure detection and failure management operations (in particular, failure detection and
skipping to change at line 1457 skipping to change at line 1464
link will be recovered at the packet layer while another will be link will be recovered at the packet layer while another will be
recovered at the 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 their complete disjointness. Due to the common not guarantee their complete disjointness. Due to the common
physical layer topology (passive), additional hierarchical concepts physical layer topology (passive), additional hierarchical concepts
such as the Shared Risk Link Group (SRLG) and mechanisms such as such as the Shared Risk Link Group (SRLG) and mechanisms such as
D.Papadimitriou et al. - Expires October 2004 27 D.Papadimitriou et al. - Expires March 2005 27
SRLG diverse path computation must be developed to provide complete SRLG diverse path computation must be developed to provide complete
working and recovery LSP/span disjointness (see [IPO-IMP] and working and recovery LSP/span disjointness (see [IPO-IMP] and
[GMPLS-RTG]). Otherwise, a failure affecting the working LSP/span [GMPLS-RTG]). Otherwise, a failure affecting the working LSP/span
would also potentially affect the recovery LSP/span; one refers to would also potentially affect the recovery LSP/span; one refers to
such an event as "common failure". such an event as "common failure".
7.4.1 SRLG Disjointness 7.4.1 SRLG Disjointness
A Shared Risk Link Group (SRLG) is defined as the set of links A Shared Risk Link Group (SRLG) is defined as the set of links
sharing a common risk (for instance, a common physical resource such sharing a common risk (for instance, a common physical resource such
skipping to change at line 1510 skipping to change at line 1517
necessary (but not a sufficient) condition to ensure network necessary (but not a sufficient) condition to ensure network
survivability. With respect to the physical network resources, a survivability. With respect to the physical network resources, a
working-recovery LSP/span pair must be SRLG disjoint in case of working-recovery LSP/span pair must be SRLG disjoint in case of
dedicated recovery type. On the other hand, in case of shared dedicated recovery type. On the other hand, in case of shared
recovery, a group of working LSP/span must be mutually SRLG-disjoint recovery, a group of working LSP/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 LSPs/spans. itself SRLG-disjoint from each of the working LSPs/spans.
8. Recovery Mechanisms Analysis 8. Recovery Mechanisms Analysis
D.Papadimitriou et al. - Expires October 2004 28 D.Papadimitriou et al. - Expires March 2005 28
In order to provide a structured analysis of the recovery mechanisms In order to provide a structured analysis of the recovery mechanisms
detailed in the previous sections, the following dimensions can be detailed in the previous sections, the following dimensions can be
considered: considered:
1. Fast convergence (performance): provide a mechanism that 1. Fast convergence (performance): provide a mechanism that
aggregates multiple failures (this implies fast failure aggregates multiple failures (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).
skipping to change at line 1548 skipping to change at line 1555
However, these dimensions are either outside the scope of this However, these dimensions are either outside the scope of this
document such as cost optimization and recovery path computational document such as cost optimization and recovery path computational
aspects or mutually conflicting. For instance, it is obvious that aspects or mutually conflicting. For instance, it is obvious that
providing a 1+1 LSP protection minimizes the LSP downtime (in case providing a 1+1 LSP protection minimizes the LSP downtime (in case
of failure) while being non-scalable and consuming recovery resource of failure) while being non-scalable and consuming recovery resource
without enabling any extra-traffic. without enabling any extra-traffic.
The following sections provide an analysis of the recovery phases The following sections provide an analysis of the recovery phases
and mechanisms detailed in the previous sections with respect to the and mechanisms detailed in the previous sections with respect to the
dimensions described here above to assess the current GMPLS protocol dimensions described here above to assess the GMPLS protocol suite
suite capabilities and applicability. In turn, this allows the capabilities and applicability. In turn, this allows the evaluation
evaluation of the potential need for further GMPLS signaling and of the potential need for further GMPLS signaling and routing
routing extensions. extensions.
8.1 Fast Convergence (Detection/Correlation and Hold-off Time) 8.1 Fast Convergence (Detection/Correlation and Hold-off Time)
Fast convergence is related to the failure management operations. It Fast convergence is related to the failure management operations. It
refers to the elapsing time between the failure detection/ refers to the 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 detailed in Section 4. actions are initiated. This point has been detailed in Section 4.
8.2 Efficiency (Recovery Switching Time) 8.2 Efficiency (Recovery Switching Time)
In general, the more pre-assignment/pre-planning of the recovery In general, the more pre-assignment/pre-planning of the recovery
LSP/span, the more rapid the recovery is. Since protection implies LSP/span, the more rapid the recovery is. Since protection implies
D.Papadimitriou et al. - Expires October 2004 29 D.Papadimitriou et al. - Expires March 2005 29
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 is likely to be slower than most span protection Span restoration is likely to be slower than most span protection
types; however this greatly depends on the efficiency of the span types; however this greatly depends on the efficiency of the span
restoration signalling. LSP restoration with pre-signaled and pre- restoration signalling. LSP restoration with pre-signaled and pre-
selected recovery resources is likely to be faster than fully selected recovery resources is likely to be faster than fully
dynamic LSP restoration, especially because of the elimination of dynamic LSP restoration, especially because of the elimination of
any potential crankback during the recovery LSP establishment. any potential crankback during the recovery LSP establishment.
skipping to change at line 1599 skipping to change at line 1606
such is more robust with respect to the failure scenario scope. such is more robust with respect to the failure scenario scope.
Moreover, LSP segment restoration, in particular, dynamic Moreover, LSP segment restoration, in particular, dynamic
restoration (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-reserved) will generally be faster than end-to-end resource is pre-reserved) will generally be faster than end-to-end
LSP restoration. 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 LSP restoration requires only that this operation while end-to-end LSP restoration requires only that
LSP end-points 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 [RFC3386]. mechanisms have been proposed through a separate effort [RFC3386].
8.3 Robustness 8.3 Robustness
In general, the less pre-assignment (protection)/pre-planning In general, the less pre-assignment (protection)/pre-planning
(restoration) of the recovery LSP/span, the more robust the recovery (restoration) of the recovery LSP/span, the more robust the recovery
type or scheme is to a variety of single failures, provided that type or scheme is to a variety of single failures, provided that
adequate resources are available. Moreover, the pre-selection of the adequate resources are available. Moreover, the pre-selection of the
recovery resources gives in the case of multiple failure scenarios recovery resources gives in the case of multiple failure scenarios
less flexibility than no recovery resource pre-selection. For less flexibility than no recovery resource pre-selection. For
instance, if failures occur that affect two LSPs sharing a common instance, if failures occur that affect two LSPs sharing a common
link along their restoration paths, then only one of these LSPs can link along their restoration paths, then only one of these LSPs can
be recovered. This occurs unless the restoration path of at least be recovered. This occurs unless the restoration path of at least
one of these LSPs is re-computed or the local resource assignment is one of these LSPs is re-computed or the local resource assignment is
modified on the fly. modified on the fly.
D.Papadimitriou et al. - Expires October 2004 30 D.Papadimitriou et al. - Expires March 2005 30
In addition, recovery types and schemes with pre-planned recovery In addition, recovery types and schemes with pre-planned recovery
resources, in particular LSP/spans for protection and LSPs for resources, in particular LSP/spans for protection and LSPs for
restoration purposes, will not be able to recover from failures that restoration purposes, will not be able to recover from failures that
simultaneously affect both the working and recovery LSP/span. Thus, simultaneously affect both the working and recovery LSP/span. Thus,
the recovery resources should ideally be as disjoint as possible the recovery resources should ideally be as disjoint as possible
(with respect to link, node and SRLG) from the working ones, so that (with respect to link, node and SRLG) from the working ones, so that
any single failure event will not affect both working and recovery any single failure event will not affect both working and recovery
LSP/span. In brief, working and recovery resource must be fully LSP/span. In brief, working and recovery resource must be fully
diverse in order to guarantee that a given failure will not affect diverse in order to guarantee that a given failure will not affect
simultaneously the working and the recovery LSP/span. Also, the risk simultaneously the working and the recovery LSP/span. Also, the risk
skipping to change at line 1673 skipping to change at line 1680
working LSP/span) allowing for extra-traffic. Obviously, 1+1 working LSP/span) allowing for extra-traffic. Obviously, 1+1
protection precludes and 1:1 recovery does not allow for any protection precludes and 1:1 recovery does not allow for any
recovery LSP/span sharing whereas 1:N and M:N recovery do allow recovery LSP/span sharing whereas 1:N and M:N recovery do allow
sharing of 1 (M, respectively) recovery LSP/spans between N working sharing of 1 (M, respectively) recovery LSP/spans between N working
LSP/spans. However, despite the fact that 1:1 LSP recovery precludes LSP/spans. However, despite the fact that 1:1 LSP recovery precludes
the sharing of the recovery LSP, the recovery schemes (see Section 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 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 its recovery resources. In addition, the flexibility in the usage of
shared recovery resources (in particular, shared links) may be shared recovery resources (in particular, shared links) may be
D.Papadimitriou et al. - Expires October 2004 31 D.Papadimitriou et al. - Expires March 2005 31
limited because of network topology restrictions, e.g. fixed ring limited because of network topology restrictions, e.g. fixed ring
topology for traditional enhanced protection schemes. topology for traditional enhanced protection schemes.
On the other hand, when using LSP restoration with pre-signaled On the other hand, when using LSP restoration with pre-signaled
resource reservation, the amount of reserved restoration capacity is resource reservation, the amount of reserved restoration capacity is
determined by the local bandwidth reservation policies. In LSP determined by the local bandwidth reservation policies. In LSP
restoration schemes with re-provisioning, a pool of spare resources restoration schemes with re-provisioning, a pool of spare resources
can be defined from which all resources are selected after failure can be defined from which all resources are selected after failure
occurrence for the purpose of restoration path computation. The occurrence for the purpose of restoration path computation. The
degree to which restoration schemes allow sharing amongst multiple degree to which restoration schemes allow sharing amongst multiple
skipping to change at line 1728 skipping to change at line 1735
amount of (over-provisioned) resources that can be used for shared amount of (over-provisioned) resources that can be used for shared
recovery purposes is known from the IGP. recovery purposes is known from the IGP.
In order to analyze this behavior, we define the difference between In order to analyze this behavior, we define the difference between
the Maximum Reservable Bandwidth (in the present case, this value is the Maximum Reservable Bandwidth (in the present case, this value is
greater than the Maximum Link Bandwidth) and the Maximum LSP greater than the Maximum Link Bandwidth) and the Maximum LSP
Bandwidth per TE link i as the Maximum Shareable Bandwidth or Bandwidth per TE link i as the Maximum Shareable Bandwidth or
max_R[i]. Within this quantity, the amount of bandwidth currently max_R[i]. Within this quantity, the amount of bandwidth currently
allocated for shared recovery per TE link i is defined as R[i]. Both allocated for shared recovery per TE link i is defined as R[i]. Both
D.Papadimitriou et al. - Expires October 2004 32 D.Papadimitriou et al. - Expires March 2005 32
quantities are expressed in terms of discrete bandwidth units (and quantities are expressed in terms of discrete bandwidth units (and
thus, the Minimum LSP Bandwidth is of one bandwidth unit). thus, the Minimum LSP Bandwidth is of one bandwidth unit).
The knowledge of this information available per TE link can be The knowledge of this information available per TE link can be
exploited in order to optimize the usage of the resources allocated exploited in order to optimize the usage of the resources allocated
per TE link for shared recovery. If one refers to r[i] as the actual per TE link for shared recovery. If one refers to r[i] as the actual
bandwidth per TE link i (in terms of discrete bandwidth units) bandwidth per TE link i (in terms of discrete bandwidth units)
committed for shared recovery, then the following quantity must be committed for shared recovery, then the following quantity must be
maximized over the potential TE link candidates: maximized over the potential TE link candidates:
skipping to change at line 1782 skipping to change at line 1789
----- ----- <--- Minimum LSP Bandwidth ----- ----- <--- Minimum LSP Bandwidth
-------- 0 ---------- 0 -------- 0 ---------- 0
Note that the above approach does not require the flooding of any Note that the above approach does not require the flooding of any
per LSP information or any detailed distribution of the bandwidth per LSP information or any detailed distribution of the bandwidth
allocation per component link or individual ports or even any per- allocation per component link or individual ports or even any per-
priority shareable recovery bandwidth information (using a dedicated priority shareable recovery bandwidth information (using a dedicated
sub-TLV). The latter would provide the same capability than the sub-TLV). The latter would provide the same capability than the
already defined Maximum LSP bandwidth per-priority information. Such already defined Maximum LSP bandwidth per-priority information. Such
D.Papadimitriou et al. - Expires October 2004 33 D.Papadimitriou et al. - Expires March 2005 33
approach is referred to as a Partial (or Aggregated) Information approach is referred to as a Partial (or Aggregated) Information
Routing as described for instance in [KODIALAM1] and [KODIALAM2]. Routing as described for instance in [KODIALAM1] and [KODIALAM2].
They show that the difference obtained with a Full (or Complete) They show that the difference obtained with a Full (or Complete)
Information Routing approach (where for the whole set of working and Information Routing approach (where for the whole set of working and
recovery LSPs, the amount of bandwidth units they use per-link is recovery LSPs, the amount of bandwidth units they use per-link is
known at each node and for each link) is clearly negligible. The known at each node and for each link) is clearly negligible. The
latter approach is detailed in [GLI], for instance. Note also that latter approach is detailed in [GLI], for instance. Note also that
both approaches rely on the deterministic knowledge (at different both approaches rely on the deterministic knowledge (at different
degrees) of the network topology and resource usage status. degrees) of the network topology and resource usage status.
skipping to change at line 1836 skipping to change at line 1843
reserved on the TE link and the current number of SRLGs recoverable reserved on the TE link and the current number of SRLGs recoverable
by this amount of (shared) recovery resources reserved on the TE by this amount of (shared) recovery resources reserved on the TE
link. The latter is equivalent to the current number of SRLGs that link. The latter is equivalent to the current number of SRLGs that
the recovery LSPs sharing the recovery resource reserved on the TE the recovery LSPs sharing the recovery resource reserved on the TE
link shall recover. Then, if explicit SRLG recoverability is link shall recover. Then, if explicit SRLG recoverability is
considered an additional TE link attribute including the explicit considered an additional TE link attribute including the explicit
list of SRLGs recoverable by the shared recovery resource reserved list of SRLGs recoverable by the shared recovery resource reserved
on the TE link and their respective shareable recovery bandwidth. on the TE link and their respective shareable recovery bandwidth.
The latter information is equivalent to the shareable recovery The latter information is equivalent to the shareable recovery
D.Papadimitriou et al. - Expires October 2004 34 D.Papadimitriou et al. - Expires March 2005 34
bandwidth per SRLG (or per group of SRLGs) which implies to consider bandwidth per SRLG (or per group of SRLGs) which implies to consider
a decreasing amount of shareable bandwidth and SRLG list over time. a decreasing amount of shareable bandwidth and SRLG list over time.
Compared to the case of recovery resource sharing only (regardless Compared to the case of recovery resource sharing only (regardless
of SRLG recoverability, as described in Section 8.4.1), this of SRLG recoverability, as described in Section 8.4.1), this
additional TE link attributes would potentially deliver better path additional TE link attributes would potentially deliver better path
computation and selection (at distinct ingress node) for shared mesh computation and selection (at distinct ingress node) for shared mesh
recovery purposes. However, due to the lack of results of evidence recovery purposes. However, due to the lack of results of evidence
for better efficiency and due to the complexity that such extensions for better efficiency and due to the complexity that such extensions
would generate, they are not further considered in the scope of the would generate, they are not further considered in the scope of the
present analysis. For instance, a per-SRLG group minimum/maximum present analysis. For instance, a per-SRLG group minimum/maximum
shareable recovery bandwidth is restricted by the length that the shareable recovery bandwidth is restricted by the length that the
corresponding (sub-)TLV may take and thus the number of SRLGs that corresponding (sub-)TLV may take and thus the number of SRLGs that
it can include. Therefore, the corresponding parameter SHOULD not be it can include. Therefore, the corresponding parameter should not be
translated into GMPLS routing (or even signalling) protocol translated into GMPLS routing (or even signalling) protocol
extensions in the form of TE link sub-TLV. extensions in the form of TE link sub-TLV.
8.4.3 Recovery Resource Sharing, SRLG Disjointness and Admission 8.4.3 Recovery Resource Sharing, SRLG Disjointness and Admission
Control Control
Admission control is a strict requirement to be fulfilled by nodes Admission control is a strict requirement to be fulfilled by nodes
giving access to shared links. This can be illustrated using the giving access to shared links. This can be illustrated using the
following network topology: following network topology:
skipping to change at line 1891 skipping to change at line 1898
(implying for instance, that the path followed by the working LSP is (implying for instance, that the path followed by the working LSP is
carried with the corresponding recovery LSP request). If node E can carried with the corresponding recovery LSP request). If node E can
guarantee that the working LSPs (A-C-D and B-C-D) are SRLG disjoint guarantee that the working LSPs (A-C-D and B-C-D) are SRLG disjoint
over the C-D span, it may securely accept the incoming recovery LSP over the C-D span, it may securely accept the incoming recovery LSP
request and assign to the recovery LSPs (A-E-F-D and B-E-F-D) the request and assign to the recovery LSPs (A-E-F-D and B-E-F-D) the
same resources on the link E-F. This, if the link E-F has not yet same resources on the link E-F. This, if the link E-F has not yet
reached its maximum recovery bandwidth sharing ratio. In this reached its maximum recovery bandwidth sharing ratio. In this
example, one assumes that the node failure probability is negligible example, one assumes that the node failure probability is negligible
compared to the link failure probability. compared to the link failure probability.
D.Papadimitriou et al. - Expires October 2004 35 D.Papadimitriou et al. - Expires March 2005 35
To achieve this, the path followed by the working LSP is transported To achieve this, the path followed by the working LSP is transported
with the recovery LSP request and examined at each upstream node of with the recovery LSP request and examined at each upstream node of
potentially shareable links. Admission control is performed using potentially shareable links. Admission control is performed using
the interface identifiers (included in the path) to retrieve in the the interface identifiers (included in the path) to retrieve in the
TE DataBase the list of SRLG Ids associated to each of the working TE DataBase the list of SRLG Ids associated to each of the working
LSP links. If the working LSPs (A-C-D and B-C-D) have one or more LSP links. If the working LSPs (A-C-D and B-C-D) have one or more
link or SRLG id in common (in this example, one or more SRLG id in link or SRLG id in common (in this example, one or more SRLG id in
common over the span C-D) node E should not assign the same resource common over the span C-D) node E should not assign the same resource
over link E-F to the recovery LSPs (A-E-F-D and B-E-F-D). Otherwise, over link E-F to the recovery LSPs (A-E-F-D and B-E-F-D). Otherwise,
one of these working LSPs would not be recoverable in case of C-D one of these working LSPs would not be recoverable in case of C-D
skipping to change at line 1945 skipping to change at line 1952
| | less flexible | | | less flexible |
| 1 | less robust | | 1 | less robust |
| | most resource consuming | | | most resource consuming |
Path | | | Path | | |
Setup ------------------------------------------------------------ Setup ------------------------------------------------------------
| | relatively fast recovery | Does not apply | | relatively fast recovery | Does not apply
| | relatively flexible | | | relatively flexible |
| 2 | relatively robust | | 2 | relatively robust |
| | resource consumption | | | resource consumption |
D.Papadimitriou et al. - Expires October 2004 36 D.Papadimitriou et al. - Expires March 2005 36
| | depends on sharing degree | | | depends on sharing degree |
------------------------------------------------------------ ------------------------------------------------------------
| | relatively fast recovery | less faster (computation) | | relatively fast recovery | less faster (computation)
| | more flexible | most flexible | | more flexible | most flexible
| 3 | relatively robust | most robust | 3 | relatively robust | most robust
| | less resource consuming | least resource consuming | | less resource consuming | least resource consuming
| | depends on sharing degree | | | depends on sharing degree |
-------------------------------------------------------------------- --------------------------------------------------------------------
1a. Recovery LSP setup (before failure occurrence) with resource 1a. Recovery LSP setup (before failure occurrence) with resource
skipping to change at line 1999 skipping to change at line 2006
routing extensions are expected to efficiently implement any of routing extensions are expected to efficiently implement any of
these recovery types and schemes. these recovery types and schemes.
10. Security Considerations 10. Security Considerations
This document does not introduce any additional security issue or This document does not introduce any additional security issue or
imply any specific security consideration from [GMPLS-ARCH] to the imply any specific security consideration from [GMPLS-ARCH] to the
current RSVP-TE GMPLS signaling, routing protocols (OSPF-TE, IS-IS- current RSVP-TE GMPLS signaling, routing protocols (OSPF-TE, IS-IS-
TE) or network management protocols (SNMP). TE) or network management protocols (SNMP).
D.Papadimitriou et al. - Expires October 2004 37 D.Papadimitriou et al. - Expires March 2005 37
However, the authorization of requests for resources by GMPLS- However, the authorization of requests for resources by GMPLS-
capable nodes SHOULD determining whether a given party, presumable capable nodes should determining whether a given party, presumable
already authenticated, has a right to access the requested already authenticated, has a right to access the requested
resources. This determination is typically a matter of local policy resources. This determination is typically a matter of local policy
control, for example by setting limits on the total bandwidth made control, for example by setting limits on the total bandwidth made
available to some party in the presence of resource contention. Such available to some party in the presence of resource contention. Such
policies may become quite complex as the number of users, types of policies may become quite complex as the number of users, types of
resources and sophistication of authorization rules increases. This resources and sophistication of authorization rules increases. This
is particularly the case for recovery schemes that assume pre- is particularly the case for recovery schemes that assume pre-
planned sharing of recovery resources, or contention for resources planned sharing of recovery resources, or contention for resources
in case of dynamic re-routing. in case of dynamic re-routing.
skipping to change at line 2027 skipping to change at line 2034
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 Labs), David Griffith (NIST) and Lyndon Ong (Ciena) for (Fujitsu Labs), David Griffith (NIST) and Lyndon Ong (Ciena) for
their useful comments. their useful comments.
Thanks also to Adrian Farrel for the thorough review of the Thanks also to Adrian Farrel for the thorough review of the
document. document.
12. Intellectual Property Considerations 12. References
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
12.1 IPR Disclosure Acknowledgement
D.Papadimitriou et al. - Expires October 2004 38
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance
with RFC 3668.
13. References
13.1 Normative References 12.1 Normative References
[BUNDLE] K.Kompella et al., "Link Bundling in MPLS Traffic [BUNDLE] K.Kompella et al., "Link Bundling in MPLS Traffic
Engineering," Work in progress, draft-ietf-mpls-bundle- Engineering," Work in progress, draft-ietf-mpls-bundle-
04.txt, August 2002. 04.txt, August 2002.
[GMPLS-ARCH] E.Mannie (Editor) et al., "Generalized Multi-Protocol [GMPLS-ARCH] E.Mannie (Editor) et al., "Generalized Multi-Protocol
Label Switching Architecture," Work in progress, draft- Label Switching Architecture," Work in progress, draft-
ietf-ccamp-gmpls-architecture-07.txt, May 2003. ietf-ccamp-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
skipping to change at line 2086 skipping to change at line 2061
[LMP] J.P.Lang (Editor) et al., "Link Management Protocol [LMP] J.P.Lang (Editor) et al., "Link Management Protocol
(LMP)," Work in progress, draft-ietf-ccamp-lmp-10.txt, (LMP)," Work in progress, draft-ietf-ccamp-lmp-10.txt,
October 2003. October 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 Dense Wavelength Division Protocol (LMP) for Dense Wavelength Division
Multiplexing (DWDM) Optical Line Systems," Work in Multiplexing (DWDM) Optical Line Systems," Work in
progress, draft-ietf-ccamp-lmp-wdm-03.txt, October progress, draft-ietf-ccamp-lmp-wdm-03.txt, October
2003. 2003.
D.Papadimitriou et al. - Expires March 2005 38
[RFC2026] S.Bradner, "The Internet Standards Process -- Revision [RFC2026] S.Bradner, "The Internet Standards Process -- Revision
3," BCP 9, IETF RFC 2026, October 1996. 3," BCP 9, RFC 2026, October 1996.
[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, IETF RFC 2119, March 1997. Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC3471] L.Berger (Editor) et al., "Generalized Multi-Protocol [RFC3471] L.Berger (Editor) et al., "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Functional Label Switching (GMPLS) Signaling Functional
Description," IETF RFC 3471, January 2003. Description," RFC 3471, January 2003.
[RFC3473] L.Berger (Editor) et al., "Generalized Multi-Protocol [RFC3473] L.Berger (Editor) et al., "Generalized Multi-Protocol
Label Switching (GMPLS) Signaling Resource ReserVation Label Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions," Protocol-Traffic Engineering (RSVP-TE) Extensions," RFC
IETF RFC 3473, January 2003. 3473, January 2003.
[RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004.
[RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004.
[TERM] E.Mannie and D.Papadimitriou (Editors), "Recovery [TERM] E.Mannie and D.Papadimitriou (Editors), "Recovery
(Protection and Restoration) Terminology for (Protection and Restoration) Terminology for
Generalized Multi-Protocol Label Switching (GMPLS)," Generalized Multi-Protocol Label Switching (GMPLS),"
Work in progress, draft-ietf-ccamp-gmpls-recovery- Work in progress, draft-ietf-ccamp-gmpls-recovery-
terminology-04.txt, April 2004. terminology-05.txt, October 2004.
D.Papadimitriou et al. - Expires October 2004 39
13.2 Informative References 12.2 Informative References
[BOUILLET] E.Bouillet et al., "Stochastic Approaches to Compute [BOUILLET] E.Bouillet et al., "Stochastic Approaches to Compute
Shared Meshed Restored Lightpaths in Optical Network Shared Meshed Restored Lightpaths in Optical Network
Architectures," IEEE Infocom 2002, New York City, June Architectures," IEEE Infocom 2002, New York City, June
2002. 2002.
[DEMEESTER] P.Demeester et al., "Resilience in Multilayer [DEMEESTER] P.Demeester et al., "Resilience in Multilayer
Networks," IEEE Communications Magazine, Vol. 37, No. Networks," IEEE Communications Magazine, Vol. 37, No.
8, pp. 70-76, August 1998. 8, pp. 70-76, August 1998.
[G.707] ITU-T, "Network Node Interface for the Synchronous
Digital Hierarchy (SDH)," Recommendation G.707, October
2000.
[G.709] ITU-T, "Network Node Interface for the Optical
Transport Network (OTN)," Recommendation G.709,
February 2001 (and Amendment nó1, October 2001).
[G.783] ITU-T, "Characteristics of Synchronous Digital
Hierarchy (SDH) Equipment Functional Blocks,"
Recommendation G.783, October 2000.
[G.806] ITU-T, "Characteristics of Transport Equipment -
Description Methodology and Generic Functionality",
Recommendation G.806, October 2000.
[G.808.1] ITU-T, "Generic Protection Switching - Linear trail and
Subnetwork Protection," Recommendation G.808.1,
December 2003.
[G.841] ITU-T, "Types and Characteristics of SDH Network
Protection Architectures," Recommendation G.841,
October 1998.
[G.842] ITU-T, "Interworking of SDH network protection
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.
[IPO-IMP] J.Strand and A.Chiu, "Impairments and Other Constraints [IPO-IMP] J.Strand and A.Chiu, "Impairments and Other Constraints
On Optical Layer Routing," Work in Progress, draft- On Optical Layer Routing," Work in Progress, draft-
ietf-ipo-impairments-05.txt, May 2003. ietf-ipo-impairments-05.txt, May 2003.
[KODIALAM1] M.Kodialam and T.V.Lakshman, "Restorable Dynamic [KODIALAM1] M.Kodialam and T.V.Lakshman, "Restorable Dynamic
Quality of Service Routing," IEEE Communications Quality of Service Routing," IEEE Communications
Magazine, pp. 72-81, June 2002. Magazine, pp. 72-81, June 2002.
[KODIALAM2] M.Kodialam and T.V.Lakshman, "Dynamic Routing of [KODIALAM2] M.Kodialam and T.V.Lakshman, "Dynamic Routing of
Restorable Bandwidth-Guaranteed Tunnels using Restorable Bandwidth-Guaranteed Tunnels using
D.Papadimitriou et al. - Expires October 2004 40 D.Papadimitriou et al. - Expires March 2005 39
Aggregated Network Resource Usage Information," IEEE/ Aggregated Network Resource Usage Information," IEEE/
ACM Transactions on Networking, pp. 399-410, June 2003. 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.
[RFC3386] W.Lai, D.McDysan, J.Boyle, et al., "Network Hierarchy [RFC3386] W.Lai, D.McDysan, J.Boyle, et al., "Network Hierarchy
and Multi-layer Survivability," IETF RFC 3386, November and Multi-layer Survivability," RFC 3386, November 2002
2002.
[RFC3469] V.Sharma and F.Hellstrand (Editors), "Framework for [RFC3469] 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. RFC 3469, February 2003.
[T1.105] ANSI, "Synchronous Optical Network (SONET): Basic [T1.105] ANSI, "Synchronous Optical Network (SONET): Basic
Description Including Multiplex Structure, Rates, and Description Including Multiplex Structure, Rates, and
Formats," ANSI T1.105, January 2001. Formats," ANSI T1.105, January 2001.
[WANG] J.Wang, L.Sahasrabuddhe, and B.Mukherjee, "Path vs. [WANG] J.Wang, L.Sahasrabuddhe, and B.Mukherjee, "Path vs.
Subpath vs. Link Restoration for Fault Management in Subpath vs. Link Restoration for Fault Management in
IP-over-WDM Networks: Performance Comparisons Using IP-over-WDM Networks: Performance Comparisons Using
GMPLS Control Signaling," IEEE Communications Magazine, GMPLS Control Signaling," IEEE Communications Magazine,
pp. 80-87, November 2002. pp. 80-87, November 2002.
14. Editor's Addresses For information on the availability of the following documents,
please see http://www.itu.int
[G.707] ITU-T, "Network Node Interface for the Synchronous
Digital Hierarchy (SDH)," Recommendation G.707, October
2000.
[G.709] ITU-T, "Network Node Interface for the Optical
Transport Network (OTN)," Recommendation G.709,
February 2001 (and Amendment nó1, October 2001).
[G.783] ITU-T, "Characteristics of Synchronous Digital
Hierarchy (SDH) Equipment Functional Blocks,"
Recommendation G.783, October 2000.
[G.806] ITU-T, "Characteristics of Transport Equipment -
Description Methodology and Generic Functionality",
Recommendation G.806, October 2000.
[G.808.1] ITU-T, "Generic Protection Switching - Linear trail and
Subnetwork Protection," Recommendation G.808.1,
December 2003.
[G.841] ITU-T, "Types and Characteristics of SDH Network
Protection Architectures," Recommendation G.841,
October 1998.
[G.842] ITU-T, "Interworking of SDH network protection
architectures," Recommendation G.842, October 1998.
D.Papadimitriou et al. - Expires March 2005 40
13. Editor's Addresses
Eric Mannie Eric Mannie
EMail: eric_mannie@hotmail.com EMail: 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
EMail: dimitri.papadimitriou@alcatel.be EMail: dimitri.papadimitriou@alcatel.be
D.Papadimitriou et al. - Expires October 2004 41 D.Papadimitriou et al. - Expires March 2005 41
Full Copyright Statement Intellectual Property Statement
Copyright (C) The Internet Society (2004). This document is subject The IETF takes no position regarding the validity or scope of any
to the rights, licenses and restrictions contained in BCP 78 and Intellectual Property Rights or other rights that might be claimed
except as set forth therein, the authors retain all their rights. to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
D.Papadimitriou et al. - Expires October 2004 42 Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
D.Papadimitriou et al. - Expires March 2005 42
 End of changes. 

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