RFC3277 日本語訳

3277 Intermediate System to Intermediate System (IS-IS) TransientBlackhole Avoidance. D. McPherson. April 2002. (Format: TXT=13077 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                       D. McPherson
Request for Comments: 3277                                           TCB
Category: Informational                                       April 2002

コメントを求めるワーキンググループD.マクファーソン要求をネットワークでつないでください: 3277年のTCBカテゴリ: 情報の2002年4月

           Intermediate System to Intermediate System (IS-IS)
                     Transient Blackhole Avoidance

中間システムへの中間システム、(-、)、一時的なBlackhole回避

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

Abstract

要約

   This document describes a simple, interoperable mechanism that can be
   employed in Intermediate System to Intermediate System (IS-IS)
   networks in order to decrease the data loss associated with
   deterministic blackholing of packets during transient network
   conditions.  The mechanism proposed here requires no IS-IS protocol
   changes and is completely interoperable with the existing IS-IS
   specification.

このドキュメントがIntermediate SystemでIntermediate Systemに使うことができる簡単で、共同利用できるメカニズムについて説明する、(-、)、一時的なネットワーク状態の間、パケットの決定論的なblackholingに関連しているデータの損失を減少させるために、ネットワークでつなぎます。 ここで提案されたメカニズムが、いいえが必要である、-、プロトコルが変えて、完全に共同利用できる、存在、-、仕様

1. Introduction

1. 序論

   When an IS-IS router that was previously a transit router becomes
   unavailable as a result of some transient condition such as a reboot,
   other routers within the routing domain must select an alternative
   path to reach destinations which have previously transited the failed
   router.  Presumably, the newly selected router(s) comprising the path
   have been available for some time and, as a result, have complete
   forwarding information bases (FIBs) which contain a full set of
   reachability information for both internal and external (e.g., BGP)
   destination networks.

いつ、-、以前にトランジットルータがリブートなどの何らかの一時的な状態の結果、入手できなくなるということであったルータ、経路ドメインの中の他のルータは以前に失敗したルータを通過した目的地に達するように迂回経路を選択しなければならないか。 おそらく、経路を包括する新たに選択されたルータは、しばらく利用可能であり、その結果内部の、そして、外部(例えば、BGP)の両方の送信先ネットワークのための可到達性情報のフルセットを含む完全な推進情報ベース(FIBs)を持っています。

   When the previously failed router becomes available again, it is only
   seconds before the paths that had previously transited the router are
   again selected as the optimal path by the IGP.  As a result,
   forwarding tables are updated and packets are once again forwarded
   along the path.  Unfortunately, external destination reachability
   information (e.g., learned via BGP) is not yet available to the
   router, and as a result, packets bound for destinations not learned
   via the IGP are unnecessarily discarded.

以前に失敗したルータが再び利用可能になるとき、以前にルータを通過した経路が再び最適経路としてIGPによって選定される前に秒にすぎません。 その結果、推進テーブルをアップデートします、そして、経路に沿ってもう一度パケットを進めます。 残念ながら、外部の目的地可到達性情報(例えば、BGPを通して、学習される)はまだルータに利用可能ではありません、そして、その結果、IGPを通して学習されなかった目的地に向かっているパケットは不必要に捨てられます。

McPherson                    Informational                      [Page 1]

RFC 3277          IS-IS Transient Blackhole Avoidance         April 2002

マクファーソン情報[1ページ]のRFC3277、-、一時的なBlackhole回避2002年4月

   A simple interoperable mechanism to alleviate the offshoot associated
   with this deterministic behavior is discussed below.

以下でこの決定論的な振舞いに関連している分枝を軽減するのが簡単である共同利用できるメカニズムについて議論します。

2. Discussion

2. 議論

   This document describes a simple, interoperable mechanism that can be
   employed in IS-IS [1, 2] networks in order to avoid transition to a
   newly available path until other associated routing protocols such as
   BGP have had sufficient time to converge.

このドキュメントがそれを使うことができる簡単で、共同利用できるメカニズムについて説明する、-、[1、2] BGPなどの他の関連ルーティング・プロトコルが一点に集まることができるくらいの時間を過すまで新たに利用可能な経路への変遷を避けるために、ネットワークでつなぎます。

   The benefits of such a mechanism can be realized when considering the
   following scenario depicted in Figure 1.

図1に表現された以下のシナリオを考えるとき、そのようなメカニズムの利益を実現できます。

                                 D.1
                                  |
                              +-------+
                              | RtrD  |
                              +-------+
                              /      \
                             /        \
                        +-------+    +-------+
                        | RtrB  |    | RtrC  |
                        +-------+    +-------+
                             \        /
                              \      /
                              +-------+
                              | RtrA  |
                              +-------+
                                   |
                                  S.1

D.1| +-------+ | RtrD| +-------+ / \ / \ +-------+ +-------+ | RtrB| | RtrC| +-------+ +-------+ \ / \ / +-------+ | RtrA| +-------+ | S.1

                 Figure 1: Example Network Topology

図1: 例のネットワーク形態

   Host S.1 is transmitting data to destination D.1 via a primary path
   of RtrA->RtrB->RtrD.  Routers A, B and C learn of reachability to
   destination D.1 via BGP from RtrD.  RtrA's primary path to D.1 is
   selected because when calculating the path to BGP NEXT_HOP of RtrD,
   the sum of the IS-IS link metrics on the RtrA-RtrB-RtrD path is less
   than the sum of the metrics of the RtrA-RtrC-RtrD path.

RtrA->の第一の経路を通して目的地D.1にデータを送るのは、RtrB->です。S.1を接待してください、RtrD。 ルータA、B、およびCはRtrDからのBGPを通して目的地D.1に可到達性を知っています。 D.1へのRtrAの第一の経路が選択される、RtrDのBGP NEXT_HOPに経路について合計で計算する、-、測定基準をリンクしてください、RtrA-RtrB-RtrD経路に、RtrA-RtrC-RtrD経路の測定基準の合計以下があります。

   Assume RtrB becomes unavailable and as a result the RtrC path to RtrD
   is used.  Once RtrA's FIB is updated and it begins forwarding packets
   to RtrC, everything should behave properly as RtrC has existing
   forwarding information regarding destination D.1's availability via
   BGP NEXT_HOP RtrD.

RtrBが入手できなくなって、その結果、RtrDへのRtrC経路が使用されていると仮定してください。 いったんRtrAのFIBをアップデートして、パケットをRtrCに送り始めると、RtrCがBGP NEXT_HOP RtrDを通して目的地D.1の有用性に関して情報を転送する存在を持っているとき、すべてが礼儀正しく振る舞うべきです。

McPherson                    Informational                      [Page 2]

RFC 3277          IS-IS Transient Blackhole Avoidance         April 2002

マクファーソン情報[2ページ]のRFC3277、-、一時的なBlackhole回避2002年4月

   Assume now that RtrB comes back online.  In only a few seconds, IS-IS
   neighbor state has been established with RtrA and RtrD and database
   synchronization has occurred.  RtrA now realizes that the best path
   to destination D.1 is via RtrB, and therefore updates it FIB
   appropriately.  RtrA begins to forward packets destined to D.1 to
   RtrB.  Though, because RtrB has yet to establish and synchronize its
   BGP neighbor relationship and routing information with RtrD, RtrB has
   no knowledge regarding reachability of destination D.1, and therefore
   discards the packets received from RtrA destined to D.1.

今、RtrBがオンラインで戻ると仮定してください。 ほんの数秒以降-、RtrAとRtrDと共に隣人状態を設置してあって、データベース同期は起こりました。 RtrAが、今目的地D.1への最も良い経路がRtrBを通してあって、したがって、それをアップデートするとわかる、FIB、適切に。 RtrAはD.1に運命づけられたパケットをRtrBに送り始めます。 もっとも、RtrBがそのBGP隣人関係とルーティング情報をRtrDとまだ確立していなくて、また同期させていないので、RtrBは目的地D.1の可到達性に関する知識を全く持っていなくて、したがって、パケットがD.1に運命づけられたRtrAから受けた破棄を持っています。

   If RtrB were to temporarily set its LSP Overload bit while
   synchronizing BGP tables with its neighbors, RtrA would continue to
   use the working RtrA->RtrC->RtrD path, and the LSP should only be
   used to obtain reachability to locally connected networks (rather
   than for calculating transit paths through the router, as defined in
   [1]).

LSPは、局所的に接続されたネットワークに可到達性を得るのに使用されるだけであるべきです。そして、RtrBがBGPテーブルを隣人に連動させている間、一時LSP Overloadビットを設定するなら、RtrAが、働くRtrA->を使用し続けている、RtrC、-、>RtrD経路、(ルータを通した計算のトランジット経路、むしろ定義されたコネ[1])として。

   However, it should be noted that when RtrB goes away, its LSP is
   still present in the IS-IS databases of all other routers in the
   routing domain.  When RtrB comes back it establishes adjacencies.  As
   soon as its neighbors have an adjacency with RtrB, they will
   advertise their new adjacency in their new LSP.  The result is that
   all the other routers will receive new LSPs from RtrA and RtrD
   containing the RtrB adjacency, even though RtrB is still completing
   its synchronization and therefore has not yet sent its new LSP.

しかしながら、RtrBが遠ざかるとき、LSPが中にまだ存在していることに注意されるべきである、-、データベース、経路ドメインの他のすべてのルータについて。 RtrBが戻るとき、それは隣接番組を確立します。 隣人にRtrBがある隣接番組があるとすぐに、彼らは新しいLSPに自分達の新しい隣接番組の広告を出すでしょう。 結果は他のすべてのルータがRtrB隣接番組を含むRtrAとRtrDから新しいLSPsを受けるということです、RtrBはまだ同期を終了していて、したがって、まだ新しいLSPを送りません。

   At this time SPF is computed and everyone will include RtrB in their
   tree since they will use the old version of RtrB LSP (the new one has
   not yet arrived).  Once RtrB has finished establishing all its
   adjacencies, it will then regenerate its LSP and flood it.  Then all
   other routers within the domain will finally compute SPF with the
   correct information.  Only at that time will the Overload bit be
   taken into account.

このとき、SPFは計算されます、そして、彼らがRtrB LSPの古いバージョンを使用するので(新しい方はまだ到着していません)、皆はそれらの木でRtrBを入れるでしょう。 RtrBが、いったんすべての隣接番組を確立し終えると、それは、次に、LSPを作り直して、それをあふれさせるでしょう。 そして、ドメインの中の他のすべてのルータが最終的に正確な情報があるSPFを計算するでしょう。 Overloadビットはその時、考慮に入れられるだけでしょう。

   As such, it is recommended that each time a router establishes an
   adjacency, it will update its LSP and flood it immediately, even
   before beginning database synchronization.  This will allow for the
   Overload bit setting to propagate immediately, and remove the
   potential for an older version of the reloaded routers LSP to be
   used.

そういうものとして、LSPをアップデートして、ルータが隣接番組を確立するたびにすぐにそれをあふれさせるのは、お勧めです、データベース同期を始める前にさえ。 これは、すぐに伝播するためにセットするOverloadビットを考慮して、再び積まれたルータLSPの旧式のバージョンが使用される可能性を取り除くでしょう。

   After synchronization of BGP tables with neighboring routers (or
   expiry of some other timer or trigger), RtrB would generate a new
   LSP, clearing the Overload bit, and RtrA could again begin using the
   optimal path via RtrB.

隣接しているルータ(または、ある他のタイマか引き金の満期)とのBGPテーブルの同期の後に、Overloadビットをきれいにして、RtrBは新しいLSPを発生させるでしょう、そして、RtrAは再びRtrBを通して最適経路を使用し始めることができました。

McPherson                    Informational                      [Page 3]

RFC 3277          IS-IS Transient Blackhole Avoidance         April 2002

マクファーソン情報[3ページ]のRFC3277、-、一時的なBlackhole回避2002年4月

   Typically, in service provider networks IBGP connections are done via
   peerings with 'loopback' addresses.  As such, the newly available
   router must advertise its own loopback (or similar) IP address, as
   well as associated adjacencies, in order to make the loopbacks
   accessible to other routers within the routing domain.  It is because
   of this that simply flooding an empty LSP is not sufficient.

通常、サービスプロバイダーネットワークでは、'ループバック'アドレスがあるpeeringsを通してIBGP接続をします。 そういうものとして、新たに利用可能なルータはそれ自身のループバックの、そして、(同様)のIPアドレスの広告を出さなければなりません、関連隣接番組と同様に、経路ドメインの中でループバックを他のルータにアクセスしやすくするように。 これのために、空のLSPを単にあふれさせるのは十分ではありません。

3. Deployment Considerations

3. 展開問題

   Such a mechanism increases overall network availability and allows
   network operators to alleviate the deterministic blackholing behavior
   introduced in this scenario.  Similar mechanisms [3] have been
   defined for OSPF, though only after realizing the usefulness obtained
   from that of the IS-IS Overload bit technique.

そのようなメカニズムは、総合的なネットワークの有用性を増加させて、ネットワーク・オペレータが振舞いがこのシナリオで導入した決定論的なblackholingを軽減するのを許容します。 同様のメカニズム[3]はOSPFのために定義されました、それから得られた有用性がわかった後にだけ-、Overloadはテクニックに噛み付きました。

   This mechanism has been deployed in several large IS-IS networks for
   a number of years.

このメカニズムが数個で大きい状態で配備された、-、何年間もネットワーク。

   Triggers for setting the Overload bit as described are left to the
   implementer.  Some potential triggers could perhaps include "N
   seconds after booting", or "N number of BGP prefixes in the BGP Loc-
   RIB".

説明されるようにOverloadビットを設定するための引き金はimplementerに残されます。 いくつかの潜在的引き金が恐らく「穂ばらみのN秒後」、または「BGP Loc- RIBのBGP接頭語のN番号」を含むかもしれません。

   Unlike similar mechanisms employed in [3], if the Overload bit is set
   in a router's LSP, NO transit paths are calculated through the
   router.  As such, if no alternative paths are available to the
   destination network, employing such a mechanism may actually have a
   negative impact on convergence (i.e., the router maintains the only
   available path to reach downstream routers, but the Overload bit
   disallows other nodes in the network from calculating paths via the
   router, and as such, no feasible path exists to the routers).

OverloadビットがルータのLSPに設定されるなら[3]で使われた同様のメカニズムと異なって、トランジット経路は全くルータを通して計算されません。 そういうものとして、どんな迂回経路も送信先ネットワークに利用可能でないなら、そのようなメカニズムを使うのは集合のときに実際にマイナスの影響があるかもしれません(噛み付かれたOverloadが計算の経路からネットワークでルータで他のノードを禁じます、そして、すなわち、ルータは川下のルータに達するように唯一の利用可能な経路を維持しますが、そういうものとして、実行可能経路は全くルータに存在していません)。

   Finally, if all systems within an IS-IS routing domain haven't
   implemented the Overload bit correctly, forwarding loops may occur.

最終的にすべてのシステムである、中、-、経路ドメイン、正しくOverloadビットを実行していなくて、輪を進めるのは起こるかもしれません。

4. Potential Alternatives

4. 潜在的代替手段

   Alternatively, it may be considered more appealing to employ
   something more akin to [3] for this purpose.  With this model, during
   transient conditions a node advertises excessively high link metrics
   to serve as an indication, to other nodes in the network that paths
   transiting the router are "less desirable" than existing paths.

あるいはまた、それはこのために[3]と何かより同系であるものを使うのが、より魅力的であると考えられるかもしれません。 一時的な状態の間、このモデルと共に、ノードはルータを通過する経路が存在するほど「それほど望ましくない」というネットワークにおける他のノードへの指示として経路に役立つ過度に高いリンク測定基準の広告を出します。

   The advantage of a metric-based mechanism over the Overload bit
   mechanism model proposed here is that transit paths may still be
   calculated through the router.  Another advantage is that a metric-
   based mechanism does not require that all nodes in the IS-IS domain
   correctly implement the Overload bit.

ここで提案されたOverloadの噛み付いているメカニズムモデルの上のメートル法ベースのメカニズムの利点はトランジット経路がルータを通してまだ計算されているかもしれないということです。 別の利点がメートル法のベースのメカニズムがそれを必要としないということである、中のすべてのノード、-、ドメイン、正しくOverloadビットを実行してください。

McPherson                    Informational                      [Page 4]

RFC 3277          IS-IS Transient Blackhole Avoidance         April 2002

マクファーソン情報[4ページ]のRFC3277、-、一時的なBlackhole回避2002年4月

   However, as currently deployed, IS-IS provides for only 6 bits of
   space for link metric allocation, and 10 bits aggregate path metric.
   Though extensions proposed in [4] remove this limitation, they have
   not yet been widely deployed.  As such, there's currently little
   flexibility when using link metrics for this purpose.  Of course,
   both methods proposed in this document are backwards-compatible.

同じくらい現在配備されている、-、スペースの6ビットだけに集合経路メートル法でリンクにメートル法の配分する、および10ビット備えます。 [4]で提案された拡大はこの制限を取り除きますが、それらはまだ広く配備されていません。 現在このためにリンク測定基準を使用するとき、そういうものとして、柔軟性がほとんどありません。 もちろん、本書では提案された両方の方法は後方に互換性があります。

5. Security Considerations

5. セキュリティ問題

   The mechanisms specified in this memo introduces no new security
   issues to IS-IS.

中のこのメモが紹介するどんな新しいセキュリティも発行しない指定されたメカニズム、-

6. Acknowledgements

6. 承認

   The author of this document makes no claim to the originality of the
   idea.  Thanks to Stefano Previdi for valuable feedback on the
   mechanism discussed in this document.

このドキュメントの作者はノークレームを考えの独創性にします。 本書では議論したメカニズムの有益なフィードバックをステファーノPrevidiをありがとうございます。

7. References

7. 参照

   [1] ISO, "Intermediate system to Intermediate system routing
       information exchange protocol for use in conjunction with the
       Protocol for providing the Connectionless-mode Network Service
       (ISO 8473)," ISO/IEC 10589:1992.

[1] ISO、「プロトコルに関連したConnectionless-モードNetwork Service(ISO8473)を提供する使用のためのIntermediateシステムルーティング情報交換プロトコルへの中間システム」、ISO/IEC、10589:1992

   [2] Callon, R., "OSI IS-IS for IP and Dual Environment," RFC 1195,
       December 1990.

[2]Callon、R.、「OSI、-、IPと二元的な環境、」、RFC1195、12月1990日

   [3] Retana, A., Nguyen, L., White, R., Zinin, A. and D. McPherson,
       "OSPF Stub Router Advertisement", RFC 3137, June 2001.

[3] レタナとA.とNguyenとL.とホワイトとR.とジニンとA.とD.マクファーソン、「OSPFスタッブルータ通知」、RFC3137、2001年6月。

   [4] Li, T. and H. Smit, "IS-IS extensions for Traffic Engineering",
       Work in Progress.

[4] 李、T.、およびH.スミット、「-、Traffic Engineeringのための拡大、」、ProgressのWork。

8. Author's Address

8. 作者のアドレス

   Danny McPherson
   TCB
   Phone: 303.470.9257
   EMail: danny@tcb.net

ダニーマクファーソンTCBは以下に電話をします。 303.470.9257 メールしてください: danny@tcb.net

McPherson                    Informational                      [Page 5]

RFC 3277          IS-IS Transient Blackhole Avoidance         April 2002

マクファーソン情報[5ページ]のRFC3277、-、一時的なBlackhole回避2002年4月

9.  Full Copyright Statement

9. 完全な著作権宣言文

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

McPherson                    Informational                      [Page 6]

マクファーソン情報です。[6ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

東京都の電車路線、駅の一覧

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る