JP2002237835A

JP2002237835A - データ・ネットワークにおけるサービス配備

Info

Publication number: JP2002237835A
Application number: JP2001256093A
Authority: JP
Inventors: Robert Haas; ロベルト・ハース; Patrick Droz; パトリック・ドロツ
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2000-09-01
Filing date: 2001-08-27
Publication date: 2002-08-23
Anticipated expiration: 2021-08-27
Also published as: CN1242336C; CN1340767A; DE60143147D1; KR20020018559A; SG101997A1; JP3584978B2; KR100462140B1

Abstract

(57)【要約】（修正有）【課題】複数のネットワーク・ノードを含むデータ・
ネットワークにおいてサービス割振り方針に従ってサー
ビスを配備する方法を提供する。【解決手段】割振り方針によって、サービスの配備の
ためのノードの選択が規定される。この方法は、この方
法は、ネットワーク・ノードを含む最下層と、各層にお
いて前の層のノードのグループがそれぞれの論理ノード
によって表された１つまたは複数の漸進的に高くなる層
とを有するサービス配備階層を定義するステップを含
む。この方法は、配備するサービスを指定するサービス
配布コマンドを生成するステップも含む。サービス配布
コマンドは、割振り方針と共に、階層のより上位の層の
論理ノードから階層のより下位の層または各下位層に供
給される。サービス配布コマンドで指定されたサービス
は、割振り方針に従って選択されたネットワーク・ノー
ドに自動的に導入される。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般にはデータ・
ネットワークにおけるサービス配備に関し、詳細には複
数のノードを含む異種データ・ネットワークにおけるサ
ービス配備に関する。

【０００２】

【従来の技術】データ・ネットワークにおいて一般的に
配備されるサービスには、ネットワークのうちの選択さ
れたノードが関与するルーティング・サービスと、ネッ
トワーク全体にわたるエンド・ツー・エンドサービスと
がある。ディフ・サーブ（diff-serv）方式は、データ
・ネットワークで配備されるサービスの一例である。一
般的なディフ・サーブ方式では、ネットワーク提供者が
複数のレベルのネットワーク・サービスを提供し、各サ
ービスに異なる料金が付随する。その場合、ネットワー
クのユーザは、ユーザが必要とするサービスのレベルに
付随する料金を支払う。周知のディフ・サーブの一例で
は、ネットワーク・アクセスに割増料金を支払う顧客の
データ・トラフィックに対して、より低額のネットワー
ク・アクセス料金を支払う顧客のデータ・トラフィック
より優先させるトランスポート優先権を与える。データ
通信が成長し続けるにつれて、ネットワークがますます
混雑するため、ディフ・サーブの需要が増えている。一
般にはネットワーク提供者、特にインターネット・サー
ビス提供者では、集客のためにディフ・サーブ・サービ
スを提供しようという要望がますます増大している。し
かし、インターネットのような大規模データ・ネットワ
ークで、ディフ・サーブや将来の他のサービスを配備す
る問題の好都合な解決策は現在のところまだない。

【０００３】従来のデータ・ネットワークでは、サービ
スは手作業で配備される。これには一般に、新しいサー
ビスを導入したいときに、ネットワーク内の各ノードで
新しい構成コマンド・セットまたは更新プログラム・コ
ード・セットを入力する必要がある。このような手動更
新は、ネットワーク運営者にとって手間と時間がかか
り、誤りを犯しやすい作業である。

【０００４】多くの従来のデータ・ネットワークは、ネ
ットワークを介したネットワーク内の各ノードへの接続
を有する中央ネットワーク・マネージャを含む。ネット
ワーク・マネージャは一般に、ネットワークに接続され
た専用コンピュータを含む。このコンピュータは、特別
なネットワーク管理ソフトウェアによってプログラムさ
れている。このようなネットワーク管理ソフトウェアの
例としては、ヒューレット・パッカードが販売するオー
プン・ビュー（Open View）ソフトウェア、チボリ・シ
ステムズが販売するネット・ビュー（Net View）ソフト
ウェア、シスコ・システムズが販売するシスコワークス
（CiscoWorks）などがある。通例、ネットワーク内の各
ノードは、ネットワーク・マネージャと協調するエージ
ェント・ソフトウェアを有する。ネットワーク・マネー
ジャとエージェントとの双方向通信によって、管理され
るネットワークに属するノードを、そのネットワーク管
理プラットフォーム特有の方法で制御することが可能に
なる。しかし、このような制御は、被管理ネットワーク
におけるサービスの配備にまでは及ばない。また、従来
のネットワーク・マネージャとそのエージェントは、拡
張可能ではない。要するに、従来のネットワーク管理シ
ステムは、大規模な異種ネットワーク全体にわたってサ
ービスを配備するのに適していない。

【０００５】プライベート・ネットワーク・ツー・ネッ
トワーク・インタフェース（Private Network to Netwo
rk Interface:ＰＮＮＩ）など、比較的最近に導入され
たルーティング・プロトコルの中には、ネットワーク内
の各ノードを手動で構成せずとも、ネットワーク内のエ
ンド・ツー・エンド接続対応ＱｏＳ（Quality of Servi
ce）の自動設定がある程度まで可能なものもある。ま
た、アクティブ・ネットワーク・エンカプスレーション
・プロトコル（Active Nework Encapsulation Protoco
l）などのプロトコルは、ネットワーク内を移動するパ
ケットが、ネットワーク内で通過する各ノードにサービ
スをロードしたりロードを試みたりする、パケット方式
の手法によりサービスを配備する。このパケット方式の
手法が正常に動作するには、以下の条件に依存する。す
なわち、Ｉ）ネットワーク内の各ノードすべてが、ネットワーク
を移動するパケットにより搬送されるコードを実行する
ことができるという意味でネットワークが同種であるこ
とと、ＩＩ）ネットワーク内の各ノードが所望のサービスを実
行することができることである。

