JP6896722B2

JP6896722B2 - リソースコンフィギュレーション方法および装置

Info

Publication number: JP6896722B2
Application number: JP2018520419A
Authority: JP
Inventors: シュ、ウェイピン; リウ、シュチェン
Original assignee: ホアウェイ・テクノロジーズ・カンパニー・リミテッド
Priority date: 2015-10-23
Filing date: 2016-10-19
Publication date: 2021-06-30
Anticipated expiration: 2036-10-19
Also published as: EP3358785A1; KR102128356B1; US20180241689A1; JP7207827B2; WO2017067464A1; CN106612196B; CN106612196A; EP3358785B1; JP2018533872A; EP3358785A4; US10979360B2; KR20180070677A; JP2020109996A

Description

本出願は、２０１５年１０月２３日に中国特許庁に出願された、「リソース取得方法および装置」と題する中国特許出願第ＣＮ２０１５１０６９７５６３．５号に基づく優先権を主張し、その全体が参照により本明細書に組み込まれる。

本出願は、通信分野に関し、特には、リソース取得方法と、サーバサイドとして使用される装置と、クライアントとして使用される装置とに関する。

ＮＥＴＣＯＮＦプロトコルは、インターネットエンジニアリングタスクフォース（ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ、ＩＥＴＦ）のＮＥＴＣＯＮＦ作業部会によって立ち上げられた新しいネットワークコンフィギュレーションプロトコル（ＮｅｔｗｏｒｋＣｏｎｆｉｇｕｒａｔｉｏｎＰｒｏｔｏｃｏｌ）である。ネットワーク管理におけるＮＥＴＣＯＮＦの機能は、簡易ネットワーク管理プロトコル（ＳｉｍｐｌｅＮｅｔｗｏｒｋＭａｎａｇｅｍｅｎｔＰｒｏｔｏｃｏｌ、ＳＮＭＰ）と類似しており、ネットワークマネージャとデバイスとの間のインタフェースインタラクションおよびデータ伝送に使用される。ネットワーク環境において、リソースマネージャは、インターネットプロトコル（ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ、ＩＰ）アドレスプールおよび転送エントリなどのネットワークデバイスの複数のリソースを合わせて管理するよう構成される。ＮＥＴＣＯＮＦプロトコルは、リソースマネージャとネットワークデバイスとの間で使用され、リソースマネージャは、ＮＥＴＣＯＮＦプロトコルに基づいてリソースをネットワークデバイスに割り当て得る。現在のリソース割り当て方式においては、リソース浪費問題が存在する。

本出願は、リソース取得方法と、サーバサイドとして使用される装置と、クライアントとして使用される装置とを提供し、これにより、リソースの節約を助ける。

上述の目的を達成すべく、本出願は以下の技術的解決手段を提供する。

本出願の第１態様は、リソース取得方法を提供する。当該方法は、サーバサイドによって要求されるリソースについての情報を含むリソース要求をサーバサイドが取得し、リソース要求をクライアントに送信する段階と、サーバサイドに割り当てられるリソースについての情報を含む、クライアントによって送信されたリソース応答をサーバサイドが受信する段階とを備える。

本出願の第２態様は、別のリソース取得方法を提供する。当該方法は、サーバサイドによって要求されるリソースについての情報を含む、サーバサイドによって送信されたリソース要求をクライアントが受信し、サーバサイドに割り当てられるリソースについての情報を、サーバサイドによって要求されるリソースについての、リソース要求に含まれる情報にしたがって取得する段階と、サーバサイドに割り当てられるリソースについての情報を含むリソース応答をサーバサイドにクライアントが送信する段階とを備える。

上述の２つの態様から、本出願の実施形態において提供されるリソース取得方法では、サーバサイドは、サーバサイドによって要求されるリソースについての情報を含むリソース要求を取得することが分かる。サーバサイドは、リソース要求をクライアントに送信する。リソース要求を受信した後、クライアントは、サーバサイドに割り当てられるリソースについての情報を、サーバサイドによって要求されるリソースについての情報にしたがって取得する。クライアントは、サーバサイドに割り当てられるリソースについての情報を含むリソース応答をサーバサイドに送信する。本出願の実施形態において提供される方法では、サーバサイドは、リソースを要求するために使用されるリソース要求をクライアントに対してアクティブに送信し、サーバサイドのリソース要求にしたがってクライアントによってサーバサイドに割り当てられるリソースは、サーバサイドの実際の要件をより良く満たすことができ、それによって、リソースを浪費する可能性の低減を助ける。

第１態様の実装例において、リソース要求をサーバサイドが取得する段階の前に、当該方法はさらに、サーバサイドによって使用されるリソースが条件を満たすかをサーバサイドが判断する段階を備え、当該条件は、サーバサイドのリソース使用量を表すために使用される。本実装例に基づいて、サーバサイドは、サーバサイドによって使用されるリソースが当該条件を満たすと判断したとき、サーバサイドによって使用されるリソースおよび当該条件にしたがってリソース要求をサーバサイドが生成するという具体的な実装例においてリソース要求を取得する。

サーバサイドは、リソース使用量に応じたリソース要求を送信する。したがって、要求されるリソースはサーバサイドの要件を満たし、それによって、リソースの浪費をさらに低減する。

第１態様の別の実装例において、当該方法はさらに、サーバサイドとアクティブクライアントとの間の通信が正常であると判断したとき、アクティブクライアントをクライアントとしてサーバサイドが選択する段階を備える。

第１態様の別の実装例において、当該方法はさらに、サーバサイドとアクティブクライアントとの間の通信が異常であると判断したとき、対応関係およびアクティブクライアントにしたがって、スタンバイクライアントをクライアントとしてサーバサイドが選択する段階を備え、当該対応関係は、アクティブクライアントについての情報およびスタンバイクライアントについての情報を含む。

アクティブクライアントおよびスタンバイクライアントの両方が存在するとき、サーバサイドは１つのクライアントのみにリソース要求を送信し、これにより、伝送リソースが低減され得ることが分かる。

本出願の第３態様は、サーバサイドとして使用される装置を提供する。当該装置は、リソース要求を取得するよう構成される取得モジュールであって、リソース要求は、サーバサイドとして使用される装置によって要求されるリソースについての情報を含む、取得モジュールと、クライアントとして使用される装置にリソース要求を送信するよう構成される送信モジュールと、クライアントとして使用される装置によって送信されたリソース応答を受信するよう構成される受信モジュールであって、リソース応答は、サーバサイドとして使用される装置に割り当てられるリソースについての情報を含む、受信モジュールとを備える。

第３態様において提供される、サーバサイドとして使用される装置は、クライアントとして使用される装置にリソース要求をアクティブに送信し、それによって、リソースを浪費する可能性の低減を助ける。

任意選択で、第３態様の実装例において、当該装置はさらに、サーバサイドとして使用される装置によって使用されるリソースが条件を満たすかを判断するよう構成される判断モジュールを備え、当該条件は、サーバサイドとして使用される装置のリソース使用量を表すために使用される。

任意選択で、第３態様の上述の実装例に基づいて、第１の取得モジュールは、サーバサイドとして使用される装置によって使用されるリソースが当該条件を満たすと判断したとき、サーバサイドとして使用される装置によって使用されるリソースと当該条件とにしたがってリソース要求を生成するという具体的な実装例においてリソース要求を取得する。

第３態様の別の実装例において、当該装置はさらに、クライアントとして使用される装置にリソース要求を第１の送信モジュールが送信する前に、サーバサイドとして使用される装置とクライアントとして使用されるアクティブ装置との間の通信が正常であると判断したとき、クライアントとして使用されるアクティブ装置を、クライアントとして使用される装置として選択するよう構成される第１の選択モジュールを備える。

第３態様の別の実装例において、当該装置はさらに、クライアントとして使用される装置にリソース要求を第１の送信モジュールが送信する前に、サーバサイドとして使用される装置とクライアントとして使用されるアクティブ装置との間の通信が異常であると判断したとき、対応関係と、クライアントとして使用されるアクティブ装置とにしたがって、クライアントとして使用されるスタンバイ装置をクライアントとして使用される装置として選択するよう構成される第２の選択モジュールを備え、対応関係は、クライアントとして使用されるアクティブ装置についての情報と、クライアントとして使用されるスタンバイ装置についての情報とを含む。

本出願の第４態様は、クライアントとして使用される装置を提供する。当該装置は、サーバサイドとして使用される装置によって送信されたリソース要求を受信するよう構成される受信モジュールであって、当該リソース要求は、サーバサイドとして使用される装置によって要求されるリソースについての情報を含む、受信モジュールと、サーバサイドとして使用される装置に割り当てられるリソースについての情報を、サーバサイドとして使用される装置によって要求されるリソースについての、リソース要求に含まれる情報にしたがって取得するよう構成される取得モジュールと、サーバサイドとして使用される装置にリソース応答を送信するよう構成される送信モジュールであって、当該リソース応答は、サーバサイドとして使用される装置に割り当てられるリソースについての情報を含む、送信モジュールとを備える。

本出願の第５態様は、サーバサイドとして使用される装置を提供する。当該装置は、プロセッサと、プロセッサと共に使用されるメモリと、通信インタフェースとを備える。メモリは、リソース取得機能を実現するプログラムを格納し、プロセッサは、リソース要求を取得する機能であって、当該リソース要求は、サーバサイドとして使用される装置によって要求されるリソースについての情報を含む、機能と、クライアントとして使用される装置にリソース要求を送信する機能と、クライアントとして使用される装置によって送信されたリソース応答を受信する機能であって、当該リソース応答は、サーバサイドとして使用される装置に割り当てられるリソースについての情報を含む、機能とを、メモリおよび通信インタフェース内のプログラムを呼び出すことによって実現する。

本出願の第６態様は、クライアントとして使用される装置を提供する。当該装置は、プロセッサと、プロセッサと共に使用されるメモリと、通信インタフェースとを備える。メモリは、リソース取得機能を実現するプログラムを格納し、プロセッサは、サーバサイドとして使用される装置によって送信されたリソース要求を受信する機能であって、当該リソース要求は、サーバサイドとして使用される装置によって要求されるリソースについての情報を含む、機能と、サーバサイドとして使用される装置によって要求されるリソースについての、リソース要求に含まれる情報にしたがって、サーバサイドとして使用される装置に割り当てられるリソースについての情報を取得する機能と、サーバサイドとして使用される装置にリソース応答を送信する機能であって、当該リソース応答は、サーバサイドとして使用される装置に割り当てられるリソースについての情報を含む、機能とを、メモリおよび通信インタフェース内のプログラムを呼び出すことによって実現する。

本出願の第１態様、第２態様、第３態様、第４態様、第５態様、および第６態様のいくつかの実装例において、リソース要求は、ネットワークコンフィギュレーションＮＥＴＣＯＮＦプロトコルに基づく通知（Ｎｏｔｉｆｉｃａｔｉｏｎ）メッセージを備え、Ｎｏｔｉｆｉｃａｔｉｏｎメッセージは、サーバサイドによって要求されるリソースについての情報を有し、リソース応答は、ＮＥＴＣＯＮＦプロトコルに基づくリモートプロシージャコールＲＰＣメッセージを備え、ＲＰＣメッセージは、サーバサイドに割り当てられるリソースについての情報を有する。

