要約

  • RFC 3181 は、新規フローの Preemption Priority と、すでに受け入れられた予約の Defending Priority を比較した。新規フローが入ると、最初の値は役目を終え、自らの防御優先度が次の到着と競った。
  • マルチキャスト予約の統合では、どの優先度を残すかが別の判断になった。最大 QoS に寄与した受信者の優先度を使う方法は歪みを抑えたが、単純な最大値はただ乗りを招き、異種統合の拒否は一受信者に全体を止める力を与えた。
  • ポリシー要素、局所判断、プリエンプションエラーは、経路全体の予約、トラフィック制御の実変更、パケット処理、アプリケーション継続を証明しなかった。

到着順より順位を選ぶ場面

RFC 3181 は 2001 年 10 月に Standards Track として公開され、RFC 2751 を廃止扱いにした。RSVP のポリシーデータにおけるタイプ値の誤りを直し、RSVP や COPS のようなシグナル型受付制御で使う Signaled Preemption Priority Policy Element を定めた。これは規格上の位置を示すが、特定の実装や運用を示さない。

仕組みが必要になるのは、全要求を収容できないときだった。容量だけで判断すれば、空きがなくなるまで順に入るため、先着順が事実上の規則になる。ポリシー型受付制御では相対順位を加えられた。低い新規要求を断るだけでなく、すでに入った低順位予約を退かせ、後発の高順位要求を受け入れることもできた。

容量が増えるわけではない。誰が不足を負担するかが変わる。新規フローの成功は、別のフローの喪失と同じ出来事だった。勝者だけを数える画面は、資源増加と損失移転を取り違える。

要素は単純、ステートレス、軽量で、ノード内の Local Decision Point でも扱えるように設計された。ステートレスとは、要素の解釈に過去の履歴や外部情報を必要としないという意味である。運用上の結果まで履歴不要という意味ではない。誰が入り、誰が退き、容量がどうだったかは別に残さねばならない。

入場券と防衛権は別の値だった

Preemption Priority は入ろうとするフローの順位で、すでに入ったフローの Defending Priority と比べられた。大きな数ほど、適用中のポリシー文脈では高順位だった。

一度受け入れられると、そのフロー自身のプリエンプション優先度は無関係になった。以後は防御優先度が、将来の新規要求に対して働いた。つまり同じ予約が、入場時と滞在時に異なる物差しを持つ。単一の「優先度」欄は、いつ誰と比べる値かを失う。

同じフローでは、入場用の値を防御用の値以下にする必要があった。差を広げれば安定性を加えられる。中程度の入場順位では他者を容易に追い出せないが、いったん入れば高い防御値で中程度の後発要求に耐えられる。先着依存と頻繁な入れ替わりの間を調整する仕組みだった。

それでも永住権ではない。さらに高い到着には敗れうる。容量や設定も変わり、別ノードは別の対応表を持ちうる。値はポリシー内の相対順位であって、組織や用途を横断する普遍的な価値順位ではなかった。

「時刻 A に入った」は過去の事実である。「時刻 B にまだ守られる」は、その時点の競争である。古い入場記録は、新しい競争相手と容量を観測していない。

ポリシーは複数の手を渡った

Policy Decision Point は複数の規則を優先基準へ縮約できた。中央決定点を持たないノードでは、Local Decision Point が要素を解釈、転送、統合した。Policy Enforcement Point は、結果をトラフィック制御と容量受付に結び付けた。

これは一人の万能管理者ではなく、証拠の受け渡しである。ポリシー権威が順位を作り、局所点が符号化された統合戦略を使い、執行点がノードの状態を変える。RSVP が運び、COPS が外部判断を支えられる。どの一段も、経路全体やアプリケーション結果を単独では見ていない。

RFC 2750 は RSVP のポリシー制御コンテナを、RFC 2748 と 2749 は COPS と COPS-RSVP の関係を説明する。インターフェースが明らかになっても、結果は保証されない。整形式のオブジェクトでも、元の規則が誤り、対応表が古く、後続ノードが異なる解釈をする可能性は残る。

セキュリティは、包含する Policy Data の完全性と、信頼された一つの領域内で使う前提に依存した。封筒は値の無断変更を検出できる。しかし、規則の正当性、設定の鮮度、執行後のサービスまでは保証しない。

統合すると他者の順位を借りられた

RSVP では予約が合流する。RFC の例では、高 QoS・低優先度の F1 と、低 QoS・高優先度の F2 が統合される。結果は高 QoS を必要とするが、どの順位を持つべきかは自明でない。

高い順位を選べば、資源を多く使う F1 が F2 の権限を借り、ただ乗りする。低い順位を選べば、本来高順位の F2 もまとめて追い出される。文書は、ただ乗りとサービス拒否を表裏として扱った。一方の不当な利益が、他方の正当な機会を奪う。

