要約

  • RFC 9895はStandards Track文書であり、共有および宛先固有のフロー制御のためのDLEP IEEE 802.1Q Aware Credit Window拡張を定義する。
  • Diffserv分類とEthernet分類の双方がフローに一致する場合、RFC 9892によりEthernet分類が優先される。したがって信用ウィンドウを決めるのはEthernet側である。
  • Extension Typeは5。利用にはExtensions Supportedによる宣言が必要で、広告する実装はRFC 9892とRFC 9893の関連メッセージ、Data Item、Ethernet分類および処理をすべて支えなければならない。

RFC 9895はRFC 9892のトラフィック分類とRFC 9893のクレジット制御を組み合わせ、論理ウィンドウをDLEPのdestination、VLAN識別子、IEEE 802.1Q PCPに関連付ける。ウィンドウは共有型にも宛先固有型にもできる。モデムはPCPからウィンドウへの設定をサポートすべきで、VLANごとのPCPマッピングもサポートしてよい。PCPなしでVLANを扱う場合は、VLANからウィンドウへのマッピングを設定可能にすべきである。これは特定のキュー数や、全実装に共通する設計を規定するものではない。

値の境界は運用上の細部ではなく分類結果そのものに関わる。VID 0はVIDを無視することを意味する。0xFFFFは予約値であり、分類に使用できるVIDは0x0001から0xFFFEまでである。PCPまたはVIDのワイルドカードは一致範囲を広げ、予期しないフローや後から現れるフローまで捕捉し得るため、RFC 9895は明確な必要性がある場合に限って使うことを推奨する。広告されたウィンドウがルーターの対応数を超えた場合、ルーターは対応可能なサブセットを使うか、セッションをリセットしてよく、不一致は通常の管理機構で報告する。ウィンドウ使用中、十分なクレジットなしにトラフィックを送ってはならない。

検証用の具体的なfixtureは、少なくとも次の通りである。第一に、DSCP、正当なVID、PCPのすべてが一致するパケットを送り、Ethernet側のウィンドウに計上されることを確認する。第二に、VLANタグを固定したままDSCPだけを変え、Ethernet優先順位が維持されることを確認する。第三にVID 0と有効なPCPを組み合わせ、VIDが無視されることを確認する。第四に0xFFFF、0x0001、0xFFFEを個別に試し、予約値と分類可能範囲の処理を記録する。さらに、未タグフロー、PCP/VIDワイルドカード、対応数を超える広告ウィンドウ、Extensions Supported、RFC 9892/9893の全メッセージとData Item、クレジット不足時の非送信を確認する。

オペレーターの判断順序は明確にできる。まず相手がExtension Type 5を宣言したか確認する。次にRFC 9892/9893の依存関係と、自装置が処理できるウィンドウ数を確認する。その後、共有型か宛先固有型か、PCPマッピング、VLANごとのPCPマッピング、またはVLAN-onlyマッピングを定義する。VID 0、予約値、使用可能範囲、ワイルドカード範囲を固定し、fixtureで再検証する。説明できない挙動が残るなら、拡張を有効化せず、検証済みサブセットを使うかセッションをリセットする。

出典