Network Working Group S. De Cnodder Internet Draft R. Cetin Expiration Date: August 2002 S. Van den Bosch Alcatel D. Gan Juniper Networks, Inc. February 2002 Backup Record Route for Fast Reroute Techniques in RSVP-TE draft-decnodder-mpls-ero-rro-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 [1]. 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. 1. 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. This document describes a method to specify the path of each local backup LSP by the ingress router and a method to make the path of each local backup LSP visible to the ingress router of the main LSP. 2. Conventions used in this document 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]. De Cnodder, et. al. [Page 1] draft-decnodder-mpls-ero-rro-fastreroute-00.txt February 2002 This document uses the term "backup LSP" to indicate a local backup LSP established by any method described in [3]. So a backup LSP could be either a one-to-one detour LSP or a bypass tunnel. 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. Normally if N nodes are traversed by the main LSP, N-1 backup LSPs have to be established to fully protect the main LSP. To improve the scalability, backup LSPs may be merged with each other or they may be merged with the main LSP when possible. Another solution is to use a single label stacked bypass tunnel that can be used by multiple LSPs (see Section 4 in [3]. Backup LSPs can also increase the total amount of reserved bandwidth in the network when they are set up with reserved resources. The ingress router of the LSP has less knowledge of the routing of packets in case of a failure in the network. The ingress router only knows whether or not a backup LSP is established, but it does not know the explicit route of the backup LSP. In addition, the ingress router has no control on the routing of the packets when a failure occurs because the routing decision is taken locally. Having control on the routing of the backup LSPs by the ingress is useful because a more optimal explicit route can be calculated. This is due to the fact that the ingress router can incorporate the routing of other backup LSPs while it is calculating a path for a backup LSP. In this way, the merging of backup LSPs will be more effective. If merging is effective, 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 main and backup LSPs. If the merging is effective (i.e. fast merging with main LSP or with other detours), then the total amount of reserved bandwidth is in the order of O(M*B). Knowing the route of the backup LSPs is also useful because then the ingress router sees how long the backup LSPs are and how effective the merging of backup LSPs is. If the ingress router sees that the total amount of bandwidth becomes excessive, then the ingress node could take the following actions: (1) reduce the bandwidth for the backup LSPs, (2) reroute some LSPs such that merging becomes more effective, (3) disable fast reroute for this LSP by removing the De Cnodder, et. al. [Page 2] draft-decnodder-mpls-ero-rro-fastreroute-00.txt February 2002 FAST_REROUTE object or by resetting the "Local protection desired" flag, or (3) establish a new LSP via an alternative path hoping that via this path the backup LSPs are routed more efficiently. In addition the ingress router can check whether or not the routers initiating the local backup LSPs were capable of using the path given by the ingress router. Centralized traffic engineering tools can also benefit a lot if ingress routers are capable of specifying all paths and checking the actual path. When all control on the routing of LSPs is taken centralized then the result can be given to the ingress router, which gives the routing information of main and backup LSPs to all routers in the path. After the establishment of the LSP, the ingress router then can give the centralized traffic engineering tool feedback about to what extend the given paths were followed. To allow the ingress router to specify the paths for the local backup LSPs, a new object, the Backup Explicit Route object (BERO), is defined. To make the path of the backup LSPs known to the ingress router, a new object called Backup Record Route object (BRRO) is defined. In addition, an optional flag in the RRO is defined to locate the merging nodes and a new flag in the Session attribute object is defined to request for recording the path of the backup LSPs in the BRRO. 4. 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. 4.1. Semantics of the Backup Explicit Route Object De Cnodder, et. al. [Page 3] draft-decnodder-mpls-ero-rro-fastreroute-00.txt February 2002 The BERO contains the path of the backup 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 use of the path specified in the BERO is optional. The PLR may overrule the path specified by the ingress. This is because some methods for local protection mechanism, it is not desirable to allow a flexible routing of all backup LSPs. An example of such a method is the bypass tunnel specified in [3] where several LSPs share the same bypass tunnel. Whether or not the PLR has chosen for the path given by the ingress, can be checked with the Backup Record Route Object specified in Section 5. 4.2. 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. 4.2.1. Subobject 1: IPv4 prefix 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 De Cnodder, et. al. [Page 4] draft-decnodder-mpls-ero-rro-fastreroute-00.txt February 2002 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. 4.2.2. Subobject 2: IPv6 Prefix 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 De Cnodder, et. al. [Page 5] draft-decnodder-mpls-ero-rro-fastreroute-00.txt February 2002 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. 4.3. Processing of the Backup Explicit Route Object Before a node receiving a Path message processes the BERO, the node first has to performs 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. 4.4. Forward Compatibility De Cnodder, et. al. [Page 6] draft-decnodder-mpls-ero-rro-fastreroute-00.txt February 2002 New subobjects may be defined and when processing the BERO, unrecognized subobjects SHOULD be ignored and passed on. 4.5. 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. 5. 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 ingress router to see the paths of the backup LSPs, 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 backup LSP is available. Therefore, the PLR has to put the RRO of the backup 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. Note that the BRRO does not need to be sent to the backup LSP but that the RRO is sufficient. 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 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 4.1 below. The BRRO can be present in both Path and Resv messages, although it is recommended only to use it in Resv messages. If a message contains multiple BRROs, only the first BRRO is meaningful. Subsequent BRROs SHOULD be ignored and SHOULD NOT be propagated. Similarly, if in a Resv message multiple BRROs are encountered De Cnodder, et. al. [Page 7] draft-decnodder-mpls-ero-rro-fastreroute-00.txt February 2002 following a FILTER_SPEC before another FILTER_SPEC is encountered, only the first BRRO is meaningful. Subsequent BRROs SHOULD be ignored and SHOULD NOT be propagated. 5.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 IPv4 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. Subobjects are organized as a last-in-first-out stack. The first subobject relative to the beginning of BRRO is considered the top. The last subobject is considered the bottom. When a new subobject is added, it is always added to the top. An empty RRO with no subobjects is considered illegal. 5.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 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 De Cnodder, et. al. [Page 8] draft-decnodder-mpls-ero-rro-fastreroute-00.txt February 2002 32 Flags The same flags as in [4]. Backup RRO Field This field is a variable length field and contains a part of the RRO or BRRO received from the local backup LSP. 5.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 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 De Cnodder, et. al. [Page 9] draft-decnodder-mpls-ero-rro-fastreroute-00.txt February 2002 The same flags as in [4]. Backup RRO Field This field is a variable length field and contains a part of the RRO or BRRO received from the local backup LSP. 5.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. 5.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. By comparing the RRO and the BRRO, the ingress router is capable of identifying the nodes that do not support the BRRO, and thus the ingress router does not know the path of the backup LSP originated by that router. 5.4. RRO/BRRO in case of detour LSPs are merged In some cases backup LSP may merge with other backup LSPs of the same main LSP. This is specifically the case with detour LSPs. Also, it is very likely that backup LSPs merge with the main LSP. On the other hand, it is also possible that backup LSPs follow for a part the same path without being merged. It is necessary that the ingress router knows whether or not merging has occurred because in case of merging, the network operates more efficiently, e.g., less bandwidth is reserved and there is less signaling and refresh overhead. Therefore, it is also recommended that a node merging two or more LSPs also indicates in the RRO by means of a flag that the LSPs are merged with another LSP. The part of the RRO behind the node that set this flag is in fact the RRO of the LSP where it merged with at the merging point. This means that all LSPs merging with each other at a certain node will have this flag set, with the exception of the LSP that was selected to be the final LSP. The merging node can give this information via the flags in the RRO subobjects. In [4] two flags are defined: "Local protection available" and "Local protection in use". For the RRO of backup LSPs, a third flag is defined to mark the merging node: 0x04 Merging occurred When merging occurred, this flag is set. De Cnodder, et. al. [Page 10] draft-decnodder-mpls-ero-rro-fastreroute-00.txt February 2002 When this flag is set, the originating node of the backup LSP (i.e. the PLR) is sure that merging occurred and that the path of the backup LSP after this merging point is in fact a path segment of another backup LSP. Therefore, merging nodes SHOULD set this flag and the PLR SHOULD NOT include the path segment after the merging node in the RRO of the main LSP. This means that the path segment after the merging node should not appear in the Backup RRO subobject of the BRRO. Optionally, the PLR MAY insert the path segment after the merging node because this information is still useful for the ingress router because then it can also see the path of the LSP with with it has merged. When the Merging occurred flag is not set, then there are 3 possibilities: 1. The LSP is not merged with other LSPs 2. The LSP is merged with other LSPs, but this LSP was selected to be the final LSP and the others merge with this LSP. 3. The node does not support this flag. The PLR must treat all three cases in the same way. This means that the PLR must assume that no merging occurred. 5.5. Requesting for backup record route by ingress router By default, all nodes along the path of the main LSP, process the RRO as defined in [4]. If the ingress router wants the egress router to initiate the recording of the paths of the backup LSPs by means of the BRRO, the ingress router has to indicate this with a new flag in the Session Attribute Object: 0x08 Record path of backup LSP desired If set, the routers along the path of the main LSP SHOULD put the path (or the part of the path until the merging node) in the BRRO of the main LSP. This means that the recording of the backup paths is on request by the ingress router, and may be switched off (by resetting the above flag) when the information is not anymore needed by the ingress router. 6. Security Considerations There are no new security issues compared to [3] and [4]. 8. References De Cnodder, et. al. [Page 11] draft-decnodder-mpls-ero-rro-fastreroute-00.txt February 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 Requirement Levels", BCP 14, RFC 2119, March 1997 [3] Pan, P., Gan, D., Swallow, G., Vasseur, J.Ph., Copper, D., Atlas, A., Jork, M., "Fast Reroute Technique in RSVP-TE", Internet draft, draft-pan-rsvp-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. 9. Acknowledgments We would like to thank Dimitri Papadimitriou and Claus Bauer for their helpful comments. 10. Author's 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 Sven Van den Bosch Alcatel Francis Wellesplein 1 B-2018 Antwerp, Belgium Email: sven.van_den_bosch@alcatel.be De Cnodder, et. al. [Page 12] draft-decnodder-mpls-brro-fastreroute-00.txtFebruary 2002 Der-Hwa Gan Juniper Networks, Inc. 1194 N. Mathilda Avenue Sunnyvale, CA 94089 Email: dhg@juniper.net A. Appendix: example of BERO Network topology F------G------H------I------+ | | | | | | | | A------B-------------C------D | | | | | | +-------------E------+ Detour setup without BERO object: Protected LSP is established through nodes A-B-C-D. Node A calculates path A-F-G-H-I-D for the detour. Node B calculates path B-E-D for the detour, which is the shortest path to the destination of the protected LSP. Node C calculates path C-I-D for the detour. Detour of node A and node C are merged together at node I. F******G******H******I******* * | * * * | * * A======B=============C======D * | * * | * **************E******* Detour Setup with BERO object: Ingress node A calculates the following detour paths: Detour-A: A-F-G-H-I-D Detour-B: B-G-H-I-D Detour-C: C-I-D In this case, although the shortest path from node B to node D is via node E, since there is already a detour needed through G-H-I-D for the detour of node A, node A prefers to merge detour of node B with his detour at node G. F******G******H******I******* * * * * * * * * De Cnodder, et. al. [Page 13] draft-decnodder-mpls-brro-fastreroute-00.txtFebruary 2002 A======B=============C======D | | | | | | +-------------E------+ BERO object sent from node A to node B contains the following information: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=1 | Length=40 | IPv4 address= Node B | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node B continued | 32 | Flags=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Type=1 | Length=8 | IPv4 address= Node G | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node G continued | 32 | Flags=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Type=1 | Length=8 | IPv4 address= Node H | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node H continued | 32 | Flags=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Type=1 | Length=8 | IPv4 address= Node I | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node I continued | 32 | Flags=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Type=1 | Length=8 | IPv4 address= Node D | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node D continued | 32 | Flags=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=1 | Length=24 | IPv4 address= Node C | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node C continued | 32 | Flags=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Type=1 | Length=8 | IPv4 address= Node I | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node I continued | 32 | Flags=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Type=1 | Length=8 | IPv4 address= Node D | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Node D continued | 32 | Flags=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ When B sends the BERO to C, it will remove the first subobject (40 bytes) such that the subobject belonging to node C appears at the top of the BERO. De Cnodder, et. al. [Page 14] draft-decnodder-mpls-brro-fastreroute-00.txtFebruary 2002 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. De Cnodder, et. al. [Page 15]