摘要

  • RFC 3290 把路由器内的 Diffserv 处理表示为相互连接的有向无环图，让管理系统可以描述流量如何被分类、计量、标记、排队、调度或丢弃。
  • 这张图刻意只是信息模型：它帮助配置和监控接口描述行为，却不强制某种实现，也不能证明数据包获得了所承诺的服务。

代码点只是处理路径的起点

数据包首部中的区分服务代码点（DSCP）很容易指出；但单凭这个六位值，很难推断特定路由器接下来会如何处理流量。它可以让行为聚合分类器选择一条分支，之后仍有过滤条件、计量器、标记或丢弃动作、队列和调度等配置决策。

2002 年发布的信息类 RFC《Diffserv 非正式管理模型》把这个差异明确画了出来。RFC 3290 将路由器的流量调节和排队行为描述为由功能性数据通路元素构成的有向无环图。分类器可以把一个流拆成多个流；计量器可以按符合性把数据包送往不同输出；后续动作可以标记、计数、丢弃或复用；队列和调度器则影响发送时机与丢包行为。

因此，解释单位是功能组合。DSCP 可能帮助行为聚合分类器选择分支，但另一分类器也可依据其他数据包字段。计量器能够区分多个符合等级，而各输出又可以连接到不同的标记、排队或丢弃选择。最终处理取决于这些功能及其参数如何连接，不是标签本身。

RFC 3290 还把低层功能组合成流量调节块（TCB）。管理员可以在接口的入口或出口理解这些块，并以串联或并联方式连接。TCB 是管理上的便利抽象——带一个输入和一个或多个输出的“黑盒”——并不意味着各路由器拥有相同的物理架构。

管理地图，不是芯片蓝图

这是 RFC 最重要的限定。该模型是为 SNMP 等配置与管理工具发明的抽象，不旨在约束或规定路由器实现。逻辑队列或计量器不必与某台设备的物理硬件一一对应。

抽象让不同设备可以被共同描述，也留下了问题。RFC 3290 把路由核心视为理想互连；实际交换结构的时延、丢包和过载必须在模型其他位置体现。队列参数描述逻辑行为，并不揭示设备缓冲区如何实现。图可以表达配置意图，却不能独自证明转发路径正确安装了该配置，或拥塞时实际发生了什么。

计量器的表示方式尤其能说明这点。在 Diffserv 架构中，计量器可以被描述为观察流量、再向动作元素发送控制信号；RFC 3290 则把它画成逻辑上的一对多数据通路分叉，每个符合性输出都连接到下一个元素。作者指出，这种描述差异没有改变计量器的功能；但它让处理路径更容易组合，也提醒读者：模型中的连线未必就是实现中的电路。

RFC 3444 后来更清楚地区分了信息模型与针对特定管理协议编码它的数据模型。沿着这个区分阅读 RFC 3290，更能看出它提供的是共享词汇和结构，而不是数据包处理引擎的强制设计。

这张图能证明什么，不能证明什么

这张图有助于检查预期的分类、调节和排队关系，也能把参数、计数器和管理对象放在共同框架下。它使策略组合可以被审阅：计量器的“超出配置”分支，只有在知道后续元素以及最终队列或丢弃行为时才有实际含义。

但已配置的图只是证据链的一层。要确认实际服务，仍需设备配置回读、实现行为、分支计数器或数据包观察，以及相关服务边界上的测量。DSCP 不是时延承诺；PHB 名称不是队列深度测量；管理模型也不是调度器在负载下按预期工作的证明。

因此，RFC 3290 至今仍有用，却不应被误当成通用路由器设计。它提供了描述标记与转发之间处理逻辑的方法；既没有把这些逻辑折叠进标记本身，也没有把意图图示变成已交付性能的证据。

来源