JP4707973B2 - 規則ベースのネットワークに規則を提供するトランザクションプロセス - Google Patents

Description

本発明は、規則ベースのネットワークに、特に、ＩＰプロトコル（インターネットプロトコル）およびＣＯＰＳ管理プロトコル（共通オープンポリシーサービスプロトコル）を使用するネットワークに、規則を提供するトランザクションプロセスに関する。

ＩＰネットワークおよびＴＣＰ制御プロトコル（伝送制御プロトコル）は既に知られている。

データの伝送を最適化し、サービス品質を向上させるために、クライアント機器が適用するように課せられた規則を、サーバがクライアント機器に伝送するネットワーク管理方法を指すＰＢＭ（ポリシーベースの管理）として知られるポリシーベースの（または規則ベースの）ネットワークの管理（または運営）も知られている。ポリシーは規則セットを含むことから、したがって、以降、「ポリシーベースのネットワークの管理」または「規則ベースのネットワークの管理」という用語を区別なしに用いる。規則ベースのネットワークの管理は、一般に、ＣＯＰＳプロトコルを含むが、ＰＥＰ ＰＤＰ（ポリシー執行ポイント／ポリシー決定ポイント）から提供規則をフェッチするためにＬＤＡＰプロトコル（軽量化ディレクトリアクセスプロトコル）も受け入れることができる。

ＣＯＰＳプロトコルは、要求／応答タイプのＩＰネットワーク管理プロトコルであり、ＴＣＰプロトコルに基づいている。ＣＯＰＳプロトコルは、規則ベースのネットワークの情況において規則またはポリシーを伝送するためにＩＥＴＦ（インターネットエンジニアリングタスクフォース）によって提案されている（Ｙａｖａｔｋａｒ Ｒ．，Ｐｅｎｄａｒａｋｉｓ Ｄ．，Ｇｕｅｒｉｎ Ｒ．，“Ａ Ｆｒａｍｅｗｏｒｋ ｆｏｒ Ｐｏｌｉｃｙ Ｂａｓｅｄ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ”，ＲＦＣ ２７５３，２０００）。ＣＯＰＳプロトコルは、ネットワークに組み込まれた要素間の規則の交換のためのモデルを提案する。例えば、その規則の目的は、ネットワークにおけるトラフィックのよりよい管理を確実にすることであり、特に、ネットワーク上で提供されるサービス品質を向上させることである。このモデルは、クライアント／サーバタイプのアーキテクチャを使用する。規則サーバ又はＰＤＰ（ポリシー決定ポイント）は、トラフィックの管理のための規則を準備し、データベースの中に集中化された情報を基にこれらの規則をクライアントに伝送する１つのネットワーク管理装置である。規則サーバクライアント、又はＰＥＰ（ポリシー執行ポイント）は、ネットワークのノードに配置された１つの装置である。ＰＥＰは、規則サーバによって伝送された情報を受信し、これを適用することが課せられている。これらのサーバクライアント、又はＰＥＰは、一般に、ルータ、スイッチ、またはファイアウォールであるが、それ自体、ルータ、スイッチ、コンピュータなどのネットワーク要素と通信しているサーバであることも可能である。

規則ベースのネットワークの管理は、ネットワークの挙動を決める規則を使用する。その規則を適用すること自体は、ネットワーク内の要素のそれぞれが果たす役割、ならびに適宜、ネットワークのエージェントが果たす役割の定義に関わる。エージェントは、例えば、エージェントと直接に通信するなど、環境を認識し、環境に作用する能力を有する、それ自体のリソースを所有している物理エンティティまたは仮想エンティティとして定義される。これらのエージェントは、ＰＥＰによってローカルで管理されることが可能なルータ、スイッチ、コンピュータなどのネットワーク要素の間で分割かれている。所定の役割は、一群の要素またはエージェントに帰属させることができ、これは、そのような役割を有する少なくとも１つの要素またはエージェントが常に存在することを意味する。モデル役割のなかには、ビジネス役割、財務役割などが存在する。さらに、１つまたは複数の規則が役割に関連することが可能である。これらの役割の定義は重要であり、これは、その定義が、対応する規則により影響を及ぼされるネットワークの部分を決定するからである。