本出願の第１態様、第２態様、第３態様、第４態様、第５態様、および第６態様のいくつかの実装例において、リソース要求は、ＲＥＳＴＣＯＮＦプロトコルに基づくＮｏｔｉｆｉｃａｔｉｏｎメッセージを備え、Ｎｏｔｉｆｉｃａｔｉｏｎメッセージは、サーバサイドによって要求されるリソースについての情報を有し、リソース応答は、ＲＥＳＴＣＯＮＦプロトコルに基づくポスト（ＰＯＳＴ）メッセージを備え、ＰＯＳＴメッセージは、サーバサイドに割り当てられるリソースについての情報を有する。

本出願の第１態様、第２態様、第３態様、第４態様、第５態様、および第６態様のいくつかの実装例において、リソース要求は取得メッセージを備え、取得メッセージは、サーバサイドによって要求されるリソースについての情報を有し、リソース応答は、応答メッセージを備え、応答メッセージは、サーバサイドに割り当てられるリソースについての情報を有し、応答メッセージは、取得メッセージに応答するために使用される。

本出願の第１態様、第２態様、第３態様、第４態様、第５態様、および第６態様のいくつかの実装例において、サーバサイドによって要求されるリソースについての情報は、第１のアクションタイプと、サーバサイドによって要求されるリソースのパラメータとを含み、第１のアクションタイプは、サーバサイドによって要求されるリソースに対して実行される操作を表すために使用され、サーバサイドに割り当てられるリソースについての情報は、第２のアクションタイプと、サーバサイドに割り当てられるリソースのパラメータとを含み、第２のアクションタイプは、サーバサイドに割り当てられるリソースに対して実行される操作を表すために使用される。

本出願の第１態様、第２態様、第３態様、第４態様、第５態様、および第６態様のいくつか実装例において、サーバサイドによって要求されるリソースについての情報は、第１のアクションタイプと、第１の識別子と、サーバサイドによって要求されるリソースのパラメータとを含み、第１のアクションタイプは、サーバサイドによって要求されるリソースに対して実行される操作を表すために使用され、第１の識別子は、リソース要求の順序を表すために使用され、サーバサイドに割り当てられるリソースについての情報は、第２の識別子と、サーバサイドに割り当てられるリソースのパラメータとを含み、第２の識別子は、リソース応答の順序を表すために使用され、第２の識別子は、第１の識別子に対応している。

クライアントおよびサーバサイドがＮＥＴＣＯＮＦプロトコルを使用することによってリソースコンフィギュレーションを実行する概略図である。

本出願の一実施形態に係るリソース取得方法のフローチャートである。

本出願の一実施形態に係る別のリソース取得方法のフローチャートである。

アクティブクライアントおよびスタンバイクライアントがＮＥＴＣＯＮＦプロトコルを使用することによってサーバサイドと通信する概略図である。

本出願の一実施形態に係る、サーバサイドとして使用される装置の概略構造図である。

本出願の一実施形態に係る、クライアントとして使用される装置の概略構造図である。

本出願の一実施形態に係る、サーバサイドとして使用される別の装置の概略構造図である。

本出願の一実施形態に係る、クライアントとして使用される別の装置の概略構造図である。

共通のリソースコンフィギュレーションプロセスにおいて、クライアントとして使用されるリソース管理デバイスとサーバサイドとして使用されるネットワークデバイスとの間で、ＮＥＴＣＯＮＦプロトコルを使用することによってリソースコンフィギュレーションが実行されてよい。例えば、図１に示すシナリオにおいて、クライアントとして使用されるリソース管理デバイスは、サーバサイドとして使用されるネットワークデバイスにアドレス範囲を送信し、アドレス範囲は、サーバサイドとして使用されるネットワークデバイスが使用するためにコンフィギュレーションされるアドレス範囲である。ネットワークデバイスは、アドレス範囲にしたがってアドレスプールを作成する。リソース管理デバイスは、手動設定にしたがってアドレス範囲を選択する。したがって、ネットワークデバイスのアドレス使用量が手動設定によって推定されるときに生じるずれがもたらすネットワークデバイスの処理能力不足を回避すべく、手動設定によってネットワークデバイスに割り当てられるアドレス範囲は、ネットワークデバイスによって実際に必要とされるアドレス範囲より大きい。その結果として、ネットワークデバイス上には大量のアイドル状態のアドレスリソースが存在し、ネットワークデバイス上の大量のアイドル状態のアドレスリソースは別のネットワークデバイスによって使用され得ないので、リソースの浪費が生じる。

本出願の実施形態において提供される方法および装置は、リソース浪費問題の解決を助けることが可能である。

本発明の実施形態の目的、技術的解決手段、および利点をより明確にすべく、本発明の実施形態における添付の図面に関連して本発明の実施形態における技術的解決手段を以下で明確に説明する。説明される実施形態が本発明の実施形態のうちの一部であることは明らかである。

本出願の実施形態において提供される方法では、サーバサイドがリソース要求を取得し、リソース要求は、クライアントのアドレスと、サーバサイドによって要求されるリソースについての情報とを含む。サーバサイドは、クライアントのアドレスにしたがって、リソース要求をクライアントに送信する。クライアントは、サーバサイドによって送信されたリソース要求を受信する。クライアントは、サーバサイドによって要求されるリソースについての、リソース要求に含まれる情報にしたがって、サーバサイドに割り当てられるリソースについての情報を取得する。クライアントは、リソース応答をサーバサイドに送信し、リソース応答は、サーバサイドに割り当てられるリソースについての情報を含む。サーバサイドは、クライアントによって送信されたリソース応答を受信する。このようにして、サーバサイドは、サーバサイドに割り当てられるリソースについての、リソース応答に含まれる情報にしたがって、サーバサイドによって必要とされるリソースを取得するでき、これにより、リソース浪費の低減を助ける。

本出願の実施形態において提供される方法および装置は、図１に示すシナリオに適用されてよい。本出願の実施形態において言及されるサーバサイドは、図１のネットワークデバイスであってよい。あるいは、本出願の実施形態において言及されるサーバサイドは、コンフィギュレーション機能を実現するプロトコルにおいてサーバサイドとして定義される装置であってよく、当該装置は、例えば、ルータ、スイッチ、サーバ、仮想化ネットワーク機能（ＶｉｒｔｕａｌｉｚｅｄＮｅｔｗｏｒｋＦｕｎｃｔｉｏｎ、ＶＮＦ）、またはＶＮＦの管理システムなどである。ＶＮＦの管理システムは、ＶＮＦマネージャ、（ＶＮＦｍａｎａｇｅｒ、ＶＮＦＭ）およびＮＦＶオーケストレータ（ＮＦＶＯｒｃｈｅｓｔｒａｔｏｒ、ＮＦＶＯ）を含む。コンフィギュレーション機能を実現するプロトコルは、ＮＥＴＣＯＮＦプロトコルまたはＲＥＳＴＣＯＮＦプロトコルなどのプロトコルであってよい。ここでは、コンフィギュレーション機能を実現するプロトコルに含まれる全てのプロトコルを１つ１つ示すことはない。本出願の実施形態において言及されるクライアントは、図１のリソース管理デバイスであってよい。あるいは、本出願の実施形態において言及されるクライアントは、コンフィギュレーション機能を実現するプロトコルにおいてクライアントとして定義される装置であってよく、当該装置は、例えば、ルータ、スイッチ、サーバ、またはコントローラなどである。クライアントとして使用される装置およびサーバサイドとして使用される装置の両方は、コンフィギュレーション機能を実現するプロトコルをサポートする。

コンフィギュレーション機能を実現するプロトコルを使用することによってサーバサイドとクライアントとの間でセッションが確立されてよく、例えば、ＮＥＴＣＯＮＦプロトコルを使用することによってサーバサイドとクライアントとの間でＮＥＴＣＯＮＦセッションが確立されてよく、または、ＲＥＳＴＣＯＮＦプロトコルを使用することによってサーバサイドとクライアントとの間でＲＥＳＴＣＯＮＦセッションが確立されてよい。サーバサイドによってクライアントからリソースを取得するための方法が、図１におけるシナリオに関連して以下で説明される。図２に示すように、本出願の本実施形態において提供されるリソース取得方法は、以下の段階を備える。

Ｓ２０１．サーバサイドが、リソース要求を取得する。ここで、リソース要求は、サーバサイドによって要求されるリソースについての情報を含む。

例えば、サーバサイドによって要求されるリソースは、サービスを完了するためにサーバサイドによって必要とされるリソースであってよく、または、別のデバイスをコンフィギュレーションするために必要とされるリソースであってよい。例えば、サーバサイドは、ブロードバンドネットワークゲートウェイ（ＢｒｏａｄｂａｎｄＮｅｔｗｏｒｋＧａｔｅｗａｙ、ＢＮＧ）である。ＢＮＧがアドレスをユーザに割り当てるサービスを完了する必要がある場合、ＢＮＧは、事前にアドレスプールおよび転送エントリを取得する必要がある。すなわち、ＢＮＧによって要求されるリソースは、アドレスプールおよび転送エントリを含む。

具体的に、サーバサイドによって要求されるリソースについての情報は、第１のアクションタイプと、サーバサイドによって要求されるリソースのパラメータとを含む。サーバサイドによって要求されるリソースのパラメータは、サービスを完了するためにサーバサイドによって必要とされるリソースに含まれる必要なパラメータである。例えば、サーバサイドがアドレス割り当てサービスを完了する必要がある場合、アドレス割り当てサービスを完了するためにサーバサイドによって必要とされるリソースはアドレスプールであり、サーバサイドによって要求されるリソースのパラメータは、アドレスプールに関連するパラメータである。第１のアクションタイプは、サーバサイドによって要求されるリソースに対して実行される操作を表すために使用される。サーバサイドによって要求されるリソースのパラメータがアドレスプールに関連するパラメータである場合、第１のアクションタイプは、「要求」、「解放」、または「リース更新」であってよい。

例えば、サーバサイドによって要求されるリソースのパラメータに含まれる内容は、第１のアクションタイプの内容が異なれば変わる。例えば、サーバサイドによって要求されるリソースはアドレスプールであり、第１のアクションタイプは「要求」である。サーバサイドによって要求されるリソースのパラメータは、アドレスプールのタイプを含む。任意選択で、サーバサイドによって要求されるリソースのパラメータはさらに、アドレスプールに含まれるアドレスの数を含んでよい。アドレスプールのタイプは、ＩＰｖ４またはＩＰｖ６であってよい。

例えば、サーバサイドによって要求されるリソースはアドレスプールであり、第１のアクションタイプは「リース更新」である。サーバサイドによって要求されるリソースのパラメータは、アドレスプールの名称を含む。リース更新というアクションを受信した後、クライアントは、指定の有効期間にしたがって、サーバサイドによって送信されたアドレスプールを有効期間まで延長してよい。任意選択で、サーバサイドによって要求されるリソースのパラメータは、さらに有効期間を含んでよい。

