JP7056626B2

JP7056626B2 - 通信システム及び通信方法

Info

Publication number: JP7056626B2
Application number: JP2019074382A
Authority: JP
Inventors: 幸洋鋒; 久史小島; 健桑原
Original assignee: Nippon Telegraph and Telephone Corp
Current assignee: Nippon Telegraph and Telephone Corp
Priority date: 2019-04-09
Filing date: 2019-04-09
Publication date: 2022-04-19
Anticipated expiration: 2039-04-09
Also published as: JP2020174259A; US20220166715A1; WO2020209099A1; US12052171B2

Description

本発明は、通信システム及び通信方法に関する。

SRv6（Segment Routing IPv6）を用いて、クラウド上の特定のサービスファンクション（SF: Service Function）を経由するEnd-to-End（E2E）通信を実現する技術が従来から知られている（例えば非特許文献１）。この従来技術を用いて、例えば、エンドユーザが利用する端末と、Internet上のパブリッククラウドとしてクラウドサービスを提供するサーバとの間で、データセンタやクラウド（プライベートクラウド）上の特定のSFを経由するE2E通信を実現する場合、図１に示すＳ１１～Ｓ１２によりキャリア網のエッジルータに対してE2Eの経路設定を行う必要がある。

（Ｓ１１）サービス事業者が管理するクラウドオーケストレータは、キャリア事業者が管理するコントローラに対して、SFインスタンス（例えば、或る特定のサービスを実現するコンテナやVM(Virtual Machine)インスタンス等）の情報等を含むクラスタNW情報を送信する。なお、クラスタNW情報には、SFインスタンスの識別子（アドレスやSID（Segment ID）等）やクラスタNWのゲートウェイ（GW）の情報等が含まれる。

（Ｓ１２）キャリア事業者が管理するコントローラは、SFインスタンス情報（例えば、SFインスタンスの識別子）等を含むクラスタNW情報に基づいて、端末とサーバとの間のE2E通信の経路を計算する。

（Ｓ１３）そして、キャリア事業者が管理するコントローラは、キャリア網のエッジルータに対してエンドユーザ毎に経路（ルーティング）を設定する。

C. Filsfils et.al., SRv6 Network Programming, draft-filsfils-spring-srv6-network-programming-07

しかしながら、上記の従来技術では、例えば、クラスタNWの環境や構成（例えば、SFインスタンスのアドレス設計やSFインスタンスの数等）に変更が生じる度に、サービス事業者はキャリア事業者に対して、SFインスタンス情報等を通知する必要がある。また、例えば、物理ホストの故障やソフトウェアのバージョンアップ、サービスの需要増によるSFインスタンスレプリカの増加、合併等によりSFインスタンスの識別子（アドレス／SID）は変更又は増減されるが、このような変更の度に、キャリア事業者はエッジルータの経路を更新又は設定し直す必要がある。

本発明は、上記の点に鑑みてなされたもので、サービスファンクション識別子の変更に対応可能なEnd to End通信を実現することを目的とする。

上記目的を達成するため、本発明の実施の形態では、通信装置間で１以上のサービス機能を経由したEnd-to-End通信をSegment Routing IPv6により実現する通信システムであって、予め決められた所定の範囲内のSegmentIDを抽象化した抽象化IDを用いて、前記End-to-End通信の通信元の通信装置からのパケットを転送する転送手段と、前記抽象化IDが含まれるパケットを受信した場合、前記抽象化IDを、前記サービス機能を提供するサービス機能インスタンスのアドレス又はSegmentIDに変換する変換手段と、を有することを特徴とする。

サービスファンクション識別子の変更に対応可能なEnd to End通信を実現することができる。

SRv6の経路設定の一例を説明するための図である。抽象化SIDの割当範囲の一例を説明するための図である。拠点内の動作の概略の一例を説明するための図である。抽象化SIDの払い出し及び事業者間の情報共有の一例を説明するための図である。ルーティング方式1-aの一例を説明するための図である。ルーティング方式1-bの一例を説明するための図である。ルーティング方式2の一例を説明するための図である。ルーティング方式3の一例を説明するための図である。変換テーブルの一例を説明するための図である。変換方式1の一例を説明するための図である。変換方式2の一例を説明するための図である。本実施形態に係る通信システムの全体構成の一例を説明するための図である。 NW情報取得装置の機能構成の一例を説明するための図である。リンクステート情報テーブルの一例を説明するための図である。経路情報テーブルの一例を説明するための図である。 DC情報テーブルの一例を説明するための図である。送信情報テーブルの一例を説明するための図である。サービス情報取得装置の機能構成の一例を説明するための図である。 SFC情報テーブルの一例を説明するための図である。抽象化SID情報テーブルの一例を説明するための図である。リソース情報テーブルの一例を説明するための図である。サービス要求情報テーブルの一例を説明するための図である。 SRv6ポリシ作成装置の機能構成の一例を説明するための図である。ポリシ配信装置の機能構成の一例を説明するための図である。ポリシ情報管理テーブルの一例を説明するための図である。ルーティングヘッダ変換装置の機能構成の一例を説明するための図である。抽象化SIDの払い出し及び事業者間の情報共有を行う場合の一例を説明するためのシーケンス図である。ルーティング方式1-bにおけるパケットフォワーディング及びルーティングヘッダ変換の一例を説明するためのシーケンス図である。ルーティング方式2におけるパケットフォワーディング及びルーティングヘッダ変換の一例を説明するためのシーケンス図である。ルーティング方式3におけるパケットフォワーディング及びルーティングヘッダ変換の一例を説明するためのシーケンス図である。コンピュータのハードウェア構成の一例を説明するための図である。

以下、本発明の実施の形態（本実施形態）について、図面を参照しながら詳細に説明する。本実施形態では、SRv6によりルーティングを行うものとして、個々のSFインスタンスの識別子を抽象化したSID（以降、「抽象化SID」と表す。）を用いることで、個々のSFインスタンスの識別子（アドレス／SID）の変更に対応可能な（つまり、個々のSFインスタンスの識別子の変更が、キャリア網のエッジルータの経路設定に影響がない）通信システム１について説明する。なお、SRv6ではSIDとしてアドレス（IPv6アドレス）を用いることが多いため、アドレスとSIDとは同じである場合が多い。

＜抽象化SIDの割当範囲＞
上述したように、本実施形態では、個々のSFインスタンスの識別子を抽象化した抽象化SIDを用いる。抽象化SIDは、ユニーク（一意）かつ静的な識別子であり、SFインスタンスの集合毎に割り当てられる。

例えば、図２（ａ）に示すように、同一のクラスタNWに属するコンテナ（SFインスタンスの一例）に対して同一の抽象化SIDを割り当てることが考えられる。図２（ａ）では、クラスタNW1に属する6つのコンテナに対して或る同一の抽象化SIDが割り当てられていると共に、クラスタNW2に属する4つのコンテナに対して或る別の同一の抽象化SIDが割り当てられている例を示している。

また、例えば、図２（ｂ）に示すように、同一のクラスタNWに属するコンテナのうち、同一のサービスを提供するコンテナに対して同一の抽象化SIDを割り当てることが考えられる。図２（ｂ）では、クラスタNW1に属するコンテナのうち、IPS（Intrusion Prevention System又はIntrusion Protection System）サービスを提供する3つのコンテナに対して或る同一の抽象化SIDが割り当てられていると共に、FW（Fire Wall）サービスを提供する3つのコンテナに対して或る別の同一の抽象化SIDが割り当てられている例を示している。

そして、キャリア事業者が管理するコントローラでは、抽象化SIDを用いて、E2E通信の経路計算とエッジルータに対する経路設定とを行う。これにより、SFインスタンスの識別子（アドレス／SID）が変更になった場合であっても、サービス事業者は、個々のSFインスタンスの識別子をキャリア事業者に通知する必要がなくなる。また、抽象化SIDは静的であるため、SFインスタンスの識別子（アドレス／SID）が変更になった場合でもエッジルータの経路設定には影響せず、トラヒックステアリングを安定的に実現することができるようになる。

なお、抽象化SIDの割当範囲となるSFインスタンス集合は、同一クラスタNWや同一サービスに限られない。例えば、同一の拠点に属するSFインスタンスに対して同一の抽象化SIDが割り当てられてもよい。

ここで、拠点とはSFインスタンスを実現する物理ホストが含まれるネットワーク環境（又はシステム環境）のことである。典型的には、拠点としてはDC（データセンタ）が挙げられる。ただし、DC以外にも、例えば、クラウドサービスを実現するネットワーク環境又はシステム環境を拠点としてもよいし、MEC（Mobile Edge Computing）を実現するネットワーク環境又はシステム環境を拠点としてもよい。以降の本実施形態では、一例として、拠点はDCであるものとして説明する。なお、DC内のネットワーク環境は、イーサネット（登録商標）・ファブリック（Ethernet Fabric）により実現されているものとする。

