Network Working Group K. Kompella Internet Draft Juniper Networks Category: Best Current Practice J. Lang Expires: August 2003 Consultant February 2003 Procedures for Modifying RSVP draft-kompella-rsvp-change-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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Kompella & Lang Best Current Practice [Page 1] Internet Draft Procedures for Modifying RSVP February 2003 Abstract This memo specifies procedures for modifying the Resource Reservation Protocol (RSVP). This memo also includes an IANA Considerations section that lays out new assignment guidelines for number spaces for RSVP messages, object classes, class-types and sub-objects. 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 [KEYWORDS]. 1. Introduction This memo specifies procedures for modifying the Resource Reservation Protocol (RSVP) [RSVP], including (but not limited to) adding, updating, extending or making obsolete: messages, message formats and procedures; object classes and class types, object formats and procedures; header formats; error codes and subcodes and semantics; and procedures for sending, receiving and addressing RSVP messages. IANA recognizes the following RSVP names spaces: Messages Types; Class Names, Class Numbers, Class Types and Sub-objects; Virtual Destination Ports; and Error Codes and (Subcode) Values (henceforth referred to as RSVP entities). This memo specifies for each name space ranges that are "for Private Use", "to be assigned by Expert Review", and "to be assigned by Standards Action" (these terms are defined in [IANA]). Assignments made from RSVP number spaces set aside for Private Use (i.e., for proprietary extensions) need not be documented. Independent RSVP implementations using the same Private Use code points will in general not interoperate, so care should be exercised in using these code points in a multi-vendor network. Assignments made from RSVP number spaces to be assigned by Expert Review are to be reviewed by an Expert designated by the IESG. It is upto the discretion of the Expert whether such assignments need to be documented, and what form and detail such documentation takes. The intent in this document is that code points from these ranges are used for Experimental extensions; it is RECOMMENDED that such assignments be accompanied by Experimental RFCs. If deployment suggests that these extensions are useful, then they should be described in Standards Track RFCs, and new code points from the Standards Action ranges be assigned. Kompella & Lang Best Current Practice [Page 2] Internet Draft Procedures for Modifying RSVP February 2003 Assignments from RSVP number spaces to be assigned by Standards Action MUST be documented by a Standards Track RFC, typically submitted to an IETF Working Group, but in any case following the usual IETF procedures for Proposed Standards. 2. Modifying RSVP Procedures RSVP entities have associated procedures describing when and how they are to be sent, received and processed. If it is desired to change a procedure that affects the processing of an RSVP entity that belongs to a range designated "Standards Action", such a change MUST be documented in a Standards Track RFC. 3. Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [RSVP] Braden, R. Ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. 4. Informative References [IANA] Narten, T. and H. Alvestrand, "Guidelines for IANA Considerations", BCP 26, RFC 2434, October 1998. [RSVP-IPSEC] Berger, L., and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997. [RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., and Swallow, G., "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 2001. Kompella & Lang Best Current Practice [Page 3] Internet Draft Procedures for Modifying RSVP February 2003 5. Security Considerations It is hoped that the procedures outlined in this memo will ensure that changes made to RSVP will be better reviewed and thus be more architecturally sound, thereby enhancing the security both of the protocol and of networks deploying it. 6. IANA Considerations For each of the RSVP name spaces identified by IANA, the space is divided into assigment ranges as follows. 6.1. Message Types A Message Type is an 8-bit number that identifies the function of the RSVP message. Values from 0 through 239 are to be assigned by Standards Action. Values from 240 through 251 are to be assigned by Expert Review. Values from 252 through 255 are reserved for Private Use. 6.2. Class Names and Numbers Each class of data object in an RSVP message is identified by an all upper-case Class Name and an 8-bit Class Number (also known as C- Num). Class Numbers are divided broadly into three ranges (0-127, 128-191, and 192-255) determined by the two high-order bits of the Class-Num object (the 'b' represents a bit). o Class-Num = 0bbbbbbb Class Numbers from 0 through 119 are to be assigned by Standards Action. Class Numbers from 120 through 123 are to be assigned by Expert Review. Class Numbers from 124 through 127 are reserved for Private Use. o Class-Num = 10bbbbbb Class Numbers from 128 through 183 are to be assigned by Standards Action. Class Numbers from 184 through 187 are to be assigned by Expert Review. Class Numbers from 188 through 191 are reserved for Private Use. o Class-Num = 11bbbbbb Class Numbers from 192 through 247 are to be assigned by Standards Action. Class Numbers from 248 through 251 are to be assigned by Expert Review. Class Numbers from 252 through 255 Kompella & Lang Best Current Practice [Page 4] Internet Draft Procedures for Modifying RSVP February 2003 are reserved for Private Use. 6.3. Class Types Within each object class there is an 8-bit Class Type (also known as a C-Type). Class Types are scoped to a Class Number. For each object class, Class Types from 0 to 191 are to be assigned by Standards Action. Class Types from 192 through 223 are to be assigned by Expert Review. Class Types from 224 through 255 are reserved for Private Use. 6.3.1. Sub-objects Within a Class Type, sub-objects may be defined, generally as a Type- Length-Value triple. These sub-objects are also registered with IANA, and appropriate ranges of values will be set aside for these. For now, the following are defined. The EXPLICIT_ROUTE object [RSVP-TE] carries a variable length sub- object that is identified by a 7-bit Type field. Types 0 through 119 are to be assigned by Standards Action. Types 120 through 123 are to be assigned by Expert Review. Types 124 through 127 are to be reserved for Private Use. The RECORD_ROUTE object [RSVP-TE] carries a variable length sub- object that is identified by an 8-bit Type field. Types 0 through 119 are to be assigned by Standards Action. Types 120 through 123 are to be assigned by Expert Review. Types 124 through 127 are to be reserved for Private Use. Types 128 through 247 are to be assigned by Standards Action. Types 248 through 251 are to be assigned by Expert Review. Types 252 through 255 are to be reserved for Private Use. 6.4. Virtual Destination Ports Virtual destination ports are described in [RSVP-IPSEC], which also specifies how IANA assignments are to be made. 6.5. Error Codes and Values An Error Code is an 8-bit quantity that appears in an ERROR_SPEC object to broadly define an error condition. With each Error Code there may be a 16-bit Error Value that further specifies the cause of the error. Error Value may be globally defined, in which case the sub-code component is assigned by IANA. Error Code values from 0 through 239 are to be assigned by Standards Action. Values from 240 through 251 are to be assigned by Expert Kompella & Lang Best Current Practice [Page 5] Internet Draft Procedures for Modifying RSVP February 2003 Review. Values from 252 through 255 are reserved for Private Use. Globally defined Error Values are assigned by Standards Action. Acknowledgments Many thanks to Scott Bradner, who was not discouraging. More cannot be said without his explicit permission. Authors' Addresses Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA Email: kireeti@juniper.net Jonathan P. Lang Email: jplang@ieee.org Full Copyright Notice Copyright (C) The Internet Society (2003). 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 Kompella & Lang Best Current Practice [Page 6] Internet Draft Procedures for Modifying RSVP February 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kompella & Lang Best Current Practice [Page 7]