JP5788294B2 - ネットワークシステムの管理方法 - Google Patents

Description

本発明は、ネットワークに関係し、特に、複数のドメインにまたがるネットワークに関係する。

ネットワークには、異なるネットワーク管理サーバによって管理されるドメインや、ひとつのポリシーにしたがって制御されるドメイン(たとえばインターネットにおけるAutonomous System(AS))がある。このような複数のドメイン間にまたがるネットワーク・サービス(以下ドメイン間サービスと呼ぶ)を展開しようとするとき、両者がもつシステム・モデルを対応づけ、そのモデルにしたがう制御管理情報を相互に変換することによって、複数のドメイン全体への設定・制御・管理をおこなうことができれば、それができない場合にくらべて設定・制御・管理ははるかに容易におこなうことができると考えられる。

ドメイン間サービスを実現するには制御管理情報をドメイン間でやりとりする必要があるが、そのための方法として、上記のようにネットワーク管理サーバのような少数の機構を使用して管理する集中管理法と、ドメイン内に分散された通常のノードあるいは制御ノード間で制御メッセージをやりとりして制御する分散制御法とがある。
（集中管理における連携）
このうち、集中管理法によるドメイン間サービスの設定・管理法に関しては、比較的ゆるい集中制御法を仮想ネットワーク(以下、スライスと呼ぶ)に対して適用した例として特許文献１がある。特許文献１においてはネットワーク管理サーバ(clearing house、aggregate manager)はスライスの識別子発行と認証・認可だけを行い、認可されたユーザ(サービス・プロバイダ)はネットワーク管理サーバから獲得したアクセス・キーを使用して直接、各ドメインの資源に関する設定や管理操作を行う。特許文献１において各ネットワーク管理サーバは、その管理区域内に閉じた資源だけを扱い、ネットワーク・リンク資源(仮想リンク資源)のように、複数の区域あるいは複数の管理ドメインに跨る資源を扱わない。

また、より集中化がすすんだ形態の集中管理法をとる例として非特許文献１がある。非特許文献１においては、ドメイン・コントローラ(ネットワーク管理サーバ)がスライスすなわち仮想ネットワークを物理ネットワーク上に生成する機能をもつ。すなわち、ドメイン・コントローラはスライスの構成すなわちスライスがふくむノードスリバー(仮想ノード)、リンクスリバー(仮想リンク)およびノードスリバーとリンクスリバーの結合情報をふくむスライス定義をスライスの開発者からうけとり、スライス定義を仮想化ノード(物理ネットワーク・ノード)に配布する。各仮想化ノードはスライス定義にしたがってノードスリバーおよびリンクスリバーに必要な資源をわりあてる。
（分散制御における連携）
一方、分散制御法によるドメイン間サービスの設定・管理法の例として非特許文献２がある。非特許文献２においては、Private Network-Network Interface(PNNI)を使用することによって、複数の物理ノードを含むピアグループ（ドメイン)を代表ノードとして扱うことによって、ルーティング情報(制御情報)を簡素化し、スケーラブルにルーティング(制御)することができるネットワークを構成することを可能にしている。非特許文献２においては複数のピアグループを含むピアグループを階層的に構成することによって、さらなるスケーラビリティを実現することを可能にしている。
（スケーラビリティ）
多くの集中管理法によるドメインにおいては、特許文献１のようにネットワーク管理サーバがアクセス権限だけを管理するのでなく、資源の内容や量をネットワーク管理サーバが直接管理しているため、資源へのアクセスを常にネットワーク管理サーバ経由でおこなう必要がある。このようなドメインにおいて他のドメインにまたがる統一的な設定・管理を実現するには、ネットワーク管理サーバが自ドメインの管理情報と他ドメインの管理情報を区別し、ドメイン内へのメッセージとドメイン外のメッセージとでことなる形式を使用する必要がある。また、このような区別をおこなうことによって、管理可能なネットワーク規模に関するスケーラビリティを確保している。

この点は分散制御法における制御ノード間の制御情報のやりとりに関しても同様である。たとえばインターネットにおいてはドメイン(Autonomous System、AS)内のルーティングにはRouting Information Protocol(RIP)、Open Shortest Path First(OSPF)などのInterior Gateway Protocol(IGP)を使用し、ドメイン間のルーティングにはBorder Gateway Protocol(BGP)などのExterior Gateway Protocol(EGP)を使用する。また、ATMにおいてはどの階層のピアグループに対してもPNNIを使用するが、ピアグループ内へのメッセージにはピアグループ内のデータベース情報を包含し、ピアグループ外へのピアグループ内のデータベース情報を包含しないという相違がある。すなわち、インターネットにおいてはドメイン内外でIGPとEGPとをつかいわけることによってスケーラビリティを確保している。一方、ATMにおいてはピアグループ内にはネットワーク・トポロジーなどに関するデータベース情報を送信するが、ピアグループ外にはそれを送信しないようにすることによって、スケーラビリティを確保している。非特許文献３においてはEGPを適用する各ドメインがすべてインターネット・プロトコルを使用するネットワークであることが前提となり、また非特許文献２においてはすべてのピアグループがATMおよびPNNIを使用することが前提となっている。
（イベント・ベースの連携)
非特許文献３は複数ドメイン間の連携をイベント・ベースでおこなう方法を記述している。この方法は各ドメインの要素(管理サーバ)がイベント・ベースで、たとえばイベント通知、イベント通知予約などのAPIにしたがって動作することが前提とされている。この方法においては連携機能の追加は複数ドメイン間をむすぶシステム・フェデレータを追加して、各ドメインで特定のイベントが発生したときにシステム・フェデレータにイベント通知するように予約するとともに、システム・フェデレータがイベント通知をうけたときにとるべき動作を規則として記述する。この方法は各ドメインがイベント・ベースの動作機構をもたないときには適用できない。

米国特許 US 2011 0149968、“Method for Controlling Internet Network”

金田 泰、中尾 彰宏、"仮想化ノードを使用した非IPプロトコル開発法と経験"、電子情報通信学会IA研究会、2010-12、2章、3.2節、4.1節および4.2節 Private Network-Network Interface Specification Version 1.0 (PNNI 1.0)、 af-pnni-0055.000、ATM Forum、March 1996、p.13〜p.38. J. Bates、J. Bacon、K. Moody、and M. Spiteri、"Using events for the scalable federation of heterogeneous components"、Proceedings of the 8th ACM SIGOPS European workshop on Support for composing distributed applications、pp.58-65、1998.

ドメイン間サービスを従来技術によって実現しようとするとき、接続されるすべてのドメインが同一の管理方式や同一の制御方式によって制御・管理されているときは、ドメイン間サービスのための機構を予め用意しておくことができ、また予め用意されていないとしても、１種類の機構を用意すればよいだけであるから、その組み込みは比較的容易である。たとえば、分散制御法を使用する場合、現在のグローバル・ネットワークにおいてはインターネット・プロトコルを使用することが前提となっているため、EGPによって実現可能である。前記のPNNIにおいても、すべてのピアグループにおいて同一の制御方式を使用することが前提とされている。しかし、今後、新世代のプロトコルに基づくネットワークが使用され、異なる制御・管理方式をとるドメイン間のサービスが必要になったときは、このような方法をとることはできない。

第１に、多種多様なドメイン間のサービスを従来技術によって実現しようとすると、すべてのネットワーク管理サーバ（またはドメイン間管理のためのサーバ）やネットワーク境界の制御ノードに、接続相手のドメインにおけるプロトコルや管理方式ごとにことなる処理をすることができる機能を搭載する必要がある（または、ドメイン間管理のためのサーバにおいて、管理化の各ドメインにおけるプロトコルや管理方式ごとにことなる処理をすることができる機能を搭載する必要がある)。

このような接続相手ごと（管理化のドメインごと）の処理機能にはつぎのような課題がある。（１）このような機能を既存の管理サーバや制御ノードに搭載するにはそれらの管理サーバや制御ノードを改造する必要があり、コストがかさむうえ、改造によってバグが発生しネットワーク障害などの事態をまねく可能性がある。（２）１個の管理サーバや制御ノードが多種のドメインと接続するときは、それらの管理サーバや制御ノードに多種のインターフェース機能を搭載する必要がある。これによって、それぞれの管理サーバや制御ノードが複雑化するとともに、処理負荷が増大する危険がある。

第２に、多種多様なドメイン間のサービスを従来技術によって実現しようとすると、１個のサーバやノードが複数の異種のドメインと接続するときは、自ドメインを含む複数のドメインにまたがる情報、例えば自ドメインと他ドメインの連絡に関する情報やドメイン間にまたがる仮想または実ネットワーク・リンクに関する情報も扱う必要がある。このような複数ドメインにまたがる設定管理情報は、自ドメインだけを管理するように設計・実装されたネットワーク管理サーバを改造しないまま扱うことはできない。そのため、管理サーバや制御ノードの改造が必要になり、それによるコスト増やバグ発生のリスクを負う必要が生じる。

本発明において解決するべき課題は、ドメイン間にまたがるネットワーク・サービスのための設定・管理を、他ドメインも含めて自ドメイン側から設定できるするようにすることである。

上記を解決するために、第１ネットワーク・ドメインと、第２ネットワーク・ドメインと、前記第２ネットワーク・ドメインに関するドメイン設定管理情報を前記第２ネットワーク・ドメインの外部から受信して前記第２ネットワーク・ドメインに属するノードの設定を行う連携システムから構成されるネットワークシステムにおいて、前記第１ネットワーク・ドメインは、複数のノードと、第２ネットワーク・ドメインとの連携のための疑似ノードおよびゲートキーパーと、前記複数のノードと前記疑似ノードとを管理する第１管理ノードを有し、前記第１管理ノードは、前記第１ネットワーク・ドメインに接続されたコンソールから、前記複数のノードのノード設定情報を含む第１ドメイン設定管理情報を受信し、かつ、前記第１ドメイン設定管理情報を前記複数のノードに送信し、前記複数のノードのそれぞれは、前記第１ドメイン設定管理情報に含まれる前記ノード設定情報に従って設定を行い、ここで、前記第１ドメイン設定管理情報は、前記疑似ノードに関する第２ノード設定情報を含んでおり、前記第２ノード設定情報は前記疑似ノードの識別情報を含んでおり、更に、前記第２ノード設定情報は、前記第２ネットワーク・ドメインに関する第２ドメイン設定管理情報を有しており、前記第１管理ノードが、前記疑似ノードに前記第１ドメイン設定管理情報を前記疑似ノードに送信し、前記疑似ノードが、前記第２ノード設定情報を前記ゲートキーパーに送信し、前記ゲートキーパーは前記第２ノード設定情報から前記疑似ノードの識別情報を除外した情報を前記連携システムに送信し、前記連携システムが、前記第２ドメイン設定管理情報を用いて、前記第２ネットワーク・ドメインに属するノードの設定を行うこととする。

ドメイン間に跨るネットワーク・サービスのためのスライスを、自ドメイン側から設定できる。

