摘要

  • RFC 1490 建议、但没有强制要求，把超过 Frame Relay 网络最大帧长的数据包拆开传送，并在该网络边缘的 DTE 设备上重组。
  • 这一算法依赖同一虚电路上的严格顺序。片段丢失或损坏时，接收端丢弃整条消息，由上层协议负责重传。
  • 1998 年的 RFC 2427 表示，RFC 1490 的多协议封装已广泛实现，但其分片算法没有互通实现；新版删除该算法，转而引用 FRF.12。

RFC 2427 对 RFC 1490 的评价很具体。它说，被替代的多协议封装已经得到广泛实现和使用；但同一附录也指出，RFC 1490 的分片算法没有可互通的实现。新版删除了这套分片方式，改用 Frame Relay Forum 的 FRF.12。RFC 2427 并没有说从未有人写出过相关代码；它说的是不同实现之间无法互通。历史的分界就在这里：规范整体可以取得广泛采用，其中某个可选机制却没有成为共同实现。

这个机制针对一个很实际的尺寸限制。1993 年 7 月发布的 RFC 1490 说明如何在 Frame Relay 骨干网上承载路由和桥接流量。它指出，网络所支持的最大帧长可能低至 262 字节；经过协议封装的数据包则可能更大。分片可以把它拆成适合底层网络的帧，再由接收端拼回去。RFC 1490 建议端点支持分片与重组，却没有把它列为必需功能。因此，多协议封装可以被采用，而两端未必都实现这套扩展。

分片的范围同样重要。RFC 1490 将过程限定在 Frame Relay 网络的边界，也就是连接在两端的 DTE 设备之间。发送端先封装数据包，再将其拆成符合网络帧长上限的片段；接收端重组后，再按未分片数据包的同一处理流程交给上层。IP 并不会把这里的片段当成一串较小的 IP 数据报。它是针对特定链路服务帧长限制的处理，而不是改变 IP 数据报本身。

RFC 791 描述的是另一层的分片：IP 数据报携带标识、偏移和分片标志，由 IP 目的端负责还原原始数据报。RFC 1490 则在已经封装的数据包外围增加另一套分片标识，并要求在 Frame Relay 边界重组，然后才进入普通协议处理。两者都把数据拆开，但涉及不同的协议层、接收端和责任边界。

RFC 1490 的片段格式带有状态。每个片段包含封装标识、一个两字节序号、偏移量和表示末片的标志位。每个新的分片消息都会推进序号；设备初始化时，序号从随机值开始。偏移以 32 字节为单位计算，第一片的偏移必须为零。这些字段让接收端能够识别同一消息的各部分、放回正确位置，并判断片段是否齐全。

规范还限定了传输顺序：片段必须从偏移零开始依序发送，面向同一数据链路连接的其他信息不得插入其中。一个端点必须能够重组至少 2 KiB，建议支持到 8 KiB。如果片段丢失或受损，整条消息就会被丢弃；重传责任属于更高层协议，Frame Relay 分片本身不负责逐片重试。

规范没有设置重组计时器。RFC 1490 的理由是 Frame Relay 服务被要求按序交付，因此接收端不必靠本地超时来判断一组未完成的片段是否过期。这是写在规范中的服务前提，不是对所有运营商交付质量的测量，也不能证明所有设备都曾正确依赖这一保证。接收端仍要为未完成消息占用缓冲；任何一片丢失仍会让整条消息被丢弃；而恢复要等待上层协议处理。

五年后，RFC 2427 将不同机制的实现结果明确拆开。它说 RFC 1490 的整体封装已得到广泛实现，并被行业和 ITU 文档采用；但分片算法没有互通实现，还存在该机制不足以满足部分 Frame Relay 应用的意见。新版因此移除它并引用 FRF.12。RFC 没有列出设备厂商、互操作测试数量或具体故障原因。我们不能替它补写这些细节。现有证据足以说明分片算法没有成为通用实现契约，却不足以说明具体为何失败。

因此要避免两种相反的误读。不能因为某个可选功能无法互通，就说 RFC 1490 整体没有被采用；它的继任规范明确说封装本身广泛实现。也不能因为封装广泛使用，就推断其每项扩展都能工作；RFC 2427 对分片的记载正好否定这一点。标准中可以包含生命周期不同的机制：一个编码格式进入各类设备，另一个算法却没有构成共同的互操作基线。

“支持 RFC 1490”作为设备标签并不足以回答实际问题：支持哪项功能？每条虚电路设定了多大的最大帧长？两端是否实现同一种片段格式、顺序规则和完成条件？RFC 2427 留下的历史答案是按机制划分的：基础封装拥有广泛的兼容集合；这套分片算法没有互通证据。FRF.12 的出现说明了标准如何转向，却不能证明后来所有网络都采用了它。