JP2008503943A - リソース管理の実現方法 - Google Patents

Abstract

本発明は、クロスドメインリソース管理の実現方法を開示している。サービス接続リソース要求を行う際に、各ドメインのボーダーCAは、まず、自体のドメイン内の特定ベアラネットワークリソースマネージャーに接続リソース要求を送信する。当該ベアラネットワークリソースマネージャーは宛先ユーザ設備が自体の管理ドメイン内にあるかどうかを判断して、自体の管理ドメイン内にあれば、対応する前処理を行い、所属するCAに操作の成功の応答を返信し、そうでなければ、対応する前処理を行い、所属のCAに前処理の成功の応答を返信する。上記CAは受信した後、次いでネクストホップのボーターCAにサービス接続リソース要求を送信する。当該方法は、クロスドメインサービス接続リソースの管理と、異なるドメイン間の相互接続を実現できる。

Description

本発明は、リソース管理技術に関し、特にクロスドメイン（cross-domain）リソース管理の実現方法に関する。

Internet規模の不断の増大に伴って、様々なネットワークサービスが次々と現れ、先進なマルチメディアシステムも次々と現れている。リアルタイムサービスがネットワークの伝送遅延、遅延揺らぎなど特性に対して比較的敏感であることで、ネットワークに突発性の高いファイル伝送プロトコル（FTP）、又は画像ファイルを含むHyperText伝送プロトコル（HTTP）などサービスがある場合、リアルタイムサービスに対する影響が大きい。また、マルチメディアサービスが大量な帯域幅の占めを必要とするため、既存ネットワークにおいて保証される必要のある核心サービスを確実に転送することが難しくなる。それで、核心サービスの確実な転送を保証するため、種々なサービス品質（QoS，Quality of Service）技術が現れた。インターネット・エンジニアリング・タスクフォース(IETF, Internet Engineering Task Force)は、QoSの需要を満たすため、もう多くのサービスモデルとメカニズムを提出した。例えば、ネットワークのアクセス又はエッジで統合サービス（Int-Serv，Integrated Service）モデルを使用し、ネットワークのコアで差別化サービス（Diff-Serv，Differentiated Service）モデルを使用するのである。

Diff-Servモデルは、優先度を設定することだけでQoSを保障している。当該モデルは回路の利用率が高い特徴はもっているが、具体的な効果を予測することで難しい。それで、バックボーンネットワーク（backbone network）のDiff-Servモデルに一つの独立したベアラ制御層が導入され、専門的Diff-Serv QoSシグナリングメカニズムが確立された。そしてネットワークのトポロジーリソースを管理するために、Diff-Servネットワークのためのリソース管理レイヤーが専門的に確立されている。このようなリソース管理Diff-Serv方式は独立したベアラ制御層を有するDiff-Servモデルと呼ばれる。図１は独立したベアラ制御層を有するDiff-Servモデルを示す図である。図１に示すように、当該モデルにおいて、ベアラ制御層102はベアラネットワーク103とサービス制御層101の間に置かれている。サービス制御層101の中のコールエージェント（CA、Call Agent）はサービスサーバ、例えば、ソフトスイッチなどであり、ソフトスイッチなどの機能を実現することができる。ベアラ制御層102には、一つ又は複数のベアラネットワークリソースマネージャーが備えている。ベアラネットワークリソースマネージャーは、管理規則とネットワークトポロジーを配置し、クライアントのサービス帯域幅申し込みのためにリソースを分配し、各ベアラネットワークリソースマネージャーの間でシグナリングを通じて伝送されるクライアントのサービス帯域幅申し込み要求と結果、及びサービス申し込みのために分配されたルートパス情報などを制御し管理すること、例えば、ベアラネットワークリソースマネージャー１と、ベアラネットワークリソースマネージャー2と、ベアラネットワークリソースマネージャー3との間の通信を制御し管理することなどを担っている。ベアラネットワーク103の中で、一つのベアラネットワークリソースマネージャーは一つの特定のベアラネットワーク区域を管理している。この特定のベアラネットワーク区域は対応されるベアラネットワークリソースマネージャーの管理ドメインと呼ばれる。例えば、ベアラネットワークリソースマネージャー１の管理ドメイン105、ベアラネットワークリソースマネージャー2の管理ドメイン106とベアラネットワークリソースマネージャー3の管理ドメイン107など。ベアラネットワーク103にはエッジルータ（ER，Edge Router）、ボーダールータ（BR，Border Router）及びコアルータ104などが備えている。ER、BRとコアルータは全てベアラネットワークに属し、接続ノード（CN，Connection Node）と総称されている。

