GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3469

Network Working Group V. Sharma, Ed. Request for Comments: 3469 Metanoia, Inc. Category: Informational F. Hellstrand, Ed.

                                                       Nortel Networks
                                                         February 2003
Framework for Multi-Protocol Label Switching (MPLS)-based Recovery

Status of this Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

 Multi-protocol label switching (MPLS) integrates the label swapping
 forwarding paradigm with network layer routing.  To deliver reliable
 service, MPLS requires a set of procedures to provide protection of
 the traffic carried on different paths.  This requires that the label
 switching routers (LSRs) support fault detection, fault notification,
 and fault recovery mechanisms, and that MPLS signaling support the
 configuration of recovery.  With these objectives in mind, this
 document specifies a framework for MPLS based recovery.  Restart
 issues are not included in this framework.

Table of Contents

 1.   Introduction................................................2
      1.1.  Background............................................3
      1.2.  Motivation for MPLS-Based Recovery....................4
      1.3.  Objectives/Goals......................................5
 2.   Overview....................................................6
      2.1.  Recovery Models.......................................7
            2.1.1   Rerouting.....................................7
            2.1.2   Protection Switching..........................8
      2.2.  The Recovery Cycles...................................8
            2.2.1   MPLS Recovery Cycle Model.....................8
            2.2.2   MPLS Reversion Cycle Model...................10
            2.2.3   Dynamic Re-routing Cycle Model...............12
            2.2.4   Example Recovery Cycle.......................13
      2.3.  Definitions and Terminology..........................14
            2.3.1   General Recovery Terminology.................14

Sharma & Hellstrand Informational [Page 1] RFC 3469 Framework for MPLS-based Recovery February 2003

            2.3.2   Failure Terminology..........................17
      2.4.  Abbreviations........................................18
 3.   MPLS-based Recovery Principles.............................18
      3.1.  Configuration of Recovery............................19
      3.2.  Initiation of Path Setup.............................19
      3.3.  Initiation of Resource Allocation....................20
            3.3.1   Subtypes of Protection Switching.............21
      3.4.  Scope of Recovery....................................21
            3.4.1   Topology.....................................21
            3.4.2   Path Mapping.................................24
            3.4.3   Bypass Tunnels...............................25
            3.4.4   Recovery Granularity.........................25
            3.4.5   Recovery Path Resource Use...................26
      3.5.  Fault Detection......................................26
      3.6.  Fault Notification...................................27
      3.7.  Switch-Over Operation................................28
            3.7.1   Recovery Trigger.............................28
            3.7.2   Recovery Action..............................29
      3.8.  Post Recovery Operation..............................29
            3.8.1   Fixed Protection Counterparts................29
            3.8.2   Dynamic Protection Counterparts..............30
            3.8.3   Restoration and Notification.................31
            3.8.4   Reverting to Preferred Path
                    (or Controlled Rearrangement)................31
      3.9.  Performance..........................................32
 4.   MPLS Recovery Features.....................................32
 5.   Comparison Criteria........................................33
 6.   Security Considerations....................................35
 7.   Intellectual Property Considerations.......................36
 8.   Acknowledgements...........................................36
 9.   References.................................................36
      9.1   Normative References.................................36
      9.2   Informative References...............................37
 10.  Contributing Authors.......................................37
 11.  Authors' Addresses.........................................39
 12.  Full Copyright Statement...................................40

1. Introduction

 This memo describes a framework for MPLS-based recovery.  We provide
 a detailed taxonomy of recovery terminology, and discuss the
 motivation for, the objectives of, and the requirements for MPLS-
 based recovery. We outline principles for MPLS-based recovery, and
 also provide comparison criteria that may serve as a basis for
 comparing and evaluating different recovery schemes.

Sharma & Hellstrand Informational [Page 2] RFC 3469 Framework for MPLS-based Recovery February 2003

 At points in the document, we provide some thoughts about the
 operation or viability of certain recovery objectives.  These should
 be viewed as the opinions of the authors, and not the consolidated
 views of the IETF.  The document is informational and it is expected
 that a standards track document will be developed in the future to
 describe a subset of this document as to meet the needs currently
 specified by the TE WG.

1.1. Background

 Network routing deployed today is focused primarily on connectivity,
 and typically supports only one class of service, the best effort
 class.  Multi-protocol label switching [RFC3031], on the other hand,
 by integrating forwarding based on label-swapping of a link local
 label with network layer routing allows flexibility in the delivery
 of new routing services.  MPLS allows for using such media-specific
 forwarding mechanisms as label swapping.  This enables some
 sophisticated features such as quality-of-service (QoS) and traffic
 engineering [RFC2702] to be implemented more effectively.  An
 important component of providing QoS, however, is the ability to
 transport data reliably and efficiently.  Although the current
 routing algorithms are robust and survivable, the amount of time they
 take to recover from a fault can be significant, in the order of
 several seconds (for interior gateway protocols (IGPs)) or minutes
 (for exterior gateway protocols, such as the Border Gateway Protocol
 (BGP)), causing disruption of service for some applications in the
 interim.  This is unacceptable in situations where the aim is to
 provide a highly reliable service, with recovery times that are in
 the order of seconds down to 10's of milliseconds.  IP routing may
 also not be able to provide bandwidth recovery, where the objective
 is to provide not only an alternative path, but also bandwidth
 equivalent to that available on the original path.  (For some recent
 work on bandwidth recovery schemes, the reader is referred to [MPLS-
 BACKUP].)  Examples of such applications are Virtual Leased Line
 services, Stock Exchange data services, voice traffic, video services
 etc, i.e., every application that gets a disruption in service long
 enough to not fulfill service agreements or the required level of
 quality.
 MPLS recovery may be motivated by the notion that there are
 limitations to improving the recovery times of current routing
 algorithms.  Additional improvement can be obtained by augmenting
 these algorithms with MPLS recovery mechanisms [MPLS-PATH].  Since
 MPLS is a possible technology of choice in future IP-based transport
 networks, it is useful that MPLS be able to provide protection and
 restoration of traffic.  MPLS may facilitate the convergence of
 network functionality on a common control and management plane.
 Further, a protection priority could be used as a differentiating

