要約

  • RFC 1190 の中間 ST agent は、宛先 application の判断より前に CONNECT を確認し、hop-local な識別子を承認し、資源予約を試みることができた。
  • 宛先の ACCEPT は別の応答であり、その枝を通る間に実際に得られた FlowSpec を origin へ返した。
  • 複数宛先の stream は各 target の結果を集めて初めて完成する。完成した制御状態も、packet、media、人間の結果を証明しなかった。

データより先に木を作る

RFC 1190 は1990年10月、Experimental Internet Stream Protocol Version 2、ST-II を公開した。Limited-Use Experimental Protocol であり、Internet Standard ではない。RFC Editor と IETF Datatracker の記録は RFC 1819 による置換を示すが、現実の stream や一般普及を示す運用資料ではない。

ST-II は IP と同じ Internet layer に置かれた。packet を互いに独立したものとは扱わず、ひとつの origin から複数 target へ向かう simplex tree を先に構築した。stream は path だけでなく、各 agent の state と割り当てられた resource を含んだ。

setup の重さは意図的だった。route、TargetList の分割、control state、resource、multicast group、forwarding handle を先に決めれば、後続 data packet の処理を軽くできる。高速な data plane は、未処理の同意を消すのではなく、その前に control plane を必要とした。

HID-APPROVE が答えたのは隣接関係だった

中間 agent が CONNECT を受けると、正常なら ACK、HID-REJECT または HID-APPROVE を前 hop に早く返す。HID は後続 packet を効率よく転送するための Hop Identifier で、control message の Reference と対応づけられた。

肯定応答の範囲は、隣り合う agent 間の local state だった。次の route が成立すること、遠方の resource が十分であること、target process が存在すること、application が参加することは含まれない。中継点は自分の state を承認できるが、宛先の代理人にはならない。

global な stream Name、枝の TargetList、local な HID、上位 protocol と process を選ぶ SAP は別の識別子だった。どれも人の identity や authorization を自動的に表さない。

FlowSpec は経路上で現実に近づいた

origin は FlowSpec に Desired と Limits を入れた。Desired は希望、Limits は中間や target が勝手に下回れない最低条件である。ある network が希望の帯域を全部出せなくても Limits 内なら、agent は実際に得た値へ Desired を直し、delay や variance を加え、必要なら PDU size を小さくして次へ渡した。

予約対象には bandwidth だけでなく、forwarding information、switch processing、buffer、multicast identifier が含まれた。ただし RFC 1190 は下位 network の共通予約方法を定めていない。文書自身、当時 reservation を提供する network は少なく、列挙した全 resource を予約するものは知られていないと述べた。

したがって FlowSpec の一行は end-to-end guarantee ではない。どの agent が、どの枝で、何を要求され、何を得て、どの Limits を満たしたかを保存して初めて意味を持つ。

宛先 application は変形後の条件を見た

CONNECT が target host に到着すると、host agent は HID negotiation を終え、Name、FlowSpec、Options、Group、application selector を対象 process に提示した。その process は参加を受け入れるか拒否し、場合によって Desired service をさらに下げた。

ここで初めて ACCEPT または REFUSE が作られる。ACCEPT は新しい Reference を持ち、LnkReference で元の CONNECT を指した。各 intermediate agent は対応を確認し、直近の sender に ACK を返し、元の path を逆向きに response を伝えた。

往路で起きた routing、resource allocation、HID agreement は target consent の準備だった。target が決めたのは participation、origin が後で決めるのは返された条件の採用である。protocol はそれぞれの decision owner を残した。

複数宛先は複数の結果を返した

origin は target ごとに ACCEPT、REFUSE または error を受け取る。ある target の ACCEPT が届いた時点で、その枝の resource は通知できる。しかし全 target の結果と identifier negotiation がそろうまで setup は完了しない。

返された FlowSpec は互換でないこともある。低 rate の大 packet を許す枝と、高 rate の小 packet を許す枝から、ひとつの安全な組合せを選べない場合があった。origin は target を落とす、stream を終了する、別 stream に分ける、といった選択をした。その後 CHANGE で過剰 reservation を解放する。

一枝の緑色表示を tree 全体へ広げてはいけない。結果は target と path に scoped され、aggregate state は origin の別決定だった。

ACCEPT は配送の領収書ではない

target が受け入れても、response の帰路が失敗し得た。ACCEPT に対する upstream ACK が再送後も来なければ、agent は origin へ REFUSE、target へ DISCONNECT を送った。高 precedence の stream に resource を奪われれば NOTIFY が revised guarantee を返し、失敗した CHANGE は reservation を部分変更したまま recovery を必要とすることもあった。

さらに ST は security service を自分では提供しなかった。ACCEPT は人、組織、権限、課金を認証しない。setup が完了しても、data が送られたか、packet が届いたか、音声や映像が decode されたか、利用者が品質を得たかは別の観測である。

次版は HID を捨て、意思決定の順番を残した

RFC 1819 は1995年に ST2+ を定義し、RFC Editor と Datatracker が記録を保つ。IESG Note は新旧どちらも Internet Standard ではなく、その候補でもないと明記した。

ST2+ は CONNECT の ACK、local resource manager、target application の判断、ACCEPT の return という骨格を維持した。一方、HID は複雑で interoperability の妨げになったとして削除した。subset implementation も、許可された部分実装が共通能力を保証しなかったため廃止した。

local identifier は設計から消えても、target consent の権限は残った。wire field、implementation compatibility、resource state、application decision を同じ事実にできないことが、revision 自体から分かる。

RFC 1077 は高速媒体だけでは足りないという課題を先に示し、後の RFC 1633 と RFC 2212 は別の reservation、guaranteed service surface を定義した。問題の類似は ST-II からの直接系譜や deployment を証明しない。

出典