摘要

  • RFC 3476 把 OIF 光 UNI 的若干字段放进 LDP 与 RSVP 的公共编号空间，却把字段内容与使用规则继续交给 OIF UNI 规范。
  • “分集不可用”“业务等级不可用”“连接未知”“发送者或接收者未获授权”等错误表明：代码点被正确识别后，政策、资源与物理执行仍可能拒绝请求。

协议登记表管理的对象很小：一个名称、一个数字，以及指向规范的引用。它的作用却不可替代。两台设备如果把同一个数字解释成不同对象，即使读取了完全相同的比特，也无法协同。公共登记消除了这种歧义，但不会替网络找到一条光路，更不会替运营者作出授权决定。

RFC 3476 于 2003 年 3 月以 Informational 身份发布，并非 Internet Standard。Optical Internetworking Forum 当时已经设计了光用户—网络接口 UNI 的信令。它的目标是尽可能复用 IETF 的 LDP、RSVP、RSVP-TE 与正在形成的 GMPLS 机制，只为 UNI 特有需求增加少量对象与错误码。要把这些对象装进既有协议，它们必须拥有不与他人冲突的值。

LDP 一侧得到三种 Source ID TLV 与三种 Destination ID TLV，分别承载 IPv4、IPv6 和 NSAP 形式；另有 Egress Label、Local Connection ID、Diversity、Contract ID 与 UNI Service Level。登记值分布在 0x0960 至 0x0970。RSVP 一侧得到 class number 229、C-Type 1 的 GENERALIZED_UNI 对象，以及 class 1、C-Type 11 的 UNI_IPv4_SESSION。GENERALIZED_UNI 的子对象可以装入源、目的 TNA 地址、分集请求、出口标签与业务等级。

这些精确数字并没有让 RFC 冒充完整业务规范。对于一个又一个 TLV 与子对象，文本都说明其内容和用法见 OIF UNI 规范。公共代码点只提供稳定的“挂钩”；外部规范解释挂在上面的语义；运营网络还要判断请求是否真实、是否有权、是否可行。

这是一条制度边界。OIF 负责面向业务的实施协议，IETF 提供可复用的信令协议，IANA 维护公共数值空间，设备厂商实现解析与状态机，运营者控制实际拓扑和稀缺光资源。RFC 被公开，并不意味着 OIF 的业务自动成为 IETF 标准；IANA 登记一个值，也不意味着任何运营者必须接受它。

公开空间与私有空间还同时存在。RFC 3476 说明，UNI 特有的 LDP 状态码来自 0x3Fxxxxxx 私用空间，不需 IANA 管理。OIF 原来定义的 Status Enquiry 与 Status Response 两个 LDP 消息已经废止，因此 RFC 不再为它们申请代码点。登记表记录的不只是“有什么”，也记录了筛选结果：有些构件进入公共命名空间，有些留在私有空间，有些在登记前退出历史舞台。

最有价值的证据来自错误码。RSVP 可以返回 Diversity not available、Service level not available 或 Invalid/Unknown connection ID；Policy Control Failure 还可以区分 Unauthorized sender 与 Unauthorized receiver。它们并不是解析器没认出代码点，而是解析成功之后，另一个控制面作出了拒绝。

设想一个格式完全正确的 GENERALIZED_UNI 对象。class、C-Type、长度与子对象都能通过校验，源和目的 TNA 也能读取。这仍然不能证明发送者有权订购电路、接收者同意接入、拓扑中确有两条独立路径，或某个时隙与波长尚有容量。语法正确与运营可行不是同一张回执。

代码点只说：“把这些比特解释为这一类对象。”它没有说：“服从这个主体”“接受这份合同”“预留这段容量”“写入这台光交叉连接”，更没有说“客户业务已经交付”。一旦把这些判断压成一个绿色状态，底层登记记录就会借用后续所有机构与设备的权威。

相邻 RFC 也没有提供捷径。RSVP 维护软状态与预留，RSVP-TE 承载隧道信令，LDP 分发标签，GMPLS 把标签概念扩展到不再是数据包头的交换资源。RFC 3471 到 3475 继续区分身份、消息往返、通知、Call 与 Connection。RFC 3476 只是为 UNI 对象补上可识别的公共词汇，没有把这些层合成一次动作。

后来发布的 RFC 3936 说明 RSVP 命名空间的分配政策；RFC 8126 更明确地区分了“给 IANA 的登记指令”与应当放在其他章节或其他规范中的技术说明。不能把这些后来的文本倒推成 2003 年的全部规则，但它们帮助我们看清 RFC 3476 已经实践的克制：登记引用，不等于执行语义。

今天的 IANA LDP 与 RSVP 登记表能够证明某些值曾被分配并指向 RFC 3476。它们不是生产遥测，不能显示路径计算是否找到分集、容量是否锁定、光交叉连接是否下发、光信号是否出现，也不能证明客户流量曾经通过。

按照 Heng Lu 的现实层方法，审计应从原始消息开始。保存字节、协议、对象或 TLV 编号、长度、U/F 位或 class/C-Type，以及解析结果；再用事件当时的登记表快照解析编号，并打开准确的 RFC 与 OIF 版本。之后逐层保存身份、认证、授权、准入、路径计算、资源预留、硬件编程、光信号、流量与业务结果。

不要让一个字段越权作证。Source ID 可读，不等于主体经过认证；Diversity 子对象存在，不等于两条路径真正独立；Service Level 写进请求，不等于 SLA 已履行；Egress Label 被解析，不等于出口光路已接通；没有收到错误，也不是所有后续动作完成的正面证明。

拒绝路径同样需要完整记录：错误对象、code、subcode、发出节点、时间，以及它所回应的原始请求。“Diversity not available”比笼统失败更有信息量，因为它指出声称的拒绝面；但它仍不能证明隐藏拓扑的全部事实，也不能排除数据库过期或其他方案存在。

RFC 3476 在互联网史上的价值，正是展示了协调权力应当有多窄。公共登记表能让互不隶属的实现说出同一个对象，这是必要基础设施；它既不是对光业务的主权，也不是业务存在的证据。编号只负责打开案卷，结论必须由后续每一层的回执完成。

来源