< draft-ietf-mpls-recovery-frmwrk-06.txt   draft-ietf-mpls-recovery-frmwrk-07.txt >
MPLS Working Group Vishal Sharma (Metanoia, Inc.) MPLS Working Group Vishal Sharma (Metanoia, Inc.)
Informational Track Fiffi Hellstrand (Nortel Networks) Informational Track Fiffi Hellstrand (Nortel Networks)
Expires: Januray 2003 (Editors) Expires: March 2003 (Editors)
July 2002 September 2002
Framework for MPLS-based Recovery Framework for MPLS-based Recovery
<draft-ietf-mpls-recovery-frmwrk-06.txt> <draft-ietf-mpls-recovery-frmwrk-07.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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Multi-protocol label switching (MPLS) integrates the label swapping Multi-protocol label switching (MPLS) integrates the label swapping
forwarding paradigm with network layer routing. To deliver reliable forwarding paradigm with network layer routing. To deliver reliable
service, MPLS requires a set of procedures to provide protection of service, MPLS requires a set of procedures to provide protection of
the traffic carried on different paths. This requires that the label the traffic carried on different paths. This requires that the label
switched routers (LSRs) support fault detection, fault notification, switched routers (LSRs) support fault detection, fault notification,
and fault recovery mechanisms, and that MPLS signaling, support the and fault recovery mechanisms, and that MPLS signaling, support the
configuration of recovery. With these objectives in mind, this configuration of recovery. With these objectives in mind, this
document specifies a framework for MPLS based recovery. document specifies a framework for MPLS based recovery.
Table of Contents Table of Contents
1. Introduction....................................................2 1. Introduction ....................................................2
1.1. Background......................................................3 1.1. Background ......................................................3
1.2. Motivation for MPLS-Based Recovery..............................3 1.2. Motivation for MPLS-Based Recovery ..............................3
1.3. Objectives/Goals................................................4 1.3. Objectives/Goals ................................................4
2. Contributing Authors............................................6 2. Contributing Authors ............................................6
3. Overview........................................................6 3. Overview ........................................................6
3.1. Recovery Models.................................................7 3.1. Recovery Models .................................................7
3.1.1 Rerouting.....................................................7 3.1.1 Rerouting .....................................................7
3.1.2 Protection Switching..........................................7 3.1.2 Protection Switching ..........................................8
3.2. The Recovery Cycles.............................................8 3.2. The Recovery Cycles .............................................8
3.2.1 MPLS Recovery Cycle Model.....................................8 3.2.1 MPLS Recovery Cycle Model .....................................8
3.2.2 MPLS Reversion Cycle Model....................................9 3.2.2 MPLS Reversion Cycle Model ...................................10
3.2.3 Dynamic Re-routing Cycle Model...............................11 3.2.3 Dynamic Re-routing Cycle Model ...............................11
3.3. Definitions and Terminology....................................12 3.3. Definitions and Terminology ....................................13
3.3.1 General Recovery Terminology.................................13 3.3.1 General Recovery Terminology .................................13
3.3.2 Failure Terminology..........................................15 3.3.2 Failure Terminology ..........................................16
3.4. Abbreviations..................................................16 3.4. Abbreviations ..................................................16
4. MPLS-based Recovery Principles.................................16 4. MPLS-based Recovery Principles .................................17
4.1. Configuration of Recovery......................................17 4.1. Configuration of Recovery ......................................17
4.2. Initiation of Path Setup.......................................17 4.2. Initiation of Path Setup .......................................17
4.3. Initiation of Resource Allocation..............................18 4.3. Initiation of Resource Allocation ..............................18
4.4. Scope of Recovery..............................................18 4.4. Scope of Recovery ..............................................18
4.4.1 Topology.....................................................18 4.4.1 Topology .....................................................19
4.4.1.1 Local Repair................................................18 1.1.1.1 Local Repair................................................19
4.4.1.2 Global Repair...............................................19 1.1.1.2 Global Repair...............................................19
4.4.1.3 Alternate Egress Repair.....................................19 1.1.1.3 Alternate Egress Repair.....................................20
4.4.1.4 Multi-Layer Repair..........................................20 1.1.1.4 Multi-Layer Repair..........................................20
4.4.1.5 Concatenated Protection Domains.............................20
4.4.2 Path Mapping.................................................20
4.4.3 Bypass Tunnels...............................................21
4.4.4 Recovery Granularity.........................................21
4.4.4.1 Selective Traffic Recovery..................................22
4.4.4.2 Bundling....................................................22
4.4.5 Recovery Path Resource Use...................................22
4.5. Fault Detection................................................22
4.6. Fault Notification.............................................23
4.7. Switch-Over Operation..........................................24
4.7.1 Recovery Trigger.............................................24
4.7.2 Recovery Action..............................................25
4.8. Post Recovery Operation........................................25
4.8.1 Fixed Protection Counterparts................................25
4.8.1.1 Revertive Mode..............................................25
4.8.1.2 Non-revertive Mode..........................................25
4.8.2 Dynamic Protection Counterparts..............................26
4.8.3 Restoration and Notification.................................26
4.8.4 Reverting to Preferred Path (or Controlled Rearrangement)....27
4.9. Performance....................................................27
5. MPLS Recovery Features.........................................28
6. Comparison Criteria............................................28
7. Security Considerations........................................30
8. Intellectual Property Considerations...........................30
9. Acknowledgements...............................................31
10. EditorsÆ Addresses.............................................31
11. References.....................................................31
1. Introduction 1.1.1.5 Concatenated Protection Domains.............................20
4.4.2 Path Mapping .................................................20
4.4.3 Bypass Tunnels ...............................................21
4.4.4 Recovery Granularity .........................................22
1.1.1.6 Selective Traffic Recovery..................................22
1.1.1.7 Bundling....................................................22
4.4.5 Recovery Path Resource Use ...................................22
4.5. Fault Detection ................................................23
4.6. Fault Notification .............................................23
4.7. Switch-Over Operation ..........................................24
4.7.1 Recovery Trigger .............................................24
4.7.2 Recovery Action ..............................................25
4.8. Post Recovery Operation ........................................25
4.8.1 Fixed Protection Counterparts ................................25
1.1.1.8 Revertive Mode..............................................25
1.1.1.9 Non-revertive Mode..........................................26
4.8.2 Dynamic Protection Counterparts ..............................26
4.8.3 Restoration and Notification .................................26
4.8.4 Reverting to Preferred Path (or Controlled Rearrangement) ....27
4.9. Performance ....................................................27
5. MPLS Recovery Features .........................................28
6. Comparison Criteria ............................................28
7. Security Considerations ........................................30
8. Intellectual Property Considerations ...........................31
9. Acknowledgements ...............................................31
10. Editors' Addresses .............................................31
11. References .....................................................31
1. Introduction
This memo describes a framework for MPLS-based recovery. We provide a This memo describes a framework for MPLS-based recovery. We provide a
detailed taxonomy of recovery terminology, and discuss the motivation detailed taxonomy of recovery terminology, and discuss the motivation
for, the objectives of, and the requirements for MPLS-based recovery. for, the objectives of, and the requirements for MPLS-based recovery.
We outline principles for MPLS-based recovery, and also provide We outline principles for MPLS-based recovery, and also provide
comparison criteria that may serve as a basis for comparing and comparison criteria that may serve as a basis for comparing and
evaluating different recovery schemes. evaluating different recovery schemes.
At points in the document, we provide some thoughts about the At points in the document, we provide some thoughts about the
operation or viability of certain recovery objectives. These should operation or viability of certain recovery objectives. These should
skipping to change at page 3, line 30 skipping to change at page 3, line 30
with network layer routing allows flexibility in the delivery of new with network layer routing allows flexibility in the delivery of new
routing services. MPLS allows for using such media specific routing services. MPLS allows for using such media specific
forwarding mechanisms as label swapping. This enables some forwarding mechanisms as label swapping. This enables some
sophisticated features such as quality-of-service (QoS) and traffic sophisticated features such as quality-of-service (QoS) and traffic
engineering [2] to be implemented more effectively. An important engineering [2] to be implemented more effectively. An important
component of providing QoS, however, is the ability to transport data component of providing QoS, however, is the ability to transport data
reliably and efficiently. Although the current routing algorithms are reliably and efficiently. Although the current routing algorithms are
robust and survivable, the amount of time they take to recover from a robust and survivable, the amount of time they take to recover from a
fault can be significant, on the order of several seconds or minutes, fault can be significant, on the order of several seconds or minutes,
causing disruption of service for some applications in the interim. causing disruption of service for some applications in the interim.
This is unacceptable is situations where the aim to provide a highly This is unacceptable in situations where the aim to provide a highly
reliable service, with recovery times that are on the order of reliable service, with recovery times that are on the order of
seconds down to 10's of milliseconds. seconds down to 10's of milliseconds. Examples of such applications
are Virtual Leased Line services, Stock Exchange data services, voice
traffic, video services etc, i.e., any application for which a
disruption in service due to a failure is long enough to not fulfill
service agreements or not guarantee the required level of quality.
MPLS recovery may be motivated by the notion that there are MPLS recovery may be motivated by the notion that there are
limitations to improving the recovery times of current routing limitations to improving the recovery times of current routing
algorithms. Additional improvement can be obtained by augmenting algorithms. Additional improvement can be obtained by augmenting
these algorithms with MPLS recovery mechanisms [3]. Since MPLS is a these algorithms with MPLS recovery mechanisms [3]. Since MPLS is a
possible technology of choice in future IP-based transport networks, possible technology of choice in future IP-based transport networks,
it is useful that MPLS be able to provide protection and restoration it is useful that MPLS be able to provide protection and restoration
of traffic. MPLS may facilitate the convergence of network of traffic. MPLS may facilitate the convergence of network
functionality on a common control and management plane. Further, a functionality on a common control and management plane. Further, a
protection priority could be used as a differentiating mechanism for protection priority could be used as a differentiating mechanism for
premium services that require high reliability. The remainder of this premium services that require high reliability, such as Virtual
document provides a framework for MPLS based recovery. It is focused Leased Line services, high priority voice and video traffic. The
at a conceptual level and is meant to address motivation, objectives remainder of this document provides a framework for MPLS based
and requirements. Issues of mechanism, policy, routing plans and recovery. It is focused at a conceptual level and is meant to
characteristics of traffic carried by recovery paths are beyond the address motivation, objectives and requirements. Issues of
scope of this document. mechanism, policy, routing plans and characteristics of traffic
carried by recovery paths are beyond 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 MPLS based protection of traffic (called MPLS-based Recovery) is
useful for a number of reasons. The most important is its ability to useful for a number of reasons. The most important is its ability to
increase network reliability by enabling a faster response to faults increase network reliability by enabling a faster response to faults
than is possible with traditional Layer 3 (or IP layer) approaches than is possible with traditional Layer 3 (or IP layer) approaches
alone while still providing the visibility of the network afforded by alone while still providing the visibility of the network afforded by
Layer 3. Furthermore, a protection mechanism using MPLS could enable Layer 3. Furthermore, a protection mechanism using MPLS could enable
IP traffic to be put directly over WDM optical channels and provide a IP traffic to be put directly over WDM optical channels and provide a
recovery option without an intervening SONET layer. This would recovery option without an intervening SONET layer. This would
facilitate the construction of IP-over-WDM networks that request a facilitate the construction of IP-over-WDM networks that request a
fast recovery ability. fast recovery ability.
skipping to change at page 4, line 27 skipping to change at page 4, line 32
SONET) mechanisms may be wasteful use of resources. SONET) mechanisms may be wasteful use of resources.
III. The granularity at which the lower layers may be able to protect III. The granularity at which the lower layers may be able to protect
traffic may be too coarse for traffic that is switched using MPLS- traffic may be too coarse for traffic that is switched using MPLS-
based mechanisms. based mechanisms.
IV. Layer 0 or Layer 1 mechanisms may have no visibility into higher IV. Layer 0 or Layer 1 mechanisms may have no visibility into higher
layer operations. Thus, while they may provide, for example, link layer operations. Thus, while they may provide, for example, link
protection, they cannot easily provide node protection or protection protection, they cannot easily provide node protection or protection
of traffic transported at layer 3. Further, this may prevent the of traffic transported at layer 3. Further, this may prevent the
lower layers from providing restoration based on the trafficÆs needs. lower layers from providing restoration based on the traffic's needs.
For example, fast restoration for traffic that needs it, and slower For example, fast restoration for traffic that needs it, and slower
restoration (with possibly more optimal use of resources) for traffic restoration (with possibly more optimal use of resources) for traffic
that does not require fast restoration. In networks where the latter that does not require fast restoration. In networks where the latter
class of traffic is dominant, providing fast restoration to all class of traffic is dominant, providing fast restoration to all
classes of traffic may not be cost effective from a service classes of traffic may not be cost effective from a service
providerÆs perspective. provider's perspective.
V. MPLS has desirable attributes when applied to the purpose of V. MPLS has desirable attributes when applied to the purpose of
recovery for connectionless networks. Specifically that an LSP is recovery for connectionless networks. Specifically that an LSP is
source routed and a forwarding path for recovery can be "pinned" and source routed and a forwarding path for recovery can be "pinned" and
is not affected by transient instability in SPF routing brought on by is not affected by transient instability in SPF routing brought on by
failure scenarios. failure scenarios.
VI. Establishing interoperability of protection mechanisms between VI. Establishing interoperability of protection mechanisms between
routers/LSRs from different vendors in IP or MPLS networks is desired routers/LSRs from different vendors in IP or MPLS networks is desired
to enable recovery mechanisms to work in a multivendor environment, to enable recovery mechanisms to work in a multivendor environment,
skipping to change at page 4, line 56 skipping to change at page 5, line 10
1.3. Objectives/Goals 1.3. Objectives/Goals
The following are some important goals for MPLS-based recovery. The following are some important goals for MPLS-based recovery.
Ia. MPLS-based recovery mechanisms may be subject to the traffic Ia. MPLS-based recovery mechanisms may be subject to the traffic
engineering goal of optimal use of resources. engineering goal of optimal use of resources.
Ib. MPLS based recovery mechanisms should aim to facilitate Ib. MPLS based recovery mechanisms should aim to facilitate
restoration times that are sufficiently fast for the end user restoration times that are sufficiently fast for the end user
application. That is, that better match the end-userÆs application application. That is, that better match the end-user's application
requirements. In some cases, this may be as short as 10s of requirements. In some cases, this may be as short as 10s of
milliseconds. milliseconds.
We observe that Ia and Ib are conflicting objectives, and a trade off We observe that Ia and Ib are conflicting objectives, and a trade off
exists between them. The optimal choice depends on the end-user exists between them. The optimal choice depends on the end-user
applicationÆs sensitivity to restoration time and the cost impact of application's sensitivity to restoration time and the cost impact of
introducing restoration in the network, as well as the end-user introducing restoration in the network, as well as the end-user
applicationÆs sensitivity to cost. application's sensitivity to cost.
II. MPLS-based recovery should aim to maximize network reliability II. MPLS-based recovery should aim to maximize network reliability
and availability. MPLS-based recovery of traffic should aim to and availability. MPLS-based recovery of traffic should aim to
minimize the number of single points of failure in the MPLS protected minimize the number of single points of failure in the MPLS protected
domain. domain.
III. MPLS-based recovery should aim to enhance the reliability of the III. MPLS-based recovery should aim to enhance the reliability of the
protected traffic while minimally or predictably degrading the protected traffic while minimally or predictably degrading the
traffic carried by the diverted resources. traffic carried by the diverted resources.
skipping to change at page 6, line 5 skipping to change at page 6, line 11
desired, the recovery path should meet the resource requirements of, desired, the recovery path should meet the resource requirements of,
and achieve the same performance characteristics as, the working and achieve the same performance characteristics as, the working
path. path.
We observe that some of the above are conflicting goals, and real We observe that some of the above are conflicting goals, and real
deployment will often involve engineering compromises based on a deployment will often involve engineering compromises based on a
variety of factors such as cost, end-user application requirements, variety of factors such as cost, end-user application requirements,
network efficiency, and revenue considerations. Thus, these goals are network efficiency, and revenue considerations. Thus, these goals are
subject to tradeoffs based on the above considerations. subject to tradeoffs based on the above considerations.
2. Contributing Authors 2. Contributing Authors
This document was the collective work of several individuals over a This document was the collective work of several individuals over a
period of two and a half years. The text and content of this document period of two and a half years. The text and content of this document
was contributed by the editors and the co-authors listed below. (The was contributed by the editors and the co-authors listed below. (The
contact information for the editors appears in Section 10, and is not contact information for the editors appears in Section 10, and is not
repeated below.) repeated below.)
Ben Mack-Crane Srinivas Makam Ben Mack-Crane Srinivas Makam
Tellabs Operations, Inc. Eshernet, Inc. Tellabs Operations, Inc. Eshernet, Inc.
4951 Indiana Avenue 1712 Ada Ct. 4951 Indiana Avenue 1712 Ada Ct.
skipping to change at page 6, line 37 skipping to change at page 6, line 43
Jon Weil Brad Cain Jon Weil Brad Cain
Nortel Networks Storigen Systems Nortel Networks Storigen Systems
Harlow Laboratories London Road 650 Suffolk Street Harlow Laboratories London Road 650 Suffolk Street
Harlow Essex CM17 9NA, UK Lowell, MA 01854 Harlow Essex CM17 9NA, UK Lowell, MA 01854
Phone: +44 (0)1279 403935 Phone: (978) 323-4454 Phone: +44 (0)1279 403935 Phone: (978) 323-4454
jonweil@nortelnetworks.com bcain@storigen.com jonweil@nortelnetworks.com bcain@storigen.com
Loa Andersson Bilel Jamoussi Loa Andersson Bilel Jamoussi
Utfors AB Nortel Networks Utfors AB Nortel Networks
R…sundav„gen 12, Box 525 3 Federal Street, BL3-03 Rasundavagen 12, Box 525 3 Federal Street, BL3-03
169 29 Solna, Sweden Billerica, MA 01821, USA 169 29 Solna, Sweden Billerica, MA 01821, USA
Phone: +46 8 5270 5038 Phone:(978) 288-4506 Phone: +46 8 5270 5038 Phone:(978) 288-4506
loa.andersson@utfors.se jamoussi@nortelnetworks.com loa.andersson@utfors.se jamoussi@nortelnetworks.com
Angela Chiu Seyhan Civanlar Angela Chiu Seyhan Civanlar
Celion Networks, Inc. Lemur Networks, Inc. Celion Networks, Inc. Lemur Networks, Inc.
One Shiela Drive, Suite 2 135 West 20th Street, 5th Floor One Shiela Drive, Suite 2 135 West 20th Street, 5th Floor
Tinton Falls, NJ 07724 New York, NY 10011 Tinton Falls, NJ 07724 New York, NY 10011
Phone: (732) 345-3441 Phone: (212) 367-7676 Phone: (732) 345-3441 Phone: (212) 367-7676
angela.chiu@celion.com scivanlar@lemurnetworks.com angela.chiu@celion.com scivanlar@lemurnetworks.com
3. Overview
3. Overview
There are several options for providing protection of traffic. The There are several options for providing protection of traffic. The
most generic requirement is the specification of whether recovery most generic requirement is the specification of whether recovery
should be via Layer 3 (or IP) rerouting or via MPLS protection should be via Layer 3 (or IP) rerouting or via MPLS protection
switching or rerouting actions. switching or rerouting actions.
Generally network operators aim to provide the fastest and the best Generally network operators aim to provide the fastest and the best
protection mechanism that can be provided at a reasonable cost. The protection mechanism that can be provided at a reasonable cost. The
higher the levels of protection, the more the resources consumed. higher the levels of protection, the more the resources consumed.
Therefore it is expected that network operators will offer a spectrum Therefore it is expected that network operators will offer a spectrum
of service levels. MPLS-based recovery should give the flexibility to of service levels. MPLS-based recovery should give the flexibility to
skipping to change at page 16, line 47 skipping to change at page 17, line 4
FRS: Fault Recovery Signal. FRS: Fault Recovery Signal.
LD: Link Degraded. LD: Link Degraded.
LF: Link Failure. LF: Link Failure.
PD: Path Degraded. PD: Path Degraded.
PF: Path Failure. PF: Path Failure.
PML: Path Merge LSR. PML: Path Merge LSR.
PG: Path Group. PG: Path Group.
POR: Point of Repair POR: Point of Repair
PPG: Protected Path Group. PPG: Protected Path Group.
PTP: Protected Traffic Portion. PTP: Protected Traffic Portion.
PSL: Path Switch LSR. PSL: Path Switch LSR.
4. MPLS-based Recovery Principles 4. MPLS-based Recovery Principles
MPLS-based recovery refers to the ability to effect quick and MPLS-based recovery refers to the ability to effect quick and
complete restoration of traffic affected by a fault in an MPLS- complete restoration of traffic affected by a fault in an MPLS-
enabled network. The fault may be detected on the IP layer or in enabled network. The fault may be detected on the IP layer or in
lower layers over which IP traffic is transported. Fastest MPLS lower layers over which IP traffic is transported. Fastest MPLS
recovery is assumed to be achieved with protection switching and may recovery is assumed to be achieved with protection switching and may
be viewed as the MPLS LSR switch completion time that is comparable be viewed as the MPLS LSR switch completion time that is comparable
to, or equivalent to, the 50 ms switch-over completion time of the to, or equivalent to, the 50 ms switch-over completion time of the
SONET layer. This section provides a discussion of the concepts and SONET layer. This section provides a discussion of the concepts and
principles of MPLS-based recovery. The concepts are presented in principles of MPLS-based recovery. The concepts are presented in
skipping to change at page 18, line 48 skipping to change at page 19, line 4
Here a recovery path reserves the required resources after a failure Here a recovery path reserves the required resources after a failure
on the working path has been detected and notified to the PSL and 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 before the traffic on the working path is switched over to the
recovery path. recovery path.
Note that under both the options above, depending on the amount of Note that under both the options above, depending on the amount of
resources reserved on the recovery path, it could either be an resources reserved on the recovery path, it could either be an
equivalent recovery path or a limited recovery path. equivalent recovery path or a limited recovery path.
4.4. Scope of Recovery 4.4. Scope of Recovery
4.4.1 Topology 4.4.1 Topology
4.4.1.1 Local Repair 4.4.1.1 Local Repair
The intent of local repair is to protect against a link or neighbor The intent of local repair is to protect against a link or neighbor
node fault and to minimize the amount of time required for failure node fault and to minimize the amount of time required for failure
propagation. In local repair (also known as local recovery), the node propagation. In local repair (also known as local recovery), the node
immediately upstream of the fault is the one to initiate recovery immediately upstream of the fault is the one to initiate recovery
(either rerouting or protection switching). Local repair can be of (either rerouting or protection switching). Local repair can be of
two types: two types:
Link Recovery/Restoration Link Recovery/Restoration
skipping to change at page 19, line 35 skipping to change at page 19, line 43
Node Recovery/Restoration Node 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 neighbor node deemed to be unreliable. Thus the recovery path is
disjoint from the working path only at a particular node and at links disjoint from the working path only at a particular node and at links
associated with the working path at that node. Once again, the associated with the working path at that node. Once again, the
traffic on the primary path is switched over to the recovery path at 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 the upstream LSR that directly connects to the failed node, and the
recovery path shares overlapping portions with the working path. recovery path shares overlapping portions with the working path.
4.4.1.2 Global Repair 4.4.1.2 Global Repair
The intent of global repair is to protect against any link or node The intent of global repair is to protect against any link or node
fault on a path or on a segment of a path, with the obvious exception fault on a path or on a segment of a path, with the obvious exception
of the faults occurring at the ingress node of the protected path of the faults occurring at the ingress node of the protected path
segment. In global repair, the POR is usually distant from the segment. In global repair, the POR is usually distant from the
failure and needs to be notified by a FIS. failure and needs to be notified by a FIS.
In global repair also, end-to-end path recovery/restoration applies. In global repair also, end-to-end path recovery/restoration applies.
In many cases, the recovery path can be made completely link and node In many cases, the recovery path can be made completely link and node
disjoint with its working path. This has the advantage of protecting 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 against all link and node fault(s) on the working path (end-to-end
skipping to change at page 19, line 47 skipping to change at page 20, line 4
The intent of global repair is to protect against any link or node The intent of global repair is to protect against any link or node
fault on a path or on a segment of a path, with the obvious exception fault on a path or on a segment of a path, with the obvious exception
of the faults occurring at the ingress node of the protected path of the faults occurring at the ingress node of the protected path
segment. In global repair, the POR is usually distant from the segment. In global repair, the POR is usually distant from the
failure and needs to be notified by a FIS. failure and needs to be notified by a FIS.
In global repair also, end-to-end path recovery/restoration applies. In global repair also, end-to-end path recovery/restoration applies.
In many cases, the recovery path can be made completely link and node In many cases, the recovery path can be made completely link and node
disjoint with its working path. This has the advantage of protecting 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 against all link and node fault(s) on the working path (end-to-end
path or path segment). path or path segment).
However, it may, in some cases, be slower than local repair since the However, it may, in some cases, be slower than local repair since the
fault notification message must now travel to the POR to trigger the fault notification message must now travel to the POR to trigger the
recovery action. recovery action.
4.4.1.3 Alternate Egress Repair 4.4.1.3 Alternate Egress Repair
It is possible to restore service without specifically recovering the It is possible to restore service without specifically recovering the
faulted path. faulted path.
For example, for best effort IP service it is possible to select a 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 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 (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 router that is acceptable for forwarding the FEC carried by the
working path (without creating looping). In an engineering context, working path (without creating looping). In an engineering context,
specific alternative FEC/LSP mappings with alternate egresses can be specific alternative FEC/LSP mappings with alternate egresses can be
formed. formed.
This may simplify enhancing the reliability of implicitly constructed This may simplify enhancing the reliability of implicitly constructed
MPLS topologies. A PSL may qualify LSP/FEC bindings as candidate MPLS topologies. A PSL may qualify LSP/FEC bindings as candidate
recovery paths as simply link and node disjoint with the immediate recovery paths as simply link and node disjoint with the immediate
downstream LSR of the working path. downstream LSR of the working path.
4.4.1.4 Multi-Layer Repair 4.4.1.4 Multi-Layer Repair
Multi-layer repair broadens the network designerÆs tool set for those Multi-layer repair broadens the network designer's tool set for those
cases where multiple network layers can be managed together to cases where multiple network layers can be managed together to
achieve overall network goals. Specific criteria for determining achieve overall network goals. Specific criteria for determining
when multi-layer repair is appropriate are beyond the scope of this when multi-layer repair is appropriate are beyond the scope of this
draft. draft.
4.4.1.5 Concatenated Protection Domains 4.4.1.5 Concatenated Protection Domains
A given service may cross multiple networks and these may employ A given service may cross multiple networks and these may employ
different recovery mechanisms. It is possible to concatenate different recovery mechanisms. It is possible to concatenate
protection domains so that service recovery can be provided end-to- protection domains so that service recovery can be provided end-to-
end. It is considered that the recovery mechanisms in different end. It is considered that the recovery mechanisms in different
domains may operate autonomously, and that multiple points of domains may operate autonomously, and that multiple points of
attachment may be used between domains (to ensure there is no single attachment may be used between domains (to ensure there is no single
point of failure). Alternate egress repair requires management of point of failure). Alternate egress repair requires management of
concatenated domains in that an explicit MPLS point of failure (the concatenated domains in that an explicit MPLS point of failure (the
PML) is by definition excluded. Details of concatenated protection PML) is by definition excluded. Details of concatenated protection
skipping to change at page 22, line 5 skipping to change at page 22, line 13
traffic in the tunnel at any given time is restricted, this is traffic in the tunnel at any given time is restricted, this is
similar to the n-to-1 or n-to-m protection cases mentioned in Section similar to the n-to-1 or n-to-m protection cases mentioned in Section
3.4.2. 3.4.2.
4.4.4 Recovery Granularity 4.4.4 Recovery Granularity
Another dimension of recovery considers the amount of traffic Another dimension of recovery considers the amount of traffic
requiring protection. This may range from a fraction of a path to a requiring protection. This may range from a fraction of a path to a
bundle of paths. bundle of paths.
4.4.4.1 Selective Traffic Recovery 4.4.4.1 Selective Traffic Recovery
This option allows for the protection of a fraction of traffic within This option allows for the protection of a fraction of traffic within
the same path. The portion of the traffic on an individual path that the same path. The portion of the traffic on an individual path that
requires protection is called a protected traffic portion (PTP). A requires protection is called a protected traffic portion (PTP). A
single path may carry different classes of traffic, with different single path may carry different classes of traffic, with different
protection requirements. The protected portion of this traffic may be protection requirements. The protected portion of this traffic may be
identified by its class, as for example, via the EXP bits in the MPLS identified by its class, as for example, via the EXP bits in the MPLS
shim header or via the priority bit in the ATM header. shim header or via the priority bit in the ATM header.
4.4.4.2 Bundling 4.4.4.2 Bundling
Bundling is a technique used to group multiple working paths together Bundling is a technique used to group multiple working paths together
in order to recover them simultaneously. The logical bundling of in order to recover them simultaneously. The logical bundling of
multiple working paths requiring protection, each of which is routed multiple working paths requiring protection, each of which is routed
identically between a PSL and a PML, is called a protected path group 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). 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 PPG as a whole can be protected either by being switched to a bypass
tunnel or by being switched to a recovery path. tunnel or by being switched to a recovery path.
4.4.5 Recovery Path Resource Use 4.4.5 Recovery Path Resource Use
skipping to change at page 23, line 34 skipping to change at page 23, line 45
determining the error rate on the path or some portion of the path. determining the error rate on the path or some portion of the path.
This is local to the LSR and consists of excessive discarding of This is local to the LSR and consists of excessive discarding of
packets at an interface, either due to label mismatch or due to TTL packets at an interface, either due to label mismatch or due to TTL
errors, for example. errors, for example.
Link Failure (LF) is an indication from a lower layer that the link Link Failure (LF) is an indication from a lower layer that the link
over which the path is carried has failed. If the lower layer over which the path is carried has failed. If the lower layer
supports detection and reporting of this fault (that is, any fault supports detection and reporting of this fault (that is, any fault
that indicates link failure e.g., SONET LOS), this may be used by the that indicates link failure e.g., SONET LOS), this may be used by the
MPLS recovery mechanism. In some cases, using LF indications may MPLS recovery mechanism. In some cases, using LF indications may
provide faster fault detection than using only MPLSûbased fault provide faster fault detection than using only MPLS_based fault
detection mechanisms. detection mechanisms.
Link Degraded (LD) is an indication from a lower layer that the link Link Degraded (LD) is an indication from a lower layer that the link
over which the path is carried is performing below an acceptable over which the path is carried is performing below an acceptable
level. If the lower layer supports detection and reporting of this level. If the lower layer supports detection and reporting of this
fault, it may be used by the MPLS recovery mechanism. In some cases, fault, it may be used by the MPLS recovery mechanism. In some cases,
using LD indications may provide faster fault detection than using using LD indications may provide faster fault detection than using
only MPLS-based fault detection mechanisms. only MPLS-based fault detection mechanisms.
4.6. Fault Notification 4.6. Fault Notification
skipping to change at page 25, line 34 skipping to change at page 25, line 42
4.8.1 Fixed Protection Counterparts 4.8.1 Fixed Protection Counterparts
For fixed protection counterparts the PSL will be pre-configured with For fixed protection counterparts the PSL will be pre-configured with
the appropriate behavior to take when the original fixed path is the appropriate behavior to take when the original fixed path is
restored to service. The choices are revertive and non-revertive restored to service. The choices are revertive and non-revertive
mode. The choice will typically be depended on relative costs of the mode. The choice will typically be depended on relative costs of the
working and protection paths, and the tolerance of the service to the working and protection paths, and the tolerance of the service to the
effects of switching paths yet again. These protection modes indicate effects of switching paths yet again. These protection modes indicate
whether or not there is a preferred path for the protected traffic. whether or not there is a preferred path for the protected traffic.
4.8.1.1 Revertive Mode 4.8.1.1 Revertive Mode
If the working path always is the preferred path, this path will be If the working path always is the preferred path, this path will be
used whenever it is available. Thus, in the event of a fault on this used whenever it is available. Thus, in the event of a fault on this
path, its unused resources will not be reclaimed by the network on path, its unused resources will not be reclaimed by the network on
failure. If the working path has a fault, traffic is switched to the failure. If the working path has a fault, traffic is switched to the
recovery path. In the revertive mode of operation, when the recovery path. In the revertive mode of operation, when the
preferred path is restored the traffic is automatically switched back preferred path is restored the traffic is automatically switched back
to it. to it.
There are a number of implications to pinned working and recovery There are a number of implications to pinned working and recovery
skipping to change at page 25, line 49 skipping to change at page 26, line 4
failure. If the working path has a fault, traffic is switched to the failure. If the working path has a fault, traffic is switched to the
recovery path. In the revertive mode of operation, when the recovery path. In the revertive mode of operation, when the
preferred path is restored the traffic is automatically switched back preferred path is restored the traffic is automatically switched back
to it. to it.
There are a number of implications to pinned working and recovery There are a number of implications to pinned working and recovery
paths: paths:
- upon failure and traffic moved to recovery path, the traffic is - upon failure and traffic moved to recovery path, the traffic is
unprotected until such time as the path defect in the original unprotected until such time as the path defect in the original
working path is repaired and that path restored to service. working path is repaired and that path restored to service.
- upon failure and traffic moved to recovery path, the resources - upon failure and traffic moved to recovery path, the resources
associated with the original path remain reserved. associated with the original path remain reserved.
4.8.1.2 Non-revertive Mode 4.8.1.2 Non-revertive Mode
In the non-revertive mode of operation, there is no preferred path or In the non-revertive mode of operation, there is no preferred path or
it may be desirable to minimize further disruption of the service it may be desirable to minimize further disruption of the service
brought on by a revertive switching operation. A switch-back to the brought on by a revertive switching operation. A switch-back to the
original working path is not desired or not possible since 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 original path may no longer exist after the occurrence of a fault on
that path. that path.
If there is a fault on the working path, traffic is switched to the 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 recovery path. When or if the faulty path (the originally working
path) is restored, it may become the recovery path (either by path) is restored, it may become the recovery path (either by
skipping to change at page 28, line 5 skipping to change at page 28, line 14
II. Priority Attribute: II. Priority Attribute:
The recovery path has a priority attribute just like the working path The recovery path has a priority attribute just like the working path
(i.e., the priority attribute of the associated traffic trunks). It (i.e., the priority attribute of the associated traffic trunks). It
can have the same priority as the working path or lower priority. can have the same priority as the working path or lower priority.
III. Preemption Attribute: III. Preemption Attribute:
The recovery path can have the same preemption attribute as the The recovery path can have the same preemption attribute as the
working path or a lower one. working path or a lower one.
5. MPLS Recovery Features 5. MPLS Recovery Features
The following features are desirable from an operational point of The following features are desirable from an operational point of
view: view:
I. It is desirable that MPLS recovery provides an option to identify I. It is desirable that MPLS recovery provides an option to identify
protection groups (PPGs) and protection portions (PTPs). protection groups (PPGs) and protection portions (PTPs).
II. Each PSL should be capable of performing MPLS recovery upon the II. Each PSL should be capable of performing MPLS recovery upon the
detection of the impairments or upon receipt of notifications of detection of the impairments or upon receipt of notifications of
impairments. impairments.
skipping to change at page 28, line 35 skipping to change at page 28, line 44
original working path after the fault is corrected or a switchover to original working path after the fault is corrected or a switchover to
a new working path, upon the discovery or establishment of a more a new working path, upon the discovery or establishment of a more
optimal working path. optimal working path.
V. The recovery model should take into consideration path merging at V. The recovery model should take into consideration path merging at
intermediate LSRs. If a fault affects the merged segment, all the intermediate LSRs. If a fault affects the merged segment, all the
paths sharing that merged segment should be able to recover. paths sharing that merged segment should be able to recover.
Similarly, if a fault affects a non-merged segment, only the path Similarly, if a fault affects a non-merged segment, only the path
that is affected by the fault should be recovered. that is affected by the fault should be recovered.
6. Comparison Criteria 6. Comparison Criteria
Possible criteria to use for comparison of MPLS-based recovery Possible criteria to use for comparison of MPLS-based recovery
schemes are as follows: schemes are as follows:
Recovery Time Recovery Time
We define recovery time as the time required for a recovery path to We define recovery time as the time required for a recovery path to
be activated (and traffic flowing) after a fault. Recovery Time is be activated (and traffic flowing) after a fault. Recovery Time is
the sum of the Fault Detection Time, Hold-off Time, Notification the sum of the Fault Detection Time, Hold-off Time, Notification
Time, Recovery Operation Time, and the Traffic Restoration Time. In Time, Recovery Operation Time, and the Traffic Restoration Time. In
skipping to change at page 30, line 43 skipping to change at page 30, line 53
IV. Percentage of coverage: dependent on a scheme and its IV. Percentage of coverage: dependent on a scheme and its
implementation, a certain percentage of faults may be covered. This implementation, a certain percentage of faults may be covered. This
may be subdivided into percentage of link faults and percentage of may be subdivided into percentage of link faults and percentage of
node faults. node faults.
V. The number of protected paths may effect how fast the total set of V. The number of protected paths may effect how fast the total set of
paths affected by a fault could be recovered. The ratio of protected paths affected by a fault could be recovered. The ratio of protected
is n/N, where n is the number of protected paths and N is the total is n/N, where n is the number of protected paths and N is the total
number of paths. number of paths.
7. Security Considerations 7. Security Considerations
The MPLS recovery that is specified herein does not raise any The MPLS recovery that is specified herein does not raise any
security issues that are not already present in the MPLS security issues that are not already present in the MPLS
architecture. architecture.
8. Intellectual Property Considerations 8. Intellectual Property Considerations
The IETF has been notified of intellectual property rights claimed in The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
9. Acknowledgements 9. Acknowledgements
We would like to thank members of the MPLS WG mailing list for their We would like to thank members of the MPLS WG mailing list for their
suggestions on the earlier versions of this draft. In particular, suggestions on the earlier versions of this draft. In particular,
Bora Akyol, Dave Allan, Dave Danenberg, Sharam Davari, and Neil Bora Akyol, Dave Allan, Dave Danenberg, Sharam Davari, and Neil
Harrison whose suggestions and comments were very helpful in revising Harrison whose suggestions and comments were very helpful in revising
the document. the document.
The editors would like to give very special thanks to Curtis The editors would like to give very special thanks to Curtis
Villamizar for his careful and extremely thorough reading of the Villamizar for his careful and extremely thorough reading of the
document and for taking the time to provide numerous suggestions, document and for taking the time to provide numerous suggestions,
which were very helpful in the last couple of revisions of the which were very helpful in the last couple of revisions of the
document. document.
10. EditorsÆ Addresses 10. Editors' Addresses
Vishal Sharma Fiffi Hellstrand Vishal Sharma Fiffi Hellstrand
Metanoia, Inc. Nortel Networks Metanoia, Inc. Nortel Networks
1600 Villa Street, Unit 352 St Eriksgatan 115 1600 Villa Street, Unit 352 St Eriksgatan 115
Mountain View, CA 94041-1174 PO Box 6701 Mountain View, CA 94041-1174 PO Box 6701
Phone: (650) 386-6723 113 85 Stockholm, Sweden Phone: (650) 386-6723 113 85 Stockholm, Sweden
v.sharma@ieee.org Phone: +46 8 5088 3687 v.sharma@ieee.org Phone: +46 8 5088 3687
Fiffi@nortelnetworks.com Fiffi@nortelnetworks.com
11. References 11. References
 End of changes. 40 change blocks. 
98 lines changed or deleted 103 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/