例えば、サーバサイドによって要求されるリソースはアドレスプールであり、第１のアクションタイプは「解放」である。サーバサイドによって要求されるリソースのパラメータは、アドレスプールの名称を含む。任意選択で、サーバサイドによって要求されるリソースのパラメータは、さらにアドレスプールのアドレス範囲を含んでよい。アドレスプールのアドレス範囲は、サーバサイドによって要求されるアドレスプールのサブセットであってよく、または、サーバサイドによって要求されるアドレスプールであってよい。

「要求」は、サーバサイドが十分なアドレスリソースプールを有さないときに、利用可能なアドレスプールをサーバサイドがクライアントに要求するというアクションである。「解放更新」は、サーバサイドによって要求されるアドレスプールが有効時間に達する前に、再び有効期間を申請するというアクションである。有効期間は、２０５０年１２月２０日などの終了時間であってよく、または、２日などの期間であってよい。「解放」は、ある期間にサーバサイドによって使用されていないアドレスプールをクライアントが別のサーバサイドに割り当てるというアクションである。本実施形態のアドレスプールはアドレスのセグメントであり、例えば、ＩＰｖ４アドレスセグメント１００．１００．０．１〜１００．１００．０．２５４は、２５４個のアドレスリソースを含むアドレスプールであることに留意すべきである。

任意選択で、リソース要求はさらにリソース要求の識別子を含んでよく、リソース要求の識別子は、リソース要求のシーケンス番号を表すために使用される。サーバサイドが複数のリソース要求をクライアントに送信する場合、リソース要求の識別子は、複数のリソース要求を区別するために使用されてよい。本出願の本実施形態において、リソース要求の識別子は、１００、Ｓｅｃｏｎｄ、およびＮｕｍｂｅｒ１００などの文字または番号のうちの少なくとも１つであってよい。

Ｓ２０２．サーバサイドが、リソース要求をクライアントに送信する。

例えば、クライアントのＩＰアドレスまたはＭＡＣアドレスのうちの少なくとも１つがサーバサイドにおいてコンフィギュレーションされてよい。サーバサイドは、ＩＰアドレスまたはＭＡＣアドレスにしたがってリソース要求をクライアントに送信してよい。あるいは、サーバサイドにおいてクライアントの識別子がコンフィギュレーションされてよく、サーバサイドは、クライアントの識別子にしたがって、クライアントのＩＰアドレスまたはＭＡＣアドレスのうちの少なくとも１つを取得してよい。サーバサイドは、ＩＰアドレスまたはＭＡＣアドレスにしたがってリソース要求をクライアントに送信してよい。あるいは、サーバサイドにおいてクライアントの識別子とポートとの間の対応関係がコンフィギュレーションされてよく、ポートは、クライアントと通信するためにサーバサイドによって使用され得るポートである。サーバサイドは、クライアントの識別子にしたがって、クライアントと通信するために使用され得るポートを取得してよい。サーバサイドは、ポートを使用することによってリソース要求をクライアントに送信してよい。

Ｓ２０３．リソース要求を受信した後、クライアントが、サーバサイドによって要求されるリソースについての、リソース要求に含まれる情報にしたがって、サーバサイドに割り当てられるリソースについての情報を取得する。

例えば、サーバサイドに割り当てられるリソースについての情報は、第２のアクションタイプと、サーバサイドに割り当てられるリソースのパラメータとを含み、第２のアクションタイプは、サーバサイドに割り当てられるリソースに対して実行される操作を表すために使用される。

例えば、サーバサイドによって要求されるリソースはアドレスプールであり、第１のアクションタイプは「要求」である。サーバサイドに割り当てられるリソースのパラメータは、アドレスプールの名称、アドレスプールの開始アドレス、およびアドレスプールの終了アドレスを含み、第２のアクションタイプは「作成」である。任意選択で、サーバサイドに割り当てられるリソースのパラメータはさらに、アドレスプールの有効期間またはアドレスプールのタイプのうちの少なくとも１つを含んでよい。アドレスプールのタイプは、ＩＰｖ４またはＩＰｖ６であってよい。「作成」は、サーバサイドにおいてアドレスプールの名称で名付けられたアドレスプールをアドレスプールの開始アドレスおよびアドレスプールの終了アドレスにしたがってサーバサイドが作成するというアクションである。

例えば、サーバサイドによって要求されるリソースはアドレスプールであり、第１のアクションタイプは「リース更新」である。サーバサイドに割り当てられるリソースのパラメータは、アドレスプールの名称およびアドレスプールの有効期間を含み、第２のアクションタイプは「アップデート」である。「アップデート」は、アドレスプールの名称に対応するアドレスプールの使用を、アドレスプールの有効期間までサーバサイドが継続するというアクションである。

例えば、サーバサイドによって要求されるリソースはアドレスプールであり、第１のアクションタイプは「解放」である。サーバサイドに割り当てられるリソースのパラメータは、アドレスプールの名称を含み、第２のアクションタイプは「削除」である。任意選択で、サーバサイドによって要求されるリソースのパラメータは、さらにアドレスプールのアドレス範囲を含んでよい。アドレスプールのアドレス範囲は、サーバサイドによって要求されるアドレスプールのサブセットであってよく、または、サーバサイドによって要求されるアドレスプールであってよい。「削除」は、アドレスプールの名称に対応するアドレスプールの使用をサーバサイドが取りやめるというアクションである。

Ｓ２０４．クライアントが、リソース応答をサーバサイドに送信する。ここで、リソース応答は、サーバサイドに割り当てられるリソースについての情報を含む。

例えば、リソース応答は、リソース要求を送信するデバイスに対する割り当てられるリソースについての情報を送信するために使用される。サーバサイドに割り当てられるリソースについての、リソース応答内の情報は、第２のアクションタイプと、サーバサイドに割り当てられるリソースのパラメータとを含む。サーバサイドに割り当てられるリソースのパラメータは、アドレスプールまたは転送エントリなどのリソース名と、リソースパラメータとを含んでよい。第２のアクションタイプは、サーバサイドに割り当てられるリソースに対して実行される操作を表すために使用される。

第２のアクションタイプは、第１のアクションタイプに対応していることが分かる。第１のアクションタイプおよび第２のアクションタイプは、同一のフィールドを使用することによって表されてよく、または、異なるフィールドを使用することによって表されてよい。

任意選択で、リソース応答はさらに、リソース応答の識別子を保持してよい。リソース応答の識別子は、リソース応答のシーケンス番号を表すために使用され、別のリソース応答と区別するために使用される。

Ｓ２０５．サーバサイドが、リソース応答にしたがってコンフィギュレーションを実行する。

例えば、サーバサイドがリソース応答にしたがってコンフィギュレーションを実行することは、サーバサイドがリソース応答内の第２のアクションタイプとサーバサイドに割り当てられるリソースのパラメータとにしたがってリソースをコンフィギュレーションすること、例えば、アドレスプールを作成すること、アドレスプールをアップデートすること、またはアドレスプールを削除することを含む。説明のためにここで例を１つ１つ提供することはしない。

本出願において提供される本実施形態では、サーバサイドはリソース要求をアクティブに開始する。リソース要求イニシエータおよびリソースユーザの両方がサーバサイドである。したがって、サーバサイドは要件に応じてリソースを申請でき、これにより、リソースがアイドル状態になることの回避、リソース利用の改善、およびリソース浪費の低減を助ける。

任意選択で、Ｓ２０１の前に、本出願において提供される本実施形態はさらに、サーバサイドによって使用されるリソースが条件を満たすかをサーバサイドが判断する段階を含む。ここで、当該条件は、サーバサイドのリソース使用量を表すために使用される。それに対応して、サーバサイドがリソース要求を取得することは、サーバサイドによって使用されるリソースが条件を満たすと判断したとき、サーバサイドによって使用されるリソースと条件とにしたがって、リソース要求をサーバサイドが生成する段階を含む。

リソース要求およびリソース応答はそれぞれ識別子を保持できることに留意すべきである。したがって、リソース要求およびリソース応答についての上述した具体的な実装例に加えて、リソース要求およびリソース応答は、任意選択で、以下の形式であってよい。

リソース要求は、サーバサイドによって要求されるリソースについての情報を含む。さらに、サーバサイドによって要求されるリソースについての情報は、第１のアクションタイプ、第１の識別子、およびサーバサイドによって要求されるリソースのパラメータを含む。第１のアクションタイプは、サーバサイドによって要求されるリソースに対して実行される操作を表すために使用される。第１の識別子は、リソース要求の順序を表すために使用される。

リソース応答は、サーバサイドに割り当てられるリソースについての情報を含む。さらに、サーバサイドに割り当てられるリソースについての情報は、第２の識別子と、サーバサイドに割り当てられるリソースのパラメータとを含む。第２の識別子は、リソース応答の順序を表すために使用される。第２の識別子は、第１の識別子に対応している。

すなわち、図２の方法と比べると、リソース応答は第２のアクションタイプを含まなくてよい。リソース応答を受信した後、サーバサイドは、リソース応答内の識別子と、リソース要求内の識別子と、リソース要求の識別子とリソース応答の識別子との間の対応関係とにしたがって、リソース応答に対応するリソース要求を判断してよく、これにより、リソース応答に対応するリソース要求内の第１のアクションタイプにしたがって、対応するリソースコンフィギュレーション操作を実行する。

ＮＥＴＣＯＮＦプロトコルが例として使用され、サーバサイドおよびクライアントがリソースコンフィギュレーションを実行する具体的なプロセスが図３に示されてよく、当該プロセスは以下の段階を含む。

Ｓ３０１．サーバサイドが、サーバサイドによって使用されるリソースが条件を満たすかを判断し、サーバサイドによって使用されるリソースが条件を満たす場合、Ｓ３０２を実行し、またはサーバサイドによって使用されるリソースが条件を満たさない場合、サーバサイドのリソース使用量のモニタリングを継続してよい。

当該条件は、サーバサイドのリソース使用量を表すために使用される。アドレスプールが例として使用される。アドレスプールが１００個のアドレスを含み、当該条件が、サーバサイドによって使用されるアドレスの数が９０より大きく１００より小さいというものであり、９１個のアドレスがサーバサイドによって使用される場合、サーバサイドは、サーバサイドによって使用されるリソースが当該条件を満たすと判断する。サービスサイドが要求したアドレスプールが、使用するには不十分であり得ることをサーバサイドは認識する。サーバサイドは、新しいアドレスプールを要求するために使用されるリソース要求を生成する。条件が、サーバサイドのアドレスプールの有効時間が２日を超えるというものである場合、要求されるアドレスプールが条件を満たすと判断した後、サーバサイドはリース更新のためのリソース要求をクライアントに送信する。条件が、使用されていないアドレスの数が２０より大きく１００より小さいというものであり、２１個のアドレスがサーバサイドによって使用されていない場合、サーバサイドは、サーバサイドによって使用されるリソースが当該条件を満たすと判断する。アドレスが解放され得るとサーバサイドが認識した場合、サーバサイドは、アドレスプールの解放を要求するために使用されるリソース要求を生成する。

Ｓ３０２．サーバサイドが、サーバサイドによって使用されるリソースと当該条件とにしたがってＮｏｔｉｆｉｃａｔｉｏｎメッセージを生成する。

