JP2005522913A - マルチクラスタ・ネットワークにおける通信のための方法、クラスタのネットワークに接続するための装置、及びクラスタを接続するためのブリッジ - Google Patents

Abstract

ネットワークにおけるネットワーク装置の各クラスタとのインタフェース用の少なくとも２つのインタフェースを有するブリッジ装置であり、前記ブリッジ装置は、クラスタを接続するための少なくとも２つのインタフェース・ポータルを有する。前記ブリッジ装置は、少なくとも１つのネットワーク装置の装置記述構成メモリデータ(SDD)の要求を内部のクライアントから受信するための第１のソフトウェア構成要素(SDDM)をポータル毎に有し、前記第１のソフトウェア構成要素が、他の装置の同様のソフトウェア構成要素の関数呼び出しを通じて、他の装置から装置記述データを取り出すように適合される。本発明はまた、マルチクラスタ・ネットワークにおける装置に関するものであり、前記装置は、前述のソフトウェア構成要素と、装置発見方法と、装置間の接続を確立するための方法とを有する。

Description

発明の詳細な説明

本発明は、マルチクラスタ・ネットワーク（例えばHAViクラスタに基づくが、それに限定されない）における通信のための方法に関するものであり、そのようなネットワークでの装置、及びクラスタを接続するためのブリッジ装置に関するものである。

HAVi(ホーム・オーディオ／ビデオ・インタラクティブ)は、現在IEEE1394バス(2000年バージョンにより拡張された1995年バージョン)で規定されており(2001年3月15日に公開されたバージョン1.1)、そのためIEEE1394の制限を引き継いでいる。１つの制限は、単一のクラスタ・ネットワークの使用である。

ホームネットワークは一般的に家の全ての装置を接続するが、そのようなHAViネットワークは全体の家に展開することが困難である。いくつかの別個のHAViクラスタを接続することが望ましい。

Thomson Licensing SAの名義で2002年11月21日に出願されたPCT特許出願EP02/013175とEP02/13179は、GUIDプロキシ技術を使用してHAViネットワークをUPnPネットワークに接続するためのゲートウェイに関するものである。

本願は、ブリッジ装置及びネットワーク装置、特にそれら装置に実装されるソフトウェア構成要素と、マルチクラスタ環境でのその相互作用について説明する。

留意すべき点は、異なるソフトウェア構成要素は、それ自体で独立のエンティティと発明を構成し、相互に別々に特許請求されることがある。

本発明は、ネットワークにおけるネットワーク装置の各クラスタとのインタフェース用の少なくとも２つのインタフェースを有するブリッジ装置に関するものであり、前記ブリッジ装置は、クラスタを接続するための少なくとも２つのインタフェース・ポータルを有し、前記ブリッジ装置が、少なくとも１つのネットワーク装置の装置記述構成メモリデータの要求を内部のクライアントから受信するための第１のソフトウェア構成要素をポータル毎に有し、前記第１のソフトウェア構成要素が、他の装置の同様のソフトウェア構成要素の関数呼び出しを通じて、他の装置から装置記述データを取り出すように適合されることを特徴とする。

本発明の実施例によると、前記第１のソフトウェア構成要素は、リモート・クラスタ装置へのパス上のブリッジ装置の同様のソフトウェア構成要素への関数呼び出しを通じて、同様のソフトウェア構成要素なしにリモート・クラスタ装置用のデータを取り出すように適合される。

本発明の実施例によると、前記第１のソフトウェア構成要素は、媒体依存の要求メッセージを装置に発行することにより、自分と同じクラスタの同様のソフトウェア構成要素なしに、装置用のデータを取り出すように適合される。

本発明の実施例によると、前記第１のソフトウェア構成要素は、
a.ネットワーク上の他の装置の第１のソフトウェア構成要素の識別子のリストと、
b.リストにおける装置へのパスで最も近いポータルの各識別子に関係する、同様の第１のソフトウェア構成要素を欠く装置のリストと
のうちの少なくとも１つを維持するように適合される。

本発明の実施例によると、前記第１のソフトウェア構成要素は、そのポータルのローカル・クラスタに第１のソフトウェア構成要素を欠く装置の装置記述データにおける変化を監視し、ブリッジ装置の他のポータルに接続されたクラスタで、対応する装置記述データの変化イベントを生成するように適合される。

本発明の実施例によると、前記ブリッジ装置は、各ポータルのポータルの他のソフトウェア構成要素とポータルのクラスタの通信媒体とのインタフェース用の第２のソフトウェア構成要素をポータル毎に更に有し、前記第２のソフトウェア構成要素は、通信媒体にリモートでアクセスするために、少なくとも特定のメソッドがネットワークの他の装置のソフトウェア構成要素とグローバルにアクセス可能であるアプリケーションプログラム可能インタフェース(API)を有する。

本発明の実施例によると、グローバルにアクセス可能なメソッドは、書き込み、読み取り、ロック、登録、ドロップ、指示のうちの少なくとも１つを有する。

本発明の実施例によると、前記ブリッジ装置は、ネットワークの全てのクラスタの全ての装置のリストを維持するための第３のソフトウェア構成要素をポータル毎に更に有する。

本発明の実施例によると、前記第３のソフトウェア構成要素は、ネットワークの何らかのクラスタの変化の検出により、前記変化の性質をそのポータルのソフトウェア構成要素に通知する第１のイベントを生成するように適合される。

本発明の実施例によると、前記第３のソフトウェア構成要素は、イベントを発行するポータルのリモート装置のリストの状態を、他のポータルの前記第３のソフトウェア構成要素にのみ通知するための第２のイベントを生成するように適合される。

本発明の実施例によると、前記第２のイベントは、イベントを発行するポータルと比較したリモート装置(すなわち、イベントを発行するポータルの共通のポータルを通じて到達可能な装置)の潜在的に不完全なリストを有する。

本発明の実施例によると、前記第３のソフトウェア構成要素は、ホストのポータルのリモート装置のリストが安定したことをクラスタの全ての装置の第３のソフトウェア構成要素に通知するための第３のイベントを生成するように適合される。

本発明の実施例によると、前記第３のイベントは、イベントを発行するポータルと比較して、リモート装置(すなわち、イベントを発行するポータルの共通のポータルを通じて到達可能な装置)の完全なリストを有する。

本発明の実施例によると、各ポータルは、ポータルのローカル・クラスタで検出されたイベントメッセージを共通のポータルに転送するための第４のソフトウェア構成要素を有する。

本発明の実施例によると、各ポータルは、ブリッジのクラスタのうちの１つで、その他の装置の第５のソフトウェア構成要素から要求を受信するための第５のソフトウェア構成要素と、発信アドレスとして最初の要求者の識別子で、その他のクラスタの第５のソフトウェア要素に前記要求を転送し、前記要求に対する非連結応答を最初の要求装置に返信するための手段とを有する。

本発明の実施例によると、各ポータルは、ブリッジのクラスタのうちの１つで、その他の装置の第５のソフトウェア構成要素から要求を受信するための第５のソフトウェア構成要素と、その他のクラスタの第５のソフトウェア要素に前記要求を転送するための手段とを有し、前記転送するポータルの発信アドレスがパラメータとして転送するポータルによって転送された要求に加えられ、前記転送された要求を受信及び連結し、その要求に対する連結応答を最初の要求装置に返信するための手段とを有する。

本発明の実施例によると、前記要求を転送するための前記手段は、ブリッジ装置の第５のソフトウェア要素に前記要求を転送するための第１のメッセージ形式と、非ブリッジ装置の第５のソフトウェア要素に要求を転送するための第２のメッセージ形式とを使用するように適合され、転送するポータルの識別子が第１のメッセージのパラメータであり、第２のメッセージのパラメータではない。

本発明の好ましい実施例によると、各ポータルは、ブリッジのクラスタのうちの１つで、その他の装置の第５のソフトウェア構成要素から要求を受信するための第５のソフトウェア構成要素と、発信アドレスとして最初の要求者の識別子で、その他のクラスタの第５のソフトウェア要素に前記要求を転送し、その転送された要求に対する応答を傍受し、前記応答の内容を連結し、最初の要求に対する単一の連結応答を最初の要求装置に返信するための手段とを有する。

本発明の実施例によると、前記ブリッジ装置は、そのクラスタの通信媒体の間でパケットの移動形式を変換するための手段を有する。

本発明の実施例によると、各ポータルは、その他の装置の第６のソフトウェア要素からの接続確立要求の受信により、ブリッジを横断する接続のために、ローカル・クラスタの接続セグメントを確立するための第６のソフトウェア要素を有する。

本発明の実施例によると、ポータルの前記第６のソフトウェア要素は、そのローカル・クラスタで接続を確立し、接続端末装置へのパスで次のセグメントの確立を実行するために、そのローカル・クラスタを次のポータルに通知するように適合される。

本発明のその他の目的は、マルチクラスタ・ネットワークのクラスタへの接続用の装置であり、前記クラスタはブリッジ装置を通じて接続され、各ブリッジ装置は少なくとも２つのクラスタ・インタフェースを有し、各インタフェースが各クラスタのネットワーク装置としてみなされ、前記ネットワーク装置が、少なくとも第２の装置の装置記述構成メモリデータの要求を内部のクライアントから受信するための第１のソフトウェア構成要素を有とし、前記第１のソフトウェア構成要素が、少なくとも１つの装置の同様のソフトウェア構成要素の関数呼び出しを通じて、少なくとも１つの他の装置から装置記述データを取り出すように適合されることを特徴とする。

本発明の実施例によると、前記第１のソフトウェア構成要素は、リモート・クラスタ装置へのパス上のブリッジ装置の同様のソフトウェア構成要素への関数呼び出しを通じて、同様のソフトウェア構成要素なしにリモート・クラスタ装置用のデータを取り出すように適合される。

本発明の実施例によると、前記第１のソフトウェア構成要素は、媒体依存の要求メッセージを第２の装置に発行することにより、同じクラスタの同様のソフトウェア構成要素なしに、それ自体として第２の装置用のデータを取り出すように適合される。

本発明の実施例によると、前記第１のソフトウェア構成要素は、
a.ネットワーク上の他の装置の第１のソフトウェア構成要素の識別子のリストと、
b.リストにおける装置へのパスで最も近いポータルの各識別子に関係する、同様の第１のソフトウェア構成要素を欠く装置のリストと
のうちの少なくとも１つを維持するように適合される。

本発明の実施例によると、前記装置は、ネットワークの全てのクラスタの全ての装置のリストを維持するための第３のソフトウェア構成要素を更に有し、前記第３のソフトウェア構成要素は、そのローカル・クラスタに接続されたポータルからリモート装置のリストを取り出し、リモート装置のリストをローカル・クラスタ装置のリストと連結するための手段を有する。

本発明の実施例によると、前記第３のソフトウェア構成要素は、前記装置の自己のローカル・クラスタに比較したリモート装置用のパスで最も近いポータルの指示を、ネットワーク装置のリストで維持するように更に適合される。

本発明の実施例によると、前記装置は、リモートのソフトウェア要素のリストの要求をローカル・クライアントから受信し、ローカル・クラスタの装置の第５のソフトウェア要素にのみ前記要求を転送するための第５のソフトウェア構成要素を有する。

本発明の実施例によると、前記装置は、同じ装置のクライアント用のアプリケーションプログラム可能インタフェース(API)を有し、シンク(sink)装置とソース(source)装置との間の接続を確立する要求を受信するように適合された第６のソフトウェア要素を有し、前記第６のソフトウェア要素は、ソース(source)装置とシンク(sink)装置との間のパスで、シンク(sink)装置へのパスでソース(source)装置に最も近いポータルを決定し、そのローカル・クラスタで接続を確立するためにそのポータルに適切な要求を送信し、パスの他の適切なポータルに前記要求を伝搬するように適合される。

ブリッジのポータルは、そのローカル・クラスタの装置でもある点に留意すべきである。

本発明のその他の目的は、少なくとも２つの装置クラスタと少なくとも１つのブリッジとを有するネットワークにおいて装置を発見するための方法であり、少なくとも２つのクラスタはブリッジにより接続され、各ブリッジは各クラスタへの接続用の少なくとも２つのインタフェース・ポータルを有し、前記処理は、
-そのローカル・クラスタの装置の識別子のリストを各ポータルに取得させるステップと、
-自分と同じクラスタの各ポータルからリモート装置のリストを各ポータルに要求させるステップと、
-そのローカル装置のリスト、及び共通のポータルを通じて到達可能なリモート装置のリストをその共通のポータルから要求することにより、その自己のリモート装置のリストを各ポータルに構築させるステップと
を有する。

本発明の実施例によると、前記方法は、その装置への最短パスである場合に、所定の装置に向かうメッセージに対してブリッジを通過させるステップを更に有する。

本発明の実施例によると、前記最短パスは、横断されるポータルの最低数を備えたパスである。

本発明のその他の目的は、ブリッジ装置により接続された複数の装置クラスタを有するネットワークにおいて、ソース(source)装置とシンク(sink)装置との間の接続を確立するための方法であり、各ブリッジ装置がクラスタへの接続用のインタフェース・ポータルを有し、前記方法は、
(a)ブリッジのポータルとネットワークの他のブリッジ認識装置に、ストリーム・マネージャ・ソフトウェア要素を提供するステップ
(b)装置のストリーム・マネージャ・ソフトウェア要素のレベルで、ローカル・クライアントからの接続から要求を受信するステップ
(c)シンク(sink)装置とソース(source)装置との間のパスで、ソース(source)装置に最も近いポータルを特定し、そのポータルに接続要求を送信するステップ
(d)ソース(source)装置とポータルのブリッジとの間の接続のセグメントを、接続要求を受信するポータルに確立させるステップ
(e)ソース(source)装置へのパスでそのブリッジの次のポータルを、接続要求を受信するポータルに所有させ、次のポータルのローカル・クラスタで接続次のセグメントを確立させるステップ
(f)シンク(sink)へのパスで、もしあれば次のブリッジを特定し、接続の適切なセグメントを確立するように、シンク(sink)装置へのパス上の次のブリッジのリモート・ポータルに指示するステップ
(g)シンク(sink)装置への接続のセグメントが確立されるまでステップ(e)に進むステップ
により特徴付けられる。

