RFC1478 日本語訳
1478 An Architecture for Inter-Domain Policy Routing. M. Steenstrup. June 1993. (Format: TXT=90673 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Steenstrup
Request for Comments: 1478 BBN Systems and Technologies
June 1993
コメントを求めるワーキンググループM.ステーンストルプの要求をネットワークでつないでください: 1478台のBBNシステムと技術1993年6月
An Architecture for Inter-Domain Policy Routing
相互ドメイン方針ルート設定のための構造
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
We present an architecture for inter-domain policy routing (IDPR). The objective of IDPR is to construct and maintain routes, between source and destination administrative domains, that provide user traffic with the requested services within the constraints stipulated for the domains transited. The IDPR architecture is designed to accommodate an internetwork containing tens of thousands of administrative domains with heterogeneous service requirements and restrictions.
私たちは相互ドメイン方針ルーティング(IDPR)のために構造を提示します。 IDPRの目的は、ソースと目的地の管理ドメインの間の通過されたドメインに規定された規制の中で要求されたサービスをユーザ交通に提供するルートを構成して、維持することです。 IDPR構造は、異種のサービス要件と制限がある何万もの管理ドメインを含むインターネットワークを収容するように設計されています。
Contributors
貢献者
The following people have contributed to the IDPR architecture: Bob Braden, Lee Breslau, Ross Callon, Noel Chiappa, Dave Clark, Pat Clark, Deborah Estrin, Marianne Lepp, Mike Little, Martha Steenstrup, Zaw-Sing Su, Paul Tsuchiya, and Gene Tsudik. Yakov Rekhter supplied many useful comments on a previous draft of this document.
以下の人々はIDPR構造に貢献しました: ボブ・ブレーデン、リー・ブレスラウ、ロスCallon、クリスマスChiappa、デーブ・クラーク、パット・クラーク、デボラEstrin、マリアンエ・レップ、マイク・リトル、マーサ・ステーンストルプはSu、ポールTsuchiya、および遺伝子TsudikをZaw歌います。 ヤコフRekhterはこのドキュメントの前の草稿の多くの役に立つコメントを供給しました。
Steenstrup [Page 1] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[1ページ]RFC1478IDPR構造1993年6月
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Internet Environment. . . . . . . . . . . . . . . . . . . 4 2. Approaches to Policy Routing. . . . . . . . . . . . . . . . . . 5 2.1. Policy Route Generation . . . . . . . . . . . . . . . . . . . 5 2.1.1. Distance Vector Approach. . . . . . . . . . . . . . . . . . 5 2.1.2. Link State Approach . . . . . . . . . . . . . . . . . . . . 7 2.2. Routing Information Distribution. . . . . . . . . . . . . . . 8 2.2.1. Distance Vector Approach. . . . . . . . . . . . . . . . . . 8 2.2.2. Link State Approach . . . . . . . . . . . . . . . . . . . .10 2.3. Message Forwarding along Policy Routes. . . . . . . . . . . .10 2.3.1. Hop-by-Hop Approach . . . . . . . . . . . . . . . . . . . .11 2.3.1.1. A Clarification . . . . . . . . . . . . . . . . . . . . .11 2.3.2. Source Specified Approach . . . . . . . . . . . . . . . . .12 3. The IDPR Architecture . . . . . . . . . . . . . . . . . . . . .13 3.1. IDPR Functions. . . . . . . . . . . . . . . . . . . . . . . .13 3.2. IDPR Entities . . . . . . . . . . . . . . . . . . . . . . . .13 3.2.1. Path Agents . . . . . . . . . . . . . . . . . . . . . . . .16 3.2.2. IDPR Servers. . . . . . . . . . . . . . . . . . . . . . . .17 3.2.3. Entity Identifiers. . . . . . . . . . . . . . . . . . . . .19 3.3. Security and Reliability. . . . . . . . . . . . . . . . . . .20 3.3.1. Retransmissions and Acknowledgements. . . . . . . . . . . .20 3.3.2. Integrity Checks. . . . . . . . . . . . . . . . . . . . . .21 3.3.3. Source Authentication . . . . . . . . . . . . . . . . . . .21 3.3.4. Timestamps. . . . . . . . . . . . . . . . . . . . . . . . .21 3.4. An Example of IDPR Operation. . . . . . . . . . . . . . . . .22 4. Accommodating a Large, Heterogeneous Internet . . . . . . . . .25 4.1. Domain Level Routing. . . . . . . . . . . . . . . . . . . . .25 4.2. Route Generation. . . . . . . . . . . . . . . . . . . . . . .27 4.3. Super Domains . . . . . . . . . . . . . . . . . . . . . . . .29 4.4. Domain Communities. . . . . . . . . . . . . . . . . . . . . .30 4.5. Robustness in the Presence of Failures. . . . . . . . . . . .31 4.5.1. Path Repair . . . . . . . . . . . . . . . . . . . . . . . .31 4.5.2. Partitions. . . . . . . . . . . . . . . . . . . . . . . . .33 5. References. . . . . . . . . . . . . . . . . . . . . . . . . . .XX 5. Security Considerations . . . . . . . . . . . . . . . . . . . .34 6. Author's Address . . . . . . . . . . . . . . . . . . . . . . .34
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. インターネット環境。 . . . . . . . . . . . . . . . . . . 4 2. 方針ルート設定へのアプローチ。 . . . . . . . . . . . . . . . . . 5 2.1. 方針ルート世代. . . . . . . . . . . . . . . . . . . 5 2.1.1。 ベクトルアプローチを遠ざけてください。 . . . . . . . . . . . . . . . . . 5 2.1.2. 州のアプローチ. . . . . . . . . . . . . . . . . . . . 7 2.2をリンクしてください。 情報流通を発送します。 . . . . . . . . . . . . . . 8 2.2.1. ベクトルアプローチを遠ざけてください。 . . . . . . . . . . . . . . . . . 8 2.2.2. 州のアプローチ. . . . . . . . . . . . . . . . . . . .10 2.3をリンクしてください。 方針ルートに沿ったメッセージ推進。 . . . . . . . . . . .10 2.3.1. ホップで、.1にアプローチ. . . . . . . . . . . . . . . . . . . .11 2.3.1を飛び越してください。 明確化. . . . . . . . . . . . . . . . . . . . .11 2.3.2。 ソースはアプローチ. . . . . . . . . . . . . . . . .12 3を指定しました。 IDPR構造. . . . . . . . . . . . . . . . . . . . .13 3.1。 IDPRは機能します。 . . . . . . . . . . . . . . . . . . . . . . .13 3.2. IDPR実体. . . . . . . . . . . . . . . . . . . . . . . .13 3.2.1。 経路エージェント. . . . . . . . . . . . . . . . . . . . . . . .16 3.2.2。 IDPRサーバ。 . . . . . . . . . . . . . . . . . . . . . . .17 3.2.3. エンティティ識別名。 . . . . . . . . . . . . . . . . . . . .19 3.3. セキュリティと信頼性。 . . . . . . . . . . . . . . . . . .20 3.3.1. Retransmissionsと承認。 . . . . . . . . . . .20 3.3.2. 保全はチェックします。 . . . . . . . . . . . . . . . . . . . . .21 3.3.3. ソース認証. . . . . . . . . . . . . . . . . . .21 3.3.4。 タイムスタンプ。 . . . . . . . . . . . . . . . . . . . . . . . .21 3.4. IDPR操作に関する例。 . . . . . . . . . . . . . . . .22 4. 大きくて、異種のインターネット. . . . . . . . .25 4.1を収容します。 ドメインレベルルート設定。 . . . . . . . . . . . . . . . . . . . .25 4.2. 世代を発送してください。 . . . . . . . . . . . . . . . . . . . . . .27 4.3. 最高のドメイン. . . . . . . . . . . . . . . . . . . . . . . .29 4.4。 ドメイン共同体。 . . . . . . . . . . . . . . . . . . . . .30 4.5. 失敗があるとき丈夫さ。 . . . . . . . . . . .31 4.5.1. 経路修理. . . . . . . . . . . . . . . . . . . . . . . .31 4.5.2。 仕切ります。 . . . . . . . . . . . . . . . . . . . . . . . .33 5. 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . .XX5。 セキュリティ問題. . . . . . . . . . . . . . . . . . . .34 6。 作者のアドレス… .34
Steenstrup [Page 2] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[2ページ]RFC1478IDPR構造1993年6月
1. Introduction
1. 序論
As data communications technologies evolve and user populations grow, the demand for internetworking increases. Internetworks usually proliferate through interconnection of autonomous, heterogeneous networks administered by separate authorities. We use the term "administrative domain" (AD) to refer to any collection of contiguous networks, gateways, links, and hosts governed by a single administrative authority who selects the intra-domain routing procedures and addressing schemes, specifies service restrictions for transit traffic, and defines service requirements for locally- generated traffic.
データ通信技術が発展して、ユーザの母集団が増加しているのに従って、インターネットワーキングの需要は増加します。 通常、インターネットワークは別々の当局によって管理された自治の、そして、種々雑多なネットワークのインタコネクトを通して増殖します。 私たちは隣接のネットワークのどんな収集も参照するのに用語「管理ドメイン」(AD)を使用します、ゲートウェイ、リンク、そして、ホストはただ一つの職務権限でだれがイントラドメインルーティング手順とアドレシング計画を選択して、トランジット交通にサービス制限を指定して、局所的に発生した交通とサービス要件を定義するかを治めました。
Interconnection of administrative domains can broaden the range of services available in an internetwork. Hence, traffic with special service requirements is more likely to receive the service requested. However, administrators of domains offering special transit services are more likely to establish stringent access restrictions, in order to maintain control over the use of their domains' resources.
管理ドメインのインタコネクトはインターネットワークで利用可能なサービスの範囲を広げることができます。 したがって、特別なサービス要件がある交通は要求されたサービスをより受けそうです。 しかしながら、特別なトランジットサービスを提供するドメインの管理者は厳しいアクセス制限をより確立しそうです、それらのドメインのリソースの使用のコントロールを維持するために。
An internetwork composed of many domains with diverse service requirements and restrictions requires "policy routing" to transport traffic between source and destination. Policy routing constitutes route generation and message forwarding procedures for producing and using routes that simultaneously satisfy user service requirements and respect transit domain service restrictions.
さまざまのサービス要件と制限で多くのドメインから構成されたインターネットワークは、ソースと目的地の間の交通を輸送するために「方針ルーティング」を必要とします。 方針ルーティングはルート世代を構成します、そして、そんなに同時にルートを作成して、使用するためのメッセージ推進手順はユーザサービス要件と敬意トランジットドメインサービス制限を満たします。
With policy routing, each domain administrator sets "transit policies" that dictate how and by whom the resources within its domain should be used. Transit policies are usually public, and they specify offered services comprising:
方針ルーティングで、それぞれのドメイン管理者はその方法を書き取って、ドメインの中のリソースが使用されるべきである「運送保険証券」を設定します。 通常、運送保険証券は公共です、そして、それらは以下を包括する提供サービスを指定します。
- Access restrictions: e.g., applied to traffic to or from certain
domains or classes of users.
- 制限にアクセスしてください: 例えば、ユーザかある一定のドメインかクラスのユーザからの交通に適用されています。
- Quality: e.g., delay, throughput, or error characteristics.
- 品質: 例えば、遅れ、スループット、または誤りの特性。
- Monetary cost: e.g., charge per byte, message, or unit time.
- 貨幣原価: 例えば、1バイトあたりの料金、メッセージ、またはユニット時間。
Each domain administrator also sets "source policies" for traffic originating within its domain. Source policies are usually private, and they specify requested services comprising:
また、それぞれのドメイン管理者はドメインの中で由来する交通のための「ソース方針」を設定します。 通常、ソース方針は個人的です、そして、それらは以下を包括する要求されたサービスを指定します。
- Access restrictions: e.g., domains to favor or avoid in routes.
- 制限にアクセスしてください: 例えばルートで支持するか、または避けるドメイン。
- Quality: e.g., acceptable delay, throughput, or reliability.
- 品質: 例えば、許容できる遅れ、スループット、または信頼性。
- Monetary cost: e.g., acceptable session cost.
- 貨幣原価: 例えば、許容できるセッション費用。
Steenstrup [Page 3] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[3ページ]RFC1478IDPR構造1993年6月
In this document, we describe an architecture for inter-domain policy routing (IDPR), and we provide a set of functions which can form the basis for a suite of IDPR protocols and procedures.
本書では、私たちは相互ドメイン方針ルーティング(IDPR)のために構造について説明します、そして、ひとそろいのIDPRプロトコルと手順の基礎を形成できる関数群を提供します。
1.1. The Internet Environment
1.1. インターネット環境
The Internet currently comprises over 7000 operational networks and over 10,000 registered networks. In fact, for the last several years, the number of constituent networks has approximately doubled annually. Although we do not expect the Internet to sustain this growth rate, we must provide an architecture for IDPR that can accommodate the Internet five to ten years in the future. According to the functional requirements for inter-autonomous system (i.e., inter-domain) routing set forth in [6], the IDPR architecture and protocols must be able to handle O(100,000) networks distributed over O(10,000) domains.
インターネットは現在、7000以上の操作上のネットワークと1万以上の登録されたネットワークを包括します。 事実上、ここ数年間、構成しているネットワークの数は周囲で毎年倍増しています。 この成長率を支えるためにインターネットを予想しませんが、私たちは将来5〜10年間インターネットを収容できるIDPRに構造を供給しなければなりません。 [6]に詳しく説明された相互自律システム(すなわち、相互ドメイン)ルーティングのための機能条件書によると、IDPR構造とプロトコルはO(10,000)ドメインの上に分配されたO(100,000)ネットワークを扱うことができなければなりません。
Internet connectivity has increased along with the number of component networks. In the early 1980s, the Internet was purely hierarchical, with the ARPANET as the single backbone. The current Internet possesses a semblance of a hierarchy in the collection of backbone, regional, metropolitan, and campus domains that compose it. However, technological, economical, and political incentives have prompted the introduction of inter-domain links outside of those in the strict hierarchy. Hence, the Internet has the properties of both hierarchical and mesh connectivity.
インターネットの接続性はコンポーネントネットワークの数と共に増加しました。 インターネットは1980年代前半にただ一つの背骨としてアルパネットで純粋に階層的でした。 現在のインターネットには、地方の、そして、首都の背骨、およびそれを構成するキャンパスドメインの収集における、階層構造の類似があります。 しかしながら、技術的で、経済的で、政治上の誘因はそれらの外で厳しい階層構造で相互ドメインリンクの導入をうながしました。 したがって、インターネットには、ともに階層的、そして、メッシュ接続性の特性があります。
We expect that the Internet will evolve in the following way. Over the next five years, the Internet will grow to contain O(10) backbone domains, most providing connectivity between many source and destination domains and offering a wide range of qualities of service, for a fee. Most domains will connect directly or indirectly to at least one Internet backbone domain, in order to communicate with other domains. In addition, some domains may install direct links to their most favored destinations. Domains at the lower levels of the hierarchy will provide some transit service, limited to traffic between selected sources and destinations. However, the majority of Internet domains will be "stubs", that is, domains that do not provide any transit service for other domains.
私たちは、インターネットが以下の方法で発展すると予想します。 次の5年間、インターネットはO(10)背骨ドメインを含むようになるでしょう、ソースと目的地ドメインを多くの間の接続性に最も提供して、さまざまなサービスの品質を提供して、有料で。 ほとんどのドメインが直接か間接的に少なくとも1つのインターネットの基幹ドメインに接続するでしょう、他のドメインで交信するために。 さらに、いくつかのドメインがそれらの最も好評な目的地に直リンクをインストールするかもしれません。 階層構造の下のレベルにおけるドメインは選択されたソースと目的地の間の交通に制限された何らかのトランジットサービスを提供するでしょう。 しかしながら、インターネットドメインの大部分が「スタッブ」でしょう、すなわち、他のドメインのための少しのトランジットサービスも提供しないドメイン。
The bulk of Internet traffic will be generated by hosts in these stub domains, and thus, the applications running in these hosts will determine the traffic service requirements. We expect application diversity encompassing electronic mail, desktop videoconferencing, scientific visualization, and distributed simulation, to list a few. Many of these applications have strict requirements on loss, delay, and throughput.
インターネットトラフィックの大半がホストによってこれらのスタッブドメインで発生するでしょう、そして、その結果、これらのホストへ駆け込むアプリケーションは交通サービス要件を決定するでしょう。 私たちはいくつかを記載するために電子メール、デスクトップテレビ会議、サイエンティフィック・ビジュアライゼーション、および分配されたシミュレーションを包含するアプリケーションの多様性を予想します。 これらのアプリケーションの多くには、損失、遅れ、およびスループットに関する厳しい要件があります。
Steenstrup [Page 4] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[4ページ]RFC1478IDPR構造1993年6月
Ensuring that Internet traffic traverses routes that provide the required services without violating domain usage restrictions will be the task of policy routing in the Internet in the next several years. Refer to [1]-[10] for more information on the role of policy routing in the Internet.
インターネットトラフィックがドメイン使用制限に違反しないで必要なサービスを提供するルートを横断するのを確実にするのが数年内に仕事を課すことのようにインターネットでの方針ルーティングについてなるでしょう。 [1]を参照してください--インターネットでの方針ルーティングの役割に関する詳しい情報のための[10]。
2. Approaches to Policy Routing
2. 方針ルート設定へのアプローチ
In this section, we provide an assessment of candidate approaches to policy routing, concentrating on the "distance vector" and "link state" alternatives for routing information distribution and route generation and on the "hop-by-hop" and "source specified" alternatives for data message forwarding. The IDPR architecture supports link state routing information distribution and route generation in conjunction with source specified message forwarding. We justify these choices for IDPR below.
このセクションでは、私たちは、データメッセージ推進のためにルーティング情報流通とルート世代のための「距離ベクトル」と「リンク状態」代替手段と、そして、「ホップごとの」に集中して、掘るのを方針への候補アプローチの査定に提供して、「ソースは指定したこと」に代替手段を提供します。 構造が支持するIDPRはソースの指定されたメッセージ推進に関連して州のルーティング情報流通とルート世代をリンクします。 私たちは以下のIDPRのためにこれらの選択を正当化します。
2.1. Policy Route Generation
2.1. 方針ルート世代
We present policy route generation from the distance vector perspective and from the link state perspective.
私たちは距離ベクトル見解とリンク州の見解からの方針ルート世代を提示します。
2.1.1. Distance Vector Approach
2.1.1. 距離ベクトルアプローチ
Distance vector route generation distributes the computation of a single route among multiple routing entities along the route. Hence, distance vector route generation is potentially susceptible to the problems of routing loop formation and slow adaptation to changes in an internetwork. However, there exist several techniques that can be applied during distance vector route generation to reduce the severity of, or even eliminate, these problems. For information on a loop-free, quickly adapting distance vector routing procedure, consult [13] and [14].
距離ベクトルルート世代はルートに沿った複数のルーティング実体にただ一つのルートの計算を広げます。 したがって、距離ベクトルルート世代は潜在的にインターネットワークにおけるルーティングループと変化への遅い適合の問題に影響されやすいです。 しかしながら、厳しさを減少させる距離ベクトルルート世代の間、適用されることさえできるか、または排泄されることさえできるいくつかのテクニックが存在しています、これらの問題。輪なしの、そして、すぐに適合している距離ベクトルルーティング手順の情報に関して、[13]と[14]に相談してください。
During policy route generation, each recipient of a distance vector message assesses the acceptability of the associated route and determines the set of neighboring domains to which the message should be propagated. In the context of policy routing, both of the following conditions are necessary for route acceptability:
方針ルート世代の間、距離ベクトルメッセージの各受取人は、関連ルートの受容性を評価して、メッセージが伝播されるべきである隣接しているドメインのセットを決定します。 方針ルーティングの文脈では、以下の条件の両方がルートの受容性に必要です:
- The route is consistent with at least one transit policy for each
domain, not including the current routing entity's domain, contained
in the route. To enable each recipient of a distance vector message
to verify consistency of the associated route with the transit
policies of all constituent domains, each routing entity should
include its domain's identity and transit policies in each
acceptable distance vector message it propagates.
- ルートは各ドメインあたり少なくとも1つの運送保険証券と一致しています、ルートに含まれた現在のルーティング実体のドメインを含んでいなくて。 すべての構成しているドメインの運送保険証券で関連ルートの一貫性について確かめる距離ベクトルメッセージの各受取人を可能にするために、それぞれのルーティング実体はそれが伝播するそれぞれの許容できる距離ベクトルメッセージにドメインのアイデンティティと運送保険証券を含むべきです。
Steenstrup [Page 5] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[5ページ]RFC1478IDPR構造1993年6月
- The route is consistent with at least one source policy for at least
one domain in the Internet. To enable each recipient of a distance
vector message to verify consistency of the associated route with
the source policies of particular domains, each domain must provide
other domains with access to its source policies.
- インターネットの少なくとも1つのドメインにおいて、ルートは少なくとも1つのソース方針と一致しています。 特定のドメインのソース方針で関連ルートの一貫性について確かめる距離ベクトルメッセージの各受取人を可能にするために、各ドメインはソース方針へのアクセスを他のドメインに提供しなければなりません。
In addition, at least one of the following conditions is necessary for route acceptability:
さらに、少なくとも以下の条件の1つがルートの受容性に必要です:
- The route is consistent with at least one of the transit policies
for the current routing entity's domain. In this case, the routing
entity accepts the distance vector message and then proceeds to
compare the associated route with its other routes to the
destinations listed in the message. If the routing entity decides
that the new route is preferable, it updates the distance vector
message with its domain's identity and transit policies and then
propagates the message to the appropriate neighboring domains. We
discuss distance vector message distribution in more detail in
section 2.2.1.
- 現在のルーティング実体のドメインにおいて、ルートは少なくとも運送保険証券の1つと一致しています。 この場合、ルーティング実体は、距離ベクトルメッセージを受け入れて、次に、メッセージに記載された目的地への他のルートと関連ルートを比べかけます。 ルーティング実体が、新しいルートが望ましいと決めるなら、それは、ドメインのアイデンティティと運送保険証券で距離ベクトルメッセージをアップデートして、適切な隣接しているドメインにメッセージを伝播します。 私たちはさらに詳細にセクション2.2.1における距離ベクトルメッセージの振分けについて議論します。
The route is consistent with at least one of the source policies for the current routing entity's domain. In this case, the routing entity need not propagate the distance vector message but does retain the associated route for use by traffic from local hosts, bound for the destinations listed in the message.
現在のルーティング実体のドメインにおいて、ルートは少なくともソース方針の1つと一致しています。 この場合、ルーティング実体は、距離ベクトルメッセージを伝播する必要はありませんが、メッセージに記載された目的地に向かっているローカル・ホストからの交通で使用のための関連ルートを保有します。
The routing entity discards any distance vector message that does not meet these necessary conditions.
ルーティング実体はこれらの必要条件を満たさないどんな距離ベクトルメッセージも捨てます。
With distance vector policy route generation, a routing entity may select and store multiple routes of different characteristics, such as qualities of service, to a single destination. A routing entity uses the quality of service information, provided in the transit policies contained in accepted distance vector messages, to discriminate between routes based on quality of service. Moreover, a routing entity may select routes that are specific to certain source domains, provided that the routing entity has access to the source policies of those domains.
ルーティング実体は、距離ベクトル方針ルート世代と共に、異なった特性の複数のルートを選択して、格納するかもしれません、サービスの品質などのように、単一の目的地に。 ルーティング実体は、サービスの質に基づくルートを区別するのに受け入れられた距離ベクトルメッセージに含まれた運送保険証券に提供されたサービスの質情報を使用します。 そのうえ、ルーティング実体はある一定のソースドメインに特定のルートを選択するかもしれません、ルーティング実体がそれらのドメインのソース方針に近づく手段を持っていれば。
In the distance vector context, the flexibility of policy route generation afforded by accounting for other domains' transit and source policies in route selection has the following disadvantages:
遠くに、ベクトル文脈、方針ルート世代の柔軟性は他のドメインのトランジットのための会計を都合しました、そして、ルート選択におけるソース方針には、以下の損失があります:
- Each recipient of a distance vector message must bear the cost of
verifying the consistency of the associated route with the
constituent domains' transit policies.
- 距離ベクトルメッセージの各受取人は構成しているドメインの運送保険証券で関連ルートの一貫性について確かめる費用を負担しなければなりません。
Steenstrup [Page 6] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[6ページ]RFC1478IDPR構造1993年6月
- Source policies must be made public. Thus, a domain must divulge
potentially private information.
- ソース方針を公表しなければなりません。 したがって、ドメインは潜在的に個人情報を明かさなければなりません。
- Each recipient of a distance vector message must bear the
potentially high costs of selecting routes for arbitrary source
domains. In particular, a routing entity must store the source
policies of other domains, account for these source policies during
route selection, and maintain source-specific forwarding
information. Moreover, there must be a mechanism for distributing
source policy information among domains. Depending on the mechanism
selected, distribution of source policies may add to the costs paid
by each routing entity in supporting source-specific routing.
- 距離ベクトルメッセージの各受取人は任意のソースドメインにルートを選択する潜在的に高いコストを負担しなければなりません。 ルーティング実体は、特に、他のドメインのソース方針を格納して、ルート選択の間、これらのソース方針を説明して、ソース特有の推進情報を保守しなければなりません。 そのうえ、ソース方針情報をドメインに分配するためのメカニズムがあるに違いありません。 選択されたメカニズムによって、ソース方針の分配はそれぞれのルーティング実体によってソース特有のルーティングを支持する際に支払われたコストに加えるかもしれません。
We note, however, that failure to distribute source policies to all domains may have unfortunate consequences. In the worst case, a domain may not learn of any acceptable routes to a given destination, even though acceptable routes do exist. For example, suppose that AD V is connected to AD W and that AD W can reach AD Z through either AD X or AD Y. Suppose also that AD~W, as a recipient of distance vector messages originating in AD Z, prefers the route through AD Y to the route through AD X. Furthermore, suppose that AD W has no knowledge of AD V's source policy precluding traffic from traversing AD Y. Hence, AD W distributes to AD V the distance vector message containing the route WYZ but not the distance vector message containing the route WXZ. AD V is thus left with no known route to AD Z, although a viable route traversing AD W and AD X does exist.
しかしながら、私たちは、すべてのドメインにソース方針を分配しない場合不幸な結果を持っているかもしれないことに注意します。 最悪の場合には、ドメインはどんな許容できるルートも与えられた目的地に知らないかもしれません、許容できるルートが存在していますが。 例えば、AD VがAD Wまで接続されて、AD WがAD XかAD ZからAD Y.Supposeのどちらかまで届くことができて、また、その西暦~WがルートよりAD Zのときに由来する距離ベクトルメッセージの受取人としてAD X.FurthermoreまでルートをAD Yまで好むと、仮定してください; そのAD WにAD Vに関する知識が全くないなら、ソース方針がAD Y.Henceを横断するのからの交通を排除して、AD WはAD VまでルートWXZを含む距離ベクトルメッセージではなく、ルートWYZを含む距離ベクトルメッセージを分配します。 AD Vは知られているルートなしでこのようにしてAD Zまで出発されます、AD WとAD Xを横断する実行可能なルートは存在していますが。
2.1.2. Link State Approach
2.1.2. リンク州のアプローチ
Link state route generation permits concentration of the computation of a single route within a single routing entity at the source of the route. In the policy routing context, entities within a domain generate link state messages containing information about the originating domain, including the set of transit policies that apply and the connectivity to adjacent domains, and they distribute these messages to neighboring domains. Each recipient of a link state message stores the routing information for anticipated policy route generation and also distributes it to neighboring domains. Based on the set of link state messages collected from other domains and on its domain's source and transit policies, a routing entity constructs and selects policy routes from its domain to other domains in the Internet.
リンク州のルート世代はルートの源でただ一つのルーティング実体の中でただ一つのルートの計算の集中を可能にします。 方針ルーティング文脈では、ドメインの中の実体は適用される運送保険証券と接続性のセットを隣接しているドメインに含む由来しているドメインの情報を含むリンク州のメッセージを発生させます、そして、それらは隣接しているドメインにこれらのメッセージを分配します。 リンク州のメッセージの各受取人は、予期された方針ルート世代のためにルーティング情報を格納して、また、隣接しているドメインにそれを分配します。 他のドメインとドメインのソースの上に集められたリンク州のメッセージと運送保険証券のセットに基づいて、ルーティング実体は、インターネットでドメインから他のドメインまで方針ルートを構成して、選択します。
We have selected link state policy route generation for IDPR for the following reasons:
私たちは以下の理由でIDPRのためにリンク国策ルート世代を選択しました:
- Each domain has complete control over policy route generation from
the perspective of itself as source.
- 各ドメインには、ソースとして方針ルート世代の完全なコントロールがそれ自体の見解からあります。
Steenstrup [Page 7] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[7ページ]RFC1478IDPR構造1993年6月
- The cost of computing a route is completely contained within the
source domain. Hence, routing entities in other domains need not
bear the cost of generating policy routes that their domains' local
hosts may never use.
- ルートを計算する費用はソースドメインの中に完全に保管されています。 したがって、他のドメインのルーティング実体はそれらのドメインのローカル・ホストが決して使用しないかもしれない方針ルートを発生させる費用を負担する必要はありません。
- Source policies may be kept private and hence need not be
distributed. Thus, there are no memory, processing, or transmission
bandwidth costs incurred for distributing and storing source
policies.
- ソース方針は、個人的に保たれるかもしれなくて、したがって、分配される必要はありません。 したがって、帯域幅コストがソース方針を分配して、格納するために被ったどんなメモリ、処理も、またはトランスミッションもありません。
2.2. Routing Information Distribution
2.2. 経路情報分配
A domain's routing information and the set of domains to which that routing information is distributed each influence the set of generable policy routes that include the given domain. In particular, a domain administrator may promote the generation of routes that obey its domain's transit policies by ensuring that its domain's routing information:
そのルーティング情報が分配されているドメインのドメインのルーティング情報とセットはそれぞれ与えられたドメインを含んでいる生成できる方針ルートのセットに影響を及ぼします。 特に、ドメイン管理者はドメインが情報を発送しているのを確実にすることによってドメインの運送保険証券に従うルートの世代を助成するかもしれません:
- Includes resource access restrictions.
- リソースアクセス制限を含んでいます。
- Is distributed only to those domains that are permitted to use these
resources.
- これらのリソースを使用することが許可されているそれらのドメインだけに分配されます。
Both of these mechanisms, distributing restrictions with and restricting distribution of a domain's routing information, can be applied in both the distance vector and link state contexts.
ドメインのルーティング情報について制限を広げて、分配を制限して、距離ベクトルとリンク州の文脈の両方でこれらのメカニズムの両方を適用できます。
2.2.1. Distance Vector Approach
2.2.1. 距離ベクトルアプローチ
A routing entity may distribute its domain's resource access restrictions by including the appropriate transit policy information in each distance vector it accepts and propagates. Also, the routing entity may restrict distribution of an accepted distance vector message by limiting the set of neighboring domains to which it propagates the message. In fact, restricting distribution of routing information is inherent in the distance vector approach, as a routing entity propagates only the preferred routes among all the distance vector messages that it accepts.
ルーティング実体は、それが受け入れて、伝播する各距離ベクトルに適切な運送保険証券情報を含んでいることによって、ドメインのリソースアクセス制限を広げるかもしれません。 また、ルーティング実体は、それがメッセージを伝播する隣接しているドメインのセットを制限することによって、受け入れられた距離ベクトルメッセージの分配を制限するかもしれません。 事実上、ルーティング情報の制限分配は遠くに固有です。ルーティング実体が受け入れるというすべての距離ベクトルメッセージの中で都合のよいルートだけを伝播するのでベクトルアプローチ。
Although restricting distribution of distance vector messages is easy, coordinating restricted distribution among domains requires each domain to know other domains' distribution restrictions. Each domain may have a set of distribution restrictions that apply to all distance vector messages generated by that domain as well as sets of distribution restrictions that apply to distance vector messages generated by other domains.
距離ベクトルメッセージの分配を制限するのは簡単ですが、ドメインの中で制限された分配を調整するのは、他のドメインの分配制限を知るために各ドメインを必要とします。 各ドメインには、他のドメインで発生する距離ベクトルメッセージに適用される分配制限のセットと同様にそのドメインで発生するすべての距離ベクトルメッセージに適用される1セットの分配制限があるかもしれません。
Steenstrup [Page 8] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[8ページ]RFC1478IDPR構造1993年6月
As a distance vector message propagates among domains, each routing entity should exercise the distribution restrictions associated with each domain constituting the route thus far constructed. In particular, a routing entity should send an accepted distance vector message to a given neighbor, only if distribution of that message to that neighbor is not precluded by any domain contained in the route.
距離ベクトルメッセージがドメインの中で伝播されるのに従って、それぞれのルーティング実体はこれまでのところルートを構成する各ドメインに関連している制限が構成した分配を運動させるべきです。 特に、ルーティング実体は受け入れられた距離ベクトルメッセージを与えられた隣人に送るべきです、その隣人へのそのメッセージの分配がルートに含まれたどんなドメインによっても排除されない場合にだけ。
To enable a routing entity to exercise these distribution restrictions, each domain must permit other domains access to its routing information distribution restrictions. However, we expect that domains may prefer to keep distribution restrictions, like source policies, private. There are at least two ways to make a domain's routing information distribution restrictions generally available to other domains:
ルーティング実体がこれらの分配制限を運動させるのを可能にするために、各ドメインはルーティング情報流通制限への他のドメインアクセスを可能にしなければなりません。 しかしながら、私たちは、ドメインが、ソース方針のように個人的に分配制限を保つのを好むかもしれないと予想します。 ドメインのルーティング情報流通制限を一般に、他のドメインに利用可能にする少なくとも2つの方法があります:
- Prior to propagation of an accepted distance vector message, a
routing entity includes in the message its domain's distribution
restrictions (all or only those to that apply to the given message).
This method requires no additional protocol for disseminating the
distribution restrictions, but it may significantly increase the
size of each distance vector message.
- 受け入れられた距離ベクトルメッセージの伝播の前に、ルーティング実体はメッセージにドメインの分配制限を含んでいます(それへのものだけが与えられたメッセージに適用されます)。 この方法は分配制限を広めるために追加議定書を全く必要としませんが、それはそれぞれの距離ベクトルメッセージのサイズをかなり増加させるかもしれません。
- Each domain independently disseminates its distribution restrictions
to all other domains, so that each domain will be able to exercise
all other domains' distribution restrictions. This method requires
an additional protocol for disseminating the distribution
restrictions, and it may require a significant amount of memory at
each routing entity for storing all domains' distribution
restrictions.
- 各ドメインは独自に他のすべてのドメインに分配制限を広めます、それぞれのドメインが他のすべてのドメインの分配制限を運動させることができるように。 この方法は分配制限を広めるために追加議定書を必要とします、そして、それはすべてのドメインの分配制限を格納するためにそれぞれのルーティング実体における重要なメモリー容量を必要とするかもしれません。
We note that a domain administrator may describe the optimal distribution pattern of distance vector messages originating in its domain, as a directed graph rooted at its domain. Furthermore, if all domains in the directed graph honor the directionality and if the graph is also acyclic, no routing loops may form, because no two domains are able to exchange distance vector messages pertaining to the same destination. However, an acyclic graph also means that some domains may be unable to discover alternate paths when connectivity between adjacent domains fails, as we show below.
私たちは、ドメイン管理者がドメインで起こる距離ベクトルメッセージの最適の分配パターンについて説明するかもしれないことに注意します、有向グラフがドメインで捜したので。 その上、有向グラフのすべてのドメインが方向性を光栄に思って、また、グラフも非循環であるなら、ルーティング輪は全く形成されないかもしれません、いいえtwo、ドメインが同じ目的地に関係する距離ベクトルメッセージを交換できるので。 しかしながら、また、非循環のグラフは、隣接しているドメインの間の接続性が失敗するとき、いくつかのドメインが代替パスを発見できないかもしれないことを意味します、私たちが以下に示すように。
We reconsider the example from section 2.1.1. Suppose that the distance vector distribution graph for AD Z is such that all distance vectors originating in AD Z flow toward AD V. In particular, distance vectors from AD Z enter AD W from AD X and AD Y and leave AD W for AD V. Now, suppose that the link between the AD Z and AD X breaks. AD X no longer has knowledge of any viable route to AD Z, although such a route exists through AD W. To ensure discovery of alternate routes to AD Z during connectivity failures, the distance
私たちはセクション2.1.1からの例を再考します。 AD ZからAD Z流動で特定のAD V.In距離ベクトルに向かって起こるすべての距離ベクトルがAD Zのための距離ベクトル分配グラフがそのようなものであるのでAD XとAD YからAD Wに入って、現在AD V.のときにADをWに出発すると仮定してください、そして、AD ZとAD Xとのリンクが壊れると仮定してください。 AD Xには、AD Zまでどんな実行可能なルートに関する知識ももうありません、そのようなルートはW.Toが接続性失敗の間のAD Zまで代替経路の発見を確実にするADを通して存在していますが、距離
Steenstrup [Page 9] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[9ページ]RFC1478IDPR構造1993年6月
vector distribution graph for AD Z must contain bidirectional links between AD W and AD X and between AD W and AD Y.
AD Zのためのベクトル分配グラフはAD WとAD XとAD WとAD Yとの双方向のリンクを含まなければなりません。
2.2.2. Link State Approach
2.2.2. リンク州のアプローチ
With link state routing information distribution, all recipients of a domain's link state message gain knowledge of that domain's transit policies and hence service restrictions. For reasons of efficiency or privacy, a domain may also restrict the set of domains to which its link state messages should be distributed. Thus, a domain has complete control over distributing restrictions with and restricting distribution of its routing information.
リンク州のルーティング情報流通で、ドメインのリンク州のメッセージのすべての受取人がそのドメインの運送保険証券としたがって、サービス制限に関する知識を獲得します。 効率かプライバシーの理由で、また、ドメインはリンク州のメッセージが分配されるべきであるドメインのセットを制限するかもしれません。 したがって、ドメインは、ルーティング情報について制限を広げて、分配を制限しながら、完全なコントロールを家に迎えます。
A domain's link state messages automatically travel to all other domains if no distribution restrictions are imposed. Moreover, to ensure that distribution restrictions, when imposed, are applied, the domain may use source specified forwarding of its link state messages, such that the messages are distributed and interpreted only by the destination domains for which they were intended. Thus, only those domains receive the given domain's link state messages and hence gain knowledge of that domain's service offerings.
分配制限が全く課されないなら、ドメインのリンク州のメッセージは自動的に他のすべてのドメインに移動します。 そのうえ、課されると分配制限が適用されているのを保証するのに、ドメインはリンク州のメッセージのソースの指定された推進を使用するかもしれません、メッセージが彼らが意図した目的地ドメインだけによって分配されて、解釈されるように。 それらのドメインだけが、与えられたドメインのリンク州のメッセージを受け取って、したがって、そのドメインのサービス提供に関する知識を獲得します。
We have selected link state routing information distribution for IDPR for the following reasons:
私たちは以下の理由でIDPRのためにリンク州のルーティング情報流通を選択しました:
- A domain has complete control over the distribution of its own
routing information.
- ドメインには、それ自身のルーティング情報の分配の完全なコントロールがあります。
- Routing information distribution restrictions may be kept private
and hence need not be distributed. Thus, there are no memory,
processing, or transmission bandwidth costs incurred for
distributing and storing distribution restrictions.
- ルート設定情報流通制限は、個人的に保たれるかもしれなくて、したがって、広げられる必要はありません。 したがって、帯域幅コストが分配制限を広げて、格納するために被ったどんなメモリ、処理も、またはトランスミッションもありません。
2.3. Message Forwarding along Policy Routes
2.3. 方針ルートに沿ったメッセージ推進
To transport data messages along a selected policy route, a routing entity may use either hop-by-hop or source specified message forwarding.
選択された方針ルートに沿ってデータメッセージを輸送するために、ルーティング実体はホップごとのソースの指定されたメッセージ推進のどちらかを使用するかもしれません。
2.3.1. Hop-by-Hop Approach
2.3.1. ホップごとのアプローチ
With hop-by-hop message forwarding, each routing entity makes an independent forwarding decision based on a message's source, destination, and requested services and on information contained in the entity's forwarding information database. Hop-by-hop message forwarding follows a source-selected policy route only if all routing entities along the route have consistent routing information and make consistent use of this information when generating and selecting
ホップごとのメッセージ推進で、それぞれのルーティング実体はメッセージのソース、目的地、および要求されたサービスに基づいていて、実体の推進情報データベースに情報に含まれた独立している推進決定をします。 ルートに沿ったすべてのルーティング実体が発生して選択しているとき一貫したルーティング情報を持って、この情報の一貫した使用をする場合にだけ、ホップごとのメッセージ推進はソースによって選択された方針ルートに従います。
Steenstrup [Page 10] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[10ページ]RFC1478IDPR構造1993年6月
policy routes and when establishing forwarding information. In particular, all domains along the route must have consistent information about the source domain's source policies and consistent, but not necessarily complete, information about transit policies and domain adjacencies within the Internet. In general, this implies that each domain should have knowledge of all other domains' source policies, transit policies, and domain adjacencies.
そして、方針ルート、推進情報を確立するとき。 特に、ルートに沿ったすべてのドメインがインターネットの中にソースドメインのソース方針の一貫した情報と運送保険証券とドメイン隣接番組の一貫しましたが、必ず完全であるというわけではない情報を持たなければなりません。 一般に、これは、各ドメインには他のすべてのドメインのソース方針、運送保険証券、およびドメイン隣接番組に関する知識があるべきであるのを含意します。
When hop-by-hop message forwarding is applied in the presence of inconsistent routing information, the actual route traversed by data messages not only may differ from the route selected by the source but also may contain loops. In the policy routing context, private source policies and restricted distribution of routing information are two potential causes of routing information inconsistencies among domains. Moreover, we expect routing information inconsistencies among domains in a large Internet, independent of whether the Internet supports policy routing, as some domains may not want or may not be able to store routing information from the entire Internet.
ホップごとのメッセージ推進が矛盾したルーティング情報があるとき適用されるとき、データメッセージによって横断された実際のルートはソースによって選択されたルートと異なるかもしれないだけではなく、輪を含みもするかもしれません。 方針ルーティング文脈では、ルーティング情報の個人的なソース方針と制限された分配はドメインの中のルーティング情報矛盾の2つの潜在的原因です。 そのうえ、私たちは大きいインターネットのドメインの中でルーティング情報矛盾を予想します、インターネットが方針ルーティングを支持するかどうかの如何にかかわらず、いくつかのドメインが欲しくないことができないかもしれない、全体のインターネットからルーティング情報を格納できないとき。
2.3.1.1. A Clarification
2.3.1.1. 明確化
In a previous draft, we presented the following example which results in persistent routing loops, when hop-by-hop message forwarding is used in conjunction with distance vector routing information distribution and route selection. Consider the sequence of events:
前の草稿では、私たちはしつこいルーティング輪をもたらす以下の例を提示しました、ホップごとのメッセージ推進が距離ベクトルルーティング情報流通とルート選択に関連して使用されるとき。 出来事の系列を考えてください:
- AD X receives a distance vector message containing a route to AD Z,
which does not include AD Y. AD X selects and distributes this route
as its primary route to AD Z.
- AD XはAD Zまでルートを含む距離ベクトルメッセージを受け取ります。それは、Y.AD Xが選択するADを含まないで、幹線道路としてAD Zまでこのルートを分配します。
- AD Y receives a distance vector message containing a route to AD Z,
which does not include AD X. AD Y selects and distributes this route
as its primary route to AD Z.
- AD YはAD Zまでルートを含む距離ベクトルメッセージを受け取ります。それは、X.AD Yが選択するADを含まないで、幹線道路としてAD Zまでこのルートを分配します。
- AD X eventually receives the distance vector message containing the
route to AD Z, which includes AD Y but not AD X. AD X prefers this
route over its previous route to AD Z and selects this new route as
its primary route to AD Z.
- AD Xが結局、AD Yを含んでいるAD Zまでルートを含む距離ベクトルメッセージを受け取りますが、どんなAD X.AD Xも前のルートよりAD Zまでこのルートを好んで、幹線道路としてAD Zまでこの新しいルートを選定しません。
- AD Y eventually receives the distance vector message containing the
route to AD Z, which includes AD X but not AD Y. AD Y prefers this
route over its previous route to AD Z and selects this new route as
its primary route to AD Z.
- AD Yが結局、AD Xを含んでいるAD Zまでルートを含む距離ベクトルメッセージを受け取りますが、どんなAD Y.AD Yも前のルートよりAD Zまでこのルートを好んで、幹線道路としてAD Zまでこの新しいルートを選定しません。
Thus, AD X selects a route to AD Z that includes AD Y, and AD Y selects a route to AD Z that includes AD X.
したがって、AD XはAD Yを含んでいるAD Zまでルートを選択します、そして、AD YはAD Xを含んでいるAD Zまでルートを選択します。
Steenstrup [Page 11] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[11ページ]RFC1478IDPR構造1993年6月
Suppose that all domains along the route selected by AD X, except for AD Y, make forwarding decisions consistent with AD X's route, and that all domains along the route selected by AD Y, except for AD X, make forwarding decisions consistent with AD Y's route. Neither AD X's selected route nor AD Y's selected route contains a loop. Nevertheless, data messages destined for AD Z and forwarded to either AD X or AD Y will continue to circulate between AD X and AD Y, until there is a route change. The reason is that AD X and AD Y have conflicting notions of the route to AD Z, with each domain existing as a hop on the other's route.
AD Y以外のAD Xまでに選択されたルートに沿ったすべてのドメインが推進をAD Xのルートと一致した決定にして、AD X以外のAD Yまでに選択されたルートに沿ったすべてのドメインが推進をAD Yのルートと一致した決定にすると仮定してください。 AD Xの選択されたルートもAD Yの選択されたルートも輪を含んでいません。 それにもかかわらず、AD Zに運命づけられていて、AD XかAD Yのどちらかまで転送されたデータメッセージは、AD XとAD Yの間を循環し続けるでしょう、ルート変化があるまで。 理由はAD XとAD YにはAD Zまでルートの闘争考えがあるということです、各ドメインがもう片方のルートの上のホップとして存在であっている中に。
We note that while BGP-3 [8] is susceptible to such routing loops, BGP-4 [9] is not. We thank Tony Li and Yakov Rekhter for their help in clarifying this difference between BGP-3 and BGP-4.
私たちは、BGP-3[8]がそのようなルーティング輪に影響されやすいのですが、BGP-4[9]が影響されやすいというわけではないことに注意します。 私たちは彼らの助けについてBGP-3とBGP-4のこの違いをはっきりさせる際にトニー・李とヤコフRekhterに感謝します。
2.3.2. Source Specified Approach
2.3.2. ソースの指定されたアプローチ
With source specified message forwarding, the source domain dictates the data message forwarding decisions to the routing entities in each intermediate domain, which then forward data messages according to the source specification. Thus, the source domain ensures that any data message originating within it follows its selected routes.
ソースの指定されたメッセージ推進で、ソースドメインはそれぞれの中間的ドメインのルーティング実体にデータメッセージ推進決定を決めます。(次に、実体はソース仕様通りにデータメッセージを転送します)。 したがって、ソースドメインは、それの中で起因するどんなデータメッセージも選択されたルートに従うのを確実にします。
For source specified message forwarding, each data message must carry either an entire source specified route or a path identifier. Including the complete route in each data message incurs a per message transmission and processing cost for transporting and interpreting the source route. Using path identifiers does not incur these costs. However, to use path identifiers, the source domain must initiate, prior to data message forwarding, a path setup procedure that forms an association between the path identifier and the next hop in the routing entities in each domain along the path. Thus, path setup may impose an initial delay before data message forwarding can begin.
ソースの指定されたメッセージ推進のために、それぞれのデータメッセージは全体のソース指定されたルートか経路識別子のどちらかを運ばなければなりません。 それぞれのデータメッセージに完全なルートを含んでいると、メッセージ送信あたりのaと加工費は、送信元経路を輸送して、解釈するために被られます。 経路識別子を使用するのはこれらのコストを被りません。 しかしながら、経路識別子を使用するために、ソースドメインはデータの前にメッセージ推進(経路に沿った各ドメインで経路識別子と次のホップの間でルーティング実体で結社を作る経路セットアップ手順)を開始しなければなりません。 したがって、データメッセージ推進が始まることができる前に経路セットアップは初期の遅れを課すかもしれません。
We have selected source specified message forwarding for IDPR data messages for the following reasons:
私たちは以下の理由へのIDPRデータメッセージのためのソースの指定されたメッセージ推進を選択しました:
- Source specified message forwarding respects the source policies of
the source domain, regardless of whether intermediate domains along
the route have knowledge of these source policies.
- ソースはソースドメインのソース方針をあいさつに送るメッセージを指定しました、ルートに沿った中間的ドメインにこれらのソース方針に関する知識があるかどうかにかかわらず。
- Source specified message forwarding is loop-free, regardless of
whether the all domains along the route maintain consistent routing
information.
- にかかわらず、ソースの指定されたメッセージ推進が輪なしである、ルートに沿ったすべてのドメインが一貫したルーティング情報を保守します。
Also, we have chosen path identifiers over complete routes, to affect source specified message forwarding, because of the reduced
また、私たちは、減少でソースの指定されたメッセージ推進に影響するように完全なルートの上に選んだ道の識別子を持っています。
Steenstrup [Page 12] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[12ページ]RFC1478IDPRアーキテクチャ1993年6月
transmission and processing cost per data message.
データメッセージあたりのトランスミッションと加工費。
3. The IDPR Architecture
3. IDPRアーキテクチャ
We now present the architecture for IDPR, including a description of the IDPR functions, the entities that perform these functions, and the features of IDPR that aid in accommodating Internet growth.
私たちは現在IDPRのためにアーキテクチャを提示します、IDPR機能、これらの機能を実行する実体、およびインターネットの成長に対応する際に支援するIDPRの特徴の記述を含んでいて。
3.1. IDPR Functions
3.1. IDPR機能
Inter-domain policy routing comprises the following functions:
相互ドメイン方針ルーティングは以下の機能を包括します:
- Collecting and distributing routing information including domain
transit policies and inter-domain connectivity.
- ドメイン運送保険証券と相互ドメインの接続性を含むルーティング情報を、集めて、分配します。
- Generating and selecting policy routes based on the routing
information distributed and on the source policies configured or
requested.
- 情報が分配して、構成したか、またはソース方針要求したルーティングに基づく方針ルートを、生成して、選択します。
- Setting up paths across the Internet using the policy routes
generated.
- インターネットの向こう側にルートが生成した方針を使用することで経路をセットアップします。
- Forwarding messages across and between domains along the established
paths.
- ドメインの向こう側に確立した経路に沿ったドメインの間にメッセージを転送します。
- Maintaining databases of routing information, inter-domain policy
routes, forwarding information, and configuration information.
- ルーティング情報に関するデータベース、相互ドメイン方針ルート、推進情報、および設定情報を保守します。
3.2. IDPR Entities
3.2. IDPR実体
From the perspective of IDPR, the Internet comprises administrative domains connected by "virtual gateways" (see below), which are in turn connected by intra-domain routes supporting the transit policies configured by the domain administrators. Each domain administrator defines the set of transit policies that apply across its domain and the virtual gateways between which each transit policy applies. Several different transit policies may be configured for the intra- domain routes connecting a pair of virtual gateways. Moreover, a transit policy between two virtual gateways may be directional. That is, the transit policy may apply to traffic flowing in one direction, between the virtual gateways, but not in the other direction.
IDPRの見解から、インターネットはトランジットがドメイン管理者によって構成された方針であるとサポートするイントラドメインルートで順番に接続される「仮想のゲートウェイ」(以下を見る)によってつなげられた管理ドメインを包括します。 それぞれのドメイン管理者はドメインの向こう側に適用される運送保険証券と各運送保険証券が適用される仮想のゲートウェイのセットを定義します。 いくつかの異なった運送保険証券が1組の仮想のゲートウェイを接続するイントラドメインルートに構成されるかもしれません。 そのうえ、仮想の2つの門の間の運送保険証券は方向上であるかもしれません。 すなわち、運送保険証券は、仮想のゲートウェイの間の一方向に流れるトラフィックに適用しますが、もう片方の方向に適用されるかもしれないというわけではありません。
Virtual gateways (VGs) are the only connecting points recognized by IDPR between adjacent administrative domains. Each virtual gateway is actually a collection of directly-connected "policy gateways" (see below) in two adjacent domains, whose existence has been sanctioned by the administrators of both domains. Domain administrators may agree to establish more than one virtual gateway between their
仮想のゲートウェイ(VGs)は隣接している管理ドメインの間でIDPRによって認識された唯一の接続ポイントです。 それぞれの仮想のゲートウェイは実際に存在が両方のドメインの管理者によって認可された2つの隣接しているドメインでの直接接続された「方針ゲートウェイ」(以下を見る)の収集です。 仮想の1つ以上の門以上を設立する、ドメイン管理者が、同意するかもしれない彼ら
Steenstrup [Page 13] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[13ページ]RFC1478IDPRアーキテクチャ1993年6月
domains. For example, if two domains are to be connected at two geographically distant locations, the domain administrators may wish to preserve these connecting points as distinct at the inter-domain level, by establishing two distinct virtual gateways.
ドメイン。 例えば、ドメイン管理者は2つのドメインが2つの地理的に遠方の位置で接続されることであるなら、相互ドメインレベルで異なるとしてこれらの接続ポイントを保持したがっているかもしれません、異なった仮想の2つの門を設立することによって。
Policy gateways (PGs) are the physical gateways within a virtual gateway. Each policy gateway forwards transit traffic according to the service restrictions stipulated by its domain's transit policies applicable to its virtual gateway. A single policy gateway may belong to multiple virtual gateways. Within a domain, two policy gateways are "neighbors" if they are in different virtual gateways. Within a virtual gateway, two policy gateways are "peers" if they are in the same domain and are "adjacent" if they are in different domains. Peer policy gateways must be able to communicate over intra-domain routes that support the transit policies that apply to their virtual gateways. Adjacent policy gateways are "directly connected" if they are the only Internet addressable entities attached to the connecting medium. Note that this definition implies that not only point-to-point links but also multiaccess networks may serve as direct connections between adjacent policy gateways.
方針ゲートウェイ(PGs)は仮想のゲートウェイの中の物理的なゲートウェイです。 ドメインの仮想のゲートウェイに適切な運送保険証券で規定されたサービス制限に応じて、それぞれの方針ゲートウェイはトランジットトラフィックを進めます。 1方針門は複数の仮想のゲートウェイに属すかもしれません。 ドメインの中では、彼らが異なった仮想のゲートウェイにいるなら、2方針門は「隣人」です。 仮想のゲートウェイの中では、異なったドメインにいるなら、彼らが同じドメインにいて、「隣接している」なら、2方針門は「同輩」です。 同輩方針ゲートウェイはトランジットがそれらの仮想のゲートウェイに適用される方針であるとサポートするイントラドメインルートの上で交信できなければなりません。 隣接している方針ゲートウェイはそれらが接続媒体に愛着している唯一のインターネットのアドレス可能な実体であるなら「直接接続されます」。 この定義が、ポイントツーポイント接続だけではなく、多重処理ネットワークも隣接している方針ゲートウェイの間のダイレクト接続として機能するかもしれないのを含意することに注意してください。
Combining multiple policy gateways into a single virtual gateway affords three advantages:
複数の方針ゲートウェイを仮想の1つの門に結合すると、3つの利点が提供されます:
- A reduction in the amount of IDPR routing information that must be
distributed and maintained throughout the Internet.
- インターネット中で分配されて、保守しなければならないIDPRルーティング情報の量の減少。
- An increase in the reliability of IDPR routes through redundancy of
physical connections between domains.
- ドメインの間の物理接続の冗長を通したIDPRルートの信頼性の増加。
- An opportunity for load sharing of IDPR traffic among policy
gateways.
- 方針ゲートウェイの中のIDPRトラフィックの負荷分割法の機会。
Several different entities are responsible for performing the IDPR functions:
いくつかの異なった実体がIDPR機能を実行するのに原因となります:
- Policy gateways collect and distribute routing information,
participate in path setup, forward data messages along established
paths, and maintain forwarding information databases.
- 方針ゲートウェイは、ルーティング情報を集めて、分配して、経路セットアップに参加して、確立した経路に沿ってデータメッセージを転送して、推進情報データベースを維持します。
- "Path agents" act on behalf of hosts to select policy routes, to set
up and manage paths, and to maintain forwarding information
databases.
- 「経路エージェント」は、方針ルートを選択して、経路をセットアップして、管理して、推進情報データベースを維持するためにホストを代表して行動します。
- Special-purpose servers maintain all other IDPR databases as
follows:
- 専用サーバは他のすべてのIDPRデータベースを以下の通りに維持します:
Steenstrup [Page 14] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[14ページ]RFC1478IDPRアーキテクチャ1993年6月
o Each "route server" is responsible for both its database of
routing information, including domain connectivity and transit
policy information, and its database of policy routes. Also,
each route server generates policy routes on behalf of its
domain, using entries from its routing information database
and source policy information supplied through configuration
or obtained directly from the path agents.
o それぞれの「ルートサーバ」はドメインの接続性と運送保険証券情報を含むルーティング情報に関するデータベースとその方針ルートに関するデータベースの両方に責任があります。 また、それぞれのルートサーバはドメインを代表して方針ルートを生成します、構成を通して提供するか、または直接経路エージェントから得るそのルーティング情報データベースとソース方針情報からエントリーを使用して。
o Each "mapping server" is responsible for its database of
mappings that resolve Internet names and addresses to
administrative domains.
o それぞれの「マッピングサーバ」はインターネット名とアドレスを管理ドメインに決議するマッピングに関するデータベースに責任があります。
o Each "configuration server" is responsible for its database of
configured information that applies to policy gateways, path
agents, and route servers in the given administrative domain.
The configuration information for a given domain includes
source and transit policies and mappings between local IDPR
entities and their Internet addresses.
o それぞれの「構成サーバ」は与えられた管理ドメインで方針ゲートウェイ、経路エージェント、およびルートサーバに適用される構成された情報に関するデータベースに責任があります。 与えられたドメインのための設定情報は地方のIDPR実体とそれらのインターネット・アドレスの間にソース、運送保険証券、およびマッピングを含んでいます。
To maximize IDPR's manageability, one should embed all of IDPR's required functionality within the IDPR protocols and procedures. However, to minimize duplication of implementation effort, one should take advantage of required functionality already provided by mechanisms external to IDPR. Two such cases are the mapping server functionality and the configuration server functionality. The functions of the mapping server can be integrated into an existing name service such as the DNS, and the functions of the configuration server can be integrated into the domain's existing network management system.
IDPRの管理可能性を最大にするために、IDPRプロトコルと手順の中でIDPRの必要な機能性のすべてを埋め込むべきです。 しかしながら、実装取り組みの複製を最小にするために、IDPRへの外部のメカニズムによって既に提供された必要な機能性を利用するべきです。 そのような2つの場合が、マッピングサーバの機能性と構成サーバの機能性です。 DNSなどの既存の名前サービスとマッピングサーバの機能を統合できます、そして、構成サーバの機能をドメインの既存のネットワーク管理システムと統合できます。
Within the Internet, only policy gateways, path agents, and route servers must be able to generate, recognize, and process IDPR messages. The existence of IDPR is invisible to all other gateways and hosts. Mapping servers and configuration servers perform necessary but ancillary functions for IDPR, and they are not required to execute the IDPR protocols.
インターネットの中では、方針ゲートウェイ、経路エージェント、およびルートサーバだけが、IDPRメッセージを生成して、認識して、処理できなければなりません。 他のすべてのゲートウェイとホストにとって、IDPRの存在は目に見えません。 マッピングサーバと構成サーバはIDPRのために必要な、しかし、付属の機能を実行します、そして、それらはIDPRプロトコルを実行する必要はありません。
3.2.1. Path Agents
3.2.1. 経路エージェント
Any Internet host can reap the benefits of IDPR, as long as there exists a path agent configured to act on its behalf and a means by which the host's messages can reach that path agent. Path agents select and set up policy routes for hosts, accounting for service requirements. To obtain a host's service requirements, a path agent may either consult its configured IDPR source policy information or extract service requirements directly from the host's data messages, provided such information is available in these data messages.
どんなインターネット・ホストもIDPRの利益を獲得できます、利益に影響するように構成された経路エージェントとホストのメッセージがその経路エージェントに届くことができる手段が存在している限り。 サービス要件を説明して、経路エージェントは、ホストのために方針ルートを選択して、セットアップします。 経路エージェントは、ホストのサービス要件を得るために、構成されたIDPRソース方針情報に相談するか、または直接ホストのデータメッセージからサービス要件を抽出するかもしれません、そのような情報がこれらのデータメッセージで利用可能であるなら。
Steenstrup [Page 15] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[15ページ]RFC1478IDPRアーキテクチャ1993年6月
Separating the path agent functions from the hosts means that host software need not be modified to support IDPR. Moreover, it means that a path agent can aggregate onto a single policy route traffic from several different hosts, as long as the source domains, destination domains, and service requirements are the same for all of these host traffic flows. Policy gateways are the natural choice for the entities that perform the path agent functions on behalf of hosts, as policy gateways are the only inter-domain connecting points recognized by IDPR.
ホストと経路エージェント機能を切り離すのは、ホストソフトウェアがIDPRをサポートするように変更される必要はないことを意味します。 そのうえ、経路エージェントが数人の異なったホストからただ一つの方針ルートトラフィックに集めることができることを意味します、これらのホスト交通の流れのすべてに、ソースドメイン、目的地ドメイン、およびサービス要件が同じである限り。 方針ゲートウェイはホストを代表して経路エージェント機能を実行する実体のための自然な選択です、方針ゲートウェイがIDPRによって認識された唯一の相互ドメイン接続ポイントであるので。
Each domain administrator determines the set of hosts that its domain's path agents will handle. We expect that a domain administrator will normally configure path agents in its domain to act on behalf of its domain's hosts only. However, a path agent can be configured to act on behalf of any Internet host. This flexibility permits one domain to act as an IDPR "proxy" for another domain. For example, a small stub domain may wish to have policy routing available to a few of its hosts but may not want to set up its domain to support all of the IDPR functionality. The administrator of the stub domain can negotiate the proxy function with the administrator of another domain, who agrees that its domain will provide policy routes on behalf of the stub domain's hosts.
それぞれのドメイン管理者はドメインの経路エージェントが扱うホストのセットを決定します。 私たちは、通常、ドメイン管理者がドメインのホストだけを代表して行動するためにドメインで経路エージェントを構成すると予想します。 しかしながら、どんなインターネット・ホストを代表して行動するために経路エージェントを構成できます。 この柔軟性は、1つのドメインが別のドメインへのIDPR「プロキシ」として機能することを許可します。 例えば、小さいスタッブドメインは、ホストのいくつかに、利用可能な方針ルーティングを持っていることを願っていますが、IDPRの機能性のすべてをサポートするためにドメインをセットアップしたがっていないかもしれません。 スタッブドメインの管理者は別のドメインの管理者とプロキシ機能を交渉できます。(その管理者は、ドメインがスタッブドメインのホストを代表して方針ルートを提供するのに同意します)。
If a source domain supports IDPR and limits all domain egress points to policy gateways, then each message generated by a host in that source domain and destined for a host in another domain must pass through at least one policy gateway, and hence path agent, in the source domain. A host need not know how to reach any policy gateways in its domain; it need only know how to reach a gateway on its own local network. Gateways within the source domain direct inter-domain host traffic toward policy gateways, using default routes or routes derived from other inter-domain routing procedures.
ソースドメインがIDPRをサポートして、すべてのドメイン出口ポイントを方針ゲートウェイに制限するなら、そのソースドメインでホストによって生成されて、ホストのために別のドメインで運命づけられた各メッセージは、少なくとも1方針門を通り抜けて、したがって、経路エージェントを通り抜けなければなりません、ソースドメインで。 ホストはドメインでどんな方針ゲートウェイにも達する方法を知る必要はありません。 それはそれ自身の企業内情報通信網でゲートウェイに達する方法を知るだけでよいです。 方針ゲートウェイに向かったソースドメインのダイレクト相互ドメインホストトラフィックの中のゲートウェイ、デフォルトルートかルートを使用すると、他の相互ドメインルーティングから、手順は派生しました。
If a source domain does not support IDPR and requires an IDPR proxy domain to provide its hosts with policy routing, the administrator of that source domain must carefully choose the proxy domain. All intervening gateways between hosts in the source domain and path agents in the proxy domain forward traffic according to default routes or routes derived from other inter-domain routing procedures. In order for traffic from hosts in the source domain to reach the proxy domain with no special intervention, the proxy domain must lie on an existing non-IDPR inter-domain route from the source to the destination domain. Hence, to minimize the knowledge a domain administrator must have about inter-domain routes when selecting a proxy domain, we recommend that a domain administrator select its proxy domain from the set of adjacent domains.
ソースドメインが方針ルーティングをホストに提供するためにIDPRをサポートしないで、IDPRプロキシドメインを必要とするなら、そのソースドメインの管理者は慎重にプロキシドメインを選ばなければなりません。 デフォルトルートかルートに従ったソースドメインのホストとプロキシのドメインの前進のトラフィックにおける経路エージェントの間のすべての介入しているゲートウェイが他の相互ドメインルーティングから手順を引き出しました。 ソースドメインのホストからのトラフィックが特別な介入なしでプロキシドメインに達するように、プロキシドメインはソースから目的地ドメインまでの既存の非IDPR相互ドメインルートの上に位置しなければなりません。 したがって、プロキシドメインを選択するときドメイン管理者が相互ドメインルートの周りに持たなければならない知識を最小にするために、私たちは、ドメイン管理者が隣接しているドメインのセットからプロキシドメインを選択することを勧めます。
Steenstrup [Page 16] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[16ページ]RFC1478IDPRアーキテクチャ1993年6月
In either case, the first policy gateway to receive messages from an inter-domain traffic flow originating at the source domain acts as the path agent for the host generating that flow.
どちらの場合ではも、ソースドメインで起因する相互ドメイン交通の流れからメッセージを受け取る最初の方針ゲートウェイはその流れを生成するホストのための経路エージェントとして務めます。
3.2.2. IDPR Servers
3.2.2. IDPRサーバ
IDPR servers are the entities that manage the IDPR databases and that respond to queries for information from policy gateways or other servers. Each IDPR server may be a dedicated device, physically separate from the policy gateway, or it may be part of the functionality of the policy gateway itself. Separating the server functions from the policy gateways reduces the processing and memory requirements for and increases the data traffic carrying capacity of the policy gateways.
IDPRサーバはIDPRデータベースを管理して、方針ゲートウェイか他のサーバから情報のための質問に応じる実体です。 それぞれのIDPRサーバは専用デバイスであるかもしれません、方針ゲートウェイから肉体的に別々です、または、それが方針ゲートウェイ自体の機能性の一部であるかもしれません。 方針ゲートウェイとサーバ機能を切り離すと、方針ゲートウェイについて処理とメモリ要件が減らされて、データトラヒック容量は増強されます。
The following IDPR databases: routing information, route, mapping, and configuration, may be distributed hierarchically, with partial redundancy throughout the Internet. This arrangement implies a hierarchy of the associated servers, where a server's position in the hierarchy determines the extent of its database. At the bottom of the hierarchy are the "local servers" that maintain information pertinent to a single domain; at the top of the hierarchy are the "global servers" that maintain information pertinent to all domains in the Internet. There may be zero or more levels in between the local and global levels.
以下のIDPRデータベース: インターネット中に部分的な冗長がある状態で、ルーティング情報(ルート、マッピング、および構成)は、階層的で分配されるかもしれません。 このアレンジメントは関連サーバの階層構造を含意します。(そこでは、階層構造のサーバの位置がデータベースの範囲を測定します)。 階層構造の下部に、単一領域に適切に情報を保守する「ローカルサーバ」があります。 階層構造の最上部に、インターネットのすべてのドメインに適切に情報を保守する「グローバルなサーバ」があります。 ゼロがあるかもしれませんか、または以上は地方とグローバルの間でレベルを平らにします。
Hierarchical database organization relieves most IDPR servers of the burden of maintaining information about large portions of the Internet, most of which their clients will never request. Distributed database organization, with redundancy, allows clients to spread queries among IDPR servers, thus reducing the load on any one server. Furthermore, failure to communicate with a given IDPR server does not mean the loss of the entire service, as a client may obtain the information from another server. We note that some IDPR databases, such as the mapping database, may grow so large that it is not feasible to store the entire database at any single server.
階層型データベース組織は彼らのクライアントがそれの大部分を決して要求しないインターネットの大半の情報を保守する負担をほとんどのIDPRサーバに取り除きます。 冗長で、クライアントは分散データベース組織でIDPRサーバに質問を広げることができます、その上、与えられたIDPRサーバとコミュニケートしない場合、全体のサービスの損失を意味しません、その結果、クライアントが別のサーバから情報を得るとき、どんなサーバでも負荷を減少させます。冗長で、クライアントは分散データベース組織でIDPRサーバに質問を広げることができます、その上、与えられたIDPRサーバとコミュニケートしない場合、全体のサービスの損失を意味しません、その結果、クライアントが別のサーバから情報を得るとき、どんなサーバでも負荷を減少させます。私たちは、マッピングデータベースなどのいくつかのIDPRデータベースがとても大きくなるかもしれないのでどんなただ一つのサーバでも全体のデータベースを保存するのが可能でないことに注意します。
IDPR routing information databases need not be completely consistent for proper policy route generation and use, because message forwarding along policy routes is completely specified by the source path agent. The absence of a requirement for consistency among IDPR routing information databases implies that there is no requirement for strict synchronization of these databases. Such synchronization is costly in terms of the message processing and transmission bandwidth required. Nevertheless, each IDPR route server should have a query/response mechanism for making its routing information database consistent with that of another route server, if necessary. A route server uses this mechanism to update its routing information
適切な方針ルート世代と使用において、IDPRルーティング情報データベースは完全に一貫していなければならないというわけではありません、方針ルートに沿ったメッセージ推進がソースの経路エージェントによって完全に指定されるので。 IDPRルーティング情報データベースの中の一貫性のための要件の欠如は、これらのデータベースの厳しい同期のための要件が全くないのを含意します。 そのような同期はメッセージ処理で高価です、そして、トランスミッション帯域幅が必要です。 それにもかかわらず、それぞれのIDPRルートサーバには、必要ならルーティング情報データベースを別のルートサーバのものと一致するようにするための質問/反応機構があるべきです。 ルートサーバは、ルーティング情報をアップデートするのにこのメカニズムを使用します。
Steenstrup [Page 17] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[17ページ]RFC1478IDPRアーキテクチャ1993年6月
database following detection of a gap or potential error in database contents, for example, when the route server returns to service after disconnection from the Internet.
ルートサーバであるときに、例えば、データベースコンテンツにおける、ギャップか潜在的誤りのデータベースの次の検出は断線の後にインターネットからサービスに戻ります。
A route server in one domain wishing to communicate with a route server in another domain must establish a policy route to the other route server's domain. To generate and establish a policy route, the route server must know the other route server's domain, and it must have sufficient routing information to construct a route to that domain. As route servers may often intercommunicate in order to obtain routing information, one might assume an ensuing deadlock in which a route server requires routing information from another route server but does not have sufficient mapping and routing information to establish a policy route to that route server. However, such a deadlock should seldom persist, if the following IDPR functionality is in place:
1つのドメインの別のドメインでルートサーバとコミュニケートしたがっているルートサーバはもう片方のルートサーバのドメインに方針ルートを確立しなければなりません。 方針ルートを生成して、証明するために、ルートサーバはもう片方のルートサーバのドメインを知らなければなりません、そして、それには、そのドメインにルートを構成できるくらいのルーティング情報がなければなりません。 ルートサーバがルーティング情報を得るためにしばしば通信し合われるとき、人は、そのルートサーバに方針ルートを証明するためにルートサーバが別のルートサーバから情報を発送するのが必要ですが、十分なマッピングを持っていない続く行き詰まりとルーティング情報を仮定するかもしれません。しかしながら、そのような行き詰まりはめったに持続するべきではありません、以下のIDPRの機能性が適所にあるなら:
- A mechanism that allows a route server to gain access, during route
server initialization, to the identities of the other route servers
within its domain. Using this information, the route server need not
establish policy routes in order to query these route servers for
routing information.
- ルートサーバがルートサーバ初期化の間にドメインの中で他のルートサーバのアイデンティティにアクセスを得ることができるメカニズム。 この情報を使用して、ルートサーバは、ルーティング情報のためにこれらのルートサーバについて質問するために方針ルートを確立する必要はありません。
- A mechanism that allows a route server to gain access, during route
server initialization, to its domain's adjacencies. Using this
information, the route server may establish policy routes to the
adjacent domains in order to query their route servers for routing
information when none is available within its own domain.
- ルートサーバがルートサーバ初期化の間にドメインの隣接番組にアクセスを得ることができるメカニズム。 この情報を使用して、ルートサーバは、なにもいつそれ自身のドメインの中で利用可能でないかというルーティング情報のためにそれらのルートサーバについて質問するために方針ルートを隣接しているドメインに確立するかもしれません。
- Once operational, a route server should collect (memory capacity
permitting) all the routing information to which it has access. A
domain usually does not restrict distribution of its routing
information but instead distributes its routing information to all
other Internet domains. Hence, a route server in a given domain is
likely to receive routing information from most Internet domains.
- かつて操作上であり、ルートサーバはそれがアクセサリーを持っているすべてのルーティング情報を集めるべきです(記憶容量の可能にすること)。 ドメインは、通常ルーティング情報の分配を制限しませんが、代わりに他のすべてのインターネットドメインにルーティング情報を分配します。 したがって、与えられたドメインのルートサーバはほとんどのインターネットドメインからルーティング情報を受け取りそうです。
- A mechanism that allows an operational route server to obtain the
identities of external route servers from which it can obtain routing
information and of the domains containing these route servers.
Furthermore, this mechanism should not require mapping server queries.
Rather, each domain should distribute in its routing information
messages the identities of all route servers, within its domain, that
may be queried by clients outside of its domain.
- 操作上のルートサーバがそれがルーティング情報を得ることができる外部経路サーバとこれらのルートサーバを含むドメインのアイデンティティを得ることができるメカニズム。 その上、このメカニズムは、サーバ質問を写像するのを必要とするはずがありません。 むしろ、各ドメインはルーティング情報メッセージでドメインの中のドメインの外でクライアントによって質問されるかもしれないすべてのルートサーバのアイデンティティを分配するべきです。
When a host in one domain wishes to communicate with a host in another domain, the path agent in the source domain must establish a policy route to a path agent in the destination domain. However, the source path agent must first query a mapping server, to determine the
1つのドメインのホストが別のドメインでホストとコミュニケートしたがっているとき、ソースドメインの経路エージェントは目的地ドメインの経路エージェントに方針ルートを確立しなければなりません。 しかしながら、ソースの経路エージェントが最初にマッピングサーバについて質問しなければならない、決定します。
Steenstrup [Page 18] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[18ページ]RFC1478IDPRアーキテクチャ1993年6月
identity of the destination domain. The queried mapping server may in turn contact other mapping servers to obtain a reply. As with route server communication, one might assume an ensuing deadlock in which a mapping server requires mapping information from an external mapping server but the path agent handling the traffic does not have sufficient mapping information to determine the domain of, and hence establish a policy route to, that mapping server.
目的地ドメインのアイデンティティ。 質問されたマッピングサーバは、回答を得るために順番に他のマッピングサーバに連絡するかもしれません。 ルートサーバコミュニケーションなら、人はマッピングサーバが外部のマッピングサーバからのマッピング情報を必要としますが、トラフィックを扱っている経路エージェントがそのマッピングサーバにドメインを決定して、したがって、方針ルートを証明できるくらいのマッピング情報を持っていない続く行き詰まりを仮定するかもしれません。
We have previously described how to minimize the potential for deadlock in obtaining routing information. To minimize the potential for deadlock in obtaining mapping information, there should be a mechanism that allows a mapping server to gain access, during mapping server initialization, to the identities of other mapping servers and the domains in which they reside. Thus, when a mapping server needs to query an external mapping server, it knows the identity of that mapping server and sends a message. The path agent handling this traffic queries a local mapping server to resolve the identity of the external mapping server to the proper domain and then proceeds to establish a policy route to that domain.
私たちは以前に、ルーティング情報を得る際に行き詰まりの可能性を最小にする方法を説明しました。 マッピング情報を得る際に行き詰まりの可能性を最小にするために、マッピングサーバがアクセスを得ることができるメカニズムがあるはずです、サーバ初期化を写像している間、他のマッピングサーバのアイデンティティとそれらが住んでいるドメインに。 したがって、マッピングサーバが、外部のマッピングサーバについて質問する必要があると、それは、そのマッピングサーバのアイデンティティを知って、メッセージを送ります。 このトラフィックを扱っている経路エージェントは、外部のマッピングサーバのアイデンティティを適切なドメインに決議するためにローカルのマッピングサーバについて質問して、次に、方針ルートをそのドメインに確立しかけます。
3.2.3. Entity Identifiers
3.2.3. エンティティ識別名
Each domain has a unique identifier within the Internet, specifically an ordinal number in the enumeration of Internet domains, determined by the Internet Assigned Numbers Authority (IANA) who is responsible for maintaining such information.
各ドメインはインターネット、明確にそのような情報を保守するのに責任があるインターネットAssigned民数記Authority(IANA)によって決定されたインターネットドメインの列挙における序数詞の中にユニークな識別子を持っています。
Each virtual gateway has a unique local identifier within a domain, derived from the adjacent domain's identifier together with the virtual gateway's ordinal number within an enumeration of the virtual gateways connecting the two domains. The administrators of both domains mutually agree upon the enumeration of the virtual gateways within their shared set of virtual gateways; selecting a single virtual gateway enumeration that applies in both domains eliminates the need to maintain a mapping between separate virtual gateway ordinal numbers in each domain.
それぞれの仮想のゲートウェイは仮想のゲートウェイの序数詞と共に2つのドメインをつなげながら仮想のゲートウェイの列挙の中で隣接しているドメインの識別子から得られたドメインの中にユニークなローカルの識別子を持っています。 両方のドメインの管理者はそれらの共有されたセットの仮想のゲートウェイの中で互いに仮想のゲートウェイの列挙に同意します。 両方のドメインで適用されるただ一つの仮想のゲートウェイ列挙を選択すると、各ドメインで別々の仮想のゲートウェイ序数詞の間のマッピングを維持する必要性は排除されます。
Each policy gateway and route server has a unique local identifier within its domain, specifically an ordinal number in the domain administrator's enumeration of IDPR entities within its domain. This local identifier, when combined with the domain identifier, produces a unique identifier within the Internet for the policy gateway or route server.
それぞれの方針ゲートウェイとルートサーバはドメイン(明確にドメインアドミニストレータのドメインの中のIDPR実体の列挙における序数詞)の中にユニークなローカルの識別子を持っています。 ドメイン識別子に結合されると、このローカルの識別子は方針ゲートウェイかルートサーバのためにインターネットの中でユニークな識別子を作り出します。
3.3. Security and Reliability
3.3. セキュリティと信頼性
The correctness of control information, and in particular routing- related information, distributed throughout the Internet is a
情報、および特にルーティングの関連する情報がインターネット中に広げたコントロールの正当性はaです。
Steenstrup [Page 19] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[19ページ]RFC1478IDPRアーキテクチャ1993年6月
critical factor affecting the Internet's ability to transport data. As the number and heterogeneity of Internet domains increases, so too does the potential for both information corruption and denial of service attacks. Thus, we have imbued the IDPR architecture with a variety of mechanisms to:
データを輸送するインターネットの能力に影響する重要な要素。 また、それほどドメインが増強するインターネットの数と異種性が両方の可能性をするとき、サービスの情報不正と否定は攻撃されます。 したがって、私たちは以下のことのためにさまざまなメカニズムをIDPRアーキテクチャに吹き込みました。
- Promote timely delivery of control information.
- 制御情報のタイムリーな配送を促進してください。
- Minimize acceptance and distribution of corrupted control
information.
- 崩壊した制御情報の承認と分配を最小にしてください。
- Verify authenticity of a source of control information.
- 制御情報の源の信憑性について確かめてください。
- Reduce the chances for certain types of denial of service attacks.
- あるタイプのサービス不能攻撃のために可能性を小さくしてください。
Consult [11] for a general security architecture for routing and [12] for a security architecture for inter-domain routing.
相互ドメインルーティングのためにルーティングのための総合証券アーキテクチャのための[11]とセキュリティー体系のための[12]に相談してください。
3.3.1. Retransmissions and Acknowledgements
3.3.1. Retransmissionsと承認
All IDPR entities must make an effort to accept and distribute only correct IDPR control messages. Each IDPR entity that transmits an IDPR control message expects an acknowledgement from the recipient and must retransmit the message up to a maximum number of times when an acknowledgement is not forthcoming. An IDPR entity that receives an IDPR control message must verify message content integrity and source authenticity before accepting, acknowledging, and possibly redistributing the message.
すべてのIDPR実体が、正しいIDPRコントロールメッセージだけを受け入れて、分配するために取り組みを作らなければなりません。 IDPRコントロールメッセージを送るそれぞれのIDPR実体は、受取人から承認を予想して、メッセージを承認が用意されていない最大数の回まで再送しなければなりません。 IDPRコントロールメッセージを受け取るIDPR実体は受け入れる前にメッセージ内容保全とソースの信憑性について確かめなければなりません、承認して、ことによるとメッセージを再配付して。
3.3.2. Integrity Checks
3.3.2. 保全はチェックします。
Integrity checks on message contents promote the detection of corrupted information. Each IDPR entity that receives an IDPR control message must perform several integrity checks on the contents. Individual IDPR protocols may apply more stringent integrity checks than those listed below. The required checks include confirmation of:
メッセージ内容の保全チェックは崩壊した情報の検出を促進します。 IDPRコントロールメッセージを受け取るそれぞれのIDPR実体はいくつかの保全チェックをコンテンツに実行しなければなりません。 個々のIDPRプロトコルは以下に記載されたものより厳しい保全チェックを当てはまるかもしれません。 必要なチェックは以下の確認を含んでいます。
- Recognized message version.
- メッセージバージョンを認識しました。
- Consistent message length.
- 首尾一貫したメッセージの長さ。
- Valid message checksum.
- 有効なメッセージチェックサム。
Each IDPR entity may also apply these integrity checks to IDPR data messages. Although the IDPR architecture only requires data message integrity checks at the last IDPR entity on a path, it does not preclude intermediate policy gateways from performing these checks as
また、それぞれのIDPR実体はこれらの保全チェックをIDPRデータメッセージに適用するかもしれません。 IDPRアーキテクチャは経路で最後のIDPR実体でデータメッセージの保全チェックを必要とするだけですが、それは、これらのチェックを実行するので、中間的方針ゲートウェイを排除しません。
Steenstrup [Page 20] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[20ページ]RFC1478IDPRアーキテクチャ1993年6月
well.
さて。
3.3.3. Source Authentication
3.3.3. ソース認証
Authentication of a message's source promotes the detection of a rogue entity masquerading as another legitimate entity. Each IDPR entity that receives an IDPR control message must verify the authenticity of the message source. We recommend that the source of the message supply a digital signature for authentication by message recipients. The digital signature should cover the entire message contents (or a hash function thereof), so that it can serve as the message checksum as well as the source authentication information.
メッセージのソースの認証は別の正統の実体のふりをする凶暴な実体の検出を促進します。 IDPRコントロールメッセージを受け取るそれぞれのIDPR実体はメッセージ源の信憑性について確かめなければなりません。 私たちは、メッセージの源がメッセージ受取人による認証のためにデジタル署名を供給することを勧めます。 デジタル署名は全体のメッセージ内容(または、それのハッシュ関数)をカバーするべきです、ソース認証情報と同様にメッセージチェックサムとして機能できるように。
Each IDPR entity may also authenticate the source of IDPR data messages; however, the IDPR architecture does not require source authentication of data messages. Instead, we recommend that higher level (end-to-end) protocols, not IDPR, assume the responsibility for data message source authentication, because of the amount of computation involved in verifying a digital signature.
また、それぞれのIDPR実体はIDPRデータメッセージの源を認証するかもしれません。 しかしながら、IDPRアーキテクチャはデータメッセージのソース認証を必要としません。 代わりに、私たちは、IDPRではなく、より高い平らな(終わらせる終わり)プロトコルがデータメッセージ源認証への責任を負うことを勧めます、デジタル署名について確かめるのにかかわる計算の量のために。
3.3.4. Timestamps
3.3.4. タイムスタンプ
Message timestamps promote the detection of out-of-date messages as well as message replays. Each IDPR control message must carry a timestamp supplied by the source, which serves to indicate the age of the message. IDPR entities use the absolute value of a timestamp to confirm that the message is current and use the relative difference between timestamps to determine which message contains the most recent information. Hence, all IDPR entities must possess internal clocks that are synchronized to some degree, in order for the absolute value of a message timestamp to be meaningful. The synchronization granularity required by the IDPR architecture is on the order of minutes and can be achieved manually.
メッセージタイムスタンプはメッセージ再生と同様に時代遅れなメッセージの検出を促進します。 それぞれのIDPRコントロールメッセージはソースによって提供されたタイムスタンプを運ばなければなりません。ソースはメッセージの時代を示すのに役立ちます。 IDPR実体は、どのメッセージが最新の情報を含むかを決定するのにメッセージがよく見られると確認して、タイムスタンプの相対的な違いを使用するのにタイムスタンプの絶対値を使用します。 したがって、すべてのIDPR実体がある程度連動する内部クロックを所有しなければなりません、メッセージタイムスタンプの絶対値が重要であるように。 IDPRアーキテクチャによって必要とされた同期粒状は、数分の注文にはあって、手動で達成できます。
Each IDPR entity that receives an IDPR control message must check that the message is timely. Any IDPR control message whose timestamp lies outside of the acceptable range may contain stale or corrupted information or may have been issued by a source whose internal clock has lost synchronization with the message recipient's internal clock.
IDPRコントロールメッセージを受け取るそれぞれのIDPR実体は、メッセージがタイムリーであることをチェックしなければなりません。 タイムスタンプが許容できる範囲の外にあるどんなIDPRコントロールメッセージも、聞き古した崩壊した情報を含んでいるか、または内部クロックがメッセージ受取人の内部クロックとの同期を失ったソースによって発行されたかもしれません。
IDPR data messages also carry timestamps; however, the IDPR architecture does not require timestamp acceptability checks on IDPR data messages. Instead, we recommend that IDPR entities only check IDPR data message timestamps during problem diagnosis, for example, when checking for suspected message replays.
また、IDPRデータメッセージはタイムスタンプを運びます。 しかしながら、IDPRアーキテクチャはIDPRデータメッセージのタイムスタンプ受容性チェックを必要としません。 代わりに、私たちは、疑われたメッセージ再生がないかどうかチェックするときだけ、例えば、IDPR実体が問題診断の間IDPRデータメッセージタイムスタンプをチェックすることを勧めます。
3.4. An Example of IDPR Operation
3.4. IDPR操作に関する例
Steenstrup [Page 21] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[21ページ]RFC1478IDPRアーキテクチャ1993年6月
We illustrate how IDPR works by stepping through an example. In this example, we assume that all domains support IDPR and that all domain egress points are policy gateways.
私たちはIDPRが例を通して踏むことによってどう働いているかを例証します。 この例では、私たちはすべてのドメインがIDPRをサポートして、すべてのドメイン出口ポイントが方針ゲートウェイであると思います。
Suppose host Hx in domain AD X wants to communicate with host Hy in domain AD Y. Hx need not know the identity of its own domain or of Hy's domain in order to send messages to Hy. Instead, Hx simply forwards a message bound for Hy to one of the gateways on its local network, according to its local forwarding information. If the recipient gateway is a policy gateway, the resident path agent determines how to forward the message outside of the domain. Otherwise, the recipient gateway forwards the message to another gateway in AD X, according to its local forwarding information. Eventually, the message will arrive at a policy gateway in AD X, as described previously in section 3.2.1.
ホストHyとドメインAD Y.Hx必要でコミュニケートするドメインAD X必需品のホストHxがメッセージをHyに送るためにそれ自身のドメインかHyのドメインのアイデンティティを知らないと仮定してください。 代わりに、Hxは単にHyに企業内情報通信網のゲートウェイの1つに向かっているメッセージを転送します、ローカルの推進情報によると。 受取人ゲートウェイが方針ゲートウェイであるなら、居住している経路エージェントはドメインの外にメッセージを転送する方法を決心しています。 さもなければ、ローカルの推進情報に応じて、受取人ゲートウェイはAD Xのときにもう1門にメッセージを転送します。 結局、メッセージはAD Xのときに以前にセクション3.2.1で説明されるように方針ゲートウェイに到着するでしょう。
The path agent resident in the recipient policy gateway uses the message header, including source and destination addresses and any requested service information (for example, type of service), in order to determine whether it is an intra-domain or inter-domain message, and if inter-domain, whether it requires an IDPR policy route. Specifically, the path agent attempts to locate a forwarding information database entry for the given traffic flow. The forwarding information database will already contain entries for all of the following:
受取人方針ゲートウェイの経路エージェントの居住者はメッセージヘッダーを使用します、ソース、送付先アドレス、およびどんな要求されたサービス情報(例えば、サービスのタイプ)も含んでいて、それがイントラドメインか相互ドメインメッセージであるかどうか決定して、相互ドメインであるなら、それがIDPR方針ルートを必要とするか否かに関係なく。 明確に、経路エージェントは、与えられた交通の流れのための推進情報データベースエントリーの場所を見つけるのを試みます。 推進情報データベースは既に以下のすべてのためのエントリーを含むでしょう:
- All intra-domain traffic flows. Intra-domain forwarding information
is integrated into the forwarding database as soon as it is received.
- すべてのイントラドメイントラフィックが流れます。 それが受け取られているとすぐに、イントラドメイン推進情報は推進データベースと統合されます。
- Inter-domain traffic flows that do not require IDPR policy routes.
Non-IDPR inter-domain forwarding information is integrated into the
forwarding database as soon as it is received.
- IDPR方針ルートを必要としない相互ドメイン交通の流れ。 それが受け取られているとすぐに、非IDPR相互ドメイン推進情報は推進データベースと統合されます。
- IDPR inter-domain traffic flows for which a path has already been set
up. IDPR forwarding information is integrated into the forwarding
database only during path setup.
- 経路が既にセットアップされたIDPR相互ドメイントラフィックは流れます。 IDPR推進情報は経路セットアップだけの間推進データベースと統合されます。
The path agent uses the message header contents to guide the search for a forwarding information database entry for a traffic flow; we suggest a radix search to locate a database entry. When the search terminates, it either produces a forwarding information database entry or a directive to generate such an entry for an IDPR traffic flow. If the search terminates in an existing database entry, the path agent forwards the message according to that entry.
経路エージェントは交通の流れのための推進情報データベースエントリーの検索を誘導するのにメッセージヘッダーコンテンツを使用します。 私たちは、データベースエントリーの場所を見つけるように基数検索を勧めます。 検索が終わると、それは、IDPR交通の流れのためのそのようなエントリーを生成するために推進情報データベースエントリーか指示を起こします。 検索が既存のデータベースエントリーで終わるなら、そのエントリーに応じて、経路エージェントはメッセージを転送します。
Suppose that the search terminates indicating that the traffic flow between Hx and Hy requires an IDPR route and that no forwarding information database entry yet exists for this flow. In this case,
HxとHyの間の交通の流れがIDPRルートを必要とするのを示しながら検索が終わって、まだ情報データベースエントリーを進めていないのがこの流れのために存在すると仮定してください。 この場合
Steenstrup [Page 22] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[22ページ]RFC1478IDPRアーキテクチャ1993年6月
the path agent first determines the source and destination domains associated with the message's source and destination addresses, before attempting to obtain a policy route. The path agent relies on the mapping servers to supply the domain information, but it caches all mapping server responses locally to limit the number of future queries. When attempting to resolve an address to a domain, the path agent always checks its local cache before contacting a mapping server.
経路エージェントは最初にメッセージのソースと送付先アドレスに関連しているソースと目的地ドメインを決心しています、方針ルートを入手するのを試みる前に。 経路エージェントはドメイン情報を提供するためにマッピングサーバを当てにしますが、それは、今後の質問の数を制限するために局所的にすべてのマッピングサーバ応答をキャッシュします。 ドメインにアドレスを決議するのを試みるとき、マッピングサーバに連絡する前に、経路エージェントはいつもローカルなキャッシュをチェックします。
After obtaining the source and destination domain information, the path agent attempts to obtain a policy route to carry the traffic from Hx to Hy. The path agent relies on the route servers to supply policy routes, but it caches all route server responses locally to limit the number of future queries. When attempting to locate a suitable policy route, the path agent consults its local cache before contacting a route server. A policy route contained in the cache is suitable provided that its associated source domain is AD X, its associated destination domain is AD Y, and it satisfies the service requirements specified in the data message or through source policy configuration.
ソースと目的地ドメイン情報を得た後に、経路エージェントは、HxからHyまでトラフィックを運ぶために方針ルートを入手するのを試みます。 経路エージェントは方針ルートを供給するためにルートサーバを当てにしますが、それは、今後の質問の数を制限するために局所的にすべてのルートサーバ応答をキャッシュします。 適当な方針ルートの場所を見つけるのを試みるとき、ルートサーバに連絡する前に、経路エージェントはローカルなキャッシュに相談します。関連ソースドメインがAD Xであり、関連目的地ドメインがAD Yであり、データメッセージかソース方針構成を通して指定されたサービス要件を満たせば、キャッシュに含まれた方針ルートは適当です。
If no suitable cache entry exists, the path agent queries the route server, providing it with the source and destination domains together with the requested services. Upon receiving a policy route query, a route server consults its route database. If it cannot locate a suitable route in its route database, the route server attempts to generate at least one route to domain AD Y, consistent with the requested services for Hx.
どんな適当なキャッシュエントリーも存在していないなら、経路エージェントはルートサーバについて質問します、要求されたサービスと共にソースと目的地ドメインをそれに提供して。 方針ルート質問を受けると、ルートサーバはルートデータベースに相談します。 ルートデータベースで適当なルートの場所を見つけることができないなら、少なくとも1つを生成するルートサーバ試みはAD Yをドメインに発送します、Hxにおいて要求されたサービスと一致しています。
The response to a successful route query consists of a set of candidate routes, from which the path agent makes its selection. We expect that a path agent will normally choose a single route from a candidate set. Nevertheless, the IDPR architecture does not preclude a path agent from selecting multiple routes from the candidate set. A path agent may desire multiple routes to support features such as fault tolerance or load balancing; however, the IDPR architecture does not specify how the path agent should use multiple routes. In any case, a route server always returns a response to a path agent's query, even if it is not successful in locating a suitable policy route.
うまくいっているルート質問への応答は1セットの候補ルートから成ります。(経路エージェントはルートから選択をします)。 私たちは、通常、経路エージェントが候補セットからただ一つのルートを選ぶと予想します。 それにもかかわらず、IDPRアーキテクチャは、候補セットから複数のルートを選択するので、経路エージェントを排除しません。 経路エージェントは、複数のルートが耐障害性かロードバランシングなどの特徴をサポートすることを望むかもしれません。 しかしながら、IDPRアーキテクチャは経路エージェントがどう複数のルートを使用するべきであるかを指定しません。 どのような場合でも、ルートサーバはいつも経路エージェントの質問への応答を返します、それが適当な方針ルートの場所を見つけるのに成功していなくても。
If the policy route is a new route provided by the route server, there will be no existing path for the route and thus the path agent must set up such a path. However, if the policy route is an existing route extracted from the path agent's cache, there may well be an existing path for the route, set up to accommodate a different host traffic flow. The IDPR architecture permits multiple host traffic flows to use the same path, provided that all flows sharing the path
方針ルートがルートサーバによって提供された、新しいルートであるなら、ルートへのどんな既存の経路もないでしょう、そして、その結果、経路エージェントはそのような経路をセットアップしなければなりません。 しかしながら、方針ルートが経路エージェントのキャッシュから抜粋された、既存のルートであるなら、たぶん、ルート(異なったホスト交通の流れに対応するために上がっているセット)には既存の経路があるでしょう。 すべてが経路を共有しながら流れれば、IDPRアーキテクチャは、複数のホスト交通の流れが同じ経路を使用することを許可します。
Steenstrup [Page 23] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[23ページ]RFC1478IDPRアーキテクチャ1993年6月
travel between the same endpoint domains and have the same service requirements. Nevertheless, the IDPR architecture does not preclude a path agent from setting up distinct paths along the same policy route to preserve the distinction between host traffic flows.
同じ終点ドメインの間を旅行してください、そして、同じサービス要件を持ってください。 それにもかかわらず、IDPRアーキテクチャは、ホスト交通の流れの区別を保存するために同じ方針ルートに沿って異なった経路をセットアップするので、経路エージェントを排除しません。
The path agent associates an identifier with the path, which will be included in each message that travels down the path and will be used by the policy gateways along the path in order to determine how to forward the message. If the path already exists, the path agent uses the preexisting identifier. However, for new paths, the path agent chooses a path identifier that is different from those of all other paths that it manages. The path agent also updates its forwarding information database to reference the path identifier and modifies its search procedure to yield the correct forwarding information database entry given the data message header.
経路エージェントは識別子を経路に関連づけます。(それは、経路の下側に移動する各メッセージに含まれて、メッセージを転送する方法を決定するのに経路に沿った方針ゲートウェイによって使用されるでしょう)。 経路が既に存在しているなら、経路エージェントは先在の識別子を使用します。 しかしながら、新しい経路に、経路エージェントはそれが管理する他のすべての経路のものと異なった経路識別子を選びます。 経路エージェントは、また、参照への経路識別子を情報データベースに転送するのをアップデートして、データメッセージヘッダーを考えて、正しい推進情報データベースエントリーをもたらすように調査方法を変更します。
For new paths, the path agent initiates path setup, communicating the policy route, in terms of requested services, constituent domains, relevant transit policies, and the connecting virtual gateways, to policy gateways in intermediate domains. Using this information, an intermediate policy gateway determines whether to accept or refuse the path and to which policy gateway to forward the path setup information. The path setup procedure allows policy gateways to set up a path in both directions simultaneously. Each intermediate policy gateway, after path acceptance, updates its forwarding information database to include an entry that associates the path identifier with the appropriate previous and next hop policy gateways. Paths remain in place until they are torn down because of failure, expiration, or when resources are scarce, preemption in favor of other paths.
新しい経路に、経路エージェントは経路セットアップに着手します、方針ルートを伝えて、要求されたサービス、構成しているドメイン、関連運送保険証券、および接続の仮想のゲートウェイに関して、中間的ドメインの方針ゲートウェイに。 この情報を使用して、中間的方針ゲートウェイは、受け入れるか、または経路セットアップ情報を転送するのを経路とどの方針ゲートウェイに拒否するかを決定します。 経路セットアップ手順で、方針ゲートウェイは同時に、両方の方向に経路をセットアップできます。 それぞれの中間的方針ゲートウェイは、経路承認の後に適切が前であることの状態で経路識別子を関連づけるエントリーと隣のホップ方針ゲートウェイを含むように推進情報データベースをアップデートします。 経路は失敗、満了のためにそれらを取りこわすか、またはリソースが不十分であり時適所に残っています、他の経路を支持して先取り。
When a policy gateway in AD Y accepts a path, it notifies the source path agent in AD X. We expect that the source path agent will normally wait until a path has been successfully established before using it to transport data traffic. However, the IDPR architecture does not preclude a path agent from forwarding data messages along a path prior to confirmation of successful path establishment. In this case, the source path agent transmits data messages along the path with full knowledge that the path may not yet have been successfully established at all intermediate policy gateways and thus that these data messages will be immediately discarded by any policy gateway not yet able to recognize the path identifier.
AD Yの方針ゲートウェイが経路を受け入れるとき、それは、データ通信量を輸送するのにそれを使用する前に経路が首尾よく確立されるまで通常、ソースの経路エージェントが待つようにX.Weが予想するADのソースの経路エージェントに通知します。 しかしながら、IDPRアーキテクチャは、うまくいっている経路設立の確認の前に経路に沿ってデータメッセージを転送するので、経路エージェントを排除しません。 この場合、ソースの経路エージェントは経路に沿って経路がまだ首尾よく設立された全く中間的な方針ゲートウェイでないかもしれなく、その結果、これらのデータメッセージがすぐにまだ経路識別子を認識できないどんな方針ゲートウェイによっても捨てられるという完全な知識でデータメッセージを送ります。
We note that data communication between Hx and Hy may occur over two separate IDPR paths: one from AD X to AD Y and one from AD Y to AD X. The reasons are that within a domain, hosts know nothing about path agents nor IDPR paths, and path agents know nothing about other path agents' existing IDPR paths. Thus, in AD Y, the path agent that
私たちは、HxとHyの間のデータ通信が2つの別々のIDPR経路の上に起こるかもしれないことに注意します: 1つ、AD XからAD YとAD Yからの1〜AD X.まで、理由はドメインの中では、ホストが経路エージェントに関して何も知らないということであり、IDPRは経路です、そして、経路エージェントが他の経路エージェントの既存のIDPR経路に関して何も知りません。 その結果、AD Yの経路エージェント、それ
Steenstrup [Page 24] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[24ページ]RFC1478IDPRアーキテクチャ1993年6月
terminates the path from AD X may not be the same as the path agent that receives traffic from Hy destined for Hx. In this case, receipt of traffic from Hy forces the second path agent to set up a new path from AD Y to AD X.
受信する経路エージェントと同じくらいがHxのために運命づけられたHyからのトラフィックであったかもしれないならAD Xからの経路を終えます。 この場合、第2代経路エージェントはHyからのトラフィックの領収書によってAD YからAD Xまでやむを得ず新しい経路をセットアップします。
4. Accommodating a Large, Heterogeneous Internet
4. 大きくて、異種のインターネットを収容します。
The IDPR architecture must be able to accommodate an Internet containing O(10,000) domains, supporting diverse source and transit policies. Thus, we have endowed the IDPR architecture with many features that allow it to function effectively in such an environment.
IDPRアーキテクチャはさまざまのソースとトランジットが方針であるとサポートして、O(10,000)ドメインを含むインターネットを収容できなければなりません。 したがって、私たちはそれがそのような環境で有効に機能する多くの特徴にIDPRアーキテクチャを寄付しました。
4.1. Domain Level Routing
4.1. ドメインレベルルート設定
The IDPR architecture provides policy routing among administrative domains. In order to construct policy routes, route servers require routing information at the domain level only; no intra-domain details need be included in IDPR routing information. The size of the routing information database maintained by a route server depends not on the number of Internet gateways, networks, and links, but on how these gateways, networks, and links are grouped into domains and on what services they offer. Therefore, the number of entries in an IDPR routing information database depends on the number of domains and the number and size of the transit policies supported by these domains.
IDPRアーキテクチャは方針ルーティングを管理ドメインに提供します。 方針ルートを構成するために、ルートサーバは、ドメインレベルだけで情報を発送するのを必要とします。 イントラドメインの詳細は全くIDPRルーティング情報に含まれる必要はありません。 ルートサーバによって維持されたルーティング情報データベースのサイズはインターネット・ゲートウェイの数、ネットワーク、およびリンクではなく、これらのゲートウェイ、ネットワーク、およびリンクがどうドメインに分類されるか、そして、それらがどんなサービスを提供するかに依存します。 したがって、IDPRルーティング情報データベースのエントリーの数はこれらのドメインによってサポートされた運送保険証券のドメインの数、数、およびサイズに依存します。
Policy gateways distribute IDPR routing information only when detectable inter-domain changes occur and may also elect to distribute routing information periodically (for example, on the order of once per day) as a backup. We expect that a pair of policy gateways within a domain will normally be connected such that when the primary intra-domain route between them fails, the intra-domain routing procedure will be able to construct an alternate route. Thus, an intra-domain failure is unlikely to be visible at the inter-domain level and hence unlikely to force an inter-domain routing change. Therefore, we expect that policy gateways will not often generate and distribute IDPR routing information messages.
方針ゲートウェイは、検出可能な相互ドメイン変化がいつだけ起こるかというIDPRルーティング情報を分配して、また、バックアップとして定期的(例えば1日あたりの一度の注文に関して)にルーティング情報を分配するのを選ぶかもしれません。 私たちは、それらの間のプライマリイントラドメインルートが失敗するとき、イントラドメインルーティング手順が代替経路を構成できるように、通常、ドメインの中の1組の方針ゲートウェイが接続されると予想します。 したがって、イントラドメイン失敗は、相互ドメインレベルで目に見えそうになくてしたがって、相互ドメインルーティング変化を強制しそうにはありません。 したがって、私たちは、方針ゲートウェイがしばしばIDPRルーティング情報メッセージを生成して、分配するというわけではないと予想します。
IDPR entities rely on intra-domain routing procedures operating within domains to transport inter-domain messages across domains. Hence, IDPR messages must appear well-formed according to the intra- domain routing and addressing procedures in each domain traversed. Recall that source authentication information (refer to section 3.3.3 above) may cover the entire IDPR message. Thus, the IDPR portion of such a message cannot be modified at intermediate domains along the path without causing source authenticity checks to fail. Therefore, at domain boundaries, IDPR messages require encapsulation and
IDPR実体はドメインの向こう側に相互ドメインメッセージを輸送するためにドメインの中で作動するイントラドメインルーティング手順を当てにします。 したがって、IDPRメッセージは各ドメインの手順が横断したイントラドメインルーティングとアドレシングによると、整形式に見えなければなりません。 ソース認証情報(上のセクション3.3.3について言及する)が全体のIDPRメッセージをカバーするかもしれないと思い出してください。 したがって、ソース信憑性チェックが失敗することを引き起こさない、経路に沿った中間的ドメインでそのようなメッセージのIDPR部分を変更できません。 そしてしたがって、ドメイン境界では、IDPRメッセージがカプセル化が必要である。
Steenstrup [Page 25] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[25ページ]RFC1478IDPRアーキテクチャ1993年6月
decapsulation according to the routing procedures and addressing schemes operating with the given domain. Only policy gateways and route servers must be capable of handling IDPR-specific messages; other gateways and hosts simply treat the encapsulated IDPR messages like any other message. Thus, for the Internet to support IDPR, only a small proportion of Internet entities require special IDPR software.
ルーティング手順と体系を扱うのに従った与えられたドメインで作動する被膜剥離術。 方針ゲートウェイとルートサーバだけがIDPR特有のメッセージを扱うことができなければなりません。 他のゲートウェイとホストはいかなる他のメッセージのようにも単にカプセル化されたIDPRメッセージを扱います。 したがって、インターネットがIDPR、わずかな割合のインターネット実体だけをサポートするには、特別なIDPRソフトウェアを必要としてください。
With domain level routes, many different traffic flows may use not only the same policy route but also the same path, as long as their source domains, destination domains, and service requirements are compatible. The size of the forwarding information database maintained by a policy gateway depends not on the number of Internet hosts but on how these hosts are grouped into domains, which hosts intercommunicate, and on how much distinction a source domain wishes to preserve among its traffic flows. Therefore, the number of entries in an IDPR forwarding information database depends on the number of domains and the number of source policies supported by those domains. Moreover, memory associated with failed, expired, or disused paths can be reclaimed for new paths, and thus forwarding information for many paths can be accommodated in a policy gateway's forwarding information database.
ドメインレベルルートで、多くの異なった交通の流れが同じ方針ルートだけではなく、同じ経路も使用するかもしれません、それらのソースドメイン、目的地ドメイン、およびサービス要件は互換性がある限り。 方針ゲートウェイによって維持された推進情報データベースのサイズはインターネット・ホストの数ではなく、これらのホストがどのようにドメインに分類されるか、そして、どのホストが通信し合うか、そして、ソースドメインがどのくらいの区別のときにトラフィックの中に流れを保存したがっているかに依存します。 したがって、IDPR推進情報データベースのエントリーの数はそれらのドメインによってサポートされたドメインの数とソース方針の数に依存します。 そのうえ、失敗したか、満期の、または、不要の経路に関連しているメモリを新しい経路に取り戻すことができます、そして、その結果、方針ゲートウェイの推進情報データベースに多くの経路のための推進情報を収容できます。
4.2. Route Generation
4.2. ルート世代
Route generation is the most computationally complex part of IDPR, because of the number of domains and the number and heterogeneity of policies that it must accommodate. Route servers must generate policy routes that satisfy the requested services of the source domains and respect the offered services of the transit domains.
ルート世代はIDPRの最も計算上複雑な部分です、それが収容しなければならない方針のドメインの数、数、および異種性のために。 ルートサーバはソースドメインと敬意の要求されたサービスを満たす方針ルートにトランジットドメインの提供サービスを生成しなければなりません。
We distinguish requested qualities of service and route generation with respect to them as follows:
私たちは以下の通りそれらに関してサービスとルート世代の要求された品質を区別します:
- Requested service limits include upper bounds on route delay, route
delay variation, and monetary cost for the session and lower bounds
on available route bandwidth. Generating a route that must satisfy
more than one quality of service constraint, for example route delay
of no more than X seconds and available route bandwidth of no less
than Y bits per second, is an NP-complete problem.
- 要求されたサービス限界はルート遅れ、ルート遅れ変化、セッションのための貨幣原価、利用可能なルート帯域幅における下界での上限を含んでいます。 1つ以上のサービスの質の規制を満たさなければならないルート、例えば少なくともY bpsのX秒と利用可能なルート帯域幅だけのルート遅れを生成するのは、NP完全な問題です。
- Optimal requested services include minimum route delay, minimum
route delay variation, minimum monetary cost for the session, and
maximum available route bandwidth. In the worst case, the
computational complexity of generating a route that is optimal with
respect to a given requested service is O((N + L) log N) for
Dijkstra's shortest path first (SPF) search and O(N + (L * L)) for
breadth-first (BF) search, where N is the number of nodes and L is
- 最適の要求されたサービスは最小のルート遅れを含んで、最小のルート遅れ変化、セッション、および利用可能な最大のための最小の貨幣原価は帯域幅を発送します。 最悪の場合には、与えられた要求されたサービスに関して最適のルートを生成する計算量は幅-最初(BF)の検索のための最初に、ダイクストラの最短パス(SPF)検索とO(N+(L*L))のためのO(N+L)ログN)です、そして、LはそのようなOです。そこでは、Nがノードの数です。
Steenstrup [Page 26] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[26ページ]RFC1478IDPRアーキテクチャ1993年6月
the number of links in the search graph. Multi-criteria
optimization, for example finding a route with minimal delay
variation and minimal monetary cost for the session, may be defined
in several ways. One approach to multi-criteria optimization is to
assign each link a single value equal to a weighted sum of the
values of the individual offered qualities of service and generate a
route that is optimal with respect to this new criterion. However,
it may not always be possible to achieve the desired route
generation behavior using such a linear combination of qualities of
service.
検索における、リンクの数はグラフ化します。 例えば、最小量の遅れ変化と最小量の貨幣原価でセッションに関してルートを見つけて、マルチ評価基準最適化はいくつかの道で定義されるかもしれません。 マルチ評価基準最適化への1つのアプローチは、個々の提供されたサービスの品質の値の荷重している合計と等しいただ一つの値を各リンクに割り当てて、この新しい評価基準に関して最適のルートを生成することです。 しかしながら、サービスの品質のそのような一次結合を使用する必要なルート世代の振舞いを達成するのはいつも可能であるかもしれないというわけではありません。
To help contain the combinatorial explosion of processing and memory costs associated with route generation, we supply the following guidelines for generation of suitable policy routes:
ルート世代に関連している処理とメモリコストの結合の爆発を含むのを助けるために、私たちは以下の適当な方針ルートの世代ガイドラインを提供します:
- Each route server should only generate policy routes from the
perspective of its own domain as source; it need not generate policy
routes for arbitrary source/destination domain pairs. Thus, we can
distribute the computational burden over all route servers.
- それぞれのルートサーバはソースとしてそれ自身のドメインの見解から方針ルートを生成するだけであるべきです。 それは方針ルートを任意のソース/目的地ドメイン組生成する必要はありません。 したがって、私たちはすべてのルートサーバの上にコンピュータの負担を分配できます。
- Route servers should precompute routes for which they anticipate
requests and should generate routes on demand only in order to
satisfy unanticipated route requests. Hence, a single route server
can distribute its computational burden over time.
- ルートサーバはそれらが要求を予期して、思いがけないルート要求を満たすためにオンデマンドのルートだけを生成するべきであるprecomputeルートがそうするべきです。 したがって、ただ一つのルートサーバは時間がたつにつれて、コンピュータの負担を分配できます。
- Route servers should cache the results of route generation, in order
to minimize the computation associated with responding to future
route requests.
- ルートサーバはルート世代の結果をキャッシュするべきです、今後のルート要求に応じると関連している計算を最小にするために。
- To handle requested service limits, a route server should always
select the first route generated that satisfies all of the requested
service limits.
- 要求されたサービス限界を扱うために、ルートサーバはいつも要求されたサービス限界のすべてを満たす生成された最初のルートを選択するべきです。
- To handle multi-criteria optimization in route selection, a route
server should generate routes that are optimal with respect to the
first specified optimal requested service listed in the source
policy. The route server should resolve ties between otherwise
equivalent routes by evaluating these routes according to the other
optimal requested services, in the order in which they are
specified. With respect to the route server's routing information
database, the selected route is optimal according to the first
optimal requested service but is not necessarily optimal according
to any other optimal requested service.
- ルート選択におけるマルチ評価基準最適化を扱うために、ルートサーバはソース方針で記載された最初の指定された最適の要求されたサービスに関して最適のルートを生成するべきです。 ルートサーバは他の最適の要求されたサービスに従ってこれらのルートを評価することによって、そうでなければ、同等なルートの間の結びつきを決議するべきです、それらが指定されるオーダーで。 ルートサーバのルーティング情報データベースに関して、選択されたルートは、最初の最適の要求されたサービスに従って最適ですが、いかなる他の最適の要求されたサービスに従っても、必ず最適であるというわけではありません。
- To handle a mixture of requested service limits and optimal
requested services, a route server should generate routes that
satisfy all of the requested service limits. The route server
should resolve ties between otherwise equivalent routes by
- 要求されたサービス限界の、そして、最適に要求されたサービスの混合物を扱うために、ルートサーバは要求されたサービス限界のすべてを満たすルートを生成するべきです。 サーバがそうでなければ、同等なルートの間の結びつきを決議するべきであるルート
Steenstrup [Page 27] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[27ページ]RFC1478IDPRアーキテクチャ1993年6月
evaluating those routes as described in the multi-criteria
optimization case above.
マルチ評価基準最適化ケースの中の説明されるとしての上のそれらのルートを評価します。
- All else being equal, a route server should always prefer
minimum-hop routes, because they minimize the amount of network
resources consumed by the routes.
- すべてのほかの存在同輩、ルートサーバはいつも最小のホップルートを好むべきです、ルートで消費されたネットワーク資源の量を最小にするので。
All domains need not execute the identical route generation procedure. Each domain administrator is free to specify the IDPR route generation procedure for route servers in its own domain, making the procedure as simple or as complex as desired.
ドメインが必要とするすべてが同じルート世代手順を実行しません。 それぞれのドメイン管理者は自由にそれ自身のドメインのルートサーバにIDPRルート世代手順を指定できます、望まれているのと同じくらい簡単であるか同じくらい複雑であるとして手順を作って。
4.3. SuperDomains
4.3. SuperDomains
A "super domain" is itself an administrative domain, comprising a set of contiguous domains with similar transit policies and formed through consensus of the administrators of the constituent domains. Super domains provide a mechanism for reducing the amount of IDPR routing information distributed throughout the Internet. Given a set of n contiguous domains with consistent transit policies, the amount of routing information associated with the set is approximately n times smaller when the set is considered as a single super domain than when it is considered as n individual domains.
「最高のドメイン」はそれ自体で同様の運送保険証券で1セットの隣接のドメインを包括して、構成しているドメインの管理者のコンセンサスを通して形成された管理ドメインです。 最高のドメインはインターネット中で分配されたIDPRルーティング情報の量を減少させるのにメカニズムを提供します。 セットがただ一つの最高のドメインであるとみなされるとき、一貫した運送保険証券がある1セットのn隣接のドメインを考えて、セットに関連しているルーティング情報の量はそれがn個々のドメインであるとみなされる時よりおよそn倍わずかです。
When forming a super domain from constituent domains whose transit policies do not form a consistent set, one must determine which transit policies to distribute in the routing information for the super domain. The range of possibilities is bounded by the following two alternatives, each of which reduces the amount of routing information associated with the set of constituent domains:
運送保険証券が一貫したセットを形成しない構成しているドメインから最高のドメインを形成するとき、最高のドメインのためのルーティング情報でどの運送保険証券を分配したらよいかを決定しなければなりません。 可能性として考えられる範囲は以下の2つの選択肢で境界があります:それは構成しているドメインのセットに関連しているルーティング情報の量をそれぞれ減少させます。
- The transit policies supported by the super domain are derived from
the union of the access restrictions and the intersection of the
qualities of service, over all constituent domains. In this case,
the formation of the super domain reduces the number of services
offered by the constituent domains, but guarantees that none of
these domains' access restrictions are violated.
- アクセス制限の組合とサービスの品質の交差点から最高のドメインによってサポートされた運送保険証券を得ます、すべての構成しているドメインにわたって。 この場合、最高のドメインの構成は、構成しているドメインによって提供されたサービスの数を減少させますが、これらのドメインのアクセス制限のいずれも違反されないのを保証します。
- The transit policies supported by the super domain are derived from
the intersection of the access restrictions and the union of the
qualities of service. In this case, the formation of the super
domain increases the number of services offered by the constituent
domains, but forces relaxation of these domains' access
restrictions.
- アクセス制限の交差点とサービスの品質の組合から最高のドメインによってサポートされた運送保険証券を得ます。 この場合、最高のドメインの構成は、構成しているドメインによって提供されたサービスの数を増強しますが、これらのドメインのアクセス制限の緩和を強制します。
Thus, we recommend that domain administrators refrain from arbitrarily grouping domains into super domains, unless they fully understand the consequences.
したがって、私たちは、ドメイン管理者が、彼らが完全に結果を理解しているというわけではないなら任意にドメインを最高のドメインに分類するのを控えることを勧めます。
Steenstrup [Page 28] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[28ページ]RFC1478IDPRアーキテクチャ1993年6月
The existence of super domains imposes a hierarchy on domains within the Internet. For model consistency, we assume that there is a single super domain at the top of the hierarchy, which contains the set of all high-level domains. A domain's identity is defined relative to the domain hierarchy. Specifically, a domain's identity may be defined in terms of the domains containing it, the domains it contains, or both.
最高のドメインの存在はインターネットの中で階層構造をドメインに課します。 モデルの一貫性のために、私たちは、ただ一つの最高のドメインがすべてのハイレベルのドメインのセットを含む階層構造の最上部にあると思います。 ドメインのアイデンティティはドメイン階層構造に比例して定義されます。 明確に、ドメインのアイデンティティはそれを含むドメイン、それが含むドメイン、または両方に関して定義されるかもしれません。
For any domain AD X, the universe of distribution for its routing information usually extends only to those domains contained in AD X's immediate super domain and at the same level of the hierarchy as AD X. However, the IDPR architecture does not preclude AD X from distributing its routing information to domains at arbitrarily high levels in the hierarchy, as long as the immediate super domain of these domains is also a super domain of AD X. For example, the administrator of an individual domain within a super domain may wish to have one of its transit policies advertised outside of the immediate super domain, so that other domains can take advantage of a quality of service not offered by the super domain itself. In this case, the super domain and the consituent domain may distribute routing information at the same level in the domain hierarchy, even though one domain actually contains the other.
AD X、通常、ルーティング情報がAD Xの即座の最高のドメインに保管されていたそれらのドメインだけに達してAD X.Howeverとしての階層構造、IDPRアーキテクチャの同じレベルにおける分配の宇宙がそうしないあらゆるドメインに、任意に高いレベルでルーティング情報をドメインに階層構造で分配するのからのAD Xを排除してください; また、これらのドメインの即座の最高のドメインがAD X.Forの例の最高のドメインである限り、最高のドメインの中の個々のドメインの管理者は即座の最高のドメインの外に運送保険証券の1つの広告を出して頂きたいかもしれません、他のドメインが最高のドメイン自体によって提供されなかったサービスの質を利用できるように。 この場合、最高のドメインとconsituentドメインは同じレベルでルーティング情報をドメイン階層構造で分配するかもしれません、1つのドメインが実際にもう片方を含んでいますが。
We note that the existence of super domains may restrict the number of routes available to source domains with access restrictions. For example, suppose that a source domain AD X has source policies that preclude its traffic from traversing a domain AD Y and that AD Y is contained in a super domain AD Z. If domains within AD Z do not advertise routing information separately, then route servers within AD X do not have enough routing information to construct routes that traverse AD Z but that avoid AD Y. Hence, route servers in AD X must generate routes that avoid AD Z altogether.
私たちは、最高のドメインの存在がアクセス制限でソースドメインに利用可能なルートの数を制限するかもしれないことに注意します。 例えば、別々に情報を発送するAD Z中のAD YとそのAD Yが保管されているドメインを横断するのからの最高のドメインAD Z.Ifドメインが広告を出さないトラフィックを排除して、次にAD X中にサーバを発送するソース方針がAD XでするソースドメインがAD Zを横断しますが、AD Y.Hence(Xが全体でAD Zを避けるルートを生成しなければならないADのルートサーバ)を避けるルートは構成できるくらいのルーティング情報を持っていないと仮定してください。
4.4. Domain Communities
4.4. ドメイン共同体
A "domain community" is a group of domains to which a given domain distributes routing information, and hence domain communities may be used to limit routing information distribution. Domain communities not only reduce the costs associated with distributing and storing routing information but also allow concealment of routing information from domains outside of the community. Unlike a super domain, a domain community is not necessarily an administrative domain. However, formation of a domain community may or may not involve the consent of the administrators of the member domains, and the definition of the community may be implicit or explicit.
「ドメイン共同体」は与えられたドメインがルーティング情報を分配するドメインのグループです、そして、したがって、ドメイン共同体は、ルーティング情報流通を制限するのに使用されるかもしれません。 共同体がルーティング情報を分配して、保存すると関連しているコストを削減するだけではなく、ドメインからのルーティング情報の隠すことを許容もする共同体のドメイン。 最高のドメインと異なって、ドメイン共同体は必ず管理ドメインであるというわけではありません。 共同体の定義は、しかしながら、ドメイン共同体の構成がメンバードメインの管理者の同意にかかわるかもしれなくて、暗黙である、または明白であるかもしれません。
Each domain administrator determines the extent of distribution of its domain's routing information and hence unilaterally defines a
それぞれのドメイン管理者は、ドメインのルーティング情報の分配の範囲を測定して、したがって、一方的にaを定義します。
Steenstrup [Page 29] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[29ページ]RFC1478IDPRアーキテクチャ1993年6月
domain community. By default, this community encompasses all Internet domains. However, the domain administrator may restrict community membership by describing the community as a neighborhood (defined, for example, in terms of domain hops) or as a list of member domains.
ドメイン共同体。 デフォルトで、この共同体はすべてのインターネットドメインを取り囲みます。 しかしながら、ドメイン管理者は近所(例えば、ドメインホップに関して、定義される)として共同体を記述するか、メンバードメインのリストとして共同体会員資格を制限するかもしれません。
A group of domain administrators may mutually agree on distribution of their domains' routing information among their domains and hence multilaterally define a domain community. By default, this community encompasses all Internet domains. However, the domain administrators may restrict community membership by describing the community as a list of member domains. In fact, this domain community may serve as a multicast group for routing information distribution.
ドメイン管理者のグループは、彼らのドメインの中で互いに彼らのドメインのルーティング情報の分配に同意して、したがって、多角的にドメイン共同体を定義するかもしれません。 デフォルトで、この共同体はすべてのインターネットドメインを取り囲みます。 しかしながら、ドメイン管理者は、メンバードメインのリストとして共同体を記述することによって、共同体会員資格を制限するかもしれません。 事実上、このドメイン共同体はルーティング情報流通のためのマルチキャストグループとして機能するかもしれません。
4.5. Robustness in the Presence of Failures
4.5. 失敗があるとき丈夫さ
The IDPR architecture possesses the following features that make it resistent to failures in the Internet:
IDPRアーキテクチャはインターネットにそれをresistentにする以下の特徴を失敗に持っています:
- Multiple connections between adjacent policy gateways in a virtual
gateway and between peer and neighbor policy gateways across an
administrative domain minimize the number of single component
failures that are visible at the inter-domain level.
- 仮想のゲートウェイの隣接している方針ゲートウェイと同輩と隣人方針ゲートウェイとの管理ドメイン中の複数の関係が相互ドメインレベルで目に見えるただ一つのコンポーネント故障の数を最小にします。
- Policy gateways distribute IDPR routing information immediately
after detecting a connectivity failure at the inter-domain level,
and route servers immediately incorporate this information into
their routing information databases. This ensures that new policy
routes will not include those domains involved in the connectivity
failure.
- 相互ドメインレベルで接続性失敗を検出する直後方針ゲートウェイはIDPRルーティング情報を分配します、そして、ルートサーバはすぐに、それらのルーティング情報データベースにこの情報を組み入れます。 これは、新しい政策ルートが接続性失敗にかかわるそれらのドメインを含まないのを確実にします。
- The routing information database query/response mechanism ensures
rapid updating of the routing information database for a previously
failed route server following the route server's reconnection to the
Internet.
- ルートサーバの再接続にインターネットに続いて、ルーティング情報データベース質問/反応機構は以前に失敗したルートサーバのためのルーティング情報データベースの急速なアップデートを確実にします。
- To minimize user service disruption following a
failure in the primary path, policy gateways attempt local path
repair immediately after detecting a connectivity failure.
Moreover, path agents may maintain standby alternate paths that can
become the primary path if necessary.
- プライマリ経路で失敗に続いて、ユーザサービスの崩壊を最小にするために、接続性失敗を検出する直後方針ゲートウェイは地方の経路修理を試みます。 そのうえ、経路エージェントは必要なら、プライマリ経路になることができる予備代替パスを維持するかもしれません。
- Policy gateways within a domain continuously monitor domain
connectivity and hence can detect and identify domain partitions.
Moreover, IDPR can continue to operate properly in the presence of
partitioned domains.
- したがって、ドメインの中の方針ゲートウェイは、絶え間なくドメインパーティションをドメインの接続性をモニターして、検出して、特定できます。 そのうえ、IDPRは、仕切られたドメインがあるとき適切に作動し続けることができます。
Steenstrup [Page 30] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[30ページ]RFC1478IDPRアーキテクチャ1993年6月
4.5.1. Path Repair
4.5.1. 経路修理
Failure of one or more entities on a given policy route may render the route unusable. If the failure is within a domain, IDPR relies on the intra-domain routing procedure to find an alternate route across the domain, which leaves the path unaffected. If the failure is in a virtual gateway, policy gateways must bear the responsibility of repairing the path. Policy gateways nearest to the failure are the first to recognize its existence and hence can react most quickly to repair the path.
与えられた方針ルートの上の1つ以上の実体の失敗はルートを使用不可能に表すかもしれません。 ドメインの中に失敗があるなら、IDPRは、ドメインの向こう側に代替経路を見つけるためにイントラドメインルーティング手順を当てにします。ドメインは経路を影響を受けないままにします。 失敗が仮想のゲートウェイにあるなら、方針ゲートウェイは経路を修理する責任を担わなければなりません。 失敗に最も近い方針ゲートウェイは、存在を認識する1番目であり、したがって、経路を修理するために最も急速に反応できます。
Relinquishing control over path repair to policy gateways in other domains may be unacceptable to some domain administrators. The reason is that these policy gateways cannot guarantee construction of a path that satisfies the source policies of the source domain, as they have no knowledge of other domains' source policies.
何人かのドメイン管理者にとって、他のドメインの方針ゲートウェイに経路修理のコントロールを放棄するのは容認できないかもしれません。 理由はこれらの方針ゲートウェイがソースドメインのソース方針を満たす経路の工事を保証できないということです、それらに他のドメインのソース方針に関する知識が全くないとき。
Nevertheless, limited local path repair is feasible, without distributing either source policy information throughout the Internet or detailed path information among policy gateways in a domain or in a virtual gateway. We say that a path is "locally repairable" if there exists an alternate route between two policy gateways, separated by at most one policy gateway, on the path. This definition covers path repair in the presence of failed routes between consecutive policy gateways as well as failed policy gateways themselves.
それにもかかわらず、限られた地方の経路修理は可能です、ドメインか仮想のゲートウェイの方針ゲートウェイの中でインターネット中のソース方針情報か詳細な経路情報のどちらかを分配しないで。 私たちは、代替経路が高々1方針門によって切り離された2方針門の間に存在しているなら経路が「局所的に修繕可能である」と言います、経路で。 この定義は失敗した方針ゲートウェイ自体と同様に連続した方針ゲートウェイの間の失敗したルートがあるとき経路修理をカバーしています。
A policy gateway attempts local path repair, proceeding in the forward direction of the path, upon detecting that the next policy gateway on a path is no longer reachable. The policy gateway must retain enough of the original path setup information to repair the path locally. Using the path setup information, the policy gateway attempts to locate a route around the unreachable policy gateway. Specifically, the policy gateway attempts to establish contact with either:
方針ゲートウェイは地方の経路修理を試みます、経路に関する順方向に続いてそれを検出するときの経路の隣の方針ゲートウェイはもう届いていません。 方針ゲートウェイはオリジナルの経路セットアップ情報が局所的に経路を修理する十分を保有しなければなりません。 経路セットアップ情報を使用して、方針ゲートウェイは、手の届かない方針ゲートウェイの周りでルートの場所を見つけるのを試みます。 明確に、方針ゲートウェイは、どちらかで接触するのを試みます:
- A peer of the unreachable policy gateway. In this case, the
contacted policy gateway attempts to locate the next policy gateway
following the unreachable policy gateway, on the original path.
- 手の届かない方針ゲートウェイの同輩。 この場合、連絡された方針ゲートウェイは、手の届かない方針ゲートウェイに続いて、隣の方針ゲートウェイの場所を見つけるのを試みます、元の経路で。
- A peer of itself, if the unreachable policy gateway is an adjacent
policy gateway and if the given policy gateway no longer has direct
connections to any adjacent policy gateways. In this case, the
contacted policy gateway attempts to locate a peer of the
unreachable policy gateway, which in turn attempts to locate the
next policy gateway following the unreachable policy gateway, on the
original path.
- それ自体の同輩手の届かない方針ゲートウェイが隣接している方針ゲートウェイであり、与えられた方針ゲートウェイにどんな隣接している方針ゲートウェイにもダイレクト接続がもうないなら。 この場合、連絡された方針ゲートウェイは、手の届かない方針ゲートウェイの同輩の居場所を見つけるのを試みます、元の経路で。順番に、ゲートウェイは手の届かない方針ゲートウェイに続いて、隣の方針ゲートウェイの場所を見つけるのを試みます。
Steenstrup [Page 31] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[31ページ]RFC1478IDPRアーキテクチャ1993年6月
If it successfully reaches the next policy gateway, the contacted policy gateway informs the requesting policy gateway. In this case, the requesting, contacted, and next policy gateways update their forwarding information databases to conform to the new part of the path. If it does not successfully reach the next policy gateway, the contacted policy gateway initiates teardown of the original path; in this case, the source path agent is responsible for finding a new route to the destination.
首尾よく隣の方針ゲートウェイに達するなら、連絡された方針ゲートウェイは要求している方針ゲートウェイを知らせます。 この場合要求、次に連絡されて、方針ゲートウェイは経路の新しい地域に従うためにそれらの推進情報データベースをアップデートします。 首尾よく隣の方針ゲートウェイに達しないなら、連絡された方針ゲートウェイは元の経路の分解を起こします。 この場合、ソースの経路エージェントは新しいルートを目的地に見つけるのに責任があります。
4.5.2. Partitions
4.5.2. パーティション
A "domain partition" exists whenever there are at least two entities within the domain that can no longer communicate over any intra- domain route. Domain partitions not only disrupt intra-domain communication but also may interfere with inter-domain communication, particularly when the partitioned domain is a transit domain. Therefore, we have designed the IDPR architecture to permit effective use of partitioned domains and hence maximize Internet connectivity in the presence of domain partitions.
もうどんなイントラドメインルートにわたっても交信できないドメインの中に少なくとも2つの実体があるときはいつも、「ドメインパーティション」は存在しています。 ドメインパーティションはイントラドメイン通信システムを遮断するだけではなく、相互ドメインコミュニケーションを妨げもするかもしれません、特に仕切られたドメインがトランジットドメインであるときに。 したがって、私たちは、仕切られたドメインの有効な使用を可能にして、したがって、ドメインパーティションがあるときインターネットの接続性を最大にするようにIDPRアーキテクチャを設計しました。
When a domain is partitioned, it becomes a set of multiple distinct "components". A domain component is a subset of the domain's entities such that all entities within the subset are mutually reachable via intra-domain routes, but no entities in the complement of the subset are reachable via intra-domain routes from entities within the subset. Each domain component has a unique identifier, namely the identifier of the domain together with the ordinal number of the lowest-numbered operational policy gateway within the domain component. No negotiation among policy gateways is necessary to determine the domain component's lowest-numbered operational policy gateway. Instead, within each domain component, all policy gateway members discover mutual reachability through intra-domain reachability information. Therefore, all members have a consistent view of which is the lowest-numbered operational policy gateway in the component.
ドメインが仕切られるとき、それは複数の異なった「コンポーネント」の1セットになります。 部分集合の中のすべての実体がドメインコンポーネントがドメインの実体の部分集合であるので、イントラドメインルートで互いに届きますが、部分集合の補数におけるどんな実体も部分集合の中で実体からのイントラドメインルートで届いていません。 それぞれのドメインコンポーネントは最も低く番号付の運用政策ゲートウェイの序数詞と共にドメインコンポーネントの中にユニークな識別子、すなわち、ドメインに関する識別子を持っています。 方針ゲートウェイの中のどんな交渉も、ドメインコンポーネントの最も低く番号付の運用政策ゲートウェイを決定するのに必要ではありません。 代わりに、すべての方針ゲートウェイメンバーがイントラドメイン可到達性情報を通してそれぞれのドメインコンポーネントの中では、互いの可到達性を発見します。 したがって、メンバーが持っているそれの一貫した視点がコンポーネントで最も低く番号付の運用政策ゲートウェイであるすべて。
IDPR entities can detect and compensate for all domain partitions that isolate at least two groups of policy gateways from each other. They cannot, however, detect any domain partition that isolates groups of hosts only. Note that a domain partition may segregate portions of a virtual gateway, such that peer policy gateways lie in separate domain components. Although itself partitioned, the virtual gateway does not assume any additional identities. However, from the perspective of the adjacent domain, the virtual gateway now connects to two separate domain components.
IDPR実体は、互いから方針ゲートウェイの少なくとも2つのグループを隔離するすべてのドメインパーティションを、検出して、補うことができます。 しかしながら、彼らはホストだけのグループを隔離する少しのドメインパーティションも検出できません。 ドメインパーティションが仮想のゲートウェイの一部を隔離するかもしれないことに注意してください、別々のドメインコンポーネントには同輩方針ゲートウェイがあるように。 それ自体で仕切られますが、仮想のゲートウェイは少しの追加アイデンティティも仮定しません。 しかしながら、隣接しているドメインの見解から、仮想のゲートウェイは現在、2つの別々のドメインコンポーネントに接続します。
Policy gateways use partition information to select routes across virtual gateways to the correct domain components. They also
方針ゲートウェイは、正しいドメインコンポーネントへの仮想のゲートウェイの向こう側にルートを選択するのにパーティション情報を使用します。 それらも
Steenstrup [Page 32] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[32ページ]RFC1478IDPRアーキテクチャ1993年6月
distribute partition information to route servers as part of the IDPR routing information. Thus, route servers know which domains are partitioned. However, route servers do not know which hosts reside in which components of a partitioned domain; tracking this information would require extensive computation and communication. Instead, when a route server discovers that the destination of a requested route is a partitioned domain, it attempts to generate a suitable policy route to each component of the destination domain. Generation of multiple routes, on detection of a partitioned destination domain, maximizes the chances of obtaining at least one policy route that can be used for communication between the source and destination hosts.
パーティション情報を分配して、IDPRルーティング情報の一部としてサーバを発送してください。 したがって、ルートサーバは、どのドメインが仕切られるかを知っています。 しかしながら、ルートサーバは、どのホストがどのコンポーネントに住んでいるかを仕切られたドメインを知りません。 この情報を追跡するのは大規模な計算とコミュニケーションを必要とするでしょう。 ルートサーバが、要求されたルートの目的地が仕切られたドメインであると発見するとき、代わりに、それは、目的地ドメインの各コンポーネントに適当な方針ルートを生成するのを試みます。 仕切られた目的地ドメインの検出における複数のルートの世代はソースとあて先ホストとのコミュニケーションに使用できる少なくとも1つの方針ルートを入手するという可能性を最大にします。
Steenstrup [Page 33] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[33ページ]RFC1478IDPRアーキテクチャ1993年6月
5. References
5. 参照
[1] Rekhter, Y., "EGP and Policy Based Routing in the New NSFNET
Backbone", RFC 1092, February 1989.
[1]Rekhter、Y.、「EGPと方針は新しいNSFNETバックボーンにおけるルート設定を基礎づけた」RFC1092、1989年2月。
[2] Clark, D., "Policy Routing in Internet Protocols", RFC 1102, May
1989.
[2] クラーク(D.、「インターネットプロトコルにおける方針ルート設定」、RFC1102)は1989がそうするかもしれません。
[3] Braun, H-W., "Models of Policy Based Routing", RFC 1104, June
1989.
[3] ブラウン、H-W.、「方針のベースのルート設定のモデル」、RFC1104、1989年6月。
[4] Leiner, B., "Policy Issues in Interconnecting Networks", RFC
1124, September 1989.
[4]Leiner、B.、「ネットワークとインタコネクトすることにおける政策問題」、RFC1124、1989年9月。
[5] Estrin, D., "Requirements for Policy Based Routing in the
Research Internet", RFC 1125, November 1989.
[5]Estrin、D.、「研究インターネットの方針のベースのルート設定のための要件」、RFC1125、1989年11月。
[6] Little, M., "Goals and Functional Requirements for Inter-
Autonomous System Routing", RFC 1126, July 1989.
[6] 少しと、M.と、「相互自律システムルート設定のための目標と機能条件書」、RFC1126、7月1989日
[7] Honig, J., Katz, D., Mathis, M., Rekhter, Y., and Yu, J.,
"Application of the Border Gateway Protocol in the Internet",
RFC 1164, June 1990.
[7] ホニッグとJ.とキャッツとD.とマシスとM.とRekhter、Y.とユー、J.、「インターネットでのボーダ・ゲイトウェイ・プロトコルの応用」RFC1164(1990年6月)。
[8] Lougheed, K. and Rekhter, Y., "A Border Gateway Protocol 3
(BGP-3)", RFC 1267, October 1991.
[8] ロッキードとK.とRekhter、Y.、「ボーダ・ゲイトウェイ・プロトコル3(BGP-3)」、RFC1267 1991年10月。
[9] Rekhter, Y. and Li, T. Editors, "A Border Gateway Protocol 4
(BGP-4)", Work in Progress, September 1992.
[9] T.エディターズ、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」というRekhter、Y.、および李は進歩、1992年9月に働いています。
[10] ISO, "Information Processing Systems - Telecommunications and
Information Exchange between Systems - Protocol for Exchange of
Inter-domain Routeing Information among Intermediate Systems to
Support Forwarding of ISO 8473 PDUs", ISO/IEC DIS 10747, August
1992.
[10] ISO、「情報処理システム(システムの間のテレコミュニケーションと情報交換)が中間システムの中の相互ドメインRouteing情報の交換のためにサポート推進に議定書を作る、ISO8473PDUs、」、ISO/IEC不-10747、8月1992日
[11] Perlman, R., "Network Layer Protocols with Byzantine Robust-
ness", Ph.D. Thesis, Department of Electrical Engineering and
Computer Science, MIT, August 1988.
[11] パールマンとR.と「込み入ったRobust岬があるネットワークLayerプロトコル」と博士号ThesisとElectrical Engineeringの部とコンピュータScience、MIT(1988年8月)。
[12] Estrin, D. and Tsudik, G., "Secure Control of Transit Internet-
work Traffic", TR-89-15, Computer Science Department, University
of Southern California.
[12] Estrin、D.、およびTsudik(G.)は「Transitインターネット仕事TrafficのControlを固定します」、TR-89-15、コンピュータ理学部、南カリフォルニアの大学。
[13] Garcia-Luna-Aceves, J.J., "A Unified Approach for Loop-Free
Routing using Link States or Distance Vectors", ACM Computer
Communication Review, Vol. 19, No. 4, SIGCOMM 1989, pp. 212-223.
[13]ガルシアルーナAceves、J.J.、「無輪のルート設定のためのリンク州か距離ベクトルを使用する統一されたアプローチ」、ACMコンピュータCommunication Review、Vol.19、No.4、SIGCOMM1989、ページ 212-223.
Steenstrup [Page 34] RFC 1478 IDPR Architecture June 1993
ステーンストルプ[34ページ]RFC1478IDPR構造1993年6月
[14] Zaumen, W.T. and Garcia-Luna-Aceves, J.J., "Dynamics of Distri-
buted Shortest-Path Routing Algorithms", ACM Computer Communica-
tion Review, Vol. 21, No. 4, SIGCOMM 1991, pp. 31-42.
[14]ZaumenとW.T.とガルシアルーナAceves、J.J.、「Distri- buted Shortest-経路ルート設定Algorithmsの力学」、ACMコンピュータCommunica- tion Review、Vol.21、No.4、SIGCOMM1991、ページ 31-42.
6. Security Considerations
6. セキュリティ問題
Refer to section 3.3 for details on security in IDPR.
IDPRのセキュリティに関する詳細についてセクション3.3を参照してください。
7. Author's Address
7. 作者のアドレス
Martha Steenstrup
BBN Systems and Technologies
10 Moulton Street
Cambridge, MA 02138
マーサステーンストルプBBN Systemsと技術10モールトン・通りケンブリッジ、MA 02138
Phone: (617) 873-3192
Email: msteenst@bbn.com
以下に電話をしてください。 (617) 873-3192 メールしてください: msteenst@bbn.com
Steenstrup [Page 35]
ステーンストルプ[35ページ]
一覧
スポンサーリンク
