JP3701476B2 - データ通信方法 - Google Patents
データ通信方法 Download PDFInfo
- Publication number
- JP3701476B2 JP3701476B2 JP27511898A JP27511898A JP3701476B2 JP 3701476 B2 JP3701476 B2 JP 3701476B2 JP 27511898 A JP27511898 A JP 27511898A JP 27511898 A JP27511898 A JP 27511898A JP 3701476 B2 JP3701476 B2 JP 3701476B2
- Authority
- JP
- Japan
- Prior art keywords
- message
- node
- path
- communication device
- resource
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/805—QOS or priority aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/16—Arrangements for providing special services to substations
- H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
- H04L12/185—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
- H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
- H04L47/745—Reaction in network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/74—Admission control; Resource allocation measures in reaction to resource unavailability
- H04L47/746—Reaction triggered by a failure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/806—Broadcast or multicast traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5629—Admission control
- H04L2012/5631—Resource management and allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5638—Services, e.g. multimedia, GOS, QOS
- H04L2012/564—Connection-oriented
- H04L2012/5642—Multicast/broadcast/point-multipoint, e.g. VOD
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワークにおけるデバイス間の通信方法に関し、特に、ネットワークのマルチキャスト通信プロトコルに関する。
【０００２】
【従来の技術】
通信プロトコルは、一般にコンピュータネットワークにおけるデバイス間のデータ伝送のフォーマットおよびタイミングに関する規則または手続きのセットを提供する。コンピュータネットワークはホストデバイスから形成される。ホストデバイスは、互いに情報を送信し合い、交換要素すなわち交換ノードの通信ネットワークによって接続される。マルチキャストは、メッセージがネットワーク内のホストのサブセットによって受信されるような通信の形式である。ポイント・ツー・マルチポイントのマルチキャスト環境では、ソースホストデバイスすなわちソースノードがメッセージを生成して複数のデスティネーションすなわち受信ホストとそのメッセージを通信する。マルチキャストは、マルチポイント・ツー・マルチポイントの場合もある。この場合、ネットワーク内の送信ノードのサブセットが複数の受信ノードへ情報を送信する。
【０００３】
マルチキャスト環境における通信フレームワークを提供するためにマルチキャストプロトコルが開発されてきた。リソース予約プロトコル（通常「ＲＳＶＰ」という。）は、マルチキャストコネクションにおけるリソース予約を行うために用いられる。ＲＳＶＰは、マルチキャストプロトコルを支援するように設計されている。しかし、ＲＳＶＰは、特に、受信ホストデバイスの数が非常の多いときには非効率的であり問題があることが分かっている。ＲＳＶＰの基本動作は、ソースからデスティネーションへＰＡＴＨ（パス）メッセージを送った後、デスティネーションがＲＥＳＥＲＶＡＴＩＯＮ（予約）メッセージで応答するというものである。複数の受信器へのコネクションを確立するために、ＰＡＴＨメッセージは、中間交換ノードのルーティングテーブルに従ってルーティングされる。受信デバイスの能力が異なることにより、受信器は、コネクションを受容するために必要なリソースを指定する。しかし、ソースからデスティネーションまでのＰＡＴＨメッセージのルーティングパスは、逆向きのＲＥＳＥＲＶＡＴＩＯＮメッセージとは同じではない可能性がある。このため、ＲＳＶＰ復路において、逆のルーティングテーブルを提供するために、各中間交換ノードにテーブルを保守しておく必要がある。
【０００４】
ソースホストがリソースを予約するためにＰＡＴＨメッセージを送信すると、受信器は、マルチキャストセッションのためにリソースを予約したことをＲＥＳＥＲＶＡＴＩＯＮメッセージで応答する。ＲＳＶＰプロトコルにおける方式の１つは、マルチキャストセッションに対する個々のソースの情報を交換ノード（１個または複数）が保守することを要求する。さらに、ＲＳＶＰでは、送信器によって用いられるリフレッシュ期間を指定することが要求される。交換ノードは、指定されたリフレッシュ期間を、その交換ノードにおいてリソース予約を保守しようと試みる際のガイドラインとして使用する。さらに、各中間交換ノードにおけるリソースの予約を保つために、ＰＡＴＨおよびＲＥＳＥＲＶＡＴＩＯＮメッセージは、一定して（例えば、１００ｍｓごとに）交換されなければならない。しかし、残念ながら、受信ノードは、適当にリソースを予約するために連続して定期的にＲＥＳＥＲＶＡＴＩＯＮメッセージで応答することが要求される。
【０００５】
【発明が解決しようとする課題】
リソース予約のこの一定リフレッシュ方式は、パケットデータネットワークにおける動的ルーティングテーブル変化のような、マルチキャストグループにおける状態変化を考慮に入れるために用いられている。リソース予約の連続的リフレッシュによって、ルーティングテーブル変化により交換ノードに残された予約は、所定時間内にリフレッシュされないときにはフラッシュ（消去）される。残念ながら、一定リフレッシュ方式は、特にネットワークの端で非常に大量のメッセージを要求し、端の交換機にとって実時間処理の浪費であることが示されている。大量のメッセージ交換および実時間集約的な処理は、大規模なマルチキャストグループにとって非常に問題であり非効率的である。従って、従来技術には、ネットワークルーティングが交換ノードで変更されるとき、および、ネットワークにおける他の状態変化が起こるときにも、マルチキャストパスに沿って正しいリソース予約を効率的に保守することが必要とされている。
【０００６】
【課題を解決するための手段】
上記の問題点は、本発明によれば、送信ノードから受信通信デバイスまで、マルチキャストグループにおけるデータ通信を確立し保守する方法によって解決される。本発明の方法は、送信ノードから受信ノードへマルチキャストパスに沿って情報を送信し、送信器と受信通信デバイスの間でパスおよび予約のメッセージの一定の定期的交換を必要とすることなく、通信を保守するのに必要なリソースを予約する。さらに、本発明によれば、マルチキャストグループの状態の変化が観測されたときにも、マルチキャストパスに沿って正しいリソース予約が保守される。
【０００７】
特に、本発明の方法は、交換ノードの通信ネットワークによって相互接続されたマルチキャストグループを定義する複数の通信デバイスのうちから選択された通信デバイス間のデータ通信を確立し保守する方法であって、
マルチキャストグループの状態の変化がいつあったかを判定し、
通常は、マルチキャストグループの状態の変化がない場合に、交換ノードで実質的に連続して受信されるデータに応答して、受信通信デバイスのリソース予約を保守し、
マルチキャストグループの状態の変化があったという判定に応答して、データが実質的に連続して受信されている間であっても、受信通信デバイスのリソース予約を新しいリソース予約に変更する。
【０００８】
【発明の実施の形態】
図１に、複数の通信デバイス間のデータ通信を確立し保守する本発明の方法が実施されるコンピュータネットワークを示す。図示されている通信デバイスには、送信通信デバイス（送信ノード）３２が含まれる。送信ノード３２は、複数の受信通信デバイス（受信ノード）３６Ａ〜３６Ｄのうちから選択された受信ノードとの間で情報を交換する。送信ノード３２（「ソースノード」ともいう。）および受信ノード３６Ａ〜３６Ｄはマルチキャストグループ３０を定義する。マルチキャストグループ３０において、送信ノードは、交換ノード３４Ａ〜３４Ｄの通信ネットワーク３１によって複数の受信ノードと相互接続される。通信デバイス（３２，３６Ａ〜３６Ｄ）は、好ましくは、コンピュータに基づくデバイス（ホスト）であり、アプリケーションプログラムを実行して、他のデバイスとの間で、マルチメディア会議、電子メール、ファイル転送、ワールドワイドウェブ、インターネット電話およびリアルタイムインターネットファックスサービスのようなさまざまなタスクを実行する。
【０００９】
情報は、ホスト通信デバイス（送信ノード、受信ノード）間で、交換ノード３４Ａ〜３４Ｄのネットワーク３１と、交換ノードに通信デバイスを接続する複数の通信リンクを介して転送される。各通信デバイス（送信ノード、受信ノード）は、１個あるいは数個の交換ノード３４と接続される。好ましくは、ホスト通信デバイス３２，３６Ａ〜３６Ｄと交換ノード３４Ａ〜３４Ｄの間の通信は、非同期転送モード（ＡＴＭ）、フレームリレー、ファイバ分散データインタフェース（ＦＤＤＩ）などのような相互接続リンクを通じて行われるが、このようなデータ通信は、無線データ伝送を通じても適当に実行される。交換ノードの例には、ルータ、レイヤ３スイッチなどがあり、ネットワーク間のインタフェースを提供する。交換ノード３４Ａ〜３４Ｄは、パケットのデスティネーションアドレスに基づいてそのパケットの次のホップを決定する。ルータ／ブリッジのような交換ノードは、異なる媒体タイプ間の変換（例えば、イーサネットからフレームリレーへ）をサポートする。
【００１０】
情報は、通信が実行される方式を指定するあらかじめ選択された正しく定義されたルールあるいはプロトコルのセットに従ってマルチキャストグループ３０内で通信される。本発明は、ソース通信デバイス３２と１個以上の受信通信デバイス３６Ａ〜３６Ｄとの間の通信方法を改善する。特に、ネットワーク内のマルチキャスト通信に対して、受信デバイスの数が非常に多い場合に、本発明は、通信のパフォーマンスおよびスケーラビリティを向上させる。図１は、単一の送信ノード３２からマルチキャストグループ３０のマルチキャストデスティネーション（受信ノード）へのルーティングパスを示している。図１の交換ノード３４Ａは、マルチキャストツリーのための入リンク２０ならびに出リンク２１および２２を有する。交換ノード３４Ｂは、入リンク２２と、受信デバイス３６Ｂ1および３６Ｂ2を接続する出リンク２３および２４と、交換ノード３４Ｃに接続された出リンク２５とを有する。図１のソースノード３２からのマルチキャスト通信の場合、交換ノード３４Ｃは、入リンク２５と、受信ノード３６Ｃ1、３６Ｃ2および３６Ｃ3にそれぞれ接続された出リンク２６，２７，２８を有する。交換ノード３４Ｄは、リンク３３および２９を介して、それぞれ交換ノード３４Ｂおよび交換ノード３４Ｃに接続される。受信ノード３６Ｄは、関連する交換ノード３４Ｄに、リンク３５によって接続される。リンク２９、３３および３５は、図１では破線で表され、マルチキャスト通信における代替ルーティングパス、および、交換ノード３４Ｄや受信ノード３６Ｄがマルチキャストグループ３０に加入した状況またはマルチキャストグループ３０から離脱した状況を示している。
【００１１】
パケットデータネットワークのルーティング機能を提供するため、各交換ノードはルーティングテーブルを保守する。ルーティングテーブル８０の例を図３に示す。例示的なルーティングテーブル８０（図３）は、図１の交換ノード３４Ｂのルーティングテーブルの例である。リンクから情報のデータパケットを受信すると、交換ノード３４Ｂは、メモリに記憶されているルーティングテーブル（図３）を見て、デスティネーションに到達するためのパケットの次のホップを決定する。図１の交換ノード３４Ｂにおいて、例えば、デスティネーションが受信ノード３６Ａであるパケットがリンク２５から受信された場合、交換ノード３４Ｂは、ルーティングテーブル８０（図３）を調べ、デスティネーションノード３６ＡがネットワークＡ（８１）にあると判定する。この例では、デスティネーションノード３６Ａへのルーティングは、図３のルーティングテーブル８０のアドレスロケーション８２に示されているように、交換ノード３４Ａを介して実現される。データパケットは、交換ノード３４Ａ（図１）へ送られることになる。
【００１２】
同じ手順が、交換ノード３４Ｂに関連するネットワークＢのホスト３６Ｂ1、および３６Ｂ2、交換ノード３４Ｃに関連するネットワークＣのホスト３６Ｃ1、３６Ｃ2および３６Ｃ3、ならびに、交換ノード３４Ｄに関連するネットワークＤのホスト３６Ｄにも適用される。交換ノード３４Ｂのルーティングテーブル８０（図３）は、アドレスロケーション８３に、送信ホストデバイス３２に到達するためには、交換ノード３４Ｂはデータをロケーション８４に示されるように交換ノード３４Ａへルーティングすることを指定している。アドレスロケーション８６は、ロケーション８５に指定されたネットワークＢ上では情報が直送によりホスト通信デバイス３６Ｂ1および３６Ｂ2へ送られることを示す。アドレスロケーション８７に示されるネットワークＣ上のホストデバイス（すなわち、通信デバイス３６Ｃ1，３６Ｃ2，３６Ｃ3）への情報のルーティングは、ロケーション８８に示されるように、データを交換ノード３４Ｃへ送ることによって実行される。図３の例示的なルーティングテーブル８０は、ロケーション８９に、ネットワークＤ上のホスト通信デバイス３６Ｄに到達するためには、交換ノード３４Ｂはデータをロケーション９０に示されるように交換ノード３４Ｃにルーティングすることを指定している。続いてデータはリンク２９を通じて交換ノード３４Ｄ（図１）へルーティングされることになる。あるいは、交換ノード３４Ｂからのデータが受信ノード３６Ｄに到達するためには、リンク３３を通じて直接交換ノード３４Ｄへルーティングされることも可能である。
【００１３】
送信ノード３２が複数の受信器とのコネクションを確立し、これらのコネクションを有効に保守するためにリソースを予約すると、パスメッセージが、中間ノード３４Ａ，３４Ｂ，３４Ｃのルーティングテーブル８０に従ってルーティングされる。送信ノード３２（図１）から受信ノード３６Ａへのマルチキャストパスは、リンク２０および２１ならびに交換ノード３４Ａを通る。受信ノード３６Ｂ1へのマルチキャストルーティングパスは、リンク２０、２２および２３を通り、受信ノード３６Ｂ2へのパスは、リンク２０、２２および２４を通り、中間交換ノード３４Ａおよび３４Ｂが情報をルーティングする。同様に、ソース３２と受信ノード３６Ｃ1、３６Ｃ2および３６Ｃ3（図１）の間のマルチキャストルーティングパスは、交換ノード３４Ａ、リンク２２、交換ノード３４Ｂ、リンク２５、交換ノード３４Ｃを通り、交換ノード３４Ｃから、受信ノード３６Ｃ1、３６Ｃ2および３６Ｃ3へ、それぞれリンク２６、２７および２８を通じて到達する。相異なる受信ノードは異なる能力を有することが可能であるため、受信ノード３６Ａ〜３６Ｃ3は、コネクションを受容するために必要なリソースを指定する。サービス品質のためのリソース（例えば、ピークデータレート、最小管理単位、最大パケットサイズ）の予約は、好ましくは、受信ノード３６Ａ〜３６Ｃ3が、パス通信に必要なリソースを割り当てるためにその受信ノードへのマルチキャストパスを通り受信したパスメッセージと逆向きに予約メッセージを送るとによって行われる。
【００１４】
マルチキャストセッションのためのリソース予約を開始するためにパスおよび予約のメッセージが送信された後、通常は、交換ノード３４Ａ，３４Ｂ，３４Ｃでほぼ連続して受信されるデータに応答して、受信通信デバイス３６Ａ〜３６Ｃ3に対するリソース予約は保守される。一実施例では、マルチキャストグループに対する予約は、データが交換ノードを通って流れ続ける間、リフレッシュされる。非同期転送モード通信の場合、所望のサービス品質を達成するために、リソースは、仮想回線コネクションを通じて予約される。このリソースの予約を保証するために、通常のデータトラフィック中には、他のパスおよび予約のメッセージは不要である。データの送信が継続しておりさまざまなロケーションへルーティングされている間にも、マルチキャストグループの状態にある変化が起きたという判定に応答して、受信ノードに対するリソース予約は変更される。好ましくは、リソース予約変更が必要であるかどうかを判定するプロセスは、交換ノードのルーティングテーブルの変化、受信ノードのサービス品質が劣化したことの観測、または、新たな受信ノード３６Ｄ（図１）がマルチキャストグループ３０に加入したかあるいはマルチキャストグループ３０から離脱したことに応答してなされる。マルチキャストグループの状態のある変化（例えば、交換ノードルーティングテーブルの変化）に応じてリソース予約を修正することとともに、パスおよび予約のメッセージの連続的な定期的交換を大幅に少なくすることによって、本発明の改良された通信プロトコルは、ネットワーク動作のパフォーマンスおよび効率を大幅に改善する。
【００１５】
図２は、送信通信デバイス３２、交換ノード３４および受信通信デバイス３６に対するさまざまな定義された要素を含むブロック図である。本発明におけるデータ通信を確立し保守する方法において、送信ノード３２からマルチキャストパスを通り受信ノード３６へパスメッセージを送るステップは、マルチキャストセッションのためのリソース予約を開始したときに実行される。好ましくは、図１に示されるように、パスメッセージは、マルチキャスト方式の実行後に、このメッセージをルーティングするさまざまな中間交換ノード３４Ａ〜３４Ｄを通じて、複数の受信ノード３６Ａ〜３６Ｄへ送信される。
【００１６】
送信されたパスメッセージは、その後、受信通信デバイス３６（図２）で受信される。次に、受信通信デバイス３６は、交換ノード３４を通じて、送信通信デバイス３２へ予約メッセージを返送するステップを実行する。この予約メッセージは、受信されたパスメッセージとは逆の向きで同じ経路（リバースルート）を通じて送信されることが多い。図６に、パスメッセージ３１０および予約メッセージ３２０の例示的なデータパケットを示す。パスメッセージに含まれる情報は、好ましくは、（１）発信ノードを認証し（パス）メッセージの内容を照合するための暗号データ、（２）デスティネーションのトランスポートアドレスを記述するセッション識別情報、（３）受信された（パス）メッセージを転送したリソース予約の情報を有する最後のホップ、（４）作成者がメッセージをリフレッシュした時刻、および（５）保証されたサービスおよび制御された負荷のサービスの情報、である。予約メッセージは、好ましくは、パスメッセージに対する上記の１〜４の項目と同様の情報を含む。予約メッセージは、リソースを予約するスタイル（例えば、予約は異なる送信器のデータストリームを区別する必要があるか）に関する情報、リソースを予約する方法（例えば、ピークデータレート、最大パケットサイズなど）に関する情報、および、データストリーム（フロー）の識別も含むことが多い。予約メッセージは、マルチキャストセッション中に受信ノード３６があるタスクを実行するため、あるいは、正しい通信を保証するために、予約される必要があるシステムリソースを指示する。
【００１７】
送信ノード３２は、図２に示されるように、アプリケーション３８、ポリシー制御４０、受付制御４２、パケットスケジューラ４４、クラシファイア４６およびプロトコルシステムプロセス４８を含むさまざまな定義された要素を有する。プロトコルシステムプロセスは、本発明の改善されたプロトコルの実行を可能にするために、ホスト通信デバイス（送信ノード３２、受信ノード３６）と、交換ノードルータデバイス３４に常駐する要素である。図２に示されるように、受信通信デバイス３６は、プロトコルシステムプロセス要素５０を有し、交換ノード３４もまた、交換ノードのメモリに記憶されたプロトコルシステムプロセス５２を含む。送信ノード３２、受信ノード３６および交換ノード３４のそれぞれのプロセスシステムプロセスは、関連するポリシー制御、受付制御、パケットスケジューラおよびクラシファイアに情報を提供する。
【００１８】
プロトコルシステムプロセス要素は、リソース予約関連メッセージを処理しリソース予約動作のソフト状態を保守するソフトウェアエンティティである。各ノードにおいて、プロトコルシステムプロセス要素は、２つのローカル判断モジュール、すなわち、受付制御およびポリシー制御と通信する。送信ノード３２の受付制御４２（図２）は、関連するノード（デバイス）が要求されたサービス品質を満たすのに十分なリソースを有するかどうかを判断する判断モジュールである。ポリシー制御４０は、ユーザが特定のリソースの予約を行う管理権限を有するかどうかを判断する。両方の検査に合格した場合、プロトコルシステムプロセス４８は、所望のサービス品質を取得するようにパケットクラシファイア４６およびパケットスケジューラ４４のパラメータを設定する。いずれかの検査が不合格である場合、処理は、要求を発したアプリケーションプロセス３８へエラー通知を返す。パケットクラシファイア、パケットスケジューラおよび受付制御の要素をトラフィック制御という。
【００１９】
また、図２において、受信通信デバイス３６は、アプリケーションエンティティ６０、ポリシー制御６２、受付制御５４、パケットスケジューラ５６およびクラシファイア５８を有する。送信ノード３２にする上記の判断および検査は、受信ノード３６でも行われる。受信通信デバイス３６のプロトコルシステムプロセス５０は、ネットワーク内でデータメッセージを送受信する処理ステップを正しく実行するために、そのアプリケーションエンティティ６０、ポリシー制御６２、受付制御５４、パケットスケジューラ５６、クラシファイア５８と対話する。同様に、交換ノード３４のプロトコルシステムプロセス５２は、送信ノード、受信ノードまたは他の中間交換ノードからのメッセージを処理する際に、関連するクラシファイア６４、パケットスケジューラ６６、受付制御６８およびポリシー制御７０と通信する。マルチキャストネットワークにおけるリソース予約プロトコルおよびその動作に関してさらに詳細には、R. Braden et al., "Resource ReSerVation Protocol (RSVP) - Version 1 Function Specification", INternet Draft, June 1997、および、L. Zhang et al., "RSVP: A New Resource ReSerVation Protocol", IEEE Network Magazine, September 1993、に記載されている。
【００２０】
送信ノード３２が、マルチキャスト環境で特定のアプリケーションを実行しようとする場合、送信ノードのアプリケーションエンティティ３８は、リソース予約を要求する。好ましくは、アプリケーションエンティティ３８（図２）は、特定のタスクを実行するコンピュータベースの送信通信デバイス３２のソフトウェアエンティティである。アプリケーションエンティティ３８は、定義されたアプリケーションプログラムインタフェース（ＡＰＩ）のセットを呼び出して、送信ノードを登録し、リソース予約セッションを開始するためにデータストリーム特性およびリソース予約のための識別子を指定することによって、送信ノード３２のプロトコルシステムプロセス４８と通信する。送信ノード３２のプロトコルシステムプロセスエンティティ４８は、通信リンク７２を通じて、交換ノード３４のプロトコルシステムプロセスエンティティ５２へパスメッセージを送る。パスメッセージを受信すると、プロトコルシステムプロセス５２は、受信ノード３６または他の交換ノード３４Ｂ，３４Ｃ，３４Ｄへパスメッセージを送るため、および、後続の処理においてリソース予約機能を実行するために、交換ノードにおけるソフト状態のデータ構造体を作成する。送信ノード３２が、複数の受信器３６Ａ〜３６Ｄ（図１）へのコネクションを確立するためにリソース予約セッションを開始すると、パスメッセージが、中間交換ノードのルーティングプロトコルデーモン７１（図２）のメモリに記憶されているルーティングテーブル８０（図３）に従ってルーティングされる。
【００２１】
ソフト状態が、中間交換ノード３４（図２）に作成される。ソフト状態は、リソースが予約されることを求められたときに、ステータスおよびルーティングの情報が回復可能となるような、ネットワーク交換ノードに保守された状態のことである。ソフト状態は、交換ノードに設定され、パスメッセージの入リンクおよび出リンクを識別する。例えば、図２の交換ノード３４のソフト状態は、交換ノード３４で送受信されるパスメッセージに対して、リンク７２を入リンクとして識別し、リンク７４を出リンクとして識別することになる。受信されるパスメッセージの入リンク７２（図２）および転送されるパスメッセージの出リンク７４を識別するパス状態は、ネットワークのマルチキャストパスが通る各中間交換ノード３４に保守される。
【００２２】
次に、パスメッセージは、受信ノード３６のプロトコルシステムプロセスエンティティ５０に送られる。定義されたアプリケーションプログラムインタフェースのセットを使用して、受信ノードアプリケーションは、プロトコルシステムプロセスにターゲットデータストリームの識別子および特性を登録している。受信ノード３６のプロトコルシステムプロセス５０は、予約を行うこと、予約を修正すること、予約の指定を削除することなどのために、受信されたパスメッセージの情報を、受信ノードのパケットスケジューラ５６、クラシファイア５８、受付制御５４およびポリシー制御６２に送る。送信ノード３２が、リソースを予約するためにパスメッセージを送信すると、受信ノード３６は、マルチキャストセッションのためにリソースを予約する予約メッセージで応答する。予約メッセージは、受信ノード３６から、もとの経路の逆に、もとの送信ノード３２へ送られる。受信ノード３６からソースノード３２へ送られた予約メッセージは、交換ノード３４で処理され、交換ノードでパスメッセージを受信後にメモリに保守されているソフト状態に従って前のホップへ転送される。予約メッセージにおいて、受信ノード３６は、ビットレート、最大メッセージサイズ、ピークビットレートなどのようなリソースを予約しなければならない。
【００２３】
交換ノード３４は、予約メッセージを受信すると、交換ノードのトラフィック制御を通じて適当なリソースを確認しなければならない。受信ノード３６のプロトコルシステムプロセス５０は、予約メッセージを、マルチキャストパスを通じて、交換ノード３４の対応するプロトコルシステムプロセス５２へ送信する。交換ノード３４のプロトコルシステムプロセス５２は、受信ノード３６から要求されたリソースを予約するために、クラシファイア６４、パケットスケジューラ６６、受付制御６８およびポリシー制御７０と通信する。図１の送信器３２へのマルチキャストパスに沿った、受信器３６Ｃ1〜３６Ｃ3に対する交換ノード３４Ａ〜３４Ｃのような他の中間交換ノードも、同じ通信のプロセスに従う。ルーティングプロトコルデーモン７１（図２）は、さまざまなルーティングプロトコルを処理するとともにルーティングテーブルを保守するための、交換ノード３４における常駐システムソフトウェアである。ルーティングテーブルを保守する際に用いられるルーティングプロトコルの例には、いくつかのルーティングプロトコルのうちとりわけ、ＯＳＰＦ(Open Shortest Path First)およびルーティング情報プロトコル（ＲＩＰ(Routing Information Protocol)）がある。
【００２４】
交換ノード３４において、この交換ノードから送信ノード３２へ予約メッセージを送る必要があるかどうかについて判断がなされる。これは、上流の交換ノードにおいてさらに処理を行う必要がないときに、メッセージの数を減らすために実行される。予約は送られるべきであると判断された場合、交換ノード３４のプロトコルシステムプロセス５２（図２）から送信ノード３２のプロトコルシステムプロセス４８へ予約メッセージが送られる。図６に、本発明で用いられるのが好ましいパケット構造を示す。図示のように、パスメッセージ３１０のフォーマットは、共通ヘッダ、完全性、セッション、ＲＳＶＰホップ、時刻値、ポリシーデータ、送信器指定および広告指定に関連する情報を含む。予約メッセージ３２０は、共通ヘッダ、完全性、セッション、ＲＳＶＰホップ、時刻値、予約確認、スコープ、ポリシーデータ、スタイルおよびフロー指定に関連する情報を含む。図６のリソース保守メッセージ３３０は、共通ヘッダ、完全性、セッションとともに、保守指定を含む。リソース保守メッセージ３３０の動作についての詳細は図５を参照して後述する。
【００２５】
図４に、リソース予約の通常動作に関するパスおよび予約の通信のアルゴリズムステップを示す。ステップ１００で、送信ノード３２は、マルチキャストグループの受信ノード３６へパスメッセージを送る。パスメッセージ内のタイマ変数の特別の値が、タイマを無効にするために代入される。指定された値が設定されていることを認識することによって、リソースをリフレッシュするために多くのパスおよび予約のメッセージが絶えず交換されることが回避される。あるいは、一定の連続するメッセージ交換によるリソース予約のリフレッシュを停止させるために、パスメッセージ自体にタイムアウト値が指定されないようにすることも可能である。あるいは、既存の通信処理との下位互換性を維持するため、リソース予約をリフレッシュする際に用いられるタイマの無効化をシミュレートするのに適した非常に高い値にタイムアウト値を設定することも可能である。本発明では、送信ノードにおいて、リソース予約リフレッシュのための連続的メッセージ交換を要求するタイマが、追加のパスメッセージを送らないように無効化される。ステップ１０２（図４）で、交換ノード３４は、最初のパスメッセージを受信すると、ソフト状態情報を設定する。パスメッセージは、マルチキャストパスにおける次のホップへ送信される。パスメッセージは、単一の交換ノードから指定された受信ノード３６（図２）へ直接に、または、他の中間交換ノード３４Ａ〜３４Ｄ（図１）を介して、受信ノードに到達するまで送信される。ステップ１０４（図４）で、マルチキャストグループの受信ノード３６Ａ〜３６Ｄはパスメッセージを受信し、マルチキャスト通信のためのシステムリソースを予約するために、交換ノード３４Ａ〜３４Ｄの経路を介して送信ノード３２へ予約メッセージを返送する。
【００２６】
ステップ１０６（図４）で、各交換ノード３４のプロトコルシステムプロセス５２（図２）は予約メッセージを受信し、リソース予約指定をパケットスケジューラ６６およびクラシファイア６４へ送る。交換ノード３４は、前にステップ１０２においてパスメッセージを受信したときから保守されているソフト状態に基づいて送信ノード３２へ予約メッセージを送る。ステップ１０８（図４）で、受信ノード３６Ａ〜３６Ｄに対するリソースの予約は、各交換ノード３４Ａ〜３４Ｄ（図１）を流れるデータトラフィックに基づいてリフレッシュされる。マルチキャストグループの予約は、マルチキャストアプリケーションに対するデータトラフィックが交換ノード３４を通るごとにリフレッシュされる。例えば、非同期転送モード（ＡＴＭ）コネクションの場合、仮想回線コネクションは、リソース予約のためにパケットスケジューリングを行う１つの例である。こうして、受信ノード３６Ａ〜３６Ｄのリソース予約は通常、交換ノード３４Ａ〜３４Ｄ（図１）でほぼ連続的に受信されているデータトラフィックに応じて保守される。
【００２７】
受信通信デバイス３６のリソース予約は、好ましくは、マルチキャストグループの状態の変化があるまで保守される。仮想メモリを処理する際の最長時間未使用（ＬＲＵ(least recently used)）方式のような仮想メモリで用いられるページ置換アルゴリズムや、交換ノードにおけるリソース予約の状態を更新するその他の関連するアプローチは、好ましくは、リソース予約の管理を保守する。交換ノード３４（図２）を通るデータフローが存在する場合、パケットスケジューラ６６およびパケットクラシファイア６４は、データの指定を参照する。これにより、予約の状態は、最近にアクセスされたことを示す状態フィールドで選択的にマークされることが可能となる。新たな予約が要求された場合、アクセスされていない予約がリストから削除される。好ましくは、通常のデータトラフィック中には、本発明のプロトコルを用いたデータ通信アプリケーションに対するリソースの予約を保証するために追加のパスおよび予約のメッセージは不要である。
【００２８】
図５に、マルチキャストグループの状態が変化したと判断された場合に、通信ネットワークにおけるマルチキャストグループがマルチキャストパスにおける正しいリソース予約を保守するためのアルゴリズムステップを示す。ルーティングテーブル変化の場合、または、受信ノードがマルチキャストグループに加入したかもしくはマルチキャストグループから離脱した場合、ルーティングプロトコルデーモン７１（図２）とプロトコルシステムプロセス５２の間に存在するインタフェースが、その状態変化を処理する。ルーティングプロトコルデーモン７１は常に、ルーティング情報とマルチキャストグループ情報を、他の交換ノードあるいは通信デバイス３２，３６と交換している。ルーティングプロトコルデーモン７１は、リソース予約プロトコルの一部としてマルチキャストグループの状態の変化をプロトコルシステムプロセス５２に通知するよう要求される。好ましくは、マルチキャストグループに加入する、または、マルチキャストグループから離脱する受信通信デバイス３６Ｄ（図１）は、リソース予約のプロセスを保証するために、リソース保守メッセージ３３０（図６）を送信する。ルーティングプロトコルデーモン７１（図２）は、マルチキャストグループの状態の変化が起きたかどうかを判断する。
【００２９】
ステップ２００（図５）で、リソース保守メッセージが、ある交換ノードのプロトコルシステムプロセスから、所望のデスティネーションを送信ノード３２として、別の交換ノードへ送られる。リソース保守メッセージ３３０（図６）は、マルチキャストグループの状態の変化があったと判定されたときに交換ノードのルーティングテーブルに定義されている経路に基づくルーティングパスに沿って送信される。好ましくは、リソース保守メッセージがたどる経路は、さまざまな交換ノードのルーティングプロトコルデーモン７１（図２）のメモリに記憶されているルーティングテーブルによって定義されるルーティングパスである。リソース保守メッセージは、さらにメッセージをルーティングする必要がなくなるまで、このルーティングパスに沿ってさまざまな交換ノードへルーティングされる。必要があれば、リソース保守メッセージは、送信ノード３２に到達するまでルーティングパスに沿ってルーティングされる。マルチキャストグループの状態に変化が起きたという判定に応じて、リソース保守メッセージは、リソース予約の保守をマークするために、マルチキャストデータ通信アプリケーションを開始した送信通信デバイス３２へ送信される。リソース保守メッセージは、以下の３つの条件のもとで送信される。
【００３０】
１．ルーティングテーブル８０（図３）が交換ノードで変更された場合。ルーティングテーブルが、リンクの追加もしくは削除により、または、リンク障害のために、変更された場合、このルーティングテーブル変化はルーティングプロトコルデーモン７１（図２）から各交換ノード３４のプロトコルシステムプロセスソフトウェア５２へさらに処理を行うために送信される。
【００３１】
２．サービス品質劣化（例えば、遅延の増大、データパケットの損失などによる）が受信ノード３６で観測あるいは検出された場合。
【００３２】
３．新たな受信ノードが、マルチキャストグループに加入したか、または、マルチキャストグループから離脱した場合。
【００３３】
新たなノードがグループに加入したという条件に対しては、新たな交換ノード（例えば図１の交換ノード３４Ｄ）がマルチキャストグループにいつ追加されたかを判定するステップが実行される。特に、通常動作において、前にグループになかった別の新たな受信ノード３４Ｄ（図１）がマルチキャストグループに加入しようとしていると識別された場合に、新たな交換ノード３６Ｄ（図１）がグループに追加される。この新しい受信ノード３６Ｄは、（図１でリンク３５により示されるように））交換ノード３４Ｄに接続される。この交換ノード３４Ｄもまた、マルチキャストグループに新たに加わったノードである。
【００３４】
交換ノード３４Ｄがマルチキャストグループ３０に追加されるのは、受信ノード３６Ｄはグループにおいて交換ノード３４Ｄの最初の受信ノードであるためである。受信ノード３６Ｄは、アプリケーションプロセス６０から、マルチキャストグループへの加入を示すレポートを送信する。交換ノード３４Ｄは、マルチキャストグループのゲートウェイとして作用して、ルーティングプロトコルデーモン７１（図２）を通じて、既存のグループへの加入に関する新しい情報を、他の交換ノードと交換しなければならない。既存のプロトコルに従って、受信ノードのアプリケーションプロセスと交換ノードのルーティングプロトコルデーモンはいずれも、マルチキャストグループへの加入を通知される。受信ノードにおいてマルチキャスト機能をサポートするソフトウェアは、好ましくは、ＲＦＣ(request for comment)１１１２に規定されたマルチキャスト通信を保守するアプリケーションへのインタフェースを提供する（S. Deering, "Host Extensions for IP Multicasting", Network Working Group, Request For Comment: 1112 (August 1989)、参照）。
【００３５】
あるいは、マルチキャストグループへの別の交換ノード３４Ｄ（図１）の追加は、マルチキャストグループへの加入がアプリケーションソフトウェアから指示されたことに基づいて、行われる可能性もある。マルチキャストをサポートするソフトウェアは、ネットワークを通じて、この指示をルーティングプロトコルデーモンに提供しなければならない。
【００３６】
マルチキャストグループにおける変化は、１つの交換ノード３４Ｄ（図１）がマルチキャストグループから削除されるときにも生じる。ＲＦＣ１１１２では、アプリケーションは、マルチキャストグループを離脱する通信デバイスのインタフェースをサポートし、受信ノードの拡張インターネットプロトコル（ＩＰ）マルチキャストサービスに通知する。好ましくは、このインタフェースは、通信デバイス３６Ｄがマルチキャストグループを離脱したときに、リソース予約プロトコルに提供される。
【００３７】
グループからの交換ノード３４Ｄの削除は、グループの交換ノードに関連するリンクにおいてリンク障害が識別されたために起こることがある。例えば、リンク障害が図１のリンク２９および３３で生じた場合、交換ノード３４Ｄは残りのマルチキャストグループから削除される。リンク障害は、プロトコルの下位のデータリンク層で判定される。ネットワーク内の通常動作のもとでは、グループからの交換ノードの削除は、特定の交換ノードに接続された受信ノードがマルチキャストグループから離脱するあるいは削除されるという指示に応じて判断される。例えば、受信ノード３６Ｄ（図１）がマルチキャストグループから離脱するあるいは削除される場合、交換ノード３４Ｄはこれに従ってグループから削除される。特定の交換ノード３４Ｄに接続されたすべての受信通信デバイス３６Ｄがマルチキャストグループから削除される場合、好ましくは、その特定交換ノード３４Ｄもまたグループから離脱する。
【００３８】
ステップ２００（図５）で、好ましくはこのような条件のもとで、リソース保守メッセージが、デスティネーションを送信ノード３６として、上流の中間交換ノードへ送信される。ステップ２０２（図５）で、交換ノード３４は、リソース保守メッセージを検査する。交換ノード３４は、パスのテーブルと、そのテーブルに関連するタイマを保守している。特定のパスが保守リストに加わった場合、新たに到着したリソース保守メッセージは、上流の交換ノードおよび送信ノードへの過大なメッセージフローを回避するために、廃棄される。リソース保守リストに保守されているタイマは、上流へのリソース保守メッセージをスクリーニングするために用いられる。リソース保守メッセージは、好ましくは、タイマが満了したときに上流へ送られる。例えば、ルーティングテーブル変化通知を受信した後、交換ノード３４のプロトコルシステムプロセス５２は、影響されるソフト状態を検査し、リソース保守メッセージをマルチキャスト送信ノードへ送る。特に、リソース保守メッセージを受信した交換ノード３４Ａ〜３４Ｄ（図１）は、このメッセージを検査して、実行中のデータ通信アプリケーションのためにマルチキャストパスを通じてリソース保守メッセージを送信する必要があるかどうかを判断する。交換ノード３４のプロトコルシステムプロセスエンティティ５２（図２）は、リソース予約が保守中であるとマークする。リソース保守メッセージを検査した後、ステップ２０４（図５）で、交換ノードのプロトコルシステムプロセスは、マルチキャストグループの状態の変化が識別されたことによる新たなリソース保守が必要であるかどうかを判断する。
【００３９】
新たな保守が必要でない場合、ステップ２０６（図５）で、新たな保守が必要でないと判定された交換ノードで、リソース保守メッセージは廃棄される。リソース保守メッセージが廃棄されると、そのルーティングパスに沿っての保守あるいは修復の処理は終了する。さらに保守が必要であると判断された場合、ステップ２０８（図５）で、プロトコルシステムプロセスは、保守ソフト状態を作成する。特に、ルーティングテーブルによるルーティングパスに沿った交換ノード３６において保守ソフト状態を作成するステップは、修復あるいは保守が必要であるという判定に応じて実行される。マルチキャストパス内の交換ノード３４が保守中である場合、そのマルチキャストグループは「保守中」とマークされ、交換ノードはリソース保守メッセージをマルチキャストグループの送信通信デバイス３２へ送る。その後、ステップ２１０（図５）で、リソース保守メッセージは、そのパスを通じて、指定された交換ノードへ、あるいは、送信ノード３２へ、転送される。リソース保守メッセージがその交換ノードあるいは送信ノードで受信されると、処理はステップ２１２に進む。その後、処理は、リソース予約動作のためにパスおよび予約の通信を開始するため、図４のステップ１００に進む。パスメッセージは、適当な保守が完了した後、送信ノード３２から選択的に送信される。
【００４０】
以上の詳細な説明は、マルチキャスト環境におけるデータ通信の方法に関するものである。この方法について、特定のハードウェアやソフトウェアに言及せずに説明した。その代わりに、この方法について、当業者が、入手可能なまたは好ましいハードウェアやソフトウェアに容易に適合させることができるように記載した。本発明はマルチキャスト環境における通信の一方法に関するものであるが、当業者には理解されるように、本発明の方法は、他のさまざまな環境にも適用可能である。
【００４１】
【発明の効果】
以上述べたごとく、本発明によれば、送信器と受信通信デバイスの間でパスおよび予約のメッセージの一定の定期的交換を必要とすることなく、通信を保守するのに必要なリソースを予約する。さらに、本発明によれば、マルチキャストグループの状態の変化が観測されたときにも、マルチキャストパスに沿って正しいリソース予約が保守される。
【図面の簡単な説明】
【図１】本発明の方法が実施される、交換ノード、送信ノードおよび受信ノードのコンピュータネットワークの構造の図である。
【図２】本発明の方法が実施される送信ノード、交換ノードおよび受信ノードのブロック図である。
【図３】図１の交換ノード３４Ｂのルーティングテーブルの図である。
【図４】リソース予約のためのパスおよび予約の通信のために実行されるステップを説明する流れ図である。
【図５】マルチキャストグループの状態の変化が生じたときにリソース予約を保守するために実行されるステップを説明する流れ図である。
【図６】本発明の方法のパスメッセージ、予約メッセージおよびリソース保守メッセージの例示的な情報フォーマットの図である。
【符号の説明】
３０ マルチキャストグループ
３１ 通信ネットワーク
３２ 送信通信デバイス（送信ノード）
３４ 交換ノード
３６ 受信通信デバイス（受信ノード）
３８ アプリケーション
４０ ポリシー制御
４２ 受付制御
４４ パケットスケジューラ
４６ クラシファイア
４８ プロトコルシステムプロセス
５０ プロトコルシステムプロセス
５２ プロトコルシステムプロセス
５４ 受付制御
５６ パケットスケジューラ
５８ クラシファイア
６０ アプリケーションエンティティ
６２ ポリシー制御
６４ クラシファイア
６６ パケットスケジューラ
６８ 受付制御
７０ ポリシー制御
７１ ルーティングプロトコルデーモン
８０ ルーティングテーブル
３１０ パスメッセージ
３２０ 予約メッセージ
３３０ 予約保守メッセージ
【発明の属する技術分野】
本発明は、ネットワークにおけるデバイス間の通信方法に関し、特に、ネットワークのマルチキャスト通信プロトコルに関する。
【０００２】
【従来の技術】
通信プロトコルは、一般にコンピュータネットワークにおけるデバイス間のデータ伝送のフォーマットおよびタイミングに関する規則または手続きのセットを提供する。コンピュータネットワークはホストデバイスから形成される。ホストデバイスは、互いに情報を送信し合い、交換要素すなわち交換ノードの通信ネットワークによって接続される。マルチキャストは、メッセージがネットワーク内のホストのサブセットによって受信されるような通信の形式である。ポイント・ツー・マルチポイントのマルチキャスト環境では、ソースホストデバイスすなわちソースノードがメッセージを生成して複数のデスティネーションすなわち受信ホストとそのメッセージを通信する。マルチキャストは、マルチポイント・ツー・マルチポイントの場合もある。この場合、ネットワーク内の送信ノードのサブセットが複数の受信ノードへ情報を送信する。
【０００３】
マルチキャスト環境における通信フレームワークを提供するためにマルチキャストプロトコルが開発されてきた。リソース予約プロトコル（通常「ＲＳＶＰ」という。）は、マルチキャストコネクションにおけるリソース予約を行うために用いられる。ＲＳＶＰは、マルチキャストプロトコルを支援するように設計されている。しかし、ＲＳＶＰは、特に、受信ホストデバイスの数が非常の多いときには非効率的であり問題があることが分かっている。ＲＳＶＰの基本動作は、ソースからデスティネーションへＰＡＴＨ（パス）メッセージを送った後、デスティネーションがＲＥＳＥＲＶＡＴＩＯＮ（予約）メッセージで応答するというものである。複数の受信器へのコネクションを確立するために、ＰＡＴＨメッセージは、中間交換ノードのルーティングテーブルに従ってルーティングされる。受信デバイスの能力が異なることにより、受信器は、コネクションを受容するために必要なリソースを指定する。しかし、ソースからデスティネーションまでのＰＡＴＨメッセージのルーティングパスは、逆向きのＲＥＳＥＲＶＡＴＩＯＮメッセージとは同じではない可能性がある。このため、ＲＳＶＰ復路において、逆のルーティングテーブルを提供するために、各中間交換ノードにテーブルを保守しておく必要がある。
【０００４】
ソースホストがリソースを予約するためにＰＡＴＨメッセージを送信すると、受信器は、マルチキャストセッションのためにリソースを予約したことをＲＥＳＥＲＶＡＴＩＯＮメッセージで応答する。ＲＳＶＰプロトコルにおける方式の１つは、マルチキャストセッションに対する個々のソースの情報を交換ノード（１個または複数）が保守することを要求する。さらに、ＲＳＶＰでは、送信器によって用いられるリフレッシュ期間を指定することが要求される。交換ノードは、指定されたリフレッシュ期間を、その交換ノードにおいてリソース予約を保守しようと試みる際のガイドラインとして使用する。さらに、各中間交換ノードにおけるリソースの予約を保つために、ＰＡＴＨおよびＲＥＳＥＲＶＡＴＩＯＮメッセージは、一定して（例えば、１００ｍｓごとに）交換されなければならない。しかし、残念ながら、受信ノードは、適当にリソースを予約するために連続して定期的にＲＥＳＥＲＶＡＴＩＯＮメッセージで応答することが要求される。
【０００５】
【発明が解決しようとする課題】
リソース予約のこの一定リフレッシュ方式は、パケットデータネットワークにおける動的ルーティングテーブル変化のような、マルチキャストグループにおける状態変化を考慮に入れるために用いられている。リソース予約の連続的リフレッシュによって、ルーティングテーブル変化により交換ノードに残された予約は、所定時間内にリフレッシュされないときにはフラッシュ（消去）される。残念ながら、一定リフレッシュ方式は、特にネットワークの端で非常に大量のメッセージを要求し、端の交換機にとって実時間処理の浪費であることが示されている。大量のメッセージ交換および実時間集約的な処理は、大規模なマルチキャストグループにとって非常に問題であり非効率的である。従って、従来技術には、ネットワークルーティングが交換ノードで変更されるとき、および、ネットワークにおける他の状態変化が起こるときにも、マルチキャストパスに沿って正しいリソース予約を効率的に保守することが必要とされている。
【０００６】
【課題を解決するための手段】
上記の問題点は、本発明によれば、送信ノードから受信通信デバイスまで、マルチキャストグループにおけるデータ通信を確立し保守する方法によって解決される。本発明の方法は、送信ノードから受信ノードへマルチキャストパスに沿って情報を送信し、送信器と受信通信デバイスの間でパスおよび予約のメッセージの一定の定期的交換を必要とすることなく、通信を保守するのに必要なリソースを予約する。さらに、本発明によれば、マルチキャストグループの状態の変化が観測されたときにも、マルチキャストパスに沿って正しいリソース予約が保守される。
【０００７】
特に、本発明の方法は、交換ノードの通信ネットワークによって相互接続されたマルチキャストグループを定義する複数の通信デバイスのうちから選択された通信デバイス間のデータ通信を確立し保守する方法であって、
マルチキャストグループの状態の変化がいつあったかを判定し、
通常は、マルチキャストグループの状態の変化がない場合に、交換ノードで実質的に連続して受信されるデータに応答して、受信通信デバイスのリソース予約を保守し、
マルチキャストグループの状態の変化があったという判定に応答して、データが実質的に連続して受信されている間であっても、受信通信デバイスのリソース予約を新しいリソース予約に変更する。
【０００８】
【発明の実施の形態】
図１に、複数の通信デバイス間のデータ通信を確立し保守する本発明の方法が実施されるコンピュータネットワークを示す。図示されている通信デバイスには、送信通信デバイス（送信ノード）３２が含まれる。送信ノード３２は、複数の受信通信デバイス（受信ノード）３６Ａ〜３６Ｄのうちから選択された受信ノードとの間で情報を交換する。送信ノード３２（「ソースノード」ともいう。）および受信ノード３６Ａ〜３６Ｄはマルチキャストグループ３０を定義する。マルチキャストグループ３０において、送信ノードは、交換ノード３４Ａ〜３４Ｄの通信ネットワーク３１によって複数の受信ノードと相互接続される。通信デバイス（３２，３６Ａ〜３６Ｄ）は、好ましくは、コンピュータに基づくデバイス（ホスト）であり、アプリケーションプログラムを実行して、他のデバイスとの間で、マルチメディア会議、電子メール、ファイル転送、ワールドワイドウェブ、インターネット電話およびリアルタイムインターネットファックスサービスのようなさまざまなタスクを実行する。
【０００９】
情報は、ホスト通信デバイス（送信ノード、受信ノード）間で、交換ノード３４Ａ〜３４Ｄのネットワーク３１と、交換ノードに通信デバイスを接続する複数の通信リンクを介して転送される。各通信デバイス（送信ノード、受信ノード）は、１個あるいは数個の交換ノード３４と接続される。好ましくは、ホスト通信デバイス３２，３６Ａ〜３６Ｄと交換ノード３４Ａ〜３４Ｄの間の通信は、非同期転送モード（ＡＴＭ）、フレームリレー、ファイバ分散データインタフェース（ＦＤＤＩ）などのような相互接続リンクを通じて行われるが、このようなデータ通信は、無線データ伝送を通じても適当に実行される。交換ノードの例には、ルータ、レイヤ３スイッチなどがあり、ネットワーク間のインタフェースを提供する。交換ノード３４Ａ〜３４Ｄは、パケットのデスティネーションアドレスに基づいてそのパケットの次のホップを決定する。ルータ／ブリッジのような交換ノードは、異なる媒体タイプ間の変換（例えば、イーサネットからフレームリレーへ）をサポートする。
【００１０】
情報は、通信が実行される方式を指定するあらかじめ選択された正しく定義されたルールあるいはプロトコルのセットに従ってマルチキャストグループ３０内で通信される。本発明は、ソース通信デバイス３２と１個以上の受信通信デバイス３６Ａ〜３６Ｄとの間の通信方法を改善する。特に、ネットワーク内のマルチキャスト通信に対して、受信デバイスの数が非常に多い場合に、本発明は、通信のパフォーマンスおよびスケーラビリティを向上させる。図１は、単一の送信ノード３２からマルチキャストグループ３０のマルチキャストデスティネーション（受信ノード）へのルーティングパスを示している。図１の交換ノード３４Ａは、マルチキャストツリーのための入リンク２０ならびに出リンク２１および２２を有する。交換ノード３４Ｂは、入リンク２２と、受信デバイス３６Ｂ1および３６Ｂ2を接続する出リンク２３および２４と、交換ノード３４Ｃに接続された出リンク２５とを有する。図１のソースノード３２からのマルチキャスト通信の場合、交換ノード３４Ｃは、入リンク２５と、受信ノード３６Ｃ1、３６Ｃ2および３６Ｃ3にそれぞれ接続された出リンク２６，２７，２８を有する。交換ノード３４Ｄは、リンク３３および２９を介して、それぞれ交換ノード３４Ｂおよび交換ノード３４Ｃに接続される。受信ノード３６Ｄは、関連する交換ノード３４Ｄに、リンク３５によって接続される。リンク２９、３３および３５は、図１では破線で表され、マルチキャスト通信における代替ルーティングパス、および、交換ノード３４Ｄや受信ノード３６Ｄがマルチキャストグループ３０に加入した状況またはマルチキャストグループ３０から離脱した状況を示している。
【００１１】
パケットデータネットワークのルーティング機能を提供するため、各交換ノードはルーティングテーブルを保守する。ルーティングテーブル８０の例を図３に示す。例示的なルーティングテーブル８０（図３）は、図１の交換ノード３４Ｂのルーティングテーブルの例である。リンクから情報のデータパケットを受信すると、交換ノード３４Ｂは、メモリに記憶されているルーティングテーブル（図３）を見て、デスティネーションに到達するためのパケットの次のホップを決定する。図１の交換ノード３４Ｂにおいて、例えば、デスティネーションが受信ノード３６Ａであるパケットがリンク２５から受信された場合、交換ノード３４Ｂは、ルーティングテーブル８０（図３）を調べ、デスティネーションノード３６ＡがネットワークＡ（８１）にあると判定する。この例では、デスティネーションノード３６Ａへのルーティングは、図３のルーティングテーブル８０のアドレスロケーション８２に示されているように、交換ノード３４Ａを介して実現される。データパケットは、交換ノード３４Ａ（図１）へ送られることになる。
【００１２】
同じ手順が、交換ノード３４Ｂに関連するネットワークＢのホスト３６Ｂ1、および３６Ｂ2、交換ノード３４Ｃに関連するネットワークＣのホスト３６Ｃ1、３６Ｃ2および３６Ｃ3、ならびに、交換ノード３４Ｄに関連するネットワークＤのホスト３６Ｄにも適用される。交換ノード３４Ｂのルーティングテーブル８０（図３）は、アドレスロケーション８３に、送信ホストデバイス３２に到達するためには、交換ノード３４Ｂはデータをロケーション８４に示されるように交換ノード３４Ａへルーティングすることを指定している。アドレスロケーション８６は、ロケーション８５に指定されたネットワークＢ上では情報が直送によりホスト通信デバイス３６Ｂ1および３６Ｂ2へ送られることを示す。アドレスロケーション８７に示されるネットワークＣ上のホストデバイス（すなわち、通信デバイス３６Ｃ1，３６Ｃ2，３６Ｃ3）への情報のルーティングは、ロケーション８８に示されるように、データを交換ノード３４Ｃへ送ることによって実行される。図３の例示的なルーティングテーブル８０は、ロケーション８９に、ネットワークＤ上のホスト通信デバイス３６Ｄに到達するためには、交換ノード３４Ｂはデータをロケーション９０に示されるように交換ノード３４Ｃにルーティングすることを指定している。続いてデータはリンク２９を通じて交換ノード３４Ｄ（図１）へルーティングされることになる。あるいは、交換ノード３４Ｂからのデータが受信ノード３６Ｄに到達するためには、リンク３３を通じて直接交換ノード３４Ｄへルーティングされることも可能である。
【００１３】
送信ノード３２が複数の受信器とのコネクションを確立し、これらのコネクションを有効に保守するためにリソースを予約すると、パスメッセージが、中間ノード３４Ａ，３４Ｂ，３４Ｃのルーティングテーブル８０に従ってルーティングされる。送信ノード３２（図１）から受信ノード３６Ａへのマルチキャストパスは、リンク２０および２１ならびに交換ノード３４Ａを通る。受信ノード３６Ｂ1へのマルチキャストルーティングパスは、リンク２０、２２および２３を通り、受信ノード３６Ｂ2へのパスは、リンク２０、２２および２４を通り、中間交換ノード３４Ａおよび３４Ｂが情報をルーティングする。同様に、ソース３２と受信ノード３６Ｃ1、３６Ｃ2および３６Ｃ3（図１）の間のマルチキャストルーティングパスは、交換ノード３４Ａ、リンク２２、交換ノード３４Ｂ、リンク２５、交換ノード３４Ｃを通り、交換ノード３４Ｃから、受信ノード３６Ｃ1、３６Ｃ2および３６Ｃ3へ、それぞれリンク２６、２７および２８を通じて到達する。相異なる受信ノードは異なる能力を有することが可能であるため、受信ノード３６Ａ〜３６Ｃ3は、コネクションを受容するために必要なリソースを指定する。サービス品質のためのリソース（例えば、ピークデータレート、最小管理単位、最大パケットサイズ）の予約は、好ましくは、受信ノード３６Ａ〜３６Ｃ3が、パス通信に必要なリソースを割り当てるためにその受信ノードへのマルチキャストパスを通り受信したパスメッセージと逆向きに予約メッセージを送るとによって行われる。
【００１４】
マルチキャストセッションのためのリソース予約を開始するためにパスおよび予約のメッセージが送信された後、通常は、交換ノード３４Ａ，３４Ｂ，３４Ｃでほぼ連続して受信されるデータに応答して、受信通信デバイス３６Ａ〜３６Ｃ3に対するリソース予約は保守される。一実施例では、マルチキャストグループに対する予約は、データが交換ノードを通って流れ続ける間、リフレッシュされる。非同期転送モード通信の場合、所望のサービス品質を達成するために、リソースは、仮想回線コネクションを通じて予約される。このリソースの予約を保証するために、通常のデータトラフィック中には、他のパスおよび予約のメッセージは不要である。データの送信が継続しておりさまざまなロケーションへルーティングされている間にも、マルチキャストグループの状態にある変化が起きたという判定に応答して、受信ノードに対するリソース予約は変更される。好ましくは、リソース予約変更が必要であるかどうかを判定するプロセスは、交換ノードのルーティングテーブルの変化、受信ノードのサービス品質が劣化したことの観測、または、新たな受信ノード３６Ｄ（図１）がマルチキャストグループ３０に加入したかあるいはマルチキャストグループ３０から離脱したことに応答してなされる。マルチキャストグループの状態のある変化（例えば、交換ノードルーティングテーブルの変化）に応じてリソース予約を修正することとともに、パスおよび予約のメッセージの連続的な定期的交換を大幅に少なくすることによって、本発明の改良された通信プロトコルは、ネットワーク動作のパフォーマンスおよび効率を大幅に改善する。
【００１５】
図２は、送信通信デバイス３２、交換ノード３４および受信通信デバイス３６に対するさまざまな定義された要素を含むブロック図である。本発明におけるデータ通信を確立し保守する方法において、送信ノード３２からマルチキャストパスを通り受信ノード３６へパスメッセージを送るステップは、マルチキャストセッションのためのリソース予約を開始したときに実行される。好ましくは、図１に示されるように、パスメッセージは、マルチキャスト方式の実行後に、このメッセージをルーティングするさまざまな中間交換ノード３４Ａ〜３４Ｄを通じて、複数の受信ノード３６Ａ〜３６Ｄへ送信される。
【００１６】
送信されたパスメッセージは、その後、受信通信デバイス３６（図２）で受信される。次に、受信通信デバイス３６は、交換ノード３４を通じて、送信通信デバイス３２へ予約メッセージを返送するステップを実行する。この予約メッセージは、受信されたパスメッセージとは逆の向きで同じ経路（リバースルート）を通じて送信されることが多い。図６に、パスメッセージ３１０および予約メッセージ３２０の例示的なデータパケットを示す。パスメッセージに含まれる情報は、好ましくは、（１）発信ノードを認証し（パス）メッセージの内容を照合するための暗号データ、（２）デスティネーションのトランスポートアドレスを記述するセッション識別情報、（３）受信された（パス）メッセージを転送したリソース予約の情報を有する最後のホップ、（４）作成者がメッセージをリフレッシュした時刻、および（５）保証されたサービスおよび制御された負荷のサービスの情報、である。予約メッセージは、好ましくは、パスメッセージに対する上記の１〜４の項目と同様の情報を含む。予約メッセージは、リソースを予約するスタイル（例えば、予約は異なる送信器のデータストリームを区別する必要があるか）に関する情報、リソースを予約する方法（例えば、ピークデータレート、最大パケットサイズなど）に関する情報、および、データストリーム（フロー）の識別も含むことが多い。予約メッセージは、マルチキャストセッション中に受信ノード３６があるタスクを実行するため、あるいは、正しい通信を保証するために、予約される必要があるシステムリソースを指示する。
【００１７】
送信ノード３２は、図２に示されるように、アプリケーション３８、ポリシー制御４０、受付制御４２、パケットスケジューラ４４、クラシファイア４６およびプロトコルシステムプロセス４８を含むさまざまな定義された要素を有する。プロトコルシステムプロセスは、本発明の改善されたプロトコルの実行を可能にするために、ホスト通信デバイス（送信ノード３２、受信ノード３６）と、交換ノードルータデバイス３４に常駐する要素である。図２に示されるように、受信通信デバイス３６は、プロトコルシステムプロセス要素５０を有し、交換ノード３４もまた、交換ノードのメモリに記憶されたプロトコルシステムプロセス５２を含む。送信ノード３２、受信ノード３６および交換ノード３４のそれぞれのプロセスシステムプロセスは、関連するポリシー制御、受付制御、パケットスケジューラおよびクラシファイアに情報を提供する。
【００１８】
プロトコルシステムプロセス要素は、リソース予約関連メッセージを処理しリソース予約動作のソフト状態を保守するソフトウェアエンティティである。各ノードにおいて、プロトコルシステムプロセス要素は、２つのローカル判断モジュール、すなわち、受付制御およびポリシー制御と通信する。送信ノード３２の受付制御４２（図２）は、関連するノード（デバイス）が要求されたサービス品質を満たすのに十分なリソースを有するかどうかを判断する判断モジュールである。ポリシー制御４０は、ユーザが特定のリソースの予約を行う管理権限を有するかどうかを判断する。両方の検査に合格した場合、プロトコルシステムプロセス４８は、所望のサービス品質を取得するようにパケットクラシファイア４６およびパケットスケジューラ４４のパラメータを設定する。いずれかの検査が不合格である場合、処理は、要求を発したアプリケーションプロセス３８へエラー通知を返す。パケットクラシファイア、パケットスケジューラおよび受付制御の要素をトラフィック制御という。
【００１９】
また、図２において、受信通信デバイス３６は、アプリケーションエンティティ６０、ポリシー制御６２、受付制御５４、パケットスケジューラ５６およびクラシファイア５８を有する。送信ノード３２にする上記の判断および検査は、受信ノード３６でも行われる。受信通信デバイス３６のプロトコルシステムプロセス５０は、ネットワーク内でデータメッセージを送受信する処理ステップを正しく実行するために、そのアプリケーションエンティティ６０、ポリシー制御６２、受付制御５４、パケットスケジューラ５６、クラシファイア５８と対話する。同様に、交換ノード３４のプロトコルシステムプロセス５２は、送信ノード、受信ノードまたは他の中間交換ノードからのメッセージを処理する際に、関連するクラシファイア６４、パケットスケジューラ６６、受付制御６８およびポリシー制御７０と通信する。マルチキャストネットワークにおけるリソース予約プロトコルおよびその動作に関してさらに詳細には、R. Braden et al., "Resource ReSerVation Protocol (RSVP) - Version 1 Function Specification", INternet Draft, June 1997、および、L. Zhang et al., "RSVP: A New Resource ReSerVation Protocol", IEEE Network Magazine, September 1993、に記載されている。
【００２０】
送信ノード３２が、マルチキャスト環境で特定のアプリケーションを実行しようとする場合、送信ノードのアプリケーションエンティティ３８は、リソース予約を要求する。好ましくは、アプリケーションエンティティ３８（図２）は、特定のタスクを実行するコンピュータベースの送信通信デバイス３２のソフトウェアエンティティである。アプリケーションエンティティ３８は、定義されたアプリケーションプログラムインタフェース（ＡＰＩ）のセットを呼び出して、送信ノードを登録し、リソース予約セッションを開始するためにデータストリーム特性およびリソース予約のための識別子を指定することによって、送信ノード３２のプロトコルシステムプロセス４８と通信する。送信ノード３２のプロトコルシステムプロセスエンティティ４８は、通信リンク７２を通じて、交換ノード３４のプロトコルシステムプロセスエンティティ５２へパスメッセージを送る。パスメッセージを受信すると、プロトコルシステムプロセス５２は、受信ノード３６または他の交換ノード３４Ｂ，３４Ｃ，３４Ｄへパスメッセージを送るため、および、後続の処理においてリソース予約機能を実行するために、交換ノードにおけるソフト状態のデータ構造体を作成する。送信ノード３２が、複数の受信器３６Ａ〜３６Ｄ（図１）へのコネクションを確立するためにリソース予約セッションを開始すると、パスメッセージが、中間交換ノードのルーティングプロトコルデーモン７１（図２）のメモリに記憶されているルーティングテーブル８０（図３）に従ってルーティングされる。
【００２１】
ソフト状態が、中間交換ノード３４（図２）に作成される。ソフト状態は、リソースが予約されることを求められたときに、ステータスおよびルーティングの情報が回復可能となるような、ネットワーク交換ノードに保守された状態のことである。ソフト状態は、交換ノードに設定され、パスメッセージの入リンクおよび出リンクを識別する。例えば、図２の交換ノード３４のソフト状態は、交換ノード３４で送受信されるパスメッセージに対して、リンク７２を入リンクとして識別し、リンク７４を出リンクとして識別することになる。受信されるパスメッセージの入リンク７２（図２）および転送されるパスメッセージの出リンク７４を識別するパス状態は、ネットワークのマルチキャストパスが通る各中間交換ノード３４に保守される。
【００２２】
次に、パスメッセージは、受信ノード３６のプロトコルシステムプロセスエンティティ５０に送られる。定義されたアプリケーションプログラムインタフェースのセットを使用して、受信ノードアプリケーションは、プロトコルシステムプロセスにターゲットデータストリームの識別子および特性を登録している。受信ノード３６のプロトコルシステムプロセス５０は、予約を行うこと、予約を修正すること、予約の指定を削除することなどのために、受信されたパスメッセージの情報を、受信ノードのパケットスケジューラ５６、クラシファイア５８、受付制御５４およびポリシー制御６２に送る。送信ノード３２が、リソースを予約するためにパスメッセージを送信すると、受信ノード３６は、マルチキャストセッションのためにリソースを予約する予約メッセージで応答する。予約メッセージは、受信ノード３６から、もとの経路の逆に、もとの送信ノード３２へ送られる。受信ノード３６からソースノード３２へ送られた予約メッセージは、交換ノード３４で処理され、交換ノードでパスメッセージを受信後にメモリに保守されているソフト状態に従って前のホップへ転送される。予約メッセージにおいて、受信ノード３６は、ビットレート、最大メッセージサイズ、ピークビットレートなどのようなリソースを予約しなければならない。
【００２３】
交換ノード３４は、予約メッセージを受信すると、交換ノードのトラフィック制御を通じて適当なリソースを確認しなければならない。受信ノード３６のプロトコルシステムプロセス５０は、予約メッセージを、マルチキャストパスを通じて、交換ノード３４の対応するプロトコルシステムプロセス５２へ送信する。交換ノード３４のプロトコルシステムプロセス５２は、受信ノード３６から要求されたリソースを予約するために、クラシファイア６４、パケットスケジューラ６６、受付制御６８およびポリシー制御７０と通信する。図１の送信器３２へのマルチキャストパスに沿った、受信器３６Ｃ1〜３６Ｃ3に対する交換ノード３４Ａ〜３４Ｃのような他の中間交換ノードも、同じ通信のプロセスに従う。ルーティングプロトコルデーモン７１（図２）は、さまざまなルーティングプロトコルを処理するとともにルーティングテーブルを保守するための、交換ノード３４における常駐システムソフトウェアである。ルーティングテーブルを保守する際に用いられるルーティングプロトコルの例には、いくつかのルーティングプロトコルのうちとりわけ、ＯＳＰＦ(Open Shortest Path First)およびルーティング情報プロトコル（ＲＩＰ(Routing Information Protocol)）がある。
【００２４】
交換ノード３４において、この交換ノードから送信ノード３２へ予約メッセージを送る必要があるかどうかについて判断がなされる。これは、上流の交換ノードにおいてさらに処理を行う必要がないときに、メッセージの数を減らすために実行される。予約は送られるべきであると判断された場合、交換ノード３４のプロトコルシステムプロセス５２（図２）から送信ノード３２のプロトコルシステムプロセス４８へ予約メッセージが送られる。図６に、本発明で用いられるのが好ましいパケット構造を示す。図示のように、パスメッセージ３１０のフォーマットは、共通ヘッダ、完全性、セッション、ＲＳＶＰホップ、時刻値、ポリシーデータ、送信器指定および広告指定に関連する情報を含む。予約メッセージ３２０は、共通ヘッダ、完全性、セッション、ＲＳＶＰホップ、時刻値、予約確認、スコープ、ポリシーデータ、スタイルおよびフロー指定に関連する情報を含む。図６のリソース保守メッセージ３３０は、共通ヘッダ、完全性、セッションとともに、保守指定を含む。リソース保守メッセージ３３０の動作についての詳細は図５を参照して後述する。
【００２５】
図４に、リソース予約の通常動作に関するパスおよび予約の通信のアルゴリズムステップを示す。ステップ１００で、送信ノード３２は、マルチキャストグループの受信ノード３６へパスメッセージを送る。パスメッセージ内のタイマ変数の特別の値が、タイマを無効にするために代入される。指定された値が設定されていることを認識することによって、リソースをリフレッシュするために多くのパスおよび予約のメッセージが絶えず交換されることが回避される。あるいは、一定の連続するメッセージ交換によるリソース予約のリフレッシュを停止させるために、パスメッセージ自体にタイムアウト値が指定されないようにすることも可能である。あるいは、既存の通信処理との下位互換性を維持するため、リソース予約をリフレッシュする際に用いられるタイマの無効化をシミュレートするのに適した非常に高い値にタイムアウト値を設定することも可能である。本発明では、送信ノードにおいて、リソース予約リフレッシュのための連続的メッセージ交換を要求するタイマが、追加のパスメッセージを送らないように無効化される。ステップ１０２（図４）で、交換ノード３４は、最初のパスメッセージを受信すると、ソフト状態情報を設定する。パスメッセージは、マルチキャストパスにおける次のホップへ送信される。パスメッセージは、単一の交換ノードから指定された受信ノード３６（図２）へ直接に、または、他の中間交換ノード３４Ａ〜３４Ｄ（図１）を介して、受信ノードに到達するまで送信される。ステップ１０４（図４）で、マルチキャストグループの受信ノード３６Ａ〜３６Ｄはパスメッセージを受信し、マルチキャスト通信のためのシステムリソースを予約するために、交換ノード３４Ａ〜３４Ｄの経路を介して送信ノード３２へ予約メッセージを返送する。
【００２６】
ステップ１０６（図４）で、各交換ノード３４のプロトコルシステムプロセス５２（図２）は予約メッセージを受信し、リソース予約指定をパケットスケジューラ６６およびクラシファイア６４へ送る。交換ノード３４は、前にステップ１０２においてパスメッセージを受信したときから保守されているソフト状態に基づいて送信ノード３２へ予約メッセージを送る。ステップ１０８（図４）で、受信ノード３６Ａ〜３６Ｄに対するリソースの予約は、各交換ノード３４Ａ〜３４Ｄ（図１）を流れるデータトラフィックに基づいてリフレッシュされる。マルチキャストグループの予約は、マルチキャストアプリケーションに対するデータトラフィックが交換ノード３４を通るごとにリフレッシュされる。例えば、非同期転送モード（ＡＴＭ）コネクションの場合、仮想回線コネクションは、リソース予約のためにパケットスケジューリングを行う１つの例である。こうして、受信ノード３６Ａ〜３６Ｄのリソース予約は通常、交換ノード３４Ａ〜３４Ｄ（図１）でほぼ連続的に受信されているデータトラフィックに応じて保守される。
【００２７】
受信通信デバイス３６のリソース予約は、好ましくは、マルチキャストグループの状態の変化があるまで保守される。仮想メモリを処理する際の最長時間未使用（ＬＲＵ(least recently used)）方式のような仮想メモリで用いられるページ置換アルゴリズムや、交換ノードにおけるリソース予約の状態を更新するその他の関連するアプローチは、好ましくは、リソース予約の管理を保守する。交換ノード３４（図２）を通るデータフローが存在する場合、パケットスケジューラ６６およびパケットクラシファイア６４は、データの指定を参照する。これにより、予約の状態は、最近にアクセスされたことを示す状態フィールドで選択的にマークされることが可能となる。新たな予約が要求された場合、アクセスされていない予約がリストから削除される。好ましくは、通常のデータトラフィック中には、本発明のプロトコルを用いたデータ通信アプリケーションに対するリソースの予約を保証するために追加のパスおよび予約のメッセージは不要である。
【００２８】
図５に、マルチキャストグループの状態が変化したと判断された場合に、通信ネットワークにおけるマルチキャストグループがマルチキャストパスにおける正しいリソース予約を保守するためのアルゴリズムステップを示す。ルーティングテーブル変化の場合、または、受信ノードがマルチキャストグループに加入したかもしくはマルチキャストグループから離脱した場合、ルーティングプロトコルデーモン７１（図２）とプロトコルシステムプロセス５２の間に存在するインタフェースが、その状態変化を処理する。ルーティングプロトコルデーモン７１は常に、ルーティング情報とマルチキャストグループ情報を、他の交換ノードあるいは通信デバイス３２，３６と交換している。ルーティングプロトコルデーモン７１は、リソース予約プロトコルの一部としてマルチキャストグループの状態の変化をプロトコルシステムプロセス５２に通知するよう要求される。好ましくは、マルチキャストグループに加入する、または、マルチキャストグループから離脱する受信通信デバイス３６Ｄ（図１）は、リソース予約のプロセスを保証するために、リソース保守メッセージ３３０（図６）を送信する。ルーティングプロトコルデーモン７１（図２）は、マルチキャストグループの状態の変化が起きたかどうかを判断する。
【００２９】
ステップ２００（図５）で、リソース保守メッセージが、ある交換ノードのプロトコルシステムプロセスから、所望のデスティネーションを送信ノード３２として、別の交換ノードへ送られる。リソース保守メッセージ３３０（図６）は、マルチキャストグループの状態の変化があったと判定されたときに交換ノードのルーティングテーブルに定義されている経路に基づくルーティングパスに沿って送信される。好ましくは、リソース保守メッセージがたどる経路は、さまざまな交換ノードのルーティングプロトコルデーモン７１（図２）のメモリに記憶されているルーティングテーブルによって定義されるルーティングパスである。リソース保守メッセージは、さらにメッセージをルーティングする必要がなくなるまで、このルーティングパスに沿ってさまざまな交換ノードへルーティングされる。必要があれば、リソース保守メッセージは、送信ノード３２に到達するまでルーティングパスに沿ってルーティングされる。マルチキャストグループの状態に変化が起きたという判定に応じて、リソース保守メッセージは、リソース予約の保守をマークするために、マルチキャストデータ通信アプリケーションを開始した送信通信デバイス３２へ送信される。リソース保守メッセージは、以下の３つの条件のもとで送信される。
【００３０】
１．ルーティングテーブル８０（図３）が交換ノードで変更された場合。ルーティングテーブルが、リンクの追加もしくは削除により、または、リンク障害のために、変更された場合、このルーティングテーブル変化はルーティングプロトコルデーモン７１（図２）から各交換ノード３４のプロトコルシステムプロセスソフトウェア５２へさらに処理を行うために送信される。
【００３１】
２．サービス品質劣化（例えば、遅延の増大、データパケットの損失などによる）が受信ノード３６で観測あるいは検出された場合。
【００３２】
３．新たな受信ノードが、マルチキャストグループに加入したか、または、マルチキャストグループから離脱した場合。
【００３３】
新たなノードがグループに加入したという条件に対しては、新たな交換ノード（例えば図１の交換ノード３４Ｄ）がマルチキャストグループにいつ追加されたかを判定するステップが実行される。特に、通常動作において、前にグループになかった別の新たな受信ノード３４Ｄ（図１）がマルチキャストグループに加入しようとしていると識別された場合に、新たな交換ノード３６Ｄ（図１）がグループに追加される。この新しい受信ノード３６Ｄは、（図１でリンク３５により示されるように））交換ノード３４Ｄに接続される。この交換ノード３４Ｄもまた、マルチキャストグループに新たに加わったノードである。
【００３４】
交換ノード３４Ｄがマルチキャストグループ３０に追加されるのは、受信ノード３６Ｄはグループにおいて交換ノード３４Ｄの最初の受信ノードであるためである。受信ノード３６Ｄは、アプリケーションプロセス６０から、マルチキャストグループへの加入を示すレポートを送信する。交換ノード３４Ｄは、マルチキャストグループのゲートウェイとして作用して、ルーティングプロトコルデーモン７１（図２）を通じて、既存のグループへの加入に関する新しい情報を、他の交換ノードと交換しなければならない。既存のプロトコルに従って、受信ノードのアプリケーションプロセスと交換ノードのルーティングプロトコルデーモンはいずれも、マルチキャストグループへの加入を通知される。受信ノードにおいてマルチキャスト機能をサポートするソフトウェアは、好ましくは、ＲＦＣ(request for comment)１１１２に規定されたマルチキャスト通信を保守するアプリケーションへのインタフェースを提供する（S. Deering, "Host Extensions for IP Multicasting", Network Working Group, Request For Comment: 1112 (August 1989)、参照）。
【００３５】
あるいは、マルチキャストグループへの別の交換ノード３４Ｄ（図１）の追加は、マルチキャストグループへの加入がアプリケーションソフトウェアから指示されたことに基づいて、行われる可能性もある。マルチキャストをサポートするソフトウェアは、ネットワークを通じて、この指示をルーティングプロトコルデーモンに提供しなければならない。
【００３６】
マルチキャストグループにおける変化は、１つの交換ノード３４Ｄ（図１）がマルチキャストグループから削除されるときにも生じる。ＲＦＣ１１１２では、アプリケーションは、マルチキャストグループを離脱する通信デバイスのインタフェースをサポートし、受信ノードの拡張インターネットプロトコル（ＩＰ）マルチキャストサービスに通知する。好ましくは、このインタフェースは、通信デバイス３６Ｄがマルチキャストグループを離脱したときに、リソース予約プロトコルに提供される。
【００３７】
グループからの交換ノード３４Ｄの削除は、グループの交換ノードに関連するリンクにおいてリンク障害が識別されたために起こることがある。例えば、リンク障害が図１のリンク２９および３３で生じた場合、交換ノード３４Ｄは残りのマルチキャストグループから削除される。リンク障害は、プロトコルの下位のデータリンク層で判定される。ネットワーク内の通常動作のもとでは、グループからの交換ノードの削除は、特定の交換ノードに接続された受信ノードがマルチキャストグループから離脱するあるいは削除されるという指示に応じて判断される。例えば、受信ノード３６Ｄ（図１）がマルチキャストグループから離脱するあるいは削除される場合、交換ノード３４Ｄはこれに従ってグループから削除される。特定の交換ノード３４Ｄに接続されたすべての受信通信デバイス３６Ｄがマルチキャストグループから削除される場合、好ましくは、その特定交換ノード３４Ｄもまたグループから離脱する。
【００３８】
ステップ２００（図５）で、好ましくはこのような条件のもとで、リソース保守メッセージが、デスティネーションを送信ノード３６として、上流の中間交換ノードへ送信される。ステップ２０２（図５）で、交換ノード３４は、リソース保守メッセージを検査する。交換ノード３４は、パスのテーブルと、そのテーブルに関連するタイマを保守している。特定のパスが保守リストに加わった場合、新たに到着したリソース保守メッセージは、上流の交換ノードおよび送信ノードへの過大なメッセージフローを回避するために、廃棄される。リソース保守リストに保守されているタイマは、上流へのリソース保守メッセージをスクリーニングするために用いられる。リソース保守メッセージは、好ましくは、タイマが満了したときに上流へ送られる。例えば、ルーティングテーブル変化通知を受信した後、交換ノード３４のプロトコルシステムプロセス５２は、影響されるソフト状態を検査し、リソース保守メッセージをマルチキャスト送信ノードへ送る。特に、リソース保守メッセージを受信した交換ノード３４Ａ〜３４Ｄ（図１）は、このメッセージを検査して、実行中のデータ通信アプリケーションのためにマルチキャストパスを通じてリソース保守メッセージを送信する必要があるかどうかを判断する。交換ノード３４のプロトコルシステムプロセスエンティティ５２（図２）は、リソース予約が保守中であるとマークする。リソース保守メッセージを検査した後、ステップ２０４（図５）で、交換ノードのプロトコルシステムプロセスは、マルチキャストグループの状態の変化が識別されたことによる新たなリソース保守が必要であるかどうかを判断する。
【００３９】
新たな保守が必要でない場合、ステップ２０６（図５）で、新たな保守が必要でないと判定された交換ノードで、リソース保守メッセージは廃棄される。リソース保守メッセージが廃棄されると、そのルーティングパスに沿っての保守あるいは修復の処理は終了する。さらに保守が必要であると判断された場合、ステップ２０８（図５）で、プロトコルシステムプロセスは、保守ソフト状態を作成する。特に、ルーティングテーブルによるルーティングパスに沿った交換ノード３６において保守ソフト状態を作成するステップは、修復あるいは保守が必要であるという判定に応じて実行される。マルチキャストパス内の交換ノード３４が保守中である場合、そのマルチキャストグループは「保守中」とマークされ、交換ノードはリソース保守メッセージをマルチキャストグループの送信通信デバイス３２へ送る。その後、ステップ２１０（図５）で、リソース保守メッセージは、そのパスを通じて、指定された交換ノードへ、あるいは、送信ノード３２へ、転送される。リソース保守メッセージがその交換ノードあるいは送信ノードで受信されると、処理はステップ２１２に進む。その後、処理は、リソース予約動作のためにパスおよび予約の通信を開始するため、図４のステップ１００に進む。パスメッセージは、適当な保守が完了した後、送信ノード３２から選択的に送信される。
【００４０】
以上の詳細な説明は、マルチキャスト環境におけるデータ通信の方法に関するものである。この方法について、特定のハードウェアやソフトウェアに言及せずに説明した。その代わりに、この方法について、当業者が、入手可能なまたは好ましいハードウェアやソフトウェアに容易に適合させることができるように記載した。本発明はマルチキャスト環境における通信の一方法に関するものであるが、当業者には理解されるように、本発明の方法は、他のさまざまな環境にも適用可能である。
【００４１】
【発明の効果】
以上述べたごとく、本発明によれば、送信器と受信通信デバイスの間でパスおよび予約のメッセージの一定の定期的交換を必要とすることなく、通信を保守するのに必要なリソースを予約する。さらに、本発明によれば、マルチキャストグループの状態の変化が観測されたときにも、マルチキャストパスに沿って正しいリソース予約が保守される。
【図面の簡単な説明】
【図１】本発明の方法が実施される、交換ノード、送信ノードおよび受信ノードのコンピュータネットワークの構造の図である。
【図２】本発明の方法が実施される送信ノード、交換ノードおよび受信ノードのブロック図である。
【図３】図１の交換ノード３４Ｂのルーティングテーブルの図である。
【図４】リソース予約のためのパスおよび予約の通信のために実行されるステップを説明する流れ図である。
【図５】マルチキャストグループの状態の変化が生じたときにリソース予約を保守するために実行されるステップを説明する流れ図である。
【図６】本発明の方法のパスメッセージ、予約メッセージおよびリソース保守メッセージの例示的な情報フォーマットの図である。
【符号の説明】
３０ マルチキャストグループ
３１ 通信ネットワーク
３２ 送信通信デバイス（送信ノード）
３４ 交換ノード
３６ 受信通信デバイス（受信ノード）
３８ アプリケーション
４０ ポリシー制御
４２ 受付制御
４４ パケットスケジューラ
４６ クラシファイア
４８ プロトコルシステムプロセス
５０ プロトコルシステムプロセス
５２ プロトコルシステムプロセス
５４ 受付制御
５６ パケットスケジューラ
５８ クラシファイア
６０ アプリケーションエンティティ
６２ ポリシー制御
６４ クラシファイア
６６ パケットスケジューラ
６８ 受付制御
７０ ポリシー制御
７１ ルーティングプロトコルデーモン
８０ ルーティングテーブル
３１０ パスメッセージ
３２０ 予約メッセージ
３３０ 予約保守メッセージ
Claims (22)
- 交換ノードを有する通信ネットワークによって相互接続されたマルチキャストグループを構成する複数の通信デバイスのうちの選択された通信デバイス間のデータ通信を確立し保守する方法において、
（ａ） 前記マルチキャストグループの状態が変化した時点を判断するステップと、
（ｂ） 前記交換ノードで受信されたデータに応答して、予約メッセージおよびパスメッセージの伝送により開始された、該マルチキャストパスに沿って配置された受信通信デバイスのリソース予約を、前記マルチキャストグループの状態の変化があるまで、保守するステップと、
（ｃ） 前記マルチキャストグループの状態が変化したという判断に応答して、データが受信されていても、前記マルチキャストパスに沿って配置された各受信通信デバイスのリソース予約を新しいリソース予約に変更するステップと
を有することを特徴とするデータ通信方法。 - 前記ステップ（ａ）は、
（ａ１） 交換ノードが前記マルチキャストグループに追加された時点を判断するステップ
を含むことを特徴とする請求項１に記載の方法。 - 前記ステップ（ａ１）は、
（ａ１．１） 前記追加された交換ノードに接続された別の受信通信デバイスが前記マルチキャストグループに加入したことを識別するステップ
を含むことを特徴とする請求項２に記載の方法。 - 前記ステップ（ａ１）は、
（ａ１．２） 前記別の受信通信デバイスから前記追加された交換ノードへ前記マルチキャストグループへの加入を示すレポートを送るステップ
を含むことを特徴とする請求項３に記載の方法。 - 前記ステップ（ａ）は、
（ａ２） 交換ノードが前記マルチキャストグループから削除された時 点を判断するステップ
を含むことを特徴とする請求項１に記載の方法。 - 前記ステップ（ａ２）は、
（ａ２．１） リンク障害が起きたかどうかを判断するステップ
を含むことを特徴とする請求項５に記載の方法。 - 前記ステップ（ａ２）は、
（ａ２．２） 受信通信デバイスが前記マルチキャストグループから離脱したかどうかを判断するステップ
を含むことを特徴とする請求項５に記載の方法。 - 前記ステップ（ａ）は、
（ａ３） 前記マルチキャストパスに沿って配置された受信通信デバイスにおいて、サービス品質の劣化があった時点を検出するステップ
を含むことを特徴とする請求項１に記載の方法。 - 前記ステップ（ａ）は、
（ａ４） 交換ノードのルーティングテーブルの変化があったかどうかを判断するステップ
を含むことを特徴とする請求項１に記載の方法。 - 前記ステップ（ｂ）は、
（ｂ１） 送信通信デバイスから受信通信デバイスへ前記マルチキャストパスを通じて、前記パスメッセージを送るステップ
を含むことを特徴とする請求項１に記載の方法。 - （ｂ２） 追加のパスメッセージを送らないようにタイマを無効にするステップをさらに有することを特徴とする請求項１０に記載の方法。
- （ｂ３） 前記パスメッセージにタイムアウト値が指定されないようにするステップをさらに有することを特徴とする請求項１０に記載の方法。
- （ｂ４） リソース予約をリフレッシュするためのタイマの無効化をシミュレートするように、前記パスメッセージ内のタイムアウト値を指定するステップをさらに有することを特徴とする請求項１０に記載の方法。
- 前記ステップ（ｂ）は、
（ｂ５） 前記パスメッセージの入リンクおよび出リンクを識別するように交換ノードにおいて保守ソフト状態を設定するステップ
を含むことを特徴とする請求項１０に記載の方法。 - 前記ステップ（ｂ）は、
（ｂ６） 前記マルチキャストパスに沿って配置された前記各受信通信デバイスで前記パスメッセージを受信するステップと、
（ｂ７） 前記マルチキャストパスに沿って配置された前記各受信通信デバイスから前記送信通信デバイスへ交換ノードを通じて予約メッセージを送信するステップと
を含むことを特徴とする請求項１４に記載の方法。 - （ｂ８） 各交換ノードにおいてプロトコルシステムプロセスを実行するステップをさらに有し、
前記ステップ（ｂ）は、
（ｂ９） 交換ノードのプロトコルシステムプロセスにおいて、予約メッセージを受信するステップと、
（ｂ１０） 前記プロトコルシステムプロセスから各交換ノードのパケットスケジューラおよびクラシファイアへリソース予約指定情報を送るステップと
を含むことを特徴とする請求項１４に記載の方法。 - 前記ステップ（ｃ）は、
（ｃ１） 前記マルチキャストグループの状態が変化したという判断に応答して、リソース予約の保守を指示するようにリソース保守メッセージを送信するステップ
を含むことを特徴とする請求項１に記載の方法。 - （ｃ２） 交換ノードに記憶されているルーティングテーブルによって定義されるルーティングパスに沿って前記リソース保守メッセージをルーティングするステップをさらに有することを特徴とする請求項１７に記載の方法。
- （ｃ３） 前記リソース保守メッセージを受信した交換ノードにおいて前記リソース保守メッセージを検査するステップと、
（ｃ４） 前記マルチキャストグループの状態の変化により前記ルーティングパスに沿っての保守が必要であるかどうかを判断するステップと
をさらに有することを特徴とする請求項１８に記載の方法。 - （ｃ５） 保守が必要であるという判断に応答して、前記ルーティングパスに沿った交換ノードにおいて保守ソフト状態を作成するステップをさらに有することを特徴とする請求項１９に記載の方法。
- （ｃ６） 前記リソース保守メッセージを送信通信デバイスへ送るステップをさらに有することを特徴とする請求項２０に記載の方法。
- （ｃ７） 前記送信通信デバイスにおいて前記リソース保守メッセージを処理するステップと、
（ｃ８） 前記送信通信デバイスにおいて前記リソース保守メッセージを受信した後、前記送信通信デバイスからパスメッセージを送信するステップとをさらに有することを特徴とする請求項２１に記載の方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/940251 | 1997-09-30 | ||
| US08/940,251 US6058113A (en) | 1997-09-30 | 1997-09-30 | Method for enhancing resource reservation communication |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11163854A JPH11163854A (ja) | 1999-06-18 |
| JP3701476B2 true JP3701476B2 (ja) | 2005-09-28 |
Family
ID=25474500
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP27511898A Expired - Fee Related JP3701476B2 (ja) | 1997-09-30 | 1998-09-29 | データ通信方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6058113A (ja) |
| JP (1) | JP3701476B2 (ja) |
Families Citing this family (67)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB9603582D0 (en) | 1996-02-20 | 1996-04-17 | Hewlett Packard Co | Method of accessing service resource items that are for use in a telecommunications system |
| SE9704020L (sv) * | 1997-11-04 | 1999-04-26 | Telia Ab | Metod för resursoptimering i ett data- och telekommunikationssystem |
| JP2000032048A (ja) * | 1998-07-14 | 2000-01-28 | Fujitsu Ltd | ネットワーク装置 |
| US6580722B1 (en) * | 1998-08-21 | 2003-06-17 | Sun Microsystems, Inc. | Bypassing topological restrictions with tunnels |
| US7239618B1 (en) * | 1998-12-11 | 2007-07-03 | Lucent Technologies Inc. | Single phase local mobility scheme for wireless access to packet-based networks |
| US6570851B1 (en) * | 1999-07-01 | 2003-05-27 | Nokia Telecommunications Oy | Receiver driven differentiated service marking for unicast and multicast applications |
| US6771661B1 (en) * | 1999-07-21 | 2004-08-03 | Cisco Technology, Inc. | Apparatus and methods for providing event-based data communications device configuration |
| US7136387B2 (en) * | 1999-08-09 | 2006-11-14 | Mci, Llc | Method of and system for providing quality of service in IP telephony |
| JP3636948B2 (ja) * | 1999-10-05 | 2005-04-06 | 株式会社日立製作所 | ネットワークシステム |
| US7106756B1 (en) | 1999-10-12 | 2006-09-12 | Mci, Inc. | Customer resources policy control for IP traffic delivery |
| US6765927B1 (en) * | 1999-10-20 | 2004-07-20 | Alcatel | RSVP proxy service for communication network |
| US7139838B1 (en) * | 1999-10-21 | 2006-11-21 | Nortel Networks Limited | Apparatus and method of distributing routing information |
| US6366577B1 (en) * | 1999-11-05 | 2002-04-02 | Mci Worldcom, Inc. | Method for providing IP telephony with QoS using end-to-end RSVP signaling |
| US7369536B2 (en) * | 1999-11-02 | 2008-05-06 | Verizon Business Global Llc | Method for providing IP telephony with QoS using end-to-end RSVP signaling |
| US6970930B1 (en) * | 1999-11-05 | 2005-11-29 | Mci, Inc. | Method and system of providing differentiated services |
| EP1230806A4 (en) * | 1999-11-05 | 2004-03-17 | Mci Worldcom Inc | METHOD FOR PROVIDING AN INTERNET PROTOCOL TELEPHONE SERVICE WITH A QUALITY OF SERVICE USING POINT TO POINT RSVP PROTOCOL SIGNALING |
| FI20000138A (fi) * | 2000-01-24 | 2001-07-25 | Nokia Networks Oy | Palvelun laadun varaaminen langattomasa tietoliikennejärjestelmässä |
| US7054938B2 (en) * | 2000-02-10 | 2006-05-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for network service reservations over wireless access networks |
| US7058730B2 (en) * | 2000-05-05 | 2006-06-06 | Fujitsu Limited | Unique address space and method for a transport network |
| US6693909B1 (en) | 2000-05-05 | 2004-02-17 | Fujitsu Network Communications, Inc. | Method and system for transporting traffic in a packet-switched network |
| US7133403B1 (en) | 2000-05-05 | 2006-11-07 | Fujitsu Limited | Transport network and method |
| US7385917B1 (en) | 2000-05-05 | 2008-06-10 | Fujitsu Limited | Method and system for providing a protection path for connectionless signals in a telecommunications network |
| US6775229B1 (en) | 2000-05-05 | 2004-08-10 | Fujitsu Network Communications, Inc. | Method and system for providing a protection path for connection-oriented signals in a telecommunications network |
| US7047176B2 (en) * | 2000-05-05 | 2006-05-16 | Fujitsu Limited | Method and system for hardware simulation |
| US7173912B2 (en) * | 2000-05-05 | 2007-02-06 | Fujitsu Limited | Method and system for modeling and advertising asymmetric topology of a node in a transport network |
| US7075927B2 (en) * | 2000-05-05 | 2006-07-11 | Fujitsu Limited | Method and system for quality of service (QoS) support in a packet-switched network |
| US7151773B1 (en) | 2000-05-05 | 2006-12-19 | Fujitsu Limited | System and method for connectionless/connection oriented signal transport |
| US6515966B1 (en) * | 2000-05-05 | 2003-02-04 | Fujitsu Network Communications, Inc. | System and method for application object transport |
| US6732182B1 (en) * | 2000-05-17 | 2004-05-04 | Worldcom, Inc. | Method for generating packet loss report by a data coordinator in a multicast data transmission network utilizing a group shortest path tree |
| US7082521B1 (en) | 2000-08-24 | 2006-07-25 | Veritas Operating Corporation | User interface for dynamic computing environment using allocateable resources |
| US7278142B2 (en) | 2000-08-24 | 2007-10-02 | Veritas Operating Corporation | Dynamic computing environment using remotely allocable resources |
| US7065637B1 (en) | 2000-08-24 | 2006-06-20 | Veritas Operating Corporating | System for configuration of dynamic computing environments using a visual interface |
| US7043724B2 (en) | 2000-09-14 | 2006-05-09 | Veritas Operating Corporation | System and services for handling computing environments as documents |
| US7571238B1 (en) * | 2000-10-18 | 2009-08-04 | Nortel Networks Limited | Authorizing communication services |
| US7027412B2 (en) * | 2000-11-10 | 2006-04-11 | Veritas Operating Corporation | System for dynamic provisioning of secure, scalable, and extensible networked computer environments |
| US8631103B1 (en) | 2000-11-10 | 2014-01-14 | Symantec Operating Corporation | Web-based administration of remote computing environments via signals sent via the internet |
| US20020107939A1 (en) * | 2001-02-07 | 2002-08-08 | Ford Daniel E. | System and method for accessing software components in a distributed network environment |
| US7180855B1 (en) * | 2001-04-19 | 2007-02-20 | At&T Corp. | Service interface for QoS-driven HPNA networks |
| US7069337B2 (en) * | 2001-03-20 | 2006-06-27 | Mci, Inc. | Policy-based synchronization of per-class resources between routers in a data network |
| US7796608B2 (en) | 2001-03-20 | 2010-09-14 | Verizon Business Global Llc | Edge-based per-flow QoS admission control in a data network |
| US7209439B2 (en) * | 2001-03-20 | 2007-04-24 | Mci, Llc | Pool-based resource management in a data network |
| US6918120B2 (en) * | 2001-04-20 | 2005-07-12 | Hewlett-Packard Development Company, L.P. | Remote file system using network multicast |
| US7036006B2 (en) * | 2001-05-17 | 2006-04-25 | Veritas Operating Corporation | System to provide computing as a product using dynamic computing environments |
| US7009970B2 (en) * | 2001-06-26 | 2006-03-07 | Motorola, Inc. | Methods for managing bandwidth in a packet-based communication system incorporating a reservation proxy function |
| US7177318B2 (en) * | 2001-08-14 | 2007-02-13 | Freescale Semiconductor, Inc. | Method and apparatus for managing multicast data on an IP subnet |
| US7227865B2 (en) * | 2001-08-16 | 2007-06-05 | Interdigital Technology Corporation | Utilizing session initiation protocol for identifying user equipment resource reservation setup protocol capabilities |
| US7272651B1 (en) * | 2001-08-28 | 2007-09-18 | Cisco Technology, Inc. | RSVP transmitter proxy |
| EP1446925A1 (en) | 2001-10-25 | 2004-08-18 | Worldcom, Inc. | Communication session quality indicator |
| JP4161185B2 (ja) * | 2001-11-16 | 2008-10-08 | 日本電気株式会社 | 時刻同期データの伝送方法 |
| US7120147B2 (en) * | 2002-01-28 | 2006-10-10 | Motorola, Inc. | Reservation proxy function supporting filtering of multicast traffic in packet-based communication systems |
| US7126963B2 (en) * | 2002-05-23 | 2006-10-24 | International Business Machines Corporation | Apparatus, method and computer program to reserve resources in communications system |
| US7043730B2 (en) * | 2002-08-29 | 2006-05-09 | Hewlett-Packard Development Company, L.P. | System and method for demand oriented network resource management |
| US7818449B2 (en) * | 2002-09-03 | 2010-10-19 | Thomson Licensing | Mechanism for providing quality of service in a network utilizing priority and reserved bandwidth protocols |
| US7069428B2 (en) * | 2002-09-10 | 2006-06-27 | Veritas Operating Corporation | System for managing boot-up of target computers |
| US6986033B2 (en) | 2002-09-10 | 2006-01-10 | Veritas Operating Corporation | System for automated boot from disk image |
| JP2004127282A (ja) * | 2002-09-13 | 2004-04-22 | Ricoh Co Ltd | 画像形成装置および印刷処理方法 |
| US8161158B2 (en) * | 2002-09-25 | 2012-04-17 | Nokia Corporation | Method in a communication system, a communication system and a communication device |
| US7327741B1 (en) * | 2002-12-20 | 2008-02-05 | Symantec Operating Corporation | Detecting and breaking cycles in a computer network |
| US7653059B1 (en) * | 2002-12-20 | 2010-01-26 | Symantec Operating Corporation | Communication sessions for a computer network |
| US7756033B2 (en) * | 2004-05-03 | 2010-07-13 | Verizon Business Global Llc | Systems and methods for managing multicast data transmissions |
| US8260893B1 (en) | 2004-07-06 | 2012-09-04 | Symantec Operating Corporation | Method and system for automated management of information technology |
| US20070171833A1 (en) * | 2005-11-21 | 2007-07-26 | Sukhbinder Singh | Socket for use in a networked based computing system having primary and secondary routing layers |
| US7694101B2 (en) | 2005-12-30 | 2010-04-06 | Vmware, Inc. | Implementing virtual disk reservations on a storage media for multiple distributed applications |
| CN100461766C (zh) * | 2006-08-02 | 2009-02-11 | 华为技术有限公司 | 一种为实时流媒体业务分配资源的方法及装置 |
| US20080084860A1 (en) * | 2006-10-10 | 2008-04-10 | Sony Ericsson Mobile Communications Ab | Device and method for reserving a resource via a portable communication... |
| JP2010028777A (ja) * | 2008-07-24 | 2010-02-04 | Fujitsu Ltd | リソース予約方法およびリソース予約装置 |
| US8238538B2 (en) | 2009-05-28 | 2012-08-07 | Comcast Cable Communications, Llc | Stateful home phone service |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2094410C (en) * | 1992-06-18 | 1998-05-05 | Joshua Seth Auerbach | Distributed management communications network |
| US5541927A (en) * | 1994-08-24 | 1996-07-30 | At&T Corp. | Method of multicasting |
| US5517494A (en) * | 1994-09-30 | 1996-05-14 | Apple Computer, Inc. | Method and system of multicast routing for groups with a single transmitter |
| US5608726A (en) * | 1995-04-25 | 1997-03-04 | Cabletron Systems, Inc. | Network bridge with multicast forwarding table |
| US5805578A (en) * | 1995-10-27 | 1998-09-08 | International Business Machines Corporation | Automatic reconfiguration of multipoint communication channels |
-
1997
- 1997-09-30 US US08/940,251 patent/US6058113A/en not_active Expired - Lifetime
-
1998
- 1998-09-29 JP JP27511898A patent/JP3701476B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11163854A (ja) | 1999-06-18 |
| US6058113A (en) | 2000-05-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3701476B2 (ja) | データ通信方法 | |
| US7535829B2 (en) | Tunnel reroute | |
| JP4448040B2 (ja) | 既存のリザーベーションプロトコルおよびフレームフォーマットを使用してネットワーク内およびネットワークを横切って行われる保証されたサービスの品質またはクラスを提供する方法および装置 | |
| US7406031B1 (en) | Multihop nested tunnel restoration | |
| US7180866B1 (en) | Rerouting in connection-oriented communication networks and communication systems | |
| JP3923863B2 (ja) | リクエストルータ装置 | |
| US7035259B2 (en) | Label switch network system | |
| US9787593B2 (en) | Performing path-oriented systems management | |
| JPH11168476A (ja) | パケット転送方法及びノード装置 | |
| JPH11502997A (ja) | ユーザ割振可能な補助帯域幅を用いた、インターネット・アクセスポイントへのオンデマンド保証帯域幅サービス | |
| US7092359B2 (en) | Method for distributing the data-traffic load on a communication network and a communication network for implementing this method | |
| WO2006131055A1 (fr) | Procédé et élément de réseau destiné au transfert de données | |
| US6771645B1 (en) | Packet relaying apparatus | |
| EP1418716A1 (en) | Communication control system, communication control method, routing controller and router suitably used for the same | |
| JP4141304B2 (ja) | マルチキャスト通信ネットワークにおける通信方法、受信端末、ｌ２スイッチおよびｌ３スイッチ | |
| JP3529541B2 (ja) | ルータ装置及びパケット転送方法 | |
| JP3469501B2 (ja) | ネットワーク機器制御装置及び通信システム | |
| CN100486219C (zh) | 一种实现端到端的流传输方法 | |
| JP2002368787A (ja) | 明示的経路指定中継装置 | |
| JP2002185491A (ja) | ネットワークリソース予約方法及びノード装置 | |
| US7042882B2 (en) | Layer-structured path setup method and node apparatus for implementing same | |
| JP2004088658A (ja) | パケット転送装置及びパケット処理方法 | |
| JP3686345B2 (ja) | 通信品質保証方法 | |
| JP3482634B2 (ja) | Ｉｐ網での通信資源予約方法 | |
| Hutchison et al. | A critique of modern internet protocols: The issue of support for multimedia |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050713 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080722 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090722 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090722 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100722 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110722 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110722 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120722 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120722 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130722 Year of fee payment: 8 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |