摘要

  • RFC 3186 在入口改写 PPP/POS 帧的一个或两个字节，让 MAPOS 网络按内部地址转发，再在出口恢复原值，因此无需增加封装头就能呈现点到点链路。
  • 真正的服务依赖一对 MAPOS 地址、两端端口模式、双向转发稳定和逐路径隔离；OAM 路径数据库只描述路径，并不负责转发。

这份 2001 年 12 月发布的文件属于 Informational。IESG 特别说明，它不是 IETF 工作组成果，也不是 Standards Track 文件，未必经历同等广度和深度的社区审查。因此，它记录了一种方案及一次参考实现测试，不能自动证明广泛部署。

方案利用了帧格式的相似性。PPP over SONET/SDH 的开头是固定地址和控制值，MAPOS 则在相近位置放内部目的地址。入口交换机把固定字节换成远端端口的 MAPOS 地址，网络据此转发，出口交换机再恢复 PPP 固定值。MAPOS v1 改一个字节，MAPOS 16 改两个。

客户看不到额外封装头，但状态没有消失。它转移到了交换机：重写目的、端口模式、C2 信号标签、内部路由、端口映射与隔离规则。透明减少了客户必须处理的复杂性，却增加了运营者必须保存的证据。

切换到 PPP 隧道模式并非一个布尔开关。交换机至少要在客户端口停用 NSP 与 SSP、停用 MAPOS 广播和组播转发、按扰码方式设置 C2，并启用指向指定目的地址的帧头重写。回到 MAPOS 模式时顺序反转。

控制台可以把这些动作压成“PPP mode”，运行代码却会逐项执行。一端先切换、标签已变而重写未生效、控制协议未停用，都可能形成中间态。可靠记录必须保存转换过程，而不只保存最终标签。

建路时，运营者在两端选择未使用的 MAPOS 地址对并配置端口。文件要求两个方向的路由与帧转发都稳定后，路径才算建立；在此之前，客户侧链路应保持 down。只有随后，两个 CPE 才透明交换 PPP LCP 控制。

地址对标识的是运营意图，不是交付回执。它不能单独证明两端模式一致、双向已收敛、某帧成功通过或应用收到数据。

RFC 3186 建议用路径数据库管理地址对，防止重复。示例行包含用户、速率、模式、地址对和状态。但文件明确说：数据库只供 OAM&P 使用，不参与帧转发。

“Up and running”因而是一项管理断言。实际转发仍由 SSP 状态、交换机端口和重写功能完成。数据库可以在转发改变后尚未更新，也可以保持正确而下一帧仍因别的原因丢失。

拆除路径同样分层。运营者先停用客户端口，可以更新数据库，之后可把端口恢复为 MAPOS 默认。目的端口停用后到达的帧应静默丢弃。这个静默不会告诉发送者是配置、路由、端口还是库存状态导致结果。

故障可见性也不对称。客户到边缘交换机的光路在本地终止，近端会看到 SONET/SDH 告警，远端物理接口却可能仍为 up。远端只能等 PPP LCP Echo 超时，才出现“物理链路 up、线路协议 down”。

超时证明的是预期回应未在期限内到达。它不能独自定位故障、判断单向还是双向中断，更不能说明应用结果。MAPOS 云内的 SSP 可以处理拓扑变化，而客户只看到端到端症状。

点到点外观也不等于专用带宽。MAPOS 协议层没有 QoS，POS 没有流控，文件承认端到端吞吐难以保证。运营者要准备足够的交换机间容量，并在超卖结构中实现逐端口公平。

参考延迟测试有明确边界：指定设备、OC12c 单向 30% 负载、固定 FCS 和扰码、每种帧长 25 次、每次 150 秒，并报告按 20 纳秒精度取整的置信区间。在该条件下交换机快于对照路由器，不代表所有负载、厂商、拥塞或应用都如此。

安全章节更直接暴露了权力边界。文件认为 CPE 难以控制内部 MAPOS 或注入另一条流，却同时强调逐路径隔离极其重要，要求避免重复路径，并在所有交换机都具备隔离前反对混合原生 MAPOS 与 PPP 隧道。

MAPOS 帧没有源地址字段。在混合环境中，这会增加判断帧属于哪条路径的难度。客户看不见内部，不能反向证明内部一定正确隔离。

RFC 3186 的历史价值不在于某种旧式传输还能否复兴，而在于它清楚展示了抽象的代价：服务表面越简单，解释权越集中到隐藏控制面。要重建事实，必须同时保存服务订单、地址对、端口、每项模式转换、双向收敛、数据库版本、隔离状态、告警、LCP 回声与帧观测。透明链路只是其中一层。