JP2006211263A

JP2006211263A - 自律分散的にリソース管理と運用を行うネットワークを構成する通信装置、通信装置の制御方法、およびプログラム

Info

Publication number: JP2006211263A
Application number: JP2005020152A
Authority: JP
Inventors: Kensuke Niitome; 憲介新留; Yukinori Kishimoto; 幸典岸本; Shinichi Kato; 愼一加藤; Hiroshi Koyano; 浩小谷野
Original assignee: NTT Communications Corp
Current assignee: NTT Communications Corp
Priority date: 2005-01-27
Filing date: 2005-01-27
Publication date: 2006-08-10

Abstract

【課題】自立分散ネットワークの管理・運用では、将来使う予定のリソースを避けてリソースを割り付けることはできない。また、将来の廃止予定を考慮してパス計算を行うこともできない。
【解決手段】本発明では、各通信装置が保有する当該通信装置のリソース（帯域、波長など）管理項目に時系列情報を含め、通信装置間の情報共有化の過程で授受される情報に前記時系列情報を含め、各通信装置が把握するネットワークのトポロジにも前記時系列情報を含める。各通信装置は通信路を開通する時刻を考慮して通信路の設計を行い、他の通信装置に時系列情報を含めた通信路確保や通信路設定の依頼を行う。
【選択図】図７

Description

本発明は、自律分散的にリソース管理と運用を行うネットワークを構成する通信装置とその制御方法に関する。

一般的に通信のオペレーションを考える上では、サービスの開始、廃止、付加サービスの有無などの管理・運用を行うサービス系のオペレーションシステム（サービス系ＯｐＳ）、ネットワークの構成要素である設備（ネットワークの構成要素として設備を考えるときには、ネットワークエレメントと言う。）の管理・運用を行うネットワークエレメント系のオペレーションシステム（ＮＥ系ＯｐＳ）、サービス系ＯｐＳとＮＥ系ＯｐＳの連携を図り、ネットワーク全体の管理・運用を行うネットワーク系のオペレーションシステム（ＮＷ系ＯｐＳ）に分類される。

図１に従来の電話系のサービスと設備（ネットワークエレメントまたはネットワークリソース：設備を、サービスを提供するためのリソースと捕らえるときには、ネットワークリソースまたは単にリソースと言う。）に対応した統合型オペレーションシステムの機能構成を示す。通信サービスとしては電話が中心であり、ネットワークリソースとしてはメタリックケーブルと交換機が中心の時代には、図１に示すようにサービス系のオペレーションを行う機能とネットワークリソースのオペレーションを行う機能とを統合したシステムが提案され、運用されてきた。このようなシステムでは、ユーザから電話サービスの依頼があると、電話用処理部９１１からサービスの種類、住所、開通予定日などを入力すると、連携処理部９２１を経由して、ケーブル用処理部９３１では開通予定日の時点で使用していない心線があるのかを確認し、交換機用処理部９３２では開通予定日の時点で使用していない交換機の端子があるのかを確認することで、設備の割付を行っていた。

しかし、通信サービスとネットワークエレメントが多様化してくると、図１のような統合型のオペレーションシステムでは、新しいサービスやネットワークエレメントに対応するための改造にかかる時間と費用とが膨大になり、図２に示すような各階層に分かれたオペレーションシステムが提案された。図２に示すシステム構成でも、サービス開通の情報はサービス系ＯｐＳから入力され、ＮＥ系ＯｐＳからネットワークリソースの情報を得て、ＮＷ系ＯｐＳであるＮＭＳ（ネットワークマネージメントシステム）で、開通予定日の時点で使用していないネットワークリソースがあるのかを確認していた。このシステム構成では、個々のシステムを連携させるためのインターフェース８６１として、例えばＳＮＭＰ、ＣＭＩＰ、ＣＯＲＢＡなどが提案されてきた。しかし、新しいネットワークエレメントが追加されるときには、ＮＭＳにも何らかの改造が必要となることがほとんどであり、ＮＭＳの大規模化に伴ってこの方式でも改造にかかる時間と費用が膨らんでおり、更なるシステム構成の改良が求められてきた。

