(57)【特許請求の範囲】
【請求項１】
カスタマサブツリーとポリシサブツリーとシステムサブツリーを備えたＩＰ(Internet Protocol)網サービス指向ＤＩＴ(Directory Information Tree)構成を構成するためのＤＩＴ管理システムにおいて、
前記カスタマサブツリーの配下には、複数のサービスエントリを作成する手段と、
各サービスエントリの配下には複数のポリシルールエントリを作成する手段と、
前記ポリシサブツリーの配下には複数のポリシルールフォーマットエントリを作成する手段と、
前記システムサブツリーの配下には複数のサービスクラス定義エントリを作成する手段と、
各サービスエントリには、各ポリシルールフォーマットエントリを介して各ポリシルールエントリから参照されるコンディションパラメータを属性として設定する手段と、
各サービスエントリには、各ポリシルールフォーマットエントリと各サービスクラス定義エントリを介して各ポリシルールエントリから参照されるアクションパラメータを属性として設定する手段と、
各サービスエントリからは対応するサービスクラス定義エントリを参照するポインタを設定する手段と、
各サービスクラス定義エントリからは対応するポリシルールフォーマットを参照するポインタを設定する手段と、
各ポリシルールフォーマットからは対応するポリシルールフォーマットを参照するポインタを設定する手段と、
を備えることを特徴とするＤＩＴ管理システム。
【請求項２】
請求項１に記載のＤＩＴ管理システムにおいて、
指定されたサービスエントリから参照されるサービスクラス定義エントリを参照する手段と、
前記サービスクラス定義エントリから参照されるルールフォーマットエントリを参照し、そのルールフォーマットに基づいてサービスエントリの下にルールエントリを作成する手段と、
を更に備えることを特徴とするＤＩＴ管理システム。
【請求項３】
請求項２に記載のＤＩＴ管理システムにおいて、
ルールエントリを作成する際に参照したルールフォーマットに書かれたコンディションパラメータをルールエントリに設定する手段を更に備えることを特徴とするＤＩＴ管理システム。
【請求項４】
請求項２又は３に記載のＤＩＴ管理システムにおいて、
サービスエントリの属性として設定されたサービスエントリの配下にルールエントリの作成が完了したか否かを表す状態情報を見て、もしその状態情報がルールエントリの作成が完了していない状態ならば、ルールエントリの作成を行う手段を更に備えることを特徴とするＤＩＴ管理システム。
【請求項５】
請求項２、３又は４に記載のＤＩＴ管理システムにおいて、
サービスエントリを生成する際にＤＩＴを参照して実際にポリシをネットワーク機器に適用するシステムがポリシの適用時間を検出できるように、ポリシを適用する時間を指定するパラメータをサービスエントリの属性として設定する手段を更に備えることを特徴とするＤＩＴ管理システム。
【請求項６】
請求項２、３、４又は５に記載のＤＩＴ管理システムにおいて、
ルールエントリを生成する際にＤＩＴを参照して実際にポリシをネットワーク機器に適用するシステムがポリシの適用対象を検出できるように、ポリシを適用する対象を指定するパラメータをルールエントリの属性として設定する手段を更に備えることを特徴とするＤＩＴ管理システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ＩＰ（Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）網サービス管理システムで使用され、ディレクトリサーバの記録媒体に記録されるサービス指向ＤＩＴ（Ｄｉｒｅｃｔｏｒｙ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｒｅｅ）構成に関する。
【０００２】
【従来の技術】
現状、ポリシサブツリーのみの検討は、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｅｅｎｒｉｎｇ  ＴａｓｋＦｏｒｃｅ）で進められている。
【０００３】
【発明が解決しようとする課題】
しかしながら、カスタマサブツリーとの関係付け、具体的には、サービスエントリからのルール生成については議論されていない。本来、網の運用を考えると、カスタマケアシステムが必要であり、カスタマケアサーバには、サービス指向のデータ構造（本発明中の、カスタマサブツリーに相当）が必要である。一方、プロビジョニング（ＮＥ（Ｎｅｔｗｏｒｋ  Ｅｌｅｍｅｎｔ；具体的にはルータ等）への設定）を意識した場合、検索時間、データの運用などを考慮すると、ポリシサブツリーが必要となる。しかしながら、これらのサブツリー間でのマッピングは検討されていない。同様に。両サブツリーを意識して、データ容量を削減するための方式は検討されていない。
【０００４】
また、多様なサービス種別、あるいは、サービス定義の変更についての検討も無い。
【０００５】
本発明は、データ容量を節約できることを可能とするＩＰ網サービス管理のためのサービス指向ＤＩＴ構成を提供することを目的とする。
【０００６】
また、本発明は、ルールの変更に柔軟に対応することを可能とするＩＰ網サービス管理のためのサービス指向ＤＩＴ構成を提供することを目的とする。
【０００７】
更に、本発明は、サービス変更に柔軟に対応することを可能とするＩＰ網サービス管理のためのサービス指向ＤＩＴ構成を提供することを目的とする。
【０００８】
【課題を解決するための手段】
本発明によれば、カスタマサブツリーとポリシサブツリーとシステムサブツリーを備えたＩＰ(Internet Protocol)網サービス指向ＤＩＴ(Directory Information Tree)構成を構成するためのＤＩＴ管理システムにおいて、前記カスタマサブツリーの配下には、複数のサービスエントリを作成する手段と、各サービスエントリの配下には複数のポリシルールエントリを作成する手段と、前記ポリシサブツリーの配下には複数のポリシルールフォーマットエントリを作成する手段と、前記システムサブツリーの配下には複数のサービスクラス定義エントリを作成する手段と、各サービスエントリには、各ポリシルールフォーマットエントリを介して各ポリシルールエントリから参照されるコンディションパラメータを属性として設定する手段と、各サービスエントリには、各ポリシルールフォーマットエントリと各サービスクラス定義エントリを介して各ポリシルールエントリから参照されるアクションパラメータを属性として設定する手段と、各サービスエントリからは対応するサービスクラス定義エントリを参照するポインタを設定する手段と、各サービスクラス定義エントリからは対応するポリシルールフォーマットを参照するポインタを設定する手段と、各ポリシルールフォーマットからは対応するポリシルールフォーマットを参照するポインタを設定する手段とを備えることを特徴とするＤＩＴ管理システムが提供される。
【０００９】
上記のＤＩＴ管理システムは、指定されたサービスエントリから参照されるサービスクラス定義エントリを参照する手段と、前記サービスクラス定義エントリから参照されるルールフォーマットエントリを参照し、そのルールフォーマットに基づいてサービスエントリの下にルールエントリを作成手段とを更に備えていてもよい。
【００１０】
上記のＤＩＴ管理システムは、ルールエントリを作成する際に参照したルールフォーマットに書かれたコンディションパラメータをルールエントリに設定する手段を更に備えていてもよい。
【００１１】
上記のＤＩＴ管理システムは、サービスエントリの属性として設定されたサービスエントリの配下にルールエントリの作成が完了したか否かを表す状態情報を見て、もしその状態情報がルールエントリの作成が完了していない状態ならば、ルールエントリの作成を行う手段を備えていてもよい。
【００１２】
上記のＤＩＴ管理システムは、サービスエントリを生成する際にＤＩＴを参照して実際にポリシをネットワーク機器に適用するシステムがポリシの適用時間を検出できるように、ポリシを適用する時間を指定するパラメータをサービスエントリの属性として設定する手段を備えていてもよい。
【００１３】
上記のＤＩＴ管理システムは、ルールエントリを生成する際にＤＩＴを参照して実際にポリシをネットワーク機器に適用するシステムがポリシの適用対象を検出できるように、ポリシを適用する対象を指定するパラメータをルールエントリの属性として設定する手段を更に備えていてもよい。
【００１８】
本発明によるＩＰサービス管理のためのサービス指向ＤＩＴ構成、設計システム（ルータ内に格納されるルーティングテーブルを設計するシステム）、カスタマケアシステム（カスタマへのサービス受付をサポートするシステムであり、カスタマ情報を管理するシステム）、ポリシ管理システム（カスタマ単位、又はカスタマが要求したサービス単位に定義されるポリシに従いルータを管理するシステム）、ディレクトリサーバ（データを一元的に管理するサーバ）からなる、ＩＰ網サービス管理システムにおいて、カスタマケアシステムが生成するサービスエントリ（ディレクトリサーバに格納されるものであり、カスタマが要求するサービス情報を含む）に、ポリシ管理システムが利用するポリシ関連データを集約し、ポリシ関連データは、このサービスエントリを参照することにより得ることで、データ容量を節約できること、サービスエントリ内容を、ポリシルール（カスタマ単位又はサービス単位に定義され、コンディションとアクションを用いて記述され、ルータに設定される）として解釈するためのポリシルールフォーマットエントリ１７（図４）を用いることで、ルールの変更に柔軟に対応できること、サービスクラス定義エントリ１８（図３）を導入することで、サービス（カスタマに提供するサービス）の変更に柔軟に対応できること（サービス種類の追加、変更が生じた場合に元データ（カスタマから受け付けたサービス情報）には変更を加える必要がないこと）、を特徴とする。
【００１９】
【発明の実施の形態】
図１は、本発明の実施形態によるＤＩＴ構成である。このＤＩＴは、ディレクトリサーバに格納されるデータとともにディレクトリサーバのハードディスクドライブ等の記録媒体に記録され、これらのデータのスキーマ定義をする。キャリアは、ディレクトリサーバを設計システム、ポリシ管理システム等のシステムと一緒に所有する。
【００２０】
ｃｕｓｔｏｍｅｒｓサブツリー（カスタマサブツリー）１１は、カスタマケアサーバが、サービスを受け付けた時に、カスタマの要求に応じて、生成されるサービスエントリ１５を含むサブツリーである。例えば、カスタマ単位、ＶＰＮ（Ｖｉｒｔｕａｌ  ｐｒｉｖａｔｅ  ｎｅｔｗｏｒｋ）単位、サービストポロジ（ポイント・ツー・ポイント（ｐ２ｐ）、ポイント・ツー・マルチポイント（ｐ２ｍ）、マルチポイント・ツー・マルチポイント（ｍ２ｍ）等）単位、で多段分岐して、サービスエントリ１５が生成される。なお、１６はポリシルールエントリである。また、図１中、”ｎ”は複数の分岐を示し、これはＯＭＴ（Ｏｂｊｅｃｔ  Ｍｏｄｅｌｉｎｇ  Ｔｅｃｈｎｉｑｕｅ）に従った記法である。図１中、ポリシルールエントリ１６からポリシルールフォーマットエントリ１７へのポインタの説明文中及びサービスクラス定義エントリ１８からポリシルールフォーマットエントリ１７へのポインタの説明文中のＤＮは、Ｄｉｓｔｉｎｇｕｉｓｈｅｄ  Ｎａｍｅの略であり、これは、ＬＤＡＰ（Ｌｉｇｈｔ−ｗｅｉｇｈｔｅｄ  Ｄｉｒｅｃｔｏｒｙ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ）のスキーマ定義で、エントリを一意に指定するために用いられる。
【００２１】
ｎｅｔｗｏｒｋサブツリー（ネットワークサブツリー）１２は、ネットワーク関連のエントリを含むサブツリーであり、ＩＰサービス管理システムとは別の網管理システムが利用する。
【００２２】
ｐｏｌｉｃｉｅｓサブツリー（ポリシサブツリー）１３は、ＩＰトラヒックに対してＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）やセキュリティ方針を適用するポリシ管理に必要な情報（エントリ１７にある情報）を含むサブツリーである。本実施形態では、上記ｃｕｓｔｏｍｅｒｓサブツリー１１配下のサービスエントリ１５に、ポリシルールのデータを集約させ、このｐｏｌｉｃｉｅｓサブツリー１３では、ポリシルールフォーマットエントリ１７のみを保持させることとしている。
【００２３】
ｓｙｓｔｅｍサブツリー１４は、ｃｕｓｔｏｍｅｒｓサブツリー１１、ｎｅｔｗｏｒｋサブツリー１２、ｐｏｌｉｃｉｅｓサブツリー１３、に対して中立的なサブツリーであり、つまり、ｃｕｓｔｏｍｅｒｓサブツリー１１、ｎｅｔｗｏｒｋサブツリー１２、ｐｏｌｉｃｉｅｓサブツリー１３だけに分類できない情報であってそれらの全てに関連を持つ情報を格納するためのサブツリーであり、配下には、サービスクラス定義エントリ１８が配備される。
【００２４】
図２は、サービスエントリ１５がもつ属性を整理したものである。ｓｅｒｖｉｃｅ  ｔｙｐｅ２１は、帯域、パケット転送優先度を指定するもので、複数のうちの１つのサービスクラス定義エントリ１８（図３）の名称が属性値として使われている（図１のサービスエントリ１５からサービスクラス定義エントリ１８への矢印で示す。）。パラメータ２２は、ポリシルールエントリ１６のコンディションとして使われる可能性のあるコンディションパラメータである。つまり、コンディションパラメータ２２は、ポリシルールエントリの種別により、ポリシルールエントリに対応するポリシルールフォーマット１７（図４）がもつｃｏｎｄｉｔｉｏｎ  ｐａｒａｍｅｔｅｒ  ４１の属性値、を基に参照されることとなる。あるポリシルールエントリ１６（図５）に着目したとき、ポリシルールエントリ１６は属性「ポリシルールフォーマット」を持っているので、属性「ポリシルールフォーマット」を参照することにより判別されるポリシルールエントリ１６に対応するポリシリールフォーマット１７を参照して（図１のポリシルールエントリ１６からポリシルールフォーマットエントリ１７への矢印で示す。）、ポリシルールフォーマット１７が持つコンディションパラメータ４１の属性値を参照して、サービスエントリ１５内の属性を参照することができる。この参照方式で、データ容量の節約が可能となる。
【００２５】
２３は、ポリシルールのアクションパラメータの一部である。他のアクションパラメータとしては、サービスクラス定義エントリが持つＰＨＢ（Ｐｅｒ  Ｈｏｐ  Ｂｅｈａｖｉｏｒ）がある。これらの関連付けは以下のようになっている。
【００２６】
オペレーションの順序としては、まず、サービスエントリが生成され、次に、ポリシルールエントリが生成され、最後に、ポリシルールの内容がルータに設定されることを想定している。
【００２７】
まず、サービスエントリが持つサービスタイプ情報を基に、サービスクラス定義エントリを検索する。このサービスクラス定義エントリは、そのサービスクラスに対するＰＨＢと、ポリシルールフォーマットエントリを持つ。次に、このポリシルールフォーマットにしたがって、ポリシルールエントリを生成する。
【００２８】
ポリシルールエントリは、ポリシルールフォーマット情報をもつので、ポリシルールフォーマットが持つサービスタイプ情報からアクションパラメータとしてのＰＨＢ、Ｓｅｒｖｉｃｅ  ＩＤからアクションパラメータ２３を検索することができる。
【００２９】
以上により、データ容量を節約し、サービスクラス定義の変更に柔軟に対応できる状態で、全てのアクションパラメータをそろえる事ができる。
【００３０】
ｒｕｌｅＣｒｅａｔｉｏｎＳｔａｔｅ（ルールクリエーションステート）２４は、サービスエントリ１５（図２）を基に、ポリシ管理システムがルータへのポリシ設定のために使うポリシルールエントリ１６（図５）の生成済／否を表現するための属性である。なお、ポリシルールエントリ１６は１つのサービスエントリ１５に対して複数あるが、複数のポリシルールエントリの生成は一括して行う。ポリシ管理システムは、ｒｕｌｅＣｒｅａｔｉｏｎＳｔａｔｅ２４の値が「未生成」であるサービスエントリについて、サービスエントリ１５（図２）、ルールフォーマットエントリポリシ１７（図４）を基に、ポリシルールエントリ１６（図５）をサービスエントリ１５の下に生成する。
【００３１】
ｐｒｏｖｉｓｉｏｎｉｎｇ  ｄａｔｅ／ｕｎｐｒｏｖｉｓｉｏｎｉｎｇ  ｄａｔｅ（プロビジョニングデート／アンプロビジョニングデート）２５は、ポリシ管理システムからのポリシ設定／設定解除（プロビジョニング／アンプロビジョニング）動作を制御するもので、カスタマに提供するサービスとも連携している。つまり、カスタマが要求するサービス期間（Ｄａｔｅ  ｒａｎｇｅのＹｅａｒｓ等）を基に、キャリアの決めた方針（例えば、サービスの１日前にはプロビジョニングを完了する等。）でｐｒｏｖｉｓｉｏｎｉｎｇ  ｄａｔｅ／ｕｎｐｒｏｖｉｓｉｏｎｉｎｇ  ｄａｔｅ  ２５を決定／入力する。
【００３２】
２６は、このサービスエントリ、つまり、このサービスエントリから生成されたポリシルールエントリを設定した時の対象ＮＥ（ネットワークエレメント；ルータに相当する。）を設定したものである。
【００３３】
なお、図２中、ＲＤＮはＲｅｌａｔｉｖｅ  ｄｉｓｔｉｎｇｕｉｓｈｅｄ  Ｎａｍｅの略であり、Ｐ２Ｍは、ポイント・ツー・マルチポイントの略であり、Ｍ２Ｍはマルチポイント・ツー・マルチポイントの略であり、ｐＤＡはＰｒｉｍａｒｙ  Ｄｅｓｔｉｎａｔｉｏｎ  Ａｄｄｒｅｓｓ（現用経路用アドレス）の略であり、ｓＤＡはｓｅｃｏｎｄａｒｙ  Ｄｅｓｔｉｎａｔｉｏｎ  Ａｄｄｒｅｓｓ（迂回用経路用アドレス）の略であり、ＮＥは、Ｎｅｔｗｏｒｋ  Ｅｌｅｍｅｎｔの略である。
【００３４】
図３は、サービス定義エントリを整理したものである。３２で示される属性は、サービスタイプに対応するサービスがもつ特徴を表している。また、３３で示される属性は、そのサービスに適用すべきポリシルールフォーマットへのポインタである。
【００３５】
図４は、ポリシルールフォーマットエントリを整理したものである。  ｃｏｎｄｉｔｉｏｎ  ｐａｒａｍｅｔｅｒ４１は、そのポリシルールがもつべきコンディションパラメータを表している。同様にａｃｔｉｏｎ  ｐａｒａｍｅｔｅｒ４２は、そのルールがもつべきアクションパラメータを表している。ｔａｒｇｅｔ４３は、そのルールが適用されるべき装置対象であるネットワークエレメントを特定するものである。ｔａｅｇｅｔ４３には、サービスエントリ１５の２６に示す１又は複数の属性が入る。
【００３６】
図５は、ポリシルールエントリ１６を整理したものである。ポリシ管理システムは、このポリシルールエントリを基にポリシの設定をＮＥに対して行うこととなる。ＰｏｌｉｃｙＲｕｌｅＦｏｒｍａｔ５１は、そのルールのフォーマットを表すポリシルールフォーマットエントリ１７へのポインタである。つまり、ポリシルールフォーマットエントリ１７を参照することにより、ポリシルールが持つコンディションパラメータとアクションパラメータの内容を検索することができる。ｒｕｌｅＳｔａｔｅ（ルールステート）５２は、そのルールがＮＥに対して設定されたか否を表すものである。ｔａｒｇｅｔＮＥ（ターゲットネットワークエレメント）５３は、そのルールが適用されるべき装置対象であるネットワークエレメントを特定するものである。ｔａｒｇｅｔＮＥ５３には、サービスエントリ１５の２６に示す１又は複数の属性が入る。
【００３７】
図１〜５を参照してに、本発明の実施形態の動作を記述する。
【００３８】
先ず、カスタマケアシステムがサービスを受付けると、要求されたサービスに対応するサービス定義エントリ１８を基に、サービスエントリ１５を生成する。コンディションパラメータ群２２、ｐｒｏｖｉｓｉｏｎｉｎｇ  Ｄａｔｅ／Ｕｎｐｒｏｖｉｓｉｏｎｉｎｇ  ｄａｔｅ２５、Ｅｄｇｅ  Ｒｏｕｔｅｒ  ＩＤ（Ａ）、Ｅｄｇｅ  Ｒｏｕｔｅｒ  ＩＤ（Ｂ）２６は、サービス受付時の情報を基に生成される。次に、設計システムの設計サーバは、アクションパラメータ２３の一部を算出し、上記サービスエントリ１５に書き込む。その後、サービスエントリがもつ状態値ｓｅｒｖｉｃｅＳｔａｔｅを、”ｐｌａｎｎｅｄ”に設定する。更に、ポリシ管理システムが必要とするポリシルールエントリ生成のため、サービスエントリ１５の新規生成または変更時は、ｒｕｌｅＣｒｅａｔｉｏｎＳｔａｔｅ  ２４は、”Ｎｏｔ  ｃｒｅａｔｅｄ”に設定しておく。
次に、ポリシ管理システムが、上記ｓｅｒｖｉｃｅＳｔａｔｅとｒｕｌｅＣｒｅａｔｉｏｎＳｔａｔｅ２４を基に、ルールを生成すべきサービスエントリ１５を検索し、ポリシルール生成を行う。生成すべきポリシルールは、サービスエントリ１５の属性値ｓｅｒｖｉｃｅ  ｔｙｐｅ２１と、ｓｅｒｖｉｃｅ  ｔｙｐｅ２１に対応するサービス定義エントリ１８を基に判明する。ｔａｒｇｅｔＮＥ５３は、ｅｄｇｅ  ｒｏｕｔｅＩＤ２６とｔａｒｇｅｔ４３を参照すれば、解決できる。
【００３９】
上記動作例において、提供するサービス定義を変更する場合は、サービス定義エントリのみを変更することで対応できる。
【００４０】
上記動作例において、ルールのフォーマット、例えば、コンディションパラメータ２２の種類が減った場合、ディレクトリ内のポリシルールフォーマットエントリのみを変更することで対応できる。
【００４１】
本発明は、データ容量を削減する、変更に柔軟に対応することに関して、ＩＰ―ＶＰＮに限定すること無く、ディレクトリサーバを使う場合のＤＩＴ構成定義に利用できる。
【００４２】
【発明の効果】
以上説明したように、本発明によれば以下の効果が奏される
１点目は、カスタマケアシステムが生成するサービスエントリに、ポリシ管理システムが利用するポリシ関連データを集約し、ポリシ関連データは、上記サービスエントリを参照することで、データ容量を節約できることである。
【００４３】
２点目は、サービスエントリ内容を、ポリシルールとして解釈するためのフォーマットエントリを用いることで、ルールの変更に柔軟に対応できることである。
【００４４】
３点目は、サービス定義エントリを導入することで、サービス変更に柔軟に対応できることである。
【図面の簡単な説明】
【図１】本発明の実施形態によるＩＰサービス管理のためのサービス指向ＤＩＴ（Ｄｉｒｅｃｔｏｒｙ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｒｅｅ）構成を示す図である。
【図２】本発明の実施形態によるサービスエントリが含む属性を示す図である。
【図３】本発明の実施形態によるサービスクラス定義エントリが含む属性を示す図である。
【図４】本発明の実施形態によるポリシルールフォーマットエントリが含む属性を示す図である。
【図５】本発明の実施形態によるポリシルールエントリが含む属性を示す図である。
【符号の説明】
１１  カスタマ
１２  ネットワーク
１３  ポリシ
１４  システム
１５  サービスエントリ
１６  ポリシルールエントリ
１７  ポリシルールフォーマットエントリ
１８  サービスクラス定義エントリ
【図１】
0003569912.tif 000002
【図２】
0003569912.tif 000003
【図３】
0003569912.tif 000004
【図４】
0003569912.tif 000005
【図５】
0003569912.tif 000006