JPH09270793A - 通信制御方法 - Google Patents
通信制御方法Info
- Publication number
- JPH09270793A JPH09270793A JP8081243A JP8124396A JPH09270793A JP H09270793 A JPH09270793 A JP H09270793A JP 8081243 A JP8081243 A JP 8081243A JP 8124396 A JP8124396 A JP 8124396A JP H09270793 A JPH09270793 A JP H09270793A
- Authority
- JP
- Japan
- Prior art keywords
- connection
- sender
- receiver
- route
- request
- 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.)
- Withdrawn
Links
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/82—Miscellaneous aspects
- H04L47/822—Collecting or measuring resource availability data
-
- 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/10—Flow control; Congestion control
- H04L47/15—Flow control; Congestion control in relation to multipoint traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2416—Real-time traffic
-
- 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/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/805—QOS or priority aware
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Communication Control (AREA)
Abstract
(57)【要約】
【課題】 経路制御と資源予約機構を統合し、効率的に
マルチキャスト通信を行うことができるようにする。 【解決手段】 新たな受信者（ホストＦ）からの送信者
（ホストＡ）とのコネクション設立要求に応じ、資源が
仮予約されるとともに、受信者の要求に適した経路が選
択され、コネクション設立要求が上位ノードに転送され
る。ホストＤにおいても同様の処理が実行され、コネク
ション設立要求が上位ノードに転送される。ホストＣに
おいては、資源が予約され、確認要求が下位ノードに転
送され、それがホストＤを介してホストＦに転送され
る。ホストＦにおいては、資源の量の調整が行われ、ホ
ストＡとの間のコネクションの設立が完了する。
マルチキャスト通信を行うことができるようにする。 【解決手段】 新たな受信者（ホストＦ）からの送信者
（ホストＡ）とのコネクション設立要求に応じ、資源が
仮予約されるとともに、受信者の要求に適した経路が選
択され、コネクション設立要求が上位ノードに転送され
る。ホストＤにおいても同様の処理が実行され、コネク
ション設立要求が上位ノードに転送される。ホストＣに
おいては、資源が予約され、確認要求が下位ノードに転
送され、それがホストＤを介してホストＦに転送され
る。ホストＦにおいては、資源の量の調整が行われ、ホ
ストＡとの間のコネクションの設立が完了する。
Description
【０００１】
【発明の属する技術分野】本発明は、通信制御方法に関
し、例えばマルチキャスト通信等に用いて好適な通信制
御方法に関する。
し、例えばマルチキャスト通信等に用いて好適な通信制
御方法に関する。
【０００２】
【従来の技術】近年、計算機がネットワークによって相
互接続された分散環境において、計算機を利用した電子
会議やビデオオンデマンド（Video on demand）システ
ムなどのマルチメディアアプリケーションが注目を浴び
ている。このようなアプリケーションが行う通信の特徴
として、データ転送に実時間性制約、即ち、一定レー
ト、または一定時間内の配送などの制約が存在すること
と、同時に同一のデータを、複数の受信者に対して効率
良く転送する必要があることなどが挙げられる。
互接続された分散環境において、計算機を利用した電子
会議やビデオオンデマンド（Video on demand）システ
ムなどのマルチメディアアプリケーションが注目を浴び
ている。このようなアプリケーションが行う通信の特徴
として、データ転送に実時間性制約、即ち、一定レー
ト、または一定時間内の配送などの制約が存在すること
と、同時に同一のデータを、複数の受信者に対して効率
良く転送する必要があることなどが挙げられる。
【０００３】マルチキャストに対応した資源予約を行う
プロトコルは既にいくつか提案されている。ここで、資
源とは、ＣＰＵ（Central Processing Unit）処理時
間、ネットワーク帯域、およびデータバッファ等であ
る。例えば、ＳＴ−ＩＩ（Internet Stream Protocol,V
ersion 2）は、１対多のコネクションを設立するプロト
コルである。送信者は最適なＦｌｏｗＳｐｅｃ（Flow S
pecification）を提案し、全受信者に対してコネクショ
ン設立要求をマルチキャストする。ここで、ＦｌｏｗＳ
ｐｅｃとは、データ転送レート、および許容伝送遅延な
どのデータ転送の性質を表し、データ転送に必要とされ
る資源の量は、指定されたＦｌｏｗＳｐｅｃをもとに計
算される。
プロトコルは既にいくつか提案されている。ここで、資
源とは、ＣＰＵ（Central Processing Unit）処理時
間、ネットワーク帯域、およびデータバッファ等であ
る。例えば、ＳＴ−ＩＩ（Internet Stream Protocol,V
ersion 2）は、１対多のコネクションを設立するプロト
コルである。送信者は最適なＦｌｏｗＳｐｅｃ（Flow S
pecification）を提案し、全受信者に対してコネクショ
ン設立要求をマルチキャストする。ここで、ＦｌｏｗＳ
ｐｅｃとは、データ転送レート、および許容伝送遅延な
どのデータ転送の性質を表し、データ転送に必要とされ
る資源の量は、指定されたＦｌｏｗＳｐｅｃをもとに計
算される。
【０００４】各受信者は、送信者からの経路で保証可能
な最大ＦｌｏｗＳｐｅｃを送信者に送り返す。送信者
は、全受信者から集めたＦｌｏｗＳｐｅｃの中で、最低
レベルのものを選択し、再びコネクション設立要求を送
信する。２度目のコネクション設立要求において、実際
に資源が予約され、全受信者に対して、等しいＦｌｏｗ
Ｓｐｅｃのコネクションが設立される。このコネクショ
ン設立手続きは、受信者が参加または脱退する度に行わ
れる。
な最大ＦｌｏｗＳｐｅｃを送信者に送り返す。送信者
は、全受信者から集めたＦｌｏｗＳｐｅｃの中で、最低
レベルのものを選択し、再びコネクション設立要求を送
信する。２度目のコネクション設立要求において、実際
に資源が予約され、全受信者に対して、等しいＦｌｏｗ
Ｓｐｅｃのコネクションが設立される。このコネクショ
ン設立手続きは、受信者が参加または脱退する度に行わ
れる。
【０００５】また、ＲＳＶＰ（Resource ReSerVation P
rotocol）においては、予め通常のマルチキャストを用
いて定期的にツリー構築要求を受信者に送ることで、Ｒ
ＳＶＰが管理するマルチキャストツリーを構築してお
く。新たに参加する受信者は、構築されたツリーを遡っ
て、コネクション設立要求を送ることにより、受信者か
らコネクションを設立する。この方式では、コネクショ
ン設立は受信者毎に行われるため、各受信者毎に異なる
ＦｌｏｗＳｐｅｃを設定することが可能である。ＲＳＶ
Ｐでは、設立されたコネクションは静的ではなく、定期
的に送られてくるツリー構築要求に従い、動的に再設立
される。
rotocol）においては、予め通常のマルチキャストを用
いて定期的にツリー構築要求を受信者に送ることで、Ｒ
ＳＶＰが管理するマルチキャストツリーを構築してお
く。新たに参加する受信者は、構築されたツリーを遡っ
て、コネクション設立要求を送ることにより、受信者か
らコネクションを設立する。この方式では、コネクショ
ン設立は受信者毎に行われるため、各受信者毎に異なる
ＦｌｏｗＳｐｅｃを設定することが可能である。ＲＳＶ
Ｐでは、設立されたコネクションは静的ではなく、定期
的に送られてくるツリー構築要求に従い、動的に再設立
される。
【０００６】
【発明が解決しようとする課題】しかしながら、従来の
ネットワークプロトコルでは、データ転送時に利用可能
な資源の量に応じて、データ転送に要する時間が変化す
るため、データ転送の実時間性を満たすことは困難であ
る課題があった。従って、送信を始める前に、送信者と
受信者間にコネクションを設立し、転送要求に応じて必
要な資源を予め予約するプロトコルが必要とされる。
ネットワークプロトコルでは、データ転送時に利用可能
な資源の量に応じて、データ転送に要する時間が変化す
るため、データ転送の実時間性を満たすことは困難であ
る課題があった。従って、送信を始める前に、送信者と
受信者間にコネクションを設立し、転送要求に応じて必
要な資源を予め予約するプロトコルが必要とされる。
【０００７】特に、マルチキャスト通信（１対多通信）
では、受信者が複数であり、受信者の参加または脱退に
より、データ転送中にコネクションが動的に変化する。
そこで、送信者と受信者間のコネクションをツリー上に
設立することにより、経路を共有し、かつ受信者の要求
に応じて動的にコネクション設立が可能な実時間マルチ
キャストプロトコルが求められている。
では、受信者が複数であり、受信者の参加または脱退に
より、データ転送中にコネクションが動的に変化する。
そこで、送信者と受信者間のコネクションをツリー上に
設立することにより、経路を共有し、かつ受信者の要求
に応じて動的にコネクション設立が可能な実時間マルチ
キャストプロトコルが求められている。
【０００８】上記２つのプロトコルＳＴ−ＩＩとＲＳＶ
Ｐの特徴をまとめたものを図１１に示す。図１１に示し
たように、ＳＴ−ＩＩは、受信者参加時に、毎回送信者
から資源予約を繰り返すため、受信者参加時のコネクシ
ョン設立要求の付加が送信者に集中し、グループのメン
バサイズのスケーラビリティに問題があり、また、各受
信者の転送レベルが最も低い受信者に合わされてしまう
という課題があった。
Ｐの特徴をまとめたものを図１１に示す。図１１に示し
たように、ＳＴ−ＩＩは、受信者参加時に、毎回送信者
から資源予約を繰り返すため、受信者参加時のコネクシ
ョン設立要求の付加が送信者に集中し、グループのメン
バサイズのスケーラビリティに問題があり、また、各受
信者の転送レベルが最も低い受信者に合わされてしまう
という課題があった。
【０００９】そこで、ＲＳＶＰにおいては、受信者から
コネクション設立要求を送信することにより、上記課題
を解決している。しかしながら、経路が動的に変化する
ことから、既設コネクションの保証が十分ではなく、ま
た、受信者毎の要求に対応しようとしているが、経路選
択自体は送信者によって行われるため、各受信者の要求
に応じた最適な経路を選ぶことができない課題があっ
た。
コネクション設立要求を送信することにより、上記課題
を解決している。しかしながら、経路が動的に変化する
ことから、既設コネクションの保証が十分ではなく、ま
た、受信者毎の要求に対応しようとしているが、経路選
択自体は送信者によって行われるため、各受信者の要求
に応じた最適な経路を選ぶことができない課題があっ
た。
【００１０】このように、従来のプロトコルの問題点
は、経路制御と資源予約機構を全く独立した機構として
捉えているため、経路選択を送信者からしか行うことが
できないことから生じていると考えられる。しかし、既
存のマルチキャスト経路制御アルゴリズムでは、内部の
処理では受信者側から、送信者側への経路選択が可能で
ある。
は、経路制御と資源予約機構を全く独立した機構として
捉えているため、経路選択を送信者からしか行うことが
できないことから生じていると考えられる。しかし、既
存のマルチキャスト経路制御アルゴリズムでは、内部の
処理では受信者側から、送信者側への経路選択が可能で
ある。
【００１１】本発明はこのような状況に鑑みてなされた
ものであり、経路制御機構と資源予約機構間のインタフ
ェースを定め、統合することにより、各受信者からの要
求に応じた経路制御、およびコネクションの設立を可能
とするものである。
ものであり、経路制御機構と資源予約機構間のインタフ
ェースを定め、統合することにより、各受信者からの要
求に応じた経路制御、およびコネクションの設立を可能
とするものである。
【００１２】
【課題を解決するための手段】請求項１に記載の通信制
御方法は、受信者からの要求に基づいて、送信者と受信
者との間の経路を選択し、コネクションを設立する経路
選択機構と、経路の資源を予約する資源予約機構の間の
インタフェースを規定し、経路選択機構と資源予約機構
とを統合することを特徴とする。
御方法は、受信者からの要求に基づいて、送信者と受信
者との間の経路を選択し、コネクションを設立する経路
選択機構と、経路の資源を予約する資源予約機構の間の
インタフェースを規定し、経路選択機構と資源予約機構
とを統合することを特徴とする。
【００１３】請求項３に記載の通信制御方法は、各送信
者が保持する各送信者のリストに基づいて、受信者から
各送信者に対してコネクションの設立を行い、複数の送
信者がコネクションを共有する場合、コネクションに予
約された資源の量に基づいて、コネクションを介してデ
ータを受信者に同時に送信する送信者の数を所定数以下
に制限し、新たな送信者または受信者のネットワークへ
の参加要求は、新たな送信者または受信者がネットワー
クに参加した場合においても、既存のコネクションを設
立している送信者および受信者のＱＯＳ要求が保証され
るとき、受理されることを特徴とする。
者が保持する各送信者のリストに基づいて、受信者から
各送信者に対してコネクションの設立を行い、複数の送
信者がコネクションを共有する場合、コネクションに予
約された資源の量に基づいて、コネクションを介してデ
ータを受信者に同時に送信する送信者の数を所定数以下
に制限し、新たな送信者または受信者のネットワークへ
の参加要求は、新たな送信者または受信者がネットワー
クに参加した場合においても、既存のコネクションを設
立している送信者および受信者のＱＯＳ要求が保証され
るとき、受理されることを特徴とする。
【００１４】請求項１に記載の通信制御方法において
は、受信者からの要求に基づいて、送信者と受信者との
間の経路を選択し、コネクションを設立する経路選択機
構と、経路の資源を予約する資源予約機構の間のインタ
フェースを規定し、経路選択機構と資源予約機構とを統
合する。
は、受信者からの要求に基づいて、送信者と受信者との
間の経路を選択し、コネクションを設立する経路選択機
構と、経路の資源を予約する資源予約機構の間のインタ
フェースを規定し、経路選択機構と資源予約機構とを統
合する。
【００１５】請求項３に記載の通信制御方法において
は、各送信者が保持する各送信者のリストに基づいて、
受信者から各送信者に対してコネクションの設立を行
い、複数の送信者がコネクションを共有する場合、コネ
クションに予約された資源の量に基づいて、コネクショ
ンを介してデータを受信者に同時に送信する送信者の数
を所定数以下に制限し、新たな送信者または受信者のネ
ットワークへの参加要求は、新たな送信者または受信者
がネットワークに参加した場合においても、既存のコネ
クションを設立している送信者および受信者のＱＯＳ要
求が保証されるとき、受理される。
は、各送信者が保持する各送信者のリストに基づいて、
受信者から各送信者に対してコネクションの設立を行
い、複数の送信者がコネクションを共有する場合、コネ
クションに予約された資源の量に基づいて、コネクショ
ンを介してデータを受信者に同時に送信する送信者の数
を所定数以下に制限し、新たな送信者または受信者のネ
ットワークへの参加要求は、新たな送信者または受信者
がネットワークに参加した場合においても、既存のコネ
クションを設立している送信者および受信者のＱＯＳ要
求が保証されるとき、受理される。
【００１６】
【発明の実施の形態】以下、本発明を適用した実時間マ
ルチキャストプロトコルＲｔＭＰ（Real-time Multicas
t Protocol）の詳細について説明する。
ルチキャストプロトコルＲｔＭＰ（Real-time Multicas
t Protocol）の詳細について説明する。
【００１７】汎用性を維持するためには、経路制御と資
源予約を統合する際に、特定の経路制御アルゴリズムに
依存してはならない。そこで、経路制御に関する機構
を、経路制御アルゴリズムに依存する部分と、それとは
独立の部分に分割する。
源予約を統合する際に、特定の経路制御アルゴリズムに
依存してはならない。そこで、経路制御に関する機構
を、経路制御アルゴリズムに依存する部分と、それとは
独立の部分に分割する。
【００１８】例えば、経路制御アルゴリズムに依存する
部分は、ノード間での経路情報の交換、および経路計算
を行うこととし、経路制御アルゴリズムに独立な部分
は、経路情報の資源に関する部分の管理および評価、提
案された経路からの所定の経路の選択、そして既設のコ
ネクションに関する情報を保持することとする。
部分は、ノード間での経路情報の交換、および経路計算
を行うこととし、経路制御アルゴリズムに独立な部分
は、経路情報の資源に関する部分の管理および評価、提
案された経路からの所定の経路の選択、そして既設のコ
ネクションに関する情報を保持することとする。
【００１９】経路を選択する際に、資源についての評価
が必要な場合には、図１に示したようなインタフェース
の内の３つ（ＲｏｕｔｅＡｄｄ、ＲｏｕｔｅＳｅｌｅｃ
ｔ、およびＲｏｕｔｅＥｖａｌ）を用い、資源予約モジ
ュール側で評価を行う。コネクションを設立する際に
は、資源予約モジュールはインタフェースＲｏｕｔｅＲ
ｅｑを用いて上位ノードの候補を取得し、その中から受
信者の要求を満たすのに最適な上位ノードを選択する。
が必要な場合には、図１に示したようなインタフェース
の内の３つ（ＲｏｕｔｅＡｄｄ、ＲｏｕｔｅＳｅｌｅｃ
ｔ、およびＲｏｕｔｅＥｖａｌ）を用い、資源予約モジ
ュール側で評価を行う。コネクションを設立する際に
は、資源予約モジュールはインタフェースＲｏｕｔｅＲ
ｅｑを用いて上位ノードの候補を取得し、その中から受
信者の要求を満たすのに最適な上位ノードを選択する。
【００２０】この機構により、特定の経路制御アルゴリ
ズムに依存することなく、資源に関するパラメータを経
路情報に反映させることができ、受信者の要求に応じた
経路選択が可能となる。
ズムに依存することなく、資源に関するパラメータを経
路情報に反映させることができ、受信者の要求に応じた
経路選択が可能となる。
【００２１】様々な受信者の要求に対応するためには、
各経路毎にその経路が満足できるＦｌｏｗｓｐｅｃのコ
ネクションを設立することが可能でなくてはならない。
すなわち、各経路毎に異なるＦｌｏｗｓｐｅｃのコネク
ションを設立することが可能でなければならない。
各経路毎にその経路が満足できるＦｌｏｗｓｐｅｃのコ
ネクションを設立することが可能でなくてはならない。
すなわち、各経路毎に異なるＦｌｏｗｓｐｅｃのコネク
ションを設立することが可能でなければならない。
【００２２】つまり、送信者が送出したデータを全経路
に転送できるとは限らず、図２に示したように、経路が
分かれる場合には、各経路の転送能力を確認し、転送可
能な経路にのみデータを送る必要がある。その際に、転
送能力を越える量のデータを転送してしまった場合に
は、資源が余分に使用され、そのコネクションの実時間
性を保証することができなくなるだけではなく、他のコ
ネクションにも悪影響を及ぼす可能性がある。
に転送できるとは限らず、図２に示したように、経路が
分かれる場合には、各経路の転送能力を確認し、転送可
能な経路にのみデータを送る必要がある。その際に、転
送能力を越える量のデータを転送してしまった場合に
は、資源が余分に使用され、そのコネクションの実時間
性を保証することができなくなるだけではなく、他のコ
ネクションにも悪影響を及ぼす可能性がある。
【００２３】そこで、送信データに優先度レベルを設
け、そのレベルに応じて、中間ノードはデータを転送す
る経路を選択するようにする。ＲｔＭＰ内部では、優先
度レベルはデータ転送レートにマップされる。図２に示
した中間ノードの場合、転送レートが５１２Ｋｂｐｓ
（キロバイト／秒）の経路と転送レートが１Ｍｂｐｓ
（メガバイト／秒）の経路に分岐している。また、転送
レートが５１２Ｋｂｐｓの経路に転送可能なデータは優
先度レベルが２以下のものとされ、転送レートが１Ｍｂ
ｐｓの経路に転送可能なデータは優先度レベルが３以下
のものとされている。
け、そのレベルに応じて、中間ノードはデータを転送す
る経路を選択するようにする。ＲｔＭＰ内部では、優先
度レベルはデータ転送レートにマップされる。図２に示
した中間ノードの場合、転送レートが５１２Ｋｂｐｓ
（キロバイト／秒）の経路と転送レートが１Ｍｂｐｓ
（メガバイト／秒）の経路に分岐している。また、転送
レートが５１２Ｋｂｐｓの経路に転送可能なデータは優
先度レベルが２以下のものとされ、転送レートが１Ｍｂ
ｐｓの経路に転送可能なデータは優先度レベルが３以下
のものとされている。
【００２４】図３に、優先度レベルとデータ転送レート
との対応関係を示す。優先度レベルとデータ転送レート
との対応は、送信者によって指定される。受信者は、コ
ネクション設立を要求する際に、Ｆｌｏｗｓｐｅｃのパ
ラメータとして、受信すべき優先度レベルを指定する。
との対応関係を示す。優先度レベルとデータ転送レート
との対応は、送信者によって指定される。受信者は、コ
ネクション設立を要求する際に、Ｆｌｏｗｓｐｅｃのパ
ラメータとして、受信すべき優先度レベルを指定する。
【００２５】送信ノードにおいて、データは優先度レベ
ルで指定されたデータ転送レートを越えないようにレー
ト制御される。各中間ノード、および受信ノードでは、
コネクション設立時に指定された優先度レベルに従い、
転送されてきたデータを転送し、または受信する。
ルで指定されたデータ転送レートを越えないようにレー
ト制御される。各中間ノード、および受信ノードでは、
コネクション設立時に指定された優先度レベルに従い、
転送されてきたデータを転送し、または受信する。
【００２６】このデータ転送制御機構を送信者側から見
た場合、送信者は多重化されたチャネルを有し、各デー
タの重要度に応じたデータ送信を行うことが可能である
ということになる。従って、例えば、図３に示したよう
に、優先度レベルが１の場合、音声を送信し、優先度レ
ベルが２の場合、粗い画像を送信する。また、優先度レ
ベルが３の場合、細かい画像を送信する。これにより、
資源に余裕があるノードでは細かい映像、資源が少ない
ノードでは、粗い画像または音声のみでサービスの提供
を受けることが可能となる。
た場合、送信者は多重化されたチャネルを有し、各デー
タの重要度に応じたデータ送信を行うことが可能である
ということになる。従って、例えば、図３に示したよう
に、優先度レベルが１の場合、音声を送信し、優先度レ
ベルが２の場合、粗い画像を送信する。また、優先度レ
ベルが３の場合、細かい画像を送信する。これにより、
資源に余裕があるノードでは細かい映像、資源が少ない
ノードでは、粗い画像または音声のみでサービスの提供
を受けることが可能となる。
【００２７】優先度レベル以外に、到着時間制約（一定
時間以内にデータが届くという制約）等の情報もコネク
ション情報として存在し、優先度レベルと同様に中間ノ
ードで管理され、コネクション設立時、データ転送時に
参照される。
時間以内にデータが届くという制約）等の情報もコネク
ション情報として存在し、優先度レベルと同様に中間ノ
ードで管理され、コネクション設立時、データ転送時に
参照される。
【００２８】図４に、コネクション設立手順の例を示
す。ここでは、送信者であるホスト１（＝ＨｏｓｔＡ）
と受信者であるホスト２（＝ＨｏｓｔＢ）、ホスト４
（＝ホストＥ）間に張られているコネクションに、新た
な受信者であるホスト６（＝ＨｏｓｔＦ）が参加する場
合に行われる処理が示されている。図４において、矢印
はメッセージの流れを示し、ホスト名の下に記載されて
いる（下位ノード，優先度レベル）はコネクション情報
を示している。
す。ここでは、送信者であるホスト１（＝ＨｏｓｔＡ）
と受信者であるホスト２（＝ＨｏｓｔＢ）、ホスト４
（＝ホストＥ）間に張られているコネクションに、新た
な受信者であるホスト６（＝ＨｏｓｔＦ）が参加する場
合に行われる処理が示されている。図４において、矢印
はメッセージの流れを示し、ホスト名の下に記載されて
いる（下位ノード，優先度レベル）はコネクション情報
を示している。
【００２９】ステップＳ１乃至Ｓ３において、受信者か
らのコネクション設立要求（ｒｅｑｕｅｓｔ（ＱＯＳ，
２）（この場合、ＱＯＳ（Quality Of Service）が２に
対応するデータの送信を要求している））に応じ、資源
予約モジュールが資源の仮予約を行う。
らのコネクション設立要求（ｒｅｑｕｅｓｔ（ＱＯＳ，
２）（この場合、ＱＯＳ（Quality Of Service）が２に
対応するデータの送信を要求している））に応じ、資源
予約モジュールが資源の仮予約を行う。
【００３０】ステップＳ４においては、経路制御モジュ
ールに上位ノードを問い合わせ、受信者の要求に適した
経路を選択する（ｇｅｔ ｕｐｐｅｒ ｎｏｄｅ）。次
に、ステップＳ５において、コネクション設立要求（ｃ
ｏｎｎｅｃｔ＿ｒｅｑ（ＱＯＳ，２））を上位ノード
（この場合、ホスト５（＝ホストＤ））に転送する。
ールに上位ノードを問い合わせ、受信者の要求に適した
経路を選択する（ｇｅｔ ｕｐｐｅｒ ｎｏｄｅ）。次
に、ステップＳ５において、コネクション設立要求（ｃ
ｏｎｎｅｃｔ＿ｒｅｑ（ＱＯＳ，２））を上位ノード
（この場合、ホスト５（＝ホストＤ））に転送する。
【００３１】ホストＤは、ホストＦからのこのコネクシ
ョン設立要求を受信したとき、上位ノード（この場合、
ホスト３（＝ホストＣ））との間にコネクションを設立
しておらず、受信者の要求を満たすことができないの
で、ホストＦにおけるステップＳ２乃至Ｓ４の処理に対
応するステップＳ６乃至Ｓ８の処理を実行し、資源の仮
予約が行われるとともに、コネクション設立要求がさら
に上位のノードに転送される。
ョン設立要求を受信したとき、上位ノード（この場合、
ホスト３（＝ホストＣ））との間にコネクションを設立
しておらず、受信者の要求を満たすことができないの
で、ホストＦにおけるステップＳ２乃至Ｓ４の処理に対
応するステップＳ６乃至Ｓ８の処理を実行し、資源の仮
予約が行われるとともに、コネクション設立要求がさら
に上位のノードに転送される。
【００３２】ホストＤからのこのコネクション設立要求
を受信したホストＣは、ステップＳ９において、既にホ
ストＡとの間にコネクションを設立していることを認識
し、この場合、受信者の要求を満たすこと（所定のＦｌ
ｏｗｓｐｅｃを満たすこと）が可能であるので、資源の
予約を行い、ステップＳ１０において下位ノードとのコ
ネクションを設立し、ステップＳ１１において、コネク
ション情報に加え、確認要求（Ｃｏｎｎｅｃｔ＿ａｃ
ｋ）を下位ノードに送り返す。
を受信したホストＣは、ステップＳ９において、既にホ
ストＡとの間にコネクションを設立していることを認識
し、この場合、受信者の要求を満たすこと（所定のＦｌ
ｏｗｓｐｅｃを満たすこと）が可能であるので、資源の
予約を行い、ステップＳ１０において下位ノードとのコ
ネクションを設立し、ステップＳ１１において、コネク
ション情報に加え、確認要求（Ｃｏｎｎｅｃｔ＿ａｃ
ｋ）を下位ノードに送り返す。
【００３３】一方、設立されているコネクションが要求
を満たさない場合、Ｆｌｏｗｓｐｅｃの変更が試みられ
る。このＦｌｏｗｓｐｅｃの変更処理は、上述したステ
ップＳ１乃至Ｓ３において行われる資源予約要求処理と
基本的には同様の手順で行われるが、ここでのＦｌｏｗ
ｓｐｅｃの変更処理は、既設コネクション上で行われる
点、および新たに資源を確保するのではなく、現在の資
源を変更する点で上述した資源予約要求処理とは異な
る。
を満たさない場合、Ｆｌｏｗｓｐｅｃの変更が試みられ
る。このＦｌｏｗｓｐｅｃの変更処理は、上述したステ
ップＳ１乃至Ｓ３において行われる資源予約要求処理と
基本的には同様の手順で行われるが、ここでのＦｌｏｗ
ｓｐｅｃの変更処理は、既設コネクション上で行われる
点、および新たに資源を確保するのではなく、現在の資
源を変更する点で上述した資源予約要求処理とは異な
る。
【００３４】上位ノードとの間のコネクションが設立さ
れていない場合、あるいは上述したＦｌｏｗｓｐｅｃの
変更が不可能である場合、上述した場合と同様にして、
資源予約要求処理が繰り返される。
れていない場合、あるいは上述したＦｌｏｗｓｐｅｃの
変更が不可能である場合、上述した場合と同様にして、
資源予約要求処理が繰り返される。
【００３５】上位ノードからの確認要求を受け取ったノ
ードは、上位ノードで保証されたＦｌｏｗｓｐｅｃに従
って、先に仮予約をした資源の量を調整し、下位ノード
に確認要求を送る。この場合、ホストＣからの確認要求
を受け取ったホストＤは、ステップＳ１２において、下
位ノードとの間のコネクションを設立するとともに、ス
テップＳ１３において、先に仮予約を行った資源の調整
を行い、ステップＳ１４において、下位ノードに対して
確認要求を送信する。
ードは、上位ノードで保証されたＦｌｏｗｓｐｅｃに従
って、先に仮予約をした資源の量を調整し、下位ノード
に確認要求を送る。この場合、ホストＣからの確認要求
を受け取ったホストＤは、ステップＳ１２において、下
位ノードとの間のコネクションを設立するとともに、ス
テップＳ１３において、先に仮予約を行った資源の調整
を行い、ステップＳ１４において、下位ノードに対して
確認要求を送信する。
【００３６】このようにして、上位ノード（この場合、
ホストＣ）からの確認要求が受信者のノード（この場
合、ホストＦ）に戻ると、ステップＳ１５において、資
源の量の調整が行われ、その時点で、コネクション設立
が完了する。次に、ステップＳ１６において、コネクシ
ョン設立が完了したことが受信者（ホストＦ）に対して
通知される。
ホストＣ）からの確認要求が受信者のノード（この場
合、ホストＦ）に戻ると、ステップＳ１５において、資
源の量の調整が行われ、その時点で、コネクション設立
が完了する。次に、ステップＳ１６において、コネクシ
ョン設立が完了したことが受信者（ホストＦ）に対して
通知される。
【００３７】この方式では、受信者の要求に応じて経路
が選択されるため、要求に最適なコネクションの設立が
可能となる。また、コネクション設立処理は、受信者と
接続されるノード間のみにおいて行われるため、グルー
プのスケーラビリティは維持される。さらに、各ノード
において資源の残り量を確認することにより、既設のコ
ネクションを乱さないことを保証することが可能であ
る。
が選択されるため、要求に最適なコネクションの設立が
可能となる。また、コネクション設立処理は、受信者と
接続されるノード間のみにおいて行われるため、グルー
プのスケーラビリティは維持される。さらに、各ノード
において資源の残り量を確認することにより、既設のコ
ネクションを乱さないことを保証することが可能であ
る。
【００３８】ＲｔＭＰにおいては、設立されたコネクシ
ョンは、受信者の参加または脱退がない限り通常変化し
ない。これは設立されたコネクションは障害発生時以外
には常にデータ転送を保証する（プロトコルの動作によ
ってコネクションが乱されることはない）点を実時間通
信プロトコルの必要条件としているためである。
ョンは、受信者の参加または脱退がない限り通常変化し
ない。これは設立されたコネクションは障害発生時以外
には常にデータ転送を保証する（プロトコルの動作によ
ってコネクションが乱されることはない）点を実時間通
信プロトコルの必要条件としているためである。
【００３９】しかしながら、コネクションが静的な場
合、ホストやネットワークの障害による経路変更がコネ
クションに反映されないため、明示的に障害回復処理を
行う必要がある。障害が生じた場合の処理を以下に示
す。
合、ホストやネットワークの障害による経路変更がコネ
クションに反映されないため、明示的に障害回復処理を
行う必要がある。障害が生じた場合の処理を以下に示
す。
【００４０】図５は、障害が発生した場合の処理例を説
明するためのフローチャートである。まず、ステップＳ
３１において、経路制御部は、隣接ノードに定期的に
「ＨＥＬＬＯメッセージ」の送信を行う。ステップＳ３
２においては、隣接ノードからの応答があったか否かが
判定される。隣接ノードからの応答があったと判定され
た場合、障害の発生はないものとし、ステップＳ３１に
戻り、再度ステップＳ３１以降の処理が実行される。一
方、隣接ノードからの応答がなかったと判定された場
合、隣接ノードまたは隣接ノードとの間のネットワーク
に障害があったものとみなし、ステップＳ３３に進み、
障害発生時の処理を開始する。
明するためのフローチャートである。まず、ステップＳ
３１において、経路制御部は、隣接ノードに定期的に
「ＨＥＬＬＯメッセージ」の送信を行う。ステップＳ３
２においては、隣接ノードからの応答があったか否かが
判定される。隣接ノードからの応答があったと判定され
た場合、障害の発生はないものとし、ステップＳ３１に
戻り、再度ステップＳ３１以降の処理が実行される。一
方、隣接ノードからの応答がなかったと判定された場
合、隣接ノードまたは隣接ノードとの間のネットワーク
に障害があったものとみなし、ステップＳ３３に進み、
障害発生時の処理を開始する。
【００４１】ステップＳ３３においては、通信不能とな
ったノードとの間に、コネクションが存在していたか否
かが判定される。コネクションが存在していなかったと
判定された場合、処理を終了する。一方、コネクション
が存在していたと判定された場合、ステップＳ３４に進
み、そのコネクションの破棄を行う。
ったノードとの間に、コネクションが存在していたか否
かが判定される。コネクションが存在していなかったと
判定された場合、処理を終了する。一方、コネクション
が存在していたと判定された場合、ステップＳ３４に進
み、そのコネクションの破棄を行う。
【００４２】次に、ステップＳ３５において、通信不能
となったノードが下位ノードであるか否かが判定され
る。通信不能となったノードが下位ノードであると判定
された場合、下位ノードに対してデータを送信する必要
がなくなるため、ステップＳ３６に進み、下位ノードの
資源が解放される。
となったノードが下位ノードであるか否かが判定され
る。通信不能となったノードが下位ノードであると判定
された場合、下位ノードに対してデータを送信する必要
がなくなるため、ステップＳ３６に進み、下位ノードの
資源が解放される。
【００４３】次に、ステップＳ３７において、このと
き、下位ノードがただ１つであるか否かが判定される。
下位ノードが１つであると判定された場合、上位ノード
にコネクション破棄要求を送り、上位ノードの資源も解
放し、処理を終了する。
き、下位ノードがただ１つであるか否かが判定される。
下位ノードが１つであると判定された場合、上位ノード
にコネクション破棄要求を送り、上位ノードの資源も解
放し、処理を終了する。
【００４４】一方、ステップＳ３５において、下位ノー
ドとの通信が不能ではないと判定された場合、即ち、上
位ノードと通信不能となったと判定された場合、ステッ
プＳ３９に進み、他の経路を検索する。
ドとの通信が不能ではないと判定された場合、即ち、上
位ノードと通信不能となったと判定された場合、ステッ
プＳ３９に進み、他の経路を検索する。
【００４５】次に、ステップＳ４０において、他の経路
が存在するか否かが判定され、他の経路が存在すると判
定された場合、ステップＳ４１に進み、コネクション設
立要求を発行し、他の経路とのコネクションを設立す
る。一方、他の経路が存在しないと判定された場合、ス
テップＳ４２に進み、上位ノードの資源を解放し、下位
ノードにコネクション再設立要求メッセージを送る。
が存在するか否かが判定され、他の経路が存在すると判
定された場合、ステップＳ４１に進み、コネクション設
立要求を発行し、他の経路とのコネクションを設立す
る。一方、他の経路が存在しないと判定された場合、ス
テップＳ４２に進み、上位ノードの資源を解放し、下位
ノードにコネクション再設立要求メッセージを送る。
【００４６】ステップＳ４３においては、コネクション
再設立要求を受け取ったノードは、現在のコネクション
を破棄した後、他の経路を検索し、コネクションの張り
直しを試みる。次に、ステップＳ４４に進み、受信者へ
の通知を行う。即ち、コネクションを破棄するのと同時
に、下位ノードに存在する受信者に対して、障害が発生
したことを通知し、さらに、コネクションの張り直しが
完了した場合、そのことを再び下位ノードに存在する受
信者に通知する。そして、処理を終了する。
再設立要求を受け取ったノードは、現在のコネクション
を破棄した後、他の経路を検索し、コネクションの張り
直しを試みる。次に、ステップＳ４４に進み、受信者へ
の通知を行う。即ち、コネクションを破棄するのと同時
に、下位ノードに存在する受信者に対して、障害が発生
したことを通知し、さらに、コネクションの張り直しが
完了した場合、そのことを再び下位ノードに存在する受
信者に通知する。そして、処理を終了する。
【００４７】このような処理によって、受信者は、障害
が発生した場合において、データを転送するとき、実時
間性を守ることができないことを知ることができ、その
対応処置を行うことができる。また、可能な限りコネク
ションは再び設立される。これらは、障害対処の重要な
機能である。
が発生した場合において、データを転送するとき、実時
間性を守ることができないことを知ることができ、その
対応処置を行うことができる。また、可能な限りコネク
ションは再び設立される。これらは、障害対処の重要な
機能である。
【００４８】例えば、電子会議のように、１対多通信だ
けではなく、多対多通信を必要とするアプリケーション
も多数存在する。特に、いくつかのアプリケーション
は、同時には固定数の送信者しかデータを送信しないと
いった特徴を有する。この場合、各送信者についてコネ
クションを設立するのではなく、通信の性質を考慮し、
コネクションを共有することにより、効率的に資源を利
用することが可能である。
けではなく、多対多通信を必要とするアプリケーション
も多数存在する。特に、いくつかのアプリケーション
は、同時には固定数の送信者しかデータを送信しないと
いった特徴を有する。この場合、各送信者についてコネ
クションを設立するのではなく、通信の性質を考慮し、
コネクションを共有することにより、効率的に資源を利
用することが可能である。
【００４９】多対多コネクションを効率良くサポートす
るために必要な機構を以下にまとめる。
るために必要な機構を以下にまとめる。
【００５０】まず、コネクションの共有を行う機構が必
要である。共通の経路では、最大送信者数に対応する帯
域を予約すればよい。ただし、送信者間で協調し、予約
された送信者数以上の送信者が同時にデータを送信しな
いことを保証するプロトコルを必要とする。
要である。共通の経路では、最大送信者数に対応する帯
域を予約すればよい。ただし、送信者間で協調し、予約
された送信者数以上の送信者が同時にデータを送信しな
いことを保証するプロトコルを必要とする。
【００５１】例えば、次のようなプロトコルを用いるこ
とにより、受信者に対して同時にデータを送信する送信
者数を所定数以下に制限することができる。
とにより、受信者に対して同時にデータを送信する送信
者数を所定数以下に制限することができる。
【００５２】即ち、全ての送信者は、送信者リストを持
っているので、送信可能な送信者のリストも同様に管理
するようにする。全ての送信者は、送信者リストを持っ
ているので、送信者同士でトークンをやりとりし、トー
クンを渡された送信者は、受信者に送信すべきデータが
ある場合、それを受信者に送信し、所定のタイミングで
トークンを次の送信者に渡す。また、送信すべきデータ
がない場合、データの送信は行わず、所定のタイミング
でトークンを次の送信者に送信する。
っているので、送信可能な送信者のリストも同様に管理
するようにする。全ての送信者は、送信者リストを持っ
ているので、送信者同士でトークンをやりとりし、トー
クンを渡された送信者は、受信者に送信すべきデータが
ある場合、それを受信者に送信し、所定のタイミングで
トークンを次の送信者に渡す。また、送信すべきデータ
がない場合、データの送信は行わず、所定のタイミング
でトークンを次の送信者に送信する。
【００５３】ここで、トークンは、例えば、送信者リス
トに記述される各送信者に設定された優先度の順番に従
って、次の送信者に送信されるようにすることができ
る。各送信者がトークンを保持する時間も、この優先度
に基づいて決めることができる。これにより、受信者に
同時にデータを送信する送信者の数を１に制限すること
ができる。
トに記述される各送信者に設定された優先度の順番に従
って、次の送信者に送信されるようにすることができ
る。各送信者がトークンを保持する時間も、この優先度
に基づいて決めることができる。これにより、受信者に
同時にデータを送信する送信者の数を１に制限すること
ができる。
【００５４】上記プロトコルを応用し、２以上の所定数
のトークンを送信者間でやりとりさせるようにすること
により、受信者に同時にデータを送信することができる
送信者数を２以上の所定数以下に制限することができ
る。従って、上記機構を用いることにより、受信者にデ
ータを同時に送信可能な送信者の数を、１または２以上
の所定数以下に制限することができる。
のトークンを送信者間でやりとりさせるようにすること
により、受信者に同時にデータを送信することができる
送信者数を２以上の所定数以下に制限することができ
る。従って、上記機構を用いることにより、受信者にデ
ータを同時に送信可能な送信者の数を、１または２以上
の所定数以下に制限することができる。
【００５５】次に、受信チャネルの選択を行う機構が必
要である。各受信者は、全送信者からのデータを受け取
るのではなく、ある特定の送信者からのデータだけを受
け取るようにする。
要である。各受信者は、全送信者からのデータを受け取
るのではなく、ある特定の送信者からのデータだけを受
け取るようにする。
【００５６】このとき、送信者同士が協調するか、ある
いは受信者が任意の送信者に対してコネクションの設立
を行うために、送信者のリストが必要となる。ＲｔＭＰ
においては、送信者リストを管理するプロトコルを新た
に加えることにより対応する。以下、ＲｔＭＰ内で追
加、変更される部分の詳細について説明する。
いは受信者が任意の送信者に対してコネクションの設立
を行うために、送信者のリストが必要となる。ＲｔＭＰ
においては、送信者リストを管理するプロトコルを新た
に加えることにより対応する。以下、ＲｔＭＰ内で追
加、変更される部分の詳細について説明する。
【００５７】まず、送信者リストの管理について説明す
る。送信者リストを管理する代表者を決め、その代表者
に送信者リストを集中管理させることは容易であるが、
送信者リストの更新、および保持が１点に集中するた
め、管理者に障害が発生した場合、プロトコル動作に致
命的な障害が生じる。また、更新負荷が集中するなどの
問題も生じる。
る。送信者リストを管理する代表者を決め、その代表者
に送信者リストを集中管理させることは容易であるが、
送信者リストの更新、および保持が１点に集中するた
め、管理者に障害が発生した場合、プロトコル動作に致
命的な障害が生じる。また、更新負荷が集中するなどの
問題も生じる。
【００５８】そこで、ＲｔＭＰにおいては、送信者リス
トを各送信者毎にそれぞれ保持する方法を採る。送信者
リストの一貫性を保証するために、以前、本発明者が提
案したＰｒｏｃｅｓｓ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅ
ｎｔ Ｐｒｏｔｏｃｏｌ（ＰＧＭＰ）において、グルー
プメンバリスト管理に用いられている、更新に全順序関
係を与える方式を採る。例えば、複数の送信者が送信者
リストの更新を同時に行おうとした場合、古い送信者リ
ストに基づいて、送信者リストが更新される可能性があ
る。これを防ぐために、更新要求に全順序関係を付け、
全ての送信者が同一の順序で更新要求を受け取り、古い
送信者リストに基づいた更新要求を拒否するようにす
る。
トを各送信者毎にそれぞれ保持する方法を採る。送信者
リストの一貫性を保証するために、以前、本発明者が提
案したＰｒｏｃｅｓｓ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅ
ｎｔ Ｐｒｏｔｏｃｏｌ（ＰＧＭＰ）において、グルー
プメンバリスト管理に用いられている、更新に全順序関
係を与える方式を採る。例えば、複数の送信者が送信者
リストの更新を同時に行おうとした場合、古い送信者リ
ストに基づいて、送信者リストが更新される可能性があ
る。これを防ぐために、更新要求に全順序関係を付け、
全ての送信者が同一の順序で更新要求を受け取り、古い
送信者リストに基づいた更新要求を拒否するようにす
る。
【００５９】即ち、所定の送信者（以下、送信者Ａとす
る）が各送信者に送信した更新要求を各送信者が受信す
ると、その更新要求に、まだ実行が不可能であることを
示す所定の実行不可能の印を対応付け、更新要求待ち行
列に入れる。そして、各送信者は確認応答を、更新要求
を受信した順番を示すシーケンシャル番号とともに送信
者Ａに送り返す。
る）が各送信者に送信した更新要求を各送信者が受信す
ると、その更新要求に、まだ実行が不可能であることを
示す所定の実行不可能の印を対応付け、更新要求待ち行
列に入れる。そして、各送信者は確認応答を、更新要求
を受信した順番を示すシーケンシャル番号とともに送信
者Ａに送り返す。
【００６０】送信者Ａが全ての送信者から確認応答とシ
ーケンシャル番号を受け取ったとき、２度目の更新要求
を、受け取ったシーケンシャル番号の中で最も大きいも
のとともに、各送信者に送信する。各送信者は、送信者
Ａからの２度目の更新要求とシーケンシャル番号を受け
取ると、待ち行列の中にある最初に受信した更新要求の
シーケンシャル番号を、いま送信者Ａより送信されてき
たシーケンシャル番号に変更し、実行不可能の印を実行
可能の印に変え、シーケンシャル番号で昇順にソートす
る。ここで、待ち行列の中にある複数の更新要求に同一
のシーケンシャル番号が対応するような場合、所定の統
一的な基準、例えば、送信者（ホスト）のアドレス等に
よって、その順序づけを行うようにする。
ーケンシャル番号を受け取ったとき、２度目の更新要求
を、受け取ったシーケンシャル番号の中で最も大きいも
のとともに、各送信者に送信する。各送信者は、送信者
Ａからの２度目の更新要求とシーケンシャル番号を受け
取ると、待ち行列の中にある最初に受信した更新要求の
シーケンシャル番号を、いま送信者Ａより送信されてき
たシーケンシャル番号に変更し、実行不可能の印を実行
可能の印に変え、シーケンシャル番号で昇順にソートす
る。ここで、待ち行列の中にある複数の更新要求に同一
のシーケンシャル番号が対応するような場合、所定の統
一的な基準、例えば、送信者（ホスト）のアドレス等に
よって、その順序づけを行うようにする。
【００６１】このソートによって先頭に並び変えられた
更新要求に、実行可能の印が対応付けられている場合、
その更新要求が現在の送信者リストに基づいたものであ
るかを、送信者リストに対応付けられたバージョンを比
較することにより確認する。確認の結果、現在のバージ
ョンである場合、送信者Ａからの更新要求が受け入れら
れ、各送信者は各送信者が保持する送信者リストを更新
し、送信者リストのバージョンを１だけ増加させ、更新
完了通知を送信者Ａに送信する。
更新要求に、実行可能の印が対応付けられている場合、
その更新要求が現在の送信者リストに基づいたものであ
るかを、送信者リストに対応付けられたバージョンを比
較することにより確認する。確認の結果、現在のバージ
ョンである場合、送信者Ａからの更新要求が受け入れら
れ、各送信者は各送信者が保持する送信者リストを更新
し、送信者リストのバージョンを１だけ増加させ、更新
完了通知を送信者Ａに送信する。
【００６２】一方、確認の結果、更新要求が現在の送信
者リストに基づいたものではなく、古い送信者リストに
基づいたものである場合、各送信者は更新要求を拒否
し、拒否メッセージを送信者Ａに送信する。送信者Ａが
各送信者より拒否メッセージを受け取った場合、再び各
送信者に対して更新要求を行い、上述した処理が繰り返
される。
者リストに基づいたものではなく、古い送信者リストに
基づいたものである場合、各送信者は更新要求を拒否
し、拒否メッセージを送信者Ａに送信する。送信者Ａが
各送信者より拒否メッセージを受け取った場合、再び各
送信者に対して更新要求を行い、上述した処理が繰り返
される。
【００６３】このような機構により、各送信者は常に、
現在、グループにデータを送信する可能性のある送信者
リストを保持することが可能となる。
現在、グループにデータを送信する可能性のある送信者
リストを保持することが可能となる。
【００６４】新たな送信者が参加した場合、各受信者に
対し、コネクションを設立する必要がある。ＲｔＭＰに
おいては、通常のコネクション設立は、受信者参加時に
おいて受信者から行われるため、特別なコネクション設
立手続きが必要とされる。ＲｔＭＰにおける送信者参加
手続きを、図６に示したフローチャートを参照して説明
する。
対し、コネクションを設立する必要がある。ＲｔＭＰに
おいては、通常のコネクション設立は、受信者参加時に
おいて受信者から行われるため、特別なコネクション設
立手続きが必要とされる。ＲｔＭＰにおける送信者参加
手続きを、図６に示したフローチャートを参照して説明
する。
【００６５】まず、ステップＳ５１において、送信者リ
ストの取得および更新を行う。即ち、送信者リストを他
の送信者から取得し、他の送信者が保持するリストに自
ホストを加える。
ストの取得および更新を行う。即ち、送信者リストを他
の送信者から取得し、他の送信者が保持するリストに自
ホストを加える。
【００６６】次に、ステップＳ５２に進み、受信者に対
し、コネクション設立を要求する。この受信者に対する
コネクション設立要求には、まだ、受信者に対してコネ
クションが張られていないため、経路制御部が提供する
通常のマルチキャストが用いられる。各中間ノードにお
いてこの要求を転送した下位ノードを記録しておき、確
認応答の集計に備える。
し、コネクション設立を要求する。この受信者に対する
コネクション設立要求には、まだ、受信者に対してコネ
クションが張られていないため、経路制御部が提供する
通常のマルチキャストが用いられる。各中間ノードにお
いてこの要求を転送した下位ノードを記録しておき、確
認応答の集計に備える。
【００６７】次に、ステップＳ５３において、コネクシ
ョンの設立を必要とするか否かが判定される。即ち、こ
の要求を受けた受信者が、全送信者からの受信を望んで
いた場合、新たな送信者との間のコネクションの設立が
必要であるとし、ステップＳ５４に進む。
ョンの設立を必要とするか否かが判定される。即ち、こ
の要求を受けた受信者が、全送信者からの受信を望んで
いた場合、新たな送信者との間のコネクションの設立が
必要であるとし、ステップＳ５４に進む。
【００６８】ステップＳ５４においては、受信者は、新
しい送信者に対して、コネクションの設立を行う。ここ
でのコネクションの設立は、ＳＴ−ＩＩ（Internet Str
eamProtocol,Version 2）のように、送信者からの要求
メッセージにより構成されたツリーに沿って行われるの
ではなく、受信者の要求を考慮して通常のコネクション
設立と同様にして行われる。
しい送信者に対して、コネクションの設立を行う。ここ
でのコネクションの設立は、ＳＴ−ＩＩ（Internet Str
eamProtocol,Version 2）のように、送信者からの要求
メッセージにより構成されたツリーに沿って行われるの
ではなく、受信者の要求を考慮して通常のコネクション
設立と同様にして行われる。
【００６９】次に、ステップＳ５５に進み、コネクショ
ンの設立が完了した場合、コネクション設立完了の確認
応答を送信者に対して送信する。
ンの設立が完了した場合、コネクション設立完了の確認
応答を送信者に対して送信する。
【００７０】一方、ステップＳ５３において、コネクシ
ョンの設立を必要としないと判定された場合、即ち、受
信者が送信者とのコネクションの設立を拒否した場合、
ステップＳ５６に進み、拒否メッセージが送信者に送り
返される。
ョンの設立を必要としないと判定された場合、即ち、受
信者が送信者とのコネクションの設立を拒否した場合、
ステップＳ５６に進み、拒否メッセージが送信者に送り
返される。
【００７１】ステップＳ５５における確認応答およびス
テップＳ５６における拒否メッセージは、送信者からの
コネクション設立要求が受信者に転送されてきた時に構
成されたツリーに沿って、送信者に送られる。
テップＳ５６における拒否メッセージは、送信者からの
コネクション設立要求が受信者に転送されてきた時に構
成されたツリーに沿って、送信者に送られる。
【００７２】次に、ステップＳ５７において、コネクシ
ョン設立の確認を行う。即ち、送信者は、全下位ノード
からの確認応答または拒否メッセージが来るのを待ち、
全下位ノードからの確認応答または拒否メッセージが来
た時点で、送信者参加手続きを終了する。
ョン設立の確認を行う。即ち、送信者は、全下位ノード
からの確認応答または拒否メッセージが来るのを待ち、
全下位ノードからの確認応答または拒否メッセージが来
た時点で、送信者参加手続きを終了する。
【００７３】ここで、拒否メッセージが来た場合には、
送信者はグループへの参加を許されない。この場合、既
に行われた送信者参加手続きの取り消し処理を行う。
送信者はグループへの参加を許されない。この場合、既
に行われた送信者参加手続きの取り消し処理を行う。
【００７４】この機構により、送信者が新たに参加した
場合、既存の受信者に対して自動的にコネクションが設
立され、受信者は新しい送信者からのデータを受け取る
ことが可能となる。
場合、既存の受信者に対して自動的にコネクションが設
立され、受信者は新しい送信者からのデータを受け取る
ことが可能となる。
【００７５】次に、受信者が参加する場合の処理につい
て、図７のフローチャートを参照して説明する。１対多
の場合と比較して異なる点は、送信者が複数存在する可
能性があるため、各送信者についてコネクション設立を
行う必要がある点である。この際、コネクションの共有
可能性などのコネクションの性質も考慮する必要があ
る。
て、図７のフローチャートを参照して説明する。１対多
の場合と比較して異なる点は、送信者が複数存在する可
能性があるため、各送信者についてコネクション設立を
行う必要がある点である。この際、コネクションの共有
可能性などのコネクションの性質も考慮する必要があ
る。
【００７６】まず、ステップＳ６１において、受信者は
送信者グループに対してリストを要求する。次に、ステ
ップＳ６２において、リストを得た受信者は、各送信者
についてコネクション設立処理を行う。この際、既に設
立されているコネクションと共有可能な場合は、送信者
が異なるときにも、それ以上の資源予約を行わない。た
だし、コネクション設立要求は上位ノードに送られる。
これは、送信者が異なる場合、既設コネクションが対象
送信者まで張られているとは限らないためである。
送信者グループに対してリストを要求する。次に、ステ
ップＳ６２において、リストを得た受信者は、各送信者
についてコネクション設立処理を行う。この際、既に設
立されているコネクションと共有可能な場合は、送信者
が異なるときにも、それ以上の資源予約を行わない。た
だし、コネクション設立要求は上位ノードに送られる。
これは、送信者が異なる場合、既設コネクションが対象
送信者まで張られているとは限らないためである。
【００７７】また、受信者が脱退する場合にも、１対多
通信のときのように、単純にコネクションを破棄するの
ではなく、それが共有されているか否かの確認を行い、
共有されている場合には解放しないようにする。コネク
ション設立時の場合と同様に、破棄要求自体は上位ノー
ドに転送される。
通信のときのように、単純にコネクションを破棄するの
ではなく、それが共有されているか否かの確認を行い、
共有されている場合には解放しないようにする。コネク
ション設立時の場合と同様に、破棄要求自体は上位ノー
ドに転送される。
【００７８】なお、新たな送信者または受信者の参加要
求は、既存のコネクションを設立している送信者および
受信者のＱＯＳ要求を必ず保証するという条件で受理さ
れる。
求は、既存のコネクションを設立している送信者および
受信者のＱＯＳ要求を必ず保証するという条件で受理さ
れる。
【００７９】次に、ＲｔＭＰの実装について説明する。
実時間オペレーティングシステムであるＲＴ−Ｍａｃｈ
（Real-Time Mach）マイクロカーネル上で動作するＲＴ
Ｓ／ＮＰＳ（Real-Time Server/Network Protocol Serv
er）環境上で実装を行った。ここでは、ＮＰＳ内の１プ
ロトコルとしてＲｔＭＰを実装し、同時に協調して経路
制御を行うサーバ、および各ネットワークセグメントの
ネットワーク資源を管理するサーバの実装も行った。
実時間オペレーティングシステムであるＲＴ−Ｍａｃｈ
（Real-Time Mach）マイクロカーネル上で動作するＲＴ
Ｓ／ＮＰＳ（Real-Time Server/Network Protocol Serv
er）環境上で実装を行った。ここでは、ＮＰＳ内の１プ
ロトコルとしてＲｔＭＰを実装し、同時に協調して経路
制御を行うサーバ、および各ネットワークセグメントの
ネットワーク資源を管理するサーバの実装も行った。
【００８０】図８は、ＲｔＭＰの内部構造の例を示して
いる。ＲｔＭＰは、上述したように実時間オペレーティ
ングシステムであるＲＴ−Ｍａｃｈ Ｍｉｃｒｏ Ｋｅ
ｒｎｅｌ２３上で動作するネットワークプロトコルサー
バ（Ｎｅｔｗｏｒｋ Ｐｒｏｔｏｃｏｌ Ｓｅｒｖｅ
ｒ）２０内の１つのプロトコルとして実装され、ネット
ワークプロトコルサーバ２０は、ネットワークデバイス
レイヤ１５、プロトコルレイヤ１６、およびインタフェ
ースレイヤ１７より構成されている。ネットワークプロ
トコルサーバ２０と経路制御を行うルーティングサーバ
（ＲｏｕｔｉｎｇＳｅｒｖｅｒ）２１は、所定のインタ
フェース処理等を行うコントロールスレッド（Ｃｏｎｔ
ｒｏｌ ｔｈｒｅａｄ）１４を介して情報のやりとりを
行うようになされている。
いる。ＲｔＭＰは、上述したように実時間オペレーティ
ングシステムであるＲＴ−Ｍａｃｈ Ｍｉｃｒｏ Ｋｅ
ｒｎｅｌ２３上で動作するネットワークプロトコルサー
バ（Ｎｅｔｗｏｒｋ Ｐｒｏｔｏｃｏｌ Ｓｅｒｖｅ
ｒ）２０内の１つのプロトコルとして実装され、ネット
ワークプロトコルサーバ２０は、ネットワークデバイス
レイヤ１５、プロトコルレイヤ１６、およびインタフェ
ースレイヤ１７より構成されている。ネットワークプロ
トコルサーバ２０と経路制御を行うルーティングサーバ
（ＲｏｕｔｉｎｇＳｅｒｖｅｒ）２１は、所定のインタ
フェース処理等を行うコントロールスレッド（Ｃｏｎｔ
ｒｏｌ ｔｈｒｅａｄ）１４を介して情報のやりとりを
行うようになされている。
【００８１】データ転送の実時間性は、設立されたコネ
クション毎に、ｉｎｐｕｔ／ｏｕｔｐｕｔ処理を行う周
期的実時間スレッド（ｏｕｔｐｕｔ ｔｈｒｅａｄ、ｌ
ｏｃａｌ ｓｅｎｄ ｔｈｒｅａｄ、およびｆｏｒｗａ
ｒｄｅｒ ｔｈｒｅａｄ）と専用バッファを割り当てる
ことにより保証する。コネクション設立要求などの制御
メッセージは実時間性を保証する必要がないため、ＮＰ
Ｓ汎用のコントロールスレッド１４によって処理され
る。
クション毎に、ｉｎｐｕｔ／ｏｕｔｐｕｔ処理を行う周
期的実時間スレッド（ｏｕｔｐｕｔ ｔｈｒｅａｄ、ｌ
ｏｃａｌ ｓｅｎｄ ｔｈｒｅａｄ、およびｆｏｒｗａ
ｒｄｅｒ ｔｈｒｅａｄ）と専用バッファを割り当てる
ことにより保証する。コネクション設立要求などの制御
メッセージは実時間性を保証する必要がないため、ＮＰ
Ｓ汎用のコントロールスレッド１４によって処理され
る。
【００８２】次に、各メッセージがどのように処理され
るかについて説明する。ネットワークデバイス層（Ｎｅ
ｔｗｏｒｋ ｄｅｖｉｃｅ ｌａｙｅｒ）１５のネット
ワークデバイスドライバによって受け取られたパケット
は、まず、プロトコルレイヤ（Ｐｒｏｔｏｃｏｌ ｌａ
ｙｅｒ）１６のデータリンクプロトコルに割り当てられ
ている高い優先度の「ｉｎｐｕｔ ｔｈｒｅａｄ」（図
８においては、ｅｔｈｅｒ ｉｎｐｕｔ ｔｈｒｅａｄ
１９）によって処理される。ここでは、ｅｔｈｅｒのパ
ケットヘッダの「ｐｒｏｔｏｃｏｌ ｔｙｐｅ」に従っ
て、上位プロトコルの入力処理ルーチン（ＲｔＭＰ入力
処理ルーチン）が呼び出される。
るかについて説明する。ネットワークデバイス層（Ｎｅ
ｔｗｏｒｋ ｄｅｖｉｃｅ ｌａｙｅｒ）１５のネット
ワークデバイスドライバによって受け取られたパケット
は、まず、プロトコルレイヤ（Ｐｒｏｔｏｃｏｌ ｌａ
ｙｅｒ）１６のデータリンクプロトコルに割り当てられ
ている高い優先度の「ｉｎｐｕｔ ｔｈｒｅａｄ」（図
８においては、ｅｔｈｅｒ ｉｎｐｕｔ ｔｈｒｅａｄ
１９）によって処理される。ここでは、ｅｔｈｅｒのパ
ケットヘッダの「ｐｒｏｔｏｃｏｌ ｔｙｐｅ」に従っ
て、上位プロトコルの入力処理ルーチン（ＲｔＭＰ入力
処理ルーチン）が呼び出される。
【００８３】次に、ＲｔＭＰ入力処理ルーチンにより、
ＲｔＭＰパケットヘッダの「ｔｙｐｅ ｆｉｅｌｄ」の
内容に基づいて、それがユーザデータおよび制御メッセ
ージのいずれであるかが判別され、適切なスレッドにデ
ィスパッチされる。
ＲｔＭＰパケットヘッダの「ｔｙｐｅ ｆｉｅｌｄ」の
内容に基づいて、それがユーザデータおよび制御メッセ
ージのいずれであるかが判別され、適切なスレッドにデ
ィスパッチされる。
【００８４】ユーザデータであると判定された場合、宛
先グループアドレスからコネクションテーブル（ＲｔＭ
Ｐ＿ＰＯＲＴ）１８が検索される。ＲｔＭＰ＿ＰＯＲＴ
１８の経路情報部に従って、各コネクション毎に、ロー
カルに存在する受信者に転送するスレッド（図８におい
ては、ｌｏｃａｌ ｓｅｎｄ ｔｈｒｅａｄ１２）と下
位ノードに転送するためのスレッド（図８においては、
ｆｏｒｗａｒｄｅｒｔｈｒｅａｄ１３）にデータが引き
渡される。ｌｏｃａｌ ｓｅｎｄ ｔｈｒｅａｄ１２
は、データを各受信者の受信バッファに入れる処理を担
当し、ｆｏｒｗａｒｄｅｒ−ｔｈｒｅａｄ１３は、Ｒｔ
ＭＰ＿ＰＯＲＴ１８に示される下位ノードに対するデー
タ転送を行う。
先グループアドレスからコネクションテーブル（ＲｔＭ
Ｐ＿ＰＯＲＴ）１８が検索される。ＲｔＭＰ＿ＰＯＲＴ
１８の経路情報部に従って、各コネクション毎に、ロー
カルに存在する受信者に転送するスレッド（図８におい
ては、ｌｏｃａｌ ｓｅｎｄ ｔｈｒｅａｄ１２）と下
位ノードに転送するためのスレッド（図８においては、
ｆｏｒｗａｒｄｅｒｔｈｒｅａｄ１３）にデータが引き
渡される。ｌｏｃａｌ ｓｅｎｄ ｔｈｒｅａｄ１２
は、データを各受信者の受信バッファに入れる処理を担
当し、ｆｏｒｗａｒｄｅｒ−ｔｈｒｅａｄ１３は、Ｒｔ
ＭＰ＿ＰＯＲＴ１８に示される下位ノードに対するデー
タ転送を行う。
【００８５】一方、制御メッセージであると判別された
場合、宛先グループアドレスからＲｔＭＰ＿ＰＯＲＴ１
８が検索される。コネクションの状態と、各メッセージ
タイプに従って処理が行われ、必要に応じて、Ｒｏｕｔ
ｉｎｇ−Ｓｅｒｖｅｒ２１、図示せぬＮｅｔｗｏｒｋ
Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｒ、その他のノードに
転送される。
場合、宛先グループアドレスからＲｔＭＰ＿ＰＯＲＴ１
８が検索される。コネクションの状態と、各メッセージ
タイプに従って処理が行われ、必要に応じて、Ｒｏｕｔ
ｉｎｇ−Ｓｅｒｖｅｒ２１、図示せぬＮｅｔｗｏｒｋ
Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｒ、その他のノードに
転送される。
【００８６】このように、プロトコル制御を行うスレッ
ドとデータ転送を行うスレッドを分離し、専用のバッフ
ァを割り当てることにより、データ転送が他の処理によ
って妨げられることを抑制し、要求されたＦｌｏｗｓｐ
ｅｃ通りのデータ転送を保証することができる。
ドとデータ転送を行うスレッドを分離し、専用のバッフ
ァを割り当てることにより、データ転送が他の処理によ
って妨げられることを抑制し、要求されたＦｌｏｗｓｐ
ｅｃ通りのデータ転送を保証することができる。
【００８７】次に、上記ＲｔＭＰの性能評価、既存のプ
ロトコルとの比較を行い、ＲｔＭＰの有効性について検
討する。
ロトコルとの比較を行い、ＲｔＭＰの有効性について検
討する。
【００８８】まず、性能評価を行う。専用Ｅｔｈｅｒｎ
ｅｔで接続されたＰＣ−ＡＴ互換機（ＣＰＵ：Ｐｅｎｔ
ｉｕｍ ９０ＭＨｚ）上で、ＲｔＭＰの各プリミティブ
についての性能評価を行った。
ｅｔで接続されたＰＣ−ＡＴ互換機（ＣＰＵ：Ｐｅｎｔ
ｉｕｍ ９０ＭＨｚ）上で、ＲｔＭＰの各プリミティブ
についての性能評価を行った。
【００８９】図９は、他のメンバが同一のセグメントに
いる場合と隣接セグメントにいる場合とについて、受信
者、送信者の参加に要する時間を示している。上段は送
信者のみが存在するグループに受信者が参加する場合、
下段は送信者が１、受信者が１のグループ（送信者と受
信者は同一のセグメントに存在する）に新たに送信者が
加わる場合について測定した結果である。
いる場合と隣接セグメントにいる場合とについて、受信
者、送信者の参加に要する時間を示している。上段は送
信者のみが存在するグループに受信者が参加する場合、
下段は送信者が１、受信者が１のグループ（送信者と受
信者は同一のセグメントに存在する）に新たに送信者が
加わる場合について測定した結果である。
【００９０】この結果から、コネクション設立時間は、
接続ノードおよび送信者までの距離とに影響されること
がわかる。また、受信者数が増加した場合もコネクショ
ン設立時間の増加はなく、むしろ既設コネクションとの
距離が短くなることにより、設立時間が短縮されたこと
がわかる。
接続ノードおよび送信者までの距離とに影響されること
がわかる。また、受信者数が増加した場合もコネクショ
ン設立時間の増加はなく、むしろ既設コネクションとの
距離が短くなることにより、設立時間が短縮されたこと
がわかる。
【００９１】次に、ＲｔＭＰのプロトコルオーバヘッド
（パケットヘッダの構築および解析、コネクション情報
の検索、コネクションに従ったデータ転送等に要する時
間など）を反映し、アプリケーションの性能に最も影響
するメッセージ送信のラウンドトリップ時間をメッセー
ジサイズについて測定した結果について説明する。
（パケットヘッダの構築および解析、コネクション情報
の検索、コネクションに従ったデータ転送等に要する時
間など）を反映し、アプリケーションの性能に最も影響
するメッセージ送信のラウンドトリップ時間をメッセー
ジサイズについて測定した結果について説明する。
【００９２】図１０は、その測定結果を表したグラフで
ある。縦軸はラウンドトリップ時間（単位はミリ秒（ｍ
ｓｅｃ））を表しており、横軸はメッセージサイズ（単
位はバイト（ｂｙｔｅｓ））を表している。点線で表し
たグラフは、他のメンバが同一セグメントにいる場合に
おけるＵＤＰ／ＩＰ（User Datagram Protocol/Interne
t Protocol）の往復通信遅延時間（raund trip time）
を表し、１点鎖線で表したグラフは、同様に、他のメン
バが同一セグメントにいる場合におけるＲｔＭＰによる
往復通信遅延時間を表している。さらに、実線で表した
グラフは、他のメンバが隣接セグメントにいる場合にお
けるＲｔＭＰによる往復通信遅延時間を表している。
ある。縦軸はラウンドトリップ時間（単位はミリ秒（ｍ
ｓｅｃ））を表しており、横軸はメッセージサイズ（単
位はバイト（ｂｙｔｅｓ））を表している。点線で表し
たグラフは、他のメンバが同一セグメントにいる場合に
おけるＵＤＰ／ＩＰ（User Datagram Protocol/Interne
t Protocol）の往復通信遅延時間（raund trip time）
を表し、１点鎖線で表したグラフは、同様に、他のメン
バが同一セグメントにいる場合におけるＲｔＭＰによる
往復通信遅延時間を表している。さらに、実線で表した
グラフは、他のメンバが隣接セグメントにいる場合にお
けるＲｔＭＰによる往復通信遅延時間を表している。
【００９３】上記グラフから分かるように、単純なＵＤ
Ｐと比較しても、ＲｔＭＰのプロトコルオーバヘッドは
同程度であり、十分な性能を出していることがわかる。
Ｐと比較しても、ＲｔＭＰのプロトコルオーバヘッドは
同程度であり、十分な性能を出していることがわかる。
【００９４】次に、実時間マルチキャストプロトコルに
必要とされる機構について、ＲｔＭＰと他のプロトコル
（ＳＴ−ＩＩ、ＲＳＶＰ（Resource ReSerVation Proto
col））との比較を行い、特に、ＲｔＭＰの特徴である
受信者からの経路選択機構の有効性、および既設コネク
ションの保証について検討する。
必要とされる機構について、ＲｔＭＰと他のプロトコル
（ＳＴ−ＩＩ、ＲＳＶＰ（Resource ReSerVation Proto
col））との比較を行い、特に、ＲｔＭＰの特徴である
受信者からの経路選択機構の有効性、および既設コネク
ションの保証について検討する。
【００９５】最初に、コネクション設立の柔軟性につい
て説明する。まず、送信者および受信者から指定された
要求に対する適応度について考察する。各コネクション
のＦｌｏｗｓｐｅｃは、各受信者の要求、および利用可
能な資源の量によって定められる。送信者から送られた
データは、指定された優先度レベルにより転送可能性が
判断され、転送可能なコネクションにのみ送られる。
て説明する。まず、送信者および受信者から指定された
要求に対する適応度について考察する。各コネクション
のＦｌｏｗｓｐｅｃは、各受信者の要求、および利用可
能な資源の量によって定められる。送信者から送られた
データは、指定された優先度レベルにより転送可能性が
判断され、転送可能なコネクションにのみ送られる。
【００９６】従って、受信者の要求が高く、経路上で利
用可能な資源が多いホストでは高いＱＯＳ（Quality Of
Service）のデータを、また、受信者の要求が低いか、
または利用可能な資源が乏しい場合は、低いＱＯＳのデ
ータをそれぞれ受け取ることができ、多種多様な受信者
の要求、および各経路の特性に対応することができる。
用可能な資源が多いホストでは高いＱＯＳ（Quality Of
Service）のデータを、また、受信者の要求が低いか、
または利用可能な資源が乏しい場合は、低いＱＯＳのデ
ータをそれぞれ受け取ることができ、多種多様な受信者
の要求、および各経路の特性に対応することができる。
【００９７】次に、ＲｔＭＰの最大の特徴である経路制
御部と、資源予約プロトコルとの統合の効果について説
明する。ＲｔＭＰにおいては、経路の資源予約に関する
パラメータのみをＲｔＭＰ側で管理し、受信者からの要
求に応じて経路選択を行うことにより、経路制御アルゴ
リズムに依存することなく、送信者および受信者の要求
に適応したツリーの構築を可能としている。ＳＴ−ＩＩ
やＲＳＶＰにおいては、資源予約機構は経路制御とは独
立に設計されているため、受信者の要求に応じた経路制
御は困難である。
御部と、資源予約プロトコルとの統合の効果について説
明する。ＲｔＭＰにおいては、経路の資源予約に関する
パラメータのみをＲｔＭＰ側で管理し、受信者からの要
求に応じて経路選択を行うことにより、経路制御アルゴ
リズムに依存することなく、送信者および受信者の要求
に適応したツリーの構築を可能としている。ＳＴ−ＩＩ
やＲＳＶＰにおいては、資源予約機構は経路制御とは独
立に設計されているため、受信者の要求に応じた経路制
御は困難である。
【００９８】さらに、他のコネクション設立と競合する
ため、経路制御部によって提案された経路が要求を満た
すことができない場合には、他の経路を選択することに
よって、再度コネクションの設立を試みる。これによ
り、コネクション設立の可能性はさらに向上する。
ため、経路制御部によって提案された経路が要求を満た
すことができない場合には、他の経路を選択することに
よって、再度コネクションの設立を試みる。これによ
り、コネクション設立の可能性はさらに向上する。
【００９９】これらのことから、ＲｔＭＰは、既存の実
時間マルチキャストプロトコルと比較して、より送信者
および受信者からの要求に応じた柔軟性の高いコネクシ
ョン設立機構を提供するということができる。
時間マルチキャストプロトコルと比較して、より送信者
および受信者からの要求に応じた柔軟性の高いコネクシ
ョン設立機構を提供するということができる。
【０１００】次に、既設コネクションの保証について説
明する。資源予約方式の実時間通信プロトコルは、実時
間性を満たすことを最大の目的とし、そのために予めコ
ネクションを設立し、必要な資源を予約する。従って、
一度設立されたコネクションは、ホストおよびネットワ
ークの障害発生時を除き、コネクション設立時の要求を
常に満たすことを保証しなければならない。
明する。資源予約方式の実時間通信プロトコルは、実時
間性を満たすことを最大の目的とし、そのために予めコ
ネクションを設立し、必要な資源を予約する。従って、
一度設立されたコネクションは、ホストおよびネットワ
ークの障害発生時を除き、コネクション設立時の要求を
常に満たすことを保証しなければならない。
【０１０１】１対多通信においては、ＳＴ−ＩＩおよび
ＲｔＭＰにおいて、コネクション設立時に、新たなコネ
クションの設立が既設のコネクションを乱さないことを
確認する。その後、コネクションが変更されることはな
いため、既設コネクション上のデータ送信は、常に要求
を満たすことが保証される。
ＲｔＭＰにおいて、コネクション設立時に、新たなコネ
クションの設立が既設のコネクションを乱さないことを
確認する。その後、コネクションが変更されることはな
いため、既設コネクション上のデータ送信は、常に要求
を満たすことが保証される。
【０１０２】多対多通信においては、重要な特性の１つ
として、グループの性質を考慮した複数の送信者による
コネクションの共有が挙げられ、ＲＳＶＰおよびＲｔＭ
Ｐはこの機構を提供する。ここで、複数の送信者が１つ
のコネクションを同時に使用しようとした場合、転送デ
ータのオーバフローが生じ、双方ともデータ転送を保証
することは不可能となる。
として、グループの性質を考慮した複数の送信者による
コネクションの共有が挙げられ、ＲＳＶＰおよびＲｔＭ
Ｐはこの機構を提供する。ここで、複数の送信者が１つ
のコネクションを同時に使用しようとした場合、転送デ
ータのオーバフローが生じ、双方ともデータ転送を保証
することは不可能となる。
【０１０３】ＲｔＭＰにおいては、コネクションの共有
などの性質を送信者が決定し、送信者リストにより送信
者間で協調し合うことを可能としているため、転送デー
タのオーバフローの発生を防ぐことができる。これに対
して、ＲＳＶＰにおいては、コネクションの共有は受信
者によって決められ、送信者側からの保証がなされな
い。従って、多対多通信においても、ＲｔＭＰはＲＳＶ
Ｐと比較して既設コネクションをより保証していると言
える。
などの性質を送信者が決定し、送信者リストにより送信
者間で協調し合うことを可能としているため、転送デー
タのオーバフローの発生を防ぐことができる。これに対
して、ＲＳＶＰにおいては、コネクションの共有は受信
者によって決められ、送信者側からの保証がなされな
い。従って、多対多通信においても、ＲｔＭＰはＲＳＶ
Ｐと比較して既設コネクションをより保証していると言
える。
【０１０４】次に、プロトコルの耐障害性について説明
する。ＲｔＭＰおよびＳＴ−ＩＩは、隣接ノードを監視
することにより、障害発生の検知および障害対策を行
う。ＲＳＶＰにおいては、障害の発生をプロトコル自身
で監視するのではなく、独立した経路制御アルゴリズム
によって監視され、障害の発生が検知されると、経路ア
ルゴリズムによって経路変更が行われ、自動的にツリー
構造が変更されるようになされている。このことから、
障害に対する柔軟性という点においては、ＲＳＶＰは非
常に柔軟であるということができる。
する。ＲｔＭＰおよびＳＴ−ＩＩは、隣接ノードを監視
することにより、障害発生の検知および障害対策を行
う。ＲＳＶＰにおいては、障害の発生をプロトコル自身
で監視するのではなく、独立した経路制御アルゴリズム
によって監視され、障害の発生が検知されると、経路ア
ルゴリズムによって経路変更が行われ、自動的にツリー
構造が変更されるようになされている。このことから、
障害に対する柔軟性という点においては、ＲＳＶＰは非
常に柔軟であるということができる。
【０１０５】しかしながら、実時間通信という点を考慮
に入れた場合、障害の発生によるデータ転送の停止は致
命的である。従って、他の機構によって自動的に経路が
切り替えられるのではなく、実時間通信プロトコルによ
ってユーザへの通知および適切な処理が行われる必要が
ある。このような処理を行う場合においては、ＲＳＶＰ
より、ＳＴ−ＩＩやＲｔＭＰの方が適しているといえ
る。
に入れた場合、障害の発生によるデータ転送の停止は致
命的である。従って、他の機構によって自動的に経路が
切り替えられるのではなく、実時間通信プロトコルによ
ってユーザへの通知および適切な処理が行われる必要が
ある。このような処理を行う場合においては、ＲＳＶＰ
より、ＳＴ−ＩＩやＲｔＭＰの方が適しているといえ
る。
【０１０６】以上、従来分離されていたマルチキャスト
経路制御機構とコネクション設立機構の統合、およびそ
れに基づいた実時間マルチキャストプロトコルＲｔＭＰ
について述べた。上述したように、ＲｔＭＰは、受信者
からの要求を経路制御に反映することにより、多種多様
な受信者の要求に対応することが可能であり、また、送
信者リストの管理機構により効率がよく、かつサービス
レベルを保証する多対多通信を提供することができる。
経路制御機構とコネクション設立機構の統合、およびそ
れに基づいた実時間マルチキャストプロトコルＲｔＭＰ
について述べた。上述したように、ＲｔＭＰは、受信者
からの要求を経路制御に反映することにより、多種多様
な受信者の要求に対応することが可能であり、また、送
信者リストの管理機構により効率がよく、かつサービス
レベルを保証する多対多通信を提供することができる。
【０１０７】なお、上記実施例においては、ＲｔＭＰを
ＲＴ−Ｍａｃｈ上で実装した場合について説明したが、
これに限定されるものではない。
ＲＴ−Ｍａｃｈ上で実装した場合について説明したが、
これに限定されるものではない。
【０１０８】また、本発明は、ＡＴＭ（Asynchronous T
ransfer Mode）などの新しいネットワークアーキテクチ
ャに適用することも可能である。
ransfer Mode）などの新しいネットワークアーキテクチ
ャに適用することも可能である。
【０１０９】
【発明の効果】請求項１に記載の通信制御方法によれ
ば、受信者からの要求に基づいて、送信者と受信者との
間の経路を選択し、コネクションを設立する経路選択機
構と、経路の資源を予約する資源予約機構の間のインタ
フェースを規定し、経路選択機構と資源予約機構とを統
合するようにしたので、１対多通信において、受信者の
要求に応じた経路を選択し、コネクションを設立するこ
とができ、既設のコネクションの品質を保証することが
可能となる。
ば、受信者からの要求に基づいて、送信者と受信者との
間の経路を選択し、コネクションを設立する経路選択機
構と、経路の資源を予約する資源予約機構の間のインタ
フェースを規定し、経路選択機構と資源予約機構とを統
合するようにしたので、１対多通信において、受信者の
要求に応じた経路を選択し、コネクションを設立するこ
とができ、既設のコネクションの品質を保証することが
可能となる。
【０１１０】請求項３に記載の通信制御方法によれば、
各送信者が保持する各送信者のリストに基づいて、受信
者から各送信者に対してコネクションの設立を行い、複
数の送信者がコネクションを共有する場合、コネクショ
ンに予約された資源の量に基づいて、コネクションを介
してデータを受信者に同時に送信する送信者の数を所定
数以下に制限し、新たな送信者または受信者のネットワ
ークへの参加要求は、新たな送信者または受信者がネッ
トワークに参加した場合においても、既存のコネクショ
ンを設立している送信者および受信者のＱＯＳ要求が保
証されるとき、受理されるようにしたので、多対多通信
を実現し、かつ、既設のコネクションの品質を乱さない
ことを保証することが可能となる。
各送信者が保持する各送信者のリストに基づいて、受信
者から各送信者に対してコネクションの設立を行い、複
数の送信者がコネクションを共有する場合、コネクショ
ンに予約された資源の量に基づいて、コネクションを介
してデータを受信者に同時に送信する送信者の数を所定
数以下に制限し、新たな送信者または受信者のネットワ
ークへの参加要求は、新たな送信者または受信者がネッ
トワークに参加した場合においても、既存のコネクショ
ンを設立している送信者および受信者のＱＯＳ要求が保
証されるとき、受理されるようにしたので、多対多通信
を実現し、かつ、既設のコネクションの品質を乱さない
ことを保証することが可能となる。
【図１】経路制御部と資源予約機構間のインタフェース
の例を示す図である。
の例を示す図である。
【図２】互いに異なる転送能力の経路が分岐する中間ノ
ードの例を示す図である。
ードの例を示す図である。
【図３】優先度レベルとデータ転送レートの対応関係の
例を示す図である。
例を示す図である。
【図４】コネクション設立手順の例を説明するための図
である。
である。
【図５】障害発生時の処理手順の例を説明するためのフ
ローチャートである。
ローチャートである。
【図６】送信者参加時のコネクション設立手順の例を説
明するためのフローチャートである。
明するためのフローチャートである。
【図７】受信者参加時のコネクション設立手順の例を説
明するためのフローチャートである。
明するためのフローチャートである。
【図８】ＲｔＭＰの内部構成例を示す図である。
【図９】受信者および送信者の参加に要する時間を示す
図である。
図である。
【図１０】ラウンドトリップ時間とメッセージサイズの
関係を示すグラフである。
関係を示すグラフである。
【図１１】従来のプロトコルＳＴ−ＩＩとＲＳＶＰの特
徴を示す図である。
徴を示す図である。
１乃至６ ホスト，１１ アウトプットスレッド（Ｏｕ
ｔｐｕｔ ｔｈｒｅａｄ），１２ ローカルセンドスレ
ッド（Ｌｏｃａｌ ｓｅｎｄ ｔｈｒｅａｄ），１３
フォワーダスレッド（Ｆｏｒｗａｒｄｅｒ ｔｈｒｅａ
ｄ），１４ コントロールスレッド（Ｃｏｎｔｒｏｌ
ｔｈｒｅａｄ），１５ ネットワークデバイスレイヤ
（Ｎｅｔｗｏｒｋ ｄｅｖｉｃｅ ｌａｙｅｒ），１６
プロトコルレイヤ（Ｐｒｏｔｏｃｏｌ Ｌａｙｅ
ｒ），１７ インタフェースレイヤ（Ｉｎｔｅｒｆａｃ
ｅ Ｌａｙｅｒ），１８ コネクションテーブル（Ｃｏ
ｎｎｅｃｔｉｏｎ ｔａｂｌｅ），１９ イーサインプ
ットスレッド（Ｅｔｈｅｒ ｉｎｐｕｔ ｔｈｒｅａ
ｄ），２０ ネットワークプロトコルサーバ（Ｎｅｔｗ
ｏｒｋ Ｐｒｏｔｏｃｏｌ Ｓｅｒｖｅｒ），２１ ル
ーティングサーバ（Ｒｏｕｔｉｎｇ Ｓｅｒｖｅｒ），
２２ アプリケーション（Ａｐｐｌｉｃａｔｉｏｎ
ｓ），２３ ＲＴ−Ｍａｃｈマイクロカーネル（ＲＴ−
Ｍａｃｈ Ｍｉｃｒｏ Ｋｅｒｎｅｌ）
ｔｐｕｔ ｔｈｒｅａｄ），１２ ローカルセンドスレ
ッド（Ｌｏｃａｌ ｓｅｎｄ ｔｈｒｅａｄ），１３
フォワーダスレッド（Ｆｏｒｗａｒｄｅｒ ｔｈｒｅａ
ｄ），１４ コントロールスレッド（Ｃｏｎｔｒｏｌ
ｔｈｒｅａｄ），１５ ネットワークデバイスレイヤ
（Ｎｅｔｗｏｒｋ ｄｅｖｉｃｅ ｌａｙｅｒ），１６
プロトコルレイヤ（Ｐｒｏｔｏｃｏｌ Ｌａｙｅ
ｒ），１７ インタフェースレイヤ（Ｉｎｔｅｒｆａｃ
ｅ Ｌａｙｅｒ），１８ コネクションテーブル（Ｃｏ
ｎｎｅｃｔｉｏｎ ｔａｂｌｅ），１９ イーサインプ
ットスレッド（Ｅｔｈｅｒ ｉｎｐｕｔ ｔｈｒｅａ
ｄ），２０ ネットワークプロトコルサーバ（Ｎｅｔｗ
ｏｒｋ Ｐｒｏｔｏｃｏｌ Ｓｅｒｖｅｒ），２１ ル
ーティングサーバ（Ｒｏｕｔｉｎｇ Ｓｅｒｖｅｒ），
２２ アプリケーション（Ａｐｐｌｉｃａｔｉｏｎ
ｓ），２３ ＲＴ−Ｍａｃｈマイクロカーネル（ＲＴ−
Ｍａｃｈ Ｍｉｃｒｏ Ｋｅｒｎｅｌ）
Claims (4)
- 【請求項１】 ネットワーク上の複数の送信者と複数の
受信者との間にコネクションを設立し、前記送信者と前
記受信者との間の通信を制御する通信制御方法におい
て、 前記受信者からの要求に基づいて、前記送信者と前記受
信者との間の経路を選択し、前記コネクションを設立す
る経路選択機構と、前記経路の資源を予約する資源予約
機構の間のインタフェースを規定し、前記経路選択機構
と前記資源予約機構とを統合することを特徴とする通信
制御方法。 - 【請求項２】 前記経路選択機構が前記経路の選択を行
う場合において、前記経路の資源についての評価が必要
なとき、前記資源予約機構は前記インタフェースを介し
て前記経路の資源を評価し、前記経路選択機構は前記評
価結果に基づいて前記経路の選択を行うことを特徴とす
る請求項１に記載の通信制御方法。 - 【請求項３】 ネットワーク上の複数の送信者と複数の
受信者の間にコネクションを設立し、前記送信者から前
記受信者へのデータの転送を制御する通信制御方法にお
いて、 各送信者が保持する各送信者のリストに基づいて、前記
受信者から各送信者に対して前記コネクションの設立を
行い、 複数の前記送信者が前記コネクションを共有する場合、
前記コネクションに予約された資源の量に基づいて、前
記コネクションを介して前記データを前記受信者に同時
に送信する前記送信者の数を所定数以下に制限し、 新たな送信者または受信者の前記ネットワークへの参加
要求は、前記新たな送信者または受信者が前記ネットワ
ークに参加した場合においても、既存の前記コネクショ
ンを設立している前記送信者および受信者のＱＯＳ要求
が保証されるとき、受理されることを特徴とする通信制
御方法。 - 【請求項４】 前記受信者は、前記送信者の所定のもの
からの前記データだけを受信することを特徴とする請求
項３に記載の通信制御方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP8081243A JPH09270793A (ja) | 1996-04-03 | 1996-04-03 | 通信制御方法 |
| US08/829,212 US6314464B1 (en) | 1996-04-03 | 1997-03-31 | Communication control method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP8081243A JPH09270793A (ja) | 1996-04-03 | 1996-04-03 | 通信制御方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH09270793A true JPH09270793A (ja) | 1997-10-14 |
Family
ID=13740985
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP8081243A Withdrawn JPH09270793A (ja) | 1996-04-03 | 1996-04-03 | 通信制御方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6314464B1 (ja) |
| JP (1) | JPH09270793A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7328167B1 (en) | 1999-09-21 | 2008-02-05 | Hitachi, Ltd. | Service reservation system |
| EP1384157A4 (en) * | 2001-04-30 | 2008-12-24 | America Online Inc | ACCESS MANAGEMENT FOR FLOWS MANAGED ON MULTIPLE CONNECTIONS |
| US7694013B2 (en) | 2001-04-30 | 2010-04-06 | Aol Inc. | Duplicating switch for streaming data units to a terminal |
| US8130755B2 (en) | 2001-04-30 | 2012-03-06 | Aol Inc. | Load balancing with direct terminal response |
Families Citing this family (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0825506B1 (en) | 1996-08-20 | 2013-03-06 | Invensys Systems, Inc. | Methods and apparatus for remote process control |
| JP2000090027A (ja) * | 1998-09-10 | 2000-03-31 | Fujitsu Ltd | オブジェクト管理システム、情報処理システム、オブジェクト管理プログラムを記録した記録媒体及び情報処理プログラムを記録した記録媒体 |
| US6618369B1 (en) * | 1998-09-29 | 2003-09-09 | Lg Electronics Inc. | Internet phone protocol |
| US6856627B2 (en) | 1999-01-15 | 2005-02-15 | Cisco Technology, Inc. | Method for routing information over a network |
| US6643773B1 (en) * | 1999-04-13 | 2003-11-04 | Nortel Networks Limited | Apparatus and method for authenticating messages in a multicast |
| US7089530B1 (en) | 1999-05-17 | 2006-08-08 | Invensys Systems, Inc. | Process control configuration system with connection validation and configuration |
| WO2000070417A1 (en) | 1999-05-17 | 2000-11-23 | The Foxboro Company | Process control configuration system with parameterized objects |
| US6788980B1 (en) * | 1999-06-11 | 2004-09-07 | Invensys Systems, Inc. | Methods and apparatus for control using control devices that provide a virtual machine environment and that communicate via an IP network |
| US7054938B2 (en) * | 2000-02-10 | 2006-05-30 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for network service reservations over wireless access networks |
| US6816910B1 (en) * | 2000-02-17 | 2004-11-09 | Netzentry, Inc. | Method and apparatus for limiting network connection resources |
| US7711790B1 (en) * | 2000-08-24 | 2010-05-04 | Foundry Networks, Inc. | Securing an accessible computer system |
| US8572278B2 (en) | 2001-04-30 | 2013-10-29 | Facebook, Inc. | Generating multiple data streams from a single data source |
| US7124166B2 (en) | 2001-04-30 | 2006-10-17 | Aol Llc | Duplicating digital streams for digital conferencing using switching technologies |
| US7331060B1 (en) | 2001-09-10 | 2008-02-12 | Xangati, Inc. | Dynamic DoS flooding protection |
| US8028092B2 (en) | 2002-06-28 | 2011-09-27 | Aol Inc. | Inserting advertising content |
| 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 |
| JP4040628B2 (ja) * | 2003-02-27 | 2008-01-30 | 富士通株式会社 | 通信制御プログラム |
| US20070014289A1 (en) * | 2003-05-21 | 2007-01-18 | Settle Timothy F | Systems and methods of multicast transport call session control for improving forward bandwidth utilization |
| US7761923B2 (en) | 2004-03-01 | 2010-07-20 | Invensys Systems, Inc. | Process control methods and apparatus for intrusion detection, protection and network hardening |
| US7620986B1 (en) | 2004-06-14 | 2009-11-17 | Xangati, Inc. | Defenses against software attacks in distributed computing environments |
| FR2875667A1 (fr) * | 2004-09-22 | 2006-03-24 | France Telecom | Procede de preemption pour la gestion des ressources radio dans un reseau de communication mobile |
| US7860857B2 (en) | 2006-03-30 | 2010-12-28 | Invensys Systems, Inc. | Digital data processing apparatus and methods for improving plant performance |
| US20070286087A1 (en) * | 2006-06-13 | 2007-12-13 | International Business Machines Corporation | Distributed Network Enhanced Wellness Checking |
| US8451731B1 (en) | 2007-07-25 | 2013-05-28 | Xangati, Inc. | Network monitoring using virtual packets |
| US9961094B1 (en) | 2007-07-25 | 2018-05-01 | Xangati, Inc | Symptom detection using behavior probability density, network monitoring of multiple observation value types, and network monitoring using orthogonal profiling dimensions |
| US8639797B1 (en) | 2007-08-03 | 2014-01-28 | Xangati, Inc. | Network monitoring of behavior probability density |
| RU2495476C2 (ru) | 2008-06-20 | 2013-10-10 | Инвенсис Системз, Инк. | Системы и способы для иммерсивного взаимодействия с действительными и/или имитируемыми техническими средствами для управления технологическим процессом, контроля состояния окружающей среды и производственного контроля |
| US20100057860A1 (en) * | 2008-08-29 | 2010-03-04 | Fry Donna M | Confirmation and acknowledgement of transmission reception |
| US8892631B2 (en) * | 2009-04-09 | 2014-11-18 | International Business Machines Corporation | System and method of optimizing digital media processing in a carrier grade web portal environment |
| US10992555B2 (en) | 2009-05-29 | 2021-04-27 | Virtual Instruments Worldwide, Inc. | Recording, replay, and sharing of live network monitoring views |
| US8463964B2 (en) | 2009-05-29 | 2013-06-11 | Invensys Systems, Inc. | Methods and apparatus for control configuration with enhanced change-tracking |
| US8127060B2 (en) | 2009-05-29 | 2012-02-28 | Invensys Systems, Inc | Methods and apparatus for control configuration with control objects that are fieldbus protocol-aware |
| JP4884520B2 (ja) * | 2009-12-07 | 2012-02-29 | インターナショナル・ビジネス・マシーンズ・コーポレーション | データ収集方法およびシステム |
| AU2011205480B2 (en) * | 2010-01-12 | 2015-02-05 | Google Llc | Operating system auto-update procedure |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5467343A (en) * | 1994-07-27 | 1995-11-14 | Motorola, Inc. | Method and device for consolidation of preferential resource constraints |
| JP2776301B2 (ja) * | 1994-08-30 | 1998-07-16 | 日本電気株式会社 | 回線予約装置および方法、回線予約受付装置および方法 |
| US5517494A (en) * | 1994-09-30 | 1996-05-14 | Apple Computer, Inc. | Method and system of multicast routing for groups with a single transmitter |
| GB9501378D0 (en) * | 1995-01-24 | 1995-03-15 | Ibm | A system and method for establishing a communication channel over a heterogeneous network between a source node and a destination node |
| CA2186795A1 (en) | 1995-11-17 | 1997-05-18 | Cormac John Sreenan | Resource management system for a broadband multipoint bridge |
| US5748892A (en) | 1996-03-25 | 1998-05-05 | Citrix Systems, Inc. | Method and apparatus for client managed flow control on a limited memory computer system |
-
1996
- 1996-04-03 JP JP8081243A patent/JPH09270793A/ja not_active Withdrawn
-
1997
- 1997-03-31 US US08/829,212 patent/US6314464B1/en not_active Expired - Fee Related
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7328167B1 (en) | 1999-09-21 | 2008-02-05 | Hitachi, Ltd. | Service reservation system |
| EP1384157A4 (en) * | 2001-04-30 | 2008-12-24 | America Online Inc | ACCESS MANAGEMENT FOR FLOWS MANAGED ON MULTIPLE CONNECTIONS |
| US7694013B2 (en) | 2001-04-30 | 2010-04-06 | Aol Inc. | Duplicating switch for streaming data units to a terminal |
| US8130755B2 (en) | 2001-04-30 | 2012-03-06 | Aol Inc. | Load balancing with direct terminal response |
| EP2395700A3 (en) * | 2001-04-30 | 2013-04-17 | America Online, Inc. | Managing access to stream hosted on duplicating switches |
Also Published As
| Publication number | Publication date |
|---|---|
| US6314464B1 (en) | 2001-11-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JPH09270793A (ja) | 通信制御方法 | |
| US6058113A (en) | Method for enhancing resource reservation communication | |
| JP4213972B2 (ja) | ネットワークのパス構成のための方法および装置 | |
| US7636781B2 (en) | System and method for realizing the resource distribution in the communication network | |
| US7702816B2 (en) | Facilitating application synchronization with a reservation protocol at a sender without application receiver participation | |
| US6556544B1 (en) | Method and system for provisioning network resources for dynamic multicast groups | |
| AU754325B2 (en) | Method and apparatus for providing guaranteed quality/class of service within and across networks using existing reservation protocols and frame formats | |
| US6038212A (en) | Method and system for optimizing the connection set up time in high speed communication networks for recovering from network failure | |
| US7327681B2 (en) | Admission control method in internet differentiated service network | |
| US6941380B2 (en) | Bandwidth allocation in ethernet networks | |
| JPH1032594A (ja) | Ａｔｍネットワークにおける階層的マルチキャストルーティング用システムおよび方法 | |
| Reinhardt | Advance reservation of network resources for multimedia applications | |
| JP2000032048A (ja) | ネットワーク装置 | |
| JPH11127195A (ja) | 通信資源管理方法及びノード装置 | |
| Schelén et al. | Resource sharing in advance reservation agents | |
| JP2001045066A (ja) | ＩＰ通信ネットワークシステム及びＱｏＳ保証装置 | |
| JP2002522961A (ja) | Ａｔｍサーバのためのリンク・レベルのフロー制御方法 | |
| CN112583636B (zh) | 一种政务网络切片的构造方法、电子设备和存储介质 | |
| EP2110992A1 (en) | System and method for monitoring and optimizing traffic in MPLS-diffserv networks | |
| JPH1127316A (ja) | ネットワークの通信品質制御システム | |
| Comer et al. | FLOWS: Performance guarantees in best effort delivery systems | |
| Cisco | Resource-Reservation Protocol (RSVP) | |
| US7643492B2 (en) | Network bandwidth reservation method | |
| JP2001333105A (ja) | 通信品質保証方法 | |
| CN100341300C (zh) | 与服务质量标准相关的数据流的多域访问控制器 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20030603 |