上記のようにネットワークリソースの使用状況が変化する１つの理由は、サービス系ＯｐＳからのサービスの開始／廃止の依頼であり、設備の割付が行われると、リソースは単に現用、在庫（現用でない）というステータスに分けられるだけでなく、予約（在庫であるが、将来開始する予定）と廃止予定（現用であるが、将来廃止する予定）というステータスも存在することになる。また、一時的なサービス提供の場合には、開通と廃止が連続的に依頼され、予約と廃止予定の両方を含むステータスも存在する。さらに、ビルのテナントが変わる場合などは、現在のテナントが使用している通信路を廃止し、その後に開通ということもあるため、廃止予定と予約という順番のステータスもある。図１および図２に示した従来の通信系のオペレーションシステムでは、このように時間とともに変化するネットワークリソースの状態（リソースの時系列情報）を、ＮＭＳなどのシステムで集中的に管理・運用してきた。

図３は、ネットワークリソースである通信装置が自立分散的にネットワークリソースを管理しパスの設定などを行う場合のシステム構成を示す。新しいネットワークリソースの管理・運用方法として、ＧＭＰＬＳ（Generalized Multi-Protocol Label Switching）技術のような、通信装置が自立分散的にネットワークリソースを管理しパスの設定などを行う方法が提案されている。

図４にＧＭＰＬＳの概要を示す。ＧＭＰＬＳでは、仮想的にネットワークを構成しルーティングとシグナリングによる自立分散ネットワークを形成する制御プレーンと、実際にデータ通信を行うデータプレーンとから構成されている（非特許文献１）。この構成では制御プレーンとデータプレーンとを対応付けするリンク管理、ネットワークのトポロジを把握（共有）するためのルーティング（非特許文献２）、およびＬＳＰ（Label Switched Path）を設定するためのシグナリング（非特許文献３）などの技術が採用されている。
E. Mannie et al., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", IETF RFC 3945, Oct. 2004. D. Katz et al., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching", IETF draft, draft-ietf-ccamp-ospf-gmpls -extensions-12.txt, Oct. 2003 (work in progress). L. Berger et al., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", IETF RFC 3473, Jan. 2003.

従来、ネットワークエレメントである通信装置は、現状のリソース情報は管理しているが、時系列情報（時間的な変化を示す情報）は管理していない。ＧＭＰＬＳにおいても、自立分散的なリソースの管理・運用とは、現状のリソースとトポロジとを把握し、パスの設定などを行うにとどまっている。したがって、自立分散的な管理・運用では、将来使う予定（予約）状態のリソースを避けてリソースを割り付けることはできない。また、将来廃止予定のリソースを考慮して将来のパス計算を行うこともできない。たとえば、障害発生時に迂回用のパスを設定する場合に、他にも経路がある場合でも、使う予定のあるリソースを使ってパスを設定してしまうこともある。このような問題に対応するために、時系列情報を含んだリソースの運用管理を行う場合には、図５に示すように、ＮＭＳによってリソースの集中管理を行う必要があった。しかし、ＮＭＳによる集中管理を行うと、上記のようにＮＭＳの改造のための負担が大きくなるという問題がある。

本発明では、各通信装置が保有する当該通信装置のリソース（帯域、波長など）管理項目に時系列情報を含め、通信装置間の情報共有化の過程で授受される情報に前記時系列情報を含め、各通信装置が把握するネットワークのトポロジにも前記時系列情報を含める。各通信装置は通信路を開通する時刻を考慮して通信路の設計を行い、他の通信装置に時系列情報を含めた通信路確保や通信路設定の依頼を行う。