本実施形態におけるドメインD1、D2、D3をふくむネットワーク全体の構成図である。 ドメインD1、D2にまたがる設定・管理操作をおこなう際のシーケンス図である。 ドメイン内設定管理プログラム２０１の手順を示すフローチャートである。 受信側ドメイン間設定管理プログラム２０２の手順を示すフローチャートである。 本実施形態における管理情報(スライス情報)の内容の説明図である。 本実施形態の補足説明における管理情報(スライス情報)の内容の説明図である。 疑似ノード表７０１の内容を示す図である。 送信側ドメイン間設定管理プログラム２０３の手順を示すフローチャートである。 ドメイン内-ドメイン間のパケット・ヘッダの受信者アドレスの対応を示す対応表である。 スライス情報５０１のXMLによる表現を示す図である。 疑似ノード、ゲートキーパー、および、ゲートウェイの構成を示す図である。 管理メッセージのスライス要求、ノード/リンク要求、ドメイン間依頼要求、ドメイン間依頼、スライス要求、ノード/リンク要求、ドメイン間依頼要求の構造、および管理メッセージが含む付加情報の内容を示す図である。 実ネットワークと仮想ネットワーク(スライス)の関係を示す図である。 ゲートキーパー-実ノード間のリンク設定要求およびリンク設定応答の内容を示す図である。 ゲートキーパー-ゲートウェイ間のパス設定要求、パス設定応答、ドメイン間パス設定要求、ドメイン間パス設定応答の内容を示す図である。 図２に示した設定・管理操作をおこなう際のシーケンスの第１部分の補足図である。 図２に示した設定・管理操作をおこなう際のシーケンスの第２部分の補足図である。 無限再帰を停止させるステップをふくまないプログラムを使用したときに設定・管理操作において発生しうる無限再帰の説明図である。 図２に示した設定・管理操作のシーケンスと、その間に生成される仮想リンクVL14に対応するドメイン間パスとの関係である。 図５の説明の続きの図である。

以下、本発明の実施例を図面に従い説明する。

（ネットワーク構成）
第１の実施形態について説明する。図１はドメインD1、D2、D3をふくむネットワーク全体の構成を示す。ドメインD1は、オペレータが、種々の制御データや制御コマンドを入力し、また、データ等を表示するのに使用するオペレータ・コンソール１０１、ネットワークを管理するためにデータや制御情報をネットワーク・ノードに配布したりネットワーク・ノードから収集したデータを処理するネットワーク管理サーバ（NM）１０２（制御管理ノード、管理ノードとも言う）、ネットワーク・ノード１０３、１０４を含み、さらにドメイン間連携のために他のドメインと通信を行うゲートキーパー(GK)１０７と、ドメインD2との連携のための疑似ノード（Pesudo Node P11）１０５、ゲートウェイ（Gateway）１０８、ドメインD3との連携のための疑似ノード（Pesudo Node P12）１０６、ゲートウェイ（Gateway）１１０を含む。ドメインD2へのパスが２個あるときは、さらにこのパスに対応するゲートウェイ（Gateway）１０９を含む。

また、ドメインD2はオペレータ・コンソール１１１、ネットワーク管理サーバ（NM）１１２、ネットワーク・ノード１１３、１１４を含み、さらにドメイン間連携のためにゲートキーパー(GK)１１７、とくにドメインD1との連携のために疑似ノード１１５、ゲートウェイ１１８、ドメインD3との連携のために疑似ノード１１６、ゲートウェイ１２０をふくむ。ドメインD1へのパスが２個あるときは、さらにこのパスに対応するゲートウェイ１１９を含む。

ゲートキーパー１０７、ゲートウェイ１０８はドメイン間連携のためのインターフェース部分であり、これらをまとめてドメインD1の「連携システム」と呼ぶことができる。また、ゲートキーパー１１７、ゲートウェイ１１８をまとめてドメインD2の「連携システム」と呼ぶことができる。

なお、ここではドメインD1とドメインD2が同様の構成をとっているが、ドメイン間インターフェースが同一であれば、いずれかのドメインの構造が他と異なっていてもよい。たとえば、ドメインD2においてはネットワーク管理サーバ１１２がドメイン間連携機構を内蔵していて、疑似ノード１１５やゲートキーパー１１７を使用することなくドメイン間のメッセージ送受信をおこなうようにしてもよい。

ここで、制御管理ノードは、自ドメインの設定管理情報だけを扱う、ドメイン間連携のために改造されていないネットワーク管理サーバもしくは制御ノードである。特定の制御管理プロトコルによって自ドメイン内のノードに制御管理情報を送信する。

疑似ノードは、ノードの設定管理情報の形式でネットワーク管理サーバから他ドメインの管理情報を受信し、他ドメインの情報をゲートキーパーに転送するノード(サーバ)である。前記の特定の制御管理プロトコルによって制御管理ノードから制御管理情報を受信する。

ゲートキーパーは、自ドメインの疑似ノードから受信する管理情報は標準形式に変換して特定のフェデレーション・プロトコルによって他ドメインに転送し、特定のフェデレーション・プロトコルによって他ドメインから受信する標準形式の管理情報は自ドメイン内の形式に変換して自ドメインの制御管理ノードに転送するサーバである。ゲートウェイのインターフェース(API)を経由してゲートウェイを設定する機能を持つ。

ゲートウェイは、自ドメインからのデータ・パケットを標準形式に変換して他ドメインに転送し、他ドメインからの標準形式のデータ・パケットは自ドメインの形式に変換して転送するゲートウェイである。ドメイン間の仮想または実データ転送パスの端点として機能することができ、またドメイン内からの仮想または実データ転送パスの端点として機能することができる。それらのパスを設定するためのインターフェース(API)をそなえている。ドメイン間の仮想または実データ転送パスとドメイン内の仮想または実データ転送パスとを連結させ、パケットを中継することができる。

上記のように、ドメインD1が複数のドメインと連携する可能性があるために複数の疑似ノード１０５、１０６が存在するが、ゲートキーパーは１個で複数のドメインと連携することができる。１個の疑似ノードが複数のドメインと連携することもできる。また、上記のようにドメインD1には複数のドメインとの連携のため複数のゲートウェイが存在するが、１個のゲートウェイが複数のドメインと連携することもできる。また、２個のドメイン間に複数のゲートウェイをおいて、そのうちの１個をネットワーク管理サーバが選択して使用することも可能であり、また動的ルーティングのように自動的に経路が選択されるときはゲートウェイの選択が自動化できることもある。

ドメインD1、D2は本実施例の方法を適用する以前はそれぞれ独立に存在し、連携しない。この状態では疑似ノード１０５、１１５、ゲートキーパー１０７、１１７、およびゲートウェイ１０８、１１８は存在しない。ドメインD1、D2にはそれぞれ物理ノードを追加することが可能であり、その際にはNM１０２、NM１１２に追加した物理ノードの情報を格納する。これによってNM１０２、NM１１２は追加された物理ノードへの設定をおこなうことができるようになる。疑似ノード１０５、１１５はこのような物理ノードの追加とまったくおなじ方法で追加することができる。すなわち、NM１０２、NM１１２に疑似ノード１０５、１１５の情報を物理ノード情報として追加する。これによって、以下に記述するようにドメイン間連携がおこなえるようになる。
（ノード構成)
図１１は、疑似ノード１０５、１１５、ゲートキーパー１０７、１１７、およびゲートウェイ１０８、１１８の構成を示す。図１１の（a）は疑似ノード１０５、１１５を示す。CPU、メモリ、ネットワーク・インターフェース(NIF)を内蔵し、NIFによってNM１０２、NM１１２、ゲートキーパー１０７、ゲートキーパー１１７等と通信することができる。

ゲートキーパー１０７、１１７は図１１の（b）のようにCPU、メモリ、ネットワーク・インターフェース(NIF)を内蔵し、NIFによって疑似ノード１０５、１１５、ゲートウェイ１０８、１１８等と通信することができる。ゲートキーパー１０７、１１７のメモリはドメイン内設定管理プログラム２０１、受信側ドメイン間設定管理プログラム２０２、送信側ドメイン間設定管理プログラム２０３等のプログラムや、疑似ノード表７０１等のデータを含んでいる。上記プログラム２０１、２０２、２０３とくにステップ３０1、３０３、４０1、４０３は、従来からゲートキーパー１０７、１１７が有するドメイン間交渉機能およびゲートウェイ設定機能に加えて、本実施例で新たに必要となる処理を包含している。また、データ７０１は本実施例で新たに必要となるデータである。

ゲートウェイ１０８、１１８は、図１１（c）のようにCPU、メモリ、および２個のネットワーク・インターフェース(NIF)を内蔵し、一方のNIFによってドメイン内のサーバやノードと通信し、他方のNIFによって他ドメインのゲートウェイ(すなわちゲートウェイ１０８に関してはゲートウェイ１１８、ゲートウェイ１１８に関してはゲートウェイ１０８)と通信することができる。ゲートキーパー１０７とゲートキーパー１１７との通信はゲートウェイ１０８、１１８を介することも可能であり、ゲートウェイ１０８、１１８を介さずに他の経路をとることも可能である。これら疑似ノード、ゲートキーパー、ゲートウェイは、メモリ内のデータやプログラムをＣＰＵで処理することで、各装置の機能を実現し、またネットワーク・インターフェースNIFを介して、外部と通信する。
（管理情報)
図５は、管理情報の内容を示す。本実施例においては仮想ネットワークまたは物理ネットワークの管理情報をスライス情報とよぶ。これは、管理情報として非特許文献１におけるのと同様なスライス(仮想ネットワーク)の構成情報などを想定しているためである。しかし、スライス情報の内容は仮想ネットワークに限定されず、実ネットワークの情報を含むことができる。
（実ネットワークとスライス）
以下、管理情報が仮想ネットワークを扱う場合について、実ネットワークと仮想ネットワークすなわちスライスとの関係を、図１３を使用して説明する。実ネットワーク１３２１上に物理ノード１３０１があり、実ネットワーク１３２６上に物理ノード１３１１がある。この物理ネットワーク１３２１および１３２６上にスライス１３２２、スライス１３２３、スライス１３２４、スライス１３２５を生成する。物理ノード１３０１上に仮想ノード１３０２、１３０３、１３０４を生成し、物理ノード１３１１上に仮想ノード１３１２、１３１３、１３１４を生成する。仮想ノード１３０４、１３１４はスライス１３２５に属し、仮想リンクによって結合される。また、仮想ノード１３０２、１３１２はスライス１３２３に属し、仮想リンクによって結合される。これらの仮想リンクはドメイン間をまたぐ。スライスの構造は実ネットワークと同一にすることも可能だが、仮想リンクはトンネル等を使用することによって物理リンクに制約されずに生成することができるため、スライスを実ネットワークとは異なる構造にすることもできる。
（スライスとスライス情報）
スライスは通常、複数の仮想ノードと仮想ノード同士とを結ぶ仮想リンク(仮想データ転送パス)とで構成される。仮想ノードは物理ノード上につくられるが、仮想ノード同士の接続は物理ノードの接続とは独立である。すなわち、仮想リンクは実リンクによって縛られない。仮想ノードはスイッチング、ルーティングをはじめとするネットワーク・プロトコル処理機能をもつが、その機能はその仮想ノードを含む物理ノードのプロトコル処理機能とは独立でありうる。

ドメイン間にまたがる仮想ネットワークの設定をおこなうため、本実施形態においては仮想ノードのリストと仮想リンクのリストとで構成されるスライスの構成情報をスライス情報（「管理情報」や「設定管理情報」とも言う）として、管理メッセージに包含する。

スライス情報は上記のような仮想ネットワークにおける仮想ノードの属性や資源量たとえば仮想ノードと対応づけられたＣＰＵの個数やメモリ量や、仮想リンクの属性たとえば仮想リンクが使用することができる帯域や、仮想ノードと仮想リンクとの接続関係などで構成される情報である。ただし、スライス情報は、スライスが含む全ての仮想ノードや仮想リンクの情報を、必ずしも含んでいる必要はない。

また、スライス情報は、必ずしも仮想ネットワークに関する情報であるとは限らない。すなわち、物理ノードや物理リンク(実データ転送パス)を管理するための情報であってもよい。この場合、スライス情報は物理ノードの設定情報や状態に関する情報、物理リンクの状態に関する情報(たとえば使用可能性やトラフィック量)などを含むことができる。