＜拠点内の動作の概略＞
エンドユーザ（以降、単に「ユーザ」とも表す。）が利用する端末と、例えばパブリッククラウドとしてクラウドサービスを提供するサーバとの間で、特定のSFインスタンスを経由したE2E通信を実現するためには、抽象化SIDをSFインスタンスの識別子（アドレス／SID）に再変換する必要がある。

そこで、本実施形態では、拠点内の所定の装置（この装置を「拠点GW」と表す。）で抽象化SIDをSFインスタンスの識別子（アドレス／SID）に変換するものとする。この場合における拠点内の動作について、図３を参照しながら説明する。図３は、拠点内の動作の概略の一例を説明するための図である。ここで、拠点内のネットワーク環境は、Leaf&spine構造のL3ネットワークであるものとする。なお、後述するように、変換方式や拠点内のルーティング方式は複数の方式が考えられる。

（Ｓ２１）コンテナ（SFインスタンスの一例）やクラスタNWを管理するクラウドオーケストレータ（例えばKubernetes等）は、コンテナの起動時に、このコンテナの情報（例えば、コンテナの識別子（アドレス／SID）等）を拠点GWに送信する。

（Ｓ２２）拠点GWは、抽象化SIDとコンテナの識別子とを対応付けた変換テーブルを作成する。

（Ｓ２３）そして、拠点GWは、パケットを受信した場合、変換テーブルにより、当該パケットのDA（Destination Address）やSRH（Segment Routing Header）中の抽象化SIDをコンテナの識別子に変換する。これにより、当該パケットが該当のコンテナまでルーティングされる。

＜抽象化SIDの払い出し及び事業者間の情報共有＞
次に、抽象化SIDを払い出す場合と、トラヒックステアリングに必要な情報を事業者間（サービス事業者及びキャリア事業者間）で共有する場合とについて、図４を参照しながら説明する。図４は、抽象化SIDの払い出し及び事業者間の情報共有の一例を説明するための図である。

（Ｓ３１）サービス事業者は、SFインスタンスの集合に抽象化SIDを割り当てる（すなわち、抽象化SIDを払い出す）。ここで、サービス事業者が抽象化SIDを払い出すことは必須ではないが、抽象化SIDを広告（つまり、抽象化SIDを通知）する際に、ルートを集約して広告できるため、サービス事業者が保有するグローバルアドレスから抽象化SIDを払い出すことが好ましい。なお、抽象化SIDの払い出しは、例えば、サービス事業者が管理する任意の装置又は機器で行われればよい。

（Ｓ３２）サービス事業者は、上記のＳ３１で払い出した抽象化SIDをキャリア事業者に通知する。

（Ｓ３３）他方で、エンドユーザは、キャリア事業者に対してサービスの申し込みを行う。この申し込みには、例えば、エンドユーザが利用する端末のアドレスを示すSA（Source Address）と、E2Eで通信する通信先のアドレスを示すDAと、申し込み対象のサービス名と、そのサービスの順序（つまり、サービスチェインにおけるSFインスタンスの実行順序）とが含まれる。

ここで、エンドユーザはキャリア事業者に対してサービスの申し込みを行うのではなく、サービス事業者に対してサービスの申し込みを行ってもよい。ただし、一般に、SFインスタンスの実行順序の情報はキャリア事業者だけが必要な情報である。また、エンドユーザにとっては、複数のサービス事業者に個々に申し込みを行うよりも、キャリア事業者のみに申し込みを行う方が効率的である。そこで、エンドユーザは、キャリア事業者に申し込みを行うことが好ましい。なお、サービスの申し込みは、例えば、エンドユーザが利用する端末等で行われればよい。

（Ｓ３４）キャリア事業者は、サービスの申し込みに応じて、SFC（Service Function Chaining）情報を作成し、SFC情報テーブルに格納する。SFC情報には、SAと、SFインスタンスの識別子やサービス名等が実行順に格納された配列又はリスト（SFC[0], SFC[1], ・・・）とが少なくとも含まれる。SFC情報にはDAが含まれていてもよい。なお、SFC情報の作成及びテーブルへの格納は、例えば、キャリア事業者が管理する任意の装置又は機器で行なわれればよい。

（Ｓ３５）キャリア事業者は、サービスの利用情報として、SAとDAとのペアをサービス事業者に通知（広告）する。これにより、エンドユーザは、自身が申し込んだサービスが利用可能となる。なお、利用情報の通知は、例えば、キャリア事業者が管理する任意の装置又は機器で行なわれればよい。

なお、拠点内のルーティング方式として、後述するルーティング方式2を用いる場合、拠点GWはキャリア事業者が管理することなる。したがって、この場合、上記のＳ３１では、サービス事業者ではなく、キャリア事業者が抽象化SIDの払い出しを行うことが好ましい。

また、エンドユーザは、例えば、より詳細な設定が必要なSF（例えば、FWで業務に不要なポートをフィルタリングするためのSF等）を利用する場合等には、サービス事業者に対して、この設定のためのメタデータ等を送信してもよい。

＜ルーティング方式＞
次に、拠点内のルーティング方式について説明する。拠点内のルーティング方式は、拠点GWの位置等の性質に応じて、ルーティング方式1-a、ルーティング方式1-b、ルーティング方式2、及びルーティング方式3が考えられる。

ルーティング方式1-a及び1-bは、拠点のトラヒックが集約される場所に拠点GWを配置し、キャリア事業者が拠点GWを管理する場合に利用可能な方式である。また、ルーティング方式2は、クラスタNW毎に拠点GWを分散配置し、これらの拠点GWをキャリア事業者が管理する場合に利用可能な方式である。一方で、ルーティング方式3は、クラスタNW毎に拠点GWを分散配置し、これらの拠点GWをサービスが管理する場合に利用可能な方式である。以降では、これらのルーティング方式1-a～ルーティング方式3について説明する。

なお、以降では、一例として、拠点（データセンタ）内のネットワーク環境はKubernetesで管理されているものとする。また、以降の各ルーティング方式の説明では、抽象化SIDをコンテナ（SFインスタンス）のアドレス／SIDに変換しているが、この変換の詳細については後述する。

≪ルーティング方式1-a≫
本方式は、拠点内のクラスタNWを接続する拠点GW（キャリア事業者管理）を用いる方式である。この方式の動作について、図５を参照しながら説明する。図５は、ルーティング方式1-aの一例を説明するための図である。

本方式では、拠点内のネットワーク環境を構成する各ネットワーク機器（例えば、Leaf SwitchやSpine Switch等）と、全てのクラスタNWとに対して、Calico node等のCNI（Container Networking Interface）に代表されるような、クラスタNWと物理ホストや外部ネットワークを接続する仮想ルータ経由でSFインスタンスのアドレス（/64）を広告しておき、拠点GW以降はSFインスタンスの識別子（アドレス／SID）のみを使用してルーティングする。すなわち、図５に示すように、仮想ルータはコンテナにアドレス（/64）を割り当てて、eBGP（External BGP（Border Gateway Protocol））により当該アドレスを各ネットワーク機器と他のクラスタNW（つまり、他のKubernetes cluster）とに広告する。このとき、仮想ルータとコンテナとの間はiBGP（Internal BGP）により通信される。なお、CNIによって異なるが仮想ルータは、Kubernetes cluster（クラスタNWの一例）のmaster nodeとなる物理ホスト上や各物理ホスト毎に存在する。

本方式では以下のＳ４１～Ｓ４３によりルーティングが行われる。なお、前提として、抽象化SIDを受け取った時の動作（つまりSRポリシ）をクラウドオーケストレータから拠点GWに予め広告しておくものとする。

（Ｓ４１）拠点GWは、抽象化SIDを広告し、SFCのパケットを拠点GWに引き込む。

（Ｓ４２）拠点GWは、当該パケットのヘッダ中の抽象化SIDに対応するコンテナのアドレス（又はSID）を各クラスタNWにリクエストする。これにより、拠点GWは、当該リクエストに対する応答として、各コンテナのアドレス（又はSID）を得る。

（Ｓ４３）拠点GWは、パケットのヘッダ中の抽象化SIDをコンテナのアドレスに付け替える。これにより、拠点GWからコンテナまで一気通貫でルーティングが可能となる。なお、クラスタNW間はeBGPで通信可能であるため、拠点GWで付け替えたコンテナのアドレスでルーティングが可能である。

図５に示す例では、Kubernetes cluster1に属するコンテナに対して同一の抽象化SID「ff01::1」が割り当てられていると共に、Kubernetes cluster2に属するコンテナに対して同一の抽象化SID「ff02::1」が割り当てられている場合に、抽象化SID「ff01::1」及び「ff02::1」がこの順にSFCとして設定されたパケットを拠点GWが受信した場合のルーティングを示している。この場合、上記のＳ４２のリクエストで各コンテナのアドレス（又はSID）を得た後、上記のＳ４３で複数の抽象化SID「ff01::1」及び「ff02::1」が同時にコンテナのアドレス（又はSID）にそれぞれ付け替えられる。これにより、図５に示すルーティング（パケットの流れ）が実現される。

