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
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)
修改资源预留协议（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).
版权所有（C）互联网协会（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.
本备忘录规定了修改资源预留协议（RSVP）的程序。本备忘录还列出了RSVP消息、对象类、类类型和子对象的数字空间的新分配准则。
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.
本备忘录规定了修改资源预留协议（RSVP）[RSVP]的程序，包括（但不限于）添加、更新、扩展或废弃：消息、消息格式和程序、对象类和类类型、对象格式和程序；头格式、错误代码和子代码以及语义，以及发送、接收和寻址RSVP消息的过程。
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.
IANA识别以下RSVP名称空间：消息类型、类名、类号、类类型和子对象、虚拟目标端口、错误代码和（子代码）值（所有这些在本文档中统称为RSVP实体）。此备注指定每个名称空间的范围以及每个范围的分配策略。必须在标准轨道RFC中定义新的RSVP名称空间，其中包括新名称空间内IANA分配的指南。
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
本文件中使用的分配政策为：标准行动（定义见[IANA]）、专家评审和组织/供应商私有（更简单地说，“供应商私有”）；最后两个在本文件中定义。这些派遣政策的目的是确保
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.
RSVP的扩展在分配代码点之前得到充分的审查，而不是过于严格。因此，如果一个扩展被广泛接受，并且它的分支被很好地理解，它可能会收到来自标准行动空间的任务；然而，如果扩展在本质上是实验性的，那么它会收到专家评审空间的任务，并且随着成熟度的提高，可能会转移到标准轨道。不审查来自供应商专用空间的分配，但有适当的机制确保这些代码点可以在网络中共存而不受损害。
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.
除IETF外，希望获得RSVP实体分配的标准机构必须决定他们希望分配的名称/编号空间类型，然后提交适当的文件。例如，如果要从指定为标准行动的数字空间进行分配，则必须提交标准跟踪RFC以支持分配请求。
This memo updates the IANA Considerations section (section 7) of [RSVP-TE], replacing the assignment policies stated there.
本备忘录更新了[RSVP-TE]的IANA注意事项部分（第7节），取代了此处规定的派遣政策。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[关键词]中的描述进行解释。
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.
对于IANA标识的每个RSVP名称空间，该空间被划分为分配范围；以下术语用于描述IANA分配值的程序：“标准行动”（定义见[IANA]）、“专家评审”和“组织/供应商私人”，定义如下。
"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.
“专家评审”范围指由IESG指定的专家评审的数值。这些范围中的代码点通常用于实验扩展；此类分配必须由记录其使用和处理的实验性RFC请求，以及IANA行动期间为该文件所做的实际分配。“专家评审”范围内的数值必须向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
“组织/供应商私有”范围是指特定于企业的值；这些文件不得在IANA注册。对于供应商私有值，数据字段的前4个八位字节字必须是在IANA SMI网络中注册的企业代码[ENT]
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.
管理私营企业代码，此后的其余数据供注册企业私人使用。（对于具有供应商专用范围的每个RSVP实体，必须指定数据字段的确切起始位置；请参见下面的示例。）通过这种方式，不同的企业、供应商或标准开发组织（SDO）可以使用相同的代码点，而无需担心冲突。
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.
消息类型是标识RSVP消息功能的8位数字。0到239之间的值由标准行动分配。240到255之间的值由专家评审指定。
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).
RSVP消息中的每一类数据对象都由一个全大写的类名和一个8位的类号（也称为class Num或C-Num）标识。类号大致分为三个范围（0-127、128-191和192-255），由Class Num对象的两个高阶位确定（下面的“b”表示位）。
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.
注意：类别Num或类别Type来自供应商私有范围的对象的第一个32位字必须是该供应商的SMI企业代码（按网络八位字节顺序）（这些企业代码可以从IANA获得并向IANA注册）。如[RSVP]第3.10节所述，遇到供应商私有对象且其SMI企业代码不可识别的实现必须基于类Num处理该对象（以及封装的消息）。
o Class-Num = 0bbbbbbb
o 类别编号=0bbb
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.
0到119之间的班级编号由标准行动分配。120至123的课程编号由专家评审分配。从124到127的类别编号保留供供应商私人使用。
o Class-Num = 10bbbbbb
o 类别编号=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.
128到183之间的班级编号由标准行动分配。从184到187的课程编号由专家评审分配。从188到191的分类号保留给供应商私人使用。
o Class-Num = 11bbbbbb
o 类别编号=11bbbbbbbb
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.
192到247之间的班级编号由标准行动分配。从248到251的课程编号由专家评审分配。从252到255的类别编号保留供供应商私人使用。
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.
在每个对象类中都有一个8位类类型（也称为C类型）。类类型的作用域为类编号。一般来说，允许通过专家评审或供应商私有分配类类型的适当性取决于类编号本身的语义。因此，任何新的类号定义都必须指定适当的IANA注意事项策略，以分配其他类类型值。
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.
对于本文档日期之前的课程编号（具体而言，0、1、3-25、30-37、42-45、64、65、128-131、161-165、192-196和207），新课程类型的默认分配策略为标准行动，除非标准跟踪或最佳当前实践RFC取代了该策略。
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.
在对象中，子对象可以定义为类型长度值三元组。此备忘录定义了显式路由和记录路由的子对象的分配策略。定义新子对象的RFC必须说明IANA如何分配子对象类型。
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.
显式路由对象[RSVP-TE]携带由7位类型字段标识的可变长度子对象。类型0到119由标准行动分配。类型120至123由专家评审指定。124至127型应保留供供应商私人使用。
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.
记录路由对象[RSVP-TE]携带由8位类型字段标识的可变长度子对象。类型0到191将由标准行动分配。192至251类由专家评审指定。类型252至255保留供供应商私人使用。
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.
显式路由或记录路由对象的供应商私有子对象的子对象内容的前四个八位字节必须是该供应商的SMI企业代码（按网络八位字节顺序）。
Virtual destination ports are described in [RSVP-IPSEC], which also specifies how IANA assignments are to be made.
[RSVP-IPSEC]中描述了虚拟目标端口，它还指定了如何进行IANA分配。
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_SPEC对象中的8位数量，用于广义定义错误条件。对于每个错误代码，可能有一个16位错误值，进一步指定错误原因。错误值可以全局定义，在这种情况下，子代码组件由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.
0到239之间的错误代码值将由标准操作分配。240到251之间的值由专家评审指定。252到255之间的值保留供供应商私人使用。如果错误代码供供应商私人使用，则错误值后的前四个八位字节必须是供应商的SMI企业代码（按网络八位字节顺序）。
Globally defined Error Values are assigned by Standards Action.
全局定义的错误值由标准操作分配。
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.
RSVP实体具有相关程序，描述何时以及如何发送、接收、处理和响应这些实体。影响属于指定“标准行动”范围的RSVP实体处理的程序变更必须记录在标准跟踪RFC中。影响属于指定“专家评审”范围的RSVP实体处理的程序变更必须记录在实验RFC中。
Many thanks to Scott Bradner, who encouraged this project, and made several helpful comments and suggestions.
非常感谢Scott Bradner，他鼓励了这个项目，并提出了一些有用的意见和建议。
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.
希望本备忘录中概述的程序将确保对RSVP所做的更改得到更好的审查，从而在体系结构上更加完善，从而增强协议和部署协议的网络的安全性。
See section 2.
见第2节。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 22052997年9月。
[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.
[RSVP-TE]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.，和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[ENT] IANA PRIVATE ENTERPRISE NUMBERS,
http://www.iana.org/assignments/enterprise-numbers
[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.
[IANA]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RSVP-IPSEC] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.
[RSVP-IPSEC]Berger，L.和T.O'Malley，“IPSEC数据流的RSVP扩展”，RFC 2207，1997年9月。
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA
Kireeti Kompella Juniper Networks 1194 N.Mathilda Ave Sunnyvale，加利福尼亚州94089
EMail: kireeti@juniper.net
EMail: kireeti@juniper.net
Jonathan P. Lang Rincon Networks
Jonathan P.Lang Rincon网络公司
EMail: jplang@ieee.org
EMail: jplang@ieee.org
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。