サービスの提供は、ネットワーク内の要素またはエージェントに、遠隔通信サービスへのアクセスをその要素またはエージェントに提供するのに必要なリソースを提供することから成る動作である。規則によるネットワーク管理が存在しない場合、ネットワークオペレータは、クライアントにサービスを提供するために、要素ごとに、またはエージェントごとに、ネットワークを構成しなければならない。その場合、誤りが生じた場合、または提供プロセス中に動作に障害が生じた場合、オペレータは、手動で、提供の順序を逆にして、問題を解決することができる。

代わりに、この提供は、ＰＥＰから要素またはエージェントに、ローカルに管理されることが可能である。役割の概念を使用する場合、ネットワークのエージェントまたは要素からのサービスの提供は、そのエージェントまたは要素に帰属させられた役割に依存する。そして、所与の役割を有するエージェントまたは要素のすべてが、所与のタイプの提供の恩恵を自動的に受けることができる。しかしながら、ネットワーク内の複数のエージェントからのサービスの提供中に誤りが生じた場合、または動作に障害が生じた場合、既に提供を受けている要素のすべての提供を解除することが必要になる。

この問題に対する知られている解決策は、オペレータによりすべてのエージェントを手動で提供から解除することである。しかしながら、ネットワーク内の要素の構成を頻繁に構成すること、または変更することは避けた方がよく、これは、そのような操作は、ネットワークのパフォーマンスを低下させ、時間およびオペレータの点で非常に大きな投資も伴うからである。

要素における提供を確保する解決策も提案されている。そのような解決策は、例えば、英国特許出願ＵＫ２３７１６４６号に記載されている。この解決策によれば、要素は、要求を展開する前に、提供要求を検証する。これを達するため、要素は、問題が生じた場合、または１つのモジュールがアクティブであり、第１のモジュールが問題に遭遇した際に第２のモジュールがアクティブになる用意ができている冗長なアーキテクチャの場合に、要素が元の構成を復元することを可能にするメモリを備えている。

しかしながら、この解決策は、少なくとも２つの理由で適切ではない。第１に、この解決策は、要素の複雑なアーキテクチャを必要とし、したがって、費用の増加、ならびに要素内部に複雑な機構が実装されることを要する。第２に、この解決策は、個々に取り上げられた各要素にだけ関する。言い換えれば、各要素自体が、提供プロセスが正しく実行されているか否かを調べ、したがって、所与の役割を有する要素（またはエージェント）のすべてが提供プロセスを正しく実行できることを確実にするリソースは全く提供されない。したがって、要素上の問題のケースで前述したのと同じ大きな欠点がやはり見られ、多数の要素またはエージェントに対する提供を解除する必要がある可能性がある。
英国特許出願公開２３７１６４６号明細書 Ｙａｖａｔｋａｒ Ｒ．，Ｐｅｎｄａｒａｋｉｓ Ｄ．，Ｇｕｅｒｉｎ Ｒ．，"Ａ Ｆｒａｍｅｗｏｒｋ ｆｏｒ Ｐｏｌｉｃｙ Ｂａｓｅｄ Ａｄｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ"，ＲＦＣ ２７５３，２０００

したがって、我々が、ネットワーク内の要素に対する提供を解除することを回避することを可能とする、提供プロセスの必要性が存在する。

したがって、本発明は、規則サーバとサーバクライアントとを含むネットワークにおける規則を提供するトランザクションプロセスを提案し、トランザクションプロセスは、（ａ）規則セットの提供を受け入れる要求をサーバからクライアントに伝送する段階と、（ｂ）要求がクライアントによって受け入れられた場合、規則の受信と適用のために必要なリソースをクライアントが確保する段階と、（ｃ）クライアントからサーバへへ要求に対して応答する段階と、（ｄ）段階（ｃ）における応答が肯定的であった場合、規則のすべてをサーバからクライアントに提供する段階を含む。

好ましい実施形態では、本発明は、以下の特徴の１つまたは複数を含む。

−いくつかのクライアントを含むネットワークにおいて、本発明に従ったプロセスの段階（ａ）、（ｂ）、および（ｃ）が、クライアントのそれぞれに関して実行され、各々が、段階（ｃ）中にサーバからの要求に応答し、各クライアント応答が肯定的である場合にだけ、提供する段階（ｄ）が実行される。