任意選択で、サーバサイドはさらに、サーバサイドによって使用されるリソースと当該条件とを別のデバイスに送信してよく、これにより、当該別のデバイスは、使用されるリソースおよび当該条件にしたがってリソース要求を生成できる。サーバサイドは、当該別のデバイスによって送信されたリソース要求を受信してよい。

例えば、Ｎｏｔｉｆｉｃａｔｉｏｎメッセージは、サーバサイドによって要求されるリソースについての情報を含む。サーバサイドによって要求されるリソースについての情報の具体的な形式については、Ｓ２０１の説明を参照されたい。任意選択で、サーバサイドによって要求されるリソースについての情報は、Ｎｏｔｉｆｉｃａｔｉｏｎメッセージのペイロード（Ｐａｙｌｏａｄ）フィールドに保持されてよい。

Ｓ３０３．サーバサイドが、Ｎｏｔｉｆｉｃａｔｉｏｎメッセージをクライアントに送信する。

サーバサイドは、ＮＥＴＣＯＮＦプロトコルにおける規定に基づくＮｏｔｉｆｉｃａｔｉｏｎメッセージをクライアントに送信してよい。詳細はここでは説明しない。

Ｓ３０４．Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを受信した後、クライアントは、リモートプロシージャコール（ＲｅｍｏｔｅＰｒｏｃｅｄｕｒｅＣａｌｌ、ＲＰＣ）メッセージを生成する。

例えば、ＲＰＣメッセージは、サーバサイドに割り当てられるリソースについての情報を含む。具体的な形式については、Ｓ２０３の説明を参照されたい。任意選択で、サーバサイドに割り当てられるリソースについての情報は、ＲＰＣメッセージのペイロード（Ｐａｙｌｏａｄ）フィールドに保持されてよい。クライアントは、ＮＥＴＣＯＮＦプロトコルにおける規定に基づくＲＰＣメッセージを送信してよい。詳細はここでは説明されない。

Ｓ３０５．クライアントが、ＲＰＣメッセージをサーバサイドに送信する。

クライアントは、ＮＥＴＣＯＮＦプロトコルにおける規定に基づくＲＰＣメッセージをサーバサイドに送信してよい。詳細はここでは説明しない。

本実施形態において、ＲＰＣメッセージと既存のＮＥＴＣＯＮＦプロトコルとの間の互換性を保証すべく、サーバサイドに割り当てられるリソースについての情報に加えて、ＲＰＣメッセージはさらに、プロトコル操作タイプを保持する。本実施形態において、ＲＰＣメッセージのプロトコル操作タイプはｅｄｉｔ−ｃｏｎｆｉｇｕｒａｔｉｏｎである。

Ｓ３０６．サーバサイドが、ＲＰＣメッセージにしたがってリソースをコンフィギュレーションする。

本実施形態において、リソースコンフィギュレーションの内容については、図２に対応する実施形態における対応する内容を参照されたい。詳細はここでは再度説明しない。

Ｓ３０７．サーバサイドが、リソースコンフィギュレーションフィードバックをクライアントに送信する。

本実施形態において、リソースコンフィギュレーションフィードバックは、リモートプロシージャコール返答（ＲＰＣ−Ｒｅｐｌｙ）メッセージであってよい。ＲＰＣ−Ｒｅｐｌｙメッセージは、クライアントにリソースコンフィギュレーション結果を通知するために使用される。リソースコンフィギュレーション結果とは、コンフィギュレーション成功またはコンフィギュレーション失敗である。

本実施形態の方法では、従来のＮｏｔｉｆｉｃａｔｉｏｎメッセージおよびＲＰＣメッセージが改善され、これにより、サーバサイドは、改善されたＮｏｔｉｆｉｃａｔｉｏｎメッセージを使用することによってクライアントにリソースを要求でき、クライアントは、ＲＰＣメッセージを使用することによってリソースをサーバサイドに送達できる。したがって、サーバサイドはＮＥＴＣＯＮＦプロトコルフレームワークにおいてリソースをアクティブに要求し、これにより、リソースの浪費が低減される。

リソース要求に使用されるＮｏｔｉｆｉｃａｔｉｏｎメッセージおよびリソース応答に使用されるＲＰＣメッセージの例は以下の通りである。

同様に、ＲＥＳＴＣＯＮＦプロトコルフレームワークにおいて、サーバサイドは、サーバサイドによって要求されるリソースについての情報を、ＲＥＳＴＣＯＮＦプロトコルに基づくＮｏｔｉｆｉｃａｔｉｏｎメッセージに追加し、リソース要求をクライアントに送信してよい。クライアントは、サーバサイドに割り当てられるリソースについての情報を、ＲＥＳＴＣＯＮＦプロトコルに基づくポスト（ＰＯＳＴ）メッセージに追加し、リソース応答をサーバサイドに送信してよい。サーバサイドによって要求されるリソースについての情報の具体的な内容と、サーバサイドに割り当てられるリソースについての情報の具体的な内容とについては、図２または図３に対応する実施形態を参照されたい。

図４に示すように、リソース管理システムにおいて、２つのクライアントが、それぞれアクティブクライアントおよびスタンバイクライアントとして設定されている。アクティブクライアントおよびスタンバイクライアントはそれぞれ、サーバサイドとＮＥＴＣＯＮＦセッションを確立する。本シナリオにおいて、リソースコンフィギュレーションプロセスが図５に示されており、当該プロセスは以下の段階を含む。

Ｓ５０１．サーバサイドが、ネットワーク管理デバイス上のリストを問い合わせることによってアクティブクライアントを判断する。

例えば、ネットワーク管理デバイス上のリストは、アクティブクライアントの識別子およびスタンバイクライアントの識別子を含む。ネットワーク管理デバイス上のリストは、サーバサイドにおいてコンフィギュレーションされたリストであってよく、または、リソース管理システムにおいてコンフィギュレーションされたリストであってよい。サーバサイドは、リソース管理システムとインタラクトすることによってネットワーク管理デバイス上のリストを取得してよい。

Ｓ５０２．サーバサイドが、サーバサイドとアクティブクライアントとの間の接続が正常かを判断し、サーバサイドとアクティブクライアントとの間の接続が正常である場合、Ｓ５０３を実行し、またはサーバサイドとアクティブクライアントとの間の接続が異常である場合、Ｓ５０４を実行する。

例えば、本実施形態における正常な接続とは、正常な通信が実行され得ることを示す。サーバサイドは、サーバサイドとスタンバイクライアントとの間の接続が正常かを、ＮＥＴＣＯＮＦプロトコルにおける対応する内容を使用することによって判断してよい。詳細はここでは説明しない。

Ｓ５０３．サーバサイドが、アクティブクライアントをターゲットクライアントとして判断し、その後、Ｓ５０５を実行する。

例えば、サーバサイドは、アクティブクライアントを、図２または図３に対応する実施形態において言及されたクライアント、すなわちターゲットクライアントとして選択する。

Ｓ５０４．サーバサイドが、アクティブクライアントのスタンバイクライアントを、対応関係およびアクティブクライアントにしたがってターゲットクライアントとして判断する。

対応関係は、アクティブクライアントについての情報およびスタンバイクライアントについての情報を含む。対応関係は、ネットワーク管理デバイス上のリストに格納されてよく、または、別のエントリの形式でサーバサイドにおいて格納されてよい。説明のためにここで例を１つ１つ提供することはしない。

例えば、サーバサイドとスタンバイクライアントとの間の接続が正常であると判断した後、サーバサイドは、スタンバイクライアントを、図２または図３に対応する実施形態におけるクライアント、すなわちターゲットクライアントとして選択する。サーバサイドとスタンバイクライアントとの間の接続が正常かを判断するためにサーバサイドによって使用される方法は、Ｓ５０２と同一である。詳細はここでは再度説明しない。

Ｓ５０５．サーバサイドが、取得メッセージを取得する。

例えば、取得メッセージは、ｆｅｔｃｈメッセージであってよい。ｆｅｔｃｈメッセージは、ＮＥＴＣＯＮＦプロトコル、ＲＥＳＴＣＯＮＦプロトコル、または、コンフィギュレーション機能を実現する別のプロトコルに基づくメッセージであってよい。ｆｅｔｃｈメッセージは、サーバサイドによって要求されるリソースについての情報を含む。サーバサイドによって要求されるリソースについての情報の具体的な形式については、Ｓ２０１を参照されたい。

Ｓ５０５は、Ｓ５０２〜Ｓ５０４の前に実行されてよく、本実施形態において順序は限定されない。

Ｓ５０６．サーバサイドが、取得メッセージをターゲットクライアントに送信する。

サーバサイドは、ＮＥＴＣＯＮＦプロトコルにおける規定に基づくｆｅｔｃｈメッセージをクライアントに送信してよい。詳細はここでは説明しない。

Ｓ５０７．取得メッセージを受信した後、ターゲットクライアントが、応答メッセージを生成する。

例えば、応答メッセージは、ｆｅｔｃｈｒｅｐｌｙメッセージであってよい。ｆｅｔｃｈｒｅｐｌｙメッセージは、ＮＥＴＣＯＮＦプロトコル、ＲＥＳＴＣＯＮＦプロトコル、または、コンフィギュレーション機能を実現する別のプロトコルに基づくメッセージであってよい。ｆｅｔｃｈｒｅｐｌｙメッセージは、サーバサイドに割り当てられるリソースについての情報を含む。具体的な形式については、Ｓ２０３における説明を参照されたい。

Ｓ５０８．ターゲットクライアントが、ｆｅｔｃｈｒｅｐｌｙメッセージをサーバサイドに送信する。

ターゲットクライアントは、ＮＥＴＣＯＮＦプロトコルにおける規定に基づくｆｅｔｃｈｒｅｐｌｙメッセージをサーバサイドに送信してよい。詳細はここでは説明しない。

本実施形態におけるｆｅｔｃｈメッセージおよびｆｅｔｃｈｒｅｐｌｙメッセージの例は以下の通りである。

上述のプロセスから、本実施形態において、ｆｅｔｃｈメッセージおよびｆｅｔｃｈ−ｒｅｐｌｙメッセージは両方とも、ＮＥＴＣＯＮＦプロトコル、ＲＥＳＴＣＯＮＦプロトコル、または、コンフィギュレーション機能を実現する別のプロトコルのフレームワークにおいて新しく設定されたメッセージタイプであり、これにより、サーバサイドとクライアントとの間でリソースコンフィギュレーションを実行するプロセスを実行するということが分かる。

加えて、本実施形態において、アクティブクライアントおよびスタンバイクライアントが存在する場合、サーバサイドは、１つのクライアントのみに要求メッセージを送信し、これにより、伝送リソースが低減され得る。

本出願の一実施形態はさらに、サーバサイドとして使用される装置とクライアントとして使用される装置とを開示する。サーバサイドとして使用される装置は、図２、図３、または図５に示される方法における「サーバサイド」によって実行される段階を実現してよく、クライアントとして使用される装置は、図２、図３、または図５に示される方法における「クライアント」によって実行される段階を実現してよい。サーバサイドとして使用される装置は、図２、図３、または図５において示される方法を使用することによって、クライアントとして使用される装置からリソースを取得してよい。

