摘要

  • RFC 1434 在每个 Data Link Switch 终结 LLC Type 2，因此两台终端拥有两条彼此独立的本地链路，并非一条跨越 WAN 的数据链路。
  • 交换节点还要通过 SSP 寻找终端、交换本地分配的 Circuit ID 并完成远端接触；TCP 连接正常，只证明两个交换节点之间的传输存在。
  • 本地确认和电路复用减少了 WAN 上的控制流量，却形成共享故障域：一条 TCP 失效，会让其中所有电路在两端同时向本地终端断开。

局域网的计时器不认识广域网

LLC Type 2 的节奏来自局域网。它假定传输延迟短而且相对稳定，用固定计时器判断帧是否丢失。把这套过程通过传统桥接直接拉过低速或拥塞的广域链路，延迟变化就会伪装成丢包。发送端重传一份其实仍在路上的帧，控制过程可能由此混乱，最后主动拆掉链路。

RFC 1434 选择改变边界，而不是把一个计时器调得越来越长。左侧终端只与附近的 Data Link Switch 建立 LLC Type 2；右侧终端也只与自己的交换节点建立另一条 LLC Type 2。两条本地连接在交换节点终结，信息再由 Switch-to-Switch Protocol 穿过可靠传输送到另一侧。

这意味着终端看到的 RR、UA 等确认，只陈述相邻交换节点已经接手本地链路责任。它不证明远端终端收到了帧，不证明另一侧 LLC 已建立，更不证明远端应用执行了动作。原文特意称两条 LLC 连接“完全独立”，正是为了防止连续的业务体验被误写成连续的协议状态。

收益同样真实。LLC 超时与确认不必穿越 WAN，SDLC 的轮询和回应也能留在本地；重试可以由靠近相应链路的交换节点吸收。广域延迟不再直接冲击为 LAN 设计的固定计时器。

一条 TCP 只是承载面

两台 Data Link Switch 在使用 SSP 前，先建立传输连接。RFC 1434 的初始实现采用 TCP，同时保留了使用其他可靠传输的可能。传输存在以后，SSP 才在其上建立端到端的 DLS 电路；多条电路可以共同使用同一连接。

顺序揭示了证据层级。端口可达、TCP 握手完成，只能说明两个交换节点之间有一条字节传输通道。它没有回答目标终端在哪里、哪台远端交换节点能接触它、Circuit ID 是否已经成对、远端本地链路是否完成接触。把“TCP up”展示成“终端服务 up”，会跳过协议中最关键的几步。

RFC 1434 为终端关系与电路实例使用不同标识。Data Link ID 由两端终端的 MAC 地址和 SAP 地址组成。每台交换节点又在本地分配一个 64 位 Circuit ID，由 DLC Port ID 与 Data Link Correlator 构成。端到端电路需要两侧 Circuit ID 的配对，每侧都要保存本地与远端的映射。

在电路尚未建立时，控制消息携带较完整的 Data Link ID；电路建立后，INFOFRAME 可以只携带远端 Circuit ID 的短头部。这个优化要求运维不能只记录一个本地数字。单独的 Circuit ID 离开分配它的交换节点就没有全局意义，必须与对端、方向和另一侧 ID 一起保存。

“能找到”与“已接通”不是同一句话

控制消息的名字像一段逐步收窄的不确定性。CANUREACH 询问谁能到达终端；ICANREACH 给出肯定回答和目标侧 Circuit ID；REACH_ACK 再把源侧 Circuit ID 送回。随后 XIDFRAME 交换链路信息，CONTACT 请求接触远端终端，CONTACTED 才表示相应步骤完成。

每个动词都有不可替代的对象。DLS 对端存活，不等于它知道终端位置。收到 ICANREACH，不等于两边都取得电路标识。Circuit ID 已配对，不等于远端终端的本地链路已接通。只有把状态顺序留下，故障发生时才能判断问题停在发现、选择、标识交换还是终端接触。

同一询问还可能收到多个 ICANREACH。RFC 1434 让源交换节点选取最先到达的回答，并向被选节点发 REACH_ACK。这个选择不是永恒的目录事实，而是某次搜索在特定时刻得到的结果。应当保存所有回答、到达顺序和最后选择，而不能只留下一个看似固有的“终端位置”。

若缓存里没有位置，交换节点可能把 CANUREACH 或 NetBIOS 查询发给所有已知 DLS 对端。位置缓存能降低这种搜索扩散，过期缓存又可能把新电路引向旧位置。发现范围与缓存新鲜度因此同属电路证据链。

