要約

  • 2026年9月11日付のdraft-ietf-mpls-mna-ioam-14は、MPLSノードの負荷分散方式が分からない場合の規範的な処理を追加した。
  • Flow ID MNAで識別したフローでは、ラベルスタック情報を負荷分散に使うと判明している場合、LSEのビット1から始まるSequence Number MNAの19ビットを不変にする。第14版は方式が未知の場合にも同じ制約を適用する。
  • ノードの方式を知るための仕組みは草案の対象外である。19ビット固定は変動要因を一つ抑えるだけで、計測経路が一定だったことを証明しない。
  • IOAM-DEXの観測を比較可能な証拠として扱うには、ハッシュの想定、根拠、対象ノード、観測地点を残す運用側の記録が要る。

「不明」を自由利用にしない

第13版には、知識があることを前提とした二つの処理があった。ノードがラベルスタック情報でフローを負荷分散すると分かっていれば、同じFlow ID MNAについてSequence Number MNAの特定の19ビットを固定する。別の方式を使うと分かっていれば、シーケンス番号の全ビットを変化させられる。

実運用で厄介なのは、そのどちらかを選ぶ根拠がない装置である。第13版から第14版への公式差分は、三つ目の処理が加わったことを示す。ノードが使う負荷分散方式が未知なら、LSEのビット1から始まる19ビットを、Flow ID MNAで示す特定フローの間は不変にしなければならない。

これは「知らない」を制約の解除理由にしない設計だ。直後の文は、MPLSノードが使う負荷分散方式を知る仕組みがこの文書の範囲外だと明記している。共通仕様が決めたのは未知時の安全側の動作であり、装置の実態を発見する方法ではない。

観測値が転送面に近づくとき

RFC 9326のIOAM Direct Exportでは、Flow IDが同一フローからのエクスポートを結び付け、Sequence Numberは通常ゼロから始まり、同じフローでDEXを持つパケットごとに一つ増える。Flow IDをどう割り当てるかはRFCの範囲外である。

draft-ietf-mpls-mna-ioam-14のMPLS表現では、任意のFlow ID MNAとSequence Number MNAが、それぞれ32ビットのFormat D LSEを丸ごと使う。固定された先頭ビットとMPLSのスタック末尾を示すSビットを除くと、値は30ビットだ。ラベルスタックがハッシュ対象なら、毎パケット変わる番号は単なる観測用メタデータではなく、経路を変える入力候補になる。

第14版は存在条件も明確にした。Fフラグが立っていなければFlow IDのFormat D LSE全体を、Qフラグが立っていなければSequence NumberのLSE全体を、固定ビットごと省く。ポストスタックのBlock-Numberは、オルタネートマーキングを使わない場合にゼロでなければならず、第13版の「SHOULD」から「MUST」へ強化された。アクションを誤った場所に置く、同じNASにDEXアクションを重ねるといった組み合わせは不正形式となり、パケットを破棄する。

前提には、IOAMを限定ドメインの仕組みとして負荷分散への影響を考慮するよう求めるRFC 9197、MPLS Network Actionsの枠組みを定めるRFC 9789、基本解を定めるRFC 9994がある。さらに、策定中のMNAポストスタックヘッダー草案やIANAのIOAM Trace-Typeレジストリにある既存定義を参照する。

固定されたのは経路ではない

19ビットの不変性が示せるのは、シーケンス番号のその部分が未知のラベルスタックハッシュを揺らさない、という限定的な点だ。チップが実際に読むフィールド、参照するラベルの深さ、各ノードの差、ソフトウェア更新後の挙動までは分からない。計測用パケットと通常パケットが同じ判断を受けたという保証もない。

Flow IDは相関の鍵であって、全装置に共通するフロー分類証明書ではない。連続した番号でも途中の別ノードで経路が分かれることはあり、番号の欠落も転送損失ではなくエクスポートや収集の問題かもしれない。資料には、実装名、相互接続試験、パケットキャプチャ、安定経路の測定、オーバーヘッド測定はいずれもない。

信頼境界も狭い。草案は単一の信頼された管理ドメイン内での利用を想定する。境界ノードは、別ドメインや信頼できない送信元から届く該当アクション付きMPLSパケットを、ドメインへ入れる前にフィルタしなければならない。付随データは平文で運ばれ得るため、追加保護がなければ完全性を前提にしてはならない。

Datatrackerの文書ページが示す制度上の位置付けも限定的だ。MPLS作業部会の現役Internet-Draftで、想定ステータスはProposed Standard。作業部会状態はIESGへの出版提出済み、IESG状態はPublication Requestedであり、履歴が改版を記録する。要求中のオペコードはまだTBAだ。第14版の存在は、IANA割当、IESG承認、RFC化、実装や導入を意味しない。

情報源