Internet Draft Hua Autumn Liu Ajay Sathyanath Expires April 2003 Ramesh Nagarajan Y.T. Wang Bharat T. Doshi Lucent Technologies October 2002 RSVP-TE Extension for Shared Mesh Protection 1. 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. 2. Abstract This document describes the use of RSVP [RSVP, RSVP-TE] to establish shared protection LSP tunnels. The method presented enables the set up and reservation of resources of protection LSPs while sharing the network protection bandwidth. The described use of RSVP allows the protection LSP to be established without changes to a pre-existing OSPF-TE protocol. Of course, A `TE' routing protocol is not required, but would be desirable as it would reduce the number of crank-backs. In the companion draft [Shared- OSPF-TE], extensions to OSPF/OSPF-TE are presented that enable further optimized operations to support efficient sharing of protection bandwidth. 3. Conventions used in this document The reader is assumed to be familiar with the terminology in [RSVP] liu-shared-mesh-restoration-rsvp-extension October 2002 draft-liu-mpls-rsvp-shared-protection-00.txt [Page 2] and [RSVP-TE]. LSR - Label Switch Router LSP - An MPLS Label Switched Path Protection Tunnel - The LSP that is used to backup up one of the many LSPs in many-to-one backup. OSPF - Open Shortest Path First TE - Traffic Engineering RRO - Record Route Object 4. Introduction This document describes the use of RSVP [RSVP, RSVP-TE] to establish shared protection LSPs among different primary tunnels. It allows MPLS network provide shared mesh protection discussed in [SHARED- PROTECTION]. A protection LSP is an additional connection/LSP between the same source-destination pair as the primary LSP, and is usually pre- established to achieve fast restoration. Protection LSPs take quite some amount of resources, and do not carry revenue-generating traffic like the primary LSP, unless of course a switch over occurs, and the protection LSP becomes active. In order to meet the needs of reducing bandwidth used for protection LSP, it is highly desirable to be able to share the resources as much as possible among all the protection paths of various primary paths. For example, suppose that in the simple topology shown below, R1 creates a primary tunnel via path [R1->R2->R3], and its protection tunnel via path [R1->R4->R5->R6- >R3]. Let, R7 create another primary tunnel via path [R7->R8->R9], and its protection tunnel via the path [R7->R5->R6->R9]. We see that both the protection paths, viz. [R1->R4->R5->R6->R3] and [R7->R5- >R6->R9] have a common link, [R5-R6]. Let us assume that both the primary paths needed 2 units of bandwidth, then the link [R5->R6], without the notion of sharing, would have to reserve 4 units of bandwidth. If however, the actual primary paths are known, link [R5- R6] need only reserve 2 units -- clearly more desirable than the former approach. liu-shared-mesh-restoration-rsvp-extension October 2002 draft-liu-mpls-rsvp-shared-protection-00.txt [Page 3] [R1]----------[R2]-------------[R3] \ / \ / [R4]-------[R5]-----------[R6] / \ / \ [R7]------[R8]-----[R9] 5.1. Need for RSVP Extension In common restoration schemes, especially the shared protection variety, paths are determined by the constituent `router ids' (as a result of both node and link protection). Therefore, in the methodology we propose, the `router ids' (RIDs) are needed to pin the LSP and to detect routing loops, whereas the `outgoing interface ids' (OIDs) are needed to find out the constituent links of a primary path. Knowing the primary path along each node of the secondary path allows the admission controller of that node to determine the exact amount of bandwidth required and that which can be shared Though RSVP-TE [RSVP-TE] has the ability to carry a `Record Route Object' (RRO), it only allows one to insert the `outgoing interface id' in the RRO. Since there is a need to have both outgoing interface and node IDs, we may either introduce a new subobject in the `Record Route Object' or introduce a new object altogether. We choose the latter because introducing a new subobject in the RRO has few problems, and they are: a)In order to use a new subobject to carry the RID, we need to define a new type for it. The intermediate routers would now insert both the OID and RID into the RRO with this new type. Once the destination router receives this information, it needs to transmit back the entire set of OIDs and RIDs to the source router, which is done through the RRO of the RESV message. If this information is copied as is from the PATH message to the RESV message's RRO, the source router would have no way to differentiate between the RRO of the PATH message and the RRO of the RESV message. One way to differentiate would be to specify a new `type', and allow the destination router to cast the PATH message's RRO to this new `type' before sending out the RESV message. This addition of a new `type' is not obvious and would only lead to confusion. b)The second and more important problem would be the extra amount of "useless" work the intermediate routers will have to perform while processing the RRO, both in the primary path's RESV message and the protection path's PATH message. The RESV message's RRO is needed solely for the reason of transmitting liu-shared-mesh-restoration-rsvp-extension October 2002 draft-liu-mpls-rsvp-shared-protection-00.txt [Page 4] the PATH message's RRO back to the source router. Similarly the RRO of the protection path's PATH message is needed for transmitting the `Primary Path List' along the protection path. However, the RRO functionality would cause every intermediate router to do additional work of inserting the OID and RID in the RRO, in order to acheive this. Clearly the intermediate routers are better off without inserting this extra information which is of no use to any router. c)If we choose to alter the functionality of the RRO for the primary path's RESV message and protection path's PATH message, we would be able to stop the intermediate routers from doing "extra amounts of useless work". However, this would lead to backward compatability issues, as the RRO now behaves differently for RESV and PATH messages, and is also variant on whether or not the messages are for the primary or the protection path. Clearly the above reasons are sufficient enough for us to choose the tack of defining a new object and provide it with specific processing rules. 6.0. RSVP Extensions We propose one additional object, RECORD_PRIMARY_PATH, that extends RSVP-TE for sharable protection LSP signaling. The new object is defined to be backward compatible for LSRs that do not recognize it (Section 3.10 in [RSVP]). Furthermore, the object can only be carried in RSVP PATH and RESV messages. 6.1. RECORD_PRIMARY_PATH Object (RPP object) The RECORD_PRIMARY_PATH object carries the list of router information which the primary LSP passes through. The admission controller on every node, in the protected path, uses this object to compute the exact (least) amount of bandwidth required to be reserved on every link of the protected LSP. The information obtained from the RECORD_PRIMARY_PATH object is useful in determining the amount of sharing that is possible with the existing protection LSPs. The Record Primary Path object has the following format: Length Total object length in bytes. Must always be a multiple of 4, and at least 4. liu-shared-mesh-restoration-rsvp-extension October 2002 draft-liu-mpls-rsvp-shared-protection-00.txt [Page 5] Class Format is 10bbbbbb, number is 0x8F. Refer section 3.3. Subobjects The contents of a RECORD_PRIMARY_PATH object are a series of variable-length data items called subobjects. Subobjects are defined in section 3.1.1 below. 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | | // (SubObjects) // | | +-------------+-------------+-------------+-------------+ C-Type is 1, 2 or 3. C-Type 1 is generally used by PATH messages in the primary path. C-Type 2 is used by RESV messages in the primary path, and C-Type 3 is used by PATH messages in the secondary path. If the C-Type of the object is 1, the object is used to collect information along the LSP setup. Each node that receives the object would add its own router ID and outgoing interface ID to the object. C-type 1 is used by PATH messages along the primary path. If the C-Type of the object is 2, each node that receives the object does not change the contents of the objects, and the object is passed unaltered to the next hop. C-Type 2 is used by RESV messages along the primary path. If the C-Type of the object is 3, each node that receives the object does not alter the contents of the objects, furthermore, the node makes a call to the admission controller providing the object as an argument. The object is then passed along unaltered to the next hop. C-Type 3 is used by the PATH message of the protection path. 6.1.1. Subobjects The contents of a RECORD_PRIMARY_PATH object are a series of variable liu-shared-mesh-restoration-rsvp-extension October 2002 draft-liu-mpls-rsvp-shared-protection-00.txt [Page 6] length items called subobjects. Each subobject has its own length field which contains the total length of the subobject in bytes, including its Type and Length fields. The length MUST always be a multiple of 4, and should at least be 4 bytes. Subobjects are organized as a last-in-first-out stack. The first subobject relative to the beginning of the object 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 object with no subobjects is considered illegal. Only 2 types of subobjects is currently defined. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x01 IPv4 address Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 12. Router ID The LSR's router ID. Interface ID If there is no ip address configured on the interface, then it is the interface index. Otherwise it is a 32-bit unicast, host address. Any network-reachable interface address is allowed here. Loopback address should not be used here. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ liu-shared-mesh-restoration-rsvp-extension October 2002 draft-liu-mpls-rsvp-shared-protection-00.txt [Page 7] | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 0x02 IPv6 address Length The Length contains the total length of the subobject in bytes, including the Type and Length fields. The Length is always 36. Router ID The LSR's router ID. Interface ID If there is no ip address configured on the interface, then it is the interface index. Otherwise it is a 128-bit unicast, host address. Any network-reachable interface address is allowed here. Loopback address should not be used here. 6.2. Processing RECORD_PRIMARY_PATH object Typically, if a node wants to setup a sharable protection, it initiates an RSVP session by adding the RECORD_PRIMARY_PATH Object (RPPO) with C-Type set to 1. The initial RPPO contains only one subobject, and it carries the sender's node ID and the outgoing interface id through which the PATH message is sent out. liu-shared-mesh-restoration-rsvp-extension October 2002 draft-liu-mpls-rsvp-shared-protection-00.txt [Page 8] When a primary LSP's PATH message containing an RPPO with C-Type set to 1, is received by an intermediate router, the router simply adds a new subobject to the existing RPPO. This new RPPO is then appended to the PATH message before sending it to the downstream node. The newly added subobject must have this router's "Router-ID" and the "Interface-Id" of the outgoing interface through which the path message was sent. When the PATH message arrives at the destination, the router stores a copy of it in the `Path State Block'. When a RESV message is sent to the upstream node, the RPPO with C-Type changed to 2, is appended to the RESV message. The RESV message's RPPO then passes through all intermediate nodes without change. When the source node receives the RESV message, it stores the RECORD_PRIMARY_PATH (RPP) in its `Path State Block'. When a protection LSP is initiated by the source node, the stored RECORD_PRIMARY_PATH is attached to the protection LSP's PATH message with the C-Type of the included object set to 3. At each intermediate node, the RECORD_PRIMARY_PATH is passed to the admission controller to find out the exact amount of bandwidth that can be shared with any of the existing protection LSPs, if any. For each refresh PATH message of the primary LSP, a new RECORD_PRIMARY_PATH Object is added to the PATH message and sent to the the destination thereby collecting the path the primary LSP traverses. The destination node updates the stored RECORD_PRIMARY_PATH object every time the refresh PATH arrives, before appending the object to the next refresh RESV message. When the source node receives the refresh RESV message, it updates the stored primary path list, thereby enabling the next refresh PATH message of the secondary LSP to carry the updated information. If a newly added subobject causes the RECORD_PRIMARY_PATH to be too big to fit in a PATH (or RESV) message, a PathErr (or ResvErr) message SHOULD be sent back to the sender (or receiver). An error code of "Notify" and an error value of "RPPO too large for MTU" is used. If the receiver receives such a ResvErr, it SHOULD send a PathErr message with error code of "Notify" and an error value of "RPPO notification". A sender receiving either of these error values SHOULD remove the RPPO from the PATH message. 6.3. Non-support of RECORD_PRIMARY_PATH object In order to achieve protection sharing and make optimal use of the protection bandwidth, all routers along the path must support RSVP and the RECORD_PRIMARY_PATH object. For backward compatibility, this object is assigned a class value of the form 10bbbbbb. RSVP routers liu-shared-mesh-restoration-rsvp-extension October 2002 draft-liu-mpls-rsvp-shared-protection-00.txt [Page 9] that do not support the object will therefore drop the object, but pass the PATH or RESV message along. If a primary path comprises of a router that does not understand the RPP object, that router would drop the object and the source router would be unable to get the `Primary Path List' (the RPP carrying the information of all the routers from source to destination). The admission controller would then be unable to allow sharing of the bandwidth among the various primary paths. This is reasonable, as the path setup and protection would still work, however, the bandwidth reserved for the protection path would not be optimal. 6.4. Error Codes for RECORD_PRIMARY_PATH In the processing described above, certain errors must be reported as "Notify". The value of the "Notify" error code is 25. For the Notify Error Code, the 16 bits of the Error Value field are: ss00 cccc cccc cccc The high order bits are as defined under Error Code 1. (See [RSVP]). When ss = 00, the following subcode (lower order 12 bits) is defined as: 4 RPP too large for MTU 7.0. Security Considerations This document raises no new security issues for OSPF. 8.0. Acknowledgments We would like to acknowledge and thank our collegues Akber Qureshi, Bharath Ramanna, Tao Liu, and John Oliva, for their helpful comments. 9.0. References [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) -- version 1 functional specification," RFC2205, September 1997. [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP tunnels", RFC3029, December 2001. [Share-OSPF-TE] Sathyanath et.al, "OSPF-TE Extensions for Shared Mesh Protection," IETF draft-sathyanath-ospf-mpls-shared-protection- 00.txt, Oct, 2002 [SHARED-PROTECTION] Akber Qureshi et.al, "MPLS-TE Shared Mesh liu-shared-mesh-restoration-rsvp-extension October 2002 draft-liu-mpls-rsvp-shared-protection-00.txt [Page 10] Protection," IETF draft-qureshi-mpls-shared-protection-00.txt, Oct, 2002 10.0. Intellectual Property Considerations Lucent Technologies Inc. may own intellectual property in some on some of the technologies disclosed in this document. The patent licensing policy of Lucent Technologies Inc. with respect to any patents or patent applications relating to this submission is stated in the March 1, 1999, letter to the IETF from Dr Roger E. Stricker, Intellectual Property Vice President, Lucent Technologies, Inc. This letter is on file in the offices of the IETF Secretariat. 11.0. Author Information Hua Autumn Liu Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733 e-mail: liuh@lucent.com phone: +1 732 332 6532 Ajay Sathyanath Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733 e-mail: ajays@lucent.com phone: +1 732 332 6049 Ramesh Nagarajan Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733 e-mail: rameshn@lucent.com phone: +1 732 949 2761 Y.T. Wang Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733 e-mail: ytwang@lucent.com phone: +1 732 949 0676 Bharat T. Doshi Lucent Technologies 101 Crawfords Corner Rd. Holmdel, NJ 07733 e-mail: bdoshi@lucent.com liu-shared-mesh-restoration-rsvp-extension October 2002 draft-liu-mpls-rsvp-shared-protection-00.txt [Page 11] phone: +1 732 332 0823 Full Copyright Statement "Copyright (C) The Internet Society (date). 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 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. liu-shared-mesh-restoration-rsvp-extension October 2002