RFC1075 日本語訳
1075 Distance Vector Multicast Routing Protocol. D. Waitzman, C.Partridge, S.E. Deering. November 1988. (Format: TXT=54731 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. Waitzman
Request For Comments: 1075 C. Partridge
BBN STC
S. Deering
Stanford University
November 1988
Waitzmanがコメントのために要求するワーキンググループD.をネットワークでつないでください: 1075 C.ヤマウズラBBN STC S.デアリングスタンフォード大学1988年11月
Distance Vector Multicast Routing Protocol
ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル
1. Status of this Memo
1. このMemoの状態
This RFC describes a distance-vector-style routing protocol for routing multicast datagrams through an internet. It is derived from the Routing Information Protocol (RIP) [1], and implements multicasting as described in RFC-1054. This is an experimental protocol, and its implementation is not recommended at this time. Distribution of this memo is unlimited.
このRFCはルーティングマルチキャストデータグラムのためにインターネットを通して距離ベクトルスタイルルーティング・プロトコルについて説明します。 それは、ルーティング情報プロトコル(RIP)[1]から得られて、RFC-1054で説明されるようにマルチキャスティングを実行します。 これは実験プロトコルです、そして、実現はこのとき、推薦されません。 このメモの分配は無制限です。
2. Introduction
2. 序論
A draft standard for multicasting over IP networks now exists [2], but no routing protocols to support internetwork multicasting are available. This memo describes an experimental routing protocol, named DVMRP, that implements internetwork multicasting. DVMRP combines many of the features of RIP [1] with the Truncated Reverse Path Broadcasting (TRPB) algorithm described by Deering [3].
マルチキャスティングにおける、IPネットワークの上の標準の草稿は現在、存在します。[2]にもかかわらず、インターネットワークマルチキャスティングを支持するどんなルーティング・プロトコルも利用可能ではありません。 このメモはインターネットワークマルチキャスティングを実行するDVMRPという実験ルーティング・プロトコルについて説明します。 DVMRPはデアリング[3]によって説明されるTruncated Reverse Path Broadcasting(TRPB)アルゴリズムにRIP[1]の特徴の多くを結合します。
DVMRP is an "interior gateway protocol"; suitable for use within an autonomous system, but not between different autonomous systems. DVMRP is not currently developed for use in routing non-multicast datagrams, so a router that routes both multicast and unicast datagrams must run two separate routing processes. DVMRP is designed to be easily extensible and could be extended to route unicast datagrams.
DVMRPは「内部のゲートウェイプロトコル」です。 マルチキャストとユニキャストデータグラムの両方を発送するルータがルーティング非マルチキャストデータグラム2つの別々のルーティングの過程を走らせなければならなくて、使用のために開発されて、現在、使用に適するのは、異なった自律システムDVMRPではなく、自律システムの中のそうではありません。 DVMRPを容易に広げることができるように設計して、ユニキャストデータグラムを発送するために広げることができました。
DVMRP was developed to experiment with the algorithms in [3]. RIP was used as the starting point for the development because an implementation was available and distance vector algorithms are simple, as compared to link-state algorithms [4]. In addition, to allow experiments to traverse networks that do not support multicasting, a mechanism called "tunneling" was developed.
DVMRPは、[3]でアルゴリズムを実験するために開発されました。 実現が利用可能であり、距離ベクトルアルゴリズムが簡単であるので、RIPは開発に出発点として使用されました、リンク州のアルゴリズム[4]と比べて。 さらに、実験がマルチキャスティングを支持しないネットワークを横断するのを許容するために、「トンネリング」と呼ばれるメカニズムは開発されました。
The multicast forwarding algorithm requires the building of trees based on routing information. This tree building needs more state information than RIP is designed to provide, so DVMRP is much more complicated in some places than RIP. A link-state algorithm, which already maintains much of the state needed, might prove a better basis for Internet multicasting routing and forwarding.
マルチキャスト推進アルゴリズムはルーティング情報に基づく木のビルを必要とします。 RIPより多くの州の情報を必要性に築き上げるこの木が提供するように設計されているので、DVMRPはRIPより所々はるかに複雑です。 リンク州のアルゴリズム(既に状態の大部分が必要であったと主張する)はインターネットマルチキャスティングルーティングと推進の、より良い基礎を立証するかもしれません。
Waitzman, Partridge & Deering [Page 1] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[1ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
DVMRP differs from RIP in one very important way. RIP thinks in terms of routing and forwarding datagrams to a particular destination. The purpose of DVMRP is to keep track of the return paths to the source of multicast datagrams. To make explanation of DVMRP more consistent with RIP, the word "destination" is used instead of the more proper "source", but the reader must remember that datagrams are not forwarded to these destinations, but originate from them.
DVMRPは1つの非常に重要な方法でRIPと異なっています。 RIPはルーティングとデータグラムを進めることに関して特定の目的地と思います。 DVMRPの目的はマルチキャストデータグラムの源にリターンパスの動向をおさえることです。DVMRPに関する説明をRIPと、より一致するようにするのに、「目的地」という言葉は、より適切な「ソース」の代わりに使用されますが、読者は、データグラムがこれらの目的地に送られなかったのを覚えていなければなりませんが、それらから発してください。
This memo is organized into the following sections:
- A description of DVMRP is presented.
- Tunnels are explained.
- The routing algorithm is shown.
- The forwarding algorithm is shown.
- The various time values are listed.
- Configuration information is specified.
このメモは以下のセクションへまとめられます: - DVMRPの記述は提示されます。 - トンネルは説明されます。 - ルーティング・アルゴリズムは示されます。 - 推進アルゴリズムは示されます。 - 様々な時間的価値は記載されています。 - 設定情報は指定されます。
This memo does not analyze distance-vector routing, nor fully explain the distance-vector algorithm; see [1] for more information on these topics. The process or processes that perform the routing and forwarding functions are called "routers" in this memo.
このメモで、距離ベクトルルーティングを分析して、完全に距離ベクトルアルゴリズムがわかるというわけではありません。 これらの話題に関する詳しい情報のための[1]を見てください。 ルーティングと推進機能を実行する過程か過程がこのメモに「ルータ」と呼ばれます。
3. Protocol Description
3. プロトコル記述
DVMRP uses the Internet Group Management Protocol (IGMP) to exchange routing datagrams [2].
DVMRPは、ルーティングデータグラム[2]を交換するのに、インターネットGroup Managementプロトコル(IGMP)を使用します。
DVMRP datagrams are composed of two portions: a small, fixed length IGMP header, and a stream of tagged data.
DVMRPデータグラムは2つの部分で構成されます: 小さくて、固定された長さのIGMPヘッダー、およびタグ付けをされたデータのストリーム。
The fixed length IGMP header of DVMRP messages is:
DVMRPメッセージの固定長IGMPヘッダーは以下の通りです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Subtype | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |バージョン| タイプ| Subtype| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The version is 1.
バージョンは1です。
The type for DVMRP is 3.
DVMRPのためのタイプは3歳です。
The subtype is one of:
「副-タイプ」、以下が1つがあります。
1 = Response; the message provides routes to some destination(s).
2 = Request; the message requests routes to some destination(s).
3 = Non-membership report; the message provides non-membership
report(s).
1は応答と等しいです。 メッセージはいくつかの目的地にルートを提供します。 2=要求。 メッセージはいくつかの目的地にルートを要求します。 3=非会員資格レポート。 メッセージは非会員資格レポートを提供します。
Waitzman, Partridge & Deering [Page 2] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[2ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
4 = Non-membership cancellation; the message cancels previous
non-membership report(s).
4は非会員資格キャンセルと等しいです。 メッセージは前の非会員資格レポートを取り消します。
The checksum is the 16-bit one's complement of the one's complement sum of the entire message, excluding the IP header. For computing the checksum, the checksum field is zeroed.
IPヘッダーを除いて、チェックサムは全体のメッセージの1の補数合計の16ビットの1の補数です。 チェックサムを計算するのにおいて、チェックサム分野のゼロは合わせられています。
The rest of the DVMRP message is a stream of tagged data. The reason for using a stream of tagged data is to provide easy extensibility (new commands can be developed by adding new tags) and to reduce the amount of redundant data in a message. The elements in the stream, called commands, are multiples of 16 bits, for convenient alignment. The commands are organized as an eight bit command numeric code, with at least an eight bit data portion. Sixteen-bit alignment of all commands is required.
DVMRPメッセージの残りはタグ付けをされたデータのストリームです。 タグ付けをされたデータのストリームを使用する理由は、くつろいでいる伸展性(新しいタグを加えることによって、新しいコマンドを開発できる)を提供して、メッセージの冗長データの量を減少させることです。 コマンドと呼ばれる流れにおける要素は便利な整列のための16ビットの倍数です。 コマンドは8ビットのコマンド数字コードとして少なくとも8ビットのデータ部で組織化されます。 すべてのコマンドの16ビットの整列が必要です。
A message that has an error in it will be discarded at the point in processing where the error is detected. Any state changed due to the message contents before the error will not be restored to its previous values.
それに誤りを持っているメッセージは処理における誤りが検出されるポイントで捨てられるでしょう。 メッセージ内容のため、誤りが前の値に復元されない前に、どんな状態も変化しました。
Certain commands have default values defined in their specification. As the defaults may be changed as the protocol is developed further, a cautious implementation will not send out messages that depend on defaults.
あるコマンドには、それらの仕様に基づき定義されたデフォルト値があります。 さらにプロトコルを開発するときデフォルトを変えるとき、用心深い実現はデフォルトによるメッセージを出さないでしょう。
The length of DVMRP messages is limited to 512 bytes, excluding the IP header.
IPヘッダーを除いて、DVMRPメッセージの長さは512バイトに制限されます。
3.1 NULL Command
3.1 ヌルコマンド
Format: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 0 | | Ignored |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
形式: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | 0 | | 無視されます。| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Description: The NULL command can be used to provide additional alignment or padding to 32 bits.
記述: NULLコマンドは、追加整列を提供するのに使用されるか、または32ビットにそっと歩くことであることができます。
3.2 Address Family Indicator (AFI) Command
3.2 アドレス家族インディケータ(AFI)コマンド
Format: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 2 | | family |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
形式: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | 2 | | 家族| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Waitzman, Partridge & Deering [Page 3] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[3ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
Values for family:
家族のための値:
2 = IP address family, in which addresses are 32 bits long.
2はIPアドレス家族と等しいです。(そこでは、アドレスが長さ32ビットです)。
Default: Family = 2.
デフォルト: 家族=2。
Description: The AFI command provides the address family for subsequent addresses in the stream (until a different AFI command is given).
記述: AFIコマンドは流れでアドレス家族をその後のアドレスに提供します(異なったAFIコマンドを与えるまで)。
It is an error if the receiver does not support the address family.
受信機がアドレス家族を養わないなら、それは誤りです。
3.3 Subnetmask Command
3.3 Subnetmaskコマンド
Format: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 3 | | count |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
形式: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | 3 | | カウント| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Additional argument, with AFI = IP:
AFI=IPとの追加議論:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subnet mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブネットマスク| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Count is 0 or 1.
カウントは、0か1です。
Default: Assume that following routes are to networks, and use a mask of the network mask of each route's destination.
デフォルト: ネットワークには次のルートがあると仮定してください、そして、各ルートの目的地のネットワークマスクのマスクを使用してください。
Description: The Subnetmask command provides the subnet mask to use for subsequent routes. There are some requirements on the bits in the subnetmask: bits 0 through 7 must be 1, and all of the bits must not be 1.
記述: Subnetmaskコマンドはその後のルートに使用するサブネットマスクを提供します。 ビットに関するいくつかの要件が「副-ネットマスク」にあります: ビット0〜7は1であるに違いありません、そして、優にビットは1であるはずがありません。
If the count is 0, then no subnet mask applies, assume that the following routes are to networks, and use a mask of the network mask of each route's destination. If count is 1, then a subnet mask should be in the data stream, of an appropriate size given the address family.
カウントが0、次に、サブネットマスクが全く適用されないということであるなら、ネットワークには以下のルートがあると仮定してください、そして、各ルートの目的地のネットワークマスクのマスクを使用してください。 カウントが1であるなら、サブネットマスクはアドレス家族に与えられた適切なサイズのデータ・ストリーム中であるはずです。
It is an error for count not to equal 0 or 1.
それはカウントが0か1と等しくない誤りです。
Subnetmasks should not be sent outside of the appropriate network.
適切なネットワークの外にSubnetmasksを送るべきではありません。
See [6] for more information regarding IP subnetting.
IPサブネッティングに関する詳しい情報のための[6]を見てください。
Waitzman, Partridge & Deering [Page 4] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[4ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
3.4 Metric Command
3.4 メートル法のコマンド
Format: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 4 | | value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
形式: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | 4 | | 値| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Value is the metric, as an unsigned value ranging from 1 to 255.
値は1〜255まで及ぶ無記名の値としてメートル法です。
Default: None.
デフォルト: なし。
Description: The metric command provides the metric to subsequent destinations. The metric is relative to the router that sent this DVMRP routing update.
記述: メートル法のコマンドはその後の目的地へのメートル法を提供します。 メートル法はこのDVMRPルーティングアップデートを送ったルータに比例しています。
It is an error for metric to equal 0.
それが誤りである、0と等しいためにはメートル法
3.5 Flags0 Command
3.5 Flags0コマンド
Format: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 5 | | value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
形式: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | 5 | | 値| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Meaning of bits in value:
値におけるビットの意味:
Bit 7: Destination is unreachable.
Bit 6: Split Horizon concealed route.
ビット7: 目的地は手が届きません。 ビット6: 分裂Horizonはルートを隠しました。
Default: All bits zero.
デフォルト: ビットが合っているゼロすべて。
Description: The flags0 command provides a way to set a number of flags. The only defined flags, bits 6 and 7, can be used to provide more information about a route with a metric of infinity. A router that receives a flag that it does not support should ignore the flag. The command is called flags0 to permit the definition of additional flag commands in the future (flags1, etc.).
記述: flags0コマンドは多くの旗を設定する方法を提供します。 無限におけるメートル法のaをルートに関する詳しい情報に提供するのに、唯一の定義された旗(ビット6と7)を使用できます。 それが支えない旗を受けるルータは旗を無視するべきです。 コマンドは、将来(flags1など)追加旗のコマンドの定義を可能にするためにflags0と呼ばれます。
This is an experimental command, and may be changed in the future.
これを実験的なコマンドであり、将来、変えるかもしれません。
3.6 Infinity Command
3.6 無限コマンド
Format: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 6 | | value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
形式: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | 6 | | 値| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Value is the infinity, as an unsigned value ranging from 1 to 255.
値は1〜255まで及ぶ無記名の値として無限です。
Waitzman, Partridge & Deering [Page 5] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[5ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
Default: Value = 16.
デフォルト: =16を評価してください。
Description: The infinity command defines the infinity for subsequent metrics in the stream.
記述: 無限コマンドはその後の測定基準のために流れで無限を定義します。
It is an error for infinity to be zero, or less than the current metric.
それは電流より無限がゼロ、または以下である誤りです。メートル法。
3.7 Destination Address (DA) Command
3.7 送付先アドレス(DA)コマンド
Format: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 7 | | count |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
形式: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | 7 | | カウント| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Array of 'count' additional arguments, with AFI = IP:
'数えてください'という追加議論、AFI=で、IPを整列させてください:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目的地Address1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目的地Address2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Count is the number of addresses supplied, from 1 to 255. The length of the addresses depends upon the current address family. The number of addresses supplied is subject to the message length limitation of 512 bytes.
カウントは1〜255まで供給されたアドレスの数です。 アドレスの長さは現在のアドレス家族に頼っています。 供給されたアドレスの数は512バイトのメッセージ長制限を受けることがあります。
Default: None.
デフォルト: なし。
Description: The DA command provides a list of destinations. While this format can express routes to hosts, the routing algorithm only supports network and subnetwork routing. The current metric, infinity, flags0 and subnetmask, when combined with a single destination address, define a route. The current metric must be less than or equal to the current infinity.
記述: DAコマンドは目的地のリストを提供します。 この形式はルートをホストに言い表すことができますが、ルーティング・アルゴリズムはネットワークとサブネットワークルーティングをサポートするだけです。 電流メートル法であり、ただ一つの送付先アドレスに結合されると、無限、flags0、および「副-ネットマスク」はルートを定義します。 現在のメートル法の必須は、よりそう以下です。現在の無限。
It is an error for count to equal 0.
それはカウントが0と等しい誤りです。
Waitzman, Partridge & Deering [Page 6] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[6ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
3.8 Requested Destination Address (RDA) Command
3.8 要求された送付先アドレス(RDA)コマンド
Format: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 8 | | count |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
形式: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | 8 | | カウント| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Array of 'count' additional arguments, with AFI = IP:
'数えてください'という追加議論、AFI=で、IPを整列させてください:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Destination Address1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 要求された目的地Address1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Destination Address2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 要求された目的地Address2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Count is the number of addresses supplied, from 0 to 255. The length of the addresses depends upon the current address family. The number of addresses supplied is subject to the message length limitation of 512 bytes.
カウントは0〜255まで供給されたアドレスの数です。 アドレスの長さは現在のアドレス家族に頼っています。 供給されたアドレスの数は512バイトのメッセージ長制限を受けることがあります。
Default: None.
デフォルト: なし。
Description: The RDA command provides a list of destinations for whom routes are requested. A routing request for all routes is encoded by using a count = 0.
記述: RDAコマンドはルートが要求されている目的地のリストを提供します。 すべてのルートを求めるルーティング要求は、カウント=0を使用することによって、コード化されます。
3.9 Non Membership Report (NMR) Command
3.9 非会員資格レポート(NMR)コマンド
Format: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 9 | | count |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
形式: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | 9 | | カウント| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Array of 'count' additional arguments, with AFI = IP:
'数えてください'という追加議論、AFI=で、IPを整列させてください:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Address1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マルチキャストAddress1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Waitzman, Partridge & Deering [Page 7] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[7ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Down Time1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time1を押さえてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Address2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マルチキャストAddress2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hold Down Time2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time2を押さえてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Count is the number of Multicast Address and Hold Down Time pairs supplied, from 1 to 255. The length of the addresses depends upon the current address family. The number of pairs supplied is subject to the message length limitation of 512 bytes.
カウントは組が1〜255まで供給したMulticast AddressとHold Down Timeの数です。 アドレスの長さは現在のアドレス家族に頼っています。 供給された組の数は512バイトのメッセージ長制限を受けることがあります。
Default: None.
デフォルト: なし。
Description: The NMR command is experimental, and has not been tested in an implementation. Each multicast address and hold down time pair is called a non-membership report. The non-membership report tells the receiving router that the sending router has no descendent group members in the given group. Based on this information the receiving router can stop forwarding datagrams to the sending router for the particular multicast address(es) listed. The hold down time indicates, in seconds, how long the NMR is valid.
記述: NMRコマンドは、実験的であり、実現でテストされていません。 それぞれのマルチキャストアドレスと抑制時間組は非会員資格レポートと呼ばれます。 非会員資格レポートは、与えられたグループにはどんな下降のグループのメンバーも送付ルータにいないと受信ルータに言います。 この情報に基づいて、受信ルータは、アドレス(es)が記載した特定のマルチキャストのために送付ルータにデータグラムを送るのを止めることができます。 抑制時間は、秒にNMRがどれくらい長い間有効であるかを示します。
It is an error for count to equal 0.
それはカウントが0と等しい誤りです。
The only other commands in a message that has NMR commands can be the AFI, flags0, and NULL commands. No relevant flags for the flags0 command are currently defined, but that may change in the future.
NMRコマンドを持っているメッセージにおける他の唯一のコマンドが、AFIと、flags0と、NULLコマンドであるかもしれません。 flags0コマンドのためのどんな関連旗も現在、定義されませんが、それは将来、変化するかもしれません。
3.10 Non Membership Report Cancel (NMR Cancel) Command
3.10 非会員資格レポートキャンセル(NMRは取り消す)命令
Format: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| 10 | | count |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
形式: 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | 10 | | カウント| +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Waitzman, Partridge & Deering [Page 8] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[8ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
Array of 'count' additional arguments, with AFI = IP:
'数えてください'という追加議論、AFI=で、IPを整列させてください:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Address1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マルチキャストAddress1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Address2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マルチキャストAddress2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Count is the number of Multicast Addresses supplied, from 1 to 255. The length of the addresses depends upon the current address family. The number of addresses supplied is subject to the message length limitation of 512 bytes.
カウントは1〜255まで供給されたMulticast Addressesの数です。 アドレスの長さは現在のアドレス家族に頼っています。 供給されたアドレスの数は512バイトのメッセージ長制限を受けることがあります。
Default: None.
デフォルト: なし。
Description: The NMR Cancel command is experimental, and has not been tested in an implementation. For each multicast address listed, any previous corresponding non-membership reports are canceled. When there is no corresponding non-membership report for a given multicast address, the Cancel command should be ignored for that multicast address.
記述: NMRキャンセル命令は、実験的であり、実現でテストされていません。 アドレスが記載した各マルチキャストにおいて、前のどんな対応する非会員資格レポートも取り消されます。 与えられたマルチキャストアドレスのためのどんな対応する非会員資格レポートもないとき、キャンセル命令はそのマルチキャストアドレスのために無視されるべきです。
It is an error for count to equal 0.
それはカウントが0と等しい誤りです。
The only other commands in a message that has NMR Cancel commands can be the AFI, flags0, and NULL commands. No relevant flags for the flags0 command are currently defined, but that may change in the future.
NMRキャンセル命令を持っているメッセージにおける他の唯一のコマンドが、AFIと、flags0と、NULLコマンドであるかもしれません。 flags0コマンドのためのどんな関連旗も現在、定義されませんが、それは将来、変化するかもしれません。
3.12 Examples (with bytes in '{}'), not including the message header:
3.12の例、(中のバイト、'、'、)、メッセージヘッダーを含んでいません:
3.12.1 Supplying a single route to the IP address 128.2.251.231 with a metric of 2, an infinity of 16, a subnetmask of 255.255.255.0:
3.12.1 ただ一つのルートをIPアドレスに供給する、128.2、.251、.231、2、16、aの無限におけるメートル法のaで、.255が255.255をsubnetmaskしている、.0:
Subtype 1,
AFI 2, Metric 2, Infinity 16, Subnet Mask 255.255.255.0
{2} {2} {4} {2} {6} {16} {3} {1} {255} {255} {255} {0}
Subtype1、AFI2、メートル法の2、無限16、サブネットマスク255.255.255、.0、2、2、4、2、6、16、3、1、255、255、255{0}
DA Count=1 [128.2.251.231]
{7} {1} {128} {2} {251} {231}
DAが=1を数える、[128.2、.251、.231]、7、1、128、2、251{231}
Waitzman, Partridge & Deering [Page 9] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[9ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
3.12.2 Supplying a route to the IP addresses 128.2.251.231 and 128.2.236.2 with a metric of 2, an infinity of 16, a subnetmask of 255.255.255.0:
3.12.2 aを供給して、IPアドレス128.2.251に.231と128.2を発送してください、.236、.2、2、16、aの無限におけるメートル法のaで、.255が255.255をsubnetmaskしている、.0:
Subtype 1,
AFI 2, Metric 2, Infinity 16, Subnet Mask 255.255.255.0
{2} {2} {4} {2} {6} {16} {3} {1} 255} {255} {255} {0}
Subtype1、AFI2、メートル法の2、無限16、サブネットマスク255.255.255、.0、2、2、4、2、6、16、3、1、255 {255} {255} {0}
DA Count=2 [128.2.251.231] [128.2.236.2]
{7} {1} {128} {2} {251} {231} {128} {2} {236} {2}
DAが=2を数える、[128.2、.251、.231]、[128.2、.236、.2]、7、1、128、2、251、231、128、2、236{2}
3.12.3 Request for all routes to IP destinations.
3.12.3 すべてを求める要求は目的地をIPに発送します。
Subtype 2, AFI 2, RDA Count = 0
{2} {2} {8} {0}
Subtype2、AFI2、RDAカウント=0 2 2 8{0}
3.12.4 Non Membership Report for groups 224.2.3.1 and 224.5.4.6 with a hold down time of 20 seconds, and group 224.7.8.5 with a hold down time of 40 seconds.
3.12.4 グループ224.2.3のための非Membership Report.1と224.5、20の抑制時間がある.6が後援する.4、およびグループ、224.7、.8、.5、40秒の抑制時間で。
Subtype 3,
AFI 2, NMR Count = 3 [224.2.3.1, 20]
{2} {2} {10} {3} {224} {2} {3} {1} {0} {0} {0} {20}
Subtype3、AFI2、NMRが=3を数える、[224.2、.3、.1、20]、2、2、10、3、224、2、3、1、0、0、0{20}
[224.5.4.6, 20] [224.7.8.5, 40]
{224} {5} {4} {6} {0} {0} {0} {20} {224} {7} {8} {5} {0} {0} {0} {40}
[224.5.4.6, 20] [224.7.8.5, 40] {224} {5} {4} {6} {0} {0} {0} {20} {224} {7} {8} {5} {0} {0} {0} {40}
3.13 Summary of Commands
3.13 コマンドの概要
Value Name Other commands allowed in same message
----- ---- ---------------------------------------
0 Null Null, AFI, Subnetmask, Metric, Flags0,
Infinity, DA, RDA, NMR, NMR-cancel
同じメッセージに許容された値のName Otherコマンド----- ---- --------------------------------------- 0のヌルヌル、AFI、Flags0(無限、DA、RDA、NMR)がNMR取り消すメートル法のSubnetmask
2 AFI Null, AFI, Subnetmask, Metric, Flags0,
Infinity, DA, RDA, NMR, NMR-cancel
2AFIヌル、AFI、Flags0(無限、DA、RDA、NMR)がNMR取り消すメートル法のSubnetmask
3 Subnetmask Null, AFI, Subnetmask, Metric, Flags0,
Infinity, DA, RDA
Flags0、3がメートル法であることでヌル、AFI、SubnetmaskをSubnetmaskする、無限、DA、RDA
4 Metric Null, AFI, Subnetmask, Metric, Flags0,
Infinity, DA
4のメートル法のヌル、AFI、メートル法のSubnetmask、Flags0、無限、DA
5 Flags0 Null, AFI, Subnetmask, Metric, Flags0,
Infinity, DA
5Flags0ヌル、AFI、メートル法のSubnetmask、Flags0、無限、DA
Waitzman, Partridge & Deering [Page 10] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[10ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
6 Infinity Null, AFI, Subnetmask, Metric, Flags0,
Infinity, DA
6無限ヌル、AFI、メートル法のSubnetmask、Flags0、無限、DA
7 DA Null, AFI, Subnetmask, Metric, Flags0,
Infinity, DA
7DAヌル、AFI、メートル法のSubnetmask、Flags0、無限、DA
8 RDA Null, AFI, Subnetmask, Flags0, RDA
8RDAヌル、AFI、Subnetmask、Flags0、RDA
9 NMR Null, AFI, Flags0, NMR
9NMRヌル、AFI、Flags0、NMR
10 NMR-cancel Null, AFI, Flags0, NMR-cancel
10NMR-キャンセルヌル、AFI、Flags0、NMRキャンセル
4. Tunnels
4. Tunnels
A tunnel is a method for sending datagrams between routers separated by gateways that do not support multicasting routing. It acts as a virtual network between two routers. For instance, a router running at Stanford, and a router running at BBN might be connected with a tunnel to allow multicast datagrams to traverse the Internet. We consider tunnels to be a transitional hack.
トンネルは、マルチキャスティングルーティングを支持しないゲートウェイによって切り離されたルータの間にデータグラムを送るための方法です。 それは2つのルータの間の仮想ネットワークとして機能します。 例えばBBNでのルータ走行がインターネットを横断するのをマルチキャストデータグラムを許容するためにトンネルに接続されるかもしれないスタンフォード、およびaを走るルータ。 私たちは、トンネルが過渡的なハッキングであると考えます。
Tunneling is done with a weakly encapsulated normal multicasted datagram. The weak encapsulation uses a special two element IP loose source route [5]. (This form of encapsulation is preferable to "strong" encapsulation, i.e., prepending an entire new IP header, because it does not require the tunnel end-points to know each other's maximum reassembly buffer size. It also has the benefit of correct behavior of the originator's time-to-live value and any other IP options present.)
トンネリングはaが弱々しく要約されている状態でして、標準がデータグラムをmulticastedしたということです。 弱いカプセル化は特別な2要素IPゆるい送信元経路[5]を使用します。 (すなわち、このフォームのカプセル化は全体の新しいIPヘッダーをprependingしながら、「強い」カプセル化より望ましいです、互いの最大の再アセンブリバッファサイズを知るのがトンネルエンドポイントを必要としないので。 また、それには、創始者の生きる時間値といかなる他のIPオプションプレゼントの正しい動きの恩恵もあります。)
A tunnel has a local end-point, remote end-point, metric, and threshold associated with it. The routers at each end of the tunnel need only agree upon the local and remote end-points. See section 8 for information on how tunnels are configured. Because the number of intermediate gateways between the end-points of a tunnel is unknown, additional research is needed to determine appropriate metrics and thresholds.
トンネルには、リモート終わりポイントの、そして、メートル法の地方のエンドポイント、およびそれに関連している敷居があります。 トンネルの各端のルータは地方の、そして、リモートなエンドポイントに同意するだけでよいです。 トンネルがどう構成されるかの情報に関してセクション8を見てください。 トンネルのエンドポイントの間の中間ゲートウェイの数が未知であるので、追加研究が適切な測定基準と敷居を決定するのに必要です。
To send a datagram on a tunnel, the following occurs:
データグラムをトンネルに送るために、以下は起こります:
- A null IP option is inserted into the datagram. This provides
preferred alignment for the loose source route IP option.
- ヌルIPオプションはデータグラムに挿入されます。 これはゆるい送信元経路IPオプションのための都合のよい整列を提供します。
- A two element loose source route IP option is inserted into
the datagram.
- 2の要素のゆるい送信元経路IPオプションはデータグラムに挿入されます。
- The source route pointer is set to point to the second element
- 送信元経路ポインタが2番目の要素を示すように設定されます。
Waitzman, Partridge & Deering [Page 11] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[11ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
in the source route.
送信元経路で。
- The first element in the source route is replaced with the
address of the originating host (the original IP source
address).
- 送信元経路における最初の要素を送信元ホスト(オリジナルのIPソースアドレス)のアドレスに取り替えます。
- The second element in the source route is replaced with the
multicast destination address provided by the originating host
(the original IP destination address).
- 送信元経路における2番目の要素を送信元ホスト(オリジナルの受信者IPアドレス)によって提供されるマルチキャスト送付先アドレスに取り替えます。
- The IP source address is replaced with the address of the
router's appropriate outgoing physical interface (the local
tunnel end-point).
- IPソースアドレスをルータの適切な外向的な物理インターフェース(地方のトンネルエンドポイント)のアドレスに取り替えます。
- The IP destination address is replaced with an address of the
remote router (the remote tunnel end-point).
- 受信者IPアドレスをリモートルータ(リモートトンネルエンドポイント)のアドレスに取り替えます。
- The datagram is transmitted to the remote router using
non-multicast routing algorithms.
- データグラムは、非マルチキャストルーティング・アルゴリズムを使用することでリモートルータに送られます。
Intermediate, non-multicast gateways will route the tunneled datagram to the remote tunnel end-point. Because the datagram's IP source address has been replaced with the address of the local tunnel end- point, ICMP error messages will go to the originating multicast router. This behavior is desired, because a host that sends a multicast datagram, which a multicast router decides to tunnel, should not be aware of the use of the tunnel. If the datagram's IP source address were not changed when encapsulating the datagram, any ICMP errors would be sent to the originating host.
中間的で、非マルチキャストのゲートウェイはリモートトンネルエンドポイントにトンネルを堀られたデータグラムを発送するでしょう。 データグラムのIPソースアドレスをポイント、ICMPエラーメッセージがそうする地方のトンネル終わりのアドレスに取り替えたので、由来しているマルチキャストルータに行ってください。 この振舞いは望まれています、マルチキャストルータがトンネルを堀ると決めるマルチキャストデータグラムを送るホストがトンネルの使用を意識しているべきでないので。 データグラムを要約するとき、データグラムのIPソースアドレスを変えないなら、どんなICMP誤りも送信元ホストに送るでしょうに。
When the remote tunnel end-point receives the tunneled datagram, the following occurs:
リモートトンネルエンドポイントがトンネルを堀られたデータグラムを受けるとき、以下は起こります:
- The IP source address is replaced with the first element in the
loose source route.
- IPソースアドレスをゆるい送信元経路における最初の要素に取り替えます。
- The IP destination address is replaced with the second element
in the loose source route.
- 受信者IPアドレスをゆるい送信元経路における2番目の要素に取り替えます。
- The null option and the loose source route option are removed
from the datagram. This is needed because a host should not
be able to tell that it has received a datagram that was sent
through a tunnel.
- データグラムからヌルオプションとゆるい送信元経路オプションを取り除きます。 ホストが、トンネルを通して送られたデータグラムを受けたと言うことができないべきであるので、これが必要です。
Because no specific network is associated with a tunnel, there are no local group memberships to be tracked for a tunnel. The only neighbor on a tunnel can be the remote end-point. Routing messages should be exchanged through tunnels, but a route is not created for a
どんな特定のネットワークもトンネルに関連していないので、トンネルに追跡されるために、地域団体会員資格は全くありません。 トンネルの上の唯一の隣人がリモート終わりポイントであるかもしれません。 トンネルを通ってルーティング・メッセージを交換するべきですが、aのためにルートを作成しません。
Waitzman, Partridge & Deering [Page 12] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[12ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
tunnel. The routing messages should be sent as unicast datagrams directly to the remote tunnel end-point; they should not use an IP loose source route.
トンネルを堀ってください。 ユニキャストデータグラムとして直接リモートトンネルエンドポイントにルーティング・メッセージを送るべきです。 彼らはIPのゆるい送信元経路を使用するべきではありません。
Justification for using the loose source route and record option for tunneling:
ゆるい送信元経路を使用するための正当化とトンネリングのための記録的なオプション:
We considered defining our own IP option to handle tunneling, but
we are worried that intermediate gateways do not transparently
pass IP options that are unknown to them. Datagrams using a new
option would not traverse the Internet. It would be better for us
if we could create a new IP option, but it won't work presently.
Recall that this is a transition design to allow us to experiment
in the current environment.
トンネリングを扱うために私たち自身のIPオプションを定義すると考えましたが、私たちは中間ゲートウェイが透明にそれらにおいて、未知であることのIPオプションに合格しないのが心配です。 新しいオプションを使用するデータグラムがインターネットを横断しないでしょう。 私たちが新しいIPオプションを作成できるなら、私たちには、より良いでしょうにが、それは現在、働かないでしょう。 これが変遷デザインであると思い出して、私たちが現在の環境を実験するのを許容してください。
The tunneled packet containing the LSRR option has the following
features:
LSRRオプションを含むトンネルを堀られたパケットは以下の特徴を持っています:
Field Value
----- --------------------
src address = src gateway address
dst address = dst gateway address
LSRR pointer = points to LSRR address 2
LSRR address 1 = src host
LSRR address 2 = multicast destination
分野値----- -------------------- dstゲートウェイアドレスLSRR srcゲートウェイアドレスdst srcアドレス=アドレス=ポインタ=はsrcホストLSRRアドレス2=マルチキャストLSRRアドレス2LSRRアドレス1=目的地を示します。
Two questions raised about using the LSRR option for tunnels are
"Can intermediate gateways ignore the option?", and "Can the
destination gateway properly detect that the LSRR is used for a
tunnel?".
目的地ゲートウェイは適切にそれを検出できます。そして、トンネルにLSRRオプションを使用することに関して引き起こされた2つの疑問が「中間ゲートウェイはオプションを無視できますか?」である、「LSRRがトンネルに使用されるか、」
When an intermediate gateway receives a datagram, it examines the
destination address. For a tunneled datagram, the destination
address will not match an address of the receiving gateway.
Therefore, the LSRR option will not be examined, and the
intermediate gateway will forward the datagram on to its next hop
for the destination address.
中間ゲートウェイがデータグラムを受けるとき、それは送付先アドレスを調べます。 トンネルを堀られたデータグラムに関しては、送付先アドレスは受信ゲートウェイのアドレスに合わないでしょう。 したがって、LSRRオプションは調べられないでしょう、そして、中間ゲートウェイは送付先アドレスのために次のホップにデータグラムを送るでしょう。
When the destination gateway receives a datagram, it notes that
the datagram destination address matches one of its own address.
It will then look at the next LSRR option address, since the
source route is not exhausted. That address is a multicast
address. Since hosts are forbidden from putting multicast
addresses into source routes, the gateway can infer that the LSRR
is for tunneling. The weakness here is that perhaps there is some
other meaning for the multicast address in the LSRR. No other
meaning is currently defined.
目的地ゲートウェイがデータグラムを受けるとき、それは、データグラム送付先アドレスがそれ自身のアドレスの1つに合っていることに注意します。 そして、送信元経路が消耗していないので、それは次のLSRRオプションアドレスを見るでしょう。 そのアドレスはマルチキャストアドレスです。 ホストがマルチキャストアドレスを送信元経路に入れるので禁じられるので、ゲートウェイは、LSRRがトンネリングのためのものであると推論できます。 ここの弱点はLSRRのマルチキャストアドレスのためのある他の意味が恐らくあるということです。 いいえ他の意味は現在、定義されます。
Waitzman, Partridge & Deering [Page 13] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[13ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
If a tunneled datagram is by error addressed to a destination
gateway that does not support multicasting, then the destination
gateway will try to find a route to the multicast address. This
will fail, and an ICMP destination unreachable error message will
be sent to the tunneled datagram's source. Since the source
address in the tunneled datagram has been adjusted to be the
address of the source multicast gateway, the ICMP errors will not
go to the originating host, which has no knowledge of tunnels.
トンネルを堀られたデータグラムがマルチキャスティングを支持しない目的地ゲートウェイに記述された誤りであると、目的地ゲートウェイはマルチキャストアドレスにルートを見つけようとするでしょう。 これは失敗するでしょう、そして、ICMPの目的地の手の届かないエラーメッセージをトンネルを堀られたデータグラムのソースに送るでしょう。 トンネルを堀られたデータグラムのソースアドレスがソースマルチキャストゲートウェイのアドレスになるように調整されたので、ICMP誤りは送信元ホストのものにならないでしょう。(その送信元ホストは、トンネルに関する知識を全く持っていません)。
5. Routing Algorithm
5. ルーティング・アルゴリズム
This section provides a terse description of the distance-vector routing algorithm. See [1] for more information.
このセクションは距離ベクトルルーティング・アルゴリズムの簡潔な記述を提供します。 詳しい情報のための[1]を見てください。
While DVMRP can express routes to individual hosts, the forwarding and routing algorithms only support network and subnetwork routing.
DVMRPが個々のホストにルートを言い表すことができる間、推進とルーティング・アルゴリズムはネットワークとサブネットワークルーティングをサポートするだけです。
In the discussion below, the term "virtual interface" is used to refer to a physical interface or a tunnel local end-point. A physical interface is a network interface, for instance, an Ethernet card. A route to a destination will be through a virtual interface. The term "virtual network" is used to refer to a physical network or a tunnel, with the qualification that routes only reference physical networks.
以下での議論では、「仮想インターフェース」という用語は、物理インターフェースかトンネルの地方のエンドポイントについて言及するのに使用されます。 物理インターフェースはネットワーク・インターフェース、例えば、イーサネットカードです。 仮想インターフェースを通して目的地へのルートがあるでしょう。 「仮想ネットワーク」という用語は物理ネットワークかトンネルを示すのに使用されます、参照物理ネットワークだけを発送する資格で。
The TRPB algorithm forwards multicast datagrams by computing the shortest (reverse) path tree from the source (physical) network to all possible recipients of the datagram. Each multicast router must determine its place in the tree, relative to the particular source, and then determine which of its virtual interfaces are in the shortest path tree. The datagram is forwarded out these virtual interfaces. The process of excluding virtual interfaces not in the shortest path tree is called "pruning."
TRPBアルゴリズムは、ソースの(物理的)のネットワークから可能なデータグラムのすべての受取人まで最も低い(逆の)経路木を計算することによって、マルチキャストデータグラムを進めます。 それぞれのマルチキャストルータは、木で特定のソースに比例して場所を決定して、次に、仮想インターフェースのどれが最短パス木にあるかを決定しなければなりません。 これらの仮想インターフェースからデータグラムを進めます。 仮想のインタフェースを除くプロセスは最短パス木に「刈り込み」と呼ばれません。
Consider a virtual network. Using Deering's terminology [3], a router is called the "parent" of the virtual network if that router is responsible for forwarding datagrams onto that virtual network through its connecting virtual interface. The virtual network can also be considered a "child" virtual network of the router. Using the child information, routers can do Reverse Path Broadcasting (RPB).
仮想ネットワークを考えてください。 デアリングの用語[3]を使用して、そのルータが接続仮想インターフェースを通してその仮想ネットワークにデータグラムを送るのに原因となるなら、ルータは仮想ネットワークの「親」と呼ばれます。 また、ルータの「子供」仮想ネットワークであると仮想ネットワークを考えることができます。 子供情報を使用して、ルータはReverse Path Broadcasting(RPB)ができます。
Unnecessary datagrams may still be sent onto some networks, because there might not be any recipients for those datagrams on the networks. There are two kinds of recipients: hosts that are members of a particular multicast group, and multicast routers. If no multicast routers on a virtual network consider that virtual network uptree to a given source, then that virtual network is a "leaf"
まだ不要なデータグラムをいくつかのネットワークに送るかもしれません、ネットワークのそれらのデータグラムのためのどんな受取人もいないかもしれないので。 2種類の受取人がいます: 特定のマルチキャストグループ、およびマルチキャストルータのメンバーであるホスト。 仮想ネットワークでマルチキャストルータでないなら、その仮想ネットワークがuptreeであると与えられたソースと考えてください、仮想ネットワークが「葉」であるその時
Waitzman, Partridge & Deering [Page 14] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[14ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
network. If a network is a leaf for a given source, and there are no members of a particular group on the network, then there are no recipients for datagrams from the source to the group on that network. That network's parent router can forgo sending those datagrams on that network, or "truncate" the shortest path tree. The algorithm that tracks and uses this information is the Truncated Reverse Path Broadcasting (TRPB) algorithm.
ネットワークでつなぎます。 ネットワークが与えられたソースへの葉であり、ネットワークに関する特定のグループのメンバーが全くいなければ、ソースからグループまでデータグラムのための受取人は全くそのネットワークの一員ではありません。 そのネットワークの親ルータは、それらのデータグラムをそのネットワークに送るのを差し控えるか、または最短パス木に「先端を切らせることができます」。 この情報を追跡して、使用するアルゴリズムはTruncated Reverse Path Broadcasting(TRPB)アルゴリズムです。
Determining which virtual networks are leaves is not simple. If any neighboring router considers a given virtual network in the path to a given destination, then the virtual network is not a leaf. Otherwise, it is a leaf. This is a voting function. If a route, with a metric poisoned by split horizon processing, is sent by some router, then that router uses that virtual network as the uptree path for that route (i.e. that router votes that the virtual network is not a leaf relative to the route's destination). Since the number of routers on a virtual network is dynamic, and since all received routing updates are not kept by routers, a heuristic is needed to determine when a network is a leaf. DVMRP samples the routing updates on a virtual interface while a hold down timer is running, which is for a time period of LEAF_TIMEOUT seconds. There is one hold down timer per virtual interface. If a route is received with a metric poisoned by split horizon processing while the hold down timer is running, or at any other time, then the appropriate virtual interface for that route is "spoiled"-- it is not a leaf. For every route, any virtual interface that was not spoiled by the time the hold down timer expires is considered a leaf.
どの仮想ネットワークが葉であるかを決定するのは簡単ではありません。 何か隣接しているルータが経路で与えられた目的地と与えられた仮想ネットワークを考えるなら、仮想ネットワークは葉ではありません。 さもなければ、それは葉です。 これは票の機能です。 分かれているメートル法の当たっている地平線処理と共に何らかのルータでルートを送るなら、そのルータはそのルートにuptree経路としてその仮想ネットワークを使用します(すなわち、そのルータは、仮想ネットワークがルートの目的地に比例した葉でないのに投票します)。 仮想ネットワークのルータの数がダイナミックであり、すべての容認されたルーティングアップデートがルータで保たれるというわけではないので、ヒューリスティックがいつネットワークが葉であるかを決定するのに必要です。 抑制タイマ(LEAF_TIMEOUT秒の期間、ある)が動いている間、DVMRPは仮想インターフェースに関するルーティング最新情報を抽出します。 1仮想インターフェースあたり1個の抑制タイマがあります。 タイマの下側への保持が稼働している間の分かれているメートル法の当たっている地平線処理か、他の時ならいつでもにルートを受け取るなら、そのルートへの適切な仮想インターフェースを「損ないます」--それは葉ではありません。 あらゆるルートにおいて、タイマの下側への保持が期限が切れる時までに損なわれなかった少しの仮想インターフェースも葉であると考えられます。
For a description of an even better forwarding algorithm, the Reverse Path Multicasting algorithm, see [3].
さらに良い推進アルゴリズム、Reverse Path Multicastingアルゴリズムの記述に関しては、[3]を見てください。
A route entry should have the following in it:
- Destination address (a source of multicast datagrams) *
- Subnet mask of the destination address *
- Next-hop router to the destination address
- Virtual interface to the next-hop router *
- List of child virtual interfaces *
- List of leaf virtual interfaces *
- A dominant router address for each virtual interface
- A subordinate router address for each virtual interface
- Timer
- Set of flags that indicate the state of the entry
- Metric
- Infinity
ルートエントリーはそれに以下を持つべきです: - 送付先アドレス(マルチキャストデータグラムの源)*--送付先アドレス*のサブネットマスク--送付先アドレスへの次のホップルータ--次のホップルータ*への仮想インターフェース--子供仮想インターフェース*のリスト--葉の仮想インターフェース*のリスト--各仮想インターフェース(各仮想インターフェース(タイマ)へのアドレスが設定したエントリーの状態を示す旗の下位のルータ)における、メートル法の優位なルータアドレス--無限
The lines that are marked with '*' indicate fields that are directly used by the forwarding algorithm.
'*'でマークされる系列は推進アルゴリズムで直接使用される分野を示します。
Waitzman, Partridge & Deering [Page 15] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[15ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
The lists of child and leaf interfaces can be implemented as bitmaps.
ビットマップとして子供と葉のインタフェースのリストを実装することができます。
5.1 Sending Routing Messages
5.1 送付ルーティング・メッセージ
DVMRP routing messages can be used for three basic purposes: to periodically supply all routing information, to gratuitously supply routing information for recently changed routes, or supply some or all routes in response to a request.
3つの基本的な目的にDVMRPルーティング・メッセージを使用できます: 定期的に、すべてのルーティング情報を提供して、無償で要求に対応して最近変えられたルート、または供給のためのルーティング情報にいくつかかすべてのルートを供給してください。
Routing messages sent to physical interfaces should have an IP TTL of 1.
物理インターフェースに送られたルーティング・メッセージは1のIP TTLを持つべきです。
A number of timeouts and rates are used by the routing and forwarding algorithms. See section 6 for their values.
多くのタイムアウトとレートが、ルーティングで使用されて、アルゴリズムを進めています。それらの値に関してセクション6を見てください。
Rules for when to send routing messages:
いつルーティング・メッセージを送るか間の規則:
- Every FULL_UPDATE_RATE seconds a router should send out
DVMRP messages with all of its routing information to all of its
virtual interfaces. To prevent routers from synchronizing when
they send updates, a real-time timer must be used.
- あらゆるFULL_UPDATE_RATE秒aルータがルーティング情報のすべてがあるDVMRPメッセージを仮想インターフェースのすべてに出すべきです。 アップデートを送るとき、ルータが同期するのを防ぐために、リアルタイムのタイマを使用しなければなりません。
- Whenever a route is changed, a routing update should be sent
for that route. Some delay must occur between triggered
updates to avoid flooding the network with triggered updates;
intervals of TRIGGERED_UPDATE_RATE seconds is suggested.
- ルートを変えるときはいつも、ルーティングアップデートをそのルートに送るべきです。 何らかの遅れが引き起こされたアップデートでネットワークをあふれさせるのを避けるために引き起こされたアップデートの間に起こらなければなりません。 TRIGGERED_UPDATE_RATE秒の間隔は示されます。
- A request for all routes should be sent on all virtual
interfaces when an DVMRP router is restarted.
- DVMRPルータを再開するとき、すべての仮想インターフェースですべてのルートを求める要求を送るべきです。
- If possible, when a DVMRP router is about to terminate
execution, it should send out DVMRP messages with metrics
equal to infinity for all of its routes, on all virtual
interfaces.
- できれば、DVMRPルータが実行を終えようとしているなら、ルートのすべてのために測定基準同輩がいるDVMRPメッセージを無限で出すべきです、すべての仮想インターフェースで。
When sending to routers connected via networks that support multicasting, the messages should be multicast to address 224.0.0.4. Therefore, routers must listen to multicast address 224.0.0.4 on every physical interface that supports multicasting. If multicasting isn't supported, broadcasting can be used. As already mentioned, routing updates to tunnels should be sent as unicast datagrams to the remote end-point of the tunnel.
マルチキャスティングをサポートするネットワークを通して接続されたルータに発信するとき、メッセージが扱うマルチキャストであるべきである、224.0、.0、.4 したがって、ルータはマルチキャスティングをサポートするあらゆる物理インターフェースでマルチキャストアドレス224.0.0.4を聞かなければなりません。 マルチキャスティングがサポートされないなら、放送を使用できます。 既に言及されるように、ユニキャストデータグラムとしてトンネルへのルーティングアップデートをトンネルのリモートエンドポイントに送るべきです。
When sending routing messages, except in response to a specific route request (via RDA command with a non-zero count), poisoned split horizon processing must be done. This means that given a route that uses network X, routing updates sent to network X must include that route with the metric equal to the infinity and should include the
特定のルート要求(非ゼロカウントによるRDAコマンドを通した)を除いて、ルーティング・メッセージを送るとき、当たっている分裂地平線処理をしなければなりません。 ネットワークXを使用するルートを考えて、これはそれを意味します、メートル法があるルートが無限と等しく、含んでいるはずであるXが含まなければならないネットワークに送られたルーティングアップデート
Waitzman, Partridge & Deering [Page 16] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[16ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
appropriate flag set in a FLAGS0 command.
適切なフラグはFLAGS0コマンドでセットしました。
Poisoned split horizon is one way to reduce the likelihood of routing loops. Another method, not available in RIP, is to choose a better infinity in a route. For routes propagated in a small, but well connected, network an infinity smaller than 16 might be better. The smaller the infinity, the less time a counting-to-infinity event will take. In traversing a wide internet, an infinity of 16 might be too small. At the cost of a longer counting-to-infinity event, the infinity can be increased.
当たっている分裂地平線はルーティング輪の見込みを減少させることにおいて一方通行です。 別のRIPで利用可能でないメソッドはルートで、より良い無限を選ぶことです。 小さい、しかし、よく接続されたネットワークで伝播されたルートにおいて、16よりわずかな無限はさらに良いかもしれません。 無限がわずかであればわずかであるほど、-無限で数えイベントがかかる時間は、より少ないです。 広いインターネットを横断するのにおいて、16の無限はわずか過ぎるかもしれません。 より長い-無限で数えイベントの費用では、無限を増強できます。
One concept in Internet Multicasting is to use "thresholds" to restrict which multicast datagrams exit a network. Multicast routers on the edge of a subnetted network or autonomous system may require a datagram to have large TTL to exit a network. This mechanism keeps most multicast datagrams within the network, reducing external traffic. An application that wants to multicast outside of its network would need to give its multicast datagrams at least a TTL of the sum of the threshold and the distance to the edge of the network (assuming TTL is used as a hop count within the network). A configuration option should allow specifying the threshold for both physical interfaces and tunnels.
インターネットMulticastingの1つの概念は制限するそれのマルチキャストデータグラムがネットワークを出る「敷居」を使用することです。 サブネット化したネットワークか自律システムの縁のマルチキャストルータは、ネットワークを出るためにデータグラムには大きいTTLがあるのを必要とするかもしれません。 域外交通を抑えて、このメカニズムはネットワークの中のほとんどのマルチキャストデータグラムを保ちます。 ネットワークの外部をマルチキャストに必要とするアプリケーションは、少なくとも敷居の合計とネットワークの縁への距離のTTLをマルチキャストデータグラムに与える必要があるでしょう(TTLを仮定するのはホップカウントとしてネットワークの中で使用されます)。 設定オプションで、物理インターフェースとトンネルの両方に敷居を指定するべきです。
When a router is started, it must send out a request for all routes on each of its virtual interfaces. The request is a message that has an RDA command with a count equal to 0 in it.
ルータが始められるとき、それはそれぞれの仮想インターフェースのすべてのルートを求める要求を出さなければなりません。 要求は0と等しいカウントがそれにある状態でRDAコマンドがあるメッセージです。
5.2 Receiving Routing Messages
5.2 ルーティング・メッセージを受け取ること。
A router must know the virtual interface that a routing message arrived on. Because the routing message may be addressed to the all-multicast-routers IP address, and because of tunnels, the incoming interface can not be identified merely by examining the message's IP destination address
ルータはルーティング・メッセージが到着した仮想インターフェースを知らなければなりません。 オールマルチキャストルータIPアドレスにルーティング・メッセージを扱うかもしれなくて、トンネルのために、メッセージの受信者IPアドレスを調べながら単に入って来るインタフェースの身元を確認することができないので
For each route expressed in a routing message, the following must occur:
ルーティング・メッセージで急送された各ルートに、以下は起こらなければなりません:
IF a metric was given for the route:
THEN add in the metric of the virtual interface that the message
arrived on.
aであるなら、メートル法であることは、ルートのための当然のことでした: THENはメッセージが到着した仮想インターフェースのメートル法を加えます。
Lookup the route's destination address in the routing tables.
ルートの目的地が経路指定テーブルで扱うルックアップ。
IF the route doesn't exist in the tables:
THEN try to find a route to the same network in the routing
tables.
IF that route exists in the tables:
ルートがテーブルに存在していないなら: THENは経路指定テーブルの同じネットワークにおいてルートを見つけようとします。 そのルートがテーブルに存在しているなら:
Waitzman, Partridge & Deering [Page 17] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[17ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
THEN IF this route came from the same router as the router
that the found route came from:
THEN CONTINUE with next route.
IF route doesn't have a metric of infinity:
THEN add the route to the routing tables.
CONTINUE with next route.
THEN IF、このルートは備え付けることのルートが以下から来させたルータと同じルータから来ました。 次のルートがあるTHEN CONTINUE。 aがルートで無限でメートル法にならないなら: THENは経路指定テーブルにルートを加えます。 次のルートがあるCONTINUE。
IF this route came from the same router as the router that the found
route came from:
THEN clear the route timer.
IF a metric was received, and it is different than the found
route's metric:
THEN change the found route to use the new metric and
infinity.
IF the metric is equal to the infinity:
THEN set the route timer to the
EXPIRATION_TIMEOUT.
CONTINUE with next route.
IF the received infinity does not equal the found route's
infinity:
THEN change the found route's infinity to be the received
infinity.
change the found route's metric to be the minimum of
the received infinity and the found route's metric.
ELSE IF a metric was received, and (it is less than the found
route's metric or (the route timer is at least halfway to the
EXPIRATION_TIMEOUT and the found route's metric equals the
received metric, and the metric is less than the received
infinity)):
THEN change the routing tables to use the received route.
clear the route timer.
CONTINUE with next route.
このルートが同じくらいから来たなら、見つけるのが発送するルータとしてのルータは以下から来ました。 THENはルートタイマをきれいにします。 aメートル法、受け取った、それが備え付けることのルートがメートル法であるより異なっている、: 見つけるのがメートル法で新しさを使用するために発送するTHEN変化と無限。 メートル法であるなら、無限には同輩がいます: THENはEXPIRATION_TIMEOUTにルートタイマを設定します。 次のルートがあるCONTINUE。 容認された無限が備え付けることのルートの無限と等しくないなら: THENは、容認された無限になるように備え付けることのルートの無限を変えます。容認された無限と備え付けることのルートのものの最小限がメートル法であるということになるように、メートル法で備え付けることのルートのものを変えてください。 または、ELSE IF aメートル法、受け取った、(それが見つけるより少ないルートのものであるメートル法、(EXPIRATION_TIMEOUTと備え付けることのルートのメートル法の同輩にとって、ルートタイマが少なくとも途中、メートル法であることで受信する、メートル法が容認された無限以下である、)、: THENは、容認されたルートを使用するために経路指定テーブルを変えます。ルートタイマをきれいにしてください。 次のルートがあるCONTINUE。
5.3 Neighbors
5.3 ネイバーズ
A list should be kept of the neighboring multicast routers on every attached network. The information can be derived by the DVMRP routing messages that are received. A neighbor that has not been heard from in NEIGHBOR_TIMEOUT seconds should be considered to be down.
リストはあらゆる付属ネットワークに隣接しているマルチキャストルータについて保たれるべきです。 受信されたDVMRPルーティング・メッセージは情報を引き出すことができます。 それがNEIGHBOR_TIMEOUT秒に聞かれていない隣人が下がっていると考えられるべきです。
5.4 Local Group Memberships
5.4 地域団体会員資格
As required by [2], a multicast router must keep track of group memberships on the multicast-capable networks attached to it. Every QUERY_RATE seconds an IGMP membership request should be sent to the All Hosts multicast address (224.0.0.1) on each network by a designated router on that network. The IGMP membership request will
必要に応じて、[2]で、マルチキャストルータはそれに付けられたマルチキャストできるネットワークでグループ会員資格の動向をおさえなければなりません。 RATEが後援するあらゆるQUERY_がAll Hostsマルチキャストアドレスに送られるべきである、IGMP会員資格が、要求する(224.0 .0 .1) そのネットワークの代表ルータによる各ネットワークで。 IGMP会員資格要求はそうするでしょう。
Waitzman, Partridge & Deering [Page 18] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[18ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
cause hosts to respond with IGMP membership reports after a small delay. Hosts will send the report for a group to the group's multicast address.
ホストが小さい遅れの後にIGMP会員資格レポートで応じることを引き起こしてください。 ホストはグループのマルチキャストアドレスにグループのためのレポートを送るでしょう。
The membership requests should have an IP TTL of 1.
会員資格要求には、1のIP TTLがあるべきです。
The routers on a network elect or "designate" a single router to do the queries. The designated router is the router with the lowest IP address on that network. Upon startup a router considers itself to be the designated router until it learns (presumably through routing messages) of a router with a lower address. To learn about the group members present on a network at startup, a router should multicast a number of membership requests, separated by a small delay. We suggest sending three requests separated by four seconds.
ネットワークのルータは、質問するためにただ一つのルータを選出するか、または「指定します」。 代表ルータはそのネットワークで最も低いIPアドレスがあるルータです。 ルータ自体が学ぶまでの(おそらくルーティング・メッセージを通して)代表ルータであると考える低いアドレスがあるルータの始動のときに。 始動でネットワークでグループの出席者に関して学ぶために、ルータは小さい遅れによって多くの会員資格要求であって、切り離されたマルチキャストがそうするべきです。 私たちは、4秒までに切り離された3つの要求を送ることを提案します。
The multicast router must receive all datagrams sent to all multicast addresses. Upon receiving an IGMP membership report for a group from an interface, it must either record the existence of that group on the interface and record the time, or update the time if the group is already recorded. The recorded group memberships must be timed-out. If a group member report is not received for a recorded group after MEMBERSHIP_TIMEOUT seconds, the recorded group should be deleted.
マルチキャストルータはすべてのマルチキャストアドレスに送られたすべてのデータグラムを受けなければなりません。 インタフェースからグループのためのIGMP会員資格レポートを受け取ると、グループが既に記録されるなら、それは、そのグループの存在をインタフェースに記録して、時間を記録しなければならないか、または時にアップデートしなければなりません。 -外で記録されたグループ会員資格を調節しなければなりません。 グループメンバーレポートがMEMBERSHIP_TIMEOUT秒以降記録されたグループのために受け取られないなら、記録されたグループは削除されるべきです。
6. Forwarding Algorithm
6. 推進アルゴリズム
The section describes the multicast forwarding algorithm and the state that must be kept for the algorithm.
セクションはアルゴリズムのために維持しなければならないマルチキャスト推進アルゴリズムと状態について説明します。
The forwarding algorithm is applied to determine how multicast datagrams arriving on a physical interface or a tunnel should be handled. If multicast datagrams were flooded, a datagram received on one virtual interface would be forwarded out of every other virtual interface. Because of redundant paths in the internet, datagrams would be duplicated. The child and leaf information, that the routing algorithm supplies, is used to prune branches in the tree to all possible destinations.
推進アルゴリズムは、物理インターフェースかトンネルの上で届くマルチキャストデータグラムがどのように扱われるべきであるかを決定するために適用されます。 マルチキャストデータグラムが水につかるなら、他のあらゆる仮想インターフェースから1つの仮想インターフェースに受け取られたデータグラムを進めるでしょうに。 インターネットにおける冗長パスのために、データグラムはコピーされるでしょう。 子供と葉の情報、ルーティング・アルゴリズム供給が剪定するのにおいて使用されているのは木ですべての可能な目的地に分岐します。
In route entries, there is a dominant router address for each virtual interface. This address is the address of some router that has a route with a lower metric (and whose metric does not equal infinity) to the destination, on that virtual interface. The dominant router address is not set for the next-hop virtual interface.
ルートエントリーに、各仮想インターフェースへの優位なルータアドレスがあります。 そして、このアドレスがaが低いルートをメートル法にする何らかのルータのアドレスである、(だれのもの、メートル法、等しい無限でない) その仮想インターフェースの目的地に。 優位なルータアドレスは次のホップ仮想インターフェースのときに予定されません。
Also in route entries, there is a subordinate router address for each virtual interface. This address is the address of some router that considers this router to be the parent of the virtual network. Therefore, the subordinate router address is not set for a virtual interface to a leaf network.
ルートエントリーにも、各仮想インターフェースへの下位のルータアドレスがあります。 このアドレスはそれが仮想ネットワークの親になるようにこのルータであると考える何らかのルータのアドレスです。 したがって、下位のルータアドレスは葉のネットワークへの仮想インターフェースのときに予定されません。
Waitzman, Partridge & Deering [Page 19] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[19ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
The algorithm for manipulating the children and leaf lists in route entries is:
ルートエントリーで子供と葉のリストを操るためのアルゴリズムは以下の通りです。
Upon router startup:
Create a route entry for each virtual interface, with:
- all other virtual interfaces in its child list,
- an empty leaf list,
- no dominant router addresses, and
- no subordinate router addresses.
Start a hold down timer for each virtual interface, with
a value of LEAF_TIMEOUT.
ルータ始動のときに: 以下で各仮想インターフェースのためのルートエントリーを作成してください。 - そして、子供リストの他の仮想インターフェース--空の葉のリスト--すべての優位なルータアドレスがない、--下位のルータアドレスがありません。 LEAF_TIMEOUTの値との各仮想インターフェースに抑制タイマを始動してください。
Upon receiving a new route:
Create the route entry, with:
- all virtual interfaces, other than the one on which the
new route was received, in its child list,
- empty leaf list,
- no dominant router addresses, and
- no subordinate router addresses.
Start the hold down timer for all virtual interfaces, other
than the one on which the new route was received, with a
value of LEAF_TIMEOUT.
新しいルートを受けることに関して: 以下でルートエントリーを作成してください。 - そして、新しいルートが子供リスト--空の葉のリスト--優位なルータアドレスでないところに受け取られたもの以外のすべての仮想インターフェース、--下位のルータアドレスがありません。 タイマで新しいルートがLEAF_TIMEOUTの値で受け取られたもの以外のすべての仮想インターフェースに保持を始めてください。
Upon receiving a route on virtual interface V from neighbor N with a
lower metric than the one in the routing table (or the same metric as
the one in the routing table, if N's address is less than my address
for V), for that route:
If V is in the child list, delete V from the child list.
If there is no dominant router for V and if V is not (now) the
next-hop virtual interface, record N as the dominant router.
aで隣人Nから仮想インターフェースVのルートを受けるとき経路指定テーブルのものよりメートル法で下ろしてください、(同じくらい、経路指定テーブルのものとしてメートル法です、それに関して、NのアドレスがV)のための私のアドレス以下であるなら、以下を発送してください。 Vが子供リストにあるなら、子供リストからのVを削除してください。 Vのためのどんな優位なルータもなくて、また(現在)のときにVが次のホップ仮想インターフェースでないなら、優位なルータとしてNを記録してください。
Upon receiving a route on virtual interface V from neighbor N with a
larger metric than the one in the routing table (or the same metric
as the one in the routing table, if N's address is greater than my
address for V), for that route:
If N is the dominant router for V, delete N as the dominant router
and add V to the child list.
aを受けるとき経路指定テーブルのものより仮想インターフェースVで隣人からメートル法でaがさらに大きいNを発送してください、(同じくらい、経路指定テーブルのものとしてメートル法です、NのアドレスがV)のための私のアドレスより大きいなら、それに関して、以下を発送してください。 NがVのための優位なルータであるなら、優位なルータとしてNを削除してください、そして、子供リストにVを追加してください。
Upon receiving a route from neighbor N on virtual interface V with a
metric equal to infinity (the split horizon flag should also be set),
for that route:
If V is in the leaf list, delete V from the leaf list.
If there is no subordinate router for V, record N as the
subordinate router.
メートル法の同輩との仮想インターフェースVで隣人Nからルートを無限(また、分裂地平線旗は設定されるべきである)で受けたら、それに関して、以下を発送してください。 Vが葉のリストにあるなら、葉のリストからのVを削除してください。 Vのためのどんな下位のルータもなければ、下位のルータとしてNを記録してください。
Upon receiving a route from neighbor N on virtual interface V with a metric other than infinity (and no split horizon flag), for that route:
無限を除いたそれにおけるメートル法(そして、分裂地平線旗がない)のルートとの仮想インターフェースVで隣人Nからルートを受けることに関して:
Waitzman, Partridge & Deering [Page 20] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[20ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
If N is the subordinate router for V, delete N as the subordinate
router and start the hold down timer for V.
NがVのための下位のルータであるなら、下位のルータとしてNを削除してください、そして、Vのためにタイマで保持を始めてください。
Upon timer expiration for a virtual interface (V), for each route:
If there is no subordinate router for V, add V to the leaf list.
仮想インターフェース(V)のためのタイマ満了のときに、それぞれに関して、以下を発送してください。 Vのためのどんな下位のルータもなければ、葉のリストにVを追加してください。
Upon failure of neighbor N on virtual interface V, for each route:
If N is the dominant router for V, delete N as the dominant router
and add V to the child list.
If N is the subordinate router for V, delete N as the subordinate
router and start the hold down timer for V.
仮想インターフェースVの隣人Nの失敗では、それぞれに関して、以下を発送してください。 NがVのための優位なルータであるなら、優位なルータとしてNを削除してください、そして、子供リストにVを追加してください。 NがVのための下位のルータであるなら、下位のルータとしてNを削除してください、そして、Vのためにタイマで保持を始めてください。
The forwarding algorithm is:
推進アルゴリズムは以下の通りです。
IF the IP TTL is less than 2: THEN CONTINUE with next datagram.
IP TTLが2歳未満であるなら: 次のデータグラムがあるTHEN CONTINUE。
find the route to the source of the IP datagram.
IPデータグラムの源においてルートを見つけてください。
IF no route exists: THEN CONTINUE with next datagram.
ルートが全く存在していないなら: 次のデータグラムがあるTHEN CONTINUE。
IF the datagram was not received on the next-hop virtual interface for the route: THEN CONTINUE with next datagram.
データグラムがルートへの次のホップ仮想インターフェースに受け取られなかったなら: 次のデータグラムがあるTHEN CONTINUE。
IF the datagram is tunneled:
THEN replace the datagram's source address with the first address
in the IP loose source route.
replace the datagram's destination address with the second
address in the IP loose source route.
delete the loose source route and the null option from the
datagram and adjust the IP header length fields to reflect
the deletion.
データグラムがトンネルを堀られるなら: THENはデータグラムのソースアドレスをIPのゆるい送信元経路における最初のアドレスに取り替えます。データグラムの送付先アドレスをIPのゆるい送信元経路における2番目のアドレスに取り替えてください。データグラムからゆるい送信元経路とヌルオプションを削除してください、そして、IPヘッダ長分野を調整して、削除を反映してください。
If the datagram destination is group 224.0.0.0 or group 224.0.0.1: THEN CONTINUE with next datagram.
データグラムの目的地がグループ224.0の.0の.0かグループ224.0.0.1であるなら: 次のデータグラムがあるTHEN CONTINUE。
FOR each virtual interface V
DO IF V is in the child list for the source of the datagram:
THEN IF V is not in the leaf list for the source
OR there are members of the destination group on V:
THEN IF the IP TTL is greater then V's threshold:
THEN subtract 1 from the IP TTL
forward the datagram out V
Vが子供にあるなら、各仮想インターフェースVがするFORはデータグラムの源に記載します: THEN IF VはソースORへの葉のリストには、Vに関する目的地グループのメンバーがいないということです: THEN IF IP TTLが、よりすばらしい当時のVである、敷居: THENが引く、IP TTLからの1は出かけているVをデータグラムに送ります。
Waitzman, Partridge & Deering [Page 21] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[21ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
7. Time Values
7. 時間的価値
This section contains a list of the various rates and timeouts, their meanings, and their values. All values are in seconds.
このセクションは様々なレートとタイムアウトのリスト、それらの意味、およびそれらの値を含みます。 秒に、すべての値があります。
How dynamic the routing environment is effects the following rates. A lower rate will allow quicker adaptation to a change in the environment, at the cost of wasting network bandwidth.
ルーティング環境がどれくらいダイナミックであるかが以下のレートに作用します。 低料金はネットワーク回線容量を浪費する費用における環境における変化への、より迅速な適合を許容するでしょう。
FULL_UPDATE_RATE = 60
- How often routing messages containing complete routing
tables are sent.
FULL_UPDATE_RATE=60--どれくらいの頻度で掘って、完全な経路指定テーブルを含むメッセージを送ります。
TRIGGERED_UPDATE_RATE = 5
- How often triggered routing messages may be sent out.
TRIGGERED_UPDATE_RATE=5--どれくらいの頻度で引き起こされたかルーティング・メッセージを出すかもしれません。
Raising the following rates and timeouts may increase the time that packets may be forwarded to a virtual interface unnecessarily.
以下のレートとタイムアウトを上げるのは不必要にパケットを仮想インターフェースに送るかもしれない時に増加するかもしれません。
QUERY_RATE = 120
- How often local group membership is queried.
QUERY_RATE=120--どれくらいの頻度で地方のグループ会員資格は質問されるか。
MEMBERSHIP_TIMEOUT = 2 * QUERY_RATE + 20
- How long a local group membership is valid without
confirmation.
2*QUERY MEMBERSHIP_TIMEOUT=_RATE+20--どれくらい長い地域団体会員資格は確認なしで有効ですか?
LEAF_TIMEOUT = 2 * FULL_UPDATE_RATE + 5
- How long the hold down timer is for a virtual interface.
2*FULL LEAF_TIMEOUT=_UPDATE_RATE+5--仮想インターフェースには、タイマの下側への保持は何と長いです!
Increasing the following timeouts will increase the stability of the routing algorithm, at the cost of slower reactions to changes in the routing environment.
以下のタイムアウトを増加させると、ルーティング・アルゴリズムの安定性は増加するでしょう、ルーティング環境における変化への、より遅い反応の費用で。
NEIGHBOR_TIMEOUT = 4 * FULL_UPDATE_RATE
- How long a neighbor is considered up without confirmation.
This is important for timing out routes, and for setting
the children and leaf flags.
NEIGHBOR_TIMEOUT=4*FULL_UPDATE_RATE--どれくらい長い隣人は確認なしで上がると考えられますか? タイミングアウトルートと、子供と葉の旗を設定するのに、これは重要です。
EXPIRATION_TIMEOUT = 2 * FULL_UPDATE_RATE
- How long a route is considered valid without confirmation.
When this timeout expires, packets will no longer be
forwarded on the route, and routing updates will consider
this route to have a metric of infinity.
EXPIRATION_TIMEOUT=2*FULL_UPDATE_RATE--どれくらい長いルートは確認なしで有効であると考えられますか? このタイムアウトが期限が切れるとき、パケットはもうルートで進められないでしょう、そして、ルーティングアップデートはこのルートでaが無限でメートル法になると考えるでしょう。
GARBAGE_TIMEOUT = 4 * FULL_UPDATE_RATE
- How long a route exists without confirmation. When this
timeout expires, routing updates will no longer contain any
information on this route, and the route will be deleted.
GARBAGE_TIMEOUT=4*FULL_UPDATE_RATE--どれくらい長いルートは確認なしで存在していますか? このタイムアウトが期限が切れるとき、ルーティングアップデートはもうこのルートの少しの情報も含まないでしょう、そして、ルートは削除されるでしょう。
Waitzman, Partridge & Deering [Page 22] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[22ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
8. Configuration options
8. 設定オプション
A router should be configurabled with the following information:
ルータは以下の情報でconfigurabledされるべきです:
- Tunnel descriptions: local end-point, remote end-point, metric, and
threshold. If no threshold is provided, the metric should be used
as the default threshold.
- 記述にトンネルを堀ってください: リモート終わりポイントの、そして、メートル法の地方のエンドポイント、および敷居。 敷居を全く提供しないなら、デフォルト敷居としてメートル法を使用するべきです。
- For a physical interface: metric, infinity, threshold and
subnetwork mask. If no threshold is provided, the metric should be
used as the default threshold.
- 物理インターフェースに: メートル法の無限、敷居、およびサブネットワークマスク。 敷居を全く提供しないなら、デフォルト敷居としてメートル法を使用するべきです。
9. Conclusion
9. 結論
This memo has presented DVMRP, an extensible distance-vector-style routing protocol, and a TRPB routing algorithm. An implementation of the ideas presented in this document has been done, and is being tested.
このメモはDVMRP、広げることができる距離ベクトルスタイルルーティング・プロトコル、およびTRPBルーティングアルゴリズムを提示しました。 本書では提示された考えの実現をして、テストしています。
The added features in DVMRP, as compared to RIP, give it flexibility at the cost of more complex processing. DVMRP still has the disadvantages of being a distance-vector algorithm. Because link- state algorithms maintain much of the state information that DVMRP has to maintain in excess of what RIP needs, a multicast link-state routing protocol should be developed.
DVMRPのRIPと比べる付記された特徴は、より複雑な処理の費用における柔軟性をそれに与えます。 DVMRPには、距離ベクトルアルゴリズムである損失がまだあります。 リンク州のアルゴリズムがDVMRPがRIPが必要とするものを超えて保守しなければならない州の情報の多くを維持するので、マルチキャストLinkState方式プロトコルは開発されるべきです。
The TRPB algorithm can cause unneeded datagrams to be sent. The Reverse Path Multicasting algorithm (RPM) [3] might be a better algorithm. The NMR and NMR-cancel DVMRP messages are designed to support RPM. Further research is needed on this topic.
TRPBアルゴリズムで、不要なデータグラムを送ることができます。 Reverse Path Multicastingアルゴリズム(RPM)[3]は、より良いアルゴリズムであるかもしれません。 NMRとNMR-キャンセルDVMRPメッセージは、RPMを支持するように設計されています。 さらなる研究がこの話題に関して必要です。
10. Acknowledgements
10. 承認
We would like to thank Robb Foster, Alan Dahlbom, Ross Callon, and the IETF Host Working Group for their ideas.
彼らの考えについてロブ・フォスター、アランDahlbom、ロスCallon、およびIETF Host作業部会に感謝申し上げます。
11. Bibliography
11. 図書目録
[1] Hedrick, C., "Routing Information Protocol", RFC 1058, Rutgers
University, June 1988.
[1] ヘドリック、C.、「ルーティング情報プロトコル」、RFC1058、ラトガース大学、1988年6月。
[2] Deering, S., "Host Extensions for IP Multicasting", RFC 1054,
Stanford University, May 1988.
[2] デアリング(S.、「IPマルチキャスティングのためのホスト拡大」、RFC1054、スタンフォード大学)は1988がそうするかもしれません。
[3] Deering, S., "Multicast Routing in Internetworks and Extended
LANs", SIGCOMM Summer 1988 Proceedings, August 1988.
[3] デアリング、S.、「インターネットワークと拡張LANにおけるマルチキャストルート設定」、SIGCOMM1988年夏の議事、1988年8月。
[4] Callon, R., "A Comparison of 'Link State' and 'Distance
[4]Callon、R.、「'リンク状態'と'距離'の比較」
Waitzman, Partridge & Deering [Page 23] RFC 1075 Distance Vector Multicast Routing Protocol November 1988
Waitzman、ヤマウズラ、およびデアリング[23ページ]RFC1075は1988年11月にベクトルマルチキャストルーティング・プロトコルを遠ざけます。
Vector' Routing Algorithms", DEC, November 1987.
1987年11月12月の「'ベクトル'ルーティング・アルゴリズム。」
[5] Postel, J., "Internet Protocol", RFC 791, USC/Information
Sciences Institute, September 1981.
[5] ポステル、J.、「インターネットプロトコル」、RFC791、科学が1981年9月に設けるUSC/情報。
[6] Mills, D., "Toward an Internet Standard Scheme for
Subnetting", RFC 940, University of Delaware, April 1985.
[6] 工場、D. 「サブネッティングのインターネットの標準の計画」へのRFC940、デラウエア大学、1985年4月。
Waitzman, Partridge & Deering [Page 24]
Waitzman、ヤマウズラ、およびデアリング[24ページ]
一覧
スポンサーリンク
