RFC1322 日本語訳
1322 A Unified Approach to Inter-Domain Routing. D. Estrin, Y.Rekhter, S. Hotz. May 1992. (Format: TXT=96934 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Estrin
Request for Comments: 1322 USC
Y. Rekhter
IBM
S. Hotz
USC
May 1992
Estrinがコメントのために要求するワーキンググループD.をネットワークでつないでください: 1322 USC Y.Rekhter IBM S.Hotz USC1992年5月
A Unified Approach to Inter-Domain Routing
相互ドメインルート設定への統一されたアプローチ
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。
Abstract
要約
This memo is an informational RFC which outlines one potential approach for inter-domain routing in future global internets. The focus is on scalability to very large networks and functionality, as well as scalability, to support routing in an environment of heterogeneous services, requirements, and route selection criteria.
このメモは将来のグローバルなインターネットにおける相互ドメインルーティングのための1つのポテンシャル法について概説する情報のRFCです。 異種のサービス、要件、およびルート選択の環境で評価基準を発送するのを支持するために、非常に大きいネットワーク、機能性、およびスケーラビリティには焦点がスケーラビリティにあります。
Note: The work of D. Estrin and S. Hotz was supported by the National Science Foundation under contract number NCR-9011279, with matching funds from GTE Laboratories. The work of Y. Rekhter was supported by the Defense Advanced Research Projects Agency, under contract DABT63-91-C-0019. Views and conclusions expressed in this paper are not necessarily those of the Defense Advanced Research Projects Agency and National Science Foundation.
以下に注意してください。 D.EstrinとS.Hotzの仕事は契約番号NCR-9011279の下で国立科学財団によって支持されました、GTE研究所からの補助金で。 Y.Rekhterの仕事は契約DABT63 91C0019に基づき国防高等研究計画庁によって支持されました。 この紙で言い表された視点と結論は必ず国防高等研究計画庁と科学基金のものであるというわけではありません。
1.0 Motivation
1.0 動機
The global internet can be modeled as a collection of hosts interconnected via transmission and switching facilities. Control over the collection of hosts and the transmission and switching facilities that compose the networking resources of the global internet is not homogeneous, but is distributed among multiple administrative authorities. Resources under control of a single administration form a domain. In order to support each domain's autonomy and heterogeneity, routing consists of two distinct components: intra-domain (interior) routing, and inter-domain (exterior) routing. Intra-domain routing provides support for data communication between hosts where data traverses transmission and switching facilities within a single domain. Inter-domain routing provides support for data communication between hosts where data
トランスミッションと施設を切り換えることを通してホストの収集がインタコネクトしたようにグローバルなインターネットをモデル化できます。 グローバルなインターネットに関するネットワークリソースを構成するホストの収集、トランスミッション、および切り換え施設のコントロールは、均質ではありませんが、複数の職務権限の中に広げられます。 ただ一つの管理で制御されたリソースはドメインを形成します。 各ドメインの自治と異種性を支持するために、ルーティングは2つの異なったコンポーネントから成ります: イントラドメインの(内部)のルーティング、および相互ドメインの(外)のルーティング。 イントラドメインルーティングはデータが単一領域の中でトランスミッションと切り換え施設を横断するところにホストの間のデータ通信のサポートを提供します。 相互ドメインルーティングがホストの間のデータ通信のサポートにどこを提供するか、データ
Estrin, Rekhter & Hotz [Page 1] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[1ページ]RFC1322
traverses transmission and switching facilities spanning multiple domains. The entities that forward packets across domain boundaries are called border routers (BRs). The entities responsible for exchanging inter-domain routing information are called route servers (RSs). RSs and BRs may be colocated.
複数のドメインにかかるトランスミッションと切り換え施設を横断します。 ドメイン境界の向こう側にパケットを送る実体は境界ルータ(BRs)と呼ばれます。 相互ドメインルーティング情報を交換するのに原因となる実体はルートサーバ(RSs)と呼ばれます。 RSsとBRsはcolocatedされるかもしれません。
As the global internet grows, both in size and in the diversity of routing requirements, providing inter-domain routing that can accommodate both of these factors becomes more and more crucial. The number and diversity of routing requirements is increasing due to: (a) transit restrictions imposed by source, destination, and transit networks, (b) different types of services offered and required, and (c) the presence of multiple carriers with different charging schemes. The combinatorial explosion of mixing and matching these different criteria weighs heavily on the mechanisms provided by conventional hop-by-hop routing architectures ([ISIS10589, OSPF, Hedrick88, EGP]).
グローバルなインターネットがサイズとルーティング要件の多様性に生えているのに従って、これらの要素の両方を収容できる相互ドメインルーティングを提供するのはますます重要になります。 ルーティング要件の数と多様性は以下のため増加しています。 (a) ソース、目的地、および輸送網によって課されたトランジット制限、(b) 異なったタイプのサービスが提供されて、必要であり、(c) 異なった充電がある複数のキャリヤーの存在は計画します。 これらの異なった評価基準を混ぜて、合わせる結合の爆発は重くホップごとの従来のルーティング建築([ISIS10589、OSPF、Hedrick88、EGP])によって提供されたメカニズムに伸しかかります。
Current work on inter-domain routing within the Internet community has diverged in two directions: one is best represented by the Border Gateway Protocol (BGP)/Inter-Domain Routeing Protocol (IDRP) architectures ([BGP91, Honig90, IDRP91]), and another is best represented by the Inter-Domain Policy Routing (IDPR) architecture ([IDPR90, Clark90]). In this paper we suggest that the two architectures are quite complementary and should not be considered mutually exclusive.
インターネットコミュニティの中の相互ドメインルーティングへの執筆中の作品は両方向に分岐しました: ボーダ・ゲイトウェイ・プロトコル相互(BGP)/Domain Routeingプロトコル(IDRP)構造([BGP91、Honig90、IDRP91])で1を表すのが最も良く、Inter-ドメインPolicyルート設定(IDPR)構造([IDPR90、Clark90])で別のものを表すのは最も良いです。 この紙では、私たちを2つの構造がかなり補足的であると示唆して、互いに排他的であると考えるべきではありません。
We expect that over the next 5 to 10 years, the types of services available will continue to evolve and that specialized facilities will be employed to provide new services. While the number and variety of routes provided by hop-by-hop routing architectures with type of service (TOS) support (i.e., multiple, tagged routes) may be sufficient for a large percentage of traffic, it is important that mechanisms be in place to support efficient routing of specialized traffic types via special routes. Examples of special routes are: (1) a route that travels through one or more transit domains that discriminate according to the source domain, (2) a route that travels through transit domains that support a service that is not widely or regularly used. We refer to all other routes as generic.
私たちは、次の5〜10年間手があいているサービスのタイプが、発展し続けて、専門化している施設が新種業務を提供するのに使われると予想します。 ホップごとのルーティング構造によってサービス(TOS)サポート(すなわち、複数の、そして、タグ付けをされたルート)のタイプに提供されたルートの数とバラエティーは交通の大きな割合に十分であるかもしれませんが、メカニズムが特別なルートで専門化している交通タイプの効率的なルーティングを支持するために適所にあるのは、重要です。 特別なルートに関する例は以下の通りです。 (1) ソースドメイン(2) (広さか定期的に利用されないサービスを支持するトランジットドメインを通って移動するルート)に従って差別する1つ以上のトランジットドメインを通って移動するルート。 私たちは一般的な他のすべての同じくらいルートを示します。
Our desire to support special routes efficiently led us to investigate the dynamic installation of routes ([Breslau-Estrin91, Clark90, IDPR90]). In a previous paper ([Breslau-Estrin91]), we evaluated the algorithmic design choices for inter-domain policy routing with specific attention to accommodating source-specific and other "special" routes. The conclusion was that special routes are best supported with source-routing and extended link-state algorithms; we refer to this approach as source-demand routing
効率的に特別なルートを支える私たちの願望は、私たちがルート([ブレスラウ-Estrin91、Clark90、IDPR90])のダイナミックなインストールを調査するように導きました。 前の論文([ブレスラウ-Estrin91])では、私たちは相互ドメイン方針ルーティングのためのソース特有の、そして、他の「特別な」ルートに対応することに関する特定の注意によるアルゴリズムのデザイン選択を評価しました。 結論はソースルーティングと拡張リンク州のアルゴリズムで特別なルートを最も良い支えるということでした。 私たちはソース要求ルーティングとこのアプローチを呼びます。
Estrin, Rekhter & Hotz [Page 2] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[2ページ]RFC1322
[Footnote: The Inter-Domain Policy Routing (IDPR) architecture uses these techniques.]. However, a source-demand routing architecture, used as the only means of inter-domain routing, has scaling problems because it does not lend itself to general hierarchical clustering and aggregation of routing and forwarding information. For example, even if a particular route from an intermediate transit domain X, to a destination domain Y is shared by 1,000 source-domains, IDPR requires that state for each of the 1,000 routes be setup and maintained in the transit border routers between X and Y. In contrast, an alternative approach to inter-domain routing, based on hop-by-hop routing and a distributed route-computation algorithm (described later), provides extensive support for aggregation and abstraction of reachability, topology, and forwarding information. The Border Gateway Protocol (BGP) and Inter-Domain Routeing Protocol (IDRP) use these techniques ([BGP91, IDRP91]). While the BGP/IDRP architecture is capable of accommodating very large numbers of datagram networks, it does not provide support for specialized routing requirements as flexibly and efficiently as IDPR-style routing.
[脚注: Inter-ドメインPolicyルート設定(IDPR)構造はこれらのテクニックを使用します。] しかしながら、それがルーティングと推進情報の一般的な階層的なクラスタリングと集合に適していないので、相互ドメインルーティングの唯一の手段として使用されるソース要求ルーティング構造はスケーリング問題を持っています。 例えば; 特定の中間的トランジットドメインXから目的地ドメインYまでのルートが1,000のソースドメインによって共有されても、IDPRは、それぞれの1,000のルートへの状態がセットアップであってXとYの間のトランジット境界ルータで維持されているのを必要とします; 対照的に、ホップごとのルーティングと分配された経路計算アルゴリズム(後で説明される)に基づく相互ドメインルーティングへの代替的アプローチは集合の大規模な支持と可到達性、トポロジー、および推進情報の抽象化を提供します。 ボーダ・ゲイトウェイ・プロトコル(BGP)とInter-ドメインRouteingプロトコル(IDRP)はこれらのテクニック([BGP91、IDRP91])を使用します。 BGP/IDRP構造が非常に多くのデータグラム・ネットワークに対応できる間、それはIDPR-スタイルルーティングして柔軟に効率的に専門化しているルーティング要件のサポートを提供しません。
1.1 Overview of the Unified Architecture
1.1 統一された構造の概観
We want to support special routes and we want to exploit aggregation when a special route is not needed. Therefore, our scalable inter- domain routing architecture consists of two major components: source-demand routing (SDR), and node routing (NR). The NR component computes and installs routes that are shared by a significant number of sources. These generic routes are commonly used and warrant wide propagation, consequently, aggregation of routing information is critical. The SDR component computes and installs specialized routes that are not shared by enough sources to justify computation by NR [Footnote: Routes that are only needed sporadically (i.e., the demand for them is not continuous or otherwise predictable) are also candidates for SDR.]. The potentially large number of different specialized routes, combined with their sparse utilization, make them too costly to support with the NR mechanism.
特別なルートを支えたいと思います、そして、特別なルートは必要でないときに、集合を利用したいと思います。 したがって、私たちのスケーラブルな相互ドメインルーティング構造は2個の主要コンポーネントから成ります: ソース要求ルーティング(SDR)、およびノードルーティング(NR)。 NRの部品は、多くのソースによって共有されるルートを、計算して、インストールします。 その結果、ルーティング情報の集合はこれらの一般的なルートが一般的に使用されて、広い伝播を保証するのが重要です。 SDRの部品は、NRによって計算を正当化できるくらいのソースによって共有されない専門化しているルートを、計算して、インストールします[脚注: また、散発的(すなわち、それらの要求は、連続していないか、またはそうでなければ、予測できる)に必要であるだけであるルートはSDRの候補です。]。 多くの異なった専門化している彼らのまばらな利用に結合したルートで、それらはNRメカニズムで支持できないくらい高価になります。
A useful analogy to this approach is the manufacturing of consumer products. When predictable patterns of demand exist, firms produce objects and sell them as "off the shelf" consumer goods. In our architecture NR provides off-the-shelf routes. If demand is not predictable, then firms accept special orders and produce what is demanded at the time it is needed. In addition, if a part is so specialized that only a single or small number of consumers need it, the consumer may repeatedly special order the part, even if it is needed in a predictable manner, because the consumer does not represent a big enough market for the producer to bother managing the item as part of its regular production. SDR provides such special
このアプローチへの役に立つ類推はコンシューマ製品の製造です。 要求の予測できるパターンが存在していると、会社は、「すぐ入手できる」消費財として物を作り出して、それらを販売します。 私たちの構造に、NRはすぐ入手できるルートを提供します。 要求が予測できないなら、それが必要であるときに、会社は、特注品を受け入れて、要求されることを生産します。 部分、それが予測できる方法で必要であっても、消費者が大きくaを表さないので、十分は売り出されます。部分が非常に専門にされるので単一の、または、少ない数の消費者だけがそれを必要とするなら、さらに、消費者が繰り返して必要である、特注品、プロデューサーが、正規の生産の一部として項目を管理するのを苦しめるように。 SDRはそのような特別番組を提供します。
Estrin, Rekhter & Hotz [Page 3] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[3ページ]RFC1322
order, on-demand routes.
注文、要求次第のルート。
By combining NR and SDR routing we propose to support inter-domain routing in internets of practically-unlimited size, while at the same time providing efficient support for specialized routing requirements.
NRとSDRルーティングを結合することで、私たちは、同時に専門化しているルーティング要件の効率的なサポートを提供している間、実際に無制限なサイズのインターネットで相互ドメインルーティングを支持するよう提案します。
The development of this architecture does assume that routing requirements will be diverse and that special routes will be needed. On the other hand, the architecture does not depend on assumptions about the particular types of routes demanded or on the distribution of that demand. Routing will adapt naturally over time to changing traffic patterns and new services by shifting computation and installation of particular types of routes between the two components of the hybrid architecture [Footnote: Before continuing with our explanation of this architecture, we wish to state up front that supporting highly specialized routes for all source-destination pairs in an internet, or even anything close to that number, is not feasible in any routing architecture that we can foresee. In other words, we do not believe that any foreseeable routing architecture can support unconstrained proliferation of user requirements and network services. At the same time, this is not necessarily a problem. The capabilities of the architecture may in fact exceed the requirements of the users. Moreover, some of the requirements that we regard as infeasible from the inter-domain routing point of view, may be supported by means completely outside of routing. Nevertheless, the caveat is stated here to preempt unrealistic expectations.].
この構造の開発は、ルーティング要件がさまざまになって、特別なルートが必要であると仮定します。 他方では、構造は要求されるか、その要求の分配の特定のタイプのルートに関する前提によりません。 ルート設定は自然に時間がたつにつれて、ハイブリッド構造の2つの成分の間の特定のタイプのルートの移行している計算とインストールでトラフィック・パターンを変えて、新種業務に順応するでしょう。[以下に脚注をつけてください。 この構造に関する私たちの説明を続行する前に、その数の近くでインターネット、または何かでさえ非常に専門化しているルートをすべてのソース目的地組支えるのが私たちが見通すことができるどんなルーティング構造でも可能でないと前払いで述べたいと思います。 言い換えれば、私たちは、どんな予見できるルーティング構造もユーザ要件とネットワーク・サービスの自由な増殖を支持できると信じていません。 同時に、これは必ず問題であるというわけではありません。 事実上、構造の能力はユーザの要件を超えるかもしれません。 そのうえ、私たちが相互ドメインルーティング観点から実行不可能であると見なして、支持されるかもしれない要件のいくつかがルーティングの外部を完全に意味します。 それにもかかわらず、警告は、非現実的な期待を先取りするためにここに述べられています。].
While the packet forwarding functions of the NR and SDR components have little or no coupling with each other, the connectivity information exchange mechanism of the SDR component relies on services provided by the NR component.
NRとSDRの部品のパケット推進関数には互いがあるカップリングがまずありませんが、SDRの部品の接続性情報交換メカニズムはNRの部品によって提供されたサービスに依存します。
1.2 Outline
1.2 アウトライン
The remainder of this report is organized as follows. Section 2 outlines the requirements and priorities that guide the design of the NR and SDR components. Sections 3 and 4 describe the NR and SDR design choices, respectively, in light of these requirements. Section 5 describes protocol support for the unified architecture and briefly discusses transition issues. We conclude with a brief summary.
このレポートの残りは以下の通り組織化されます。 セクション2はNRとSDRの部品の設計を誘導する要件とプライオリティについて概説します。 セクション3と4はこれらの要件の観点からそれぞれNRとSDRデザイン選択について説明します。 セクション5は、統一された構造のプロトコルサポートについて説明して、簡潔に変遷問題について論じます。 私たちは簡潔な概要で締めくくります。
Estrin, Rekhter & Hotz [Page 4] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[4ページ]RFC1322
2.0 Architectural Requirements and Priorities
2.0 建築要件とプライオリティ
In order to justify our design choices for a scalable inter-domain routing architecture, we must articulate our evaluation criteria and priorities. This section defines complexity, abstraction, policy, and type of service requirements.
スケーラブルな相互ドメインルーティング構造のための私たちのデザイン選択を正当化するために、私たちは評価基準とプライオリティについて明確に話さなければなりません。 このセクションはサービス要件の複雑さ、抽象化、方針、およびタイプを定義します。
2.1 Complexity
2.1 複雑さ
Inter-domain routing complexity must be evaluated on the basis of the following performance metrics: (1) storage overhead, (2) computational overhead, and (3) message overhead. This evaluation is essential to determining the scalability of any architecture.
以下の性能測定基準に基づいて相互ドメインルーティングの複雑さを評価しなければなりません: (1) 格納オーバーヘッド、(2)のコンピュータのオーバーヘッド、および(3)メッセージオーバーヘッド。 この評価はどんな構造のスケーラビリティも決定するのに不可欠です。
2.1.1 Storage Overhead
2.1.1 格納オーバーヘッド
The storage overhead of an entity that participates in inter-domain routing comes from two sources: Routing Information Base (RIB), and Forwarding Information Base (FIB) overhead. The RIB contains the routing information that entities exchange via the inter-domain routing protocol; the RIB is the input to the route computation. The FIB contains the information that the entities use to forward the inter-domain traffic; the FIB is the output of the route computation. For an acceptable level of storage overhead, the amount of information in both FIBs and RIBs should grow significantly slower than linearly (e.g., close to logarithmically) with the total number of domains in an internet. To satisfy this requirement with respect to the RIB, the architecture must provide mechanisms for either aggregation and abstraction of routing and forwarding information, or retrieval of a subset of this information on demand. To satisfy this requirement with respect to the FIB, the architecture must provide mechanisms for either aggregation of the forwarding information (for the NR computed routes), or dynamic installation/tear down of this information (for the SDR computed routes).
相互ドメインルーティングに参加する実体の格納オーバーヘッドは2つのソースから来ます: Information基地(RIB)、およびForwarding Information基地(FIB)のオーバーヘッドを発送します。 RIBは相互ドメインルーティングを通した実体交換が議定書を作るというルーティング情報を含んでいます。 RIBは経路計算への入力です。 FIBは実体が相互ドメイン交通を進めるのに使用する情報を含んでいます。 FIBは経路計算の出力です。 合格水準の格納オーバーヘッドのために、FIBsとRIBsの両方の情報量が直線的よりかなり遅くなるべきである、(例えば、対数関数的に閉じる、)、インターネットにおける、ドメインの総数で。 RIBに関してこの要件を満たすために、構造はルーティングと推進情報の集合と抽象化かオンデマンドのこの情報の部分集合の検索のどちらかにメカニズムを提供しなければなりません。 FIBに関してこの要件を満たすために、構造は推進情報(NRがルートを計算したので)の集合かダイナミックなインストール/裂け目のどちらかへのメカニズムにこの情報について下にを供給しなければなりません(SDRがルートを計算したので)。
Besides being an intrinsically important evaluation metric, storage overhead has a direct impact on computational and bandwidth complexity. Unless the computational complexity is fixed (and independent of the total number of domains), the storage overhead has direct impact on the computational complexity of the architecture since the routing information is used as an input to route computation. Moreover, unless the architecture employs incremental updates, where only changes to the routing information are propagated, the storage overhead has direct impact on the bandwidth overhead of the architecture since the exchange of routing information constitutes most of the bandwidth overhead.
さらにメートル法の本質的に重要な評価格納オーバーヘッドであることはコンピュータと帯域幅複雑さに直接的な衝撃を持っています。 計算量が修理されるのと(ドメインの総数から独立する)でないなら、ルーティング情報が入力として経路計算に使用されるので、格納オーバーヘッドは構造の計算量に直接的な衝撃を持っています。 そのうえ、構造がアップデート増加を使わない場合、ルーティング情報への変化だけが伝播されるところでは、ルーティング情報の交換が帯域幅オーバーヘッドの大部分を構成するので、格納オーバーヘッドは構造の帯域幅オーバーヘッドに直接的な衝撃を持っています。
Estrin, Rekhter & Hotz [Page 5] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[5ページ]RFC1322
2.1.2 Computational Overhead
2.1.2 コンピュータのオーバーヘッド
The NR component will rely primarily on precomputation of routes. If inter-domain routing is ubiquitous, then the precomputed routes include all reachable destinations. Even if policy constraints make fully ubiquitous routing impossible, the precomputed routes are likely to cover a very large percentage of all reachable destinations. Therefore the complexity of this computation must be as small as possible. Specifically, it is highly desirable that the architecture would employ some form of partial computation, where changes in topology would require less than complete recomputation. Even if complete recomputation is necessary, its complexity should be less than linear with the total number of domains.
NRの部品は主としてルートの前計算を当てにするでしょう。 相互ドメインルーティングが遍在しているなら、前計算されたルートはすべての届いている目的地を含んでいます。 完全に遍在しているルーティングが方針規制で不可能になっても、前計算されたルートはすべての届いている目的地の非常に大きい百分率をカバーしそうです。 したがって、この計算の複雑さはできるだけ小さくなければなりません。 明確に、構造が何らかの形式の部分的な計算を使うのは、非常に望ましいです、トポロジーの変化が完全な再計算以下を必要とするだろうところで。 完全な再計算が必要であっても、複雑さはドメインの総数であまり直線的であるべきではありません。
The SDR component will use on-demand computation and caching. Therefore the complexity of this computation can be somewhat higher. Another reason for relaxed complexity requirements for SDR is that SDR is expected to compute routes to a smaller number of destinations than is NR (although SDR route computation may be invoked more frequently).
SDRの部品は要求次第の計算とキャッシュを使用するでしょう。 したがって、この計算の複雑さはいくらか高い場合があります。 SDRに、伸びやかな複雑さ要件の別の理由はSDRがNR(SDR経路計算は、より頻繁に呼び出されるかもしれませんが)より少ない数の目的地にルートを計算すると予想されるということです。
Under no circumstances is computational complexity allowed to become exponential (for either the NR or SDR component).
計算量は指数に(NRかSDRの部品のための)決して、なることができません。
2.1.3 Bandwidth Overhead
2.1.3 帯域幅オーバーヘッド
The bandwidth consumed by routing information distribution should be limited. However, the possible use of data compression techniques and the increasing speed of network links make this less important than route computation and storage overhead. Bandwidth overhead may be further contained by using incremental (rather than complete) exchange of routing information.
ルーティング情報流通で消費された帯域幅は制限されるべきです。 しかしながら、データ圧縮のテクニックの活用可能性とネットワークリンクの増加する速度で、これは経路計算と格納オーバーヘッドほど重要でなくなります。 帯域幅オーバーヘッドは、ルーティング情報の増加(完全であるよりむしろ)の交換を使用することによって、さらに含まれるかもしれません。
While storage and bandwidth overhead may be interrelated, if incremental updates are used then bandwidth overhead is negligible in the steady state (no changes in topology), and is independent of the storage overhead. In other words, use of incremental updates constrains the bandwidth overhead to the dynamics of the internet. Therefore, improvements in stability of the physical links, combined with techniques to dampen the effect of topological instabilities, will make the bandwidth overhead even less important.
格納と帯域幅オーバーヘッドは相関的であるかもしれませんが、アップデート増加が使用されているなら、帯域幅オーバーヘッドは、定常状態(トポロジーで変化がない)で取るにたらなく、格納オーバーヘッドから独立しています。 言い換えれば、アップデート増加の使用はインターネットの力学に帯域幅オーバーヘッドを抑制します。 したがって、位相的な不安定性の効果を湿らせるようにテクニックに結合された物理的なリンクの安定性における改良で、帯域幅オーバーヘッドは、より重要でなくさえなるでしょう。
2.2 Aggregation
2.2 集合
Aggregation and abstraction of routing and forwarding information provides a very powerful mechanism for satisfying storage, computational, and bandwidth constraints. The ability to aggregate, and subsequently abstract, routing and forwarding information is
ルーティングと推進情報の集合と抽象化は、満足させるための非常に強力なメカニズムにコンピュータの格納を提供して、規制を帯域幅に提供します。 集合的、そして、次に抽象的なルーティングと情報を転送することへの能力はそうです。
Estrin, Rekhter & Hotz [Page 6] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[6ページ]RFC1322
essential to the scaling of the architecture [Footnote: While we can not prove that there are no other ways to achieve scaling, we are not aware of any mechanism other than clustering that allows information aggregation/abstraction. Therefore, the rest of the paper assumes that clustering is used for information aggregation/abstraction.]. This is especially true with respect to the NR component, since the NR component must be capable of providing routes to all or almost all reachable destinations.
構造のスケーリングに不可欠です。[以下に脚注をつけてください。 スケーリングを達成する他の方法が全くないと立証できませんが、私たちは情報集合/抽象化を許すクラスタリング以外のどんなメカニズムも意識していません。 したがって、紙の残りは、クラスタリングが情報集合/抽象化に使用されると仮定します。]. これはNRの部品に関して特に本当です、NRの部品がすべてかほとんどすべての届いている目的地にルートを提供できなければならないので。
At the same time, since preserving each domain's independence and autonomy is one of the crucial requirements of inter-domain routing, the architecture must strive for the maximum flexibility of its aggregation scheme, i.e., impose as few preconditions, and as little global coordination, as possible on the participating domains.
各ドメインの独立と自治を保存するのが、相互ドメインルーティングの重要な要件の1つである時から構造が集合計画の最大の柔軟性を求めて努力しなければならない同時に、すなわち、同じくらいほとんど参加ドメインで可能であるとしての同じくらいわずかな前提条件、およびグローバルなコーディネートを課さないでください。
The Routing Information Base (RIB) carries three types of information: (1) topology (i.e., the interconnections between domains or groups of domains), (2) network layer reachability, and (3) transit constraint. Aggregation of routing information should provide a reduction of all three components. Aggregation of forwarding information will follow from reachability information aggregation.
経路情報基地(RIB)は3つのタイプの情報を運びます: (1) トポロジー(すなわち、ドメインのドメインかグループの間のインタコネクト)、(2)ネットワーク層の可到達性、および(3)トランジット規制。 ルーティング情報の集合はすべての3つのコンポーネントの減少を供給するべきです。 推進情報の集合は可到達性情報集合から続くでしょう。
Clustering (by forming routing domain confederations) serves the following aggregation functions: (1) to hide parts of the actual physical topology, thus abstracting topological information, (2) to combine a set of reachable destination entities into a single entity and reduce storage overhead, and (3) to express transit constraints in terms of clusters, rather than individual domains.
クラスタリング(経路ドメイン同盟者を形成するのによる)は以下の総計機能に役立ちます: (1) 実際の物理的なトポロジーの部品を隠して、その結果、1セットの届いている目的地実体を単一体に結合して、個々のドメインよりむしろクラスタに関してトランジット規制を言い表すために格納オーバーヘッド、および(3)を抑えるために位相的な情報、(2)を抜き取るために。
As argued in [Breslau-Estrin91], the architecture must allow confederations to be formed and changed without extensive configuration and coordination; in particular, forming a confederation should not require global coordination (such as that required in ECMA ([ECMA89]). In addition, aggregation should not require explicit designation of the relative placement of each domain relative to another; i.e., domains or confederations of domains should not be required to agree on a partial ordering (i.e., who is above whom, etc.).
[ブレスラウ-Estrin91]で論争されるように、構造は、同盟者が大規模な構成とコーディネートなしで形成されて、変えられるのを許容しなければなりません。 特に、同盟者を形成するのはグローバルなコーディネート(ECMA[ECMA89]で必要であるそれなどの)を必要とするべきではありません。さらに、集合は別のものに比例してそれぞれのドメインの相対的なプレースメントの明白な名称を必要とするべきではありません; すなわち、ドメインのドメインか同盟者は順序に同意するのが(すなわち、だれがだれの上でいますかなど)必要であるべきではありません。
Estrin, Rekhter & Hotz [Page 7] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[7ページ]RFC1322
The architecture should allow different domains to use different methods of aggregation and abstraction. For example, a research collaborator at IBM might route to USC as a domain-level entity in order to take advantage of some special TOS connectivity to, or even through, USC. Whereas, someone else at Digital Equipment Corporation might see information at the level of the California Educational Institutions Confederation, and know only that USC is a member. Alternatively, USC might see part of the internal structure within the IBM Confederation (at the domain's level), whereas UCLA may route based on the confederation of IBM domains as a whole.
構造で、異なったドメインは集合と抽象化の異なった方法を使用できるべきです。 例えば、IBMの研究共同制作者は、USCかUSCさえを通して何らかの特別なTOSの接続性を利用するためにドメインレベルとして実体をUSCに発送するかもしれません。 ところが、DECの他の誰かが、カリフォルニアEducational Institutions Confederationのレベルで情報を考えて、USCがメンバーにすぎないことを知るかもしれません。 あるいはまた、USCはIBM Confederation(ドメインのレベルにおける)の中で内部の構造の一部を見るかもしれませんが、UCLAはIBMの同盟者に基づいて全体でドメインを発送するかもしれません。
Support for confederations should be flexible. Specifically, the architecture should allow confederations to overlap without being nested, i.e., a single domain, or a group of domains may be part of more than one confederation. For example, USC may be part of the California Educational Institutions Confederation and part of the US R&D Institutions Confederation; one is not a subset of the other. Another example: T.J. Watson Research Center might be part of NYSERNET Confederation and part of IBM-R&D-US Confederation. While the above examples describe cases where overlap consists of a single domain, there may be other cases where multiple domains overlap. As an example consider the set of domains that form the IBM Confederation, and another set of domains that form the DEC Confederation. Within IBM there is a domain IBM-Research, and similarly within DEC there is a domain DEC-Research. Both of these domains could be involved in some collaborative effort, and thus have established direct links. The architecture should allow restricted use of these direct links, so that other domains within the IBM Confederation would not be able to use it to talk to other domains within the DEC Confederation. A similar example exists when a multinational corporation forms a confederation, and the individual branches within each country also belong to their respective country confederations. The corporation may need to protect itself from being used as an inter-country transit domain (due to internal, or international, policy). All of the above examples illustrate a situation where confederations overlap, and it is necessary to control the traffic traversing the overlapping resources.
同盟者のサポートはフレキシブルであるべきです。 明確に、入れ子にされないで、同盟者は構造で重なることができるべきです、すなわち、単一領域、または、ドメインのグループが1人以上の同盟者の一部であるかもしれません。 例えば、USCはカリフォルニアEducational Institutions Confederationの一部と米国研究開発Institutions Confederationの一部であるかもしれません。 1つはもう片方の部分集合ではありません。 別の例: T.J.ワトソン研究所は、NYSERNET Confederationの一部とIBM R&D米国Confederationの一部であるかもしれません。 上記の例がオーバラップが単一領域から成るケースについて説明している間、他のケースが複数のドメインが重なるところにあるかもしれません。 例と、IBM Confederationを形成するドメイン、および12月のConfederationを形成するもう1セットのドメインのセットを考えてください。 中では、そこのIBMがドメインIBM-研究です、そして、同様に、12月中に、ドメイン12月-研究があります。 これらのドメインの両方が、何らかの共同努力にかかわることができて、その結果、直リンクを確立しました。 構造はこれらの直リンクの制限された使用を許すべきです、IBM Confederationの中の他のドメインが12月のConfederationの中で他のドメインと話すのにそれを使用できないように。 多国籍企業が同盟者を形成するとき、同様の例は存在しています、そして、また、各国の中の個々のブランチは彼らのそれぞれの国の同盟者のものです。 会社は、相互国のトランジットドメイン(内部的、または、国際的な方針による)として使用されるので我が身をかばう必要があるかもしれません。 上記の例のすべてが同盟者が重なって、それが重なっているリソースを横断しながら交通整理するのに必要である状況を例証します。
While flexible aggregation should be accommodated in any inter-domain architecture, the extent to which this feature is exploited will have direct a effect on the scalability associated with aggregation. At the same time, the exploitation of this feature depends on the way addresses are assigned. Specifically, scaling associated with forwarding information depends heavily on the assumption that there will be general correspondence between the hierarchy of address registration authorities, and the way routing domains and routing domain confederations are organized (see Section 2.6).
フレキシブルな集合がどんな相互ドメイン構造でも設備されるべきである間、この特徴が利用される範囲は集合に関連しているスケーラビリティに影響をダイレクトに与えるでしょう。 同時に、この特徴の開発はアドレスが割り当てられる方法によります。 明確に、推進情報に関連しているスケーリングは大いにアドレス登録局の階層構造と、経路ドメインと経路ドメイン同盟者が組織化されている方法との一般的な通信があるという(セクション2.6を見てください)前提によります。
Estrin, Rekhter & Hotz [Page 8] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[8ページ]RFC1322
2.3 Routing Policies
2.3 ルート設定方針
Routing policies that the architecture must support may be broadly classified into transit policies and route selection policies [Breslau-Estrin 91, Estrin89].
構造が支持しなければならないルート設定方針は運送保険証券とルート選択方針[ブレスラウ-Estrin91、Estrin89]に露骨に分類されるかもしれません。
Restrictions imposed via transit policies may be based on a variety of factors. The architecture should be able to support restrictions based on the source, destination, type of services (TOS), user class identification (UCI), charging, and path [Estrin89 , Little89]. The architecture must allow expression of transit policies on all routes, both NR and SDR. Even if NR routes are widely used and have fewer source or destination restrictions, NR routes may have some transit qualifiers (e.g., TOS, charging, or user-class restriction). If the most widely-usable route to a destination has policy qualifiers, it should be advertiseable by NR and the transit constraints should be explicit.
運送保険証券で課された制限はさまざまな要素に基づくかもしれません。 構造はソース、目的地、サービスのタイプ(TOS)、ユーザ階級帰属意識(UCI)、充電、および経路[Estrin89、Little89]に基づく制限をサポートできるべきです。 構造はルート、NRとSDRのすべての両方における運送保険証券の表現を許容しなければなりません。NRルートが広く使用され、より少ないソースか目的地制限を持っても、NRルートには、何人かのトランジット資格を与える人(例えば、TOS、充電、またはユーザ・クラス制限)がいるかもしれません。 目的地への最も多くの広く使用可能なルートに方針資格を与える人がいるなら、NRで「広告を出-可能」であるはずです、そして、トランジット規制は明白であるべきです。
Route selection policies enable each domain to select a particular route among multiple routes to the same destination. To maintain maximum autonomy and independence between domains, the architecture must support heterogeneous route selection policies, where each domain can establish its own criteria for selecting routes. This argument was made earlier with respect to source route selection ([IDPR90, Clark90, Breslau-Estrin91]). In addition, each intermediate transit domain must have the flexibility to apply its own selection criteria to the routes made available to it by its neighbors. This is really just a corollary to the above; i.e., if we allow route selection policy to be expressed for NR routes, we can not assume all domains will apply the same policy. The support for dissimilar route selection policies is one of the key factors that distinguish inter-domain routing from intra-domain routing ([ECMA89, Estrin89]). However, it is a non-goal of the architecture to support all possible route selection policies. For more on unsupported route selection policies see Section 2.3.2 below.
ルート選択方針は、各ドメインが複数のルートの中で特定のルートを同じ目的地に選択するのを可能にします。 ドメインの間の最大の自治と独立を維持するために、構造は異種のルート選択方針を支持しなければなりません。そこでは、各ドメインがそれ自身のルートを選択する評価基準を確立できます。 この議論を送信元経路選択([IDPR90、Clark90、ブレスラウ-Estrin91])に関して、より早くしました。 さらに、それぞれの中間的トランジットドメインには、隣人でそれに利用可能にされたルートにそれ自身の選択評価基準を適用する柔軟性がなければなりません。 これは本当にただ上記での推論です。 すなわち、ルート選択方針がNRルートに言い表されるのを許容するなら、私たちは、すべてのドメインが同じ方針を適用すると思うことができません。 異なったルート選択方針のサポートはイントラドメインルーティング([ECMA89、Estrin89])と相互ドメインルーティングを区別する主要因の1つです。 しかしながら、それはすべての可能なルート選択方針を支持する構造の非目標です。 サポートされないルート選択方針の以上に関しては、セクション2.3.2未満を見てください。
2.3.1 Routing Information Hiding
2.3.1 ルート設定情報隠蔽
The architecture should not require all domains within an internet to reveal their connectivity and transit constraints to each other. Domains should be able to enforce their transit policies while limiting the advertisement of their policy and connectivity information as much as possible; such advertisement will be driven by a "need to know" criteria. Moreover, advertising a transit policy to domains that can not use this policy will increase the amount of routing information that must be stored, processed, and propagated. Not only may it be impractical for a router to maintain full inter- domain topology and policy information, it may not be permitted to
構造は、それらの接続性とトランジット規制を互いに明らかにするためにインターネットの中ですべてのドメインを必要とするべきであるというわけではありません。 ドメインはそれらの方針と接続性情報の広告をできるだけ制限している間、それらの運送保険証券を実施できるべきです。 そのような広告は「知る必要性」評価基準によって動かされるでしょう。 そのうえ、この方針を使用できないドメインに運送保険証券の広告を出すと、格納されて、処理されて、伝播しなければならないルーティング情報の量は増加するでしょう。 単にルータが完全な相互ドメイントポロジーと方針情報を保守するように非実用的でありますように、ではなく、それは受入れられないかもしれません。
Estrin, Rekhter & Hotz [Page 9] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[9ページ]RFC1322
obtain this information.
この情報を得てください。
2.3.2 Policies Not Supported
2.3.2 支持されなかった方針
In this and previous papers we have argued that a global inter-domain routing architecture should support a wide range of policies. In this section we identify several types of policy that we explicitly do not propose to support. In general our reasoning is pragmatic; we think such policy types are either very expensive in terms of overhead, or may lead to routing instabilities.
これと前の書類では、私たちは、グローバルな相互ドメインルーティング構造がさまざまな方針を支持するべきであると主張しました。 このセクションで、私たちは支持するよう明らかに提案しないいくつかのタイプの方針を特定します。 一般に、私たちの推理は実践的です。 私たちは、そのような方針タイプがオーバーヘッドで非常に高価であると思うか、または不安定性を発送するのに通じるかもしれません。
1. Route selection policies contingent on external behavior.
The route selection process may be modeled by a function that
assigns a non-negative integer to a route, denoting the degree
of preference. Route selection applies this function to all
feasible routes to a given destination, and selects the route
with the highest value. To provide a stable environment, the
preference function should not use as an input the status and
attributes of other routes (either to the same or to a
different destination).
1. 外部の振舞い次第で選択方針を発送してください。 ルート選択の過程は非負の整数をルートに割り当てる機能によってモデル化されるかもしれません、好みの度合いを指示して。 ルート選択は、与えられた目的地へのすべての可能なルートにこの機能を適用して、最も高い値でルートを選択します。 安定環境を提供するために、選択関数は入力として他のルート(同じくらい、または、異なった目的地への)の状態と属性を使用するべきではありません。
2. Transit policies contingent on external behavior.
To provide a stable environment, the domain's transit policies
can not be automatically affected by any information external
to the domain. Specifically, these policies can not be modified,
automatically, in response to information about other domains'
transit policies, or routes selected by local or other domains.
Similarly, transit policies can not be automatically modified
in response to information about performance characteristics of
either local or external domains.
2. 外部の振舞い次第で運送保険証券。 安定環境を提供するために、ドメインの運送保険証券はそのドメインへの外部のどんな情報でも自動的に影響を受けることができません。 明確に、自動的に他のドメインの運送保険証券、または地方の、または、他のドメインによって選択されたルートの情報に対応してこれらの方針を変更できません。 同様に、自動的に地方の、または、外部のドメインの性能の特性の情報に対応して運送保険証券を変更できません。
3. Policies contingent on external state (e.g., load).
It is a non-goal of the architecture to support load-sensitive
routing for generic routes. However, it is possible that some
types of service may employ load information to select among
alternate SDR routes.
3. 外部次第で方針は(例えば、負荷)を述べます。 それは負荷敏感なルーティングを一般的なルートに支持する構造の非目標です。 しかしながら、何人かのタイプのサービスが交互のSDRルートの中で選択する負荷情報を使うのは、可能です。
4. Very large number of simultaneous SDR routes.
It is a non-goal of the architecture to support a very large
number of simultaneous SDR routes through any single router.
Specifically, the FIB storage overhead associated with SDR
routes must be comparable with that of NR routes, and should
always be bound by the complexity requirements outlined earlier
[Foonote: As discussed earlier, theoretically the state overhead
could grow O(N^2) with the number of domains in an internet.
However, there is no evidence or intuition to suggest that
this will be a limiting factor on the wide utilization of SDR,
provided that NR is available to handle generic routes.].
4. 非常に多くの同時のSDRルート。 それはどんなただ一つのルータを通しても非常に多くの同時のSDRルートを支える構造の非目標です。 明確に、SDRルートに関連しているFIB格納オーバーヘッドは、NRルートのものに匹敵していなければならなくて、より早く概説された複雑さ要件によっていつも縛られるべきです。[Foonote: 以前に検討したことであるが、インターネットにおける、ドメインの数に従って、理論的に、州のオーバーヘッドはO(N^2)を育てるかもしれません。 しかしながら、これがSDRの広い利用に関する限定因子になると示唆するために、どんな証拠も直観もありません、NRが一般的なルートを扱うために利用可能であれば。].
Estrin, Rekhter & Hotz [Page 10] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[10ページ]RFC1322
2.4 Support for TOS Routing
2.4 TOSルート設定のサポート
Throughout this document we refer to support for type of service (TOS) routing. There is a great deal of research and development activity currently underway to explore network architectures and protocols for high-bandwidth, multimedia traffic. Some of this traffic is delay sensitive, while some requires high throughput. It is unrealistic to assume that a single communication fabric will be deployed homogeneously across the internet (including all metropolitan, regional, and backbone networks) that will support all types of traffic uniformly. To support diverse traffic requirements in a heterogeneous environment, various resource management mechanisms will be used in different parts of the global internet (e.g., resource reservation of various kinds) [ST2-90, Zhang91].
このドキュメント中では、私たちはサービス(TOS)ルーティングのタイプのサポートについて言及します。 高帯域(マルチメディア交通)には現在ネットワークアーキテクチャとプロトコルを探るためには進行中の大きな研究開発活動があります。 この交通のいくつかが遅れ敏感ですが、或るものは高生産性を必要とします。 ただ一つのコミュニケーション織物が一様にすべてのタイプの交通を支持するインターネット(すべて首都であって、地方で包含して、背骨ネットワーク)の向こう側に等質的に配備されると仮定するのは非現実的です。 異機種混在環境におけるさまざまの交通要件を支持するために、様々な資源管理メカニズムはグローバルなインターネット(例えば、様々な種類の資源予約)[ST2-90、Zhang91]の異なった部品で使用されるでしょう。
In this context, it is the job of routing protocols to locate routes that can potentially support the particular TOS requested. It is explicitly not the job of the general routing protocols to locate routes that are guaranteed to have resources available at the particular time of the route request. In other words, it is not practical to assume that instantaneous resource availability will be known at all remote points in the global internet. Rather, once a TOS route has been identified, an application requiring particular service guarantees will attempt to use the route (e.g., using an explicit setup message if so required by the underlying networks). In Section 4 we describe additional services that may be provided to support more adaptive route selection for special TOS [Footnote: Adaptive route selection implies adaptability only during the route selection process. Once a route is selected, it is not going to be a subject to any adaptations, except when it becomes infeasible.].
このような関係においては、潜在的に要求された特定のTOSを支持できるルートの場所を見つけるのは、ルーティング・プロトコルの仕事です。 明らかに、保証されるルートの場所を見つける一般的なルーティング・プロトコルのいずれの仕事にもルート要求の特定の時に利用可能なリソースがないということです。 言い換えれば、瞬時に起こっているリソースの有用性がすべての遠隔点でグローバルなインターネットで知られていると仮定するのは実用的ではありません。 むしろ、TOSルートがいったん特定されると、特定のサービス保証を必要とするアプリケーションは、ルートを使用するのを試みるでしょう(例えば、そうだとすれば、明白なセットアップメッセージを使用するのが基本的なネットワークが必要です)。 セクション4では、私たちは特別なTOSのために、より適応型のルート選択を支持するために提供されるかもしれない追加サービスについて説明します。[以下に脚注をつけてください。 適応型のルート選択はルート選択の過程だけの間適応性を含意します。 ルートがいったん選択されると、どんな適合への対象でなくもなるでしょう、それが実行不可能になる時を除いて。].
2.5 Commonality between Routing Components
2.5 ルート設定コンポーネントの間の共通点
While it is acceptable for the NR and SDR components to be dissimilar, we do recognize that such a solution is less desirable -- all other things being equal. In theory, there are advantages in having the NR and SDR components use similar algorithms and mechanisms. Code and databases could be shared and the architecture would be more manageable and comprehensible. On the other hand, there may be some benefit (e.g., robustness) if the two parts of the architecture are heterogeneous, and not completely inter-dependent. In Section 5 we list several areas in which opportunities for increased commonality (unification) will be exploited.
NRとSDRの部品が異なるのが、許容できる間、私たちは、そのような解決策はそれほど望ましくはありません--他のすべての等しいものと認めます。 理論上、NRとSDRの部品に同様のアルゴリズムとメカニズムを使用させるのにおいて利点があります。構造は、よりコードとデータベースを共有できて、処理しやすくて、分かりやすいでしょう。 他方では、構造の2箇所が異種であって、完全に互いに依存しているというわけではないなら、何らかの利益(例えば、丈夫さ)があるかもしれません。 セクション5では、私たちは増加する共通点(統一)の機会が利用されるいくつかの領域を記載します。
2.6 Interaction with Addressing
2.6 アドレシングとの相互作用
The proposed architecture should be applicable to various addressing schemes. There are no specific assumptions about a particular
提案された構造は様々なアドレシング計画に適切であるべきです。 事項に関するどんな特定の仮定もありません。
Estrin, Rekhter & Hotz [Page 11] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[11ページ]RFC1322
address structure, except that this structure should facilitate information aggregation, without forcing rigid hierarchical routing.
この構造が堅い階層型ルーティングを強制しないで情報集合を容易にするはずであるのを除いて、構造を記述してください。
Beyond this requirement, most of the proposals for extending the IP address space, for example, can be used in conjunction with our architecture. But our architecture itself does not provide (or impose) a particular solution to the addressing problem.
この要件を超えて、私たちの構造に関連して例えば、IPアドレス空間を広げるための提案の大部分を使用できます。 しかし、私たちの構造自体はアドレシング問題の特殊解を提供しません(でしゃばってください)。
Estrin, Rekhter & Hotz [Page 12] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[12ページ]RFC1322
3.0 Design Choices for Node Routing (NR)
3.0 ノードルート設定のためのデザイン選択(NR)
This section addresses the design choices made for the NR component in light of the above architectural requirements and priorities. All of our discussion of NR assumes hop-by-hop routing. Source routing is subject to different constraints and is used for the complementary SDR component.
このセクションは上記の建築要件とプライオリティの観点からNRの部品のためにされたデザイン選択を記述します。 私たちのNRの議論のすべてがホップごとのルーティングを仮定します。 ソースルーティングは、異なった規制をなることがあって、補足的なSDRの部品に使用されます。
3.1 Overview of NR
3.1 NRの概観
The NR component is designed and optimized for an environment where a large percentage of packets will travel over routes that can be shared by multiple sources and that have predictable traffic patterns. The efficiency of the NR component improves when a number of source domains share a particular route from some intermediate point to a destination. Moreover, NR is best suited to provide routing for inter-domain data traffic that is either steady enough to justify the existence of a route, or predictable, so that a route may be installed when needed (based on the prediction, rather than on the actual traffic). Such routes lend themselves to distributed route computation and installation procedures.
NRの部品は、パケットの大きな割合が複数のソースが共有できて、予測できるトラフィック・パターンを持っているルートの上を移動するところで設計されていて、環境のために最適化されます。 多くのソースドメインが何らかの中間的ポイントから目的地まで特定のルートを共有するとき、NRの部品の効率は向上します。 そのうえ、ルートの存在を正当化できるくらい安定したか、または予測できる相互ドメインデータ通信量のためのルーティングを提供するためにNRに合うのが最も良い、必要であると(実際の交通に関してというよりむしろ予測に基づいて)ルートをインストールできるように。 そのようなルートは分配された経路計算と据え付け要領に自分たちを与えます。
Routes that are installed in routers, and information that was used by the routers to compute these routes, reflect the known operational state of the routing facilities (as well as the policy constraints) at the time of route computation. Route computation is driven by changes in either operational status of routing facilities or policy constraints. The NR component supports route computation that is dynamically adaptable to both changes in topology and policy. The NR component allows time-dependent selection or deletion of routes. However, time dependency must be predictable (e.g., advertising a certain route only after business hours) and routes should be used widely enough to warrant inclusion in NR.
ルータにインストールされるルート、およびルータによって使用された、これらのルートを計算した情報は経路計算時点で、ルーティング施設(方針規制と同様に)の知られている操作上の状態を反映します。 経路計算はルーティング施設の操作上の状態か方針規制のどちらかにおける変化によって追い立てられます。 NRの部品はダイナミックにトポロジーの変化と方針の両方に適合できる経路計算を支持します。 NRの部品はルートの時間依存する選択か削除を許します。 しかしながら、時間の依存は予測できるに違いありません、そして、(例えば、営業時間後にだけある一定のルートの広告を出します)ルートはNRでの包含を保証できるくらい広く使用されるべきです。
The proposed architecture assumes that most of the inter-domain conversations will be forwarded via routes computed and installed by the NR component.
提案された構造は、相互ドメインの会話の大部分がNRの部品によって計算されて、インストールされたルートで進められると仮定します。
Moreover, the exchange of routing information necessary for the SDR component depends on facilities provided by the NR component; i.e., NR policies must allow SDR reachability information to travel. Therefore, the architecture requires that all domains in an internet implement and participate in NR. Since scalability (with respect to the size of the internet) is one of the fundamental requirements for the NR component, it must provide multiple mechanisms with various degrees of sophistication for information aggregation and abstraction.
そのうえ、SDRの部品に必要なルーティング情報の交換はNRの部品によって提供された施設によります。 すなわち、NR方針で、SDR可到達性情報は移動しなければなりません。 したがって、構造は、インターネットにおけるすべてのドメインがNRを実行して、参加するのを必要とします。 スケーラビリティ(インターネットのサイズに関する)がNRの部品のための基本的な要件の1つであるので、それは情報集合と抽象化のための様々な度の洗練を複数のメカニズムに提供しなければなりません。
Estrin, Rekhter & Hotz [Page 13] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[13ページ]RFC1322
The potential reduction of routing and forwarding information depends very heavily on the way addresses are assigned and how domains and their confederations are structured. "If there is no correspondence between the address registration hierarchy and the organisation of routeing domains, then ... each and every routeing domain in the OSIE would need a table entry potentially at every boundary IS of every other routeing domain" ([Oran89]). Indeed, scaling in the NR component is almost entirely predicated on the assumption that there will be general correspondence between the hierarchy of address assignment authorities and the way routing domains are organised, so that the efficient and frequent aggregation of routing and forwarding information will be possible. Therefore, given the nature of inter- domain routing in general, and the NR component in particular, scalability of the architecture depends very heavily on the flexibility of the scheme for information aggregation and abstraction, and on the preconditions that such a scheme imposes. Moreover, given a flexible architecture, the operational efficiency (scalability) of the global internet, or portions thereof, will depend on tradeoffs made between flexibility and aggregation.
ルーティングと推進情報の潜在的減少は非常に大いにアドレスが割り当てられる方法とドメインと彼らの同盟者がどう構造化されるかによります。 「ドメイン、… それぞれその時、およびOSIEのあらゆるrouteingドメインが必要とするrouteingのアドレス登録階層構造と機構との通信が全くなければ、テーブル項目は潜在的にあらゆる境界の他のあらゆるrouteingドメインのそうです。」([Oran89]) 本当に、NRの部品を計量するのはアドレス課題当局の階層構造と経路ドメインが組織化されている方法との一般的な通信があるという前提でほぼ完全に叙述されます、ルーティングと推進情報の効率的で頻繁な集合が可能になるように。 したがって、一般に、相互ドメインルーティングの本質、および特にNRの部品を考えて、構造のスケーラビリティは非常に大いに情報集合と抽象化の計画の柔軟性と、そして、そのような計画が課す前提条件に依存します。 そのうえ、フレキシブルな構造を考えて、グローバルなインターネット、またはそれの部分の経営効率(スケーラビリティ)は柔軟性と集合の間で作られた見返りに依存するでしょう。
While the NR component is optimized to satisfy the common case routing requirements for an extremely large population of users, this does not imply that routes produced by the NR component would not be used for different types of service (TOS). To the contrary, if a TOS becomes sufficiently widely used (i.e., by multiple domains and predictably over time), then it may warrant being computed by the NR component.
NRの部品がユーザの非常に大きい人口のためのよくある例ルーティング要件を満たすために最適化されている間、これは、NRの部品によって作成されたルートが異なったタイプのサービス(TOS)に使用されないのを含意しません。 それと反対に、TOSが十分広く使用されるように(すなわち、予想どおりに複数のドメインと時間の上間)なるなら、それは、NRの部品によって計算されるのを保証するかもしれません。
To summarize, the NR component is best suited to provide routes that are used by more than a single domain. That is, the efficiency of the NR component improves when a number of source domains share a particular route from some intermediate point to a destination. Moreover, NR is best suited to provide routing for inter-domain data traffic that is either steady enough to justify the existence of a route, or predictable, so that a route may be installed when needed, (based on the prediction, rather than on the actual traffic).
まとめるために合う、単一領域以上によって使用されるルートを提供するためにNRの部品に合うのは最も良いです。 多くのソースドメインが何らかの中間的ポイントから目的地まで特定のルートを共有するとき、すなわち、NRの部品の効率は向上します。 そのうえ、必要であるとルートをインストールできるようにルートの存在を正当化できるくらい安定したか、または予測できる相互ドメインデータ通信量(実際の交通に関してというよりむしろ予測に基づいた)のためのルーティングを提供するためにNRに合うのは最も良いです。
3.2 Routing Algorithm Choices for NR
3.2 NRのためのルーティング・アルゴリズム選択
Given that a NR component based on hop-by-hop routing is needed to provide scalable, efficient inter-domain routing, the remainder of this section considers the fundamental design choices for the NR routing algorithm.
ホップごとのルーティングに基づいたNRの部品がスケーラブルで、効率的な相互ドメインルーティングを提供するのに必要であるなら、このセクションの残りはNRルーティング・アルゴリズムのための基本的なデザイン選択を考えます。
Typically the debate surrounding routing algorithms focuses on link state and distance vector protocols. However, simple distance vector protocols (i.e., Routing Information Protocol [Hedrick88]), do not scale because of convergence problems. Improved distance vector
通常、ルーティング・アルゴリズムを囲む討論はリンク状態と距離ベクトルプロトコルに焦点を合わせます。 簡単な距離ベクトルプロトコル(すなわち、ルーティング情報プロトコル[Hedrick88])、しかしながら、集合問題改良された距離ベクトルのために、比例しないでください。
Estrin, Rekhter & Hotz [Page 14] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[14ページ]RFC1322
protocols, such as those discussed in [Jaffee82, Zaumen91, Shin87], have been developed to address this issue using synchronization mechanisms or additional path information. In the case of inter- domain routing, having additional path information is essential to supporting policy. Therefore, the algorithms we consider for NR are link state and one we call path vector (PV). Whereas the characteristics of link state algorithms are generally understood (for example, [Zaumen 91]), we must digress from our evaluation discussion to describe briefly the newer concept of the PV algorithm [Footnote: We assume that some form of SPF algorithm will be used to compute paths over the topology database when LS algorithms are used [Dijkstra59, OSPF]].
同期メカニズムか追加経路情報を使用することでこの問題を記述するために[Jaffee82、Zaumen91、Shin87]で議論するものなどのプロトコルを開発してあります。 相互ドメインルーティングの場合では、追加経路情報を持っているのは方針を支持するのに不可欠です。 私たちがNRのために考えるアルゴリズムは、その結果、私たちがリンク状態を呼んで、経路ベクトル(PV)と呼ぶものです。 リンク州のアルゴリズムの特性は一般に理解されていますが(例えば、[Zaumen91])、私たちは、簡潔にPVアルゴリズムの、より新しい概念について説明するために私たちの評価議論から脱線しなければなりません[脚注: 私たちは、何らかのフォームのSPFアルゴリズムがLSアルゴリズムが使用されているとき[Dijkstra59、OSPF]、トポロジーデータベースに関して経路を計算するのに使用されると思います]。
3.2.1 Path Vector Protocol Overview
3.2.1 経路ベクトルプロトコル概観
The Border Gateway Protocol (BGP) (see [BGP91]) and the Inter Domain Routing Protocol (IDRP) (see [IDRP91]) are examples of path vector (PV) protocols [Footnote: BGP is an inter-autonomous system routing protocol for TCP/IP internets. IDRP is an OSI inter-domain routing protocol that is being progressed toward standardization within ISO. Since in terms of functionality BGP represents a proper subset of IDRP, for the rest of the paper we will only consider IDRP.].
ボーダ・ゲイトウェイ・プロトコル(BGP)([BGP91]を見る)とInter Domainルート設定プロトコル(IDRP)([IDRP91]を見る)は経路ベクトル(PV)プロトコルに関する例です。[以下に脚注をつけてください。 BGPはTCP/IPインターネットのための相互自律システムルーティング・プロトコルです。 IDRPはISOの中の標準化に向かって進行されているOSI相互ドメインルーティング・プロトコルです。 BGPが機能性に関してIDRPの真部分集合を表すので、紙の残りのために、私たちはIDRPを考えるだけです。].
The routing algorithm employed by PV bears a certain resemblance to the traditional Bellman-Ford routing algorithm in the sense that each border router advertises the destinations it can reach to its neighboring BRs. However,the PV routing algorithm augments the advertisement of reachable destinations with information that describes various properties of the paths to these destinations.
PVによって使われたルーティング・アルゴリズムは各境界ルータがそれが隣接しているBRsに達することができる目的地の広告を出すという意味における伝統的なBellman-フォードルーティング・アルゴリズムとのある類似を持っています。 しかしながら、PVルーティング・アルゴリズムは経路の様々な特性についてこれらの目的地に説明する情報がある届いている目的地の広告を増大させます。
This information is expressed in terms of path attributes. To emphasize the tight coupling between the reachable destinations and properties of the paths to these destinations, PV defines a route as a pairing between a destination and the attributes of the path to that destination. Thus the name, path-vector protocol, where a BR receives from its neighboring BR a vector that contains paths to a set of destinations [Footnote: The term "path-vector protocol" bears an intentional similarity to the term "distance-vector protocol", where a BR receives from each of its neighbors a vector that contains distances to a set of destinations.]. The path, expressed in terms of the domains (or confederations) traversed so far, is carried in a special path attribute which records the sequence of routing domains through which the reachability information has passed. Suppression of routing loops is implemented via this special path attribute, in contrast to LS and distance vector which use a globally-defined monotonically-increasing metric for route selection [Shin87].
この情報は経路属性で言い表されます。 経路の届いている目的地と所有地の間の密結合をこれらの目的地に強調するために、PVはその目的地への経路の目的地と属性の間の組み合わせとルートを定義します。 その結果、名前、経路ベクトルプロトコル。(そこでは、BRが隣接しているBRから1セットの目的地に経路を含むベクトルを受けます[脚注: 「経路ベクトルプロトコル」という用語には、BRが隣人各人から1セットの目的地に距離を含むベクトルを受ける「距離ベクトルプロトコル」という用語まで意図的な類似性があります。])。 今までのところ横断されているドメイン(または、同盟者)で言い表された経路は可到達性情報が終わった経路ドメインの系列を記録する特別な経路属性で運ばれます。 ルーティング輪の抑圧はこの特別な経路属性で実行されます、グローバルに定義されたルートにおいてメートル法で単調に増加する選択[Shin87]を使用するLSと距離ベクトルと対照して。
Because PV does not require all routing domains to have homogeneous
PVが、均質の状態で持っているドメインをすべて発送するのを必要としないので
Estrin, Rekhter & Hotz [Page 15] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[15ページ]RFC1322
criteria (policies) for route selection, route selection policies used by one routing domain are not necessarily known to other routing domains. To maintain the maximum degree of autonomy and independence between routing domains, each domain which participates in PV may have its own view of what constitutes an optimal route. This view is based solely on local route selection policies and the information carried in the path attributes of a route. PV standardizes only the results of the route selection procedure, while allowing the selection policies that affect the route selection to be non-standard [Footnote: This succinct observation is attributed to Ross Callon (Digital Equipment Corporation).].
ルート選択の評価基準(方針)、1つの経路ドメインによって使用されるルート選択方針は必ず他の経路ドメインに知られているというわけではありません。 経路ドメインの間の最大の度の自治と独立を維持するために、PVに参加する各ドメインは最適のルートを構成することに関するそれ自身の意見を持っているかもしれません。 この視点は唯一ルートの経路属性で運ばれたローカルのルート選択方針と情報に基づいています。 ルート選択に影響する選択方針が標準的でないのを許容している間、PVはルート選択手順の結果だけを標準化します[脚注: この簡潔な観測はロスCallon(DEC)の結果と考えられます。]。
3.3 Complexity
3.3 複雑さ
Given the above description of PV algorithms, we can compare them to LS algorithms in terms of the three complexity parameters defined earlier.
PVアルゴリズムの上の記述を考えて、私たちは、より早く定義された3つの複雑さパラメタに関してLSアルゴリズムとそれらを比較できます。
3.3.1 Storage Overhead
3.3.1 格納オーバーヘッド
Without any aggregation of routing information, and ignoring storage overhead associated with transit constraints, it is possible to show that under some rather general assumptions the average case RIB storage overhead of the PV scheme for a single TOS ranges between O(N) and O(Nlog(N)), where N is the total number of routing domains ([Rekhter91]). The LS RIB, with no aggregation of routing information, no transit constraints, a single homogeneous route selection policy across all the domains, and a single TOS, requires a complete domain-level topology map whose size is O(N).
ルーティング情報のどんな集合とも、トランジット規制に関連している格納オーバーヘッドを無視しないで、いくつかのかなり一般的な仮定で、独身のTOSのPV計画の平均したケースRIB格納オーバーヘッドがO(N)とO(Nが経路ドメイン[Rekhter91]の総数であるところのNlog(N)))の間で及ぶのを示すのは可能です。 ルーティング情報の集合のないLS RIB(トランジット規制がなく、すべてのドメイン中のただ一つの均質のルート選択方針、および独身のTOS)はサイズがO(N)である完全なドメインレベルトポロジー地図を必要とします。
Supporting heterogeneous route selection and transit policies with hop-by-hop forwarding and LS requires each domain to know all other domains route selection and transit policies. This may significantly increase the amount of routing information that must be stored by each domain. If the number of policies advertised grows with the number of domains, then the storage could become unsupportable. In contrast, support for heterogeneous route selection policies has no effect on the storage complexity of the PV scheme (aside from simply storing the local policy information). The presence of transit constraints in PV results in a restricted distribution of routing information, thus further reducing storage overhead. In contrast, with LS no such reduction is possible since each domain must know every other domain's transit policies. Finally, some of the transit constraints (e.g., path sensitive constraints) can be expressed in a more concise form in PV (see aggregation discussion below).
ホップごとの推進とLSと共に異種のルート選択と運送保険証券を支持するのは、他のすべてのドメインが選択と運送保険証券を発送するのを知るために各ドメインを必要とします。 これは各ドメインで格納しなければならないルーティング情報の量をかなり増加させるかもしれません。 ドメインの数に応じて広告に掲載された方針の数が成長するなら、格納は支持できなくなるかもしれません。 対照的に、異種のルート選択方針のサポートはPV計画(単にローカルの方針情報を格納することは別として)の格納の複雑さで効き目がありません。 PVでのトランジット規制の存在はルーティング情報の制限された分配をもたらして、その結果、さらに格納オーバーヘッドを下げます。 各ドメインが他のあらゆるドメインの運送保険証券を知らなければならないので、対照的に、LSでは、そのようなどんな減少も可能ではありません。 最終的に、PVの、より簡潔なフォームでトランジット規制(例えば、経路の敏感な規制)のいくつかを言い表すことができます(以下での集合議論を見てください)。
The ability to further restrict storage overhead is facilitated by the PV routing algorithm, where route computation precedes routing
さらに格納オーバーヘッドを制限する能力はPVルーティング・アルゴリズムで促進されます。そこでは、経路計算がルーティングに先行します。
Estrin, Rekhter & Hotz [Page 16] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[16ページ]RFC1322
information dissemination, and only routing information associated with the routes selected by a domain is distributed to adjacent domains. In contrast, route selection with LS is decoupled from the distribution of routing information, and has no effect on such distribution.
情報普及、およびドメインによって選択されるルートに関連している情報がドメインに隣接して分配されるルーティングだけ。 対照的に、LSとのルート選択は、ルーティング情報の分配から衝撃を吸収されて、そのような分配のときに効き目がありません。
While theoretically routing information aggregation can be used to reduce storage complexity in both LS and PV, only aggregation of topological information would yield the same gain for both. Aggregating transit constraints with LS may result in either reduced connectivity or less information reduction, as compared with PV. Aggregating heterogeneous route selection policies in LS is highly problematic, at best. In PV, route selection policies are not distributed, thus making aggregation of route selection policies a non-issue [Footnote: Although a domain's selection policies are not explicitly distributed, they have an impact on the routes available to other domains. A route that may be preferred by a particular domain, and not prohibited by transit restrictions, may still be unavailable due to the selection policies of some intermediate domain. The ability to compute and install alternative routes that may be lost using hop-by-hop routing (either LS of PV) is the critical functionality provided by SDR.].
LSとPVの両方で格納の複雑さを減少させるのに理論的に情報集合を発送するのを使用できる間、位相的な情報の唯一の集合が両方のための同じ利得を譲るでしょう。 LSとの規制がもたらすかもしれないトランジットに集めるのはPVと比べて接続性か、より少ない情報減少を減らしました。 LSの異種のルート選択方針に集めるのはせいぜい非常に問題が多いです。 PVでは、ルート選択方針は、分配されて、その結果、ルート選択方針の集合をどうでもいい問題にしないことです。[以下に脚注をつけてください。 ドメインの選択方針は明らかに分配されませんが、それらは他のドメインに利用可能なルートに影響を与えます。 特定のドメインによって好まれて、トランジット制限で禁止されないかもしれないルートは何らかの中間的ドメインの選択方針でまだ入手できないかもしれません。 ホップごとのルーティング(PVのLS)を使用することでなくされるかもしれない代替のルートを計算して、インストールする能力はSDRによって提供された重大な機能性です。].
Support for multiple TOSs has the same impact on storage overhead for both LS and for PV.
複数のTOSsのサポートには、両方のLSとPVのための格納オーバーヘッドへの同じ影響力があります。
Potentially the LS FIB may be smaller if routes are computed at each node on demand. However, the gain of such a scheme depends heavily on the traffic patterns, memory size, and caching strategy. If there is not a high degree of locality, severely degraded performance can result due to excessive overall computation time and excessive computation delay when forwarding packets to a new destination. If demand driven route computation is not used for LS, then the size of the FIB would be the same for both LS and PV.
潜在的に、ルートがオンデマンドのそれぞれのノードで計算されるなら、LS FIBは、より小さいかもしれません。 しかしながら、そのような計画の獲得は大いにトラフィック・パターンと、記憶容量と、戦略をキャッシュするのに依存します。 過度の総合的な計算時間と過度の計算遅れのため、新しい目的地にパケットを送るとき、高度の場所がなければ、厳しく降格している性能は結果として生じることができます。 要求であるなら、駆動経路計算はLSに使用されないで、LSとPVの両方には、次に、FIBのサイズは同じでしょう。
Estrin, Rekhter & Hotz [Page 17] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[17ページ]RFC1322
3.3.2 Route Computation Complexity
3.3.2 経路計算の複雑さ
Even if all domains employ exactly the same route selection policy, computational complexity of PV is smaller than that of LS. The PV computation consists of evaluating a newly arrived route and comparing it with the existing one [Footnote: Some additional checks are required when an update is received to insure that a routing loop has not been created.]. Whereas, conventional LS computation requires execution of an SPF algorithm such as Dijkstra's.
すべてのドメインがまさに同じルート選択方針を使っても、PVの計算量はLSのものより小さいです。 PV計算は新たに到着したルートを評価して、既存のものとそれを比べるのから成ります[脚注: ルーティング輪が作成されていないのを保障するためにアップデートを受けるとき、いくつかの追加チェックを必要とします。]。 ところが、従来のLS計算はダイクストラなどのSPFアルゴリズムの実行を必要とします。
With PV, topology changes only result in the recomputation of routes affected by these changes, which is more efficient than complete recomputation. However, because of the inclusion of full path information with each distance vector, the effect of a topology change may propagate farther than in traditional distance vector algorithms. On the other hand, the number of affected domains will still be smaller with PV than with conventional LS hop-by-hop routing. With PV, only those domains whose routes are affected by the changes have to recompute, while with conventional LS hop-by-hop routing all domains must recompute. While it is also possible to employ partial recomputation with LS (i.e., when topology changes, only the affected routes are recomputed), "studies suggest that with a very small number of link changes (perhaps 2) the expected computational complexity of the incremental update exceeds the complete recalculation" ([ANSI87-150R]). However these checks are much simpler than executing a full SPF algorithm.
PVと共に、トポロジー変化はこれらの変化で影響を受けるルートの再計算をもたらすだけです。(再計算は完全な再計算より効率的です)。 しかしながら、各距離ベクトルがあるフルパス情報の包含のために、トポロジー変化の効果は伝統的な距離ベクトルアルゴリズムより遠くに伝播されるかもしれません。他方では、影響を受けるドメインの数はまだPVと共にホップごとの従来のLSルーティングより少なくなっているでしょう。 PVと共に、ルートが変化で影響を受けるそれらのドメインだけがrecomputeにそうしましたが、すべてのドメインはホップごとの従来のLSルーティングでrecomputeがそうしなければなりません。 また、LSがある部分的な再計算を使うのも可能である間(すなわち、トポロジーが変化するとき、影響を受けるルートだけが再計算されます)、「研究は、非常に少ない数のリンク変化(恐らく2)に応じて、アップデート増加の予想された計算量が完全な再計算を超えているのを示す」([ANSI87-150R])。 しかしながら、これらのチェックは完全なSPFアルゴリズムを実行するよりはるかに簡単です。
Support for heterogeneous route selection policies has serious implications for the computational complexity. The major problem with supporting heterogeneous route selection policies with LS is the computational complexity of the route selection itself. Specifically, we are not aware of any algorithm with less than exponential time complexity that would be capable of computing routes to all destinations, with LS hop-by-hop routing and heterogeneous route selection policies. In contrast, PV allows each domain to make its route selection autonomously, based only on local policies. Therefore support for dissimilar route selection policies has no negative implications for the complexity of route computation in PV. Similarly, providing support for path-sensitive transit policies in LS implies exponential computation, while in PV such support has no impact on the complexity of route computation.
異種のルート選択方針のサポートには、計算量のための重大な意味があります。 LSと共に異種のルート選択方針を支持することに関する大した問題はルート選択自体の計算量です。 明確に、私たちはすべての目的地にルートを計算できる指数時間の複雑さ以下でどんなアルゴリズムも意識していません、ホップごとのLSルーティングと異種のルート選択方針で。 対照的に、PVは各ドメインにローカルの方針だけに基づいて、ルート選択を自主的にさせます。 したがって、異なったルート選択方針のサポートには、PVの経路計算の複雑さのためのマイナス要素が全くありません。 同様に、LSの経路敏感な運送保険証券のサポートを提供すると、指数の計算は含意されます、そのようなサポートがPVで経路計算の複雑さに変化も与えませんが。
In summary, because NR will rely primarily on precomputation of routes, aggregation is essential to the long-term scalability of the architecture. To the extent aggregation is facilitated with PV, so is reduced computational complexity. While similar arguments may be made for LS, the aggregation capabilities that can be achieved with LS are more problematic because of LS' reliance on consistent
概要では、NRが主としてルートの前計算を当てにするので、集合は構造の長期のスケーラビリティに不可欠です。 範囲に、集合はPVと共に容易にされて、減少している計算量もそうです。 LSのために同様の議論をするかもしれませんが、LSと共に達成できる集合能力は一貫することへのLSの信用のために、より問題が多いです。
Estrin, Rekhter & Hotz [Page 18] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[18ページ]RFC1322
topology maps at each node. It is also not clear what additional computational complexity will be associated with aggregation of transit constraints and heterogeneous route selection policies in LS.
各ノードのトポロジー地図。 また、どんな追加計算量がLSのトランジット規制と異種のルート選択方針の集合に関連するかも、明確ではありません。
3.3.3 Bandwidth Overhead
3.3.3 帯域幅オーバーヘッド
PV routing updates include fully-expanded information. A complete route for each supported TOS is advertised. In LS, TOS only contributes a factor increase per link advertised, which is much less than the number of complete routes. Although TOSs may be encoded more efficiently with LS than with PV, link state information is flooded to all domains, while with PV, routing updates are distributed only to the domains that actually use them. Therefore, it is difficult to make a general statement about which scheme imposes more bandwidth overhead, all other factors being equal.
アップデートが含むPVルーティングは情報を完全に広くしました。 それぞれがTOSを支持したので、完全なルートの広告を出します。 LSでは、TOSは1広告に掲載されたリンクあたり1つの要素増加しか寄付しません。(リンクは完全なルートの数よりはるかに少ないです)。 TOSsはPVより効率的にLSと共にコード化されるかもしれませんが、リンク州の情報はすべてのドメインへあふれます、ルーティングアップデートがPVと共に実際にそれらを使用するドメインだけに広げられますが。 したがって、計画が、より多くの帯域幅を課す総論を等しい頭上の、そして、他の要素にするのは難しいです。
Moreover, this is perhaps really not an important difference, since we are more concerned with the number of messages than with the number of bits (because of compression and greater link bandwidth, as well as the increased physical stability of links).
そのうえ、これは恐らく本当に重要な違いではありません、私たちがビット(圧縮とリンクの増加する物理的な安定性と同様により大きいリンク帯域幅による)の数よりメッセージの数に関係があるので。
3.4 Aggregation
3.4 集合
Forming confederations of domains, for the purpose of consistent, hop-by-hop, LS route computation, requires that domains within a confederation have consistent policies. In addition, LS confederation requires that any lower level entity be a member of only one higher level entity. In general, no intra-confederation information can be made visible outside of a confederation, or else routing loops may occur as a result of using an inconsistent map of the network at different domains. Therefore, the use of confederations with hop-by-hop LS is limited because each domain (or confederation) can only be a part of one higher level confederation and only export policies consistent with that confederation (see examples in Section 2.2). These restrictions are likely to impact the scaling capabilities of the architecture quite severely.
一貫している、ホップごとのLS経路計算の目的のためにドメインの同盟者を形成するのは、同盟者の中のドメインには一貫した方針があるのを必要とします。 さらに、LS同盟者は、どんな下のレベル実体も1つのより高い平らな実体だけのメンバーであることを必要とします。 一般に、同盟者の外でイントラ同盟者情報を全く目に見えるようにすることができませんか、または異なったドメインでネットワークの矛盾した地図を使用することの結果、ルーティング輪は現れるかもしれません。 したがって、各ドメイン(または、同盟者)が1人のより高い平らな同盟者の一部だけであり、その同盟者と一致した方針を輸出できるだけであるので(セクション2.2で例を見てください)、ホップごとのLSとの同盟者の使用は限られています。 これらの制限は全く厳しく構造のスケーリング能力に影響を与えそうです。
In comparison, PV can accommodate different confederation definitions because looping is avoided by the use of full path information. Consistent network maps are not needed at each route server, since route computation precedes routing information dissemination. Consequently, PV confederations can be nested, disjoint, or overlapping. A domain (or confederation) can export different policies or TOS as part of different confederations, thus providing the extreme flexibility that is crucial for the overall scaling and extensibility of the architecture.
相対的に、ループがフルパス情報の使用で避けられるので、PVは異なった同盟者定義を収容できます。 経路計算がルーティング情報普及に先行するので、一貫したネットワーク地図はそれぞれのルートサーバで必要ではありません。 その結果、PV同盟者は、入れ子にすることができるか、ばらばらになるか、または重なっています。 ドメイン(または、同盟者)は異なった同盟者の一部として異なった方針かTOSを輸出できます、その結果、構造の総合的なスケーリングと伸展性に、重要な極端な柔軟性を提供します。
In summary, aggregation is essential to achieve acceptable complexity
概要では、集合は、許容できる複雑さを獲得するのに不可欠です。
Estrin, Rekhter & Hotz [Page 19] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[19ページ]RFC1322
bounds, and flexibility is essential to achieve acceptable aggregation across the global, decentralized internet. PV's strongest advantage stems from its flexibility.
領域、および柔軟性はそうです。グローバルで、分散しているインターネットの向こう側に許容集合を達成するために、不可欠です。 PVの最も強い利点は柔軟性によります。
3.5 Policy
3.5方針
The need to allow expression of transit policy constraints on any route (i.e., NR routes as well as SDR routes), by itself, can be supported by either LS or PV. However, the associated complexities of supporting transit policy constraints are noticeably higher for LS than for PV. This is due to the need to flood all transit policies with LS, where with PV transit policies are controlled via restricted distribution of routing information. The latter always imposes less overhead than flooding.
LSかPV自身のどちらかがどんなルート(すなわち、SDRルートと同様にNRルート)における運送保険証券規制の表現を許容する必要性を支持できます。 しかしながら、LSには、運送保険証券規制を支持する関連複雑さはPVより顕著に高いです。 これはPVと共に、運送保険証券がルーティング情報の制限された分配で制御されるLSと共にすべての運送保険証券をあふれさせる必要性のためです。 後者はいつも氾濫より少ないオーバーヘッドを課します。
While all of the transit constraints that can be supported with LS can be supported with PV, the reverse is not true. In other words, there are certain transit constraints (e.g., path-sensitive transit constraints) that are easily supported with PV, and are prohibitively expensive (in terms of complexity) to support in LS. For example, it is not clear how NR with LS could support something like ECMA-style policies that are based on hierarchical relations between domains, while support for such policies is straightforward with PV.
PVと共にLSと共に支持できるトランジット規制のすべてを支持できますが、逆は本当ではありません。 言い換えれば、PVと共に容易に支持された、LSで支持するために法外に高価な(複雑さに関する)あるトランジット規制(例えば、経路の敏感なトランジット規制)があります。 例えば、LSとNRがドメインの階層的な関係に基づいているECMA-スタイル方針のようにどのように何かを支持できたかは、明確ではありません、そのような方針のサポートがPVに簡単ですが。
As indicated above, support for heterogeneous route selection policies, in view of its computational and storage complexity, is impractical with LS hop-by-hop routing. In contrast, PV can accommodate heterogeneous route selection with little additional overhead.
上で示されるように、コンピュータと格納複雑さから見て、異種のルート選択方針のサポートはホップごとのLSルーティングで非実用的です。 対照的に、PVは少ない追加オーバーヘッドがある異種のルート選択を収容できます。
3.6 Information Hiding
3.6 情報隠蔽
PV has a clear advantage with respect to selective information hiding. LS with hop-by-hop routing hinges on the ability of all domains to have exactly the same information; this clearly contradicts the notion of selective information hiding. That is, the requirement to perform selective information hiding is unsatisfiable with LS hop-by-hop routing.
PVには、選択している情報隠蔽に関して明らかに有利な立場があります。 ホップごとのルーティングがあるLSはすべてのドメインにはまさに同じ情報がある能力に依ります。 これは明確に選択している情報隠蔽の概念に矛盾します。 すなわち、選択している情報隠蔽を実行するという要件はホップごとのLSルーティングでunsatisfiableです。
3.7 Commonality between NR and SDR Components
3.7 NRとSDRの部品の間の共通点
In [Breslau-Estrin91] we argued for the use of LS in conjunction with SDR. Therefore there is some preference for using LS with NR. However, there are several reasons why NR and SDR would not use exactly the same routing information, even if they did use the same algorithm. Moreover, there are several opportunities for unifying the management (distribution and storage) of routing and forwarding information, even if dissimilar algorithms are used.
[ブレスラウ-Estrin91]では、私たちはSDRに関連してLSの使用について賛成の議論をしました。したがって、NRとLSを使用するための何らかの好みがあります。 しかしながら、NRとSDRがまさに同じルーティング情報を使用しないいくつかの理由があります、同じアルゴリズムを使用したとしても。 そのうえ、ルーティングと推進情報の管理(分配と格納)を統一するいくつかの機会があります、異なったアルゴリズムが使用されていても。
Estrin, Rekhter & Hotz [Page 20] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[20ページ]RFC1322
In considering the differences between NR and SDR we must address several areas:
NRとSDRの違いを考える際に、私たちはいくつかの領域を記述しなければなりません:
1. Routing information and distribution protocol: LS for SDR is
quite different from the LS in NR. For example, SDR LS need
not aggregate domains; to the contrary SDR LS requires detailed
information to generate special routes.
1. ルート設定情報と分配は議定書を作ります: SDRのためのLSはNRのLSと全く異なっています。 例えば、SDR LSはドメインに集める必要はありません。 それと反対に、SDR LSは、詳細な情報が特別なルートを発生させるのを必要とします。
In addition, consistency requirements (essential for NR) are
unnecessary for the SDR component. Therefore LS information for
the SDR component can be retrieved on-demand, while the NR
component must use flooding of topology information.
さらに、SDRの部品には、一貫性要件(NRに、不可欠の)は不要です。 したがって、要求次第でSDRの部品のためのLS情報を検索できます、NRの部品はトポロジー情報の氾濫を使用しなければなりませんが。
2. Route computation algorithm: It is not clear whether route
computation algorithm(s) can be shared between the SDR and NR
components, given the difficulty of supporting heterogeneous
route selection policies in NR.
2. 計算アルゴリズムを発送してください: SDRとNRの部品の間でルート計算アルゴリズムを共有できるかどうかは明確ではありません、NRの異種のルート選択方針を支持するという困難を考えて。
3. Forwarding information: The use of dissimilar route computation
algorithms does not preclude common handling of packet
forwarding. Even if LS were used for NR, the requirement would
be the same, i.e., that the forwarding agent can determine
whether to use a NR precomputed route or an SDR installed route
to forward a particular data packet.
3. 推進情報: 異なったルート計算アルゴリズムの使用はパケット推進の一般的な取り扱いを排除しません。 LSがNRに使用されたとしても、要件はすなわち、同じで、小口運送業者が、NR precomputedルートを使用するかどうかと決心できるということであるだろうにかSDRは、特定のデータ・パケットを進めるためにルートをインストールしました。
In conclusion, using similar algorithms and mechanisms for SDR and NR components would have benefits. However, these benefits do not dominate the other factors as discussed before.
結論として、SDRとNRの部品に同様のアルゴリズムとメカニズムを使用するのにおいて、利益があるでしょう。 しかしながら、これらの利益は以前議論するように他の要素を支配していません。
Estrin, Rekhter & Hotz [Page 21] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[21ページ]RFC1322
3.8 Summary
3.8 概要
Given the performance complexity issues associated with global routing, aggregation of routing information is essential; at the same time we have argued that such aggregation must be flexible. Given the difficulties of supporting LS hop-by-hop routing in the presence of (a) flexible aggregation, (b) heterogeneous route selection policies, and (c) incomplete or inconsistent routing information, we see no alternative but to employ PV for the NR component of our architecture.
グローバルなルーティングに関連している性能複雑さ問題を考えて、ルーティング情報の集合は不可欠です。 同時に、私たちは、そのような集合がフレキシブルであるに違いないと主張しました。 支持の困難を考えて、LSは(a)の面前でフレキシブルな集合、(b)の異種のルート選択方針、および(c)の不完全であるか矛盾したルーティング情報を発送しながら、ホップで跳んで、私たちは私たちの構造のNRの部品にPVを使う以外の代替手段を全く見ません。
Based on the above tradeoffs, our NR component employs a PV architecture, where route computation and installation is done in a distributed fashion by the routers participating in the NR component [Footnote: Packet forwarding along routes produced by the NR component can be accomplished by either source routing or hop-by-hop routing. The latter is the primary choice because it reduces the amount of state in routers (if route setup is employed), or avoids encoding an explicit source route in network layer packets. However, the architecture does not preclude the use of source routing (or route setup) along the routes computed, but not installed, by the NR component.].
上の見返り、私たちのNRコンポーネント雇用に基づいたPV構造。(そこでは、経路計算とインストールがNRの部品に参加するルータによって分配されたファッションで行われます)。[以下に脚注をつけてください。 ソースルーティングかホップごとのルーティングのどちらかでNRの部品によって作成されたルートに沿ったパケット推進を実行できます。 後者は、ルータにおける、状態の量を減少させるのによる(ルートセットアップが採用しているなら)第一の選択である、またはネットワーク層パケットの明白な送信元経路をコード化するのを避けます。 しかしながら、構造はNRの部品によって計算されますが、インストールされなかったルートに沿ってソースルーティング(または、ルートセットアップ)の使用を排除しません。].
The distributed algorithm combines some of the features of link state with those of distance vector algorithms; in addition to next hop information, the NR component maintains path attributes for each route (e.g., the list of domains or routing domain confederations that the routing information has traversed so far). The path attributes that are carried along with a route express a variety of routing policies, and make explicit the entire route to the destination. With aggregation, this is a superset of the domains that form the path to the destination.
分配されたアルゴリズムはリンク状態の特徴のいくつかを距離ベクトルアルゴリズムのものに結合します。 次のホップ情報に加えて、NRの部品は、各ルートへの経路属性が(例えば、ドメインかルーティング情報が今までのところ横断した経路ドメイン同盟者のリスト)であると主張します。 ルートと共に運ばれる経路属性で、さまざまなルーティング方針を言い表して、目的地への全体のルートは明白になります。 集合で、これは経路を目的地に形成するドメインのスーパーセットです。
Estrin, Rekhter & Hotz [Page 22] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[22ページ]RFC1322
4.0 Source-demand routing (SDR)
4.0 ソース要求ルーティング(SDR)
Inter-domain routers participating in the SDR component forward packets according to routing information computed and installed by the domain that originates the traffic (source routing domain).
ルーティング情報によると、SDRのコンポーネントの前進のパケットに参加する相互ドメインルータが、計算して、交通(ソース経路ドメイン)を溯源するドメインのそばでインストールされました。
It is important to realize that requiring route installation by the source routing domain is not a matter of choice, but rather a necessity. If a particular route is used by a small number of domains (perhaps only one) then it is more appropriate to have the source compute and install the special route instead of burdening the intermediate nodes with the task of looking for and selecting a route with the specialized requirements. In addition, if the demand for the route is unpredictable, and thus can be determined only by the source, it should be up to the source to install the route.
ソース経路ドメインのそばでルートインストールを必要とするのが、選択の問題ではなく、むしろ必要性であるとわかるのは重要です。 少ない数のドメイン(恐らく1つだけ)によって特定のルートが使用されるなら、ソースが専門化している要件でルートを探して、選択するタスクで中間的ノードを負担することの代わりに特別なルートを計算して、インストールするのを持っているのは、より適切です。 ルートの需要を、予測できないで、さらに、ルートをインストールするのはソースまで達していて、その結果、単にソースは決定できるべきです。
In general, information that is used by source routing domains for computing source-demand routes reflects administrative (but not operational) status of the routing facilities (i.e., configured topology and policy) [Footnote: If SDR uses NR information then operational status could be considered in some route selection.]. Consequently, it is possible for a source routing domain to compute a route that is not operational at route installation time. The SDR component attempts to notify the source domain of failures when route installation is attempted. Similarly, the SDR component provides mechanisms for the source routing domain to be notified of failures along previously-installed active routes. In other words, the SDR component performs routing that is adaptive to topological changes; however, the adaptability is achieved as a consequence of the route installation and route management mechanisms. This is different from the NR component, where status changes are propagated and incorporated by nodes as soon as possible. Therefore, to allow faster adaptation to changes in the operational status of routing facilities, the SDR component allows the source domain to switch to a route computed by the NR component, if failure along the source- demand route is detected (either during the route installation phase, or after the route is installed), and if policy permits use of the NR route.
一般に、ソース要求ルートを計算するのにソース経路ドメインによって使用される情報はルーティング施設(すなわち、構成されたトポロジーと方針)の管理の、そして、(操作上でない)の状態を反映します[脚注: SDRがNR情報を使用するなら、操作上の状態は何らかのルート選択で考えられるかもしれません。]。 その結果、ソース経路ドメインがルートインストール時間に操作上でないルートを計算するのは、可能です。 SDRの部品は、ルートインストールが試みられるとき、失敗のソースドメインに通知するのを試みます。 同様に、SDRの部品は、ソース経路ドメインが以前にインストールされたアクティブなルートに沿って失敗について通知されるためにメカニズムを提供します。 言い換えれば、SDRの部品は位相的な変化に適応型のルーティングを実行します。 しかしながら、適応性はルートインストールとルート管理メカニズムの結果として達成されます。これはNRの部品と異なっています。そこでは、状態変化は、できるだけ早く、ノードによって伝播されて、組み込まれます。 したがって、ルーティング施設の操作上の状態の変化への、より速い適合を許容するために、ソースドメインはSDRの部品でNRの部品によって計算されたルートに切り替わります、ソース要求ルートに沿った失敗が検出されて(どちらかルートインストールフェーズか、ルートがインストールされた後に)、方針がNRルートの使用を可能にするなら。
The NR component will group domains into confederations to achieve its scaling goals (see [IDRP91]). In contrast, SDR will allow an AD-level route to be used by an individual domain without allowing use by the entire confederation to which the domain belongs. Similarly, a single transit domain may support a policy or special TOS that is not supported by other domains in its confederation(s). In other words, the architecture uses SDR to support non- hierarchical, non-aggregated policies where and when needed. Consequently, SDR by itself does not have the scaling properties of
NRの部品は、スケーリング目標を達成するためにドメインを同盟者に分類するでしょう([IDRP91]を見てください)。 対照的に、SDRは、ADレベルルートが個々のドメインによって使用を許さないでドメインが属する全体の同盟者によって使用されるのを許容するでしょう。 同様に、ただ一つのトランジットドメインは他のドメインによって同盟者で支持されない方針か特別なTOSを支持するかもしれません。 非集められた方針は、必要である言い換えれば、構造がサポートに非階層的にSDRを使用して、どこでいつであるか。 その結果、それ自体でSDRには、スケーリング特性がありません。
Estrin, Rekhter & Hotz [Page 23] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[23ページ]RFC1322
NR. In compensation, SDR does not require a complete, global domain map if portions of the world are never traversed or communicated with. As a result of the looser routing structure, SDR does not guarantee that a participating source routing domain will always have sufficient information to compute a route to a destination. In addition, if the domain does have sufficient information, it is possible that the quantity may be large enough to preclude storage and/or route computation in a timely fashion. However, despite the lack of guarantees, it is a goal of the architecture to provide efficient methods whereby sources can obtain the information needed to compute desired routes [Footnote: The primary goal of policy or TOS routing is to compute a route that satisfies a set of specialized requirements, and these requirements take precedence over optimality. In other words, even if a routing domain that participates in SDR or NR has sufficient information to compute a route, given a particular set of requirements, the architecture does not guarantee that the computed route is optimal.].
NR。 補償では、世界の一部が横断されるか、または決してコミュニケートされないなら、SDRは完全で、グローバルなドメイン地図を必要としません。 よりゆるいルーティング構造の結果、SDRは、目的地にルートを計算するために参加しているソース経路ドメインには十分な情報がいつもあるのを保証しません。 さらに、ドメインに十分な情報があるなら、量が直ちに格納、そして/または、経路計算を排除できるくらい大きいのは、可能です。 しかしながら、保証の不足にもかかわらず、それはソースが必要なルートを計算するのに必要である情報を得ることができる効率的な方法を提供する構造の目標です。[以下に脚注をつけてください。 方針かTOSルーティングの第一の目標が1セットの専門化している要件を満たすルートを計算することであり、これらの要件は最適の上で優先します。 言い換えれば、SDRかNRに参加する経路ドメインがルートを計算できるくらいの情報を持っても、特定のセットの要件を考えて、構造は、計算されたルートが最適であることを保証しません。].
Essential to SDR is the assumption that the routes installed on demand will be used sparingly. The architecture assumes that at any given moment the set of all source-demand routes installed in an internet forms a small fraction of the total number of source-demand routes that can potentially be installed by all the routing domains. It is an assumption of the architecture that the number of routes installed in a BR by the SDR component should be on the order of log N (where N is the total number of routing domains in the Internet), so that the scaling properties of the SDR component are comparable with the scaling properties of the NR component. The NR component achieves this property as a result of hierarchy.
SDRに不可欠であるのは、要求に応じてインストールされたルートが控えめに使用されるという仮定です。 構造は、いつなんどきでもインターネットにインストールされたすべてのソース要求ルートのセットがすべての経路ドメインで潜在的にインストールできるソース要求ルートの総数のわずかな部分を形成すると仮定します。 それはログN(Nがインターネットの経路ドメインの総数であるところ)の注文にはSDRの部品によってBRにインストールされたルートの数がそうあるべきであるという構造の仮定です、SDRの部品のスケーリング特性がNRの部品のスケーリング特性に匹敵しているように。 NRの部品は階層構造の結果、この特性を獲得します。
Note that the above requirement does not imply that only a few domains can participate in SDR, or that routes installed by the SDR component must have short life times. What the requirement does imply, is that the product of the number of routes specified by domains that participate in SDR, times the average SDR-route life time, is bounded. For example, the architecture allows either a small number of SDR routes with relatively long average life times, or a large number of SDR routes with relatively short average life times. But the architecture clearly prohibits a large number of SDR routes with relatively long average life times. The number of SDR routes is a function of the number of domains using SDR routes and the number of routes used per source domain.
上記の要件が、ほんのいくつかのドメインがSDRに参加できなければならないか、またはSDRの部品によってインストールされたルートが短い人生時を過さなければならないのを含意しないことに注意してください。 要件がすることは、それがSDRに参加するドメイン、平均したSDR-ルート人生時間は境界があるという何倍も指定されたルートの数の製品であることを含意します。 例えば、構造は比較的長い平均年数回がある少ない数のSDRルート、または比較的短い平均年数回がある多くのSDRルートを許容します。 しかし、構造は比較的長い平均年数回で明確に多くのSDRルートを禁止します。 SDRルートの数は、ドメインの数がSDRルートを使用する機能とソースドメイン単位で使用されるルートの数です。
In summary, SDR is well suited for traffic that (1) is not widely- used enough (or is not sufficiently predictable or steady) to justify computation and maintenance by the NR component, and (2) whose duration is significantly longer than the time it takes to perform the route installation procedure.
概要では、(1)が広くそうでない交通が持続時間がルート据え付け要領を実行するためにそれがかかる時間よりかなり長いNRの部品で計算と維持を正当化できるくらいの(または、十分予測できないか、または安定していません)(2)を使用したので、SDRはよく合っています。
Estrin, Rekhter & Hotz [Page 24] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[24ページ]RFC1322
The architecture does not require all domains in the Internet to participate in SDR. Therefore, issues of scalability (with respect to the size of the Internet) become less crucial (though still important) to the SDR component. Instead, the primary focus of the SDR component is shifted towards the ability to compute routes that satisfy specialized requirements, where we assume that the total number of domains requiring special routes simultaneously through the same part of the network is small relative to the total population.
構造は、SDRに参加するためにインターネットのすべてのドメインを必要とするというわけではありません。したがって、スケーラビリティ(インターネットのサイズに関する)の問題はSDRの部品により重要でなく(まだ重要ですが)なります。 代わりに、SDRの部品の焦点は専門化している要件を満たすルートを計算する能力に向かって移行します、私たちが、同時にネットワークの同じ部分を通って特別なルートを必要とするドメインの総数が総人口に比例してわずかであると思うところで。
4.1 Path Vector vs. Link State for SDR
4.1 経路ベクトル対SDRのためのリンク状態
It is feasible to use either a distance vector or link state method of route computation along with source routing. One could imagine, for instance, a protocol like BGP in which the source uses the full AD path information it receives in routing updates to create a source route. Such a protocol could address some of the deficiencies identified with distance vector, hop-by-hop designs. However, we opt against further discussion of such a protocol because there is less to gain by using source routing without also using a link state scheme. The power of source routing, in the context of inter-AD policy routing, is in giving the source control over the entire route. This goal cannot be realized fully when intermediate nodes control which legal routes are advertised to neighbors, and therefore to a source.
ソースルーティングに伴う経路計算の距離ベクトルかリンク州の方法のどちらかを使用するのは可能です。 人は、例えば、ソースがそれがルーティングアップデートで受け取る完全なAD経路情報を使用するBGPのようなプロトコルが送信元経路を作成すると想像できました。 そのようなプロトコルは距離ベクトル、ホップごとのデザインと同一視された欠乏のいくつかを記述するかもしれません。 しかしながら、また、リンク州の計画を使用しないでソースルーティングを使用することによって獲得するために以下があるので、私たちはそのようなプロトコルのさらなる議論に対して選びます。 全体のルートのソース支配力を与えるのにおいて相互AD方針ルーティングの文脈のソースルーティングのパワーがあります。 中間的ノードが、どの法的なルートが隣人と、そして、したがって、ソースに広告を出すかを制御すると、完全にこの目標を実現できるというわけではありません。
In other words, intermediate nodes should be able to preclude the use of a route by expressing a transit policy, but if a route is not precluded (i.e., is legal according to all ADs in the route), the route should be made available to the source independent of an intermediate domain's preferences for how its own traffic flows.
言い換えれば、中間的ノードは運送保険証券を言い表すことによって、ルートの使用を排除するはずであることができますが、ルートを排除しないなら(すなわち、ルートによるすべてのADsによると、法的です)、ルートをそれ自身の交通がどう流れるか中間的ドメインの好みの如何にかかわらずソースに利用可能にするべきです。
Therefore, the SDR component employs an IDPR-like architecture in which link-state style updates are distributed with explicit policy terms included in each update along with the advertising node's connectivity.
したがって、広告ノードの接続性に伴う各アップデートにどのリンク州のスタイルアップデートが明白な方針用語で分配されているかのIDPRのような構造を含んでいるSDRコンポーネント雇用。
4.2 Distribution of Routing Information
4.2 経路情報の分配
By using a hop-by-hop NR component based on PV to complement the source-routing SDR component, we have alleviated the pressure to aggregate SDR forwarding information; the large percentage of inter- domain traffic carried, simultaneously, by any particular border router will be forwarded using aggregated NR forwarding information. However, the use of NR does not address the other major scaling problem associated with SDR: that of distributing, storing, and computing over a complete domain-level topology map. In this section we describe promising opportunities for improving the scaling properties of SDR routing information distribution, storage, and
ホップごとのソースルーティングSDRの部品の補足となるようにPVに基づくNRの部品を使用することによって、私たちはSDR推進情報に集める圧力を軽減しました。 情報を転送しながら集められたNRを使用することで同時にどんな特定の境界ルータによっても運ばれた相互ドメイン交通の大きな割合を進めるでしょう。 しかしながら、NRの使用はSDRに関連しているもう片方のその重大なスケーリング問題を訴えません: 分配のものと、格納と、完全なドメインレベルトポロジー地図に関して計算すること。 そしてこのセクションで、私たちがSDRルーティング情報流通、格納のスケーリング特性を改良する有望な機会について説明する。
Estrin, Rekhter & Hotz [Page 25] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[25ページ]RFC1322
computation.
計算。
Note that we do not propose to solve this problem in the same way that we solve it for NR. A priori abstraction will not be employed since different domains may require different methods of abstracting the same routing information. For example, if we aggregate routing information of domains that do not share the same policy and TOS characteristics (i.e., services), then outside of the aggregate, only those services that are offered by all domains in the aggregate will be advertised. In order to locate special routes, SDR only uses aggregates when the component domains (and in turn the aggregate) advertise the required TOS and policy descriptions. When the required TOS or policy characteristics are not offered by an aggregate, full information about the component domains is used to construct a route through those domains that do support the particular characteristics. Consequently, we need some other, more flexible, means of reducing the amount of information distributed and held. We address two issues in turn: distribution of configured topology and policy information, and distribution of dynamic status information.
私たちが、私たちがNRのためにそれを解決するという同じようにこの問題を解決するよう提案しないことに注意してください。 異なったドメインが同じルーティング情報を抜き取る異なった方法を必要とするかもしれないので、先験的な抽象化は使われないでしょう。 例えば、私たちが同じ方針を共有しないドメインとTOSの特性(すなわち、サービス)のルーティング情報に集めると、集合の外では、集合のすべてのドメインによって提供されるそれらのサービスだけの広告を出すでしょう。 コンポーネントドメインであるときにだけ、SDRが特別なルートの場所を見つけるのに集合を使用する、(順番に、集合) 必要なTOSと方針記述の広告を出してください。 必要なTOSか方針の特性が集合によって提供されないとき、コンポーネントドメインに関する完全情報は、特定の特性を支持するそれらのドメインを通してルートを構成するのに使用されます。 その結果、私たちが必要である、ある他のより多くの曲げやすいもの、情報量が分配して、保持した減少の手段。 私たちは順番に2冊を記述します: 構成されたトポロジーと方針情報の分配、およびダイナミックな状態情報の分配。
4.2.1 Configured Information
4.2.1 構成された情報
Information about the existence of inter-domain links, and policies maintained by domains, changes slowly over time. This is referred to as configured information. In the current IDPR specification complete, global, configuration information is kept by a route server in each domain. Route servers (RS) are the entities that compute source routes. On startup a RS can download the connectivity database from a neighbor RS; as domains, inter-domain links, or policies change, the changes are flooded to a RS in each domain.
相互ドメインリンク、およびドメインによって維持された方針の存在に関する情報は時間がたつにつれて、ゆっくり変化します。 これは構成された情報と呼ばれます。 現在のIDPR仕様では、完全で、グローバルな設定情報は各ドメインにルートサーバによって保たれます。 ルートサーバ(RS)は送信元経路を計算する実体です。 始動では、RSは隣人RSから接続性データベースをダウンロードできます。 ドメイン、相互ドメインリンク、または方針が変化するのに従って、変化は各ドメインのRSへあふれます。
We have not yet specified the exact mechanisms for distributing configured connectivity information for SDR. However, unlike the current IDPR specification, the SDR component will not flood all configured information globally. Several alternate methods for organizing and distributing information are under investigation.
私たちはまだSDRのための構成された接続性情報を分配するのに正確なメカニズムを指定していません。しかしながら、現在のIDPR仕様と異なって、SDRの部品はすべての構成された情報をグローバルにあふれさせるというわけではないでしょう。 結団するためのいくつかの代替方法と情報伝達は調査中です。
Configured information may be regularly distributed via an out-of- band channel, e.g., CD/ROM. In a similar vein, this information could be posted in several well-known locations for retrieval, e.g., via FTP. Between these "major" updates, aggregated collections of changes may be flooded globally. Moreover, limited flooding (e.g., by hop-count) could be used as appropriate to the "importance" of the change; while a policy change in a major backbone may still be flooded globally, a new inter-regional link may be flooded only within those regions, and information about an additional link to a non-transit domain may not be available until the next regularly-
定期的に構成された情報はそうです。-アウトを通して分配されて、バンドでは、例えば精神を集中してください。CD/ROM。 似たような仕方で、例えば、FTPを通した検索のために数個の周知の位置にこの情報を掲示できました。 これらの「主要な」アップデートの間では、変化の集められた収集はグローバルに水につかっているかもしれません。 そのうえ、適宜、限られた氾濫(例えば、ホップカウントによる)を変化の「重要性」に使用できました。 主要な背骨における政策変更はまだグローバルに水につかっているかもしれません、そして、新しい相互地方のリンクはそれらの領域だけの中で水につかるかもしれません、そして、非トランジットドメインへの追加リンクの情報は次まで定期的に利用可能でないかもしれませんが
Estrin, Rekhter & Hotz [Page 26] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[26ページ]RFC1322
scheduled "major" distribution.
「主要な」分配の計画をしました。
Changes that are not distributed as they occur will not necessarily be discovered. However, a route server may learn pertinent information by direct query of remote servers, or through error messages resulting from traffic sent along failed routes. Complete global flooding may be avoided by using some combination of these mechanisms.
起こるとき分配されなかった変化は必ず発見されるというわけではないでしょう。 しかしながら、ルートサーバはリモートサーバのダイレクト質問の近く、または、失敗したルートに沿って送られた交通から生じるエラーメッセージを通して適切な情報を学ぶかもしれません。 完全なグローバルな氾濫は、これらのメカニズムの何らかの組み合わせを使用することによって、避けられるかもしれません。
Even if an initial implementation uses a simple global flood, we must study the problem of structuring connectivity information such that it can be retrieved or distributed in a more selective manner, while still allowing sources to discover desired routes. For example, we imagine RSs requesting filtered information from each other. How the RSs should define filters that will get enough information to find special routes, while also effectively limiting the information, is an open question. Again, the question is how to effectively anticipate and describe what information is needed in advance of computing the route.
初期の実現が簡単なグローバルな洪水を使用しても、私たちは情報筋が必要なルートを発見するのをまだ許容している間、より選択している方法でそれを検索するか、または分配できるように接続性情報を構造化するという問題を研究しなければなりません。 例えば、私たちは、RSsが互いからフィルターにかけることの情報を要求すると想像します。 また、事実上、情報を制限している間、RSsがどう十分な情報が特別なルートを見つけるフィルタを定義するはずであるかは、未決問題です。 一方、質問はルートを計算する前に事実上、なにかを予期して、説明するかに、情報がどう必要であるかということです。
The essential dilemma is that networks are not organized in a nicely geographical or topologically consistent manner (e.g., it is not effective to ask for all networks going east-west that are within a certain north-south region of the target), hence a source domain does not know what information it needs (or should ask for) until it searches for, and discovers, the actual path. Even with a central database, techniques are needed to structure configuration information so that the potential paths that are most likely to be useful are explored first, thereby reducing the time required for route computation.
aでうまく地理的な状態で位相的に組織化されなかったそのネットワークが一貫した方法(例えば、東西になる目標のある一定の南北領域の中にあるすべてのネットワークを求めるのは有効でない)であり、したがって、実際の経路を捜し求めて、発見するまでソースドメインが、それがどんな情報を必要とするかを(または、求めるべきです)知らないという不可欠のジレンマ。 主要なデータベースがあっても、テクニックが設定情報を構造化するのに必要であるので、役に立つ最も傾向がある潜在的経路は最初に探検されます、その結果、経路計算に必要である時間を短縮します。
One promising approach organizes information using route fragments (partial paths) [Footnote: Route fragments were first suggested by Dave Clark and Noel Chiappa.]. Although the number of route fragments grows faster than the number of domains (at least O(N^2)), we can selectively choose those that will be useful to compute routes. In particular, for each stub domain, fragments would be constructed to several well-known backbones [Footnote: Route fragments may be computed by a destination's route server and either made available via information service queries or global flooding. In addition, NR computed routes may be used as SDR route fragments.]. Among its benefits, this approach aggregates domain information in a manner useful for computing source-routes, and provides an index, namely the destination, which facilitates on-demand reference and retrieval of information pertinent to a particular route computation. At this point, it is not clear how route fragments will affect SDR's ability to discover non-hierarchical routes.
1つの有望なアプローチが、ルート断片(部分的な経路)を使用することで情報を組織化します[脚注: ルート断片は最初に、デーブ・クラークとクリスマスChiappaによって提案されました。]。 ルート断片の数はドメイン(少なくともO(N^2))の数より速くなりますが、私たちは選択的にルートを計算するために役に立つものを選ぶことができます。 それぞれのスタッブドメインにおいて、特に、断片はいくつかの周知の背骨に構成されるでしょう。[以下に脚注をつけてください。 ルート断片は目的地のルートサーバによって計算されて、情報サービス質問で利用可能に作られたか、グローバルな氾濫であるかもしれません。 添加、計算されたNRでは、SDRが断片を発送するとき、ルートは使用されるかもしれません。]. 利益の中では、このアプローチは、送信元経路を計算することの役に立つ方法によるドメイン情報に集めて、インデックス、すなわち、特定の経路計算に適切な要求次第の参照と情報の検索を容易にする目的地を提供します。 ここに、ルート断片がどのように非階層的なルートを発見するSDRの性能に影響するかは、明確ではありません。
Estrin, Rekhter & Hotz [Page 27] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[27ページ]RFC1322
4.2.2 Dynamic Status Information
4.2.2 ダイナミックな状態情報
Assuming a technique for global or partial distribution of configured information, a second issue is whether, and how, to distribute dynamic status information (i.e., whether an inter-domain connection is up or down).
構成された情報のグローバルであるか部分的な分配のためのテクニックを仮定して、第2刷が仮定する、そして、どのように、ダイナミックな状態情報(すなわち、相互ドメイン接続が起きているか、または下がっていることにかかわらず)を分配するために。
In the current version of IDPR, dynamic status information is flooded globally in addition to configuration information. We propose to distribute status information based strictly on locality. First, dynamic information will be advertised within a small hop-count radius. This simple and low-overhead mechanism exploits topological locality. In addition to flooding status updates to nearby nodes, we also want to provide more accurate route information for long distance communications that entails more than a few network hops. Reverse path update (RPU) is a mechanism for sending dynamic status information to nodes that are outside the k-hop radius used for updates, but that nevertheless would obtain better service (fewer failed setups) by having access to the dynamic information [Estrin- etal91].
IDPRの最新版では、設定情報に加えてダイナミックな状態情報はグローバルに水につかっています。 私たちは、厳密に場所に基づく状態情報を分配するよう提案します。 まず最初に、小さいホップカウント半径の中に動的情報の広告を出すでしょう。 この簡単で低いオーバーヘッドのメカニズムは位相的な場所を利用します。 また、状態が近いノードにアップデートする氾濫に加えて、長距離のコミュニケーションのためのかなり多くのネットワークホップを伴うより正確な経由地案内を提供したいと思います。 逆の経路アップデート(RPU)は、アップデートに使用されるk-ホップ半径の外でありますが、それにもかかわらず動的情報[Estrin- etal91]に近づく手段を持っていることによって、より良いサービス(より少ない失敗したセットアップ)を得るノードにダイナミックな状態情報を送るためのメカニズムです。
RPU uses the existing active routes (represented by installed setup state or by a cache of the most recent source routes sent via the node in question) as a hint for distribution of event notifications. Instead of reporting only the status of the route being used, RPU reports the status of the domain's other inter-domain connections. If source routing exhibits route locality, the source is more likely to use other routes going through the node in question; in any case the overhead of the information about other links will be minimal.
RPUはイベント通知の分配に、ヒントとして既存のアクティブなルート(インストールされたセットアップ国か問題のノードで送られた最新の送信元経路のキャッシュで、表される)を使用します。 使用されるルートの状態だけを報告することの代わりに、RPUはドメインの他の相互ドメイン接続の状態を報告します。 ソースルーティングがルート場所を示すなら、ソースは問題のノードを調べながら、他のルートをより使用しそうです。 どのような場合でも、他のリンクの情報のオーバーヘッドは最小量になるでしょう。
In this way, sources will receive status information from regions of the network through which they maintain active routes, even if those regions are more than k hops away. Using such a scheme, k could be small to maximize efficiency, and RPU could be used to reduce the incidence of failed routes resulting from inaccurate status information. This will be useful if long-path communication exhibits route locality with respect to regions that are closer to the destination (and therefore outside the k hop radius of flooded information). In such situations, flooding information to the source of the long route would be inefficient because k would have to be equal to the length of the route, and in almost all cases, the percentage of nodes that would use the information decreases significantly with larger k.
このように、情報筋は彼らがアクティブなルートを維持するネットワークの領域から状態情報を受け取るでしょう、それらの領域が遠くのkホップ以上であっても。 そのような計画を使用して、kは効率を最大にするために小さいかもしれません、そして、不正確な状態情報から生じる失敗したルートの発生を減少させるのにRPUは使用できました。 長い経路コミュニケーションが目的地(そしてしたがって、水につかっている情報のkホップ半径の外で)の、より近くにある領域に関してルート場所を示すなら、これは役に立ちます。 そのような状況で、kはルートの長さと等しくなければならないでしょう、したがって、長いルートの源への氾濫情報が効率が悪いだろう、より大きいkに従って、ほとんどすべての場合、情報を使用するノードの割合はかなり減少します。
4.3 Source-Demand Route Management
4.3 ソース要求ルート管理
SDR may be built either on top of the network layer supported by the NR component, or in parallel with it. SDR forwarding will be
SDRはNRの部品によって支持されたネットワーク層の上か、それと平行して造られるかもしれません。 SDR推進はそうでしょう。
Estrin, Rekhter & Hotz [Page 28] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[28ページ]RFC1322
supported via two techniques: loose source-routing and route setup.
2つのテクニックを通して支持される: ソースルーティングとルートセットアップを発射してください。
The first technique, loose source-routing, would allow the originator of a packet to specify a sequence of domains that the packet should traverse on its path to a destination. Forwarding such a packet within a domain, or even between domains within a confederation, would be left to intra-domain routing. This avoids per-connection state and supports transaction traffic.
最初のテクニック(ゆるいソースルーティング)で、パケットの生成元はパケットが経路で目的地に横断するはずであるドメインの系列を指定できるでしょう。 そのようなパケットを進めて、ドメイン以内か同盟者の中のドメインの間にはさえ、左にイントラドメインにはルーティングがあるでしょう。 これは、1接続あたりの状態を避けて、取引交通を支持します。
The second technique, route setup, will be based on mechanisms developed for IDPR and described in [IDPR90]. It is well suited to conversations that persist significantly longer than a round-trip- time. The setup protocol defines packet formats and the processing of route installation request packets (i.e, setup packets). When a source generates a setup packet, the first border router along the specified source route checks the setup request, and if accepted, installs routing information; this information includes a path ID, the previous and next hops, and whatever other accounting-related information the particular domain requires. The setup packet is passed on to the next BR in the domain-level source route, and the same procedure is carried out [Footnote: The setup packet may be forwarded optimistically, i.e., before checks are completed, to reduce latency.]. When the setup packet reaches the destination, an accept message is propagated back hop by hop, and each BR en route activates its routing information. Subsequent data packets traveling along the same path to the destination include a path ID in the packet. That path ID is used to locate the appropriate next-hop information for each packet.
2番目のテクニック(ルートセットアップ)はIDPRのために開発されて、[IDPR90]で説明されたメカニズムに基づくでしょう。 それは往復の時間より長い間かなり持続する会話によく合っています。 セットアッププロトコルはルートインストールリクエスト・パケット(i.e、セットアップパケット)のパケット・フォーマットと処理を定義します。 ソースがセットアップパケットを発生させると、1番目は、セットアップが要求する指定された送信元経路チェック、受け入れるならルータに接していて、ルーティング情報をインストールします。 この情報は経路ID、前で次のホップ、および特定のドメインが必要とするどんな他の会計関連の情報も含んでいます。 セットアップパケットはドメインレベル送信元経路による次のBRに通過されます、そして、同じ手順が行われます[脚注: 楽観的にセットアップパケットを進めるかもしれません、すなわち、チェックがレイテンシを減少させるために終了する前に。]。 セットアップパケットが目的地に達すると受け入れる、伝播された逆ホップがホップであって、途中各BRがルーティング情報を活性化するというメッセージを受け入れてください。 同じ経路に沿って目的地に移動する順次データパケットはパケットに経路IDを含んでいます。 その経路IDは、各パケットのための適切な次のホップ情報の場所を見つけるのに使用されます。
Border routers that support both the NR and the SDR components, must be able to determine what forwarding mechanism to use. That is, when presented with a network layer PDU, such a BR should be able to make an unambiguous decision about whether forwarding of that PDU should be handled by the NR or the SDR component. Discrimination mechanisms are dependent on whether the new network layer introduced by the SDR component is built on top of, or in parallel with, the network layers supported by the NR component. Once the discrimination is made, packets that have to be forwarded via routes installed by the SDR component are forwarded to the exit port associated with the particular Path ID in the packet header. Packets that have to be forwarded via routes installed by the NR component are forwarded to the exit port associated with the particular destination and Type of Service parameters (if present) in their packet headers.
NRとSDRの部品の両方を支える境界ルータは、どんな推進メカニズムを使用したらよいかを決定できなければなりません。 すなわち、そのPDUの推進がNRかSDRの部品によって扱われるべきであるかどうかに関してPDU、そのようなBRがはっきりとした結論をするはずであることができるネットワーク層を与えるとき。 区別メカニズムはSDRの部品によって導入された新しいネットワーク層がネットワーク層かNRの部品によって支持されたネットワーク層築き上げられるかどうかに依存しています。 いったん区別をすると、SDRの部品によってインストールされたルートで進められなければならないパケットをパケットのヘッダーで特定のPath IDに関連している出口ポートに送ります。 彼らのパケットのヘッダーのServiceパラメタの特定の目的地とTypeに関連していて(現在)の出口ポートにNRの部品によってインストールされたルートで進められなければならないパケットを送ります。
Next, we describe the primary differences between the IDPR setup procedure previously specified, and the procedure we propose to develop for this hybrid architecture.
次に、私たちは以前に指定されたIDPRセットアップ手順と、私たちがこのハイブリッド構造のために開発するよう提案する手順の第一の違いについて説明します。
Estrin, Rekhter & Hotz [Page 29] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[29ページ]RFC1322
During route installation, if a BR on the path finds that the remainder of the indicated route from the BR to the destination is identical to the NR route from the BR to the destination, then the BR can turn off the SDR route at that point and map it onto the NR route. For this to occur, the specifications of the SDR route must completely match those of the NR route. In addition, the entire forward route must be equivalent (i.e., the remaining hops to the destination).
ルートインストールの間、経路のBRが、示されたBRから目的地までのルートの残りがBRから目的地までNRルートと同じであることがわかるなら、BRはその時、SDRルートをオフにして、NRルートにそれを写像できます。 これが起こるように、SDRルートの仕様はNRルートのものに完全に合わなければなりません。 さらに、全体の前進のルートは同等でなければなりません(すなわち、残りは目的地へ跳びます)。
Moreover, if the NR route changes during the course of an active SDR route, and the new NR route does not match the SDR route, then the SDR route must be installed for the remainder of the way to the destination. Consequently, when an SDR route is mapped onto an NR route, the original setup packet must be saved. A packet traveling from a source to destination may therefore traverse both an SDR and an NR route segment; however, a packet will not traverse another SDR segment after traveling over an NR segment. However, during transient periods packets could traverse the wrong route and therefore this must be an optional and controllable feature.
そのうえ、NRがアクティブなSDRルートのコースの間、変化を発送して、新しいNRルートがSDRルートに合っていないなら、目的地への方法の残りのためにSDRルートをインストールしなければなりません。 SDRルートがNRルートに写像されるとき、その結果、オリジナルのセットアップパケットを救わなければなりません。 したがって、ソースから目的地まで移動するパケットはSDRとNRルートセグメントの両方を横断するかもしれません。 しかしながら、パケットはNRセグメントの上を旅行した後に、別のSDRセグメントを横断しないでしょう。 しかしながら、一時的な期間のパケットの間、間違ったルートを横断できて、したがって、これは任意の、そして、制御可能な特徴であるに違いありません。
A source can also request notification if a previously-down link or node returns to operation some time after a requested route setup fails. If a BR on the route discovers that the requested next-hop BR is not available, the BR can add the source to a notification list and when the next-hop BR becomes reachable, a notification can be sent back to the source. This provides a means of flushing out bad news when it is no longer true. For example, a domain might decide to route through a secondary route when its preferred route fails; the notification mechanism would inform the source in a timely manner when its preferred route is available again.
また、要求されたルートセットアップが失敗した後に以前に下がっているリンクかノードがいつか操作に戻るなら、情報筋は通知を要求できます。 ルートの上のBRが、要求された次のホップBRが利用可能でないと発見するなら、BRは通知リストにソースを追加できます、そして、次のホップBRが届くようになるとき、通知はソースに送り返すことができます。 これはそれがもう本当でないときに悪いニュースを洗う手段を提供します。 例えば、ドメインは都合のよいルートが失敗する二次ルートによるルートに決めるかもしれません。 通知メカニズムは、都合のよいルートが直ちにいつ再び利用可能であるかをソースに知らせるでしょう。
A third option addresses adaptation after route installation. During packet forwarding along an active SDR route, if a BR finds that the SDR route has failed, it may redirect the traffic along an existing NR route to the destination. This adaptation is allowed only if use of the NR route does not violate policy; for example, it may provide a less desirable type of service. This is done only if the source selects the option at route setup time. It is also up to the source whether it is to be notified of such actions.
3番目のオプションはルートインストールの後に適合を記述します。 アクティブなSDRルートに沿ったパケット推進の間、BRが、SDRルートが失敗したのがわかるなら、それは既存のNRルートに沿って目的地に交通を向け直すかもしれません。 NRルートの使用が方針に違反しない場合にだけ、この適合は許容されています。 例えば、それはそれほど望ましくないタイプのサービスを提供するかもしれません。 ソースがルート準備時間にオプションを選択する場合にだけ、これをします。 そのような動作について通知されることになっているか否かに関係なく、それはソースまでも達しています。
When a SDR route does fail, the detecting BR sends notification to the source(s) of the active routes that are affected. Optionally, the detecting BR may include additional information about the state of other BRs in the same domain. In particular, the BR can include its domain's most recent "update" indicating that domain's inter- domain links and policy. This can be helpful to the extent there is communication locality; i.e., if alternative routes might be used that traverse the domain in question, but avoid the failed BR.
SDRルートが失敗すると、検出しているBRは影響を受けるアクティブなルートの源に通告を送っています。 任意に、検出しているBRは同じドメインに他のBRsの州に関する追加情報を含むかもしれません。 特に、BRは、そのドメインの相互ドメインリンクと方針を示しながら、ドメインの最新の「アップデート」を含むことができます。 これはコミュニケーション場所があるという範囲に役立っている場合があります。 すなわち、問題のドメインを横断しますが、失敗したBRを避ける代替のルートが使用されるかもしれないなら。
Estrin, Rekhter & Hotz [Page 30] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[30ページ]RFC1322
In summary, when a route is first installed, the source has several options (which are represented by flags in the route setup packet):
ルートが最初にインストールされるとき、概要では、ソースはいくつかのオプション(ルートセットアップパケットに旗で表される)を持っています:
1. If an NR route is available that satisfies all local policy
and TOS, then use it. Otherwise...
1. NRルートが利用可能であるなら、それはすべてのローカルの方針とTOSを満たして、次に、使用はそれです。 そうでなければ…
2. Indicate whether the source wants to allow the setup to
default to a NR route if the SDR route setup fails.
2. SDRルートセットアップが失敗するならソースが、セットアップがNRルートをデフォルトとするのを許容したがっているかどうかを示してください。
3. Request notification of mapping to a NR route.
3. NRルートにマッピングの通知を要求してください。
4. Request additional configured information on failure.
4. 失敗の追加構成された情報を要求してください。
5. Request addition to a notification list for resource
re-availability.
5. リソース再の有用性のための通知リストへの追加を要求してください。
6. Allow data packets to be rerouted to a NR route when failure
happens after setup (so long as no policy is violated).
6. 失敗がセットアップの後に起こる(方針が全く違反されない限り)ときにはデータ・パケットはNRルートに別ルートで送らされてください。
7. Request notification of a reroute of data packets.
7. aの通知がデータ・パケットのコースを変更するよう要求してください。
8. Request additional configured information on failure notice
when the route is active.
8. ルートがアクティブであるときには失敗通知の追加構成された情報を要求してください。
9. Request addition to a notification list if an active route
fails.
9. アクティブなルートが失敗するなら、通知リストへの追加を要求してください。
Estrin, Rekhter & Hotz [Page 31] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[31ページ]RFC1322
5.0 The Unified Architecture
5.0 統一された構造
In addition to further evaluation and implementation of the proposed architecture, future research must investigate opportunities for increased unification of the two components of our architecture. We are investigating several opportunities for additional commonality:
提案された構造のさらなる評価と実現に加えて、今後の研究は私たちの構造の2つの成分の増加する統一の機会を調査しなければなりません。 私たちは追加共通点のいくつかの機会を調査しています:
1. Routing Information Base:
Perhaps a single RIB could be shared by both NR and SDR.
NR routes can be represented as a directed graph labeled
with flags (on the nodes or links) corresponding to the
generic transit constraints. SDR requires that this graph
be augmented by links with non-generic policies that have
been discovered and maintained for computing special routes;
in addition, special policy flags may be added to links
already maintained by the NR component.
1. 経路情報基地: 恐らく、シングルRIBはNRとSDR. NRの両方によって共有されて、一般的なトランジット規制に対応する旗(ノードかリンクの)でラベルされた有向グラフとしてルートを表すことができるということであるかもしれません。 SDRは、このグラフが特別なルートを計算するために発見されて、維持された非ジェネリック方針とのリンクによって増大させられるのを必要とします。 さらに、個別保険証券旗はNRの部品によって既に維持されたリンクに加えられるかもしれません。
2. Information Distribution:
The NR path vectors could include address(es) of repositories
for SDR-update information for each AD (or confederation) to
assist the SDR component in retrieving selective information
on demand. For domains with minimal policies, where the space
required for policy information is smaller than the space
required for a repository address (e.g., if the policies for
the domain listed are all wildcard), the NR path vectors could
include a flag to that effect.
2. 情報流通: 各AD(または、同盟者)のためのSDR-アップデート情報がオンデマンドの選択している情報を検索するのにSDRの部品を助けるように、NR経路ベクトルは倉庫のアドレス(es)を含むかもしれません。 最小量の方針でのドメインに、NR経路ベクトルはその趣旨で旗を含むかもしれません。(そこでは、方針情報に必要であるスペースがスペースが倉庫アドレスに必要であるというよりも(例えば、ドメインが記載したので方針がすべてワイルドカードであるなら)小さいです)。
3. Packet Forwarding:
We should consider replacing the current IDPR-style network
layer (which contains a global path identifier used in
forwarding data packets to the next policy gateway on an
IDPR route) with a standard header (e.g., IP or CLNP),
augmented with some option fields. This would unify the
packet header parsing and forwarding functions for SDR and NR,
and possibly eliminate some encapsulation overhead.
3. パケット推進: 私たちは、現在のIDPR-スタイルネットワーク層(IDPRルートの上で推進データ・パケットで隣の方針ゲートウェイに使用されるグローバルな経路識別子を含む)をいくつかのオプション・フィールドに従って増大する標準のヘッダー(例えば、IPかCLNP)に取り替えると考えるべきです。 これは、SDRとNRのために機能を分析して、進めるパケットのヘッダーを統一して、ことによると何らかのカプセル化オーバーヘッドを取り除くでしょう。
4. Reachability Information:
Currently IDRP distributes network reachability information
within updates, whereas IDPR only distributes domain
reachability information. IDPR uses a domain name service
function to map network numbers to domain numbers; the latter
is needed to make the routing decision. We should consider
obtaining the network reachability and domain information in
a unified manner.
4. 可到達性情報: 現在の、IDRPはアップデートの中でネットワーク可到達性情報を分配しますが、IDPRはドメイン可到達性情報を分配するだけです。 IDPRはドメイン番号にネットワーク・ナンバーを写像するのにドメイン名サービス機能を使用します。 後者が、ルーティング決定をするのに必要です。 私たちは、統一された方法によるネットワークの可到達性とドメイン情報を得ると考えるべきです。
Estrin, Rekhter & Hotz [Page 32] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[32ページ]RFC1322
5.1 Applicability to Various Network Layer Protocols
5.1 様々なネットワーク層プロトコルへの適用性
The proposed architecture is designed to accommodate such existing network layer protocols as IP ([Postel81]), CLNP ([ISO-473-88]), and ST-II ([ST2-90]). In addition, we intend for this architecture to support future network layer mechanisms, e.g., Clark and Jacobson's proposal or Braden and Casner's Integrated Services IP. However on principal we can not make sweeping guarantees in advance of the mechanisms themselves. In any case, not all of the mentioned protocols will be able to utilize all of the capabilities provided by the architecture. For instance, unless the increase in the number of different types of services offered is matched by the ability of a particular network layer protocol to unambiguously express requests for such different types of services, the capability of the architecture to support routing in the presence of a large number of different types of service is largely academic. That is, not all components of the architecture will have equal importance for different network layer protocols. On the other hand, this architecture is designed to serve the future global internetworking environment. The extensive research and development currently underway to implement and evaluate network mechanisms for different types of service suggests that future networks will offer such services.
提案された構造は、IP([Postel81)、CLNP([ISO-473-88])、およびST-II[ST2-90])のような既存のネットワーク層プロトコルに対応するように設計されています。 さらに、私たちは将来のネットワーク層メカニズム、例えばクラークとジェーコブソンの提案を支持するこの構造かブレーデンとCasnerのIntegrated ServicesのためにIPを意図します。 しかしながら、私たちはメカニズム自体の前で校長の上では、全面的な保証をすることができません。 どのような場合でも、言及されたプロトコルのすべてが構造によって提供された能力のすべてを利用できるというわけではないでしょう。 例えば、異なったタイプのサービスの数で提供された増加が特定のネットワーク層プロトコルが明白にそのような異なったタイプのサービスを求める要求を言い表す能力によって合われていない場合、構造が多くの異なったタイプのサービスがあるとき掘るのを支持する能力は主にアカデミックです。 すなわち、構造のすべての成分には、異なったネットワーク層プロトコルのための等しい重要性があるというわけではないでしょう。 他方では、この構造は、将来のグローバルなインターネットワーキング環境に役立つように設計されています。 現在異なったタイプのサービスのためにネットワークメカニズムを実行して、評価するためには進行中の大規模な研究開発は、将来のネットワークがそのようなサービスを提供するのを示します。
One of the fundamental issues in the proposed architecture is the issue of single versus multiple protocols. The architecture does not make any assumptions about whether each network layer is going to have its own inter-domain routing protocol, or a single inter-domain routing protocol will be able to cover multiple network layers [Footnote: Similar issue already arose with respect to the intra- domain routing protocol, which generated sufficient amount of controversy within the Internet community. It is our opinion, that the issue of single versus multiple protocols is more complex for the inter-domain routing than for the intra-domain routing.]. That is, the proposed architecture can be realized either by a single inter- domain routing protocol covering multiple network layers, or by multiple inter-domain routing protocols (with the same architecture) tailored to a specific network layer [Footnote: If the single protocol strategy is adopted, then it is likely that IDRP will be used as a base for the NR component. Since presently IDRP is targeted towards CLNP, further work is needed to augment it to support IP and ST-II. If the multiple protocol strategy is adopted, then it is likely that BGP will be used as a base for the NR component for IP, and IDRP will be used as a base for the NR component for CLNP. Further work is needed to specify protocol in support for the NR component for ST-II. Additional work may be needed to specify new features that may be added to BGP.].
提案されたアーキテクチャの基本的な問題の1つはシングル対複数のプロトコルの問題です。 アーキテクチャが各ネットワーク層にはそれ自身の相互ドメインがあるだろうかどうかに関する少しの仮定もルーティング・プロトコルにしないか、またはただ一つの相互ドメインルーティング・プロトコルは複数のネットワーク層をカバーできるでしょう。[以下に脚注をつけてください。 同様の問題はイントラドメインルーティング・プロトコルに関して既に起こりました。(それは、インターネットコミュニティの中で十分な量の論争を生成しました)。 それは相互ドメインルーティングには、シングル対複数のプロトコルの問題がイントラドメインルーティングより複雑であるという私たちの意見です。]. 複数のネットワーク層をカバーするただ一つの相互ドメインルーティング・プロトコル、または特定のネットワーク層に適合した複数の相互ドメインルーティング・プロトコル(同じアーキテクチャがある)ですなわち、提案されたアーキテクチャを実現できます。[以下に脚注をつけてください。 ただ一つのプロトコル戦略が採用されると、IDRPはNRの部品にベースとして使用されそうでしょう。 現在のIDRPがCLNPに向かって狙うので、さらなる仕事がIPとST-IIをサポートするためにそれを増大させるのに必要です。 BGPはIPのためのNRの部品にベースとして使用されるでしょう、そして、複数のプロトコル戦略が採用されると、IDRPはCLNPのためのNRの部品にベースとして使用されそうでしょう。 さらなる仕事が、NRの部品のサポートにおけるプロトコルをST-IIに指定するのに必要です。 追加仕事が、BGPに加えられるかもしれない新機能を指定するのに必要であるかもしれません。].
Estrin, Rekhter & Hotz [Page 33] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[33ページ]RFC1322
5.2 Transition
5.2 変遷
The proposed architecture is not intended for full deployment in the short term future. We are proposing this architecture as a goal towards which we can begin guiding our operational and research investment over the next 5 years.
提案されたアーキテクチャは短期間未来の完全な展開のために意図しません。 私たちは次の5年間私たちの操作上と研究投資を誘導し始めることができる目標としてこのアーキテクチャを提案しています。
At the same time, the architecture does not require wholesale overhaul of the existing Internet. The NR component may be phased in gradually. For example, the NR component for IP may be phased in by replacing existing EGP-2 routing with BGP routing. Once the NR component is in place, it can be augmented by the facilities provided by the SDR component.
同時に、アーキテクチャは既存のインターネットの大量のオーバーホールを必要としません。 NRの部品は徐々に段階的に導入されるかもしれません。 例えば、IPのためのNRの部品は、既存のEGP-2ルーティングをBGPルーティングに取り替えることによって、段階的に導入されるかもしれません。 NRの部品が適所にいったんあると、SDRの部品によって提供された施設でそれを増大させられることができます。
The most critical components of the architecture needed to support SDR include route installation and packet forwarding in the routers that support SDR. Participation as a transit routing domain requires that the domain can distribute local configuration information (LCI) and that some of its routers implement the route installation and route management protocols. Participation as a source requires that the domain have access to a RS to compute routes, and that the source domain has a router that implements the route installation and route management protocols. In addition, a network management entity must describe local configuration information and send it to the central repository(ies). A collection and distribution mechanism must be put in place, even if it is centralized.
SDRをサポートするのに必要であるアーキテクチャの最も重要な成分はSDRをサポートするルータにルートインストールとパケット推進を含んでいます。トランジット経路ドメインとしての参加は、ドメインがローカルの設定情報(LCI)を分配できて、ルータのいくつかが、ルートがインストールとルート管理プロトコルであると実装するのを必要とします。 ソースとしての参加はドメインがルートを計算するためにRSに近づく手段を持って、ソースドメインにはルートインストールとルートが管理プロトコルであると実装するルータがあるのを必要とします。 さらに、ネットワークマネージメント実体は、中央倉庫(ies)にローカルの設定情報について説明して、それを送らなければなりません。 それが集結されても、集散メカニズムを適所に置かなければなりません。
Estrin, Rekhter & Hotz [Page 34] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[34ページ]RFC1322
6.0 Conclusions and Future Work
6.0の結論と未来は働いています。
In summary, the proposed architecture combines hop-by-hop path- vector, and source-routed link-state, protocols, and uses each for that which it is best suited: NR uses PV and multiple, flexible, levels of confederations to support efficient routing of generic packets over generic routes; SDR uses LS computation over a database of configured and dynamic information to route special traffic over special routes. In the past, the community has viewed these two as mutually exclusive; to the contrary, they are quite complementary and it is fortunate that we, as a community, have pursued both paths in parallel. Together these two approaches will flexibly and efficiently support TOS and policy routing in very large global internets.
概要では、提案されたアーキテクチャはホップごとの経路ベクトル、およびソースによって発送されたリンク状態を合併します、プロトコル、そして、それぞれそれへのそれがそうである用途は最もよく適合しました: NRはジェネリックルートの上でジェネリックパケットの効率的なルーティングをサポートするのにPV、および複数の、そして、フレキシブルなレベルの同盟者を使用します。 SDRは、特別なルートの上に特別なトラフィックを発送するのに構成されてダイナミックな情報に関するデータベースの上のLS計算を使用します。 過去に、共同体は、これらの2が互いに排他的であるとみなしました。 それと反対に、それらはかなり補足的です、そして、私たちが共同体として平行な両方の経路を追求したのは、幸いです。 これらの2つのアプローチが、TOSと方針が非常に大きいグローバルなインターネットでルーティングであると一緒に、柔軟に効率的にサポートするでしょう。
It is now time to consider the issues associated with combining and integrating the two. We must go back and look at both architectures and their constituent protocols, eliminate redundancies, fill in new holes, and provide seamless integration.
今、問題を考える時間が結合と統合による2を関連づけたということです。 私たちは、アーキテクチャとそれらの構成しているプロトコルの両方が戻って、見て、冗長さをなくして、新しい穴をふさいでいて、シームレス統合を提供しなければなりません。
7.0 Acknowledgments
7.0 承認
We would like to thank Hans-Werner Braun (San Diego Supercomputer Center), Lee Breslau (USC), Scott Brim (Cornell University), Tony Li (cisco Systems), Doug Montgomery (NIST), Tassos Nakassis (NIST), Martha Steenstrup (BBN), and Daniel Zappala (USC) for their comments on a previous draft.
前の草稿の彼らのコメントについてハンス-ヴェルナー(サンディエゴのSupercomputerセンター)、ブラウンリー・ブレスラウ(USC)スコットBrim(コーネル大学)、トニー李(コクチマスSystems)、ダグモンゴメリ(NIST)タソスNakassis(NIST)、マーサ・ステーンストルプ(BBN)、およびダニエルZappala(USC)に感謝申し上げます。
Estrin, Rekhter & Hotz [Page 35] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[35ページ]RFC1322
8.0 References
8.0の参照箇所
[ANSI 87-150R] "Intermediate System to Intermediate System Intra- Domain Routing Exchange Protocol", ANSI X3S3.3/87-150R.
[ANSI87-150R] 「中間システムイントラドメインルート設定交換プロトコルへの中間システム」、ANSI X3S3.3/87-150R。
[BGP 91] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-3)", RFC 1267, cisco Systems, T.J. Watson Research Center, IBM Corp., October 1991.
[BGP91]のロッキード、K.、およびY.Rekhter、「ボーダ・ゲイトウェイ・プロトコル3(BGP-3)」、RFC1267コクチマスSystems、T.J.ワトソン研究所、IBM社(1991年10月)。
[Breslau-Estrin 91] Breslau, L., and D. Estrin, "Design and Evaluation of Inter-Domain Policy Routing Protocols", To appear in Journal of Internetworking Research and Experience, 1991. (Earlier version appeared in ACM Sigcomm 1990.)
[ブレスラウ-Estrin91] ブレスラウ、L.、およびD.Estrin、ToはInternetworking ResearchとExperience、1991年のJournalで「相互ドメイン方針ルーティング・プロトコルのデザインと評価」ように見えます。 (以前のバージョンはACM Sigcomm1990に現れました。)
[Clark 90] Clark, D., "Policy Routing in Internetworks", Journal of Internetworking Research and Experience, Vol. 1, pp. 35-52, 1990.
[クラーク90]クラークとD.と「インターネットワークにおける方針ルート設定」とInternetworking ResearchのJournalとExperience、Vol.1、ページ 35-52, 1990.
[Dijkstra 59] Dijkstra, E., "A Note on Two Problems in Connection with Graphs", Numer. Math., Vol. 1, 1959, pp. 269-271.
[ダイクストラ59]ダイクストラ、E.、「グラフに関する2つの問題に関する注」Numer。 数学、Vol.1、1959、ページ 269-271.
[ECMA89] "Inter-Domain Intermediate Systems Routing", Draft Technical Report ECMA TR/ISR, ECMA/TC32-TG 10/89/56, May 1989.
[ECMA89]「相互ドメイン中間システムルート設定」は1989年5月に技術報告書ECMA TR/ISR、ECMA/TC32-TG10/89/56を作成します。
[EGP] Rosen, E., "Exterior Gateway Protocol (EGP)", RFC 827, BBN, October 1982.
[EGP] ローゼン、E.、「外のゲートウェイプロトコル(EGP)」、RFC827、BBN、1982年10月。
[Estrin 89] Estrin, D., "Policy Requirements for Inter Administrative Domain Routing", RFC 1125, USC Computer Science Department, November 1989.
[Estrin89] Estrin、D.、「間の管理ドメインルート設定のための方針要件」、RFC1125、USCコンピュータ理学部、1989年11月。
[Estrin-etal91] Estrin, D., Breslau, L., and L. Zhang, "Protocol Mechanisms for Adaptive Routing in Global Multimedia Internets", University of Southern California, Computer Science Department Technical Report, CS-SYS-91-04, November 1991.
[Estrin-etal91]Estrin(D.、ブレスラウ、L.、およびL.チャン)は「グローバルなマルチメディアインターネットにおける最適経路指定のためにメカニズムについて議定書の中で述べます」、南カリフォルニアの大学、コンピュータサイエンス部の技術報告書、Cs-SYS-91-04、1991年11月。
[Hedrick 88] Hedrick, C., "Routing Information Protocol", RFC 1058, Rutgers University, June 1988.
[ヘドリック88]ヘドリック、C.、「ルーティング情報プロトコル」、RFC1058、ラトガース大学、1988年6月。
[Honig 90] Honig, J., Katz, D., Mathis, M., Rekhter, Y., and J. Yu, "Application of the Border Gateway Protocol in the Internet", RFC 1164, Cornell Univ. Theory Center, Merit/NSFNET, Pittsburgh Supercomputing Center, T.J. Watson Research Center, IBM Corp., June 1990.
[ホニッグ90]ホニッグ、J.、キャッツ、D.、マシス、M.、Rekhter、Y.、およびJ.ユー、「インターネットでのボーダ・ゲイトウェイ・プロトコルの応用」、RFC1164、コーネル大学 理論センター、長所/NSFNET、ピッツバーグのSupercomputingセンターT.J.ワトソン研究所、IBM社、1990年6月。
[IDPR90] Steenstrup, M., "Inter-Domain Policy Routing Protocol Specification and Usage: Version 1", Work in Progress, February 1991.
[IDPR90]ステーンストルプ、M.、「相互ドメイン方針ルート設定は仕様と用法を議定書の中で述べます」。 バージョン1インチ、進歩、1991年2月に働いてください。
Estrin, Rekhter & Hotz [Page 36] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[36ページ]RFC1322
[IDRP91] "Intermediate System to Intermediate System Inter-domain Routeing Exchange Protocol", ISO/IEC/ JTC1/SC6 CD10747.
[IDRP91] 「中間システム相互ドメインRouteing交換プロトコルへの中間システム」、ISO/IEC/JTC1/SC6 CD10747。
[ISIS10589] "Information Processing Systems - Telecommunications and Information Exchange between Systems - Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the protocol for providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589.
[ISIS10589] 「情報処理システム--システムの間のテレコミュニケーションと情報交換--プロトコルに関連したコネクションレスなモードネットワーク・サービス(ISO8473)を提供する使用のための中間システムイントラドメインルート設定交換プロトコルへの中間システム」、ISO/IEC10589。
[ISO-473 88] "Protocol for providing the connectionless-mode network service", ISO 8473, 1988.
[ISO-473 88] 「コネクションレスなモードネットワーク・サービスを提供するためのプロトコル」、ISO8473、1988。
[Jaffee 82] Jaffee, J., and F. Moss, "A Responsive Distributed Routing Algorithm for Computer Networks", IEEE Transactions on Communications, July 1982.
[ジャッフェ82]ジャッフェ、J.、およびF.こけ、「コンピュータネットワークのための敏感な分配されたルーティング・アルゴリズム」、コミュニケーション(1982年7月)に関するIEEEトランザクション。
[Little 89] Little, M., "Goals and Functional Requirements for Inter-Autonomous System Routing", RFC 1126, SAIC, October 1989.
[小さい89] 少しと、M.と、「相互自律システムルート設定のための目標と機能条件書」、RFC1126、SAIC、10月1989日
[Oran 89] Oran, D., "Expert's Paper: The Relationship between Addressing and Routeing", ISO/JTC1/SC6/WG2, 1989.
[オラン89] オラン、D.、「専門家のものは以下に紙を張ります」。 「アドレシングとRouteingとの関係」、ISO/JTC1/SC6/WG2、1989。
[OSPF] Moy, J., "The Open Shortest Path First (OSPF) Specification", RFC 1131, Proteon, October 1989.
[OSPF] Moy、J.、「開いている最短パス最初(OSPF)の仕様」、RFC1131、Proteon、1989年10月。
[Postel 81] Postel, J., "Internet Protocol", RFC 791, DARPA, September 1981.
[ポステル81]ポステル、J.、「インターネットプロトコル」、RFC791、DARPA、1981年9月。
[Rekhter 91] Rekhter, Y., "IDRP protocol analysis: storage complexity", IBM Research Report RC17298(#76515), October 1991.
Rekhter、[Rekhter91]Y.、「IDRPは分析について議定書の中で述べます」。 「ストレージの複雑さ」、IBM Research Report RC17298(#76515)、1991年10月。
[Shin87] Shin, K., and M. Chen, "Performance Analysis of Distributed Routing Strategies Free of Ping-Pong-Type Looping", IEEE Transactions on Computers, February 1987.
コンピュータ(1987年2月)の上の[Shin87]向こうずね、K.とM.チェン、「ピンポンタイプループを有でない分配されたルート設定戦略の機能解析」IEEEトランザクション。
[ST2-90] Topolcic, C., "Experimental Internet Stream Protocol, version 2 (ST II)", RFC 1190, CIP Working Group, October 1990.
[ST2-90]Topolcic、C.、「実験インターネットStreamプロトコル、バージョン2(ST II)」、RFC1190、CIP作業部会、10月1990
[Zaumen 91] Zaumen, W., and J. Garcia-Luna-Aceves, "Dynamics of Link State and Loop-free Distance-Vector Routing Algorithms", ACM Sigcomm '91, Zurich, Switzerland, September 1991.
[Zaumen91] Zaumen、W.、およびJ.ガルシアルーナAceves、「リンク状態と無輪のDistanceVector方式アルゴリズムの力学」、ACM Sigcomm91年(チューリッヒ(スイス)1991年9月)。
[Zhang 91] Zhang, L., "Virtual Clock: A New Traffic Control Algorithm for Packet Switching Networks".
[チャン91]チャン、L.、「仮想の時計:」 「パケット交換網のための新しいトラフィックコントロールアルゴリズム。」
Estrin, Rekhter & Hotz [Page 37] RFC 1322 A Unified Approach to Inter-Domain Routing May 1992
相互ドメインルート設定1992年5月へのEstrin、Rekhter、および統一されたアプローチあたりHotz[37ページ]RFC1322
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Authors' Addresses
作者のアドレス
Deborah Estrin University of Southern California Computer Science Department, MC 0782 Los Angeles, California 90089-0782
南カリフォルニアコンピュータ理学部、ロサンゼルスのM.C.0782、カリフォルニア90089-0782のデボラEstrin大学
Phone: (310) 740-4524 EMail: estrin@usc.edu
以下に電話をしてください。 (310) 740-4524 メールしてください: estrin@usc.edu
Yakov Rekhter IBM T.J. Watson Research Center P.O. Box 218 Yorktown Heights, New York 10598
ニューヨーク ヤコフRekhter IBM T.J.ワトソン研究所私書箱218ヨークタウンの高さ、10598
Phone: (914) 945-3896 EMail: yakov@ibm.com
以下に電話をしてください。 (914) 945-3896 メールしてください: yakov@ibm.com
Steven Hotz University of Southern California Computer Science Department, MC 0782 Los Angeles, California 90089-0782
南カリフォルニアコンピュータ理学部、ロサンゼルスのM.C.0782、カリフォルニア90089-0782のスティーブンHotz大学
Phone: (310) 822-1511 EMail: hotz@usc.edu
以下に電話をしてください。 (310) 822-1511 メールしてください: hotz@usc.edu
Estrin, Rekhter & Hotz [Page 38]
Estrin、Rekhter、およびHotz[38ページ]
一覧
スポンサーリンク