【０００６】実際には、これらの条件は必ずしも満たさ
れない。コードの入手、コードの実行、またはサービス
のサポートを行うことができないノードは、パケットを
廃棄するか、または次のノードに転送する。これは明ら
かに望ましくない。パケット方式の手法の例の中には、
構成コードをパケットには組み込まない例もある。その
代わりに、ネットワークのノードは、中央コード・リポ
ジトリまたは分散データベースに照会することによっ
て、または必要なコードをすでにダウンロードしている
ノードに照会することによって、新しい構成プログラム
・コードを入手するする必要がある。このような照会
は、ネットワークに追加のトラフィック、遅延、複雑さ
を生じさせる。パケット方式の手法は、比較的多数のデ
ータ・ネットワーキング・アプリケーションでのサービ
スの配備には適さない。たとえば、パケット方式の手法
は、ホップごとのルーティングが行われるネットワーク
でのサービスの配備には適さない。そのようなネットワ
ークでは、パケットの流れが常に同じノードを通過する
という保証がないためである。インターネットは、ホッ
プごとのルーティングが行われるネットワークの例であ
る。

【０００７】

【発明が解決しようとする課題】「Spawing Networks」
(IEEE Network Magazine１９９９年７／８月号)で、キ
ャンベル（Campbell）等は、分散オブジェクト技法と中
央プロファイル・データベースとに基づいて仮想ネット
ワーク・アーキテクチャを自動的に配備する高度な方法
を提案している。「Virtual Active Networks - Safe a
nd Flexible Environments for Customer-Managed Serv
ices」（１９９９年１０月スイスチューリヒ開催の第
１０回IFIP/IEEE International Workshop on Distribu
ted Systems（DSOM'99）議事録）では、ブルンナー（Br
uner）等が、異なる仮想アクティブ・ネットワーク（Ｖ
ＡＮ）において配備されたサービスを分離する枠組みを
開示している。しかし、ＶＡＮの構築には手動作業が残
っている。アクティブ・ネットワークは一般に、前述の
パケット方式配備手法を使用する。この手法は、予測可
能な調整されたサービス配備が望ましい異種ネットワー
クでのサービス配備には適さない。異種ネットワーク
と、異種ネットワーク内の非アクティブ・ホップ間のリ
ンクのための抽象化については、バルガバン（Bharghav
an）等が「A Scalable Architecture for Active Netwo
rks」（ＯＰＥＮＡＲＣＨ２０００、２０００年３月
イスラエルテルアビブ）で述べている。インターネッ
ト・プロトコル（ＩＰ）および非同期転送モード（ＡＴ
Ｍ）ネットワークでは、階層構造を使用してルーティン
グ情報の収集と伝播を行う。ＩＰネットワークは、ルー
ティング情報を収集するに過ぎない。しかし、ＡＴＭ
ＰＮＮＩは、帯域幅および遅延特性も集約して、ＱｏＳ
ルーティングを可能にする。「Transition Matrix Gene
ration for Complex Node Representation」（１９９９
年５月日本高知開催のIEEE ATM Workshop議事録ｐ４
８９〜５００）では、イリアディス等がネットワーク階
層の下層のノードの特性を収集する複合ノード表現につ
いて記載している。「An Approach to Hierarchical Ne
twork Managemetn Architecture Basedon SNMPv2」（Sm
artnet'99 第５回IFIP Conference on Intelligence i
n Networks、１９９９年１１月タイ）では、シャオ等
が、階層構造を使用して多数のノードと共にスケーリン
グする分散ネットワーク管理方式について記載してい
る。比較的大規模な異種データ・ネットワーク全体に柔
軟性のある方式でサービスを都合よく編成し、自動的に
配備する問題のスケーラブルな解決策を提供することが
望ましいであろう。

【０００８】

【課題を解決するための手段】本発明によると、複数の
ネットワーク・ノードを含むデータ・ネットワークにお
いて、サービスの配備のためのノードの選択を規定する
サービス割振り方針に従ってサービスを配備する方法で
あって、ネットワーク・ノードを含む最下層と各層にお
いて前の層のノードのグループがそれぞれの論理ノード
によって表された１または複数の漸進的に高くなってい
く層とを有するサービス配備階層を規定するステップ
と、配備するサービスを指定するサービス配布コマンド
を生成するステップと、階層のより上位の層の論理ノー
ドから階層のより下位の各層のノードに、サービス配布
コマンドを割振り方針と共に供給するステップと、割振
り方針に従って選択されたネットワーク・ノードにサー
ビス配布コマンドで指定されたサービスを自動的に導入
するステップとを含む方法が提供される。

【０００９】この方法は、階層のより上位の層の論理ノ
ードから階層のより下位の層のネットワーク・ノード
に、配備するサービスの要件を示すサービス請求を供給
するステップと、サービス請求を各ネットワーク・ノー
ドの機能と比較して、ノードが配備するサービスをサポ
ートする能力を示すメトリクスを生成するステップと、
メトリクスを集約して階層の次のレベルアップのために
集約されたメトリクスを生成し、連続した層のために集
約ステップを繰り返すステップと、上位層において集約
されたメトリクスに基づいて配布コマンドを生成するス
テップとさらに含むことが好ましい。

【００１０】本発明の好ましい実施形態では、この方法
は、選択されたノードのうちの１つまたは複数のノード
を表す論理ノードにおいて情報を維持してサービスの動
的再配備を可能にするステップを含む。

【００１１】集約ステップは、１または複数の階層にお
ける異なるノードグループのための異なる集約手続きを
含むことが好ましい。

【００１２】本発明を別の観点から見ると、複数のノー
ドを含むネットワーク・システムであって、前記サービ
ス配備方法を実行するように構成されたシステムが提供
される。

【００１３】本発明は、このようなネットワーク・シス
テムのネットワーク・ノードにも及ぶ。さらに、本発明
は、ネットワーク・システムのノードにロードして前記
方法を実行するようにシステムを構成するコンピュータ
・プログラム・コード手段を含むコンピュータ・プログ
ラム要素にも及ぶ。

【００１４】本発明は、データ・ネットワークにおい
て、柔軟性を向上させ、顧客要求への応答時間を短縮し
た、サービスを都合よく編成し自動的に配備するという
問題のスケーラブルな解決策を提供する。ネットワーク
管理のこのタスクは、ネットワーク・マネージャからネ
ットワークそれ自身に転送される。

【００１５】本明細書で、本発明を使用する方法を参照
しながら特徴について説明する場合、対応する特徴は本
発明を使用する装置に応じて提供することができ、その
逆も可能であることを理解されたい。

【００１６】

