摘要

  • RFC 2370 用 9、10、11 三类 Opaque LSA 携带应用专属信息，并分别把泛洪限制在链路、区域与自治系统范围。
  • O-bit、重传确认和 LSDB 记录能证明邻居能力与协议承载，却不能证明应用理解内容、认可新鲜度、完成路径计算、安装转发状态或成功传送流量。

链路状态协议里的广告通常一看就知道用途：Router-LSA 描述路由器连接，Network-LSA 描述共享网络，摘要和外部 LSA 进入既定的路由计算。1998 年的 RFC 2370 引入了一种克制得多的模糊性：OSPF 可以搬运一个对象，却不负责定义对象正文的意义。

“Opaque”不是加密，也不是秘密。它表示共同协议只识别标准 LSA 头，后面跟着按 32 位对齐的应用专属信息。年龄、Options、类型、Link State ID、Advertising Router、序列号、校验和与长度都属于 OSPF；正文如何解释，则属于另一个规范与另一段运行代码。

这是一种明确的权力分工。共同层只提供身份、边界、泛洪、确认、老化与数据库同步。未来应用不必重新发明分发协议，却也不能借用 OSPF 的成功，把自己的语义、权限和结果一并宣告为事实。

三种类型画出三道拓扑边界

Type 9 只在本地链路传播。实现必须记住它所属的接口，不能从别的接口继续泛洪。Type 10 只在所属 OSPF 区域内传播，区域边界就是停止线。Type 11 面向整个自治系统，行为接近 Type 5 外部 LSA，但不能进入 stub area。

因此，scope 不是说明性标签，而是可执行约束。一个校验和正确的 Type 10 仍无权越过 ABR。一个在 stub area 内收到的 Type 11 不是“可忽略的额外信息”，而是违反分发合同的对象，应被拒绝。发送方和接收方共同承担守住边界的责任。

Link State ID 还被切成两部分：高八位是 Opaque Type，余下 24 位是类型专属 ID。它们给扩展家族和实例命名，却不证明正文真实，不证明源路由器有权作出这项业务声明，也不替消费者决定动作。

O-bit 证明愿意承载，不证明掌握所有语义

RFC 2370 必须面对混合部署。路由器在 Database Description 交换中用 O-bit 表示愿意接收和转发 Opaque LSA。邻居据此生成数据库摘要和重传列表：只向具备能力的邻居登记 Opaque LSA。多播更新仍可能让不具备能力的设备偶然收到对象，但未知类型会被丢弃。

O-bit 回答的是窄问题：邻居是否支持这套载体机制。它没有列出邻居真正理解哪些 Opaque Type，也不证明本机安装了对应应用。一个设备可以忠实转发自己不消费的扩展；一个应用也可能因为中间能力断点，只看到不完整的拓扑。

所以，LSDB 同步与应用收敛必须分账。协议层把合法且范围正确的 LSA 存入数据库并完成确认；应用层还要筛选类型、解析正文、检查源与新鲜度、和其他状态核对，再决定是否采用。数据库里有一行，只能说明 OSPF 接受了协议对象，不能充当应用回执。

序列号、年龄和校验和并不等于事实仍然有效

Opaque LSA 继承 OSPF 的生命周期：序列号区分新旧实例，校验和发现受保护字节的损坏，LS age 与 MaxAge 支持过期和清除，MinLSInterval 与 MinLSArrival 限制更新频率，重传和确认闭合邻接层交付。

这些证据都真实，却各自有限。校验和验证字节，不验证语义；较新的序列号可以替换旧记录，不证明源应用的数据刚刚测量；确认表示邻居收到，不表示应用采用；LSA 还可能在源已经不可达时继续存在。

Type 11 正是后来修订的原因。RFC 5250 在 2008 年取代 RFC 2370，因为区域外路由器可能在源停止运行后继续使用 AS 范围信息，最长接近一小时。新规范让 Type 11 的发起者以 ASBR 身份暴露可达性，并要求消费者在发起者不可达时停止使用相关 Opaque LSA。

这项修复说明：原有载体可能完全按年龄和泛洪规则运行，应用仍可能得到过时事实。扩大分发不会自动增加真实性；声明者是否还存在，必须成为使用决定的一部分。

流量工程展示了这只信封的价值与边界

RFC 3630 后来用区域范围的 Type 10 携带流量工程属性。具备 TE 能力的设备可以据此建立 TE 数据库；不理解 TE 语义的节点仍可把它当作 Opaque 对象继续泛洪。这让新应用复用成熟的分发系统，而无需把自己的算法塞进基础 OSPF。

但收到 TE LSA 不等于执行 TE。RFC 3630 明确说，更新 TE 数据库无需触发普通 SPF，并把路径如何实例化留在机制之外。部分节点不支持扩展时，消费者的 TE 拓扑还可能缺块。同步的 LSA、完整的应用视图、计算出的路径、安装成功的转发项与真实流量，是五张不同凭证。

RFC 7684 后来又把 Opaque LSA 用于扩展前缀和链路属性；今天的 IANA OSPFv2 注册表仍记录 Type 9、10、11 和后续命名空间。注册表证明名称得到分配，不证明某个网络部署、启用或受益。

安全边界同样不能合并。OSPF 认证可以保护协议交换，RFC 5709 又增加 HMAC-SHA 算法；但通过认证的包只说明它来自持有相应密钥的协议参与者。应用仍须判断声明者是否有权发布特定属性、内容是否与其他证据一致、是否足够新、是否允许驱动动作。大量不同广告还会造成数据库与处理压力。

这正符合 Heng Lu 关于 Running-Code Primacy 与最小初始规范的要求：共同层只规定互操作必需的确定性规则，后续扩展通过实现、部署与自愿采用取得现实效力。文件发布不是运行结果，数据库记录不是转发结果。

RFC 2370 的历史意义因此不只在 OSPF。它证明成熟协议可以帮助未来信息流动，却不必声称掌握未来信息的意义。信封可以到达，数据库可以一致；应用仍要说明为什么相信，网络仍要证明接下来真正发生了什么。

来源