Network Working Group S. De Cnodder Internet Draft R. Cetin Expiration Date: July 2002 S. van den Bosch Alcatel A. Atlas Avici Systems May 2002 Backup Record Route for Fast Reroute Techniques in RSVP-TE draft-decnodder-mpls-ero-rro-fastreroute-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts 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). The latter can also be used for bypass tunnels. 2. Conventions used in this document De Cnodder, et al. Expires July 2002 [Page 1] Internet Draft draft-decnodder-mpls-ero-rro-fastreroute May 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. 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 cost of the fast restoration time 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 have to 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. 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. To allow a faster merging with other detour LSPs, PLRs should be aware of the paths of the other detour LSPs. For instance, when a PLR knows the path of the detour LSPs established by the downstream PLR, then this PLR can calculate a path for its detour LSP, which can merge faster with one of the detour LSPs established by a downstream PLR. Another advantage is that PLRs also can use links which would otherwise have been unavailable. For instance, if a detour LSP reserves bandwdith it is possible that the upstream PLR gets the updated unreserved bandwidth via the TE extenstions 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 De Cnodder, et al. Expires July 2002 [Page 2] Internet Draft draft-decnodder-mpls-ero-rro-fastreroute May 2002 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 centralized server like for instance the ingress node of the LSP or a Path Computation Server [5]. This can result in the most optimal paths than the first approach, which relies on a 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 intance 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]. 4. 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 De Cnodder, et al. Expires July 2002 [Page 3] Internet Draft draft-decnodder-mpls-ero-rro-fastreroute May 2002 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). +------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 De Cnodder, et al. Expires July 2002 [Page 4] Internet Draft draft-decnodder-mpls-ero-rro-fastreroute May 2002 flag". When the flag is set by a certain PLR, then that PLR is supporting the BRRO, and when the flag is not set, then the PLR is not supporting the BRRO. 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 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. 5. 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 the Resv message containing the path of its detour LSP. Because a BRRO can be long, and there can be many BRROs in the Resv message, it is possible that the MTU is exceeded. To limit the size of the Resv message, a PLR may remove other BRROs in the Resv message. It is preferred that when a PLR removes BRROs, that it removes the BRROs belonging to PLRs as close to the destination as possible. When inserting a BRRO, a PLR SHOULD insert the BRRO in front of the other BRROs already present in the Resv message. When removing BRROs, it SHOULD start from the last BRRO, i.e. it should start with the least recent BRROs. A PLR may maintain a threshold indicating the maximum number of BRROs it will forward in the Resv message. If this threshold is set to 1, then the PLR will only forward its own BRRO and will remove all other BRROs. 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. 6. Using a Backup Explicit Route Object in the Path message The most optimal path calculations for detour LSPs can only be achieved when a centralized server does the calculations. This centralized server can be the ingress LSR, a path computation server, De Cnodder, et al. Expires July 2002 [Page 5] Internet Draft draft-decnodder-mpls-ero-rro-fastreroute May 2002 or an off-line traffic-engineering server. Altough such a centralized approach can compute the most 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 do path calculations. This is needed in case of failures and thus the result of the centralized server is not anymore valid. The centralized server calculates all paths such that the merging is optimal and the result is put in the Backup Explicit Route Object (BERO). 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). The use of the path specified in the BERO is optional. The PLR may overrule the path specified by the ingress. This is because there may be PLRs in the network not supporting the BERO or when the path specified by the BERO fails, the PLR may calculate another path. The BERO can also be used to specify which bypass tunnel should be used in case there are multiple bypass tunnels. 7. 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 dowsntream, 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. De Cnodder, et al. Expires July 2002 [Page 6] Internet Draft draft-decnodder-mpls-ero-rro-fastreroute May 2002 The BRRO Class is TBD. Currently one C_Type is defined. The BRRO 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 Record Route object are a series of variable-length data items called subobjects. The subobjects are defined in section 7.1 below. The BRRO can be present in both Path and Resv messages, although it is recommended only to use it in Resv messages. 7.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. 7.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 De Cnodder, et al. Expires July 2002 [Page 7] Internet Draft draft-decnodder-mpls-ero-rro-fastreroute May 2002 0x01 IPv4 address of the PLR. Length 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. 7.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 De Cnodder, et al. Expires July 2002 [Page 8] Internet Draft draft-decnodder-mpls-ero-rro-fastreroute May 2002 0x02 IPv6 address of the PLR. Length 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. 7.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. 7.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. 7.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 July 2002 [Page 9] Internet Draft draft-decnodder-mpls-ero-rro-fastreroute May 2002 0x10 BRRO capable When this flag is set, the node is supporting the BRRO, otherwise the node is not supporting the BRRO. 8. 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 4.2. below. An example is given in Appendix A. 8.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. 8.1.1. Subobject 1: IPv4 prefix De Cnodder, et al. Expires July 2002 [Page 10] Internet Draft draft-decnodder-mpls-ero-rro-fastreroute May 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 | IPv4 address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address (continued) | Prefix Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Backup ERO Field) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x01 IPv4 address Length The Length contains the total length of the subobject in bytes, including the Type, Length, and Backup ERO Field. IPv4 address An IPv4 address. This address is treated as a prefix based on the prefix length value below. Bits beyond the prefix are ignored on receipt and SHOULD be set to zero on transmission. Prefix length Length in bits of the IPv4 prefix Flags No flags are currently defined. Backup ERO Field Explicit Route object as defined in [4] for the backup LSP. The contents of the IPv4 subobject and prefix length must correspond with a subobject in the ERO. 8.1.2. Subobject 2: IPv6 Prefix De Cnodder, et al. Expires July 2002 [Page 11] Internet Draft draft-decnodder-mpls-ero-rro-fastreroute May 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 | IPv6 address (16 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 address (continued) | Prefix Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Backup ERO Field) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x02 IPv6 address Length The Length contains the total length of the subobject in bytes, including the Type, Length, and Backup ERO Field. IPv6 address An IPv6 address. This address is treated as a prefix based on the prefix length value below. Bits beyond the prefix are ignored on receipt and SHOULD be set to zero on transmission. Prefix Length Length in bits of the IPv6 prefix. Flags No flags are currently defined. Backup ERO Field Explicit Route object as defined in [4] for the backup LSP. The contents of the IPv6 subobject and prefix length must correspond with a subobject in the ERO. De Cnodder, et al. Expires July 2002 [Page 12] Internet Draft draft-decnodder-mpls-ero-rro-fastreroute May 2002 TBD: subobjects for bypass tunnels. 8.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: 1) The node checks if there is a subobject in the BERO corresponding with the first subobject in the ERO. Then there are 3 possibilities: * At least one matching subobject in the BERO is found and the BERO subobject field is not empty: the ERO for the backup LSP SHOULD be set identically to the content of the Backup ERO Field belonging to the matching BERO subobject. If there are multiple matching BERO subobjects, the first subobject appearing in the BERO is selected. * At least one matching subobject in the BERO is found but they all have an empty Backup ERO Field: then the node SHOULD establish a backup LSP with a path determined by some other means (e.g., by means of a local CSPF calculation). * No such 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. 2) The selected matching BERO subobject MUST be removed together with all subobjects that appear before the selected matching subobject. 8.3. Forward Compatibility New subobjects may be defined and when processing the BERO, unrecognized subobjects SHOULD be ignored and passed on. 8.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. 9. Security Considerations There are no new security issues compared to [3] and [4]. 10. References De Cnodder, et al. Expires July 2002 [Page 13] Internet Draft draft-decnodder-mpls-ero-rro-fastreroute May 2002 [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. 11. 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 Riza Cetin Alcatel Francis Wellesplein 1 B-2018 Antwerp, Belgium email: riza.cetin@alcatel.be De Cnodder, et al. Expires July 2002 [Page 14] Internet Draft draft-decnodder-mpls-ero-rro-fastreroute May 2002 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 July 2002 [Page 15]