1. 導入

インターネットプロトコル (Internet Protocol, IP) マルチキャストサービスモデルは RFC 1112 [RFC1112] で定義されている。RFC 1112 は、IP マルチキャストアドレス (224.0.0.0 から 239.255.255.255) G に送信されるデータグラムが、アドレス G に送信されたデータグラムの受信を要求したそれぞれの「上位層プロトコルモジュール」に配信されることを規定している。RFC 1112 は、宛先アドレス G によって識別されるネットワークサービスを「ホストグループ」(host group) と呼んでいる。このモデルは、一対多および多対多のグループ通信の両方をサポートする。本ドキュメントでは、RFC 1112 で定義されたマルチキャストモデルを指して「任意ソースマルチキャスト」(Any-Source Multicast, ASM) という用語を使用する。RFC 3513 [RFC3513] は、ASM セマンティクスを持つ IPv6 マルチキャストアドレスの形式を規定している。

232/8 (232.0.0.0 から 232.255.255.255) の範囲の IPv4 アドレスは、現在、ソース特定マルチキャスト (Source-Specific Multicast, SSM) 宛先アドレスとして指定され、ソース特定のアプリケーションおよびプロトコルによる使用のために予約されている [IANA-ALLOC]。

IPv6 については、[IPv6-UBM] の規約により、アドレスプレフィックス FF3x::/32 がソース特定マルチキャストのために予約されており、ここで 'x' は任意の有効なスコープ識別子 (scope identifier) である。[IPv6-UBM] の用語を用いると、すべての SSM アドレスは P=1、T=1、plen=0 でなければならない。[IPv6-MALLOC] はさらに、SSM アドレスのネットワークプレフィックスフィールドもゼロに設定することを要求しているため、すべての SSM アドレスは FF3x::/96 の範囲に収まる。将来的なドキュメントでは、新しい IP アドレスから MAC アドレスへのマッピングが定義される等の場合に、非ゼロのネットワークプレフィックスフィールドを許可する可能性がある。したがって、アドレスの割り当ては FF3x::/96 の範囲内で行われるべきであるが、システムは将来のネットワークプレフィックスフィールドの用途との互換性を保つため、FF3x::/32 全体を SSM アドレスとして扱わなければならない。

FF3x::4000:0001 から FF3x::7FFF:FFFF の範囲のアドレスは、[IPv6-MALLOC] により IANA の割り当て用に予約されている。FF3x::8000:0000 から FF3x::FFFF:FFFF の範囲のアドレスは、[IPv6-MALLOC] に記述されているように、ホストによる動的割り当てが許可されている。FF3x::0000:0000 から FF3x::3FFF:FFFF の範囲のアドレスは、無効な IPv6 SSM アドレスである。([IPv6-MALLOC] は FF3x::0000:0001 から FF3x::3FFF:FFFF について P=0 および T=0 を設定しなければならないとしているが、SSM については [IPv6-UBM] が P=1 および T=1 を要求しているため、これらのアドレスは無効として指定されている。) このような無効なアドレスに送信されるパケットの扱いは規定されていない ― ルーターまたはホストはそのようなパケットを破棄することを選択してもよい。

SSM アドレスに送信されるデータグラムに対しては、ソース特定マルチキャスト配信セマンティクスが提供される。すなわち、送信元 IP アドレス S、SSM 宛先アドレス G を持つデータグラムは、明示的に S からアドレス G に送信されたデータグラムの受信を要求した上位層の「ソケット」(socket) にのみ配信される。RFC 1112 の ASM モデルと比較すると、SSM はネットワーク層において一対多の配信のサポートのみを提供する。

ソース特定マルチキャストの利点は以下のとおりである。

2 つの送信元が同じソース特定宛先アドレスを同時に使用する場合の、トラフィックの交差配信の排除。複数の送信元および異なるアプリケーションが同じ SSM 宛先アドレスを同時に使用することが明示的にサポートされる。
上記の特性により、ソース特定アドレスを選択する際のホスト間の調整の必要性が回避される。
ASM サービスモデルを提供するために必要とされた多くのルータープロトコルおよびアルゴリズムが不要になる。たとえば、PIM - Sparse Mode (PIM-SM) プロトコル [PIM-SM] の「共有ツリー」(shared trees) およびランデブーポイント (Rendezvous Points) は、ソース特定モデルをサポートするために必須ではない。SSM をサポートするために必要なルーター機構は、実際には ASM をサポートするために必要な機構のサブセットである。たとえば、PIM-SM プロトコルの最短パスツリー機構は、SSM セマンティクスを提供するように調整できる。

ASM と同様に、受信者の集合は SSM 送信者には知らされない。SSM 送信者は、受信者の識別情報も、受信者の数も得ることはない。

SSM は、1 つまたは複数の送信者が存在し、かつ送信者の識別情報がアプリケーション開始前に既知であるような、配布型 (dissemination-style) アプリケーションに特に適している。たとえば、メインデータソースに障害が発生した場合にバックアップデータソースを提供したいデータ配布アプリケーションは、各送信元に 1 つのチャネルを使用し、受信者にその両方のチャネルを通知することができる。SSM は、すべての参加者の識別情報が事前に既知であるとは限らないマルチソースアプリケーションを構築するためにも使用できるが、その場合、マルチソースの「ランデブー」(rendezvous) 機能はネットワーク層では発生しない。単播 (unicast) を下位トランスポートとするアプリケーションと同様に、この機能はアプリケーション自体またはアプリケーション層ライブラリによって実装できる。

クライアントが、サーバーがリッスンしている「サービスロケーショングループ」(service location group) にマルチキャストクエリを直接送信するという形式のマルチキャストリソースディスカバリは、SSM によって直接サポートされない。

本ドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、"OPTIONAL" は、RFC 2119 [RFC2119] で説明されているとおりに解釈されなければならない (MUST)。

本ドキュメントは、ソース特定マルチキャストアドレスのセマンティクスを定義し、その使用を管理する方針を規定する。具体的には、SSM アドレスに送信されるデータグラムに適用されるインターネットネットワークサービスの拡張を定義し、そのネットワークサービスをサポートするホストの拡張を定義する。これらのアドレスを使用するホスト、ルーター、アプリケーションおよびプロトコルは、本ドキュメントで概説された方針を遵守しなければならない (MUST)。ホストが遵守しない場合、そのホストまたは同一 LAN 上の他のホストが、ある SSM チャネルに送信されるトラフィックを受信できなくなる可能性がある。ルーターが遵守しない場合、SSM トラフィックがネットワーク内の不要な箇所に配信され、ネットワークに不必要な負荷をもたらす可能性がある。