摘要

  • RFC 9730 的核心不是以集中式控制取代 GMPLS，而是定义两类控制机制如何共存：控制器可进行跨域协调、抽象和路径计算，GMPLS 网络元素仍可承担域内发现、RSVP-TE 信令、标签分配以及快速保护与恢复。
  • 在这种协同模型里，“控制器已经接受请求”“域内 LSP 已建立”“PLR 已完成局部切换”“客户业务恢复”是四种不同事实。它们可能先后发生，也可能部分成功、部分失败，因此必须保留分层证据，不能用单一控制器状态代替端到端运行事实。

RFC 9730 真正改变的，是责任边界的可见度

RFC 9730 于 2025 年 3 月作为 IETF Informational RFC 发布，题为《Interworking of GMPLS Control and Centralized Controller Systems》。它所描述的不是一场“集中式对分布式”的替代，而是现实网络中两种控制方法的互补关系。

GMPLS 的基本逻辑仍然成立。网络元素可以收集节点和链路状态，形成 Traffic Engineering Database（TED），按照本地策略进行受约束路径计算，并通过 RSVP-TE 沿路径逐跳分配标签和建立交叉连接。路由决策不必全部来自远端控制器，设备也不是只执行静态命令的无状态终端。

集中控制器则在另一个层面工作。RFC 8453 所定义的 ACTN 架构把客户网络控制器 CNC、多域服务协调器 MDSC 和配置网络控制器 PNC 分开。MDSC 处在业务请求与域资源之间，负责映射和翻译业务需求、协调多个域，并处理抽象资源视图；PNC 更靠近网络元素，负责配置、监控，并向上暴露原始、缩减或抽象后的拓扑与资源信息。

这意味着“集中计算”并不等于“逐跳集中配置”。控制器可以选择一条路径，甚至预先计算保护路径，然后通过 PCInitiate 或 NETCONF 把建立请求交给入口节点。此后，RSVP-TE 仍可在网络元素之间运行，完成实际 LSP 建立。控制器决定的，是约束、路径或触发；设备执行的，则可能仍是分布式信令和资源编程。

对运营治理而言，这一点非常重要。若不区分“谁算出了路径”与“谁真正建立了路径”，系统很容易把控制意图误认为运行事实。

一个跨域图，可以是全局的，也可以故意不完整

ACTN 的抽象设计提供了可扩展性，却同时引入了证据解释问题。MDSC 可以从多个 PNC 获取拓扑信息，形成跨域视图；但 MPI 上传递的并不必然是每个域的完整内部状态。它可以是受策略过滤后的抽象，隐藏内部节点、链路或资源细节，只保留业务计算所需要的连通性、带宽和约束。

因此，“MDSC 拥有全局拓扑”不能自然推导为“MDSC 知道每个域内所有实时细节”。一个域可以把内部复杂网络压缩成几个抽象节点或边。对跨域路径计算而言，这可能已经足够；对解释某次故障中到底是哪条内部链路被占用、哪个标签无法分配，却可能远远不够。

RFC 9730 还允许网络元素和控制器拥有不同粒度的状态：原始状态、缩减状态、抽象状态。这些状态也可能运行在不同时间尺度上。标准没有给出一个对所有实现都有效的“状态必须在多少毫秒内刷新”的统一上限。

所以，拓扑版本与时间戳不能被视为装饰字段。它们决定了一次计算究竟基于什么信息。控制器选出的路径在计算时可能完全合理，但在提交到入口节点时，域内资源已经变化；反过来，设备本地 TED 也可能因路由传播或策略原因尚未反映上层看到的变化。

合理的证据链至少应保留：MDSC 下发的业务请求与约束、使用的抽象拓扑版本和抽象策略、PNC 对请求的响应、路径或路径分段、所假定的链路或风险组不相交关系，以及最终的重路由命令确认。只有这样，后续审计才能判断问题出在计算、状态陈旧、策略差异，还是执行阶段。

路径“由谁计算”并没有唯一答案

RFC 9730 的互通场景允许路径计算位于不同位置。它可以在集中控制器，也可以在入口节点及其 TED 中完成，还可以由 PCE 完成。