独立したベアラ制御層を有するDiff-Servモデルのなかで、ベアラネットワークリソースマネージャーは管理規則とネットワークトポロジーを配置して、クライアントのサービス帯域幅申し込みのためにリソースを分配している。ベアラ制御層がユーザのサービス帯域幅申し込みを処理するとき、ベアラネットワークリソースマネージャーはユーザサービスのパスを決定し、指定されたパスに従ってサービスフローを転送するようにエッジルータに通知する。現在、ベアラネットワークがベアラ制御層に決定されたパスに基づいて、ユーザサービスフローを指定された経路に従って転送するプロセスでは、主にマルチプロトコルラベルスイッチング（MPLS）技術を利用している。即ち、リソース予約方式を使用してベアラ制御層に指定されたサービスフローのパスに沿ってラベルスイッチパス（LSP、Label Switched Path）を確立し、リソース予約プロトコル-トラフィックエンジニアリング（RSVP-TE、Resource Reservation Protocol-Traffic Engineering）又は制約ベースルーティング （CR-LDP、Constraint-based Routing LDP）の経路表示メカニズムを使用してエンドツーエンドのLSPを確立している。

このような方案では、エンドツーエンドの全体のネットワークのトポロジー構造とリソース状況を知ってこそ、エンドツーエンドのQoSを厳格に保証することができる。しかし、異なる独立運営ネットワークの間では、ビジネス、セキュリティなどの問題のため、現地ネットワークの部署状況とネットワークリソース品質状況が他の独立運営ネットワークに知られることを希望していない。だから、当該方案の応用範囲には一定の局限性がある。

現在、独立したベアラ制御層を有するDiff-Servモデルはまた少なくない。例えば、サービス品質のバックボーン実験ネットワーク（Qbone，Quality-of-Service backbone）の帯域幅ブローカーモデルである。図2はQboneの帯域幅ブローカーモデルを示す図である。図2に示すように、当該モデルでは各Diff-Serv管理ドメインのためにみな対応する帯域幅ブローカーを設置した。例えば、帯域幅ブローカー1、帯域幅ブローカー2と帯域幅ブローカー3などである。前記帯域幅ブローカーは、ユーザホスト、サービスサーバ、又はネットワークをメンテナンスする人からの帯域幅申し込み要求を処理し、現在ネットワークのリソース予約状況、配置戦術、及びユーザと締結したサービスレベルアグリーメント（SLA，Service Level Agreement）などに基づいて、ユーザの帯域幅申し込みを許可するかどうかを決定する。当該帯域幅ブローカーの内部構造は、図3に示すように、ドメイン間インタフェース、ユーザサービスインタフェース、戦術インタフェース、ネットワークマネジメントインタフェース、経路情報、データベース、ドメイン内インタフェースと簡単戦術サービスモデルなどを含んでいる。当該帯域幅ブローカーには、各種類のSLA配置情報、物理ネットワークのトポロジー情報、ルータの配置情報と戦術情報、ユーザ認証情報、現在のリソース予約情報、ネットワーク占有状態情報など大量な静的又は動的な情報が記録されている。同時に、帯域幅ブローカーは、ユーザのサービスフローのパスとクロスドメインのダウンストリーム帯域幅ブローカーの位置を決定するために、経路情報を記録する必要がある。その中で、上記Diff-Serv管理ドメインは図に示すような管理ドメインA、管理ドメインB、管理ドメインCである。

