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]