摘要

  • draft-ietf-nmop-simap-concept-13 允许客户端从一项服务沿 supporting relationships 下探到逻辑与物理资源，也能从资源反查依赖它的服务。
  • 返回结果只证明某个 SIMAP 服务器在特定时间、来源、抽象层级与访问权限下展示了什么；完整性、同步状态、因果关系、决策权、实际执行与最终效果都需要独立证据。

运营人员在故障现场最想要的，往往是一条短路：点开某台设备，就知道哪些业务会受影响；点开某项业务，又能一路看到它经过哪些逻辑层、承载链路和物理设施。SIMAP 的价值，正在于把这种原本散落在控制器、资产台账、保障系统和工程师经验里的关系，组织成可以双向遍历的拓扑图。

但图越顺畅，越容易让人高估它。一次查询可以完整返回，也可以在语法和权限上完全合规，却仍然只是服务器对网络的一种表达。它可能经过授权裁剪，可能使用抽象节点，可能引用不同时间采集的外部数据，也可能描述计划、被动设施或某个历史快照，而不是此刻生产网络的全部状态。

当前依据是2026年9月4日发布的 draft-ietf-nmop-simap-concept-13。IETF Datatracker 将其列为 NMOP 工作组的有效 Internet-Draft，拟定状态为 Informational。文档历史 显示，它在9月12日进入 IETF Last Call，意见征集截止9月26日。它还不是 RFC，内容仍可能调整。

同一条关系，可以回答两个方向的问题

SIMAP 的核心实体包括 network、node、link 和 termination point。关系既可存在于同一层内，也可跨层连接。服务到资源的查询，从选定服务向下走，找到服务所使用的逻辑资源，再沿支撑关系抵达物理资源。资源到服务的查询则从物理、二层或三层资源出发，向上找出依赖它的服务及相关节点、端点和链路。

这种双向性比一张设备清单更有用。它让“某条链路失效会影响谁”成为结构化问题，也让容量规划、故障隔离、性能监测和计费有机会共享同一组依赖关系。RFC 8345 已经定义了 supporting network、node、link 与 termination point 等 YANG 关系。SIMAP 在此基础上扩大运营语境，把服务层、基础设施层与外部模型连接起来。

连接并不等于收编。容量、运行状态、性能、库存、配置、保障和可观测数据可以保留在 SIMAP 之外。地图提供到这些模型的入口，但外部记录仍有自己的标识体系、采集时间和可信边界。把三个系统中的同名对象连在一起，并不能自动证明它们指向同一实体、同一时刻和同一事实层级。

看不见的层，不等于不存在

草案明确说明，客户端只能取得它被授权看到的内容。服务器可以基于安全、管理或商业理由隐藏某些层，也可以用抽象层代替原生拓扑。对该客户端而言，这样的结果可以是正确答案；对整张网络而言，它却不一定是完整答案。

因此，查询结果中没有某个节点，不能推出网络里没有该节点。一个抽象节点可能代表多个原生设备；一条逻辑链路可能遮蔽两条具有不同共同故障风险的物理路径；服务客户可以获得排障所需关系，却无权看到供应商内部设施。访问控制定义了答案的边界。

跨层导航与跨抽象层级导航也不能混为一谈。前者回答“三层链路由哪条二层或光层路径承载”，后者回答“这个抽象节点代表哪些原生节点”。一张查询收据若只写“返回了三层拓扑”，仍无法说明它的粒度与隐藏范围。

“实时”仍然要带时间戳

第13版把 live topology 定义为真实网络的最新快照，并要求实现执行初始、按需发现以及同步，从而提供更新的分层拓扑。这些是实现应满足的要求，不是每次 API 返回成功时自动生成的合规证明。

同一个框架还要支持历史快照、潜在拓扑、预期拓扑和被动拓扑。预期拓扑表达想要实现的结构，可能不列出中间跳点和设备；被动拓扑可能包含无法从网络协议自动发现、只能人工记录或从外部资产系统取得的设施。节点状态和历史变化也可以存放在 SIMAP 内部，或仅由它链接访问。

把这些视图放在一起比较之前，必须先回答五个问题：是哪一个 topology instance，属于哪一类视图，来源是谁，描述哪个时间点，已知同步状态是什么。缺少这些限定，“live”只是类型名，而不是新鲜度证据。

依赖关系不是事故原因

当资源到服务查询返回六项业务时，它证明的是这六项业务在所查实例中被表示为依赖该资源。它不证明这台设备造成了六项业务故障。资源可能位于备用路径，可能参与负载分担，关系可能已经过时，状态也可能在快照后发生变化。业务故障还可能来自完全不同的因素。

因果判断需要另一组证据：资源何时改变状态，流量或服务何时出现相容变化，替代解释如何被排除，干预之后是否恢复。SIMAP 可以为调查提供结构，却不能用图上的邻接关系替代时间顺序与实际观测。

写入地图，不等于改动生产网络

草案还划出一条重要边界。SIMAP API 可以有读写操作，但写入拓扑并不是通过控制器北向接口直接改变生产网络。写操作主要服务于 what-if 分析、仿真，以及无法自动发现的预期或被动拓扑。真实网络变化仍要通过常规控制器操作完成。

这意味着自动化链条至少要保留四份相互独立的凭据：用于判断的地图或方案；允许采取行动的策略与责任主体；控制器或设备实际收到的操作；变更后的网络与服务观测。地图写入成功，只能证明模型事务被接受，不能证明设备已执行，更不能证明业务已恢复。

闭环同样如此。SIMAP 可以支撑监测与分析，但完整闭环还包括纠正动作、执行权限和反馈。没有变更后的独立观测，系统最多知道自己推进了流程，不知道网络是否真的变好。

给关键查询留下“视图收据”

影响生产决策的查询，应保留服务器与实例标识、模型版本、客户端角色和授权范围、拓扑层和抽象层级、外部来源、采集与快照时间、遍历方向、过滤条件以及同步状态。如果随后采取行动，决策、授权、执行、观测和回退也应分别记录。

这些限定不会削弱 SIMAP，反而使自动化结果可解释、可复核。SIMAP 最有价值的回答不是“这就是网络”，而是更准确的一句：在这些来源、权限和时间条件下，这个服务器展示的依赖关系是这样。

来源

文档正文与状态：SIMAP 第13版及其历史记录。相关基础与控制：RFC 8345、RFC 8341、RFC 8040、RFC 9417和RFC 9408。相关的SIMAP YANG 草案是个人 Internet-Draft，在 IETF 标准流程中没有正式地位。 冻结的源文本：第13版归档。流量工程背景：RFC 9522。