メインコンテンツまでスキップ

RFC 4379 - 4. Theory of Operation

4. 動作理論 (Theory of Operation)​

MPLS echo request は特定の LSP をテストするために用いられる。テスト対象 LSP は "FEC スタック" によって識別される。例えば、LSP が LDP で確立され出口 IP アドレスが 10.1.1.1 である場合、FEC スタックは値 10.1.1.1/32 の LDP IPv4 プレフィックスサブ TLV を単一要素として含む。テスト対象 LSP が RSVP LSP なら、FEC スタックはその LSP を一意に識別する RSVP セッションと送信者テンプレートの単一要素からなる。

FEC スタックはより複雑になり得る。例えば、出口 10.10.1.1 の LDP LSP トンネルを通る VPN IPv4 プレフィックス 10.1/8 をテストする場合。このとき FEC スタックは 2 つのサブ TLV を含み、底が VPN IPv4 プレフィックス、頂が LDP IPv4 プレフィックスである。下層 (LDP) トンネルが不明または無関係とみなされる場合、FEC スタックは VPN IPv4 サブ TLV のみの単一要素でよい。

MPLS echo request を受信したとき、受信側は (ping 対象の FEC スタックについて) コントロールプレーンとデータプレーンの両方が健全であり、かつ両平面が同期していることを検証することが期待される。手順は第 4.4 節を参照。

4.1. 等価マルチパス (ECMP) への対処 (Dealing with Equal-Cost Multi-Path)​

LSP は単純なポイントツーポイントトンネルとは限らない。単一の LSP は複数の入端で始まり複数の出端で終わるのが常である (LDP LSP でよくある)。特定の FEC の LSP は、中継 LSR において複数の "ネクストホップ" をもち得る。入端においても、所望の端点に到達するための複数の異なる LSP を選択し得る。最後に、LSP はバックアップパス、迂回パス、その他の代替パスをもち得る。

後二者を先に扱う：MPLS echo request を始める LSR は、echo request を任意の所望 LSP に強制投入できると仮定するため、入端での複数 LSP の選択は問題にならない。各種バックアップパス (通常、主 LSP がダウンするまでデータ転送に使われない) のプローブについては本ドキュメントでは扱わない。

特定のパケットが実際にとる LSP とパスは事前に不明となり得るため、MPLS echo request が可能な限りすべてのパスをたどれると有益である。しかしこれは理想的ではあるが、各 LSR が異なるパスにパケットを分配するために用いるアルゴリズムが独自仕様となり得るため非現実的である場合がある。

代替パスを一定範囲カバーするため、MPLS echo request の宛先 IP アドレスとソース UDP ポートの選択にある程度の自由度がある。これだけでは明らかに不十分である；traceroute の場合、ダウンストリームマッピング TLV のマルチパス情報がさらに自由度を与える。その用法は以下のとおり：入端 LSR は定期的に MPLS traceroute メッセージを送り、特定 LSP にマルチパスがあるかを決定する。あれば、各ホップは各ダウンストリームパスをどう駆動するかの情報を提供する。入端はこれらのパスをたどる MPLS echo request を送信できる。複数の LSR に ECMP がある場合、入端はそれらの組み合わせを試みてすべての可能なパスをたどってもよい (MAY)。しかし完全なカバーは実現不可能な場合がある。

4.2. MPLS ペイロードの搬送に用いられる LSP のテスト (Testing LSPs That Are Used to Carry MPLS Payloads)​

一部の LSP 中断を検出するため、MPLS ペイロードを搬送する LSP (L2VPN や L3VPN トラフィックを搬送する LSP 等) をテストする際、MPLS echo request を少なくとも 1 つの追加ラベルでカプセル化する必要がある場合がある (MAY)。例えば、LDP や RSVP-TE LSP をテストする際、単に MPLS echo request を送るだけでは検出できないことがある：LSP ping 宛先の直上流ルータが、倒数第 2 ホップポップ (penultimate hop popping) を用いて、MPLS ペイロードの搬送用に設定されていないインタフェース経由で MPLS echo request を正常に転送してしまった場合である。受信ルータは IP パケットがラベルなしで送られたか Implicit Null ラベルで送られたかを区別できないため、MPLS echo request の上に Nil FEC シムラベルを置くことで、この種のパケットが非ラベルインタフェース経由で転送されるのを防げる。

