摘要

  • RFC 5420 以 TLV 扩展 RSVP-TE 属性，因为 SESSION_ATTRIBUTE 中八位 Flags 字段无法持续容纳扩展；适用范围包括 MPLS 与 GMPLS 的分组和非分组 LSP。
  • Attribute Flags TLV 不是一个独立的“必需”标记。它可以出现在 LSP_ATTRIBUTES 或 LSP_REQUIRED_ATTRIBUTES 中；究竟是透明转发，还是要求路径上检查，由承载它的对象决定。
  • LSP_ATTRIBUTES 使用 class 197 的 C-Num 形式：不认识对象的 LSR 应原样转发。其内未知 TLV 或未知 Attribute Flags bit 也原样转发。LSP_REQUIRED_ATTRIBUTES 使用 class 67：每个 transit LSR 都须检查并处理内容；未知对象、TLV 类型或置位 bit 必须以相应 Unknown Attributes TLV 或 Unknown Attributes Bit 的 PathErr 拒绝建立。
  • “必需”只表示要求路径上的检查，不表示每个属性都有同一套不支持行为。对已识别但不支持的属性，定义该 TLV 或 bit 的 RFC 保留语义权；RFC 5420 本身不替代它。

承载边界、职责与报告

请求者或入口节点先选择承载对象：若依赖只是出口动作或选择性理解，通常把属性放进 LSP_ATTRIBUTES，以保留跨旧节点的透明转发；若每个 transit LSR 的检查是建立条件，才选择 LSP_REQUIRED_ATTRIBUTES。这个选择不能由 Attribute Flags TLV 或其中某个 bit 单独完成。相同的 TLV/bit 放在两个对象中，强制性后果也不同。

中转 LSR 的职责是识别承载对象并按其规则处理。对 LSP_ATTRIBUTES，未知对象、TLV 或 bit 不构成由 RFC 5420 规定的拒绝理由，而是继续转发且不改变未知内容。对 LSP_REQUIRED_ATTRIBUTES，未知对象、未知 TLV 或未知 set bit 则具有拒绝权限，产生相应的 Unknown Attributes PathErr。若节点识别属性但不支持它，不能套用“必需即拒绝”或“必需即继续”的统一规则，必须回到定义该属性的 RFC。

下游转发是另一件事：一个节点把 LSP_ATTRIBUTES 原样送到后续节点，只证明它转发了内容，不证明它理解或执行了属性。出口是否采取动作、key-transit 是否实际应用属性，需要定义 RFC 规定的行为和可用的报告来验证。请求者可以要求路径级检查，却不能用基础对象替代属性定义中的语义。

三个反事实应明确区分。第一，若未知 TLV 或 bit 位于 LSP_ATTRIBUTES，它应被原样转发。第二，若未知对象、未知 TLV 或未知 set bit 位于 LSP_REQUIRED_ATTRIBUTES，建立应被拒绝。第三，若属性已被识别但不受支持，处理结果遵循定义该属性的 RFC，而不是一条普遍规则。

LSP_REQUIRED_ATTRIBUTES 不用于 Resv。Resv 上的 LSP_ATTRIBUTES 可以报告整个 LSP 的状态；这不同于 RRO Attributes subobject 的逐跳状态。后者必须绑定到紧邻在前的 address 或 interface subobject 所标识的 LSR；节点不能只推送 Attributes subobject 而不同时推送该标识。定义属性的 RFC 可以规定某个 bit 报告 compliance 或 non-compliance，也可以规定报告是否有意义或是否必须，不能把“有报告”泛化成所有属性的保证。逐跳报告还会暴露各节点的运行状态、支持情况或合规判断，并消耗 RRO 与 RSVP 消息空间；若新增 RRO Attributes 使 Path 或 Resv 超过消息空间，按 RFC 3209 的 oversized-RRO 规则处理。

在 LSP region 边界，forwarding-adjacency LSP 可在本地策略允许且边界支持相关对象时继承一部分 Attributes TLV；否则，属性对象会随继承的 ERO 一并复制。Attribute Flags TLV 与 RRO Attributes subobject 共用一个 IANA 管理的 bit 编号空间，但定义 RFC 必须说明 bit 在何处有意义并处理零值默认。RFC 7570 是对 RFC 5420 机制的后续通用扩展，涉及 hop-specific 的 ERO/RRO 属性及注册指导；它不是普遍部署的证据，也不是只针对保护机制的规范，并未消除可选承载与必需检查的分界。

三个场景

  • 仅出口：可选对象让旧式 transit 节点保持可达；出口是否采取动作必须由属性定义的机制或报告核验。成功建立本身不是证明。
  • 关键中转：如果 key-transit 节点不理解，选择可选对象只能保留转发，不能提供强保证；若该节点是依赖条件，应由定义 RFC 和请求策略明确所需检查。
  • 全路径：all-LSR 支持是建立前提时，class 67 的未知对象、TLV 或 bit 会让一个不支持的 hop 触发 fail-closed。已识别但不支持仍须回到定义 RFC，不能假定统一拒绝或统一继续。

这带来明确交换：required examination 缩小旧设备可用范围，并可能把单一 unsupported hop 变成 setup failure；optional forwarding 保留兼容性，却削弱保证。RRO 逐跳报告既消耗消息空间，也可能向观察者暴露运营状态；FA-LSP 继承引入边界策略成本，共享注册表要求未来定义者保持语义对齐。来源没有说明任何厂商、运营商、部署普及度、失败率、建立时延、性能或客户结果；也没有指明未来属性应属于 optional、required、egress-only 还是 key-hop-specific。那取决于定义 RFC 与运营政策。冻结的 errata 页面只是 RFC 5420 当前记录，本稿不从中提出额外修正主张。

来源