背景技術におけるPNNIやIGP、EGPにおいてはスライス情報がルーティング情報を含んでいた。しかし、本実施例においては、スライス情報はおもに仮想ネットワークの構成情報すなわち仮想ネットワークの構造などに関する情報を含み、ルーティング情報は仮想ネットワークの開発者が別途あたえることを想定する。しかしながら、スライス情報としてルーティング情報を含むことも可能である。
（スライス情報の内容）
次に図５の（ａ）から（c）と図２０の (d) を用いて、スライス情報の内容を説明する。

図５の（ａ）は、ドメインD1用スライス情報を示す。スライスＳ(仮想ネットワークまたは物理ネットワーク)に関するスライス情報５０１は、ポートp1、p2をもつ仮想ノードVN1、ポートp1、ｐ２をもつ仮想ノードＶＮ２、ポートｐ３’、ｐ４’をもつ仮想ノードVNPと、VN1のポートp1とVN2のポートp2とを結ぶ仮想リンクVL12、VN1のポートp2とVNPのポートp3'とをむすぶ仮想リンクVL14、VN2のポートp1とVNPのポートp4'とをむすぶ仮想リンクVL23とで構成される。仮想ノードVN1は物理ノードN11に対応づけられ(すなわちN11内に生成され)、仮想ノードVN2は物理ノードN12に対応づけられ(すなわちN12内に生成され)ている。また、仮想ノードVNPは疑似ノードP11に対応づけられている。さらに、仮想ノードVNPはその内部にポートp1、p4をもつ仮想ノードVN3、ポートp2、p3をもつ仮想ノードVN4と、VN3のポートp1とVN4のポートp2とを結ぶ仮想リンクVL34を入れ子として含み、VN3のポートp4は仮想リンクVL24によってVNPのポートp4'と結ばれ、VN4のポートp3は仮想リンクVL13によってVNPのポートp3'と結ばれている。仮想ノードVN3は物理ノードN21に対応づけられ、仮想ノードVN4は物理ノードN22に対応づけられている。言い換えれば、自ドメインの制御管理ノードにドメイン間に跨る設定管理情報をあたえるとき、この設定管理情報は入れ子（ネスト）形式をしている自ドメインの情報はネットワーク・ノード単位にまとめられ、他ドメインの情報は１個のネットワーク・ノードへの情報の形式にまとめられ、ドメインD1内でドメインD2を代理 (代表) しているP11という疑似ノードの識別子が付加されている。

図５の（ｂ）は、標準スライス情報を示す。スライス情報は、ドメインD1からドメインD2にわたされるとき、その中間点において５０２の形式をとる（ドメインD1からドメインD2へ渡されるスライス情報であり、ドメインに依存性がないということで標準スライス情報とする）。すなわち、スライスSに関するスライス情報５０２は、ポートp1、p2をもつ仮想ノードVN1、ポートp1、p2をもつ仮想ノードVN2、ポートp1、p4をもつ仮想ノードVN3、ポートp3、p2をもつ仮想ノードVN4と、VN1のポートp1とVN2のポートp2とを結ぶ仮想リンクVL12、VN3のポートp1とVN4のポートp2と結ぶ仮想リンクVL34、VN1のポートp2とVN4のポートp3とを結ぶ仮想リンクVL14、VN2のポートp1とVN3のポートp4とを結ぶ仮想リンクVL23とで構成される。スライス情報５０２はスライス情報５０１を変換することによってえられる。この変換は１個のネットワーク・ノードへの情報の形式にまとめられていた他ドメインの情報を個別の情報に分離し、ドメインD1以外では意味をもたないP11という疑似ノードの識別子を削除するという意味がある。仮想ノードVN1は物理ノードN11に対応づけられ(すなわちN11内に生成され)、仮想ノードVN2は物理ノードN12に対応づけられ(すなわちN12内に生成され)ている。また、仮想ノードVN3は物理ノードN21に対応づけられ、仮想ノードVN4は物理ノードN22に対応づけられている。

なお、ドメインD1とドメインD2の中間点におけるスライス情報の形式として、図２０の５０４の形式をとることもできる。すなわち、スライスSに関するスライス情報５０４はスライス情報５０２とは違って各仮想ノードがドメインごとにくくられている。仮想ノードVN1、VN2はドメインD1の物理ノードN11、N12内にあるため、ドメインD1によってくくられている。また、仮想ノードVN3、VN4はドメインD2の物理ノードN21、N22内にあるため、ドメインD2によってくくられている。この形式をとることによって、ゲートキーパーが他のドメインにおける物理ノードとドメインとの対応関係を知る必要がなくなり、また物理ノードのなかから自ドメインに属するものだけを選択する処理負荷がなくなるという利点がある。また、ドメインによってくくられた内容は暗号化したままゲートキーパー間で転送することができるため、後述する暗号化、復号化の処理をおこなうのに適している。

図５の（ｃ）は、ドメインD2用スライス情報を示す。スライス情報は、ドメインD2内では５０３の形式をとる。すなわち、スライスSに関するスライス情報５０３はポートp1、p4をもつ仮想ノードVN3、ポートp3、p2をもつ仮想ノードＶＮ４、ポートｐ１’、ｐ２’をもつ仮想ノードVNQと、VN3のポートp1とVN4のポートp2とをむすぶ仮想リンクVL34、VN3のポートp4とVNQのポートp1’とをむすぶ仮想リンクVL23、VN4のポートp3とVNQのポートp2'とをむすぶ仮想リンクVL14とで構成される。仮想ノードVN3は物理ノードN21に対応づけられ(すなわちN21内に生成され)、仮想ノードVN4は物理ノードN22に対応づけられ(すなわちN22内に生成され)ている。また、仮想ノードVNQは疑似ノードP21に対応づけられている。さらに、仮想ノードVNQはその内部にポートp1、p2をもつ仮想ノードVN1、ポートp1、p2をもつ仮想ノードVN2と、VN1のポートp1とVN2のポートp2とをむすぶ仮想リンクVL12を入れ子としてふくみ、VN1のポートp2は仮想リンクVL24によってVNQのポートp2'と結ばれ、VN2のポートp1は仮想リンクVL13によってVNQのポートp1'とむすばれている。スライス情報５０３における仮想リンクVL24およびVL13とスライス情報５０１における仮想リンクVL24およびVL13と偶然に同名になっているが、これらは異なる仮想リンクである。仮想ノードVN1は物理ノードN11に対応づけられ、仮想ノードVN2は物理ノードN12に対応づけられている。

このようなスライス情報はさまざまな方法で表現することができるが、XMLを使用することによって、スライス情報５０１は、図１０のように表現することができる。
（シーケンス)
（主シーケンス）
図２は、ドメインD1、D2にまたがる設定・管理操作をおこなう際のシーケンスを表す。図２においてスライス要求２１１、ノード/リンク要求２１２、ドメイン間依頼要求２１３、ドメイン間依頼２１４、スライス要求２１５、ノード/リンク要求２１６、ドメイン間依頼要求２１７はいずれも管理メッセージの一種であり、図１２の（ａ）の管理メッセージ１２０１の形式をとる。管理メッセージ１２０１は、種別１２０２、スライス情報１２０３、付加情報１２０４から構成される。種別１２０２は、管理メッセージ１２０１の種別（スライス要求、ノード／リンク要求、等）を表す。

前記の制御管理ノード、擬似ノード、ゲートキーパー、ゲートウェイが自ドメインおよび他ドメインに用意されているとき、それらは次のように動作する。前述の設定管理情報は、特定の制御管理プロトコルによって自ドメインの疑似ノードに配布され、自ドメインの疑似ノードはそれを自ドメインのゲートキーパーに転送する。自ドメインのゲートキーパーは、前記設定管理情報を標準形式に変換して前記のフェデレーション・プロトコルによって他ドメインのゲートキーパーに転送するとともに、自ドメインのゲートウェイにおいて終端する自ドメインの他のノードからの仮想または実データ転送パスを設定・管理する。

また、自ドメインのゲートキーパーは、他ドメインのゲートキーパーから前記のフェデレーション・プロトコルによって標準形式の設定管理情報を受信したとき、これを自ドメインのゲートウェイに送信し、自ドメインのゲートウェイにおいて終端する他ドメインからの仮想または実データ転送パスを設定・管理する。また、自ドメインのゲートキーパーは、受信した標準形式の設定管理情報を自ドメインの形式に変換し、自ドメイン形式の設定管理情報を自ドメインの制御管理ノードに送信する。

さらに、自ドメインのゲートキーパーは他ドメインのゲートキーパーから前記のフェデレーション・プロトコルによって設定管理の成功応答を受信すると、自ドメインのゲートウェイにおいて終端する他ドメインからの仮想または実データ転送パスを設定・管理する。

ここで、上記の設定管理情報はネスト形式をしている。前記の自ドメイン形式の設定管理情報は自ドメインの疑似ノードに配布され、自ドメインの疑似ノードは前記の自ドメイン形式の設定管理情報を自ドメインのゲートキーパーに転送する。自ドメインのゲートキーパーは前記の自ドメイン形式の設定管理情報が標準形式で受信した前記の設定管理情報と同一であることを識別し、転送処理を行わない。

また、複数ドメインとの連携に関する場合は、次のようになる。

自ドメイン以外のドメインが複数個あるときはそれぞれに対応する疑似ノードが存在するが、標準形式の設定管理情報を受信したときは、変換後は設定管理情報において、その他ドメインの情報をまとめる疑似ノードの名称を設定管理情報の送信元のドメインに対応する疑似ノード名とする。

なお、相手ドメインが複数個存在するときは、上記の手段のうち疑似ノードは相手ドメインごとに異なるものを使用する。ゲートキーパーは相手ドメインごとに異なる擬似ノードを使用することも可能であり、また複数の相手ドメインに対して１個のゲートキーパーを対応させることもできる。ゲートウェイは複数の相手ドメインに対して１個にすることもでき、相手ドメインごとに１個にすることもできる。また、１個の相手ドメインに対して複数のゲートウェイを使用することも可能である。

上記構成により、ドメイン間にまたがるネットワーク・サービスのための設定・制御・管理をネットワーク管理サーバや制御ノードの改造なしに、付加的なサーバやノードを追加するだけで実現することができるため、ネットワークの構成は単純化し、制御管理ノードの改造によるコストやバグ発生のリスクを回避することができる。また第２に、N種類のプロトコルや管理方式にもとづくドメイン間を連携させるときも、各プロトコルや各管理方式と標準的な中間形式との変換をおこなうN種類の管理機能や制御機能だけを搭載したサーバやノードを用意すればよいため、スケーラブルな連携を実現することができる。

また、見方を変えると次のような動作になる。第１ネットワーク・ドメインと、第２ネットワーク・ドメインと、前記第２ネットワーク・ドメインに関するドメイン設定管理情報を前記第２ネットワーク・ドメインの外部から受信して前記第２ネットワーク・ドメインに属するノードの設定を行う連携システムから構成されるネットワークシステムにおいて、前記第１ネットワーク・ドメインは、複数のノードと、第２ネットワーク・ドメインとの連携のための疑似ノードおよびゲートキーパーと、前記複数のノードと前記疑似ノードとを管理する第１管理ノードを有し、前記第１管理ノードは、前記第１ネットワーク・ドメインに接続されたコンソールから、前記複数のノードのノード設定情報を含む第１ドメイン設定管理情報を受信し、かつ、前記第１ドメイン設定管理情報を前記複数のノードに送信し、前記複数のノードのそれぞれは、前記第１ドメイン設定管理情報に含まれる前記ノード設定情報に従って設定を行い、ここで、前記第１ドメイン設定管理情報は、前記疑似ノードに関する第２ノード設定情報を含んでおり、前記第２ノード設定情報は前記疑似ノードの識別情報を含んでおり、更に、前記第２ノード設定情報は、前記第２ネットワーク・ドメインに関する第２ドメイン設定管理情報を有しており、前記第１管理ノードが、前記疑似ノードに前記第１ドメイン設定管理情報を前記疑似ノードに送信し、前記疑似ノードが、前記第２ノード設定情報を前記ゲートキーパーに送信し、前記ゲートキーパーは前記第２ノード設定情報から前記疑似ノードの識別情報を除外した情報を前記連携システムに送信し、前記連携システムが、前記第２ドメイン設定管理情報を用いて、前記第２ネットワーク・ドメインに属するノードの設定を行うと、纏めることもできる。

