摘要

  • 在 RFC 5251 的 shuffling 模式中，入口 PE 把 Session 与 Sender Template 里的 CPI 换成 PPI，出口 PE 再执行反向转换。
  • 因而，客户看到一条始终完整的会话，并不能证明当时使用了哪一版 PIT、内部选择了哪个端口、物理资源是否按预期编程，或业务数据是否真正抵达。

一条会话为何要换两次名字

客户边缘设备发起的是一个很直接的意图：把自己认识的一个端口连接到另一个端口。请求进入运营商网络后，内部资源不再以客户的地址体系命名；到达远端边缘时，客户熟悉的名字又重新出现。若只看两个 CE，会话似乎从未改变。

RFC 5251 把这种执行方式称为 shuffling。入口 PE 改写 RSVP-TE 的 Session 和 Sender Template 对象，用运营商端口标识 PPI 代替客户端口标识 CPI。出口 PE 按相反方向查询映射，把 PPI 还原成 CPI。客户会话之所以完整，恰恰是因为底层名字被有纪律地改变了两次。

这种设计保护了两个地址域的独立性，也允许运营商隐藏内部拓扑。问题不在转换，而在把“同一会话”误读成“同一物理事实”。会话连续只说明控制平面的抽象被维护；它没有自动观察映射是否新鲜、交叉连接是否正确、光路是否连续，更没有测量应用结果。

CPI、VPN-PPI 与 PPI 不是三个别名

CPI 标识端口的客户侧，PPI 标识端口的运营商侧，VPN-PPI 则是在 L1VPN 客户地址域里表达 PE 端口。PPI 由运营商控制，CPI 与 VPN-PPI 的地址由 L1VPN 管理者控制。三者指向相关对象，却来自不同授权边界。

未编号端口可以为了便利让 PPI 与 VPN-PPI 采用相同的端口索引。但数值相同不等于身份相同。若日志只写“端口 17”，却不保存这是 CPI、VPN-PPI 还是 PPI，也不保存 VPN 上下文和观测边界，那么它删除了重建转换所需的关键事实。

控制通道也有同样的局部性。CE 与 PE 的控制通道地址必须在一个 L1VPN 内唯一，却不要求跨所有 L1VPN 唯一。因此，地址必须与 VPN 明确绑定。脱离上下文的地址不能被提升为全局身份。

真正作出决定的是哪一版 PIT

每个运营商边缘维护 VPN 专属的 Port Information Table。PIT 保存 CPI 与 PPI 的对应关系，并为本地端口保存 VPN-PPI 信息。条目可以来自配置，也可以吸收 RFC 5195 与 RFC 5252 所描述的 BGP 或 OSPF 发现结果。

发现解决“知道了什么”，shuffling 执行的是“此刻用了什么”。请求到达时，入口 PE 在 L1VPN 上下文中选择 PIT，解析目标 CPI 对应的 PPI，然后改写信令对象。远端 PE 又依赖自己的 PIT 状态进行反向转换。两次查询共同维持客户看到的单一会话。

如果收据没有记录准确的 PIT 代际，就无法复演决定。一行格式正确的映射可能已经过期、配置错误，或被放进错误的 VPN 上下文。协议仍可非常规范地执行一次错误转换。RFC 5251 的安全讨论因此强调管理与配置保护，并建议考虑数据面验证来发现意外误配置。它划清的是证据边界：信令证明信令转换，数据测试才观察连接的结果。

被隐藏的路径并未因此消失

在运营商网络内部，信令携带 PPI；在两端边界，采用 shuffling 时必须一致地处理所有 RSVP-TE 消息。若只改写其中一部分，同一会话的状态会互相矛盾。客户看到一个 LSP，以及两台 PE 之间的一条虚拟链路；运营商看到组成这条服务的实际分段与资源。

PE 可以过滤返回给 CE 的拓扑信息，Record Route 与 Notification 对象也可能在边界被编辑或移除。这是合理的服务隔离：购买连接不等于获得运营商内部地图。但审计不能从干净的客户视图反推被刻意隐藏的路径。“一条会话”并不意味着一个物理跳、一根光纤、一个波长，也不保证路径从未变化。

shuffling 还不是唯一实现方式。运营商可以采用 stitched 或 nested 模式，把 PE 到 PE 的会话、既有 LSP 或 forwarding adjacency 关联到客户请求。RFC 5150 和 RFC 4206 分别为拼接与层级 LSP 提供机制。对客户而言结果可能相似，内部收据却完全不同。因此，执行模式本身就是证据字段，而非可忽略的实现细节。

Resv 没有看见物理交叉连接

源 CE 选择它知道的目标，运营商策略限制可接受的端口拓扑，入口 PE 解析身份并计算内部路径，目标 CE 最终接受或拒绝。每一步都重要，也都只回答一个有限问题：谁提出意图、谁允许、哪个名字被解析、对端是否接受。

Path 或 Resv 仍是控制平面收据。资源预留、标签或波长编程、保护状态、物理连续性和客户流量属于后续层次。即使 CE 到 CE 测试成功，它也只证明测试实际发送和接收的内容；时延、丢包、SLA 与应用成果仍需各自的观测。

客户提供 Explicit Route Object 也不会获得内部路径的最终权威。PE 可以拒绝 ERO；在允许松散形式时，PE 仍会计算并插入运营商路径。客户意图可以约束服务，却不能替每一个内部跳点背书。

让证据跨过下一次配置变更

一条可审计链应从 L1VPN 身份、控制通道、原始源 CPI 与目标 CPI 开始。随后保存 PIT 的准确版本、条目来源、解析出的 PPI，以及 Session 和 Sender Template 改写前后的值。出口侧还要保存反向查询、恢复后的 CPI 和目标 CE 的回应。

在这些事实之后，才是 RSVP 状态、资源编程、交叉连接、数据面测试与业务观测。用一个“session up”字段覆盖整条链，会在下次配置变更后抹掉解释历史会话的能力。拓扑可以不向客户公开，但运营商内部必须保有受保护、可关联的轨迹，把客户抽象连接到隐藏分段。

Lu Heng 关于现实层的纪律在这里极其具体：一个地址域里的名字，不是另一个地址域里的同一事实；转换成功，不是物理连接已被观察；会话连续，也不是业务连续。运行中的系统若要承担责任，就必须在每个边界准确记录自己转换了什么，以及真正观察到了什么。

来源