摘要

  • TALI 2.0 必须先把新连接的对端视为 1.0；只有收到标明版本 2.0 的 moni 消息，才能开放发送新的 opcode。
  • RFC 3094 是 Tekelec 发布的 Informational 提案；IESG 注记明确指出它是 SIGTRAN 标准轨道工作的替代方案，而 IETF 并未审查其技术健全性或完整性。

边界在第一条 SS7 消息发出前就已经出现。RFC 3094 描述 Transport Adapter Layer Interface（TALI），这是 Tekelec 为电路交换网络与 IP 网络之间传送信令提出的接口。信令网关可以通过 TCP/IP 承载 SCCP、ISUP 和 MTP 相关消息，并提供管理与电路动态注册能力。文档详细规定了消息格式、定时器、对端状态以及 TALI 1.0 和 2.0 的差异。但细致的规范仍然只是规范，RFC 首页也明确了它的地位。

IESG 注记把 TALI 定位为供应商提出的替代技术，当时 IETF 的 SIGTRAN 工作组正在制定标准轨道技术。注记说明 IETF 没有审查该提案的技术健全性或完整性，并建议潜在用户在作决定前也考察 SIGTRAN。它没有说 IETF 认定 TALI 不健全、正式拒绝了它，或证明它从未部署。注记限定的是审查范围，并给出比较建议。

TALI 最具体的工程问题是向后兼容。1.0 没有简单的版本识别方式；2.0 复用既有的 moni（监测）消息，在其中固定 12 个字节作为版本标签，后续数据仍可由具体实现自行使用，整个数据部分仍不得超过 200 个字节。moni 也继续承担回显用途，可用于测量往返时间或执行本地任务。

这个标签决定对端可以发送什么。连接建立时，2.0 实现把 far_end_version 初始化为 1.0。它可以报告自己的版本，却不能因为本地软件支持 2.0 就推断远端也支持。实现必须检查收到的 moni 并识别已知版本字符串；如果识别消息没有到达或标签不匹配，远端就继续按 1.0 处理。

状态变量控制三个 2.0 新 opcode：mgmt、xsrv 和 spcl。1.0 节点会把它们视为无效消息并立即关闭 socket。因而，2.0 节点必须先确认对端为 2.0 或更高版本，才可发送这些 opcode；若对端是 1.0，就回退到 1.0 功能。RFC 还规定，1.0 实现可以忽略 moni 新增的数据部分，照常进行监测与确认。兼容性并不表示两端都理解每项功能；它规定的是如何保持连接可用，而不把旧对端无法处理的 opcode 发过去。

这不是抽象的“向后兼容”口号，而是可观察的控制面：本地实现声明版本，远端提供证据，状态机记录声明，opcode 门控决定哪些能力可以穿过 socket。文档印刷的版本号或本地配置都不能替代实际收到的对端声明。

周边标准历史也需要同样谨慎地解读。RFC 2719 已描述 SIGTRAN 架构；之后的标准轨道文件规定了 M2UA、M3UA、SUA 等适配层，SCTP 也成为相关工作使用的传输方式。RFC 3094 本身还讨论 SCTP 替代协议栈。这些文档证明了相关的平行或后续规范工作，却不能单独证明 TALI 被替代、某个网络完成迁移，或任意两种实现实现了互通。

RFC 3094 发布于 2001 年 4 月，类别为 Informational，并明确声明它不定义互联网标准。出版、机制说明和审查边界是三件不同的事。状态机写得完整，不等于部署过；IESG 的警示也不等于技术失败。若要对部署或质量作判断，还需要运行实现、测试结果、运维记录或实际流量等证据。

来源