摘要

  • RFC 3020 为多链路帧中继链路束规定了四种激活方式：至少一条、全部、达到指定数量，或者采用实现自定义规则。
  • 因而，bundle 的 up 只证明选定的激活条件已经满足；成员数量、可用带宽、时延、名称错配、序列异常、重排丢失和最终交付仍是不同的证据层。

绿色告警先回来了。

四条物理线路中，只有一条恢复。逻辑接口却从 down 变成了 up。若值班人员只盯着总览屏幕，这像是一场很短的故障；若查看 RFC 3020 定义的激活规则，它可能只是默认的 class A 正常工作：至少一条成员链路在线，整个链路束就可以在线。

状态没有撒谎。被省略的是状态后面的条件。

RFC 3020 于 2000 年 12 月发布，为 FRF.16 的 UNI/NNI Multilink Frame Relay 功能定义了一组管理对象。MFR 把多条物理链路反向复用为一个逻辑链路束，让上层 Q.922 数据链路把它视为一条物理接口。这个设计既需要汇聚，也需要把不同路径到达的帧或分片恢复到正确顺序。

它留下的历史价值，不只是一套旧式帧中继 MIB。它准确展示了一个至今仍常见的事实：聚合对象的健康状态不是自然事实，而是策略对多个组件状态执行计算后的结果。

一个逻辑接口，两个编号权威

RFC 3020 同时把成员链路和链路束放进通用 Interface MIB。每条物理成员链路有自己的 ifIndex，逻辑链路束也有一个 ifIndex。但在媒体专用的 bundle 表里，管理者创建行时选择的是 mfrBundleIndex，而通用接口编号由 agent 选择。

标准因此定义了双向映射：从 ifIndex 找到 mfrBundleIndex，也从 bundle 索引找到通用接口。两个数字不同，不代表有两个链路束；它们可能是两个管理命名空间对同一逻辑对象的引用。

创建过程也分层。管理者把 mfrBundleRowStatus 设为 createAndGo，agent 创建 bundle 行并在通用接口表中生成相应接口。实现还可以支持先 createAndWait 再激活。成员链路通过自身物理接口的 ifIndex 建行，并用 mfrBundleLinkConfigBundleIndex 指向一个已经存在的 bundle。

因此，行存在只证明配置对象存在。它不证明成员协议已经到达 up，不证明汇聚接口满足激活条件，更不证明远端收到了一帧业务数据。

“够用”有四种写法

决定链路束何时激活的是 mfrBundleActivationClass。

Class A 要求至少一条链路 up；class B 要求所有链路 up；class C 要求达到 mfrBundleThreshold 指定的数量；class D 交给实现自定义。默认值是 class A。

当 class C 生效时，活跃成员数达到阈值，逻辑链路束进入 operational up/active；跌破阈值，则转为 inactive。在阈值不适用的 class 中，对象返回 -1。Class D 是否使用该阈值，要看实现。

RFC 3020 还把 bundle 的 linkUp 和 linkDown 通知明确绑定到这个判定。当足够多的成员链路 up，逻辑接口的 ifOperStatus 从 down 变成 up；数量不足时反向转换。

设想一个配置了四条成员链路的 bundle。Class A 下，一条存活即可变绿。Class B 下，三条存活仍是 down。Class C 的阈值若为二，第二条线路改变总体状态，第三和第四条只改变容量，不再改变那一个布尔值。Class D 则要求观察者拿到实现版本和规则，才能重建为何变绿。

同一个 up，可能描述完全不同的剩余能力。要解释它，必须同时保存激活类别、阈值、配置成员数和活跃成员数。

容量从来不是那个绿色位

RFC 3020 把 mfrBundleLinksConfigured 和 mfrBundleLinksActive 分开，也单独报告 bundle 的可用带宽。

这种拆分很重要。链路束 up 不意味着活跃成员数等于配置成员数。可用带宽也不等于规划容量。采用 class A 的四链路束可以在只剩四分之一物理资源时合法显示在线。

