Network Working Group                Ping Pan, Ed. (Juniper Networks)
Internet Draft                               Ping Pan, Ed  (Ciena Corp)
Expires: May 2003                        Der-Hwa Gan (Juniper Networks)
Expiration Date: July 2002
                                        George Swallow  (Cisco Systems)
Network Working Group
                                  Jean Philippe Vasseur (Cisco Systems)
                                          Dave Cooper (Global Crossing)
                                         Alia Atlas Atlas, Ed (Avici Systems)
                                            Markus Jork (Avici Systems)

           Fast Reroute Extensions to RSVP-TE for LSP Tunnels

              draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt

              draft-ietf-mpls-rsvp-lsp-fastreroute-01.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-Drafts. Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document defines extensions to and describes the use of RSVP
   [RSVP, RSVP-TE] to establish backup LSP tunnels for local repair of
   LSP tunnels.  These mechanisms enable the re-direction of traffic
   onto backup LSP tunnels in 10s of milliseconds in the event of a
   failure.

   Two methods are presented defined here. One is to setup  The one-to-one backup method creates
   detour LSPs
according to the requirements defined by the head-end users. The other
is to setup many-to-one bypass for each protected LSP using at each potential point of local
   repair.  The facility backup method creates a single bypass tunnel to backup
   protect a potential failure point; by taking advantage of MPLS label
   stacking, this bypass tunnel can protect a set of protected LSPs (making use of label stacking). that
   have similar backup constraints. Both methods can be used to protect
   links and nodes during network failure.  The described
use of behavior and
   extensions to RSVP allows allow LERs and LSRs to implement either or both one-to-one
   methods and many-to-one backups to
interoperate. interoperate in a mixed network.

Contents

    1  Introduction   .............................................  4
    2  Terminology  ...............................................  4
    3  Local Repair Techniques  ...................................  6
    3.1  One-to-one Backup  .......................................  6
    3.2  Facility Backup  .........................................  7
    4  RSVP Extensions  ...........................................  8
    4.1  FAST_REROUTE Object  .....................................  8
    4.2  DETOUR Object  ........................................... 11
    4.3  SESSION_ATTRIBUTE Flags  ................................. 12
    4.4  RRO IPv4/IPv6 Sub-Object Flags  .......................... 13
    5  Head-End Behavior  ......................................... 14
    6  Point of Local Repair Behavior  ............................ 15
    6.1  Signaling a Backup Path  ................................. 16
    6.1.1  Backup Path Identification: Sender-Template Specific ... 17
    6.1.2  Backup Path Identification: Path-Specific  ............. 18
    6.2  Procedures for Backup Path Computation  .................. 18
    6.3  Signaling Backups for One-To-One Protection  ............. 20
    6.3.1  Make-Before-Break with Detour LSPs  .................... 21
    6.3.2  Message Handling  ...................................... 21
    6.3.3  Local Reroute of Traffic Onto Detour LSP  .............. 22
    6.4  Signaling for Facility Protection  ....................... 23
    6.4.1  Discovering Downstream Labels  ......................... 23
    6.4.2  Procedures for the PLR before Local Repair  ............ 23
    6.4.3  Procedures for the PLR during Local Repair  ............ 23
    6.4.4  Processing backup tunnel's ERO  ........................ 24
    6.5  PLR Procedures During Local Repair  ...................... 25
    6.5.1  Notification of local repair  .......................... 25
    6.5.2  Revertive Behavior  .................................... 26
    7  Merge Node Behavior  ....................................... 27
    7.1  Handling Backup Path Messages Before Failure  ............ 27
    7.1.1  Merging Backup Paths using the Sender-Template
           Specific Method  ....................................... 28
    7.1.2  Merging Detours using Path-Specific Method  ............ 28
    7.1.2.1  An Example on Path Message Merging  .................. 29
    7.1.3  Message Handling for Merged Detours  ................... 30
    7.2  Handling Failures  ....................................... 30
    8  Behavior of all LSRs  ...................................... 31
    8.1  Merging Detours in Path-Specific Method  ................. 31
    9  Security Considerations  ................................... 32
   10  IANA Guidelines  ........................................... 32
   11  Intellectual Property Considerations  ...................... 32
   12  Full Copyright Statement  .................................. 32
   13  Acknowledgments  ........................................... 33
   14  References  ................................................ 33
   15  Author Information  ........................................ 33

1.  Introduction

   This document describes the use of extends RSVP [RSVP] to establish backup LSP tunnels
   for the local repair of LSP tunnels. By the term LSP tunnel
   we mean an explicitly routed LSP.  In this document, we often refer
   to LSPs.  In all cases we mean explicitly routed LSPs.  Applicability
   of the techniques discussed herein to LSPs which dynamically change
   their routes such as those used in unicast IGP routing  This technique is beyond the
   scope of this document.

   In order presented
   to meet the needs of real-time applications applications, such as voice over IP,
   for which it is highly desirable to be able to re-direct user
   traffic onto backup LSP tunnels in 10s of milliseconds.  The backup LSPs have
   to  This
   timing requirement can be placed satisfied by computing and signaling
   backup LSP tunnels in advance of failure and by re-directing
   traffic as close to the failure point as possible, since
   reporting possible.  In this way, the
   time for the redirection does not include any path computation or
   signaling delays, including delays to propagate failure
   notification between nodes may cost significant delay. LSRs.  The speed of repair made possible by
   the techniques and extensions described herein is the primary
   advantage of this method.  We use the term local repair when
   referring to techniques which accomplish this, and refer the to an
   explicitly routed LSP that which is associated to one or more backup
   tunnels provided with such protection as a
   protected LSP. There  These techniques are applicable only to explicitly
   routed LSPs; Application of the techniques discussed herein to LSPs
   which dynamically change their routes such as those used in unicast
   IGP routing is beyond the scope of this document.

   Section 2 covers new terminology used in this document.  The two
   basic strategies for
   setting up creating backup tunnels. These LSPs are one-to-one backup and facility
   backup.  One-to-one backup operates on described in Section
   3.  In Section 4, the basis of a backup LSP for
   each protected LSP.  The facility backup aims at using a single LSP protocol extensions to back up a set of protected LSPs.

1.1. One-to-one backup RSVP to support local
   protection are described.  In Section 5, the one behavior of an LER
   which wishes to one case, a label switched path request local protection for an LSP is established which
   intersects the original tunnel somewhere downstream presented.
   The behavior of the a potential point of
   link or node failure.  For each LSP which is backed up, another
   backup LSP local repair (PLR) is established.

             [R1]---[R2]-----[R3]----[R4]---[R5]
                        \           /
                         [R6]---[R7]

   For example, suppose that given in the simple topology above, R1 creates a
   tunnel
   Section 6; this describes how to R5 via the path [R1->R2->R3->R4->R5].  R2 can provide user
   traffic protection by creating a partial backup tunnel
   [R2->R6->R7->R4] which merges with determine the original tunnel
   [R1->R2->R3->R4->R5] at R4.  We refer a partial one-to-one backup
   tunnel [R2->R6->R7->R4] as a detour.

   To fully protect a LSP that traverses through N nodes, there could be
   as many as (N - 1) detours. To minimize processing overhead, it is
   desirable to merge detours back appropriate strategy
   to a main use for protecting an LSP wherever possible.

1.2. Facility backup

   A second means of backing up LSPs is and how to take advantage implement each of the label
   stack.  Instead
   strategies.  The behavior of creating a separate LSP for every backed-up LSP, merge node, the LSR where a
   single
   protected LSP is created which serves to and its backup up a set of LSPs.  We
   call such a LSP tunnel a bypass tunnel.

   The bypass tunnel must intersect the path of the original LSP(s)
   somewhere downstream of the point of local repair.  This of course
   implies that rejoin, is described in Section 7.
   Finally, the set required behavior of LSPs being backed up all pass through some
   common downstream node.  All LSPs which pass through other nodes in the point of
   local repair network is
   discussed in Section 8.

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and through this common node which do not also use the
   facilities involved "OPTIONAL" in the bypass tunnel are candidates for this set
   of LSPs.

   To effect the repair of the protected LSPs, packets belonging to a
   LSP are redirected onto the bypass tunnel.  An additional label
   representing the bypass tunnel is stacked onto the redirected
   packets.  At the penultimate hop of the bypass tunnel, the label for
   the bypass tunnel is popped off the stack, revealing the label which
   represents the LSP being backed up.

                [R8]
                    \
              [R1]---[R2]----[R3]----[R4]---[R5]
                         \\          //   \
                          [R6]===[R7]     [R9]

   In the above example, R2 in this case would build a bypass tunnel
   [R2->R6->R7->R4].  The doubled lines represent this tunnel.  The
   backup path for [R1->R2->R3->R4->R5] again rejoins the original path
   at R4, but its path is now [R1->R2->R4->R5] with the bypass tunnel as
   the connection between R2 and R4.

   In this example, the backup tunnel is a Next-Next-Hop (NNHOP) bypass
   tunnel.  That is, it bypasses a single node (R3) of the protected
   path.  NNHOP bypass tunnels may protect against Link (R2-R3) failure
   and/or Node (R3) failure as NHOP bypass tunnel only protects against
   link failure.

   The scalability improvement comes in that this bypass tunnel can also
   be used to backup LSPs from any of R1, or R2, R8 to any of R4, R5, or
   R9 which traverse the link R2->R3.

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document this
   document are to be interpreted as described in RFC2119 [RFC-WORDS].

   The reader is assumed to be familiar with the terminology in [RSVP]
   and [RSVP-TE].

      LSR - Label Switch Router

      LSP - An MPLS Label Switched Path Path.  In this document, an LSP
            will always refer to an explicitly routed LSP.

      Local Repair - Techniques used to repair LSP tunnels quickly
           when a node or link along the LSPs path fails.

     Protected LSP

      PLR - An Point of Local Repair. The head-end LSR of a backup tunnel
           or a detour LSP.

      One-to-one Backup - A local repair technique where a backup LSP
           is said to be separately created for each protected LSP at a given hop if
          it PLR.

      Facility Backup - A local repair technique where a bypass tunnel
           is used to protect one or more protected LSPs which
           traverse the PLR, the resource being protected and the
           Merge Point in that order.

      Protected LSP - An LSP is said to be protected at a given hop if
           it has one or multiple associated backup tunnels originating
           at that hop.

      Detour LSP - The LSP that is used to re-route traffic around
           a failure in one-to-one backup.

      Bypass Tunnel - An LSP that is used to protect a set of LSPs
           passing over a common facility.

      Backup Tunnel - The LSP that is used to backup up one of the many
           LSPs in many-to-one backup.

      NHOP Bypass Tunnel - Next-Hop Bypass Tunnel.  A backup tunnel
           which bypasses a single link of the protected LSP.

      NNHOP Bypass Tunnel - Next-Next-Hop Bypass Tunnel.  A backup
           tunnel which bypasses a single node of the protected LSP.

      Backup Path - The LSP that is responsible for backing up one
           protection LSP. A backup path refers to either a detour LSP
           or a backup tunnel.

     PLR - Point of Local Repair. The head-end of a backup tunnel or
          a detour LSP.

      MP - Merge Point. The LSR where one or more backup tunnels rejoin
           the path of the protected LSP, downstream of the potential
           failure. The same LSR may be both an MP and a PLR
           simultaneously.

      DMP - Detour Merge Point.  In the case of one-to-one backup, a Merge Point may
          also be
           this is an LSR where multiple detours converge and only one
           detour is signaled beyond that LSR; this type of merge point
          may be referred to as a Detour Merge Point.  A MP may also
          be a PLR. LSR.

      Reroutable LSP - Any LSP for which the head-end LSR requests
          for
           local protection. See Section 9.1 for more detail.

      CSPF - Constraint-based Shortest Path First.

3. RSVP Extensions

   We propose two additional objects, FAST_REROUTE and DETOUR, that
   extend RSVP-TE for fast-reroute signaling. The new objects are
   defined

      SRLG Disjoint - A path is considered to be backward compatible for LSRs that do not recognize them
   (Section 3.10 in [RSVP]).  Both objects can only be carried in RSVP
   Path messages.

   The SESSION_ATTRIBUTE and RECORD_ROUTE objects are also extended to
   support bandwidth and SRLG disjoint from a
         given link or node protection features:

   In many circumstances, it may be desirable for if the head-end LSR path does not
   only use any links or
         nodes which belong to signal an LSP the same SRLG as fast reroutable but also to specify to every
   PLR along its path that the LSP must be rerouted onto given link or
         node.

