Network Working Group Atsushi Iwata Internet Draft Norihito Fujita Tetsurou Nishida Expiration Date: January 2002 NEC Corporation July 2001 MPLS Signaling Extensions for Shared Fast Rerouting 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 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. Iwata,et al. draft-iwata-mpls-shared-fastreroute-00 [Page 1] Internet Draft July 2001 Abstract This document proposes an enhanced scheme for fast rerouting which provides means of quickly repairing LSPs in cases of link/node failures. It also provides for the sharing of backup LSPs and their resources and thus allows minimization of requirements for backup resources. Several schemes for performing fast local repair (i.e., fast reroute) have been proposed to minimize the overhead of LSP restoration as well as the overhead of backup LSP computation. These schemes provide a way to establish a backup LSP from any node along the primary path. However, they also require the allocation of dedicated network resources for each backup LSP and these resources cannot be shared. Thus, the backup network resources should be shared as much as possible to increase network efficiency while guaranteeing the recoverability of LSPs. On the other hand, a general concept of sharing links along backup paths has already been proposed, and its requirements in terms of link state information and signaling functions have been outlined. Therefore, this document utilizes this concept of sharing backup LSPs and specifically applies the concept to the fast-reroute scenario. We propose new shared fast-reroute signaling extensions to RSVP-TE signaling. Furthermore, we extend the basic idea of this shared fast-reroute LSPs to support multiple load- balanced primary LSPs having backup LSPs shared among these primary LSPs. The additional signaling extensions for this purpose are also described in this document. Table of Contents Page 1. Introduction 3 2. Overview 5 2.1 Shared fast-reroute LSPs for a single primary LSP 5 2.2 Shared fast-reroute LSPs for multiple load-balanced 6 primary LSPs 2.3 Signaling overview 7 2.3.1 Distributed computation mode initiated 7 by ingress node 2.3.2 Ingress centric computation mode initiated 12 by ingress node 2.3.3 Distributed computation mode initiated 13 by egress node 3. RSVP-TE Signaling Extension 15 4. CR-LDP Signaling Extension 15 5. Security Considerations 15 6. References 16 Iwata,et al. draft-iwata-mpls-shared-fastreroute-00 [Page 2] Internet Draft July 2001 1. Introduction The quick restoration or rerouting of a label switched path (LSP) around failed links and nodes has been regarded as an extremely important feature to users. When links or nodes fail, user traffic must be switched over a detour path (i.e., recovery path) within a very short time. It is possible to initiate such a detour path by using any of the following three approaches [SHARMA], (1) pre- established, (2) pre-qualified, and (3) established-on-demand. The first option (1) is the same as the protection-switching option, in which a recovery path is established in advance of possible failures on the working path (i.e., primary path). This option is considered to be the most desirable in terms of quick recovery of data traffic in cases where packet loss is undesirable. Furthermore, in order to provide the shortest possible LSP switch-over time, the decision to take the detour must be made as close to the failure point as possible, since it may take a significant amount of time to notify other nodes (such as the ingress node) of the LSP of such failure. Two schemes for performing fast local repair (i.e., fast reroute ) have been proposed to minimize the overhead involved in LSP restoration [GAN],[HASKIN]. In the first approach [GAN], the backup LSPs originate from (N-1) nodes along the primary path and are node- disjoint paths from the primary path, where N is the number of hops that the LSP traverses. It also acts to automatically merge the backup LSPs with the primary LSP to make as short a path as possible to minimize the overhead involved in LSP computation. The second approach [HASKIN] is to reverse traffic at the point of failure along the protected LSP back to the ingress node of the primary path (i.e., the protected LSP), so that it is possible to redirect the traffic flow via a parallel (node-disjoint) backup LSP that runs between the ingress and egress nodes of the primary LSP path. Thus, in this approach, a backup LSP that runs back to the ingress node of the primary path is established in addition to the other backup LSP from the ingress to egress node. Both approaches are capable of providing the quick restoration, in time of the order of 50 milliseconds that is provided in SONET self- healing rings, and of simultaneously minimizing the complexity and signaling requirements involved in computing alternative paths. However, dedicated network resources must be allocated for each of the backup LSPs and it is not possible to share these resources in the current form. For a restoration objective such as recovery from the single link failure, it is possible to share links along the backup LSP among different backup LSPs in such a way that recovery from the single link failure is guaranteed. Thus, in order to efficiently use network resources, the backup network resources must be shared as much as possible while guaranteeing recoverability of Iwata,et al. draft-iwata-mpls-shared-fastreroute-00 [Page 3] Internet Draft July 2001 LSPs in cases of network failure. On the other hand, a general concept of the sharing of links along backup paths has already been proposed [KINI], and its requirements in terms of link state information and signaling functions have been described. In this concept, the entity for which protection from failure is provided could be a link, node, or shared risk link group (SRLG). This concept allows sharing of the LSP resources of the links of the backup LSP among the backup LSPs of other primary LSPs to guarantee restoration of LSPs in the event of failures in single links, nodes, or SRLGs. However, for sharing of backup LSPs of other primary LSPs, the link state routing protocol, for example OSPF or ISIS, has to be extended to include a few new information elements. Additionally, new algorithms for the establishment of shared backup LSPs must be based on this information. In the work reported upon in this document, this concept of shared backup LSPs has been applied to the fast-reroute scenario. Thus, we propose an enhanced fast-reroute scheme which provides quick repair of LSPs in cases of link/node failures and also provides the capability of sharing backup LSP resources (e.g., label ID and bandwidth etc.) so that the requirement for backup resources is minimized. The way of sharing the LSP resources has two possibilities: (1) all LSP resources including label ID and bandwidth information and (2) part of LSP resources such as only bandwidth information. In case of (1), the action of the label merge of different backup LSPs will be used, and in case of (2), the logical bandwidth sharing would be enough among different backup LSPs. To minimize the computational overhead imposed by the shared backup LSPs, (1) the backup fast-reroute LSPs that originate from any node along a "SINGLE PRIMARY LSP" are at least shared as much as possible, (2) if computational complexity allows, the backup LSPs that originate from "OTHER PRIMARY LSPs" are also shared by using the [KINI] scheme. Note that the computation involved in (1) is much simpler than that involved in (2). This is because, with the approach (1), the full path information on the primary LSP and fast-reroute backup LSPs are available. This allows easy computation of the shared path in an efficient way. Thus, applying the approach (1) alone, it is not necessary to extend the OSPF or ISIS routing protocol for sharing links. We also outline new signaling procedures for RSVP-TE signaling [RSVP- TE] that allows the implementation of shared-path-based fast rerouting of LSPs (i.e. shared fast-reroute LSPs). The proposed procedures are used to compute and establish the shared fast-reroute LSPs in a distributed fashion, and are used to continuously adapt to the latest topology without manual intervention. Furthermore, we Iwata,et al. draft-iwata-mpls-shared-fastreroute-00 [Page 4] Internet Draft July 2001 extend the basic idea of such shared fast-reroute LSPs to support multiple load-balanced primary LSPs that have shared backup LSPs. The additional signaling procedures used for this purpose are also described in this document. A similar approach is applicable to CR- LDP [CR-LDP] signaling. 2. Overview In Section 2.1 and 2.2, examples are used to illustrate the shared fast-reroute LSP schemes. Section 2.3 outlines an RSVP-TE signaling procedure that establishes fast-reroute backup LSPs that are shared as much as possible while still guaranteeing single link / node failure recovery. 2.1 Shared fast-reroute LSPs for a single primary LSP Figure 1 illustrates a simple case where backup fast-reroute LSPs (depicted as 1st, 2nd, 3rd, and 4th in the figure) originate from the ingress, node 2, node 3, and node 4, and move towards the egress. Each backup LSP includes shared network resources (depicted as 1st (w/end), 1st (w/2nd,3rd), 1st (w/2nd,3rd,4th)). The backup fast- reroute LSPs (ingress to egress, node 2 to egress, node 3 to egress, and node 4 to egress) include common links and nodes, which are shared among these backup LSPs. This formation of fast-reroute LSPs is the same as a specific option in [GAN], since that scheme allows the use of any node along the primary path in establishing a fast-reroute LSP towards any downstream node of an LSP which is more than one hop away from the current node. Figure 1 is a specific case of [GAN] where any node along the primary path tries to establish a fast-reroute LSP toward the egress node such that the backup fast-reroute LSPs which originate from different nodes along the same primary path can be maximally shared to minimize the requirement for backup network resources. Choosing the egress node as the merge point of the fast- reroute LSPs also makes easy to optimize the computation of the backup LSP paths. Ingress====> Node 2====> Node 3====> Node 4====> Egress v v v v ^ |1st |2nd |3rd |4th | | v v v ^ +---------->+**********>+**********>+**********>+ 1st 1st(w/2nd) 1st(w/2nd,3rd) 1st(w/2nd,3rd,4th) Primary LSP (Main RSVP Path) =====> Fast reroute LSPs (Detours) -----> Iwata,et al. draft-iwata-mpls-shared-fastreroute-00 [Page 5] Internet Draft July 2001 Shared parts of reroute LSPs *****> Merge point + Figure 1: Example of shared fast-reroute LSPs 2.2 Shared fast-reroute LSPs for multiple load-balanced primary LSPs Figure 2 illustrates a case where two primary LSPs are established from the ingress to the egress and are used in a load-balanced mode in which x % of traffic is forwarded through one primary LSP and (100-x) % of traffic is through the other primary LSP based on the network load condition. On one side of the primary LSP (depicted as primary #1), the backup fast-reroute LSPs originate from any node along the primary path and run towards the egress to allow sharing of the links and nodes of the other primary LSP (depicted as primary #2). For example, as shown in Fig. 2, primary paths #1 and #2 originate from the ingress and path through nodes 2, 3, and 4 to the egress, and from the ingress through nodes 5, 6, and 7 to the egress, respectively. The backup fast-reroute LSPs of primary path #1 originate from nodes 2, 3, and 4 and run through node 5, 6 and 7 toward egress, and this path shares several links and nodes with primary path #2. The backup fast-reroute LSPs of primary path #2 originate from nodes 5, 6, and 7 and run through nodes 2, 3 and 4 towards the egress, and this path shares several links and nodes with primary path #1. In this example, it is not possible for primary path #1 and backup fast-reroute path #2 to share the bandwidth and each required bandwidth should be allocated in order to guarantee the recovery from failure. Other resources such as label IDs, however, can be shared between them. When the same label ID is used on the primary path #1 and the backup fast-reroute path #2, it means that the backup fast- reroute path #2 has merged with primary path #1. In this case, the bandwidth that has been pre-established for primary LSP #1 must be increased to accommodate backup fast-reroute path #2. Note that it is possible to share any of the nodes of primary path #1 with backup fast-reroute LSP #2 (originated from node 5, 6, and 7) in the same manner as is shown in example of Fig. 1. Although Fig. 2 shows an example with two load-balanced primary LSPs, the same scheme can be extended to support N load-balanced primary LSPs with N shared fast-reroute LSPs as backup paths. There are several options in establishing such shared fast-reroute backup LSPs. The details of these options will be given in a future document. Iwata,et al. draft-iwata-mpls-shared-fastreroute-00 [Page 6] Internet Draft July 2001 ============> Primary #1 ************> Backup #2 (for Primary #2) ________ _____ _____ _____ _______ | | | | | | | | | | |Ingress |===>|Node2|====>|Node3|====>|Node4|====>|Egress | |________|***>|_____|****>|_____|****>|_____|****>|_______| V V v ^ v ^ v ^ ^ | |1st 2nd| * 3rd| * 4th| * | | | | * | * | * | | | | * | * | * | | | _v_^_ _v_^_ _v_^__ | | ------->| |---->| |---->| |-------->+ + ========>|Node5|====>|Node6|====>|Node7|========>+ |_____| |_____| |_____| -------------> Backup #1 (for Primary #1) =============> Primary #2 Primary load-balanced LSPs =====> Fast reroute LSPs (detours) -----> ******> Figure 2: Example of shared fast-reroute LSPs as backups for multiple load-balanced primary LSPs 2.3 Signaling procedure overview Section 2.3.1 through 2.3.3 outline three modes of RSVP-TE signaling procedures that can be used in establishing fast-reroute backup LSPs that are shared as much as possible while guaranteeing recovery from the failure of a single link or node. For simplicity, the case of Figure 1 (a single primary LSP with backup fast-reroute LSPs) is mainly used as an example. 2.3.1 Distributed computation mode initiated by the ingress node The first mode is the distributed computation mode which is initiated by the ingress node. Figures 3 and 4 give an overview of the signaling procedure of this first mode. Figure 3 applies to shared fast-reroute LSPs for a single primary LSP. The primary LSP from ingress to egress is established by a normal RSVP-TE signaling procedure. Once the primary LSP has been established from the ingress to run through nodes 2, 3, and 4 to the egress, the ingress node issues a PATH message with node-disjoint explicit route object (ERO) (e.g., ingress - node 5 - node 6 - node 7 - egress) of the pre-established primary path to the egress in order to create the 1st backup fast-reroute LSP. This path will be used for Iwata,et al. draft-iwata-mpls-shared-fastreroute-00 [Page 7] Internet Draft July 2001 any other backup fast-reroute LSPs, that originate from other downstream nodes along the primary path, so that network resources are maximally shared. Once the 1st backup fast-reroute LSP has been established, the ingress node issues the "Backup LSP Trigger" message (a new message, to be determined) to the one hop downstream node (node 2) along this primary path. This Backup LSP Trigger message includes the ERO object of the established 1st backup-reroute LSP so that other nodes are able to perform the shared path computation. Node 2, receiving the Backup LSP Trigger message, computes a new fast-reroute LSP that runs towards the egress node so that this calculated LSP maximally shares the links and nodes of the existing 1st backup fast-reroute LSP. It then sends a new PATH message toward the Egress node with a new ERO. If node 5, which is an intermediate node along the 1st fast-reroute LSP, receives this PATH message, it sends back an RESV message to node 2 and merges the 2nd fast-reroute LSP on its upstream side with the 1st fast-reroute LSP. When node 2 receives the RESV message, it forwards the Backup LSP Trigger message to the one-hop downstream node, in this case, node 3. The same procedure is carried out by nodes 3 and 4, and then the Backup LSP Trigger message finally reaches the Egress node, which responds to the ingress node with a notification of the results of the whole procedure of setting up the backup fast-reroute LSP. Ingress====> Node2 ====> Node3 ====> Node4 ====> Egress v v v v ^ |1st |2nd |3rd |4th | | v v v ^ +--------> Node5 ****> Node6 ****> Node7 ******>+ 1st 1st(w/2nd) 1st(w/2nd,3rd) 1st(w/2nd,3rd,4th) Ingress Node5 Node6 Node7 Egress | PATH | | | | 1st |-----------|-----------|-----------|---------->| Backup |<----------|-----------|-----------|-----------| Path | RESV | | | | | | | | | | Node2 | | | | 2nd | |PATH | | | | Backup |====>|---->* | | | Path | |<--- | | | | | |RESV | Node3 | | | 3rd | | | |PATH | | | Backup | |=====|====>|---->* | | Path | | | |<--- | | | Iwata,et al. draft-iwata-mpls-shared-fastreroute-00 [Page 8] Internet Draft July 2001 | | | |RESV | Node4 | | 4th | | | | | |PATH | | Backup | | | |=====|====>|---->* | Path | | | | | |<----| | | | | | | |RESV | | | | | | | | | | | | | | | |=====|==========>| |<====|=====|=====|=====|=====|=====|===========| | | | | | | | | PATH/RESV for Backup LSPs: ------> Backup LSP Trigger message: ======> Merge points: * Figure 3: Example of the distributed computation mode initiated by ingress node Figure 4 applies to shared fast-reroute LSPs for multiple load- balanced primary LSPs. As a simple example, we assume that these primary LSPs are node-disjoint paths which may be applied to protection switching. If these LSPs are not node-disjoint paths, the following description requires some changes. The primary LSPs, #1 and #2, run from ingress to egress and are both established by a normal RSVP-TE signaling procedure. Primary LSP #1 is established from the ingress through nodes 2, 3, and 4 to the egress, and primary LSP #2 is established from the ingress through nodes 5, 6, and 7 to the egress. Here, we only describe the procedure used to make a fast-reroute backup LSP for primary LSP #1. The backup LSP for the other primary LSP, #2, can be created according to the same procedure as is described below. The ingress node issues a PATH message with node-disjoint ERO (e.g., ingress - node 5 - node 6 - node 7 - egress) of the established primary path #1, which is actually the same as the ERO of primary path #2 in this example, to the egress in order to create the 1st backup fast-reroute LSP. This 1st backup fast-reroute LSP will be used by other backup fast-reroute LSPs, which originate from other downstream nodes along the primary path #1, so that network resources are maximally shared. As described below, this 1st backup fast-reroute LSP could be arranged to be merged with primary LSP #2 by sharing the label ID. Once the 1st backup fast-reroute LSP has been established, the ingress node issues the "Backup LSP Trigger" message to the one hop downstream node (node 2) along this primary path. This Backup LSP Trigger message includes the ERO object of the established 1st backup-reroute LSP so that other nodes are able to perform the shared path computation. Node Iwata,et al. draft-iwata-mpls-shared-fastreroute-00 [Page 9] Internet Draft July 2001 2, receiving the Backup LSP Trigger message, computes a new fast- reroute LSP that runs towards the egress node so that this calculated LSP maximally shares the links and nodes of the existing 1st backup fast-reroute LSP. It then sends a new PATH message toward the Egress node with a new ERO. If node 5, which is an intermediate node along the 1st fast-reroute LSP, receives this PATH message, it sends back an RESV message to node 2 and merges the 2nd fast-reroute LSP on its upstream side with the 1st fast-reroute LSP. When node 2 receives the RESV message, it forwards the Backup LSP Trigger message to the one- hop downstream node, in this case, node 3. The same procedure is carried out by nodes 3 and 4, and then the Backup LSP Trigger message finally reaches the Egress node, which responds to the ingress node with a notification of the results of the whole procedure of setting up the backup fast-reroute LSP. Now, there is a choice in the merging of backup fast-reroute LSPs. The first possibility is for backup fast-reroute LSPs and primary LSP #2 not to share label resources. Label resources are maintained independently between these LSPs in this case. The second possibility is that both label resources are shared, so that the same label ID is used for both paths and the total amount of bandwidth has to be increased to accommodate both LSPs. This second possibility thus requires the LSP modification [ASH] capabilities, i.e., the addition of extra bandwidth to allow merging of the backup fast-reroute LSPs with primary path #1. ============> Primary #1 ************> Backup #2 (for Primary #2) ________ _____ _____ _____ _______ | | | | | | | | | | |Ingress |===>|Node2|====>|Node3|====>|Node4|====>|Egress | |________|***>|_____|****>|_____|****>|_____|****>|_______| V V v ^ v ^ v ^ ^ | |1st 2nd| * 3rd| * 4th| * | | | | * | * | * | | | | * | * | * | | | _v_^_ _v_^_ _v_^__ | | ----->| |---->| |---->| |-------->+ ========>|Node5|====>|Node6|====>|Node7|========>+ |_____| |_____| |_____| -------------> Backup #1 (for Primary #1) =============> Primary #2 Ingress Node5 Node6 Node7 Egress Node2 Node3 Node4 | | | | | | | | Iwata,et al. draft-iwata-mpls-shared-fastreroute-00 [Page 10] Internet Draft July 2001 |PATH | | | | | | | |(P#1)| | | | | | | Primary |---->|-----|---->|-----|---->|-----|---------->| #1 LSP |<----|<----|-----|<----|-----|<----|-----------| | | | | | |RESV | | |PATH | | | | |(P#1)| | |(P#2)| | | | | | | Primary |-----|---->|-----|---->|-----|---->|---------->| #2 LSP |<----|-----|<----|-----|<----|-----|<----------| | | | | | |RESV | | | | | | | |(P#2)| | |PATH | | | | | | | P#1 1st |-----|---->|-----|---->|-----|---->|---------->| Backup |<----|-----|<----|-----|<----|-----|<----------| ERO=P#2 | | | | | | |RESV | | |PATH | | | | | | P#1 2nd |====>|---->* | | | | | Backup | |<----| | | | | | Path | |RESV | | | | | | | | | |PATH | | | | P#1 3rd | |=====|====>|---->* | | | Backup | | | |<----| | | | Path | | | |RESV | | | | | | | | | |PATH | | P#1 4th | | | |=====|====>|---->| | Backup | | | | | |<----| | Path | | | | | |RESV | | | | | | | | | | | | | | | |=====|==========>| |<====|=====|=====|=====|=====|=====|===========| | | | | | | | | |PATH | | | | | | | P#2 1st |---->|-----|---->|-----|---->|-----|---------->| Backup |<----|<----|-----|<----|-----|<----|-----------| ERO:P#1 | | | | | | |RESV | | | | | | | | | ~ ~ ~ ~ ~ ~ ~ ~ | | | | | | | | PATH/RESV for Primary /Backup LSP : ------> Backup LSP Trigger message : ======> Merge points: * Figure 4: Example of the distributed computation mode initiated by the egress node (fast-reroute for multiple load-balanced LSPs) Iwata,et al. draft-iwata-mpls-shared-fastreroute-00 [Page 11] Internet Draft July 2001 2.3.2 Ingress-centric computation mode initiated by the ingress node The second mode is the Ingress-centric computation mode initiated by the ingress node. Figure 5 gives an overview of the signaling procedure of this second mode. The example applies to a backup fast- reroute LSP for a single primary LSP. The primary LSP and fist backup fast-reroute LSP are established in the same way as in the first mode. The main difference from the first mode is that the ingress node controls the establishment of the backup fast-reroute LSPs by using the Backup LSP Trigger message. The reason of introducing this mode is that there might be a case where it might be difficult for any node along the primary path to compute the backup paths in a distributed manner due to topological constraints. In such a case, this mode allows the ingress node to compute the shared backup paths in a centralized way for increasing the possibility to find such paths. In the first mode, when node 2 receives the RESV message from node 5, node 2 forwards the Backup LSP Trigger message to the one hop downstream node, node 3. In this second mode, however, node 2 sends a Backup LSP Trigger Acknowledgment message to the ingress. The ingress node issues the "Backup LSP Trigger" message to the one- hop downstream node from node 2, node 3, along this primary path. This Backup LSP Trigger message includes the ERO object of the established 1st backup-reroute LSP so that other nodes are able to perform the shared path computation. Node 3, receiving the Backup LSP Trigger message, computes a new fast-reroute LSP that runs towards the egress node so that this calculated LSP maximally shares the links and nodes of the existing 1st backup fast-reroute LSP. It then sends a new PATH message toward the Egress node with a new ERO. If node 6, which is an intermediate node along the 1st fast-reroute LSP, receives this PATH message, it sends back an RESV message to node 3 and merges the 3rd fast-reroute LSP on its upstream side with the 1st fast-reroute LSP. When node 3 receives the RESV message, it sends the Backup LSP Trigger Acknowledgment message back to the ingress. The same procedure is carried out by node 4. Ingress====> Node2 ====> Node3 ====> Node4 ====> Egress v v v v ^ |1st |2nd |3rd |4th | | v v v ^ +--------> Node5 ****> Node6 ****> Node7 ******>+ 1st 1st(w/2nd) 1st(w/2nd,3rd) 1st(w/2nd,3rd,4th) Ingress Node5 Node6 Node7 Egress Iwata,et al. draft-iwata-mpls-shared-fastreroute-00 [Page 12] Internet Draft July 2001 | PATH | | | | 1st |-----------|-----------|-----------|---------->| Backup |<----------|-----------|-----------|-----------| Path | RESV | | | | | | | | | | Node2 | | | | 2nd | |PATH | | | | Backup |====>|---->* | | | Path |<=== |<--- | | | | | |RESV | Node3 | | | 3rd | | |PATH | | | Backup |===========|====>|---->* | | Path |<==========|==== |<--- | | | | | |RESV | Node4 | | 4th | | | |PATH | | Backup |===========|===========|====>|---->* | Path |<==========|===========|=====|<----| | | | | |RESV | | PATH/RESV for Backup LSPs: ------> Backup LSP Trigger message: ======> Merge points: * Figure 5: Example of ingress-centric computation mode initiated by the ingress node 2.3.3 Distributed computation mode initiated by the egress node The third mode is the distributed computation mode initiated by the egress node. Figure 6 gives an overview of the the signaling procedure of this third mode. The example applies to a backup fast- reroute LSP for a single primary LSP. The main difference between the first and second modes is the timing with which the primary LSP and backup fast-reroute LSPs are established. In the first and second modes, the primary LSP is established at first, and the establishment of the backup fast-reroute LSPs follows. In this third mode, on the other hand, the primary LSP and fast-reroute LSPs are established simultaneously. The ingress node issues the PATH message for the primary LSP to the egress node. The egress node sends back the RESV message to the one- hop upstream node, node 4. Node 4, on receiving the RESV message, allocates the label resources for the primary LSP and then computes a backup fast-reroute path that originates from itself. It issues another PATH message with a node-disjoint ERO object to establish a backup fast-reroute LSP that runs towards the egress node. Once the backup fast-reroute LSP (4th backup LSP) (node 4 - node 7 - egress) has been established, node 4 sends the RESV message for the primary Iwata,et al. draft-iwata-mpls-shared-fastreroute-00 [Page 13] Internet Draft July 2001 LSP to a node which is one-hop upstream, node 3. This RESV message may include the ERO object optionally that node 4 has computed for the backup fast-reroute LSP. This ERO object will be used for maximally sharing of the backup-path resources of the network in the following steps. Node 3, on receiving the RESV message with ERO object that has been specified by node 4, allocates the label resources for the primary LSP. Node 3 computes the backup fast-reroute LSP that originates from itself by using the ERO object that has been specified by node 4. It then issues another PATH message to set up a path that runs towards the egress node with ERO (node 3 - node 6 - node 7 - egress). If node 7, which is an intermediate node along the 4th fast-reroute LSP, receives this PATH message, it sends back an RESV message to node 3 through node 6 and merges the 3rd fast-reroute LSP on its own upstream side with the 4th fast-reroute LSP. When node 3 receives the RESV message, it forwards the RESV message for the primary path to a node which is one-hop upstream, node 2. After that, the same procedures is applied by node 2 and the ingress. Finally, the primary LSP and the backup fast-reroute LSPs have been established. Ingress====> Node 2====> Node 3====> Node 4====> Egress v v v v ^ |1st |2nd |3rd |4th | | v v v ^ +--------> Node 5****> Node 6****> Node 7******>+ 1st 1st(w/2nd) 1st(w/2nd,3rd) 1st(w/2nd,3rd,4th) Ingress Node5 Node6 Node7 Egress Node2 Node3 Node4 | | | | | | | | |PATH | | | | | | | |(P) | | | | | | | Primary |---->|-----|---->|-----|---->|-----|---------->| LSP | | | | | |<----|-----------| Path | | | | | |RESV | | | | | | | |(P) | | | | | | | | | | | | | | | |PATH | | | | | | | |(B) | | 4th | | | |RESV | |====>|==========>| Backup | | | |(P) | |<====|<==========| Path | | | |<----|-----|RESV | | | | | |PATH | |(B) | | | | | |(B) | | | | Iwata,et al. draft-iwata-mpls-shared-fastreroute-00 [Page 14] Internet Draft July 2001 3rd | |RESV | |====>|=====|====>* | Backup | |(P) | |<====|<====|=====| | Path | |<----|-----|RESV | | | | | |PATH | |(B) | | | | | |(B) | | | | | | 2nd |RESV |====>|=====|====>* | | | Backup |(P) |<====|=====|=====| | | | Path |<----|RESV | | | | | | |PATH |(B) | | | | | | |(B) | | | | | | | 1st |=====|====>* | | | | | Backup |<====|=====| | | | | | Path |RESV | | | | | | | |(B) | | | | | | | PATH/RESV for Primary LSP : ------> PATH/RESV for Backup LSPs : ======> Merge points: * Figure 6: Example of distributed computation mode initiated by the egress node 3. RSVP-TE Signaling Extension 3.1 New objects To be determined. 3.2 New Message Formats To be determined. 4. CR-LDP Signaling Extension 4.1 New TLVs To be determined. 4.2 New Message Formats To be determined. 5. Security Considerations This document does not introduce new security considerations to the existing system of MPLS-TE signaling (RSVP-TE [RSVP-TE], CR-LDP [CR- Iwata,et al. draft-iwata-mpls-shared-fastreroute-00 [Page 15] Internet Draft July 2001 LDP]). 6. References [SHARMA] V. Sharma et al., "Framework for MPLS-based Recovery," work in progress , March 2001 [GAN] D. Gan et al., "A Method for MPLS LSP Fast-Reroute Using RSVP Detours," work in progress , April 2001. [HASKIN] D. Haskin et al., "A Method for Setting Alternative Label Switched Paths to Handle Fast Reroute," work in progress , November 2000 [KINI] S. Kini et al., "Shared Backup Label Switched Path Restoration," work in progress , May 2001 [RSVP] R. Braden, et al., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification, RFC2205, September 1997. [RSVP-TE] D. Awduche, et al., "Extensions to RSVP for LSP Tunnels," work in progress , February 2001. [LDP] L. Andersson, et al., "LDP Specification," RFC3036, January 2001. [CR-LDP] B. Jamoussi, et al., "Constraint-Based LSP Setup using LDP," work in progress , February 2001. [ASH] G. Ash, et al., "LSP Modification Using CR-LDP", work in progress , March 2001. 7. Authors' Addresses Atsushi Iwata NEC Corporation Networking Research Laboratories 1-1, Miyazaki, 4-Chome, Miyamae-ku, Kawasaki, Kanagawa, 216-8555, JAPAN Phone: +81-(44)-856-2123 Fax: +81-(44)-856-2230 Iwata,et al. draft-iwata-mpls-shared-fastreroute-00 [Page 16] Internet Draft July 2001 Email: a-iwata@ah.jp.nec.com Norihito Fujita NEC Corporation Networking Research Laboratories 1-1, Miyazaki, 4-Chome, Miyamae-ku, Kawasaki, Kanagawa, 216-8555, JAPAN Phone: +81-(44)-856-2123 Fax: +81-(44)-856-2230 Email: n-fujita@bk.jp.nec.com Tetsurou Nishida NEC Corporation IP Software Technology Division 1131, Hinode, Abiko, Chiba 270-1198, JAPAN Phone: +81-(471)-82-1111 Fax: +81-(471)-85-6881 Email: nishida@ay.jp.nec.com Iwata,et al. draft-iwata-mpls-shared-fastreroute-00 [Page 17]