【発明の実施の形態】まず図１を参照すると、本発明の
好ましい実施形態では、プロセッサ２０と、入出力（Ｉ
／Ｏ）ポート４０と、プロセッサ２０によって実行され
るコンピュータ・プログラム・コード命令を記憶する第
１の不揮発性メモリ６０と、ノード１０の動作パラメー
タを示す機能（ＣＡＰＳ）リストを記憶する第２の不揮
発性メモリ５０とを含むプログラム可能ネットワーク・
ノード１０が提供される。ＣＡＰＳリストの好ましい例
については後で詳述する。プロセッサ２０、Ｉ／Ｏポー
ト４０、第１のメモリ６０、および第２のメモリ５０は
すべてバス・アーキテクチャ３０によって相互接続され
ている。本発明の特に好ましい実施形態では、プロセッ
サ２０はマイクロプロセッサを含む。高速動作のため
に、マイクロプロセッサは縮小命令セット（ＲＩＳＣ）
アーキテクチャを有することが好ましい。適合するＲＩ
ＳＣマイクロプロセッサの例としては、インテル・コー
ポレーションが販売するｉ９６０マイクロプロセッサ
と、インターナショナル・ビジネス・マシーンズ・コー
ポレーションが販売するＰｏｗｅｒＰＣマイクロプロセ
ッサがある（ＰｏｗｅｒＰＣはインターナショナル・ビ
ジネス・マシーンズ・コーポレーションの登録商標であ
る）。動作時、ノード１０は、１つまたは複数のＩ／Ｏ
ポート４０を異なるノードまたは端点に接続して当該他
のノードまたは端点との通信リンクを形成することによ
ってネットワークに組み込まれる。Ｉ／Ｏポート４０の
機能に応じて、通信リンクは、光ファイバ、銅線、およ
び無線周波数や赤外線などのワイヤレス媒体を含む様々
なネットワーク技法のうちの１つまたはそれらの組み合
わせによって物理的に設けることができることを理解さ
れたい。同様に、Ｉ／Ｏポート４０によって確立される
通信リンクは、トークンリング、スロッテド・リング、
イーサネット（Ｒ）、およびＡＴＭを含む複数の異なる
物理層プロトコルのうちの１つまたは複数のプロトコル
に従ってデータを伝達することができることを理解され
たい。動作時、第１のメモリ６０に記憶されているプロ
グラム・コードが、特定のルーティング機能に従ってＩ
／Ｏポート４０のうちの異なるポート間でデータ・トラ
フィックを伝送するようにマイクロプロセッサを構成す
る。ネットワーク・ノード１０は、プログラム・コード
によって、ルータ、スイッチ、ブリッジ、ブルータ、ま
たは同様のデータ・ネットワーク装置として機能するよ
うに構成することができる。本発明の実施形態によって
は、ノードを構成するためのプログラム・コードは、ノ
ードの製造時に第１のメモリ６０に事前プログラムして
おくことができる。このような事前プログラムされたコ
ードは、変更不能とすることができる。しかし、本発明
の他の実施形態では、ネットワーク内の遠隔場所からＩ
／Ｏポート４０を介して第１のメモリ６０に、更新、修
正、および全く異なるコードをロードすることができ
る。第１のメモリ６０と第２のメモリ５０は、本発明の
ある実施形態では、単一の物理メモリの論理的に区分化
された部分によって実施することができることを理解さ
れたい。

【００１７】本発明の好ましい実施形態では、第２のメ
モリ５０に記憶されたＣＡＰＳリストは、拡張マークア
ップ言語（ＸＭＬ）でコード化される。ＸＭＬによっ
て、ＣＡＰＳリストに記録されるデータ項目を、そのデ
ータ項目をネットワーク内の他のノードの特性に関連す
るデータ項目と組み合わせる規則と共に記述することが
できるので有利である。このようなＣＡＰＳリストの一
例のＸＭＬリストを以下に示す。このＣＡＰＳリストに
は、ノードがサポートする様々な動作および構成アプリ
ケーション・プログラミング・インタフェース（ＡＰ
Ｉ）を示す標識が含まれる。また、ＣＡＰＳリストに
は、たとえばプロセッサ速度やバッファ・サイズなど、
ノードの多数の動作パラメータも含まれる。これらのデ
ータ項目によって、新しいサービスをそのノード上に配
備することができるか否かを判断することができる。 <Network Processor> <base_capabilities> <API supported> PIN 1520 v.1.1.</API_supported> <PIN_1520_specifics> <version> 1.3 </version> etc. </PIN_1520_specifics> <general> <processing> <speed> 500 MHz </speed> </Processing> <scheduling> <total_bandwidth> 100 Mbit/s <total_bandwidth> <type>WFQ</type> <max_queues>1000</max_queues> </scheduling> <buffers_management> <total_buffer_size> 1 MB </total_buffer_size> <max_buffer_pools> 16 </max_buffer_pools> <buffer_sharing> yes </buffer_sharing> <RED>yes</RED> </buffers_management> <forwarding> <type> hardware </type> <programmable> yes </programmable> <fields> source destination address port </fields> <rate> 100% line rate </rate> <table_size> 100k entries </table_size> <number_of_tables> 1 </number_of_tables> </forwarding> </general> <resource_usage> // 定義済み機能のための現在の使用 </resource_usage> </base_capabilities> <diff_serv> // ＮＰがdiff/servの明示的サポートを備えない場合は無し <API_supported> standard_MIB <API_supported> <general> <classifier> <fields> 6 </fields> etc. </classifier> etc. <general> <resource_usage> // 定義済み機能のための現在の使用 </resource_usage> </diff_serv> etc. </Network Processor>