经典 PCE 模式中，PCE 负责返回计算结果，PCC 决定是否以及何时部署该路径。这是一种“建议与执行分离”。状态型 PCE 和 PCE-initiated 模式则向前推进一步：PCE 可以通过 PCInitiate 触发 LSP 的建立或删除，并通过后续状态报告了解执行结果。

即便如此，PCInitiate 的存在也不能把整个建立过程压缩成一条“控制器已完成”的记录。RFC 8281 明确描述了 PCE 向 PCC 发起 LSP 创建，PCC 随后建立 LSP，并以 PCRpt 报告状态。对于 RSVP-TE 建立方式，入口 PCC 之后还要完成 Path/Resv 等实际信令和资源处理。

因此，从证据角度看，至少应把以下事实分开：

第一层是控制器请求事实，包括 PCInitiate 或 NETCONF 请求是否到达、约束是什么、ERO 或路径信息是什么。第二层是域内信令事实，包括 RSVP Path、Resv、错误返回和标签分配。第三层是数据面编程事实，包括交叉连接和标签状态是否真正安装。第四层才是控制器对该 LSP 的状态认知，例如 PCRpt 或同等状态报告。

任何一层都可能出现“已接受但未完成”的中间态。

多域建立不是一种机制，而是一组可组合方法

跨多个域建立端到端业务时，RFC 9730 并不规定只有一种实现。

一种方法是端到端 RSVP-TE：源域控制器触发源节点，RSVP-TE 跨越多个 GMPLS 域，由各域边界节点参与域间标签分配。另一种方法是 LSP stitching，把各域内的 S-LSP 拼接起来形成端到端 LSP。还有一种是不建立贯穿全部域的端到端 RSVP-TE 会话，而由每个域的控制器分别建立本域路径段，再通过控制器层协调这些段。

这些模型的差异不仅是协议细节，也直接决定故障责任边界。端到端会话里，一个错误可能沿 RSVP-TE 路径传播；分段模型里，每个域可能分别成功，但段与段之间的标签、连接或边界协调仍可能失败。

因此，运营系统不能只记录“业务 ID 对应一条路径”。它还需要知道这条业务由哪些段组成、每个段由谁控制、域间标签由谁分配，以及是否存在端到端 RSVP-TE 状态。否则，一次跨域故障会很快变成“所有控制器都显示成功，但客户仍不通”的灰区。

故障发生时，局部速度与全局协调形成接力

恢复场景最能体现 RFC 9730 的设计取向。

对于 span protection，也就是相邻节点之间的链路保护，RFC 9730 没有重新定义新的保护要求，而是沿用既有 GMPLS 恢复机制。APS 或 GMPLS Notify 等分布式机制能够在靠近故障的位置完成更快切换，而不必等待集中控制器先感知、计算再下发。

在快速重路由里，同样要区分“计算”“创建”和“检测/切换”。控制器可以提前计算保护路径；RSVP-TE 可以建立 detour 或 bypass；真正发生故障时，PLR 在本地检测并把流量切换到保护路径。把三件事合并成“FRR 已配置”会掩盖最重要的运行差异：路径可能算出来却未建立，保护 LSP 可能已建立却不可用，PLR 也可能在故障发生后没有真正切换。

RFC 4873 的 segment recovery 提供了另一种局部恢复方式。branch node，也就是与 PLR 类似的修复点，可以建立独立的 recovery LSP 到 merge node。branch 和 merge 的选择可以是动态的、本地的；如果无法建立恢复路径，则必须把失败向上报告。这里再次显示出一种边界：本地节点可以先尝试修复，但它必须把“不能修”的事实交回更高层。

单域能自救，并不代表多域服务已经恢复

单域内，如果已有替代资源，GMPLS 域可以尝试 segment rerouting。集中控制器也可以预先计算保护路径，或在故障后为单域刷新备选路径。

但“刷新了一个备选路径”不等于路径一定是新鲜的。实际新鲜度仍取决于故障报告何时产生、PNC 何时处理、状态何时进入控制器存储、MDSC 何时计算，以及入口节点最终使用的 TED 或头端状态是否同步。

