Guest

Cisco IP Multicast

IPマルチキャスト テクノロジーの概要

Downloads
IPマルチキャスト テクノロジーの概要

概要


IPマルチキャスト テクノロジーの概要


目次

IPマルチキャスト テクノロジーの概要
IPマルチキャストの基本事項
マルチキャスト グループの概念
IPマルチキャスト アドレス
ドメイン内マルチキャスト プロトコル
ドメイン間マルチキャスト プロトコル
関連資料
まとめ

IPマルチキャスト テクノロジーの概要

バージョン履歴

バージョン番号  日付  注記 
1 2000/9 この資料が作成されました。
2 2001/10/16 すべての項目を更新し、新規の項目を追加しました。
3 2002/4/18 すべての項目を更新し、新規の項目を追加し、いくつかの項目を削除しました。

従来のIP通信では、ホストはパケットを単一のホスト(ユニキャスト伝送)またはすべてのホスト(ブロードキャスト伝送)に送信できます。IPマルチキャストは、第三の可能性を提供するものであり、ホストがパケットをホストのサブセット(グループ)に送信できるようにします。この資料では、IPマルチキャストについて簡単に概要を説明します。最初に、マルチキャスト グループの概念、IPマルチキャスト アドレス、レイヤ2マルチキャスト アドレスなどの一般的な事項について説明します。そのあと、Internet Group Management Protocol(IGMP)、Cisco Group Management Protocol(CGMP)、Protocol Independent Multicast(PIM)、Pragmatic General Multicast(PGM)といったドメイン内マルチキャスト プロトコルについて説明します。最後に、Multiprotocol Border Gateway Protocol(MBGP)、Multicast Source Directory Protocol(MSDP)、Source Specific Multicast(SSM)といったドメイン間プロトコルについて説明します。

この資料は、IPマルチキャストに関する新しい知識を補っていただくことを目的としています。読者はTCP/IP、Border Gateway Protocol(BGP)、およびネットワーキング全般について基礎知識があることを前提とします。この資料で言及されている事項の詳細については、Beau Williamson著『Developing IP Multicast Networks, Volume 1』(Cisco Press、1999)を参照してください。

return to top

IPマルチキャストの基本事項

IP マルチキャストは、何千人もの社内ユーザまたはホーム ユーザ向けに単一のストリームで情報を同時に配信することにより、トラフィックを減らす省帯域テクノロジーです。マルチキャストを利用するアプリケーションとしては、ビデオ会議、企業内通信、遠距離ラーニングのほか、ソフトウェア、株式市況、ニュースなどの配信があります。

IPマルチキャストは、最小限のネットワーク帯域幅を使用して、送信元にも受信者にも負担をかけずに、アプリケーションのソース トラフィックを複数の受信者に配信します。PIMやその他のサポートするマルチキャスト プロトコルがイネーブルに設定されているシスコ ルータによってパスが分岐する地点で、マルチキャスト パケットが複製され、複数の受信者に対する最も効率的なデータ配信が行われます。

IPマルチキャスト以外の手段では、多くの場合、送信元がデータの2つ以上のコピーを送信しなければなりません。アプリケーション レベル マルチキャストのように、送信元が受信者ごとに別々のコピーを送信しなければならない場合もあります。狭帯域アプリケーションでも、受信者が何千人にものぼれば、Cisco IPマルチキャストを使用するメリットがあります。MPEGビデオのような広帯域アプリケーションの場合には、1つのストリームのために空いている帯域幅の大半が必要になることがあります。このようなアプリケーションでは、複数の受信者に同時に情報を送信するにはIPマルチキャストを使用するしかありません。図1に、IPマルチキャストによる1つの送信元から多数の受信者へのデータ配信を示します。

図1:多数の受信者へのマルチキャスト伝送


図1の例では、受信者(特定のマルチキャスト グループ)は送信元からのビデオ データ ストリームの受信を希望しています。受信者はネットワーク上のルータにIGMPホスト レポートを送信することにより、この意向を表明します。その結果、ルータは送信元から受信者にデータを配信する役割を担うことになります。ルータはPIMを使用して、マルチキャスト配信ツリーをダイナミックに作成します。これにより、送信元と受信者の間のパス上に存在するネットワーク セグメントだけに、ビデオ データ ストリームが配信されます。次に、このプロセスについて詳しく説明します。

return to top

マルチキャスト グループの概念

マルチキャストは、グループという概念を基盤としています。マルチキャスト グループとは、特定のデータ ストリームを受信したいという意向を表明した、任意の受信者グループです。このグループには物理的または地理的な制約がなく、インターネットまたはプライベート インターネットワーク上のどの場所にホストが存在しても構いません。特定のグループ宛に送信されるデータの受信を希望するホストは、IGMPを使用してそのグループに加入する必要があります(IGMPについては、「IGMP」で後述します)。各ホストは、該当するグループのメンバーでないとデータ ストリームを受信できません。

return to top

IP マルチキャスト アドレス

IPマルチキャスト アドレスは、 特定のグループに加入し、そのグループを宛先とするマルチキャスト トラフィックの受信を希望しているIPホストの「集合」を表します。次に、IPv4マルチキャスト アドレスの表記規約について説明します。

IP クラスDアドレス

IPマルチキャスト アドレスの割り当ては、Internet Assigned Numbers Authority(IANA)が管理しています。IANAにより、IPマルチキャストに使用するIPv4クラスDアドレス スペースが割り当てられています。したがって、IPマルチキャスト グループ アドレスは、すべて224.0.0.0~239.255.255.255の範囲に属します。


注:クラスDアドレスの範囲を使用するのは、IPマルチキャスト トラフィックのグループ アドレスまたは宛先アドレスに限られます。マルチキャスト データグラムの送信元アドレスは、常にユニキャスト送信元アドレスです。

表1に、この資料で説明するマルチキャスト アドレスの範囲を要約します。

表1:マルチキャスト アドレス範囲の割り当て
項目  範囲 
予約済みリンク ローカル アドレス 224.0.0.0/24
グローバル スコープ アドレス 224.0.1.0 ~ 238.255.255.255
SSMアドレス 232.0.0.0/8
GLOPアドレス 233.0.0.0/8
限定スコープ アドレス 239.0.0.0/8

予約済みリンク ローカル アドレス

224.0.0.0/24というアドレス範囲は、IANAによってローカル ネットワーク セグメント上のネットワーク プロトコル用に予約されています。これらのアドレスを指定されたパケットは、ルータにより転送されることはありません。リンク ローカル宛先アドレスを指定されたパケットは通常、Time to Live(TTL)値1で送信されます。ルータはこのパケットを転送しません。

これらのアドレスは、ネットワーク プロトコルによるルータの自動検出と、重要なルーティング情報の伝達に使用されます。たとえば、Open Shortest Path First(OSPF)は、IPアドレス224.0.0.5および224.0.0.6をリンクステート情報の交換に使用します。表2に、いくつかの代表的なリンク ローカルIPアドレスの例を示します。


