摘要

  • RFC 892 让两个运输实体各自选择一枚 16 位引用，由对方用它定位运输连接；引用属于运输状态，并不等同于底层网络连接。
  • 映射可以双向复用：多个运输连接可共享一条网络连接；在支持的等级里，一条运输连接也可同时使用多条网络连接。
  • 分离不是无限承诺。底层服务质量、共享的 pervasive 功能、协商后的协议等级与各等级的恢复规则，仍决定路径能否复用、更换或直接结束运输连接。

RFC 892 中的 TC 与 NC 不是同义缩写。Transport Connection 面向两个运输用户，Network Connection 则是运输实体向下使用的承载服务。运输数据单元必须经过 NC，但运输状态并不必然由那条 NC 的寿命定义。

运输连接投入使用以前，要先分配到一条网络连接；若启用 splitting，则可以分配到多条。承载者既可能是现成的 NC，也可能为本次需要新建。于是“使用哪条路”是本地选择，“这是谁的运输状态”则由另一套证据回答。

这份文本本身也有清楚的制度边界。RFC 892 只是把 ISO 的运输协议规范作为资料分发，并明确声明它不是 ARPA Internet 标准。数月后的 RFC 905 用更新的 ISO DP 8073 文本取代了它，同样没有把 ISO 规范自动变成 Internet 的权威标准。

引用由两端分别产生

连接建立时，发起方发送 Connection Request TPDU，也就是 CR；响应方回送 Connection Confirm TPDU，也就是 CC。CR 带有本端选择的 source reference，CC 带回响应端选择的 reference。此后，每一方都用对方指定的值作为 destination reference。

引用是 16 位本地值，不得为零，不得仍在使用，也不得处于旧连接释放后的冻结期。它既不是全局名称，也不是身份凭证。只有接收端的状态表赋予它“指向哪一条 TC”的含义。

RFC 892 特别强调这种安排的对称性。它不需要预先指定 master 与 slave，也能处理双方同时发起的碰撞。更关键的是，规范把它称为“独立于 Network Connection 的 Transport Connection 标识”。

但独立不等于脱离上下文。带有正确 destination reference 的 TPDU 仍须从可接受的承载分配到达，并与活跃状态、对端引用和协议阶段相符。引用证明的是协议内部的归属，不证明机构身份、操作授权或应用完成。

发起方提出偏好，响应方给出结果

RFC 892 定义五种程序等级：简单的 class 0、基本错误恢复的 class 1、可多路复用的 class 2、兼具恢复与复用的 class 3，以及检测并恢复丢失、乱序、重复和损坏的 class 4。

发起方在 CR 中提出首选等级，也可列出备选；但若首选 class 0，就不能列备选。发出请求以后，发起方可以暂按首选等级运行。这个动作不是最终裁决。响应方通过 CC 返回 selected class；若合法结果不同，发起方必须调整自己的功能。

TPDU 最大长度又有独立协商。响应方可以接受建议，也可以在允许集合中下调至协议给出的下限。options 同样从 proposed 变成 selected。底层 NC 已建立、CR 格式正确、调用者表达偏好与最终运输合同成立，是四件不同的事。

等级选择还要看底层现实。规范按残余错误与已报告故障的可接受程度区分网络质量，并把用户要求、成本与服务质量纳入决定。一条 NC 即使可达，也可能因为质量不足或已经启用的 pervasive 功能与新 TC 不兼容而不能复用。

一条承载多项状态，一项状态也可跨多条承载

Multiplexing 允许多个 TC 共享一条 NC。每个 TPDU 都携带 destination reference，接收方据此把同一承载上的数据送回不同状态。资源被复用，运输连接没有因此合并。

共享仍会制造共同命运。规范把某些功能称为 pervasive：若第一条 TC 在某条 NC 上启用，这条 NC 生命周期内的其他 TC 也必须使用。底层路径不负责定义运输身份，却能给所有上层会话施加共同规则。

Splitting and recombining 则反向映射：一条 TC 同时使用多条 NC，以提高韧性、吞吐量或满足其他需要。RFC 892 的等级表并未让所有 class 都拥有这项能力；它是 class 4 的机制。准确的历史结论不是“OSI 运输天然多路径”，而是规范明确区分了一项运输状态与承载它的路径集合。

Reassignment 又展示了连接连续性的条件。当承载 NC 消失，调用该机制的恢复等级可把原 TC 分配到另一条 NC，再进行 resynchronization。对端要从一枚有效 TPDU、相关网络地址以及旧状态的引用中确认新承载属于同一对运输实体。

Class 0 是必要的反例。它没有独立的运输释放程序，TC 的寿命直接随 NC 结束。RFC 892 没有用一句“层次分离”抹平差异，而是把连续性明确交给具体等级。

TCP 后来成为另一种承载服务

RFC 983 在 1986 年提出：向上继续提供 ISO TSAP 服务，向下则以 TCP/IP 实现。这样，ISO 的 session、presentation 与 application 实体可以不知晓底层已经换成 TCP。文档同时说明，完整迁移计划不在其范围内。

RFC 1006 随后以 version 3 取代 RFC 983，把 ISO transport class 0 映射到 TCP。TCP 提供可靠字节流，却不保留 TPDU 所需的离散对象边界，因此 RFC 1006 增加带长度的 TPKT。它恢复分帧，不提供认证、授权或内容完整性。

这一映射缩小了原规范的选择：TCP open 成为下层连接建立，TCP close 成为断开，class 0 在其上运行。但运输服务接口与 TPDU 仍能跨越最初文本没有指定为 Internet 标准的底层实现。

RFC 2126 在 1997 年又把模型扩展到 IPv4 或 IPv6 上的 TCP，并规定 class 0 与 class 2 变体。它保留 TPKT version 3，以免破坏 RFC 1006 的安装基础。它也指出：TCP 端口 102 被保留，但合规连接并非必须全部使用它。

今天的 IANA 服务名与端口注册表 仍列出 iso-tsap 与端口 102。注册行证明号码协调，不证明监听者采用哪个 class、CR 是否获得确认、引用是否仍活跃，更不证明应用成功。

来源与边界

本文依据 RFC 892、取代它的 RFC 905、RFC 983、RFC 1006、RFC 2126 与 IANA 注册表。它们能证明协议设计、文本地位和 TCP 承载映射，不能证明当前部署、OSI 取代 TCP/IP、与 QUIC 或 SCTP 的直接谱系、任何实现都支持 splitting/reassignment、对端已认证，或某个应用已经完成工作。