RFC1753 日本語訳
1753 IPng Technical Requirements Of the Nimrod Routing and AddressingArchitecture. N. Chiappa. December 1994. (Format: TXT=46586 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group N. Chiappa Request for Comments: 1753 December 1994 Category: Informational
Chiappaがコメントのために要求するワーキンググループN.をネットワークでつないでください: 1753 1994年12月のカテゴリ: 情報
IPng Technical Requirements
Of the Nimrod Routing and Addressing Architecture
ニムロデRoutingとアドレッシング体系に関するIPng技術的要求事項
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
要約
This document was submitted to the IETF IPng area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list.
RFC1550に対応してIETF IPng領域にこのドキュメントを提出しました。 このドキュメントの公表はどんな考えのIPng領域のそばでも中で言い表された状態で承認を含意しません。 big-internet@munnari.oz.au メーリングリストにコメントを提出するべきです。
This document presents the requirements that the Nimrod routing and addressing architecture has upon the internetwork layer protocol. To be most useful to Nimrod, any protocol selected as the IPng should satisfy these requirements. Also presented is some background information, consisting of i) information about architectural and design principles which might apply to the design of a new internetworking layer, and ii) some details of the logic and reasoning behind particular requirements.
このドキュメントはニムロデルーティングとアドレッシング体系がインターネットワーク層のプロトコルに持っている要件を提示します。 ニムロデの最も役に立つように、IPngとして選定されるどんなプロトコルもこれらの要件を満たすべきです。 また、提示されているのは、何らかの基礎的な情報です、特定の要件の後ろで新しいインターネットワーキング層、およびii)のデザインに論理と推理のいくつかの詳細を適用するかもしれない建築するのと設計原則のi)情報から成って。
1. Introduction
1. 序論
It is important to note that this document is not "IPng Requirements for Routing", as other proposed routing and addressing designs may need different support; this document is specific to Nimrod, and doesn't claim to speak for other efforts.
このドキュメントが「ルート設定のためのIPng要件」でないと述べるのは重要です、他の提案されたルーティングとデザインを記述すると異なったサポートが必要とするとき。 このドキュメントは、ニムロデにとって特定であり、他の努力を代弁すると主張しません。
However, although I don't wish to assume that the particular designs being worked on by the Nimrod WG will be widely adopted by the Internet (if for no other reason, they have not yet been deployed and tried and tested in practise, to see if they really work, an absolutely necessary hurdle for any protocol), there are reasons to believe that any routing architecture for a large, ubiquitous global Internet will have many of the same basic fundamental principles as the Nimrod architecture, and the requirements that these generate.
しかしながら; ニムロデWGが働かせる特定のデザインがインターネットによって広く採用されると仮定したいと思いませんが(他の理由がないためにまだそれらを配備されて、試みていなくて、テストされて、練習してください、そして、見るために、本当に、仕事、いずれかのための絶対に必要なハードルはそれらであるなら議定書を作ります); ニムロデ構造、およびこれらが発生させる要件として大きくて、遍在している世界的なインターネットへのどんなルーティング構造にも同じ基本的な原理の多くがあると信じる理由があります。
Chiappa [Page 1] RFC 1753 Nimrod Technical Requirements for IPng December 1994
IPng1994年12月のためのChiappa[1ページ]RFC1753ニムロデ技術的要求事項
While current day routing technologies do not yet have the characteristics and capabilities that generate these requirements, they also do not seem to be completely suited to routing in the next-generation Internet. As routing technology moves towards what is needed for the next generation Internet, the underlying fundamental laws and principles of routing will almost inevitably drive the design, and hence the requirements, toward things which look like the material presented here.
現在の日のルーティング技術には、これらの要件を発生させる特性と能力がまだありませんが、また、それらは、次世代インターネットでルーティングに完全に合うように思えません。 ルーティング技術が次世代インターネットに必要であるものに近づくのに従って、ルーティングの基本的な基本法則と原則は、ほぼ必然的にデザインを追い立てて、したがって、要件を追い立てるでしょう、ここで寄贈された材料に似ているものに向かって。
Therefore, even if Nimrod is not the routing architecture of the next-generation Internet, the basic routing architecture of that Internet will have requirements that, while differing in detail, will almost inevitably be similar to these.
したがって、ニムロデが次世代インターネットのルーティング構造でなくても、そのインターネットの基本的なルーティング構造には詳細に異なっている間にほぼ必然的にこれらと同様になる要件があるでしょう。
In a similar, but more general, context, note that, by and large, the
general analysis of sections 3.1 ("Interaction Architectural Issues")
and 3.2 ("State and Flows in the Internetwork Layer") will apply to
other areas of a new internetwork layer, not just routing.
同様の、しかし、より一般的な文脈では、概して、セクション3.1(「相互作用構造的な問題」)と3.2(「インターネットワーク層の中を述べて、流れる」)の一般的解析がルーティングだけではなく、新しいインターネットワーク層の他の領域に適用されることに注意してください。
I will tackle the internetwork packet format first (which is simpler), and then the whole issue of the interaction with the rest of the internetwork layer (which is a much more subtle topic).
私は最初に(より簡単である)インターネットワークパケット・フォーマットに取り組むつもりです、そして、次に、インターネットワークの残りとの相互作用の全体の問題は層にされます(はるかに微妙な話題です)。
2. Packet Format
2. パケット・フォーマット
2.1 Packet Format Issues
2.1 パケット・フォーマット問題
As a general rule, the design philosophy of Nimrod is "maximize the lifetime (and flexibility) of the architecture". Design tradeoffs (i.e., optimizations) that will adversely affect the flexibility, adaptability and lifetime of the design are not not necessarily wise choices; they may cost more than they save. Such optimizations might be the correct choices in a stand-alone system, where the replacement costs are relatively small; in the global communication network, the replacement costs are very much higher.
概して、ニムロデの設計理念は「構造の生涯(そして、柔軟性)を最大にしてください」です。 デザインの柔軟性、適応性、および生涯に悪影響を与えるデザイン見返り(すなわち、最適化)は必ず賢明な選択です。 彼らは救う以上かかるかもしれません。 そのような最適化はスタンド・アローン・システムで正しい選択であるかもしれません。(そこでは交換コストが比較的わずかです)。 グローバル通信ネットワークでは、交換コストはたいへん高いです。
Providing the Nimrod functionality requires the carrying of certain information in the packets. The design principle noted above has a number of corollaries in specifying the fields to contain that information.
ニムロデの機能性を提供するのはパケットでの、ある情報の携帯を必要とします。 上に述べられた設計原理はその情報を含むように分野を指定する際に多くの推論を持っています。
First, the design should be "simple and straightforward", which means that various functions should be handled by completely separate mechanisms, and fields in the packets. It may seem that an opportunity exists to save space by overloading two functions onto one mechanism or field, but general experience is that, over time, this attempt at optimization costs more, by restricting flexibility and adaptability.
まず最初に、デザインは「簡単で簡単であるべきである」(様々な機能が完全に別々のメカニズム、およびパケットの分野によって扱われるべきであることを意味します)。 機会が1つのメカニズムかフィールドに2つの機能を積みすぎることによって記憶空間を節約するために存在するように思えるかもしれませんが、一般的な経験は時間がたつにつれて最適化へのこの試みが以上かかります、柔軟性と適応性を制限することによってことです。
Chiappa [Page 2] RFC 1753 Nimrod Technical Requirements for IPng December 1994
IPng1994年12月のためのChiappa[2ページ]RFC1753ニムロデ技術的要求事項
Second, field lengths should be specified to be somewhat larger than can conceivably be used; the history of system architecture is replete with examples (processor address size being the most notorious) where fields became too short over the lifetime of the system. The document indicates what the smallest reasonable "adequate" lengths are, but this is more of a "critical floor" than a recommendation. A "recommended" length is also given, which is the length which corresponds to the application of this principle. The wise designer would pick this length.
2番目に、フィールド長は多分使用できるよりいくらか大きくなるように指定されるべきです。 システム構築の歴史は分野がシステムの生涯短くなり過ぎたところに例(最も悪名高いプロセッサアドレスサイズ)で充満しています。 ドキュメントが、最もわずかな妥当な「適切な」長さがどのくらいであるかを示しますが、これは推薦より「重要な床」です。 また、「お勧め」の長さ(この原則のアプリケーションに対応する長さである)を与えます。 賢明なデザイナーはこの長さを選ぶでしょう。
It is important to now that this does *not* mean that implementations must support the maximum value possible in a field of that size. I imagine that system-wide administrative limits will be placed on the maximum values which must be supported. Then, as the need arises, we can increase the administrative limit. This allows an easy, and completely interoperable (with no special mechanisms) path to upgrade the capability of the network. If the maximum supported value of a field needs to be increased from M to N, an announcement is made that this is coming; during the interim period, the system continues to operate with M, but new implementations are deployed; while this is happening, interoperation is automatic, with no transition mechanisms of any kind needed. When things are "ready" (i.e., the proportion of old equipment is small enough), use of the larger value commences.
現在に、これが実現が支持しなければならない*平均ではなく、*にそのサイズの分野で可能な最大値をするのは、重要です。 私は、システム全体の管理限界が支持しなければならない最大の値に置かれると想像します。 そして必要に応じて、私たちは管理限界を増加させることができます。 これで、簡単で、完全に共同利用できる(特別なメカニズムのない)経路はネットワークの能力をアップグレードさせることができます。 分野の最大の支持された値が、MからNに増加する必要があるなら、これが来る予定であるという発表をします。 暫時の間、システムは、Mで作動し続けていますが、新しい実現は配備されます。 これが起こっている間、どんな種類の変遷メカニズムも全く必要でない状態でinteroperationが自動です。 いろいろなことが「準備ができている」とき(すなわち、古い設備の割合は十分わずかです)、より大きい値の使用は始まります。
Also, in speaking of the packet format, you first need to distinguish between the host-router part of the path, and the router-router part; a format that works OK for one may not do for another.
また、パケット・フォーマットについて話す際に、あなたは、最初に、経路のホストルータ地域、およびルータルータ部分を見分ける必要があります。 OKに働いている形式は別のもののために個人的にはそうしないかもしれません。
The issue is complicated by the fact that Nimrod can be made to work, albeit not in optimal form, with information/fields missing from the packet in the host to "first hop router" section of the packet's path. The missing fields and information can then be added by the first hop router. (This capability will be used to allow deployment and operation with unmodified IPv4 hosts, although similar techniques could be used with other internetworking protocols.) Access to the full range of Nimrod capabilities will require upgrading of hosts to include the necessary information in the packets they exchange with the routers.
それにしても、ニムロデはどんな最適のフォームでも働かされることができないという事実によって問題が複雑にされます、ホストのパケットからパケットの経路の「最初のホップルータ」セクションまでなくなった情報/分野で。 そして、最初のホップルータはなくなった分野と情報を加えることができます。 (この能力は変更されていないIPv4ホストとの展開と操作を許すのに使用されるでしょう、他のインターネットワーキングプロトコルと共に同様のテクニックを使用できましたが。) 最大限の範囲のニムロデ能力へのアクセスは、それらがルータで交換するパケットに必要事項を含むようにホストにアップグレードするのを必要とするでしょう。
Second, Nimrod currently has three planned forwarding modes (flows, datagram, and source-routed packets), and a format that works for one may not work for another; some modes use fields that are not used by other modes. The presence or absence of these fields will make a difference.
2番目に、ニムロデは現在モード(流れ、データグラム、およびソースによって発送されたパケット)を進めながら、3を計画させます、そして、働いている形式は別のもののために個人的には働かないかもしれません。 いくつかのモードが他のモードで使用されない分野を使用します。 これらの分野の存在か欠如に効果があるでしょう。
Chiappa [Page 3] RFC 1753 Nimrod Technical Requirements for IPng December 1994
IPng1994年12月のためのChiappa[3ページ]RFC1753ニムロデ技術的要求事項
2.2 Packet Format Fields
2.2 パケット・フォーマット分野
What Nimrod would like to see in the internetworking packet is:
ニムロデがインターネットワーキングパケットで見たがっているものは以下の通りです。
- Source and destination endpoint identification. There are several
possibilities here.
- ソースと目的地終点識別。 いくつかの可能性がここにあります。
One is "UID"s, which are "shortish", fixed length fields which
appear in each packet, in the internetwork header, which contain
globally unique, topologically insensitive identifiers for either
i) endpoints (if you aren't familiar with endpoints, think of them
as hosts), or ii) multicast groups. (In the former instance, the
UID is an EID; in the latter, a "set ID", or SID. An SID is an
identifier which looks just like an EID, but it refers to a group
of endpoints. The semantics of SID's are not completely defined.)
For each of these 48 bits is adequate, but we would recommend 64
bits. (IPv4 will be able to operate with smaller ones for a while,
but eventually either need a new packet format, or the difficult
and not wholly satisfactory technique known as Network Address
Translators, which allows the contents of these fields to be only
locally unique.)
1つがそうである、「UID、「s、各パケット、インターネットワークヘッダーに現れる「やや短く」て、固定された長さの野原がどれであるか、どれ、含有、グローバルにユニークです、位相的に、i)終点(終点になじみ深くないなら、ホストとしてそれらを考える)かii)マルチキャストのどちらかのための神経の鈍い識別子が分類されるか、」 (前の例では、UIDはEIDです。 後者、「セットID」、またはSIDで。 SIDはまさしくEIDに似ている識別子ですが、それは終点のグループを参照します。 SIDの意味論は完全に定義されているというわけではありません。) それぞれのこれらの48ビットは適切ですが、私たちは64ビットを推薦するでしょう、したがって。 (結局新しいパケット・フォーマット、またはこれらの分野のコンテンツが局所的にだけ特有であることを許容するNetwork Address Translatorsとして知られている難しくて完全に満足できないテクニックを必要とするのを除いて、IPv4はしばらく、より小さいもので作動できるでしょう。)
Another possibility is some shorter field, named an "endpoint
selector", or ESEL, which contains a value which is not globally
unique, but only unique in mapping tables on each end, tables which
map from the small value to a globally unique value, such as a DNS
name.
別の可能性は「終点セレクタ」という何らかのより短い分野であるかESEL(各端でテーブルを写像する際にグローバルにユニークであるのではなく、ユニークであるだけである値を含む)は小さい値からグローバルにユニークな値までどの地図を見送るか、DNS名のように。
Finally, it is possible to conceive of overall networking designs
which do not include any endpoint identification in the packet at
all, but transfer it at the start of a communication, and from then
on infer it. This alternative would have to have some other means
of telling which endpoint a given packet is for, if there are
several endpoints at a given destination. Some coordination on
allocation of flow-ids, or higher level port numbers, etc., might
do this.
最終的に、全くパケットでの少しの終点識別も含んでいない総合的なネットワークデザインを想像するのは可能です、コミュニケーションの始めでそれを移して、それ以来それを推論するのを除いて。 この代替手段には、どの終点に関して与えられたパケットがあるかを言うある他の手段がなければならないでしょう、いくつかの終点が与えられた目的地にあれば。 流れイド、または、より高い平らなポートナンバーの配分の何らかのコーディネートなどがこれをするかもしれません。
- Flow identification. There are two basic approaches here, depending
on whether flows are aggregated (in intermediate switches) or not.
It should be emphasized at this point that it is not yet known
whether flow aggregation will be needed. The only reason to do it
is to control the growth of state in intermediate routers, but
there is no hard case made that either this growth will be
unmanageable, or that aggregating flows will be feasible
practically.
- 流れ識別。 流れが集められるかどうかに(中間的スイッチで)よって、2つの基本的なアプローチがここにあります。 ここに流れ集合が必要であるかどうかはまだ知られていないと強調されるべきです。 そんなに集合の流れは実際にそれをする中間的ルータにおける、状態の成長を制御するためにありますが、この成長がされた少しも困難な弁護になりませんが、ある唯一の理由が「非-処理しやす」されるか、または可能になるでしょう。
Chiappa [Page 4] RFC 1753 Nimrod Technical Requirements for IPng December 1994
IPng1994年12月のためのChiappa[4ページ]RFC1753ニムロデ技術的要求事項
For the non-aggregated case, a single "flow-id" field will suffice.
This *must not* use one of the two previous UID fields, as in
datagram mode (and probably source-routed mode as well) the flow-id
will be over-written during transit of the network. It could most
easily be constructed by adding a UID to a locally unique flow-id,
which will provide a globally unique flow-id. It is possible to use
non-globally unique flow-ids, (which would allow a shorter length
to this field), although this would mean that collisions would
result, and have to be dealt with. An adequate length for the local
part of a globally unique flow-id would be 12 bits (which would be
my "out of thin air" guess), but we recommend 32. For a non-
globally unique flow-id, 24 bits would be adequate, but I recommend
32.
非集められたケースのために、ただ一つの「流れイド」分野は十分でしょう。 *使用1ではなく、前の2つのUID分野のこの*必須、データグラムモード(そして、たぶんまた、ソースによって発送されたモード)のように、流れイドはネットワークのトランジットの間、上書きされるでしょう。 局所的にユニークな流れイドにUIDを追加することによって、最も容易にそれを組み立てることができるでしょう。(イドはグローバルにユニークな流れイドを提供するでしょう)。 非グローバルにユニークな流れイドを使用するのが可能である、(より短い長さにこの分野に与えるでしょう)、これは、衝突が結果として生じることを意味して、対処されなければならないでしょうが。 グローバルにユニークな流れイドの地方の部分への適切な長さは12ビット(私の「薄い空気」推測である)でしょうが、私たちは32を推薦します。 非グローバルにユニークな流れイドに、24ビットは適切でしょうが、私は32を推薦します。
For the aggregated case, three broad classes of mechanism are
possible.
集められたケースにおいて、メカニズムの3つの広いクラスが可能です。
- Option 1: The packet contains a sequence (sort of like a source
route) of flow-ids. Whenever you aggregate or deaggregate, you
move along the list to the next one. This takes the most space,
but is otherwise the least work for the routers.
- オプション1: パケットは流れイドの系列(ちょっと送信元経路のような)を含んでいます。 「反-集合」、あなたが集めるか、またはあなたが次のものへのリストに沿って移るときはいつも。 これは、最も多くのスペースを取りますが、そうでなければ、ルータのための作業経済の法則です。
- Option 2: The packet contains a stack of flow-ids, with the
current one on the top. When you aggregate, you push a new one
on; when you de-aggregate, you take one off. This takes more
work, but less space in the packet than the complete "source-
route". Encapsulating packets to do aggregation does basically
this, but you're stacking entire headers, not just flow-ids. The
clever way to do this flow-id stacking, without doing
encapsulation, is to find out from flow-setup how deep the stack
will get, and allocate the space in the packet when it's
created. That way, all you ever have to do is insert a new
flow-id, or "remove" one; you never have to make room for more
flow-ids.
- オプション2: 現在のものが先端にある状態で、パケットは流れイドのスタックを含んでいます。 集めるとき、あなたは新しいものを押します。 反-集めるときに、あなたは1つを取り去ります。 これは、より多くの仕事を取って、パケットのスペースより完全な「ソースルート」を取ります。 集合をするためにパケットをカプセルに入れると、これは基本的にしますが、あなたは流れイドだけではなく、全体のヘッダーを積み重ねています。 カプセル化をしないで積み重ねながらこの流れイドをする賢明な方法は、それが作成されるとき、流れセットアップからスタックがどれくらい深くなるかを見つけて、パケットにスペースを割り当てることです。 そのように、あなたがしなければならないのは、新しい流れイドを挿入するか、または1つを「取り除く」ことです。 あなたは、より多くの流れイドに決して場所を開ける必要はありません。
- Option 3: The packet contains only the "base" flow-id (i.e., the
one with the finest granularity), and the current flow-id. When
you aggregate, you just bash the current flow-id. The tricky
part comes when you de-aggregate; you have to put the right
value back. To do this, you have to have state in the router at
the end of the aggregated flow, which tells you what the de-
aggregated flow for each base flow is. The downside here is
obvious: we get away without individual flow state for each of
the constituent flows in all the routers along the path of that
aggregated, flow, *except* for the last one.
- オプション3: パケットは「ベース」流れイド(すなわち、最もすばらしい粒状があるもの)、および現在の流れイドだけを含んでいます。 集めるとき、あなたはただ現在の流れイドを強打します。 あなたが反-集めるときに、油断のならない部分は来ます。 あなたは正しい値を戻さなければなりません。 これをするために、あなたは集められた流れの終わりにルータで状態を持たなければなりません。(流れはそれぞれのベース流動のための反-集められた流れが何であるかをあなたに言います)。 ここの下落傾向は明白です: 私たちはその経路に沿ったすべてのルータにおける、それぞれの構成している流れのための州が集めた個々の流れなしで逃げます、流れ、最後のもののための*を除いた*。
Chiappa [Page 5] RFC 1753 Nimrod Technical Requirements for IPng December 1994
IPng1994年12月のためのChiappa[5ページ]RFC1753ニムロデ技術的要求事項
Other than encapsulation, which has significant inefficiency in
space overhead fairly quickly, after just a few layers of
aggregation, there appears to be no way to do it with just one
flow-id in the packet header. Even if you don't touch the
packets, but do the aggregation by mapping some number of "base"
flow-id's to a single aggregated flow in the routers along the
path of the aggregated flow, the table that does the mapping is
still going to have to have a number of entries directly
proportional to the number of base flows going through the
switch.
カプセル化を除いて。(それは、ちょうど1つの流れイドがパケットのヘッダーにある状態でそれをする方法でなくなるようにわずかいくつかの層の集合の後にすばやく公正に現れるスペースオーバーヘッドで重要な非能率を持っています)。 集められた流れの経路に沿って何らかの数の「ベース」流れイドをルータにおけるただ一つの集められた流れに写像することによって集合をする以外に、あなたがパケットに触れないでも、マッピングをするテーブルで、それでも、多くのエントリーがスイッチを通るベース流れの数に正比例するようにならなければならないでしょう。
- A looping packet detector. This is any mechanism that will detect a
packet which is "stuck" in the network; a timeout value in packets,
together with a check in routers, is an example. If this is a hop-
count, it has to be more than 8 bits; 12 bits would be adequate,
and I recommend 16 (which also makes it easy to update). This is
not to say that I think networks with diameters larger than 256 are
good, or that we should design such nets, but I think limiting the
maximum path through the network to 256 hops is likely to bite us
down the road the same way making "infinity" 16 in RIP did (as it
did, eventually). When we hit that ceiling, it's going to hurt, and
there won't be an easy fix. I will note in passing that we are
already seeing paths lengths of over 30 hops.
- ループパケット探知器。 これはネットワークで「張り付けられる」パケットを検出するあらゆるメカニズムです。 ルータにおけるチェックと共にパケットのタイムアウト値は例です。 これがホップカウントであるなら、それは8ビット以上でなければなりません。 12ビットは適切でしょう、そして、私は16を推薦します(また、それをアップデートするのが簡単にします)。 これが私が、直径が256より大きいネットワークが良いと考えるか、または私たちがそのようなネットを設計するべきであると言わないためのものですが、私は、RIPで「無限」を16にするとした同じようにネットワークを通した最大の経路を256のホップに制限するのに先で私たちに噛み付きそうである(結局したように)と思います。 私たちがその天井を打ったとき、痛むでしょう、そして、簡単なフィックスがないでしょう。 通過で私たちが既に30以上のホップの経路の長さが見えていることに注意するでしょう。
- Optional source and destination locators. These are structured,
variable length items which are topologically sensitive identifiers
for the place in the network from which the traffic originates or
to which the traffic is destined. The locator will probably contain
internal separators which divide up the fields, so that a
particular field can be enlarged without creating a great deal of
upheaval. An adequate value for maximum length supported would be
up to 32 bytes per locator, and longer would be even better; I
would recommend up to 256 bytes per locator.
- 任意のソースと目的地ロケータ。 これらは構造化されます、位相的にそうである可変長項目。交通が由来するか、または交通が運命づけられているネットワークにおける場所のための機密の識別子。 ロケータはたぶん分野に分割される内部の分離符を含むでしょう、大きな隆起を作成しないで特定の分野を拡大できるように。 支持された最大の長さのための適切な値は、1ロケータあたり最大32バイトであるだろう、より長い間、さらに良いでしょう。 私は1ロケータあたり最大256バイトを推薦するでしょう。
- Perhaps (paired with the above), an optional pointer into the
locators. This is optional "forwarding state" (i.e., state in the
packet which records something about its progress across the
network) which is used in the datagram forwarding mode to help
ensure that the packet does not loop. It can also improve the
forwarding processing efficiency. It is thus not absolutely
essential, but is very desirable from a real-world engineering view
point. It needs to be large enough to identify locations in either
locator; e.g., if locators can be up to 256 bytes, it would need to
be 9 bits.
- 恐らく(上記では、対にされる)、ロケータへの任意のポインタ。 これはパケットが輪にされないのを確実にするのを助けるのにデータグラム推進モードで使用される任意の「推進状態」(すなわち、ネットワークの向こう側に進歩に関して何かを記録するパケットの状態)です。 また、それは推進処理効率を高めることができます。 それは、その結果、絶対に不可欠ではありませんが、本当の世界工学見地から非常に望ましいです。 それは、どちらのロケータでも位置を特定できるくらい大きい必要があります。 例えば、ロケータが最大256バイトであるかもしれないなら、それは、9ビットである必要があるでしょう。
- An optional source route. This is used to support the "source
routed packet" forwarding mode. Although not designed in detail
yet, we can discuss two possible approaches.
- 任意の送信元経路。 これは、モードを進めながら「ソースの発送されたパケット」を支持するのに使用されます。 詳細にまだ設計されていませんが、私たちは2つの可能なアプローチについて議論できます。
Chiappa [Page 6] RFC 1753 Nimrod Technical Requirements for IPng December 1994
IPng1994年12月のためのChiappa[6ページ]RFC1753ニムロデ技術的要求事項
In one, used with "semi-strict" source routing (in which a
contiguous series of entities is named, albeit perhaps at a high
layer of abstraction), the syntax will likely look much like source
routes in PIP; in Nimrod they will be a sequence of Nimrod entity
identifiers (i.e., locator elements, not complete locators), along
with clues as to the context in which each identifier is to be
interpreted (e.g., up, down, across, etc.). Since those identifiers
themselves are variable length (although probably most will be two
bytes or less, otherwise the routing overhead inside the named
object would be excessive), and the hop count above contemplates
the possibility of paths of over 256 hops, it would seem that these
might possibly some day exceed 512 bytes, if a lengthy path was
specified in terms of the actual physical assets used. An adequate
length would be 512 bytes; the recommended length would be 2^16
bytes (although this length would probably not be supported in
practise; rather, the field length would allow it).
「準厳しい」ソースルーティング(それにしても、実体の隣接のシリーズはそこで恐らく高い層の抽象化で命名される)で使用されるものでは、構文はおそらくPIPの送信元経路に非常に似るでしょう。 ニムロデでは、ニムロデエンティティ識別名(すなわち、完全なロケータではなく、ロケータ要素)の系列になるでしょう、解釈される各識別子がことである文脈に関する手がかりと共に(上に、例えば、横切ってダウンしてくださいなど)。 それらの識別子自体が可変長(大部分はたぶん2バイトによりなるでしょうが、さもなければ、名前付の物の中のルーティングオーバーヘッドは過度である)であり、ホップカウント上が256以上のホップの経路の可能性を熟考するので、これらの力がいつかことによると512バイトを超えているのは見えるでしょう、長い経路が使用される実際の物的資産で指定されたなら。 適切な長さは512バイトでしょう。 お勧めの長さは2^16バイト(この長さはたぶん中で支持されないでしょうが、練習してください; むしろ、フィールド長はそれを許容する)でしょう。
In the other, used with classical "loose" source routes, the source
consists of a number of locators. It is not yet clear if this mode
will be supported. If so, the header would need to be able to store
a sequence of locators (as described above). Space might be saved
by not repeating locator prefixes that match that of the previous
locator in the sequence; Nimrod will probably allow use of such
"locally useful" locators. It is hard to determine what an adequate
length would be for this case; the recommended length would be 2^16
bytes (again, with the previous caveat).
古典的な「ゆるい」送信元経路で使用されるもう片方では、ソースは多くのロケータから成ります。 このモードが支持されるかどうかは、まだ明確ではありません。 そうだとすれば、ヘッダーは、ロケータの系列を格納できる必要があるでしょう(上で説明されるように)。 スペースは系列で前のロケータのものに合っているロケータ接頭語を繰り返さないことによって、節約されるかもしれません。 ニムロデはたぶんそのような「局所的に役に立つ」ロケータの使用を許すでしょう。 適切な長さがどのくらいであるかをこのような場合決定しにくいです。 お勧めの長さが2^16バイトであるだろう、(再び、前の警告、)
- Perhaps (paired with the above), an optional pointer into the
source route. This is also optional "forwarding state". It needs to
be large enough to identify locations anywhere in the source route;
e.g., if the source router can be up to 1024 bytes, it would need
to be 10 bits.
- 恐らく(上記では、対にされる)、ソースへの任意のポインタは発送します。 また、これは任意の「推進状態」です。 それは、送信元経路でどこでも位置を特定できるくらい大きい必要があります。 例えば、ソースルータが1024バイトまで達することができるなら、それは、10ビットである必要があるでしょう。
- An internetwork header length. I mention this since the above
fields could easily exceed 256 bytes, if they are to all be carried
in the internetwork header (see comments below as to where to carry
all this information), the header length field needs to be more
than 8 bits; 12 bits would be adequate, and I recommend 16 bits.
The approach of putting some of the data items above into an
interior header, to limit the size of the basic internetworking
header, does not really seem optimal, as this data is for use by
the intermediate routers, and it needs to be easily accessible.
- インターネットワークヘッダ長。 上の分野が容易に256バイトを超えるかもしれないので、私はこれについて言及します、それらがインターネットワークヘッダーですべて運ばれるつもりであるなら(このすべての情報をどこまで運ぶかに関して以下でのコメントを見てください)、8ビット以上であるヘッダ長分野の必要性。 12ビットは適切でしょう、そして、私は16ビットを推薦します。 基本的なインターネットワーキングヘッダーのサイズを制限するために内部のヘッダーにデータ項目のいくつかを上に入れるアプローチは本当に最適に見えません、このデータが中間的ルータによる使用のためのものであり、容易にアクセスしやすいのが必要であるときに。
- Authentication of some sort is needed. See the recent IAB document
which was produced as a result of the IAB architecture retreat on
security (draft-iab-sec-arch-workshop-00.txt), section 4, and
especially section 4.3. There is currently no set way of doing
"denial/theft of service" in Nimrod, but this topic is well
- ある種の認証が必要です。 セキュリティ(iab秒の大-ワークショップの00.txtを作成する)、セクション4、および特にセクション4.3におけるIAB構造後退の結果、製作された最近のIABドキュメントを見てください。 現在、「サービスの否定/窃盗」をするセット方法が全くニムロデにありませんが、この話題は良いです。
Chiappa [Page 7] RFC 1753 Nimrod Technical Requirements for IPng December 1994
IPng1994年12月のためのChiappa[7ページ]RFC1753ニムロデ技術的要求事項
explored in that document; Nimrod would use whatever mechanism(s)
seem appropriate to those knowledgeable in this area.
そのドキュメントでは、探検されます。 ニムロデはこの領域で博識なそれらに適切に見えるどんなメカニズムも使用するでしょう。
- A version number. Future forwarding mechanisms might need other
information (i.e., fields) in the packet header; use a version
number would allow it to be modified to contain what's needed.
(This would not necessarily be information that is visible to the
hosts, so this does not necessarily mean that the hosts would need
to know about this new format.) 4 bits is adequate; it's not clear
if a larger value needs to be recommended.
- バージョン番号。 将来の推進メカニズムはパケットのヘッダーで他の情報(すなわち、分野)を必要とするかもしれません。 数が必要であるものを含むように変更されるのをそれを許容するバージョンを使用してください。 (必ずホストにとって、目に見える情報であるというわけではないので、これは、必ずホストが、この新しい形式に関して知る必要を意味するというわけではありません。) 4ビットは適切です。 より大きい値が、お勧めである必要があるかどうかは、明確ではありません。
2.3 Field Requirements and Addition Methods
2.3 分野要件と添加方法
As noted above, it's possible to use Nimrod in a limited mode where needed information/fields are added by the first-hop router. It's thus useful to ask "which of the fields must be present in the host- router header, and which could be added by the router?" The only ones which are absolutely necessary in all packets are the endpoint identification (provided that some means is available to map them into locators; this would obviously be most useful on UID's which are EID's).
上で述べたように、必要な情報/分野が最初に、ホップルータによって加えられる限られたモードでニムロデを使用するのは可能です。 その結果、「分野のどれがホストルータヘッダーに存在していなければならないか、そして、ルータはどれを加えることができますか?」を尋ねるのは役に立ちます。 唯一のすべてのパケットで絶対に必要なものは終点識別(いくつかならば、手段はそれらをロケータに写像するために利用可能です; これはEIDのものであるUIDのところで明らかに最も役に立つ)です。
As to the others, if the user wishes to use flows, and wants to guarantee that their packets are assigned to the correct flows, the flow-id field is needed. If the user wishes efficient use of the datagram mode, it's probably necessary to include the locators in the packet sent to the router. If the user wishes to specify the route for the packets, and does not wish to set up a flow, they need to include the source route.
他のものに関して、ユーザが、流れを使用することを願って、それらのパケットが正しい流れに割り当てられるのを保証したいなら、流れイド分野が必要です。 ユーザがデータグラムモードの効率的な使用を願うなら、ルータに送られたパケットにロケータを含むのがたぶん必要です。 ユーザがパケットにルートを指定することを願って、流れをセットアップしたくないなら、それらは、送信元経路を含む必要があります。
How would additional information/fields be added to the packet, if the packet is emitted from the host in incomplete form? (By this, I mean the simple question of how, mechanically, not the more complex issue of where any needed information comes from.)
パケットが不完全なフォームでホストから放たれているなら、追加情報/分野はどのようにパケットに加えられますか? (これで、私は、簡単がいずれも情報を必要としたところに関するいずれのより複雑な問題もどう機械的に、来ないかに質問すると言っています。)
This question is complex, since all the IPng candidates (and in fact, any reasonable inter-networking protocol) are extensible protocols; those extension mechanisms could be used. Also, it would possible to carry some of the required information as user data in the internetworking packet, with the original user's data encapsulated further inside. Finally, a private inter-router packet format could be defined.
この質問はすべてのIPng候補(そして、事実上、どんな妥当なインターネットワーキングプロトコルも)が広げることができるプロトコルであるので、複雑です。 それらの拡大メカニズムを使用できました。 それも要約するでしょう。利用者データとしてインターネットワーキングパケットで必須情報のいくつかを運ぶのにおいて可能です、オリジナルのユーザのものと共に、データは中にさらに要約されました。 最終的に、個人的な相互ルータパケット・フォーマットを定義できました。
It's not clear which path is best, but we can talk about which fields the Nimrod routers need access to, and how often; less used ones could be placed in harder-to-get-to locations (such as in an encapsulated header). The fields to which the routers need access on every hop are the flow-id and the looping packet detector. The
どの経路が最も良いかが、明確ではありませんが、ニムロデルータがどの分野にアクセスを必要とするかに関して私たちはどれくらいの頻度で話すことができるか。 より始めにくい位置(要約のヘッダーなどの)にそれほど中古でないものを置くことができました。 ルータがあらゆるホップの上でアクセスを必要とする分野は、流れイドとループパケット探知器です。 The
Chiappa [Page 8] RFC 1753 Nimrod Technical Requirements for IPng December 1994
IPng1994年12月のためのChiappa[8ページ]RFC1753ニムロデ技術的要求事項
locator/pointer fields are only needed at intervals (in what datagram forwarding mode calls "active" routers), as is the source route (the latter at every object which is named in the source route).
間隔(どんなデータグラム推進モードが、「アクティブな」ルータと呼ぶかの)を置いて、ロケータ/ポインタ分野が必要であるだけです、送信元経路(送信元経路で命名されるあらゆる物の後者)のように。
Depending on how access control is done, and which forwarding mode is used, the UID's and/or locators might be examined for access control purposes, wherever that function is performed.
アクセス管理がどのように完了しているか、そして、どの推進モードが使用されているかによって、UIDのもの、そして/または、ロケータはアクセス管理目的がないかどうか調べられるかもしれません、その機能がどこで実行されても。
This is not a complete exploration of the topic, but should give a rough idea of what's going on.
これは、話題の完全な探検ではありませんが、起こっていることに関するおよその考えを与えるべきです。
3. Architectural Issues
3. 構造的な問題
3.1 Interaction Architectural Issues
3.1 相互作用構造的な問題
The topic of the interaction with the rest of the internetwork layer is more complex. Nimrod springs in part from a design vision which sees the entire internetwork layer, distributed across all the hosts and routers of the internetwork, as a single system, albeit a distributed system.
インターネットワーク層の残りとの相互作用の話題は、より複雑です。 ニムロデはインターネットワークのすべてのホストとルータの向こう側に分配された全体のインターネットワーク層をただ一つのシステムと考えるデザインビジョンから一部生じます、分散システムですが。
Approached from that angle, one naturally falls into a typical system designer point of view, where you start to think of the modularization of the system; chosing the functional boundaries which divide the system up into functional units, and defining the interactions between the functional units. As we all know, that modularization is the key part of the system design process.
その角度からアプローチされています、1つは自然に典型的なシステム設計者観点になります。(そこではあなたがシステムの変調を考え始めます)。 機能的なユニットに上がっていて、機能的なユニットの間で相互作用を定義しているシステムを分割する機能的境界をchosingします。 誰もが知っているとおり、その変調はシステム設計の過程の主要な部分です。
It's rare that a group of completely independent modules form a system; there's usually a fairly strong internal interaction. Those interactions have to be thought about and understood as part of the modularization process, since it effects the placement of the functional boundaries. Poor placement leads to complex interactions, or desired interactions which cannot be realized.
完全に独立しているモジュールのグループがシステムを形成するのは、まれです。 通常、かなり強い内部の相互作用があります。 それらの相互作用は、変調の過程の一部として考えて、理解されなければなりません、機能的境界のプレースメントに作用するので。 不十分なプレースメントは実感できない複雑な相互作用、または必要な相互作用に通じます。
These are all more important issues with a system which is expected to have a long lifetime; correct placement of the functional boundaries, so as to clearly and simply break up the system into truly fundamental units, is a necessity is the system is to endure and serve well.
これらは長い生涯を持っていると予想されるシステムのすべて重要な問題です。 機能的境界のプレースメントが本当に基本的なユニットにシステムを明確に、単に壊れさせる必要性がシステムであるということであることが正しいのは、続いて、よく役立つことです。
3.1.1 The Internetwork Layer Service Model
3.1.1 インターネットワーク層のサービスモデル
To return to the view of the internetwork layer as a system, that system provides certain services to its clients; i.e., it instantiates a service model. To begin with, lacking a shared view of the service model that the internetwork layer is supposed to provide, it's reasonable to suppose that it will prove impossible to agree on
システムとしてインターネットワーク層の視点に戻るために、そのシステムはクライアントに対する、あるサービスを提供します。 すなわち、それはサービスモデルを例示します。 初めに、インターネットワーク層が提供するべきであるというサービスモデルの共有された意見を欠いていて、それが同意するのが不可能であると判明すると思うのは妥当です。
Chiappa [Page 9] RFC 1753 Nimrod Technical Requirements for IPng December 1994
IPng1994年12月のためのChiappa[9ページ]RFC1753ニムロデ技術的要求事項
mechanisms at the internetwork level to provide that service.
そのサービスを提供するインターネットワークレベルにおけるメカニズム。
To answer the question of what the service model ought to be, one can view the internetwork layer itself as a subsystem of an even large system, the entire internetwork itself. (That system is quite likely the largest and most complex system we will ever build, as it is the largest system we can possibly build; it is the system which will inevitably contain almost all other systems.)
サービスモデルが何であるべきであるかに関する質問に答えるために、人は同等の大規模システムのサブシステムであるとインターネットワーク層自体をみなすことができます、全体のインターネットワーク自体。 (そのシステムはかなりありそうな最も大きくて私たちが構築するつもりである中で最も複雑なシステムです、それが私たちが構築できる中で最も大きいシステムであるので; それは必然的に他のほとんどすべてのシステムを含むシステムです。)
From that point of view, the issue of the service model of the internetwork layer becomes a little clearer. The services provided by the internetwork layer are no longer purely abstract, but can be thought about as the external module interface of the internetwork layer module. If agreement can be reached on where to put the functional boundaries of the internetwork layer, and on what overall service the internet as a whole should provide, the service model of the internetwork layer should be easier to agree on.
その観点から、インターネットワーク層のサービスモデルの問題は少し明確になります。 インターネットワーク層で提供されたサービスについて、もう純粋に抽象的ではありませんが、インターネットワーク層のモジュールの外部のモジュールインタフェースとして考えることができます。 インターネットワーク層の機能的境界をどこに置くか、そして、全体でインターネットがどんな総合的なサービスのときに提供されるべきであるかに関して合意に達することができるなら、インターネットワーク層のサービスモデルは同意するのが、より簡単であるはずです。
In general terms, it seems that the unreliable packet ought to remain the fundamental building block of the internetwork layer. The design principle that says that we can take any packet and throw it away with no warning or other action, or take any router and turn it off with no warning, and have the system still work, seems very powerful. The component design simplicity (since routers don't have to stand on their heads to retain a packet which they have the only copy of), and overall system robustness, resulting from these two assumptions is absolutely critical.
あいまいな言葉で、頼り無いパケットがインターネットワーク層の基本的なブロックのままで残るべきであるように思えます。 私たちがどんなパケットも取って、警告も他の動作なしでそれを捨てるか、どんなルータも取って、警告なしでそれをオフにして、またはシステムをまだ働かせることができると言う設計原理は非常に強力に見えます。 コンポーネントデザインの簡単さ(ルータが、彼らの頭の上で彼らが唯一のコピーを持っているパケットを保有するのに耐える必要はないので)、および総合体系丈夫さ、これらの2つの仮定から生じるのは絶対に批判的です。
In detail, however, particularly in areas which are still the subject of research and experimentation (such as resource allocation, security, etc.), it seems difficult to provide a finished definition of exactly what the service model of the internetwork layer ought to be.
しかしながら、詳細に、特にそれでも、研究テーマと実験(資源配分、セキュリティなどの)である領域では、インターネットワーク層のサービスモデルがまさに何であるべきであるかに関する終わっている定義を提供するのが難しく思えます。
3.1.2 The Subsystems of the Internetwork Layer
3.1.2 インターネットワーク層のサブシステム
In any event, by viewing the internetwork layer as a large system, one starts to think about what subsystems are needed, and what the interactions among them should look like. Nimrod is simply a number of the subsystems of this larger system, the internetwork layer. It is *not* intended to be a purely standalone set of subsystems, but to work together in close concert with the other subsystems of the internetwork layer (resource allocation, security, charging, etc.) to provide the internetwork layer service model.
とにかく、インターネットワーク層を大規模システムであるとみなすことによって、1つはどんなサブシステムが必要であるか、そして、それらの中の相互作用が何に似るべきであるか考え始めます。 ニムロデは単にこのより大きいシステム、インターネットワーク層の多くのサブシステムです。 それは*ではなく、純粋にスタンドアロンセットのサブシステムであることを意図する*ですが、インターネットワーク層のサービスを提供するために厳密なコンサートでインターネットワーク層(資源配分、セキュリティ、充電など)の他のサブシステムで一緒に働くには、モデル化してください。
One reason that Nimrod is not simply a monolithic subsystem is that some of the interactions with the other subsystems of the internetwork layer, for instance the resource allocation subsystem,
ニムロデが単に一枚岩的なサブシステムでない1つの理由はインターネットワークの他のサブシステムとの相互作用のいくつかに層にされるということです、例えば、資源配分サブシステム
Chiappa [Page 10] RFC 1753 Nimrod Technical Requirements for IPng December 1994
IPng1994年12月のためのChiappa[10ページ]RFC1753ニムロデ技術的要求事項
are much clearer and easier to manage if the routing is broken up into several subsystems, with the interactions between them open.
多くは、よりなくて、ルーティングがいくつかのサブシステムに終えられるなら、それらの間には、開いている相互作用はある状態で、より管理しやすいですか?
It is important to realize that Nimrod was initially broken up into separate subsystems for purely internal reasons. It so happens that, considered as a separate problem, the fundamental boundary lines for dividing routing up into subsystems are the same boundaries that make interaction with other subsystems cleaner; this provides added evidence that these boundaries are in fact the right ones.
ニムロデが初めは純粋に内部の理由で別々のサブシステムに壊れたとわかるのは重要です。 偶然、別々の問題、サブシステムに上がっている分割ルーティングのための基本的な境界であるとみなされているのは、他のサブシステムとの相互作用をよりきれいにする同じ境界です。 これは事実上、これらの境界が正しいものであるという付記された証拠を提供します。
The subsystems which comprise the functionality covered by Nimrod are i) routing information distribution (in the case of Nimrod, topology map distribution, along with the attributes [policy, QOS, etc.] of the topology elements), ii) route selection (strictly speaking, not part of the Nimrod spec per se, but functional examples will be produced), and iii) user traffic handling.
ニムロデでカバーされた機能性を包括するサブシステムは、i)ルーティング情報流通(トポロジー要素の属性[方針、QOSなど]に伴うニムロデの場合におけるトポロジー地図分配)と、ii)ルート選択(厳密に言うと、そういうもののニムロデ仕様の一部ではなく、機能的な例が作り出される)と、iii)ユーザ交通取り扱いです。
The former can fairly well be defined without reference to other subsystems, but the second and third are necessarily more involved. For instance, route selection might involve finding out which links have the resources available to handle some required level of service. For user traffic handling, if a particular application needs a resource reservation, getting that resource reservation to the routers is as much a part of getting the routers ready as making sure they have the correct routing information, so here too, routing is tied in with other subsystems.
他のサブシステムの参照なしで前者を公正によく定義できますが、2番目と3番目は必ずさらに伴われます。 例えば、ルート選択は、どのリンクにいくつかを扱うために利用可能なリソースがあるかがサービスのレベルを必要としたのを見つけることを伴うかもしれません。 ユーザ交通取り扱いのために、特定用途が資源予約を必要とするなら、その資源予約をルータに得るのは、ルータを用意するしたがって、また、ここに正しいルーティング情報を持って、ルーティングが他のサブシステムで接続されるのを確実にするのと同じくらい多くの部分です。
In any event, although we can talk about the relationship between the Nimrod subsystems, and the other functional subsystems of the internetwork layer, until the service model of the internetwork layer is more clearly visible, along with the functional boundaries within that layer, such a discussion is necessarily rather nebulous.
とにかく、私たちはニムロデサブシステムと、インターネットワーク層の他の機能的なサブシステムとの関係に関して話すことができますが、インターネットワーク層のサービスモデルが機能的境界と共にその層の中で明確に目に見えるまで、そのような議論は必ずかなり不明瞭です。
3.2 State and Flows in the Internetwork Layer
3.2 インターネットワーク層における状態と流れ
The internetwork layer as whole contains a variety of information, of varying lifetimes. This information we can refer to as the internetwork layer's "state". Some of this state is stored in the routers, and some is stored in the packets.
全体のインターネットワーク同じくらい層は異なった生涯のさまざまな情報を含んでいます。 私たちがインターネットワーク層の「状態」と呼ぶことができるこの情報。 この何らかの状態がルータに格納されます、そして、或るものはパケットに格納されます。
In the packet, I distinguish between what I call "forwarding state", which records something about the progress of this individual packet through the network (such as the hop count, or the pointer into a source route), and other state, which is information about what service the user wants from the network (such as the destination of the packet), etc.
パケットでは、私はネットワーク(ホップカウント、または送信元経路へのポインタなどの)、および他の状態を通したこの個々のパケットの進歩に関して自分が何かを記録する「状態を進めます」と呼ぶことを見分けます。状態はユーザがネットワーク(パケットの目的地などの)からどんなサービスが欲しいかの情報ですなど。
Chiappa [Page 11] RFC 1753 Nimrod Technical Requirements for IPng December 1994
IPng1994年12月のためのChiappa[11ページ]RFC1753ニムロデ技術的要求事項
3.2.1 User and Service State
3.2.1 ユーザとサービス状態
I call state which reflects the desires and service requests of the user "user state". This is information which could be sent in each packet, or which can be stored in the router and applied to multiple packets (depending on which makes the most engineering sense). It is still called user state, even when a copy is stored in the routers.
私は、ユーザの願望とサービスのリクエストを反映する州を「ユーザ状態」と呼びます。 これは各パケットで送ることができたか、ルータに格納されて、または複数のパケットに適用できる情報(どれが最も多くの工学意味になるかによる)です。 コピーがルータに格納さえされるとき、それはまだユーザ状態と呼ばれています。
User state can be divided into two classes; "critical" (such as destination addresses), without which the packets cannot be forwarded at all, and "non-critical" (such as a resource allocation class), without which the packets can still be forwarded, just not quite in the way the user would most prefer.
ユーザ状態を2つのクラスに分割できます。 「批判的である」(送付先アドレスなどの)、パケットがどれであるはずがないかなしで全く進められないで、「非臨界である」(リソース割り振りクラスなどの)、まだパケットを進めることができるものがなければ、まさしく全く方法でいずれのユーザも、大部分は好まないでしょう。
There are a range of possible mechanisms for getting this user state to the routers; it may be put in every packet, or placed there by a setup. In the latter case, you have a whole range of possibilities for how to get it back when you lose it, such as placing a copy in every Nth packet.
このユーザ状態をルータに得るためのさまざまな可能なメカニズムがあります。 それは、セットアップでそこにあらゆるパケットに入れられるか、または置かれるかもしれません。 後者の場合では、それを失うと、あなたはどうそれを取り戻すかためには全体の範囲の可能性を持っています、あらゆるNthパケットにコピーを置くのなどように。
However, other state is needed which cannot be stored in each packet; it's state about the longer-term (i.e., across the life of many packets) situation; i.e., state which is inherently associated with a number of packets over some time-frame (e.g., a resource allocation). I call this state "server state".
しかしながら、各パケットに格納できない他の状態が必要です。 それは、より長い期間(すなわち、多くのパケットの人生の向こう側の)状況に関する状態です。 すなわち、どれが本来いくらかの時間枠(例えば、資源配分)の上の多くのパケットに関連しているかを述べてください。 私は、これを州の「サーバ状態」と呼びます。
This apparently changes the "stateless" model of routers somewhat, but this change is more apparent than real. The routers already contain state, such as routing table entries; state without which is it virtually impossible to handle user traffic. All that is being changed is the amount, granularity, and lifetime, of state in the routers.
これが明らかにルータの「国がない」モデルをいくらか変えますが、この変化は本当であるというよりも明らかです。 ルータは既に経路指定テーブルエントリーなどの状態を含んでいます。 ハンドルユーザ交通への実際にはどれがそれであるかなしで不可能な状態。 変えられているすべてが、ルータにおける状態の量と、粒状と、生涯です。
Some of this service state may need to be installed in a fairly reliable fashion; e.g., if there is service state related to billing, or allocation of resources for a critical application, one more or less needs to be guaranteed that this service state has been correctly installed.
このいくつかのサービス州が、かなり信頼できるファッションにインストールされる必要があるかもしれません。 例えば、支払いに関連するサービス状態、または批判的なアプリケーションのためのリソースの配分があれば、人は、多少このサービス状態が正しくインストールされたのが保証される必要があります。
To the extent that you have state in the routers (either service state, or user state), you have to be able to associate that state with the packets it goes with. The fields in the packets that allow you to do this are "tags".
あなたがルータ(サービス州かユーザ状態のどちらか)で状態を持っているという範囲と、あなたはそれが伴うパケットにその状態を関連づけることができなければなりません。 あなたがこれができるパケットの分野は「タグ」です。
Chiappa [Page 12] RFC 1753 Nimrod Technical Requirements for IPng December 1994
IPng1994年12月のためのChiappa[12ページ]RFC1753ニムロデ技術的要求事項
3.2.2 Flows
3.2.2 流れ
It is useful to step back for a bit here, and think about the traffic in the network. Some of it will be from applications with are basically transactions; i.e., they require only a single packet, or a very small number. (I tend to use the term "datagram" to refer to such applications, and use the term "packet" to describe the unit of transmission through the network.) However, other packets are part of longer-lived communications, which have been termed "flows".
少しここに下がって、ネットワークで交通について考えるのは役に立ちます。 それのいくつかがアプリケーションからある、基本的に取引です。 すなわち、彼らは単一のパケット、または非常に少ない数だけを必要とします。 (私はそのようなアプリケーションを参照するのに「データグラム」という用語を使用して、ネットワークを通したトランスミッションのユニットについて説明するのに「パケット」という用語を使用する傾向があります。) しかしながら、他のパケットは、より長く送られたコミュニケーションの一部です。(コミュニケーションは「流れ」と呼ばれました)。
A flow, from the user's point of view, is a sequence of packets which are associated, usually by being from a single application instance. In an internetwork layer which has a more complex service model (e.g., supports resource allocation, etc.), the flow would have service requirements to pass on to some or all of the subsystems which provide those services.
ユーザの観点から、流れは関連パケットの系列です、通常、ただ一つのアプリケーション例からあることによって。 より複雑なサービスモデル(例えば、資源配分などを支持する)があるインターネットワーク層の中では、流れはそれらのサービスを提供するサブシステムのいくつかかすべてに通るというサービス要件を持っているでしょう。
To the internetworking layer, a flow is a sequence of packets that share all the attributes that the internetworking layer cares about. This includes, but is not limited to: source/destination, path, resource allocation, accounting/authorization, authentication/security, etc., etc.
インターネットワーキング層に、流れはインターネットワーキング層が心配するすべての属性を共有するパケットの系列です。 含んでいますが、これは制限されません: ソース/目的地、経路、資源配分、会計/認可、認証/セキュリティなど
There isn't necessarily a one-one mapping from flows to *anything* else, be it a TCP connection, or an application instance, or whatever. A single flow might contain several TCP connections (e.g., with FTP, where you have the control connection, and a number of data connections), or a single application might have several flows (e.g., multi-media conferencing, where you'd have one flow for the audio, another for a graphic window, etc., with different resource requirements in terms of bandwidth, delay, etc., for each.)
*ほかに流れから*まで何も写像するもの-1が必ずあるというわけではありません、TCP接続、アプリケーション例、または何であるかにかかわらず。ただ一つの流れがいくつかのTCP接続(あなたがコントロール接続、および多くのデータ接続がいるところで例えば、FTPで)を含むかもしれませんか、またはただ一つのアプリケーションには数回の流れがあるかもしれません。(例えば、帯域幅に関する異なったリソース要件、それぞれのための遅れなどがあるマルチメディア会議。)そこでは、あなたがグラフィック窓への別のものオーディオのための1回の流れなどを持っているでしょう。
Flows may also be multicast constructs, i.e., multiple sources and destinations; they are not inherently unicast. Multicast flows are more complex than unicast (there is a large pool of state which must be made coherent), but the concepts are similar.
また、流れがマルチキャスト構造物であるかもしれなく、すなわち、倍数は、ソースと目的地です。 本来それらはユニキャストではありません。 マルチキャスト流れはユニキャストより複雑ですが(一貫性を持つようにしなければならない状態の大きいプールがあります)、概念は同様です。
There's an interesting architectural issue here. Let's assume we have all these different internetwork level subsystems (routing, resource allocation, security/access-control, accounting), etc. Now, we have two choices.
おもしろい構造的な問題がここにあります。 私たちにはこれらのすべてのインターネットワークの異なったレベルサブシステム(資源配分、セキュリティ/アクセス管理が説明されて、掘る)などがあると仮定しましょう。 今、私たちには、2つの選択があります。
First, we could allow each individual subsystem which uses the concept of flows to define itself what it thinks a "flow" is, and define which values in which fields in the packet define a given "flow" for it. Now, presumably, we have to allow 2 flows for subsystem X to map onto 1 flow for subsystem Y to map onto 3 flows for subsystem Z; i.e., you can mix and match to your heart's content.
まず最初に、私たちは、定義するのに流れの概念を使用するそれぞれの独特のサブシステムにそれによる考え「流れ」が何であるかということであることを許容して、パケットの分野がそれのために与えられた「流れ」を定義するどの値を定義できたか。 私たちがおそらく1に写像するサブシステムXのための2回の流れを許さなければならないので、サブシステムYが3に写像する流れはサブシステムZのために流れます。 すなわち、あなたは、思うぞんぶん混入して、合うことができます。
Chiappa [Page 13] RFC 1753 Nimrod Technical Requirements for IPng December 1994
IPng1994年12月のためのChiappa[13ページ]RFC1753ニムロデ技術的要求事項
Second, we could define a standard "flow" mechanism for the internetwork layer, along with a way of identifying the flow in the packet, etc. Then, if you have two things which wish to differ in *any* subsystem, you have to have a separate flow for each.
2番目に、私たちはインターネットワーク層のために標準の「流れ」メカニズムを定義できました、パケットの流れなどを特定する方法と共に そして、2つのものがありました(どんな*サブシステムでありも*において異なるように、あなたがそうしなければならないことを願っています)ら、それぞれのための別々の流れを持ってください。
The former has the advantages that it's a little easier to deploy incrementally, since you don't have to agree on a common flow mechanism. It may save on replicated state (if I have 3 flows, and they are the same for subsystem X, and different for Y, I only need one set of X state). It also has a lot more flexibility. The latter is simple and straightforward, and given the complexity of what is being proposed, it seems that any place we can make things simpler, we should.
前者には、増加して配備するのが少し簡単である利点があります、あなたが一般的な流れメカニズムに同意する必要はないので。 それは模写された状態で節約されるかもしれません(それらが私には3回の流れがあって、サブシステムXに同じであって、Yにおいて、異なる場合にだけ、私は1セットのX状態を必要とします)。 また、それには、ずっと多くの柔軟性があります。 後者は、簡単であって、簡単です、そして、提案されていることに関する複雑さを考えて、私たちがそうすることができるどんな場所でも事態が、より簡単になるように思えて、私たちは簡単であるべきです。
The choice is not trivial; it all depends on things like "what percentage of flows will want to share the same state in certain subsystems with other flows". I don't know how to quantify those, but as an architect, I prefer simple, straightforward things. This system is pretty complex already, and I'm not sure the benefits of being able to mix and match are worth the added complexity. So, for the moment I'll assume a single, system-wide, definition of flows.
選択は些細ではありません。 それはすべて、「何パーセントの流れが、あるサブシステムで他の流れと同じ状態を共有したくなるでしょうか」のようなものによります。 それらを定量化する方法を知りませんが、建築家として、私は簡単で、簡単なものを好みます。 このシステムは既にかなり複雑です、そして、私は混入して、合うことができる利益は加えられた複雑さの価値があるのを確信していません。 そのように、そして、さしあたり、私は流れの単一の、そして、システム全体の定義を仮定するつもりです。
The packets which belong to a flow could be identified by a tag consisting of a number of fields (such as addresses, ports, etc.), as opposed to a specialized field. However, it may be more straightforward, and foolproof, to simply identify the flow a packet belongs to with by means of a specialized tag field (the "flow-id" ) in the internetwork header. Given that you can always find situations where the existing fields alone don't do the job, and you *still* need a separate field to do the job correctly, it seems best to take the simple, direct approach , and say "the flow a packet belongs to is named by a flow-id in the packet header".
多くの分野(アドレス、ポートなどの)から成るタグで流れに属すパケットは特定できました、専門分野と対照的に。 しかしながら、それは、インターネットワークヘッダーで単に専門化しているタグ・フィールドによる(「流れイド」)とパケットが属す流れを同一視するために、より簡単であって、きわめて簡単であるかもしれません。 あなたが正しく仕事するためにいつも既存の分野だけが*まだ仕事、およびあなたをしていない*がそうしなければならない状況に別々の分野を見つけることができるなら、簡単で、ダイレクトなアプローチを取って、「パケットが属す流れはパケットのヘッダーで流れイドによって命名されます」と言うのは最も良く思えます。
The simplicity of globally-unique flow-id's (or at least a flow-id which unique along the path of the flow) is also desirable; they take more bits in the header, but then you don't have to worry about all the mechanism needed to remap locally-unique flow-id's, etc., etc. From the perspective of designing something with a long lifetime, and which is to be deployed widely, simplicity and directness is the only way to go. For me, that translates into flows being named solely by globally unique flow-id's, rather than some complex semantics on existing fields.
グローバルにユニークなイドの流れものの簡単さ、(少なくとも流れイド、どれ、ユニークである、流れの経路) また、望ましいです。 彼らはヘッダーをより多くのビット中に入れますが、あなたがすべてのメカニズムを心配するように持っていないその時は局所的にユニークなイドの流れものなどをremapに必要としました。 設計の見解から、長い生涯、どれが広く配備されることになっていたらよいか、そして、簡単さ、および率直さがある何かが行く唯一の方法です。 私に関しては、それは唯一存在するときの何らかの複雑な意味論よりむしろグローバルにユニークな流れイドの分野によって命名される流れに翻訳されます。
However, the issue of how to recognize which packets belong to flows is somewhat orthogonal to the issue of whether the internetwork level recognizes flows at all. Should it?
しかしながら、パケットがどれに属するかが流れるとどう認めるかに関する問題はインターネットワークレベルが全く流れを認識するかどうかに関する問題といくらか直交しています。 それはそうするべきですか?
Chiappa [Page 14] RFC 1753 Nimrod Technical Requirements for IPng December 1994
IPng1994年12月のためのChiappa[14ページ]RFC1753ニムロデ技術的要求事項
3.2.3 Flows and State
3.2.3 流れと状態
To the extent that you have service state in the routers you have to be able to associate that state with the packets it goes with. This is a fundamental reason for flows. Access to service state is one reason to explicitly recognize flows at the internetwork layer, but it is not the only one.
あなたがルータでサービス状態を持っているという範囲と、あなたはそれが伴うパケットにその状態を関連づけることができなければなりません。 これは流れに関する基本的な理由です。 サービス状態へのアクセスはインターネットワーク層で明らかに流れを認識する1つの理由ですが、それは唯一無二ではありません。
If the user has requirements in a number of areas (e.g., routing and access control), they can theoretically communicate these to the routers by placing a copy of all the relevant information in each packet (in the internetwork header). If many subsystems of the internetwork are involved, and the requirements are complex, this could be a lot of bits.
ユーザが多くの領域(例えば、ルーティングとアクセス管理)に要件を持っているなら、彼らは、各パケット(インターネットワークヘッダーの)にすべての関連情報のコピーを置くことによって、これらを理論的にルータに伝えることができます。 インターネットワークの多くのサブシステムがかかわって、要件が複雑であるなら、これは多くのビットであるかもしれません。
(As a final aside, there's clearly no point in storing in the routers any user state about packets which are providing datagram service; the datagram service has usually come and gone in the same packet, and this discussion is all about state retention.)
(傍らに決勝として、ルータにデータグラムサービスを提供しているパケットに関してどんなユーザ状態も格納する意味が全く明確にありません; 通常、データグラムサービスは同じパケットを行き来して、この議論は州の保有に関するものです。)
There are two schools of thought as to how to proceed. The first says that for reasons of robustness and simplicity, all user state ought to be repeated in each packet. For efficiency reasons, the routers may cache such user state, probably along with precomputed data derived from the user state. (It makes sense to store such cached user state along with any applicable server state, of course.)
どう続くかに関して考えの2つの学校があります。 1番目は、丈夫さと簡単さの理由で、すべてのユーザ状態が各パケットで繰り返されるべきであると言います。 効率理由で、ルータはたぶんユーザ状態から得られた前計算されたデータに伴うそのようなユーザ状態をキャッシュするかもしれません。 (どんな適切なサーバ状態に伴うそのようなキャッシュされたユーザ状態も格納する意味になる、もちろん。)
The second school says that if something is going to generate lots of packets, it makes engineering sense to give all this information to the routers once, and from then on have a tag (the flow-id) in the packet which tells the routers where to find that information. It's simply going to be too inefficient to carry all the user state around all the time. This is purely an engineering efficiency reason, but it's a significant one.
2番目の学校は、何かが多くのパケットを発生させるなら、一度このすべての情報をルータに教えて、どこでそれを見つけるかをルータに言うパケットにそれ以来、タグ(流れイド)を持つ工学意味を情報にすると言います。 単に、絶えずすべてのユーザ状態を持ち歩くのは効率が悪くなり過ぎるでしょう。 これは純粋に工学効率理由ですが、それはかなりのものです。
There is a slightly deeper argument, which says that the routers will inevitably come to contain more user state, and it's simply a question of whether that state is installed by an explicit mechanism, or whether the routers infer that state from watching the packets which pass through them. To the extent that it is inevitable anyway, there are obvious benefits to be gained from recognizing that, and an explicit design of the installation is more likely to give satisfactory results (as opposed to an ad-hoc mechanism).
わずかに深い議論があります、そして、それは単にその状態が明白なメカニズムによってインストールされるかどうか、またはルータが通るパケットを見るのからそれらまでその状態を推論するかどうかに関する問題です。(議論はルータが必然的により多くのユーザ状態を含むようになると言います)。 それがとにかく必然であるという範囲には、それを認識しながら得るために、明白な利益があります、そして、インストールの明白なデザインが、より実績を上げそうです(臨時のメカニズムと対照的に)。
It is worth noting that although the term "flow" is often used to refer to this state in the routers along the path of the flow, it is important to distinguish between i) a flow as a sequence of packets (i.e., the definition given in 3.2.2 above), and ii) a flow, as the
「流れ」という期間が流れの経路に沿ったルータでこの状態について言及するのにおいてしばしば使用されていますが、パケットの系列としてi) 流れを見分けるのが重要であることに注意する価値がある、(すなわち、中に与えられた定義、3.2、上の.2、)、ii) そして、流れ
Chiappa [Page 15] RFC 1753 Nimrod Technical Requirements for IPng December 1994
IPng1994年12月のためのChiappa[15ページ]RFC1753ニムロデ技術的要求事項
thing which is set up in the routers. They are different, and although the particular meaning is usually clear from the context, they are not the same thing at all.
ルータでセットアップされるもの。 異なります、そして、特定の意味は文脈から通常明確ですが、それらは全く同じものではありません。
I'm not sure how much use there is to any intermediate position, in which one subsystem installs user state in the routers, and another carries a copy of its user state in each packet.
私は確実に、どれほどサブシステムがユーザ状態をルータにインストールするどんな中間的位置にはもそこでの使用があって、別のものが各パケットでユーザ状態のコピーを運ぶということではありません。
(There are other intermediate positions. First, one flow might use a given technique for all its subsystems, and another flow might use a different technique for its; there is potentially some use to this, although I'm not sure the cost in complexity of supporting both mechanisms is worth the benefits. Second, one flow might use one mechanism with one router along its path, and another for a different router. A number of different reasons exist as to why one might do this, including the fact that not all routers may support the same mechanisms simultaneously.)
(他の中間的位置があります。 まず最初に1回の流れがすべてのサブシステム、および別のもののための流れが異なったテクニックを使用するかもしれない与えられたテクニックを使用するかもしれない、それ、。 これへの何らかの使用が潜在的にあります、私は両方のメカニズムをサポートする複雑さにおける費用が利益の価値があるのを確信していませんが。 2番目に、1回の流れが経路に沿って1つのルータがある1つのメカニズム、および異なったルータのための別のものを使用するかもしれません。 多くの異なった理由が1つがこれをするかもしれない理由に関して存在しています、すべてのルータが同時に同じメカニズムをサポートするかもしれないというわけではないという事実を含んでいて。)
It seems to me that to have one internetwork layer subsystem (e.g., resource allocation) carry user state in all the packets (perhaps with use of a "hint" in the packets to find potentially cached copies in the router), and have a second (e.g., routing) use a direct installation, and use a tag in the packets to find it, makes little sense. We should do one or the other, based on a consideration of the efficiency/robustness tradeoff.
1つのインターネットワーク層のサブシステム(例えば、資源配分)を持っているのがすべてのパケット(恐らくルータで潜在的にキャッシュされたコピーを見つけるパケットにおける「ヒント」の使用がある)でユーザ状態を運んで、それを見つけるためにパケットに1秒(例えば、ルーティング)がダイレクトインストールを使用して、タグを使用するのを持って、少ししか理解できないように思えます。 私たちは効率/丈夫さ見返りの考慮に基づいて1かもう片方をするべきです。
Also, if there is a way of installing such flow-associated state, it makes sense to have only one, which all subsystems use, instead of building a separate one for each flow.
また、そのような流れで関連している状態をインストールする方法があれば、1つしか持たない意味になります、各流れのために別々のものを築き上げることの代わりに。(すべてのサブシステムが意味を使用します)。
It's a little difficult to make the choice between installation, and carrying a copy in each packet, without more information of exactly how much user state the network is likely to have in the future. (For instance, we might wind up with 500 byte headers if we include the full source route, resource reservation, etc., in every header.)
インストールと、各パケットでコピーを運ぶことの選択をするのは少し難しいです、ネットワークが将来ちょうどどのくらいのユーザ状態を持ちそうであるかに関する詳しい情報なしで。 (例えば、完全な送信元経路、資源予約などを入れるなら、私たちは500バイトのヘッダーをもって終わるかもしれません、すべてのヘッダーで。)
It's also difficult without consideration of the actual mechanisms involved. As a general principle, we wish to make recovery from a loss of state as local as possible, to limit the number of entities which have to become involved. (For instance, when a router crashes, traffic is rerouted around it without needing to open a new TCP connection.) The option of the "installation" looks a lot more attractive if it's simple, and relatively cheap, to reinstall the user state when a router crashes, without otherwise causing a lot of hassle.
また、それも実際のメカニズムのかかわった考慮なしで難しいです。 一般的な原則として、状態の損失からの回復をできるだけローカルにして、かかわるようにならなければならない実体の数を制限したいと思います。 (例えば、ルータがクラッシュすると、新しいTCP接続を開く必要はなくて、交通はそれの周りで別ルートで送られます。) それが簡単であるなら、「インストール」のオプションははるかに魅力的に見えます、そして、比較的安く、ルータであるときに、ユーザ状態を再インストールするのはクラッシュします、そうでなければ、多くの苦労を引き起こさないで。
Chiappa [Page 16] RFC 1753 Nimrod Technical Requirements for IPng December 1994
IPng1994年12月のためのChiappa[16ページ]RFC1753ニムロデ技術的要求事項
However, given the likely growth in user state, the necessity for service state, the requirement for reliable installation, and a number of similar considerations, it seems that direct installation of user state, and explicit recognition of flows, through a unified definition and tag mechanism in the packets, is the way to go, and this is the path that Nimrod has chosen.
しかしながら、ユーザ状態でのありそうな成長、サービス状態の必要性、信頼できるインストールのための要件、および多くの同様の問題を考えて、パケットの統一された定義とタグメカニズムを通したユーザ状態のダイレクトインストール、および流れの明示の承認が行く方法であり、これがニムロデが選んだ経路であるように思えます。
3.3 Specific Interaction Issues
3.3 特定の相互作用問題
Here is a very incomplete list of the things which Nimrod would like to see from the internetwork layer as a whole:
ここに、ニムロデが全体でインターネットワーク層から見たがっているものの非常に不完全なリストがあります:
- A unified definition of flows in the internetwork layer, and a
unified way of identifying, through a separate flow-id field, which
packets belong to a given flow.
- インターネットワーク層における流れの統一された定義、および別々の流れイド分野を通ってどのパケットが与えられた流れに属すかを特定する統一された方法。
- A unified mechanism (potentially distributed) for installing state
about flows (including multicast flows) in routers.
- 流れ(マルチキャスト流れを含んでいる)に関して状態をルータにインストールするための統一されたメカニズム(潜在的に分配されます)。
- A method for getting information about whether a given resource
allocation request has failed along a given path; this might be
part of the unified flow setup mechanism.
- 与えられた資源配分要求が与えられた経路に沿って失敗したかどうかの情報を得るためのメソッド。 これは統一された流れセットアップメカニズムの一部であるかもしれません。
- An interface to (potentially distributed) mechanism for maintaining
the membership in a multi-cast group.
- マルチキャストグループで会員資格を維持するための(潜在的に分配されています)のメカニズムへのインタフェース。
- Support for multiple interfaces; i.e., multi-homing. Nimrod does
this by decoupling transport identification (done via EID's) from
interface identification (done via locators). E.g., a packet with
any valid destination locator should be accepted by the TCP of an
endpoint, if the destination EID is the one assigned to that
endpoint.
- 複数のインタフェースのサポート。 すなわち、マルチホーミング。 デカップリング輸送識別(EIDを通して、する)でニムロデはインタフェース識別(ロケータを通して、する)からこれをします。 例えばどんな有効な目的地ロケータがあるパケットも終点のTCPによって受け入れられるはずです、目的地EIDがその終点に割り当てられたものであるなら。
- Support for multiple locators ("addresses") per network interface.
This is needed for a number of reasons, among them to allow for
less painful transitions in the locator abstraction hierarchy as
the topology changes.
- 複数のロケータには、1ネットワーク・インターフェースあたりの(「アドレス」)をサポートしてください。 これが、トポロジーが変化するとき、ロケータ抽象化階層構造でそれほど苦痛でない変遷を考慮するのにそれらの中で様々な意味で必要です。
- Support for multiple UID's ("addresses") per endpoint (roughly, per
host). This would definitely include both multiple multicast SID's,
and at least one unicast EID (the need for multiple unicast EID's
per endpoint is not obvious).
- 複数のUIDの1終点あたりの(「アドレス」)のサポート、(およそ、ホスト、) これは確実に複数のマルチキャストSIDのものと少なくとも1つのユニキャストのEIDの両方を含んでいるでしょう(1終点あたりの複数のユニキャストEIDの必要性は明白ではありません)。
- Support for distinction between a multicast group as a named
entity, and a multicast flow which may not reach all the members.
- 命名された実体としてのマルチキャストグループと、すべてのメンバーに届くかもしれないというわけではないマルチキャスト流動の区別のために、サポートします。
- A distributed, replicated, user name translation system (DNS?) that
maps such user names into (EID, locator0, ... locatorN) bindings.
- そのようなユーザを写像する分配されて、模写されたユーザ名前翻訳システム(DNS?)は(EID、locator0、…locatorN)と結合を命名します。
Chiappa [Page 17] RFC 1753 Nimrod Technical Requirements for IPng December 1994
IPng1994年12月のためのChiappa[17ページ]RFC1753ニムロデ技術的要求事項
Security Considerations
セキュリティ問題
Security issues are discussed in section 2.2.
セクション2.2で安全保障問題について議論します。
Author's Address
作者のアドレス
J. Noel Chiappa
J.クリスマスChiappa
Phone: (804) 898-8183 EMail: jnc@lcs.mit.edu
以下に電話をしてください。 (804) 898-8183 メールしてください: jnc@lcs.mit.edu
Chiappa [Page 18]
Chiappa[18ページ]
一覧
スポンサーリンク
