[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 RFC 3936

Network Working Group                                        K. Kompella
Internet Draft                                          Juniper Networks
Updates: 3209                                                    J. Lang
Category: Best Current Practice                          Rincon Networks
Expires: December 2003                                         June 2003


                     Procedures for Modifying RSVP
                   draft-kompella-rsvp-change-01.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 (2003).  All Rights Reserved.















Kompella & Lang           Best Current Practice                 [Page 1]


Internet Draft        Procedures for Modifying RSVP            June 2003


Abstract

   This memo specifies procedures for modifying the Resource reSerVation
   Protocol (RSVP).  This memo also includes an IANA Considerations
   section that 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: Messages Types; Class
   Names, Class Numbers, Class Types and Sub-objects; Virtual
   Destination Ports; and Error Codes and (Subcode) Values (henceforth
   referred to as RSVP entities).  This memo specifies for each name
   space ranges that are "Vendor Private", "assigned by Expert Review",
   and "assigned by Standards Action" (these terms are defined in the
   IANA Considerations section).  New RSVP name spaces must be defined
   in a Standards Track RFC which include guidelines for IANA
   assignments within the new name spaces.

   Assignments made from RSVP number spaces set aside for Vendor Private
   Use (i.e., for proprietary extensions) need not be documented.  These
   code points are further disambiguated by (SMI) enterprise codes (see
   [ENT]); thus, independent RSVP implementations can use the same
   Vendor Private Use code points and still interoperate without fear of
   code point collision.

   Assignments made from RSVP number spaces assigned by Expert Review
   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 accompanied by Experimental RFCs
   that document their use and processing.

   Assignments from RSVP number spaces assigned by Standards Action MUST



Kompella & Lang           Best Current Practice                 [Page 2]


Internet Draft        Procedures for Modifying RSVP            June 2003


   be documented by a Standards Track RFC.

   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.

   Note that this memo updates the IANA Considerations section (section
   7) of [RSVP-TE].


2. 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.


3. 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.


4. 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.





Kompella & Lang           Best Current Practice                 [Page 3]


Internet Draft        Procedures for Modifying RSVP            June 2003


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 be more
   architecturally sound, thereby enhancing the security both of the
   protocol and of networks deploying it.


6. IANA Considerations

   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 allocates values: "Standards
   Action" (as defined in [IANA]); "Expert Review" and "Vendor Private
   Use".

   Values from "Expert Review" ranges MUST be registered with IANA, and
   MUST be accompanied by an Experimental RFC that describes the format
   and procedures for using the code point.

   Values from "Vendor Private" ranges MUST NOT be registered with IANA;
   however, the first 4-octet word of the data field MUST be an
   enterprise code 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, several
   enterprises (vendors) can use the same code point without fear of
   collision.

6.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.

6.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



Kompella & Lang           Best Current Practice                 [Page 4]


Internet Draft        Procedures for Modifying RSVP            June 2003


   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.

6.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.  For each
   object class, Class Types from 0 to 191 are to be assigned by
   Standards Action.  Class Types from 192 through 223 are to be
   assigned by Expert Review.  Class Types from 224 through 255 are
   reserved for Vendor Private Use.

6.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.



Kompella & Lang           Best Current Practice                 [Page 5]


Internet Draft        Procedures for Modifying RSVP            June 2003


   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.

6.4. Virtual Destination Ports

   Virtual destination ports are described in [RSVP-IPSEC], which also
   specifies how IANA assignments are to be made.

6.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.


Acknowledgments

   Many thanks to Scott Bradner, who encouraged this project, and made
   several helpful comments and suggestions.














Kompella & Lang           Best Current Practice                 [Page 6]


Internet Draft        Procedures for Modifying RSVP            June 2003


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 (2003).  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
   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."











Kompella & Lang           Best Current Practice                 [Page 7]


Internet Draft        Procedures for Modifying RSVP            June 2003


Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.















































Kompella & Lang           Best Current Practice                 [Page 8]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/