≪ルーティング方式1-b≫
本方式は、上記のルーティング方式1-aと同様に、拠点内のクラスタNWを接続する拠点GW（キャリア事業者管理）を用いて抽象化SIDとSFインスタンスのSIDとを変換する方式である。ルーティング方式1-aとルーティング方式1-bとでは、各SFインスタンスのSIDが広告されている範囲が異なる。このルーティング方式1-bの動作について、図６を参照しながら説明する。図６は、ルーティング方式1-bの一例を説明するための図である。

本方式では、ルーティング方式1-aでSFインスタンスがDCNW（つまり、拠点（データセンタ）内のネットワーク環境）からアクセス可能となることを防ぐため、拠点GWやLeaf Switchで折り返したルーティングを行う。このために、本方式では、拠点内のネットワーク環境を構成する各ネットワーク機器のうち、Leaf Switchであるネットワーク機器と、全てのクラスタNWとに対して、仮想ルータ経由でSFインスタンスのアドレス（/64）を広告しておく。そして、拠点GWは、Leaf Switchとコンテナのアドレスとを指定してルーティングを行う。

すなわち、図６に示すように、仮想ルータはコンテナにアドレス（/64）を割り当てて、eBGPにより当該アドレスをLeaf Switchと他のクラスタNWとに広告する。このとき、仮想ルータとコンテナとの間はiBGPにより通信される。

本方式では以下のＳ５１～Ｓ５３によりルーティングが行われる。

（Ｓ５１）拠点GWは、抽象化SIDを広告し、SFCのパケットを拠点GWに引き込む。

（Ｓ５２）拠点GWは、当該パケットのヘッダ中の抽象化SIDに対応するコンテナのアドレス（又はSID）を各クラスタNWにリクエストする。これにより、拠点GWは、当該リクエストに対する応答として、各コンテナのアドレス（又はSID）を得る。

（Ｓ５３）拠点GWは、パケットのヘッダから抽象化SIDをpopし、Leaf Switch（又はクラスタNWのGW）のアドレスと、コンテナのアドレス（又はSID）とを当該ヘッダにスタックする。これにより、クラスタNW間では拠点GW及びLeaf Switchを経由したルーティングが可能となる。

図６に示す例では、Kubernetes cluster1に属するコンテナに対して同一の抽象化SID「ff01::1」が割り当てられていると共に、Kubernetes cluster2に属するコンテナに対して同一の抽象化SID「ff02::1」が割り当てられている場合に、抽象化SID「ff01::1」及び「ff02::1」がこの順にSFCとして設定されたパケットを拠点GWが受信した場合のルーティングを示している。この場合、上記のＳ５２のリクエストで各コンテナのアドレス（又はSID）を得た後、上記のＳ５３で抽象化SIDがパケットのヘッダからpopされ、Leaf Switch（又はクラスタNWのGW）のアドレスとコンテナのアドレス（又はSID）とが当該ヘッダにスタックされる。これにより、図６に示すルーティング（パケットの流れ）が実現される。

≪ルーティング方式2≫
本方式は、クラスタNW毎に分散配置された拠点GW（キャリア事業者管理）を用いる方式である。この方式の動作について、図７を参照しながら説明する。図７は、ルーティング方式2の一例を説明するための図である。なお、クラスタNW毎に分散配置されている拠点GWをまとめて「拠点GWクラスタ」と表す。

また、各拠点GWはKubernetesのポッド（１つ以上のコンテナで構成されるグループ）で実現され、Kubernetes cluster1に配置される拠点GWを「Cluster1のGW用ポッド」、Kubernetes cluster2に配置される拠点GWを「Cluster2のGW用ポッド」等とも表す。

本方式では拠点GWがクラスタ毎に存在し、これらの拠点GWは、Leaf&Spine構造のL3NWとクラスタNWと間の通信やクラスタNW間の通信を行う際に必ず経由される。また、各拠点GWからクラスタNW（サービス事業者管理）までは、例えばVXLAN（Virtual eXtensible Local Area Network）等のトンネルで接続する。

本方式では以下のＳ６１～Ｓ６４によりルーティングが行われる。

（Ｓ６１）各拠点GW（例えば、Cluster1のGW用ポッドやCluster2のGW用ポッド等）は、該当のクラスタNW内に存在するサービスの抽象化SIDを広告する。

（Ｓ６２）GW（単にパケットを転送するだけのルータ又はスイッチ）から各拠点GWまでは抽象化SIDによりルーティングする。GWは、拠点内のネットワーク環境と拠点外のネットワーク環境との間で、単にパケットを転送するだけのルータ又はスイッチのことである。

（Ｓ６３）パケットを受信した拠点GWは、各クラスタNWのクラウドオーケストレータに対して、コンテナのアドレス（又はSID）をリクエストする。これにより、拠点GWは、当該リクエストに対する応答として、各コンテナのアドレス（又はSID）を得る。

（Ｓ６４）拠点GWは、トンネル（例えばVXLANやGRE（Generic Routing Encapsulation）等）を介して、当該拠点GWに対応するクラスタNWのコンテナにパケットを転送する。また、クラスタNW間でパケットを転送する際には、拠点GWクラスタを経由する。

図７に示す例では、Kubernetes cluster1に属するコンテナに対して同一の抽象化SID「ff01::1」が割り当てられていると共に、Kubernetes cluster2に属するコンテナに対して同一の抽象化SID「ff02::1」が割り当てられている場合に、抽象化SID「ff01::1」及び「ff02::1」がこの順にSFCとして設定されたパケットをGWが受信した場合のルーティングを示している。

この場合、上記のＳ６１での抽象化SIDの広告によりパケットが拠点GWポッドに引き込まれる。そして、上記のＳ６３のリクエストで同一クラスタNW内の各コンテナのアドレスを得た後、拠点GWポッドは、End.B6.Encaps又はNAT（Network Address Translation）を実施し、該当のコンテナのアドレスにDAを変換する。そして、当該拠点GWポッドは、該当のコンテナにパケットを転送する。

そして、当該拠点GWは、トンネル及び仮想ルータを介して、コンテナ1にパケットを転送する。

パケットを受信したコンテナ1は、End（Endpoint function）を実施する。これにより、コンテナ1でのSF処理後のDAは「ff02::1」となる。その後、コンテナ1は、Cluster1のGW用ポッドまでdefault routeでパケットを送信する。

続いて、コンテナ1から送信されたパケットを受信したCluster1のGW用ポッドは、iBGPにより、Kubernetes cluster2に対応する拠点GW（Cluster2のGW用ポッド）へパケットを転送する。

そして、Cluster2のGW用ポッドは、Cluster1のGW用ポッドと同様に、コンテナ2のアドレスを得た後、End.B6.Encapsを実施し、コンテナ2のアドレスにDAを変換する。これにより、トンネル及び仮想ルータを介して、コンテナ2にパケットが転送され、図７に示すルーティング（パケットの流れ）が実現される。

≪ルーティング方式3≫
本方式は、クラスタNW毎に分散配置された拠点GW（サービス事業者管理）を用いる方式である。この方式の動作について、図８を参照しながら説明する。図８は、ルーティング方式3の一例を説明するための図である。なお、各拠点GWはKubernetesのポッドで実現され、Kubernetes cluster1に配置される拠点GWを「拠点GWポッド1」、Kubernetes cluster2に配置される拠点GWを「拠点GWポッド2」等とも表す。

本方式では、各拠点GWポッドのアドレスを仮想ルータ等で広告しておき、拠点GWポッドがパケットを受信したタイミングで抽象化SIDを外して、コンテナのアドレス（又はSID）をencapすることで、E2E通信を確率する。

本方式では以下のＳ７１～Ｓ７４によりルーティングが行われる。

（Ｓ７１）各拠点GW（例えば、拠点GWポッド1や拠点GWポッド2等）は、抽象化SIDを広告する。このとき、各拠点GWは、loopbackアドレスを抽象化SIDとして、クラスタNW内にはiBGPにより、クラスタNW外にはeBGPにより広告する。これにより、パケットが該当の拠点GWポッドに引き込まれる（すなわち、単にパケットを転送するだけのルータ又はスイッチであるGWや他の拠点GWポッドから、該当の拠点GWポッドまでパケットが転送される。）。

（Ｓ７２）パケットを受信した拠点GWポッドは、同一クラスタNWのクラウドオーケストラに対して、コンテナのアドレス（又はSID）をリクエストする。これにより、当該拠点GWポッドは、当該リクエストに対する応答として、同一クラスタNW内の各コンテナのアドレス（又はSID）を得る。

