摘要

  • RFC 1190 的中间 ST 节点可以确认 CONNECT、协商本地转发标识符并尝试预留资源，但这些动作发生在目标应用作决定之前。
  • HID-APPROVE 只封闭一跳的标识符交换；目标应用另行返回 ACCEPT 或 REFUSE，并把该分支实际累积的 FlowSpec 带回源端。
  • 多目标流要等每个目标都有结果，源端还可能删除分支、拆成两条流或释放过量资源；接受本身也不证明后续数据或媒体抵达。

最早返回的“同意”不属于应用

RFC 1190 于 1990 年 10 月发布，定义 Experimental Internet Stream Protocol Version 2，也就是 ST-II。它是一项限定使用的实验协议，不是 Internet Standard。RFC Editor 记录与 IETF Datatracker 记录确认它后来被 RFC 1819 取代，却不证明某条真实网络曾完成过图中的交互。

中间节点收到 CONNECT，先为控制链路选择状态，再快速向前一跳回复 ACK、HID-REJECT 或 HID-APPROVE。若没有错误，它随后调用路由功能、预留资源，并按目标分支生成新的 CONNECT。

这个肯定回答有严格边界。它说明相邻节点处理了请求，并可能接受一个 Hop Identifier 作为今后快速转发的本地把手。它不说明远端应用是否存在、是否愿意参加，也不说明整条路径达到请求条件。中间节点拥有本地队列与转发表，不因此取得目标应用的决定权。

流不是一个包，而是一棵先建立的树

ST-II 位于与 IP 相同的 Internet 层。RFC 1190 把流定义成由一个源端指向多个目标的单向树，同时包括路径、已分配资源与每个节点保存的状态。数据包只有在 setup 之后才属于某条流。

这是一种把复杂度前置的安排。路由功能按 TargetList 的子集选择下一跳；全局 Name 标识流；Virtual Link Identifier 把控制消息送进正确状态机；HID 则让后续数据用较短的本地标识完成转发。若底层网络支持组播，一个副本可以抵达多个下一跳，但参与节点仍要协商同一个 HID。

这些字段都不是人的身份或授权凭证。Name 说明协议对象，TargetList 划分叶子，HID 说明一跳的快速转发状态，SAP 选择上层应用。把它们压成一个“流已获批”状态，正好抹掉设计原本保留的界线。

FlowSpec 在路上会改变

RFC 1190 所说的资源不只带宽，还包括转发信息、交换处理能力、缓冲区和组播标识符。文档没有规定所有底层网络如何实现预留，并坦白指出当时很少有网络支持资源预留，作者所知也没有网络能预留全部这些资源。

源端的 FlowSpec 同时包含 Desired 与 Limits。若某一跳拿不到全部期望值，只要结果仍在最低 Limits 内，就可以把发往下一跳的 Desired 更新为实际取得的值。带宽可能下降，时延与抖动可能累积，报文尺寸也可能因链路 MTU 缩小。中间与目标节点不能擅改源端给出的最低界线。

所以“预留成功”至少要回答五个问题：谁请求、哪一跳处理、请求值多少、实际取得多少、是否仍在最低条件内。一个脱离分支与版本的布尔值，不能代表端到端服务。

目标应用保留最后一层拒绝权

请求抵达目标主机后，ST 节点先完成 HID 协商，再把 Name、FlowSpec、Options、Group 与应用选择信息交给指定进程。目标应用可以接受、拒绝，也可以在允许范围内降低希望获得的服务。

只有经过这一步，目标节点才发送 ACCEPT 或 REFUSE。ACCEPT 使用新的 Reference，并用 LnkReference 对应先前的 CONNECT。每个中间节点检查这层关联、向下一跳确认收到，再沿原路反向传播自己的上游消息。

这不是重复确认。逐跳 ACK 证明控制消息被相邻节点处理；HID-APPROVE 证明一跳标识符可用；资源管理器说明本地能给什么；目标应用决定是否参加；源端再判断返回条件是否值得采用。五种决定不能相互借权。

多目标流没有一个天然的总答案

源端会分别收到每个目标的 ACCEPT、REFUSE 或错误。只有所有目标都有结果，而且标识符协商结束，RFC 1190 才把 setup 视为完成，并允许开始发送数据。

各分支的答案未必能合并。一路可能允许低速大包，另一路允许高速小包；共同的报文尺寸、速率组合也许不存在。源端可以删除某个目标、终止整条流，或另建一条流。参数调和后，还应通过 CHANGE 释放超过最终选择的资源。

因此 B 的 ACCEPT 只证明 B 分支在那份 FlowSpec 下的接受。它不能替 C、D 作答，也不能证明源端已经形成一个能对所有目标兑现的承诺。

接受之后，承诺仍可能退化

即使目标发出 ACCEPT，反向传播仍可能失败。中间节点多次收不到上游确认时，要向源端改发 REFUSE，并向目标发送 DISCONNECT。更高 precedence 的流还可能抢占资源；建立后的 NOTIFY 可以报告保证下降；一次失败的 CHANGE 甚至可能只改了一部分预留，迫使系统进入恢复。

RFC 1190 也明确说 ST 协议本身不提供 security services。ACCEPT 不认证某个人，不批准账单，也不证明应用代表某个机构作出不可撤销承诺。控制状态建立后，数据是否发出、包是否抵达、音频是否解码、参与者是否听见，仍要靠后续证据。

1995 年的修订删掉了 HID，却保留了同意边界

RFC 1819 在 1995 年将实验修订为 ST2+；它的 RFC Editor 记录和 Datatracker 记录保留了取代关系。IESG 注记强调，新旧两版都不是、也不在考虑成为 Internet Standard。

ST2+ 仍要求中间节点确认 CONNECT、调用本地资源管理器、继续传播请求，再由目标应用返回 ACCEPT。但它删除了 HID，因为实现经验表明这种复杂度妨碍互操作；它也取消了 subset implementations，因为“允许只做一部分”没有保证双方能力一致。

这段修订史反而突出核心：本地快速转发标识可以被下一版淘汰，远端应用的同意仍不能被一跳确认代替。实现能力、资源状态与参与决定从来不是同一条记录。

更早的 RFC 1077 已把高速网络问题从光纤速率扩展到交换、主机与管理；后来的 RFC 1633 和 RFC 2212 又定义了别的预留与保证服务边界。相似问题不能证明直接谱系，但都说明物理容量、条件承诺与实际观测不可互换。

来源