Procedures for Modifying the Resource reSerVation Protocol (RSVP)
RFC 3936
Document | Type |
RFC - Best Current Practice
(October 2004; No errata)
Also known as BCP 96
Was draft-kompella-rsvp-change (individual in tsv area)
|
|
---|---|---|---|
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3936 (Best Current Practice) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
Send notices to | (None) |
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 Kompella & Lang Best Current Practice [Page 1] RFC 3936 Procedures for Modifying RSVP October 2004 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 Kompella & Lang Best Current Practice [Page 2] RFC 3936 Procedures for Modifying RSVP October 2004Show full document text