GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:bcp:bcp96

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]

/data/webs/external/dokuwiki/data/pages/rfc/bcp/bcp96.txt · Last modified: 2004/10/14 23:46 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki