RFC1774 日本語訳
1774 BGP-4 Protocol Analysis. P. Traina, Ed.. March 1995. (Format: TXT=23823 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Traina, Editor Request for Comments: 1774 cisco Systems Category: Informational March 1995
ワーキンググループP.Traina、コメントを求めるエディタ要求をネットワークでつないでください: 1774年のコクチマスSystems Category: 情報の1995年3月
BGP-4 Protocol Analysis
BGP-4プロトコル分析
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Introduction
序論
The purpose of this report is to document how the requirements for advancing a routing protocol to Draft Standard have been satisfied by the Border Gateway Protocol version 4 (BGP-4). This report summarizes the key features of BGP, and analyzes the protocol with respect to scaling and performance. This is the first of two reports on the BGP protocol.
このレポートの目的はボーダ・ゲイトウェイ・プロトコルバージョン4(BGP-4)によってルーティング・プロトコルをDraft Standardに唱えるための要件がどう満たされたかを記録することです。 このレポートは、BGPに関する重要な特色をまとめて、スケーリングと性能に関してプロトコルを分析します。 これはBGPプロトコルに関する2つのレポートの1番目です。
BGP-4 is an inter-autonomous system routing protocol designed for TCP/IP internets. Version 1 of the BGP protocol was published in RFC 1105. Since then BGP versions 2, 3, and 4 have been developed. Version 2 was documented in RFC 1163. Version 3 is documented in RFC1267. The changes between versions are explained in Appendix 2 of [1].
BGP-4はTCP/IPインターネットのために設計された相互自律システムルーティング・プロトコルです。 BGPプロトコルのバージョン1はRFC1105で発行されました。 それ以来、BGPバージョン2、3、および4を開発してあります。 バージョン2はRFC1163に記録されました。 バージョン3はRFC1267に記録されます。 バージョンの間の変化は[1]のAppendix2で説明されます。
Possible applications of BGP in the Internet are documented in [2].
インターネットのBGPの可能なアプリケーションは[2]に記録されます。
Please send comments to iwg@ans.net.
コメントを iwg@ans.net に送ってください。
Key features and algorithms of the BGP-4 protocol.
BGP-4の重要な特色とアルゴリズムは議定書を作ります。
This section summarizes the key features and algorithms of the BGP protocol. BGP is an inter-autonomous system routing protocol; it is designed to be used between multiple autonomous systems. BGP assumes that routing within an autonomous system is done by an intra- autonomous system routing protocol. BGP does not make any assumptions about intra-autonomous system routing protocols employed by the various autonomous systems. Specifically, BGP does not require all autonomous systems to run the same intra-autonomous system routing protocol.
このセクションはBGPプロトコルの重要な特色とアルゴリズムをまとめます。 BGPは相互自律システムルーティング・プロトコルです。 それは、複数の自律システムの間で使用されるように設計されています。BGPは、自律システムの中でイントラ自律システムルーティング・プロトコルでルーティングすると仮定します。 BGPは様々な自律システムでイントラ自律システムルーティング・プロトコルに関するどんな仮定も使わせません。明確に、BGPは、同じイントラ自律システムルーティング・プロトコルを走らせるためにすべての自律システムを必要とするというわけではありません。
BGP is a real inter-autonomous system routing protocol. It imposes no constraints on the underlying Internet topology. The information exchanged via BGP is sufficient to construct a graph of autonomous systems connectivity from which routing loops may be pruned and some
BGPは本当の相互自律システムルーティング・プロトコルです。 それは基本的なインターネットトポロジーに規制を全く課しません。 BGPを通して交換された情報は、ルーティング輪余計なものを取り除かれるかもしれない自律システムの接続性といくつかのグラフを作図するために十分です。
Traina [Page 1] RFC 1774 BGP-4 Protocol Analysis March 1995
Traina[1ページ]RFC1774BGP-4は1995年の分析行進のときに議定書を作ります。
routing policy decisions at the autonomous system level may be enforced.
自律システムレベルにおけるルーティング政策決定は励行されるかもしれません。
The key features of the protocol are the notion of path attributes and aggregation of network layer reachability information (NLRI).
プロトコルに関する重要な特色は、経路属性の概念とネットワーク層可到達性情報(NLRI)の集合です。
Path attributes provide BGP with flexibility and expandability. Path attributes are partitioned into well-known and optional. The provision for optional attributes allows experimentation that may involve a group of BGP routers without affecting the rest of the Internet. New optional attributes can be added to the protocol in much the same fashion as new options are added to the Telnet protocol, for instance.
経路属性は柔軟性と拡張可能性をBGPに提供します。 経路属性は周知で任意に仕切られます。 任意の属性への支給はインターネットの残りに影響しないでBGPルータのグループにかかわるかもしれない実験を許します。 例えば、新しいオプションがTelnetプロトコルに追加されるような似たり寄ったりのファッションで新しい任意の属性をプロトコルに追加できます。
One of the most important path attributes is the AS-PATH. AS reachability information traverses the Internet, this information is augmented by the list of autonomous systems that have been traversed thus far, forming the AS-PATH. The AS-PATH allows straightforward suppression of the looping of routing information. In addition, the AS-PATH serves as a powerful and versatile mechanism for policy-based routing.
最も重要な経路属性の1つはAS-PATHです。 AS可到達性情報はインターネットを横断して、この情報はこれまでのところ横断された自律システムのリストによって増大させられます、AS-PATHを形成して。 AS-PATHはルーティング情報のループの簡単な抑圧を許します。 さらに、AS-PATHは方針ベースのルーティングのための強力で多能なメカニズムとして機能します。
BGP-4 enhances the AS-PATH attribute to include sets of autonomous systems as well as lists. This extended format allows generated aggregate routes to carry path information from the more specific routes used to generate the aggregate.
BGP-4は、リストと同様に自律システムのセットを含むようにAS-PATH属性を高めます。 この拡張フォーマットで、発生している集合ルートは集合を発生させるのに使用されるより特定のルートから経路情報を運ぶことができます。
BGP uses an algorithm that cannot be classified as either a pure distance vector, or a pure link state. Carrying a complete AS path in the AS-PATH attribute allows to reconstruct large portions of the overall topology. That makes it similar to the link state algorithms. Exchanging only the currently used routes between the peers makes it similar to the distance vector algorithms.
BGPは純粋な距離ベクトルか純粋なリンク状態のどちらかとして分類できないアルゴリズムを使用します。 AS-PATH属性における経路で総合的なトポロジーの大半を再建する完全なASを運びます。 それで、それはリンク州のアルゴリズムと同様になります。同輩の間の現在中古のルートだけを交換するのに、距離ベクトルアルゴリズムと同様になります。
To conserve bandwidth and processing power, BGP uses incremental updates, where after the initial exchange of complete routing information, a pair of BGP routers exchanges only changes (deltas) to that information. Technique of incremental updates requires reliable transport between a pair of BGP routers. To achieve this functionality BGP uses TCP as its transport.
帯域幅と処理能力を保存するのに、BGPはアップデート増加を使用します、1組のBGPルータが完全なルーティング情報の初期の交換の後にその情報への変化(デルタ)だけを交換するところで。 アップデート増加のテクニックは1組のBGPルータの間の信頼できる輸送を必要とします。 この機能性を達成するために、BGPは輸送としてTCPを使用します。
In addition to incremental updates, BGP-4 has added the concept of route aggregation so that information about groups of networks may represented as a single entity.
アップデート増加に加えて、BGP-4は、単一体として表されて、ネットワークのグループの情報が加えたようにルート集合の概念を加えました。
BGP is a self-contained protocol. That is, it specifies how routing information is exchanged both between BGP speakers in different autonomous systems, and between BGP speakers within a single
BGPは自己充足的なプロトコルです。 すなわち、それはシングルの中で異なった自律システムのBGPスピーカーの間と、そして、BGPスピーカーの間でどうルーティング情報を交換するかを指定します。
Traina [Page 2] RFC 1774 BGP-4 Protocol Analysis March 1995
Traina[2ページ]RFC1774BGP-4は1995年の分析行進のときに議定書を作ります。
autonomous system.
自律システム。
To allow graceful coexistence with EGP and OSPF, BGP provides support for carrying both EGP and OSPF derived exterior routes BGP also allows to carry statically defined exterior routes or routes derived by other IGP information.
EGPとOSPFとの優雅な共存を許容するために、BGPはまたBGPが静的に定義された外のルートを運ばせる外のルートか他のIGP情報によって引き出されたルートをEGPとOSPFが引き出した両方を運ぶサポートに提供します。
BGP performance characteristics and scalability
BGP性能の特性とスケーラビリティ
In this section we'll try to answer the question of how much link bandwidth, router memory and router CPU cycles does the BGP protocol consume under normal conditions. We'll also address the scalability of BGP, and look at some of its limits.
私たちが質問に答えようとするこのセクションでは、BGPプロトコルは正常な状況ではどのくらいのリンク帯域幅、ルータメモリ、およびルータCPUサイクルを費やしますか? 私たちは、また、BGPのスケーラビリティを記述して、限界のいくつかを見るつもりです。
BGP does not require all the routers within an autonomous system to participate in the BGP protocol. Only the border routers that provide connectivity between the local autonomous system and its adjacent autonomous systems participate in BGP. Constraining the set of participants is just one way of addressing the scaling issue.
BGPは、BGPプロトコルに参加するために自律システムの中ですべてのルータを必要とするというわけではありません。 地方の自律システムとその隣接している自律システムの間に接続性を提供する境界ルータだけがBGPに参加します。 関係者のセットを抑制するのはスケーリング問題を記述することにおいてただ一方通行です。
Link bandwidth and CPU utilization
リンク帯域幅とCPU使用率
Immediately after the initial BGP connection setup, the peers exchange complete set of routing information. If we denote the total number of routes in the Internet by N, the mean AS distance of the Internet by M (distance at the level of an autonomous system, expressed in terms of the number of autonomous systems), the total number of autonomous systems in the Internet by A, and assume that the networks are uniformly distributed among the autonomous systems, then the worst case amount of bandwidth consumed during the initial exchange between a pair of BGP speakers is
初期のBGP接続設定直後、同輩は完全なルーティング情報を交換します。 私たちが、Nによるインターネットのルートの総数、M(自律システムの数で言い表された自律システムのレベルにおける距離)のインターネットの平均であるAS距離、Aによるインターネットの自律システムの総数を指示して、ネットワークが自律システムの中で一様に分配されると思うなら、1組のBGPスピーカーの間の初期の交換の間に消費された帯域幅の最悪の場合量はそうです。
MR = O(N + M * A)
さんはOと等しいです。(N+M*a)
The following table illustrates typical amount of bandwidth consumed during the initial exchange between a pair of BGP speakers based on the above assumptions (ignoring bandwidth consumed by the BGP Header).
以下のテーブルは上の仮定に基づく1組のBGPスピーカーの間の初期の交換の間に消費された典型的な量の帯域幅を例証します(BGP Headerによって消費された帯域幅を無視して)。
# NLRI Mean AS Distance # AS's Bandwidth ---------- ---------------- ------ --------- 10,000 15 300 49,000 bytes 20,000 8 400 86,000 bytes * 40,000 15 400 172,000 bytes 100,000 20 3,000 520,000 bytes
# 帯域幅の距離#としてのNLRI平均---------- ---------------- ------ --------- 10,000 15、300、4万9000バイト20,000 8、400、8万6000バイト*40,000 15 400 17万2000バイト100,000 20 3,000 520,000バイト
* the actual "size" of the Internet at the the time of this document's publication
* このドキュメントの公表の時間のインターネットの実際の「サイズ」
Traina [Page 3] RFC 1774 BGP-4 Protocol Analysis March 1995
Traina[3ページ]RFC1774BGP-4は1995年の分析行進のときに議定書を作ります。
Note that most of the bandwidth is consumed by the exchange of the Network Layer Reachability Information (NLRI).
帯域幅の大部分がNetwork Layer Reachability情報(NLRI)の交換で消費されることに注意してください。
BGP-4 was created specifically to reduce the amount of NLRI entries carried and exchanged by border routers. BGP-4, along with CIDR [4] has introduced the concept of the "Supernet" which describes a power-of-two aggregation of more than one class-based network.
BGP-4は、特に境界ルータによって運ばれて、交換されたNLRIエントリーの量を減少させるために作成されました。 BGP-4、CIDRと共に、[4]は1つ以上のクラスを拠点とするネットワークの2のパワー集合について説明する"Supernet"の概念を紹介しました。
Due to the advantages of advertising a few large aggregate blocks instead of many smaller class-based individual networks, it is difficult to estimate the actual reduction in bandwidth and processing that BGP-4 has provided over BGP3. If we simply enumerate all aggregate blocks into their individual class-based networks, we would not take into account "dead" space that has been reserved for future expansion. The best metric for determining the success of BGP-4's aggregation is to sample the number NLRI entries in the globally connected Internet today and compare it to projected growth rates before BGP-4 was deployed.
多くの、より小さいクラスを拠点とする個々のネットワークの代わりに大きい集合数ブロックの広告を出す利点のために、BGP-4がBGP3の上で供給した帯域幅と処理の実際の減少を見積もっているのは難しいです。 単にそれらの個々のクラスを拠点とするネットワークにすべての集合ブロックを数え上げるなら、私たちは今後の拡大のために予約された「死んでいる」スペースを考慮に入れないでしょう。 BGP-4の集合の成功を決定するのにおける、メートル法のベストは、BGP-4が配備される前に、今日、グローバルに接続されたインターネットで数のNLRIエントリーを抽出して、映し出された成長率とそれを比較することです。
In January of 1994, router carrying a full routing load for the globally connected Internet had approximately 19,000 network entries (this number is not exact due to local policy variations). The BGP deployment working group estimated that the growth rate at that time was over 1000 new networks per month and increasing. Since the widespread deployment of BGP-4, the growth rate has dropped significantly and a sample done at the end of November 1994 showed approximately 21,000 entries present, as opposed to the expected 30,000.
1994年1月に、グローバルに接続されたインターネットまで完全なルーティング積載物を運ぶルータがおよそ1万9000のネットワークエントリーを持っていました(この数は地方の方針変化のために正確ではありません)。 BGP展開ワーキンググループは成長率がその時、1カ月あたり1000の新しいネットワークの上にあって、増加していると見積もっていました。 BGP-4の広範囲の展開以来、成長率は著しく低下しています、そして、1994年11月の終わりに行われたサンプルはおよそ2万1000のエントリーが予想と対照的に3万を提示するのを示しました。
CPU cycles consumed by BGP depends only on the stability of the Internet. If the Internet is stable, then the only link bandwidth and router CPU cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE messages. The KEEPALIVE messages are exchanged only between peers. The suggested frequency of the exchange is 30 seconds. The KEEPALIVE messages are quite short (19 octets), and require virtually no processing. Therefore, the bandwidth consumed by the KEEPALIVE messages is about 5 bits/sec. Operational experience confirms that the overhead (in terms of bandwidth and CPU) associated with the KEEPALIVE messages should be viewed as negligible. If the Internet is unstable, then only the changes to the reachability information (that are caused by the instabilities) are passed between routers (via the UPDATE messages). If we denote the number of routing changes per second by C, then in the worst case the amount of bandwidth consumed by the BGP can be expressed as O(C * M). The greatest overhead per UPDATE message occurs when each UPDATE message contains only a single network. It should be pointed out that in practice routing changes exhibit strong locality with respect to the AS path. That is routes that change are likely to have common AS path. In this
BGPによって費やされたCPUサイクルはインターネットの安定性だけに依存します。 インターネットが安定しているなら、BGPによって費やされた唯一のリンク帯域幅とルータCPUサイクルはBGP KEEPALIVEメッセージの交換のためです。 同輩だけの間でKEEPALIVEメッセージを交換します。 交換の提案された頻度は30秒です。 KEEPALIVEメッセージは、かなり短く(19の八重奏)、実際には処理するのを必要としません。 したがって、KEEPALIVEメッセージによって消費された帯域幅はおよそ5ビット/秒です。 運用経験は、KEEPALIVEメッセージに関連しているオーバーヘッド(帯域幅とCPUに関する)が取るにたらないとして見なされるべきであると確認します。 インターネットが不安定であるなら、可到達性情報(それは不安定性によって引き起こされる)への変化だけがルータ(UPDATEメッセージを通した)の間を流れます。 私たちが1秒あたりのルーティング変化の数をCで指示するなら、O(C*M)として最悪の場合にはBGPによって消費された帯域幅の量を表すことができます。 それぞれのUPDATEメッセージがただ一つのネットワークだけを含んでいると、UPDATEメッセージあたりの最もすばらしいオーバーヘッドは起こります。 習慣ルーティングで、変化がAS経路に関して強い場所を示すと指摘されるべきです。 すなわち、変化するルートは一般的なAS経路を持っていそうです。 これで
Traina [Page 4] RFC 1774 BGP-4 Protocol Analysis March 1995
Traina[4ページ]RFC1774BGP-4は1995年の分析行進のときに議定書を作ります。
case multiple networks can be grouped into a single UPDATE message, thus significantly reducing the amount of bandwidth required (see also Appendix 6.1 of [1]).
ケース複数のネットワークをただ一つのUPDATEメッセージに分類できます、その結果、帯域幅の量をかなり減少させるのが必要です。(参照、[1])のAppendix6.1。
Since in the steady state the link bandwidth and router CPU cycles consumed by the BGP protocol are dependent only on the stability of the Internet, but are completely independent on the number of networks that compose the Internet, it follows that BGP should have no scaling problems in the areas of link bandwidth and router CPU utilization, as the Internet grows, provided that the overall stability of the inter-AS connectivity (connectivity between ASs) of the Internet can be controlled. Stability issue could be addressed by introducing some form of dampening (e.g., hold downs). Due to the nature of BGP, such dampening should be viewed as a local to an autonomous system matter (see also Appendix 6.3 of [1]). It is important to point out, that regardless of BGP, one should not underestimate the significance of the stability in the Internet.
BGPプロトコルによって費やされたリンク帯域幅とルータCPUサイクルが定常状態では、インターネットの安定性だけに依存していますが、インターネットを構成するネットワークの数で完全に独立しているので、BGPがリンク帯域幅とルータCPU利用の領域にスケーリング問題を全く持っているはずがないということになります、インターネットが発展するとき、インターネットの相互ASの接続性(ASsの間の接続性)の総合的な安定性を制御できれば。 何らかのフォームの湿り(例えば、抑制)を導入することによって、安定性問題を記述できるでしょう。 BGPの自然のため、そのような湿りはローカルとして自律システムの件に見なされるべきです。(参照、[1])のAppendix6.3。 それが指摘するために重要である、BGP、1にかかわらずそれはインターネットで安定性の意味を過小評価するべきではありません。
Growth of the Internet has made the stability issue one of the most crucial ones. It is important to realize that BGP, by itself, does not introduce any instabilities in the Internet. Current observations in the NSFNET show that the instabilities are largely due to the ill-behaved routing within the autonomous systems that compose the Internet. Therefore, while providing BGP with mechanisms to address the stability issue, we feel that the right way to handle the issue is to address it at the root of the problem, and to come up with intra-autonomous routing schemes that exhibit reasonable stability.
インターネットの成長は安定性問題を最も重要なものの1つにしました。 BGP自身がインターネットにおける少しの不安定性も導入しないとわかるのは重要です。 NSFNETの海流観測は、不安定性が主にインターネットを構成する自律システムの中の無作法なルーティングのためであることを示します。 したがって、安定性問題を記述するためにメカニズムをBGPに提供している間、私たちは、問題を扱う正しい方法が問題の本質でそれを記述して、妥当な安定性を示すイントラ自治のルーティング計画を思いつくことであると感じます。
It also may be instructive to compare bandwidth and CPU requirements of BGP with EGP. While with BGP the complete information is exchanged only at the connection establishment time, with EGP the complete information is exchanged periodically (usually every 3 minutes). Note that both for BGP and for EGP the amount of information exchanged is roughly on the order of the networks reachable via a peer that sends the information (see also Section 5.2). Therefore, even if one assumes extreme instabilities of BGP, its worst case behavior will be the same as the steady state behavior of EGP.
また、BGPの帯域幅とCPU要件をEGPと比べるのもためになっているかもしれません。 単にコネクション確立時にBGPと共に完全な情報を交換しますが、EGPと共に、完全な情報を定期的(通常3分毎)に交換します。 情報を送る同輩を通して届いているネットワークの注文のときにBGPと交換された情報の量のEGPのためのそれがおよそそうであることに注意してください(また、セクション5.2を見てください)。 したがって、人がBGPの極端な不安定性を仮定しても、最悪の場合の振舞いはEGPの定常状態動きと同じになるでしょう。
Operational experience with BGP showed that the incremental updates approach employed by BGP presents an enormous improvement both in the area of bandwidth and in the CPU utilization, as compared with complete periodic updates used by EGP (see also presentation by Dennis Ferguson at the Twentieth IETF, March 11-15, 1991, St.Louis).
BGPの運用経験は、BGPによって使われたアップデート増加アプローチが帯域幅の領域とCPU使用率における莫大な改良を提示するのを示しました、EGPによって使用される完全な周期的なアップデートと比べて(また、Twentieth IETFのデニスファーガソンによるプレゼンテーションを見てください、1991年3月11日〜15日、セントルイス)。
Traina [Page 5] RFC 1774 BGP-4 Protocol Analysis March 1995
Traina[5ページ]RFC1774BGP-4は1995年の分析行進のときに議定書を作ります。
Memory requirements
メモリ要件
To quantify the worst case memory requirements for BGP, denote the total number of networks in the Internet by N, the mean AS distance of the Internet by M (distance at the level of an autonomous system, expressed in terms of the number of autonomous systems), the total number of autonomous systems in the Internet by A, and the total number of BGP speakers that a system is peering with by K (note that K will usually be dominated by the total number of the BGP speakers within a single autonomous system). Then the worst case memory requirements (MR) can be expressed as
BGPのための最悪の場合メモリ要件を定量化するには、Nによるインターネットのネットワークの総数、M(自律システムの数で言い表された自律システムのレベルにおける距離)のインターネットの平均であるAS距離、Aによるインターネットの自律システムの総数、およびKでシステムとじっと見ているBGPスピーカーの総数を指示してください(通常、Kが単一の自律システムの中でBGPスピーカーの総数によって支配されることに注意してください)。 そして、メモリ要件(MR)を言い表すことができる最悪の場合
MR = O((N + M * A) * K)
さんはOと等しいです。(N+M*a)*K)
In the current NSFNET Backbone (N = 2110, A = 59, and M = 5) if each network is stored as 4 octets, and each autonomous system is stored as 2 octets then the overhead of storing the AS path information (in addition to the full complement of exterior routes) is less than 7 percent of the total memory usage.
現在のNSFNET Backbone(N=2110、A=59、およびM=5)では、各ネットワークが4つの八重奏として格納されて、各自律システムが2つの八重奏として格納されるなら、AS経路情報(外のルートの総定員に加えた)を格納するオーバーヘッドは総メモリ使用量の7パーセント未満です。
It is interesting to point out, that prior to the introduction of BGP in the NSFNET Backbone, memory requirements on the NSFNET Backbone routers running EGP were on the order of O(N * K). Therefore, the extra overhead in memory incurred by the NSFNET routers after the introduction of BGP is less than 7 percent.
それは指摘するためにおもしろく、NSFNET BackboneでのBGPの導入の前に、O(N*K)の注文にはEGPを走らせるNSFNET Backboneルータに関するメモリ要件がありました。 したがって、BGPの導入の後にNSFNETルータによって被られたメモリにおける余分なオーバーヘッドは7パーセント未満です。
Since a mean AS distance grows very slowly with the total number of networks (there are about 60 autonomous systems, well over 2,000 networks known in the NSFNET backbone routers, and the mean AS distance of the current Internet is well below 5), for all practical purposes the worst case router memory requirements are on the order of the total number of networks in the Internet times the number of peers the local system is peering with. We expect that the total number of networks in the Internet will grow much faster than the average number of peers per router. Therefore, scaling with respect to the memory requirements is going to be heavily dominated by the factor that is linearly proportional to the total number of networks in the Internet.
平均であるAS距離が非常にゆっくり成長するので、ネットワーク(NSFNET背骨ルータで知られている2,000のネットワークのかなり上におよそ60の自律システムがあります、そして、現在のインターネットの平均であるAS距離が5のかなり下にある)の総数、実際上は最悪の場合ルータメモリ要件と共に、インターネット回のネットワークの総数の注文にはローカルシステムとじっと見ている同輩の数があります。 私たちは、インターネットのネットワークの総数が1ルータあたりの同輩の平均した数よりはるかに速くなると予想します。 したがって、メモリ要件に関して比例するのはインターネットのネットワークの総数に比例している直線的である要素によって大いに支配されるでしょう。
The following table illustrates typical memory requirements of a router running BGP. It is assumed that each network is encoded as 4 bytes, each AS is encoded as 2 bytes, and each networks is reachable via some fraction of all of the peers (# BGP peers/per net).
以下のテーブルは、BGPを走らせながら、ルータの典型的なメモリ要件を例証します。 各ネットワークが4バイト、各ASが2バイトとしてコード化されるのでそれぞれコード化されて、ネットワークが同輩(1ネットあたりの#BGP同輩/)のすべてのある部分を通して届いているということであると思われます。
Traina [Page 6] RFC 1774 BGP-4 Protocol Analysis March 1995
Traina[6ページ]RFC1774BGP-4は1995年の分析行進のときに議定書を作ります。
# Networks Mean AS Distance # AS's # BGP peers/per net Memory Req ---------- ---------------- ------ ------------------- ---------- 2,100 5 59 3 27,000 4,000 10 100 6 108,000 10,000 15 300 10 490,000 100,000 20 3,000 20 1,040,000
# Mean AS Distance#AS#のネットのMemory ReqあたりのBGP同輩/をネットワークでつなぎます。---------- ---------------- ------ ------------------- ---------- 2,100 5 59 3 27,000 4,000 10 100 6 108,000 10,000 15 300 10 490,000 100,000 20 3,000 20 1,040,000
To put memory requirements of BGP in a proper perspective, let's try to put aside for a moment the issue of what information is used to construct the forwarding tables in a router, and just focus on the forwarding tables themselves. In this case one might ask about the limits on these tables. For instance, given that right now the forwarding tables in the NSFNET Backbone routers carry well over 20,000 entries, one might ask whether it would be possible to have a functional router with a table that will have 200,000 entries. Clearly the answer to this question is completely independent of BGP. On the other hand the answer to the original questions (that was asked with respect to BGP) is directly related to the latter question. Very interesting comments were given by Paul Tsuchiya in his review of BGP in March of 1990 (as part of the BGP review committee appointed by Bob Hinden). In the review he said that, "BGP does not scale well. This is not really the fault of BGP. It is the fault of the flat IP address space. Given the flat IP address space, any routing protocol must carry network numbers in its updates." With the introduction of CIDR [4] and BGP-4, we have attempted to reduce this limitation. Unfortunately, we cannot erase history nor can BGP-4 solve the problems inherent with inefficient assignment of future address blocks.
BGPのメモリ要件を適切な見解に入れるために、ちょっとどんな情報がルータで推進テーブルを組み立てるのに使用されるかに関する問題、およびまさしく推進テーブル自体の焦点を中断するのを試みましょう。 この場合、人はこれらのテーブルで限界に関して尋ねるかもしれません。 例えば、NSFNET Backboneルータにおける推進テーブルがたった今はるかに2万以上のエントリーを運ぶなら、人は、20万のエントリーを持っているテーブルで機能的なルータを持っているのが可能であるかどうか尋ねるかもしれません。 明確に、この質問の答えはBGPから完全に独立しています。 他方では、独創的な質問(それはBGPに関して尋ねられた)の答えは直接後者の質問に関連します。 非常におもしろいコメントは1990(ボブHindenによって任命されたBGP再調査委員会の一部としての)年3月の彼のBGPのレビューでポールTsuchiyaによって与えられました。 レビューでは、彼がそれを言った、「BGPはよく比例しません」。 これは本当にBGPのせいではありません。 それは平坦なIPアドレス空間のせいです。 「平坦なIPアドレス空間を考えて、どんなルーティング・プロトコルもアップデートにおけるネットワーク・ナンバーを運ばなければなりません。」 CIDR[4]とBGP-4の導入で、私たちは、この制限を抑えるのを試みました。 残念ながら、私たちは歴史を消すことができません、そして、BGP-4は将来のあて先ブロックの効率の悪い課題で固有の問題を解決できません。
To reiterate, BGP limits with respect to the memory requirements are directly related to the underlying Internet Protocol (IP), and specifically the addressing scheme employed by IP. BGP would provide much better scaling in environments with more flexible addressing schemes. It should be pointed out that with only very minor additions BGP was extended to support hierarchies of autonomous system [8]. Such hierarchies, combined with an addressing scheme that would allow more flexible address aggregation capabilities, can be utilized by BGP-like protocols, thus providing practically unlimited scaling capabilities.
繰り返すために関連する、メモリ要件に関するBGP限界は直接基本的なインターネットプロトコル(IP)、および明確にIPによって使われたアドレシング計画に関連します。 BGPは、環境を計量するほうがよいのをよりフレキシブルなアドレシング計画を提供するでしょう。 非常に小さい方の追加だけで、BGPが自律システム[8]の階層構造をサポートするために広げられたと指摘されるべきです。 BGPのようなプロトコルでそのようなよりフレキシブルなアドレス集合能力を許容するアドレシング計画に結合した階層構造は利用できます、その結果、実際に無制限なスケーリング能力を提供します。
Applicability of BGP
BGPの適用性
In this section we'll try to answer the question of what environment is BGP well suited, and for what is it not suitable? Partially this question is answered in the Section 2 of [1], where the document states the following:
私たちがどんな環境がよく合うBGPであり、何のためのそれであるかに関する適当でない質問に答えようとするこのセクションで? 部分的に、この質問はドキュメントが以下を述べる[1]のセクション2で答えられます:
Traina [Page 7] RFC 1774 BGP-4 Protocol Analysis March 1995
Traina[7ページ]RFC1774BGP-4は1995年の分析行進のときに議定書を作ります。
"To characterize the set of policy decisions that can be enforced using BGP, one must focus on the rule that an AS advertises to its neighbor ASs only those routes that it itself uses. This rule reflects the "hop-by-hop" routing paradigm generally used throughout the current Internet. Note that some policies cannot be supported by the "hop-by-hop" routing paradigm and thus require techniques such as source routing to enforce. For example, BGP does not enable one AS to send traffic to a neighbor AS intending that the traffic take a different route from that taken by traffic originating in the neighbor AS. On the other hand, BGP can support any policy conforming to the "hop-by-hop" routing paradigm. Since the current Internet uses only the "hop-by-hop" routing paradigm and since BGP can support any policy that conforms to that paradigm, BGP is highly applicable as an inter-AS routing protocol for the current Internet."
「BGP、1を使用することで励行されることができる政策決定のセットを特徴付けるのはASがそれ自体が使用するそれらのルートの隣人ASsだけに広告を出すという規則に焦点を合わせなければなりません。」 この規則は一般に、現在のインターネット中で使用される「ホップごとの」ルーティングパラダイムを反映します。 いくつかの方針が「ホップごとの」ルーティングパラダイムによってサポートされて、その結果、実施するソースルーティングなどのテクニックを必要とすることができないことに注意してください。 例えば、BGPは、1ASが交通が隣人ASで起こる交通で取られたそれと異なったルートを取ることを意図する隣人ASに交通を送るのを可能にしません。 他方では、BGPは「ホップごとの」ルーティングパラダイムに従うどんな方針も支持できます。 「現在のインターネットが「ホップごとの」ルーティングパラダイムだけを使用して、BGPがそのパラダイムに従うどんな方針も支持できるので、BGPは現在のインターネットへの相互ASルーティング・プロトコルとして非常に適切です。」
While BGP is well suitable for the current Internet, it is also almost a necessity for the current Internet as well. Operational experience with EGP showed that it is highly inadequate for the current Internet. Topological restrictions imposed by EGP are unjustifiable from the technical point of view, and unenforceable from the practical point of view. Inability of EGP to efficiently handle information exchange between peers is a cause of severe routing instabilities in the operational Internet. Finally, information provided by BGP is well suitable for enforcing a variety of routing policies.
BGPは現在のインターネットに十分適していますが、それはほとんどもまた、現在のインターネットの必要性です。 EGPの運用経験は、それが現在のインターネットに非常に不十分であることを示しました。 EGPによって課された位相的な制限は、技術的な観点から道理に合わなく、実用的な観点から「非-実施でき」されます。 EGPが効率的に同輩の間の情報交換を扱うことができないことは操作上のインターネットにおける厳しいルーティングの不安定性の原因です。 最終的に、BGPによって提供された情報はさまざまなルーティング方針を実施するのに十分適当です。
Rather than trying to predict the future, and overload BGP with a variety of functions that may (or may not) be needed, the designers of BGP took a different approach. The protocol contains only the functionality that is essential, while at the same time provides flexible mechanisms within the protocol itself that allow to expand its functionality. Since BGP was designed with flexibility and expandability in mind, we think it should be able to address new or evolving requirements with relative ease. The existence proof of this statement may be found in the way how new features (like repairing a partitioned autonomous system with BGP) are already introduced in the protocol.
または、そうするかもしれないさまざまな機能で未来について予言して、BGPを積みすぎようとするよりむしろ、()、必要です、BGPのデザイナーがa異なるアプローチを取ったということになるかもしれなくなってください。 プロトコルは不可欠の機能性だけを含んでいます、それ自体で機能性を広げるプロトコルの中のフレキシブルなメカニズムが同時に、提供されますが。 BGPが柔軟性と拡張可能性で念頭に設計されたので、私たちは、それが相対的な容易さで新しいか発展している要件を記述できるべきであると思います。 この声明の存在証拠は新機能(BGPと共に仕切られた自律システムを修理するような)がプロトコルで既に導入される方法で見つけられるかもしれません。
To summarize, BGP is well suitable as an inter-autonomous system routing protocol for the current Internet that is based on IP (RFC 791) as the Internet Protocol and "hop-by-hop" routing paradigm. It is hard to speculate whether BGP will be suitable for other environments where internetting is done by other than IP protocols, or where the routing paradigm will be different.
まとめるために適当である、BGPはインターネットプロトコルと「ホップごとの」ルーティングパラダイムとしてIP(RFC791)に基づいている現在のインターネットへの相互自律システムルーティング・プロトコルとして十分適当です。 ルーティングパラダイムがどこでBGPがIPプロトコルを除いて、internettingが行われる他の環境に適するかどうか、または異なるようになるかを推測しにくいです。
Traina [Page 8] RFC 1774 BGP-4 Protocol Analysis March 1995
Traina[8ページ]RFC1774BGP-4は1995年の分析行進のときに議定書を作ります。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Acknowledgments
承認
The BGP-4 protocol has been developed by the IDR/BGP Working Group of the Internet Engineering Task Force. I would like to express thanks to Yakov Rekhter for providing RFC 1265. This document is only a minor update to the original text. I'd also like to explicitly thank Yakov Rekhter and Tony Li for their review of this document as well as their constructive and valuable comments.
BGP-4プロトコルはインターネット・エンジニアリング・タスク・フォースのIDR/BGP作業部会によって開発されました。 ヤコフのおかげでRFC1265を提供するためにRekhterを急送したいと思います。 このドキュメントは原本への小さい方の最新版にすぎません。 また、彼らの彼らの建設的で貴重なコメントと同様にこのドキュメントのレビューについて明らかにヤコフRekhterとトニー・李に感謝申し上げます。
Editor's Address
エディタのアドレス
Paul Traina cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134
サンノゼ、ポールTrainaコクチマスSystems Inc.170W.タスマン博士カリフォルニア 95134
EMail: pst@cisco.com
メール: pst@cisco.com
Traina [Page 9] RFC 1774 BGP-4 Protocol Analysis March 1995
Traina[9ページ]RFC1774BGP-4は1995年の分析行進のときに議定書を作ります。
References
参照
[1] Rekhter, Y., and T., Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, T.J. Watson Research Center, IBM Corp., cisco Systems, March 1995.
[1] Rekhter、Y.、およびT.、李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」RFC1771、T.J.ワトソン研究所、IBM社、コクチマスSystems(1995年3月)。
[2] Rekhter, Y., and P. Gross, Editors, "Application of the Border Gateway Protocol in the Internet", RFC 1772, T.J. Watson Research Center, IBM Corp., MCI, March 1995.
[2] Rekhter、Y.と総計のP.エディターズ、「インターネットでのボーダ・ゲイトウェイ・プロトコルの応用」RFC1772、T.J.ワトソン研究所、IBM社、MCI(1995年3月)。
[3] Willis, S., Burruss, J., and J. Chu, "Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2", RFC 1657, Wellfleet Communications Inc., IBM Corp., July 1994.
[3] ウィリス、S.、Burruss、J.、およびJ.チュウ、「SMIv2"を使用して、境界ゲートウェイの第4バージョンのための管理オブジェクトの定義は(BGP-4)について議定書の中で述べます、RFC1657、WellfleetコミュニケーションInc.、IBM社、1994年7月」。
[4] Fuller V., Li. T., Yu J., and K. Varadhan, "Classless Inter- Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, BARRNet, cisco, MERIT, OARnet, September 1993.
[4] フラーV.、李。 T.、ユーJ.、およびK.Varadhan、「以下を掘る(CIDR)階級のない相互ドメイン」 「Address AssignmentとAggregation Strategy」、RFC1519、BARRNet、コクチマス、MERIT、OARnet、9月1993日
[6] Moy J., "Open Shortest Path First Routing Protocol (Version 2)", RFC 1257, Proteon, August 1991.
[6]Moy J.、「開いている最短パス優先ルーティングプロトコル(バージョン2)」、RFC1257、Proteon、1991年8月。
[7] Varadhan, K., Hares S., and Y. Rekhter, "BGP4/IDRP for IP---OSPF Interaction", Work in Progress.
[7]Varadhan、K.、野兎S.、およびY.Rekhter、「IPのためのBGP4/IDRP」---「OSPF相互作用」、処理中の作業。
[8] ISO/IEC 10747, Kunzinger, C., Editor, "Inter-Domain Routing Protocol", October 1993.
[8] ISO/IEC10747、Kunzinger、C.、エディタ、「相互ドメインルーティング・プロトコル」、1993年10月。
Traina [Page 10]
Traina[10ページ]
一覧
スポンサーリンク