Procedures for Modifying the Resource reSerVation Protocol (RSVP)
The rulebook for who may change RSVP and how new message types, object classes and error codes get their numbers.
Kompella, K. and J. Lang, "Procedures for Modifying the Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936, DOI 10.17487/RFC3936, October 2004, <https://www.rfc-editor.org/info/rfc3936>.
@misc{rfc3936,
series = {Request for Comments},
number = 3936,
howpublished = {RFC 3936},
publisher = {RFC Editor},
doi = {10.17487/RFC3936},
url = {https://www.rfc-editor.org/info/rfc3936},
author = {K. Kompella and J. Lang},
title = {{Procedures for Modifying the Resource reSerVation Protocol (RSVP)}},
pagetotal = 7,
year = 2004,
month = oct,
} RFC text
Contents
Network Working Group K. Kompella Request for Comments: 3936 Juniper Networks Updates: 3209, 2205 J. Lang BCP: 96 Rincon Networks Category: Best Current Practice October 2004 Procedures for Modifying the Resource reSerVation Protocol (RSVP) Status of this Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This memo specifies procedures for modifying the Resource reSerVation Protocol (RSVP). This memo also lays out new assignment guidelines for number spaces for RSVP messages, object classes, class-types, and sub-objects. 1. Introduction This memo specifies procedures for modifying the Resource reSerVation Protocol (RSVP) [RSVP], including (but not limited to) adding, updating, extending or obsoleting: 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 name spaces: Message Types, Class Names, Class Numbers, Class Types and Sub-objects, Virtual Destination Ports, and Error Codes and (Subcode) Values (all of these will collectively be referred to as RSVP entities in this document). This memo specifies ranges for each name space and assignment policies for each range. New RSVP name spaces must be defined in a Standards Track RFC which include guidelines for IANA assignments within the new name spaces. The assignment policies used in this document are: Standards Action (as defined in [IANA]), Expert Review, and Organization/Vendor Private (more simply, "Vendor Private"); the last two are defined in this document. The intent of these assignment policies is to ensure that extensions to RSVP receive adequate review before code-points are assigned, without being overly rigid. Thus, if an extension is widely accepted and its ramifications are well understood, it may receive an assignment from the Standards Action space; however, if an extension is experimental in nature, it receives an assignment from the Expert Review space, and may, with maturity, move to Standards Track. Assignments from the Vendor Private space are not reviewed, but there are mechanisms in place to ensure that these codepoints can co-exist in a network without harm. A standards body other than the IETF that wishes to obtain an assignment for an RSVP entity must decide from which type of name/number space they desire their assignment be made from, and then submit the appropriate documentation. For example, if the assignment is to be made from a number space designated as Standards Action, a Standards Track RFC MUST be submitted in support of the request for assignment. This memo updates the IANA Considerations section (section 7) of [RSVP-TE], replacing the assignment policies stated there. 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 BCP 14, RFC 2119 [KEYWORDS]. 2. Assignment Policies for RSVP Entities For each of the RSVP name spaces identified by IANA, the space is divided into assignment ranges; the following terms are used in describing the procedures by which IANA assigns values: "Standards Action" (as defined in [IANA]), "Expert Review", and "Organization/Vendor Private", defined below. "Expert Review" ranges refer to values that are to be reviewed by an Expert designated by the IESG. The code points from these ranges are typically used for experimental extensions; such assignments MUST be requested by Experimental RFCs that document their use and processing, and the actual assignments made during the IANA actions for the document. Values from "Expert Review" ranges MUST be registered with IANA. "Organization/Vendor Private" ranges refer to values that are enterprise-specific; these MUST NOT be registered with IANA. For Vendor Private values, the first 4-octet word of the data field MUST be an enterprise code [ENT] as registered with the IANA SMI Network Management Private Enterprise Codes, and the rest of the data thereafter is for the private use of the registered enterprise. (For each RSVP entity that has a Vendor Private range, it must be specified where exactly the data field starts; see below for examples.) In this way, different enterprises, vendors, or Standards Development Organizations (SDOs) can use the same code point without fear of collision. 2.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 255 are to be assigned by Expert Review. 2.2. Class Names and Numbers Each class of data objects in an RSVP message is identified by an all upper-case Class Name and an 8-bit Class Number (also known as Class-Num or 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' below represents a bit). Note: the first 32-bit word of an Object whose Class-Num or Class- Type is from the Vendor Private range MUST be that vendor's SMI enterprise code in network octet order (these enterprise codes can be obtained from, and registered with, IANA). An implementation encountering a Vendor Private object with an SMI enterprise code that it does not recognize MUST treat that object (and enclosing message) based on the Class-Num, as specified in [RSVP], section 3.10. 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 Vendor 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 Vendor 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 are reserved for Vendor Private Use. 2.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. In general, the appropriateness of allowing assignments of Class Types through Expert Review or Vendor Private depends on the semantics of the Class Number itself. Thus, any new Class Number definition must specify an appropriate IANA Considerations policy for assigning additional Class Type values. For Class Numbers that pre-date this document (specifically, 0, 1, 3-25, 30-37, 42-45, 64, 65, 128-131, 161-165, 192-196, and 207), the default assignment policy for new Class Types is Standards Action, unless a Standards Track or Best Current Practice RFC supercedes this. 2.3.1. Sub-objects Within an object, sub-objects may be defined, generally as a Type- Length-Value triple. This memo defines the assignment policies for sub-objects of EXPLICIT_ROUTE and RECORD_ROUTE. An RFC defining new sub-objects MUST state how IANA is to assign the sub-object Types. 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 Vendor 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 191 are to be assigned by Standards Action. Types 192 through 251 are to be assigned by Expert Review. Types 252 through 255 are to be reserved for Vendor Private Use. The first four octets of the sub-object contents of a Vendor Private sub-object of an EXPLICIT_ROUTE or RECORD_ROUTE object MUST be that vendor's SMI enterprise code in network octet order. 2.4. Virtual Destination Ports Virtual destination ports are described in [RSVP-IPSEC], which also specifies how IANA assignments are to be made. 2.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 Review. Values from 252 through 255 are reserved for Vendor Private Use. If the Error Code is for Vendor Private Use, the first four octets following the Error Value MUST be the vendor's SMI enterprise code in network octet order. Globally defined Error Values are assigned by Standards Action. 3. Modifying RSVP Procedures RSVP entities have associated procedures describing when and how they are to be sent, received, processed, and responded to. A change to a procedure that affects the processing of an RSVP entity that belongs to a range designated "Standards Action" MUST be documented in a Standards Track RFC. A change to a procedure that affects the processing of an RSVP entity that belongs to a range designated "Expert Review" MUST be documented in an Experimental RFC. 4. Acknowledgements Many thanks to Scott Bradner, who encouraged this project, and made several helpful comments and suggestions. 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 more architecturally sound, thereby enhancing the security both of the protocol and of networks deploying it. 6. IANA Considerations See section 2. 7. References 7.1. 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., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. 7.2. Informative References [ENT] IANA PRIVATE ENTERPRISE NUMBERS, http://www.iana.org/assignments/enterprise-numbers [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RSVP-IPSEC] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997. 8. Authors' Addresses Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA EMail: kireeti@juniper.net Jonathan P. Lang Rincon Networks EMail: jplang@ieee.org 9. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.
AI ELI5
On this page
§1Scope and Goals
This memo gives procedures for modifying the Resource reSerVation Protocol (RSVP): adding, updating, extending or obsoleting messages, object classes, header formats, error codes, and the procedures for sending, receiving and addressing RSVP messages.
IANA recognizes these RSVP name spaces: Message Types, Class Names, Class Numbers, Class Types and Sub-objects, Virtual Destination Ports, and Error Codes and (Subcode) Values. The memo sets ranges and assignment policies for each. New RSVP name spaces must be defined in a Standards Track RFC that includes IANA guidelines.
The aim is that extensions get adequate review before code points are assigned, without being overly rigid. It also updates the IANA Considerations section (section 7) of RFC 3209, replacing the policies stated there.
When people want to add something new to the reservation system, there must be fair rules so changes are checked first but not blocked for no reason.
§2The Three Assignment Policies
Each number space is divided into ranges, and each range uses one of three policies.
- Standards Action, as defined in RFC 2434: needs a Standards Track RFC. Suited to widely accepted extensions whose ramifications are well understood.
- Expert Review: values reviewed by an Expert designated by the IESG, typically for experimental extensions. Such assignments MUST be requested by Experimental RFCs documenting their use and processing, and the values MUST be registered with IANA.
- Organization/Vendor Private: enterprise-specific values that MUST NOT be registered with IANA. The first 4-octet word of the data MUST be an enterprise code from the IANA SMI Network Management Private Enterprise Codes, so different vendors or standards bodies can use the same code point without collision.
A standards body other than the IETF must pick which kind of space it wants and submit the matching documentation. For a Standards Action space, a Standards Track RFC MUST be submitted.
There are three kinds of doors for getting a new number. One needs a big vote, one needs a single expert's okay, and one is a private door where each company adds its own name tag first.
§3Message Types, Class Numbers and Class Types
A Message Type is an 8-bit number. Values 0 through 239 go by Standards Action and 240 through 255 by Expert Review.
Each object class has a Class Name and an 8-bit Class Number, split into three ranges by the two high-order bits. In each range the Standards Action, Expert Review and Vendor Private blocks are laid out as in the table below. A Vendor Private object must begin with the vendor's SMI enterprise code in network octet order. If an implementation does not recognize the code, it MUST handle the object and its message based on the Class-Num, as specified in RFC 2205, section 3.10.
Within a class, an 8-bit Class Type is scoped to the Class Number. Any new Class Number definition must say how additional Class Types are assigned. For the pre-existing Class Numbers the default is Standards Action unless a Standards Track or BCP RFC supersedes it.
Sub-objects of EXPLICIT_ROUTE (7-bit Type) and RECORD_ROUTE (8-bit Type) also get ranges. The first four octets of a Vendor Private sub-object MUST be the vendor's SMI enterprise code.
Every kind of message and every kind of label has a number. The number line is cut into a part for official things, a part for experiments and a part for private company use.
| Space | Standards Action | Expert Review | Vendor Private |
|---|---|---|---|
| Message Type | 0-239 | 240-255 | none |
| Class-Num 0bbbbbbb | 0-119 | 120-123 | 124-127 |
| Class-Num 10bbbbbb | 128-183 | 184-187 | 188-191 |
| Class-Num 11bbbbbb | 192-247 | 248-251 | 252-255 |
| EXPLICIT_ROUTE sub-object | 0-119 | 120-123 | 124-127 |
| RECORD_ROUTE sub-object | 0-191 | 192-251 | 252-255 |
| Error Code | 0-239 | 240-251 | 252-255 |
§4Error Codes and Virtual Destination Ports
An Error Code is an 8-bit value in the ERROR_SPEC object that broadly defines an error. It may come with a 16-bit Error Value giving more detail. Codes 0 through 239 are Standards Action, 240 through 251 are Expert Review and 252 through 255 are Vendor Private. For a Vendor Private code, the first four octets after the Error Value MUST be the vendor's SMI enterprise code. Globally defined Error Values are assigned by Standards Action.
Virtual destination ports are described in RFC 2207, which also specifies how IANA assigns them.
Error numbers follow the same three-door idea. Numbers for private use start with the company's name tag so errors are never mixed up.
§5Changing Procedures
Each RSVP entity has procedures for when and how it is sent, received, processed and answered. A change to a procedure affecting an entity in a Standards Action range MUST be documented in a Standards Track RFC. A change affecting an entity in an Expert Review range MUST be documented in an Experimental RFC.
If you change how an official thing works, you need an official write-up. If you change an experimental thing, an experimental write-up is enough.
§6Security and IANA Notes
The security section is short and hopeful: the procedures are meant to ensure that changes to RSVP are better reviewed and so more architecturally sound, which should improve the security of the protocol and of networks deploying it. The IANA Considerations section simply points to section 2.
Checking changes carefully first makes it less likely that a new idea breaks something or opens a hole.