(57)【要約】      （修正有）【課題】トラフィックエンジニアリング及びＱｏＳの二つの分野を融合する簡便な手段を与える。【解決手段】電気通信システムは、ネットワークを含んでいる。システムはネットワークと通信するＮＭＳを含んでおり、そのＮＭＳは、ルートオブジェクトに付けられたＱｏＳパスオブジェクトを伴ったサービスオンデータを有している。システムは、ネットワークと通信する複数のノードを含んでおり、ノードは、ネットワークを通してＮＭＳから送られるルートワードが付けられたＱｏＳパスオブジェクトを受け取る。テレビ会議をする方法は、ＱｏＳパスオブジェクトを生成するステップを含んでいる。ルートオブジェクトにＱｏＳパスオブジェクトを付けるステップがある。【選択図】  図２
2005328532.tif 000002
【特許請求の範囲】
【請求項１】
ＱｏＳパスオブジェクトを生成する生成ステップと、
ルートオブジェクトにＱｏＳパスオブジェクトを付ける付加ステップとを含む、テレビ会議をする方法。
【請求項２】
ＱｏＳパスオブジェクトは、ディフサーブクラスオブジェクトを含む、請求項１に記載の方法。
【請求項３】
付加ステップは、１回の動作で、ディフサーブクラスオブジェクトをルートオブジェクトに付けるステップを含む、請求項２に記載の方法。
【請求項４】
サービスオンデータと共に、ディフサーブクラスオブジェクトを伴ったルートオブジェクトを、パスに沿って自動的に提供するステップを含む、請求項３に記載の方法。
【請求項５】
ＬＳＰのルートオブジェクトを定めるステップを含む、請求項４に記載の方法。
【請求項６】
ＳＰＶＣの指定中継リストのルートオブジェクトを定めるステップを含む、請求項５に記載の方法。
【請求項７】
生成ステップは、ディフサーブクラスオブジェクトについてＱＯＳパラメータを定めるステップを含む、請求項６に記載の方法。
【請求項８】
パスは、ＭＰＬＳネットワークに亘っている、請求項７に記載の方法。
【請求項９】
パス中のノードに、ディフサーブクラスオブジェクトを有するルートワードを送るステップを含む、請求項８に記載の方法。
【請求項１０】
ネットワークと、
ネットワークと通信し、ルートオブジェクトに付けられたＱＯＳパスオブジェクトを伴うサービスオンデータを有するＮＭＳと、
ネットワークと通信し、ルートワードに付けられたＱＯＳパスオブジェクトを、ネットワークを通じてＮＭＳから受け取る複数のノードとを含む電気通信システム。
【請求項１１】
ＱＯＳパスオブジェクトはディフサーブパスオブジェクトを含む、請求項１０に記載のシステム。
【請求項１２】
ネットワークは、ＭＰＬＳ、ＡＴＭ、又はフレームリレーネットワークである、請求項１１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電気通信ネットワークの管理に関する。より詳細には、ルートオブジェクトに付けられたディフサーブ(DiffServ)クラスオブジェクトを用いた電気通信ネットワークの管理に関する。
【背景技術】
【０００２】
ネットワークサービスは、単純な仮想接続及び帯域幅の供給(即ち、速度及びフィード)を超えて進歩している。これは、(1)サービスプロバイダが行う提供の均一化(commoditization)と、(2)企業におけるアウトソーシング通信のニーズ(例えば、レイヤー２/３ＶＰＮ、コンテンツ配信、ホスティング等)との組合せによるものである。その結果、サービスプロバイダが必要とする(彼らのネットワーク管理プロダクトにある)管理オブジェクト(managed object)は、益々複雑になっている。この複雑化の１つの特徴として、管理オブジェクトは、ネットワークに亘って急速に分布していることがある。分布したオブジェクトは、管理するのが困難であり、これは、結果として、人員配置による高額の費用を必要とする。ネットワークの構築が、小規模から大規模モデルに進歩するにつれて、サービスプロバイダは、管理コストが可能な限り低減されるように、彼らのベンダーが、プロダクトのインフラストラクチャを活用することを要求している。
【０００３】
本発明は、サービスオンデータ(ServiceOn Data)ルートオブジェクトを基礎として用いて、トラフィックエンジニアリング及びＱｏＳの２つの分野を融合する簡便な手段を与える。通常、これらの分野は、互いに区別されると考えられている。これによって、ユーザ定義のディフサーブクラスをＭＰＬＳネットワークに加えるのに要する時間と、その複雑さ及びコストとが低減される。また、ネットワークにこれらクラスを加えることを自動化することで、動作の速度及び精度が改善される。最終的に、本発明は、ネットワークにおいて新たなディフサーブクラスを生成する過程をはかどらせる。指導原理は、サービスの展開を速くすることで、迅速な利益の生成が促進されることである。
【発明の開示】
【０００４】
本発明は、電気通信システムに関する。システムは、ネットワークを具えている。システムは、ネットワークと通信するＮＭＳを具えており、ＮＭＳは、ルートオブジェクトに付けられたＱＯＳパスオブジェクトを伴ったサービスオンデータを有している。システムは、ネットワークと通信する複数のノードを具えており、これらノードは、ルートオブジェクトに付けられたＱＯＳパスオブジェクトを、ネットワークを介してＮＭＳから受信する。
【０００５】
本発明は、テレビ会議を行う方法に関する。その方法は、ＱＯＳパスオブジェクトを生成するステップを含んでいる。ＱＯＳパスオブジェクトをルートオブジェクトに付けるステップがある。
【発明を実施するための最良の形態】
【０００６】
図を参照すると、幾つかの図を通して類似又は同じ部分には、類似した符号が付されている。特に図２を参照すると、電気通信システム(10)が示されている。システム(10)は、ネットワーク(12)を具えている。システム(10)は、ネットワーク(12)と通信するＮＭＳ(14)を具えており、ＮＭＳ(14)は、ルートオブジェクトに付けられたＱＯＳパスオブジェクトを伴ったサービスオンデータを有している。システム(10)は、ネットワーク(12)と通信する複数のノード(16)を具えており、これらノード(16)は、ルートオブジェクトに付けられたＱＯＳパスオブジェクトを、ネットワーク(12)を介してＮＭＳ(14)から受信する。
【０００７】
ＱＯＳパスオブジェクトは、ディフサーブパスオブジェクトを含んでいるのが好ましい。ネットワーク(12)は、ＭＰＬＳ、ＡＴＭ、又はフレームリレーネットワーク(12)であるのが好ましいが、適当なディフサーブ能力があるＩＰネットワークであってもよい。
【０００８】
本発明は、テレビ会議を行う方法に関する。その方法は、ＱＯＳパスオブジェクトを生成する生成ステップを含んでいる。ＱＯＳパスオブジェクトをルートオブジェクトに付ける付加ステップがある。
【０００９】
ＱＯＳパスオブジェクトは、ディフサーブクラスオブジェクトを含んでいるのが好ましい。付加ステップは、１回の動作にて、ディフサーブクラスオブジェクトをルートオブジェクトに付けるステップを含むのが好ましい。
【００１０】
ディフサーブクラスオブジェクトを伴ったルートオブジェクトを、サービスオンデータと共に、パスに沿って自動的に供給するステップがあるのが好ましい。ＬＳＰのルートオブジェクトを定義するステップがあるのが好ましい。
【００１１】
ＳＰＶＣの指定中継リスト(designated transit list)のルートオブジェクトを定義するステップがあるのが好ましい。生成ステップは、ディフサーブクラスオブジェクトについて、ＱＯＳパラメータを定義するステップを含むのが好ましい。パスは、ＭＰＬＳネットワーク(12)に亘っているのが好ましい。ディフサーブクラスオブジェクトを有するルートオブジェクトを、パス中のノード(16)に送るステップがあるのが好ましい。
【００１２】
[ディフサーブクラス]
これは、ネットワークを通じてＩＰトラフィックを転送するための様々な手段を与える方法である。それは、道路上で、通常の往来を通って救急車が出て来る手段に少し似ている。ネットワーク分野では、優先度の高いディフサーブクラスを生成することができ、そのディフサーブクラスによって、ある特定のトラフィックのＱｏＳを、その他のトラフィックのＱｏＳよりも良くすることが可能である。何故にこれを行うことを望むのか？ それは、ボイスオーバーインターネットを用いている場合、生成されたパケットは、ｅメール又はウェブのトラフィックのＱｏＳよりも良いＱｏＳを必要とする。よって、ボイスオーバーＩＰディフサーブクラスが生成される。ＩＰパケットが、それに関連するＱｏＳを得るためには、それらは、ＩＰヘッダーのディフサーブフィールドを用いて、それを得るようにマークされていなければならない。その結果、そのようにマークされたどのパケットも、ディフサーブクラスに関連するＱｏＳを得るであろう。
【００１３】
[サービスオンデータ]
マルコーニによって製造された市販用のネットワーク管理システムパッケージは、世界中の多くのサイトで使用されている。
【００１４】
[ルートオブジェクト]
サービスオンデータのソフトウェアエレメントによって、ユーザは、ネットを通じてルートを特定することが可能となる。ＲＯは、端から端に達するのに横切るノードを選択するために用いられる。これによって、例えばＡＴＭ又はＭＰＬＳネットワークのようなネットワークに亘って、必要なパスが与えられる。ＲＯが定義されると、例えば、ＡＴＭのＳＰＶＣやＭＰＬＳのＬＳＰのような接続が生成可能となる。
【００１５】
本発明が機能している場合、ＩＰネットワークのクオリティオブサービス(ＱｏＳ)の展開は、例えばディフサーブのような多くの技術を用いて達成され得る。このスキームでは、ＩＰヘッダの６ビットのフィールドが用いられて、パケットがディフサーブドメインを行き来する際にパケットが受けるＱｏＳ処理を定義する。図１は、このようなディフサーブドメインの端に到達する２つのＩＰパケットを示している。上のパケットは、ディフサーブフィールドに値がなく、その結果、それはベストエフォートサービスを受ける。下のパケットは、ディフサーブフィールドに値があって、ベストエフォートよりもレベルが高い適切なサービスを受ける。
【００１６】
このケースにおけるサービスレベルは、実際にはＱｏＳであって、パケットがネットワーク(12)を横切る際の全経験(experience)として記述される。最終的には、これは、エンドユーザの経験であって、例えば、図１の下のパケットが、ボイスオーバーＩＰのフォンコールの一部である場合、ユーザは、そのパケットがベストエフォートとして送られた場合よりも、良いサービスを得る。典型的なＱｏＳパラメータは、以下を含んでいる。
・待ち行列の選択
・待ち行列内の優先度
・待ち行列の規律(discipline)
・出口(egress)インターフェイスでのスケジューリング
【００１７】
ディフサーブパスオブジェクトは、要求されたＱｏＳレベルが適用される特定のネットワーク(12)のパスを記録するために必要とされる。それは、ユーザ定義の所定のディフサーブクラスが適用される一連のノード(16)及びインターフェイスを定義する。
【００１８】
図２は、ディフサーブ対応のネットワーク(12)を示しており、ネットワーク(12)は、一連のＭＰＬＳノード(16)を含んでいる。全てのインターフェイスには、「ａ」から「ｐ」までの符号が付されている。パス「ａ」から「ｈ」上に、例として(必要に応じてその他の任意のディフサーブ値を用いることも可能である)、値０ｘ１１１１１１(即ち、６つ全てのビットが１に設定されている)を有するユーザ定義のディフサーブクラスがあることが要求される。これにより、このパスを行き来するパケットが、ユーザ定義のディフサーブクラスに関したサービスのレベルを受けることが保証される。なお、これには、ノード(16)は全てマルコーニの装置であることが仮定されている。
【００１９】
要求されたＱｏＳの設定を生成する手順は、以下の通りである。
・コマンドラインインターフェイス(又はＳＮＭＰ)のようなある手段を用いて、各ノードを繋げる。
・要求されるディフサーブクラスと、それに関連するパラメータとを定義する。
・そのディフサーブクラスを、「ａ」乃至「ｈ」の各インターフェイスに配置する。
・その新しいディフサーブクラスを有効にして、ＩＰトラフィックがそれによって処理されるようにする。
【００２０】
そして、適切なディフサーブのマーキングがあるＩＰトラフィックは、図２に示した関係するノード(16)の各々から、要求されたサービスレベルを得る。このスキームにおける問題は、２つの要素からなる。
・ユーザは、複数のノードの大半についてデバイスレベル設定をする必要がある。
・一旦設定がなされると、その設定を思い出すことは困難である。
・ディフサーブクラスを生成することは複雑なので、間違いが起こりやすい。
【００２１】
ディフサーブパスオブジェクトの発明によって、パラメータを設定し、パスを記録するスキームがもたらされることで、これらの問題は解決される。サービスオンデータは、現存するルートオブジェクトを用いて、パス(即ち、インターフェイス「ａ」乃至「ｈ」)に加えて、全てのパラメータを(ノード当たりに一度ではなく、単に一度)記録する。ユーザは、ディフサーブクラスを生成し、一回の動作で、それをルートオブジェクトに付ける。その後、サービスオンデータは、要求されたパスに沿って、自動的にＲＯ(ディフサーブクラスを含む)を供給する。これによって、人による入力の量が低減されて、ＲＯが再利用可能となる。後者は、トラフィックエンジニアリングの(例えば、ＬＳＰの明示的なルートオブジェクトを、又はＳＰＶＣの指定中継リストを生成する)間にて、ディフサーブクラスの詳細が、単純な動作でＲＯに単に付けられるように、既に定義されていてもよい。
【００２２】
それ故に、ディフサーブパスオブジェクトは、ＲＯを基礎として用いて、トラフィックエンジニアリング及びＱｏＳの２つの分野を融合する。言い換えると、ディフサーブクラスがｎ個のノード(ｎは１又は２以上)で必要とされる場合、ユーザが指示した(ｎ個のノードでの)ｎ回の動作の代わりに、単に１回の動作が必要とされて、サービスオンデータが、その他を管理する。さらなる利益は、ディフサーブパスオブジェクトが複製されて、最小の労力で、修正バージョンが効率的に生成可能となることである。
【００２３】
上述の説明は、ユーザ定義のディフサーブクラスを設定することに集中していた。ネットワーク(12)の発見(discovery)の間に得られる利益もある。簡単な例は以下の通りである。ユーザは回り道をして、複数のノードで、ディフサーブクラスを手動で設定しており、必要とされる全てのインターフェイスにそれを付けて、サービスを利用可能としていると仮定する。サービスオンデータは、この情報を発見して、新たなディフサーブパスオブジェクトを投入する(populate)ために、それを利用する。この機能によって、トラフィックエンジニアリングとＱｏＳとを統合するために使用されるマイグレーションパス(migration path)が提供される。この発見は、ソフトウェアのある部分(「ディスカバリー」と称される)で処理される。このソフトウェアは、多数の管理プロトコル(例えば、ＩＣＭＰ)を利用して、まず最初に、存在するノードを割り出す。そして、それらノードの構成が、(ＳＮＭＰを利用して)決定及び記録され得る。設定されたディフサーブクラスは、発見され、そして、サービスオンデータベースに記録されて、その後、検索及び使用され得る。
【００２４】
ディフサーブパスオブジェクトは、サービスオンデータへのアドオン(addon)として実施され得る。主要な２つの要素が含まれる。
(１)ディフサーブパスオブジェクトのＱｏＳパラメータを決定する。
(２)ディフサーブパスオブジェクトをＲＯに付ける。
(３)ネットワークにディフサーブパスオブジェクトを与える。
【００２５】
サービスオンデータは、本発明を実施するためのプラットホームをもたらすが、それは、このＮＭＳ(14)に限定される必要はない。ノーテルのコンチビティ(Contivity)やシスコのＩＰソリューションのようなＮＭＳ製品は、本発明を利用できる。多くのＭＮＳ製品は、ディフサーブクラスをサポートしているので、エンドツーエンドの事例について、このプロセスを簡単にする任意のユーティリティが利用できる。
【００２６】
説明を目的として、上述の実施例について本発明を詳細に記載したが、このような詳細は単に説明を目的としたものであって、当該分野の専門家によれば、添付されている特許請求の範囲に記載されている場合を除いて、本発明の精神及び範囲から逸脱することなく、その詳細について種々の変形をなし得ることが理解されるだろう。
【図面の簡単な説明】
【００２７】
添付の図面には、本発明の好ましい実施例と、本発明を実施する好ましい方法とが図示されている。
【図１】図１は、ベストエフォートＩＰ及びディフサーブＩＰの概要を示している。
【図２】図２は、ディフサーブに対応したネットワークの概要を示している。
【図１】
2005328532.tif 000003
【図２】
2005328532.tif 000004
【外国語明細書】
2005328532.tif 000005
2005328532.tif 000006
2005328532.tif 000007
2005328532.tif 000008
2005328532.tif 000009
2005328532.tif 000010
2005328532.tif 000011
2005328532.tif 000012
2005328532.tif 000013
2005328532.tif 000014
2005328532.tif 000015
2005328532.tif 000016
2005328532.tif 000017