当单域段重路由失败，例如域内资源不足，或者故障发生在域间链路，责任就上升到多域层。RFC 9730 描述的流程是：结果从 GMPLS 域报告到 Controller(G)，再向 MDSC 或多域协调层传播；上层随后可以计算跨域替代路径，并触发新的多域重路由。替代路径甚至可以经过原业务从未经过的新域。

这是一种典型的“局部先处置、全局再协调”的接力，而不是主备控制模式的二选一。

并发恢复会带来新的状态问题

RFC 4426 区分 span、segment 和 end-to-end recovery，并允许多个恢复层级并发存在。这提高了生存能力，却也意味着恢复动作本身可能互相影响。

局部保护可能已经切换业务，而端到端控制器仍在计算新路径；segment recovery 可能建立了恢复 LSP，而更高层又因为收到资源不足或域间故障报告启动跨域改道。保护动作还可能伴随抢占与回切。一次恢复完成后，如果系统自动恢复到原工作路径，回切本身也可能带来第二次扰动。

所以，事件记录必须带“保护范围”。监控系统应知道一次动作是在单链路、单段还是端到端范围生效，也要知道它是保护、恢复还是重路由。否则，多层控制器只看到“LSP changed”，很难判断变化是故障直接结果、局部保护结果，还是更高层重新优化的结果。

四种“成功”，需要四类证据

在 RFC 9730 所描绘的混合控制体系里，最危险的误解之一，是把不同层面的成功压缩成一个绿色状态。

控制器接受成功，只能证明某个请求进入了控制系统并被接受。证据包括请求、约束、拓扑版本、策略、计算结果和命令确认。

域内建立成功，需要域内证据。包括原始 TED 或本地策略计算结果、PCInitiate/NETCONF 接收记录、RSVP Path/Resv 或错误、标签与交叉连接编程，以及 PCRpt 或同等 LSP 状态。

局部保护成功，应有故障检测时间、PLR 或 branch/merge 节点、保护范围、detour/bypass 或 recovery LSP 状态、真实流量切换、资源不足通知，以及可能发生的抢占和回切记录。

端到端业务恢复成功，则必须回到客户边界。最终证据应是端点可达性、性能指标和客户 SLO，而不是某个控制器内部显示“reroute complete”。

这四类证据可以相关，但不能互相替代。只有最后一层能够回答业务是否真的恢复。

控制器失联时，已有业务不应随之消失

RFC 9730 对控制器可靠性的态度相当明确：控制器断开或关闭时，已经建立的服务应继续承载流量，预先建立的保护也应继续工作。控制器冗余、备份或网络元素中的功能备份被视为值得采用的可靠性措施。

这划出了一条关键责任线。控制器可以是计算和协调中心，但不应天然成为现有转发状态的单点生死开关。对于已经部署的 LSP 和本地保护，系统设计应尽量确保它们不因控制层暂时不可达而立即失效。

与此同时，这并不意味着控制器的安全性可以降低要求。恰恰相反，控制器能够看到跨域抽象、发起路径改变、协调恢复，因此是高价值控制点。每个实体仍需要独立的管理、信任与安全策略，包括认证、授权、补丁、监控与防护。

控制器失联时的“继续转发”，和控制器被错误授权时的“错误重配置”，是两类完全不同的风险。前者强调自治和备份，后者强调信任边界和变更权限。

不要把邻近 RFC 当作 RFC 9730 的恢复证明

围绕 ACTN 和网络切片存在多个相邻标准，但它们解决的问题不同。RFC 9731 描述 VN 操作的 YANG 数据模型；RFC 9732 讨论基于 NRP 的增强 VPN 资源框架；RFC 9889 讨论 5G 网络切片如何利用现有 IP/MPLS 技术实现。

这些文档可以共同出现在一个系统中，却不能被当作 RFC 9730 恢复机制的直接证据。一个系统支持 VN YANG，并不能证明其 GMPLS 快速重路由已经工作；一个网络实现资源分区，也不能证明故障后跨域路径已经重新建立。

RFC 9730 本身同样没有规定单一遥测产品、统一的收敛目标或固定“证明格式”。部分非 GMPLS 恢复方式也不在其范围内。工程团队因此需要把标准中描述的角色和协议事件映射到自己的可观测体系，而不是等待一个标准化仪表盘替自己完成证据闭环。

来源