（Ｓ７３）当該拠点GWポッドは、当該パケットのヘッダ中の抽象化SIDを該当のコンテナのアドレスに変換した上で、当該パケットを送信する。これにより、該当のコンテナに当該パケットが転送される。

（Ｓ７４）また、新たな抽象化SIDがDAになった場合、拠点GWポッドは、該当の抽象化SIDを広告する拠点GWポッドまでパケットを送信する。これにより、次の拠点GWポッドまで当該パケットが転送される。

図８に示す例では、Kubernetes cluster1に属するコンテナに対して同一の抽象化SID「ff01::1」が割り当てられていると共に、Kubernetes cluster2に属するコンテナに対して同一の抽象化SID「ff02::1」が割り当てられている場合に、抽象化SID「ff01::1」及び「ff02::1」がこの順にSFCとして設定されたパケットをGWが受信した場合のルーティングを示している。

この場合、上記のＳ７１での抽象化SIDの広告によりパケットが拠点GWポッドに引き込まれる。そして、上記のＳ７２のリクエストで同一クラスタNW内の各コンテナのアドレスを得た後、拠点GWポッドは、End.B6.Encaps又はNAT（Network Address Translation）を実施し、該当のコンテナのアドレスにDAを変換する。そして、当該拠点GWポッドは、該当のコンテナにパケットを転送する。

パケットを受信したコンテナでは、End（Endpoint function）を実施する。これにより、当該コンテナでのSF処理後のDAが別の抽象化SIDに変換される。その後、コンテナは、同一クラスタNWの拠点GWポッドまでdefault routeでパケットを送信する。

続いて、同一クラスタNWのコンテナから送信されたパケットを受信した拠点GWポッドは、Leaf&Spine構造のL3NW経由で、他のクラスタNWの拠点GWポッドに当該パケットを転送する。これにより、図８に示すルーティング（パケットの流れ）が実現される。

＜変換方式＞
次に、抽象化SIDをSFインスタンス（例えば、コンテナやVM等）の識別子（アドレス／SID）に変換する方式について説明する。変換方式としては、NATベースの変換方式（変換方式1）及びSRv6のEnd Functionを用いた変換方式（変換方式2）が考えられる。以降では、これらの変換方式について説明する。なお、抽象化SIDからSFインスタンスの識別子への変換は、上記の図５及び図６の拠点GW、図７の拠点GWクラスタ、又は図８の拠点GWポッドで行われる。

≪変換方式1≫
本方式は、NATベースで変換する方式である。本方式では、拠点GWが具備するNAT機能により、パケットのヘッダのDAを変換する（なお、SRHは書き換えない。）。このとき、本方式では、SA毎に変換前後のDAを対応付けたテーブル（変換テーブル）を用いて、ヘッダのDAを変換する。なお、拠点GWではSRv6の処理（例えば、End（Endpoint function）やT（Transit behavior）等）は行わずに、NA変換されたDAでコンテナに向けてフォワードする。

ここで、変換テーブルの一例を図９に示す。図９は、変換テーブルの一例を説明するための図である。図９に示すように、変換テーブルは、SA毎に、DA（変換前のDA）と、変換後のDAとが対応付けられている。このとき、変換前のDAには抽象化SIDが、変換後のDAにはコンテナ（SFインスタンス）のアドレス（又はSID）が設定される。これにより、拠点GWは、パケットのSAに応じて、抽象化SIDをSFインスタンスの識別子（アドレス／SID）に変換することができる。

クラウドオーケストレータは、サービスに加入しているユーザのアドレスや、SFインスタンスであるコンテナのアドレス／SIDの情報を保有している。このため、拠点GWは、これらの情報をクラウドオーケストレータから取得し、ユーザのアドレスとコンテナのアドレスとの対応関係を格納することで、上述した変換テーブルを作成することができる。

例えば、図１０に示すように、サービス1のクラスタNWに属するコンテナ1にパケットを転送した後、サービス2のクラスタNWに属する或るコンテナにパケットを転送する場合を考える。この場合、サービス1のクラスタNWのルーティング機能（例えば、Linux（登録商標）のiptables等）により、拠点GWからのパケットがコンテナ1に転送された後、サービス2のクラスタNWにパケットが転送される。

このとき、例えば、拠点GWでのNAT変換前では、DAは「ff01::1（サービス1の抽象化SID）」、SAは「端末のv6アドレス」、SRHは「<サーバ, ff02::1, ff01::1, SL=2>」である。NAT変換後では、DAは「コンテナ1のアドレス」、SAは「端末のv6アドレス」、SRHは「<サーバ, ff02::1, ff01::1, SL=2>」となる。また、コンテナ1に到達後では、DAは「ff02::1（サービス2の抽象化SID）」、SAは「端末のv6アドレス」、SRHは「<サーバ, ff02::1, ff01::1,SL=1>」となる。なお、SLは、SRHのsegment listの中で現在DAに設定されているSIDを示すインデックスのことである。

クラウドオーケストレータは上記のDA, SA, SRHのうち、NAT変換後及びコンテナ1に到達後のDA, SA, SRHの情報をルーティング機能やコンテナ1から取得し、変換テーブル作成に必要な情報として拠点GWに送信する。これにより、拠点GWは、変換テーブルを作成することができる。なお、NAT変換前のDA, SA, SRHの情報は拠点GWが保持している。

具体的には、NAT変換前後の情報を参照して、SA「端末のv6アドレス」と、DA「ff01::1（サービス1の抽象化SID）」と、変換後のDA「コンテナ1のアドレス」とを対応付けることで、変換テーブルのレコードを作成することができる。

≪変換方式2≫
本方式は、SRv6のEnd Functionを用いた変換方式である。本方式では、拠点GWでIPv6ヘッダ及びSRHをカプセル化し、新たなIPv6ヘッダのDAをコンテナのアドレス（又はSID）に変換する（なお、SAは変換しない。）。また、パケットを受信したコンテナは、例えば、My Local SID Tableを参照して、Endを実施し、次のサービスの抽象化SIDにDAを変換する。

SRポリシの投入方法については次のようにすればよい。すなわち、例えば、クラウドオーケストレータは、ユーザのアドレスとコンテナのアドレス（又はSID）との対応関係（例えば、図９に示す変換テーブル）を取得する。そして、クラウドオーケストレータと拠点GWとをPCEP（Path Computation Element Protocol）で接続する（このとき、拠点GWをPCC（Path Computation Client）とする。）。これにより、PCEPによってSIDとFunctionとのペアをポリシとして投入することが可能となる。なお、PCEPについては以下の参考文献を参照されたい。

［参考文献］
PCEP Extensions for Segment Routing leveraging the IPv6 data plane draft-negi-pce-segment-routing-ipv6-04

例えば、図１１に示すように、サービス1のクラスタNWに属するコンテナ1にパケットを転送した後、サービス2のクラスタNWに属する或るコンテナにパケットを転送する場合を考える。この場合、サービス1のクラスタNWのルーティング機能により、拠点GWからのパケットがコンテナ1に転送された後、サービス2のクラスタNWにパケットが転送される。クラウドオーケストレータは、例えばBGP-LU（BGP Labeled Unicast）等により抽象化SIDを拠点GWに広告しておくと共に、SRポリシを拠点GWに投入しておく。

このとき、例えば、拠点GWでのEnd.B6.Encaps実施前では、DAは「ff01::1（サービス1の抽象化SID）」、SAは「端末のv6アドレス」、SRHは「<サーバ, ff02::1, ff01::1, SL=2>」である。End.B6.Encaps実施後では、DAは「コンテナ1のアドレス」、SAは「端末のv6アドレス」、SRHは「<サーバ, ff02::1, ff01::1, SL=2>」及び「コンテナ1のSID, SL=0」となる。また、コンテナ1に到達後では、DAは「ff02::1（サービス2の抽象化SID）」、SAは「端末のv6アドレス」、SRHは「<サーバ, ff02::1, ff01::1,SL=1>」となる。

このように、本方式では、拠点GWでEnd.B6.Encapsを実施して、パケットをカプセル化した上で、新たなヘッダのDAをコンテナのアドレスとする。したがって、クラウドオーケストレータは、このための抽象化SIDとSRポリシとを予め拠点GWに広告及び投入しておく。

＜通信システム１の全体構成＞
次に、本実施形態に係る通信システム１の全体構成について、図１２を参照しながら説明する。図１２は、本実施形態に係る通信システム１の全体構成の一例を説明するための図である。

図１２に示すように、本実施形態に係る通信システム１には、端末１０と、経路制御装置２０と、NW装置３０と、拠点４０とが含まれる。経路制御装置２０、NW装置３０及び拠点４０は、管理NW内に設置等される機器や装置又は管理NW環境の一部を構成するネットワーク環境（若しくは、管理NW環境に含まれるネットワーク環境）である。

