摘要

  • RFC 1973 在 Q.922 头之后用 0xcf 指明 PPP，但接收器仍须结合首字节、Protocol-Field-Compression 和相关 NCP 的协商状态判断后续格式。
  • 同一 LCP Identifier 若从不同 framing address 收到多份响应，可揭示误接多点；NCP 成功后若出现等价的 RFC 1490 封装，则必须回到 Link Establishment，防止对端遗忘状态形成流量黑洞。

设想一条已运行数月的虚电路。监控只显示物理接口仍为 Up，DLCI 仍能承载帧，偶尔还能收到看似正确的 IP 数据。然而一端记得自己已经完成 PPP 协商，另一端却突然改用普通 Frame Relay 多协议封装。两边并非完全失联，却可能把彼此的有效流量当成不可理解的噪声。RFC 1973 处理的正是这种危险的“半连接”。

这份 1996 年 6 月发布的规范把 PPP 放进点对点 Frame Relay 电路。PPP 提供 LCP、各网络层 NCP、认证与压缩；这些机制依赖两个 peer，而不是多点或多接入关系。Frame Relay 的虚电路可以提供两点之间的承载，但它的地址与拓扑语义并不自动证明只有两个参与者。于是，封装格式还要承担一项额外任务：使接收端知道何时应该相信既有 PPP 状态，何时必须退回起点重新确认。

先承认无法共存

PPP 通常使用以 ISO 3309 为基础的 HDLC-like framing。设计者一度希望它与 Frame Relay framing 共存于同一链路。RFC 1973 给出了否定结论：Q.922 会把地址从一个字节扩展成两个或四个字节，而 DLCI 子字段的结构不能总与 ISO 3309 的解释无歧义地区分。只靠观察比特流，接收器可能无法确定地址在哪里结束、下一字段从哪里开始。

规范没有用猜测补洞，而是选择明确边界。帧的顺序是：0x7e Flag、Q.922 Address、Control、NLPID 0xcf、PPP Protocol，之后才是 Information 与 Padding。Q.922 字段说明 Frame Relay 承载语境；0xcf 选择 PPP 解释器；PPP Protocol 再选择 LCP、某个 NCP 或被承载的网络层协议。

这也解释了为何 Address-and-Control-Field-Compression 不得协商。HDLC-like PPP 中可压缩的是恒定的 Address 与 Control 值；Frame Relay 的相应值并不恒定，而且会随交换网络转发而改变。把它们当成冗余字段删除，等于删掉仍参与交付判断的上下文。

首字节必须带着协商记录来读

Protocol-Field-Compression 的角色不同。它可以把两字节的 PPP Protocol 压成一字节。RFC 1973 还指出，在这种 framing 中，移除 NLPID 并压缩 Protocol 后，Information 字段会落在 32 位边界；若能改善吞吐，PFC 应当协商。

压缩也制造了判别难题。接收端先查看 Frame Relay 头后的第一个字节。如果它是零，必须按 RFC 1490 格式理解；如果是 0xcf，它明确标出 PPP NLPID。如果非零且不是 0xcf，只有在 PFC 已启用、并且该值关联的 NCP 已经完成协商时，才预期它是被压缩的 PPP Protocol。少了任一条件，都必须按 RFC 1490 封装解释。

因此，同一个字节的意义依赖本地保存的协商状态。IANA 至今仍把 0xCF 列为 PPP NLPID，同时把 PPP Protocol 00cf 列为保留值。RFC 1973 禁用后者是为避免 PFC 生效时发生碰撞；文本允许它表示后面还有一个 PPP Protocol 包，却没有赋予它身份、认证或交付证明。

cf-c0-21 只是开始

初始 LCP 包在 Frame Relay 头之后出现 cf-c0-21：cf 是 PPP NLPID，c021 是未压缩的 LCP Protocol。识别出 LCP Configure-Request 后，PPP 链路进入 Link Establishment。

这三个字节很适合做抓包筛选条件，却很不适合做“PPP 已成功”的结论。它们只让解析器知道应该尝试读取什么。Configure-Request 的长度、选项、Identifier 和后续响应仍须校验；LCP 尚未因此进入 Opened，更没有证明认证或 NCP 已完成。

RFC 1973 随后给出一个异常诊断：如果原本应为点对点的 feed 被误接到多点网络或 multicast group，多台设备可能回复同一 Configure-Request。相同 Identifier 的多份响应若来自不同 framing address，应触发配置错误提示。

证据是组合出来的。Identifier 把响应关联到同一请求；不同 framing address 显示不止一个可观察来源；响应数量把偶然重复与多方回复区分开。单个响应不证明只有一个 peer，DLCI 也不是全球稳定的组织身份。更重要的是，有些实现可能在物理上无法记录或报告这些地址，所以“没有报警”并不能反向证明拓扑正确。

等价封装为何触发重建

进入 Link Establishment 后，在 Network-Layer Protocol phase 到来之前，其他 NLPID 不得发送；收到时必须静默丢弃。这个规则把尚未完成的 PPP 控制面与其他封装隔开，避免数据平面先于协商结果占据解释权。

当某个 PPP Protocol 的 NCP 已成功协商，情形反而更敏感。若此时收到 RFC 1490 定义的同一网络层协议等价封装，RFC 1973 要求 PPP 链路回到 Link Establishment，并发送新的 LCP Configure-Request。原因不是新封装天然错误，而是它说明远端可能已经丢失原 PPP 状态。如果本端继续按旧约定发送，流量会进入双方各自都认为“正确”的黑洞。

重新开始是恢复动作，不是根因判决。它不证明远端重启、线路被切换或设备故障；不恢复已被丢弃的数据；也不保证下一轮协商成功。它只把一个含糊的数据面症状变成可观察的控制面交换。

配置失败后还有两种本地选择。若实现要求 PPP 配置或认证等 negotiated feature，可以进入 Termination；否则，Configure-Request 发送方达到 Max-Configure 后，必须只发送 RFC 1490 封装。前者优先保住所需属性，后者优先维持较低条件下的承载。两种策略都不能由一个字节替运营者决定。

小规则留下的大边界

RFC 1973 要求链路 full-duplex，可以是永久或交换虚电路。Frame Relay 控制信号向 LCP 提供 Up/Down 事件，但控制信号失败不得影响 PPP 的正确运行。规范推荐 Magic Number 与 PFC，把初始 MRU 设为 1600；除非明确协商出至少 2048 的 peer MRU，网络层 MTU 不应超过 1500。

当年的设备限制也写进了协议。部分交换机只能处理 262 字节帧，因此在 LCP 协商完成之前，实现必须可把 LCP 包限制到 259 字节，为 NLPID 与 Protocol 字段留出空间。PPP 链路不要求支持 XID；Inverse ARP 也不要求，因为相应功能由 PPP NCP negotiation 提供。它们是这个特定组合的互操作规则，不是对所有 Frame Relay 场景的普遍裁决。

RFC 2427 后来取代的是 RFC 1490 和 RFC 1294 的一般多协议 Frame Relay 规范，并没有取代 RFC 1973。IANA 编号也只证明命名空间仍有登记。它们都不证明当前采用率、厂商默认、某次事故或任何客户结果。RFC 1973 的 Security Considerations 更明确表示未讨论安全问题，不能从封装格式补出认证、完整性或保密性。

来源