RFC2260 日本語訳
2260 Scalable Support for Multi-homed Multi-provider Connectivity. T.Bates, Y. Rekhter. January 1998. (Format: TXT=28085 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Bates
Request for Comments: 2260 Cisco Systems
Category: Informational Y. Rekhter
Cisco Systems
January 1998
ネットワークワーキンググループT.はコメントを求める要求を和らげます: 2260年のシスコシステムズカテゴリ: 情報のY.Rekhterシスコシステムズ1998年1月
Scalable Support for Multi-homed Multi-provider Connectivity
スケーラブルなサポート、マルチ、家へ帰り、マルチプロバイダーの接続性
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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
2. Abstract
2. 要約
This document describes addressing and routing strategies for multi- homed enterprises attached to multiple Internet Service Providers (ISPs) that are intended to reduce the routing overhead due to these enterprises in the global Internet routing system.
このドキュメントが戦略を記述して、発送すると説明する、マルチ、家へ帰り、企業は世界的なインターネットルーティングシステムでこれらの企業によるルーティングオーバーヘッドを下げることを意図する複数のインターネットサービスプロバイダ(ISP)に付きました。
3. Motivations
3. 動機
An enterprise may acquire its Internet connectivity from more than one Internet Service Provider (ISP) for some of the following reasons. Maintaining connectivity via more than one ISP could be viewed as a way to make connectivity to the Internet more reliable. This way when connectivity through one of the ISPs fails, connectivity via the other ISP(s) would enable the enterprise to preserve its connectivity to the Internet. In addition to providing more reliable connectivity, maintaining connectivity via more than one ISP could also allow the enterprise to distribute load among multiple connections. For enterprises that span wide geographical area this could also enable better (more optimal) routing.
企業は以下の理由のいくつかによって1つ以上のインターネットサービスプロバイダ(ISP)からインターネットの接続性を取得するかもしれません。 インターネットへの接続性をより信頼できるようにする方法として1つ以上のISPで接続性を維持するのを見なすことができました。 このように、ISPの1つを通した接続性が失敗すると、他のISPを通した接続性は、企業がインターネットとして接続性を保存するのを可能にするでしょう。 また、より信頼できる接続性を提供することに加えて、1つ以上のISPで接続性を維持するのに、企業は複数の接続に負荷を分配できました。 また、広い地理的な領域にかかる企業に関しては、これは、より良い(より最適の)ルーティングを可能にするかもしれません。
The above considerations, combined with the decreasing prices for the Internet connectivity, motivate more and more enterprises to become multi-homed to multiple ISPs. At the same time, the routing overhead that such enterprises impose on the Internet routing system becomes more and more significant. Scaling the Internet, and being able to support a growing number of such enterprises demands mechanism(s) to contain this overhead. This document assumes that an approach where routers in the "default-free" zone of the Internet would be required
インターネットの接続性の減少している価格に結合された上の問題がなるようにますます多くの企業を動機づける、マルチ、家へ帰り、複数のISPに。 同時に、そのような企業がインターネット・ルーティングシステムに課すルーティングオーバーヘッドはますます重要になります。 インターネットをスケーリングして、このオーバーヘッドを含むようにそのような増加している数の企業要求メカニズムをサポートできること。 インターネットの「デフォルトなし」のゾーンのルータが必要であるだろうところでこのドキュメントは、それがアプローチであると仮定します。
Bates & Rekhter Informational [Page 1] RFC 2260 Multihoming January 1998
[1ページ]RFC2260マルチホーミング1998年1月の情報のベイツとRekhter
to maintain a route for every multi-homed enterprise that is connected to multiple ISPs does not provide an adequate scaling. Moreover, given the nature of the Internet, this document assumes that any approach to handle routing for such enterprises should minimize the amount of coordination among ISPs, and especially the ISPs that are not directly connected to these enterprises.
ルートを維持する、あらゆる、マルチ、家へ帰り、複数のISPに接続される企業は適切なスケーリングを提供しません。 そのうえ、インターネットの性質を考えて、このドキュメントは、扱うそのような企業のために掘られるどんなアプローチもISP、および特に直接これらの企業に接続されないISPの中でコーディネートの量を最小にするべきであると仮定します。
There is a difference of opinions on whether the driving factors behind multi-homing to multiple ISPs could be adequately addressed by multi-homing just to a single ISP, which would in turn eliminate the negative impact of multi-homing on the Internet routing system. Discussion of this topic is beyond the scope of this document.
複数のISPへのマルチホーミングの後ろの運転する要素がマルチホーミングでまさしくただ一つのISPに適切に記述されるかもしれないかどうかに関する意見の相違があります。(順番に、それは、インターネット・ルーティングシステムの上でマルチホーミングの負の衝撃を排除するでしょう)。 この話題の議論はこのドキュメントの範囲を超えています。
The focus of this document is on the routing and addressing strategies that could reduce the routing overhead due to multi-homed enterprises connected to multiple ISPs in the Internet routing system.
このドキュメントの焦点がルーティングにあって、ルーティングオーバーヘッドを下げることができた戦略を記述するのがある、マルチ、家へ帰り、企業はインターネット・ルーティングシステムの複数のISPに接続しました。
The strategies described in this document are equally applicable to both IPv4 and IPv6.
本書では説明された戦略は等しくIPv4とIPv6の両方に適切です。
4. Address allocation and assignment
4. アドレス配分と課題
A multi-homed enterprise connected to a set of ISPs would be allocated a block of addresses (address prefix) by each of these ISPs (an enterprise connected to N ISPs would get N different blocks). The address allocation from the ISPs to the enterprise would be based on the "address-lending" policy [RFC2008]. The allocated addresses then would be used for address assignment within the enterprise.
マルチ、家へ帰り、それぞれのこれらのISPは1ブロックのアドレス(アドレス接頭語)を1セットのISPに接続された企業に割り当てるでしょう(N ISPに接続された企業はN異なったブロックを手に入れるでしょう)。 ISPから企業までのアドレス配分は「アドレスを貸している」方針[RFC2008]に基づくでしょう。 そして、割り当てられたアドレスはアドレス課題に企業の中で使用されるでしょう。
One possible address assignment plan that the enterprise could employ is to use the topological proximity of a node (host) to a particular ISP (to the interconnect between the enterprise and the ISP) as a criteria for selecting which of the address prefixes to use for address assignment to the node. A particular node (host) may be assigned address(es) out of a single prefix, or may have addresses from different prefixes.
企業が使うことができた1つの可能なアドレス課題プランはアドレス課題にノードに使用するアドレス接頭語についてどれを選択するか評価基準として特定のISP(企業とISPの間の内部連絡への)にノード(ホスト)の位相的な近接を使用することです。 特定のノード(ホスト)には、ただ一つの接頭語からの割り当てられたアドレスであるかもしれない(es)、またはアドレスが異なった接頭語からあるかもしれません。
5. Routing information exchange
5. ルート設定情報交換
The issue of routing information exchange between an enterprise and its ISPs is decomposed into the following components:
企業とそのISPの間のルーティング情報交換の問題は以下のコンポーネントに分解されます:
a) reachability information that an enterprise border router
advertises to a border router within an ISP
a) 企業境界ルータがISPの中に境界ルータに広告を出すという可到達性情報
b) reachability information that a border router within an ISP
advertises to an enterprise border router
ISPの中の境界ルータが企業境界ルータに広告を出すというb)可到達性情報
Bates & Rekhter Informational [Page 2] RFC 2260 Multihoming January 1998
[2ページ]RFC2260マルチホーミング1998年1月の情報のベイツとRekhter
The primary focus of this document is on (a); (b) is covered only as needed by this document.
このドキュメントの焦点が(a)にあります。 (b) 必要に応じてだけこのドキュメントで覆われています。
5.1. Advertising reachability information by enterprise border routers
5.1. 企業境界ルータによる広告可到達性情報
When an enterprise border router connected to a particular ISP determines that the connectivity between the enterprise and the Internet is up through all of its ISPs, the router advertises (to the border router of that ISP) reachability to only the address prefix that the ISP allocated to the enterprise. This way in a steady state routes injected by the enterprise into its ISPs are aggregated by these ISPs, and are not propagated into the "default-free" zone of the Internet.
ISP、ルータのすべてを通して企業とインターネットの間の接続性をある特定のISPに関連している境界ルータが決定する計画がISPが企業に割り当てたアドレス接頭語だけに可到達性の広告を出すとき(そのISPの境界ルータに)。 このように、企業によってISPに注入されたルートは、定常状態では、これらのISPによって集められて、インターネットの「デフォルトなし」のゾーンに伝播されません。
When an enterprise border router connected to a particular ISP detemrines that the connectivity between the enterprise and the Internet through one or more of its other ISPs is down, the router starts advertising reachability to the address prefixes that was allocated by these ISPs to the enterprise. This would result in injecting additional routing information into the "default-free" zone of the Internet. However, one could observe that the probability of all multi-homed enterprises in the Internet concurrently losing connectivity to the Internet through one or more of their ISPs is fairly small. Thus on average the number of additional routes in the "default-free" zone of the Internet due to multi-homed enterprises is expected to be a small fraction of the total number of such enterprises.
他のISPの1つ以上を通した企業とインターネットの間の接続性がdetemrinesであるのにもかかわらずの、企業境界ルータが特定のISPに接続したときにはダウンしてください、ルータ始めがこれらのISPによって企業に割り当てられたアドレス接頭語に可到達性の広告を出して。 これはインターネットの「デフォルトなし」のゾーンに追加ルーティング情報を注ぐのに結果として生じるでしょう。 しかしながら、人がそれを観測できた、すべての確率、マルチ、家へ帰り、同時にそれらのISPの1つ以上を通してインターネットに接続性を失うインターネットの企業はかなり小さいです。 その結果、平均的にインターネットの「デフォルトなし」のゾーンの追加ルートの数がそうする、マルチ、家へ帰り、計画はそのような企業の総数のわずかな部分であると予想されます。
The approach described above is predicated on the assumption that an enterprise border router has a mechanism(s) by which it could determine (a) whether the connectivity to the Internet through some other border router of that enterprise is up or down, and (b) the address prefix that was allocated to the enterprise by the ISP connected to the other border router. One such possible mechanism could be provided by BGP [RFC1771]. In this case border routers within the enterprise would have an IBGP peering with each other. Whenever one border router determines that the intersection between the set of reachable destinations it receives via its EBGP (from its directly connected ISP) peerings and the set of reachable destinations it receives from another border router (in the same enterprise) via IBGP is empty, the border router would start advertising to its external peer reachability to the address prefix that was allocated to the enterprise by the ISP connected to the other border router. The other border router would advertise (via IBGP) the address prefix that was allocated to the enterprise by the ISP connected to that router. This approach is known as "auto route injection".
(b) 上で説明されたアプローチは企業境界ルータにはそれが(a) その企業のある他の境界ルータを通したインターネットへの接続性が上がるか、または下がっているかを決定できたメカニズムがあるという前提で叙述されました、そして、ISPによって企業に割り当てられたアドレス接頭語はもう片方の境界ルータに接続しました。 BGP[RFC1771]はそのような可能なメカニズムの1つを提供できました。 この場合、企業の中の境界ルータで、IBGPは互いと共にじっと見るでしょう。 1つの境界ルータが、それがEBGP(直接接続されたISPからの)peeringsを通して受ける届いている目的地のセットとそれがIBGPを通して別の境界ルータ(同じ企業における)から受ける届いている目的地のセットの間の交差点が人影がないことを決定するときはいつも、境界ルータは、外部の同輩の可到達性に広告を出しもう片方の境界ルータに関連づけられたISPによって企業に割り当てられたアドレス接頭語に始めるでしょう。 もう片方の境界ルータはそのルータに関連づけられたISPによって企業に割り当てられたアドレス接頭語の広告を出すでしょう(IBGPを通して)。 このアプローチは「オート・ルート注射」として知られています。
Bates & Rekhter Informational [Page 3] RFC 2260 Multihoming January 1998
[3ページ]RFC2260マルチホーミング1998年1月の情報のベイツとRekhter
As an illustration consider an enterprise connected to two ISPs, ISP-A and ISP-B. Denote the enterprise border router that connects the enterprise to ISP-A as BR-A; denote the enterprise border router that connects the enterprise to ISP-B as BR-B. Denote the address prefix that ISP-A allocated to the enterprise as Pref-A; denote the address prefix that ISP-B allocated to the enterprise as Pref-B. When the set of routes BR-A receives from ISP-A (via EBGP) has a non-empty intersection with the set of routes BR-A receives from BR-B (via IBGP), BR-A advertises to ISP-A only the reachability to Pref-A. When the intersection becomes empty, BR-A would advertise to ISP-A reachability to both Pref-A and Pref-B. This would continue for as long as the intersection remains empty. Once the intersection becomes non-empty, BR-A would stop advertising reachability to Pref-B to ISP-A (but would still continue to advertise reachability to Pref-A to ISP-A). Figure 1 below describes this method graphically.
イラストと、2つのISP、ISP A、およびISP Bに接続された計画を考えてください。 BR-AとしてISP Aに企業を接続する企業境界ルータを指示してください。 BR-BとしてISP Bに企業を接続する企業境界ルータを指示してください。 ISP AがPref-Aとして企業に割り当てたアドレス接頭語を指示してください。 ISP BがPref-Bとして企業に割り当てたアドレス接頭語を指示してください。 BR-AがISP A(EBGPを通した)から受けるルートのセットにBR-AがBR-B(IBGPを通した)から受けるルートのセットがある非人影のない交差点があるとき、BR-AはISP AにPref-Aへの可到達性だけの広告を出します。 交差点が空になると、BR-AはPref-AとPref-Bの両方へのISP Aの可到達性に広告を出すでしょう。 交差点が空のままで残っている限り、これは続くでしょう。 しかし、交差点がいったん非空になると、BR-Aが、Pref-Bに可到達性の広告を出すのをISP Aに止めるだろう、(まだISP a)へのPref-Aに可到達性の広告を出してい続けているでしょう。 以下の図1はグラフィカルにこの方法を説明します。
+-------+ +-------+ +-------+ +-------+
( ) ( ) ( ) ( )
( ISP-A ) ( ISP-B ) ( ISP-A ) ( ISP-B )
( ) ( ) ( ) ( )
+-------+ +-------+ +-------+ +-------+
| /\ | /\ | /\ |
| || | || | Pref-A (connection
| Pref-A | Pref-B | Pref-B broken)
| || | || | || |
+-----+ +-----+ +-----+ +-----+
| BR-A|------|BR-B | | BR-A|------|BR-B |
+-----+ IBGP +-----+ +-----+ IBGP +-----+
+-------+ +-------+ +-------+ +-------+ ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) (ISP A)(ISP B)(ISP A)(ISP B)+-------+ +-------+ +-------+ +-------+ | /\ | /\ | /\ | | || | || | Pref-A(接続|Pref-A|Pref-B| 壊されたPref-B)| || | || | || | +-----+ +-----+ +-----+ +-----+ | Br A|------|Br B| | Br A|------|Br B| +-----+ IBGP+-----+ +-----+ IBGP+-----+
non-empty intersection empty intersection
非人影のない交差点人影のない交差点
Figure 1: Reachability information advertised
図1: 広告に掲載された可到達性情報
Although strictly an implementation detail, calculating the intersection could potentially be a costly operation for a large set of routes. An alternate solution to this is to make use of a selected single (or more) address prefix received from an ISP (the ISP's backbone route for example) and configure the enterprise border router to perform auto route injection if the selected prefix is not present via IBGP. Let's suppose ISP-B has a well known address prefix, ISP-Pref-B for its backbone. ISP-B advertises this to BR-B and BR-B in turn advertises this via IBGP to BR-A. If BR-A sees a withdraw for ISP-Pref-B it advertises Pref-B to ISP-A.
実現の詳細、交差点について計算するのは厳密にそうすることができましたが、大きいセットのルートのための潜在的に高価な操作になってください。 この代替策は、選択された接頭語がIBGPを通して存在していないなら、ISP(例えば、ISPの背骨ルート)から受け取られた選択されたただ一つ(さらに)のアドレス接頭語を利用して、オート・ルート注射を実行するために企業境界ルータを構成することです。 ISP Bにはよく知られているアドレス接頭語、背骨のためのISP-Pref-Bがあると思いましょう。 ISP BはBR-Bにこれの広告を出します、そして、BR-BはBR-AへのIBGPを通して順番にこれの広告を出します。 BR-Aが、aがISP-Pref-Bのために引き下がるのを見るなら、それはISP AにPref-Bの広告を出します。
Bates & Rekhter Informational [Page 4] RFC 2260 Multihoming January 1998
[4ページ]RFC2260マルチホーミング1998年1月の情報のベイツとRekhter
The approach described in this section may produce less than the full Internet-wide connectivity in the presence of ISPs that filter out routes based on the length of their address prefixes. One could observe however, that this would be a problem regardless of how the enterprise would set up its routing and addressing.
このセクションで説明されたアプローチはルートを無視するISPがあるとき完全なインターネット全体の接続性がそれらのアドレス接頭語の長さを基礎づけたほど生産されないかもしれません。 しかしながら、人は見ることができて、企業がどうそのルーティングとアドレシングをセットアップするだろうかにかかわらずこれは問題でしょう。
5.2. Further improvements
5.2. さらなる改良
The approach described in the previous section allows to significantly reduce the routing overhead in the "default-free" zone of the Internet due to multi-homed enterprises. The approach described in this section allows to completely eliminate this overhead.
中の前項がインターネットの「デフォルトなし」のゾーンにおけるルーティングオーバーヘッドをかなり下げさせる説明されたアプローチがそうする、マルチ、家へ帰り、企業。 このセクションで説明されたアプローチで、このオーバーヘッドを完全に取り除きます。
An enterprise border router would maintain EBGP peering not just with the directly connected border router of an ISP, but with the border router(s) in one or more ISPs that have their border routers directly connected to the other border routers within the enterprise. We refer to such peering as "non-direct" EBGP.
企業境界ルータはISPの直接接続された境界ルータだけでじっと見るのではなく、境界ルータで企業の中で直接それらの境界ルータを他の境界ルータに関連づける1つ以上のISPでじっと見るEBGPを維持するでしょう。 私たちは「非ダイレクトな」EBGPのようなじっと見ることについて言及します。
An ISP that maintains both direct and non-direct EBGP peering with a particular enterprise would advertise the same set of routes over both of these peerings. An enterprise border router that maintains either direct or non-direct peering with an ISP advertises to that ISP reachability to the address prefix that was allocated by that ISP to the enterprise. Within the ISP routes received over direct peering should be preferred over routes received over non-direct peering. Likewise, within the enterprise routes received over direct peering should be preferred over routes received over non-direct peering.
特定の企業と共にじっと見るEBGPをダイレクトに、そして非ダイレクトに維持するISPはこれらのpeeringsの両方の上に同じセットのルートの広告を出すでしょう。 ISPとのダイレクトであるか非ダイレクトなじっと見ることがそのISPによって企業に割り当てられたアドレス接頭語へのそのISPの可到達性に広告を出すと主張する企業境界ルータ。 中では、ダイレクトじっと見る上に受け取られたISPルートが非ダイレクトなじっと見る上に受け取られたルートより好まれるべきです。 同様に、企業の中では、ダイレクトじっと見る上に受け取られたルートは非ダイレクトなじっと見る上に受け取られたルートより好まれるべきです。
Forwarding along a route received over non-direct peering should be accomplished via encapsulation [RFC1773].
カプセル化[RFC1773]で非ダイレクトなじっと見る上に受け取られたルートに沿った推進は実行されるべきです。
As an illustration consider an enterprise connected to two ISPs, ISP-A and ISP-B. Denote the enterprise border router that connects the enterprise to ISP-A as E-BR-A, and the ISP-A border router that is connected to E-BR-A as ISP-BR-A; denote the enterprise border router that connects the enterprise to ISP-B as E-BR-B, and the ISP-B border router that is connected to E-BR-B as ISP-BR-B. Denote the address prefix that ISP-A allocated to the enterprise as Pref-A; denote the address prefix that ISP-B allocated to the enterprise as Pref-B. E-BR-A maintains direct EBGP peering with ISP-BR-A and advertises reachability to Pref-A over that peering. E-BR-A also maintain a non-direct EBGP peering with ISP-BR-B and advertises reachability to Pref-B over that peering. E-BR-B maintains direct EBGP peering with ISP-BR-B, and advertises reachability to Pref-B over that peering. E-BR-B also maintains a non-direct EBGP peering
イラストと、2つのISP、ISP A、およびISP Bに接続された計画を考えてください。 E-BR-AとしてISP Aに企業を接続する企業境界ルータを指示して、ISP-BR-AとしてE-BR-Aに接続されるISP A境界ルータを指示してください。 E-BR-BとしてISP Bに企業を接続する企業境界ルータを指示して、ISP-BR-BとしてE-BR-Bに接続されるISP B境界ルータを指示してください。 ISP AがPref-Aとして企業に割り当てたアドレス接頭語を指示してください。 ISP BがPref-Bとして企業に割り当てたアドレス接頭語を指示してください。 E- BR-AはISP-BR-Aと共にじっと見るダイレクトEBGPを維持して、そのじっと見ることの上にPref-Aに可到達性の広告を出します。 E- BR-Aはそのじっと見ることの上にまた、ISP-BR-Bと共にじっと見る非ダイレクトなEBGPを維持して、Pref-Bに可到達性の広告を出します。 E- BR-BはISP-BR-Bと共にじっと見るダイレクトEBGPを維持して、そのじっと見ることの上にPref-Bに可到達性の広告を出します。 また、E- BR-Bは非ダイレクトなEBGPをじっと見るのに維持します。
Bates & Rekhter Informational [Page 5] RFC 2260 Multihoming January 1998
[5ページ]RFC2260マルチホーミング1998年1月の情報のベイツとRekhter
with ISP-BR-A, and advertises reachability to Pref-A over that peering.
ISP-BR-A、そのじっと見ることの上にPref-Aに可到達性の広告を出します。
When connectivity between the enterprise and both of its ISPs (ISP-A and ISP-B is up, traffic destined to hosts whose addresses were assigned out of Pref-A would flow through ISP-A to ISP-BR-A to E-BR- A, and then into the enterprise. Likewise, traffic destined to hosts whose addresses were assigned out of Pref-B would flow through ISP-B to ISP-BR-B to E-BR-B, and then into the enterprise. Now consider what would happen when connectivity between ISP-BR-B and E-BR-B goes down. In this case traffic to hosts whose addresses were assigned out of Pref-A would be handled as before. But traffic to hosts whose addresses were assigned out of Pref-B would flow through ISP-B to ISP-BR-B, ISP-BR-B would encapsulate this traffic and send it to E- BR-A, where the traffic will get decapsulated and then be sent into the enterprise. Figure 2 below describes this approach graphically.
ISP AとISP Bが上がっている、アドレスがPref-Aから割り当てられたホストに運命づけられた交通はISP Aを通してE-BR- Aと、そして、そして、企業の中へのISP-BR-Aに流れるでしょう。ISPの企業と両方の間の接続性である、(同様に、アドレスがPref-Bから割り当てられたホストに運命づけられた交通はISP Bを通してE-BR-Bと、そして、そして、企業の中へのISP-BR-Bに流れるでしょう; ISP-BR-BとE-BR-Bの間の接続性が落ちると、起こるでしょう。今度は. アドレスがPref-Bから割り当てられたホストへの交通がISP Bを通してISP-BR-Bに流れて、ISP-BR-BがE BR-Aにこの交通を要約して、それを送る前にこの場合アドレスがPref-Aから割り当てられたホストへの交通が何として扱われるか考えてください; 交通がそうするところでは、decapsulatedしてください、そして、次に、企業に送ってください。以下の図2はグラフィカルにこのアプローチについて説明します。
+---------+ +---------+
( ) ( )
( ISP-A ) ( ISP-B )
( ) ( )
+---------+ +---------+
| |
+--------+ +--------+
|ISP-BR-A| |ISP-BR-B|
+--------+ +--------+
| /+/ |
/\ | Pref-B /+/ |
|| | /+/ \./
Pref-A| /+/ non- /.\
|| | /+/ direct |
| /+/ EBGP |
+------+ +-------+
|E-BR-A|-----------|E-BR-B |
+------+ IBGP +-------+
+---------+ +---------+ ( ) ( ) ( ) ( ) (ISP A)(ISP B)+---------+ +---------+ | | +--------+ +--------+ |ISP Br A| |ISP Br B| +--------+ +--------+ | /+/ | /\ | Pref-B/+/| || | /+/\/Pref-A| /+/非/\|| | /+/ダイレクトです。| | /+/EBGP| +------+ +-------+ |電子BrのA|-----------|電子BrのB| +------+ IBGP+-------+
Figure 2: Reachability information advertised via non-direct EBGP
図2: 非ダイレクトなEBGPを通しての広告に掲載された可到達性情報
Observe that with this scheme there is no additional routing information due to multi-homed enterprises that has to be carried in the "default-free" zone of the Internet. In addition this scheme doesn't degrade in the presence of ISPs that filter out routes based on the length of their address prefixes.
あるこの計画でどんな追加ルーティング情報もそうしないのを観測してください、マルチ、家へ帰り、インターネットの「デフォルトなし」のゾーンで運ばれるためにそれにはある企業。 さらに、この計画はそれらのアドレス接頭語の長さに基づくルートを無視するISPがあるとき下がりません。
Note that the set of routers within an ISP that maintain non-direct peering with the border routers within an enterprise doesn't have to be restricted to the ISP's border routers that have direct peering
ISPの中の企業の中を境界ルータでじっと見るのがそうする必要はないと非ダイレクトに主張するルータのセットがダイレクトじっと見ることを持っているISPの境界ルータに制限されることに注意してください。
Bates & Rekhter Informational [Page 6] RFC 2260 Multihoming January 1998
[6ページ]RFC2260マルチホーミング1998年1月の情報のベイツとRekhter
with the enterprise's border routers. The non-direct peering could be maintained with any router within the ISP. Doing this could improve the overall robustness in the presence of failures within the ISP.
企業のものと共に、ルータに接してください。 ISPの中でどんなルータでも非ダイレクトなじっと見ることを維持できました。 これをすると、総合的な丈夫さはISPの中の失敗があるとき改良されるかもしれません。
5.3. Combining the two
5.3. 2を結合します。
One could observe that while the approach described in Section 5.2 allows to completely eliminate the routing overhead due to multi- homed enterprises in the "default-free" zone of the Internet, it may result in a suboptimal routing in the presence of link failures. The sub-optimality could be reduced by combining the approach described in Section 5.2 with a slightly modified version of the approach described in Section 5.1. The modification consists of constraining the scope of propagation of additional routes that are advertised by an enterprise border router when the router detects problems with the Internet connectivity through its other border routers. A way to constrain the scope is by using the BGP Community attribute [RFC1997].
人が、アプローチがセクション5.2が完全に排泄するのを許容するコネについて説明しましたが、ルーティングオーバーヘッドがそうするのを観測できた、マルチ、家へ帰り、インターネットの「デフォルトなし」のゾーンの企業、それはリンクの故障があるとき準最適のルーティングをもたらすかもしれません。 サブの最適は、セクション5.2でアプローチのわずかに変更されたセクション5.1で説明されるバージョンで説明されたアプローチを結合することによって、減少できるでしょう。 変更はルータが他の境界ルータを通してインターネットの接続性に関する問題を検出すると企業境界ルータによって広告に掲載される追加ルートの伝播の範囲を抑制するのから成ります。 範囲を抑制する方法はBGP Community属性[RFC1997]を使用することです。
5.4. Better (more optimal) routing in steady state
5.4. 定常状態における、より良い(より最適の)ルーティング
The approach described in this document assumes that in a steady state an enterprise border router would advertise to a directly connected ISP border router only the reachability to the address prefix that this ISP allocated to the enterprise. As a result, traffic originated by other enterprises connected to that ISP and destined to the parts of the enterprise numbered out of other address prefixes would not enter the enterprise at this border router, resulting in potentially suboptimal paths. To improve the situation the border router may (in steady state) advertise reachability not only to the address prefix that was allocated by the ISP that the router is directly connected to, but to the address prefixes allocated by some other ISPs (directly connected to some other border routers within the enterprise). Distribution of such advertisements should be carefully constrained, or otherwise this may result in significant additional routing information that would need to be maintained in the "default-free" part of the Internet. A way to constrain the distribution of such advertisements is by using the BGP Community attribute [RFC1997].
本書では説明されたアプローチは、定常状態では、企業境界ルータがこのISPが企業に割り当てたアドレス接頭語への可到達性だけの直接接続されたISP境界ルータに広告を出すと仮定します。 その結果、そのISPに接続された他の企業によって溯源されて、他のアドレス接頭語から付番された企業の部分に運命づけられた交通はこの境界ルータで企業に入らないでしょう、潜在的に準最適の経路をもたらして。 状況を改善するために、境界ルータはルータが直接関連づけられるISPによって割り当てられたアドレス接頭語に広告を出すだけではなく、ある他のISP(企業の中で直接ある他の境界ルータに関連づけられる)によって割り当てられたアドレス接頭語にも可到達性の広告を出すかもしれません(定常状態で)。 そのような広告の分配が慎重に抑制されるべきですか、またはさもなければ、これはインターネットの「デフォルトなし」の地域で維持される必要がある重要な追加ルーティング情報をもたらすかもしれません。 そのような広告の分配を抑制する方法はBGP Community属性[RFC1997]を使用することです。
6. Comparison with other approaches
6. 他のアプローチとの比較
CIDR [RFC1518] proposes several possible address allocation strategies for multi-homed enterprises that are connected to multiple ISPs. The following briefly reviews the alternatives being used today, and compares them with the approaches described above.
CIDR[RFC1518]がいくつかの可能なアドレス配分戦略を提案する、マルチ、家へ帰り、複数のISPに接続される企業。 以下は、今日使用されることで簡潔に代替手段を見直して、上で説明されたアプローチとそれらを比べます。
Bates & Rekhter Informational [Page 7] RFC 2260 Multihoming January 1998
[7ページ]RFC2260マルチホーミング1998年1月の情報のベイツとRekhter
6.1. Solution 1
6.1. ソリューション1
One possible solution suggested in [RFC1518] is for each multi-homed enterprise to obtain its IP address space independently from the ISPs to which it is attached. This allows each multi-homed enterprise to base its IP assignments on a single prefix, and to thereby summarize the set of all IP addresses reachable within that enterprise via a single prefix. The disadvantage of this approach is that since the IP address for that enterprise has no relationship to the addresses of any particular ISPs, the reachability information advertised by the enterprise is not aggregatable with any, but default route. results in the routing overhead in the "default-free" zone of the Internet of O(N), where N is the total number of multi-homed enterprises across the whole Internet that are connected to multiple ISPs.
[RFC1518]に示された1つの可能な解決策がそれぞれのためのものである、マルチ、家へ帰り、それが付けているISPからIPアドレス空間を独自に得る企業。 これがそれぞれを許容する、マルチ、家へ帰り、IP課題をただ一つの接頭語に基礎づけて、その結果ただ一つの接頭語を通してその企業の中で届いているすべてのIPアドレスのセットをまとめる企業。 デフォルトルートいずれがある「集合-可能」ではなく、その企業のためのIPアドレスにはどんな特定のISPのアドレス、企業によって広告に掲載された可到達性情報との関係も全くないのでO(N)のインターネットの「デフォルトなし」のゾーンにおけるルーティングオーバーヘッドでNが総数であるところの結果であるこのアプローチの難点がある、マルチ、家へ帰り、全体のインターネット中の複数のISPに接続される企業。
As a result, this approach can't be viewed as a viable alternative for all, but the enterprises that provide high enough degree of addressing information aggregation. Since by definition the number of such enterprises is likely to be fairly small, this approach isn't viable for most of the multi-homed enterprises connected to multiple ISPs.
結果、このアプローチを見ることができないように、企業以外のすべてのための実行可能な代案として、それは十分高度のアドレス指定情報集合を提供します。 そのような企業の数が定義上かなり小さい傾向があるので大部分には、このアプローチが実行可能でない、マルチ、家へ帰り、企業は複数のISPに接続しました。
6.2. Solution 2
6.2. ソリューション2
Another possible solution suggested in [RFC1518] is to assign each multi-homed enterprise a single address prefix, based on one of its connections to one of its ISPs. Other ISPs to which the multi-homed enterprise is attached maintain a routing table entry for the organization, but are extremely selective in terms of which other ISPs are told of this route and would need to perform "proxy" aggregation. Most of the complexity associated with this approach is due to the need to perform "proxy" aggregation, which in turn requires t addiional inter-ISP coordination and more complex router configuration.
[RFC1518]に示された別の可能な解決策がそれぞれを割り当てることである、マルチ、家へ帰り、ISPの1つとの接続のひとりに基づいた企業のaただ一つのアドレス接頭語。 他のISP、どれ、マルチ、家へ帰り、付けられた企業は組織のためにa経路指定テーブルエントリーを維持します、どの他のISPがこのルートについて言われるかに非常に選択していて、「プロキシ」集合を実行するのが必要であるだろうというのを除いて。 このアプローチに関連している複雑さの大部分は順番にt addiional相互ISPコーディネートと、より複雑なルータ構成を必要とする「プロキシ」集合を実行する必要性のためです。
7. Discussion
7. 議論
The approach described in this document assumes that addresses that an enterprise would use are allocated based on the "address lending" policy. Consequently, whenever an enterprise changes its ISP, the enterprise would need to renumber part of its network that was numbered out of the address block that the ISP allocated to the enterprise. However, these issues are not specific to multihoming and should be considered accepted practice in todays internet. The approach described in this document effectively eliminates any distinction between single-home and multi-homed enterprise with respect to the impact of changing ISPs on renumbering.
本書では説明されたアプローチは、企業が使用するアドレスが「アドレスの貸す」方針に基づいて割り当てられると仮定します。 その結果、ISPを変えるときはいつも、企業は、ISPが企業に割り当てたあて先ブロックから付番されたネットワークの一部に番号を付け替えさせる必要があるでしょう。 しかしながら、これらの問題は、マルチホーミングに特定でなく、今日のインターネットにおける慣例であると考えられるべきです。 そして、本書では有効に説明されたアプローチがただ一つの家でのどんな区別も排除する、マルチ、家へ帰り、変化ISPの番号を付け替えることへの影響に関する企業。
Bates & Rekhter Informational [Page 8] RFC 2260 Multihoming January 1998
[8ページ]RFC2260マルチホーミング1998年1月の情報のベイツとRekhter
The approach described in this document also requires careful address assignment within an enterprise, as address assignment impacts traffic distribution among multiple connections between an enterprise and its ISPs.
また、本書では説明されたアプローチは企業の中で慎重なアドレス課題を必要とします、アドレス課題が企業とそのISPとの複数の関係にトラヒック分配に影響を与えるとき。
Both the issue of address assignment and renumbering could be addressed by the appropriate use of network address translation (NAT). The use of NAT for multi-homed enterprises is the beyond the scope of this document.
ネットワークアドレス変換(NAT)の適切な使用でアドレス課題の問題と番号を付け替えることの両方を記述できるでしょう。 NATの使用、マルチ、家へ帰り、企業はこの範囲が記録する以遠です。
Use of auto route injection (as described in Section 5.1) increases the number of routers in the default-free zone of the Internet that could be affected by changes in the connectivity of multi-homed enterprises, as compared to the use of provider-independed addresses (as described in Section 6.1). Specifically, with auto route injection when a multi-homed enterprise loses its connectivity through one of its ISPs, the auto injected route has to be propagated to all the routers in the default-free zone of the Internet. In contrast, when an enterprise uses provider-independent addresses, only some (but not all) of the routers in the default-free zone would see changes in routing when the enterprise loses its connectivity through one of its ISPs.
注射が接続性における変化で影響を受けることができたインターネットの無デフォルトのゾーンのルータの数を増加させる(セクション5.1で説明されるように)オート・ルートの使用、マルチ、家へ帰り、企業プロバイダーで不依存させられたアドレスの使用と比べて(セクション6.1で説明されるように)。 aであることの特にオート・ルート注射、マルチ、家へ帰り、企業はISPの1つを通して接続性を失って、自動注入されたルートはインターネットの無デフォルトのゾーンのすべてのルータに伝播されなければなりません。 対照的に、企業がプロバイダーから独立しているアドレスを使用すると、企業がISPの1つを通して接続性を失うと、無デフォルトのゾーンのルータのいくつか(すべてでない)だけがルーティングにおける変化を見るでしょう。
To supress excessive routing load due to link flapping the auto injected route has to be advertised until the connectivity via the other connection (that was previously down and that triggered auto route injection) becomes stable.
supressの過度のルーティングに、もう片方の接続(それは以前に下にいました、そして、オート・ルート注射の引き金となった)を通した接続性が安定するようになるまで、自動注入されたルートをばたつかせながらリンクするのにおいて当然の負荷の広告を出さなければなりません。
Use of the non-direct EBGP approach (as described in Section 5.2) allows to eliminate route flapping due to multi-homed enterprises in the default-free zone of the Internet. That is the non-direct EBGP approach has better properties with respect to routing stability than the use of provider-independent addresses (as described in Section 6.1).
アプローチ(セクション5.2で説明されるように)でルートのばたつくことを排除する非ダイレクトなEBGPの使用がそうする、マルチ、家へ帰り、インターネットの無デフォルトのゾーンの企業。 すなわち、非ダイレクトなEBGPアプローチには、ルーティングの安定性に関してプロバイダーから独立しているアドレスの使用より良い特性があります(セクション6.1で説明されるように)。
8. Applications to multi-homed ISPs
8. アプリケーション、マルチ、家へ帰り、ISP
The approach described in this document could be applicable to a small to medium size ISP that is connected to several upstream ISPs. The ISP would acquire blocks of addresses (address prefixes) from its upstream ISPs, and would use these addresses for allocations to its customers. Either auto route injection, or the non-direct EBGP approach, or a combination of both could be used by the ISP when peering with its upstream ISPs. Doing this would provide routability for the customers of such ISP, without advertsely affecting the overall scalability of the Internet routing system.
本書では説明されたアプローチはaにいくつかの上流のISPに関連づけられる中型のサイズISPに小さい状態で適切であるかもしれません。 ISPは、上流のISPからブロックのアドレス(アドレス接頭語)を習得して、配分にこれらのアドレスを顧客に使用するでしょう。 上流のISPでじっと見るとき、オート・ルート注射か非ダイレクトなEBGPのどちらかがアプローチするか、またはISPは両方の組み合わせを使用できました。 これをすると、routabilityはそのようなISPの顧客に提供されるでしょう、advertselyにインターネット・ルーティングシステムの総合的なスケーラビリティに影響しないで。
Bates & Rekhter Informational [Page 9] RFC 2260 Multihoming January 1998
[9ページ]RFC2260マルチホーミング1998年1月の情報のベイツとRekhter
9. Security Considerations
9. セキュリティ問題
Since the non-direct EBGP approach (as described in Section 5.2) requires EBGP sessions between routers that are more than one IP hop from each other, routers that maintain these sessions should use an appropriate authentication mechanism(s) for BGP peer authentication.
非ダイレクトなEBGPアプローチ(セクション5.2で説明されるように)が互いから1つ以上のIPホップであるルータの間のEBGPセッションを必要とするので、これらのセッションを維持するルータはBGP同輩認証に適切な認証機構を使用するべきです。
Security issues related to the IBGP peering, as well as the EBGP peering between routers that are one IP hop from each other are outside the scope of this document.
安全保障問題はこのドキュメントの範囲の外に互いからの1つのIPホップであるルータの間をじっと見るEBGPがあるのと同じくらい上手にじっと見るIBGPに関連しました。
10. Acknowledgments
10. 承認
The authors of this document do not make any claims on the originality of the ideas described in this document. Anyone who thought about these ideas before should be given all due credit.
このドキュメントの作者は考えの独創性のどんなクレームについても本書では説明させません。 以前これらの考えについて考えただれにもすべての当然のクレジットを与えるべきです。
11. References
11. 参照
[RFC1518]
Rekhter, Y., and T. Li, "An Architecture for IP Address
Allocation with CIDR", RFC 1518, September 1993.
[RFC1518] Rekhter、Y.、およびT.李、「CIDRとのIPアドレス配分のための構造」、RFC1518、1993年9月。
[RFC1771]
Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
1995年の[RFC1771]Rekhter、Y.、およびT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。
[RFC1773]
Hanks, S., Li, T., Farinacci, T., and P. Traina, "Generic
Routing Encapsulation over IPv4 networks", RFC 1773, October
1994.
1994年10月の[RFC1773]ハンクスとS.と李とT.とファリナッチ、T.とP.Traina、「IPv4ネットワークの上の一般的なルート設定Encapsulation」RFC1773。
[RFC1918]
Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot G.J., and
E. Lear, "Address Allocation for Private Internets", RFC 1918,
February 1996.
[RFC1918]RekhterとY.とマスコウィッツとB.とKarrenbergとD.、deグルートG.J.とE.リア、「個人的なインターネットのためのアドレス配分」RFC1918(1996年2月)。
[RFC1997]
Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute",
RFC 1997, August 1996.
[RFC1997] チャンドラとR.とTraina、P.とT.李、「BGP共同体属性」、RFC1997、1996年8月。
[RFC2008]
Rekhter, Y., and T. Li, "Implications of Various Address
Allocation Policies for Internet Routing", BCP 7, RFC 2008,
October 1996.
[RFC2008] Rekhter、Y.、およびT.李、「様々の含意はインターネットルート設定のための配分方針を記述します」、BCP7、RFC2008、1996年10月。
Bates & Rekhter Informational [Page 10] RFC 2260 Multihoming January 1998
[10ページ]RFC2260マルチホーミング1998年1月の情報のベイツとRekhter
12. Authors' Addresses
12. 作者のアドレス
Tony Bates Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
トニーベイツシスコシステムズInc.170の西タスマン・Driveサンノゼ、カリフォルニア 95134
EMail: tbates@cisco.com
メール: tbates@cisco.com
Yakov Rekhter Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 EMail: yakov@cisco.com
ヤコフRekhterシスコシステムズInc.170の西タスマン・Driveサンノゼ、カリフォルニア 95134はメールされます: yakov@cisco.com
Bates & Rekhter Informational [Page 11] RFC 2260 Multihoming January 1998
[11ページ]RFC2260マルチホーミング1998年1月の情報のベイツとRekhter
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Bates & Rekhter Informational [Page 12]
ベイツとRekhter情報です。[12ページ]
一覧
スポンサーリンク
