IPマルチキャスト概要

マルチキャストについて

マルチキャストは、マルチキャストのルーティングに対応した特別な網で実現されます。網を構成するルーターは、特定の端末が送信するマルチキャストパケットを複製して、複数のノードに配送します。マルチキャストパケットを送信する端末をソース(source)と呼び、それを受信する端末をリスナー(listener)と呼びます(図1)。以下の説明では、マルチキャストパケットを単にパケットと書きます。また、マルチキャストに対応した網をマルチキャスト網、あるいは単にと書きます。

図1:マルチキャスト網

図1:マルチキャスト網

グループという単位でパケットを区別します。例えば、2種類の映像ストリームを同じマルチキャスト網に流すときには、それぞれのパケットに対して異なるグループを割り当てます。グループの識別子としてマルチキャストアドレスが定義されています。IPv4では224.0.0.0/4の範囲が、IPv6ではff00::/8の範囲がマルチキャストアドレスとして割り当てられます。

図2の例では、232.0.0.1と232.0.0.2という2つのグループのパケットが流れています。左側2つのリスナーは232.0.0.1というグループのパケットを受信しており、右側2つのリスナーは232.0.0.2というグループのパケットを受信しています。中央のリスナーは両方のグループのパケットを受信しています。

図2: グループとマルチキャストアドレス

図2: グループとマルチキャストアドレス

パケットのIPヘッダの終点アドレスには、グループに対応するマルチキャストアドレスを格納します。 網内のルーターは、このマルチキャストアドレスを見て、パケットの転送先を判断します。網内のルーターはグループごとに編成された経路表を持っているので、その経路表にしたがってパケットを配送します。経路表は、通常、PIM-SM、PIM-DM、DVMRPなどのルーティングプロトコルによって自動的に生成されます。

なお、マルチキャスト網の配送経路は樹状になるので、配送経路の全体を表して配送木(Distribution Tree)と呼びます。

IGMP/MLD

マルチキャストグループへの参加者を管理するプロトコルとして、IPv4/IPv6それぞれ次のプロトコルが提案されています。

IPv4 ... IGMP(Internet Group Management Protocol)
IPv6 ... MLD(Multicast Listener Discovery)

MLDはIGMPの仕組みを元にIPv6での利用環境に適合させたものです。そのため、呼び方は違いますが、プロトコル動作そのものはまったく同じ動作となります。ただし、そのバージョン番号に以下の違いがあるので、注意してください。

IPv4 IPv6

IGMPv1

対応するバージョンなし

IGMPv2

MLDv1

IGMPv3

MLDv2

IGMPやMLDなどのマルチキャストグループ管理プロトコルの目的は、リスナーがマルチキャスト網に対して、受信したいパケットのグループとソースを通知することです。

網内のルーターはリスナーに対してクエリー(Query)というメッセージを送信します。クエリーを受信したリスナーは、 ルーターに対してレポート(Report)というメッセージを返します(図3)。レポートの中には、リスナーが受信したいパケットのグループとソースの情報が含まれます。レポートを受信したルーターはその情報をルーティングに反映します。なお、ルーティングに関する動作はIGMPやMLDでは規定されていません。

図3: IGMP/MLD

図3: IGMP/MLD

ソースを記述する表現として、IGMP/MLDでは、次の2つの概念を定義しています。

  • フィルターモード (Filter Mode)
  • ソースリスト (Source List)

フィルターモードにはINCLUDEEXCLUDEという 2つのモードがあり、INCLUDEモードでは、受信を許可するソースを列挙します。逆にEXCLUDEモードでは、受信を許可しないソースを列挙します。ソースリストはソースのアドレスを列挙したものです。以下に具体例を示します。

次の例では、192.168.0.1と192.168.0.2をソースとするパケットだけを受信します。

  • フィルターモード : INCLUDE
  • ソースリスト : { 192.168.0.1, 192.168.0.2 }

次の例では、192.168.0.1以外のアドレスをソースとするパケットだけを受信します。

  • フィルターモード : EXCLUDE
  • ソースリスト : { 192.168.0.1 }

次の例では、すべてのソースからのパケットを受信します。
「{ }」は「何もない」という意味を表現しています。

  • フィルターモード : EXCLUDE
  • ソースリスト : { }

次の例は、いずれのソースもまったく受信しないことを意味します。

  • フィルターモード : INCLUDE
  • ソースリスト : { }

なお、フィルターモードとソースリストは、IGMPv3(MLDv2)で採用された概念であり、 IGMPv1とIGMPv2(MLDv1)では定義されていません。つまり、IGMPv1とIGMPv2(MLDv1)では、ソースの希望を通知する仕組みがなく、単に受信したいパケットのグループだけを通知します。

[補足]
フィルターモードとソースリストを使ってIGMPv1とIGMPv2(MLDv1)の動作を記述することもできます。ソースの希望を指定できないということは、ソースリストがいつでも空であるということです。つまり、IGMPv1とIGMPv2(MLDv1)の動作は、次の2つの記述に集約されます。