図６に示すように、サーバサイドとして使用される装置は、取得モジュール６０１、送信モジュール６０２、および受信モジュール６０３を含む。

取得モジュール６０１は、リソース要求を取得するよう構成され、リソース要求は、クライアントとして使用される装置のアドレスと、サーバサイドとして使用される装置によって要求されるリソースについての情報とを含む。送信モジュール６０２は、クライアントとして使用される装置のアドレスにしたがって、クライアントとして使用される装置にリソース要求を送信するよう構成される。受信モジュール６０３は、クライアントとして使用される装置によって送信されたリソース応答を受信するよう構成され、リソース応答は、サーバサイドとして使用される装置に割り当てられるリソースについての情報を含む。

任意選択で、図６に示される装置はさらに、サーバサイドとして使用される装置によって使用されるリソースが、条件を満たすかを判断するよう構成される判断モジュール６０４を備えてよく、当該条件は、サーバサイドとして使用される装置のリソース使用量を表すために使用される。

任意選択で、判断モジュールが判断結果を取得した場合、取得モジュール６０１は、サーバサイドとして使用される装置によって使用されるリソースが条件を満たすと判断したとき、サーバサイドとして使用される装置によって使用されるリソースと当該条件とにしたがって、リソース要求を生成するという具体的な実装例においてリソース要求を取得する。

任意選択で、図６に示された装置はさらに、第１の送信モジュールが、クライアントとして使用される装置にリソース要求を送信する前に、サーバサイドとして使用される装置とクライアントとして使用されるアクティブ装置との間の通信が正常であると判断したとき、クライアントとして使用されるアクティブ装置をクライアントとして使用される装置として選択するよう構成される第１の選択モジュール６０５を備えてよい。

任意選択で、図６に示された装置はさらに、第１の送信モジュールがクライアントとして使用される装置にリソース要求を送信する前に、サーバサイドとして使用される装置とクライアントとして使用されるアクティブ装置との間の通信が異常であると判断したとき、対応関係と、クライアントとして使用されるアクティブ装置とにしたがって、クライアントとして使用されるスタンバイ装置をクライアントとして使用される装置として選択するよう構成される第２の選択モジュール６０６を備えてよい。ここで、対応関係は、クライアントとして使用されるアクティブ装置についての情報と、クライアントとして使用されるスタンバイ装置についての情報とを含む。

任意選択で、取得モジュール６０１によって取得されるリソース要求は、ネットワークコンフィギュレーションＮＥＴＣＯＮＦプロトコルに基づく通知（Ｎｏｔｉｆｉｃａｔｉｏｎ）メッセージであり、Ｎｏｔｉｆｉｃａｔｉｏｎメッセージは、サーバサイドとして使用される装置によって要求されるリソースについての情報を含む。受信モジュール６０３によって受信されるリソース応答は、ＮＥＴＣＯＮＦプロトコルに基づくリモートプロシージャコールＲＰＣメッセージを備え、ＲＰＣメッセージは、サーバサイドとして使用される装置に割り当てられるリソースについての情報を有する。

あるいは、取得モジュール６０１によって取得されるリソース要求は、ＲＥＳＴＣＯＮＦプロトコルに基づくＮｏｔｉｆｉｃａｔｉｏｎメッセージであり、Ｎｏｔｉｆｉｃａｔｉｏｎメッセージは、サーバサイドとして使用される装置によって要求されるリソースについての情報を含む。受信モジュール６０３によって受信されるリソース応答は、ＲＥＳＴＣＯＮＦプロトコルに基づくポスト（ＰＯＳＴ）メッセージであり、ＰＯＳＴメッセージは、サーバサイドとして使用される装置に割り当てられるリソースについての情報を含む。

あるいは、取得モジュール６０１によって取得されるリソース要求は、取得メッセージであり、取得メッセージは、サーバサイドとして使用される装置によって要求されるリソースについての情報を含む。受信モジュール６０３によって受信されるリソース応答は、応答メッセージであり、応答メッセージは、サーバサイドとして使用される装置に割り当てられるリソースについての情報を含み、応答メッセージは、取得メッセージに応答するために使用される。

任意選択で、サーバサイドとして使用される装置によって要求されるリソースについての、取得モジュール６０１によって取得されるリソース要求に含まれる情報は、第１のアクションタイプと、サーバサイドとして使用される装置によって要求されるリソースのパラメータとを含み、第１のアクションタイプは、サーバサイドとして使用される装置によって要求されるリソースに対して実行される操作を表すために使用される。サーバサイドとして使用される装置に割り当てられるリソースについての、受信モジュール６０３によって受信されるリソース応答に含まれる情報は、第２のアクションタイプと、サーバサイドとして使用される装置に割り当てられるリソースのパラメータとを含み、第２のアクションタイプは、サーバサイドとして使用される装置に割り当てられるリソースに対して実行される操作を表すために使用される。

あるいは、サーバサイドとして使用される装置によって要求されるリソースについての、取得モジュール６０１によって取得されるリソース要求に含まれる情報は、第１のアクションタイプと、第１の識別子と、サーバサイドとして使用される装置によって要求されるリソースのパラメータとを含み、第１のアクションタイプは、サーバサイドとして使用される装置によって要求されるリソースに対して実行される操作を表すために使用され、第１の識別子は、リソース要求の順序を表すために使用される。サーバサイドとして使用される装置に割り当てられるリソースについての、受信モジュール６０３によって受信されるリソース応答に含まれる情報は、第２の識別子と、サーバサイドとして使用される装置に割り当てられるリソースのパラメータとを含み、第２の識別子は、リソース応答の順序を表すために使用され、第２の識別子は、第１の識別子に対応している。

本実施形態においてサーバサイドとして使用される装置は、クライアントとして使用される装置にリソース要求をアクティブに送信してリソースコンフィギュレーションを要求し、それによって、リソース浪費の低減を助ける。

図７に示すように、クライアントとして使用される装置は、受信モジュール７０１、取得モジュール７０２、および送信モジュール７０３を備える。

受信モジュール７０１は、サーバサイドとして使用される装置によって送信されたリソース要求を受信するよう構成され、リソース要求は、クライアントとして使用される装置のアドレスと、サーバサイドとして使用される装置によって要求されるリソースについての情報とを含む。取得モジュール７０２は、サーバサイドとして使用される装置によって要求されるリソースについての、リソース要求に含まれる情報にしたがって、サーバサイドとして使用される装置に割り当てられるリソースについての情報を取得するよう構成される。送信モジュール７０３は、サーバサイドとして使用される装置にリソース応答を送信するよう構成され、リソース応答は、サーバサイドとして使用される装置に割り当てられるリソースについての情報を含む。

任意選択で、受信モジュール７０１によって受信されるリソース要求は、ネットワークコンフィギュレーションＮＥＴＣＯＮＦプロトコルに基づく通知（Ｎｏｔｉｆｉｃａｔｉｏｎ）メッセージであり、Ｎｏｔｉｆｉｃａｔｉｏｎメッセージは、サーバサイドとして使用される装置によって要求されるリソースについての情報を含む。送信モジュール７０３によって送信されるリソース応答は、ＮＥＴＣＯＮＦプロトコルに基づくリモートプロシージャコールＲＰＣメッセージであり、ＲＰＣメッセージは、サーバサイドとして使用される装置に割り当てられるリソースについての情報を含む。

あるいは、受信モジュール７０１によって受信されるリソース要求は、ＲＥＳＴＣＯＮＦプロトコルに基づくＮｏｔｉｆｉｃａｔｉｏｎメッセージであり、Ｎｏｔｉｆｉｃａｔｉｏｎメッセージは、サーバサイドとして使用される装置によって要求されるリソースについての情報を含む。送信モジュール７０３によって送信されるリソース応答は、ＲＥＳＴＣＯＮＦプロトコルに基づくポスト（ＰＯＳＴ）メッセージであり、ＰＯＳＴメッセージは、サーバサイドとして使用される装置に割り当てられるリソースについての情報を含む。

あるいは、受信モジュール７０１によって受信されるリソース要求は、取得メッセージであり、取得メッセージは、サーバサイドとして使用される装置によって要求されるリソースについての情報を含む。送信モジュール７０３によって送信されるリソース応答は、応答メッセージであり、応答メッセージは、サーバサイドとして使用される装置に割り当てられるリソースについての情報を含み、応答メッセージは、取得メッセージに応答するために使用される。

任意選択で、サーバサイドとして使用される装置によって要求されるリソースについての、受信モジュール７０１によって受信されるリソース要求に含まれる情報は、第１のアクションタイプと、サーバサイドとして使用される装置によって要求されるリソースのパラメータとを含み、第１のアクションタイプは、サーバサイドとして使用される装置によって要求されるリソースに対して実行される操作を表すために使用される。サーバサイドとして使用される装置に割り当てられるリソースについての、取得モジュール７０２によって取得される情報は、第２のアクションタイプと、サーバサイドとして使用される装置に割り当てられるリソースのパラメータとを含み、第２のアクションタイプは、サーバサイドとして使用される装置に割り当てられるリソースに対して実行される操作を表すために使用される。

あるいは、サーバサイドとして使用される装置によって要求されるリソースについての、受信モジュール７０１によって受信されるリソース要求に含まれる情報は、第１のアクションタイプと、第１の識別子と、サーバサイドとして使用される装置によって要求されるリソースのパラメータとを含み、第１のアクションタイプは、サーバサイドとして使用される装置によって要求されるリソースに対して実行される操作を表すために使用され、第１の識別子は、リソース要求の順序を表すために使用される。サーバサイドとして使用される装置に割り当てられるリソースについての、取得モジュール７０２によって取得される情報は、第２の識別子と、サーバサイドとして使用される装置に割り当てられるリソースのパラメータとを含み、第２の識別子は、リソース応答の順序を表すために使用され、第２の識別子は、第１の識別子に対応している。

図６におけるサーバサイドとして使用される装置によって送信されたリソース要求を受信した後、本実施形態におけるクライアントとして使用される装置は、サーバサイドとして使用される装置にリソース応答を送信して、サーバサイドとして使用される装置に対してリソースをコンフィギュレーションするよう命令し、それによって、リソースの浪費の回避を助ける。

図８に示すように、本出願の一実施形態はさらにサーバサイドとして使用される装置を開示し、当該装置は、プロセッサと、プロセッサと共に使用されるメモリと、通信インタフェースとを備える。上述のコンポーネントは、通信バスを使用することによって互いに通信し合う。サーバサイドとして使用される、図８に対応する実施形態において提供される装置は、サーバサイドとして使用される、図６に対応する実施形態において提供される装置であってよい。

メモリは、リソース取得機能を実現するプログラムを格納し、プロセッサは、メモリおよび通信インタフェース内のプログラムを呼び出すことによって、図２、図３、または図５に示された方法における、「サーバサイド」によって実行される内容を実現してよい。

本出願の一実施形態はさらに、クライアントとして使用される装置を開示し、図９に構造が示されている。メモリは、リソース取得機能を実現するプログラムを格納し、プロセッサは、メモリおよび通信インタフェース内のプログラムを呼び出すことによって、図２、図３、または図５に示された方法における、「クライアント」によって実行される段階を実現してよい。クライアントとして使用される、図９に対応する実施形態において提供される装置は、クライアントとして使用される、図７に対応する実施形態において提供される装置であってよい。

