Network Working Group G. Huston
Request for Comments: 3221 Internet Architecture Board
Category: Informational December 2001
Commentary on
Inter-Domain Routing in the Internet
Status of this 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 (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document examines the various longer term trends visible within the characteristics of the Internet's BGP table and identifies a number of operational practices and protocol factors that contribute to these trends. The potential impacts of these practices and protocol properties on the scaling properties of the inter-domain routing space are examined.
このドキュメントはインターネットのBGPテーブルの特性内に見える様々な長期的な傾向を調べて、これらの傾向に貢献する業務慣行およびプロトコルの多くの要因を特定します。ドメイン間ルーティング空間のスケール特性上のこれらの慣行とプロトコル特性の潜在的な影響について検討されています。
This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board.
このドキュメントはインターネットアーキテクチャ委員会の一部に関する共同運動の成果です。
Table of Contents
目次
1. Introduction................................................. 2
2. Network Scaling and Inter-Domain Routing ................... 2
3. Measurements of the total size of the BGP Table ............ 4
4. Related Measurements derived from BGP Table ................ 7
5. Current State of inter-AS routing in the Internet .......... 11
6. Future Requirements for the Exterior Routing System ........ 14
7. Architectural Approaches to a scalable Exterior
Routing Protocol........................................... 15
8. Directions for Further Activity ............................ 21
9. Security Considerations .................................... 22
10. References ................................................. 23
11. Acknowledgements ........................................... 24
12. Author's Address ........................................... 24
13. Full Copyright Statement ................................... 25
This document examines the various longer term trends visible within the characteristics of the Internet's BGP table and identifies a number of operational practices and protocol factors that contribute to these trends. The potential impacts of these practices and protocol properties on the scaling properties of the inter-domain routing space are examined.
このドキュメントはインターネットのBGPテーブルの特性内に見える様々な長期的な傾向を調べて、これらの傾向に貢献する業務慣行およびプロトコルの多くの要因を特定します。ドメイン間ルーティング空間のスケール特性上のこれらの慣行とプロトコル特性の潜在的な影響について検討されています。
These impacts include the potential for exhaustion of the existing Autonomous System number space, increasing convergence times for selection of stable alternate paths following withdrawal of route announcements, the stability of table entries, and the average prefix length of entries in the BGP table. The larger long term issue is that of an increasingly denser inter-connectivity mesh between ASes, causing a finer degree of granularity of inter-domain policy and finer levels of control to undertake inter-domain traffic engineering.
これらの影響は、ルートアナウンス、テーブルエントリの安定性、およびBGPテーブル内のエントリの平均プレフィックス長の中止後に安定な代替パスを選択するための収束時間を増大させる、既存の自律システム番号空間の枯渇の可能性を含みます。大きな長期的な問題は、ドメイン間のトラフィックエンジニアリングを行うための制御のドメイン間ポリシーとより細かいレベルの粒度の細かい度を引き起こし、そのAS間ますます高密度の相互接続性のメッシュです。
Various approaches to a refinement of the inter-domain routing protocol and associated operating practices that may provide superior scaling properties are identified as an area for further investigation.
ドメイン間ルーティングプロトコルの改良と優れたスケーリング特性を提供することができる関連事業慣行に種々のアプローチが、さらなる調査のための領域として同定されています。
This document is the outcome of a collaborative exercise on the part of the Internet Architecture Board.
このドキュメントはインターネットアーキテクチャ委員会の一部に関する共同運動の成果です。
Are there inherent scaling limitations in the technology of the Internet or its architecture of deployment that may impact on the ability of the Internet to meet escalating levels of demand? There are a number of potential areas to search for such limitations. These include the capacity of transmission systems, packet switching capacity, the continued availability of protocol addresses, and the capability of the routing system to produce a stable view of the overall topology of the network. In this study we will look at this latter capability with the objective of identifying some aspects of the scaling properties of the Internet's routing system.
需要の高まりレベルを満たすために、インターネットの能力に影響を与える可能性があり、インターネットの技術や展開のそのアーキテクチャであり、固有のスケーリング制限はありますか？そのような制限を検索する可能性領域の数があります。これらは、伝送システムの容量、パケット交換容量、プロトコルアドレスの継続的な可用性、およびネットワーク全体のトポロジーの安定したビューを生成するために、ルーティングシステムの能力を含みます。本研究では、インターネットのルーティングシステムのスケーリング特性のいくつかの側面を特定する目的で、この後者の機能を見ていきます。
The basic structure of the Internet is a collection of networks, or Autonomous Systems (ASes) that are interconnected to form a connected domain. Each AS uses an interior routing system to maintain a coherent view of the topology within the AS, and uses an exterior routing system to maintain adjacency information with neighboring ASes to create a view of the connectivity of the entire system.
インターネットの基本的な構造は、接続されたドメインを形成するように相互接続されたネットワークの集合、または自律システム（のAS）です。各ASは、AS内のトポロジのコヒーレントビューを維持するために内部ルーティングシステムを使用して、システム全体の接続のビューを作成するために、隣接のASと隣接情報を維持するために、外部ルーティングシステムを使用します。
This network-wide connectivity is described in the routing table used by the BGP4 protocol (referred to as the Routing Information Base, or RIB). Each entry in the table refers to a distinct route. The attributes of the route, together with local policy constraints, are used to determine the best path from the local AS to the AS that is originating the route. Determining the 'best path' in this case is determining which routing advertisement and associated next hop address is the most preferred by the local AS. Within each local BGP-speaking router this preferred route is then loaded into the local RIB (Loc-RIB). This information is coupled with information obtained from the local instance of the interior routing protocol to form a Forwarding Information Base (or FIB), for use by the local router's forwarding engine.
このネットワーク全体の接続は（ルーティング情報ベース、またはRIBとも呼ばれる）BGP4プロトコルによって使用されるルーティングテーブルに記載されています。テーブル内の各エントリは、異なる経路を指します。一緒にローカルポリシー制約を持つルートの属性は、ルートを発信しているASへのローカルASから最適なパスを決定するために使用されています。この場合には「最良のパス」を決定することは、ルーティング広告と関連したネクストホップアドレスが最もローカルASによって好まれるかを決定しています。各ローカルBGP圏ルータ内のこの好ましい経路は、ローカルRIB（LOC-RIB）にロードされます。この情報は、ローカルルータのフォワーディングエンジンで使用するために、転送情報ベース（またはFIB）を形成する内部ルーティングプロトコルのローカルインスタンスから得られた情報と結合されます。
The BGP routing system is not aware of finer level of topology of the network on a link-by-link basis within the local AS or within any remote AS. From this perspective BGP can be seen as an inter-AS connectivity maintenance protocol, as distinct from a link-level topology management protocol, and the BGP routing table can be viewed as a description of the current connectivity of the Internet using an AS as the basic element of connectivity computation.
BGPルーティングシステムは、ローカルAS内またはリモートAS内のリンク・バイ・リンクに基づいてネットワークのトポロジのより細かいレベルを認識していません。リンクレベルトポロジ管理プロトコル、およびBGPルーティングテーブルとは別個に限り使用して、インターネットの現在の接続の説明と見なすことができ、この観点からBGPは、AS間の接続維持プロトコルとして見ることができます接続計算の基本的な要素。
There is an associated dimension of policy determination within the routing table. If an AS advertises a route to a neighboring AS, the local AS is offering to accept traffic from the neighboring AS which is ultimately destined to addresses described by the advertised routing entry. If the local AS does not originate the route, then the inference is that the local AS is willing to undertake the role of transit provider for this traffic on behalf of some third party. Similarly, an AS may or may not choose to accept a route from a neighbor. Accepting a route implies that under some circumstances, as determined by the local route selection parameters, the local AS will use the neighboring AS to reach addresses spanned by the route. The BGP routing domain is intended to maintain a coherent view of the connectivity of the inter-AS domain, where connectivity is expressed as a preference for 'shortest paths' to reach any destination address as modulated by the connectivity policies expressed by each AS, and coherence is expressed as a global constraint that none of the paths contains loops or dead ends. The elements of the BGP routing domain are routing entries, expressed as a span of addresses. All addresses advertised within each routing entry share a common origin AS and a common connectivity policy. The total size of the BGP table is therefore a metric of the number of distinct routes within the Internet, where each route describes a contiguous set of addresses that share a common origin AS and a common reachability policy.
ルーティングテーブル内のポリシー決意の関連する寸法があります。 ASが隣接ASへのルートをアドバタイズする場合、ASローカルは、最終的にアドバタイズルーティングエントリによって記述アドレス宛ての隣接ASからのトラフィックを受け入れるために提供されます。 ASローカルルートを発信していない場合、推論は、ローカルASは、いくつかのサードパーティに代わって、このトラフィックのためのトランジットプロバイダの役割を引き受けることをいとわないということです。同様に、ASは、またはネイバーからルートを受け入れることを選択しない場合があります。ルートを受け入れること経路によって張らアドレスに到達するようないくつかの状況下では、ローカルルート選択パラメータによって決定されるように、ローカルASは隣接を使用することを意味します。 BGPルーティングドメインは、接続が各ASによって表さ接続ポリシーによって変調されたような任意の宛先アドレスに到達するための「最短経路」の嗜好として表されるインターASドメイン、の接続のコヒーレントビューを維持するために意図され、そしてコヒーレンスは、パスのいずれもループまたは行き止まりを含まないグローバル制約として表現されます。 BGPルーティングドメインの要素がルーティングエントリで、アドレスのスパンとして表さ。すべてのアドレスは、各ルーティングエントリを共有内共通の起源ASとの共通接続性ポリシーを宣伝しました。 BGPテーブルの合計サイズは、したがって、各経路として共通の起源を共有アドレスの連続セットと共通の到達可能性ポリシーを記述するインターネット内の別個の経路の数のメトリックです。
When the scaling properties of the Internet were studied in the early 1990s two critical factors identified in the study were, not surprisingly, routing and addressing [2]. As more devices connect to the Internet they consume addresses, and the associated function of maintaining reachability information for these addresses, with an assumption of an associated growth in the number of distinct provider networks and the number of distinct connectivity policies, implies ever larger routing tables. The work in studying the limitations of the 32 bit IPv4 address space produced a number of outcomes, including the specification of IPv6 [3], as well as the refinement of techniques of network address translation [4] intended to allow some degree of transparent interaction between two networks using different address realms. Growth in the routing system is not directly addressed by these approaches, as the routing space is the cross product of the complexity of the inter-AS topology of the network, multiplied by the number of distinct connectivity policies multiplied by the degree of fragmentation of the address space. For example, use of NAT may reduce the pressure on the number of public addresses required by a single connected network, but it does not necessarily imply that the network's connectivity policies can be subsumed within the aggregated policy of a single upstream provider.
インターネットのスケーリング特性は、1990年代初めに研究されたときに研究で同定された2つの重要な要因は、驚くことではないが、ルーティングおよびアドレッシングた[2]。より多くのデバイスは、それらがアドレスを消費し、インターネットに接続し、異なるプロバイダネットワークの数に関連した成長と異なる接続ポリシーの数の仮定を用いて、これらのアドレスの到達可能性情報を維持するための関連する機能として、これまでより大きなルーティングテーブルを暗示。 32ビットのIPv4アドレス空間の制限を検討中の作業は、IPv6の仕様[3]、ならびにネットワークアドレス変換の技術の改良を含む結果の数は、[4]透明相互作用をある程度許容することを意図生成しました異なるアドレスレルムを使用して2つのネットワーク間。ルーティング空間がの断片化の程度を掛けた異なる接続ポリシーの数を乗じ、ネットワークのインターASトポロジの複雑さの外積であるように、ルーティングシステムの成長は、直接、これらの方法によって対処されていませんアドレス空間。例えば、NATの使用は、単一の接続されたネットワークによって必要とされるパブリックアドレスの数に圧力を減少させることができるが、それが必ずしもネットワークの接続ポリシーは、単一の上流プロバイダの集約ポリシー内に包含されることができることを意味するものではありません。
When an AS advertises a block of addresses into the exterior routing space this entry is generally carried across the entire exterior routing domain of the Internet. To measure the common characteristics of the global routing table, it is necessary to establish a point in the default-free part of the exterior routing domain and examine the BGP routing table that is visible at that point.
ASは外部ルーティング空間にアドレスのブロックをアドバタイズする場合、このエントリは、一般的にインターネットの全体外部ルーティングドメイン間で行われます。グローバルルーティングテーブルの共通の特性を測定するために、外部ルーティングドメインの既定のない部分にポイントを確立し、その時点で表示されているBGPルーティングテーブルを検討する必要があります。
Measurements of the size of the routing table were somewhat sporadic to start, and a number of measurements were taken at approximate monthly intervals from 1988 until 1992 by Merit [5]. This effort was resumed in 1994 by Erik-Jan Bos at Surfnet in the Netherlands, who commenced measuring the size of the BGP table at hourly intervals in 1994. This measurement technique was adopted by the author in 1997, using a measurement point located at the edge of AS 1221 at Telstra in Australia, again using an hourly interval for the measurement. The initial measurements were of the number of routing entries contained within the set of selected best paths. These measurements were expanded to include the number of AS numbers, number of AS paths, and a set of measurements relating to the prefix size of routing table entries.
ルーティングテーブルのサイズの測定は開始する幾分散発的であった、そして測定の数は、[5]メリット1988年から1992年まで近似毎月の間隔で採取しました。この取り組みは、位置測定点を用いて、この測定技術は、1997年に作者によって採択された1994年に時間間隔でBGPテーブルのサイズを測定開始オランダのSURFNET、でエリック・ヤン・ボスによって1994年に再開しました。再び測定の時間単位の間隔を使用してオーストラリアのテルストラでAS 1221の縁、。初期測定は、選択された最良の経路のセット内に含まれるルーティングエントリの数でした。これらの測定は、AS番号の数、パスASの数、およびルーティングテーブルエントリのプレフィックスサイズに関する測定値のセットを含むように拡張しました。
This data contains a view of the dynamics of the Internet's routing table growth that spans some 13 years in total and includes a very detailed view spanning the most recent seven years [6]. Looking at just the total size of the BGP routing table over this period, it is possible to identify four distinct phases of inter-AS routing practice in the Internet.
このデータは、合計で、いくつかの13年にまたがるインターネットのルーティングテーブルの成長のダイナミクスのビューが含まれており、最新の7年にわたる非常に詳細なビューが含まれる[6]。この期間中BGPルーティングテーブルのちょうど合計サイズを見ると、インターネットでAS間ルーティングの練習の4つの異なる段階を識別することが可能です。
The initial characteristics of the routing table size from 1988 until April 1994 show definite characteristics of exponential growth. If continued unchecked, this growth would have lead to saturation of the available BGP routing table space in the non-default routers of the time within a small number of years.
1988年から1994年4月までのルーティングテーブルサイズの初期特性は、指数関数的成長の明確な特徴を示します。チェックを外す続けた場合は、この成長は年の数が少ない内の時間のデフォルト以外のルータで利用可能なBGPルーティングテーブルスペースの飽和につながるだろう。
Estimates of the time at which this would've happened varied somewhat from study to study, but the overall general theme of these observations was that the growth rates of the BGP routing table were exceeding the growth in hardware and software capability of the deployed network, and that at some point in the mid-1990's, the BGP table size would have grown to the point where it was larger than the capabilities of available equipment to support.
、時間の見積もりは、その時にこれが起こった研究に研究から多少変化してきただろうが、これらの観察の全体的な一般的なテーマは、BGPルーティングテーブルの成長率が展開されたネットワークのハードウェアとソフトウェア機能の成長を超えたということでしたその1990年代半ばのある時点で、BGPテーブルのサイズは、サポートするために利用可能な機器の能力よりも大きかった地点に成長しているだろう。
The response from the engineering community was the introduction of a hierarchy into the inter-domain routing system. The intent of the hierarchical routing structure was to allow a provider to merge the routing entries for its customers into a single routing entry that spanned its entire customer base. The practical aspects of this change was the introduction of routing protocols that dispensed with the requirement for the Class A, B and C address delineation, replacing this scheme with a routing system that carried an address prefix and an associated prefix length. This approached was termed Classless Inter-Domain Routing (CIDR) [5].
エンジニアリング・コミュニティからの応答は、ドメイン間ルーティングシステムへの階層の導入でした。階層型ルーティング構造の意図は、プロバイダがその全体の顧客基盤をまたがる単一のルーティングエントリにその顧客のためのルーティングエントリをマージすることを可能にすることでした。この変更の実用的な側面は、アドレスプレフィックスと関連するプレフィックス長を実施ルーティングシステムにこの方式を置き換える、クラスA、B及びCアドレス描写のための要件を不要ルーティングプロトコルの導入でした。これは、[5]クラスレスドメイン間ルーティング（CIDR）と名付けた近づきました。
A concerted effort was undertaken in 1994 and 1995 to deploy CIDR routing in the Internet, based on encouraging deployment of the CIDR-capable version of the BGP protocol, BGP4 [7].
協調努力は、BGPプロトコルのCIDR対応バージョンの展開を奨励に基づいて、インターネットにCIDRルーティングを展開するために1994年と1995年に行われた、BGP4 [7]。
The intention of CIDR was one of hierarchical provider address aggregation, where a network provider was allocated an address block from an address registry, and the provider announced this entire block into the exterior routing domain as a single entry with a single routing policy. Customers of the provider were encouraged to use a sub-allocation from the provider's address block, and these smaller routing elements were aggregated by the provider and not directly passed into the exterior routing domain. During 1994 the size of the routing table remained relatively constant at some 20,000 entries as the growth in the number of providers announcing address blocks was matched by a corresponding reduction in the number of address announcements as a result of CIDR aggregation.
CIDRの意図は、ネットワークプロバイダがアドレスレジストリからアドレスブロックを割り当て、およびプロバイダが単一のルーティングポリシーに単一のエントリとして外部ルーティングドメインにこのブロック全体を発表された階層的なプロバイダのアドレス集合の一つでした。プロバイダの顧客はプロバイダのアドレスブロックからサブ割り当てを使用することを奨励し、そしてこれらのより小さいルーティング要素は、プロバイダによって集約し、直接外部ルーティングドメインに渡されませんでした。 1994年の間に、ルーティングテーブルのサイズは、CIDR凝集の結果としてアドレス発表の数の対応する減少にマッチしたアドレスブロックを発表プロバイダの数の増加として約2万個のエントリで比較的一定のままでした。
For the next four years until the start of 1998, CIDR proved effective in damping unconstrained growth in the BGP routing table. During this period, the BGP table grew at an approximate linear rate, adding some 10,000 entries per year.
1998年の開始まで次の4年間は、CIDRは、BGPルーティングテーブルに制約のない成長を減衰に効果的であることが判明しました。この期間中、BGPテーブルには、年間約10,000のエントリを追加して、おおよその線形速度で成長しました。
A close examination of the table reveals a greater level of stability in the routing system at this time. The short term (hourly) variation in the number of announced routes reduced, both as a percentage of the number of announced routes, and also in absolute terms. One of the other benefits of using large aggregate address blocks is that instability at the edge of the network is not immediately propagated into the routing core. The instability at the last hop is absorbed at the point where an aggregate route is used in place of a collection of more specific routes. This, coupled with widespread adoption of BGP route flap damping, was very effective in reducing the short term instability in the routing space during this period.
テーブルの精密検査は、この時点でルーティングシステムにおける安定性の高いレベルを明らかにする。発表されたルートの数の短期（毎時）変化が絶対値でも発表されたルートの数のパーセンテージとして、の両方を減少し、。大きな凝集アドレスブロックを使用することの他の利点の一つは、ネットワークのエッジでの不安定性は直ちにルーティングコアに伝播されないことです。最後のホップでの不安定性は、集約経路をより具体的なルートの集合の代わりに使用されている点で吸収されます。これは、BGPルートフラップダンピングの普及と相まって、この期間中にルーティング空間における短期不安定性を低減するのに非常に有効でした。
In late 1998 the trend of growth in the BGP table size changed radically, and the growth for the period 1998 - 2000 is again showing all the signs of a re-establishment of a growth trend with strong correlation to an exponential growth model. This change in the growth trend appears to indicate that pressure to use hierarchical address allocations and CIDR has been unable to keep pace with the levels of growth of the Internet, and some additional factors that impact the growth in the BGP table size have become more prominent in the Internet. This has lead to a growth pattern in the total size of the BGP table that has more in common with a compound growth model than a linear model. A good fit of the data for the period from January 1999 until December 2000 is a compound growth model of 42% growth per year.
1998年末にBGPテーブルサイズの増加の傾向が劇的に変化し、期間1998年成長 - 2000は、再び対数増殖モデルに強い相関の成長傾向の再確立のすべての兆候を示しています。成長傾向の変化は、階層的なアドレス割り当てを使用するために、その圧力を示すために表示され、CIDRは、インターネットの成長のレベルとペースを維持することができなかった、とBGPテーブルサイズの成長に影響を与えるいくつかの追加の要因がより顕著になってきましたインタネットの中には。これは、線形モデルよりも化合物の成長モデルと共通の多くを有するBGPテーブルの合計サイズに成長パターンをもたらしました。 2000年12月までに1999年1月からの期間のデータの良好な適合は年間42％の成長の化合物の成長モデルです。
An initial observation is that this growth pattern points to some weakening of the hierarchical model of connectivity and routing within the Internet. To identify the characteristics of this recent trend it is necessary to look at a number of related characteristics of the routing table.
最初の観察は、この成長パターンは、インターネット内の接続とルーティングの階層モデルのいくつかの弱体化を指していることです。この最近の傾向の特性を識別するためには、ルーティングテーブルの関連する特性の数を調べることが必要です。
BGP table size data for the first half of 2001 shows different trends at various measurement points in the Internet. Some measurement points where the local AS has a relative larger number of more specific routes show a steady state for the first half of 2001 with no appreciable growth, while other measurement points where the local AS has had a lower number of more specific routes initially show a continuation of table size growth. There are a number of commonly observed discontinuities in the data for 2001, corresponding to events where a significant number of more specific entries have been replaced by an encompassing aggregate prefix.
2001年上半期のBGPテーブルサイズのデータは、インターネット内の種々の測定点で異なる傾向を示しています。 ASローカルのより具体的なルートの低い数を持っているように、ローカル他の測定ポイントが最初に表示しながら、より具体的なルートの相対多数がないかなりの成長に2001年前半のための定常状態を示し有するいくつかの測定点テーブルサイズの成長の継続。より具体的なエントリのかなりの数は、包括的な集計接頭辞に置き換えられているイベントに対応した2001年のデータでは一般的に観察不連続の数があります。
The level of analysis of the BGP routing table has been extended in an effort to identify the factors contributing to this growth, and to determine whether this leads to some limiting factors in the potential size of the routing space. Analysis includes measuring the number of ASes in the routing system, and the number of distinct AS paths, the range of addresses spanned by the table and average span of each routing entry.
BGPルーティングテーブルの分析のレベルは、この成長に貢献する因子を同定するために、これはルーティング空間の電位サイズに多少の制限要因につながるかどうかを決定するために努力に拡張されています。分析は、ルーティングシステム内のASの数、およびパスAS別個の数、テーブル及び各ルーティングエントリの平均スパンがまたがるアドレスの範囲を測定することを含みます。
Each network that is multi-homed within the topology of the Internet and wishes to express a distinct external routing policy must use a unique AS number to associate its advertised addresses with such a policy. In general, each network is associated with a single AS, and the number of ASes in the default-free routing table tracks the number of entities that have unique routing policies. There are some exceptions to this, including large global transit providers with varying regional policies, where multiple ASes are associated with a single network, but such exceptions are relatively uncommon.
インターネットのトポロジ内のマルチホームと異なる外部のルーティングポリシーを表現することを希望された各ネットワークは、ポリシーにそのアドバタイズアドレスを関連付けるためにAS番号ユニークを使用しなければなりません。一般に、各ネットワークは、単一のASに関連付けられ、デフォルトフリールーティングテーブル内のASの数は、固有のルーティングポリシーを持っているエンティティの数を追跡しています。複数のASを単一のネットワークに関連付けられているが、このような例外は比較的まれであるされている様々な地域政策、との大規模なグローバルトランジットプロバイダーを含め、これにはいくつかの例外があります。
The number of unique ASes present in the BGP table has been tracked since late 1996, and the trend of AS number deployment over the past four years is also one that matches a compound growth model with a growth rate of 51% per year. As of the start of May 2001 there were some 10,700 ASes visible in the BGP table. At a continued rate of growth of 51% p.a., the 16 bit AS number space will be fully deployed by August 2005. Work is underway within the IETF to modify the BGP protocol to carry AS numbers in a 32-bit field. [8] While the protocol modifications are relatively straightforward, the major responsibility rests with the operations community to devise a transition plan that will allow gradual transition into this larger AS number space.
BGPテーブルに存在する独特のASの数は、1996年後半以降に追跡されており、過去4年間のAS番号の導入の傾向はまた、年間51％の成長率を有する化合物の成長モデルと一致するものです。 2001年5月の開始の時点でBGPテーブルに表示いくつかの10700のASがありました。 51％のP.A.の成長の継続的な速度で、数空間として16ビットを完全ワークは、32ビットのフィールドでAS番号運ぶためにBGPプロトコルを変更するために、IETF内で進行中である2005年8月によって展開されるであろう。プロトコルの変更が比較的簡単であるが[8]、主要な責任は、番号空間ASこの大きなに徐々に移行を可能にする移行計画を考案する操作コミュニティにかかっています。
It is also possible to track the total amount of address space advertised within the BGP routing table. At the start of 2001 the routing table encompassed 1,081,131,733 addresses, or some 25.17% of the total IPv4 address space, or 25.4% of the usable unicast public address space. By September 2001 this has growth to 1,123,124,472 addresses, or some 26% of the IPv4 address space. This has grown from 1,019,484,655 addresses in November 1999. However, there are a number of /8 prefixes that are periodically announced and withdrawn from the BGP table, and if the effects of these prefixes is removed, a compound growth model against the previous 12 months of data of this metric yields a best fit model of growth of 7% per year in the total number of addresses spanned by the routing table.
BGPルーティングテーブル内でアドバタイズアドレス空間の総量を追跡することも可能です。 2001年開始時のルーティングテーブルは1081131733のアドレス、又は全IPv4アドレス空間の一部25.17パーセント、または使用可能なユニキャストパブリックアドレス空間の25.4％を包含しました。 2001年9月では、これは1123124472のアドレス、またはIPv4アドレス空間の一部の26％に成長しています。これは、しかし、定期的に発表し、BGPテーブルから引き出し、およびされている/ 8プレフィックスの数がある1999年11月に1019484655のアドレスから成長してきたこれらのプレフィックスの効果が削除された場合、過去12ヶ月に対する化合物の成長モデルこのメトリックのデータのルーティングテーブルが及ぶアドレスの総数で年間7％の成長のベストフィットモデルを生成します。
Compared to the 42% growth in the number of routing advertisements, the growth in the amount of address space advertised is far lower. One possible explanation is that much of the growth of the Internet in terms of growth in the number of connected devices is occurring behind various forms of NAT gateways. In terms of solving the perceived finite nature of the address space identified just under a decade ago, this explanation would tend to indicate that the Internet appears so far to have embraced the approach of using NATs, irrespective of their various perceived functional shortcomings. [9] This explanation also supports the observation of smaller address fragments supporting distinct policies in the BGP table, as such small address blocks may encompass arbitrarily large networks located behind one or more NAT gateways. There are alternative explanations of this difference between the growth of the table and the growth of address space, including a trend towards discrete exterior routing policies being applied to finer address blocks.
ルーティング広告の数に42％の成長と比較して、アドバタイズアドレススペースの量の増加ははるかに低いです。一つの可能な説明は、接続機器数の増加という点で、インターネットの成長の多くはNATゲートウェイの様々な形の後ろに発生していることです。ちょうど十年前で特定のアドレス空間の知覚有限性を解決するという点では、この説明は、インターネットを問わず、様々な認知機能の欠点の、NATのを使用してのアプローチを採用しているために、これまでに表示されていることを示すために傾向があります。このような小さなアドレスブロックは、1つまたは複数のNATゲートウェイの背後に位置する任意の大規模なネットワークを包含することができるように[9]この説明は、また、BGPテーブルに異なるポリシーをサポート小さいアドレス断片の観察を支持します。テーブルの成長と離散外部ルーティングポリシーは細かいアドレスブロックに適用されている傾向を含むアドレス空間の成長との間のこの違いの別の説明があります。
The intent of CIDR aggregation was to support the use of large aggregate address announcements in the BGP routing table. To confirm whether this is still the case the average span of each BGP announcement has been tracked for the past 12 months. The data indicates a decline in the average span of a BGP advertisement from 16,000 individual addresses in November 1999 to 12,100 in December 2000. As of September 2001 this span has been further reduced to an average 10,700 individual addresses per routing entry. This corresponds to an increase in the average prefix length from /18.03 to /18.44 by December 2000 and a /18.6 by September 2001. Separate observations of the average prefix length used to route traffic in operation networks in late 2000 indicate an average length of 18.1 [11]. This trend towards finer-grained entries in the routing table is potentially cause for concern, as it implies the increasing spread of traffic over greater numbers of increasingly smaller forwarding table entries. This, in turn, has implications for the design of high speed core routers, particularly when extensive use is made of a small number of very high speed cached forwarding entries within the switching subsystem of a router's design.
CIDR凝集の目的は、BGPルーティングテーブル内の大集約アドレスアナウンスの使用をサポートすることでした。これはまだそうであるかどうかを確認するには、各BGPアナウンスメントの平均スパンは、過去12カ月間追跡されています。このスパンがさらにルーティングエントリあたりの平均10700の個々のアドレスに縮小されました2001年9月のように、データは2000年12月で12100に1999年11月16,000個々のアドレスからBGPアドバタイズメントの平均スパンの減少を示しています。これは、2000年後半に運用ネットワークでのトラフィックのルーティングに使用される平均プレフィックス長の2001別々の観測が18.1の平均長さを示す9月までに2000年12月によって/18.03から/18.44までの平均プレフィックス長の増加と/18.6に対応します[11]。ルーティングテーブルに細かい粒度のエントリへのこの傾向は、ますます小さくフォワーディングテーブルエントリのより多くのトラフィックの増加広がりを暗示するように、潜在的に、懸念の原因です。これは、順番に、広範な使用は、ルータの設計のスイッチングサブシステム内の非常に高速キャッシュされた転送エントリの数が少ないから作られる場合は特に、高速コアルータの設計に影響があります。
A similar observation can be made regarding the number of addresses advertised per AS. In December 1999 each AS advertised an average of 161,900 addresses (equivalent to a prefix length /14.69, and in January 2001 this average has fallen to 115,800 addresses, an equivalent prefix length of /15.18.
同様の観察は、ASごとに広告を出したアドレスの数について行うことができます。 1999年12月に各ASは、プレフィックス長/14.69に相当161900のアドレス（の平均を宣伝し、2001年1月にこの平均は115800人の住所、/15.18の同等のプレフィックス長に落ちています。
This points to increasingly finer levels of routing detail being announced into the global routing domain. This, in turn, supports the observation that the efficiencies of hierarchical routing structures are no longer being fully realized within the deployed Internet. Instead, increasingly finer levels of routing detail are being announced globally in the BGP tables. The most likely cause of this trend of finer levels of routing granularity is an increasingly dense interconnection mesh, where more networks are moving from a single-homed connection with hierarchical addressing and routing into multi-homed connections without any hierarchical structure. The spur for this increasingly dense connectivity mesh in the Internet may well be the declining unit costs of communications bearer services coupled with a common perception that richer sets of adjacencies yields greater levels of service resilience.
これは、ますますルーティング細部の細かいレベルはグローバルルーティングドメインに発表されているを指します。これは、順番に、階層型ルーティング構造の効率は、もはや完全に展開、インターネット内で実現されている観測をサポートしています。代わりに、ルーティングの詳細ますます細かいレベルがBGPテーブルにグローバルに発表されています。粒度をルーティングするより細かいレベルのこの傾向の最も可能性の高い原因は、複数のネットワークは、階層アドレッシング及び任意の階層構造を持たないマルチホーム接続にルーティングとシングルホーム接続から移動している、ますます密な相互接続メッシュです。インターネットでは、このますます密な接続メッシュの拍車は良く隣接の豊かなセットがサービス回復力の高いレベルをもたらすという共通認識と相まって通信ベアラサービスの低下単位コストとすることができます。
In addition to looking at the average prefix length, the analysis of the BGP table also includes an examination of the number of advertisements of each prefix length.
平均プレフィックス長を見ていることに加えて、BGPテーブルの分析は、各プレフィックス長の広告の数の検査を含みます。
An extensive program commenced in the mid-nineties to move away from intense use of the Class C space and to encourage providers to advertise larger address blocks, as part of the CIDR effort. This has been reinforced by the address registries who have used provider allocation blocks that correspond to a prefix length of /19 and, more recently, /20.
90年代半ばに始まった大規模なプログラムは、クラスC空間の激しい使用から離れて移動すると、CIDRの努力の一環として、より大きなアドレスブロックを宣伝するためにプロバイダーを奨励します。これは、より最近になって、/ 20、/ 19のプレフィックス長に対応するプロバイダアロケーションブロックを使用しているアドレスレジストリによって補強されています。
These measures were introduced in the mid-90's when there were some 20,000 - 30,000 entries in the BGP table. Some six years later in April 2001 it is interesting to note that of the 108,000 entries in the routing table, some 59,000 entries have a /24 prefix. In absolute terms the /24 prefix set is the fastest growing set in the BGP routing table. The routing entries of these smaller address blocks also show a much higher level of change on an hourly basis. While a large number of BGP routing points perform route flap damping, nevertheless there is still a very high level of announcements and withdrawals of these entries in this particular area of the routing table when viewed using a perspective of route updates per prefix length. Given that the numbers of these small prefixes are growing rapidly, there is cause for some concern that the total level of BGP flux, in terms of the number of announcements and withdrawals per second may be increasing, despite the pressures from flap damping. This concern is coupled with the observation that, in terms of BGP stability under scaling pressure, it is not the absolute size of the BGP table that is of prime importance, but the rate of dynamic path re-computations that occur in the wake of announcements and withdrawals. Withdrawals are of particular concern due to the number of transient intermediate states that the BGP distance vector algorithm explores in processing a withdrawal. Current experimental observations indicate a typical convergence time of some 2 minutes to propagate a route withdrawal across the BGP domain. [10]
BGPテーブル30,000エントリ - 約2万人があったときに、これらの措置は、90年代半ばに導入されました。いくつかの6年後の2001年4月に、それはルーティングテーブルに108,000のエントリのことに注意することは興味深い、いくつかの59,000のエントリが/ 24のプレフィックスを持っています。絶対的に/ 24プレフィックスセットは、BGPルーティングテーブルで最も急速に成長しているセットです。これらの小さなアドレスブロックのルーティングエントリも時間ごとに変化するのはるかに高いレベルを示しました。 BGPルーティングポイント多数の減衰経路フラップを実行している間プレフィクス長さ当たりのルートアップデートの視点を用いて見たときに、それにもかかわらず、ルーティングテーブルのこの特定の領域におけるこれらのエントリの発表や引き出しの非常に高いレベルが依然として存在します。これらの小さなプレフィックスの数が急速に成長していることを考えると、毎秒発表や引き出しの数の点でBGPフラックスの合計レベルは、減衰フラップからの圧力にもかかわらず、増加することができることを、いくつかの懸念があります。この問題は、スケーリング圧力下BGP安定性の観点から、それが最も重要であるBGPテーブルの絶対的な大きさではない、観察と結合されるが、アナウンスをきっかけに起こる動的経路再計算の速度そして引き出し。引き出し起因BGP距離ベクトルアルゴリズムは離脱を処理する際に探求過渡中間状態の数に特に重要です。現在の実験観察は、BGPドメイン間でルートの撤退を伝播するために、いくつかの2分の典型的な収束時間を示しています。 [10]
An increase in the density of the BGP mesh, coupled with an increase in the rate of such dynamic changes, does have serious implications in maintaining the overall stability of the BGP system as it continues to grow. The registry allocation policies also have had some impact on the routing table prefix distribution. The original registry practice was to use a minimum allocation unit of a /19, and the 10,000 prefix entries in the /17 to /19 range are a consequence of this policy decision. More recently, the allocation policy now allows for a minimum allocation unit of a /20 prefix, and the /20 prefix is used by some 4,300 entries as of January 2001, and in relative terms is one of the fastest growing prefix sets. The number of entries corresponding to very small address blocks (smaller than a /24), while small in number as a proportion of the total BGP routing table, is the fastest growing in relative terms. The number of /25 through /32 prefixes in the routing table is growing faster, in terms of percentage change, than any other area of the routing table. If prefix length filtering were in widespread use, the practice of announcing a very small address block with a distinct routing policy would have no particular beneficial outcome, as the address block would not be passed throughout the global BGP routing domain and the propagation of the associated policy would be limited in scope. The growth of the number of these small address blocks, and the diversity of AS paths associated with these routing entries, points to a relatively limited use of prefix length filtering in today's Internet. In the absence of any corrective pressure in the form of widespread adoption of prefix length filtering, the very rapid growth of global announcements of very small address blocks is likely to continue. In percentage terms, the set of prefixes spanning /25 to /32 show the largest growth rates.
そのような動的変化の速度の増加と相まってBGPメッシュの密度の増加は、それが成長し続けているBGPシステムの全体的な安定性を維持する上で重大な意味を持っています。レジストリの割り当てポリシーは、ルーティングテーブルのプレフィックス配布に何らかの影響を与えてきました。元のレジストリの練習/ 19の最小割り当て単位を使用することであった、そして/ 17/19の範囲10,000プレフィックスエントリがこのポリシー決定の結果です。さらに最近では、割り当てポリシーは今/ 20プレフィックスの最小割り当て単位を可能にし、/ 20プレフィックスは、2001年1月の時点でいくつかの4300のエントリで使用され、相対的な用語で最も急速に成長しているプレフィックスセットの一つです。 （/ 24未満）、非常に小さなアドレスブロックに対応するエントリの数は、合計のBGPルーティングテーブルの割合として数の小さいながらは、相対的な用語で成長最速です。ルーティングテーブル内の/ 32プレフィックスを介し/ 25の数は、ルーティングテーブルの他の領域よりも、変化率の点で、より速く成長しています。プレフィックス長フィルタリングが普及した場合、アドレスブロックがグローバルBGPルーティングドメインと関連の伝播を通して渡されないように、異なるルーティングポリシーに非常に小さなアドレスブロックを発表の実施は、特に有益な結果を持っていないであろうポリシーは、範囲が限定されるだろう。これらの小アドレスブロックの数、およびこれらのルーティングエントリに関連付けられたパスASの多様性の成長は、今日のインターネットでのプレフィックス長フィルタリングの比較的限定された使用を指します。プレフィックス長フィルタリングの普及の形で是正圧力がない場合には、非常に小さなアドレスブロックの世界的な発表の非常に急速な成長が続く可能性が高いです。割合の用語では、/ 32/25にまたがるプレフィックスのセットは、最大の成長率を示しています。
With the CIDR routing structure it is possible to advertise a more specific prefix of an existing aggregate. The purpose of this more specific announcement is to punch a 'hole' in the policy of the larger aggregate announcement, creating a different policy for the specifically referenced address prefix.
CIDRルーティング構造で、既存の集約のより具体的なプレフィックスを通知することが可能です。このより具体的な発表の目的は、具体的には、参照アドレスプレフィックスの異なるポリシーを作成する、より大きな凝集発表のポリシーに「穴」をパンチすることです。
Another use of this mechanism is to perform a rudimentary form of load balancing and mutual backup for multi-homed networks. In this model a network may advertise the same aggregate advertisement along each connection, but then advertise a set of specific advertisements for each connection, altering the specific advertisements such that the load on each connection is approximately balanced. The two forms of holes can be readily discerned in the routing table - while the approach of policy differentiation uses an AS path that is different from the aggregate advertisement, the load balancing and mutual backup configuration uses the same As path for both the aggregate and the specific advertisements. While it is difficult to understand whether the use of such more specific advertisements was intended to be an exception to a more general rule or not within the original intent of CIDR deployment, there appears to be very widespread use of this mechanism within the routing table. Some 59,000 advertisements, or 55% of the total number of routing table entries, are being used to punch policy holes in existing aggregate announcements. Of these the overall majority of some 42,000 routes use distinct AS paths, so that it does appear that this is evidence of finer levels of granularity of connection policy in a densely interconnected space. While long term data is not available for the relative level of such advertisements as a proportion of the full routing table, the growth level does strongly indicate that policy differentiation at a fine level within existing provider aggregates is a significant driver of overall table growth.
このメカニズムの別の用途は、マルチホームネットワークの負荷分散と相互バックアップの初歩的なフォームを実行することです。このモデルでは、ネットワークは、各接続に沿って同じ集約広告を広告することができるが、各接続の負荷がほぼ平衡であるように特定の広告を変更すること、各接続のための特定の広告のセットを広告します。穴の2つの形態が容易にルーティングテーブルに識別することができる - ポリシー分化のアプローチは、総計広告異なるASパスを使用しながら、負荷分散と相互バックアップ構成は、骨材との両方のための経路と同じように使用し特定の広告。このようなより具体的な広告の使用はCIDR展開の本来の意図内のより一般的な規則の例外かどうかであることを意図していたかどうかを理解することは困難ですが、ルーティングテーブル内のこのメカニズムの非常に広範囲に使用があるように見えます。一部59,000広告、またはルーティングテーブルエントリの総数の55％は、既存の集合アナウンスにおけるポリシー孔をパンチするために使用されています。これが密に相互接続空間での接続ポリシーの粒度の細かいレベルの証拠であると表示されないように、これらのいくつか42,000ルートの全体の大半は、パスAS明確な使用します。長期データが完全なルーティングテーブルの割合などの広告の相対的なレベルのために利用可能ではないが、成長レベルが強く、既存のプロバイダ凝集内細かいレベルでポリシー分化全体表増殖の有意なドライバであることを示しているん。
The resumption of compound growth trends within the BGP table, and the associated aspects of finer granularity of routing entries within the table form adequate grounds for consideration of potential refinements to the Internet's exterior routing protocols and potential refinements to current operating practices of inter-AS connectivity. With the exception of the 16 bit AS number space, there is no particular finite limit to any aspect of the BGP table. The motivation for such activity is that a long term pattern of continued growth at current rates may once again pose a potential condition where the capacity of the available processors may be exceeded by some aspect of the Internet routing table.
AS間の接続の現在の事業慣行へのインターネットの外部ルーティングプロトコルや潜在的な改良への潜在的な改良の検討のための表形式の適切な敷地内に複合成長BGPテーブル内の動向、およびルーティングエントリのより細かい粒度の関連する側面の再開。番号空間として16ビットを除いて、BGPテーブルのいずれかの態様には、特に有限の制限はありません。そのような活動のための動機は、現在の速度で継続的な成長の長期パターンが再び利用可能なプロセッサの能力は、インターネット・ルーティング・テーブルの一部の側面を超えてもよいポテンシャル状態をもたらす可能性があることです。
The decreasing unit cost of communications bearers in many part of the Internet is creating a rapidly expanding market in exchange points and other forms of inter-provider peering. A model of extensive interconnection at the edges of the Internet is rapidly supplanting the deployment model of a single-homed network with a single upstream provider. The underlying deployment model of CIDR was that of a single-homed network, allowing for a strict hierarchy of supply providers. The business imperatives driving this denser mesh of interconnection in the Internet are substantial, and the casualty in this case is the CIDR-induced dampened growth of the BGP routing table.
インターネットの多くの部分において通信ベアラの減少単価は、交換点と間プロバイダピアリングの他の形態で急速に拡大市場を作成しています。インターネットのエッジでの広範囲の相互接続のモデルが急速に単一の上流プロバイダとのシングルホームネットワークの展開モデルに取って代わるれます。 CIDRの基礎となる展開モデルは、供給業者の厳密な階層構造を可能にする、単一のホームネットワークのことでした。インターネットに相互接続のこのより高密度メッシュを駆動するビジネス要請は相当であり、この場合の損害は、BGPルーティングテーブルのCIDR誘導性湿らせた成長です。
It would appear that one of the major drivers of the recent growth of the BGP table is that of small networks, advertised as a /24 prefix entry in the routing table, multi-homing with a number of peers and upstream providers. In the appropriate environment where there are a number of networks in relatively close proximity, using peer relationships can reduce total connectivity costs, as compared to using a single upstream service provider. Equally significantly, multi-homing with a number of upstream providers is seen as a means of improving the overall availability of the service. In essence, multi-homing is seen as an acceptable substitute for upstream service resiliency. This has a potential side effect that when multi-homing is seen as a preferable substitute for upstream provider resiliency, the upstream provider cannot command a price premium for proving resiliency as an attribute of the provided service, and therefore has little economic incentive to spend the additional money required to engineer resiliency into the network. The actions of the network's multi-homed clients then become self-fulfilling. One way to characterize this behavior is that service resiliency in the Internet is becoming the responsibility of the customer, not the service provider.
BGPテーブルの最近の成長の主要な要因のひとつが、仲間や上流プロバイダの数と/ 24プレフィックスルーティングテーブルのエントリ、マルチホーミングとして宣伝、小規模ネットワークのことであるということを思われます。比較的近接したネットワークの数が存在し、適切な環境では、ピア関係を使用して、単一の上流のサービスプロバイダを使用することに比べて、トータルの接続コストを削減することができます。等しく重要なことは、上流プロバイダの数とマルチホーミングは、サービスの全体的な可用性を向上させる手段として見られています。本質的には、マルチホーミングは、上流サービスの復元のために許容される代替として見られています。これは、マルチホーミングは、上流プロバイダの回復力のための好適な代替として見た場合に、上流のプロバイダが提供するサービスの属性として弾力性を証明するために価格プレミアムを指揮することができないという潜在的な副作用があり、そのため過ごすには少し経済的インセンティブを持っていますネットワークに弾力性を設計するために必要な追加のお金。ネットワークのマルチホームのクライアントの行動は、自己達成となります。この動作を特徴付けるための一つの方法は、インターネットでのサービスの回復力は、顧客ではなく、サービス提供者の責任になっていることです。
In such an environment resiliency still exists, but rather than being a function of the bearer or switching subsystem, resiliency is provided through the function of the BGP routing system. The question is not whether this is feasible or desirable in the individual case, but whether the BGP routing system can scale adequately to continue to undertake this role.
このような環境の復元にまだ存在し、むしろベアラの関数であるまたはサブシステムを切り替えるよりも、弾力がBGPルーティングシステムの機能を介して提供されます。質問は、これは個々のケースでは実現可能か望ましいかどうかではなく、BGPルーティングシステムは、この役割を引き受けるために継続して適切にスケーリングすることができるかどうか。
Further driving this growth in the routing table is the use of selective advertisement of smaller prefixes along different paths in an effort to undertake traffic engineering within a multi-homed environment. While there is considerable effort being undertaken to develop traffic engineering tools within a single network using MPLS as the base flow management tool, inter-provider tools to achieve similar outcomes are considerably more complex when using such switching techniques.
さらにルーティングテーブルにこの成長を駆動するマルチホーム環境内のトラフィックエンジニアリングを行うための努力に異なる経路に沿って小さいプレフィックスの選択広告の使用です。かなりの努力がベースフロー管理ツールとしてMPLSを使用して、単一のネットワーク内のトラフィック・エンジニアリング・ツールを開発するために行われているがありますが、インタープロバイダツールは、同様の成果を達成するために、このようなスイッチング技術を使用した場合、かなり複雑です。
At this stage the only tool being used for inter-provider traffic engineering is that of the BGP routing table. Such use of BGP appears to place additional fine-grained prefixes into the routing table. This action further exacerbates the growth and stability pressures being placed on the BGP routing domain.
この段階では、インタープロバイダのトラフィックエンジニアリングのために使用されている唯一のツールは、BGPルーティングテーブルのことです。 BGPのこのような使用は、ルーティングテーブルに追加きめ細かな接頭辞を配置することが表示されます。このアクションは、さらに、BGPルーティングドメイン上に配置されている成長と安定圧力を悪化させます。
There is considerable evidence of a lack of uniformity of operational practices within the inter-domain routing space. This includes the use and setting of prefix filters, the use and setting of route damping parameters and level of verification undertaken on BGP advertisements by both the advertiser and the recipient. There is some extent of 'noise' in the routing table where advertisements appear to be propagated well beyond their intended domain of applicability, and also where withdrawals and advertisements are not being adequately damped close to the origin of the route flap. This diversity of operating practices also extends to policies of accepting advertisements that are more specific advertisements of existing provider blocks.
ドメイン間ルーティング空間内の業務慣行の均一性の欠如のかなりの証拠があります。これは、プレフィックスフィルタ、広告主と受信者の両方によってBGPアドバタイズに行わ経路減衰パラメータおよび検証のレベルの使用および設定の使用および設定を含みます。広告がうまく適用のそれらの意図されたドメインを超えて伝播されるように見え、また、引き出しや広告が適切に近いルートフラップの原点に減衰されていないところルーティングテーブルに「ノイズ」のある程度があります。事業慣行のこの多様性は、既存のプロバイダ・ブロックのより具体的な宣伝が含まれた広告を受け入れる方針にまで及びます。
The current growth factors at play in the BGP table are not easily susceptible to another round of CIDR deployment pressure within the operator community. The denser interconnectivity mesh, the increasing use of multi-homing with smaller address prefixes, the extension of the use of BGP to perform roles related to inter-domain traffic engineering and the lack of common operating practices all point to a continuation of the trend of growth in the total size of the BGP routing table, with this growth most apparent with advertisements of smaller address blocks, and an increasing trend for these small advertisements to be punching a connectivity policy 'hole' in an existing provider aggregate advertisement.
BGPテーブルで遊んで、現在の成長因子は、オペレータのコミュニティ内のCIDRの展開圧の別のラウンドを受けやすいではありません。密度の高い相互接続性メッシュ、小さなアドレスプレフィックスを持つマルチホーミングの使用が増加し、ドメイン間のトラフィックエンジニアリングとの傾向の継続をすべてのポイントの共通事業慣行の欠如に関連する役割を実行するためのBGPの使用の延長これらの小さな広告の小さなアドレスブロックの広告に最も明らかこの成長、および増加傾向とのBGPルーティングテーブルの合計サイズの成長は、既存のプロバイダ集約広告に接続ポリシー「穴」を打ち抜くことができます。
It may be appropriate to consider how to operate an Internet with a BGP routing table that has millions of small entries, rather than the expectation of a hierarchical routing space with at most tens of thousands of larger entries in the global routing table.
小さな数百万のエントリを持つBGPルーティングテーブルではなく、グローバルルーティングテーブル内の大きい方のエントリの数千人のほとんどの十時と階層ルーティングスペースを期待して、インターネットを操作する方法を検討することが適切であろう。
It is beyond the scope of this document to define a scalable inter-domain routing environment and associated routing protocols and operating practices. A more modest goal is to look at the attributes of routing systems as understood and identify those aspects of such systems that may be applicable to the inter-domain environment as a potential set of requirements for inter-domain routing tools.
これは、スケーラブルなドメイン間ルーティング環境と関連するルーティングプロトコルや事業慣行を定義するには、この文書の範囲外です。より控えめな目標は、理解されるようにルーティングシステムの属性を見て、ドメイン間ルーティングツールの要件の潜在的なセットとして、ドメイン間の環境にも適用することができるようなシステムのこれらの側面を特定することです。
The overall intent is scalability of the routing environment. Scalability can be expressed in many dimensions, including number of discrete network layer reachability entries, number of discrete route policy entries, level of dynamic change over a unit of time of these entries, time to converge to a coherent view of the connectivity of the network following changes, and so on.
全体的な意図は、ルーティング環境のスケーラビリティです。スケーラビリティは、離散ネットワークレイヤ到達可能性エントリの数、別個のルートポリシーエントリの数、これらのエントリの単位時間にわたる動的変化のレベル、ネットワークの接続性のコヒーレントビューに収束するまでの時間を含め、多くの次元で表すことができます。変更を次、というように。
The basic objective behind this expressed requirement for scalability is that the most likely near to medium trend in the structure of the Internet is a continuation in the pattern of dense interconnectivity between a large number of discrete network entities, and little impetus behind hierarchical aggregating structures. It is not an objective to place any particular metrics on scalability within this examination of requirements, aside from indicating that a prudent view would encompass a scale of connectivity in the inter-domain space that is at least two orders of magnitude larger than comparable metrics of the current environment.
スケーラビリティのために、この表現要件の背後にある基本的な目的は、インターネットの構造の中のトレンドに近い可能性が高いが、階層的な凝集構造の背後にある個別のネットワークエンティティの数が多い、と少し弾み間の密な相互接続のパターンで連続であるということです。さておき、慎重なビューは、匹敵メトリックよりも少なくとも二桁大きいドメイン間空間での接続性の規模を包含するだろうことを示してから、要件のこの調査の中にスケーラビリティ上の任意の特定のメトリックを配置する目的ではありません現在の環境。
Any routing system should behave in a stable and predictable fashion. What is inferred from the predictability requirement is the behavior that under identical environmental conditions the routing system should converge to the same state. Stability implies that the routing state should be maintained for as long as the environmental conditions remain constant. Stability also implies a qualitative property that minor variations in the network's state should not cause large scale instability across the entire network while a new stable routing state is reached. Instead, routing changes should be propagated only as far as necessary to reach a new stable state, so that the global requirement for stability implies some degree of locality in the behavior of the system.
任意のルーティングシステムは安定し、予測可能な方法で振る舞う必要があります。どのような予測可能性の要件から推測されることは、同一の環境条件の下で、ルーティングシステムが同じ状態に収束しなければならない行動です。安定性は、ルーティング状態があれば、環境条件が一定として維持されなければならないことを意味します。安定性はまた、新しい安定したルーティング状態に達している間に、ネットワークの状態のわずかな変動は、ネットワーク全体の大規模な不安定性を引き起こしてはならない定性的な性質を意味します。代わりに、ルーティングの変更は、安定性のための世界的な要件は、システムの動作に地域のいくつかの程度を意味するように、新しい安定状態に到達するまでしか、必要に応じて伝播されなければなりません。
Any routing system should have adequate convergence properties. By adequate it is implied that within a finite time following a change in the external environment, the routing system will have reached a shared common description of the network's topology that accurately describes the current state of the network and is stable. In this case finite time implies a time limit that is bounded by some upper limit, and this upper limit reflects the requirements of the routing system. In the case of the Internet this convergence time is currently of the order of hundreds of seconds as an upper bound on convergence. This long convergence time is perceived as having a negative impact on various applications, particularly those that are time critical. A more useful upper bound for convergence is of the order of seconds or lower if it is desired to support a broad range of application classes.
任意のルーティングシステムは、十分な収束特性を有するべきです。十分なことで、それが有限の時間内に、外部環境の変化に追従することを暗示された、ルーティングシステムは、正確にネットワークの現在の状態を説明し、安定したネットワークのトポロジの共通の記述に達しています。この場合には有限の時間は、いくつかの上限値によって制限される制限時間を意味し、この上限は、ルーティングシステムの要件を反映しています。インターネットの場合、この収束時間は、現在、収束の上限として数百秒のオーダーです。この長い収束時間は、種々の用途、タイムクリティカルであることが特にものに負の影響を有するものとして知覚されます。アプリケーションクラスの広い範囲をサポートすることが望まれる場合、収束のためのより多くの有用な上限は秒以下のオーダーです。
It is not a requirement to be able to undertake full convergence of the inter-domain routing system in the sub-second timescale.
サブ秒のタイムスケールでドメイン間ルーティングシステムの完全な収束を行うことができるようにする必要はありません。
The greater the amount of information passed within the routing system, and the greater the frequency of such information exchanges, the greater the level of expectation that the routing system can maintain an accurate view of the connectivity of the network. Equally, the greater the amount of information passed within the routing system, and the higher the frequency of information exchange, the higher the level of overhead consumed by operation of the routing system. There is an element of design compromise in a routing system to pass enough information across the system to allow each routing element to have adequate local information to reach a coherent local view of the network, yet ensure that the total routing overhead is low.
ルーティングシステムは、ネットワークの接続性の正確なビューを維持することができるという期待のレベルが大きいほど、ルーティングシステム内で渡される情報の量が多いほど、そのような情報交換の頻度も大きいです。均等ルーティングシステム内で渡される情報の量、より大きな、およびルーティングシステムの動作によって消費されるオーバヘッドのレベルの情報交換の頻度が高いほど、より高いです。各ルーティングエレメントは、ネットワークのコヒーレントローカルビューに到達するのに十分なローカルな情報を持っている、まだ総ルーティングオーバーヘッドが低いことを確認することを可能にするシステム全体の十分な情報を渡すためのルーティングシステムにおける設計の妥協の要素があります。
This document does not attempt to define an inter-domain routing protocol that possess all the attributes as listed above, but a number of architectural considerations can be identified that would form an integral part of the protocol design process.
この文書では、上記のように、すべての属性を持っているドメイン間ルーティングプロトコルを定義しようとしませんが、建築検討事項の数は、プロトコル設計プロセスの不可欠な部分を形成することを識別することができます。
The two major approaches to routing protocols are distance vector and link state.
ルーティングプロトコルには2つの主要なアプローチは、距離ベクトルとリンク状態です。
In the distance vector protocol a routing node gathers information from its neighbors, applies local policy to this information and then distributes this updated information to its neighbors. In this model the nature of the local policy applied to the routing information is not necessarily visible to the node's neighbors, and the process of converting received route advertisements into advertised route advertisements uses a local policy process whose policy rules are not visible externally. This scenario can be described as 'policy opaque'. The side effect of such an environment is that a third party cannot remotely compute which routes a network may accept and which may be re-advertised to each neighbor.
距離ベクトルプロトコルでは、ルーティングノードは、その近隣から情報を収集し、この情報にローカルポリシーを適用し、次いでその隣に、この更新された情報を配信します。このモデルではルーティング情報に適用されるローカルポリシーの性質は、必ずしもノードの近隣には見えない、そしてアドバタイズルートアドバタイズに受信した経路広告を変換するプロセスは、そのポリシールール外部から見えないローカルポリシープロセスを使用します。このシナリオでは、「政策の不透明」として記述することができます。このような環境の副作用は、第三者が遠隔ネットワークが受け入れることができ、これは、各ネイバーに再アドバタイズすることができる経路を計算することができないということです。
In link state protocols a routing node effectively broadcasts its local adjacencies, and the policies it has with respect to these adjacencies, to all nodes within the link state domain. Every node can perform an identical computation upon this set of adjacencies and associated policies in order to compute the local forwarding table. The essential attribute of this environment is that the routing node has to announce its routing policies, in order to allow a remote node to compute which routes will be accepted from which neighbor, and which routes will be advertised to each neighbor and what, if any, attributes are placed on the advertisement. Within an interior routing domain the local policies are in effect metrics of each link and these polices can be announced within the routing domain without any consequent impact.
リンク状態プロトコルでルーティングノードは、効果的にそのローカル隣接関係をブロードキャストし、およびポリシーは、リンクステートドメイン内のすべてのノードに、これらの隣接に対して有しています。各ノードはローカル転送テーブルを計算するために隣接し、関連するポリシーのこのセットに同じ計算を行うことができます。この環境の基本的な属性は、ルーティングノードがどのネイバーから受け入れられる、そしてどのルートが各ネイバーにアドバタイズされます、何があればどのルート計算するために、リモート・ノードを可能にするために、そのルーティング方針を発表しなければならないことです、属性が広告に配置されます。内部ルーティングドメイン内のローカルポリシーは、各リンクの効果の指標であり、これらのポリシーは、任意の結果的な影響を与えることなく、ルーティングドメイン内で発表することができます。
In the exterior routing domain it is not the case that interconnection policies between networks are always fully transparent. Various permutations of supplier / customer relationships and peering relationships have associated policy qualifications that are not publicly announced for business competitive reasons. The current diversity of interconnection arrangements appears to be predicated on policy opaqueness, and to mandate a change to a model of open interconnection policies may be contrary to operational business imperatives.
外部ルーティングドメインでは、ネットワーク間の相互接続ポリシーは、常に完全に透過的であるとは限りません。サプライヤ/顧客関係の様々な順列とピアリング関係は、公的事業競争力のある理由のために発表されていないポリシーの資格が関連付けられています。相互接続契約の現在の多様性は、政策の不透明性を前提とすること、および運用業務要請に反するかもしれオープン相互接続政策のモデルへの変更を強制するように見えます。
An inter-domain routing tool should be able to support models of interconnection where the policy associated with the interconnection is not visible to any third party. If the architectural choice is a constrained one between distance vector and link state, then this consideration would appear to favor the continued use of a distance vector approach to inter-domain routing. This choice, in turn, has implications on the convergence properties and stability of the inter-domain routing environment. If there is a broader spectrum of choice, the considerations of policy-opaqueness would still apply.
ドメイン間ルーティングツールは、相互に関連付けられたポリシーは、第三者に表示されていない相互接続のモデルをサポートすることができなければなりません。建築の選択は距離ベクトルとリンク状態の間に拘束されたものである場合、この考察は、ドメイン間ルーティングへの距離ベクトルアプローチの継続的な使用を好むように見えます。この選択は、今度は、ドメイン間ルーティング環境の収束性と安定性に影響を与えます。選択肢の広いスペクトルがある場合は、ポリシー・不透明の考慮事項は、まだ適用されます。
The current issues with the trend behaviors of the BGP space can be coarsely summarized as the growth in the number of distinct routing objects, the increased level of dynamic behaviors of these objects (in the form of announcements and withdrawals).
BGP空間の傾向挙動と現在の問題は、粗異なるルーティングオブジェクトの数、（アナウンスと引き出しの形で）、これらのオブジェクトの動的挙動の増加したレベルの成長のように要約することができます。
This entails evaluating possible measures that can address the growth rate in the number of objects in the inter-domain routing table, and separately examining measures that can reduce the level of dynamic change in the routing table. The current routing architecture defines a basic unit of a route object as an originating AS number and an address prefix.
これは、ドメイン間ルーティングテーブル内のオブジェクト、およびルーティングテーブル内の動的変化のレベルを低下させることができ、別々に調べる小節数の成長速度に対処することができる可能な対策を評価することを伴います。現在のルーティングアーキテクチャは数AS元アドレスプレフィックスとしてルートオブジェクトの基本単位を定義します。
In looking at the growth rate in the number of route objects, the salient observation is that the number of route objects is the byproduct of the density of the interconnection mesh and the number of discrete points where policy is imposed of route objects. One approach to reduce the growth in the number of objects is to allow each object to describe larger segments of infrastructure. Such an approach could use a single route object to describe a set of address prefixes, or a collection of ASs, or a combination of the two. The most direct form of extension would be to preserve the assumption that each routing object represents an indivisible policy entity. However, given that one of the drivers of the increasing number of route objects is a proliferation of discrete route objects, it is not immediately apparent that this form of aggregation will prove capable in addressing the growth in the number of route objects.
ルートオブジェクトの数の成長率を見ると、顕著な観察は、ルートオブジェクトの数が相互メッシュの密度とポリシーがルートオブジェクトで課せられる離散点の数の副生成物であるということです。オブジェクト数の増加を低減する一つのアプローチは、各オブジェクトは、インフラストラクチャのより大きなセグメントを記述することを可能にすることです。そのようなアプローチは、アドレスプレフィックスの集合、又はのASのコレクション、またはこの2つの組合せを記述するために1つのルートオブジェクトを使用することができます。拡張の最も直接的な形は、各ルーティングオブジェクトは不可分ポリシーエンティティを表す仮定を維持することであろう。しかし、ルートオブジェクトの増加のドライバの一方が離散ルートオブジェクトの増殖であることを考えると、凝集のこの形態は、ルートオブジェクトの数の増加に対処することができることを証明することが直ちに明らかではありません。
If single route objects are to be used that encompass a set of address prefixes and a collection of ASs, then it appears necessary to define additional attributes within the route object to further qualify the policies associated with the object in terms of specific prefixes, specific ASs and specific policy semantics that may be considered as policy exceptions to the overall aggregate
1つのルートオブジェクトは、アドレスプレフィックスのセットとお尻のコレクションを包含するように使用される場合、さらに、特定の接頭辞の面でオブジェクトに関連付けられたポリシーを修飾するために、ルートオブジェクト内の追加の属性を定義する必要が表示され、特定のAS全体の集計にポリシーの例外として考えてもよいし、特定のポリシーのセマンティクス
Another approach to reduce the number of route objects is to reduce the scope of advertisement of each routing object, allowing the object to be removed and proxy aggregated into some larger object once the logical scope of the object has been reached. This approach would entail the addition of route attributes that could be used to define the circumstances where a specific route object would be subsumed by an aggregate route object without impacting the policy objectives associated with the original set of advertisements.
ルートオブジェクトの数を減らすための別のアプローチは、オブジェクトの論理的範囲に達した後、オブジェクトが除去されると、プロキシは、いくつかの大きなオブジェクトに集約できるように、各ルーティング対象の広告の範囲を減少させることです。このアプローチは、特定のルートオブジェクトは、広告の元のセットに関連付けられたポリシー目標に影響を与えることなく、集約ルートオブジェクトによって包含されるであろう状況を定義するために使用することができる経路属性の付加を伴うであろう。
Attempting to place greater levels of detail into route objects is intended to address the dual role of the current BGP system as both an inter-domain connectivity maintenance protocol and as an implicit traffic engineering tool.
ルートオブジェクトに詳細の高いレベルを配置しようとすると、ドメイン間接続の保守プロトコルの両方としておよび暗黙のトラフィックエンジニアリングツールとして、現在のBGPシステムの二重の役割に取り組むことです。
In the current environment, advertisement of more specific prefixes with unique policy but with the same origin AS is often intended to create a traffic engineering response, where incoming traffic to an AS may be balanced across multiple paths. The outcome is that the control of the relative profile of load is placed with the originating AS. The way this is achieved is by using limited knowledge of the remote AS's route selection policy to explicitly limit the number of egress choices available to a remote AS. The most common route selection policy is the preference for more specific prefixes over larger address blocks. By advertising specific prefixes along specific neighbor AS connections with specific route attributes, traffic destined to these addresses is passed through the selected transit paths. This limitation of choice allows the originating AS to override the potential policy choices of all other ASs, imposing its traffic import policies at a higher level than the remote AS's egress policies.
現在の環境では、独自のポリシーを持つ複数の特定の接頭語の広告が、しばしばASへの着信トラフィックを複数のパス間でバランスすることができるトラフィックエンジニアリング応答を、作成するために意図されるのと同じ起源を持ちます。結果は、負荷の相対的プロファイルの制御は次のように発信して配置されることです。これが達成される方法は、明示的にリモートASに利用できる出口選択肢の数を制限するために、リモートASの経路選択ポリシーの限られた知識を使用することです。最も一般的なルート選択ポリシーは、より大きなアドレスブロックをより詳細に特定のプレフィックスのための好みです。特定のルートの属性との接続など、特定の隣人に沿って、特定のプレフィックスを広告することで、これらのアドレス宛てのトラフィックを選択トランジットパスを通されます。選択のこの制限は、リモートASの出口政策よりも高いレベルでのトラフィックのインポートポリシーを課すこと、他のすべてのASの潜在的な政策選択を上書きするように、発信することができます。
An alternative approach is the use of a class of traffic engineering attributes that are attached to an aggregate route object. The intent of such attributes is to direct each remote AS to respond to the route object in a manner that equates to the current response to more specific advertisements, but without the need to advertise specific prefix route objects. However, even this approach uses route objects to communicate traffic engineering policy, and the same risk remains that the route table is used to carry fine-detailed traffic path policies.
別のアプローチは、集約ルートオブジェクトに添付されているトラフィックエンジニアリング属性のクラスを使用することです。このような属性の意図は、より具体的な広告に対する電流応答に相当する方法で、ルートオブジェクトに応答するが、特定のプレフィックスのルートオブジェクトを宣伝する必要なしにするように各リモートを向けることです。しかし、このアプローチは、トラフィックエンジニアリングポリシーを伝えるために、ルートオブジェクトを使用し、同じリスクは、ルートテーブルを微詳細なトラフィックパスポリシーを運ぶために使用されていることに変わりはありません。
An alternative direction is to separate the functions of connectivity maintenance and traffic engineering, using the routing protocol to identify a number of viable paths from a source AS to a destination AS, and use a distinct collection of traffic engineering tools to allow a traffic source AS to make egress path selections that match the desired traffic service profile for the traffic.
代替の方向は、宛先としてのようなソースから実行可能なパスの数を識別するために、ルーティングプロトコルを使用して、接続の維持及びトラフィックエンジニアリングの機能を分離し、トラフィックソースをAS許可するトラフィックエンジニアリングツールの別個のコレクションを使用することですトラフィックのために必要な交通サービスプロファイルに一致する出力パスの選択を行います。
There is one critical difference between traffic engineering approaches as used in intra-domain environments and the current inter-domain operating practices. Whereas the intra-domain environment uses the ingress network element to make the appropriate path choice to the egress point, the inter domain traffic engineering has the opposite intent, where a downstream AS (or egress point) is attempting to influence the path choice of an upstream AS (or ingress point). If explicit traffic engineering were undertaken within the inter-domain space, it is highly likely that the current structure would be altered. Instead of the downstream element attempting to constrain the path choices of an upstream element, a probable approach is the downstream element placing a number of advisory constraints on the upstream elements, and the upstream elements using a combination of these advisory constraints, dynamic information relating to path service characteristics and local policies to make an egress choice.
ドメイン内の環境下で使用されるような交通工学的アプローチと現在のドメイン間の事業慣行の間に1つの重要な違いがあります。ドメイン内の環境は退出ポイントに適切なパスの選択をするために、入口ネットワーク要素を使用するのに対し、ドメイン間のトラフィックエンジニアリングは、（または出口点）AS下流のパスの選択に影響を与えるためにしようとしている反対の意思を持っています上流AS（または入口点）。明示的なトラフィックエンジニアリングは、ドメイン間の空間内で行われた場合、現在の構造が変更されること可能性が高いです。代わりに、上流の要素の経路の選択を制限しようと下流要素の、可能性のアプローチは、上流エレメント諮問制約、及びこれらアドバイザリー制約の組み合わせを使用して、上流の要素の数を確定下流要素に関連する動的な情報でありますパスサービスの特性と出力選択をするローカルポリシー。
From the perspective of the inter-domain routing environment, such measures offer the potential to remove the advertisement of specific routes for traffic engineering purposes. However, there is a need to adding traffic engineering information into advertised route blocks, requiring the definition of the syntax and semantics of traffic engineering attributes that can be attached to route objects.
ドメイン間ルーティング環境の観点から、このような対策は、トラフィックエンジニアリングの目的で、特定のルートの広告を削除する可能性を提供します。しかし、ルートオブジェクトに取り付けることができるトラフィックエンジニアリング属性の構文とセマンティクスの定義を必要とし、宣伝ルートブロックにトラフィックエンジニアリング情報を追加する必要があります。
The CIDR routing model assumed a hierarchy of providers, where at each level in the hierarchy the routing policies and address space of networks at the lower level of hierarchy were subsumed by the next level up (or 'upstream') provider. The connectivity policy assumed by this model is also a hierarchical model, where horizontal connections within a single level of the hierarchy are not visible beyond the networks of the two parties.
CIDRルーティングモデルは、階層の各レベルでのルーティングポリシーと階層のより低いレベルでのネットワークのアドレス空間は、次のレベルアップ（または「上流」）プロバイダによって包含されたプロバイダの階層を仮定しました。このモデルによって想定接続ポリシーはまた、階層の単一レベル内の水平方向の接続は、2人の当事者のネットワークを越えて表示されていない階層モデルです。
A number of external factors are increasing the density of interconnection including decreasing unit costs of communications services and the increasing use of exchange points to augment point-to-point connectivity models with point-to-multi-point facilities.
外部要因の数は、ポイントツーマルチポイント設備がポイント・ツー・ポイント接続モデルを増強するユニット通信サービスの費用と交換ポイントの使用の増加を減少させることを含む、相互接続の密度が増加しています。
The outcome of these external factors is a significant reduction in the hierarchical nature of the inter-domain space. Such a trend can be viewed with concern given the common approach of using hierarchies as a tool for scaling routing systems. BGP falls within this approach, and relies on hierarchies in the address space to contain the number of independently routing objects. The outcomes of this characteristic of the Internet in terms of the routing space is the increasing number of distinct route policies that are associated with each multi-homed network within the Internet.
これらの外部要因の結果は、ドメイン間のスペースの階層的性質が大幅に減少します。そのような傾向は、ルーティングシステムをスケーリングするためのツールとして階層を使用する一般的な手法所与の関心事で見ることができます。 BGPは、このアプローチに収まる、と独立してルーティングオブジェクトの数を格納するアドレス空間に階層に依存しています。ルーティング・スペースの点でインターネットのこの特徴の結果は、インターネット内の各マルチホームネットワークに関連付けられている個別のルートポリシーの増加です。
One way to limit the proliferation of such policies across the entire inter-domain space is to associate attributes to such advertisements that specify the conditions whereby a remote transit AS may proxy-aggregate this route object with other route objects.
全体のドメイン間の空間を横切って、そのようなポリシーの増殖を制限するための一つの方法は、条件を指定して、そのような広告の属性を関連付けることができる月プロキシ集合として遠隔トランジット他のルートオブジェクトと、このルートオブジェクト。
A final consideration is to consider whether these requirements can best be met by an approach of a set of upward-compatible extensions to BGP, or by a replacement to BGP. No recommendation is made here, and this is a topic requiring further investigation.
最後の考慮事項は、これらの要件は、最高のBGPへの上位互換の拡張セットのアプローチによって、またはBGPへの置換によって満たすことができるかどうかを検討することです。いかなる勧告はここで行われていない、これはさらなる調査が必要なトピックです。
The general approach in extending BGP appears to lie in increasing the number of supported transitive route attributes, allowing the route originator greater control in specifying the scope of propagation of the route and the intended outcome in terms of policy and traffic engineering. It may also be necessary to allow BGP sessions to negotiate additional functionality intended to improve the convergence behavior of the protocol. Whether such changes can produce a scalable and useful outcome in terms of inter-domain routing remains, at this stage, an open question.
BGPを拡張における一般的なアプローチは、ポリシーおよびトラフィックエンジニアリングの観点から経路および意図する結果の伝播の範囲を特定の経路発信より大きな制御を可能にする、サポートされている推移ルート属性の数を増加させることにあると思われます。また、BGPセッションは、プロトコルの収束挙動を改善することを目的と追加機能を交渉することを可能にする必要があります。このような変化は、ドメイン間ルーティングの面でスケーラブルかつ有用な結果を生成することができますかどうかは、この段階では、未解決の問題のまま。
An alternative approach is that of a replacement protocol, and such an approach may well be based on the adoption of a link-state behavior. The issues of policy opaqueness and link-state protocols have been described above. The other major issue with such an approach is the need to limit the extent of link state flooding, where the inter-domain space would need some further levels of imposed structure similar to intra-domain areas. Such structure may well imply the need for an additional set of operator inter-relationships such as mutual transit, and this may prove challenging to adapt to existing practices.
別のアプローチは、その交換プロトコルであり、そのようなアプローチは当リンク状態行動の採用に基づくことができます。政策の不透明性およびリンクステートプロトコルの問題は、上記に記載されています。そのようなアプローチの他の主要な問題は、ドメイン間の空間は、ドメイン内の領域と同様課された構造のいくつかのさらなるレベルを必要とするリンクステートフラッディングの範囲を制限することが必要です。このような構造は十分な相互トランジットなどのオペレータの相互関係の追加セットの必要性を暗示することができ、これは、既存の慣行に適応するための挑戦を証明することがあります。
The potential sets of actions include more than extend or replace the BGP protocol. A third approach is to continue to use BGP as the basic means of propagating route objects and their associated AS paths and other attributes, and use one or more overlay protocols to support inter-domain traffic engineering and other forms of inter-domain policy negotiation. This approach would appear to offer a means of transition for the large installed base currently using BGP4 as their inter-domain routing protocol, placing additional functionality in the overlay protocols while leaving the basic functionality of BGP4 intact. The resultant inter-dependencies between BGP and the overlay protocols would require very careful attention, as this would be the most critical aspect of such an approach.
アクションの潜在的なセットは、BGPプロトコルを拡張または交換以上のものを含んでいます。第三のアプローチは、パスやその他の属性として関連付けられたルートオブジェクトとそのを伝播する基本的な手段として、BGPを使用して、ドメイン間のトラフィックエンジニアリングとドメイン間ポリシー交渉の他の形態をサポートするために、1つのまたは複数のオーバーレイ・プロトコルを使用し続けることです。このアプローチは、現在、無傷のBGP4の基本的な機能を残しつつ、オーバーレイ・プロトコルに追加機能を配置し、それらのドメイン間ルーティングプロトコルとしてBGP4を使用して大規模なインストールベースの移行の手段を提供するように思われます。これは、このようなアプローチの最も重要な側面であるようにBGPとオーバーレイプロトコル間の結果の相互依存性は、非常に細心の注意が必要となります。
While there may exist short term actions based on providing various incentives for network operators to remove redundant or inefficiently grouped entries from the BGP routing table, such actions are short term palliative measures, and will not provide long term answers to the need to a scalable inter-domain routing protocol.
BGPルーティングテーブルから冗長または非効率的にグループ化されたエントリを削除するネットワーク・オペレータのための様々なインセンティブを提供することに基づいて、短期行動が存在するかもしれないが、そのようなアクションは、短期緩和策であり、スケーラブル間に必要に長期的回答を提供しないであろう-domainルーティングプロトコル。
One potential short term protocol refinement is to allow a set of grouped advertisements to be aggregated into a single route advertisement. This form of proxy aggregation would take a set of bit-wise aligned routing entries with matching route attributes, and under certain well identified circumstances, aggregate these routing entries into a single re-advertised aggregate routing entry. This technique removes information from the routing system, and some care must be taken to define a set of proxy aggregation conditions that do not materially alter the flow of traffic, or the ability of originating ASes to announce routing policy.
一つの可能性のある短期プロトコル改良は、グループ化された広告の組は、単一の経路広告に集約できるようにすることです。プロキシ凝集のこの形態は、一致ルート属性をビット単位に整列ルーティングエントリのセットを取り、特定のウェル同定状況下では、単一の再アドバタイズ集約ルーティングエントリにこれらのルーティングエントリを集約することになります。この技術は、ルーティングシステムから情報を削除し、そしていくつかの注意が著しく交通の流れ、またはルーティングポリシーを発表する発信元のASの能力を変更しないプロキシ集約条件のセットを定義するために取られなければなりません。
A further refinement to this approach is to consider the definition of the syntax and semantics of a number of additional route attributes. Such attributes could define the extent to which specific route advertisements should be propagated in the inter-domain space, allowing the advertisement to be subsumed by a larger aggregate advertisement at the boundary of this domain. This could be used to form part of the preconditions of automated proxy aggregation of specific routes, and also limit the extent to which announcement and withdrawals are propagated across the routing domain.
このアプローチのさらなる改良は、追加のルート属性の数の構文とセマンティクスの定義を検討することです。このような属性は、広告は、このドメインの境界で大きな集約広告に包含することができるように、特定のルート広告は、ドメイン間の空間に伝播すべき範囲を定義することができます。これは、特定のルートの自動プロキシ凝集の前提条件の一部を形成し、また、アナウンス及び引き出しがルーティングドメインを横切って伝播される程度を制限するために使用することができます。
It is unclear that such measures would result in substantial longer term changes to the scaling and convergence properties of BGP4. Taking the requirement set enumerated in section 6 of this document, one approach to the longer term requirements may be to preserve a number of attributes of the current BGP protocol, while refine other aspects of the protocol to improve its scaling and convergence properties. A minimal set of alterations could retain the Autonomous System concept to allow for boundaries of information summarization, as well as retaining the approach of associating each prefix advertisement with an originating AS. The concept of policy opaqueness would also be retained in such an approach, implying that each AS accepts a set of route advertisements, applies local policy constraints, and re-advertises those advertisements permitted by the local policy constraints. It could be feasible to consider alterations to the distance vector path selection algorithm, particularly as it relates to intermediate states during processing of a route withdrawal. It is also feasible to consider the use of compound route attributes, allowing a route object to include an aggregate route, and a number of specifics of the aggregate route, and attach attributes that may apply to the aggregate or a specific address prefix. Such route attributes could be used to support multi-homing and inter-domain traffic engineering mechanisms. The overall intent of this approach is to address the major requirements in the inter-domain routing space without using an increasing set of globally propagated specific route objects.
このような措置はBGP4のスケーリングと収束の特性にかなりの長期的な変化をもたらすことは明らかではありません。この文書のセクション6に列挙要件セットを取って、長期的な要件に対する1つのアプローチは、そのスケーリングと収束特性を改善するためのプロトコルの他の態様を改善しながら、現在のBGPプロトコルの属性の数を保存することができます。変化の最小セットは、情報集約の境界を可能にするために自律システムのコンセプトを維持するだけでなく、元のASと各プレフィックスの広告を関連付けるのアプローチを保持できます。ポリシー不透明の概念は、各ASは、経路広告のセットを受け入れることを意味し、このような方法で保持される、ローカルポリシーの制約を適用し、ローカルポリシーの制約により許可されるものの広告を再アドバタイズ。経路離脱の処理中に中間状態に関し、特にように、距離ベクトル経路選択アルゴリズムへの変更を検討することが可能であってもよいです。集約ルート、および集約ルートの詳細の数が含まれるように、ルートオブジェクトを許可する、化合物のルート属性の使用を考慮し、集約または特定のアドレスプレフィックスに適用される可能性のある属性を添付することも可能です。このようなルートの属性は、マルチホーミングとインタードメイントラフィックエンジニアリングメカニズムをサポートするために使用することができます。このアプローチの全体的な意図は、世界的に伝播し、特定のルートオブジェクトの増加セットを使用せずに、ドメイン間ルーティング空間の主要な要件に対処することです。
A potential applied research topic is to consider the feasibility of de-coupling the requirements of inter-domain connectivity management with the applications of policy constraints and the issues of sender-and/or receiver-managed traffic engineering requirements. Such an approach may use a link-state protocol as a means of maintaining a consistent view of the topology of inter-domain network, and then use some form of overlay protocol to negotiate policy requirements of each AS, and use a further overlay to support inter-domain traffic engineering requirements. The underlying assumption of such an approach is that by dividing up the functional role of inter-domain routing into distinct components each component will have superior scaling and convergence properties which in turn to result in superior properties for the entire routing system. Obviously, this assumption requires some testing.
潜在的な応用研究テーマは、デカップリング政策の制約のアプリケーションや送信者および/または受信機が管理するトラフィックエンジニアリング要件の問題でドメイン間接続管理の要件の実現可能性を検討することです。そのようなアプローチは、ドメイン間のネットワークのトポロジーの一貫したビューを維持するための手段として、リンクステートプロトコルを使用し、各ASのポリシー要件を交渉するオーバーレイプロトコルのいくつかのフォームを使用し、サポートするようにさらにオーバーレイを使用することができますインタードメイントラフィックエンジニアリング要件。そのようなアプローチの基礎となる仮定は、別個のコンポーネントにドメイン間ルーティングの機能的役割を分割することによって、各構成要素は順番に全体ルーティングシステムのための優れた特性をもたらすために、優れたスケーリングと収束特性を有することです。明らかに、この仮定は、いくつかのテストが必要です。
Research topics with potential longer term application include the approach of drawing a distinction between a network's identity, a network's location relative to other networks, and a feasible path between a source and destination network that satisfies various policy and traffic engineering constraints. Again the intent of such an approach would be to divide the current routing function into a number of distinct scalable components.
潜在的な長期的なアプリケーションとの研究テーマは、ネットワークのアイデンティティ、他のネットワークへのネットワークの場所の相対的な区別を描くのアプローチ、および様々な政策やトラフィックエンジニアリング制約を満たす元と宛先ネットワークの間の可能なパスを含めます。再び、そのようなアプローチの目的は、別個のスケーラブルな構成要素の数に現在のルーティング機能を分割することであろう。
Any adopted inter-domain routing protocol needs to be secure against disruption. Disruption comes from two primary sources:
任意採用ドメイン間ルーティングプロトコルは、破壊に対して安全である必要があります。破壊は、二つの主要な要因から生じます。
- Accidental misconfiguration - Malicious attacks
- 偶然の設定ミス - 悪意のある攻撃
Given past experience with routing protocols, both can be significant sources of harm.
ルーティングプロトコルとの過去の経験を考えると、両方のは、危害の重大な源となることができます。
Given that it is not reasonable to guarantee the security of all the routers involved in the global Internet inter-domain routing system, there is also every reason to believe that malicious attacks may come from peer routers, in addition to coming from external sources.
グローバルなインターネットドメイン間ルーティングシステムに関与するすべてのルータのセキュリティを保証することは合理的ではないことを考えると、悪意のある攻撃は、外部ソースから来るに加えて、ピアルータから来るかもしれないことを信じる十分な理由もあります。
A protocol design should therefore consider how to minimize the damage to the overall routing computation that can be caused by a single or small set of misbehaving routers.
プロトコルの設計は、したがって、不正動作するルータの単一または小さな集合によって引き起こされる可能性が全体的なルーティング計算への損傷を最小限にする方法を検討すべきです。
The routing system itself needs to be resilient against accidental or malicious advertisements of a route object by a route server not entitled to generate such an advertisement. This implies several things, including the need for cryptographic validation of announcements, cryptographic protection of various critical routing messages and an accurate and trusted database of routing assignments via which authorization can be checked.
ルーティングシステム自体がそのような広告を生成する権利がないルート・サーバによってルートオブジェクトの偶発的または悪意のある広告に対して弾力的である必要があります。これは、発表の暗号検証の必要性、様々な重要なルーティングメッセージの暗号保護と認可を確認することができ、それを介してルーティングの割り当ての正確かつ信頼できるデータベースを含むいくつかのことを、意味しています。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[2] Clark, D., Chapin, L., Cerf, V., Braden, R. and R. Hobby, "Towards the Future Internet Architecture", RFC 1287, December 1991.
[2]クラーク、D.、チャピン、L.、サーフ、V.、ブレーデン、R.とR.趣味、RFC 1287 "未来のインターネットアーキテクチャに向けて"、1991年12月。
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, December 1998.
[3]デアリング、S.とR. Hindenと「インターネットプロトコル、バージョン6（IPv6）の仕様、RFC 2460（1998年12月）。
[4] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[4] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。
[5] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[5]フラー、V.、李、T.、ゆう、J.及びK. Varadhan、 "クラスレスドメイン間ルーティング（CIDR）：アドレス割り当ておよび集約戦略"、RFC 1519、1993年9月。
[6] Huston, G., "The BGP Routing Table", The Internet Protocol Journal, vol. 4, No. 1, March 2001.
[6]ヒューストン、G.、 "BGPルーティングテーブル"、インターネット・プロトコル・ジャーナル、巻。 4、第1号、2001年3月。
[7] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[7] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[8] Vohara, Q. and E. Chen, "BGP support for four-octet AS number space", Work in Progress.
[8] Vohara、Q.およびE.チェン、「番号空間AS 4オクテットのためのBGPサポート」が進行中で働いています。
[9] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[9]ハイン、T.、 "NATの建築的意味"、RFC 2993、2000年11月。
[10] Labovitz, C., Ahuja, A., Bose, A. and J. Jahanian, "Delayed Internet Routing Convergence", Proceedings ACM SIGCOMM 2000, August 2000.
[10] Labovitz、C.、アフジャ、A.、ボーズ、A.およびJ. Jahanian、 "遅延インターネットルーティング収束"、議事録のACM SIGCOMM 2000、2000年8月。
[11] Lothberg, P., personal communication, December 2000.
[11] Lothberg、P.、私信、2000年12月。
This document is the outcome of a collaborative effort of the IAB, and the editor acknowledges the contributions of the members of the IAB in the preparation of the document. The contributions of John Leslie, Thomas Narten and Abha Ahuja in reviewing this document are also acknowledged.
このドキュメントは、IABの共同の努力の結果である、と編集者は、文書の作成にIABのメンバーの貢献を認めています。この文書のレビューではジョン・レスリー、トーマスNarten氏とアブハアフジャの貢献も認めています。
Internet Architecture Board Email: iab@ietf.org
インターネットアーキテクチャ委員会メールアドレス：iab@ietf.org
Geoff Huston Telstra 5/490 Northbourne Ave Dickson ACT 2602 Australia
ジェフ・ヒューストンテルストラ490分の5ノースボーンアベニューディクソンACT 2602オーストラリア
EMail: gih@telstra.net
メールアドレス：gih@telstra.net
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。