要約

  • SPRING作業部会の二つの草案は、SRv6とSR-MPLSにTimestamp and Forward（TSF）ループバックモードを定める。反射側が受信時刻T2を高速転送経路で未認証STAMPパケットへ書き込み、そのまま返すため、通常の反射処理へのパントを避け、セッション数と測定頻度を高められる。
  • TSFは管理された単一ドメイン内で有用になり得るが、時刻値だけでは書き手、経路、時計、利用権限を認証できない。重要な判断に使う系列には、モード、接続許可、サービス文脈、時計状態、検証結果、許された後続処理を束ねる「モード・信頼記録」が必要だ。

速い数字が会議室に届くまで

深夜の障害対応で、五秒ごとの測定が遅延上昇を示したとする。担当者は別経路への切替を提案し、翌朝にはそのデータがSLA報告にも転用される。グラフは十分に細かく、欠測もない。だが、会議で「どの方式で測ったのか」と問われるまで、TSFだったことは表に出ない。

反射装置が高速転送処理の中でT2を書いた。その事実は、処理遅延を抑えた良い説明になる。送信者が認められた主体だったこと、想定したサービス経路を通ったこと、時計が許容誤差内だったこと、契約判断まで許されたことの説明にはならない。

問題は、TSFを使ったことではない。収集時には存在した信頼条件が、数値だけを別システムへ渡す過程で剝がれたことである。診断用に十分な測定と、経路を自動変更する測定と、金銭的な効果を生む測定は、同じ証拠水準でなくてよい。

TSFが省く処理、得る時間

通常のSTAMP反射処理では、受信したテストパケットをデータプレーンの高速経路から外し、プロトコル処理を経て応答を作る必要がある。TSFでは、送信側がT1を入れ、反射側が所定位置にT2を記録して同じパケットを返す。送信側は受信時にT4を得る。

T2とT1の差から前向きの片方向遅延、T4とT1の差からループバック遅延を計算できる。制御プレーンへのパントを避けることで、草案はセッションの大規模化と短い測定間隔を狙う。一時的な混雑や短周期の変化を捉える上で、これは明確な実務上の利益だ。

SRv6版では、PTPv2またはNTPv4形式を書き込む二つのEnd.TSF動作が提案され、対応するSIDが反射ノードに設定される。SR-MPLS版では、MPLS Network Actionのサブスタック内に二つの操作コードを置く。目的は共通でも、運用上の管理点は別々だ。記録には、どちらのデータプレーン、どの動作または操作コード、どの装置能力を使ったかが必要になる。

認証しないことを隠さない設計

両草案は、TSF付きループバックがRFC 8972の未認証反射パケットに限られ、認証済み形式には対応しないと明記している。RFC 8762の認証モードは、128ビットに切り詰めたHMAC-SHA-256でSTAMPメッセージの完全性を保護する。鍵の配布は仕様外だが、HMACを正しく検証したパケットとTSFパケットが同じ主張をするわけではない。

だからといって、TSFを危険な測定と決め付けるのも誤りだ。想定環境は単一の管理ドメインであり、運用者が送信側、反射側、往路と復路を設定する。TSF処理は信頼するノードとセッションに限定し、該当パケットを管理境界でフィルターする。動作、時刻形式、書込位置、ペイロード長を検証し、不正なパケットは破棄する必要もある。

これらは、パケット外側に信頼を組み立てる方法である。構成管理、入口制御、物理的な管理、別レイヤーの保護、監視を組み合わせてよい。ただし、後からデータを読む人がその組合せを確認できなければならない。「社内網だから信頼できる」という一文では、境界が変わった時点を追跡できない。

完全性と時計と代表性

測定の信頼性は一つの軸ではない。

メッセージ完全性は、途中の改変や偽造を検出できるかという問題だ。認証済みSTAMPは、そのためのHMACを持つ。TSFのSTAMP形式にはない。SRv6でSRH HMACを別途用いる場合も、それは別の保護層として明示すべきで、T2そのものの属性にしてはならない。

