summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3936.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3936.txt')
-rw-r--r--doc/rfc/rfc3936.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc3936.txt b/doc/rfc/rfc3936.txt
new file mode 100644
index 0000000..c298fda
--- /dev/null
+++ b/doc/rfc/rfc3936.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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 2004
+
+
+ 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.
+
+
+
+
+
+
+
+Kompella & Lang Best Current Practice [Page 3]
+
+RFC 3936 Procedures for Modifying RSVP October 2004
+
+
+ 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.
+
+
+
+
+
+
+Kompella & Lang Best Current Practice [Page 4]
+
+RFC 3936 Procedures for Modifying RSVP October 2004
+
+
+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.
+
+
+
+
+Kompella & Lang Best Current Practice [Page 5]
+
+RFC 3936 Procedures for Modifying RSVP October 2004
+
+
+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
+
+
+
+
+
+
+
+
+
+Kompella & Lang Best Current Practice [Page 6]
+
+RFC 3936 Procedures for Modifying RSVP October 2004
+
+
+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.
+
+
+
+
+
+
+
+Kompella & Lang Best Current Practice [Page 7]
+