摘要

  • RFC 3936 把每条 RSVP Class-Num 行为带再分为 Standards Action、Expert Review 和 Vendor Private 三种分配通道。
  • “谁能取得号码”与“不认识对象的旧节点如何执行”是两套控制面；私用只描述分配方式，不会让线路行为也变成私有。

九个区间，其实是两张表叠在一起

RFC 2205 为 RSVP 对象规定了八位 Class-Num 和八位 C-Type。遇到未知类时，0bbbbbbb 让节点拒绝整条消息并返回 Unknown Object Class；10bbbbbb 让节点忽略对象，不转发也不报错；11bbbbbb 让节点不解释对象，却在后续消息中不经检查、不作修改地继续转发。RFC 2205 的官方记录说明文件身份，真正选择动作的是线上那个字节。

RFC 3936 于 2004 年作为 BCP 96 发布。它没有重画这三条路径，而是在每条路径里各开三扇门。拒绝整条消息的 0–127 区间中，0–119 用 Standards Action，120–123 用 Expert Review，124–127 留给厂商私用。只丢对象的区间依次是 128–183、184–187、188–191。原样携带未知对象的区间依次是 192–247、248–251、252–255。

今天的 IANA RSVP Parameters 仍展示这九段。横向看，是标准、试验和私用的授权条件；纵向看，是旧代码遇到未知对象时的三种动作。选择 124 与选择 252 都可以是“私用”，后果却可能从整条消息失败变成对象穿越旧节点。

RFC 3936 的资料页说明它更新 RFC 2205 与 RFC 3209；勘误页用于核对修订。RFC 3209 的资料页能证明 RSVP-TE 文件沿革，却不能证明某个代码点已经部署。

私用号码前面还有一个公共编号

Vendor Private 用法不逐项登记。为让不同企业复用同一私用代码点，RFC 3936 要求相关数据字段的第一个四字节字放置 IANA SMI Private Enterprise Number。编号来自公开的 IANA 企业编号登记表。

这能分开命名空间，却不是认证。企业编号不能证明发送者身份、设备归属或载荷安全，也不会令两家厂商的私有格式互通。如果实现不认识企业编号，仍须依 Class-Num 外层规则处理对象与消息。私有的是语义，公共的是兼容动作。

未知类不等于已知类中的未知子型

高位分流只适用于未知 Class-Num。节点若认识类而不认识 C-Type，RFC 2205通常要求拒绝整条消息。RFC 3936 因而要求新类自行说明后续 C-Type 的分配政策；旧类默认使用 Standards Action，除非后来的 Standards Track 或 BCP 文件另有规定。

EXPLICIT_ROUTE 与 RECORD_ROUTE 的子对象又是独立命名空间。RFC 3936 同样为它们划分标准、专家审查和私用范围，并要求私用格式携带企业编号。RFC 2207提供 IPsec 流虚拟目的端口的背景，RFC 3473展示后续 GMPLS 扩展；但子对象类型并不会因为也属于 RSVP 就自动继承 Class-Num 的三种动作。

处理规则的修改也受文件类别约束：Standards Action 范围要用 Standards Track RFC，Expert Review 范围要用 Experimental RFC。2004 年采用的是 RFC 2434的分配政策词汇；RFC 8126后来取代它，不能倒过来成为原设计的作者。

登记表证明号码状态，不证明实现、流量、互通或安全效果。Heng Lu 关于最小初始规范与自愿采用以及运行代码优先的论述，正好提醒我们把发布、实现和运营事实分开。

RFC 3936 管理的不是一个中性的数字。号码高位已经是旧机器能够执行的决定。代码点可以不公开具体用途，它对陌生路由器的命令却从未私有。