摘要

  • RFC 5127 的处理聚合允许多个 Diffserv 服务类共享一种转发处理，并保留不同 DSCP。
  • 服务类描述端到端应用要求；处理聚合只描述某个网段如何本地转发。
  • 聚合必须满足成员中最严格的丢包、时延与抖动要求，不能采用平均值冲淡责任。
  • 成员还应具有相近的流量特征，否则相同业务标签可能掩盖完全不同的队列压力。
  • 聚合不得销毁原始端到端服务类身份，因为下一个管理域可以采取不同映射。
  • 推荐做法是不改写 DSCP，而由分类器把多个值送入同一队列；若采用本地标记，离域时必须恢复。
  • 每个成员类仍需独立 conditioning、准入或 policing，聚合总量控制只是另一层检查。
  • 四种处理聚合只是一个实例，不是实现的最低数量、最高数量或合规证书。
  • Real-Time 聚合成立的前提是边缘已对各类流量执行可约束的准入，队列名称不能创造这个前提。
  • 安全聚合取决于链路速率、利用率、队列深度、调度器、包长组合、发送速率与故障后的绕行负载。
  • MPLS Traffic Class 和 LSP 记录本地域编码，不证明队列已正确安装或数据包获得预期行为。
  • 管理层必须分别保存原始类别、授权、计量、准入、聚合预算、安装状态、跨域恢复、观测性能与应用结果。

示例图为何最容易变成权力

四行表格很容易被产品化。采购规范要求四个队列，设备界面显示四种颜色，审计人员核对四个名称。完成这些动作之后，组织可能相信 RFC 5127 已经“落地”。

但 RFC 本身说得更窄。一个域可以使用更多或更少的处理聚合，也可以只支持部分服务类。未支持类如何处置，由本地政策和客户协议决定。四不是下限，也不是上限。

这正是最小初始规范的意义：标准给出足够互操作和分析的结构，却把具体资源决策留给运行域。错误不在于本地采用四个聚合，而在于把示例数量抬高为能力证明。

真正需要证明的是：哪些成员进入每个聚合，它们各自要求什么，准入上限是多少，聚合预算如何形成，调度器怎样安装，在正常与故障负载下又测得什么结果。

同一处理不等于同一承诺

RFC 5127 专门区分 treatment aggregate 与以单一代码点和单一 PHB 为中心的 behavior aggregate。处理聚合可以包含多个 DSCP，因为它只关心这些数据包在此处共享什么转发资源。

原服务类仍然存在。它承载应用对丢包、时延和抖动的端到端要求。网络把几个类送进同一队列，是实现压缩，不是合同合并。

因此，聚合必须满足最严格成员的要求。若一个成员能忍受中等丢包，另一个只能忍受极低丢包，不能取平均值后宣布二者都合格。平均值会把明确责任变成整体统计。

不过，“最严格”也不是自动容量公式。当前流量、包长分布、峰值相关性、调度权重、队列内存、链路利用率与备份路径共同决定能否达到目标。规范确定责任方向，运行数据决定事实。

四个聚合各自隐藏什么条件

Network Control 用于在拒绝服务或异常高负载中保护网络生存所需流量。文档还区分客户的网络控制流量与提供商自己的控制流量。两者都叫 control，却可能位于不同队列与资源预算。一个绿色图标无法说明保护的是谁的控制面。

Real-Time 示例汇集电话、信令、多媒体会议、实时交互与广播视频。它假定边缘已经按类准入和整形，使总输入具有可预测上限。若该假定没有收据，EF 式队列只是配置，不是确定性。

Assured Elastic 保留不同丢弃优先级。即便共享调度资源，不同成员也不必有相同生存概率。Elastic 可以让 CS1 比 Default/CS0 更早丢弃；在 MPLS 示例中，CS1 甚至可能在拥塞时饥饿。

这些差异说明，聚合名称只是索引。要理解真实风险，仍需看到成员、丢弃级别、准入、资源与测量。

成员级控制与总量控制不能互换

RFC 5127 建议每个服务类在聚合前进行 conditioning 或准入，并可对聚合总量再做控制。两层检查回答不同问题。

