要約

  • Requester はプローブ、TTL、返信モード、カプセル化、逆方向情報の要求を選ぶ。Responder が返せるのは、自分の位置で確認できるローカルな証拠だけである。
  • IP 方式は 127/8 のアドレスと UDP を MPLS スタック内に置く。非 IP 方式は ACH を使い、IP ルーティングに依存しない。非 IP ACH の返信モード 4 では、返信は逆 LSP 上を ACH で戻り、IP/UDP を使ってはならない。その戻り経路を持たないノードは要求を破棄すべきである。
  • R フラグは Reverse-path Target FEC Stack TLV を要求するが、Echo 応答で R を設定してはならない。R や TLV がなければ逆 FEC を推測できない。関連する双方向 LSP でも、逆方向の FEC は異なることがある。
  • Requester は応答のインターフェース、ラベルスタック、該当する FEC を検証しなければならない。検証に失敗した応答は破棄し、失敗を報告することが望ましい。GAL は運搬のための要素であり対象 FEC ではない。FEC 検証に含めず、Nil FEC TLV を付けず、DSMAP/DDMAP にも現れてはならない。

この手続きは静的 LSP と PW FEC、さらに非 IP の MPLS-TP 経路を調べる。DSMAP/DDMAP と TTL 期限切れにより、要求を LSP 上の特定点へ導けるため、Responder は出口とは限らず中間点でもよい。Requester は試験条件を決める権限を持つが、Responder は局所的な返信を端点間の結論へ拡張する権限を持たない。RFC 6370 の識別子と RFC 6371 の OAM 枠組みは相関と境界を支えるが、RFC 6426 の検証を代替しない。

検証フィクスチャ。 明示的な MPLS ラベルスタック、TTL 列（1、2、3 など）、対象の静的 LSP/PW FEC、入出力インターフェース、返信モード 4、Source Identifier と Destination Identifier を記録する。127/8 と UDP の IP サンプル、非 IP ACH サンプルを別々に送る。TTL 期限切れの地点、DSMAP/DDMAP の内容、GAL の有無、R が要求にだけ設定されていること、応答の Reverse-path Target FEC Stack TLV を確認する。応答に逆 FEC 証拠が含まれる場合、Requester はそれを検証する。IP アドレスを使う P2MP では RFC 6425 の手順を必ずサポートし、IP を使わない場合は RFC 6426 の非 IP 手順を適用する。各応答を正しい分岐と識別子に結び付ける。要求された返信モードをサポートしない、または利用できないノードは要求を破棄しなければならない。ECMP 上では ACH on-demand CV を使わない。ACH ヘッダーがハッシュを変え、実トラフィックとは別の経路を観測し得るためである。

運用の判断経路。 まず対象、FEC、識別子、境界フィルターを確定し、TTL、返信モード、カプセル化を選ぶ。応答を受けたら、対象点か TTL で選ばれた中間点かを確認する。次にインターフェースとラベルスタック、対象 FEC、そして R を要求した場合だけ逆 FEC TLV を検証する。不一致、想定外の Source Identifier、必要な戻り LSP の欠如、GAL の対象 FEC 扱いは、いずれも破棄して報告する。無応答は証拠不足として記録し、原因を断定しない。

出典