Network Working Group S. Rao
Request for Comments: 3883 UTA
Updates: 1793 A. Zinin
Category: Standards Track Alcatel
A. Roy
Cisco Systems
October 2004
Detecting Inactive Neighbors over OSPF Demand Circuits (DC)
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 (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF behavior over demand circuits (DC) is optimized in RFC 1793 to minimize the amount of overhead traffic. A part of the OSPF demand circuit extensions is the Hello suppression mechanism. This technique allows a demand circuit to go down when no interesting traffic is going through the link. However, it also introduces a problem, where it becomes impossible to detect an OSPF-inactive neighbor over such a link. This memo introduces a new mechanism called "neighbor probing" to address the above problem.
OSPFは、IPネットワークで使用されるリンクステートドメイン内ルーティングプロトコルです。需要回路（DC）を超えるOSPFの動作は、オーバーヘッドトラフィックの量を最小限にするためにRFC 1793に最適化されています。 OSPFデマンド回路の拡張の一部は、ハロー抑制機構です。この手法には、対象トラフィックがリンクを通過していない場合にダウンする需要回路を可能にします。しかし、それはまた、そのようなリンク上でOSPF-非アクティブな隣人を検出することができなくなる問題を、紹介します。このメモは、上記の問題に対処するために、「探査隣人」と呼ばれる新しいメカニズムを導入しています。
In some situations, when operating over demand circuits, the remote neighbor may be unable to run OSPF [RFC2328], and, as a possible result, unable to route application traffic. Possible scenarios include:
需要回路上で動作するときに、いくつかの状況では、リモート隣人は、可能な結果として、ルートアプリケーショントラフィックにできないOSPF [RFC2328]を実行することができない、とすることができます。考えられるシナリオは次のとおりです。
o The OSPF process might have died on the remote neighbor.
O OSPFプロセスは、リモート隣人に死亡している場合があります。
o Oversubscription (Section 7 of [RFC1793]) may cause a continuous drop of application data at the link level.
Oオーバーサブスクリプション（[RFC1793]のセクション7）はリンクレベルでのアプリケーションデータの連続的な低下を引き起こすことがあります。
The problem here is that the local router cannot identify problems such as this, since the Hello exchange is suppressed on demand circuits. If the topology of the network is such that other routers cannot communicate their knowledge about the remote neighbor via flooding, the local router and all the routers behind it will never know about the problem, so application traffic may continue being forwarded to the OSPF-incapable router.
こんにちは交換がデマンド回線に抑制されているので、ここでの問題は、ローカルルータはこのような問題を特定することができないということです。ネットワークのトポロジーは、他のルータは、洪水を介したリモート隣人についての知識を伝えることができないようなものである場合には、ローカルルータとその背後にあるすべてのルータが問題について知っていることはありませんので、アプリケーショントラフィックはOSPF-不可能に転送され続ける可能性ルータ。
This memo describes a backward-compatible neighbor probing mechanism based on the details of the standard flooding procedure followed by OSPF routers.
このメモはOSPFルータに続いて、標準的な氾濫手順の詳細に基づいて、下位互換性が隣人のプロービングメカニズムを説明しています。
The solution this document proposes uses the link-state update packets to detect whether the OSPF process is operational on the remote neighbor. We call this process "Neighbor probing". The idea behind this technique is to allow either of the two neighbors connected over a demand circuit to test the remote neighbor at any time (see Section 2.1).
この文書は提案しているソリューションは、OSPFプロセスは、リモート近隣に動作可能であるかどうかを検出するために、リンクステートアップデートパケットを使用しています。私たちは、「隣人探査」このプロセスを呼び出します。この技術の背後にある考え方は、（セクション2.1を参照）デマンド回線を介して接続された二つの隣人のいずれかが任意の時点でのリモート隣人をテストできるようにすることです。
The routers across the demand circuit can be connected by either a point-to-point link, a virtual link, or a point-to-multipoint interface. The case of routers connected by broadcast networks or Non-Broadcast Multi-Access (NBMA) links is not considered, since Hello suppression is not used in these cases (Section 3.2 [RFC1793]).
要求回路の両端ルータは、ポイントツーポイントリンク、仮想リンク、またはポイントツーマルチポイントインターフェースのいずれかによって接続することができます。ハロー抑制がこれらの場合に使用されていないため、ブロードキャストネットワークまたは非ブロードキャストマルチアクセス（NBMA）リンクによって接続されたルータの場合は（セクション3.2 [RFC1793]）、考慮されていません。
The neighbor probing mechanism is used as follows. After a router has synchronized the Link State Database (LSDB) with its neighbor over the demand circuit, the demand circuit may be torn down if there is no more application traffic. When application traffic starts going over the link, the link is brought up. If ospfIfDemandNbrProbe is enabled, the routers SHOULD probe each other. While the link is up, the routers may also periodically probe each other every ospfIfDemandNbrProbeInterval. Neighbor probing should not be considered as interesting traffic and should not cause the demand circuit to remain up (relevant details of implementation are outside of the scope of this document).
次のように隣人プロービングのメカニズムが使用されています。ルータは需要回路を介してそのネイバーとリンクステートデータベース（LSDB）を同期した後は、それ以上のアプリケーション・トラフィックがない場合、デマンド回線が切断することができます。アプリケーショントラフィックがリンクの上に行くを開始すると、リンクが育っています。 ospfIfDemandNbrProbeが有効になっている場合、ルータはお互いを探るべきです。リンクがアップしている間、ルータは、定期的にすべてのospfIfDemandNbrProbeIntervalお互いを調べることがあります。プロービングの近隣には、対象トラフィックと考えるべきではないと（実装の関連する詳細は、この文書の範囲外である）までのままに需要回路が発生することはありません。
The case when one or more of the router's links are oversubscribed (see section 7 of [RFC1793]) should be considered by the implementations. In such a situation, even if the link status is up and application data is being sent on the link, only a limited number of neighbors are really reachable. To make sure temporarily unreachable neighbors are not mistakenly declared down, Neighbor probing should be restricted to those neighbors that are actually reachable (i.e., there is a circuit established with the neighbor at the moment the probing procedure needs to be initiated). This check itself is also considered an implementation detail.
ルータのリンクの一つ以上をオーバーサブスクライブされている場合は（[RFC1793]のセクション7を参照）を実装することによって考慮されるべきです。このような状況では、リンクステータスがアップしていると、アプリケーションデータがリンク上で送信されている場合でも、隣人の限られた数は、実際に到達可能です。一時的に到達不能隣人が誤ってダウンと宣言されていないことを確認するには、近隣のプロービングは（すなわち、プロービング手順の時点で隣で確立回路がある開始する必要があります）実際に到達可能であるそれらの隣人に制限する必要があります。この検査自体も、実装の詳細とみなされます。
The neighbor probing method described in this section is completely compatible with standard OSPF implementations, because it is based on standard behavior that must be followed by OSPF implementations in order to keep their LSDBs synchronized.
それは同期それらLSDBsを維持するために、OSPF実装が続かなければならない標準の動作に基づいているため、このセクションで説明ネイバープロービング方法は、標準的なOSPF実装と完全に互換性があります。
When a router needs to verify the OSPF capability of a neighbor reachable through a demand circuit, it should flood to the neighbor any LSA in its LSDB that would normally be sent to the neighbor during the initial LSDB synchronization process (in most cases, such an LSA must have already been flooded to the neighbor by the time the probing procedure starts). For example, the router may flood its own router-LSA (without originating a new version), or the neighbor's own router-LSA. If the neighbor is still alive and OSPF-capable, it replies with a link state acknowledgement or a link state update (an implied acknowledgement), and the LSA is removed from the neighbor's retransmission list. The implementations should limit the number of times an LSA can be retransmitted to ospfIfDemandNbrProbeRetxLimit, when used for neighbor probing. If no acknowledgement (explicit or implicit) is received for a predefined period of time, the probing router should treat this as evidence of the neighbor's unreachability (proving wrong the assumption of reachability used in [RFC1793]) and should bring the adjacency down.
ルータは需要回路を介して到達可能なネイバーのOSPF機能を検証する必要がある場合、それは、ほとんどの場合（隣人に、このような通常の初期LSDB同期プロセス中にネイバーに送信されるそのLSDB内のすべてのLSAをあふれさせる必要がありますLSAは、既にプロービング手順が開始される時間）によってネイバーに殺到している必要があります。たとえば、ルータが（新しいバージョンを起点せず）は、独自のルータLSAをあふれさせること、または隣人の自身のルータLSA。ネイバーがまだ生きているとOSPF-可能であるならば、それはリンク状態確認やリンク状態更新（暗黙の確認応答）で応答し、そしてLSAは隣人の再送リストから削除されます。実装は、隣接プローブに使用する場合LSAは、ospfIfDemandNbrProbeRetxLimitに再送信することができる回数を制限すべきです。 （明示的または暗黙の）肯定応答が所定の期間のために受信されない場合、プロービングルータは（間違った[RFC1793]で使用される到達可能性の仮定を証明する）隣人の到達不能の証拠としてこれを扱うべきであると隣接関係をダウンさせる必要があります。
Note that when the neighbor being probed receives such a link state update packet, the received LSA has the same contents as the LSA in the neighbor's LSDB, and hence should normally not cause any additional flooding. However, since LSA refreshes are not flooded over demand circuits, the received LSA may have a higher Sequence Number. This will result in the first probe LSA being flooded further by the neighbor. Note that if the current version of the probe LSA has already been flooded to the neighbor, it will not be propagated any further by the neighbor. Also note that in any case, subsequent (non-first) probe LSAs will not cause further flooding until the LSA's sequence number is incremented.
通常、任意の追加の洪水が発生することはありませんので、プローブさ隣人が、このようなリンク状態更新パケットを受信すると、受信LSAは隣人のLSDBでLSAと同じ内容を持っていることに注意してください、と。 LSAのリフレッシュがデマンド回線を超える浸水していないので、受信したLSAは、より高いシーケンス番号を有することができます。これは隣人によってさらに殺到している第一プローブLSAになります。プローブLSAの現在のバージョンが既に隣人にフラッディングされている場合、それは隣人でそれ以上伝播されないことに注意してください。また、LSAのシーケンス番号がインクリメントされるまで、どのような場合には、それに続く（非最初の）プローブのLSAはさらに洪水を起こさないことに注意してください。
Again, the implementation should insure (through internal mechanisms) that OSPF link state update packets sent over the demand circuit for the purpose of neighbor probing do not prevent that circuit from being torn down.
再び、実装は、プロービング隣人のために要求回路を介して送信されるOSPFリンク状態更新パケットは解体されることから、その回路を妨げないこと（内部機構を介して）を保証すべきです。
Virtual links can be treated analogously to point-to-point links, so the techniques described in this memo are applicable to virtual links as well. The case of point-to-multipoint interface running as a demand circuit (section 3.5 [RFC1793]) can be treated as individual point-to-point links, for which the solution has been described in section 2.
仮想リンクは、ポイントツーポイントリンクと同様に処理することができるので、このメモに記載された技術は、同様に仮想リンクにも適用可能です。需要回路（セクション3.5 [RFC1793]）として実行されているポイントツーマルチポイントインターフェイスの場合は、溶液は、セクション2に記載された個々のポイントツーポイントリンクとして扱うことができます。
All mechanisms described in this document are backward-compatible with standard OSPF implementations.
この文書に記載されているすべての機構は、標準的なOSPFの実装との下位互換性があります。
In addition to the lost functionality mentioned in Section 6 of [RFC1793], there is additional overhead in terms of the amount of data (link state updates and acknowledgements) being transmitted due to neighbor probing whenever the link is up, thereby increasing the overall cost.
[RFC1793]のセクション6に記載された失われた機能に加えて、追加のオーバーヘッドは、データの量である（リンク状態の更新及び確認応答）、それによって全体的なコストを増加させること、リンクがアップしているときはいつでもプロービングによるネイバーに送信されます。
The original idea of limiting the number of LSA retransmissions on demand circuits (used as part of the solution described in this document) and its implementation belong to Padma Pillay-Esnault and Derek Yeung.
需要（この文書に記載された溶液の一部として使用される）回路およびその実装にLSA再送信の数を制限するのオリジナルのアイデアは、パドマPillay-Esnaultとデレクヨンに属します。
The authors would like to thank John Moy, Vijayapal Reddy Patil, SVR Anand, and Peter Psenak for their comments on this work.
作者はこの作品で彼らのコメントのためにジョン・モイ、Vijayapalレディパティル、SVRアナンド、そしてピーターPsenakに感謝したいと思います。
A significant portion of Sira's work was carried out as part of the HFCL-IISc Research Project (HIRP), Bangalore, India. He would like to thank the team for their insightful discussions.
Sira社の仕事の重要な部分は、HFCL、IISc研究プロジェクト（HIRP）、バンガロール、インドの一環として行われました。彼は、彼らの洞察に満ちた議論のためのチームに感謝したいと思います。
The mechanism described in this document does not modify security aspects of the OSPF routing protocol.
本書で説明されたメカニズムは、OSPFルーティングプロトコルのセキュリティの側面を変更しません。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[RFC1793]モイ、J.、 "オンデマンド・サーキットをサポートするためのOSPFの拡張"、RFC 1793、1995年4月。
Appendix A. Configurable Parameters
付録A.設定可能なパラメータ
This memo defines the following additional configuration parameters for OSPF interfaces.
このメモはOSPFインターフェイスの以下の追加の設定パラメータを定義します。
ospfIfDemandNbrProbe Indicates whether or not neighbor probing is enabled to determine whether the neighbor is inactive. Neighbor probing is disabled by default.
ospfIfDemandNbrProbeは隣人のプロービングが隣人が非アクティブであるかどうかを判断するために有効になっているかどうかを示します。プロービングの近隣には、デフォルトでは無効になっています。
ospfIfDemandNbrProbeRetxLimit The number of consecutive LSA retransmissions before the neighbor is deemed inactive and the neighbor adjacency is brought down. Sample value is 10 consecutive LSA retransmissions.
ネイバーがアクティブでないとみなされ、ネイバー隣接関係が倒される前に、連続したLSAの再送回数をospfIfDemandNbrProbeRetxLimit。サンプル値は、10回の連続したLSA再送信です。
ospfIfDemandNbrProbeInterval Defines how often the neighbor will be probed. The sample value is 2 minutes.
ospfIfDemandNbrProbeIntervalは隣人がプローブされる頻度を定義します。サンプル値は2分です。
Authors' Addresses
著者のアドレス
Sira Panduranga Rao The University of Texas at Arlington 416 Yates Street, 300 Nedderman Hall Arlington, TX 76019
アーリントンのテキサスSIRA Pandurangaラオ東京大学416イエーツストリート、300 Neddermanホールアーリントン、TX 76019
EMail: siraprao@hotmail.com
メールアドレス：siraprao@hotmail.com
Alex Zinin Alcatel 701 E Middlefield Rd Mountain View, CA 94043
アレックスジニンアルカテル701 EミドルRdのマウンテンビュー、CA 94043
EMail: zinin@psg.com
メールアドレス：zinin@psg.com
Abhay Roy Cisco Systems 170 W. Tasman Dr. San Jose,CA 95134
アブヘイロイシスコシステムズ170 W.タスマン博士はカリフォルニア州サンノゼ95134
EMail: akr@cisco.com
メールアドレス：akr@cisco.com
Full Copyright Statement
完全な著作権声明
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/S HE 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.
この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。
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.
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。