本発明によれば、自立分散ネットワークにおいても時間的な変化を考慮したネットワークリソースの割付が可能となる。また、図６に示すように時系列情報を含むリソース管理を集中管理する必要がなくなるので、新しいネットワークエレメントの追加にも安価かつ柔軟に対応できるオペレーションシステムを構築できる。

以下にこの発明の実施形態を図面を参照して説明するが、同一の機能を有する部分は、各図中に同一参照番号を付けて重複説明を省略する。
［第１実施形態］
図７に通信装置の機能構成例を、図８にプロパティ（リソースに関する情報）の例を、図９に通信装置での処理フローを、図１０に通信路設計の優先度テーブルの例を示す。通信装置１００は、図６に示したルータや伝送装置（３２１〜３２５）などの通信装置であって、各通信装置固有の機能として従来から備える機能の他に、トポロジ把握部１１０、時相通信路設計部１２０、ステータス設定部１３０、通信路設定部１４０、および時系列情報を含むプロパティ、トポロジ、および優先度テーブルを記録する記録部１５０を備えている。プロパティとは、図８に示すように通信路の種別を示す通信路タイプ、通信路を特定する識別子である通信路ＩＤ、最大帯域幅、現用帯域などのほかに、時系列情報である予約帯域と開通予定時刻、廃止予定帯域と廃止予定時刻などの情報からなり、通信装置１００の記録部１５０に記録され、適宜更新される。プロパティを構成する時系列情報である予約帯域と開通予定時刻、廃止予定帯域と廃止予定時刻などの時間に関係する情報は、複数個となっても良い。ステータス（時系列情報）の例としては、（現在の使用区分）＝（在庫）、（現在の使用区分，帯域，開通予定時刻）＝（在庫，１００Ｍｂｐｓ，２００５／１／３１１０：００：００）、（現在の使用区分，帯域，廃止予定時刻）＝（現用，１００Ｍｂｐｓ，２００５／１／２７００：００：００）、（現在の使用区分，帯域，廃止予定時刻，開通予定時刻）＝（現用，５０Ｍｂｐｓ，２００５／１／３１１２：００：００，２００５／２／３１７：００：００）、（現在の使用区分，帯域，開通予定時刻，廃止予定時刻）＝（現用，２００Ｍｂｐｓ，２００５／２／７１０：００：００，２００５／２／７１９：００：００）などがある。優先度テーブルは、あらかじめ通信装置１００の記録部１５０に記録され、通信路の設計を行う際に、リソース選定の優先度として利用する。

ネットワーク内の１つの通信装置１００が、オペレータまたは他のオペレーションシステムから開通の時刻を含んだ通信路変更の指示を受け取ると、当該通信装置１００のトポロジ把握部１１０は、当該通信装置１００の記録部１５０のプロパティに時系列情報を書き込む（Ｓ１９１）。次にトポロジ把握部１１０は、他の通信装置と互いの時系列情報を含むプロパティを授受し（Ｓ１９２）、ネットワークのトポロジ（時系列情報を含む）を把握する（Ｓ１９３）。ここで、プロパティの授受の方法は従来技術を使用すれば良く、例えばＩＰプロトコルによる方法、共通線信号方式による方法などが考えられる。次に時相通信路設計部１２０で、把握した時系列情報を含むトポロジから、図１０に示すような優先度を考慮して、優先度の高いリソースから通信路を構築するリソースを選択する（Ｓ１９４）。通信路設計に使用する時系列情報としては、例えば、通信路の開通情報のようなオペレータがユーザインターフェースから入力した時系列情報や他のＯｐＳからの時系列情報なども考えられる。時相通信路設計部１２０では、このようなトポロジ把握部１１０で収集した時系列情報以外の情報も用いて設計することもある。なお、図１０中の計画的通信路開通とは、ユーザからの通信路の開通依頼や、中継網のトラヒック増加に対応するための通信路開通などが該当する。さらに、選択した通信路上の他の通信装置に、開通予定時刻に通信路を設定できるかを確認する工程を含めても良い。また、把握しているトポロジを利用して設計するのではなく、他の通信装置に改めて開通予定時刻に通信路を設定できるかを問い合わせる方法だけによって設計する方法もある。次にステータス設定部１３０は、設定予定の通信路上の通信装置に、各通信装置のプロパティに時系列情報を書き込む（ステータスの変更）よう依頼する（Ｓ１９５）。さらに、プロパティに書き込まれた時刻に自動的またはオペレータからの指示により、通信路を開通するための指示を、通信路設定部１４０が行う。