本地先点头，远端仍可沉默

连接建立过程里有一处最能说明两条本地链路的独立性。源终端发送 SABME 后，源交换节点可以在远端尚未接触时，本地回复 UA。为避免终端立刻把数据灌入未完成的远端路径，交换节点先向本地发送 RNR；等收到对端 CONTACTED，再以 RR 放行。

本地回复并非伪造远端成功。它表示交换节点已经接受邻接链路的职责，RNR 则诚实地保留了链条后半段的不确定性。真正的错误发生在观测系统把 UA 解释成远端终端已接受、把 RR 解释成远端应用已处理。

这里至少有四种不同事实：SSP 电路已建立、远端接触已完成、本地发送获准、应用交换得到回应。一个绿灯不能代表四者。即使可靠 TCP 已把字节送到远端交换节点，远端 LLC 仍可能重试、断开或找不到相应应用。

1995 年的 RFC 1795 后来把流量授权写得更明确。它增加能力交换，并按方向、按电路实施自适应节奏。发送者启动时没有获准单元，必须等接收者用 FCIND 授予额度，初始窗口来自能力交换。这些不是 RFC 1434 的原始功能，但它们说明可靠传输之上仍需要独立的注入许可。

复用节省连接，也集中事故

本地终结省掉 WAN 上反复的 LLC 确认，复用则避免每对终端独占一条传输连接。可是一旦许多独立电路共用同一 TCP，它们也共享同一个中间故障点。

RFC 1434 的规定很直接：两台交换节点之间的 TCP 失败，复用在该连接上的所有连接都要拆除。两侧 Data Link Switch 向每个受影响的本地系统发送 DISC。某台终端的网线、端口和本地 LLC 可能完全健康，仍会因为中间共享依赖消失而看到会话终止。

因此，十条几乎同时发生的本地断线，可能只有一个传输根因；只报“十次终端故障”会放大根因数量。反过来，只报“一次 TCP 断线”又会隐藏十条电路的业务影响。事件模型必须同时保留一个共享原因和多条受影响关系。

正常拆除另有 HALT_DL 与 DL_HALTED 交互，本地 DLC 错误也可把一条电路带入断开状态。终端表面都表现为掉线，责任面却可能是本地链路、远端链路、单一 SSP 电路或公共传输。时间相近不是分类依据，状态机的第一处转变才是。

后续标准把隐藏层变成观测层

RFC 1795 明言自己对 RFC 1434 作出重大改变并取而代之。APPN Implementers Workshop 的 DLSw 小组希望形成多厂商可实现的统一 SSP，同时修正文档问题。它在传输建立后、普通电路控制之前加入能力交换，并规范了传输协商与按电路流控。

RFC 2024 再把层次投射为管理对象。传输状态包括 connecting、初始能力交换、connected、quiescing、disconnecting 与 disconnected；管理者还能查看电路创建、搜索活动、断开原因等。到这里，“套接字在线”不再有资格吞并其余状态。

RFC 2166 记录了规模扩大后的代价：维护大量对端配置、把发现和 NetBIOS 流量复制到许多点对点连接、保有传输会话，以及在中心节点终结大量 LLC2 都会消耗资源。v2.0 因而加入更明确的 halt 原因、组播辅助发现、按需连接，以及双方支持时的一条双向 TCP。

这些后续变化不能倒写成 1993 年已具备的能力。它们证明的是：RFC 1434 把广域延迟隔离出去后，状态并未消失，而是迁移到交换节点，并需要新的协商、观测和规模控制。

证据必须走到应用才算完整

一份可追查的记录至少要包含：传输对端与状态；搜索的终端地址；所有 ICANREACH 及所选回答；成对 Circuit ID；CONTACT 与 CONTACTED；两侧本地 DLC 状态；发送许可；数据计数；HALT、DLC 错误或传输失败的首个原因。应用回应另行记录，不能由前述状态自动生成。

RFC 1434 与 RFC 1795 都明确说没有讨论安全问题。因此，仅凭这些文献不能把 SSP 交换当作对端认证、终端授权、机密性或对抗攻击的完整保证。TCP 的可靠性描述的是既定模型中的顺序交付，不是安全结论。

这些 RFC 也不证明某个厂商部署、某次事故或当代网络仍在使用该机制。历史价值在于它们把一个看似连续的会话拆回责任现实：本地确认、远端接触、共享传输、流量许可和应用结果，各自都需要自己的证据。

来源