−本発明によるプロセスは、クライアント応答が肯定的でない場合、段階（ｂ）においてクライアントによって確保されたリソースを解放するための段階（ｅ）も含む。

−本発明に従ったプロセスは、要求に対する応答が肯定的でなかった場合、クライアントからサーバに誤りメッセージを伝送するための段階（ｃ’）も含む。

−規則マネージャを含むネットワークにおいて、本発明によるプロセスは、段階（ｃ’）において送信された誤りメッセージの中に含まれる情報の少なくとも一部を含むメッセージをサーバから規則マネージャに伝送するための段階（ｃ”）も含む。

−いくつかのネットワーク要素、サーバクライアントのクライアント、およびネットワーク要素マネージャも含むネットワークにおいて、段階（ｂ）におけるクライアントによるリソースの確保が、サーバクライアントとネットワーク要素マネージャの間の予備的な通信段階（ａ’）に続いて実行される。

−ネットワーク要素マネージャは、サーバクライアントの一体部分であるため、通信段階（ａ’）は、クライアントサーバ内部における内部動作である。

本発明は、そのようなプロセスを実施するリソースを有する規則サーバも範囲に含む。

次に、単に例として提示し、添付の図面を参照する現行の好ましい実施形態の以下の説明において、本発明をより詳細に説明する。

本発明は、ネットワークにおける規則の提供のためのトランザクションプロセスを提供する。このネットワークは、少なくとも１つの規則サーバ（ＰＤＰ）と、少なくとも１つの規則サーバクライアント（ＰＥＰ）とを含む。本発明によるトランザクションプロセスは、規則セットの提供を受け入れる要求をサーバからクライアントに伝送する第１の段階を含む。プロセスは、要求がクライアントによって受け入れられる場合、規則の受信と適用のために必要なリソースをクライアントが確保する、第２の段階を含む。プロセスは、クライアントからサーバへ要求に対して応答する第３の段階、及び、要求に対するクライアントの応答が肯定的であった場合、サーバからクライアントにすべての規則を提供するための第４の段階を含む。したがって、提供は、規則の受信および適用のために必要なリソースが実際に利用可能であるとクライアントによって前もって検証されている場合にだけ、実行されることが可能である。したがって、提供プロセス中または提供プロセス後に、不必要に時間と費用がかかる提供解除プロセスを要する、障害または誤りを回避することが可能である。さらに、規則セットを担うトランザクション機構の使用は、要求に対するクライアントの応答中にも、サーバによるクライアントへの提供中にもトランザクションの原子性を保証する。したがって、提供プロセスは、ネットワークにおける要素に対する提供解除を回避することが可能になる。ネットワークがいくつかのクライアントを含む場合、クライアントのそれぞれが、サーバからの要求に応答し、提供段階は、各クライアントの応答が肯定的である場合にだけ実行される。したがって、提供プロセスは、クライアントのいずれかが否定的に応答した場合に、いくつかのクライアントに対して提供解除を行うことを回避することを可能とする。

図１は、本発明によるプロセスの段階を示す流れ図であり、この例ではサーバとサーバクライアントが関与している。このサーバとこのサーバクライアントがネットワークを形成し、したがって、ネットワークは、クライアント／サーバタイプのアーキテクチャを有する。次に、本発明によるプロセスを図１に示した例を参照して説明する。

本発明によるプロセスは、規則セットの提供を受け入れる要求を、サーバからサーバクライアントに伝送する第１の段階（ａ）を含む。したがって、要求は、規則セットに関するトランザクションに関わる。これは、要求が、その規則セットの一般的な特性（受信のため、および、該当する場合、規則を適用するため、または規則を実行するために必要なリソースなど）を含むことを意味する。いずれにしても、要求は、その規則を適用するため、またはその規則を実行するために必要なコードおよび／またはデータの全体を含むわけではない。

プロセスは、要求がクライアントによって受け入れられた場合、規則の受信と適用のために必要なリソースをクライアントが確保する第２の段階（ｂ）を含む。例えば、適用の原理は、次のとおりとすることが可能である。要求は、ＰＥＰによって管理されるネットワークのローカル部分において利用可能なリソースが、これらの規則を受信し、そして適用する、または実行するのを可能にするのに十分であるときに、ＰＥＰによって受け入れられる。したがって、リソースの確保は、要求に適合される。