Sharma & Hellstrand Informational [Page 3] RFC 3469 Framework for MPLS-based Recovery February 2003

 mechanism for premium services that require high reliability, such as
 Virtual Leased Line services, and high priority voice and video
 traffic.  The remainder of this document provides a framework for
 MPLS based recovery.  It is focused at a conceptual level and is
 meant to address motivation, objectives and requirements.  Issues of
 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

 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 and provide a
 recovery option without an intervening SONET layer or optical
 protection.  This would facilitate the construction of IP-over-WDM
 networks that request a fast recovery ability (Note that what is
 meant here is the transport of IP traffic over WDM links, not the
 Generalized MPLS, or GMPLS, control of a WDM link).
 The need for MPLS-based recovery arises because of the following:
 I.   Layer 3 or IP rerouting may be too slow for a core MPLS network
      that needs to support recovery times that are smaller than the
      convergence times of IP routing protocols.
 II.  Layer 3 or IP rerouting does not provide the ability to provide
      bandwidth protection to specific flows (e.g., voice over IP,
      virtual leased line services).
 III. Layer 0 (for example, optical layer) or Layer 1 (for example,
      SONET) mechanisms may be wasteful use of resources.
 IV.  The granularity at which the lower layers may be able to protect
      traffic may be too coarse for traffic that is switched using
      MPLS-based mechanisms.
 V.   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.  Further, this may
      prevent the lower layers from providing restoration based on the
      traffic's needs.  For example, fast restoration for traffic that
      needs it, and slower restoration (with possibly more optimal use
      of resources) for traffic that does not require fast

Sharma & Hellstrand Informational [Page 4] RFC 3469 Framework for MPLS-based Recovery February 2003

      restoration.  In networks where the latter class of traffic is
      dominant, providing fast restoration to all classes of traffic
      may not be cost effective from a service provider's perspective.
 VI.  MPLS has desirable attributes when applied to the purpose of
      recovery for connectionless networks.  Specifically that an LSP
      is source routed and a forwarding path for recovery can be
      "pinned" and is not affected by transient instability in SPF
      routing brought on by failure scenarios.
 VII. Establishing interoperability of protection mechanisms between
      routers/LSRs from different vendors in IP or MPLS networks is
      desired to enable recovery mechanisms to work in a multivendor
      environment, and to enable the transition of certain protected
      services to an MPLS core.

1.3. Objectives/Goals

 The following are some important goals for MPLS-based recovery.
 I.    MPLS-based recovery mechanisms may be subject to the traffic
       engineering goal of optimal use of resources.
 II.   MPLS based recovery mechanisms should aim to facilitate
       restoration times that are sufficiently fast for the end user
       application.  That is, that better match the end-user's
       application requirements.  In some cases, this may be as short
       as 10s of milliseconds.
 We observe that I and II may be conflicting objectives, and a trade
 off may exist between them.  The optimal choice depends on the end-
 user application's sensitivity to restoration time and the cost
 impact of introducing restoration in the network, as well as the
 end-user application's sensitivity to cost.
 III.  MPLS-based recovery should aim to maximize network reliability
       and availability.  MPLS-based recovery of traffic should aim to
       minimize the number of single points of failure in the MPLS
       protected domain.
 IV.   MPLS-based recovery should aim to enhance the reliability of
       the protected traffic while minimally or predictably degrading
       the traffic carried by the diverted resources.
 V.    MPLS-based recovery techniques should aim to be applicable for
       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

Sharma & Hellstrand Informational [Page 5] RFC 3469 Framework for MPLS-based Recovery February 2003

       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.
 VI.   MPLS-based recovery techniques may be applicable for an entire
       end-to-end path or for segments of an end-to-end path.
 VII.  MPLS-based recovery mechanisms should aim to take into
       consideration the recovery actions of lower layers.  MPLS-based
       mechanisms should not trigger lower layer protection switching
       nor should MPLS-based mechanisms be triggered when lower layer
       switching has or may imminently occur.
 VIII. MPLS-based recovery mechanisms should aim to minimize the loss
       of data and packet reordering during recovery operations.  (The
       current MPLS specification itself has no explicit requirement
       on reordering.)
 IX.   MPLS-based recovery mechanisms should aim to minimize the state
       overhead incurred for each recovery path maintained.
 X.    MPLS-based recovery mechanisms should aim to minimize the
       signaling overhead to setup and maintain recovery paths and to
       notify failures.
 XI.   MPLS-based recovery mechanisms should aim to preserve the
       constraints on traffic after switchover, if desired.  That is,
       if desired, the recovery path should meet the resource
       requirements of, and achieve the same performance
       characteristics as, the working path.
 We observe that some of the above are conflicting goals, and real
 deployment will often involve engineering compromises based on a
 variety of factors such as cost, end-user application requirements,
 network efficiency, complexity involved, and revenue considerations.
 Thus, these goals are subject to tradeoffs based on the above
 considerations.

2. Overview

 There are several options for providing protection of traffic.  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.
 Generally network operators aim to provide the fastest, most stable,
 and the best protection mechanism that can be provided at a
 reasonable cost.  The higher the levels of protection, the more the

Sharma & Hellstrand Informational [Page 6] RFC 3469 Framework for MPLS-based Recovery February 2003

 resources 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 Virtual Leased Line
 (VLL) service or real-time applications like Voice over IP (VoIP) may
 be supported using link/node protection together with pre-
 established, pre-reserved path protection.  Best effort traffic, on
 the other hand, may use path protection that is established on demand
 or may 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 two basic models for path recovery: rerouting and
 protection switching.
 Protection switching and rerouting, as defined below, may be used
 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.

