Network Working Group S. De Cnodder
Internet Draft R. Cetin
Expiration Date: May 2003 S. van den Bosch
Alcatel
A. Atlas
Avici Systems
November 2002
Backup Record Route for Fast Reroute Techniques in RSVP-TE
draft-decnodder-mpls-ero-rro-fastreroute-02.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.
Abstract
MPLS fast reroute [3] is considered as a possible solution to protect
traffic against link and node failures by re-directing the traffic
locally to a backup LSP. A backup LSP can be either a detour LSP or a
bypass tunnel. This document describes two methods to optimize the
routing of detour LSPs such that they merge faster, a distributed
method and a centralized method. The distributed method uses the
Backup Record Route Object (BRRO) and the centralized method uses the
Backup Explicit Route Object (BERO).
2. Conventions used in this document
De Cnodder, et al. Expires May 2003 [Page 1]
Internet Draft draft-decnodder-mpls-ero-rro-fastreroute November 2002
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [2].
3. Summary for Sub-IP Area
3.1. Summary
This document describes procedures and protocol extensions to
improving the path calculation done at PLRs to provide MPLS fast
reroute.
3.2. Related documents
draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt [3] and RFC 3209 [4].
3.3. Where does it fit in the Picture of the Sub-IP Work
This document extends RSVP-TE which is part of the Sub-IP area.
3.4. Why is it Targeted at this WG
This document extends the MPLS signaling and the MPLS fast reroute
procedures. The latter is part of the MPLS WG.
3.5. Justification
There are multiple Justifications. First of all, scalability is a
known problem of MPLS and therefore methods are needed to reduce the
number of LSPs as much as possible. Secondly, MPLS is used for
traffic engineering purposes, which means that bandwidth is a scarce
resource so it is needed to optimize the bandwidth reservations in
the network.
4. Introduction
MPLS fast reroute [3] is considered as a possible solution to protect
traffic against link and node failures. An attractive property of
MPLS fast reroute is that it is able to re-direct the traffic to an
alternative backup LSP very fast, typically in the order of 10s of
milliseconds. To achieve this fast restoration time, a backup or
detour LSP can be established at each node. The traffic can be
switched immediately to this LSP once a failure has been detected
downstream of the backup LSP.
The issue in achieving fast restoration time with MPLS fast reroute
is that a lot of LSPs have to be established. When detour LSPs are
used and N nodes are traversed by the main LSP, N-1 detour LSPs must
De Cnodder, et al. Expires May 2003 [Page 2]
Internet Draft draft-decnodder-mpls-ero-rro-fastreroute November 2002
be established to fully protect the main LSP. To improve the
scalability, detour LSPs may be merged with each other or they may be
merged with the protected LSP when possible. Another solution is to
use a single label stacked bypass tunnel that can be used to protect
multiple LSPs.
In case of detour LSPs, if merging is effective (i.e. fast merging
with protected LSP or with other detour LSPs), then there is not much
signaling and refresh overhead, and also the total amount of
bandwidth reserved in the network is limited. In case the protection
bandwidth is zero, the latter is not an issue and the considerations
developed in this memo are limited to signaling and refresh overhead
only.
To allow a PLR to select the closest (or most optimal) merging node
with detour LSPs originated by other PLRs, the PLR should be aware of
the paths of the detour LSPs established by the other PLRs. For
instance, when a PLR knows the path of the detour LSP established by
the downstream PLR, then the PLR can calculate a path for its detour
LSP, which can merge with the detour LSP established by the
downstream PLR at a node as close as possible to the PLR.
If merging is not effective and the maximum hop count is M, then the
total amount of reserved bandwidth is in the order of O(M*M*B) where
B is the bandwidth signaled for detour LSPs. This means that the
amount of signaling overhead and bandwidth reservations is quadratic
with the hop count. If the merging is effective, then the total
amount of reserved bandwidth is in the order of O(M*B), i.e.
signaling overhead and bandwidth reservations are linear with the hop
count.
Another advantage is that PLRs also can use links which would
otherwise have been unavailable. For instance, if a detour LSP
reserves bandwidth it is possible that the upstream PLR gets the
updated unreserved bandwidth via the TE extensions of the IGP before
the upstream PLR calculates its detour LSP. Then, it could be
possible that the links taken by the detour LSP of the downstream PLR
do not have enough bandwidth anymore. If the upstream PLR knows the
path of the detour LSP of the downstream node, the upstream PLR does
not have to take into account the bandwidth of these links anymore.
To make the path of the backup LSPs visible to the other PLRs, a new
object called Backup Record Route Object (BRRO) is defined in this
document.
An alternative is a centralized approach where the path calculations
of all detour LSPs are performed by a single entity like for instance
the ingress node of the LSP or a Path Computation Server [5]. This
De Cnodder, et al. Expires May 2003 [Page 3]
Internet Draft draft-decnodder-mpls-ero-rro-fastreroute November 2002
may result in a more optimal solution than the first approach, which
relies on a purely distributed path calculation, but at the cost of a
higher computation complexity.
The centralized approach uses the Backup Explicit Route Object (BERO)
and can also be used for bypass tunnels. The BERO gives a recommended
path or bypass tunnel to each PLR. The PLR can use this information
to calculate for instance a path for the detour LSP. If the PLR
cannot find such a path, it may compute another path. This is likely
to be the case when there is a failure on the path specified by the
centralized server.
The idea of the usefulness of fast merging of protection LSPs of any
nature (end-to-end backup LSPs and detour LSPs) is also described in
[6].
5. Path optimization with Backup Record Route Object
When a PLR has established a detour LSP, it may insert a BRRO in the
Resv message. The BRRO contains the path of the detour LSP. When the
upstream PLR receives this Resv message, it can calculate a path for
its detour LSP taking into account the paths given by all the BRROs
present in the Resv message. Note that a BRRO only contains the path
of a single detour LSP and that there can be multiple BRROs in the
Resv message, one for each downstream PLR.
By putting the BRROs in the Resv message, detours are established
starting from the penultimate node and then one by one towards the
ingress node. Note that a BRRO normally does not appear in the first
Resv message to establish the LSP, but that it appears later on in
one of the refreshes. This is because when the first Resv message to
establish the main LSP is sent, the path of the detour is not yet
known and thus no BRRO can be included in this Resv message.
An alternative could be to insert the BRROs into the Path message,
but this is probably less efficient because detour LSPs established
by upstream PLRs could merge with the protected LSP before the PLR
that is calculating a path for its detour LSP. In this case the path
of the upstream detour LSP must be avoided. Therefore, the BRROs
should only be put in the Resv message.
Figure 1 shows a network where a protected LSP is established (A-B-
C-D) and because no optimization with BRRO is used, detours could be
established as follows: PLR C uses C-G-H-D, PLR B uses B-I-J-D, and
PLR A uses A-K-L-M-D. While with the optimization this results in
that PLR B now uses B-F-G-H and PLR A now uses A-F-G-H-D (see figure
2).
De Cnodder, et al. Expires May 2003 [Page 4]
Internet Draft draft-decnodder-mpls-ero-rro-fastreroute November 2002
+------F------G******H
| | * *
| | * * ==== protected LSP
A======B======C======D***+ **** detour LSP
* * | * * ---- unused link
* * | * *
* +******I******J *
* *
* *
+******K******L******M***+
Figure 1: an example network without BRRO
+******F******G******H
* * * *
* * * *
A======B======C======D---+
| | | | |
| | | | |
| +------I------J |
| |
| |
+------K------L------M---+
Figure 2: an example network with BRRO
By putting the BRROs in the Resv message, the upstream PLRs have to
wait until they receive a Resv message containing a BRRO and this is
not necessarily the first Resv message. This could occur in
situations where the detour LSP is established after that the Resv
message is sent upstream in order not to delay the establishment of
the protected LSP. Therefore the PLRs have to wait until they have
received a BRRO from a downstream node. However, when the downstream
nodes do not support the BRRO, an upstream PLR will never receive a
BRRO and thus the PLR will wait forever (or for a timeout). To avoid
this, an extra flag is defined in the RRO, which is an object present
in the first Resv message. This flag is called the "BRRO capable
flag". When the flag is set by a certain PLR, then that PLR MUST
include the BRRO in one of the next Resv messages, and when the flag
is not set, then the PLR will not put the BRRO in a Resv message. In
the former case, a PLR may wait until it has received at least one
BRRO from a node that has set this flag, preferentially from the
first node downstream that had set the flag. An alternative is that
the PLR immediately establishes a detour LSP and re-optimized the
detour LSP when it receives a BRRO.
If none of the nodes has set this flag, the PLR does not have to wait
to establish the detour LSP. This means that when a PLR has set the
De Cnodder, et al. Expires May 2003 [Page 5]
Internet Draft draft-decnodder-mpls-ero-rro-fastreroute November 2002
flag, but was not able to set up a detour LSP, it has to include an
empty BRRO in order not to delay the establishment of the detour LSPs
at the upstream PLRs in case they would wait for a BRRO.
Nodes setting the BRRO capable flag MUST send a BRRO upstream, while
nodes not setting the BRRO capable flag MAY send a BRRO.
6. Inserting a Backup Record Route Object in the Resv message
When a PLR has established a detour LSP, and it has set the BRRO
capable flag in the RRO, the PLR MUST include a BRRO in a Resv
message containing the path of its detour LSP if it was able to
establish a detour LSP.
In addition to the path of the own detour LSP, a PLR MAY also include
BRROs containing the path of the detour LSPs established by the
downstream PLRs. It is preferred that when a PLR includes paths of
detour LSPs of downstream PLRs, then the paths of the detour LSPs of
the closest downstream PLRs should be selected. The paths of the
detour LSPs of the downstream PLRs are learned by the BRROs received
in the Resv message.
If the PLR was not able to establish a detour LSP, and it has not
received another BRRO in the Resv message, then it MUST put an empty
BRRO in the next Resv message. If the PLR was not able to establish a
detour LSP, but it has received at least one BRRO from the downstream
PLR, then the PLR MUST forward at least 1 BRRO in the Resv message,
preferentially the BRRO generated by the most upstream PLR.
When the path of the originating detour LSP in the BRRO makes the
Resv message too long (e.g., it becomes longer than the MTU), then an
empty BRRO SHOULD be put in the Resv message.
The BRRO containing the path of the own detour LSP SHOULD be in front
of the BRROs containing other detour LSPs.
A PLR may maintain a threshold indicating the maximum number of BRROs
it will put in the Resv message. If this threshold is set to 1, then
the PLR will only put the path of its own detour LSP in a BRRO. This
means that when all nodes support the BRRO, a PLR can calculate a
detour LSP taking into account the path of the detour LSP established
by the downstream node. This can already give a good performance
improvement.
When a PLR sees that the BRRO has changed, then the PLR may re-
optimize its detour LSP. This can happen for instance when a detour
of a downstream PLR has failed and a new detour has been calculated.
To ensure stability, a PLR should not re-optimize the detour path
De Cnodder, et al. Expires May 2003 [Page 6]
Internet Draft draft-decnodder-mpls-ero-rro-fastreroute November 2002
more than once every time period (e.g., 30 seconds). This can lead to
a less optimal routing for a time period but it will slowly converge
to a more optimal routing, depending on the timeperiod. It can be
expected that detour LSPs that are periodically re-optimized are not
too often rerouted. If a PLR sees that the BRRO is changing very
often (more than once in a few re-optimization timeperiods), then it
would be better to ignore the BRRO at that PLR. Note that the
upstream PLRs still see a stable BRRO in this case such that for
them, BRRO is still useful.
7. Using a Backup Explicit Route Object in the Path message
The most optimal path calculations for detour LSPs can only be
achieved when a single entity performs all path calculations. This
single entity can be the ingress LSR, a path computation server, or
an off-line traffic-engineering server. Although such a centralized
approach can compute more optimal paths, this goes at the cost of an
increased computational load at the place where the calculations are
done. Note that this approach still requires that PLRs can perform
path calculations. This is needed in case the TE database of the
single entity is out-of-date, the amount of available resources
change during the signaling of the LSP because for instance other
LSPs are established at the same time, or in case of link or node
failures on the path of the detour LSP. In all these cases, the
content of the BERO may result in the fact that the detour LSP cannot
be established based on the BERO content, and the PLR has to
calculate a path for the detour LSP without using the information of
the BERO.
The single entity calculates all paths such that the merging is
optimal and the result (or the most relevant part of it) is put in
the Backup Explicit Route Object (BERO) by the ingress LSR.
The BERO contains the path of the detour LSP. Each PLR checks if it
can find itself in the BERO. If this is the case, then the ingress
router wants the PLR to use a certain path for the local backup LSP,
and this path is also contained in the BERO and linked to the address
of the PLR.
The path in the BERO can also contain loose hops which has to be
resolved by the PLRs. This could be used to keep the length of the
BERO short. In this case, the BERO could only specify the merging
nodes as loose hops (and the next node as a strict hop to guarantee
merging).
To further decrease the length of the BERO, the part of the path that
is common between detour LSPs originated by different PLRs SHOULD be
given once such that there is no duplication of information.
De Cnodder, et al. Expires May 2003 [Page 7]
Internet Draft draft-decnodder-mpls-ero-rro-fastreroute November 2002
Take as an example a node that can merge 3 detour LSPs. In this case,
the BERO should contain only 1 path which is applicable for 3 PLRs:
the merging node as a loose node, and the remainder of the path
towards the egress as a strict path.
Not all detour LSPs have to be specified in the BERO. For instance,
detour LSPs that cannot be optimized should not have a path in the
BERO. Also, the number of detour LSPs in the BERO has to be limited
such that the length of the object is below a certain maximum value
and to limit the parsing time of the BERO.
The use of the path specified in the BERO is optional. The PLR MAY
overrule the path specified by the ingress. This is because some PLRs
on the path of the protected LSP do not support the BERO processing
or when the path specified by the BERO is not valid, the PLR SHOULD
calculate another path.
The BERO can also be used to specify which bypass tunnel should be
used in case there are multiple bypass tunnels.
8. Backup Record Route Object
The paths of the backup LSPs can be recorded via the Backup Record
Route objects (BRRO). Because it is only useful for the nodes along
the protected LSP to see the paths of the detour LSPs established
downstream, the BRRO SHOULD only be put in Resv messages of the main
LSP.
Only the originating node of a backup LSP (i.e., the PLR) knows
whether or not the detour LSP is available. Therefore, the PLR has to
put the RRO of the detour LSP into the BRRO of the Resv message of
the main LSP. The PLR knows that the backup LSP is available because
for instance it received a Resv message for the detour LSP.
This document defines a backup record route ojects with 2 types of
subobjects: a subobject in case the PLR inserts an IPv4 address in
the RRO and a subobject in case it is an IPv6 address.
The BRRO Class is TBD. Currently one C_Type is defined. The BRRO has
the following format:
Class = 11bbbbbb (TBD), C_Type = 1
De Cnodder, et al. Expires May 2003 [Page 8]
Internet Draft draft-decnodder-mpls-ero-rro-fastreroute November 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subobjects
The contents of a Backup Record Route object are a series of
variable-length data items called subobjects. The subobjects are
defined in section 8.1 below.
The BRRO can be present in both Path and Resv messages, although it
is recommended only to use it in Resv messages.
8.1. Subobjects for BRRO
Two subobjects are currently defined: a subobject in case the PLR has
an IPv4 address and a subobject in case it is an IPv6 address.
Each subobject contains besides of the address of the PLR also the
path of the backup LSP it originates. This path could be the RRO of
the backup LSP.
There SHOULD only be 1 subobject in the BRRO.
8.1.1. Subobject 1: PLR with IPv4 address
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Backup RRO Field) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
0x01 IPv4 address of the PLR.
Length
De Cnodder, et al. Expires May 2003 [Page 9]
Internet Draft draft-decnodder-mpls-ero-rro-fastreroute November 2002
The Length contains the total length of the subobject in bytes,
including the Type, Length, and Backup RRO Field.
IPv4 address
A 32-bit unicast, host address of the PLR.
Prefix length
32
Flags
The same flags as in [4].
Backup RRO Field
This field is a variable length field and contains the RRO
received from the detour LSP established by the PLR mentioned
in the IPv4 address field. If the backup RRO field is not
present, then this means that the PLR was not able to establish
a detour LSP.
8.1.2. Subobject 2: PLR with IPv6 address
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Backup RRO Field) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
0x02 IPv6 address of the PLR.
Length
De Cnodder, et al. Expires May 2003 [Page 10]
Internet Draft draft-decnodder-mpls-ero-rro-fastreroute November 2002
The Length contains the total length of the subobject in bytes,
including the Type, Length, and Backup RRO Field.
IPv4 address
A 128-bit unicast, host address of the PLR.
Prefix length
128
Flags
The same flags as in [4].
Backup RRO Field
This field is a variable length field and contains the RRO
received from the detour LSP established by the PLR mentioned
in the IPv6 address field. If the backup RRO field is not
present, then this means that the PLR was not able to establish
a detour LSP.
8.2. Forward Compatibility
Forward compatibility is similar as the RRO defined in [4]. New
subobjects may be defined and when processing the BRRO, unrecognized
subobjects SHOULD be ignored and passed on.
8.3. Non-support of BRRO
The BRRO is assigned a class value of the form 11bbbbbb, which means
that routers not recognizing this object will ignore the object and
forward it unexamined and unmodified.
8.4. The BRRO capable flag in the RRO
Currently the following flags are defined for the RRO:
0x01 Local protection available [4]
0x02 Local protection in use [4]
0x04 Bandwidth protection [3]
0x08 Node Protection [3]
The following new flag is defined:
De Cnodder, et al. Expires May 2003 [Page 11]
Internet Draft draft-decnodder-mpls-ero-rro-fastreroute November 2002
0x10 BRRO capable
When this flag is set, the node MUST send at least 1 BRRO to the
upstream PLR.
9. Backup Explicit Route Object
The paths of the backup LSPs can be specified with the Backup
Explicit Route Object (BERO), which is an optional object in the Path
message.
The Backup Explicit Route Class is TBD. Currently one C_Type is
defined, Type 1. The Backup Explicit Route object has the following
format:
Class = 11bbbbbb (TBD), C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subobjects
The contents of a Backup Explicit Route object are a series of
variable-length data items called subobjects. The subobjects are
defined in section 9.1. below. .in 3
9.1. Subobjects
The contents of a Backup Explicit Route object are a series of
variable-length data items called subobjects. Two subobjects are
currently defined: a subobject in case the node originating a
backup LSP has an IPv4 address and a subobject in case it is an
IPv6 address.
9.1.1. Subobject 1: IPv4 prefix
De Cnodder, et al. Expires May 2003 [Page 12]
Internet Draft draft-decnodder-mpls-ero-rro-fastreroute November 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Length PLR | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address PLR 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address PLR n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Backup ERO Field) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
0x01 IPv4 address
Length
The Length contains the total length of the subobject in bytes,
including the Type, Length, Length PLR, Reserved field, PLR
addresses and Backup ERO Field.
Length PLR
The Length contains the total length of all PLR address fields
in bytes. Dividing this number by 4 gives the number of PLR
addresses.
Reserved
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt.
IPv4 address PLR
An IPv4 address of a particular PLR
Backup ERO Field
Explicit Route object as defined in [4] for the backup LSP.
The input ERO of a particular PLR is defined as the concatenation of
De Cnodder, et al. Expires May 2003 [Page 13]
Internet Draft draft-decnodder-mpls-ero-rro-fastreroute November 2002
the backup ERO fields found in all subobjects where this PLR has an
IPv4 address in one of the IPv4 address PLR fields.
9.1.2. Subobject 2: IPv6 Prefix
TBD
9.2. Processing of the Backup Explicit Route Object
Before a node receiving a Path message processes the BERO, the node
first has to perform the first step of the ERO processing as
described in [4], i.e. it first has to check if the node is part of
the abstract node described by the first subobject in the ERO. If
this is the case, then the processing of the BERO can start as
follows:
The node checks if there is a subobject in the BERO containing a PLR
address corresponding with the first subobject in the ERO (bits
masked by the prefix length in the ERO are not taken into account).
Then there are 2 possibilities:
* At least one matching subobject in the BERO is found and the BERO
subobject field is not empty: the input ERO obtained by concatenating
all backup ERO fields of the matching subobjects SHOULD be used to
calculate the path of the detour LSP originated by that PLR. If the
input ERO is empty, i.e. the PLR was found in the one of the PLR
address fields, the PLR MUST compute a detour path as if no BERO was
present.
* No matching subobject is found: the processing of the BERO stops
and the processing of the Path message continues. In this case, no
backup LSP MAY be used at that node.
A PLR MAY update the BERO when it is sent to the next PLR. For
instance a PLR may remove a subobject in the BERO if it only contains
addresses in the IP address PLR field belonging to itself or to PLRs
upstream of itself (PLR addresses available in RRO).
9.3. Forward Compatibility
New subobjects may be defined and when processing the BERO,
unrecognized subobjects SHOULD be ignored and passed on.
9.4. Non-support of the Backup Explicit Route Object
The BERO is assigned a class value of the form 11bbbbbb, which means
that routers not recognizing this object will ignore the object and
forward it unexamined and unmodified.
De Cnodder, et al. Expires May 2003 [Page 14]
Internet Draft draft-decnodder-mpls-ero-rro-fastreroute November 2002
10. Security Considerations
There are no new security issues compared to [3] and [4].
11. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Require-
ment Levels", BCP 14, RFC 2119, March 1997.
[3] Pan, P., Gan, D., Swallow, G., Vasseur, J.P., Copper, D.,
Atlas, A., Jork, M., "Fast Reroute Technique in RSVP-TE",
Internet draft, draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt,
work in progress.
[4] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels",
RFC 3209.
[5] Vasseur, JP., Iturralde, C., Zhang, R., Vinet, X.,
Matsushima, S., Atlas, A., "RSVP Path computation request and
reply messages", draft-vasseur-mpls-computation-rsvp-03.txt,
work in progress.
[6] Iwata, A., Fujita, N., Nishida, T., "MPLS Signaling Exten-
sions for Shared Fast Rerouting", Internet draft, draft-
iwata-mpls-shared-fastreroute-00.txt, work in progress.
12. Acknowledgments
We would like to thank Claus Bauer, Der-Hwa Gan, Dimitri
Papadimitriou and Cristel Pelsser for their helpful comments.
Authors Addresses
Stefaan De Cnodder
Alcatel
Francis Wellesplein 1
B-2018 Antwerp, Belgium
email: stefaan.de_cnodder@alcatel.be
De Cnodder, et al. Expires May 2003 [Page 15]
Internet Draft draft-decnodder-mpls-ero-rro-fastreroute November 2002
Riza Cetin
Alcatel
Francis Wellesplein 1
B-2018 Antwerp, Belgium
email: riza.cetin@alcatel.be
Sven Van den Bosch
Alcatel
Francis Wellesplein 1
B-2018 Antwerp, Belgium
email: sven.van_den_bosch@alcatel.be
Alia Atlas
Avici Systems
101 Billerica Avenue
N. Billerica, MA 01862
email: aatlas@avici.com
De Cnodder, et al. Expires May 2003 [Page 16]