IPマルチキャストによる映像配信の設計

読み:あいぴーまるちきゃすとによるえいぞうはいしんのせっけい / 英語表記:IP multicast video distribution design

同じ映像を複数の受信者へ効率よく届けるため、受信者の参加管理とルータ間の配送経路を組み合わせる設計である。L2スイッチの転送制御、送信元とグループの組による配信の識別、回線ごとの必要帯域を整理する。

イマシルちゃんの解説

一台のカメラの映像を六台のモニターで見るとき、同じ映像を別々に送ると回線を余計に使ってしまうね。
IPマルチキャストは、同じデータを経路の分かれ目で複製して複数の受信者へ届ける通信方式だよ。
IPv4では、端末が受信したい配信を近くのルータへ知らせるプロトコルにIGMPを使うんだ。
ルータ同士で配信経路を作るのは、別のプロトコルのPIMだよ。
L2スイッチには、IGMPのやり取りを見て受信者のいる接続先へ転送を絞るIGMPスヌーピングという機能があるんだ。
この三つの役割を分けて設計すれば、必要な場所へ映像を届けながら、見ていない端末側へ流れる余計な通信を減らせるよ。

より深い解説

同じ映像を何回運ぶかで考える

ユニキャストで同じ映像を六台へ配る場合、送信元は受信者ごとの通信を用意する。これらが同じ回線を通れば、その回線には同じ内容のデータが重複して流れる。

マルチキャストでは、複数の受信者へ向かう経路が分岐する場所でパケットを複製する。同じ配送ツリーの共通区間では一組の映像データを運び、分岐後の必要な出力先へ送る。受信者が増えても、全ての区間の帯域が人数に比例して増えるわけではない。

ただし、必要な送信元の種類が増えれば共有区間の通信量も増える。カメラAを見る人が増える場合と、今まで見ていなかったカメラBの映像を新しく流す場合は違う。

変化共有する配信区間への影響
既に配信中の映像を別の端末でも受け取る同じ枝を共有する範囲では、その映像をもう一組流す必要はない
別のカメラの映像を新しく受け取る新しい映像が通る区間では通信量が増える
同じ映像を別の支店へも配る分岐後の支店向け回線にも映像が流れる
誰も受け取らなくなる参加状態が削除されれば不要な配送の枝を取り除ける

送信側の直結区間では、下流の視聴状態にかかわらずカメラが送信し続ける構成もある。計算するときは「どの回線を横切るデータか」を必ず指定する。

三つの装置が担当する仕事を分ける

IPv4のマルチキャストでは、端末の参加とルータ間の経路作成を別の仕組みで扱う。通常のユニキャスト経路を設定しただけで、複数の宛先へ必要な分だけ複製する動作まで完成するわけではない。

場所使う仕組み管理する情報
受信端末と同じリンクのルータIGMPそのリンクにどの配信の受信者がいるかを把握する
L2スイッチIGMPスヌーピングどのポートの先に受信者がいるかを把握する
マルチキャストルータ同士PIM上流から受けたデータをどの下流へ配送するかを決める

IGMPは端末が参加情報を伝えるためのプロトコルである。端末からの通知をそのまま遠くの送信元までルーティングするのではなく、受信者側のルータが情報を利用し、必要な配送経路を上流へ要求する。

IGMPスヌーピングはスイッチがIGMPのやり取りを観測する機能であり、IGMPとPIMを置き換えるものではない。ルータの役割とL2スイッチの役割を区別することが、設定箇所を判断する出発点になる。

不要なフラッディングを抑える

マルチキャストの受信者を把握しないL2スイッチでは、対象フレームが同じVLANの複数ポートへフラッディングされる場合がある。映像のような連続した大きな通信では、見ていない端末の接続回線まで帯域を使ってしまう。

IGMPスヌーピングを有効にすると、参加情報に基づいて受信者のいるポートへ転送を絞れる。マルチキャストルータにつながるポートの扱いも必要であり、「受信端末がないポートは全て閉じる」という単純な処理ではない。

