この記事はシスコの有志による Cisco Systems Japan Advent Calendar 2022 の１つとして投稿しています。昨年の記事や関連する投稿記事は以下リンクよりご覧いただけます。
- 2017年版: https://qiita.com/advent-calendar/2017/cisco
- 2018年版: https://qiita.com/advent-calendar/2018/cisco
- 2019年版: https://qiita.com/advent-calendar/2019/cisco
- 2020年版: https://qiita.com/advent-calendar/2020/cisco
- 2020年版(2枚目): https://qiita.com/advent-calendar/2020/cisco2
- 2021年版: https://qiita.com/advent-calendar/2021/cisco
- 2021年版(2枚目): https://qiita.com/advent-calendar/2021/cisco2
- 2022年版: https://qiita.com/advent-calendar/2022/cisco
InterBEE & IP PAVILION
前回のAdvent Calenderの投稿から早1年近く、年末に向けてゆっくりできているかと思いきや、、
11/16-18に幕張メッセで開催されたメディア総合展示会 InterBEE 2022 に出展しておりました。
今年は放送システムのIP化、そしてリモートプロダクションの実現に向けた製品やデモ紹介などなど多くの展示を行っておりました。
ブースへお越しくださったみなさま、ありがとうございました！
人気だった瓦せんべいもゲットいただけましたでしょうか。。？
また、ブース出展以外にも複数の企業が参加し、相互接続によるシステム構築・展示を行うInter BEE IP PAVILIONに協力させていただきました。展示会までいろいろな苦労がありましたが、検証から構築までの経験を得られたことはもちろん、お越しくださった皆様からたくさんのご意見やアドバイスをいただけたことが何よりの励みになっています。
本当にメディア関連のお仕事づくしなここ1,2か月でした。
今回はそんな活動の中で制作した、NexusスイッチとNMOSの連携を行うツールを紹介します。
AMWA NMOS
IP PAVILIONでも活用されていたNMOS（Networked Media Open Specifications）は、異なるベンダーのメディア機器（カメラ・モニタ・スイッチャー等）をIPによって制御する相互運用のためのオープンな仕組みです。
NMOSはIPによるメディア伝送に向けたソリューション開発を促進するフォーラムであるAMWA（Advanced Media Workflow Association）によって仕様策定が行われており、機能に応じてIS（Interface Specifications）として分類されています。
- IS-04: Discovery & Registration
- IS-05: NMOS Device Connection Management
- IS-06: Network Control
- IS-07: Event & Tally
- IS-08: Audio Channel Mapping
- IS-09: System Parameters
- IS-10: AMWA Specification
- IS-11 Stream Compatibility Management
- IS-12 Control Protocol
NMOSの仕様やテストコードはWebページとGithubに公開されています。
それぞれを説明していくとそれだけで１つの記事になってしまいますので、ここではご紹介に留めておきます。
Nexusスイッチ : Non-Blocking Multicast 機能
データセンター向けのスイッチであるNexus 9000シリーズは、メディア伝送で利用できる機能も有しています。それらの機能の1つとして Non-Blocking Multicast (NBM)があります。
NBMには
- PIM Active: ストリームごとに帯域予約を行い、各リンクの使用帯域を把握しながら帯域あふれを防ぐ
- PIM Passive：SDN Controller等から投入される各ストリームのルート情報に従って伝送を行う
といった2つのモードがあり、用途に合わせて利用するモードを選ぶことができます。
より詳細な機能の内容については、Cisco IP Fabric for Media White Paperをご参照ください！
NBM PIM Active Mode
NBMのPIM Active Modeについて簡単に紹介します。
こちらのモードでは、ストリーム（マルチキャストアドレス）ごとに利用する帯域をFlow Policyという形で指定する必要があります。デフォルトの設定では対応するストリームのFlow Policyがない場合にはドロップされるようになっており、許可されたストリームのみが割り当てられた分の帯域を利用して伝送されていきます。
さらに、転送先のインターフェースの使用可能な帯域が、Flow Policyに割り当てられている帯域よりも少ない場合、スイッチはそのインターフェースに対する転送を行いません。
PIM Activeモードではこのような仕組みによって、ロスレスのマルチキャストの伝送を実現しています。
NMOS/NBM連携ツール - CASTaNET
ここまでにご紹介したNMOSとNBMですが、それぞれ運用面において懸念がありました。
- NMOS : IS-06（Network Control）の利用が非推奨となり、ネットワーク側の制御をNMOSを中心に行うことが難しくなった
- NBM (PIM Active) : Flow Policyの設定をストリームごとに行う必要があり、新しいストリームを伝送する場合には各機器への再設定が必要（作業コストが高くなる）
そこで、NMOS IS-04で登録される機器情報をベースに帯域マッピングを自動的に行い、Nexusスイッチへ設定を反映するツール「CASTaNET」を作成しました。
CASTaNET : システム構成
CASTaNETはスイッチのアプリケーションホスティング機能の利用も見据えて、コンテナベースのアプリケーションとして作成しています。コード自体はNodeJSのTypescript互換モードで記述しています。
選定理由としては、
- 静的な型付けによって複数のAPI間をスムーズに連携させられる
- 今後、WebGUIを組み込む際にFront/Backで同一言語を使える
- SDP周りの既存ライブラリsdp-transformが使いやすい
といったものがありました。が、既存ライブラリが素晴らしかったので即決したというのが正直なところです 
前回の記事に引き続き今回もイメージのミニマム化を図ってみました。
やはり、コンテナのマルチステージビルドは便利ですね。。一度、これで組んでしまうとやめられません。結果、170MB程度のイメージとなりました。
FROM node:alpine as ts-builder
WORKDIR /build
COPY package*.json src tsconfig.json ./
RUN npm install \
&& npm run build
FROM node:alpine
WORKDIR /dist
ENV NODE_ENV production
COPY --from=ts-builder /build/dist/* /build/package*.json ./
RUN npm install --omit=dev \
&& npm cache clean --force
CMD ["node", "./app.js"]
CASTaNET : ワークフロー
CASTaNETは起動時にSDPで得られる情報とNBMで指定する帯域の紐づけが記載された設定ファイル(YAML)を読み込みます。
これを保持しつつ、以下の動作を繰り返し行います。
- IS04 Query APIにてRDSへ問い合わせてSenderの一覧を取得
もしくは、Websocketによる通知を受信し、追加されたSenderの情報を取得 - 得られた各SenderのSDPのURLへアクセスし、記載されている以下のパラメータ値を確認
- Multicast Address
- Media Type
- RTP rate
- FMTP (width/height)
- 設定ファイルの記述と照合し、スイッチ側に対するAPIのパラメータへ変換
- 生成された帯域予約の設定をNexusスイッチへREST APIで入れ込む
CASTaNET : 改善点
動作テストはDocker Hubにて公開さているNMOSコンテナrhastie/nmos-cppを利用して行いました。
1台のIP-GWの登録情報を変更しながら、それに応じたFlow PolicyがNexusスイッチに随時適用されることが確認できています。
ただ、実際の運用においては数百台規模のIP端末がネットワークに接続されるため、多数のAPIコールが発生することになります。現在の実装ではスケールや即時適用という点が大きな課題となります。
今回は、CASTaNET単体から1つのNexusスイッチへAPI経由でFlow Policyを入れ込んでいく形をとりましたが、大規模なファブリックにおいては複数のNexusスイッチをまとめて管理するコントローラ（Nexus Dashboard Fabric Controller）等を介して一括設定をすることも負荷軽減や整合性を担保するという点で有利になると考えています。
Nexus DashboardにはNBMをはじめとした機能の一括設定や、実際のトラフィックやPTPの同期情報を一元的に可視化する機能も内包されているので、次回の投稿でご紹介します！
まとめ
今回は、NMOSとNBMを連携させるツール CASTaNETをご紹介しました。
年内には体裁を整えて、Github等でコードを公開しようと思います。（がんばります 
）
お仕事柄、資料作成やデモを行うことが多いのですが、しっかりと目標を立ててモノづくりをするのは気持ちいいですね。。。
ここまでお読みいただきありがとうございました。
みなさまもよい年末をお過ごしください～ 
免責事項
本サイトおよび対応するコメントにおいて表明される意見は、投稿者本人の個人的意見であり、シスコの意見ではありません。本サイトの内容は、情報の提供のみを目的として掲載されており、シスコや他の関係者による推奨や表明を目的としたものではありません。各利用者は、本Webサイトへの掲載により、投稿、リンクその他の方法でアップロードした全ての情報の内容に対して全責任を負い、本Web サイトの利用に関するあらゆる責任からシスコを免責することに同意したものとします。