【００１８】本発明のある実施形態では、第２のメモリ
５０に記憶されるＣＡＰＳリストは固定している。しか
し、本発明の他の実施形態では、第２のメモリ５０に記
憶されるＣＡＰＳリストは、データ項目の追加または削
除によって再プログラムまたはその他の方法で変更を加
えることができる。この構成は、たとえば異なる組み合
わせのＩ／Ｏポートを導入することができるネットワー
ク・ノードの場合に特に望ましい。次に図２を参照する
と、本発明の特に好ましい実施形態では、ネットワーク
７０にノード１１が接続されている。ノード１１は、本
明細書で図１を参照しながら前述したノード１０と類似
しているが、ノード１１ではＩ／Ｏポート４０がＩ／Ｏ
サブシステム４５に置き換えられている点が異なる。ネ
ットワークにはＣＡＰＳリスト・ライブラリ・サーバ８
０、ピココード・ライブラリ・サーバ１００、およびソ
フトウェア・プロトコル・ライブラリ・サーバ１１０も
接続されている。ＣＡＰＳリスト・ライブラリ・サーバ
８０には、ＣＡＰＳリストのライブラリ９０が記憶さ
れ、各ライブラリ９０はノード１１のための異なるポー
ト・モジュールに対応する。ピココード・ライブラリ・
サーバ１００には、プロセッサ２０を構成するためのコ
ンピュータ・プログラム・コードのライブラリ１２０が
記憶される。ソフトウェア・プロトコル・ライブラリ・
サーバ１００には、Ｉ／Ｏサブシステム４５のポート間
でデータをルーティングするときにプロセッサ２０によ
って実行されるソフトウェア・ルーティング・プロトコ
ルのライブラリ１３０が記憶される。Ｉ／Ｏサブシステ
ム４５は、複数の対応する交換可能プラグイン・ポート
・モジュール４１、４２、および４３を受け入れる複数
のスロットを含む。各ポート・モジュール４１、４２、
４３は、固有の識別子を記憶する不揮発性レジスタ４６
を含む。次に図２と図３とを共に参照すると、ステップ
１４０で、ポート・モジュール４３がスロットの１つに
挿入されると、プロセッサ２０が対応するレジスタ４６
から固有識別子を読み取る。次に、ステップ１５０で、
固有識別子がノード１１からライブラリ・サーバ８０に
送られる。ステップ１６０で、ライブラリ・サーバ８０
は、受け取った固有識別子に基づいてライブラリ９０か
らノード１１に付加されたポート・モジュール４３に対
応するＣＡＰＳリストを取り出す。次にステップ１７０
で、ライブラリ・サーバ８０はノード１１に取り出した
ＣＡＰＳリストを返す。ステップ１８０で、プロセッサ
２０が付加されたポート・モジュール４３のＣＡＰＳリ
ストを第２のメモリ５０に記憶されているノード１１の
ＣＡＰＳリストに追加する。同様のプロセスを行って、
プロセッサ２０を構成するための更新されたプログラム
・マイクロコードがピココード・ライブラリ・サーバ１
００からノード１１に転送され、第１のメモリ６０に記
憶される。同様に、もう一つの同様のプロセスを行っ
て、プロセッサ２０が実行する新しいソフトウェア・ル
ーティング・プロトコルがソフトウェア・プロトコル・
ライブラリ・サーバ１１０からノード１１に転送され、
やはり第１のメモリ６０に記憶される。本発明のある実
施態様では、ライブラリ・サーバ９０、１００、および
１１０から対応するＣＡＰＳリスト、プロセッサ・プロ
グラム・コード、およびソフトウェア・プロトコルのセ
ット、またはこれらの任意の組み合わせを取り出すため
の固有識別子をノード１１自体に設けることができる。
本発明のある実施形態では、ライブラリ・サーバ８０、
１００、１１０はネットワーク７０に接続された単一の
サーバ・コンピュータ・システムによって実施すること
もできることを理解されたい。

【００１９】また、本発明の他の実施形態では、前記ラ
イブラリ８０、１２０、１３０のうちの１つまたは複数
のライブラリをノード１１に記憶することもできること
を理解されたい。このような実施形態は、ノード１１に
存在するメモリ空間をより多く必要とすることは明らか
である。しかし、両方の固有識別子をネットワーク７０
を介してライブラリ・サーバ８０、１００、１１０に送
信することと、ＣＡＰＳリスト、プロトコル、およびプ
ロセッサ・プログラム・コードをライブラリ・サーバ８
０、１００、および１１０からノード１１に送信し戻す
こととが回避され、それによってデータ・トラフィック
の伝送のための制御トラフィックによって占有されるこ
とになるはずの帯域幅が開放される。

【００２０】次に図４を参照すると、本発明の好ましい
実施形態では、データ・ネットワークは、図１および図
２を参照しながら前述したようなノード２２０を含む。
データ・ネットワークのノード２２０は、サービス配備
階層２１０に論理的に構成されている。サービス配備階
層２１０は、データ・ネットワークのトポロジに基づ
く。しかし、サービス配備階層２１０は、ノードへの到
達可能性とリンク状況を示すデータを配送しないことに
留意されたい。したがって、サービス配備階層２１０
は、プライベート・ネットワーク・インタフェース（Ｐ
ＮＮＩ）ルーティング階層などのルーティング階層とは
異なる。サービス配備階層２１０は、同じサブネット２
３０内のノード２２０をグループ化することによって形
成される。次に、ノード２２０の１つをグループ・リー
ダーとして選択する。各グループ２３０は、階層の次の
層で単一の論理グループ・ノード２４０として現れる。
たとえば、階層２１０の最下層１８０では、サブネット
２３０内のノード２２０が、中間層１９０における論理
サブネット２６０の論理グループ・ノード２４０として
グループ化される。最上位層２００では、論理サブネッ
ト２６０の論理ノードが論理グループ・ノード２５０と
してグループ化される。

【００２１】次に図５を参照すると、サービス配備階層
２１０のネットワーク・サービス配備方式の一例は、請
求ステップ２７０と、集約ステップ２８０と、配布ステ
ップ２９０と、導入ステップ３００と、公示ステップ３
１０とを含む。

【００２２】請求ステップ２７０では、ネットワーク上
で配備するサービスの要件がネットワークの各ノード２
２０にブロードキャストまたはマルチキャストされる。
各ノード２２０は、配備するサービスの要件を、それぞ
れの第２のメモリ５０に記憶されているＣＡＰＳリスト
で規定されている機能と比較する。各ノード２２０は比
較の結果をメトリクスの形で生成する。サービスの要件
が事前にわかっている場合、または汎用書式がある場
合、請求ステップは省くことができる。