障害発生のリカバリ（障害復旧）をする場合には、通信路設計のステップＳ１９４でのリソース選定の優先度が変わる。障害発生のリカバリの場合には、できるだけ早い通信路開通が要求されるので、開通予定時刻（開通希望時刻）が現在である。したがって、現在、在庫状態（現用でない）のリソースから選定する必要がある。したがって、在庫のリソースの中で、まず将来使われる予定のないリソース（予約のないリソース）から選定する。予約のないリソースでは足りない場合には、予約のあるリソースからも選定する。また、重要な通信路のリカバリの場合には、早期のリカバリを実現するために、重要度の低い現用のリソースを減らしてでもリソースを選定する。
廃止の場合には、通信路設計を行う必要は無く、把握しているトポロジから廃止する通信路を構成する通信装置に対して、廃止予約情報（廃止予定帯域、廃止予定時刻など）を各装置のプロパティに書き込むよう依頼する（Ｓ１９５）。

［第２実施形態］
本実施形態は、自立分散ネットワークとして具体的な検討が進められているＧＭＰＬＳに適用した場合を示す。図１１にノードの機能構成例を、図１２にプロパティの例を示す。通信装置２００は、従来のノードとしての機能の他に、トポロジを把握するルーティング部２１０、時相パス計算部２２０、ステータスの設定やリンクの設定を行うシグナリング制御部２３０、および時系列情報を含むプロパティ、トポロジ、および優先度テーブルを記録する記録部２４０を備えている。ルーティング制御部２１０は、ＴＥリンクのプロパティ内に時系列情報であるステータスを含めて広告すること、時系列情報をＴＥ（トラヒック・エンジニアリング）データベースに組み込むことを行い、トポロジを把握する。時相パス計算部２２０では、ＴＥリンクの現在の使用区分、開通予定時刻、廃止予定時刻を考慮するため、「時刻」と「ステータス」が計算時に使用する要素に追加される。シグナリング制御部２３０は、ステータスの変更・設定を行う。具体的には、ＰａｔｈメッセージとＲｅｓｖメッセージで送信されるＬＳＰ＿ＡＴＴＲＩＢＵＴＥ．ｏｂｊｅｃｔにステータスを含める方法と新たなオブジェクトを定義して送る方法とある。プロパティには、リンクタイプ、リンクＩＤ、ローカルインターフェースＩＰアドレス、ＴＥメトリック（コスト値）、最大帯域幅などの従来のＧＭＰＬＳに規定されている情報の他に、時系列の情報（ステータス）を含める。なお、ステータスは第１実施形態で示したものと同じであり、複数個の時系列情報になっても良い。また、優先度テーブルは図１０と同様のテーブルを記録部２４０に記録しているものとする。

図１３にＧＭＰＬＳでのネットワークの構成例と処理手順の概要を、図１４に処理フローの概要を示す。ＧＭＰＬＳでは、実際にデータが伝送されるデータプレーン３２０とネットワークを制御するために仮想的なネットワークを構築する制御プレーン３１０とから構成される。リソースを追加した場合には、コンフィグやユーザインターフェース等により初期値を入力し、ＴＥリンクの登録とリソースのステータスの登録を行う（Ｓ４３１）。ＴＥリンクの変更やリソースのステータスの変更があった場合には、各ノードのルーティング制御部２１０は、変更内容について広告する（Ｓ４３２）。この広告によって各ノードはトポロジを把握できる。ステータスとは、ＴＥリンクのプロパティの一部として登録する現用／在庫、予約、予定開通時刻、廃止予約、廃止予定時刻などの時間的変化を示す情報（時系列情報）を言うものとし、この時系列の考え方は従来のＧＭＰＬＳには無いものである。

