摘要

  • RFC 6525 允许选定的 SCTP 流把序列状态重置为零，而不拆除整个关联，也不改动未列出的流。
  • Sender’s Last Assigned TSN 标出了旧纪元的终点。累计确认尚未到达该点时，接收端必须返回“In progress”，并暂存界线之后的数据。
  • 重配置本身拥有单调递增的请求序号、可重放的响应和拒绝结果：协议要忘记数据序列，必须先准确记住“忘记”这件事发生到哪一步。

归零不等于过去已经离开网络

SCTP 关联可以承载多个单向流。RFC 4960 让每个 DATA 分片携带关联范围内的 Transmission Sequence Number，同时让有序用户消息在各自流中使用 Stream Sequence Number。RFC 9260 延续了这种分工：TSN 服务于确认与重复检测，应用次序则限制在单个流内。

因此，一个应用可能已经结束流 3 的旧用途，想把它交给新的会话，但属于旧用途的分片仍在重传或排队。若立即把 SSN 设为零，延迟分片就可能被误认成新纪元的数据；若关闭整个关联，又会无端牺牲流 8、路径状态和仍然有效的上下文。

RFC 6525 在 2012 年定义了 RE-CONFIG chunk。它并不删除在途数据，而是协调双方在什么时刻可以结束旧编号、开始新编号。

最后已分配 TSN 划出了一条界线

Outgoing SSN Reset Request 包含重配置请求序号、重配置响应序号、Sender’s Last Assigned TSN，以及可选的流编号列表。没有列表表示所有出站流；列出编号则只影响这些流，其他流的状态保持不变。

最后已分配 TSN 等于“下一个将分配的 TSN 减一”。发送请求前，发送端停止为受影响流分配新的 SSN，并把后续用户消息排队。否则，若请求丢失而新消息已经发出，接收端便无法判断它们属于哪一个序列纪元。

接收端把这条界线同累计确认点比较。确认点还未到达时，它进入 deferred reset processing：对于受影响流，TSN 高于界线的数据被保存在本地，响应结果为“In progress”。这证明请求已被识别，却不表示重置已经成功。

累计确认抵达界线后，接收端才把指定流的下一个预期 SSN 设为零，释放暂存 TSN，并返回成功。未被列出的流继续原来的序列。新纪元不是某一端宣布出来的，而是在双方都能区分旧数据与新数据时成立。

负责遗忘的控制交换不能失忆

RE-CONFIG 请求使用单调递增的序号，并以初始 TSN 为起点。响应复制相应请求号，可以报告成功、拒绝、SSN 错误、已有请求处理中、请求序号错误或仍在处理中。

最近一个请求因重传再次到达时，接收端必须给出先前相同的响应，不能再次执行一次重置。改变数据编号的操作，因而依赖一条独立且可重放的控制历史。

收到“In progress”后，请求端重启定时器，必要时重传，但不增加关联错误计数。这不是路径故障或拥塞证据。只有收到成功，发送端才重置相应的出站状态、处理排队数据并恢复编号分配。

对端也可以拒绝。RFC 6525 把它视为管理决定，而且允许关联建立后仍由用户配置。支持这种扩展，只说明双方会说这种控制语言，并不等于同意每一次具体重置。

并发请求还揭示了“看起来重复”和“确实重复”的差别。若一个入站请求完全落在本端已经等待的出站重置范围内，对端可以回答“Nothing to do”；若两份请求只部分重叠，仍要正常处理，即使某个已经归零的流再次被设为零。这会多产生控制报文，却避免把部分重合误判成同一件事。

响应中的请求序号也不能被当作新的流序号、业务会话号或长期事件标识。它只为这条关联里的重配置控制交换排序。离开关联上下文，单独保存一个数字不足以还原到底哪些流被选中、旧数据界线在哪里，或最终是否真正完成。

扩展也能增加入站或出站流数量。新申请的出站流在收到肯定响应之前不得使用。可见 RE-CONFIG 并不是一个任意改写关联结构的命令，而是一组每项都需要确认其生效边界的事务。

成功结果也有两种有用含义：“Performed”表示动作已经执行，“Nothing to do”则说明当前状态已经满足请求。两者都不同于“In progress”。监控系统若把所有非拒绝结果压成同一个绿色状态，就会丢掉何时可以释放排队消息这一关键时间差。

入站与出站拥有不同的控制者

SCTP 流是单向的。反方向的相同编号不会自动组成一条双向流；若应用需要关联二者，必须自己定义。一个端点若要重置自己接收的流，实际要请求对端重置其出站流，因为真正掌握发送界线的是分配过这些序号的一方。

SSN/TSN Reset 又是另一种操作。它重置所有方向的 SSN，并为双方选择新的 TSN 起点。请求期间发送端停止分配 TSN，协议还用最大分段寿命防止编号回绕产生歧义。它不能被当作“选定流重置的加强版”。

RFC 6458 向应用暴露 SCTP 序号与通知接口，所以 RFC 6525 要求应用显式启用重配置并订阅相关通知。一个依赖序号单调递增的程序，必须知道纪元何时改变。

消息交织替换了计数器，没有取消边界

RFC 8260 为 I-DATA 引入 32 位 Message Identifier，以便不同用户消息相互交织。在这种关联中执行流重置时，有序与无序消息各自的 MID 计数器都必须归零。许多调度器采用较晚分配 TSN 的方式，使实现更复杂，但旧数据边界仍然不可省略。

流重置也不同于部分可靠性。RFC 7496 规定优先级、重传次数等消息放弃策略。放弃消息回答“还要重试多久”；重置流回答“什么时候可以重新使用这套序号”。二者改变的不是同一种状态。

IANA SCTP 参数登记表 把 130 分配给 RE-CONFIG，并列出相关参数与结果。登记表可以帮助解码抓包，却不能证明某个实现支持扩展、两个端点已经协商，或应用已经启用它。

RFC 6525 还指出，SCTP 的 verification tag 继续提供针对盲目攻击者的既有限制。这是一项窄结论：它不证明应用意图得到认证，也不覆盖在途攻击者或错误授权。运行证据仍需同时包含对端能力、应用许可和实际请求结果。

来源