摘要

  • RFC 3919 为 RMON-2 代理提供了一套共同的 IPv6 与 MPLS 解析路径名称，但这些名称并不等于对其承载服务的完整说明。
  • MPLS 条目写下了最清晰的边界：入口处可以区分单播与组播，但其子协议“无法系统地识别”。

远程监测从一个看似简单的问题开始：探针能识别哪些类型的数据包？RMON-2 的协议目录用一份能力清单来回答。管理软件据此把计数器、主机表或会话表关联到某条有名称的封装路径。但目录既不是对网络流量的普查，也不会因为管理员添加一行配置就让探针突然学会新的解析方式。RFC 2021 将这种能力称为有限扩展：软件必须预先掌握相关的分用逻辑，配置才可能把解析范围向上延伸一层。

RFC 3919 于 2004 年 10 月作为信息性备忘录发布，为 IPv6 和多协议标签交换（MPLS）补充了协议标识宏。它的目标并不宏大：让不同 RMON-2 代理之间更容易互操作。如果两台探针用不兼容的名称描述同一条数据包路径，管理工具便难以可靠比较各自按协议划分的视图。备忘录特别指出，即便不使用这些标识，也可以实现符合 RMON-2 的系统。它们是共享词汇，不是新的符合性测试，也不证明所有探针都支持它们。RFC 3919；RFC Editor 记录

文档内部的对比很有启发性。在 IPv6 中，下一层协议由一个八位组的 Protocol 字段选择，因此标识可以沿着已知分用值继续向下。RFC 3919 将 ICMPv6 标为协议号 58，也把原生 IPv6 上的 UDP 与 IPv6-in-IPv4 隧道中的 UDP 分成两条路径。ether2.ip6.udp 和 ether2.ip.ipip6.udp 不是可以互换的标签；它们保留了解析器经过的封装层次，而不只是最后都写着 UDP。

MPLS 的分支则更短。RFC 3919 定义 mplsu 和 mplsm 两个入口，分别用链路层的 EtherType 0x8847 与 0x8848 区分单播、组播，并列出其他链路类型上的编码。之后，两条定义都明确停下：MPLS 的子协议无法系统地识别。这不代表 MPLS 永远不会承载 IP，也不表示标签后的包一概无法解析。准确的意思是，这组 RMON 标识没有为 MPLS 条目之下定义一套通用、可共享的子协议树。RFC 3032

这条边界防止目录条目承诺超出自身描述范围。探针或许知道外层帧格式，或能识别某个 MPLS 入口，却未必能为标签栈后面的每种载荷或服务给出稳定一致的名称。路由标签本身并不声明协议家族；解释它还要依赖其他机制和上下文。RFC 3919 并不试图从标签中推导这种语境，也没有承诺不同代理会为同一条目录项分配相同的本地编号。

“协议名称”和“索引”也不能混为一谈。RFC 2895 定义 protocolDirID 及其参数字符串的编码规则；而计数表使用的是 protocolDirLocalIndex。RFC 2021 明确，这个整数只在某个 SNMP 实体内部有意义。它是指向该探针本地目录的句柄，不是可以复制到另一台探针数据中、并默认含义相同的全球标识。互操作性依赖共享的描述规则和谨慎解释，而不是假设每个代理都采用同一套本地编号。

所以，RFC 3919 留下的是一道很具体的边界：IPv6 暴露了标准化的下一层字段时，标识词汇可以描述更深的解析路径；MPLS 子层在此框架中没有类似的系统映射时，描述就停在外层入口。能力清单能帮助管理者提出更好的问题，但不能证明探针实际看到了某个包、正确解析了它、在某个时间窗口内对它计数，或识别了标签背后的商业服务。要支撑这些结论，需要观测记录和额外证据，而不是给表格再添一个更长的名称。

来源