RFC5058 日本語訳
5058 Explicit Multicast (Xcast) Concepts and Options. R. Boivie, N.Feldman, Y. Imai, W. Livens, D. Ooms. November 2007. (Format: TXT=80072 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Boivie
Request for Comments: 5058 N. Feldman
Category: Experimental IBM
Y. Imai
WIDE / Fujitsu
W. Livens
ESCAUX
D. Ooms
OneSparrow
November 2007
Boivieがコメントのために要求するワーキンググループR.をネットワークでつないでください: 5058年のN.フェルドマンカテゴリ: 富士通W.がESCAUX D.オームスOneSparrow2007年11月に賑す実験的なIBM Y.イマイ広い/
Explicit Multicast (Xcast) Concepts and Options
明白なマルチキャスト(Xcast)概念とオプション
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは配備されたプロトコルとのセキュリティのようなもの、輻輳制御、または不適当な相互作用のために、どんな目的のためのこのRFCのフィットネスに関するどんな知識と発行するという決定がIETFレビューに基づいていないという特に注も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 このドキュメントの読者は実現と展開のために値を評価する際に警戒するべきです。 詳しい情報に関してRFC3932を見てください。
Abstract
要約
While traditional IP multicast schemes (RFC 1112) are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describes Xcast (Explicit Multi-unicast), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address.
非常に大きいマルチキャストグループに、伝統的なIPマルチキャスト計画(RFC1112)がスケーラブルである間、それらには、非常に多くの異なったマルチキャストグループのスケーラビリティ問題があります。 このドキュメントは補足的なスケーリング特性でXcast(明白なMulti-ユニキャスト)、新しいマルチキャスト計画について説明します: Xcastは非常に多くの小さいマルチキャストセッションを支持します。 Xcastはデータ・パケットで明らかに目的地のリストをコード化することによって、これを達成します、マルチキャストグループアドレスを使用することの代わりに。
This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification.
このドキュメントはいくつかの領域でXcast概念とオプションについて議論します。 それは完全な技術仕様書を提供しません。
Boivie, et al. Experimental [Page 1] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[1ページ]RFC5058Xcast概念とオプション2007年11月
Table of Contents
目次
1. Introduction ....................................................3
2. Xcast Overview ..................................................4
3. The Cost of the Traditional IP Multicast Schemes ................6
4. Motivation ......................................................9
5. Application ....................................................11
6. Xcast Flexibility ..............................................12
7. Xcast Control Plane Options ....................................13
7.1. SIP Control Plane for Xcast ...............................14
7.2. Receiver-Initiated Join for Xcast .........................14
8. Optional Information ...........................................15
8.1. List of Ports .............................................15
8.2. List of DSCPs .............................................15
8.3. Channel Identifier ........................................15
9. Possible Xcast Packet Encoding .................................16
9.1. General ...................................................16
9.2. IPv4 ......................................................17
9.2.1. IPv4 Header ........................................17
9.2.2. Xcast4 Header ......................................17
9.3. IPv6 ......................................................20
9.3.1. IPv6 Header ........................................20
9.3.2. Xcast6 Header ......................................20
9.3.2.1. Routing Extension Header ..................21
9.3.2.2. Destination Extension Header ..............21
10. Impact on Upper-Layer Protocols ...............................22
10.1. Checksum Calculation in Transport-Layer Headers ..........22
10.2. IPsec ....................................................22
11. Gradual Deployment ............................................23
11.1. Tunneling ................................................23
11.2. Premature X2U ............................................25
11.3. Semi-Permeable Tunneling (IPv6 Only) .....................25
11.4. Special Case: Deployment without Network Support .........26
11.5. Using a Small Number of Xcast-Aware Routers to
Provide Xcast ............................................27
12. (Socket) API ..................................................28
13. Unresolved Issues .............................................28
13.1. The Format of the "List of Addresses" ....................28
13.2. The size of Channel Identifier ...........................28
13.3. Incremental Deployment ...................................28
13.4. DSCP usage ...............................................29
13.5. Traversing a Firewall or NAT Products ....................29
13.6. The Size of BITMAP .......................................29
14. Security Considerations .......................................29
15. IANA Considerations ...........................................30
16. Informative References ........................................31
17. Contributors ..................................................33
1. 序論…3 2. Xcast概観…4 3. 伝統的なIPマルチキャスト計画の費用…6 4. 動機…9 5. アプリケーション…11 6. Xcastの柔軟性…12 7. Xcastは飛行機オプションを制御します…13 7.1. Xcastのために制御飛行機をちびちび飲んでください…14 7.2. 受信機で開始される、Xcastには、接合してください…14 8. 任意の情報…15 8.1. ポートのリスト…15 8.2. DSCPsのリスト…15 8.3. チャンネル識別子…15 9. 可能なXcastパケットコード化…16 9.1. 一般…16 9.2. IPv4…17 9.2.1. IPv4ヘッダー…17 9.2.2. Xcast4ヘッダー…17 9.3. IPv6…20 9.3.1. IPv6ヘッダー…20 9.3.2. Xcast6ヘッダー…20 9.3.2.1. ルート設定拡張ヘッダー…21 9.3.2.2. 目的地拡張ヘッダー…21 10. 上側の層のプロトコルで影響を与えてください…22 10.1. トランスポート層ヘッダーのチェックサム計算…22 10.2. IPsec…22 11. ゆるやかな展開…23 11.1. トンネリング…23 11.2. 時期尚早なX2U…25 11.3. 準透過性のトンネリング(IPv6専用)…25 11.4. 特別なケース: ネットワークサポートのない展開…26 11.5. Xcastを提供するのに少ない数のXcast意識しているルータを使用します…27 12. (ソケット) API…28 13. 未定の問題…28 13.1. 「住所録」の形式…28 13.2. Channel Identifierのサイズ…28 13.3. 増加の展開…28 13.4. DSCP用法…29 13.5. ファイアウォールかNAT製品を横断します…29 13.6. ビットマップのサイズ…29 14. セキュリティ問題…29 15. IANA問題…30 16. 有益な参照…31 17. 貢献者…33
Boivie, et al. Experimental [Page 2] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[2ページ]RFC5058Xcast概念とオプション2007年11月
1. Introduction
1. 序論
While traditional IP multicast schemes [1112] are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describes Xcast (Explicit Multi-unicast (Xcast)), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address. This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification.
非常に大きいマルチキャストグループに、伝統的なIPマルチキャスト計画[1112]がスケーラブルである間、それらには、非常に多くの異なったマルチキャストグループのスケーラビリティ問題があります。 このドキュメントは補足的なスケーリング特性でXcast(明白なMulti-ユニキャスト(Xcast))、新しいマルチキャスト計画について説明します: Xcastは非常に多くの小さいマルチキャストセッションを支持します。 Xcastはデータ・パケットで明らかに目的地のリストをコード化することによって、これを達成します、マルチキャストグループアドレスを使用することの代わりに。 このドキュメントはいくつかの領域でXcast概念とオプションについて議論します。 それは完全な技術仕様書を提供しません。
Multicast, the ability to efficiently send data to a group of destinations, is becoming increasingly important for applications such as IP telephony and video-conferencing.
マルチキャスト(効率的に目的地のグループにデータを送る能力)はますますIP電話技術やビデオ会議などのアプリケーションには重要になっています。
Two kinds of multicast seem to be important: a broadcast-like multicast that sends data to a very large number of destinations, and a "narrowcast" multicast that sends data to a fairly small group [BOIV]. An example of the first is the audio and video multicasting of a presentation to all employees in a corporate intranet. An example of the second is a videoconference involving three or four parties. For reasons described below, it seems prudent to use different mechanisms for these two cases. As the Reliable Multicast Transport working group has stated: "it is believed that a 'one size fits all' protocol will be unable to meet the requirements of all applications" [RMT]. Note that the 1998 IAB Routing Workshop [2902] came to the same conclusion: "For example, providing for many groups of small conferences (a small number of widely dispersed people) with global topological scope scales badly given the current multicast model".
2種類のマルチキャストは重要であるように思えます: 非常に多くの目的地にデータを送る放送のようなマルチキャスト、およびかなり小さいグループ[BOIV]にデータを送る「ナローキャスト」マルチキャスト。 1つの番目ものに関する例は、企業イントラネットにおける全社員へのプレゼンテーションのオーディオとビデオマルチキャスティングです。 2番目に関する例は3か4回のパーティーにかかわるビデオ会議です。 以下で説明された理由で、これらの2つのケースに異なったメカニズムを使用するのは慎重に思えます。 Reliable Multicast Transportワーキンググループが述べたように: 「'フリーサイズ'プロトコルがすべてのアプリケーションに関する必要条件を満たすことができないと信じられている」[RMT]。 1998IABルート設定Workshop[2902]が同じ結論に来たことに注意してください: 「例えば、現在のマルチキャストモデルを考えて、グローバルな位相的な範囲で小さい会議の多くのグループ(少ない数の広く分散している人々)に備えるのはひどく比例します。」
Today's multicast schemes can be used to minimize bandwidth consumption. Explicit Multi-Unicast (Xcast) also can be used to minimize bandwidth consumption for "small groups". But it has an additional advantage as well. Xcast eliminates the per-session signaling and per-session state information of traditional IP multicast schemes and this allows Xcast to support very large numbers of multicast sessions. This scalability is important since it enables important classes of applications such as IP telephony, videoconferencing, collaborative applications, networked games, etc., where there are typically very large numbers of small multicast groups.
帯域幅消費を最小にするのに今日のマルチキャスト計画を使用できます。 「小集団」のために帯域幅消費を最小にするのに明白なMulti-ユニキャスト(Xcast)も使用できます。 しかし、それには、また、追加利点があります。 Xcastは伝統的なIPマルチキャスト計画の1セッションあたりのシグナリングと1セッションあたりの州の情報を排除します、そして、これはXcastが非常に多くのマルチキャストセッションを支持するのを許容します。 重要なクラスのIP電話技術、テレビ会議、協力的なアプリケーション、ネットワークでつながれたゲームなどのアプリケーション(通常非常に多くの小さいマルチキャストグループがある)を可能にするので、このスケーラビリティは重要です。
Interestingly, the idea for Xcast has been around for some time, although this was not immediately known to the three groups that independently re-invented it in the late 1990's. In fact the very
おもしろく、Xcastのための考えがしばらく周囲にあります、これはすぐに、1990年代後半に独自にそれを再発明した3つのグループにおいて知られていませんでしたが。 事実上、まさしくその
Boivie, et al. Experimental [Page 3] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[3ページ]RFC5058Xcast概念とオプション2007年11月
first proposal of the multicast concept in the Internet community, by Lorenzo Aguilar in his 1984 SIGCOMM paper [AGUI] proposed the use of an explicit list of destinations discussed in more detail below. At about the same time, David Cheriton and Stephen Deering developed Host Group Multicast in 1985 [CHER].
まず最初に、インターネットコミュニティでのマルチキャスト概念の提案、彼の1984SIGCOMMのロレンツォ・アギラルのそばでは、論文[阿久比]はさらに詳細に以下で議論した目的地の明白なリストの使用を提案しました。 ほぼ同じ頃、デヴィッドCheritonとスティーブン・デアリングは1985年[シェール]にHost Group Multicastを開発しました。
The Internet community compared the two proposals and concluded that a single mechanism was preferable to multiple mechanisms. Further, since Aguilar's proposal seemed to have serious scaling problems, the Host Group model was adopted.
インターネットコミュニティは、2つの提案を比較して、ただ一つのメカニズムが複数のメカニズムより望ましいと結論を下しました。アギラルの提案が重大なスケーリング問題を持っているように思えたので、さらに、Host Groupモデルは採用されました。
However, for reasons described below, we believe it makes sense to use different mechanisms for the two different kinds of multicast discussed above. While Host Group multicast may have been sufficient in the Internet of 1985, we believe that Xcast can be an important complement to Host Group multicast in the Internet of the 21st century.
しかしながら、以下で説明された理由で、私たちは、それが上で議論した2つの異種のマルチキャストのための異なったメカニズムを使用に理解できると信じています。 Host Groupマルチキャストが1985年のインターネットで十分であったかもしれない間、私たちは、Xcastが重要であって、21世紀のインターネットのHost Groupマルチキャストに理想的である場合があると信じています。
2. Xcast Overview
2. Xcast概観
In this document, the following terminology will be used:
本書では、以下の用語は使用されるでしょう:
- Session: in Xcast, the term 'multicast session' will be used
instead of 'multicast group' to avoid the strong association of
multicast groups with multicast group addresses in traditional IP
multicast.
- セッション: Xcastでは、'マルチキャストセッション'という用語は、'マルチキャストグループ'の代わりに伝統的なIPマルチキャストにおけるマルチキャストグループアドレスでマルチキャストグループの強い協会を避けるのに使用されるでしょう。
- Channel: in a session with multiple senders (e.g., a video
conference), the flow sourced by one sender will be called a
channel. So, a session can contain one or more channels.
- 以下を精神を集中させてください。 複数の送付者(例えば、テレビ会議システム)とのセッションのときに、1人の送付者によって出典を明示された流れはチャンネルと呼ばれるでしょう。 それで、セッションは1個以上のチャンネルを含むことができます。
In the Host Group Model, the packet carries a multicast address as a logical identifier of all group members. In Xcast, the source node keeps track of the destinations in the multicast channel that it wants to send packets to.
Host Group Modelでは、パケットはすべてのグループのメンバーの論理的な識別子としてマルチキャストアドレスを運びます。 Xcastでは、ソースノードはそれがパケットを送りたがっているマルチキャストチャンネルで目的地の動向をおさえます。
The source encodes the list of destinations in the Xcast header, and then sends the packet to a router. Each router along the way parses the header, partitions the destinations based on each destination's next hop, and forwards a packet with an appropriate Xcast header to each of the next hops.
ソースは、Xcastヘッダーで目的地のリストをコード化して、次に、パケットをルータに送ります。 道に沿った各ルータは、ヘッダーを分析して、各目的地の次のホップに基づく目的地を仕切って、適切なXcastヘッダーと共にそれぞれの次のホップにパケットを送ります。
When there is only one destination left, the Xcast packet can be converted into a normal unicast packet, which can be unicasted along the remainder of the route. This is called X2U (Xcast to Unicast).
1つの目的地だけが残っているとき、正常なユニキャストパケットにXcastパケットを変換できます。(ルートの残りに沿ってそれをunicastedすることができます)。 これはX2U(UnicastへのXcast)と呼ばれます。
For example, suppose that A is trying to get packets distributed to B, C, and D in Figure 1 below:
例えば、Aで以下の図1のB、C、およびDにパケットを分配しようとしていると仮定してください:
Boivie, et al. Experimental [Page 4] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[4ページ]RFC5058Xcast概念とオプション2007年11月
R4 ---- B
/
/
A----- R1 ---- R2 ---- R3 R8 ---- C
\ /
\ /
R5 ---- R6 ---- R7
\
\
R9 ---- D
R4---- B//A----- R1---- R2---- R3 R8---- C\/\/R5---- R6---- R7\\R9---- D
Figure 1
図1
This is accomplished as follows: A sends an Xcast packet with the list of destinations in its Xcast header to the first router, R1.
これは以下の通り達成されます: R1、目的地のリストがXcastヘッダーにある状態で、AはXcastパケットを最初のルータに送ります。
Since the Xcast header will be slightly different for IPv4 and IPv6 [2460], we won't reveal any details on the encoding of the Xcast header in this section (see Section 9). So, ignoring the details, the packet that A sends to R1 looks like this:
XcastヘッダーがIPv4とIPv6[2460]においてわずかに異なるようになるので、私たちはこのセクションでのXcastヘッダーのコード化に関する少しの詳細も明らかにするつもりではありません(セクション9を見てください)。 それで、詳細を無視して、AがR1に送るパケットはこれに似ています:
[ src = A | dest = B C D | payload ]
[srcはAと等しいです| B dest=C D| ペイロード]
When R1 receives this packet, it needs to properly process the Xcast header. The processing that a router does on receiving one of these Xcast packets is as follows:
R1がこのパケットを受けるとき、それは、適切にXcastヘッダーを処理する必要があります。 これらのXcastパケットの1つを受け取るときルータがする処理は以下の通りです:
- Perform a route table lookup to determine the next hop for each of
the destinations listed in the packet.
- ルートテーブルルックアップを実行して、パケットに記載されたそれぞれの目的地に次のホップを決定してください。
- Partition the set of destinations based on their next hops.
- それらの次のホップに基づく目的地のセットを仕切ってください。
- Replicate the packet so that there's one copy of the packet for
each of the next hops found in the previous steps.
- 前のステップで見つけられたそれぞれの次のホップのためのパケットのコピー1部があるように、パケットを模写してください。
- Modify the list of destinations in each of the copies so that the
list in the copy for a given next hop includes just the
destinations that ought to be routed through that next hop.
- 当然のことの次ホップのためのコピーのリストがまさしくそれが発送されるべきである次に跳ぶ目的地を含むように、それぞれのコピーの目的地のリストを変更してください。
- Send the modified copies of the packet on to the next hops.
- パケットの変更されたコピーを次のホップに送ってください。
- Optimization: If there is only one destination for a particular
next hop, the packet can be sent as a standard unicast packet to
the destination (X2U).
- 最適化: 次の特定のホップのための1つの目的地しかなければ、標準のユニキャストパケットとして目的地(X2U)にパケットを送ることができます。
So, in the example above, R1 will send a single packet on to R2 with a destination list of < B C D >, and R2 will send a single packet to R3 with the same destination list.
それで、上では、例では、R1が<B C D>の目的地リストがあるR2に単一のパケットを送るでしょう、そして、R2が同じ目的地リストがあるR3に単一のパケットを送るでしょう。
Boivie, et al. Experimental [Page 5] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[5ページ]RFC5058Xcast概念とオプション2007年11月
When R3 receives the packet, it will, by the algorithm above, send one copy of the packet to next hop R5 with an Xcast list of < C D >, and one ordinary unicast packet addressed to < B > to R4. R4 will receive a standard unicast packet and forward it on to < B >. R5 will forward the Xcast packet that it receives on to R6, which will pass it on to R7. When the packet reaches R7, R7 will transmit ordinary unicast packets addressed to < C > and < D >, respectively. R8 and R9 will receive standard unicast packets, and forward the packets on to < C > and < D >, respectively.
R3がパケットを受けるとき、上のアルゴリズムで、それは<C D>のXcastリスト、およびR4への<B>に記述された1つの普通のユニキャストパケットと共にパケットのコピー1部を次のホップR5に送るでしょう。 R4は標準のユニキャストパケットを受けて、<B>にそれを送るでしょう。R5はそれがR6に受けるXcastパケットを送るでしょう。R6はそれをR7に通過するでしょう。 パケットがR7に達すると、R7はそれぞれ<C>と<D>に記述された普通のユニキャストパケットを伝えるでしょう。 R8とR9はそれぞれ<C>と<D>に標準のユニキャストパケットを受けて、パケットを送るでしょう。
It's important that the Xcast packet that is sent to a given next hop only includes destinations for which that next hop is the next hop listed in the route table. If the list of destinations in the packet sent to R4, for example, had also included C and D, R4 would send duplicate packets.
次のホップを考えて、aに送られるXcastパケットが次のホップが次のホップであることがルートテーブルに記載した目的地を含んでいるだけであるのは、重要です。 また、例えばR4に送られたパケットの目的地のリストがCとDを含んでいたなら、R4は写しパケットを送るでしょう。
Note that when routing topology changes, the routing for an Xcast channel will automatically adapt to the new topology since the path an Xcast packet takes to a given destination always follows the ordinary, unicast routing for that destination.
トポロジー変化を発送するとき、Xcastパケットが与えられた目的地に取る経路がいつもその目的地への普通のユニキャストルーティングに従うので、Xcastチャンネルのためのルーティングが自動的に新しいトポロジーに順応することに注意してください。
3. The Cost of the Traditional IP Multicast Schemes
3. 伝統的なIPマルチキャスト計画の費用
Traditional IP multicast schemes [DEER, DEE2, FARI] were designed to handle very large multicast groups. These work well if one is trying to distribute broadcast-like channels all around the world but they have scalability problems when there is a very large number of groups.
伝統的なIPマルチキャスト計画[DEER、DEE2、FARI]は、非常に大きいマルチキャストグループを扱うように設計されました。 ものが世界中の放送のようなチャンネルを分配しようとしているなら、これらはうまくいきますが、彼らには、非常に多くのグループがあるとき、スケーラビリティ問題があります。
The characteristics of the traditional IP multicast model are determined by its two components: the Host Group model [DEER] and a Multicast Routing Protocol. Both components make multicast very different from unicast.
伝統的なIPマルチキャストモデルの特性は2つのコンポーネントで決定します: Host Groupは[DEER]とMulticastルート設定プロトコルをモデル化します。 両方のコンポーネントで、マルチキャストはユニキャストと非常に異なるようになります。
In the Host Group model, a group of hosts is identified by a multicast group address, which is used both for subscriptions and forwarding. This model has two main costs:
Host Groupモデルで、ホストのグループはマルチキャストグループアドレスによって特定されます。(それは、購読と推進に使用されます)。 このモデルには、2つの主なコストがあります:
- Multicast address allocation: The creator of a multicast group
must allocate a multicast address that is unique in its scope
(scope will often be global). This issue is being addressed by
the MALLOC working group, which is proposing a set of Multicast
Address Allocation Servers (MAAS) and three protocols (Multicast
Address Set Claim (MASC), Address Allocation Protocol (AAP),
Multicast Address Dynamic Client Allocation Protocol (MADCAP)).
- マルチキャストアドレス配分: マルチキャストグループの創造者は範囲でユニークなマルチキャストアドレスを割り当てなければなりません(範囲はしばしばグローバルになるでしょう)。 この問題は、MALLOCワーキンググループによって記述されて、3つのプロトコル(マルチキャストAddress Setは(MASC)を要求します、Address Allocationプロトコル(AAP)、Multicast Address Dynamic Client Allocationプロトコル(MADCAP))です。(ワーキンググループは、Multicast Address Allocation Servers(マース)の1セットを提案しています)。
Boivie, et al. Experimental [Page 6] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[6ページ]RFC5058Xcast概念とオプション2007年11月
- Destination unawareness: When a multicast packet arrives in a
router, the router can determine the next hops for the packet,
but knows nothing about the ultimate destinations of the packet,
nor about how many times the packet will be duplicated later on
in the network. This complicates the security, accounting and
policy functions.
- :目的地気づかなさ マルチキャストパケットがルータに到着して、ルータがパケットのために次のホップを決定できますが、パケットの最終仕向地に関して何も知らないときに時と後で、パケットが何回ネットワークでコピーされるかの周りに関して。 これはセキュリティ、会計、および方針機能を複雑にします。
In addition to the Host Group model, a routing algorithm is required to maintain the member state and the delivery tree. This can be done using a (truncated) broadcast algorithm or a multicast algorithm [DEER]. Since the former consumes too much bandwidth by unnecessarily forwarding packets to some routers, only the multicast algorithms are considered. These multicast routing protocols have the following costs:
Host Groupモデルに加えて、ルーティング・アルゴリズムが、加盟国と配送木を維持するのに必要です。 これは(端が欠ける)の放送アルゴリズムかマルチキャストアルゴリズム[DEER]を使用し終わることができます。 前者が不必要にいくつかのルータにパケットを送ることによってあまりに多くの帯域幅を消費するので、マルチキャストアルゴリズムだけが考えられます。 これらのマルチキャストルーティング・プロトコルには、以下のコストがあります:
- Connection state: The multicast routing protocols exchange
messages that create state for each (source, multicast group) in
all the routers that are part of the point-to-multipoint tree.
This can be viewed as "per flow" signaling that creates
multicast connection state, possibly yielding huge multicast
forwarding tables. Some of these schemes even disseminate this
multicast routing information to places where it isn't
necessarily needed [1075]. Other schemes try to limit the
amount of multicast routing information that needs to be
disseminated, processed, and stored throughout the network.
These schemes (e.g., [2201]) use a "shared distribution tree"
that is shared by all the members of a multicast group and they
try to limit the distribution of multicast routing information
to just those nodes that "really need it". But these schemes
also have problems. Because of the shared tree, they use less
than optimal paths in routing packets to their destinations and
they tend to concentrate traffic in small portions of a network.
And these schemes still involve lots of "per flow" signaling and
"per flow" state.
- 接続州: マルチキャストルーティング・プロトコルはそれぞれ(ソース、マルチキャストグループ)のためにポイントツーマルチポイント木の一部であるすべてのルータで状態を創設するメッセージを交換します。 ことによると巨大なマルチキャスト推進テーブルをもたらして、それに合図する「流れ」がマルチキャスト接続状態を創設するとき、これを見ることができます。 これらの計画のいくつかがそれが必ず必要であるというわけではない場所[1075]にこのマルチキャストルーティング情報を広めさえします。 他の計画はネットワーク中に広められて、処理されて、格納される必要があるマルチキャストルーティング情報の量を制限しようとします。 これらの計画(例えば、[2201])はマルチキャストグループのすべてのメンバーによって共有される「共有された分配木」を使用します、そして、彼らはマルチキャストルーティング情報の分配をまさしく「本当にそれを必要とである」それらのノードに制限しようとします。 しかし、また、これらの計画には、問題があります。共有された木のために、ルーティングパケットの最適経路以下を自己の目的地に使用します、そして、それらは少しずつネットワークの交通を集結する傾向があります。 そして、これらの計画はまだシグナリングと「流れ」が述べる多くの「流れ」にかかわっています。
- Source advertisement mechanism: Multicast routing protocols
provide a mechanism by which members get 'connected' to the
sources for a certain group without knowing the sources
themselves. In sparse-mode protocols [2201, DEE2], this is
achieved by having a core node, which needs to be advertised in
the complete domain. On the other hand, in dense-mode protocols
[1075] this is achieved by a "flood and prune" mechanism. Both
approaches raise additional scalability issues.
- ソース広告メカニズム: マルチキャストルーティング・プロトコルはメンバーが、あるグループのためにソース自体を知らないでソースに'接続されること'を得るメカニズムを提供します。 まばらなモードプロトコル[2201、DEE2]では、これは、コアノードを持っていることによって、達成されます。(ノードは完全なドメインに広告を出す必要があります)。 他方では、濃いモードプロトコル[1075]では、これは「洪水とプルーン」メカニズムによって達成されます。 両方のアプローチは追加スケーラビリティ問題を提起します。
- Inter-domain routing: Multicast routing protocols that rely on a
core node [2201, DEE2] additionally need an inter-domain
multicast routing protocol (e.g., [FARI]).
- 相互ドメインルーティング: さらに、コアノード[2201、DEE2]を当てにするマルチキャストルーティング・プロトコルが相互ドメインマルチキャストルーティング・プロトコル(例えば、[FARI])を必要とします。
Boivie, et al. Experimental [Page 7] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[7ページ]RFC5058Xcast概念とオプション2007年11月
The cost of multicast address allocation, destination unawareness and the above scalability issues lead to a search for other multicast schemes. Source-Specific Multicast (SSM) [4607] addresses some of the above drawbacks: in SSM, a host joins a specific source, thus the channel is identified by the couple (source address, multicast address). This approach avoids multicast address allocation as well as the need for an inter-domain routing protocol. The source advertisement is taken out of the multicast routing protocol and is moved to an out-of-band mechanism (e.g., web page).
マルチキャストアドレス配分の費用、目的地気づかなさ、および上のスケーラビリティ問題は他のマルチキャスト計画の検索につながります。 ソース特有のMulticast(SSM)[4607]は上の欠点のいくつかを記述します: SSMに、ホストは特定のソースに加わります、その結果、チャンネルがカップル(ソースアドレス、マルチキャストアドレス)によって特定されます。 このアプローチは相互ドメインルーティング・プロトコルの必要性と同様にマルチキャストアドレス配分を避けます。 ソース広告は、マルチキャストルーティング・プロトコルから取り出されて、バンドで出ているメカニズム(例えば、ウェブページ)に動かされます。
Note that SSM still creates state and signaling per multicast channel in each on-tree node. Figure 2 depicts the above costs as a function of the number of members in the session or channel. All the costs have a hyperbolic behavior.
SSMが木の上の各ノードにまだマルチキャストチャンネルあたりの状態とシグナリングを創設していることに注意してください。 図2はセッションかチャンネルによる会員数の関数として上のコストについて表現します。 すべてのコストには、大げさな振舞いがあります。
cost of the traditional
IP multicast model
per member
^
| costly| OK
| <-----|----->
| . |
| .. |
| ..|..
| | .........
| | ........
+--------------------------->
| number of members
v
alternative=Xcast
メンバー^あたりの伝統的なIPマルチキャストモデルの費用| 高価| OK| <、-、-、-、--、|、-、-、-、--、>| . | | .. | | ..|.. | | ......... | | ........ +--------------------------->| 会員数対代替手段=Xcast
Figure 2
図2
The traditional IP multicast model becomes expensive for its members if the groups are small. Small groups are typical for conferencing, gaming, and collaborative applications. These applications are well- served by Xcast.
グループが小さいなら、伝統的なIPマルチキャストモデルはメンバーにとって高価になります。 会議、ゲーミング、および協力的なアプリケーションに、小集団は典型的です。 これらのアプリケーションはXcastによってよく役立たれています。
In practice, traditional IP multicast routing protocols impose limitations on the number of groups and the size of the network in which they are deployed. For Xcast, these limitations do not exist.
実際には、伝統的なIPマルチキャストルーティング・プロトコルはそれらが配備されるグループの数とネットワークのサイズに制限を課します。 Xcastに関しては、これらの制限は存在していません。
Boivie, et al. Experimental [Page 8] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[8ページ]RFC5058Xcast概念とオプション2007年11月
4. Motivation
4. 動機
Xcast takes advantage of one of the fundamental tenets of the Internet "philosophy", namely, that one should move complexity to the edges of the network and keep the middle of the network simple. This is the principle that guided the design of IP and TCP and it's the principle that has made the incredible growth of the Internet possible. For example, one reason that the Internet has been able to scale so well is that the routers in the core of the network deal with large Classless Inter-Domain Routing (CIDR) blocks as opposed to individual hosts or individual "connections". The routers in the core don't need to keep track of the individual TCP connections that are passing through them. Similarly, the IETF's Diffserv effort is based on the idea that the routers shouldn't have to keep track of a large number of individual Resource Reservation Protocol (RSVP) flows that might be passing through them. It's the authors' belief that the routers in the core shouldn't have to keep track of a large number of individual multicast flows, either.
Xcastがインターネット「哲学」の基本的な主義の1つを利用して、すなわち、その複雑さをネットワークの縁に動かして、ネットワークの中央を簡単に保つべきです。 これはIPとTCPのデザインを誘導した原則です、そして、それはインターネットの信じられない成長を可能にした原則です。 例えば、インターネットがそれほどよく比例できた1つの理由はネットワークのコアのルータが個々のホストか個々の「接続」と対照的に大きいClassless Inter-ドメインルート設定(CIDR)ブロックに対処するということです。 コアのルータは彼らを通り抜けている個々のTCP接続の動向をおさえる必要はありません。 同様に、IETFのDiffservの努力はルータがそれらを通り抜けているかもしれない多くの個々のResource予約プロトコル(RSVP)流れの動向をおさえる必要はないはずであるという考えに基づいています。 コアのルータが多くの個々のマルチキャスト流れの動向をおさえる必要はないはずであるのは、作者の信念です。
Compared to traditional IP multicast, Xcast has the following advantages:
Xcastには、伝統的なIPマルチキャストと比べて、以下の利点があります:
1) Routers do not have to maintain state per session (or per channel)
[SOLA]. This makes Xcast very scalable in terms of the number of
sessions that can be supported since the nodes in the network do
not need to disseminate or store any multicast routing information
for these sessions.
1) ルータはセッション(またはチャンネル単位で)あたりの状態を維持する必要はありません。 [SOLA。] これで、Xcastはネットワークにおけるノードがこれらのセッションのためのどんなマルチキャストルーティング情報も広めるか、または格納する必要はないので支持できるセッションの数で非常にスケーラブルになります。
2) No multicast address allocation required.
2) どんなマルチキャストアドレス配分も必要ではありません。
3) No need for multicast routing protocols (neither intra- nor
inter-domain). Xcast packets always take the "right" path as
determined by the ordinary unicast routing protocols.
3) マルチキャストルーティング・プロトコル(どちらもイントラか相互ドメイン)の必要性がありません。 Xcastパケットは普通のユニキャストルーティング・プロトコルで決定するようにいつも「正しい」経路を取ります。
4) No core node, so no single point of failure. Unlike the shared
tree schemes, Xcast minimizes network latency and maximizes
network "efficiency".
4) コアノードでなく、したがって、どんなシングルも失敗を指しません。 共有された木の計画と異なって、Xcastはネットワーク潜在を最小にして、ネットワーク「効率」を最大にします。
5) Symmetric paths are not required. Traditional IP multicast
routing protocols create non-shortest-path trees if paths are not
symmetric. (A path between two nodes A and B is symmetric if the
path is both the shortest path from A to B as well as the shortest
path from B to A.) It is expected that an increasing number of
paths in the Internet will be asymmetric in the future as a result
of traffic engineering and policy routing, and thus the
traditional IP multicast schemes will result in an increasing
amount of suboptimal routing.
5) 左右対称の経路は必要ではありません。 経路が左右対称でないなら、伝統的なIPマルチキャストルーティング・プロトコルは非最短パス木を作成します。 (2つのノードAとBの間の経路は経路がAからBまでの最短パスとBからA.までの最短パスの両方であるなら左右対称です) インターネットの増加する数の経路が将来交通工学と方針ルーティングの結果、非対称になると予想されて、その結果、伝統的なIPマルチキャスト計画は増加する量の準最適のルーティングをもたらすでしょう。
Boivie, et al. Experimental [Page 9] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[9ページ]RFC5058Xcast概念とオプション2007年11月
6) Automatic reaction to unicast reroutes. Xcast will react
immediately to unicast route changes. In traditional IP multicast
routing protocols, a communication between the unicast and the
multicast routing protocol needs to be established. In many
implementations, this is on a polling basis, yielding a slower
reaction to, e.g., link failures. It may also take some time for
traditional IP multicast routing protocols to fix things up if
there is a large number of groups that need to be fixed.
6) ユニキャストへの自動反応はコースを変更します。 Xcastはすぐユニキャストルート変化に反応するでしょう。 伝統的なIPマルチキャストルーティング・プロトコルでは、ユニキャストとマルチキャストルーティング・プロトコルとのコミュニケーションは、設立される必要があります。 より遅い反応をもたらして、多くの実現これが世論調査ベースで中である、例えば、失敗をリンクしてください。 また、修理される必要がある多くのグループがあれば、それは便宜を図る伝統的なIPマルチキャストルーティング・プロトコルのためにある程度時間がかかるかもしれません。
7) Easy security and accounting. In contrast with the Host Group
Model, in Xcast all the sources know the members of the multicast
channel, which gives the sources the means to, e.g., reject
certain members or count the traffic going to certain members
quite easily. Not only a source, but also a border router is able
to determine how many times a packet will be duplicated in its
domain. It also becomes easier to restrict the number of senders
or the bandwidth per sender.
7) 簡単なセキュリティと会計。 Xcastのすべての情報筋が手段をソースに与えるマルチキャストチャンネルのメンバーを知っているHost Group Modelと比べて、例えば、確信しているメンバーを拒絶するか、または全く容易に確信しているメンバーのものになるトラフィックを数えてください。 ソースだけではなく、境界ルータも、パケットが何回ドメインにコピーされるかを決定できます。 また、送付者の数か1送付者あたりの帯域幅を制限するのは、より簡単になります。
8) Heterogeneous receivers. Besides the list of destinations, the
packet could (optionally) also contain a list of Diffserv Code
Points (DSCPs). While traditional IP multicast protocols have to
create separate groups for each service class, Xcast incorporates
the possibility of having receivers with different service
requirements within one multicast channel.
8) 異種の受信機。 また、目的地のリスト以外に、パケットは(任意に)Diffserv Code Points(DSCPs)のリストを含むかもしれません。 伝統的なIPマルチキャストプロトコルはそれぞれのサービスのクラスのために別々のグループを創設しなければなりませんが、Xcastは1個のマルチキャストチャンネルの中に異なったサービス要件で受信機を持っている可能性を取り入れます。
9) Xcast packets can make use of traffic-engineered unicast paths.
9) Xcastパケットはトラフィックで設計されたユニキャスト経路を利用できます。
10) Simple implementation of reliable protocols on top of Xcast,
because Xcast can easily address a subset of the original list of
destinations to do a retransmission.
10) Xcastが「再-トランスミッション」をするために容易に目的地のオリジナルのリストの部分集合を扱うことができるのでXcastの上の信頼できるプロトコルの簡単な実装。
11) Flexibility (see Section 6).
11) 柔軟性(セクション6を見ます)。
12) Easy transition mechanisms (see Section 11).
12) 簡単な変遷メカニズム(セクション11を見ます)。
It should be noted that Xcast has a number of disadvantages as well:
Xcastにはまた、多くの損失があることに注意されるべきです:
1) Overhead. Each packet contains all remaining destinations. But,
the total amount of data is still much less than for unicast
(payload is only sent once). A method to compress the list of
destination addresses might be useful.
1) オーバーヘッド。 各パケットはすべての残っている目的地を含んでいます。 しかし、データの総量はユニキャストよりはるかにそれほどまだ(一度ペイロードを送るだけである)です。 送付先アドレスのリストを圧縮するメソッドは役に立つかもしれません。
2) More complex header processing. Each destination in the packet
needs a routing table lookup. So, an Xcast packet with n
destinations requires the same number of routing table lookups as
n unicast headers. Additionally, a different header has to be
constructed per next hop. Note however that:
2) より複雑なヘッダー処理。 パケットの各目的地は経路指定テーブルルックアップを必要とします。 それで、n目的地があるXcastパケットはnユニキャストヘッダーと同じ数の経路指定テーブルルックアップを必要とします。 さらに、異なったヘッダーは次のホップ単位で組み立てられなければなりません。 しかしながら、以下のことに注意してください。
Boivie, et al. Experimental [Page 10] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[10ページ]RFC5058Xcast概念とオプション2007年11月
a) Since Xcast will typically be used for super-sparse sessions,
there will be a limited number of branching points, compared to
non-branching points. Only in a branching point do new headers
need to be constructed.
a) Xcastが超まばらなセッションに通常使用されるので、限られた数の分岐ポイントがあるでしょう、非分岐ポイントと比べて。 分岐ポイントだけでは、新しいヘッダーは、組み立てられる必要があります。
b) The header construction can be reduced to a very simple
operation: overwriting a bitmap.
b) 非常に簡単な操作にヘッダー工事を抑えることができます: ビットマップを上書きします。
c) Among the non-branching points, a lot of them will contain only
one destination. In these cases, normal unicast forwarding can
be applied.
c) 非分岐ポイントの中では、それらの多くが1つの目的地だけを含むでしょう。 これらの場合では、通常のユニキャスト推進を適用できます。
d) By using a hierarchical encoding of the list of destinations in
combination with the aggregation in the forwarding tables the
forwarding can be accelerated [OOMS].
d) 推進テーブルの集合と組み合わせて目的地のリストの階層符号化を使用することによって、推進を加速できます[オームス]。
e) When the packet enters a region of the network where link
bandwidth is not an issue anymore, the packet can be
transformed by a Premature X2U. Premature X2U (see Section
11.2) occurs when a router decides to transform the Xcast
packet for one or more destinations into unicast packets. This
avoids more complex processing downstream.
e) パケットがそれ以上リンク帯域幅が問題でないネットワークの領域に入るとき、Premature X2Uはパケットを変えることができます。 ルータが、Xcastパケットをユニキャストパケットへの1つ以上の目的地に変えると決めると、時期尚早なX2U(セクション11.2を見る)は起こります。 これは川下で、より複雑な処理を避けます。
f) Other mechanisms to reduce the processing have been described
in [IMAI] (tractable list) and [OOMS] (caching), but are not
(yet) part of the Xcast specification.
f) 処理を抑える他のメカニズムは、[イマイ](御しやすいリスト)と[オームス](キャッシュする)で説明されますが、(まだ、)Xcast仕様の一部ではありません。
3) Xcast only works with a limited number of receivers.
3) Xcastは限られた数の受信機で働いているだけです。
5. Application
5. アプリケーション
While Xcast is not suitable for multicast sessions with a large number of members, such as the broadcast of an IETF meeting, it does provide an important complement to existing multicast schemes in that it can support very large numbers of small sessions. Thus, Xcast enables important applications such as IP telephony, videoconferencing, multi-player games, collaborative e-meetings, etc. The number of these sessions will become huge.
Xcastがマルチキャストセッションに適していない間、IETFミーティングの放送などの多くのメンバーと共に、それは、非常に多くの小さいセッションをサポートすることができるので、既存のマルチキャスト体系に重要な補数を提供します。 したがって、XcastはIP電話技術、テレビ会議、マルチプレーヤーゲーム、協力的な電子ミーティングなどの重要なアプリケーションを可能にします。 これらのセッションの数は巨大になるでしょう。
Some may argue that it is not worthwhile to use multicast for sessions with a limited number of members, and that it's preferable to use unicast instead. But in certain cases, limited bandwidth in the "last mile" makes it important to have some form of multicast, as the following example illustrates. Assume n residential users set up a video conference. Typically, access technologies are asymmetric (e.g., xDSL, General Packet Radio Service (GPRS), or cable modem). So, a host with xDSL has no problem receiving n-1 basic 100 kb/s
或るものは限られた数のメンバーとのセッションにマルチキャストを使用する価値がなくて、代わりにユニキャストを使用するのが望ましいと主張するかもしれません。 しかし、ある場合には、「最後のマイル」における限られた帯域幅で何らかのフォームのマルチキャストを持っているのは重要になります、以下の例が例証するように。 n住宅のユーザがテレビ会議システムをセットアップすると仮定してください。 アクセス技術は通常、非対称です(例えば、xDSL、汎用パケット無線システム(GPRS)、またはケーブルモデム)。 それで、xDSLのホストには、n-1の基本的な100kb/sを受けることにおける問題が全くありません。
Boivie, et al. Experimental [Page 11] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[11ページ]RFC5058Xcast概念とオプション2007年11月
video channels, but the host is not able to send its own video data n-1 times at this rate. Because of the limited and often asymmetric access capacity, some type of multicast is mandatory.
ビデオは精神を集中しますが、ホストはこのままでいくとそれ自身のビデオ・データn-1回数を送ることができません。 制限されてしばしば非対称のアクセス容量のために、タイプのマルチキャストは義務的です。
A simple but important application of Xcast lies in bridging the access link. The host sends the Xcast packet with the list of unicast addresses and the first router performs a Premature X2U.
アクセスリンクをブリッジするのにおいてXcastの簡単な、しかし、重要なアプリケーションがあります。 ホストはユニキャストアドレスのリストがあるXcastパケットを送ります、そして、最初のルータはPremature X2Uを実行します。
Since Xcast is not suitable for large groups, Xcast will not replace the traditional IP multicast model, but it does offer an alternative for multipoint-to-multipoint communications when there can be very large numbers of small sessions.
Xcastが大きいグループに適していないので、Xcastは伝統的なIPマルチキャストモデルを置き換えないでしょうが、非常に多くの小さいセッションがあることができるとき、それは多点からマルチポイント通信のために代替手段を提供します。
6. Xcast Flexibility
6. Xcastの柔軟性
The main goal of multicast is to avoid duplicate information flowing over the same link. By using traditional IP multicast instead of unicast, bandwidth consumption decreases while the state and signaling per session increases. Xcast has a cost of 0 in these two dimensions, but it does introduce a third dimension corresponding to the header processing per packet. This three-dimensional space is depicted in Figure 3.
マルチキャストの第一目的は同じリンクの上に流れる写し情報を避けることになっています。 ユニキャストの代わりに伝統的なIPマルチキャストを使用することによって、1セッションあたりの状態とシグナリングは増加しますが、帯域幅消費は下がります。 Xcastには、これらのふたり寸法における、0の費用がありますが、それは1パケットあたりのヘッダー処理に対応する3番目の寸法を紹介します。 この立体は図3に表現されます。
state&signaling
per session
in router
^
|
|
....
B | ....
. | ....
. | ....
. | ....
. +------------------..---> processing
. / .... C per packet
. / ..... in router
. / .....
. / .....
./ .....
/A....
/
/
link bandwidth
ルータ^におけるセッションあたりの状態とシグナリング| | .... B| .... . | .... . | .... . | .... . +------------------..--->処理/…。 パケット/あたりのC… ルータ/で… . / ..... ./ ..... /A.… //リンク帯域幅
Figure 3
図3
Boivie, et al. Experimental [Page 12] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[12ページ]RFC5058Xcast概念とオプション2007年11月
One method of delivering identical information from a source to n destinations is to unicast the information n times (A in Figure 3). A second method, the traditional IP multicast model (B in Figure 3), sends the information only once to a multicast address. In Xcast, the information is sent only once, but the packet contains a list of destinations (point C).
ソースからn目的地まで同じ情報を提供するあるメソッドがn回(図3のA)ユニキャストへの情報です。 2番目のメソッド(伝統的なIPマルチキャストモデル(図3のB))は一度だけマルチキャストアドレスに情報を送ります。 Xcastでは、一度だけ情報を送りますが、パケットは目的地(ポイントC)のリストを含んでいます。
The three points A, B, and C define a plane (indicated with dots in Figure 3): a plane of conservation of misery. All three approaches have disadvantages. The link bandwidth is a scarce resource, especially in access networks. State&signaling/session encounters limitations when the number of sessions becomes large, and an increased processing/packet is cumbersome for high-link speeds.
3ポイントA、B、およびCは飛行機(ドットが図3にある状態で、示される)を定義します: 災いの保護の飛行機。 すべての3つのアプローチには、損失があります。 リンク帯域幅は特にアクセスネットワークで不十分なリソースです。 セッションの数が大きくなると、州とシグナリング/セッションは制限に遭遇します、そして、高リンク速度に、増強された処理/パケットは厄介です。
One advantage of Xcast is that it allows a router to move within this plane of conservation of misery based upon its location in a network. For example, in the core of the network, a cache could be used to move along the line from C to B without introducing any per-flow signaling. Another possibility, as suggested above, is to use premature X2U to move along the line from C to A in an access network if there is an abundance of bandwidth in the backbone.
Xcastの1つの利点はルータがネットワークで位置に基づく災いの保護のこの飛行機の中にそれで移行するということです。 例えば、ネットワークのコアでは、系列に沿ってCからBまでどんな1流れあたりのシグナリングも導入しないで移行するのにキャッシュを使用できました。 上に示される別の可能性はバックボーンにおける帯域幅が豊富でありあるなら系列に沿ってアクセスネットワークでCからAまで移行するのに時期尚早なX2Uを使用することです。
7. Xcast Control Plane Options
7. Xcast規制飛行機オプション
Unlike traditional IP multicast schemes, Xcast does not specify a "control plane". There is no Internet Group Management Protocol (IGMP [3376]), and as mentioned above, there are no intra- or inter- domain multicast routing protocols. With Xcast, the means by which multicast sessions are defined is an application-level issue and applications are not confined to the model in which hosts use IGMP to join a multicast session. For example:
伝統的なIPマルチキャスト体系と異なって、Xcastは「制御飛行機」を指定しません。 インターネットGroup Managementプロトコル(IGMP[3376])が全くありません、そして、以上のように、イントラか相互ドメインマルチキャストルーティング・プロトコルが全くありません。 Xcastにおいて、マルチキャストセッションが定義される手段はアプリケーションレベル発行です、そして、アプリケーションはホストがマルチキャストセッションに参加するのにIGMPを使用するモデルに閉じ込められません。 例えば:
- Some applications might want to use an IGMP-like receiver-join
model.
- いくつかのアプリケーションがIGMPのような受信機で接合しているモデルを使用したがっているかもしれません。
- Other applications might want to use a model in which a user places
a call to the party or parties that he or she wants to talk to
(similar to the way that one puts together a conference call today
using the buttons on one's telephone).
- 他のアプリケーションはユーザがその人が(1つが今日電話会議をまとめる人の電話の上でボタンを使用する方法と同様)と話したがっているパーティーかパーティーに電話するモデルを使用したがっているかもしれません。
- One might define a session based on the cells that are close to a
moving device in order to provide for a "smooth handoff" between
cells when the moving device crosses cell boundaries.
- 人は動くデバイスの近くに動くデバイスがセル境界に交差するとき、セルの間に「滑らかな移管」に備えるためにあるセルに基づくセッションを定義するかもしれません。
- In some applications, the members of the session might be specified
as arguments on a command line.
- 使用目的によっては、セッションのメンバーは議論としてコマンドラインで指定されるかもしれません。
Boivie, et al. Experimental [Page 13] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[13ページ]RFC5058Xcast概念とオプション2007年11月
- One might define an application that uses GPS to send video from a
bank robbery to the three police cars that are closest to the bank
being robbed.
- 人は銀行強盗事件から泥棒に入られる銀行の最も近くにある3台のパトカーにビデオを送るのにGPSを使用するアプリケーションを定義するかもしれません。
Thus, the application developer is not limited to the receiver- initiated joins of the IGMP model. There will be multiple ways in which an Xcast sender determines the addresses of the members of the channel.
したがって、受信機に開始されて、制限されなかったアプリケーション開発者はIGMPモデルで加わります。 Xcast送付者がチャンネルのメンバーのアドレスを決定する複数の方法があるでしょう。
For the purpose of establishing voice and multimedia conferences over IP networks, several control planes have already been defined, including SIP [3261] and H.323 [H323].
IPネットワークの上の声とマルチメディア会議を確立する目的のために、数機の制御飛行機が既に定義されました、SIP[3261]とH.323[H323]を含んでいて。
7.1. SIP Control Plane for Xcast
7.1. Xcastのための一口制御飛行機
In SIP, a host takes the initiative to set up a session. With the assistance of a SIP server, a session is created. The session state is kept in the hosts. Data delivery can be achieved by several mechanisms: meshed unicast, bridged, or multicast. Note that for the establishment of multicast delivery, a multicast protocol and communication with Multicast Address Allocation Servers (MAAS) are still required.
SIPでは、ホストはセッションをセットアップするイニシアチブを取ります。 SIPサーバの支援で、セッションは作成されます。 セッション状態はホストに維持されます。 数個のメカニズムはデータ配送を達成できます: ブリッジされたユニキャストかマルチキャストを網の目にかけました。 マルチキャスト配送の設立には、Multicast Address Allocation Servers(マース)とのマルチキャストプロトコルとコミュニケーションがまだ必要であることに注意してください。
In "meshed unicast" or "multi-unicasting", the application keeps track of the participants' unicast addresses and sends a unicast to each of those addresses. For reasons described in Section 3, multi- unicasting (rather than multicast) is the prevalent solution in use today. It's a simple matter to replace multi-unicast code with Xcast code. All that the developer has to do is replace a loop that sends a unicast to each of the participants by a single "xcast_send" that sends the data to the participants. Thus it's easy to incorporate Xcast into real conferencing applications.
「マルチunicasting「かみ合っているユニキャスト」か」では、アプリケーションは、関係者のユニキャストアドレスの動向をおさえて、それぞれのそれらのアドレスにユニキャストを送ります。 セクション3で説明された理由で、今日、マルチunicasting(マルチキャストよりむしろ)は使用中の一般的なソリューションです。 マルチユニキャストコードをXcastコードに取り替えるのは、簡単な事柄です。 開発者がしなければならないすべてはデータを関係者に送る単一の「_が送るxcast」で関係者各人にユニキャストを送る輪を置き換えることです。 したがって、実際の会議アプリケーションにXcastを組み入れるのは簡単です。
Both Xcast and SIP address super-sparse multicast sessions. It turns out that Xcast (a very flexible data plane mechanism) can be easily integrated with SIP (a very flexible control plane protocol). When an application decides to use Xcast forwarding it does not affect its interface to the SIP agent: it can use the same SIP messages as it would for multi-unicasting. SIP could be used with Xcast to support the conferencing model mentioned above in which a caller places a call to several parties.
XcastとSIPの両方が超まばらなマルチキャストセッションを扱います。 容易に、Xcast(非常にフレキシブルなデータ飛行機メカニズム)をSIP(非常にフレキシブルな規制飛行機プロトコル)と統合できると判明します。 アプリケーションが、Xcast推進を使用すると決める場合、SIPエージェントにインタフェースに影響しません: それはマルチunicastingに使用するように同じSIPメッセージを使用できます。 前記のように訪問者が数人のパーティーに電話する会議モデルをサポートするのにXcastと共にSIPを使用できました。
7.2. Receiver-Initiated Join for Xcast
7.2. 受信機で開始される、Xcastには、接合してください。
In the previous section, it was discussed how to establish an Xcast session among well known participants of a multi-party conference. In some cases, it is useful for participants to be able to join a session without being invited. For example, the chairman of a video
前項で、マルチパーティ会議の顔が広い関係者の中でどのようにXcastセッションを確立するか議論しました。 いくつかの場合、関係者が招待されないでセッションに参加できるのは、役に立ちます。 例えば、ビデオの議長
Boivie, et al. Experimental [Page 14] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[14ページ]RFC5058Xcast概念とオプション2007年11月
chat may want to leave the door of their meeting open for newcomers. The IGMP-like receiver-initiated join model mentioned above can be implemented by introducing a server that hosts can talk to, to join a conference.
チャットは彼らのミーティングのドアを新来者にとって開いているままにしたがっているかもしれません。 IGMPのようが受信機で開始した、会議に参加するために、ホストが話すことができるサーバを紹介することによって言及された上を実装することができるモデルに加わってください。
8. Optional Information
8. 任意情報
8.1. List of Ports
8.1. ポートのリスト
Although an extension to SIP could be arranged such that all participants in a session use the same transport (UDP) port number, in the general case, it is possible for each participant to listen on a different port number. To cover this case, the Xcast packet optionally contains a list of port numbers.
セッションのすべての関係者がSIPへの拡大をアレンジできたので、同じ輸送を使用しますが、(UDP)は数を移植します、一般的な場合で各関係者が異なったポートナンバーで聴くのは、可能です。 本件をカバーするために、Xcastパケットは任意にポートナンバーのリストを含んでいます。
If the list of port numbers is present, the destination port number in the transport-layer header will be set to zero. On X2U, the destination port number in the transport-layer header will be set to the port number corresponding to the destination of the unicast packet.
ポートナンバーのリストが存在していると、トランスポート層ヘッダーの目的地ポートナンバーはゼロに設定されるでしょう。 X2Uでは、トランスポート層ヘッダーの目的地ポートナンバーはユニキャストパケットの目的地に対応するポートナンバーに設定されるでしょう。
8.2. List of DSCPs
8.2. DSCPsのリスト
The Xcast packet could (optionally) also contain a list of Diffserv Code Points (DSCPs). While traditional IP multicast protocols have to create separate groups for each service class, Xcast incorporates the possibility of having receivers with different service requirements within one channel.
また、Xcastパケットは(任意に)Diffserv Code Points(DSCPs)のリストを含むかもしれません。 伝統的なIPマルチキャストプロトコルはそれぞれのサービスのクラスのために別々のグループを創設しなければなりませんが、Xcastは1個のチャンネルの中に異なったサービス要件で受信機を持っている可能性を取り入れます。
The DSCP in the IP header will be set to the most demanding DSCP of the list of DSCPs. This DSCP in the IP header will determine, e.g., the scheduler to use.
IPヘッダーのDSCPはDSCPsのリストの最も過酷なDSCPに用意ができるでしょう。 ヘッダーが決定するIP、例えば使用するスケジューラのこのDSCP。
If two destinations, with the same next-hop, have 'non-mergeable' DSCPs, two Xcast packets will be created. 'Non-mergeable' meaning that one cannot say that one is more or less stringent than the other.
2つの目的地に'非合併可能'DSCPsが同じ次のホップと共にあると、2つのXcastパケットが作成されるでしょう。 それを意味する'非合併可能'は、1つがもう片方より多少厳しいと言うことができません。
8.3. Channel Identifier
8.3. チャンネル識別子
Optionally, a sender can decide to add an extra number in the Xcast header: the Channel Identifier. If the source does not want to use this option, it must set the Channel Identifier to zero. If the Channel Identifier is non-zero, the pair (Source Address, Channel Identifier) must uniquely identify the channel (note that this is similar to the (S, G) pair in SSM). This document does not assign any other semantics to the Channel Identifier besides the one above.
任意に、送付者は、Xcastヘッダーで増刊を加えると決めることができます: 英仏海峡識別子。 ソースがこのオプションを使用したいと思わないなら、それは英仏海峡Identifierをゼロに設定しなければなりません。 英仏海峡Identifierが非ゼロであるなら、組(ソースAddress、Channel Identifier)は唯一チャンネルを特定しなければなりません(これがSSMで(S、G)組と同様であることに注意してください)。 このドキュメントは上のもの以外にいかなる他の意味論も英仏海峡Identifierに割り当てません。
Boivie, et al. Experimental [Page 15] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[15ページ]RFC5058Xcast概念とオプション2007年11月
This Channel Identifier could be useful for several purposes:
このChannel Identifierはいくつかの目的の役に立つかもしれません:
1) A key to a caching table [OOMS].
1) キャッシュテーブル[オームス]のキー。
2) "Harmonization" when used with Host Group Multicast (to be
discussed in greater detail in another document).
2) 「調和させること、」 Host Group Multicast(別のドキュメントで詳細によりすばらしい議論する)と共に使用されると。
3) An identifier of the channel in error, flow control, etc.,
messages.
3) 間違いチャンネル、フロー制御などの識別子、メッセージ。
4) It gives an extra demultiplexing possibility (beside the port-
number).
4) それは付加的な逆多重化の可能性(ポート番号の横の)を与えます。
5) ...
5) ...
The size of the channel identifier and its semantics are TBD.
チャンネル識別子のサイズとその意味論はTBDです。
9. Possible Xcast Packet Encoding
9. 可能なXcastパケットコード化
9.1. General
9.1. 一般
The source address field of the IP header contains the address of the Xcast sender. The destination address field carries the All-Xcast- Routers address (to be assigned link-local multicast address); this is to have a fixed value. Every Xcast router joins this multicast group. The reasons for putting a fixed number in the destination field are:
IPヘッダーのソースアドレス分野はXcast送付者のアドレスを含んでいます。 目的地アドレス・フィールドはAll-Xcastルータアドレス(リンクローカルのマルチキャストアドレスが割り当てられる)を運びます。 これは、一定の価値を持つためのものです。 あらゆるXcastルータがこのマルチキャストグループに加わります。 あて先フィールドに定数を置く理由は以下の通りです。
1) The destination address field is part of the IP pseudo header and
the latter is covered by transport layer checksums (e.g., UDP
checksum). So, the fixed value avoids a (delta) recalculation of
the checksum.
1) 目的地アドレス・フィールドはIP疑似ヘッダーの一部です、そして、後者はトランスポート層チェックサム(例えば、UDPチェックサム)でカバーされています。 それで、一定の価値はチェックサムの(デルタ)再計算を避けます。
2) The IPsec Authentication Header (AH) [4302] covers the IP header
destination address, hence preventing any modification to that
field. Also, both AHs and Encapsulating Security Payloads (ESPs)
cover the whole UDP packet (via authentication and/or encryption).
The UDP checksum cannot therefore be updated if the IP header
destination address were to change.
2) IPsec認証ヘッダー(ああ) [4302] したがって、その分野へのどんな変更も防いで、IPヘッダー送付先アドレスをカバーしています。 また、AHsとEncapsulating Security有効搭載量の両方(ESPs)が全体のUDPパケット(認証、そして/または、暗号化を通した)をカバーしています。 したがって、IPヘッダー送付先アドレスが変化するつもりであったなら、UDPチェックサムをアップデートできません。
3) In Xcast for IPv6, the Routing Extension shall be used; this
header extension is only checked by a router if the packet is
destined to this router. This is achieved by making all Xcast
routers part of the All_Xcast_Routers group.
3) IPv6のためのXcastでは、ルート設定Extensionは使用されるものとします。 パケットがこのルータに運命づけられている場合にだけ、このヘッダー拡大はルータによってチェックされます。 これは、Xcastルータが分けるAll_Xcast_Routersグループのすべてを作ることによって、達成されます。
Boivie, et al. Experimental [Page 16] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[16ページ]RFC5058Xcast概念とオプション2007年11月
4) Normally Xcast packets are only visible to Xcast routers.
However, if a non-Xcast router receives an Xcast packet by
accident (or by criminal intent), it will not send ICMP errors
since the Xcast packet carries a multicast address in the
destination address field [1812].
4) 通常、Xcastパケットは単にXcastルータに目に見えます。 しかしながら、非Xcastルータが偶然に(または犯行目的で)Xcastパケットを受けると、Xcastパケットが目的地アドレス・フィールド[1812]でマルチキャストアドレスを運ぶので、それは誤りをICMPに送らないでしょう。
Note that some benefits only hold when the multicast address stays in the destination field until it reaches the end-node (thus not combinable with X2U).
エンドノード(その結果、X2Uと共に結合可能しない)に達するまでマルチキャストアドレスがあて先フィールドにいるときだけ、いくつかの利益が成立することに注意してください。
9.2. IPv4
9.2. IPv4
[AGUI] and [1770] proposed (for a slightly different purpose) to carry multiple destinations in the IPv4 option. But because of the limited flexibility (limited size of the header), Xcast will follow another approach. The list of destinations will be encoded in a separate header. The Xcast header for IPv4 (in short, Xcast4) would be carried between the IPv4 header and the transport-layer header.
[阿久比]と[1770]は、IPv4オプションにおける複数の目的地を運ぶよう提案しました(わずかに異なった目的のために)。 しかし、限定変動相場(ヘッダーの限られたサイズ)のために、Xcastは別のアプローチに続くでしょう。 目的地のリストは別々のヘッダーでコード化されるでしょう。 IPv4(要するにXcast4)のためのXcastヘッダーはIPv4ヘッダーとトランスポート層ヘッダーの間まで運ばれるでしょう。
[IPv4 header | Xcast4 | transport header | payload ]
[IPv4ヘッダー|Xcast4|輸送ヘッダー| ペイロード]
Note also that since the Xcast header is added to the data portion of the packet, if the sender wishes to avoid IP fragmentation, it must take the size of the Xcast header into account.
また、送付者がIP断片化を避けたいならXcastヘッダーがパケットのデータ部に加えられるのでXcastヘッダーのサイズを考慮に入れなければならないことに注意してください。
9.2.1. IPv4 Header
9.2.1. IPv4ヘッダー
The Xcast4 header is carried on top of an IP header. The IP header will carry the protocol number listed as usable for experimental purposes in RFC 4727 [4727]. See also Section 15. The source address field contains the address of the Xcast sender. The destination address field carries the All_Xcast_Routers address.
Xcast4ヘッダーはIPヘッダーの上に運ばれます。 IPヘッダーはRFC4727[4727]実験目的のために使用可能であるとして記載されたプロトコル番号を運ぶでしょう。 また、セクション15を見てください。 ソースアドレス・フィールドはXcast送付者のアドレスを含んでいます。 目的地アドレス・フィールドはAll_Xcast_Routersアドレスを運びます。
9.2.2. Xcast4 Header
9.2.2. Xcast4ヘッダー
The Xcast4 header is format depicted in Figure 4. It is composed of two parts: a fixed part (first 12 octets) and two variable-length parts that are specified by the fixed part.
Xcast4ヘッダーは図4に表現された書式です。 それは2つの部品で構成されます: 固定部分によって指定される固定部分(最初の12の八重奏)と2つの可変長の部品。
Boivie, et al. Experimental [Page 17] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[17ページ]RFC5058Xcast概念とオプション2007年11月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VERSION|A|X|D|P|R| NBR_OF_DEST | CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHANNEL IDENTIFIER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROT ID | LENGTH | RESV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Addresses and DSCPs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Port Numbers (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |バージョン|A|X|D|P|R| _DESTのNBR_| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チャンネル識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PROT ID| 長さ| RESV| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 住所録とDSCPs| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ポートナンバー(任意の)のリスト| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
図4
VERSION = Xcast version number. This document describes version 1.
バージョンはXcastバージョン番号と等しいです。 このドキュメントはバージョン1について説明します。
A = Anonymity bit: if this bit is set, the destination addresses for which the corresponding bit in the bitmap is zero must be overwritten by zero.
=匿名に噛み付きました: このビットが設定されるなら、ビットマップの対応するビットがゼロである送付先アドレスをゼロで上書きしなければなりません。
X = Xcast bit: if this bit is set, a router must not reduce the Xcast packet to unicast packet(s), i.e., the packet must stay an Xcast packet end-to-end. This bit can be useful when IPsec [4301] is applied. If this bit is cleared a router should apply X2U if there is only one destination left in the Xcast packet. In some cases a router could decide not to apply X2U to a packet with the Xcast bit cleared, e.g., the router has no directly connected hosts and wants to avoid the extra processing required by X2U.
X=Xcastは噛み付きました: このビットが設定されるなら、ルータはXcastパケットをユニキャストパケットに変えてはいけません、すなわち、パケットがXcastのパケットの終わりからエンドのままで残らなければなりません。 IPsec[4301]が適用されているとき、このビットは役に立つ場合があります。 このビットがきれいにされるなら、1つの目的地だけがXcastパケットに残っているなら、ルータはX2Uを適用するべきです。 いくつかの場合、ルータは、Xcastビットがきれいにされている状態でX2Uをパケットに適用しないと決めるかもしれません、そして、例えば、ルータには、どんな直接接続されたホストもいません、そして、付加的な処理を避ける必需品がX2Uが必要です。
D = DSCP bit: if this bit is set, the packet will contain a DS byte for each destination.
D=DSCPは噛み付きました: このビットが設定されると、パケットは各目的地へのDSバイトを含むでしょう。
P = Port bit: if this bit is set, the packet will contain a port number for each destination.
Pはポートビットと等しいです: このビットが設定されると、パケットは各目的地へのポートナンバーを含むでしょう。
NBR_OF_DEST = the number of original destinations.
NBR_OF_DESTは元の目的地の数と等しいです。
CHECKSUM = A checksum on the Xcast header only. This is verified and recomputed at each point that the Xcast header is processed. The checksum field is the 16-bit one's complement of the one's complement sum of all the bytes in the header. For purposes of computing the checksum, the value of the checksum field is zero. It is not clear yet whether a checksum is needed (for further study). If only one destination is wrong it can still be useful to forward the packet to N-1 correct destinations and 1 incorrect destination.
CHECKSUMはXcastヘッダーだけの上にチェックサムと等しいです。 これは、Xcastヘッダーが処理されるという各ポイントで確かめられて、再計算されます。 チェックサム分野はヘッダーでのすべてのバイトの1の補数合計の16ビットの1の補数です。 チェックサムを計算する目的のために、チェックサム分野の値はゼロです。 チェックサムが必要であるかどうかは(さらなる研究に)、まだ明確ではありません。 1つの目的地だけが間違っているなら、N-1の正しい目的地と1つの不正確な目的地にパケットを送るのはまだ役に立っている場合があります。
Boivie, et al. Experimental [Page 18] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[18ページ]RFC5058Xcast概念とオプション2007年11月
CHANNEL IDENTIFIER = 4-octet Channel Identifier (see Section 8.3). Since it is located within the first 8 bytes of the header, it will be returned in ICMP messages.
チャンネル識別子は4八重奏のチャンネル識別子と等しいです(セクション8.3を見てください)。 それがヘッダーの最初の8バイト以内で位置しているので、ICMPメッセージでそれを返すでしょう。
PROT ID = specifies the protocol of the following header.
PROT ID=は以下のヘッダーのプロトコルを指定します。
LENGTH = length of the Xcast header in 4-octet words. This field puts an upper boundary to the number of destinations. This value is also determined by the NBR_OF_DEST field and the D and P bits.
LENGTHは4八重奏の単語によるXcastヘッダーの長さと等しいです。 この分野は上側の境界を目的地の数につけます。 また、NBR_OF_DEST分野、D、およびPビットに従って、この値も決定しています。
RESV = R = Reserved. It must be zero on transmission and must be ignored on receipt.
RESVは予約されたR=と等しいです。 それをトランスミッションのゼロでなければならなく、領収書の上で無視しなければなりません。
The first variable part is the 'List of Addresses and DSCPs', the second variable part is the 'List of Port Numbers'. Both are 4-octet aligned. The second variable part is only present if the P-bit is set.
最初の可変部分は可変部分が'Port民数記のリスト'である秒に'AddressesとDSCPsのリスト'です。 両方が並べられた4八重奏です。 P-ビットが設定される場合にだけ、2番目の可変部分は存在しています。
Figure 5 gives an example of the variable part for the case that the P-bit is set and the D-bit is cleared (in this example, N is odd):
クリアされて(この例では、Nは変です)、図5はP-ビットが設定されて、D-ビットが設定されるケースのために可変部分に関する例を出します:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BITMAP |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port 1 | Port 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port N | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ビットマップ| ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目的地1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 目的地N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ポート1| ポート2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ポートN| 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
図5
Boivie, et al. Experimental [Page 19] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[19ページ]RFC5058Xcast概念とオプション2007年11月
BITMAP = every destination has a corresponding bit in the bitmap to indicate whether the destination is still valid on this branch of the tree. The first bit corresponds to the first destination in the list. This field is 4-octet aligned (e.g., for 49 destinations, there will be a 64-bit bitmap). If Xcast is applied in combination with IPsec, the bitmap -- since it can change en route -- has to be moved to a new to-be-defined IPv4 option.
あらゆるBITMAP=目的地が、目的地が木のこの枝でまだ有効であるかどうかを示すためにビットマップに対応するビットを持っています。 最初のビットはリストにおける最初の目的地に対応しています。 この分野は並べられた4八重奏(例えば、49の目的地には、64ビットのビットマップがある)です。 XcastがIPsecと組み合わせて適用されるなら、途中で変化できて以来のビットマップは定義された新しいIPv4オプションに動かされなければなりません。
List of Destinations. Each address size is 4 octets.
目的地のリスト。 それぞれのアドレスサイズは4つの八重奏です。
List of Port Numbers. List of 2-octet destination port number(s), where each port corresponds in placement to the preceding Destination Address.
ポートナンバーのリスト。 2八重奏の目的地ポートナンバーのリスト。(そこでは、各ポートがプレースメントで前のDestination Addressに対応します)。
9.3. IPv6
9.3. IPv6
The Xcast6 header encoding is similar to IPv4, except that Xcast information would be stored in IPv6 extension headers.
Xcast情報がIPv6拡張ヘッダーに保存されるだろうというのを除いて、Xcast6ヘッダーコード化はIPv4と同様です。
[IPv6 header | Xcast6 | transport header | payload ]
[IPv6ヘッダー|Xcast6|輸送ヘッダー| ペイロード]
9.3.1. IPv6 Header
9.3.1. IPv6ヘッダー
The IPv6 header will carry the NextHeader value 'Routing Extension'. The source address field contains the address of the Xcast sender. The destination address field carries the All_Xcast_Routers address.
IPv6ヘッダーはNextHeader値の'ルート設定Extension'を運ぶでしょう。 ソースアドレス・フィールドはXcast送付者のアドレスを含んでいます。 目的地アドレス・フィールドはAll_Xcast_Routersアドレスを運びます。
9.3.2. Xcast6 Header
9.3.2. Xcast6ヘッダー
The Xcast6 header is also composed of a fixed part and two variable parts. The fixed part and the first variable part are carried in a Routing Extension. The second variable part is carried in a Destination Extension.
また、Xcast6ヘッダーは固定部分と2つの可変部分で構成されます。 固定部分と最初の可変部分はルート設定Extensionで運ばれます。 2番目の可変部分はDestination Extensionで運ばれます。
Boivie, et al. Experimental [Page 20] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[20ページ]RFC5058Xcast概念とオプション2007年11月
9.3.2.1. Routing Extension Header
9.3.2.1. ルート設定拡張ヘッダー
The P-bit of Xcast4 is not present because it is implicit by the presence or absence of the Destination Extension (Figure 6).
それがDestination Extension(図6)の存在か不在で暗黙であるので、Xcast4のP-ビットは存在していません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrExtLen |RouteType=Xcast| 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VERSION|A|X|D| R | NBR_OF_DEST | CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHANNEL IDENTIFIER |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Addresses and DSCPs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | HdrExtLen |RouteType=Xcast| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VERSION|A|X|D| R | NBR_OF_DEST | CHECKSUM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CHANNEL IDENTIFIER | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List of Addresses and DSCPs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6
Figure 6
HdrExtLen = The header length is expressed in 8-octets; thus, a maximum of 127 destinations can be listed (this is why NBR_OF_DEST is 7 bits).
HdrExtLen = The header length is expressed in 8-octets; thus, a maximum of 127 destinations can be listed (this is why NBR_OF_DEST is 7 bits).
RouteType = Xcast (see Section 15)
RouteType = Xcast (see Section 15)
The fourth octet is set to 0.
The fourth octet is set to 0.
R = Reserved.
R = Reserved.
CHANNEL IDENTIFIER = 16-octet Channel Identifier (see Section 8.3).
CHANNEL IDENTIFIER = 16-octet Channel Identifier (see Section 8.3).
The other fields are defined in Section 9.2.2.
The other fields are defined in Section 9.2.2.
The 'List of Addresses and DSCPs' is 8-octet aligned. The size of the bitmap is determined by the number of destinations and is a multiple of 64 bits.
The 'List of Addresses and DSCPs' is 8-octet aligned. The size of the bitmap is determined by the number of destinations and is a multiple of 64 bits.
9.3.2.2. Destination Extension Header
9.3.2.2. Destination Extension Header
Optionally, the Destination Extension (Figure 7) is present to specify the list of Port Numbers. The destination header is only evaluated by the destination node.
Optionally, the Destination Extension (Figure 7) is present to specify the list of Port Numbers. The destination header is only evaluated by the destination node.
Boivie, et al. Experimental [Page 21] RFC 5058 Xcast Concepts and Options November 2007
Boivie, et al. Experimental [Page 21] RFC 5058 Xcast Concepts and Options November 2007
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrExtLen |Opt Type=Ports | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Port Numbers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | HdrExtLen |Opt Type=Ports | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List of Port Numbers | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7
Figure 7
For the Option Type for Ports, see Section 15. The first three bits must be 010 to indicate that the packet must be discarded if the option is unknown and that the option cannot be changed en-route.
For the Option Type for Ports, see Section 15. The first three bits must be 010 to indicate that the packet must be discarded if the option is unknown and that the option cannot be changed en-route.
The number of Ports must be equal to the number of destinations specified in the Routing header.
The number of Ports must be equal to the number of destinations specified in the Routing header.
10. Impact on Upper-Layer Protocols
10. Impact on Upper-Layer Protocols
Some fields in the Xcast header(s) can be modified as the packet travels along its delivery path. This has an impact on:
Some fields in the Xcast header(s) can be modified as the packet travels along its delivery path. This has an impact on:
10.1. Checksum Calculation in Transport-Layer Headers
10.1. Checksum Calculation in Transport-Layer Headers
In transport-layer headers, the target of the checksum calculation includes the IP pseudo header, transport header, and payload (IPv6 header extensions are not a target).
In transport-layer headers, the target of the checksum calculation includes the IP pseudo header, transport header, and payload (IPv6 header extensions are not a target).
The transformation of an Xcast packet to a normal unicast packet -- (premature) X2U -- replaces the multicast address in the IP header destination field by the address of a final destination. If the Xcast header contains a Port List, the port number in the transport layer (which should be zero) also needs to be replaced by the port number corresponding to the destination. This requires a recalculation of these checksums. Note that this does not require a complete recalculation of the checksum, only a delta calculation, e.g., for IPv4:
The transformation of an Xcast packet to a normal unicast packet -- (premature) X2U -- replaces the multicast address in the IP header destination field by the address of a final destination. If the Xcast header contains a Port List, the port number in the transport layer (which should be zero) also needs to be replaced by the port number corresponding to the destination. This requires a recalculation of these checksums. Note that this does not require a complete recalculation of the checksum, only a delta calculation, e.g., for IPv4:
Checksum' = ~ (~Checksum + ~daH + ~daL + daH' + daL' + ~dp + dp')
Checksum' = ~ (~Checksum + ~daH + ~daL + daH' + daL' + ~dp + dp')
In which "'" indicates the new values, "da" the destination address, "dp" the destination port, and "H" and "L" the higher and lower 16 bits, respectively.
In which "'" indicates the new values, "da" the destination address, "dp" the destination port, and "H" and "L" the higher and lower 16 bits, respectively.
10.2. IPsec
10.2. IPsec
This is described in [PARI].
This is described in [PARI].
Boivie, et al. Experimental [Page 22] RFC 5058 Xcast Concepts and Options November 2007
Boivie, et al. Experimental [Page 22] RFC 5058 Xcast Concepts and Options November 2007
11. Gradual Deployment
11. Gradual Deployment
11.1. Tunneling
11.1. Tunneling
One way to deploy Xcast in a network that has routers that have no knowledge of Xcast is to setup "tunnels" between Xcast peers (MBone approach [MBONE]). This enables the creation of a virtual network layered on top of an existing network [2003]. The Xcast routers exchange and maintain Xcast routing information via any standard unicast routing protocol (e.g., RIP, OSPF, IS-IS, BGP). The Xcast routing table that is created is simply a standard unicast routing table that contains the destinations that have Xcast connectivity, along with their corresponding Xcast next hops. In this way, packets may be forwarded hop-by-hop to other Xcast routers, or may be "tunneled" through non- Xcast routers in the network.
One way to deploy Xcast in a network that has routers that have no knowledge of Xcast is to setup "tunnels" between Xcast peers (MBone approach [MBONE]). This enables the creation of a virtual network layered on top of an existing network [2003]. The Xcast routers exchange and maintain Xcast routing information via any standard unicast routing protocol (e.g., RIP, OSPF, IS-IS, BGP). The Xcast routing table that is created is simply a standard unicast routing table that contains the destinations that have Xcast connectivity, along with their corresponding Xcast next hops. In this way, packets may be forwarded hop-by-hop to other Xcast routers, or may be "tunneled" through non- Xcast routers in the network.
For example, suppose that A is trying to get packets distributed to B, C, and D in Figure 8 below, where "X" routers are Xcast-capable, and "R" routers are not. Figure 9 shows the routing tables created via the Xcast tunnels:
For example, suppose that A is trying to get packets distributed to B, C, and D in Figure 8 below, where "X" routers are Xcast-capable, and "R" routers are not. Figure 9 shows the routing tables created via the Xcast tunnels:
R4 ---- B
/
/
A ----- X1 ---- R2 ---- X3 R8 ---- C
\ /
\ /
R5 ---- R6 ---- X7
\
\
R9 ---- D
R4 ---- B / / A ----- X1 ---- R2 ---- X3 R8 ---- C \ / \ / R5 ---- R6 ---- X7 \ \ R9 ---- D
Figure 8
Figure 8
Router X1 establishes a tunnel to Xcast peer X3. Router X3 establishes a tunnel to Xcast peers X1 and X7. Router X7 establishes a tunnel to Xcast peer X3.
Router X1 establishes a tunnel to Xcast peer X3. Router X3 establishes a tunnel to Xcast peers X1 and X7. Router X7 establishes a tunnel to Xcast peer X3.
X1 routing table: X3 routing table: X7 routing table:
Dest | NextHop Dest | NextHop Dest | NextHop
------+---------- ------+--------- ------+---------
B | X3 A | X1 A | X3
C | X3 C | X7 B | X3
D | X3 D | X7
X1 routing table: X3 routing table: X7 routing table: Dest | NextHop Dest | NextHop Dest | NextHop ------+---------- ------+--------- ------+--------- B | X3 A | X1 A | X3 C | X3 C | X7 B | X3 D | X3 D | X7
Figure 9
Figure 9
Boivie, et al. Experimental [Page 23] RFC 5058 Xcast Concepts and Options November 2007
Boivie, et al. Experimental [Page 23] RFC 5058 Xcast Concepts and Options November 2007
The source A will send an Xcast packet to its default Xcast router, X1, that includes the list of destinations for the packet. The packet on the link between X1 and X3 is depicted in Figure 10:
The source A will send an Xcast packet to its default Xcast router, X1, that includes the list of destinations for the packet. The packet on the link between X1 and X3 is depicted in Figure 10:
+----------+
| payload |
+----------+
| UDP |
+----------+
| Xcast |
| B,C,D |
| prot=UDP |
+----------+
| inner IP |
| src=A |
|dst=All_X_|
|prot=Xcast|
+----------+
| outer IP |
| src=X1 |
| dst=X3 |
| prot=IP |
+----------+
+----------+ | payload | +----------+ | UDP | +----------+ | Xcast | | B,C,D | | prot=UDP | +----------+ | inner IP | | src=A | |dst=All_X_| |prot=Xcast| +----------+ | outer IP | | src=X1 | | dst=X3 | | prot=IP | +----------+
Figure 10
Figure 10
When X3 receives this packet, it processes it as follows:
When X3 receives this packet, it processes it as follows:
- Perform a route table lookup in the Xcast routing table to
determine the Xcast next hop for each of the destinations listed in
the packet.
- Perform a route table lookup in the Xcast routing table to determine the Xcast next hop for each of the destinations listed in the packet.
- If no Xcast next hop is found, replicate the packet and send a
standard unicast to the destination.
- If no Xcast next hop is found, replicate the packet and send a standard unicast to the destination.
- For those destinations for which an Xcast next hop is found,
partition the destinations based on their next hops.
- For those destinations for which an Xcast next hop is found, partition the destinations based on their next hops.
- Replicate the packet so that there's one copy of the packet for
each of the Xcast next hops found in the previous steps.
- Replicate the packet so that there's one copy of the packet for each of the Xcast next hops found in the previous steps.
- Modify the list of destinations in each of the copies so that the
list in the copy for a given next hop includes just the
destinations that ought to be routed through that next hop.
- Modify the list of destinations in each of the copies so that the list in the copy for a given next hop includes just the destinations that ought to be routed through that next hop.
- Send the modified copies of the packet on to the next hops.
- Send the modified copies of the packet on to the next hops.
Boivie, et al. Experimental [Page 24] RFC 5058 Xcast Concepts and Options November 2007
Boivie, et al. Experimental [Page 24] RFC 5058 Xcast Concepts and Options November 2007
- Optimization: If there is only one destination for a particular
Xcast next hop, send the packet as a standard unicast packet to the
destination, since there is no advantage to forwarding it as an
Xcast packet.
- Optimization: If there is only one destination for a particular Xcast next hop, send the packet as a standard unicast packet to the destination, since there is no advantage to forwarding it as an Xcast packet.
So, in the example above, X1 will send a single packet on to X3 with a destination list of < B C D >. This packet will be received by R2 as a unicast packet with destination X3, and R2 will forward it on, having no knowledge of Xcast. When X3 receives the packet, it will, by the algorithm above, send one copy of the packet to destination < B > as an ordinary unicast packet, and 1 copy of the packet to X7 with a destination list of < C D >. R4, R5, and R6 will behave as standard routers with no knowledge of Xcast. When X7 receives the packet, it will parse the packet and transmit ordinary unicast packets addressed to < C > and < D >, respectively.
So, in the example above, X1 will send a single packet on to X3 with a destination list of < B C D >. This packet will be received by R2 as a unicast packet with destination X3, and R2 will forward it on, having no knowledge of Xcast. When X3 receives the packet, it will, by the algorithm above, send one copy of the packet to destination < B > as an ordinary unicast packet, and 1 copy of the packet to X7 with a destination list of < C D >. R4, R5, and R6 will behave as standard routers with no knowledge of Xcast. When X7 receives the packet, it will parse the packet and transmit ordinary unicast packets addressed to < C > and < D >, respectively.
The updating of this route table, while simple in an intra-domain environment, would be more complex in an inter-domain environment. Thus, the use of tunneling in an inter-domain environment requires further consideration.
The updating of this route table, while simple in an intra-domain environment, would be more complex in an inter-domain environment. Thus, the use of tunneling in an inter-domain environment requires further consideration.
11.2. Premature X2U
11.2. Premature X2U
If a router discovers that its downstream neighbor is not Xcast capable, it can perform a Premature X2U, i.e., send a unicast packet for each destination in the Xcast header that has this neighbor as a next hop. Thus, duplication is done before the Xcast packet reached its actual branching point.
If a router discovers that its downstream neighbor is not Xcast capable, it can perform a Premature X2U, i.e., send a unicast packet for each destination in the Xcast header that has this neighbor as a next hop. Thus, duplication is done before the Xcast packet reached its actual branching point.
A mechanism (protocol/protocol extension) to discover the Xcast capability of a neighbor is for further study. Among others, one could think of an extension to a routing protocol to advertise Xcast capabilities, or one could send periodic 'Xcast pings' to its neighbors (send an Xcast packet that contains its own address as a destination and check whether the packet returns).
A mechanism (protocol/protocol extension) to discover the Xcast capability of a neighbor is for further study. Among others, one could think of an extension to a routing protocol to advertise Xcast capabilities, or one could send periodic 'Xcast pings' to its neighbors (send an Xcast packet that contains its own address as a destination and check whether the packet returns).
11.3. Semi-Permeable Tunneling (IPv6 Only)
11.3. Semi-Permeable Tunneling (IPv6 Only)
This is an optimization of tunneling in the sense that it does not require (manual) configuration of tunnels. It is enabled by adding a Hop-by-Hop Xcast6 header. An IPv6 packet can initiate/trigger additional processing in the on-route routers by using the IPv6 Hop- by-hop option.
This is an optimization of tunneling in the sense that it does not require (manual) configuration of tunnels. It is enabled by adding a Hop-by-Hop Xcast6 header. An IPv6 packet can initiate/trigger additional processing in the on-route routers by using the IPv6 Hop- by-hop option.
The type of the Xcast6 Hop-by-hop option has a prefix '00' so that routers that cannot recognize Xcast6 can treat the Xcast6 datagram as a normal IPv6 datagram and forward it toward the destination in the IPv6 header.
The type of the Xcast6 Hop-by-hop option has a prefix '00' so that routers that cannot recognize Xcast6 can treat the Xcast6 datagram as a normal IPv6 datagram and forward it toward the destination in the IPv6 header.
Boivie, et al. Experimental [Page 25] RFC 5058 Xcast Concepts and Options November 2007
Boivie, et al. Experimental [Page 25] RFC 5058 Xcast Concepts and Options November 2007
Packets will be delivered to all members if at least all participating hosts are upgraded.
Packets will be delivered to all members if at least all participating hosts are upgraded.
When the source A sends an Xcast packet via semi-permeable tunneling to destinations B, C, and D, it will create the packet of Figure 11. One of the final destinations will be put in the destination address field of the outer IP header.
When the source A sends an Xcast packet via semi-permeable tunneling to destinations B, C, and D, it will create the packet of Figure 11. One of the final destinations will be put in the destination address field of the outer IP header.
+----------+
| payload |
+----------+
| UDP |
+----------+
| Xcast |
| |
+----------+
| inner IP |
| src=A |
|dst=All_X_|
|prot=Xcast|
+----------+
| Xcast |
|SP-tunnel |
|Hop-by-hop|
+----------+
| outer IP |
| src=A |
| dst=B |
| prot=IP |
+----------+
+----------+ | payload | +----------+ | UDP | +----------+ | Xcast | | | +----------+ | inner IP | | src=A | |dst=All_X_| |prot=Xcast| +----------+ | Xcast | |SP-tunnel | |Hop-by-hop| +----------+ | outer IP | | src=A | | dst=B | | prot=IP | +----------+
Figure 11
Figure 11
Semi-permeable tunneling is a special tunneling technology that permits intermediate Xcast routers on a tunnel to check the destinations and branch if destinations have a different next hop.
Semi-permeable tunneling is a special tunneling technology that permits intermediate Xcast routers on a tunnel to check the destinations and branch if destinations have a different next hop.
Note that with the introduction of an Xcast IPv4 option, this technique could also be applied in IPv4 networks.
Note that with the introduction of an Xcast IPv4 option, this technique could also be applied in IPv4 networks.
11.4. Special Case: Deployment without Network Support
11.4. Special Case: Deployment without Network Support
A special method of deploying Xcast is possible by upgrading only the hosts. By applying tunneling (see Sections 11.1 and 11.3) with one of the final destinations as a tunnel endpoint, the Xcast packet will be delivered to all destinations when all the hosts are Xcast aware. Both normal and semi-permeable tunneling can be used.
A special method of deploying Xcast is possible by upgrading only the hosts. By applying tunneling (see Sections 11.1 and 11.3) with one of the final destinations as a tunnel endpoint, the Xcast packet will be delivered to all destinations when all the hosts are Xcast aware. Both normal and semi-permeable tunneling can be used.
Boivie, et al. Experimental [Page 26] RFC 5058 Xcast Concepts and Options November 2007
Boivie, et al. Experimental [Page 26] RFC 5058 Xcast Concepts and Options November 2007
If host B receives this packet, in the above example, it will notice the other destinations in the Xcast header. B will create a new Xcast packet and will send it to one of the remaining destinations.
If host B receives this packet, in the above example, it will notice the other destinations in the Xcast header. B will create a new Xcast packet and will send it to one of the remaining destinations.
In the case of Xcast6 and semi-permeable tunneling, Xcast routers can be introduced in the network without the need of configuring tunnels.
In the case of Xcast6 and semi-permeable tunneling, Xcast routers can be introduced in the network without the need of configuring tunnels.
The disadvantages of this method are:
The disadvantages of this method are:
- all hosts in the session need to be upgraded.
- all hosts in the session need to be upgraded.
- non-optimal routing.
- non-optimal routing.
- anonymity issue: hosts can know the identity of other parties in the session (which is not a big issue in conferencing, but maybe for some other application).
- anonymity issue: hosts can know the identity of other parties in the session (which is not a big issue in conferencing, but maybe for some other application).
- host has to perform network functions and needs an upstream link which has the same bandwidth as its downstream link.
- host has to perform network functions and needs an upstream link which has the same bandwidth as its downstream link.
11.5. Using a Small Number of Xcast-Aware Routers to Provide Xcast
in a Not-So-Small Network
11.5. Using a Small Number of Xcast-Aware Routers to Provide Xcast in a Not-So-Small Network
In this approach, an Xcast packet uses a special 32-bit unicast address in the destination field of the IP header. In the simplest version of this scheme, there might be only a single Xcast-aware router in a network. This Xcast-aware router looks like a "server" to the other routers and it is configured so that its IP address (or one of its IP addresses) corresponds to the "special" 32-bit address. Thus, when Xcast clients send Xcast packets, the non-Xcast-aware routers will route these packets to the Xcast-aware router and the Xcast-aware router can "explode" (X2U) them into an appropriate set of unicast packets. This allows clients anywhere in a network to use Xcast to overcome the problem of limited bandwidth in the "first mile" with a minimum number of Xcast-aware routers (i.e., 1).
In this approach, an Xcast packet uses a special 32-bit unicast address in the destination field of the IP header. In the simplest version of this scheme, there might be only a single Xcast-aware router in a network. This Xcast-aware router looks like a "server" to the other routers and it is configured so that its IP address (or one of its IP addresses) corresponds to the "special" 32-bit address. Thus, when Xcast clients send Xcast packets, the non-Xcast-aware routers will route these packets to the Xcast-aware router and the Xcast-aware router can "explode" (X2U) them into an appropriate set of unicast packets. This allows clients anywhere in a network to use Xcast to overcome the problem of limited bandwidth in the "first mile" with a minimum number of Xcast-aware routers (i.e., 1).
Another possibility is to deploy a few of these Xcast-aware routers at various points in the network and to configure each of these with the special 32-bit address. This provides redundancy, eliminating the single point of failure, and reduces the distance an Xcast packet needs to travel to reach an Xcast-aware router, reducing network latencies. In this case, the Xcast-aware routers appear to be a single server that is "multihomed" (i.e., connected to the network at more than one place) and the non-Xcast-aware routers will, via ordinary unicast routing, deliver packets that are addressed to this "multihomed virtual server" via the shortest available path.
Another possibility is to deploy a few of these Xcast-aware routers at various points in the network and to configure each of these with the special 32-bit address. This provides redundancy, eliminating the single point of failure, and reduces the distance an Xcast packet needs to travel to reach an Xcast-aware router, reducing network latencies. In this case, the Xcast-aware routers appear to be a single server that is "multihomed" (i.e., connected to the network at more than one place) and the non-Xcast-aware routers will, via ordinary unicast routing, deliver packets that are addressed to this "multihomed virtual server" via the shortest available path.
Boivie, et al. Experimental [Page 27] RFC 5058 Xcast Concepts and Options November 2007
Boivie, et al. Experimental [Page 27] RFC 5058 Xcast Concepts and Options November 2007
Note that this scheme of delivering packets to any host in a group is also known as an "anycast" and is described in more detail in RFCs [1546], [2526], and [3068]. Note too that RFC 1546 says:
Note that this scheme of delivering packets to any host in a group is also known as an "anycast" and is described in more detail in RFCs [1546], [2526], and [3068]. Note too that RFC 1546 says:
The important observation is that multiple routes to an anycast
address appear to a router as multiple routes to a unicast
destination, and the router can use standard algorithms to
choose the best route.
The important observation is that multiple routes to an anycast address appear to a router as multiple routes to a unicast destination, and the router can use standard algorithms to choose the best route.
12. (Socket) API
12. (Socket) API
In the most simple use of Xcast, the final destinations of an Xcast packet receive an ordinary unicast UDP packet. This means that hosts can receive an Xcast packet with a standard, unmodified TCP/IP stack.
In the most simple use of Xcast, the final destinations of an Xcast packet receive an ordinary unicast UDP packet. This means that hosts can receive an Xcast packet with a standard, unmodified TCP/IP stack.
Hosts can also transmit Xcast packets with a standard TCP/IP stack with a small Xcast library that sends Xcast packets on a raw socket. This has been used to implement Xcast-based applications on both Unix and Windows platforms without any kernel changes.
Hosts can also transmit Xcast packets with a standard TCP/IP stack with a small Xcast library that sends Xcast packets on a raw socket. This has been used to implement Xcast-based applications on both Unix and Windows platforms without any kernel changes.
Another possibility is to modify the sockets interface slightly. For example, one might add an "xcast_sendto" function that works like "sendto" but that uses a list of destination addresses in place of the single address that "sendto" uses.
Another possibility is to modify the sockets interface slightly. For example, one might add an "xcast_sendto" function that works like "sendto" but that uses a list of destination addresses in place of the single address that "sendto" uses.
13. Unresolved Issues
13. Unresolved Issues
Additional work is needed in several areas.
Additional work is needed in several areas.
13.1. The Format of the "List of Addresses"
13.1. The Format of the "List of Addresses"
Additional details need to be specified. For example, in the IPv4 case, the format of the DSCPs option needs to be specified.
Additional details need to be specified. For example, in the IPv4 case, the format of the DSCPs option needs to be specified.
13.2. The Size of Channel Identifier
13.2. The Size of Channel Identifier
The size of the channel identifiers in IPv4 and IPv6 are different in this document. 32 bits might be sufficient for both IPv6 and IPv4.
The size of the channel identifiers in IPv4 and IPv6 are different in this document. 32 bits might be sufficient for both IPv6 and IPv4.
13.3. Incremental Deployment
13.3. Incremental Deployment
Several possible methods of incremental deployment are discussed in this document including tunneling, premature X2U, etc. Additional work is needed to determine the best means of incremental deployment for an intra-domain as well as an inter-domain deployment of Xcast. If tunneling is used, additional details need to be specified (e.g., tunneling format, use of tunnels in the inter-domain case).
Several possible methods of incremental deployment are discussed in this document including tunneling, premature X2U, etc. Additional work is needed to determine the best means of incremental deployment for an intra-domain as well as an inter-domain deployment of Xcast. If tunneling is used, additional details need to be specified (e.g., tunneling format, use of tunnels in the inter-domain case).
Boivie, et al. Experimental [Page 28] RFC 5058 Xcast Concepts and Options November 2007
Boivie, et al. Experimental [Page 28] RFC 5058 Xcast Concepts and Options November 2007
13.4. DSCP Usage
13.4. DSCP Usage
DSCP usage needs some work. DSCPs may have to be rewritten as packets cross inter-domain boundaries.
DSCP usage needs some work. DSCPs may have to be rewritten as packets cross inter-domain boundaries.
13.5. Traversing a Firewall or NAT Products
13.5. Traversing a Firewall or NAT Products
The usage of a different, carried protocol type for IPv4 may cause difficulty in traversing some firewall and NAT products.
The usage of a different, carried protocol type for IPv4 may cause difficulty in traversing some firewall and NAT products.
13.6. The Size of BITMAP
13.6. The Size of BITMAP
Given that this is designed for small groups, it might make sense to simply mandate a fixed size for the bitmap.
Given that this is designed for small groups, it might make sense to simply mandate a fixed size for the bitmap.
14. Security Considerations
14. Security Considerations
The list of destinations in Xcast is provided by an application layer that manages group membership as well as authorization if authorization is desired.
The list of destinations in Xcast is provided by an application layer that manages group membership as well as authorization if authorization is desired.
Since a source has the list of destinations and can make changes to the list, it has more control over where its packets go than in traditional multicast and can prevent anonymous eavesdroppers from joining a multicast session, for example.
Since a source has the list of destinations and can make changes to the list, it has more control over where its packets go than in traditional multicast and can prevent anonymous eavesdroppers from joining a multicast session, for example.
Some forms of denial-of-service attack can use Xcast to increase their "effect". A smurf attack, for example, sends an ICMP Echo Request in which the source address in the packet is set to the address of the target of the attack so that the target will receive the ICMP echo reply. With Xcast, the ICMP Echo Request could be sent to a list of destinations that could cause each member of the list to send an Echo Reply to the target.
Some forms of denial-of-service attack can use Xcast to increase their "effect". A smurf attack, for example, sends an ICMP Echo Request in which the source address in the packet is set to the address of the target of the attack so that the target will receive the ICMP echo reply. With Xcast, the ICMP Echo Request could be sent to a list of destinations that could cause each member of the list to send an Echo Reply to the target.
Measures have been taken in traditional multicast to avoid this kind of attack. A router or host can be configured so that it will not reply to ICMP requests addressed to a multicast address. The Reverse Path Forwarding check in traditional multicast architectures also helps limit these attacks. In Xcast, it can be difficult for a host to recognize that an ICMP request has been addressed to multiple destinations since the packet may be an ordinary unicast packet by the time it reaches the host. On the other hand, a router can detect Xcast packets that are used to send ICMP requests to multiple destinations and can be configured to drop those packets. Note, too, that since Xcast sends packets to a short list of destinations, the problem of sending attack packets to multiple destination is less of
Measures have been taken in traditional multicast to avoid this kind of attack. A router or host can be configured so that it will not reply to ICMP requests addressed to a multicast address. The Reverse Path Forwarding check in traditional multicast architectures also helps limit these attacks. In Xcast, it can be difficult for a host to recognize that an ICMP request has been addressed to multiple destinations since the packet may be an ordinary unicast packet by the time it reaches the host. On the other hand, a router can detect Xcast packets that are used to send ICMP requests to multiple destinations and can be configured to drop those packets. Note, too, that since Xcast sends packets to a short list of destinations, the problem of sending attack packets to multiple destination is less of
Boivie, et al. Experimental [Page 29] RFC 5058 Xcast Concepts and Options November 2007
Boivie, et al. Experimental [Page 29] RFC 5058 Xcast Concepts and Options November 2007
a problem than in traditional multicast. Obviously, the use of IPsec to provide confidentiality and/or authentication can further diminish the risk of this type of attack.
a problem than in traditional multicast. Obviously, the use of IPsec to provide confidentiality and/or authentication can further diminish the risk of this type of attack.
The problem of secure group communications has been addressed by the Multicast Security (MSEC) working group, which has defined an architecture for securing IP-multicast-based group communications [3740]. Many of the concepts discussed in the MSEC working group, such as managing group membership, identifying and authenticating group members, protecting the confidentiality and integrity of multicast traffic, and managing and securely distributing and refreshing keys, also apply to Xcast-based group communications. And many of the same mechanisms seem to apply. One significant difference between multicast and Xcast is the fact that the Xcast header (or at least a bitmap in the Xcast header) needs to change as an Xcast packet travels from a source to a destination. This affects the use of IPsec and suggests that at least the Xcast header bitmap must be in a "mutable" field. A complete solution for securing Xcast-based group communications addressing all the issues listed above will be the subject of additional work which will be discussed in one or more additional documents. We expect that this effort will build on the work that has already been done in the msec working group.
The problem of secure group communications has been addressed by the Multicast Security (MSEC) working group, which has defined an architecture for securing IP-multicast-based group communications [3740]. Many of the concepts discussed in the MSEC working group, such as managing group membership, identifying and authenticating group members, protecting the confidentiality and integrity of multicast traffic, and managing and securely distributing and refreshing keys, also apply to Xcast-based group communications. And many of the same mechanisms seem to apply. One significant difference between multicast and Xcast is the fact that the Xcast header (or at least a bitmap in the Xcast header) needs to change as an Xcast packet travels from a source to a destination. This affects the use of IPsec and suggests that at least the Xcast header bitmap must be in a "mutable" field. A complete solution for securing Xcast-based group communications addressing all the issues listed above will be the subject of additional work which will be discussed in one or more additional documents. We expect that this effort will build on the work that has already been done in the msec working group.
15. IANA Considerations
15. IANA Considerations
Experimentation with the Xcast protocol requires the use of protocol numbers maintained by IANA. For example, to implement XCAST6, implementations must agree on four protocol numbers:
Experimentation with the Xcast protocol requires the use of protocol numbers maintained by IANA. For example, to implement XCAST6, implementations must agree on four protocol numbers:
(1) Multicast Address for All_Xcast_Routers
(2) Routing Type of IPv6 Routing Header
(3) Option Type of IPv6 Destination Option Header
(4) Option Type of IPv6 Hop-by-Hop Options Header
(1) Multicast Address for All_Xcast_Routers (2) Routing Type of IPv6 Routing Header (3) Option Type of IPv6 Destination Option Header (4) Option Type of IPv6 Hop-by-Hop Options Header
A protocol implementer may temporarily experiment with Xcast by using the values set aside for experimental use in RFC [4727]. An implementer must verify that no other experiment uses the same values on the Xcast testbed at the same time.
A protocol implementer may temporarily experiment with Xcast by using the values set aside for experimental use in RFC [4727]. An implementer must verify that no other experiment uses the same values on the Xcast testbed at the same time.
A future revision of the Xcast specification published on the standards track is required before IANA can assign permanent registry entries for Xcast. Implementers should be aware that they will need to modify their implementations when such permanent allocations are made.
A future revision of the Xcast specification published on the standards track is required before IANA can assign permanent registry entries for Xcast. Implementers should be aware that they will need to modify their implementations when such permanent allocations are made.
Boivie, et al. Experimental [Page 30] RFC 5058 Xcast Concepts and Options November 2007
Boivie, et al. Experimental [Page 30] RFC 5058 Xcast Concepts and Options November 2007
16. Informative References
16. Informative References
[1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
Service", RFC 1546, November 1993.
[1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
Addresses", RFC 2526, March 1999.
[2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC
3068, June 2001.
[3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[1075] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector
Multicast Routing Protocol", RFC 1075, November 1988.
[1075] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[1770] Graff, C., "IPv4 Option for Sender Directed Multi-Destination
Delivery", RFC 1770, March 1995.
[1770] Graff, C., "IPv4 Option for Sender Directed Multi-Destination Delivery", RFC 1770, March 1995.
[1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October
1996.
[2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[2201] Ballardie, A., "Core Based Trees (CBT) Multicast Routing
Architecture", RFC 2201, September 1997.
[2201] Ballardie, A., "Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997.
[2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[2902] Deering, S., Hares, S., Perkins, C., and R. Perlman,
"Overview of the 1998 IAB Routing Workshop", RFC 2902, August
2000.
[2902] Deering, S., Hares, S., Perkins, C., and R. Perlman, "Overview of the 1998 IAB Routing Workshop", RFC 2902, August 2000.
[3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002.
[3376] カイン、B.とデアリングとS.とKouvelasとI.とフェナー、B.とA.Thyagarajan、「インターネット集団経営は議定書を作ります、バージョン3インチ、RFC3376、2002年10月。」
[3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[3740]HardjonoとT.とB.ウィス、「マルチキャストグループセキュリティー体系」、RFC3740、2004年3月。
Boivie, et al. Experimental [Page 31] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[31ページ]RFC5058Xcast概念とオプション2007年11月
[4301] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[4301] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[4302] ケント、S.、「IP認証ヘッダー」、RFC4302、2005年12月。
[4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
RFC 4607, August 2006.
[4607] ホルブルックとH.とB.カイン、「IPのためのソース特有のマルチキャスト」、RFC4607、2006年8月。
[4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[4727] フェナー、B.、「IPv4、IPv6、ICMPv4、ICMPv6、UDP、およびTCPヘッダーの実験値」、RFC4727、2006年11月。
[AGUI] L. Aguilar, "Datagram Routing for Internet Multicasting",
SIGCOMM '84, March 1984.
「インターネットマルチキャスティングのためのデータグラムルート設定」、SIGCOMM1984年3月84年の[阿久比]L.アギラル。
[CHER] David R. Cheriton, Stephen E. Deering, "Host groups: a
multicast extension for datagram internetworks", Proceedings
of the ninth symposium on Data communications, p. 172-179,
September 1985, Whistler Moutain, British Columbia, Canada.
[シェール]デヴィッドR.Cheriton、スティーブン・E.デアリング、「グループをホスティングしてください」 「データグラムインターネットワークのためのマルチキャスト拡大」、Dataコミュニケーション、pに関する9番目のシンポジウムのProceedings。 172-179、1985年9月、口笛を吹く人Moutain、ブリティッシュコロンビア、カナダ。
[BOIV] Boivie, R. and N. Feldman, "Small Group Multicast", Work in
Progress, February 2001.
[BOIV] 「小さいグループマルチキャスト」というBoivie、R.、およびN.フェルドマンは進歩、2001年2月に働いています。
[DEER] S. Deering, "Multicast Routing in a datagram internetwork",
PhD thesis, December 1991.
[DEER]S.デアリング、「データグラムインターネットワークにおけるマルチキャストルート設定」、博士論文、1991年12月。
[DEE2] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and
L. Wei, "The Pim Architecture for Wide-area Multicast
Routing", ACM Transactions on Networks, April 1996.
[DEE2] S.デアリング、D.Estrin、D.ファリナッチ、V.ジェーコブソン、C.リュウ、およびL.ウェイ、「広い領域マルチキャストルート設定のためのPim構造」、ネットワーク(1996年4月)におけるACM取引。
[FARI] Farinacci, D., et al., "Multicast Source Discovery Protocol",
Work in Progress, June 1998.
[FARI] ファリナッチ、D.、他、「マルチキャストソース発見プロトコル」、Progress、1998年6月のWork。
[H323] ITU-T Recommendation H.323 (2000), Packet-Based Multimedia
Communications Systems.
[H323] ITU-T推薦H.323(2000)、パケットベースのマルチメディア通信システム。
[IMAI] Imai, Y., "Multiple Destination option on IPv6 (MDO6)", Work
in Progress, September 2000,
[イマイ]イマイ、Y.、「IPv6(MDO6)における複数のDestinationオプション」、Progress、2000年9月のWork
[MBONE] Casner, S., "Frequently Asked Questions (FAQ) on the
Multicast Backbone (MBONE)",
<ftp://ftp.isi.edu/mbone/faq.txt>.
[MBONE] Casner、S.、「マルチキャスト背骨(MBONE)の上のよく出る質問(FAQ)」、<ftp://ftp.isi.edu/mbone/faq.txt>。
[OOMS] Ooms, D., Livens, W., and O. Paridaens, "Connectionless
Multicast", Work in Progress, April 2000.
[オームス]オームス、D.、賑す、4月2000、W.、および「コネクションレスなマルチキャスト」というParidaensが中で扱うO.は進歩をします。
[PARI] Paridaens, O., Ooms, D., and B. Sales, "Security Framework
for Explicit Multicast", Work in Progress, June 2002.
[PARI] Paridaens、O.、オームス、D.、およびB.販売、「明白なマルチキャストのためのセキュリティフレームワーク」は進歩、2002年6月に働いています。
Boivie, et al. Experimental [Page 32] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[32ページ]RFC5058Xcast概念とオプション2007年11月
[RMT] Reliable Multicast Transport Working Group web site,
<http://www.ietf.org/html.charters/rmt-charter.html>, June
15, 1999.
[RMT]信頼できるMulticast Transport作業部会ウェブサイト、<http://www.ietf.org/html.charters/rmt-charter.html>、1999年6月15日。
[SOLA] M. Sola, M. Ohta, T. Maeno, "Scalability of Internet
Multicast Protocols", INET'98,
<http://www.isoc.org/inet98/proceedings/6d/6d_3.htm>.
[SOLA] M.Sola、M.太田、T.マエノ、「インターネットマルチキャストプロトコルのスケーラビリティ」、INET98年、<http://www.isoc.org/inet98/議事/6d/6d_3.htm>。
17. Contributors
17. 貢献者
Olivier Paridaens Alcatel Network Strategy Group Fr. Wellesplein 1, 2018 Antwerpen, Belgium Phone: 32 3 2409320 EMail: Olivier.Paridaens@alcatel.be
オリビエParidaensアルカテルネットワーク戦略グループフラン。 Wellesplein1、アントウェルペン(ベルギー)が電話をする2018: 32 3 2409320 メール: Olivier.Paridaens@alcatel.be
Eiichi Muramoto Matsushita Electric Industrial Co., Ltd. 4-12-4 Higashi-shinagawa, Shinagawa-ku Tokyo 140-8587, Japan Phone: +81-3-6710-2031 EMail: muramoto@xcast.jp
Eiichi Muramoto松下電器4-12-4Higashi-shinagawa、品川区東京140-8587(日本)は以下に電話をします。 +81-3-6710-2031 メールしてください: muramoto@xcast.jp
Boivie, et al. Experimental [Page 33] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[33ページ]RFC5058Xcast概念とオプション2007年11月
Authors' Addresses
作者のアドレス
Rick Boivie IBM T. J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 Phone: 914-784-3251 EMail: rhboivie@us.ibm.com
リックBoivie IBM T.J.ワトソン研究所19の地平線Driveホーソーン、ニューヨーク 10532は以下に電話をします。 914-784-3251 メールしてください: rhboivie@us.ibm.com
Nancy Feldman IBM T. J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 EMail: nkfeldman@yahoo.com
ナンシーフェルドマンIBM T.J.ワトソン研究所19の地平線Driveホーソーン、ニューヨーク 10532はメールされます: nkfeldman@yahoo.com
Yuji Imai Fujitsu Laboratories Ltd. 1-1, Kamikodanaka 4-Chome, Nakahara-ku Kawasaki 211-8588, Japan Phone: +81-44-754-2628 Fax : +81-44-754-2793 EMail: ug@xcast.jp
1-1に、Kamikodanaka4丁目の中原区川崎211-8588(日本)が電話をするYujiイマイ富士通研究所: +81-44-754-2628 ファックスで以下を送ってください。 +81-44-754-2793 メールしてください: ug@xcast.jp
Wim Livens ESCAUX Krijtstraat 17, 2600 Berchem, Belgium EMail: wim@livens.net
ヴィムはESCAUX Krijtstraat17、2600Berchem、ベルギーメールを賑します: wim@livens.net
Dirk Ooms OneSparrow Belegstraat 13; 2018 Antwerp, Belgium EMail: dirk@onesparrow.com
短剣オームスOneSparrow Belegstraat13。 2018年のアントワープ(ベルギー)メール: dirk@onesparrow.com
Boivie, et al. Experimental [Page 34] RFC 5058 Xcast Concepts and Options November 2007
Boivie、他 実験的な[34ページ]RFC5058Xcast概念とオプション2007年11月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78とwww.rfc-editor.org/copyright.htmlに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Boivie, et al. Experimental [Page 35]
Boivie、他 実験的[35ページ]
一覧
スポンサーリンク