3.  Local Repair Techniques

   Two different techniques for local protection are presented here.
   The one-to-one backup technique has a PLR compute a separate backup path
   offering an equivalent bandwidth.

   It may be desirable to signal the need for the fast reroutable LSP to
   be node protected along its path. By node protected we mean that
   LSP, called a detour LSP, for each LSP which the PLR along protects using
   this technique.  With the path must protect facility backup technique, the reroutable LSP with a detour LSP
   or PLR creates
   a NNHOP backup single bypass tunnel (except for which can be used to protect multiple LSPs.

3.1.  One-to-one backup

   In the penultimate hop LSR that
   will just require one-to-one technique, a NHOP backup tunnel). This way label switched path is established
   which intersects the reroutable original LSP
   is being protected against any somewhere downstream of the point
   of link or node failure.

3.1. FAST_REROUTE Object

   The FAST_REROUTE object carries  For each LSP which is backed up, a
   separate backup LSP is established.

              [R1]---[R2]-----[R3]----[R4]---[R5]
                 \     \         \   /   \   /
                [R6]---[R7]-------[R8]----[R9]

              Protected LSP:  [R1->R2->R3->R4->R5]
              R1's Backup:    [R1->R6->R7->R8->R3]
              R2's Backup:    [R2->R7->R8->R4]
              R3's Backup:    [R3->R8->R9->R5]
              R4's Backup:    [R4->R9->R5]

              Example 1: One-to-One Backup Technique

   In the simple topology shown above in Example 1, the control information, such as
   setup and hold priorities and bandwidth. A protected LSP uses the
   FAST_REROUTE object
   runs from R1 to specify the level of R5.  R2 can provide user traffic protection by
   creating a partial backup LSP which merges with the protected LSP
   at R4.  We refer to a partial one-to-one backup LSP
   [R2->R7->R8->R4] as a detour.

   To fully protect an LSP that is
   required during local repair. The FAST_REROUTE object can traverses N nodes, there could be used as
   many as (N - 1) detours.  The paths for
   both one-to-one and facility backup, and has the following format:

     Class = TBD  (use form 11bbbbbb for compatibility)
     C-Type = 1

              0 detours necessary to
   fully protect the LSP in Example 1              2             3
       +-------------+-------------+-------------+-------------+
       |       Length (bytes)      |  Class-Num  |   C-Type    |
       +-------------+-------------+-------------+-------------+
       | Setup Prio  | Hold Prio   | Hop-limit   |    Flags    |
       +-------------+-------------+-------------+-------------+
       |                 Bandwidth                             |
       +-------------+-------------+-------------+-------------+
       |                  Include-any                          |
       +-------------+-------------+-------------+-------------+
       |                  Exclude-any                          |
       +-------------+-------------+-------------+-------------+
       |                  Include-all                          |
       +-------------+-------------+-------------+-------------+

     Setup Priority

       The priority of are given there.  To minimize
   the backup path with respect to taking resources, number of LSPs in the range of 0 to 7.  The value 0 network, it is desirable to merge a
   detour back to its protected LSP when feasible.  When a detour LSP
   intersects its protected LSP at an LSR with the highest priority.
       Setup Priority is used same outgoing
   interface, it will be merged.

   When a failure occurs along the protected LSP, the PLR redirects
   traffic onto the local detour.  For instance, if the link [R2->R3]
   fails in deciding whether this session can
       preempt another session. See [RSVP-TE] for Example 1, R2 will switch traffic received from R1 onto
   the usage on priority.

     Holding Priority

       The priority of protected LSP along link [R2->R7] using the backup path label received when
   R2 created the detour.  When R4 receives traffic with respect to holding
       resources, in the range label
   provided for R2's detour, R4 will switch that traffic onto link
   [R4-R5] using the label received from R5 for the protected LSP.  At
   no point does the depth of 0 to 7.  The value 0 is the highest
       priority.  Holding Priority label stack increase as a result of
   taking the detour.  While R2 is used in deciding whether this
       session can be preempted by another session. See [RSVP-TE] for using its detour, traffic will take
   the usage on priority.

     Hop-limit path [R1->R2->R7->R8->R4->R5].

3.2. Facility backup

   The maximum number facility backup technique takes advantage of extra hops the backup path MPLS label
   stack.  Instead of creating a separate LSP for every backed-up LSP, a
   single LSP is allowed
      to take, from current node (a PLR) created which serves to backup up a MP, with PLR and MP
      excluded in counting.  For example, hop-limit set of 0 means only
      direct links between PLR and MP can be considered.

     Flags

      0x01  One-to-one Backup Desired

         Indicates that the LSPs.  We
   call such an LSP should be protected via tunnel a bypass tunnel.

   The bypass tunnel must intersect the one-
         to-one backup mechanism described in Section 5.
         This flag can only be set by path of the head-end LSRs.

      0x02  Facility Backup Desired

         Indicates that original LSP(s)
   somewhere downstream of the LSP should be protected via PLR.  Naturally, this constrains the facility
         backup mechanism described in Section 6.  This flag can
         only be
   set by of LSPs being backed-up via that bypass tunnel to those that
   pass through some common downstream node.  All LSPs which pass
   through the head-end LSRs.

     Bandwidth

      Bandwidth estimate  (32-bit IEEE floating point integer) of local repair and through this common node
   which do not also use the facilities involved in
      bytes-per-second.

     Exclude-any

      A 32-bit vector representing a the bypass tunnel
   are candidates for this set of attribute filters associated
      with LSPs.

                 [R8]
                     \
               [R1]---[R2]----[R3]----[R4]---[R5]
                          \          /   \
                           [R6]===[R7]     [R9]

                Protected LSP 1: [R1->R2->R3->R4->R5]
                Protected LSP 2: [R8->R2->R3->R4]
                Protected LSP 3: [R2->R3->R4->R9]
                Bypass LSP Tunnel: [R2->R6->R7->R4]

                    Example 2: Facility Backup Technique

   In Example 2, R2 has built a backup path any of bypass tunnel which renders a protects against
   the failure of link unacceptable.

     Include-any

      A 32-bit vector representing a set [R2->R3], link [R3->R4] or node [R3].  The
   doubled lines represent this tunnel.  The scalability improvement
   this technique provides is that the same bypass tunnel can also be
   used to protect LSPs from any of attribute filters associated
      with a backup path R1, R2 or R8 to any of R4, R5 or
   R9.  Example 2 describes three different protected LSPs which renders a link acceptable (with
      respect to this test). A null set (all bits set are
   using the same bypass tunnel for protection.

   As with the one-to-one technique, to zero)
      automatically passes.

     Include-all

      A 32-bit vector representing fully protect an LSP that
   traverses N nodes, there could be as many as (N-1) bypass tunnels.
   However, each of those bypass tunnels could protected a set of attribute filters associated
      with
   LSPs.

   When a backup path all of which must be present for failure occurs along a protected LSP, the PLR redirects
   traffic into the appropriate bypass tunnel.  For instance, if link to
   [R2->R3] fails in Example 2, R2 will switch traffic received from
   R1 on the protected LSP onto link [R2->R6]; the label will be
      acceptable (with respect to this test). A null set (all bits set
   switched for one which will be understood by R4 to zero) automatically passes.

   The C-Class must indicate the
   protected LSP and then the bypass tunnel's label will be assigned pushed
   onto the label-stack of the redirected packets.  If
   penultimate-hop-popping is used, then the merge point in such Example 2,
   R4, will receive the redirected packet with a way that, for label indicating the LSRs
   protected LSP that do the packet is to follow.  If
   penultimate-hop-popping is not support used, then R4 will pop the FAST_REROUTE objects, they MUST forward bypass
   tunnel's label and examine the objects
   downstream unchanged.

   Some of label underneath to determine the existing implementations use
   protected LSP that the FAST_REROUTE object with
   a different C-type value, and slightly different object format (shown
   below).  For backward compatible purposes, it packet is documented here to follow.  When R2 is using the
   bypass tunnel for
   information purpose.

     C-Type = 7

              0             1              2             3
       +-------------+-------------+-------------+-------------+
       |       Length (bytes)      |  Class-Num  |   C-Type    |
       +-------------+-------------+-------------+-------------+
       | Setup Prio  | Hold Prio   | Hop-limit   | Reserved    |
       +-------------+-------------+-------------+-------------+
       |                 Bandwidth                             |
       +-------------+-------------+-------------+-------------+
       |                  Include-any                          |
       +-------------+-------------+-------------+-------------+
       |                  Exclude-any                          |
       +-------------+-------------+-------------+-------------+

3.2. DETOUR protected LSP 1, the traffic takes the path
   [R1->R2->R6->R7->R4->R5]; the bypass tunnel is the connection
   between R2 and R4.

4. RSVP Extensions

   We propose two additional objects, FAST_REROUTE and DETOUR, to
   extend RSVP-TE for fast-reroute signaling.  These new objects are
   backward compatible with LSRs that do not recognize them (see
   section 3.10 in [RSVP]).  Both objects can only be carried in RSVP
   Path messages.

   The SESSION_ATTRIBUTE and RECORD_ROUTE objects are also extended to
   support bandwidth and node protection features.