2.1.1 Rerouting

 Recovery by rerouting is defined as establishing new paths or path
 segments on demand for restoring traffic after the occurrence of a
 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.
 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.
 In terms of the principles defined in section 3, reroute recovery
 employs paths established-on-demand with resources reserved-on-
 demand.

Sharma & Hellstrand Informational [Page 7] RFC 3469 Framework for MPLS-based Recovery February 2003

2.1.2 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.  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 employs
 pre-established recovery paths, and, if resource reservation is
 required on the recovery path, pre-reserved resources.  The various
 sub-types of protection switching are detailed in Section 4.4 of this
 document.

2.2. The Recovery Cycles

 There are three defined recovery cycles: the MPLS Recovery Cycle, 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 cycles to achieve an optimized network
 again.  The reversion cycle applies for explicitly routed traffic
 that does not rely on any dynamic routing protocols to converge.  The
 dynamic re-routing cycle applies for traffic that is forwarded based
 on hop-by-hop routing.

2.2.1 MPLS Recovery Cycle Model

 The MPLS recovery cycle model is illustrated in Figure 1. Definitions
 and a key to abbreviations follow.
  1. -Network Impairment

| –Fault Detected

  |    |    --Start of Notification
  |    |    |    -- Start of Recovery Operation
  |    |    |    |    --Recovery Operation Complete
  |    |    |    |    |    --Path Traffic Recovered
  |    |    |    |    |    |
  |    |    |    |    |    |
  v    v    v    v    v    v
 ----------------------------------------------------------------
  | T1 | T2 | T3 | T4 | T5 |
 Figure 1. MPLS Recovery Cycle Model

Sharma & Hellstrand Informational [Page 8] RFC 3469 Framework for MPLS-based Recovery February 2003

 The various timing measures used in the model are described below.
 T1   Fault Detection Time
 T2   Fault Hold-off Time
 T3   Fault Notification Time
 T4   Recovery Operation Time
 T5   Traffic Recovery Time
 Definitions of the recovery cycle times are as follows:
 Fault Detection Time
    The time between the occurrence of a network impairment and the
    moment the fault is detected by MPLS-based recovery mechanisms.
    This time may be highly dependent on lower layer protocols.
 Fault Hold-Off 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 Fault Hold-off Time may be zero.
    Note: The Fault Hold-Off Time may occur after the Fault
    Notification Time interval if the node responsible for the
    switchover, the Path Switch LSR (PSL), rather than the detecting
    LSR, is configured to wait.
 Fault Notification Time
    The time between initiation of a Fault Indication Signal (FIS) by
    the 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.
    Note: If the PSL detects the fault itself, there still may be a
    Fault Hold-Off Time period between detection and the start of the
    recovery operation.
 Recovery Operation Time
    The time between the first and last recovery actions.  This may
    include message exchanges between the PSL and PML (Path Merge LSR)
    to coordinate recovery actions.

Sharma & Hellstrand Informational [Page 9] RFC 3469 Framework for MPLS-based Recovery February 2003

 Traffic Recovery Time
    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.

2.2.2 MPLS Reversion Cycle Model

 Protection switching, revertive mode, requires the traffic to be
 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.
  1. -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|
 Figure 2. MPLS Reversion Cycle Model
 The various timing measures used in the model are described below.
 T7   Fault Clearing Time
 T8   Clear Hold-Off Time
 T9   Clear Notification Time
 T10  Reversion Operation Time
 T11  Traffic Reversion Time
 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.

Sharma & Hellstrand Informational [Page 10] RFC 3469 Framework for MPLS-based Recovery February 2003

 Definitions of the reversion cycle times are as follows:
 Fault Clearing Time
    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.
 Clear Hold-Off Time
    The configured waiting time between the clearing of a fault and
    MPLS-based recovery action(s).  Waiting time may be needed to
    ensure that the path is stable and to avoid flapping in cases
    where a fault is intermittent.  The Clear Hold-Off Time may be
    zero.
    Note: The Clear Hold-Off Time may occur after the Clear
    Notification Time interval if the PSL is configured to wait.
 Clear Notification Time
    The time between initiation of a Fault Recovery Signal (FRS) by
    the LSR clearing the fault and the time at which the path switch
    LSR begins the reversion operation.  This is zero if the PSL
    clears the fault itself.
    Note: If the PSL clears the fault itself, there still may be a
    Clear Hold-off Time period between fault clearing and the start of
    the reversion operation.
 Reversion Operation Time
    The time between the first and last reversion actions.  This may
    include message exchanges between the PSL and PML to coordinate
    reversion actions.
 Traffic Reversion Time
    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).
    In practice, the most interesting times in the reversion cycle are
    the Clear Hold-off Time and the Reversion Operation Time together
    with Traffic Reversion Time (or some other measure of traffic

Sharma & Hellstrand Informational [Page 11] RFC 3469 Framework for MPLS-based Recovery February 2003

    disruption).  The first interval is to ensure stability of the
    repaired path and the latter one is to minimize disruption time
    while the reversion action is in progress.
    Given that both paths are available, it is better to wait to have
    a well-controlled switch-back with minimal disruption than have an
    immediate operation that may cause new faults to be introduced
    (except, perhaps, when the recovery path is unable to offer a
    quality of service comparable to the preferred path).

2.2.3 Dynamic Re-routing Cycle Model

 Dynamic rerouting aims to bring the IP network to a stable state
 after a network impairment has occurred.  A re-optimized network is
 achieved after the routing protocols have converged, and the traffic
 is moved from a recovery path to a (possibly) new working path.  The
 steps involved in this mode are illustrated in Figure 3.
 Note that the cycle shown below may be overlaid on the recovery cycle
 shown 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 occurs if 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.
  1. -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 |
 Figure 3. Dynamic Rerouting Cycle Model
 The various timing measures used in the model are described below.
 T12  Network Route Convergence Time
 T13  Hold-down Time (optional)
 T14  Switchover Operation Time
 T15  Traffic Restoration Time