以下、図２を用いて手順を詳しく説明する。図２のシーケンスにおいて、まずコンソール(Console)１０１からネットワーク管理サーバ(NM)１０２にスライス要求２１１を送信する。スライス要求２１１はドメインD1内形式のスライス情報５０１を含んでいる。NM１０２はスライス情報５０１を自ドメイン(D1)の管理情報として受信し、ノード/リンク要求２１２にいれて疑似ノード１０５を含むNM１０２の管理下の各ノードに配布する(スライス情報５０１の配布の方法に関する他の選択肢については後述する)。

図２において、疑似ノード１０５およびノードN11（１０３）、N12（１０４）が、ノード/リンク要求２１２を受信する。疑似ノード１０５が受信するノード/リンク要求２１２は、ノードN11（１０３）、N12（１０４）が受信するノード/リンク要求２１２と同一である。すなわち、疑似ノード１０５をドメインD1に追加し、ドメインD2と連携するにあたってNM１０２の処理方法を変更する必要はない。したがってNM１０２のソフトウェアおよびハードウェアを変更する必要もまったくない。また、ノードN11（１０３）、N12（１０４）のソフトウェアおよびハードウェアを変更する必要もまったくない。そして、疑似ノード１０５がノード/リンク要求２１２を受信すると、スライス情報５０１をドメイン間依頼要求２１３にいれてゲートキーパー１０７に送信する。

ドメインＤ１のゲートキーパー１０７は、ドメインＤ１内形式のスライス情報５０１を入力し、後述するドメイン内設定管理プログラム２０１を実行して、その結果である(ドメイン依存性がない)標準形式のスライス情報５０２をもとめ、それをドメイン間依頼２１４にいれて他ドメインのゲートキーパー１１７に送信する。ドメイン内設定管理プログラム２０１の実行中にゲートキーパー１０７からドメイン間リンクの始点であるノードN11（１０３）とノードN12（１０４）にそれぞれリンク設定要求２３１、２３３が送信され、リンク設定要求２３１、２３３に対する応答であるリンク設定応答２３２、２３４をゲートキーパー１０７が受信する。リンク設定要求２３１、２３３およびリンク設定応答２３２、２３４によって、ノードN11（１０３）およびノードN12（１０４）とゲートウェイ１０８とのあいだの仮想リンクのドメインD1内部分が設定される。また、ドメイン内設定管理プログラム２０１の実行中にゲートキーパー１０７からゲートウェイ１０８にパス設定要求２４１が送信され、ゲートウェイ１０８からパス設定応答２４２を受信する。

他ドメインのゲートキーパー１１７は標準形式のスライス情報５０２を入力し、後述する受信側ドメイン間設定管理プログラム２０２を実行してその結果であるドメインD2内形式のスライス情報５０３をもとめ、それをスライス要求２１５にいれてネットワーク管理サーバ(NM)１１２に送信する。受信側ドメイン間設定管理プログラム２０２の実行中にゲートキーパー１１７からゲートウェイ１１８にドメイン間パス設定要求２４５が送信され、ゲートウェイ１１８からドメイン間パス設定応答２４６を受信する。

NM１１２はスライス情報５０３をドメインD2の管理情報として受信し、ノード/リンク要求２１６にいれて疑似ノード１１５を含むNM１１２の管理下の各ノードに配布する(スライス情報５０３の配布の方法に関する他の選択肢については後述する)。疑似ノード１１５がノード/リンク要求２１６を受信すると、スライス情報５０３をドメイン間依頼要求２１７にいれてゲートキーパー１１７に送信する。

ゲートキーパー１１７はドメインD2内形式のスライス情報５０３を入力し、ドメイン内設定管理プログラム２０１を実行するが、その結果スライス情報をドメインD1に転送する必要がないことがわかるため、転送はおこなわずにドメイン間依頼要求２１７に対する応答であるドメイン間依頼要求応答２２１を疑似ノード１１５にかえす。ドメイン内設定管理プログラム２０１の実行中にゲートキーパー１１７からドメイン間リンクの始点であるノードN21（１１３）とノードN22（１１４）にそれぞれリンク設定要求２３５、２３７が送信され、リンク設定要求２３５、２３７に対する応答であるリンク設定応答２３６、２３８をゲートキーパー１１７が受信する。リンク設定要求２３５、２３７およびリンク設定応答２３６、２３８によって、ノードN21（１１３）およびノードN22（１１４）とゲートウェイ１１８とのあいだの仮想リンクのドメインD2内部分が設定される。また、ドメイン内設定管理プログラム２０１の実行中にゲートキーパー１１７からゲートウェイ１１８にパス設定要求２４３が送信され、ゲートウェイ１１８からパス設定応答２４４を受信する。

ドメイン間依頼要求応答２２１を受信した疑似ノード１１５はノード/リンク要求２１６に対する応答であるノード/リンク要求応答２２２をNM１１２に返す。それを受信したNM１１２はスライス要求２１５に対する応答であるスライス要求応答２２３をゲートキーパー１１７にかえす。それを受信したゲートキーパー１１７はドメイン間依頼２１４に対する応答であるドメイン間依頼応答２２４をゲートキーパー１０７に返す。

ドメイン間依頼応答２２４を受信したゲートキーパー１０７は送信側ドメイン間設定管理プログラム２０３を実行し、ドメイン間依頼要求２１３に対する応答であるドメイン間依頼要求応答２２５を疑似ノード１０５にかえす。送信側ドメイン間設定管理プログラム２０３の実行中にゲートキーパー１１７からゲートウェイ１１８にドメイン間パス設定要求２４７が送信され、ゲートウェイ１１８からドメイン間パス設定応答２４８を受信する。

ドメイン間依頼要求応答２２５を受信した疑似ノード２０５はノード/リンク要求２１２に対する応答であるノード/リンク要求応答２２６をNM１０２にかえす。それを受信したNM１０２はスライス要求２１１に対する応答であるスライス要求応答２２７をコンソール(Console)１０１に返す。
（シーケンス補足）
以下、上記のシーケンスを補足説明する。図２のシーケンスは、ドメインD1からドメインD2にまたがる管理をおこなうシーケンスだったが、逆のシーケンスも同じ形をとる。すなわち、図２は、ドメインＤ１側のコンソール１０１からスライス情報５０１を含むスライス要求２１１を入力したときのシーケンスだったが、ドメインＤ２側のコンソール１１１からスライス情報５０３を含むスライス要求を入力したときのシーケンスは、図２におけるConsole１０１とConsole１１１とを交換し、NM（１０２）とNM（１１２）とを交換し、物理ノード１０３、１０４と物理ノード１１３、１１４とを交換し、ゲートウェイ１０８とゲートウェイ１１８とを交換し、疑似ノード１０５と疑似ノード１１５とを交換し、ゲートキーパー１０７とゲートキーパー１１７とを交換してえられるシーケンスとなる。

また、ドメインD2がゲートキーパー１０７−ゲートキーパー１１７間と同一のインターフェース(API)を実装していれば、ドメインD2の内部のシーケンスにかかわらず、ドメインD1におけるシーケンスは変化しない。すなわち、ドメインD2がドメイン間依頼２１４に対してドメイン間依頼応答２２４を返すのであれば、スライス要求２１１からドメイン間依頼２１４までとドメイン間依頼応答２２４からスライス要求応答２２７までのシーケンスは変化しない。
（スライス情報の配布法に関する代案）
前記の説明においてはスライス情報５０１および５０３をノードに配布する際に、NM１０２およびNM１１２がスライス情報をそのまま全ノードに直接配布する方法をとっていた。しかし、この方法に関しては３つの代案が存在する。
（部分情報の配布)
第１の代案を、図６を使用して説明する。第1の代案は、スライス情報５０１および５０３から配布先のノードに関する情報だけを抽出し、１個のノードに関する情報だけを各ノードに配布する方法である。この方法をとるときは、疑似ノード１０５はスライス情報５０１から仮想ノードVN1およびVN2に関する情報を削除したスライス情報６０１を受信する。しかし、仮想ノードVNPから仮想ノードVN1およびVN2への仮想リンクすなわちVL1P、VL2Pの情報は、これらの仮想リンクに対応する設定を実行するために必要であり、スライス情報601に含まれている。疑似ノード１０５がスライス情報６０１を受信したときは、スライス情報５０２のかわりにスライス情報６０２を使用する。すなわち、標準形式のスライス情報から仮想ノードVN1およびVN2の情報が脱落したものがドメインD1からドメインD2にわたされる。さらに、NM（１１２）にわたされるスライス情報は、スライス情報６０３のかたちとなる。すなわち、ここでも仮想ノードVN1およびVN2の情報が脱落しているが、仮想ノードVNQから仮想ノードVN3およびVN4への仮想リンクすなわちVL3Q、VL4Qの情報は、これらの仮想リンクに対応する設定を実行するために必要であり、スライス情報603に含まれている。
（制御プロトコル（ルーティング・プロトコル等）による配布）
第２の代案は、NM（１０２）およびNM（１１２）がスライス情報５０１および５０３を１個のノードにだけ配布し、ノード間でそのスライス情報を分散的に再配布する方法である。ルーティング・プロトコルなどの制御プロトコルにスライス情報をうめこむことによって、このような再配布を実現することができる。
（ドメイン内秘密情報の暗号化）
第３の代案は、スライス情報が含むドメイン内秘密情報を暗号化する方法である。複数のドメインの連携においては、他のドメインに対して自ドメイン内部の情報を隠蔽したいことがある。本実施例においてはドメインD1にスライス情報をわたす際にドメインD2の管理情報がすべて参照可能な状態でわたされるため、このような隠蔽ができない。しかし、それを隠蔽するためにつぎのような方法をとることができる。スライス情報５０１を生成する際に、仮想ノードVNP内の情報を暗号化し、隠蔽する。ただし、リンク名VL14およびVL23だけは隠蔽しない。このようにすれば仮想リンクとその実装パラメタとの対応をとることができるが、ドメイン内の構成などは隠蔽することができる。

暗号化された情報を含むスライス情報５０１はゲートキーパー１０８においてスライス情報５０２に変換する際に仮想ノードVN1、VN2およびそれらのあいだの仮想リンクVL12の情報を暗号化することによってドメインD1内部の情報を隠蔽する。スライス情報502がゲートキーパー118にわたされ、スライス情報503に変換される際にゲートキーパー118がもつ復号化キーによって仮想ノードVN3、VN4およびそれらのあいだの仮想リンクVL34の情報を平文化することができる。ドメインD2内ではこの情報にもとづいて設定管理をおこなうことができる。スライス情報503がゲートキーパー118から仮にゲートキーパー108にわたされるとすると、その際にはふたたび仮想ノードVN3、VN4およびそれらのあいだの仮想リンクVL34の情報はゲートキーパー１１８によって暗号化されるが、逆に仮想ノードVN1、VN2およびそれらのあいだの仮想リンクVL12の情報はゲートキーパー108によって復号化される。