本発明の他の特徴は、本発明の好ましい実施例の記載で明らかになる。本発明は、この実施例に限定されない。実施例は図面を用いて説明される。

２つのHAViクラスタをブリッジするための１つの方法は、ソフトウェア要素のプロキシ手法に基づく。図２５は、ブリッジ装置により連結された２つのHAViクラスタにより形成されたネットワークの例である。装置及びサブ装置、又は機能は、それぞれ装置制御モジュール(DCM)及び機能構成モジュール(FCM)と呼ばれるソフトウェア要素により表される。

HAVi装置の発見処理は、IEEE1394バスでの‘GUID’認識に基づく。GUIDはグローバル一意識別子を表す。GUIDはIEEE1394装置を一意に識別する。

ブリッジの一方側の装置は、IEEE1394レベルで認識できないため、他方側の装置により認識されない。一方側のコントローラは、他方側の目的物を使用することができない。ブリッジ装置は一方側のDCMとFCMの表示を構築し、それらが表している実際のソフトウェア要素のプロキシ要素として、それらを他方側のDCM及びFCMとして提示する。

図２５において、実際のDCMとFCMはそのSEID(ソフトウェア要素ID)で表される。SEIDはGUID(各装置の下に例が示されている)とその装置内に一意の数字との組み合わせである。

そのDCMとFCMは、ブリッジ装置の他方側でプロキシSE(ソフトウェア要素)として表される。実際のSEとそれを区別するために、それが点線で示されている。実際のDCMとFCM毎に１つのプロキシSEが存在する。制御アプリケーションは、そのプロキシSEを通じてブリッジの背後の実際の目的装置を制御することができる。

本発明のこの実施例は、GUIDプロキシを使用したポータルとブリッジに基づく。しかし、本発明はこの特定の場合に限定されない。更に、HAVi1.1はIEEE1394に基づくが、本発明のクラスタは他のネットワーク技術と特にインターネットプロトコル(IP)又は無線技術(IEEE802.11、Hiperlan2等)に基づくことがある。実施例において、GUIDプロキシ技術を使用することにより、一例としてこの柔軟性が達成される。本願の優先日に利用可能な最新のHAViのバージョンは、バージョン1.1である。HAVi1.1はブリッジについて記載しておらず、HAVi1.1装置がマルチクラスタ・ネットワークに接続されると、全くブリッジを認識しない。

本願は、まずHAViブリッジ装置について説明し、それに続いてHAViブリッジ認識装置(すなわち、ブリッジ装置のリソースを利用し、それと通信することができる装置)の記載がある。ブリッジがHAVi1.1装置にトランスペアレントではないため、そのような装置が必要になることがある。
［I ブリッジ装置］
図１は、２つのブリッジ104と105により直列に相互接続された３つのクラスタ101から103を有するネットワークを表す。クラスタ101はIEEE1394に基づき、クラスタ102はIP技術に基づき、クラスタ103は例えばIEEE802.11に基づく無線ネットワークである。クラスタ102の装置は、例えばHAVi装置又はブリッジがHAViプロキシ表示を管理するUPnP装置であり得る。

この実施例によるGUIDプロキシ解決策の原理は、ローカル・クラスタの外にある装置のGUIDをローカル・クラスタで通知し、それによりローカルHAVi装置がその存在の認識を取得する。リモート装置のリモートのGUIDが認識されると、メッセージングシステムがどの装置にHAViメッセージを送信しなければならないかをその内部テーブルで知るため、その装置はHAViソフトウェア要素によりアドレス指定可能になる。HAViメッセージがリモート装置に送信される場合、その宛先アドレスはプロキシGUIDのものである。プロキシのGUIDに基づくHAViミドルウェア及びHAVi応用モジュール(DCM、FCM、アプリケーション)からのメッセージは、ブリッジにより適切に渡される。

HAVi-HAViブリッジのソフトウェア・アーキテクチャは、図２に表される。それはこの実施例によると２つのポータルで構成されるが、２より多いポータルも可能である。各ポータルはHAViクラスタ(例えばIEEE1394-1995バス)に接続され、そのクラスタでのアドレス指定可能なエンティティである。完全なHAViスタックはブリッジで動作する。HAViモジュールがそれ自体の２つのインスタンスをシミュレートするか否か、又は２つの分離したモジュールが同じ機能のために同時に動作するか否かは、実装依存である。図２において、１つのみのメッセージングシステムが表されているが、機能的にはポータル毎に１つ存在する。ソフトウェア要素(メッセージングシステムはソフトウェア要素である)は、それが存在するノードのGUIDでアドレス指定され、各ポータルがその自己のGUIDを保有する。
a)SddManager
自己記述装置データ(SDD)は、それ自体についての情報(装置の形式、機能、バージョン等)を他の装置に提供するHAVi装置用の手段である。HAVi-1.1において、SDDはIEEE1394HAVi装置の構成ROM(GUIDのような他の情報を含む)の一部であり、直接のIEEE1394読み取りトランザクションを使用して、他の装置により読み取られる。

これは単一のIEEE1394クラスタでは十分であるが、HAViネットワークがマルチクラスタであり、異なる媒体技術で構築されている場合、そのような読み取りトランザクションは不十分である。そのときに必要なものは、ネットワークの何らかのHAVi装置のSDDデータを読み取る手段である。これは、HAViメッセージの使用により達成され得る。この実施例によると、ソフトウェア要素は、メッセージングシステムを使用して、HAVi装置のSDDデータにアクセスすることができる。何らかのクラスタの何らかのクライアントに要求に応じてSDDデータを提供するために、適切なアプリケーション特有のインタフェース(API)がHAViスタックで定められている。

SddManagerは、ローカルでSDDデータの要求を処理し、リモートのSddManagerから応答を集めるという意味で、レジストリと類似性を有する新しいシステムソフトウェア要素である。レジストリは中間機能(IAV)と全機能(FAV)を備えた全ての装置に存在するが、SddManagerはこの実施例による何らかのブリッジ認識HAVi装置に実装されるという違いがある。ブリッジ認識装置は、FAV又はIAV形式(Full A/V装置又はIntermediate A/V装置)である。HAVi1.1以下のバージョンの装置にSddManagerは存在しない。従って、SddManagerを備えた装置は、SddManagerを欠く装置とともに同じクラスタに共存する。このことは、HAVi装置のクライアントアプリケーション又はソフトウェア要素が、好ましくは全ての要求についてそのローカルSddManagerを呼び出し、ローカルSddManagerが全ての情報を集める(他のSddManagerにクエリを送信し、及び／又はローカルの低水準の動作を行う)役割をすることを意味する。ローカルSddManagerが装置に存在しない場合、クライアントは他の手段を通じて情報を取得しなければならない。この場合、クライアントは、ブリッジの認識を有さないHAVi-1.1装置で動作している。それはローカルのIEEE1394クラスタ装置にのみアクセスすることができる。

この実施例によると、クライアントはSDDデータを取り出すために以下の処理を実行する。

if(ローカルSddManagerが存在する)
(301,302,303) ローカルSddManagerを呼び出す
else //(すなわち、装置がブリッジ認識装置でない)
(304) ローカルAPI(例えばCMM1394)を使用し、ローカル・クラスタ装置のSDDデータを取り出す //ここではローカル・クラスタに過ぎない
換言すると、クライアントアプリケーションは、好ましくはSddManagerを備えた装置とSddManagerを備えない装置の双方で機能するように適合される。

この実施例によると、SddManagerは他のSddManagerにより通知されたイベントから取得したSDDデータ情報をキャッシュする。このことにより、ネットワークのトラヒックを減少させ、要求が行われた時にSddManagerからクライアントへの応答時間を減少させることが可能になる。従って、キャッシュはSddManagerに集中され、同じ装置のいくつかのクライアントにより重複して行われる必要がない。

SddManagerのレベルでは、以下の処理が実行される。

if(クライアントからのクエリがローカル・データのみに関するものである(すなわち同じ装置にある))
応答を送信する
else
ifリモートSddManagerがクエリ要求される目的装置に存在する)
(301) リモートSddManagerを呼び出す
else
if(目的装置がローカル・クラスタにある)
(303) ローカルAPI(例えばCMM1394)を使用し、SDDデータを取り出す
else //すなわち、目的装置がブリッジ認識ではなく、ローカル・クラスタにない
ブリッジの出口ポータルのSddManagerを呼び出す
換言すると、クライアントから受信されたクエリがローカルで利用可能なデータのみに関係しない場合、SDDデータが取り出される目的装置がSddManagerを有するかどうかをSddManagerが最初に確認し、その場合には目的のSddManagerを呼び出す。その他の場合(目的装置がSddManagerを有さない場合)、目的装置がローカル・クラスタに存在し、データを取り出すために通信媒体マネージャ(Communication Media Manager)のようなローカルAPI(例えばIEEE1394のCMM1394)を使用するか否かを確認する。リモートの非ブリッジ認識装置のために、要求がローカル・クラスタの出口ポータルのSddManagerに転送される。

図３は、前記の２つの処理で参照された異なる場合のメッセージ順序を示している。参照番号は、前記の２つの処理で提供されたステップに対応する。

好ましくは、SddManagerはネットワーク(ローカル及びリモート)の他の全てのSddManagerのリストを格納し、SddManagerのない装置の場合には、クエリを送信する最も近いポータルのGUID(以下に説明する通り、ネットワーク・マネージャにより提供される)を格納する。

SddManagerは以下のサービスを提供する。

SddManagerはこの実施例では以下のデータ構造を有する。
(a)DeviceProfile
定義
struct DeviceProfile {
DeviceClass deviceClass;
boolean withDcmMangager;
boolean withStreamManager;
boolean withResourceManager;
boolean withDisplayCapability;
boolean deviceActive;
boolean bridge;
};
説明
この構造は、HAVi_Device_Profileカテゴリのもとで、IEEE1394構成ROMで検出された値を格納する(HAVi-1.1仕様の458ページ)。deviceClassパラメータは装置の形式(FAV、IAV等)を提供する。モジュールが装置に存在する場合に、withXxxManagerのbooleanはTrueである。withDisplayCapabilityは、IAVについてはDDIコントローラが存在するか否かを示し、FAVについてはDDIコントローラとlevel2のUI(ユーザインタフェース)が存在するか否かを示す。deviceActiveのbooleanは、装置が動作中である場合にTrueである。bridgeパラメータは、装置がブリッジであるか否かを特定する。
(b)Vendor
定義
struct Vendor {
VendorID vendorId; //HAVi-1.1のp110に定義されている
DeviceManufacturer vendorText; HAVi-1.1のp149に定義されている
};
説明
製造者についての情報である。最大文字数は、2バイトのUNICODE UTF-16で符号化されて50であり、最大のサイズは100バイトである。
(c)Model
struct Model {
ModelId modelId //HAVi-1.1のp200に定義されている
DeviceModel modelText //HAVi-1.1のp149に定義されている
};
説明
この構造は、モデルについての情報を提供する。最大文字数は、2バイトのUNICODE UTF-16で符号化されて50であり、最大のサイズは100バイトである。
(d)DcmProfile
定義
struct DcmProfile {
uint transferredDcmCodeUnitSize;
uint installedDcmCodeSpace;
uint installedDcmWorkingSpace;
Version MessageVersion; //HAVi-1.1のp110に定義されている
};
説明
この構造は、DCUについての情報を有する。フィールドは、HAVi-1.1仕様のセクション9.10.7のp460に定められた通りである。
(e)SddData
定義
struct SddData {
Version version; //HAVi-1.1のp110に定義されている
DeviceProfile deviceProfile;
Vendor vendor;
Model model;
UserPreferredName userPreferredName; //HAVi-1.1のp150に定義されている
DeviceIcon deviceIcon; //HAVi-1.1のp158に定義されている
Dcmprofile dcmProfile;
sequence<octet> dcmReference;
};
説明
この構造は、HAVi装置についての情報を提供する。これは、基本的にはHAVi-1.1仕様のIEEE1394構成ROMのSDD部と同じ情報である。フィールドについての詳細な情報については、HAVi-1.1仕様のセクション9を参照のこと。deviceProfile構造のbridgeのbooleanにより表されたbridgeのビットが装置プロフィールに追加されることに留意すべきである。このデータは、HAVi装置がブリッジであるか否かを示すために使用される。dcmProfileとdcmReferenceがBAV装置についてのみ有効なフィールドであることにも留意すべきである。

SddManagerのアプリケーション・プログラマブル・インタフェース(API)は以下の通りである。
SddManager::GetSddData
プロトタイプ
Status SddManager::GetSddData(in GUID guid, out SddData sddData)
パラメータ
-guid クライアントがSDDデータを取り出すことを望むGUID
-sddData 指定されたGUIDのSDDデータ
説明
このメソッドは、GUIDにより指定された所定のHAVi装置のSDDデータを取り出す。GUIDがローカル装置(クライアントのホスト)のものである場合、ローカルSddManagerは対応するSDDデータで応答を送信する。GUIDがリモート装置のものである場合、ローカルSddManagerはリモートSDDデータを取り出すことを担う。これは、前記に既に提示された処理に従って行われる。
エラーコード
-SddManager::EUNKNOWN_GUID GUIDが未知である
-SddManager::ENOT_READY SDDデータが現在更新中である。クライアントは後でリトライしてもよい
-SddManager::ELAV 指定されたGUIDがLAV装置であり、SDDデータを有さない
SddManagerは以下のイベントを使用する。
SddDataChanged
プロトタイプ
void SddDataChanged(in GUID guid, in SddData sddData)
パラメータ
-guid SDDデータの変更された装置のGUID
-sddData 新しいSDDデータ
説明
このイベントは、GUIDにより指定された装置のSDDデータの変更をネットワークの装置に通知するために使用される。SddManagerをホストする装置は、そのローカルSDDデータにこのイベントを提供することができる。

ブリッジ装置は、変化したSDDで装置にローカルなポータルでのSDDデータの変化を(例えばIPクラスタのマルチキャスト・メッセージを通じて)検出し、その他のポータルのSddManagerに情報を送信することにより、SddManagerのないリモート装置のSDDデータにイベントを提供することができる。

