要約

  • draft-ietf-mpls-stamp-pw-21は、制御プレーンへのpunt pathで行われるレート制限が、STAMPからは実ネットワークの損失と区別できず、パケット損失として報告され得ると明記する。
  • アラームを障害認定や経路変更に結びつけるには、セッション、カプセル化、両端のリミッター、往復方向、MTU、ECMP、戻りコンテキスト、サービス面の独立観測を保存しなければならない。

同じ沈黙を生む二つの場所

試験応答が来ないとき、送信側が直接知るのは「測定サイクルが完了しなかった」という一点である。途中のLSPで落ちても、終端で制御プレーンに上げられた後に落ちても、結果は沈黙になる。

MPLS向けSTAMP案では、試験パケットを通常の転送から分離し、Provider Edgeの制御プレーンで処理する。各パケットはCPUとメモリーを消費するため、Session-SenderとSession-ReflectorはDoSや過負荷に備えてレート制限を行う。この防御は必要だ。

ところが防御が測定結果に混ざる。revision 21は、punt path上の制限が実際のネットワーク損失と区別できず、損失として報告され得ると記す。中間経路が落とした場合と、到着後に終端が落とした場合を、一つの割合だけでは分けられない。

ここで重要なのはSTAMPを否定することではない。測定値が持つ権限を狭く、正確にすることだ。値は不完了を示す。原因、顧客影響、責任主体は別の証拠で立てる。

RFCになる直前でも、まだInternet-Draftである

現行のrevision 21は2026年9月10日付で、IESGは9月14日に承認し、翌日にRFC Editor queueへ送った。履歴には編集作業とIANA対応が残る。公開されればProposed Standardとなり、RFC 8762とRFC 8972を更新する予定だが、現時点ではRFCではない。

対象も限定される。一つの管理ドメイン内にあるpoint-to-point LSPと、point-to-point single-segment PWである。point-to-multipointとmulti-segment PWは範囲外だ。特定ベンダーの実装、運用者の採用、事故の発生を示す文書でもない。

審査履歴には、この論点が本文に入った経緯が残っている。IESGレビューでは、TTL expiry方式などが両端ですべての試験パケットを制御プレーンへ送る点を踏まえ、punt-path policingがSTAMP上のネットワーク損失として見えることを明記すべきだと指摘された。revision 21はそれに対応した。レビューは弱点を作ったのではなく、観測と原因の隙間を可視化した。

二つの形式は異なる証拠を残す

RFC 8762は基本STAMPを、RFC 8972はSSIDやTLV拡張を定義する。MPLS案のFormat 1はIP/UDPを含み、Format 2は含まない。後者ではSender用とReflector用の新しいG-ACh channel typeを使う。どちらも非ゼロのSSIDを往復で持つ。

Format 1ではアドレス、宛先ポート、SSIDをセッション識別に使える。Format 2ではSSIDに加え、受信したLSP/PWコンテキストとローカル設定が必要になる。IP/UDPフィールドを扱うTLVはFormat 2では使えない。

同じラベルスタックを使うことは、データと同じunderlayを測るための中心条件だ。しかしIPヘッダーのアドレスが実トラフィックと異なれば、IPベースECMPは別の経路を選び得る。準拠装置ならGALはECMPに影響しないはずだが、非準拠装置では影響し得る。ラベルが同じという事実は強い根拠でも、全ホップの同一性証明ではない。

返り道は別の失敗領域である

G-AChで届いた試験に対し、Reflectorは双方向LSPまたはPWの逆方向で返す。受信したPW labelまたはultimate LSP labelからreverse contextを特定する。見つからなければ、受信パケットを捨て、返信してはならない。

Senderから見れば再び無応答である。往路、終端のexception処理、Reflector、reverse-context lookup、復路、最後のpunt pathのどこで失敗したかは、無応答だけでは分からない。

容量も方向別に扱う必要がある。Reflectorは受信ごとに応答し、復路には往路と同程度の試験レートが生じ得る。しかも復路容量が小さい場合がある。round-tripの一つの数字が、二つの方向と二つの制御プレーンを合成していることを忘れてはならない。

MTUは測定だけを壊せる

G-ACh、GAL、IP/UDP、Extra Paddingは試験パケットを大きくする。各方向でLSP/PW MTUに収まらなければならない。大きすぎるG-AChパケットはfragmentされずに落ち、損失として見える。

それは試験パケットにとって本物の損失だ。しかし小さい顧客パケットが同じ結果になるとは限らない。逆にLSPが壊れたとき、routableな宛先を持つFormat 1が別のIP/MPLS経路でReflectorに到達し、誤って良好な結果を返すこともある。非ルータブル宛先やdomain-edge filteringはリスクを減らすが、応答を経路証明へ変えるわけではない。

