< draft-ietf-mpls-recovery-frmwrk-00.txt   draft-ietf-mpls-recovery-frmwrk-01.txt >
IETF Draft Vishal Sharma IETF Draft Vishal Sharma
Multi-Protocol Label Switching Ben-Mack Crane Multi-Protocol Label Switching Ben-Mack Crane
Expires: March 2001 Srinivas Makam Expires: May 2001 Srinivas Makam
Ken Owens Ken Owens
Tellabs Operations, Inc. Tellabs Operations, Inc.
Changcheng Huang Changcheng Huang
Carleton University Carleton University
Fiffi Hellstrand Fiffi Hellstrand
Jon Weil Jon Weil
Loa Andersson Loa Andersson
Bilel Jamoussi Bilel Jamoussi
Nortel Networks Nortel Networks
Brad Cain Brad Cain
Mirror Image Internet Mirror Image Internet
Seyhan Civanlar Seyhan Civanlar
Coreon Networks Coreon Networks
Angela Chiu Angela Chiu
AT&T Labs AT&T Labs
September 2000 November 2000
Framework for MPLS-based Recovery Framework for MPLS-based Recovery
<draft-ietf-mpls-recovery-frmwrk-00.txt> <draft-ietf-mpls-recovery-frmwrk-01.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts. Internet-Drafts are draft documents valid for a maximum of Internet-Drafts are draft documents valid for a maximum of six months
six months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet-Drafts time. It is inappropriate to use Internet-Drafts as reference
as reference material or to cite them other than as "work in material or to cite them other than as "work in progress."
progress." The list of current Internet-Drafts can be accessed at
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
http://www.ietf.org/shadow.html.
Abstract Abstract
Multi-protocol label switching (MPLS) [1] integrates the label Multi-protocol label switching (MPLS) [1] integrates the label
swapping forwarding paradigm with network layer routing. To deliver swapping forwarding paradigm with network layer routing. To deliver
reliable service, MPLS requires a set of procedures to provide reliable service, MPLS requires a set of procedures to provide
protection of the traffic carried on different paths. This requires protection of the traffic carried on different paths. This requires
that the label switched routers (LSRs) support fault detection, that the label switched routers (LSRs) support fault detection, fault
fault notification, and fault recovery mechanisms, and that MPLS notification, and fault recovery mechanisms, and that MPLS signaling
signaling [2] [3] [4] [5] [6] support the configuration of [2] [3] [4] [5] [6] support the configuration of recovery. With these
recovery. With these objectives in mind, this document specifies a objectives in mind, this document specifies a framework for MPLS
framework for MPLS based recovery. based recovery.
Table of Contents Page Table of Contents Page
1.0 Introduction 3 1.0 Introduction 3
1.1 Background 3 1.1 Background 3
1.2 Motivations for MPLS-Based Recovery 3 1.2 Motivations for MPLS-Based Recovery 3
1.3 Objectives 4 1.3 Objectives 4
2.0 Overview 5 2.0 Overview 5
2.1 Recovery Models 6 2.1 Recovery Models 6
2.2 Recovery Cycles 7 2.2 Recovery Cycles 7
2.2.1 MPLS Recovery Cycle Model 7 2.2.1 MPLS Recovery Cycle Model 7
2.2.2 MPLS Reversion Cycle Model 9 2.2.2 MPLS Reversion Cycle Model 9
2.2.3 Dynamic Reroute Cycle Model 10 2.2.3 Dynamic Reroute Cycle Model 10
2.3 Definitions and Terminology 11 2.3 Definitions and Terminology 11
2.4 Abbreviations 15 2.4 Abbreviations 15
3.0 MPLS Recovery Principles 15 3.0 MPLS Recovery Principles 15
3.1 Configuration of Recovery 15 3.1 Configuration of Recovery 15
3.2 Initiation of Path Setup 15 3.2 Initiation of Path Setup 15
3.3 Initiation of Resource Allocation 16 3.3 Initiation of Resource Allocation 16
3.4 Scope of Recovery 17 3.4 Scope of Recovery 17
3.4.1 Topology 17 3.4.1 Topology 17
3.4.1.1 Local Repair 17 3.4.1.1 Local Repair 17
3.4.1.2 Global Repair 17 3.4.1.2 Global Repair 17
3.4.1.3 Alternate Egress Repair 18 3.4.1.3 Alternate Egress Repair 18
3.4.1.4 Multi-Layer Repair 18 3.4.1.4 Multi-Layer Repair 18
3.4.1.5 Concatenated Protection Domains 18 3.4.1.5 Concatenated Protection Domains 18
3.4.2 Path Mapping 18 3.4.2 Path Mapping 18
3.4.3 Bypass Tunnels 19 3.4.3 Bypass Tunnels 19
3.4.4 Recovery Granularity 20 3.4.4 Recovery Granularity 20
3.4.4.1 Selective Traffic Recovery 20 3.4.4.1 Selective Traffic Recovery 20
3.4.4.2 Bundling 20 3.4.4.2 Bundling 20
3.4.5 Recovery Path Resource Use 20 3.4.5 Recovery Path Resource Use 20
3.5 Fault Detection 21 3.5 Fault Detection 21
3.6 Fault Notification 21 3.6 Fault Notification 21
3.7 Switch Over Operation 22 3.7 Switch Over Operation 22
3.7.1 Recovery Trigger 22 3.7.1 Recovery Trigger 22
3.7.2 Recovery Action 22 3.7.2 Recovery Action 22
3.8 Switch Back Operation 23 3.8 Switch Back Operation 23
3.8.1 Revertive and Non-revertive Mode 23 3.8.1 Fixed Protection Counterparts 23
3.8.2 Restoration and Notification 23 3.8.2 Dynamic Protection Counterparts 24
3.8.3 Reverting to Preferred Path 23 3.8.3 Restoration and Notification 25
3.9 Performance 24 3.8.4 Reverting to Preferred Path 25
3.9 Performance 26
4.0 Recovery Requirements 25 4.0 Recovery Requirements 26
5.0 MPLS Recovery Options 25 5.0 MPLS Recovery Options 27
6.0 Comparison Criteria 26 6.0 Comparison Criteria 27
7.0 Security Considerations 27 7.0 Security Considerations 29
8.0 Intellectual Property Considerations 27 8.0 Intellectual Property Considerations 29
9.0 Acknowledgements 28 9.0 Acknowledgements 29
10.0 Author's Addresses 28 10.0 Author's Addresses 30
11.0 References 29 11.0 References 30
1.0 Introduction 1.0 Introduction
This memo describes a framework for MPLS-based recovery. We provide This memo describes a framework for MPLS-based recovery. We provide a
a detailed taxonomy of recovery terminology, and discuss the detailed taxonomy of recovery terminology, and discuss the motivation
motivation for, the objectives of, and the requirements for MPLS- for, the objectives of, and the requirements for MPLS-based recovery.
based recovery. We outline principles for MPLS-based recovery, and We outline principles for MPLS-based recovery, and also provide
also provide comparison criteria that may serve as a basis for comparison criteria that may serve as a basis for comparing and
comparing and evaluating different recovery schemes. evaluating different recovery schemes.
1.1 Background 1.1 Background
Network routing deployed today is focussed primarily on Network routing deployed today is focussed primarily on connectivity
connectivity and typically supports only one class of service, the and typically supports only one class of service, the best effort
best effort class. Multi-protocol label switching, on the other class. Multi-protocol label switching, on the other hand, by
hand, by integrating forwarding based on label-swapping of a link integrating forwarding based on label-swapping of a link local label
local label with network layer routing allows flexibility in the with network layer routing allows flexibility in the delivery of new
delivery of new routing services. MPLS allows for using media routing services. MPLS allows for using such media specific
specific forwarding mechanisms as label swapping. This enables more forwarding mechanisms as label swapping. This enables more
sophisticated features such as quality-of-service (QoS) and traffic sophisticated features such as quality-of-service (QoS) and traffic
engineering [7] to be implemented more effectively. An important engineering [7] to be implemented more effectively. An important
component of providing QoS, however, is the ability to transport component of providing QoS, however, is the ability to transport data
data reliably and efficiently. Although the current routing reliably and efficiently. Although the current routing algorithms are
algorithms are very robust and survivable, the amount of time they very robust and survivable, the amount of time they take to recover
take to recover from a fault can be significant, on the order of from a fault can be significant, on the order of several seconds or
several seconds or minutes, causing serious disruption of service minutes, causing serious disruption of service for some applications
for some applications in the interim. This is unacceptable to many in the interim. This is unacceptable to many organizations that aim
organizations that aim to provide a highly reliable service, and to provide a highly reliable service, and thus require recovery times
thus require recovery times on the order of tens of milliseconds, on the order of tens of milliseconds, as specified, for example, in
as specified, for example, in the GR253 specification for SONET. the GR253 specification for SONET.
MPLS recovery may be motivated by the notion that there are MPLS recovery may be motivated by the notion that there are inherent
inherent limitations to improving the recovery times of current limitations to improving the recovery times of current routing
routing algorithms. Additional improvement not obtainable by other algorithms. Additional improvement not obtainable by other means can
means can be obtained by augmenting these algorithms with MPLS be obtained by augmenting these algorithms with MPLS recovery
recovery mechanisms. Since MPLS is likely to be the technology of mechanisms. Since MPLS is likely to be the technology of choice in
choice in the future IP-based transport network, it is useful that the future IP-based transport network, it is useful that MPLS be able
MPLS be able to provide protection and restoration of traffic. to provide protection and restoration of traffic. MPLS may
MPLS may facilitate the convergence of network functionality on a facilitate the convergence of network functionality on a common
common control and management plane. Further, a protection priority control and management plane. Further, a protection priority could be
could be used as a differentiating mechanism for premium services used as a differentiating mechanism for premium services that require
that require high reliability. The remainder of this document high reliability. The remainder of this document provides a framework
provides a framework for MPLS based recovery. It is focused at a for MPLS based recovery. It is focused at a conceptual level and is
conceptual level and is meant to address motivation, objectives and meant to address motivation, objectives and requirements. Issues of
requirements. Issues of mechanism, policy, routing plans and mechanism, policy, routing plans and characteristics of traffic
characteristics of traffic carried by protection paths are beyond carried by recovery paths are beyond the scope of this document.
the scope of this document.
1.2 Motivation for MPLS-Based Recovery 1.2 Motivation for MPLS-Based Recovery
MPLS based protection of traffic (called MPLS-based Recovery) is
useful for a number of reasons. The most important is its ability
to increase network reliability by enabling a faster response to
faults than is possible with traditional Layer 3 (or the IP layer)
alone while still providing the visibility of the network afforded
Layer 3. Furthermore, a protection mechanism using MPLS could
enable IP traffic to be put directly over WDM optical channels,
without an intervening SONET layer. This would facilitate the
construction of IP-over-WDM networks.
The need for MPLS-based recovery arises because of the following: MPLS based protection of traffic (called MPLS-based Recovery) is
useful for a number of reasons. The most important is its ability to
increase network reliability by enabling a faster response to faults
than is possible with traditional Layer 3 (or IP layer) approaches
alone while still providing the visibility of the network afforded by
Layer 3. Furthermore, a protection mechanism using MPLS could enable
IP traffic to be put directly over WDM optical channels, without an
intervening SONET layer. This would facilitate the construction of
IP-over-WDM networks.
I. Layer 3 or IP rerouting may be too slow for a core MPLS network The need for MPLS-based recovery arises because of the following:
that needs to support high reliability/availability.
II. Layer 0 (for example, optical layer) or Layer 1 (for example, I. Layer 3 or IP rerouting may be too slow for a core MPLS network
SONET) mechanisms may not be deployed in topologies that meet that needs to support high reliability/availability.
carriersĘ protection goals.
III. The granularity at which the lower layers may be able to II. Layer 0 (for example, optical layer) or Layer 1 (for example,
protect traffic may be too coarse for traffic that is switched SONET) mechanisms may not be deployed in topologies that meet
using MPLS-based mechanisms. carriers' protection goals.
IV. Layer 0 or Layer 1 mechanisms may have no visibility into III. The granularity at which the lower layers may be able to protect
higher layer operations. Thus, while they may provide, for traffic may be too coarse for traffic that is switched using MPLS-
example, link protection, they cannot easily provide node based mechanisms.
protection or protection of traffic transported using MPLS.
Furthermore there is a need for open standards. IV. Layer 0 or Layer 1 mechanisms may have no visibility into higher
layer operations. Thus, while they may provide, for example, link
protection, they cannot easily provide node protection or protection
of traffic transported at layer 3.
V. Establishing interoperability of protection mechanisms between V. MPLS has desirable attributes when applied to the purpose of
routers/LSRs from different vendors in IP or MPLS networks is recovery for connectionless networks. Specifically that an LSP is
urgently required to enable the adoption of MPLS as a viable core source routed and a forwarding path for recovery can be "pinned" and
transport and traffic engineering technology. is not affected by transient instability in SPF routing brought on by
failure scenarios.
1.3 Objectives/Goals Furthermore there is a need for open standards.
We lay down the following objectives for MPLS-based recovery. VI. Establishing interoperability of protection mechanisms between
routers/LSRs from different vendors in IP or MPLS networks is
urgently required to enable the adoption of MPLS as a viable core
transport and traffic engineering technology.
I. MPLS-based recovery mechanisms should facilitate fast (10Ęs of 1.3 Objectives/Goals
ms) recovery times.
II. MPLS-based recovery should maximize network reliability and We lay down the following objectives for MPLS-based recovery.
availability. MPLS based protection of traffic should minimize the
number of single points of failure in the MPLS protected domain.
III. MPLS based recovery should enhance the reliability of the I. MPLS-based recovery mechanisms should facilitate fast (10's of ms)
protected traffic while minimally or predictably degrading the recovery times.
traffic carried by the diverted resources.
IV. MPLS-based recovery techniques should be applicable for II. MPLS-based recovery should maximize network reliability and
protection of traffic at various granularities. For example, it availability. MPLS-based recovery of traffic should minimize the
should be possible to specify MPLS-based recovery for a portion of number of single points of failure in the MPLS protected domain.
the traffic on an individual path, for all traffic on an individual
path, or for all traffic on a group of paths.
V. MPLS-based recovery techniques may be applicable for an entire III. MPLS-based recovery should enhance the reliability of the
end-to-end path or for segments of an end-to-end path. protected traffic while minimally or predictably degrading the
traffic carried by the diverted resources.
VI. MPLS-based recovery actions should not adversely affect other IV. MPLS-based recovery techniques should be applicable for
network operations. protection of traffic at various granularities. For example, it
should be possible to specify MPLS-based recovery for a portion of
the traffic on an individual path, for all traffic on an individual
path, or for all traffic on a group of paths. Note that a path is
used as a general term and includes the notion of a link, IP route or
LSP.
VII. MPLS-based recovery actions in one MPLS protection domain V. MPLS-based recovery techniques may be applicable for an entire
(defined in Section 2.2) should not adversely affect the recovery end-to-end path or for segments of an end-to-end path.
actions in other MPLS protection domains.
VII. MPLS-based recovery mechanisms should be able to take into VI. MPLS-based recovery actions should not adversely affect other
consideration the recovery actions of lower layers. network operations.
VIII. MPLS-based recovery actions should avoid network-layering VII. MPLS-based recovery actions in one MPLS protection domain
violations. That is, defects in MPLS-based mechanisms should not (defined in Section 2.2) should not adversely affect the recovery
trigger lower layer protection switching. actions in other MPLS protection domains.
IX. MPLS-based recovery mechanisms should minimize the loss of data VII. MPLS-based recovery mechanisms should be able to take into
and packet reordering during recovery operations. (The current MPLS consideration the recovery actions of lower layers.
specification has itself no explicit requirement on reordering).
X. MPLS-based recovery mechanisms should minimize the state VIII. MPLS-based recovery actions should avoid network-layering
overhead incurred for each recovery path maintained. violations. That is, defects in MPLS-based mechanisms should not
trigger lower layer protection switching.
XI. MPLS-based recovery mechanisms should be able to preserve the IX. MPLS-based recovery mechanisms should minimize the loss of data
constraints on traffic after switchover, if desired. That is, if and packet reordering during recovery operations. (The current MPLS
desired, the recovery path should meet the resource requirements specification has itself no explicit requirement on reordering).
of, and achieve the same performance characteristics, as the
working path.
2.0 Overview X. MPLS-based recovery mechanisms should minimize the state overhead
incurred for each recovery path maintained.
There are several options for providing protection of traffic using XI. MPLS-based recovery mechanisms should be able to preserve the
MPLS. The most generic requirement is the specification of whether constraints on traffic after switchover, if desired. That is, if
recovery should be via Layer 3 (or IP) rerouting or via MPLS desired, the recovery path should meet the resource requirements of,
protection switching or rerouting actions. and achieve the same performance characteristics as the working path.
Generally network operators aim to provide the fastest and the best 2.0 Overview
protection mechanism that can be provided at a reasonable cost. The
higher the level of protection, the more resources it consumes,
therefore it is expected that network operators will offer a
spectrum of service levels. MPLS-based recovery should give the
flexibility to select the recovery mechanism, choose the
granularity at which traffic is protected, and to also choose the
specific types of traffic that are protected in order to give
operators more control over that tradeoff. With MPLS-based
recovery, it can be possible to provide different levels of
protection for different classes of service, based on their service
requirements. For example, using approaches outlined below, a VLL
service that supports real-time applications like VoIP may be
supported using link/node protection together with pre-established,
pre-reserved path protection, while best effort traffic may use
established-on-demand path protection or simply rely on IP re-
route or higher layer recovery mechanisms. As another example of
their range of application, MPLS-based recovery strategies may be
used to protect traffic not originally flowing on label switched
paths, such as IP traffic that is normally routed hop-by-hop, as
well as traffic forwarded on label switched paths.
2.1 Recovery Models There are several options for providing protection of traffic using
MPLS. The most generic requirement is the specification of whether
recovery should be via Layer 3 (or IP) rerouting or via MPLS
protection switching or rerouting actions.
There are two basic models for path recovery: rerouting and Generally network operators aim to provide the fastest and the best
protection switching. protection mechanism that can be provided at a reasonable cost. The
higher the level of protection, the more resources are consumed.
Therefore it is expected that network operators will offer a spectrum
of service levels. MPLS-based recovery should give the flexibility to
select the recovery mechanism, choose the granularity at which
traffic is protected, and to also choose the specific types of
traffic that are protected in order to give operators more control
over that tradeoff. With MPLS-based recovery, it can be possible to
provide different levels of protection for different classes of
service, based on their service requirements. For example, using
approaches outlined below, a VLL service that supports real-time
applications like VoIP may be supported using link/node protection
together with pre-established, pre-reserved path protection, while
best effort traffic may use established-on-demand path protection or
simply rely on IP re-route or higher layer recovery mechanisms. As
another example of their range of application, MPLS-based recovery
strategies may be used to protect traffic not originally flowing on
label switched paths, such as IP traffic that is normally routed hop-
by-hop, as well as traffic forwarded on label switched paths.
Protection switching and rerouting, as defined below, may be used 2.1 Recovery Models
together. For example, protection switching to a recovery path may
be used for rapid restoration of connectivity while rerouting
determines a new optimal network configuration, rearranging paths,
as needed, at a later time [8] [9].
2.1.1 Rerouting There are two basic models for path recovery: rerouting and
protection switching.
Recovery by rerouting is defined as establishing new paths or path Protection switching and rerouting, as defined below, may be used
segments on demand for restoring traffic after the occurrence of a together. For example, protection switching to a recovery path may
fault. The new paths may be based upon fault information, network be used for rapid restoration of connectivity while rerouting
routing policies, pre-defined configurations and network topology determines a new optimal network configuration, rearranging paths, as
information. Thus, upon detecting a fault, paths or path segments needed, at a later time [8] [9].
to bypass the fault are established using signaling. Reroute
mechanisms are inherently slower than protection switching
mechanisms, since more must be done following the detection of a
fault. However reroute mechanisms are simpler and more frugal as no
resources are committed until after the fault occurs and the
location of the fault is known.
Pre-planned techniques need to take into account all possible 2.1.1 Rerouting
failures in the protected domain such that " blind switching" upon
detection of failure has a high probability of providing useful
recovery.
Once the network routing algorithms have converged after a fault,
it may be preferable, in some cases, to reoptimize the network by
performing a reroute based on the current state of the network and
network policies. This is currently discussed further in Section
3.8, but will also be clarified further in upcoming revisions of
this document.
In terms of the principles defined in section 3, reroute recovery Recovery by rerouting is defined as establishing new paths or path
employs paths established-on-demand with resources reserved-on- segments on demand for restoring traffic after the occurrence of a
demand. fault. The new paths may be based upon fault information, network
routing policies, pre-defined configurations and network topology
information. Thus, upon detecting a fault, paths or path segments to
bypass the fault are established using signaling. Reroute mechanisms
are inherently slower than protection switching mechanisms, since
more must be done following the detection of a fault. However reroute
mechanisms are simpler and more frugal as no resources are committed
until after the fault occurs and the location of the fault is known.
2.1.2 Protection Switching Once the network routing algorithms have converged after a fault, it
may be preferable, in some cases, to reoptimize the network by
performing a reroute based on the current state of the network and
network policies. This is discussed further in Section 3.8.
Protection switching recovery mechanisms pre-establish a recovery In terms of the principles defined in section 3, reroute recovery
path or path segment, based upon network routing policies, the employs paths established-on-demand with resources reserved-on-
restoration requirements of the traffic on the working path, and demand.
administrative considerations. The recovery path may or may not be
link and node disjoint with the working path [10]. However if the
recovery path shares sources of failure with the working path, the
overall reliability of the construct is degraded. When a fault is
detected, the protected traffic is switched over to the recovery
path(s) and restored.
In terms of the principles in section 3, protection switching 2.1.2 Protection Switching
employs pre-established recovery paths, and if resource reservation
is required on the recovery path, pre-reserved resources.
2.1.2.1. Subtypes of Protection Switching Protection switching recovery mechanisms pre-establish a recovery
path or path segment, based upon network routing policies, the
restoration requirements of the traffic on the working path, and
administrative considerations. The recovery path may or may not be
link and node disjoint with the working path [10]. However if the
recovery path shares sources of failure with the working path, the
overall reliability of the construct is degraded. When a fault is
detected, the protected traffic is switched over to the recovery
path(s) and restored.
The resources (bandwidth, buffers, processing) on the recovery path In terms of the principles in section 3, protection switching employs
may be used to carry either a copy of the working path traffic or pre-established recovery paths, and if resource reservation is
extra traffic that is displaced when a protection switch occurs. required on the recovery path, pre-reserved resources.
This leads to two subtypes of protection switching.
In 1+1 ("one plus one") protection, the resources (bandwidth, 2.1.2.1. Subtypes of Protection Switching
buffers, processing capacity) on the recovery path are fully
reserved, and carry the same traffic as the working path. Selection
between the traffic on the working and recovery paths is made at
the path merge LSR (PML). In effect the PSL function is deprecated
to establishment of the working and protection paths and a simple
replication function. The recovery intelligence is delegated to the
PML.
In 1:1 ("one for one") protection, the resources (if any) allocated The resources (bandwidth, buffers, processing) on the recovery path
on the recovery path are fully available to preemptible low may be used to carry either a copy of the working path traffic or
priority traffic except when the recovery path is in use due to a extra traffic that is displaced when a protection switch occurs.
fault on the working path. In other words, in 1:1 protection, the This leads to two subtypes of protection switching.
protected traffic normally travels only on the working path, and is
switched to the recovery path only when the working path has a
fault. Once the protection switch is initiated, the low priority
traffic being carried on the recovery path may be displaced by the
protected traffic. This method affords a way to make efficient use
of the recovery path resources.
This concept can be extended to 1:n (one for n) and m:n (m for n) In 1+1 ("one plus one") protection, the resources (bandwidth,
protection. buffers, processing capacity) on the recovery path are fully
reserved, and carry the same traffic as the working path. Selection
between the traffic on the working and recovery paths is made at the
path merge LSR (PML). In effect the PSL function is deprecated to
establishment of the working and recovery paths and a simple
replication function. The recovery intelligence is delegated to the
PML.
Additional specifications of the recovery actions are found in In 1:1 ("one for one") protection, the resources (if any) allocated
Section on the recovery path are fully available to preemptible low priority
traffic except when the recovery path is in use due to a fault on the
working path. In other words, in 1:1 protection, the protected
traffic normally travels only on the working path, and is switched to
the recovery path only when the working path has a fault. Once the
protection switch is initiated, the low priority traffic being
carried on the recovery path may be displaced by the protected
traffic. This method affords a way to make efficient use of the
recovery path resources.
2.2 The Recovery Cycles This concept can be extended to 1:n (one for n) and m:n (m for n)
protection.
There are three defined recovery cycles; the MPLS Recovery Cycle, 2.2 The Recovery Cycles
the MPLS Reversion Cycle and the Dynamic Re-routing Cycle. The
first cycle detects a fault and restores traffic onto MPLS-based
recovery paths. If the recovery path is non-optimal the cycle may
be followed by any of the two latter to achieve an optimized
network again. The reversion cycle applies for explicitly routed
traffic that that does not rely on any dynamic routing protocols to
be converged. The dynamic re-routing cycle applies for traffic that
is forwarded based on hop-by-hop routing.
2.2.1 MPLS Recovery Cycle Model There are three defined recovery cycles; the MPLS Recovery Cycle, the
The MPLS recovery cycle model is illustrated in Figure 1. MPLS Reversion Cycle and the Dynamic Re-routing Cycle. The first
Definitions and a key to abbreviations follow. cycle detects a fault and restores traffic onto MPLS-based recovery
paths. If the recovery path is non-optimal the cycle may be followed
by any of the two latter to achieve an optimized network again. The
reversion cycle applies for explicitly routed traffic that that does
not rely on any dynamic routing protocols to be converged. The
dynamic re-routing cycle applies for traffic that is forwarded based
on hop-by-hop routing.
--Network Impairment 2.2.1 MPLS Recovery Cycle Model
| --Fault Detected
| | --Start of Notification
| | | -- Start of Recovery Operation
| | | | --Recovery Operation Complete
| | | | | --Path Traffic Restored
| | | | | |
| | | | | |
v v v v v v
----------------------------------------------------------------
| T1 | T2 | T3 | T4 | T5 |
Figure 1. MPLS Recovery Cycle Model The MPLS recovery cycle model is illustrated in Figure 1.
Definitions and a key to abbreviations follow.
The various timing measures used in the model are described below. --Network Impairment
T1 Fault Detection Time | --Fault Detected
T2 Hold-off Time | | --Start of Notification
T3 Notification Time | | | -- Start of Recovery Operation
T4 Recovery Operation Time | | | | --Recovery Operation Complete
T5 Traffic Restoration Time | | | | | --Path Traffic Restored
| | | | | |
| | | | | |
v v v v v v
----------------------------------------------------------------
| T1 | T2 | T3 | T4 | T5 |
Definitions of the recovery cycle times are as follows: Figure 1. MPLS Recovery Cycle Model
Fault Detection Time The various timing measures used in the model are described below.
T1 Fault Detection Time
T2 Hold-off Time
T3 Notification Time
T4 Recovery Operation Time
T5 Traffic Restoration Time
The time between the occurrence of a network impairment and the Definitions of the recovery cycle times are as follows:
moment the fault is detected by MPLS-based recovery mechanisms.
This time may be highly dependent on lower layer protocols.
Hold-Off Time Fault Detection Time
The configured waiting time between the detection of a fault and The time between the occurrence of a network impairment and the
taking MPLS-based recovery action, to allow time for lower layer moment the fault is detected by MPLS-based recovery mechanisms. This
protection to take effect. The Hold-off Time may be zero. time may be highly dependent on lower layer protocols.
Note: The Hold-Off Time may occur after the Notification Time Hold-Off Time
interval if the node responsible for the switchover, the Path
Switch LSR (PSL), rather than the detecting LSR, is configured to
wait.
Notification Time The configured waiting time between the detection of a fault and
taking MPLS-based recovery action, to allow time for lower layer
protection to take effect. The Hold-off Time may be zero.
The time between initiation of a fault indication signal (FIS) by Note: The Hold-Off Time may occur after the Notification Time
the LSR detecting the fault and the time at which the Path Switch interval if the node responsible for the switchover, the Path Switch
LSR (PSL) begins the recovery operation. This is zero if the PSL LSR (PSL), rather than the detecting LSR, is configured to wait.
detects the fault itself or infers a fault from such events as an
adjacency failure.
Note: If the PSL detects the fault itself, there still may be a Notification Time
Hold-Off Time period between detection and the start of the The time between initiation of a fault indication signal (FIS) by the
recovery operation. LSR detecting the fault and the time at which the Path Switch LSR
(PSL) begins the recovery operation. This is zero if the PSL detects
the fault itself or infers a fault from such events as an adjacency
failure.
Recovery Operation Time Note: If the PSL detects the fault itself, there still may be a Hold-
Off Time period between detection and the start of the recovery
operation.
The time between the first and last recovery actions. This may Recovery Operation Time
include message exchanges between the PSL and PML to coordinate
recovery actions.
Traffic Restoration Time The time between the first and last recovery actions. This may
include message exchanges between the PSL and PML to coordinate
recovery actions.
The time between the last recovery action and the time that the Traffic Restoration Time
traffic (if present) is completely recovered. This interval is
intended to account for the time required for traffic to once again
arrive at the point in the network that experienced disrupted or
degraded service due to the occurrence of the fault (e.g. the PML).
This time may depend on the location of the fault, the recovery
mechanism, and the propagation delay along the recovery path.
2.2.2 MPLS Reversion Cycle Model The time between the last recovery action and the time that the
traffic (if present) is completely recovered. This interval is
intended to account for the time required for traffic to once again
arrive at the point in the network that experienced disrupted or
degraded service due to the occurrence of the fault (e.g. the PML).
This time may depend on the location of the fault, the recovery
mechanism, and the propagation delay along the recovery path.
Protection switching, revertive mode, requires the traffic to be 2.2.2 MPLS Reversion Cycle Model
switched back to a preferred path when the fault on that path is
cleared. The MPLS reversion cycle model is illustrated in Figure
2. Note that the cycle shown below comes after the recovery cycle
shown in Fig. 1.
--Network Impairment Repaired Protection switching, revertive mode, requires the traffic to be
| --Fault Cleared switched back to a preferred path when the fault on that path is
| | --Path Available cleared. The MPLS reversion cycle model is illustrated in Figure 2.
| | | --Start of Reversion Operation Note that the cycle shown below comes after the recovery cycle shown
| | | | --Reversion Operation Complete in Fig. 1.
| | | | | --Traffic Restored on Preferred Path
| | | | | |
| | | | | |
v v v v v v
---------------------------------------------------------------
| T7 | T8 | T9 | T10| T11|
Figure 2. MPLS Reversion Cycle Model --Network Impairment Repaired
| --Fault Cleared
| | --Path Available
| | | --Start of Reversion Operation
| | | | --Reversion Operation Complete
| | | | | --Traffic Restored on Preferred Path
| | | | | |
| | | | | |
v v v v v v
-----------------------------------------------------------------
| T7 | T8 | T9 | T10| T11|
The various timing measures used in the model are described below. Figure 2. MPLS Reversion Cycle Model
T7 Fault Clearing Time
T8 Wait-to-Restore Time
T9 Notification Time
T10 Reversion Operation Time
T11 Traffic Restoration Time
Note that time T6 (not shown above) is the time for which the The various timing measures used in the model are described below.
network impairment is not repaired and traffic is flowing on the T7 Fault Clearing Time
recovery path. T8 Wait-to-Restore Time
T9 Notification Time
T10 Reversion Operation Time
T11 Traffic Restoration Time
Definitions of the reversion cycle times are as follows: Note that time T6 (not shown above) is the time for which the network
impairment is not repaired and traffic is flowing on the recovery
path.
Fault Clearing Time Definitions of the reversion cycle times are as follows:
The time between the repair of a network impairment and the time
that MPLS-based mechanisms learn that the fault has been cleared.
This time may be highly dependent on lower layer protocols.
Wait-to-Restore Time Fault Clearing Time
The configured waiting time between the clearing of a fault and The time between the repair of a network impairment and the time that
MPLS-based recovery action(s). Waiting time may be needed to MPLS-based mechanisms learn that the fault has been cleared. This
ensure the path is stable and to avoid flapping in cases where a time may be highly dependent on lower layer protocols.
fault is intermittent. The Wait-to-Restore Time may be zero.
Note: The Wait-to-Restore Time may occur after the Notification Wait-to-Restore Time
Time interval if the PSL is configured to wait.
Notification Time The configured waiting time between the clearing of a fault and MPLS-
based recovery action(s). Waiting time may be needed to ensure the
path is stable and to avoid flapping in cases where a fault is
intermittent. The Wait-to-Restore Time may be zero.
The time between initiation of an FRS by the LSR clearing the fault Note: The Wait-to-Restore Time may occur after the Notification Time
and the time at which the path switch LSR begins the reversion interval if the PSL is configured to wait.
operation. This is zero if the PSL clears the fault itself.
Note: If the PSL clears the fault itself, there still may be a
Wait-to-Restore Time period between fault clearing and the start of
the reversion operation.
Reversion Operation Time Notification Time
The time between the first and last reversion actions. This may The time between initiation of an FRS by the LSR clearing the fault
include message exchanges between the PSL and PML to coordinate and the time at which the path switch LSR begins the reversion
reversion actions. operation. This is zero if the PSL clears the fault itself.
Note: If the PSL clears the fault itself, there still may be a Wait-
to-Restore Time period between fault clearing and the start of the
reversion operation.
Traffic Restoration Time Reversion Operation Time
The time between the last reversion action and the time that The time between the first and last reversion actions. This may
traffic (if present) is completely restored on the preferred path. include message exchanges between the PSL and PML to coordinate
This interval is expected to be quite small since both paths are reversion actions.
working and care may be taken to limit the traffic disruption
(e.g., using "make before break" techniques and synchronous switch-
over).
In practice, the only interesting times in the reversion cycle are Traffic Restoration Time
the Wait-to-Restore Time and the Traffic Restoration Time (or some
other measure of traffic disruption). Given that both paths are
available, there is no need for rapid operation, and a well-
controlled switch-back with minimal disruption is desirable.
2.2.3 Dynamic Re-routing Cycle Model The time between the last reversion action and the time that traffic
(if present) is completely restored on the preferred path. This
interval is expected to be quite small since both paths are working
and care may be taken to limit the traffic disruption (e.g., using
"make before break" techniques and synchronous switch-over).
Dynamic rerouting aims to bring the IP network to a stable state In practice, the only interesting times in the reversion cycle are
after a network impairment has occurred. A re-optimized network is the Wait-to-Restore Time and the Traffic Restoration Time (or some
achieved after the routing protocols have converged, and the other measure of traffic disruption). Given that both paths are
traffic is moved from a recovery path to a (possibly) new working available, there is no need for rapid operation, and a well-
path. The steps involved in this mode are illustrated in Figure 3. controlled switch-back with minimal disruption is desirable.
Note that the cycle shown below may follow the recovery cycle shown 2.2.3 Dynamic Re-routing Cycle Model
in Fig. 1 or the reversion cycle shown in Fig. 2, or both (in the
event that both the recovery cycle and the reversion cycle take
place before the routing protocols converge, and after the
convergence of the routing protocols it is determined (based on on-
line algorithms or off-line traffic engineering tools, network
configuration, or a variety of other possible criteria) that there
is a better route for the working path).
--Network Enters a Semi-stable State after an Impairment Dynamic rerouting aims to bring the IP network to a stable state
| --Dynamic Routing Protocols Converge after a network impairment has occurred. A re-optimized network is
| | --Initiate Setup of New Working Path between PSL achieved after the routing protocols have converged, and the traffic
| | | and PML is moved from a recovery path to a (possibly) new working path. The
| | | --Switchover Operation Complete steps involved in this mode are illustrated in Figure 3.
| | | | --Traffic Moved to New Working Path
| | | | |
| | | | |
v v v v v
---------------------------------------------------------------
| T12 | T13 | T14 | T15 |
Figure 3. Dynamic Rerouting Cycle Model Note that the cycle shown below may be overlaid on the recovery
The various timing measures used in the model are described below. cycle shown in Fig. 1 or the reversion cycle shown in Fig. 2, or both
T12 Network Route Convergence Time (in the event that both the recovery cycle and the reversion cycle
T13 Hold-down Time (optional) take place before the routing protocols converge, and after the
T14 Switchover Operation Time convergence of the routing protocols it is determined (based on on-
T15 Traffic Restoration Time line algorithms or off-line traffic engineering tools, network
configuration, or a variety of other possible criteria) that there is
a better route for the working path).
Network Route Convergence Time --Network Enters a Semi-stable State after an Impairment
| --Dynamic Routing Protocols Converge
| | --Initiate Setup of New Working Path between PSL
| | | and PML
| | | --Switchover Operation Complete
| | | | --Traffic Moved to New Working Path
| | | | |
| | | | |
v v v v v
-----------------------------------------------------------------
| T12 | T13 | T14 | T15 |
We define the network route convergence time as the time taken for Figure 3. Dynamic Rerouting Cycle Model
the network routing protocols to converge and for the network to The various timing measures used in the model are described below.
reach a stable state. T12 Network Route Convergence Time
T13 Hold-down Time (optional)
T14 Switchover Operation Time
T15 Traffic Restoration Time
Holddown Time Network Route Convergence Time
We define the holddown period as a bounded time for which a We define the network route convergence time as the time taken for
recovery path must be used. In some scenarios it may be difficult the network routing protocols to converge and for the network to
to determine if the working path is stable. In these cases a reach a stable state.
holddown time may be used to prevent excess flapping of traffic
between a working and a recovery path.
Switchover Operation Time Holddown Time
The time between the first and last switchover actions. This may We define the holddown period as a bounded time for which a recovery
include message exchanges between the PSL and PML to coordinate the path must be used. In some scenarios it may be difficult to determine
switchover actions. if the working path is stable. In these cases a holddown time may be
used to prevent excess flapping of traffic between a working and a
recovery path.
As an example of the recovery cycle, we present a sequence of Switchover Operation Time
events that occur after a network impairment occurs and when a The time between the first and last switchover actions. This may
protection switch is followed by dynamic rerouting. include message exchanges between the PSL and PML to coordinate the
switchover actions.
I. Link or path fault occurs As an example of the recovery cycle, we present a sequence of events
II. Signaling initiated (FIS) for the fault detected that occur after a network impairment occurs and when a protection
III. FIS arrives at the PSL switch is followed by dynamic rerouting.
IV. The PSL initiates a protection switch to a pre-configured
recovery path
V. The PSL switches over the traffic from the working path to the
recovery path
VI. The network enters a semi-stable state
VII. Dynamic routing protocols converge after the fault, and a new
working path is calculated (based, for example, on some of the
criteria mentioned earlier in Section 2.1.1).
VIII. A new working path is established between the PSL and the PML
(assumption is that PSL and PML have not changed)
IX. Traffic is switched over to the new working path.
2.3 Definitions and Terminology I. Link or path fault occurs
II. Signaling initiated (FIS) for the fault detected
III. FIS arrives at the PSL
IV. The PSL initiates a protection switch to a pre-configured
recovery path
V. The PSL switches over the traffic from the working path to the
recovery path
VI. The network enters a semi-stable state
VII. Dynamic routing protocols converge after the fault, and a new
working path is calculated (based, for example, on some of the
criteria mentioned earlier in Section 2.1.1).
VIII. A new working path is established between the PSL and the PML
(assumption is that PSL and PML have not changed)
IX. Traffic is switched over to the new working path.
This document assumes the terminology given in [11], and, in 2.3 Definitions and Terminology
addition, introduces the following new terms.
2.3.1 General Recovery Terminology This document assumes the terminology given in [11], and, in
addition, introduces the following new terms.
Rerouting 2.3.1 General Recovery Terminology
A recovery mechanism in which the recovery path or path segments Rerouting
are created dynamically after the detection of a fault on the
working path. In other words, a recovery mechanism in which the
recovery path is not pre-established.
Protection Switching A recovery mechanism in which the recovery path or path segments are
created dynamically after the detection of a fault on the working
path. In other words, a recovery mechanism in which the recovery path
is not pre-established.
A recovery mechanism in which the recovery path or path segments Protection Switching
are created prior to the detection of a fault on the working path.
In other words, a recovery mechanism in which the recovery path is
pre-established.
Working Path A recovery mechanism in which the recovery path or path segments are
created prior to the detection of a fault on the working path. In
other words, a recovery mechanism in which the recovery path is pre-
established.
The protected path that carries traffic before the occurrence of a Working Path
fault. The working path exists between a PSL and PML. The working
path can be of different kinds; a hop-by-hop routed path, a trunk,
a link, an LSP or part of a multipoint-to-point LSP.
Synonyms for a working path are primary path and active path. The protected path that carries traffic before the occurrence of a
fault. The working path exists between a PSL and PML. The working
path can be of different kinds; a hop-by-hop routed path, a trunk, a
link, an LSP or part of a multipoint-to-point LSP.
Recovery Path Synonyms for a working path are primary path and active path.
The path by which traffic is restored after the occurrence of a Recovery Path
fault. In other words, the path on which the traffic is directed by
the recovery mechanism. The recovery path is established by MPLS
means. The recovery path can either be an equivalent recovery path
and ensure no reduction in quality of service, or be a limited
recovery path and thereby not guarantee the same quality of service
(or some other criteria of performance) as the working path. A
limited recovery path is not expected to be used for an extended
period of time.
Synonyms for a recovery path are: back-up path, alternative path, The path by which traffic is restored after the occurrence of a
and protection path. fault. In other words, the path on which the traffic is directed by
the recovery mechanism. The recovery path is established by MPLS
means. The recovery path can either be an equivalent recovery path
and ensure no reduction in quality of service, or be a limited
recovery path and thereby not guarantee the same quality of service
(or some other criteria of performance) as the working path. A
limited recovery path is not expected to be used for an extended
period of time.
Protection Counterpart Synonyms for a recovery path are: back-up path, alternative path, and
protection path.
The "other" path when discussing pre-planned protection switching Protection Counterpart
schemes. The protection counterpart for the working path is the
recovery path and vice-versa.
Path Group (PG) The "other" path when discussing pre-planned protection switching
schemes. The protection counterpart for the working path is the
recovery path and vice-versa.
A logical bundling of multiple working paths, each of which is Path Group (PG)
routed identically between a Path Switch LSR and a Path Merge LSR.
Protected Path Group (PPG) A logical bundling of multiple working paths, each of which is routed
identically between a Path Switch LSR and a Path Merge LSR.
A path group that requires protection. Protected Path Group (PPG)
Protected Traffic Portion (PTP) A path group that requires protection.
The portion of the traffic on an individual path that requires
protection. For example, code points in the EXP bits of the shim
header may identify a protected portion.
Path Switch LSR (PSL) Protected Traffic Portion (PTP)
An LSR that is the transmitter of both the working path traffic and The portion of the traffic on an individual path that requires
its corresponding recovery path traffic. The PSL is responsible for protection. For example, code points in the EXP bits of the shim
switching or replicating the traffic between the working path and header may identify a protected portion.
the recovery path.
Path Merge LSR (PML) Path Switch LSR (PSL)
An LSR that receives both working path traffic and its The PSL is responsible for switching or replicating the traffic
corresponding recovery path traffic, and either merges their between the working path and the recovery path.
traffic into a single outgoing path, or, if it is itself the
destination, passes the traffic on to the higher layer protocols.
Intermediate LSR Path Merge LSR (PML)
An LSR on a working or recovery path that is neither a PSL nor a An LSR that receives both working path traffic and its corresponding
PML for that path. recovery path traffic, and either merges their traffic into a single
outgoing path, or, if it is itself the destination, passes the
traffic on to the higher layer protocols.
Bypass Tunnel Intermediate LSR
A path that serves to backup a set of working paths using the label An LSR on a working or recovery path that is neither a PSL nor a PML
stacking approach. The working paths and the bypass tunnel must all for that path.
share the same path switch LSR (PSL) and the path merge LSR (PML).
Switch-Over Bypass Tunnel
The process of switching the traffic from the path that the traffic A path that serves to back up a set of working paths using the label
is flowing on onto one or more alternate path(s). This may involve stacking approach [1]. The working paths and the bypass tunnel must
moving traffic from a working path onto one or more recovery paths, all share the same path switch LSR (PSL) and the path merge LSR
or may involve moving traffic from a recovery path(s) on to a more (PML).
optimal working path(s).
Switch-Back Switch-Over
The process of returning the traffic from one or more recovery The process of switching the traffic from the path that the traffic
paths back to the working path(s). is flowing on onto one or more alternate path(s). This may involve
moving traffic from a working path onto one or more recovery paths,
or may involve moving traffic from a recovery path(s) on to a more
optimal working path(s).
Revertive Mode Switch-Back
A recovery mode in which traffic is automatically switched back The process of returning the traffic from one or more recovery paths
from the recovery path to the original working path upon the back to the working path(s).
restoration of the working path to a fault-free condition.
Non-revertive Mode Revertive Mode
A recovery mode in which traffic is not automatically switched back A recovery mode in which traffic is automatically switched back from
to the original working path after this path is restored to a the recovery path to the original working path upon the restoration
fault-free condition. (Depending on the configuration, the original of the working path to a fault-free condition. This assumes a failed
working path may, upon moving to a fault-free condition, become the working path does not automatically surrender resources to the
recovery path, or it may be used for new working traffic, and be no network.
longer associated with its original recovery path).
MPLS Protection Domain Non-revertive Mode
The set of LSRs over which a working path and its corresponding A recovery mode in which traffic is not automatically switched back
recovery path are routed. to the original working path after this path is restored to a fault-
free condition. (Depending on the configuration, the original working
path may, upon moving to a fault-free condition, become the recovery
path, or it may be used for new working traffic, and be no longer
associated with its original recovery path).
MPLS Protection Plan MPLS Protection Domain
The set of all LSP protection paths and the mapping from working to The set of LSRs over which a working path and its corresponding
protection paths deployed in an MPLS protection domain at a given recovery path are routed.
time.
Liveness Message MPLS Protection Plan
A message exchanged periodically between two adjacent LSRs that The set of all LSP protection paths and the mapping from working to
serves as a link probing mechanism. It provides an integrity check protection paths deployed in an MPLS protection domain at a given
of the forward and the backward directions of the link between the time.
two LSRs as well as a check of neighbor aliveness.
Path Continuity Test Liveness Message
A test that verifies the integrity and continuity of a path or path A message exchanged periodically between two adjacent LSRs that
segment. The details of such a test are beyond the scope of this serves as a link probing mechanism. It provides an integrity check of
draft. (This could be accomplished, for example, by transmitting a the forward and the backward directions of the link between the two
control message along the same links and nodes as the data traffic LSRs as well as a check of neighbor aliveness.
or similarly could be measured by the absence of traffic and by
providing feedback.)
2.3.2 Failure Terminology Path Continuity Test
Path Failure (PF) A test that verifies the integrity and continuity of a path or path
Path failure is fault detected by MPLS-based recovery mechanisms, segment. The details of such a test are beyond the scope of this
which is define as the failure of the liveness message test or a draft. (This could be accomplished, for example, by transmitting a
path continuity test, which indicates that path connectivity is control message along the same links and nodes as the data traffic or
lost. similarly could be measured by the absence of traffic and by
providing feedback.)
Path Degraded (PD) 2.3.2 Failure Terminology
Path degraded is a fault detected by MPLS-based recovery mechanisms
that indicates that the quality of the path is unacceptable.
Link Failure (LF) Path Failure (PF)
A lower layer fault indicating that link continuity is lost. This Path failure is fault detected by MPLS-based recovery mechanisms,
may be communicated to the MPLS-based recovery mechanisms by the which is define as the failure of the liveness message test or a path
lower layer. continuity test, which indicates that path connectivity is lost.
Link Degraded (LD) Path Degraded (PD)
A lower layer indication to MPLS-based recovery mechanisms that the Path degraded is a fault detected by MPLS-based recovery mechanisms
link is performing below an acceptable level. that indicates that the quality of the path is unacceptable.
Fault Indication Signal (FIS) Link Failure (LF)
A signal that indicates that a fault along a path has occurred. It A lower layer fault indicating that link continuity is lost. This may
is relayed by each intermediate LSR to its upstream or downstream be communicated to the MPLS-based recovery mechanisms by the lower
neighbor, until it reaches an LSR that is setup to perform MPLS layer.
recovery.
Fault Recovery Signal (FRS) Link Degraded (LD)
A signal that indicates a fault along a working path has been A lower layer indication to MPLS-based recovery mechanisms that the
repaired. Again, like the FIS, it is relayed by each intermediate link is performing below an acceptable level.
LSR to its upstream or downstream neighbor, until is reaches the
LSR that performs recovery of the original path.
2.4 Abbreviations Fault Indication Signal (FIS)
A signal that indicates that a fault along a path has occurred. It is
relayed by each intermediate LSR to its upstream or downstream
neighbor, until it reaches an LSR that is setup to perform MPLS
recovery.
FIS: Fault Indication Signal. Fault Recovery Signal (FRS)
FRS: Fault Recovery Signal. A signal that indicates a fault along a working path has been
LD: Link Degraded. repaired. Again, like the FIS, it is relayed by each intermediate LSR
LF: Link Failure. to its upstream or downstream neighbor, until is reaches the LSR that
PD: Path Degraded. performs recovery of the original path.
PF: Path Failure.
PML: Path Merge LSR.
PG: Path Group.
PPG: Protected Path Group.
PTP: Protected Traffic Portion.
PSL: Path Switch LSR.
3.0 MPLS-based Recovery Principles 2.4 Abbreviations
MPLS-based recovery refers to the ability to effect quick and FIS: Fault Indication Signal.
complete restoration of traffic affected by a fault in an MPLS- FRS: Fault Recovery Signal.
enabled network. The fault may be detected on the IP layer or in LD: Link Degraded.
lower layers over which IP traffic is transported. Fast MPLS LF: Link Failure.
protection may be viewed as the MPLS LSR switch completion time PD: Path Degraded.
that is comparable to, or equivalent to, the 50 ms switch-over PF: Path Failure.
completion time of the SONET layer. This section provides a PML: Path Merge LSR.
discussion of the concepts and principles of MPLS-based recovery.
The concepts are presented in terms of atomic or primitive terms
that may be combined to specify recovery approaches. We do not
make any assumptions about the underlying layer 1 or layer 2
transport mechanisms or their recovery mechanisms.
3.1 Configuration of Recovery PG: Path Group.
PPG: Protected Path Group.
PTP: Protected Traffic Portion.
PSL: Path Switch LSR.
An LSR should allow for configuration of the following recovery 3.0 MPLS-based Recovery Principles
options:
Default-recovery (No MPLS-based recovery enabled): MPLS-based recovery refers to the ability to effect quick and
Traffic on the working path is recovered only via Layer 3 or IP complete restoration of traffic affected by a fault in an MPLS-
rerouting. This is equivalent to having no MPLS-based recovery. enabled network. The fault may be detected on the IP layer or in
This option may be used for low priority traffic or for traffic lower layers over which IP traffic is transported. Fastest MPLS
that is recovered in another way (for example load shared traffic recovery is assumed to be achieved with protection switching and may
on parallel working paths may be automatically recovered upon a be viewed as the MPLS LSR switch completion time that is comparable
fault along one of the working paths by distributing it among the to, or equivalent to, the 50 ms switch-over completion time of the
remaining working paths). SONET layer. This section provides a discussion of the concepts and
principles of MPLS-based recovery. The concepts are presented in
terms of atomic or primitive terms that may be combined to specify
recovery approaches. We do not make any assumptions about the
underlying layer 1 or layer 2 transport mechanisms or their recovery
mechanisms.
Recoverable (MPLS-based recovery enabled): 3.1 Configuration of Recovery
This working path is recovered using one or more recovery paths,
either via rerouting or via protection switching.
3.2 Initiation of Path Setup An LSR should allow for configuration of the following recovery
options:
As explained in Section 2.2, there are two options for the Default-recovery (No MPLS-based recovery enabled):
initiation of the recovery path setup. Traffic on the working path is recovered only via Layer 3 or IP
rerouting or by some lower layer mechanism such as SONET APS. This
is equivalent to having no MPLS-based recovery. This option may be
used for low priority traffic or for traffic that is recovered in
another way (for example load shared traffic on parallel working
paths may be automatically recovered upon a fault along one of the
working paths by distributing it among the remaining working paths).
Pre-established: Recoverable (MPLS-based recovery enabled):
This working path is recovered using one or more recovery paths,
either via rerouting or via protection switching.
This is the same as the protection switching option. Here a 3.2 Initiation of Path Setup
recovery path(s) is established prior to any failure on the working
path. The path selection can either be determined by an
administrative centralized tool (online or offline), or chosen
based on some algorithm implemented at the PSL and possibly
intermediate nodes. To guard against the situation when the pre-
established recovery path fails before or at the same time as the
working path, the recovery path should have secondary configuration
options as explained in Section 3.3 below.
Pre Qualified: There are three options for the initiation of the recovery path
setup.
A pre-established path need not be created, it may be pre- Pre-established:
qualified. A pre-qualified recovery path is not created expressly
for protecting the working path, but instead is a path created for
other purposes that is designated as a recovery path after
determination that it is an acceptable alternative for carrying the
working path traffic. Variants include the case where an optical
path or trail is configured, but no switches are set.
Established-on-Demand: This is the same as the protection switching option. Here a recovery
path(s) is established prior to any failure on the working path. The
path selection can either be determined by an administrative
centralized tool (online or offline), or chosen based on some
algorithm implemented at the PSL and possibly intermediate nodes. To
guard against the situation when the pre-established recovery path
fails before or at the same time as the working path, the recovery
path should have secondary configuration options as explained in
Section 3.3 below.
This is the same as the rerouting option. Here, a recovery path is Pre Qualified:
established after a failure on its working path has been detected
and notified to the PSL.
3.3 Initiation of Resource Allocation A pre-established path need not be created, it may be pre-qualified.
A recovery path may support the same traffic contract as the A pre-qualified recovery path is not created expressly for protecting
working path, or it may not. We will distinguish these two the working path, but instead is a path created for other purposes
situations by using different additive terms. If the recovery path that is designated as a recovery path after determination that it is
is capable of replacing the working path without degrading service, an acceptable alternative for carrying the working path traffic.
it will be called an equivalent recovery path. If the recovery path Variants include the case where an optical path or trail is
lacks the resources (or resource reservations) to replace the configured, but no switches are set.
working path without degrading service, it will be called a limited
recovery path. Based on this, there are two options for the
initiation of resource allocation:
Pre-reserved: Established-on-Demand:
This option applies only to protection switching. Here a pre- This is the same as the rerouting option. Here, a recovery path is
established recovery path reserves required resources on all hops established after a failure on its working path has been detected and
along its route during its establishment. Although the reserved notified to the PSL.
resources (e.g., bandwidth and/or buffers) at each node cannot be
used to admit more working paths, they are available to be used by
all traffic that is present at the node before a failure occurs.
Reserved-on-Demand: 3.3 Initiation of Resource Allocation
This option may apply either to rerouting or to protection A recovery path may support the same traffic contract as the working
switching. Here a recovery path reserves the required resources path, or it may not. We will distinguish these two situations by
after a failure on the working path has been detected and notified using different additive terms. If the recovery path is capable of
to the PSL and before the traffic on the working path is switched replacing the working path without degrading service, it will be
over to the recovery path. called an equivalent recovery path. If the recovery path lacks the
resources (or resource reservations) to replace the working path
without degrading service, it will be called a limited recovery path.
Based on this, there are two options for the initiation of resource
allocation:
Note that under both the options above, depending on the amount of Pre-reserved:
resources reserved on the recovery path, it could either be an
equivalent recovery path or a limited recovery path.
3.4 Scope of Recovery This option applies only to protection switching. Here a pre-
established recovery path reserves required resources on all hops
along its route during its establishment. Although the reserved
resources (e.g., bandwidth and/or buffers) at each node cannot be
used to admit more working paths, they are available to be used by
all traffic that is present at the node before a failure occurs.
3.4.1 Topology Reserved-on-Demand:
3.4.1.1 Local Repair This option may apply either to rerouting or to protection switching.
Here a recovery path reserves the required resources after a failure
on the working path has been detected and notified to the PSL and
before the traffic on the working path is switched over to the
recovery path.
The intent of local repair is to protect against a single link or Note that under both the options above, depending on the amount of
neighbor node fault. In local repair (also known as local recovery resources reserved on the recovery path, it could either be an
[12] [9]), the node immediately upstream of the fault is the one to equivalent recovery path or a limited recovery path.
initiate recovery (either rerouting or protection switching). Local
repair can be of two types:
Link Recovery/Restoration 3.4 Scope of Recovery
In this case, the recovery path may be configured to route around a 3.4.1 Topology
certain link deemed to be unreliable. If protection switching is
used, several recovery paths may be configured for one working
path, depending on the specific faulty link that each protects
against.
Alternatively, if rerouting is used, upon the occurrence of a fault 3.4.1.1 Local Repair
on the specified link each path is rebuilt such that it detours
around the faulty link.
In this case, the recovery path need only be disjoint from its The intent of local repair is to protect against a link or neighbor
working path at a particular link on the working path, and may have node fault and to minimize the amount of time required for failure
overlapping segments with the working path. Traffic on the working propagation. In local repair (also known as local recovery [12] [9]),
path is switched over to an alternate path at the upstream LSR that the node immediately upstream of the fault is the one to initiate
connects to the failed link. This method is potentially the fastest recovery (either rerouting or protection switching). Local repair can
to perform the switchover, and can be effective in situations where be of two types:
certain path components are much more unreliable than others.
Node Recovery/Restoration Link Recovery/Restoration
In this case, the recovery path may be configured to route around a In this case, the recovery path may be configured to route around a
neighbor node deemed to be unreliable. Thus the recovery path is certain link deemed to be unreliable. If protection switching is
disjoint from the working path only at a particular node and at used, several recovery paths may be configured for one working path,
links associated with the working path at that node. Once again, depending on the specific faulty link that each protects against.
the traffic on the primary path is switched over to the recovery
path at the upstream LSR that directly connects to the failed node,
and the recovery path shares overlapping portions with the working
path.
3.4.1.2 Global Repair Alternatively, if rerouting is used, upon the occurrence of a fault
on the specified link each path is rebuilt such that it detours
around the faulty link.
In this case, the recovery path need only be disjoint from its
working path at a particular link on the working path, and may have
overlapping segments with the working path. Traffic on the working
path is switched over to an alternate path at the upstream LSR that
connects to the failed link. This method is potentially the fastest
to perform the switchover, and can be effective in situations where
certain path components are much more unreliable than others.
The intent of global repair is to protect against any link or node Node Recovery/Restoration
fault on a label switched path or on a segment of a label switched
path, with the obvious exception of the faults occurring at the
ingress node. In global repair (also known as path
recovery/restoration) the node that initiates the recovery is the
ingress to the label switched path and so may be distant from the
faulty link or node. In some cases, a fault notification (in the
form of a FIS) must be sent from the node detecting the fault to
the PSL. In many cases, the recovery path can be made completely
link and node disjoint with its working path. This has the
advantage of protecting against all link and node fault(s) on the
working path (or path segment), and being more efficient than per-
hop link or node recovery.
In addition, it can be potentially more optimal in resource usage
than the link or node recovery. However, it is in some cases slower
than local repair since it takes longer for the fault notification
message to get to the PSL to trigger the recovery action.
3.4.1.3 Alternate Egress Repair In this case, the recovery path may be configured to route around a
neighbor node deemed to be unreliable. Thus the recovery path is
disjoint from the working path only at a particular node and at links
associated with the working path at that node. Once again, the
traffic on the primary path is switched over to the recovery path at
the upstream LSR that directly connects to the failed node, and the
recovery path shares overlapping portions with the working path.
It is possible to restore service without specifically recovering 3.4.1.2 Global Repair
the faulted path.
For example, for best effort IP service it is possible to select a
recovery path that has a different egress point from the working
path (i.e., there is no PML). The recovery path egress must simply
be a router that is acceptable for forwarding the FEC carried by
the working path (without creating looping). In an engineering
context, specific alternative FEC/LSP mappings with alternate
egresses can be formed.
This may simplify enhancing the reliability of implicitly The intent of global repair is to protect against any link or node
constructed MPLS topologies. A PSL may qualify LSP/FEC bindings as fault on a path or on a segment of a path, with the obvious exception
candidate recovery paths as simply link and node disjoint with the of the faults occurring at the ingress node of the protected path
immediate downstream LSR of the working path. segment. In global repair the PSL is usually distant from the failure
and needs to be notified by a FIS.
In global repair also end-to end path recovery/restoration applies.
In many cases, the recovery path can be made completely link and node
disjoint with its working path. This has the advantage of protecting
against all link and node fault(s) on the working path (end-to-end
path or path segment).
3.4.1.4 Multi-Layer Repair However, it is in some cases slower than local repair since it takes
longer for the fault notification message to get to the PSL to
trigger the recovery action.
Multi-layer repair broadens the network designerĘs tool set for 3.4.1.3 Alternate Egress Repair
those cases where multiple network layers can be managed together
to achieve overall network goals. Specific criteria for
determining when multi-layer repair is appropriate are beyond the
scope of this draft.
3.4.1.5 Concatenated Protection Domains It is possible to restore service without specifically recovering the
faulted path.
For example, for best effort IP service it is possible to select a
recovery path that has a different egress point from the working path
(i.e., there is no PML). The recovery path egress must simply be a
router that is acceptable for forwarding the FEC carried by the
working path (without creating looping). In an engineering context,
specific alternative FEC/LSP mappings with alternate egresses can be
formed.
A given service may cross multiple networks and these may employ This may simplify enhancing the reliability of implicitly constructed
different recovery mechanisms. It is possible to concatenate MPLS topologies. A PSL may qualify LSP/FEC bindings as candidate
protection domains so that service recovery can be provided end-to- recovery paths as simply link and node disjoint with the immediate
end. It is considered that the recovery mechanisms in different downstream LSR of the working path.
domains may operate autonomously, and that multiple points of
attachment may be used between domains (to ensure there is no
single point of failure). Alternate egress repair requires
management of concatenated domains in that an explicit MPLS point
of failure (the PML) is by definition excluded. Details of
concatenated protection domains are beyond the scope of this draft.
3.4.2 Path Mapping 3.4.1.4 Multi-Layer Repair
Path mapping refers to the methods of mapping traffic from a faulty Multi-layer repair broadens the network designer's tool set for those
working path on to the recovery path. There are several options for cases where multiple network layers can be managed together to
this, as described below. Note that the options below should be achieve overall network goals. Specific criteria for determining
viewed as atomic terms that only describe how the working and when multi-layer repair is appropriate are beyond the scope of this
protection paths are mapped to each other. The issues of resource draft.
reservation along these paths, and how switchover is actually
performed lead to the more commonly used composite terms, such as
1+1 and 1:1 protection, which were described in Section 2.1.
1-to-1 Protection 3.4.1.5 Concatenated Protection Domains
In 1-to-1 protection the working path has a designated recovery A given service may cross multiple networks and these may employ
path that is only to be used to recover that specific working path. different recovery mechanisms. It is possible to concatenate
protection domains so that service recovery can be provided end-to-
end. It is considered that the recovery mechanisms in different
domains may operate autonomously, and that multiple points of
attachment may be used between domains (to ensure there is no single
point of failure). Alternate egress repair requires management of
concatenated domains in that an explicit MPLS point of failure (the
PML) is by definition excluded. Details of concatenated protection
domains are beyond the scope of this draft.
ii) n-to-1 Protection 3.4.2 Path Mapping
In n-to-1 protection, up to n working paths are protected using Path mapping refers to the methods of mapping traffic from a faulty
only one recovery path. If the intent is to protect against any working path on to the recovery path. There are several options for
single fault on any of the working paths, the n working paths this, as described below. Note that the options below should be
should be diversely routed between the same PSL and PML. In some viewed as atomic terms that only describe how the working and
cases, handshaking between PSL and PML may be required to complete protection paths are mapped to each other. The issues of resource
the recovery, the details of which are beyond the scope of this reservation along these paths, and how switchover is actually
draft. performed lead to the more commonly used composite terms, such as 1+1
and 1:1 protection, which were described in Section 2.1.
n-to-m Protection 1-to-1 Protection
In n-to-m protection, up to n working paths are protected using m In 1-to-1 protection the working path has a designated recovery path
recovery paths. Once again, if the intent is to protect against any that is only to be used to recover that specific working path.
single fault on any of the n working paths, the n working paths and
the m recovery paths should be diversely routed between the same
PSL and PML. In some cases, handshaking between PSL and PML may be
required to complete the recovery, the details of which are beyond
the scope of this draft. N-to-m protection is for further study.
Split Path Protection ii) n-to-1 Protection
In split path protection, multiple recovery paths are allowed to In n-to-1 protection, up to n working paths are protected using only
carry the traffic of a working path based on a certain configurable one recovery path. If the intent is to protect against any single
load splitting ratio. This is especially useful when no single fault on any of the working paths, the n working paths should be
recovery path can be found that can carry the entire traffic of the diversely routed between the same PSL and PML. In some cases,
working path in case of a fault. Split path protection may require handshaking between PSL and PML may be required to complete the
handshaking between the PSL and the PML(s), and may require the recovery, the details of which are beyond the scope of this draft.
PML(s) to correlate the traffic arriving on multiple recovery paths
with the working path. Although this is an attractive option, the
details of split path protection are beyond the scope of this
draft, and are for further study.
3.4.3 Bypass Tunnels n-to-m Protection
It may be convenient, in some cases, to create a "bypass tunnel" In n-to-m protection, up to n working paths are protected using m
for a PPG between a PSL and PML, thereby allowing multiple recovery recovery paths. Once again, if the intent is to protect against any
paths to be transparent to intervening LSRs [Error! Bookmark not single fault on any of the n working paths, the n working paths and
defined.]. In this case, one LSP (the tunnel) is established the m recovery paths should be diversely routed between the same PSL
between the PSL and PML following an acceptable route and a number and PML. In some cases, handshaking between PSL and PML may be
of recovery paths are supported through the tunnel via label required to complete the recovery, the details of which are beyond
stacking. A bypass tunnel can be used with any of the path mapping the scope of this draft. N-to-m protection is for further study.
options discussed in the previous section.
As with recovery paths, the bypass tunnel may or may not have Split Path Protection
resource reservations sufficient to provide recovery without
service degradation. It is possible that the bypass tunnel may
have sufficient resources to recover some number of working paths,
but not all at the same time. If the number of recovery paths
carrying traffic in the tunnel at any given time is restricted,
this is similar to the 1 to n or m to n protection cases mentioned
in Section 3.4.2.
3.4.4 Recovery Granularity In split path protection, multiple recovery paths are allowed to
carry the traffic of a working path based on a certain configurable
load splitting ratio. This is especially useful when no single
recovery path can be found that can carry the entire traffic of the
working path in case of a fault. Split path protection may require
handshaking between the PSL and the PML(s), and may require the
PML(s) to correlate the traffic arriving on multiple recovery paths
with the working path. Although this is an attractive option, the
details of split path protection are beyond the scope of this draft,
and are for further study.
Another dimension of recovery considers the amount of traffic 3.4.3 Bypass Tunnels
requiring protection. This may range from a fraction of a path to a
bundle of paths.
3.4.4.1 Selective Traffic Recovery It may be convenient, in some cases, to create a "bypass tunnel" for
a PPG between a PSL and PML, thereby allowing multiple recovery paths
to be transparent to intervening LSRs [8]. In this case, one LSP
(the tunnel) is established between the PSL and PML following an
acceptable route and a number of recovery paths are supported through
the tunnel via label stacking. A bypass tunnel can be used with any
of the path mapping options discussed in the previous section.
This option allows for the protection of a fraction of traffic As with recovery paths, the bypass tunnel may or may not have
within the same path. The portion of the traffic on an individual resource reservations sufficient to provide recovery without service
path that requires protection is called a protected traffic portion degradation. It is possible that the bypass tunnel may have
(PTP). A single path may carry different classes of traffic, with sufficient resources to recover some number of working paths, but not
different protection requirements. The protected portion of this all at the same time. If the number of recovery paths carrying
traffic may be identified by its class, as for example, via the EXP traffic in the tunnel at any given time is restricted, this is
bits in the MPLS shim header or via the priority bit in the ATM similar to the 1 to n or m to n protection cases mentioned in Section
header. 3.4.2.
3.4.4.2 Bundling 3.4.4 Recovery Granularity
Bundling is a technique used to group multiple working paths
together in order to recover them simultaneously. The logical
bundling of multiple working paths requiring protection, each of
which is routed identically between a PSL and a PML, is called a
protected path group (PPG). When a fault occurs on the working path
carrying the PPG, the PPG as a whole can be protected either by
being switched to a bypass tunnel or by being switched to a
recovery path.
3.4.5 Recovery Path Resource Use Another dimension of recovery considers the amount of traffic
requiring protection. This may range from a fraction of a path to a
bundle of paths.
In the case of pre-reserved recovery paths, there is the question 3.4.4.1 Selective Traffic Recovery
of what use these resources may be put to when the recovery path is
not in use. There are two options:
Dedicated-resource: This option allows for the protection of a fraction of traffic within
If the recovery path resources are dedicated, they may not be used the same path. The portion of the traffic on an individual path that
for anything except carrying the working traffic. For example, in requires protection is called a protected traffic portion (PTP). A
the case of 1+1 protection, the working traffic is always carried single path may carry different classes of traffic, with different
on the recovery path. Even if the recovery path is not always protection requirements. The protected portion of this traffic may be
carrying the working traffic, it may not be possible or desirable identified by its class, as for example, via the EXP bits in the MPLS
to allow other traffic to use these resources. shim header or via the priority bit in the ATM header.
Extra-traffic-allowed: 3.4.4.2 Bundling
If the recovery path only carries the working traffic when the
working path fails, then it is possible to allow extra traffic to
use the reserved resources at other times. Extra traffic is, by
definition, traffic that can be displaced (without violating
service agreements) whenever the recovery path resources are needed
for carrying the working path traffic.
3.5 Fault Detection Bundling is a technique used to group multiple working paths together
in order to recover them simultaneously. The logical bundling of
multiple working paths requiring protection, each of which is routed
identically between a PSL and a PML, is called a protected path group
(PPG). When a fault occurs on the working path carrying the PPG, the
PPG as a whole can be protected either by being switched to a bypass
tunnel or by being switched to a recovery path.
MPLS recovery is initiated after the detection of either a lower 3.4.5 Recovery Path Resource Use
layer fault or a fault at the IP layer or in the operation of MPLS-
based mechanisms. We consider four classes of impairments: Path
Failure, Path Degraded, Link Failure, and Link Degraded.
Path Failure (PF) is a fault that indicates to an MPLS-based In the case of pre-reserved recovery paths, there is the question of
recovery scheme that the connectivity of the path is lost. This what use these resources may be put to when the recovery path is not
may be detected by a path continuity test between the PSL and PML. in use. There are two options:
Some, and perhaps the most common, path failures may be detected
using a link probing mechanism between neighbor LSRs. An example of
a probing mechanism is a liveness message that is exchanged
periodically along the working path between peer LSRs. For either
a link probing mechanism or path continuity test to be effective,
the test message must be guaranteed to follow the same route as the
working or recovery path, over the segment being tested. In
addition, the path continuity test must take the path merge points
into consideration. In the case of a bi-directional link
implemented as two unidirectional links, path failure could mean
that either one or both unidirectional links are damaged.
Path Degraded (PD) is a fault that indicates to MPLS-based recovery Dedicated-resource:
schemes/mechanisms that the path has connectivity, but that the If the recovery path resources are dedicated, they may not be used
quality of the connection is unacceptable. This may be detected by for anything except carrying the working traffic. For example, in
a path performance monitoring mechanism, or some other mechanism the case of 1+1 protection, the working traffic is always carried on
for determining the error rate on the path or some portion of the the recovery path. Even if the recovery path is not always carrying
path. This is local to the LSR and consists of excessive discarding the working traffic, it may not be possible or desirable to allow
of packets at an interface, either due to label mismatch or due to other traffic to use these resources.
TTL errors, for example.
Link Failure (LF) is an indication from a lower layer that the link Extra-traffic-allowed:
over which the path is carried has failed. If the lower layer If the recovery path only carries the working traffic when the
supports detection and reporting of this fault (that is, any fault working path fails, then it is possible to allow extra traffic to use
that indicates link failure e.g., SONET LOS), this may be used by the reserved resources at other times. Extra traffic is, by
the MPLS recovery mechanism. In some cases, using LF indications definition, traffic that can be displaced (without violating service
may provide faster fault detection than using only MPLS-based fault agreements) whenever the recovery path resources are needed for
detection mechanisms. carrying the working path traffic.
Link Degraded (LD) is an indication from a lower layer that the 3.5 Fault Detection
link over which the path is carried is performing below an MPLS recovery is initiated after the detection of either a lower
acceptable level. If the lower layer supports detection and layer fault or a fault at the IP layer or in the operation of MPLS-
reporting of this fault, it may be used by the MPLS recovery based mechanisms. We consider four classes of impairments: Path
mechanism. In some cases, using LD indications may provide faster Failure, Path Degraded, Link Failure, and Link Degraded.
fault detection than using only MPLS-based fault detection
mechanisms.
3.6 Fault Notification Path Failure (PF) is a fault that indicates to an MPLS-based recovery
scheme that the connectivity of the path is lost. This may be
detected by a path continuity test between the PSL and PML. Some,
and perhaps the most common, path failures may be detected using a
link probing mechanism between neighbor LSRs. An example of a probing
mechanism is a liveness message that is exchanged periodically along
the working path between peer LSRs. For either a link probing
mechanism or path continuity test to be effective, the test message
must be guaranteed to follow the same route as the working or
recovery path, over the segment being tested. In addition, the path
continuity test must take the path merge points into consideration.
In the case of a bi-directional link implemented as two
unidirectional links, path failure could mean that either one or both
unidirectional links are damaged.
Protection switching relies on rapid and reliable notification of Path Degraded (PD) is a fault that indicates to MPLS-based recovery
faults. Once a fault is detected, the node that detected the fault schemes/mechanisms that the path has connectivity, but that the
must determine if the fault is severe enough to require path quality of the connection is unacceptable. This may be detected by a
recovery. Then the node should send out a notification of the fault path performance monitoring mechanism, or some other mechanism for
by transmitting a FIS to those of its upstream LSRs that were determining the error rate on the path or some portion of the path.
sending traffic on the working path that is affected by the fault. This is local to the LSR and consists of excessive discarding of
This notification is relayed hop-by-hop by each subsequent LSR to packets at an interface, either due to label mismatch or due to TTL
its upstream neighbor, until it eventually reaches a PSL. A PSL is errors, for example.
the only LSR that can terminate the FIS and initiate a protection
switch of the working path to a recovery path.
Since the FIS is a control message, it should be transmitted with Link Failure (LF) is an indication from a lower layer that the link
high priority to ensure that it propagates rapidly towards the over which the path is carried has failed. If the lower layer
affected PSL(s). Depending on how fault notification is configured supports detection and reporting of this fault (that is, any fault
in the LSRs of an MPLS domain, the FIS could be sent either as a that indicates link failure e.g., SONET LOS), this may be used by the
Layer 2 or Layer 3 packet. An example of a FIS could be the MPLS recovery mechanism. In some cases, using LF indications may
liveness message sent by a downstream LSR to its upstream neighbor, provide faster fault detection than using only MPLS_based fault
with an optional fault notification field set. Alternatively, it detection mechanisms.
could be a separate fault notification packet. The intermediate LSR
should identify which of its incoming links (upstream LSRs) to
propagate the FIS on. In the case of 1+1 protection, the FIS should
also be sent downstream to the PML where the recovery action is
taken.
3.7 Switch-Over Operation Link Degraded (LD) is an indication from a lower layer that the link
over which the path is carried is performing below an acceptable
level. If the lower layer supports detection and reporting of this
fault, it may be used by the MPLS recovery mechanism. In some cases,
using LD indications may provide faster fault detection than using
only MPLS-based fault detection mechanisms.
3.7.1 Recovery Trigger 3.6 Fault Notification
The activation of an MPLS protection switch following the detection MPLS-based recovery relies on rapid and reliable notification of
or notification of a fault requires a trigger mechanism at the PSL. faults. Once a fault is detected, the node that detected the fault
must determine if the fault is severe enough to require path
recovery. If the node is not capable of initiating direct action
(e.g. as a PSL) the node should send out a notification of the fault
by transmitting a FIS to those of its upstream LSRs that were sending
traffic on the working path that is affected by the fault. This
notification is relayed hop-by-hop by each subsequent LSR to its
upstream neighbor, until it eventually reaches a PSL. A PSL is the
only LSR that can terminate the FIS and initiate a protection switch
of the working path to a recovery path.
MPLS protection switching may be initiated due to automatic inputs Since the FIS is a control message, it should be transmitted with
or external commands. The automatic activation of an MPLS high priority to ensure that it propagates rapidly towards the
protection switch results from a response to a defect or fault affected PSL(s). Depending on how fault notification is configured in
conditions detected at the PSL or to fault notifications received the LSRs of an MPLS domain, the FIS could be sent either as a Layer 2
at the PSL. It is possible that the fault detection and trigger or Layer 3 packet [13]. The use of a Layer 2-based notification
mechanisms may be combined, as is the case when a PF, PD, LF, or LD requires a Layer 2 path direct to the PSL. An example of a FIS could
is detected at a PSL and triggers a protection switch to the be the liveness message sent by a downstream LSR to its upstream
recovery path. In most cases, however, the detection and trigger neighbor, with an optional fault notification field set or it can be
mechanisms are distinct, involving the detection of fault at some implicitly denoted by a teardown message. Alternatively, it could be
intermediate LSR followed by the propagation of a fault a separate fault notification packet. The intermediate LSR should
notification back to the PSL via the FIS, which serves as the identify which of its incoming links (upstream LSRs) to propagate the
protection switch trigger at the PSL. MPLS protection switching in FIS on. In the case of 1+1 protection, the FIS should also be sent
response to external commands results when the operator initiates a downstream to the PML where the recovery action is taken.
protection switch by a command to a PSL (or alternatively by a
configuration command to an intermediate LSR, which transmits the
FIS towards the PSL).
Note that the PF fault applies to hard failures (fiber cuts, 3.7 Switch-Over Operation
transmitter failures, or LSR fabric failures), as does the LF
fault, with the difference that the LF is a lower layer impairment
that may be communicated to - MPLS-based recovery mechanisms. The
PD (or LD) fault, on the other hand, applies to soft defects
(excessive errors due to noise on the link, for instance). The PD
(or LD) results in a fault declaration only when the percentage of
lost packets exceeds a given threshold, which is provisioned and
may be set based on the service level agreement(s) in effect
between a service provider and a customer.
3.7.2 Recovery Action 3.7.1 Recovery Trigger
After a fault is detected or FIS is received by the PSL, the The activation of an MPLS protection switch following the detection
recovery action involves either a rerouting or protection switching or notification of a fault requires a trigger mechanism at the PSL.
operation. In both scenarios, the next hop label forwarding entry MPLS protection switching may be initiated due to automatic inputs or
for a recovery path is bound to the working path. external commands. The automatic activation of an MPLS protection
switch results from a response to a defect or fault conditions
detected at the PSL or to fault notifications received at the PSL. It
is possible that the fault detection and trigger mechanisms may be
combined, as is the case when a PF, PD, LF, or LD is detected at a
PSL and triggers a protection switch to the recovery path. In most
cases, however, the detection and trigger mechanisms are distinct,
involving the detection of fault at some intermediate LSR followed by
the propagation of a fault notification back to the PSL via the FIS,
which serves as the protection switch trigger at the PSL. MPLS
protection switching in response to external commands results when
the operator initiates a protection switch by a command to a PSL (or
alternatively by a configuration command to an intermediate LSR,
which transmits the FIS towards the PSL).
3.8 Switch-Back Operation Note that the PF fault applies to hard failures (fiber cuts,
transmitter failures, or LSR fabric failures), as does the LF fault,
with the difference that the LF is a lower layer impairment that may
be communicated to - MPLS-based recovery mechanisms. The PD (or LD)
fault, on the other hand, applies to soft defects (excessive errors
due to noise on the link, for instance). The PD (or LD) results in a
fault declaration only when the percentage of lost packets exceeds a
given threshold, which is provisioned and may be set based on the
service level agreement(s) in effect between a service provider and a
customer.
3.8.1 Revertive and Non-Revertive Modes 3.7.2 Recovery Action
After a fault is detected or FIS is received by the PSL, the recovery
action involves either a rerouting or protection switching operation.
In both scenarios, the next hop label forwarding entry for a recovery
path is bound to the working path.
These protection modes indicate whether or not there is a preferred 3.8 Switch-Back Operation
path for the protected traffic.
3.8.1.1 Revertive Mode When traffic is flowing on the recovery path decisions can be made to
whether let the traffic remain on the recovery path and consider it
as a new working path or do a switch to the old or a new working
path. This switch-back operation has two styles, one where the
protection counterparts, i.e. the working and recovery path, are
fixed or "pinned" to its route and one in which the PSL or other
network entity with real time knowledge of failure dynamically
performs re-establishment or controlled rearrangement of the paths
comprising the protected service.
If the working path always is the preferred path, this path will be 3.8.1 Fixed Protection Counterparts
used whenever it is available. If the working path has a fault,
traffic is switched to the recovery path. In the revertive mode of
operation, when the preferred path is restored the traffic is
automatically switched back to it.
3.8.1.2 Non-revertive Mode For fixed protection counterparts the PSL will be pre-configured with
the appropriate behavior to take when the original fixed path is
restored to service. The choices are revertive and non-revertive
mode. The choice will typically be depended on relative costs of the
working and protection paths, and the tolerance of the service to the
effects of switching paths yet again. These protection modes indicate
whether or not there is a preferred path for the protected traffic.
In the non-revertive mode of operation, there is no preferred path. 3.8.1.1 Revertive Mode
A switchback to the "original" working path is not desired or not
possible since the original path may no longer exist after the
occurrence of a fault on that path.
If there is a fault on the working path, traffic is switched to the If the working path always is the preferred path, this path will be
recovery path. When or if the faulty path (the originally working used whenever it is available. Thus, in the event of a fault on this
path) is restored, it may become the recovery path (either by path, its unused resources will not be reclaimed by the network on
configuration, or, if desired, by management actions). This applies failure. If the working path has a fault, traffic is switched to the
for explicitly routed working paths. recovery path. In the revertive mode of operation, when the
preferred path is restored the traffic is automatically switched back
to it.
When the traffic is switched over to a recovery path, the There are a number of implications to pinned working and recovery
association between the original working path and the recovery path paths:
may no longer exist, since the original path itself may no longer - upon failure and traffic moved to recovery path, the traffic is
exist after the fault. Instead, when the network reaches a stable unprotected until such time as the path defect in the original
state following routing convergence, the recovery path may be working path is repaired and that path restored to service.
switched over to a different preferred path based either on pre- - upon failure and traffic moved to recovery path, the resources
configured information or optimization based on the new network associated with the original path remain reserved.
topology and associated information.
3.8.2 Restoration and Notification 3.8.1.2 Non-revertive Mode
MPLS restoration deals with returning the working traffic from the In the non-revertive mode of operation, there is no preferred path or
recovery path to the original or a new working path. Reversion is it may be desirable to minimize further disruption of the service
performed by the PSL upon receiving notification, via FRS, that the brought on by a revertive switching operation. A switch-back to the
working path is repaired or upon receiving notification that a new original working path is not desired or not possible since the
working path is established. original path may no longer exist after the occurrence of a fault on
that path.
If there is a fault on the working path, traffic is switched to the
recovery path. When or if the faulty path (the originally working
path) is restored, it may become the recovery path (either by
configuration, or, if desired, by management actions).
As before, an LSR that detected the fault on the working path also In the non-revertive mode of operation, the working traffic may or
detects the restoration of the working path. If the working path may not be restored to a new optimal working path or to the original
had experienced a LF defect, the LSR detects a return to normal working path anyway. This is because it might be useful, in some
operation via the receipt of a liveness message from its peer. If cases, to either: (a) administratively perform a protection switch
the working path had experienced a LD defect at an LSR interface, back to the original working path after gaining further assurances
the LSR could detect a return to normal operation via the about the integrity of the path, or (b) it may be acceptable to
resumption of error-free packet reception on that interface. continue operation on the recovery path, or (c) it may be desirable
Alternatively, a lower layer that no longer detects a LF defect may to move the traffic to a new optimal working path that is calculated
inform the MPLS-based recovery mechanisms at the LSR that the link based on network topology and network policies.
to its peer LSR is operational.
The LSR then transmits FRS to its upstream LSR(s) that were 3.8.2 Dynamic Protection Counterparts
transmitting traffic on the working path. This is relayed hop-by-
hop until it reaches the PSL(s), at which point the PSL switches
the working traffic back to the original working path.
In the non-revertive mode of operation, the working traffic may or For Dynamic protection counterparts when the traffic is switched over
may not be restored to the original working path. This is because to a recovery path, the association between the original working path
it might be useful, in some cases, to either: (a) administratively and the recovery path may no longer exist, since the original path
perform a protection switch back to the original working path after itself may no longer exist after the fault. Instead, when the network
gaining further assurances about the integrity of the path, or (b) reaches a stable state following routing convergence, the recovery
it may be acceptable to continue operation without the recovery path may be switched over to a different preferred path either
path being protected, or (c) it may be desirable to move the optimization based on the new network topology and associated
traffic to a new working path that is calculated based on network information or based on pre-configured information.
topology and network policies, after the dynamic routing protocols
have converged.
We note that if there is a way to transmit fault information back
along a recovery path towards a PSL and if the recovery path is an
equivalent recovery path, it is possible for the working path and
its recovery path to exchange roles once the original working path
is repaired following a fault. This is because, in that case, the
recovery path effectively becomes the working path, and the
restored working path functions as a recovery path for the original
recovery path. This is important, since it affords the benefits of
non-revertive switch operation outlined in Section 3.8.1, without
leaving the recovery path unprotected.
3.8.3 Reverting to Preferred Path (or Controlled Rearrangement) Dynamic protection counterparts assume that upon failure, the PSL or
other network entity will establish new working paths if a switch-
back will be performed.
In the revertive mode, a "make before break" restoration switching 3.8.3 Restoration and Notification
can be used, which is less disruptive than performing protection
switching upon the occurrence of network impairments. This will
minimize both packet loss and packet reordering. The controlled
rearrangement of paths can also be used to satisfy traffic
engineering requirements for load balancing across an MPLS domain.
3.9 Performance MPLS restoration deals with returning the working traffic from the
recovery path to the original or a new working path. Reversion is
performed by the PSL either upon receiving notification, via FRS,
that the working path is repaired, or upon receiving notification
that a new working path is established.
Resource/performance requirements for recovery paths should be For fixed counterparts in revertive mode, an LSR that detected the
specified in terms of the following attributes: fault on the working path also detects the restoration of the working
path. If the working path had experienced a LF defect, the LSR
detects a return to normal operation via the receipt of a liveness
message from its peer. If the working path had experienced a LD
defect at an LSR interface, the LSR could detect a return to normal
operation via the resumption of error-free packet reception on that
interface. Alternatively, a lower layer that no longer detects a LF
defect may inform the MPLS-based recovery mechanisms at the LSR that
the link to its peer LSR is operational.
The LSR then transmits FRS to its upstream LSR(s) that were
transmitting traffic on the working path. At the point the PSL
receives the FRS, it switches the working traffic back to the
original working path.
I. Resource class attribute: A similar scheme is for dynamic counterparts where e.g. an update of
Equivalent Recovery Class: The recovery path has the same resource topology and/or network convergence may trigger installation or setup
reservations and performance guarantees as the working path. In of new working paths and send notification to the PSL to perform a
other words, the recovery path meets the same SLAs as the working switch over.
path.
Limited Recovery Class: The recovery path does not have the same
resource reservations and performance guarantees as the working
path.
A. Lower Class: The recovery path has lower resource requirements We note that if there is a way to transmit fault information back
or less stringent performance requirements than the working path. along a recovery path towards a PSL and if the recovery path is an
equivalent working path, it is possible for the working path and its
recovery path to exchange roles once the original working path is
repaired following a fault. This is because, in that case, the
recovery path effectively becomes the working path, and the restored
working path functions as a recovery path for the original recovery
path. This is important, since it affords the benefits of non-
revertive switch operation outlined in Section 3.8.1, without leaving
the recovery path unprotected.
B. Best Effort Class: The recovery path is best effort. 3.8.4 Reverting to Preferred Path (or Controlled Rearrangement)
II. Priority Attribute: In the revertive mode, a "make before break" restoration switching
can be used, which is less disruptive than performing protection
switching upon the occurrence of network impairments. This will
minimize both packet loss and packet reordering. The controlled
rearrangement of paths can also be used to satisfy traffic
engineering requirements for load balancing across an MPLS domain.
The recovery path has a priority attribute just like the working 3.9 Performance
path (i.e., the priority attribute of the associated traffic
trunks). It can have the same priority as the working path or lower
priority.
III. Preemption Attribute: Resource/performance requirements for recovery paths should be
The recovery path can have the same preemption attribute as the specified in terms of the following attributes:
working path or a lower one.
4.0 MPLS Recovery Requirement I. Resource class attribute:
Equivalent Recovery Class: The recovery path has the same resource
reservations and performance guarantees as the working path. In other
words, the recovery path meets the same SLAs as the working path.
Limited Recovery Class: The recovery path does not have the same
resource reservations and performance guarantees as the working path.
The following are the MPLS recovery requirements: A. Lower Class: The recovery path has lower resource requirements or
less stringent performance requirements than the working path.
I. MPLS recovery SHALL provide an option to identify protection B. Best Effort Class: The recovery path is best effort.
groups (PPGs) and protection portions (PTPs).
II. Each PSL SHALL be capable of performing MPLS recovery upon the II. Priority Attribute:
detection of the impairments or upon receipt of notifications of
impairments.
III. A MPLS recovery method SHALL not preclude manual protection The recovery path has a priority attribute just like the working path
switching commands. This implies that it would be possible under (i.e., the priority attribute of the associated traffic trunks). It
administrative commands to transfer traffic from a working path to can have the same priority as the working path or lower priority.
a recovery path, or to transfer traffic from a recovery path to a
working path, once the working path becomes operational following a
fault.
IV. A PSL SHALL be capable of performing either a switch back to III. Preemption Attribute:
the original working path after the fault is corrected or a
switchover to a new working path, upon the discovery of a more
optimal working path.
V. The recovery model should take into consideration path merging The recovery path can have the same preemption attribute as the
at intermediate LSRs. If a fault affects the merged segment, all working path or a lower one.
the paths sharing that merged segment should be able to recover.
Similarly, if a fault affects a non-merged segment, only the path
that is affected by the fault should be recovered.
5.0 MPLS Recovery Options 4.0 MPLS Recovery Requirement
There SHOULD be an option for: The following are the MPLS recovery requirements:
I. Configuration of the recovery path as excess or reserved, with I. MPLS recovery SHALL provide an option to identify protection
excess as the default. The recovery path that is configured as groups (PPGs) and protection portions (PTPs).
excess SHALL provide lower priority preemptable traffic access to
the protection bandwidth, while the recovery path configured as
reserved SHALL not provide any other traffic access to the
protection bandwidth.
II. Each protected path SHALL provide an option for configuring the II. Each PSL SHALL be capable of performing MPLS recovery upon the
protection alternatives as either rerouting or protection detection of the impairments or upon receipt of notifications of
switching. impairments.
III. Each protected path SHALL provide a configuration option for III. A MPLS recovery method SHALL not preclude manual protection
enabling restoration as either non-revertive or revertive, with switching commands. This implies that it would be possible under
revertive as the default. administrative commands to transfer traffic from a working path to a
recovery path, or to transfer traffic from a recovery path to a
working path, once the working path becomes operational following a
fault.
6.0 Comparison Criteria IV. A PSL SHALL be capable of performing either a switch back to the
original working path after the fault is corrected or a switchover to
a new working path, upon the discovery or establishment of a more
optimal working path.
Possible criteria to use for comparison of MPLS-based recovery V. The recovery model should take into consideration path merging at
schemes are as follows: intermediate LSRs. If a fault affects the merged segment, all the
paths sharing that merged segment should be able to recover.
Similarly, if a fault affects a non-merged segment, only the path
that is affected by the fault should be recovered.
Recovery Time 5.0 MPLS Recovery Options
We define recovery time as the time required for a recovery path to There SHOULD be an option for:
be activated (and traffic flowing) after a fault. Recovery Time is
the sum of the Fault Detection Time, Hold-off Time, Notification
Time, Recovery Operation Time, and the Traffic Restoration Time. In
other words, it is the time between a failure of a node or link in
the network and the time before a recovery path is installed and
the traffic starts flowing on it.
Full Restoration Time I. Configuration of the recovery path as excess or reserved, with
excess as the default. The recovery path that is configured as excess
SHALL provide lower priority preemptable traffic access to the
protection bandwidth, while the recovery path configured as reserved
SHALL not provide any other traffic access to the protection
bandwidth.
We define full restoration time as the time required for a II. Configuring the protection alternatives as either rerouting or
permanent restoration. This is the time required for traffic to be protection switching.
routed onto links, which are capable of or have been engineered
sufficiently to handle traffic in recovery scenarios. Note that
this time may or may not be different from the "Recovery Time"
depending on whether equivalent or limited recovery paths are used.
Backup Capacity III. Enabling restoration as either non-revertive or revertive, with
non-revertive as the default if fixed protection counterparts are
used.
Recovery schemes may require differing amounts of "backup capacity" 6.0 Comparison Criteria
in the event of a fault. This capacity will be dependent on the Possible criteria to use for comparison of MPLS-based recovery
traffic characteristics of the network. However, it may also be schemes are as follows:
dependent on the particular protection plan selection algorithms as
well as the signaling and re-routing methods.
Additive Latency Recovery Time
Recovery schemes may introduce additive latency to traffic. For We define recovery time as the time required for a recovery path to
example, a recovery path may take many more hops than the working be activated (and traffic flowing) after a fault. Recovery Time is
path. This may be dependent on the recovery path selection the sum of the Fault Detection Time, Hold-off Time, Notification
algorithms. Time, Recovery Operation Time, and the Traffic Restoration Time. In
other words, it is the time between a failure of a node or link in
the network and the time before a recovery path is installed and the
traffic starts flowing on it.
Quality of Protection Full Restoration Time
Recovery schemes can be considered to encompass a spectrum of We define full restoration time as the time required for a permanent
"packet survivability" which may range from "relative" to restoration. This is the time required for traffic to be routed onto
"absolute. Relative survivability may mean that the packet is on an links, which are capable of or have been engineered sufficiently to
equal footing with other traffic of, as an example, the same diff- handle traffic in recovery scenarios. Note that this time may or may
serv code point (DSCP) in contending for the surviving network not be different from the "Recovery Time" depending on whether
resources. Absolute survivability may mean that the survivability equivalent or limited recovery paths are used.
of the protected traffic has explicit guarantees.
Re-ordering Setup vulnerability
Recovery schemes may introduce re-ordering of packets. Also the The amount of time that a working path or a set of working paths is
action of putting traffic back on preferred paths might cause left unprotected during such tasks as recovery path computation and
packet re-ordering. recovery path setup may be used to compare schemes. The nature of
this vulnerability should be taken into account, e.g.: End to End
schemes correlate the vulnerability with working paths, Local Repair
schemes have a topological correlation that cuts across working paths
and Network Plan approaches have a correlation that impacts the
entire network.
State Overhead Backup Capacity
As the number of recovery paths in a protection plan grows, the Recovery schemes may require differing amounts of "backup capacity"
state required to maintain them also grows. Schemes may require in the event of a fault. This capacity will be dependent on the
differing numbers of paths to maintain certain levels of coverage, traffic characteristics of the network. However, it may also be
etc. The state required may also depend on the particular scheme dependent on the particular protection plan selection algorithms as
used to recover. In many cases the state overhead will be in well as the signaling and re-routing methods.
proportion to the number of recovery paths.
Loss Additive Latency
Recovery schemes may introduce a certain amount of packet loss
during switchover to a recovery path. Schemes that introduce loss
during recovery can measure this loss by evaluating recovery times
in proportion to the link speed.
In case of link or node failure a certain packet loss is Recovery schemes may introduce additive latency to traffic. For
inevitable. example, a recovery path may take many more hops than the working
path. This may be dependent on the recovery path selection
algorithms.
Coverage Quality of Protection
Recovery schemes may offer various types of failover coverage. The Recovery schemes can be considered to encompass a spectrum of "packet
total coverage may be defined in terms of several metrics: survivability" which may range from "relative" to "absolute".
I. Fault Types: Recovery schemes may account for only link faults Relative survivability may mean that the packet is on an equal
or both node and link faults or also degraded service. For example, footing with other traffic of, as an example, the same diff-serv code
a scheme may require more recovery paths to take node faults into point (DSCP) in contending for the surviving network resources.
account. Absolute survivability may mean that the survivability of the
protected traffic has explicit guarantees.
II. Number of concurrent faults: dependent on the layout of Re-ordering
recovery paths in the protection plan, multiple fault scenarios may
be able to be restored.
III. Number of recovery paths: for a given fault, there may be one Recovery schemes may introduce re-ordering of packets. Also the
or more recovery paths. action of putting traffic back on preferred paths might cause packet
re-ordering.
IV. Percentage of coverage: dependent on a scheme and its State Overhead
implementation, a certain percentage of faults may be covered. This
may be subdivided into percentage of link faults and percentage of
node faults.
V. The number of protected paths may effect how fast the total set As the number of recovery paths in a protection plan grows, the state
of paths affected by a fault could be recovered. The ratio of required to maintain them also grows. Schemes may require differing
protected is n/N, where n is the number of protected paths and N is numbers of paths to maintain certain levels of coverage, etc. The
the total number of paths. state required may also depend on the particular scheme used to
recover. In many cases the state overhead will be in proportion to
the number of recovery paths.
7.0 Security Considerations Loss
The MPLS recovery that is specified herein does not raise any Recovery schemes may introduce a certain amount of packet loss during
security issues that are not already present in the MPLS switchover to a recovery path. Schemes that introduce loss during
architecture. recovery can measure this loss by evaluating recovery times in
proportion to the link speed.
8.0 Intellectual Property Considerations In case of link or node failure a certain packet loss is inevitable.
The IETF has been notified of intellectual property rights claimed Coverage
in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
9.0 Acknowledgements Recovery schemes may offer various types of failover coverage. The
total coverage may be defined in terms of several metrics:
We would like to thank members of the MPLS WG mailing list for I. Fault Types: Recovery schemes may account for only link faults or
their suggestions on the earlier version of this draft. In both node and link faults or also degraded service. For example, a
particular, Bora Akyol, Dave Allan, and Neil Harrisson, whose scheme may require more recovery paths to take node faults into
suggestions and comments were very helpful in revising the account.
document.
10.0 AuthorsĘ Addresses II. Number of concurrent faults: dependent on the layout of recovery
paths in the protection plan, multiple fault scenarios may be able to
be restored.
Vishal Sharma Ben Mack-Crane III. Number of recovery paths: for a given fault, there may be one or
Tellabs Research Center Tellabs Operations, Inc. more recovery paths.
One Kendall Square 4951 Indiana Avenue
Bldg. 100, Ste. 121 Lisle, IL 60532
Cambridge, MA 02139-1562 Phone: 630-512-7255
Phone: 617-577-8760 Ben.Mack-Crane@tellabs.com
Vishal.Sharma@tellabs.com
Srinivas Makam Ken Owens IV. Percentage of coverage: dependent on a scheme and its
Tellabs Operations, Inc. Tellabs Operations, Inc. implementation, a certain percentage of faults may be covered. This
4951 Indiana Avenue 1106 Fourth Street may be subdivided into percentage of link faults and percentage of
Lisle, IL 60532 St. Louis, MO 63126 node faults.
Phone: 630-512-7217 Phone: 314-918-1579
Srinivas.Makam@tellabs.com Ken.Owens@tellabs.com
Changcheng Huang Fiffi Hellstrand V. The number of protected paths may effect how fast the total set of
Dept. of Systems & Computer Engg. Nortel Networks paths affected by a fault could be recovered. The ratio of protected
Carleton University St Eriksgatan 115 is n/N, where n is the number of protected paths and N is the total
Minto Center, Rm. 3082 PO Box 6701 number of paths.
1125 Colonial By Drive 113 85 Stockholm, Sweden 7.0 Security Considerations
Ottawa, Ontario K1S 5B6, Canada Phone: +46 8 5088 3687
Phone: 613 520-2600 x2477 Fiffi@nortelnetworks.com
Changcheng.Huang@sce.carleton.ca
Jon Weil Brad Cain The MPLS recovery that is specified herein does not raise any
Nortel Networks Mirror Image Internet security issues that are not already present in the MPLS
Harlow Laboratories London Road 49 Dragon Ct. architecture.
Harlow Essex CM17 9NA, UK Woburn, MA 01801, USA
Phone: +44 (0)1279 403935 bcain@mirror-image.com
jonweil@nortelnetworks.com
Loa Andersson Bilel Jamoussi 8.0 Intellectual Property Considerations
Nortel Networks Nortel Networks
St Eriksgatan 115, PO Box 6701 3 Federal Street, BL3-03
113 85 Stockholm, Sweden Billerica, MA 01821, USA
Phone: +46 8 50 88 36 34 Phone:(978) 288-4506
loa.andersson@nortelnetworks.com jamoussi@nortelnetworks.com
Seyhan Civanlar Angela Chiu The IETF has been notified of intellectual property rights claimed in
Coreon, Inc. AT&T Labs, Rm. 4-204 regard to some or all of the specification contained in this
1200 South Avenue, Suite 103 100 Schulz Drive document. For more information consult the online list of claimed
Staten Island, NY 10314 Red Bank, NJ 07701 rights.
Phone: (718) 889 4203 Phone: (732) 345-3441
scivanlar@coreon.net alchiu@att.com
11.0 References 9.0 Acknowledgements
[1] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label We would like to thank members of the MPLS WG mailing list for their
Switching Architecture", Work in Progress, Internet Draft <draft-ietf- suggestions on the earlier version of this draft. In particular, Bora
mpls-arch-06.txt>, August 1999. Akyol, Dave Allan, and Neil Harrisson, whose suggestions and comments
were very helpful in revising the document.
[2] Andersson, L., Doolan, P., Feldman, N., Fredette, A., Thomas, B., 10.0 Authors' Addresses
"LDP Specification", Work in Progress, Internet Draft <draft-ietf-
mpls-ldp-06.txt>, September 1999.
[3] Awduche, D. Hannan, A., and Xiao, X., "Applicability Statement for Vishal Sharma Ben Mack-Crane
Extensions to RSVP for LSP-Tunnels", draft-ietf-mpls-rsvp-tunnel- Tellabs Research Center Tellabs Operations, Inc.
applicability-00.txt", work in progress, Sept. 1999. One Kendall Square 4951 Indiana Avenue
Bldg. 100, Ste. 121 Lisle, IL 60532
Cambridge, MA 02139-1562 Phone: 630-512-7255
Phone: 617-577-8760 Ben.Mack-Crane@tellabs.com
Vishal.Sharma@tellabs.com
[4] Jamoussi, B. "Constraint-Based LSP Setup using LDP", Work in Srinivas Makam Ken Owens
Progress, Internet Draft <draft-ietf-mpls-cr-ldp-03.txt>, September Tellabs Operations, Inc. Tellabs Operations, Inc.
1999. 4951 Indiana Avenue 1106 Fourth Street
Lisle, IL 60532 St. Louis, MO 63126
Phone: 630-512-7217 Phone: 314-918-1579
Srinivas.Makam@tellabs.com Ken.Owens@tellabs.com
[5] Braden, R., Zhang, L., Berson, S., Herzog, S., "Resource Changcheng Huang Fiffi Hellstrand
ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", Dept. of Systems & Computer Engg. Nortel Networks
RFC 2205, September 1997. Carleton University St Eriksgatan 115
Minto Center, Rm. 3082 PO Box 6701
1125 Colonial By Drive 113 85 Stockholm, Sweden
Ottawa, Ontario K1S 5B6, Canada Phone: +46 8 5088 3687
Phone: 613 520-2600 x2477 Fiffi@nortelnetworks.com
Changcheng.Huang@sce.carleton.ca
Jon Weil Brad Cain
Nortel Networks Mirror Image Internet
Harlow Laboratories London Road 49 Dragon Ct.
Harlow Essex CM17 9NA, UK Woburn, MA 01801, USA
Phone: +44 (0)1279 403935 bcain@mirror-image.com
jonweil@nortelnetworks.com
[6] Awduche, D. et al "Extensions to RSVP for LSP Tunnels", Work in Loa Andersson Bilel Jamoussi
Progress, Internet Draft <draft-ietf-mpls-rsvp-lsp-tunnel-04.txt, Nortel Networks Nortel Networks
September 1999. St Eriksgatan 115, PO Box 6701 3 Federal Street, BL3-03
113 85 Stockholm, Sweden Billerica, MA 01821, USA
Phone: +46 8 50 88 36 34 Phone:(978) 288-4506
loa.andersson@nortelnetworks.com jamoussi@nortelnetworks.com
[7] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., McManus, J., Seyhan Civanlar Angela Chiu
"Requirements for Traffic Engineering Over MPLS", RFC 2702, September Coreon, Inc. AT&T Labs, Rm. 4-204
1200 South Avenue, Suite 103 100 Schulz Drive
Staten Island, NY 10314 Red Bank, NJ 07701
Phone: (718) 889 4203 Phone: (732) 345-3441
scivanlar@coreon.net alchiu@att.com
11.0 References
[1] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label
Switching Architecture", Internet Draft draft-ietf-mpls-arch-07.txt,
Work in Progress , July 2000.
[2] Andersson, L., Doolan, P., Feldman, N., Fredette, A., Thomas, B.,
"LDP Specification", Internet Draft draft-ietf-mpls-ldp-11.txt, Work in
Progress , August 2000.
[3] Awduche, D. Hannan, A., and Xiao, X., "Applicability Statement for
Extensions to RSVP for LSP-Tunnels", draft-ietf-mpls-rsvp-tunnel-
applicability-01.txt, work in progress, April 2000.
[4] Jamoussi, B. et al "Constraint-Based LSP Setup using LDP", Internet
Draft draft-ietf-mpls-cr-ldp-04.txt, Work in Progress , July 2000.
[5] Braden, R., Zhang, L., Berson, S., Herzog, S., "Resource ReSerVation
Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205,
September 1997.
[6] Awduche, D. et al "Extensions to RSVP for LSP Tunnels", Internet
Draft draft-ietf-mpls-rsvp-lsp-tunnel-07.txt, Work in Progress, August
2000.
[7] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., McManus, J.,
"Requirements for Traffic Engineering Over MPLS", RFC 2702, September
1999. 1999.
[8] Andersson, L., Cain B., Jamoussi, B., "Requirement Framework for [8] Andersson, L., Cain B., Jamoussi, B., "Requirement Framework for
Fast Re-route with MPLS", draft-andersson-reroute-frmwrk-00.txt, work Fast Re-route with MPLS", draft-andersson-reroute-frmwrk-00.txt, work in
in progress, October 1999. progress, October 1999.
[9] Goguen, R. and Swallow, G., "RSVP Label Allocation for Backup [9] Goguen, R. and Swallow, G., "RSVP Label Allocation for Backup
Tunnels", draft-swallow-rsvp-bypass-label-00.txt, work in progress, Tunnels", draft-swallow-rsvp-bypass-label-00.txt, work in progress,
October 1999. October 1999.
[10] Makam, S., Sharma, V., Owens, K., Huang, C., [10] Makam, S., Sharma, V., Owens, K., Huang, C.,
"Protection/restoration of MPLS Networks", draft-makam-mpls- "Protection/restoration of MPLS Networks", Internet Draft draft-makam-
protection-00.txt, work in progress, October 1999. mpls-protection-00.txt, work in progress, October 1999.
[11] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G., [11] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G.,
Viswanathan, A., "A Framework for Multiprotocol Label Switching", Viswanathan, A., "A Framework for Multiprotocol Label Switching",
<draft-ietf-mpls-framework-05.txt>, Work in Progress, September 1999. Internet Draft draft-ietf-mpls-framework-05.txt, Work in Progress,
September 1999.
[12] Haskin, D. and Krishnan R., "A Method for Setting an Alternative [12] Haskin, D. and Krishnan R., "A Method for Setting an Alternative
Label Switched Path to Handle Fast Reroute", draft-haskin-mpls-fast- Label Switched Path to Handle Fast Reroute", Internet Draft draft-
reroute-01.txt, 1999, Work in progress. haskin-mpls-fast-reroute-05.txt, November 2000, Work in progress.
[13] Owens, K., Makam,V., Sharma, V., Mack-Crane, B., and Haung, C., "A
Path Protection/Restoration Mechanism for MPLS Networks", Internet
Draft, draft-chang-mpls-path-protection-02.txt, Work in Progress
November 2000.
 End of changes. 330 change blocks. 
1279 lines changed or deleted 1306 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/