Sharma & Hellstrand Informational [Page 12] RFC 3469 Framework for MPLS-based Recovery February 2003

 Network Route Convergence Time
    We define the network route convergence time as the time taken for
    the network routing protocols to converge and for the network to
    reach a stable state.
 Holddown Time
    We define the holddown period as a bounded time for which a
    recovery path must be used.  In some scenarios it may be difficult
    to determine 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.
 Switchover Operation Time
    The time between the first and last switchover actions.  This may
    include message exchanges between the PSL and PML to coordinate
    the switchover actions.
 Traffic Restoration Time
    The time between the last restoration action and the time that
    traffic (if present) is completely restored on the new preferred
    path.

2.2.4 Example Recovery Cycle

 As an example of the recovery cycle, we present a sequence of events
 that occur after a network impairment occurs and when a protection
 switch is followed by dynamic rerouting.
    I. Link or path fault occurs
   II. Signaling initiated (FIS) for the detected fault
  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 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.

Sharma & Hellstrand Informational [Page 13] RFC 3469 Framework for MPLS-based Recovery February 2003

2.3. Definitions and Terminology

 This document assumes the terminology given in [RFC3031], and, in
 addition, introduces the following new terms.

2.3.1 General Recovery Terminology

 Re-routing
    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.
 Protection Switching
    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.
 Working Path
    The protected path that carries traffic before the occurrence of a
    fault.  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.
 Recovery Path
    The path by which traffic is restored after the occurrence of a
    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,
    and protection path.

Sharma & Hellstrand Informational [Page 14] RFC 3469 Framework for MPLS-based Recovery February 2003

 Protection Counterpart
    The "other" path when discussing pre-planned protection switching
    schemes.  The protection counterpart for the working path is the
    recovery path and vice-versa.
 Path Switch LSR (PSL)
    An LSR that is responsible for switching or replicating the
    traffic between the working path and the recovery path.
 Path Merge LSR (PML)
    An LSR that is responsible for receiving the recovery path
    traffic, and either merging the traffic back onto the working
    path, or, if it is itself the destination, passing the traffic on
    to the higher layer protocols.
 Point of Repair (POR)
    An LSR that is setup for performing MPLS recovery.  In other
    words, an LSR that is responsible for effecting the repair of an
    LSP.  The POR, for example, can be a PSL or a PML, depending on
    the type of recovery scheme employed.
 Intermediate LSR
    An LSR on a working or recovery path that is neither a PSL nor a
    PML for that path.
 Path Group (PG)
    A logical bundling of multiple working paths, each of which is
    routed identically between a Path Switch LSR and a Path Merge LSR.
 Protected Path Group (PPG)
    A path group that requires protection.
 Protected Traffic Portion (PTP)
    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.

Sharma & Hellstrand Informational [Page 15] RFC 3469 Framework for MPLS-based Recovery February 2003

 Bypass Tunnel
    A path that serves to back up a set of working paths using the
    label stacking approach [RFC3031].  The working paths and the
    bypass tunnel must all share the same path switch LSR (PSL) and
    the path merge LSR (PML).
 Switch-Over
    The process of switching the traffic from the path that the
    traffic 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).
 Switch-Back
    The process of returning the traffic from one or more recovery
    paths back to the working path(s).
 Revertive Mode
    A recovery mode in which traffic is automatically switched back
    from the recovery path to the original working path upon the
    restoration of the working path to a fault-free condition.  This
    assumes a failed working path does not automatically surrender
    resources to the network.
 Non-revertive Mode
    A recovery mode in which traffic is not automatically switched
    back 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, i.e., is surrendered to the network.)
 MPLS Protection Domain
    The set of LSRs over which a working path and its corresponding
    recovery path are routed.
 MPLS Protection Plan
    The set of all LSP protection paths and the mapping from working
    to protection paths deployed in an MPLS protection domain at a
    given time.

Sharma & Hellstrand Informational [Page 16] RFC 3469 Framework for MPLS-based Recovery February 2003

 Liveness Message
    A message exchanged periodically between two adjacent LSRs that
    serves as a link probing mechanism.  It provides an integrity
    check of the forward and the backward directions of the link
    between the two LSRs as well as a check of neighbor aliveness.
 Path Continuity Test
    A test that verifies the integrity and continuity of a path or
    path segment.  The details of such a test are beyond the scope of
    this document.  (This could be accomplished, for example, by
    transmitting a control message along the same links and nodes as
    the data traffic or similarly could be measured by the absence of
    traffic and by providing feedback.)

2.3.2 Failure Terminology

 Path Failure (PF)
    Path failure is a fault detected by MPLS-based recovery
    mechanisms, which is defined as the failure of the liveness
    message test or a path continuity test, which indicates that path
    connectivity is lost.
 Path Degraded (PD)
    Path degraded is a fault detected by MPLS-based recovery
    mechanisms that indicates that the quality of the path is
    unacceptable.
 Link Failure (LF)
    A lower layer fault indicating that link continuity is lost.  This
    may be communicated to the MPLS-based recovery mechanisms by the
    lower layer.
 Link Degraded (LD)
    A lower layer indication to MPLS-based recovery mechanisms that
    the link is performing below an acceptable level.
 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 (the POR).  The FIS is transmitted

Sharma & Hellstrand Informational [Page 17] RFC 3469 Framework for MPLS-based Recovery February 2003

    periodically by the node/nodes closest to the point of failure,
    for some configurable length of time or until the transmitting
    node receives an acknowledgement from its neighbor.
 Fault Recovery Signal (FRS)
    A signal that indicates a fault along a working path has been
    repaired.  Again, like the FIS, it is relayed by each intermediate
    LSR to its upstream or downstream neighbor, until is reaches the
    LSR that performs recovery of the original path.  The FRS is
    transmitted periodically by the node/nodes closest to the point of
    failure, for some configurable length of time or until the
    transmitting node receives an acknowledgement from its neighbor.