３個以上のドメインにまたがるスライス情報に関しても、ドメインごとにそのドメインのゲートキーパーが、外部にスライス情報を送信する際には自ドメインのスライス情報を暗号化し、外部からスライス情報を受信する際には自ドメインのスライス情報を復号化するようにすればよい。
（パケット・ヘッダ変換法)
（ゲートウェイにおけるパケット・ヘッダ変換（ドメイン内表現-ドメイン間表現間マッピング））
つぎに、ゲートウェイ１０８、１１８におけるパケット・ヘッダ変換の方法について記述する。ドメイン間で転送されるパケットのパケット・ヘッダは、後述するようにドメイン内の実装方式と、ドメイン間の実装方式とで、独立に決めることができる。このため、この変換においては、アドレス変換だけでなく、プロトコル変換が必要な場合がある。すなわち、第１にドメインD1とD2では異なるプロトコルが使用されている可能性がある。また、第２にD1-D2間のパケット転送においてはD1、D2とは異なるプロトコルが使用される可能性がある。そのため、ゲートウェイ１０８、１１８は、これらのプロトコル間の変換をおこなう必要がある。すなわち、データ・パケットのパケット・ヘッダを変換する必要がある。

図９は、ゲートウェイ１０８、１１８が内蔵する４種類のプロトコル変換のための対応表を記述している。ゲートウェイ１０８、１１８は、これらの対応表を参照してパケット・ヘッダ変換を行うが、変換のプログラム自体は予め記憶装置に用意されているヘッダを用いて行われる。但し、異なる種類のプロトコル変換のうちのいずれを使用するかはスライスごとに指定する必要がある。

第１に、VLAN（VLAN:Vurtual LAN、仮想ＬＡＮ）からVLANへの変換は、図９の(a)に示すVLAN ID（VLANID:VLAN Identifier、ＶＬＡＮ識別子）とMACアドレスの対応表９０１を使用し、ドメイン内でのVLAN IDとMACアドレスをキーとして、ドメイン間のVLAN IDとMACアドレスとを対応表９０１から求めて、パケット・ヘッダのVLAN IDとMACアドレスを書き換えればよい。

第２に、IPトンネルからIPトンネルへの変換は、図９の(b)に示すIPアドレスの対応表９０２を使用し、ドメイン内のIPアドレスをキーとしてドメイン間のIPアドレスを対応表９０２から求めてパケット・ヘッダのIPアドレスをかきかえればよい。

第３に、VLANからIPトンネルへの変換は、図９の(c)に示すVLAN ID、MACアドレスとIPアドレスとの対応表９０３を使用し、Ethernet（登録商標）ヘッダのIPヘッダへの変換もしくはIPアドレスの挿入をおこなって、求めたIPアドレスを得られたIPヘッダに書き込めばよい。

第４に、IPトンネルからVLANへの変換は、図９の(d)に示す対応表９０４を使用してIPアドレスとVLAN ID、MACアドレスとの対応表を使用しIPヘッダのEthernetヘッダへの変換もしくはIPアドレスの削除をおこなって、求めたVLAN IDとMACアドレスとをEthernetヘッダに書き込めばよい。

これらの対応表はドメイン内からドメイン間へとドメイン間からドメイン内への双方向に使用することができる。これら対応表において、ドメイン内からドメイン間への変換においては、変換元としてドメイン内でのゲートウェイのアドレスを指定し、変換先として他ドメインのゲートウェイのドメイン間でのアドレスを指定する。また、ドメイン間からドメイン内への変換においては、変換元として自ドメインのゲートウェイのドメイン間でのアドレスを指定し、変換先として自ドメインのノードにつけられたドメイン内アドレスを指定する。これらの対応表は後述するゲートキーパー１０７、１１７からゲートウェイ１０８、１１８への通信すなわちパス設定要求２４１、２４３およびドメイン間パス設定要求２４５、２４７によって設定され、ドメイン間でデータ・パケットがやりとりされる際にパケット・ヘッダの変換が行われる。

（ゲートウェイにおけるパケット・ヘッダ変換の省略)
上記の方法においては、ドメイン内とドメイン間の実装方式が同一でも、対応表を使用してアドレス変換を行っている。しかし、実装方式が同一であれば、アドレス(およびVLAN ID)を揃えれば変換の必要はなくなる。すなわち、ゲートキーパー１０８がゲートキーパー１１８に対してドメイン間仮想リンクのドメインD1側のアドレスをわたす際にゲートウェイ１０９のアドレスを渡していたが、そのかわりに仮想ノードVN1およびVN2からゲートキーパー１０８が受取ったアドレス(およびVLAN ID)をそのままゲートキーパー１１８に渡せば、ゲートウェイ１０９における変換は不要になり、ゲートウェイも不要になる(ただし、外部からのリンクをドメイン内部に直結する必要がある)。
（送信側（ドメインD1）ゲートキーパーの処理1/2）
図３は、ゲートキーパー１０７および１１７におけるドメイン内設定管理プログラム２０１の処理手順を示すフローチャートである。ドメイン内設定管理プログラム２０１の実行が開始されると、まずステップ３０１において、受信したドメイン間依頼要求が廃棄するべきものかどうかを判定する。この判定のための具体的な方法については後述する。判定の結果が真であればドメイン内設定管理プログラム２０１を終了するが、偽であればステップ３０２にすすむ。
（送信側ゲートキーパーにおけるドメイン間仮想リンクのためのドメイン内設定)
ステップ３０２においては、ドメイン間依頼要求２１３に含まれる情報を使用して、ドメイン間リンクに接続するドメイン内リンクを設定する。具体的には、ドメインD1におけるスライス情報５０１の処理においては、まず、仮想リンクVL14およびVL23に対応するパスの設定をおこなう。この設定においてはまずこのドメイン間リンクが通過するべきゲートウェイがまだ決まっていなければ、それを決定する。ドメインD1-D2間のゲートウェイとしてはゲートウェイ１０８が存在するため、これを使用するように決定される。複数のゲートウェイが使用可能なときは、それらのうちの特定のゲートウェイを選択することによって負荷分散をはかることもでき、またIPルーティングのように経路が自動的に選択される方法を使用するときは自動選択にまかせることもできる。
（ドメイン間仮想リンクのためのVLANによるドメイン内設定)
つぎに、仮想リンクVL14のドメイン内部分すなわち仮想ノードVN1からゲートウェイ１０８までの部分を設定する。この設定においてはドメインD1において使用可能な仮想リンク実装法のなかから、ドメインD2とは独立に、また仮想リンクVL14のドメイン間部分とも独立に実装法を決定することができる。その実装法としてVLANを選択するときは、まず仮想ノードVN1のポートp2と仮想ノードVNPのポートp3のVLAN IDを一致させる。そのためには、ゲートキーパー１０７が、スライス情報５０１において仮想ノードVN1と対応している実ノードN11（１０３）にリンク設定要求２３１を送信し、実ノードN11（１０３）からリンク設定応答２３２を受信してVLAN IDを交渉する。VLAN IDとして１００を使用するときは、図１４の(a)に示すようにリンク設定要求２３１においてその値が指定される。図１４においてはリンク設定要求２３１において指定されたVLAN IDがそのまま使用されたため２回の通信でVLAN IDが決定されるが、実ノードN11（１０３）がその値の変更を要求するときは３回以上の通信が必要になる。

さらに、仮想リンクVL14を経由してVN1のポートp2にパケットを送信する際にはポートp2に対応するMACアドレスが、ゲートウェイ１０８が受信したパケットに受信者MACアドレスとして指定されるように(パケットが中継されるように)、ゲートウェイ１０８に第１の設定をおこなう。逆に仮想リンクVL14を経由してVNPが代表している仮想ノードVN4のポートp3'にパケットを送信する際には中継点である仮想ノードVNPのポートp3に対応するMACアドレスがパケットに受信者MACアドレスとして指定されるように、前記の実ノードN11（１０３）との通信においてMACアドレスを通知する。ゲートウェイ１０８側のMACアドレスがx.x.x.x.x.xでありN11側のMACアドレスがy.y.y.y.y.yであれば、図１４の(a)に示すようにリンク設定要求２３１に前者が指定され、図１４の(b)に示すようにリンク設定応答２３２に後者が指定される。

また、仮想リンクVL23のドメイン内部分すなわち仮想ノードVN2からゲートウェイ１０８までの部分を設定する。この設定においてはドメインD1において使用可能な仮想リンク実装法のなかから、ドメインD2とは独立に、また仮想リンクVL23のドメイン間部分とも独立に実装法を決定することができる。

その実装方法としてVLANを選択するときは、まず仮想ノードVN2のポートp1と仮想ノードVNPのポートp4のVLAN IDを一致させる。そのためには、ゲートキーパー１０７が、スライス情報５０１において仮想ノードVN2と対応している実ノードN12（１０４）にリンク設定要求２３３を送信し、実ノードN12（１０４）からリンク設定応答２３４を受信してVLAN IDを交渉する。VLAN IDとして「１０１」を使用するときは、図１４の(c)に示すようにリンク設定要求２３３においてその値が指定される。

さらに、仮想リンクVL23を経由してVN2のポートp1にパケットを送信する際にはポートp1に対応するMACアドレスが、ゲートウェイ１０８が受信したパケットに受信者MACアドレスとして指定されるように(パケットが中継されるように)、ゲートウェイ１０８に第２の設定をおこなう。逆に仮想リンクVL23を経由してVNPが代表している仮想ノードVN3のポートp4'にパケットを送信する際には中継点である仮想ノードVNPのポートp4に対応するMACアドレスがパケットに受信者MACアドレスとして指定されるように、前記の実ノードN12（104）との通信においてMACアドレスを通知する。ゲートウェイ１０８側のMACアドレスがz.z.z.z.z.zでありN12側のMACアドレスがu.u.u.u.u.uであれば、図１４の(c)に示すようにリンク設定要求２３３に前者が指定され、図１４の(d)に示すようにリンク設定応答２３４に後者が指定される。

上記の第１および第２の設定のために、ゲートキーパー１０７がゲートウェイ１０８にパス設定要求２４１を送信し、ゲートウェイ１０８からパス設定応答２４２を受信する。第１の設定におけるVLAN IDが１００、ゲートウェイ１０８側のMACアドレスがx.x.x.x.x.x、N12側のMACアドレスがy.y.y.y.y.y、第２の設定におけるVLAN IDが「１０１」、ゲートウェイ１０８側のMACアドレスがz.z.z.z.z.z、N12側のMACアドレスがu.u.u.u.u.uであるときのパス設定要求２４１の内容を図１５の(a)に示す。ゲートウェイ１０８がパス設定要求２４１を受信すると、この情報を使用してVLANパスを設定する。

ゲートウェイ１０８はパス設定要求２４１の受信時にゲートウェイ１０８のドメイン内-ドメイン間アドレス対応表９０１〜９０４の一部を生成する。すなわち、リンク名VL14およびVL23をキーとしてドメイン内-ドメイン間アドレス対応表９０１〜９０４のうちゲートウェイ１０８が使用しているものに旧VLAN IDおよび旧MACアドレスすなわち変換前のVLAN IDとMACアドレスと新VLAN IDおよび新MACアドレスすなわち変換後のVLAN IDとMACアドレスを格納する。

