Network Working Group Ting Cai Internet Draft (Terabeam) Expiration Date: May 2002 Ping Pan Network Working Group (Juniper Networks) Extending RSVP Object Class Encoding To Handle Unknown Objects draft-cai-rsvp-unknown-objects-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. 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 This memo describes a new method to encode RSVP object class numbers such that transit routers will have the ability to forward the messages with unknown objects in a timely fashion. draft-cai-rsvp-unknown-objects-01.txt ^L[Page 1] Internet Draft draft-cai-rsvp-unknown-objects-01.txt November 2001 1. Introduction RSVP [RSVP, Section 3.10] has defined a set of rules for implementations to deal with objects that have unknown class number. Specifically, for unknown objects whose Class-Num octet is 11bbbbbb (that is, the two high-order bits are set), the router must not reject the message and/or ignore the object. Instead, when one such unknown-class object is received in a tear-down or an error message, the entire RSVP message must be forwarded immediately. If a such unknown-class object is received in a Path or a Resv refresh message, the router will save the object, and only forward the message in the next refresh cycle. However, this behavior may not be acceptable for certain applications, where fast message delivery is desired. 2. RSVP Extensions The goal, then, is to provide a mechanism whereby routers can forward RSVP messages immediately, when the messages contain some unknown objects. This document defines a new unknown class number range for this purpose. The new extension is based on the existing encoding for Class-Num = 11bbbbbb [RSVP, Section 3.10]. 2.1. Syntax Every RSVP object consists of a one-word header, with the following format: 0 1 2 3 +-------------+-------------+-------------+-------------+ | Length (bytes) | Class-Num | C-Type | +-------------+-------------+-------------+-------------+ | | // (Object contents) // | | +-------------+-------------+-------------+-------------+ According to RFC2205, the high-order two bits of the Class-Num is used to determine what action a router should take if it does not recognize the Class-Num of an object. We extend this and propose the following: - Class-Num = 110bbbbb draft-cai-rsvp-unknown-objects-01.txt ^L[Page 2] Internet Draft draft-cai-rsvp-unknown-objects-01.txt November 2001 The router should check the object. If the object is new or different from the one that has been saved by the router, the message MUST be treated as a trigger message, and be processed accordingly. - Class-Num = 111bbbbb The node should follow the rules defined in RSVP for Class-Num = 11bbbbbb. 2.2. Detailed Rules The following more detailed rules hold for unknown-class objects with a Class-Num of the form 110bbbbb: 1. Such unknown-class objects received in PathTear, ResvTear, PathErr, or ResvErr messages should be forwarded immediately in the same messages. 2. When such unknown-class objects received in Path or Resv messages at a router, they must be compared with previously saved copies, if there are any. If the objects are new or different, the received messages MUST be considered as trigger messages, and be forwarded immediately. 3. When a Resv refresh is generated by merging multiple reservation requests, the refresh message should include the union of unknown-class objects from the component requests. Only one copy of each unique unknown-class object should be included in this union. The merged message must be forwarded immediately. 4. The original order of such unknown-class objects need not be retained; however, the message that is forwarded must obey the general order requirements for its message type. 2.3. Impact on Other Applications Currently, there are a number of known implementations that have been using the objects within the range of 110bbbbb, and can benefit from our proposal. The SESSION_ATTRIBUTE object (Class_Num 207) [RSVP-TE] is used to aid the setup of RSVP-TE LSPs, and is optional in Path messages. It carries control information such as local protection flags. It is draft-cai-rsvp-unknown-objects-01.txt ^L[Page 3] Internet Draft draft-cai-rsvp-unknown-objects-01.txt November 2001 possible that network operators may need to change a LSP's local protection behavior at run-time, for example, set/reset bandwidth- protection and node-protection features by changing the corresponding bits in the SESSION_ATTRIBUTE object [RSVP-FR]. If there are routers in the network that do not support the object, the local protection notifications may not take effect for a long time when using the existing rules. With our proposal, notification messages can be forwarded immediately on all network nodes. Similarly, FAST_REROUTE object (Class_Num 205) [RSVP-FR] is used to setup fast reroutable LSPs in the network, and needs to be forwarded in a timely fashion. Finally, a recent proposal on LSP data plane detection [LSP-PING] can benefit from the fast message delivery for RSVP unknown objects proposed here as well. 3. Security Considerations Forwarding objects with unknown class defined in this document helps incremental deployment of new objects, however, if not careful, it can create too many RSVP control messages to be generated and processed at routers. 4. Acknowledgments We thank Der-Hwa Gan and Yakov Rekhter for useful discussion. 5. References [RSVP] R. Braden, Ed., et al, "Resource ReSerVation protocol (RSVP) -- version 1 functional specification," RFC2205. [RSVP-TE] D. Awduche, et al, "RSVP-TE: Extensions to RSVP for LSP tunnels" Internet Draft. [RSVP-FR] P. Pan, et al, "Fast Reroute Techniques in RSVP-TE", Internet Draft. [LSP-PING] P. Pan, et al, "Detecting Data Plane Liveliness in RSVP- TE", Internet Draft. draft-cai-rsvp-unknown-objects-01.txt ^L[Page 4] Internet Draft draft-cai-rsvp-unknown-objects-01.txt November 2001 6. Author Information Ting Cai Terabeam Networks 14833 NE 87th St. Redmond, WA, USA mmail: Ting.Cai@terabeam.com phone: (206) 255-6220 Ping Pan Juniper Networks 1194 N.Mathilda Ave Sunnyvale, CA 94089 e-mail: pingpan@juniper.net phone: (408)-745-3704 draft-cai-rsvp-unknown-objects-01.txt ^L[Page 5]