一种情况是，视频类超过自身额度，而语音类暂时安静。聚合总量仍在上限内，总量计量器显示正常；成员计量器却能发现视频正在借用别人的余量。此时问题是授权与公平。

另一种情况是，每个成员都遵守自身上限，但多个峰值在链路故障后同时出现。没有单一违规者，聚合却过载。此时失败的是容量模型与相关性假设。

若只保留总队列计数器，这两种故障会留下相同的丢包症状。调查者无法知道应修正客户策略、边缘准入、共享预算还是故障路径设计。

历史流量可以帮助规划，却不能充当未来准入。点到点业务可能稳定，多点业务的来源集合更易变化。成员越多，相关峰值越不能由单一平均值代表。

身份必须穿过本地域

每个管理域可采取不同聚合方式。因此，RFC 要求不销毁原端到端服务类的概念。推荐方式是保留原 DSCP，由分类器把多个值送入共同队列。

有的域需要使用内部标记。此时必须在出口恢复原始指示。隧道是保存内外语义的一种方式，但“存在隧道”不证明恢复正确。证据链至少包括入口 DSCP、内部值、封装关联、解封装结果与出口 DSCP。

恢复失败可能不会断网。数据包继续到达，下游却按错误类别处理。应用只看到时延或丢包上升，而两端各自的局部配置都可能看似合理。这类静默语义损失比显式丢包更难归责。

DSCP 本身也不认证资格。攻击者或错误应用可以设置优先值。入口分类、合同资格与实际计量仍是独立收据。

链路越快，只是可选空间更大

RFC 给出经验判断：在利用率保持工程范围内时，更高链路速度通常允许更多聚合。关键是条件从句。

额定速率不等于当前余量。重大链路失败后，IP 重路由或 MPLS 保护切换可以把多个聚合集中到备份路径。路由连续性得到维护，服务余量却可能消失。

队列深度也没有单向答案。更深队列可吸收突发，同时增加等待；更浅队列减少等待，却更早显露丢包。包长和发送速率影响串行化与占用，调度器决定谁先支付代价。

因此，验证要在正常、相关突发、链路故障、调度变更和成员变化场景下进行。空闲时无丢包，只证明空闲时没有压力。

跨提供商边界交换的是服务身份

RFC 建议提供商之间以服务类建立关系，而不是把一方内部聚合名称当作全球接口。提供商 A 可用四个队列，B 可用六个。B 需要理解收到的服务类，但无义务复制 A 的物理结构。

这保护了本地自主，也提出了记录要求。双方应说明支持哪些类、如何处理不支持类、入口如何准入、是否改写、怎样恢复，以及用什么指标证明接收后的行为。

在两端抓到相同 DSCP，只证明两个观测点的字段一致。它不能证明中间每一跳都执行同一 PHB、拥有足够资源或满足应用端到端时延。

可移植的不是队列品牌，而是类别身份、边界协议与测量收据。这样内部实现才能变化，而不把客户锁在某个供应商的术语里。

MPLS 三个位仍然属于本地域

附录用 E-LSP 和当时称为 EXP 的字段映射处理聚合。RFC 5462 后来把它改名为 Traffic Class。改名记录了术语演进，不是部署证据。

每个 MPLS 域控制自己的 Traffic Class 分配。E-LSP 可从该字段推断 PHB Scheduling Class 与丢弃优先级；L-LSP 每条路径只承载一个调度类，聚合因而成为逐 LSP 决策。

标签与位值说明计划的承载编码。安装的 LFIB、分类器与调度器说明配置状态。队列遥测与包测量说明运行行为。端到端探针与应用数据才说明结果。这些现实层不能由一个标签替代。

档案能证明到哪里

RFC Editor 与 Datatracker 证明 RFC 5127 的身份、日期和 Informational 状态。IANA 表证明代码点登记。相关 RFC 定义 DS 字段、Diffserv 架构、AF、EF、计量与 MPLS 映射；后续文档证明标准讨论继续发展。

这 24 个来源不包含具名运营商部署、当前产品配置、真实包迹、事故、采用比例或客户 SLA 测量。因此本文不声称某家公司使用四聚合，不声称某实现恢复标记，也不把标准建议说成现场结果。

来源