したがって測定の有効性は、損失率と一緒にカプセル化、サイズ、ECMP仮定、戻り経路を記録して初めて検証できる。

リミッターを外さず、リミッターを証拠に入れる

制御プレーン保護を撤去すべきではない。過剰な試験はCPU、メモリー、復路帯域を消費する。攻撃者は試験を注入して負荷を作り、逆に抑圧して健全なLSP/PWを故障に見せられる。

必要なのは相関である。草案はFormat 1のUDPポート、Format 2のLSP/PWコンテキストとchannel typeなどを使い、いつレート制限が働いたかをalerting systemがfailure notificationと結びつけられるようにするのが有用だとする。また受信側policingは、試験に割り当てた帯域より厳しくしないよう勧告する。

RFC 5085由来の「関連PWビットレートの5%未満」という指針も保護基準であり、妥当性証明ではない。複数セッションが同じaggregate policerを共有すれば、個別セッションの割合だけでは説明できない。

HMACによる完全性保護も別問題を解く。正しいセッションのパケットかを検証できても、同じECMP経路を通ったか、欠落がどこで生じたか、サービスが影響を受けたかまでは証明しない。

アラームに添えるべき台帳

最低限、次を一つの調査記録で結ぶ。

  1. 使用した仕様の版と測定意味；
  2. SSID、Sender、Reflector、ローカル設定；
  3. LSP/PWコンテキストと方向；
  4. Format、IP/port、channel type、CW、GAL/TTL、label stack、サイズ；
  5. 往復それぞれの送信レートと割当帯域；
  6. 両端punt-path policerの設定、カウンター、時刻；
  7. 送信・反射・受信数とT1〜T4；
  8. reverse-context lookupとdiscard；
  9. 両方向のMTU、ECMP、entropy条件；
  10. 同一時間帯のデータプレーン独立観測；
  11. alert rule、信頼度、未解決の原因候補；
  12. 判断、追試、復旧確認。

この台帳があれば、監視は早い段階で正直に言える。「プローブ経路の損失を観測した」。サービス経路の故障、顧客影響、責任の所在は、その次に確定する。

相関は自動的な免罪符ではない

policer counterとSTAMP lossが同じ時刻に増えたとしても、それだけで全損失をControl Planeへ帰属させてはならない。カウンターがどのinterface、channel type、queue、集約範囲を対象にするかを確認する必要がある。複数のOAM sessionや攻撃トラフィックが同じlimiterを共有すれば、aggregate dropは個別SSIDの因果を直接示さない。

逆にservice counterが安定していることも、サービス無影響の完全な証明ではない。観測点が違うECMP memberを見ているかもしれず、sampling intervalがずれているかもしれない。probe loss、punt drop、data-plane discard、interface congestion、customer experienceは、それぞれ異なるcoverageを持つ。相関はそれらを一つに潰す作業ではなく、境界を保ったまま比較する作業である。

運用state machineには「原因未確定」を正式に置くべきだ。その状態では、低レートでの再試験、別formatによる比較、双方向MTUの確認、両endpointのlimiter読出し、passive telemetryとの照合を自動化できる。だがtraffic moveや顧客責任通知は保留する。証拠が増えた時だけauthority levelを上げる設計なら、調査速度と慎重さは両立する。

clear条件も分ける必要がある。probeが戻ったこと、punt pathの負荷が下がったこと、LSP/PWが意図した経路で動くこと、customer serviceが回復したことは別のreceiptだ。alert thresholdを下回っただけで全てをrecoveredにすると、誤測定だったのか、実障害が直ったのかを後から学べない。

一つのadministrative domainにも複数の責任がある

ドラフトはsingle network administrative domainを前提にする。しかし現実の一ドメインには、transport team、platform team、security team、vendor support、automation owner、customer operationsが共存し得る。技術的な管理境界は、意思決定主体が一人であることを保証しない。

導入審査では「STAMPを実装したか」だけでなく、誰がtest bandwidthを決めるか、誰がaggregate policerを所有するか、誰が両方向のcounterを保存するか、software update後のECMPを誰が検証するか、誰がinvestigationからrerouteへの昇格を承認するかを決めなければならない。プロトコルが動いても、この責任鎖が空なら誤った自動化は避けられない。

Heng Luの原則はここで抽象論ではない。測定への参加は処置権限ではなく、管理上の表示はrunning realityそのものではない。monitorの安定とcustomer networkの継続も同じではない。Running-code primacyとは、一つのcounterを崇拝することではなく、決定を実行経路と観測結果に結び直すことである。

出典