4.1. FAST_REROUTE Object

   The DETOUR FAST-REROUTE object is used in one-to-one backup to control the backup used for the
   protected LSP.  This specifies the setup and identify
   detour LSPs. hold priorities, the
   session attribute filters, and bandwidth to be used for protection.
   It also allows a specific local protection technique to be requested.
   This object MUST only be inserted into the PATH message by the
   head-end LER and MUST NOT be changed by downstream LSRs. The
   FAST-REROUTE object has the following format:

      Class = TBD  (to conform 0bbbbbbb format  (use form 11bbbbbb for compatibility)
      C-Type = 7 1

               0             1              2             3
        +-------------+-------------+-------------+-------------+
        |       Length (bytes)      |  Class-Num  |   C-Type    |
        +-------------+-------------+-------------+-------------+
        | Setup Prio  | Hold Prio   | Hop-limit   |    Flags    |
        +-------------+-------------+-------------+-------------+
        |                 Bandwidth                             |
        +-------------+-------------+-------------+-------------+
        |                  Include-any                          |
        +-------------+-------------+-------------+-------------+
        |                  Exclude-any                          |
        +-------------+-------------+-------------+-------------+
        |                  Include-all                          |
        +-------------+-------------+-------------+-------------+

      Setup Priority

        The priority of the backup path with respect to taking
        resources, in the range of 0 to 7.  The value 0 is the highest
        priority.  Setup Priority is used in deciding whether
        this session can preempt another session. See [RSVP-TE] for
        the usage on priority.

      Holding Priority

        The priority of the backup path with respect to holding
        resources, in the range of 0 to 7.  The value 0 is the highest
        priority.  Holding Priority is used in deciding whether this
        session can be preempted by another session. See [RSVP-TE] for
        the usage on priority.

      Hop-limit

       The maximum number of extra hops the backup path is allowed
       to take, from current node (a PLR) to a MP, with PLR and MP
       excluded in counting.  For example, hop-limit of 0 means only
       direct links between PLR and MP can be considered.

      Flags

       0x01  One-to-one Backup Desired
          Indicates that protection via the one-to-one backup
          technique is desired.

       0x02  Facility Backup Desired

          Indicates that protection via the facility backup
          technique is desired.

      Bandwidth

       Bandwidth estimate  (32-bit IEEE floating point integer) in
       bytes-per-second.

      Exclude-any

       A 32-bit vector representing a set of attribute filters
       associated with a backup path any of which renders a link
       unacceptable.

      Include-any

       A 32-bit vector representing a set of attribute filters
       associated with a backup path any of which renders a link
       acceptable (with respect to this test). A null set (all bits
       set to zero) automatically passes.

      Include-all

       A 32-bit vector representing a set of attribute filters
       associated with a backup path all of which must be present for
       a link to be acceptable (with respect to this test). A null set
       (all bits set to zero) automatically passes.

   The two high-order bits of the Class-Num (11) indicate that nodes
   that do not understand the object should ignore it and pass if
   forward unchanged.

   For informational purposes, a different C-type value and format for
   the FAST_REROUTE object are specified below.  This is used by
   existing implementations.  The meaning of the fields is the same as
   described for C-Type 1.

      C-Type = 7

               0             1              2             3
        +-------------+-------------+-------------+-------------+
        |       Length (bytes)      |  Class-Num  |   C-Type    |
        +-------------+-------------+-------------+-------------+
        | Setup Prio  | Hold Prio   | Hop-limit   | Reserved    |
        +-------------+-------------+-------------+-------------+
        |                 Bandwidth                             |
        +-------------+-------------+-------------+-------------+
        |                  Include-any                          |
        +-------------+-------------+-------------+-------------+
        |                  Exclude-any                          |
        +-------------+-------------+-------------+-------------+

4.2. DETOUR Object

   The DETOUR object is used in one-to-one backup to identify detour
   LSPs. It has the following format:

      Class = TBD  (to conform 0bbbbbbb format for compatibility)
      C-Type = 7

             0             1              2             3
        +-------------+-------------+-------------+-------------+
        |       Length (bytes)      |  Class-Num  |   C-Type    |
        +-------------+-------------+-------------+-------------+
        |                      PLR ID  1                        |
        +-------------+-------------+-------------+-------------+
        |                    Avoid Node ID 1                    |
        +-------------+-------------+-------------+-------------+
       //                        ....                          //
        +-------------+-------------+-------------+-------------+
        |                      PLR ID  n                        |
        +-------------+-------------+-------------+-------------+
        |                    Avoid Node ID  n                   |
        +-------------+-------------+-------------+-------------+

      PLR ID  (1 - n)

        IPv4 address identifying the beginning point of detour which
        is a PLR. Any local address on the PLR can be used.

      Avoid Node ID  (1 - n)

        IP address identifying the immediate downstream node that
        the PLR is trying to avoid. Router ID of downstream node
        is preferred. This field is mandatory, and is used by
        the MP for merging rules discussed below.

   There can be more than one pair of (PLR_ID, Avoid_Node_ID) entries in
   a DETOUR object. If detour merging is desired, after each merging
   operation, the Detour Merge Point should combine all the merged
   detours in the subsequent Path messages.

   The high-order bit of the C-Class is zero; LSRs that do not support
   the DETOUR objects MUST reject any Path message containing a DETOUR
   object and send a PathErr to notify the PLR.

4.3. SESSION_ATTRIBUTE Flags

   To explicitly request bandwidth and node protection, two new flags
   are defined in the SESSION_ATTRIBUTE object.

   For both C-Type 1 and 7, the SESSION_ATTRIBUTE object currently has
   the following flags defined:

      Local protection desired:   0x01

        This flag permits transit routers to use a local repair
        mechanism which may result in violation of the explicit route
        object.  When a fault is detected on an adjacent downstream link
        or node, a transit node may reroute traffic for fast service
        restoration.

      Label recording desired:   0x02

        This flag indicates that label information should be included
        when doing a route record.

      SE Style desired:   0x04

        This flag indicates that the tunnel ingress node may choose to
        reroute this tunnel without tearing it down. A tunnel egress
        node SHOULD use the SE Style when responding with a Resv
        message.  When requesting fast reroute, the head-end LSR
        SHOULD set this flag; this is not necessary for the
        path-specific method of the one-to-one backup technique.

   The following new flags are defined:

      Bandwidth protection desired:  0x08
        This flag indicates to the PLRs along the protected LSP path
        that a backup path with a bandwidth guarantee is desired.
        The bandwidth to be guaranteed is that of the protected
        LSP, if no FAST_REROUTE object is included in the PATH message;
        if a FAST_REROUTE object is in the PATH message, then the
        bandwidth specified therein is that to be guaranteed.

      Node protection desired: 0x10

        This flag indicates to the PLRs along a protected LSP path
        that a backup path which bypasses at least the next node of
        the protected LSP is desired.

4.4. RRO IPv4/IPv6 Sub-Object Flags

   To report whether bandwidth and/or node protection are provided as
   requested, we define two news flags in the RRO IPv4 sub-object.

   RRO IPv4 and IPv6 sub-object address:

   These two sub-objects currently have the following flags defined:

      Local protection available:  0x01

        Indicates that the link downstream of this node is protected
        via a local repair mechanism, which can be either one-to-one
        or facility backup.

      Local protection in use:  0x02

        Indicates that a local repair mechanism is in use to maintain
        this tunnel (usually in the face of an outage of the link it
        was previously routed over, or an outage of the neighboring
        node).

   Two new flags are defined:

      Bandwidth protection:  0x04

        The PLR will set this when the protected LSP has a backup path
        which is guaranteed to provide the desired bandwidth specified
        in the FAST_REROUTE object or the bandwidth of the protected
        LSP, if no FAST_REROUTE object was included.  The PLR may set
        this whenever the desired bandwidth is guaranteed; the PLR ID  1                        |
       +-------------+-------------+-------------+-------------+
       |                    Avoid Node ID 1                    |
       +-------------+-------------+-------------+-------------+
      //                        ....                          //
       +-------------+-------------+-------------+-------------+
       |
        MUST set this flag when the desired bandwidth is guaranteed
        and the "bandwidth protection desired" flag was set in the
        SESSION_ATTRIBUTE object.  If the requested bandwidth is not
        guaranteed, the PLR ID  n                        |
       +-------------+-------------+-------------+-------------+
       |                    Avoid MUST NOT set this flag.

      Node ID  n                   |
       +-------------+-------------+-------------+-------------+ protection:  0x08

        The PLR ID  (1 - n)

       IPv4 address identifying will set this when the beginning point of detour protected LSP has a backup path
        which
       is provides protection against a PLR. Any local address on failure of the PLR can be used.

     Avoid Node ID  (1 - n)

       IP address identifying next LSR
        along the immediate downstream protected LSP.  The PLR may set this whenever node that
        protection is provided by the protected LSP's backup path; the
        PLR is trying to avoid. Router ID of downstream MUST set this flag when the node protection is preferred. This field is mandatory, provided
        and is used by the MP for merging rules discussed below.

   There could be more than one pair of (PLR_ID, Avoid_Node_ID) entry "node protection desired" flag was set in
   a DETOUR the
        SESSION_ATTRIBUTE object.  If detour merging node protection is desired, after each merging
   operation (Section 5.3), not provided,
        the MP should combine all PLR MUST NOT set this flag.  Thus, if a PLR could only
        setup a link-protection backup path, the merged detours
   in "Local protection
        available" bit will be set but the "Node protection" bit will
        be cleared.

5. Head-End Behavior

   The head-end of an LSP determines whether local protection should
   be requested for that LSP and which local protection technique is
   desired for the subsequent Path messages. protected LSP.  The C-Class must head-end also determines what
   constraints should be assigned in such a way that, requested for the LSRs backup paths of a protected
   LSP.

   To indicate that do
   not support the DETOUR objects, an LSP should be locally protected, the LSRs head-end
   LSR MUST reject either set the message and
   send a PathErr to notify "Local protection desired" flag in the PLR.

3.3.
   SESSION_ATTRIBUTE Modification

   To explicitly require bandwidth and node protection, two new flags
   are defined object or include a FAST_REROUTE object in the SESSION_ATTRIBUTE object:

   SESSION_ATTRIBUTE

     Class = 207
     C-Type = 7 (LSP_TUNNEL)

            0             1              2             3
       +-------------+-------------+-------------+-------------+
       | Setup Pri   | Holding Pri |      Flags  | Name Length |
       +-------------+-------------+-------------+-------------+
       |                                                       |
       //   Session Name      (NULL padded display string)     //
       |                                                       |
       +-------------+-------------+-------------+-------------+

     Current Flags:

     Local
   PATH message or both.  It is recommended that the "local protection desired:   0x01

       This
   desired" flag permits transit routers to use a local repair mechanism
       which may result in violation of the explicit route object.
       When SESSION_ATTRIBUTE object always be set.  If a fault is detected on an adjacent downstream link or node,
   head-end LSR signals a transit node can reroute traffic FAST_REROUTE object, it MUST be stored for fast service restoration.

     Label
   Path refreshes.

   The head-end LSR of a protected LSP MUST set the "label recording desired:   0x02

       This
   desired" flag indicates that label information should be included
       when doing a route record.

     SE Style desired:   0x04 in the SESSION_ATTRIBUTE object.  This flag indicates that facilitates
   the tunnel ingress node may choose to
       reroute this tunnel without tearing it down. A tunnel egress node
       SHOULD use of the SE Style when responding with facility backup technique.  If node protection is
   desired, the head-end LSR should set the "node protection desired"
   flag in the SESSION_ATTRIBUTE object; if only link protection is
   desired, this flag should be cleared.  Similarly, if a Resv message.
       When requesting fast reroute, guarantee of
   bandwidth protection is desired, then the head-end LSR MUST set
       this flag.

     New  Flags:

     Bandwidth "bandwidth protection desired:  0x08

       This
   desired" flag indicates to in the PLRs along SESSION_ATTRIBUTE object should be set;
   otherwise, this flag should be cleared.

   If the protected LSP path head-end LSR determines that a control of the backup path with a bandwidth guarantee paths for
   the protected LSP is desired. desired, then the LSR should include the
   FAST_REROUTE object.  The bandwidth which must attribute filters, bandwidth, hop-limit
   and priorities will be guaranteed is used by the PLRs when determining the backup
   paths.

   If the head-end LSR desires that of the protected
       LSP, if no FAST_REROUTE object is included in LSP be protected via
   the PATH message;
       if one-to-one backup technique, then head-end LSR should include a
   FAST_REROUTE object is in and set the PATH message, then "one-to-one backup desired" flag.
   If the
       bandwidth specified in there is head-end LSR desires that which must the protected LSP be guaranteed.

     Node protection desired: 0x10

       This flag indicates to protected via
   the facility backup technique, then the head-end LSR should include
   a FAST_REROUTE object and set the "facility backup desired" flag.
   The lack of a FAST_REROUTE object, or having both these flags
   clear should be treated by PLRs along as a lack of preference.  If
   both flags are set a PLR may use either method or both.

   The head-end LSR of a protected LSP path
       that they must select a backup path that bypasses at least MUST support the
       next node of additional
   flags defined in Section 4.4 being set or clear in the protected LSP.

3.4. RRO Modification

   To record bandwidth IPv4 and node protection, we define two news flags in
   IPv6 sub-objects.  The head-end LSR of a protected LSP MUST support
   the RRO IPv4 Label sub-object.

   RRO IPv4 sub-object address:

     Type: 0x01  IPv4 address

            0             1              2             3
       +-------------+-------------+-------------+-------------+
       |     Type    |     Length  |  IPv4 address (4 bytes)   |
       +-------------+-------------+-------------+-------------+
       | IPv4 address (continued)  | Prefix Len  |     Flags   |
       +-------------+-------------+-------------+-------------+

     Current Flags:

     Local protection available:  0x01

       Indicates that

   If the link downstream head-end LSR of this node is protected
       via a an LSP determines that local repair mechanism, which can protection is
   newly desired, this should be either one-to-one
       or facility backup. signaled via make-before-break.

6. Point of Local protection in use:  0x02

       Indicates that Repair Behavior

   Every LSR along a local repair mechanism is protected LSP (except the egress) MUST follow the
   PLR behavior described in use to maintain this tunnel (usually document.

   A PLR SHOULD support the FAST_REROUTE object, the "local protection
   desired", "label recording desired", "node protection desired" and
   "bandwidth protection desired" flags in the face of an outage of SESSION_ATTRIBUTE
   object, and the link it
       was previously routed over, or an outage of "local protection available", "local protection in
   use", "bandwidth protection", and "node protection" flags in the neighboring
       node).

     New Flags:

     Bandwidth protection:  0x04

       The
   RRO IPv4 and IPv6 sub-objects.  A PLR will set this when MAY support the protected DETOUR
   object.

   A PLR MUST consider an LSP has a backup
       path which provides as having asked for local protection if
   the desired bandwidth, which "local protection desired" flag is that set in the FAST_REROUTE SESSION_ATTRIBUTE
   object or the bandwidth of and/or the protected LSP,
       if no FAST_REROUTE object was is included.  The  If the
   FAST_REROUTE object is included, a PLR may SHOULD consider providing
   one-to-one protection if the "one-to-one desired" is set this
       whenever and SHOULD
   consider providing facility backup if the "facility backup desired"
   flag is set when determining whether to provide local protection
   and which technique to use to provide that local protection.  If
   the desired bandwidth "node protection desired" flag is guaranteed; set, the PLR MUST set SHOULD try to
   provide node protection; if this flag when the desired bandwidth is guaranteed and not feasible, the
       "bandwidth protection desired" flag was set PLR SHOULD
   then try to provide link protection.

   The following treatment for the RRO IPv4 or IPv6 sub-object's flags
   must be followed if an RRO is included in the
       SESSION_ATTRIBUTE object.

     Node protection:  0x08

       When set, protected LSP's RESV
   message.  Based on this indicates that additional information the head-end may
   take appropriate actions.

    - Until a PLR has a backup path
       providing protection against link and node failure on available, the PLR MUST clear the
      relevant four flags in the corresponding path section. In case RRO IPv4 or IPv6
      sub-object.

    - Whenever the PLR could only
       setup has a link-protection backup path, path available, the "Local PLR MUST set
      the "local protection available" bit will be set but flag.  If no established
      one-to-one backup LSP or bypass tunnel exists, or the "Node protection" bit
       will be cleared.

3.5. New RRO sub-object: MAX_PROTECTED_BANDWIDTH

   This sub-object one-to-one
      LSP and the bypass tunnel is carried in "DOWN" state, the PLR MUST clear
      the "local protection available" flag in its IPv4 (or IPv6)
      address subobject of the RRO object and is optional.  An
   implementation MAY support it.  An LSR SHOULD send the updated RESV.

    - The PLR MUST ignore and silently
   propagate this sub-object, if clear the "local protection in use" flag unless it
      is not understood.

   RRO MAX_PROTECTED_BANDWIDTH sub-object:

            0             1              2             3
       +-------------+-------------+-------------+-------------+
       |     Type    |     Length  |          Flags            |
       +-------------+-------------+-------------+-------------+
       |               Bandwidth protection ratio              |
       +-------------+-------------+-------------+-------------+

       Type: 0x04

       Length: 32

       Flags:

         No Flags are currently defined

       Bandwidth protection ratio

         Let's call T actively redirecting traffic into the bypass tunnel selected for backup path instead of
      along the protected LSP.

    - The bandwidth protection ratio is PLR SHOULD also set the "node protection" flag if the backup
      path protects against the sum failure of the bandwidths of all immediate downstream
      node and, if not, the protected LSPs having selected
         T as their bypass tunnel / bandwidth of PLR SHOULD clear the bypass tunnel T.
         The bandwidth "node protection"
      flag.  This MUST be done if the "node protection ratio is a 32-bit IEEE floating
         point integer desired" flag
      was set in bytes-per-second. the SESSION_ATTRIBUTE object.

    - The minimum value for PLR SHOULD set the protected ratio is 1, which means "the TE
   LSP is bandwidth protected".

   Note that "bandwidth protection" if the PLR must select a backup tunnel in such path
      offers a way that the bandwidth protected ratio is 1 for guarantee and, if not, SHOULD clear the TE LSP having required
   bandwidth
      "bandwidth protection" flag. This MUST be done if the "bandwidth
      protection desired" flag was set in the SESSION_ATTRIBUTE object of their Path
   message

   The bandwidth protected ratio may be used for troubleshooting purpose
   or to trigger appropriate decision the head-end LSR (outside the
   scope of this document).

4.
      object.

6.1 Signaling for a Backup Path

   A number of objectives must be met to obtain a satisfactory signaling
   solution. These are summarized as follows:

     1. Unambiguously and uniquely identify backup paths
     2. Unambiguously associate protected LSPs with their backup paths
     3. Work with both global and non-global label spaces
     4. Allow for merging of backup paths
     5. Maintain RSVP state during and after fail-over.

   LSP tunnels are identified by a combination of the SESSION and
   SENDER_TEMPLATE objects. The relevant fields are as follows.

      IPv4 (or IPv6) tunnel end point address
        IPv4 (or IPv6) address of the egress node for the tunnel.

      Tunnel ID

        A 16-bit identifier used in the SESSION that remains constant
        over the life of the tunnel.

      Extended Tunnel ID

        A 32-bit (IPv4) or 128-bit (IPv6) identifier used in the SESSION
        that remains constant over the life of the tunnel. Normally set
        to all zeros. Ingress nodes that wish to narrow the scope of a
        SESSION to the ingress-egress pair may place their IPv4 IP address
        here as a globally unique identifier.

      IPv4 (or IPv6) tunnel sender address

        IPv4 (or IPv6) address for a sender node

      LSP ID

        A  16-bit identifier used in the SENDER_TEMPLATE and the
        FILTER_SPEC that can be changed to allow a sender to share
        resources with itself.

   The first three of these are in the SESSION object and are the basic
   identification of the tunnel. The last two are in the
   SENDER_TEMPLATE.

   In particular, setting  Setting the "Extended Tunnel ID" to the original IPv4
   sender
   an IP address of the head-end LSR allows the PLR scope of the SESSION
   to identify be narrowed to which protected only LSPs sent by that LSR.  A backup LSP a
   message (from MP) corresponds. For example, when a Resv message
   arrives at the PLR, the Extended Tunnel ID identifies is
   considered to be part of the original
   sender, allowing same session as its protected LSP;
   therefore these three cannot be varied.

   The last two are in the PLR to identify SENDER_TEMPLATE.  Multiple LSPs in the state to same
   SESSION may be refreshed.

4.1. Identification protected and association of backup paths

   We propose two take different approaches to identify backup paths:

     - Path Message Specific:

       The routes; this is common
   when rerouting a tunnel using make-before-break.  It is necessary
   that a backup paths use the same SESSION and SENDER_TEMPLATE
       objects as the ones used in the path be clearly identified with its protected LSP. However, the Path
       messages need to provide enough information LSP, so
   that allow the LSRs
       to differentiate the correct merging and state treatment can be done.  Therefore, a
   backup paths path must inherit its LSP ID from the associated protected LSPs.

       In case of one-to-one backup,
   LSP.  Thus, the presence of DETOUR object only field in Path messages signifies the SESSION and SENDER_TEMPLATE
   objects which could be varied between a backup path, while the presence of
       FAST_REROUTE object indicates path and a protected LSP.

     - Sender-Template Specific:
   LSP is the "IPv4 (or IPv6) tunnel sender address" in the
   SENDER_TEMPLATE.

   There are two different methods to uniquely identify a backup
   path.  These are described below.

6.1.1. Backup Path Identification: Sender-Template-Specific
   In this approach, the SESSION object and the LSP_ID are copied from
   the protected LSP.  The IPv4 "IPv4 tunnel sender address address" is set to an
   address of the PLR node. PLR.  If the head-end of a tunnel is also acting as
   the PLR, it must choose an IP address different from the one used
   in the SENDER_TEMPLATE SENDER_TEMPLATE of the original LSP tunnel.

   When using the sender-template-specific approach, the protected
   LSPs and the backup paths SHOULD use the Shared Explicit (SE)
   style.  This allows bandwidth sharing between multiple backup
   paths.  The backup paths and the protected LSP MAY be merged by the
   Detour Merge Points, when the ERO from the MP to the egress is the
   same on each LSP to be merged, as specified in [RSVP-TE].

6.1.2. Backup Path Identification: Path-Specific

   In this approach, rather than varying the SESSION or
   SENDER_TEMPLATE objects, a new object, the DETOUR object, is used
   to distinguish between PATH messages for a backup path and the
   protected LSP.

   Thus, the backup paths use the same SESSION and SENDER_TEMPLATE
   objects as the ones used in the protected LSP. The presence of
   DETOUR object in Path messages signifies a backup path; the
   presence of FAST_REROUTE object and/or the original LSP
       tunnel. "local protection
   requested" flag in the SESSION_ATTRIBUTE object indicates a
   protected LSP.

   In the path-message-specific approach, when an LSR receives
   multiple Path message messages which have the same Session SESSION and Sender Template
   SENDER_TEMPLATE objects and which also have the same next-hop, that LSR
   must merge the Path
   messages; without messages.  Without this behavior, the multiple
   RESV messages received back would not be distinguishable as to
   which backup path each belongs to.  This merging behavior does
   reduce the total number of RSVP states inside the network.  One merging example is given in
   Section 5.3.

   When using the sender-template-specific approach, the protected LSPs
   and the backup paths SHOULD use the Shared Explicit (SE) style.  This
   allows bandwidth sharing between multiple backup paths.  The backup
   paths and the protected LSP can be merged by the Merge Points, when
   the ERO from the MP to the egress is the same on each LSP to be
   merged, as specified in [RSVP].

5. One-to-one backup protection

   In this section, we describe an one-to-one backup method that has the
   feature to protect both network links and nodes.

   To support the one-to-one backup, the users at head-end LSRs must
   specify the backup service requirements for the protected LSPs.  The
   LSRs must be able to interface
   expense of merging LSPs with CSPF to compute the most suitable
   detour route for the protected LSPs.  Upon receiving the local
   protection requests different EROs.

6.2 Procedures for Backup Path Computation

   Before a protected LSP, the PLRs must try to
   establish the detour LSPs immediately.  During network failure, the PLR must redirect the data packets into the detour LSPs in a timely
   fashion.

5.1. Operation Overview

   If can create a one-to-one backup for detour or a protected LSP is explicitly desired, the
   head-end LSR SHOULD insert into bypass tunnel, the Path message desired
   explicit route must be determined.  This can be done using a FAST_REROUTE
   object, with CSPF.

   Before CSPF computation, the "One-to-one Backup desired" flag set.  A one-to-one
   backup for following information should be
   collected at a PLR:

      - The list of downstream nodes that the protected LSP may passes
        through. This information is readily available from the
        RECORD_ROUTE objects during LSP setup. This information is also be created based upon a PLR's
   local policy
        available from the ERO.  However, if either the "local ERO contains loose
        sub-objects, the ERO may not provide adequate information.

      - The downstream links/nodes that we want to protect against. Once
        again, this information is learned from the RECORD_ROUTE
        objects.  Whether node protection desired" flag is set desired is determined by
        the "node protection" flag in the SESSION_ATTRIBUTE object or a FAST_REROUTE object is included or
   both.

   When processed at a PLR, the PLR initiates a detour LSP by sending a
   new Path message that contains a DETOUR object.  Since an LSP cannot
   be a protected and a detour LSP at the same time, any Path message
   MUST NOT contain both FAST_REROUTE and DETOUR objects,
        local policy.

      - The LSRs upstream uni-directional links that initiate the detour LSPs SHOULD support both
   FAST_REROUTE and DETOUR objects. It is possible that some LSRs along
   a protected LSP do not support this standard.  If that
        passes through.  This information is learned from the case,
   those LSRs will not establish protection
        RECORD_ROUTE objects; it is only needed for their immediate links or
   nodes.  Any LSR which does support this standard SHOULD provide setting up
        one-to-one protection.

   The LSRs that support  In the detour LSPs MUST store all received
   FAST_REROUTE and/or DETOUR objects for Path refreshes.  The LSRs must
   process path-specific method, it is
        necessary to avoid the detour LSPs independent of and the protected LSPs LSP sharing
        a common next-hop upstream of the failure.  In the
        sender-template-specific mode, this same restriction is
        necessary to avoid
   triggering sharing bandwidth between the detour and
        its protected LSP, where that bandwidth has only been reserved
        once.

      - The link attribute filters to be applied.  These are derived
        from the LSP loop detection procedure described FAST_REROUTE object, if included in [RSVP-TE]. the PATH message,
        and the SESSION_ATTRIBUTE object otherwise.

      - The one-to-one backup can use either path-message-specific or sender-
   template-specific bandwidth to identify the detour LSPs.

   When using be used is found in the sender-template-specific approach, FAST_REROUTE object,
        if included in the protected PATH message, and
   detour LSPs should have the "SE Style desired" bit set in the SESSION_ATTRIBUTE objects.  At the MP, the detour LSPs merge into
        object otherwise.  Local policy may modify the
   protected LSPs according bandwidth to the merging rules defined for SE style
   reservations be
        reserved.

      - The hop-limit, if a FAST_REROUTE object was included in [RSVP].

   In the case of one-to-one backup, there is no need for the PLRs
        PATH message.

   When applying a CSPF algorithm to
   learn about compute the backup labels used at route, the merging points.

5.2. Procedures
   following constraints should be satisfied:

      - For detour LSPs, the destination MUST be the tail-end of the
        protected LSP; for bypass tunnels (Section 6), the PLR

   Upon receiving a Path message that contains a FAST_REROUTE object, a
   PLR needs to run CPSF based on destination
        MUST be the information provided in address of the
   FAST_REROUTE, as well as MP.

      - When setting up one-to-one protection using the downstream interface and nexthop router
   information, to compute path-specific
        method, a detour route. More details on CSPF
   computation are described MUST not traverse the upstream links of the
        protected LSP in Section 7.

   Once a the same direction.  This prevents the
        possibility of early merging of the detour is successfully computed and established, into the PLR needs
   not to compute protected
        LSP.  When setting up one-to-one protection using the
        sender-template-specific method, a detour routes again, unless (1) should not traverse
        the contents upstream links of
   FAST_REROUTE have changed, or (2) the downstream interface and/or protected LSP in the same direction;
        this prevents sharing the
   nexthop router for bandwidth between a protected LSP have changed.

   After a successful detour computation,
        and its backup upstream of the PLR generates a Path
   message to setup failure where the bandwidth
        would be used twice in the event of a detour path. failure.

      - The Path consists of backup LSP cannot traverse the following:

     - A DETOUR object downstream node and/or link
        whose failure is being protected against.  Note that specifies if the current
        PLR ID is the penultimate hop, node protection is not possible
        and
       Avoid Node ID. Only one pair of (PLR_ID, Avoid_Node_ID)
       permitted.

     - An EXPLICIT_ROUTE object toward only the egress. downstream link can be avoided.  The ERO information
       comes backup path
        may be computed to be SRLG disjoint from the CSPF computation. downstream node
        and/or link being avoided.

      - The SENDER_TSPEC object contains backup path must satisfy the bandwidth information resource requirements of the
        protected LSP.  This SHOULD consider the link attribute
        filters, bandwidth, and hop limits determined from the previously received
        FAST_REROUTE objects.

     - The RSVP_HOP object contains and SESSION_ATTRIBUTE object.

   If such computation succeeds, the PLR's IP address.

     - PLR should attempt to establish a
   backup path.  The detour LSP PLR may generate schedule a re-computation at a later time
   to discover better paths that may have emerged.  If for any reason,
   the PLR is unable to bring up a backup path, it must schedule a
   retry at a later time.

6.3 Signaling Backups for One-To-One Protection

   Once a PLR has decided to locally protect an LSP with one-to-one
   backup, and process its own RRO object.

     - has identified the desired path, it takes the following
   steps to signal the detour.

   The FAST_REROUTE object MUST NOT following describes the transformation to be included. performed upon the
   protected LSP's PATH message to create the detour LSP's PATH
   message.

   - When using If the sender-template-specific approach, sender-template specific method is to be used, then the
     PLR MUST change the "IPv4 (or IPv6) tunnel sender address" in of the
     SENDER_TEMPLATE must be set to an address belonging to the PLR.

     - The detour LSPs MUST use PLR that is not
     the same reservation style as was used for the protected LSP. This must be correctly reflected in  Additionally, the
       SESSION_ATTRIBUTE object.

     - All other objects SHOULD
     DETOUR object MAY be identical added to those of the protected
       LSP.

   The PLR MUST not mix the messages for the protected and the detour
   LSPs.  When a PLR receives Resv, ResvTear and PathErr messages from
   the downstream detour destination, the messages MUST not be forwarded
   upstream. Similarly, when a PLR receives ResvErr and ResvConf
   messages from a protected LSP, it MUST not propagate them onto PATH message.

   - If the
   associated detour LSP.

   A session tear-down request path-specific method is normally originated by the sender via
   PathTear messages. When a PLR node receives a PathTear message from
   upstream, it MUST delete both protected and detour LSPs. The PathTear
   messages MUST propagate to both protected and detour LSPs.

   During error conditions, the LSRs may send ResvTear messages to fix
   problems on be used, then the failing path. When a PLR node receives the ResvTear
   messages from downstream for a protected LSP, as long as a detour is
   up, the ResvTear messages MUST not sent further upstream.

5.3. Procedures for the MP using the Path-Specific Approach

   An LSR (that is, add
     a MP) may receive multiple Path messages from
   different interfaces with identical SESSION and SENDER_TEMPLATE
   objects. Path state merging is REQUIRED. DETOUR object to the PATH message.

   - The SESSION_ATTRIBUTE flags "Local protection desired",
     "Bandwidth protection desired" and "Node protection desired" MUST
     be cleared.  The merging rule is "Label recording desired" flag MAY be modified.
     If the following:

   For all Path messages that do not have either Message contained a FAST_REROUTE or a
   DETOUR object, or and the MP ERO
     is not completely strict, the egress Include-any, Exclude-any, and
     Include-all fields of the LSP, no merging is
   required.  The messages are processed according FAST_REROUTE object should be copied to [RSVP-TE].

   Otherwise,
     the MP MUST record corresponding fields of the Path state as well as their
   incoming interface. SESSION_ATTRIBUTE object.

   - If the protected LSP's Path messages do not share outgoing
   interface and next-hop LSR, message contained a FAST_REROUTE
     object, this MUST be removed from the MP detour LSP's PATH message.

   - The PLR must consider them as independent
   LSPs, and generate an EXPLICIT_ROUTE object toward the egress.
     First, the PLR must not merge them.

   For remove all sub-objects preceding the Path messages that share first
     address belonging to the same outgoing interface Merge Point.  Then the PLR should add
     sub-objects corresponding to the desired backup path between the
     PLR and
   next-hop LSR, the MP runs MP.

   - The SENDER_TSPEC object should contain the following procedure to select bandwidth information
     from the received FAST_REROUTE object, if included in the
     protected LSP's PATH message.

   - The RSVP_HOP object containing one of
   them as the final LSP.

    1. Eliminate from consideration those that traverse nodes that other PLR's IP address.

   - The detour LSPs want to avoid.

    2. If one LSP is originated from this node, this must be MUST use the final same reservation style as the
     protected LSP. Quit.

    3. If only one LSP contains FAST_REROUTE object, this This must be correctly reflected in the
       final LSP. Quit.

    4. If there
     SESSION_ATTRIBUTE object.

   Detour LSPs are several LSPs, regular LSPs in operation.  Once a detour path is
   successfully computed and the detour LSP is established, the PLR
   need not all compute detour routes again, unless (1) the contents of them
   FAST_REROUTE have changed, or (2) the downstream interface and/or
   the nexthop router for a DETOUR
       object, then eliminate those with DETOUR from final protected LSP
       considerations.

    5. If several candidates remain (that is, there are both have changed.  The PLR may
   recompute detour
       and protected LSPs), prefer the ones routes at any time.

6.3.1 Make-Before-Break with FAST_REROUTE object.

    6. If none found, prefer the ones without DETOUR object. Detour LSPs

   If none
       found, prefer the ones with DETOUR object.

    7. If several candidate LSPs still remain, sender-template specific method is used, it is a local decision possible to
   do make-before-break with detour LSPs.  This is done by using two
   different IP addresses belonging to choose which one will be the final LSP. The decision can
       be based on PLR (which were not used in
   the number SENDER_TEMPLATE of the protected LSP).  If the current detour
   LSP uses the first IP hops address in ERO, bandwidth requirements,
       or others. its SENDER_TEMPLATE, then the new
   detour LSP should be signaled using the second IP address in its
   SENDER_TEMPLATE.  Once the final new detour LSP has been identified, created, the MP MUST only transmit
   current detour LSP can be torn down.  By alternating the
   Path use of
   these IP addresses, the current and new detour LSPs will have
   different SENDER_TEMPLATES and, thus, different state in the
   downstream LSRs.

   This make-before-break mechanism, changing the PLR IP address in
   the DETOUR object instead, is not feasible with the path-specific
   method because the PATH messages that are corresponding to for new and current detour LSPs
   may be merged if they share a common next-hop.

6.3.2 Message Handling
   LSRs must process the detour LSPs independent of the final LSP. Other protected LSPs are
   considered merged at this node.
   to avoid triggering the LSP loop detection procedure described in
   [RSVP-TE].

   The MP may receive PathTear PLR MUST not mix the messages for some of the merging LSPs.
   No PathTear message should be propagated downstream until protected and the MP has
   received tear-down from all merging detour
   LSPs.  When an LSR receives a PLR receives Resv, ResvTear for an LSP and it is PathErr messages from
   the downstream detour destination, the messages MUST not be forwarded
   upstream. Similarly, when a PLR for
   that receives ResvErr and ResvConf
   messages from a protected LSP, then the LSR SHOULD it MUST not propagate them onto the ResvTear towards the
   LSP's ingress.  For each backup LSP where the LSR
   associated detour LSP.

   A session tear-down request is normally originated by the merge node,
   the ResvTear should also be propagated along the backup LSP towards
   the backup LSP's ingress, sender via
   PathTear messages. When a PLR.

5.3.1. An Example on Path Message Merging

   Consider PLR node receives a PathTear message from
   upstream, it MUST delete both the following example:

                G----H----I--\
                |    |    |   \
           A----B----C----D----E---F

   The protected LSP is A-B-C-D-E-F. After running CSPF, let the detour
   ERO from B be B-G-H-I-D-E-F, and the detour ERO from C be C-H-I-E-F.

   H will receive Path LSPs. The
   PathTear messages that have the same SESSION and
   SENDER_TEMPLATE from detours for B MUST propagate to both protected and C.  During merging at H, since detour C has LSPs.

   During error conditions, the LSRs may send ResvTear messages to fix
   problems on the failing path. When a shorter ERO path length (that is, ERO is I-E-F, and
   path length is 3), H will select it as PLR node receives the final LSP, and only
   propagate its Path ResvTear
   messages downstream.  Upon receiving from downstream for a Resv (or protected LSP, as long as a
   ResvTear) message, H must relay on detour is
   up, the ResvTear messages toward both B and C.

   E needs to merge as well, and will select MUST not be sent further upstream.
   PathErrs should be treated similiarly.

6.3.3 Local Reroute of Traffic onto Detour LSP

   When the main PLR detects a failure on the protected LSP, since it has the FAST_REROUTE object.  Thus, PLR MUST
   rapidly switch packets to the detour protected LSP's backup LSP terminates at E.

5.3.2. Creating new DETOUR object at MP

   If several LSPs are merged, the MP uses instead of
   the following algorithm protected LSP's normal out-segment.  The goal of this technique
   is to
   format its outgoing DETOUR object for effect the final redirection within 10s of milliseconds.

               L32      L33      L34      L35
           R1-------R2-------R3-------R4-------R5
                    |                |
               L46  |      L47       | L44
                    R6---------------R7

            Protected LSP:

    - If final LSP is protected LSP itself (that is, it contains
      FAST_REROUTE object), no DETOUR object needed.

    - Otherwise, combine all [R1->R2->R3->R4->R5]
            Detour LSP:    [R2->R6->R7->R4]

                 Example 3: Redirect to Detour

   In Example 3 above, if the (PLR_ID, Avoid_Node_ID) pairs from
      all link [R2->R3] fails, then R2 would do
   the DETOUR objects following.  Any traffic received on link [R1->R2] with label
   L32 would be sent out link [R2->R6] with label L46 (along the
   detour LSP) instead of all merged LSPs, out link [R3->R4] with lable L34 (along the
   protected LSP).  The Merge Point, R4, would recognize that packets
   received on link [R7->R4] with label L44 should be sent out link
   [R4->R5] with label L35, and create a new object thus merged with all listed. Ordering is insignificant.

5.4. Local reroute of the traffic onto protected LSP.

6.4 Signaling for Facility Protection

    A PLR may use one or more bypass tunnels to protect against the detour LSP

   Detour LSPs are regular LSPs
    failure of a link and/or a node.  These bypass tunnels may be
    setup in operation. They are established as
   soon advance or may be dynamically created as the new protected
    LSPs are up.  During local repair, packets
   belonging signaled.

6.4.1. Discovering Downstream Labels

   To support facility backup, it is necessary for the PLR to
   determine a protected LSP are simply switched (for example, label
   swapping) onto which will indicate to the corresponding detour LSP.  At MP that packets
   received with that label should be switched along the Merge Point, protected
   LSP.  This can be done without explicitly signaling the
   packets arrived from backup path
   if the detour LSP are merged MP uses a label space global to that LSR.

   As described in Section 5, the final LSP.

   In head-end LSR MUST set the example above, "label
   recording requested" flag in the SESSION_ATTRIBUTE object for LSPs
   requesting local protection.  This will cause (as specified in
   [RSVP- TE]) all LSRs to record their INBOUND labels and to note via
   a flag if there the label is a node failure at D, C will switch
   traffic onto global to the pre-established detour LSR.  Thus, when a protected
   LSP (C-H-I-E-F). At E, is first signaled through a PLR, the
   traffic switches onto PLR can examine the RRO in
   the Resv message and learn about the incoming labels that are used
   by all downstream nodes for this LSP.

   When MPs use per-interface-label spaces, the PLR must send Path
   messages (for each protected LSP again.

6. Facility protection using label stacked bypass tunnel

   In this section, we describe a method where a single backup tunnel
   can be used to protect many LSPs. The LSPs can be protected against
   both link and node failures.

   Each PLR makes use of one or more NHOP or NNHOP bypass tunnels.  Each tunnel) via that
   bypass tunnel will be used prior to backup a set of protected LSP.  Those
   bypass tunnels may be setup initially or may also be dynamically
   setup. The users at head-end initiate the fast reroute process by
   setting the appropriated fields failure in order to discover the SESSION_ATTRIBUTE and/or
   FAST_REROUTE objects
   appropriate MP label. The signaling procedures for this are in an LSP's Path messages. At each PLR, one
   Section 6.4.3 below.

6.4.2. Procedures for the PLR before Local Repair

   A PLR which determines to use facility-backup to protect a given
   LSP SHOULD select a bypass tunnel to use taking into account
   whether node protection is selected to reroute an LSP's data packets be provided, what bandwidth was
   requested and whether a bandwidth guarantee is desired, and what
   link attribute filters were specified in case of
   network failure. the FAST_REROUTE object.
   The process selection of selecting a bypass tunnel for a protected LSP is performed
   by the PLR when the LSP is first setup.

   During failure,

6.4.3. Procedures for the PLR during Local Repair

   When the PLR reroutes detects a link or/and node failure condition, it needs
   to reroute the data packets of each protected
   LSP traffic onto the bypass tunnel. The tunnel and to start
   sending the control messages of traffic for the backed-up
   LSPs are also sent over protected LSP onto the bypass
   tunnel.

   The facility backup uses tunnel is identified using the sender-template-specific approach
   method.  The procedures to identify the backup tunnels.

6.1. Discovering downstream labels

   When global labels follow are similar to those described in use at MPs, the PLR may learn backup labels
   in a very efficient manner.
   Section 6.3.

      - The labels are learned during normal
   signaling of the protected LSP by observing the contents of the RRO
   object in the Resv message.

   When a protected LSP SESSION is first signaled through a PLR, the PLR can
   learn about the incoming labels that are used by all downstream nodes
   for this LSP.  In particular, it can learn incoming labels used by
   downstream MPs, whether they are one hop or multiple hops away from
   the PLR. unchanged.

      - The SESSION_ATTRIBUTE is unchanged except as follows:
        The "Local protection desired", "Bandwidth protection desired",
        and "Node protection desired" flags SHOULD be cleared.
        The "Label recording desired" MAY be modified.

      - The labels are learned during normal signaling IPv4 (or IPv6) tunnel sender address of the
   protected LSP by observing the contents of SENDER_TEMPLATE
        is set to an address belonging to the RRO PLR.

      - The RSVP_HOP object in the Resv
   message.

   Two methods are available for discovering/obtaining the label used at
   the merge node.  One relies on explicit signaling over the bypass
   tunnel prior must contain an IP source address
        belonging to any failure of the primary path.  If the nodes in PLR. Consequently, the
   network use a global-to-the-node label space, then MP will send messages
        back to the label can be
   discovered by PLR using the RRO as a destination that IP address.

      - The PLR must generate an EXPLICIT_ROUTE object without additional signaling.

   When this second method is intended, toward the head-end router includes an
        egress. Detailed ERO processing is described below.

      - The RRO object may need to be updated, as described in Section
        6.5.

   The PLR sends Path, PathTear, and sets ResvConf messages via the label-recording-requested flag backup
   tunnel.  The MP sends Resv, ResvTear, and PathErr messages by
   directly addressing them to the address in the
   Session_Attribute object.  This will cause (as RSVP_HOP object
   contents as specified in [RSVP-
   TE]) all nodes [RSVP].

   If it is necessary to record their INBOUND labels and signal the backup prior to note via a flag
   if failure to
   determine the MP label is global to use, then the node.

   Note that when global labels are used, no same Path message need be sent
   via the bypass tunnel prior to failure.

   When MPs use per-interface-label spaces, is sent.
   In this case, the PLR must should continue to send Path messages (for each Reroutable LSP) via for the
   protected LSP along the normal route.   PathTear messages should be
   duplicated, with one sent along the normal route and one sent thru
   the bypass tunnel prior to tunnel. The MP should duplicate the
   failure in order Resv and ResvTear
   messages and sent them to discover both the appropriate MP label. The signaling
   procedures PLR and the LSR indicated by the
   protected LSP's RSVP_HOP object.

6.4.4. Processing backup tunnel's ERO

   Procedures for this ERO processing are identical to those described in [RSVP-TE]. This
   section 6.3 below.

6.2. Procedures describes additional ERO update procedures for the PLR before fast-reroute

   When a protected LSP in first signaled, all the PLRs along the path Path messages
   which determine to create a backup tunnel via a are sent over bypass tunnel should
   perform the following:

     - tunnels.  If normal ERO processing rules
   were followed, the "Local protection desired" bit is set in Merge Point would examine the
       SESSION_ATTRIBUTE first sub-object and there is no Fast_Reroute object, or
       there
   likely reject it (Bad initial sub-object).  This is a Fast_Reroute object with because the Facility-Backup-Desired
       flag set,
   unmodified ERO might contain the PLR should select or create IP address of a bypass tunnel for
       the reroutable LSP.

     - If bypassed node (in
   the PLR can find case of a NNHOP bypass tunnel, the PLR MUST set
       the "Node protection" bit and the "Local protection available"
       flags of its IPv4 Backup Tunnel), or IPv6 RRO subobject if of an RRO object interface which is
       included in the Resv message.

     - If
   currently down (in the PLR cannot find a NNHOP bypass tunnel, but can find case of a NHOP bypass tunnel, Backup Tunnel).  For this
   reason, the PLR must clear the "Node protection"
       bit and must set invoke the "local protection available" flags in
       the RRO object of the Resv message,

     - If the PLR can find following ERO procedures before sending a
   Path message via a bypass tunnel tunnel.

   Sub-objects belonging to abstract nodes which precede the Merge Point
   are removed, along with bandwidth guarantee, the PLR must set first sub-object belonging to the "Bandwidth protection" flag in MP.  A
   sub-object identifying the
       above mentioned RRO subobject.

     - If Backup Tunnel destination is then added.

   More specifically, the PLR cannot find a bypass tunnel with the requested
       bandwidth guarantee, must:

     - remove all the PLR must clear sub-objects proceeding the "Bandwidth
       protection" flag in first address belonging
        to the above mentioned RRO subobject.

   Based on MP.

     - replace this additional information first MP address with an IP address of the head-end may take
   appropriate actions.

   Note MP.
        (Note that when global labels are used, no Path message need this could be sent
   via the bypass tunnel prior to failure.

6.3. same address that was just removed.)

6.5. PLR Procedures for During Local Repair

   In addition to the PLR during fast-reroute

   When technique specific signaling and packet
   treatment, there is common signaling which should be followed.

   During fast reroute, for each protected LSP containing an RRO
   object, the PLR detects a link or/and node failure condition, it needs
   to reroute obtains the data traffic onto RRO from the bypass tunnel protected LSP's stored
   RESV and to start
   sending updates it by inserting an IPv4 sub-object with the control traffic for IPv4
   address of the protected LSP onto outbound interface address the bypass
   tunnel.

   The backup tunnel traffic is identified as follows:

     - The SESSION and SESSION_ATTRIBUTE are unchanged.

     - forwarded
   onto.

   The PLR MUST update the IPv4 tunnel sender address or IPv6 sub-object it
   inserted into the RRO by setting the "Local protection in use" and
   "Local Protection Available" flags.

6.5.1. Notification of local repair

   In many situations, the SENDER_TEMPLATE route used during a Local Repair will be less
   than optimal. The purpose of Local Repair is changed
       (set to an address belonging to keep high priority
   and loss sensitive traffic flowing while a more optimal re-routing of
   the PLR).

     - The RSVP_HOP object must contain tunnel can be effected by the IPv4 source address
       (and LIH) head-end of the bypass tunnel. Consequently,  Thus the MP will send
       messages back
   head-end needs to know of the PLR with HOP objects containing this same
       IPv4 address.

     - The PLR must generate failure so it may re-signal an EXPLICIT_ROUTE object toward the egress.
       Detailed ERO processing LSP
   which is described below.

     - The RRO object may need to be updated, as described below.

   Messages sent by PLR via the backup tunnel include Path, PathTear,
   and ResvConf. Messages sent by MP via the same RSVP_HOP object
   contents include Resv, and ResvTear.

6.3.1. Processing backup tunnel's ERO

   Procedures for ERO processing are described in [RSVP-TE]. If normal
   ERO processing rules are followed by the Merge Point, and optimal.

   To provide this notification, the PLR
   sends SHOULD send a Path Error
   message via the backup tunnel, the Merge Point would
   examine the first sub-object with error code of "Notify" (Error code =25) and likely reject it (Bad initial sub-
   object).

   This is because the ERO may contain the IP address an error
   value field of a bypassed node
   (in ss00 cccc cccc cccc where ss=00 and the case of sub-code = 3
   ("Tunnel locally repaired") (see [RSVP-TE])
   Additionally a NNHOP Backup Tunnel), or of head-end may also detect that an interface which is
   currently down (in LSP needs to be moved
   to a more optimal path by noticing failures reported via the IGP.
   Note that in the case of a NHOP Backup Tunnel).  For this
   reason, the PLR must update inter-area TE LSP (TE LSP spanning areas),
   the ERO before sending head-end LSR will need to rely exclusively on Path Error messages onto
   Backup Tunnels.

   This
   to be informed of failures in another area.

6.5.2 Revertive Behavior

   Upon a failure event, a protected TE LSP is done locally repaired by operating on the original ERO:

   Sub-objects belonging to abstract nodes which precede the Merge Point
   PLR.  There are removed, along with two basic strategies for restoring the first Sub-object belonging TE LSP to the MP.  A
   Sub-object identifying the Backup Tunnel destination is then added.

   More specifically, the PLR must: a
   full working path.

    - remove all the sub-objects proceeding Global revertive mode: The head-end LSR of each tunnel is
      responsible for reoptimizing the first address belonging
       to TE LSPs that used the MP. failed
      resource.  There are several potential reoptimization triggers - replace
      RSVP error messages, inspection of OSPF LSAs or ISIS LSPs, and
      timers.  Note that this first MP address with re-optimization process may proceed as
      soon as the IP destination address failure is detected.  It is not tied to the
      restoration of the backup tunnel.

   The procedure described above ensures successful ERO processing at failed resource.

    - Local revertive mode: Upon detecting that the Merge Point.

6.3.2. Processing backup tunnel's RRO

   During fast reroute, for each protected LSP containing an RRO object, resource is
      restored, the PLR must update the RRO by inserting an IPv4 sub-object with the
   IPv4 address re-signals each of TE LSPs that used to be
      routed over the backup tunnel source address in the Path
   messages.

   For each rerouted restored resource.  Every TE LSP in the backup tunnel, the PLR must update the
   RRO object in Resv messages sent upstream in successfully
      resignaled along the following manner:

     - restored resource is switched back.

   There are several circumstances where a local revertive mode might
   not be desirable. In the IPv4 or IPv6 sub-object inserted by this node, set the
       "Local protection available" and "Local protection in use" flags
       according to the current state case of resource flapping (not an uncommon
   failure type), this could generate multiple traffic disruptions.
   Therefore, in the local repair mechanism.

     - Update revertive mode, the label sub-object recording PLR should implement a
   means to dampen the INBOUND label
       (same label value re-signaling process in order to limit
   potential disruptions due to flapping.

   In the local revertive mode, any TE LSP will be switched back,
   without any distinction, as opposed to the one sent global revertive mode
   where the Resv message).

6.4. Procedures for state maintenance during fast-reroute

   We will describe how state is maintained using an example:

                [R8]
                    \
              [R1]---[R2]-X--[R3]----[R4]---[R5]
                         \\          //   \
                          [R6]===[R7]     [R9]

   We assume that:

     - a bypass tunnel decision to reuse the restored resource is set up and follows taken by the
   head-end LSR based on the TE LSP attributes. When the head-end
   learns of the failure, it may reoptimize the R2-R6-R7-R4 path;

     - PLR (R2) performs 1:N protection;

     - various protected LSPs exist LSP tunnel
   along a different and follow more optimal path, because it has a more
   complete view of the R2-R3-R4 segment;

     - link R2-R3 fails, resources and all protected LSPs are rerouted via TE LSP constraints; this means
   that the bypass tunnel. old LSP which has been reverted to may not be optimal any
   longer. Note that the same procedure as the one described bellow would apply in the case of a node (R3) failure.

6.4.1. Path state

   Path state for every locally repaired LSPs is refreshed downstream by inter-area LSP, where the PLR. These TE LSP
   path computation might be done on some Path messages use a new SENDER_TEMPLATE value (the
   IPv4 tunnel sender address is set to a PLR address), and are sent
   onto Computation Server, the bypass tunnel with changed PHOP, ERO and RRO.

   When a
   reoptimization process can still be triggered on the Head-End
   LSP. The local link fails, revertive mode is optional.

   However, there could be some are circumstances where the Head-end does not have
   the ability to reroute the TE LSP (e.g if the protected LSPs LSP is
   pinned down, as may be desirable if the paths are determined using
   this link.  At this point,
   an off-line optimization tool) or if Head-end does not have the
   complete TE topology information (depending on the LSR MUST NOT remove path computation
   scenario). In those cases, the state (Path
   and Resv) and send PathTear and ResvErr messages local revertive might be a
   interesting option.

   It is recommended that are
   corresponding to these LSPs immediately.  We one always assume use the globally revertive mode.
   Note that these
   LSPs a link or node "failure" may have been repaired upstream, and new Path messages will soon
   arrive via the bypass tunnels.

   However, the state will be removed if they have not been refreshed by
   a PLR after due to the soft-state lifetime has expired.

6.4.2. Resv state

   Resv state facility being
   permanently taken out of service.  Local revertive mode is refreshed by
   optional.  When used in combination, the MP by sending Resv messages global mode may rely
   solely on timers to do the IP
   destination contained reoptimization.  When local revertive
   mode is not used, head-end LSRs SHOULD react to RSVP error messages
   and/or IGP indications in order to make a timely response.

   Interoperability: If a PLR is configured with the PHOP object of local revertive
   mode but the Path message received
   via MP is not, any attempt from the bypass tunnel.

   The PLR receives these Resv messages, refreshes the original state
   (corresponding to resignal the protected LSP), and hence continues refreshing TE
   LSP over the state upstream of restored resource would fail as the MP will not send
   any Resv message. The PLR to will still refresh the head-end.

6.5. Local reroute of TE LSP over the traffic onto
   backup tunnel. The TE LSP will not revert to the bypass tunnel

   To perform Local Repair, packets belonging restored resource;
   instead it will continue to a protected LSP are
   sent on use the corresponding backup tunnel in case of local failure. until it is
   re-optimized.

7. Merge Node Behavior

   An additional label (representing the bypass tunnel) LSR is pushed onto
   the stack. At the penultimate hop of the bypass tunnel, a Merge Point if it receives the
   additional label Path message for a
   protected LSP and one or more messages for a backup LSP which is popped off the stack. The packet thus arrives at
   merged into that protected LSP.  In the Merge Point with one-to-one backup
   technique, the same top-level label it would have carried
   when arriving prior to failure (although LSR is aware that it would have arrived on is a
   different interface merge node prior to failure).

7. Procedures for detour and bypass tunnel computation

   To setup
   failure.  In the detours described in Section 5 and facility backup technique, the bypass tunnels in
   Section 6, CSPF LSR may be used to find the optimal route.  Before CSPF
   computation, the following information should be collected at a PLR:

     - The list of downstream nodes not know
   that it is a Merge Point until a failure occurs and it receives a
   backup LSP's Path message.  Therefore, an LSR which is on the path
   of a protected LSP passes
       through. This information SHOULD always assume that it is readily available from the
       RECORD_ROUTE objects during LSP setup. Note, a protected merge point.

   When a MP receives a backup LSP's
       ERO Path message thru a bypass
   tunnel, the Send_TTL in the Common Header may not provide adequate information since the LSP could
       be a loose routed path.

     - The downstream links/nodes that we want to protect against. Once
       again, this information is learnt from match the RECORD_ROUTE objects.

     - The upstream uni-directional links that TTL of
   the protected LSP passes
       through, this information is learnt from IP packet within which the RECORD_ROUTE
       objects. Path message was transported.  This information
   is only needed expected behavior.

7.1. Handling Backup Path Messages Before Failure

   There are two circumstances where a Merge Point will receive Path
   messages for setting up
       one-to-one protection in path-message-specific approach.

     - The LSP resource information, such as bandwidth. Such information
       can be found in the FAST_REROUTE objects.

   When applying a CSPF algorithm backup path prior to compute failure.  In the first case, if
   a PLR is providing local protection via the one-to-one backup route,
   technique, the
   following constraints should detour will be satisfied:

     - The source address of signaled and must be properly handled
   by the MP.  In this case, the backup LSP is the current PLR,
       For setting detours (Section 5), the destination MUST may be signaled via the tail-end of
   sender-template-specific method or via the protected LSP, whereas for setting up
       bypass tunnels (Section 6), path-specific method.

   In the destination MUST be second case, if the address Merge Point does not provide labels
   global to the MP and record them in a Label sub-object of the MP.

     - When setting up one-to-one protection using RRO
   or if the path-specific
       approach, a detour MUST PLR does not traverse use such recorded information, the upstream links of PLR may
   signal the protected LSP backup path, as described above in Section 6.4.1, to
   determine the same direction.  This prevents label to use if the
       possibility of early merging PLR is providing protection
   according to the facility backup technique. In this case, the
   backup LSP is signaled via the sender-template-specific method.

   The reception of a backup LSP's path message does not indicate that
   a failure has occured and the detour into incoming protected LSP will no longer
   be used.

7.1.1. Merginging Backup Paths using the Sender-Template Specific Method

   An LSR may receive multiple Path messages for one or more backup
   LSPs and, possibly, the protected LSP.

     -  Each of these Path messages
   will have a different SENDER_TEMPLATE.  The backup protected LSP cannot traverse can be
   recognized because it will either include the downstream nodes FAST_REROUTE object,
   have the "local protection desired" flag set in the
   SESSION_ATTRIBUTE object or both.

   If the outgoing interface and links next-hop LSR are the same, then the
   Path messages are eligible for merging.  As specified in [RSVP],
   only those Path messages whose ERO from that we are trying LSR to protect against. However, if the PLR egress is
   the penultimate hop, avoid traversing downstream link only.
       The detour LSP/bypass tunnel may also same can be SRLG disjoint from
       the protected section (see merged.  If merging occurs and one of the note at Path
   messages merged was for the end of this section).

     - The backup path must satisfy protected LSP, then the resource requirements final Path
   message to be sent MUST be that of the protected LSP.

   If such computation succeeds,  This merges
   the PLR should trigger RSVP to
   establish a backup path. The PLR may schedule a re-computation at a
   later time.  The backup path should be as short as possible, and must
   merge back LSPs into the protected LSP at its MP.  If for any reason, that LSR.  Once the
   PLR is unable to bring up a backup path, it must schedule a retry at
   a later time.

   The PLR final
   Path message has been identified, the option MP MUST start to apply other constraints during refresh it
   downstream periodically.

   If merging occurs and all the CSPF
   computation.  For example, a simple method can be to terminate Path messages were for backup LSPs,
   then the
   computation as soon DETOUR object, if any, should be altered as a backup path is found. On specified in
   Section 8.1

7.1.2. Merging Detours using the other hand, Path-Specific Method

   An LSR (that is, an
   implementation MP) may wish to continue exhaustive search to discover an
   optimal path receive multiple Path messages from
   different interfaces with lowest cost (or highest available bandwidth). identical SESSION and SENDER_TEMPLATE
   objects. In this case, Path state merging is REQUIRED.

   The PLR also has merging rule is the option to re-compute following:

   For all Path messages that do not have either a FAST_REROUTE or a
   DETOUR object, or the backup path
   periodically even after MP is the backup egress of the LSP, no merging is up and running to ensure
   continuous adaptation
   required.  The messages are processed according to [RSVP-TE].

   Otherwise, the latest network conditions. However,
   during MP MUST record the replacement of a functional backup path with a more
   optimal one, Path state as well as their
   incoming interface. If the protected LSP may Path messages do not have any backup path available
   for a short interval.  Except, if share outgoing
   interface and next-hop LSR, the PLR supports both one-to-one MP must consider them as independent
   LSPs, and facility backup schemes, must not merge them.

   For all the protected LSP could be protected by
   multiple backup LSPs. In this case, Path messages that share the LSP is fully protected at all
   time.

   Nevertheless, same outgoing interface and
   next-hop LSR, the exact CSPF algorithms to be used to compute back-up
   tunnels or detour LSPs are beyond MP runs the scope following procedure to select one of
   them as the Path message to forward downstream.

     1. Eliminate from consideration those that traverse nodes that
        other Path messages want to avoid.

     2. If one LSP is originated from this document. Both
   [OSPF-TE] and [ISIS-TE] may provide more insight on node, this subject.

   Note also that the backup tunnel path computation may must be performed by
   a centralized path computation server or may use some distributed
   backup path computation algorithms.

7.1. Notion of diverse routing

   Two TE LSPs are said link diverse if and
        the final LSP. Quit.

     3. If only if their paths do not
   have any link in common. Two TE LSPs one Path message contains FAST_REROUTE object, this
        becomes the chosen Path message. Quit.

     4. If there are said node diverse if several LSPs, and
   only if their paths do not all of them have any node in common. It is
   straightforward to demonstrate that two node diverse paths are also
   link diverse.

   To be effective a backup tunnel must imperatively be diversely routed DETOUR
        object, then eliminate those with DETOUR from the protected LSP path section it is protecting. That consideration.

     5. If several candidates remain (that is, a one-
   hop NHOP backup tunnel path must not contain the there are both detour
        and protected link. In
   the example provided in Section 6, LSPs), prefer the backup LSP path must not
   contain ones with FAST_REROUTE object.

     6. If none found, prefer the R2-R3 link.  A NNHOP backup tunnel must not contain ones without DETOUR object. If none
        found, prefer the
   protected link nor ones with DETOUR object.

     7. If several candidate Path message still remain, it is a local
        decision to choose which one will be the PLR's next hop. In final LSP. The decision
        can be based on the first example provided number of IP hops in Section 1, the backup tunnel must not traverse ERO, bandwidth
        requirements, or others.

   Once the R2-R3 link nor final Path message has been identified, the R3 MP MUST start to
   refresh it downstream periodically.  Other LSPs are considered merged
   at this node.

   The notion of SRLG diverse path also exists. A set of links
   constitute a SRLG ("Shared Risk Link Group") if they share a resource
   whose failure may affect all the links in the set. So  For bandwidth reservation on the backup
   tunnel may outgoing link, any
   merging should be SRLG disjoint from the considered to have occured before bandwidth is
   reserved.  Thus, even though Fixed Filter is specified, multiple
   detours and/or their protected LSP path section it is
   protecting.

   Note that in which are to be merged due to
   sharing an outgoing interface and next-hop LSR will reserve only
   the case bandwidth of the final Path message on that outgoing
   interface.

7.1.2.1. An Example on Path Message Merging

                R7---R8---R9-\
                |    |    |   \
           R1---R2---R3---R4---R5---R6
           Protected LSP:  [R1->R2->R3->R4->R5->R6]
           R2's Detour:    [R2->R7->R8->R9->R4->R5->R6]
           R3's Detour:    [R3->R8->R9->R5->R6]

           Example 4: Path Message Merging

   In Example 4 above, R8 will receive Path protection, the whole paths of messages that have the
   protected LSP
   same SESSION and the backup tunnel must be entirely link/node
   diverse.

   Well-known algorithms can be used to compute link/node/SRLG diversely
   routed paths.

8. Network Failure Detection, Notification SENDER_TEMPLATE from detours for R2 and Troubleshooting

8.1. Notification of local repair

   In many situations, the route used during R3.
   During merging at R8 since detour R3 has a Local Repair shorter ERO path length
   (that is, ERO is [R9->R5->R6], and path length is 3), R8 will be less
   than optimal. The point of
   select it as the Local Repair is to keep high priority final LSP, and loss sensitive traffic flowing while only propagate its Path messages
   downstream.  Upon receiving a more optimal re-routing of
   the tunnel can be effected by the head-end of the tunnel.  Thus Resv (or a ResvTear) message, R8 must
   relay on the
   head-end messages toward both R2 and R3.

   R5 needs to know of merge as well, and will select the failure so main LSP, since it may re-signal an LSP
   which is optimal.

   To provide this notification, the PLR SHOULD send a Path Error
   message with error code of "Notify" (Error code =25) and an error
   value field of ss00 cccc cccc cccc where ss=00 and
   has the sub-code = 3
   ("Tunnel locally repaired") (see [RSVP-TE])
   Note also that in FAST_REROUTE object.  Thus, the case of inter-area TE LSP (TE detour LSP spanning
   areas), the head-end terminates at
   R5.

7.1.3. Message Handling for Merged Detours

   When an LSR will exclusively rely on receives a ResvTear for an LSP, the Path Error
   message to be informed that LSR must determine
   whether it has an alternate associated LSP.  For instance, if the
   ResvTear was received for a protected LSP, but an associated backup
   LSP has suffered not received a failure if ResvTear, then the
   failure occurs in another area than LSR has an alternate
   associated LSP.  If the area it belongs to. In LSR does not have an alternate associated
   LSP, then the
   case of a failure occurring in MP MUST propogate the head-end area or in ResvTear toward the case of
   intra-area TE LSP, LSP's
   ingress and, for each backup LSP merged into that LSP at this LSR,
   the head-end could ResvTear should also detect be propogated along the TE LSP failure
   through backup LSP.

   The MP may receive PathTear messages for some of the IGP notification.

8.2. Failure detection mechanisms

   Link failure detection can be performed through layer-2 failure
   detection mechanism.  Node failure detection can merging LSPs.
   No PathTear message should be done through IGP
   loss of adjacency or RSVP hellos messages extensions as per defined
   in [RSVP-TE]. However, it is beyond propagated downstream until the scope MP
   has received PathTear messages for each of this document to
   define and describe the exact mechanisms on failure detection.

   When a network failure is detected, the PLR MUST immediately switch
   traffic from merged LSPs.
   However, the protected LSP to fact that one or more of the backup path. At merged LSPs has been torn
   down should be reflected in the same time, downstream message, such as by
   changing the PLR MAY send DETOUR object, if any.

7.2.  Handling Failures

   When a PathErr messages toward the head-end downstream LSR to notify
   the failure condition. The PLR MUST send detects a RESV with an updated RRO
   which indicates that local protection is in use.

8.3. Troubleshooting of local repair

   For troubleshooting purposes, an RRO object may link failure, for any
   protected LSPs routed over the failed link, Path and Resv state
   MUST NOT be inserted in cleared and PathTear and ResvErr messages MUST NOT be
   sent immediately; if this is not the
   Path message sent by case, then the head-end. The previously described
   mechanisms do facility backup
   technique will not require work.  Further a downstream LSR SHOULD reset the Path message
   refresh timers for these LSPs as if they had just been refreshed.
   This is to carry an RRO object.
   On allow time for the other hand, PLR to begin refreshing state via the RRO object
   bypass tunnel.  State MUST be inserted in removed if it has not been refreshed
   before the refresh timer expires.  This allows the facility backup
   technique to work without requiring that it signal backup paths
   thru the bypass tunnel before failure.

   After a failure has occured, the MP must still send Resv
   message messages
   for the backup LSPs associated with the protected LSPs which have
   failed.  If the backup LSP if was sent through a bypass tunnel, then
   the "Local protection desired" bit PHOP object in its Path message will have the IP address of the SESSION_ATTRIBUTE
   associated PLR. This will ensure that Resv state is refreshed.

   Once the local link has been set in recovered, the corresponding Path
   message, MP may or if FAST_REROUTE object is present in may not accept
   Path messages.

9. Interoperability considerations messages for existing protected LSPs which had failed over to
   their backup.

8.  Behavior of all LSRs

   The following guidelines are useful when running one-to-one and/or
   facility backups.

9.1. Requesting local-protection objects defined and recognizing those requests

   The head-end LSR of a protected LSP MUST either set the "Local
   protection desired" flag techniques defined in the SESSION_ATTRIBUTE object, or include
   the FAST_REROUTE object, or both.  A PLR MUST consider that a PATH
   message with either a set "Local protection desired" flag this document
   require behavior from all LSRs in the
   SESSION_ATTRIBUTE object, or the presence of the FAST_REROUTE object,
   or both to be a request for local protection.

   A PLR SHOULD consider traffic-engineered network,
   even if that LSR is not along the constraints signaled via path of a received
   FAST_REROUTE object, or protected LSP.

   First, if a received SESSION_ATTRIBUTE DETOUR object
   (Bandwidth and Node protection constraints on the bypass tunnel can
   also be specified by setting the "Bandwidth protection desired" and
   "Node protection desired" bits is included in the SESSION_ATTRIBUTE object), when
   determining the backup LSP's path to use.  If signaled backup constraints
   and bandwidth are desired, the PATH
   message SHOULD contain for the
   FAST_REROUTE object.

   A head-end LSR MUST set sender-template-specific method, the "Label recording desired" flag LSRs in the
   SESSION_ATTRIBUTE object
   traffic-engineered network should support the DETOUR object.

   Second, if a backup tunnel through a bypass tunnel the Path-Specific Method is desired.

   If local protection was not requested to be supported for
   the current LSP of a tunnel
   and one-to-one backup technique, it is then desired for necessary that tunnel, the head-end LSR MUST send a
   new Path message reflecting the change ("Local protection desired"
   flag set LSRs in
   the SESSION_ATTRIBUTE object or include a FAST_REROUTE
   object). When a node detects a change traffic-engineered network be capable of merging detours as
   specified below in the SESSION_ATTRIBUTE object
   it SHOULD forward the Path message immediately.

9.2. Backups for local protection

   A PLR that recognizes that local protection Section 8.1.

   It is required on a
   protected LSP MUST try possible to protect the LSP's data path immediately, avoid specific LSRs which do not support this
   behavior by
   either setting up assigning an one-to-one detour LSP or a bypass tunnel.

   When a network has a mix link attribute to all the links of PLRs those
   LSPs and then requesting that support either one-to-one
   backup, or facility backup, or both, backup paths exclude that link
   attribute.

8.1. Merging Detours in Path-Specific Method

   If multiple Path Messages for different detours are received with
   the same SESSION, SENDER_TEMPLATE, outgoing interface and next-hop
   LSR, then the LSR must function as a Detour Merge Point and merge
   the detour Path Messages.  This merging should occur as specified
   in Section 7.1.2 and shown in Example 4.

   In addition, it is up necessary to update the network
   operators to decide which backup mechanism DETOUR object to use.

   When using both schemes, reflect
   the PLR merging which has the option to backup data
   traffic on an one-to-one detour LSP, as well as on a bypass tunnel.
   In case of a network failure, the PLR can re-reroute traffic taken place.  This is done using
   one of the two backup path initially. If the backup path failed also, the other backup path can be used
   following algorithm to re-reroute user traffic.

   If no established detour LSP or backup tunnel exists, or format the detour
   LSP and outgoing DETOUR object for the backup tunnel is in "DOWN" state,
   final LSP:

     - Combine all the PLR MUST clear (PLR_ID, Avoid_Node_ID) pairs from all the
   "local protection available" flag in its IPv4 (or IPv6) address
   subobject
       DETOUR objects of the RRO all merged LSPs, and SHOULD send the updated RESV.  When create a detour
   LSP or backup tunnel new object with
       all listed. Ordering is established, the PLR MUST set the "local
   protection available" flag and the appropriated "bandwidth
   protection" and "node protection" bits, and SHOULD send the updated
   Resv.

10. insignificant.

9. Security Considerations

   This document does not introduce new security issues. The security
   considerations pertaining to the original RSVP protocol [RSVP] remain
   relevant.

11.

   It should be noted that the facility backup technique requires that
   a PLR and its selected Merge Point will trust RSVP messages
   received from each other.

10. IANA Guidelines

   IANA [RFC-IANA] will assign RSVP C-class numbers for FAST_ROUTE and
   DETOUR objects.  Currently, in production networks, FAST_REROUTE uses
   C-class 205, and DETOUR uses C-class 63.

12.

11. Intellectual Property Considerations

   Cisco Systems and Juniper Networks may have intellectual property
   rights claimed in regard to some of the specification contained in
   this document

13.

12. Full Copyright Statement

   Copyright (C) The Internet Society (2002). 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.

14.

13. Acknowledgments

   We would like to acknowledge the input and helpful comments from Arthi Ayyangar, Riza Cetin, Rob
   Goguen, Carol Iturralde, Kireeti Kompella, Manoj Leelanivas, Tony Li, Yakov Rekhter and Nischal Sheth.

15. Curtis Villamizar.  Especially,
   we thank those, who have been involved in interoperability testing
   and field trails, and provided invaluable ideas and suggestions.
   They are Rob Goguen, Carol Iturralde, Brook Bailey, Safaa Hasan,
   and Richard Southern.

14. References

   [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP)
   -- version 1 functional specification," RFC2205, September 1997.

   [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP
   tunnels", RFC3029, December 2001.

   [RFC-WORDS]  Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, March 1997.

   [OSPF-TE] Katz, Yeung, Traffic Engineering Extensions to OSPF, draft-
   katz-yeung-ospf-traffic-05.txt,
   draft-katz-yeung-ospf-traffic-05.txt, June 2001.

   [ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft-
   ietf-isis-tr affic-03.txt, June 2001.

   [RSVP-REFRESH]  L. Berger, et al, "RSVP Refresh Overhead Reduction
   Extensions", RFC2961.

   [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an
   IANA Considerations Section in RFCs", RFC 2434.

16.

15. Author Information

   Ping Pan
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale,
   CIENA Corp.
   10480 Ridgeview Court
   Cupertino, CA 94089 95014
   e-mail: pingpan@juniper.net ppan@ciena.net
   phone: +1 408 745 3704 366 4991

   Der-Hwa Gan
   Juniper Networks
   1194 N.Mathilda Ave
   Sunnyvale, CA 94089
   e-mail: dhg@juniper.net
   phone: +1 408 745 2074

   George Swallow
   Cisco Systems, Inc.
   250 Apollo Drive
   Chelmsford, MA 01824
   email:  swallow@cisco.com
   phone:  +1 978 244 8143

   Jean Philippe Vasseur
   Cisco Systems, Inc.
11, rue Camille Desmoulins
92782  Issy les Moulineaux Cedex 9,
France
   300 Apollo Drive
   Chelmsford, MA 01824
   email: jvasseur@cisco.com jpv@cisco.com
   phone: +33 689108267  +1 978 497 6238

   Dave Cooper
   Global Crossing
   960 Hamlin Court
   Sunnyvale, CA 94089
   email: dcooper@gblx.net
   phone: +1 916 415 0437

   Alia Atlas
   Avici Systems
   101 Billerica Avenue
   N. Billerica, MA 01862
   email: aatlas@avici.com
   phone: +1 978 964 2070

   Markus Jork
   Avici Systems
   101 Billerica Avenue
   N. Billerica, MA 01862
   email: mjork@avici.com
   phone: +1 978 964 2142