次に、プロセスは、クライアントからサーバへ要求に対して応答する第３の段階（ｃ）を含む。この実施形態では、応答は明示的であり、これは、ＰＥＰが応答をＰＤＰに送信することを意味する。

例えば、要求がクライアントまたはＰＥＰによって受け入れられる場合、クライアントは、「はい」の値、または任意の他の論理値（例えば、１、「はい」、真など）をブール関数に割り当てることができ、要求に適切なリソースを確保することができる。次に、プロセスは、クライアントからサーバにブール関数を伝送するための段階（ｃ）を含む。次に、第４の段階（ｄ）でブール関数の値が「はい」であった場合、トランザクションがＰＤＰによって有効化される。トランザクションの有効化は、後の時点で適用する、または実行する目的で、要求に関わる規則セットに一括してグループ化された規則（規則の内容を含む）のすべてを提供すること（例えば、ダウンロード動作）の形態をとる。

ブール関数に対する論理値の割り当ては、トランザクションの有効化に先立って実行される。トランザクション有効化の後、すべての規則の適用に必要なコードまたはデータを、例えば、ダウンロードし、かつ／または実行することが可能である。

したがって、サーバクライアントにおけるトランザクションは、必要なリソースが実際に利用可能であると前もって検証済みである場合にだけ、または（例えば、トラフィックのような）ネットワークまたはネットワークの一部の状態などのサーバクライアントが認識する責任を負う他の基準に従って実行されることが可能である。したがって、提供中（例えば、ダウンロード中）、または提供後（適用する際）に、不必要な長い時間と費用がかかる提供解除の動作を要する障害または誤りが回避される。さらに、規則セットに関わるトランザクション機構の使用は、ＰＤＰによって提供されなければならないすべての規則の原子性を保証する。規則セットの原子性は、要求に対する応答の段階（例えば、必要なリソースが実際に利用可能であるとＰＥＰが検証する際）にも、規則の適用につながるトランザクション有効化の段階にも等しく該当する。

変形形態では、クライアントのサーバに対する応答は暗示的である。そのような場合、サーバは、例えば、所定期間の満了後、クライアントからの応答は既定の応答であると見なす。既定の応答は、肯定的とすることが可能であり、サーバは、その同じ所定期間中に相反する命令を何も受け取らなかった場合、前記期間が満了した時、応答は肯定的であると見なす。

図２は、本発明に従ったプロセスの段階を示す流れ図であり、今回は、サーバといくつかのサーバクライアントが関与している。実際、ネットワークがＮ個のサーバクライアントまたはＰＤＰを含む場合（ただし、Ｎは、任意の整数である）、サーバによってクライアントまたはＰＥＰのそれぞれに要求が送信され（段階ａ）、合計でＮ個の要求が行われるものとして本発明を考えるのがよい。リソースの０個からＮ個の確保が、これらのリソースの利用可能性に従ってＮ個のサーバクライアントの間で実行され（段階ｂ）、次に、クライアントのそれぞれによって応答が送信されて、合計でＮ個の応答が行われる。例として、応答に対応する論理値がブール関数に割り当てられる。次に、Ｎ個の応答がサーバに送信され（段階ｃ）、サーバによって検査されるＮ個の要求が肯定的であった場合にだけ、トランザクションがサーバにおいて有効化される（提供段階ｄ）。したがって、本発明からもたらされる利点は、Ｎが増加するにつれて増加する。適宜、サーバクライアントのそれぞれは、段階（ａ）で送信された要求がこれらのクライアントのそれぞれのレベルで受け入れられなかった場合（段階ｃ’）、誤りメッセージを送信する責任を負う。すると、サーバは、誤りの原因を分析することができるネットワークの他のエンティティに、適宜、その情報を伝送するために必要な情報を有する。

さらに、クライアントの少なくとも１つが、段階（ａ）で送信された要求を拒否した場合、サーバは、その要求を以前に受け入れているクライアントのすべての間で以前に確保されているリソースの解放（段階ｅ）を命令することができる。この実施形態では、要求を受け入れたクライアントによって確保されたリソースを解放するこの段階は、サーバクライアントに対する適切なメッセージの伝送により、サーバによって明示的に示されることが可能である。