参加情報は永続的に正しいとは限らない。端末が移動・終了するため、IGMPのQueryとReportによって状態を更新する。クエリアが不在のままスヌーピングだけを有効にすると、状態の期限切れなどで期待どおり配信されない構成もある。未登録のマルチキャストを転送するか捨てるかも製品の設定を確認する。

同じポートの先に複数端末がいる場合は、最初の一台の離脱だけでそのポート全体への配信を止めないようにする。Fast Leaveなどの最適化を適用できる条件は、接続構成によって異なる。RFC 4541はスヌーピング実装での考慮事項を整理している。

配信をグループだけで識別するか

マルチキャストでは、受信したい配信の宛先としてグループアドレスを指定する。グループをG、送信元のIPアドレスをSと表す。

任意の送信元からグループGへの通信を受けるモデルでは、複数のカメラが同じGへ送ると、受信者はグループの指定だけでカメラを一台に絞れない。アプリケーション側で捨てることはできても、ネットワークが必要な映像だけを配送するとは限らない。

これに対しSSMは、特定の送信元から特定のグループへ送られる配信を選ぶモデルである。チャネルを(S,G)で識別するため、同じGを使ってもSが違えば別の配信として扱える。

モデル受信者が指定する情報カメラごとの選別
ASMグループGを指定するグループの指定だけで送信元を一台に限定しない
SSM送信元SとグループGを指定する同じGでも送信元を指定して選別できる

IPv4でSSM用に割り当てられた範囲は232.0.0.0/8である。一般のIPv4マルチキャスト範囲全体と同じではない。用途、アドレス範囲、対応機器をそろえて利用する。

SSMの定義とアドレス範囲はRFC 4607で確認できる。送信元を指定できることは、その送信者を暗号学的に認証することとは異なる。安全性が必要なら認証や送信元偽装への対策も別に検討する。

IGMPの版によって伝えられる情報が違う

IGMPv2の基本的な参加通知はグループを対象とする。一方、IGMPv3は送信元フィルタを扱い、受信したい送信元の集合などを通知できる。特定のカメラの送信元を指定する構成では、この違いが重要になる。

IGMPv3のINCLUDEは指定した送信元から受け取りたいことを表し、EXCLUDEは指定した送信元を除いて受け取りたいことを表す。SSMでは、選んだ送信元を含める通知を利用する。

例えば受信者がカメラAからカメラBへ表示を切り替えると、受信に必要な送信元の条件も変わる。端末のソフトウェア、隣接ルータ、途中のスヌーピング機能が、その情報を適切に扱える必要がある。「スイッチがIGMP対応」という表示だけで、送信元単位の制御まで対応すると決め付けない。

令和5年度の問題では、カメラごとに送信元IPアドレスが異なる一方、同じグループを使う条件が示される。そこで古い版の参加通知だけを前提にすると、カメラを選ぶための情報が不足する。IGMPv3の当時の仕様はRFC 3376を参照できる。

PIMとユニキャストの経路情報をつなげる

PIMはProtocol Independent Multicastの略である。特定のユニキャスト経路制御プロトコルだけに依存せず、利用可能な経路情報を基に配送ツリーを作れるという意味であり、経路情報が不要という意味ではない。

受信者側のルータは、送信元へ向かう上流を経路情報から判断し、必要な配信へのJoinを送る。データはその逆向きに上流から届く。配送は一方向のツリーとして考え、参加通知の向きと映像の向きを区別する。

RPFは、送信元へ戻る経路などから期待される受信インタフェースを判断する仕組みである。映像が別のインタフェースから入ると、ループなどを防ぐために受け入れられない場合がある。送信元にpingが通ることだけで、マルチキャストの転送が正しいと判断しない。

PIM-SMのASMでは、RPという合流点を根とする共有ツリーを使い、必要に応じて送信元への最短経路ツリーへ切り替える。SSMでは送信元が分かっているため、RPを経由する共有ツリーを必要としない。SSMを使うこととPIMを使うことは排他的な選択ではない。

PIM-SMの動作とSSMへの適用はRFC 7761に記載されている。OSPFは上流を判断する経路情報を提供できるが、OSPF自身が受信者の参加を管理するわけではない。

帯域は通過する映像の種類から計算する

