【draft-ooms-xcast-basic-spec-01】の訳♪

INTERNET DRAFT【draft-ooms-xcast-basic-spec-01.txt】

明示的なマルチキャスト(Xcast)の基本的な仕様書
このメモの位置付け この文書はインターネットドラフトであり、RFC2026の10節の全ての規定に完全に準拠している。 インターネットドラフトはIETF、その分野、およびその作業グループの作業文書である。他のグル ープもまたインターネットドラフトとして編集中の文書を配布できることに注意されたい。 インターネットドラフトは、最大6ヵ月間有効な草稿文書であり、いつでも他の文書によって更新、 入れ替え、または廃止されるかもしれない。参考文献としてインターネットドラフトを使うこと、 または"作業中"として他の資料に引用することは不適当である。 最新のインターネットドラフトのリストは、 http://www.ietf.org/ietf/1id-abstract.txt で入手することができる。 インターネットドラフトの保護ディレクトリのリストは、 http://www.ietf.org/shadow.html で入手できる。 概要 マルチキャストはIP電話やビデオ会議のようなネットワークベースのアプリケーションの出現によっ てますます重要になってきている。インターネットコミュニティはここ10年以上にわたり [1075, 2201, 2236, DEER, DEE2, FARI, HOLB, MBONE, PERL]においてIPマルチキャストについて相当量の 作業を行ってきた。 しかしながら、従来のマルチキャスト構成は非常に大きなマルチキャストグループをサポートできる という意味で拡張性がある一方で、ネットワークが多数の個別のマルチキャストグループのサポート を必要とするとき、問題を生ず。 この文書は、既存の構成を補完する、明示的なマルチキャスト(Xcast)と名付けられた新しいマル チキャストのスキームについて記述する。既存の構成が、限られた数の非常に大きなマルチキャスト セッションをサポートできるのに対し、Xcastは多数の小さなマルチキャストセッションをサポート できる。これは、マルチキャストアドレスを使用する代わりにデータパケットの宛先リストを明示的 に符号化することによって達成される。 既存のコントロールプレーンと、データプレーン機構であるXcastの協調について記述し、段階的な 展開のためのシナリオは研究は調査してある。IPv4とIPv6の両方に対する符号化が提案されている。 このドラフトは、3種類の初期のドラフト([BOIV]、[IMAI]、[OOMS])を併合したものである。 目次 1.序文 2.Xcastのあらまし 3.従来形マルチキャストの枠組の問題点 4.研究の動機 5.アプリケーション 6.柔軟性のあるXcast 7.コントロールプレーン 7.1 SIP(Session Initiation Protocol) 7.2 受信側起動joinモデル 8.オプション情報 8.1 ポートリスト 8.2 DSCP(Differentiated Services Code Point) 8.3 チャネル識別子 9.符号化 9.1 一般原理 9.2 IPv4 9.2.1 IPv4ヘッダ 9.2.2 Xcast4ヘッダ 9.3 IPv6 9.3.1 IPv6ヘッダ 9.3.2 Xcast6ヘッダ 9.3.2.1 経路制御ヘッダ 9.3.2.2 宛先拡張ヘッダ 10.上位レイヤプロトコルの影響 10.1 UDPとICMPにおけるチェックサム計算 10.2 IPsec認証ヘッダ 11.段階的展開 11.1 トンネリング 11.2 未成熟のX2U 11.3 半透明トンネリング(IPv6) 11.4 特殊ケース:ネットワークサポートなしでの展開 12.(ソケット)API 13.セキュリティの考察 参考文献 変更: 00->01:−Xcastヘッダにチャネル識別子を付加 −用語の整理(従来の、現行の、今日のmc) −セッションとチャネルの定義の付加 1.序論 宛先グループへデータを効率的に送信する能力を持つマルチキャストは、IP電話やビデオ会議のよ うなアプリケーションにおいてますます重要になってきている。 重要なマルチキャストには2種類あるように思われる。ブロードキャスト−多数の宛先へデータを 送信するマルチキャスト−と、ナローキャスト−かなり小さなグループにデータを送信するマルチ キャスト−である。最初の例は、IETF会議から世界中のサイトへ活動しているグループセッション の中継における、オーディオやビデオのマルチキャストである。2番目の例は、3〜4グループが 集まって参加するビデオ会議である。以下に述べる理由により、これら2つのケースは異なるメカ ニズムを使うことが賢明なように思える。信頼性マルチキャスト・トランスポート・グループが述 べているように、"'一つの型で全てに適応する'プロトコルは全てのアプリケーションの要求を処 理することは不可能であると思われる。"[RMT]。 マルチキャストは帯域幅の消費を最小にするために使用される。明示的なマルチキャスト(Xcast )もまた、"小さなグループ"に関して帯域幅の消費を最小にするために使用される。しかもその上 、付加的な長所を持つ。Xcastは従来のマルチキャストにおけるセッション毎のシグナリングやセ ッション毎の状態情報を削除し、非常に多くの数のマルチキャストセッションを、サポートするこ とを可能にする。このスケーラビリティが重要である。何故なら同時に起こるマルチキャストセッ ションは多数で、そしてグループのメンバの数は少ないというIP電話、ビデオ会議、協調アプリケ ーション、ネットワークゲームなどのような重要なアプリケーションのクラスを使用可能にするか らである。 2.Xcastのあらまし この文書に伴う用語は、以下のように使用される: −セッション:Xcastにおいて'マルチキャストセッション'という用語は、従来のIPマルチキャス トのマルチキャストグループアドレスに対して、マルチキャストとの強い関連を避けるために、 'マルチキャストグループ'の代わりに用いられる。 −チャネル:複数の送信元(例えばビデオ会議)があるセッションにおいて、一つの送信元によっ て送信されるフローは、チャネルと呼ばれる。従って、セッションは一つまたはそれ以上のチャ ネルを含む。 ホストグループモデルにおけるパケットは、全てのグループメンバの論理的な識別子として、マル チキャストアドレスを運ぶ。Xcastにおいて送信元ノードは、宛先へパケットを送信しようとする マルチキャストチャネル内の宛先を保存する。 送信元はXcastヘッダで宛先のリストを符号化し、そしてそれからルータにそのパケットを送信す る。途中のルータはヘッダを解析し、それぞれの宛先の次ホップに基づいた宛先毎に分割し、そし てそれぞれの、次ホップに適切なXcastヘッダを持つパケットを転送する。 一つの宛先だけが残ったとき、Xcastパケットは通常のユニキャストパケットに変更できる。そし てそれは残ったルート上をユニキャストされる。これはX2U(Xcast to Unicast)と呼ばれる。 例えば、Aが、以下の図1のように、分散したB、C、Dにパケットを到着させることを試みると想定 する:        R4-------B / / / A-------R1-------R2-------R3      R8-------C \    / \      / \     / R5-------R6-------R7 \ \ \ R9-------D 図1 これは次のように成し遂げられる: 「A」は最初のルータR1へ、そのXcastヘッダ内の宛先リストを用いて、Xcast パケットを送信する。 Xcastヘッダは、IPv4とIPv6では少しばかり異なるので、このセクション(セクション9参照)では Xcastヘッダの符号化の詳細を明かさない。そこで詳細を無視して、AからR1に送信するパケットを このように見てみる: [ src = A | dest = B C D | payload ] R1がこのパケットを受信すると、Xcastヘッダを正確に処理する必要がある。これらのXcastパケッ トの一つを受信すると同時にルータが行う処理は、以下の通りである: −パケット内にリストされた宛先毎の次ホップを決定するために、ルートテーブル照合の実行 −次ホップに基づいた宛先毎の分割 −前のステップで見つけた次ホップ毎に、パケットのコピーが一つ含まれるように、 パケットを複製。 −与えられた次ホップに向けて、コピー内のリストは次ホップを通ってルーティングされるように 、コピー内の宛先リストを変更。 −変更されたパケットのコピーを、次ホップに転送。 −最適化:特定の次ホップに関して宛先が一つだけなら、Xcastパケットとして転送することは マルチキャスト利得が全く無いので、その宛先へは標準のユニキャストパケットとして パケットを送信する(X2U)。      従って上記の例では、R1は<B C D>の宛先リストを用いて、R2に向けて一つのパケットを送信し 、R2は同じ宛先リストを用いて、R3に一つのパケットを送信する。 R3がパケットを受信すると、上記のアルゴリズムに従って、<C D>のXcastリストを用いて宛先R5 へパケットのコピーを一つ送信する。そして、一つの通常のユニキャストパケットは、<B>と宛 名を書かれる。R4は標準のユニキャストパケットを受信し、隣接した<B>へ転送する。R5はXcast パケットを転送し、それをR6が受信し、隣接するR7に中継する。パケットがR7に到着すると、R7は それぞれ<C>や<D>と宛名を書かれた標準のユニキャストパケットを送信する。R8とR9は標準の ユニキャストパケットを受信し、それぞれに隣接する<C>や<D>にパケットを転送する。 ある次ホップに送信されるXcastパケットは、その次ホップは、ルートテーブルでリストされた次 ホップである宛先だけを含むということが重要である。もしR4へ送信するパケット内の宛先リスト が、例えば<C D>を含んでいるなら、R4は複数のパケットを送信するだろう。 ルーティングトポロジが変化する時、与えられた宛先へXcastパケットを運ぶパスは、その宛先へ の通常のユニキャストルーティングをいつも追跡するので、Xcastチャネルのためのルーティング は、新しいトポロジに自動的に適応することに注意されたい。 3.従来形マルチキャストの枠組の問題点 従来形マルチキャストの枠組[DEER、DEE2、FARI]は、巨大なマルチキャストグループを扱うように 設計された。それは、世界中に放送のようなチャネルを配送する場合はうまく動く。しかし、非常 に多数のグループとなると、スケーラビリティの問題が生じる。 従来のIPマルチキャストモデルの特性は、ホストグループモデル[DEER]とマルチキャストルーティ ングプロトコルという2つの構成要素によって決定される。2つの構成要素は、ユニキャストとマ ルチキャストの間にある特性の違いを増す。 ホストグループモデルにおいて、ホストのグループは、マルチキャストグループアドレスによって 識別され、予約と転送で使用される。このモデルには2つの主な問題点がある: −マルチキャストアドレス割当:マルチキャストグループの作成者は、その領域内(領域はしばし ばグローバルである)でユニークなマルチキャストアドレスを割り当てる必要がある。この課題 は、Malloc(Multicast Address allocation)working groupによって検討されている。そして それは、マルチキャスト・アドレス・アロケーション・サーバ(MAAS)と3つのプロトコル (MASC、AAP、MADCAP)の組み合わせを提案している。   −宛先不明:マルチキャストパケットがルータに到着すると、ルータはそのパケットの次ホップを 決定できるが、パケットの最終的な宛先、またネットワーク上であと何回複製されるかについて は何も知らない。これは、セキュリティ、課金及びポリシー機能を複雑にする。 ホストグループモデルの他に、ルーティングアルゴリズムはメンバ状態や配信ツリーを維持するこ とを要求される。これは、(省略された)ブロードキャストアルゴリズムまたは、マルチキャスト アルゴリズムを使う[DEER]ことで実行できる。前者は、パケットをいくつかのルータに不必要に転 送して帯域を非常に多く消費するので、マルチキャストアルゴリズムだけについて検討する。これ    らのマルチキャストルーティングプロトコルには以下の問題点がある。 −コネクション状態:マルチキャストルーティングプロトコルは、ポイント・マルチポイントツリ ーの要素である全てのルータに、それぞれ(発信元、マルチキャストグループ)の状態を作成す るメッセージを交換する。これは、マルチキャストコネクション状態を作成するシグナリングを 作り出すことになる。多分、巨大なマルチキャスト転送テーブルとして見なされる。これらの枠 組には、必ずしも必要としない所へマルチキャストルーティング情報を広めることさえある[1075]。 他の仕組はネットワークの隅から隅まで伝播、処理、格納を必要とするマルチキャスト ルーティング情報の量を制限しようとする。これらの仕組(例えば[2201])は、マルチキャスト グループの全てのメンバに共有される"共有配信ツリー"を使う。そして、"本当にそれが必要で ある"ノードに対して、マルチキャストルーティング情報の配信を制限しようとする。しかしこ れらの構成にも問題がある。共有ツリーなので、宛先へのパケットのルーティングにおいて、決 して最適ではないパスを使い、ネットワークの小さな部分にトラフィックが集中する傾向がある。 −送信元広告メカニズム:マルチキャストルーティングプロトコルは、送信元自体を知ることなし に特定のグループに対して、そのメンバを送信元に接続するメカニズムを提供する。疎モードプ ロトコル[2201、DEE2]では、コアノードを持つことによって成し遂げられ、それはドメイン全体 に広告される必要がある。一方、密モードプロトコル[1075]では、これは"フラッド・プルーン" メカニズムによって成し遂げられる。両方のアプローチはともに、付加的なスケーラビリティの 問題が生じる。 ドメイン間ルーティング:コアノード[2201、DEE2]に依存するマルチキャストルーティングプロ トコルは、ドメイン間マルチキャストルーティングプロトコル(例えば[FARI])を必要とする。 マルチキャストアドレス割当、宛先不明および上記のスケーラビリティの問題などが人々を、他の マルチキャスト方式の追求へ向かわせた。送信元特定マルチキャスト(SSM)[HOLB]は、上記の欠 点のいくつかを解決した。つまり、SSMではホストを特定の送信元に属し、その上、チャネルはア ドレスの組(送信元アドレス、マルチキャストアドレス)によって、同定する。このアプローチは 、ドメイン間ルーティングプロトコルの必要性だけでなく、マルチキャストアドレス割当も回避す る。送信元の広告は、マルチキャストルーティングプロトコルから取り外されて、アウト-オブ-バ ンドメカニズム(例えば、Webページ)に移される。 SSMはさらに、それぞれのツリー上の各ノードにおいて、マルチキャストチャネル毎の状態とシグ ナリングを作成することに注意されたい。図2に、セッションまたはチャネルに属するメンバ数の 関数として、上記のコストを描写する。全てのコストは、双曲線的な動きである。 メンバ毎の従来のマルチキャストのコスト          ↑ |  costly |  OK | ←―――――|―――――→ | ・ | | ・・ | | ・・|・・ | |  ・・・・・・・・・ | |           ・・・・・・・・ |――――――――――――――――――――――――→ |    メンバ数 ↓      代案 = Xcast 図2    従来のマルチキャストモデルは、グループが小さいとそのメンバは費用がかかるようになる。小さ なグループは会議、ゲーム、共調アプリケーションが代表的である。これらのアプリケーションは 、Xcastによって効率よくサービスされる。 実際問題として、従来のマルチキャストルーティングプロトコルは、グループ数や展開されるネッ トワークの大きさについて制限を余儀なくする。Xcastでは、これらの制限は存在しない。 4.研究の動機   Xcastはインターネットの"哲学"、すなわちネットワークの周辺に複雑なものを移動し、ネットワ ークの中央はシンプルにするという、基本的な考え方を利用する。これはIPやTCP、そしてインタ ーネットの信じられないほどの成長を可能にした原則である。例えば、インターネットがよく拡大 をつづけてきた理由の一つに、ネットワークのコアにあるルータが個々のホストまたは個々の"コ ネクション"ではなく、大きなCIDRブロックを扱うことがある。コアにあるルータは、ルータを通 り過ぎる個々のTCPコネクションの経路を追跡する必要はない。同様に、IETFのDiffservの効果は 、ルータがそれを通過する多数のRSVP(Resource Reservation Protocol)フローを個々に追跡す る必要はない、という考え方を基盤にしている。著者の考えでは、コアのルータは、多数のマルチ   キャストフローを個々に追跡すべきではないというものである。 従来のマルチキャストと比べて、Xcastには次のような利点がある: 1)ルータはセッションまたはチャネル毎の状態を維持する必要がない[SOLA]。これにより、 ネットワークのノードがセッションのマルチキャストルーティング情報を伝播したり記憶 したりする必要が全く無くなるので、サポート可能なセッションの数に関して、Xcastは 容易に大規模化できる。 2)マルチキャストアドレス割当は不要。 3)マルチキャストルーティングプロトコルは不要。Xcastパケットは、通常のユニキャスト ルーティングプロトコルによって決定された"正しい"経路を選ぶ。 4)コアノードが不要なので、その故障によるシステムダウンはない。 配信ツリー構成と違っ て、Xcastはネットワーク遅延を最小にし、ネットワーク"効率"を最大にする。 5)対称のパスは必要ない。従来のマルチキャストルーティングプロトコルは、パスが対称 (対称=AからBまでの最短パスがBからAまでの最短パスと同じ)でないなら、非最短パス ツリーを作成するトラフィックエンジニアリングとより賢明なルーティングによって、イン ターネットのパスはますます非対称になるであろうと予想される。かくしてマルチキャスト は最適なネットワークの利用からますます脱線していくであろう。 6)ユニキャストへの新ルートに自動的に反応。Xcastは、ユニキャストのルートの変化に、 即座に反応する。従来のマルチキャストルーティングプロトコルにおいて、ユニキャスト およびマルチキャストルーティングプロトコル間の通信は接続確立が必要である。たいてい の実装ではポーリングを基本としており、例えばリンクの失敗に対してより遅い反応となる。 多数のグループに問題があると、従来方式のマルチキャストルーティングプロトコルは問題 を処理するのに時間がかかる。 7)セキュリティと課金が容易。ホストグループモデルとは対照的に、Xcastでは全ての送信元 は、マルチキャストチャネルのメンバを知っている。そしてそれは、例えば特定のメンバを 拒否したり非常に簡単に特定のメンバへのトラフィックをカウントしたりする手段を、送信 元に与える。送信元だけでなく、境界ルータもまたドメイン内でどれくらいパケットを複製 するかを決定できる。送信元の数や送信元毎の帯域幅を制限することも簡単になる。 8)異質の受信者の収容。宛先リストのほかにも、パケットは、DiffServ CodePoint(DSCP)の リストも含むことができる(オプション)。従来のマルチキャストプロトコルではそれぞれ のサービスクラス毎に異なるグループを作成する必要があるが、Xcastでは一つのマルチキ ャストチャネル内に異なるサービス要求を有する受信者を収容できる可能性がある。 9)Xcastパケットは、トラフィックエンジニアリングにより制御されたユニキャストパスを 利用できる。 10)Xcastの上位層に高信頼プロトコルを簡単に組み込み可能。再送に際して元の宛先リストの サブセットを容易に指定できる。 11)柔軟性(6章参照) 12)より簡単な遷移メカニズム(11章参照)   なお、Xcastはいくつかの欠点を持つことにも注意すべきである。 1)オーバーヘッド。それぞれのパケットは、全ての未着信宛先を含む。しかし、データの総量 は、ユニキャストよりもずっと少ない(ペイロードは一度送信されるだけ)。宛先アドレス のリストを圧縮する方法は、有用である。 2)より複雑なヘッダ処理。パケットにあるそれぞれの宛先に対して、ルーティングテーブルを 検索する必要がある。それで、n個の宛先を持つXcastパケットは、n個のユニキャストヘッ ダと同じだけルーティングテーブルの検索を必要とする。そのうえ、異なるヘッダをホップ 毎に再構成する必要がある。しかし、以下の各点に注意されたい: a)Xcastは非常に散在したセッションなので、非分岐点に比べて分岐点の数は限られる。 分岐点においてのみ新しいヘッダを、再構成する必要がある。 b)ヘッダの再構成は、ビットマップの上書きとして、非常に簡略化された。 c)非分岐点の大多数は一つの宛先のみを含む。これらは、普通のユニキャスト転送を適用 すればよい。 d)転送テーブルの多重化と組み合わせて、宛先リストを階層的に符号化することによって、 転送を加速することができる[OOMS]。 e)パケットが、リンク帯域幅に問題の無いネットワークの領域に入ると、未成熟X2Uによっ てそのパケットを変換してもよい。X2U(11.2章参照)は、ルータが一つあるいはそれ 以上の宛先のXcastパケットをユニキャストパケットに変換することを決定するときに 発生する。これにより下流でのより複雑な処理を避けることができる。 f)上記以外に、処理を減少するためのメカニズムが[IMAI](制御しやすいリスト)や[OOMS] (キャッシング)に記述されているが、このXcastの基本仕様書にはない。 3)Xcastは制限された数の受信者のみを扱う。 5.アプリケーション   IETF会議のブロードキャストのような多数のメンバを有するマルチキャストセッションにはXcast   は不適当である一方、多数の小さなセッションをサポートできるという点でXcastは既存のマルチ   キャスト構成に重要な補足を提供する。それでXcastは、会議、マルチプレーヤー・ゲーム、共同   作業などの重要なアプリケーション階層をカバーする。これらのセッションの数は、巨大になるで   あろう。   中には制限された数のメンバでのセッションにマルチキャストを使うことは、不適当であり、代わ   りにユニキャストを使うべきだという議論もある。しかし、"ラスト・マイル"の中で制限された   帯域幅の場合、以下の例で説明するように、マルチキャストがいくつかの形態を持つことが重要で   ある。ビデオ会議をセットアップするn個の住宅地のユーザを想定する。一般的には、アクセス技術は   非対称(例えば、xDSL、GPRSまたはケーブルモデル)である。従って、xDSLを用いるホストは、   n-1個の基本的な100kb/sのビデオチャネルを受信することに問題は無いが、この速度では自分の   ビデオデータをn-1回送信することはできない。アクセス容量は制限され非対称なので、何らかの   マルチキャストが必須である。   Xcastのシンプルであるが重要なアプリケーションは、アクセスリンクをブリッジすることである。   ホストはユニキャストアドレスリストを用いてXcastパケットを送信する。そして、最初のルータは、   未成熟X2Uを実行する。   Xcastは大きなグループには不適当なので、従来のマルチキャストモデルに取って代わることはない。   しかし、小さなセッションが多数あるときは、マルチポイント−マルチポイント接続の選択肢となる。 6.Xcastの柔軟性   マルチキャストの主な目的は、同じリンク上を複数の同一情報が流れることを避けることである。   ユニキャストの代わりに従来のマルチキャストを使うことによって、セッションごとのシグナリングと   状態が増加するけれど、帯域幅の消費は減少する。これら2つの次元は別に、我々は第3の次元:   「パケット毎のヘッダ処理」を定義する。この3次元空間を図3に示す。 ルータのセッションごとの状態とシグナリング ↑ | B・・・ ・ |   ・・・・ ・ |        ・・・・ ・ |            ・・・・ ・ |                ・・・・   ・   |                    ・・・・  ・ +―――――――――――――――――――――――・・―――→ルータの ・ /                     ・・・・C    パケット ・ /                 ・・・・・         処理 ・ /             ・・・・・ ・   /         ・・・・・ ・  /    ・・・・・ /A・・・・ / リンク帯域幅 図3   送信元からn個の宛先までの同じ情報を配信する一つの方法は、n回情報をユニキャストすること   である(図3のA)。2番目の方法は、従来のマルチキャストモデル(図3のB)が、マルチキャスト   アドレスへ一度だけ情報を送信する。Xcastにおいてその情報は一度だけ送信されるが、   パケットは宛先リスト(C点)を含む。   3つの点A、B、Cは一つの平面(図3のドットで示された):動作限界面を定義する。   3つのアプローチはすべて欠点を持っている。リンク帯域幅は、特にアクセスネットワークにおいて   少ない資源である。状態&シグナリング/セッションは、セッションの数が大きくなると限界に   出くわし処理/パケットの増加は高いリンク速度では厄介である。   Xcastの良い所は、ルータ自身で折り合いをつけることができるということである。全ての情報は   パケットによって運ばれるので、Xcastではルータが必要なら動作保存面(図3)上を動く(例え   ば、ネットワーク上でルータの位置)ことが可能である。ルータは、キャッシュすればCからBまで   移動することができ、一方未成熟のX2Uは、CからAまでの移動を可能にする。 7.コントロールプレーン   従来のマルチキャストの構成と違って、Xcastには"コントロールプレーン"の仕様がない。IGMPは   なく、上記のように、ドメイン内あるいはドメイン間マルチキャストルーティングプロトコルも   ない。Xcastによってマルチキャストセッションを定義する方法はアプリケーションレベルでの   問題であり、アプリケーションはホストがマルチキャストセッションに参加するためのIGMPを使う   モデルには制限されない。例えば:     −あるアプリケーションでは、IGMPのような受信者参加モデルを使用      することが望ましいかもしれない。     −他のアプリケーションでは、ユーザが参加した一つあるいは複数のパーティに発呼する      モデル(今日の電話会議で受信機のボタンを操作するのと同じような)が期待されるかも      しれない。     −移動するデバイスがセルの境界を横切る時、セル間で"スムーズな受け渡し"を提供する      ために、移動するデバイスに近いセル上でセッションを定義するかもしれない。     −いくつかのアプリケーションにおいてはセッションのメンバは、コマンドラインの引数      として指定されるかもしれない。     −銀行強盗に襲われた銀行に最も近い3台のパトカーまで、銀行強盗のビデオを送信する      ためにGPSを使うアプリケーションが定義されるかもしれない。   このように、アプリケーションの開発者がIGMPモデルの受信者起動の参加モデルに限られることは   ない。Xcastの送信側がチャネルのメンバのアドレスを決定する方法はたくさんある。   IPネットワーク上で音声やマルチメディア会議を解説するために、いくつかのコントロールプレーンが、   SIP[2543]やH.323[H323]を含めて、すでに定義されている。 7.1 SIP(Session Initiation Protocol)     SIPにおいて、ホストはセッションをセットアップするための主導権を得る。   SIPサーバの援助によりセッションは作成される。セッションの状態はホスト内に保存される。 データ配信はいくつかのメカニズム:メッシュ・ユニキャスト、ブリッジまたはマルチキャストに よって達成される。マルチキャスト配信の確立に対して、マルチキャストプロトコルやマルチキャ ストアドレスアロケーションサーバ(MAAS)との通信がやはり必要であることに注意されたい。   "メッシュ・ユニキャスト"あるいは"マルチ−ユニキャスティング"において、アプリケーションは 参加者のユニキャストアドレスを追跡し、それらのアドレスそれぞれにユニキャストを送信する。 3章に記述した理由により、マルチキャストよりもむしろマルチ−ユニキャスティングの方が、 現在は効果的な解決法である。Xcastコードにマルチ−ユニキャストコードを交換することは、 簡単である。開発者が行うべきことは、参加者へのデータを送信する一つの"xcast_send"にそれぞれの 参加者にユニキャストを送信するというループを置き換えることであ疏る。従って、実際の 会議アプリケーションにXcastを組み込むことは簡単である。   XcastとSIPの両方とも、非常に疏なマルチキャストセッションを扱う。Xcast(非常に柔軟性のあ るデータプレーンメカニズム)はSIP(非常に柔軟性のあるコントロールプレーンプロトコル)と 簡単に結合することが判る。アプリケーションがXcast転送を使うことを決定しても、SIPエージェ ントとのインターフェースに影響はない。つまりマルチ−ユニキャスティングと同じSIPメッセー ジを使うことができる。 7.2 受信者起動Joinモデル   前の章において、マルチ−パーティ会議でよく知っている参加者の間でXcastセッションを確立 する方法が議論された。いくつかの場合、招待なしにセッションに参加することができることは 参加者にとって便利である。例えば、ビデオ・チャットの司会者は、初めての参加者のために会議 の入口を開けっ放しにすることを望む。受信者起動Joinモデルは、もし会議に参加することを望む なら、ホストと話すことができるサーバを導入することによって実現できる。 8.オプション情報 8.1 ポートリスト   SIPへの拡張は、セッション内のすべての参加者が同じトランスポート(UDP)ポート番号を使う   ように設定することも出来るが、一般的な場合、それぞれの参加者が異なるポート番号で受信する   ことは可能である。このような場合をカバーするために、Xcastパケットはオプションとして   ポート番号リストを含む。   もし、ポート番号リストが存在するなら、トランスポートレイヤヘッダ内の宛先ポート番号はゼロ   にセットされる。X2U上ではトランスポートレイヤヘッダ内の宛先ポート番号は、ユニキャストパ   ケットの宛先と一致するポート番号にセットされる。 8.2 DSCPsリスト   XcastパケットはDiffServ コードポイント (DSCP) のリストも含む(オプション)。 従来のマルチキャストプロトコルではサービスクラス毎に分かれたグループを作成する必要があるが、   Xcastでは同一チャネル内に異なるサービス要求を有する受信者を収容することが可能である。   IPヘッダ内のDSCPは、DSCPリスト中で最も要求されるDSCPにセットされる。このIPヘッダ内のDSCPは、   例えば使用するスケジューラを決定する。   もし同じ次ホップを持つ2つの宛先が'合流できない'DSCPを持つなら、2つのXcastパケットが   作成される。'合流できない'とは、どちらがより緊急であるか区別できないことを意味する。   8.3 チャネル識別子   送信側は随意にXcastヘッダ内に特別なナンバーチャネル識別子を加えることを決定できる。 もし送信元がこのオプションを使いたくなかったら、チャネル識別子をゼロにセットしなければ   ならない。チャネル識別子がゼロでないなら、ペア(ソースアドレス、チャネル識別子)は、   チャネルをただ一義的に指定する(これはSSMの(S,G)ペアに類似することに注意されたい)。   この文書では、上記を除いて、チャネル識別子に他の意味を割り当てることはしない。   このチャネル識別子は、幾つかの目的において便利である。   1)エラー、フロー制御メッセージなどにおけるチャネルの識別子   2)キャッシュテーブルへのキー[OOMS]。   3)特別な多重分離方式の可能性(ポート番号を除く)   4)・・・ 9.符号化 9.1 一般原理   IPヘッダの送信元アドレスフィールドは、Xcast送信元のアドレスを含む。宛先アドレスフィールドには、   全てのXcastルータのアドレス(リンクローカルなマルチキャストアドレスが割り当てられる)を   運ぶ。これは固定した値を持つべきである。あらゆるXcastルータは、このマルチキャストグループに   加わる。宛先フィールドに固定値を入れる理由は下記のとおりである。   1)宛先アドレスフィールドは、IP擬似ヘッダの一部であり、後者は、トランスポートレイヤの    チェックサム(例えば、UDPチェックサム)によって、カバーされる。従って、固定値にして    おくと、チェックサムの再計算をしなくてすむ。   2)IPsec AH (Authentication Header ) は、IPヘッダの宛先アドレスをカバーするので、その    フィールドに対するどのような変更も防止する。AHとESPペイロードの両方とも、UDPパケット    全体(認証および暗号化により)をカバーする。そのためもし、IPヘッダの宛先アドレスが変更    されても、UDPチェックサムをアップデートできない。   3)IPv6においてXcastが使われるときは、経路制御ヘッダを使用するべきである。このヘッダは、    パケットの行き先がこのルータ宛かどうかをそのルータによってチェックされるだけである。    これは全てのXcastルータのグループの要素である全てのXcastルータを作成することによって    達成される。   4)普通、XcastパケットはXcastルータに見えるだけである。しかしながら、もしXcastに対応して    いないルータが、偶然もしくは意図的にXcastパケットを受信したら、Xcastパケットは宛先アド    レスフィールドにマルチキャストアドレスを入れて運ぶので、そのルータはICMPエラーを送信    しない([1812])。   エンドノードに到着するまで、マルチキャストアドレスが宛先フィールドに滞在するときに、   いくつかの利点を持つだけであることに注意されたい(つまりX2Uと結合しない)。 9.2 IPv4   [AGUI]と[1770]はIPv4オプションに複数の宛先を入れて運ぶことを(僅かに異なる目的のために)   提案した。しかし、柔軟性(ヘッダのサイズの制限)が制限されるので、Xcastは他のアプローチ   を採用する。宛先リストは、独立したヘッダで符号化される。IPv4のXcastヘッダ(つまりXcast4)は、   IPv4ヘッダとトランスポートヘッダの間に置かれる。 [ IPv4 ヘッダ| Xcast4|トランスポートヘッダ|ペイロード ]   Xcastヘッダは、パケットのデータの一部に加えられるので、もし送信側がIPフラグメンテーションを   避けたいなら、Xcastヘッダのサイズを考慮する必要があることにも注意されたい。 9.2.1 IPv4ヘッダ   Xcast4ヘッダは、IPヘッダの次に置かれる。IPヘッダのプロトコル番号は、PROTO_Xcastである。   ソースアドレスフィールドは、Xcast送信元のアドレスである。宛先アドレスフィールドは、   全てのXcastルータのアドレスである。   9.2.2 Xcast4ヘッダ   Xcast4ヘッダを、図4に示す。それは、2つの部分-固定部分(最初の12オクテット)と、   2つの可変長の部分-により構成される。       図4   VERSION = Xcastのバージョンナンバー。この文書はバージョン1。   A = 匿名ビット:このビットがセットされていると、ビットマップ上の対応するビットがゼロで     ある宛先アドレスはゼロで上書きしなければならない。   X = Xcastビット:このビットがセットされていると、ルータはXcastパケットをユニキャスト     パケットに変更してはならない。すなわちエンド−エンドでXcastパケットのままにしなければ     ならない。このビットは、IPsecが適用されるときに役に立つ。   D = DSCPビット:このビットがセットされていると、各宛先毎にDS−バイトが設定されている。   P = ポートビット:このビットがセットされていると、各宛先毎にポート番号が設定されている。   NBR_OF_DEST = 宛先の総数   CHECKSUM = Xcastヘッダだけのチェックサム。これは、Xcastヘッダが処理される各ポイントで         検証・再計算される。チェックサムフィールドは、ヘッダの全てのバイトの1の補数和 の1の補数を16ビット表示したものである。チェックサムの計算のため、チェックサム フィールドの値はゼロである。チェックサムが(ffs)であるべきか否かはまだ明らか ではない。もし1つの宛先だけが間違いならば、パケットをN-1の正確な宛先および1つ の間違った宛先に転送することがまだ有益であるかもしれない。   PROT ID =次に続くヘッダーのプロトコルを指定。   LENGTH=4オクテット単位のXcastヘッダの長さ。このフィールドは、宛先の数の上限となる。       その値は、NBR_OF_DESTフィールドとD、Pのビットによって決定される。   RESV=R=予約済。送信時には0であり、受信時は無視されなければならない。   CHANNEL IDENTIFIER=4オクテットのチャネル識別子。(8.3章参照)   最初の変数部分は、アドレスとDSCPのリストであり、2番目の変数部分は、ポート番号のリストである。   両方とも4オクテット単位で区切る。2番目の変数部分は、P-ビットがセットされたときのみ、存在する。   図5は、P−ビットがセットされD−ビットがゼロ(この例では、Nは奇数)の場合の変数部分の例を示す。       図5   BITMAP=宛先ごとに、宛先がまだツリーの枝上に存在するかどうかを示すビットをビットマップ内       に持つ。最初のビットは、リストの最初の宛先と一致する。このフィールドは、4オクテット単位で       調整される(たとえば、49個の宛先のために、64ビットのビットマップが作られる)。       もし、XcastがIpsecと組み合わせて用いられるなら、そのビットマップは−ルータ上で       変化するので−新たに定義されるべきIPv4オプションに移動しなければならない。   宛先リスト。個々のアドレスサイズは、4オクテットである。   ポート番号のリスト。2オクテットの宛先ポート番号のリストであり、そして、個々のポートが   前述の宛先アドレスの位置と一致している。 9.3 IPv6   Xcast6ヘッダの符号化は、Xcast情報をIPv6の拡張ヘッダに蓄えるという他は、IPv4に似ている。     [ IPv6 ヘッダ | Xcast6 | トランスポートヘッダ | ペイロード ]   9.3.1 IPv6ヘッダ   IPv6ヘッダは、’経路制御ヘッダ’でNextHeaderの値を運ぶ。   送信元アドレスフィールドは、送信側のXcastのアドレスを含む。   宛先アドレスフィールドは、全てのXcastルータのアドレスを運ぶ。  9.3.2 Xcast6ヘッダ   Xcast6ヘッダもまた、固定部分と可変部分から構成される。固定部分と可変部分の先頭部は、   経路制御ヘッダによって運ばれる。2番目の可変部分は、宛先拡張ヘッダで運ばれる。 9.3.2.1 経路制御ヘッダ   Xcast4におけるP-ビットは、宛先拡張の有無によらず暗黙に決定されるので、Xcast4ではPビット   はない(図6)。                      図6   HdrExtLen=ヘッダの長さは、8オクテット単位で表される。従って、最大127の宛先をリスト         できる(NBR_OF_DESTが7ビットである理由)。   RouteType=Xcastは、IANAによって割り当てられなければならない。   4番目のオクテットは、0にセットされる。   R=予約   CHANNEL IDENTIFIER=16オクテットのチャネル識別子(8.3節参照)   他のフィールドは、9.2.2項で定義されている。   'アドレスとDSCPのリスト'は、8オクテット単位で区切られる。このビットマップのサイズは、   宛先番号で決定され、64ビットの倍数である。 9.3.2.2 宛先拡張ヘッダ(終点オプションヘッダとも呼ばれる)   オプションで宛先拡張ヘッダ(図7)は、ポート番号のリストを指定するために存在する。   この宛先ヘッダは、宛先ノードによって評価されるだけである。                      図7   ポートのオプションタイプは、IANAによって割り当てられるべきである。最初の3ビットは、もし   そのオプションが未知ならばそのパケットは破棄し、そのオプションは途中で変更できないと言う   ことを示すために「010」にする必要がある。   ポート番号は、経路制御ヘッダに指定された宛先ナンバーと等しい必要がある。 10. 上位レイヤプロトコルへの影響   Xcastヘッダ内のいくつかのフィールドは、配信パスに沿ってパケットが移動すると、変更される。   これにより以下のような影響がある。 10.1 トランスポートレイヤヘッダのチェックサム計算   トランスポートレイヤヘッダにおいてチェックサム計算の対象は、IP擬似ヘッダ、 トランスポートヘッダ、そしてペイロード(IPv6拡張ヘッダは対象外)を含む。   Xcastパケットから普通のユニキャストパケットへの変換−X2U−は、IPヘッダ宛先 フィールド内のマルチキャストアドレスが最終宛先のアドレスに置き換えられる。 もし、Xcastヘッダがポートリストを含むなら、トランスポートレイヤのポート番号 (ゼロにすべき)は、宛先まで一致するポートナンバーによって置き換えられる必要もある。 これによりチェックサムの再計算が必要となる。これは、チェックサムの完全な再計算を 要求するわけではなく、例えばIPv4のような増分計算のみであることに注意されたい。   Checksum’ =〜(〜Checksum + 〜daH+ 〜daL+ 〜daH’ + 〜daL’ + 〜dp + dp’)   ここで、“、”は新しい値を示し、“da”は宛先アドレス、“dp”は宛先ポート、 “H”と“L”はそれぞれ16ビットよりも高いか低いかを示す。 10.2 IPsec   これは、[PARI]で述べられている。  11.段階的展開 11.1 トンネリング   Xcastを認識しないルータを持つネットワークでXcastを展開する一つの方法はXcastピア間で、   "トンネル" をセットアップすることである(Mboneアプローチ)。これにより既存のネットワーク   上にバーチャルネットワークレイヤの作成が可能になる[2003]。Xcastルータは、標準ユニキャスト   ルーティングプロトコル(例えば、RIP、OSPF、ISIS)経由で、Xcastルーティング情報を交換し、   維持する。作成されたXcastルーティングテーブルはXcastの次ホップ相当する宛先を含む単なる   標準ユニキャストルーティングテーブルである。このようにして、パケットは、他のXcastルータ   にホップバイホップで転送される、または、ネットワーク上のXcastでないルータを"トンネル"する。   例えば、Aが以下の図8において、B、C、Dに分配させようとすることを想定すると、"X"ルータは   Xcast可能であり、"R"は可能でない。図9は、Xcastトンネルを経由して作成されたルーティング   テーブルを示す。                      R4――――B                      /                    /    A――――X1――――R2――――X3   R8――――C                    ¥               /                     ¥            /                      R5――――R6――――X7                                  ¥                                  ¥                                   R9――――D                      図8   ルータX1は、XcastピアであるX3とトンネルを確立する。ルータX3は、XcastピアであるX1、X7と   トンネルを確立する。ルータX7は、XcastピアであるX3とトンネルを確立する。                      図9   送信元AはXcastルータとしてX1を自動選択し、Xcastパケットを送信する。ルータX1はその   パケットの宛先リストを持っている。X1とX3の間のリンク上のパケットを、図10に示す。            図10   X3がこのパケットを受信すると、次のように処理する:   −パケットにリストされた宛先のそれぞれに対してXcastの次ホップを決定するために、    Xcastルーティングテーブルのルートテーブルを照合する。   −Xcastの次ホップが見つからなかったら、パケットを複製し、宛先へ標準ユニキャストとして    送信する。   −Xcastの次ホップが見つかった宛先に対して、次ホップを基礎に宛先を分割する。   −前のステップで見つけたそれぞれのXcastの次ホップに対してパケットのコピーがひとつずつ    あるように、そのパケットを複製する。   −与えられた次ホップ向けのコピー内のリストは、その次ホップへの経路を定めるべき宛先を    含むように、それぞれのコピー内の宛先リストを変更。   −次ホップ上に変更されたパケットのコピーを送信。   −最適化: 特定のXcastの次ホップの宛先が一つだけなら、Xcastパケットとしてそれをフォーマット    することにマルチキャストとしての利点が全然ないので、標準のユニキャストパケットとして    パケットを宛先に送信する。   従って上記の例では、X1は<B C D>の宛先リスト用いて、X3に単一パケットを送信する。   このパケットは、宛先X3を持つユニキャストパケットとしてR2によって受信される。そして、   R2は、Xcastについての知識を全く持たずに転送する。X3はパケットを受信するとき、上記の   アルゴリズムによって、普通のユニキャストパケットとして宛先<B>にパケットのコピーを送信   する。そして<C、D>の宛先リストを持つパケットのコピーををX7に送信する。R4、R5そしてR6は、   Xcastの知識がない標準のルータとして振舞う。X7はパケットを受信すると、そのパケットを   解析し、<C>と<D>宛ての普通のユニキャストパケットアドレスを個々に伝送する。  11.2 未成熟のX2U   下流のルータがXcastとして動作しないとわかったら、未成熟のX2Uを実行できる。すなわち、   次ホップとしてこのルータを持つXcastヘッダ内のそれぞれの宛先にユニキャストパケットを   送信する。こうしてXcastパケットが実際の分岐点に到着する前に、複製が行われる。   ルータが、その隣接ルータがXcastとして動作可能か否かを知るためのメカニズム(プロトコル/   拡張プロトコル)がffsである。他の方法として、一つはXcastとしての有効性を知らせるための   ルーティングプロトコルの拡張がある。またもう一つは、そのルータに''Xcast ping'(宛先として   自身のアドレスを含み、パケットが戻ってくるかどうかチェックするというXcastパケットを送信   する。)の周期的な送信がある。    11.3 半透明トンネリング(IPv6のみ)   これは、トンネルの(手動の)設定を要求しないという意味において、トンネルの最適化である。   ホップバイホップのXcast6ヘッダを加えることによって可能である。IPv6パケットは、   IPv6のホップバイホップオプションを使うことによってルート上のルータでの付加的な処理を   開始/起動できる。   Xcastホップバイホップオプションのタイプは、Xcast6を認識できないルータがXcast6データグラムを   正常なIPv6データグラムとして扱え、IPv6ヘッダ内の宛先に転送できるように、識別コード『00』   を持つ。   もし、少なくとも全ての関係するホストがアップグレードされるならば、パケットは、全ての   メンバーに伝送される。   宛先B、CおよびDに半透明なトンネリング経由で、送信元AがXcastパケットを送信するとき、   Aは図11のようなパケットを作成する。最後の宛先のひとつは、外部IPヘッダの宛先アドレス   フィールドに入れられる。    図11   半透明トンネリングは、もし宛先が異なる次ホップのときに、トンネル上のXcasatルータが宛先   と分岐をチェックすることを可能にする特別なトンネリング技術である。   Xcast IPv4オプションの導入して、このテクニックは、IPv4ネットワークに当てはめることが   できることに注意されたい。  11.4 特殊ケース:ネットワークサポートなしでの展開   Xcastを展開する特殊な方法に、ホストのみアップグレードする方法がある。トンネルの終点と して最後の宛先のひとつにトンネリングを適用(11.1節と11.3節参照)することによって、全ての   ホストがXcastを認識するとき、Xcastパケットは、全ての宛先に配送される。透明、半透明な   トンネリングの両方とも、使用できる。   上記の例では、もしホストBがこのパケットを受信すると、Xcastヘッダ内のほかの宛先を通知する。   Bは、新しいXcastパケットを作成し、残っている宛先のひとつにそれを送信する。   Xcast6、半透明なトンネリングの場合、Xcastルータは、トンネルを設定する必要なしにネットワークに   導入される。   この方法の欠点は次の通り:   −セッション内の全てのホストの、アップグレードが必要である。   −非最適ルーティング   −匿名性の問題:ホストはセッション内の、他のパーティの属性を知ることができる(会議におけ    る大きな問題ではないが、たぶん幾つか他のアプリケーション?)。   −ホストは、ネットワーク機能を実行する必要があり、下流リンクと同じ帯域幅を持つ上流リンク    が必要である。 12.(ソケット)API   Xcastの最も簡単な用途では、Xcastパケットの最後の宛先は、普通のユニキャストUDPパケットを   受信する。これは、ホストが、標準あるいは未修正のTCP/IPスタックでXcastパケットを受信する   ことができることを意味する。   ホストは、raw socket上でXcastパケットを送る小さいXcastライブラリを持つ標準のTCP/IPスタックで   Xcastパケットも送ることができる。これは、どのようなカーネル変更なしに、UnixとWindowsプラット   フォーム上にXcastに基づいたアプリケーションを実装するのに使用された。   別の可能性として、ソケットインタフェースをわずかに修正する方法である。例えば、それは、   「sendto」のように働くけれども、「sendto」が使う単一のアドレスの代わりに終点アドレスの   リストを使う「xcast_sendto」機能を追加することになろう。  13.セキュリティの考察   [PARI]参照。