要約

  • RSVPでは送信側のPathがデータ方向へ進み、受信側のResvが逆向きに資源を要求する。各ノードは資源の有無と要求者の権限を別々に判断し、分類器やスケジューラへ状態を実装する。
  • 対応する更新が届かなければ状態は消える。ResvConfもエンドツーエンド品質の保証ではない。「予約済み」には経路、要求、各ホップの判断、実装、更新世代、観測結果が要る。

消えることまで含めて予約である

アプリケーションが終了し、最後の更新が来なくなる。ルータはクリーンアップ・タイマーを待ち、予約状態を削除する。中央の台帳が取消しを命じるわけでも、全経路に一斉削除が成功するわけでもない。

RFC 2205はこれをソフトステートと呼ぶ。PathとResvが状態を作り、同じ意味を持つ後続メッセージが周期的に更新する。期限までに対応する更新がなければ状態は失効する。数回のシグナリング損失には耐えられても、古い要求を無期限の資源権に変えることはない。

したがって「予約済み」は単独の属性ではない。誰が、どのフローについて、どの経路とポリシーの下で、いつまで有効な処理を要求したか、という時刻付きの文である。期限を外した表示は、プロトコルが備えた忘却能力を奪う。

PathとResvは逆方向の証人

RSVPは単方向フローを扱い、受信側が予約を開始する。送信側はデータの進む経路に沿ってPathを周期送信する。RSVP対応ノードは前ホップを含む経路状態を保存する。受信側はその情報を使い、Resvをホップごとに送信側へ戻す。

Pathを捕捉しただけでは、逆方向の要求が全ノードへ届いたとはいえない。Resvを一地点で見ても、その上流が受理したとはいえない。二つは同じ事実の複製ではなく、分散した会話の別々の証拠だ。

マルチキャストでは複数受信者の要求が上流でマージされる。ノードが転送するflowspecは、受信した値をローカルに調整したり、複数枝の要求を統合したりして変わり得る。「Resvあり」だけを残す監査記録では、その変化も範囲も再現できない。

各ホップに資源の門と権限の門がある

Resvを受けたノードでは、アドミッション制御が資源の十分性を、ポリシー制御が要求者の権限を判定する。RFC 2205では両方の成功が必要になる。

その後に初めて、パケット分類器とスケジューラ、またはリンク層の相当機構へ設定が行われる。RSVPはQoSとポリシーのパラメータを運ぶが、その内容を全面的に解釈しない。意味と執行はローカルな制御系に残る。

空き容量は許可ではない。許可は実装ではない。一つの出力インターフェースの実装は全経路の実装ではない。実装状態も、パケットが期待した遅延や損失を経験した証明ではない。この四つを一つの緑色へ畳むと、障害時にどの権限と工程が欠けたのか分からなくなる。

RFC 2208は広域展開を考える際、処理・保存負荷、集約、セキュリティ、ポリシー制御を課題として挙げた。これは1997年の適用上の注意であり、現在の普及率ではない。重要なのは、シグナリングだけで運用制度全体を代替できないという境界である。

成功らしく見えるResvConfの限界

受信側はResvで確認を要求できる。上流のマージ点に同等以上の予約が既にあれば、ノードは要求をそれ以上転送せず、ResvConfを返せる。

しかしRFC 2205は、ResvConfの受信は何も保証しないと明記する。二つの受信者要求がマージされる例では、後から来た要求が確認を受けても、先の要求が対応する送信者まで到達せず失敗する可能性がある。ResvConfの後にResvErrが届くことさえある。

確実に言えるのは、特定ノードがその時点の状態で確認要求を処理したことだけだ。全ホップのアドミッション、全スケジューラの実装、経路の継続、アプリケーションの品質は別の証拠を要する。

確認は無価値なのではない。ローカルな制御イベントを、経路全体の成果証明へ昇格させてはいけない。

経路変更は古い状態を自然に退場させる