【００２３】集約ステップ２８０では、ノード２２０に
よって生成されたメトリクスが、最下層１８０から最上
位層２００までサービス配備階層２１０を上に伝播して
いくにつれて集約される。集約ステップによって、サー
ビス配備をスケーラブルにすることができる。メトリク
スが最上層まで集約されると、ノード２５０はネットワ
ークが当該サービスをサポートすることができるか否か
を示す。

【００２４】配布ステップ２９０では、サービス配備階
層２１０内の各層１８０、１９０、２００でサービスを
サポートするのに最も適したノードのみを選択すること
によってサービスの配備が行われる。この選択は、サー
ビスの「サービス固有割振り方針（ＳＳＡＰ）」に基づ
いて行われる。配備要件はサービスによって異なる。た
とえば、経路にあるすべてのホップでの配備を必要とす
るサービスがある。しかし、経路の両端部またはネット
ワークの選択されたノードのみで必要なサービスもあ
る。サービスのＳＳＡＰによって、ネットワークにおい
てサービスをどのように配備するかが規定される。

【００２５】導入ステップ２３０では、サービスが対応
するＳＳＡＰに従ってネットワークの最下層１８０のノ
ード２２０に導入される。

【００２６】公示ステップ３１０では、各ノード２２０
が各ノードに導入されているサービスを公示し、同じサ
ービスを公示している他のノード２２０の識別情報を動
的に認識する。これによって、たとえばピアを自動構成
するためのルーティング・プロトコルなどの制御サービ
スが可能になる。

【００２７】次に請求ステップについて詳細に説明す
る。前述のように、このステップではネットワーク上で
配備するサービスの要件がネットワークの各ノード２２
０にブロードキャストまたはマルチキャストされる。本
発明の好ましい実施形態では、サービスの要件はブロー
ドキャストまたはマルチキャストのために、前述の例示
のＣＡＰＳリストと同様の方式でＸＭＬなどのマークア
ップ言語でコード化される。要件は、必要なルーティン
グ・プロトコル、バッファ・サイズや待ち行列数などの
物理機能または論理機能、またはこれらの組み合わせと
定義することができる。ネットワークのある部分は、省
略された形態の請求ステップでよい。たとえば、ＳＳＡ
Ｐによって、その間にサービスを配備する両端部または
両端点が定義されている場合、請求ステップでサービス
の要件をその両端部または端点間の間のノードにのみマ
ルチキャストすることができる。

【００２８】サービスは以下の２つのカテゴリに分類す
ることができる。すなわち、事前にはわかっていないカ
スタム・メトリクスまたはカスタム集約規則のセットま
たはその両方を必要とするもの。このようなメトリクス
は、配備するサービスの要件と要件を受け取る各ノード
のＣＡＰＳリストの内容との前述の比較から導き出され
る。事前にわかっている汎用メトリクスまたは汎用集約
規則のセットのみを必要とするものとである。

【００２９】汎用メトリクスによっては、対応する汎用
集約規則を介してネットワーク内でデフォルトにより公
示することができるものもある。新しいサービスの配備
でそのようなメトリクスを十分な頻度で使用する場合、
デフォルトによりそれらのメトリクスを公示することに
よって請求ステップと集約ステップが余分になる。した
がって、状況によってはこの２つのステップを省くこと
ができる。これは、短時間で導入する必要のあるサービ
スの配備の場合に特に望ましい。カスタム・メトリクス
のセットは、配備するサービスの要件と、それを受け取
るノード２２０のＣＡＰＳリストの対応する項目との前
述の比較の結果の値を有する。このセット内の値は、配
備されるサービスをノードがサポートするか否かを単に
示すだけの二進値とすることができる。一代替形態で
は、価値は、ノードがサービスをサポートできるコスト
を示すことが可能である。他の態様では、この値によっ
て、配備されるサービスをノードがどの程度サポートす
ることができるかを示すことができる。図４を参照する
と、ディフ・サーブ・サービスなどの特定のサービスを
サポートすることができるノードが、請求ステップを実
行した結果の一例として黒で図示されている。

【００３０】次に、集約ステップについて詳述する。前
述のように、サービス配備階層２１０では連続した層を
上方にたどっていくため、スケーラビリティのためには
メトリクスのセットを集約することが望ましい。本発明
の特に好ましい実施形態では、集約ステップは、ネット
ワーク内の変更を取り込むために、頻繁な間隔で、また
は事前定義されたイベント発生時、あるいはその両方で
実行される。図６を参照すると、メトリクスのセットが
従来のようにサービス配備階層２１０の連続した各層間
の状態遷移マトリックスとして配置されている。たとえ
ば、Ｍ₁は層１９０の論理サブネット２６０の状態遷移
マトリックスである。階層２１０内のサブネットの端部
には、要素ｍ_i,,jが端部ｉとｊの間の最短経路上のホッ
プ数と定義されるように番号が付けられ、この経路上の
各ホップでディフ・サーブ・サービスなどの所望のサー
ビスが提供される。マトリックスは対称なので、半分の
みが示される。

【００３１】次に、配布ステップ２９０について詳述す
る。配布ステップ２９０では、サービスの配備が対応す
るＳＳＡＰによって指示される。ＳＳＡＰには、たとえ
ばノード２２０のうちのどのノードをサービス使用可能
にする必要があるかを識別するトポロジ指向標識が含ま
れる。具体的には、配布ステップ２９０は、階層２１０
内の最上位ノード２５０から出されたサービスを配備す
る配布コマンドから開始する。配布コマンドは対応する
ＳＳＡＰと共に階層２１０を下っていく。階層２１０内
の各層で、グループ・リーダーは、この配布コマンド
を、グループ全体にフラッディングするのではなく、サ
ービスを配備する必要があるノードにのみ転送する。こ
れによって、ネットワークの輻輳が最小限になるので有
利である。本発明の特に好ましい実施形態では、グルー
プ・リーダーは、配布コマンドを伝播させるように選択
されていない限り、下層のノードには配布コマンドを伝
播させない。サービスがアクティブ状態であるならば、
サービスを配備するノード２２０はそのサービスを維持
する。これによって、有意な変化があった場合にサービ
スを自動的に配備することができる。何が有意な変化で
あるかはＳＳＡＰによって定義される。ルーティング変
更が発生したときにサービスの再配備を回避するため
に、配布コマンドの伝送中にヒューリスティックを使用
して、サービスが１組の経路上に配備されるようにする
ことができる。このようなヒューリスティックもＳＳＡ
Ｐに含まれる。再び図４を参照すると、マトリックスＭ
₁，ｍ_1,5は非ゼロであり、ネットワークが必要なサービ
スをサポートすることができることを示している。した
がって、図６を参照すると、最下層が備える状態遷移マ
トリックスに基づいて、階層２１０内の各層で最短経路
が選択されるようにして配布が行われる。次に、この経
路上のノードは配布コマンドを階層２１０内の次の下層
に転送し、物理ノード２２０がある最下層１８０に達す
るまで転送される。ここでサービスが各ノード２２０に
個別に導入される。図６で、最短経路の両端部は各層で
太線で示されており、各層のこの経路上のノードは黒く
示されている。