本出願の実施形態のリソース要求およびリソース応答は、ＹＡＮＧモデルを使用することによって説明されてよい。具体的な記述方式は、ここでは説明しない。

本明細書における実施形態は全て、漸進的な方式で説明されている。実施形態における同一の、または類似した部分については、これらの実施形態を参照されたい。各実施形態は、他の実施形態との差に重点を置いている。

上述の汎用プロセッサは、マイクロプロセッサであってよく、または、プロセッサは、任意の従来のプロセッサであってよい。本発明の実施形態に関連して開示された方法の段階は、ハードウェアプロセッサによって直接実行されてよく、または、プロセッサ内のハードウェアモジュールとソフトウェアモジュールとの組み合わせを使用することによって実行されてよい。ソフトウェアを使用することによって段階が実現されるとき、上述の機能を実現するコードがコンピュータ可読媒体に格納されてよく、コンピュータ可読媒体は、コンピュータ記憶媒体を含む。記憶媒体は、コンピュータがアクセス可能な任意の入手可能な媒体であってよい。以下のものが例として使用されるが、それに限定されているわけではない。コンピュータ可読媒体は、ランダムアクセスメモリ（英文全表記：ｒａｎｄｏｍａｃｃｅｓｓｍｅｍｏｒｙ、略してＲＡＭ）、リードオンリメモリ（英文全表記：ｒｅａｄ−ｏｎｌｙｍｅｍｏｒｙ、略してＲＯＭ）、電気的消去可能プログラマブルリードオンリメモリ（英文全表記：ｅｌｅｃｔｒｉｃａｌｌｙｅｒａｓａｂｌｅｐｒｏｇｒａｍｍａｂｌｅｒｅａｄ−ｏｎｌｙｍｅｍｏｒｙ、略してＥＥＰＲＯＭ）、コンパクトディスクリードオンリメモリ（英文全表記：ｃｏｍｐａｃｔｄｉｓｃｒｅａｄ−ｏｎｌｙｍｅｍｏｒｙ、略してＣＤ−ＲＯＭ）もしくは別の光ディスクストレージ、ディスク記憶媒体もしくは別のディスクストレージ、または、コマンド形式もしくはデータ構造形式でプログラムコードを保持または格納するために使用でき、かつ、コンピュータがアクセス可能な任意の他の媒体であってよい。コンピュータ可読媒体は、コンパクトディスク（英文全表記：ｃｏｍｐａｃｔｄｉｓｃ、略してＣＤ）、レーザディスク、デジタルビデオディスク（英文全表記：ｄｉｇｉｔａｌｖｉｄｅｏｄｉｓｃ、略してＤＶＤ）、フロッピー（登録商標）ディスク、またはブルーレイディスクであってよい。