■ 受信するとき

  • フィルターモード : EXCLUDE
  • ソースリスト : { }

■ 受信しないとき

  • フィルターモード : INCLUDE
  • ソースリスト : { }

IGMP/MLD プロキシ

IGMP/MLDのメッセージは原則としてルーターの先に流れません。IGMP/MLDメッセージのTTL(IPv6ではHopLimit)は1に設定されており、ルーターを越える前に消滅するように作られています。IGMPの目的は、リスナーがルーターに対して、リスナーの希望を伝えることであり、 IGMPはルーターを越えた動作を規定していません。したがって、リスナーとマルチキャスト網の間にルーターが介在する場合には、 次のいずれかを選択する必要があります。

  • 介在するルーターはIGMP/MLDメッセージを中継する。
  • 介在するルーターはPIM-SMなどのルーティングプロトコルをサポートする。

ルーターにかかる負荷を考えると前者の方が有利ですが、 前者はパケットを送信する際には利用できません。すなわち、 リスナーがソースとしても動作する場合には、後者の解に限られます。 どちらの解を採用するかは網のサービスによって決まります。この章では、前者の解についてのみ説明し、次の章で、後者について、特にPIM-SMについて説明します。

前述のように、IGMP/MLDメッセージはルーターを越えないので、介在するルーターは、IGMP/MLDメッセージを中継する必要があります。また、 IGMP/MLDメッセージだけでなく、実際のストリーミングなどのデータパケットも転送する必要があります。これらの機能を総称して、IGMP/MLDプロキシと呼んでいます。

図4でIGMP/MLDプロキシの動作イメージを示します。

図4: IGMP/MLDプロキシ

図4: IGMP/MLDプロキシ

なお、IGMP/MLDプロキシをどのように実現するかは、実装に依存します。 簡単な方法としては、IGMP/MLDメッセージをブリッジする方法がありますが、セキュリティの面で心配があります。より安全な方法としては、ルーターがIGMP/MLDメッセージを終端する方法があります。この場合、ルーターは、網側に対してリスナーとして振舞う必要があるので、実装が難しくなります。RTシリーズでは、後者の実装を実現しています。

PIM-SM

概要

PIM-SMは、網内のルーターが、 経路情報を動的に構成するために使用するプロトコルです。ユニキャスト通信では、RIPやOSPF、BGPなどのプロトコルがこれにあたりますが、PIM-SMはマルチキャスト通信を対象に経路情報の制御を行います。

  • ユニキャストの経路を構成する ... RIP、OSPF、BGPなど
  • マルチキャストの経路を構成する ... PIM-SM、PIM-DM、DVMRPなど

この分類について、前者をユニキャストルーティングプロトコル、後者をマルチキャストルーティングプロトコルと呼びます。PIM-SMでは、ユニキャストのルーティングを基盤として、マルチキャストのルーティングを実現します。言い換えると、網内ではユニキャストパケットをルーティングする必要があります。一方、PIM-SMは、ユニキャストルーティングの実現方法を規定していません。すなわち、RIPやOSPF やBGPなど、任意のユニキャストルーティングプロトコルを利用できます。

PIMは、Protocol Independent Multicastの略で、特定のユニキャストルーティングプロトコルに依存しないことを表現しています。SMSparse Modeの略で、リスナーが離散的に存在しているときに、より効率的に動作することを示します。SM(Sparse Mode)の反対の概念としてDM(Dense Mode)があります。Dense Modeは、リスナーが密集して存在しているときに、効率的に動作します。

ランデブポイント

マルチキャスト網では、あらかじめ中心的な役割を果たすルーターを決めておき、これをランデブポイント(Rendezvous Point)と呼びます。
ランデブポイントの役割は、デフォルトの配送木を提供することです。通常、配送木はソースごとに構築されますが、初期の段階では、 ソースごとの配送木は構築されていません。このような状態でパケットの配送を請け負うのがランデブポイントの役割です。
ランデブポイントは網内のルーターから選出されます。自動的に選出する仕組みとして、Bootstrap Router(BSR)というプロトコルが提案されています。BSRを使わずに手動で設定する運用もあります。
なお、ヤマハルーターにはランデブポイントとして動作する機能は実装されておりません。

図5: ランデブポイントの位置

図5: ランデブポイントの位置

Helloメッセージと指定ルーター

イーサネットのように複数の端末が同一セグメントに接続する構成では、その中から代表として1つのルーターを選出します。選出したルーターを指定ルーター(Designated Router)と呼びます。これは、OSPFのDesignated Routerと同様の概念です。
また、指定ルーターを選出するために、Helloメッセージを交換します。Helloメッセージにはルーターの優先度が含まれており、優先度の高いルーターが指定ルーターになります。優先度が同じ場合には、IPアドレスの大きいものが指定ルーターになります(図6)。