管理NWとは、ユーザネットワーク、データセンタ、インターネット（Internet）に接続するアクセス網等のIPv6網である。管理NWは、複数のNW装置３０と、その間を接続するリンクとで構成される。管理NWに接続可能な端末１０は、データ（パケット）を送信する装置であり、エンドユーザが利用する。端末１０として任意の装置を利用することが可能であり、その種別や通信特性（例えば、通信間隔や宛先数、パケットサイズ等）は問わない。

なお、図１等のキャリア網は管理NWに相当する。また、図１等のエッジルータやGWR、キャリア網を構成する各種ネットワーク機器（不図示）等はNW装置３０に相当する。図１等の端末は端末１０に相当する。

拠点４０は、例えばDC（データセンタ）等であり、その内部のネットワーク環境では複数の物理ホスト（コンピュータノード）６０がファブリック構造で接続されている。クラウドオーケストレータ７０は、例えばKubernetes等で実現され、物理ホスト６０上の仮想ホスト３１０やクラスタNWを管理する。仮想ホスト３１０は、例えばコンテナやVM等のSFインスタンスである。これらの仮想ホスト３１０やクラスタNWはサービスを提供している。なお、以降では、仮想ホスト３１０はコンテナであるものとして、「コンテナ３１０」とも表す。

ルーティングヘッダ変換装置５０は、ルーティング機能を有し、受信したパケットのルーティングヘッダ（すなわち、IPv6ヘッダやSRH等）のパラメータ（例えば、DA等）を変換してパケットをフォワーディングする。図３や図５～図６等の拠点GW、図７の拠点GWクラスタ、及び図８の拠点GWポッドは、ルーティングヘッダ変換装置５０（又は、ルーティングヘッダ変換装置５０を実現するプログラム若しくは機能）に相当する。

経路制御装置２０は、例えば管理NW内のNW装置３０とピア関係にあり、E2E通信の経路をNW装置３０に設定する。また、図１等のコントローラは経路制御装置２０に相当する。経路制御装置２０は、例えば、NW情報取得装置２１０と、サービス情報取得装置２２０と、SRv6ポリシ作成装置２３０と、ポリシ配信装置２４０とで構成されている。

NW情報取得装置２１０は、管理NWや拠点４０内部のネットワークの情報を取得する。サービス情報取得装置２２０は、サービスの情報等を取得する。SRv6ポリシ作成装置２３０は、ネットワーク情報やサービス情報等に基づいて、端末１０毎の経路を作成する。ポリシ配信装置２４０は、NW装置３０に対して経路を設定する。

≪NW情報取得装置２１０の機能構成≫
本実施形態に係るNW情報取得装置２１０の機能構成について、図１３を参照しながら説明する。図１３は、NW情報取得装置２１０の機能構成の一例を説明するための図である。

図１３に示すように、本実施形態に係るNW情報取得装置２１０は、機能部として、通信部２１１と、情報管理部２１２と、リンクステート情報演算部２１３とを有する。これらは、例えば、プロセッサ等が実行する処理により実現される。

また、本実施形態に係るNW情報取得装置２１０は、リンクステート情報テーブル３１１と、経路情報テーブル３１２と、DC情報テーブル３１３と、送信情報テーブル３１４とを有する。これらは、記憶装置等に記憶されている。

通信部２１１は、NW装置３０やSRv6ポリシ作成装置２３０等と通信を行う。情報管理部２１２は、各種テーブルを管理する。リンクステート情報演算部２１３は、例えばSIDをキーにしたソート等の演算を行う。

本実施形態に係るNW情報取得装置２１０は、通信部２１１により、BGP-LS等のプロトコルを用いて、管理NWにおけるルータ等のNW装置３０から、IGP（Interior Gateway Protocol）のリンクステート情報やBGP、IPの経路情報を取得する。リンクステート情報は、リンクステート情報演算部２１３によりSIDをキーにしたソート等の演算を行った後、情報管理部２１２によりリンクステート情報テーブル３１１に格納される。また、経路情報は、情報管理部２１２により経路情報テーブル３１２に格納される。

DC情報テーブル３１３には、DC情報が格納されている。DC情報は、例えば、拠点４０（データセンタ）が接続されているAS（Autonomous System）の情報や、データセンタに対して管理NW側のゲートウェイとなるルータのSIDの情報等である。

また、本実施形態に係るNW情報取得装置２１０は、情報管理部２１２により、送信情報テーブル３１４に格納されている送信情報を参照して、リンクステート情報や経路情報、DC情報をSRv6ポリシ作成装置２３０に送信する範囲（データの範囲）を決定する。そして、本実施形態に係るNW情報取得装置２１０は、通信部２１１により、決定された範囲のリンクステート情報や経路情報、DC情報をSRv6ポリシ作成装置２３０に送信する。なお、このとき、毎回全ての情報がSRv6ポリシ作成装置２３０に送信されてもよいし、前回送信された情報との差分のみがSRv6ポリシ作成装置２３０に送信されてもよい。

ここで、リンクステート情報テーブル３１１の一例を図１４に示す。図１４に示すように、リンクステート情報テーブル３１１に格納されている各リンクステート情報には、SIDと、SID属性と、State情報とが含まれる。なお、リンクステート情報テーブル３１１には、BGP-LS等でNW装置３０から取得したリンクステート情報が、SIDをキーにしたソート等の演算が行われた上で格納されている。

次に、経路情報テーブル３１２の一例を図１５に示す。図１５に示すように、経路情報テーブル３１２に格納されている各経路情報には、Prefixと、Router-ID/Originatorと、前回送信時の情報と、前回送信時からの差分とが含まれる。すなわち、経路情報は、BGPテーブルに格納されている情報やIPルートテーブルに格納されている情報である。また、経路情報では、前回送信時からの差分有無と、差分がある場合には前回送信した情報とが含まれる。

次に、DC情報テーブル３１３の一例を図１６に示す。図１６に示すように、DC情報テーブル３１３に格納されている各DC情報には、接続先ASと、SIDとが含まれる。すなわち、DC情報には、各拠点４０（データセンタ）がどのAS（サブAS）に接続されているかという情報と、データセンタに対して管理NW側のゲートウェイとなるルータのSIDとが含まれる。これらの情報は、SRv6を用いて特定の拠点４０（データセンタ）へパケットの引き込みを行う際に、その入り口となるルータを指定した経路を設定する場合に用いられる。

次に、送信情報テーブル３１４の一例を図１７に示す。図１７に示すように、送信情報テーブル３１４に格納されている各送信情報には、項目と、設定値とが含まれる。項目としてはデータ送信間隔や送信データ範囲があり、設定値には当該項目に対する設定値が格納される。なお、データ送信間隔の設定値には、例えば、「30秒」や「60秒」等のデータ送信間隔が設定される。また、送信データ範囲には、例えば、「全データ送信」や「差分があるデータのみ送信」、「特定エリアのデータのみ送信」等が設定される。

≪サービス情報取得装置２２０の機能構成≫
本実施形態に係るサービス情報取得装置２２０の機能構成について、図１８を参照しながら説明する。図１８は、サービス情報取得装置２２０の機能構成の一例を説明するための図である。

図１８に示すように、本実施形態に係るサービス情報取得装置２２０は、機能部として、通信部２２１と、情報管理部２２２とを有する。これらは、例えば、プロセッサ等が実行する処理により実現される。

また、本実施形態に係るサービス情報取得装置２２０は、SFC情報テーブル３２１と、リソース情報テーブル３２２と、抽象化SID情報テーブル３２３と、サービス要求情報テーブル３２４とを有する。これらは、記憶装置等に記憶されている。

通信部２２１は、SRv6ポリシ作成装置２３０やクラウドオーケストレータ７０、端末１０等と通信を行う。情報管理部２２２は、各種テーブルを管理する。

本実施形態に係るサービス情報取得装置２２０は、通信部２１１により、サービス事業者やエンドユーザが持つ情報をクラウドオーケストレータ７０や端末１０等から取得する（又は、クラウドオーケストレータ７０や端末１０等から送信若しくは通知された情報を受信する。）。

SFC情報テーブル３２１には、SFC情報が格納されている。SFC情報は、サービスのエンドユーザが要求するサービスファンクションチェイニングの情報のことである。

リソース情報テーブル３２２には、リソース情報が格納されている。リソース情報テーブルは、拠点４０で提供されるサービスの余剰リソース量の情報である。

抽象化SID情報テーブル３２３は、抽象化SID情報が格納されている。抽象化SID情報は、サービスの抽象化SIDである。すなわち、本実施形態では、抽象化SIDの割当範囲はサービス毎であるものとしている。

サービス要求情報テーブル３２４は、サービス要求情報が格納されている。サービス要求情報は、サービスの許容遅延時間やリソース負荷分散等に関する情報である。

