Ethernet TSN の QoS（3）IEEE 802.1Qat:SRP / 配信手順

SRP(Stream Reservation Protocol:ストリーム予約プロトコル)は、ストリームの配信経路を確定し、経路上のスイッチやエンドステーション(映像表示装置など)の帯域確保と最悪時の遅延時間の確認を行うプロトコルだ。この規格は当初 IEEE802.1Qat として標準化されたが、後に IEEE802.1Q-2011 に組み込まれた。

SRP の基本動作は、ストリーム配信元(Talker:トーカー)からストリームを受信するエンドステーション(Listener:リスナー)までの経路を構築し、帯域幅や遅延時間などの QoS 要件を満たすことだ。まずは、ここで登場する用語を説明したい。

SRP の主な用語

SRP の主な用語は次の通りだが、各用語のイメージは図1 を参照いただきたい。ここで重要な役割を果たすのが「AV Bridge」だ。AV Bridge は、様々な QoS パラメータやポート情報の登録削除を行い、遅延時間計算や IEEE802.1Qav で規定するシェーパ機能により必要な QoS を実現している。

SRP 配信手順

Talker が好き勝手にストリームを送信したのでは、確実に Listener に届く保証はなく、既に正常に配信されているストリームを乱す恐れもある。そこで、Talker が送信を開始する前に、次のポイントを事前に確認し必要なリソースを確保する手順が作られた。

まず、ネットワーク全体で経路が作られる様子を説明する。具体的な手順は、次の4つのステップに
分かれる。

※ Asking/Advertise/Ready は様々な用語が使用されている。注意が必要。

Step1

Step1 は、Listener による配信要求問合せ(Asking)をネットワーク全体に通知（マルチキャスト）し登録することだ。図2 のように Listener が送信した Asking マルチキャストフレームは、途中経路の Bridge で全てのポートにコピー出力され、ネットワーク全体に行き渡る。ストリーム送信元の Talker 以外のエンドステーションは、このフレームを受信後廃棄する。Talker はこのフレームを受信すると、ネットワーク上にストリーム配信を要求する Listener が居ることに気が付く。もちろんフレームを中継している Bridge も同様に Listener の存在と到達経路を学習することができる。

途中経路の Bridge が初期状態で Talker のアドレスを学習していない状態では、Talker の接続先を探すため全てのポートに Asking マルチキャストフレームを送信する。これを Flooding (洪水)と呼ぶ。学習が完了すると、Flooding は止まり Talker 接続ポートにのみ送信するように変わる。

ネットワーク全体に行き渡る過程で、Bridge は フレーム受信ポートを「Asking(問合せ)」、出力ポートを「Declaration(宣言)」ポートに設定する。Talker から逆方向に Asking(問合せ)ポートを辿ると、Listener にたどり着くことができる。つまり、Talker から Listener にたどり着くストリーム配信ルートが出来上がったことになる。

Step2

無事 Asking が Talker に到着すると、Talker は「予約広告(Advertise)」動作を開始する。 Advertise を受信した Bridge は、要求された QoS 要件に見合う帯域などのリソースを確保できるか確認し、要求を満たすことができれば必要なリソースを予約し、内部のデータベースを更新する。

Listener 接続先は学習済のため、接続先のポートにのみフレームを転送する。この作業を途中経路の全ての Bridge で行い、最終的に Listener に到達する。Advertise を受信したポートは、ポート状態を D→Ad に変える。ストリーム配信経路は、Ad→As になる。途中経路の全ての Bridge でリソースを確保し、予約が完了したケースが、図3 だ。

Step3

Talker が送信する Advertise が Listener に到着すると、Listener は到着した情報を確認する。途中経路のリソース確保に成功したことを確認すると、Listener は「準備完了(Ready)」を送信し、Talker に対しストリームの配信を要求する。図4 のようにReady は既に構築された経路 を通りTalker に届く。 Ready を受信したポートは、ポート状態を As→R に変える。ストリーム配信経路は、Ad→R になる。この段階で QoS 要件を満たす経路が確定する。いつでも、ストリーム配信ができる状態になる。

図5 は、途中経路の Bridge2 でリソースを確保できず「予約広告(Advertise)」に失敗した例だ。Bridge2 でリソースを確保できなかったため、失敗箇所の情報は順次伝播し Listener に届く。これらの予約の成功と失敗は、Talker にも届く。経路は完成したが、リソース確保に失敗したため、Listener はストリームの配信要求ができない。

Step4

図6 のように3つの手順で経路が構築され、4ステップ目でストリームの送信を開始する。しかし実際は、Talkerと Listener が送信するメッセージは中継 Bridge をステップバイステップで進み、様々な状況に対応できるように作られている。また、プロトコルも SRP と表記してきたが、実際は図7 の様に SRP 配下の MSRP プロトコルで動作している。 SRP はMSRP のアプリケーションの位置づけだ。MSRP の配下にある MRP は幾つかの物理層に対応するためのプロトコルで、MSRP/MVRP/MMRP 共通プロトコルになっている。MSRP は物理層を切り離した形になるため、データ長は物理層で付加される部分を除いた「ペイロード」の表記になる。イーサネット上での動作を考える場合は、ヘッダと FCS を加算する必要がある。