このような技術方案において、帯域幅ブローカーが区域内全てのルータのリソースと配置情報を直接に管理していて、トポロジーと管理が余りにも複雑な問題がある。同時に、帯域幅ブローカーが本区域の動的な経路情報を記録する必要があるため、経路表の更新が頻繁な問題があり、ネットワーク予約が不安定になってしまう。そして、本区域の動的な経路情報に基づいて帯域幅ブローカーによって決定された、サービス経路をサービスフローの実際的な転送経路と一致させることも難しい。

本発明は上記に鑑みてなされたものであって、クロスドメインサービス接続リソースの管理を実現し、異なるドメイン間の相互接続を実現することができる、リソース管理の実現方法を提供することを主たる目的とする。

上記の目的に達するため、本発明の技術方案は下記のように実現される。
リソース管理の実現方法であって、サービス接続リソース要求を行う際に、当該方法は、
各ドメインのボーダーコールエージェントCAは自体のドメイン内のベアラネットワークリソースマネージャーに接続リソース要求を送信し、要求を受信したベアラネットワークリソースマネージャーは宛先ユーザ設備が自体の管理ドメイン内にあるかどうかを判断して、自体の管理ドメイン内にあれば、ステップｂを実行し、そうでなければ、ステップｄを実行するステップaと、
当該ベアラネットワークリソースマネージャーは対応する処理を行い、所属するCAに要求の成功の応答を返信するステップｂと、
リソース申し込みの応答を受信したCAは自体がソースボーターCAであるかどうかを判断して、そうであれば、対応する処理を行うように自体のドメイン内のベアラネットワークリソースマネージャーに指示し、処理に成功した後、現在の処理手順を終了し、そうでなければ、対応する処理を行うように自体のドメイン内のベアラネットワークリソースマネージャーに指示し、処理に成功した後、自体の前のホップボーダーCAに要求の成功の応答を送信してから、このステップに戻るステップｃと、
当該ベアラネットワークリソースマネージャーは対応する前処理を行い、所属するCAに前処理の成功の応答を返信し、前記CAは前処理の応答を受信した後、次いでネクストホップのボーダーCAにサービス接続リソース要求を送信し、ステップaに戻るステップｄとを含む。

上記方案で、ステップaにおいて、現在のサービスフローの接続情報を収納することを更に含む。

上記方案で、ステップｂとｃにおける前記対応する処理を行うことは、具体的に、ベアラネットワークリソースマネージャーがサービスルーティング、LSPリソースの分配を完了し、ベアラネットワーク設備にQoS戦術を送信することである。

上記方案で、ステップｄにおける前記サービス接続リソース要求には、ボーダールータアドレスシーケンス、サービスレベルアグリーメントSLAとQoSパラメータが付けられている。ステップｄにおいて前記対応する前処理を行うことは、具体的に、経路リソース、帯域幅リソースを含むサービス接続に必要なリソースを予約することである。

上記方案で、前記ドメインは、地理区域、又は専用ネットワーク、又は独立の運営ネットワークである。各ドメイン内に一つ以上のボーダーCAが含まれ、全てのボーダーCAは共同で一つのベアラネットワークリソースマネージャーに対応され、或いは，各ドメイン内に一つ以上のボーダーCAが含まれ、各ボーダーCAはそれぞれ一つのベアラネットワークリソースマネージャーに対応される。前記接続リソース要求は、サービス経路を申し込む要求であり、又はサービス接続リソースを修正する要求であり、又はサービス接続リソースを解放する要求である。前記ベアラネットワークリソースマネージャーは、ソースユーザ設備の属するベアラネットワークリソースマネージャーであり、又は入口BRの属するベアラネットワークリソースマネージャーである。

本発明に提供されるリソース管理の方法は、クロスドメインのサービス接続を確立する際に、各ドメインのボーダーCAと一つの特定ベアラネットワークリソースマネージャーを通じて、サービス経路の選択、サービス接続リソースの分配や修正又は解放を完了して、相互透明な異なる運営ネットワークが相互接続されている場合のQoSシグナリングを解決し、SIP/H.248のような既存応用層シグナリングを拡張し、ベアラ制御層のシグナリング需要を低下し、相互接続の可能性を高め、サービス接続のためなるべく連続的なQoSを提供し、ベアラネットワークでサービス接続のQoSを高めている。そして、異なるQoS方案を採用した各種類のドメイン間で相互接続を行うことが便利になって、拡張性が優れている。

