RFC2189 日本語訳
2189 Core Based Trees (CBT version 2) Multicast Routing -- ProtocolSpecification --. A. Ballardie. September 1997. (Format: TXT=52043 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Ballardie Request for Comments: 2189 Consultant Category: Experimental September 1997
Ballardieがコメントのために要求するワーキンググループA.をネットワークでつないでください: 2189年のコンサルタントカテゴリ: 実験的な1997年9月
Core Based Trees (CBT version 2) Multicast Routing
コアBased Trees(CBTバージョン2)マルチキャストルート設定
-- Protocol Specification --
-- 仕様を議定書の中で述べてください--
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
This document describes the Core Based Tree (CBT version 2) network layer multicast routing protocol. CBT builds a shared multicast distribution tree per group, and is suited to inter- and intra-domain multicast routing.
このドキュメントはCore Based Tree(CBTバージョン2)ネットワーク層マルチキャストルーティング・プロトコルについて説明します。 そして、CBTが1グループあたり1本の共有されたマルチキャスト分配木を建てて、合っている、相互、イントラドメインマルチキャストルーティング。
CBT may use a separate multicast routing table, or it may use that of underlying unicast routing, to establish paths between senders and receivers. The CBT architecture is described in [1].
CBTが別々のマルチキャスト経路指定テーブルを使用するかもしれませんか、またはそれは、送付者と受信機の間の経路を証明するのに基本的なユニキャストルーティングのものを使用するかもしれません。 CBT構造は[1]で説明されます。
This document is progressing through the IDMR working group of the IETF. CBT related documents include [1, 5, 6]. For all IDMR-related documents, see http://www.cs.ucl.ac.uk/ietf/idmr.
このドキュメントはIETFのIDMRワーキンググループを通して進歩をしています。 CBTの関連するドキュメントは[1、5、6]を含んでいます。 すべてのIDMR関連のドキュメントに関しては、 http://www.cs.ucl.ac.uk/ietf/idmr を見てください。
TABLE OF CONTENTS
目次
1. Changes Since Previous version............................. 2
2. Introduction & Terminology................................. 3
3. CBT Functional Overview.................................... 3
4. CBT Protocol Specificiation Details........................ 6
4.1 CBT HELLO Protocol..................................... 6
4.1.1 Sending HELLOs................................... 7
4.1.2 Receiving HELLOs................................. 7
4.2 JOIN_REQUEST Processing................................ 8
4.2.1 Sending JOIN_REQUESTs............................ 8
4.2.2 Receiving JOIN_REQUESTs.......................... 8
4.3 JOIN_ACK Processing.................................... 9
4.3.1 Sending JOIN_ACKs................................ 9
4.3.2 Receiving JOIN_ACKs.............................. 9
1. Since Previousバージョンを変えます… 2 2. 序論と用語… 3 3. CBT機能概要… 3 4. CBTはSpecificiationの詳細について議定書の中で述べます… 6 4.1 CBT、こんにちは、議定書を作ってください… 6 4.1 .1 HELLOsを送ります… 7 4.1 .2 HELLOsを受けます… 7 4.2 _要求処理に参加してください… 8 4.2 .1 発信して、_要求に参加してください… 8 4.2 .2 受信して、_要求に参加してください… 8 4.3 _ACK処理に参加してください… 9 4.3 .1 発信して、_ACKsを接合してください… 9 4.3 .2 受信して、_ACKsを接合してください… 9
Ballardie Experimental [Page 1] RFC 2189 CBTv2 Protocl Specification September 1997
[1ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
4.4 QUIT_NOTIFICATION Processing........................... 10
4.4.1 Sending QUIT_NOTIFICATIONs....................... 10
4.4.2 Receiving QUIT_NOTIFICATIONs..................... 10
4.5 CBT ECHO_REQUEST Processing............................ 11
4.5.1 Sending ECHO_REQUESTs............................ 11
4.5.2 Receiving ECHO_REQUESTs.......................... 12
4.6 ECHO_REPLY Processing.................................. 12
4.6.1 Sending ECHO_REPLYs.............................. 12
4.6.2 Receiving ECHO_REPLYs............................ 12
4.7 FLUSH_TREE Processing.................................. 13
4.7.1 Sending FLUSH_TREE Messages...................... 13
4.7.2 Receiving FLUSH_TREE Messages.................... 13
5. Non-Member Sending......................................... 13
6. Timers and Default Values.................................. 13
7. CBT Packet Formats and Message Types....................... 14
7.1 CBT Common Control Packet Header....................... 14
7.2 HELLO Packet Format.................................... 15
7.3 JOIN_REQUEST Packet Format............................. 16
7.4 JOIN_ACK Packet Format................................. 16
7.5 QUIT_NOTIFICATION Packet Format........................ 17
7.6 ECHO_REQUEST Packet Format............................. 18
7.7 ECHO_REPLY Packet Format............................... 18
7.8 FLUSH_TREE Packet Format............................... 19
8. Core Router Discovery...................................... 19
8.1 "Bootstrap" Mechanism Overview........................ 20
8.2 Bootstrap Message Format.............................. 21
8.3 Candidate Core Advertisement Message Format........... 21
9. Interoperability Issues.................................... 21
10. Security Considerations.................................. 21
Acknowledgements.............................................. 22
References.................................................... 22
Author Information............................................ 23
4.4 _通知処理をやめてください… 10 4.4 .1 発信は_通知をやめました… 10 4.4 .2 受信は_通知をやめました… 10 4.5 CBTは_要求処理をまねます… 11 4.5 .1 送付エコー_要求… 11 4.5 .2 エコー_要求を受け取ります… 12 4.6 _回答処理をまねてください… 12 4.6 .1 エコー_リプライを送ります… 12 4.6 .2 エコー_リプライを受けます… 12 4.7 _木の処理を洗い流してください… 13 4.7 .1 水洗_木のメッセージを送ります… 13 4.7 .2 水洗_木のメッセージを受け取ります… 13 5. 非会員発信… 13 6. タイマとデフォルト値… 13 7. CBTパケット・フォーマットとメッセージタイプ… 14 7.1 CBT共通制御機構パケットのヘッダー… 14、7.2、こんにちは、パケット・フォーマット… 15 7.3 _リクエスト・パケット形式を接合してください… 16 7.4 _ACKパケット・フォーマットを接合してください… 16 7.5 _通知パケット・フォーマットをやめてください… 17 7.6 _リクエスト・パケット形式を鳴り響かせてください… 18 7.7 _回答パケット・フォーマットを鳴り響かせてください… 18 7.8 _木のパケット・フォーマットを洗い流してください… 19 8. コアルータ発見… 19 8.1はメカニズム概観を「独力で進みます」… 20 8.2 メッセージ・フォーマットを独力で進んでください… 21 8.3 候補コア広告メッセージ・フォーマット… 21 9. 相互運用性問題… 21 10. セキュリティ問題… 21の承認… 22の参照箇所… 22 情報を書いてください… 23
1. Changes from CBT version 1
1. CBTバージョン1からの変化
This version of the CBT protocol specification differs significantly from the previous version. Consequently, this version represents version 2 of the CBT protocol. CBT version 2 is not, and was not, intended to be backwards compatible with version 1; we do not expect this to cause extensive compatibility problems because we do not believe CBT is at all widely deployed at this stage. However, any future versions of CBT can be expected to be backwards compatible with this version.
CBTプロトコル仕様のこのバージョンは旧バージョンから有意差があります。 その結果、このバージョンはCBTプロトコルのバージョン2を表します。 後方にバージョン1と互換性があった状態であることを意図して、CBTバージョン2は、なくて、またありませんでした。 CBTが現在のところ広く全く配備されると信じていないので、私たちは、これが大規模な互換性の問題を引き起こすと予想しません。 しかしながら、CBTのどんな将来のバージョンも後方にこのバージョンと互換性があった状態であると予想できます。
Ballardie Experimental [Page 2] RFC 2189 CBTv2 Protocl Specification September 1997
[2ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
The most significant changes to version 2 compared to version 1 include:
バージョン1にたとえられたバージョン2への最も重要な変化は:
o new LAN mechanisms, including the incorporation of an HELLO
protocol.
o HELLOプロトコルの編入を含む新しいLANメカニズム。
o new simplified packet formats, with the definition of a common CBT
control packet header.
o 一般的なCBTコントロールパケットのヘッダーの定義がある新しい簡易型のパケット・フォーマット。
o each group shared tree has only one active core router.
o それぞれのグループの共有された木には、1つのアクティブなコアルータしかありません。
This specification revision is a complete re-write of the previous
revision.
この仕様書改訂は前の改正の完全な書き直しです。
2. Introduction & Terminology
2. 序論と用語
In CBT, a "core router" (or just "core") is a router which acts as a "meeting point" between a sender and group receivers. The term "rendezvous point (RP)" is used equivalently in some contexts [2]. A core router need not be configured to know it is a core router.
CBTでは、「コアルータ」(または、まさしく「コア」)は送付者とグループ受信機の間の「ミーティングポイント」として機能するルータです。 「ランデブーポイント(RP)」という用語はいくつかの文脈[2]で同等に使用されます。 コアルータは、それがコアルータであることを知るために構成される必要はありません。
A router that is part of a CBT distribution tree is known as an "on- tree" router. An on-tree router maintains active state for the group.
CBT分配木の一部であるルータとして知られている、「オンである、」 ルータを木に追い上げてください。 木の上のルータはグループのために活動的な状態を維持します。
We refer to a broadcast interface as any interface that supports multicast transmission.
私たちはマルチキャスト送信を支持するどんなインタフェースとしての放送インタフェースについても言及します。
An "upstream" interface (or router) is one which is on the path towards the group's core router with respect to this interface (or router). A "downstream" interface (or router) is one which is on the path away from the group's core router with respect to this interface (or router).
「上流」のインタフェース(または、ルータ)は経路でこのインタフェース(または、ルータ)に関してグループのコアルータに向かっているものです。 「川下」のインタフェース(または、ルータ)はこのインタフェース(または、ルータ)に関してグループのコアルータから遠くの経路にあるものです。
Other terminology is introduced in its context throughout the text.
他の用語はテキスト中の文脈で紹介されます。
3. CBT Functional Overview
3. CBT機能概要
The CBT protocol is designed to build and maintain a shared multicast distribution tree that spans only those networks and links leading to interested receivers.
CBTプロトコルは、関心がある受信機に通じるそれらのネットワークとリンクだけにかかる共有されたマルチキャスト分配木を建てて、維持するように設計されています。
To achieve this, a host first expresses its interest in joining a group by multicasting an IGMP host membership report [3] across its attached link. On receiving this report, a local CBT aware router invokes the tree joining process (unless it has already) by generating a JOIN_REQUEST message, which is sent to the next hop on the path towards the group's core router (how the local router discovers which core to join is discussed in section 8). This join
これを達成するために、ホストは最初に、マルチキャスティングで仲間に入ることへの関心を示します。付属リンクの向こう側のIGMPホスト会員資格レポート[3]。 このレポートを受け取ると、地方のCBT意識しているルータは、JOIN_REQUESTメッセージを発生させることによって、木の接合の過程(既にそうしていない場合)を呼び出します(ローカルルータが、どのコアを接合したらよいかをどう発見するかについてセクション8で議論します)。(メッセージはグループのコアルータに向かった経路の次のホップに送られます)。 これは接合します。
Ballardie Experimental [Page 3] RFC 2189 CBTv2 Protocl Specification September 1997
[3ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
message must be explicitly acknowledged (JOIN_ACK) either by the core router itself, or by another router that is on the path between the sending router and the core, which itself has already successfully joined the tree.
コアルータ自体、または送付ルータとコアの間の経路にある別のルータで明らかにメッセージを承認しなければなりません(JOIN_ACK)。既に、経路自体は首尾よく木に合流しました。
The join message sets up transient join state in the routers it traverses, and this state consists of <group, incoming interface, outgoing interface>. "Incoming interface" and "outgoing interface" may be "previous hop" and "next hop", respectively, if the corresponding links do not support multicast transmission. "Previous hop" is taken from the incoming control packet's IP source address, and "next hop" is gleaned from the routing table - the next hop to the specified core address. This transient state eventually times out unless it is "confirmed" with a join acknowledgement (JOIN_ACK) from upstream. The JOIN_ACK traverses the reverse path of the corresponding join message, which is possible due to the presence of the transient join state. Once the acknowledgement reaches the router that originated the join message, the new receiver can receive traffic sent to the group.
セットが一時的でそれが横断するルータで状態に加わって、この状態が<グループから成るというメッセージを接合してください、入って来るインタフェース、出発しているインタフェース>。 対応するリンクがマルチキャスト送信を支持しないなら、「入って来るインタフェース」と「外向的なインタフェース」は、それぞれ「前のホップ」と「次のホップ」であるかもしれません。 「次のホップ」は経路指定テーブルから収集されます--「前のホップ」は入って来るコントロールパケットのIPソースアドレスから抜粋されます、そして、指定されたコアアドレスへの次のホップ。 結局aがある回が承認(JOIN_ACK)に上流へ、参加するこの一時的な状態。 対応の逆の経路が参加するJOIN_ACK横断は通信して、どれが一時的存在のために可能であるかが状態に加わります。 一度、承認が由来したルータに達する、メッセージを接合してください、そして、新しい受信機はグループに送られた交通を受けることができます。
Loops cannot be created in a CBT tree because a) there is only one active core per group, and b) tree building/maintenance scenarios which may lead to the creation of tree loops are avoided. For example, if a router's upstream neighbour becomes unreachable, the router immediately "flushes" all of its downstream branches, allowing them to individually rejoin if necessary. Transient unicast loops do not pose a threat because a new join message that loops back on itself will never get acknowledged, and thus eventually times out.
1グループあたりそこのa)が1つのアクティブなコアにすぎないので、CBT木で輪を作成できません、そして、木の輪の創造につながるかもしれないb)木のビル/維持シナリオが避けられます。 例えば、ルータの上流の隣人が手が届かなくなるなら、ルータはすぐに川下のブランチのすべてを「洗い流します」、必要なら、それらが個別に再び加わるのを許容して。 輪がa新しいので脅威を引き起こさない一時的なユニキャストは、外でそれ自体の輪が決して承認されないというメッセージを接合して、その結果、結局回を接合します。
The state created in routers by the sending or receiving of a JOIN_ACK is bi-directional - data can flow either way along a tree "branch", and the state is group specific - it consists of the group address and a list of local interfaces over which join messages for the group have previously been acknowledged. There is no concept of "incoming" or "outgoing" interfaces, though it is necessary to be able to distinguish the upstream interface from any downstream interfaces. In CBT, these interfaces are known as the "parent" and "child" interfaces, respectively. A router is not considered "on- tree" until it has received a JOIN_ACK for a previously sent JOIN_REQUEST.
ルータでJOIN_ACKの発信か受信で創設された状態は双方向です--状態はグループ特有です--データは木の「ブランチ」に沿っていずれにせよ流れることができます、そして、グループアドレスから成ります、そして、どれがグループへのメッセージを接合するかの上で局所界面のリストは以前に、承認されました。 「入って来る」か「送信する」インタフェースの概念が全くありません、どんな川下のインタフェースとも上流のインタフェースを区別できるのが必要ですが。 CBTでは、これらのインタフェースは「親」として知られています、そして、「子供」はそれぞれ連結します。 木に登ってください。ルータが考えられない、「オンである、」 以前に送られたJOIN_REQUESTのためにJOIN_ACKを受けるまで。
With regards to the information contained in the multicast forwarding cache, on link types not supporting native multicast transmission an on-tree router must store the address of a parent and any children. On links supporting multicast however, parent and any child information is represented with local interface addresses (or similar identifying information, such as an interface "index") over which the parent or child is reachable.
ネイティブのマルチキャスト送信を支持していないリンク型の上のマルチキャスト推進キャッシュに含まれた情報への尊敬で、木の上のルータは親とどんな子供のアドレスも格納しなければなりません。 しかしながら、マルチキャストを支持するリンクの上では、親とどんな子供情報も親か子供が届いている局所界面アドレス(または、インタフェース「インデックス」などの同様の身元が分かる情報)で代理をされます。
Ballardie Experimental [Page 4] RFC 2189 CBTv2 Protocl Specification September 1997
[4ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
Data from non-member senders must be encapsulated (IP-in-IP) by the first-hop router, and is unicast to the group's core router. Consequently, no group state is required in the network between the first hop router and the group's core. On arriving at the core router, the data packet's outer encapsulating header is removed and the packet is disemminated over the group shared tree as described below.
非会員送付者からのデータは、最初に、ホップルータで要約しなければならなくて(IPにおけるIP)、グループのコアルータへのユニキャストです。 その結果、グループ状態は全く最初のホップルータとグループのコアの間のネットワークで必要ではありません。 コアルータに到着すると、データ・パケットの外側の要約のヘッダーを取り除きます、そして、以下で説明されるようにグループの共有された木の上でパケットをdisemminatedします。
When a multicast data packet arrives at a router, the router uses the group address as an index into the multicast forwarding cache. A copy of the incoming multicast data packet is forwarded over each interface (or to each address) listed in the entry except the incoming interface.
マルチキャストデータ・パケットがルータに到着するとき、ルータはインデックスとしてマルチキャスト推進キャッシュにグループアドレスを使用します。 入って来るインタフェースを除いて、エントリーに記載された各インタフェース(または各アドレスに)にわたって入って来るマルチキャストデータ・パケットのコピーを送ります。
Each router that comprises a CBT multicast tree, except the core router, is responsible for maintaining its upstream link, provided it has interested downstream receivers, i.e. the child interface list is not NULL. A child interface is one over which a member host is directly attached, or one over which a downstream on-tree router is attached. This "tree maintenance" is achieved by each downstream router periodically sending a CBT "keepalive" message (ECHO_REQUEST) to its upstream neighbour, i.e. its parent router on the tree. One keepalive message is sent to represent entries with the same parent, thereby improving scalability on links which are shared by many groups. On multicast capable links, a keepalive is multicast to the "all-cbt-routers" group (IANA assigned as 224.0.0.15); this has a suppressing effect on any other router for which the link is its parent link. If a parent link does not support multicast transmission, keepalives are unicast.
コアルータ以外に、CBTマルチキャスト木を包括するそれぞれのルータが上流のリンクを維持するのに原因となる、関心がある川下の受信機を持っているなら、すなわち、子供インタフェースリストはNULLではありません。 子供インタフェースは、メンバーホストが直接付けられているもの、または木の上の川下のルータが付属しているものです。 この「木の維持」は定期的にCBT"keepalive"メッセージ(ECHO_REQUEST)を上流の隣人(すなわち、木の上の親ルータ)に送るそれぞれの川下のルータによって達成されます。 同じ親と共にエントリーを表すために1つのkeepaliveメッセージを送ります、その結果、多くのグループによって共有されるリンクでスケーラビリティを改良します。 keepaliveが「オールcbtルータ」グループへのマルチキャストのできるリンクの上では、マルチキャストである、(IANAが224.0として.0を割り当てた、.15)。 これはリンクがその親リンクであるいかなる他のルータにも抑圧影響を与えます。 親リンクがマルチキャスト送信を支持しないなら、keepalivesはユニキャストです。
The receipt of a keepalive message over a valid child interface prompts a response (ECHO_REPLY), which is either unicast or multicast, as appropriate. The ECHO_REPLY message carries a list of groups for which the corresponding interface is a child interface.
有効な子供インタフェースの上のkeepaliveメッセージの領収書は応答(ECHO_REPLY)をうながします、適宜。(ユニキャストか応答はマルチキャストのどちらかです)。 ECHO_REPLYメッセージは対応するインタフェースが子供インタフェースであるグループのリストを運びます。
It cannot be assumed all of the routers on a multi-access link have a uniform view of unicast routing; this is particularly the case when a multi-access link spans two or more unicast routing domains. This could lead to multiple upstream tree branches being formed (an error condition) unless steps are taken to ensure all routers on the link agree which is the upstream router for a particular group. CBT routers attached to a multi-access link participate in an explicit election mechanism that elects a single router, the designated router (DR), as the link's upstream router for all groups. Since the DR might not be the link's best next-hop for a particular core router, this may result in join messages being re-directed back across a multi-access link. If this happens, the re-directed join message is unicast across the link by the DR to the best next-hop, thereby
マルチアクセスリンクの上のルータのすべてにはユニキャストルーティングの一定の視点があると思うことができません。 マルチアクセスリンクが2つ以上のユニキャスト経路ドメインにかかるとき、これは特にそうです。 方法がリンクの上のすべてのルータが、特定のグループのためにどれが上流のルータであるかに同意するのを保証するために取られない場合、これは形成される複数の上流の木の枝(エラー条件)に通じるかもしれません。 マルチアクセスリンクに付けられたCBTルータはただ一つのルータ、代表ルータを(DR)に選出する明白な選挙メカニズムに参加します、すべてのためのリンクの上流のルータが分類されるとき。 DRが特定のコアルータのためのリンクの最も良い次のホップでないかもしれないので、これをもたらすかもしれません。マルチアクセスリンクの向こう側に向け直されながら、メッセージを接合してください。 これが起こるなら、向け直すことは接合します。メッセージが最も良い次のホップへのDRによるリンクの向こう側のユニキャストである、その結果。
Ballardie Experimental [Page 5] RFC 2189 CBTv2 Protocl Specification September 1997
[5ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
preventing a looping scenario. This re-direction only ever applies to join messages. Whilst this is suboptimal for join messages, which are generated infrequently, multicast data never traverses a link more than once (either natively, or encapsulated).
ループシナリオを防ぎます。 このリダイレクションは、メッセージを接合するのに申し込むだけです。 これが準最適である、メッセージを接合してください。(メッセージはまれに発生して、マルチキャストデータが一度(ネイティブの、または、要約の)よりリンクを決して横断しないということです)。
In all but the exception case described above, all CBT control messages are multicast over multicast supporting links to the "all- cbt- routers" group, with IP TTL 1. The IP source address of CBT control messages is the outgoing interface of the sending router. The IP destination address of CBT control messages is either the "all- cbt- routers" group address, or a unicast address, as appropriate. All the necessary addressing information is obtained by on-tree routers as part of tree set up.
上で説明された例外ケース以外のすべてでは、すべてのCBTコントロールメッセージが「オールcbtなルータ」のグループへのリンクを支えるマルチキャストの上のマルチキャストです、IP TTL1と共に。 CBTコントロールメッセージのIPソースアドレスは送付ルータの外向的なインタフェースです。 CBTコントロールメッセージの受信者IPアドレスは、「オールcbtなルータ」のグループアドレスかユニキャストアドレスのどちらかです、適宜。 木の一部がセットアップされたので、木の上のルータはすべての必要なアドレス指定情報を得ます。
If CBT is implemented over a tunnelled topology, when sending a CBT control packet over a tunnel interface, the sending router uses as the packet's IP source address the local tunnel end point address, and the remote tunnel end point address as the packet's IP destination address.
CBTコントロールパケットをトンネルのインタフェースの上に送るとき、CBTがトンネルを堀られたトポロジーの上で実行されるなら、送付ルータはパケットのIPソースアドレスとしてローカルのトンネルエンドポイントアドレス、およびパケットの受信者IPアドレスとしてのリモートトンネルエンドポイントアドレスを使用します。
4. Protocol Specification Details
4. プロトコル仕様の詳細
Details of the CBT protocol are presented in the context of a single router implementation.
CBTプロトコルの詳細はただ一つのルータ実現の文脈に提示されます。
4.1. CBT HELLO Protocol
4.1. CBT、こんにちは、プロトコル
The HELLO protocol is used to elect a designated router (DR) on broadcast-type links. It is also used to elect a designated border router (BR) when interconnecting a CBT domain with other domains (see [5]). Alternatively, the designated BR may be elected as a matter of local policy.
HELLOプロトコルは、放送タイプリンクの(DR)に代表ルータを選出するのに使用されます。 また、他のドメインでCBTドメインとインタコネクトするとき、それは、(BR)に指定された境界ルータを選出するのに使用されます。([5])を見てください。 あるいはまた、指定されたBRはローカルの方針の問題として選出されるかもしれません。
A router represents its status as a link's DR by setting the DR-flag on that interface; a DR flag is associated with each of a router's broadcast interfaces. This flag can only assume one of two values: TRUE or FALSE. By default, this flag is FALSE.
DR-旗をそれにけしかけるのによるリンクのDRが連結するとき、ルータは状態を表します。 DR旗はそれぞれのルータの放送インタフェースに関連しています。 この旗は2つの値の1つを仮定できるだけです: 本当であるか、または誤っています。 デフォルトで、この旗はFALSEです。
A network manager can preference a router's DR eligibility by optionally configuring an HELLO preference, which is included in the router's HELLO messages. Valid configuration values range from 1 to 254 (decimal), 1 representing the "most eligible" value. In the absence of explicit configuration, a router assumes the default HELLO preference value of 255. The elected DR uses HELLO preference zero (0) in HELLO advertisements, irrespective of any configured preference. The DR continues to use preference zero for as long as it is running.
ネットワークマネージャ缶の優先、任意に、HELLO優先を構成するのによるルータのDR適任。(それは、ルータのHELLOメッセージに含まれています)。 1が「最も適任」の値を表して、有効な構成は1〜254までの範囲(10進)を評価します。 明白な構成がないとき、ルータは、デフォルトHELLO好みが255の値であると仮定します。 選出されたDRはどんな構成された好みの如何にかかわらずHELLO広告でHELLO好みゼロの(0)を使用します。 DRは、走っている限り、好みゼロを使用し続けています。
Ballardie Experimental [Page 6] RFC 2189 CBTv2 Protocl Specification September 1997
[6ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
HELLO messages are multicast periodically to the all-cbt-routers group, 224.0.0.15, using IP TTL 1. The advertisement period is [HELLO_INTERVAL] seconds.
定期的にHELLOメッセージはオールcbtルータグループ、224.0へのマルチキャストです。.0 .15 IP TTL1を使用します。 広告の期間は[HELLO_INTERVAL]秒です。
HELLO messages have a suppressing effect on those routers which would advertise a "lesser preference" in their HELLO messages; a router resets its [HELLO_INTERVAL] if the received HELLO is "better" than its own. Thus, in steady state, the HELLO protocol incurs very little traffic overhead.
HELLOメッセージはそれらのHELLOメッセージにおける「より少ない好み」の広告を出すそれらのルータに抑圧影響を与えます。 容認されたHELLOが「それ自身のより良い」なら、ルータは[HELLO_INTERVAL]をリセットします。 したがって、定常状態では、HELLOプロトコルはほとんど交通オーバーヘッドを被りません。
The DR election winner is that which advertises the lowest HELLO preference, or the lowest-addressed in the event of a tie.
DR当選者は、広告を出す中でHELLO好み最も低いそれ、または繋がりの場合、最も低く記述です。
The situation where two or more routers attached to the same broadcast link areadvertising HELLO preference 0 should never arise. However, should this situation arise, all but the lowest addressed zero advertising router relinquishes its claim as DR immediately by unsetting the DR flag on the corresponding interface. The relinquishing router(s) subsequently advertise their previously used preference value in HELLO advertisements.
2つ以上のルータが同じ放送リンクareadvertising HELLO好み0に付いた状況は決して起こるべきではありません。 ほとんど最も低いのがこの状況が起こるならどのようにゼロを記述したとしても、すぐDRを非設定するのによるDRが対応するインタフェースで弛むとき、広告ルータは要求を放棄します。 放棄ルータは次に、HELLO広告におけるそれらの以前中古の好みの値の広告を出します。
4.1.1. Sending HELLOs
4.1.1. 送付HELLOs
When a router starts up, it multicasts two HELLO messages over each of its broadcast interfaces in successsion. The DR flag is initially unset (FALSE) on each broadcast interface. This avoids the situation in which each router on a multi-access subnet believes it is the DR, thus preventing the multiple forwarding of join-requests should they arrive during this start up period. If no "better" HELLO message is received after HOLDTIME seconds, the router assumes the role of DR on the corresponding interface.
いつルータは始動して、それはsuccesssionのそれぞれの放送インタフェースの上のマルチキャストtwo HELLOメッセージであるか。 DR旗は初めは各放送でのunset(FALSE)が連結するということです。 これはマルチアクセスサブネットに関する各ルータがそれがDRであると信じている状況を避けます、その結果、それらがこの始めの間、期間で到着するなら、要求に参加する複数の推進を防ぎます。 HOLDTIME秒以降「より良い」HELLOメッセージを全く受け取らないなら、ルータは対応するインタフェースのDRの役割を引き受けます。
A router sends an HELLO message whenever its [HELLO_INTERVAL] expires. Whenever a router sends an HELLO message, it resets its hello timer.
[HELLO_INTERVAL]が期限が切れるときはいつも、ルータはHELLOメッセージを送ります。 ルータがHELLOメッセージを送って、それがリセットであることのときはいつも、それ、こんにちは、タイマ。
4.1.2. Receiving HELLOs
4.1.2. HELLOsを受けます。
A router does not respond to an HELLO message if the received HELLO is "better" than its own, or equally preferenced but lower addressed.
容認されたHELLOが記述されていた状態で「それ自身のより良い」か、等しくpreferencedされていますが、または低いなら、ルータはHELLOメッセージに応じません。
A router must respond to an HELLO message if that received is lesser preferenced (or equally preferenced but higher addressed) than would be sent by this router over the same interface. This response is sent on expiry of an interval timer which is set between zero (0) and [HOLDTIME] seconds when the lesser preferenced HELLO message is received.
受け取られたそれがこのルータで同じインタフェースの上に送るだろうよりpreferencedされていた状態で(または、しかし、等しく記述されていた状態で、より高くpreferencedされます)少ないなら、ルータはHELLOメッセージに応じなければなりません。 より少ないpreferenced HELLOメッセージが受信されているとき(0)と[HOLDTIME]秒の間ではなく設定されるインタバルタイマの満期にこの応答を送ります。
Ballardie Experimental [Page 7] RFC 2189 CBTv2 Protocl Specification September 1997
[7ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
4.2. JOIN_REQUEST Processing
4.2. _要求処理に参加してください。
A JOIN_REQUEST is the CBT control message used to register a member host's interest in joining the distribution tree for the group.
JOIN_REQUESTはグループのために分配木に合流することにおいてメンバーホストの利益のためを示すのに使用されるCBTコントロールメッセージです。
4.2.1. Sending JOIN_REQUESTs
4.2.1. 発信して、_要求に参加してください。
A JOIN_REQUEST can only ever be originated by a leaf router, i.e. a router with directly attached member hosts. This join message is sent hop-by-hop towards the core router for the group (see section 8). The originating router caches <group, NULL, upstream interface> state for each join it originates. This state is known as "transient join state". The absence of a "downstream interface" (NULL) indicates that this router is the join message originator, and is therefore responsible for any retransmissions of this message if a response is not received within [RTX_INTERVAL]. It is an error if no response is received after [JOIN_TIMEOUT] seconds. If this error condition occurs, the joining process may be re-invoked by the receipt of the next IGMP host membership report from a locally attached member host.
すなわち、葉のルータ、直接付属しているメンバーホストがいるルータは今までに、JOIN_REQUESTを溯源できるだけです。 これは接合します。ホップごとにグループのためにコアルータに向かってメッセージを送ります(セクション8を見てください)。 NULL、由来しているルータは<グループをキャッシュして、それぞれがそれを接合するので、上流のインタフェース>状態は由来します。 この状態が知られている、「一時的である、状態に加わってください、」 「川下のインタフェース」(NULL)の不在が、このルータがそうであることを示す、メッセージ創始者に加わって、したがって、a応答が[RTX_INTERVAL]の中で受けられないなら、このメッセージのどんな「再-トランスミッション」にも責任があります。 [JOIN_TIMEOUT]秒以降応答を全く受けないなら、それは誤りです。 このエラー条件が起こるなら、接合の過程は局所的に添付のメンバーホストから次のIGMPホスト会員資格レポートの領収書で再呼び出されるかもしれません。
Note that if the interface over which a JOIN_REQUEST is to be sent supports multicast, the JOIN_REQUEST is multicast to the all-cbt- routers group, using IP TTL 1. If the link does not support multicast, the JOIN_REQUEST is unicast to the next hop on the unicast path to the group's core.
JOIN_REQUESTが送られることになっているインタフェースがマルチキャスト、JOIN_REQUESTを支持するならオールcbtルータへのマルチキャストは分類されます、IP TTL1を使用してことである注意。 リンクがマルチキャストを支持しないなら、JOIN_REQUESTはグループのコアへのユニキャスト経路の次のホップへのユニキャストです。
4.2.2. Receiving JOIN_REQUESTs
4.2.2. 受信して、_要求に参加してください。
On broadcast links, JOIN_REQUESTs which are multicast may only be forwarded by the link's DR. Other routers attached to the link may process the join (see below). JOIN_REQUESTs which are multicast over a point-to-point link are only processed by the router on the link which does not have a local interface corresponding to the join's network layer (IP) source address. Unicast JOIN_REQUESTs may only be processed by the router which has a local interface corresponding to the join's network layer (IP) destination address.
放送リンクの上では、マルチキャストであるJOIN_REQUESTsはリンクのDRによって進められるだけであるかもしれません。リンクに付けられた他のルータが処理されるかもしれない、接合してください(以下を見てください)。 ポイントツーポイント接続の上のマルチキャストであるJOIN_REQUESTsが局所界面を対応するようにしないリンクの上のルータによって処理されるだけである、接合、ネットワーク層(IP)ソースアドレスはそうです。 ユニキャストJOIN_REQUESTsが局所界面を対応するようにするルータによって処理されるだけであるかもしれない、接合、目的地が記述するネットワーク層(IP)はそうです。
With regard to forwarding a received JOIN_REQUEST, if the receiving router is not on-tree for the group, and is not the group's core router, and has not already forwarded a join for the same group, the join is forwarded to the next hop on the path towards the core. The join is multicast, or unicast, according to whether the outgoing interface supports multicast. The router caches the following information with respect to the forwarded join: <group, downstream interface, upstream interface>. Subsequent JOIN_REQUESTs received for the same group are cached until this router has received a JOIN_ACK for the previously sent join, at which time any cached joins can also be acknowledged.
接合してください。受信ルータがグループのために木でなく、またグループのコアルータでなく、また既にaを進めていないなら容認されたJOIN_REQUESTを進めることに関して、同じグループのために接合してください、コアに向かった経路の次のホップに送ります。 接合、マルチキャスト、または外向的なインタフェースがマルチキャストを支持するかどうかに従ったユニキャストがそうです。 進めることの以下の情報が接合するルータキャッシュ: <グループ、川下のインタフェース、上流のインタフェース>。 このルータが以前に送るためにJOIN_ACKを受けるまで同じグループがキャッシュされるので、REQUESTsが受けたその後のJOIN_は接合して、また、何かがキャッシュしたどの時間が接合するかで承認できます。
Ballardie Experimental [Page 8] RFC 2189 CBTv2 Protocl Specification September 1997
[8ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
If this transient join state is not "confirmed" with a join acknowledgement (JOIN_ACK) message from upstream, the state is timed out after [TRANSIENT_TIMEOUT] seconds.
状態はaで「確認されません」。これほど一時的であるなら接合してください、[TRANSIENT_TIMEOUT]秒以降外で上流からのメッセージ、状態が調節されているという承認(JOIN_ACK)に参加してください。
If the receiving router is the group's core router, the join is "terminated" and acknowledged by means of a JOIN_ACK. Similarly, if the router is on-tree and the JOIN_REQUEST arrives over an interface that is not the upstream interface for the group, the join is acknowledged.
受信ルータがグループのコアルータであるなら接合する、「終えられ」て、JOIN_ACKによって承認されて、接合してください。 接合してください。ルータが木であり、JOIN_REQUESTがインタフェースの上で到着するなら同様に、それがグループのための上流のインタフェースでない、承認されます。
If a JOIN_REQUEST for the same group is scheduled to be sent over the corresponding interface (i.e. awaiting a timer expiry), the JOIN_REQUEST is unscheduled.
同じグループのためのJOIN_REQUESTによって対応するインタフェース(すなわち、タイマ満期を待つ)の上に送られる予定であるなら、JOIN_REQUESTは予定外です。
If this router has a cache-deletion-timer [CACHE_DEL_TIMER] running on the arrival interface for the group specified in a multicast join, the timer is cancelled.
このルータがマルチキャストで指定されたグループのための到着インタフェースで走ると接合するキャッシュ削除タイマ[CACHE_デル_TIMER]を持っているなら、タイマは取り消されます。
4.3. JOIN_ACK Processing
4.3. _ACK処理に参加してください。
A JOIN_ACK is the mechanism by which an interface is added to a router's multicast forwarding cache; thus, the interface becomes part of the group distribution tree.
JOIN_ACKはインタフェースがルータのマルチキャスト推進キャッシュに加えられるメカニズムです。 したがって、インタフェースはグループ分配木の一部になります。
4.3.1. Sending JOIN_ACKs
4.3.1. 発信して、_ACKsを接合してください。
The JOIN_ACK is sent over the same interface as the corresponding JOIN_REQUEST was received. The sending of the acknowledgement causes the router to add the interface to its child interface list in its forwarding cache for the group, if it is not already.
対応するJOIN_REQUESTを受け取ったような同じインタフェースの上にJOIN_ACKを送ります。 ルータはグループのために承認の発信で推進キャッシュで子供インタフェースリストにインタフェースを追加します、初霜でないなら。
A JOIN_ACK is multicast or unicast, according to whether the outgoing interface supports multicast transmission or not.
JOIN_ACKはマルチキャストか外向的なインタフェースがマルチキャスト送信を支持するかどうかに従って、ユニキャストです。
4.3.2. Receiving JOIN_ACKs
4.3.2. 受信して、_ACKsを接合してください。
The group and arrival interface must be matched to a <group, ...., upstream interface> from the router's cached transient state. If no match is found, the JOIN_ACK is discarded. If a match is found, a CBT forwarding cache entry for the group is created, with "upstream interface" marked as the group's parent interface.
グループと到着インタフェースに<グループに匹敵しなければならない、…, ルータからの上流のインタフェース>は一時的な状態をキャッシュしました。 マッチが全く見つけられないなら、JOIN_ACKは捨てられます。 マッチが見つけられるなら、グループのためにキャッシュエントリーを進めるCBTは作成されます、「上流のインタフェース」がグループの親インタフェースとしてマークされている状態で。
If "downstream interface" in the cached transient state is NULL, the JOIN_ACK has reached the originator of the corresponding JOIN_REQUEST; the JOIN_ACK is not forwarded downstream. If "downstream interface" is non-NULL, a JOIN_ACK for the group is sent
キャッシュされた一時的な状態の「川下のインタフェース」がNULLであるなら、JOIN_ACKは対応するJOIN_REQUESTの創始者に届きました。 JOIN_ACKは川下に送られません。 「川下のインタフェース」が非NULLであるなら、グループのためのJOIN_ACKを送ります。
Ballardie Experimental [Page 9] RFC 2189 CBTv2 Protocl Specification September 1997
[9ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
over the "downstream interface" (multicast or unicast, accordingly). This interface is installed in the child interface list of the group's forwarding cache entry.
「川下のインタフェース」(それに従ってマルチキャストかユニキャスト)の上で。 このインタフェースはグループの推進キャッシュエントリーの子供インタフェースリストにインストールされます。
Once transient state has been confirmed by transferring it to the forwarding cache, the transient state is deleted.
一時的な状態が推進キャッシュにそれを移すことによっていったん確認されると、一時的な状態は削除されます。
4.4. QUIT_NOTIFICATION Processing
4.4. _通知処理をやめてください。
A CBT tree is "pruned" in the direction downstream-to-upstream whenever a CBT router's child interface list for a group becomes NULL.
グループのためのCBTルータの子供インタフェースリストがNULLになるときはいつも、CBT木は指示の川下から上流で「剪定されます」。
4.4.1. Sending QUIT_NOTIFICATIONs
4.4.1. 発信は_通知をやめました。
A QUIT_NOTIFICATION is sent to a router's parent router on the tree whenever the router's child interface list becomes NULL. If the link over which the quit is to be sent supports multicast transmission, if the sending router is the link's DR the quit is unicast, otherwise it is multicast.
ルータの子供インタフェースリストがNULLになるときはいつも、木でQUIT_NOTIFICATIONをルータの親ルータに送ります。 辞任が送られることになっているリンクがマルチキャスト送信を支持するなら、送付ルータがリンクのDRであるなら辞任がユニキャストである、さもなければ、それはマルチキャストです。
A QUIT_NOTIFICATION is not acknowledged; once sent, all information pertaining to the group it represents is deleted from the forwarding cache immediately.
QUIT_NOTIFICATIONは承認されません。 いったん送ると、すぐに、推進キャッシュからそれが代表するグループに関係するすべての情報を削除します。
To help ensure consistency between a child and parent router given the potential for loss of a QUIT_NOTIFICATION, a total of [MAX_RTX] QUIT_NOTIFICATIONs are sent, each HOLDTIME seconds after the previous one.
_QUIT_NOTIFICATIONの損失の可能性、[マックス_RTX]QUITの合計を考えて、子供と親ルータの間の一貫性を確実にするのを助けるために、NOTIFICATIONsを送ります、前のものの秒後の各HOLDTIME。
The sending of a quit (the first) also invokes the sending of a FLUSH_TREE message over each downstream interface for the corresponding group.
また、やめられたa(1番目)の発信は対応するグループのためにそれぞれの川下のインタフェースにわたってFLUSH_TREEメッセージの発信を呼び出します。
4.4.2. Receiving QUIT_NOTIFICATIONs
4.4.2. 受信は_通知をやめました。
The group reported in the QUIT_NOTIFICATION must be matched with a forwarding cache entry. If no match is found, the QUIT_NOTIFICATION is ignored and discarded. If a match is found, if the arrival interface is a valid child interface in the group entry, how the router proceeds depends on whether the QUIT_NOTIFICATION was multicast or unicast.
グループは、QUITで_推進キャッシュエントリーにNOTIFICATIONを合わせなければならないと報告しました。 マッチが全く見つけられないなら、QUIT_NOTIFICATIONは無視されて、捨てられます。 マッチが到着インタフェースがグループエントリーで有効な子供インタフェースであるなら見つけられるなら、ルータがどう続くかはQUIT_NOTIFICATIONがマルチキャストかそれともユニキャストであったかによります。
If the QUIT_NOTIFICATION was unicast, the corresponding child interface is deleted from the group's forwarding cache entry, and no further processing is required.
QUIT_NOTIFICATIONがユニキャストであったなら、対応する子供インタフェースはグループの推進キャッシュエントリーから削除されます、そして、どんなより遠い処理も必要ではありません。
Ballardie Experimental [Page 10] RFC 2189 CBTv2 Protocl Specification September 1997
[10ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
If the QUIT_NOTIFICATION was multicast, and the arrival interface is a valid child interface for the specified group, the router sets a cache-deletion-timer [CACHE_DEL_TIMER].
QUIT_NOTIFICATIONがマルチキャストであり、到着インタフェースが指定されたグループに、有効な子供インタフェースであるなら、ルータはキャッシュ削除タイマ[CACHE_デル_TIMER]を設定します。
Because this router might be acting as a parent router for multiple downstream routers attached to the arrival link, [CACHE_DEL_TIMER] interval gives those routers that did not send the QUIT_NOTIFICA- TION, but received it over their parent interface, the opportunity to ensure that the parent router does not remove the link from its child interface list. Therefore, on receipt of a multicast QUIT_NOTIFICATION over a parent interface, a receiving router schedules a JOIN_REQUEST for the group for sending at a random interval between 0 (zero) and HOLDTIME seconds. If a multicast JOIN_REQUEST is received over the corresponding interface (parent) for the same group before this router sends its own scheduled JOIN_REQUEST, it unschedules the multicasting of its own JOIN_REQUEST.
複数の川下のルータのための親ルータが到着リンクに付いたのでこのルータが行動しているかもしれないので、[CACHE_デル_TIMER]間隔はQUIT_NOTIFICA- TIONを送りませんでしたが、それらの親インタフェース(親ルータが子供インタフェースリストからリンクを取り外さないのを保証する機会)の上にそれを受けたそれらのルータを与えます。 したがって、親インタフェースの上のaマルチキャストQUIT_NOTIFICATIONを受け取り次第、受信ルータは0(ゼロ)とHOLDTIME秒の無作為の間隔で、発信するためのグループのためにJOIN_REQUESTの計画をします。 このルータがそれ自身の予定されているJOIN_REQUESTを送る前に同じグループのために対応するインタフェース(親)の上にaマルチキャストJOIN_REQUESTを受け取るなら、それはそれ自身のJOIN_REQUESTのマルチキャスティングの非計画をします。
4.5. ECHO_REQUEST Processing
4.5. エコー_要求処理
The ECHO_REQUEST message allows a child to monitor reachability to its parent router for a group (or range of groups if the parent router is the parent for multiple groups). Group information is not carried in ECHO_REQUEST messages.
ECHO_REQUESTメッセージで、子供はグループのために親ルータに可到達性をモニターできます(グループの範囲は親ルータが倍数のための親であるなら分類されます)。 グループ情報はECHO_REQUESTメッセージで運ばれません。
4.5.1. Sending ECHO_REQUESTs
4.5.1. 送付エコー_要求
Whenever a router creates a forwarding cache entry due to the receipt of a JOIN_ACK, the router begins the periodic sending of ECHO_REQUEST messages over its parent interface. The ECHO_REQUEST is multicast to the "all-cbt-routers" group over multicast-capable interfaces, unless the sending router is the DR on the interface over which the ECHO_REQUEST is being sent, in which case it is unicast (as is the corresponding ECHO_REPLY).
JOIN_ACKの領収書のため推進キャッシュエントリーを作成するときはいつも、ルータは親インタフェースの上でECHO_REQUESTメッセージの周期的な発信を始めます。 ECHO_REQUESTがマルチキャストできるインタフェースの上の「オールcbtルータ」グループへのマルチキャストである、送付ルータがECHO_REQUESTが送られるインタフェースのDRでないなら、その場合、それはユニキャスト(対応するECHO_REPLYのような)です。
ECHO_REQUEST messages are sent at [ECHO_INTERVAL] second intervals.
[ECHO_INTERVAL]2番目の間隔を置いて、ECHO_REQUESTメッセージを送ります。
Whenever an ECHO_REQUEST is sent, [ECHO_INTERVAL] is reset.
ECHO_REQUESTを送るときはいつも、[ECHO_INTERVAL]はリセットされます。
If no response is forthcoming, any groups present on the parent interface will eventually expire [GROUP_EXPIRE_TIME]. This results in the sending of a QUIT_NOTIFICATION upstream, and sends a FLUSH_TREE message downstream for each group for which the upstream interface was the parent interface.
どんな応答も用意されていないと、親インタフェースの現在のどんなグループも結局、[GROUP_EXPIRE_タイム誌]を吐き出すでしょう。 これは、上流へQUIT_NOTIFICATIONの発信をもたらして、上流のインタフェースが親インタフェースであった各グループのためにFLUSH_TREEメッセージを川下に送ります。
Ballardie Experimental [Page 11] RFC 2189 CBTv2 Protocl Specification September 1997
[11ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
4.5.2. Receiving ECHO_REQUESTs
4.5.2. エコー_要求を受け取ります。
If an ECHO_REQUEST is received over any valid child interface, the receiving router schedules an ECHO_REPLY message for sending over the same interface; the scheduled interval is between 0 (zero) and HOLDTIME seconds. This message is multicast to the "all-cbt-routers" group over multicast-capable interfaces, and unicast otherwise.
どんな有効な子供インタフェースにわたってもECHO_REQUESTを受け取るなら、受信ルータは同じインタフェースを移動することへのECHO_REPLYメッセージの計画をします。 0(ゼロ)とHOLDTIME秒の間には、予定されている間隔があります。 そうでなければ、このメッセージはマルチキャストできるインタフェース、およびユニキャストの上の「オールcbtルータ」グループへのマルチキャストです。
If a multicast ECHO_REQUEST message arrives via any valid parent interface, the router resets its [ECHO_INTERVAL] timer for that upstream interface, thereby suppressing the sending of its own ECHO_REQUEST over that upstream interface.
マルチキャストECHO_REQUESTメッセージがどんな有効な親インタフェースを通しても到着するなら、ルータは[ECHO_INTERVAL]タイマをその上流のインタフェースにリセットします、その結果、その上流のインタフェースの上でそれ自身のECHO_REQUESTの発信を抑圧します。
4.6. ECHO_REPLY Processing
4.6. エコー_回答処理
ECHO_REPLY messages allow a child to monitor the reachability of its parent, and help ensure the group state information is consistent between them.
ECHO_REPLYメッセージは、子供が親の可到達性をモニターするのを許容して、グループ州の情報がそれらの間で一貫しているのを確実にするのを助けます。
4.6.1. Sending ECHO_REPLY messages
4.6.1. 送付ECHO_REPLYメッセージ
An ECHO_REPLY message is sent in response to receiving an ECHO_REQUEST message, provided the ECHO_REQUEST is received over any one of this router's valid child interfaces. An ECHO_REPLY reports all groups for which the link is its child.
ECHO_REQUESTメッセージを受け取ることに対応してECHO_REPLYメッセージを送ります、このルータの有効な子供インタフェースのどれかの上にECHO_REQUESTを受け取るなら。 ECHO_REPLYはリンクがその子供であるすべてのグループを報告します。
ECHO_REPLY messages are unicast or multicast, as appropriate.
ECHO_REPLYメッセージは、適宜ユニキャストかマルチキャストです。
4.6.2. Receiving ECHO_REPLY messages
4.6.2. ECHO_REPLYメッセージを受け取ります。
An ECHO_REPLY message must be received via a valid parent interface.
有効な親インタフェースを通してECHO_REPLYメッセージを受け取らなければなりません。
For each group reported in an ECHO_REPLY, the downstream router attempts to match the group with one in its forwarding cache for which the arrival interface is the group's parent interface. For each successful match, the entry is "refreshed". If however, after [GROUP_EXPIRE_TIME] seconds a group has not been "refreshed", a QUIT_NOTIFICATION is sent upstream, and a FLUSH_TREE message is sent downstream, for the group.
ECHO_REPLYで報告された各グループのために、川下のルータは、到着インタフェースがグループの親インタフェースである推進キャッシュでグループを1つに合わせるのを試みます。 それぞれのうまくいっているマッチに関しては、エントリーは「すっきりです」。 しかしながら、[GROUP_EXPIRE_タイム誌]秒以降グループを「リフレッシュしていない」なら、上流へQUIT_NOTIFICATIONを送ります、そして、FLUSH_TREEメッセージを川下に送ります、グループのために。
If this router has directly attached members for any of the flushed groups, the receipt of an IGMP host membership report for any of those groups will prompt this router to rejoin the corresponding tree(s).
このルータでいずれのための直接付属しているメンバーがいる、紅潮は分類されて、それらのグループのどれかのIGMPホスト会員資格レポートの領収書は、このルータが対応する木に再び加わるようにうながすでしょう。
Ballardie Experimental [Page 12] RFC 2189 CBTv2 Protocl Specification September 1997
[12ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
4.7. FLUSH_TREE Processing
4.7. 水洗_木の処理
The FLUSH_TREE (flush) message is the mechanism by which a router invokes the tearing down of all its downstream branches for a particular group. The flush message is multicast to the "all-cbt- routers" group when sent over multicast-capable interfaces, and unicast otherwise.
FLUSH_TREE(平らである)メッセージはルータが下に裂け目を呼び出す特定のグループのためのすべての川下のブランチのメカニズムです。 別の方法でマルチキャストできるインタフェース、およびユニキャストの上に送ると、豊富なメッセージは「オールcbtなルータ」のグループへのマルチキャストです。
4.7.1. Sending FLUSH_TREE messages
4.7.1. 送付FLUSH_TREEメッセージ
A FLUSH_TREE message is sent over each downstream (child) interface when a router has lost reachability with its parent router for the group (detected via ECHO_REQUEST and ECHO_REPLY messages). All group state is removed from an interface over which a flush message is sent. A flush can specify a single group, or all groups (INADDR_ANY).
ルータがグループ(ECHO_REQUESTとECHO_REPLYを通して、メッセージを検出する)のための親ルータに可到達性を失ったとき、それぞれの川下の(子供)インタフェースにわたってFLUSH_TREEメッセージを送ります。 豊富なメッセージが送られるインタフェースからすべてのグループ状態を取り除きます。 水洗がただ一つのグループ、またはすべてのグループを指定できる、(INADDR、_少しも)
4.7.2. Receiving FLUSH_TREE messages
4.7.2. FLUSH_TREEメッセージを受け取ります。
A FLUSH_TREE message must be received over the parent interface for the specified group, otherwise the message is discarded.
指定されたグループのためにFLUSH_TREEメッセージを親インタフェースの上に受け取らなければなりません。さもなければ、メッセージは捨てます。
The flush message must be forwarded over each child interface for the specified group.
指定されたグループのためにそれぞれの子供インタフェースにわたって豊富なメッセージを転送しなければなりません。
Once the flush message has been forwarded, all state for the group is removed from the router's forwarding cache.
いったん豊富なメッセージを転送すると、ルータの推進キャッシュからグループのためのすべての状態を取り除きます。
5. Non-Member Sending
5. 非会員発信
Data can be sent to a CBT tree by a sender not attached to the group tree. The sending host originates native multicast data, which is promiscuously received by a local router, which must be CBT capable. It is assumed the local CBT router knows about the relevant <core, group> mapping, and thus can encapsulate (IP-in-IP) the data packet and unicast it to the corresponding core router. On arriving at the core router, the data packet is decapsulated and disemminated over the group tree in the manner already described.
グループ木に付けられなかった送付者はCBT木にデータを送ることができます。 送付ホストは固有のマルチキャストデータを溯源します。(データはローカルルータによって乱雑に受け取られます)。(それは、できるCBTであるに違いありません)。 地方のCBTルータが関連<コア、それが>が写像して、その結果データ・パケットとユニキャストをカプセルに入れることができる(IPにおけるIP)グループに関して対応するコアルータに知ると思われます。 コアルータに到着すると、データ・パケットは、decapsulatedされてグループ木の上で既に説明された方法でdisemminatedされています。
6. Timers and Default Values
6. タイマとデフォルト値
This section provides a summary of the timers described above, together with their recommended default values. Other values may be configured; if so, the values used should be consistent across all CBT routers attached to the same network.
このセクションはそれらのお勧めのデフォルト値と共に上で説明されたタイマの概要を提供します。 他の値は構成されるかもしれません。 そうだとすれば、使用される値は同じネットワークに付けられたすべてのCBTルータの向こう側に一貫しているべきです。
o [HELLO_INTERVAL]: the interval between sending an HELLO message.
Default: 60 seconds.
o [こんにちは、_間隔]、: HELLOメッセージを送るところの間隔。 デフォルト: 60秒。
Ballardie Experimental [Page 13] RFC 2189 CBTv2 Protocl Specification September 1997
[13ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
o [HELLO_PREFERENCE]: Default: 255.
o [こんにちは、_好み]、: デフォルト: 255.
o [HOLDTIME]: generic response interval. Default: 3 seconds.
o [HOLDTIME]: ジェネリック応答間隔。 デフォルト: 3秒。
o [MAX_RTX]: default maximum number of retransmissions. Default 3.
o [マックス_RTX]: 最大数のデフォルト「再-トランスミッション」。 デフォルト3。
o [RTX_INTERVAL]: message retransmission time. Default: 5 seconds.
o [RTX_間隔]: メッセージの再送時間。 デフォルト: 5秒。
o [JOIN_TIMEOUT]: raise exception due to tree join failure.
Default: 3.5 times [RTX_INTERVAL].
o [_タイムアウトを接合します]: 木による昇給例外は失敗を接合します。 デフォルト: 3.5回[RTX_間隔]。
o [TRANSIENT_TIMEOUT]: delete (unconfirmed) transient state.
Default: (1.5*RTX_INTERVAL) seconds.
o [一時的な_タイムアウト]: (未確認)の一時的な状態を削除してください。 デフォルト: (1.5*RTX_間隔) 秒。
o [CACHE_DEL_TIMER]: remove child interface from forwarding cache.
Default: (1.5*HOLDTIME) seconds.
o [キャッシュ_デル_タイマ]: 推進キャッシュから子供インタフェースを取り除いてください。 デフォルト: (1.5*HOLDTIME) 秒。
o [GROUP_EXPIRE_TIME]: time to send a QUIT_NOTIFICATION to our
non-responding parent. Default: (1.5*ECHO_INTERVAL).
o [グループ_は_時間を吐き出します]: QUIT_NOTIFICATIONを私たちの無回答の親に送る時間。 デフォルト: (1.5*エコー_間隔。)
o [ECHO_INTERVAL]: interval between sending ECHO_REQUEST to parent
routers. Default: 60 seconds.
o [エコー_間隔]: ECHO_REQUESTを親ルータに送るところの間隔。 デフォルト: 60秒。
o [EXPECTED_REPLY_TIME]: consider parent unreachable. Default: 70
seconds.
o [予想された_回答_時間]: 親が手が届かないと考えてください。 デフォルト: 70秒。
7. CBT Packet Formats and Message Types
7. CBTパケット・フォーマットとメッセージタイプ
CBT control packets are encapsulated in IP. CBT has been assigned IP protocol number 7 by IANA [4].
CBTコントロールパケットはIPでカプセルに入れられます。 IPプロトコル番号7はIANA[4]によってCBTに割り当てられました。
7.1. CBT Common Control Packet Header
7.1. CBT共通制御機構パケットのヘッダー
All CBT control messages have a common fixed length header.
すべてのCBTコントロールメッセージには、一般的な固定長ヘッダーがあります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| vers | type | addr len | 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | vers| タイプ| addr len| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. CBT Common Control Packet Header
図1。 CBT共通制御機構パケットのヘッダー
This CBT specification is version 2.
このCBT仕様はバージョン2です。
Ballardie Experimental [Page 14] RFC 2189 CBTv2 Protocl Specification September 1997
[14ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
CBT packet types are:
CBTパケットタイプは以下の通りです。
o type 0: HELLO
o 0はタイプします: こんにちは
o type 1: JOIN_REQUEST
o タイプ1: _要求に参加してください。
o type 2: JOIN_ACK
o 2はタイプします: _ACKを接合してください。
o type 3: QUIT_NOTIFICATION
o 3はタイプします: _通知をやめてください。
o type 4: ECHO_REQUEST
o 4はタイプします: エコー_要求
o type 5: ECHO_REPLY
o 5はタイプします: エコー_回答
o type 6: FLUSH_TREE
o 6はタイプします: 水洗_木
o type 7: Bootstrap Message (optional)
o 7はタイプします: メッセージを独力で進んでください。(任意)です。
o type 8: Candidate Core Advertisement (optional)
o 8はタイプします: 候補コア広告(任意)です。
o Addr Length: address length in bytes of unicast or multicast
addresses carried in the control packet.
o Addrの長さ: バイトのユニキャストかマルチキャストアドレスのアドレスの長さはコントロールパケットで運ばれました。
o Checksum: the 16-bit one's complement of the one's complement
sum of the entire CBT control packet.
o チェックサム: 全体のCBTコントロールパケットの1の補数合計の16ビットの1の補数。
7.2. HELLO Packet Format
7.2. こんにちは、パケット・フォーマット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBT Control Packet Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | option type | option len | option value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CBTコントロールパケットのヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 好み| オプションタイプ| オプションlen| オプション価値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. HELLO Packet Format
図2。 こんにちは、パケット・フォーマット
HELLO Packet Field Definitions:
こんにちは、パケットフィールド定義:
o preference: sender's HELLO preference.
o 好み: 送付者のHELLO好み。
o option type: the type of option present in the "option value"
field. One option type is currently defined: option type 0
(zero) = BR_HELLO; option value 0 (zero); option length 0
(zero). This option type is used with HELLO messages sent by a
o オプションタイプ: オプションのタイプは「オプション価値」で分野を提示します。 1つのオプションタイプが現在、定義されます: オプションタイプ0(ゼロ)はBR_HELLOと等しいです。 オプション価値0(ゼロ)。 オプション長さ0(ゼロ)。 このオプションタイプはaで送るHELLOメッセージと共に使用されます。
Ballardie Experimental [Page 15] RFC 2189 CBTv2 Protocl Specification September 1997
[15ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
border router (BR) as part of designated BR election (see [5]).
指定されたBR選挙の一部としてルータ(BR)に接してください。([5])を見てください。
o option len: length of the "option value" field in bytes.
o オプションlen: バイトで表現される「オプション価値」分野の長さ。
o option value: variable length field carrying the option value.
o オプション価値: オプション価値を運ぶ可変長フィールド。
7.3. JOIN_REQUEST Packet Format
7.3. _リクエスト・パケット形式を接合してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBT Control Packet Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| group address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| target router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| originating router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option type | option len | option value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CBTコントロールパケットのヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目標ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルータを溯源します。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションタイプ| オプションlen| オプション価値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. JOIN_REQUEST Packet Format
図3。 _リクエスト・パケット形式を接合してください。
JOIN_REQUEST Field Definitions
_要求フィールド定義に参加してください。
o group address: multicast group address of the group being joined.
For a "wildcard" join (see [5]), this field contains the value of
INADDR_ANY.
o アドレスを分類してください: 加わられるグループのマルチキャストグループアドレス。 「ワイルドカード」に関して接合してください。([5]) この分野が_少しもINADDRの値を含むのを確実にしてください。
o target router: target (core) router for the group.
o ルータを狙ってください: グループのために(コア)ルータを狙ってください。
o originating router: router that originated this JOIN_REQUEST.
o ルータを溯源します: このJOIN_REQUESTを溯源したルータ。
o option type, option len, option value: see HELLO packet format,
section 7.2.
o オプションタイプ、オプションlen、オプション価値: HELLOパケット・フォーマット、セクション7.2を見てください。
7.4. JOIN_ACK Packet Format
7.4. _ACKパケット・フォーマットを接合してください。
JOIN_ACK Field Definitions
_ACKフィールド定義に参加してください。
o group address: multicast group address of the group being joined.
o アドレスを分類してください: 加わられるグループのマルチキャストグループアドレス。
o target router: router (DR) that originated the corresponding
JOIN_REQUEST.
o ルータを狙ってください: 対応するJOIN_REQUESTを溯源したルータ(DR)。
Ballardie Experimental [Page 16] RFC 2189 CBTv2 Protocl Specification September 1997
[16ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBT Control Packet Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| group address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| target router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option type | option len | option value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CBTコントロールパケットのヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目標ルータ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプションタイプ| オプションlen| オプション価値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. JOIN_ACK Packet Format
o option type, option len, option value: see HELLO packet format,
section 7.2.
図4。 JOIN_ACK Packet Format oオプションタイプ、オプションlen、オプション価値: HELLOパケット・フォーマット、セクション7.2を見てください。
7.5. QUIT_NOTIFICATION Packet Format
7.5. _通知パケット・フォーマットをやめてください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBT Control Packet Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| group address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| originating child router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CBTコントロールパケットのヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 子供ルータを溯源します。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. QUIT_NOTIFICATION Packet Format
図5。 _通知パケット・フォーマットをやめてください。
QUIT_NOTIFICATION Field Definitions
_通知フィールド定義をやめてください。
o group address: multicast group address of the group being joined.
o アドレスを分類してください: 加わられるグループのマルチキャストグループアドレス。
o originating child router: address of the router that
originates the QUIT_NOTIFICATION.
o 子供ルータを溯源します: QUIT_NOTIFICATIONを溯源するルータのアドレス。
Ballardie Experimental [Page 17] RFC 2189 CBTv2 Protocl Specification September 1997
[17ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
7.6. ECHO_REQUEST Packet Format
7.6. エコー_リクエスト・パケット形式
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBT Control Packet Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| originating child router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CBTコントロールパケットのヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 子供ルータを溯源します。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. ECHO_REQUEST Packet Format
図6。 エコー_リクエスト・パケット形式
ECHO_REQUEST Field Definitions
エコー_要求フィールド定義
o originating child router: address of the router that
originates the ECHO_REQUEST.
o 子供ルータを溯源します: ECHO_REQUESTを溯源するルータのアドレス。
7.7. ECHO_REPLY Packet Format
7.7. エコー_回答パケット・フォーマット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBT Control Packet Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| originating parent router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| group address #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| group address #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| group address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CBTコントロールパケットのヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 親ルータを溯源します。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループアドレス#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループアドレス#2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループアドレス#n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7. ECHO_REPLY Packet Format
図7。 エコー_回答パケット・フォーマット
ECHO_REPLY Field Definitions
エコー_回答フィールド定義
o oringinating parent router: address of the router originating
this ECHO_REPLY.
o 親ルータをoringinatingします: このECHO_REPLYを溯源するルータのアドレス。
o group address: a list of multicast group addresses for which
o アドレスを分類してください: マルチキャストのリストがアドレスを分類する、どれ
Ballardie Experimental [Page 18] RFC 2189 CBTv2 Protocl Specification September 1997
[18ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
this router considers itself a parent router w.r.t. the link
over which this message is sent.
このルータ自体は、親ルータw.r.t.がこのメッセージが送られるリンクであると考えます。
7.8. FLUSH_TREE Packet Format
7.8. 水洗_木のパケット・フォーマット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBT Control Packet Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| group address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| group address #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CBTコントロールパケットのヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | グループアドレス#n| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8. FLUSH_TREE Packet Format
エイト環。 水洗_木のパケット・フォーマット
FLUSH_TREE Field Definitions
水洗_木のフィールド定義
o group address(es): multicast group address(es) of the group(s)
being "flushed".
o アドレス(es)を分類してください: マルチキャストグループは、「紅潮している」ので、グループの(es)を扱います。
8. Core Router Discovery
8. コアルータ発見
There are two available options for CBTv2 core discovery; the "bootstrap" mechanism (as currently specified with the PIM sparse mode protocol [2]) is applicable only to intra-domain core discovery, and allows for a "plug & play" type operation with minimal configuration. The disadvantage of the bootstrap mechanism is that it is much more difficult to affect the shape, and thus optimality, of the resulting distribution tree. Also, to be applicable, all CBT routers within a domain must implement the bootstrap mechanism.
CBTv2コア発見のための2つの利用可能なオプションがあります。 」 メカニズムを独力で進んでください。「(PIMがまばらな状態で現在指定されるように、モードプロトコル[2])は、イントラドメインコア発見だけに適切であり、最小量の構成で「プラグとプレー」タイプ操作を考慮します。 独力で進んでください。不都合である、メカニズムは形に影響して、その結果、最適に影響するのが結果として起こる分配木ではるかに難しいということです。 また、ドメインの中のすべてのCBTルータが適切に、なるように実装しなければならない、メカニズムを独力で進んでください。
The other option is to manually configure leaf routers with <core, group> mappings (note: leaf routers only); this imposes a degree of administrative burden - the mapping for a particular group must be coordinated across all leaf routers to ensure consistency. Hence, this method does not scale particularly well. However, it is likely that "better" trees will result from this method, and it is also the only available option for inter-domain core discovery currently available.
別の選択肢は<コア、グループ>マッピング(注意: 葉のルータ専用)で手動で葉のルータを構成することです。 これは管理負担の度合いを課します--一貫性があることを保証するためにすべての葉のルータの向こう側に特定のグループのためのマッピングを調整しなければなりません。 したがって、このメソッドは特によく比例しません。 しかしながら、「より良い」木はこのメソッドから生じそうでしょう、そして、また、それは相互ドメインコア発見のための現在利用可能な唯一の利用可能なオプションです。
Ballardie Experimental [Page 19] RFC 2189 CBTv2 Protocl Specification September 1997
[19ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
8.1. "Bootstrap" Mechanism Overview
8.1. 「独力で進んでください」というメカニズム概要
It is unlikely that the bootstrap mechanism will be appended to a well-known network layer protocol, such as IGMP [3], though this would facilitate its ubiquitous (intra-domain) deployment. Therefore, each multicast routing protocol requiring the bootstrap mechanism must implement it as part of the multicast routing protocol itself.
メカニズムを独力で進んでください。それがありそうもない、それ、よく知られるネットワーク層プロトコルに追加するでしょう、IGMP[3]などのように、これは遍在している(イントラドメイン)展開を容易にするでしょうが。 したがって、それぞれのマルチキャストルーティング・プロトコル必要である、必須がマルチキャストルーティング・プロトコル自体の一部としてそれを実装するメカニズムを独力で進んでください。
A summary of the operation of the bootstrap mechanism follows (details are provided in [7]). It is assumed that all routers within the domain implement the "bootstrap" protocol, or at least forward bootstrap protocol messages.
メカニズム尾行を独力で進んでください。操作の概要、(詳細は[7])に明らかにされます。 ドメインの中のすべてのルータが「独力で進んでください」というプロトコルを実装すると思われるか、またはプロトコルメッセージは前方を少なくとも独力で進みます。
A subset of the domain's routers are configured to be CBT candidate core routers. Each candidate core router periodically (default every 60 secs) advertises itself to the domain's Bootstrap Router (BSR), using "Core Advertisement" messages. The BSR is itself elected dynamically from all (or participating) routers in the domain. The domain's elected BSR collects "Core Advertisement" messages from candidate core routers and periodically advertises a candidate core set (CC-set) to each other router in the domain, using traditional hop- by-hop unicast forwarding. The BSR uses "Bootstrap Messages" to advertise the CC-set. Together, "Core Advertisements" and "Bootstrap Messages" comprise the "bootstrap" protocol.
ドメインのルータの部分集合は、CBT候補コアルータになるように構成されます。 それぞれの候補コアルータは定期的にドメインのBootstrap Routerに自分を売り込みます(あらゆる60がsecsするデフォルト)(BSR)、「コア広告」メッセージを使用して。 BSRはそのドメインのルータからダイナミックに選出されます。 ドメインの選出されたBSRは候補コアルータから「コア広告」メッセージを集めて、そのドメインに定期的に候補の巻き癖の互いに(セットをCCします)のルータの広告を出します、ホップによる伝統的なホップユニキャスト推進を使用して。 BSRは、CCセットの広告を出すのに「メッセージを独力で進んでください」を使用します。 「コア広告」と「メッセージを独力で進んでください」は「独力で進んでください」というプロトコルを一緒に、包括します。
When a router receives an IGMP host membership report from one of its directly attached hosts, the local router uses a hash function on the reported group address, the result of which is used as an index into the CC-set. This is how local routers discover which core to use for a particular group.
ルータが直接付属しているホストのひとりからIGMPホスト会員資格レポートを受け取るとき、ローカルルータは報告されたグループアドレスのハッシュ関数を使用します。その結果はインデックスとしてCCセットに使用されます。 これはローカルルータが、特定のグループにどのコアを使用したらよいかをどう発見するかということです。
Note the hash function is specifically tailored such that a small number of consecutive groups always hash to the same core. Furthermore, bootstrap messages can carry a "group mask", potentially limiting a CC-set to a particular range of groups. This can help reduce traffic concentration at the core.
ハッシュ関数が少ない数の連続したグループがいつも同じコアに論じ尽くす明確にオーダーメイドのそのようなものであることに注意してください。 その上、「グループマスク」を運ぶことができて、潜在的にCCセットを特定の範囲のグループに制限しながら、メッセージを独力で進んでください。 これは、コアでトラフィック集中を抑えるのを助けることができます。
If a BSR detects a particular core as being unreachable (it has not announced its availability within some period), it deletes the relevant core from the CC-set sent in its next bootstrap message. This is how a local router discovers a group's core is unreachable; the router must re-hash for each affected group and join the new core after removing the old state. The removal of the "old" state follows the sending of a QUIT_NOTIFICATION upstream, and a FLUSH_TREE message downstream.
BSRが手が届かないとして特定のコアを検出するなら(それはいつかの期間以内に有用性を発表していません)、それは次が独力で進むコネが送られたCCセットメッセージから関連コアを削除します。 これはローカルルータが、グループのコアが手が届かないとどう発見するかということです。 ルータは、それぞれのために影響を受けるグループを再論じ尽くして、古い状態を取り除いた後に、新しいコアを接合しなければなりません。 「古い」状態の取り外しはQUIT_NOTIFICATION上流の発信、およびFLUSH_TREEメッセージに川下に従います。
Ballardie Experimental [Page 20] RFC 2189 CBTv2 Protocl Specification September 1997
[20ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
8.2. Bootstrap Message Format
8.2. メッセージ・フォーマットを独力で進んでください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBT common control packet header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| For full Bootstrap Message specification, see [7] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CBT共通制御機構パケットのヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 完全なBootstrap Message仕様に関しては、[7]を見てください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9. Bootstrap Message Format
図9。 メッセージ・フォーマットを独力で進んでください。
8.3. Candidate Core Advertisement Message Format
8.3. 候補コア広告メッセージ・フォーマット
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CBT common control packet header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| For full Candidate Core Adv. Message specification, see [7] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CBT共通制御機構パケットのヘッダー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 完全なCandidate Core Advのために。 仕様を通信させてください、そして、[7]を見てください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10. Candidate Core Advertisement Message Format
図10。 候補コア広告メッセージ・フォーマット
9. Interoperability Issues
9. 相互運用性問題
Interoperability between CBT and DVMRP is specified in [5].
CBTとDVMRPの間の相互運用性は[5]で指定されます。
Interoperability with other multicast protocols will be fully specified as the need arises.
他のマルチキャストプロトコルがある相互運用性は必要に応じて完全に指定されるでしょう。
10. Security Considerations
10. セキュリティ問題
Security considerations are not addressed in this memo.
セキュリティ問題はこのメモで扱われません。
Whilst multicast security is a topic of ongoing research, multicast applications (users) nevertheless have the ability to take advantage of security services such as encryption or/and authentication provided such services are supported by the applications.
マルチキャストセキュリティは継続中の研究の話題ですが、それにもかかわらず、そのようなサービスがアプリケーションでサポートされるなら、マルチキャストアプリケーション(ユーザ)には暗号化か/などのセキュリティー・サービスと認証を利用する能力があります。
RFCs 1949 and 2093/2094 discuss different ways of distributing multicast key material, which can result in the provision of network layer access control to a multicast distribution tree.
RFCs1949と2093/2094はネットワーク層アクセスコントロールの支給をもたらすことができるマルチキャストの主要な材料を分配する異なった方法についてマルチキャスト分配木と議論します。
[9] offers a synopsis of multicast security threats and proposes some possible counter measures.
[9]はマルチキャスト軍事的脅威の構文を提供して、いくつかの可能な対応策を提案します。
Ballardie Experimental [Page 21] RFC 2189 CBTv2 Protocl Specification September 1997
[21ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
Beyond these, little published work exists on the topic of multicast security.
これらを超えて、ほとんど発行されなかった仕事はマルチキャストセキュリティの話題に関して存在しています。
Acknowledgements
承認
Special thanks goes to Paul Francis, NTT Japan, for the original brainstorming sessions that brought about this work.
特別な感謝では、オリジナルのブレインストーミング・セッションのために、ポール・NTTのフランシス(日本)に、それがこの仕事を引き起こしたと言われています。
The emergence of CBTv2 owes much to Clay Shields and his work on Ordered CBT (OCBT) [8]. Clay identified and proved several failure modes of CBT as it was specified with multiple cores, and also suggested using an unreliable quit mechanism, which appears in this specification as the QUIT_NOTIFICATION. Clay has also provided more general constructive comments on the CBT architecture and specification.
CBTv2の出現はOrdered CBT(OCBT)[8]に対するクレイ・シールズと彼の仕事から多くを借りています。 複数のコアで指定されて、また、使用するのを示したとき、粘土がCBTのいくつかの故障モードを特定して、立証した、頼り無さ、メカニズムをやめてください、QUIT_NOTIFICATIONとしてこの仕様に現れる。 また、粘土はCBT構造と仕様の、より一般的な建設的なコメントを提供しました。
Others that have contributed to the progress of CBT include Ken Carlberg, Eric Crawley, Jon Crowcroft, Mark Handley, Ahmed Helmy, Nitin Jain, Alan O'Neill, Steven Ostrowsksi, Radia Perlman, Scott Reeve, Benny Rodrig, Martin Tatham, Dave Thaler, Sue Thompson, Paul White, and other participants of the IETF IDMR working group.
CBTの進歩に貢献した他のものがIETF IDMRワーキンググループのケンCarlberg、エリック・クローリー・ジョン・クロウクロフト、マーク・ハンドレー、アフマドHelmy、ジャイナ教のNitinアラン・オニール、スティーブンOstrowsksi、Radiaパールマン、スコットReeve、ベニーRodrig、マーチンTatham、デーヴThaler、スートンプソン、ポール・ホワイト、および他の関係者を入れます。
Thanks also to 3Com Corporation and British Telecom Plc for funding this work.
これに資金を供給するための3Com社とブリティッシュ・テレコムPlcにも感謝は働いています。
References
参照
[1] Core Based Trees (CBT) Multicast Routing Architecture; A. Ballardie; RFC 2201, September 1997.
[1] コアは木(CBT)のマルチキャストルート設定構造を基礎づけました。 A。 Ballardie。 1997年9月のRFC2201。
[2] Protocol Independent Multicast (PIM) Sparse Mode/Dense Mode; D. Estrin et al; ftp://netweb.usc.edu/pim Working drafts, 1996.
[2] 独立しているマルチキャスト(PIM)のまばらなモード/濃いモードを議定書の中で述べてください。 D。 Estrin他。 ftp://netweb.usc.edu/pim 概要版、1996。
[3] Internet Group Management Protocol, version 2 (IGMPv2); W. Fenner; ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-igmp- v2-**.txt. Working draft, 1996.
[3] インターネットGroup Managementプロトコル、バージョン2(IGMPv2)。 W。 フェナー。 ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-igmp- v2-**.txt。 概要版、1996。
[4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[4] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[5] CBT Border Router Specification for Interconnecting a CBT Stub Region to a DVMRP Backbone; A. Ballardie; ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt-dm- interop-**.txt. Working draft, March 1997.
[5] CBTはCBTスタッブ周辺とDVMRP背骨とインタコネクトするためのルータ仕様に接しています。 A。 Ballardie。 ftp://ds.internic.net/internet-drafts/draft-ietf-idmr-cbt-dm- interop-**.txt。 1997年3月の概要版。
[6] Ballardie, A., "Scalable Multicast Key Distribution", RFC 1949, July 1996.
[6]Ballardie、A.、「スケーラブルなマルチキャスト主要な分配」、RFC1949、1996年7月。
Ballardie Experimental [Page 22] RFC 2189 CBTv2 Protocl Specification September 1997
[22ページ]RFC2189CBTv2 Protocl仕様1997年9月に実験的なBallardie
[7] A Dynamic Bootstrap Mechanism for Rendezvous-based Multicast Routing; D. Estrin et al.; Technical Report; ftp://catarina.usc.edu/pim
[7] 動力はランデブーベースのマルチキャストルート設定のためにメカニズムを独力で進みます。 D。 Estrin他。 技術報告書。 ftp://catarina.usc.edu/pim
[8] The Ordered Core Based Tree Protocol; C. Shields and J.J. Garcia- Luna-Aceves; In Proceedings of IEEE Infocom'97, Kobe, Japan, April 1997; http://www.cse.ucsc.edu/research/ccrg/publications/infocomm97ocbt.ps.gz
[8] 命令されたコアは木のプロトコルを基礎づけました。 C。 シールズとJ.J.ガルシアルーナ-Aceves。 IEEE Infocom97年、神戸(日本)1997年4月の議事で。 http://www.cse.ucsc.edu/research/ccrg/publications/infocomm97ocbt.ps.gz
[9] Multicast-Specific Security Threats and Counter-Measures; A. Ballardie and J. Crowcroft; In Proceedings "Symposium on Network and Distributed System Security", February 1995, pp.2-16.
[9] マルチキャスト特有の軍事的脅威と対応策。 A。 BallardieとJ.クロウクロフト。 Proceedings、「ネットワークと分散システムセキュリティに関するシンポジウム」、1995年2月、pp.2-16。
Author Information:
情報を書いてください:
Tony Ballardie, Research Consultant
トニーBallardie、研究コンサルタント
EMail: ABallardie@acm.org
メール: ABallardie@acm.org
Ballardie Experimental [Page 23]
Ballardie実験的です。[23ページ]
一覧
スポンサーリンク
