RFC2201 日本語訳
2201 Core Based Trees (CBT) Multicast Routing Architecture. A.Ballardie. September 1997. (Format: TXT=38040 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Ballardie Request for Comments: 2201 Consultant Category: Experimental September 1997
Ballardieがコメントのために要求するワーキンググループA.をネットワークでつないでください: 2201年のコンサルタントカテゴリ: 実験的な1997年9月
Core Based Trees (CBT) Multicast Routing Architecture
コアベースの木(CBT)のマルチキャストルート設定構造
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 このメモはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
CBT is a multicast routing architecture that builds a single delivery tree per group which is shared by all of the group's senders and receivers. Most multicast algorithms build one multicast tree per sender (subnetwork), the tree being rooted at the sender's subnetwork. The primary advantage of the shared tree approach is that it typically offers more favourable scaling characteristics than all other multicast algorithms.
CBTはそれが1グループの送付者と受信機のすべてによって共有されるグループあたり1本の単一の配送木を建てるマルチキャストルーティング構造です。 木が送付者のサブネットワークに根づいて、ほとんどのマルチキャストアルゴリズムが送付者(サブネットワーク)あたり1本のマルチキャスト木を建てます。 共有された木のアプローチの第一の利点は他のすべてのマルチキャストアルゴリズムより好都合なスケーリングの特性を通常提供するということです。
The CBT protocol [1] is a network layer multicast routing protocol that builds and maintains a shared delivery tree for a multicast group. The sending and receiving of multicast data by hosts on a subnetwork conforms to the traditional IP multicast service model [2].
CBTプロトコル[1]はマルチキャストグループのために共有された配送木を建てて、維持するネットワーク層マルチキャストルーティング・プロトコルです。 サブネットワークの上のホストによるマルチキャストデータの送受信は伝統的なIPマルチキャストサービスモデル[2]に従います。
CBT is progressing through the IDMR working group of the IETF. The CBT protocol is described in an accompanying document [1]. For this, and all IDMR-related documents, see http://www.cs.ucl.ac.uk/ietf/idmr
CBTはIETFのIDMRワーキンググループを通して進歩をする予定です。 CBTプロトコルは添付書類[1]で説明されます。 これ、およびすべてのIDMR関連のドキュメントに関しては、 http://www.cs.ucl.ac.uk/ietf/idmr を見てください。
TABLE OF CONTENTS
目次
1. Background................................................... 2
2. Introduction................................................. 2
3. Source Based Tree Algorithms................................. 3
3.1 Distance-Vector Multicast Algorithm...................... 4
3.2 Link State Multicast Algorithm........................... 5
3.3 The Motivation for Shared Trees.......................... 5
4. CBT - The New Architecture................................... 7
4.1 Design Requirements...................................... 7
4.2 Components & Functions................................... 8
4.2.1 CBT Control Message Retransmission Strategy........ 10
4.2.2 Non-Member Sending................................. 11
5. Interoperability with Other Multicast Routing Protocols ..... 11
1. バックグラウンド… 2 2. 序論… 2 3. ソースは木のアルゴリズムを基礎づけました… 3 3.1距離ベクトルマルチキャストアルゴリズム… 4 3.2 州のマルチキャストアルゴリズムをリンクしてください… 5 3.3 共有された木に関する動機… 5 4. CBT--新しい構造… 7 4.1 要件を設計してください… 7 4.2のコンポーネントと機能… 8 4.2 .1 CBTはメッセージの再送戦略を制御します… 10 4.2 .2 非会員発信… 11 5. 他のマルチキャストルーティング・プロトコルがある相互運用性… 11
Ballardie Experimental [Page 1] RFC 2201 CBT Multicast Routing Architecture September 1997
構造1997年9月に掘られるBallardieの実験的な[1ページ]RFC2201CBTマルチキャスト
6. Core Router Discovery........................................ 11
6.1 Bootstrap Mechanism Overview............................. 12
7. Summary ..................................................... 13
8. Security Considerations...................................... 13
Acknowledgements ............................................... 14
References ..................................................... 14
Author Information.............................................. 15
6. コアルータ発見… 11 6.1 メカニズム概観を独力で進んでください… 12 7. 概要… 13 8. セキュリティ問題… 13の承認… 14の参照箇所… 14 情報を書いてください… 15
1. Background
1. バックグラウンド
Shared trees were first described by Wall in his investigation into low-delay approaches to broadcast and selective broadcast [3]. Wall concluded that delay will not be minimal, as with shortest-path trees, but the delay can be kept within bounds that may be acceptable. Back then, the benefits and uses of multicast were not fully understood, and it wasn't until much later that the IP multicast address space was defined (class D space [4]). Deering's work [2] in the late 1980's was pioneering in that he defined the IP multicast service model, and invented algorithms which allow hosts to arbitrarily join and leave a multicast group. All of Deering's multicast algorithms build source-rooted delivery trees, with one delivery tree per sender subnetwork. These algorithms are documented in [2].
共有された木は最初に、Wallによって彼の調査で放送する低い遅れアプローチと選択している放送[3]に説明されました。 壁は、遅れが最短パス木なら最小量になりませんが、許容できるかもしれない領域の中に遅れを保つことができると結論を下しました。 当時マルチキャストの利益と用途は完全に理解されていたというわけではありません、そして、はるかに遅れているとき、IPマルチキャストアドレス空間は初めて、定義されました。(クラスDスペース[4])。 1980年後半のデアリングの仕事[2]は、ホストが任意にマルチキャストグループに加わって、出るアルゴリズムを、彼がIPマルチキャストサービスモデルを定義したので先駆けていて、発明しました。 デアリングのマルチキャストアルゴリズムのすべてが送付者サブネットワークあたり1本の配送木でソースが根づいている配送木を建てます。 これらのアルゴリズムは[2]に記録されます。
After several years practical experience with multicast, we see a diversity of multicast applications and correspondingly, a wide variety of multicast application requirements. For example, distributed interactive simulation (DIS) applications have strict requirements in terms of join latency, group membership dynamics, group sender populations, far exceeding the requirements of many other multicast applications.
マルチキャストの数個の何年もの実用的な経験の後に、私たちはマルチキャストアプリケーションの多様性を対応する見ます、さまざまなマルチキャストアプリケーション要件。 例えば、アプリケーションには厳しい要件がある分配された対話的なシミュレーション(DIS)は潜在を接合します、グループ会員資格力学、グループ送付者の母集団、遠くに他の多くのマルチキャストアプリケーションの要件を超えていて。
The multicast-capable part of the Internet, the MBONE, continues to expand rapidly. The obvious popularity and growth of multicast means that the scaling aspects of wide-area multicasting cannot be overlooked; some predictions talk of thousands of groups being present at any one time in the Internet.
インターネットのマルチキャストできる地域(MBONE)は、急速に広がり続けています。 マルチキャストの明白な人気と成長は、広い領域マルチキャスティングのスケーリング局面を見落とすことができないことを意味します。 いくつかの予測がインターネットで何千ものいかなる時も存在しているグループについて話します。
We evaluate scalability in terms of network state maintenance, bandwidth efficiency, and protocol overhead. Other factors that can affect these parameters include sender set size, and wide-area distribution of group members.
私たちはネットワーク州の維持、帯域幅効率、およびプロトコルオーバーヘッドに関してスケーラビリティを評価します。 これらのパラメタに影響できる他の要素が送付者セットサイズ、およびグループのメンバーの広い領域分配を含んでいます。
2. Introduction
2. 序論
Multicasting on the local subnetwork does not require either the presence of a multicast router or the implementation of a multicast routing algorithm; on most shared media (e.g. Ethernet), a host,
地方のサブネットワークの上のマルチキャスティングはマルチキャストルータの存在かマルチキャストルーティング・アルゴリズムの実現のどちらかを必要としません。 ほとんどの共有されたメディア(例えば、イーサネット)、ホストに関して
Ballardie Experimental [Page 2] RFC 2201 CBT Multicast Routing Architecture September 1997
構造1997年9月に掘られるBallardieの実験的な[2ページ]RFC2201CBTマルチキャスト
which need not necessarily be a group member, simply sends a multicast data packet, which is received by any member hosts connected to the same medium.
必ずグループのメンバーでなければならないというわけではなく、単にマルチキャストデータ・パケットを送ります。(それは、同じ媒体に接続されたどんなメンバーホストによっても受け取られます)。
For multicasts to extend beyond the scope of the local subnetwork, the subnet must have a multicast-capable router attached, which itself is attached (possibly "virtually") to another multicast- capable router, and so on. The collection of these (virtually) connected multicast routers forms the Internet's MBONE.
サブネットには、マルチキャストが地方のサブネットワークの範囲を超えて広がるように、マルチキャストできる添付のルータなどがなければなりません。(ルータはそれ自体で別のマルチキャストのできるルータに付けられています(ことによると「実際には」))。 これらの(実際には)接続されたマルチキャストルータの収集はインターネットのMBONEを形成します。
All multicast routing protocols make use of IGMP [5], a protocol that operates between hosts and multicast router(s) belonging to the same subnetwork. IGMP enables the subnet's multicast router(s) to monitor group membership presence on its directly attached links, so that if multicast data arrives, it knows over which of its links to send a copy of the packet.
すべてのマルチキャストルーティング・プロトコルがIGMP[5](同じサブネットワークに属しながらホストとマルチキャストルータの間で作動するプロトコル)を利用します。 IGMPは、サブネットのマルチキャストルータが直接付属しているリンクの上にグループ会員資格存在をモニターするのを可能にします、マルチキャストデータが到着するなら、リンクのどれを送ったらよいかの上でパケットのコピーを知るように。
In our description of the MBONE so far, we have assumed that all multicast routers on the MBONE are running the same multicast routing protocol. In reality, this is not the case; the MBONE is a collection of autonomously administered multicast regions, each region defined by one or more multicast-capable border routers. Each region independently chooses to run whichever multicast routing protocol best suits its needs, and the regions interconnect via the "backbone region", which currently runs the Distance Vector Multicast Routing Protocol (DVMRP) [6]. Therefore, it follows that a region's border router(s) must interoperate with DVMRP.
今までのところのMBONEの記述では、私たちは、MBONEの上のすべてのマルチキャストルータが同じマルチキャストルーティング・プロトコルを走らせていると思いました。 これはほんとうは、そうではありません。 MBONEは自主的に管理されたマルチキャスト領域、1時までに定義された各領域または、よりマルチキャストできる境界ルータの収集です。 各領域は、必要性に最もよく合うどのマルチキャストルーティング・プロトコルを走らせるかを独自に選びます、そして、領域は現在ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル(DVMRP)[6]を走らせる「背骨周辺」を通して内部連絡されます。 したがって、領域の境界ルータがDVMRPと共に共同利用しなければならないということになります。
Different algorithms use different techniques for establishing a distribution tree. If we classify these algorithms into source-based tree algorithms and shared tree algorithms, we'll see that the different classes have considerably different scaling characteristics, and the characteristics of the resulting trees differ too, for example, average delay. Let's look at source-based tree algorithms first.
異なったアルゴリズムは、分配木を設立するのに異なったテクニックを使用します。 これらのアルゴリズムをソースベースの木のアルゴリズムと共有された木のアルゴリズムに分類すると、私たちは、異なったクラスにはかなり異なったスケーリングの特性があるのがわかるでしょう、そして、結果として起こる木の特性はまた、例えば異なります、平均した遅れ。 最初に、ソースベースの木のアルゴリズムを見ましょう。
3. Source-Based Tree Algorithms
3. ソースベースの木のアルゴリズム
The strategy we'll use for motivating (CBT) shared tree multicast is based, in part, in explaining the characteristics of source-based tree multicast, in particular its scalability.
私たちが共有された木のマルチキャストを動機づけること(CBT)に使用するつもりである戦略はソースベースの木のマルチキャスト、特にスケーラビリティの特性について説明する際に一部基づいています。
Most source-based tree multicast algorithms are often referred to as "dense-mode" algorithms; they assume that the receiver population densely populates the domain of operation, and therefore the accompanying overhead (in terms of state, bandwidth usage, and/or processing costs) is justified. Whilst this might be the case in a local environment, wide-area group membership tends to be sparsely
ほとんどのソースベースの木のマルチキャストアルゴリズムがしばしば「濃いモード」アルゴリズムと呼ばれます。 彼らは、受信機人口が密に操作のドメインに居住すると仮定します、そして、したがって、付随のオーバーヘッド(状態、帯域幅用法、そして/または、処理コストに関する)は正当です。 これは地方の環境でそうであるかもしれませんが、広い領域グループ会員資格は、まばらにである傾向があります。
Ballardie Experimental [Page 3] RFC 2201 CBT Multicast Routing Architecture September 1997
構造1997年9月に掘られるBallardieの実験的な[3ページ]RFC2201CBTマルチキャスト
distributed throughout the Internet. There may be "pockets" of denseness, but if one views the global picture, wide-area groups tend to be sparsely distributed.
インターネット中で分配されています。 うっそうの「ポケット」があるかもしれませんが、人がグローバルな絵を見るなら、広い領域グループは、まばらに分配される傾向があります。
Source-based multicast trees are either built by a distance-vector style algorithm, which may be implemented separately from the unicast routing algorithm (as is the case with DVMRP), or the multicast tree may be built using the information present in the underlying unicast routing table (as is the case with PIM-DM [7]). The other algorithm used for building source-based trees is the link-state algorithm (a protocol instance being M-OSPF [8]).
ソースベースのマルチキャスト木は距離ベクトルスタイルアルゴリズムで建てられます、別々にユニキャストルーティング・アルゴリズムから実行されるかもしれないもの(DVMRPに関してそうであるように)かマルチキャスト木が、基本的なユニキャスト経路指定テーブルの現在の情報を使用することで建てられるかもしれません。(PIM-DM[7])があるケースのように。 ビルのソースベースの木に使用されるもう片方のアルゴリズムはリンク州のアルゴリズムです。(M-OSPF[8])であるプロトコル例。
3.1. Distance-Vector Multicast Algorithm
3.1. 距離ベクトルマルチキャストアルゴリズム
The distance-vector multicast algorithm builds a multicast delivery tree using a variant of the Reverse-Path Forwarding technique [9]. The technique basically is as follows: when a multicast router receives a multicast data packet, if the packet arrives on the interface used to reach the source of the packet, the packet is forwarded over all outgoing interfaces, except leaf subnets with no members attached. A "leaf" subnet is one which no router would use to reach the souce of a multicast packet. If the data packet does not arrive over the link that would be used to reach the source, the packet is discarded.
距離ベクトルマルチキャストアルゴリズムは、Reverse-経路Forwardingのテクニック[9]の異形を使用することでマルチキャスト配送木を建てます。 テクニックは基本的に以下の通りです: パケットがパケットの源に達するのに使用されるインタフェースで到着するならマルチキャストルータがマルチキャストデータ・パケットを受けるとき、すべての外向的なインタフェースにわたってパケットを送ります、添付のメンバーのいない葉のサブネットを除いて。 「葉」サブネットはどんなルータもマルチキャストパケットのsouceに達するのに使用しないものです。 データ・パケットがソースに届くのに使用されるリンクの上に到着しないなら、パケットは捨てられます。
This constitutes a "broadcast & prune" approach to multicast tree construction; when a data packet reaches a leaf router, if that router has no membership registered on any of its directly attached subnetworks, the router sends a prune message one hop back towards the source. The receiving router then checks its leaf subnets for group membership, and checks whether it has received a prune from all of its downstream routers (downstream with respect to the source). If so, the router itself can send a prune upstream over the interface leading to the source.
これはマルチキャスト木の工事への「放送とプルーン」アプローチを構成します。 データ・パケットが葉のルータに達すると、直接付属しているサブネットワークのいずれにもそのルータで会員資格を全く登録しないなら、ルータはソースに向かってワンバウンドのプルーンのメッセージを送ります。 受信ルータは、次に、グループ会員資格のために葉のサブネットをチェックして、川下のルータのすべてからそれがプルーンを受けたかどうかチェックします(ソースに関する川下の)。 そうだとすれば、ルータ自体で、インタフェースの上のプルーンの上流はソースに通じることができます。
The sender and receiver of a prune message must cache the <source, group> pair being reported, for a "lifetime" which is at the granularity of minutes. Unless a router's prune information is refreshed by the receipt of a new prune for <source, group> before its "lifetime" expires, that information is removed, allowing data to flow over the branch again. State that expires in this way is referred to as "soft state".
プルーンのメッセージの送付者と受信機は<ソースをキャッシュしなければなりません、グループ>組が報告されて、数分の粒状にある「生涯」の間。 ルータのプルーンの情報が新しいプルーンの領収書で<ソースにリフレッシュされない場合、「生涯」の前のグループ>は期限が切れて、その情報は取り除かれます、データが再び支店の上を流れるのを許容して。 このように期限が切れる状態は「軟性国家」と呼ばれます。
Interestingly, routers that do not lead to group members are incurred the state overhead incurred by prune messages. For wide-area multicasting, which potentially has to support many thousands of active groups, each of which may be sparsely distributed, this technique clearly does not scale.
グループのメンバーに通じないルータはおもしろく、被られて、州のオーバーヘッドがプルーンでメッセージを被ったということです。 (潜在的に、それは、何千もの活動的なグループを支持しなければなりません)。それはそれぞれまばらに分配されるかもしれません。広い領域マルチキャスティングのために、このテクニックは明確に比例しません。
Ballardie Experimental [Page 4] RFC 2201 CBT Multicast Routing Architecture September 1997
構造1997年9月に掘られるBallardieの実験的な[4ページ]RFC2201CBTマルチキャスト
3.2. Link-State Multicast Algorithm
3.2. リンク州のマルチキャストアルゴリズム
Routers implementing a link state algorithm periodically collect reachability information to their directly attached neighbours, then flood this throughout the routing domain in so-called link state update packets. Deering extended the link state algorithm for multicasting by having a router additionally detect group membership changes on its incident links before flooding this information in link state packets.
定期的にリンク州のアルゴリズムを実行するルータが、可到達性情報を彼らの直接付属している隣人に集めて、次に、いわゆるリンク州のアップデートパケットの経路ドメイン中にこれをあふれさせます。 リンク州のパケットにこの情報をあふれさせる前にルータに付随しているリンクの上にグループ会員資格変化をさらに、検出させることによって、デアリングはマルチキャスティングのためにリンク州のアルゴリズムを広げました。
Each router then, has a complete, up-to-date image of a domain's topology and group membership. On receiving a multicast data packet, each router uses its membership and topology information to calculate a shortest-path tree rooted at the sender subnetwork. Provided the calculating router falls within the computed tree, it forwards the data packet over the interfaces defined by its calculation. Hence, multicast data packets only ever traverse routers leading to members, either directly attached, or further downstream. That is, the delivery tree is a true multicast tree right from the start.
そして各ルータ、ドメインのトポロジーとグループ会員資格の完全で、最新のイメージを持っています。 マルチキャストデータ・パケットを受けると、各ルータは、送付者サブネットワークに根づいている最短パス木について計算するのにその会員資格とトポロジー情報を使用します。 計算のルータが計算された木の中に下がるなら、それは計算で定義されたインタフェースの上にデータ・パケットを送ります。 したがって、マルチキャストデータ・パケットは直接付けられたメンバーに通じるルータか一層の川下を横断するだけです。 すなわち、配送木はまさしく始めからの本当のマルチキャスト木です。
However, the flooding (reliable broadcasting) of group membership information is the predominant factor preventing the link state multicast algorithm being applicable over the wide-area. The other limiting factor is the processing cost of the Dijkstra calculation to compute the shortest-path tree for each active source.
しかしながら、グループ会員資格情報の氾濫(信頼できる放送)は広い領域にわたってリンク州のマルチキャストアルゴリズムが適切であることを防ぐ支配的な要素です。 もう片方の限定因子はそれぞれの活発なソースに最短パス木を計算するダイクストラの計算の加工費です。
3.3. The Motivation for Shared Trees
3.3. 共有された木に関する動機
The algorithms described in the previous sections clearly motivate the need for a multicast algorithm(s) that is more scalable. CBT was designed primarily to address the topic of scalability; a shared tree architecture offers an improvement in scalability over source tree architectures by a factor of the number of active sources (where source is usually a subnetwork aggregate). Source trees scale O(S * G), since a distinct delivery tree is built per active source. Shared trees eliminate the source (S) scaling factor; all sources use the same shared tree, and hence a shared tree scales O(G). The implication of this is that applications with many active senders, such as distributed interactive simulation applications, and distributed video-gaming (where most receivers are also senders), have a significantly lesser impact on underlying multicast routing if shared trees are used.
前項で明確に説明されたアルゴリズムは、よりスケーラブルなマルチキャストアルゴリズムの必要性を動機づけます。 CBTは主としてスケーラビリティの話題を記述するように設計されました。 共有された木の構造は活発なソース(通常、ソースがサブネットワーク集合であるところ)の数の要素でソース木の構造の上にスケーラビリティにおける改良を提供します。 異なった配送木が活発なソース単位で建てられるので、ソース木はO(S*G)をスケーリングします。 共有された木はソース(S)けた移動子を排除します。 すべてのソースが同じ共有された木を使用します、そして、したがって、共有された木はO(G)をスケーリングします。 この含意は共有された木が使用されているなら分配された対話的なシミュレーション適用や、分配されたビデオゲーミングなどの多くの活発な送付者(またほとんどの受信機が送付者であるところ)とのアプリケーションが基本的なマルチキャストルーティングにかなり少ない影響力を持っているということです。
Ballardie Experimental [Page 5] RFC 2201 CBT Multicast Routing Architecture September 1997
構造1997年9月に掘られるBallardieの実験的な[5ページ]RFC2201CBTマルチキャスト
In the "back of the envelope" table below we compare the amount of state required by CBT and DVMRP for different group sizes with different numbers of active sources:
以下の「封筒」テーブルでは、私たちは異なったグループサイズのために異なった数の活発なソースと共にCBTとDVMRPによって必要とされた状態の量を比較します:
|--------------|---------------------------------------------------| | Number of | | | | | groups | 10 | 100 | 1000 | ==================================================================== | Group size | | | | | (# members) | 20 | 40 | 60 | -------------------------------------------------------------------| | No. of srcs | | | | | | | | | | | per group |10% | 50% |100% |10% | 50% |100% |10% | 50% | 100% | -------------------------------------------------------------------- | No. of DVMRP | | | | | | | | | | | router | | | | | | | | | | | entries | 20 | 100 | 200 |400 | 2K | 4K | 6K | 30K | 60K | -------------------------------------------------------------------- | No. of CBT | | | | | router | | | | | entries | 10 | 100 | 1000 | |------------------------------------------------------------------|
|--------------|---------------------------------------------------| | 数| | | | | グループ| 10 | 100 | 1000 | ==================================================================== | グループサイズ| | | | | (#メンバー) | 20 | 40 | 60 | -------------------------------------------------------------------| | srcsについていいえ| | | | | | | | | | | グループ単位で|10% | 50% |100% |10% | 50% |100% |10% | 50% | 100% | -------------------------------------------------------------------- | DVMRPについていいえ| | | | | | | | | | | ルータ| | | | | | | | | | | エントリー| 20 | 100 | 200 |400 | 2 K| 4 K| 6 K| 30 K| 60 K| -------------------------------------------------------------------- | CBTについていいえ| | | | | ルータ| | | | | エントリー| 10 | 100 | 1000 | |------------------------------------------------------------------|
Figure 1: Comparison of DVMRP and CBT Router State
図1: DVMRPとCBTルータ状態の比較
Shared trees also incur significant bandwidth and state savings compared with source trees; firstly, the tree only spans a group's receivers (including links/routers leading to receivers) -- there is no cost to routers/links in other parts of the network. Secondly, routers between a non-member sender and the delivery tree are not incurred any cost pertaining to multicast, and indeed, these routers need not even be multicast-capable -- packets from non-member senders are encapsulated and unicast to a core on the tree.
また、共有された木はソース木と比べて重要な帯域幅と州の貯蓄を被ります。 まず第一に、木はグループの受信機(受信機に通じるリンク/ルータを含んでいる)にかかるだけです--ルータ/リンクへの費用が全くネットワークの他の部分にありません。 第二に、非会員送付者と配送木の間のルータは本当に、これらのルータはマルチキャストできる必要さえありません--被られたいずれもマルチキャストとの関係かかって、非会員送付者からのパケットがカプセルに入れられるということでなく、コアにオンなユニキャストは木です。
Ballardie Experimental [Page 6] RFC 2201 CBT Multicast Routing Architecture September 1997
構造1997年9月に掘られるBallardieの実験的な[6ページ]RFC2201CBTマルチキャスト
The figure below illustrates a core based tree.
以下の図はコアに基づいている木を例証します。
b b b-----b
\ | |
\ | |
b---b b------b
/ \ / KEY....
/ \/
b X---b-----b X = Core
/ \ b = on-tree router
/ \
/ \
b b------b
/ \ |
/ \ |
b b b
b b b-----b\| | \ | | b---b b------b/\/KEY… /\/b X---b-----木の上のルータ/\/\b X=コア/\b=b b------b/\| / \ | b b b
Figure 2: CBT Tree
図2: CBT木
4. CBT - The New Architecture
4. CBT--新しい構造
4.1. Design Requirements
4.1. 設計の品質
The CBT shared tree design was geared towards several design objectives:
共有された木が設計するCBTはいくつかの設計目標に向かって連動しました:
o scalability - the CBT designers decided not to sacrifice CBT's
O(G) scaling characteric to optimize delay using SPTs, as does
PIM. This was an important design decision, and one, we think,
was taken with foresight; once multicasting becomes ubiquitous,
router state maintenance will be a predominant scaling factor.
It is possible in some circumstances to improve/optimize the
delay of shared trees by other means. For example, a broadcast-
type lecture with a single sender (or limited set of
infrequently changing senders) could have its core placed in the
locality of the sender, allowing the CBT to emulate a shortest-
path tree (SPT) whilst still maintaining its O(G) scaling
characteristic. More generally, because CBT does not incur
source-specific state, it is particularly suited to many sender
applications.
o スケーラビリティ--CBTデザイナーは、SPTsを使用することで遅れを最適化するためにCBTのO(G)スケーリングcharactericを犠牲にしないと決めました、PIMのように。 私たちは、これが重要なデザイン決定であり、1つが先見で取られたと思います。 マルチキャスティングがいったん遍在するようになると、ルータ州の維持は支配的なけた移動子になるでしょう。 いくつかの事情では、他の手段で共有された木の遅れを改良するか、または最適化するのが可能です。 例えば、独身の送付者(または、限られたセットのまれに変化している送付者)との放送タイプ講演で送付者の場所にコアを置くかもしれません、まだO(G)スケーリングを独特に維持している間、CBTが最も低い経路木(SPT)を見習うのを許容して。 より一般に、CBTがソース特有の状態を被らないので、それは特に多くの送付者アプリケーションに合っています。
o robustness - source-based tree algorithms are clearly robust; a
sender simply sends its data, and intervening routers "conspire"
to get the data where it needs to, creating state along the way.
This is the so-called "data driven" approach -- there is no
set-up protocol involved.
o 丈夫さ--ソースベースの木のアルゴリズムは明確に強健です。 送付者はそれが必要があるデータを得るために単に「共謀してください」をデータ、および介入しているルータに送ります、道に沿って状態を創設して。 これは「追い立てられたデータ」いわゆるアプローチです--かかわったどんなセットアッププロトコルもありません。
Ballardie Experimental [Page 7] RFC 2201 CBT Multicast Routing Architecture September 1997
構造1997年9月に掘られるBallardieの実験的な[7ページ]RFC2201CBTマルチキャスト
It is not as easy to achieve the same degree of robustness in
shared tree algorithms; a shared tree's core router maintains
connectivity between all group members, and is thus a single
point of failure. Protocol mechanisms must be present that
ensure a core failure is detected quickly, and the tree
reconnected quickly using a replacement core router.
共有された木のアルゴリズムにおける、同じ度の丈夫さを達成するのは簡単ではありません。 共有された木のコアルータは、すべてのグループのメンバーの間で接続性を維持して、その結果、1ポイントの失敗です。 プロトコルメカニズムは、コア失敗がすぐに検出されるのを確実にするプレゼントと、すぐに交換コアルータを使用することで再接続された木であるに違いありません。
o simplicity - the CBT protocol is relatively simple compared to
most other multicast routing protocols. This simplicity can lead
to enhanced performance compared to other protocols.
o 簡単さ--他のほとんどのマルチキャストルーティング・プロトコルと比べて、CBTプロトコルは比較的簡単です。 他のプロトコルと比べて、この簡単さは高められた性能につながることができます。
o interoperability - from a multicast perspective, the Internet is
a collection of heterogeneous multicast regions. The protocol
interconnecting these multicast regions is currently DVMRP [6];
any regions not running DVMRP connect to the DVMRP "backbone" as
stub regions. CBT has well-defined interoperability mechanisms
with DVMRP [15].
o 相互運用性--マルチキャスト見解から、インターネットは異種のマルチキャスト領域の収集です。 現在、これらのマルチキャスト領域とインタコネクトするプロトコルはDVMRP[6]です。 DVMRPを走らせないどんな領域もスタッブ周辺としてDVMRP「背骨」に接続します。 CBTには、DVMRP[15]がある明確な相互運用性メカニズムがあります。
4.2. CBT Components & Functions
4.2. 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 [5] 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 6). This join message must be explicitly acknowledged (JOIN_ACK) either by the core router itself, or by another router that is on the unicast path between the sending router and the core, which itself has already successfully joined the tree.
これを達成するために、ホストは最初に、マルチキャスティングで仲間に入ることへの関心を示します。付属リンクの向こう側のIGMPホスト会員資格レポート[5]。 このレポートを受け取ると、地方のCBT意識しているルータは、JOIN_REQUESTメッセージを発生させることによって、木の接合の過程(既にそうしていない場合)を呼び出します(ローカルルータが、どのコアを接合したらよいかをどう発見するかについてセクション6で議論します)。(メッセージはグループのコアルータに向かった経路の次のホップに送られます)。 これはオンであるコアルータ自体、または別のものによって明らかに承認された(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
セットが一時的でそれが横断するルータで状態に加わって、この状態が<グループから成るというメッセージを接合してください、入って来るインタフェース、出発しているインタフェース>。 対応するリンクがマルチキャスト送信を支持しないなら、「入って来るインタフェース」と「外向的なインタフェース」は、それぞれ「前のホップ」と「次のホップ」であるかもしれません。 「次のホップ」は経路指定テーブルから収集されます--「前のホップ」は入って来るコントロールパケットのIPソースアドレスから抜粋されます、そして、指定されたコアアドレスへの次のホップ。 結局aがある回が承認(JOIN_ACK)に上流へ、参加するこの一時的な状態。 対応の逆の経路が参加するJOIN_ACK横断は通信して、どれが一時的存在のために可能であるかが状態に加わります。 一度、承認に達します。
Ballardie Experimental [Page 8] RFC 2201 CBT Multicast Routing Architecture September 1997
構造1997年9月に掘られるBallardieの実験的な[8ページ]RFC2201CBTマルチキャスト
router that originated the join message, the new receiver can receive traffic sent to the group.
由来したルータ、メッセージを接合してください、そして、新しい受信機はグループに送られた交通を受けることができます。
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.
ルータでJOIN_ACKの発信か受信で創設された状態は双方向です--状態はグループ特有です--データは木の「ブランチ」に沿っていずれにせよ流れることができます、そして、グループアドレスから成ります、そして、どれがグループへのメッセージを接合するかの上で局所界面のリストは以前に、承認されました。 「入って来る」か「送信する」インタフェースの概念が全くありません、どんな川下のインタフェースとも上流のインタフェースを区別できるのが必要ですが。 CBTでは、これらのインタフェースは「親」として知られています、そして、「子供」はそれぞれ連結します。
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.
ネイティブのマルチキャスト送信を支持していないリンク型の上のマルチキャスト推進キャッシュに含まれた情報への尊敬で、木の上のルータは親とどんな子供のアドレスも格納しなければなりません。 しかしながら、マルチキャストを支持するリンクの上では、親とどんな子供情報も親か子供が届いている局所界面アドレス(または、インタフェース「インデックス」などの同様の身元が分かる情報)で代理をされます。
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 "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
コアルータ以外に、CBTマルチキャスト木を包括するそれぞれのルータが上流のリンクを維持するのに原因となる、関心がある川下の受信機を持っているなら、すなわち、子供インタフェースリストはNULLではありません。 子供インタフェースは、メンバーホストが直接付けられているもの、または木の上の川下のルータが付属しているものです。 この「木の維持」は定期的に"keepalive"メッセージ(ECHO_REQUEST)を上流の隣人(すなわち、木の上の親ルータ)に送るそれぞれの川下のルータによって達成されます。 同じ親と共にエントリーを表すために1つのkeepaliveメッセージを送ります、その結果、多くのグループによって共有されるリンクでスケーラビリティを改良します。 keepaliveが「オールcbtルータ」グループへのマルチキャストのできるリンクの上では、マルチキャストである、(IANAが224.0として.0を割り当てた、.15)。 これには、aがあります。
Ballardie Experimental [Page 9] RFC 2201 CBT Multicast Routing Architecture September 1997
構造1997年9月に掘られるBallardieの実験的な[9ページ]RFC2201CBTマルチキャスト
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.
リンクがその親リンクであるいかなる他のルータへの効果も抑圧します。 親リンクがマルチキャスト送信を支持しないなら、keepalivesはユニキャストです。
The receipt of a keepalive message over a valid child interface immediately prompts a response (ECHO_REPLY), which is either unicast or multicast, as appropriate.
有効な子供インタフェースの上のkeepaliveメッセージの領収書はすぐに応答(ECHO_REPLY)をうながします、適宜。(ユニキャストか応答はマルチキャストのどちらかです)。
The ECHO_REQUEST does not contain any group information; the ECHO_REPLY does, but only periodically. To maintain consistent information between parent and child, the parent periodically reports, in a ECHO_REPLY, all groups for which it has state, over each of its child interfaces for those groups. This group-carrying echo reply is not prompted explicitly by the receipt of an echo request message. A child is notified of the time to expect the next echo reply message containing group information in an echo reply prompted by a child's echo request. The frequency of parent group reporting is at the granularity of minutes.
ECHO_REQUESTは少しのグループ情報も含んでいません。 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 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).
マルチアクセスリンクの上のルータのすべてにはユニキャストルーティングの一定の視点があると思うことができません。 マルチアクセスリンクが2つ以上のユニキャスト経路ドメインにかかるとき、これは特にそうです。 方法がリンクの上のすべてのルータが、特定のグループのためにどれが上流のルータであるかに同意するのを保証するために取られない場合、これは形成される複数の上流の木の枝(エラー条件)に通じるかもしれません。 マルチアクセスリンクに付けられたCBTルータはただ一つのルータ、代表ルータを(DR)に選出する明白な選挙メカニズムに参加します、すべてのためのリンクの上流のルータが分類されるとき。 DRが特定のコアルータのためのリンクの最も良い次のホップでないかもしれないので、これをもたらすかもしれません。マルチアクセスリンクの向こう側に向け直されながら、メッセージを接合してください。 これが起こるなら、向け直すのは、最も良い次のホップへのDRによるリンクの向こう側のユニキャストであり、その結果、ループシナリオを防ぎながら、メッセージを接合します。 このリダイレクションは、メッセージを接合するのに申し込むだけです。 これが準最適である、メッセージを接合してください。(メッセージはまれに発生して、マルチキャストデータが一度(ネイティブの、または、要約の)よりリンクを決して横断しないということです)。
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. When a CBT control message is sent over a non-multicast supporting link, it is explicitly addressed to the appropriate next hop.
上で説明された例外ケース以外のすべてでは、すべてのCBTコントロールメッセージが「オールcbtルータ」グループへのリンクを支えるマルチキャストの上のマルチキャストです、IP TTL1と共に。 非マルチキャストサポートリンクの上にCBTコントロールメッセージを送るとき、明らかに次の適切なホップにそれを記述します。
4.2.1. CBT Control Message Retransmission Strategy
4.2.1. CBTコントロールメッセージの再送戦略
Certain CBT control messages illicit a response of some sort. Lack of response may be due to an upstream router crashing, or the loss of the original message, or its response. To detect these events, CBT
あるCBTコントロールはある種の不法なa応答を通信させます。 無反応は上流のルータクラッシュ、オリジナルのメッセージの損失、またはその応答のためであるかもしれません。 これらの出来事、CBTを検出するために
Ballardie Experimental [Page 10] RFC 2201 CBT Multicast Routing Architecture September 1997
構造1997年9月に掘られるBallardieの実験的な[10ページ]RFC2201CBTマルチキャスト
retransmits those control messages for which it expects a response, if that response is not forthcoming within the retransmission- interval, which varies depending on the type of message involved. There is an upper bound (typically 3) on the number of retransmissions of the original message before an exception condition is raised.
その応答が「再-トランスミッション」間隔中に用意されていないなら、それが応答を予想するそれらのコントロールメッセージを再送します。メッセージのかかわったタイプに頼っていて、間隔は異なります。 例外条件が高くしている前に上限(通常3)がオリジナルのメッセージの「再-トランスミッション」の数にあります。
For example, the exception procedure for lack of response to an ECHO_REQUEST is to send a QUIT_NOTIFICATION upstream and a FLUSH_TREE message downstream for the group. If this is router has group members attached, it restarts the joining process to the group's core.
例えば、ECHO_REQUESTへの無反応のための例外手順はグループのためにQUIT_NOTIFICATION上流とFLUSH_TREEメッセージを川下に送ることです。 これがそうなら、ルータでグループのメンバーを付けて、それは接合の過程をグループのコアに再開します。
4.2.2. Non-Member Sending
4.2.2. 非会員発信
If a non-member sender's local router is already on-tree for the group being sent to, the subnet's upstream router simply forwards the data packet over all outgoing interfaces corresponding to that group's forwarding cache entry. This is in contrast to PIM-SM [18] which must encapsulate data from a non-member sender, irrespective of whether the local router has joined the tree. This is due to PIM's uni-directional state.
非会員送付者のローカルルータが発信するグループのために既に木であるなら、サブネットの上流のルータは単にそのグループの推進キャッシュエントリーに対応するすべての外向的なインタフェースにわたってデータ・パケットを送ります。 これは非会員送付者からデータを要約しなければならないPIM-SM[18]と対照的になっています、ローカルルータが木に合流したかどうかの如何にかかわらず。 これはPIMのuni方向の状態のためです。
If the sender's subnet is not attached to the group tree, the local DR must encapsulate the data packet and unicast it to the group's core router, where it is decapsulated and disseminated over all tree interfaces, as specified by the core's forwarding cache entry for the group. The data packet encapsulation method is IP-in-IP [14].
送付者のサブネットがグループ木に付けられないなら、地方DRはデータ・パケットとユニキャストをカプセルに入れらなければなりません。それはすべての木の上のグループのコアルータ、それがどこでdecapsulatedされるか、そして、および播種性のに連結します、グループのためのコアの推進キャッシュエントリーで指定されるように。 データ・パケットカプセル化方法はIPにおけるIP[14]です。
Routers in between a non-member sender and the group's core need not know anything about the multicast group, and indeed may even be multicast-unaware. This makes CBT particulary attractive for applications with non-member senders.
非会員送付者とグループのコアの間のルータはマルチキャストグループに関して何も知る必要はありません、そして、本当に、マルチキャスト気づかなくさえあるかもしれません。 これで、CBT particularyは非会員送付者と共にアプリケーションに魅力的になります。
5. Interoperability with Other Multicast Routing Protocols
5. 他のマルチキャストルーティング・プロトコルがある相互運用性
See "interoperability" in section 4.1.
セクション4.1の「相互運用性」を見てください。
The interoperability mechanisms for interfacing CBT with DVMRP are defined in [15].
DVMRPにCBTを連結するための相互運用性メカニズムは[15]で定義されます。
6. Core Router Discovery
6. コアルータ発見
Core router discovery is by far the most controversial and difficult aspect of shared tree multicast architectures, particularly in the context of inter-domain multicast routing (IDMR). There have been many proposals over the past three years or so, including advertising core addresses in a multicast session directory like "sdr" [11], manual placement, and the HPIM [12] approach of strictly dividing up
コアルータ発見は断然共有された木のマルチキャスト構造の最も論議を呼んで難しい局面です、特に相互ドメインマルチキャストルーティング(IDMR)の文脈で。 多くの提案が過去およそ3年間あります、厳密に分割する"sdr"[11]、手動のプレースメント、およびHPIM[12]アプローチのようなマルチキャストセッションディレクトリのコアアドレスの広告を出すのを含んでいて
Ballardie Experimental [Page 11] RFC 2201 CBT Multicast Routing Architecture September 1997
構造1997年9月に掘られるBallardieの実験的な[11ページ]RFC2201CBTマルチキャスト
the multicast address space into many "hierarchical scopes" and using explicit advertising of core routers between scope levels.
多くの「階層的な範囲」へのマルチキャストアドレス空間と範囲レベルの間でコアルータの明白な広告を使用すること。
There are currently two options for CBTv2 [1] core discovery; the "bootstrap" mechamism, and manual placement. The bootstrap mechanisms (as currently specified with the PIM sparse mode protocol [18]) 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, it must be implemented by all CBT routers within a domain.
現在、CBTv2[1]コア発見のための2つのオプションがあります。 「独力で進んでください」というmechamism、および手動のプレースメント。 メカニズムを独力で進んでください。(PIMがまばらな状態で現在指定されるように、モードプロトコル[18])は、イントラドメインコア発見だけに適切であり、最小量の構成で「プラグとプレー」タイプ操作を考慮します。 独力で進んでください。不都合である、メカニズムは形に影響して、その結果、最適に影響するのが結果として起こる分配木ではるかに難しいということです。 また、ドメインの中のすべてのCBTルータでそれを実行しなければなりません。
Manual configuration of leaf routers with <core, group> mappings is the other option (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.
<コアがある葉のルータの手動の構成、グループ>マッピングは別の選択肢(注意: 葉のルータ専用)です。 これは1段階の管理負担を課します--一貫性があることを保証するためにすべての葉のルータの向こう側に特定のグループのためのマッピングを調整しなければなりません。 したがって、この方法は特によく比例しません。 しかしながら、「より良い」木はこの方法から生じそうでしょう、そして、また、それは相互ドメインコア発見のための現在利用可能な唯一の利用可能なオプションです。
6.1. Bootstrap Mechanism Overview
6.1. メカニズム概観を独力で進んでください。
It is unlikely at this stage that the bootstrap mechanism will be appended to a well-known network layer protocol, such as IGMP [5] or ICMP [13], 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[5]やICMP[13]のように、これは遍在している(イントラドメイン)展開を容易にするでしょうが。 メカニズムを独力で進んでください。したがって、それぞれのマルチキャストルーティング・プロトコル必要である、マルチキャストルーティング・プロトコル自体の一部としてそれを実行しなければなりません。
A summary of the operation of the bootstrap mechanism follows. It is assumed that all routers within the domain implement the "bootstrap" protocol, or at least forward bootstrap protocol messages.
操作の概要、メカニズム尾行を独力で進んでください。 ドメインの中のすべてのルータが「独力で進んでください」というプロトコルを実行すると思われるか、またはプロトコルメッセージは前方を少なくとも独力で進みます。
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 hopby-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します)のルータの広告を出します、伝統的なhopby-ホップユニキャスト推進を使用して。 BSRは、CCセットの広告を出すのに「メッセージを独力で進んでください」を使用します。 「コア広告」と「メッセージを独力で進んでください」は「独力で進んでください」というプロトコルを一緒に、包括します。
Ballardie Experimental [Page 12] RFC 2201 CBT Multicast Routing Architecture September 1997
構造1997年9月に掘られるBallardieの実験的な[12ページ]RFC2201CBTマルチキャスト
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メッセージに川下に従います。
7. Summary
7. 概要
This document presents an architecture for intra- and inter-domain multicast routing. We motivated this architecture by describing how an inter-domain multicast routing algorithm must scale to large numbers of groups present in the internetwork, and discussed why most other existing algorithms are less suited to inter-domain multicast routing. We followed by describing the features and components of the architecture, illustrating its simplicity and scalability.
このドキュメントはイントラと相互ドメインマルチキャストルーティングのために構造を提示します。 私たちは、相互ドメインマルチキャストルーティング・アルゴリズムがどう比例しなければならないかをインターネットワークにおける現在の多くのグループに説明することによってこの構造を動機づけて、他のほとんどの既存のアルゴリズムがなぜそれほど相互ドメインマルチキャストルーティングに合っていないかと議論しました。 私たちは、その簡単さとスケーラビリティを例証して、構造の特徴と成分について説明することによって、続きました。
8. Security Considerations
8. セキュリティ問題
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はネットワーク層アクセス管理の支給をもたらすことができるマルチキャストの主要な材料を分配する異なった方法についてマルチキャスト分配木と議論します。
[19] offers a synopsis of multicast security threats and proposes some possible counter measures.
[19]はマルチキャスト軍事的脅威の構文を提供して、いくつかの可能な対応策を提案します。
Ballardie Experimental [Page 13] RFC 2201 CBT Multicast Routing Architecture September 1997
構造1997年9月に掘られるBallardieの実験的な[13ページ]RFC2201CBTマルチキャスト
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のフランシス(日本)に、それがこの仕事を引き起こしたと言われています。
Clay Shields' work on OCBT [17] identified various failure scenarios with a multi-core architecture, resulting in the specification of a single core architecture.
OCBT[17]へのClayシールズの作業は様々な失敗シナリオをマルチコア構造と同一視しました、単芯構造の仕様をもたらして。
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] Ballardie, A., "Core Based Trees (CBT version 2) Multicast Routing: Protocol Specification", RFC 2189, September 1997.
[1]Ballardie、A.、「Based Trees(CBTバージョン2)マルチキャストルート設定の芯を取ってください」 「プロトコル仕様」、RFC2189、1997年9月。
[2] Multicast Routing in a Datagram Internetwork; S. Deering, PhD Thesis, 1991; ftp://gregorio.stanford.edu/vmtp/sd-thesis.ps.
[2] データグラムインターネットワークにおけるマルチキャストルート設定。 S。 デアリング、博士Thesis、1991。 ftp://gregorio.stanford.edu/vmtp/sd-thesis.ps 。
[3] Mechanisms for Broadcast and Selective Broadcast; D. Wall; PhD thesis, Stanford University, June 1980. Technical Report #90.
放送と選択している放送のための[3]メカニズム。 D。 壁。 博士論文、スタンフォード大学、1980年6月。 技術報告書#90。
[4] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[4] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[5] Internet Group Management Protocol, version 2 (IGMPv2); W. Fenner; Work In Progress.
[5] インターネットGroup Managementプロトコル、バージョン2(IGMPv2)。 W。 フェナー。 進行中で、働いてください。
[6] Distance Vector Multicast Routing Protocol (DVMRP); T. Pusateri; Work In Progress.
[6] ベクトルマルチキャストルーティング・プロトコル(DVMRP)を遠ざけてください。 T。 Pusateri。 進行中で、働いてください。
[7] Protocol Independent Multicast (PIM) Dense Mode Specification; D. Estrin et al; ftp://netweb.usc.edu/pim, Work In Progress.
[7] 独立しているマルチキャスト(PIM)の濃いモード仕様を議定書の中で述べてください。 D。 Estrin他。 ftp://netweb.usc.edu/pim 、進行中で、働いてください。
[8] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[8]Moy、J.、「OSPFへのマルチキャスト拡大」、RFC1584、1994年3月。
[9] Reverse path forwarding of broadcast packets; Y.K. Dalal and R.M. Metcalfe; Communications of the ACM, 21(12):1040--1048, 1978.
[9] 放送パケットの経路推進を逆にしてください。 Y.K.DalalとR.M.メトカルフェ。 1040--1048、ACM、21(12)に関するコミュニケーション:1978。
Ballardie Experimental [Page 14] RFC 2201 CBT Multicast Routing Architecture September 1997
構造1997年9月に掘られるBallardieの実験的な[14ページ]RFC2201CBTマルチキャスト
[10] Some Issues for an Inter-Domain Multicast Routing Protocol; D. Meyer; Work In Progress.
[10] 相互ドメインマルチキャストルート設定のためのいくつかの問題が議定書を作ります。 D。 マイヤー。 進行中で、働いてください。
[11] SDP: Session Description Protocol; M. Handley and V. Jacobson; Work In Progress.
[11]SDP: セッション記述プロトコル。 M。 ハンドレーとV.ジェーコブソン。 進行中で、働いてください。
[12] Hierarchical Protocol Independent Multicast; M. Handley, J. Crowcroft, I. Wakeman. Available from: http://www.cs.ucl.ac.uk/staff/M.Handley/hpim.ps and ftp://cs.ucl.ac.uk/darpa/IDMR/hpim.ps Work done 1995.
[12] 階層化プロトコルの独立しているマルチキャスト。 M。 ハンドレー、J.クロウクロフト、I.ウェイクマン。 利用可能: 1995に行われた http://www.cs.ucl.ac.uk/staff/M.Handley/hpim.ps と ftp://cs.ucl.ac.uk/darpa/IDMR/hpim.ps Work
[13] Postel, J., "Internet Control Message Protocol (ICMP)", STD 5, RFC 792, September 1981.
[13] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル(ICMP)」、STD5、RFC792、1981年9月。
[14] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[14] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、1996年10月。
[15] CBT - Dense Mode Multicast Interoperability; A. Ballardie; Work In Progress.
[15]CBT--濃いモードマルチキャスト相互運用性。 A。 Ballardie。 進行中で、働いてください。
[16] Performance and Resource Cost Comparisons of Multicast Routing Algorithms for Distributed Interactive Simulation Applications; T. Billhartz, J. Bibb Cain, E. Farrey-Goudreau, and D. Feig. Available from: http://www.epm.ornl.gov/~sgb/pubs.html; July 1995.
分配された対話的なシミュレーション適用のためのマルチキャストルーティング・アルゴリズムの[16]パフォーマンスとリソース原価比較。 T。 Billhartz、J.Bibbカイン、E.Farrey-グドロー、およびD.Feig。 利用可能: http://www.epm.ornl.gov/~sgb/pubs.html; 1995年7月。
[17] 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/info- comm97ocbt.ps.gz
[17] 命令されたコアは木のプロトコルを基礎づけました。 C。 シールズとJ.J.ガルシアルーナ-Aceves。 IEEE Infocom97年、神戸(日本)1997年4月の議事で。 http://www.cse.ucsc.edu/research/ccrg/publications/info- comm97ocbt.ps.gz
[18] Estrin, D., et. al., "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2117, June 1997.
et[18]Estrin、D.、アル、「独立しているマルチキャストまばらなモード(PIM-Sm)を議定書の中で述べてください」 「プロトコル仕様」、RFC2117、1997年6月。
[19] 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.
[19] マルチキャスト特有の軍事的脅威と対応策。 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 15]
Ballardie実験的です。[15ページ]
一覧
スポンサーリンク
