摘要

  • LAN 上的 EtherType 能区分上游分配与下游分配，却不足以指出哪个上游邻居的标签空间适用。接收端还要结合 context label 与入口 LAN 接口选表。
  • MPLS 隧道通过内层标签之上的栈保存根身份；如果 PHP 会删除最后一个上下文选择器，RFC 5331 要求关闭 PHP。

识别类型只是第一道门

多个上游 LSR 共享一个 LAN。帧的 EtherType 表明栈顶属于上游分配，但数字 L 可以在每个邻居的空间中分别出现。接收端仍不知道该查谁的表。

RFC 5331 使用一跳 MPLS 隧道补足身份。最外层是上游 LSR 分配的 context label；下一层才是与 FEC 绑定的上游标签。接收端把 context label 与入口 LAN 接口一起查找，选出邻居空间，再解释第二层。

因此 EtherType、入口接口、第一层标签、第二层标签和所选表是连续但不同的回执。采集链若在不同阶段丢掉其中一项，会留下格式正确却无法复现决定的片段。

外层标签还是表选择器

在 MPLS 隧道中，内层上游标签的上下文来自它上方的标签。外层栈不仅运输数据，还告诉下游节点隧道根是谁。

PHP 习惯在倒数第二跳弹出外层标签，减少出口工作。但如果出口仍需要该标签选择 context-specific table，优化就删除了语义输入。RFC 5331 因而要求关闭 PHP。

这不是把所有 PHP 视为风险。判断条件是：被删除状态是否还有未完成的授权用途。若答案是“用于选表”，就不能先删后猜。

只保留内层号码无法修复。相同值可以在平台表、下游分配表和多个上游邻居表中分别指向不同 FEC。默认落入任何一张表都是新决定。

根地址是协议身份，不是机箱别名

下游 LSR 为每个唯一隧道根维护独立的 Upstream Neighbor Label Space。根由 head-end IP 表示。同一设备用不同 head-end 地址时，RFC 5331 仍要求不同空间。

两个隧道只有在完整条件成立时才能共享空间，包括使用同一根地址和同一分配者。标签分发协议所写的 assigner 地址必须与隧道建立协议的 root 地址一致，即便两者不是同一种协议。

资产库可以知道两个地址属于一台机箱，但不能自动把协议身份合并。应保存两项声明、来源、时间和匹配结果。别名关系只是一条候选证据。

GRE 把源地址放进查表键

有信令的隧道显式命名根；人工配置的隧道要配置根。GRE 甚至可通过封装直接形成，此时 IP 源地址被视为根。

源地址由此参与内层标签语义。地址变化、重写或非对称终结可能把同一数字引向另一空间。源地址正确只说明 RFC 查表坐标，不证明发送者被授权。

同号究竟是安全复用还是碰撞

context label 在同一 LAN 内必须唯一。规范给出人工配置和受限的 IPv4 主机位生成方法。若同一 LAN 上两个接口的低 20 位相同，其他 LSR 很可能把包送错。

相同号码出现在不同 LAN 接口上却没有歧义，因为入口接口属于上下文。全局去重会制造假冲突；漏掉 LAN 范围会错过真冲突。

自动方法还依赖 IPv4、掩码和保留值边界。IPv6-only 接口不能假装满足这条生成路径。

已安装不等于已知道对端支持

上游分配是可选功能，只有在已知下游 LSR 支持时才能使用。RFC 5331 把如何获得这种知识留给应用与分发协议。

本地镜像包含代码、IANA 有编号、配置界面有开关，都不能独自证明特定对端、隧道和应用已经同意。能力回执需要来源、范围、获得时间与失效时间。

来源与证据边界

这些来源证明规则、历史与登记，不证明当前实现、隧道、PHP 状态、根地址、上下文表、碰撞、误路由、组播树、转发或交付结果。