摘要

  • RFC 3175 让聚合区域内部的路由器忽略端到端 RSVP 消息，再用与 DSCP 关联的聚合预留承载大量流。核心少保存状态，不等于边缘可以省掉逐流准入凭据。
  • 解聚合器决定映射，用 DCLASS 把 DSCP 传回去，并把该流的令牌桶计入聚合容量；聚合器再分类和标记数据包。映射、容量、标记、逐跳处理和最终交付是不同事实。
  • 聚合带宽故意按块和预测配置，并不精确等于成员之和；走错出口的 RSVP-E2E-IGNORE 消息还可能无声消失。健康检查必须贯通两个边缘、核心调度和真实流量。

每条流都被记住，核心就随终端数量膨胀

RSVP 的精度来自逐流状态。一次预留要在路径上的每台参与路由器交换消息、执行计算并占用内存。会话数量增加时，核心的控制面负担也跟着终端需求增长。

RFC 3175 没有否定逐流意图，而是改变了它必须在哪里可见。共享入口和出口的多条端到端预留，可以穿过一个聚合区域，由一条更大的预留承载。第一台从外部接口接收 Path 并转向内部接口的路由器是聚合器；最后一台把它送回外部接口的是解聚合器；中间设备不再为这条流逐一建档。

这不是把端到端服务改成“只看总量”。恰恰相反，核心得以变薄，是因为边缘继续保管成员账本。共享系统可以忘记细节，负责准入的系统不能忘。

协议号 134 明确规定谁可以不知道

普通 RSVP Path 会让理解 Router Alert 的路由器参与处理。为了隐藏端到端信令，聚合器把 IP 协议号改成 RSVP-E2E-IGNORE；IANA 为它登记了 134。内部路由器按普通数据包转发，不安装这条流的 RSVP 状态；到达正确出口后，解聚合器恢复 RSVP。

这个字段不是“预留已完成”的章。它只是限定：这些节点不要看，那一个节点必须重新接手。RFC 3175 特别提醒，如果配置找不到合适的解聚合器，改写后的 Path 可能一路走到目的地，再因陌生协议号被忽略，而且很难发现。

所以，核心没有状态是设计成功，出口没有回执却是故障。入口必须能把送出的隐藏消息与出口恢复的消息对应起来。否则，网络看似安静，只是把失败也一起隐藏了。

DSCP 是聚合坐标，不是客户权利

区域内用一个或多个 DSCP 标识聚合流量，再由相应 PHB 提供逐跳待遇。运营者可以把 Guaranteed Service 映射到一类，把 Controlled Load 放到另一类，也可以制定别的本地政策。

RFC 把最终映射决定交给解聚合器，因为它最先看到接收方的 Resv 和请求的服务类型。解聚合器用 DCLASS 返回所选 DSCP；聚合器记录关系，在向发送方继续转发 Resv 前移除 DCLASS，并在入口为匹配的数据包打标。

这个流程故意把权限分开。抓包看到 DSCP，只能证明该处的六个比特；DCLASS 只能证明某条信令携带过映射选择。它们都不能证明分类器匹配了正确流、聚合预留仍有余量、每台内部设备装载了预期队列，或接收应用得到了所需体验。

解聚合器仍要逐条做准入会计

有足够聚合带宽时，解聚合器可以把端到端 Resv 发回聚合器，并把其中的令牌桶加入内部使用量。这一步正是“大块存在”不能替代的成员凭据。

一个 1000 单位的预留，并不会自动批准下一条 10 单位请求。系统仍要找到正确聚合会话，读取已承诺用量，应用映射和准入政策，再确认余量。只有聚合 Path 而没有 Resv 时，需要新建资源预留；容量不足时，需要扩容、等待或拒绝，不能借现有块的名义虚构成功。

因此，核心状态数量可以与成员数脱钩，边缘账本却不能。扩展性来自把逐流责任集中到更合适的位置，而不是把责任消灭。

精确相加反而会毁掉聚合收益

最直观的安全尺寸，是把所有成员的带宽和突发量相加。但若每次加入和退出都重设聚合值，核心仍要频繁处理信令。RFC 3175 因而讨论大于即时总和的块，并让调整间隔更长。

一天中的固定高峰、近期增长趋势，都可以成为预测输入。调整越细，空闲容量越少，控制面变化越多；调整越粗，信令越少，预测误差和恢复压力越大。RFC 没有把某一种算法写成普遍真理。

这里的本地自由带来额外证据义务。预测值不是可用容量；配置容量不是已用容量；准入结果不是队列运行状态；队列状态也不是应用结果。如果监控系统把它们合成一个绿色数字，聚合就从状态优化变成了事实遮蔽。

故障对象变少，故障半径却变大

逐流预留提供更严格的隔离。聚合后，多条流共享一类，突发可能相互影响。RFC 引用了特定条件下对平均和尾部延迟有利的研究，但那不是任意网络在 2026 年的性能证明。要得出运营结论，还需要具体实现、拓扑、队列、流量组合、测量方法和时间窗口。

同一机制也放大集中风险。聚合预留被破坏，许多通话或会话会一起失去保障；预留过量，其他业务被挤压；入口分类错误，不该享受待遇的包进入保护类。控制对象少了，每个对象承载的后果更多。

密码完整性也只覆盖一层。对于被核心忽略的端到端消息，聚合器与解聚合器成为逻辑 RSVP 邻居；区域内的聚合消息仍按相邻节点逐跳保护。摘要验证能证明配置密钥和消息完整性，不能证明映射、容量、标记或交付正确。

后来的扩展暴露了第一版聚合的边界

RFC 4804 把聚合带入 MPLS TE 与 DS-TE 隧道。RFC 4860 又引入通用聚合预留，因为 RFC 3175 不能为相同源、目的与 PHB 组合表达多个聚合。RFC 5350 更新了 Router Alert 的 IANA 规则。今天的 IANA 表仍保留协议号 134 和 IPv4/IPv6 聚合 C-Type。

这些记录证明规范与登记存在，不证明某台路由器实现、某个运营商启用，也不证明某条业务质量。RFC 3175 更持久的价值，是给出一条约束：核心可以不知道逐流细节，但必须有人保管从请求到结果的可重建链条。

Lu Heng 关于运行代码、最小共同规范与现实层的论述，是本文公开标明的后设分析，不是 RFC 作者的话。它提醒我们：登记项、政策、配置、运行行为和经济结果不能互借权威。聚合可以让共同层更薄，不能让证明链也一起变薄。

来源与边界

证据冻结于亚洲/上海时间 2026 年 10 月 2 日。它支持 RFC 3175 的机制、IANA 登记与后续规范关系，不证明具体部署、采用率、状态节省量、流量、性能、事故、运营者行为或交付质量。预测案例是建议，不是测量数据。