摘要

  • RFC 1223 让 ES-IS 与 IS-IS 运行在没有原生广播、多播的 HYPERchannel 上。
  • 一次协议群发被展开为按配置或学习名单生成的多个副本，并以时间间隔逐个发送。
  • 一个合法 PDU 或一个成功副本，不能证明名单完整、全员收到、邻接形成、路由收敛或数据送达。

上层的一次，底层的多次

1991 年 5 月的 RFC 1223 说明如何在 Network Systems Corporation 的 HYPERchannel 设备上传送 OSI CLNS 与 LLC1。RFC Editor 将它列为 Informational，IETF Datatracker 保留其 Legacy 身份。它是历史设计记录，不是互联网标准，也不是部署证明。

ES-IS 与 IS-IS 假定子网能把一个控制报文送给一组参与者；HYPERchannel 只会协商点到点传送。RFC 1223 明说，特制办法只能解决这些协议的具体问题，不能提供通用多播。

于是“发送一次 Hello”实际包含：选择某一时刻的成员名单、生成多个副本、分别入队、逐份发出、由各接收端处理。上层调用成功只证明调用完成，不能替代后续任何一层。

名单同时来自配置与观察

有真实中间系统时，终端预先配置 IS 名单，发送 ESH 时向每个已知 IS 各送一份。若收到名单外 IS 的 ISH，还应按其保持时间暂存该地址。永久到下次编辑的配置项，与会过期的观察项，是两种来源；合并进内存不等于来源消失。

规范建议副本之间留出间隔，多数系统可取约 0.1 秒，以免挤占正常流量。首个与末个收件人因此可能经历不同队列和链路状态。一个收件人的回执不能代表整批。

IS-IS 需要完整的参与者集合

中间系统也要配置其他 IS 的地址。IS-IS 尤其要求相关 Level 1 或 Level 2 名单完整，不能把参与指定 IS 选择和状态交换的集合切开。发送时，IS 遍历名单并逐个复制；多次传输对 IS-IS 本身保持透明。

RFC 1142 给出当时的 IS-IS 模型，RFC 1195 记录它在 IP/OSI 双环境中的使用，RFC 995 提供 ES-IS 背景。它们都不能替某台机器证明名单快照或实际收件结果。

没有路由器时，地址管理者扮演路由器

若没有真实 IS，一个或多个 SNARE 地址管理者可以对终端表现为 IS。每个终端必须配置全部管理者；冗余增加候选人，却没有取消名单完整性要求。SNARE 记录 ESH、转发报文、返回重定向，是三个需分别观察的动作。

HYPERchannel 不支持 ES-IS 查询配置功能，所以每台系统起步时至少要配置一个真实 IS 或 SNARE。后续学习能扩充种子，不能凭空补回缺失的种子。

RFC 1223 的长久价值，是把抽象的代价暴露出来：群体意图、名单权威、副本生成、节流、传输、接收、拓扑更新与收敛必须分别留证。否则“少了一个成员”既可能是漏配，也可能是过期、排队丢弃、链路失败或收件无效。

来源