オペレータ、他のオペレーションシステム、またはノード内の時刻をトリガとして、リンクの端点となるノードの１つであって当該トリガを受信したノード３２１（イニシエータ）の時相パス計算部２２０は、把握している時系列情報を含むトポロジから時系列情報を考慮したパス計算（時相パス計算）を行う（Ｓ４３４）。次に、シグナリング制御部２３０がシグナリングによって時系列情報を含んだＬＳＰの設定を他のノード３２２〜３２５に依頼し、データプレーン３２０上でもパスを設定する（Ｓ４３５）。また、シグナリング制御部２３０は、ステータスが変更されたことをルーティング部２１０に通知し、ルーティング部が他のノードへ広告するとともにＴＥデータベースに記録する。一方、中継ノード３２３〜３２５および他端の端点ノード３２２（ターミネータ）では、イニシエータ３２１からのＰａｔｈメッセージを受理し（Ｓ４３７）、ＴＥリンクとリソースの割り当ての可否を判断し（Ｓ４３８）、Ｐａｔｈメッセージを次のノードに中継し、次のノードからのＲｅｓｖメッセージをイニシエータ側のノードに中継し、データプレーン上でパスの設定を行う（Ｓ４３９）。このような処理フローによってステータスの内容がトポロジに反映される（Ｓ４４１）。また、いずれかのステップでエラーが発生した場合には従来のＧＭＰＬＳの処理にしたがって、ロールバック処理が行われる（Ｓ４４２）。
なお、図１５にイニシエータを中心とした処理フローの詳細を示す。

［第３実施形態］
本実施形態は、ＧＭＰＬＳでの処理手順を、いくつかのパス設定のシナリオも含めて説明する。ノードの機能構成とプロパティは、図１１と図１２に示したものと同じとする。図１６にネットワークの構成例を、図１７にノードのリソースのステータス情報の変化の例を示す。また、優先度テーブルは図１０に示したテーブルを用いる。
クライアント５１１とクライアント５１２との間に、時刻ｔ３からｔ４の間に一時的なＬＳＰを設定するシナリオを示す。ノード５２１とノード５２７との間には既にいくつかのパスが設定されている。ここで、図１７をリンク５３３のリソースのステータスとする。

クライアント５１１から一時利用のパスの依頼を受けたノード５２１は、イニシエータとして時相パス計算部２２０で、ＴＥデータベースを参照して、時刻ｔ３〜ｔ４における一時利用可能な経路（ＴＥリンクごとの空きリソース）を以下のように検索する。時相パス計算の結果、帯域に空きがあれば、ノード５２１（もしくはクライアント５１１）のシグナリング制御部２３０は開通予定時刻と廃止予定時刻を設定したＰａｔｈメッセージを送出する。時相パス計算部２２０の計算例をリンク５３３のリソースのステータスを示す図１７を用いて説明する。リンク５３３の最大帯域をＷ、予約のない現用の帯域をｗ１、ｔ１に廃止予約のある帯域をｗ２、ｔ２に開通予約のある在庫をｗ３とする。時間ｔ３〜ｔ４の現用予定の帯域はｗ１＋ｗ３であるから、Ｗ−（ｗ１＋ｗ３）が一時利用予定の帯域ｗ４よりも大きければ、時間ｔ３〜ｔ４に帯域に空きがあることになる。中継ノード、ターミネータのシグナリング制御部２３０は、リソースを予約し、ＰａｔｈメッセージまたはＲｅｓｖメッセージを中継する。このシグナリングが完了すれば、一時利用の時相ＬＳＰは設定完了となる。このような処理フローにより時相ＬＳＰの経路上のノードは、ＴＥリンクのリンク情報をアップデートして新しいトポロジを把握する。なお、時相ＬＳＰは、タイマ機能により自動的にデータプレーン上のパス設定を行うこともできるし、オペレータからの明示的なコマンドによりデータプレーン上のパスを設定することもできる。なお、Ｗ−（ｗ１＋ｗ３）がｗ４よりも小さいときにはエラーとなるが、オペレータにかえすエラーメッセージ内に、ｗ４−{Ｗ−（ｗ１＋ｗ３）}の値を含めることもできる。また、Ｗ−ｗ１がｗ４よりも大きいときには、時刻ｔ２以降の帯域が不足しているので、上記のｗ４−{Ｗ−（ｗ１＋ｗ３）}の値に加えて時刻ｔ２もエラーメッセージに含めることもできる。このようなエラーメッセージに含める情報は、オペレータにとって有用な情報となる。

