RFC3221 日本語訳
3221 Commentary on Inter-Domain Routing in the Internet. G. Huston. December 2001. (Format: TXT=66580 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Huston Request for Comments: 3221 Internet Architecture Board Category: Informational December 2001
コメントを求めるワーキンググループG.ヒューストン要求をネットワークでつないでください: 3221年のインターネット・アーキテクチャ委員会カテゴリ: 情報の2001年12月
Commentary on
Inter-Domain Routing in the Internet
インターネットの相互ドメインルート設定の論評
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
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
1. 序論… 2 2. スケーリングと相互ドメインルート設定をネットワークでつないでください… 2 3. BGP Tableの総サイズの測定値… 4 4. BGP Tableから得られたMeasurementsは関係づけました… 7 5. インターネットでの相互ASルーティングの現在の州… 11 6. 外のルート設定システムのための将来の要件… 14 7. スケーラブルなExteriorルート設定プロトコルへの建築Approaches… 15 8. さらなる活動のための指示… 21 9. セキュリティ問題… 22 10. 参照… 23 11. 承認… 24 12. 作者のアドレス… 24 13. 完全な著作権宣言文… 25
Huston Informational [Page 1] RFC 3221 Commentary on Inter-Domain Routing December 2001
相互ドメインルート設定2001年12月のヒューストン情報[1ページ]のRFC3221Commentary
1. Introduction
1. 序論
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.
これらの衝撃は既存のAutonomous System数のスペースの疲労困憊の可能性を含んで、安定した代替パスの品揃えのために集合時間を増加させて、ルート発表の次の取り消し、テーブル項目の安定性、および平均はBGPテーブルにエントリーの長さを前に置きます。 より大きい長期問題はASesの間のますますより濃い相互接続性メッシュのものです、よりすばらしい度の相互ドメイン方針の粒状と、よりすばらしいレベルのコントロールが相互ドメイン交通工学を引き受けることを引き起こして。
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.
このドキュメントはインターネット・アーキテクチャ委員会側の協力的な運動の結果です。
2. Network Scaling and Inter-Domain Routing
2. ネットワークスケーリングと相互ドメインルート設定
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.
インターネットの基本構造は接続ドメインを形成するためにインタコネクトされるネットワーク、またはAutonomous Systems(ASes)の収集です。 各ASは、ASの中でトポロジーの論理的な視点を維持するのに内部のルーティングシステムを使用して、全体のシステムの接続性の視点を作成するために隣接しているASesがある隣接番組情報を保守するのに外のルーティングシステムを使用します。
Huston Informational [Page 2] RFC 3221 Commentary on Inter-Domain Routing December 2001
相互ドメインルート設定2001年12月のヒューストン情報[2ページ]のRFC3221Commentary
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プロトコル(経路情報基地、またはRIBと呼ばれる)によって使用される経路指定テーブルで説明されます。 テーブルの各エントリーは異なったルートを示します。 ルートの属性は、地方のASからルートを溯源しているASまで最も良い経路を決定するのに地方の方針規制と共に使用されます。 この場合'最も良い経路'を決定するのは、ルーティング広告と次の関連ホップアドレスがどれであるかを大部分が地方のASで好んだ決定することです。 そして、それぞれの地方のBGP-話しルータの中では、この都合のよいルートは地方のRIB(Loc-RIB)にロードされます。 この情報はForwarding Information基地(または、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を相互AS接続性維持プロトコルと考えることができます、リンク・レベルトポロジー管理プロトコルと異なって、インターネットの現在の接続性の記述として接続性計算の基本要素としてASを使用することでBGP経路指定テーブルは見なすことができます。
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がルートでかかられたアドレスに達するのにローカルのルート選択パラメタで決定するように隣接しているASを使用するのを含意します。 BGP経路ドメインが'最短パス'が各ASによって言い表された接続性方針で調節されるようにどんな送付先アドレスにも達するように接続性が優先として言い表される相互ASドメインの接続性の論理的な視点を維持することを意図して、一貫性は経路のいずれも輪か行き止まりを含んでいないというグローバルな規制として言い表されます。 BGP経路ドメインの要素はアドレスの長さとして言い表されたルーティングエントリーです。 それぞれのルーティングエントリーの中に広告に掲載されたすべてのアドレスが一般的な起源ASと一般的な接続性方針を共有します。 したがって、BGPテーブルの総サイズは異なったルートの数におけるインターネットの中各ルートがa一般的な起源ASと一般的な可到達性方針を共有する隣接のアドレスについて説明するメートル法のaです。
Huston Informational [Page 3] RFC 3221 Commentary on Inter-Domain Routing December 2001
相互ドメインルート設定2001年12月のヒューストン情報[3ページ]のRFC3221Commentary
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つのネットワークの間の透明な相互作用をいくらかの許容することを意図するネットワーク・アドレス翻訳4のテクニックの気品と同様に; ルーティングシステムにおける成長はこれらのアプローチで直接記述されません、ルーティングスペースが異なったアドレス空間の断片化の度合いが掛けられた接続性方針の数が掛けられたネットワークの相互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が外のルーティングスペースに1ブロックのアドレスの広告を出すとき、一般に、このエントリーはインターネットの全体の外の経路ドメインの向こう側に運ばれます。 グローバルな経路指定テーブルの共通する特徴を測定するために、外の経路ドメインの無デフォルトの地域のポイントを確立して、その時目に見えるBGP経路指定テーブルを調べるのが必要です。
3. Measurements of the total size of the BGP Table
3. BGP Tableの総サイズの測定値
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.
経路指定テーブルのサイズの測定値は始めるためにいくらか過疎でした、そして、多くの測定値がMerit[5]によって1988年から1992年まで大体の毎月の間隔で、取られました。 この努力は1994年にオランダのSurfnetでエリック-ジャン・ボスによって再開されました。(オランダは、1時間おきに1994年のBGPテーブルのサイズを測定し始めました)。 この測定技術は1997年に作者によって採用されました、オーストラリアにテルストラにAS1221の縁に位置する測定ポイントを使用して、測定のために再び1時間ごとの間隔を費やして。 当初測定は選択された最も良い経路のセットの中に含まれたルーティングエントリーの数のものでした。 これらの測定値が含むように広げられた、ルーティングの接頭語サイズに関連するAS番号の数、AS経路の数、および1セットの測定値がエントリーをテーブルの上に置きます。
Huston Informational [Page 4] RFC 3221 Commentary on Inter-Domain Routing December 2001
相互ドメインルート設定2001年12月のヒューストン情報[4ページ]のRFC3221Commentary
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つの異なったフェーズを特定するのは可能です。
3.1 Pre-CIDR Growth
3.1 プレCIDRの成長
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テーブル・サイズが肝心になっただろうということでした。
3.2 CIDR Deployment
3.2 CIDR展開
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].
工学共同体からの応答は相互ドメインルーティングシステムへの階層構造の導入でした。 階層型ルーティング構造の意図はプロバイダーが全体の顧客ベースにかかった単一のルーティングエントリーに顧客のためのルーティングエントリーを合併するのを許容することでした。 この変化の実用的な局面はClass A、B、およびCアドレス輪郭描写のための要件を省いたルーティング・プロトコルの導入でした、この計画をアドレス接頭語と関連接頭語の長さを運んだルーティングシステムに取り替えて。 アプローチされたこれはClassless Inter-ドメインルート設定(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年にインターネットでCIDRルーティングを配備するために引き受けられました、BGPプロトコルのCIDRできるバージョンの展開を奨励することに基づいて、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
CIDRの意志は階層的なプロバイダーアドレス集合、どこにあて先ブロックをアドレス登録からネットワーク内の提供者に割り当てたか、そして、およびプロバイダーのひとりが単一のエントリーとしてただ一つのルーティング方針でこの全体のブロックを外の経路ドメインに発表したということでした。 プロバイダーの顧客がプロバイダーのあて先ブロックからサブ配分を使用するよう奨励されて、これらのよりわずかなルーティング要素は、プロバイダーによって集められて、直接外の経路ドメインに入りませんでした。 1994
Huston Informational [Page 5] RFC 3221 Commentary on Inter-Domain Routing December 2001
相互ドメインルート設定2001年12月のヒューストン情報[5ページ]のRFC3221Commentary
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集合の結果、合われていたとき、経路指定テーブルのサイズはおよそ2万のエントリーに比較的一定数にとどまりました。
3.3 CIDR Growth
3.3 CIDRの成長
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経路指定テーブルでの湿気の自由な成長で実効を現しました。 この期間、1年あたりおよそ1万のエントリーを加えて、BGPテーブルは大体の直線的な速度で成長しました。
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時間ごと)の変化は発表されたルートの数の割合、および絶対項でも減少しました。大きい集合あて先ブロックを使用する諸手当の1つはネットワークの縁の不安定性がすぐにルーティングコアに伝播されないということです。 集合ルートが、より特定のルートの収集に代わって使用されるポイントで最後のホップにおける不安定性を没頭させます。 BGPルートフラップ湿気の広範囲の採用に結びつけられたこれはこの期間、ルーティングスペースにおける短期間の不安定性を減少させるのにおいて非常に効果的でした。
3.4 Current Growth
3.4 現在の成長
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.
BGPテーブル・サイズにおける趨勢成長率は1998年後半に根本的に変化しました、そして、2000年の1998--期間の成長は再び、強い相関関係で成長傾向の再建のすべての兆候を急激な増加モデルに示していることです。 成長傾向におけるこの変化は階層的なアドレスの配分とCIDRを使用する圧力がインターネットの成長のレベルと足並をそろえることができないで、BGPテーブル・サイズにおける成長に影響を与えるいくつかの追加要素がインターネットで、より際立つようになったのを示すように見えます。 これはそれが複合成長モデルと共用して線形モデルより持っているBGPテーブルの総サイズにおける成長パターンにリードを持っています。 1999年1月から2000年12月までの期間のためのデータの良いフィットは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.
初期の観測はこの成長パターンがインターネットの中に接続性とルーティングの階層的なモデルのいくつかの弱化を示すということです。 この最近の傾向の特性を特定するために、経路指定テーブルの多くの関連する特性を見るのが必要です。
Huston Informational [Page 6] RFC 3221 Commentary on Inter-Domain Routing December 2001
相互ドメインルート設定2001年12月のヒューストン情報[6ページ]のRFC3221Commentary
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年の前半の定常状態を示しています、地方のASが初めは下側の数の、より特定のルートを持っていた他の測定ポイントはテーブル・サイズの成長の継続を示していますが。 出来事に対応している、2001年のデータには多くの一般的に観測された不連続が多くの、より特定のエントリーが取り囲むことの集合接頭語に取り替えられたところにあります。
4. Related Measurements derived from BGP Table
4. BGP Tableから得られた関連Measurements
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経路指定テーブルの分析のレベルを広げてあります。 分析は、ルーティングシステムのASesの数、および異なったAS経路(それぞれのルーティングエントリーのテーブルと平均した長さによってかかられたアドレスの範囲)の数を測定するのを含んでいます。
4.1 AS Number Consumption
4.1 数の消費として
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に関連しています、そして、無デフォルトの経路指定テーブルのASesの数はユニークなルーティング方針を持っている実体の数を追跡します。 これへのいくつかの例外があります、複数のASesがただ一つのネットワークに関連していますが、そのような例外が比較的珍しい異なった地域政策での大きいグローバルなトランジットプロバイダーを含んでいて。
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.
1996年後半以来BGPテーブルの現在のユニークなASesの数は追跡されています、そして、また、過去4年間のAS数の展開の傾向は1年あたり51%の成長率に複合成長モデルを合わせるものです。 2001年5月の始まりの時点で、BGPテーブルで目に見えるおよそ1万700ASesがありました。 継続的な成長率の51%p.a.では、16ビットのAS数のスペースは2005年8月までに完全に配備されるでしょう。 仕事は32ビットの分野でAS番号を運ぶようにBGPプロトコルを変更するIETFの中で進行中です。 [8] プロトコル変更は比較的簡単ですが、主な職務は、このより大きいAS数のスペースにゆるやかな変遷を許容する変遷プランについて工夫するために操作共同体と共に休息しています。
Huston Informational [Page 7] RFC 3221 Commentary on Inter-Domain Routing December 2001
相互ドメインルート設定2001年12月のヒューストン情報[7ページ]のRFC3221Commentary
4.2 Address Consumption
4.2 アドレス消費
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年の始めが、経路指定テーブルが10億8113万1733のアドレス、または総IPv4アドレス空間のおよそ25.17%を包含したか、または使用可能なユニキャスト公衆の25.4%はスペースを記述します。 2001年9月までには、これには、11億2312万4472のアドレスへの成長、またはIPv4アドレス空間のおよそ26%があります。 これは1999年11月に10億1948万4655のアドレスから成長しました。 しかしながら、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年未満前に特定されたアドレス空間の知覚された有限本質を解決することに関して、この説明は、インターネットが今までのところNATsを使用するアプローチを迎え入れたように見えるのを示す傾向があるでしょう、彼らの様々な知覚された機能的な短所の如何にかかわらず。 [9] また、この説明はBGPテーブルの異なった方針を支持するより小さいアドレス断片の観測を支持します、そのようなわずかなあて先ブロックが1NAT門以上の後ろに位置する任意に大きいネットワークを包含するとき。 テーブルの成長とアドレス空間の成長の間には、この違いの代替の説明があります、より詳しいあて先ブロックに適用される離散的な外のルーティング方針に向かって傾向を含めて。
4.3 Granularity of Table Entries
4.3 テーブル項目の粒状
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
CIDR集合の意図はBGP経路指定テーブルにおける大きい集合アドレス発表の使用を支持することでした。 それでも、これがそれぞれのBGP発表の平均した長さのそうであるかどうか確認するのが過去12カ月追跡されています。 データは2000年12月に11月の1万6000の個々のアドレスからBGP広告の平均した長さの衰退を1999〜1万2100に示します。 2001年9月付けで、この長さはさらにルーティングエントリーあたり1万700の平均した個々のアドレスまで減少しました。 これは2001年9月までに2000年12月までに/18.03から/18.44までの平均した接頭語の長さと/18.6で増加に対応しています。 2000年後半に操作ネットワークの交通を発送するのに使用される平均した接頭語の長さの別々の観測は平均した長さの18.1[11]を示します。 増加が広まったのを含意するとき、経路指定テーブルの、よりきめ細かに粒状のエントリーに向かったこの傾向は潜在的に心配の種です。
Huston Informational [Page 8] RFC 3221 Commentary on Inter-Domain Routing December 2001
相互ドメインルート設定2001年12月のヒューストン情報[8ページ]のRFC3221Commentary
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.
より大きい数のますますより小さい推進の上の交通では、エントリーをテーブルの上に置いてください。 これには、高速コアルータのデザインのための意味が順番にあります、特にルータのデザインの切り換えサブシステムの中でエントリーを進めるキャッシュされた非常に高い速度の少ない数で大規模な使用をするとき。
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は平均16万1900のアドレスの広告を出しました。(接頭語長さ/14.69、およびこの平均が11万5800のアドレスに堕落するようにする2001年1月、/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テーブルでグローバルに発表されています。 よりすばらしいレベルのルーティング粒状のこの傾向の最もありそうな原因が、より多くのネットワークが動いているますます濃いインタコネクトメッシュである、aがシングル家へ帰った、接続、階層的なアドレシングとルーティング、マルチ、家へ帰り、少しも階層構造のない接続。 インターネットのメッシュが一般的な知覚がそんなにより豊かな状態でコミュニケーション運搬人サービスのコストが結合した減退しているユニットが隣接番組のセットであったならたぶんそうするだろうこのますます濃い接続性のための拍車は、より大きいレベルのサービス弾力をもたらします。
4.4 Prefix Length Distribution
4.4 接頭語長さの分配
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.
大規模なプログラムは、Class Cスペースの激しい使用から遠くに動いて、プロバイダーを奨励する90年代の半ばで、より大きいあて先ブロックの広告を出し始めました、CIDRの努力の一部として。 これは/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
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
Huston Informational [Page 9] RFC 3221 Commentary on Inter-Domain Routing December 2001
Huston Informational [Page 9] RFC 3221 Commentary on Inter-Domain Routing December 2001
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]
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]
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.
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.
Huston Informational [Page 10] RFC 3221 Commentary on Inter-Domain Routing December 2001
Huston Informational [Page 10] RFC 3221 Commentary on Inter-Domain Routing December 2001
4.5 Aggregation and Holes
4.5 Aggregation and Holes
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.
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.
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.
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.
5. Current State of inter-AS routing in the Internet
5. Current State of inter-AS routing in the Internet
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.
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.
Huston Informational [Page 11] RFC 3221 Commentary on Inter-Domain Routing December 2001
Huston Informational [Page 11] RFC 3221 Commentary on Inter-Domain Routing December 2001
5.1 A denser interconnectivity mesh
5.1 A denser interconnectivity mesh
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.
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.
5.2 Multi-Homed small networks and service resiliency
5.2 Multi-Homed small networks and service resiliency
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.
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.
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.
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.
Huston Informational [Page 12] RFC 3221 Commentary on Inter-Domain Routing December 2001
Huston Informational [Page 12] RFC 3221 Commentary on Inter-Domain Routing December 2001
5.3 Traffic Engineering via Routing
5.3 Traffic Engineering via Routing
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.
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.
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.
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.
5.4 Lack of Common Operational Practices
5.4 Lack of Common Operational Practices
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.
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.
5.5 CIDR and Hierarchical Routing
5.5 CIDR and Hierarchical Routing
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.
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.
Huston Informational [Page 13] RFC 3221 Commentary on Inter-Domain Routing December 2001
Huston Informational [Page 13] RFC 3221 Commentary on Inter-Domain Routing December 2001
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.
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.
6. Future Requirements for the Exterior Routing System
6. Future Requirements for the Exterior Routing System
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.
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.
6.1 Scalability
6.1 Scalability
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 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.
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.
6.2 Stability and Predictability
6.2 Stability and Predictability
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 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.
Huston Informational [Page 14] RFC 3221 Commentary on Inter-Domain Routing December 2001
Huston Informational [Page 14] RFC 3221 Commentary on Inter-Domain Routing December 2001
6.3 Convergence
6.3 Convergence
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.
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.
It is not a requirement to be able to undertake full convergence of the inter-domain routing system in the sub-second timescale.
6.4 Routing Overhead
6.4 Routing Overhead
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.
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.
7. Architectural approaches to a scalable Exterior Routing Protocol
7. Architectural approaches to a scalable Exterior Routing Protocol
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.
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.
7.1 Policy opaqueness vs. policy transparency
7.1 Policy opaqueness vs. policy transparency
The two major approaches to routing protocols are distance vector and link state.
The two major approaches to routing protocols are distance vector and link state.
Huston Informational [Page 15] RFC 3221 Commentary on Inter-Domain Routing December 2001
Huston Informational [Page 15] RFC 3221 Commentary on Inter-Domain Routing December 2001
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 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 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.
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.
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.
Huston Informational [Page 16] RFC 3221 Commentary on Inter-Domain Routing December 2001
Huston Informational [Page 16] RFC 3221 Commentary on Inter-Domain Routing December 2001
7.2 The number of routing objects
7.2 The number of routing objects
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).
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).
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.
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.
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.
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
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
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.
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.
Huston Informational [Page 17] RFC 3221 Commentary on Inter-Domain Routing December 2001
Huston Informational [Page 17] RFC 3221 Commentary on Inter-Domain Routing December 2001
7.3 Inter-domain Traffic Engineering
7.3 Inter-domain Traffic Engineering
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.
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.
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.
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.
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.
代替的アプローチは集合ルート物に付けられている交通工学属性のクラスの使用です。 そのような属性の意図が、より特定の広告への現在の応答に一致している方法でルート物に応じるようそれぞれのリモートASに指示することですが、特定の接頭語の広告を出す必要性がなければ、物を発送してください。 しかしながら、このアプローチさえ交通工学方針を伝えるのにルート物を使用します、そして、ルートテーブルがきめ細かに詳細な交通経路方針を運ぶのに使用されるという同じ危険は残っています。
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から目的地ASまで多くの実行可能な経路を特定して、交通を許容する交通エンジニアリングツールの異なった収集を使用するために、出口経路選択をそれにするソース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
交通工学的方法の間には、1つのきわどい違いがイントラドメイン環境と現在の相互ドメイン操作習慣に使用されるようにあります。 イントラドメイン環境は適切な経路選択を出口ポイントにするのにイングレスネットワーク要素を使用しますが、間のドメイン交通工学には、反対の意図があります、川下のAS(または、出口ポイント)が、上流のASの経路選択に影響を及ぼすのを試みているところで(イングレス
Huston Informational [Page 18] RFC 3221 Commentary on Inter-Domain Routing December 2001
相互ドメインルート設定2001年12月のヒューストン情報[18ページ]のRFC3221Commentary
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.
ポイント) 明白な交通工学が相互ドメインスペースの中で引き受けられるなら、現在の構造は非常に変更されそうでしょうに。 上流の要素の経路選択を抑制するのを試みる下流要素の代わりに、ありえそうなアプローチは上流の要素、およびこれらの顧問規制(出口選択をするように経路サービスの特性とローカルの方針に関連する動的情報)の組み合わせを使用する上流の要素における多くの顧問規制を置く下流要素です。
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.
相互ドメインルーティング環境の見解から、そのような測定は交通工学目的のために特定のルートの広告を取り除く可能性を提供します。 しかしながら、広告を出しているルートブロックに交通工学情報を追加することへの必要があります、物を発送するために付けることができる構文の定義と交通工学属性の意味論を必要として。
7.4 Hierarchical Routing Models
7.4 階層型ルーティングモデル
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.
1つの方法で、スペースが関連づけることになっている全体の相互ドメイン属性の向こう側にそのような方針の増殖をリモートトランジットASがそうするかもしれない状態を指定するそのような広告に制限するために、プロキシは他のルート物でこのルート物に集めます。
Huston Informational [Page 19] RFC 3221 Commentary on Inter-Domain Routing December 2001
相互ドメインルート設定2001年12月のヒューストン情報[19ページ]のRFC3221Commentary
7.5 Extend or Replace BGP
7.5は、BGPを広げているか、または取り替えます。
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.
最終的な考慮は1セットの上向きコンパチブル拡大の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プロトコルを置き換えるより以上を含んでいます。 3番目のアプローチは伝播する基本的な手段がそれらの物、関連AS経路、および他の属性を発送するときBGPを使用して、相互ドメイン交通工学と他の形式の相互ドメイン方針交渉を支持するのに1つ以上のオーバレイプロトコルを使用し続けることです。 それらの相互ドメインルーティング・プロトコルとしてBGP4を使用することでこのアプローチは現在大きいインストールされたベースのために変遷の手段を提供するように見えるでしょう、BGP4に関する基本機能を完全なままにする間、オーバレイプロトコルに追加機能性を置いて。 BGPとオーバレイプロトコルの間の結果の相互依存性は非常に慎重な注意を必要とするでしょう、これがそのようなアプローチの最も重大な局面であるので。
Huston Informational [Page 20] RFC 3221 Commentary on Inter-Domain Routing December 2001
相互ドメインルート設定2001年12月のヒューストン情報[20ページ]のRFC3221Commentary
8. Directions for Further Activity
8. さらなる活動のための指示
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経路指定テーブルから余分であるか効率悪く分類されたエントリーを取り除く様々な誘因を提供することに基づいた短期間動作が存在しているかもしれない間、そのような動作は、短期間の緩和剤の測定であり、スケーラブルな相互ドメインルーティング・プロトコルに必要性の長期答えを提供しないでしょう。
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セットの分類された広告がただ一つのルート広告に集められるのを許容することです。 このフォームのプロキシ集合は1セットの合っているルート属性と、そして、あるよく特定された状況の下でのビット的な並べられたルーティングエントリーを取って、集合は単一の再広告を出している集合ルーティングエントリーへのこれらのルーティングエントリーです。 このテクニックはルーティングシステムから情報を取り除きます、そして、物質的に交通の流れ、またはルーティング方針を発表する由来しているASesの能力を変更しない1セットのプロキシ集合状態を定義するために何らかの注意を払わなければなりません。
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
そのような測定がBGP4のスケーリングと集合の特性へのかなりの、より長い用語変化をもたらすのは、不明瞭です。 要件セットがこのドキュメントのセクション6で列挙した取り、要件というより長い期間への1つのアプローチが現在のBGPプロトコルの多くの属性を保存することであるかもしれない、プロトコルの他の局面を洗練して、スケーリングと集合の特性を改良してください。 1人の極小集合の変更は、それぞれの接頭語広告を由来しているASに関連づけるアプローチを保有することと同様に情報総括の境界を考慮するためにAutonomous System概念を保有するかもしれません。 また、方針不透明の概念はそのようなアプローチで保有されるでしょう、各ASが1セットのルート広告を受け入れて、地方の方針規制を適用して、地方の方針規制で受入れられたそれらの広告の再広告を出すのを含意して。 距離ベクトル経路選択アルゴリズムと変更を考えるのは可能であるかもしれません、特にルート退出の処理の間中間的州に関連するとき。 また、ルート物を許容する合成ルート属性の使用が含んでいると考えるのにおいてそれも可能です。
Huston Informational [Page 21] RFC 3221 Commentary on Inter-Domain Routing December 2001
相互ドメインルート設定2001年12月のヒューストン情報[21ページ]のRFC3221Commentary
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.
ルート、および集合ルートの多くの詳細に集めてください、そして、集合接頭語か特定のアドレス接頭語に適用されるかもしれない属性を付けてください。 そのようなルート属性は、マルチホーミングと相互ドメイン交通工学メカニズムをサポートするのに使用されるかもしれません。このアプローチの総合的な意図は相互ドメインルーティングスペースに増加するセットのグローバルに伝播された特定のルート物を使用しないで主要な要件を記述することです。
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.
潜在的より長い用語アプリケーションがある研究話題は様々な方針と交通工学規制を満たすネットワークのアイデンティティと、他のネットワークに比例したネットワークの位置と、ソースと送信先ネットワークの間の実行可能経路の間で区別をつけるアプローチを含んでいます。 一方、そのようなアプローチの意図は現在の経路選択機能を多くの異なったスケーラブルなコンポーネントに分割するだろうことです。
9. Security Considerations
9. セキュリティ問題
Any adopted inter-domain routing protocol needs to be secure against disruption. Disruption comes from two primary sources:
どんな採用された相互ドメインルーティング・プロトコルも、分裂に対して安全である必要があります。 分裂は2人の一次資料から来ます:
- Accidental misconfiguration
- Malicious attacks
- 偶然のmisconfiguration--悪意ある攻撃
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.
また、世界的なインターネット相互ドメインルーティングシステムにかかわるすべてのルータのセキュリティを保証するのが妥当でないなら、悪意ある攻撃が同輩ルータから来るかもしれないと信じるあらゆる理由があります、外部電源から来ることに加えて。
Huston Informational [Page 22] RFC 3221 Commentary on Inter-Domain Routing December 2001
相互ドメインルート設定2001年12月のヒューストン情報[22ページ]のRFC3221Commentary
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.
ルーティングシステム自体は、そのような広告を作る権利を与えられなかったルートサーバでルート物の偶然の、または、悪意がある広告に対して弾力がある必要があります。 これはいくつかのことを含意します、発表の暗号の合法化、様々な批判的なルーティング・メッセージの暗号の保護、およびを通した認可をチェックできるルーティング課題の正確で信じられたデータベースの必要性を含んでいて。
10. References
10. 参照
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、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.趣味、「今後のインターネット建築」、RFC1287、1991年12月。
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification, RFC 2460, December 1998.
[3] デアリングとS.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様、RFC2460、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)」、RFC3022、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)階級のない相互ドメイン」 「アドレス課題と集合戦略」、RFC1519、9月1993日
[6] Huston, G., "The BGP Routing Table", The Internet Protocol
Journal, vol. 4, No. 1, March 2001.
[6] ヒューストン、G.、「BGP経路指定テーブル」、インターネットプロトコル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.と1995年のT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。
[8] Vohara, Q. and E. Chen, "BGP support for four-octet AS number
space", Work in Progress.
[8] ProgressのVoharaとQ.とE.チェン、「4八重奏のAS数のスペースのBGPサポート」、Work。
[9] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[9] ハイン、T.、「NATの建築含意」、RFC2993、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.とボーズとA.とJ.Jahanian、「遅れたインターネットルート設定集合」、議事ACM SIGCOMM2000、2000年8月。
Huston Informational [Page 23] RFC 3221 Commentary on Inter-Domain Routing December 2001
相互ドメインルート設定2001年12月のヒューストン情報[23ページ]のRFC3221Commentary
[11] Lothberg, P., personal communication, December 2000.
[11]Lothberg、P.、個人的なコミュニケーション、2000年12月。
11. Acknowledgements
11. 承認
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、およびアブハーAhujaの貢献は承諾されます。
12. Author
12. 作者
Internet Architecture Board Email: iab@ietf.org
インターネット・アーキテクチャ委員会メール: iab@ietf.org
Geoff Huston Telstra 5/490 Northbourne Ave Dickson ACT 2602 Australia
ジェフヒューストンテルストラ5/490のNorthbourne Aveディックソンは2602オーストラリアを活動させます。
EMail: gih@telstra.net
メール: gih@telstra.net
Huston Informational [Page 24] RFC 3221 Commentary on Inter-Domain Routing December 2001
相互ドメインルート設定2001年12月のヒューストン情報[24ページ]のRFC3221Commentary
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Huston Informational [Page 25]
ヒューストンInformationalです。[25ページ]
一覧
スポンサーリンク
