要約

  • RFC 9546 は S-Label の直後に d-ACH を置き、アクティブ OAM に独立した 8 ビット循環シーケンス番号を与える。
  • PREOF は OAM 処理にその番号を使わなければならず、仕様は App-flow と OAM が異なるシーケンス番号空間を使うと明記する。
  • 連続した OAM 系列が示せるのは Node ID、Level、Session ID、時刻で区切られた試験履歴であり、業務パケットやアプリケーション結果ではない。

運用室の画面は穏やかだった。試験パケットは複製され、遅れてきたコピーは除去され、出力順にも穴がなかった。一方、現場の制御系は一件の操作が実行期限を越えたと訴えていた。

同じ S-Label を見れば、アプリ側の誤報と決めたくなる。試験も業務も同じ DetNet サービスに属し、PREOF の対象になっている。しかし RFC 9546 は、所属と履歴の同一性を分けて設計している。

S-Label は関係を示すが、共通の通し番号ではない

DetNet サービス副層では S-Label がフローを識別する。MPLS データプレーン上のアクティブ OAM パケットでは、DetNet Associated Channel Header、すなわち d-ACH が S-Label の直後になければならない。受信ノードはその試験を対象サービスへ結び付け、適切な特殊機能へ渡せる。

だが d-ACH は独自の Sequence Number を持つ。PREOF が OAM パケットを処理するときは、その値をシーケンス情報として使う。さらに仕様は、App-flow と OAM が別のシーケンス番号空間を使うと明言する。

OAM の 6 番が 5 番の後に現れたという記録は、その試験会話の連続性を支える。ところが同時点の業務パケット番号、採用された本番コピー、順序回復バッファの期限、アプリケーションの受理は示さない。OAM 6 を業務イベント 6 に変換する規則はない。

したがって S-Label は「どのサービスについて測ったか」を結ぶ関係キーである。「どの本番イベントを代理したか」を示す共通主キーではない。ラベルと番号だけを残すデータ基盤は、別々の台帳を後から誤って接合する。

ヘッダー全体が観測の有効範囲を作る

d-ACH の先頭 4 ビットは 0001 で、IP パケットや DetNet データパケットと区別する。続く 4 ビットの Version は RFC 9546 では 0 である。その後に 8 ビットの循環 Sequence Number、16 ビットの Channel Type、20 ビットの Node ID、3 ビットの Level、5 ビットの Flags、4 ビットの Session ID が並ぶ。

Node ID は送信元 DetNet ノードを示し、DetNet ドメイン内で一意にプロビジョニングされなければならない。ただし配布方法は仕様の範囲外である。20 ビットの値を受信しただけでは、世界全体での一意性も台帳の正しさも証明できない。どのドメインで、どの期間に、どの装置へ割り当てられたかを別のインベントリーが支える必要がある。

Level は保守ドメインの階層に似た意味を持つ。内側の運用境界と外側のサービス境界では、同じサービスを見ても可視範囲が違う。Session ID は、同じノード・同じ Level から同時に始まる複数の OAM セッションを区別する。Channel Type は関連チャネル上のプロトコルを示す。

監査可能なキーは、S-Label、Node ID、Level、Session ID、Channel Type、設定エポック、観測点、時刻の組み合わせになる。8 ビットの数字だけでは履歴ではなく、範囲を待っている値にすぎない。

0 への折り返しと再起動を混同しない

送信元は送信前にシーケンス番号を設定しなければならない。初期値は予測しにくい値が推奨され、通常は OAM パケットごとに 1 増やす。ただし Packet Ordering Function の負荷試験や異常系試験のため、別の方式も許される。

値は 0 から 255 までで循環する。RFC は、アクティブ OAM の送信頻度が App-flow より大幅に低いため、この大きさで十分だとする。これは想定された OAM 運用に対する判断であり、任意の高頻度設定や長期間集計に無条件で適用できる保証ではない。

254, 255, 0, 1 は正常な折り返しかもしれないし、新しいセッションの開始かもしれない。重複番号は複製、折り返し、再起動、あるいは Session ID を失った二系列の混在から生じる。欠番もネットワーク損失だけでなく、収集器の欠落、観測点変更、意図した異常順序試験で起きる。

だから原フィールドを保存する。緑／赤の派生状態は閲覧には便利でも、後日の判定材料を破壊する。完全な d-ACH、S-Label、受信時刻、観測ノード、試験レート、設定エポックがなければ、折り返しの意味を復元できない。

PREOF の成功は処理した系列に属する

Packet Replication, Elimination and Ordering Functions は、複数経路へのコピー、後着コピーの除去、順序回復を行える。だが各判断は、見えているパケット、履歴窓、許容遅延、入力されたシーケンス空間に対する局所的な判断である。

OAM では d-ACH がその入力になる。App-flow の本番データには別のシーケンス文脈がある。OAM コピーを正しく除去した記録から、本番でどのコピーを採用したかは分からない。試験系列を順序どおりに出した記録から、本番バッファの到着状況や期限も分からない。

強い fate sharing が確認できても、カウンターは一つにならない。それは試験の関連性を高めるが、存在しない本番イベントを生成しない。ECMP や LAG、カプセル化、シェーピング、資源処理の同等性は別の重要な問いである。本稿の境界はさらに基礎的で、処理が同等でも履歴は別、という会計原則にある。

相関はできる。代理証明にはできない

第一の記録は、目的の S-Label と正しい位置の d-ACH を示す。第二は Node ID、Level、Session ID、Channel Type、エポック、試験方針で OAM セッションを定義する。第三は OAM 番号に対する各 PREOF 判断を保存する。第四は独立して App-flow の番号、複製、除去、受信、アプリ結果を追う。

その上で相関させる。同じ限定時間内に両方で欠落が起きれば調査根拠になる。同じ設定変更の直後に変化すれば因果仮説は強まる。しかし表現は「二つの限定観測が同時に変化した」でなければならない。「OAM 番号が本番パケットの到着を証明した」ではない。

台帳を分けることで、初めて候補を比較できる。試験生成器の再起動、Node ID の衝突、収集欠落、本番コピーだけに共通するリスク、順序窓の失効、アプリ側の拒否がそれぞれ見える。一枚の緑ランプに、これらを裁定する権限はない。

出典