ここで、SFC情報テーブル３２１の一例を図１９に示す。図１９に示すように、SFC情報テーブル３２１に格納されている各SFC情報には、ユーザのSAと、このユーザのサービスファンクションチェイニングの情報とが含まれる。ここで、SFC[i]はi番目のサービスファンクションチェイニングの情報を表す。なお、同じサービスファンクションが複数の拠点４０に配置（デプロイ）されている場合、SRv6ポリシ作成装置２３０は、SFC情報と、後述するリソース情報とに基づいて、余剰リソース量を考慮しつつ、どの拠点４０のサービスファンクションを利用するかを決定し、SRv6ポリシを作成する。

次に、抽象化SID情報テーブル３２３の一例を図２０に示す。図２０に示すように、抽象化SID情報テーブル３２３に格納されている各抽象化SID情報には、サービスと、このサービスに割り当てられた抽象化SIDとが含まれる。なお、SRv6ポリシ作成装置２３０の出力として得られるSRHは、抽象化SIDと、NW情報取得装置２１０で保持される、NW装置３０に付属するSIDとでエンコードされる。ここで、本実施形態では、サービス単位で抽象化SIDを割り当てたが、どうような範囲を抽象化SIDの割当範囲とするかは任意に決定されてよい。

次に、リソース情報テーブル３２２の一例を図２１に示す。図２１に示すように、リソース情報テーブル３２２に格納されている各リソース情報には、拠点４０の識別子であるDC識別子と、この拠点４０で提供されるサービスのサービス名と、このサービスを提供するための余剰リソース量とが含まれる。すなわち、リソース情報は、拠点４０及びサービス毎の余剰リソース量である。SRv6ポリシ作成装置２３０が、これらの情報を基にSRv6ポリシを作成することで、SFインスタンス側のリソース不足に起因する通信遅延やパケットロス等を回避することが可能となる。

次に、サービス要求情報テーブル３２４の一例を図２２に示す。図２２に示すように、サービス要求情報テーブル３２４に格納されている各サービス要求情報には、エンドユーザ（又はサービス事業者）による要求（例えば、サービスの許容遅延時間等）が格納される。

≪SRv6ポリシ作成装置２３０の機能構成≫
本実施形態に係るSRv6ポリシ作成装置２３０の機能構成について、図２３を参照しながら説明する。図２３は、SRv6ポリシ作成装置２３０の機能構成の一例を説明するための図である。

図２３に示すように、本実施形態に係るSRv6ポリシ作成装置２３０は、機能部として、通信部２３１と、ポリシ作成部２３２とを有する。これらは、例えば、プロセッサ等が実行する処理により実現される。

通信部２３１は、NW情報取得装置２１０やサービス情報取得装置２２０から所定の間隔で情報を受信する。また、通信部２３１は、ポリシ作成部２３２で作成されたSRv6ポリシをポリシ配信装置２４０に送信する。

ポリシ作成部２３２は、NW情報取得装置２１０やサービス情報取得装置２２０から受信した情報に基づいて、SRv6ポリシを作成する。SRv6ポリシには、少なくとも１つ以上のSRv6候補経路が割り当てられており、この経路は抽象化SIDやNW装置３０に対応するSIDでエンコードされる。また、SRv6ポリシには、NW装置３０がパケットを受信した場合の処理を指定することもできる。

≪ポリシ配信装置２４０の機能構成≫
本実施形態に係るポリシ配信装置２４０の機能構成について、図２４を参照しながら説明する。図２４は、ポリシ配信装置２４０の機能構成の一例を説明するための図である。

図２４に示すように、本実施形態に係るポリシ配信装置２４０は、機能部として、通信部２４１と、情報管理部２４２とを有する。これらは、例えば、プロセッサ等が実行する処理により実現される。

また、本実施形態に係るポリシ配信装置２４０は、ポリシ情報管理テーブル３４１を有する。このテーブルは、記憶装置等に記憶されている。

通信部２４１は、SRv6ポリシ作成装置２３０からSRv6ポリシを受信する。また、通信部２４１は、NW装置３０にSRv6ポリシを配信（送信）する。このとき、通信部２４１は、PCEP等のプロトコルを用いて、SRv6ポリシを送信する。

情報管理部２４２は、SRv6ポリシ作成装置２３０から受信したSRv6ポリシの情報（ポリシ情報）をポリシ情報管理テーブル３４１に格納する。

ここで、ポリシ情報管理テーブル３４１の一例を図２５に示す。図２５に示すように、ポリシ情報には、ポリシ名と、配信先と、適用条件と、Functionと、SID-Listとが含まれる。ここで、配信先は、SRv6ポリシの配信先となるNW装置３０の識別子である。また、SID-ListはSRv6経路の情報である。適用条件はSRv6ポリシの適用条件であり、FunctionはどのようなFunctionを実施するかの情報である。

≪ルーティングヘッダ変換装置５０の機能構成≫
本実施形態に係るルーティングヘッダ変換装置５０の機能構成について、図２６を参照しながら説明する。図２６は、ルーティングヘッダ変換装置５０の機能構成の一例を説明するための図である。

図２６に示すように、本実施形態に係るルーティングヘッダ変換装置５０は、機能部として、通信部５０１と、情報管理部５０２と、パケットバッファ部５０３と、変換処理部５０４とを有する。これらは、例えば、プロセッサ等が実行する処理により実現される。

また、本実施形態に係るルーティングヘッダ変換装置５０は、変換テーブル５１１を有する。このテーブルは、記憶装置等に記憶されている。

通信部５０１は、拠点４０（データセンタ）内のNW装置（例えば、ルータ等）との間でパケットを送受信する。また、通信部５０１は、クラウドオーケストレータ７０との間で各種情報を送受信する。

情報管理部５０２は、クラウドオーケストレータ７０からの情報（例えば、SAとDAと変換後のDAとの対応関係を表す情報）を変換テーブル５１１に格納する。

パケットバッファ部５０３は、拠点４０内のNW装置からのパケットをバッファする。変換処理部５０４は、変換テーブル５１１を参照して、パケットのヘッダのパラメータ（DA等）を変換する。なお、変換テーブル５１１の一例は、図９に示した通りである。

＜抽象化SIDの払い出し及び事業者間の情報共有時のシーケンス＞
以降では、本実施形態に係る通信システム１において、抽象化SIDの払い出しと、キャリア事業者及びサービス事業者の間での情報共有とを行う場合のシーケンスについて、図２７を参照しながら説明する。図２７は、抽象化SIDの払い出し及び事業者間の情報共有を行う場合の一例を説明するためのシーケンス図である。なお、本実施形態では、クラスタNWとして、「クラスタNW1」と「クラスタNW2」とを想定し、クラスタNW1のクラウドオーケストレータ７０を「クラウドオーケストレータ７０－１」、クラスタNW2のクラウドオーケストレータ７０を「クラウドオーケストレータ７０－２」とする。また、クラスタNW1に属するコンテナ３１０を「コンテナ３１０－１」、クラスタNW2に属するコンテナ３１０を「コンテナ３１０－２」と表す。

Ｓ１０１－１～Ｓ１０３－２までがコンテナ（SFインスタンス）起動時のシーケンス、Ｓ２０１－１～Ｓ２０３－２までが抽象化SID払い出し時のシーケンス、Ｓ３０１～Ｓ３０３までがキャリア事業者及びサービス事業者の間での情報共有と経路設定のシーケンスである。なお、以降の図２７～図３０では、実線矢印はD-Paneを表し、破線矢印はC-Plane（又はその他の通信）を表す。

クラウドオーケストレータ７０－１は、クラスタNW1に属するコンテナ３１０－１を起動させる（Ｓ１０１－１）。同様に、クラウドオーケストレータ７０－２は、クラスタNW2に属するコンテナ３１０－２を起動させる（Ｓ１０１－２）。

クラスタNW1内の仮想NW装置（つまり、クラスタNW1でルーティングを行う物理ホスト６０上の機能）は、コンテナ３１０－１にアドレス（又はSID）を割り当てる（Ｓ１０２－１）。同様に、クラスタNW2内の仮想NW装置は、コンテナ３１０－２にアドレス（又はSID）を割り当てる（Ｓ１０２－２）。

そして、クラスタNW1内の仮想NW装置と、クラスタNW2内の仮想NW装置とは、拠点４０内にコンテナ３１０のアドレスを（又はSID）を広告する（ステップＳ１０３－１及びＳ１０３－２）。上述したように、この広告範囲は、ルーティング方式1～ルーティング方式3によって異なる。

次に、クラウドオーケストレータ７０－１及びクラウドオーケストレータ７０－２は、予め決められた割当範囲の抽象化SIDを払い出す（Ｓ２０１－１及びＳ２０１－２）。次に、クラウドオーケストレータ７０－１及びクラウドオーケストレータ７０－２は、払い出した抽象化SIDを経路制御装置２０に通知する（Ｓ２０２－１及びＳ２０２－２）。

