[要約] RFC 3221は、インターネットにおける異ドメインルーティングに関する解説であり、その目的はインターネットのルーティングプロトコルの設計と運用に関するガイドラインを提供することです。
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.
Copyright（c）The Internet Society（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テーブルのエントリの平均プレフィックス長が含まれます。より大きな長期的な問題は、ASE間のますます密度の高い接続性メッシュの問題であり、ドメイン間政策のより細かい程度の粒度と、ドメイン間の交通工学を引き受けるためのより細かいレベルの制御を引き起こすことです。
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.
インターネットの基本構造は、接続されたドメインを形成するために相互接続されたネットワークまたは自律システム（ASE）のコレクションです。それぞれがAS内のトポロジーの一貫したビューを維持するためにインテリアルーティングシステムを使用し、外部ルーティングシステムを使用して隣接するASESで隣接情報を維持して、システム全体の接続性のビューを作成します。
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.
このネットワーク全体の接続性は、BGP4プロトコル（ルーティング情報ベースまたはリブと呼ばれる）で使用されるルーティングテーブルで説明されています。テーブル内の各エントリは、異なるルートを指します。ルートの属性は、ローカルポリシーの制約とともに、ルートを発信しているようにローカルからの最適なパスを決定するために使用されます。この場合の「最良のパス」を決定することは、どのルーティング広告と関連する次のホップアドレスがローカルASが最も好むかを決定することです。各ローカルBGP語を話すルーター内で、この優先ルートはローカルリブ（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 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は、最終的に広告されたルーティングエントリによって記述されたアドレスに運命づけられます。ローカルがルートを発生しない場合、推論は、一部の第三者に代わってこのトラフィックの輸送プロバイダーの役割を喜んで引き受けることをいとわないということです。同様に、隣人からのルートを受け入れることを選択する場合と選択できない場合があります。ルートを受け入れることは、ローカルルート選択パラメーターによって決定される状況によっては、ローカルがルートによって範囲に及ぶアドレスに到達するように隣接するようにローカルが使用することを意味します。BGPルーティングドメインは、インターインターASドメインの接続性のコヒーレントビューを維持することを目的としています。ここでは、接続性は「最短パス」が各ASが表現する接続ポリシーによって変調される任意の宛先アドレスに到達することを好み、コヒーレンスは、どのパスにもループや行き止まりが含まれていないというグローバルな制約として表されます。BGPルーティングドメインの要素は、アドレスの範囲として表されるルーティングエントリです。各ルーティングエントリ内で宣伝されているすべてのアドレスは、共通の起源と共通の接続ポリシーを共有します。したがって、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]の仕様、およびある程度の透明な相互作用を可能にすることを目的としたネットワークアドレス翻訳の技術の改良を含む多くの結果を生み出しました。異なるアドレスレルムを使用した2つのネットワーク間。ルーティングシステムの成長は、これらのアプローチによって直接対処されません。ルーティングスペースは、ネットワークのトポロジーとしての複雑さの交差積であり、異なる接続性ポリシーの数に断片化の程度を掛けた数に掛けているため住所スペース。たとえば、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.
Aがアドレスのブロックを外部ルーティングスペースに宣伝する場合、このエントリは通常、インターネットの外部ルーティングドメイン全体に掲載されます。グローバルルーティングテーブルの一般的な特性を測定するには、外部ルーティングドメインのデフォルトのない部分にポイントを確立し、その時点で表示される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.
ルーティングテーブルのサイズの測定は、開始するのに多少散発的であり、1988年から1992年までの概念間隔で多くの測定値がメリットによって行われました[5]。この取り組みは、1994年にオランダのSurfnetのErik-Jan Bosによって再開され、1994年にHourly間隔でBGPテーブルのサイズを測定し始めました。オーストラリアのテルストラでのAS 1221のエッジは、測定に1時間ごとの間隔を使用しています。最初の測定値は、選択した最良のパスのセットに含まれるルーティングエントリの数でした。これらの測定値は、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ルーティングテーブルの合計サイズのみを見ると、インターネットでのルーティング慣行の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のアドレス描写の要件を捨てたルーティングプロトコルの導入であり、このスキームをアドレスのプレフィックスと関連するプレフィックス長を伝えるルーティングシステムに置き換えました。このアプローチは、クラスレスドメイン間ルーティング（CIDR）と呼ばれました[5]。
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].
1994年と1995年に、BGPプロトコルのBGP4 [7]のCIDR利用可能なバージョンの展開を促進することに基づいて、インターネットにCIDRルーティングを展開するために協調した努力が行われました。
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の意図は、ネットワークプロバイダーがアドレスレジストリからアドレスブロックを割り当てられた階層プロバイダーアドレス集約の1つであり、プロバイダーはこのブロック全体を外部ルーティングドメインに単一のルーティングポリシーを持つ単一のエントリとして発表しました。プロバイダーの顧客は、プロバイダーのアドレスブロックからのサブアロケーションを使用することを奨励され、これらの小さなルーティング要素はプロバイダーによって集約され、外部ルーティングドメインに直接渡されませんでした。1994年、ルーティングテーブルのサイズは、アドレスブロックを発表するプロバイダーの数の増加がCIDR集約の結果としての住所アナウンスの数の減少と一致したため、約20,000のエントリで比較的一定のままでした。
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.
テーブルを綿密に調べると、現時点ではルーティングシステムの安定性が高くなります。発表されたルートの数の短期（時間ごとの）変動は、発表されたルートの数の割合と絶対的な用語でもあります。大規模な集約アドレスブロックを使用する他の利点の1つは、ネットワークの端での不安定性がすぐにルーティングコアに伝播されないことです。最後のホップでの不安定性は、より具体的なルートのコレクションの代わりに集計ルートが使用されるポイントで吸収されます。これは、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テーブルの総サイズの成長パターンにつながります。1999年1月から2000年12月までの期間のデータの適合性は、年間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ルーティングテーブルの分析のレベルは、この成長に寄与する要因を特定し、これがルーティングスペースの潜在的なサイズのいくつかの制限要因につながるかどうかを判断するために拡張されています。分析には、ルーティングシステムのASE数の測定と、パスとしての明確な数の測定が含まれます。各ルーティングエントリのテーブルと平均スパンで及ぶアドレスの範囲が含まれます。
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の数は、一意のルーティングポリシーを持つエンティティの数を追跡します。これには、さまざまな地域ポリシーを備えた大規模なグローバルトランジットプロバイダーなど、複数のASEが単一のネットワークに関連付けられていますが、そのような例外は比較的まれです。
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年間の数の展開の傾向は、複合成長モデルと年間51％の成長率と一致するものでもあります。2001年5月の開始時点で、BGPテーブルには約10,700のASが見えました。51％のP.A.の継続的な成長率では、16ビットAS数値スペースが2005年8月までに完全に展開されます。IETF内で作業が進行中で、BGPプロトコルを変更して32ビットフィールドに数字として運ばれます。[8]プロトコルの変更は比較的簡単ですが、主要な責任はオペレーションコミュニティにかかっており、この大きな数のスペースに徐々に移行できる移行計画を考案します。
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年の開始時に、ルーティングテーブルには、1,081,131,733のアドレス、つまりIPv4アドレススペースの約25.17％、つまり使用可能なユニキャストパブリックアドレススペースの25.4％が含まれていました。2001年9月までに、これは1,123,124,472のアドレス、つまりIPv4アドレス空間の約26％に成長しました。これは、1999年11月に1,019,484,655の住所から成長しました。しかし、BGPテーブルから定期的に発表され、撤回される /8の接頭辞がいくつかあり、これらのプレフィックスの効果が削除されれば、過去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％の成長と比較して、宣伝されている住所スペースの量の増加ははるかに低いです。考えられる説明の1つは、接続されたデバイスの数の成長の観点からインターネットの成長の多くが、さまざまな形のNATゲートウェイの背後で発生していることです。10年以内に特定されたアドレス空間の知覚された有限の性質を解決するという点では、この説明は、さまざまな知覚された機能的な欠点に関係なく、NATを使用するアプローチを受け入れているように見えることを示す傾向があります。[9]この説明は、BGPテーブルの明確なポリシーをサポートする小さなアドレスフラグメントの観察をサポートしています。そのような小さなアドレスブロックには、1つ以上のNATゲートウェイの後ろにある任意の大きな大きなネットワークが含まれる可能性があるためです。テーブルの成長とアドレス空間の成長との間には、この違いのこの違いの代替説明があります。これには、より細かいアドレスブロックに適用される離散外部ルーティングポリシーへの傾向が含まれます。
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ルーティングテーブルでの大規模な集約アドレスアナウンスの使用をサポートすることでした。これがまだ12か月間、各BGP発表の平均スパンが追跡されているかどうかを確認するため。このデータは、1999年11月の16,000個の個人アドレスから2000年12月の12,100へのBGP広告の平均広告の減少を示しています。これは、2000年12月までに/18.03から/18.44までの平均接頭辞の長さの増加に対応し、2001年9月までにA /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月には、それぞれが平均161,900の住所を宣伝しました（プレフィックス長/14.69に相当し、2001年1月にはこの平均は115,800のアドレスに低下しました。
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.
クラスCスペースの激しい使用から離れ、CIDRの取り組みの一環としてプロバイダーがより大きなアドレスブロックを宣伝することをプロバイダーに奨励するために、90年代半ばに大規模なプログラムが開始されました。これは、 /19および最近では /20のプレフィックス長に対応するプロバイダー割り当てブロックを使用したアドレスレジストリによって強化されています。
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テーブルに約20,000〜30,000のエントリがあった90年代半ばに導入されました。約6年後の2001年4月には、ルーティングテーブルの108,000のエントリのうち、約59,000のエントリがA /24プレフィックスがあることに注目することは興味深いことです。絶対的な用語では、 /24プレフィックスセットは、BGPルーティングテーブルで最も急速に成長しているセットです。これらの小さなアドレスブロックのルーティングエントリは、1時間ごとにはるかに高いレベルの変化を示しています。多数のBGPルーティングポイントはルートフラップダンピングを実行しますが、それでも、プレフィックスの長さごとのルート更新の視点を使用して表示された場合、ルーティングテーブルのこの特定の領域にこれらのエントリの発表と引き出しが非常に高いレベルがあります。これらの小さな接頭辞の数が急速に増加していることを考えると、フラップ減衰による圧力にもかかわらず、1秒あたりの発表数と引き出しの数が増加する可能性があるという点で、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システムが成長し続けるにつれて全体的な安定性を維持することに深刻な意味を持ちます。レジストリの割り当てポリシーは、ルーティングテーブルのプレフィックス分布にもある程度影響を与えました。元のレジストリの慣行は、A /19の最小割り当て単位を使用することであり、 /17〜 /19の範囲の10,000のプレフィックスエントリは、このポリシー決定の結果です。最近では、A /20プレフィックスの最小割り当てユニットが許可され、 /20プレフィックスは2001年1月の時点で約4,300のエントリで使用され、相対的な用語では、最も急速に成長しているプレフィックスセットの1つです。非常に小さなアドレスブロックに対応するエントリの数（a /24よりも小さい）は、総BGPルーティングテーブルの割合として数が少ないが、相対的な用語で最も急速に成長している。ルーティングテーブル内の /25から32の接頭辞の数は、ルーティングテーブルの他のどの領域よりも、変化率の点でより速く成長しています。接頭辞の長さフィルタリングが広範囲に使用されている場合、異なるルーティングポリシーを備えた非常に小さなアドレスブロックを発表する慣行は、グローバルBGPルーティングドメインと関連する関連の伝播全体に渡されないため、特に有益な結果はありません。ポリシーの範囲は制限されます。これらの小さなアドレスブロックの数の増加と、これらのルーティングエントリに関連するASパスの多様性は、今日のインターネットでのプレフィックス長フィルタリングの比較的限られた使用を示しています。プレフィックス長フィルタリングの広範な採用という形での是正圧力がない場合、非常に小さな住所ブロックのグローバルな発表の非常に急速な成長が続く可能性があります。パーセンテージの用語では、 /25〜 /32にまたがるプレフィックスのセットは、最大の成長率を示しています。
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.
このメカニズムのもう1つの使用は、マルチホームネットワークのために、初歩的な形式の負荷分散と相互バックアップを実行することです。このモデルでは、ネットワークは各接続に沿って同じ集約広告を宣伝する場合がありますが、各接続の特定の広告セットを宣伝し、各接続の負荷がほぼバランスになるように特定の広告を変更します。2つの形式の穴はルーティングテーブルで容易に識別できます - ポリシーの差別化のアプローチは、集約広告とは異なるASパスを使用しますが、ロードバランスと相互バックアップ構成は、集約とアグリゲートの両方のパスと同じを使用します。特定の広告。このような具体的な広告の使用が、より一般的なルールの例外であるかどうかを理解することは困難ですが、CIDRの展開の元の意図の範囲内ではないことを意図しているかどうかは、ルーティングテーブル内でこのメカニズムを非常に広く使用しているようです。約59,000の広告、つまりルーティングテーブルエントリの総数の55％が、既存の集計アナウンスのポリシーホールをパンチするために使用されています。これらのうち、約42,000ルートの全体的な過半数はパスとして異なるものを使用しているため、これは密に相互接続された空間における接続ポリシーの粒度の粒度がより細かくなっていることの証拠であると思われます。完全なルーティングテーブルの一部として、このような広告の相対的なレベルでは長期データは利用できませんが、成長レベルは、既存のプロバイダー集約内の微細なレベルでのポリシーの差別化が全体的なテーブルの成長の重要な要因であることを強く示しています。
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.
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テーブルの最近の成長の主要なドライバーの1つは、ルーティングテーブルにA /24プレフィックスエントリとして宣伝されており、多くのピアとアップストリームプロバイダーを備えたマルチホミングとして宣伝されている小さなネットワークのものであるように思われます。比較的近接している多くのネットワークがある適切な環境では、ピア関係を使用すると、単一のアップストリームサービスプロバイダーを使用するのと比較して、合計接続コストを削減できます。同様に、多くのアップストリームプロバイダーを備えたマルチホーミングは、サービスの全体的な可用性を改善する手段と見なされています。本質的に、マルチホーミングは、上流のサービス回復力の許容可能な代替品と見なされています。これには、マルチホーミングがアップストリームプロバイダーの回復力の好ましい代替品と見なされる場合、上流のプロバイダーは、提供されたサービスの属性としてレジリエンシーを証明するための価格プレミアムを命じることができず、したがって、したがって、使用する経済的インセンティブがほとんどないという潜在的な副作用があります。ネットワークへの回復力を設計するために必要な追加のお金。ネットワークのマルチホームクライアントのアクションは、自己実現になります。この動作を特徴付ける1つの方法は、インターネットでのサービスの回復力が、サービスプロバイダーではなく、顧客の責任になりつつあることです。
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.
これには、ドメイン間ルーティングテーブルのオブジェクトの数の成長率に対処できる可能性のある測定値を評価し、ルーティングテーブルの動的変化のレベルを低下させる可能性のある測定値を個別に調べることを伴います。現在のルーティングアーキテクチャは、ルートオブジェクトの基本ユニットを、数字とアドレスプレフィックスとして発信するものとして定義します。
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.
ルートオブジェクトの数の成長速度を見ると、顕著な観察は、ルートオブジェクトの数が相互接続メッシュの密度の副産物であり、ポリシーがルートオブジェクトに課される離散点の数であるということです。オブジェクトの数の成長を減らすための1つのアプローチは、各オブジェクトがインフラストラクチャのより大きなセグメントを記述できるようにすることです。このようなアプローチでは、単一のルートオブジェクトを使用して、アドレスプレフィックスのセット、お尻のコレクション、または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
アドレスのプレフィックスのセットと尻のコレクションを含む単一ルートオブジェクトを使用する場合、特定のプレフィックス、特定のASSの観点からオブジェクトに関連するポリシーをさらに適格にするために、ルートオブジェクト内の追加属性を定義する必要があると思われます。全体的な集計のポリシーの例外と見なされる可能性のある特定のポリシーセマンティクス
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の出口ポリシーよりも高いレベルで課されます。
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.
別の方向性は、接続のメンテナンスとトラフィックエンジニアリングの機能を分離し、ルーティングプロトコルを使用して、宛先としてソースから多くの実行可能なパスを識別し、トラフィックエンジニアリングツールの明確なコレクションを使用してトラフィックソースを許可することです。トラフィックの目的のトラフィックサービスプロファイルに一致する出力パス選択を行う。
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ルーティングモデルは、プロバイダーの階層を想定していました。階層の各レベルで、階層の下位レベルでのネットワークのルーティングポリシーと対処スペースは、次のレベルアップ（または「アップストリーム」）プロバイダーによって包含されました。このモデルで想定される接続ポリシーは、階層モデルでもあり、階層の単一レベル内の水平接続は、両当事者のネットワークを超えて見えません。
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.
ドメイン間スペース全体にわたるこのようなポリシーの拡散を制限する1つの方法は、このルートオブジェクトを他のルートオブジェクトと凝集させる可能性のあるリモートトランジットを指定する条件を指定するこのような広告に属性を関連付けることです。
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.
別のアプローチは、交換プロトコルのアプローチであり、そのようなアプローチは、リンク状態の動作の採用に基づいている可能性があります。ポリシーの不透明度とリンク状態のプロトコルの問題は上記で説明されています。このようなアプローチのもう1つの主要な問題は、リンク状態の洪水の範囲を制限する必要性です。ここでは、ドメイン間スペースがドメイン内領域と同様に、さらにレベルの課された構造を必要とします。このような構造は、相互輸送などの追加のオペレーターの相互関係セットの必要性を示唆する可能性があり、これは既存の慣行に適応するのが難しいことが証明される可能性があります。
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プロトコルを拡張または交換する以上のものが含まれます。3番目のアプローチは、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.
潜在的な短期的なプロトコルの改良の1つは、グループ化された一連の広告を単一のルート広告に集約できるようにすることです。この形式のプロキシ集約は、一致するルート属性を備えたビットごとのアラインドルーティングエントリのセットを取り、特定の適切に特定された状況下では、これらのルーティングエントリを単一の再承認された集計ルーティングエントリに集約します。この手法はルーティングシステムから情報を削除し、トラフィックの流れを実質的に変えないプロキシ集約条件のセット、またはルーティングポリシーを発表するASESの能力を定義するために、ある程度の注意を払う必要があります。
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に関連付けるアプローチを保持することができます。ポリシーの不透明度の概念は、そのようなアプローチでも保持され、それぞれが一連のルート広告を受け入れ、ローカルポリシーの制約を適用し、ローカルポリシーの制約によって許可されている広告を再承認することを意味します。特にルートの引き出しの処理中に中間状態に関連するため、距離ベクトルパス選択アルゴリズムの変更を検討することが可能です。また、複合ルート属性の使用を考慮して、ルートオブジェクトが集約ルートと集約ルートの多くの詳細を含めることを可能にし、集約または特定のアドレスプレフィックスに適用される属性を接続することもできます。このようなルート属性は、マルチホーミングおよびドメイン間の交通工学メカニズムをサポートするために使用できます。このアプローチの全体的な意図は、グローバルに伝播された特定のルートオブジェクトのセットを増やすことなく、ドメイン間ルーティングスペースの主要な要件に対処することです。
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.
潜在的な応用研究トピックは、ドメイン間接続管理の要件を、ポリシーの制約のアプリケーションと送信者および/または受信機が管理したトラフィックエンジニアリング要件の問題をカップする可能性を考慮することです。このようなアプローチでは、リンク状態のプロトコルを使用して、ドメイン間ネットワークのトポロジーの一貫したビューを維持し、何らかの形のオーバーレイプロトコルを使用して、それぞれのポリシー要件を交渉し、さらにオーバーレイを使用してサポートします。ドメイン間の交通工学要件。このようなアプローチの根本的な仮定は、ドメイン間ルーティングの機能的役割を異なるコンポーネントに分割することにより、各コンポーネントが優れたスケーリングと収束特性を持ち、ルーティングシステム全体に優れた特性をもたらすことです。明らかに、この仮定にはいくつかのテストが必要です。
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:
採用されたドメイン間ルーティングプロトコルは、混乱を防ぐ必要があります。混乱は2つの主要なソースから来ています：
- 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] Bradner、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] Clark、D.、Chapin、L.、Cerf、V.、Braden、R。、およびR. Hobby、「Towand the Future Internet Architecture」、RFC 1287、1991年12月。
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, December 1998.
[3] Deering、S。and 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] Fuller、V.、Li、T.、Yu、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] Huston、G。、「BGPルーティングテーブル」、The Internet Protocol Journal、Vol。4、No。1、2001年3月。
[7] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[7] Rekhter、Y。およびT. Li、「ボーダーゲートウェイプロトコル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. Chen、「ナンバースペースとしての4オクテットのBGPサポート」、進行中の作業。
[9] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[9] Hain、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.、Ahuja、A.、Bose、A。、およびJ. Jahanian、「遅延インターネットルーティングコンバージェンス」、Proceedings ACM Sigcomm 2000、2000年8月。
[11] Lothberg, P., personal communication, December 2000.
[11] Lothberg、P.、Personal Communication、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のメンバーの貢献を認めています。この文書のレビューにおけるジョン・レスリー、トーマス・ナルテン、アバ・アフジャの貢献も認められています。
Internet Architecture Board Email: iab@ietf.org
インターネットアーキテクチャボードメール：iab@ietf.org
Geoff Huston Telstra 5/490 Northbourne Ave Dickson ACT 2602 Australia
Geoff Huston Telstra 5/490 Northbourne Ave Dickson Act 2602 Australia
EMail: gih@telstra.net
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。