Ethernet TSN の QoS（4）IEEE 802.1Qat:SRP / MSRP 動作とストリーム配信の可否判断

ネットワーク構成を単純化したモデルで、改めて MSRP の動作と Talker と Listener が送信する各種パラメータを説明したい。

図1 はMSRP 説明モデルで、次の要素からできている。全ての要素には MSRP と関連プロトコルが実装されている。

MSRP プロトコルは、Talker/Listener がストリーム送信する際に特有の属性を持つメッセージを送信する。このメッセージを受け取ったAV Bridge は要求された QoS 機能をサポートするために、メッセージのブリッジ内部での転送、メッセージに基づきキューイングやフィルタリングなどの管理情報を更新する。更新情報に従い、メッセージの修正や他ポートへの転送を行う。まずは、基本動作を再度説明する。

基本動作 Step1

Listener は、ストリームS を要求する Asking（問合せ）を送信する。AV Bridge は Asking を順次次段に転送し、最終的には Talker に到達する。 Asking を受信した AV Bridge と Talker は、受信ポートが Asking の状態であることを記録する（図2）。ここでは、Declaration（宣言ポート）は省略している。

このネットワークは同じ AVB クラウド内にある（例えば、SR クラスA 、Priority＝５）。ストリームの識別は、Talker の MAC アドレス（48ビット）と Stream ID（16ビット）で行うが、ここで送信する Asking には、ストリームS を指定する「Stream ID」が入っている。

基本動作 Step2

Talker は Asking に応え、 Advertise（予約広告）を送信する。AV Bridge は Advertise を順次次段に転送し、最終的には Listener に到達する。 Advertise を受信した AV Bridge と Listener は、受信ポートが Advertise 状態であることを記録する（図3）。Advertise メッセージに従い、帯域確保や遅延時間確認を行う。

Talker が送信する Advertise には次のような情報が入っている。

基本動作 Step3/4

Listener は Advertise の受信により、途中経路の AV Bridge がストリームの QoS 要件に対応したことを知ることができる。次いで、自分自身もストリーム受信の準備を完了すると Ready （準備完了）を送信する。 Ready を受信した AV Bridge3 は、ポートをAs→R に変更する。ポート状態が、Ad/R になると準備完了状態になり、次段の AV Bridge2 に Ready をフォワードする。

順次この手順を繰り返し、Ready がTalker に到着したところで、ストリーム配信の全ての準備が完了する。Talker はストリーム配信を開始できる。

MSRP 失敗例

MSRP 失敗例： Advertise

Listener が送信した「ストリームS を要求する Asking 」は既に Talker に到達しているいる状態で、AV Bridge2 と AV Bridge3 間の帯域が不足し、ストリームS が通過できないケースを想定している（図5）。

この状態で Talker が Advertise を送信すると、Talker→AV Bridge1→AV Bridge2 と伝搬する。AV Bridge2 出力ポートで帯域不足を検出し、QoS 要件を満たせないため経路設定に失敗する。ここで、Listener とTalker に対し次のように動作し、「失敗」をドメイン全体に通知する。

ネットワーク全体

上記の2つの手順で全ての関係者が「ストリーム予約」に失敗したことを知ることになる。キュー等の予約はすべて取り消され、Listener はストリームを要求せず、Talker もストリームを送信しない状態になる。

MSRP 失敗例： Ready

図7 は Listener を2台接続した例だ。Talker から Listener1 へのパスは図5/6 と同様に予約に失敗したが、Talker から Listener2 へのパスは予約に成功したケースだ。このケースでは、AV Bridge2 は「Ready failed」を Talker に向けて送信する。AV Bridge1 と Talker の受信ポートは、「Rf： Ready failed」に設定される。この時、Talker は少なくとも1台の Listener は予約に成功しているため、ストリームを送信できると判断し、ストリームを送信する。しかし、ドメイン内の全ての Listener がストリームを受信できる状態ではないことも分かっている。

この状態は、様々なタイミングで変化する可能性がある。Listener1 が先に処理された場合は「Asking Failed」になり、ストリームを送信できない状態になる。Listener2 が先に処理された場合は「Ready」になり、全てに送信できる状態になる可能性もある。最終的に、Listener1/2 の情報が揃ったところで「Ready failed」状態に遷移し、少なくとも1台の Listener が予約に成功した状態に落ち着く。

1台の Talker に複数の Listener が接続されている場合、ストリーム配信準備に成功した Listener と失敗した Listener が混在する可能性がある。この時、少なくとも1台の Listener への配信が可能ならば、ストリーム配信を開始する。全ての Listener への配信準備に失敗した場合は、もちろんストリーム配信を開始しない。

Talker が Advertise（予約広告）に失敗した場合は、ストリームを配信することはできない。成功した場合は、Listener の状態により配信の可否が決まる。つまり、配信の可否は、Talker の「Advertise」、Listener の「Asking」と「Ready」状態の組み合わせで決まることになる