要約

  • RFC 9892はStandards TrackのIETF仕様であり、拡張可能なDLEP Traffic Classification Data Itemと、初期のDiffservおよびEthernet Sub-Data Itemを定義する。
  • TIDはモデム内でローカルなTraffic Classification Identifierで、分類情報の集合を名付ける。FIDは各Sub-Data Item内でフローを示す。したがってTIDとFIDは装置間でグローバルに意味を持つ名前ではない。
  • 宛先との関連付けは、そのデータを消費する拡張が与える。TIDの運用上の意味も拡張固有である。TIDを受信すると、ルーターは関連する分類情報を初期化または置換し、必要に応じてデータプレーン状態を更新する。

何が一致し、何が検証されるか

Diffserv Sub-Data ItemはDSCP値をグループ化する。同一のTraffic Classification Data Item内でDS Field値が重複すればエラーである。カウントがゼロのDSCP項目は、他の項目で対応付けられていないDSCPへのワイルドカードになる。Ethernet Sub-Data ItemはVLAN/PCP値をグループ化する。明示的なVLANが先に一致し、PCPカウントがゼロの項目がデフォルト一致を提供する。同一Data Item内で優先度が重複する場合もエラーである。両方の分類器が一致するとEthernet VID/PCPがDiffserv DSCPより優先され、そのEthernet側のTIDを使う。

これらの形式だけでは何も実行しない。別途ネゴシエートされたDLEP拡張がデータを要求し、解釈しなければならない。RFC 9893のクレジット・ウィンドウによるフロー制御は例であって、RFC 9892の要求事項ではない。RFC 9892はスケジューラー、キューの重み、アドミッション・ポリシー、クレジット・ウィンドウ・アルゴリズムを定義しない。将来の5タプル分類も拡張性の例であり、同RFCの定義済み分類器ではない。

検証フィクスチャ

実装検証には、再現可能な四つの入力を使える。第一に一つのDSCPだけを対応付け、期待するFIDを確認する。第二にカウントゼロを送り、未対応DSCPがデフォルトTIDになることを確認する。第三に一つのData Item内でDS FieldまたはPCPを重複させ、エラーとして拒否されることを確認する。第四に同じパケットがEthernet VID/PCPとDSCPの双方に一致するようにし、記録されたTIDがEthernet側であることを確認する。その後、同じTIDの新しい分類情報を送り、旧マッピングが黙って統合されず置換されることを検査する。監査にはメッセージ方向、Data Itemのダイジェスト、TID/FID、検証結果、ネゴシエート済み拡張、適用状態を残す。

運用者の判断経路

最初にDLEPセッションとデータを消費する拡張のネゴシエーションを確認する。次に送信元、TID/FIDのローカルな範囲、宛先関連付けを確認する。続いて重複、ワイルドカード、Ethernet優先順位を検証する。失敗した更新は隔離し、キュー方針として扱わない。成功した場合は置換前後を記録し、消費拡張に実際のキュー処理を照会する。最後に該当するDLEPトランスポートまたはリンク層のセキュリティを確認する。これは該当区間を保護するが、RFC 9892がエンドツーエンドの信頼を保証するという意味ではない。

悪意あるピアが分類からキューへの対応を変えれば、サービスクラスに遅延、輻輳、損失を生じさせ得る。RFC 9892はDLEPのトランスポートおよびリンク層セキュリティを参照するが、新しい信頼モデルを定義しない。また、この資料群は行政ドメインをまたぐDSCPの信頼性を確立していない。

出典