摘要

  • 客户可以在获准的 CE 集合中请求连接，也可以选择部分客户侧链路；运营商仍掌握 PE 到 PE 的路径计算、资源分配、接纳规则和核心拓扑。
  • 运营商可以隐藏自己的网络，却至少会知道客户 CE 的地址与位置；合同登记、信令认证、光交叉连接状态和业务实际送达是四类不同证据。

请求里有起点和终点，却没有核心路由的授权书

一条连接请求从客户边缘发出时，最容易产生的错觉是：既然客户发起了连接，客户就控制了连接。RFC 5253 把这句话拆成两半。客户控制的是 L1VPN 的连接拓扑——请求在哪些客户边缘之间建立、修改或删除连接。运营商控制的是自己的网络——尤其是承载这条连接的 PE 到 PE 段。

这个边界不是礼貌性的分工。客户若在 Explicit Route Object 中指定运营商核心内的路线，PE 应当拒绝。客户能表达“把 A 接到 B”，不能借同一条信令表达“必须经过核心节点 X、Y、Z”。路径可以即时计算，也可以事先计算；可以由入口 PE 算，也可以交给 PCE 或管理系统；甚至可以在客户发起请求前就预建好。选择哪一种，仍属于运营商的执行面。

因此，“客户自助开通”不是“客户掌握内部路径”。自助入口只降低了发起动作的摩擦，并没有转移资源所有权、路由决策权或内部信息披露义务。真正清楚的产品说明应当说：客户拥有端点意图，运营商拥有路径执行。

没有 CE—PE 路由交换，不代表没有依赖

Basic Mode 不在客户边缘和运营商边缘之间交换路由信息。客户要取得远端 CPI，必须依靠配置、目录服务或其他面向该 L1VPN 的机制。运营商内部仍然运行路由，PE 之间仍然可以传播成员信息。

这种隔离减少了客户窥见核心拓扑的机会，也缩小了控制面的耦合。但它没有消除依赖。客户提出的目标必须落在运营商维护的 Port Information Table、成员关系、可用端口、接纳政策和资源池之内。客户请求成功与否，取决于一套客户看不到的判断。

反过来，运营商也依赖客户的意图来形成服务价值。空闲的光资源不会自动变成客户连接。双方不是一个控制器，也不是两个互不相关的系统；它们通过一条刻意收窄的接口合作。

这条接口的证据不能只有一个“成功”。至少要分别记录：客户要求了什么，入口如何判定资格，内部选了哪一个段，资源是否保留，两个边界的交叉连接是否真实存在，以及终端业务是否到达。

运营商出售的是结果集合，不是一张核心地图

RFC 5253 允许按整个 L1VPN 或按单条连接配置政策。政策可以来自客户合同。运营商可以把资源划给特定客户，也可以在同一对 PE 之间预先计算多条段，再决定哪个 VPN、哪条连接可以使用哪一段。

这使服务能够同时满足商业抽象和工程灵活性。客户买的是一个结果：在约定属性下把两个合格端口连起来。运营商保留如何实现这个结果的空间。Path Key ID 甚至可以让客户引用一条保密段，而不暴露段内路线。

但抽象越成功，越容易遮住证据缺口。一个段标识符不能证明它当前对应哪条路径。一次 RSVP-TE 成功不能说明使用的是哪版政策。一个“已预留”状态不能代替设备上的交叉连接回读。一张发票也无法证明故障发生时备份资源真的独立。

保密并不要求不可验证。运营商可以不公布每个内部节点，同时保存一条可审计的内部执行链；客户也可以不取得核心地图，却收到与合同结果相匹配的外部凭证。关键是不要用抽象名词替代事实状态。

拓扑保密不是镜像关系

Basic Mode 对运营商核心很友好：没有路由信息向 CE 分发；Record Route Object 可以过滤；Notify 消息里的内部地址可以被 PE 替换；预计算段还可以用路径键隐藏。

客户获得的保密却不是同样形状。RFC 5253 明说，运营商至少会知道 CE 的地址和位置。否则它无法把端口加入正确的 VPN、检查连接限制并建立服务。客户的其他内部拓扑可以继续隐藏，但接入点本身不可能完全匿名。

这种不对称并不自动构成不当行为。它是运行服务所需的信息结构。然而，它确实把更多观察能力放在运营商一侧：运营商既知道自己的核心，也知道客户接入点可能集中在哪些地点。客户往往只能知道请求是否被接受。

治理重点因此不是强求双方“知道一样多”，而是限制用途。CE 地址与位置应有明确目的、最小访问范围、保留期限和查询记录。运营商的核心保密也不能扩张成“任何承诺都无需验证”。可以隐藏路径细节，同时披露是否满足时延、保护、隔离或恢复承诺的证据类别。

