要約

  • RFC 9571 は Synonymous Flow Label を使い、RFC 6374 の損失・遅延測定を一般 MPLS と multipoint-to-point LSP に広げる。
  • SFL はパケットの所属を示すが、並べ替え、別インターフェース、複数コア、転送パイプラインが受信カウンターへ反映し終えたことは示さない。
  • 検証可能な結果には、範囲、バッチ、待ち時間、重なる窓の帰属、方式、設定世代、応答値、後段のサービス観測を分離した記録が要る。

境界を越えたのは色であって、処理の末尾ではない

送信側が A の SFL を終え、B に切り替えた瞬間を考える。受信側に B が見えたとしても、A の全パケットが計数済みとは限らない。ECMP の遅い枝、別の受信ポート、別コアの更新、長いハードウェアパイプラインに A が残り得るからだ。

RFC 9571 は、この時間差を測定契約の中心に置く。2024 年 5 月の IETF Proposed Standard であり、MPLS-TP を主対象としていた RFC 6374 を一般 MPLS と multipoint-to-point に拡張する。送信者はバッチを終えた後、全パケットが到着したと確信できるまで待ってから、同じ SFL で Query を送る。

つまり SFL は集合の鍵であり、遠隔完了通知ではない。正確さは、待ち時間が実際の経路と実装に対して十分だったという別の証拠に依存する。

LM メッセージ一個では同時刻を作れない

RFC 6374 の LM メッセージを境界に使う方式では、データが LM より後に着くと窓がずれる。RFC 9571 は、ECMP の順序逆転、異なるインターフェース、分散したプロセッサコア、リンク集約、処理からカウンター更新までの遅延を挙げる。

実損失が少ないほど、この一個のずれが大きい。交互マーキングは A と B を受信後にも区別できるため、単一パケットの到着順を境界にする問題を弱める。ただし、A の最後尾がすでに可視かどうかは別問題として残る。

運用記録には、バッチ終端、Query、応答、採用したドレイン時間、観測装置、インターフェース、実装世代を残す必要がある。結果だけでは、後から「本当に損失か、読み取りが早すぎたか」を分けられない。

multipoint の総数には送信元が欠ける

multipoint-to-point LSP では、通常の送信元アドレスが MPLS パケットにない。出口が正しく合計しても、どの入口から来た集団に損失があったかは答えられない。

そこで RFC 9571 は送信元固有の識別を要求する。FEC、送信元、宛先、SFL、バッチ、インデックス、セッション、計数位置を一組として扱って初めて、source-to-destination の問いになる。

SFL TLV は SFL と割当元 FEC、管理用バッチ、インデックスを運ぶ。ただしインデックスは設定時に両者が合意する便宜機能であり、普遍的な主体証明ではない。

損失と遅延は別窓でも同じパケットを使う

損失バッチの途中に短い遅延バッチを置ける。RFC 9571 が両者を「比較的」独立と書くのは、窓が重なるからだ。遅延バッチを短くするか、損失バッチを延ばさなければ、カウンターを整合できない場合がある。

遅延用 D のパケットは損失用 A にも属し得る。二重計数するか報告時に調整するかはローカル事項である。D が A と B の境界を横切れば、どちらに属させるかを決め、関係する全パケットの到着後に Query を出す。

標準の簡略規則は、遅延測定系に損失測定能力と設定を求め、遅延窓を包む損失窓より先に閉じ、次の遅延バッチ終了までに前のバッチが到着できる長さを求める。これは実装自由度を狭めて履歴を一意に近づける規則だ。

初期化中のゼロを性能ゼロにしてはいけない

Time Bucket の境界を作成・変更した直後、応答側は一測定期間を完了するまで各バケットをゼロで返す。このゼロは「全期間をまだ観測していない」という状態であり、ジッターが無かったという測定ではない。

標準偏差方式は個数、遅延合計、最小、最大、二乗和を返す。平均方式はタイムスタンプ総和か、最初と最後の時刻と個数を返せる。サンプル方式は選んだパケットだけを読み、読み取り間隔を窓にする。方式名と設定世代を失った数値は比較不能である。

また、SFL を用いた損失・遅延の combined mode は現仕様ではサポートされない。ACH や TLV の拡張性を、実装済み能力と読んではならない。

戻ってきた応答にも文脈の鎖が要る

測定パケットは業務パケットと同じ MPLS スタックに GAL を足し、ACH type で測定種別を表す。一部ハードウェアは OAM 処理へ渡す前にラベルスタックを捨てるため、SFL TLV が失われた文脈を補う。UDP では必須で、他の場合も不要と外部手段で分かる場合を除き必要になる。

point-to-point の帯域内応答以外では戻り情報も必要だ。応答が届いたこと、正しいバッチへの応答であること、TLV が改変されていないことは別々の検証点である。RFC は TLV 改変が RFC 6374 応答側に検出されず測定を乱し得ると認める。

測定値はアプリケーション結果ではない

窓が正しく閉じても、証明できるのは指定集団・観測点・期間・方式の損失または遅延である。原因、再送の効果、別経路、SLA の定義、利用者体験は追加証拠を要する。

送信元やフローの粒度はプライバシーも削る。制御通信の暗号化、ラベルの定期変更、複数ラベルの併用という対策は、観測権限の設計と一緒に扱うべきだ。

出典

出典