4.3. MPLS Echo Request の送信 (Sending an MPLS Echo Request)​

MPLS echo request は UDP パケットである。IP ヘッダの設定は以下のとおり：ソース IP アドレスは送信者のルーティング可能なアドレス；宛先 IP アドレスは 127/8 範囲 (IPv4) または 0:0:0:0:0:FFFF:127/104 範囲 (IPv6) から取った (ランダムに選んだ) アドレス。IP TTL は 1 に設定。ソース UDP ポートは送信者が選択；宛先 UDP ポートは 3503 (MPLS echo request 用に IANA が割り当て) に設定。IP ヘッダには MUST で Router Alert オプションを設定する。

MPLS echo request は、テスト対象 FEC スタックに対応するラベルスタックで送信される。なお (例えば) スタック頂 FEC への通常ルーティングがトラフィックエンジニアリングトンネル [RSVP-TE] 経由である場合、さらにラベルが適用され得る。スタック内のすべての FEC が Implicit Null ラベルに対応する場合、送信時にさらにラベルが適用されていても、MPLS echo request はラベルなしとみなされる。

echo request にラベルがある場合、(ping 対象により) 最内ラベルの TTL を 1 に設定して、ping 要求が過剰に遠くへ行くのを防いでもよい。そうすべき例には、VPN IPv4 や IPv6 プレフィックス、L2 VPN エンドポイント、疑似回線の ping が含まれる。ping 要求が過剰に遠くへ行くのを防ぐには、ラベルに Router Alert ラベルを挿入してもよい；しかしこれは MPLS echo request が実データとは異なるデータパスをとるという望ましくない副作用をもたらす可能性がある。これらの機構が疑似回線接続性検証にどう用いられるかは [VCCV] を参照。

"ping" モード (エンドツーエンド接続性チェック) では、最外ラベルの TTL は 255 に設定される。"traceroute" モード (障害分離モード) では、TTL は順に 1、2、… と設定される。

送信側は Sender's Handle と Sequence Number を選択する。後続の MPLS echo request 送信時は、Sequence Number を 1 増やすべき (SHOULD)。ただし送信側は同じ Sequence Number をもつ echo request の一群を送信して、その Sequence Number を含む少なくとも 1 つのパケットが到達する機会を高めてもよい (MAY)。

TimeStamp Sent は echo request 送信時刻 (秒とマイクロ秒) に設定。TimeStamp Received はゼロとする。

MPLS echo request には MUST で FEC スタック TLV が必要である。さらに、応答モードは MUST で所望の応答モードに設定する；リターンコードとサブコードはゼロとする。"traceroute" モードでは、echo request は SHOULD でダウンストリームマッピング TLV を含む。

4.4. MPLS Echo Request の受信 (Receiving an MPLS Echo Request)​

MPLS echo request がコントロールプレーンに送られるのは、以下のいずれかのパケット処理例外によってトリガされる：Router Alert オプション、IP TTL 満了、MPLS TTL 満了、MPLS Router Alert ラベル、または 127/8 アドレス範囲内の宛先アドレス。コントロールプレーンはさらに UDP 宛先ポート 3503 によってそれを識別する。

報告の目的上、スタック底はスタック深さ 1 とみなされる。これは、実際のスタックが Target FEC スタック内の FEC より多くのラベルを含み得る場合の絶対基準を設けるためである。

さらに、本ドキュメントに挙げるすべてのエラーコードにおいて、スタック深さ 0 は "未指定値" を意味し、リターンサブコードフィールドを使用しない既存実装との互換性のためである。

MPLS echo request を受信した LSR X は以下のように処理する：

  1. パケット全体の正当性を検証する。パケット形式が不良なら、LSR X はリターンコード "Malformed echo request received"、サブコード 0 の MPLS Echo Reply を送信すべき (SHOULD)。"Ignore" とマークされておらず LSR X が理解できない TLV があれば、LSR X は適切な MPLS "TLV not understood"、サブコード 0 を送信すべき (SHOULD)；後者の場合、応答の Errored TLVs TLV にこれらの理解不能 TLV をサブ TLV としてのみ含める。ヘッダフィールド Sender's Handle、Sequence Number、Timestamp Sent は検査されないが、MPLS echo reply メッセージに含まれる。

