要約

  • 正常なPCRepは、あるTED、制約、目的関数、ポリシーの下でPCEが解を得たことを示す。PCCの受け入れや装置への実装を示すものではない。
  • シグナリングまたはプログラミング、資源予約、RIB/FIB、LSP状態、パケット観測、サービス測定には、それぞれ後続の証拠が必要になる。

ネットワーク運用画面では、一つの緑色が多くを語りすぎることがある。計算要求は成功し、明示経路が表示され、コストも条件内に収まっている。その表示を見た人が「経路は開通した」と言えば、計算の完了が転送の完了へ一瞬で置き換わる。

しかし、その時点で答えが出たのは数学的、あるいはポリシー付きの探索問題だけである。ルーターのローカルポリシー、LSPの設定、転送表、実際のパケットは、まだ別の時間を生きている。

RFC 4655はこの境界をアーキテクチャとして表した。著者はAdrian Farrel、Jean-Philippe Vasseur、Jerry Ashであり、IETF PCEワーキンググループの成果である。PCEはネットワークグラフに計算上の制約を適用して経路を求める主体と定義される。外部PCEの図では、headendがサービス設定のシグナリングを始める前に計算を依頼し、PCEはTEDとローカルポリシーを用いて応答する。

計算とシグナリングは最初から別の箱に置かれている。

TEDは現在のネットワークそのものではない

Traffic Engineering Databaseには、PCEが把握するトポロジーと資源情報が入る。情報源はIGP拡張にも、帯域外同期にもなり得る。完全な場合も、部分的な場合もある。

RFC 4655は、同期が十分でなければ計算済み経路の失敗率や次善経路の可能性が高まると記す。計算後にリンク障害や予約状況の変化が起きることもある。したがって「実行可能な経路」という表現には、「その時点でPCEに見えていた状態に対して」という条件が付く。

RFC 5440はVasseurとJean-Louis Le RouxによるPCEP仕様である。PCReqには端点、帯域幅、セットアップ／保持優先度などを載せられる。制約は候補を除外し、RFC 5541の目的関数は残る候補の選び方を示す。さらにローカルポリシーは、依頼や応答そのものを左右する。

この四つ、つまりTED、制約、目的関数、ポリシーを保存しなければ、EROだけを後から見ても、なぜその答えになったかを再現できない。

PCRepが完了させる仕事

RFC 5440の成功シーケンスは、要求受信、経路計算成功、計算済み経路のPCCへの送信で終わる。EROは計算されたTE LSPの経路を符号化し、MPLSまたはGMPLS制御プレーンが直ちにシグナリングへ使える状態になる。

「使える」は「使った」ではない。

RSVP-TEなら、RFC 3209に基づくシグナリングと予約が次に走る。途中のノードで拒否されることもある。Segment Routingなら、RFC 9256がcandidate path、segment list、headendに実体化されたSR Policy、そこへsteerされたトラフィックを区別する。RFC 8664はSR情報をPCEPで運ぶが、headendのFIBを読み返す規格ではない。

両方式の実装機構は同じではない。それでも、計算結果とデータプレーン結果を分離する必要は共通している。

Statefulは「実行済み」の別名ではない

Stateful PCEではLSP状態の同期、更新、delegationが加わる。RFC 8231は、LSP状態の所有者がPCCに残ると明記する。PCEから届いた属性もPCCのローカルポリシーに従う。delegationは特定LSPの属性を更新する権限で、PCCは取り消すことができる。

状態を示す後続証拠がPCRptである。LSPがUpまたはActiveになればPCCが報告し、設定できなければDownと原因を報告する。さらにRFC 8231は、PCRepとPCRptには直接の対応関係がなく、一つのPCRepの後に複数の状態報告が続くことを説明する。

ここに運用上の重要な時間差がある。PCRepはPCEの計算について語り、PCRptはPCCが持つLSP状態について語る。RFC 8281によるPCE起点のLSPでも、起動要求と装置結果は同じ証拠ではない。

現実に近づく証拠の順番

まずPCCが応答を受け入れたかを確認する。次にシグナリングまたはプログラミングが実行されたか、必要な予約が成立したかを見る。RIBとFIBは別々に読み返す。その後、インターフェースカウンター、probe、path trace、flow telemetryでパケットを観測する。最後に定義された期間の遅延、損失、ジッター、可用性を使ってサービスやSLAを評価する。

RIBはFIBではない。FIBはパケットの利用実績ではない。一回のpath traceは月間SLAではない。証拠を段階化するのは手続きを増やすためではなく、意図を結果として報告しないためである。

実装文書にも同じ考え方が見える。JuniperのPCEP設定資料は、PCE属性を受け取った後にPCCがLSPを再シグナリングすると説明し、セッション、LSP、SPRING-TE、ルートを別コマンドで検証する。Paragonの障害対応資料には、サーバーがプロビジョニングを確認しても、PCCがシグナリングできずLSPがDownのままという例がある。これは一製品の挙動だが、確認応答と運用状態の差を具体化する。

Farrelの仕事を正しく位置づける

FarrelのIETFプロフィールには多数のRFCと役割が並ぶ。本稿で扱う功績は限定的であり、同時に重要である。FarrelはVasseur、Ashとともに、計算、情報、ポリシー、シグナリングを分けて検証できるPCEアーキテクチャを記述した。PCEP本体はVasseurとLe Rouxが執筆し、その後のstateful拡張、LSP initiation、SR対応は別の著者とコミュニティが積み上げた。実装者と運用者が最後の現実を作る。

一人に全てを帰属させないことは評価を弱めない。単一の文書を稼働中のシステム全体と取り違えない、という同じ原則を守ることになる。

出典一覧