RFC2791 日本語訳
2791 Scalable Routing Design Principles. J. Yu. July 2000. (Format: TXT=63416 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Yu Request for Comments: 2791 CoSine Communications Category: Informational July 2000
コメントを求めるワーキンググループJ.ユーの要求をネットワークでつないでください: 2791年のコサインコミュニケーションカテゴリ: 情報の2000年7月
Scalable Routing Design Principles
スケーラブルなルート設定設計原理
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
ルート設定はネットワークに不可欠です。 ルート設定スケーラビリティは大きいネットワークに不可欠です。 ルーティングが比例しないとき、ネットワークの安定性と性能には直接的な衝撃があります。 したがって、ルーティングスケーラビリティは特に大きいネットワークのための切迫した課題です。 このドキュメントは大きいネットワークのためにスケーラブルなルーティングを設計する基本原理と同様にルーティングスケーラビリティに影響する重要な要因を特定します。
Yu Informational [Page 1] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[1ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
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
1つの序論… 2 2の一般的なルート設定デザイン目標… 今日の大きいネットワークの3 3の特性… 3 4ルート設定スケーリング冊… 3 4.1 ルータリソース消費… 4 4.2 ルート設定の複雑さ… 5 5ルーティング・プロトコルスケーラビリティ… そして、6、5.1、-、OSPF… 6 5.2BGP… 8 6のスケーラブルなルート設定設計原理… 9 6.1ビル階層構造… 10 6.2区画化… 13 6.3 適切なトレードオフをします… 13 6.4 経路情報の過程の負担を減少させてください… 14 6.4 .1ルート設定知性プレースメント… 14 6.4 .2 ルートと経路情報を減らしてください… 15 6.4 .2 .1 CIDRとルート集合… 15 6.4 .2 .2 それがPossibleであるところでDefaultルート設定を利用してください… 15 6.4 .2 .3 迂回経路を減少させてください… 16 6.4 .3 縁でスタティックルートを使用してください… 16 6.4 .4 ルートのばたつくことの衝撃を最小にしてください… 16 方針とスケーラブルな実現17 6.6にバンドの外に掘られるスケーラブルな6.5は処理されます… 19 7の結論と議論… 19 8 セキュリティ問題… 20 9承認… 21 10の参照箇所… 21作者のアドレス… 22 付録のAバンドで出ているルート設定は処理されます… 23 完全な著作権宣言文… 26
1. Introduction
1. 序論
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背骨ネットワークなどの大きいネットワークのためにルーティングを設計する挑戦は単に働かせるのではなく、比例もさせることです。 スケーラブルなルーティングシステムがなければ、ネットワークは厳しいパフォーマンスに不利な条件が欠点であるかもしれません、残念ながら、大きいネットワークの悲惨な事件によって立証されるように。 このドキュメントは、大きいネットワークのスケーラブルなルーティングシステムを設計するためにルーティングスケーラビリティ問題を分析して、1セットの本質を定義するのを試みます。
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は論じます。
Yu Informational [Page 2] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[2ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
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は結論をドキュメントに供給します。
2. Common Routing Design Goals
2. 一般的なルート設定デザイン目標
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 Redundancy、丈夫さo Reasonable収束時間oルート設定情報保全o Sensible、および処理しやすいルーティング方針
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.
大きいネットワークにおける、設計のルーティングの挑戦は単にこれらの基本的な目標を達成するのではなく、ルーティングシステムスケールを作りもすることです。
3. Characteristics of Today's Large Networks
3. 今日の大きいネットワークの特性
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 彼らには、冗長と丈夫さ必要条件を満たす豊かな接続性があります、そして、その結果、それらには、複雑なtopologiesがあります。
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.
これらの特性はネットワークのルーティングスケーラビリティへのダイレクト挑戦を課します。
4. Routing Scaling Issues
4. ルート設定スケーリング問題
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)が複雑さを発送して、低く生産して、品質を修理してください。
Yu Informational [Page 3] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[3ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
4.1. Router Resource Consumption
4.1. ルータリソース消費
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.
ルーティングの過程は特に不安定なネットワーク条件のもとでbursty荷重をルータに置きます。 極端な場合には、ルーティングの過程がルータからすべての利用可能資源を取って、遅いルーティングによるどの結果が、集合にもかかわらず、集合でないか。 内部のルーティング情報を一点に集めることができないとき、ネットワークは麻痺しています。
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.
今日大きいネットワークが通常使う、-、[1、Interiorルート設定プロトコルとしての2か]OSPF[3](IGP)、およびExteriorルート設定プロトコルとしてのBGP[4](EGP)、それぞれ。 IGPはネットワークの内部の向こう側に経路について計算します。 BGPは経路ドメインの間のルーティング交換、またはAutonomous Systemsを容易にします(AS)。 また、BGPはネットワークの中で外部のルーティング情報を処理して、伝播します。 不安定性をリンクするのにおいて当然の頻繁なトポロジー変化に結びつけられたネットワークにおける、多くのルータと隣接番組の存在は内部のルーティングで過度のリソース消費に貢献するでしょう。 外のルーティングの場合では、BGPシステムと頻繁なルーティングアップデート(ルートのばたつく)における多量のルータが重い負担をルータに置くでしょう。 セクション5が、問題をスケーリングすると説明する、-、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などのInterExchange Pointsでさらに高いです。
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の典型的な無デフォルトのルータに起こることができます。
Yu Informational [Page 4] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[4ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
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、(-、)、ルータでの負担を減少させるためにレート限界をそのような活動に課します。 例えば、OSPFは、高々5秒に一度個々のSLAをアップデートできると指定します。 これはばたつくことを本質的には湿らせます。
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セッション処理や、維持や、ルート処理や、フィルタリングやルート格納などのように。
4.2. Routing Complexity
4.2. ルート設定の複雑さ
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
ルート設定Policyは一般的にルーティング経路選択とルートフィルタリングの形で取り扱いルーティング情報の管理評価基準について言及します。 ルーティング情報が扱われる方法はネットワーク以内とドメインの向こう側に交通の流れに直接的な衝撃を持っています。 as
Yu Informational [Page 5] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[5ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
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.
ルーティングの複雑さを減少させるキーは系統的で一貫したルーティング計画であり、aは簡単ですが、満たされる方針を管理の要件が取り締まる発送することです。
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.
ルーティング管理の複雑さに貢献する別の要素は接頭語ベースのルートフィルタリングです。 周知のとおり、接頭語ベースのフィルタリングが、ルーティングシステムの保全を保護するのに必要です。 インターネットに知られているルートの数が今日と同じくらい大きいときに、これは挑戦になります。
5. Routing Protocol Scalability
5. ルーティング・プロトコルスケーラビリティ
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.
または、今日の一般的に配備されたルーティング・プロトコルがそうである、-、InteriorルーティングのためのOSPF(通称IGP)と外のルーティングのためのBGP(通称EGP)。 スケーリングと他の局面に関して、これらのプロトコルはプロトコルの前の世代の間、既に改良です、RIPやEGPのように。 しかしながら、ネットワークが大きいときに、それでも、スケーラビリティは主要な問題です、ルーティングデザインがスケーリング問題に神経が鈍いか、またはプロトコル実現が効率が悪いときに。
5.1. IS-IS and OSPF
5.1. -、OSPF
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.
そして、 より早くドキュメントで説明されるように-、OSPFはLink州ルーティング・プロトコルです。 リンク州のルーティング・プロトコルの基本的な成分は、与えられたルーティング領域のルーティングトポロジーについて説明するLink州のDataBase(LSDB)のi)世代と維持です。 そして、ii)ルート計算はデータベースの情報をトポロジーに基礎づけました。 ルーティング領域のそれぞれのノードがLink州AdvertisementかLSAで地方のルーティングトポロジーについて説明するのに原因となる、(場合におけるLSP、-、)。 それぞれの個別に発生しているLSAはその領域のすべてのルータへ分配されるか、またはあふれるでしょう。 各ルータは他のすべてのルータからLSAsを受けます、全体のルーティング領域のルーティングトポロジーを反映するリンク州データベースを形成して。
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のサイズです。
Yu Informational [Page 6] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[6ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
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アップデートを受けたものを除いて。 または、自然を与える、-、OSPF氾濫、Nルータがある完全な網目状ネットワークには、ただ一つのリンクの故障が起こると、ネットワークで水につかっているLSAsの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.
プロトコルは、30分毎にどれが既に非常にロードされたルータのためにOSPFの場合で問題を増加させることができたかがリフレッシュするか、または安定したネットワーク条件さえのもとであふれさせるでしょう。
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.
上の議論から、人は、より多くのルータとLink州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].
リンク州のプロトコルはルート計算にダイクストラのShortest Path First(SPF)アルゴリズムを通常使用します。 ダイクストラアルゴリズムはO(N^2)の注文に比例します。(そこでは、Nがノードの数です)。 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.
その結果、リンク州のルーティング・プロトコルは領域で多くのルータと過度の隣接番組でネットワーク形態に比例しません。 ネットワーク形態が不安定であるときに、計算、処理、および帯域幅コストは拡大されて、どの原因がルータリソースの過剰消費であるか。 不安定性が防ぐいつ、-、または、隣接番組であり、ネットワークルーティング炉心溶解が起こると主張するのからの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メッセージを受け取らない、(OSPFと以下のための40秒、-、)、それは、隣人がダウンすると考えます。 不十分なリソース、ルータが発信するCPU時間を割り当てることができないかもしれないルータCPUか過程HELLOをパケットにする重い氾濫、再計算、および他の活動が起こると。 そして、ネットワークにおけるルータは隣接番組を失います。(それは、不安定性を拡大します)。 その結果、孤立している不安定性は全体のネットワークの向こう側にルーティング失敗に徐々に拡大することができます。
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
リンク州のIGPsも、今日インターネットに知られている7万のルートなどの多くのルートを運ぶためによく比例しません。 外部経路がリンク州のデータベースとLSAに含まれているので
Yu Informational [Page 7] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[7ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
(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.
(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によって運ばれた大きい外部経路、 より重要(その領域の過度の隣接番組)
5.2. BGP
5.2. BGP
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は異なったAutonomous体系網の間のルーティングか可到達性情報の交換を許容する相互ドメインルーティング・プロトコルです。 機能上、BGPはExternal BGP(E- BGP)とInternal 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.
通常、大きいネットワークはおよそ7万であるインターネットに知られているすべてのルートを学びます。 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セッション設立、および重いルートのばたつくことの期間、物凄いリソースを消費します。
Yu Informational [Page 8] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[8ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
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.
ルーティング階層構造の導入は、例えば、BGP、I-BGP Route Reflectors[7]とBGP Confederations[8]を通して完全なメッシュ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同輩にルーティング情報を分配する方法を変えるでしょう。 考える価値があるメカニズムが情報を分配するのにマルチキャストを使用するか、またはそれらと同様のメカニズムが使用した氾濫を採用している、-、または、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で議論するように考えられるべきです。
6. Scalable Routing Design Principles
6. スケーラブルなルート設定設計原理
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.
プロトコルデザイン決定、プロトコル実現決定、およびネットワークデザイン決定でルーティングがどう比例するかは影響を及ぼされます。 ネットワーク・デザイナーは、ネットワークデザイン決定をダイレクトに管理して、プロトコル設計と実装へのかなりの影響を持つことができます。 このドキュメントの焦点はネットワークデザイン決定です。
Yu Informational [Page 9] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[9ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
Following is a set of design principles for making a large network routing system more scalable:
以下に、大きいネットワークルーティングシステムをよりスケーラブルにするための1セットの設計原理があります:
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 Reducingルート処理o Compartmentalization o Making負担oのDefiningのスケーラブルなルーティング方針と実現o Utilizingを造ります。
6.1. Building Hierarchy
6.1. ビル階層構造
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でtieredされた階層構造を築き上げることになっています。 トランジットコアネットワークはネットワークが役立つ全体の地理的な領域をカバーしています。 それぞれのアクセスネットワーク(別名地域ネットワーク)は1つの領域をカバーしています。 通常、地方のコンポーネントの中に直リンク接続が全くありません。 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
このデザインはルーティングに関してトランジットコアネットワークと同じくらい完全に各地域ネットワークの独立しているASsを扱います、そして、各ASは独立しているIGPを走らせます。 ルーティング知識を交換するためのトランジットコアがある各地域ネットワークE-BGP。 完全なI-BGP
Yu Informational [Page 10] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[10ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
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.
接続は、それぞれのコンポーネントネットワークだけの中に設立される必要があります。 このデザインで、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付加的なASをルーティング経路に挿入するということです。 経路のこの付加的なASは他のプロバイダーのためにルート選択困難を引き起こすかもしれません。
2) One Domain with IGP and BGP Hierarchy
2) IGPがある1つのドメインとBGP階層構造
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つのASドメインに含んでいます。 または、ルーティング階層構造がマルチレベルを利用することによって実現される、-、OSPF領域とBGP ConfederationかI-BGP Reflectorのどちらかか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.
このメカニズムはルーティング経路での付加的なASの導入を避けます。(経路はPoint1)で説明されたメソッドより利点です)。 しかしながら、彼らの大部分が使用しているのでマルチ領域の階層的なIGPが大きいネットワークが現在1日間、めったに使用されていない、-、内部のルーティングのために。(それは、十分なマルチレベルサポートを持っていません)。 -、サポートマルチ領域ルーティング、それはバックボーンとサブ領域の間で厳しい階層構造を課して、特定の接頭語の代わりにデフォルトルートのバックボーン領域からサブ領域までの広告だけを許します。 この制限は簡単なサブ領域トポロジーによってネットワークに適しているかもしれません。 大きいネットワークにおけるサブ領域、通常地方かアクセスネットワーク自体には、複雑なトポロジーがあります。 デフォルトルートの非常に抽象的なルーティング情報を受け取ると、交通工学に必要であるルート選択をするサブ領域の能力は影響されるでしょう。 また、それは外部のASs例えば、IGPによって派生させられたBGP Multi出口弁別器(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.
取り組みが変更する作っていることにされるのである、-、議定書を作って、特定のルートのバックボーン領域からサブ領域までの分配を許してください。 メカニズムはそのような分配を容易にします。[15]では、指定されます。 そのようなメカニズムの実装であるときには利用可能になってください、ビルルーティングのための魅力的な選択が大きいネットワークの中の階層構造であるつもりであったならマルチレベルIGPを実装して。
Yu Informational [Page 11] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[11ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
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).
マルチ領域の代わりに-、全体のネットワークのために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ドメインがあっても、I-BGPをネットワークで、よりスケーラブルにするようにBGP階層構造を築き上げるのは可能です。 BGP ReflectorsとBGP Confederationsは完全なメッシュ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反射鏡は2つ以上のレベルの階層構造を築き上げる能力を提供します、階層構造の異なったレベルの中の相互作用がルーティング輪を作成する可能性を避けるために慎重にアレンジされる限り。
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つのレベルのルーティング階層構造は取り扱いスケーリング問題に十分ですか?」 「本当に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番目に、tieredされたサブドメインに分けられる必要があります。
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.
2つ以上のレベルの階層構造を持っていると、彼らが今日定義されるとき、IGPsの能力は超えられているでしょう。 例えば、バックボーン領域を通ってOSPFでは、すべての領域をつなげなければなりません。領域は2つ以上のレベルの階層構造を持っている可能性を排除します。 -、同じ制限を持っています。 したがって、再定義されるべきプロトコルの必要性はIGPの2つの階層的な層より望ましい状態でそうするべきです。
Yu Informational [Page 12] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[12ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
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プロトコルバグの大部分はルーティング領域サポートに関連します。 複数のレベルの中の相互作用が管理とデバッグの複雑さを増強するので、階層構造の中のレベルを最小に抑えるのは望ましいです。
6.2. Compartmentalization
6.2. 区画化
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.
以来本質的にはルーティング階層構造を築き上げると、大きいルーティング領域は、より小さい領域かドメインに分割されて、それは、区画化の目標を達成するのを助けます。
6.3. Making Proper Trade-offs
6.3. 適切なトレードオフをします。
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
冗長は複雑さと増強された隣接番組をネットワーク形態に紹介します。 また、冗長はできるだけ増加が発送する各ルートにおいて多くの迂回経路の必要性を課します。
Yu Informational [Page 13] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[13ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
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.
速い集合は、ネットワーク形態における変化ができるだけはやくネットワークに伝播されるのを必要とします。 そのような動作はルーティングアップデートとその結果ルート処理負担を増強します。 ネットワークであるときにいらいらさせられた負担は完全なインターネット・ルーティング情報を運びます、通常、大きいネットワークがして、トポロジー変化が頻繁に起こるとき。 ルートの湿りが、絶対速い集合を犠牲にして安定性を達成するのに必要であるかもしれません。
6.4. Reduce Burdens of Routing Information Processing
6.4. 経路情報処理の負担を減少させてください。
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)はルートのばたつくことの影響を減少させます。
6.4.1. Routing Intelligence Placement
6.4.1. ルート設定知性プレースメント
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.
また、処理の重い負担を動かすのがバンドの外へのプロセッサを発送するのも、望ましいです、パケット推進と取り扱いのためのネットワークルータにおける、より多くのリソースを解放して。
Yu Informational [Page 14] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[14ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
6.4.2. Reduce Routes and Routing Information
6.4.2. ルートと経路情報を減らしてください。
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、システムの多くのルートに、います。したがって、損をしている必要なルーティング情報なしでシステムのルートの数を減少させるのは最も良いです。
6.4.2.1. CIDR and Route Aggregation
6.4.2.1. CIDRとルート集合
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.
ネットワークの中で、より良い集合を達成するために。 ネットワークにおける、ルートの数を減少させるために、それはいて、地域ネットワークがトランジットコアネットワークにルートを発表するとき、それらを集めることができるように1ブロックの連続したIPアドレスを各アクセスか地域ネットワークに割り当てるべきです。 この道、コア、および他の地域ネットワークはどんな特定のアクセスネットワークの特定の接頭語も知る必要はないでしょう。 プロバイダーブロックからの顧客の住所の課題は集合をサポートするために計画されなければならないでしょうが、取り組み価値があるでしょう。
6.4.2.2. Utilize Default Routing When Possible
6.4.2.2. 可能であるときにはデフォルトルート設定を利用してください。
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.
デフォルトルートの使用は究極のルート総括を実現します。(それは、ルーティング情報を最小限まで減らします)。 また、例えば、ルート総括はルートのばたつくことの場合で独特のルートに関連している不安定性にマスクをかけます。 適切であるときに、ネットワークがデフォルトルーティングを利用するのは、有益です。 例えば、2番目に、tieredされた地域ネットワークがスタッブであり、完全なインターネット・ルーティング情報を要求するどんな接続顧客もいなければ、地域ネットワークは単に接続コアネットワークにデフォルトを向けることができます。 しかしながら、ルーティング情報の過剰総括には、ルーティング粒状を失うという危険があります、そして、その結果、交通工学などのネットワークの経営は悪影響を受けるでしょう。 したがって、警告は、デフォルトルーティングを使用するとき、運動させられる必要があります。
Yu Informational [Page 15] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[15ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
6.4.2.3. Reduce Alternative Paths
6.4.2.3. 迂回経路を減少させてください。
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分の1か4番目の代替経路を捨てることができました。 これはすべてのネットワーク管理者が彼女のネットワークの特別の必要性に基づいてする必要があるトレードオフ決定です。
6.4.3. Use Static Route at Edges
6.4.3. 縁でスタティックルートを使用してください。
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を通って交信するなら、リソース消費は非常に徹底的になるでしょう。 それが付属顧客ルータのすべてによって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.
一見したところでは、異なったAutonomous System(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.
プロバイダーの集合ルータの顧客のスタティックルートの構成は管理オーバーヘッドを加えるかもしれません、特に顧客が多くのルートの広告を出すなら。 他方では、通常、顧客がプロバイダーに発表するルートのセットはまれに変化します。 したがって、いったん構成されると、それは楽なメンテナンスを必要とします。
6.4.4. Minimize the Impact of Route Flapping
6.4.4. ルートのばたつくことの影響を最小にしてください。
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セッションの不安定性によって大幅に引き起こされます。 ルートのばたつくのは、世界的なインターネットでどこでも起因して、あらゆるネットワークに影響できます。
Yu Informational [Page 16] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[16ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
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を使用するのは、ルートのばたつくことを軽減するのを助けることができます。
6.5. Scalable Routing Policy and Scalable Implementation
6.5. スケーラブルなルート設定方針とスケーラブルな実装
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.
ルート設定方針は、1つ以上のルートが利用可能になるとネットワークか他のネットワークからのある一定のルートの承認と広告とルーティング好みに関する決定を発送することを伴います。 ルート設定方針は、ネットワーク実体の間でビジネス協定を実施して、非技術系の評価基準によって主に支配されます。 本質に、ルーティング方針は、ルートフィルタリングとルート選択の評価基準を定義することを伴います。
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つの局面が経路ドメイン、または、異なったプロバイダーネットワークの間のトラフィックコントロールと関係があります。 個々の接頭語に基づく方針を打ち出すのは、多くの接頭語がインターネットにある状態で比例しないので、この場合避けられるべきです。 行政上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
ルートフィルタリングの別の目的はトラフィックを'ブラックホール'に導く間違って広告を出したルーティング情報の承認を防ぐことによってルーティング情報の保全を保護することです。 この場合、接頭語ベースのフィルタリングだけが目標を十分実現するでしょう。 接頭語ベースのフィルタリングは、ネットワークと直接の顧客か同輩ネットワークとの境界に起こる必要があります。 同輩ネットワークが通常多量の接頭語の広告を出すので、同輩ネットワークの限界では、フィルタリングは、より管理しにくいです。 先に述べたように、知られているおよそ7万のルートがあります。
Yu Informational [Page 17] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[17ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
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つ以上のソースがさらにルートを広告に掲載できたので、これは、大きい無デフォルトのネットワークが、フィルターにかけるのさえ必要であるだろうことを意味します。 フィルターにかけられるのであるべき接頭語の全くの量はルータ構成メモリと構成管理のための挑戦を課します。 比例させるように、人は、どのソースから接頭語を受け入れるべきであるか、または否定するべきである整理するバンドで出ているプロセスから助けに依存する必要があるでしょう。 接頭語ベースのフィルタリングを実装するための現在の提案されたメカニズムの中に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 トラフィックがネットワークを出るように、最も近いインタコネクトポイントに交通整理します。 また、この方針はHotじゃがいもルート設定として知られています。
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.
以下の基本原理は、ルーティング政策管理をスケーリングするのを助けるでしょう。
Yu Informational [Page 18] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[18ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
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 バンドの外では、可能であるところでルーティング方針処理を使用します。
6.6. Out-of-Band Process
6.6. バンドの外では、処理してください。
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はバンドの外の現在の例のルート処理を提示します。 また、それは他の可能なソリューションを示します。
7. Conclusion and Discussion
7. 結論と議論
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
ルーティングがどう比例するかがネットワークの安定性と性能に直接的な衝撃を持っています。 インターネットの速い成長とプロバイダーのネットワークの結果の拡張に従って、スケーリングを発送して、ますますなってください。
Yu Informational [Page 19] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[19ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
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.
処理を発送するのを補助するバンドで出ているリソースの使用はインターネットExchange Points(IXPs)で使用されるだけである概念です。 しかしながら、潜在的にルーティングスケーリング問題を記述するのを助けるネットワークの中の利点にそれを使用できました。 これはさらなる探検にふさわしい話題です。
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パラダイムのままで残るという私たちの信念です。 したがって、本書では概説されたスケーラブルなルーティング設計原理は新技術の展開でまだ適用されているべきです。
8. Security Considerations
8. セキュリティ問題
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.
しかしながら、ドキュメントに示されたネットワーク区画化などのあるルーティングスケーリング改良メカニズムはことによるとそのような供給停止が全体のネットワークに広まるのを防ぐのを助けるでしょう、したがって、サービス不能攻撃で引き起こされたネットワーク供給停止を軽減するでしょう。
Yu Informational [Page 20] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[20ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
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.
本書では説明されたメカニズムは、ルーティング・プロトコルのセキュリティ局面を高めもしませんし、弱めもしませんが、ここでルーティング・プロトコルかルーティングメカニズムのセキュリティ増進がルーティングスケーラビリティに影響を与えるかもしれないのを示す価値があります。 したがって、ルーティングでセキュリティ増進を適用するとき、1つはスケーラビリティで含意を意識していなければなりません。
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]であったならプロポーズされます。 1セッションあたり1個のベースでそれをします、そして、MD-5つの拡大のオーバーヘッドは最小限です。その結果、スケーラビリティに直接的な衝撃を全く持っていません。 または、経路に沿ったどんなISPも情報を作り出したか、または変更したかもしれないので1接頭語あたりのAS経路検証をすることに関する心配があった、(陰湿である、) 1つの極端な解決策は処理、メモリ、および管理オーバーヘッドに関して非常に強いセキュリティを与えますが、莫大なスケーリング問題を提示する各接頭語のための署名を持つことです。
9. Acknowledgement
9. 承認
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とデーヴ・キャッツのおかげで、ドキュメントと多くの役に立つコメントの大量のレビューにおいて、特別です。 彼らの洞察に満ちたコメントのためにヤコフRekhter、クリスマス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].
作者をこのドキュメントの公表の後に話題の上のEnkeチェンによって作られた関連していて独立しているプレゼンテーションがあるのを意識するようにしました。 プレゼンテーションは[14]でこのようにして参照をつけられます。
10. References
10. 参照
[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] 「プロトコルがあるConjunctionにおける、Providing Connectionless-モードNetwork Service(ISO8473)の使用のためのIntermediate System Intra-ドメインRouteing Exchangeプロトコルへの中間的System」、ISO DP10589(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.、「OSIの使用、-、TCP/IPにおけるルート設定と二元的な環境、」、RFC1195、12月1990日
[3] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[3]Moy、J.、「OSPF、バージョン2インチ、RFC2328、1998インチ年4月。
[4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[4]RekhterとY.と1995年のT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。
[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.マラン、F.Jahanian、INFOCOM99、ニューヨーク(ニューヨーク)、1999年6月の議事における「インターネットルート設定の不安定性の起源」
Yu Informational [Page 21] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[21ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
[6] J. Moy, "OSPF-Anatomy of an Internet Routing Protocol",
Addison-Wesley, January 1998.
[6] J.Moy、「インターネットルーティング・プロトコルのOSPF-解剖学」、アディソン-ウエスリー、1998年1月。
[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 Route Reflection--完全への代替手段はIBGPを網の目にかけます」、RFC2796、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スケーリング問題を解決することへの自律システム同盟者アプローチ」、RFC1965、1996年6月。
[9] Curtis, V., Chandra, R. and R. Govindan, "BGP Route Flap
Damping", RFC 2439, November 1998.
[9] カーティスとV.とチャンドラとR.とR.Govindan、「BGPルートフラップ湿気」、RFC2439、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):」 「アドレス課題と集合戦略」、RFC1519、9月1993日
[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. and D.マイヤー、「ルート設定方針システム模写」、RFC2769、2000年2月。
[12] Bates, T., Bush, R., Li, T. and Y. Rekhter, "DNS-based NLRI
origin AS verification in BGP", Work in Progress.
[12] ProgressのベイツとT.とブッシュとR.と李とT.とY.Rekhter、「BGPでのDNSベースのNLRI起源AS検証」、Work。
[13] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, August 1998.
[13] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、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.スミット、「2レベルとのドメイン全体の接頭語分配、-、」 仕事進行中です。
Author's Address
作者のアドレス
Jieyun (Jessica) Yu CoSine Communications 1200 Bridge Parkway Redwood City, CA 94065
Parkwayレッドウッドシティー、Jieyun(ジェシカ)ユーコサインコミュニケーション1200Bridgeカリフォルニア 94065
EMail: jyy@cosinecom.com
メール: jyy@cosinecom.com
Yu Informational [Page 22] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[22ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
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.
NAPsのRoute Server(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.
また、大きいネットワークでアドレスルーティングスケーラビリティを助けるのにRoute Serverの概念を使用できます。
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
--------------------------- POPのLANメディア| | ----- ----- |CR| |RS| ----- ----- / | \ / | \C1 C2。Cn
Figure 1: RS serving customer aggregation router connecting
customer routers
図1: RS顧客に仕えること集合ルータ接続顧客ルータ
Yu Informational [Page 23] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[23ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
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です。 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.
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までのパスルートに続くでしょう、そして、これらのルートに続いて起こる交通は黒く掘られた状態でなるでしょう。 しかしながら、これはここで説明された特定のアプリケーションで問題ではありません。 C2、これはRSルータがC1と共にじっと見るためにCRを通らなければならないからです… 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.
C1をもっているRS同輩以来のこのシナリオで… RSルータがルーティング情報をC1に通過するとき、CRを通してCnで、それを必要とします…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
大きいプロバイダーネットワークには、Interexchange Point、NAPまたは個人的なインタコネクトに多くのBGP同輩がしばしばいます。 これは、境界ルータが多くのE-BGPセッションを扱わなければならないことを意味します。 以来
Yu Informational [Page 24] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[24ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
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ルータに移動させるのは、有望な代替の解決策です。 個人的なinterexchangeポイントの複数の同輩にRSを使用する場合では、シナリオは上の1で)説明されるように顧客集合ルータと顧客ルータの間で使用されるRSと同様です。 NAPのそのようなじっと見ることの場合では、ISPのNAPルータとRSの間の同じNAPメディアか私設のメディアに個人的なRSを置くことができました。
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反射鏡構造のさらに別の層を加えるだろうことです。 別の可能な解決策はI-BGP ServerとしてRSルータを使用するだろうことです。POPのトポロジーによって、この解決策は適当であるかもしれません。 ネットワークPOPのRSルータの使用は、さらに調査される必要があります。
Yu Informational [Page 25] RFC 2791 Scalable Routing Design Principles July 2000
スケーラブルな[25ページ]RFC2791ルート設定設計原理2000年7月の情報のユー
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Yu Informational [Page 26]
ユーInformationalです。[26ページ]
一覧
スポンサーリンク