【００３２】請求ステップと配布ステップは、サービス
を配布するネットワークに接続されたネットワーク・マ
ネージャまたはエンド・ユーザ要求に応答したゲートウ
ェイ、あるいはこの２つの組み合わせによって開始する
ことができる。

【００３３】次に、導入ステップについて詳述する。配
布コマンドが階層２１０内の最下層１８０に達したとき
のノード２２０へのサービスの導入は、自動的に行われ
る。本発明の好ましい実施形態では、ノードをサービス
を実行するように構成するためのコードが入ったリポジ
トリへのリンクが、配布コマンドに付随するＳＳＡＰに
含まれている。あるいは、配備されるサービスに関連づ
けられた構成コードが比較的小さい場合、コードは配布
コマンドに含めることができる。

【００３４】次に、公示ステップについて詳述する。サ
ービスが導入された後は、サービスは制御メッセージを
交換する隣接ノードを見つけるか、または公示され、そ
れによってデータ・パケットがサービス使用可能にされ
たノードを介してそれぞれの宛先に向けてルーティング
される。前者は、明示的アドレス信号方式を使用する。
明示的アドレス指定の他の例としては、ルーティング更
新メッセージがピア・ノードに対して明示的にアドレス
されるほとんどのルーティング・プロトコルがある。後
者は、暗黙的アドレス信号方式を使用する。暗黙的アド
レス指定は、ノードは、同じサービスを稼働させてサー
ビスを実行しているピア・ノードのアドレスを使用する
必要がない。暗黙的アドレス指定の例は、インターネッ
ト技術標準化委員会（Internet Engineering Task Forc
e:ＩＥＴＦ）ディフ・サーブ（diff-serv）に見られる
ものなどの帯域内信号方式や、ＩＥＴＦＲＳＶＰに見
られるものなどの帯域外周波信号方式がある。図４およ
び図６を参照しながら上述した本発明の好ましい実施形
態では、ディフ・サーブ・サービスの配備が企図されて
いた。前述のように、このようなサービスは、暗黙的ア
ドレス指定サービスの例である。公示ステップでは、こ
のようなサービスが配備されるノードがそのサービスを
公示する。この公示は再び集約され、配布される。ここ
では、公示に付随する状態遷移マトリックスは、集約ス
テップで作成したものと同じである。これは、終端点間
のディフ・サーブ・サービスのサポートする経路が１つ
しかないためである。集約された公示は、適切な経路を
設けるルーティングと組み合わされる。サービス配備階
層２１０とネットワークのルーティング階層とを整合さ
せることにより、暗黙的アドレス指定サービスを配備す
る場合の公示ステップの実行が容易になることを理解さ
れたい。

【００３５】次に図７を参照しながら、本発明を使用す
るＡＴＭ−ＰＮＮＩネットワークの一例について説明
し、上述のサービス配備階層をインターネット・プロト
コル（ＩＰ）ルーティング・サービスの配備に適用する
例を示す。このサービスは、明示的アドレス指定帯域外
制御サービスである。このＡＴＭ−ＰＮＮＩネットワー
クは、ＩＰルータ・ノード３５０が接続された複数のＡ
ＴＭスイッチ・ノード３６０を含む。サービス配備階層
は、３つの層３２０、３３０、３４０を含む。層３３０
は、論理ノード３９０、４００、４１０、４２０を有す
る。層３２０は、グループ４３０と４５０の間に論理グ
ループ４４０を有する。ＩＰルーティング階層は、サー
ビス配備階層およびＰＮＮＩ階層と一致している。Open
ShortestPath First （ＯＳＰＦ）サービスおよび境界
ゲートウェイ・プロトコル（ＢＧＰ）サービスが適切な
層に自動的に導入される。ＯＳＰＦの詳細は、ＩＥＴＦ
ＲＦＣ（Request for Comments）１５８３に記載されて
いる。この説明では、請求ステップおよび集約ステップ
は省く。配布ステップに重点を置いて説明すると、ＳＳ
ＡＰはたとえばノード４１０をＯＳＰＦバックボーン領
域として選択する。次に、各ＯＳＰＦ領域で、ルータ３
５０が同じ領域内の他のルータ３５０と相互接続する。
すべてのＯＳＰＦルータ３５０からの公示は、それぞれ
のグループに限定される。ただし、バックボーン領域の
境界領域ルータはすべての領域で公示される。ＢＧＰサ
ービスを実行するために選定されたルータ３５０は、最
上位層３２０まで公示され、それによってグループ４３
０および４５０とグループ４４０内のピアから見える。
次に図８を参照すると、その結果のＩＰルーティング階
層は、ＯＳＰＦ自律システムを含む。ＯＳＰＦ自律シス
テムは４つのＯＳＰＦ領域４６０、４７０、４８０、お
よび４９０を、２つのＢＧＰ通信ノード５１０および５
２０にわたるＢＧＰ経路５００と共に含む。