なお、上記の記述はドメインD1におけるスライス情報５０１の処理の場合のものだが、ドメインD2におけるスライス情報５０３の処理の場合には、ゲートキーパー１１７がゲートウェイ１１８にパス設定要求２４３を送信し、ゲートウェイ１０８からパス設定応答２４４を受信する。
（ドメイン間仮想リンクのためのIPトンネル(GRE等)によるドメイン内設定)
一方、仮想リンクVL14のドメイン内部分すなわち仮想ノードVN1からゲートウェイまでの部分においてインターネット・プロトコル上のトンネルたとえばGRE(Generic Routing Encapsulation)トンネルが使用可能であり、それを選択するときは、上記のVLAN IDの一致は必要ないが、ゲートキーパー１０７はVLAN IDのかわりにGREキー、MACアドレスのかわりにIPアドレスがパケットに指定されるようにゲートウェイ１０８への第１の設定をおこない、実ノードN11（１０３）との通信すなわちリンク設定要求２３１およびリンク設定応答２３２をおこなう。GREキーとして１０００を使用するときは、図１４の(e)に示すようにリンク設定要求２３１においてその値が指定される。ゲートウェイ１０８側のIPアドレスがx.x.x.xでありN11側のIPアドレスがy.y.y.yであれば、図１４の(e)に示すようにリンク設定要求２３１に前者が指定され、図１４の(f)に示すようにリンク設定応答２３２に後者が指定される。

また、仮想リンクVL23のドメイン内部分すなわち仮想ノードVN2からゲートウェイまでの部分においてインターネット・プロトコル上のトンネルを使用するときには、上記のVLAN IDの一致は必要ないが、ゲートキーパー１０７は、VLAN IDのかわりにGREキー、MACアドレスのかわりにIPアドレスがパケットに指定されるようにゲートウェイ１０８への第２の設定をおこない、実ノードN12（１０４）との通信すなわちリンク設定要求２３３およびリンク設定応答２３４をおこなう。GREキーとして１０００を使用するときは、図１４の(e)に示すようにリンク設定要求２３３においてその値が指定される。ゲートウェイ１０８側のIPアドレスがz.z.z.zでありN12側のIPアドレスがu.u.u.uであれば、図１４の(g)に示すようにリンク設定要求２３３に前者が指定され、図１４の(h)に示すようにリンク設定応答２３２に後者が指定される。

上記の第１および第２の設定のために、ゲートキーパー１０７がゲートウェイ１０８にパス設定要求２４１を送信し、ゲートウェイ１０８からパス設定応答２４２を受信する。第１の設定におけるGREキーが１０００、ゲートウェイ１０８側のIPアドレスがx.x.x.x、N11側のIPアドレスがy.y.y.y、第２の設定におけるGREキーが１００１、ゲートウェイ１０８側のIPアドレスがz.z.z.zでありN12側のIPアドレスがu.u.u.uであるときのパス設定要求２４１の内容を図１５の(b)に示す。ゲートウェイ１０８がパス設定要求２４１を受信すると、この情報を使用してGREトンネルを設定する。

ゲートウェイ１０８は、パス設定要求２４１の受信時にゲートウェイ１０８のドメイン内-ドメイン間アドレス対応表９０１〜９０４の一部を生成する。すなわち、リンク名VL14およびVL23をキーとしてドメイン内-ドメイン間アドレス対応表９０１〜９０４のうちゲートウェイ１０８が使用しているものに旧GREキーおよび旧IPアドレスすなわち変換前のGREキーとIPアドレスと新GREキーおよび新IPアドレスすなわち変換後のGREキーとIPアドレスを格納する。
（送信側ゲートキーパーのスライス情報変換）
つづいてステップ３０３において、ドメイン間依頼要求２１３の内容をフラット化する。すなわち、スライス情報５０１が入力されたときはスライス情報を標準スライス情報５０２の形に変換する。すなわち、仮想ノードVNPによって囲われていた仮想ノードVN3およびVN4をVNPの外に出し、VNPを消去する。
（受信側(ドメインD2)へのスライス情報の送信）
最後にステップ３０４において、ドメイン間依頼要求２１３の内容と自ドメイン側のドメイン間リンク情報を既定の他ドメインに転送する。具体的には、フラット化した標準スライス情報５０２をドメイン間依頼２１４にいれて相手ドメインのゲートキーパーに送信する。すなわち、ゲートキーパー１０７はゲートキーパー１１７に送信し、ゲートキーパー１１７はゲートキーパー１０７に送信する。この送信の際には、ドメイン間仮想リンクの実装情報を相手ドメインのゲートキーパーに送信する。すなわち、ドメイン間仮想リンクの実装のためにVLANを使用するときは、仮想リンクVL14およびVL23の付随情報としてそれらに対応するVLAN ID、仮想リンク終端のポート情報として仮想ノードVNPのポートp3に対応するMACアドレスと仮想ノードVNPのポートp4に対応するMACアドレスとをあわせて通知する。また、ドメイン間仮想リンクの実装のためにGREを使用するときは上記の各ポートに対応するIPアドレスを通知する。以上でドメイン内設定管理プログラム２０１の実行を終了する。
（受信側ゲートキーパーの処理）
図４は、ゲートキーパー１１７および１０７における受信側ドメイン間設定管理プログラム２０２の処理手順を示すフローチャートである。受信側ドメイン間設定管理プログラム２０２の実行が開始されると、まずステップ４０１において、再帰停止のための印付け/記録をおこなう。そのための具体的な方法については後述する。
（受信側ゲートキーパーにおけるドメイン間仮想リンク設定）
つづいて、ステップ４０２において、ドメイン間依頼に含まれる情報を使用して、ドメイン間リンクを設定する。具体的には、スライス情報５０２における仮想リンクVL14およびVL23に対応するパスの設定をおこなう。この設定においてはまずこのドメイン間リンクが通過するべきゲートウェイを決定する。ドメインＤ１−Ｄ２間のゲートウェイとしてはゲートウェイ１１８が存在するため、これを使用するように決定される。複数のゲートウェイが使用可能なときは、それらのうちの特定のゲートウェイを選択することによって負荷分散をはかることもでき、またＩＰルーティングのように経路が自動的に選択される方法を使用するときは自動選択にまかせることもできる。

つぎに、ドメイン間仮想リンクの実装方式を決定し、ゲートウェイ１０８とゲートウェイ１１８との間のパスを設定する。この設定においてはドメインD1−D2間で使用可能な仮想リンク実装法のなかから、ドメインD1内およびドメインD2内とは独立に実装法を決定することができる。
（VLANによるドメイン間仮想リンク設定）
仮想リンクVL14がVLANによって実現されるときは、自ドメイン(ドメインD2)内の仮想ノードVN4のポートp3のVLAN IDを、ドメイン間依頼２１４に含まれる相手ドメイン(ドメインD1)内のポートp1と一致させる。そのため、ゲートウェイ１０８に第１の設定をおこなう。さらに、仮想リンクVL14を経由して相手ドメイン内のポートp1にパケットを送信する際にはポートp1に対応するゲートウェイ１０８のMACアドレスがパケットに受信者MACアドレスとして指定されるように、ゲートウェイ１１８を設定する。すなわち、ゲートウェイ１１８を受信者としているパケットのヘッダを変換してゲートウェイ１０８に転送するように第３の設定をおこなう。このパケット・ヘッダ変換の方法については後述する。

また、仮想リンクVL23がVLANによって実現されるときは、自ドメイン(ドメインD2)内の仮想ノードVN3のポートp4のVLAN IDを、ドメイン間依頼２１４に含まれる相手ドメイン(ドメインD1)内のポートp2と一致させる。そのため、ゲートウェイ１０８に第２の設定をおこなう。さらに、仮想リンクVL23を経由して相手ドメイン内のポートp2にパケットを送信する際にはポートp2に対応するゲートウェイ１０８のMACアドレスがパケットに受信者MACアドレスとして指定されるように、ゲートウェイ１１８を設定する。すなわち、ゲートウェイ１１８を受信者としているパケットのヘッダを変換してゲートウェイ１０８に転送するように第４の設定をおこなう。

上記の第１〜第４の設定のために、ゲートキーパー１１７がゲートウェイ１１８にドメイン間パス設定要求２４５を送信し、ゲートウェイ１１８からドメイン間パス設定応答２４６を受信する。第１の設定におけるVLAN IDが１０２、MACアドレスがa.a.a.a.a.a、第２の設定におけるVLAN IDが１０３、MACアドレスがc.c.c.c.c.cであるときのドメイン間パス設定要求２４５の内容を図１５の(c)に示す。ゲートウェイ１１８がドメイン間パス設定要求２４５を受信すると、この情報を使用してVLANパスを設定する。

ゲートウェイ１１８は、パス設定要求２４３の受信時にゲートウェイ１１８のドメイン内-ドメイン間アドレス対応表９０１〜９０４の一部を生成する。すなわち、リンク名VL14およびVL23をキーとしてドメイン内-ドメイン間アドレス対応表９０１〜９０４のうちゲートウェイ１１８が使用しているものに旧VLAN IDおよび旧MACアドレスすなわち変換前のVLAN IDとMACアドレスと新VLAN IDおよび新MACアドレスすなわち変換後のVLAN IDとMACアドレスを格納する。
（IPトンネル(GRE等)によるドメイン間仮想リンク設定)
一方、仮想リンクVL14が、インターネット・プロトコル上のトンネルたとえばGREトンネルによって実現されるときには、上記のVLAN IDの一致は必要ないが、MACアドレスのかわりにIPアドレスがパケットに指定されるようにゲートウェイ１１８に第１の設定をおこなう。また、ゲートウェイ１１８を受信者としているパケットのヘッダを書き換えてゲートウェイ１０８に転送するように第３の設定をおこなう。また、仮想リンクVL23がインターネット・プロトコル上のトンネルによって実現されるときには、上記のVLAN IDの一致は必要ないが、VLAN IDのかわりにGREキー、MACアドレスのかわりにIPアドレスがパケットに指定されるようにゲートウェイ１１８に第２の設定をおこなう。また、ゲートウェイ１１８を受信者としているパケットのヘッダを書き換えてゲートウェイ１０８に転送するように第４の設定をおこなう。

上記の第１〜第４の設定のために、ゲートキーパー１１７がゲートウェイ１１８にパス設定要求２４３を送信し、ゲートウェイ１１８からパス設定応答２４４を受信する。第１の設定におけるGREキーが１００２、ゲートウェイ１１８側のIPアドレスがa.a.a.a、ゲートウェイ１０８側のIPアドレスがb.b.b.b、第２の設定におけるGREキーが１００３、ゲートウェイ１１８側のIPアドレスがc.c.c.c、ゲートウェイ１０８側のIPアドレスがd.d.d.dであるときのドメイン間パス設定要求２４５の内容を図１５の(d)に示す。ゲートウェイ１１８がドメイン間パス設定要求２４５を受信すると、この情報を使用してGREトンネルを設定する。

