要約

  • RFC 2210では、SENDER_TSPECは送信者の宣言、ADSPECは下流方向に合成される経路要約、FLOWSPECは上流方向へ進む受信者の要求であり、それぞれ証明する段階が違う。
  • 一般情報のbreak bitは、少なくとも1つの要素がRSVP/Integrated Servicesを支えないことを示す。立った場合、他のADSPECパラメーターは経路全体の証拠として信頼できない。
  • サービス固有のbreak bitは、RSVPを理解する要素のどこかが、その特定サービスを提供できないことを示す。
  • PATH_MTUは経路と予約の合流で小さい値へ縮小するが、送信者の元の最大パケット宣言は書き換えられない。対象外の大きなパケットはbest effort扱いになり得る。
  • 広告、予約、合成値、遅延限界の計算は、経路不変、全要素での許可、トラフィック適合、実測品質、アプリケーション成功を一括して証明しない。

最初に確認すべきは値の有効条件だった

ADSPECの数値は、単独で見ると強い確証に見える。

パス上のIntegrated Services対応ホップ数、利用可能性を表す帯域、最小遅延、最小MTU。Guaranteed serviceなら、遅延限界の計算に使う誤差項も含まれる。受信者はそれらをもとに、どのサービスをどのパラメーターで要求するか判断できた。

だがRFC 2210は、値の利用より前に、要約の連続性を検査させた。

PATHメッセージが下流へ進むと、参加可能な各要素はローカル情報を合成する。要素ごとの記録を追加しないため、ADSPECは経路が長くなってもほぼ一定の大きさに保たれる。

その圧縮は、途中の詳細を捨てることで成立する。もし参加できない要素が存在しても、その事実まで捨てれば、受信者は連続した計算と誤認する。一般break bitは、まさにこの欠落を残すためのものだった。

ビットが立ったとき、RFCは残りのパラメーターをunreliableと扱う。個々のルーターが嘘をついたという意味ではない。経路全体を代表するために必要な計算の鎖が切れたという意味である。

後段の対応ルーターは前段の欠落を消せない

break bitは累積的な否定である。

経路後半のルーターがRSVPもGuaranteed serviceも完全に実装していても、すでに通過した非対応要素を対応済みに変えることはできない。後段は自分の情報を正しく処理できるが、過去の断絶を修復する権限はない。

したがって、ビットは後続要素によって単純に戻されない。

この性質は、最終ホップの状態だけを表示する監視とは異なる。ADSPECは「現在の要素が何を知るか」だけでなく、「ここまでの経路にどの種類の欠落があったか」を保持する。

数値が経路の要約なら、break bitは要約工程の来歴である。

同じPATH/RESV交換に異なる著者がいた

RFC 2210が扱う主要な3オブジェクトには、それぞれ別の著者がいる。

SENDER_TSPECは送信者が作る。トークンバケット型のトラフィック記述と最大パケットサイズMを含み、PATHで下流へ運ばれる。経路要素は、送信者の元の宣言を変更しない。

ADSPECは経路が作る。対応要素がローカル情報を合成し、下流へ進む。送信者の意図でも受信者の要求でもない。

FLOWSPECは受信者が作る。選択したサービスと予約パラメーターを示し、RESVで上流へ進む。複数の受信者や分岐があれば、途中でマージされることもある。

つまり、宣言、広告、要求が同じ信令系に載っている。

これらを一つの「予約情報」と呼ぶだけでは、どこから来た主張か分からなくなる。TSpecがあることは実トラフィックの適合を示さない。ADSPECがあることは資源の確保を示さない。FLOWSPECがあることはサービスの提供結果を示さない。

cleanな広告にも時刻と経路がある

一般break bitが立っていないADSPECは無意味ではない。対応の断絶がその広告で記録されなかったという、限定された肯定的証拠である。

しかし、それは将来の経路を固定しない。

PATHが通過した後でルーティングが変われば、データパケットが別の要素を通る可能性がある。ローカルな資源状況や方針も変わり得る。RESVを受け取った要素は、その時点で改めて admission control を行う。

従って、cleanなADSPECは「この広告が構成された経路と時点」に相対的である。

監視画面がビットだけを保持し、経路変更や更新時刻を失えば、過去には正しかった信号を現在の保証として使ってしまう。信号が偽になるのではない。信号を適用する対象が変わる。

PATH_MTUが示す複数の上限

最大パケットサイズは、各層を混ぜない設計を具体的に示す。