最後に、上述の実施形態は、本発明の技術的解決手段を説明することを意図した例に過ぎず、本発明を限定することを意図したものではないということに留意すべきである。上述の実施形態に関連して、本発明と本発明の利点とが詳細に説明されたが、当業者であればさらに、本発明の特許請求の範囲から逸脱することなく、上述の実施形態において説明された技術的解決手段に変更を施し、または、これらのいくつかの技術的特徴に対して等価な置き換えを行い得ることを当業者は理解すべきである。
［項目１］
リソース取得方法であって、
リソース要求をサーバサイドが取得する段階であって、上記リソース要求は、上記サーバサイドによって要求されるリソースについての情報を備える、段階と、
上記リソース要求を上記クライアントに上記サーバサイドが送信する段階と、
上記クライアントによって送信されたリソース応答を上記サーバサイドが受信する段階であって、上記リソース応答は、上記サーバサイドに割り当てられるリソースについての情報を備える、段階と
を備える方法。
［項目２］
リソース要求をサーバサイドが取得する上記段階の前に、
上記サーバサイドによって使用されるリソースが条件を満たすかを上記サーバサイドが判断する段階であって、上記条件は、上記サーバサイドのリソース使用量を表すために使用される、段階をさらに備える、
項目１に記載の方法。
［項目３］
リソース要求をサーバサイドが取得する上記段階は、
上記サーバサイドによって使用される上記リソースが上記条件を満たすと判断したとき、上記サーバサイドによって使用される上記リソースと上記条件とにしたがって、上記リソース要求を上記サーバサイドが生成する段階
を有する、項目２に記載の方法。
［項目４］
上記リソース要求を上記クライアントに上記サーバサイドが送信する上記段階の前に、
上記サーバサイドとアクティブクライアントとの間の通信が正常であると判断したとき、上記アクティブクライアントを上記クライアントとして上記サーバサイドが選択する段階
をさらに備える、項目１から３のいずれか一項に記載の方法。
［項目５］
上記リソース要求を上記クライアントに上記サーバサイドが送信する上記段階の前に、
上記サーバサイドとアクティブクライアントとの間の通信が異常であると判断したとき、対応関係と上記アクティブクライアントとにしたがって、スタンバイクライアントを上記クライアントとして上記サーバサイドが選択する段階であって、上記対応関係は、上記アクティブクライアントについての情報および上記スタンバイクライアントについての情報を含む、段階をさらに備える、
項目１から３のいずれか一項に記載の方法。
［項目６］
上記リソース要求は、ネットワークコンフィギュレーションＮＥＴＣＯＮＦプロトコルに基づく通知Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを備え、上記Ｎｏｔｉｆｉｃａｔｉｏｎメッセージは、上記サーバサイドによって要求される上記リソースについての上記情報を有し、
上記リソース応答は、上記ＮＥＴＣＯＮＦプロトコルに基づくリモートプロシージャコールＲＰＣメッセージを備え、上記ＲＰＣメッセージは、上記サーバサイドに割り当てられる上記リソースについての上記情報を有する、
項目１から５のいずれか一項に記載の方法。
［項目７］
上記リソース要求は、ＲＥＳＴＣＯＮＦプロトコルに基づくＮｏｔｉｆｉｃａｔｉｏｎメッセージを備え、上記Ｎｏｔｉｆｉｃａｔｉｏｎメッセージは、上記サーバサイドによって要求される上記リソースについての上記情報を有し、
上記リソース応答は、上記ＲＥＳＴＣＯＮＦプロトコルに基づくポストＰＯＳＴメッセージを備え、上記ＰＯＳＴメッセージは、上記サーバサイドに割り当てられる上記リソースについての上記情報を有する、
項目１から５のいずれか一項に記載の方法。
［項目８］
上記リソース要求は、取得メッセージを備え、上記取得メッセージは、上記サーバサイドによって要求される上記リソースについての上記情報を有し、
上記リソース応答は、応答メッセージを備え、上記応答メッセージは、上記サーバサイドに割り当てられる上記リソースについての上記情報を有し、上記応答メッセージは、上記取得メッセージに応答するために使用される、
項目１から５のいずれか一項に記載の方法。
［項目９］
上記サーバサイドによって要求される上記リソースについての上記情報は、第１のアクションタイプと、上記サーバサイドによって要求される上記リソースのパラメータとを含み、上記第１のアクションタイプは、上記サーバサイドによって要求される上記リソースに対して実行される操作を表すために使用され、
上記サーバサイドに割り当てられる上記リソースについての上記情報は、第２のアクションタイプと、上記サーバサイドに割り当てられる上記リソースのパラメータとを含み、上記第２のアクションタイプは、上記サーバサイドに割り当てられる上記リソースに対して実行される操作を表すために使用される、
項目１から８のいずれか一項に記載の方法。
［項目１０］
上記サーバサイドによって要求される上記リソースについての上記情報は、第１のアクションタイプと、第１の識別子と、上記サーバサイドによって要求される上記リソースのパラメータとを含み、上記第１のアクションタイプは、上記サーバサイドによって要求される上記リソースに対して実行される操作を表すために使用され、上記第１の識別子は、上記リソース要求の順序を表すために使用され、
上記サーバサイドに割り当てられる上記リソースについての上記情報は、第２の識別子と、上記サーバサイドに割り当てられる上記リソースのパラメータとを含み、上記第２の識別子は、上記リソース応答の順序を表すために使用され、上記第２の識別子は、上記第１の識別子に対応している、
項目１から８のいずれか一項に記載の方法。
［項目１１］
リソース取得方法であって、
サーバサイドによって送信されたリソース要求をクライアントが受信する段階であって、上記リソース要求は、上記サーバサイドによって要求されるリソースについての情報を備える、段階と
上記サーバサイドによって要求される上記リソースについての、上記リソース要求に含まれる上記情報にしたがって、上記サーバサイドに割り当てられるリソースについての情報を上記クライアントが取得する段階と、
リソース応答を上記サーバサイドに上記クライアントが送信する段階であって、上記リソース応答は、上記サーバサイドに割り当てられる上記リソースについての上記情報を備える、段階と
を備える方法。
［項目１２］
上記リソース要求は、ネットワークコンフィギュレーションＮＥＴＣＯＮＦプロトコルに基づく通知Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを備え、上記Ｎｏｔｉｆｉｃａｔｉｏｎメッセージは、上記サーバサイドによって要求される上記リソースについての上記情報を有し、
上記リソース応答は、上記ＮＥＴＣＯＮＦプロトコルに基づくリモートプロシージャコールＲＰＣメッセージを備え、上記ＲＰＣメッセージは、上記サーバサイドに割り当てられる上記リソースについての上記情報を有する、
項目１１に記載の方法。
［項目１３］
上記リソース要求は、ＲＥＳＴＣＯＮＦプロトコルに基づくＮｏｔｉｆｉｃａｔｉｏｎメッセージを備え、上記Ｎｏｔｉｆｉｃａｔｉｏｎメッセージは、上記サーバサイドによって要求される上記リソースについての上記情報を有し、
上記リソース応答は、上記ＲＥＳＴＣＯＮＦプロトコルに基づくポストＰＯＳＴメッセージを備え、上記ＰＯＳＴメッセージは、上記サーバサイドに割り当てられる上記リソースについての上記情報を有する、
項目１１に記載の方法。
［項目１４］
上記リソース要求は、取得メッセージを備え、上記取得メッセージは、上記サーバサイドによって要求される上記リソースについての上記情報を有し、
上記リソース応答は、応答メッセージを備え、上記応答メッセージは、上記サーバサイドに割り当てられる上記リソースについての上記情報を有し、上記応答メッセージは、上記取得メッセージに応答するために使用される、
項目１１に記載の方法。
［項目１５］
上記サーバサイドによって要求される上記リソースについての上記情報は、第１のアクションタイプと、上記サーバサイドによって要求される上記リソースのパラメータとを含み、上記第１のアクションタイプは、上記サーバサイドによって要求される上記リソースに対して実行される操作を表すために使用され、
上記サーバサイドに割り当てられる上記リソースについての上記情報は、第２のアクションタイプと、上記サーバサイドに割り当てられる上記リソースのパラメータとを含み、上記第２のアクションタイプは、上記サーバサイドに割り当てられる上記リソースに対して実行される操作を表すために使用される、
項目１１から１４のいずれか一項に記載の方法。
［項目１６］
上記サーバサイドによって要求される上記リソースについての上記情報は、第１のアクションタイプと、第１の識別子と、上記サーバサイドによって要求される上記リソースのパラメータとを含み、上記第１のアクションタイプは、上記サーバサイドによって要求される上記リソースに対して実行される操作を表すために使用され、上記第１の識別子は、上記リソース要求の順序を表すために使用され、
上記サーバサイドに割り当てられる上記リソースについての上記情報は、第２の識別子と、上記サーバサイドに割り当てられる上記リソースのパラメータとを含み、上記第２の識別子は、上記リソース応答の順序を表すために使用され、上記第２の識別子は、上記第１の識別子に対応している、
項目１１から１４のいずれか一項に記載の方法。
［項目１７］
サーバサイドとして使用される装置であって、
リソース要求を取得するよう構成される取得モジュールであって、上記リソース要求は、サーバサイドとして使用される上記装置によって要求されるリソースについての情報を含む、取得モジュールと、
クライアントとして使用される上記装置に上記リソース要求を送信するよう構成される送信モジュールと、
クライアントとして使用される上記装置によって送信されたリソース応答を受信するよう構成される受信モジュールであって、上記リソース応答は、サーバサイドとして使用される上記装置に割り当てられるリソースについての情報を含む、受信モジュールと
を備える装置。
［項目１８］
サーバサイドとして使用される上記装置によって使用されるリソースが条件を満たすかを判断するよう構成される判断モジュールであって、上記条件は、サーバサイドとして使用される上記装置のリソース使用量を表すために使用される、判断モジュールをさらに備える、
項目１７に記載の装置。
［項目１９］
上記第１の取得モジュールは具体的に、サーバサイドとして使用される上記装置によって使用されるリソースが条件を満たすと判断したとき、サーバサイドとして使用される上記装置によって使用される上記リソースと上記条件とにしたがって、上記リソース要求を生成するよう構成される、
項目１８に記載の装置。
［項目２０］
クライアントとして使用される上記装置に上記リソース要求を上記第１の送信モジュールが送信する前に、サーバサイドとして使用される上記装置と、クライアントとして使用されるアクティブ装置との間の通信が正常であると判断したとき、クライアントとして使用される上記アクティブ装置をクライアントとして使用される上記装置として選択するよう構成される第１の選択モジュール
をさらに備える、項目１７から１９のいずれか一項に記載の装置。
［項目２１］
クライアントとして使用される上記装置に上記リソース要求を上記第１の送信モジュールが送信する前に、サーバサイドとして使用される上記装置と、クライアントとして使用されるアクティブ装置との間の通信が異常であると判断したとき、対応関係と、クライアントとして使用される上記アクティブ装置とにしたがって、クライアントとして使用されるスタンバイ装置をクライアントとして使用される上記装置として選択するよう構成される第２の選択モジュールであって、上記対応関係は、クライアントとして使用される上記アクティブ装置についての情報と、クライアントとして使用される上記スタンバイ装置についての情報とを含む、第２の選択モジュールをさらに備える、
項目１７から１９のいずれか一項に記載の装置。
［項目２２］
上記リソース要求は、ネットワークコンフィギュレーションＮＥＴＣＯＮＦプロトコルに基づく通知Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを備え、上記Ｎｏｔｉｆｉｃａｔｉｏｎメッセージは、サーバサイドとして使用される上記装置によって要求される上記リソースについての上記情報を有し、
上記リソース応答は、上記ＮＥＴＣＯＮＦプロトコルに基づくリモートプロシージャコールＲＰＣメッセージを備え、上記ＲＰＣメッセージは、サーバサイドとして使用される上記装置に割り当てられる上記リソースについての上記情報を有する、
項目１７から２１のいずれか一項に記載の装置。
［項目２３］
上記リソース要求は、ＲＥＳＴＣＯＮＦプロトコルに基づくＮｏｔｉｆｉｃａｔｉｏｎメッセージを備え、上記Ｎｏｔｉｆｉｃａｔｉｏｎメッセージは、サーバサイドとして使用される上記装置によって要求される上記リソースについての情報を有し、
上記リソース応答は、上記ＲＥＳＴＣＯＮＦプロトコルに基づくポストＰＯＳＴメッセージを備え、上記ＰＯＳＴメッセージは、サーバサイドとして使用される上記装置に割り当てられる上記リソースについての上記情報を有する、
項目１７から２１のいずれか一項に記載の装置。
［項目２４］
上記リソース要求は、取得メッセージを備え、上記取得メッセージは、サーバサイドとして使用される上記装置によって要求される上記リソースについての上記情報を有し、
上記リソース応答は、応答メッセージを備え、上記応答メッセージは、サーバサイドとして使用される上記装置に割り当てられる上記リソースについての上記情報を有し、上記応答メッセージは、上記取得メッセージに応答するために使用される、
項目１７から２１のいずれか一項に記載の装置。
［項目２５］
サーバサイドとして使用される上記装置によって要求される上記リソースについての上記情報は、第１のアクションタイプと、サーバサイドとして使用される上記装置によって要求される上記リソースのパラメータとを含み、上記第１のアクションタイプは、サーバサイドとして使用される上記装置によって要求される上記リソースに対して実行される操作を表すために使用され、
サーバサイドとして使用される上記装置に割り当てられる上記リソースについての上記情報は、第２のアクションタイプと、サーバサイドとして使用される上記装置に割り当てられる上記リソースのパラメータとを含み、上記第２のアクションタイプは、サーバサイドとして使用される上記装置に割り当てられる上記リソースに対して実行される操作を表すために使用される、
項目１７から２４のいずれか一項に記載の装置。
［項目２６］
サーバサイドとして使用される上記装置によって要求される上記リソースについての上記情報は、第１のアクションタイプと、第１の識別子と、サーバサイドとして使用される上記装置によって要求される上記リソースのパラメータとを含み、上記第１のアクションタイプは、サーバサイドとして使用される上記装置によって要求される上記リソースに対して実行される操作を表すために使用され、上記第１の識別子は、上記リソース要求の順序を表すために使用され、
サーバサイドとして使用される上記装置に割り当てられる上記リソースについての上記情報は、第２の識別子と、サーバサイドとして使用される上記装置に割り当てられる上記リソースのパラメータとを含み、上記第２の識別子は、上記リソース応答の順序を表すために使用され、上記第２の識別子は、上記第１の識別子に対応している、
項目１７から２４のいずれか一項に記載の装置。
［項目２７］
クライアントとして使用される装置であって、
サーバサイドとして使用される装置によって送信されたリソース要求を受信するよう構成される受信モジュールであって、上記リソース要求は、サーバサイドとして使用される上記装置によって要求されるリソースについての情報を含む、受信モジュールと、
サーバサイドとして使用される上記装置によって要求される上記リソースについての、上記リソース要求に含まれる上記情報にしたがって、サーバサイドとして使用される上記装置に割り当てられるリソースについての情報を取得するよう構成される取得モジュールと、
サーバサイドとして使用される上記装置にリソース応答を送信するよう構成される送信モジュールであって、上記リソース応答は、サーバサイドとして使用される上記装置に割り当てられる上記リソースについての上記情報を含む、送信モジュールと
を備える装置。
［項目２８］
上記リソース要求は、ネットワークコンフィギュレーションＮＥＴＣＯＮＦプロトコルに基づく通知Ｎｏｔｉｆｉｃａｔｉｏｎメッセージを備え、上記Ｎｏｔｉｆｉｃａｔｉｏｎメッセージは、サーバサイドとして使用される上記装置によって要求される上記リソースについての上記情報を有し、
上記リソース応答は、上記ＮＥＴＣＯＮＦプロトコルに基づくリモートプロシージャコールＲＰＣメッセージを備え、上記ＲＰＣメッセージは、サーバサイドとして使用される上記装置に割り当てられる上記リソースについての上記情報を有する、
項目２７に記載の装置。
［項目２９］
上記リソース要求は、ＲＥＳＴＣＯＮＦプロトコルに基づくＮｏｔｉｆｉｃａｔｉｏｎメッセージを備え、上記Ｎｏｔｉｆｉｃａｔｉｏｎメッセージは、サーバサイドとして使用される上記装置によって要求される上記リソースについての上記情報を有し、
上記リソース応答は、上記ＲＥＳＴＣＯＮＦプロトコルに基づくポストＰＯＳＴメッセージを備え、上記ＰＯＳＴメッセージは、サーバサイドとして使用される上記装置に割り当てられる上記リソースについての上記情報を有する、
項目２７に記載の装置。
［項目３０］
上記リソース要求は、取得メッセージを備え、上記取得メッセージは、サーバサイドとして使用される上記装置によって要求される上記リソースについての上記情報を有し、
上記リソース応答は、応答メッセージを備え、上記応答メッセージは、サーバサイドとして使用される上記装置に割り当てられる上記リソースについての上記情報を有し、上記応答メッセージは、上記取得メッセージに応答するために使用される、
項目２７に記載の装置。
［項目３１］
サーバサイドとして使用される上記装置によって要求される上記リソースについての上記情報は、第１のアクションタイプと、サーバサイドとして使用される上記装置によって要求される上記リソースのパラメータとを含み、上記第１のアクションタイプは、サーバサイドとして使用される上記装置によって要求される上記リソースに対して実行される操作を表すために使用され、
サーバサイドとして使用される上記装置に割り当てられる上記リソースについての上記情報は、第２のアクションタイプと、サーバサイドとして使用される上記装置に割り当てられる上記リソースのパラメータとを含み、上記第２のアクションタイプは、サーバサイドとして使用される上記装置に割り当てられる上記リソースに対して実行される操作を表すために使用される、
項目２７から３０のいずれか一項に記載の装置。
［項目３２］
サーバサイドとして使用される上記装置によって要求される上記リソースについての上記情報は、第１のアクションタイプと、第１の識別子と、サーバサイドとして使用される上記装置によって要求される上記リソースのパラメータとを含み、上記第１のアクションタイプは、サーバサイドとして使用される上記装置によって要求される上記リソースに対して実行される操作を表すために使用され、上記第１の識別子は、上記リソース要求の順序を表すために使用され、
サーバサイドとして使用される上記装置に割り当てられる上記リソースについての上記情報は、第２の識別子と、サーバサイドとして使用される上記装置に割り当てられる上記リソースのパラメータとを含み、上記第２の識別子は、上記リソース応答の順序を表すために使用され、上記第２の識別子は、上記第１の識別子に対応している、
項目２７から３０のいずれか一項に記載の装置。

Claims