アルゴリズムは以下の変数と識別子を使用する：

  • Interface-I： MPLS echo request を受信したインタフェース。
  • Stack-R： パケット受信時のラベルスタック。
  • Stack-D： ダウンストリームマッピング TLV で運ばれるラベルスタック (存在するとは限らない)。
  • Label-L： 実際のスタックから現在検査中のラベル。初期化不要。
  • Label-stack-depth： 検証中のラベル深さ。受信ラベルスタック S 内のラベル数に初期化。
  • FEC-stack-depth： 現在の実ラベルの検証に適用する Target FEC スタック内の FEC の深さ。初期化不要。
  • Best-return-code： 現在既知の最良の echo reply リターンコード。アルゴリズムが進むにつれ、このコードはさらに検査により変わり得る。
  • Best-rtn-subcode： Best-return-code と同様だが Echo Reply サブコード用。
  • FEC-status： 第 4.4.1 節 FEC チェックアルゴリズムが返す結果値。

  1. echo request が良好なら、LSR X は echo を受信したインタフェースを Interface-I に、受信時のラベルスタックを Stack-R に格納する。

  2. ラベル検証 (Label Validation)：

    Label-stack-depth が 0 なら：FEC-stack-depth を 1 に、Label-L を 3 (Implicit Null) に設定；Best-return-code を 3 ("Replying router is an egress for the FEC at stack depth")、Best-rtn-subcode を FEC-stack-depth 値 (1) に設定し、ステップ 5 (Egress Processing) へ。

    さもなければ、Stack-R の Label-stack-depth 深さから Label-L を取り出し、入ラベルマップ (ILM) で検索して、ラベルが割り当てられており何らかの操作に関連付けられているかを決定する。L のエントリがなければ：Best-return-code を 11 ("No label entry at stack-depth")、Best-rtn-subcode を Label-stack-depth に設定し、ステップ 7 (Send Reply Packet) へ。さもなければ、対応する NLFE から関連ラベル操作を取り出し、ステップ 4 へ。

  3. ラベル操作チェック (Label Operation Check)：

    ラベル操作が "Pop and Continue Processing" (Explicit Null と Router Alert ラベルを含む) なら：Label-stack-depth を減らして次のラベルへ反復し、ステップ 3 に戻る。

    ラベル操作が "Swap or Pop and Switch based on Popped Label" なら：Best-return-code を 8 ("Label switched at stack-depth")、Best-rtn-subcode を Label-stack-depth に設定し、中継交換を報告する。受信した echo request にダウンストリームマッピング TLV があれば：TLV 内 IP アドレスが 127.0.0.1 または 0::1 なら、Best-return-code を 6 ("Upstream Interface Index Unknown") に設定し、応答には SHOULD で Interface and Label Stack TLV を含め、Interface-I と Stack-R を埋める。さもなければ、ダウンストリームマッピング TLV 内 IP アドレス、インタフェースアドレス、ラベルスタックが Interface-I と Stack-R に一致するか検証する；一致しなければ、Best-return-code を 5 ("Downstream Mapping Mismatch") に設定し、応答には SHOULD で Interface and Label Stack TLV を含め、Interface-I と Stack-R に基づき埋め、ステップ 7 へ。利用可能な各ダウンストリーム ECMP パスについて：NHLFE エントリから出力インタフェースを取り出す；出力インタフェースで MPLS が有効でなければ、Best-return-code を 9 ("Label switched but no MPLS forwarding at stack-depth")、Best-rtn-subcode を Label-stack-depth に設定し、Send_Reply_Packet へ。ダウンストリームマッピング TLV があれば、応答には SHOULD で現在の ECMP パス情報を埋めたダウンストリームマッピング TLV を含める。ダウンストリームマッピング TLV がなければ、またはダウンストリーム IP アドレスが ALLROUTERS マルチキャストアドレスに設定されていれば、ステップ 7 へ。"Validate FEC Stack" フラグがセットされておらず、LSR が FEC チェックを既定で実行するように設定されていなければ、ステップ 7 へ。

    FEC-stack-depth の決定：ダウンストリームマッピング TLV の Stack-D を底から上へたどり、Implicit Null でないラベルごとにラベル数を減らし、ラベルごとに FEC-stack-depth を増やす；1 つ以上の Implicit Null ラベルを含む場合、FEC-stack-depth は Label-stack-depth より大きくなり得る。FEC-stack-depth を 0、i を Label-stack-depth とする；i>0 の間：++FEC-stack-depth；Stack-D[FEC-stack-depth]!=3 (Implicit Null) なら --i。FEC スタック内ラベル数 >= FEC-stack-depth なら、4.4.1 節 FEC チェック手順を実行する；FEC-status が 2 なら Best-return-code を 10 に設定；リターンコードが 1 なら Best-return-code を FEC-return-code に、Best-rtn-subcode を FEC-stack-depth に設定。ステップ 7 へ。

  4. 出口処理 (Egress Processing)：受信した echo request にダウンストリームマッピング TLV がなければ、またはダウンストリーム IP アドレスが 127.0.0.1 または 0::1 なら、ステップ 6 (Egress FEC Validation) へ。ダウンストリームマッピング TLV 内 IP アドレス、インタフェースアドレス、ラベルスタックが Interface-I と Stack-R に一致するか検証する；一致しなければ、Best-return-code を 5 に設定し、応答には SHOULD で Received Interface and Label Stack TLV を作成し、ステップ 7 へ。

  5. 出口 FEC 検証 (Egress FEC Validation)：FEC-stack-depth から始まる Target FEC スタックのすべてのエントリについてループする。4.4.1 節アルゴリズムで Label-L と FEC-stack-depth の FEC に対し FEC チェックを実行；Best-return-code を FEC-code に、Best-rtn-subcode を FEC-stack-depth 値に設定する。FEC-status が 1 ならステップ 7 へ。++FEC-stack-depth；FEC-stack-depth > FEC スタック内 FEC 数ならステップ 7 へ。FEC-status が 0 なら：++Label-stack-depth；Label-stack-depth > Stack-R 内ラベル数ならステップ 7 へ；Label-L = Stack-R の Label-stack-depth 深さから取り出したラベル；ステップ 6 に戻る。

  6. 応答パケットの送信 (Send Reply Packet)：リターンコード Best-return-code、リターンサブコード Best-rtn-subcode の MPLS echo reply を送信し、上記過程で作成したすべての TLV を含める。echo reply の送信手順は 4.4.1 節を参照。

