摘要

  • RFC 1070 把完整的 OSI 网络层 PDU 封装进 IP，借现成 Internet 测试尚不成熟的 OSI 路由协议，又不去改动既有 IP 网关。IP 在这里提供底层子网，而不是替 OSI 决定逻辑拓扑。
  • IP 可达、NSAP 可映射、列入 core.EON、进入本地 SNAcP 缓存以及声明 ES/IS 角色，是五种不同的事实。文档中的清单滞后案例表明，物理连通不变时，上层成员关系仍可能短暂失真。

RFC 1070 开篇就给实验划了红线：这些方法只适合有限规模的试验，不适合运行环境。1989 年，OSI 网络层协议的成熟程度不一，真实路由交换还缺少足够广、足够动态的测试场。若把尚不稳定的实现装进现有 Internet 网关，实验越逼真，干扰工作网络的风险也越大。

提案于是反过来使用已经存在的连通性。完整的 CLNP、ES-IS 或 IS-IS 数据单元被装进 IP 数据报；站点内部仍可直接在本地链路上运行 OSI，只有跨越 IP 网关时才借用 Internet。文档把这个底层叫作 “IP subnet”，把建立在它上面的实验叫 EON，即 Experimental OSI-based Network。

IP 地址回答“送到哪”，不回答“它是谁”

RFC 1070 特意指出，一个参与站点里的许多系统都可能经 IP 可达，但实验者只会把其中一部分配置成 EON 的直接连接者。机器可以是 OSI 终端系统 ES、中间系统 IS，或同时承担两种角色；角色随时可以改变，而 Internet 上的物理位置不必改变。

直接 EON 把每个 ISO-gram 放进 IPv4 数据报的数据区，协议号为十进制 80。设计者希望由 OSI CLNL 做分片，以便真正测试该层，但 Internet 途中仍可能发生 IP 分片，所以目的主机也必须具备 IP 重组能力。收到某个 IP 分片，最多证明底层观察到一段数据；它不能替代上层 PDU 重组、校验、接纳或转发的证据。

地址格式延续了 RFC 1069 的框架，把四字节 Internet 地址嵌在 EON 的 NSAP 末段，后面再接 NSAP selector。这样可以算法化推出 IP 子网上的 SNPA。初始 LOC-AREA 为零，路由域号由 IANA 分配。这个映射省去了另一个查找步骤，却没有把一个地址变成 ES、IS、单跳邻居或可用路由。

提案的非目标同样清楚：它不追求任意 NSAP、不要求所有人先实现全部 OSI 路由协议、不拿现有 IP 路由算法替 ISO-gram 选路，也不打算建设大规模生产环境或处理 IP-to-CLNP 网关。Internet 提供传送条件；实验仍坚持自己的地址和路由语义。

SNAcP 用复制和本地角色模拟广播

ES-IS 与 IS-IS 假定广播子网具有“所有 ES”和“所有 IS”这类组播语义，底层 IP 并不会自动替 EON 提供这两组成员。RFC 1070 在 OSI CLNL 和 IP 之间放入一个小层，称为 SNAcP。

每台参与机器的 SNAcP 保存一张缓存：哪些 Internet 地址在本机看来属于一个 ISO 8473 跳以内的 core systems。单播只发一份；发往所有 ES、所有 IS 或广播时，SNAcP 为缓存中的地址逐一复制 ISO-gram。它在前面加上版本、地址语义与 Fletcher 校验和。收到数据后，单播和广播总会进入上层；“所有 ES”或“所有 IS”是否被接收，则由本机当时配置的角色决定。

因此，这张“广播网”并不是底层天然存在的共同对象。发送者以自己的缓存定义复制范围，接收者以自己的角色决定接纳。发完所有副本，不能证明缓存没有漏人；一台机器收下 all-IS，也不能证明别处已经学习到它的路由。

来自 ICMP 的错误还会经过本地政策改变这张逻辑图。目的不可达、参数问题或超时可使缓存地址被标为不可用；source quench 可使它暂时不可用。所谓“通知网络管理”甚至可以只是打印、计数、写日志，或什么也不做。SNAcP 会在模拟组播时跳过不可用地址，对相应单播向 OSI CLNL 返回错误。底层信号只有被本机解释之后，才成为上层邻接状态。

core.EON 是启动种子，hosts.EON 只是名册

路由交换要先找到交换对象。RFC 1070 因而让 IANA 维护四份文件。core.EON 与 core.EON-UDP 保存两个实验中被视为单个 ISO 跳可达的 SNPA 地址，供 core system 启动时形成初始缓存。hosts.EON 与 hosts.EON-UDP 罗列参与的终端系统，方便应用和人查阅，文档明确说 OSI CLNL 不使用它们。

即便进入 core.EON，也不能推导这台机器是网关或 IS。它可能只是 ES，也可能兼任两种角色。反过来，一个新 core system 可以在条目尚未分发时开始参与，只是其他系统重启后不知道向它发送 ESH、ISH 等配置消息。清单表达启动时的逻辑联系，不是实时角色真相；主机名册连这个作用也没有。

文档虚构的 Fordor 场景把差别表现得很直接。192.5.2.1 原来是 core system 和 IS，192.5.2.2 原来是 ES。两者对调职责，但 Internet 连通性完全不变。如果实验者没有立即通知 IANA，其他 core systems 仍按旧 core.EON 向 .1 发配置消息，而 .1 现在只以 ES 回应；它们又不知道该主动联系新的 IS .2，于是 .2 在 EON 拓扑中像是不可达。

等 .2 启动并用 OSI 路由交换宣布自己，其他 IS 才回应并更新缓存，新的逻辑链路随之建立。修复的不是电缆，也未必是 IP 路由，而是清单、角色声明和学习状态之间的缺口。

EON-UDP 是另一项并行实验

有些实现者能调用 UDP，却不能直接访问 IP 层。EON-UDP 把 OSI NPDU 放入 UDP 的 147 端口，并把 SNAcP 放在 UDP 与 ISO 8473 之间。其余试验规则相似，但 RFC 1070 明说，两种参与者不能直接互通。理论上可以另建网关，设计和路由问题却不在本文档范围内。它们有各自的 core 与 hosts 文件，是受不同实现条件约束的两张实验网。

这也解释了 RFC 1070 与邻近方案的边界。RFC 1006 让 OSI session 及更高层在 TCP/IP 上运行；RFC 1070 则把 OSI 网络层与传输层放到 IP internetwork 上。RFC 1069 借 Internet 路由和地址转发 CLNP，RFC 1070 要测试的恰是 OSI 路由和地址。都“运行在 Internet 上”，并不表示它们测试同一层。

来源与限度

RFC 1070 是实验提案，Fordor 是假设拓扑。它们能证明设计者如何区分底层、地址、清单、缓存与角色，不能证明 EON 大规模部署、投入生产，或直接演化成某种现代覆盖网。RFC 994 与 RFC 995 给出同期 CLNP 和 ES-IS 规范，也不能替任何具体实现出具合格证明。

真正留下来的历史边界很窄：一张网络可以成为另一张网络的链路，却不会自动获得后者的成员、角色与路由事实。同一个包同时经过两层，也不意味着两层的记录可以互相代替。