要約

  • RFC 1595 の性能情報は Section、Line、Path、VT、近端・遠端、現在・過去の15分区間に分かれていた。数値だけでは、何を観測したかが決まらない。
  • 利用不能時間は十秒連続の SES の最初の秒から始まる。十秒列が900秒の境界をまたぐと、前区間の SES や UAS は次の読み出しで変わり得る。
  • RFC 2558 と RFC 3592 は、速報値を後で直す方式と、十段の遅延線で確定まで待つ方式を明示した。即時性と初回値の不変性は同時には得られなかった。

「直前の区間」はまだ閉じていない

15分の終了直前に Path で重大エラー秒が続き始めたとする。時計が次の区間へ移ると、管理局は interval 1、すなわち直前に完了した区間を読める。しかし、この時点で連続数が十に達していなければ、末尾の秒を通常のエラー時間として残すべきか、利用不能時間へ入れるべきかはまだ決まらない。

新しい区間に入ってから十秒列が完成すると、利用不能状態は十秒目ではなく最初の SES から始まる。境界より前の秒も UAS 側へ移る。RFC 1595 はこのため、開始直後に同じ過去区間を連続して GET すると、Path、Line、VT の SES と UAS が異なる値を返し得ると明記した。

これは過去の信号を書き換える話ではない。物理的な一秒は同じであり、後から確定するのは管理上の分類である。危ういのは、最初の読み出しに版番号も取得時刻も付けず、「完了区間だから確定」と扱う収集側だ。

判定は十秒ぶん遡る

Line、Path、VT では、十秒連続の SES が生じると、その第一秒から利用不能になる。復帰には十秒連続の非SESが必要で、その十秒は利用不能時間に含めない。利用可能中は各エラーカウンターが進み、利用不能中はその層の UAS だけが進む。

したがって、この十秒は単なる通知抑制ではない。どの台帳へ秒を入れるかを決める待ち時間である。最初の異常を観測した瞬間、エージェントは事象を知っていても、その事象の最終区分までは知らない。

区間が切り替わっても状態判定は継続する。カウンターの保存先が current から interval 1 へ移っても、十秒列の文脈は消えない。暦上の区切りより、状態機械の記憶の方が長い。

同じ「エラー」でも層が違う

SONET/SDH 機器は、すべての場所ですべての層を終端するわけではない。再生器は Section だけを終端し、上位層には透明になり得る。アド・ドロップ多重化装置やデジタルクロスコネクトは Line を扱い、端局多重化装置は Path や VT/VC まで終端し得る。

RFC 1595 は、その構造を ifEntry と ifStack に反映した。Section の符号違反は B1、Line は B2、Path は B3、浮動 VT は V5 から得る。LOS、LOF、AIS、LOP、RDI も適用層が異なる。名称が似ていても、層と回線速度を失った二つの数は比較できない。

ifOperStatus の down も根因そのものではない。Medium/Section/Line をまとめたエントリは Section または Line の状態から down になり、Path エントリは Path の状態から down になる。赤い一語は調査の入口であって、故障部品の住所ではない。

遠端データが消えるとき

Line、Path、VT には近端と遠端の性能表がある。Path の遠端値は G1 の Path Overhead にある FEBE 情報から収集される。指標名が同じでも、遠端の報告経路を通った別の証言である。

RFC 2558 は、同じ層または下位層に入力欠陥がある秒について、遠端一秒統計を absent とするよう定めた。ここで absent を 0 に置き換えると、観測路が壊れた瞬間に「遠端は無傷」という誤った証明が生まれる。ゼロは観測の結果であり、欠落は観測できなかった状態だ。

直して速く出すか、待って一度で出すか

RFC 2558 は、実装上の選択を明瞭にした。性能値をリアルタイムに更新するなら、利用可能性が確定した後に ES、SES、SEFS、CV、UAS を遡って調整できなければならない。境界をまたいだ十秒列なら、前区間も対象になる。

もう一つの方法は、一秒ごとの近端・遠端カウントと警報状態を十段の遅延線へ通すことだった。判定済みの秒だけを性能表へ加えるので、後から直す必要はない。ただし、表示は実時間より十秒遅れる。RFC 3592 は2003年にもこの仕組みを残した。

どちらも仕様に忠実であり得る。速報方式には版管理が要る。遅延方式には遅延の明示が要る。片方を「データ破損」、もう片方を「装置の遅さ」と決めつける前に、エージェントの方針を確かめる必要がある。

RFC 2493 はさらに、current、history、任意のaggregateを分け、経過秒数、有効区間、無効区間を扱った。再起動直後やプロキシの欠測では、履歴が揃わないこともある。RFC 1595 の96区間は24時間分の上限であり、常に96個が完全だという約束ではない。同文書は最低4区間、既定32区間としていた。

通知時刻より事象時刻が早い

後継仕様では、linkDown は利用不能状態が確定してから送る一方、その時刻は最初の UAS、つまり約十秒前を指す。linkUp も同じ構造を持つ。

送信時刻は「いつ通知できるだけの知識を得たか」を示す。有効時刻は「状態機械が変化をどこへ置いたか」を示す。受信時刻だけなら障害開始を後ろへずらし、有効時刻だけならエージェントが即時に知っていたように見える。二つの時刻は競合せず、両方必要である。

SES という名前にも版がある

RFC 2558 は、重大エラー秒を決める閾値が複数の標準で異なることを記録し、sonetSESthresholdSet を追加した。エージェントは全方式を実装しなくてもよい。設定を変更した場合、それ以前の SES 統計は無効化される。

履歴グラフに閾値セットを残さなければ、規則の変更が回線品質の改善や悪化に見える。同じ整数でも、分類契約が違えば同じ測定ではない。

読み出しを証拠にする条件

保存すべきものは値だけではない。管理対象のインスタンス、スタック位置、層、近端/遠端、指標定義、閾値セット、区間番号と開始時刻、経過秒、有効/無効区間、エージェントの再起動世代、取得時刻、暫定修正方式か十秒遅延方式かを一緒に残す。

それで証明できるのは、ある規則の下でエージェントが何を示したかまでだ。故障部品、利用者影響、ベンダー適合性、切替成功、修復完了は別の証拠を要する。RFC 1595 はセキュリティを論じておらず、RFC 2558 は後に GET/SET の情報と操作性が敏感であると警告した。

Lu Heng のRunning-Code Primacyは、記号を実装された観測へ戻す。Minimum Initial Specificationは、共通層が比較可能な最小意味を定め、保存や対応は現場の選択として可視化すべきだと示す。Why BTW.Media Existsの編集原則に従えば、最初の数字を物語にせず、修正、遅延、欠落をそのまま報告することになる。

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 を置き換えた。この正式な置換関係は、単に「後継文書がある」という説明より狭く、検証可能である。

資料は仕様と文書系譜を証明するが、特定の導入、回線障害、顧客影響、製品動作、通知到達、収集器の挙動、セキュリティ状態、修復結果は証明しない。冒頭は仕様から組み立てた例であり、実在の事故ではない。