4.4.1. FEC 検証 (FEC Validation)​

本節は Target FEC スタック内の FEC エントリの検証を記述し、FEC、Label-L、Interface-I を受け取る。アルゴリズムの手順は以下のとおり：

  1. 2 つの戻り値 FEC-status と FEC-return-code を 0 に初期化する。
  2. FEC が Nil FEC なら：Label-L が Explicit_Null または Router_Alert なら return。さもなければ、FEC-return-code を 10 に、FEC-status を 1 に設定し return。
  3. LSP 上で受信トラフィックがさらにどう交換されるか、またはどのアプリケーションに関連付けられるかを記述する FEC ラベルマッピングを検査する。マッピングがなければ、FEC-return-code を 4 ("Replying router has no mapping for the FEC at stack-depth")、FEC-status を 1 に設定し return。
  4. FEC のラベルマッピングが Implicit Null なら、FEC-status を 2 としてステップ 5 へ。さもなければ、FEC のラベルマッピングが Label-L ならステップ 5 へ。さもなければ、FEC-return-code を 10 に、FEC-status を 1 に設定し return。
  5. プロトコルチェック：FEC のアドバタイズに用いられるプロトコルを検査する。Interface-I に関連付けられたプロトコルがその FEC タイプの FEC をアドバタイズしないと決定できれば、FEC-return-code を 12 ("Protocol not associated with interface at FEC stack-depth")、FEC-status を 1 に設定する。
  6. return。

4.5. MPLS Echo Reply の送信 (Sending an MPLS Echo Reply)​

MPLS echo reply は UDP パケットである。それは MPLS echo request への応答としてのみ送信されなければならない (MUST)。ソース IP アドレスは応答者のルーティング可能なアドレス；ソースポートは LSP ping の well-known UDP ポート。宛先 IP アドレスと UDP ポートは echo request のソース IP アドレスとソース UDP ポートからコピーする。IP TTL は 255 に設定。echo request の応答モードが "Reply via an IPv4 UDP packet with Router Alert" なら、IP ヘッダには MUST で Router Alert IP オプションを含める；LSP 経由で応答を送る場合、最上位ラベルは MUST で Router Alert ラベル (1) [LABEL-STACK] とする。