また、クラスタNW1内の仮想NW装置と、クラスタNW2内の仮想NW装置とは、抽象化SIDを広告する（Ｓ２０３－１及びＳ２０３－２）。上述したように、この広告範囲は、ルーティング方式1～ルーティング方式3によって異なる。

続いて、端末１０は、経路制御装置２０に対して。サービスの利用申請を送信する（Ｓ３０１）。この利用申請には、上述したように、SA、DA、サービス名及び順序が含まれる。なお、これら以外にも、例えば、サービス要求情報が含まれていてもよい。

以降では、上記の利用申請には、サービス名として、コンテナ３１０－１が提供するサービスのサービス名と、コンテナ３１０－２が提供するサービスのサービス名とが含まれているものとする。

経路制御装置２０は、クラウドオーケストレータ７０－１及びクラウドオーケストレータ７０－２に対して、利用情報（すなわち、SAとDAとのペア）を通知する（Ｓ３０２－１及びＳ３０２－２）。そして、経路制御装置２０は、上記の利用申請に係るサービスを提供するための経路制御を実現するSRv6ポリシをNW装置３０に設定する（Ｓ３０３）
＜パケットフォワーディング及びルーティングヘッダ変換時のシーケンス＞
次に、パケットフォワーディング及びルーティングヘッダ変換時のシーケンスについて説明する。上述したように、ルーティング方式としては、ルーティング方式1-a～ルーティング方式3が考えられる。以降では、ルーティング方式1-b、ルーティング方式2、及びルーティング方式3をそれぞれ用いた場合におけるパケットフォワーディング及びルーティングヘッダ変換時のシーケンスについて説明する。なお、以降では、一例として、コンテナ３１０－１が提供するサービス（SF1）と、コンテナ３１０－２が提供するサービス（SF2）とを順に利用して、端末１０がサーバとの間でE2E通信を行う場合について説明する。

≪ルーティング方式1-b≫
以降では、ルーティング方式1-bを用いた場合におけるパケットフォワーディング及びルーティングヘッダ変換時のシーケンスについて、図２８を参照しながら説明する。図２８は、ルーティング方式1-bにおけるパケットフォワーディング及びルーティングヘッダ変換の一例を説明するためのシーケンス図である。本方式の特徴としては、単一のルーティングヘッダ変換装置５０が複数のサービス（クラスタNW）を収容している。

端末１０は、NW装置３０（例えば、管理NWのエッジルータ等）にパケットを送信する（Ｓ４０１）。このパケットのヘッダには、SA「端末１０のアドレス（又はSID）」、DA「サーバのアドレス（又はSID）」が設定されているものとする。この時点では、SRHは存在しない。

NW装置３０は、T.Insertを実施して、パケットに対してSRHを追加して、DAを変更する（Ｓ４０２）。これにより、SA「端末１０のアドレス（又はSID）」、DA「SF1の抽象化SID」、SRH「SF1の抽象化SID, SF2の抽象化SID, サーバのアドレス（又はSID）」となる。なお、上述したように、本実施形態では、サービス単位（つまり、このサービスを提供するSFインスタンスで構成されるクラスタNW単位）で抽象化SIDを割り当てている。

そして、NW装置３０は、DA（又は、SRHにエンコードされたSID）に従って当該パケットを送信（ルーティング）する（Ｓ４０３）。これにより、当該パケットが、拠点４０のルーティングヘッダ変換装置５０にルーティングされる。

ルーティングヘッダ変換装置５０は、変換方式1又は変換方式2により、抽象化SIDをコンテナ３１０のSID（又はアドレス）に変換する（Ｓ４０４）。変換方式1の場合は、DA「コンテナ３１０－１のSID（又はアドレス）」、SRH「SF1の抽象化SID, SF2の抽象化SID, サーバのアドレス（又はSID）」となる。

そして、ルーティングヘッダ変換装置５０は、DAに従って当該パケットを送信（ルーティング）する（Ｓ４０５）。これにより、当該パケットが、コンテナ３１０－１までルーティングされる。

コンテナ３１０－１は、当該パケットを受信すると、SFの処理を行い、DAをSF2の抽象化SIDに変更する（Ｓ４０６）。なお、コンテナ３１０－１は、Endを実施することで、DAをSF2の抽象化SIDに変更することができる。

これにより、当該パケットがルーティングヘッダ変換装置５０にルーティングされる（Ｓ４０７）。

ルーティングヘッダ変換装置５０は、変換方式1又は変換方式2により、抽象化SIDをコンテナ３１０のSID（又はアドレス）に変換する（Ｓ４０８）。変換方式1の場合は、DA「コンテナ３１０－２のSID（又はアドレス）」、SRH「SF2の抽象化SID, サーバのアドレス（又はSID）」となる。

これにより、当該パケットがコンテナ３１０－２にルーティングされる（Ｓ４０９）。

以降、同様に、コンテナ３１０－２は、当該パケットを受信すると、SFの処理を行い、DAをサーバのアドレス（又はSID）に変更する（Ｓ４１０）。これにより、当該パケットがサーバまでルーティングされる（Ｓ４１１）。

≪ルーティング方式2≫
以降では、ルーティング方式2を用いた場合におけるパケットフォワーディング及びルーティングヘッダ変換時のシーケンスについて、図２９を参照しながら説明する。図２９は、ルーティング方式2におけるパケットフォワーディング及びルーティングヘッダ変換の一例を説明するためのシーケンス図である。本方式の特徴としては、サービス（クラスタNW）単位で存在するルーティングヘッダ変換装置５０が、単一のサービス（クラスタNW）が払い出す抽象化SIDを各SFインスタンスの識別子（アドレス／SID）に変換する。

なお、ルーティング方式2では、クラスタNW毎にGW用ポッドが存在し、これらのGW用ポッドが拠点GWクラスタを構成している。このため、図２９では、クラスタNW1のGW用ポッドを「ルーティングヘッダ変換装置５０－１」、クラスタNW2のGW用ポッドを「ルーティングヘッダ変換装置５０－２」と表す。

端末１０は、NW装置３０（例えば、管理NWのエッジルータ等）にパケットを送信する（Ｓ５０１）。このパケットのヘッダには、SA「端末１０のアドレス（又はSID）」、DA「サーバのアドレス（又はSID）」が設定されているものとする。この時点では、SRHは存在しない。

NW装置３０は、T.Insert又はEnd.B6.Encapsを実施して、パケットに対してSRHを追加して、DAを変更する（Ｓ５０２）。これにより、SA「端末１０のアドレス（又はSID）」、DA「SF1の抽象化SID」、SRH「SF1の抽象化SID, SF2の抽象化SID, サーバ」となる。なお、上述したように、本実施形態では、サービス単位（つまり、このサービスを提供するSFインスタンスで構成されるクラスタNW単位）で抽象化SIDを割り当てている。

そして、NW装置３０は、DA（又は、SRHにエンコードされたSID）に従って当該パケットを送信（ルーティング）する（Ｓ５０３）。これにより、当該パケットが、拠点４０のルーティングヘッダ変換装置５０－１にルーティングされる。

ルーティングヘッダ変換装置５０－１は、変換方式1又は変換方式2により、抽象化SIDをコンテナ３１０のSID（又はアドレス）に変換する（Ｓ５０４）。変換方式1の場合は、DA「コンテナ３１０－１のSID（又はアドレス）」、SRH「SF1の抽象化SID, SF2の抽象化SID, サーバのアドレス（又はSID）」となる。

そして、ルーティングヘッダ変換装置５０－１は、DAに従って当該パケットを送信（ルーティング）する（Ｓ５０５）。これにより、当該パケットが、コンテナ３１０－１までルーティングされる。

コンテナ３１０－１は、当該パケットを受信すると、SFの処理を行い、DAをSF2の抽象化IDに変更する（Ｓ５０６）。なお、コンテナ３１０－１は、Endを実施することで、DAをSF2の抽象化SIDに変更することができる。

これにより、当該パケットがルーティングヘッダ変換装置５０－２にルーティングされる（Ｓ５０７）。

以降、同様に、ルーティングヘッダ変換装置５０－２は、変換方式1又は変換方式2により、抽象化SIDをコンテナ３１０－２のSID（又はアドレス）に変換する（Ｓ５０８）。変換方式1の場合は、DA「コンテナ３１０－２のSID（又はアドレス）」、SRH「SF2の抽象化SID, サーバのアドレス（又はSID）」となる。

そして、ルーティングヘッダ変換装置５０－２は、DAに従って当該パケットを送信（ルーティング）する（Ｓ５０９）。これにより、当該パケットが、コンテナ３１０－２までルーティングされる。

コンテナ３１０－２は、当該パケットを受信すると、SFの処理を行い、DAをサーバのアドレス（又はSID）に変更する（Ｓ５１０）。これにより、当該パケットがサーバにルーティングされる（Ｓ５１１）。