上記の例では、ＴＥデータベースの時系列情報を利用して時相パス計算を行ったが、シグナリングによって各ノードに時系列を考慮したリンクの在庫を問い合わせることによって設計する方法もある。図１６のネットワーク場合は、イニシエータのノード５２１が、時刻ｔ３〜ｔ４に帯域ｗ４が確保できるかを、シグナリング（Ｐａｔｈメッセージ）を用いて各ノードに問い合わせる。リンク５３３のリソースのステータスを把握しているノード５２３が上記の例と同じようにＷ−（ｗ１＋ｗ３）とｗ４とを比較し、Ｗ−（ｗ１＋ｗ３）がｗ４以上でれば、次のノードであるノード５２５にＰａｔｈメッセージを中継し、Ｗ−（ｗ１＋ｗ３）がｗ４よりも小さければ、ＰａｔｈＥｒｒメッセージをイニシエータであるノード５２１に戻す。このＰａｔｈＥｒｒメッセージに足りなかった帯域の情報であるｗ４−{Ｗ−（ｗ１＋ｗ３）}の値や時刻ｔ２を加えても良い。全てのノードで帯域が確保できれば、Ｒｅｓｖメッセージがノード５２１（もしくはクライアント５１１）に戻り、帯域が確保できたこと（設計できたこと）が分かる。

次に、リンクの障害時に、動的に迂回先パスの計算を実行するシナリオを示す。この場合には、即時にパス設定を行うことが求められるが、時相パス計算部２２０でのパスの検索方法が異なる。図１７のようなステータスのＴＥリンクが迂回先パスとして使用できるかを考える場合について説明する。迂回先パスとして帯域ｗ５が求められているとする。現在の現用の帯域はｗ１＋ｗ２で空きはＷ−（ｗ１＋ｗ２）であるが、将来まで考慮すると、予約のない在庫に相当する帯域は、Ｗ−（ｗ１＋ｗ３＋ｗ４）である。図１０に示す優先度テーブルでは予約のない在庫から選定するので、Ｗ−（ｗ１＋ｗ３＋ｗ４）がｗ５よりも大きい場合には、このリンクを使用する。迂回先パスのどの候補にも帯域に空きがない場合には、予約のある在庫もリソース選定に使用するので、Ｗ−（ｗ１＋ｗ２）がｗ５よりも大きければ帯域に空きがあることになり、このリンクを使用する。さらに、重要度の高いパスのリカバリの場合には、重要度の低い現用パスの帯域を減らしてでもリソースを確保するので、Ｗ−（ｗ１＋ｗ２）がｗ５よりも小さく、ｗ１が重要度の低いパスの帯域だとすると、Ｗ−ｗ２がｗ５よりも大きければ、ｗ５をまず確保し、ｗ１の帯域をＷ−（ｗ２＋ｗ５）まで減らすこととなる。このように障害が発生したパスの重要度を考慮したパス計算が可能となる。