本発明の主な考えは、クロスドメインの、サービス接続に係る、サービス経路リソースの申し込み、修正、解放のドメイン間シグナリング過程を提出することである。具体的には、異なるドメインに対して、当該ドメイン内のボーダーCA及び一つの特定ベアラネットワークリソースマネージャーだけでサービス経路の申し込みやサービス接続リソースの修正、解放を行うことである。サービス接続リソース要求を行うとき、各ドメインのボーダーCAは、まず、自体のドメイン内の特定ベアラネットワークリソースマネージャーに対して接続リソース要求を送信する。当該ベアラネットワークリソースマネージャーは宛先ユーザ設備が自体の管理ドメイン内にあるかどうかを判断して、自体の管理ドメイン内にあれば、対応する処理を行い、所属するCAに操作の成功の応答を返信し、他の場合には、対応する前処理を行い、所属するCAに前処理の成功の応答を返信し、当該CAは受信した後、続いてネクストホップのCAにサービス接続リソース要求を送信する。

その中で、上記ボーダーCAは他のドメインCAと接続されるCAであり、各ドメイン内には複数のボーダーCAを備え、それぞれ異なるドメインのCAと相互接続されることができる。上記特定ベアラネットワークリソースマネージャーはCAによって指定されたものであり、ソースユーザ設備が属するベアラネットワークリソースマネージャー、又はある入口BRが属するベアラネットワークリソースマネージャーであることができる。当該特定ベアラネットワークリソースマネージャーはボーダーCAと直接に接続されることができ、ボーターCAと間接に接続されることもできる。同一のドメインに対して、複数のボーダーCAを選択したら、選択された全てのボーダーCAは共同で一つの特定ベアラネットワークリソースマネージャーに対応されることができ、各CAが一つの特定ベアラネットワークリソースマネージャーに対応されることもできる。例えば、あるドメイン内にCA1〜CA5など五つのCAが含まれ、そのなかでCA1とCA3がボーダーCAであり、それぞれ二つの異なるドメインと接続されているなら、CA1とCA3は共同で一つの特定ベアラネットワークリソースマネージャーに対応されることができ、それぞれ二つの異なる特定ベアラネットワークリソースマネージャーに対応されることもできる。

ここで、上記のドメインは一つの区域であり、異なる角度から区分されることができる。地理位置の角度から区分するなら、各ドメインは異なる地理区域、例えば、一つの省、市、地区などに対応されることができる。サービス機能の角度から区分するなら、各ドメインは異なる専用ネットワーク、例えば、金融ネットワーク、教育ネットワークなどに対応されることができる。サービスプロバイダーの角度から区分するなら、各ドメインは異なる独立運営ネットワークに対応されることができる。上記クロスドメインとは、ソースユーザ設備と宛先ユーザ設備が異なるドメインに属することを指すものであり、異なるドメインのCA間でサービス接続リソースの分配、修正又は解放を行う必要がある。上記の接続リソース要求は、サービス経路申し込みの要求、又はサービス接続リソースの修正要求、又はサービス接続リソースの解放要求であって良い。

本発明方案の核心は、各ドメインにおいて、ボーダーCAと一つの特定ベアラネットワークリソースマネージャーを通じて、現在サービス接続リソース要求に対応する操作を完了することである、例えば、経路を選択し、そして対応するリソース分配を行い、又は対応するリソースに対して修正を行い、又は対応するリソースを解放することである。対応する処理が当該特定ベアラネットワークリソースマネージャーだけに係るなら、当該ベアラネットワークリソースマネージャーは自体の管理ドメイン内で対応する処理を完了する。対応する処理が複数のベアラネットワークリソースマネージャーに係るなら、当該特定ベアラネットワークリソースマネージャーは自体の管理ドメイン内での処理を完了する必要があるだけでなく、自体とそれが接続されているベアラネットワークリソースマネージャーとの間のドメイン間リソース処理、例えば、ドメイン間経路選択を行う必要もある。各ドメイン内の特定ベアラネットワークリソースマネージャーを決定することを基本として、CAの間で行われる全てのサービス経路申し込み、サービス接続リソース修正、又はサービス接続リソース解放は、全部独立したベアラネットワークリソースマネージャーに基づいて完了される。

