摘要

  • RFC 1992 预期大型互联网中的路由数据库经常不完整、不一致：提供者可限制信息发布，接收者可选择性保留，内部地图可因请求者不同而不同，缓存也可能陈旧。
  • 特殊约束路径由用户或代理承担信息获取与计算成本；单一设备算出的既定路径可避免不一致逐跳判断形成环路，却不证明地图正确、策略公平、资源兑现或系统已部署。

一张全球地图最令人安心的地方，也是它最昂贵的地方：每个参与者都要拿到足够完整、足够新、足够一致的副本。RFC 1992 面对的是一个被设想为十亿级网络、服务各异、资源有限的互联网。它没有承诺把副本做得更大、更快，而是先取消了这项共同义务。

Nimrod 的地图是一张由节点和有向邻接组成的图，描述可用连接、服务条件与使用限制。同一片物理网络可以在一张地图里缩成一个节点，在另一张地图里展开为内部结构。节点代表甚至可以针对不同请求返回不同内部地图，例如出于安全考虑。文档因此明确说，不要求不同路由器拥有一致地图。

这不是对错误状态的消极容忍，而是规模设计的起点。关键问题从“怎样让所有人知道一切”变成“谁需要知道什么、保存多久、为哪一种路径付出多少成本”。

分层不是无损压缩

第一层工具是聚类。主机、路由器、网络与已有聚类可继续组合，形成一棵最终由通用顶层聚类包住全部对象的层级。每层不必使用同一种聚类算法，逻辑边界也不必贴合任何物理设备边界。最低共同条件只是：当组成元素可运行时，聚类内部任意两点之间至少存在一条不离开该聚类的路径。

第二层工具是抽象。聚类减少“能看见多少对象”，抽象减少“每个对象要描述多少内容”。RFC 1992 给出的例子很诚实：可以删去只有少数元素提供的服务，也可以用平均值概括多种服务。这些做法会缩小地图，同时也可能抹掉恰好对某个特殊业务最重要的信息。

因此，抽象地图不是自动错误，却一定有适用边界。若路径只需要普通可达性，平均描述也许够用；若它要求某个稀有时延、带宽或访问条件，被删除的少数能力就可能决定成败。地图越轻，计算者越应知道它没有包含什么。

第三层工具是受限发布。每个聚类决定发布哪部分信息、发给哪些对象。第四层则在接收端：接收者决定收到什么以后真正保留什么。前者可能为了隐藏内部结构或服务政策，后者可能为了内存、处理能力或本地相关性。最终数据库都少了一块，但信息缺失的控制者并不相同。

第五层是缓存。已经取得的信息可以重复使用，以省去下一次查询的带宽和等待。RFC 同时警告，缓存可能过时，并由此产生质量较差的路径。缓存期限不是无关紧要的性能参数，而是计算依据能否代表当前网络的时间边界。

谁要特殊路径，谁承担复杂度

满足多重约束的路径生成通常是 NP-complete 问题。Nimrod 的答案不是让每台路由器持续承担这项负担，而是把计算放到需要它的一方。用户可以自己决定，实际更可能由代理设备代为获取地图、运行算法并选择路径。

不同地点无需采用相同算法，也不必等待全球协调后再升级。某个用户若需要保证吞吐、限定时延、避开某类服务提供者或满足用途限制，可以投入更多信息与算力；不需要这些条件的流量不必支付同样成本。这既是一种部署策略，也是一种成本归属设计。

但“需求方付费”不能被写成公平证明。信息提供者仍决定什么可见。算力无法恢复从未披露的内部链接，昂贵算法也无法把粗粒度平均值还原成被删去的稀有服务。掌握更多地图、预算或议价能力的用户可能拥有更好的选择。Nimrod 分散了算法权力，并未消除信息权力。

为什么一处计算能阻止一种环路

地图不一致最危险的组合方式，是每个路由器都根据自己的视图重新决定下一跳。A 认为出口在 B，B 又认为出口在 A，两个局部判断都可能自洽，合在一起却变成环路。

RFC 1992 的路径式转发改变了组合规则。一个设备根据自己维护的那份信息算出完整决策，后续转发执行这项结果，而不是让每一跳再从另一份地图独立改写方向。其他路由器的数据库仍可不同，但它们不会在这条已选路径上轮流投票。

具体状态并非总在包内。Flow mode 的包携带 path-id，索引此前沿途安装的状态；建立请求还能携带带宽、时延等资源要求，并得到成功或失败响应。CSC 与 CSS mode 通过有序的 connectivity specification 表达路径，包里只有选路结果，不包含选择标准。Datagram mode 则利用预设的 flow 状态形成严格无环的路径，同时不采用 IPv4 式源路由。

所以，把 Nimrod 概括为“所有包都带源路由”并不准确。它研究的是如何在包与路由器之间分配既定路径状态。共同点是路径已由单一计算者形成，而不是每跳临时拼接。

这也限定了“无环”的证据强度。它能说明不同路由器的下一跳认知不会在该路径上组合成环，却不能说明计算者那张地图正确。链接可能已经失效，缓存可能太旧，状态可能没有完整安装，提供者也可能无法兑现公告中的服务。没有兜圈，不等于已经到达；建立成功，不等于持续获得所需 QoS。

已认证地图仍可能误导

RFC 1992 的 Trust 一节没有把认证当作终点。节点可以隐藏内部地图，只需对外符合自己的公告描述；但文档示例表明，公告可能让人以为流量不可被另一节点观察，而物理网络实际上不能强制这种隐私。即使节点值得信任、收到的信息也经过认证，仍可能存在诚实错误。

这使证据链必须拆开：谁发布了地图，传输中是否被改动，地图采用何种抽象，信息何时有效，算法如何解释，路径状态是否安装，数据包是否经过，应用是否获得结果。来源身份只能回答前两项中的一部分，不能替后面的现实作证。

安全边界更加直接：RFC 1992 的 Security Considerations 明说本文不处理安全问题。它不能证明地图认证、授权、完整性、保密性或抗攻击性，更不能把“出于安全而返回不同地图”推导成“这些地图已经安全”。

架构文档不是部署清单

RFC 1992 的状态是 Informational，并说明协议与分布式数据库的具体规范位于其他文档。RFC 1752 记录，IESG 当时认为 Nimrod 过于偏研究，不适合作为 IPng 候选；RFC 1753 也拒绝预设广泛采用，因为相关设计尚未经过部署、实践与验证。到 RFC 2102，单播路由生成仍留给具体 routing agent，多播的路由生成与转发机制则都没有固定。

这组材料能证明一项研究架构如何定义取舍，不能证明互联网采用了它，也不能证明某款产品实现了它。卢恒所说的“本地未来决策”有助于理解算法为何可在不同地点演进；“运行代码优先”则把采用证据留给实现与运行。“现实层次”进一步提醒：地图是声明，路径状态是执行条件，真实包流与业务结果是后续层次。

RFC 1992 最值得保留的历史判断，是它拒绝用全球全知换取安全感。Nimrod 没有让残缺地图变得正确；它只是让一条路径的转发不必汇总每台路由器的不同错误。它把环路问题缩小了，同时把信息质量、计算成本、服务政策与运行结果留在各自必须举证的位置。

来源