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
Explicit Multicast (Xcast) Concepts and Options
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は、いかなる目的のためにと、公開する決定が展開されたプロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFレビューに基づいていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。詳細については、RFC 3932を参照してください。
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マルチキャストのスキーム（RFC 1112）は、非常に大きなマルチキャストグループのためのスケーラブルであるが、それらは別々のマルチキャストグループの非常に大きな数のスケーラビリティの問題を持っています。この文書はのXcast（明示的なマルチユニキャスト）、補完的なスケーリング特性を持つ新しいマルチキャスト方式について説明しますのXcastは小さなマルチキャストセッションの非常に大きな数をサポートしています。 XCASTは、明示的にデータパケット内の宛先のリストをコード化するのではなく、マルチキャストグループアドレスを使用してこれを実現しています。
This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification.
この文書では、いくつかの分野でのXcastの概念とオプションについて説明します。それは完全な技術仕様を提供していません。
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
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を記述する（明示的なマルチユニキャスト（の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".
目的地の非常に多く、そしてかなり小さいグループ[BOIV]にデータを送信し、「ナロー」マルチキャストにデータを送信し、放送のようなマルチキャスト：マルチキャストの二種類が重要であると思われます。最初の例では、企業のイントラネット内のすべての従業員へのプレゼンテーションのオーディオおよびビデオマルチキャストです。第二の例は、3人のまたは4つの当事者が関与するビデオ会議です。下記の理由から、この2つのケースのために異なるメカニズムを使用することが賢明と思われます。リライアブルマルチキャスト交通ワーキンググループとして述べている：[RMT]「プロトコルのすべてのアプリケーションの要件を満たすことができません 『ワンサイズは、すべてが収まる』と考えられています」。 「たとえば、ひどく現在のマルチキャストモデルを与えられたスケール大域的な位相範囲と小さな会議（広く分散した人の数が少ない）の多くのグループを提供する」：1998 IABルーティングワークショップ[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.
今日のマルチキャスト方式では、帯域幅の消費を最小限にするために使用することができます。マルチユニキャスト（のXcast）明示的にも、「小グループ」のための帯域幅の消費を最小限にするために使用することができます。しかし、それは同様にさらなる利点を有します。 XCASTは、セッション毎のシグナリングと伝統的なIPマルチキャストの方式のセッションごとの状態情報を排除し、これは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 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].
これはすぐに独立して1990年代後半に、それを再発明した三つのグループに知られていなかったが、興味深いことに、のXcastのためのアイデアは、いくつかの時間を回避されています。実際には彼の1984 SIGCOMM紙でロレンツォ・アギラールにより、インターネットコミュニティにおけるマルチキャスト概念の非常に最初の提案は、[AGUI]以下でより詳細に議論の目的地の明示的なリストを使用することを提案しました。ほぼ同時に、デビッド・チェリトンとスティーブンデアリングは[CHER] 1985年にホストグループマルチキャストを開発しました。
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.
インターネットコミュニティは、二つの提案を比較し、単一のメカニズムが複数の機構に好適であると結論付けました。アギラールの提案は、深刻なスケーリングの問題を持っているように見えたので、ホストグループモデルが採用されました。
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.
しかし、以下の理由のために、我々はそれが、上述のマルチキャストの二つの異なる種類の異なるメカニズムを使用することは理にかなって考えています。ホストグループマルチキャストは1985年のインターネットで十分だったかもしれないが、我々はのXcastは、21世紀のインターネットでは、グループマルチキャストをホストするための重要な補完することができると信じています。
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.
ホストグループモデルでは、パケットは、すべてのグループメンバーの論理識別子としてマルチキャストアドレスを運びます。 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).
左一つだけ先がある場合、のXcastパケットは、経路の残りの部分に沿ってユニキャストすることができ、通常のユニキャストパケットに変換することができます。これは、X2U（ユニキャストへの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に分配パケットを取得しようとしていると仮定する。
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.
これは以下のように達成される：Aは最初のルータ、R1に対するのXcastヘッダ内の宛先のリストとの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 | DEST = B 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.
- 前のステップで見つかった次のホップのそれぞれについて、パケットのコピーがありますように、パケットを複製します。
- 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).
- 最適化：特定の次のホップのための唯一の宛先が存在する場合、パケットは、宛先（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に単一パケットを送信します。
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リストとネクストホップR5にパケットのコピーを送信すると、1つの通常のユニキャストパケットはR4に<B>宛て。 R4は、標準のユニキャストパケットを受信し、<B>にそれを転送します。 R5は、それがR7にそれを渡すだろうR6、へ受け取りのXcastパケットを転送します。パケットが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.
これは、与えられた次のホップに送られるの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チャネルのためのルーティングは自動的に新しいトポロジーに適合することに注意してください。
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]は非常に大規模なマルチキャストグループを処理するように設計されました。 1は、世界中の放送のようなチャンネルを配布しようとしている場合、これらはうまく動作しますが、グループの非常に数が多いときには、スケーラビリティの問題を抱えています。
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.
ホストグループモデル[DEER]とマルチキャストルーティングプロトコル：伝統的なIPマルチキャストモデルの特性は、その2つの要素によって決定されます。両方のコンポーネントは、ユニキャストからマルチキャストは非常に異なって作ります。
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:
ホストグループモデルでは、ホストのグループは、両方のサブスクリプションおよび転送のために使用されるマルチキャストグループアドレスによって識別されます。このモデルは、主に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)).
- マルチキャストアドレスの割り当て：マルチキャストグループの作成者が（スコープしばしばグローバルになります）、その範囲内で一意であるマルチキャストアドレスを割り当てる必要があります。この問題は、マルチキャストアドレス割り当てサーバ（MAAS）と3つのプロトコル（マルチキャストアドレスセットクレーム（MASC）のセットを提案しているMALLOCワーキンググループによって対処されている、アドレス割り当てプロトコル（AAP）、マルチキャスト（動的クライアント割り当てプロトコルアドレスMADCAP））。
- 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:
ホストグループモデルに加えて、ルーティングアルゴリズムは、加盟国及び配信ツリーを維持するために必要とされます。これは、（切り捨て）ブロードキャストアルゴリズムまたはマルチキャストアルゴリズム[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]）。
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).
マルチキャストアドレスの割り当て、先の無自覚と上記のスケーラビリティの問題のコストは、他のマルチキャストスキームの検索につながります。ソース固有マルチキャスト（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
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のために、これらの制限は存在しません。
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の設計を導いた原則であり、それは可能なインターネットの信じられないほどの成長をした原則です。例えば、インターネットは非常によく比例することができた理由の一つは、その個々のホストまたは個々の「接続」とは対照的に、大規模なクラスレスドメイン間ルーティング（CIDR）ブロックとネットワーク取引のコア内のルータ。コア内のルータは、それらを通過している個々のTCP接続を追跡する必要はありません。同様に、IETFのDiffservの努力は、ルータがそれらを通過する可能性がある個々のリソース予約プロトコル（RSVP）フローの多数のトラックを保持する必要はありませんという考えに基づいています。これは、コア内のルータはどちらか、個々のマルチキャストフローの多数を追跡する必要はありません著者の信念です。
Compared to traditional IP multicast, Xcast has the following advantages:
従来のIPマルチキャストと比較すると、のXcastは、次のような利点があります。
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マルチキャストルーティングプロトコルは、非最短経路ツリーを作成します。これは、インターネット内のパスの数の増加が非対称であることが期待される（パスは、AにBからの最短経路と同様にAからBへの最短パスの両方である場合、2つのノードAとBとの間の経路が対称的です）トラフィックエンジニアリングとポリシールーティングの結果として、将来的には、したがって、従来のIPマルチキャスト方式は、次善のルーティングの増加量になります。
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にすべてのソースは、例えば、特定のメンバーを拒否するか、非常に簡単に特定のメンバーへ向かうトラフィックをカウントするソースに手段を与えマルチキャストチャネルのメンバーを知っています。ソース、だけでなく、境界ルータは、パケットがそのドメインに複製されます回数を決定することができるだけではなく。また、送信者の数や送信者ごとの帯域幅を制限することが容易になります。
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のコードポイント（DSCPを）のリストを含めることができます。従来の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: 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.
2）より複雑なヘッダ処理。パケット内の各宛先は、ルーティングテーブルのルックアップを必要とします。したがって、n個の宛先とのXcastパケットは、n個のユニキャストヘッダーとしてルーティングテーブルルックアップの同じ数を必要とします。さらに、異なるヘッダが次のホップごとに構築されなければなりません。しかしなお：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）フォワーディングテーブル転送における凝集と組み合わせて、宛先のリストの階層符号化を使用することにより、[OOMS】加速することができます。
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）は、パケットが早期のX2Uで変換することができます。ルータは、ユニキャストパケットに1つの以上の宛先のためのXcastパケットを変換することを決定したときに早期の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）の処理を低減する他の機構は、[今井（扱いやすいリストに記載されている）および[OOMS]（キャッシュ）が、）まだ（のXcast仕様の一部ではありません。
3) Xcast only works with a limited number of receivers.
3）のXcastは、受信機だけの限られた数で動作します。
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 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は住宅のユーザーは、ビデオ会議を設定します。典型的には、アクセス技術が非対称である（例えば、xDSLの、汎用パケット無線サービス（GPRS）、またはケーブルモデム）。だから、xDSL回線を持つホストは、n-1基本的な100キロバイト/ sのビデオチャネルを受信問題はないが、ホストは、このレートで独自の映像データ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パケットを送信し、最初のルータは、早期の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マルチキャストモデルを置き換えることはありませんが、小さなセッションの非常に大きな数字があることができたときには、マルチポイント・ツー・マルチポイント通信のための代替手段を提供しません。
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マルチキャストの代わりにユニキャストを使用することにより、帯域幅の消費が減少セッション増加当たり状態とシグナリングします。 XCASTは、これらの二次元0のコストを有するが、それは、パケットごとにヘッダ処理に対応する第3の次元を導入しません。この3次元空間は、図3に示されています。
state&signaling
per session
in router
^
|
|
....
B | ....
. | ....
. | ....
. | ....
. +------------------..---> processing
. / .... C per packet
. / ..... in router
. / .....
. / .....
./ .....
/A....
/
/
link bandwidth
Figure 3
図3
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個の宛先にソースから同一の情報を配信する方法の一つは、（図3のA）の情報をn回ユニキャストすることです。第二の方法は、従来の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.
不幸の保全の面：A、B、及びCは、（図3においてドットで示す）の平面を定義する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の一つの利点は、ルータがネットワーク内のその位置に基づいて、悲惨の保全のこの平面内で移動することを可能にすることです。例えば、ネットワークのコアにおいて、キャッシュは、任意のフローごとのシグナリングを導入することなく、BにCから線に沿って移動するために使用することができます。上記で示唆したように別の可能性は、バックボーンにおける帯域幅の豊富がある場合、アクセスネットワーク内にCから線に沿って移動するように早期X2Uを使用することです。
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は、「コントロールプレーン」を指定していません。全くインターネットグループ管理プロトコル（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の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.
- いくつかのアプリケーションでは、セッションのメンバーは、コマンドラインの引数として指定される可能性があります。
- 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]を含む、定義されています。
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サーバの助けを借りて、セッションが作成されます。セッション状態をホストに保たれています。噛合ユニキャスト、ブリッジ、またはマルチキャスト：データ配信は、いくつかのメカニズムによって達成することができます。マルチキャスト配信、マルチキャストアドレス割り当てサーバ（MAAS）とマルチキャストプロトコルとの通信の確立のためになおが依然として必要とされています。
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.
では、アプリケーションが参加者のユニキャストアドレスを追跡し、これらのアドレスのそれぞれにユニキャストを送信し、「マルチユニキャスト」または「ユニキャスト噛み合っ」。セクション3で説明する理由のために、マルチユニキャスト（よりむしろマルチキャスト）使用中の優勢溶液が今日あります。それはのXcastコードでマルチユニキャストコードを交換することは簡単なことです。開発者が関係しているすべてのことは、参加者にデータを送るシングル「xcast_send」により、参加者のそれぞれにユニキャストを送信したループを交換です。したがって、実際の会議アプリケーションへの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（非常に柔軟な制御プレーンプロトコル）と統合することができることが分かります。アプリケーションは、SIPエージェントへのインタフェースには影響しませんフォワーディングのXcastを使用することを決定したとき：それはマルチユニキャストの場合と同じように、それは同じSIPメッセージを使用することができます。 SIPは、発信者が複数の関係者に電話をかけている上記の会議のモデルをサポートするための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 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.
前のセクションでは、マルチパーティ会議のよく知られ、参加者間のXcastセッションを確立する方法を説明しました。参加者が招待されずにセッションに参加できるようにするためにいくつかのケースでは、それは便利です。例えば、ビデオチャットの会長は、新規参入者のためのオープン会談のドアを残しておきたいことがあります。 IGMPのような受信機が開始し、上記のモデルは会議に参加するために話すことができるホストするサーバーを導入することで実現できる参加。
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に、トランスポート層ヘッダの宛先ポート番号は、ユニキャストパケットの宛先に対応するポート番号に設定されます。
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のコードポイント（DSCPを）のリストを含めることができます。従来のIPマルチキャストプロトコルは、各サービス・クラスのために別々のグループを作成する必要がありますが、のXcastは、一つのチャンネル内の異なるサービス要件のレシーバを持つ可能性が組み込まれています。
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は、DSCPをリストの最も要求の厳しい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つの宛先は、「非マージ可能」のDSCPをお持ちの場合は、2つのXcastパケットが作成されます。 「非マージ可能な」1は1が多かれ少なかれ厳格以外であると言うことができないことを意味します。
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ヘッダ内の余分な数を追加することを決定することができます。ソースは、このオプションを使用したくない場合は、ゼロにチャネル識別子を設定する必要があります。チャネル識別子が非ゼロである場合、対（ソースアドレス、チャネル識別子）が一意に（これは、SSMに（S、G）ペアに類似していることに注意）チャネルを識別しなければなりません。この文書では、上記1以外のチャネル識別子に他の意味を割り当てることはありません。
This Channel Identifier could be useful for several purposes:
このチャネル識別子は、いくつかの目的のために有用であろう：
1) A key to a caching table [OOMS].
キャッシュ表1）鍵[OOMS]。
2) "Harmonization" when used with Host Group Multicast (to be discussed in greater detail in another document).
2）ホストグループマルチキャスト（別の文書で詳細に説明される）で使用される「調和」。
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) ...
５） 。。。
The size of the channel identifier and its semantics are TBD.
チャネル識別子の大きさとその意味は未定です。
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送信者のアドレスが含まれています。宛先アドレスフィールドは、（リンクローカルマルチキャストアドレスを割り当てる）オールの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認証ヘッダ（AH）[4302]は、したがって、そのフィールドへの変更を防止する、IPヘッダの宛先アドレスをカバーします。また、AHSおよびカプセル化セキュリティペイロード（ESPの）両方が（認証および/または暗号化を経由して）全体の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において、ルーティング拡張を使用しなければなりません。パケットはこのルータ宛てされている場合は、このヘッダ拡張は、唯一のルータによってチェックされます。これはAll_Xcast_Routersグループの全てのXcastルータ部分を作ることによって達成されます。
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とこれ組み合わせ可能ではない）に達するまで、マルチキャストアドレスが宛先フィールド内に留まるとき、いくつかの利点のみを保持することに注意してください。
[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.
【AGUI]及び[1770]のIPv4オプションで複数の宛先に運ぶために（わずかに異なる目的のために）を提案しました。しかしため限られた柔軟性（ヘッダの限られたサイズ）、のXcastは別のアプローチに従います。宛先リストは、別個のヘッダ内に符号化されます。 IPv4用のXcastヘッダは（Xcast4、ショートで）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.
Xcastヘッダは、送信者がIP断片化を回避したい場合、それは考慮のXcastヘッダのサイズを取る必要があり、パケットのデータ部分に付加されているので、またことに留意されたいです。
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ヘッダは、RFC 4727で実験目的のために使用できるように記載されているプロトコル番号[4727]を運びます。送信元アドレスフィールドがのXcast送信者のアドレスが含まれても、第15項を参照してください。宛先アドレスフィールドはAll_Xcast_Routersアドレスを運びます。
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.
固定部（第12オクテット）と固定部によって指定された2つの可変長部分：Xcast4ヘッダは、それが2つの部分から構成されている図4に示されているフォーマットです。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
図4
VERSION = Xcast version number. This document describes version 1.
VERSION =の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]が印加されたとき、このビットは有用であり得ます。このビットがクリアされている場合の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.
チェックサムは、唯一のXcastヘッダのチェックサムを=。これは、のXcastヘッダが処理される各ポイントで検証及び再計算されます。チェックサムフィールドは、ヘッダ内のすべてのバイトの1の補数和の16ビットの1の補数です。チェックサムを計算する目的のために、チェックサムフィールドの値はゼロです。これは、チェックサムが（さらなる研究のために）必要とされているかどうかはまだ明らかではありません。唯一つの宛先が間違っている場合、まだN-1、正しい宛先および1つの間違った宛先にパケットを転送するために有用であることができます。
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.
最初の変数の部分は「アドレスとのDSCPのリスト」で、第二の可変部分は、「ポート番号のリスト」です。両方の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):
図5は、（この例では、Nが奇数である）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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
図5
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オクテットの宛先ポート番号（複数可）のリスト。
The Xcast6 header encoding is similar to IPv4, except that Xcast information would be stored in IPv6 extension headers.
XCAST6ヘッダ符号化はのXcast情報は、IPv6拡張ヘッダに格納されることを除いて、IPv4のと同様です。
[IPv6 header | Xcast6 | transport header | payload ]
[IPv6ヘッダ| XCAST6 |トランスポートヘッダ|ペイロード]
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値「ルーティング拡張」を運びます。送信元アドレスフィールドには、のXcast送信者のアドレスが含まれています。宛先アドレスフィールドはAll_Xcast_Routersアドレスを運びます。
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ヘッダは、固定部と二つの可変部分から構成されています。固定部と第1の可変部は、ルーティング拡張で搬送されます。第二の可変部分は先の拡張で運ばれます。
The P-bit of Xcast4 is not present because it is implicit by the presence or absence of the Destination Extension (Figure 6).
それは先の拡張（図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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6
図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は、ヘッダ長が8オクテットで表され=。従って、127件の宛先の最大値は（NBR_OF_DESTが7ビットである理由である）を挙げることができます。
RouteType = Xcast (see Section 15)
RouteType =のXcast（セクション15を参照）
The fourth octet is set to 0.
4番目のオクテットは0に設定されています。
R = Reserved.
R =予約。
CHANNEL IDENTIFIER = 16-octet Channel Identifier (see Section 8.3).
CHANNEL IDENTIFIER = 16オクテットチャネル識別子（8.3節を参照してください）。
The other fields are defined in Section 9.2.2.
他のフィールドは、セクション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.
「アドレスとのDSCPの一覧は、」整列8オクテットです。ビットマップのサイズは、宛先の数によって決定され、64ビットの倍数です。
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.
必要に応じて、先の拡張（図7）は、ポート番号のリストを指定するために存在しています。先ヘッダのみ、宛先ノードによって評価されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | HdrExtLen |Opt Type=Ports | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| List of Port Numbers |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7
図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.
ポートのオプションタイプの場合、最初の3ビット第15項を参照のオプションが不明であり、オプションはエンルート変更することができないという場合にパケットを廃棄しなければならないことを示すために、010でなければなりません。
The number of Ports must be equal to the number of destinations specified in the Routing header.
ポートの数は、ルーティングヘッダで指定された宛先の数に等しくなければなりません。
Some fields in the Xcast header(s) can be modified as the packet travels along its delivery path. This has an impact on:
パケットがその送達経路に沿って移動するのXcastヘッダ（S）の一部のフィールドを修正することができます。これは上の影響があります。
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).
トランスポート層のヘッダに、チェックサム計算の対象は、IP擬似ヘッダー、トランスポートヘッダー、及びペイロード（IPv6ヘッダ拡張が対象ではない）を含みます。
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:
通常のユニキャストパケットへのXcastパケットの変換 - （早期）X2Uは、 - 最終的な宛先のアドレスでIPヘッダの宛先フィールドにマルチキャストアドレスを置き換えます。 Xcastヘッダは、ポートリストが含まれている場合は、（ゼロでなければならない）、トランスポート層のポート番号は、宛先に対応するポート番号を交換する必要があります。これは、これらのチェックサムの再計算を必要とします。 IPv4のために、例えば、これはチェックサムの完全な再計算を必要としないことに注意してください、唯一のデルタ計算：
Checksum' = ~ (~Checksum + ~daH + ~daL + daH' + daL' + ~dp + dp')
チェックサム '=〜（〜サム+〜+〜DAH DAH DAL +' + 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.
ここで、「'」は、それぞれ、送信先アドレス、 『DP』、宛先ポート、および 『H』と 『L』 『DA』、上位と下位16ビットを新たな値を示しています。
This is described in [PARI].
これは、[PARI]に記載されています。
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.
Xcastの知識を持っていないルータを有するネットワーク内のXcastを展開する一つの方法は、のXcastピア（あるMBoneアプローチ[MBONE]）との間のセットアップ「トンネル」です。これは、既存のネットワーク[2003]の上に重ね仮想ネットワークを作成することができます。 Xcastルータの交換とは、任意の標準的なユニキャストルーティングプロトコル（例えば、RIP、OSPF、IS-IS、BGP）を介してのXcastルーティング情報を維持します。作成されたのXcastルーティングテーブルは、単にそれらに対応するのXcastの次ホップと一緒に、のXcastの接続性を持っている目的地が含まれている標準のユニキャストルーティングテーブルです。このように、パケットは、他のXcastルータにホップバイホップに転送してもよいし、ネットワーク内の非のXcastルータを介して「トンネリング」することができます。
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:
例えば、Aが「X」ルータはのXcast対応している以下の図8にB、C、およびDに分配パケットを取得しようとしていることを想定し、「R」ルータではありません。図9は、のXcastトンネルを介して作成したルーティングテーブルを示します。
R4 ---- B
/
/
A ----- X1 ---- R2 ---- X3 R8 ---- C
\ /
\ /
R5 ---- R6 ---- X7
\
\
R9 ---- D
Figure 8
図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.
ルータX1はのXcastピアX3へのトンネルを確立します。ルータX3はのXcastピアX1とX7へのトンネルを確立します。ルータX7はのXcastピア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
Figure 9
図9
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:
ソースAは、パケットの宛先のリストが含まれ、デフォルトのXcastルータ、X1へのXcastパケットを送信します。 X1とX3との間のリンク上のパケットは、図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 |
+----------+
Figure 10
図10
When X3 receives this packet, it processes it as follows:
X3は、このパケットを受信すると、以下のように、それを処理します。
- 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.
- パケットに記載されている目的地のそれぞれについてのXcast次のホップを決定するためのXcastルーティングテーブルにルートテーブルルックアップを実行します。
- If no Xcast next hop is found, replicate the packet and send a standard unicast to the destination.
- 何のXcastの次ホップが見つからない場合は、パケットを複製し、宛先に標準ユニキャストを送信します。
- For those destinations for which an Xcast next hop is found, partition the destinations based on their next hops.
- のXcastの次ホップが発見されたものを宛先の場合、彼らの次のホップに基づいて目的地を分割します。
- Replicate the packet so that there's one copy of the packet for each of the Xcast next hops found in the previous steps.
- 前のステップで見つかったのXcastの次ホップのそれぞれについて、パケットのコピーがありますように、パケットを複製します。
- 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 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.
- 最適化：特定のXcastの次ホップのための唯一の宛先が存在する場合のXcastパケットとして転送する全く利点がないので、目的地までの標準的なユニキャストパケットとしてパケットを送信します。
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.
したがって、上記の例では、X1は、<B C D>の宛先リストとX3の上の単一のパケットを送信します。このパケットは、宛先X3とユニキャストパケットとしてR2によって受信され、R2は、のXcastの知識を有していない、それを転送します。 X3がパケットを受信すると、それは、上記のアルゴリズムにより、<C、D>の宛先リストとX7に通常のユニキャストパケットとして宛先<B>へのパケットの一つのコピー、およびパケットの1つのコピーを送信します。 R4、R5、及びR6は、のXcastの知識と同様に、標準的なルータを動作します。 X7がパケットを受信すると、パケットを解析し、通常のユニキャストパケットは、それぞれ、<C>と<D>宛て送信します。
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.
このルートテーブルの更新は、ドメイン内の環境でシンプルながら、ドメイン間環境ではより複雑になります。このように、ドメイン間環境でのトンネリングを使用することは、さらに検討が必要です。
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.
ルータはその下流ネイバーができるXCASTされていないことを検出した場合、それはつまり、ネクストホップとしてこの隣人を持つのXcastヘッダ内の宛先毎にユニキャストパケットを送信し、早期のX2Uを実行することができます。 Xcastパケットは、その実際の分岐点に到達する前にこのように、複製が行われます。
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).
近隣ののXcast能力を発見するメカニズム（プロトコル/プロトコルの拡張）は今後の検討課題です。 （宛先として自身のアドレスが含まれているのXcastパケットを送信し、パケットを返すかどうかを確認してください）他の人の中で、一つはのXcast機能をアドバタイズするルーティングプロトコルの拡張と考えることができ、または1つは、その隣に定期的に「のXcast pingを」送ることができます。
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.
これは、トンネルの（手動）の設定を必要としないという意味で、トンネルの最適化です。これは、ホップバイホップXCAST6ヘッダを追加することによって有効になっています。 IPv6パケットは、IPv6のホップバイホップオプションを使用してオンルートルータに追加の処理をトリガ/開始することができます。
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.
XCAST6を認識できないルータは通常のIPv6データグラムとしてXCAST6データグラムを処理し、IPv6ヘッダーの宛先に向けて転送することができるようにXCAST6ホップバイホップオプションの種類は、プレフィックス「00」を有します。
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.
ソースAが宛先B、C、およびDに半透過トンネルを介してのXcastパケットを送信するとき、それは最終的な目的地の一つは、外側のIPヘッダの宛先アドレスフィールドに配置される図11のパケットを作成します。
+----------+
| 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
図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.
半透過性のトンネリングは、宛先が異なる次のホップを持っている場合、目的地やブランチをチェックするためにトンネル上の中間のXcastルータを許可する特別なトンネリング技術です。
Note that with the introduction of an Xcast IPv4 option, this technique could also be applied in IPv4 networks.
XcastのIPv4オプションの導入により、この技術はまた、IPv4ネットワークに適用できることに留意されたいです。
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.
展開のXcastの特別な方法は、ホストのみをアップグレードすることが可能です。すべてのホストが認識XCASTされたとき、トンネルエンドポイントとして、最終的な目的地とトンネリング（セクション11.1及び11.3を参照）を適用することによって、のXcastパケットは、すべての宛先に配信されます。正常および半透過性の両方のトンネリングを使用することができます。
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.
ホストBは、上記の例では、このパケットを受信した場合、それはのXcastヘッダ内の他の宛先に気づくであろう。 Bは、新規のXcastパケットを作成し、残りの地の一つに送信します。
In the case of Xcast6 and semi-permeable tunneling, Xcast routers can be introduced in the network without the need of configuring tunnels.
XCAST6と半透過トンネルの場合、のXcastルータは、トンネルを設定する必要なく、ネットワークに導入することができます。
The disadvantages of this method are:
この方法の欠点は、以下のとおりです。
- all hosts in the session need to be upgraded.
- セッション内のすべてのホストをアップグレードする必要があります。
- 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).
- 匿名性の問題：ホストが（多分他のアプリケーションのために、会議では大きな問題ではありません）セッション内の他の当事者の身元を知ることができます。
- 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. Xcast-Awareのルータの数が少ないを使用することは、それほど小さくないネットワークでのXcastを提供するために、
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).
このアプローチでは、のXcastパケットは、IPヘッダの宛先フィールドに特別な32ビットのユニキャストアドレスを使用します。この方式の最も単純なバージョンでは、ネットワーク内のみの単一のXcast認識ルータがあるかもしれません。これのXcast認識ルータは他のルータに「サーバ」のように見え、そのIPアドレス（またはそのIPアドレスの1つ）は「特別な」32ビットのアドレスに対応するように設定されています。このように、のXcastクライアントはのXcastパケットを送信するとき、非のXcast対応のルータは、ルートのXcast認識ルータとのXcast認識ルータにこれらのパケットは、ユニキャストパケットの適切なセットにそれらを（X2U）を「爆発」することができます。これは、どこにでも、ネットワーク内のクライアントがのXcast対応ルータの最小数（即ち、1）と「ファーストマイル」に制限された帯域幅の問題を克服するためのXcastを使用することを可能にします。
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.
別の可能性は、ネットワーク内の様々なポイントで、これらのXcast対応ルータの数を展開するために、特別な32ビットアドレスでこれらのそれぞれを構成することです。これは、単一障害点を排除し、冗長性を提供し、のXcastパケットは、ネットワークの待ち時間を減らすこと、のXcast認識ルータに到達するために移動する必要がある距離を低減します。この場合、のXcast対応ルータは、「マルチホーム」である単一のサーバーであるように見える（すなわち、複数の場所でネットワークに接続されている）と非対応のXcastルータは、通常のユニキャストルーティングを介して、パケットを配信しますそれは、最短利用可能経路を介して、この「マルチホーム仮想サーバー」に宛てています。
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:
グループ内の任意のホストにパケットを送達するこの方式はまた、「エニーキャスト」として知られており、RFCの[1546]、[2526]及び[3068]に詳細に記載されていることに留意されたいです。あまりにもRFC 1546が言うに注意してください：
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.
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.
Xcastの最も簡単な使用では、のXcastパケットの最終目的地は、通常のユニキャストUDPパケットを受け取ります。これは、ホストが標準、無修正TCP / IPスタックとのXcastパケットを受信できることを意味します。
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.
また、ホストは、生のソケット上のXcastパケットを送信する小規模のXcastライブラリと標準のTCP / IPスタックとのXcastパケットを送信することができます。これは、任意のカーネルの変更なしで両方のUnixおよびWindowsプラットフォーム上のXcastベースのアプリケーションを実装するために使用されてきました。
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.
別の可能性はわずかソケット・インタフェースを変更することです。例えば、一つは「のsendto」のように働く「xcast_sendto」機能が追加される場合がありますが、それは「のsendto」は使用している単一のアドレスの代わりに、送信先アドレスのリストを使用しています。
Additional work is needed in several areas.
追加の作業は、いくつかの分野で必要とされています。
Additional details need to be specified. For example, in the IPv4 case, the format of the DSCPs option needs to be specified.
追加の詳細を指定する必要があります。例えば、IPv4のケースにおいて、DSCPをオプションのフォーマットを指定する必要があります。
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.
IPv4とIPv6でのチャネル識別子のサイズは、このドキュメントで異なっています。 32ビットは、IPv6とIPv4の両方のために十分であるかもしれません。
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).
増分展開のいくつかの可能な方法は、トンネリング、時期尚早X2Uなどの追加作業は、ドメイン内だけでなく、のXcastのドメイン間の展開のために、増分展開の最良の手段を決定するために必要とされるなど、このドキュメントで説明されています。トンネリングを使用する場合、追加の詳細を指定する必要がある（例えば、トンネル形式、ドメイン間の場合のトンネルの使用）。
DSCP usage needs some work. DSCPs may have to be rewritten as packets cross inter-domain boundaries.
DSCPの使用量は、いくつかの作業を必要とします。パケットは、ドメイン間の境界を越えるようなDSCPを書き換えなければならないことがあります。
The usage of a different, carried protocol type for IPv4 may cause difficulty in traversing some firewall and NAT products.
異なるの使用量は、IPv4のプロトコルタイプは、一部のファイアウォールやNATの製品を横断する際の困難を引き起こす可能性が運ば。
Given that this is designed for small groups, it might make sense to simply mandate a fixed size for the bitmap.
これは小グループのために設計されていることを考えると、それは単にビットマップのために固定サイズを強制しても意味があります。
The list of destinations in Xcast is provided by an application layer that manages group membership as well as authorization if authorization is desired.
Xcastでの宛先のリストは、許可が必要とされる場合は、グループメンバーシップなどの権限を管理するアプリケーションレイヤによって提供されます。
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.
サービス拒否攻撃のいくつかの形態は、その「効果」を高めるためのXcastを使用することができます。スマーフ攻撃は、例えば、ターゲットがICMPエコー応答を受信するように、パケットの送信元アドレスが攻撃の対象のアドレスに設定されたICMPエコー要求を送信します。 Xcastでは、ICMPエコー要求は、リストの各メンバーがターゲットにエコー応答を送信する可能性があり宛先のリストに送ることができます。
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 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.
対策は、この種の攻撃を回避するために、従来のマルチキャストで撮影されています。それはマルチキャストアドレス宛ICMP要求に応答しないように、ルータやホストを設定することができます。伝統的なマルチキャストアーキテクチャでリバースパス転送のチェックは、これらの攻撃の制限をすることができます。ホストがパケットをそれがホストに到達するまでに、通常のユニキャストパケットであってもよいので、ICMP要求が複数の宛先に対処されたことを認識するためのXcastには、困難であり得ます。一方、ルータは、複数の宛先にICMP要求を送信するために使用されており、それらのパケットをドロップするように構成することができるのXcastパケットを検出することができます。 Xcastは、送信先の短いリストにパケットを送信するので、複数の宛先への攻撃パケットを送信する問題は、従来のマルチキャストにおけるよりも問題が少ないであることにも注意してください。明らかに、機密性および/または認証を提供するためにIPsecを使用すると、さらにこの種の攻撃の危険性を減少させることができます。
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.
安全なグループ通信の問題は、IPマルチキャストベースのグループ通信を確保するためのアーキテクチャを定義しているマルチキャストセキュリティ（MSEC）ワーキンググループ、[3740]によって対処されてきました。このように、グループメンバーシップを管理するグループのメンバーを識別し、認証し、マルチキャストトラフィックの機密性と完全性を保護し、管理し、安全に配布するなどMSECワーキンググループで議論した概念、そしてさわやかなキーの多くは、またのXcastベースのグループ通信に適用されます。そして、同じメカニズムの多くは、適用するように見えます。マルチキャストとのXcastとの間の1つの大きな違いはのXcastヘッダ（またはのXcastヘッダ内に少なくともビットマップ）のXcastパケットがソースから宛先に移動するように変更する必要があるという事実です。これは、IPsecの使用に影響を与え、少なくとものXcastヘッダのビットマップが「可変」フィールドになければならないことを示唆しています。上記のすべての問題に対処するのXcastベースのグループ通信を確保するための完全なソリューションは、1つのまたは複数の追加の文書で説明される追加の作業の対象となります。私たちは、この努力はすでにミリ秒ワーキンググループで行われている作業の上に構築されることを期待しています。
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:
Xcastプロトコルとの実験はIANAによって維持プロトコル番号を使用する必要があります。例えば、XCAST6を実装するために、実装は4つのプロトコル番号に同意する必要があります。
(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.
プロトコルの実装は、一時的に[4727] RFCに実験的使用のために確保された値を使用してのXcastを試すことができます。実装者は、他の実験が同時にのXcastテストベッド上で同じ値を使用していないことを確認する必要があります。
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.
IANAはのXcastのための永続的なレジストリエントリを割り当てることができます前に、標準化過程の上、公開のXcast仕様の今後の改正が必要です。実装者は、このような永久的な配分が行われたとき、彼らは彼らの実装を変更する必要があることに注意する必要があります。
[1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[1546]ウズラ、C.、メンデス、T.、およびW.ミリケン、 "ホストエニーキャストサービス"、RFC 1546、1993年11月。
[2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[2526]ジョンソン、D.とS.デアリング、 "予約済みのIPv6サブネットエニーキャストアドレス"、RFC 2526、1999年3月。
[3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[3068]のHuitema、C.、 "6to4のリレールータのエニーキャストプレフィックス"、RFC 3068、2001年6月。
[1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[1112]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[1075] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[1075] Waitzman、D.、ヤマウズラ、C.、およびS.デアリング、 "距離ベクトルマルチキャストルーティングプロトコル"、RFC 1075、1988年11月。
[1770] Graff, C., "IPv4 Option for Sender Directed Multi-Destination Delivery", RFC 1770, March 1995.
[1770] Graffの、C.、RFC 1770、1995年3月 "送信者監督マルチ先の配達のためのIPv4オプション"。
[1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[1812]ベイカー、F.、エド。、 "IPバージョン4つのルータのための要件"、RFC 1812、1995年6月。
[2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[2003]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。
[2201] Ballardie, A., "Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997.
【2201】Ballardie、A.、 "コアベースツリー（CBT）マルチキャストルーティングアーキテクチャ"、RFC 2201、1997年9月。
[2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[2902] Deering, S., Hares, S., Perkins, C., and R. Perlman, "Overview of the 1998 IAB Routing Workshop", RFC 2902, August 2000.
[2902]デアリング、S.、ノウサギ、S.、パーキンス、C.、およびR.パールマン、RFC 2902 "1998 IABルーティングワークショップの概要"、2000年8月。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[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"、RFC 3376、2002年10月。
[3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[3740] Hardjono、T.とB.ウィス、 "マルチキャストグループのセキュリティアーキテクチャ"、RFC 3740、2004年3月。
[4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[4607]ホルブルック、H.、およびB.カイン、 "IPのためのソース固有のマルチキャスト"、RFC 4607、2006年8月。
[4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[4727]フェナー、B.、RFC 4727、2006年11月 "のIPv4、IPv6の、ICMPv4の、ICMPv6の、UDP、およびTCPヘッダには実験値"。
[AGUI] L. Aguilar, "Datagram Routing for Internet Multicasting", SIGCOMM '84, March 1984.
[AGUI] L.アギラール、 "インターネットマルチキャスティングのためのデータグラムルーティング"、SIGCOMM '84、1984年3月。
[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.
【CHER]デヴィッドR. Cheriton、スティーブンE.デアリング、「ホストグループ：データグラムインターネットワークのためのマルチキャスト拡張」、データ通信に第シンポジウム、P。 172-179、1985年9月、ウィスラーマウンテン、ブリティッシュコロンビア州、カナダ。
[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. Jacobson氏、C.劉、およびL.ウェイ、 "広域マルチキャストルーティングのためのピム・アーキテクチャ"、ネットワーク上のACMトランザクション、1996年4月。
[FARI] Farinacci, D., et al., "Multicast Source Discovery Protocol", Work in Progress, June 1998.
[FARI]ファリナッチ、D.ら、 "マルチキャストソース発見プロトコル"、進歩、1998年6月での作業。
[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.、進歩、2000年9月の作業の "IPv6（MDO6）上の複数の宛先オプション"、
[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.
[OOMS] Ooms、D.、Livens、W.、およびO. Paridaens、 "コネクションレスマルチキャスト"、進歩、2000年4月の作業。
[PARI] Paridaens, O., Ooms, D., and B. Sales, "Security Framework for Explicit Multicast", Work in Progress, June 2002.
[PARI] Paridaens、O.、Ooms、D.、およびB.販売、 "明示的マルチキャストのためのセキュリティフレームワーク" が進歩、2002年6月での作業。
[RMT] Reliable Multicast Transport Working Group web site, <http://www.ietf.org/html.charters/rmt-charter.html>, June 15, 1999.
[RMT]リライアブルマルチキャスト交通ワーキンググループのWebサイトに、<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.ソラ、M.太田、T.前野、 "インターネットマルチキャストプロトコルのスケーラビリティ"、INET'98、<http://www.isoc.org/inet98/proceedings/6d/6d_3.htm>。
Olivier Paridaens Alcatel Network Strategy Group Fr. Wellesplein 1, 2018 Antwerpen, Belgium Phone: 32 3 2409320 EMail: Olivier.Paridaens@alcatel.be
オリヴィエParidaensアルカテル・ネットワーク戦略グループ神父Wellesplein 1、2018年アントワープ、ベルギー電話：32 3 2409320 Eメール：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 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
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スカイラインドライブホーソーン、NY 10532電話：914-784-3251 Eメール：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スカイラインドライブホーソーン、NY 10532 Eメール：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
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
Wim Livens ESCAUX Krijtstraat 17, 2600 Berchem, Belgium EMail: wim@livens.net
ヴィムがESCAUX Krijtstraat 17、2600ベルヘム、ベルギーの電子メールをLivens：wim@livens.net
Dirk Ooms OneSparrow Belegstraat 13; 2018 Antwerp, Belgium EMail: dirk@onesparrow.com
ダークOoms OneSparrow Belegstraat 13。 2018年アントワープ、ベルギーのEメール：dirk@onesparrow.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に及び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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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に情報を記述してください。