2.4. Abbreviations

 FIS:   Fault Indication Signal.
 FRS:   Fault Recovery Signal.
 LD:    Link Degraded.
 LF:    Link Failure.
 PD:    Path Degraded.
 PF:    Path Failure.
 PML:   Path Merge LSR.
 PG:    Path Group.
 POR:   Point of Repair.
 PPG:   Protected Path Group.
 PTP:   Protected Traffic Portion.
 PSL:   Path Switch LSR.

3. MPLS-based Recovery Principles

 MPLS-based recovery refers to the ability to effect quick and
 complete restoration of traffic affected by a fault in an MPLS-
 enabled network.  The fault may be detected on the IP layer or in
 lower layers over which IP traffic is transported.  Fastest MPLS
 recovery is assumed to be achieved with protection switching and may
 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
 SONET layer.  Further, MPLS-based recovery may provide bandwidth
 protection for paths that require it.  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.

Sharma & Hellstrand Informational [Page 18] RFC 3469 Framework for MPLS-based Recovery February 2003

3.1. Configuration of Recovery

 An LSR may support any or all of the following recovery options on a
 per-path basis:
 Default-recovery (No MPLS-based recovery enabled): 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).
 Recoverable (MPLS-based recovery enabled): This working path is
 recovered using one or more recovery paths, either via rerouting or
 via protection switching.

3.2. Initiation of Path Setup

 There are three options for the initiation of the recovery path
 setup.  The active and recovery paths may be established by using
 either RSVP-TE [RFC2205][RFC3209] or CR-LDP [RFC3212], or by any
 other means including SNMP.
 Pre-established:
    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, 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:
    A pre-established path need not be created, it may be pre-
    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
    determining 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.

Sharma & Hellstrand Informational [Page 19] RFC 3469 Framework for MPLS-based Recovery February 2003

 Established-on-Demand:
    This is the same as the rerouting option.  Here, a recovery path
    is established after a failure on its working path has been
    detected and notified to the PSL.  The recovery path may be pre-
    computed or computed on demand, which influences recovery times.

3.3. Initiation of Resource Allocation

 A recovery path may support the same traffic contract as the working
 path, or it may not.  We will distinguish these two situations by
 using different additive terms.  If the recovery path is capable of
 replacing the working path without degrading service, it will be
 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:
 Pre-reserved:
    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.
    The resources held by a set of recovery paths may be shared if
    they protect resources that are not simultaneously subject to
    failure.
 Reserved-on-Demand:
    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.
    Note that under both the options above, depending on the amount of
    resources reserved on the recovery path, it could either be an
    equivalent recovery path or a limited recovery path.

Sharma & Hellstrand Informational [Page 20] RFC 3469 Framework for MPLS-based Recovery February 2003

3.3.1 Subtypes of Protection Switching

 The resources (bandwidth, buffers, processing) on the recovery path
 may be used to carry either a copy of the working path traffic or
 extra traffic that is displaced when a protection switch occurs. This
 leads to two subtypes of protection switching.
 In 1+1 ("one plus one") protection, the resources (bandwidth,
 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.
 In 1:1 ("one for one") protection, the resources (if any) allocated
 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.
 This concept can be extended to 1:n (one for n) and m:n (m for n)
 protection.

3.4. Scope of Recovery

3.4.1 Topology

3.4.1.1 Local Repair

 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
 propagation.  In local repair (also known as local recovery), the
 node immediately upstream of the fault is the one to initiate
 recovery (either rerouting or protection switching).  Local repair
 can be of two types:

Sharma & Hellstrand Informational [Page 21] RFC 3469 Framework for MPLS-based Recovery February 2003

 Link Recovery/Restoration
    In this case, the recovery path may be configured to route around
    a 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 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.  Link recovery is
    potentially the fastest to perform the switchover, and can be
    effective in situations where certain path components are much
    more unreliable than others.
 Node Recovery/Restoration
    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.

3.4.1.2 Global Repair

 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
 of the faults occurring at the ingress node of the protected path
 segment.  In global repair, the POR 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).

Sharma & Hellstrand Informational [Page 22] RFC 3469 Framework for MPLS-based Recovery February 2003

 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
 recovery action.

3.4.1.3 Alternate Egress Repair

 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.
 This may simplify enhancing the reliability of implicitly constructed
 MPLS topologies.  A PSL may qualify LSP/FEC bindings as candidate
 recovery paths as simply link and node disjoint with the immediate
 downstream LSR of the working path.

3.4.1.4 Multi-Layer Repair

 Multi-layer repair broadens the network designer's tool set for 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
 document.

3.4.1.5 Concatenated Protection Domains

 A given service may cross multiple networks and these may employ
 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 document.

Sharma & Hellstrand Informational [Page 23] RFC 3469 Framework for MPLS-based Recovery February 2003

3.4.2 Path Mapping

 Path mapping refers to the methods of mapping traffic from a faulty
 working path on to the recovery path.  There are several options for
 this, as described below.  Note that the options below should be
 viewed as atomic terms that only describe how the working and
 protection paths are mapped to each other.  The issues of resource
 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 4.3.1..
 1-to-1 Protection
    In 1-to-1 protection the working path has a designated recovery
    path that is only to be used to recover that specific working
    path.
 n-to-1 Protection
    In n-to-1 protection, up to n working paths are protected using
    only one recovery path.  If the intent is to protect against any
    single fault on any of the working paths, the n working 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
    document.
 n-to-m Protection
    In n-to-m protection, up to n working paths are protected using m
    recovery paths.  Once again, if the intent is to protect against
    any 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 document.  n-to-m protection is for
    further study.
 Split Path Protection
    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

Sharma & Hellstrand Informational [Page 24] RFC 3469 Framework for MPLS-based Recovery February 2003

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

