摘要

  • RFC 3496 在 RSVP-TE PATH 中增加可选的 ATM_SERVICECLASS 对象，使 MPLS LSP 能请求 UBR、VBR-NRT、VBR-RT 或 CBR。
  • RFC 明确不规定 LSR 如何用队列与调度实现这些类别。识别、路径状态、预留、标签、调度配置、测量结果和应用交付必须分别取证。

这项扩展试图让 MPLS 网络承载封装后的 ATM 信元，同时保留 ATM 的服务类差异。路径可以经过以太网、Packet over SONET 或 ATM 链路。被统一的是请求语言，不是底层设备的实现方法。

对象的类号是 227，C-Type 为 1。前 29 位保留，发送时必须为零，接收时必须忽略；最后三位依次表示 UBR、非实时 VBR、实时 VBR 与 CBR，4 至 7 保留。这个紧凑格式只回答“想要哪一类”。

它没有说明队列多深、使用何种调度器、分配多少缓存、怎样整形、目标时延和丢包是多少。RFC 3496 直接划线：文档只规定如何发出“TE 路径必须支持 ATM 类”的信号，不规定 LSR 怎样模拟它。

对象出现在 PATH 中，依附 IPv4 LSP Tunnel 会话与 LABEL_REQUEST。DIFFSERV 对象可以同时存在，却不是同一件事。原 RSVP-TE 的限制继续适用，包括只支持单播 LSP。

若 LSP 关联 ATM 服务类，发送端必须带上对象；理解它的 LSR 把对象记录在路径状态块。状态记录证明控制面记住了请求，不能证明数据面已经获得对应队列。

若 PATH 出现多个对象，只有第一个有效；后续对象必须被忽略且不得继续转发。因此 CBR 后面再跟 UBR 不是协商、后备顺序或合并服务，只是一个有效值和被丢弃的多余值。

回程 RESV 无论如何都不携带该对象。预留成功不是对三位服务类的回显确认。操作者必须把出站 PATH、逐跳状态、准入、标签与实际调度配置关联起来。

兼容规则更容易制造错觉。不认识类号 227 的 LSR 按 RSVP 的 11 高位规则，忽略对象却原样转发。字节穿过节点，不代表节点理解或执行要求。不认识 C-Type 的节点则返回 PathErr。

RFC 说不支持会让路径建立失败，发送端应通知管理系统，并可能删除对象重试。删除后成功，只证明通用 LSP 可建立；它同时证明原来的服务类合同已不在请求里。把这种结果写成“恢复”会隐藏降级。

RFC 3270 处理 Diffserv 到 MPLS 的映射，RFC 3564 与 4124 处理 DS-TE，RFC 5127 处理多个服务类的处理聚合。RFC 3496 的边界是单个 ATM 类请求在 RSVP-TE 中被识别、拒绝或在重试时消失。

这也解释了为什么安全验证不能替代实现验证。完整性机制至多证明消息来自持有相应密钥的一方、受保护字段没有被改写；策略准入至多证明某项请求被允许。它们都不读取某跳当前的队列绑定、调度权重和缓存占用。即使发送者身份、PATH 内容和预留事务全部有效，数据面仍可能把 CBR 流量放进错误队列。安全收据、资源收据和行为收据必须并列保存。

反过来，短时测试看见稳定速率，也不能补写缺失的控制历史。轻载网络可能偶然呈现近似 CBR 的输出，而没有任何专用调度保证；拥塞出现后差异才显现。历史审计因此既要保留信令和配置，也要在受控负载下测量时延、抖动、丢包与速率。仅凭一次空闲期成功，会把环境余量误认为协议履约。

这里的空白必须由运行证据填补，不能由类别名称代填。

证据链应逐级保留：发出 PATH、解析对象、接受 SC 值、逐跳记录、策略与资源准入、收到 RESV、安装标签、配置队列和调度、负载下测量、应用结果。三位信号只能启动这条链，不能完成它。

来源