各ベアラネットワークリソースマネージャーに対して、各ベアラネットワークリソースマネージャー内部では同一又は異なるQoS計算方法を採用して、現在サービス接続リソース要求のために、管轄されるベアラレイヤーのサービス経路と所要するリソースを計算し、現在のサービス接続に対する最適パスを選出することができる。ここのサービス経路を計算するとは、ベアラネットワークリソースマネージャーはそれが管理するドメイン内のIPアドレス、ER、BRトポロジー、ドメイン内のLSPリソースとドメインの出口のIPアドレス、隣接のBR、ベアラネットワークリソースマネージャートポロジー、及びドメインの出口LSPリソースなどに基づいて、CA又は隣接ベアラネットワークリソースマネージャーからのサービス接続要求のためにサービス経路選択を行い、サービスフローのドメイン内LSP、ドメインの出口LSPを決定することである。

各ベアラネットワークリソースマネージャーのドメイン内のサービス経路選択の方式に対して、多種の既存のドメイン内経路選択計算方法を採用することができる。例えば、ベアラネットワークリソースマネージャーで各CNのため一つのマトリックス経路表を設置し、入口ルータと出口ルータに基づいて対応するLSPを選択することで、ベアラ制御層内各ベアラネットワークリソースマネージャーのドメイン内経路選択を実現し、サービスルーティングを完了する。このように、各サービス接続リソース要求は一連のLSPとバインディングされ、コールが終わると、LSPと他のリソースは全て解放される。同様に、ベアラネットワークリソースマネージャーのドメイン間のサービス経路選択の方式に対しても、既存のドメイン間経路選択計算方法を採用することができる。また、ドメイン間とドメイン内でリソース分配を行うプロセスに対しても、同様に既存の方案を採用することができる。具体的な経路選択方案とリソース分配方法は本出願者の他の特許出願に詳しく開示され、説明されており、ここでは省略する。

本発明方法の一具体的な実施例は図４に示すようである。図４で、ベアラネットワークリソースマネージャーはCMと表示され、一つのCAiは一つのCMiに対応し、iは１からｎまでの正整数であり、一対のCAiとCMiは一つのドメインを代表する。図４でのCA1はソースユーザ設備の所属するCAを表示し、CAnは宛先ユーザ設備の所属するCAである。図４はサービス接続申し込みを例としたものであり、本実施例でのリソース予約には経路リソース、帯域幅リソースなどサービス接続に必要なリソースが含まれ、それに対応して、リソースを分配することは、経路パスを選定し、占有される帯域幅リソースを決定することなどである。本実施例でのリソース管理の方法は下記のステップを含む。

1）CA1はユーザ設備のコール要求を受信した後、CM1に接続リソース要求を開始し、現在のサービスフローのため接続情報を収納する。本実施例で、CM1は要求を開始するユーザ設備の属するベアラリソースマネージャーである。

他のCAに対しては、接続リソース要求を受信した後、対応するCMに接続リソース要求を開始し、現在サービスフローのため接続情報を収納する。ここで、あるCAの対応するCMとは、当該CAの属するドメインでの特定ベアラネットワークリソースマネージャー、例えば、CM2、……、CMnを指すものである。

後にサービス経路計算方法を利用してドメイン内の経路選択を行うために、ソースベアラネットワークリソースマネージャーCM1は受信された接続リソース要求の中のクインティプル（quintuple）のソースIPアドレスに基づいて、当該IPアドレスがどのERに属するかを決定する。