リソースコンフィギュレーション方法であって、
リソース要求をサーバサイドが取得する段階であって、前記リソース要求は、前記リソース要求に示されるリソースについての情報を備える、段階と、
ネットワークコンフィギュレーションプロトコル（ＮＥＴＣＯＮＦ）またはリプレゼンテーショナルステートトランスファーコンフィギュレーションプロトコル（ＲＥＳＴＣＯＮＦ）に基づいて、前記リソース要求をクライアントに前記サーバサイドが送信する段階と、
前記クライアントから送信されたリソース応答を前記サーバサイドが受信する段階であって、前記リソース応答は、前記サーバサイドに割り当てられるリソースについての情報を備える、段階と
を備える方法であって、
リソース要求をサーバサイドが取得する前記段階の前に、
前記サーバサイドによって使用されるリソースが条件を満たすかを前記サーバサイドが判断する段階であって、前記条件は、前記サーバサイドのリソース使用量を表すために使用される、段階をさらに備え、
リソース要求をサーバサイドが取得する前記段階は、
前記サーバサイドによって使用される前記リソースが前記条件を満たすと判断したとき、前記サーバサイドによって使用される前記リソースと前記条件とにしたがって、前記リソース要求を前記サーバサイドが生成する段階
を有する、方法。
ネットワークコンフィギュレーションプロトコル（ＮＥＴＣＯＮＦ）またはリプレゼンテーショナルステートトランスファーコンフィギュレーションプロトコル（ＲＥＳＴＣＯＮＦ）に基づいて、前記リソース要求をクライアントに前記サーバサイドが送信する前記段階の前に、
前記サーバサイドとアクティブクライアントとの間の通信が異常であると判断したとき、対応関係と前記アクティブクライアントとにしたがって、スタンバイクライアントを前記クライアントとして前記サーバサイドが選択する段階であって、前記対応関係は、前記アクティブクライアントについての情報および前記スタンバイクライアントについての情報を含む、段階をさらに備える、
請求項１に記載の方法。
前記リソース要求は、取得メッセージを備え、前記取得メッセージは、前記リソース要求に示される前記リソースについての前記情報を有し、
前記リソース応答は、応答メッセージを備え、前記応答メッセージは、前記リソース応答に示される前記リソースについての前記情報を有し、前記応答メッセージは、前記取得メッセージに応答するために使用される、
請求項１または２に記載の方法。
前記リソース要求に示される前記リソースについての前記情報は、第１のアクションタイプと、前記リソース要求に示される前記リソースのパラメータとを含み、前記第１のアクションタイプは、前記リソース要求に示される前記リソースに対して実行される操作を表すために使用され、
前記リソース応答に示される前記リソースについての前記情報は、第２のアクションタイプと、前記リソース応答に示される前記リソースのパラメータとを含み、前記第２のアクションタイプは、前記リソース応答に示される前記リソースに対して実行される操作を表すために使用される、
請求項１から３のいずれか一項に記載の方法。
前記リソース要求に示される前記リソースについての前記情報は、第１のアクションタイプと、第１の識別子と、前記リソース要求に示される前記リソースのパラメータとを含み、前記第１のアクションタイプは、前記リソース要求に示される前記リソースに対して実行される操作を表すために使用され、前記第１の識別子は、前記リソース要求のシーケンスを表すために使用され、
前記リソース応答に示される前記リソースについての前記情報は、第２の識別子と、前記リソース応答に示される前記リソースのパラメータとを含み、前記第２の識別子は、前記リソース応答のシーケンスを表すために使用され、前記第２の識別子は、前記第１の識別子に対応している、
請求項１から３のいずれか一項に記載の方法。
リソースコンフィギュレーション方法であって、
ネットワークコンフィギュレーションプロトコル（ＮＥＴＣＯＮＦ）またはリプレゼンテーショナルステートトランスファーコンフィギュレーションプロトコル（ＲＥＳＴＣＯＮＦ）に基づいて、サーバサイドによって送信されたリソース要求をクライアントが受信する段階であって、前記リソース要求は、前記リソース要求に示されるリソースについての情報を備える、段階と
前記リソース要求に示される前記リソースについての前記情報にしたがって、前記サーバサイドに割り当てられるリソースについての情報を前記クライアントが取得する段階と、
リソース応答を前記サーバサイドに前記クライアントが送信する段階であって、前記リソース応答は、前記サーバサイドに割り当てられる前記リソースについての前記情報を備える、段階と
を備え、
前記リソース要求に示される前記リソースについての前記情報は、第１のアクションタイプと、前記リソース要求に示される前記リソースのパラメータとを含む、または、第１のアクションタイプと、第１の識別子と、前記リソース要求に示される前記リソースのパラメータとを含み、
前記第１のアクションタイプは、前記リソース要求に示される前記リソースに対して実行される操作を表すために使用され、前記第１の識別子は、前記リソース要求のシーケンスを表すために使用され、
前記リソース応答に示される前記リソースについての前記情報は、第２のアクションタイプと、前記リソース応答に示される前記リソースのパラメータとを含む、または、第２の識別子と、前記リソース応答に示される前記リソースのパラメータとを含み、
前記第２のアクションタイプは、前記リソース応答に示される前記リソースに対して実行される操作を表すために使用され、前記第２の識別子は、前記リソース応答のシーケンスを表すために使用され、前記第２の識別子は、前記第１の識別子に対応している、
方法。
前記リソース要求は、取得メッセージを備え、前記取得メッセージは、前記リソース要求に示される前記リソースについての前記情報を有し、
前記リソース応答は、応答メッセージを備え、前記応答メッセージは、前記リソース応答に示される前記リソースについての前記情報を有し、前記応答メッセージは、前記取得メッセージに応答するために使用される、
請求項６に記載の方法。
サーバサイドとして動作する装置であって、
リソース要求を取得する取得モジュールであって、前記リソース要求は、サーバサイドとして動作する前記装置によって前記リソース要求に示されるリソースについての情報を含む、取得モジュールと、
ネットワークコンフィギュレーションプロトコル（ＮＥＴＣＯＮＦ）またはリプレゼンテーショナルステートトランスファーコンフィギュレーションプロトコル（ＲＥＳＴＣＯＮＦ）に基づいて、クライアントとして動作する装置に前記リソース要求を送信する送信モジュールと、
クライアントとして動作する前記装置によって送信されたリソース応答を受信する受信モジュールであって、前記リソース応答は、サーバサイドとして動作する前記装置に割り当てられるリソースについての情報を含む、受信モジュールと、
サーバサイドとして動作する前記装置によって使用されるリソースが条件を満たすかを判断する判断モジュールであって、前記条件は、サーバサイドとして動作する前記装置のリソース使用量を表すために使用される、判断モジュールと
を備え、
前記取得モジュールは具体的に、サーバサイドとして動作する前記装置によって使用される前記リソースが前記条件を満たすと判断したとき、サーバサイドとして動作する前記装置によって使用される前記リソースと前記条件とにしたがって、前記リソース要求を生成する、
装置。
クライアントとして動作する前記装置に前記リソース要求を前記送信モジュールが送信する前に、サーバサイドとして動作する前記装置と、クライアントとして動作するアクティブ装置との間の通信が正常であると判断したとき、クライアントとして動作する前記アクティブ装置をクライアントとして動作する前記装置として選択する第１の選択モジュール
をさらに備える、請求項８に記載の装置。
クライアントとして動作する前記装置に前記リソース要求を前記送信モジュールが送信する前に、サーバサイドとして動作する前記装置と、クライアントとして動作するアクティブ装置との間の通信が異常であると判断したとき、対応関係と、クライアントとして動作する前記アクティブ装置とにしたがって、クライアントとして動作するスタンバイ装置をクライアントとして動作する前記装置として選択する第２の選択モジュールであって、前記対応関係は、クライアントとして動作する前記アクティブ装置についての情報と、クライアントとして動作する前記スタンバイ装置についての情報とを含む、第２の選択モジュールをさらに備える、
請求項８または９に記載の装置。
前記リソース要求は、取得メッセージを備え、前記取得メッセージは、前記リソース要求に示される前記リソースについての前記情報を有し、
前記リソース応答は、応答メッセージを備え、前記応答メッセージは、前記リソース応答に示される前記リソースについての前記情報を有し、前記応答メッセージは、前記取得メッセージに応答するために使用される、
請求項８から１０のいずれか一項に記載の装置。
前記リソース要求に示される前記リソースについての前記情報は、第１のアクションタイプと、前記リソース要求に示される前記リソースのパラメータとを含み、前記第１のアクションタイプは、前記リソース要求に示される前記リソースに対して実行される操作を表すために使用され、
前記リソース応答に示される前記リソースについての前記情報は、第２のアクションタイプと、前記リソース応答に示される前記リソースのパラメータとを含み、前記第２のアクションタイプは、前記リソース応答に示される前記リソースに対して実行される操作を表すために使用される、
請求項８から１０のいずれか一項に記載の装置。
前記リソース要求に示される前記リソースについての前記情報は、第１のアクションタイプと、第１の識別子と、前記リソース要求に示される前記リソースのパラメータとを含み、前記第１のアクションタイプは、前記リソース要求に示される前記リソースに対して実行される操作を表すために使用され、前記第１の識別子は、前記リソース要求のシーケンスを表すために使用され、
前記リソース応答に示される前記リソースについての前記情報は、第２の識別子と、前記リソース応答に示される前記リソースのパラメータとを含み、前記第２の識別子は、前記リソース応答のシーケンスを表すために使用され、前記第２の識別子は、前記第１の識別子に対応している、
請求項８から１０のいずれか一項に記載の装置。
クライアントとして動作する装置であって、
ネットワークコンフィギュレーションプロトコル（ＮＥＴＣＯＮＦ）またはリプレゼンテーショナルステートトランスファーコンフィギュレーションプロトコル（ＲＥＳＴＣＯＮＦ）に基づいて、サーバサイドとして動作する装置によって送信されたリソース要求を受信する受信モジュールであって、前記リソース要求は、サーバサイドとして動作する前記装置によって前記リソース要求に示されるリソースについての情報を含む、受信モジュールと、
前記リソース要求に示される前記リソースについての前記情報にしたがって、サーバサイドとして動作する前記装置に割り当てられるリソースについての情報を取得する取得モジュールと、
サーバサイドとして動作する前記装置にリソース応答を送信する送信モジュールであって、前記リソース応答は、サーバサイドとして動作する前記装置に割り当てられる前記リソースについての前記情報を含む、送信モジュールと
を備え、
前記リソース要求に示される前記リソースについての前記情報は、第１のアクションタイプと、前記リソース要求に示される前記リソースのパラメータとを含む、または、第１のアクションタイプと、第１の識別子と、前記リソース要求に示される前記リソースのパラメータとを含み、
前記第１のアクションタイプは、前記リソース要求に示される前記リソースに対して実行される操作を表すために使用され、前記第１の識別子は、前記リソース要求のシーケンスを表すために使用され、
前記リソース応答に示される前記リソースについての前記情報は、第２のアクションタイプと、前記リソース応答に示される前記リソースのパラメータとを含む、または、第２の識別子と、前記リソース応答に示される前記リソースのパラメータとを含み、
前記第２のアクションタイプは、前記リソース応答に示される前記リソースに対して実行される操作を表すために使用され、前記第２の識別子は、前記リソース応答のシーケンスを表すために使用され、前記第２の識別子は、前記第１の識別子に対応している、
装置。
前記リソース要求は、取得メッセージを備え、前記取得メッセージは、前記リソース要求に示される前記リソースについての前記情報を有し、
前記リソース応答は、応答メッセージを備え、前記応答メッセージは、前記リソース応答に示される前記リソースについての前記情報を有し、前記応答メッセージは、前記取得メッセージに応答するために使用される、
請求項１４に記載の装置。