[要約] RFC 5058は、明示的なマルチキャスト（Xcast）の概念とオプションに関する情報を提供するものであり、マルチキャスト通信の効率性と信頼性を向上させることを目的としています。
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
明示的なマルチキャスト（Xcast）の概念とオプション
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
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は、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開プロトコルとの不適切な相互作用のIETFレビューに基づいていないことに注意しています。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、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）は、非常に大きなマルチキャストグループでスケーラブルですが、非常に多数の異なるマルチキャストグループでスケーラビリティの問題があります。このドキュメントでは、補完的なスケーリングプロパティを備えた新しいマルチキャストスキームであるXast（明示的なマルチユニカスト）について説明します。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]は、非常に大きなマルチキャストグループでスケーラブルですが、非常に多数の異なるマルチキャストグループでスケーラビリティの問題があります。このドキュメントでは、補完的なスケーリングプロパティを備えた新しいマルチキャストスキームであるXast（明示的なマルチユニカスト（Xcast））について説明します。Xcastは、非常に多数の小さなマルチキャストセッションをサポートしています。Xcastは、マルチキャストグループアドレスを使用する代わりに、データパケット内の宛先のリストを明示的にエンコードすることにより、これを達成します。このドキュメントでは、いくつかの分野でのXcastの概念とオプションについて説明します。完全な技術仕様は提供されません。
Multicast, the ability to efficiently send data to a group of destinations, is becoming increasingly important for applications such as IP telephony and video-conferencing.
マルチキャストは、IPテレフォニーやビデオ会議などのアプリケーションにとって、目的地のグループにデータを効率的に送信する機能がますます重要になっています。
Two kinds of multicast seem to be important: a broadcast-like multicast that sends data to a very large number of destinations, and a "narrowcast" multicast that sends data to a fairly small group [BOIV]. An example of the first is the audio and video multicasting of a presentation to all employees in a corporate intranet. An example of the second is a videoconference involving three or four parties. For reasons described below, it seems prudent to use different mechanisms for these two cases. As the Reliable Multicast Transport working group has stated: "it is believed that a 'one size fits all' protocol will be unable to meet the requirements of all applications" [RMT]. Note that the 1998 IAB Routing Workshop [2902] came to the same conclusion: "For example, providing for many groups of small conferences (a small number of widely dispersed people) with global topological scope scales badly given the current multicast model".
2種類のマルチキャストが重要であると思われます。非常に多数の宛先にデータを送信する放送のようなマルチキャストと、かなり小さなグループ[Boiv]にデータを送信する「ナローキャスト」マルチキャストです。最初の例は、企業イントラネットのすべての従業員へのプレゼンテーションのオーディオとビデオのマルチリキャストです。2つ目の例は、3つまたは4つのパーティーを含むビデオ会議です。以下で説明する理由により、これら2つのケースに異なるメカニズムを使用することは賢明のようです。信頼性の高いマルチキャストトランスポートワーキンググループが述べているように、「「1つのサイズがすべてに適合する」プロトコルは、すべてのアプリケーションの要件を満たすことができないと考えられています」[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.
今日のマルチキャストスキームを使用して、帯域幅の消費を最小限に抑えることができます。明示的なMulti-Unicast（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].
興味深いことに、Xcastのアイデアはしばらく前から存在していましたが、1990年代後半に独立して再発明した3つのグループにはすぐにはわかりませんでした。実際、1984年のSigcomm Paper [Agui]のLorenzo Aguilarによるインターネットコミュニティにおけるマルチキャストコンセプトの最初の提案は、以下で詳しく説明する目的地の明示的なリストの使用を提案しました。ほぼ同時に、デビッド・チェリトンとスティーブン・ディーリングは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.
インターネットコミュニティは、2つの提案を比較し、単一のメカニズムが複数のメカニズムよりも好ましいと結論付けました。さらに、Aguilarの提案には深刻なスケーリングの問題があるように思われたため、ホストグループモデルが採用されました。
However, for reasons described below, we believe it makes sense to use different mechanisms for the two different kinds of multicast discussed above. While Host Group multicast may have been sufficient in the Internet of 1985, we believe that Xcast can be an important complement to Host Group multicast in the Internet of the 21st century.
ただし、以下で説明する理由により、上記の2つの異なる種類のマルチキャストに異なるメカニズムを使用することは理にかなっていると考えています。ホストグループマルチキャストは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).
宛先が1つしか残っていない場合、Xcastパケットは通常のユニキャストパケットに変換できます。これは、ルートの残りの部分に沿ってユニキャストできます。これはx2u（xcast to unicast）と呼ばれます。
For example, suppose that A is trying to get packets distributed to B, C, and D in Figure 1 below:
たとえば、Aがパケットを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は、Xcastヘッダーに最初のルーターであるR1に宛先のリストを含む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を参照）。したがって、詳細を無視すると、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.
- 前の手順で見つかった次のホップごとにパケットのコピーが1つあるように、パケットを複製します。
- Modify the list of destinations in each of the copies so that the list in the copy for a given next hop includes just the destinations that ought to be routed through that next hop.
- 各コピーの宛先のリストを変更して、特定の次のホップのコピーのリストには、次のホップを通してルーティングされるべき宛先だけが含まれます。
- Send the modified copies of the packet on to the next hops.
- 変更されたパケットのコピーを次のホップに送信します。
- Optimization: If there is only one destination for a particular next hop, the packet can be sent as a standard unicast packet to the destination (X2U).
- 最適化：特定の次のホップの宛先が1つしかない場合、パケットは宛先（x2u）に標準のユニキャストパケットとして送信できます。
So, in the example above, R1 will send a single packet on to R2 with a destination list of < B C D >, and R2 will send a single packet to R3 with the same destination list.
したがって、上記の例では、R1は<B C d>の宛先リストでR2に単一のパケットを送信し、R2は同じ宛先リストでR3に単一のパケットを送信します。
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リストと1つの通常のユニキャストパケットが<b>にR4にアドレス指定された1つの通常のユニキャストパケットを使用して、パケットのコピーを次のホップR5に送信します。R4は標準のユニキャストパケットを受け取り、<b>に転送します。R5は、R6に受け取るXastパケットを転送し、R7に渡します。パケットがR7に到達すると、R7はそれぞれ<c>と<d>にアドレス指定された通常のユニキャストパケットを送信します。R8とR9は標準のユニキャストパケットを受け取り、パケットをそれぞれ<c>と<d>に転送します。
It's important that the Xcast packet that is sent to a given next hop only includes destinations for which that next hop is the next hop listed in the route table. If the list of destinations in the packet sent to R4, for example, had also included C and D, R4 would send duplicate packets.
特定の次のホップに送信される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]は、非常に大きなマルチキャストグループを処理するように設計されています。これらは、世界中に放送のようなチャネルを配布しようとしている場合にうまく機能しますが、非常に多くのグループがある場合、スケーラビリティの問題があります。
The characteristics of the traditional IP multicast model are determined by its two components: the Host Group model [DEER] and a Multicast Routing Protocol. Both components make multicast very different from unicast.
従来のIPマルチキャストモデルの特性は、ホストグループモデル[Deer]とマルチキャストルーティングプロトコルの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）、アドレス割り当てプロトコル（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:
ホストグループモデルに加えて、加盟国と配信ツリーを維持するには、ルーティングアルゴリズムが必要です。これは、（切り捨てられた）ブロードキャストアルゴリズムまたはマルチキャストアルゴリズム[ディア]を使用して実行できます。前者は、一部のルーターに不必要に転送することで帯域幅を消費しすぎるため、マルチキャストアルゴリズムのみが考慮されます。これらのマルチキャストルーティングプロトコルには、次のコストがあります。
- 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では、ホストが特定のソースに結合するため、チャネルはカップルによって識別されます（ソースアドレス、マルチキャストアドレス）。このアプローチは、マルチキャストアドレスの割り当てとドメイン間ルーティングプロトコルの必要性を回避します。ソース広告は、マルチキャストルーティングプロトコルから取り出され、バンド外のメカニズム（例：Webページ）に移動されます。
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の設計を導いた原則であり、インターネットの信じられないほどの成長を可能にした原則です。たとえば、インターネットが非常にうまくスケーリングできた理由の1つは、ネットワークのコアのルーターが、個々のホストや個々の「接続」とは対照的に、大規模なクラスのないドメイン間ルーティング（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) ルーターは、セッションごと（またはチャネルごと）[ソラ]を維持する必要はありません。これにより、Xcastは、ネットワーク内のノードがこれらのセッションにマルチキャストルーティング情報を広めたり保管したりする必要がないため、サポートできるセッションの数に関して非常にスケーラブルになります。
2) No multicast address allocation required.
2) マルチキャストアドレスの割り当ては必要ありません。
3) No need for multicast routing protocols (neither intra- nor inter-domain). Xcast packets always take the "right" path as determined by the ordinary unicast routing protocols.
3) マルチキャストルーティングプロトコルは必要ありません（ドメイン内または干渉間でもありません）。Xcastパケットは、通常のユニキャストルーティングプロトコルによって決定される「正しい」パスを常に取ります。
4) No core node, so no single point of failure. Unlike the shared tree schemes, Xcast minimizes network latency and maximizes network "efficiency".
4) コアノードはないため、単一の障害点はありません。共有ツリースキームとは異なり、Xcastはネットワークの遅延を最小化し、ネットワークの「効率」を最大化します。
5) Symmetric paths are not required. Traditional IP multicast routing protocols create non-shortest-path trees if paths are not symmetric. (A path between two nodes A and B is symmetric if the path is both the shortest path from A to B as well as the shortest path from B to A.) It is expected that an increasing number of paths in the Internet will be asymmetric in the future as a result of traffic engineering and policy routing, and thus the traditional IP multicast schemes will result in an increasing amount of suboptimal routing.
5) 対称パスは必要ありません。従来のIPマルチキャストルーティングプロトコルは、パスが対称でない場合、非短いパスパスツリーを作成します。（2つのノードAとBの間のパスは、パスがAからBまでの最短パスであり、Bから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コードポイント（DSCPS）のリストも含まれています。従来のIPマルチキャストプロトコルは、サービスクラスごとに個別のグループを作成する必要がありますが、Xcastには、1つのマルチキャストチャネル内に異なるサービス要件を持つレシーバーがある可能性が組み込まれています。
9) Xcast packets can make use of traffic-engineered unicast paths.
9) Xcastパケットは、トラフィックエンジニアリングのユニキャストパスを利用できます。
10) Simple implementation of reliable protocols on top of Xcast, because Xcast can easily address a subset of the original list of destinations to do a retransmission.
10）Xcastは、Xcastの上に信頼できるプロトコルを簡単に実装できます。これは、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) オーバーヘッド。各パケットには、残りのすべての目的地が含まれています。ただし、データの合計量は、ユニキャストの場合よりもはるかに少ないです（ペイロードは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 Unicastヘッダーと同じ数のルーティングテーブル検索が必要です。さらに、次のホップごとに別のヘッダーを構築する必要があります。ただし、次のことに注意してください。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によって変換できます。早期X2U（セクション11.2を参照）は、ルーターが1つ以上の宛先のXcastパケットをユニキャストパケットに変換することを決定したときに発生します。これにより、下流のより複雑な処理が回避されます。
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) 処理を減らす他のメカニズムは、[imai]（扱いやすいリスト）および[ooms]（キャッシュ）で説明されていますが、Xact仕様の一部ではありません。
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 Basic 100 KB/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のコストはこれらの2つの次元で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の目的地に同一の情報を配信する1つの方法は、情報をn回ユニカストすることです（図3のA）。2番目の方法である従来のIPマルチキャストモデル（図3のB）は、情報をマルチキャストアドレスに一度だけ送信します。Xcastでは、情報は一度だけ送信されますが、パケットには宛先のリストが含まれています（ポイントC）。
The three points A, B, and C define a plane (indicated with dots in Figure 3): a plane of conservation of misery. All three approaches have disadvantages. The link bandwidth is a scarce resource, especially in access networks. State&signaling/session encounters limitations when the number of sessions becomes large, and an increased processing/packet is cumbersome for high-link speeds.
3つのポイントA、B、およびCは、平面を定義します（図3のドットで示されています）：悲惨な保存面。3つのアプローチには、欠点があります。リンク帯域幅は、特にアクセスネットワークでの希少なリソースです。State＆Signaling/Sessionは、セッションの数が大きくなり、処理/パケットの増加が高リンク速度で面倒な場合の制限に遭遇します。
One advantage of Xcast is that it allows a router to move within this plane of conservation of misery based upon its location in a network. For example, in the core of the network, a cache could be used to move along the line from C to B without introducing any per-flow signaling. Another possibility, as suggested above, is to use premature X2U to move along the line from C to A in an access network if there is an abundance of bandwidth in the backbone.
Xcastの利点の1つは、ネットワーク内の場所に基づいて、この悲惨さの保護面内をルーターを移動できることです。たとえば、ネットワークのコアでは、フローごとの信号を導入することなく、キャッシュを使用してCからBへのラインに沿って移動できます。上記の別の可能性は、バックボーンに帯域幅が豊富にある場合、早期のX2Uを使用してアクセスネットワーク内のCからAに沿って線に沿って移動することです。
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).
- 他のアプリケーションは、ユーザーがパーティーやパーティーに通話したいパーティーに電話をかけるモデルを使用したい場合があります（電話でボタンを使用して今日の電話会議をまとめる方法と同様）。
- 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.
- 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.
「Meshed Unicast」または「Multi-Unicasting」では、アプリケーションは参加者のユニキャストアドレスを追跡し、それらの各アドレスにユニキャストを送信します。セクション3で説明されている理由により、（マルチキャストではなく）マルチユンキャストが今日使用されている一般的なソリューションです。Multi-Unicastコードを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（非常に柔軟なコントロールプレーンプロトコル）と簡単に統合できることがわかります。アプリケーションがXcastの転送を使用することを決定した場合、SIPエージェントへのインターフェイスには影響しません。マルチユンキャストと同じSIPメッセージを使用できます。SIPをXastで使用して、上記の会議モデルをサポートできます。このモデルでは、発信者がいくつかの当事者に電話をかけます。
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コードポイント（DSCPS）のリストも含まれている可能性があります。従来のIPマルチキャストプロトコルは、サービスクラスごとに個別のグループを作成する必要がありますが、Xcastは1つのチャネル内に異なるサービス要件を持つレシーバーを持つ可能性を組み込んでいます。
The DSCP in the IP header will be set to the most demanding DSCP of the list of DSCPs. This DSCP in the IP header will determine, e.g., the scheduler to use.
IPヘッダーのDSCPは、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パケットが作成されます。「マッズルできない」つまり、一方が他方よりも多かれ少なかれ厳しいとは言えません。
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）ペアに似ていることに注意してください）。このドキュメントでは、上記の文書以外に他のセマンティクスをチャネル識別子に割り当てません。
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) ...
5) ...
The size of the channel identifier and its semantics are TBD.
チャネル識別子のサイズとそのセマンティクスは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 Senderのアドレスが含まれています。宛先アドレスフィールドには、すべてのXast-Routersアドレスが搭載されています（リンクローカルマルチキャストアドレスが割り当てられます）。これは固定値を持つことです。すべての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とカプセル化セキュリティペイロード（ESPS）の両方がUDPパケット全体をカバーしています（認証および/または暗号化を介して）。したがって、IPヘッダーの宛先アドレスが変更された場合、UDPチェックサムを更新することはできません。
3) In Xcast for IPv6, the Routing Extension shall be used; this header extension is only checked by a router if the packet is destined to this router. This is achieved by making all Xcast routers part of the All_Xcast_Routers group.
3) IPv6のXcastでは、ルーティング拡張機能を使用するものとします。このヘッダー拡張機能は、パケットがこのルーターに運命づけられている場合にのみルーターによってチェックされます。これは、すべてのXcastルーターをALL_XCAST_Routersグループの一部にすることによって達成されます。
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ルーターにのみ表示されます。ただし、Xast以外のルーターが偶然（または犯罪の意図によって）Xcastパケットを受信した場合、Xcastパケットには宛先アドレスフィールドにマルチキャストアドレスが含まれているため、ICMPエラーが送信されません[1812]。
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断片化を回避したい場合は、Xastヘッダーのサイズを考慮する必要があることに注意してください。
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]の実験目的で使用可能としてリストされているプロトコル番号を保持します。セクション15も参照してください。ソースアドレスフィールドには、Xcast Senderのアドレスが含まれています。宛先アドレスフィールドには、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.
Xcast4ヘッダーは、図4に示す形式です。これは、固定部品（最初の12オクテット）と固定部品で指定された2つの可変長パーツの2つの部分で構成されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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.
バージョン= 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.
a =匿名ビット：このビットが設定されている場合、ビットマップの対応するビットがゼロである宛先アドレスは、ゼロで上書きする必要があります。
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パケットに宛先が1つしか残っていない場合、ルーターはX2Uを適用する必要があります。場合によっては、ルーターがX2Uをパケットに適用しないことを決定できます。たとえば、ルーターには直接接続されたホストがなく、X2Uが必要とする追加の処理を回避したいと考えています。
D = DSCP bit: if this bit is set, the packet will contain a DS byte for each destination.
D = DSCPビット：このビットが設定されている場合、パケットには各宛先のDSバイトが含まれます。
P = Port bit: if this bit is set, the packet will contain a port number for each destination.
p =ポートビット：このビットが設定されている場合、パケットには各宛先のポート番号が含まれます。
NBR_OF_DEST = the number of original destinations.
nbr_of_dest =元の宛先の数。
CHECKSUM = A checksum on the Xcast header only. This is verified and recomputed at each point that the Xcast header is processed. The checksum field is the 16-bit one's complement of the one's complement sum of all the bytes in the header. For purposes of computing the checksum, the value of the checksum field is zero. It is not clear yet whether a checksum is needed (for further study). If only one destination is wrong it can still be useful to forward the packet to N-1 correct destinations and 1 incorrect destination.
checksum = xcastヘッダーのみのチェックサム。これは、Xcastヘッダーが処理されていることを各ポイントで検証および再計算します。チェックサムフィールドは、ヘッダー内のすべてのバイトの補完合計を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-OCTETチャネル識別子（セクション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.
長さ= Xcastヘッダーの長さ4-OCTETワードで。このフィールドは、目的地の数に上の境界を置きます。この値は、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.
最初の変数パーツは「アドレスのリストとDSCPS」です。2番目の変数部分は「ポート番号のリスト」です。どちらも4-OCTETアラインドされています。2番目の変数パーツは、Pビットが設定されている場合にのみ存在します。
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は、Pビットが設定され、Dビットがクリアされている場合の変数部分の例を示しています（この例では、nは奇妙です）：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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-OCTETアラインドされています（たとえば、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-OCTET宛先ポート番号のリスト。各ポートは、前述の宛先アドレスに配置して対応します。
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 Senderのアドレスが含まれています。宛先アドレスフィールドには、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ヘッダーは、固定部品と2つの変数部品で構成されています。固定部品と最初の変数パーツは、ルーティング拡張機能で運ばれます。2番目の変数部品は、宛先拡張機能に搭載されています。
The P-bit of Xcast4 is not present because it is implicit by the presence or absence of the Destination Extension (Figure 6).
Xcast4のPビットは、宛先拡張の有無によって暗黙的であるため存在しません（図6）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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).
チャネル識別子= 16-OCTETチャネル識別子（セクション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.
「アドレスのリストとDSCPS」は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.
ポートのオプションタイプについては、セクション15を参照してください。最初の3つのビットは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ヘッダーの一部のフィールドは、パケットが配信パスに沿って移動するときに変更できます。これには次の影響があります。
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')
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」、「DP」、「H」と「L」は、それぞれ高度16ビットと低い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を展開する1つの方法は、Xcastピア間で「トンネル」をセットアップすることです（MBONEアプローチ[MBONE]）。これにより、既存のネットワーク[2003]の上に階層化された仮想ネットワークの作成が可能になります。Xcastルーターは、標準のユニキャストルーティングプロトコル（RIP、OSPF、IS-IS、BGPなど）を介してXcastルーティング情報を交換し、維持します。作成されたXcastルーティングテーブルは、Xcast接続を備えた宛先を含む標準のユニキャストルーティングテーブルと、対応するXcast Next Hopsです。このようにして、パケットは他の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がパケットをB、C、およびDに配布しようとしていると仮定します。以下の図8では、「X」ルーターはXcastで利用でき、「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 Peer X3にトンネルを確立します。ルーターX3は、Xcast Peers X1およびX7にトンネルを確立します。ルーターX7は、Xcast Peer X3にトンネルを確立します。
X1 routing table: X3 routing table: X7 routing table:
Dest | NextHop Dest | NextHop Dest | NextHop
------+---------- ------+--------- ------+---------
B | X3 A | X1 A | X3
C | X3 C | X7 B | X3
D | X3 D | X7
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 Next Hopを決定します。
- 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 Next Hopが見つかった目的地については、次のホップに基づいて目的地を分割します。
- 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 Next Hopsごとにパケットのコピーが1つあるようにします。
- Modify the list of destinations in each of the copies so that the list in the copy for a given next hop includes just the destinations that ought to be routed through that next hop.
- 各コピーの宛先のリストを変更して、特定の次のホップのコピーのリストには、次のホップを通してルーティングされるべき宛先だけが含まれます。
- Send the modified copies of the packet on to the next hops.
- 変更されたパケットのコピーを次のホップに送信します。
- Optimization: If there is only one destination for a particular 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 Next Hopの宛先が1つしかない場合は、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がパケットを受信すると、上記のアルゴリズムにより、パケットのコピーを通常のユニキャストパケットとして宛先<b>に送信し、パケットのコピーは<c d>の宛先リストを使用してx7に送信します。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能力がないことを発見した場合、時期尚早のX2Uを実行できます。つまり、この隣人を次のホップとして持っているXcastヘッダーの各宛先にユニキャストパケットを送信します。したがって、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 Ping」を隣人に送信することができます（独自のアドレスを宛先として含むXcastパケットを送信し、パケットが返されるかどうかを確認してください）。
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 Hop-by-Hopオプションのタイプにはプレフィックス「00」があり、Xcast6を認識できないルーターはXcast6データグラムを通常のIPv6データグラムとして扱い、IPv6ヘッダーの宛先に転送できます。
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パケットを送信すると、図11のパケットが作成されます。最終目的地の1つは、外側のIPヘッダーの宛先アドレスフィールドに配置されます。
+----------+
| payload |
+----------+
| UDP |
+----------+
| Xcast |
| |
+----------+
| inner IP |
| src=A |
|dst=All_X_|
|prot=Xcast|
+----------+
| Xcast |
|SP-tunnel |
|Hop-by-hop|
+----------+
| outer IP |
| src=A |
| dst=B |
| prot=IP |
+----------+
Figure 11
図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ルーターをトンネル上の中間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の展開の特別な方法は、ホストのみをアップグレードすることで可能です。トンネルのエンドポイントとして最終目的地の1つを使用したトンネル（セクション11.1および11.3を参照）を適用することにより、すべてのホストがXastが認識している場合、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パケットを作成し、残りの目的地の1つに送信します。
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.
- ホストはネットワーク機能を実行する必要があり、下流リンクと同じ帯域幅を持つ上流のリンクが必要です。
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-Awareのルーターが1つしかない可能性があります。このXcast-Awareルーターは、他のルーターの「サーバー」のように見え、IPアドレス（またはIPアドレスのいずれか）が「特別な」32ビットアドレスに対応するように構成されています。したがって、XcastクライアントがXcastパケットを送信すると、非Xast-AwareルーターはこれらのパケットをXcast-Awareルーターにルーティングし、Xcast-Awareルーターは適切なユニキャストパケットのセットに「爆発」（X2U）になります。これにより、ネットワーク内のどこでもクライアントがXcastを使用して、最小数のXast-Awareルーター（つまり、1）で「最初のマイル」の限られた帯域幅の問題を克服できます。
Another possibility is to deploy a few of these Xcast-aware routers at various points in the network and to configure each of these with the special 32-bit address. This provides redundancy, eliminating the single point of failure, and reduces the distance an Xcast packet needs to travel to reach an Xcast-aware router, reducing network latencies. In this case, the Xcast-aware routers appear to be a single server that is "multihomed" (i.e., connected to the network at more than one place) and the non-Xcast-aware routers will, via ordinary unicast routing, deliver packets that are addressed to this "multihomed virtual server" via the shortest available path.
もう1つの可能性は、これらのXcast-Awareルーターのいくつかをネットワーク内のさまざまなポイントに展開し、これらのそれぞれを特別な32ビットアドレスで構成することです。これにより、冗長性が提供され、単一の障害ポイントが排除され、Xcastパケットが移動するのに必要な距離が削減され、Xcast Awareルーターに到達してネットワークの遅延が削減されます。この場合、Xcast-Awareルーターは「マルチホーム」（つまり、複数の場所でネットワークに接続されている）の単一サーバーであるように見え、非Xastに認識されていないルーターは、通常のユニキャストルーティングを介してパケットを配信しますこれは、最短のパスを介してこの「マルチホームの仮想サーバー」に宛てられています。
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:
グループの任意のホストにパケットを配信するこのスキームは、「Anycast」とも呼ばれ、RFCS [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パケットを標準のTCP/IPスタックで送信して、Xcastパケットを生のソケットに送信する小さな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の場合、DSCPSオプションの形式を指定する必要があります。
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のチャネル識別子のサイズが異なります。IPv6とIPv4の両方で32ビットで十分かもしれません。
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を使用して「効果」を増やすことができます。たとえば、Smurf攻撃は、ターゲットが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リクエストに返信しないように設定できます。従来のマルチキャストアーキテクチャの逆パス転送チェックは、これらの攻撃を制限するのにも役立ちます。Xcastでは、ホストがホストに到達するまでにパケットが通常のユニキャストパケットである可能性があるため、ホストがICMPリクエストが複数の宛先に対処されていることを認識することは困難です。一方、ルーターは、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ワーキンググループで議論された概念の多くも、Xastベースのグループコミュニケーションに適用されます。そして、同じメカニズムの多くが当てはまるようです。マルチキャストとXcastの重要な違いの1つは、Xcastヘッダー（またはXcastヘッダーの少なくともビットマップ）がソースから宛先に移動するにつれて変更する必要があるという事実です。これはIPSECの使用に影響を与え、少なくともXastヘッダービットマップが「可変」フィールドにある必要があることを示唆しています。上記のすべての問題に対処するすべての問題に対処するXastベースのグループコミュニケーションを保護するための完全なソリューションは、1つ以上の追加のドキュメントで議論される追加作業の対象となります。この取り組みは、MSECワーキンググループですでに行われている作業に基づいていると予想しています。
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
(1) all_xcast_routersのマルチキャストアドレス（2）ルーティングのタイプIPv6ルーティングヘッダー（3）オプションのタイプIPv6宛先オプションヘッダー（4）オプションIPv6ホップバイホップオプションヘッダーのタイプタイプ
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.
プロトコル実装者は、RFCで実験的に使用するために確保された値を使用して、Xastを一時的に実験することができます[4727]。実装者は、他の実験ではXastテストベッドで同じ値を同時に使用しないことを確認する必要があります。
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] Partridge、C.、Mendez、T。、およびW. Milliken、「Host Anycasting Service」、RFC 1546、1993年11月。
[2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[2526] Johnson、D。およびS. Deering、「予約済みのIPv6サブネットAnycastアドレス」、RFC 2526、1999年3月。
[3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[3068] Huitema、C。、「6to4リレールーターのAnycast Prefix」、RFC 3068、2001年6月。
[1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[1112] Deering、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.、Partridge、C。、およびS. Deering、「距離ベクトルマルチキャストルーティングプロトコル」、RFC 1075、1988年11月。
[1770] Graff, C., "IPv4 Option for Sender Directed Multi-Destination Delivery", RFC 1770, March 1995.
[1770] Graff、C。、「送信者向けのMulti-destination DeliveryのIPv4オプション」、RFC 1770、1995年3月。
[1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[1812] Baker、F.、ed。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[2003] Perkins、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] Deering、S。and 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] Deering、S.、Hares、S.、Perkins、C。、およびR. Perlman、「1998 IABルーティングワークショップの概要」、RFC 2902、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIATION Protocol」、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] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、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. Weis、「マルチキャストグループセキュリティアーキテクチャ」、RFC 3740、2004年3月。
[4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[4607] Holbrook、H。およびB. Cain、「IPのソース固有のマルチキャスト」、RFC 4607、2006年8月。
[4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[4727] Fenner、B。、「IPv4、IPv6、ICMPv4、ICMPv6、UDP、およびTCPヘッダーの実験値」、RFC 4727、2006年11月。
[AGUI] L. Aguilar, "Datagram Routing for Internet Multicasting", SIGCOMM '84, March 1984.
[Agui] L. Aguilar、「インターネットマルチキャストのデータグラムルーティング」、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] David R. Cheriton、Stephen E. Deering、「ホストグループ：Datagramインターネットワークのマルチキャスト拡張機能」、データコミュニケーションに関する第9回シンポジウムの議事録、p。172-179、1985年9月、カナダ、ブリティッシュコロンビア州ウィスラームーテイン。
[BOIV] Boivie, R. and N. Feldman, "Small Group Multicast", Work in Progress, February 2001.
[Boiv] Boivie、R。およびN. Feldman、「Small Group Multicast」、Work in Progress、2001年2月。
[DEER] S. Deering, "Multicast Routing in a datagram internetwork", PhD thesis, December 1991.
[ディア] 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。エストリン、D。ファリナッチ、V。ジェイコブソン、C。リュー、およびL. wei、「幅広いマルチキャストルーティングのためのPIMアーキテクチャ」、1996年4月、ACMトランザクション。
[FARI] Farinacci, D., et al., "Multicast Source Discovery Protocol", Work in Progress, June 1998.
[Fari] Farinacci、D.、et al。、「Multicast Source Discovery Protocol」、Work in Progress、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,
[Imai] Imai、Y。、「IPv6（MDO6）の複数の宛先オプション」、2000年9月、進行中の作業
[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、「Connectionless Multicast」、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. Sales、「明示的なマルチキャストのセキュリティフレームワーク」、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. Sola、M。Ohta、T。Maeno、「インターネットマルチキャストプロトコルのスケーラビリティ」、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
Olivier Paridaens Alcatel Network Strategy Group Fr.Wellesplein 1、2018 Antwerpen、ベルギー電話：32 3 2409320メール：olivier.paridaens@alcatel.be
Eiichi Muramoto Matsushita Electric Industrial Co., Ltd. 4-12-4 Higashi-shinagawa, Shinagawa-ku Tokyo 140-8587, Japan Phone: +81-3-6710-2031 EMail: muramoto@xcast.jp
ムラモト松島電気産業株式会社、Ltd。4-12-4西海西海、西川ku東京140-8587、日本電話：81-3-6710-2031メール：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
Rick Boivie Ibm T. J. Watson Research Center 19スカイラインドライブホーソーン、ニューヨーク10532電話：914-784-3251メール：rhboivie@us.ibm.com
Nancy Feldman IBM T. J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532 EMail: nkfeldman@yahoo.com
ナンシーフェルドマンIBM T. J.ワトソンリサーチセンター19スカイラインドライブホーソーン、ニューヨーク10532メール：nkfeldman@yahoo.com
Yuji Imai Fujitsu Laboratories Ltd. 1-1, Kamikodanaka 4-Chome, Nakahara-ku Kawasaki 211-8588, Japan Phone: +81-44-754-2628 Fax : +81-44-754-2793 EMail: ug@xcast.jp
Yuji Imai Fujitsu Laboratories Ltd. 1-1、Kamikodanaka 4-Chome、Nakahara-Ku Kawasaki 211-8588、日本電話：81-44-754-2628 FAX：81-44-754-2793メール：ug@xcast.jp
Wim Livens ESCAUX Krijtstraat 17, 2600 Berchem, Belgium EMail: wim@livens.net
wim livens escauxkrijtstraat 17、2600 Berchem、Belgiumメール：wim@livens.net
Dirk Ooms OneSparrow Belegstraat 13; 2018 Antwerp, Belgium EMail: dirk@onesparrow.com
Dirk Ooms OnesParrow Belegstraat 13;2018 Antwerp、Belgiumメール：dirk@onesparrow.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。