摘要

  • RFC 1307 是 1992 年 3 月发布、供进一步研究的 Experimental 协议说明，不是互联网标准；它描述 Cray Research 项目如何让主机上的传输服务方按需启用或释放下游交换链路。
  • 传输服务方只看见 up 与 down，DSLCP 内部却维护 Down、Coming Up、Up、Going Down、Bring Down、Bring Up 六种状态，以容纳尚未完成的控制操作和反向到来的新意图。
  • 在 Up 状态收到 release 时，DSLCP 发出 teardown、进入 Going Down，并立即通知服务方链路 down。这个通知是本地接口语义，不是控制器已完成拆除、更不是物理线路或容量已经释放的证明。
  • DSLCP 对 teardown 请求总向服务方返回成功；即使控制器报告找不到对应事务，也可按成功继续。超时、重传、重复与乱序还会让真实响应在抵达时已经过时。
  • 可靠判断必须分开保存用户请求、服务方二态视图、事务标识与端点、六态机状态、控制器记录及回复、物理观察和数据结果，不能让其中一项代替其余证据。

down 抵达时，事情还没有结束

RFC 1307 中最值得停下来的瞬间，不是线路真正变为某种物理状态的时刻，因为文献没有给出那种现场观察；而是状态机处于 Up、传输服务方提出 teardown 的时刻。DSLCP 向链路控制器发送拆除命令，内部转入 Going Down，同时就把链路 down 的通知交还给传输服务方。

这三个动作几乎可以写在一行状态转换里，却属于三类记录。发送命令说明控制意图已经发出；进入 Going Down 说明 DSLCP 知道控制动作仍在进行；向上报告 down 说明它决定让调用方不再承担这段等待。若只保存最后一项，进行时就会被抄成完成时。

这种安排不是疏忽。RFC 明确让传输服务方只感知 up 或 down，并告诉它不要自行跟踪某条链路的具体状态，因为 DSLCP 负责内部状态，还可能执行服务方看不见的重定向或其他处理。抽象层的承诺是“你可以按照 down 行事”，而不是“我已经观察到物理电路完全拆除”。

因此，down 可以是一项稳定、有效、对上层有用的答案，同时仍不足以证明控制器收到了命令、找到了事务、完成了硬件操作或释放了某种稀缺资源。接口答案的价值不因证据边界而减少；真正的风险，是把有意缩窄的接口答案扩大成它从未声称掌握的物理历史。

昂贵线路催生了按需控制

协议的经济动机很直接。电路交换链路若长期保持连接会产生费用，因此通常处于断开状态。传输服务方最接近会话的开始与结束，适合在需要时请求链路启用，在使用结束时请求释放。至于硬件与管理上的建立细节，则交给独立的链路控制器。

这项分工把“什么时候需要服务”与“设备怎样完成服务”分开。传输服务方可以依据会话使用情况表达 connect 或 release，DSLCP 把意图组织成事务，控制器处理实际控制细节。减少长期连接成本的目标，需要一个足够简单的上层接口；但费用动机本身不证明任何具体账单在某一时刻停止，也不证明某段容量已重新可售。

更耐人寻味的是，控制一条尚未准备好的数据链路，首先需要另一条已经存在的网络路径。主机与链路控制器之间在 DSLCP 事务开始前必须可达，控制报文可以装在 IP 或 UDP 数据报中。准备数据通道依赖控制通道；受控链路的 down 也不等于控制路径同时消失。

RFC 1307 不要求这个控制传输可靠。命令发出、控制器执行、回复返回是可分离的阶段。它们之间既有网络时间，也有丢失和重复的可能。若把发送记录直接当成设备效果，或把上层 down 直接当成控制器确认，就越过了协议专门保留下来的异步空间。

两盏指示灯背后有六个房间

传输服务方只面对二态世界：链路 up，或者 down。DSLCP 的内部状态却有六个。Down 和 Up 容易理解；Coming Up 与 Going Down 表示控制器操作尚在进行；Bring Down 与 Bring Up 则记录一项更棘手的事实——用户的新意图已经反转，但旧操作还没有得到结果。

