RFC3883 日本語訳
3883 Detecting Inactive Neighbors over OSPF Demand Circuits (DC). S.Rao, A. Zinin, A. Roy. October 2004. (Format: TXT=13100 bytes) (Updates RFC1793) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Rao
Request for Comments: 3883 UTA
Updates: 1793 A. Zinin
Category: Standards Track Alcatel
A. Roy
Cisco Systems
October 2004
コメントを求めるワーキンググループS.ラオの要求をネットワークでつないでください: 3883のUTAアップデート: 1793年のA.ジニンカテゴリ: 標準化過程アルカテルA.ロイシスコシステムズ2004年10月
Detecting Inactive Neighbors over OSPF Demand Circuits (DC)
OSPF要求サーキットの上に不活発なネイバーズを検出します。(DC)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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の振舞いは、オーバーヘッド・トラヒックの量を最小にするためにRFC1793で最適化されます。 OSPF要求サーキット拡張子の一部がHello抑圧メカニズムです。 どんなおもしろい交通もリンクを通らないことであるとき、このテクニックは要求サーキットが落ちます。 しかしながら、また、それは問題を紹介します。そこでは、そのようなリンクの上にOSPF不活発な隣人を検出するのが不可能になります。 このメモはその上の問題を訴えるために「隣人の調べ」と呼ばれる新しいメカニズムを紹介します。
1. Motivation
1. 動機
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)はリンク・レベルでアプリケーションデータの連続した低下を引き起こすかもしれません。
Rao, et al. Standards Track [Page 1] RFC 3883 OSPF DC Inactive Neighbor Detection October 2004
ラオ、他 隣人検出2004年10月に不活発な標準化過程[1ページ]RFC3883OSPF DC
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交換が要求サーキットの上に抑圧されるので。 それの後ろのローカルルータとすべてのルータがネットワークのトポロジーが他のルータが氾濫を通してリモート隣人に関するそれらの知識を伝えることができないようにものであるなら、問題に関して決して知るというわけではないので、アプリケーション交通は、OSPF不可能なルータに送られ続けるかもしれません。
This memo describes a backward-compatible neighbor probing mechanism based on the details of the standard flooding procedure followed by OSPF routers.
このメモはOSPFルータがあとに続いた標準の氾濫手順の詳細に基づく後方コンパチブル隣人調べメカニズムについて説明します。
2. Proposed Solution
2. 提案されたソリューション
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]).
ポイントツーポイント接続、仮想のリンクかポイントツーマルチポイントインタフェースのどちらかは要求サーキット中のルータを接続できます。 放送網かNon-放送Multi-アクセス(NBMA)リンクによって接続されたルータに関するケースは考えられません、Hello抑圧がこれらの場合(セクション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).
隣人調べメカニズムは以下の通り使用されます。 ルータがLink州Database(LSDB)を要求サーキットの上の隣人に連動させた後に、それ以上のアプリケーション交通が全くなければ、要求サーキットを取りこわすかもしれません。 アプリケーション交通がリンクを調べ始めるとき、リンクは持って来られます。 ospfIfDemandNbrProbeが有効にされるなら、ルータSHOULDは互いを調べます。 リンクは上がっていますが、ルータは上がるかもしれません、また、定期的に互いを調べてください。あらゆる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
ルータのリンクの1つか以上が申込みが超過しているとき([RFC1793]のセクション7を見てください)、ケースは実現で考えられるべきです。 そのような状況で、リンク状態が上がってい、アプリケーションデータをリンクに送っても、限られた数の隣人だけが本当に届いています。 念のため一時手の届かない隣人は下がっていると誤って宣言されないで、Neighborの調べは実際にそうであるそれらの隣人に制限されるべきです。
Rao, et al. Standards Track [Page 2] RFC 3883 OSPF DC Inactive Neighbor Detection October 2004
ラオ、他 隣人検出2004年10月に不活発な標準化過程[2ページ]RFC3883OSPF DC
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.
届きます(すなわち、調べ手順が開始されるために必要とする瞬間に隣人と共に確立されたサーキットがあります)。 また、このチェック自体は実現の詳細であると考えられます。
2.1. Neighbor Probing
2.1. 隣人の調べ
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実現と完全に互換性があります、OSPF実現がそれらのLSDBsを連動させ続けるためにあとに続かなければならない標準の振舞いに基づいているので。
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は隣人の「再-トランスミッション」リストから取り外されます。 実現は隣人の調べに使用されるとospfIfDemandNbrProbeRetxLimitにLSAを再送できるという回の数を制限するべきです。 事前に定義された期間の間、承認(明白であるか暗黙の)を全く受けないなら、調べルータは、隣人の「非-可到達性」(間違っていると可到達性の仮定が[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には、より高いSequence Numberがあるかもしれないという要求の上にあふれません。 これは、より遠くに隣人で水につかっている最初の徹底的調査LSAをもたらすでしょう。 徹底的調査LSAの最新版が既に隣人へあふれたなら、それが隣人によってこれ以上伝播されないことに注意してください。 また、どのような場合でも、その後(非最初に)の徹底的調査LSAsが一層の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リンク州のアップデートパケットが、そのサーキットが取りこわされるのを防がないのを保障するべきです(内部のメカニズムを通して)。
Rao, et al. Standards Track [Page 3] RFC 3883 OSPF DC Inactive Neighbor Detection October 2004
ラオ、他 隣人検出2004年10月に不活発な標準化過程[3ページ]RFC3883OSPF DC
3. Support of Virtual Links and Point-to-multipoint Interfaces
3. 仮想のリンクとポイントツーマルチポイントインタフェースのサポート
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で説明されます)。
4. Compatibility Issues
4. 互換性の問題
All mechanisms described in this document are backward-compatible with standard OSPF implementations.
本書では説明されたすべてのメカニズムは標準のOSPF実現と互換性があります後方の。
5. Deployment Considerations
5. 展開問題
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で言及された無くなっている機能性に加えて、リンクが上がっているときはいつも、隣人の調べのため伝えられるデータ量に関する追加オーバーヘッド(リンク州のアップデートと承認)があります、その結果、全費用を上げます。
6. Acknowledgements
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 retransmissionsのオンデマンドのサーキット(解決策の一部が本書では説明したように、使用される)の数を制限するという着想とその実現はPadma Pillay-EsnaultとデリックYeungに属します。
The authors would like to thank John Moy, Vijayapal Reddy Patil, SVR Anand, and Peter Psenak for their comments on this work.
作者はこの仕事の彼らのコメントについてジョンMoy、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.
シーラ川の仕事の重要な部分がHFCL-IISc Research Project(HIRP)、バンガロール(インド)の一部として行われました。 彼は彼らの洞察に満ちた議論についてチームに感謝したがっています。
7. Security Considerations
7. セキュリティ問題
The mechanism described in this document does not modify security aspects of the OSPF routing protocol.
本書では説明されたメカニズムはOSPFルーティング・プロトコルのセキュリティ局面を変更しません。
8. Normative References
8. 引用規格
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC
1793, April 1995.
[RFC1793] Moy、J.、「要求サーキットを支えるためにOSPFを広げています」、RFC1793、1995年4月。
Rao, et al. Standards Track [Page 4] RFC 3883 OSPF DC Inactive Neighbor Detection October 2004
ラオ、他 隣人検出2004年10月に不活発な標準化過程[4ページ]RFC3883OSPF DC
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 Indicates、隣人の調べが、隣人が不活発であるかどうか決定するのが可能にされるのであるかどうか 隣人の調べはデフォルトで無能にされます。
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 retransmissionsの数はダウンします。 標本値は10連続したLSA retransmissionsです。
ospfIfDemandNbrProbeInterval
Defines how often the neighbor will be probed. The sample
value is 2 minutes.
しばしば、隣人が調べられるospfIfDemandNbrProbeInterval Defines。 標本値は2分です。
Authors' Addresses
作者のアドレス
Sira Panduranga Rao The University of Texas at Arlington 416 Yates Street, 300 Nedderman Hall Arlington, TX 76019
アーリントン416イェイツ通り、300Nedderman Hallアーリントン、テキサス 76019のシーラ川Pandurangaラオテキサス大
EMail: siraprao@hotmail.com
メール: siraprao@hotmail.com
Alex Zinin Alcatel 701 E Middlefield Rd Mountain View, CA 94043
アレックスジニンアルカテル701E Middlefield第マウンテンビュー、カリフォルニア 94043
EMail: zinin@psg.com
メール: zinin@psg.com
Abhay Roy Cisco Systems 170 W. Tasman Dr. San Jose,CA 95134
サンノゼ、Abhayロイシスコシステムズ170w.タスマン博士カリフォルニア 95134
EMail: akr@cisco.com
メール: akr@cisco.com
Rao, et al. Standards Track [Page 5] RFC 3883 OSPF DC Inactive Neighbor Detection October 2004
ラオ、他 隣人検出2004年10月に不活発な標準化過程[5ページ]RFC3883OSPF DC
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
彼が代理をするか、または(もしあれば)後援される/S、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄して、急行か暗示していて、含んでいる他はあらゆる保証です。「そのままで」という基礎と貢献者の上でこのドキュメントとここに含まれた情報を提供して、組織が彼である、情報の使用はここにどんな権利か市場性のどんな黙示的な保証か特定目的への適合性も侵害しないでしょう。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Rao, et al. Standards Track [Page 6]
ラオ、他 標準化過程[6ページ]
一覧
スポンサーリンク
