doc: Add RFC documents

1 files changed, 2635 insertions, 0 deletions

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