摘要

  • RFC 9894 是 IETF Standards Track 文档，定义 DLEP Diffserv Aware Credit Window 扩展；它把 RFC 9892 的流量分类与 RFC 9893 的信用窗口机制合在一起。
  • 这个扩展不是松散的功能旗标。使用方必须在 Extensions Supported Data Item 中声明它；只有在收到的初始化消息表明对端支持后，参与者才可发送相关 Data Items。
  • 扩展类型为 6。宣告它的实现必须支持 RFC 9892 和 RFC 9893 所定义的相关消息、Data Items、Diffserv 分类与处理，因此 RFC 9892/9893 构成强制依赖闭包。

RFC 9894 将 DLEP 目的地与 DSCP 值映射到共享或专用的逻辑窗口。共享窗口可由多个目的地或分类共同使用，目的地特定窗口则把信用约束收窄到某一目的地；实际映射形状不是 RFC 预先规定的一张通用表。通配符可以扩大匹配范围，甚至涵盖已经存在或后来出现的流，因此 RFC 9894 建议除非确有需要，不要使用通配符。

分类边界也必须明确：如果 Diffserv 分类和以太网流量分类同时匹配，RFC 9892 规定以太网分类优先。这意味着看到 DSCP 匹配并不足以证明最终窗口就是 DSCP 窗口。启用信用窗口后，路由器没有可用信用时不得向调制解调器发送流量；“先发出去、再补记信用”不是这里的安全解释。

接入决策应从对端初始化消息开始：确认 Extension Type 6 已被双方声明，再核对调制解调器宣告的窗口、路由器可实现的队列和组合。路由器支持较少的队列或窗口组合时，应使用明确可支持的子集；若无法形成有效子集，可以重置会话，并通过普通管理机制报告不匹配。沉默地裁剪、继续发送或把未实现的能力展示成已实现，会让控制面与数据面的观察结果失真。

安全上，能够注入调整信用窗口的 DLEP 消息可能把窗口改小或改为不可用，从而造成拒绝服务；RFC 8175 的安全机制适用于此扩展。管理系统应能报告对端声明、采用的子集、被拒绝的映射、重置原因、无信用丢弃或阻塞，以及安全事件；RFC 并未规定某一种 CLI、YANG 模块或遥测阈值。

验证夹具与操作员路径

  1. 用初始化报文夹具分别测试双方均声明 Type 6、仅一方声明、双方均未声明三种情况；检查未获对端声明时相关 Data Items 不会发出。
  2. 用一个调制解调器声明四个 DSCP 窗口、而路由器只实现两个窗口的夹具，验证系统明确选择两个窗口并记录映射，而不是隐式接受四个。
  3. 分别注入共享窗口、目的地特定窗口和通配符匹配；加入新流，确认通配符不会在没有审查的情况下扩大到新流。
  4. 让同一流同时命中 DSCP 与以太网分类，验证以太网分类胜出；耗尽信用后确认路由器不向调制解调器发送该流量。
  5. 以受保护和伪造的窗口调整消息运行测试，确认认证失败、窗口异常和会话重置均进入管理报告。

**操作员决策路径：**先验证对端声明和依赖闭包；再建立 DSCP、目的地和共享窗口的实际表；然后比较宣告形状与本地可实现形状。能完整实现就启用，不能完整实现就选择有记录、可观测的子集；没有安全且可验证的子集就重置。最后以管理报告和数据面检查确认无信用不发送。

来源

以上来源没有建立部署普及率、性能改善测量或统一的 DSCP 到窗口映射，也没有规定统一的队列数量、专有命令、YANG 模块、遥测阈值或回滚计时器。跨行政域传递的 DSCP 标记是否可信仍是运营者的事项，而不是 RFC 9894 已证明的结果。