第一の戦略は、統合 QoS に実際に寄与したフローの要素だけを参加させ、その中の最高順位を選んだ。資源要求を決める者と順位を決める者を近づけるため、推奨された。歪みを減らすが、悪用が不可能になるわけではない。

第二の戦略は全要素から最高順位を取った。実装は単純だが、QoS と順位を切り離し、小さな要求の高順位を高価な予約全体へ貸せるため、推奨されなかった。

第三の戦略は QoS が異種ならエラーにした。ツリー全体で同質性を調整し強制できる場合には推奨できた。一方、調整がなければ、一人の不適合な受信者が他の全受信者を失敗させられる。

異なる戦略を情報損失なしに圧縮する中立手法は知られていなかった。さらに完全性で守られた Policy Data は、書き換えると封筒が無効になるため、局所点が変更すべきではなかった。最終数値だけでなく、参加者、戦略、保護境界が意味を構成した。

エラーは競争を伝え、サービスを結論しなかった

PREEMPTION は、以前受け入れられたフローが退かされたことを示した。HETEROGENEOUS は異種統合を示した。前者では、勝者の要素のコピーが、敗者の要素を作った決定点へ戻された。両方の順位を知った決定点は、より高い値で復帰を試みられた。

この返送は競争を可視化する。しかし敗者のアプリケーションが通知を受けたこと、送信を止めたこと、資源を解放したこと、正常に回復したことは示さない。勝者が全ホップに予約を置けたことも示さない。局所受付と経路全体は異なる範囲である。

復帰は振動を起こしうる。RFC は、プリエンプション優先度、他予約を殺す要求、RSVP の blockade state によって、退去、復帰、再退去が繰り返される可能性を述べた。各復帰を成功として数えれば、不安定さを報奨してしまう。滞在時間と利用者に見える中断を測る必要がある。

異種エラーも局所定義に対する正確な答えにすぎない。別経路、低い QoS、アプリケーション側の代替策まで否定しない。

登録表と後続規格は導入実績ではない

RFC はポリシー要素のタイプ値を割り当てた。現在の IANA RSVP パラメータ表は調整された番号を示すが、ノードが認識したこと、決定点が発行したこと、執行点が動作したこと、利用者が有益なサービスを受けたことは示さない。

後の RSVP-TE 文書は関連するプリエンプションを扱い、RFC 6401 は受付優先度を拡張した。設計史の文脈にはなるが、RFC 3181 の導入証拠ではなく、後の挙動を 2001 年の要素に書き戻せない。

Standards Track もコードの普及率ではない。資料は現在の事業者、トラフィッククラス、緊急通話、容量節約、受付率、アプリケーション成果を何も特定していない。

検証可能な台帳は敗者を消さない

監査記録は、フローと予約の識別、QoS、ポリシー出所、完全性文脈、二つの値から始まる。解釈または統合したノードと役割、戦略、判断時の容量と競合予約、受付または退去を保存する。

統合では、どの受信者が QoS に寄与し、どの要素が順位に参加したかを残す。プリエンプションでは、勝者の到着、敗者の予約、返送エラー、トラフィック制御の撤去、復帰試行を結ぶ。現在状態で過去の回を上書きしない。

その後に経路予約、パケット処理、アプリケーション反応を別証拠として加える。順位は不足下の判断材料であり、資源を生み、執行を証明し、サービスを代弁するものではない。

二つの値が残した歴史的教訓は簡潔である。扉を開ける権限と、扉を開けたままにする権限は同じとは限らない。責任ある記録は、時刻、競争者、決定者、執行者、結果を区別する。

出典と限界

状態、二つの優先度、役割、統合戦略、エラー、登録、安全範囲は、RFC 3181 本文、RFC Editor 情報、HTML 版、IETF 履歴、errata 検索に基づく。版の比較は、廃止扱いの RFC 2751 本文と情報ページに限る。

隣接インターフェースは RSVP、RSVP ポリシー制御拡張、COPS、COPS の RSVP 利用で確認した。後の文脈は RSVP-TE、RSVP 受付優先度、IANA RSVP パラメータ表で境界を定めた。

順位、執行、観測結果を分ける分析は、Lu Heng の実行コードの優先性、現実の層、最小初期仕様に関する論考から示唆を受けた。17 件の資料は上海時間 2026 年 10 月 2 日に凍結した。

これらは仕様と文脈を証明するが、導入や成果を証明しない。現行実装、ベンダー、事業者、フロー、アプリケーション、事故、攻撃、容量節約、パケット処理、サービス結果は特定されていない。数値は適用ポリシー内の相対順位であり、普遍的な社会・商業順位ではない。証拠連鎖は Sofia Ren の編集分析であり、RFC 著者、IETF、IANA、Lu Heng の主張ではない。