令和5年度午後Ⅰ問2の条件では、カメラ20台がそれぞれ8Mbit/sの映像を送り、6台の受信装置が最大4画面ずつ表示する。全受信装置の表示枠は24個だが、存在する映像の種類は20までである。

共通区間を通るマルチキャストの映像が全20種類になった場合、最大の合計は次のように求められる。

異なる映像の最大数 = min(20台, 6台 × 4画面) = 20
共通区間の映像通信量 = 20 × 8Mbit/s = 160Mbit/s

同じカメラを複数画面で選んでも、その共通区間に同じ配信を画面数分流す必要はない。受信装置の台数だけで送信レートを掛けると、ユニキャストの計算を混ぜてしまう。

一方、受信装置一台が四種類を受け取る接続回線は32Mbit/sになる。途中の回線では、その先にある受信者が要求する映像の集合を作って計算する。上流の値を全ての回線へそのまま当てはめてはいけない。

問題が与えるレートに既にヘッダーを含む場合は、同じ分を二重に加算しない。実設備では管理通信、突発的な変動、将来の増設、障害時の迂回を含めて余裕を確保する。優先制御を追加しても物理的な回線容量そのものは増えない。

管理用通信と映像用通信を分ける

カメラ管理サーバの画面をHTTPSで操作する通信は、管理端末から管理サーバへのユニキャストである。映像を受信するマルチキャストとは宛先も動作も異なる。

管理用の許可ルールを作る際は、誰が接続を開始するかを確認する。ブラウザが管理サーバへ接続する構成なのに、端末から全カメラへのHTTPS接続を一律に許可する必要はない。

Web画面からカメラを選べることも、ブラウザだけで任意のIPマルチキャスト映像を受信・表示できることを意味しない。問題では対応ソフトウェアとの連携条件を読む。カメラ一覧を中央で管理する利点と、受信処理を担当するソフトウェアの機能を分けて説明する。

映像の復号は、圧縮符号化された映像から画像を再構成する処理を指す場合がある。ここでの復号を、暗号化された通信を解読する処理と無条件に同一視しない。

受信者を追加するときの設定と切り分け

新しいVLANや接続先のPCでも映像を見られるようにするなら、まずそのPCに直接つながるL3インタフェースを特定する。そこがIGMPで参加情報を受け取る場所になる。映像の経路上にある全インタフェースへ同じ設定を並べるのではない。

観測した状態次に調べること
端末が受信できないアプリケーションが指定する送信元・グループと参加通知を確認する
同じVLANの一部だけ失敗するスヌーピングの登録ポート、クエリア、端末側の受信設定を確認する
別のVLANへ届かない受信側インタフェースのIGMPと、ルータ間のPIMを確認する
Joinはあるが映像が届かない送信元への経路、RPF、転送状態、TTL、ACLを確認する
関係のない端末の回線まで混雑するフラッディングの範囲とスヌーピングの動作を確認する
カメラを切り替えると別の映像も届く送信元単位の選別と機器のIGMPv3対応を確認する

参加状態、上流インタフェース、下流の出力先、パケットカウンタを順に突き合わせると、設定不足の場所を絞れる。UDPを使う配信で欠損が発生した場合も、ネットワークが自動的に全て再送するとは限らない。映像側のバッファや損失回復の仕組みは別に確認する。

午後問題での問われ方

令和5年度午後Ⅰ問2では、映像を必要な受信者だけへ届ける機能の分担と、共通回線を流れる通信量の把握が中心になる。プロトコル名に加えて「端末とルータの間」「L2スイッチの中」「ルータ同士の間」のどこで動くかを答える。

問いの観点判断の根拠
不要な配信を抑える方法受信者のポート情報に基づいて転送を絞る
同一グループでカメラを選ぶ条件グループに加えて送信元を指定できるかを確認する
必要帯域対象区間を通過する異なる映像の数を数える
PCでの視聴機能の追加参加通知を受けるL3インタフェースと対応ソフトウェアを確認する

本稿は公式問題を題材にした学習用の解説である。設問固有の装置名、番号、字数条件は公式資料と照合する。

参考資料

実際の試験ではここに出る!全1問

ネットワークスペシャリスト

午後Ⅰ
↑