3.4.3 Bypass Tunnels

 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 [RFC2702].  In this case, one
 LSP (the tunnel) is established between the PSL and PML following an
 acceptable route and a number of recovery paths can be supported
 through the tunnel via label stacking.  It is not necessary to apply
 label stacking when using a bypass tunnel.  A bypass tunnel can be
 used with any of the path mapping options discussed in the previous
 section.
 As with recovery paths, the bypass tunnel may or may not have
 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 n-to-1 or n-to-m protection cases mentioned in Section
 3.4.2.

3.4.4 Recovery Granularity

 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.

3.4.4.1 Selective Traffic Recovery

 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
 requires protection is called a protected traffic portion (PTP).  A
 single path may carry different classes of traffic, with different
 protection requirements.  The protected portion of this traffic may
 be 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.

3.4.4.2 Bundling

 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

Sharma & Hellstrand Informational [Page 25] RFC 3469 Framework for MPLS-based Recovery February 2003

 (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

 In the case of pre-reserved recovery paths, there is the question of
 what use these resources may be put to when the recovery path is not
 in use.  There are two options:
 Dedicated-resource: If the recovery path resources are dedicated,
 they may not be used for anything except carrying the working
 traffic.  For example, in the case of 1+1 protection, the working
 traffic is always carried on the recovery path.  Even if the recovery
 path is not always carrying the working traffic, it may not be
 possible or desirable to allow other traffic to use these resources.
 Extra-traffic-allowed: 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.
 Shared-resource: A shared recovery resource is dedicated for use by
 multiple primary resources that (according to SRLGs) are not expected
 to fail simultaneously.

3.5. Fault Detection

 MPLS recovery is initiated after the detection of either a lower
 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 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 [MPLS-PATH].
 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

Sharma & Hellstrand Informational [Page 26] RFC 3469 Framework for MPLS-based Recovery February 2003

 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
 schemes/mechanisms that the path has connectivity, but that the
 quality of the connection is unacceptable.  This may be detected by a
 path performance monitoring mechanism, or some other mechanism for
 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
 packets at an interface, either due to label mismatch or due to TTL
 errors, for example.
 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
 supports detection and reporting of this fault (that is, any fault
 that indicates link failure e.g., SONET LOS (Loss of Signal)), this
 may be used by the MPLS recovery mechanism.  In some cases, using LF
 indications may provide faster fault detection than using only MPLS-
 based fault detection mechanisms.
 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.6. Fault Notification

 MPLS-based recovery relies on rapid and reliable notification of
 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 point of repair, POR) the node should send out a
 notification of the fault by transmitting a FIS to the POR.  This can
 take several forms:
 (i)  control plane messaging: relayed hop-by-hop along the path
      upstream of the failed LSP until a POR is reached.
 (ii) user plane messaging: sent downstream to the PML, which may take
      corrective action (as a POR for 1+1) or communicate with a POR
      upstream (for 1:n) by any of several means:
    -  control plane messaging
    -  user plane return path (either through a bi-directional LSP or
       via other means)

Sharma & Hellstrand Informational [Page 27] RFC 3469 Framework for MPLS-based Recovery February 2003

 Since the FIS is a control message, it should be transmitted with
 high priority to ensure that it propagates rapidly towards the
 affected POR(s).  Depending on how fault notification is configured
 in the LSRs of an MPLS domain, the FIS could be sent either as a
 Layer 2 or Layer 3 packet [MPLS-PATH].  The use of a Layer 2-based
 notification requires a Layer 2 path direct to the POR.  An example
 of a FIS could be the liveness message sent by a downstream LSR to
 its upstream neighbor, with an optional fault notification field set
 or it can be implicitly denoted by a teardown message.
 Alternatively, it could be a separate fault notification packet.  The
 intermediate LSR should identify which of its incoming links to
 propagate the FIS on.

3.7. Switch-Over Operation

3.7.1 Recovery Trigger

 The activation of an MPLS protection switch following the detection
 or notification of a fault requires a trigger mechanism at the PSL.
 MPLS protection switching may be initiated due to automatic inputs or
 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 to the POR via the FIS, which
 serves as the protection switch trigger at the POR.  MPLS protection
 switching in response to external commands results when the operator
 initiates a protection switch by a command to a POR (or alternatively
 by a configuration command to an intermediate LSR, which transmits
 the FIS towards the POR).
 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.

Sharma & Hellstrand Informational [Page 28] RFC 3469 Framework for MPLS-based Recovery February 2003

3.7.2 Recovery Action

 After a fault is detected or FIS is received by the POR, 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.

3.8. Post Recovery Operation

 When traffic is flowing on the recovery path, decisions can be made
 as to whether to let the traffic remain on the recovery path and
 consider it as a new working path or to do a switch back to the old
 or to a new working path.  This post recovery operation has two
 styles, one where the protection counterparts, i.e., the working and
 recovery path, are fixed or "pinned" to their routes, 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.

3.8.1 Fixed Protection Counterparts

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

3.8.1.1 Revertive Mode

 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
 path, its unused resources will not be reclaimed by the network on
 failure.  Resources here may include assigned labels, links,
 bandwidth etc.  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.
 There are a number of implications to pinned working and recovery
 paths:
  1. upon failure and after traffic has been moved to the recovery

path, the traffic is unprotected until such time as the path

     defect in the original working path is repaired and that path
     restored to service.

Sharma & Hellstrand Informational [Page 29] RFC 3469 Framework for MPLS-based Recovery February 2003

  1. upon failure and after traffic has been moved to the recovery

path, the resources associated with the original path remain

     reserved.

3.8.1.2 Non-revertive Mode

 In the non-revertive mode of operation, there is no preferred path or
 it may be desirable to minimize further disruption of the service
 brought on by a revertive switching operation.  A switch-back 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 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).
 In the non-revertive mode of operation, the working traffic may or
 may not be restored to a new optimal working path or to the original
 working path anyway.  This is because it might be useful, in some
 cases, to either: (a) administratively perform a protection switch
 back to the original working path after gaining further assurances
 about the integrity of the path, or (b) it may be acceptable to
 continue operation on the recovery path, or (c) it may be desirable
 to move the traffic to a new optimal working path that is calculated
 based on network topology and network policies.  Once a new working
 path has been defined, an associated recovery path may be setup.