変形形態では、リソースを解放する段階は、自動的な形で、つまり、サーバによるクライアントに対するメッセージの伝送を必要とすることなく、所定のタイムアウトの終了時に実行されることが可能である。このタイムアウトが満了したときに、各サーバクライアントが、以前に確保されているリソースを解放する。

本発明によるプロセスは、応答が否定的であった場合、要求を変更し、および第１の段階に戻ることも含むことが可能である。これは、少なくとも１つのＰＥＰがトランザクション要求を拒否した場合（例えば、対応するブール関数に帰属させられる値が、このケースでは、「いいえ」である）、トランザクション要求は、ＰＤＰによって有効化されず、提供は実行されない。それでも、ＰＤＰは、ネットワークエンティティ（規則マネージャなどの）にその障害を知らせることができる。すると、規則マネージャが、１つまたは複数の規則を生成し、または変更して、その生成された、または変更された規則をＰＤＰに伝送し、次に、ＰＤＰが、新しい要求をＰＥＰにサブミットすることができる。

代替は、要求を変更することではなく、単にタイムアウト後に要求を再びサブミットすることとすることが可能である。

そのような動作は、障害の原因を調べた後、規則提供動作が行われる前に、要求を新たにサブミットすることが可能になる。したがって、（ｉ）提供解除を回避することができ、（ｉｉ）要求を変更する、あるいは要求を再びサブミットして成功させる目的でタイムアウトを動作させる機会が提供され、かつ（ｉｉｉ）すべての規則の原子性が保証される。詳細には、変更は、例えば、関与するネットワークの部分（トラフィックなどの）の使用の条件に従って、可能な場合、リアルタイムで、クライアントから利用可能なリソースに従って要求を適合させることを目的とすることが可能である。

この目的で、本発明によるプロセスは、クライアントの応答が否定的であった場合、サーバクライアントからサーバに誤りメッセージを伝送するための別の段階（ｃ’）も含むことが可能である。この段階は、段階ｂよりも後である。このような段階は、要求に関して否定的な応答が発せられた理由をＰＤＰに知らせるような性質のものである。

次に、ＰＤＰが、ポリシーマネージャまたは規則マネージャなどのネットワーク内の別のエンティティにメッセージを送信することができる（段階ｃ”）。このメッセージは、段階ｃ’で送られた誤りメッセージの中に含まれる情報の少なくとも一部を含むことが可能である。ＰＤＰによって送信されるメッセージを受信するネットワーク内のエンティティは、障害の原因を分析するのに必要なツールを備えていることが可能である。

これを達するために、プロセスは、誤りメッセージをモデル誤りメッセージを含むデータベースと比較するための段階も含むことが可能である。そのような比較は、規則マネージャなどのネットワークエンティティのレベルで実行することが可能であり、場合により、詳細にすることができる。これは、送信された誤りメッセージとの最良の合致を示すモデルメッセージの選択をデータベース内で可能にするように、誤りメッセージの特性を分析できることを意味する。例えば、合致のレベルが十分でないと考えられるときに、最適なモデルメッセージが拒否される場合、適宜、障害メッセージが選択されることが可能である。したがって、この選択段階は、適切なモデルメッセージが選択されることが可能になる。データベースの中に含まれるそれらのモデルメッセージに対して、誤りに対処するのに使用することができる、あるいは少なくとも適切な動作を実行することができるモデルルーチンが対応する。データベースの中でメッセージが選択された時点で、ネットワークエンティティは、関連するモデルルーチンの実行を命令することができる。したがって、新しい要求を伝送する目的でＰＤＰに伝送する前に、規則は、選択されたモデルルーチンの実行中に生成され、または変更されることが可能である。したがって、規則の生成または変更は、提供の障害に関して既に得られている経験に関連して最適であるような形で行われる。

