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
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
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.
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
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:
- 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
- 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.
- 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.
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
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.
- 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