要約

  • RFC 9894はIETF Standards Track文書であり、宛先固有および共有のフロー制御を行うDLEP Diffserv Aware Credit Window拡張を定義する。
  • この拡張は単独の機能フラグではない。RFC 9892のトラフィック分類とRFC 9893のクレジット・ウィンドウ機構を組み合わせるため、両RFCの関連メッセージ、Data Items、処理を含む依存関係が必須となる。
  • 拡張タイプは6である。Extensions Supported Data Itemで宣言し、受信した初期化メッセージで相手の対応を確認するまで、関連Data Itemsを送信してはならない。

RFC 9894はDLEPの宛先とDSCP値を、共有または専用の論理ウィンドウへ対応付ける。共有ウィンドウは複数の宛先や分類で利用でき、宛先固有ウィンドウは一つの宛先に対して信用を制限する。RFCは普遍的なDSCP対ウィンドウ表を定めていない。ワイルドカードは既存のフローだけでなく、後から現れるフローまで意図せず含める可能性があるため、必要な場合を除いて避けることが推奨される。

分類が重なる場合も見落とせない。Diffserv分類とEthernetトラフィック分類の双方が一致したなら、RFC 9892ではEthernet分類が優先される。したがってDSCPが一致した事実だけから、最終的にDSCP用ウィンドウが選ばれたとは判断できない。クレジット・ウィンドウを使用中に利用可能なクレジットがなければ、ルーターはモデムへトラフィックを送信してはならない。

接続時には、まず双方がExtension Type 6を通知したかを確認する。次に、モデムが通知するウィンドウの組合せと、ルーターが実装するキューおよび信用の組合せを照合する。ルーターが少ない組合せしか扱えない場合は、実装済みの部分集合を明示的に使うことができる。妥当な部分集合を形成できない場合はセッションをリセットし、通常の管理機構で不一致を報告する。静かな切り捨ては、制御面の表示とデータ面の動作を分離させる。

信用ウィンドウを変更するDLEPメッセージを注入されると、ウィンドウを縮小または利用不能にされ、サービス拒否につながる可能性がある。この拡張にはRFC 8175のセキュリティ機構が適用される。管理報告では、相手の通知、採用した部分集合、拒否した対応、リセット理由、クレジット不足による停止、分類の結果とセキュリティ異常を区別して示すべきである。ただしRFCは特定のCLI、YANGモジュール、しきい値やロールバック時間を定めていない。

検証フィクスチャーと運用者の判断経路

  1. 双方がType 6を通知する場合、一方だけの場合、双方が通知しない場合の初期化メッセージを用意し、相手の対応がないと関連Data Itemsを送信しないことを確認する。
  2. モデムが4つのDSCPウィンドウを通知し、ルーターが2つだけ実装するフィクスチャーで、2つの対応可能な組合せを記録して採用することを確認する。
  3. 共有、宛先固有、ワイルドカードの各範囲に新しいフローを加え、ワイルドカードが未審査の新規フローまで拡大しないか検証する。
  4. 同じフローにDSCP分類とEthernet分類を同時に一致させ、Ethernetが優先されること、クレジットを使い切った後に送信しないことを確認する。
  5. 保護された変更メッセージと偽造メッセージを試し、認証失敗、異常な変更、リセットが管理報告に現れることを確認する。

**運用者の判断経路：**相手の通知とRFC 9892/9893の依存関係を確認し、実際のDSCP、宛先、共有ウィンドウの表を作る。通知された形状と実装可能な形状を比較し、完全に実装できれば有効化する。できなければ、記録と観測が可能な部分集合だけを採用し、安全に検証できる部分集合がなければリセットする。最後に、クレジット不足時の送信禁止をデータ面で確認する。

出典

これらの出典は、導入普及率、測定済み性能向上、または一律のDSCP対ウィンドウ対応を示していない。統一されたキュー数、専用CLI、YANGモジュール、テレメトリーしきい値、ロールバック・タイマーも定義されていない。行政ドメインをまたぐDSCPマーキングを信頼できるかは運用上の懸念であり、RFC 9894が確立した結果ではない。