3.8.2 Dynamic Protection Counterparts

 For dynamic protection counterparts when the traffic is switched over
 to a recovery path, the association between the original working path
 and the recovery path may no longer exist, since the original path
 itself may no longer exist after the fault.  Instead, when the
 network reaches a stable state following routing convergence, the
 recovery path may be switched over to a different preferred path
 either optimization based on the new network topology and associated
 information or based on pre-configured information.
 Dynamic protection counterparts assume that upon failure, the PSL or
 other network entity will establish new working paths if another
 switch-over will be performed.

Sharma & Hellstrand Informational [Page 30] RFC 3469 Framework for MPLS-based Recovery February 2003

3.8.3 Restoration and Notification

 MPLS restoration deals with returning the working traffic from the
 recovery path to the original or a new working path.  Restoration 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.
 For fixed counterparts in revertive mode, an LSR that detected the
 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.
 A similar scheme is used for dynamic counterparts where e.g., an
 update of topology and/or network convergence may trigger
 installation or setup of new working paths and may send notification
 to the PSL to perform a switch over.
 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 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 4.8.1, without leaving
 the recovery path unprotected.

3.8.4 Reverting to Preferred Path (or Controlled Rearrangement)

 In the revertive mode, "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.

Sharma & Hellstrand Informational [Page 31] RFC 3469 Framework for MPLS-based Recovery February 2003

3.9. Performance

 Resource/performance requirements for recovery paths should be
 specified in terms of the following attributes:
 I.   Resource Class Attribute:
      Equivalent Recovery Class: The recovery path has the same
      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
      performance guarantees as the working path.
      A.  Lower Class:
          The recovery path has lower resource requirements or less
          stringent performance requirements than the working path.
      B.  Best Effort Class:
          The recovery path is best effort.
 II.  Priority Attribute:
      The recovery path has a priority attribute just like the working
      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:
      The recovery path can have the same preemption attribute as the
      working path or a lower one.

4. MPLS Recovery Features

 The following features are desirable from an operational point of
 view:
 I.   It is desirable that MPLS recovery provides an option to
      identify protection groups (PPGs) and protection portions
      (PTPs).
 II.  Each PSL should be capable of performing MPLS recovery upon the
      detection of the impairments or upon receipt of notifications of
      impairments.
 III. A MPLS recovery method should not preclude manual protection
      switching commands.  This implies that it would be possible
      under administrative commands to transfer traffic from a working
      path to a recovery path, or to transfer traffic from a recovery

Sharma & Hellstrand Informational [Page 32] RFC 3469 Framework for MPLS-based Recovery February 2003

      path to a working path, once the working path becomes
      operational following a fault.
 IV.  A PSL may 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.
 V.   The recovery model should take into consideration path merging
      at 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.

5. Comparison Criteria

 Possible criteria to use for comparison of MPLS-based recovery
 schemes are as follows:
 Recovery Time
    We define recovery time as the time required for a recovery path
    to 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
    We define full restoration time as the time required for a
    permanent restoration.  This is the time required for traffic to
    be 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.
 Setup vulnerability
    The amount of time that a working path or a set of working paths
    is left unprotected during such tasks as recovery path computation
    and 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,

Sharma & Hellstrand Informational [Page 33] RFC 3469 Framework for MPLS-based Recovery February 2003

    Local Repair schemes have a topological correlation that cuts
    across working paths and Network Plan approaches have a
    correlation that impacts the entire network.
 Backup Capacity
    Recovery schemes may require differing amounts of "backup
    capacity" in the event of a fault.  This capacity will be
    dependent on the traffic characteristics of the network.  However,
    it may also be dependent on the particular protection plan
    selection algorithms as well as the signaling and re-routing
    methods.
 Additive Latency
    Recovery schemes may introduce additive latency for traffic.  For
    example, a recovery path may take many more hops than the working
    path.  This may be dependent on the recovery path selection
    algorithms.
 Quality of Protection
    Recovery schemes can be considered to encompass a spectrum of
    "packet survivability" which may range from "relative" to
    "absolute". Relative survivability may mean that the packet is on
    an equal footing with other traffic of, as an example, the same
    diff-serv code point (DSCP) in contending for the resources of the
    portion of the network that survives the failure.  Absolute
    survivability may mean that the survivability of the protected
    traffic has explicit guarantees.
 Re-ordering
    Recovery schemes may introduce re-ordering of packets.  Also the
    action of putting traffic back on preferred paths might cause
    packet re-ordering.
 State Overhead
    As the number of recovery paths in a protection plan grows, the
    state required to maintain them also grows.  Schemes may require
    differing numbers of paths to maintain certain levels of coverage,
    etc.  The state required may also depend on the particular scheme
    used for recovery.  The state overhead may be a function of
    several parameters.  For example,  the number of recovery paths
    and the number of the protected facilities (links, nodes, or
    shared link risk groups (SRLGs)).

Sharma & Hellstrand Informational [Page 34] RFC 3469 Framework for MPLS-based Recovery February 2003

 Loss
    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
    inevitable.
 Coverage
    Recovery schemes may offer various types of failover coverage.
    The total coverage may be defined in terms of several metrics:
 I.   Fault Types: Recovery schemes may account for only link faults
      or both node and link faults or also degraded service.  For
      example, a scheme may require more recovery paths to take node
      faults into account.
 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.
 III. Number of recovery paths: for a given fault, there may be one or
      more recovery paths.
 IV.  Percentage of coverage: dependent on a scheme and its
      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
      of paths affected by a fault could be recovered.  The ratio of
      protection is n/N, where n is the number of protected paths and
      N is the total number of paths.

6. Security Considerations

 The MPLS recovery that is specified herein does not raise any
 security issues that are not already present in the MPLS
 architecture.
 Confidentiality or encryption of information on the recovery path is
 outside the scope of this document, but any method designed to do
 this in other contexts may be used with the methods described in this
 document.