PathとResvは冪等である。経路が変わると次のPathが新経路に状態を作り、後続Resvが予約を構成する。使われなくなった旧経路の区間は更新を失い、期限切れになる。

PathTearとResvTearは早期削除に使えるが、配送は保証されない。Tearが失われても、更新のない状態は最終的に消える。完璧な一回の削除命令より、継続意思がなければ消える設計の方が強い。

一方、上流でアドミッションが失敗しても、その下流の予約は残る場合がある。部分的なサービスを維持したり、一時的な経路変動から素早く回復したりするためだ。あるルータの「予約状態あり」と、エンドツーエンドの「予約未成立」は両立する。

記録には失敗地点、残存範囲、更新主体、失効予定を含めなければならない。

Summary Refreshも期限を消さない

PathとResvを毎回すべて再送する負荷に対し、RFC 2961はMESSAGE_ID、特定メッセージのホップ単位確認、バンドル、Summary Refreshを導入した。既知状態なら識別子だけで更新できる。

軽くなるのは表現であって、予約の条件ではない。Summary Refreshは通常更新の同期性を保つ必要がある。受信ノードに該当状態がなければrefresh NACKを返せる。隣接ノードからのACKはシグナリング受信の証拠で、サービス品質の証拠ではない。

要求の世代、ノードごとの更新・削除タイマー、隣接間MESSAGE_IDの世代、設定の版、データ面観測期間は別々に保存すべきだ。一つの「開始日時」に押し込むと、効率化が誤った恒久性へ化ける。

DREPは制御状態の写真を撮る

RFC 2745のDREQ/DREPは、RSVPノードをたどってPathまたは予約状態を集める。各ホップの応答を並べれば、どこで状態が欠け、どこで違うかを調査できる。

ただし応答は分割され、エラーで途中終了し、別の復路を通り、ファイアウォールやタイムアウトに阻まれ得る。完全なDREPであっても、それは通過時点のメモリ状態だ。分類器・スケジューラの実設定や、アプリケーションが経験した遅延・損失・スループットを自動的に測るものではない。

診断は証人を増やす。制御面の証人にデータ面まで語らせないことが、正しい利用法である。

Lixia Zhangを単独の権威にしない

IETF DatatrackerはLixia ZhangをRFC 2205の著者の一人として記録する。UCLAの経歴は、Xerox PARC在籍時にRSVPが着想・開発されたと説明する。RFCはRobert Bradenを編集者、Zhang、Steven Berson、Shai Herzog、Sugih Jaminを著者として挙げ、さらに広い共同研究と標準化コミュニティを認める。

Internet Hall of FameはZhangの功績をRSVPと後年のRSVP-TE利用に結び付ける。これは功績を示す制度的資料であって、現在の運用者数やトラフィック量の測定ではない。元の統合サービス向けRSVPと、後のトラフィックエンジニアリング拡張も同一ではない。

証拠が支えるのは共同設計者、共著者、標準化貢献者という記述である。唯一の発明者、現在の運用者、IETF合意の所有者、実サービスの保証人という記述ではない。人物の権威で運用証拠を代用しないことが、貢献を正確に評価する方法でもある。

「予約済み」を支える七つの記録

一つ目は経路で、送信者、セッション、経路、前ホップ、観測時刻。二つ目は要求で、受信者、Resv内容、filter/flowspec、確認要求、世代。三つ目は権限で、各ホップのアドミッションとポリシー判断である。

四つ目は実装で、分類器・スケジューラの対象、処理結果、設定読戻し。五つ目は更新で、間隔、最終一致、削除期限、Summary Refresh識別子、NACK。六つ目はResvConf/DREPの応答ノード、対象状態、時刻。七つ目は実データ経路と期間を限定したサービス測定だ。

どの記録も他の意味を借りられない。七つを経路と世代で結べば、「特定要求が特定ノードで許可・実装され、現在の更新期間にあり、観測区間でこの結果を得た」と言える。永久の緑印より狭いが、判断に耐える結論である。

情報源