摘要

  • RFC 1595 把 SONET/SDH 性能记录拆成段、线路、通道与虚支路，也区分近端、远端、当前窗口和历史窗口；离开这些坐标，整数就失去证据边界。
  • 某层连续出现十个严重误码秒时，不可用状态从第一个严重误码秒开始计算。如果这十秒跨过 15 分钟边界，上一窗口中的 SES、UAS 等值可能在下一次读取时发生变化。
  • RFC 2558 与 RFC 3592 允许代理在实时显示后回溯修正，也允许用十级延迟线把结果整体推迟十秒。前者保留即时性，后者保留首次读出的稳定性。

窗口关了，判断还没有完成

设想一个通道在 14 分 57 秒开始出现连续严重误码。15 分钟窗口结束时，管理站已经可以读取“最近完成”的区间 1，但代理还没有看到完整的十秒序列。几秒后，第十个严重误码秒出现，状态机才有足够证据判定：不可用时间应从第一秒算起。

于是，已经归档到上一个窗口的若干秒需要重新分类。物理事件没有倒退，标准也没有改写光纤上的过去；改变的是管理账本对那些秒的归属。RFC 1595 直接承认：若十秒判定跨越 900 秒边界，在新窗口最初几秒连续两次读取上一窗口的通道、线路或虚支路表，SES 与 UAS 可能不同。

这正是文章的核心。一个区间能够在编号上“完成”，却在证据上仍处于暂定状态。把第一次 GET 保存成没有版本、没有读取时刻的最终事实，才是后来争议的来源。

十秒为什么能影响过去

在线路、通道和虚支路层，不可用状态由连续十个严重误码秒触发，而且十秒全部算入不可用时间。恢复则要求连续十个非严重误码秒，这十个干净秒不计入不可用时间。

可用时，各层相应的误码计数继续增加；不可用时，该层只有 UAS 增加。因而十秒规则并非简单的告警防抖。它决定某一秒属于 ES、SES、CV、SEFS，还是属于 UAS。第一个严重误码秒刚出现时，代理只能看见现象，不能知道九秒后的分类结果。

如果状态机在每个 15 分钟边界清零，问题会被粗暴切断。但标准明确保留跨区间的状态。计数器换了行，判定链没有换历史。

每个数字先属于一个层

SONET/SDH 设备并不在每个节点终结全部层次。再生器可以只处理 Section，对更高层透明；分插复用器和数字交叉连接设备终结 Line；终端复用器还可能终结 Path 与 VT/VC。RFC 1595 用不同的接口条目以及接口栈保存这种结构。

层次不同，观测源也不同。Section 的编码违例来自 B1，Line 来自 B2，Path 来自 B3，浮动 VT 使用 V5。丢失信号、丢帧、AIS、指针丢失与远端缺陷各有适用层。一个汇总仪表上的“线路错误”可以方便值班，却不能替代故障定位。

ifOperStatus=down 也只是投影。组合的介质/Section/Line 条目会因相应缺陷而下线，Path 条目则根据通道状态下线。它说明哪个管理表面被判为 down，却没有单独指出哪块设备、哪段光纤或哪个远端环节是根因。

远端不是近端的镜像副本

标准为线路、通道和虚支路分别设置近端与远端性能表。远端通道数据来自 G1 通道开销字节中的远端块误码信息。指标名称可能相同，但证据是经另一条观测路径返回的。

RFC 2558 进一步规定：同层或更低层存在入向缺陷时，远端的一秒统计应标为 absent。这里最危险的清洗操作，是把缺失补成零。零表示在适用规则下没有计到事件；absent 表示这一秒没有可用的远端证据。越是在底层故障破坏观测通道时，虚假的零越容易制造“远端干净”的错觉。

要么修正，要么延迟

RFC 2558 把 RFC 1595 的时间难题展开为两种实现。第一种让性能计数近实时出现，但在十秒序列完成后回溯调整 ES、SES、SEFS、CV 与 UAS。序列跨界时，调整会落到上一窗口。

第二种把每秒的近端/远端违例计数和告警标志送入十级延迟线，等状态确定后再更新性能表。这样首次公开的分类较稳定，代价是计数比现实慢十秒。RFC 3592 在 2003 年继续保留这一机制。

两种做法都可以忠实。问题出在采集器既要求立刻，又假设第一次读取永不变化；或者看见十秒延迟，就把合规设计误报为设备迟钝。真正需要保存的是实现策略、代理历元、轮询时间、旧值、新值和修正原因。

RFC 2493 又给 15 分钟历史增加了完整性语言：当前表、历史表和可选汇总表彼此分离，并记录已过秒数、有效区间与无效区间。设备重启或代理取数失败时，历史不必天然完整。RFC 1595 的 96 个区间是 24 小时上限；它要求至少保存 4 个，并以 32 个为默认，而不是无条件承诺一整天连续、有效的证据。

告警的时间可以早于发送

后继文本要求 linkDown 只有在代理确定进入不可用状态后才发送，但告警对应的有效时刻要回到第一个 UAS，也就是大约十秒之前；linkUp 同理。

发送时刻回答“代理何时知道得足够多”，有效时刻回答“状态机把变化放在哪一秒”。只存接收时刻，会把故障向后平移；只存有效时刻，又会让人误以为代理当时已经知道并立即通知。两个时钟都要留下。

“严重”也有版本

RFC 2558 记录了不同标准对 SES 阈值的定义差异，并增加 sonetSESthresholdSet 表明代理采用哪一套阈值。代理不必支持全部选项；一旦切换阈值，之前收集的 SES 统计应作废。

因此，数值相同不等于语义相同。阈值变化后，趋势图的拐点可能来自分类规则，而非光信号。没有阈值版本、层次、端点和有效性，漂亮曲线只是把多种账本叠在一起。

证据能说到哪里

一份可复核的快照至少应保留：接口与栈位置、Section/Line/Path/VT、近端或远端、指标定义、阈值集、当前或历史区间、区间起点和编号、已过秒数、有效/无效区间、代理重启历元、读取时刻，以及计数是暂定、可修正还是延迟公开。

这些字段能证明代理在特定规则下展示了什么。它们不能单独证明故障器件、客户影响、厂商合规、切换成功或端到端恢复。RFC 1595 本身甚至明确说没有讨论安全问题；RFC 2558 后来才提醒，这些 GET/SET 对象会暴露配置并影响接口，读取权限也需要控制。

Lu Heng 的运行代码优先要求符号回到可执行、可观测的系统；最小初始规范说明共同层只需固定可比较的最小回执，轮询、留存、修正与处置仍是本地责任；为什么 BTW.Media 存在则提出编辑要求：把延迟、修正和缺失本身写出来，而不是让第一张图代替现实。

15 分钟的边界让数据可管理。最终性字段，才让它可追责。

来源与证据边界

技术事实来自 RFC Editor 的 RFC 1595 条目与全文、RFC 2558 条目与全文、RFC 3592 条目与全文，以及 RFC 2493 条目和全文。三篇 Lu Heng 文章只提供解释纪律，不是 SONET 技术来源。

文档沿革有明确日期：RFC 1595 于 1994 年 3 月以 Standards Track MIB 发布；RFC 2558 于 1999 年 3 月取代它，RFC 3592 又于 2003 年 9 月取代 RFC 2558。这不是笼统的“后来有修订”，而是本篇证据边界的一部分。

这些来源证明规范语义与文档沿革，不证明任何具名部署、实时线路状态、事故、客户损失、厂商实现、告警送达、采集器行为或修复结果。开头场景是根据规则构造的逻辑例子，不是新闻事件。