摘要

  • RFC 3387 识别出 QoS 机制上方缺失的一层：数据包已经可以被分类、标记和优先调度，但服务本身可能尚未被清楚定义、授权、核验或结算。
  • 文件把职责分到接入边缘、网络核心和管理域边界，并提醒人们：收费业务与集中管理也可能损害原本去中心化的尽力而为网络。

先看一张最容易令人满意的回执。两个数据包进入同一设备，其中一个带有类别标记。分类器认出它，调度器让它先离开。抓包、配置和计数器都能证明本地动作真实发生。

但这张回执没有回答服务问题。标记是谁写入的？请求者是否获准？沿途是否预留了足够资源？下一个运营者是否采用同一含义？测量者是否独立？回程由另一家网络承载时谁收费？如果应用仍然失败，哪一方负责？

2002 年 9 月发布的 RFC 3387 正是从这道裂缝出发。它来自 IRTF 的 Service Management Research Group，类别为 Informational，不定义新协议，也没有宣称某套架构已经部署。它所记录的历史瞬间是：区分流量的技术正在前进，把这些技术组织成可运营服务的支撑系统却仍不完整。

早期 IP 管理强调简单和非集中控制，尽力而为与这种结构彼此强化。QoS 改变了管理对象。只要一组数据包得到不同待遇，网络就必须解释待遇的含义、获得资格的条件、稀缺资源的分配方法和跨越多个自治网络的责任边界。

RFC 3387 把服务分成“定义”与“实现”。定义必须无歧义，并能映射到网络真实能力；实现则要把定义落实为控制和资源。信息模型可以保存意图，策略对象可以描述规则，但都不等于设备已经接受配置，更不等于路径交付了结果。

在接入边缘，职责包括认证、授权、准入、流量参数核验和计费接口。那里最接近用户，也最适合决定请求者是谁、可使用多少资源以及越界时如何处置。服务核验、故障通知、重建和终止同样不能省略。授权是允许，准入是资源判断，两者不是一张回执。

网络核心面对的是另一组问题：流量工程、设备配置、资源上报、故障检测和恢复。文件讨论了更集中地计算路径，因为单个转发节点可能看不到作出全局决定所需的信息。但它没有把集中化写成必然答案，反而追问：网络中部新增服务功能的收益，是否抵得过复杂性与不稳定风险？

到了管理域边界，技术问题与商业问题重叠。路径可能穿过许多相互竞争的运营者，它们拥有不同服务模型，也不愿向对手暴露内部容量。双边 SLA 可以描述一个交接点，却不能自动拼成端到端定量保证。域越多，谈判、测量和故障归因越难。

带宽经纪人与可信第三方因此成为可能方案。它们或许帮助处理准入、价格、支付或核验，同时隔离敏感信息。RFC 3387 并未把这些角色规定为必须采用的中央权威。中介能交换证据，不代表它是服务有效性的来源。

计费让现实层次更加清楚。文件要求在服务诞生时就设计计费与安全，而不是等转发机制完成后再补。RFC 2975 区分计量、定价和账单：计量记录特定范围内的资源消耗，定价应用价格规则，账单提出付款要求，实际支付又是下一件事。准确计数器可能遇到错误费率，正确账单也可能尚未支付；付款更不能反向证明网络履约。

DiffServ 的每跳行为同样只有有限含义。它能规定一个节点或一个域如何处理聚合流量，却不能替整条路径作证。RFC 3387 明确指出，每跳类别保证绝不等同于端到端保证。客户关心的是带宽、时延和错误率能否沿途成立，而不是某一台设备是否执行了优先队列。

服务设计还有一个没有签约的利益相关者：尽力而为流量。专用或高优先级容量即使闲置，也可能无法供普通流量使用。收费更高的业务会给运营者带来倾斜资源的动机。RFC 3387 没有提供某个网络的实测损害，但把这一激励冲突公开摆到了架构层。

把 Lu Heng 的运行代码优先原则带入这段历史，边界会更清楚。共同层只应规定互操作、安全和可验证性所需的最小确定规则。运营者可以在边界交换身份、授权、参数和测量回执，同时保留内部资源决策。核验者、经纪人或目录不应因为记录事实而获得统治所有参与者的权力。

RFC 3387 没有完成 IP 服务管理架构。它的重要性恰恰在于拒绝把早到的一张技术回执包装成完整产品。队列确实能区分数据包；运营者仍需定义服务、承诺资源、连接多个域、核验履约、结算账目，并证明高价业务没有悄悄把成本转嫁给尽力而为。

来源