要約
- RFC 5251 のシャッフリングでは、入口 PE が Session と Sender Template の CPI を PPI に書き換え、出口 PE が逆変換して CPI を復元する。
- CE が一つのセッションを観測できても、どの世代の PIT が使われたか、意図した内部ポートが選ばれたか、物理交差接続やデータ面が成立したかは別の証拠を要する。
変わらない外観を作る変換
顧客装置が表明するのは、自分の名前空間で知っている二つのポートを結びたいという意思である。要求は別の識別体系を運用する事業者網に入り、遠端では再び顧客が理解できる名前で現れる。両端の CE だけを見れば、最初から最後まで同じセッションに見える。
RFC 5251 はこの動作を shuffling と呼ぶ。入口 PE は RSVP-TE の Session と Sender Template に入っている Customer Port Identifier、すなわち CPI を Provider Port Identifier、PPI に置換する。出口 PE は PPI を CPI に戻す。同じ顧客セッションを維持するために、下層の端点名は二度変わる。
これは曖昧さではなく、顧客と事業者のアドレス空間を分離する設計である。内部アドレスやトポロジーを顧客に公開しなくてよい。しかし、その利点を「内部でも何も変わらなかった」という証明に読み替えてはいけない。維持されたのはセッションの抽象であって、物理的な事実の全てではない。
三つの識別子は権限も異なる
CPI はポートの顧客側を示し、PPI は事業者側を示す。VPN-PPI は L1VPN の顧客アドレス領域で PE ポートを表現する。PPI の割り当ては事業者が管理し、CPI と VPN-PPI のアドレスは L1VPN 管理者が管理する。
番号なしポートでは、便宜上 PPI と VPN-PPI が同じポートインデックスを用いることがある。数値が等しくても、権限と意味の領域は統合されない。「ポート 17」だけを保存し、それが CPI、VPN-PPI、PPI のどれか、どの VPN か、どの境界で観測したかを失えば、変換履歴は再構成できない。
制御チャネルのアドレスにも同じ問題がある。CE と PE のアドレスは一つの L1VPN 内では一意でなければならないが、別の L1VPN では再利用できる。従って VPN との明確な関連付けが必要であり、アドレス単体を世界で一意な身元として扱うことはできない。
PIT の「現在」ではなく「その時」を残す
各 PE は VPN ごとの Port Information Table を持つ。PIT には CPI と PPI の組が入り、ローカルポートについては VPN-PPI の情報も入る。プロビジョニングのほか、RFC 5195 の BGP や RFC 5252 の OSPF による発見が材料を提供し得る。
ただし、発見の来歴と実行時の選択は分けて考えるべきだ。要求を受けた入口 PE は L1VPN に対応する PIT を選び、宛先 CPI を PPI に解決して信令オブジェクトを書き換える。遠端 PE は別の参照で逆変換を行う。二つの判断が顧客向けの一貫性を作る。
監査で必要なのは、後日見える最新 PIT ではなく、その瞬間に選ばれた正確な世代である。古い行、誤った VPN コンテキスト、誤設定された組み合わせでも、形式上は正しい変換を実行できる。RFC 5251 が管理設定の保護を重視し、偶発的な誤設定に対してデータ面検証を考慮するよう述べる理由はここにある。
隠されたトポロジーにも証跡が要る
事業者網内の信令は PPI を運ぶ。シャッフリングを採用した PE は、対象となる全ての RSVP-TE メッセージに境界変換を適用しなければならない。一部だけを変換すれば、同じセッションの状態がメッセージごとに食い違う。
顧客には一つの LSP と PE 間の仮想リンクが見え、事業者にはその内部区間が見える。PE は顧客に返すトポロジーを絞り、Record Route や Notification を境界で編集または削除できる。内部構成を守ること自体は正当である。ただし、簡略化された表示から隠れた物理経路を推定することはできない。
一つのセッションは、一つの物理ホップ、一つの波長、不変の経路を意味しない。さらに RFC 5251 は stitched や nested の構成も認める。RFC 5150 の LSP stitching や RFC 4206 の LSP hierarchy により、PE 間セッション、既存 LSP、forwarding adjacency を顧客要求に関連付けられる。外見が同じサービスでも、内部で残る受領記録は異なる。動作モードは証拠の一部である。
受理と物理接続を混同しない
発信 CE は既知の宛先を選ぶ。事業者ポリシーは許されるポート間トポロジーを制限する。PE は名前を解決し、内部経路を計算または補完する。宛先 CE は要求を受理する。それぞれは重要な決定だが、観測している対象が違う。
Path や Resv は制御面の記録であり、物理スイッチの状態を直接見たわけではない。資源予約、ラベルや波長の設定、保護状態、光学的連続性、顧客トラフィックは後の層に属する。CE 間試験が成功しても、それは送受信した試験信号についての証拠であり、SLA 性能やアプリケーション成果まで自動的に証明しない。
顧客が Explicit Route Object を与えた場合も、内部経路の権限が顧客へ移るわけではない。PE は ERO を拒否でき、許容される loose な指定でも内部経路を計算して挿入する。顧客の意思はサービスを制約するが、事業者の各ホップを決定するものではない。
変更後にも説明できる記録
最初に L1VPN、制御チャネル、元の送信元 CPI と宛先 CPI、要求時刻を保存する。次に PIT の世代と行の来歴、解決した PPI、書き換え前後の Session と Sender Template を保存する。出口では逆参照、復元した CPI、宛先 CE の応答を記録する。
その後の段に RSVP 状態、資源プログラミング、物理交差接続、データ面試験、サービス観測を置く。「session up」という一つの値に潰すと、設定変更後に過去の対応関係を説明できない。顧客から内部トポロジーを隠しても、事業者内部の保護された監査領域では顧客抽象と内部区間を結び付けられなければならない。
Lu Heng の現実層の規律を適用すれば境界は明快になる。顧客領域の名前は事業者領域の名前と同じ事実ではない。変換成功は物理接続の観測ではない。セッション継続はサービス継続そのものではない。稼働系の説明責任は、各境界が何を変え、何を実際に見たかを残すところから始まる。
情報源
- RFC 5251: Layer 1 VPN Basic Mode
- RFC Editor の RFC 5251 情報
- IETF Datatracker の RFC 5251 情報
- RFC 4847: Framework and Requirements for Layer 1 VPNs
- RFC 5253: Applicability Statement for L1VPN Basic Mode
- RFC 4208: GMPLS User-Network Interface
- RFC 3473: GMPLS RSVP-TE Extensions
- RFC 4204: Link Management Protocol
- RFC 4206: LSP Hierarchy with GMPLS TE
- RFC 5150: Label Switched Path Stitching
- RFC 5195: BGP-Based Auto-Discovery for L1VPNs
- RFC 5252: OSPF-Based L1VPN Auto-Discovery
- RFC 5920: Security Framework for MPLS and GMPLS Networks
- Lu Heng: Running-Code Primacy
- Lu Heng: On Reality Layers
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