echo reply の形式は echo request と同じ。Sender's Handle、Sequence Number、TimeStamp Sent は echo request からコピー；TimeStamp Received は echo request 受信時刻に設定する (要求側と応答側の時計が同期していれば、この情報が最も有用)。echo request の FEC スタック TLV は応答へコピーしてもよい (MAY)。

応答側は前小節で決定したリターンコードとサブコードを埋めなければならない (MUST)。

echo request に Pad TLV があれば、応答側は応答のしかたについての指示を最初のバイトで MUST で解釈する。

応答ルータが FEC の宛先なら、echo reply にダウンストリームマッピング TLV を含めるべきではない (SHOULD NOT)。

echo request にダウンストリームマッピング TLV があり、応答ルータが FEC の宛先でなければ、応答側は SHOULD でそのダウンストリームルータと対応する入ラベルのラベルを計算し、回送する echo reply に各ダウンストリームルータ向けのダウンストリームマッピング TLV を追加する。

ダウンストリームマッピング TLV に含まれるマルチパス情報の処理が受信ルータの実行を望む量を超える場合、応答ルータは MAY で echo request のダウンストリームマッピングに含まれるマルチパスの一部のみで応答してもよい。(注：echo request 起動側は、応答に含まれなかったマルチパス情報をもつ別の echo request を送ってもよい (MAY)。)

応答モード 4 ("Reply via application level control channel") を除き、echo reply は常に IP/MPLS ネットワークのコンテキストで送信される。

4.6. MPLS Echo Reply の受信 (Receiving an MPLS Echo Reply)​

LSR X は、自身が送信した MPLS echo request の応答のみを受け取るべきである (SHOULD)。したがって MPLS echo reply を受信したとき、X はパケットを解析して形式が良好か確認し、宛先 UDP ポートと Sender's Handle を用いて以前送信した echo request との一致を試みる。一致が見つからなければ X はその echo reply を破棄する；さもなければ Sequence Number の一致を検査する。

echo reply にダウンストリームマッピングが含まれ、X がさらに traceroute を望むなら、そのダウンストリームマッピングを次の echo request (TTL を 1 増やす) へ SHOULD でコピーする。

4.7. VPN IPv4 と IPv6 プレフィックスの問題 (Issue with VPN IPv4 and IPv6 Prefixes)​

通常、VPN IPv4 プレフィックスまたは VPN IPv6 プレフィックスへの LSP ping は、深さ 1 より大きいラベルスタックで送信され、最内ラベル TTL が 1 となり、ping がカスタマデバイスに到達する前に出口 PE で終端する。しかし一部の場合、ラベルスタックは ping が出口 PE にヒットする前に単一ラベルへ縮小し得る；これは ping を早期終了させる。複数 AS のキャリアーズキャリア VPN が一例である。

この問題を回避する一法は、この種の ping を受信した LSR が ping が早期終了したことに気づき、エラーコード 13 を返送することである。このとき起動 LSR は VPN ラベルの TTL を増やして ping を再試行できる。こうして入端 LSR は順に TTL 値を試し、VPN ping が出口 PE に到達できる値を見つける。

4.8. 非準拠ルータ (Non-compliant Routers)​

ping 対象の FEC スタックの出口が MPLS ping をサポートしなければ、応答は送信されず、可能性としての "偽陰性" となる。 "traceroute" モードで、中継 LSR が LSP ping をサポートしなければ、その LSR はいくつかの TTL (例 n) に対して応答しない。echo request を送信した LSR は SHOULD で TTL=n+1, n+2, …, n+k で echo request を送り、パスより下流の LSR をプローブすべきである。この場合、TTL>n の echo request に対しては、ダウンストリームマッピング TLV を含む応答を受け取るまで、ダウンストリームマッピング TLV の "Downstream IP Address" フィールドを ALLROUTERS マルチキャストアドレスに設定して送信すべき (SHOULD)。ラベルスタックはダウンストリームマッピング TLV から省略してもよい (MAY)。さらに、ダウンストリームマッピング TLV を含む echo reply を受け取るまで、"Validate FEC Stack" フラグを SHOULD で設定すべきではない (SHOULD NOT)。