RFC1992 日本語訳
1992 The Nimrod Routing Architecture. I. Castineyra, N. Chiappa, M.Steenstrup. August 1996. (Format: TXT=59848 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group I. Castineyra
Request for Comments: 1992 BBN
Category: Informational N. Chiappa
M. Steenstrup
BBN
August 1996
Castineyraがコメントのために要求するワーキンググループI.をネットワークでつないでください: 1992年のBBNカテゴリ: 情報のN.Chiappa M.ステーンストルプBBN1996年8月
The Nimrod Routing Architecture
ニムロデルート設定構造
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
We present a scalable internetwork routing architecture, called Nimrod. The Nimrod architecture is designed to accommodate a dynamic internetwork of arbitrary size with heterogeneous service requirements and restrictions and to admit incremental deployment throughout an internetwork. The key to Nimrod's scalability is its ability to represent and manipulate routing-related information at multiple levels of abstraction.
ニムロデは、私たちがスケーラブルなネットワーク間ルーティング構造を提示すると呼びました。 ニムロデ構造は、異種のサービス要件と制限がある任意のサイズのダイナミックなインターネットワークを収容して、インターネットワーク中に増加の展開を認めるように設計されています。 ニムロデのスケーラビリティのキーは複数のレベルの抽象化でルーティング関連の情報を表して、操るその性能です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview of Nimrod . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Constraints of the Internetworking Environment . . . . . . . 3
2.2 The Basic Routing Functions . . . . . . . . . . . . . . . . . 5
2.3 Scalability Features . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Clustering and Abstraction . . . . . . . . . . . . . . . 6
2.3.2 Restricting Information Distribution . . . . . . . . . . 7
2.3.3 Local Selection of Feasible Routes . . . . . . . . . . . 8
2.3.4 Caching . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.5 Limiting Forwarding Information . . . . . . . . . . . . . 8
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Nodes and Adjacencies . . . . . . . . . . . . . . . . . . . . 9
3.3 Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1 Connectivity Specifications . . . . . . . . . . . . . . 10
3.4 Locators . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5 Node Attributes . . . . . . . . . . . . . . . . . . . . . . 11
3.5.1 Adjacencies . . . . . . . . . . . . . . . . . . . . . . 11
3.5.2 Internal Maps . . . . . . . . . . . . . . . . . . . . . 11
3.5.3 Transit Connectivity . . . . . . . . . . . . . . . . . . 12
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 ニムロデの概観、基本的な経路選択機能. . . . . . . . . . . . . . . . . 5 2.3スケーラビリティが.62.3に.1のクラスタリングと抽象化を特徴とするというインターネットワーキング環境. . . . . . . 3 2.2の.32.1の規制; . . . . . . . . . . . . . . 6 2.3.2 情報. . . . . . . . . . . . . 8 3を転送しながら、可能なルート. . . . . . . . . . . 8 2.3.4キャッシュ. . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.5制限の情報流通.72.3.3局所的選択を制限すること。 構造. . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1終点. . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2ノードと隣接番組. . . . . . . . . . . . . . . . . . . . 9 3.3地図. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.1の接続性仕様…; 10 3.4のロケータ. . . . . . . . . . . . . . . . . . . . . . . . . 10 3.5のノード属性. . . . . . . . . . . . . . . . . . . . . . 11 3.5.1の隣接番組. . . . . . . . . . . . . . . . . . . . . . 11 3.5.2の内部の地図. . . . . . . . . . . . . . . . . . . . . 11 3.5.3トランジットの接続性. . . . . . . . . . . . . . . . . . 12
Castineyra, et. al. Informational [Page 1] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[1ページ]のRFC1992ニムロデ
3.5.4 Inbound Connectivity . . . . . . . . . . . . . . . . . . 12
3.5.5 Outbound Connectivity . . . . . . . . . . . . . . . . . 12
4. Physical Realization . . . . . . . . . . . . . . . . . . . . . 13
4.1 Contiguity . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 An Example . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Multiple Locator Assignment . . . . . . . . . . . . . . . . 15
5. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.1 Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2 Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3 Connectivity Specification (CSC) Mode . . . . . . . . . . . 24
5.4 Flow Mode . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.5 Datagram Mode . . . . . . . . . . . . . . . . . . . . . . . 25
5.6 Connectivity Specification Sequence Mode . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
3.5.4 本国行きの接続性. . . . . . . . . . . . . . . . . . 12 3.5.5の外国行きの接続性. . . . . . . . . . . . . . . . . 12 4。 物理的な実現. . . . . . . . . . . . . . . . . . . . . 13 4.1の接触. . . . . . . . . . . . . . . . . . . . . . . . 13 4.2は例. . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3の複数のロケータ課題. . . . . . . . . . . . . . . . 15 5です。 推進. . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1方針. . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2信用. . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.3接続性仕様(CSC)モード. . . . . . . . . . . 24 5.4流れモード. . . . . . . . . . . . . . . . . . . . . . . . . 25 5.5データグラムモード. . . . . . . . . . . . . . . . . . . . . . . 25 5.6接続性仕様系列モード. . . . . . . . . . 26 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 26 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 26 7。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
1. 序論
Nimrod is a scalable routing architecture designed to accommodate a continually expanding and diversifying internetwork. First suggested by Noel Chiappa, the Nimrod architecture has undergone revision and refinement through the efforts of the Nimrod working group of the IETF. In this document, we present a detailed description of this architecture.
ニムロデは絶えず広がっていて多角化しているインターネットワークを収容するように設計されたスケーラブルなルーティング構造です。 1番目はクリスマスChiappaによって示されて、ニムロデ構造はIETFのニムロデワーキンググループの努力で改正と気品を受けました。 本書では、私たちはこの構造の詳述を提示します。
The goals of Nimrod are as follows:
ニムロデの目標は以下の通りです:
1. To support a dynamic internetwork of arbitrary size by
providing mechanisms to control the amount of routing information
that must be known throughout an internetwork.
1. ルーティング情報の量を制御するためにメカニズムを提供することによって任意のサイズのダイナミックなインターネットワークを支持するために、インターネットワーク中でそれを知っていなければなりません。
2. To provide service-specific routing in the presence of multiple
constraints imposed by service providers and users.
2. 複数の面前でサービス特有のルーティングを提供するために、規制はサービスプロバイダーとユーザででしゃばりました。
3. To admit incremental deployment throughout an internetwork.
3. インターネットワーク中に増加の展開を認めるために。
We have designed the Nimrod architecture to meet these goals. The key features of this architecture include:
私たちは、これらの目標を達成するようにニムロデ構造を設計しました。 この構造に関する重要な特色は:
1. Representation of internetwork connectivity and services in the
form of maps at multiple levels of abstraction.
1. 複数のレベルの抽象化における地図の形におけるインターネットワークの接続性の、そして、サービスの表現。
2. User-controlled route generation and selection based on maps and
traffic service requirements.
2. ユーザによって制御されたルート世代と選択はサービス要件を地図と交通に基礎づけました。
3. User-directed packet forwarding along established paths.
3. 確立した経路に沿ったユーザによって指示されたパケット推進。
Castineyra, et. al. Informational [Page 2] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[2ページ]のRFC1992ニムロデ
Nimrod is a general routing architecture that can be applied to routing both within a single routing domain and among multiple routing domains. As a general internetwork routing architecture designed to deal with increased internetwork size and diversity, Nimrod is equally applicable to both the TCP/IP and OSI environments.
ニムロデはただ一つの経路ドメインと複数の経路ドメインの中のルーティングに適用できる一般的なルーティング構造です。 増加するインターネットワークサイズと多様性に対処するように設計された一般的なネットワーク間ルーティング構造として、ニムロデは等しくTCP/IPとOSI環境の両方に適切です。
2. Overview of Nimrod
2. ニムロデの概観
Before describing the Nimrod architecture in detail, we provide an overview. We begin with the internetworking requirements, followed by the routing functions, and concluding with Nimrod's scaling characteristics.
詳細にニムロデ構造について説明する前に、私たちは概観を提供します。 経路選択機能があとに続いていて、ニムロデのスケーリングの特性で締めくくって、私たちはインターネットワーキング要件で始めます。
2.1 Constraints of the Internetworking Environment
2.1 インターネットワーキング環境の規制
Internetworks are growing and evolving systems, in terms of number, diversity, and interconnectivity of service providers and users, and therefore require a routing architecture that can accommodate internetwork growth and evolution. A complicated mix of factors such as technological advances, political alliances, and service supply and demand economics will determine how an internetwork will change over time. However, correctly predicting all of these factors and all of their effects on an internetwork may not be possible. Thus, the flexibility of an internetwork routing architecture is its key to handling unanticipated requirements.
インターネットワークは、サービスプロバイダーとユーザの数、多様性、および相互接続性に関して成長して、システムを発展していて、したがって、インターネットワークの成長と発展に対応できるルーティング構造を必要とします。 技術的進歩や、政治上の連合や、サービス需要と供給経済学などの要素の複雑なミックスは、インターネットワークが時間がたつにつれてどのように変化するかを決定するでしょう。 しかしながら、正しくこれらの要素のすべてとインターネットワークへのそれらの効果のすべてを予測するのは可能でないかもしれません。 したがって、ネットワーク間ルーティング構造の柔軟性はその思いがけない要件を扱うキーです。
In developing the Nimrod architecture, we first assembled a list of internetwork environmental constraints that have implications for routing. This list, enumerated below, includes observations about the present Internet; it also includes predictions about internetworks five to ten years in the future.
ニムロデ構造を開発する際に、私たちは最初に、ルーティングのために意味を持っているインターネットワーク環境的制約のリストを組み立てました。 以下に数え上げられたこのリストは現在のインターネットに関して観測を含んでいます。 また、それは将来、5〜10年間インターネットワークに関する予測を含みます。
1. The Internet will grow to include O(10^9) networks.
1. インターネットはO(10^9)ネットワークを含むようになるでしょう。
2. The number of internetwork users may be unbounded.
2. インターネットワークユーザの数は限りないかもしれません。
3. The capacity of internetwork resources is steadily increasing but
so is the demand for these resources.
3. インターネットワークリソースの容量は着実に増加していますが、これらのリソースの要求もそうです。
4. Routers and hosts have finite processing capacity and finite
memory, and networks have finite transmission capacity.
4. ルータとホストには、有限処理容量と有限記憶力があります、そして、ネットワークには、有限送信能力があります。
5. Internetworks comprise different types of communications media --
including wireline, optical and wireless, terrestrial and
satellite, shared multiaccess and point-to-point -- with different
service characteristics in terms of throughput, delay, error and
loss distributions, and privacy.
5. インターネットワークは異なったサービスの特性でスループット、遅れ、誤り、損失配、およびプライバシーに関して光学と無線の、そして、地球のワイヤーラインと衛星を含んでいると多重処理とポイントツーポイントが共有されたという異なったタイプの通信機関を包括します。
Castineyra, et. al. Informational [Page 3] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[3ページ]のRFC1992ニムロデ
6. Internetwork elements -- networks, routers, hosts, and processes --
may be mobile.
6. インターネットワーク要素(ネットワーク、ルータ、ホスト、および過程)は可動であるかもしれません。
7. Service providers will specify offered services and restrictions on
access to those services. Restrictions may be in terms of when a
service is available, how much the service costs, which users may
subscribe to the service and for what purposes, and how the user
must shape its traffic in order to receive a service guarantee.
7. サービスプロバイダーはそれらのサービスへのアクセスのときに提供サービスと制限を指定するでしょう。 時とどんな目的とユーザがサービス保証を受け取るためにどのように交通を形成しなければならないように、制限はあるかもしれないか。(その時、サービスは利用可能であり、どのくらいのサービスコスト、そのユーザはサービスに加入するかもしれないか)。
8. Users will specify traffic service requirements which may vary
widely among sessions. These specifications may be in terms of
requested qualities of service, the amounts they are willing to pay
for these services, the times at which they want these services,
and the providers they wish to use.
8. ユーザはセッションのときにばらつきが大きいかもしれない交通サービス要件を指定するでしょう。 要求されたサービスの品質に関してこれらの仕様があるかもしれません、彼らがこれらのサービスのために支払っても構わないと思っている量、自分達がそれらが利用したがっているこれらのサービス、およびプロバイダーが欲しい回。
9. A user traffic session may include m sources and n destinations,
where m, n > or = 1.
9. ユーザ交通セッションはmソースとnの目的地、どこm、n>または=1を含むかもしれないか。
10. Service providers and users have a synergistic relationship. That
is, as users develop more applications with special service
requirements, service providers will respond with the services to
meet these demands. Moreover, as service providers deliver more
services, users will develop more applications that take advantage
of these services.
10. サービスプロバイダーとユーザには、相乗の関係があります。 すなわち、ユーザが特別なサービス要件で、より多くのアプリケーションを開発するとき、サービスプロバイダーは、これらの需要にこたえるためにサービスで応じるでしょう。 そのうえ、サービスプロバイダーが、より多くのサービスを提供するとき、ユーザはこれらのサービスを利用するより多くのアプリケーションを開発するでしょう。
11. Support for varied and special services will require more
processing, memory, and transmission bandwidth on the part of both
the service providers offering these services and the users
requesting these services. Hence, many routing-related activities
will likely be performed not by routers and hosts but rather by
independent devices acting on their behalf to process, store, and
distribute routing information.
11. 様々で特別なサービスのサポートはこれらのサービスを提供するサービスプロバイダーとこれらのサービスを要求するユーザの両方側のより多くの処理、メモリ、およびトランスミッション帯域幅を必要とするでしょう。 ルーティング情報をしたがって、多くのルーティング関連の活動がルータとホストに実行されるのではなく、むしろそれらの利益に影響する独立している装置によっておそらく実行されて、処理して、格納して、分配するでしょう。
12. Users requiring specialized services (e.g., high guaranteed
throughput) will usually be willing to pay more for these services
and to incur some delay in obtaining them.
12. 通常、専門化しているサービス(例えば、高い保証されたスループット)を必要とするユーザは、より多くこれらのサービスの代価を払い、それらを得る何らかの遅れを被っても構わないと思うでしょう。
13. Service providers are reluctant to introduce complicated protocols
into their networks, because they are more difficult to manage.
13. 管理するのが、より難しいので、サービスプロバイダーはそれらのネットワークに複雑なプロトコルを取り入れるのに気が重いです。
14. Vendors are reluctant to implement complicated protocols in their
products, because they take longer to develop.
14. 彼らが展開するために時間がかかるので、業者はそれらの製品の中の複雑なプロトコルを実行するのに気が重いです。
Collectively, these constraints imply that a successful internetwork routing architecture must support special features, such as service- specific routing and component mobility in a large and changing internetwork, using simple procedures that consume a minimal amount of internetwork resources. We believe that the Nimrod architecture
これらの規制は、うまくいっているネットワーク間ルーティング構造が特徴を支持しなければならないのをまとめて、含意します、大きくて変化しているインターネットワークにおけるサービスの特定のルーティングやコンポーネントの移動性のように、インターネットワークリソースの最少量を消費する簡単な手順を用いて。 私たちは、それがニムロデ構造であると信じています。
Castineyra, et. al. Informational [Page 4] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[4ページ]のRFC1992ニムロデ
meets these goals, and we justify this claim in the remainder of this document.
これらの目標を達成する、私たちはこのドキュメントの残りにおけるこのクレームを正当化します。
2.2 The Basic Routing Functions
2.2 基本的な経路選択機能
The basic routing functions provided by Nimrod are those provided by any routing system, namely:
すなわち、ニムロデがどんなルーティングシステムによっても提供されたものであるなら機能を発送する基礎、:
1. Collecting, assembling, and distributing the information necessary
for route generation and selection.
1. ルート世代と選択のために必要情報を集めて、組み立てて、分配します。
2. Generating and selecting routes based on this information.
2. この情報に基づくルートを、発生して、選択します。
3. Establishing in routers information necessary for forwarding
packets along the selected routes.
3. 選択されたルートに沿って推進に必要なルータ情報にパケットを設立します。
4. Forwarding packets along the selected routes.
4. 選択されたルートに沿ってパケットを進めます。
The Nimrod approach to providing this routing functionality includes map distribution according to the "link-state" paradigm, localization of route generation and selection at traffic sources and destinations, and specification of packet forwarding through path establishment by the sources and destinations.
このルーティングの機能性を提供することへのニムロデアプローチは「リンク状態」パラダイム、ルート世代のローカライズ、交通源と目的地での選択、およびパケット推進の仕様通りにソースと目的地のそばに経路設立で地図分配を含んでいます。
Link-state map distribution permits each service provider to have control over the services it offers, through both distributing restrictions in and restricting distribution of its routing information. Restricting distribution of routing information serves to reduce the amount of routing information maintained throughout an internetwork and to keep certain routing information private. However, it also leads to inconsistent routing information databases throughout an internetwork, as not all such databases will be complete or identical. We expect routing information database inconsistencies to occur often in a large internetwork, regardless of whether privacy is an issue. The reason is that we expect some devices to be incapable of maintaining the complete set of routing information for the internetwork. These devices will select only some of the distributed routing information for storage in their databases.
リンク州の地図分配は、各サービスプロバイダーがそれが提供するサービスを管理することを許可します、ルーティング情報について制限を広げて、分配を制限することで。 ルーティング情報の分配を制限するのはインターネットワーク中で保守されたルーティング情報の量を減少させて、あるルーティング情報を個人的に保つのに役立ちます。 しかしながら、また、インターネットワーク中で矛盾したルーティング情報データベースに通じます、すべてのそのようなどんなデータベースも完全であるか、または同じになるというわけではないとき。 私たちは、プライバシーが問題であるかどうかにかかわらずルーティング情報データベース矛盾が大きいインターネットワークで頻出すると予想します。 理由は私たちが、いくつかの装置がインターネットワークのための完全なルーティング情報を保守できないと予想するということです。 これらの装置はそれらのデータベースで格納のための何らかのだけ分配されたルーティング情報を選択するでしょう。
Route generation and selection, based on maps and traffic service requirements, may be completely controlled by the users or, more likely, by devices acting on their behalf and does not require global coordination among routers. Thus these devices may generate routes specific to the users' needs, and only those users pay the cost of generating those routes. Locally-controlled route generation allows incremental deployment of and experimentation with new route generation algorithms, as these algorithms need not be the same at
地図と交通サービス要件に基づくルート世代と選択は、ユーザかおそらくそれらの利益に影響する装置によって完全に制御されるかもしれなくて、ルータの中でグローバルなコーディネートを必要としません。 したがって、これらの装置はユーザーのニーズに特定のルートを発生させるかもしれません、そして、それらのユーザだけがそれらのルートを発生させる費用を支払います。 局所的に制御されたルート世代はこれらとしてのアルゴリズムが同じである必要はない新しいルート世代アルゴリズムがある増加の展開と実験を許します。
Castineyra, et. al. Informational [Page 5] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[5ページ]のRFC1992ニムロデ
each location in an internetwork.
インターネットワークにおける各位置。
Packet forwarding according to paths may be completely controlled by the users or the devices acting on their behalf. These paths may be specified in as much detail as the maps permit. Such packet forwarding provides freedom from forwarding loops, even when routers in a path have inconsistent routing information. The reason is that the forwarding path is a route computed by a single device and based on routing information maintained at a single device.
経路に従ったパケット推進はそれらの利益に影響するユーザか装置によって完全に制御されるかもしれません。 これらの経路は地図が可能にするのと同じくらい多くの詳細に指定されるかもしれません。 経路のルータに矛盾したルーティング情報がありさえするときさえ、そのようなパケット推進は推進輪から自由を提供します。 理由は推進経路が単一の装置によって計算されて、単一の装置で保守されたルーティング情報に基づくルートであるということです。
We note that the Nimrod architecture and Inter-Domain Policy Routing (IDPR) [1] share in common link-state routing information distribution, localized route generation and path-oriented message forwarding. In developing the Nimrod architecture, we have drawn upon experience gained in developing and experimenting with IDPR.
私たちは、ニムロデ構造とInter-ドメインPolicyルート設定(IDPR)[1]が一般的なリンク州のルーティング情報流通、局所化されたルート世代、および経路指向のメッセージ推進を分担することに注意します。 ニムロデ構造を開発する際に、私たちはIDPRを開発して、実験する際に行われた経験を利用しました。
2.3 Scalability Features
2.3 スケーラビリティ機能
Nimrod must provide service-specific routing in arbitrarily large internetworks and hence must employ mechanisms that help to contain the amount of internetwork resources consumed by the routing functions. We provide a brief synopsis of such mechanisms below, noting that arbitrary use of these mechanisms does not guarantee a scalable routing architecture. Instead, these mechanisms must be used wisely, in order enable a routing architecture to scale with internetwork growth.
ニムロデは、サービス特有のルーティングを任意に大きいインターネットワークに提供しなければならなくて、したがって、経路選択機能によって消費されたインターネットワークリソースの量を含むのを助けるメカニズムを使わなければなりません。 私たちは以下のそのようなメカニズムの簡単な大意を提供します、これらのメカニズムの任意の使用がスケーラブルなルーティング構造を保証しないことに注意して。 代わりに、ルーティング構造がインターネットワークの成長で比例するのを可能にするのに賢明にこれらのメカニズムを使用しなければなりません。
2.3.1 Clustering and Abstraction
2.3.1 クラスタリングと抽象化
The Nimrod architecture is capable of representing an internetwork as clusters of entities at multiple levels of abstraction. Clustering reduces the number of entities visible to routing. Abstraction reduces the amount of information required to characterize an entity visible to routing.
ニムロデ構造は実体のクラスタとして複数のレベルの抽象化でインターネットワークを表すことができます。 クラスタリングはルーティングに目に見える実体の数を減少させます。 抽象化はルーティングに目に見える実体を特徴付けるのに必要である情報量を減少させます。
Clustering begins by aggregating internetwork elements such as hosts, routers, and networks according to some predetermined criteria. These elements may be clustered according to relationships among them, such as "managed by the same authority", or so as to satisfy some objective function, such as "minimize the expected amount of forwarding information stored at each router". Nimrod does not mandate a particular cluster formation algorithm.
クラスタリングは、いくつかの予定された評価基準に従ってホストや、ルータや、ネットワークなどのインターネットワーク原理に集めることによって、始まります。 それらの中の関係に従って、これらの要素は群生するかもしれません、「同じ権威で、管理される」か、または何らかの目的関数を満たすために、「各ルータで格納された予想された量の推進情報を最小にしてください」などのように。 ニムロデは特定のクラスタ構成アルゴリズムを強制しません。
New clusters may be formed by clustering together existing clusters. Repeated clustering of entities produces a hierarchy of clusters with a unique universal cluster that contains all others. The same clustering algorithm need not be applied at each level in the hierarchy.
新しいクラスタは、既存のクラスタに群がることによって、形成されるかもしれません。 実体の繰り返されたクラスタリングはすべての他のものを含むユニークな普遍的なクラスタでクラスタの階層構造を作成します。 同じクラスタ化アルゴリズムは各レベルで階層構造で適用される必要はありません。
Castineyra, et. al. Informational [Page 6] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[6ページ]のRFC1992ニムロデ
All elements within a cluster must satisfy at least one relation, namely connectivity. That is, if all elements within a cluster are operational, then any two of them must be connected by at least one route that lies entirely within that cluster. This condition prohibits the formation of certain types of separated clusters, such as the following. Suppose that a company has two branches located at opposite ends of a country and that these two branches must communicate over a public network not owned by the company. Then the two branches cannot be members of the same cluster, unless that cluster also includes the public network connecting them.
クラスタの中のすべての要素が少なくとも1つの関係、すなわち、接続性を満たさなければなりません。 すなわち、クラスタの中のすべての要素が操作上であるなら、そのクラスタに完全に属す少なくとも1つのルートでそれらのどんな2つも接続しなければなりません。 この状態はあるタイプの以下などの切り離されたクラスタの構成を禁止します。 会社が国の反対端に2つのブランチを位置させていて、これらの2つのブランチが会社によって所有されていなかった公衆通信回線の上で交信しなければならないと仮定してください。 次に、2つのブランチが同じクラスタのメンバーであるはずがありません、また、そのクラスタが彼らを接続する公衆通信回線を含んでいない場合。
Once the clusters are formed, their connectivity and service information is abstracted to reduce the representation of cluster characteristics. Example abstraction procedures include elimination of services provided by a small fraction of the elements in the cluster or expression of services in terms of average values. Nimrod does not mandate a particular abstraction algorithm. The same abstraction algorithm need not be applied to each cluster, and multiple abstraction algorithms may be applied to a single cluster.
クラスタがいったん形成されると、それらの接続性とサービス情報は、クラスタ特性の表現を抑えるので、抜き取られています。 例の抽象化手順は平均値に関してクラスタの要素のわずかな部分によって提供されたサービスの除去かサービスの表現を含んでいます。 ニムロデは特定の抽象化アルゴリズムを強制しません。 同じ抽象化アルゴリズムは各クラスタに適用される必要はありません、そして、複数の抽象化アルゴリズムが単一のクラスタに適用されるかもしれません。
A particular combination of clustering and abstraction algorithms applied to an internetwork results in an organization related to but distinct from the physical organization of the component hosts, routers, and networks. When a clustering is superimposed over the physical internetwork elements, the cluster boundaries may not necessarily coincide with host, router, or network boundaries. Nimrod performs its routing functions with respect to the hierarchy of entities resulting from clustering and abstraction, not with respect to the physical realization of the internetwork. In fact, Nimrod need not even be aware of the physical elements of an internetwork.
インターネットワークに適用されたクラスタリングと抽象化アルゴリズムの特定の組み合わせは物理的な組織と関連しますが、コンポーネントホスト、ルータ、およびネットワークにおいて異なった組織をもたらします。 クラスタリングが物理的なインターネットワーク要素の上重ねられるとき、クラスタ境界は必ずホスト、ルータ、またはネットワーク限界と一致するかもしれないというわけではありません。 ニムロデはインターネットワークの物理的な実現に関して実行するのではなく、クラスタリングと抽象化から生じる実体の階層構造に関して経路選択機能を実行します。 事実上、ニムロデはインターネットワークの物理的な要素を意識している必要さえありません。
2.3.2 Restricting Information Distribution
2.3.2 情報流通を制限すること。
The Nimrod architecture supports restricted distribution of routing information, both to reduce resource consumption associated with such distribution and to permit information hiding. Each cluster determines the portions of its routing information to distribute and the set of entities to which to distribute this information. Moreover, recipients of routing information are selective in which information they retain. Some examples are as follows. Each cluster might automatically advertise its routing information to its siblings (i.e., those clusters with a common parent cluster). In response to requests, a cluster might advertise information about specific portions of the cluster or information that applies only to specific users. A cluster might only retain routing information from clusters that provide universal access to their services.
構造が支持するニムロデは、ともにそのような分配に関連しているリソース消費を抑えて、情報隠蔽を可能にするためにルーティング情報の分配を制限しました。 各クラスタは分配するルーティング情報の部分とこの情報を分配する実体のセットを決定します。 そのうえ、ルーティング情報の受取人は彼らが保有するどの情報で選択能力があるか。 いくつかの例は以下の通りです。 各クラスタは自動的に兄弟(すなわち、一般的な親クラスタがあるそれらのクラスタ)にルーティング情報の広告を出すかもしれません。 要求に対応して、クラスタはクラスタの特定部位の情報か特定のユーザだけに適用される情報の広告を出すかもしれません。 クラスタは彼らのサービスへの普遍的なアクセスを提供するクラスタからのルーティング情報を保有するだけであるかもしれません。
Castineyra, et. al. Informational [Page 7] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[7ページ]のRFC1992ニムロデ
2.3.3 Local Selection of Feasible Routes
2.3.3 可能なルートの局所的選択
Generating routes that satisfy multiple constraints is usually an NP-complete problem and hence a computationally intensive procedure. With Nimrod, only those entities that require routes with special constraints need assume the computational load associated with generation and selection of such routes. Moreover, the Nimrod architecture allows individual entities to choose their own route generation and selection algorithms and hence the amount of resources to devote to these functions.
複数の規制を満たすルートを発生させるのは、通常NP完全な問題としたがって、計算上徹底的な手順です。 ニムロデと共に、特別な規制があるルートを必要とするそれらの実体だけが、コンピュータの負荷がそのようなルートの世代と品揃えに関連していると仮定しなければなりません。 そのうえ、ニムロデ構造は、個々の実体はこれらの機能に注ぐためにそれら自身のルート世代と選択アルゴリズムを選んで、したがって、リソースの量を選ぶのを許容します。
2.3.4 Caching
2.3.4 キャッシュ
The Nimrod architecture encourages caching of acquired routing information in order to reduce the amount of resources consumed and delay incurred in obtaining the information in the future. The set of routes generated as a by-product of generating a particular route is an example of routing information that is amenable to caching; future requests for any of these routes may be satisfied directly from the route cache. However, as with any caching scheme, the cached information may become stale and its use may result in poor quality routes. Hence, the routing information's expected duration of usefulness must be considered when determining whether to cache the information and for how long.
ニムロデ構造は、後天的なルーティング情報が将来情報を得る際に被られた消費されたリソースと遅れの量を減少させるためにキャッシュされるよう奨励します。 特定のルートを発生させる副産物として発生するルートのセットはキャッシュに従順なルーティング情報に関する例です。 これらのルートのどれかを求める今後の要求は直接経路キャッシュから満たされるかもしれません。 しかしながら、どんなキャッシュ計画ならも、キャッシュされた情報は聞き古したであるなるかもしれません、そして、使用は貧しい上質のルートをもたらすかもしれません。 したがって、ルーティング情報の有用性の予想された持続時間は、情報をキャッシュするかどうか決定するとき、考えられて、どれくらい長い間、そうしなければならないか。
2.3.5 Limiting Forwarding Information
2.3.5 推進情報を制限すること。
The Nimrod architecture supports two separate approaches for containing the amount of forwarding information that must be maintained per router. The first approach is to multiplex, over a single path (or tree, for multicast), multiple traffic flows with similar service requirements. The second approach is to install and retain forwarding information only for active traffic flows.
ニムロデ構造はルータ単位で保守しなければならない推進情報の量を含むための2つの別々のアプローチを支持します。 最初のアプローチはただ一つの経路(または、マルチキャストのための木)にわたって同様のサービス要件がある複数の交通の流れを多重送信することです。 2番目のアプローチは、アクティブな交通の流れのためだけの推進情報をインストールして、保有することです。
With Nimrod, the service providers and users share responsibility for the amount of forwarding information in an internetwork. Users have control over the establishment of paths, and service providers have control over the maintenance of paths. This approach is different from that of the current Internet, where forwarding information is established in routers independent of demand for this information.
ニムロデと、サービスプロバイダーとユーザはインターネットワークにおける、推進情報の量への責任を共有します。 ユーザは経路の設立を管理します、そして、サービスプロバイダーは経路の維持を管理します。 このアプローチは現在のインターネットのものと異なっています。(そこでは、推進情報がこの情報の要求の如何にかかわらずルータに確立されます)。
3. Architecture
3. 構造
Nimrod is a hierarchical, map-based routing architecture that has been designed to support a wide range of user requirements and to scale to very large dynamic internets. Given a traffic stream's description and requirements (both quality of service requirements and usage-restriction requirements), Nimrod's main function is to
ニムロデはさまざまなユーザ要件を支持して、非常に大きいダイナミックなインターネットに比例するように設計されている階層的で、地図ベースのルーティング構造です。 記述と要件(サービスの質要件と用法限定要求の両方)、ニムロデの主な機能がある交通の流れのものを与えました。
Castineyra, et. al. Informational [Page 8] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[8ページ]のRFC1992ニムロデ
manage in a scalable fashion how much information about the internetwork is required to choose a route for that stream, in other words, to manage the trade-off between amount of information about the internetwork and the quality of the computed route. Nimrod is implemented as a set of protocols and distributed databases. The following sections describe the basic architectural concepts used in Nimrod. The protocols and databases are specified in other documents.
その流れのためのルートを選ぶインターネットワークのどのくらいの情報が必要であるスケーラブルなファッションで管理して、言い換えれば、インターネットワークに関する情報量と計算されたルートの品質の間のトレードオフを管理してください。 ニムロデは1セットのプロトコルと分散データベースとして実行されます。 以下のセクションはニムロデで使用される基本のアーキテクチャ概念について説明します。 プロトコルとデータベースは他のドキュメントで指定されます。
3.1 Endpoints
3.1 終点
The basic entity in Nimrod is the endpoint. An endpoint represents a user of the internetwork layer: for example, a transport connection. Each endpoint has at least one endpoint identifier (EID). Any given EID corresponds to a single endpoint. EIDs are globally unique, relatively short "computer-friendly" bit strings---for example, small multiples of 64 bits. EIDs have no topological significance whatsoever. For ease of management, EIDs might be organized hierarchically, but this is not required.
ニムロデの基本的対象は終点です。 終点はインターネットワーク層のユーザの代理をします: 例えば、輸送接続。 各終点には、少なくとも1つの終点識別子(EID)があります。 どんな与えられたEIDも単一の終点に対応しています。 EIDsはグローバルにユニークで、比較的短い「コンピュータに優しい」ビット列です。---例えば、64ビットのわずかな倍数。 EIDsには、位相的な意味が全くありません。管理の容易さにおいて、EIDsは階層的で組織化されるかもしれませんが、これは必要ではありません。
BEGIN COMMENT
コメントを始めてください。
In practice, EIDs will probably have a second form, which we can
call the endpoint label (EL). ELs are ASCII strings of unlimited
length, structured to be used as keys in a distributed database
(much like DNS names). Information about an endpoint---for
example, how to reach it---can be obtained by querying this
distributed database using the endpoint's label as key.
実際には、EIDsには、2番目のフォームがたぶんあるでしょう。(私たちは終点ラベル(EL)をそれと呼ぶことができます)。 ELsはキーとして分散データベース(DNS名のような)に使用されるために構造化された無制限な長さのASCIIストリングです。 終点に関する情報---例えば、それに達する方法---終点のラベルを使用するこの分散データベースについて同じくらい質問することによって、主要な得ることができます。
END COMMENT
終わりのコメント
3.2 Nodes and Adjacencies
3.2 ノードと隣接番組
A node represents a region of the physical network. The region of the network represented by a node can be as large or as small as desired: a node can represent a continent or a process running inside a host. Moreover, as explained in section 4, a region of the network can simultaneously be represented by more than one node.
ノードは物理ネットワークの領域を表します。 ノードによって代表されたネットワークの地域は、望まれているのと同じくらい広大であるか、または同じくらい小さいことができます: ノードはホストの中を走る大陸か過程を表すことができます。 そのうえ、セクション4で説明されるように、1つ以上のノードは同時に、ネットワークの領域を表すことができます。
An adjacency consists of an ordered pair of nodes. An adjacency indicates that traffic can flow from the first node to the second.
隣接番組は1順序対のノードから成ります。 隣接番組は、交通が最初のノードから2番目まで流れることができるのを示します。
3.3 Maps
3.3 地図
The basic data structure used for routing is the map. A map expresses the available connectivity between different points of an internetwork. Different maps can represent the same region of a physical network at different levels of detail.
ルーティングに使用される基礎データ構造は地図です。 地図はインターネットワークの異なったポイントの間の利用可能な接続性を言い表します。 異なった地図は異なったレベルの詳細で物理ネットワークの同じ領域を表すことができます。
Castineyra, et. al. Informational [Page 9] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[9ページ]のRFC1992ニムロデ
A map is a graph composed of nodes and adjacencies. Properties of nodes are contained in attributes associated with them. Adjacencies have no attributes. Nimrod defines languages to specify attributes and to describe maps.
地図はノードと隣接番組で構成されたグラフです。 ノードの特性はそれらに関連している属性に含まれています。 隣接番組には、属性が全くありません。 ニムロデは、属性を指定して、地図について説明するために言語を定義します。
Maps are used by routers to generate routes. In general, it is not required that different routers have consistent maps.
地図はルータによって使用されて、ルートを発生させます。 一般に、異なったルータには一貫した地図があるのが必要ではありません。
BEGIN COMMENT
コメントを始めてください。
Nimrod has been designed so that there will be no routing loops
even when the routing databases of different routers are not
consistent. A consistency requirement would not permit
representing the same region of the internetwork at different
levels of detail. Also, a routing-database consistency
requirement would be hard to guarantee in the very large internets
Nimrod is designed to support.
ニムロデは、異なったルータのルーティングデータベースが一貫してさえいないとき、ルーティング輪が全くないように、設計されています。 一貫性要件は、異なったレベルの詳細でインターネットワークの同じ領域を表すことを許可しないでしょう。 また、ルーティングデータベース一貫性要件は非常に大きいインターネットでニムロデがサポートに設計されているのを保証しにくいでしょう。
END COMMENT
終わりのコメント
In this document we speak only of routers. By "router" we mean a physical device that implements functions related to routing: for example, forwarding, route calculation, path set-up. A given device need not be capable of doing all of these to be called a router. The protocol specification document, see [2], splits these functionalities into specific agents.
本書では私たちはルータだけについて話します。 「ルータ」で、私たちはルーティングに関連する機能を実行するフィジカル・デバイスを言っています: 例えば、推進、ルート計算、経路セットアップ。 与えられた装置は、ルータと呼ばれるためにこれらがすべて、できる必要はありません。 特定のエージェントに仕様ドキュメントについて議定書の中で述べて、[2]を見て、これらの機能性を分けます。
3.3.1 Connectivity Specifications
3.3.1 接続性仕様
By connectivity between two points we mean the available services and the restrictions on their use. Connectivity specifications are among the attributes associated with nodes. The following are informal examples of connectivity specifications:
2ポイントの間の接続性で、私たちは彼らの使用のときに営業品目と制限を言っています。 ノードに関連している属性の中に接続性仕様があります。 ↓これは接続性仕様の非公式の例です:
o "Between these two points, there exists best-effort service with no
restrictions."
o 「これらの2ポイントの間では、制限のないベストエフォート型サービスは存在しています。」
o "Between these two points, guaranteed 10 ms delay can be arranged for
traffic streams whose data rate is below 1 Mbyte/sec and that have low
(specified) burstiness."
o 「これらの2ポイントの間では、データ信号速度が1メガバイト/秒未満であり、低い(指定された)burstinessを持っている交通の流れのために保証された10ms遅れを配置できます。」
o "Between these two points, best-effort service is offered, as long as
the traffic originates in and is destined for research organizations."
o 「これらの2ポイントの間に、ベストエフォート型サービスを提供します、交通が起こって、研究組織のために運命づけられている限り。」
3.4 Locators
3.4 ロケータ
A locator is a string of binary digits that identifies a location in an internetwork. Nodes and endpoint are assigned locators.
ロケータはインターネットワークにおける位置を特定する一連のバイナリー・ディジットです。 ロケータはノードと終点に割り当てられます。
Castineyra, et. al. Informational [Page 10] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[10ページ]のRFC1992ニムロデ
Different nodes have necessarily different locators. A node is assigned only one locator. Locators identify nodes and specify *where* a node is in the network. Locators do *not* specify a path to the node. An endpoint can be assigned more than one locator. In this sense, a locator might appear in more than one location of an internetwork.
異なったノードには、必ず異なったロケータがあります。 1つのロケータだけがノードに割り当てられます。 ロケータは、ノードを特定して、**ネットワークにはノードがどこにあるかを指定します。 ロケータは*でないのが指定する*にノードへの経路をします。 1つ以上のロケータを終点に割り当てることができます。 この意味で、ロケータはインターネットワークの複数の位置に現れるかもしれません。
In this document locators are written as ASCII strings that include colons to underline node structure: for example, a:b:c. This does not mean that the representation of locators in packets or in databases will necessarily have something equivalent to the colons.
本書ではロケータはノード構造にアンダーラインを引くためにコロンを含んでいるASCIIストリングとして書かれています: 例えば、a:b:c。 これは、パケットかデータベースにおける、ロケータの表現にはコロンに何か同等なものが必ずあることを意味しません。
A given physical element of the network might help implement more than one node---for example, a router might be part of two different nodes. Though this physical element might therefore be associated with more than one locator, the nodes that this physical element implements have each only one locator.
ネットワークの与えられた物理的な原理は、1つ以上のノードを実行するのを助けるかもしれません。---例えば、ルータは2つの異なったノードの一部であるかもしれません。 したがって、この物理的な要素は1つ以上のロケータに関連しているかもしれませんが、この物理的な要素が実行するノードはそれぞれ1つのロケータしか持っていません。
The connectivity specifications of a node are identified by a tuple consisting of the node's locator and an ID number.
ノードの接続性仕様はノードのロケータとID番号から成るtupleによって特定されます。
All map information is expressed in terms of locators, and routing selections are based on locators. EIDs are *not* used in making routing decisions---see section 5.
すべての地図情報がロケータに関して言い表されます、そして、ルーティング選択はロケータに基づいています。 EIDsは*でないのがルーティングを決定にする際に使用した*です。---セクション5を見てください。
3.5 Node Attributes
3.5 ノード属性
The following are node attributes defined by Nimrod.
↓これはニムロデによって定義されたノード属性です。
3.5.1 Adjacencies
3.5.1 隣接番組
Adjacencies appear in maps as attributes of both the nodes in the adjacency. A node has two types of adjacencies associated with it: those that identify a neighboring node to which the original node can send data to; and those that identivy a neighboring node that can send data to the original node.
隣接番組は隣接番組における、両方のノードの属性として地図に載っています。 ノードには、それに関連している隣接番組の2つのタイプがあります: オリジナルのノードがデータをどれに送ることができるかに隣接しているノードを特定するもの。 そして、オリジナルのノードにデータを送ることができる隣接しているノードをidentivyするもの。
3.5.2 Internal Maps
3.5.2 内部の地図
As part of its attributes, a node can have internal maps. A router can obtain a node's internal maps---or any other of the node's attributes, for that matter---by requesting that information from a representative of that node. (A router associated with that node can be such a representative.) A node's representative can in principle reply with different internal maps to different requests---for example, because of security concerns. This implies that different routers in the network might have different internal maps for the same node.
属性の一部として、ノードは内部の地図を持つことができます。 ルータはノードの内部の地図を入手できます。---または、さらに言えば、ノードのいかなる他のも結果と考えます。---そのノードの代表からその情報を要求することによって。 (そのノードに関連しているルータはそのような代表であるかもしれません。) ノードの代表は原則として異なった内部の地図で異なった要求に関して返答できます。---例えば安全上の配慮のために。 これは、ネットワークにおける異なったルータには同じノードのための異なった内部の地図があるかもしれないのを含意します。
Castineyra, et. al. Informational [Page 11] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[11ページ]のRFC1992ニムロデ
A node is said to own those locators that have as a prefix the locator of the node. In a node that has an internal map, the locators of all nodes in this internal map are prefixed by the locator of the original node.
ノードは接頭語としてノードのロケータを持っているそれらのロケータを所有していると言われています。 内部の地図を持っているノードでは、この内部の地図のすべてのノードのロケータはオリジナルのノードのロケータによって前に置かれています。
Given a map, a more detailed map can be obtained by substituting one of the map's nodes by one of that node's internal maps. This process can be continued recursively. Nimrod defines standard internal maps that are intended to be used for specific purposes. A node's "detailed map" gives more information about the region of the network represented by the original node. Typically, it is closer to the physical realization of the network than the original node. The nodes of this map can themselves have detailed maps.
地図を考えて、そのノードの内部の地図の1つで地図のノードの1つを代入することによって、より詳細な地図を入手できます。 この過程は再帰的に持続できます。 ニムロデは特定の目的で使用されることを意図する標準の内部の地図を定義します。 ノードの「精密な地図」はオリジナルのノードによって代表されたネットワークの領域に関する詳しい情報を与えます。 通常、それはネットワークの物理的な実現のオリジナルのノードより近くにあります。 この地図缶のノード自体には、精密な地図があります。
3.5.3 Transit Connectivity
3.5.3 トランジットの接続性
For a given node, this attribute specifies the services available between nodes adjacent to the given node. This attribute is requested and used when a router intends to route traffic *through* a node. Conceptually, the traffic connectivity attribute is a matrix that is indexed by a pair of locators: the locators of adjacent nodes. The entry indexed by such a pair contains the connectivity specifications of the services available across the given node for traffic entering from the first node and exiting to the second node.
与えられたノードとして、この属性はノードの間で与えられたノードに隣接して利用可能なサービスを指定します。 ルータがルート交通*から*にノードを意図すると、この属性は、要求されていて、使用されます。 概念的に、交通接続性属性は1組のロケータによって索引をつけられるマトリクスです: 隣接しているノードのロケータ。 そのような組によって索引をつけられたエントリーは最初のノードから入って、2番目のノードに出る交通のための与えられたノードの向こう側に利用可能にサービスの接続性仕様を含んでいます。
The actual format of this attribute need not be a matrix. This document does not specify the format for this attribute.
この属性の実際の形式はマトリクスである必要はありません。 このドキュメントはこの属性に形式を指定しません。
3.5.4 Inbound Connectivity
3.5.4 本国行きの接続性
For a given node, this attribute represents connectivity from adjacent nodes to points within the given node. This attribute is requested and used when a router intends to route traffic to a point within the node but does not have, and either cannot or does not want to obtain, a detailed map of the node. The inbound connectivity attribute identifies what connectivity specifications are available between pairs of locators. The first element of the pair is the locator of an adjacent node; the second is a locator owned by the given node.
与えられたノードに関しては、この属性は与えられたノードの中に隣接しているノードからポイントまで接続性を表します。 または、この属性を要求して、ルータがそうするつもりであるなら使用されて、ノードの中で指しますが、aへの交通が持っていないルート、およびどちらかが要求できない、得たくない、ノードの精密な地図。 本国行きの接続性属性は、どんな接続性仕様が組のロケータの間で利用可能であるかを特定します。 組の最初の要素は隣接しているノードのロケータです。 2番目は与えられたノードによって所有されていたロケータです。
3.5.5 Outbound Connectivity
3.5.5 外国行きの接続性
For a given node, this attribute represents connectivity from points within the given node to adjacent nodes. This attribute identifies what connectivity specifications are available between pairs of locators. The first element of the pair is a locator owned by the given node, the second is the locator of an adjacent node.
与えられたノードに関しては、この属性は与えられたノードの中のポイントから隣接しているノードまで接続性を表します。 この属性は、どんな接続性仕様が組のロケータの間で利用可能であるかを特定します。 組の最初の要素が与えられたノードによって所有されていたロケータである、2番目は隣接しているノードのロケータです。
Castineyra, et. al. Informational [Page 12] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[12ページ]のRFC1992ニムロデ
The Transit, Inbound and Outbound connectivity attributes together wiht a list of adjacencies form the "abstract map."
Transit、Inbound、および一緒にOutbound接続性属性は隣接番組形式のリストをwihtします。「抽象的な地図。」
4. Physical Realization
4. 物理的な実現
A network is modeled as being composed of physical elements: routers, hosts, and communication links. The links can be either point-to- point---e.g., T1 links---or multi-point---e.g., ethernets, X.25 networks, IP-only networks, etc.
ネットワークは物理的な要素で構成されるとしてモデル化されます: ルータ、ホスト、および通信リンク。 リンクは、ポイントからポイントであるかもしれません。---例えば、T1リンク---または、マルチポイント---例えば、イーサネット、X.25ネットワーク、IPだけネットワークなど
The physical representation of a network can have associated with it one or more Nimrod maps. A Nimrod map is a function not only of the physical network, but also of the configured clustering of elements (locator assignment) and of the configured connectivity.
ネットワークの具現は1つ以上のニムロデ地図をそれに関連づけたはずです。 ニムロデ地図は物理ネットワークだけではなく、要素(ロケータ課題)の構成されたクラスタリングと構成されたまた接続性について関数です。
Nimrod has no pre-defined "lowest level": for example, it is possible
to define and advertise a map that is physically realized inside a
CPU. In this map, a node could represent, for example, a process or a
group of processes. The user of this map need not necessarily know
or care. ("It is turtles all the way down!", in [3] page 63.)
ニムロデには、事前に定義された「最も低いレベル」が全くありません: 例えば、CPUの中に物理的に実現される地図の定義して、広告を出すのは可能です。 この地図では、ノードは例えば過程の過程かグループを代表するかもしれません。 この地図のユーザは、必ず知る必要はありませんし、また気にかける必要はありません。 ([3] 63ページの「それはいっぱいに下に亀です!」)
4.1 Contiguity
4.1 接触
Locators sharing a prefix must be assigned to a contiguous region of a map. That is, two nodes in a map that have been assigned locators sharing a prefix should be connected to each other via nodes that themselves have been assigned locators with that prefix. The main consequence of this requirement is that "you cannot take your locator with you."
接頭語を共有するロケータを地図の隣接の領域に割り当てなければなりません。 すなわち、地図の接頭語を共有するロケータが割り当てられた2つのノードがロケータがその接頭語で自分たちで割り当てられたノードで互いに接続されるべきです。 この要件の主な結果は「あなたはあなたと共にロケータを連れて行くことができない」ということです。
As an example of this, see figure 1, consider two providers x.net and y.net (these designations are *not* locators but DNS names) which appear in a Nimrod map as two nodes with locators A and B. Assume that corporation z.com (also a DNS name) was originally connected to x.net. Locators corresponding to elements in z.com are, in this example, A-prefixed. Corporation z.com decides to change providers- --severing its physical connection to x.net. The connectivity requirement described in this section implies that, after the provider change has taken place, elements in z.com will have been, in this example, assigned B-prefixed locators and that it is not possible for them to receive data destined to A-prefixed locators through y.net.
この例を、1図を参照してください、そして、2つのプロバイダーがロケータAとB.Assumeとの2つのノードとしてニムロデ地図に会社z.com(DNS名も)が元々x.ネットに接続されたのを現れさせるx.ネットとy.ネット(これらの名称は*ロケータではなく、DNSが命名する*である)であると考えてください。 この例では、z.comの要素に対応するロケータはAによって前に置かれています。 x.ネットに物理接続を断ち切って、社z.のcomは、プロバイダーを変えると決めます。 このセクションで説明された接続性要件はプロバイダー変化が起こった後にBで前に置かれたロケータがこの例でz.comの要素に割り当てられてしまうだろうといって、彼らがy.ネットを通してAで前に置かれたロケータに運命づけられたデータを受け取るのが、可能でないことを含意します。
Castineyra, et. al. Informational [Page 13] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[13ページ]のRFC1992ニムロデ
A B
+------+ +------+
| x.net| | y.net|
+------+ /+------+
/
+-----+
|z.com|
+-----+
B+------+ +------+ | x. ネット| | y. ネット| +------+ /+------+ / +-----+ |z. com| +-----+
Figure 1: Connectivity after switching providers
図1: プロバイダーを切り換えた後の接続性
The contiguity requirement simplifies routing information exchange: if it were permitted for z.com to receive A-prefixed locators through y.net, it would be necessary that a map that contains node B include information about the existence of a group of A-prefixed locators inside node B. Similarly, a map including node A would have to include information that the set of A-prefixed locators asigned to z.com is not to be found within A. The more situations like this happen, the more the hierarchical nature of Nimrod is subverted to "flat routing." The contiguity requirement can also be expressed as "EIDs are stable; locators are ephemeral."
接触要件はルーティング情報交換を簡素化します: それがz.comがy.ネットを通してAで前に置かれたロケータを受けることが許可されるなら、ノードBを含む地図がノードB.Similarlyの中にAで前に置かれたロケータのグループの存在の情報を含んでいるのが必要でしょうに、ノードAを含んでいるとz.comにasignedされたAで前に置かれたロケータのセットがA.の中で見つけられないように、このような、より多くの状況が起これば起こるほど、ニムロデの階層的な自然がさらに「平坦なルーティング」に打倒されるということであるという情報を含むように持たれている地図。 また、「EIDsは安定している」とき、接触要件を言い表すことができます。 「ロケータははかないです。」
4.2 An Example
4.2 例
Figure 2 shows a physical network. Hosts are drawn as squares, routers as diamonds, and communication links as lines. The network shown has the following components: five ethernets ---EA through EE; five routers---RA through RE; and four hosts---HA through HD. Routers RA, RB, and RC interconnect the backbone ethernets---EB, EC and ED. Router RD connects backbone EC to a network consisting of ethernet EA and hosts HA and HB. Router RE interconnects backbone ED to a network consisting of ethernet EE and hosts HC and HD. The assigned locators appear in lower case beside the corresponding physical entity.
図2は物理ネットワークを示しています。 ホストは正方形、ダイヤモンドとしてのルータ、および線としての通信リンクとして描かれます。 見せられたネットワークは以下のコンポーネントを持っています: 5つのイーサネット---EAからEE。 5つのルータ---reを通したRA。 そして、4人のホスト---HDを通してハ。 ルータのRA、RB、およびRCは背骨イーサネットとインタコネクトします。---EB、EC、および教育。 ルータRDはイーサネットEAから成るネットワークに背骨ECを接続して、HAと中の硬さを接待します。 ルータREはホストのイーサネットEE、HC、およびHDから成るネットワークと背骨EDとインタコネクトします。 対応する物理的実体の横で割り当てられたロケータは小文字に現れます。
Figure 3 shows a Nimrod map for that network. The nodes of the map are represented as squares. Lines connecting nodes represent two adjacencies in opposite directions. Different regions of the network are represented at different detail. Backbone b1 is represented as a single node. The region of the network with locators prefixed by "a" is represented as a single node. The region of the network with locators prefixed by "c" is represented in full detail.
図3はそのネットワークのためにニムロデ地図を示しています。 地図のノードは正方形として表されます。 ノードを接続する線がそれぞれ反対の方向に2つの隣接番組を表します。 ネットワークの異なった領域は異なった詳細で表されます。 背骨b1はただ一つのノードとして表されます。 ロケータが“a"によって前に置かれているネットワークの領域はただ一つのノードとして表されます。 ロケータが「c」によって前に置かれているネットワークの領域は一部始終で表されます。
Castineyra, et. al. Informational [Page 14] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[14ページ]のRFC1992ニムロデ
4.3 Multiple Locator Assignment
4.3 複数のロケータ課題
Physical elements can form part of, or implement, more than one node. In this sense it can be said that they can be assigned more than one locator. Consider figure 4, which shows a physical network. This network is composed of routers (RA, RB, RC, and RD), hosts (HA, HB, and HC), and communication links. Routers RA, RB, and RC are connected with point-to-point links. The two horizontal lines in the bottom of the figure represent ethernets. The figure also shows the locators assigned to hosts and routers.
物理的な要素缶のフォームは、ノードを離れているか、または1より実行します。 この意味で、1つ以上のロケータをそれらに割り当てることができると言うことができます。 4図を考えてください。(図は物理ネットワークを示しています)。 このネットワークはルータ(RA、RB、RC、およびRD)、ホスト(HA、中の硬さ、およびHC)、および通信リンクで構成されます。 ルータのRA、RB、およびRCはポイントツーポイント接続に接続されます。 図の下部の2個の水平な線がイーサネットを表します。 また、図はホストとルータに割り当てられたロケータを示しています。
In figure 4, RA and RB have each been assigned one locator (a:t:r1 and b:t:r1, respectively). RC has been assigned locators a:y:r1 and b:d:r1; one of these two locators shares a prefix with RA's locator, the other shares a prefix with RB's locator. Hosts HA and HB have each been assigned three locators. Host HC has been assigned one locator. Depending on what communication paths have been set up between points, different Nimrod maps result. A possible Nimrod map for this network is given in figure 5.
中では、あるロケータ(それぞれa:t:r1とb:t:r1)がそれぞれ図の4、RA、およびRBに割り当てられました。 ロケータのa:y:r1とb:d:r1はRCに割り当てられました。 これらの2つのロケータの1つはRAのロケータと接頭語を共有して、もう片方がRBのロケータと接頭語を共有します。 3つのロケータがそれぞれホストHAと中の硬さに割り当てられました。 1つのロケータがホストHCに割り当てられました。 異なったニムロデ地図は結果として生じて、どんな通信路がポイントの間でセットアップされたかによります。 このネットワークに、可能なニムロデ地図は考えて、5が中で計算するということです。
Castineyra, et. al. Informational [Page 15] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[15ページ]のRFC1992ニムロデ
a:h1 +--+ a:h2 +--+
|HA| |HB|
| | | |
+--+ +--+
a:e1 | |
--------------------- EA
|
/\ /\
/RB\ b1:r1 /RD\ b2:r1
/\ /\ \ /
/ \/ \ \/
EB b1:t:e1 / \ | EC
------------------------ -------------------------- b2:e1
/ \
/ \
/\ \
/RA\ b1:r2 \/\
\ / /RC\ b2:t:r2
\/ \ /
\ \/
\ / ED
----------------------------------- b3:t:e1
|
|
|
/\
/RE\ b3:t:r1
\ /
EE \/
----------------------------- c:e1
| |
+--+ +--+
|HC| c:h1 |HD| c:h2
| | | |
+--+ +--+
a: h1+--+ a: h2+--+|ハ| |中の硬さ| | | | | +--+ +--+ a: e1| | --------------------- EA| /\/\/RB\b1: r1 /RD\b2: r1/\/\\//\/\\/EB b1:t:e1/\| EC------------------------ -------------------------- b2: e1/\/\/\\/RA\b1: r2\/\\//RC\b2:t:r2\/\/\\/\/ED----------------------------------- b3:t:e1| | | /\/RE\b3: t: r1\/EE\/----------------------------- c: e1| | +--+ +--+ |HC| c: h1|HD| c: h2| | | | +--+ +--+
Figure 2: Example Physical Network
図2: 例の物理ネットワーク
Castineyra, et. al. Informational [Page 16] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[16ページ]のRFC1992ニムロデ
+-----+ +-----+
+----------+ | | | |
| |--------------| b2 | --------------| a |
| | | | | |
| b1 | +-----+ +-----+
| | |
| | |
| | |
+----------+ |
\ |
\ |
\ |
\ |
\ +--------+
\ | |
------- | b3:t:e1|
| |
+--------+
|
|
|
|
+-------+
| |
|b3:t:r1|
| |
+-------+
|
+-----+ +-----+ +-----+
| | | | | |
| c:h1|-------| c:e1|-----| c:h2|
| | | | | |
+-----+ +-----+ +-----+
+-----+ +-----+ +----------+ | | | | | |--------------| b2| --------------| a| | | | | | | | b1| +-----+ +-----+ | | | | | | | | | +----------+ | \ | \ | \ | \ | \ +--------+ \ | | ------- | b3:t:e1| | | +--------+ | | | | +-------+ | | |b3:t:r1| | | +-------+ | +-----+ +-----+ +-----+ | | | | | | | c: h1|-------| c: e1|-----| c: h2| | | | | | | +-----+ +-----+ +-----+
Figure 3: Nimrod Map
図3: ニムロデMap
Castineyra, et. al. Informational [Page 17] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[17ページ]のRFC1992ニムロデ
a:t:r1 b:t:r1
+--+ +--+
|RA|------------|RB|
+--+ +--+
\ /
\ /
\ /
\ /
\ /
\ /
\ /
\
+--+
|RC| a:y:r1
+--+ b:d:r1
|
---------------------------
| | |
a:y:h1 +--+ +--+ +--+ a:y:h2
b:d:h2 |HA| |RD| c:r1 |HB| b:d:h1
c:h1 +--+ +--+ +--+ c:h2
|
|
--------------------
|
+--+
|HC| c:h3
+--+
a:t:r1b:t:r1+--+ +--+|RA|------------|RB| +--+ +--+ \ / \ / \ / \ / \ / \ / \ / \ +--+ |RC| a:y:r1+--+ b:d:r1| --------------------------- | | | a:y:h1+--+ +--+ +--+ a:y:h2b:d:h2|ハ| |rd| c: r1|中の硬さ| b:d:h1c: h1+--+ +--+ +--+ c: h2| | -------------------- | +--+ |HC| c: h3+--+
Figure 4: Multiple Locators
図4: 複数のロケータ
Castineyra, et. al. Informational [Page 18] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[18ページ]のRFC1992ニムロデ
a b c
+-------------+ +-------------+ +---------------+
| | | | | |
| a:t | | b:t | | |
| +--+ | | +--+ | | |
| | |--------------|--| | | | |
| +--+ | | +--+ | | |
| | | | | | | |
| +--+ | | +--+ | | |
| + + | | + + | | |
| +--+ a:y | | +--+ b:d | | |
| | | | | |
+-------------+ +-------------+ +---------------+
b c+-------------+ +-------------+ +---------------+ | | | | | | | a: t| | b: t| | | | +--+ | | +--+ | | | | | |--------------|--| | | | | | +--+ | | +--+ | | | | | | | | | | | | +--+ | | +--+ | | | | + + | | + + | | | | +--+ a: y| | +--+ b: d| | | | | | | | | +-------------+ +-------------+ +---------------+
Figure 5: Nimrod Map
図5: ニムロデMap
Nodes and adjacencies represent the *configured* clustering and connectivity of the network. Notice that even though a:y and b:d are defined on the same hardware, the map shows no connection between them: this connection has not been configured. A packet given to node `a' addressed to a locator prefixed with "b:d" would have to travel from node a to node b via the arc joining them before being directed towards its destination. Similarly, the map shows no connection between the c node and the other two top level nodes. If desired, these connections could be established, which would necessitate setting up the exchange of routing information. Figure 6 shows the map when these connections have been established.
ノードと隣接番組はネットワークの*構成された*クラスタリングと接続性を表します。 a: yとb: dが同じハードウェアで定義されますが、地図がそれらの間の接続を全く示さないのに注意してください: この接続は構成されていません。 「b: d」で前に置かれたロケータに記述されたノード'a'に与えられたパケットは、目的地に向けられる前にそれらを接合しながら、aをノードからノードbにアークで旅行しなければならないでしょう。 同様に、地図はcノードと他の2先端とのどんな関係にも平らなノードを示していません。 望まれているなら、これらの接続(ルーティング情報の交換をセットアップするのを必要とする)は確立されるかもしれません。 図6は、これらの接続がいつ確立されたかを地図に示します。
In the strict sense, Nimrod nodes do not overlap: they are distinct entities. But, as we have seen in the previous example, a physical element can be given more than one locator, and, in that sense, participate in implementing more than one node. That is, two different nodes might be defined on the same hardware. In this sense, Nimrod nodes can be said to overlap. But to notice this overlap one would have to know the physical-to-map correspondence. It is not possible to know when two nodes share physical assets by looking only at a Nimrod map.
厳密な意味で、ニムロデノードは重なりません: それらは別個の物です。 しかし、周知のごとく前の例では、物理的な要素は、1つ以上のロケータを与えて、その意味で、1つ以上のノードを実行するのに関与できます。 すなわち、2つの異なったノードが同じハードウェアで定義されるかもしれません。 この意味で、重なるとニムロデノードを言うことができます。 しかし、このオーバラップ1に気付くのは写像するために物理的な通信を知らなければならないでしょう。 2つのノードがいつ単にニムロデ地図を見ることによって物的資産を分担するかを知るのは可能ではありません。
Castineyra, et. al. Informational [Page 19] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[19ページ]のRFC1992ニムロデ
5. Forwarding
5. 推進
Nimrod supports four forwarding modes:
ニムロデは4つの推進モードを支持します:
1. Connectivity Specification Chain (CSC) mode: In this mode, packets
carry a list of connectivity specifications. The packet is
required to go through the nodes that own the connectivity
specifications using the services specified. The nodes associated
with the listed connectivity specifications should define a
continuous path in the map. A more detailed description of the
requirements of this mode is given in section 5.3.
1. 接続性Specification Chain(CSC)モード: このモードで、パケットは接続性仕様のリストを運びます。 パケットは指定されたサービスを利用することで接続性仕様を所有しているノードを調べなければなりません。 記載された接続性仕様に関連しているノードは地図で連続した経路を定義するはずです。 セクション5.3でこのモードの要件の、より詳細な記述を与えます。
Castineyra, et. al. Informational [Page 20] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[20ページ]のRFC1992ニムロデ
+--------+ +--------+
| | | |
| a:t:r1 |-----------------------------------------------| b:t:r1 |
| | | |
+--------+ +--------+
| |
| |
| /-----------------------------------------\ |
| | | |
| | | |
| +--------+ +--------+ +--------+ |
| | | | | | | |
| | a:y:h1 --------| c:h1 |--------------------| b:d:h1 | |
| | | | | | | |
| +--------+ +--------+ +--------+ |
| | | | | | | |
+--------+ | | +------+ +------+ | +--------+
| | | | | | | | | | |
| a:y:r1 | | | | c:r1 |--| c:h3 | | | b:d:r1 |
| | | | | | | | | | |
+--------+ | | +------+ +------+ | +--------+
| | | | | | | |
| +--------+ +--------+ +--------+ |
| | | | | | | |
| | a:y:h2 |-------- c:h2 |--------------------| b:d:h2 | |
| | | | | | | |
| +--------+ +--------+ +--------+ |
| | | |
| | | |
| | | |
| \-----------------------------------------/ |
\-------------------------------------------------------------/
+--------+ +--------+ | | | | | a:t:r1|-----------------------------------------------| b:t:r1| | | | | +--------+ +--------+ | | | | | /-----------------------------------------\ | | | | | | | | | | +--------+ +--------+ +--------+ | | | | | | | | | | | a:y:h1--------| c: h1|--------------------| b:d:h1| | | | | | | | | | | +--------+ +--------+ +--------+ | | | | | | | | | +--------+ | | +------+ +------+ | +--------+ | | | | | | | | | | | | a:y:r1| | | | c: r1|--| c: h3| | | b:d:r1| | | | | | | | | | | | +--------+ | | +------+ +------+ | +--------+ | | | | | | | | | +--------+ +--------+ +--------+ | | | | | | | | | | | a:y:h2|-------- c: h2|--------------------| b:d:h2| | | | | | | | | | | +--------+ +--------+ +--------+ | | | | | | | | | | | | | | \-----------------------------------------/ | \-------------------------------------------------------------/
Figure 6: Nimrod Map II
図6: ニムロデMap II
2. Connectivity Specifications Sequence (CSS) mode: In this mode,
packets carry a list of connectivity specifications. The packet
is supposed to go sequentially through the nodes that own each one
of the listed connectivity specifications in the order they were
specified. The nodes need not be adjacent. This mode can be seen
as a generalization of the CSC mode. Notice that CSCs are said to
be a *chains* of locators, CSSs are *sequences* of locators. This
difference emphasizes the contiguity requirement in CSCs. A
detailed description of this mode is in section 5.6.
2. 接続性Specifications Sequence(CSS)モード: このモードで、パケットは接続性仕様のリストを運びます。 パケットによるオーダーにおける記載された接続性仕様のそれぞれを所有しているノードを連続して調べると思われて、それらが指定されたということです。 ノードは隣接している必要はありません。 このモードをCSCモードの一般化と考えることができます。 CSCsが*がロケータの*をチェーニングして、CSSsがロケータの*系列*であるということであると言われているのに注意してください。 この違いはCSCsで接触要件を強調します。 このモードの詳述がセクション5.6にあります。
Castineyra, et. al. Informational [Page 21] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[21ページ]のRFC1992ニムロデ
3. Flow mode: In this mode, the packet includes a path-id that
indexes state that has been previously set up in routers along the
path. Packet forwarding when flow state has been established is
relatively simple: follow the instructions in the routers' state.
Nimrod includes a mechanism for setting up this state. A more
detailed description of this mode can be found in section 5.4.
3. 流れモード: このモードでは、パケットは以前に経路に沿ったルータで設立された状態に索引をつける経路イドを含んでいます。 流れ状態を設置してあるとき、パケット推進は比較的簡単です: ルータの状態で指示に従ってください。 ニムロデはこの状態を設立するためのメカニズムを入れます。 セクション5.4でこのモードの、より詳細な記述を見つけることができます。
4. Datagram mode: in this mode, every packet carries source and
destination locators. This mode can be seen as a special case of
the CSS mode. Forwarding is done following procedures as
indicated in section 5.5.
4. データグラムモード: このモードで、あらゆるパケットがソースと目的地ロケータを運びます。 特殊なものとしてCSSモードについてこのモードを見ることができます。 推進はセクション5.5にみられるように手順に従い終わっています。
BEGIN COMMENT
コメントを始めてください。
The obvious parallels are between CSC mode and IPV4's strict
source route and between CSS mode and IPV4's loose source route.
CSCモードとIPV4の厳しい送信元経路の間と、そして、CSSモードとIPV4のゆるい送信元経路の間には、明白な類似があります。
END COMMENT
終わりのコメント
In all of these modes, the packet may also carry locators and EIDs for the source and destinations. In normal operation, forwarding does not take the EIDs into account, only the receiver does. EIDs may be carried for demultiplexing at the receiver, and to detect certain error conditions. For example, if the EID is unknown at the receiver, the locator and EID of the source included in the packet could be used to generate an error message to return to the source (as usual, this error message itself should probably not be allowed to be the cause of other error messages). Forwarding can also use the source locator and EID to respond to error conditions, for example, to indicate to the source that the state for a path-id cannot be found.
また、これらのモードで、全部で、パケットはソースと目的地までロケータとEIDsを運ぶかもしれません。 通常の操作では、推進はEIDsを考慮に入れないで、受信機だけはそうします。 EIDsは、受信機の逆多重化、あるエラー条件を検出するために運ばれるかもしれません。 ソースに戻るためにエラーメッセージを発生させるのに例えば、EIDが受信機で未知であるならパケットにソースのロケータとEIDを含んでいるのを使用できました(いつものように、たぶん他のエラーメッセージの原因であることをこのエラーメッセージ自体を許容するべきではありません)。 また、推進は、例えば、経路イドのための状態を見つけることができないのをソースまで示すためにエラー条件に応じるのにソースロケータとEIDを使用できます。
Packets can be visualized as moving between nodes in a map. A packet indicates, implicitly or explicitly, a destination locator. In a packet that uses the datagram, CSC, or CSS forwarding mode, the destination locator is explicitly indicated . In a packet that uses the flow forwarding mode, the destination locator is implied by the path-id and the distributed state in the network (it might also be included explicitly). Given a map, a packet moves to the node in this map to which the associated destination locator belongs. If the destination node has a "detailed" internal map, the destination locator must belong to one of the nodes in this internal map (otherwise it is an error). The packet goes to this node (and so on, recursively).
地図のノードの間を動くとパケットを想像できます。 パケットはそれとなくか明らかに目的地ロケータを示します。 モードを進めながらデータグラム、CSC、またはCSSを使用するパケットでは、目的地ロケータは明らかに示されます。モードを進めながら流れを使用するパケットでは、目的地ロケータはネットワークで経路イドと分散州によって含意されます(また、それは明らかに含まれるかもしれません)。 地図を考えて、パケットは関連目的地ロケータが属するこの地図のノードに動きます。 目的地ノードに内部の「詳細な」地図があるなら、目的地ロケータはこの内部の地図でノードの1つに属さなければなりません(さもなければ、それは誤りです)。 パケットはこのノード(などと、再帰的である)に達します。
Castineyra, et. al. Informational [Page 22] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[22ページ]のRFC1992ニムロデ
5.1 Policy
5.1方針
CSC and CSS mode implement policy by specifying the connectivity specifications associated with those nodes that the packet should traverse. Strictly speaking, there is no policy information included in the packet. That is, in principle, it is not possible to determine what criteria were used to select the route by looking at the packet. The packet only contains the results of the route generation process. Similarly, in a flow mode packet, policy is implicit in the chosen route.
CSCとCSSモードは、パケットが横断するはずであるそれらのノードに関連している接続性仕様を指定することによって、政策を実施します。 厳密に言うと、パケットに情報を含んでいて、方針が全くありません。 すなわち、原則として、どんな評価基準がパケットを見ることによってルートを選択するのに使用されたかを決定するのは可能ではありません。 パケットはルート発生経過の結果を含むだけです。 同様に、方針は選ばれたルートで流れモードパケットでは、暗に示されています。
A datagram-mode packet can indicate a limited form of policy routing by the choice of destination and source locators. For this choice to exist, the source or destination endpoints must have several locators associated with them. This type of policy routing is capable of, for example, choosing providers.
データグラムモードパケットは目的地とソースロケータの選択で限局型の方針ルーティングを示すことができます。 この選択が存在するように、ソースか目的地終点にはそれらに関連しているいくつかのロケータがなければなりません。 例えば、このタイプの方針ルーティングはプロバイダーを選ぶことができます。
5.2 Trust
5.2 信用
A node that chooses not to divulge its internal map can work internally any way its administrators decide, as long as the node satisfies its external characterization as given in its Nimrod map advertisements. Therefore, the advertised Nimrod map should be consistent with a node's actual capabilities. For example, consider the network shown in figure 7 which shows a physical network and the advertised Nimrod map. The physical network consists of hosts and a router connected together by an ethernet. This node can be sub- divided into component nodes by assigning locators as shown in the figure and advertising the map shown. The map seems to imply that it is possible to send packets to node a:x without these being observable by node a:y; however, this is actually not enforceable.
内部の地図を明かさないのを選ぶノードは管理者が決めるどんな方法でも内部的に動くことができます、ノードがニムロデ地図広告で与えるように外部の特殊化を満たす限り。 したがって、広告を出しているニムロデ地図はノードの実際の能力と一致しているべきです。 例えば、ショーの物理ネットワークと広告を出しているニムロデが写像する7が中で計算するのが示されたネットワークを考えてください。 物理ネットワークはイーサネットによって一緒に接されたホストとルータから成ります。 図に示されて、見せられた地図の広告を出すとしてロケータを割り当てることによって、このノードはサブ分割されたコンポーネントノードであるかもしれません。 地図がパケットをノードに送るのが可能であることを含意するように思える、a: ノードで観察可能なこれらの存在のないx、a: y。 しかしながら、これは実際に実施できません。
In general, it is reasonable to ask how much trust should be put in the maps obtained by a router. Even when a node is "trustworthy," and the information received from the node has been authenticated, there is always the possibility of an honest mistake.
一般に、どのくらいの信用がルータによって入手された地図に入れられるべきであるかを尋ねるのは妥当です。 ノードが「信頼でき」て、ノードから受け取られた情報が認証さえされたとき、うっかりミスの可能性がいつもあります。
Castineyra, et. al. Informational [Page 23] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[23ページ]のRFC1992ニムロデ
+--+
|RA| a:r1
+--+
|
|
|
|
-------------------------------
| |
+--+ +--+
|Ha| a:x:h1 |Ha| a:y:h2
+--+ +--+
+--+ |RA| a: r1+--+| | | | ------------------------------- | | +--+ +--+ |ハ| a:x:h1|ハ| a:y:h2+--+ +--+
Physical Network
物理ネットワーク
a |
+----------------|--------------------
| | |
| +----+ |
| |a:r1| |
| a:x +----+ a:y |
| +------+ / \ +-------+ |
| | | / \| | |
| | | | | |
| | | | | |
| +------+ +-------+ |
| |
+ -----------------------------------+
a| +----------------|-------------------- | | | | +----+ | | |a: r1| | | a: x+----+ a: y| | +------+ / \ +-------+ | | | | / \| | | | | | | | | | | | | | | | +------+ +-------+ | | | + -----------------------------------+
Advertised Nimrod Map
広告を出しているニムロデMap
Figure 7: Example of Misleading Map
図7: 紛らわしい地図に関する例
5.3 Connectivity Specification (CSC) Mode
5.3 接続性仕様(CSC)モード
Routing for a CSC packet is specified by a list of connectivity specifications carried in the packet. These are the connectivity specifications that make the specified path, in the order that they appear along the path. These connectivity specifications are attributes of nodes. The route indicated by a CSC packet is specifed in terms of connectivity specifications rather than physical entities: a connectivity specification in a CSC-mode packet would
CSCパケットのためのルート設定はパケットで運ばれた接続性仕様のリストによって指定されます。 これらはそれらが経路に沿って見えるオーダーにおける指定された経路を作る接続性仕様です。 これらの接続性仕様はノードの属性です。 CSCパケットによって示されたルートは物理的実体よりむしろ接続性仕様でspecifedされます: CSC-モードパケットの接続性仕様はそうするでしょう。
Castineyra, et. al. Informational [Page 24] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[24ページ]のRFC1992ニムロデ
correspond to a type of service between two points of the network without specifying the physical path.
物理的な経路を指定しないで、ネットワークの2ポイントの間の一種のサービスに対応してください。
Given two connectivity specifications that appear consecutively in the a CSC-mode packet, there should exist an adjacency going from the node corresponding to the first connectivity specification to the node corresponding to the second connectivity specification. The first connectivity specification referenced in a CSC-mode packet should be an outbound connectivity specification; similarly, the last connectivity specification referenced in a CSC-mode packet should be an inbound connectivity specification; the rest should be transit connectivity specifications.
a CSC-モードパケットに連続して現れる2つの接続性仕様を考えて、最初の接続性仕様に対応するノードから2番目の接続性仕様に対応するノードまで行く隣接番組は存在するべきです。 CSC-モードパケットで参照をつけられる最初の接続性仕様は外国行きの接続性仕様であるべきです。 同様に、CSC-モードパケットで参照をつけられる最後の接続性仕様は本国行きの接続性仕様であるべきです。 残りはトランジット接続性仕様であるべきです。
5.4 Flow Mode
5.4 流れモード
A flow mode packet includes a path-id field. This field identifies state that has been established in intermediate routers. The packet might also contain locators and EIDs for the source and destination. The setup packet also includes resource requirements. Nimrod includes protocols to set up and modify flow-related state in intermediate routers. These protocols not only identify the requested route, but also describe the resources requested by the flow---e.g., bandwidth, delay, etc. The result of a set-up attempt might be either confirmation of the set-up or notification of its failure. The source-specified routes in flow mode setup are specified in terms of CSSs.
流れモードパケットは経路イド分野を含んでいます。 この分野は中間的ルータに設置された状態を特定します。 また、パケットはソースと目的地へのロケータとEIDsを含むかもしれません。 また、セットアップパケットはリソース要件を含んでいます。 ニムロデは、中間的ルータで流れ関連の状態を設立して、変更するためにプロトコルを入れます。 これらのプロトコルは要求されたルートを特定するだけではなく、流れによって要求されたリソースについて説明もします。---例えば、帯域幅、遅れなど セットアップ試みの結果は、セットアップの確認か失敗が通知のどちらかであるかもしれません。 流れモードセットアップにおけるソースによって指定されたルートはCSSsに関して指定されます。
5.5 Datagram Mode
5.5 データグラムモード
A realistic routing architecture must include an optimization for datagram traffic, by which we mean user transactions which consist of single packets, such as a lookup in a remote translation database. Either of the two previous modes contains unacceptable overhead if much of the network traffic consists of such datagram transactions. A mechanism is needed which is approximately as efficient as the existing IPv4 "hop-by-hop" mechanism. Nimrod has such a mechanism.
現実的なルーティング構造は私たちが単一のパケットから成るユーザ取引を言っているデータグラム交通のための最適化を含まなければなりません、リモート翻訳データベースのルックアップのように。 ネットワークトラフィックの大部分がそのようなデータグラム取引から成るなら、前の2つのモードのどちらかが容認できないオーバーヘッドを含んでいます。 既存の「ホップごとのIPv4」メカニズムとほぼ同じくらい効率的なメカニズムが必要です。 ニムロデには、そのようなメカニズムがあります。
The scheme can be characterized by the way it divides the state in a
datagram network between routers and the actual packets. In IPv4,
most packets currently contain only a small amount of state
associated with the forwarding process ("forwarding state")---the hop
count. Nimrod proposes that enlarging the amount of forwarding state
in packets can produce a system with useful properties. It was
partially inspired by the efficient source routing mechanism in SIP
[5], and the locator pointer mechanism in PIP [6]).
ルータと実際のパケットの間のデータグラム・ネットワークで状態を分割する方法で計画を特徴付けることができます。 IPv4では、ほとんどのパケットが現在、推進の過程(「推進状態」)に関連している少量の状態だけを含みます。---ホップカウント。 ニムロデは、パケットの推進状態の量を拡大すると役に立つ特性があるシステムを作成できるよう提案します。 それはSIP[5]の効率的なソースルーティングメカニズム、およびPIP[6])のロケータポインタメカニズムによって部分的に奮い立たせられました。
Nimrod datagram mode uses pre-set flow-mode state to support a strictly non-looping path, but without a source-route.
厳密に非輪にしている経路を支持するのに事前に設定流れモード状態を使用しますが、ニムロデデータグラムモードは送信元経路なしでそうします。
Castineyra, et. al. Informational [Page 25] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[25ページ]のRFC1992ニムロデ
5.6 Connectivity Specification Sequence Mode
5.6 接続性仕様系列モード
The connectivity specification sequence mode specifies a route by a list of connectivity specifications. There are no contiguity restrictions on consecutive connectivity specifications.
接続性仕様系列モードは接続性仕様のリストでルートを指定します。 接触制限が全く連続した接続性仕様にありません。
BEGIN COMMENT
コメントを始めてください。
The CSS and CSC modes can be seen as combination of the datagram
and flow modes. Therefore, in a sense, the basic forwarding modes
of Nimrod are just these last two.
CSSとCSCモードをデータグラムと流れモードの組み合わせと考えることができます。 したがって、ある意味で、ニムロデの基本の推進モードはまさしくこれらが2を持続するということです。
END COMMENT
終わりのコメント
6. Security Considerations
6. セキュリティ問題
Security issues are not addressed in this document.
安全保障問題は本書では記述されません。
7. References
7. 参照
[1] Steenstrup, M., "Inter-Domain Policy Routing Protocol
Specification: Version 1," RFC 1479, June 1993.
[1] ステーンストルプ、M.、「相互ドメイン方針ルート設定は仕様を議定書の中で述べます」。 「バージョン1」、RFC1479、1993年6月。
[2] Steenstrup M., and R. Ramanathan, "Nimrod Functionality and
Protocols Specification," Work in Progress, February 1996.
[2] ステーンストルプM.、R.Ramanathan、および「ニムロデFunctionalityとプロトコル仕様」は進歩、1996年2月に働いています。
[3] Wright, R., "Three Scientists and their Gods Looking for Meaning
in an Age of Information", New York: Times Book, first ed., 1988.
[3] R.と、「情報のAgeのMeaningのための3Scientistsと彼らの神Looking」という職人ニューヨーク、: 回のBook、最初に、教育、1988
[4] Deering, S., "SIP: Simple Internet Protocol," IEEE Network, vol.
7, May 1993.
[4] デアリング、S.は「以下をちびちび飲みます」。 「簡単なインターネットプロトコル」、IEEE Network、vol.7、1993年5月。
[5] Francis, P., "A Near-Term Architecture for Deploying Pip," IEEE
Network, vol. 7, May 1993.
[5] フランシス、P.、「種を配備するための短期間構造」、IEEE Network、vol.7、1993年5月。
Castineyra, et. al. Informational [Page 26] RFC 1992 Nimrod Routing Architecture August 1996
et Castineyra、アル。 構造1996年8月に掘る情報[26ページ]のRFC1992ニムロデ
8. Authors' Addresses
8. 作者のアドレス
Isidro Castineyra BBN Systems and Technologies 10 Moulton Street Cambridge, MA 02138
イシドロCastineyra BBNシステムと技術10モールトン・通りケンブリッジ、MA 02138
Phone: (617) 873-6233 EMail: isidro@bbn.com
以下に電話をしてください。 (617) 873-6233 メールしてください: isidro@bbn.com
Noel Chiappa EMail: gnc@ginger.lcs.mit.edu
クリスマスChiappaはメールします: gnc@ginger.lcs.mit.edu
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
Castineyra, et. al. Informational [Page 27]
et Castineyra、アル。 情報[27ページ]
一覧
スポンサーリンク
