摘要

  • RFC 5212 允许一个 GMPLS 控制平面把多个层与多个交换区域的 TE 链路放进同一 TED；它也明确承认，路径算出来时，端点所在层可能尚未真正连通。
  • ISCD、虚拟 TE 链路和稳定接口标识证明的是规划能力。要证明业务成立，还要有边界调整资源、低层 LSP 实例、属性与 SRLG 继承来源、数据完整性验证、跨层 OAM 以及客户流量观测。

统一视图解决了谁看得见什么

RFC 5212 是信息类需求文档，不是具体协议。它把“层”和“区域”分开：区域由 PSC、L2SC、TDM、LSC、FSC 等交换类型识别；层则描述某一数据平面的交换粒度。一个区域可以容纳多个层，多区域网络则至少跨越两种交换类型。

统一 GMPLS 控制平面的吸引力很直观。不同层的 TE 链路进入同一个 Traffic Engineering Database，路径计算不必在彼此隔离的地图之间猜测。运营者可以让分组业务使用下层传送资源，也可以围绕整个网络而不是某一层做容量优化。

但“统一”统一的是表示，不是所有事实。RFC 要求路径计算和信令能够在部分 TE 信息上运行。更关键的是，它允许把尚未建立底层 LSP 的可能性作为虚拟 TE 链路通告给上层。开启触发式信令后，算法甚至可以产出一条跨区域路径，而这条路径在端点层仍不连通；设计假定请求到达边界时，会再创建或选择低层 FA-LSP。

因此，计算结果不是完成态，而是一份包含后续动作的方案。

能力、余量、分配与验证是四张票据

ISCD 可以说明接口支持哪种交换、采用什么编码、带宽粒度如何。它不能证明设备内部恰好还有资源完成层间转换。混合节点要维护连接不同层的内部链路，也要暴露终结与调整能力的可用性。RFC 5212 之所以要求路径计算考虑这些资源，正是因为高层 LSP 可能走到门口，才发现低层没有可用的适配条件。

这里不能用一个“supported”字段包办全部判断。能力表示设备能做某类工作；余量表示此刻仍有多少；分配表示本次请求拿到了什么；验证则回答生成的数据链路是否正确。权限还在第五个维度：即便资源存在，边界策略或另一管理域也未必允许请求使用。

这与恒路笔记中反复强调的现实层次相呼应。记录能够描述系统，不能替系统作出动作；看见某项能力，也不会自动获得调用它的权力。

“虚拟”不是缺陷，抹掉状态才是

预先建立所有低层 LSP 会长期占用带宽和适配资源。虚拟 TE 链路提供了更灵活的做法：先把一种可实现的连接选择呈现给上层，等上层真正选用时，立即在低层发起信令。

问题不在虚拟化本身。问题出现在资产清单或保障平台把五个不同状态压成一个绿色图标：可能存在、已被选择、正在建立、已经建立、已经验证并承载流量。只要这些状态仍然可见，虚拟链路是一项诚实的期权；一旦状态被抹平，它就会被误读为已经存在的电路。

即使是真实 FA-LSP，稳定标识也可能遮住变化。RFC 5212 要求允许在保持相应 TE 链路接口标识不变的情况下重新路由 FA-LSP。对上层来说，这是必要的抽象稳定性；对风险分析来说，这意味着同一个名字背后的光路、节点与共同故障面可以改变。

风险在继承时可能被压缩掉

低层 LSP 被提升为上层 TE 链路时，需要继承交换能力、TE 度量、各优先级带宽、保护属性和 SRLG 等信息。RFC 没有把这件事写成简单复制。继承要遵循策略，上层度量不一定等于低层度量之和，隐藏低层路由还可能丢失可靠性判断所需的信息。SRLG 应如何完整继承，文档明确留给后续讨论。

这会产生一种很现实的错觉：上层看到两条分离的链路，低层却让它们经过同一管道、同一供电点或同一管理故障域。保护标记仍在，物理独立性却未必存在。抽象并非错误，但它能支持多强的承诺，取决于继承数据的来源、更新时间与披露边界。

VNT 重配置也不是无成本整理。释放利用率低的 FA-LSP、把嵌套流量迁往另一条路径，都可能干扰上层。Make-before-break 是降低干扰的方法，不是“零丢包”“零乱序”或应用无感的测量结果。

建立成功，只结束了控制平面的问题

RFC 5212 第 5.9 节单独提出：低层 LSP 建立并准备作为高层数据链路使用时，可以先验证连接正确性和数据完整性。具体方法取决于数据技术，超出该文档范围，但 GMPLS 应协调验证。

如果“建立”已经等于“可用”，这一节就没有存在必要。信令成功证明控制平面事务达到某个状态；数据链路验证证明低层连接的特定性质；跨层 OAM 还要把与客户 LSP 有关的告警向上传递；最终，来自明确观察点和时间窗口的流量与应用结果，才能证明客户所得到的服务。

一张可审计的跨层凭证至少要绑定：请求代次与端点、所选路径和每次层间转换、边界策略决定、调整资源分配、虚拟链路转真实的状态、低层 LSP 身份与资源、度量/保护/SRLG 的继承来源、连接与完整性测试、客户层与服务层 OAM 关联，以及最终转发结果。

这张凭证是 BTW 的编辑建议，不是 RFC 5212 强加的协议要求。它只做一件重要的事：阻止某一层的成功冒充另一层的结果。

地图的权威止于地图

TED 对它收到的控制平面表示具有权威性。它可以支持计算，也可以触发信令。但它不能替另一管理域批准资源，不能把“可能建立”变成“已经建立”，不能自动恢复被抽象隐藏的共同风险，更不能证明客户应用已经交付。

把这些边界说清，并不会削弱自动化。相反，它让自动化可追责：地图负责计算，信令负责尝试改变状态，验证工具负责测试生成的链路，保障系统负责把不同来源、代次和时间戳的证据正确关联。

真正危险的不是屏幕上有一条虚线，而是平台把虚线画成实线后，删掉了它尚未完成的那些动词。

来源

  1. RFC 5212 HTML
  2. IETF Datatracker：RFC 5212
  3. RFC 5212 信息页
  4. RFC 5339：MLN/MRN 需求评估
  5. IETF Datatracker：RFC 5339
  6. RFC 6001：GMPLS 多层/多区域协议扩展
  7. IETF Datatracker：RFC 6001
  8. RFC 5623：基于 PCE 的层间框架
  9. RFC 4202：GMPLS 路由扩展
  10. RFC 4206：GMPLS TE 的 LSP 层级
  11. RFC 3945：GMPLS 架构
  12. RFC 5146：面向 G.709 的 GMPLS 扩展
  13. RFC 4847：路径计算域序列
  14. RFC 4726：跨域 MPLS TE 框架
  15. RFC 4802：GMPLS TE MIB
  16. RFC 4803：GMPLS LSR MIB
  17. RFC 4377：MPLS OAM 需求
  18. RFC 5212 文档历史
  19. 恒路：运行代码优先