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
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.
ノードIDベースのリソース予約プロトコル（RSVP）を使用するハローメッセージは、TEリンクが無番号である場合、データおよび制御プレーンは、分離されている場合、例えば、多くの場合暗示されます。リンクレベルの障害検出はハローRSVPメッセージを交換する以外の何らかの手段によって実行されたときに更に、ノードIDハローベースのセッションを使用することは、リソース予約プロトコル - トラフィックエンジニアリング（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.
RSVP Helloメッセージ交換は、[RFC3209]で紹介されました。 RSVPハローの使用は、RSVPグレースフルリスタート（GR）の手順をサポートするために、[RFC3473]に拡張されています。
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]は汎用MPLS（GMPLS）のためのGR手順についてRSVP Helloメッセージの使用を指定します。 GMPLSは、コントロールプレーンとデータプレーンの分離の概念を導入しています。換言すれば、GMPLSネットワークにおいて、制御プレーン情報は、そのエンドポイントのIP可能であり、それは物理的または論理的に互いに素それが制御するデータベアラ・リンクからのものであってもよい。制御ネットワークを介して搬送されます制御チャネルからのデータベアラリンクの分離の結果の一つは、RSVP Helloメッセージは（の一部）は、これらの番号が付けられている場合でも、リンクインターフェースベアラデータで終端されていないということです。代わりに、RSVP helloメッセージは、制御チャネル（IP対応）エンドポイントで終端されています。後者は、これらの制御チャネルをホスティングするノード、すなわち、ノードIDに割り当てられた値によって識別することができます。その結果、GRアプリケーションのためのRSVP Helloメッセージの使用は、Node-IDこんにちはベースのセッションの動作と使用方法を明確にする必要性を紹介します。
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ハローベースのセッションの使用はまた、隣接障害シグナリングの検出のために最適ですGMPLS-RSVP-TEおよびRSVP-TEのためにノードの対の間の複数のリンクが存在する場合。隣接ノード間のすべてのTEリンクが無番号である場合も同様に、そのノードが隣接障害シグナルの検出のためのノードIDベースのHelloメッセージを交換することが暗示されます。この文書は、すべてまたはTEリンクのサブセットが番号付けされていないノードIDこんにちはベースのメッセージ交換の使用を明確にしています。
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：TEルータID ISIS [ISIS-TE]のためのOSPF [OSPF-TE]およびトラフィックエンジニアリングルータID TLVのためのルータアドレスTLVでアドバタイズとして。 IPv6の場合、ノードIDはOSPFv3のためRouter_IPv6_Address [OSPFv3の-TE]およびIS-ISのIPv6 TE ROUTER_ID [IS-ISv6-TE]を指します。
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ハローセッションベースのローカルおよびリモートノード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パケットの送信元と送信先の分野で使用されているこんにちはセッション：インタフェースこんにちはセッションを有界。
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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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.
ノードIDベースのハローセッションは、ローカルおよびリモートノードIDがそれぞれのHelloパケットの送信元と宛先の分野で使用されるようにRSVP Helloメッセージの交換を介して確立されます。 OSPF [OSPF-TE]およびISIS [ISIS-TE]のためのトラフィックエンジニアリングルータID TLVのためのルータアドレスTLVで定義され、ここで、IPv4で、ノードIDは、TEルータIDを指します。 IPv6の場合、ノードIDはOSPFv3のためRouter_IPv6_Address [OSPFv3の-TE]およびIS-ISのIPv6 TE ROUTER_ID [IS-ISv6-TE]を指します。このセクションでは、ノード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メッセージを送信します。さらに、ノードは、IPパケットの宛先アドレスフィールドに、近隣のノードIDを置きます。
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.
宛先IPアドレスがローカルノードID IGP-TEトポロジでアドバタイズされるようであるノードは、Helloパケットを受信すると、ノードは、Helloメッセージに返信で、そのノードIDを使用しなければなりません。言い換えれば、ノードは、RSVP Helloメッセージに使用されるノードIDは、これら/派生IGP-TEトポロジーに含まれていることを確認しなければなりません。さらに、ノードは、その隣接有する（すなわち、ノードIDのペアごと）IGPインスタンスごとに1つのNode-IDベースのRSVPハローセッションを実行することができます。
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, 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.
リンク障害検出がハローRSVPメッセージを交換する以外の何らかの手段によって実行される場合でも可能なインターフェイスをパケット交換の場合には、ノードIDハローベースのセッションを使用することは、GMPLS-RSVP-TEおよびRSVPのためのシグナリング隣接障害を検出するのにも最適ですノードの対の間の複数のリンクが存在する場合-Te。ノードの対の間のすべてのインタフェースが番号付けされていない場合も同様に、隣接故障シグナリング検出するために、RSVPを使用するための最適な方法は、ノードIDベースのハローセッションを実行することです。また、単一または複数の番号または番号なしの制御チャネルを有する光ネットワークの場合には、シグナリング隣接故障を検出するためのノードIDハローベースのメッセージの使用も最適です。したがって、リンク障害検出がハローRSVPメッセージを交換する以外の何らかの手段によって行わ、またはノードの対の間のすべてのインタフェースが無数であるか、またはデータおよび制御プレーンの分離とGMPLSネットワークにおいて、ノードは、ノードIDベースを実行する必要がある場合れたときこんにちは、RSVP-TEの隣接故障を知らせるの検出のためのセッション。それは、シグナリングの隣接関係とリンク障害を区別することが望ましいノードIDベースのHelloセッションあればそれにもかかわらず、ハローズメッセージをバインドされたインターフェースのやり取りと共存することができます。ノードのペアが番号と無数のTEリンク、ノードIDと共有する場合も同様に、インターフェースベースのハローセッションが共存することができます。
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メッセージは、直接RSVP隣人の間で送信されるデフォルトです。それは「ローカルNODE_ID」送信ノードののIPv4 / IPv6送信元アドレスとして使用し、「リモートNODE_ID」隣接ノードののIPv4 / IPv6宛先アドレスとして、この文書では、この動作を変更しません。 TTL /ホップ制限の設定や処理も変更されません。
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で定義されるようにまた、この文書は、（RESTART_CAPオブジェクトの定義および処理を含む）状態回復のためのハロー処理の使用を変更しません。
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]に関連するセキュリティ上の考慮事項は、関連残ります。 RSVPメッセージのセキュリティは、[RFC2747]に記載され、Helloメッセージの完全性及びノードIDの所有権の認証を提供しています。
We would like to thank Anca Zamfir, Jean-Louis Le Roux, Arthi Ayyangar, and Carol Iturralde for their useful comments and suggestions.
私たちは、彼らの役に立つコメントと提案のためANCA Zamfir、ジャン=ルイ・ル・ルー、Arthi Ayyangar、およびキャロルIturraldeに感謝したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベーカー、F.、リンデル、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、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]カッツ、D.、Kompella、K.、およびD.ヨン、 "トラフィックエンジニアリング（TE）OSPFバージョン2への拡張"、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]スミット、H.、およびT.李、 "トラフィックエンジニアリングのための中間システム（ISIS）拡張機能（TE）への中間システム"、RFC 3784、2004年6月。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress.
[BFD]カッツ、D.およびD.区、「双方向フォワーディング検出」、進行中の作業。
[IS-ISv6-TE] Harrison, J., et al. "IPv6 Traffic Engineering in IS-IS", Work in Progress, November 2005.
[IS-ISv6-TE]ハリソン、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]石黒、K.、ら。 「OSPFバージョン3へのトラフィックエンジニアリングの拡張」、進歩、2006年4月に作業。
Authors' Addresses
著者のアドレス
Zafar Ali Cisco Systems Inc. 100 South Main St. #200 Ann Arbor, MI 48104, USA
Zafarアリシスコシステムズ株式会社100南メインストリート＃200アナーバー、MI 48104、USA
Phone: (734) 276-2459 EMail: zali@cisco.com
電話：（734）276-2459 Eメール：zali@cisco.com
Reshad Rahman Cisco Systems Inc. 2000 Innovation Dr., Kanata, Ontario, K2K 3E8, Canada
Reshadラーマンシスコシステムズ株式会社2000年イノベーション博士は、カナタ、オンタリオ、K2K 3E8、カナダ
Phone: (613) 254-3519 EMail: rrahman@cisco.com
電話：（613）254-3519 Eメール：rrahman@cisco.com
Danny Prairie Cisco Systems Inc. 2000 Innovation Dr., Kanata, Ontario, K2K 3E8, Canada
ダニー・プレーリーシスコシステムズ株式会社2000年イノベーション博士は、カナタ、オンタリオ、K2K 3E8、カナダ
Phone: (613) 254-3544 EMail: dprairie@cisco.com
電話：（613）254-3544 Eメール：dprairie@cisco.com
Dimitri Papadimitriou Alcatel Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
ディミトリPapadimitriouアルカテルブロック。 B-2018アントワープ、Velgiom Vellesplein 1
Phone: +32 3 240-8491 EMail: dimitri.papadimitriou@alcatel.be
電話：+32 3 240-8491 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。