ゲートウェイ１１８は、パス設定要求２４１の受信時にゲートウェイ１１８のドメイン内-ドメイン間アドレス対応表９０１〜９０４の一部を生成する。すなわち、リンク名VL14およびVL23をキーとしてドメイン内-ドメイン間アドレス対応表９０１〜９０４のうちゲートウェイ１１８が使用しているものに旧GREキーおよび旧IPアドレスすなわち変換前のGREキーとIPアドレスと新GREキーおよび新IPアドレスすなわち変換後のGREキーとIPアドレスを格納する。
(受信側ゲートキーパーのスライス情報変換)
更に、ステップ４０３において、ドメイン間依頼の内容を階層化する。階層化する際には疑似ノード名をスライス定義に挿入する必要があるが、ここで使用する疑似ノード名は疑似ノード表８０１からもとめる(疑似ノード表８０１については後述する)。すなわち、ドメインD1に対応する仮想ノード名を決定し(VNQとする)、仮想ノードVN1およびVN2を仮想ノードVNQによって囲う。
(ネットワーク管理サーバへのスライス情報の送信)
最後にステップ４０４において、ドメイン間依頼の内容をNM112に転送する。具体的には、階層化した標準スライス情報５０１をスライス要求２１５にいれて自ドメインのネットワーク管理サーバ１１２に送信する。以上で受信側ドメイン間設定管理プログラム２０２の実行を終了する。
（送信側（ドメインD1）ゲートキーパーの処理2/2））
（送信側ゲートキーパーにおけるドメイン間仮想リンク設定）
図８は、ゲートキーパー１１７および１０７における送信側ドメイン間設定管理プログラム２０３の処理手順を示すフローチャートである。送信側ドメイン間設定管理プログラム２０３の実行が開始されると、ステップ８０１において、ドメイン間依頼応答に含まれる情報を使用して、ドメイン間リンクを設定する。具体的には、スライス情報５０２における仮想リンクVL14およびVL23に対応するドメイン間のパスの設定をおこなう。ゲートウェイとしてはすでにゲートウェイ１１８が選択されているため、これを使用する。
（VLANによるドメイン間仮想リンク設定）
仮想リンクVL14がVLANによって実現されるときは、自ドメイン(ドメインD1)内の仮想ノードVN2のポートp1のVLAN IDを、ドメイン間依頼応答２２４に含まれる相手ドメイン(ドメインD2)内のポートp3と一致させる。そのため、ゲートウェイ１０８に第１の設定をおこなう。さらに、仮想リンクVL14を経由して相手ドメイン内のポートp3にパケットを送信する際にはポートp3に対応するゲートウェイ１１８のMACアドレスがパケットに受信者MACアドレスとして指定されるように、ゲートウェイ１０８を設定する。すなわち、ゲートウェイ１０８を受信者としているパケットのヘッダをかきかえてゲートウェイ１１８に転送するように第３の設定をおこなう。

また、仮想リンクVL23がVLANによって実現されるときは、自ドメイン(ドメインD1)内の仮想ノードVN1のポートp2のVLAN IDを、ドメイン間依頼応答２２４にふくまれる相手ドメイン(ドメインD2)内のポートp3と一致させる。そのため、ゲートウェイ１０８に第２の設定をおこなう。さらに、仮想リンクVL23を経由して相手ドメイン内のポートp3にパケットを送信する際にはポートp3に対応するゲートウェイ１０８のMACアドレスがパケットに受信者MACアドレスとして指定されるように、ゲートウェイ１０８を設定する。すなわち、ゲートウェイ１０８を受信者としているパケットのヘッダをかきかえてゲートウェイ１１８に転送するように第４の設定をおこなう。

上記の第１〜第４の設定のために、ゲートキーパー１１７がゲートウェイ１１８にドメイン間パス設定要求２４５を送信し、ゲートウェイ１１８からドメイン間パス設定応答２４６を受信する。また、ゲートウェイ１１８はパス設定要求２４１の受信時にゲートウェイ１１８のドメイン内-ドメイン間アドレス対応表９０１〜９０４の一部を生成する。
（IPトンネル(GRE等)によるドメイン間仮想リンク設定）
一方、仮想リンクVL14がインターネット・プロトコル上のトンネルたとえばGREトンネルによって実現されるときには、上記のVLAN IDの一致は必要ないが、MACアドレスのかわりにIPアドレスがパケットに指定されるようにゲートウェイ１０８に第１の設定をおこなう。また、ゲートウェイ１０８を受信者としているパケットのヘッダをかきかえてゲートウェイ１１８に転送するように第４の設定をおこなう。

仮想リンクVL23がインターネット・プロトコル上のトンネルによって実現されるときには、上記のVLAN IDの一致は必要ないが、MACアドレスのかわりにIPアドレスがパケットに指定されるようにゲートウェイ１０８に第２の設定をおこなう。また、ゲートウェイ１０８を受信者としているパケットのヘッダをかきかえてゲートウェイ１１８に転送するように第３の設定をおこなう。

上記の第１〜第４の設定のために、ゲートキーパー１１７がゲートウェイ１１８にパス設定要求２４３を送信し、ゲートウェイ１１８からパス設定応答２４４を受信する。また、ゲートウェイ１０８はパス設定要求２４１の受信時にゲートウェイ１０８のドメイン内-ドメイン間アドレス対応表９０１〜９０４の一部を生成する。
（無限再帰の停止）
以下、ドメイン間通信の無限再帰を停止させる方法について、すなわちステップ４０１およびステップ３０１について詳細に説明する。前記の説明のように、ゲートキーパー１１７は、ドメイン内設定管理処理３０１においてスライス情報をドメインD1に転送する必要がないことを判定するが、この判定がおこなわれないと仮定するとスライス情報はドメインD1に転送され、すでにドメインD1への設定は完了しているにもかかわらず再度、設定が実行される。それだけでなく、スライス情報はさらにドメインD2に転送され、ドメインD1−D2間の転送が無限にくりかえされる。このような無限再帰を停止させ、重複した設定がおこなわれないようにするための３つの方法を、図１２を用いて説明する。

いずれにおいても、管理メッセージ１２０１は種別１２０２、スライス情報１２０３、付加情報１２０４から構成される。種別１２０２は、管理メッセージ１２０１の種別をあらわす。スライス生成のための管理メッセージにおいては種別１２０２が「スライス生成」を意味する値を含む。付加情報１２０４の既定値は空または０だが、無限再帰を停止させるために以下のように空または０でない値を含むことがある。図１２の(a)においては付加情報１２０４がスライス情報１２０３とは独立にあたえられているが、付加情報１２０４をスライス情報１２０３の内部にいれることも可能である。
（識別子による方法）
第１の方法は、スライス情報に含まれるスライス識別子やメッセージに含まれるオーダ識別子(要求識別子)を記録して利用する方法である。この方法においてはステップ４０１において、ゲートキーパー１１７が他ドメインから受取った管理メッセージに含まれる識別情報をゲートキーパー１１７がもつ内部データベース(主記憶上のテーブルなど)または外部データベース(関係データベースなど)に記録する。また、ステップ３０１においてゲートキーパー１１７が自ドメインの疑似ノード１１５から管理メッセージを受取ると、その管理メッセージに含まれるスライス情報が含む識別情報をキーとして上記のデータベースが含む識別情報を検索する。その結果、同一の識別情報がみつからないとその管理メッセージは自ドメインから送信したものだと判定するが、同一の識別情報がみつかったときは自ドメインから送信したものではないと判定する。そのため、自ドメインから送信された管理メッセージはNM（１１２）にわたされず、無限再帰を防止することができる。この方法を使用すれば、第１、第２の方法のように適用可能なネットワーク構成が制限されることはない。

スライスごとに１回だけ実行される処理たとえばスライスの初期定義などに関しては、識別情報としてスライス名を使用することができる。ただし、これを識別子として使うためには、スライス識別子が全ドメインで一意に決められる必要がある。NM１１２、NM１０２がスライス名をそのままのかたちで扱うときは検索の際に単純に比較すればよい。しかし、NM１１２、NM１０２がスライス名を書き換えるときは、ゲートキーパー１１７、１０７はその書き換え方法にしたがってデータベースが含むスライス名を書換えたものを管理メッセージが含むスライス名と比較する必要がある。たとえば、NM１１２、NM１０２がスライス名にドメイン名を接頭辞として加えることが考えられるが、この場合は比較前にデータベースが含むスライス名にドメイン名をくわえる、もしくは管理メッセージが含むスライス名から接頭辞をとりさる。

スライスごとに複数回、実行される処理たとえばスライスの変更定義などに関しては、識別情報としてオーダ識別子を使用することができる。ただし、これを識別子として使うためには、第１にオーダ識別子が全ドメインで一意に決められる必要がある。第２にメッセージが転送される際にオーダ識別子が保存される必要がある。

スライス名のような確実な識別情報が利用できないときは、つぎのような方法をとることも可能である。すなわち、他ドメインから管理メッセージを受信した際にはスライス情報のすべてを記録し、疑似ノード１１５から管理メッセージを受信したときは、受信したスライス情報と記録されたスライス情報の類似度が一定値以上かどうかをみることができる。ただし、この方法は確実性がないため、後述するカウンタ(第３の方法)のような方法と併用することが望ましい。
（マーキングによる方法）
第２の方法は、管理メッセージへの印づけ（(マーキング)をおこなう方法である。この方法においてはステップ４０１において、ゲートキーパー１１７が他ドメインからうけとった管理メッセージに印づけしてNM１１２にわたす。また、ステップ３０１においてゲートキーパー１１７が自ドメインの疑似ノード１１５から印のない管理メッセージを受取るとそれは廃棄するべきものだと判定するが、印づけされた管理メッセージをうけとったときは廃棄するべきものではないと判定する。そのため、自ドメインから送信された管理メッセージはNM１１２にわたされず、無限再帰を防止することができる。

印付け次のようにすればよい。すなわち、管理メッセージに０(false)または１(true)を意味する１ビットの情報をうめこむ。管理メッセージがXMLによって記述されているときは、図１２の(b)のマーキング用付加情報１２０４Ａまたは図１２の(c)のマーキング用付加情報１２０４Ｂをふくむ。

第１の方法はもっとも単純だが、他ドメインからとどいた情報は第２の他ドメインには転送されない。そのため、３個以上のドメインが数珠つなぎになっているときは適用できない。
（カウンタ(TTL)による方法)
第３の方法は管理メッセージにカウンタを組み込む方法である。この方法においてはステップ４０１において、ゲートキーパー１１７が他ドメインからうけとった管理メッセージにふくまれるカウンタをカウント・アップしてNM１１２にわたす。もしカウンタがふくまれないときは、初期値(0)をふくむカウンタを挿入する。また、ステップ３０１においてゲートキーパー１１７が自ドメインの疑似ノード１１５からカウンタが一定値以上の管理メッセージをうけとるとそれは廃棄するべきものだと判定するが、印づけされた管理メッセージをうけとったときは廃棄するべきものではないと判定する。

