[要約] 要約：RFC 3883は、OSPF Demand Circuits（DC）上の非アクティブな隣接ノードを検出するための手法を提案しています。 目的：このRFCの目的は、OSPF DC上の非アクティブな隣接ノードを効果的に検出し、ネットワークのパフォーマンスと信頼性を向上させることです。
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)
OSPF需要回路（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）The Internet Society（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.
ここでの問題は、Hello Exchangeがオンデマンドサーキットを抑制されるため、ローカルルーターがこのような問題を特定できないことです。ネットワークのトポロジが、他のルーターが洪水を介してリモートネイバーに関する知識を伝えることができない場合、地元のルーターとその背後のすべてのルーターは問題について決して知りません。ルーター。
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人の隣人のいずれかがいつでもリモートネイバーをテストできるようにすることです（セクション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.
ルーターのリンクの1つ以上がオーバーサブスクライブされている場合（[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.
このセクションで説明した隣接プロービング方法は、標準のOSPF実装と完全に互換性があります。これは、LSDBを同期させるために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の再送信数を需要回路（このドキュメントで説明したソリューションの一部として使用）を制限するという当初のアイデアとその実装は、Padma Pillay-EsnaultとDerek Yeungに属します。
The authors would like to thank John Moy, Vijayapal Reddy Patil, SVR Anand, and Peter Psenak for their comments on this work.
著者は、この作品に関するコメントについて、ジョン・モイ、ヴィジャヤパル・レディ・パティル、SVRアナンド、ピーター・ペシナックに感謝したいと思います。
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.
シラの研究のかなりの部分が、インドのバンガロールにある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] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[RFC1793] Moy、J。、「需要回路をサポートするためにOSPFを拡張」、RFC 1793、1995年4月。
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.
OSPFIFDEMANDNBRPROBERETXLIMIT隣人が非アクティブであると見なされ、隣人の隣接が倒される前の連続したLSA再送信の数。サンプル値は、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
シラパンドゥランガラオテキサス大学アーリントン416イェーツストリート、300ネダーマンホールアーリントン、テキサス76019
EMail: siraprao@hotmail.com
Alex Zinin Alcatel 701 E Middlefield Rd Mountain View, CA 94043
アレックス・ジニン・アルカテル701 E Middlefield Rd Mountain View、CA 94043
EMail: zinin@psg.com
Abhay Roy Cisco Systems 170 W. Tasman Dr. San Jose,CA 95134
Abhay Roy Cisco Systems 170 W. Tasman Dr. San Jose、CA 95134
EMail: akr@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織（もしあれば）が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。