【００３６】図９を参照すると、本発明の他の例では、
複数のサーバ５６０、５６５、および５７０と複数のル
ータ・ノード５８０、５９０、６００、および６１０を
含むＩＰネットワークがある。このネットワークには明
示的アドレス指定帯域内サービスが配備される。サービ
スの配備の結果、サーバ５６０および５７０はプロキシ
・キャッシュを実行することになる。したがって、プロ
キシ・キャッシュ・サーバ５６０および５７０には、透
過ＨＴＴＰクライアント（図示せず）が接続されてい
る。プロキシ・キャッシュ５６０は透過なため、ＨＴＴ
Ｐクライアントはそのプロキシ・キャッシュ５６０およ
び５７０のアドレスを使用して構成する必要がない。そ
の代わりに、ルータ５８０、６００、および６１０が層
４スイッチングを実行し、ＨＴＴＰ要求をプロキシ・キ
ャッシュ・サーバ５６０に転送する。応答時間を向上さ
せるために、２層のキャッシュを使用する。第１レベル
・キャッシュ５６０には、ローカル・ユーザによって最
も頻繁に要求されるページが入れられる。第２のレベル
・キャッシュ５７０にはすべてのユーザによって最も頻
繁に使用されるページが入れられる。この説明では、サ
ービス配備の前にネットワークに十分なルーティングお
よびアドレス指定機能がすでに備えられているものとす
る。請求ステップで、サービスをサポートするための特
定の要件がノード５８０、５９０、６００、６１０、お
よび６１５に送られる。ここでは、この要件には、直接
接続されたサーバ５７０、５６５、および５６０上の最
低限の処理能力および記憶域と、ルータ５８０、５９
０。６００、６１０および６１５が層４スイッチングを
実行できる能力が含まれる。バックボーン領域６２０を
表す論理が、第２レベル・キャッシュ５７０に対応する
要件と共に請求を受け取る。しかし、領域５５０、５４
０、および５３０を表す論理ノードは、第１レベルキャ
ッシュ５６０の要件を受け取る。その結果のメトリクス
は、二進値とすることができ、サービス配備階層を上方
に送られ、前述のように各論理グループごとに集約され
る。集約は、各ルータ５８０、５９０、６００、６１
０、および６１５からの結果の論理ＯＲによって行われ
る。次に、メトリクスは前の結果の論理ＡＮＤによって
再び集約される。ネットワーク全体を表す論理ノード
は、これによって、所望のサービスを現行のネットワー
ク基盤上に配備することができるか否かが判断される。
この例は、サービス配備階層の層によって異なるカスタ
ム集約規則を示している。このシステムは、ユーザには
透過である。したがって、ユーザはこのサービス配備か
らは公示を受け取らない。しかし、第１レベル・キャッ
シュ５６０はキャッシュ・ミスを第２レベル・キャッシ
ュ５７０に転送する。したがって、第２レベル・キャッ
シュ５７０はそのアドレスの公示を生成する。これらの
公示は、自律システム内に含まれ、ネットワーク全体に
フラッディングされるのではなく、第１レベル・キャッ
シュ５６０にのみ送られる。

【００３７】次に、本発明を仮想外部リンクを使用する
本発明を仮想プライベート・ネットワーク（ＶＰＮ）に
適用する例について、図１０を参照しながら説明する。
前述の本発明のディフ・サーブの例は、トランシット・
ネットワークにも適用可能である。したがって、仮想外
部リンクは不要であった。ＶＰＮは一般に、同じネット
ワーク内のサブネット６４０、６５０、および６６０を
相互接続する。ＶＰＮは通常、定義済みＱｏＳを、終端
点における暗号化機能と共に必要とする。所望のＱｏＳ
が、ＩＥＴＦＲＳＶＰなどのプロトコルによって信号
送信される。この例では、ＶＰＮの終端点が設定されて
いるものとする。図１０で、これらの終端点は、文字
Ａ、Ｂ、およびＣで示されている。ＶＰＮが形成された
ネットワークは、ＲＳＶＰ対応ルータ・ノード６６０と
ＲＳＶＰ非対応ルータ・ノード７００の両方を含む。請
求ステップ中に、ＳＳＡＰはＶＰＮの所望の終端点のア
ドレスを組み込み、それによって集約ステップ中に適切
な仮想外部リンク６７０および６８０を作成することが
できる。そうしなければ、サービス配備階層の上位層６
９０は、終端点Ａ、Ｂ、およびＣをＲＳＶＰ対応ルータ
６６０と相互接続することができるか否かを判断するこ
とができなくなる。サービス配備階層に対応する状態遷
移マトリックスは、図４を参照しながら前述したディフ
・サーブの例のものと同様である。マトリックスＭ_1..1
およびＭ_1.2から作成されたマトリックスＭ₁において、
ｍ_2,0＝３であり、これは種端点ＡとＢの間のＶＰＮの
コストである。同様に、終端点ＢとＣの間のＶＰＮのコ
ストはｍ_3,2＝４であり、終端点ＡとＣの間のコストは
ｍ_3,0＝６である。次に、配布ステップは、全体的なコ
ストが最小限になるように、終端点ＡとＢ、ＢとＣの間
のＶＰＮの配備を選択することによって開始する。

【００３８】要約すると、以上、本発明の例として、複
数のネットワーク・ノードを含むデータ・ネットワーク
においてサービス割振り方針に従ってサービスを配備す
る方法について説明した。この割振り方針によって、サ
ービスの配備のためのノードの選択が規定される。この
方法は、ネットワーク・ノードを含む最下層と、各層に
おいて前の層のノードのグループがそれぞれの論理ノー
ドによって表された１つまたは複数の漸進的に高くなる
層とを有するサービス配備階層を定義するステップを含
む。この方法は、配備するサービスを指定するサービス
配布コマンドを生成するステップも含む。サービス配布
コマンドは、割振り方針と共に、階層のより上位の層の
論理ノードから階層のより下位の層または各下位層に供
給される。サービス配布コマンドで指定されたサービス
は、割振り方針に従って選択されたネットワーク・ノー
ドに自動的に導入される。本発明の他の例として複数の
ノードを含むネットワーク・システムについても説明し
た。このシステムは、前記のサービス配備方法を実行す
るように構成されている。本発明の他の例として、この
ようなネットワーク・システムのネットワーク・ノード
についても記載した。

【００３９】まとめとして、本発明の構成に関して以下
の事項を開示する。