假设 setup 尚在等待，状态是 Coming Up，此时最后一个传输会话结束并要求 release。DSLCP 不能假装此前的 setup 从未发出，因为控制器仍可能随后完成它。状态于是进入 Bring Down：先等 setup 的回复；若 setup 成功，马上补发 teardown。当前意图已经是 down，在途动作却仍指向 up。

反向情形同样成立。teardown 已发出、状态为 Going Down 时，又有新的 connect 需求。DSLCP 转入 Bring Up，等待拆除结果，然后再发送 setup。此刻用户希望 up，控制器可能正在拆，服务方又只看到经抽象后的二态答案。六个状态不是把简单问题复杂化，而是保存不同时间的意图不能相互擦除这一事实。

如果系统只记录最终 up/down，Bring Down 与 Bring Up 的存在就会消失。一条迟到的 setup success 看起来像无缘无故的启用，一条拆除成功也可能被误放到新的 connect 意图之后。状态机所承担的，正是把“现在想要什么”与“此前已经要求控制器做什么”同时保留下来。

事务不是一个号码

DSLCP 报文带有 16 位标识符、两个 32 位端点地址、功能、事件状态，以及由控制器解释的任意消息体。RFC 的事务识别依赖标识符与两个端点共同使用。单独一个 16 位值既不是电路，也不是传输会话、人员身份或全局唯一的权威令牌。

事件状态也不是悬空的设备真相。定义的功能是 bring up 和 bring down；状态包括 setup succeeded、setup failed、teardown succeeded、teardown failed，以及异步 network down。RFC 特别说明，事件状态描述的是受控链路相对于上一次功能请求的状态。去掉请求上下文，一条 success 便失去它究竟回答什么的关键边界。

所以，匹配控制器回复不能只看“成功”或标识符。至少要连接两端地址、尚未完成的功能、发出时间、当时与收到时的内部状态。旧标识符可能重现，重复数据报可能再次触发回应，用户意图也可能在回复途中反转。消息本身可以真实无误，却已不再适合当前方向。

控制器消息体具有控制器自己的意义，也不能被主机一侧随意提升为认证或授权证据。RFC 的 Security Considerations 明说没有讨论安全问题。端点、字符串、事务编号和回复由此都不能从这份来源获得身份验证、完整性、机密性或授权保证。

建立要交代成败，拆除只给上层成功

RFC 1307 对 setup 与 teardown 的报告并不对称。某次 setup 是否成功或失败，会通知传输服务方；而对 teardown，服务方可以假定成功，因为 DSLCP 总会向它返回成功响应。这个接口选择让调用方结束得干净，不必等待或解释控制器的每一种状态。

但“总是返回成功”定义的是 DSLCP 对服务方的承诺，不是对物理世界的观察。上层成功可以与 Going Down 并存，也可以与一个尚未抵达的控制器回复并存。若控制器后来返回失败，上层先前得到的成功仍是协议规定的本地收敛结果；它没有因此变成一份设备拆除证书。

最尖锐的例子发生在 Up 状态收到 teardown failed。RFC 将其解释为 DSLCP 为无效事务发出了 teardown，控制器没有与该标识符和端点相符的事务记录。规定动作是继续，好像请求已经成功。状态机借此避免被一项不存在的控制器记录困住，并回到可继续工作的本地抽象。

“好像成功”四个字必须按原来的语法阅读。它告诉实现下一步如何推进，并没有重建控制器为何没有记录、记录何时丢失、此前是否发生过物理拆除。未知事务与已完成事务可能在本地得到相同后续动作，却不是同一段历史。若审计只保留最终成功，恰恰会删掉 RFC 已经显露的失同步证据。

超时会制造多份真消息

不可靠控制传输迫使 DSLCP 设置超时并重传。作者所在环境采用五秒超时和三次重传，同时明确指出这些数值需要按环境调整。这个例子证明的是协议预计会有等待与重复，不是为所有网络确立固定的最佳参数。

