要約

  • RFC 3429は、MPLSの予約値14をOAM Alert Labelとして割り当て、ユーザープレーンOAMパケットを識別できるようにした。これはITU-T Y.1711の機能全体を定義するものではない。
  • 対象となるPHPのケースでは、ペナルティメートホップが通常の最上位ラベルを外しても、OAMラベルとペイロードをMPLS OAM対応の出口まで転送する。ラベルを処理できない終端は別のケースで、当時のY.1711の適用範囲外だった。
  • パケット内のTTSIは送信元の入口LSRを識別する手掛かりになるが、LSPの健全性、顧客トラフィックの到達、アラームへの対処を証明しない。

最後の転送処理をどの装置が担うかは、単なる実装上の選択ではない。終端が二段のラベル検索をラインレートで行えない場合、MPLSの制御プレーンは前段のLSRに最上位ラベルを外させる。このPenultimate Hop Popping（PHP）で終端の処理は軽くなる。一方、運用保守（OAM）パケットについては、外側の転送ラベルがなくなっても、受信側にそのパケットの意味を伝える必要がある。

2002年のRFC 3429は、その識別子として値14を指定した。RFC 3032で予約されていたMPLSラベル値の一つをOAM Alert Labelに充て、ユーザープレーンのOAMパケットを通常のトラフィックから見分ける。値を予約することと、OAMの動作やネットワークの状態を保証することは別だ。

implicit-nullとOAMラベルは違う

PHPの要求に使うimplicit-null（値3）は、シグナリングで配布される制御上の値であり、パケットのラベルスタックには現れない。これに対し、OAM Alert Labelはパケット内に残る。RFC 3429のケース1では、終端もMPLS LSRとして動作しているが、二回の検索を避けるためにPHPを要求する。ペナルティメートホップは通常の最上位ラベルをポップし、OAMラベルとペイロードを保ったまま終端へ渡す。

終端がMPLS OAMに対応していれば、元の最上位ラベルがなくても、残ったスタックの先頭にある値14を見てOAMパケットと判別できる。パケットのTTSI（Trail Termination Source Identifier）は、RFC 3429が説明する経路で、そのOAMパケットを生成した入口LSRを示す。入口の識別がラベル剥離後も残る仕組みだが、TTSIが示すのは発信元までであって、各ホップの転送成否やアプリケーションへの配信ではない。

ITU-TのY.1711勧告が規定するCV、FDI、BDIなどのOAM機能、そのペイロード、RFC 3031のMPLSアーキテクチャ、そしてRFC 3429によるラベル割り当ては、関連するが同じ仕様ではない。値14を認識したという事実だけでは、特定機能の成功も、ユーザートラフィックの到達も分からない。

同じPHP要求でも終端能力は同じではない

RFC 3429のケース2では、終端ノードにMPLSラベルの検索・処理能力がなく、ラベル付きパケットも認識できない。それでもPHPを要求し得る。この要求は、ケース1と同じOAM能力を意味しない。RFC 3429は当時のY.1711 OAMがケース1だけに適用できるとし、ケース2とcarrier-supporting-carrierのシナリオを今後の検討事項に残した。

もしOAMを理解しない終端LSRにパケットが届けば、RFC 3429はそのパケットが破棄されると述べる。RFC 3031も、意味不明のラベルを安易に外して通常のIPパケットとして転送することに慎重だ。ラベルにはIPヘッダーだけでは復元できない転送上の意味が含まれ得るからである。誤った読み替えをせずに捨てることは安全側の選択だが、監視結果が得られないという問題は残る。

したがって、出口で記録が見つからないだけでは、パスが正常とも、PHPが原因で故障したとも言えない。終端にOAM機能がない、ポリシーでフィルタされた、前段で失われた、ペイロードの解析に失敗した、あるいは実際に経路で障害が起きた可能性を分けて調べる必要がある。

IANAの登録は実装一覧ではない

現在のIANA MPLS Label Values登録簿は値14をOAM Alert Labelとして掲載し、RFC 3429を参照している。安定した番号は、別々に書かれる仕様が同じパケット種別を指すのに役立つ。しかし、現在のどのLSRがY.1711を実装するのか、どのLSPでPHPが有効か、パケット破棄がどのように可視化されるかまでは示さない。

RFC 3429は2002年11月のInformational RFCであり、普及の調査報告ではない。歴史的に重要なのは、ITU-TがOAM機能を定め、IETFがMPLSラベルを予約し、さらにPHPの終端で必要となる能力境界が文章化されたことだ。登録簿が固定するのは共通の解釈であって、運用の結果ではない。

実経路を評価するなら、implicit-nullの通知、ペナルティメートホップの操作、終端で受信したスタック、OAM対応状況、TTSIと入口LSRの照合、各OAM機能の結果を別々に確認する必要がある。顧客サービスの到達性は、さらに別のデータプレーン証拠で確かめる。「ラベル14の登録」「OAM有効」「LSP正常」を一つの状態に畳み込めば、まだ測定していないサービス結果まで測れたことにしてしまう。

参照資料