【００４０】（１）複数のネットワーク・ノードを含む
データ・ネットワークにおいて、サービスの配備のため
のノードの選択を規定するサービス割振り方針に従って
サービスを配備する方法であって、前記ネットワーク・
ノードを含む最下層と、各層において前の層のノードの
グループがそれぞれの論理ノードによって表された１つ
または複数の漸進的に高くなる層とを有するサービス配
備階層を定義するステップと、配備する前記サービスを
指定するサービス配布コマンドを生成するステップと、
前記サービス配布コマンドを前記割振り方針と共に前記
階層のより上位の層の論理ノードから前記階層のより下
位の層または各下位層のノードに供給するステップと、
前記割振り方針に従って選択されたネットワーク・ノー
ドに前記サービス配布コマンドで指定された前記サービ
スを自動的に導入するステップとを含む方法。（２）配備する前記サービスの要件を示すサービス請求
を、前記階層のより上位の前記層の前記論理ノードから
前記階層のより下位の層のネットワーク・ノードに供給
するステップと、前記サービス請求を各ネットワーク・
ノードの機能と比較して、前記ノードが配備する前記サ
ービスをサポートする能力を示すメトリクスを生成する
ステップと、前記メトリクスを集約して前記階層の次の
層のために集約されたメトリクスを生成するステップ
と、連続した各層について前記集約ステップを繰り返す
ステップと、より上位の前記層における集約された前記
メトリクスに基づいて前記配布コマンドを生成するステ
ップとを含む、上記（１）に記載の方法。（３）前記選択されたノードのうちの１つまたは複数の
ノードを表す論理ノードにおいて情報を保持して、前記
サービスの動的再配備を可能にするステップを含む、上
記（１）または（２）に記載の方法。（４）前記集約ステップが、前記層のうちの１つまたは
複数の層の異なるノード・グループのための異なる集約
手続きを含む、上記（２）に記載の方法。（５）複数のノードを含み、上記（１）ないし（４）の
いずれか一項に記載のサービス配備方法を実行するよう
に構成されたシステム。（６）上記（５）に記載のネットワーク・システムのネ
ットワーク・ノード。（７）ネットワーク・システムのノードにロードされ、
前記システムを上記（１）ないし（５）のいずれか一項
に記載の方法を実行するように構成するコンピュータ・
プログラム・コード手段を含むコンピュータ・プログラ
ム要素。

【図面の簡単な説明】

【図１】プログラム可能ネットワーク・ノードを示すブ
ロック図である。

【図２】他のプログラム可能ネットワーク・ノードを示
すブロック図である。

【図３】図２に示すプログラム可能ネットワーク・ノー
ドの動作に関連するフローチャートである。

【図４】機能の集約を示すデータ・ネットワークのため
のサービス配備階層の図である。

【図５】データ・ネットワークのためのサービス配備の
フローチャートである。

【図６】サービス配布を示すデータ・ネットワークのた
めのサービス配備階層のブロック図である。

【図７】ＡＴＭネットワークのためのサービス配布階層
のブロック図である。

【図８】図７に示すＡＴＭネットワークのためのＩＰル
ーティング階層を示すブロック図である。

【図９】他のＩＰルーティング階層を示すブロック図で
ある。

【図１０】下層プライベート・ネットワークを示すブロ
ック図である。

【符号の説明】

１０プログラム可能ネットワーク・ノード１１ノード２０プロセッサ４０入出力ポート４１ポート・モジュール４５Ｉ／Ｏサブシステム４６不揮発性レジスタ５０第２の不揮発性メモリ６０第１の不揮発性メ７０ネットワーク８０ＣＡＰＳリスト・ライブラリ・サーバ１００ピコ・コード・ライブラリ・サーバ１１０ソフトウェア・プロトコル・ライブラリ・サー
バ３５０ＩＰルータ・ノード３６０ＡＴＭスイッチ・ノード３９０論理ノード

───────────────────────────────────────────────────── フロントページの続き (72)発明者ロベルト・ハーススイスシー・エイチ−8134 アドリシュヴィルアルビスシュトラーセ５ (72)発明者パトリック・ドロツスイスシー・エイチ−8803 リューシュリコンアルテ・ランドシュトラーセ 105 Ｆターム(参考） 5K030 GA11 HA08 HA10 HC01 JL07 KA01 KA05 KA13 LB05

Claims

【特許請求の範囲】

【請求項１】複数のネットワーク・ノードを含むデータ
・ネットワークにおいて、サービスの配備のためのノー
ドの選択を規定するサービス割振り方針に従ってサービ
スを配備する方法であって、前記ネットワーク・ノードを含む最下層と、各層におい
て前の層のノードのグループがそれぞれの論理ノードに
よって表された１つまたは複数の漸進的に高くなる層と
を有するサービス配備階層を定義するステップと、配備する前記サービスを指定するサービス配布コマンド
を生成するステップと、前記サービス配布コマンドを前記割振り方針と共に前記
階層のより上位の層の論理ノードから前記階層のより下
位の層または各下位層のノードに供給するステップと、前記割振り方針に従って選択されたネットワーク・ノー
ドに前記サービス配布コマンドで指定された前記サービ
スを自動的に導入するステップとを含む方法。
【請求項２】配備する前記サービスの要件を示すサービ
ス請求を、前記階層のより上位の前記層の前記論理ノー
ドから前記階層のより下位の層のネットワーク・ノード
に供給するステップと、前記サービス請求を各ネットワーク・ノードの機能と比
較して、前記ノードが配備する前記サービスをサポート
する能力を示すメトリクスを生成するステップと、前記メトリクスを集約して前記階層の次の層のために集
約されたメトリクスを生成するステップと、連続した各
層について前記集約ステップを繰り返すステップと、より上位の前記層における集約された前記メトリクスに
基づいて前記配布コマンドを生成するステップとを含
む、請求項１に記載の方法。
【請求項３】前記選択されたノードのうちの１つまたは
複数のノードを表す論理ノードにおいて情報を保持し
て、前記サービスの動的再配備を可能にするステップを
含む、請求項１または２に記載の方法。
【請求項４】前記集約ステップが、前記層のうちの１つ
または複数の層の異なるノード・グループのための異な
る集約手続きを含む、請求項２に記載の方法。
【請求項５】複数のノードを含み、請求項１ないし４の
いずれか一項に記載のサービス配備方法を実行するよう
に構成されたシステム。
【請求項６】請求項５に記載のネットワーク・システム
のネットワーク・ノード。
【請求項７】ネットワーク・システムのノードにロード
され、前記システムを請求項１ないし５のいずれか一項
に記載の方法を実行するように構成するコンピュータ・
プログラム・コード手段を含むコンピュータ・プログラ
ム要素。