時計の妥当性は別問題である。T2引くT1で片方向遅延を出すには、送信側と反射側の時計がNTPv4かPTPv2で同期していなければならない。PTP形式のフィールドがあるだけでは、同期状態や誤差を保証しない。時刻源、最終同期、誤差推定、ホールドオーバーを系列へ結び付ける必要がある。T1とT4を同じ送信側で取るループバック遅延、時計同期を必要としないループバック損失では条件が異なる。

代表性はさらに別だ。テストパケットを対象トラフィックと同じSRカプセル化で送っても、すべてのアプリケーションフローが同じECMP経路、キュー、サービス文脈を経験したとは限らない。草案は、受信した転送経路またはサービス文脈の中だけで処理するよう求める。ある文脈の結果を別の契約へ使う権限までは与えない。

認証は時計を正しくせず、正しい時計は送信者を認証せず、正しい送信者は測定の代表性を自動的に証明しない。この区別を保つ方が、単一の「信頼済み」表示より運用に役立つ。

パケットではなく系列に付ける記録

必要な情報をすべてワイヤ形式へ押し込む必要はない。重要な判断へ入る測定系列ごとに、短いモード・信頼記録を作ればよい。

そこにはセッション、送信者、反射者、責任者、SRv6またはSR-MPLS、双方向・片方向・ループバック・TSFの別、認証形式の有無を置く。設定された往復経路、カプセル化、セグメントリストの版を指紋化し、サービスやテナントの文脈と、文脈をまたぐ処理を防ぐ仕組みを示す。

TSFについては、End.TSF動作またはMPLS操作コード、時刻形式、固定オフセット、反射装置の能力確認を残す。送信許可、境界フィルター、セッション識別子の生成方針、STAMP以外の保護も別欄にする。T1、T2、T4の解釈には、時計源、同期状態、誤差推定、最終確認時刻を添える。

運用欄には送信頻度、間隔、標本数、損失、不正パケット、拒否、書込失敗、妥当性検査を置く。判断欄には集計期間、外れ値処理、しきい値、不確実性、承認者、許可された操作を置く。秘密鍵や完全なトポロジー、利用者通信は不要である。限定した事実と原データのハッシュで、後日の再構成は可能だ。

構成が変われば記録も失効させる。セグメントリスト、反射ソフトウェア、境界ルール、時計状態、サービス配置、利用目的のどれかが変われば再発行する。監視アラート用に集めた系列が、コピーされたという理由だけでSLA決済の証拠へ昇格してはならない。

自動化に渡す前に決めること

短い測定間隔は、発見だけでなく反応も速める。そこで用途別の証拠水準が必要になる。仮説を立てるアラートならTSF単独でもよい場合がある。五回の悪化で経路を変えるなら、安定条件、影響範囲、別測定、ロールバックを加えるべきだ。顧客補償なら、方法、期間、サービス範囲、反証手段を保存しなければならない。

これらはプロトコルが中央で決める事項ではない。最小限の共通仕様が測定方法を相互運用可能にし、各運用者が将来の使用権限を局所的に決める。Heng Luの「最小初期仕様、将来判断の局所化」は、この分業を弱さではなく設計原則として捉える。選択が異なっても、根拠の形式が見えれば比較と監査はできる。

草案であることも測定条件の一部

二つの文書は2026年9月12日付の現行Internet-Draftで、想定ステータスはInformationalである。End.TSF動作とMPLS操作コードは割当待ちだ。実装状況の記述は具体的な試みを示すが、広範な対応、商用展開、測定規模、運用方針を証明しない。

草案は自らの限界を隠していない。信頼するセッション、境界フィルター、能力確認、範囲検査、カウンター、通知のレート制限を求めながら、認証済みSTAMP非対応も明記する。危ういのは、この丁寧な境界がデータ基盤で削られ、時刻値だけが「客観的事実」として残る時だ。

TSFは観測を速くする。その観測が何を決めてよいかは、別の記録で初めて説明できる。

出典