この場合(ブリッジがSDD Managerのない装置用にイベントを広める場合)、SddManagerのない装置を備えたクラスタの全てのポータルは、その自己の共通のポータルにイベントを送信し、それが次にリモートにイベントを転送し、既知のSDD処理(IEEE1394ネットワークの場合にバスのリセットと構成ROMの読み取り、IPネットワークの場合にマルチキャストパケットの送信)に応じてローカル・クラスタが更新される。SDDManagerのない装置は、例えば基本的(BAV)非IEEE1394装置のようなHAVi1.1装置であり得る。レガシー装置(LAV)の場合、SDDデータを有さないため、問題はない。

IEEE1394構成ROMの拡張は次のように実行される。

SddManger構造の定義と整合するように、以下のように新しいフィールドがIEEE1394HAVi装置の構成ROMに追加される。HAVi_Devide_ProfileはIEEE1394構成ROMの24ビットの即値(IEEE1212により指定される)フィールドであり、そのフィールドは既に以下のものを有する。
-HAVi_Device_Class[bit0...3]
-HAVi_DCM_Manager[bit4]
-HAVi_Stream_Manager[bit5]
-HAVi_Resource_Manager[bit6]
-HAVi_Display_Capability[bit7]
-HAVi_Device_Status[bit8]
-ビット9から23は未使用
新しいフィールドがビット9でこのエントリーに追加される。

HAVi_Bridgeは、装置がHAViブリッジであるか否かをIAV/VAV装置に対して指定する1ビットの即値である。BAVの場合、このビットは0である。

b)通信媒体マネージャ(Communication Media Manger)
ブリッジのポータルの変更された通信媒体マネージャ(CMM: Communication Media Manager)が次に説明される。

ブリッジのCMM (ブリッジ毎にいくつかのCMMが存在するため、実際には各ポータルのCMM) のAPIは、実施例によると、ホスト装置のソフトウェア要素にのみアクセス可能である(すなわち、ローカルのアクセス可能性)のではなく、そのAPI/メソッドのうちの少なくともいくつかにとってグローバルにアクセス可能である。これは、各種のCMMに有効である。以下、ブリッジ装置に存在するものとして、IEEE1394に基づく装置のCMM(CMM1394)と、IPに基づく装置のCMM(CMMIP)について説明する。

CMM1394のAPIは、以下のようになる。

CMMIPのAPIは、以下のようになる。

登録とドロップのAPIにより、リモートのHAViソフトウェア要素がCMMのポータルのネットワークにローカルの装置から低水準のメッセージを受信することが可能になる。‘送信’API(IPではsend、IEEE1394ではread-write-lock)により、リモート・クラスタの特定の装置へのメッセージの送信が可能になる。例えば、この手段はリモートに設置された装置制御モジュール(DCM)により使用され、１つ以上のブリッジを越えてその制御される装置と通信することができる。

リモートCMM(すなわち、それ自体とは同じ装置ではない)を使用することを望むHAViのSEは、リモートCMMにより使用されるリンク技術を認識しなければならない(すなわち前記のAPIを認識しなければならない)。

HAViのSEにより使用される処理は以下の通りである。
-0x00000001のソフトウェア要素形式のアトリビュート値(すなわち通信媒体マネージャ(Communication Media Manager))でローカル・レジストリにクエリを送る(そのローカル・レジストリがリモート・レジストリにクエリを送出する)ことによるリモートCMM技術の発見と、リモートCMMのSEIDの取り出し。この実施例によると、このSEIDのソフトウェア処理(swHandle)部はCMMの種類を与える(CMM1394の場合は0x0001、CMMIPの場合は0x0009)。
-次に、SEが対応するリンク技術を取り扱う方法を認識している場合には、CMMを使用することができる。例えば、その技術に基づいてリモート装置に送信されるメッセージの内容を特定することができなければならない。

図４は、1に等しいGUIDを有する装置のソフトウェア要素が、3に等しいGUIDを有するリモートIP装置にIPメッセージを送信するように、ブリッジのリモートCMMIPに命令する例を示している。

要約すると、特にクライアントが異なるネットワーク技術で直接通信する(例えば低水準のメッセージを送信する)ためにCMMのAPIを使用することを可能にするため、ブリッジのポータルのCMMの少なくとも特定の機能が、CMMの自己の装置のローカルのクライアント以外のクライアントにアクセス可能になる。
c)装置発見／ネットワーク・マネージャ
この実施例によると、ネットワーク・マネージャのソフトウェア要素は、全HAViネットワークに接続された全ての装置についての情報を提供するために作られる。CMMはそのローカル・クラスタに接続されたGUIDのリストを提供する。ネットワーク・マネージャは、ローカル・クラスタを含む全マルチクラスタ・ネットワークのGUIDのリストを与えることができる。各ポータルにネットワーク・マネージャが存在する。ネットワーク・マネージャはまた、好ましくはブリッジ認識装置にも存在する。

ネットワーク・マネージャにより以下のサービスが提供される。

