要約

  • RFC 9892 の TID は分類集合、FID はその中のフローを表す。値の意味は発行したモデムに限られ、同じ数字を別装置や別セッションの永続識別子として扱えない。
  • ルーターは集合全体を検証して置き換え、明示規則、ワイルドカード、Ethernet 優先を解決する。利用法は交渉済み拡張が与え、実際の処理はデータプレーンで改めて観測する。

更新メッセージの後も、監視画面には古い FID が残っていた。新しい規則は追加されたように見え、同じパケットが二つのフローへ分類された。ところがプロトコル上、更新は追加ではなく集合の置換だった。

RFC 9892 は Dynamic Link Exchange Protocol に Traffic Classification Data Item を導入する。モデムは TID の下に分類規則をまとめ、各 Sub-Data Item の FID でフローを表す。最初の形式は Diffserv の DSCP と Ethernet の VLAN/PCP を扱う。

この構造は用途から独立している。分類情報を何に使うかは拡張機能ごとに決まる。したがって、FID が得られた事実は、キューを作ったことも、信用窓を割り当てたことも、パケットがリンクを越えたことも示さない。

ローカルな番号に永続性を足さない

TID と FID はモデムローカルである。二台のモデムが同じ値を使っても同じ対象ではない。装置交換後に番号が再利用されれば、モデムとセッションを捨てたデータベースは過去と現在を誤って結合する。

RFC 8175 の DLEP は、モデムと接続ルーターの間にローカルなセッションを作る。拡張はセッション初期化時に交渉され、複数接続は別セッションになる。無線上の信号方式はモデム実装の領域であり、DLEP が規定するものではない。

記録のキーには、モデム、ルーター、セッション、受信メッセージ、時刻、分類集合の版、利用拡張が必要になる。TID/FID だけを外部 API に公開すれば、狭いローカル参照が全社的なオブジェクトのように振る舞い始める。

IANA DLEP Parameters は Traffic Classification を Data Item type 29 として登録し、Diffserv と Ethernet の Sub-Data Item type を管理する。登録は符号の衝突を防ぐ。実装、交渉、現行構成、パケット処理を観測するわけではない。

Heng Lu の動くコードを第一の証拠とする原則に従えば、登録と仕様は可能性を整え、実行状態が効果を示す。両者を一つの「対応済み」にまとめないことが重要である。

置換と履歴を同時に守る

モデムは Session Initialization Response で分類を送り、Session Update で新規または更新済みの集合を通知できる。既存 TID が見つかれば、ルーターは対応情報を置き換え、関連するデータプレーン状態を必要に応じて更新する。

運用上の現在値は一つの完全な集合である。一方、監査には前の集合、置換時刻、受信メッセージが要る。現在値へ古い要素を累積すれば存在しない規則を作り、上書きだけなら変化の理由を失う。

Sub-Data Item の順序には意味がない。到着順や FID の大小を暗黙の優先順位にしてはいけない。優先は明示された一致規則から決まる。

ゼロの意味も階層で変わる。Sub-Data Item がゼロの分類集合は、その TID に何も一致させない。DSCP がゼロ件の Diffserv 項目は、明示 FID に捕捉されない DSCP のワイルドカードである。Ethernet の VID ゼロは VLAN を無視する。どれも単純な「既定値」ではない。

最小の初期仕様と将来のローカル判断という Heng Lu の考え方は、この境界を説明する。共通層は形式、検証、衝突、優先を定める。具体的な処理と損失責任はローカルな実装者に残る。

検証は断片ではなく集合全体で行う

Diffserv Sub-Data Item は FID と DSCP 群を結ぶ。ルーターは利用前に検証し、同じ DS Field が Traffic Classification Data Item 全体で一度だけ現れることを確認する。別々の Sub-Data Item に一つずつ現れても重複であり、集合はエラーになる。

RFC 2474 は classifier を、定義済み規則に従いヘッダー内容でパケットを選ぶ主体とする。DSCP は各ノードで per-hop behavior に写像され、キュー制御などで実装される。選択規則とノード動作とサービス結果は別の層である。

RFC 2475 の Diffserv アーキテクチャでは、分類器とトラフィックコンディショナーが管理ドメインと境界に置かれる。マークが同じでも、各ドメインの方針と実装が同じとは限らない。

Ethernet Sub-Data Item は VLAN と PCP を使う。明示 VLAN は既定写像より先に照合される。パケットが Diffserv と Ethernet の両方に一致した場合、RFC 9892 は Ethernet 情報を優先する。

監査記録は候補を捨ててはいけない。DSCP、VLAN/PCP、明示かワイルドカードか、集合全体の検証結果、採用した優先規則を保存して初めて、最終 FID を説明できる。DSCP 一件だけでは入力は示せても決定は示せない。

拡張が初めて用途を与える

RFC 9892 の形式は、それを要求する拡張でのみ用いられる。RFC 9894 の Diffserv Aware Credit Window は一例である。参加者は初期化時に対応を宣言し、利用を示す実装は RFC 9892 と RFC 9893 のメッセージ、項目、処理を実装しなければならない。

RFC 9893 は Credit Window Association Data Item を別に定義し、TID を DLEP destination と信用窓へ結ぶ。Association にない TID はその仕組みで使われず、異なる窓の TID が重なればエラーになる。

既存の RFC 9893 記事は、信用が送信許可であって配送証明ではない点を扱った。本稿はその前段を扱う。どの分類集合が現行で、どの規則が勝ち、どの拡張が FID を制御入力にしたかという問題である。

その後にも、状態の導入、キューや窓への割当、個別パケットの受入れ、リンク送信、遠端受信、アプリケーション結果が残る。一段の成功を次へ自動継承させてはいけない。

認証済みの分類でも効果は未証明

RFC 9892 は、DLEP peer を装う者が別の分類を注入し、キュー写像を変えて遅延、輻輳、損失を起こし得ると警告する。RFC 8175 が挙げるトランスポート層やレイヤー 2 の保護は、送信者偽装を抑える。

ただし、認証は「誰が送ったか」を証明するだけである。方針の正しさ、ルーターへの導入、ローカル構成との整合、パケットの結果は別に確認する必要がある。

証拠列には peer identity、session、message hash、validation result を置き、その後へ selected FID、consumer extension、destination、intended state、observed state、counter、link transmission、remote outcome を接続する。

Heng Lu の現実の層と象徴権力が示すように、一語が観測していない行為を吸収すると権力になる。「分類済み」を「受信・検証・導入・処理・配送済み」と読めば、ローカル参照がサービス全体の証明へ膨張する。

分類器はフローに名前を与えた。その名前が何を証明しないかを残すことが、運用上の信頼性である。

情報源