带宽字段本身仍是 agent 报告的汇聚资源状态，不是应用吞吐量。它没有携带某次流量测试的起止时间、负载、拥塞、重传、远端接收或业务完成信息。它比一个布尔状态更丰富，却仍没有跨过端到端边界。

标准还分别暴露了最大成员数、是否分片、最大分片、序列号长度和最大差分时延。这些对象解释了聚合系统的额外责任：不同链路的速度与传播条件不同，接收端必须重排。

所以，“最低连通性恢复”和“承诺容量恢复”应当是两条告警。把它们折叠成一个绿色位，技术上省事，治理上却会制造含混。

错序事件不是丢帧计数器

mfrBundleResequencingErrors 记录重排错误事件。RFC 3020 特别说明，一个事件可能对应多帧丢失。若收到序列 56、59、60，并判定 57 与 58 丢失，计数器只增加一次。

因此，增量一说明 agent 记录了一个错误事件，却不能直接换算成丢了一帧。反过来，计数不变也不能证明交付完整：还要考虑轮询窗口、计数器重置或回绕、agent 重启以及未由该对象覆盖的失败。

每条成员链路还有自己的往返时延、无效控制帧、定时器到期、疑似环回、意外序列和 bundle 名称错配计数。成员状态来自 FRF.16 状态机，并不是“电信号有/无”的简单复制。

名称错配通知尤其能说明证据责任。它同时报告本端配置名、此前看到的远端名、当前成员报告的远端名；标准还提醒，所谓“配置值”也可能是自动生成的。通知证明管理视图与协议视图发生不一致，却不能仅靠这一条通知裁定最初错误来自本地、远端、自动化还是陈旧状态。

这些成员证据可以说明一个仍为 up 的 aggregate 为什么已经劣化，却仍不能替代远端业务收据。

修改门槛，也会修改下一次“恢复”

激活类别、阈值、定时器、分片和序列号选项的最大访问权限是 read-create。管理者还可能创建、修改和删除 bundle 或成员行，并决定成员属于哪个 bundle。

这不代表每个合规实现都必须允许全部写操作。RFC 3020 的 compliance 条款把不少对象的最低权限降为只读：写能力可以不提供，但实际采用的值必须可报告。MIB 声明的最大权限、具体 agent 的能力、当前主体获得的授权，是三个问题。

如果写权限存在，物理线路不发生任何变化，策略修改也能让总体状态变化。把 class C 阈值从三降到二，两条存活链路就会从“不足”变成“足够”；把 class B 改为 class A，也可能立即出现同样效果。

新状态依然准确。问题在于，事故报告若只写“链路恢复”，就会把政策放宽写成设施修复。

安全章节明确警告，不受保护的 SET 可能损害网络运行。仅使用 SNMPv1，即使所在网络有 IPsec，也不能决定安全网络里的哪个主体有权 GET 或 SET 哪些对象。RFC 推荐 SNMPv3 的 USM 与 VACM，并把正确授权配置交给运营方。

身份认证证明谁发起修改，访问控制证明他是否有权修改。两者都不证明新门槛满足客户或业务对容量和完整性的要求。

标准轨道不是部署证明

RFC 3020 是 Proposed Standard。RFC 9141 后来更新了它，但更新内容是替换已经退出的 IETF FTP 服务引用，并未改变 MFR 的激活语义。

这些来源能证明标准的设计与文档谱系，不能证明某个厂商完整实现了对象、某家运营商部署了 MFR、某次故障按此机制恢复，或者某位客户获得无损服务。本文不作这些推断。

Lu Heng 的 Reality Layers 可把证据拆开：行创建、激活策略、成员协议状态、汇聚接口状态、帧完整性计数和接收结果各在一层。Running-Code Primacy 对 class D 尤其重要，因为其规则明文交给实现。Minimum Initial Specification 则解释了为什么一套有限 MIB 可以有用，而无需假装它已经是端到端业务验证系统。

这些只是公开说明的分析视角。Lu Heng 并非 RFC 3020 的作者，也没有为它背书。

真正可审计的句子不是“链路束已恢复”，而是：“在这一版本的规则下，这组成员此刻满足了这个门槛。”再强的结论，需要再强的一组收据。

来源