ソースベアラネットワークリソースマネージャー以外の他のベアラネットワークリソースマネージャーにとって、接続リソース要求のパラメータに乗せられているのは対応するベアラネットワークリソースマネージャー管理ドメインの入口BRアドレスであり、入口BRのアドレスは経路選択の過程で決定される。例えば、ホップバイホップ経路計算方法で、入口BRアドレスは、前のホップのベアラネットワークリソースマネージャーによってドメイン間LSPが選択された後、決定される。即ち、当該LSPの出口ルータアドレスシーケンスである。本実施例で、CM2……CMnは入口BRが属するベアラネットワークリソースマネージャーである。

2）CMiはサービス経路計算方法を利用してドメイン内の経路選択を行い、ドメイン内LSPリソースを申し込み、そしてこれらのLSPリソース情報を記録する。下記はCM1だけを例としており、他のCMの処理はCM１の処理と完全に同じである。

3）CM1は宛先ユーザ設備が自体の管理ドメイン内にあるかどうかを判断して、宛先ユーザ設備が管理ドメイン内にあれば、CM1はリソースを分配し、QoS戦術を対応するベアラネットワーク設備に送信し、その後実行の結果をCA1に返信する。宛先ユーザ設備が管理ドメイン内になければ、CM1はCA1に対して予約成功を応答し、当該応答にはサービス接続リソース要求の中に元にあったQoSパラメータ、サービス種類が付けられている。もちろん、CA1にこれらのパラメータが既に保留されているなら、応答でこれらのパラメータをCA1に返信する必要がなくなる。当該応答にはまたCM1で選定されたドメイン間ルータアドレスシーケンスとドメイン間SLAが付けられている。

4）CA1は予約応答を受信した後、自体が接続されているネクストホップCA2に対して接続リソース要求を送信し、当該要求にはエッジルータアドレスシーケンス、SLA、QoSパラメータが付けられている。ネクストホップCA2はアップストリームCA1から送信される接続リソース要求を受信した後、当該要求を対応するCM2に転送する。当該CM2はCM１に管轄される経路と相互接続されているエッジルータを見付け、独立運営ネットワーク自体の規則とSLAに基づいて適当な入口ルータを選択する。

宛先ユーザ設備の所属するベアラネットワークリソースマネージャー以外の全てのベアラネットワークリソースマネージャーは、要求が宛先ユーザ設備の所属するCMnに到達するまでに、ステップ1〜4を繰り返して実行する。

5）宛先CMnはサービスルーティング、LSPリソースの分配を完了し、QoS戦術を送信し、その後、対応するCAnに対してリソース申し込みの応答を返信する。CAnはりソース申し込みの応答を受信した後、前のホップCAに対してリソース申し込みの応答を返信する。

6）前のホップCAはリソース申し込みの応答を受信した後、自体のドメイン内のCMに接続リソース分配情報を送信する。CMは受信した後、サービスルーティング、LSPリソースの分配を完了し、QoS戦術を送信し、その後対応するCAに対してリソース申し込みの応答を返信する。CAはりソース申し込みの応答を受信した後、前のホップCAに対してリソース申し込みの応答を返信する。

宛先CMn以外の他のベアラネットワークリソースマネージャーは、リソース申し込みの応答を通じて前のホップCAに対して、自体のLSPリソースとネクストホップベアラネットワークリソースマネージャーから返信されたLSPリソースを一緒に送信し、まだこれらのLSPリソースは前のホップCAによって対応するCMに送信され、申し込みの応答がCM1に到達するまでに本ステップを繰り返す。

7）CM1はストリームマッピングコマンドをスタートし、会話ID、ストリーム情報、QoSパラメータ、トラフィック記述子及び全体のパスのラベルスタックなどの情報をERに送信する。

サービスリソース修正、サービスリソース解放に関連する処理プロセスは上記の手順と似ている。

本発明で、ベアラネットワークリソースマネージャーによって管轄されるベアラネットワークはMPLSネットワークに局限しなく、トラフィックエンジニアリングをサポートしている他のネットワーク、例えば、ATMネットワーク、光ネットワーク及び他のネットワークであっていい。ドメイン内パスの計算方法はホップバイホップパス計算方法に局限しなく、他のQoS計算方法であっていい。

ドメイン間ルータ間のネットワークにおいて、SLA又はQoSがサポートされないと、トンネル方式、又はIP TOS/差別化サービスモデルに基づいたDiff-Servコードポイント（DSCP、Diff-Serv Code Point）を使用してトラフィック分類と転送を行うことができる。