≪ルーティング方式3≫
以降では、ルーティング方式3を用いた場合におけるパケットフォワーディング及びルーティングヘッダ変換時のシーケンスについて、図３０を参照しながら説明する。図３０は、ルーティング方式3におけるパケットフォワーディング及びルーティングヘッダ変換の一例を説明するためのシーケンス図である。本方式の特徴としては、サービス（クラスタNW）毎に存在するルーティングヘッダ変換装置５０が、サービス事業者が払い出した抽象化SIDを各SFインスタンスの識別子（アドレス／SID）に変換する。

なお、ルーティング方式3では、クラスタNW毎に拠点GWポッドが存在する。このため、図３０では、クラスタNW1の拠点GWポッドを「ルーティングヘッダ変換装置５０－１」、クラスタNW2の拠点GWポッドを「ルーティングヘッダ変換装置５０－２」と表す。

端末１０は、NW装置３０（例えば、管理NWのエッジルータ等）にパケットを送信する（Ｓ６０１）。このパケットのヘッダには、SA「端末１０のアドレス（又はSID）」、DA「サーバのアドレス（又はSID）」が設定されているものとする。この時点では、SRHは存在しない。

NW装置３０は、T.Insert又はEnd.B6.Encapsを実施して、パケットに対してSRHを追加して、DAを変更する（Ｓ６０２）。これにより、SA「端末１０のアドレス（又はSID）」、DA「SF1の抽象化SID」、SRH「SF1の抽象化SID, SF2の抽象化SID, サーバ」となる。なお、上述したように、本実施形態では、サービス単位（つまり、このサービスを提供するSFインスタンスで構成されるクラスタNW単位）で抽象化SIDを割り当てている。

そして、NW装置３０は、DA（又は、SRHにエンコードされたSID）に従って当該パケットを送信（ルーティング）する（Ｓ６０３）。これにより、当該パケットが、拠点４０のルーティングヘッダ変換装置５０－１にルーティングされる。

ルーティングヘッダ変換装置５０－１は、変換方式1又は変換方式2により、抽象化SIDをコンテナ３１０のSID（又はアドレス）に変換する（Ｓ６０４）。変換方式1の場合は、DA「コンテナ３１０－１のSID（又はアドレス）」、SRH「SF1の抽象化SID, SF2の抽象化SID, サーバのアドレス（又はSID）」となる。

そして、ルーティングヘッダ変換装置５０－１は、DAに従って当該パケットを送信（ルーティング）する（Ｓ６０５）。これにより、当該パケットが、コンテナ３１０－１までルーティングされる。

コンテナ３１０－１は、当該パケットを受信すると、SFの処理を行い、DAをSF2の抽象化IDに変更する（Ｓ６０６）。なお、コンテナ３１０－１は、Endを実施することで、DAをSF2の抽象化SIDに変更することができる。

これにより、当該パケットがルーティングヘッダ変換装置５０－２にルーティングされる（Ｓ６０７）。

以降、同様に、ルーティングヘッダ変換装置５０－２は、変換方式1又は変換方式2により、抽象化SIDをコンテナ３１０－２のSID（又はアドレス）に変換する（Ｓ６０８）。変換方式1の場合は、DA「コンテナ３１０－２のSID（又はアドレス）」、SRH「SF2の抽象化SID, サーバのアドレス（又はSID）」となる。

そして、ルーティングヘッダ変換装置５０－２は、DAに従って当該パケットを送信（ルーティング）する（Ｓ６０９）。これにより、当該パケットが、コンテナ３１０－２までルーティングされる。

コンテナ３１０－２は、当該パケットを受信すると、SFの処理を行い、DAをサーバのアドレス（又はSID）に変更する（Ｓ６１０）。これにより、当該パケットがサーバにルーティングされる（Ｓ６１１）。

＜ハードウェア構成＞
最後に、本実施形態に係る通信システム１に含まれる各種機器又は装置（例えば、端末１０や経路制御装置２０、ルーティングヘッダ変換装置５０、物理ホスト６０等）を実現するコンピュータ１０００のハードウェア構成について説明する。図３１は、コンピュータ１０００のハードウェア構成の一例を説明するための図である。本実施形態に係る通信システム１に含まれる各種機器又は装置は、例えば、図３１に示すコンピュータ１０００を１台以上用いて実現することが可能である。

図３１に示すコンピュータ１０００は、ハードウェアとして、入力装置１００１と、表示装置１００２と、外部Ｉ／Ｆ１００３と、通信Ｉ／Ｆ１００４と、プロセッサ１００５と、メモリ装置１００６とを有する。これら各ハードウェアは、それぞれがバスＢを介して通信可能に接続されている。

入力装置１００１は、例えばキーボードやマウス、タッチパネル等である。表示装置１００２は、例えばディスプレイ等である。なお、コンピュータ１０００は、入力装置１００１及び表示装置１００２の少なくとも一方を有していなくてもよい。

外部Ｉ／Ｆ１００３は、外部装置とのインタフェースである。外部装置には、各種の外部記録媒体である記録媒体１００３ａ等がある。

通信Ｉ／Ｆ１００４は、コンピュータ１０００を通信ネットワークに接続するためのインタフェースである。プロセッサ１００５は、例えばCPU（Central Processing Unit）等の演算装置である。メモリ装置１００６は、RAM（Random Access Memory）や補助記憶装置等の記憶装置である。

なお、コンピュータ１０００は、ハードウェアとして、複数のプロセッサ１００５や複数のメモリ装置１００６を有していてもよい。

本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

１通信システム
１０端末
２０経路制御装置
３０ NW装置
４０拠点
５０ルーティングヘッダ変換装置
６０物理ホスト
７０クラウドオーケストレータ
２１０ NW情報取得装置
２２０サービス情報取得装置
２３０ SRv6ポリシ作成装置
２４０ポリシ配信装置

Claims

通信装置間で１以上のサービス機能を経由したEnd-to-End通信をSegment Routing IPv6により実現する通信システムであって、
予め決められた所定の範囲内のSegmentIDを抽象化した抽象化IDを用いて、前記End-to-End通信の通信元の通信装置からのパケットを転送する転送手段と、
前記抽象化IDが含まれるパケットを受信した場合、前記抽象化IDを、前記サービス機能を提供するサービス機能インスタンスのアドレス又はSegmentIDに変換する変換手段と、
を有することを特徴とする通信システム。
前記変換手段は、
前記通信元の通信装置の送信元アドレスと、抽象化IDと、ネットワークアドレス変換機能により該抽象化IDを変換した変換後のSegmentIDとを対応付けた変換テーブルを用いて、抽象化IDを、サービス機能インスタンスのアドレス又はSegmentIDに変換する、
又は、予め設定されたSegment Routing IPv6ポリシに基づいて、前記パケットに対してEnd.B6.Encaps処理を行うことで、抽象化IDを、サービス機能インスタンスのアドレス又はSegmentIDに変換する、ことを特徴とする請求項１に記載の通信システム。
前記抽象化IDは、
同一サービスを提供するサービス機能インスタンスの集合毎、同一クラスタネットワークに属するサービス機能インスタンスの集合毎、又は同一拠点に設置された物理ホスト上のサービス機能インスタンスの集合毎に割り当てられる、ことを特徴とする請求項１又は２に記載の通信システム。
前記変換手段により変換されたアドレス又はSegmentIDを用いて、前記サービス機能インスタンスに前記パケットを送信する送信手段を有する、ことを特徴とする請求項１乃至３の何れか一項に記載の通信システム。
前記通信システムは、
前記サービス機能インスタンスを実現する１以上の物理ホストが設置された拠点毎に前記変換手段を有する、ことを特徴とする請求項１乃至４の何れか一項に記載の通信システム。
前記通信システムは、
前記サービス機能インスタンスが属するクラスタネットワーク毎に前記変換手段を有する、ことを特徴とする請求項１乃至４の何れか一項に記載の通信システム。
前記通信システムは、
前記クラスタネットワーク毎に、前記サービス機能インスタンスと同一自律システムに属するポッド又は前記サービス機能インスタンスと異なる自律システムに属するポッドのいずれかとして前記変換手段を有する、ことを特徴とする請求項６に記載の通信システム。
通信装置間で１以上のサービス機能を経由したEnd-to-End通信をSegment Routing IPv6により実現する通信システムに用いられる通信方法であって、
予め決められた所定の範囲内のSegmentIDを抽象化した抽象化IDを用いて、前記End-to-End通信の通信元の通信装置からのパケットを転送する転送手順と、
前記抽象化IDが含まれるパケットを受信した場合、前記抽象化IDを、前記サービス機能を提供するサービス機能インスタンスのアドレス又はSegmentIDに変換する変換手順と、
を有することを特徴とする通信方法。