ネットワーク・マネージャのデータ構造は以下の通りである。
(a)ClusterType
定義
enum ClusterType {IEEE1394, IP};
説明
ClusterTypeは特定のクラスタで使用される技術についての情報を提供する。この実施例によると、２つのクラスタ技術(1394(HAVi-1.1とIP)が定められるが、その他のものも容易に追加され得る。
(b)NetDeviceInfo
定義
struct NetDeviceInfo {
GUID deviceGuid;
uint hops;
GUID nearestPortalGuid;
ClusterType clusterType;
};
説明
NetworkDeviceInfo構造は、ネットワークにおける位置がどこであっても、装置についての情報を提供する。すなわち、それはGUID自体と、それに到達するホップ数(後述のループ問題を解決するためにネットワーク・マネージャにより使用される)と、その装置¹に到達するために最も近いポータルのGUIDと、それが接続されたクラスタの形式とを提供する。最後の２つの項目により、クライアントがその最も近いポータルのCMMXXXに到達し、リモート・クラスタの低水準の機能にアクセスし、リモート装置に低水準のメッセージを送信することが可能になる。
(c)RemoteNetworkState
定義
enum RemoteNetworkState {STABLE, CHANGING, FINAL};
説明
RemoteNetworkStateはポータルの背後のリモート・ネットワーク（すなわち、ネットワーク・マネージャを有するポータルの背後のクラスタ）の状態についての情報を提供する。STABLEは、ポータルのリモート・クラスタ装置のリストが安定しており、他のネットワーク・マネージャがそれに依存し得ることを意味する。CHANGINGは、リモートのリストが依然として変更を受けることを意味する。FINALは、ポータルのリモートのリストが、安定すべきであるが、クラスタの他のポータルによって確認が必要であることを意味する(更なる詳細については動作発見処理を参照)。

ネットワーク・マネージャのAPIは以下の通りである。
(a)NetworkManager::GetNetDeviceList
プロトタイプ
Status NetworkManger::GetNetDeviceList(
out uint updateId,
out sequence<NetDeviceInfo> activeNetDeviceList,
out sequence<NetDeviceInfo> nonactiveNetDeviceList)
パラメータ
-updateId ネットワークの更新番号。この番号はリストが変更される毎に１だけ増加し、ネットワークが同じに留まっているか否かを確認するためにクライアントにより使用され得る。
-activeNetDeviceList ネットワークの全ての動作中の装置のリスト。最初の項目はローカル装置であるべきである。
-nonactiveNetDeviceList ネットワークの全ての非動作中の装置のリスト。
説明
このAPIは全ネットワークの全ての装置のリストを、動作中の装置のリストと非動作中の装置のリストに分けて戻す。各装置についての情報はNetDeviceInfo構造に含まれる。これは装置のGUIDと、それに到達するために最も近いポータルのGUIDと、それが取り付けられたクラスタの形式とを与える。例えば図４において、SEはGUID3を取り出し、そのクラスタがIPに基づき、それに到達するために最も近いポータルがGUID6であることを検出し、次に6に等しいGUIDを有する装置のCMMIPにCmmIp::SendのHAViメッセージを送信することができる。
エラーコード
-NetworkManger::ENOT_READY リストがまだ利用可能ではなく、システムがそれを更新していることがある。これは一時的なエラーであり、クライアントのソフトウェ要素はリトライすることがあり、又はNetworkUpdatedイベントを使用することがある。
(b)NetworkManager::GetRemoteDeviceList
プロトタイプ
Status NetworkManger::GetRemoteDeviceList(
out uint updateId;
out sequence<NetDeviceInfo> activeRemoteDeviceList;
out sequence<NetDeviceInfo> nonactiveRemoteDeviceList)
パラメータ
-updateId リモート・ネットワークの更新番号。この番号はリストが変更される毎に１だけ増加し、リモート・ネットワークが同じに留まっているか否かを確認するためにクライアントにより使用され得る。
-activeNetDeviceList ブリッジの背後のネットワークの全ての動作中の装置のリスト。
-nonactiveNetDeviceList ブリッジの背後のネットワークの全ての非動作中の装置のリスト。
説明
このAPIは、ネットワーク・マネージャを有するブリッジの背後のネットワークの全ての到達可能な装置のリストを、動作中の装置のリストと非動作中の装置のリストに分けて戻す(動作中の装置は、メッセージ(装置のSDDデータにより指定される通り、IAVとFAVの場合はHAViであり、BAVの場合はプライベート)を受信する状態にある装置である)。各装置についての情報は、NetDeviceInfo構造に含まれる。これは装置のGUIDと、それに到達する出口ポータルのGUIDと、ホップ数と、最も近いポータルと、それが取り付けられたクラスタの形式とを与える。この実施例では、このAPIへのアクセスはネットワーク・マネージャにより制限される。ブリッジ装置のリモート装置のリストをクエリ送出し、その後内部テーブルを構築し、ループ問題を解決するために、それが装置(ブリッジ又は非ブリッジ)のネットワーク・マネージャにより使用される。変形によると、APIは他のソフトウェア要素にも同様に利用可能にされる。
エラーコード
-NetworkManager::ENOT_READY リストがまだ利用可能ではなく、システムがそれを更新していることがある。これは一時的なエラーであり、クライアントのソフトウェ要素はリトライすることがあり、又はRemoteNetworkChangedイベント(ブリッジ装置のネットワーク・マネージャの場合のみ)とRemoteNetworkUpdatedイベント(全てのネットワーク・マネージャの場合)を使用することがある。
(c)NetworkManger::GetNetDeviceInfo
プロトタイプ
Status NetworkManger::GetNetDeviceInfo(
in GUID guid,
out NetDeviceInfo deviceInfo)
パラメータ
-guid クライアントがいくつかの情報を希望するGUID
-deviceInfo この装置についての情報、すなわち対応するNetDeviceInfo構造である。
説明
このAPIは所定のネットワーク装置の完全な情報を提供する。ネットワーク・マネージャはNetDeviceInfo構造を戻す。
エラーコード
-NetworkManager::EUNKNOWN_GUID GUIDが未知である。

この実施例によると、ネットワーク・マネージャのイベントは以下の通りである。
(a)NetworkUpdated
プロトタイプ
void NetworkUpdated(
in uint updateId,
in sequence<NetDeviceInfo> activeNetDeviceList,
in sequence<NetDeviceInfo> nonactiveNetDeviceList,
in sequence<GUID> changedDevices,
in sequence<GUID> goneDevices,
in sequence<GUID> newDevices)
パラメータ
-updateId ネットワークの更新番号。この番号はリストが変更される毎に１だけ増加し、ネットワークが同じに留まっているか否かを確認するためにクライアントにより使用され得る。
-activeNetDeviceList 全HAViネットワークの動作中の装置のリスト。最初の項目はローカル装置であるべきである。
-nonactiveNetDeviceList 全HAViネットワークの非動作中の装置のリスト。
-changedDevices ホップ及び最も近いポータルが変更されたGUIDのリスト。
-goneDevices ネットワークを外れたGUIDのリスト。
-newDevices ネットワークに加わったGUIDのリスト。
説明
NetworkUpdatedはローカルのイベントであり、ネットワーク・マネージャをホストする装置のソフトウェア要素に送信される。HAViネットワーク(どのクラスタでもよい)のどこかで変更が存在する場合に、すなわちネットワーク・マネージャがそのローカル・クラスタに接続されたブリッジから１つ以上のRemoteNetworkUpdatedイベントを受信した後(リモートの変更)に、又はローカル・クラスタの変更の後に、このイベントが作られる。再構成時間の間に、ネットワーク・マネージャはNetworkUpdatedまで、NetworkManger::GetNetDeviceListのAPIのNetworkManger::ENOT_READYに戻ることがある。activeNetDeviceListとnonactiveNetDeviceListの内容の定義は、NetworkManger::GetNetDeviceListのAPIに定められたものと同じである。外れた装置は古い装置のリストでわかり、新しい装置と変更された装置は新しい装置のリストの完全な情報を備えているため、changedDevicesとgoneDevicesとnewDevicesのフィールドはGUIDのみを提供する。

変形の実施例によると、同じクラスタの他の装置がネットワーク・マネージャを有さない場合、このイベントは、その装置にあるソフトウェア要素にアクセス可能にされる。
(b)RemoteNetworkUpdated
プロトタイプ
void RemoteNetworkUpdated(
in uint updateId,
in sequence<NetDeviceInfo> activeRemoteDeviceList,
in sequence<NetDeviceInfo> nonactiveRemoteDeviceList,
in sequence<GUID> changedDevices,
in sequence<GUID> goneDevices,
in sequence<GUID> newDevices)
パラメータ
-updateId リモート・ネットワークの更新番号。この番号はリストが変更される毎に１だけ増加し、リモート・ネットワークが同じに留まっているか否かを確認するためにクライアントにより使用され得る。
-activeNetDeviceList 全HAViネットワークの動作中の装置のリスト。
-nonactiveNetDeviceList 全HAViネットワークの非動作中の装置のリスト。
-changedDevices ホップ及び最も近いポータルが変更されたGUIDのリスト。
-goneDevices ネットワークを外れたGUIDのリスト。
-newDevices ネットワークに加わったGUIDのリスト。
説明
RemoteNetworkUpdatedは、ネットワーク・マネージャのみのグローバルのイベントである。ネットワーク・マネージャがそのローカル・クラスタをプロキシしているネットワークの一部に変化を検出した時に、及びネットワークが安定していると考えられる時に、このイベントが作られる(次のイベントとは反対であり、その次のイベントはブリッジのネットワーク・マネージャにのみ送信され、リストの状態がまだ安定していない時に使用される)。ネットワーク・マネージャの共通のポータルのクラスタでの変更、又はその共通のポータルに接続されたブリッジにより転送された変更のため、これが生じ得る。再構成時間の間に、ネットワーク・マネージャはRemoteNetworkUpdatedまで、NetworkManager::GetRemoteDeviceListのNetworkManager::ENOT_READYに戻ることがある。activeNetDeviceListとnonactiveNetDeviceListの内容の定義は、NetworkManger::GetNetDeviceListのAPIに定められたものと同じである。外れた装置は古い装置のリストでわかり、新しい装置と変更された装置は新しい装置のリストの完全な情報を備えているため、changedDevicesとgoneDevicesとnewDevicesのフィールドはGUIDのみを提供する。
(c)RemoteNetworkChanged
プロトタイプ
void RemoteNetworkChanged(
in RemoteNetworkState state,
in uint updateId,
in sequence<NetDeviceInfo> activeRemoteDeviceList,
in sequence<NetDeviceInfo> nonactiveRemoteDeviceList,
in sequence<GUID> changedDevices,
in sequence<GUID> goneDevices,
in sequence<GUID> newDevices)
パラメータ
-state リモート・ネットワークの状態。これはリモートのリストの文字化でループ問題を解決するために有用である。
-updateId リモート・ネットワークの更新番号。この番号は、リストが変更される毎に１だけ増加し、リモート・ネットワークが同じに留まっているか否かを確認するためにクライアントにより使用され得る。
-activeNetDeviceList 全HAViネットワークの動作中の装置のリスト。
-nonactiveNetDeviceList 全HAViネットワークの非動作中の装置のリスト。
-changedDevices ホップ及び最も近いポータルが変更されたGUIDのリスト。
-goneDevices ネットワークを外れたGUIDのリスト。
-newDevices ネットワークに加わったGUIDのリスト。
説明
RemoteNetwrokChangedはブリッジ装置のネットワーク・マネージャにのみ向かうグローバルのイベントである。それはRemoteNetworkUpdatedイベントと同じであるが、再構成ステップの間にブリッジ装置のネットワーク・マネージャにより使用される。そのステップの間に、安定したネットワーク状態に到達する前に(特にループが存在する場合)、いくつかのイベントが作られることがある。これは、ネットワークがまだ安定していないため使用されないメッセージを、ブリッジ認識装置に送信することを回避する。フィールドの意味はRemoteNetworkUpdatedイベントと同じである。

前記に基づいて、本発明によるブリッジ間の発見処理は以下のようになる。

目的は、HAViネットワークに接続された全ての装置を発見することである。これが行われると、各ポータルの‘リモート’装置のリストが、それ自体を通じて到達可能な装置についての情報を与える。IEEE1394.1トポロジーは、ブリッジを消すことによりループを開くが、ループに関する動作はこの実施例では異なる。この実施例によると、ブリッジは特定のパスについては通過することがあるが、他のものについては通過しない。従ってループが存在する場合、ブリッジは完全には消されないが、GUIDにより特定される装置への特定のパス上にある場合、リモートのリストのGUIを提示する。ブリッジが通過するか否かは、以下に説明される通り、特定の基準に基づいて決定される。この例では、ホップ数がブリッジの数ではなく、宛先に到達するために横断するポータルの数を反映する。ポータルがそのクラスタを介するのではなく、その共通のポータルを介して到達されることがあるため、選択が行われる(すなわち、全ブリッジを横断するポータルへのメッセージの必要性がなく、ブリッジがクラスタの非ポータル装置について完全に交差されなければならない)。

基本的な発見処理は以下の通りである。

各ローカル・クラスタは、その自己のローカル発見処理を実行する。IEEE1394クラスタの発見処理は本質的に既知であり、‘selfID’パケットを使用してトポロジー情報の伝播を引き起こすIEEE1394バスのリセットに基づく。

この段階が終了すると、CMM1394が全てのノードの構成ROMを読み取り、そのGUIDを取得する。(存在する場合には)SDDデータが読み取られ、接続された装置についてのHAVi定義の情報を取得する。

IPクラスタについての発見処理は本質的に既知であり、マルチキャスト通知パケットに基づく。

実施例によるCMMIPは、前記通知に基づいてそのGUIDリストを構築し、それは例えば新しい装置がクラスタに接続されたときに生じる。SDDデータもまたそのパケットに含まれる。

この時点で双方のクラスタ形式についてローカルGUIDのリストとSDDデータが既知になり、それ故にクラスタのネットワーク・マネージャがそのローカル・クラスタにあるブリッジ装置を認識する。

完全なネットワーク装置のリストを構築するために、ネットワーク・マネージャは相互にクエリを送出し始める。

この実施例による処理は、次の通りである。
(1)ネットワーク・マネージャがそのクラスタのブリッジを検索する。
(2)ブリッジ装置のネットワーク・マネージャが、そのローカル・クラスタに接続された他のブリッジ装置のポータルのNetworkManger::GetRemoteDeviceListのAPIを呼び出す。そのクエリ送出されたポータルの共通のポータルが、ネットワークのその側面の装置のリストを既に構築しているべきである。
(3)ブリッジ装置のネットワーク・マネージャが、その共通のポータルから(HAViメッセージにより、又は好ましい実施例ではブリッジの内部情報共有を介して、等)、その自己のリモートの装置リストになるリストを取得する。共通のポータルは、その自己のクラスタに接続された他のブリッジ装置のNetworkManger::GetRemoteDeviceListのAPIを呼び出すと、前記リストを提供することが可能である。
(4)ブリッジ認識(BA)装置のネットワーク・マネージャは、そのローカル・クラスタに接続されたブリッジ装置のNetworkManager::GetRemoteDeviceListのAPIを呼び出す。これが全ネットワークのGUIDリストを構築する。

HAViのSEがそのローカルのネットワーク・マネージャのNetworkManager::GetNetworkDeviceListのAPIを呼び出す。

要求された情報が利用可能になる前にステップが終了した場合、ENOT_READYのエラーが戻されることがあり、クライアントが待たなければならない。この実施例によると、ステップ１と２は実際に並行して行われ、デッドロックの問題を回避する機構が提案される。装置のリストの構築処理は、トポロジーのリーフ(leaf)のクラスタからルートのクラスタに進む(少なくともループのないネットワークの場合)。

発見ルールは以下の通りである。

次のルールが発見処理に適用される。それは、リモートのネットワーク状態(すなわち‘Changing’、‘Final’又は‘Stable’)に応じて分類される。更に状態がなにであれ、いくつかの一般ルールが存在する。従って、ルールは“G”、“C”、“F”及び“S”のカテゴリーに分類される。

前記の処理は、必要に応じて反復処理を通じて、冗長のパスの対立が適切に解決されることを確保するステップを有する。このため、３つの可能な状態(ChangingとStableとFinal)が定められる。その状態に関する情報は、RemoteNetworkChangedイベントのRemoteNetworkStateのデータ構造を使用して伝搬される。

変形の実施例によると、応答可能になる前に他のブリッジからの大量のイベントにより殺到された遅いブリッジを有することを回避するために、タイムアウト処理がこの発見処理に実装される。
(d)メッセージ送信
HAVi仕様によると、HAViメッセージは、ソフトウェア要素からその他のソフトウェア要素に送信される。ソフトウェア要素はSEID(ソフトウェア要素識別子)により識別される。このSEIDは、ソフトウェア要素がある装置のGUIDと、装置内に固有のswHandleで構成される。HAViメッセージのヘッダは、宛先SEIDと発信元SEIDとを含む。

この実施例では、ブリッジ装置はHAViメッセージを変更しない(HAViメッセージがTAMヘッダを含まないとここでは呼ぶ)。宛先SEIDと、発信元SEIDと、プロトコル形式と、メッセージ形式と、メッセージ番号と、メッセージ長と、メッセージ・ボディーのフィールドは、同一に保たれる。しかし、メッセージングシステムはメッセージを宛先にルーティングする。そうするために、ブリッジのメッセージングシステムがクラスタでHAViメッセージを受信すると、宛先SEID(更に正確にはSEIDに含まれるGUID)を見る。このGUIDがその自己のGUIDである場合、このメッセージは内部のSE用であり、それを配信する。このGUIDがそのリモートのGUIDのリストに存在する場合、メッセージをその共通のポータルに転送する(又は１つの共通のポータルより多い適切な共通のポータルが存在するべきである)。共通のポータルは、このメッセージを(その内部テーブルに関して)対応する宛先装置に送信する。この装置が、最終の宛先装置又はパスの次のブリッジになり得る。

メッセージングシステムの一般的な動作に関しては、何も変更されていない。
・メッセージ番号は依然としてHAVi-1.1仕様のセクション3.2.1.2.3(p29)のルールに従う。このことはメッセージの最初の送信者と最後の受信者にも当てはまる。パス上のブリッジのメッセージングシステムは、何がHAViメッセージの中にあるかにこだわらず、ただ転送するだけである。
・‘簡単な’メッセージ(すなわち肯定応答が要求されていない)がただ送信され、肯定応答が必要とされない。
・‘信頼のある’メッセージが送信され、肯定応答又は否定応答(Ack又はNack)が受信されるまで、呼び出し側がブロックされる。このことは最初の送信者にも当てはまり、パス上のブリッジのメッセージングシステムはメッセージ(最初のメッセージ、Ack又はNackメッセージ)を送信するだけである。

図４のトポロジーに戻ると、GUID1を備えた装置のSEがHAViの信頼のあるメッセージを、GUID3を備えた装置のその他のSEに送信することを希望すると、GUID1を備えた装置のメッセージングシステムはブリッジのポータル(GUID5を備えた装置)にメッセージを送信する。ブリッジのメッセージングシステムは、宛先SEID及び更に正確にはそのSEIDに含まれるGUIDを見て、このメッセージがリモートのリストの装置用であることを推論する。次にそれがHAViメッセージを共通のポータルに転送し、次にその共通のポータルがGUID3を備えた装置にそれを送信する(図５参照)。次に肯定応答がGUID3を備えた装置からブリッジを介してGUI1を備えた装置に送信される。

エラー処理は以下のように実行される。

既にHAVi-1.1仕様に定められている以上のものは、HAViメッセージのエラー処理に追加されない。実際にパス上のブリッジのメッセージングシステムは、単にメッセージを転送するだけである。
(e)イベント・マネージャ
SEがイベントを(EventManger::PostEventのAPIで)送信する場合、イベント・マネージャは、ローカル・クラスタでのみそれを(EventManger::ForwardEventのAPIで)送出している。その他のイベント・マネージャからイベントを受信するブリッジのイベント・マネージャは、それをその共通のポータルに転送する。次に共通のポータルはこのイベントをそのクラスタに(EventManager::ForwardEventのAPIで)送信等する。

イベントを共通のポータルに転送するか否かのポータルのイベント・マネージャのルールは、元の送出者のGUIDがその共通のポータルのリモートのリストに存在するか否かである。元の送出者のGUIDはForwardEventメッセージのパラメータとして与えられる。次がForwardEventのAPIのリマインダである。
Status EventManger::ForwardEvent(
in SEID posterSeid,
in EventId eventId,
in sequence<octet> eventInfo)
posterSeidパラメータは、イベントをそのローカルのイベント・マネージャに送出した元のSEのSEIDである。このSEIDに含まれるGUIDは、SEが存在する装置のGUIDを与える。GUIDは、イベントを転送するか否かを決定するために、ポータルによって使用される。

ブリッジが非BA装置(この装置はリモート装置から制御可能である)からのイベントをリモート・クラスタに転送するが、ポータルのイベント・マネージャは、その共通のポータルから受信されたイベントメッセージ(すなわちリモートのイベント)をそのクラスタの非BA装置のイベント・マネージャに転送しない。

イベントのエラー処理は、基本的にHAVi-1.1(イベント・マネージャのプロトコルのセクション5.4.5(p144)参照)と同じままである。小さな更新点は、各ポータルがその背後にあるもののプロキシとして動作することである。従って、イベント・マネージャはそのローカル・クラスタのイベント・マネージャ(それがメッセージを送信したもの)から応答を受信し、ポータルは、それが共通のクラスタから全ての応答を受信したときに、その応答を合併して反映して応答する。

図６は、マルチクラスタ・ネットワークでのイベント送出の基本的な処理を示したものである。GUID3を有する装置のSEから送出されたイベントは、GUID3を有する装置のイベント・マネージャにより、そのクラスタの全てのイベント・マネージャに転送される。送出者のGUIDが共通のポータルのリモートのリストにあるとすぐに、ポータルはこのイベントをリモート・クラスタに転送する(これが、ポータル6がポータル5に転送しない理由である)。次に、ポータルは非BA装置を除いてそのクラスタのイベント・マネージャに、このイベントを転送する(これが、装置2がこのイベントを受信しない理由である)。

変形の実施例によると、PostEventのAPIの“グローバル”パラメータは以下のように変更される。現在は、それはイベントが装置にローカルであるか、HAViネットワークにグローバルであるかを示すbooleanとして定められている。このbooleanは次のように‘enum’構造に交換される。

enum EventScope{LOCAL, CLUSTER, NETWORK};
好ましい実施例では、PostEventのAPIは不変のままである。
(f)レジストリ
HAViにおいて、レジストリのクエリ要求(Registry::GetElement又はRegistry::MultipleGetElement)は、SEによってレジストリに送信される。基本的な処理は、SEがローカルのレジストリにクエリ送出し、それがクエリをHAViネットワークの全ての他のレジストリに転送する。レジストリがリモート・ノードからクエリを受信するとすぐに、その自己のデータベースを検索した後にクエリに単に応答する。

この概念はここではブリッジと調和を保たれる。リモート・ノードからクエリを受信するレジストリは、ブリッジ装置のレジストリを除いて、その自己のデータベースを検索して応答する。基本的な処理は、SEがそのローカルのレジストリにクエリ送出し、そのローカルのレジストリがネットワークの全てのレジストリに要求を転送するままである。このことは以下に詳細化される。

ポータルのレジストリは、そのクラスタのレジストリからその共通のポータルのレジストリに届く要求をありのままに転送する。しかし、要求の最初の送信者のGUIDがその共通のポータルのリモートのリストに存在する場合(すなわち、その共通のポータルが最初の送信者の反対である)にのみ、それを行う。前述の通り、このことは異なるパスで同じ宛先にメッセージを送信することを回避する。その最初のGUIDがその共通のポータルのリモートのリストにない場合、要求は転送されない。このことはループのトポロジーで生じ得る。この場合、その共通のポータルが最初のGUIDをプロキシするクラスタのブリッジを介して(その他のルートによって)要求を受信する。更に、ブリッジのレジストリは、非BA装置のレジストリからの要求を転送しない。その装置はリモートのGUIDの認識を有しておらず、リモートのSEIDにメッセージを送信することができない(レジストリへの基本クエリはGUIDを有するSEIDを戻す)。

求められると、共通のポータルのレジストリは、他のブリッジを含むそのクラスタの他のレジストリに要求を転送することができる。従って、レジストリの要求は全ネットワークに送信される。

BA装置のレジストリは、そのクエリをそのクラスタにのみ送信し、クラスタ間のレジストリ通信は、レジストリ自体により制御される(‘クラスタ分離’)。図７では、ネットワーク・マネージャのリスト(ローカル及びリモート)を備えた３つのブリッジのループ状ネットワークが示されている。

変形の実施例によると、基本的な処理は以下の通りである。最初のレジストリ(装置GUID1)が全ネットワークの全てのレジストリにクエリを送信する。最初のクラスタで送信されたHAViメッセージの数は9(レジストリ毎に1)である(ネットワークに9個のレジストリがあるため)。全てのメッセージが全ての装置により転送されないため、他のクラスタではこの数は減少する。

好ましい実施例によると、最初のレジストリ(GUID1)は、その自己のクラスタの全てのレジスタにのみクエリを送信する。この最初のクラスタのHAViメッセージの数は、ここでは3である。次にブリッジのレジストリが、その共通のポータルのクラスタで前記の動作を繰り返す(しかし、最初の送信者GUID1が共通のポータルのリモートのリストに存在する場合にのみである。これがGUID7を有するポータルがGUID8を有するポータルにそれを転送しない理由である)。

この小さい例は、クエリの改善(9個ではなく、3個のメッセージ)を示すが、応答で同じ現象が現れる。好ましい実施例では、ポータルのレジストリがその共通のポータルのクラスタのレジストリの全ての応答を合併することにより、１つの単一の応答を作る。更に、この例では、全ての装置が１つのブリッジを通じて到達可能であるが、いくつかのブリッジがチェーン状になる場合には、冗長のHAViメッセージの数が、最初の送信者の近くのクラスタで非常に大きくなる。

レジストリのメッセージ処理は以下のように実行される。

クラスタ分離では、最初のレジストリはそのクラスタのすべてのレジストリにクエリ送出する。これは、要求の全体のトラヒックを減少させる。次に、ブリッジのレジストリが要求を転送する。ポータルが(共通のポータルのリモートのリストに基づいて)要求をその共通のポータルに転送するか否かを認識できるようにするために、HAViメッセージの発信元SEIDは、最初の送信者のものでなければならない(この発信元SEIDが変更された場合には、ネットワーク・マネージャの動作に選択されたルート管理のため、ループ・ネットワークのクエリが終点を有さない)。しかし、ネットワークの全てのレジストリは最初の要求者に応答し、クエリを送信したものより多い応答をこれが受信し、理解されないことがある。これが、この実施例によると最初の要求者がそのローカルのクラスタのレジストリのみから応答を受信する理由である。

(GetElementの例で)この問題を解決するために以下の変更が使用され得る。

1.BA装置のレジストリは、それがそのクラスタにのみクエリを送信したが、全ネットワークの全てのレジストリから応答を受信することを認識する。メッセージ数の減少は、要求についてのみ行われ、応答について行われない。非BA装置からの要求が転送されないため、それが機能し得る。

2.Register::GetElementのAPIが変更される。最初の要求者のSEIDについての情報を有するように、新しいパラメータが追加される。APIは以下のようになる。

Status Registry::GetElement(
in SEID initialRequester,
in SimpleQuery query,
out sequence<SEID> seidList)
このメッセージを受信するブリッジのポータルは、この最初の要求者のパラメータのSEIDに含まれるGUIDに基づいて、クエリをその共通のポータルに転送するか否かを認識する。応答についてトラヒックの改善が行われる。ブリッジは、要求をそのリモート・クラスタに転送する際に、HAVi1.1装置にHAVi1.1メッセージを送信し、(各装置のSDDのバージョンのフィールドに基づいて)BA装置にこの新しいメッセージを送信しなければならない。その要求は、(最初の要求者のものではなく)ブリッジの発信元SEIDを備えた新しいものである。ポータルはそれに送信された全ての応答を集め(それが要求の発信元SEIDであるため)、その最初の要求者(当初要求を受信した装置)に送信する１つのSEIDリストに合併する。

3.前記2の変形において、非ブリッジのレジストリは最初の要求者の識別を使用しない。この情報は要求をリモート・クラスタに転送するか否かを決定するために、ブリッジ装置のレジストリにのみ有用である。その他の変形は、ブリッジ装置に専用の新しいメソッド呼び出しでレジスタのAPIを拡張することにある。ブリッジ認識レジストリは、ポータルのレジストリにこの呼び出しを使用する。

Status Registry::ForwardGetElement(
in SEID initialRequester,
in SimpleQuery query,
out sequence<SEID> seidList)
呼び出されたブリッジ装置は、最初の要求者の正体について認識する。非ブリッジ装置は、通常のGetElement呼び出しを受信する。双方の呼び出しは最初の要求者のSEIDではなく、ブリッジの発信元SEIDを有する。ブリッジがレジストリから全ての応答を受信すると、それは１つのSEIDリストに合併し、最初に受信したForwardGetElement呼び出しに応答する。

4.第４の変形は、レジスタのAPIの変更を回避することにある。GetElement要求は、ブリッジにより現状のままで(すなわち、HAViメッセージの発信元SEIDを変更せずに)転送される。ブリッジ装置がそのクラスタのレジストリ(その他のブリッジ又は非ブリッジ装置)から応答を受信すると、それはその応答を転送しない。それはその応答を分析し、クエリを受信した要求者に返信する合併したSEIDのリストを構築するために、SEIDのリストを抽出する。それが全ての応答を受信すると、合併したSEIDリストでその自己の応答を送信することができる。

次の表は、４つの提案された変形の是非を要約するものである。

GetElementのAPIが変更される必要がないため、好ましい変形は３番と４番である。変形3は、ブリッジ間の同期を可能にする利点を有する。

図８は、第３の変形を使用してGetElement呼び出しの相互作用の例を示す。

最初の送信者がGetElement要求をそのローカルのレジストリに送信する。次にローカルのレジストリは、このGetElement要求をそのローカル・クラスタの他のレジストリに転送する。ブリッジのレジストリがこの要求を受信すると、それをその共通のポータルのレジストリに送信する(発信元SEIDに含まれるGUIDがこの共通のポータルのリモートのリストにあることを仮定する)。次にこれが新しい要求とみなされる。その新しい要求は、共通のポータルのクラスタのレジストリに送信される。GetElementは非ブリッジ装置に送信され、ForwardGetElementはブリッジ装置に送信される。他のブリッジがこのクラスタに存在する場合に、前記処理が繰り返される。

各リモート・クラスタでは、異なる要求がブリッジ装置のレジストリにより送信される(すなわち、ブリッジは最初の要求をリモート・クラスタに単に配置するのではない)。ブリッジ装置はこの要求を追跡し、そのクラスタのレジストリの応答をその共通のポータルに戻す。ブリッジ装置のレジストリがそのクラスタのレジストリから全ての応答を受信すると、それを１つの単一の応答(１つのSEIDリスト)に合併し、それをその共通のポータルに提供する。次に共通のポータルは、自己のSEIDリストで補われたこのSEIDリストを要求者のレジストリに送信することができる。要求者のレジストリがその他のブリッジ内である場合、又はブリッジのGetElement応答が最初の要求者に接続されている場合、この応答はForwardGetElement応答である。

図８の特有の例では、SEIDリストはブリッジ装置により合併される。
-GUID6を備えたポータルは、GUID7を備えた装置からのリスト(E)と自己のリスト(D)を、GUID5を備えたその共通のポータルに戻す。GUID5を備えたポータルはこのリストを受け取り、その自己のリスト(C)に追加する。結果は(C,D,E)である。
-GUID10を備えたポータルは、GUID3を備えた装置から(空)と、GUID4を備えた装置(F)からと、その自己のリスト(空)から、GUID8を備えた装置からのリスト(空)を、GUID9を備えたその共通のポータルに戻す。結果は(F)である。
-GUID1を備えた装置のレジストリは、GUID5を備えた装置(C,D,E)からと、GUID9を備えた装置(F)から、GUID2を備えた装置(B)からの応答を受信する。それはその自己のリスト(A)を追加し、SEに応答を戻す。最終的な結果は(A,B,C,D,E,F)である。

GetElementメソッドについて述べられたことはまた、MultipleGetElementメソッドにも適用可能である。以下のものは、特にブリッジのレジストリに専用の新しいAPIである。

Status Registry::ForwardMultipleGetElement(
in SEID initialRequester,
in ComplexQuery query,
out sequence<SEID> seidList)
(g)ストリーム
既知のHAViストリーム・マネージャは、ストリーム接続を確立することを可能にするシステムソフトウェア要素である。ストリーム接続は、ソース(source)の機能構成要素とシンク(sink)の機能構成要素を関連付け(その結果として、関連するソース(source)とシンク(sink)装置)、必要なリソースの可用性を保証する。このリソースはチャネル、帯域等であることがある。図９は、HAViにより特定されたストリーム接続モデルを示す。２つの機能構成要素が相互接続されている。機能制御モジュールと装置制御モジュールとの内部接続(FCM/DCM)が各関連する装置で行われている。装置接続は、関連する装置の間で行われている(図９の２つのFull A/V装置)。論理接続はHAViレベル(すなわちソフトウェア要素間)であり、物理接続は実際の装置(論理レベルでDCM/FCMにより表されるもの)を含む。

ストリーム接続が確立されると、ストリームがソース(source)とシンク(sink)の間で送信されることがある。HAViでは、ストリーム接続を作ることを望む各アプリケーションは、そのローカルのストリーム・マネージャ(すなわち、同じ装置にあるストリーム・マネージャ)を使用しなければならない。

HAVi仕様によると、機能構成要素は、FCM(機能構成モジュール)により、ネットワークのどこかに表され、装置は、DCM(装置制御モジュール)により、ネットワークのどこかに表される。クライアントアプリケーションがそのローカルのストリーム・マネージャからストリーム接続を要求すると、それはソース(source)とシンク(sink)の機能構成要素の身元を示す。ストリーム・マネージャに提供される情報は、FcmPlug構造にグループ化される。
-TargetId：機能構成要素(FCMではない)がある装置のGUIDと、装置内の構成要素へのインデックス
-プラグ方向：イン又はアウト
-機能構成要素がいくつかのプラグを管理している場合にはプラグ番号
ストリーム・マネージャは、内部接続(すなわち装置内の接続)を実現するために、DCMのサービスを使用する。DCMモジュールを動作するために、ストリーム・マネージャはHAViメッセージを使用する。従って、内部接続を確立する方法は、媒体の技術(例えばIEC61883/IEEE1394)に依存しない。

ストリーム・マネージャは、装置ストリーム接続を設定するために、そのリンクレイヤのサービス(例えばIEC1883 CMPプロトコル)を使用する。

この実施例によると、マルチクラスタのストリームの処理は以下のようになる。

単一クラスタのHAViネットワークでは、ストリームを確立するために、クライアントはそのローカルのストリーム・マネージャを使用する。このローカルのストリーム・マネージャは、このストリームを完全に担う。マルチクラスタ・ネットワークでは、クライアントにローカルのストリーム・マネージャは、ソース(source)及び／又はシンク(sink)装置と同じクラスタにないことがある。更に、それはソース(source)及び／又はシンク(sink)装置に使用される媒体技術を認識しないことがある。従って、基本的な原理は、パスのストリーム・マネージャを協力させることである。

簡単な単一クラスタのストリームでは、クライアントはストリーム・マネージャにより使用される転送形式と伝送フォーマットとチャネルとプラグを指定することが可能である。マルチクラスタのストリームでは、ストリームが横断するクラスタ毎に、前記の全てのパラメータをクライアントが選択できることを考えることは現実的ではない(目的は、クライアントが全く認識していない媒体技術を有することができることである)。従って、クライアントは帯域の方針(静的又は動的)と、ストリーム形式(ストリームに固有である)を単に指定しなければならない。次にストリーム・マネージャが全ての転送の問題を担う。

HAViのブロードキャスト・ストリームは、ストリーム・マネージャのSprayOutとTapInのAPIで設定される。

この実施例によると、ストリーム・マネージャがそのAPIでローカル呼び出しを受信し、目的装置がリモートである(ローカル・クラスタにない)場合、それは目的の機能構成要素(装置)に接続された最も近いポータルのストリーム・マネージャにその呼び出しを転送する。次に、このストリーム・マネージャはブロードキャスト接続を実行するが、この接続はリモート・クラスタにローカルであるに過ぎない。従って、ブロードキャスト・ストリームはブリッジを横断しないが、リモートで制御され得る。

ポイント・ツー・ポイント・ストリーム用の提案されたAPIが、次に記載される。

HAVi-1.1装置との下位互換性を保つために、ブリッジを横断する前記ストリーム又はリモート・クラスタの前記ストリーム用に新しいストリーム・マネージャのメソッドを定義する必要がある。それが以下に提示される。

既知のストリーム・マネージャのAPIに比較して、新しいメソッドは下線付である。

(a)StreamManager::MultiClusterFlowTo
プロトタイプ
Status StreamManager::MultiClusterFlowTo(
in boolean dynamicBw,
in FcmPlug source,
in FcmPlug sink,
in boolean anyStreamType,
in StreamType streamType,
out ConnectionId connId)
パラメータ
-dynamicBw 動的(dynamicBwがTrueである)又は静的(dynamicBwがFalseである)な帯域割り当てが設定されるべきかを示す。
-source ソース(source)プラグを特定するFcmPlug構造。
-sink シンク(sink)プラグを特定するFcmPlug構造
-anyStreamType ストリーム形式がクライアントにより指定されたもの、又はストリーム・マネージャにより選択されたものでなければならないかを示す。
-streamType クライアントにより指定されたものである場合のストリーム形式。
-connId FlowToにより戻されるConnectionId値
説明
このAPIにより、クライアントがマルチクラスタのHAViネットワークでストリームの生成を要求することが可能になる。そのようなネットワークでは、ソース(source)装置とシンク(sink)装置は必ずしも同じ媒体形式にある必要がない。ソース(source)とシンク(sink)で同じでなければならない唯一のパラメータは、ストリーム形式である。ストリーム形式は変換され得るが、それはコンバータ・モジュール(例えば、一方のストリーム形式の入力と他方の異なるストリーム形式の出力とを備えたコンバータFCM)で行われる。転送形式の変換はブリッジで実行される。この実施例によると、２つの異なる媒体技術を接続するブリッジは、ストリームとメッセージの転送形式を１つの形式から他のものに変換することが可能である。

従って、この実施例によると、クライアントは、このマルチクラスタ接続に使用される転送形式と伝送フォーマットとチャネルを管理しない。それは、ストリームのパス上のブリッジのストリーム・マネージャにより処理される。
エラーコード
-StreamManager::ESOURCE_FCM sourceにより示されたFCMが存在しない
-StreamManager::FSINK_FCM sinkにより示されたFCMが存在しない
-StreamManager::ESOURCE_PLUG sourceにより示されたFCMが特定のプラグを含まない
-StreamManager::FSINK_PLUG sinkにより示されたFCMが特定のプラグを含まない
-StreamManager::EUNSUP_STREAM 接続が未対応のストリーム形式を必要とする
-StreamManager::ENO_MATCH_STREAM プラグが互換性がない(ストリーム形式の不一致)
-StreamManager::ENO_MATCH_BW ソース(source)の帯域がシンク(sink)により対応されたものを超える、又はhint.Stype.maxBWがソース(source)／シンク(sink)FCMの対応するStype.maxBWを超える(帯域の不一致)
-StreamManager::ENO_MATCH_SPEED ソース(source)がシンク(sink)に未対応の伝送速度を使用する
-StreamManager::ENO_MATCH_DIR プラグが互換性がない(方向の不一致)
-StreamManager::ESOURCE_BUSY ソース(source)プラグがその他のストリームのメンバである
-StreamManager::ESINK_BUSY シンク(sink)プラグがその他のストリームのメンバである
-StreamManager::EDEV_BUSY 装置プラグの割り当て失敗
-StreamManager::EINSUFF_BANDWIDTH 帯域割り当てが失敗した
-StreamManager::EINSUFF_CHANNEL チャネル割り当てが失敗した
-StreamManager::ESTATICBW dynamicBwがFalseの値を有し、ストリーム形式が可変レートであるが、ソース(source)が静的帯域割り当てに設定され得ない
-StreamManager::ERESERVED_SOURCE 予約の保護のため、要求された接続が確立(すなわちオーバレイされない)及び拒絶される必要がある
-StreamManager::ERESERVED_SINK sink(FlowTo要求を行うソフトウェア要素ではない)により示されるFCMが予約済である
-StreamManager::EDEV_CONN 装置接続の確立の失敗
-StreamManager::ESHARE ソース(source)プラグが共有可能でないため、接続が確立され得ない(FlowTo要求を行うソフトウェア要素と所有者が異なる)
(b)StreamManager::OnThePath
プロトタイプ
Status StreamManager::OnThePath(
in boolean dynamicBw,
in FcmPlug source,
in FcmPlug sink,
in StreamType streamType,
in TransportType segmentTransportType,
in TransmissionFormat segmentTransmissionFormat,
in Channel segmentChannel,
in ConnectionId connId)
パラメータ
-dynamicBw 動的(dynamicBwがTrueである)又は静的(dynamicBwがFalseである)な帯域割り当てが設定されるべきかを示す。
-source ソース(source)プラグを特定するFcmPlug構造。
-sink シンク(sink)プラグを特定するFcmPlug構造
-streamType 接続のストリーム形式。ストリーム形式は全体の接続を通じて一意であるが、転送形式と伝送フォーマットとチャネルは異なり得る(特に多様な媒体技術を横断するとき)
-segmentTransportType, segmentTransmissionFormat, segmentChannel 現在のセグメント(すなわちこの呼び出しを受信するポータルが取り付けられたクラスタ)の転送形式と伝送フォーマットとチャネルの値
-connId 最初のストリーム・マネージャにより割り当てられたConnectionId値
説明
このAPIは、少なくとも１つのクラスタを通じた接続を構築するために、ブリッジのストリーム・マネージャ間で使用される。dynamicBwとsourceとsinkのパラメータは元のMultiClusterFlowToのメソッドの呼び出しからコピーされる。それらは、パスのどのポータルにストリームを送信する必要があるかを決定するために、ポータルのストリーム・マネージャにより使用される。

streamTypeのパラメータはストリームの形式を特定する。この形式は、全体のストリームで一意であり、ストリームを運ぶために使用される転送により影響を受けない。そのストリーム形式を(例えばDVからMPEG2に)変更するストリームは、コンバータ(例えばFCMコンバータ)を通過し、実際に２つの動作中のストリームが存在し、FCMコンバータは最初のストリーム用のシンク(sink)と変換されたストリーム用のソース(source)である。

“セグメント”のパラメータ(segmentTransportTypeとsegmentTransmissionFormatとsegmentChannel)は、ストリームの現在の(すなわち目的のストリーム・マネージャにローカルの)セグメントで使用されるパラメータを特定する。これは、この呼び出しを受信するポータルのストリーム・マネージャがそのセグメントで確立された全ての情報を取得し、その共通のポータルに内部でそれを接続するのに有用である。

connIdのパラメータは、最初のストリーム・マネージャにより記入され、そのセグメントのストリームをマルチクラスタのストリームに“加える”ために、ストリームのパスのポータルのストリーム・マネージャにより使用される。
エラーコード
-StreamManager::EUNSUP_TRANSPORT 接続が未対応の転送形式を必要とする
-StreamManager::EUNSUP_STREAM 接続が未対応のストリーム形式を必要とする
-StreamManager::ENO_MATCH_FMT プラグが互換性がない(伝送フォーマットの不一致)
-StreamManager::ENO_MATCH_SPEED ソース(source)がシンク(sink)により対応されていない伝送速度を使用する
-StreamManager::ENO_MATCH_TRANSPORT プラグが互換性がない(転送形式の不一致)
-StreamManager::ENO_MATCH_DIR プラグが互換性がない(方向の不一致)
-StreamManager::ESOURCE_BUSY ソース(source)プラグがその他のストリームのメンバである
-StreamManager::ESINK_BUSY シンク(sink)プラグがその他のストリームのメンバである
-StreamManager::EDEV_BUSY 装置プラグの割り当て失敗
-StreamManager::EINSUFF_BANDWIDTH 帯域割り当てが失敗した
-StreamManager::EINSUFF_CHANNEL チャネル割り当てが失敗した
-StreamManager::EDEV_CONN 装置接続の確立の失敗
マルチクラスタのストリーム接続の設定のための処理は以下の通りである。

マルチクラスタのストリームは、クライアントにローカルのストリーム・マネージャにより起動され、HAVi-1.1ではそれによって所有される(“所有する”とは、そのローカル接続マップに存在するという意味である)。このストリーム・マネージャは“最初の”ストリーム・マネージャと呼ばれる。それは、シンク(sink)装置へのパス上の目的の機能構成要素(装置)の最も近いポータルのストリーム・マネージャに呼び出しを転送する。その結果、ポータルのストリーム・マネージャは、(ローカル・クライアントによる)ローカル呼び出しと、(リモートのストリーム・マネージャによる)リモート呼び出しとを受信することができる。

このポータルのストリーム・マネージャは、目的の装置の機能構成要素とクラスタの接続を行う役割をし、その共通のポータルのストリーム・マネージャは、ストリームのパスの次のクラスタの接続を行う役割をする。ストリームが他のブリッジを横断する場合、共通のポータルのストリーム・マネージャは、ストリームのパスの次のブリッジのストリーム・マネージャにHAViメッセージを送信し、それによりその次のブリッジのストリーム・マネージャがその共通のポータルに内部の接続を転送することができ、それがそのクラスタの接続を行う等である。各セグメントでは、適切なストリーム・マネージャがDCMのAPIを呼び出して転送パラメータの選択を実行し、そのDCMはソース(source)とシンク(sink)装置の１つになり得るが、同様にパスのブリッジにもなり得る。

従って処理は以下のようになる。
1.クライアントは、最初のストリーム・マネージャと呼ばれるそのローカルのストリーム・マネージャのMultiClusterFlowToのAPIを呼び出す。
2.最初のストリーム・マネージャは、ソース(source)機能構成要素(FCMではなく、装置)を調べ、シンク(sink)へのパス上のソース(source)のクラスタに接続された最初のポータルに呼び出しを転送する。このポータルはプライマリ・ポータルと呼ばれる。２つの可能性があるが、動作に違いはない。
・ソース(source)機能構成要素がリモート・クラスタにあり、それに接続された最も近いポータルのストリーム・マネージャ(ネットワーク・マネージャにより提供されたNetDeviceInfo構造のnearestPortalGuidのパラメータでわかる)にMultiClusterFlowTo呼び出しを転送する。
・ソース(source)機能構成要素がローカル・クラスタにあり、シンク(sink)機能構成装置へのパス上のローカル・クラスタのポータルのストリーム・マネージャにMultiClusterFlowTo呼び出しを転送する(シンク(sink)装置のGUIDはこのポータルのリモートのリストにあり、ローカル・クラスタのその他の如何なるポータルのリモートのリストにも存在しない)。
3.プライマリ・ポータルのこのストリーム・マネージャは、ストリームの終点でストリーム形式の全てのDCMとFCMのHAVi動作を実行する。更に、このクラスタの転送で全てのHAVi動作を実行する。
4.次にこのストリーム・マネージャは、最初のセグメント(すなわち、ソース(source)装置とプライマリ・ポータルとの間)でストリームを設定することを担う。
5.次にそれは、その共通のポータルのストリーム・マネージャに手を貸す。
6.このストリーム・マネージャは、２番目(又は次)のセグメントでストリームを設定することを担う。それは最後のシンク(sink)装置又はその他のポータルまでであり得る。セグメントでのストリームの転送は、このストリーム・マネージャにより完全に決定及び処理される(HAVi動作とDCM/FCM呼び出しを含む)。
7.その他のポータルがパスにある場合、ストリーム・マネージャは、シンク(sink)装置へのパス上の次のポータルにあるストリーム・マネージャのStreamManager::OnThePathのAPIを呼び出す。

特有のクラスタでは、接続の構築は、ソース(source)とシンク(sink)の終点(ポータル又は装置)のストリーム・マネージャを含む。

処理の図は図１０に示される通りである。

マルチクラスタのストリーム接続の解除については、新しいAPIの必要性は存在しない。動作中のストリームをドロップすることを希望する何らかのSEは、ストリームを所有するストリーム・マネージャのDropのAPIを呼び出す。それがマルチクラスタのストリームである場合、この最初のストリーム・マネージャは、ストリームのパス上の最初のポータルにその呼び出しを転送し、解除処理は構築処理と同一であり、それが担うクラスタの接続のための識別子として各ポータルのストリーム・マネージャが内部に保つConnectionIdに基づく。

この解決策で、HAVi-1.1装置はリモートのストリーム・マネージャにより確立されたストリームを見ることすらできないため、それをドロップすることができない。それは、そのクラスタのストリーム・マネージャにより所有されるマルチクラスタのストリームを(このストリームのソース(source)及び／又はシンク(sink)を認識できない場合ですら)ドロップすることができることがある。

変形として、接続の確立は、ソース(source)からシンク(sink)ではなく、シンク(sink)からソース(source)に行われ得る。

動的帯域割り当ても、マルチクラスタのストリームで管理され得る。MultiClusterFlowToのAPIでdynamicBwのbooleanのパラメータがTrueに設定されている場合、DCMのソース(source)はそのクラスタにリソースの再割り当てをすることを担う。次にそれがBandwidthRequirementChangedイベントを送信する。このイベントは、パスの次のセグメントを担うストリーム・マネージャにより取得される。このストリーム・マネージャは必要に応じて帯域の再割り当て等を行う。MultiCluseterFlowToのAPIでdynamicBwのbooleanのパラメータがFalseに設定されている場合、(HAVi-1.1に記載されている通り)ストリームの必要な帯域の変化がストリームを失敗モードにすることがある。

ストリーム接続のエラー処理は以下のように実行される。構築処理の間に１つのセグメントで接続が確立され得ない場合、ストリーム・マネージャはStatusの戻り値に失敗の理由を備えてOnThePathメッセージを返信する。次に最初のストリーム・マネージャまで接続がセグメント毎に解除され、その最初のストリーム・マネージャは、そのクライアントに警告し、又は利用可能な場合は“代替のパス”を受け取る(以下参照)。

既存の接続がセグメントで切断されると(バスのリセット、リソース不足等のため)、接続を担う前記のセグメントのリソース・マネージャは、最初のストリーム・マネージャにより取得されるMultiClusterConnectionDroppedイベントを送信し、これがストリームをドロップすること、又は“代替のパス”を通じて動作中に保つことを試みることを担う。最初のストリーム・マネージャは、OnThePathのAPIのconnIdのパラメータを通じて取り出し可能である。このconnIdパラメータは、mgrパラメータへのアクセスを与え、そのmgrパラメータは最初のストリーム・マネージャのSEIDである。

カプセル化対変換
この実施例によると、ストリームが媒体技術Aに基づくクラスタから、媒体技術Bに基づくクラスタを通じて、媒体技術Aに基づくクラスタに戻ると、B形式のクラスタのストリーム・マネージャは、ストリームの転送形式を変換しないことを決定する(例えば1394 over IP)。ストリームはクラスタBでカプセル化される。これは性能の理由で有用になり得る。しかし、シンク(sink)装置がクラスタBのこのストリームに追加されるとすぐに、媒体技術Bの表示手段がストリームを表示できるようにストリームが変換される。従って、A->Bの変換がクラスタBで行われ、B->Aの変換が目的のA形式のクラスタで行われる。

ストリーム・マネージャは、いわゆる接続マップを使用して、HAViネットワークで動作する全てのHAViストリームのリストを提供することができる。これはGetGlobalConnectionMapのAPIで行われる。それは、Registry::GetElementのものと同様の方法で動作する。前述の通り、ネットワーク・マネージャにより定められたループ解決処理のため、トラヒックを減少させるために、このクエリを他のクラスタのストリーム・マネージャに転送する新しいパラメータの必要性が存在する。提案されるAPIは以下の通りである。

Status StreamManager::ForwardGetGlobalConnectionMap(
in SEID initialRequester,
out sequence<Connection> list)
initialRequesterのパラメータにより、ポータルがこの要求をその共通のポータルに転送しなければならないか否かを知ることが可能になる。各ストリーム・マネージャのローカル接続マップは、ポータルのストリーム・マネージャにより集められ、最初に要求したストリーム・マネージャに最終的に返信される。

この実施例によると、クラスタの装置からGetLocalConnectionMapを受信するブリッジのストリーム・マネージャは、そのSEIDから導かれる呼び出し側の身元に応じて異なって動作する。
・呼び出し側がストリーム・マネージャではない。このことは、SEがそのローカル接続マップを知りたいということを意味する。ローカル接続マップのみが応答で送信される。
・呼び出し側がHAVi-1.1装置(すなわち、非ブリッジ認識)のストリーム・マネージャである。同様に、ローカル接続マップのみが応答で送信される。
・呼び出し側がBA装置のストリーム・マネージャである。要求は共通のポータルに転送され(転送ルールが満たされる場合)、共通のポータルのストリーム・マネージャは、そのクラスタの全てのストリーム・マネージャにGetLocalConnectionMapを送信し、そのクラスタに接続された他のポータルのストリーム・マネージャにForwardGetGlobalConnectionMapを送信する。

更に、新しいマルチクラスタ接続を処理するために、Connectionのデータ構造に小さい変更が行われる。新しいエントリーが以下のConnectionTypeに追加される。

enum ConnectionType {FLOW, SPRAY, TAP, MULTI_CLUSTER_FLOW}
MULTI_CLUSTER_FLOWの接続形式の場合、Connectionの構造のtransmissionFormatとchannelのパラメータは、ソース(source)装置により設定される(実際にソース(source)とパスの最初のポータルの間の最初のセグメントのストリームにのみ反映する)。

connectionId構造からコピーされたsegmentIdパラメータで(mgrのフィールドが指定されたクラスタのストリームを担うストリーム・マネージャを特定する)、各セグメントの接続の識別の必要性が検討される。

この実施例によると、ループ解決処理で定められた主要なパスと比較して、特定の条件で代替のパスが提供される。

パスの１つのクラスタでのリソース不足のためストリームが確立され得ない場合、且つこのクラスタを通過しないソース(source)とシンク(sink)の間のその他のルートが可能である場合、ストリーム・マネージャとネットワーク・マネージャは、トラヒック混雑のクラスタを回避するために、代替のパスにストリームを経路変更することを決定することがある。このことは、元のルートと同じホップ数を有するルートに当てはまり得るが、大きいホップ数を有するルートにも当てはまることがある。この場合、ネットワーク・マネージャは、正しいパスが選択され得るように、他のポータルのリモートのリストに現在ある装置に到達できることを内部で追跡しなければならない。

図１１は、代替のパスを使用する例を示している。右側のクラスタ1101は、不運にもそのクラスタのほぼ全てのリソース(帯域若しくはチャネル又はその双方)を予約しているストリームで、既に動作中である。HAViアプリケーションは装置3と装置4の間でストリームを構築することを必要とする。ストリームがクラスタ1101を介して確立されるため、ネットワーク・マネージャの基本のリモートGUIDのリストでは、前記のことは動作せず、失敗になる。失敗がわかると、ストリーム・マネージャは、それを運ぶリソースを有する左側のクラスタを通過して、このストリームの代替のパスを使用することを決定する。その共通のポータル14を通じて装置13までストリームを送信することすら可能である。

代替のパスの決定のこの場合に次の処理が使用される。
1.接続の構築中にセグメント(クラスタ)でストリームの確立が不可能である。
2.クラスタの前のブリッジが警告を受ける(OnThePathの呼び出しのエラーが戻される)
3.その他のパスが存在するか否かをブリッジが検査する
4.見つからない場合は、OnThePathの呼び出しのエラーが前のブリッジに戻される
5.ステップ3³に進む
(h)リソース・マネージャ
リソース・マネージャはブリッジにより影響を受けるべきではない。
[II HAViブリッジ認識装置]
図１２は、この実施例によるブリッジ認識装置(残りの説明でBA装置と呼ばれる)の内部ソフトウェア・アーキテクチャを表す。BA装置は、HAVi1.1ソフトウェア要素と、SddManagerとネットワーク・マネージャとを有する。
・SddManager
ブリッジ装置に専用のセクションで既に提示したとおり、BA装置のSddManagerは、全HAViネットワークの何らかの装置のSDDデータを取り出すことを担う。これは、リモートのSddManagerにアクセスして、又はローカルの低水準の呼び出しを実行して行われる。
・CMM
HAVi-BA装置のCMMに基本的に変更は存在しない。CMMは、低水準のローカル・クラスタにアクセスすることを可能にすることを担う。CMMはローカル・クラスタの全てのGUIDのリストを戻すGetGuidListのAPIを依然として提供する。また、それはこのクラスタで低水準のメッセージを送受信する方法を提供する。実際にCMM1394はHAVi-1.1の文献で指定されている。

ネットワーク・マネージャ
BA装置のネットワーク・マネージャは以下のように動作する。
・クラスタの再構成の後に、ローカル発見を実行する。
・新しい装置を検出すると、そのそれぞれのリモートのリストを要求する。
・ENOT_READYのエラー応答を受信すると、RemoteNetworkUpdatedイベントを受信するため、ある時間だけ待つ。
・特定の時間の後にイベントが来ない場合、応答しなかったポータルのリモートのリストを取得することを再び試みることがある。
・ポータルからの全ての応答を有すると、リストを比較してその新しいリストを構築し、変化したフィールドと外れたフィールドと新しいフィールドを記入する。
・そのネットワーク装置のリストが終了すると、そのクライアントにNetworkUpdatedイベントを送信する。
・その新しいリストを構築する間に、ネットワーク装置のリストを取得する何らかのクライアントの要求は、ENOT_READYのエラーで応答される。
[III 新しいHAViの値]
HAVi1.1に存在するものに追加される新しいHAViソフトウェア要素の形式は、以下のように定められる。

この実施例によるHAViのSEIDは以下のようになる。

HAViのAPIコードは以下のようになる。

Registryと、StreamManagerと、SddManagerと、CMMIPの追加のHAVi動作コードは、この実施例によると以下のようになる。

この実施例によるSddManagerとNetworkManagerのHAViエラーコードは以下のようになる。

この実施例によるHAViシステムイベント形式は以下のようになる。

[IV 発見のシナリオ]
(a)ループのないネットワーク
図１８は、完全なネットワーク構築処理の間のネットワーク・マネージャの相互作用を示している。装置は最初に停止されており、次に同時に作動するため、各装置で並行して発見が行われる。ブリッジのネットワーク・マネージャについて、ローカル及びリモートのリストの構成が説明される。

図１３において、最初のローカル発見処理(すなわち、IEEE1394クラスタでのトポロジーの構築とIPクラスタのマルチキャスト通知)が示されている。この最初のステップの終了時に、図１３に示される通り、ネットワーク・マネージャはその内部テーブルにそのローカル装置を有する。

次に、ブリッジ装置は、そのネットワーク・マネージャが完全な非リモートのリスト又は不完全な非リモートのリストを有するか否かを検査する。非リモートのリストは、ローカルのリストと、クラスタに接続された他のポータルの全てのリモートのリストとを有する。そのような完全なリストが１つのポータルに存在する場合、それが他方(共通のポータル)に与えられ、その他方がそのリモートのリストを完全とみなす。図１４において、ブリッジABのGUID5のネットワーク・マネージャは、それがこの装置の唯一のブリッジであると認識するため、ブリッジはGUID6のリモートのリストを更新することができ、そのリモートのリストは(1,2,5)になる。ブリッジ装置BCについても同じであり、GUID7のネットワーク・マネージャが(3,4,8)としてそのリモートのリストを更新する。

図１５において、ブリッジ装置のネットワーク・マネージャは、装置のリモートのリストを相互に要求する。ブリッジ装置のネットワーク・マネージャは、そのリモート装置のリストを反復して更新することができる。特に、ポータル6とポータル7の非リモートのリストは、要求が応答されると完全になり、ポータル5と8のリモートのリストが更新され得る。

図１６において、BA装置のネットワーク・マネージャは、そのローカル・クラスタに接続された各ブリッジ装置にリモート装置のリストを要求し、そのグローバル・ネットワークのリストを構築する。

図１７において、クライアントのSEはそのローカルのネットワーク・マネージャに全ネットワークの装置のグローバルのリストを要求することができる。
(b)ループのないネットワークへの新しい装置の追加
図１８は、開始点(すなわち、ループのない既存のネットワーク)を示している。リモートのリストのみがブリッジのネットワーク・マネージャに示されている。

GUID9を備えた新しい装置が追加される。この装置は、ローカル発見手段(selfID、マルチキャスト等)を介して、それが接続されたクラスタで検出される。検出されると、このGUIDは、それに接続されたブリッジの共通のポータルのネットワーク・マネージャで更新される。これが図１９に示されており、共通のポータル7は、新しく接続されたGUID9でそのリモートのリストを更新する。

次に更新されたポータルは、他の(BA装置及びブリッジの)ネットワーク・マネージャにRemoteNetworkUpdatedイベントを送出する。このポータルに接続されたブリッジは、このイベントを取得し、その自己の共通のポータルのリモートのリストを更新する。図２０において、ポータル6はポータル7からイベントを取得し、その共通のポータル5を更新する。

その後、完全なネットワークが更新される。この時点でGUID9は全てのクラスタに認識されている。
(c)ループを備えたネットワーク
前述の通り、図２１に表されたネットワークの全ての装置は、多かれ少なかれ同時に作動する。最初のステップは、依然としてローカルのリストを作るローカル発見処理である。

この構成において、非ポータルは、有効なリモートのリストとしてその共通のポータルに与える完全な非リモートのリストを有することができる。全てのポータルは、それがそのクラスタで唯一のものでないことを認識するため、その自己の共通のポータルのリモートのリストを更新する前に、他のポータルにそのリモートのリストをまず要求する(図22)。また、このトポロジーにリーフ(leaf)がないため、各ポータルは他のものを待つ。

ポータルはGetRemoteDeviceListのクエリに応答できないため、ENOT_READYの応答エラーを送信する。ポータルのネットワーク・マネージャがそのようなエラーを受信すると、それは、そのクラスタに接続されたポータルがそのリモートのリストを更新し終えていないことを認識する(例えばその共通のポータルに接続された他のポータルを待っている：このことは非常に長い単一の回線のネットワークで生じ得る)。

この実施例によると、ポータルはその共通のポータルに不完全なリモートのリストを通信する。次に共通のポータルは、この不完全な情報でそのリモートのリストを更新する。これが図２３に表される。

次にポータルは、図２４に示される通り、RemoteNetworkChangedイベントでこの不完全なリモートのリストを送出する。このイベントはブリッジのネットワーク・マネージャについてのみであり、リストが安定状態にないことを明確に指定する(RemoteNetworkUpdatedは最後の安定したリストである)。

マルチクラスタのHAViネットワークの図である。 HAVi-HAViブリッジの図である。 SddManagerを使用する異なる場合を示したネットワークの図である。 CMMの使用例を示したマルチクラスタのHAViネットワークの図である。 ブリッジを通じたメッセージの送信を示した図である。 イベント・ポスティング・アルゴリズムを表した図である。 レジストリのトラヒック向上を表した図である。 ブリッジのレジストリ用の要求／応答アルゴリズムを表した図である。 先行技術のHAViストリーム接続モデルの図である。 マルチクラスタのストリーム構造を示した図である。 データ用の代替のルートを示したマルチクラスタのネットワークの図である。 HAViブリッジ認識装置のソフトウェア・アーキテクチャの図である。 ローカル発見処理を示したマルチクラスタのネットワークの図である。 リーフ(leaf)のブリッジでの第１のリモートのリストの更新を示したマルチクラスタのネットワークの図である。 ブリッジ・ネットワーク・マネージャの相互作用を示したマルチクラスタのネットワークの図である。 ネットワーク・マネージャのグローバルのリストを構築するための処理を示したブロック図である。 ネットワーク・マネージャのクライアント呼び出しを示したマルチクラスタのネットワークの図である。 リモートのリストの概念を示したマルチクラスタのネットワークの図である。 新しい装置の接続を示した図である。 更新されたリモートのリストの伝搬を示した図である。 ループを備えたネットワークでのローカル発見処理の図である。 どのポータルがリモートのリストを要求するかに応じた処理を示した図である。 不完全なリモートのリストでポータルの更新の処理を示した図である。 イベントを使用した不完全なリモートのリストの送信を示した図である。 GUIDプロキシ技術を使用した２つのHAViクラスタとブリッジとを有するネットワークの図である。

Claims (34)

1. ネットワークにおけるネットワーク装置の各クラスタとのインタフェース用の少なくとも２つのインタフェースを有するブリッジ装置であって、
   前記ブリッジ装置は、クラスタを接続するための少なくとも２つのインタフェース・ポータルを有し、
   前記ブリッジ装置が、少なくとも１つのネットワーク装置の装置記述構成メモリデータ(SDD)の要求を内部のクライアントから受信するための第１のソフトウェア構成要素(SDDM)をポータル毎に有し、
   前記第１のソフトウェア構成要素が、他の装置の同様のソフトウェア構成要素の関数呼び出しを通じて、他の装置から装置記述データを取り出すように適合されることを特徴とするブリッジ装置。
2. 請求項１に記載のブリッジ装置であって、
   前記第１のソフトウェア構成要素は、リモート・クラスタ装置へのパス上のブリッジ装置の同様のソフトウェア構成要素への関数呼び出しを通じて、同様のソフトウェア構成要素なしにリモート・クラスタ装置用のデータを取り出すように適合されたブリッジ装置。
3. 請求項１又は２に記載のブリッジ装置であって、
   前記第１のソフトウェア構成要素は、媒体依存の要求メッセージを前記装置に発行することにより、自分と同じクラスタの同様のソフトウェア構成要素なしに、装置用のデータを取り出すように適合されたブリッジ装置。
4. 請求項１ないし３のうちのいずれか１項に記載のブリッジ装置であって、
   前記第１のソフトウェア構成要素は、
   a.ネットワーク上の他の装置の第１のソフトウェア構成要素の識別子のリストと、
   b.前記リストにおける前記装置へのパスで最も近いポータルの各識別子に関係する、同様の第１のソフトウェア構成要素を欠く装置のリストと
   のうちの少なくとも１つを維持するように適合されたブリッジ装置。
5. 請求項１ないし４のうちのいずれか１項に記載のブリッジ装置であって、
   前記第１のソフトウェア構成要素は、そのポータルのローカル・クラスタに第１のソフトウェア構成要素を欠く装置の装置記述データにおける変化を監視し、前記ブリッジ装置の他のポータルに接続されたクラスタで、対応する装置記述データの変化イベントを生成するように適合されたブリッジ装置。
6. 請求項１ないし５のうちのいずれか１項に記載のブリッジ装置であって、
   各ポータルのポータルの他のソフトウェア構成要素とポータルのクラスタの通信媒体とのインタフェース用の第２のソフトウェア構成要素(CMM)をポータル毎に更に有し、
   前記第２のソフトウェア構成要素は、前記通信媒体にリモートでアクセスするために、少なくとも特定のメソッドがネットワークの他の装置のソフトウェア構成要素とグローバルにアクセス可能であるアプリケーションプログラム可能インタフェース(API)を有するブリッジ装置。
7. 請求項６に記載のブリッジ装置であって、
   グローバルにアクセス可能なメソッドは、書き込み、読み取り、ロック、登録、ドロップ、指示のうちの少なくとも１つを有するブリッジ装置。
8. 請求項１ないし７のうちのいずれか１項に記載のブリッジ装置であって、
   ネットワークの全てのクラスタの全ての装置のリストを維持するための第３のソフトウェア構成要素(NM)をポータル毎に更に有するブリッジ装置。
9. 請求項８に記載のブリッジ装置であって、
   前記第３のソフトウェア構成要素は、ネットワークの何らかのクラスタの変化の検出により、前記変化の性質をそのポータルのソフトウェア構成要素に通知する第１のイベントを生成するように適合されたブリッジ装置。
10. 請求項８又は９に記載のブリッジ装置であって、
    前記第３のソフトウェア構成要素は、イベントを発行するポータルのリモート装置のリストの状態を、他のポータルの前記第３のソフトウェア構成要素にのみ通知するための第２のイベントを生成するように適合されたブリッジ装置。
11. 請求項１０に記載のブリッジ装置であって、
    前記第２のイベントは、イベントを発行するポータルと比較してリモート装置(すなわち、イベントを発行するポータルの共通のポータルを通じて到達可能な装置)の潜在的に不完全なリストを有するブリッジ装置。
12. 請求項８ないし１１のうちのいずれか１項に記載のブリッジ装置であって、
    前記第３のソフトウェア構成要素は、ホストのポータルのリモート装置のリストが安定したことをクラスタの全ての装置の前記第３のソフトウェア構成要素に通知するための第３のイベントを生成するように適合されたブリッジ装置。
13. 請求項１２に記載のブリッジ装置であって、
    前記第３のイベントは、イベントを発行するポータルと比較したリモート装置(すなわち、イベントを発行するポータルの共通のポータルを通じて到達可能な装置)の完全なリストを有するブリッジ装置。
14. 請求項１ないし１３のうちのいずれか１項に記載のブリッジ装置であって、
    各ポータルは、ポータルのローカル・クラスタで検出されたイベントメッセージを共通のポータルに転送するための第４のソフトウェア構成要素(EM)を有するブリッジ装置。
15. 請求項１ないし１４のうちのいずれか１項に記載のブリッジ装置であって、
    各ポータルは、
    ブリッジのクラスタのうちの１つで、その他の装置の第５のソフトウェア構成要素から要求を受信するための第５のソフトウェア構成要素(Reg)と、
    発信アドレスとして最初の要求者の識別子で、その他のクラスタの第５のソフトウェア要素に前記要求を転送し、前記要求に対する非連結応答を最初の要求装置に返信するための手段と
    を有するブリッジ装置。
16. 請求項１ないし１４のうちのいずれか１項に記載のブリッジ装置であって、
    各ポータルは、
    ブリッジのクラスタのうちの１つで、その他の装置の第５のソフトウェア構成要素から要求を受信するための第５のソフトウェア構成要素(Reg)と、
    その他のクラスタの第５のソフトウェア要素に前記要求を転送するための手段であって、転送された要求が、前記転送するポータルの発信アドレスをパラメータとして含む手段と、
    前記転送された要求を受信及び連結し、前記要求に対する連結応答を最初の要求装置に返信するための手段と
    を有するブリッジ装置。
17. 請求項１６に記載のブリッジ装置であって、
    前記要求を転送するための前記手段は、ブリッジ装置の第５のソフトウェア要素に前記要求を転送するための第１のメッセージ形式と、非ブリッジ装置の第５のソフトウェア要素に要求を転送するための第２のメッセージ形式とを使用するように適合され、転送するポータルの識別子が第１のメッセージのパラメータであり、第２のメッセージのパラメータではないブリッジ装置。
18. 請求項１ないし１４のうちのいずれか１項に記載のブリッジ装置であって、
    各ポータルは、
    ブリッジのクラスタのうちの１つで、その他の装置の第５のソフトウェア構成要素から要求を受信するための第５のソフトウェア構成要素(Reg)と、
    発信アドレスとして最初の要求者の識別子で、その他のクラスタの第５のソフトウェア要素に前記要求を転送し、前記転送された要求に対する応答を傍受し、前記応答の内容を連結し、最初の要求に対する単一の連結応答を最初の要求装置に返信するための手段と
    を有するブリッジ装置。
19. 請求項１ないし１８のうちのいずれか１項に記載のブリッジ装置であって、
    そのクラスタの通信媒体の間でパケットの移動形式を変換するための手段を更に有するブリッジ装置。
20. 請求項１ないし１９のうちのいずれか１項に記載のブリッジ装置であって、
    各ポータルは、その他の装置の第６のソフトウェア要素からの接続確立要求の受信により、前記ブリッジを横断する接続のために、ローカル・クラスタの接続セグメントを確立するための第６のソフトウェア要素(SM)を有するブリッジ装置。
21. 請求項２０に記載のブリッジ装置であって、
    ポータルの前記第６のソフトウェア要素は、そのローカル・クラスタで接続を確立し、接続端末装置へのパスで次のセグメントの確立を実行するために、そのローカル・クラスタを次のポータルに通知するように適合されたブリッジ装置。
22. マルチクラスタ・ネットワークのクラスタへの接続用の装置であって、
    クラスタはブリッジ装置を通じて接続され、
    各ブリッジ装置は少なくとも２つのクラスタ・インタフェースを有し、
    各インタフェースが各クラスタのネットワーク装置としてみなされ、
    前記ネットワーク装置が、少なくとも第２の装置の装置記述構成メモリデータ(SDD)の要求を内部のクライアントから受信するための第１のソフトウェア構成要素(SDDM)を有し、
    前記第１のソフトウェア構成要素が、少なくとも１つの装置の同様のソフトウェア構成要素の関数呼び出しを通じて、少なくとも１つの他の装置から装置記述データを取り出すように適合されることを特徴とする装置。
23. 請求項２２に記載の装置であって、
    前記第１のソフトウェア構成要素は、リモート・クラスタ装置へのパス上のブリッジ装置の同様のソフトウェア構成要素への関数呼び出しを通じて、同様のソフトウェア構成要素なしにリモート・クラスタ装置用のデータを取り出すように適合された装置。
24. 請求項２２又は２３に記載の装置であって、
    前記第１のソフトウェア構成要素は、媒体依存の要求メッセージを前記第２の装置に発行することにより、自分と同じクラスタの同様のソフトウェア構成要素なしに、第２の装置用のデータを取り出すように適合された装置。
25. 請求項２２ないし２４のうちのいずれか１項に記載の装置であって、
    前記第１のソフトウェア構成要素は、
    -ネットワーク上の他の装置の第１のソフトウェア構成要素の識別子のリストと、
    -前記リストにおける前記装置へのパスで最も近いポータルの各識別子に関係する、同様の第１のソフトウェア構成要素を欠く装置のリストと
    のうちの少なくとも１つを維持するように適合された装置。
26. 請求項２２ないし２５のうちのいずれか１項に記載の装置であって、
    ネットワークの全てのクラスタの全ての装置のリストを維持するための第３のソフトウェア構成要素(NM)を更に有し、
    前記第３のソフトウェア構成要素は、そのローカル・クラスタに接続されたポータルからリモート装置のリストを取り出し、リモート装置のリストをローカル・クラスタ装置のリストと連結するための手段を有する装置。
27. 請求項２６に記載の装置であって、
    前記第３のソフトウェア構成要素は、前記装置の自己のローカル・クラスタに比較したリモート装置用のパスで最も近いポータルの指示を、ネットワーク装置のリストで維持するように更に適合された装置。
28. 請求項２５ないし２７のうちのいずれか１項に記載の装置であって、
    前記第３のソフトウェア構成要素は、ネットワークの何らかのクラスタの変化の検出により、前記変化の性質をそのローカル装置の構成要素に通知する第１のイベントを生成するように適合された装置。
29. 請求項２２ないし２８のうちのいずれか１項に記載の装置であって、
    リモートのソフトウェア要素のリストの要求をローカル・クライアントから受信し、ローカル・クラスタの装置の第５のソフトウェア要素にのみ前記要求を転送するための第５のソフトウェア構成要素(Reg)を有する装置。
30. 請求項２２ないし２９のうちのいずれか１項に記載の装置であって、
    同じ装置のクライアント用のアプリケーションプログラム可能インタフェース(API)を有し、シンク(sink)装置とソース(source)装置との間の接続を確立する要求を受信するように適合された第６のソフトウェア要素を有し、
    前記第６のソフトウェア要素は、ソース(source)装置とシンク(sink)装置との間のパスで、シンク(sink)装置へのパスでソース(source)装置に最も近いポータルを決定し、そのローカル・クラスタで接続を確立するためにそのポータルに適切な要求を送信し、パスの他の適切なポータルに前記要求を伝搬するように適合された装置。
31. なくとも２つの装置クラスタと少なくとも１つのブリッジとを有するネットワークにおいて装置を発見するための方法であって、
    少なくとも２つのクラスタはブリッジにより接続され、
    各ブリッジは各クラスタへの接続用の少なくとも２つのインタフェース・ポータルを有し、
    前記処理は、
    -そのローカル・クラスタの装置の識別子(GUID)のリストを各ポータルに取得させるステップと、
    -自分と同じクラスタの各ポータルからリモート装置のリストを各ポータルに要求させるステップと、
    -そのローカル装置のリスト、及び共通のポータルを通じて到達可能なリモート装置のリストをその共通のポータルから要求することにより、その自己のリモート装置のリストを各ポータルに構築させるステップと
    を有する方法。
32. 請求項３１に記載の方法であって、
    その装置への最短パスである場合に、所定の装置に向かうメッセージに対してブリッジを通過させるステップを更に有する方法。
33. 請求項３２に記載の方法であって、
    前記最短パスは、横断されるポータルの最低数を備えたパスである方法。
34. ブリッジ装置により接続された複数の装置クラスタを有するネットワークにおいて、ソース(source)装置とシンク(sink)装置との間の接続を確立するための方法であって、
    各ブリッジ装置がクラスタへの接続用のインタフェース・ポータルを有し、
    前記方法は、
    (a)ブリッジのポータルとネットワークの他のブリッジ認識装置に、ストリーム・マネージャ・ソフトウェア要素を提供するステップと、
    (b)装置のストリーム・マネージャ・ソフトウェア要素のレベルで、ローカル・クライアントからの接続から要求を受信するステップと、
    (c)シンク(sink)装置とソース(source)装置との間のパスで、ソース(source)装置に最も近いポータルを特定し、そのポータルに接続要求を送信するステップと、
    (d)ソース(source)装置とポータルのブリッジとの間の接続のセグメントを、接続要求を受信するポータルに確立させるステップと、
    (e)ソース(source)装置へのパスでそのブリッジの次のポータルを、接続要求を受信するポータルに所有させ、次のポータルのローカル・クラスタで接続の次のセグメントを確立させるステップと、
    (f)シンク(sink)へのパスで、もしあれば次のブリッジを特定し、接続の適切なセグメントを確立するように、シンク(sink)装置へのパス上の次のブリッジのリモート・ポータルに指示するステップと、
    (g)シンク(sink)装置への接続のセグメントが確立されるまでステップ(e)に進むステップと
    により特徴付けられる方法。

Images