図6: 指定ルーターの選出

図6: 指定ルーターの選出

なお、Helloメッセージの役割は、指定ルーターを選出するだけではありません。その他にも多数のパラメータを含んでおり、ルーター間でのネゴシエーションの対象となります。ルーターは、リンクの種類を問わず、すべてのインターフェースで定期的にHelloメッセージを交換します。

Join/Pruneメッセージ

Join/Pruneメッセージは、 リスナーが受信すべきグループやソースの情報をランデブポイントやソースに伝えるものです。 Joinは受信を希望するという肯定的な意味を伝え、Pruneは受信を希望しないという否定的な意味を伝えます。
Join/Pruneはユニキャストのパケットであり、ユニキャストルーティングプロトコルにしたがって転送されます。 多くの場合、リスナーと直接つながっているルータが最初にJoin/Pruneを生成し、それが、ランデブポイントかソースまで転送されていきます。
Joinの役割は、マルチキャストの経路を生成して配送木を構築することです。 網内のルーターは、Joinを順番に中継して、 最終的にはランデブポイントかソース(※)に届けます。途中でJoinを中継したルーターは、中継した方向とは逆の方向に、マルチキャストの経路を生成します。最終的には、ランデブポイントやソースを中心とする配送木が構築されます(図7)。

(※) 正確にはソースではなくて、「ソースに直接つながっているルーター」です。ソースは必ずしもPIM-SMをサポートしているとは限りません。

図7: Joinメッセージと経路(配送木)の関係

図7: Joinメッセージと経路(配送木)の関係

Pruneの役割は、Joinとは逆に、経路を破棄して配送木を刈り取ることです。動作はJoinと同様なので省略しますが、Pruneを中継したルーターが経路を削除していきます。なお、グループG、ソースSのパケットを受信したいという希望に相当するメッセージを、(S,G) Joinと書きます。同様に、(S,G) Pruneは、パケットを受信しないという希望に相当します。また、ソースを特定せず、すべてのソースを受信する場合には(*,G) Join(*,G) Pruneと書きます。

RPT (Rendezvous Point Tree)

リスナーをマルチキャスト網に接続すると、そのリスナーと接続している指定ルーターは、(*,G) Joinをランデブポイントに向けて送信します。(*,G) Joinは途中のルーターを1つずつ経由して、やがてランデブポイントに到着します。前述のとおり、途中のルーターには、パケットを配送する経路が生成されます。つまり、ランデブポイントを中心とする配送木が構成されることになります。この配送木をRPT(Rendezvous Point Tree)と呼びます(図8)。
ランデブポイントは必ずしもソースと一致しないので、ソースがマルチキャストパケットを送信するときには、パケットをランデブポイントに渡す必要があります。このために、ソースはRegisterというメッセージの中にマルチキャストパケットをカプセル化して、ランデブポイントにユニキャストします。ランデブポイントはそれを展開して、元のマルチキャストパケットを取り出し、それを配送します。パケットはRPTにしたがって網内に配送されていきます。

図8: RPT

図8: RPT

SST (Source Specific Tree)

Registerを使ってパケットを配送する方法では、ルーターの負荷が大きくなります。そこで、ランデブポイントは、 (S,G) Joinというメッセージをソースに対して送信します。これによって、ソースを中心とする配送木(SST)が構成されます。 SSTが完成したら、ランデブポイントはソースに対しRegister-Stopを送信します。ソースは、Register-Stopを受信したら、Registerを使わずにマルチキャストパケットを送信します。パケットはSSTにしたがって網内に配送されていきます(図9)。

図9: SST

図9: SST

SPT (Shortest Path Tree)

SSTは、ソースを中心とする配送木ですが、経路は最適化されていないので、必ずしも最短の経路になっているわけではありません。そこで、リスナーを収容しているルーターは、ソースに対して(S,G) Joinを送信します。これによって、ソースからリスナーへ至る最短の配送木(SPT)が構成されます。パケットはSPTにしたがって網内に配送されていきます(図10)。

図10: SPT

図10: SPT

PIM-SSM

SSMは、Source Specific Multicastの略です。セキュリティ上の理由により、ソースを特定して運用するマルチキャストを意味しています。逆に、ソースを特定しないで、すべてのソースからのマルチキャストパケットを受信する運用をASM (Any Source Multicast)と呼んでいます。
SSMを実現するためには、IGMPv3を使用する必要があります。これよりも低いバージョンでは、ソースのIPアドレスを指定できないので、リスナーがソースに対する選り好みをルーターに伝えることができません。ルーターは、RPTを介して受信したパケットを破棄し、SSTやSPTを介して受信したパケットのみを下流に転送します。これによって、リスナーが希望するソースから受信したパケットのみをリスナーに届けることができます。

ページトップへ戻るReturn to Top