Network Working Group K. Kompella
Internet Draft Juniper Networks
Updates: 2205 3209 J. Lang
Category: Best Current Practice Rincon Networks
Expires: November 2004 May 2004
Procedures for Modifying RSVP
draft-kompella-rsvp-change-02.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 (2004). All Rights Reserved.
Kompella & Lang Best Current Practice [Page 1]
Internet Draft Procedures for Modifying RSVP May 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.
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 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 for each name space ranges 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 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
Kompella & Lang Best Current Practice [Page 2]
Internet Draft Procedures for Modifying RSVP May 2004
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.
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 "Vendor Private
Use", 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.
"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.
Kompella & Lang Best Current Practice [Page 3]
Internet Draft Procedures for Modifying RSVP May 2004
2.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
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,
Kompella & Lang Best Current Practice [Page 4]
Internet Draft Procedures for Modifying RSVP May 2004
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.
Kompella & Lang Best Current Practice [Page 5]
Internet Draft Procedures for Modifying RSVP May 2004
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.
Acknowledgments
Many thanks to Scott Bradner, who encouraged this project, and made
several helpful comments and suggestions.
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.
IANA Considerations
See section 2.
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.
[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 6]
Internet Draft Procedures for Modifying RSVP May 2004
Informative References
[ENT] IANA PRIVATE ENTERPRISE NUMBERS,
http://www.iana.org/assignments/enterprise-numbers
[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.
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
Full Copyright Notice
Copyright (C) The Internet Society (2004). 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
Kompella & Lang Best Current Practice [Page 7]
Internet Draft Procedures for Modifying RSVP May 2004
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."
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kompella & Lang Best Current Practice [Page 8]