送信者TSpecのMは、送信者が生成し得る最大サイズである。一方、ADSPECのPATH_MTUは、経路上でより小さいローカルMTUに出会うたびに縮小する。受信者は複数送信者が関わる場合、該当する最小値を考慮する。

予約が合流する点でも、小さい受信者側上限が上流へ残る。送信者に届くマージ結果は、その予約分岐群で共通に受け入れられる上限を表す。

それでも元のSENDER_TSPECは書き換えられない。

送信能力、経路の対象範囲、受信者群の共通上限は、別々の事実だからである。値を一つに正規化すれば、誰が何を表明したかが失われる。

対象上限を超えるパケットは、best effortだけを受ける可能性がある。予約が存在しても、あらゆるサイズのパケットに同じ扱いを与えるわけではない。

受信者のFLOWSPECは判断の結果だった

受信者はADSPECを受け取り、そのまま返送するのではない。

アプリケーション要件、送信者TSpec、経路広告、ローカル方針を考え、FLOWSPECを構築する。Guaranteed serviceでは、合成パラメーターとトラフィック記述から、目標とする遅延条件に合う予約を計算できる。Controlled-Loadでは、そのサービス定義に応じた要求を作る。

ここで広告は要求へ変換される。

上流の各RSVP対応要素は、TSpecとFLOWSPECを該当するトラフィック制御サービスへ渡す。方針とadmission controlはまだ残っている。正しい形式の要求でも拒否され得る。

さらに、複数の予約はマージされる。上流で見えるFLOWSPECが、特定受信者の最初の要求と同一とは限らない。マージ結果は、その地点で形成された制御状態の証拠であり、データパケットがすでに処理された証拠ではない。

一般breakとサービスbreakの違い

一般情報フラグメントのbreak bitは、RSVP/Integrated Servicesの基盤に対する断絶を示す。そのため、他の一般パラメーターを含むADSPEC全体のエンドツーエンド解釈に影響する。

サービス固有break bitは、より限定された問いに答える。

ある要素がRSVPを理解していても、Guaranteed serviceを実装していない場合がある。そのとき一般的な参加能力は残るが、Guaranteedの連続性は成立しない。サービス固有ビットは、この違いを潰さない。

「RSVP対応」と「すべてのQoSサービス対応」は同義ではない。また、「特定サービス非対応」と「信令基盤全体の不在」も同義ではない。

複数のbreak bitは、障害表示を増やすためではなく、どの前提が失われたかを正確に示すためにある。

Controlled-LoadとGuaranteedは別のサービスだった

Controlled-Load serviceは、適合するフローに対し、負荷のないbest-effortネットワークに近いサービスを与えることを目指した。admission controlは必要だが、特定の遅延値や損失率を数値保証するサービスではない。

従って、そのADSPECブロックにはGuaranteedのような合成誤差項は要求されない。ただし、経路要素がControlled-Loadを提供できない場合のbreak表示は必要である。

Guaranteed serviceは異なる。

Ctot、Dtot、Csum、Dsumを経路上で合成し、トラフィックパラメーターと組み合わせてキューイング遅延の上限を導く。

計算結果は、条件付きだからこそ厳密である。フローが宣言に適合し、サービスが経路で支えられ、予約が許可され、パラメーターが現在の経路に適用できる必要がある。上限はアプリケーションの処理完了を証明しない。

セットアッププロトコルとサービスの分離

RSVPは、サービスオブジェクトを運びながら、そのすべての内部意味を自分で所有しなくてよい。サービスモジュールがパラメーターを解釈し、セットアップ側は状態の伝搬と維持を扱う。

RFC 2205はRSVPのPATH/RESVとsoft stateを定義する。RFC 2211と2212は個別サービスを定義する。RFC 2215はローカル値と合成値を整理し、RFC 2216は単一ネットワーク要素のサービスという単位を示す。RFC 2210は、その接続点にある。

この分離は、責任範囲も分ける。

信令が成功しても、サービス動作の観測にはならない。サービスが局所的に存在しても、全経路の対応にはならない。ポリシーと認証も、正しい形式のオブジェクトだけでは完了しない。

規格の意味と導入実績を混ぜない

RFC 2210は1997年9月にProposed Standardとして公表された。そのテキストは、オブジェクト、方向、合成、breakの意味を確認する一次資料である。

一方、現在の導入率、特定製品の実装品質、事業者の性能、商用上の成功は、この資料からは分からない。

歴史的に重要なのは、Internetが必ずこの設計に従ったという物語ではない。精密な制御面であっても、自分が証明できない範囲を1ビットで明示したことにある。