Network Working Group Z. Ali
Request for Comments: 4558 R. Rahman
Category: Standards Track D. Prairie
Cisco Systems
D. Papadimitriou
Alcatel
June 2006
Network Working Group Z. Ali
Request for Comments: 4558 R. Rahman
Category: Standards Track D. Prairie
Cisco Systems
D. Papadimitriou
Alcatel
June 2006
Node-ID Based Resource Reservation Protocol (RSVP) Hello: A Clarification Statement
基于节点ID的资源预留协议（RSVP）Hello：一个澄清声明
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
Use of Node-ID based Resource Reservation Protocol (RSVP) Hello messages is implied in a number of cases, e.g., when data and control planes are separated, when TE links are unnumbered. Furthermore, when link level failure detection is performed by some means other than exchanging RSVP Hello messages, use of a Node-ID based Hello session is optimal for detecting signaling adjacency failure for Resource reSerVation Protocol-Traffic Engineering (RSVP-TE). Nonetheless, this implied behavior is unclear, and this document formalizes use of the Node-ID based RSVP Hello session in some scenarios. The procedure described in this document applies to both Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) capable nodes.
在许多情况下，例如，当数据和控制平面分离时，当TE链路不编号时，暗示使用基于节点ID的资源预留协议（RSVP）Hello消息。此外，当通过交换RSVP Hello消息以外的一些手段执行链路级故障检测时，使用基于节点ID的Hello会话对于检测资源预留协议业务工程（RSVP-TE）的信令邻接故障是最佳的。尽管如此，这种隐含的行为还不清楚，本文档正式规定了在某些场景中使用基于节点ID的RSVP Hello会话。本文档中描述的过程适用于支持多协议标签交换（MPLS）和通用MPLS（GMPLS）的节点。
The RSVP Hello message exchange was introduced in [RFC3209]. The usage of RSVP Hello has been extended in [RFC3473] to support RSVP Graceful Restart (GR) procedures.
[RFC3209]中引入了RSVP Hello消息交换。[RFC3473]中扩展了RSVP Hello的用法，以支持RSVP优雅重启（GR）过程。
More specifically, [RFC3473] specifies the use of the RSVP Hello messages for GR procedures for Generalized MPLS (GMPLS). GMPLS introduces the notion of control plane and data plane separation. In other words, in GMPLS networks, the control plane information is carried over a control network whose end-points are IP capable and that may be physically or logically disjoint from the data bearer links it controls. One of the consequences of separation of data bearer links from control channels is that RSVP Hello messages are not terminated on data bearer links' interfaces even if (some of) those are numbered. Instead, RSVP Hello messages are terminated at the control channel (IP-capable) end-points. The latter MAY be identified by the value assigned to the node hosting these control channels, i.e., Node-ID. Consequently, the use of RSVP Hello messages for GR applications introduces a need for clarifying the behavior and usage of Node-ID based Hello sessions.
更具体地说，[RFC3473]指定将RSVP Hello消息用于通用MPLS（GMPLS）的GR过程。GMPLS引入了控制平面和数据平面分离的概念。换句话说，在GMPLS网络中，控制平面信息通过控制网络传输，该控制网络的端点具有IP能力，并且可以从物理上或逻辑上与其控制的数据承载链路分离。将数据承载链路与控制信道分离的后果之一是，RSVP Hello消息不会在数据承载链路的接口上终止，即使（其中一些）接口已编号。相反，RSVP Hello消息在控制通道（支持IP）端点处终止。后者可以通过分配给承载这些控制信道的节点的值来识别，即节点ID。因此，对于GR应用程序使用RSVP Hello消息引入了澄清基于节点ID的Hello会话的行为和使用的需求。
Even in the case of packet switching capable interfaces, when link failure detection is performed by some means other than RSVP Hello messages (e.g., [BFD]), the use of Node-ID based Hello sessions is also optimal for detection of signaling adjacency failures for GMPLS-RSVP-TE and RSVP-TE when there is more than one link between a pair of nodes. Similarly, when all TE links between neighbor nodes are unnumbered, it is implied that the nodes will exchange Node-ID based Hello messages for detection of signaling adjacency failures. This document also clarifies the use of Node-ID based Hello message exchanges when all or a sub-set of TE links are unnumbered.
即使在支持分组交换的接口的情况下，当通过RSVP Hello消息（例如，[BFD]）以外的一些方式执行链路故障检测时，当一对节点之间存在多个链路时，使用基于节点ID的Hello会话对于GMPLS-RSVP-TE和RSVP-TE的信令邻接故障的检测也是最佳的。类似地，当相邻节点之间的所有TE链路都未编号时，这意味着节点将交换基于节点ID的Hello消息，以检测信令邻接故障。本文档还阐明了当TE链接的所有或子集未编号时，基于节点ID的Hello消息交换的使用。
Node-ID: TE Router ID as advertised in the Router Address TLV for OSPF [OSPF-TE] and Traffic Engineering Router ID TLV for ISIS [ISIS-TE]. For IPv6, the Node-ID refers to the Router_IPv6_Address for OSPFv3 [OSPFv3-TE] and the IPv6 TE Router_ID for IS-IS [IS-ISv6-TE].
节点ID:OSPF[OSPF-TE]的路由器地址TLV中公布的TE路由器ID和ISIS[ISIS-TE]的流量工程路由器ID TLV中公布的TE路由器ID。对于IPv6，节点ID指的是OSPFv3[OSPFv3 TE]的路由器_IPv6_地址和IS-IS[IS-ISv6-TE]的IPv6 TE路由器_ID。
Node-ID based Hello Session: A Hello session in which local and remote Node-IDs are used in the source and destination fields of the Hello packet, respectively.
基于节点ID的Hello会话：一种Hello会话，其中本地和远程节点ID分别用于Hello数据包的源字段和目标字段。
Interface bounded Hello Session: A Hello session in which local and remote addresses of the interface in question are used in the source and destination fields of the Hello packet, respectively.
接口绑定Hello会话：一种Hello会话，在该会话中，相关接口的本地和远程地址分别用于Hello数据包的源字段和目标字段。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
A Node-ID based Hello session is established through the exchange of RSVP Hello messages such that local and remote Node-IDs are respectively used in the source and destination fields of Hello packets. Here, for IPv4, Node-ID refers to the TE router-id as defined in the Router Address TLV for OSPF [OSPF-TE] and the Traffic Engineering router ID TLV for ISIS [ISIS-TE]. For IPv6, the Node-ID refers to the Router_IPv6_Address for OSPFv3 [OSPFv3-TE] and the IPv6 TE Router_ID for IS-IS [IS-ISv6-TE]. This section formalizes a procedure for establishing Node-ID based Hello sessions.
通过交换RSVP Hello消息建立基于节点ID的Hello会话，使得本地和远程节点ID分别用于Hello数据包的源字段和目的字段。这里，对于IPv4，节点ID指OSPF[OSPF-TE]的路由器地址TLV和ISIS[ISIS-TE]的流量工程路由器ID TLV中定义的TE路由器ID。对于IPv6，节点ID指的是OSPFv3[OSPFv3 TE]的路由器_IPv6_地址和IS-IS[IS-ISv6-TE]的IPv6 TE路由器_ID。本节正式说明了建立基于节点ID的Hello会话的过程。
If a node wishes to establish a Node-ID based RSVP Hello session with its neighbor, it sends a Hello message with its Node-ID in the source IP address field of the Hello packet. Furthermore, the node also puts the neighbor's Node-ID in the destination address field of the IP packet.
如果节点希望与其邻居建立基于节点ID的RSVP Hello会话，它将在Hello数据包的源IP地址字段中发送一条带有节点ID的Hello消息。此外，该节点还将邻居的节点ID放入IP分组的目的地地址字段中。
When a node receives a Hello packet where the destination IP address is its local Node-ID as advertised in the IGP-TE topology, the node MUST use its Node-ID in replying to the Hello message. In other words, nodes MUST ensure that the Node-IDs used in RSVP Hello messages are those derived/contained in the IGP-TE topology. Furthermore, a node can only run one Node-ID based RSVP Hello session per IGP instance (i.e., per Node-ID pair) with its neighbor.
当一个节点接收到一个Hello数据包，其中目标IP地址是其在IGP-TE拓扑中公布的本地节点ID时，该节点必须使用其节点ID来回复Hello消息。换句话说，节点必须确保RSVP Hello消息中使用的节点ID是IGP-TE拓扑中派生/包含的ID。此外，节点只能在每个IGP实例（即，每个节点ID对）与其邻居之间运行一个基于节点ID的RSVP Hello会话。
Even in the case of packet switching capable interfaces, when link failure detection is performed by some means other than exchanging RSVP Hello messages, use of Node-ID based Hello sessions is also optimal in detecting signaling adjacency failures for GMPLS-RSVP-TE and RSVP-TE when there is more than one link between a pair of nodes. Similarly, if all interfaces between a pair of nodes are unnumbered, the optimal way to use RSVP to detect signaling adjacency failure is to run Node-ID based Hello sessions. Furthermore, in the case of an optical network with single or multiple numbered or unnumbered control channels, use of Node-ID based Hello messages for detecting signaling adjacency failure is also optimal. Therefore, when link failure detection is performed by some means other than exchanging RSVP Hello messages, or if all interfaces between a pair of nodes are unnumbered, or in a GMPLS network with data and control plane separation, a node MUST run Node-ID based Hello sessions for detection of signaling adjacency failure for RSVP-TE. Nonetheless,
即使在支持分组交换的接口的情况下，当通过交换RSVP Hello消息以外的一些方式执行链路故障检测时，当一对节点之间存在多个链路时，使用基于节点ID的Hello会话在检测GMPLS-RSVP-TE和RSVP-TE的信令邻接故障方面也是最佳的。类似地，如果一对节点之间的所有接口都没有编号，那么使用RSVP检测信令邻接故障的最佳方法是运行基于节点ID的Hello会话。此外，在具有单个或多个编号或未编号控制信道的光网络的情况下，使用基于节点ID的Hello消息来检测信令邻接故障也是最佳的。因此，当通过交换RSVP Hello消息以外的某些方式执行链路故障检测时，或者如果一对节点之间的所有接口都没有编号，或者在具有数据和控制平面分离的GMPLS网络中，节点必须运行基于节点ID的Hello会话，以检测RSVP-TE的信令邻接故障。尽管如此
if it is desirable to distinguish between signaling adjacency and link failures, Node-ID based Hello sessions can co-exist with the exchange of interface bound Hellos messages. Similarly, if a pair of nodes share numbered and unnumbered TE links, Node-ID and interface based Hello sessions can co-exist.
如果需要区分信令邻接和链路故障，则基于节点ID的Hello会话可以与接口绑定Hellos消息的交换共存。类似地，如果一对节点共享编号和未编号的TE链接，则节点ID和基于接口的Hello会话可以共存。
The procedure presented in this document is backward compatible with both [RFC3209] and [RFC3473].
本文件中介绍的程序与[RFC3209]和[RFC3473]向后兼容。
Per [RFC3209], the Hello mechanism is intended for use between immediate neighbors, and Hello messages are by default sent between direct RSVP neighbors. This document does not modify this behavior, as it uses as "local node_id" the IPv4/IPv6 source address of the sending node and as "remote node_id" the IPv4/IPv6 destination address of the neighbor node. TTL/Hop Limit setting and processing are also left unchanged.
根据[RFC3209]，Hello机制用于直接邻居之间，并且Hello消息默认在直接RSVP邻居之间发送。本文档不修改此行为，因为它将发送节点的IPv4/IPv6源地址用作“本地节点id”，并将邻居节点的IPv4/IPv6目标地址用作“远程节点id”。TTL/Hop限制设置和处理也保持不变。
Moreover, this document does not modify the use of Hello Processing for State Recovery as defined in Section 9.3 of [RFC3473] (including definition and processing of the RESTART_CAP object).
此外，本文件不修改[RFC3473]第9.3节（包括重新启动\u CAP对象的定义和处理）中定义的状态恢复Hello处理的使用。
As this document does not modify or extend the RSVP Hello messages exchange between immediate RSVP neighbors, it does not introduce new security considerations.
由于本文档未修改或扩展直接RSVP邻居之间的RSVP Hello消息交换，因此未引入新的安全注意事项。
The security considerations pertaining to the original [RFC3209] remain relevant. RSVP message security is described in [RFC2747] and provides Hello message integrity and authentication of the Node-ID ownership.
与原始[RFC3209]相关的安全注意事项仍然相关。消息的所有权为[RfC27]，消息的完整性在消息的完整性[RfC27]中描述。
We would like to thank Anca Zamfir, Jean-Louis Le Roux, Arthi Ayyangar, and Carol Iturralde for their useful comments and suggestions.
我们要感谢安卡·赞菲尔、让·路易斯·勒鲁克斯、阿尔西·艾扬加和卡罗尔·伊图拉尔德提出了有益的意见和建议。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]Baker，F.，Lindell，B.和M.Talwar，“RSVP加密认证”，RFC 2747，2000年1月。
[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., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]Berger，L.“通用多协议标签交换（GMPLS）信令资源预留协议流量工程（RSVP-TE）扩展”，RFC 3473，2003年1月。
[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[OSPF-TE]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[ISIS-TE]Smit，H.和T.Li，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 37842004年6月。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress.
[BFD]Katz，D.和D.Ward，“双向转发检测”，工作正在进行中。
[IS-ISv6-TE] Harrison, J., et al. "IPv6 Traffic Engineering in IS-IS", Work in Progress, November 2005.
[IS-ISv6-TE]Harrison，J.等人，“IS-IS中的IPv6流量工程”，正在进行的工作，2005年11月。
[OSPFv3-TE] Ishiguro, K., et al. "Traffic Engineering Extensions to OSPF version 3", Work in Progress, April 2006.
[OSPFv3 TE]Ishiguro，K.等人，“OSPF版本3的流量工程扩展”，正在进行的工作，2006年4月。
Authors' Addresses
作者地址
Zafar Ali Cisco Systems Inc. 100 South Main St. #200 Ann Arbor, MI 48104, USA
Zafar Ali Cisco Systems Inc.美国密歇根州安阿伯市南大街100号，邮编：48104
Phone: (734) 276-2459 EMail: zali@cisco.com
电话：（734）276-2459电子邮件：zali@cisco.com
Reshad Rahman Cisco Systems Inc. 2000 Innovation Dr., Kanata, Ontario, K2K 3E8, Canada
Reshad Rahman Cisco Systems Inc.2000创新博士，加拿大安大略省卡纳塔市，K2K 3E8
Phone: (613) 254-3519 EMail: rrahman@cisco.com
电话：（613）254-3519电子邮件：rrahman@cisco.com
Danny Prairie Cisco Systems Inc. 2000 Innovation Dr., Kanata, Ontario, K2K 3E8, Canada
Danny Prairie Cisco Systems Inc.2000创新博士，加拿大安大略省卡纳塔市，K2K 3E8
Phone: (613) 254-3544 EMail: dprairie@cisco.com
电话：（613）254-3544电子邮件：dprairie@cisco.com
Dimitri Papadimitriou Alcatel Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Dimitri Papadimitriou Alcatel Fr.Wellesplein 1，B-2018比利时安特卫普
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。