重传之后，控制器可能面对冗余请求，主机则可能收到意外回复。数据报的先后次序也不一定与意图顺序一致：第一次请求的响应可能在后来请求之后才到；同一成功可能由重复请求引出多次回应。接收时间最晚的消息，不一定代表最新的用户意图。

RFC 对 stale success 的处理很具体。如果本地已经处于 Down，却收到 setup succeeded，它把这看作重复请求与分组乱序可能造成的结果，并发送 teardown。成功消息可以是真的——某次 setup 确实被控制器认为成功——却在当前状态下已经不再是想要的结果。补偿性 teardown 不是否认成功，而是把物理方向重新拉回现行意图。

在 Bring Down 状态收到 setup success，也会发送 teardown 并进入 Going Down。这里更能看见状态机的记忆：它先接纳旧操作的完成，再执行后到的 release。若监控把两条命令分别标成“一次成功启用”和“一次成功拆除”，却没有标出它们属于同一意图反转，便会凭空制造一次有意义的业务会话。

乱序的拆除成功可能是警报，而不是好消息

teardown succeeded 若在 Going Down 抵达，符合尚未完成的拆除请求；若它在 Up 状态抵达，含义就不同。RFC 说此时某种错误已经发生，并提出较保守的做法：把连接带到 down 并重新同步；文献也承认，忽略该消息也可能令人满意。

两种可选反应表明，单条意外成功不足以确定唯一物理事实。它可能是迟到、重复或失同步的一部分，而当前 Up 又表达本地状态机的另一项判断。协议没有假装矛盾不存在，而是让实现者在保守重同步与忽略之间作取舍。

异步 network down 也应单独记录。它由控制器报告，不是主机上的 release 请求，也不是 teardown success。该事件可以让 Coming Up、Bring Up 或 Up 转为 Down，并通知传输服务方。虽然最终二态显示同为 down，触发来源、事务关系和处理路径并不相同。

因此，同一 down 至少可能来自服务方主动 release 后的提前通知，来自 setup 过程中的异步网络故障，或来自状态机为失同步采取的收敛动作。没有原始事件类型与状态转换，最终标签无法反推是哪一条历史。

逻辑结论不能代替物理观察

严谨的事件记录需要保存一条完整连接链：传输用户何时提出 connect 或 release，传输服务方当时的活动会话数与二态视图，16 位标识符和两个端点，发出的 bring-up 或 bring-down 功能，转换前后的六态状态，超时与重传次数，控制器是否持有该事务记录，回复事件与时间，以及独立的物理链路和数据面观察。

这些记录的权威范围不同。用户请求证明需求；服务方视图证明接口得到的逻辑状态；DSLCP 状态证明本地控制进度；控制器记录证明它认得哪项事务；响应证明控制器针对某个上下文发回何种事件；物理遥测才可能说明线路现象；传输与应用记录才说明数据是否移动、收到并产生结果。

容量释放、计费停止、访问授权和安全属性还各有自己的记录。RFC 1307 没有给它们结论。把逻辑 down 输入资源系统也许是一项运营选择，但那项选择不能倒过来证明控制器已完成或电路已拆。否则，一个为简化调用者而设计的接口约定，会在下游变成虚构的物理凭证。

RFC 1307 的六态机提醒我们，二态不是世界只有两种状态，而是有人承担了隐藏中间态的责任。真正可靠的系统既可以继续给上层清楚的 up/down，也应让命令、等待、反转、回复与观察在证据层面保持原样。主机可以先说 down；历史记录不能跟着提前结束。

来源与证据边界

本文唯一来源是 RFC Editor 发布的 RFC 1307，即 Jeff Young 与 Andy Nicholson 于 1992 年 3 月发表的 Experimental 协议说明。它支持关于按需链路、既存控制路径、事务字段、二态接口、六态机、意图反转、setup/teardown 报告差异、超时重传、过时成功、重同步、未知事务和异步 network down 的描述。它不证明任何现今部署、真实控制器、物理电路、容量释放、账单变化、数据传输、应用结果或安全属性。本文也不重述已发布 RFC 1306 文章所讨论的路由查找、外部激活、未完成电路时的无数据规则、路由别名或首个字节前的独立计时器。