カウンタは次のように実現すればよい。すなわち、初期値を０(または空文字列"")とし、ゲートキーパー１１７および１０７を通過するたびにカウントアップする(1、2、3、…のように、または図１２の12(d)の1204C、図１２の（ｅ）の1204Dのように、またはカウントダウンする。

第２の方法の利点はあらかじめきめられた回数の再帰を許容することができるため、数珠つなぎのようなネットワーク構成にも対応することができる。すなわち、ステップ３０１においてカウンタの値が指定値を超えてきているかどうか(または０になったかどうか)を判定するようにすれば、指定回数までの反復を許容することができる。しかし、数珠つなぎのときは数珠の数に上限がある。
（疑似ノードの選択）
以下、ステップ４０３における疑似ノードの選択および疑似ノード表７０１について説明する。ゲートキーパー１１７は、スライス情報５０２を受信し、それをスライス情報５０３に変換する。その際に、ステップ４０３において、スライス情報５０３に挿入する疑似ノード名を選択する必要がある。そのために使用する疑似ノード表７０１について図７を使用して説明する。疑似ノード表７０１にはドメインD2に隣接するドメインD1、D2に対応する疑似ノードがそれぞれP21（１１５）、P22（１１６）であることが記録されている。疑似ノード表７０１はネットワーク構成を決定する際に生成する。ステップ４０３において疑似ノード表７０１を使用することによって、管理メッセージがドメインD1から届いたときは仮想ノードVNQに対応する疑似ノードをP21（１１５）とし、管理メッセージがドメインD3から届いたときは仮想ノードVNQに対応する疑似ノードをP22（116）とする。
（シーケンスの補足２）
図２を使用して説明した設定・管理操作のシーケンスを、更に図１６、図１７を使用して補足する。図１６は、スライス要求２１１からスライス要求２１５までの流れを表す。すなわち、コンソール１０１から入力したスライス定義５０１を含むメッセージが投入され、物理ノードと疑似ノードに共通のAPI(プロトコル)によって配布され、スライス定義の変換を経てNM（１１２）に到達する。図１７は、スライス要求２１５からドメイン間依頼要求２１７までの流れを表す。スライス要求２１５が含むスライス定義５０３は図１７の右側に記述されているとおりだが、これがNM（１１２）から物理ノードと疑似ノードに共通のAPI(プロトコル)によって配布される。

図１８は、無限再帰を停止させるステップを含まないプログラムを使用したときに設定・管理操作において発生しうる無限再帰を記述している。設定・管理メッセージはNM（１０２）から疑似ノード１０５、ゲートキーパー１０７、ゲートキーパー１１７、ドメイン管理１１２、疑似ノード１１５、ゲートキーパー１１７の順で転送されるが、無限再帰を停止させるステップがなければさらにゲートキーパー１０７、NM１０２に転送される。この転送は無限に繰り返されうる。

図１９は、図２に示した設定・管理操作のシーケンスと、その間に生成される仮想リンクVL14に対応するドメイン間パスとの関係をあらわしている。この過程において、ゲートキーパー１０７からゲートウェイ１０８への設定と、ゲートキーパー１０７と物理ノードN11（１０３）との通信によってVL14のドメインD１内部分が生成される。また、ゲートキーパー１０７からゲートウェイ１０８への設定と、ゲートキーパー１１７からゲートウェイ１１８への設定とによってVL14のドメインD1-D2間部分が生成される。さらに、ゲートキーパー１１７からゲートウェイ１１８への設定と、ゲートキーパー１１７と物理ノードN21（１１５）との通信によってVL14のドメインD2内部分が生成される。

101、111 オペレータ・コンソール
102、112 ネットワーク管理サーバ(NM)
103、104、113、114 ネットワーク・ノード(物理ノード)
105、106、115、116 疑似ノード
107、117 ゲートキーパー(GK)
108、109、110、118、119、120 ゲートウェイ
201 ドメイン内設定管理プログラム
202 受信側ドメイン間設定管理プログラム
203 送信側ドメイン間設定管理プログラム
1321 物理ネットワーク
1322、1323、1324、1325 スライス
1301 物理ノード
1302、1303、1304 仮想ノード
501、502、503、601、602、603 スライス情報
211、215 スライス要求
212、216 ノード/リンク要求
213、217 ドメイン間依頼要求
214 ドメイン間依頼
1201 管理メッセージ
1202 管理メッセージの種別
1203 管理メッセージのスライス情報
1204 管理メッセージの付加情報
241、243 パス設定要求
242、244 パス設定応答
245、247 ドメイン間パス設定要求
246、248 ドメイン間パス設定応答
221 ドメイン間依頼要求応答
235、237 リンク設定要求
236、238 リンク設定応答
222 ノード/リンク要求応答
223 スライス要求応答
224 ドメイン間依頼応答
225 ドメイン間依頼要求応答
226 ノード/リンク要求応答
227 スライス要求応答
901、902、903、904 ドメイン内-ドメイン間アドレス対応表
701 疑似ノード表。

Claims (14)

1. 第１ネットワーク・ドメインと、第２ネットワーク・ドメインと、前記第２ネットワーク・ドメインに関するドメイン設定管理情報を前記第２ネットワーク・ドメインの外部から受信して前記第２ネットワーク・ドメインに属するノードの設定を行う連携システムから構成されるネットワークシステムの管理方法であって、
   前記第１ネットワーク・ドメインは、複数のノードと、第２ネットワーク・ドメインとの連携のための疑似ノードおよびゲートキーパーと、前記複数のノードと前記疑似ノードとを管理する第１管理ノードを有しており、
   前記第１管理ノードは、前記第１ネットワーク・ドメインに接続されたコンソールから、前記複数のノードのノード設定情報を含む第１ドメイン設定管理情報を受信し、かつ、前記第１ドメイン設定管理情報を前記複数のノードに送信し、
   前記複数のノードのそれぞれは、前記第１ドメイン設定管理情報に含まれる前記ノード設定情報に従って設定を行い、
   ここで、前記第１ドメイン設定管理情報は、前記疑似ノードに関する第２ノード設定情報を含んでおり、前記第２ノード設定情報は前記疑似ノードの識別情報を含んでおり、更に、前記第２ノード設定情報は、前記第２ネットワーク・ドメインに関する第２ドメイン設定管理情報を有しており、
   前記第１管理ノードが、前記第１ドメイン設定管理情報を前記疑似ノードに送信し、
   前記疑似ノードが、前記第２ノード設定情報を前記ゲートキーパーに送信し、前記ゲートキーパーは前記第２ノード設定情報から前記疑似ノードの識別情報を除外した情報を前記連携システムに送信し、
   前記連携システムが、前記第２ドメイン設定管理情報を用いて、前記第２ネットワーク・ドメインに属するノードの設定を行うことを特徴とするネットワークシステムの管理方法。
2. 請求項１記載のネットワークシステムの管理方法であって、前記疑似ノードが、前記疑似ノードに関するノード設定情報を前記ゲートキーパーに送信する際、前記第１ネットワーク・ドメインに関する前記第１ドメイン設定管理情報から前記疑似ノードのノード設定管理情報を除外したものを、合わせて送信することを特徴とするネットワークシステムの管理方法。
3. 請求項１記載のネットワークシステムの管理方法であって、
   前記ゲートキーパーが、前記連携システムから前記第１ネットワーク・ドメインの第２ドメイン設定管理情報を受信したとき、前記第２ドメイン設定管理情報を前記第１管理ノードに送信することによって前記第１ネットワーク・ドメインへの制御・管理をおこなうことを特徴とするネットワークシステムの管理方法。
4. 請求項３記載のネットワークシステムの管理方法であって、
   前記疑似ノードが前記連携システムから前記第１ネットワーク・ドメインの第２ドメイン設定管理情報と前記第２ネットワーク・ドメインの第３ドメイン設定管理情報とを受信したとき、前記第３ドメイン設定管理情報に前記疑似ノードの識別情報を付加して前記疑似ノードの設定管理情報とすることによって、第２ネットワーク・ドメインのネットワーク・ノードに関する情報を含まない形に変換して前記第１管理ノードに送信することを特徴とするネットワークシステムの管理方法。
5. 請求項１記載のネットワークシステムの管理方法であって、
   前記第１ドメイン設定管理情報が前記複数ネットワーク・ノードと前記疑似ノードとの間のリンク情報を含み、前記ゲートキーパーは前記リンク情報にしたがってゲートウェイに指示を送信することにより前記第１ネットワーク・ドメインと前記第２ネットワーク・ドメインとの間のリンクを生成することを特徴とするネットワークシステムの管理方法。
6. 請求項５記載のネットワークシステムの管理方法であって、
   前記第１ドメイン設定管理情報が仮想ネットワークの仮想ノードおよび仮想リンクを生成・管理する情報を含み、前記のリンク情報がドメイン間仮想リンクを生成・管理する情報であり、
   前記第１ネットワーク・ドメインと前記第２ネットワーク・ドメインとの間のリンク生成によって前記ドメイン間仮想リンクのための通信設定を行うことによって前記第１ネットワーク・ドメインと前記第２ネットワーク・ドメインにまたがる仮想ネットワークを生成・管理することを特徴とするネットワークシステムの管理方法。
7. 請求項３記載のネットワークシステムの管理方法であって、
   前記疑似ノードが前記連携システムから前記第１ネットワーク・ドメインの第２ドメイン設定管理情報を受信したとき、
   前記第２ドメイン設定管理情報が前記第１ドメイン設定管理情報と同定されないとき、前記第２ドメイン設定管理情報を前記第１管理ノードに送信することを特徴とするネットワークシステムの管理方法。
8. 請求項７記載のネットワークシステムの管理方法であって、
   前記疑似ノードが前記第２ドメイン設定管理情報を受信すると前記第２ドメイン設定管理情報の識別子を記憶し、前記第１ドメイン設定管理情報を受信した際に前記第１ドメイン設定管理情報と前記記憶した識別子と照合し、両者が一致したときに前記第２ドメイン設定管理情報と前記第１ドメイン設定管理情報とを同定することを特徴とするネットワークシステムの管理方法。
9. 請求項７記載のネットワークシステムの管理方法であって、
   前記疑似ノードが前記第１ドメイン設定管理情報を受信すると前記第２ドメイン設定管理情報の識別子を記憶し、第２ドメイン設定管理情報を受信した際に前記第２ドメイン設定管理情報と前記記憶した識別子と照合し、両者が一致したときに前記の第２ドメイン設定管理情報と前記の第１ドメイン設定管理情報とを同定することを特徴とするネットワークシステムの管理方法。
10. 請求項７記載のネットワークシステムの管理方法であって、
    前記疑似ノードが前記第１ドメイン設定管理情報を受信すると前記第１ドメイン設定管理情報に印づけし、前記第２ドメイン設定管理情報を受信すると印付けされていないとき前記第２ドメイン設定管理情報を前記第１管理ノードに送信することを特徴とするネットワークシステムの管理方法。
11. 請求項７記載のネットワークシステムの管理方法において、
    前記疑似ノードが前記第２ドメイン設定管理情報を受信すると前記第２ドメイン設定管理情報に印づけし、前記第１ドメイン設定管理情報を受信すると印づけされていないとき前記第２ドメイン設定管理情報を前記第１管理ノードに送信することを特徴とするネットワークシステムの管理方法。
12. 請求項３のネットワークシステムの管理方法において、
    前記疑似ノードが前記第１ドメイン設定管理情報を受信すると前記の第２ドメイン設定管理情報に一定値をふくむカウンタを追加し、ドメイン設定管理情報が前記の第１ネットワーク・ドメインおよび前記の第２ネットワーク・ドメインを通過するごとに前記のカウンタがカウント・ダウンされるように構成し、
    前記の疑似ノードが前記の第２ドメイン設定管理情報を受信すると前記の第２ドメイン設定管理情報がふくむ前記のカウンタをカウント・アップし、前記の第１ドメイン設定管理情報を受信すると前記のカウンタが一定値をこえないときにかぎって前記の第２ドメイン設定管理情報を前記の第１管理ノードに送信することを特徴とするネットワークシステムの管理方法。
13. 請求項１記載のネットワークシステムの管理方法であって、
    前記第1ドメイン設定管理情報が前記疑似ノードのノード設定管理情報を含み、前記疑似ノードのノード設定管理情報は前記第２ネットワーク・ドメインに関する第２ドメイン設定管理情報を含み、前記疑似ノードが前記ゲートキーパーに前記第１ドメイン設定管理情報を転送し、前記ゲートキーパーが前記第１ドメイン設定管理情報を受信すると前記第２ドメイン設定管理情報を前記第２ネットワーク・ドメインに送信することを特徴とするネットワークシステムの管理方法。
14. 請求項１３記載のネットワークシステムの管理方法であって、
    前記第１および第２ネットワーク・ドメインのほかに第３ネットワーク・ドメインが存在し、第３ネットワーク・ドメインに対応する第２疑似ノードが存在するとき、
    前記ゲートキーパーが前記第１ネットワーク・ドメインの第２ドメイン設定管理情報を受信したとき、
    前記第２ドメイン設定管理情報を前記連携システムから受信したときは前記第２ドメイン設定管理情報を前記疑似ノードの設定管理情報とし、前記第３ネットワーク・ドメインの第２の連携システムから受信したときは前記第２ドメイン設定管理情報を前記第２疑似ノードの設定管理情報とすることを特徴とするネットワークシステムの管理方法。

Images