[Multi-AS Segment Routing 検証連載 #0] Multi-AS Segment Routing で VPN を構築する記事を連載します

サマリ

Multi-AS での Segment Routing 活用について検証しています。
検証結果についてこれから連載します。
この記事では検証の概要（Multi-AS、Multi-vendor、SR で VPN と TE を実現）について述べます。

はじめに

イノベーションセンターの田島です。主にサービスプロバイダー網の技術検証から検証用 AS の設計・構築・運用まで担当しています。我々が検証に取り組む Multi-AS での Segment Routing 活用について、今回から複数回にわたって解説します。

記事一覧

※記事が公開され次第、リンクを追加します。

検証の背景と記事のねらい

我々サービスプロバイダーが拠点間通信の需要に応えるときは、専用の機器や回線を用意する場合ばかりではなく、共用の IP バックボーンを用意したうえで VPN などのサービスを実装し提供する場合もあります。この取り組みは、その IP バックボーンと VPN を構築する技術の話です。

IP バックボーンは単一の IGP で作られることが多いですが、中には単一の IGP で管理するのが難しいネットワークもあります。例えば単純にノード数が多かったり、構築経緯の異なるネットワーク同士を相互接続している、などの理由が考えられます。我々の取り組みはそういった場合においても、次のような利点をいかにして実現するのか実証するものです。

ネットワークを分割しそれぞれの独立性を保ちつつも同じ end-to-end の通信を提供する
単に通信できる以上の付加価値を付与する

この検証では AS による IGP 分割でネットワーク同士の疎結合を保ちつつ、それぞれの AS で Segment Routing（SR）を用いて end-to-end の通信をより詳細にコントロールする方式を実際に試しています。 SR は比較的新しい分野で情報が限定的になりがちなため、実証した内容をこうして記事として執筆することで情報提供と SR のさらなる発展を期待しています。我々の記事が SR の VPN と TE の技術に興味を持つきっかけとなり、技術理解や各キャリアルーターでの実装の一助となれば幸いです。

お約束ごとではありますが、一連の内容は NTT Com の現在および未来にわたるネットワークサービスの仕様を定めるものではありません。また記載内容は我々の検証環境で実際に行った結果を基にしており、再現性のある記述に努めますが、言及する各ルーターメーカーの実装内容や動作を保証するものではありません。

検証の概要

まずネットワークサービスの模式図を例示しネットワークの概念と用語を説明します。

サービスプロバイダー側が用意する中央のネットワークに、顧客のルーター Customer Edge（CE）が接続されます。 CE を収容するプロバイダー側のルーターを Provider Edge（PE）といい、特にパケットが CE から PE に入る方を ingress PE とよび、出る方を egress PE とよびます。図に示すように実際のルーターとリンクで構成されるアンダーレイ（Underlay）の上に ingress PE から egress PE までの仮想的なオーバーレイ（Overlay）経路があるというのが VPN の実装です。この経路を制御することを Traffic Engineering（TE）とよびます。

台数が増えるなどにより、アンダーレイを分割した場合を考えます。図には多くのルーターを例示できませんが次の図のように変わります。

検証では、このような状態でもオーバーレイの機能を維持するためには何が必要なのかを考えます。オーバーレイの機能とは複数のアンダーレイ AS を経由した VPN の実現と、そのような VPN 経路の TE の実現です。その際に各アンダーレイの実装自由度を確保するため、構成する機器のメーカー制約は導入しません。つまり、異機種間の相互接続ということになります。

まとめますと、これから紹介する我々の取り組みは