Internet DRAFT - draft-iwata-mpls-shared-fastreroute
draft-iwata-mpls-shared-fastreroute
Network Working Group Atsushi Iwata
Internet Draft Norihito Fujita
<draft-iwata-mpls-shared-fastreroute-00.txt> Tetsurou Nishida
Expiration Date: January 2002 NEC Corporation
July 2001
MPLS Signaling Extensions for Shared Fast Rerouting
<draft-iwata-mpls-shared-fastreroute-00.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 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 <draft-ietf-mpls-recovery-frmwrk-02.txt>, March 2001
[GAN] D. Gan et al., "A Method for MPLS LSP Fast-Reroute Using RSVP
Detours," work in progress <drat-gan-fast-reroute-00.txt>, April
2001.
[HASKIN] D. Haskin et al., "A Method for Setting Alternative Label
Switched Paths to Handle Fast Reroute," work in progress <draft-
haskin-mpls-fast-reroute-05.txt>, November 2000
[KINI] S. Kini et al., "Shared Backup Label Switched Path
Restoration," work in progress <draft-kini-restoration-shared-
backup-01.txt>, 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 <draft-ietf-mpls-rsvp-lsp-tunnel-08.txt>, 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 <draft-ietf-mpls-cr-ldp-05.txt>, February 2001.
[ASH] G. Ash, et al., "LSP Modification Using CR-LDP", work in
progress <draft-ietf-mpls-crlsp-modify-03.txt>, 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]