ネットワークは、それ自体がＰＥＰのクライアントであるいくつかのネットワーク要素（またはネットワークエージェントさえ）も含むことが可能である。したがって、これらの要素は、ＰＥＰと通信することが可能である。ＰＥＰの応答が、ＰＥＰとネットワーク要素の間で通信する段階の後に、またはＰＥＰによるネットワーク要素マネージャの問い合わせの後に実行されようにすることも有利である。そのようなマネージャは、実際、要素管理レイヤ（ＥＭＬ）のやり方にならって、ネットワークの要素に対して構成動作およびメンテナンス動作を実行できることが可能である。その機能は、要素マネージャが、必要な場合、リアルタイムで、要素の状態を認識しているように整える。したがって、問い合わせることは、ＰＥＰが、ネットワーク要素の状態を確かめることを可能とし、その情報に基づいて、肯定的な、またはそうでない応答を形成すること、又は、言い換えれば、要求を受け入れること、または拒否することを可能とする。

適切な場合、要素マネージャは、ＰＥＰの一体部分とすることが可能であり、これは、ＰＥＰが、ネットワーク要素マネージャに特有のタスクを実行できることを意味する。そのような場合、ＰＥＰは、必要な場合、リアルタイムで、ネットワークの要素の状態を知っている。したがって、ＰＥＰは、ネットワークの要素に関してそれが所有する知識に基づいて、要求を受け入れること、または拒否することができる。

したがって、ＰＥＰは、それが管理するネットワークの部分の状態を確かめた後、要求を受け入れること、または拒否することができる。特に、ネットワークのその部分の状態は、その部分において利用可能なリソースに関わる。したがって、（ｉ）要求の受け入れ、または拒否は、ＰＥＰによる要求の受信の時点におけるＰＥＰのクライアントネットワーク要素の状態を考えて行うことが可能であり、（ｉｉ）提供の解除が回避され、かつ（ｉｉｉ）規則トランザクションの原子性が保証される。

しかしながら、本発明は、前述した種類の形態に限定されず、当業者が容易に利用できるあらゆる数の他の変形形態をとることが可能である。

サーバとサーバクライアントが関与する、本発明に従ったプロセスの段階を示す流れ図である。 サーバといくつかのサーバクライアントが関与する、本発明に従ったプロセスの段階を示す流れ図である。

Claims (6)

1. 規則サーバとサーバクライアントとを含むネットワークにおける規則を提供するトランザクションプロセスであって、
   （ａ）規則セットの提供を受け入れる要求をサーバからクライアントに伝送する段階と、
   （ｂ）要求がクライアントによって受け入れられた場合、規則の受信と適用のために必要なリソースをクライアントが確保する段階と、
   （ｃ）クライアントからサーバへ要求に対して応答する段階と、
   （ｄ）段階（ｃ）における応答が肯定的であった場合、規則のすべてをサーバからクライアントに提供する段階と、
   （ｃ’）要求に対する応答が肯定的でない場合、クライアントからサーバに誤りメッセージを伝送する段階と、
   （ｆ）誤りメッセージをモデル誤りメッセージを含むデータベースと比較する段階とを含み、
   ネットワークが、いくつかのクライアントを含み、段階（ａ）、（ｂ）、および（ｃ）が、クライアントのそれぞれに関して実行され、各々が、段階（ｃ）中にサーバからの要求に応答し、各クライアント応答が肯定的である場合にだけ、提供する段階（ｄ）が実行される、プロセス。
2. クライアント応答が肯定的でない場合、段階（ｂ）においてクライアントによって確保されたリソースを解放する段階（ｅ）も含む請求項１に記載のプロセス。
3. ネットワークが、規則マネージャも含み、
   段階（ｃ’）において送信された誤りメッセージの中に含まれる情報の少なくとも一部を含むメッセージをサーバから規則マネージャに伝送する段階（ｃ”）も含む請求項１に記載のプロセス。
4. ネットワークが、サーバクライアントのクライアントであるいくつかのネットワーク要素と、ネットワーク要素マネージャとを含み、
   段階（ｂ）におけるクライアントによるリソースの確保が、サーバクライアントとネットワーク要素マネージャの間の通信の予備的な段階（ａ’）に続いて実行される請求項１に記載のプロセス。
5. ネットワーク要素マネージャが、サーバクライアントの一体部分であり、通信段階（ａ’）が、サーバクライアント内部の動作である請求項１から４のいずれか一項に記載のプロセス。
6. 請求項１から５のいずれか一項に記載のプロセスを実行するリソースを有する規則サーバ。

Images