合同认识这台 CE，协议不一定认证了这条消息

RFC 5253 把一个常被后台系统混成同一字段的问题写得很清楚。新 CE 加入服务时，会在合同和控制通道建立过程中被识别。可是控制面实体并不会仅凭这种登记就在每次信令时自动得到认证。要取得认证结果，必须真正启用 RSVP-TE 的认证程序。

合同回答“谁应当有权使用服务”。配置回答“哪个地址或通道代表它”。认证回答“这次消息由持有哪个凭据的一方发出”。完整性回答“消息途中是否被改动”。授权则回答“即使身份正确，这个请求是否允许”。

把这些问题压成一个绿色的“可信客户”会制造危险的盲点。过期凭据可能仍能认证一个已失去合同权限的实体；正确合同也可能配着未认证的控制通道；认证成功的客户仍可能请求一对被政策禁止的端点；授权正确的连接仍可能在数据面接错。

物理隔离也不是句号。RFC 说，每客户独立的物理通道“可以被认为”安全，但客户仍可能希望用 IPsec 等机制取得更高保证，而且这些机制必须可用。共享通道则需要安全机制并应当强制执行。“专线”描述结构，“完整性校验通过”才描述一次具体通信。

在出口才拒绝，政策正确，成本可能错误

连接限制既可以在入口 PE 执行，也可以在出口 PE 执行。两者都可能阻止最终连接，却不会产生相同成本。

如果规则在入口已经稳定可知，入口拒绝会在请求进入核心前终止动作。等到出口再拒绝，请求可能已经跨越多台设备，产生解析、转发和临时状态，消耗本可留给合法请求的信令资源。RFC 5253 特别提醒，出口执行可能浪费信令工作。

这说明“拦截次数”不是完整的安全指标。一个系统可以拦住全部非法请求，同时让每一个请求都走到最昂贵的位置才失败。领导层还应观察：拒绝发生在哪一跳、占用了多少临时状态、状态多久释放、是否与正常业务竞争。

已知且稳定的资格规则应尽量前移。出口复核仍有价值，但应作为纵深防御，而不是允许不可能请求遍历全网的理由。

保护标志覆盖不了所有故障组合

Basic Mode 可以调用 GMPLS 的多种恢复机制：保护 PE 到 PE 段、保护链路、恢复控制通道。列表很丰富，组合却有边界。同一个链路保护请求不能只保护 CE 到 PE 或只保护 PE 到 PE；也不能在同一模型里让边缘部分采用链路恢复、核心部分采用段恢复。完整的双归属 CE 到 CE 恢复不在 Basic Mode 范围内。

所以，“受保护连接”必须写清故障单位。它保护的是接入链路、核心段、设备、站点、共享风险组，还是完整的双归属服务？一个协议位只承诺它所定义的组合，不能被市场语言扩成普遍韧性。

故障之后也要分层计时。保护请求被接受，不等于备份资源独立；控制面切换成功，不等于光交叉连接已经换路；光路恢复，不等于客户应用会话已经恢复。每一步都需要自己的时间戳和结果。

专用光路仍然可能把数据送错地方

专用 Layer 1 连接比共享介质更难截获，单条连接归属于一个 L1VPN 也提供了有价值的隔离。RFC 5253 仍然把 misconnection 列为安全风险：交叉连接错误时，数据可以抵达错误消费者，而所有“专用容量”的描述仍然看似成立。

成员政策能降低风险：连接只能发生在同一 L1VPN 的 CE 之间。但政策检查并没有观察最终光信号。对敏感数据，客户仍应在自己的网络层采用保护，例如在 IP 业务上使用 IPsec。

最强的证据链必须由双方拼合。运营商回读交叉连接和资源状态；客户验证远端身份并做端到端业务探测。任何一方都不应仅凭自己的控制面确认，替另一方证明其不可见的执行结果。

让两套权力保留两套凭证

每次连接至少应保留以下相互关联但不合并的记录：合同版本和合格 CE 集合；控制通道凭据；源端、目的端和请求属性；入口政策决定；内部段和路径计算版本；资源接纳；两侧交叉连接回读；保护范围和实际恢复测试；被过滤或替换的拓扑字段；客户侧加密与端到端送达。

客户不必拿到核心地图才有资格质疑服务。运营商也不必公开拓扑才能证明客户从未获得内部路由权。双方需要的是在故障前约定好的证据接口。

RFC 5253 的价值不在于把控制权做成一个模糊的“共管”。它把意图与执行之间的接缝画出来。可靠治理的任务，是让这条接缝可以审计，让两侧各有负责人，并且永远不把端点选择、路径保密或信令成功误写成端到端交付。

Sources