摘要

  • RFC 1315 为 Frame Relay DTE 定义管理对象，并把 Frame Relay 看作一个物理网络接口通向多条虚连接或邻居的多接入媒介。
  • DLCMI 对象规定状态查询间隔、完整查询间隔、未响应阈值和统计窗口；MIB 还把电路组与错误组单列。
  • 代理依据计数规则把接口标记为 down，是关于该受管接口的判断；它不证明每条虚电路、远端、报文或应用结果均已失败。

一个附着点，多种关系

RFC 1315 的操作模型把一个物理接口与其上的多条虚连接放在同一层级。这样做有诊断价值：管理者可以把虚电路同相应物理连接归组，而不必把每个虚电路想象成独立的物理线。但归组不是合并。MIB 仍然设置 DLCMI、circuit 和 error 三组，因为它们回答不同的问题。

电路表的一行可以描述某个 DLCI 和虚电路；接口记录可以描述该接口的管理参数；错误对象可以计数特定观察。三者共享一个物理附着点，却不能相互代言。电路表中有一行不证明其传过业务；接口被判为 down 不叙述每条虚电路先前、随后或别处发生的状态；计数器也不说明哪项应用被影响。

把沉默变成有范围的状态

DLCMI 部分让界线格外清楚。它定义连续状态查询之间的 polling interval、完整查询间隔、允许多少未获响应的查询后将接口判为 down 的 error threshold，以及在多少轮询间隔中计数的 monitored events。代理不是凭一次沉默就宣布失败，而是在配置好的观察窗口内对特定缺失响应计数，再使用配置阈值作出本地管理判断。

因此，down 能支持的说法是精确的：在某接口、某管理方案和某时间窗口下，代理按既定规则作出了接口状态判定。RFC 并不由此证明运营商故障、远端设备不可用、所有 VC 已改变状态、用户流量中断或业务损失。把它简化成“网络全挂了”，会把对象的范围换成没有记录支撑的因果故事。

frDlcmiState 也不应被夸大。它说明接口上活动的 Data Link Connection Management 方案，并蕴含该接口使用的 DLCI。这是接口配置/状态事实，不是整条网络路径的身份，不是远端证明，也不是所有相关虚电路可用的凭证。RFC 1293 在本系列中讨论已知 DLCI、未知协议地址时的 InARP 问题；RFC 1294 讨论 VC—封装分配和帧标签。RFC 1315 讨论的则是共享附着点如何被管理与判定。

变化本身也需要记录

RFC 1315 指出虚电路在正常运行中可以新增、删除或改变可用性，并定义一个与 SNMP Link Up/Link Down 相呼应的 trap。trap 是关于受管事件的通知，不是每帧审计，不保证通知被接收，也不证明下游业务结果。它必须和接口记录、电路快照以及独立的流量或服务证据一起阅读。

一个可复核的事件时间线应并列保存接口状态变迁、未响应查询计数、阈值和窗口、circuit 表快照、trap、原始管理交换、流量计数与服务探测。接口状态说明代理作了什么判断；计数说明它数到了什么；电路行说明 MIB 当时表示什么。任何一个都不能取代另一个。

来源与证据边界

本文依据 RFC 1315《Management Information Base for Frame Relay DTEs》（1992 年 4 月）。它支持一个物理接口/多条虚连接的模型、DLCMI/circuit/error 组、轮询与完整查询间隔、阈值和统计窗口、VC 可用性变化及相关 trap。它不证明任何现实接口、运营商、远端、虚电路故障、报文事件、客户影响、修复或恢复。