[要約] RFC 2791は、スケーラブルなルーティング設計の原則についての要約です。その目的は、大規模なネットワーク環境で効果的なルーティングを実現するための指針を提供することです。
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.
Copyright（c）The Internet Society（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 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.
このドキュメントの構成は次のとおりです。セクション2では、ルーティング関数と設計目標について説明します。セクション3および4は、今日の大規模なネットワークの特性と関連するルーティングスケーリングの問題について説明します。セクション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冗長性と堅牢性o合理的な収束時間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 それらはデフォルトフリーです。つまり、彼らはインターネット全体に知られているすべてのルートを運びます。現在、総数は約70,000です。
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]を、それぞれ外部ルーティングプロトコル（EGP）としてインテリアルーティングプロトコル（IGP）およびBGP [4]として採用しています。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 複数のパスと組み合わされたルートが多すぎるには、保管のためにルーターに大量のメモリが必要です。NAPSなどの交換ポイントでは、需要はさらに高くなっています。
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更新が昼寝の典型的なデフォルトのないルーターで発生する可能性があります。
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を最大5秒に1回更新できることを指定します。これは本質的に羽ばたきを減衰させます。
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ルーターをできるだけ接続します。その結果、顧客集約ルーターが何百ものE-BGPセッションを処理することは珍しくありません。これは、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.
ルーティング管理の複雑さに寄与するもう1つの要因は、プレフィックスベースのルートフィルタリングです。よく知られているように、ルーティングシステムの完全性を保護するためには、プレフィックスベースのフィルタリングが必要です。これは、インターネットに知られているルートの数が今日のように大きい場合の課題になります。
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（別名IGP）および外部ルーティングのBGP（別名EGP）です。スケーリングやその他の側面に関しては、これらのプロトコルは、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（IS-ISの場合はLSP）でローカルルーティングトポロジを説明する責任があります。個別に生成された各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アップデートを受信するとき、ルーターは情報を検証し、ローカルLSDBを更新してから、元のLSAアップデートを受け取ったインターフェイスを除き、すべてのインターフェイスを除いて送信します。IS-ISまたはOSPFの洪水の性質を考えると、Nルーターを備えたフルメッシュネットワークは、単一のリンク障害が発生したときにネットワークに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）アルゴリズムを使用します。Dijkstraアルゴリズムは、O（n^2）の順序までスケーリングします。ここで、nはノードの数です。アルゴリズムはO（L*logn）の順序まで改善できます。ここで、Lはネットワーク内のリンクの数、Nは目的地またはルーターの数です[6]。
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.
ノードの隣接は、各ノードから定期的に送信されるハローメッセージの交換を通じて発見および維持されます。ノードが特定の期間内に隣人からハローメッセージを受信できない場合（OSPFで40秒、IS-ISでは少ない）、隣人をダウンします。ルーターCPUを希少なリソースにする重度の洪水、再計算、およびその他のアクティビティが発生した場合、ルーターは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.
また、リンク状態のIGPSは、今日インターネットに知られている70,000ルートなど、多数のルートを運ぶために十分にスケーリングしません。外部ルートはLink-State-DatabaseおよびLSA（IS-ISのLSP）の更新に含まれているため、リンク帯域幅とルーターメモリの消費は途方もないものになります。さらに、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
o BGPセッションの確立、ルート選択、ルーティング情報処理、ルーティングの更新の処理における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.
BGPに関連する主要なスケーリングの問題は、完全なメッシュI-BGP接続にあります。前のセクションで述べたように、IGPが外部から学習した接頭辞を運ぶために拡張しないため、I-BGPはこの義務を引き受けます。ルーティングループを防ぐために、I-BGPを介して学習したプレフィックスは、別のI-BGPスピーカーに宣伝されることを禁止されています。その結果、AS内のルーター間のI-BGPセッションの完全なメッシュが必要です。nルーターのASでは、各ルーターは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]およびBGPコンフェデレーション[8]を介した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.
もう1つの潜在的な解決策は、完全なメッシュペアワイズ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]は、ルートフラップによってトリガーされる過剰な更新を減らす1つの方法です。セクション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適切なトレードオフの作成oルート処理負荷の削減
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とIS-ISは、ネットワークに多数のルーター、特に大量の隣接を持っている場合、縮小が不十分です。残念ながら、これは、ルーター間の完全なメッシュの隣接を備えた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.
この設計では、Transit Core Networkと各地域ネットワークをルーティングに関して完全に独立したASSとして扱い、それぞれが独立した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.
この設計のもう1つの利点は、そのようなコンポーネントの不安定性がシステム全体に影響を与えないようにルーティングシステムを区分化することです。セクション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を介してインターネットに宣伝されているときに、ルーティングパスのように1つの追加を挿入することです。パスのようにこれは、他のプロバイダーにルート選択の難しさを引き起こす可能性があります。
2) One Domain with IGP and BGP Hierarchy
2) IGPおよびBGP階層を持つ1つのドメイン
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.
この方法には、トランジットコアと各地域ネットワークがドメインとして1つに含まれます。ルーティング階層は、マルチレベルの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）で説明されている方法よりも利点です。ただし、マルチエリアの階層IGPは、大規模なネットワークでは現在使用されることはめったにありません。これらのほとんどは、十分なマルチレベルのサポートを持たない内部ルーティングにISを使用しているためです。IS-ISはマルチエリアルーティングをサポートしていますが、バックボーンとサブエリアの間に厳格な階層を課し、バックボーンエリアからサブエリアへのデフォルトルートの広告のみを特定のプレフィックスの代わりに許可します。この制限は、単純なサブエリアトポロジを持つネットワークに適している場合があります。大規模なネットワーク（通常は地域またはアクセスネットワーク）のサブエリア自体には、複雑なトポロジがあります。デフォルトのルートなど、非常に抽象的なルーティング情報を受信すると、トラフィックエンジニアリングに必要なルート選択を行うサブエリアの能力に影響します。また、IGP由来のBGPマルチエキシトディスクリミネーター（MED）情報など、外部ASSに渡された情報も制限されます。
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
3) BGP階層を備えた1つの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.
1つのIGPドメインを使用しても、BGP階層を構築して、ネットワークでI-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リフレクターは、ルーティングループの作成の可能性を回避するために、さまざまなレベルの階層間の相互作用が慎重に配置されている限り、3つ以上のレベルの階層を構築する能力を提供します。
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つのレベルですか？」「3つ以上のレベルの階層が本当に必要ですか？」
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番目のサブドメインが、ルーティングプロトコルが処理するには大きすぎる場合、階層の別の層を導入する必要があるか、サブドメインを複数のセカンドに分割する必要があります。階層型サブドメイン。
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つのレベルの階層を維持し、サブドメインを追加することは、階層に別のレベルを追加するよりも管理しやすいように見えます。ただし、1つの懸念は、トップレベルまたはトランジットコアネットワークにノードを追加して、スケーラブルを低下させることです。スプリットサブエリアを同じコアルーターに接続すると、コア領域にノードを追加する必要がないことが排除されます。
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.
3つ以上のレベルの階層を持つことは、現在定義されているIGPの能力を超えています。たとえば、OSPFでは、すべての領域をバックボーン領域を介して接続する必要があります。これにより、2つ以上のレベルの階層がある可能性がなくなります。IS-ISには同じ制限があります。したがって、IGPの2つ以上の階層層が望ましい場合、プロトコルを再定義する必要があります。
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.
ルーティングポリシーを実行し、ルートフィルタリングを実行するルーターと減衰は、ルーティングインテリジェンスを所有すると言われています。ルーティングインテリジェンスは、ルーティングポリシーの形でネットワークエンティティ間のビジネス契約を実施するために必要です。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.
通常、トラフィックはネットワークのコアに大きく集中しています。トラフィックはネットワークの端からコアに向かって集約するため、ネットワークの端近くにトラフィックがあまり集中しません。その結果、スケーラブルなルーティングシステムを構築するには、特に十分に転送とルーティングを切り離さないルーターで展開されたネットワークで、ネットワークの端にルーティングインテリジェンスを配置することが賢明です。さらに、ネットワークのエッジに近いルーティングインテリガンシーを可能な限りプッシュすることは、すべてのルーターに計算および構成の負担を分散する目的にも役立ちます。
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で説明したように、システム内の多数のルートは、ルートスケーリングの問題の主要な犯人の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.
[10]で指定されているCIDRは、IPアドレススペースを効率的に利用し、グローバルルーティングテーブルのルート数を減らすためのルートを集約するメカニズムを提供します。CIDRは、ルーティング情報を要約する方法を提供します。これは、今日のインターネットでスケーラビリティをルーティングするためのキーの1つです。
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ルーターなど）では、1つの主要なパスと代替パスが合理的な冗長性を提供する必要があります。この場合、スケーリングのために3番目または4番目の代替ルートを破棄できます。これは、すべてのネットワーク管理者がネットワークの特定のニーズに基づいて行う必要があるトレードオフ決定です。
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?
前述のように、大規模なネットワークでのスケーリングの問題の1つは、単一のルーターが何百もの顧客ルーターにファンアウトする可能性があることです。その結果、すべての顧客ルーターがBGPを介してEdgeルーターと通信する場合、リソース消費は非常に集中します。エッジルーターが添付されたすべての顧客ルーターを使用して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.
一見すると、異なる自律システムの顧客ネットワークが（AS）BGPを介してプロバイダーネットワークとルーティング情報を交換する必要があるようです。ただし、これは必ずしもそうではありません。顧客ネットワークが単一宿泊施設である場合（つまり、顧客の唯一のネットワーク接続がプロバイダーネットワークを介している場合）、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 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セッションの不安定性が原因で、インターネット全体で過度のルーティングの更新が生じます。ルートフラップは、グローバルインターネットのどこにでも発生し、インターネットルーティングメッシュ（BGPメッシュ）のすべてのネットワークに影響を与えます。インターネットに知られている70,000を超えるルートがあり、ルートの羽ばたきにはほとんど分離されていないため、ルートのフラッピングは、どのネットワーク内のルーターに圧倒される可能性があります。
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.
[10]で指定されているように、ルート羽ばたきの影響を減らす1つの方法は、ルートの減衰をオンにすることです。基本的に、減衰は安定するまで不安定なルートを抑制します。現在のプラクティスは、各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.
ルートフィルタリングの1つの側面は、ルーティングドメイン間または異なるプロバイダーネットワーク間のトラフィック制御に関係しています。この場合、個々の接頭辞に基づいてポリシーを作成する必要があります。これは、インターネット内の多数の接頭辞があるため、拡張しないためです。プレフィックスのスケールのセットを管理的に表すASSに基づいてポリシーを作成します。
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.
ルートフィルタリングのもう1つの目的は、トラフィックを「ブラックホール」に導く誤って宣伝されたルーティング情報の受け入れを防ぐことにより、ルーティング情報の整合性を保護することです。この場合、プレフィックスベースのフィルタリングのみが目標を十分に達成します。プレフィックスベースのフィルタリングは、ネットワークとその直接的な顧客またはピアネットワークの間の境界で発生する必要があります。ピアネットワークは通常、大量のプレフィックスを宣伝するため、フィルタリングはピアネットワークの境界で管理が困難です。前述のように、インターネットには約70,000のルートが知られています。これは、ルートを複数のソースで宣伝できるため、数十万の接頭辞の順序で大規模なデフォルトのないネットワークをフィルタリングする必要があることを意味します。フィルタリングされるプレフィックスの量は、ルーター構成メモリと構成管理に課題を課します。それをスケーリングするには、どのプレフィックスを受け入れるか、どのソースから拒否する必要があるかを整理するために、バンド外のプロセスの助けに頼る必要があります。IRR [11]およびDNS [12]は、プレフィックスベースのフィルタリングを実装するための現在提案されているメカニズムの1つです。
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.
ポリシーが定義されている場合、スケーラブルな実装に対するその意味を考慮する必要があります。たとえば、ポリシーが顧客がどのパストラフィックが続くかを判断できる場合、プロバイダーではなく顧客がルーティングパラメーターを設定してルーティングを優先することを好むようにする必要がある必要があります。顧客は、BGPコミュニティまたはMEDなどのメカニズムを使用して、ルーティングの好みをはるかにスケーラブルな方法で設定できます。これにより、このようなルーティング管理負担をプロバイダーにのみ配置することができません。ルーティング管理の負担を配布すると、ポリシーの実装がよりスケーラブルになります。
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つの個別のプロセスです。ルーターの究極のタスクは、ルーティング情報から派生した転送テーブルに基づいて転送パケットを転送することです。ルートスケーリングの問題の主な原因の1つは、ルーティングには処理が必要であるため、ルーターが処理能力を使い果たすことです。ルーターはパケットを転送する必要がありますが、ルーティング情報を交換および処理したり、ルーティングポリシーを実行したりする必要はありません。これらのタスクは他の場所で実行できます。したがって、問題は次のとおりです。ルーターからルーティングプロセスを削除して負担を軽減することは可能ですか？ルーターからルーターから他のシステムにルーティングプロセスを移動すると、バンド外のルート処理と呼ばれます。
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を大規模ネットワークでスケーリングするためには、IS-I-IS複数のレベルメカニズムが必要です。また、ペアワイズフルメッシュピアリングの代わりに、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のいずれかが情報を偽造または変更した可能性があるため、パス検証としてPER-PREFIXを実行することについて懸念がありました（悪意があるかどうか）。極端な解決策の1つは、各プレフィックスに非常に強力なセキュリティを提供するが、処理、メモリ、および管理オーバーヘッドの点で大きなスケーリングの問題を提示する署名を持つことです。
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.
文書の広範なレビューと多くの有用なコメントをしてくれたCurtis VillamizarとDave Katzに感謝します。Yakov Rekhter、Noel Chiappa、Rob 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] 「Connectionless-Mode Network Service（ISO 8473）を提供するためのプロトコルと併せて使用するための交換プロトコルを中間システムから中間システム（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。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[3] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[3] Moy、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. Li、「ボーダーゲートウェイプロトコル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
[5] C. Labovitz、R。Malan、F。Jahanian、「インターネットルーティングの不安定性の起源」、InfoCom99、ニューヨーク、ニューヨーク、1999年6月
[6] J. Moy, "OSPF-Anatomy of an Internet Routing Protocol", Addison-Wesley, January 1998.
[6] J. Moy、「インターネットルーティングプロトコルのOSPF解剖学」、Addison-Wesley、1998年1月。
[7] Bates, T., Chandra, R. and E. Chen, "BGP Route Reflection - An alternative to full mesh IBGP", RFC 2796, April 2000.
[7] Bates、T.、Chandra、R。、およびE. Chen、「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] Curtis、V.、Chandra、R。and R. Govindan、「BGP Route Flap Damping」、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] Fuller、V.、Li、T.、Yu、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.、Govindan、R。、およびD. Meyer、「ルーティングポリシーシステムの複製」、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] Bates、T.、Bush、R.、Li、T。およびY. Rekhter、「BGPの検証としての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. Chen、「バックボーンネットワークのスケーラビリティをルーティング。」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. Li、T。Przygienda、H。Smit、「2レベルのIS-ISを備えたドメイン全体のプレフィックス分布」、進行中の作業。
Author's Address
著者の連絡先
Jieyun (Jessica) Yu CoSine Communications 1200 Bridge Parkway Redwood City, CA 94065
Jieyun（Jessica）Yu Cosine Communications 1200 Bridge Parkway Redwood City、CA 94065
EMail: jyy@cosinecom.com
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.
NAPSでのルートサーバー（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）は、顧客ルーターC1、C2 ... CN（Nが数百）である可能性があります。RSルーターが導入されると、CR、C1、C2 ...代わりにRSルーターを使用してCNピアを使用し、RSはポリシーとフィルターに従って、処理されたルーティング情報（または転送情報）をそれらすべてに渡します。
The advantages are obvious:
利点は明らかです：
o The customer aggregation router peers only with the RS router instead of with hundreds of customer routers.
o 顧客集約ルーターは、数百の顧客ルーターではなく、RSルーターとのみピアをします。
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ルーターの使用に関する一般的な懸念の1つは、ルーティング接続の不一致と物理的な接続の可能性です。たとえば、CRとC1の間のリンクがダウンし、RSルーターが停止を認識していない場合、C1からCRへのルートを通過し続け、これらのルートに続くトラフィックはブラックホールになります。ただし、これはここで説明する特定のアプリケーションでは問題ではありません。これは、RSルーターがCRを通過してC1、C2 ... CNを使用してピアを行う必要があるためです。リンクがダウンすると、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の間でルーティング情報を交換することはできません。この問題は、バックアップとして2番目の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) Interexchangeポイントでのプライベート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 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.
大規模なプロバイダーネットワークには、多くの場合、交換ポイント、昼寝、またはプライベート相互接続で多くのBGPピアがあります。これは、ボーダールーターが多くのE-BGPセッションを処理する必要があることを意味します。相互接続ポイントは通常、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ルーターにシフトすることは、有望な代替ソリューションです。プライベート交換ポイントで複数のピアにRSを使用する場合、シナリオは、上記で説明されているように、顧客集約ルーターと顧客ルーターの間で使用されるRSに似ています。昼寝を覗く場合、プライベートRSは、ISPの昼寝ルーターとRSの間の同じNAPメディアまたはプライベートメディアのいずれかに配置できます。
3) RS Routers at Each POP in a Large Network
3) 大規模なネットワーク内の各ポップの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リフレクター構造のさらに別の層を追加することです。別の可能な解決策は、RSルーターをI-BGPサーバーとして使用することです。ポップのトポロジーに応じて、このソリューションが適切である場合と適切でない場合があります。ネットワークポップでのRSルーターの使用をさらに調査する必要があります。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。