RFC2102 日本語訳
2102 Multicast Support for Nimrod : Requirements and SolutionApproaches. R. Ramanathan. February 1997. (Format: TXT=50963 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Ramanathan Request for Comments: 2102 BBN Systems and Technologies Category: Informational February 1997
Ramanathanがコメントのために要求するワーキンググループR.をネットワークでつないでください: 2102台のBBNシステムと技術カテゴリ: 情報の1997年2月
Multicast Support for Nimrod : Requirements and Solution Approaches
ニムロデのマルチキャストサポート: 要件とソリューションアプローチ
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
Nimrod does not specify a particular solution for multicasting. Rather, Nimrod may use any of a number of emerging multicast techniques. We identify the requirements that Nimrod has of a solution for multicast support. We compare existing approaches for multicasting within an internetwork and discuss their advantages and disadvantages. Finally, as an example, we outline the mechanisms to support multicast in Nimrod using the scheme currently being developed within the IETF - namely, the Protocol Indpendent Multicast (PIM) protocol.
ニムロデはマルチキャスティングの特殊解を指定しません。 むしろ、ニムロデは多くの現れているマルチキャストのテクニックのいずれも使用するかもしれません。 私たちはニムロデが持っているマルチキャストサポートの解決策の要件を特定します。 私たちは、インターネットワークの中でマルチキャスティングのための既存のアプローチを比較して、それらの利点と損失について議論します。 最終的に、例として、私たちはIETFの中で開発されながらニムロデで現在計画を使用することでマルチキャストを支持するためにメカニズムについて概説します--すなわち、プロトコルIndpendent Multicast(PIM)は議定書を作ります。
Table of Contents
目次
1 Introduction................................................. 2
2 Multicast vs Unicast......................................... 3
3 Goals and Requirements....................................... 4
4 Approaches................................................... 6
5 A Multicasting Scheme based on PIM........................... 10
5.1 Overview ................................................ 10
5.2 Joining and Leaving a Tree .............................. 12
5.2.1 An Example ........................................ 15
5.3 Establishing a Shared Tree .............................. 16
5.4 Switching to a Source-Rooted Shortest Path Tree.......... 18
5.5 Miscellaneous Issues..................................... 20
6 Security Considerations...................................... 21
7 Summary...................................................... 21
8 References................................................... 22
9 Acknowledgements............................................. 23
10 Author's Address............................................. 23
1つの序論… 2 2マルチキャスト対ユニキャスト… 3 3の目標と要件… 4 4のアプローチ… 1Multicasting Schemeあたり6 5はPIMを基礎づけました… 10 5.1概観… 10 5.2 木に合流して、残します… 12 5.2 .1 例… 15 5.3 共有された木を設立します… 16 5.4 ソースが根づいている最短パス木に切り替わります… 18 5.5 種々雑多な問題… 20 6 セキュリティ問題… 21 7概要… 21 8つの参照箇所… 22 9つの承認… 23 10作者のアドレス… 23
Ramanathan Informational [Page 1] RFC 2102 Nimrod Multicast Support February 1997
[1ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
1 Introduction
1つの序論
The nature of emerging applications such as videoconferencing, remote classroom, etc. makes the support for multicasting essential for any future routing architecture. Multicasting is performed by using a multicast delivery tree whose leaves are the multicast destinations.
テレビ会議などのアプリケーション、遠く離れた教室などとして現れる自然で、マルチキャスティングのサポートはどんな今後のルーティング建築にも不可欠になります。 マルチキャスティングは、葉がマルチキャストの目的地であるマルチキャスト配送木を使用することによって、実行されます。
Nimrod does not propose a solution for the multicasting problem. There are two chief reasons for this. First, multicasting is a non- trivial problem whose requirements are still not well understood. Second, a number of groups (for instance the IDMR working group of the IETF) are studying the problem by itself and it is not our intention to duplicate those efforts.
ニムロデはマルチキャスティング問題の解決を提案しません。 この2つの主要な理由があります。 まず最初に、マルチキャスティングは要件がまだよく理解されていない非取るに足りない問題です。 2番目に、多くのグループ(例えば、IETFのIDMRワーキンググループ)自体が問題を研究しています、そして、それはそれらの努力をコピーするという私たちの意志ではありません。
This attitude towards multicasting is consistent with Nimrod's general philosophy of flexibility, adaptability and incremental change.
マルチキャスティングに対するこの態度はニムロデの柔軟性、適応性、および漸進的変化の一般的な哲学と一致しています。
While a multicasting solution per se is not part of the "core" Nimrod architecture, Nimrod does require that the solution have certain characteristics. It is the purpose of this document to discuss some of these requirements and evaluate approaches towards meeting them.
そういうもののマルチキャスティング解決策は「コア」ニムロデ構造の一部ではありませんが、ニムロデは、解決策には、ある特性があるのを必要とします。 これらの要件のいくつかについて議論して、それらに会うことに向かったアプローチを評価するのは、このドキュメントの目的です。
This document is organized as follows. In section 2 we discuss why multicasting is treated a little differently than unicast despite the fact that the former is essentially a generalization of the latter. Following that, in section 4 we discuss current approaches toward multicasting . In section 5, we give an example of how Nimrod multicasting may be done using PIM [DEF+94a]. For readers who do not have the time to go through the entire document, a summary is given at the end.
このドキュメントは以下の通りまとめられます。 セクション2で、私たちは、マルチキャスティングがなぜ前者が本質的には後者の一般化であるという事実にもかかわらず、ユニキャストと異なって少し扱われるかと議論します。 それに続いて、セクション4で、私たちはマルチキャスティングに向かった現在のアプローチについて論じます。セクション5では、ニムロデマルチキャスティングがどうPIM[DEF+94a]を使用し終わるかもしれないかに関する例を出します。 全体のドキュメントを調べる時間を持っていない読者に関しては、終わりに概要をします。
This document uses many terms and concepts from the Nimrod Architecture document [CCS96] and some terms and concepts (in section 5) from the Nimrod Functionality document [RS96]. Much of the discussion assumes that you have read at least the Nimrod Architecture document [CCS96].
このドキュメントはニムロデFunctionalityドキュメント[RS96]からのいくつかのニムロデArchitectureドキュメントからの多くの用語と概念[CCS96]、用語、および概念(セクション5の)を使用します。 議論の多くが、あなたが少なくともニムロデArchitectureドキュメント[CCS96]を読んだと仮定します。
Ramanathan Informational [Page 2] RFC 2102 Nimrod Multicast Support February 1997
[2ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
2 Multicast vs Unicast
2マルチキャスト対ユニキャスト
We begin by looking at the similarities and differences between unicast routing and multicast routing. Both unicast and multicast routing require two phases - route generation and packet forwarding. In the case of unicast routing, Nimrod specifies modes of packet forwarding; route generation itself is not specified but left to the particular routing agent. For multicasting, Nimrod leaves both route generation and packet forwarding mechanisms unspecified. To explain why, we first point out three aspects that make multicasting quite different from unicasting :
私たちは、ユニキャストルーティングとマルチキャストルーティングの類似性と違いを見ることによって、始めます。 ユニキャストとマルチキャストルーティングの両方が二相を必要とします--ルート世代とパケット推進。 ユニキャストルーティングの場合では、ニムロデはパケット推進の方法を指定します。 ルート世代自体は、特定のルーティングエージェントに指定されませんが、任せます。 マルチキャスティングのために、ニムロデはルート世代とパケット推進の両方をメカニズムに不特定のままにします。 理由について説明するために、私たちは最初に、マルチキャスティングをunicastingと全く異なるようにする3つの局面を指摘します:
o Groups and group dynamism. In multicasting, the destinations are part of a group, whose membership is dynamic. This brings up the following issues :
o グループとグループ力動説。 マルチキャスティングでは、目的地は会員資格がダイナミックであるグループの一部です。 これは以下の問題を持って来ます:
- An association between the multicast group and the EIDs and
locators of the members comprising that group. This is especially
relevant in the case of sender initiated multicasting and policy
support.
- そのグループを包括するメンバーのマルチキャストグループと、EIDsとロケータとの協会。 これは送付者の開始しているマルチキャスティングと方針サポートの場合で特に関連しています。
- A mechanism to accommodate new group members in the delivery in
response to addition of members, and a mechanism to "prune" the
delivery in response to departures.
- メンバーの追加に対応して配送で新しいグループのメンバーを収容するメカニズム、および出発に対応して配送を「剪定する」メカニズム。
o State creation. Most solutions to multicasting can essentially be viewed as creating state in routers for multicast packet forwarding. Based on who creates the state, multicasting solutions differ. In multicasting, we have several options for this - e.g., the sender, the receivers or the intermediate routers.
o 創造を述べてください。 マルチキャストパケット推進のためにルータで状態を創設すると本質的にはマルチキャスティングのほとんどの解決策を見なすことができます。 だれが状態を創設するかに基づいて、マルチキャスティング解決策は異なります。 マルチキャスティングでは、私たちはこれのためのいくつかのオプションを持っています--例えば、送付者、受信機または中間的ルータ。
o Route generation. Even more so than in unicast routing, one can choose from a rich spectrum of heuristics with different tradeoffs between a number of parameters (such as cost and delay, algorithmic time complexity and optimality etc.). For instance, some heuristics produce a low-cost tree with high end-to-end delay and some produce trees that give the shortest path to each destination but with a higher cost. Heuristics for multicasting are a significant research area today, and we expect advances to result in sophisticated heuristics in the near future.
o 世代を発送してください。 ユニキャストルーティングよりさらにそうです、多くのパラメタ(費用、遅れ、アルゴリズムの時間的コスト、最適などの)の間には、発見的教授法の豊かなスペクトルと異なった見返りがある状態で、人は選ぶことができます。 例えば、いくつかの発見的教授法が高い端から端への遅れと各目的地に最短パスを与えるいくつかの生産物木にもかかわらず、より高い費用で安価の木を生産します。 今日マルチキャスティングのための発見的教授法は重要な研究領域です、そして、私たちは進歩が近い将来高度な発見的教授法をもたらすと予想します。
Noting that there are various possible combinations of route generation, group dynamism handling and state creation for a solution and that each solution conceivably has applications for which it is the most suitable, we do not specify one particular approach to multicasting in Nimrod. Every implementation of Nimrod is free to use its own multicasting technique, as long as it meets the goals and requirements of Nimrod. However, for interoperability, it is
解決策のためのルート世代の様々な可能な組み合わせ、グループ力動説取り扱い、および州の創造があって、各解決策が多分、それが最も適しているアプリケーションを持っていることに注意して、私たちはニムロデでマルチキャスティングへの1つの特定のアプローチを指定しません。 ニムロデのあらゆる実現が無料でそれ自身のマルチキャスティングのテクニックを使用できます、ニムロデの目標と必要条件を満たす限り。 しかしながら、相互運用性のために、それはそうです。
Ramanathan Informational [Page 3] RFC 2102 Nimrod Multicast Support February 1997
[3ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
necessary that certain things are agreed upon - for instance, the structure of the forwarding information database that they create (we discuss this in more detail in section 4).
あることは同意されます--例えば、それらが作成する(私たちはさらに詳細にセクション4でこれについて議論します)推進情報データベースの構造が必要です。
Thus, we do not discuss the details of any multicast solution here, only its requirements in the context of Nimrod. Specifically, we structure the discussion in the remainder of this document on the following two themes :
したがって、私たちはここのどんなマルチキャスト解決策の詳細、ニムロデの文脈の要件だけについても議論しません。 明確に、私たちは以下の2つのテーマのこのドキュメントの残りにおける議論を構造化します:
o What are the goals that we want to meet in providing multicasting in
Nimrod, and what specific requirements do these goals imply for the
multicast solution?
o マルチキャスティングをニムロデに提供する際に達成したいと思う目標は何です、そして、これらの目標はマルチキャスト解決策のためにどんな決められた一定の要求を含意しますか?
o What are some of the approaches to multicasting being discussed
currently, and how relevant are each of these approaches to Nimrod?
o 現在議論するマルチキャスティングへのアプローチのいくつかが何です、そして、ニムロデへのそれぞれのこれらのアプローチはどれくらい関連していますか?
3 Goals and Requirements
3つの目標と要件
The chief goals of Nimrod multicasting and their implications on solution requirements are as follows:
ニムロデマルチキャスティングの主要目標と解決策要件に関するそれらの含意は以下の通りです:
1. Scalability. Nimrod multicasting must scale in terms of the size of the internetwork, the number of groups supported and the number of members per group. It must also support group dynamism efficiently. This has the following implications for the solution:
1. スケーラビリティ。 ニムロデマルチキャスティングはインターネットワークのサイズ、支持されたグループの数、および1グループあたりの会員数に関して比例しなければなりません。 そうしなければならない、サポートグループ力動説、も効率的に。 これには、解決策のための以下の意味があります:
o Routers not on the direct path to the multicast destinations should
not be involved in state management. In a network with a large
number of routers, a solution that does involve such routers is
unlikely to scale.
o ルータはマルチキャストの目的地への直接路で国家管理にかかわるべきです。 多くのルータがあるネットワークでは、そのようなルータにかかわる解決策は比例しそうにはありません。
o It is likely that there will be a number of applications that have
a few members per group (e.g., medical imaging) and a number of
applications that have a large number of members per group (e.g.,
news distribution). Nimrod multicasting should scale for both
these situations. If no single mechanism adequately scales for
both sparse and dense group memberships simultaneously, a
combination of mechanisms should be considered.
o 数人のグループ(例えば、医療画像処理)あたりのメンバーがいる多くの利用と多くのグループ(例えば、ニュース分配)あたりのメンバーがいる多くの利用がありそうでしょう。 ニムロデマルチキャスティングはこれらの状況の両方のために比例するべきです。 どんなただ一つのメカニズムも同時にまばらなものと同様に濃いグループ会員資格のために適切に比例しないなら、メカニズムの組み合わせは考えられるべきです。
o In the face of group membership change, there must be a facility
for incremental addition or deletion of "branches" in the
multicast tree. Reconstructing the tree from scratch is not likely
to scale.
o グループ会員資格変化に直面して、マルチキャスト木での「ブランチ」の増加の添加か削除のための施設があるに違いありません。 最初から木を再建するのは比例しそうにはありません。
Ramanathan Informational [Page 4] RFC 2102 Nimrod Multicast Support February 1997
[4ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
o It is likely that we will have some well-known groups (i.e., groups
which are more or less permanent in existence) and some ephemeral
groups. The dynamics of group membership are likely to be
different for each class of groups, and the solution should take
that into account as appropriate.
o 私たちには、いくつかの周知のグループ(すなわち、だいたい現存するパーマであるグループ)といくつかのはかないグループがありそうでしょう。 グループ会員資格の力学はそれぞれのクラスのグループにおいて異なる傾向があります、そして、解決策は適宜それを考慮に入れるべきです。
2. Policy support. This includes both quality of service (QOS) as well as access restrictions, although currently, demand is probably higher for QOS. In particular, every path from a source to each destination in the multicast group should satisfy the requested quality of service and conform to the access restrictions. The implications for the multicasting solution are :
2. 方針サポート。 QOSには、要求は現在、たぶんより高いのですが、これはサービスの質(QOS)とアクセス制限の両方を含んでいます。 マルチキャストグループのあらゆるソースから各目的地までの経路が、特に、要求されたサービスの質を満たして、アクセス制限に従うべきです。 マルチキャスティング解決策のための含意は以下の通りです。
o It is likely that many multicasting applications will be cost
conscious in addition to having strict quality of service bounds
(such as delay and jitter). Balancing these will necessitate
dealing with some new parameters - e.g., the tree cost (sum of the
"cost" of each link), the tree delay (maximum, mean and variance
in end-to-end delay) etc.
o 多くのマルチキャスティングアプリケーションが厳しいサービスの質領域(遅れやジターなどの)を持っていることに加えて意識している費用になるのは、ありそうです。 これらのバランスをとるのは、いくつかの新しいパラメタに対処するのを必要とするでしょう--例えば、木の木の遅れ(最大、平均、および変化は終わりから終わりで延着する)費用(それぞれのリンクの「費用」の合計)など
o In order to support policy-based routing, we need to know where the
destinations are (so that we can decide what route we can take to
them). In such a case, a mechanism that provides an association
between a group id and a set of destination locators is probably
required.
o 方針ベースのルーティングを支持するために、私たちは、目的地がどこにあるかを(私たちが、どんなルートをそれらに取ることができるかを決めることができるように)知る必要があります。 このような場合には、グループイドと目的地ロケータのセットとの協会を提供するメカニズムがたぶん必要です。
o Some policy constraints are likely to be destination specific. For
instance, a domain might refuse transit service to traffic going to
certain destination domains. This presents certain unique problems
- in particular, for a single group, multiple trees may need to be
built, each tree "servicing" disjoint partitions of the multicast
destinations.
o いくつかの方針規制が目的地特有である傾向があります。 例えば、ドメインはある一定の目的地ドメインまで続く交通に対するトランジットサービスを拒否するかもしれません。 これはあるユニークな問題を提示します--ただ一つのグループに、特に、複数の木が、建てられる必要があるかもしれなくて、それぞれの木の「整備点検」はマルチキャストの目的地のパーティションをばらばらにならせます。
3. Resource sharing. Multicasting typically goes hand in hand with large traffic volume or applications with a high demand for resources. These, in turn, imply efficient resource management and sharing if possible. Therefore, it is important that we place an emphasis on interaction with resource reservation. For instance, Nimrod must be able to provide information on which tree resources are shareable and which are not so that resource reservation may use it while allocating resources to flows.
3. リソース・シェアリング。 マルチキャスティングはリソースの高需要で手を携えて大きい交通量かアプリケーションを通常伴います。 できれば、これらは順番に効率的な資源管理と共有を含意します。 したがって、私たちが資源予約との相互作用を強調するのは、重要です。 例えば、ニムロデは木のリソースが共有可能とどれが資源予約がリソースを流れに割り当てている間、それを使用できるためのそうでないかということである情報を提供できなければなりません。
4. Interoperability. There are two issues in this context. First, the solution must be independent of mechanisms that provide the solution with information it needs. For instance, many multicast solutions (e.g., PIM) make use of information supplied by unicast routing protocols. The multicast solution must not be dependent on which unicast protocol is used.
4. 相互運用性。 2冊がこのような関係においてはあります。 まず最初に、解決策はそれが必要とする情報を解決策に提供するメカニズムから独自であるに違いありません。 例えば、多くのマルチキャスト解決策(例えば、PIM)がユニキャストルーティング・プロトコルによって提供された情報を利用します。 マルチキャスト解決策はどのユニキャストプロトコルが使用されているかに依存しているはずがありません。
Ramanathan Informational [Page 5] RFC 2102 Nimrod Multicast Support February 1997
[5ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
Second, a multicast solution must interoperate with other multicast solutions in the construction of a delivery tree. This implies some kind of "agreement" at some "level". For instance, the agreement could be that everybody use the same structure for storing forwarding information in the routers. Since the delivery tree is defined by the nature of forwarding information in the routers and not by the particular mechanism used to create that information, multiple implementations can coexist.
2番目に、マルチキャスト解決策は配送木の構造における他のマルチキャスト解決策で共同利用しなければなりません。 これはいくつかの「レベル」である種の「協定」を含意します。 例えば、協定はみんながルータに推進情報を格納するのに同じ構造を使用するということであるかもしれません。 配送木がその情報を作成するのに使用される特定のメカニズムで定義されるのではなく、推進情報の本質によってルータで定義されるので、複数の実現が共存できます。
4 Approaches
4つのアプローチ
The approaches to multicasting currently in operation and those being considered by the IETF include the following :
現在、IETFによって考えられる操作ともののマルチキャスティングへのアプローチは以下を含んでいます:
1. Distance vector multicast routing protocol (DVMRP)[DC90]. This approach is based upon distance-vector routing information distribution and hop-by-hop forwarding. It uses Reverse Path Forwarding (RPF)[DM78] - a distributed algorithm for constructing an internetwork broadcast tree. DVMRP uses a modified RPF algorithm, essentially a truncated broadcast tree, to build a reverse shortest path sender-based multicast delivery tree. A reverse shortest path from s to d is a path that uses the same intermediate nodes as those in the shortest path from d to s (If the paths are symmetric (i.e., cost the same) in either direction, the reverse shortest path is same as the shortest path.) An implementation of RPF exists in the current Internet in what is commonly referred to as the MBONE. An improvement to this is in the process of being deployed. It incorporates "prune" messages to truncate further the routers not on the path to the destinations and "graft" messages to undo this truncation, if later necessary.
1. ベクトルマルチキャストルーティング・プロトコル(DVMRP)[DC90]を遠ざけてください。 このアプローチは距離ベクトルルーティング情報流通とホップごとの推進に基づいています。 それはReverse Path Forwarding(RPF)[DM78]を使用します--インターネットワーク放送木を組み立てるための分配されたアルゴリズム。 DVMRPは、逆の最短パス送付者ベースのマルチキャスト配送木を建てるのに変更されたRPFアルゴリズム、本質的には端が欠けている放送木を使用します。 逆のsからdまでの最短パスはdからsまで最短パスにおけるそれらと同じ中間的ノードを使用する経路(経路がどちらかの方向に左右対称であるなら(すなわち、同じくらいかかります)、逆の最短パスは最短パスと同じです。)です。 RPFの実現は一般的にMBONEと呼ばれることにおける現在のインターネットに存在しています。 配備されることの途中にこれへの改良があります。 目的地への経路でないのにルータにさらに先端を切らせる「プルーン」メッセージとこのトランケーションを元に戻す「汚職」メッセージを取り入れます、より遅れているなら。必要。
The main advantage of this scheme is that it is simple. The major handicap is scalability. Two issues have been raised in this context[BFC93]. First, if S is the number of active sources and G the number of groups, then the state overhead is O(GS) and might be unacceptable when resources are limited. Second, routers not on a multicast tree are involved (in terms of sending/tracking prune and graft messages) even though they might not be interested in the particular source-group pair. The performance of this scheme is expected to be relatively poor for large networks with sparsely distributed group membership. Furthermore, no support for policies or QOS is provided.
この計画の主な利点はそれが簡単であるということです。 大きなハンディキャップはスケーラビリティです。 2冊はこのような関係においては[BFC93]提起されました。 まず最初に、州のオーバーヘッドは、Sが活発なソースの数であり、Gがグループの数であるならO(GS)であり、リソースが限られているとき、容認できないかもしれません。 2番目に、特定のソースグループ組に興味を持たないかもしれませんが、ルータはマルチキャスト木の上でかかわりません(発信/追跡で、メッセージを剪定して、接ぎ木してください)。 この計画の性能がまばらに分配されたグループ会員資格によって大きいネットワークには比較的貧しいと予想されます。 その上、方針かQOSのサポートを全く提供しません。
2. Core Based Trees (CBT)[BFC93]. This scheme uses a single tree shared by all sources per group. This tree has a single router as the core (with additional routers for robustness) from which branches emanate. The chief distinguishing characteristic of CBT is that it is receiver initiated, i.e., receivers wishing to join a multicast group find the tree (or its core) and attach themselves to it, without any
2. コアは木(CBT)[BFC93]を基礎づけました。 この計画はすべての1グループあたりのソースによって共有された単一の木を使用します。 この木には、ブランチが発するコア(丈夫さのための追加ルータがある)としてただ一つのルータがあります。 CBTの主要な区別の特性はそれが開始された受信機であり、すなわち、マルチキャストグループに加わりたがっている受信機が木(または、コア)に当たって、それに愛着を持つということです、いずれなしでも
Ramanathan Informational [Page 6] RFC 2102 Nimrod Multicast Support February 1997
[6ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
participation from the sources.
ソースからの参加。
The chief motivation behind this scheme is the reduction of the state overhead, to O(G), in comparison to DVMRP and PIM(described below). Also, only routers in the path between the core and the potential members are involved in the process. Core-based tree formation and packet flow are decoupled from underlying unicast routing.
この計画の後ろの主要な動機は州のオーバーヘッドの減少です、O(G)に、DVMRPとの比較とPIMで(以下で、説明されます)。 コアと会員になる可能性のある人の間の経路のルータだけが過程にかかわります。 コアベースの木の構成とパケット流動は基本的なユニキャストルーティングから衝撃を吸収されます。
The main disadvantage is that packets no longer traverse the shortest path from the source to their destinations. The performance in general depends on judicious placement of cores and coordination between them. Traffic concentration on links incident to the core is another problem. There is also a dependence on network entities (in other administrative domains, for instance) for resource reservation and policy routing.
主な不都合はパケットがもうソースからそれらの目的地まで最短パスを横断しないということです。 一般に、性能はそれらの間のコアとコーディネートの賢明なプレースメントに依存します。 コアに付随しているリンクへの交通集中は別の問題です。 また、資源予約と方針ルーティングのためのネットワーク実体(例えば他の管理ドメインで)への依存があります。
3. Protocol Independent Multicasting (PIM)[DEFJ93]. Yet another approach based on the receiver initiated philosophy, this is designed to reap the advantages of DVMRP and CBT. Using a "rendezvous point", a concept similar to the core discussed above, it allows for the simultaneous existence of shared and source-specific multicast trees. In the steady state, data can be delivered over the reverse shortest path from the sender to the receiver (for better end-to-end delay) or over the shared tree.
3. 独立しているマルチキャスティング(PIM)[DEFJ93]について議定書の中で述べてください。 受信機に基づいたさらに別のアプローチは哲学を開始して、これは、DVMRPとCBTの利点を獲得するように設計されています。 「ランデブーポイント」、上で議論したコアと同様の概念を使用して、それは共有されてソース特有のマルチキャスト木の同時の存在を考慮します。 定常状態では、逆の送付者から受信機(終わりから終わりへの、より良い遅れのための)までの最短パスの上、または、共有された木の上にデータを送ることができます。
Using two modes of operation, sparse and dense, this provides improved performance, both when the group membership in an internetwork is sparse and when it is dense. It is however, a complex protocol. A limitation of PIM is that the shortest paths are based on the reverse metrics and therefore truly "shortest" only when the links are symmetric.
2つの運転モードを使用して、まばらであって、濃くて、これは向上した性能を提供します、インターネットワークにおけるグループ会員資格がともにまばらであり、それが濃いときに。 しかしながら、それはそうであり、複合体はプロトコルです。 PIMの限界はリンクが左右対称であるときにだけ、最短パスが逆の測定基準に基づいてしたがって、本当に、「最も短い」ということです。
4. Multicast Open Shortest Path First (MOSPF)[Moy92]. Unlike the abovementioned approaches, this is based on link-state routing information distribution. The packet forwarding mechanism is hop-by-hop. Since every router has complete topology information, every router computes the shortest path multicast tree from any source to any group using Dijkstra's algorithm. If the router doing the computation falls within the tree computed, it can determine which links it must forward copies onto.
4. 開いているマルチキャストの最短パスの最初の(MOSPF。)[Moy92] 上記のアプローチと異なって、これはLinkState方式情報流通に基づいています。 パケット推進メカニズムはホップホップです。 あらゆるルータには完全なトポロジー情報があるので、あらゆるルータがダイクストラのアルゴリズムを使用することでどんなソースからどんなグループまでも最短パスマルチキャスト木を計算します。 木の中で計算滝をするルータが計算されたなら、それは、どのリンクにコピーを送らなければならないかを決定できます。
Ramanathan Informational [Page 7] RFC 2102 Nimrod Multicast Support February 1997
[7ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
MOSPF inherits advantages of OSPF and link-state distribution, namely localized route computation (and easy verification of loop-freedom), fast convergence to link-state changes etc. However, group membership information is sent throughout the network, including links that are not in the direct path to the multicast destinations. Thus, like DVMRP, this is most suitable for small internetworks, that is, as an intra-domain routing mechanism.
MOSPFはOSPFの利点とリンク州の分配、すなわち、局所化された経路計算(そして、輪自由の簡単な検証)を引き継ぎます、リンク州の変化などへの速い集合 しかしながら、ネットワーク中でグループ会員資格情報を送ります、マルチキャストの目的地には直接路にないリンクを含んでいて。 したがって、DVMRPのように、これはすなわち、小さいインターネットワーク、イントラドメインルーティングメカニズムとして最も適当です。
5. Inter-Domain Policy Routing (IDPR)[Ste]. This approach uses link-state routing information distribution like MOSPF, but uses source-specified packet forwarding. Using the link-state database, the source generates a policy multicast route to the destinations. Using this, the IDPR path-setup procedure sets up state in intermediate entities for packet duplication and forwarding. The state contains information about the next-hop entities for the multicast flow. When a data packet arrives, it is forwarded to each next hop entity obtained from the state.
5. 相互ドメイン方針ルート設定(IDPR)[Ste]。 このアプローチは、MOSPFのようにLinkState方式情報流通を使用しますが、ソースによって指定されたパケット推進を使用します。 リンク州のデータベースを使用して、ソースは方針マルチキャストルートを目的地に発生させます。 これを使用して、IDPR経路セットアップ手順はパケット重複と推進のために中間的実体で状態を設立します。 状態はマルチキャスト流動のための次のホップ実体の情報を含んでいます。 データ・パケットが到着するとき、状態から得られた次のそれぞれのホップ実体にそれを送ります。
Among the advantages of this approach are its ability to support policy based multicast routing with ease and independence (flexibility) in the choice of multicasting algorithm used at the source. IDPR also allows resource sharing over multiple multicast trees. The major disadvantage is that it makes it relatively more difficult to handle group membership changes (additions and deletions) since such changes must be first communicated to the source of the tree which will then add branches appropriately.
このアプローチの有利な立場の中に、容易さがあるベースのマルチキャストルーティングとマルチキャスティングアルゴリズムの選択における独立(柔軟性)がソースで使用した方針を支持する性能があります。 また、IDPRは複数のマルチキャスト木の上にリソース・シェアリングを許容します。 主要な不都合は最初に次に適切にブランチを加える木の源にそのような変化を伝えなければならないので、グループ会員資格変化(追加と削除)を扱うのを比較的難しくするということです。
We now discuss the applicability of these approaches to Nimrod. Common to all of the approaches described is the fact that we need to set up state in the intermediate routers for multicast packet forwarding. The approaches differ mainly on who initiates the state creation - the sender (e.g., IDPR, PIM), the receiver (e.g., CBT, PIM) or the routers themselves create state without intitiation by the sender or receivers (e.g., DVMRP, MOSPF).
私たちは現在、ニムロデへのこれらのアプローチの適用性について議論します。 説明されたアプローチのすべてに共通であるのは、私たちが、マルチキャストパケット推進のために中間的ルータで状態を設立する必要があるという事実です。 だれが主に州の創造を開始するかに関してアプローチは異なります--送付者か受信機(例えば、DVMRP、MOSPF)で送付者(例えば、IDPR、PIM)、受信機(例えば、CBT、PIM)またはルータ自体がintitiationなしで状態を創設します。
Nimrod should be able to accommodate both sender initiated as well as receiver initiated state creation for multicasting. In the remainder of this section, we discuss the pros and cons of these approaches for Nimrod.
ニムロデはマルチキャスティングのための開始された送付者と受信機の開始している州の創造の両方を収容できるべきです。 このセクションの残りでは、私たちはニムロデのためのこれらのアプローチの賛否両論について議論します。
Nimrod uses link-state routing information distribution (topology maps) and has four modes of packet forwarding - flow mode, Connectivity Specification Chain (CSC) mode, Connectivity Specification Sequence (CSS) mode and datagram mode [CCS96].
ニムロデは、LinkState方式情報流通(トポロジー地図)を使用して、パケット推進の4つの方法を持っています--流れモード、Connectivity Specification Chain(CSC)モード、Connectivity Specification Sequence(CSS)モード、およびデータグラムモード[CCS96]。
Ramanathan Informational [Page 8] RFC 2102 Nimrod Multicast Support February 1997
[8ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
An approach similar to that used in IDPR is viable for multicasting using the flow mode. The source can set up state in intermediate routers which can then appropriately duplicate packets. For the CSC, BTES and datagram modes, an approach similar to the one used in MOSPF is applicable. In these situations, the advantages and disadvantages of these approaches in the context of Nimrod is similar to the advantages and disadvantages of IDPR and MOSPF respectively.
マルチキャスティングに、IDPRで使用されるそれと同様のアプローチは、流れモードを使用することで実行可能です。 ソースは次に適切にパケットをコピーできる中間的ルータで状態を設立できます。 CSC、BTES、およびデータグラムモードにおいて、MOSPFで使用されるものと同様のアプローチは適切です。 これらの状況で、ニムロデの文脈における、これらのアプローチの利点と損失はそれぞれIDPRとMOSPFの利点と難点と同様です。
Sender based trees can be set up using an approach similar to IDPR and generalizing it to an "n" level hierarchy. A significant advantage of this approach is policy-based routing. The source knows about the policies of nodes that care to advertise them and can choose a route the way it wants (i.e., not depend upon other entities to choose the route, as in some schemes mentioned above). Another advantage is that each source can use the multicast route generation algorithm and packet forwarding scheme that best suits it, instead of being forced to use whatever is implemented elsewhere in the network. Further, this approach allows for incrementally deploying new multicast tree generation algorithms as research in that area progresses.
送付者はIDPRと同様のアプローチを使用するのに設定できて、「n」平らな階層構造にそれを一般化する木を基礎づけました。 このアプローチの重要な利点は方針ベースのルーティングです。 情報筋はそれらの広告を出すのを気にかけて、それが欲しい方法でルートを選ぶことができる(すなわち、ルートを選ぶために前記のようにいくつかの計画のように他の実体によりません)ノードの方針に関して知っています。 別の利点は各ソースがそれに最もよく合う計画を進めながらマルチキャストルート世代アルゴリズムとパケットを使用できるということです、ネットワークにおけるほかの場所で実行されるものなら何でも使用させられることの代わりに。 さらに、その領域での研究が進歩をするとき、このアプローチは、新しいマルチキャスト木の世代を増加して配備するためにアルゴリズムを許容します。
CBT-like methods may be used to set up receiver initiated trees. Nimrod provides link-state maps for generating routes and a CBT-like method is compatible with this. For instance, a receiver wishing to join a group may generate a (policy) route to the core for that group using its link-state map and attach itself to the tree.
CBTのような方法は、受信機の開始している木をセットアップするのに使用されるかもしれません。 ニムロデはリンク州の地図をルートを発生させるのに提供します、そして、CBTのような方法はこれと互換性があります。 例えば、仲間に入る受信機願望は、そのグループのために(方針)ルートをコアにリンク州の地図を使用することで発生させて、木に愛着を持つかもしれません。
A disadvantage of sender based methods in general seems to be the support of group dynamism. Specifically, if there is a change in the membership of the group, the particular database which contains the group-destination mapping must be updated. In comparison, receiver oriented approaches seem to be able to accommodate group dynamism more naturally.
一般に、送付者に基づいている方法の不都合はグループ力動説のサポートであるように思えます。 明確に、グループの会員資格における変化があれば、グループ目的地マッピングを含む特定のデータベースをアップデートしなければなりません。 相対的に、受信機指向のアプローチは、より自然にグループ力動説に対応できるように思えます。
Nimrod does not preclude the simultaneous existence of multiple approaches to multicasting and the possibility of switching from one to the other depending on the dynamics of group distributions. Interoperability is an issue - that is, the question of whether or not different implementations of Nimrod can participate in the same tree. However, as long as there is agreement in the structure of the state created (i.e., the states can be interpreted uniformly for packet forwarding), this should not be a problem. For instance, a receiver wishing to join a sender created tree might set up state on a path between itself and a router on the tree with the sender itself being unaware of it. Packets entering the router would now be additionally forwarded along this new "branch" to the new receiver.
グループ配の力学によって、ニムロデは複数のアプローチのマルチキャスティングへの同時の存在と1から切り替わるもう片方への可能性を排除しません。 相互運用性は問題です--すなわち、ニムロデの異なった実現が同じ木に参加できるかどうかに関する問題。 しかしながら、協定が創設された状態の構造にある(パケット推進のために一様にすなわち、州を解釈できます)限り、これは問題であるべきではありません。 例えば、送付者の作成された木に合流する受信機願望は、それに気づかないので、送付者自身と共にそれ自体とルータの間の経路の状態を木に設立するかもしれません。 現在、この新しい「ブランチ」に沿ってさらに、ルータに入るパケットを新しい受信機に送るでしょう。
Ramanathan Informational [Page 9] RFC 2102 Nimrod Multicast Support February 1997
[9ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
In conclusion, the architecture of Nimrod can accommodate diverse approaches to multicasting. Each approach has its disadvantages with respect to the requirements mentioned in the previous section. The architecture does not demand that one particular solution be used, and indeed, we expect that a combination of approaches will be employed and engineered in a manner most appropriate to the requirements of the particular application or subscriber.
結論として、ニムロデの構造はマルチキャスティングへのさまざまのアプローチを収容できます。 各アプローチには、前項で言及された要件に関して損失があります。 本当に、構造は、1つの特殊解が使用されるのを要求しないで、私たちはアプローチの組み合わせが特定用途か加入者の要件に最も適切な方法で使われて、設計されると予想します。
5 A Multicasting Scheme based on PIM
5 PIMに基づくMulticasting Scheme
The Inter-Domain Multicast Routing (IDMR) working group of the IETF has developed a specification for a new multicast scheme, namely, Protocol Independent Multicasting (PIM) for use in the Internet [DEF+94a, DEF+94b]. In this section, we decribe how the schemes mentioned therein may be implemented using the facilities provided by Nimrod.
IETFのInter-ドメインMulticastルート設定(IDMR)ワーキンググループはインターネット[DEF+94a、DEF+94b]での使用のためにすなわち、新しいマルチキャスト計画、プロトコル無党派Multicasting(PIM)への仕様を開発しました。 このセクションでは、私たちはそこに言及された計画がニムロデによって提供された施設を使用することでどう実行されるかもしれないかをdecribeします。
We note that the path setup facility provided in Nimrod makes it very conducive to PIM-style multicasting; despite the length of the description given here, we assure the reader that it is quite simple to implement PIM style multicasting in Nimrod.
私たちは、ニムロデに提供された経路セットアップ施設でそれがPIM-スタイルマルチキャスティングに非常に役に立つようになることに注意します。 ここに与えられた記述の長さにもかかわらず、私たちは、ニムロデでPIMスタイルマルチキャスティングを実行するのがかなり簡単であることを読者に知らせます。
Before reading this section, we recommend that the reader acquire some familiarity with PIM (see [DEF+94a, DEF+94b]).
このセクションを読む前に、私たちは、読者がPIMへの何らかの親しみを取得することを勧めます([DEF+94a、DEF+94b]を見てください)。
5.1 Overview
5.1 概観
The PIM architecture maintains the traditional IP multicast service model of receiver-initiated membership and is independent of any specific unicast routing protocol (hence the name).
PIM構造は、受信機で開始している会員資格の伝統的なIPマルチキャストサービスモデルを維持して、どんな特定のユニキャストルーティング・プロトコル(したがって、名前)からも独立しています。
A significant aspect of PIM is that it provides mechanisms for establishing two kinds of trees - a shared tree, which is intended for low "cost" multicasting and a source-based tree, intended for low delay multicasting.
PIMの重要な局面は2種類の木を設立するのにメカニズムを提供するということです--共有された木。(その木は、低い「費用」マルチキャスティングとソースベースの木のために意図されて、低い遅れマルチキャスティングのために意図しています)。
A shared tree is rooted at a rendezvous point (RP), which is typically a prespecified router for the multicast group in question. In order to establish a shared tree, a designated router (DR) for a host wishing to join a group G initiates a flow setup from the RP for G to the DR. A source S wishing to send to a group G initiates a flow setup between S and the RP for group G. At the conclusion of these flow setups, packets can be forwarded from S to H through the RP. For details on the protocol used to implement this flow setup please refer to [DEF+94b].
共有された木はランデブーポイント(RP)に根づきます。(通常、それは、問題のマルチキャストグループのための前指定されたルータです)。 共有された木を設立するために、グループGに加わりたがっているホストのための代表ルータ(DR)はGのためのRPからDRまでの流れセットアップに着手します。ソースSが、グループGに発信するのがSの間の流れセットアップに着手して、グループG.AtのためのRPがこれらの流れセットアップの結論に着手することを願っている場合、RPを通してSからHまでパケットを進めることができます。 この流れセットアップを実行するのに使用されるプロトコルに関する詳細について、[DEF+94b]を参照してください。
Ramanathan Informational [Page 10] RFC 2102 Nimrod Multicast Support February 1997
[10ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
After the shared tree has been setup, a recipient for group G has the option of switching to a source-based shortest path tree. In such a tree, packets are delivered from the source to each recipient along the shortest path. To establish a source-based shortest path tree, the DR for H looks at the source S of the packets it is receiving via the shared tree and establishes a flow between S and the DR. The flow is established along the shortest path from the DR to S (Thus, strictly speaking, it is the reverse shortest path that is being used.) Subsequently, packets can be forwarded from S to H using this shortest path and thereby bypassing the RP. For details on the protocol used to implement source-based trees in PIM please refer to [DEF+94b].
共有された木がセットアップであることの、後で、グループGのための受取人にはソースベースの最短パス木に切り替わるオプションがあります。 そのような木では、パケットは最短パスに沿ってソースから各受取人まで果たされます。 HのためのDRは、ソースベースの最短パス木を証明するために、それが共有された木を通して受けているパケットの源Sを見て、SとDRの間で流れを確立します。流れは最短パスに沿ってDRからSまで確立されます(厳密に言うと、その結果、それは使用されている逆の最短パスです。)。 次に、この最短パスを使用して、その結果、RPを迂回させながら、SからHまでパケットを進めることができます。 PIMでソースベースの木を実行するのに使用されるプロトコルに関する詳細について、[DEF+94b]を参照してください。
When a host wishes to leave a multicast group, its designated router sends a prune message towards the source (for source-based trees) or towards the RP (for shared trees). For details on this and other features of PIM please refer to [DEF+94b].
ホストがマルチキャストグループを出たがっているとき、代表ルータはソース(ソースベースの木のための)かRP(共有された木のための)に向かってプルーンのメッセージを送ります。 これに関する詳細とPIMの他の特徴について、[DEF+94b]を参照してください。
In Nimrod, PIM is implemented as follows (we refer to PIM based multicast as Nimpim). In order to join a shared tree, an endpoint (or an agent acting on behalf of the endpoint) wishing to join a group G queries the association database for the EID and locator of the RP for G (for well-known groups the association may be configured). It is required that such an association be maintained for every multicast group G. The endpoint gets a route for the RP and initiates a multicast flow setup to the RP (a multicast flow setup is similar to an unicast flow setup described in [CCS96] except for one feature - when a multicast flow setup request reaches a node that already has that flow present, the request is not forwarded further. The new flow gets "spliced" in as a new branch of the existing multicast tree). Similarly, the source establishes a flow to the RP. The RP creates state to associate these two flows and now packets can be forwarded to the endpoints from the source. Note that each flow setup may be "hierarchical" and involve many subflows. All this, however, is transparent to Nimpim. For details on management of hierarchical flows please refer to [CCS96].
ニムロデでは、PIMは以下の通り実行されます(私たちはPIMのベースのマルチキャストをNimpimと呼びます)。 共有された木に合流して、グループGに加わる終点(または、終点を代表して行動しているエージェント)願望はGのためにRPのEIDとロケータのための協会データベースについて質問します(周知のグループにおいて、協会は構成されるかもしれません)。 そのような協会が終点がRPのためにルートを手に入れるあらゆるマルチキャストグループG.のために維持されて、マルチキャスト流れセットアップにRPに着手するのが必要です。(マルチキャスト流れセットアップは1つの特徴以外の[CCS96]で説明されたユニキャスト流れセットアップと同様です--マルチキャスト流れセットアップ要求が既にその流れプレゼントを持っているノードに達するとき、要求はさらに転送されません。 流れが既存のマルチキャスト木の新しい枝として「継がれること」に得る新しさ). 同様に、ソースはRPへの流れを確立します。 RPはこれらの2回の流れを関連づけるために状態を創設します、そして、今、パケットをソースから終点に送ることができます。 それぞれの流れセットアップが「階層的であり」、多くの「副-流れ」を伴うかもしれないと述べてください。 しかしながら、このすべてがNimpimに透明です。 階層的な流れの管理に関する詳細について、[CCS96]を参照してください。
To create the source-based tree, the representative for a recipient node N obtains the EID or locator of the source from the data packets and initiates a multicast flow setup to the source. The route agent for the node N uses its map in order to calculate the shortest path from the source to N. The flow request is sent along the reverse of this path. We note that the "shortness" of the path is constrained by the amount of routing information available locally. However, since the map is available locally, one can find the actual shortest path from the source to N and not use the shortest path from N to S. Thus, with Nimrod one can actually surmount a shortcoming of PIM with relative ease.
受取人ノードNのための代表は、ソースベースの木を作成するために、データ・パケットからソースのEIDかロケータを入手して、マルチキャスト流れセットアップにソースに着手します。 ノードNのためのルートエージェントは、N. ソースから流れ要求までの最短パスがこの経路の逆に沿って送られると見込むのに地図を使用します。 私たちは、経路の「短かさ」がルーティング情報の有効な量によって局所的に抑制されることに注意します。 しかしながら、地図が局所的に利用可能であるので、ものによって、実際のソースから使用ではなく、Nまでの最短パスが最短パスであることをNからS.Thusまで見つけることができて、ニムロデと共に、1つは実際に相対的な容易さでPIMの短所を乗り越えることができます。
Ramanathan Informational [Page 11] RFC 2102 Nimrod Multicast Support February 1997
[11ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
We now discuss some more details of Nimpim. We start with a description of multicast flow setup. This is the "basic" functionality required to implement multicasting. Having this "building-block" spelt out, we use this to specify the establishment of the shared tree (in section 5.3) and the establishment of a source-based tree (in section 5.4).
私たちは現在、Nimpimのそれ以上の細部について議論します。 私たちはマルチキャスト流れセットアップの記述から始まります。 これはマルチキャスティングを実行するのに必要である「基本的な」機能性です。 この「ブロック」について詳しく説明させて、私たちは、共有された木の設立(セクション5.3の)とソースベースの木の設立(セクション5.4の)を指定するのにこれを使用します。
We only discuss sparse-mode multicasting, as described in [DEF+94a] here. Further, to simplify the discussion, we assume a single Rendezvous Point per group. Finally, we "address" all entities in terms of their EIDs alone for reasons of conciseness - the locators could be used in conjuction to reduce the overhead of database lookups.
私たちはここで[DEF+94a]で説明されるようにまばらなモードマルチキャスティングについて議論するだけです。 さらに、議論を簡素化するために、私たちは1グループあたり1独身のRendezvous Pointを仮定します。 最終的に、私たちは簡潔の理由でそれらのEIDsに関して単独ですべての実体を「記述します」--データベースルックアップのオーバーヘッドを下げるのにconjuctionでロケータを使用できました。
5.2 Joining and Leaving a Tree
5.2 木に合流して、残すこと。
Nimpim uses two control packets in order to setup a flow - the Nimrod Multicast Flow-Request packet (NMFReq) and the Nimrod Multicast Flow-Reply packet (NMFRep).
Nimpimは流れをセットアップするのに2つのコントロールパケットを使用します--ニムロデMulticast Flow-リクエスト・パケット(NMFReq)とニムロデMulticast Flow-回答パケット(NMFRep)。
The NMFReq packet is a control packet identified by a prespecified "payload type". The protocol-specific part of this packet includes the following fields (except for the Code field, these fields are present in the Unicast Flow-Request packet too) :
NMFReqパケットは前指定された「ペイロードタイプ」によって特定されたコントロールパケットです。 このパケットのプロトコル特有の一部が以下の分野を含んでいます(Code分野を除いて、これらの分野はUnicast Flow-リクエスト・パケットにも存在しています):
1. S-EID : The EID of the initiator of the flow.
1. S-エイド: 流れの創始者のEID。
2. T-EID : The EID of the target of the flow.
2. T-エイド: 流れの目標のEID。
3. Flow-id : A label denoting the flow.
3. 流れイド: 流れを指示するラベル。
4. Direction : The direction of the flow - whether from the initiator
to the target (FORW) or from the target to the initiator (REVERSE)
or both (BOTH).
4. 指示: 流れの方向--目標から創始者から目標(FORW)か創始者(REVERSE)か両方(BOTH)にかかわらず。
5. Code : Denotes whether the packet is for joining a flow
(NMFReq-Join) for leaving a flow (NMFReq-Prune).
5. コード: パケットが流れを接合するもの(NMFReq接合する)であるか否かに関係なく、流れ(NMFReq-プルーン)を残すために指示します。
6. Source Route : A sequence of node locators through which the packet
must travel.
6. 送信元経路: パケットが移動しなければならないノードロケータの系列。
Ramanathan Informational [Page 12] RFC 2102 Nimrod Multicast Support February 1997
[12ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
The processing of the NMFReq by a forwarding agent at node N is similar to that of the unicast flow request (see [CCS96]), except for the fact that now we provide the ability for the new flow to "splice" onto an existing delivery tree or "un-splice" from an existing delivery tree. Specifically,
ノードNの小口運送業者によるNMFReqの処理はユニキャスト流れ要求のものと同様です([CCS96]を見てください)、今、私たちが新しい流れが既存の配送木から既存の配送木か「不-接続」に「継ぐ」能力を提供するという事実を除いて。 明確に
o If the Code is NMFReq-Join then the algorithm executed by the
forwarding agent for node N is shown in Figure 1.
o CodeがNMFReq接合しているなら、ノードNのために小口運送業者によって実行されたアルゴリズムは図1に示されます。
o If the Code is NMFReq-Prune then the algorithm is executed by the
forwarding agent at node N is shown in Figure 2.
o CodeがNMFReq-プルーンであるなら、アルゴリズムはNが図2に示されるノードで小口運送業者によって実行されます。
The NMFRep packet is used to accept or reject an NMFReq-Join or NMFReq-Prune. The packet format is the same as that for unicast flow request. However, an NMFRep packet is generated now by the first node N that grafts the new flow to the existing tree. This may be different from the target of the NMFReq.
NMFRepパケットが受け入れるか、または拒絶するのにおいて使用されている、NMFReq接合するか、NMFReq剪定 パケット・フォーマットはユニキャスト流れ要求のためのそれと同じです。 しかしながら、NMFRepパケットは現在、既存の木への新しい流れを接ぎ木する最初のノードNで発生します。 これはNMFReqの目標と異なっているかもしれません。
It is required that a leaf router keep track of all hosts currently joined to the group and send a prune message only if there is no host in the local network for the group.
葉のルータが現在グループで加わられているすべてのホストの動向をおさえて、グループのための企業内情報通信網にホストが全くいない場合にだけプルーンのメッセージを送るのが必要です。
The NMFReq - NMFRep exchanges constitute a procedure for joining a multicast delivery tree (when the Code is Join) and for leaving a multicast delivery tree (when the Code is Prune). We term these procedures Tree-Join and Tree-Leave respectively; we shall be using these procedures as "building-blocks" in the construction of shared trees (section 5.3) and of source-based trees (section 5.4).
NMFReq--NMFRep交換はマルチキャスト配送木(CodeがJoinであるときに)に合流して、マルチキャスト配送木を残すための手順を構成します(CodeがPruneであるときに)。 私たち、これらの手順がそれぞれTree接合して、Tree残す用語。 私たちは「ブロック」として共有された木(セクション5.3)とソースベースの木(セクション5.4)の構造でこれらの手順を用いるでしょう。
Ramanathan Informational [Page 13] RFC 2102 Nimrod Multicast Support February 1997
[13ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
begin
if the flow-id F in NMFReq-Join is in flow-list then
if T-EID in NMFReq-Join = target in flow state for F then
if Direction in NMFReq-Join is REVERSE or BOTH then
Add the node preceding N in source route to child list for F
else
discard packet
else
discard packet
else
begin
install state for F in N, i.e.,
assign parent(F) = node succeeding N in source route
assign child(F) = node preceeding N in source route
assign target(F) = T-EID in NMFReq-Join
forward NMFReq-Join to parent(F)
end
end.
NMFReq接合しているところのDirectionがREVERSEであるかほかのFがほかにパケットを捨てるので子供リストへの送信元経路によるBOTHの当時のAddノード先行Nがほかにパケットを捨てるならそしてFがインストールを始めるので流れ状態のNMFReq接合している=目標のT-EIDが、送信元経路によるNが目標(F)=T-EIDを割り当てるノード送信元経路案配子供(F)でNを引き継ぐすなわち、NのF、案配親(F)=ノード=preceedingのために中で前方に親(F)終わりのエンドにNMFReq接合していた状態でNMFReq接合するように述べるならNMFReq接合しているところの流れイドFがその時流れリストにあるなら、始まってください。
Figure 1: Algorithm executed by a forwarding agent for node N when when it receives an NMFReq-Join.
図1: アルゴリズムがノードNのために、小口運送業者で、それが受信される時を実行した、NMFReq接合してください。
begin
if the flow-id F in NMFReq-Prune is in flow-list
then begin
delete previous hop in source route from child list for F, if exists
if child list for F is empty
then begin
delete the flow-id and state associated with it
forward to next hop in source route
end
else discard packet
end
else forward to next hop in source-route
end.
NMFReq-プルーンの流れイドFによる次に流れリストが始めるコネがFのために送信元経路で子供リストから前のホップを削除するということであるなら始まってください、存在、Fがその時空であるので子供リストが始まるなら、流れイドを削除してください、そして、それが前方にある状態で送信元経路エンドのほかの次のホップに関連づけられて、送信元経路エンドを次に跳ぶためにほかに前方にパケット終わりを捨てるように述べてください。
Figure 2: Algorithm executed by a forwarding agent for node N when it receives an NMFReq-Prune.
図2: NMFReq-プルーンを受けるとき、アルゴリズムはノードのために小口運送業者でNを実行しました。
Ramanathan Informational [Page 14] RFC 2102 Nimrod Multicast Support February 1997
[14ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
5.2.1 An Example
5.2.1 例
An example of how a tree is joined is given here with the help of Figure 3. In the figure, bold lines indicate an existing tree. Representative R on behalf of host H joins the tree by sending an NMFJoin-Req towards a target T. When used in the shared tree mode, the target is the RP and when used in the source tree mode, it is the source (root) of the multicast tree. Suppose that a host H wants to join the multicast tree. The following steps are executed :
木がどう合流されているかに関する例は図3の助けによってここに出されます。 図では、太い線は既存の木を示します。 共有された木のモードで使用される目標T.Whenに向かってNMFJoin-Reqを送ることによって、ホストHを代表した代表Rは木に合流します、そして、目標はRPです、そして、ソース木のモードで使用されると、それはマルチキャスト木の源(根)です。 ホストHがマルチキャスト木に合流したがっていると仮定してください。 以下のステップは実行されます:
Step 1. A representative R of H queries the route agent for a route
from T to R. It obtains the route T - C- B - A - R. It builds a
NMFJoin-Req packet with source route as R, A, B, C, T and flow
as F forwards it to A.
1を踏んでください。 Hの代表RはTからR.までルートエージェントについてルートに質問します。ItはルートTを入手します--FとしてのR、A、B、C、T、および流れがそれをAに送るとき、C B--A--R.Itは送信元経路でNMFJoin-Reqパケットを建てます。
Step 2. A looks for flow F in its installed flow database and
doesn't find it. It installs state for F (makes R a child and
B a parent in the multicast tree) and sends the NMFJoin-Req packet
to B.
2を踏んでください。 Aは、インストールされた流れデータベースにおける流れFを探して、それを見つけません。 それは、F(マルチキャスト木で子供にRを作って、親にBを作る)のために状態をインストールして、NMFJoin-ReqパケットをBに送ります。
Step 3. B looks for flow F in its installed flow database and finds it.
It adds B to its child list and constructs an NMFJoin-Rep packet and
sends it to A.
3を踏んでください。 Bは、インストールされた流れデータベースにおける流れFを探して、それを見つけます。 それは、子供リストにBを追加して、NMFJoin-レップパケットを組み立てて、それをAに送ります。
Step 4. A forwards the packet to R and the tree joining is complete.
Branch B-A-R is now added to the tree.
4を踏んでください。 AはパケットをRに送ります、そして、木の接合は完全です。 分岐してください。B A Rは現在、木に加えられます。
Ramanathan Informational [Page 15] RFC 2102 Nimrod Multicast Support February 1997
[15ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
5.3 Establishing a Shared Tree
5.3 共有された木を設立すること。
There are two parts to establishing a shared tree - the receiver-to- RP communication wherein the receiver joins the delivery tree rooted at RP and the sender-to-RP communication wherein the RP joins the delivery tree rooted at the sender.
共有された木を設立するのに2つの部品があります--受信機からRPへの受信機がRPに根づいている配送木に合流するコミュニケーションと送付者からRPへのRPが送付者に根づいている配送木に合流するコミュニケーション。
T
+---+
| |\
+---+ \
/ \
/ \
C / \ X
+---+ +---+
| | | |
+---+ +---+
\
\
\
R join-req join-req \ B
+---+ - - - - -> +---+ - - - - -> +---+
| |<------------| |<-----------| |
+---+ join-rep +---+ join-rep +---+
| A \
| \
| \ Y
( ) +---+
H | |
+---+
T+---+ | |\ +---+ \/\/\C/\X+---+ +---+ | | | | +---+ +---+ reqを接合している\R reqを接合している\B\\+---+--、--、--、--、->+---+--、--、--、--、->+---+ | | <、-、-、-、-、-、-、-、-、-、-、--、| | <、-、-、-、-、-、-、-、-、-、--、|、| +---+ レップを接合している+---+ レップを接合している+---+ | \| \ | \Y( )+---+ H| | +---+
Figure 3: Illustration for the example describing joining an existing multicast tree.
図3: 既存のマルチキャスト木に合流すると説明する例のためのイラスト。
Receiver-RP Communications: When an endpoint wishes to join a multicast group G, the endpoint representative obtains the Rendezvous Point EID for G. We assume that the association database contains such a mapping. For details on how the association database query is implemented, please refer [CCS96].
受信機-RPコミュニケーション: 終点であるときに、マルチキャストを接合するという願望はGを分類して、終点代表はRendezvous Point EIDをG.に入手します。Weは、協会データベースがそのようなマッピングを含むと仮定します。 協会データベース質問がどう実行されるかに関する詳細について、[CCS96]を参照してください。
The representative also obtains the flow-id to be used for the flow. The flow-id is constructed as the tuple (RP-EID, G) or an equivalent thereof. Note that the flow-id must be unique to the particular multicast flow. This is not the only method or perhaps even the best method for obtaining a flow id. Alternate methods for obtaining the flow-id are discussed in section 5.5.
また、代表は、流れに使用されるために流れイドを得ます。 流れイドはtuple(RP-EID、G)かそれの同等物として構成されます。 流れイドが特定のマルチキャスト流動にユニークであるに違いないことに注意してください。 これは、流れイドを得るための唯一の方法でなくて、また恐らくまたは最も良い方法でもありません。 セクション5.5で流れイドを得るための代替方法について議論します。
Ramanathan Informational [Page 16] RFC 2102 Nimrod Multicast Support February 1997
[16ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
The representative then initiates a Tree-Join procedure.
そして、代表はTree接合している手順に着手します。
The NMFReq packet fields are as follows:
NMFReqパケット分野は以下の通りです:
o S-EID : The EID of the endpoint wishing to join.
o S-エイド: 接合したがっている終点のEID。
o T-EID : The RP EID (obtained from the Association Database).
o T-エイド: RP EID(協会データベースから、得ます)。
o Flow-id : The flow-id for this group (obtained as mentioned
above).
o 流れイド: このグループ(以上のように、得る)のための流れイド。
o Direction : REVERSE (from the RP to the receiving endpoint).
o 指示: REVERSE(RPから受信終点までの)。
o Code : Join.
o コード: 接合してください。
o Source Route : Reverse of the route obtained from the map agent
for a query "from RP-EID to Receiver-EID".
o 送信元経路: ルートの逆は地図エージェントから「RP-EIDから受信機-EID」を質問に得ました。
At the first node already containing this Flow-id or the RP, an NMFRep packet is generated. The S-EID, T-EID, Direction and Flow-id fields are copied from the NMFReq packet and the Code is set to Join-Accept or Join-Refuse as the case may be. The source route is reversed from the NMFReq packet.
既にこのFlow-イドを含む最初のノードかRPでは、NMFRepパケットは発生します。 CodeはS-EID、T-EID、Direction、およびFlow-イド分野はNMFReqパケットからコピーされて、Join受け入れるセットか場合によってJoin-廃物です。 送信元経路はNMFReqパケットから逆にされます。
Sender-RP Communications: When an endpoint wishes to send to a multicast group G, the endpoint representative obtains the Rendezvous Point EID for G. We assume that the association database contains such a mapping. For details on how the association database query is implemented, please refer [CCS96].
送付者-RPコミュニケーション: 終点であるときに、マルチキャストに発信するという願望はGを分類して、終点代表はRendezvous Point EIDをG.に入手します。Weは、協会データベースがそのようなマッピングを含むと仮定します。 協会データベース質問がどう実行されるかに関する詳細について、[CCS96]を参照してください。
The representative also obtains the flow-id to be used for the flow. The flow-id is constructed as the tuple (Sender-EID, G) or an equivalent thereof. Note that the flow-id must be unique to the particular multicast flow. This is not the only method or perhaps even the best method for obtaining a flow id. Alternate methods for obtaining the flow-id are discussed in section 5.5.
また、代表は、流れに使用されるために流れイドを得ます。 流れイドはtuple(送付者-EID、G)かそれの同等物として構成されます。 流れイドが特定のマルチキャスト流動にユニークであるに違いないことに注意してください。 これは、流れイドを得るための唯一の方法でなくて、また恐らくまたは最も良い方法でもありません。 セクション5.5で流れイドを得るための代替方法について議論します。
The representative then sends a RP-Register Message to the RP. This register message is equivalent to the PIM-Register described in [DEF+94b]. The RP-Register message contains the group G and the flow-id (obtained as discussed above) and the sender EID.
そして、代表はRP-レジスタMessageをRPに送ります。 このレジスタメッセージは[DEF+94b]で説明されたPIM-レジスタに同等です。 RP-レジスタメッセージはグループG、流れイド(上で議論するように、得る)、および送付者EIDを含んでいます。
The RP then initiates a Tree-Join with the Sender EID as the target. The NMFReq fields are as follows :
そして、RPは目標としてSender EIDにTree接合しているaを開始します。 NMFReq分野は以下の通りです:
o S-EID : RP-EID.
o S-エイド: RP-エイド。
o T-EID : Sender EID (copied from RP-Register Message).
o T-エイド: 送付者EID(RP-レジスタメッセージから、コピーされます)。
Ramanathan Informational [Page 17] RFC 2102 Nimrod Multicast Support February 1997
[17ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
o Flow-id : The flow-id field from RP-Register Message.
o 流れイド: RP-レジスタMessageからの流れイド分野。
o Code : Join.
o コード: 接合してください。
o Direction : REVERSE.
o 指示: 逆になってください。
o Source Route : Reverse of the route obtained from map agent
query "from Sender-EID to RP-EID".
o 送信元経路: ルートの逆は地図エージェント質問から「送付者-EIDからRP-EID」を得ました。
The NMFRep fields are obvious.
NMFRep分野は明白です。
Shared Tree Data Forwarding: Packets sent from the source for group G contain the Flow-id used by the sender(s) and receiver(s) for setting up the delivery tree. The packets from the sender are sent to the RP where they are multicast, using the state created for the flow, into the delivery tree rooted at the RP to all of the receivers that did a Tree-Join.
共有された木のデータ推進: グループGのためにソースから送られたパケットは配送木をセットアップするのに送付者と受信機によって使用されるFlow-イドを含んでいます。 それらがマルチキャストであるRPに送付者からのパケットを送ります、流れのために創設された状態を使用して、Tree接合していた状態でaをした受信機のすべてへのRPに根づいている配送木に。
5.4 Switching to a Source-Rooted Shortest Path Tree
5.4 ソースが根づいている最短パス木に切り替わること。
There are two parts involved in switching to a Source-Rooted Shortest Path Tree - the receiver-source communications wherein the receiver joins a multicast delivery tree rooted at the source and the receiver-RP communications wherein the receiver leaves the shared tree.
Sourceが根づいているShortest Path Treeに切り替わるのにかかわる2つの部品があります--受信機がマルチキャスト配送木に合流する受信機ソースコミュニケーションはソースと受信機が共有された木を出発する受信機-RPコミュニケーションで捜しました。
Receiver-Source Communications: An endpoint E that is receiving packets through the shared tree from source S has the option of switching to a delivery tree rooted at the source such that packets from S to E traverse the shortest path (using whatever metric).
受信機ソースコミュニケーション: SからEまでのパケットがソースに共有された木を通してソースSからパケットを受けている終点Eで配送木に切り替わるオプションを根づかせるので最短パスを横断する、(何でも使用する、メートル法、)
The endpoint representative of E obtains the flow-id to be used for the flow. The flow-id is constructed equivalently to the tuple (Source-EID, G). Note that the flow-id must be unique to the particular multicast flow. This is not the only method or perhaps even the best method for obtaining a flow id. Alternate methods for obtaining the flow-id are discussed in section 5.5.
Eを代表している終点は、流れに使用されるために流れイドを得ます。 流れイドは同等にtuple(ソース-EID、G)に構成されます。 流れイドが特定のマルチキャスト流動にユニークであるに違いないことに注意してください。 これは、流れイドを得るための唯一の方法でなくて、また恐らくまたは最も良い方法でもありません。 セクション5.5で流れイドを得るための代替方法について議論します。
The representative for E initiates a Tree-Join toward S with NMFReq fields as follows:
Eの代表は以下のNMFReqと共にSに向かってTree接合している分野を開始します:
o S-EID : EID of the Endpoint E.
o S-エイド: 終点EのEID。
o T-EID : EID of the source.
o T-エイド: ソースのEID。
o Flow-id : Flow id for the multicast (obtained as mentioned above).
o 流れイド: マルチキャスト(以上のように、得る)のための流れイド。
o Code : Join.
o コード: 接合してください。
Ramanathan Informational [Page 18] RFC 2102 Nimrod Multicast Support February 1997
[18ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
o Direction : REVERSE.
o 指示: 逆になってください。
o Source Route : To obtain the route, the route agent is queried for
a shortest path route (based on the chosen metric, typically, the
delay) from the source to the endpoint. We note that the quality
of the route is constrained by the amount of routing information
available, directly or indirectly, to the route agent. The Source
Route is the reverse of the route thus obtained.
o 送信元経路: ルートを入手するために、ルートエージェントが最短パスルートに質問される、(選ぶのにメートル法であることで通常基づいている、遅れ) ソースから終点まで。 私たちは、ルートの品質が直接か間接的なルートエージェントにとって、利用可能なルーティング情報の量によって抑制されることに注意します。 Source Routeはこのようにして入手されたルートの逆です。
A comment on the difference between the shortest-path trees obtained using the RPF tree as in [DEF+94b, DC90] and the trees that are be obtained here. When using the RPF scheme, the packets from the source S to the endpoint E follow a path that is the shortest path from E to S. This is the desired path if and only if the path is symmetric in either direction. However, in the mechanism described here for Nimrod, the packets do follow the "actual" shortest path from S to E whether or not the path is symmetric.
最短パス木の違いのコメントは[DEF+94b、DC90]のようにRPF木を使用して、木を得ました。ここで、得ます。 そして、RPF計画を使用するとき、ソースSから終点Eまでのパケットが小道をたどって、すなわち、EからS.Thisまでの最短パスが必要な経路である、経路がどちらかの方向に左右対称である場合にだけ。 しかしながら、ニムロデのためにここで説明されたメカニズムでは、経路が左右対称であるか否かに関係なく、パケットは「実際」のSからEまでの最短パスに続きます。
The NMFRep fields are obvious.
NMFRep分野は明白です。
Receiver-RP Communications: After the receiver has joined the source-rooted tree, it can optionally disassociate itself from the shared tree. This is done by initiating a Tree-Leave procedure.
受信機-RPコミュニケーション: 受信機がソースが根づいている木に合流した後に、それは共有された木からそれ自体を任意に分離できます。 Tree-休暇手順に着手することによって、これをします。
The representative sends a NMFReq packet toward the RP with the fields as follows.
分野は以下の通りで代表がNMFReqパケットをRPに向かって送ります。
o S-EID : The EID of the endpoint wishing to leave the shared tree.
o S-エイド: 共有された木を残したがっている終点のEID。
o T-EID : The RP-EID.
o T-エイド: RP-EID。
o Flow-id : The flow-id it used to join the shared tree.
o 流れイド: それが共有された木に合流するのに使用した流れイド。
o Code : Prune.
o コード: 剪定します。
o Direction : REVERSE.
o 指示: 逆になってください。
o Source Route : Obtained as for the Tree-Join.
o 送信元経路: 得る、木で接合しています。
The prune packet is processed by the intermediate forwarding agents as mentioned in section 5.2. When the receiver gets back the NMFRep packet, the receiver has left the shared tree.
プルーンのパケットはセクション5.2で言及されるように中間的小口運送業者によって処理されます。 受信機がNMFRepパケットを取り戻すとき、受信機は共有された木を出発しました。
Source Tree Data Forwarding: Packets from the source contain the flow-id that was used to join the source tree for a given multicast group. Forwarding agents simply use the state created by the Tree- Join procedure in order to duplicate and forward packets toward the receivers.
ソース木のデータ推進: ソースからのパケットは与えられたマルチキャストグループのためにソース木に合流するのに使用された流れイドを含んでいます。 Treeによって作成されて、小口運送業者は単に状態を使用します。受信機に向かってパケットをコピーして、送るために手順を接合してください。
Ramanathan Informational [Page 19] RFC 2102 Nimrod Multicast Support February 1997
[19ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
5.5 Miscellaneous Issues
5.5 種々雑多な問題
Obtaining the Flow-Id: In the above scheme the flow-id for a particular multicast group G was obtained by combining the RP-EID and the group set-id (G-SID) (in case of shared tree) or by combining the Source-EID and the G-SID (in case of source-based tree). A disadvantage of this approach is that the bit-length of EID/SID is potentially high (more than 64 bits) and thus the flow-id could be very long. While there do exist bit-based data structures and search algorithms (such as Patricia Trees) that may be used for an efficient implementation, it is worth considering some other methods in lieu of using the EID/SID combination. We describe some methods below :
流れイドを得ます: 上の計画では、RP-EIDとグループセットイド(G-SID)(共有された木の場合の)を結合するか、またはSource-EIDとG-SID(ソースベースの木の場合の)を結合することによって、特定のマルチキャストグループGのための流れイドを得ました。 このアプローチの不都合はEID/SIDのビット-長さが潜在的に高く(64ビット以上)、その結果、流れイドが非常に長いかもしれないということです。 効率的な実現に使用されるかもしれないビットベースのデータ構造と検索アルゴリズム(パトリシアTreesなどの)は存在していますが、EID/SID組み合わせを使用することの代わりにある他の方法を考える価値があります。 私たちは以下のいくつかの方法を説明します:
1. For shared trees, the flow-id for a particular group G may be stored and updated in the association database. Since we have to use the association database anyway to obtain the RP-EID, these does not cause much additional burden.
1. 共有された木に関しては、協会データベースで特定のグループGのための流れイドを格納して、アップデートするかもしれません。 私たちがRP-EIDを入手するのにとにかく協会データベースを使用しなければならないので、これらは多くの追加負担を引き起こしません。
However, this cannot be used efficiently for source-based trees because we need a flow-id for each combination of Source and Group.
しかしながら、私たちがSourceとGroupの各組み合わせに流れイドを必要とするので、ソースベースの木に効率的にこれを使用できません。
2. The flow-id for shared trees could be done as above. When the sender does an RP-Register, it could send the RP the flow-id that it wishes to be used by receivers when they switch to a source-based tree. This could be included in the RP-Register message. The RP could then multicast that flow-id to all receivers in a special packet. When the receivers wish to switch, they use that flow-id.
2. 同じくらい上で共有された木のための流れイドができました。 送付者がRP-レジスタをすると、それはソースベースの木に切り替わるとき受信機によってそれが使用されたがっている流れイドをRPに送るかもしれません。 RP-レジスタメッセージにこれを含むことができました。 RPは次に、aのすべての受信機へのその流れイドのマルチキャストの特別なパケットをそうすることができました。 切り替わるという受信機願望であるときに、それらはその流れイドを使用します。
This needs the definition of the "special" packet.
これは「特別な」パケットの定義を必要とします。
3. The flow-id is handed out only by the source (for source-based trees) or the RP (for shared trees). The receivers use a "dummy" flow-id in the NMFReq when doing a Tree-Join. The correct flow-id to be used is returned in the NMFRep message generated by the forwarding agent where the new branch meets the existing tree. Forwarding agents in the path of the NMFRep packet update the state information by rewriting the dummy flow-id by the correct flow-id contained in the NMFRep packet.
3. 流れイドは単にソース(ソースベースの木のための)かRP(共有された木のための)によって与えられます。 aをするとき、受信機はNMFReqの「ダミー」の流れイドを使用します。Tree接合しています。 新しいブランチが既存の木に触れるところで小口運送業者によって発生したNMFRepメッセージで使用されるべき正しい流れイドを返します。 NMFRepパケットの経路の小口運送業者は、NMFRepパケットに含まれた正しい流れイドでダミーの流れイドを書き直すことによって、州の情報をアップデートします。
This requires the re-definition of the NMFRep packet. Note that now there must be space for two flow-ids in the NMFRep packet - one for the "dummy" flow-id and the other for the "correct" flow-id that must replace the dummy flow-id.
これはNMFRepパケットの再定義を必要とします。 2つの流れイドのためのスペースが現在NMFRepパケットにあるに違いないことに注意してください--「ダミー」の流れイドのための1つとダミーの流れイドを置き換えなければならない「正しい」流れイドのためのもう片方。
We claim that each of the above schemes achieves synchronization in the flow-id in various parts of the internetwork and that each flow- id is unique to the multicast delivery tree. A formal proof of these claims is beyond the scope of this document.
私たちはそれぞれの上の計画がインターネットワークの様々な部分の流れイドにおける同期を実現して、それぞれの流れイドがマルチキャスト配送木にユニークであると主張します。 これらのクレームの正式な証拠はこのドキュメントの範囲を超えています。
Ramanathan Informational [Page 20] RFC 2102 Nimrod Multicast Support February 1997
[20ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
Dense Mode Multicast: The PIM architecture [DEF+94a] includes a multicast protocol when the group membership is densely distributed within the internetwork. In this mode, no Rendezvous Points are used and a source rooted tree is formed based on Reverse Path Forwarding in a manner similar to that of DVMRP [DC90].
濃いモードマルチキャスト: グループ会員資格がインターネットワークの中で密に分配されるとき、PIM構造[DEF+94a]はマルチキャストプロトコルを含んでいます。 このモードで、どんなRendezvous Pointsも使用されていません、そして、ソース根づいている木はDVMRP[DC90]のものと同様の方法によるReverse Path Forwardingに基づいて形成されます。
We do not give details of how Nimrod can implement Dense Mode Multicast here.
私たちはニムロデがここでどうDense Mode Multicastを実行できるかに関する詳細を述べません。
Multiple RPs: Our discussion above has been based on the assumption that there is one RP per group. PIM allows more than one RP per group. We do not discuss multiple-RP PIM here.
倍数RPs: 私たちの上の議論は1グループあたり1RPがあるという仮定に基づきました。 PIMは1グループあたり1RPを許容します。 私たちはここで複数のRP PIMについて議論しません。
6 Security Considerations
6 セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
7 Summary
7概要
o Nimrod does not specify a particular multicast route generation algorithm or state creation procedure. Nimrod can accommodate diverse multicast techniques and leaves the choice of the technique to the particular instantiation of Nimrod.
o ニムロデは特定のマルチキャストルート世代アルゴリズムか州の創造手順を指定しません。 ニムロデは、ニムロデの特定の具体化にさまざまのマルチキャストのテクニックに対応できて、テクニックの選択を残します。
o A solution for multicasting within Nimrod should be capable of:
o ニムロデの中のマルチキャスティングの解決策はそうすることができるべきです:。
- Scaling to large networks, large numbers of multicast groups and
large multicast groups.
- マルチキャストグループと多くの大きいマルチキャストグループに比例します。
- Supporting policy, including quality of service and access
restrictions.
- サービスの質とアクセス制限を含む方針を支持します。
- Resource sharing.
- リソース・シェアリング。
- Interoperability with other solutions.
- 他の解決策がある相互運用性。
o Multicasting typically requires the setting up of state in intermediate routers for packet forwarding. The state setup may be initiated by the sender (e.g., IDPR), by the receiver (e.g., CBT), by both (e.g., PIM) or by neither. The architecture of Nimrod provides sufficient flexibility to accommodate any of these approaches.
o マルチキャスティングはパケット推進において、中間的ルータに状態が候補になっている設定を通常必要とします。 州のセットアップは送付者(例えば、IDPR)、受信機(例えば、CBT)、(例えば、PIM)かどちらも両方によって着手されるかもしれません。 ニムロデの構造はこれらのアプローチのどれかを収容できるくらいの柔軟性を提供します。
o A receiver-initiated multicast protocol, PIM, is being designed by the IDMR working group of the IETF. The facilities provided by Nimrod make the use of PIM as a multicast protocol quite straightforward.
o 受信機で開始しているマルチキャストプロトコル(PIM)はIETFのIDMRワーキンググループによって設計されています。 ニムロデによって提供された施設で、マルチキャストプロトコルとしてのPIMの使用はかなり簡単になります。
Ramanathan Informational [Page 21] RFC 2102 Nimrod Multicast Support February 1997
[21ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
8 References
8つの参照箇所
[BFC93] A. J. Ballardie, P. F. Francis, and J. Crowcroft. Core based
trees. In Proceedings of ACM SIGCOMM, 1993.
[BFC93]A.J.Ballardie、P.F.フランシス、およびJ.クロウクロフト。 コアは木を基礎づけました。 ACM SIGCOMM、1993年の議事で。
[CCS96] Castineyra, I., Chiappa, N., and M. Steenstrup, "The Nimrod
Routing Architecture", RFC 1992, August 1996.
1996年8月の[CCS96]CastineyraとI.とChiappa、N.とM.ステーンストルプ、「ニムロデルート設定構造」RFC1992。
[DC90] S. Deering and D. Cheriton. Multicast routing in datagram
internetworks and extended lans. ACM Transactions on Computer
Systems, pages 85--111, May 1990.
[DC90] S.デアリングとD.Cheriton。 データグラムインターネットワークと拡張lansでのマルチキャストルーティング。 1990年5月のコンピュータシステムズ、85--111ページのACM Transactions。
[DEF+94a] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Liu,
C., and L. Wei, "Protocol Independent Multicast (PIM) :
Motivation and Architecture, Work in Progress.
[クールな+94a] デアリング、S.、Estrin、D.、ファリナッチ、D.、ジェーコブソン、V.、リュウ、C.、およびL.ウェイ、「独立しているマルチキャスト(PIM)について議定書の中で述べてください」 進行中の動機と構造、仕事。
[DEF+94b] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Liu,
C., and L. Wei, "Protocol Independent Multicast (PIM) :
Sparse Mode Protocol Specification, Work in Progress.
[クールな+94b] デアリング、S.、Estrin、D.、ファリナッチ、D.、ジェーコブソン、V.、リュウ、C.、およびL.ウェイ、「独立しているマルチキャスト(PIM)について議定書の中で述べてください」 まばらなモードプロトコル仕様、処理中の作業。
[DEFJ93] Deering, S., Estrin, D., Farinacci, D., and V. Jacobson,
"IGMP router extensions for routing to sparse multicast
groups, Work in Progress.
[DEFJ93] デアリング、S.、Estrin、D.、ファリナッチ、D.、およびV.ジェーコブソン、「まばらなマルチキャストグループ、ProgressのWorkへのルーティングのためのIGMPルータ拡張子。」
[DM78] Y. K. Dalal and R. M. Metcalfe. Reverse path forwarding of
broadcast packets. Communications of the ACM, 21(12), pages
1040--1048, 1978.
[DM78]Y.K.DalalとR.M.メトカルフェ。 放送パケットの経路推進を逆にしてください。 1040--1048ページ、1978 21(12)、年のACM、コミュニケーション。
[Moy92] Moy, J., "Multicast Extensions to OSPF, RFC 1584, March 1994.
[Moy92] Moy、J.、「OSPF、RFC1584、1994年3月までのマルチキャスト拡大。」
[RS96] Ramanathan, S., and M. Steenstrup, "Nimrod functional and
protocol specifications, Work in Progress.
[RS96] Ramanathan、S.とM.ステーンストルプ、「ニムロデ機能的、そして、プロトコル仕様、ProgressのWork。」
[Ste] Steenstrup, M., "Inter-domain policy routing protocol
specification: Version 2", Work in Progress.
[Ste]ステーンストルプ、M.、「相互ドメイン方針ルーティングは仕様を議定書の中で述べます」。 バージョン2インチ、進行中で働いてください。
Ramanathan Informational [Page 22] RFC 2102 Nimrod Multicast Support February 1997
[22ページ]RFC2102ニムロデマルチキャストサポート1997年2月の情報のRamanathan
9 Acknowledgements
9つの承認
We thank Isidro Castineyra (BBN), Charles Lynn (BBN), Martha Steenstrup (BBN) and other members of the Nimrod Working Group for their comments and suggestions on this memo.
私たちはこのメモの上で彼らのコメントと提案についてイシドロCastineyra(BBN)、チャールズリン(BBN)、マーサ・ステーンストルプ(BBN)、およびニムロデ作業部会の他のメンバーに感謝します。
10 Author's Address
10作者のアドレス
Ram Ramanathan BBN Systems and Technologies 10 Moulton Street Cambridge, MA 02138
牡羊座Ramanathan BBN系と技術10モールトン・通りケンブリッジ、MA 02138
Phone: (617) 873-2736 EMail: ramanath@bbn.com
以下に電話をしてください。 (617) 873-2736 メールしてください: ramanath@bbn.com
Ramanathan Informational [Page 23]
Ramanathan情報です。[23ページ]
一覧
スポンサーリンク