従来の電話系のサービスと設備に対応した統合型オペレーションシステムの機能構成を示す図。従来の階層化されたオペレーションシステムの構成を示す図。ネットワークリソースである通信装置が自立分散的にネットワークリソースを管理しパスの設定などを行う場合のシステム構成を示す図。ＧＭＰＬＳの概要を示す図。ＮＭＳによってリソースの集中管理を行うイメージを示す図。時系列情報を含むリソース管理を自立分散的に管理するイメージを示す図。通信装置の機能構成例を示す図。プロパティ（リソースに関する情報）の例を示す図。通信装置での処理フローを示す図。通信路設計の優先度テーブルの例を示す図。ノードの機能構成例を示す図。プロパティの例を示す図。ＧＭＰＬＳでのネットワークの構成例と処理手順の概要を示す図。処理フローの概要を示す図。イニシエータを中心とした処理フローの詳細を示す図。ネットワークの構成例を示す図。ノードのリソースのステータス情報の変化の例を示す図。

Claims

自律分散的にリソース管理と運用を行うネットワークを構成する通信装置であって、
時系列情報を含む他の通信装置の通信路設定情報を収集し、ネットワークの構成を把握し、ネットワーク構成データを作成するトポロジ把握部と、
上記トポロジ把握部が作成したネットワーク構成データベースから、時系列情報を含めて通信路の設計を行う上記時相通信路設計部と、
上記時相通信路設計部の設計結果にしたがって、通信路設定情報を変更・設定する指示を他の通信装置に行うステータス設定部と、
当該通信装置の通信路の時系列情報を含む通信路情報および上記ネットワーク構成データを記録する記録部と、
を備えた通信装置。
請求項１記載の通信装置であって、
上記トポロジ把握部で収集した時系列情報以外の時系列情報も通信路の設計に使用する上記時相通信路設計部
を備えた通信装置。
自律分散的にリソース管理と運用を行うネットワークを構成する通信装置であって、
他の通信装置の通信路設定情報を収集し、ネットワークの構成を把握し、ネットワーク構成データを作成するトポロジ把握部と、
当該通信装置が時系列情報を含む通信路情報を把握するネットワーク内に、通信路の設定が可能かの確認を、時系列情報も考慮して行う時相通信路設計部と、
上記トポロジ把握部で作成したネットワーク構成データから設定したい通信路上の他の通信装置を把握し、当該他の通信装置に時系列情報を含めて通信路の設定が可能かの確認を依頼するステータス設定部と、
当該通信装置の通信路の時系列情報を含む通信路情報および上記ネットワーク構成データを記録する記録部と、
を備えた通信装置。
請求項３記載の通信装置であって、
上記ステータス設定部の確認結果が全て可能となった場合に、通信路設定情報を変更・設定する指示を他の通信装置に行う上記ステータス設定部と、
を備えた通信装置。
請求項１から４のいずれかに記載の通信装置であって、
通信路設計の目的別にリソース選定の優先度情報を記録する上記記録部と、
上記優先度情報にしたがって通信路の設計を行う上記時相通信路設計部と、
を備えた通信装置。
自律分散的にリソース管理と運用を行うネットワークを構成する通信装置であって、
通信路設計の目的別にリソース選定の優先度情報を記録する記録部と、
他の装置から時系列情報を含む通信路確認指示を受信するステータス設定部と、
上記優先度情報にしたがって、上記通信路確認指示の通信路の割り当てが可能かを確認する時相通信路設計部と、
を備えた通信装置。
請求項１から６のいずれかに記載の通信装置であって、
時系列情報を含む当該通信装置の通信路設定情報を、他の通信装置に通知する上記トポロジ把握部
を備えた通信装置。
請求項１から７のいずれかに記載の通信装置であって、
設定された時系列情報を含む通信路設定情報にしたがって、設定された時間に通信路を変更・設定する通信路設定部
を備えた通信装置。
請求項1から８のいずれかに記載の通信装置であって、
上記時相通信路設計部で設計に必要なリソースが確保できない場合に、不足したリソースの情報またはリソースが不足する時刻の情報のうち少なくともいずれかを、エラーメッセージに含める上記ステータス設定部
を備えた通信装置。
ＧＭＰＬＳネットワークを構成する通信装置であって、
他の通信装置から時系列情報を含むリンクのプロパティを収集し、トポロジを把握し、ＴＥデータを作成するルーティング制御部と、
上記ルーティング制御部が作成した時系列情報を含んだＴＥデータを用いてパスの設計を行う時相パス計算部と、
上記時相パス計算部の設計結果にしたがって、他の通信装置に時系列情報を含むリンクのプロパティを変更・設定を指示するシグナリング制御部と、
上記ＴＥデータを記録する記録部と、
を備えた通信装置。
請求項１０記載の通信装置であって、
他の通信装置にシグナリングによってパス設定が可能なことを確認する時相パス計算部
を備えた通信装置。
ＧＭＰＬＳネットワークを構成する通信装置であって、
他の通信装置からリンクのプロパティを収集し、トポロジを把握し、ＴＥデータを作成するルーティング制御部と、
当該通信装置が把握しているリンクにパスの設定が可能かを時系列情報も考慮して確認する時相パス計算部と、
上記ルーティング制御部が作成したＴＥデータを用いて、パスの経路上の他の通信装置にパスの設定が可能かを、時系列情報を含めた確認の依頼をするシグナリング制御部と
上記ＴＥデータを記録する記録部と、
を備えた通信装置。
請求項１０から１２のいずれかに記載の通信装置であって、
パス設計の目的別にリソース選定の優先度情報を記録する上記記録部と、
上記優先度情報にしたがってパス設計を行う上記時相パス計算部と、
を備えた通信装置。
ＧＭＰＬＳネットワークを構成する通信装置であって、
他の通信装置から時系列情報を含むシグナリングメッセージを受理し、パス設定の可否を確認するとともに、他の装置にＰａｔｈメッセージを中継または他の装置のＲｅｓｖメッセージを中継するシグナリング制御部
を備えた通信装置。
自律分散的にリソース管理と運用を行うネットワークを構成する通信装置の制御方法であって、
トポロジ把握部で、時系列情報を含む他の通信装置の通信路設定情報を収集し、ネットワークの構成を把握し、ネットワーク構成データベースを作成し、
時相通信路設計部で、上記トポロジ把握部で作成した時系列情報を含むネットワーク構成データベースを利用して通信路の設計を行い、
ステータス設定部で、時系列情報を含む通信路設定情報を変更・設定する指示を他の通信装置に行う
ことを特徴とする通信装置の制御方法。
自律分散的にリソース管理と運用を行うネットワークを構成する通信装置の制御方法であって、
トポロジ把握部で、他の通信装置の通信路設定情報を収集し、ネットワークの構成を把握し、ネットワーク構成データを作成し、
時相通信路設計部で、当該通信装置が時系列情報を含む通信路情報を把握するネットワーク内に、通信路の設定が可能かの確認を、時系列情報も考慮して行い、
ステータス設定部で、上記トポロジ把握部で作成したネットワーク構成データから設定したい通信路上の他の通信装置を把握し、当該他の通信装置に時系列情報を含めて通信路の設定が可能かの確認を依頼する
ことを特徴とする通信装置の制御方法。
自律分散的にリソース管理と運用を行うネットワークを構成する通信装置の制御方法であって、
あらかじめ記録部に通信路設計の目的別にリソース選定の優先度情報を記録しておき、
ステータス設定部で、他の装置からの時系列情報を含む通信路確認指示を受信し、
時相通信路設計部で、上記優先度情報にしたがって、上記通信路確認指示の通信路の割り当てが可能かを確認する
ことを特徴とする通信装置の制御方法。
請求項１から１４のいずれかに記載の通信装置をコンピュータにより実現するプログラム。