摘要

  • GAL 值 13 是例外标记，不是普通转发标签：在所述 MPLS-TP 规则中，它位于栈底，后接 ACH；正常用户面报文不得出现 GAL，GAL 不得重复，接收者也不得依据 GAL 把报文转发给另一节点。
  • ACH 以二进制 0001 开始，包含版本和 16 位 Channel Type。Channel Type 由 IETF 审查的规范和 IANA 注册表赋予互操作含义；注册本身不证明某个接收端已启用该类型，也不证明运营者已授权发送者使用它。
  • G-ACh 不得承载用户流量。它提供一个公共维护信封，适用于伪线、LSP、拼接段和 section；它并没有把 OAM、信令或管理协议的安全、状态机或策略一并定义出来。

接收者在弹出 MPLS 或伪线标签后，若无法处理所示 Channel Type、没有通过范围外方式表明支持、发现本地禁用的实验类型、看到 GAL 后 ACH 首个四位不是 0001，或无法识别 ACH 版本，就必须丢弃该关联信道报文。这里的“支持”不是通过 GAL 自动协商出来的能力。对于 RFC 5586 的 LSP 示例，只有两端标签边缘路由器可以发起新的 G-ACh 报文；路径中的节点可以处理并响应，这同样不是一般性的转发授权。

RFC 7026 删除了 ACH TLV。原因不是维护信封失去作用，而是 TLV 的不可预测格式和长度令硬件处理困难，且没有已分配的 Channel Type 使用它们；G-ACh 报文不得再由 ACH TLV 置于其前面。RFC 7214 将原先分散的 G-ACh 注册表集中到共同的 IANA 位置，并将 Channel Type 注册表重新命名以明确其通用性；这项整合没有改变既有分配。当前 IANA 表采用 IETF Review，包含维护、测量、信令和管理用途，也保留实验范围。

GAL 与 ACH 既不是认证，也不是授权。它们不验证发送者身份、不协商能力、不批准管理动作、不建立 LSP，也不授予转发权。安全要求属于相应 Channel Type 规范和运营策略；拥塞、应用层安全和特殊处理资源仍然是实现者与运营者的责任。资料没有给出逐厂实现覆盖率、生产流量、启用率或畸形报文丢弃频率，因此不能从注册表推导这些事实。

来源