メインコンテンツまでスキップ

1. Introduction (はじめに)

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

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

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

FF3x::4000:0001 から FF3x::7FFF:FFFF の範囲のアドレスは、IANA による割り当てのために [IPv6-MALLOC] で予約されています。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 を義務付けているため、これらは無効として指定されます。) このような無効なアドレスに送信されたパケットの処理は未定義です -- ルーターまたはホストは、そのようなパケットを破棄することを選択してもよい (MAY)。

SSM アドレスに送信されたデータグラムには、ソース特定マルチキャスト配信セマンティクスが提供されます。つまり、送信元 IP アドレス S と SSM 宛先アドレス G を持つデータグラムは、送信元 S によってアドレス G に送信されたデータグラムの受信を具体的に要求した各上位層「ソケット」にのみ配信されます。SSM アドレス G と送信元ホストアドレス S に対して、(S,G) によって識別されるネットワークサービスは、「チャネル」と呼ばれます。RFC 1112 の ASM モデルとは対照的に、SSM は 1対多配信のネットワーク層サポートのみを提供します。

ソース特定マルチキャストの利点は以下の通りです:

  • 2つのソースが同じソース特定宛先アドレスを同時に使用する場合のトラフィックの交差配信の排除。複数のソースおよび異なるアプリケーションによる SSM 宛先アドレスの同時使用が明示的にサポートされています。

  • 上記の結果として、ソース特定アドレスを選択する際のホスト間の調整の必要性の回避。

  • ASM サービスモデルを提供するために必要なルータープロトコルおよびアルゴリズムの多くの回避。例えば、PIM - Sparse Mode (PIM-SM) プロトコル [PIM-SM] の「共有ツリー」およびランデブーポイント (Rendezvous Points) は、ソース特定モデルをサポートするために必要ではありません。実際、SSM をサポートするために必要なルーターメカニズムは、主に ASM をサポートするために使用されるもののサブセットです。例えば、PIM-SM プロトコルの最短パスツリーメカニズムは、SSM セマンティクスを提供するために適応させることができます。

ASM と同様に、受信者のセットは SSM 送信者には不明です。SSM ソースには、受信者の身元もその数も提供されません。

SSM は、アプリケーションの開始前に身元が判明している1つ以上の送信者を持つ、普及型アプリケーションに特に適しています。例えば、プライマリソースがフェイルオーバーした場合にセカンダリデータソースを提供することを望むデータ普及アプリケーションは、各ソースに1つのチャネルを使用し、両方を受信者に広告することによってこれを実装するかもしれません。SSM は、すべての参加者の身元が事前に判明していないマルチソースアプリケーションを構築するために使用できますが、この場合、マルチソースの「ランデブー」機能はネットワーク層では発生しません。ユニキャストを基礎となるトランスポートとして使用するアプリケーションと同様に、この機能はアプリケーションまたはアプリケーション層ライブラリによって実装できます。

クライアントがサーバーがリッスンする「サービスロケーショングループ」に直接マルチキャストクエリを送信する形式のマルチキャストリソース発見は、SSM では直接サポートされていません。

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は、RFC 2119 [RFC2119] で説明されているように解釈されるべきです。

この文書は、ソース特定マルチキャストアドレスのセマンティクスを定義し、その使用を規定するポリシーを指定します。特に、SSM アドレスに送信されるデータグラムに適用されるインターネットネットワークサービスの拡張を定義し、ネットワークサービスをサポートするためのホスト拡張を定義します。これらのアドレスを使用するホスト、ルーター、アプリケーション、およびプロトコルは、この文書で概説されているポリシーに準拠しなければなりません (MUST)。ホストが準拠しない場合、そのホストまたは同じ LAN 上の他のホストが SSM チャネルに送信されたトラフィックを受信できなくなる可能性があります。ルーターが準拠しない場合、SSM トラフィックが不要なネットワークの部分に配信され、ネットワークに不必要な負荷がかかる可能性があります。