RFC 4379 - 2. Motivation

2. 動機 (Motivation)

LSP がユーザートラフィックを配信できない場合、その障害が MPLS コントロールプレーンで検出できるとは限らない. このようなトラフィックの "ブラックホール" や誤ルーティングを、ユーザーが妥当な時間内に検出できるようにするツールと、障害を切り分ける機構を提供する必要がある.

本ドキュメントでは、これらの目標を達成する機構を記述する. この機構は ping/traceroute のパラダイムをモデルとしている. ping (ICMP echo request [ICMP]) は到達性の確認に用いられ、traceroute はホップバイホップの障害の局所化およびパストレースに用いられる. 本ドキュメントは、MPLS LSP をテストするための "ping" モードと "traceroute" モードを規定する.

基本的な考え方は、特定の転送等価クラス (Forwarding Equivalence Class, FEC) に属するパケットの MPLS パスが、実際にその FEC の出口であるラベルスイッチングルータ (Label Switching Router, LSR) で終端していることを検証することである. 本ドキュメントは、このテストを、その FEC に属する他のパケットと同じデータパスに沿ってパケット ("MPLS echo request" と呼ぶ) を送信することで行うことを提案する. MPLS echo request は、MPLS パスが検証されている FEC に関する情報も運ぶ. この echo request は、その FEC に属する他のパケットとまったく同様に転送される. "ping" モード (基本的な到達性確認) では、パケットはパスの終端に到達し、そこで出口 LSR のコントロールプレーンへ送られ、その LSR が自身が本当にその FEC の出口であるかを検証する. "traceroute" モード (障害切り分け) では、パケットは各 transit LSR のコントロールプレーンへ送られ、その LSR が自身が本当にこのパスの transit LSR であるかを種々のチェックで確認する. またこの LSR は、データプレーンと照らし合わせてコントロールプレーンを確認するのに役立つ追加情報、すなわち転送がルーティングプロトコルの決定したパスと一致しているかどうかを返す.

これらのツールの使い方の一つは、FEC を定期的に ping して到達性を確認することである. ping が失敗した場合は、traceroute を開始して障害の所在を特定できる. また、転送がコントロールプレーンと一致していることを検証するために、FEC に対して定期的に traceroute を行うこともできる. ただし、これは transit LSR に大きな負担をかけるため、慎重に使用すべきである.

2.1. アドレス範囲 127/8 の使用 (Use of Address Range 127/8)

上述のとおり、LSP ping は診断ツールとして意図されている. これは、MPLS ベースのサービスの提供者がネットワーク障害を切り分けられるようにすることを目的とする. 特に、LSP ping はコントロールプレーンとデータプレーンが同期していない状況を診断する必要がある. これは、MPLS echo request パケットをそのラベルスタックのみに基づいてルーティングすることによって行われる. つまり、IP 宛先アドレスは転送の判断に一切使用されない. 実際、MPLS echo request パケットの送信者は、LSP の終端にあるルータのアドレスを事前に知らないこともある.

MPLS ベースのサービスの提供者は、LSP が取り得るすべての可能なパスのトレースも必要とする. ほとんどの MPLS サービスは IP ユニキャスト転送に基づいているため、これらのパスは等コストマルチパス (Equal-Cost Multi-Path, ECMP) 負荷分散の対象となる.

このことから、次の要件が導かれる.

1. 対象の LSP が未知の形で故障している可能性があるとしても、診断パケットが MPLS サービスのユーザーに配信される可能性は絶対最小限に抑えなければならない (MUST).

2. LSP が途中で終端してしまう形で故障した場合、その診断パケットを IP 転送してはならない (MUST NOT).

3. したがって、診断パケットを変化させてすべての ECMP パスをたどらせる手段が必須 (REQUIRED) である.

明らかに、一般的なユニキャストアドレスを使用しても、最初の二つの要件のいずれも満たせない. アドレスに関する他のいくつかの選択肢が検討された. ネットワーク事業者が決めるプライベートアドレス空間の一部や、新しく指定された IPv4 リンクローカルアドレスである. プライベートアドレス空間の使用は、主要な MPLS ベースのサービスが IPv4 仮想プライベートネットワーク (Virtual Private Network, VPN) であり、VPN がしばしばプライベートアドレスを使用するため、効果がないと判断された.

IPv4 リンクローカルアドレスは、転送できる範囲が限定される点でより魅力的である. しかし、この範囲のアドレスを使用すると、故障した LSP から "脱出" した診断パケットの最初の受信者が、そのパケットが到着したインタフェースにたまたまそのアドレスを割り当てられていて、誤ってそのパケットを受け取ってしまう可能性が依然としてある. さらに、IPv4 リンクローカルアドレス範囲が割り当てられたのはごく最近である. 多くの導入済みルータは、その範囲のアドレスを持つパケットをデフォルトルートへ向けて転送してしまう.

IPv4 には 127/8 の範囲が、IPv6 にはそれを IPv4 マップ IPv6 アドレス (IPv4-mapped IPv6 address) として埋め込んだ同じ範囲が、いくつかの理由から選ばれた.

RFC 1122 は 127/8 を "Internal host loopback address" (内部ホストループバックアドレス) として割り当て、次のように述べている. "Addresses of this form MUST NOT appear outside a host." (この形式のアドレスはホストの外部に現れてはならない (MUST NOT).) したがって、ホストのデフォルトの動作はそのようなパケットを破棄することである. これは、診断パケットが誤ってホストに送られた場合に、黙って破棄されることを確実にするのに役立つ.

RFC 1812 [RFC1812] は次のように述べている.

ルータは、ループバックインタフェース経由の場合を除き、宛先アドレスがネットワーク 127 上にあるパケットを転送すべきではない (SHOULD NOT). ルータは、ネットワーク管理者がこのチェックを無効にできるスイッチを備えてもよい (MAY). そのようなスイッチを備える場合、そのデフォルトはチェックを実行すること (MUST) でなければならない.

これは、診断パケットが IP 転送されることが決してないことを確実にするのに役立つ.

127/8 アドレス範囲は 16M 個のアドレスを提供し、ECMP パスをたどるためにアドレスを変化させる際に大きな柔軟性を与える. 最後に、実装上の最適化として、127/8 は可能性のある LSP パケットを識別する簡単な手段を提供する.