ベアラネットワークリソースマネージャーの間には、サービス接続リソース分配、修正、解放、及びベアラ制御層のメンテナンスシグナリングとして、ある特定のプロトコルを使用することができる。

上記は本発明の好ましい実施例に過ぎず、本発明の保護範囲を限定するものではない。

独立したベアラ制御層を有する差別化サービスモデルを示す図である。 Qboneの帯域幅ブローカーモデルを示す図である。 図2における帯域幅ブローカーの内部構造を示す図である。 本発明方法の一具体的な実施例の処理流れ図である。

符号の説明

CA コールエージェント
CM ベアラネットワークリソースマネージャー

Claims (10)

1. リソース管理の実現方法であって、サービス接続リソース要求を行う際に、
   各ドメインのボーダーコールエージェントCAは自体のドメイン内のベアラネットワークリソースマネージャーに接続リソース要求を送信し、要求を受信したベアラネットワークリソースマネージャーは宛先ユーザ設備が自体の管理ドメイン内にあるかどうかを判断して、自体の管理ドメイン内にあれば、ステップｂを実行し、そうでなければ、ステップｄを実行するステップaと、
   当該ベアラネットワークリソースマネージャーは対応する処理を行い、所属するCAに要求の成功の応答を返信するステップｂと、
   リソース申し込みの応答を受信したCAは自体がソースボーターCAであるかどうかを判断して、そうであれば、対応する処理を行うように自体のドメイン内のベアラネットワークリソースマネージャーに指示し、処理に成功した後、現在の処理手順を終了し、そうでなければ、対応する処理を行うように自体のドメイン内のベアラネットワークリソースマネージャーに指示し、処理に成功した後、自体の前のホップボーダーCAに要求の成功の応答を送信してから、このステップに戻るステップｃと、
   当該ベアラネットワークリソースマネージャーは対応する前処理を行い、所属するCAに前処理の成功の応答を返信し、前記CAは前処理応答を受信した後、次いでネクストホップのボーダーCAにサービス接続リソース要求を送信し、ステップaに戻るステップｄと
   を含むことを特徴とする方法。
2. ステップaにおいて、現在のサービスフローの接続情報を収納することを更に含むことを特徴とする請求項1記載の方法。
3. ステップｂとｃにおける前記対応する処理を行うことは、具体的に、ベアラネットワークリソースマネージャーがサービスルーティング、LSPリソースの分配を完了し、ベアラネットワーク設備にQoS戦術を送信することであることを特徴とする請求項1記載の方法。
4. ステップｄにおける前記サービス接続リソース要求には、ボーダールータアドレスシーケンス、サービスレベルアグリーメントSLAとQoSパラメータが付けられていることを特徴とする請求項1記載の方法。
5. ステップｄにおいて前記対応する前処理を行うことは、具体的に、経路リソース、帯域幅リソースを含むサービス接続に必要なリソースを予約することであることを特徴とする請求項1記載の方法。
6. 前記ドメインは、地理区域、又は専用ネットワーク、又は独立の運営ネットワークであることを特徴とする請求項1記載の方法。
7. 各ドメイン内に一つ以上のボーダーCAが含まれ、全てのボーダーCAは共同で一つのベアラネットワークリソースマネージャーに対応されることを特徴とする請求項1記載の方法。
8. 各ドメイン内に一つ以上のボーダーCAが含まれ、各ボーダーCAはそれぞれ一つのベアラネットワークリソースマネージャーに対応されることを特徴とする請求項1記載の方法。
9. 前記接続リソース要求は、サービス経路を申し込む要求であり、又はサービス接続リソースを修正する要求であり、又はサービス接続リソースを解放する要求であることを特徴とする請求項1記載の方法。
10. 前記ベアラネットワークリソースマネージャーは、ソースユーザ設備の属するベアラネットワークリソースマネージャーであり、又は入口BRの属するベアラネットワークリソースマネージャーであることを特徴とする請求項1、7又は8記載の方法。

Images