Network Working Group J. Yu
Request for Comments: 2791 CoSine Communications
Category: Informational July 2000
Scalable Routing Design Principles
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
Routing is essential to a network. Routing scalability is essential to a large network. When routing does not scale, there is a direct impact on the stability and performance of a network. Therefore, routing scalability is an important issue, especially for a large network. This document identifies major factors affecting routing scalability as well as basic principles of designing scalable routing for large networks.
ルーティングとは、ネットワークに不可欠です。スケーラビリティをルーティングは、大規模なネットワークに不可欠です。スケールしないルーティングするとき、ネットワークの安定性と性能に直接影響があります。そのため、ルーティングのスケーラビリティは、特に大規模なネットワークのために、重要な問題です。この文書では、ルーティング拡張性に影響を与える主な要因だけでなく、大規模なネットワークのためのスケーラブルなルーティングを設計の基本原則を識別します。
Table of Contents
目次
1 Introduction .................................. 2
2 Common Routing Design Goals ................... 3
3 Characteristics of Today's Large Networks ..... 3
4 Routing Scaling Issues .......................... 3
4.1 Router Resource Consumption ..................... 4
4.2 Routing Complexity .............................. 5
5 Routing Protocol Scalability ..................... 6
5.1 IS-IS and OSPF .................................. 6
5.2 BGP ............................................. 8
6 Scalable Routing Design Principles .............. 9
6.1 Building Hierarchy .............................. 10
6.2 Compartmentalization ............................ 13
6.3 Making Proper Trade-offs ........................ 13
6.4 Reduce Burdens of Routing Information Process ... 14
6.4.1 Routing Intelligence Placement .................. 14
6.4.2 Reduce Routes and Routing Information ........... 15
6.4.2.1 CIDR and Route Aggregation ...................... 15
6.4.2.2 Utilize Default Routing where it's Possible ..... 15
6.4.2.3 Reduce Alternative Paths ........................ 16
6.4.3 Use Static Route at Edge ......................... 16
6.4.4 Minimize the Impact of Route Flapping ............ 16
6.5 Scalable Routing Policy and Scalable Implementation 17
6.6 Out-of-band Process .............................. 19
7 Conclusion and Discussion ........................ 19
8 Security Considerations .......................... 20
9 Acknowledgement .................................. 21
10 References ....................................... 21
Author's Address .............................................. 22
Appendix A Out-of-Band Routing Processes .................... 23
Full Copyright Statement ..................................... 26
Routing is essential to a network. Without routing, packets cannot be delivered to desired destinations and the network would be non-functional. The challenge of designing the routing for a large network, such as a large ISP backbone network, is not only to make it work, but also to make it scale. Without a scalable routing system, a network may suffer from severe performance penalties, as unfortunately proven by disastrous events in large networks. This document attempts to analyze routing scalability issues and define a set of principles for designing scalable routing system for large networks.
ルーティングとは、ネットワークに不可欠です。ルーティングせずに、パケットが所望の宛先に配信することができず、ネットワークが非機能的であろう。このような大規模なISPのバックボーンネットワークとして、大規模なネットワークのルーティングを設計する課題は、それを動作させるために、だけでなく、それはスケールにするだけではありません。残念ながら、大規模なネットワークでの悲惨な出来事によって証明されたとして、スケーラブルなルーティングシステムがなければ、ネットワークは、深刻なパフォーマンスの低下に苦しむことがあります。この文書は、ルーティングのスケーラビリティの問題を分析し、大規模ネットワークのためのスケーラブルなルーティングシステムを設計するための原則のセットを定義することを試みます。
The organization of this document is as follows: Section 2 describes routing functions and design goals. Sections 3 and 4 discuss the
次のように本書の構成は次のとおりです。第2節では、ルーティング機能と設計目標について説明します。セクション3と4話し合います
characteristics of today's large networks and the associated routing scaling issues. Section 5 explores routing protocol scalability, and Section 6 presents scalable routing design principles. Section 7 provides a conclusion to the document.
今日の大規模ネットワークの特性と関連するルーティングのスケーリングの問題。第5節では、ルーティングプロトコルの拡張性を探り、そして第6節は、スケーラブルなルーティング設計の原則を提示します。第7節は、文書に結論を提供します。
The basic goals a routing system should achieve are as follows:
次のようにルーティングシステムが達成すべき基本的な目的は次のとおりです。
o Stability o Redundancy and robustness o Reasonable convergency time o Routing information integrity o Sensible and manageable routing policy
賢明かつ管理可能ルーティングポリシーOルーティング情報の完全性の合理的な収束時間の冗長性と堅牢性のO安定性
The challenge of designing routing in a large network is not only to achieve these basic goals but also to make the routing system scale.
大規模なネットワークでのルーティング設計の課題は、これらの基本的な目標を達成するためだけでなく、ルーティングシステムのスケールを作ることだけではありません。
Today's large networks typically possess the following features:
今日の大規模なネットワークでは、一般的に以下のような特徴を持っています：
o They are composed of a large number of nodes (routers and/or switches), typically in the hundreds. Some provider networks include customer CPE routers within their administrative domain, which increases the number of nodes to thousands.
Oそれらは典型的には数百に、ノード（ルータ及び/又はスイッチ）の多数で構成されています。いくつかのプロバイダのネットワークは、数千個のノードの数が増加し、その管理ドメイン内の顧客CPEルータが含まれます。
o They have rich connectivity to meet redundancy and robustness requirements, and they consequently have complex topologies.
O彼らは、冗長性と堅牢性の要件を満たすために豊富な接続性を持っている、と彼らは結果的に複雑なトポロジーを有します。
o They are default-free; that is, they carry all the routes known to the entire Internet. Currently, the total number is approximately 70,000.
O彼らは、デフォルトフリーです。つまり、彼らはインターネット全体に知られているすべてのルートを運びます。現在、総数は約7万です。
o The customer aggregation routers inside the large networks connect sometimes hundreds of customer routers.
O大規模ネットワーク内の顧客集約ルータは時々、顧客のルータの数百を接続します。
These characteristics impose a direct challenge to the routing scalability of the network.
これらの特性は、ネットワークのルーティングのスケーラビリティへの直接の挑戦を課しています。
Today, the main issues surrounding routing scaling are: i) excessive router resource consumption, which can potentially increase routing convergency difficulties thus destabilize a network; and ii) routing complexity, resulting in poor management of network, producing low service quality.
今日では、ルーティングのスケーリングを取り巻く主な課題は以下のとおりです。潜在的に収束の難しさは、このようにネットワークを不安定にルーティング増やすことができますI）過度のルータの資源消費、;及びii）ルーティングの複雑さ、低いサービス品質を製造する、ネットワークの貧弱な管理をもたらします。
The routing process puts bursty loads on routers, especially under unstable network conditions. In the extreme case, the routing process takes all available resources from the routers, which results in slow routing convergence or no convergence. A network is paralyzed when it cannot converge internal routing information.
ルーティングプロセスは、特に不安定なネットワーク条件下では、ルータ上のバースト性負荷を置きます。極端な場合には、ルーティング処理が遅いルーティング収束又は全く収束をもたらすルータからのすべての利用可能なリソースを要します。それは内部ルーティング情報を収束できない場合、ネットワークが麻痺しています。
It's worthy noting that routers with internal architectures that tightly couple forwarding and routing processes tend to handle the excessive routing load poorly. The emerging new generation of routers with the architecture of separating resource used for forwarding and routing could provide better routing scalability.
それはしっかりと夫婦転送およびルーティングプロセスが不十分過大なルーティング負荷を処理する傾向がある内部アーキテクチャとルーターことは注目に値するのです。リソースを分離するアーキテクチャを持つルータの新興新しい世代は、より良いルーティングスケーラビリティを提供することができ、転送およびルーティングに使用しました。
Today, a large network typically employs IS-IS [1,2] or OSPF [3] as an Interior Routing Protocol(IGP) and BGP [4] as an Exterior Routing Protocol(EGP), respectively. The IGP calculates paths across the interior of the network. BGP facilitates routing exchange between routing domains, or Autonomous Systems (AS). BGP also processes and propagates external routing information within the network. The presence of a large number of routers and adjacencies in a network, coupled with frequent topology changes due to link instability, will contribute to excessive resource consumption by the interior routing. In the case of exterior routing, a large quantity of routers in a BGP system plus frequent routing updates (route flapping) would put a heavy burden on the routers. Section 5 describes scaling issues with IS-IS, OSPF and BGP in detail.
今日、一般的には採用する大規模なネットワークは、IS-IS [1,2]またはOSPF [3]のような内部ルーティングプロトコル（IGP）とBGP [4]のような外部ルーティングプロトコル（EGP）、それぞれ。 IGPは、ネットワークの内部を横切って経路を計算します。 BGPは、ルーティングドメイン、または自律システム（AS）間のルーティング交換を容易にします。 BGPはまた、処理して、ネットワーク内の外部ルーティング情報を伝搬します。不安定をリンクによる頻繁なトポロジの変化と相まって、ネットワーク内のルータと隣接関係の多数の存在は、内部ルーティングにより過度のリソース消費に寄与することになります。外部ルーティングの場合、BGPシステムにおけるルータの大量プラス頻繁なルーティングアップデート（ルートフラッピング）がルータに重い負担をかけることになります。第5節は、詳細にIS-IS、OSPFやBGPとスケーリングの問題について説明します。
In addition, having many destinations in a routing system, combined with multiple paths associated with these routes, impose the following scaling issues on BGP:
加えて、BGPに以下のスケーリング問題を課し、これらの経路に関連する複数のパスと組み合わせ、ルーティングシステムに多くの目的地を有します。
o A large number of routes combined with multiple paths for each increases the cost of routing processing for route selection, routing policy application and filtering.
Oそれぞれに対する複数のパスと組み合わさ経路多数の、経路選択処理をルーティングポリシーの適用とフィルタリングルーティングのコストを増加させます。
o Too many routes combined with multiple paths requires large amounts of memory on routers for storage. The demand is even higher at InterExchange Points such as NAPs.
複数のパスと組み合わさO多くのルートは、ストレージのためのルータに大量のメモリを必要とします。需要は、NAPのようエクスチェンジポイントにおいても高いです。
o The larger the number of routes, the greater the chance route flapping will occur and the more BGP routing updates will happen as a result. Based on statistics collected by [5], thousands of BGP updates in a measured 15 minute interval can occur on a typical default-free router at a NAP.
経路の数より大きなO、大きなチャンスルートフラッピングが発生し、より多くのBGPルーティングアップデートは結果として起こります。 [5]、実測15分間隔でのBGPアップデートの数千人がNAPで、一般的なデフォルトのないルータ上で発生する可能性がありますによって収集された統計に基づいています。
Route flapping refers to frequent routing updates occurring due to network instability, for example, when the state of a physical link in the network is fluctuating, or when a BGP session is torn down and re-established numerous time within a short period of time.
ルートフラッピングは、ネットワーク内の物理リンクの状態が変動している場合、例えば、不安定ネットワークによって生じる頻繁なルーティングアップデートを指す、またはBGPセッションが切断及び短時間で多数の時間を再確立したとき。
To facilitate fast convergence, topology change information must be propagated in a timely fashion. When a route becomes unavailable and is withdrawn, the information is typically sent immediately. If the affected routes have been announced to the global Internet, the update information is likely to be propagated to the entire Internet.
高速コンバージェンスを容易にするために、トポロジ変更情報をタイムリーに伝播しなければなりません。経路が利用できなくなったと引き抜かれる場合、情報は、典型的には、すぐに送信されます。影響を受けるルートは、グローバルなインターネットに発表されている場合は、更新情報がインターネット全体に伝播する可能性があります。
Route flapping has a profound impact on routers running BGP. The routers have to process routing information frequently and this consumes a tremendous amounts of the available resources. When a local route or link is oscillating, interior routing is affected as well by excessive topology information flooding and subsequent shortest path calculations. However, OSPF (or IS-IS) imposes rate limits on such activity to reduce the burden on the routers. For example, OSPF specifies that an individual SLA can be updated at most once every 5 seconds. This essentially dampens the flapping.
ルートフラッピングは、BGPを実行しているルータに深刻な影響を与えています。ルータは頻繁にルーティング情報を処理する必要があり、これは、利用可能なリソースの膨大な量を消費します。局所経路またはリンクが発振している場合、内部ルーティングは、過度のトポロジ情報フラッディングおよびその後の最短経路計算によっても影響されます。しかし、OSPF（またはIS-IS）は、ルータの負担を軽減するためにそのような活性にレート制限を課します。例えば、OSPFは、個々のSLAは、最高1回5秒ごとに更新できるように指定します。これは本質的にフラッピングを減衰させます。
Moreover, large numbers of E-BGP sessions processed by a single router create another potential scaling issue. Large networks usually have huge customer subscriptions and connections. To scale the hardware and the number of nodes in the network, providers tend to dedicate a group of customer aggregation routers, each connecting as many customer CPE routers as possible. As a result, it's not uncommon for a customer aggregation router to handle hundreds of E-BGP sessions, which imposes potential problems, such as BGP session processing and maintenance, route processing, filtering and route storage.
また、単一のルータによって処理されたE-BGPセッションの多くは、他の潜在的なスケーリングの問題を作成します。大規模なネットワークは、通常、巨大な顧客のサブスクリプションとの接続を持っています。ハードウェアとネットワーク内のノードの数を拡張するために、プロバイダは、顧客集約ルータのグループを専用にする傾向があり、それぞれは、できるだけ多くの顧客のCPEルータを接続します。その結果、このようなBGPセッション処理やメンテナンス、ルート処理、フィルタリングやルートストレージなどの潜在的な問題を課しており、E-BGPセッションの数百を処理するために、顧客の集約ルータのために珍しくありません。
Routing complexity can lead to network management difficulties, which will have an impact on trouble shooting and quick problem resolution. It can result in a less than desirable service quality across the network. Complicated routing policies and special cases or exceptions in a routing design can contribute to routing complexity in a large system.
複雑さをルーティングすることは、トラブルシューティングや迅速な問題解決に影響を与えますネットワーク管理の難しさ、につながることができます。これは、ネットワークを介して、望ましいサービス品質未満になることができます。複雑なルーティングポリシーとルーティング設計の特殊なケースまたは例外は、大規模システムでの複雑さをルーティングに貢献することができます。
Routing Policy refers to the administrative criteria for handling routing information, commonly in the form of routing path selection and route filtering. The way routing information is handled has a direct impact on traffic flow within a network and across domains. As a result, it affects business agreements among different networks. Therefore, the determination of routing policy is largely dominated by non-technical concerns, such as business considerations. Routing policy can be very complex, which would make management and configuration an unscalable task.
ルーティングポリシーは、一般的に経路選択と経路フィルタリングルーティングの形で、ルーティング情報を処理するための管理基準を指します。ルーティング情報が処理される方法は、ネットワーク内及びドメイン間のトラフィックフローに直接影響を有します。その結果、異なるネットワーク間の業務契約に影響を与えます。したがって、ルーティングポリシーの決意は、主に、このようなビジネス上の考慮事項などの非技術的な問題によって支配されます。ルーティングポリシーは、管理と構成スケーラブルタスクになるだろうこれは、非常に複雑になることがあります。
The keys to reducing routing complexity are systematic as well as consistent routing scheme and a routing policy that is simple but meets the requirement of administrative polices.
ルーティングの複雑さを軽減するための鍵は、体系的なだけでなく、一貫性のあるルーティング方式とシンプルですが、管理ポリシーの要件を満たしているルーティングポリシーです。
Another factor contributing to the complexity of routing management is prefix-based route filtering. As is well known, prefix-based filtering is necessary in order to protect the integrity of the routing system. This becomes a challenge when the number of routes known to the Internet is as large as it is today.
ルーティング管理の複雑さに寄与するもう一つの要因は、プレフィックスベースの経路フィルタリングです。周知のように、プレフィックスベースのフィルタリングは、ルーティングシステムの完全性を保護するために必要です。これは、インターネットに知られているルートの数は、それが今日のように大きい課題となっています。
Today's commonly deployed routing protocols are IS-IS or OSPF for Interior routing (aka IGP) and BGP for exterior routing (aka EGP). In terms of scaling and other aspects, these protocols are already an improvement over the previous generation of protocols, such as RIP and EGP. However, scalability is still a major issue when a network is large, when a routing design is insensitive to scaling issues, or the protocol implementation is inefficient.
今日の一般的な展開ルーティングプロトコルは、IS-ISまたはOSPF外部ルーティング（別名EGP）用インテリア・ルーティング（別名IGP）とBGPのためのものです。スケーリングおよび他の態様の観点から、これらのプロトコルは、すでにそのようなRIPやEGPなどのプロトコルの前の世代に比べて改善されています。ネットワークが大きい場合、ルーティング設計は、スケーリングの問題に影響されない、またはプロトコルの実装が非効率的であるときしかし、スケーラビリティが主要な問題は、まだあります。
As described earlier in the document, IS-IS and OSPF are Link State routing protocols. The basic components of a link state routing protocol are i) generation and maintenance of a Link-State-DataBase (LSDB) that describes the routing topology of a given routing area; and ii) route calculation based on the topology information in the database. Each node in a routing area is responsible for describing its local routing topology in a Link State Advertisement or LSA (LSP in the case of IS-IS.) Each individually generated LSA will be distributed or flooded to all the routers in the area. Each router receives LSAs from all the other routers, forming a link-state-database that reflects the routing topology of the entire routing area.
文書で前述したように、IS-IS、およびOSPFはリンクステートルーティングプロトコルです。リンクステートルーティングプロトコルの基本的な構成要素は、iが所与のルーティング領域のルーティングトポロジを記述するリンクステートデータベース（LSDB）の）の生成および維持です。及びii）ルート計算データベース内のトポロジ情報に基づい。ルーティング領域内の各ノードは、リンクステート広告またはLSAにそのローカルルーティングトポロジを説明する責任がある（LSP IS-ISの場合。）は、それぞれ個別にLSAは、エリア内のすべてのルータに分配またはフラッディングする生成。各ルータは、全体のルーティングエリアのルーティングトポロジを反映したリンクステートデータベースを形成し、他のすべてのルータからLSAを受信します。
The main associated scaling issues are the complexity of the link state flooding and routing calculation, plus the size of the LSDB which contributes to the cost of routing calculation and router memory consumption.
主な関連したスケーリングの問題は、リンク状態洪水やルーティング計算の複雑さに加え、計算とルータのメモリ消費量をルーティングのコストに貢献するLSDBのサイズです。
Flooding is the process by which a router distributes its self-originated LSA to the rest of the routers in the area in case of any link state change. A router will send the LSA via all its interfaces. When receiving an LSA update, a router validates the information and updates its local LSDB before sending it out via all its own interfaces, except the one from which it received the original LSA update. Given the nature of IS-IS or OSPF flooding, a full-mesh network with N routers would have O(N^2) of LSAs flooded in the network when a single link failure occurs. A single router outage would cause LSA in the order of O(N^3) to be flooded in the system.
洪水は、ルータが任意のリンク状態が変化した場合にはエリア内のルータの残りの部分に自己発信LSAを配布するプロセスです。ルータは、そのすべてのインタフェースを介してLSAを送信します。 LSAの更新を受信した場合、ルータは、情報を検証し、それが元のLSAの更新を受信したから1を除いて、すべての独自のインターフェースを介してそれを送信する前に、そのローカルLSDBを更新します。 IS-ISまたはOSPF洪水の性質を考えると、Nルータとフルメッシュネットワークは、単一リンク障害が発生した場合、ネットワーク内の浸水LSAのO（N ^ 2）を持っています。単一ルータの停止はシステムにフラッディングされるべきO（N ^ 3）の順にLSAを引き起こします。
In the case of OSPF, the protocol will refresh or flood every 30 minutes even under stable network conditions, which could increase the problem for an already highly loaded router.
OSPFの場合、プロトコルは、すでに非常にロードされたルータの問題を高める可能性がある、でも安定したネットワーク環境の下で、30分ごとに更新したり、フラッディングします。
From the above discussion, one can easily observe that the more routers and adjacencies in a Link State IGP routing area, the more CPU burden there are for each router to bear. When a network is unstable, the load will be amplified.
上記の議論から、人は簡単リンクステートIGPルーティングエリア内の複数のルータとの隣接関係は、より多くのCPUの負担が負担する各ルータのためにそこにあることを観察することができます。ネットワークが不安定な場合、負荷が増幅されます。
A link-state protocol typically uses Dijkstra's Shortest Path First (SPF) algorithm for route calculation. The Dijkstra algorithm scales to the order of O(N^2), where N is the number of nodes. The algorithm could be improved to the order of O(l*logN) where l is the number of links in the network and N is the number of destinations or routers [6].
リンクステートプロトコルは、通常、ルート計算のためのDijkstraのSPF（Shortest Path First）アルゴリズムを使用しています。ダイクストラアルゴリズムスケールNはノードの数であり、O（N ^ 2）の順に。アルゴリズムは、lは、ネットワーク内のリンクの数であり、Nは、目的地やルータ[6]の数であり、O（L * logN個）の順に向上させることができました。
Consequently, link state routing protocols do not scale to a network topology with many routers and excessive adjacencies in an area. When the network topology is unstable, the computation, processing and bandwidth costs are magnified, which causes excessive consumption of router resources. When the instability prevents IS-IS or OSPF from maintaining adjacencies, a network routing meltdown occurs.
そのため、リンクステートルーティングプロトコルは、地域の多くのルータや過度の隣接関係を持つネットワークトポロジに拡張できません。ネットワークトポロジーが不安定な場合には、計算、処理、および帯域幅のコストは、ルータ資源の過剰消費を引き起こす、拡大されています。不安定性は隣接関係を維持するから、IS-ISまたはOSPFを防止する場合、ネットワーク・ルーティング・メルトダウンが発生します。
Node adjacencies are discovered and maintained through the exchange of HELLO messages sent periodically from each node. When a node fails to receive HELLO messages from its neighbor within a certain period of time (40 seconds for OSPF and less for IS-IS), it considers the neighbor down. When heavy flooding, re-calculation and other activities happen that make router CPU a scarce resource, a router may not be able to allocate CPU time to send or process HELLO packets. Routers in the network then lose adjacency, which magnifies the instability. As a result, an isolated instability can escalate to a routing failure across the entire network.
ノードの隣接関係を発見し、各ノードから定期的に送信されるHELLOメッセージの交換を介して維持されます。ノードは、一定の期間内にそのネイバーからHELLOメッセージ（IS-ISのためのOSPFと少ないため40秒）を受信するように失敗した場合、それがダウン隣人を検討します。大洪水、再計算およびその他の活動は、ルータのCPU希少資源作ることが起こると、ルータは、HELLOパケットを送信またはプロセスにCPU時間を割り当てることができない場合があります。ネットワーク内のルータは、不安定性を拡大隣接を失います。結果として、単離された不安定性は、ネットワーク全体のルーティングの失敗にエスカレートすることができます。
Link-state IGPs also do not scale well to carry a large number of routes such as the 70,000 routes known to the Internet today. Since external routes are included in the link-state-database and in LSA (LSP for IS-IS) updates, the link bandwidth and router memory consumption will be tremendous. Moreover, due to the large size of LSA updates, it would aggravate router resource consumption in the process of LSA flooding, especially under unstable network condition.
リンク状態のIGPはまた、今日のインターネットに知られている7万ルートとして多数のルートを運ぶためにうまくスケールしません。外部経路がリンクステートデータベースと更新（IS-IS用LSP）LSAに含まれているため、リンク帯域幅とルータのメモリ消費量が多大であろう。また、LSA更新の大きなサイズのため、それは特に不安定なネットワーク条件の下で、LSAフラッディングの過程で、ルータのリソース消費を悪化させるだろう。
To summarize, a scalable design should avoid inclusion of too many routers in an IGP routing area, a large external routes carried by IGP and, more important, excessive adjacencies in the area.
要約すると、スケーラブルな設計は、IGPルーティングエリアにあまりにも多くのルーター、IGPによって運ばれ、大きな外部ルートや地域で、より重要なのは、過度の隣接関係の混入を避ける必要があります。
BGP is an inter-domain routing protocol allowing the exchange of routing or reachability information between different Autonomous-System networks. Functionally, BGP is composed of External BGP(E-BGP) and Internal BGP(I-BGP). E-BGP is used for exchanging external routes while I-BGP is typically used for distributing externally learned routes within an AS.
BGPは、異なる自律システムネットワーク間ルーティングまたは到達可能性情報の交換を可能にするドメイン間ルーティングプロトコルです。機能的には、BGPは外部BGP（E-BGP）と内部BGP（I-BGP）で構成されています。 E-BGPは、I-BGPは通常、AS内で外部から学習したルートを配布するために使用されている間、外部ルートを交換するために使用されます。
The general costs of BGP are as follows:
次のようにBGPの一般的な費用は以下のとおりです。
o CPU consumption in BGP session establishment, route selection, routing information processing, and handling of routing updates
BGPセッション確立中のOのCPU消費量、経路選択、情報処理ルーティング、ルーティングアップデートの取り扱い
o Router memory to install routes and multiple paths associated with the routes.
Oルータのメモリはルートおよびルートに関連付けられた複数のパスをインストールします。
The major scaling issue associated with BGP lie in the full mesh I-BGP connections. Since it does not scale for an IGP to carry externally learned prefixes, as mentioned in the previous section, I-BGP assumes this duty. In order to prevent routing loops, prefixes learned via I-BGP are prohibited from being advertised to another I-BGP speaker. As a result, a full mesh of I-BGP sessions among the routers within an AS is required. In an AS with N routers, each router will have to establish I-BGP sessions with N-1 routers, and the system complexity is in the order of O(N^2). Therefore, BGP scales poorly when the number of routers involved in I-BGP mesh is large.
フルメッシュI-BGP接続にBGPの嘘に関連する主要なスケーリングの問題。前節で述べたように、それは、外部から学んだプレフィックスを運ぶためにIGPのためにスケールしないので、I-BGPはこの義務を前提としています。ルーティングループを防ぐために、接頭辞は、I-BGP経由で学習を別のI-BGPスピーカーに広告が禁止されています。その結果、AS内のルータ間でI-BGPセッションのフルメッシュが必要です。 Nルータと同様に、各ルータは、N-1ルータとI-BGPセッションを確立する必要があり、システムの複雑されますO（N ^ 2）程度です。 I-BGPメッシュに関与するルータの数が多い場合そのため、BGPは不十分スケール。
A large network normally learns all the routes known to the Internet, which is approximately 70,000. I-BGP will need to carry all these routes.
大規模ネットワークは、通常、約70,000であるインターネットに知られているすべてのルートを学習します。 I-BGPは、これらすべてのルートを実行する必要があります。
The large number of I-BGP sessions and routes consumes tremendous resources from each router, especially during BGP session establishment and during periods of heavy route flapping.
I-BGPセッションと多数のルートは、特にBGPセッションの確立中に、重いルートフラッピングの期間中、各ルータからの膨大なリソースを消費します。
Frequent routing updates are another potential scaling problem in large networks. BGP uses incremental updates and sends out routing information about unreachable routes quickly for fast convergence. This is a great improvement from EGP, in which the whole routing table is updated at a fixed time interval. However, when a network is unstable the updates, especially those containing route withdrawals, are sent immediately, causing global BGP updates. As a result, network instability initiated anywhere in a network triggers updates all over the Internet. This effect is magnified when large amounts of routes are visible to the Internet, putting a heavy load on routers that participate in BGP.
頻繁なルーティングアップデートは、大規模なネットワーク内の別の潜在的なスケーリング問題です。 BGPは、増分更新を使用し、高速な収束のために素早く到達不能ルートに関するルーティング情報を送信します。これは、全体のルーティングテーブルは、一定の時間間隔で更新されたEGPから大きな改善です。ネットワークが不安定な場合ただし、更新は、特にルートの引き出しを含むものは、グローバルBGPアップデートを引き起こし、すぐに送信されます。その結果、ネットワーク内のどこにでも開始されたネットワークの不安定性は、すべてのインターネット上での更新をトリガします。ルート大量のインターネットに表示されている場合は、この効果は、BGPに参加ルータに大きな負荷をかけ、拡大しています。
The introduction of a routing hierarchy in BGP, through I-BGP Route Reflectors [7] and BGP Confederations [8], for example, will help alleviate the scaling problem caused by the requirement of full mesh I-BGP establishment.
I-BGPルートリフレクタ[7]と[8] BGP連合を介してBGPでルーティング階層の導入は、例えば、フルメッシュI-BGP確立の要求に起因するスケーリング問題を軽減するのに役立ちます。
Another potential solution is to avoid the requirement of full mesh pairwise I-BGP connections. This will change the way that BGP distributes routing information among the I-BGP peers. Mechanisms worth considering are using multicast to distribute information or adopting flooding mechanisms similar to those used in IS-IS or OSPF. Further investigation of the implication of using such mechanism for BGP route distribution is needed.
別の潜在的な解決策は、フルメッシュペアごとのI-BGP接続の必要性を回避することです。これは、BGPは、I-BGPピア間でルーティング情報を配布する方法が変更されます。検討に値するメカニズムは、情報を配布するために、マルチキャストを使用して、またはIS-ISまたはOSPFで使用されるものと同様の氾濫メカニズムを採用しています。 BGPルート配布のためのそのような機構を使用することの含意のさらなる調査が必要です。
Route dampening [9] is one way to reduce excessive updates triggered by route flapping. The trade-off between fast convergence and stability of the network should be considered, as discussed in section 6.3.
減衰経路は、[9]ルートフラッピングによってトリガ過度の更新を減少させる一つの方法です。セクション6.3で説明したように、ネットワークの高速収束および安定性の間のトレードオフを考慮しなければなりません。
The routing design for a large-scale network should achieve the basic goals of accuracy, stability, redundancy and convergence as described in Section 2 and moreover should achieve it in a scalable fashion.
さらに、第2節で説明したように、大規模ネットワークのためのルーティング設計は、スケーラブルな方法でそれを達成する必要があり、精度、安定性、冗長性と収束の基本的な目標を達成すべきです。
How routing scales is influenced by protocol design decisions, protocol implementation decisions, and network design decisions. A network engineer has direct control over network design decisions and can have substantial influence over protocol design and implementation. The focus of this document is network design decisions.
どのようにルーティングスケールは、プロトコルの設計上の決定、プロトコル実装の決定、およびネットワークの設計上の決定に影響を受けています。ネットワークエンジニアは、ネットワークの設計上の決定を直接制御を持ち、プロトコルの設計と実装に対する実質的な影響力を持つことができます。このドキュメントの焦点は、ネットワークの設計上の決定です。
Following is a set of design principles for making a large network routing system more scalable:
大規模なネットワークのルーティングシステムは、よりスケーラブル作るための設計原理のセットは、次のとおりです。
o Building hierarchy o Compartmentalization o Making proper trade-offs o Reducing route processing burdens o Defining scalable routing policies and implementation o Utilizing out-of-band routing assistance
アウトオブバンドの活用支援をルーティングoをスケーラブルなルーティングポリシーおよび実装の定義oをルート処理負担を軽減oを適切なトレードオフを作る〇〇ビルの階層0の区画化
As discussed in Section 5.1, OSPF and IS-IS scale poorly when a network has a large number of routers and in particular, a large quantity of adjacencies. This has unfortunately been proven by networks that deploy IP over ATM with full mesh adjacencies among the routers. The full mesh overlay design combined with the inefficient protocol implementation led to disastrous network outages. A lesson learned from this is to avoid full mesh overlay topology in a large network with a large, flat network routing structure.
セクション5.1で議論したように、OSPFとは、ネットワークルーターの、特に多数の隣接関係を大量にある場合不十分スケール-です。これは、残念ながらルータの中でフルメッシュ隣接関係でATM上でIPを展開したネットワークによって証明されています。非効率的なプロトコル実装と組み合わせるフルメッシュオーバーレイの設計は悲惨なネットワークの停止につながりました。このことから学んだ教訓は、大規模な、フラットなネットワークのルーティング構造を持つ大規模なネットワークでは、フルメッシュ・オーバーレイ・トポロジーを避けるためです。
Building hierarchical routing structures in the network is the key to achieving routing scalability in a large network. As discussed earlier in this document, large networks are usually composed of many routers with a complex topology, which results in a large number of adjacencies. As also discussed earlier, currently available routing protocols scale poorly for handling a large number of routers in a routing domain or many adjacencies among the routers. Therefore, it is sensible to build a routing hierarchy to reduce the number of routers as well as the number of adjacencies in a routing domain.
ネットワーク内の階層型ルーティング構造を構築する大規模なネットワークでのルーティングのスケーラビリティを達成するための鍵です。本書で前述したように、大規模なネットワークは、通常、隣接の多数になる複合トポロジで多くのルータで構成されています。また、前述したように、現在利用可能なルーティングプロトコルは、ルータ間のルーティングドメインまたは多数の隣接関係にルータの多数を処理するために不十分なスケール。したがって、ルータの数だけでなく、ルーティングドメイン内の隣接関係の数を減らすために、ルーティング階層を構築することが賢明です。
The current common practice is to build a two-tiered hierarchy in a network with a center component (or transit core network) to which a number of outskirt components (or access networks) attach. The transit core network covers the entire geographical area the network serves; each access network (aka regional network) covers one region. There are usually no direct link connections among the regional components. Traffic from one regional network to another traverses the transit core. Customer networks connect only to access or regional networks. There are a number of ways to build a routing hierarchy in the above described hierarchical network topology.
現在の一般的な方法は、センタ成分（またはトランジットコアネットワーク）郊外成分（またはアクセスネットワーク）の数が付着するとネットワーク内の2つの層階層を構築することです。トランジットコアネットワークは、ネットワークが機能する全体の地理的領域をカバーします。各アクセスネットワーク（別名、地域ネットワーク）は、一方の領域をカバーしています。地域のコンポーネントの間には直接のリンク接続は、通常はありません。 1つの地域ネットワークから別のトラフィックはトランジットコアを横断します。顧客ネットワークは、アクセスまたは地域ネットワークにのみ接続します。上記の階層的なネットワークトポロジのルーティング階層を構築するためのいくつかの方法があります。
1) Completely Separate Routing Domains
1）完全に別のルーティングドメイン
This design treats the transit core network and each regional network as completely independent ASs with respect to routing, and each AS runs an independent IGP. Each regional network E-BGP with the transit core for exchanging routing knowledge. Full I-BGP connections need to be established only within each component network. With this design, the maximum number of routers in an IGP domain is the total number of routers in each component. As a result, the IGP processing load is reduced, and the number of routers in an I-BGP mesh in the network routing system is decreased dramatically.
この設計は、トランジットコアネットワーク及びルーティングに対する各地域のネットワークのような完全に独立したお尻扱い、各ASは、独立したIGPを実行します。ルーティング知識を交換するための通過コアを有する各地域ネットワークE-BGP。全I-BGP接続は、各コンポーネントのネットワーク内で確立する必要があります。この設計では、IGPドメイン内のルータの最大数は、各成分のルータの総数です。結果として、IGP処理の負荷が低減され、I-BGPのルータの数が劇的に減少されているネットワークルーティングシステムにメッシュ。
Another advantage of this design is that it compartmentalizes the routing system so that instability in one such component has less impact on the entire system. See the discussion in section 6.2.
この設計の別の利点は、そのような成分の不安定は、システム全体にあまり影響を有するように、それがルーティングシステムを区画することです。セクション6.2での議論を参照してください。
The main disadvantage of this scheme is that it inserts one extra AS in the routing path when routes are advertised to the Internet via BGP. This extra AS in the path may cause route selection difficulties for other providers.
この方式の主な欠点は、ルートがBGPを介してインターネットにアドバタイズされる場合、それは、ルーティングパスにASの余分なものを挿入することです。パス内のASこの余分は、他のプロバイダのための経路選択の問題を引き起こす可能性があります。
2) One Domain with IGP and BGP Hierarchy
IGPとBGP階層を持つ2）一つのドメイン
This method includes the transit core and each regional network into one AS domain. The routing hierarchy is realized by utilizing multi-level IS-IS or OSPF areas and either BGP Confederation or I-BGP Reflector or a combination of the two.
この方法は、ドメインとして一つにトランジットコアと各地域のネットワークを含みます。ルーティング階層は、マルチレベルIS-ISまたはOSPFエリアを利用し、BGP連合又はI-BGPリフレクタまたはその2つの組合せのいずれかによって実現されます。
This mechanism avoids the introduction of an extra AS in the routing path, which is an advantage over the method described in Point 1). However, multi-area hierarchical IGP is rarely used now-a-days in large networks since most of them are using IS-IS for internal routing, which does not have sufficient multi-level support. Although IS-IS supports multi-area routing, it imposes a strict hierarchy between backbone and sub-areas and allows only the advertisement of a default route from the backbone area to the sub-areas instead of specific prefixes. This restriction may be suitable for a network with a simple sub-area topology. A sub-area in a large network, typically a regional or access network, itself has a complicated topology. Receiving highly abstract routing information, such as a default route, would affect the sub-area's ability to make route selections required for traffic engineering. It would also limit the information passed to external ASs, for example, IGP-derived BGP Multi-Exit-Discriminator (MED) information.
この機構は、ポイント1に記載された方法よりも有利であるルーティングパス）のように余分の導入を回避します。それらのほとんどは、十分なマルチレベルをサポートしていない内部ルーティングに対して、IS-ISを使用しているので、マルチエリア階層IGPはほとんど大規模なネットワークで、今-日を使用されていません。 IS-ISがマルチエリアルーティングをサポートしていますが、それはバックボーンとサブエリア間の厳密な階層を課し、その代わりに、特定のプレフィックスのサブ領域にのみバックボーンエリアからデフォルトルートの広告を可能にします。この制限は、単純なサブエリアのトポロジーを有するネットワークのために適切であり得ます。典型的には、大規模なネットワーク内のサブ領域、地域又はアクセスネットワーク、それ自体が複雑なトポロジーを有します。そのようなデフォルトルートとして、抽象度の高いルーティング情報を受信し、トラフィックエンジニアリングのために必要なルート選択を行うためのサブエリアの能力に影響を与えます。また、外部のASに渡される情報、例えば、IGP由来BGPマルチ出口弁別（MED）情報を制限します。
Efforts are being made to modify the IS-IS protocol to allow the distribution of specific route from backbone area to sub-areas. A mechanism facilitates such distribution is specified in [15]. When implementation of such mechanism become available, implementing multi-level IGP will be an attractive option for building routing hierarchy within a large network.
努力がサブエリアにバックボーンエリアから特定のルートの分布を可能にするために、IS-ISプロトコルを修正するために行われています。機構は、このような分布は[15]で指定され容易にします。このようなメカニズムの実装が利用可能になったとき、マルチレベルのIGPを実装する大規模ネットワーク内のルーティング階層を構築するための魅力的な選択肢であろう。
3) One IGP Area with BGP Hierarchy
BGP階層を持つ3）一つのIGPエリア
In lieu of multi-area IS-IS, the routing hierarchy could be achieved by defining one IGP domain for the entire network while employing a BGP hierarchy. Fortunately, the hierarchical topology of the network in this case helps reduce adjacencies in the routing domain (recall there are no connections among the second-level network components). In addition, improvements could be made to further reduce the adjacency by carefully arranging the adjacencies to keep them at a minimum but still achieve good redundancy. However, this is less than ideal since the number of routers remains unchanged, which increases the load on the SPF calculation. Moreover, instability within any regional network would still affect the entire network (that is, there would be no fault isolation).
マルチエリアの代わりに、IS-IS、BGPの階層を使用しながら、ルーティング階層は、ネットワーク全体のための1つのIGPドメインを定義することによって達成することができます。幸いなことに、この場合のネットワークの階層的トポロジは、（第2のレベルのネットワークコンポーネント間の接続がないリコール）ルーティングドメイン内の隣接関係を減らすことができます。また、改善がさらに慎重に最低でそれらを保つそれでも良い冗長性を実現するために隣接関係を配置することにより、隣接関係を減らすために作ることができます。ルータの数は、SPF計算の負荷を増大させる、変わらないので、これは理想的な未満です。また、任意の地域ネットワーク内の不安定性は依然として（、全く故障分離がないということがある）、ネットワーク全体に影響を与えます。
Even with one IGP domain, it is possible to build BGP hierarchy to make I-BGP more scalable in the network. BGP Reflectors and BGP Confederations are existing mechanisms to address the scaling problem of full-mesh I-BGP.
一つでもIGPドメインとは、ネットワークにおけるI-BGPは、よりスケーラブルにするためにBGPの階層構造を構築することが可能です。 BGPリフレクタとBGPコンフェデレーションは、フルメッシュI-BGPのスケーリングの問題に対処するためのメカニズムを既存しています。
Further, a BGP reflector provides the ability to build more than two levels of hierarchy, as long as the interactions among the different levels of the hierarchy are carefully arranged to avoid the possibility of creating routing loops.
さらに、BGPリフレクタであれば、階層の異なるレベル間の相互作用が慎重にルーティングループを作成する可能性を避けるように配置されているように、階層構造の二つ以上のレベルを構築する能力を提供します。
Questions worth asking are: "Are two levels of routing hierarchy sufficient for handling scaling issues?" "Is there really a need for more than two levels of hierarchy?"
尋ねる価値の質問は以下のとおりです。「ルーティング階層の2つのレベルのスケーリングの問題を処理するのに十分か？」 「階層の二つ以上のレベルの必要性が本当にあるの？」
When a second-tier sub-domain of a large network, such as a regional network, grows too big for routing protocols to handle, either another layer of hierarchy needs to be introduced or the sub-domain needs to be split into multiple second-tiered sub-domains.
そのような地域ネットワークのような大規模なネットワークの第2の層のサブドメインは、ルーティングプロトコルが処理するためには大きすぎる成長するとき、階層の別の層のいずれかを導入する必要があるまたはサブドメインは、複数の2次に分割する必要があります階層のサブドメイン。
Keeping two levels of hierarchy and adding more sub-domains appears to be more manageable than adding another level to the hierarchy. However, one concern is to avoid adding more nodes to the top-level or transit core network to make it less scalable. Connecting the split sub-areas to the same core router would eliminate the need to add more nodes in the core area than is recommended.
階層2つのレベルを維持し、複数のサブドメインを追加する階層の別のレベルを追加するよりも扱いやすいように見えます。しかし、一つの懸念は、それがあまりスケーラブルにするために、トップレベルまたはトランジットコアネットワークにノードを追加することを避けるためです。同じコアルータに分割されたサブ領域を接続することが推奨されるよりも、コア領域内の複数のノードを追加する必要がなくなります。
Having more than two levels of hierarchy would exceed the capability of IGPs as they are defined today. In OSPF, for example, all the areas must be connected via the backbone area, which eliminates the possibility of having more than two levels of hierarchy. IS-IS has the same limitation. Therefore, the protocols need to be redefined should more than two hierarchical layers in IGP be desirable.
彼らは今日で定義した通りである階層の二つ以上のレベルを持つことのIGPの能力を超えるでしょう。 OSPFでは、例えば、全ての領域は、階層つ以上のレベルを有する可能性を排除するバックボーンエリアを介して接続されなければなりません。 IS-ISは、同じ制限があります。したがって、プロトコルはIGPでつ以上の階層が望まなければならない再定義する必要があります。
The complexity of protocols and management will increase with the number of levels added to the hierarchy. According to [6], most of the OSPF protocol bugs found over the years are related to routing area support. Because the interaction among the multiple levels increases management and debugging complexity, it is desirable to keep the levels within a hierarchy to a minimum.
プロトコルおよび管理の複雑さは、階層に追加レベルの数とともに増加します。 [6]によると、年間で見出さOSPFプロトコルバグの大部分は領域サポートをルーティングに関連しています。複数のレベル間の相互作用は、管理とデバッグの複雑さを増加させるので、最小限に階層内のレベルを維持することが望ましいです。
A scalable routing design of a large network should be able to localize problems or failures, thus preventing them from spreading to the entire network, consuming resources of network routers, and causing network wide instability. This is compartmentalization. Network compartmentalization makes fault isolation possible which contributes the stability of a large network.
大規模ネットワークのスケーラブルなルーティングの設計は、このように、ネットワーク全体に広がるネットワークルータのリソースを消費し、ネットワーク全体の不安定性を引き起こすことから、それらを防止、問題または障害をローカライズすることができなければなりません。これは区画です。ネットワーク区画化は、大規模なネットワークの安定性に貢献している障害の分離を可能にします。
To achieve compartmentalization in routing design for a large network, one needs to avoid a design where the whole large network is one flat routing system or routing domain. This is the reason for the architecture of dividing interior and exterior routing in the global routing system. Within a network, it is best to divide the network into multiple routing domains or multiple routing areas. For example, in OSPF, only summary route SLAs, rather than individual area routes, are flooded beyond the area. When an area border router aggregates the routes in its sub-area, instability of any route included in the summary route would not cause flooding of SLAs to other areas. As a result, router resources in other areas would not be consumed for handling flooding and the SPF recalculation. In other words, instability within each individual area would be prevented from spreading to the entire routing domain.
大規模なネットワークの設計をルーティングに区画化を達成するためには、全体の大規模なネットワークが1つのフラットルーティングシステムまたはルーティングドメインで設計を避けるために必要です。これは、グローバルルーティングシステムに内部と外部のルーティングを分割するアーキテクチャの理由です。ネットワーク内で、複数のルーティングドメインまたは複数のルーティングエリアにネットワークを分割するのが最善です。例えば、OSPFに、概要のみルートのSLAはなく、個々の領域のルートは、領域を超えてフラッディングされます。エリア境界ルータはそのサブエリア内のルートを集約すると、任意の経路の不安定性は、他の地域へのSLAの洪水を起こさないサマリールートに含まれています。その結果、他の分野でのルータのリソースは、洪水やSPF再計算を処理するために消費されません。換言すれば、それぞれの個々の領域内の不安定性は、全体のルーティングドメインに広がるのを防止することになります。
Since building a routing hierarchy essentially divides a big routing area into smaller areas or domains, it help achieve the goal of compartmentalization.
ルーティング階層を構築することは、本質的に小さい領域またはドメインに大きなルーティングエリアを分割しているので、それは区画化の目標を達成するのを助けます。
When designing routing for a large network, the overall goal should be set with considerations of routing scalability and stability. The trade-offs between conflicting goals should be taken into account. Examples of such trade-offs are redundancy vs. scalability and convergence vs. stability.
大規模なネットワークのルーティングを設計するとき、全体的な目標は、ルーティング拡張性と安定性を考慮して設定する必要があります。相反する目標の間のトレードオフを考慮しなければなりません。このようなトレードオフの例としては、安定性対拡張性と収束対冗長です。
Redundancy introduces complexity and increased adjacencies to the network topology. Redundancy also imposes the need for as many alternative paths as possible for each route, which increases route processing and storage burdens. Because of these problems, it may be necessary to sacrifice absolute redundancy in favor of a reasonable level that scales better for the routing system.
冗長性は、複雑さを紹介し、ネットワークトポロジに隣接増加しました。冗長性はまた、経路処理および記憶負担を増大させる各ルートについて、できるだけ多くの代替パスの必要性を課します。これらの問題のため、ルーティングシステムのためのより良いスケーリング合理的なレベルを支持して絶対冗長性を犠牲にする必要があるかもしれません。
Fast convergence requires that changes in network topology be propagated to the network as quickly as possible. Such action increases routing updates and, consequently, the route processing burden. The burden is aggravated when a network carries full Internet routing information, as large networks usually do, and topology changes happen frequently. Route dampening may be necessary to achieve stability at the expense of absolute fast convergence.
高速コンバージェンスは、ネットワークトポロジの変更が可能な限り迅速にネットワークに伝播されている必要があります。そのようなアクションは、ルーティングアップデートと、その結果、経路処理負担を増大させます。大規模なネットワークは通常どおりネットワークは、完全なインターネットルーティング情報を搬送し、トポロジの変更が頻繁に発生したときの負担がさらに悪化します。ルートダンプニングは絶対に高速コンバージェンスを犠牲にして安定性を達成する必要があるかもしれません。
The tasks of reducing routing processing burdens includes: i) strategically place the routing intelligence within the network, ii) avoid carrying unnecessary routing information and iii) reduce the impact of route flapping.
ルーティング処理の負担を低減するタスクが含まれた：i）戦略的に、ネットワーク内のルーティング・インテリジェンスを配置II）不要なルーティング情報を運ぶ回避およびiii）ルートフラッピングの影響を低減します。
A router that executes routing policies, performs route filtering and dampening is said to posses routing intelligence. Routing intelligence is needed for a network i) to enforce the business agreement between network entities in the form of routing policies; ii) to protect the integrity of the routing information within the network and sometimes iii) to shield a network from instability happening elsewhere in the Internet.
ルーティングポリシーを実行するルータは、経路フィルタリングを実行し、減衰は、ルーティング・インテリジェンスを保有すると言われています。ルーティングインテリジェンスは、ルーティングポリシーの形式でネットワークエンティティ間の業務契約を強制するネットワークI）のために必要とされます。 II）ネットワーク、時にはIII）インターネットの他の場所で起こって不安定性からネットワークを保護するための内のルーティング情報の完全性を保護します。
The more routing intelligence a router has, the more resources of the router are needed to perform those tasks. It is logical, then, to place as little routing intelligence as possible on routers that already are heavily burdened with other tasks.
以上のルーティングインテリジェンスは、ルータは、ルータの多くのリソースは、これらのタスクを実行するために必要とされています。それは、すでに大きく他のタスクを抱えているルータ上でできるだけ少ないルーティングインテリジェンスを配置し、その後、論理的です。
Usually, traffic is heavily concentrated in the core of the network. Because traffic aggregates from the edge of the network toward the core, traffic is less concentrated near the edge of the network. Consequently, to build a scalable routing system, it is wise to place routing intelligence at the edge of the network, especially in the networks deployed with routers that do not sufficiently decouple forwarding and routing. In addition, pushing routing intelligency as close to the edge of the network as possible also serves the purpose of distributing computational and configuration burdens across all routers.
通常、トラフィックは重くネットワークのコアに集中しています。トラフィックがコアに向かって、ネットワークのエッジから集約しているので、トラフィックは、ネットワークのエッジ付近のより低濃度です。その結果、スケーラブルなルーティングシステムを構築するために、特に十分に転送およびルーティングを分離しないルータで展開したネットワークでは、ネットワークのエッジにルーティングインテリジェンスを配置するのが賢明です。また、できるだけネットワークのエッジに近いプッシュルーティングintelligencyはまた、すべてのルータを横断計算および設定負荷を分配する目的を果たします。
It is also desirable to move the heavy burden of processing routes to out-of-band processors, freeing more resources in network routers for packet forwarding and handling.
パケット転送及び処理のためのネットワークルータに多くのリソースを解放し、アウト・オブ・バンド・プロセッサに処理経路の重荷を移動することも望ましいです。
As discussed in Section 4.1, a large number of routes in the system is one of the major culprits in route scaling problems. Therefore, it is best to reduce the number of routes in the system without losing necessary routing information.
セクション4.1で議論するように、システム内のルートの多くは、ルートスケーリング問題の主要な原因の一つです。したがって、必要なルーティング情報を失うことなく、システム内のルートの数を低減することが最良です。
CIDR as specified in [10] provides a mechanism to aggregate routes for efficiently utilizing IP address space as well as reducing the number of routes in the global routing table. CIDR offers a way to summarize routing information, which is one of the keys for routing scalability in today's Internet.
で指定されるようにCIDR [10]効率的にIPアドレス空間を利用するだけでなく、グローバルルーティングテーブル内のルートの数を減少させるための集約ルートの機構を提供します。 CIDRは、今日のインターネットでのスケーラビリティをルーティングするための鍵の一つであるルーティング情報を、要約する方法を提供しています。
Route aggregation would not only help global Internet scalability but would also contribute to scalability in local networks. The overall goal is to keep the routes in the backbone to a minimum.
ルート集約は、グローバルなインターネットのスケーラビリティを助けるだけでなく、ローカルネットワークに拡張性に貢献します。全体的な目標は、最小限のバックボーンにルートを維持することです。
To achieve better aggregation within the network; that is, to reduce the number of routes in the network, a block of consecutive IP addresses should be allocated to each access or regional network so that when a regional network announces its routes to the transit core network, they can be aggregated. This way, the core and other regional networks would not need to know the specific prefixes of any particular access network. Although assignment of customer addresses from a provider block would have to be planned to support aggregation, the effort would be worthwhile.
ネットワーク内でより良い凝集を達成するために、地域ネットワークは、トランジットコアネットワークへのルートを発表するとき、それらは凝集することができるように、すなわち、ネットワーク内のルートの数を減らすために、連続したIPアドレスのブロックは、各アクセスまたは地域ネットワークに割り当てられるべきです。この方法では、コアおよびその他の地域ネットワークは、特定のアクセスネットワークの特定の接頭辞を知っている必要はありません。プロバイダのブロックから顧客アドレスの割り当ては、集約をサポートするために計画しなければならないが、努力は価値があるだろう。
The use of a default route achieves ultimate route summarization, which reduces routing information to minimum. Route summarization also masks the instability associated with an individual route, for example, in the case of route flapping. It's beneficial for a network to utilize default routing when appropriate. For example, if a second-tiered regional network is a stub and there is no connected customer requesting full Internet routing information, the regional network can simply point default to its connected core network. However, over-summarization of routing information has the danger of losing routing granularity and as a result, management of network such as traffic engineering would be adversely affected. Therefore, caution needs to be exercised when using default routing.
デフォルトルートの使用を最小限にルーティング情報を減少させる究極のルート集約を実現します。ルート集約もマスクルートフラッピングの場合には、例えば、個々のルートに関連する不安定性。これは、適切なデフォルトのルーティングを利用するネットワークのために有益です。第二段地域ネットワークはスタブであり、完全なインターネットルーティング情報を要求しない接続された顧客が存在しない場合、例えば、地域ネットワークは、単に、その接続されたコアネットワークにデフォルトを指すことができます。しかし、過集約ルーティング情報のルーティング粒度を失う危険性があり、結果として、そのようなトラフィック・エンジニアリングなどのネットワークの管理が悪影響を受けることになります。そのため、注意がデフォルトルーティングを使用するときに行使する必要があります。
Due to the requirement of reliability, the connectivity in the Internet is rich, resulting in many paths toward a particular destination. In other words, there are many alternate paths in the BGP routing table towards the same destination, which consumes router memory and adds to the routing processing burden.
信頼性の要求に、インターネットに接続性は、特定の宛先に向けて多くのパスで得られ、リッチです。換言すれば、ルータのメモリを消費し、ルーティング処理負担を増大同じ宛先に向かってBGPルーティングテーブル内の多くの代替経路が存在します。
To make routing scale, it is desirable to reduce alternate paths while preserving reasonable redundancy. For example, on a given border router (such as a NAP router), one primary path plus an alternate path should provide reasonable redundancy. In this case, a third or a fourth alternate route could be discarded for the sake of scaling. This is a trade-off decision every network administrator needs to make based on the particular needs of her network.
ルーティングスケールを作るために、合理的な冗長性を維持しながら、代替パスを低減することが望ましいです。例えば、所与のボーダルータの一のプライマリパスプラス代替パス（例えばNAPルータとして）妥当な冗長性を提供すべきです。この場合、第三又は第四の代替経路は、スケーリングのために廃棄することができます。これは、すべてのネットワーク管理者は、彼女のネットワークの特定のニーズに基づいて行う必要があるトレードオフの決定です。
As mentioned earlier, one of the scaling issues in large networks is that a single router may fan out to hundreds of customer routers. As a result, resource consumption will be very intensive if all the customer routers communicate via BGP with the edge router. Is it necessary for the edge router to BGP with all of its attached customer routers?
先に述べたように、大規模ネットワークでのスケーリングの問題の一つは、単一のルータが顧客のルータの数百にファンアウトかもしれないということです。すべての顧客ルータがエッジルータでBGPを介して通信する場合、結果として、資源の消費量が非常に集中的になります。それは、その添付顧客のすべてのルータでBGPにエッジルータに必要ですか？
At first glance, it seems necessary for a customer network in a different Autonomous System(AS) to exchange routing information with the provider network via BGP. However, this is not necessarily the case. When a customer network is single-homed (that is, if the sole network connection for a customer is via its provider network), BGP is not necessary and static routing can work. Since the customer network is single-homed, static routing will not have any negative impact on services. The advantages are that the customer aggregation router will have fewer E-BGP sessions to handle, and no route flapping can result from the statically configured customer routes.
一見すると、BGPを経由して、プロバイダのネットワークでルーティング情報を交換するために、異なる自律システム（AS）内の顧客ネットワークのために必要であると考えられます。しかし、これは必ずしもそうではありません。顧客ネットワークは、（顧客の唯一のネットワーク接続は、そのプロバイダのネットワークを介して行われる場合には、である）シングルホームである場合、BGPは必要ではなく、静的ルーティングが機能することができます。顧客ネットワークがシングルホームであるので、スタティックルーティングは、サービス上の任意の負の影響を与えることはありません。利点は、顧客の集約ルータが処理するために、少数のE-BGPセッションを持つことになりますし、何のルートフラッピングが静的に設定された顧客のルートから生じることができないことです。
Configuration of the customer's static routes on the provider's aggregation router may add management overhead, especially if a customer advertises a large number of routes. On the other hand, the set of routes a customer announces to the provider usually changes infrequently; thus it requires low maintenance once it is configured.
プロバイダーの集約ルータ上の顧客のスタティックルートの設定は、顧客が多数のルートをアドバタイズする場合は特に、管理オーバーヘッドを追加することができます。一方、ルートのセットの顧客は通常、あまり頻繁に変更プロバイダに発表しました。したがって、それが設定されたら、低メンテナンスを必要とします。
As discussed earlier, route flapping is largely caused by link instability and/or BGP session instability that results in excessive routing updates across the Internet. Route flapping can originate anywhere in the global Internet and affect every network in the
前述したように、ルートフラッピングは、主リンクの不安定性及び/又はインターネットを介して過剰なルーティングアップデートをもたらすBGPセッションの不安定性によって引き起こされます。ルートフラッピングは、グローバルなインターネットのどこにでも発生し、内のすべてのネットワークに影響を与えることができます
Internet routing mesh (BGP mesh). Given that there are over 70,000 routes known to the Internet and there is little isolation for route flapping, handling route flapping could be overwhelming to routers in any network.
インターネットルーティングメッシュ（BGPメッシュ）。インターネットに知られ、7万以上のルートがあると少しルートフラッピングの分離、ルートフラッピングを処理する任意のネットワーク内のルータに圧倒的な可能性があることを考えます。
One way to reduce the effect of route flapping is to turn on route dampening as specified in [10]. Essentially, dampening suppresses an unstable route until it becomes stable. The current practice is for each ISP to enable route dampening on its border routers. This way, excessive routing updates can be stopped at the border.
ルートフラッピングの影響を低減する1つの方法は[10]で指定されるように減衰経路をオンにすることです。それが安定するまで基本的に、減衰は、不安定なルートを抑制します。現在の慣行は、各ISPはその境界ルータにルートダンプニングを可能にするためです。この方法では、過度のルーティングアップデートは、国境で停止させることができます。
An ideal model is to suppress the announcement of a flapping route right at the source. One way to implement this is to have a router recognize instability associated with its directly connected links and suppress the announcement of the route. So far, there is no such implementation. This approach should be explored.
理想的なモデルは、右のソースにフラッピングルートの告知を抑制することです。これを実現する1つの方法は、ルータが直接接続されたリンクに関連付けられた不安定性を認識し、ルートの発表を抑制することです。これまでのところ、そのような実装ではありません。このアプローチは、検討されるべきです。
Route aggregation often masks route flapping since components of an aggregated route (more specific routes) would not cause the aggregated route to flap. Therefore using CIDR can also help to alleviate route flapping.
集約された経路（より具体的なルート）の構成要素はフラップに集約経路を引き起こさないのでフラッピングルート集約しばしばマスク経路。したがって、CIDRを使用した場合も、ルートフラッピングを軽減するのに役立ちます。
Routing policy involves routing decisions about acceptance and advertisement of certain routes to or from other networks and about routing preference when more than one route becomes available. Routing policy enforces business agreements between network entities and is largely governed by non-technical criteria. In essence, routing policy involves defining criteria for route filtering and route selection.
ルーティングポリシーは、他のネットワークへの又はからの特定の経路の受け入れ及び広告約つ以上の経路が使用可能になったときに優先ルーティングに関するルーティングの決定を含みます。ルーティングポリシーは、ネットワークエンティティ間の業務契約を強制し、主に非技術的な基準によって支配されています。本質的に、ルーティングポリシーは、ルートフィルタリング及び経路選択のための基準を定義することを含みます。
One aspect of route filtering has to do with traffic control between routing domains or between different provider networks. Making policy based on individual prefixes should be avoided in this case because, with the large number of prefixes in the Internet, it does not scale. Making policy based on ASs that administratively represent a set of prefixes scales better.
経路フィルタリングの一の態様は、ルーティングドメイン間または異なるプロバイダネットワーク間のトラフィックの制御に関係しています。インターネットでのプレフィックスの数が多いと、それはスケールしない、ので、個々のプレフィックスに基づく政策決定は、この場合には避けるべきです。行政プレフィックスのセットより優れたスケールを表すのASに基づいて政策を作ります。
Another purpose of route filtering is to protect the integrity of routing information by preventing the acceptance of falsely advertised routing information that would lead traffic to 'black holes'. In this case, only prefix-based filtering will sufficiently achieve the goal. Prefix-based filtering needs to occur at the borders between a network and its direct customers or peer networks. The filtering is harder to manage at the boundary of the peer networks since a peer network usually advertises a large amount of prefixes. As mentioned earlier, there are about 70,000 routes known to the Internet. This means a large default-free network would need to filter on the order of hundred of thousands of prefixes or even more since a route could be advertised by more than one sources. The sheer amount of the prefixes to be filtered imposes challenges for router configuration memory and configuration management. To make it scale, one would need to rely on the help from an out-of-band process to sort out which prefixes should be accepted or denied from which source. IRR [11] and DNS [12] are among the current proposed mechanisms for implementing prefix-based filtering.
ルートフィルタリングのもう一つの目的は、「ブラックホール」にトラフィックを導く偽って宣伝ルーティング情報の受け入れを防止することにより、ルーティング情報の完全性を保護することです。この場合、唯一のプレフィックスベースのフィルタリングは、十分に目標を達成します。プレフィックスベースのフィルタリングは、ネットワークとその直接の顧客やピア・ネットワークの間の境界で発生する必要があります。ピア・ネットワークは、通常、プレフィックスの大量をアドバタイズするので、フィルタリングは、ピアネットワークの境界で管理することが困難です。前述したように、インターネットに知られている約70,000のルートがあります。これは、大規模なデフォルトのないネットワークはルートが複数のソースによってアドバタイズされる可能性があるのでプレフィックスまたはそれ以上の何千もの百のためにフィルタリングする必要があるだろうことを意味します。フィルタリングされるプレフィックスの膨大な量は、ルータのコンフィギュレーションメモリおよび構成管理のための課題を課します。その規模にするために、人はどのソースから受け入れまたは拒否すべきプレフィックス整理してアウトオブバンドプロセスからの援助に頼る必要があるだろう。 IRR [11]とDNS [12]プレフィックスベースのフィルタリングを実施するための現在の提案されたメカニズムの一つです。
Route selection policy determines which path should be used to send traffic toward a certain destination. This is important, for example, when a network has two connections to another network and learns routes from both connections. The decision involves which path to select to send traffic to the customers behind the other network. The choices are typically:
経路選択ポリシーは、特定の宛先に向けてトラフィックを送信するために使用されるべきパスを決定します。これは、ネットワークが別のネットワークへの2つの接続を有し、両方の接続からのルートを学習するとき、例えば、重要です。決定は、他のネットワークの背後にある顧客にトラフィックを送信するために選択したパスが含まれます。選択肢は、通常、次のとおりです。
o Directing traffic to the closest interconnection point for traffic to exit the network. This policy is also known as Hot-Potato-Routing
ネットワークを終了するトラフィックに対して最も近い相互接続点へのトラフィックを演出O。このポリシーはまた、ホットポテトルーティングとして知られています
o Directing traffic to the optimal network exit point. The optimal exit point is determined based on certain criteria by the network administrator and is not necessary the closest exit point
最適なネットワークの出口点へのトラフィックを演出O。最適な出口ポイントは、ネットワーク管理者が特定の基準に基づいて決定され、最も近い出口点必要ではありません
o Always preferring routes advertised by directly connected customers
Oは、必ず直接接続され、顧客によってアドバタイズされたルートを好みます
o Allowing other network or customer to determine the path
経路を決定するために、他のネットワークまたは顧客の許可O
When a policy is defined, its implications for scalable implementation need to be considered. For example, if the policy allows customers to determine which paths traffic follows, customers, not the provider, should be required to set routing parameters to make the routing favor their preferred path. Customers can use the BGP community or mechanisms such as MED to set routing preferences in a much more scalable way. This avoids putting such routing management burdens solely on the provider. Distributing the routing management burden makes the policy implementation more scalable.
ポリシーが定義されている場合は、スケーラブルな実装のためにその影響が考慮される必要があります。ポリシーは、顧客トラフィックが追従する経路を決定することを可能にする場合、例えば、顧客が、プロバイダは、ルーティングはそれらの好ましい経路を支持するためにルーティングパラメータを設定するために必要とされるべきではありません。顧客は、はるかにスケーラブルな方法でルーティング設定を設定するためにこのようなMEDとしてBGPコミュニティやメカニズムを使用することができます。これは単にプロバイダに、このようなルーティングの管理負担を入れて回避します。ルーティング管理の負担を分散することで政策の実施がよりスケーラブルになります。
Another scaling measure is to avoid making complex policy. When routing policy is complex, management, such as configuration of the router and debugging, would be a problem. The ultimate goal is to make the network manageable.
別のスケーリング尺度は、複雑なポリシーを避けることです。ルーティングポリシーが複雑である場合、そのようなルータやデバッグの構成と管理は、問題となるであろう。究極の目標は、ネットワークを管理できるようにすることです。
The following basic principles would help scale the routing policy management.
次の基本的な原則は、ルーティングポリシー管理のスケーリングに役立つだろう。
o Making policies as simple as possible but meet the requirements
O要件をできるだけ簡単政策を作るが、会います
o Automating as much as possible to avoid error-prone manual work
エラーが発生しやすい手作業を避けるために、可能な限り自動化するO
o Avoiding policy based on individual prefixes as much as possible with the exception of prefix-based route filtering for protecting routing integrity
ルーティング完全性を保護するためのプレフィックスベース経路フィルタリングを除いて可能な限り個々のプレフィックスに基づいてポリシーを回避O
o Avoiding making exceptions
例外を作る回避O
o Using out-of-band routing policy processing where possible
可能な場合、ポリシールーティング処理アウトオブバンド用いO
A typical router assumes both routing and forwarding functions. However, conceptually, routing and forwarding are two separate processes. A router's ultimate task is to forward packets based on its forwarding table, which is derived from routing information. One of the main causes of route scaling problems is that routers run out of processing power because routing requires too much processing. While a router has to forward packets, it does not necessarily have to exchange and process routing information or execute routing policy; these tasks can be performed elsewhere. Thus the question should be: Would it be possible to remove the routing process from a router to reduce its burden? Moving the routing process from the routers to other systems is referred to as out-of-band route processing.
典型的なルータは、ルーティングおよび転送の両方の機能を想定しています。しかし、概念的に、ルーティングおよび転送は、2つの別々のプロセスです。ルータの最終的なタスクは、ルーティング情報から導出され、その転送テーブルに基づいてパケットを転送することです。ルートスケーリングの問題の主な原因の一つは、ルーティングがあまりにも多くの処理を必要とするため、ルータは処理能力が不足していることです。ルータがパケットを転送しなければならないが、それは必ずしも交換プロセスルーティング情報またはポリシールーティングを実行する必要はありません。これらのタスクは、他の場所で行うことができます。したがって、質問は次のようになります。その負担を軽減するために、ルータからのルーティングプロセスを削除することは可能でしょうか？他のシステムへのルータからルーティングプロセスを移動するアウトオブバンド経路処理と呼ばれます。
Out-of-band route processes would, in short, perform the heavy-duty routing tasks. They would build a forwarding table for the router, select routes based on pre-defined policy, filter routes, and shield the router from route flapping attacks.
アウトオブバンドのルートプロセスは、簡単に言えば、大型のルーティングタスクを実行します。彼らは、ルータの転送テーブルを構築する事前定義されたポリシーに基づいて経路選択、フィルタルート、およびルートフラッピングの攻撃からルータを保護します。
The shortcomings of out-of-band route processing are the possible introduction of delays in routing changes; the de-coupling of routing and forwarding paths, which could introduce inaccurate routing information; and the cost of extra equipment.
アウトオブバンド経路処理の欠点は、ルーティングの変更の遅れの可能な導入です。不正確なルーティング情報を導入する可能性がルーティングおよび転送パスのデカップリング。余分な設備のコスト。
Appendix A presents a current example of out-of-band route processing. It also suggests other possible solutions.
付録Aは、アウトオブバンドのルート処理の現在の例を示します。また、他の可能な解決策を提案します。
How routing scales has a direct impact on network stability and performance. With the fast growth of the Internet and consequent expansion of providers' networks, routing scaling become increasingly an important issue to address. This document identifies the major factors that affect route scalability and establishes basic principles for designing scalable routing in large networks.
どのようにルーティングスケールは、ネットワークの安定性とパフォーマンスに直接影響を与えます。インターネットの急速な成長とプロバイダのネットワークの拡大に伴い、その結果として、ルーティングスケーリングはますます対処するための重要な課題となって。この文書は、ルートスケーラビリティに影響を与える主な要因を特定し、大規模なネットワークでスケーラブルなルーティングを設計するための基本原則を確立します。
The major routing scaling issues we are facing today are excessive router resource consumption due to routing processing burdens causing routing convergency difficulties thus introducing network instability; and routing complexity resulting in difficulties of management and trouble shooting causing degradation of service.
私たちが今日直面している主要なルーティングのスケーリングの問題が原因ので、ネットワークの不安定性を導入し、ルーティング収束の困難を引き起こして処理負担をルーティングに過大なルータの資源消費されています。およびサービスの低下を引き起こし、管理、トラブルシューティングの困難が生じ複雑さをルーティングします。
The outlined principles for designing a scalable routing system are building routing hierarchy; introducing fault isolation; reducing routing processing burden where possible; defining manageable routing policies and using the assistance of available out-of-band routing process.
スケーラブルなルーティングシステムを設計するために概説した原理は、ルーティング階層を構築しています。障害分離を導入します。可能な場合、ルーティング処理負担を軽減します。管理ルーティングポリシーを定義し、利用可能な帯域外ルーティングプロセスの支援を用いて。
The use of out-of-band resources to assist routing processing is a concept only been used in the Internet Exchange Points (IXPs). However, it could potentially be used to advantage within a network to help addressing routing scaling issues. This is a topic worthy of further exploration.
ルーティング処理を支援するために、アウトオブバンドリソースの使用が唯一のインターネットエクスチェンジポイント（のIXP）で使用されてきた概念です。しかし、潜在的にルーティングスケーリングの問題に対処するために、ネットワーク内に有利に使用することができます。これは、さらなる調査に値するトピックです。
Routing protocols and/or their implementations can still be improved or enhanced for better handling of the scaling issues. For example, the IS-IS multiple level mechanism is needed in order to scale the IGP in large network. Also, using multicast or a reliable flooding mechanism for I-BGP updates instead of pairwise full mesh peering is something worth investigating.
ルーティングプロトコルおよび/またはその実装はまだ改善やスケーリングの問題のより良いハンドリングのために向上させることができます。例えば、複数のレベルの機構は大規模ネットワークでIGPをスケーリングするために必要であるが、です。また、マルチキャストまたはI-BGPのための信頼性の高いフラッディングメカニズムを使用すると、代わりに、ペアごとのフルメッシュのピアリングの更新調査する価値のあるものです。
It is our belief that even with the deployment of new technologies such as DWDM, MPLS and others in the future, the fundamental routing scheme will remain the current IGP/BGP paradigm. Therefore, the scalable routing design principles outlined in this document should still apply with the deployment of new technologies.
それも、将来的には、このようなDWDM、MPLSおよび他のような新技術の導入で、基本的なルーティング方式は、現在のIGP / BGPのパラダイム残ることを私たちの信念です。そのため、このドキュメントで概説さスケーラブルなルーティングの設計原理はまだ新しい技術の展開に適用されるべきです。
This document deals with routing scaling issues and thus is unlikely to have a direct impact on security.
スケーリングの問題をルーティングするため、セキュリティに直接影響を与える可能性は低いとこの文書では扱っています。
However, certain routing scaling improvement mechanisms suggested in the document, such as network compartmentalization, will possibly alleviate network outages caused by denial-of-service attacks since it would help prevent such outages from spreading to the entire network.
それはネットワーク全体に広がるような障害を防ぐのを助けることになるので、このようなネットワーク区画として文書で提案されている特定のルーティングスケーリング改善メカニズムは、おそらくサービス拒否攻撃によって引き起こされるネットワーク障害を軽減します。
Although the mechanisms described in this document do not enhance or weaken the security aspect of routing protocols, it is worth indicating here that security enhancement of routing protocols or routing mechanisms may impact routing scalability. Therefore, when applying security enhancement in routing, one has to be aware of the implications on scalability.
本書で説明されたメカニズムは、ルーティングプロトコルのセキュリティ面を強化または弱体化していないが、ルーティングプロトコルやルーティングメカニズムのセキュリティ強化は、ルーティングのスケーラビリティに影響を与える可能性があることをここで示している価値があります。ルーティングのセキュリティ強化を適用する場合したがって、一つはスケーラビリティに影響を認識しなければなりません。
For example, TCP MD5 signature option is proposed to be a mechanism to protect BGP sessions from being spoofed [13]. It is done on a per-session basis and the overhead of MD-5 extensions are minimal thus has no direct impact on scalability. There have been concerns about doing per-prefix AS path verification as any one ISP along a path could have forged or modified information (maliciously or not). One extreme solution is to have a signature for each prefix which gives very strong security but presents enormous scaling issues in terms of processing, memory and administrative overhead.
例えば、TCP MD5署名オプションがスプーフィングされるのBGPセッションを保護するための機構であることが提案されている[13]。これは、セッションごとに行われ、MD-5の拡張機能のオーバーヘッドは、このように拡張性に直接的な影響を及ぼさない最小限です。パスに沿ったいずれかのISPが情報（悪意を持ったりしない）偽造または変更している可能性があるので、パスの検証ASごとのプレフィックスことについての懸念がありました。一つの極端な解決策は、非常に強力なセキュリティを提供しますが、処理、メモリおよび管理オーバーヘッドの面で多大なスケーリングの問題を提示し、各プレフィックスの署名を持っていることです。
Special thanks to Curtis Villamizar and Dave Katz for the extensive review of the document and many helpful comments. Many thanks to Yakov Rekhter, Noel Chiappa and Rob Coltun for their insightful comments. The author also like to thank Susan R. Harris for the much needed polishing of English language in the document.
ドキュメントと多くの有益なコメントの広範な見直しのためのカーティスVillamizarとデイブ・カッツに感謝します。彼らの洞察に満ちたコメントについてヤコフ・レックター、クリスマスChiappaとロブColtunに感謝します。著者はまた、文書中の英語の多くの必要な研磨のためのスーザンR.ハリスに感謝したいです。
The author was made aware after the publication of this document that there is a relevant and independent presentation made by Enke Chen on the subject. The presentation is thus referenced in [14].
著者は、被験者のエンケ陳によって作られた、関連する、独立したプレゼンテーションがあることが、本書の発行後に知らされました。プレゼンテーションは、このように[14]で参照されます。
[1] "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO DP 10589, February 1990.
[1]「中間システム中間システムドメイン内のRouteing交換プロトコルへのコネクションレスモードネットワークサービスを（ISO 8473）の提供のための議定書と併せて使用する」、ISO DP 10589、1990年2月。
[2] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195, December 1990.
[2] Callon、R.は、RFC 1195、1990年12月 "OSIの使用はTCP / IPでのルーティングおよびデュアル環境のためにIS-IS"。
[3] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[3]モイ、J.、 "OSPFバージョン2"、RFC 2328、1998年4月。
[4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[4] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[5] C. Labovitz, R. Malan, F. Jahanian, "Origins of Internet Routing Instability," in the Proceedings of INFOCOM99, New York, NY, June, 1999
INFOCOM99、ニューヨーク、NY、1999年6月の議事録では、[5] C. Labovitz、R.マラン、F. Jahanian、 "インターネットルーティングの不安定性の起源、"
[6] J. Moy, "OSPF-Anatomy of an Internet Routing Protocol", Addison-Wesley, January 1998.
[6] J.モイ、アディソン・ウェズリー、1998年1月 "インターネットルーティングプロトコルのOSPF-解剖学"。
[7] Bates, T., Chandra, R. and E. Chen, "BGP Route Reflection - An alternative to full mesh IBGP", RFC 2796, April 2000.
[7]ベイツ、T.、チャンドラ、R.とE.チェン、 "BGPルートリフレクション - フルメッシュIBGPへの代替"、RFC 2796、2000年4月。
[8] Traina, P., "Autonomous System Confederation Approach to Solving the I-BGP Scaling Problem", RFC 1965, June 1996.
[8] Trainaの、P.、 "I-BGPスケーリング問題を解決するための自律システム連合アプローチ"、RFC 1965、1996年6月。
[9] Curtis, V., Chandra, R. and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[9]カーティス、V.、チャンドラ、R.とR.ゴヴィンダン、 "BGPルートフラップダンピング"、RFC 2439、1998年11月。
[10] Fuller, V., Li, T., Yu, J. and K. Varadhan "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[10]フラー、V.、李、T.、ゆう、J.及びK. Varadhan "クラスレスドメイン間ルーティング（CIDR）：アドレス割り当ておよび集約戦略"、RFC 1519、1993年9月。
[11] Villamizar, C., Alaettinoglu, C., Govindan, R. and D. Meyer, "Routing Policy System Replication", RFC 2769, February 2000.
[11] Villamizar、C.、Alaettinoglu、C.、ゴヴィンダン、R.およびD.マイヤー、 "ルーティングポリシーシステムレプリケーション"、RFC 2769、2000年2月。
[12] Bates, T., Bush, R., Li, T. and Y. Rekhter, "DNS-based NLRI origin AS verification in BGP", Work in Progress.
[12]ベイツ、T.、ブッシュ、R.、李、T.とY. Rekhter、 "BGPでの検証AS DNSベースのNLRIの起源" が進行中で働いています。
[13] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[13] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[14] E. Chen, "Routing Scalability in Backbone Networks." Nanog Presentation: http://www.nanog.org/mtg-9901/ppt/enke/index.htm
[14] E.チェン、「バックボーンネットワークにおけるルーティングスケーラビリティ。」 Nanogのプレゼンテーション：http://www.nanog.org/mtg-9901/ppt/enke/index.htm
[15] T. Li, T. Przygienda, H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", Work in Progress.
[15] T.李、T. Przygienda、H.スミット、 "IS-IS二レベルでドメイン全体のプレフィックス配布" が進行中で働いています。
Author's Address
著者のアドレス
Jieyun (Jessica) Yu CoSine Communications 1200 Bridge Parkway Redwood City, CA 94065
Jieyun（ジェシカ）ゆうコサインコミュニケーションズ1200ブリッジパークウェイレッドウッドシティ、CA 94065
EMail: jyy@cosinecom.com
メールアドレス：jyy@cosinecom.com
Appendix A. Out-of-Band Routing Processes
付録A.アウトオブバンドルーティングプロセス
The use of a Route Server(RS) at NAPs is an example of achieving routing scalability through an out-of-band routing process. A NAP is a public inter-connection point where ISP networks exchange traffic. ISP routers at a NAP establish BGP peer sessions with each other. The result is full mesh E-BGP peering with a complexity of O(N^2) system wide. When the RS is in place, each router peers only with the RS (and its backup) to obtain necessary routing information (or more precisely, the necessary forwarding information). In addition, the RS also filters routes and executes policy for each provider's router, which further reduces the burden on all routers involved.
NAPのにルートサーバ（RS）の使用は、アウトオブバンドルーティングプロセスを経由スケーラビリティを実現する例です。 NAPはISPのネットワーク交換トラフィックパブリック相互接続点です。 NAPのISPのルータが相互にBGPピアセッションを確立します。結果はO（N ^ 2）システム全体の複雑さとピアリングフルメッシュE-BGPです。 RSが所定の位置にあるときにのみRS（およびそのバックアップ）を有する各ルータピアが必要なルーティング情報（または、より正確に、必要な転送情報）を取得します。また、RSはまた、ルートをフィルタリングし、さらに関連するすべてのルータの負担を軽減各プロバイダのルータのための政策を実行します。
The concept of the Route Server can also be used to help address routing scalability in a large network.
ルートサーバの概念はまた、大規模なネットワークにアドレスルーティングのスケーラビリティを支援するために使用することができます。
1) RS Assisted Peering between Customer Aggregation Router and Customer Routers
1）RSは、お客様の集約ルータと顧客ルータ間のピアリング支援します
Currently, in a typical large provider network, it's not unusual that a customer aggregation router connects up to hundreds of customer routers. That means the router has to handle hundreds of E-BGP sessions and filter a large number of prefixes. These tasks impose a heavy burden on the aggregation router. Reducing the number of customer routers per aggregation router is not an optimal option, since this would introduce more routers in the routing system of the whole network, which is neither scalable for backbone routing, nor cost efficient. Using an RS between customers and the providers' customer aggregation router become an attractive option to reduce the burden on the router.
現在、典型的な大規模なプロバイダーのネットワークでは、顧客の集約ルータは、顧客のルータの数百まで接続されていることは珍しいことではありません。これは、ルータはE-BGPセッションの数百を処理し、プレフィックスの多数をフィルタするために有することを意味します。これらのタスクは、集約ルータに重い負担を課します。これは、バックボーンルーティングのためのスケーラブルな、またコスト効率的でもない、ネットワーク全体のルーティングシステムに複数のルータを導入するため、集約ルータあたりの顧客ルータの数を減らすことは、最適なオプションではありません。顧客やプロバイダの顧客集約ルータ間のRSを使用すると、ルータの負担を軽減するための魅力的な選択肢となります。
Figure 1 shows one way of incorporating an RS router between a provider's customer aggregation router and customer routers.
図1は、プロバイダの顧客集約ルータと顧客ルータ間のRSルータを組み込む1つの方法を示しています。
--------------------------- LAN Media in a POP
| |
----- -----
|CR | |RS |
----- -----
/ | \
/ | \
C1 C2..Cn
Figure 1: RS serving customer aggregation router connecting customer routers
図1：顧客のルータを接続する顧客の集約ルータにサービスを提供するRS
In a scenario without an RS, the customer aggregation router(CR) has to peer with customer routers C1, C2 ... Cn (where n could be in the hundreds). When an RS router is introduced, CR, C1, C2 ... Cn peer with the RS router instead, and the RS passes the processed routing information (or forwarding information) to all of them, according to policy and filters.
RSなしのシナリオでは、顧客集約ルータ（CR）は顧客ルータ（nは数百であってもよい）C1、C2 ... CNとのピアに有しています。 RSルータが導入されたときに、CR、C1、C2···Cnが代わりにRSルータとピア、及びRSは、ポリシーおよびフィルタによれば、それらの全てに（または転送情報）処理ルーティング情報を渡します。
The advantages are obvious:
利点は明白です：
o The customer aggregation router peers only with the RS router instead of with hundreds of customer routers.
唯一のRSルータとの代わりに、顧客のルータの何百もの顧客の集約ルータピアO。
o The customer aggregation router does not need to filter prefixes or process routing policies, which frees resources for packet forwarding and handling.
O顧客の集約ルータは、接頭辞やパケット転送と処理のためのリソースを解放し、プロセスのルーティングポリシーを、フィルタリングする必要はありません。
One general concern with the use of an RS router is the possibility of a mismatch of routing connectivity and the physical connectivity. For example, if the link between the CR and C1 is down and if the RS router is not aware of the outage, it will continue to pass routes from C1 to the CR, and the traffic following these routes will be black holed. However, this is not a problem in the specific application described here. This is because the RS router has to go through the CR to peer with C1, C2 ... Cn. When the link is down, C1 is inaccessible from the RS router, and no routing information can be exchanged between the two. Consequently, the RS will announce no routes related to C1.
RSルータを使用した一般的な一個の懸念は、ルーティング接続と物理的な接続の不一致の可能性があります。例えば、CR及びC1との間のリンクがダウンしているとRSルータが障害を認識しない場合、それはC1からCRへの経路を通過していき、これらの経路次のトラフィックは、穴あき黒になる場合。しかし、これは、ここに記載された特定の用途では問題ではありません。 RSルータはC1、C2 ... CNとのピアにCRを通過しなければならないためです。リンクがダウンしている場合、C1はRSルータからアクセス不能であり、何らのルーティング情報は、2つの間で交換することができません。その結果、RSはC1に関連したルートをアナウンスしません。
Another concern is the creation of single point of failure. If the RS router is down, no routing information can be exchanged between the customer aggregation router and C1, C2 ... Cn, and no traffic will flow between them. This problem could be addressed by adding a second RS router as a backup.
もう一つの懸念は、単一障害点の作成です。 RSルータがダウンした場合、ルーティング情報は、顧客集約ルータとC1、C2 ... Cnの間で交換することはできない、とトラフィックは、それらの間に流れません。この問題は、バックアップとして二RSルータを追加することによって対処することができます。
In this scenario, since RS peers with C1 ... Cn via CR, it requires that when the RS router passes routing information to C1...Cn, it designates the IP address of the CR as the next hop. Likewise, when the RS router passes routes from each customer router to the customer aggregation router, it needs to place the correct next hop on the route. Modifications need to be made to the RS code to include this function.
このシナリオでは、CRを介してC1 ... CNとRSピアので、RSルータはC1 ... CNにルーティング情報を通過するとき、それは次のホップとしてCRのIPアドレスを指定することを必要とします。同様に、時にRSルータは、ルート上に正しいネクストホップを配置する必要があり、顧客の集約ルータに各顧客のルータからのルートを渡します。変更は、この機能が含まれるようにRSコードになされる必要があります。
2) Private RS Router at InterExchange Point
エクスチェンジポイントで2）プライベートRSルータ
A large provider network often has many BGP peers at the Interexchange Point, NAP or private interconnection. This means a border router has to handle many E-BGP sessions. Since an
大規模なプロバイダ・ネットワークは、多くの場合、エクスチェンジポイント、NAPまたはプライベート相互接続で多くのBGPピアを持っています。これは、境界ルータは、多くのE-BGPセッションを処理しなければならないことを意味します。から
Interconnect points is usually the administrative boundary between ISPs, policy and route filtering are very demanding. This imposes a scaling problem on the border router.
インターコネクトポイントが通常のISP間の管理境界で、ポリシーとルートフィルタリングは非常に厳しいです。これは、境界ルータ上のスケーリングの問題を課します。
Deploying many routers to distribute the load among them is an expensive solution: extra hardware and extra ports cost money. Shifting the routing burden to an RS router is a promising alternative solution. In the case of using RS for multiple peers at a private interexchange point, the scenario is similar to RS used between customer aggregation router and customer routers as described in 1) above. In the case of such peering at a NAP, the private RS could be placed either on the same NAP media or a private media between the ISP's NAP router and the RS.
それらの間で負荷を分散するために多くのルータを展開すると、高価なソリューションです：余分なハードウェアや余分なポートにはお金がかかります。 RSルータにルーティング負担をシフトすることは有望な代替ソリューションです。上記1）に記載のように、プライベートエクスチェンジポイントで複数のピアのためにRSを用いた場合、シナリオは、顧客集約ルータと顧客ルータの間で使用されるRSと同様です。このようNAPでピアリングの場合は、プライベートRSは、同じNAPメディアまたはISPのNAPルータとRS間のプライベートメディアに配置することができます。
3) RS Routers at Each POP in a Large Network
3）大規模ネットワーク内の各POPでルータをRS
Even in a network with a hierarchical routing structure, a sub-area may become too large, and I-BGP full meshing may impose a scaling problem. One way to address this would be to split the sub-area or add yet another tier of I-BGP reflector structure. Another possible solution would be to use an RS router as an I-BGP Server. Depending on the topology of a POP, this solution may or may not be suitable. The use of RS routers at network POPs need to be investigated further.
でも、階層型ルーティング構造のネットワークでは、サブエリアが大きくなりすぎて、およびI-BGPのフルメッシュ生成は、スケーリングの問題を課すことができます。これに対処する1つの方法は、サブエリアを分割したり、I-BGPリフレクタ構造のさらに別の層を追加することです。別の可能な解決策は、I-BGPサーバとしてRSルータを使用することです。 POPのトポロジに応じて、このソリューションは、または適切なであってもなくてもよいです。ネットワークのPOPsのRSルータを使用することは、さらに調査する必要があります。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。