摘要

  • RFC 5212 允许“虚拟 TE 链路”在底层 LSP 尚未建立时，就以近似已建立链路的形式提供给上层计算。
  • 统一 TED 证明的是某个快照里存在跨层候选路径，不证明适配资源已经锁定、底层连通性已经验证或用户业务已经送达。
  • 可靠系统应保留一条完整状态链：通告、计算、授权、触发、资源承诺、底层验证、上层安装、数据转发与用户观察。

14:00 的绿色没有回答 14:02 的问题

14:00，一个分组层控制器收到 10 Gb/s 的连接请求。界面把两个边界节点之间画成一条稳定的绿色 TE 链路；下方光层的内部跳数被折叠，TED 中的属性足以让路径计算成功。

这条线其实是虚拟的。它代表“如果被选中，就可能创建一条底层 LSP”。14:01，上层请求触发底层信令。几乎同时，另一个事务占用了混合节点内的大部分适配资源。外部链路仍显示宽裕总容量，但真正负责终结一种交换能力并把信号交给另一种能力的内部功能只剩 2.5 Gb/s。底层建立失败。14:02，业务面板仍写着“路径可用”，因为它展示的是两分钟前的计算，而不是一分钟前的执行。

这是一个构造场景，不对应任何真实运营商、产品或事故。14:00 的计算可以完全诚实；越界发生在组织把“可计算”读成“已预留”，又把“已预留”想象成“已交付”。

RFC 5212 规定了什么

RFC 5212 于 2008 年 7 月以 IETF Informational 文档发布。它给 GMPLS 多层网络以及其中的多区域网络规定框架和功能需求。区域对应交换技术，层对应交换粒度。同一控制平面实例可以处理分组、二层、TDM、波长和光纤交换等不同能力。

文档并没有给出一套完整解决方案。它主要讨论一个 TE 域内由单一 GMPLS 控制平面实例管理多个层的情形；多套控制平面分别覆盖不同层不在其范围内。它认为单一服务商可能最常见，同时明确没有排除不同层归不同管理主体所有。

统一视图可以减少重复控制实例、加快开通并改善跨层资源选择。但统一不等于合并现实。RFC 5212 特别指出，地址与 TE 信息聚合并不会改变控制平面和数据平面的分离。共同地图也不会把两个行政主体变成一个权力主体。

TED 保存的是有时效的表示

多个层的 TE 链路可以汇入同一个 Traffic Engineering Database。路径计算于是能够选择一条跨越层或区域的路线，让底层 LSP 承载上层 LSP。

TED 中保存的是通告。它描述某个来源在某个时刻报告的交换能力、编码、带宽、优先级、拓扑和约束。算法找到候选路线，证明这条路线符合该表示；它没有证明候选所需的每一项资源已经为本次请求锁定。

混合节点最能说明这道边界。不同交换技术之间的衔接需要内部终结和适配资源。外部端口可能还有大量带宽，内部矩阵或连接却已经无法完成所需转换。因此 RFC 5212 要求通告适配能力，并要求计算把可用的终结与适配资源当作约束。

即使通告结构正确，“可用”仍需要时间、粒度和责任主体。并发事务可以先一步占用资源；链路聚合可以抹掉决定成败的内部瓶颈；过滤与传播延迟也会制造不完整视图。地图可以对自己的快照负责，却不能替未来事务签字。

虚拟链路是一张待执行的期权

如果预先建立所有底层 LSP，没有上层流量时也会占用带宽和适配资源。RFC 5212 因而允许一个底层 LSP 的“可能性”像已建立的 TE 链路一样向上通告，而不真正建立它。这就是虚拟 TE 链路。

这种设计不是欺骗，而是受控的按需承诺。上层拓扑可以保持稳定，资源只在实际请求选择虚拟链路时创建。文档要求：一旦上层 LSP 使用这条虚拟链路，底层 LSP 必须立即发起信令。