Sharma & Hellstrand Informational [Page 35] RFC 3469 Framework for MPLS-based Recovery February 2003

7. Intellectual Property Considerations

 The IETF has been notified of intellectual property rights claimed in
 regard to some or all of the specification contained in this
 document.  For more information consult the online list of claimed
 rights.

8. Acknowledgements

 We would like to thank members of the MPLS WG mailing list for their
 suggestions on the earlier versions of this document.  In particular,
 Bora Akyol, Dave Allan, Dave Danenberg, Sharam Davari, and Neil
 Harrison whose suggestions and comments were very helpful in revising
 the document.
 The editors would like to give very special thanks to Curtis
 Villamizar for his careful and extremely thorough reading of the
 document and for taking the time to provide numerous suggestions,
 which were very helpful in the last couple of revisions of the
 document.  Thanks are also due to Adrian Farrel for a through reading
 of the last version of the document, and to Jean-Phillipe Vasseur and
 Anna Charny for several useful editorial comments and suggestions,
 and for input on bandwidth recovery.

9. References

9.1 Normative

 [RFC3031]     Rosen, E., Viswanathan, A. and R. Callon,
               "Multiprotocol Label Switching Architecture", RFC 3031,
               January 2001.
 [RFC2702]     Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and
               J. McManus, "Requirements for Traffic Engineering Over
               MPLS", RFC 2702, September 1999.
 [RFC3209]     Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
               V. and G. Swallow, "RSVP-TE Extensions to RSVP for LSP
               Tunnels",  RFC 3209, December 2001.
 [RFC3212]     Jamoussi, B. (Ed.), Andersson, L., Callon, R., Dantu,
               R., Wu, L., Doolan, P., Worster, T., Feldman, N.,
               Fredette, A., Girish, M., Gray, E., Heinanen, J.,
               Kilty, T. and A. Malis, "Constraint-Based LSP Setup
               using LDP", RFC 3212, January 2002.

Sharma & Hellstrand Informational [Page 36] RFC 3469 Framework for MPLS-based Recovery February 2003

9.2 Informative

 [MPLS-BACKUP] Vasseur, J. P., Charny, A., LeFaucheur, F., and
               Achirica, "MPLS Traffic Engineering Fast reroute:
               backup tunnel path computation for bandwidth
               protection", Work in Progress.
 [MPLS-PATH]   Haung, C., Sharma, V., Owens, K., Makam, V. "Building
               Reliable MPLS Networks Using a Path Protection
               Mechanism", IEEE Commun. Mag., Vol. 40, Issue 3, March
               2002, pp. 156-162.
 [RFC2205]     Braden, R., Zhang, L., Berson, S., Herzog, S.,
               "Resource ReSerVation Protocol (RSVP) -- Version 1
               Functional Specification", RFC 2205, September 1997.

10. Contributing Authors

 This document was the collective work of several individuals over a
 period of three years.  The text and content of this document was
 contributed by the editors and the co-authors listed below. (The
 contact information for the editors appears in Section 11, and is not
 repeated below.)
 Ben Mack-Crane
 Tellabs Operations, Inc.
 1415 West Diehl Road
 Naperville, IL 60563
 Phone: (630) 798-6197
 EMail: Ben.Mack-Crane@tellabs.com
 Srinivas Makam
 Eshernet, Inc.
 1712 Ada Ct.
 Naperville, IL 60540
 Phone: (630) 308-3213
 EMail: Smakam60540@yahoo.com

Sharma & Hellstrand Informational [Page 37] RFC 3469 Framework for MPLS-based Recovery February 2003

 Ken Owens
 Edward Jones Investments
 201 Progress Parkway
 St. Louis, MO 63146
 Phone: (314) 515-3431
 EMail: ken.owens@edwardjones.com
 Changcheng Huang
 Carleton University
 Minto Center, Rm. 3082
 1125 Colonial By Drive
 Ottawa, Ont. K1S 5B6 Canada
 Phone: (613) 520-2600 x2477
 EMail: Changcheng.Huang@sce.carleton.ca
 Jon Weil
 Brad Cain
 Storigen Systems
 650 Suffolk Street
 Lowell, MA 01854
 Phone: (978) 323-4454
 EMail: bcain@storigen.com
 Loa Andersson
 EMail: loa@pi.se
 Bilel Jamoussi
 Nortel Networks
 3 Federal Street, BL3-03
 Billerica, MA 01821, USA
 Phone:(978) 288-4506
 EMail: jamoussi@nortelnetworks.com

Sharma & Hellstrand Informational [Page 38] RFC 3469 Framework for MPLS-based Recovery February 2003

 Angela Chiu
 AT&T Labs-Research
 200 Laurel Ave. Rm A5-1F13
 Middletown , NJ 07748
 Phone: (732) 420-9061
 EMail: chiu@research.att.com
 Seyhan Civanlar
 Lemur Networks, Inc.
 135 West 20th Street, 5th Floor
 New York, NY 10011
 Phone: (212) 367-7676
 EMail: scivanlar@lemurnetworks.com

11. Editors' Addresses

 Vishal Sharma (Editor)
 Metanoia, Inc.
 1600 Villa Street, Unit 352
 Mountain View, CA 94041-1174
 Phone: (650) 386-6723
 EMail: v.sharma@ieee.org
 Fiffi Hellstrand (Editor)
 Nortel Networks
 St Eriksgatan 115
 PO Box 6701
 113 85 Stockholm, Sweden
 Phone: +46 8 5088 3687
 EMail: fiffi@nortelnetworks.com

Sharma & Hellstrand Informational [Page 39] RFC 3469 Framework for MPLS-based Recovery February 2003

12. Full Copyright Statement

 Copyright (C) The Internet Society (2003).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Sharma & Hellstrand Informational [Page 40]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3469.txt · Last modified: 2003/02/06 19:40 (external edit)