要約

  • 一つのBFDセッションでMPLS-TP Continuity Check（CC）とproactive Connectivity Verification（CV）をインターリーブする。CCはG-AChコードポイント 0x0022、CVは 0x0023 を使い、通常はCCの間に毎秒1個のCVを送る。
  • CVはSource MEP-ID TLVを追加する。sink MEPはこの変更されてはならない送信元識別子で誤接続を検出する。RDIはCCのBFD diagnosticフィールドだけに現れ、CVのdiagnosticフィールドは無視しなければならない。
  • 連続性喪失はセッション周期に相手のDetect Multiplier 3を掛けた検出時間で判断し、誤接続は1秒以内に検出する。誤接続からの離脱には、欠陥を示すCVを3.5秒間受信しないことが必要である。

仕組みと権限の分離

運用者はMEG、MEP-ID、CC周期、望ましいCV状態、認証状態と鍵を設定する。相手のdiscriminatorは設定する場合も、ローカルで割り当てる場合もある。送信元MEPは証拠を送るが、受信側が正しい対象に接続したと一方的に宣言する権限はない。sink MEPはSource MEP-IDと型、カプセル化、discriminatorとlabelの対応、認証を有効にした場合の認証結果を評価する。

誤ったカプセル化、予期しないSource MEP-IDまたは型、別のlabelに対応するdiscriminator、期待したdiscriminatorが誤ったlabelから届く状態、認証有効時の認証失敗はmis-connectivityの条件になり得る。欠陥に入るとsink MEPはクライアント処理へsignal failを示す。ただしトラフィックを遮断するかどうかは、パケットを受信した事実ではなく、MPLS-TP OAMフレームワークが定めるdefect consequent actionだけで決める。検出時間満了はdiagnostic 1、Link Down Indication後は5、検出したmis-connectivityは9で報告する。

coordinated operationでは1本の双方向BFDセッションが欠陥状態を追跡する。independent operationでは2本のセッションを使うため、相手のRDIを受信しても一方のセッションがUPのままになり得る。状態変更とPoll/Final交換はCCだけで行い、CVに含まれる状態情報やPoll/Finalは無視する。このため、運用者の設定、送信元MEPの証拠、sink MEPの分類、RFC 6371が位置付ける後続動作は別々の権限として扱う必要がある。

オペレーター検証フィクスチャ

  1. G-AChコードポイントがCC 0x0022、CV 0x0023になっているか確認する。GALを使う場合はスタックの最下部にあり、TTLが少なくとも1か確認する。
  2. CCと毎秒1個のCVの交互送信を捕捉し、連続性喪失の時間を「セッション周期×相手のDetect Multiplier 3」で照合する。規範にない遅延値を付け加えない。
  3. CVのSource MEP-ID TLVが期待したMEP-IDと一致し、型も一致し、途中のノードが値を変更していないか確認する。
  4. 自側と相手側のdiscriminatorが同じlabelに対応するか、さらに期待したdiscriminatorが誤ったlabelから来ていないか逆方向にも確認する。
  5. カプセル化、MEG、MEP-ID、CC周期、CV状態、認証フラグと鍵を設定記録と突き合わせる。認証失敗を、識別子が検証済みである証拠に置き換えない。
  6. RDIをCCのdiagnosticだけから読んでいるか、CVのdiagnosticを無視しているか確認する。CVのsession stateとPoll/Finalで状態を変更してはいけない。
  7. diagnostic 1（検出時間満了）、5（Link Down Indication）、9（mis-connectivity）を区別し、離脱に3.5秒の無欠陥CVが必要か確認する。
  8. coordinatedかindependentかを記録する。independentなら、ローカルUP、相手RDI、反対方向の状態を別々に残し、単一のUPをサービス判定にしない。
  9. Source MEP-ID TLVはBFD control-packet lengthの外側にあり、BFD digest authentication使用時もdigestに含まれない。この完全性上の論点を、認証成功だけで消去しない。

判断の順序

まずカプセル化とG-ACh搬送を確認し、次にlabelとdiscriminatorを照合する。その後、CVのSource MEP-IDと型が期待端点かを判定し、RDIはCC diagnosticからだけ読み、運用モードとタイマーを確認する。誤接続ならsink MEPの欠陥としてdiagnostic 9を報告し、3.5秒の離脱条件を待ち、クライアントへの作用はOAM consequent actionに従う。遠端RDIだけなら、independent modeでUPを「サービス正常」と書き換えず、ローカル状態、遠端欠陥、クライアントへの影響を分けて示す。

CVのないCCだけなら到達性は示せても、意図した送信元は確定できない。逆にCVのdiagnosticをRDIとして読むことは、無視すべきフィールドから権限を作ることになる。誤ったSource MEP-IDやlabel対応はパケットが届いても欠陥であり、UPはアプリケーションサービスの健全性を意味しない。資料はベンダー、運用者、採用率、選択されたモード、誤検知率、顧客影響時間、商業価値、復旧結果を示していない。事故や導入に関する申し立てもない。RFC 5880、5586、5921、5860、6371、5884、5885は、それぞれの状態機械、搬送、枠組み、要件、後続動作、MPLS/VCCVの役割に限って参照し、RFC 6428の処理規則を代替しない。errataは取得時点のスナップショットであり、追加の訂正主張ではない。

出典