摘要

  • NMOP 工作组 10 月 2 日发布的 SIMAP 概念草案第 14 版，在第 4.3 节新增 REQ-CONGESTION：未来的 SIMAP 协议绑定必须确保自身流量不会造成持续拥塞。第 13 版没有这条具名要求。
  • 草案认为具有拥塞控制的传输方式，例如基于 TCP 的绑定，已在传输层满足这一点。若绑定没有传输层拥塞控制，以 UDP 为例，则部署须限于容量预先配置或预留的受控环境，并限制服务器能产生的流量。这仍是未获批准的 Internet-Draft。

地图是观察工具，但观察也要占用被观察对象的容量。一次大型拓扑查询、频繁刷新，或面向众多客户端的持续订阅，都不会因为用途是“监控”就自动变成免费流量。SIMAP，即 Service & Infrastructure Maps，试图规范服务与基础设施地图的概念及要求。它的最新修订将地图流量的拥塞责任，从隐含的运维常识推到了草案正文。

draft-ietf-nmop-simap-concept-14 在第 4.3 节加入 REQ-CONGESTION，要求协议绑定避免 SIMAP 流量造成持续拥塞。与 9 月的第 13 版对照，这是一项新增条件，而不是既有性能段落的改名。文本把基于 TCP 等有传输层拥塞控制的绑定视为满足该条件；对于没有这类控制的绑定，它用 UDP 作例子，要求把部署限定在有预留或预先配置容量的受控环境，并对服务器发出的数据量设限。

这并不等于“IETF 禁止 SIMAP 使用 UDP”。草案没有指定唯一协议，没有给出每秒请求数或带宽阈值，也没有举出已经运行的 UDP 版 SIMAP 或实际拥塞事故。相反，它为未来绑定划了一道条件边界：如果无法依靠传输层调节拥塞，就必须从部署范围、容量保障和服务器输出三处承担责任。使用 TCP 也只是满足这里的传输层条件，不代表整套地图在准确性、权限或可靠性上自动合格。

容易混淆的是草案早已有 REQ-PERFORMANCE。它希望大型拓扑能够按增量、过滤条件或分页获取，并在适合时支持流式传输或订阅。这些办法解决的是访问效率与响应方式。分页不阻止客户端以过高频率翻页；订阅也不保证总量始终低于线路容量。第 14 版新增的拥塞条款，正是要把“少搬无用数据”与“不给网络制造持久拥塞”分成两张验收表。

新条款引用的 RFC 8085 是 UDP 使用方面的既有指导。UDP 本身不内建拥塞控制，应用需要承担相应责任；受控环境也与开放互联网不同。SIMAP 草案不是重新发布了这份 RFC，更没有据此证明某种产品已经违规。Datatracker 当前显示该工作组草案拟作为信息类 RFC，处于等待 Area Director 后续处理的阶段；这不是标准已经获批的表述。

因此，接受一个地图方案时，至少应分别看三类证据：数据是否及时，拓扑覆盖是否足够，以及在预期查询、订阅和拓扑规模下，自身到底产生多少流量。若绑定缺少传输层拥塞控制，还应明确受控环境的边界、已经保障的容量以及服务器输出上限如何执行。这是一种基于草案要求的编辑性验收框架，不是 IETF 发布的认证测试，也不是要求现网马上切换协议。

地图的可信度不仅来自它画得准，也来自它不会为求画得准而让网络失去余量。谁有权给观察系统分配流量预算，成为这次修订真正提出的治理问题。

来源