Network Working Group A. Farrel
Request for Comments: 4859 Old Dog Consulting
Category: Informational April 2007
Network Working Group A. Farrel
Request for Comments: 4859 Old Dog Consulting
Category: Informational April 2007
Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object
资源预留协议流量工程（RSVP-TE）会话属性对象中标志字段的代码点注册表
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document provides instructions to IANA for the creation of a new codepoint registry for the flags field in the Session Attribute object of the Resource Reservation Protocol Traffic Engineering (RSVP-TE) signaling messages used in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) signaling.
本文档向IANA提供了为多协议标签交换（MPLS）和通用MPLS（GMPLS）信令中使用的资源预留协议流量工程（RSVP-TE）信令消息的会话属性对象中的标志字段创建新代码点注册表的说明。
The Resource Reservation Protocol (RSVP) [RFC2205] has been extended as RSVP for Traffic Engineering (RSVP-TE) for use in Multiprotocol Label Switching (MPLS) signaling [RFC3209] and Generalized MPLS (GMPLS) [RFC3473].
资源预留协议（RSVP）[RFC2205]已扩展为用于流量工程的RSVP（RSVP-TE），用于多协议标签交换（MPLS）信令[RFC3209]和通用MPLS（GMPLS）[RFC3473]。
[RFC3209] introduced a new signaling object, the Session Attribute object, that is carried on the RSVP Path message. The Session Attribute object contains an eight-bit field of flags.
[RFC3209]引入了一个新的信令对象，即RSVP Path消息中携带的会话属性对象。会话属性对象包含八位标志字段。
The original specification of RSVP-TE assigned uses to three of these bit flags. Subsequent MPLS and GMPLS RFCs have assigned further flags.
RSVP-TE的原始规范指定使用其中三个位标志。随后的MPLS和GMPLS RFC分配了更多的标志。
There is a need for a codepoint registry to track the use of the bit flags in this field, to ensure that bits are not assigned more than once, and to define the procedures by which such bits may be assigned.
需要一个代码点注册表来跟踪该字段中位标志的使用情况，以确保不会多次分配位，并定义分配这些位的过程。
This document lists the current bit usage and provides information for IANA to create a new registry. This document does not define the uses of specific bits -- definitive procedures for the use of the bits can be found in the referenced RFCs.
本文档列出了当前位的使用情况，并为IANA创建新注册表提供了信息。本文件未定义特定BIT的使用——BIT使用的最终程序可在参考RFC中找到。
[RFC3209] defines the use of three bits as follows:
[RFC3209]定义了三位的使用，如下所示：
0x01 Local protection desired
0x01需要本地保护
0x02 Label recording desired
0x02需要标签记录
0x04 SE Style desired
需要0x04 SE样式
[RFC4090] defines the use of two bits as follows:
[RFC4090]定义了两位的使用，如下所示：
0x08 Bandwidth protection desired
0x08需要带宽保护
0x10 Node protection desired
需要0x10节点保护
[RFC4736] defines the use of one bit as follows:
[RFC4736]定义一位的使用如下：
0x20 Path re-evaluation request
0x20路径重新评估请求
This informational document exists purely to create an IANA registry. Such registries help to protect the IETF process against denial-of-service attacks.
此信息性文档的存在纯粹是为了创建IANA注册表。此类注册表有助于保护IETF进程免受拒绝服务攻击。
Otherwise there are no security considerations for this document.
否则，本文档不考虑安全因素。
IANA has created a new codepoint registry as follows.
IANA创建了一个新的代码点注册表，如下所示。
The new registry has been placed under the "RSVP-TE Parameters" branch of the tree.
新注册表已放置在树的“RSVP-TE参数”分支下。
The new registry has been termed "Session Attribute Object Flags."
新注册表被称为“会话属性对象标志”
Flags from this registry may only be assigned by IETF consensus [RFC2434].
此注册表中的标志只能由IETF协商一致[RFC2434]分配。
The registry references the flags already defined as described in Section 2 of this document.
注册表引用了本文件第2节中所述的已定义的标志。
Thanks to JP Vasseur, Bill Fenner, and Thomas Narten for reviewing this document.
感谢JP Vasseur、Bill Fenner和Thomas Narten审阅本文档。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）——版本1，功能规范”，RFC 22052997年9月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC3209] 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.
[RFC3209]Awduche，D.，Berger，L.，Gan，D.，Li，T.，Srinivasan，V.和G.Swallow，“RSVP-TE：LSP隧道RSVP的扩展”，RFC 3209，2001年12月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.，Ed.“通用多协议标签交换（GMPLS）信令-资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090]Pan，P.，Ed.，Swallow，G.，Ed.，和A.Atlas，Ed.，“LSP隧道RSVP-TE快速重路由扩展”，RFC 40902005年5月。
[RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, November 2006.
[RFC4736]Vasseur，JP.，Ed.，Ikejiri，Y.，和R.Zhang，“多协议标签交换（MPLS）流量工程（TE）松路由标签交换路径（LSP）的再优化”，RFC 47362006年11月。
Author's Address
作者地址
Adrian Farrel Old Dog Consulting
阿德里安·法雷尔老狗咨询公司
EMail: adrian@olddog.co.uk
EMail: adrian@olddog.co.uk
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见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编辑功能的资金目前由互联网协会提供。