(57)【要約】      （修正有）【課題】ＩＰネットワークでＱｏＳを保証するための方法を提供する。【解決手段】ＩＰベアラネットワーク内のＩＰパケットのルート選択の機能で分離され、保証ＱｏＳ要件を伴うサービスに対する同じ機能が、ベアラ制御レイヤ内のベアラネットワークリソースマネージャによって達成される。ネットワークリソース占有状態に応じてルート選択を完了した後、ベアラネットワークリソースマネージャは、マルチレベルラベルスタック技術によりベアラネットワーク内のリソースマネージャによって指定されたパスに従ってトラヒックストリームが転送されるようにエッジルータを制御する。さらに、ＩＰネットワークにおいて保証ＱｏＳを提供するためのシステムも開示する。方法およびシステムは、優れた拡張性を備えており、従来のネットワークにほとんど影響を及ぼさない。【選択図】  図６
2004254328.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰネットワークにおいて保証サービス品質（ＱｏＳ：Quality of Service）を提供するための方法であって、
前記ネットワーク内の関連サービスエンティティが、加入者から保証ＱｏＳ要件を伴うサービス要求を受信した後、前記サービス要求を分析することによって送信元加入者および宛先加入者のアドレスならびにサービスのＱｏＳパラメータを取得し、ルート選択およびリソース適用要求を前記ネットワークのベアラ制御レイヤに送信するステップａと、
ベアラ制御レイヤ内のベアラネットワークリソースマネージャが、送信元加入者および宛先加入者の前記アドレスならびにサービスタイプに従って、サービスベアラ論理ネットワーク内のサービスに対するルートおよびリソースを割り当てるステップｂと、
前記ベアラ制御レイヤによって決定されたルートおよびリソースに従って、前記サービスベアラ論理ネットワーク内のトラヒックストリームを転送するステップｃと、
を有する。
【請求項２】
前記サービスベアラ論理ネットワークは、前記サービスタイプに従って基本ネットワークからあらかじめ計画され、あらかじめ構成されている、請求項１記載の方法。
【請求項３】
前記サービスベアラ論理ネットワークは、エッジノードおよびタンデムスイッチングノードを有し、前記エッジノードと前記タンデムスイッチングノードの間には、マルチプロトコルラベルスイッチング（ＭＰＬＳ：Multi-Protocol Label Switching）技術によってラベルスイッチパス（ＬＳＰ：Label Switching Path）接続が確立される、請求項１または請求項２記載の方法。
【請求項４】
前記タンデムスイッチングノードは、ネットワークリソース管理領域から選択されるコアルータの一部である、請求項３記載の方法。
【請求項５】
サービスに対して割り当てられる前記ルートは、マルチレベルラベルスタックによって表され、ステップｃでは、前記サービスベアラ論理ネットワーク内のノードが、前記マルチレベルラベルスタックで構成されたラベルに従ってトラヒックストリームを転送し、サービスに対するＭＰＬＳパケットがタンデムスイッチングノードを通過する度に前記マルチレベルラベルスタックのレベルが１レベルずつ減少する、請求項１記載の方法。
【請求項６】
トラヒックストリームデータパケットの転送中、ちょうど通過したＬＳＰは、トラヒックストリームデータパケットがタンデムスイッチングノードを通過する度に終端し、マルチレベルラベルスタックの前記ＬＳＰを表すラベルは、そのスイッチングノードまたは前記ＬＳＰの最後から２番目のホップルータでポップされ、その後、前記タンデムスイッチングノードは、次のＬＳＰを表す現在最上位のラベルに従って前記パケットを転送する、請求項５記載の方法。
【請求項７】
前記ステップｂは、領域の論理トポロジのリソースが不足しているためにルート選択に失敗したことをベアラネットワークリソースマネージャが検出したとき、加入者からのサービス要求を拒否するようサービス制御レイヤに知らせるステップをさらに有する、請求項１記載の方法。
【請求項８】
前記サービスベアラ論理ネットワークは、各サービスタイプに対して同じトポロジまたは異なるトポロジを持つ、請求項１から請求項７のいずれかに記載の方法。
【請求項９】
前記サービスベアラ論理ネットワークのネットワーク構造は、公衆電話網のネットワーク構造と同じまたは似ている、請求項１から請求項７のいずれかに記載の方法。
【請求項１０】
前記サービスベアラ論理ネットワークは、大都市圏ネットワーク、県バックボーンネットワーク、全国バックボーンネットワーク、または国際バックボーンネットワークである、請求項１記載の方法。
【請求項１１】
前記サービスベアラ論理ネットワークは、対応するベアラネットワークリソースマネージャによってそれぞれ管理される異なるネットワークリソース管理領域に分割される、請求項１記載の方法。
【請求項１２】
前記ネットワークは、ＩＰバックボーンネットワーク、ローカルエリアネットワーク、大都市圏ネットワーク、または相互接続されたネットワークである、請求項１記載の方法。
【請求項１３】
保証ＱｏＳ要件を伴う前記サービスは、音声サービス、映像通信サービス、ストリームメディア映像サービス、その他特殊なＱｏＳ要件を伴うサービスである、請求項１記載の方法。
【請求項１４】
加入者がサービスを中止または終了した後、前記ベアラ制御レイヤが、サービスによって占有されていたリソースを解放し、トラヒックストリームの処理を取り消すよう対応するエッジルータに知らせるステップをさらに有する、請求項１記載の方法。
【請求項１５】
ＩＰネットワークにおいて保証ＱｏＳを提供するためのシステムであって、
エッジルータおよびコアルータを含み、各種ＩＰサービスパケットを運ぶ基本ネットワークレイヤと、
基本ネットワークから計画、構成され、エッジノード、タンデムスイッチングノード、およびこれらの間の接続を含み、保証ＱｏＳ要件を伴うトラヒックストリームを運ぶサービスベアラ論理レイヤと、
リソースマネージャを含み、前記サービスベアラ論理レイヤおよび前記基本ネットワークレイヤのベアラネットワークリソースを管理するベアラ制御レイヤと、
サービスエンティティを含み、サービス要求を処理するサービス制御レイヤと、
を有する。
【請求項１６】
前記サービスベアラ論理レイヤ内のノード間の論理接続は、ＭＰＬＳ技術によって確立されたＬＳＰ接続である、請求項１５記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＩＰネットワーク技術に関し、特に、ＩＰネットワークにおける保証付きサービス品質（ＱｏＳ：Quality of Service）を提供するための方法およびそのシステムに関する。
【背景技術】
【０００２】
現在、電気通信サービスプロバイダのＩＰネットワークが提供できるデータサービスは限られている。ブロードバンドネットワーク加入者の数の増加に伴って、ＩＰネットワークに対するサービス要件もますます高まる一方である。音声およびテレビ会議などのリアルタイム・サービスには、ＱｏＳに関する厳しい要件がある。
【０００３】
図１に示すように、電気通信サービスプロバイダのＩＰネットワーク全体は、アクセス／エッジレイヤおよびコアレイヤで構成されている。ＩＰネットワークの加入者は、ＸＤＳＬ、ＨＦＣ、イーサネット（Ｒ）、専用回線またはＷＬＬなどのさまざまなアクセス手段を通じてエッジルータＥにアクセスすることができる。エッジルータＥは、加入者の管理に責任を負っており、ＩＰパケットの転送およびルーティングに責任を負うコアルータＲＨに接続されている。ＩＰネットワークは、膨大なものになりうる。たとえば、電気通信サービスプロバイダの全国規模のネットワークが、何千というコアルータおよびエッジルータで構成される場合もある。ネットワークルートの管理の利便性および安定性を考慮して、ＩＰネットワークは、図１において点線で示す複数の独立したルート管理領域に分割することができる。ネットワーク全体は、複数のネットワーク領域およびその間を結ぶ接続で構成される。
【０００４】
ネットワークは、市区町村、県、国などの行政区画に基づいて、あるいは他の方法に基づいていくつかの領域に分割することができる。通常、電気通信サービスプロバイダのＩＰネットワークは、行政区画に基づいて分割されており、各領域がＩＰ自律システム（ＡＳ：Autonomous System）になっている場合もある。
【０００５】
設計思想により、一般に従来のＩＰネットワークにおいて保証されたＱｏＳを提供する手立てはない。ネットワークアプリケーションの開発を適応させるため、統合サービス（Ｉｎｔ−Ｓｅｒｖ：Integrated Service）モデルおよび差別化サービス（Ｄｉｆｆ−Ｓｅｒｖ：Differentiated Service）モデルを始めとする、ＩＰ ＱｏＳのためのさまざまな方法が提案されてきた。それらの中で、差別化サービスモデルを使用することで、マルチプロトコルラベルスイッチング（ＭＰＬＳ：Multiprotocol Label Switching）技術と共にＱｏＳのサポートを提供することができる。現在、統合サービスモデルおよび差別化サービスモデルの組み合わせは、統合サービスモデルがアクセスネットワークおよび境界に使用され、差別化サービスモデルがバックボーンネットワークに使用される一般的な方法となっている。ＭＰＬＳ技術は、差別化サービスモデルがバックボーンネットワークに使用される場合に使用することができる。
【０００６】
差別化サービスモデルが使用される場合において、ＱｏＳを保証するために優先順位のみがサービスタイプ（ＴｏＳ：Type of Service）に設定されている場合、高い回線利用率という利点はあるものの、その効果は予測不可能である。そのため、さらに差別化サービスの改善が行われてきた。一部の組織およびベンダでは、バックボーン差別化サービスに独立したベアラ制御レイヤを導入し、一連の特殊な差別化サービスＱｏＳシグナリングメカニズムを確立している。差別化サービスの適用を促すため、ＩＥＴＦ、一部のベンダおよび機関が一体となって、ネットワークリソースおよびトポロジの管理に帯域幅ブローカ（ＢＢ：Bandwidth Broker）を採用するＱｂｏｎｅ試験ネットワーク上のインターネット２（Internet 2）を推進している。また他には、同様のＱｏＳサーバ／リソースマネージャ技術を使用して、リソースおよびトポロジを管理し、各差別化サービス領域のＱｏＳ機能を調整する方法を提案するベンダもある。こうしたすべての方法において、ネットワークリソースおよびトポロジを管理するためのベアラ制御レイヤは、特別に差別化サービス基本ネットワーク向けに確立される。図２に示すように、専門ネットワークリソース管理を備えるこの差別化サービスモードは、独立ベアラ制御レイヤを備える差別化サービスモデルと呼ばれる。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
独立ベアラ制御レイヤを備える差別化サービスモデルにおいて、ネットワークのエッジルータは、グループごとにＤＳフィールドの分類およびマークを行い、ＩＰパケットのＤＳフィールドおよびＭＰＬＳパケットのＥＸＰ情報を使用して、ＩＰグループの優先順位情報を伝達する。ネットワークのコアノードにおいては、ルータが、優先順位情報に基づいて対応するパケットの転送処理を選択する。ＢＢまたはＱｏＳサーバ／リソースマネージャなどのベアラ制御レイヤ内のサーバは、管理ルールおよびネットワークトポロジを構成し、加入者のサービス帯域幅要求にリソースを割り当てる。指定された帯域幅は、サービス品質保証制度（ＳＬＡ：Service Level Agreement）による加入者との調整を通じて共有することができる。各管理領域のベアラネットワーク制御サーバは、サービス帯域幅要求および結果、ベアラネットワークリソースマネージャなどによって割り当てられるパス情報を、シグナリングを通じて相互に転送する。現在、実装、計画、操作および保守を行うことが困難であるといった問題が、Ｑｂｏｎｅの帯域幅ブローカモデルのような独立ベアラ制御レイヤを備える従来の差別化サービスモデルにはある。
【０００８】
インターネット２ＢＢモデルを示す図３に示されているような第１の従来技術の方式において、インターネット２は各差別化サービス管理領域に対して対応するＢＢを定義し、ＢＢは加入者のコンピュータ、サービスサーバＳ、またはネットワークサービススタッフからの帯域幅適用要求を処理する責任を負っている。ＢＢは、現行ネットワークの保持されているリソース状態、構成ポリシー、および加入者と契約したサービスのＳＬＡに従って、帯域幅適用を許可するかどうかを判断する。
【０００９】
図４に示すように、帯域幅マネージャは、各種のＳＬＡ構成情報、物理ネットワークのトポロジ情報、ルータの構成情報およびポリシー情報、ユーザ認証情報、現在保持されているリソースに関する情報、およびネットワークの占有状態など、大量の静的情報および動的情報を記録する。同時に、帯域幅マネージャは、トラヒックストリームのルートおよび交差領域のダウンストリーム帯域幅の位置を判断するため、ルート情報も記録する。
【００１０】
インターネット２の帯域幅マネージャモデルにおいては、帯域幅マネージャが領域内のすべてのルータのリソース情報および構成情報を直接管理するので、トポロジおよび管理が非常に複雑になるという問題がある。同時に、帯域幅マネージャには領域の動的なルート情報を記録する必要があるので、ルートテーブルが頻繁に更新されるという問題があり、その結果ネットワーク維持が不安定になる。さらに、領域の動的ルート情報によって決定されたサービスルートが、トラヒックストリームの実際の転送ルートと一致することは困難である。
【００１１】
帯域幅マネージャモデルにはあまりに多くの問題があるため、今までのところこのモデルはビジネス用途には使用されたことがない。
【００１２】
図５に示すように、日本のＮＥＣによって提案されたリッチ（Rich）ＱｏＳの解決策である第２の従来技術の方式において、ＱｏＳサーバ（ＱＳ）は重要な要素と見なされている。さらにポリシーサーバ（ＣＳ）、ディレクトリサーバ（ＤＳ）およびネットワーク管理モニタリングサーバも、この解決策に含まれている。ポリシーサーバは、ＱｏＳサーバおよび管理インタフェースに関する情報などのポリシー構成情報に従って関連するルータのパラメータ設定および構成を実施する。ディレクトリサーバは、ネットワークデバイス構成情報、ユーザ情報およびＱｏＳ情報を保存するための集中データベースである。ネットワーク管理モニタリングサーバは、ルータおよびリンクのブロック状態などの情報を収集する責任を負っているが、この情報はＱｏＳサーバがサービス適用のルートを選択する際の参照となる。
【００１３】
ＱｏＳサーバは、ベアラネットワークのネットワークトポロジおよびリソース状態に基づいてＱｏＳ要件を満たすベアラルートを割り当てる責任を負っている。ＱｏＳサーバのトポロジおよび帯域幅条件を事前に設定し、ルート選択のルールを事前に構成しておく必要がある。サービスサーバが帯域幅要求をＱｏＳサーバに送信すると、ＱｏＳサーバはこのコールのリソース要求を記録して、ＱｏＳ要件、現在のトポロジおよびこのサービス要求に対するベアラネットワークのリソース条件に従って要件を満足するベアラルートを割り当てる。
【００１４】
ＱｏＳサーバは、サービスの帯域幅占有条件に従って対応するＬＳＰポリシー修正コマンドをポリシーサーバに送信する。次に、ポリシーサーバは、ＱｏＳサーバからのコマンドに従って対応するエッジルータを構成する。
【００１５】
エッジルータは、ＭＰＬＳ ＬＳＰ表示ルート技術を使用し、ＱｏＳサーバによって決定されるパスに従ってＬＳＰを再作成または調整する。
【００１６】
ＮＥＣによって提案されたリッチＱｏＳ方式において、ＱｏＳサーバが管理するのはやはり複雑なベアラネットワークであり、膨大な数のルータがある。ＱｏＳサーバおよびポリシーサーバは、ＭＰＬＳ ＬＳＰ表示ルート技術を使用して、エッジルータに情報を伝達する。エンドツーエンドＬＳＰを確立するモードには、拡張性に乏しくネットワーク規模が制限されているという欠点がある。このため、この方式は、全国規模の公衆ネットワークにおけるエンドツーエンドのサービス要件を満たすことができない。
【００１７】
帯域幅マネージャが領域内のすべてのルータのリソース情報および構成情報を直接管理するので、トポロジおよび管理が非常に複雑になるという問題がある。ＮＥＣなど他のベンダによって提案されている解決策において、ＱｏＳサーバは依然として複雑なベアラネットワークを管理する。ベアラネットワークに使用される表示ルート技術によりエンドツーエンドＬＳＰを確立するモードには、拡張性に乏しくネットワーク規模が制限されているという欠点があり、これは全国規模の公衆ネットワークにおけるエンドツーエンドのサービス要件を満たすことができない。したがって、電気通信サービスプロバイダの大規模なＩＰバックボーンネットワークにおいて、ＶｏＩＰまたはテレビ電話など、加入者のサービス要求に対して、送信元エッジルータから宛先エッジルータに保証付きＱｏＳを提供する方法は、緊急の解決を必要とする問題である。
【００１８】
本発明の目的は、公衆ネットワークにおけるエンドツーエンドのサービスのＱｏＳ要件を満たすことができるように、ＩＰネットワークにおいて保証ＱｏＳを提供するための方法を提供することである。
【００１９】
本発明のもう１つの目的は、ＩＰネットワークにおいて保証ＱｏＳを提供するためのシステムを提供することである。
【課題を解決するための手段】
【００２０】
本発明の目的を達成するため、第１に、ＭＰＬＳ技術のＬＳＰを用いて、特定サービスに対してＩＰ物理ネットワークにおいて対応するサービスベアラ論理ネットワークを分離して、特定サービスと従来のインターネットサービスを分ける。第２に、ベアラ制御レイヤおよびベアラネットワークリソースマネージャの概念を導入する。ベアラ制御レイヤは、ベアラネットワークリソースマネージャで構成され、加入者サービスに対するリソース計算およびルート選択を担っている。サービスパスおよびＱｏＳパラメータを決定した後、ベアラネットワークリソースマネージャは、トラヒックストリームのパスプロパティおよびＱｏＳプロパティを指定するようＩＰネットワークエッジデバイスに知らせる。最後に、ＭＰＬＳ技術のマルチレベルラベルスタックを用いて、ＩＰネットワークデバイスが、ベアラネットワークリソースマネージャによって指定されたパスに従ってＩＰネットワーク内のトラヒックストリームＩＰパケットを転送する。
【００２１】
本発明に係る方法は、次のステップ、つまり、
ａ）ＩＰネットワーク内の関連サービスエンティティが、加入者から保証ＱｏＳ要件を伴うサービス要求を受信した後、前記サービス要求を分析することによって送信元加入者および宛先加入者のアドレスならびにサービスのＱｏＳパラメータを取得し、ルート選択およびリソース適用要求を前記ネットワークのベアラ制御レイヤに送信するステップと、
ｂ）ベアラ制御レイヤ内のベアラネットワークリソースマネージャが、送信元加入者および宛先加入者の前記アドレスならびにサービスタイプに従って、サービスベアラ論理ネットワーク内のサービスに対するルートおよびリソースを割り当てるステップと、
ｃ）前記ベアラ制御レイヤによって決定されたルートおよびリソースに従って、前記サービスベアラ論理ネットワーク内のトラヒックストリームを転送するステップと、
を有する。
【００２２】
上記の方法において、前記サービスベアラ論理ネットワークは、エッジノードおよびタンデムスイッチングノードを有し、前記エッジノードと前記タンデムスイッチングノードの間には、マルチプロトコルラベルスイッチング（ＭＰＬＳ：Multi-Protocol Label Switching）技術によってラベルスイッチパス（ＬＳＰ：Label Switching Path）接続が確立される。前記サービスベアラ論理ネットワークは、前記サービスタイプに従って基本ネットワークからあらかじめ計画されあらかじめ構成されている。
【００２３】
上記の方法において、サービスに対して割り当てられる前記ルートは、マルチレベルラベルスタックによって表され、ステップｃでは、前記サービスベアラ論理ネットワーク内のノードが、前記マルチレベルラベルスタックで構成されたラベルに従ってトラヒックストリームを転送し、サービスに対するＭＰＬＳパケットがタンデムスイッチングノードを通過する度に前記マルチレベルラベルスタックのレベルが１レベルずつ減少する。
【００２４】
トラヒックストリームデータパケットの転送中、ちょうど通過したＬＳＰは、トラヒックストリームデータパケットがタンデムスイッチングノードを通過する度に終端し、マルチレベルラベルスタックの前記ＬＳＰを表すラベルは、そのスイッチングノードまたは前記ＬＳＰの最後から２番目のホップルータでポップされ、その後、前記タンデムスイッチングノードは、次のＬＳＰを表す現在最上位のラベルに従って前記パケットを転送する。
【００２５】
前記ステップｂは、領域の論理トポロジのリソースが不足しているためにルート選択に失敗したことをベアラネットワークリソースマネージャが検出したとき、加入者からのサービス要求を拒否するようサービス制御レイヤに知らせるステップをさらに有することができる。
【００２６】
本発明に係るシステムは、エッジルータおよびコアルータを含み、各種ＩＰサービスパケットを運ぶ基本ネットワークレイヤと、基本ネットワークから計画、構成され、エッジノード、タンデムスイッチングノード、およびこれらの間の接続を含み、保証ＱｏＳ要件を伴うトラヒックストリームを運ぶサービスベアラ論理レイヤと、リソースマネージャを含み、前記サービスベアラ論理レイヤおよび前記基本ネットワークレイヤのベアラネットワークリソースを管理するベアラ制御レイヤと、サービスエンティティを含み、サービス要求を処理するサービス制御レイヤと、を有する。
【００２７】
従来のモデルと比較すると、本発明では、あらかじめＭＰＬＳ技術によりＩＰ物理ベアラネットワークにおいてサービスベアラ論理ネットワークを計画し構成するため、ＱｏＳ要件を伴うサービスと従来のインターネットサービスを個別に管理することができ、これによって、ベアラ制御レイヤにおいてリソース管理およびルート選択を実現するための基盤が提供される。同時に、ルート選択およびリソース割り当ての機能が従来のＩＰ基本ネットワークのルーティングプロトコルおよびリソース割り当てメカニズムから独立しており、特別のベアラ制御レイヤを用いて加入者に対するルート選択およびリソース管理を処理する。さらに、十分なリソースがない場合、要求を拒否することができる。ベアラネットワークで用いるＭＰＬＳのマルチレベルラベルスタック技術によって、加入者のトラヒックストリームを、ＩＰ物理ネットワーク内のベアラ制御レイヤによって指定されたパスに従って転送する。従って、本発明によれば、公衆ネットワークにおけるエンドツーエンドのサービスのＱｏＳ要件を十分に満たすことができる。
【００２８】
また、新たに導入したベアラネットワーク制御レイヤによって、ネットワークルーティングプロトコルの再構築を招くことはない。また、ＭＰＬＳ技術のマルチレベルラベルスタックを用いてベアラネットワークによって指定されたルートに従ってトラヒックストリームを転送するためのコアルータを修正する必要はない。従って、本発明は、従来のネットワークに対してほとんど影響を与えない。
【発明を実施するための最良の形態】
【００２９】
図１２を参照すると、本発明に係る方法は次のステップを有する。
【００３０】
ステップＡでは、加入者は保証ＱｏＳ要求を伴うサービス要求を開始し、ネットワークの関連サービスエンティティが、サービス要求を分析することによってこのサービス要求の送信元加入者および宛先加入者のアドレスならびに関連するＱｏＳパラメータを取得し、その後、ルート選択およびリソース適用要求をネットワークのベアラ制御レイヤに送信する。
【００３１】
ステップＢでは、ベアラ制御レイヤ内のベアラネットワークリソースマネージャが、送信元加入者および宛先加入者のアドレスならびにサービスタイプに従って、サービスベアラ論理ネットワーク内の当該サービスのルートおよびリソースを割り当てる。
【００３２】
ルートの割り当てはマルチレベルラベルスタックを使用し、ベアラ制御レイヤはベアラ論理ネットワークのエッジノードにマルチレベルラベルスタックを知らせる。
【００３３】
領域の論理トポロジのリソースが不足しているためにルート選択に失敗した場合、ベアラネットワークリソースマネージャは、サービス要求を拒否するようにサービス制御レイヤに指示する。
【００３４】
ステップＣでは、サービスベアラ論理ネットワークにおいて、ベアラ論理レイヤによって割り当てられたルートに従って、トラヒックストリームを転送する。
【００３５】
サービスベアラ論理ネットワークにおいて、トラヒックストリーム送信元終端のエッジノードは、各送信済みトラヒックストリームデータパケットでルートのマルチレベルラベルスタックをカプセル化する。サービスベアラ論理ネットワーク内のノードは、マルチレベルラベルスタックに従ってトラヒックストリームを転送する。トラヒックストリームデータパケットがスイッチングノードを通過すると、マルチレベルラベルスタックのレイヤが１つ減らされる。
【００３６】
以下、本発明について、添付の図面およびＩＰバックボーンネットワークの例を参照してより詳細に説明する。
【００３７】
本発明に係るネットワークの全体構造を示す図６に示すように、ネットワークは、サービス機能モデルに関して、基本ネットワークレイヤおよびサービスベアラ論理ネットワークを含むベアラネットワークと、ベアラ制御レイヤと、サービス制御レイヤとを有する。
【００３８】
物理ネットワークエンティティはエッジルータＥおよびコアルータＲＨを有するため、ベアラネットワークの基本ネットワークレイヤを用いてさまざまなＩＰパケットが運ばれる。ベアラネットワークのサービスベアラ論理ネットワークは、ＭＰＬＳ技術を使用する基本ネットワークレイヤに基づいてあるサービスのタイプに対してあらかじめ計画された論理ネットワークである。
【００３９】
ベアラ制御レイヤは、ベアラ論理ネットワークおよび基本ネットワークレイヤのベアラネットワークリソースを管理する責任を負っている。ベアラ制御レイヤは、加入者のサービス要求に対してサービスベアラ論理ネットワーク上のＱｏＳ要件を満たすベアラパスを選択する。
【００４０】
サービス制御レイヤは、ＶｏＩＰ／テレビ電話の呼び出し信号を処理するためのソフトスイッチ（SoftSwitch）や、加入者のＶｏＤ要求を処理するためのＶｏＤサービスのＷｅｂサーバなど、サービス要求を処理するためのいくつかのサーバから成っている。
【００４１】
ネットワークの管理の利便性および安定性を考慮して、ＩＰ基本ネットワークはすべて、点線で囲まれた領域のようにさまざまなネットワークリソース管理領域に分割されている。ネットワークリソース管理領域の分割は、ルーティング領域の分割に対応させることができる。各管理領域は、加入者サービスに対してネットワークリソース計算およびルート選択の責任を負うベアラネットワークリソースマネージャ（ＣＭ）によって管理される。さまざまな領域のＣＭは、論理によってベアラルート選択ネットワークを構成している。ＱｏＳ要件を満たすベアラネットワークルートは、相互間のシグナリングを通じて複数の管理領域に及ぶサービス要求に対して選択することができる。
【００４２】
基本ネットワークレイヤは、各種ＩＰサービスの最終ベアラデバイスレイヤである。保証ＱｏＳを伴わないインターネットサービスおよび保証ＱｏＳを伴うＩＰサービスは、いずれも、基本ネットワークレイヤによって運ばれる。ＱｏＳを伴うトラヒックストリームをＩＰ基本ネットワークによって確実に運ぶためには、インターネットサービスのトラヒックストリームと保証ＱｏＳのトラヒックストリームを分けて異なるパスで転送する必要がある。
【００４３】
端局、中継局、県の集中局、国際集中局、および局間の中継線を含むＰＳＴＮのネットワーク構造を参照すると、サービスベアラ論理ネットワークは、ＩＰ基本ネットワークを基礎とするＩＰサービスの一種としてとらえることができる。サービスベアラ論理レイヤは、エッジノード、タンデムスイッチングノード、およびノード間の論理接続を含んでいる。エッジルータＥは、サービスベアラネットワークのエッジノードである。各ＩＰネットワークリソース管理領域内の一部のコアルータＲＨは、タンデムスイッチングノードＲとして選択することができる。ノードは、ＭＰＬＳ技術によりあらかじめ確立されたＬＳＰを通じて接続される。たとえば、ＬＳＰは、ＲＳＶＰ−ＴＥまたはＣＲ−ＬＳＰ、およびＭＰＬＳトラヒックエンジニアリング技術などのシグナリングを用いて静的に構成することができ、ＬＳＰ設計に対して帯域幅および他のＱｏＳ特性は保存される。エッジノード、タンデムスイッチングノード、およびＬＳＰ接続は、図７に示すようにトラヒックストリームの論理ベアラネットワークを形成する。
【００４４】
また、ＭＰＬＳ論理ベアラネットワークは、階層化ＬＳＰ技術を使用することもできる、つまり、エッジノード／タンデムスイッチングノード間のＬＳＰ接続が、ルータの一部の物理リンクに加えて、一部の下位レイヤＬＳＰを通過することができる。しかし、これらの下位レイヤＬＳＰは、ベアラネットワーク上でトンネルインタフェースとして処理され、サービス論理ベアラネットワークに現れることはない。ベアラ制御レイヤは、エッジノード／タンデムスイッチングノード間のＬＳＰ接続を処理する必要があるだけであり、下位レイヤＬＳＰを処理する必要はない。
【００４５】
加入者から保証ＱｏＳを伴うサービス要求を受け取ると、トラヒックストリームはエッジノード（エッジルータ）に入り、エッジノードはトラヒックストリームを論理ベアラネットワークに入れる。トラヒックストリームは、開始のエッジノードから始まって、いくつかのタンデムスイッチングノードを通過した後、終端のエッジノードに到達する。トラヒックストリームは、論理ベアラネットワーク内でＬＳＰを通じて一意的に決定することができるため、トラヒックストリームはベアラ制御レイヤによって定義されたパスに沿って転送される。このようにして、制御可能なトラヒックストリームルートの転送が実現され、トラヒックストリームがインターネットサービスと一緒に転送される状態を防止することができるため、トラヒックストリームのＱｏＳを保証し、ＩＰネットワークにおけるサービス提供レベルをＰＳＴＮにおけるサービス提供レベルに到達させることができる。
【００４６】
基本ネットワークレイヤ上でサービスベアラ論理ネットワークを計画する方法として複数の方法がある。電気通信サービスプロバイダは、大都市圏ドメインネットワーク、県のバックボーンネットワーク、および全国バックボーンネットワーク、さらには国際バックボーンネットワークさえも、それぞれＰＳＴＮ公衆電話回線網の計画整備を参照して設計することができる。
【００４７】
独立した論理ベアラネットワークは、ＶｏＩＰやテレビ電話、ＶｏＤなど、異なるサービスごとにそれぞれ計画し構成することができる。もちろん、各サービスの論理ベアラネットワークのトポロジ構造は、具体的な実装プロセスの実際条件、タンデムスイッチングノードの選択、ならびに各サービスの変換モデルおよび負荷予測に応じて、同じであっても異なっていてもよい。
【００４８】
保証ＱｏＳを伴う各サービスの基本ネットワークレイヤによって保存され設定された論理ベアラネットワークのネットワークトポロジ構造は、ベアラ制御レイヤのＣＭに記録され、ノード間の各ＬＳＰの状態もＣＭに報告される。各領域のＣＭは、管理領域内における複数のサービスの論理ベアラネットワークを管理する。
【００４９】
ベアラ制御レイヤは、ベアラ論理ネットワーク内のサービス要求に対してリソース計算およびルート選択を行う。ベアラ制御レイヤは、すべての領域のＣＭを含んでおり、各ＣＭは１つの領域内のサービスベアラ論理ネットワークのリソースおよびルート選択を管理する。領域にまたがるサービス適用に対するリソース制御およびルート選択は、領域間のシグナリングを通じて複数のＣＭによって達成することができる。
【００５０】
それぞれの会話ごとに、加入者は、サービスシグナリングを通じてＶｏＩＰコールまたはテレビ電話コールなどのサービス要求を送信する必要がある。申請を受信した後、対応するサービス処理サーバは、そのサービスに対する加入者の権利ならびにコール元およびコール先の加入者のアドレスを判定し、この会話に必要な帯域幅などのＱｏＳパラメータを決定する。次に、ベアラ制御レイヤに対応するリソースおよびサービスベアラパスを申請する。インタフェースは、具体的な実施方法に応じて、内部インタフェースでもオープンインタフェースでもよい。サービス制御レイヤサーバがＣＭに統合されている条件下では、内部インタフェースになる。他の条件では、シップ（ＳＩＰ：Session Initiation Protocol）などのシグナリングを、サービス制御レイヤおよびベアラ制御レイヤ間のインタフェースとして使用することができる。
【００５１】
サービス制御レイヤからルート選択およびリソース適用の要求を受信すると、ベアラ制御レイヤのＣＭは、送信元アドレスおよび宛先アドレスに従ってサービスベアラ論理ネットワーク内のこの要求に対するルートを選択する。領域の論理ネットワークトポロジに十分なリソースがない場合、ＣＭは、加入者の要求を拒否するようサービス制御レイヤに知らせる。ルート選択に成功した場合、ＣＭは、ＩＰトラヒックストリームに対応する適切なＱｏＳパラメータおよびサービスパスパラメータを設定するよう対応するエッジルータに知らせる。加入者が会話を終了すると、ベアラ制御レイヤは、加入者によって占有されていたリソースを解放し、対応するエッジルータにＩＰトラヒックストリーム処理を開始するよう知らせる。
【００５２】
複数のリソース管理領域にわたる会話が処理される場合、ベアラ制御レイヤのＣＭは、この領域のルート選択を行うだけではなく、近隣領域のＣＭを選択しこれに宛先加入者のアドレスまたは番号に従ってパス要求を送信する。これはＰＳＴＮにおけるアウティングルート（outing route）の機能に類似している。
【００５３】
ＣＭ間の要求情報は、宛先加入者情報に加えて、通過領域に関するパス情報、つまり、どのＬＳＰを通過したかに関する情報も含んでいる。アップストリームＣＭからの要求を受信すると、現在のＣＭは、宛先ドメインに向かうルートを探す。その領域自体が宛先領域である場合、ＣＭは、入口ＬＳＰ情報およびＱｏＳ要件に基づいて領域内のパスを選択し、選択したパスをアップストリームＣＭに知らせる。その領域が宛先領域でない場合、ＣＭは、電話番号またはＩＰアドレスなどの宛先加入者情報に従ってダウンストリームＣＭを定義し、入口ＬＳＰ情報およびＱｏＳ要件に従って領域内のパスを選択してから、要求メッセージをダウンストリームＣＭに送信する。要求情報は宛先加入者情報を含み、領域内のパス情報を、サービスパス情報、つまり、どのＬＳＰを通過したかに関する情報に追加することができる。
【００５４】
領域に十分なベアラネットワークリソースがない場合、ＣＭは、サービス適用を拒否し、アップストリームＣＭに失敗情報を送信する。パスに沿うＣＭは対応するリソースを解放し、失敗情報をアップストリームＣＭに送信する。開始の終端ＣＭは、失敗情報を受信すると要求がポップすることをサービス制御レイヤに知らせる。
【００５５】
加入者がサービスを終了すると、サービス制御レイヤは対応するＣＭにリソース解放コマンドを送信する。このサービスのパスに沿うＣＭは、以前そのサービスに割り当てられていたリリースを解放する。
【００５６】
図８に示すように、加入者サービス適用のためのベアラ制御レイヤにおける可能な実装プロセスについて、加入者Ｓ１が加入者Ｓ２との通信を要求する場合を例にとって説明する。ここで、加入者Ｓ１は領域Ａに属するエッジルータＥ１に接続され、加入者Ｓ２は領域Ｄに属するエッジルータＥ２に接続され、ＣＭ−Ａ、ＣＭ−Ｂ、ＣＭ−Ｃ、およびＣＭ−Ｄは領域Ａ、領域Ｂ、領域Ｃ、および領域Ｄをそれぞれ管理する。
【００５７】
（１）加入者コール要求を分析することにより、コール元およびコール先加入者のアドレスを取得した後、サービス制御レイヤサーバは、要求を加入者Ｓ１の領域のＣＭ−Ａに送信して、加入者Ｓ１および加入者Ｓ２間のトラヒックストリームパスを作成するよう申請する。
【００５８】
（２）要求を受信すると、ＣＭ−Ａは、Ｓ２のアドレスまたは電話番号に従ってＣＭ−ＣをダウンストリームＣＭとして選択し、領域Ａの現在のリソース状態に従ってパス「ＬＳＰａ１／ＬＳＰａｃ」をノードＥ１から領域Ｃへのパスとして選択し、その後、ＣＭ−Ａに記録されている論理ベアラネットワークのリソース状態を更新する。
【００５９】
（３）ＣＭ−Ａは、要求情報をダウンストリームＣＭ−Ｃに送信する。要求情報は、加入者Ｓ１および加入者Ｓ２のアドレスまたは番号などのコール情報、ならびに必要なＱｏＳパラメータを含み、また、領域Ａにおける「ＬＳＰａ１／ＬＳＰａｃ」のパス情報を含むこともある。
【００６０】
（４）ＣＭ−Ａからリソース要求情報を受信すると、ＣＭ−Ｃは、その入口パスＬＳＰａｃを取得し、宛先加入者Ｓ２に関する情報に従ってベアラルート情報を検索することにより、ダウンストリームＣＭがＣＭ−Ｄであることを検出する。そして、ＣＭ−Ｃは、入口パスＬＳＰａｃ、ダウンストリーム領域Ｄ、サービス適用のＱｏＳ要件、および領域Ｃのリソース状態に従って、ＬＳＰｃｄを領域Ｃの出口パスとして選択する。
【００６１】
（５）領域Ｃのパス情報を受信した要求情報に追加した後、ＣＭ−Ｃは、要求情報をダウンストリームＣＭ−Ｄに再度送信する。要求情報は、加入者Ｓ１および加入者Ｓ２に関するコール情報、必要なＱｏＳパラメータ、およびコール申請が通過する「ＬＳＰａ１／ＬＳＰａｃ／ＬＳＰｃｄ」のパス情報を含んでいる。
【００６２】
（６）ＣＭ−Ｃから要求情報を受信すると、ＣＭ−Ｄは、領域ＤのＬＳＰｃｄの入口パスを取得し、宛先加入者Ｓ２に関する情報に従ってベアラルート情報を検索することにより、領域ＤのエッジノードＥ２を検出する。そして、ＣＭ−Ｄは、入口パスＬＳＰｃｄ、宛先ノードＥ２、サービス適用のＱｏＳパラメータ、および領域Ｄのリソース状態に従って、ＬＳＰｄ１をノードＥ２へのパスとして選択する。
【００６３】
（７）ＣＭ−Ｄは、リソースが正常に予約されたことを示す情報をアップストリームＣＭに送信する。この情報は、加入者Ｓ１および加入者Ｓ２に関するコール情報、およびコール申請のパス全体「ＬＳＰａ１／ＬＳＰａｃ／ＬＳＰｃｄ／ＬＳＰｄ１」を含んでいる。
【００６４】
処理が完了すると、ベアラネットワーク内のトラヒックストリームのパスはすべて、パスに沿うすべてのＣＭに知られる。
【００６５】
領域にまたがるサービスに対する上記実施プロセスに加えて、さらにいくつかの実施プロセスがある。加入者サービス適用は、単方向トラヒックストリームあるいは双方向トラヒックストリームのいずれにもなりうる。双方向トラヒックストリームの場合は、２方向のパスは同じパスを割り当てられるか、またはそれぞれ別のパスを割り当てられることがある。どちらの実施プロセスが採用されるかにかかわりなく、ベアラ制御レイヤは、各サービス適用に対してサービスベアラ論理ネットワークのパスを全部決定する。
【００６６】
図９に示すように、ベアラパスが決定された後、ＣＭは、加入者が位置している領域内のエッジルータに、帯域幅およびトラヒックストリームの優先度などのＱｏＳパラメータを設定してトラヒックストリームのベアラパスを設定するよう知らせ、トラヒックストリームがサービスによって決定されたＱｏＳパラメータに従って確実に処理されるように、またトラヒックストリームがＣＭによって決定されたパスに沿って確実に転送されるようにする。加入者サービスの適用が成功すると、ＣＭの制御の下で、エッジルータは、トラヒックストリーム分類表の対応する項目を作成し、トラヒックストリームに必要な帯域幅および優先度などのＱｏＳパラメータ、ならびにトラヒックストリームのベアラネットワーク内の転送パスパラメータを記録する。エッジルータは、決定されたＱｏＳパラメータおよび転送要件に従って、トラヒックストリームに属するＩＰパケットを処理する。加入者がサービスを終了すると、エッジルータは、ＣＭの制御の下でトラヒックストリーム分類表の対応する項目を削除する。
【００６７】
ＭＰＬＳ技術の表示ルートおよびマルチレベルラベルスタックの方法を使用して、基本ネットワークで決定されたベアラパスに従って、転送トラヒックストリームを実現することができる。マルチレベルラベルスタックの方法は、本実施例で使用される。
【００６８】
加入者サービス適用に対してベアラパスを選択すると、ベアラ制御レイヤは、ベアラネットワークのエッジルータに対してあるトラヒックストリームの転送パスを知らせ、ＭＰＬＳ技術のマルチレベルラベルスタックの方法により、ベアラ制御レイヤによって決定されたパスに従ってトラヒックストリームを転送する。エッジルータは、ベアラ制御レイヤからのコマンドに従って、マルチレベルラベルスタックによりトラヒックストリームのＩＰパケットをカプセル化し、タンデムルータはあらかじめ設定されたラベルのみを転送する。スイッチングルータは、ＬＳＰ開始点および終端点のルータであり、２レベルのラベルスタックの処理能力を備えていることが好ましい。
【００６９】
マルチレベルラベルスタックを使用する転送手順を示す図１０に示すように、２つのエッジルータＥ１とＥ２の間にはいくつかのコアルータがある。加入者サービスは、エッジルータＥ１からエッジルータＥ２へのトラヒックストリームである。ベアラ制御レイヤによってトラヒックストリームに割り当てられているベアラパスは、エッジルータＥ１−ＬＳＰａ→スイッチングルータＲＡ−ＬＳＰｂ→スイッチングルータＲＢ−ＬＳＰｃ→スイッチングルータＲＣ−ＬＳＰｄ→エッジルータＥ２となる。
【００７０】
パス内の各ノードに対応するラベルがグローバルラベルの場合、例えば、ＬＳＰａのＥ１のグローバルラベルがＬａ、ＬＳＰｂのＲＡのグローバルラベルがＬｂ、ＬＳＰｃのＲＢのグローバルラベルがＬｃ、ＬＳＰｄのＲＣのグローバルラベルがＬｄの場合、パスＬＳＰａ→ＬＳＰｂ→ＬＳＰｃ→ＬＳＰｄのラベルスタックは、Ｌａ／Ｌｂ／Ｌｃ／Ｌｄとなる。ここで、Ｌａはラベルスタックの最上位にある。
【００７１】
図１１に示すように、最後から２番目のホップでのポッピング機能がパスに沿うルータにおいて構成されていない場合、トラヒックストリームに対するベアラネットワーク内のＭＰＬＳの転送は、次のようになる。
【００７２】
まず、トラヒックストリームパケットがエッジルータＥ１に到達すると、Ｅ１は、ベアラ制御レイヤからのコマンドに従ってラベルスタックＬａ／Ｌｂ／Ｌｃ／Ｌｄでパケットをカプセル化する。ここで、Ｌａはラベルスタックの最上位にある。次に、Ｅ１はＬＳＰａに沿ってＭＰＬＳパケットを送信する。ＭＰＬＳパケットはＬＳＰａを経由して転送される場合、いくつかのルータを通過するが、これらのルータはすべてラベルスタックの最上位のラベルにのみ従ってＭＰＬＳパケットを転送し、おそらく最上位のラベルを置き換える。
【００７３】
ＭＰＬＳパケットがＬＳＰａに沿ってスイッチングルータＲＡに到達すると、ＬＳＰａはＲＡで終端しているため、ＲＡは最上位のラベルをポップして２番目のラベルＬｂに従ってＭＰＬＳパケットを転送する。従って、ＭＰＬＳパケットは、ラベルスタックを１レベルだけ減らされて、ＬＳＰｂに沿って転送される。
【００７４】
同様に、次いでＭＰＬＳパケットがＬＳＰｂに沿って転送される。ＭＰＬＳパケットがいくつかのルータを通過すると、これらのルータはラベルスタックの最上位のラベルにのみ従ってＭＰＬＳパケットを転送し、おそらく最上位のラベルを置き換える。ＲＢがＭＰＬＳパケットを受信した後、ＬＳＰｂはＲＢで終端しているため、ＲＢはラベルスタックの最上位のラベルをポップして次のラベルＬｃに従ってＭＰＬＳパケットを転送する。従って、ＭＰＬＳパケットは、ラベルスタックを１レベルだけ減らされて、ＬＳＰｃに沿って転送される。
【００７５】
ＭＰＬＳパケットがルータＲＣに到達すると、ＬＳＰｃはＲＣで終端しているため、ＲＣは最上位のラベルをポップして２番目のラベルＬｄに従ってＭＰＬＳパケットを転送する。従って、ＭＰＬＳパケットは、最後のラベルの残ったラベルスタックと共に、スイッチングルータＲＣでＬＳＰｄに沿って転送される。
【００７６】
パケットはＬＳＰｄに沿って転送されている間、おそらくいくつかのルータを通過し、これらのルータがラベルを置き換えることができる。このようにして、ＭＰＬＳパケットはＬＳＰｄを経由してその宛先エッジルータＥ２に到達する。Ｅ２がＭＰＬＳパケットを受信したとき、ＬＳＰｄはエッジルータＥ２で終端しているため、ラベルはポップされて、トラヒックストリームのＩＰパケットが回復される。
【００７７】
上記の説明では、転送トラヒックストリームにグローバルラベルが使用される場合を例として取り上げている。実際には、ＭＰＬＳによる同様の基本的転送方法の原理に基づいて、ＭＰＬＳ技術のマルチレベルラベルスタック方法は、転送トラヒックストリームにローカルラベルが使用される状況において採用することができ、最後から２番目のホップでのポッピング機能も構成される状況において採用することができる。具体的な転送プロセスについては、本明細書では省略する。
【００７８】
以上の説明は、本発明の好ましい実施の形態に過ぎず、本発明の保護の範囲を限定するものと解釈されるべきではない。
【産業上の利用可能性】
【００７９】
本発明は、電気通信サービスプロバイダのネットワーク全体で使用することも、あるいは各地域ネットワークでそれぞれ使用することも可能である。複数のサービスプロバイダのネットワークに及ぶサービスの場合には、本発明をネットワークごとに別個に使用することができる。
【図面の簡単な説明】
【００８０】
【図１】ＩＰネットワークのネットワークアーキテクチャを示す概略図
【図２】独立ベアラ制御レイヤのネットワークモデルを示す概略図
【図３】インターネット２の帯域幅ブローカのモデルを示す概略図
【図４】帯域幅ブローカの内部機能原理を示す図
【図５】日本のＮＥＣによって提案されているリッチＱｏＳの解決策を示す図
【図６】本発明の全モデルを示す概略図
【図７】ＭＰＬＳ技術のＬＳＰにより確立されるサービスベアラ論理ネットワークを示す図
【図８】ベアラ制御レイヤのルート選択手順を示す概略図
【図９】エッジルータの機能を示すブロック図
【図１０】サービスパスを示す概略図
【図１１】マルチレベルラベルスタックによる転送手順を示す概略図
【図１２】本発明を示すフローチャート
【図１】
2004254328.tif 000003
【図２】
2004254328.tif 000004
【図３】
2004254328.tif 000005
【図４】
2004254328.tif 000006
【図５】
2004254328.tif 000007
【図６】
2004254328.tif 000008
【図７】
2004254328.tif 000009
【図８】
2004254328.tif 000010
【図９】
2004254328.tif 000011
【図１０】
2004254328.tif 000012
【図１１】
2004254328.tif 000013
【図１２】
2004254328.tif 000014