管理风险来自删掉“虚拟”二字。已选择只说明下一笔事务必须发生；已触发只说明请求已经发出；底层 LSP 已建立还没有说明连通性和数据完整性通过验证；验证通过也不自动证明上层全程安装完成，更不证明客户流量已经获得目标服务。

诚实的控制台必须分别显示：候选已计算、资源待定、资源已承诺、底层已验证、上层已安装、业务已观察。一个绿色图标无法同时承担六种证据。

抽象会把共同故障也折叠掉

底层 LSP 建立后，可以作为 TE 链路或 Forwarding Adjacency 通告给上层。多个上层 LSP 能嵌套其上，形成供客户层使用的 Virtual Network Topology。这样，上层不必理解服务层的所有内部路径。

简化同时带来信息损失。RFC 5212 指出，看似分离的两条光路可能共用同一根光纤，因而会在一次切断中同时失败。如果共同风险没有越过抽象边界，上层算出的“多样性”只存在于图上。

这不意味着服务层必须公开所有内部拓扑。规模、自治和商业隔离都需要抽象。真正不能丢的是会改变决策的属性：共同风险组、有效容量、保护状态、验证状态、告警映射，以及谁有权承诺或释放资源。

管理边界也应遵循相同原则。底层提供者可以隐藏跳数，但仍应返回有范围的资源承诺、验证结果、风险类别和告警关联标识。保密不等于让上层猜测一条线究竟代表什么。

RFC 5339 没有替部署作答

RFC 5339 随后评估了当时已有的 GMPLS 协议能否满足 RFC 5212。它没有得出“已经全部解决”或“完全不能使用”这两个简单结论。大量功能依赖本地流程、运营商策略、TE 算法和协议范围外的管理工具。

评估列出六类扩展：虚拟 TE 链路的建立与删除、TE 链路的平滑删除、受约束的多区域信令、混合节点适配容量通告、分层 MIB 的协同，以及对技术专用 OAM 的控制与配置。

其中的适配容量例子非常重要。不做链路捆绑时，分开的通告还能显示内部适配资源的上限；捆绑之后，总量数字可能看起来很大，却无法告诉计算者该节点其实不能终结所请求的 LSP。算术没有造假，语义结构丢失了关键约束。

这是一份 2008 年的评估，不能据此判断今天所有实现。它提供的是证据纪律：需求文档、协议扩展、本地算法和生产执行各属于不同层，任何一层的引用都不能替另一层出具回执。

信令成功以后仍要验证

RFC 5212 说，底层 LSP 在作为数据链路交给上层之前，可以验证正确连通性和数据完整性。具体验证方式依赖数据平面技术，GMPLS 协议应当协调验证。RFC 5339 也把跨层测试协调视作运营事项。

因此，信令完成只证明控制事务完成。技术验证回答链路是否正确。上层信令回答客户路径是否安装。探针与计数器回答流量是否使用了预期路径。最终，客户观察回答服务目标是否实现。

分开保存这些结果，事故排查才有落点：是 TED 过期、触发失败、底层交叉连接错误、上层安装缺失、OAM 告警没有跨层映射，还是安装后的数据平面发生偏离。若只剩一个绿色状态，各层都可以局部正确，业务却无处可寻。

一份能穿过层边界的回执

回执从请求开始：端点、带宽、优先级、交换能力、保护和服务目标。它冻结计算所用的 TED 快照，记录快照年龄、通告来源、过滤与缺失信息，并列出每一次层或区域转换。

每个抽象跳都要注明：物理链路、已建立 FA-LSP、真实 TE 链路，还是虚拟 TE 链路。每个混合节点要保存所需适配功能、可用容量与预留纪元。策略决定和管理批准必须与触发事务关联。

执行阶段继续串联底层信令、服务层路径、资源承诺、交叉连接状态、通告传播、连通性验证、上层安装、OAM 映射、共同风险、数据探针与用户观察。释放同样需要回执：已经拆除的资源若仍留在 TED 中，就会制造与虚拟链路相反的幻象。

来源