表2:リンク ローカル アドレスの例

IPアドレス  用途 
224.0.0.1 このサブネット上の全システム
224.0.0.2 このサブネット上の全ルータ
224.0.0.5 OSPFルータ
224.0.0.6 OSPF指定ルータ
224.0.0.12 Dynamic Host Configuration Protocol(DHCP)サーバ/リレー エージェント

グローバル スコープ アドレス

224.0.1.0~238.255.255.255の範囲のアドレスを、グローバル スコープ アドレスといいます。組織間およびインターネット経由でのデータのマルチキャストには、これらのアドレスを使用します。

これらのアドレスの一部は、IANAによってマルチキャスト アプリケーション用に予約されています。たとえば、IPアドレス224.0.1.1は、Network Time Protocol(NTP)用に予約されています。

IPマルチキャスト用に予約されたIPアドレスについては、RFC 1112『Host Extensions for IP Multicasting』に定義されています。予約済みIPマルチキャスト アドレスの詳細については、次のURLで参照できます。
http://www.iana.org/assignments/multicast-addresses


注: IETFのWebサイト(http://www.ietf.org)で、すべてのRFCおよびInternet Engineering Task Force(IETF)ドラフトを参照できます。
SSMアドレス

232.0.0.0/8の範囲内のアドレスは、SSM用に予約されています。SSMは、1対多コミュニケーションにおける効率的なデータ配信メカニズムを提供するPIMプロトコルの拡張機能です。SSMについては、 「SSM」 で後述します。

GLOPアドレス

RFC 2770『GLOP Addressing in 233/8』では、AS番号をすでに予約している組織がスタティックに定義するアドレス用に、233.0.0.0/8のアドレス範囲を予約することを提唱しています。この方法を、GLOPアドレッシングといいます。233.0.0.0/8アドレス範囲の2番目および3番目のオクテットに、ドメインのAS番号を指定します。たとえば、AS 62010は16進フォーマットではF23Aと表記されます。これをF2および3Aの2つのオクテットに分けると、10進フォーマットでそれぞれ242および58になります。これらの値を使用して、233.242.58.0/24というサブネットを、AS 62010用にグローバルに予約します。

限定スコープ アドレス

239.0.0.0/8の範囲内のアドレスを、限定スコープ アドレスまたは管理スコープ アドレスといいます。これらのアドレスは、ローカル グループまたは組織内に限定して使用することがRFC 2365『Administratively Scoped IP Multicast』に定められています。企業、大学などの組織は、限定スコープ アドレスを使用して、ドメイン外部には転送されないローカル マルチキャスト アプリケーションを実装することができます。通常、このアドレス範囲のマルチキャスト トラフィックをAutonomous System(AS;自律システム)またはユーザが定義した任意のドメインの外部に流出させないようにするためのフィルタを、ルータに設定します。ASまたはドメインの内部では、限定スコープ アドレス範囲をさらに区分して、ローカル マルチキャスト境界を定義することができます。このような区分をアドレス スコーピングといい、これらの小規模なドメイン間でのアドレスの再利用を可能にします。

レイヤ2マルチキャスト アドレス

従来、LANセグメント上のNetwork Interface Card(NIC)が受信できるのは、カードに設定されたMACアドレスまたはブロードキャストMACアドレスを宛先とするパケットに限られていました。IPマルチキャストでは、共通の宛先MACアドレスを持つ1つのデータ ストリームを、複数のホストが受信することが要求されます。複数のホストが同じパケットを受信しても、マルチキャスト グループを区別できるようにするために、何らかの方法を考案する必要がありました。

そのための1つの方法は、IPマルチキャスト クラスDアドレスを直接、MACアドレスに対応づけることです。現在ではこの方法を使用して、NICは多くの異なるMACアドレス(自身のユニキャスト アドレス、ブロードキャスト アドレス、およびマルチキャスト アドレス範囲)を宛先とするパケットを受信できるようになっています。

各種のIEEE LAN仕様には、ブロードキャスト パケットおよびマルチキャスト パケットの送信に関する条件が定められています。802.3仕様では、最初のオクテットの0ビットを使用して、ブロードキャスト フレームまたはマルチキャスト フレームを表します。図2に、イーサネット フレームのブロードキャスト ビットまたはマルチキャスト ビットの位置を示します。

図2:IEEE 802.3 MACアドレスのフォーマット

このビットは、フレームの宛先がホストのグループまたはネットワーク上の全ホストであることを表します(ブロードキャスト アドレスの場合、0xFFFF.FFFF.FFFF)。

IPマルチキャストでは、この機能を利用してLANセグメント上のホスト グループにIPパケットを送信します。

イーサネットMACアドレス マッピング

IANAは、16進フォーマットの01:00:5Eで始まるイーサネットMACアドレスのブロックを所有しています。このブロックの半分が、マルチキャスト アドレスに割り当てられます。0100.5e00.0000 ~ 0100.5e7f.ffffの範囲が、IPマルチキャスト用のイーサネットMACアドレスに使用できます。

この割り当てでは、イーサネット アドレスの中の23ビットを、IPマルチキャスト グループ アドレスに対応づけることができます。マッピングにより、イーサネット アドレスのこれらの23ビットに、IPマルチキャスト グループ アドレスの下位23ビットが書き込まれます(図3を参照)。

図3:IPマルチキャストとイーサネットまたはFDDI MACアドレスのマッピング

このマッピングでは、IPマルチキャスト アドレスの上位5ビットが廃棄されるので、形成されるアドレスは固有ではありません。実際には、32個の異なるマルチキャスト グループIDが、同じイーサネット アドレスに対応づけられることになります(図4を参照)。ネットワーク管理者がIPマルチキャスト アドレスを割り当てる際は、このことを考慮する必要があります。たとえば、224.1.1.1と225.1.1.1は、レイヤ2スイッチ上の同じマルチキャストMACアドレスに対応します。あるユーザが(224.1.1.1で表される)グループAに加入し、別のユーザが(225.1.1.1で表される)グループBに加入する場合、これらのユーザはどちらも、AおよびBのストリームを両方とも受信することになります。このような状況では、マルチキャスト配置による効率性が限られたものになります。

図4:MACアドレスのあいまい性

return to top

ドメイン内マルチキャスト プロトコル

ここでは、ドメイン内マルチキャスト プロトコルについて説明します。ドメイン内マルチキャスト プロトコルとは、マルチキャスト ドメインの内部でマルチキャストをサポートするために使用するプロトコルを意味します。ここで説明する内容は次のとおりです。

IGMP

IGMPは、特定のLAN上のマルチキャスト グループに個々のホストをダイナミックに登録するためのプロトコルです。グループ メンバーシップの識別は、各ホストがローカル マルチキャスト ルータにIGMPメッセージを送信することにより行われます。IGMPでは、ルータがIGMPメッセージを待ち受けるとともに、定期的にクエリを送信して、特定のサブネット上でアクティブまたは非アクティブになっているグループを検出します。

IGMPの各バージョンについて、次に説明します。

IGMPバージョン1

IGMPバージョン1(IGMPv1)は、RFC 1112『Host Extensions for IP Multicasting』に記述されています。IGMPv1メッセージのパケット フォーマットを、図5に示します。

図5:IGMPv1メッセージ フォーマット

バージョン1のIGMPメッセージは、次の2タイプだけです。

  • メンバーシップ クエリ

  • メンバーシップ レポート

ホストは特定のマルチキャスト グループに対応するIGMPメンバーシップ レポートを送信して、そのグループに加入を希望していることを表明します。アプリケーションがマルチキャスト ソケットを開いた時点で、ホスト上で動作しているTCP/IPスタックが自動的にIGMPメンバーシップ レポートを送信します。ルータは定期的にIGMPメンバーシップ クエリを送信して、そのグループ宛のトラフィックの受信を希望しているホストがサブネット上に最低1台あるかどうかを確認します。IGMPメンバーシップ クエリを3回続けて送信しても応答がない場合、ルータはそのグループをタイムアウトにして、グループ宛のトラフィック転送を停止します。

IGMP バージョン2

IGMPv1の後継は、現在の標準であるIGMPバージョン2(IGMPv2)です。IGMPv2は、IGMPv1と下位互換性があります。IGMPv2の仕様は、RFC 2236『Internet Group Management Protocol, Version 2』に記述されています。IGMPv2メッセージのパケット フォーマットを、図6に示します。

図6:IGMPv2メッセージ フォーマット

バージョン2のIGMPメッセージには、次の4タイプがあります。

  • メンバーシップ クエリ

  • バージョン1メンバーシップ レポート

  • バージョン2メンバーシップ レポート

  • グループ脱退

IGMPバージョン2の動作は、基本的にバージョン1と同じです。主な違いは、グループ脱退(leave group)メッセージがある点です。ホストはこのメッセージを使用して、ローカル マルチキャスト ルータと能動的に対話し、グループから脱退することを表明できます。その場合、ルータはグループ固有のクエリを送信し、そのトラフィックの受信を希望しているホストがまだ残っているかどうかを判別します。応答がない場合、ルータはグループをタイムアウトにして、トラフィック転送を停止します。IGMPバージョン2では、グループ脱退メッセージの追加により、脱退時の遅延をIGMPバージョン1よりも大幅に短縮し、不要になったトラフィックを迅速に停止できるようになっています。

IGMP バージョン3

IGMPバージョン3(IGMPv3)は、IGMP進化の次の段階です。IGMPv3では、マルチキャストの受信側であるホストが、どのグループからのマルチキャスト トラフィックの受信を希望するか、そのトラフィックをどの送信元から受信したいのかについて、ルータに通知することのできる「送信元フィルタリング」のサポートが追加されています。Cisco IOSソフトウェアはこのメンバーシップ情報により、受信者が要求した送信元からのみ、トラフィックを転送できます。

IGMPv3は新しい標準です。Windows、Macintosh、およびUNIXオペレーティング システムの最新版では、いずれもIGMPv3がサポートされています。この資料の執筆時点では、アプリケーション デベロッパがIGMPv3 APIにアプリケーションを移植する作業が進められていました。

IGMPv3メッセージのクエリ パケット フォーマットを、図7に示します。

図7:IGMPv3クエリ メッセージ フォーマット

表3 に、IGMPv3クエリ メッセージの主なフィールドを示します。

表3:IGMPv3クエリ メッセージ フィールドの説明

フィールド  説明 
Type = 0x11 IGMPクエリ。
Max resp. code 最大応答時間(秒)。応答レポートを送信するまでの最大時間を表します。
Group address マルチキャスト グループ アドレス。汎用的なクエリでは、このアドレスは0.0.0.0です。
S Sフラグ。ルータによる処理が停止中であることを意味します。
QRV Querier Robustness Value。この値はタイマーおよび再試行回数に影響します。
QQIC Querier's Query Interval Code(秒)。クエリアが使用するクエリ インターバルを表します。
Number of sources [N] クエリに含まれる送信元の数。group-and-sourceクエリの場合、この数はゼロ以外です。
Source address [1...N] 送信元のアドレス。


IGMPv3メッセージのレポート パケット フォーマットを、図8に示します。

図8:IGMPv3レポート メッセージ フォーマット

表4 に、IGMPv3レポート メッセージの主なフィールドを示します。

表4:IGMPv3レポート メッセージ フィールドの説明

フィールド  説明 
# of group records [M] レポートに含まれるグループ レコードの数。
Group record [1...M] レポートを送信したインターフェイス上の単一のマルチキャスト グループに関する送信側のメンバーシップに関する情報を含むフィールドのブロック。
Record type グループのレコード タイプ(例: MODE_IS_INCLUDE、MODE_IS_EXCLUDE)。
# of sources [N] レコードに含まれる送信元の数。
Source address [1...N] 送信元のアドレス。


IGMPv3には、次のタイプのIGMPメッセージがあります。

  • バージョン3メンバーシップ クエリ

  • バージョン3メンバーシップ レポート

IGMPv3では、アプリケーションが希望するトラフィックの送信元を明示的に指定することができます。IGMPv3を使用すると、受信者が特定のマルチキャスト ホスト グループへのメンバーシップを指定するとき、次の2つのモードを使用できます。

  • INCLUDEモード — このモードでは、受信者は特定のホスト グループへのメンバーシップをアナウンスし、トラフィック受信を希望する送信元アドレスのリスト(INCLUDEリスト)を提供します。

  • EXCLUDEモード — このモードでは、受信者は特定のマルチキャスト グループへのメンバーシップをアナウンスし、トラフィック受信を希望しない送信元アドレスのリスト(EXCLUDEリスト)を提供します。ホストはEXCLUDEリストにIPアドレスが含まれていない送信元からのみ、トラフィックを受信します。IGMPv2のように、すべての送信元からトラフィックを受信するには、ホストは空白のEXCLUDEリストを指定してEXCLUDEモード メンバーシップを使用します。

IGMPv3の最新の仕様は、IETFドラフト『Internet Group Management Protocol, Version 3』に記載されています(IETF Webサイト[http://www.ietf.org])。IGMPv3の主要アプリケーションの1つであるSSMについては、「SSM」 で後述します。

レイヤ2スイッチング環境でのマルチキャスト

レイヤ2スイッチのデフォルトの動作では、スイッチ上で宛先LANに属するすべてのポートに、すべてのマルチキャスト トラフィックが転送されます。この動作はスイッチの効率性を損ないます。スイッチの目的は、データを受信する必要のあるポートだけにトラフィックを限定することだからです。

レイヤ2スイッチング環境で効率的にIPマルチキャストを処理する方法としては、CGMP、IGMPスヌーピング、およびRouter-Port Group Management Protocol(RGMP)の3つがあります。CGMPおよびIGMPスヌーピングは、エンド ユーザすなわち受信側クライアントを含むサブネット上で使用します。RGMPは、コラプスト バックボーンのように、ルータだけを含むルーテッド セグメントで使用します。

これら3つの方法について、次に説明します。

CGMP

CGMPは、Catalystスイッチがシスコ ルータ上のIGMP情報を利用して、レイヤ2で転送先を決定できるようにするためにシスコが開発したプロトコルです。マルチキャスト ルータおよびレイヤ2スイッチに、CGMPを設定する必要があります。CGMPを使用すると、関係する受信者に接続するCatalystスイッチ ポートだけに、IPマルチキャスト トラフィックが配信されます。トラフィックを明示的に要求していない他のポートは、ポートがマルチキャスト ルータに接続されていないかぎり、トラフィックを受信しません。マルチキャスト ルータ ポートは、すべてのIPマルチキャスト データ パケットを受信する必要があります。

CGMPの基本動作を図9に示します。ホストがマルチキャスト グループに加入すると(図中のA)、ホストは非送信要求IGMPメンバーシップ レポート メッセージをターゲット グループ(この例では224.1.2.3)にマルチキャストします。このIGMPレポートは、通常のIGMP処理に従い、スイッチ経由でルータに渡されます。ルータ(このインターフェイスについてはCGMPをイネーブルに設定している必要があります)は、IGMPレポートを受信すると、それを通常どおりに処理しますが、CGMP joinメッセージも作成してスイッチに送信します(図9のB)。

図9:CGMPの基本動作

スイッチはこのCGMP joinメッセージを受信すると、そのマルチキャスト グループに対応する自分自身のContent-Addressable Memory(CAM;連想記憶メモリ)テーブルにポートを追加します。このマルチキャスト グループ宛の以降のトラフィックはすべて、そのポートから該当するホストに転送されます。レイヤ2スイッチは、いくつかの宛先MACアドレスを1つの物理ポートに割り当てることができるように設計されています。したがって、スイッチを階層型に接続し、かつ1つのポートから多数のマルチキャスト宛先アドレスへの転送を行うことができます。マルチキャスト グループのエントリには、ルータ ポートも追加されます。IGMP制御メッセージもマルチキャスト トラフィックとして送信されるので、マルチキャスト ルータは、あらゆるグループについてマルチキャスト トラフィックをすべてリスンする必要があります。CGMPでは、スイッチはルータからのCGMP joinメッセージおよびCGMP leaveメッセージだけをリスンすれば済みます。それ以外のマルチキャスト トラフィックは、CGMPによって作成された新しいエントリを含むCAMテーブルを使用して転送されます。

IGMPスヌーピング

IGMPスヌーピングは、レイヤ2 LANスイッチで動作するIPマルチキャスト制約メカニズムです。IGMPスヌーピングでは、ホストとルータの間で送信されるIGMPパケット内のレイヤ3情報(IGMP join/leaveメッセージ)を、LANスイッチが検証する、すなわち「スヌープする」必要があります。スイッチが特定のマルチキャスト グループのホストからのIGMPホスト レポートを検出すると、スイッチはそのホストのポート番号を該当するマルチキャスト テーブル エントリに追加します。スイッチがホストからのIGMP leave groupメッセージを検出すると、スイッチはそのホストのテーブル エントリを削除します。

IGMP制御メッセージはマルチキャスト パケットとして送信されるので、これらのメッセージはレイヤ2ではマルチキャスト データと区別がつきません。IGMPスヌーピングが稼働しているスイッチは、すべてのマルチキャスト データ パケットを検証して、関連するIGMP制御情報を含んでいないかどうかを調べる必要があります。低速なCPUを搭載したローエンド スイッチでIGMPスヌーピングを実装すると、データが高速で送信された場合、パフォーマンスに重大な影響が出ることがあります。この問題を解決するには、IGMPチェックをハードウェアで実行できる特殊なApplication-Specific Integrated Circuit(ASIC;特定用途向けIC)を搭載したハイエンド スイッチでIGMPスヌーピングを実装します。特殊なハードウェアを搭載していないローエンド スイッチには、CGMPが適しています。

RGMP

CGMPおよびIGMPスヌーピングは、アクティブである受信者のいるルーテッド ネットワーク セグメント上で動作するように設計された、IPマルチキャスト制約メカニズムです。これらは両方とも、ホストとルータの間で送信されるIGMP制御メッセージによって、どのスイッチ ポートが関係する受信者に接続されているかを判別します。

スイッチド イーサネットのバックボーン ネットワーク セグメントは通常、そのセグメント上にホストを持たないスイッチに接続する数台のルータで構成されています。ルータはIGMPホスト レポートを生成しないので、CGMPおよびIGMPスヌーピングではマルチキャスト トラフィックを制約することができず、VLAN上の全ポートにマルチキャスト トラフィックがフラッディングされる結果となります。その代わりにルータはPIMメッセージを生成して、レイヤ3レベルでマルチキャスト トラフィックに加入したり、マルチキャスト トラフィックを削除したりします。PIMについては、「PIM」で後述します。

RGMPは、ルータだけで構成されるネットワーク セグメントにおけるIPマルチキャスト制約メカニズムです。ルータおよびレイヤ2スイッチで、RGMPをイネーブルに設定する必要があります。マルチキャスト ルータは、特定のグループに関するRGMP joinメッセージを送信することによって、データ フローの受信を希望していることを表明します(図10のA)。スイッチは、そのマルチキャスト グループの転送テーブルに該当するポートを追加します。この動作はCGMP joinメッセージを処理する場合と同様です。IPマルチキャスト データ フローは、必要とされるルータ ポートだけに転送されます(図10のB)。データ フローが不要になると、ルータはRGMP leaveメッセージを送信し、スイッチは転送エントリを削除します。RGMPの最新の仕様については、IETFドラフト『Router-port Group Management Protocol』に記載されています(IETF Webサイト[http://www.ietf.org])。

図10:RGMPの基本動作

マルチキャスト配信ツリー

マルチキャスト対応のルータが作成する配信ツリーは、ネットワーク上でIPマルチキャスト トラフィックをすべての受信者に配信するためのパスを制御します。マルチキャスト配信ツリーには、送信元ツリーおよび共有ツリーの2つの基本タイプがあります。各タイプについて次に説明します。

送信元ツリー

マルチキャスト配信ツリーの最も単純な形式は、送信元ツリーです。このツリーのルートは送信元であり、それを基点にネットワーク上の各受信者に向かって分岐し、スパニングツリーを形成します。このツリーはネットワーク上の最短パスを使用するので、Shortest Path Tree(SPT;最短パス ツリー)と呼ばれることがあります。

図11に、グループ224.1.1.1のSPTを示します。このツリーは送信元であるホストAをルートとし、受信者であるホストBおよびホストCに接続しています。

図11:ホストAの送信元ツリー

(S, G)という特殊な表記は、「SコンマG」と読み、SPTを表します。Sは送信元のIPアドレスであり、Gはマルチキャスト グループ アドレスです。この表記を使用すると、図11に示されたSPTは(192.168.1.1, 224.1.1.1)です。

(S, G)表記では、各グループの送信元ごとに個別のSPTが存在することになりますが、これはそのとおりです。たとえば、ホストBもグループ224.1.1.1にトラフィックを送信していてホストAおよびホストCが受信者である場合、別の(S, G) SPTが存在し、これは(192.168.2.2, 224.1.1.1)という表記になります。

共有ツリー

送信元をルートとする送信元ツリーとは違い、共有ツリーは、ネットワーク上のどこか1つのポイントを共通のルートとして使用します。この共有ルートのことを、ランデブー ポイント(RP)といいます。

図12に、グループ224.2.2.2に対する、ルータDをルートとする共有ルートを示します。この共有ツリーは単方向です。送信元のトラフィックは、送信元ツリーでRPに送信されます。そのあと、トラフィックはRPから共有ツリーを使用して転送され、すべての受信者に到達します(ただし、送信元とRPの中間に受信者が存在する場合には、その受信者は直接サービスされます)。

図12:共有配信ツリー

この例では、送信元(ホストAおよびホストD)からのマルチキャスト トラフィックは、ルート(ルータD)まで送信されたあと、共有ツリーを使用して受信者であるホストBおよびホストCに到達します。マルチキャスト グループの送信元がすべて同じ共有ツリーを使用するので、このツリーを表記する場合は、(*, G)というワイルドカード表記を使用します(スター コンマGと読みます)。ここで、*はすべての送信元を表し(Gはマルチキャスト グループを表します。したがって、図12の共有ツリーは、(*, 224.2.2.2)と表記します。

送信元ツリーと共有ツリー

送信元ツリーと共有ツリーは、どちらもループフリーです。ツリーが分岐する場所でのみ、メッセージが複製されます。

マルチキャスト グループのメンバーは、いつでも加入または脱退する可能性があります。したがって、配信ツリーをダイナミックに更新する必要があります。特定の分岐に存在するすべてのアクティブな受信者が、特定のマルチキャスト グループのトラフィックを要求しなくなった場合には、ルータは配信ツリーからその分岐を削除し、そこから先へのトラフィック転送を停止します。その分岐の受信者がアクティブになり、マルチキャスト トラフィックを要求するようになると、ルータは配信ツリーをダイナミックに変更し、再びトラフィック転送を開始します。

送信元ツリーには、送信元と受信者の間で最適なパスを作成するという利点があります。この利点によって、マルチキャスト トラフィックの転送におけるネットワーク遅延が少なくなります。ただし、この最適化には代償が伴います。ルータは送信元ごとにパス情報を維持しなければなりません。何千もの送信元、何千ものグループが存在するネットワークでは、このオーバーヘッドによりリソース関連の問題がルータで発生しやすくなります。ネットワーク設計者は、マルチキャスト ルーティング テーブルの容量によるメモリ消費について考慮する必要があります。

共有ツリーには、各ルータ上で維持する必要のあるステートの量が少なくて済むという利点があります。ネットワーク上で共有ツリーだけを使用する場合、この利点により全体的なメモリ所要量が減少します。共有ツリーの欠点は、ある種の状況下で、送信元と受信者の間のパスが最適パスではなくなり、その結果パケット配信に遅延を生じる可能性がある点です。たとえば、図12の場合、ホストA(送信元1)とホストB(受信者)の間の最短パスは、本来ならルータAおよびルータCです。ここではルータDを共有ツリーのルートとして使用しているので、トラフィックはルータA、ルータB、ルータDを通過したあとルータCに到達しなければなりません。共有ツリーだけの環境を実装する場合、ネットワーク設計者はRPの配置を慎重に考慮する必要があります。

マルチキャスト転送

ユニキャスト ルーティングでは、ネットワーク上でトラフィックは送信元から宛先ホストまで、単一のパスでルーティングされます。ユニキャスト ルータは、送信元アドレスについては考慮せず、宛先アドレスと、その宛先に向けてトラフィックをどのように転送するかだけを考慮します。ルータは宛先アドレスについてルーティング テーブルをスキャンしたあと、その宛先の方向にある適正なインターフェイスからユニキャスト パケットを1コピーのみ転送します。

マルチキャスト転送では、送信元はマルチキャスト グループ アドレスに代表される任意のホスト グループにトラフィックを送信します。マルチキャスト ルータは、どの方向がアップストリーム(送信元へ向かう)方向で、どの方向がダウンストリーム方向か(複数の場合もある)を判別しなければなりません。複数のダウンストリーム パスがある場合、ルータはパケットを複製して、それを適切な(ユニキャスト ルート メトリックが最良の)ダウンストリーム パスで転送します。すべてのパスが適切であるとは限りません。受信者に向かってではなく、送信元から遠ざかる方向へマルチキャスト トラフィックを転送することを、Reverse Path Forwarding(RPF)といいます。RPFについて、次に説明します。

RPF

PIMはユニキャスト ルーティング情報を使用して、受信者から送信元へ向かうリバース パスを使用する配信ツリーを作成します。そのあと、マルチキャスト ルータはその配信パスで、送信元から受信者へパケットを転送します。RPFは、マルチキャスト転送における重要な概念です。RPFにより、ルータは配信ツリーを使用してマルチキャスト トラフィックを正しく転送できます。RPFは既存のユニキャスト ルーティング テーブルを使用して、アップストリームおよびダウンストリームのネイバを判別します。アップストリーム インターフェイスでマルチキャスト パケットを受信した場合にのみ、ルータはパケットを転送します。このRPFチェックは、配信ツリーを確実にループフリーにするのに役立ちます。

RPFチェック

ルータにマルチキャスト パケットが着信すると、ルータはそのパケットについてRPFチェックを実行します。このRPFチェックが成功すると、パケットが転送されます。そうでない場合、パケットは廃棄されます。

送信元ツリーを下へ向かって流れるトラフィックの場合、RPFチェック手順は次のように行われます。

1. ルータはユニキャスト ルーティング テーブルで送信元アドレスを調べ、そのパケットが着信したのが、送信元に逆戻りするパス上にあるインターフェイスかどうかを判別します。

2. 送信元に逆戻りするインターフェイスにパケットが着信した場合、RPFチェックは成功であり、パケットが転送されます。

3. ステップ2のRPFチェックに失敗した場合、パケットは廃棄されます。

図13に、RPFチェックに失敗する場合の例を示します。

図13:RPFチェックの失敗

図13では、送信元151.10.3.21からのマルチキャスト パケットがシリアル インターフェイス0(S0)に着信しています。ユニキャスト ルート テーブルと照合した結果、S1は、このルータが151.10.3.21にユニキャスト データを転送する場合に使用するインターフェイスです。パケットはインターフェイスS0に着信したので、このパケットは廃棄されます。

図14 に、RPFチェックが成功する場合の例を示します。

図14:RPFチェックの成功

この例では、マルチキャスト パケットはインターフェイスS1に着信しています。ルータはユニキャスト ルーティング テーブルを参照し、S1が適正なインターフェイスであることを確認します。RPFチェックは成功し、パケットが転送されます。

PIM

PIMは特定のIPルーティング プロトコルに依存せず、Enhanced Interior Gateway Routing Protocol(EIGRP)、Open Shortest Path First(OSPF)、Border Gateway Protocol(BGP)、スタティック ルートなど、ユニキャスト ルーティング テーブルの書き込みに使用される、どのユニキャスト ルーティング プロトコルでも利用することができます。PIMはこのルーティング情報を使用して、マルチキャスト転送機能を実行します。PIMはマルチキャスト ルーティング プロトコルと呼ばれますが、実際には完全に独立したマルチキャスト ルーティング テーブルを作成するのではなく、ユニキャスト ルーティング テーブルを使用してPRFチェック機能を実行します。他のルーティング プロトコルとは異なり、PIMはルータ間でのルーティング アップデートの送受信を行いません。

PIMの転送モードについて、次に説明します。

PIM Dense(稠密)モード(PIM-DM)

PIM-DMは、プッシュ モデルを使用してマルチキャスト トラフィックをネットワークの隅々にまでフラッディングします。このプッシュ モデルは、データを受信者に配信するための強引な方式です。この方式は、ある種の状況(ネットワークのあらゆるサブネットにアクティブな受信者がいる場合)では効率的です。

PIM-DMは最初に、ネットワーク全体にマルチキャスト トラフィックをフラッディングします。ダウンストリーム ネイバのないルータは、不要なトラフィックをプルーニングします。このプロセスは3分おきに繰り返されます。

ルータはこのようなフラッディングおよびプルーニング メカニズムを通じてデータ ストリームを受信することにより、ステート情報を蓄積します。これらのデータ ストリームには送信元およびグループの情報が含まれているので、ダウンストリーム ルータがマルチキャスト転送テーブルを作成できます。PIM-DMでは送信元ツリー、すなわち(S, G)エントリしかサポートされないので、共有配信ツリーは作成できません。

PIM Sparse(希薄)モード(PIM-SM)

PIM-SMは、プル モデルを使用してマルチキャスト トラフィックを配信します。明示的にデータを要求したアクティブな受信者が存在するネットワーク セグメントだけが、トラフィックを受信します。

PIM-SMは、共有ツリーでデータ パケットを転送することにより、アクティブな送信元に関する情報を配布します。PIM-SMは(少なくとも最初は)共有ツリーを使用するので、RPが不可欠になります。ネットワーク上で管理者がRPを設定している必要があります。

送信元がRPに登録したあと、共有ツリーを使用してデータが受信者まで転送されます。エッジ ルータは特定の送信元からRPを経由して共有ツリーでデータ パケットを受信した時点で、その送信元について学習します。次にエッジ ルータは、その送信元に対してPIM(S, G)joinメッセージを送信します。リバース パス上の各ルータは、RPアドレスのユニキャスト ルーティング メトリックを、送信元アドレスのメトリックと比較します。送信元アドレスのメトリックの方が良い場合には、ルータは送信元に対してPIM(S, G)joinメッセージを転送します。RPのメトリックと同じ、またはRPのメトリックの方が良い場合には、RPと同じ方向にPIM(S, G)joinメッセージが送信されます。この場合、共有ツリーと送信元ツリーは一致しているとみなされます。

図15に、標準的なPIM-SM単方向共有ツリーを示します。送信元に最も近いルータがRPに登録し(図15のA)、送信元とRPの間の送信元ツリー(S, G)を作成します(図15のB)。RPから受信者に向かう共有ツリー(*, G)を使用して、データが転送されます。

図15:単方向共有ツリーと送信元ツリー

送信元と受信者の間で共有ツリーが最適なパスではない場合、ルータはダイナミックに送信元ツリーを作成し、共有ツリーでのトラフィック転送を停止します。この動作は、Cisco IOSソフトウェアのデフォルトの動作です。ネットワーク管理者はCisco IOSのip pim spt-threshold infinityコマンドを使用して、トラフィックを強制的に共有ツリーに置いておくことができます。

PIM-SMについては当初、RFC 2362『Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification』に記述されていました。このRFCは改訂中であり、現在はドラフト形式です。ドラフトの仕様『Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification (Revised)』は、IETFのWebサイト(http://www.ietf.org)で参照できます。

PIM-SMは、WANリンクを使用するネットワークも含めて、あらゆる規模のネットワークに対応するスケーラビリティがあります。明示的なjoinメカニズムにより、WANリンクからの不要なトラフィックのフラッディングを防止します。

双方向PIM(Bidir-PIM)

双方向PIM(Bidir-PIM)は、個々のPIMドメイン内での効率的な多対多コミュニケーションのために設計された、PIMプロトコルの拡張機能です。双方向モードのマルチキャスト グループは、送信元が多数になっても、ごくわずかにオーバーヘッドが増えるだけで任意の数に対応できるスケーラビリティがあります。

PIM SMモードで作成される共有ツリーは、単方向です。つまり、データ ストリームをRP(共有ツリーのルート)搬送するには、送信元ツリーを作成する必要があり、そこから分岐を経由して受信者まで転送できます。送信元のデータは、RPに向かって共有ツリーを上方向へ流れることはできません。これは双方向共有ツリーとみなされます。

双方向モードでは、グループのRPをルートとする双方向共有ツリーでのみ、トラフィックがルーティングされます。Bidir-PIMでは、RPのIPアドレスは、すべてのルータがこのIPアドレスをルートとするループフリーのスパニングツリー トポロジーを確立するための重要な役割を果たします。このIPアドレスはルータ アドレスである必要はなく、ネットワーク上でPIMドメイン内のどこからでも到達可能な空いている任意のアドレスを使用できます。

図16に、双方向共有ツリーを示します。送信元からのデータは、RPに向かって共有ツリー(*, G)を上方向に流れたあと、受信者に向かって共有ツリーを下方向に流れることができます。登録プロセスはないので、送信元ツリー(S, G)は作成されません。

図16:双方向共有ツリー

Bidir-PIMは、PIM-SMのメカニズムから派生したもので、共有ツリー動作に共通する点が多くあります。Bidir-PIMでも、共有ツリーのアップストリームにあるRPまで送信元トラフィックを無条件に転送する動作が行われますが、PIM-SMのような送信元の登録プロセスはありません。すべてのルータで(*, G)マルチキャスト ルーティング エントリだけに基づいてトラフィックを転送できるようにするには、このような変更が必要にして十分なものです。この機能では、送信元固有のステートは不要であり、任意の数の送信元に対応するスケーラビリティがもたらされます。

Bidir-PIMの最新の仕様については、IETFドラフト『Bi-directional Protocol Independent Multicast (BIDIR-PIM)』に記述されており、IETF Webサイト(http://www.ietf.org)で参照できます。

PGM

PGMは、複数の送信元から複数の受信者への整然とした重複のないマルチキャスト データ配信を必要とするアプリケーションのための、高信頼性マルチキャスト トランスポート プロトコルです。PGMを使用する場合、マルチキャスト グループの受信者は、送信および再送信によってすべてのデータ パケットを確実に受信することができるか、または回復不可能なデータ パケット損失を検知することができます。

高信頼性PGMトランスポート プロトコルは、送信元および受信者に実装します。送信元は発信データ パケットの送信ウィンドウを維持し、否定応答(NAK)を受信した場合には個々のパケットを再送信します。ルータなどのネットワーク要素は、(データ パケットがドロップされたときの)NAKの多発を抑え、再送信されたデータが必要なネットワークだけに効率よく転送されるように支援します。

PGMは、基本的な信頼性が要求されるマルチキャスト アプリケーションのためのソリューションとして開発されました。PGMは、ベストエフェート型配信よりも優れているとはいえ、100%の信頼性があるわけではありません。PGMの仕様は、特定のネットワーク レイヤに依存しません。シスコが実装したPGMルータ アシスト機能は、PGM over IPをサポートしています。

PGMの最新の仕様は、RFC 3208『PGM Reliable Transport Protocol Specification』に記述されています。


注: IETFのWebサイト(http://www.ietf.org)で、すべてのRFCおよびIETFドラフトを参照できます。
return to top

ドメイン間マルチキャスト プロトコル

ここでは、ドメイン間マルチキャスト プロトコル(すなわち、マルチキャスト ドメイン同士の間で使用されるプロトコル)について説明します。これらのプロトコルは、Internet Service Provider(ISP;インターネット サービス プロバイダー)がインターネット上でマルチキャスト トラフィックを転送する場合にも使用します。ここで説明するプロトコルは、次のとおりです。

MBGP

MBGPは、プロバイダーがマルチキャストRPFチェックを実行する際に使用するルート プレフィクスを区別するための手段を提供します。RPFチェックとは、マルチキャスト転送ツリーがたどるパスをルータが判別し、送信元から受信者へマルチキャスト コンテンツを正しく配信するための基本的なメカニズムです。詳細については、この資料で前述した「RPF」 を参照してください。

MBGPについては、RFC 2283『Multiprotocol Extensions for BGP-4』に記述されています。MBGPはBGPの拡張版なので、ルーティングをフィルタおよび制御するためのすべてのAS間ツール(たとえば、ルート マップなど)も含めて、プロバイダーおよびカスタマーがドメイン間ルーティング環境で必要とする管理メカニズムを含んでいます。したがって、内部BGP(iBGP)または外部BGP(eBGP)を利用しているネットワークでは、MBGPの使用によって、使い慣れたBGPのさまざまなポリシー制御手段を適用し、マルチキャストにおけるルーティング ポリシー(および転送ポリシー)を指定することができます。

BGP4では、MP_REACH_NLRIおよびMP_UNREACH_NLRIの2つのパス属性が導入されています。これらの新しい属性によって、2種類のルーティング情報(1つはユニキャスト ルーティング用、もう1つはマルチキャスト ルーティング用)を簡単に伝達できます。マルチキャスト ルーティングに対応づけられたルートは、ドメイン間の境界でRPFチェックに使用されます。

MBGPの主な利点は、インターネットワークがユニキャスト トポロジーとマルチキャスト トポロジーの不一致をサポートできる点です。ユニキャスト トポロジーとマルチキャスト トポロジーが一致している場合、MBGPはそれぞれ異なるポリシーをサポートできます。Unicast Routing Information Base(U-RIB;ユニキャスト ルーティング情報ベース)およびMulticast Routing Information Base(M-RIB;マルチキャスト情報ベース)について、個別のBGPルーティング テーブルが維持されます。M-RIBは、ユニキャスト ルーティング テーブルから、マルチキャスト ポリシーを適用して引き出されます。RPFチェックおよびPIM転送イベントは、M-RIBの情報に基づいて実行されます。MBGPは、スケーラブルなポリシーベースのドメイン間ルーティング プロトコルを提供します。

MSDP

PIM-SMモデルでは、送信元または受信者に最も近いルータがRPに登録します。RPは、特定のグループの送信元および受信者をすべて認識しています。ネットワーク管理者が複数のRPを設定し、複数のPIM-SMドメインを作成する場合があります。その場合、各ドメインのRPは、他のドメインに存在する送信元について知ることができません。MSDPは、この問題を解決するための洗練された手段です。

MSDPはISP間のピアリングを目的として開発されました。各ISPが、競合するISPの維持するRPに頼って自社のカスタマーにサービスを提供することを望まなかったからです。MSDPを使用すると、各ISPがそれぞれ独自のローカルRPを使用しても、インターネット上でマルチキャスト トラフィックを送受信することができます。

MSDPは、アクティブな送信元に関する情報のRP間での共有を可能にします。各RPは自身のローカル ドメインに存在する受信者を認識しています。リモート ドメインのRPがアクティブな送信元について知ると、RPはその情報を自身のローカル受信者に渡すことができます。その後、ドメイン間でマルチキャスト データを転送できるようになります。MSDPの特長は、ドメインごとに独立した、他のドメインに依存しないRPを維持できる点です。MSDPを使用すると、ネットワーク管理者はドメイン間で選択的にマルチキャスト トラフィックを転送することができ、また、特定のグループまたは送信元をブロックすることもできます。マルチキャスト ドメイン間でのトラフィック転送には、PIM-SMが使用されます。

各ドメインのRPは、他のドメインのRP、または他のドメインに接続する境界ルータとのTCP接続を使用して、MSDPピアリング セッションを確立します。RPが自身のドメイン内にある新しいマルチキャスト送信元について(通常のPIM登録メカニズムを通じて)学習すると、RPは最初のデータ パケットをSource-Active(SA)メッセージでカプセル化し、そのSAをすべてのMSDPピアに送信します。MSDPは修正版のRPFチェックを使用して、SAメッセージを転送すべきピアを判別します。この修正版のRPFチェックは、ホップ単位のメトリックではなく、ASレベルで行われます。各受信側のピアも同じ修正版のRPFチェックを使用してSAを転送します。最終的にインターネットワーク上(理論上、マルチキャスト インターネット全体)のすべてのMSDPルータにSAが到達します。受信側のMSDPピアがRPであり、そのRPにSAのグループの(*, G)エントリがある場合(すなわち、該当する受信者が存在する場合)、RPはその送信元に関する(S, G)ステートを作成し、送信元へのSPTに加入します。カプセル化されたデータがカプセル化解除され、そのRPの共有ツリーを使用して転送されます。受信者の最終ホップ ルータがパケットを受信した時点で、その最終ホップ ルータも送信元へのSPTに加入できるようになります。MSDPスピーカーは定期的に、そのRP自身のドメイン内に存在するすべての送信元を含むSAを送信します。図17に、ドメインAの送信元とドメインEの受信者との間におけるデータの流れを示します。

図17:MSDPによる各ドメインのRP間での送信元情報の共有

Anycast RP

Anycast RPは、MSDPの有益な応用であり、マルチキャストsparseモード ネットワークが単一のマルチキャスト ドメイン内で耐障害性および負荷分散機能を提供できるようにします。

ループバック インターフェイス上で、2つ以上のRPを同じIPアドレス(たとえば10.0.0.1)で設定します(図18を参照)。このループバック アドレスは、ホスト アドレスとして(32ビット マスクを使用して)設定する必要があります。この10.0.0.1がローカルRPのIPアドレスであることを認識するように、すべてのダウンストリーム ルータを設定します。IPルーティングにより、それぞれの送信元および受信者にトポロジー的に最も近いRPが自動的に選択されます。送信元によっては1つのRPしか使用せず、また受信者によっては別のRPを使用している場合もあるので、MSDPによりRPがアクティブな送信元に関する情報を交換できるようにします。すべてのRPが互いにMSDPピアになるように設定されます。各RPは、他のRPのエリア内に存在するアクティブな送信元を認識するようになります。いずれかのRPに障害が発生すると、IPルーティングが収束し、いずれか1つのRPが2つのエリアのアクティブRPになります。

Anycast RPの詳細については、次のURLにあるシスコ技術資料「Anycast RP」を参照してください。http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/mcst_sol/anycast.htm


注: 上記のAnycast RPの例では、RFC 1918『Address Allocation for Private Internets』に記載されているIPアドレスを使用しています。通常、これらのIPアドレスはドメイン間の境界でブロックされているので、他のISPからはアクセスできません。RPを他のドメインから到達可能にするには、有効なIPアドレスを使用する必要があります。
図18:Anycast RP


注: RPが使用されるのは、送信元と受信者の間で最初に接続を確立するときだけです。最終ホップ ルータがSPTに加入したあとは、RPは不要になります。

SSM

SSMは、1対多コミュニケーションにおける効率的なデータ配信メカニズムを提供するPIMプロトコルの拡張機能です。SSMを使用すると、受信側のクライアントがディレクトリ サービスを通じて特定のマルチキャスト送信元について一度学習すれば、共有RPを使用するのではなく、直接その送信元からコンテンツを受信できるようになります。

SSMを使用する場合、MSDPにより他のPIMドメイン内のアクティブな送信元を検出する必要がありません。Webサーバなど、アプリケーション レベルでの帯域外サービスにより、送信元の検出を実行できます。さらに、RPも不要になります。

従来のマルチキャスト実装では、IPマルチキャスト グループ全体にトラフィックが分散されるので、アプリケーションはIPマルチキャスト グループ アドレスに「加入」する必要があります。送信元および受信者の異なる2つのアプリケーションが同じIPマルチキャスト グループ アドレスを使用する場合、これら2つのアプリケーションの受信者は、両方のアプリケーションの送信者からトラフィックを受信することになります。受信者側では、適切にプログラミングされていれば、不要なトラフィックをフィルタできるとはいえ、この状況では不要なネットワーク トラフィックが目につく程度にまで発生する可能性があります。

SSM対応のマルチキャスト ネットワークでは、受信者に最も近いルータが、特定のマルチキャスト送信元に対する受信側アプリケーションの加入要求を「認識」します。受信側アプリケーションは、IGMPv3のINCLUDEモードを使用して、特定の送信元への加入をシグナリングすることができます。INCLUDEモードについては、この資料で前述した「IGMPバージョン3」を参照してください。

この場合、マルチキャスト ルータはPIM-SMモードのように共通のRPに要求を送信するのではなく、送信元に直接、要求を送信できます。この時点で、送信元は最短パスを使用して受信者に直接データを送信できるようになります。SSMでは、マルチキャスト トラフィックのルーティングはすべて送信元ツリーを使用して実行されます。共有ツリーは存在しないので、RPは不要です。

SSMでは特定の送信元を明示的に指定または除外できるので、ある程度のセキュリティがもたらされます。INCLUDEリストで明示的に指定されていないグループへの送信元からのトラフィックが、無関係の受信者に転送されることはありません。

SSMは、1対多タイプのアプリケーションに関連するIPマルチキャスト アドレスの衝突という問題も解決します。SSMモードを実行しているルータは、完全な(S, G)アドレスに基づいてデータ ストリームをルーティングします。送信元がインターネット上で送信するIPアドレスが固有である場合には、この送信元からの(S, G)もすべて固有になります。

return to top

関連資料

  • Cisco IOSソフトウェア マルチキャスト サービスWebページ(http://www.cisco.com/go/ipmulticast

  • Cisco IOSソフトウェアIPマルチキャスト グループ外部ホームページ (ftp://ftpeng.cisco.com/ipmulticast.html)

  • Developing IP Multicast Networks』 Cisco Press

  • Bi-directional Protocol Independent Multicast (BIDIR-PIM)』 IETFインターネット ドラフト

  • Internet Group Management Protocol, Version 3』 IETFインターネット ドラフト

  • PGM Reliable Transport Protocol』 IETFインターネット ドラフト

  • RFC 1112 『Host extensions for IP multicasting

  • RFC 1918 『Address Allocation for Private Internets

  • RFC 2236 『Internet Group Management Protocol, Version 2

  • RFC 2283 『Multiprotocol Extensions for BGP-4

  • RFC 2362 『Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification

  • RFC 2365 『Administratively Scoped IP Multicast

  • RFC 2770 『GLOP Addressing in 233/8

return to top

まとめ

この資料では、マルチキャスト グループの概念、IPマルチキャスト アドレス、レイヤ2マルチキャスト アドレスなど、マルチキャストに関する一般的な事項について検証しました。次に、IGMP、CGMP、PIM、PGMといったドメイン内マルチキャスト プロトコルおよび、MBGP、 MSDP、SSMといったドメイン間プロトコルについて検証しました。

return to top