It is the top of the page

Link for moving within the page
To text (c)

このウェブサイトではサイトの利便性の向上のためにクッキーを利用します。サイトの閲覧を続行されるには、クッキーの使用にご同意いただきますようお願いします。
お客様のブラウザの設定によりクッキーの機能を無効にすることもできます。詳細はこちら

The main part starts here.

  1. ナレッジセンター
  2. 匠コラム

放送システム IP 化に向けたネットワーク技術

匠コラム
ネットワーク

ビジネス推進本部 第3応用技術部 第2チーム
細谷 典弘

最近、4K/8K テレビの話題を聞くようになってきました。
映像の高解像度化により、従来の SDI による映像配信から IP による映像配信が注目され始めています。

しかしながら、ただ IP 化を行っただけでは、SDI のような高品質な伝送路を構築することは出来ません。
また、放送システムの伝送では時刻同期も重要であり、PTP が必要になります。
そのため、PTP のためのネットワーク設計も必要になります。

本コラムでは、SDI のような高品質のネットワークを実現するための技術である Non-Blocking Multicast を紹介します。

一般的なマルチキャスト通信

基本的に IP ネットワークはドロップが発生することを前提として設計します。
例えば図1のようなネットワークで Audio と Video を流したときに、マルチキャストの設定により Audio や Video のようなマルチキャストの通信をロードバランスすることは可能です。


図1:一般的な IP ネットワークのトポロジー(Spine-Leaf モデル)

しかしながらロードバランスを行っても、図2のようにスイッチ間の帯域が 40G で 36G の帯域を使用しているときに 12G の映像を追加で流した場合、ハッシュ計算により映像が流れるリンクが決まってしまい、帯域に余裕があるリンクがあっても輻輳しているリンクが選ばれ、映像の通信でドロップが発生する可能性があります。


図2:ハッシュ計算によるドロップ

そこで、映像の通信で必要なマルチキャストにおいて、ドロップをしない仕組みが必要になります。

Non-Blocking Multicast

ここからは、マルチキャスト通信でドロップを発生させない Non-Blocking Multicast の紹介になります。
ある映像を流すために IGMP の join が来た場合、Non-Blocking Multicast では、その映像に必要な帯域を予約します。
次の検証で、その動作を確認します。

図3と図4のマルチキャストルーティングのテーブルを作成した検証では、IGMP の join をさせる順番を変えています。
図3のマルチキャストルートを見ると、送信元:10.1.11.2、送信先:239.1.110.2 の映像が流れてくるインタフェースは 1/49 になっています。
図4を見ると、映像の流れてくるインタフェースが 1/50に変わっており、映像の流れるリンクはハッシュ計算では決まらず、帯域の予約状況を見て使うリンクを決めていることが分かります。


図3:show ip mroute


図4:show ip mroute

つまり図2で起きていたようなドロップは発生することがなく、図5のように帯域の空いているリンクがあれば、そのリンクを使うようになります。


図5:Non-Blocking Multicast を使った場合

したがって図6のように、Non-Blocking Multicast でネットワーク内に映像や音声などの専用の伝送路を擬似的に作ることが可能になり、図7のように Camera と Monitor があたかも SDI ケーブルで直接繋がられているようになります。


図6:Non-Blocking Multicast を使ったときの IP ネットワーク内の映像用伝送路


図7:Non-Blocking Multicast を使ったときの伝送路

Cisco の DCNM (Data Center Network Managers) という製品では、図8のように、その専用の伝送路を可視化することが可能です。


図8:DCNM を使った可視化

注意すべき点としては、帯域に空きが無い場合は新たな映像用の igmp join が来ても、図9のようにマルチキャストルーティングは作られず、その映像用の通信経路は作られないということが挙げられます。


図9:帯域に空きがないときの show ip mroute

Non-Blocking Multicast と Qos

IP のネットワークで映像や音声を流す場合、それ以外の IP パケットが同時に同じリンクを通ることが可能なため、映像や音声のパケットがドロップする可能性があります。
そのため、映像や音声の帯域を確保するために QoS の設定が必要になります。
Non-Blocking Multicast では、映像や音声の帯域が確保されているため、それ以外の通信よりも優先されます。

図10のように Video:4Gbps, Audio:1Gbps の帯域を確保している状況で、10Gbps のリンクに、音声用に1つ、映像用に2つの通信を流し、その他の IP 通信で2Gbps の負荷を掛けます。もし QoS の設定が無ければ、すべての通信でドロップが発生しますが、Non-Blocking Multicast では、映像と音声用に帯域を確保しているため、図11のように、映像と音声の通信ではドロップが発生せず、その他の IP 通信でドロップが発生します。


図10:帯域の設定


図11:QoS 試験

最後に

ここまで見てきて分かりますように、Non-Blocking Multicast を使うことで、IP ネットワーク内に映像や音声の伝送路を SDI のように作ることが可能になります。
しかしながら、専用の帯域を確保するため、リンクの帯域に空きがないときは、新たな伝送路を作ることが出来なくなるため、帯域の設計が重要になります。
また、今回は紹介していませんが、冗長経路の設計や障害時の動作も重要です。
さらに映像と音声の同期などに PTP を使うため、PTP のためのネットワーク設計も必要です。
今後、今回のコラムでは説明できなかったこれらの情報に関しても、本コラムで紹介していく予定です。

執筆者プロフィール

細谷 典弘
ネットワンシステムズ株式会社 ビジネス推進本部
第3応用技術部 第2チーム 所属

マルチクラウド基盤に用いられるハードウェアとソフトウェアの最先端テクノロジーに関する調査・検証と、案件の技術支援をする業務に従事。
特に Kubernetes に注目している。
また最近では、放送業界の IP 化に向けた技術調査・検証も行っている。

  • CCIE Routing and Switching (#16002)
  • CCIE Data Center (#16002)
  • Red Hat Certified System Administrator in Red Hat OpenStack(RHCSA) (EX210)
  • 電気通信主任技術者(伝送交換)

Webからのお問い合わせはこちらから

ナレッジセンターを検索する

カテゴリーで検索

タグで検索