JP2021527368A - ストリームを設定するための方法、ストリーム識別子情報を提供するための方法、ｄｎｓサーバーの使用、機器、コンピュータープログラムおよびコンピューター可読媒体 - Google Patents

Abstract

本発明は、ＴＳＮネットワーク、特にＩＥＥＥ ８０２．１に準拠したネットワークにおいてストリームを設定するための方法に関し、この方法では、・ストリーム参加部材（１，２）から、エントリが格納されているＤＮＳサーバー（６）へ要求メッセージ（８）が送信され、この要求メッセージはそれぞれ、ストリームに割り当てられている第１のタイプのストリーム識別子と、第１のタイプのストリーム識別子とは異なる、各ストリームに割り当てられている第２のタイプのストリーム識別子と、このようなタイプのエントリに対してのみ使用されている、もしくは使用される、所定のタイプの表示とを含んでおり、要求メッセージ（８）は少なくとも１つのストリーム参加部材（１，２）に既知の第１のタイプのストリーム識別子と、所定のタイプとを含んでおり、・ストリーム参加部材（１，２）はＤＮＳサーバー（６）から応答メッセージ（９）を受け取り、応答メッセージは、ストリームに属する第２のタイプのストリーム識別子を含んでおり、・ストリーム参加部材（１，２）は、受け取ったストリーム識別子を使用してストリームに登録する。

Description

本発明は、ＴＳＮネットワーク、特にＩＥＥＥ ８０２．１に準拠したネットワークにおいてストリームを設定するための方法に関する。さらに本発明は、ストリーム識別子情報を提供するための方法、ＤＮＳサーバーの使用、機器、コンピュータープログラムおよびコンピューター可読媒体に関する。

ＩＥＥＥ標準化の枠において、ＡＶＢ（オーディオ・ビデオ・ブリッジング）ワーキンググループにおいてイーサネットテクノロジ（ＩＥＥＥ ８０２を参照）が拡張され、保証されたＱｏＳ（いわゆる「サービス品質」）を実現するメカニズムが追加された。

Ｔｉｍｅ Ｓｅｎｓｉｔｉｖｅ Ｎｅｔｗｏｒｋｉｎｇ（ＴＳＮ）は、とりわけ、ブリッジング規格ＩＥＥＥ ８０２．１Ｑを拡張して、イーサネットネットワークを介したリアルタイムにクリチカルなデータの伝送メカニズムを含む、一連の規格を指す。これらのＴＳＮ規格には、たとえば、時刻同期（ＩＥＥＥ ８０２．１ＡＳ−Ｒｅｖ）、フレーム・プリエンプション（ＩＥＥＥ ８０２．１Ｑｂｕ）および予約（ＩＥＥＥ ８０２．１Ｑｃａ、ＩＥＥＥ ８０２．１Ｑｃｃ）ならびにその他の規格が含まれる。

ＡＶＢおよびＴＳＮの枠において、品質はいわゆるストリームによって保証されるべきである。ストリームは保護された通信接続を表す。ストリームを介した元来のデータ伝送の前に、データフレームの損失のないリアルタイム転送と時間通りの供給とを可能にするために、ネットワークリソースの登録および予約が行われる。ストリームの場合、リソースの予約は、特にいわゆるストリーム予約プロトコル（ＳＲＰ）によって実行可能である。ＳＲＰは、たとえば、Ｌｅｖｉ Ｐｅａｒｓｏｎによる論文「Ｓｔｒｅａｍ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ」（ＡＶｎｕ Ａｌｌｉａｎｃｅ Ｂｅｓｔ Ｐｒａｃｔｉｃｅｓ、２０１４年１１月３日（２０１４−１１−０３）、１〜２１ページ、ＸＰ０５５４４９６８８）、いわゆるＳｔｒｅａｍ Ｒｅｓｅｒｖａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＲＰ）において扱われている。

ＴＳＮストリームモデルにおいてデータストリームの方向が配向されている。送信側またはソースはここでは「トーカー」と称され、受信側またはシンクは「リスナー」と称される。一方では、厳密に１つの「トーカー」が２つ以上の「リスナー」に同時にデータを送信することがあり得る。他方では、２つ以上の「リスナー」が厳密に１つの「トーカー」に同時に送信することがあり得る。

タイムセンシティブなネットワークに対して、より正確にはＴＳＮコントロールプレーンに対して、アプリケーションは、属する識別子、特にいわゆるストリームＩＤを介して個々のストリームを識別する。ＴＳＮの観点からは、これらは、内部構造のない６４ビット長のビットストリングである。

２つ以上のストリーム参加部材(Stream-Teilnehmer)が、同じストリームＩＤを有する共通のストリームと接続できるようにするために、すべての参加部材は、ストリームに属する、コントロールプレーンの識別子、特にストリームＩＤを知っている必要がある。

ＴＳＮアーキテクチャでは、ストリーム識別用のストリームＩＤは、６４ビットのみを有する、比較的短いものになるように意図的に選択されている。これは、技術的な理由から、すべてのストリームＩＤがそれぞれ、タイムセンシティブなネットワークのすべてのノード、特にＴＳＮ ＬＡＮ内のすべてのＴＳＮブリッジにおいて知られている必要があり、比較的長いストリームＩＤはすぐにメモリバジェットを超えてしまうだろうということに起因する。

ストリームＩＤは、長さが比較的短いため、「管理不足」の対象になる。

ネットワーク内のストリームＩＤの「管理不足」に対処する１つの手法は、手動管理である。これは、たとえばＥｘｃｅｌテーブル等のテーブルを誘導することによって実行できる。しかし、これには相当な手間が伴う。

米国特許出願公開第２０１３／２８２４５３号明細書は、メディアをストリーミングするためのシステムおよび方法を開示している。

特に、ストリームＩＤを新たに全体的に計画する必要なく、「プラグアンドプレイ」だけで、新しいＴＳＮアプリケーションをネットワークに追加できるようにするには、動作中のストリームＩＤの自動管理も望まれるだろう。

したがって、本発明の課題は、僅かな手間で実施され、特に、コントロールプレーンにおいて使用されるストリーム識別子の手動管理が不要である、ネットワーク、特にＩＥＥＥ ８０２．１に準拠したネットワークにおいてストリームを設定するための方法を提示することである。さらに、本発明の課題は、そのような方法を実施するのに適している機器を提示することである。

上述の課題は、ＴＳＮネットワーク、特にＩＥＥＥ ８０２．１に準拠したネットワークにおいてストリームを設定するための方法によって解決され、この方法では、
・ストリームを介して少なくとも１つの別のストリーム参加部材にデータを送信することを望む、かつ／または少なくとも１つの別のストリーム参加部材からストリームを介してデータを受信することを望む少なくとも１つのストリーム参加部材から、エントリが格納されているＤＮＳサーバーへ要求メッセージが送信され、要求メッセージはそれぞれ、ストリームに割り当てられている第１のタイプのストリーム識別子と、第１のタイプのストリーム識別子とは異なる、各ストリームに割り当てられている第２のタイプのストリーム識別子と、このようなタイプのエントリに対してのみ使用されている、もしくは使用される、所定のタイプの表示とを含んでいる。ここで要求メッセージは少なくとも１つの、少なくとも１つのストリーム参加部材に既知の第１のタイプのストリーム識別子と、所定のタイプとを含んでおり、
・少なくとも１つのストリーム参加部材がＤＮＳサーバーから応答メッセージを受け取り、この応答メッセージは、ストリームに属する第２のタイプのストリーム識別子を含んでおり、かつ
・少なくとも１つのストリーム参加部材は、受け取ったストリーム識別子を使用してストリームに登録する。

さらに、上述の課題は、機器によって解決され、この機器は、
・エントリが格納されているＤＮＳサーバーへ要求メッセージを送信するように構成および／または設定されており、要求メッセージはそれぞれ、ストリームに割り当てられている第１のタイプのストリーム識別子と、第１のタイプのストリーム識別子とは異なる、各ストリームに割り当てられている第２のタイプのストリーム識別子と、このようなタイプのエントリに対してのみ使用されている、もしくは使用される、所定のタイプの表示とを含んでいる。ここで要求メッセージは少なくとも１つの、機器に既知の、第１のタイプのストリーム識別子と、所定のタイプとを含んでおり、
・ＤＮＳサーバーから応答メッセージを受け取るように構成および／または設定されており、応答メッセージは、ストリームに属する第２のタイプのストリーム識別子を含んでおり、かつ
・受け取った第２のタイプのストリーム識別子を使用して、属するストリームと接続するように構成および／または設定されている。

言い換えれば、本発明では、２つの異なるタイプのストリーム識別子が用いられる。これによって、参加部材もしくはアプリケーションの側で、コントロールプレーンにおいて使用されるストリーム識別子とは異なるタイプのストリーム識別子を使用することが可能になる。したがって特に、参加部材もしくはアプリケーションの側で、ＴＳＮの枠においてコントロールプレーンにおいて使用される「単に」６４ビットのサイズのストリームＩＤよりも格段に長い識別子を使用することができる。参加部材側のストリーム識別子もしくはアプリケーション側のストリーム識別子をコントロールプレーンからのもしくはコントロールプレーンに対するストリーム識別子に割り当てるために、本発明ではさらにネームサービスがアクセスされる。

ここでコントロールプレーン（ドイツ語ではＳｔｅｕｅｒｕｎｇｓｅｂｅｎｅ（コントロールレベル））は、特に、ストリーム管理が行われる、たとえば、ストリームの構築および解体が制御されるプレーンとして理解されるべきである。ストリーム利用データは、いわゆるデータプレーン（ドイツ語ではＤａｔｅｎｅｂｅｎｅ（データレベル））において搬送される。

ストリーム識別子をこのように「二分割すること」によって、アプリケーション側もしくは機器側で、より長い名前を使用できるようになる。そのサイズは、ノードに格納されるべき、コントロールプレーン用の意図的に短い識別子を（格段に）上回る。このようにして、短い識別子と接続されていることがあり、常に、占有率の綿密な比較を必要とする「管理不足」を、アプリケーションもしくは機器のレベルにおいて回避することができる。「長い」名前を、機器側もしくはアプリケーション側で意図的に選択することができる。

ここで一方のタイプのストリーム識別子の他方のタイプのストリーム識別子への割り当てに関する情報は、本発明に従って、エントリに格納される。これらのエントリは、この目的のために特別に設けられた新しいタイプを特徴とする。ＤＮＳサーバーに格納されているエントリは、ストリーム識別子の一方のタイプを別のタイプに結び付ける。

ＤＮＳサーバーに格納されたエントリは、有利にはリソースレコードであり、ここでリソースレコードは、特にＤＮＳサーバーに格納されたファイルの一部である。

本発明では、従来技術から知られているタイプ（「ｔｙｐｅ」）の代わりに、たとえば、リソースレコード（ＲＲ）に対してＲＦＣ１０３５において定義されているタイプ、たとえばタイプ「Ａ」、「ＴＸＴ」、「ＰＴＲ」、「ＮＳ」、「ＳＯＡ」、または他の規格、特に他のＲＦＣに従ったタイプの代わりに、新たなタイプが、特別に、ネームサービスの枠におけるストリーム識別子の提供のために使用される。これは、たとえばタイプ「ＴＳＮ」と称され得る。これは有利には１６ビットのタイプである。このタイプの正確な値を、標準化の枠内で、特にＩｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）もしくはＩｎｔｅｒｎｅｔ Ａｓｓｉｇｎｅｄ Ｎｕｍｂｅｒｓ Ａｕｔｈｏｒｉｔｙ（ＩＡＮＡ）によって適切に定めることができる。

ＲＦＣは、Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）グループのＲｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓの略であることに留意されたい。ＲＦＣ１０３５はたとえばＵＲＬ
ｈｔｔｐｓ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃｌ０３４５
において提示されている。

本発明による、ネームサービスエントリに対する新たなタイプの導入によって、特にＴＳＮ機器に関するＴＳＮ関連情報が、「ＤＮＳデータバジェット」において容易に、妨害されることなく呼び出され、更新され得る。

特に、同様に本出願人に帰属する、ファイル番号ＥＰ１７１８７４７３．８を有する欧州特許出願において提示されているように、第１のタイプのストリーム識別子および第２のタイプのストリーム識別子の割り当てに関する情報が、タイプ「ＴＸＴ」のリソースレコードに格納される場合に比べて、ＤＮＳにおけるＴＳＮ情報の条件付き更新が簡素化される。これは、この条件が、ＴＸＴ ＲＲに過度に非特異的に関連する代わりに、ここではＴＳＮ情報に十分に特異的に関連するためである。ＴＸＴ ＲＲは多くの異なるアプリケーションに使用され（特にＲＦＣ６７６３を参照）、ＤＮＳクエリ操作は最大でＲＲタイプをフィルタリングできるため、ＴＳＮアプリケーションはより多くの数のＴＸＴ ＲＲを応答として得ることができ、次にこれははじめに、ＴＳＮ情報を含むＴＸＴ ＲＲが存在するか否か、かつどこに存在するかに関して調べられなければならない。まさにＩＯ機器では、これに必要なリソースが不足しているか、もしくは高価なハードウェアが必要になる場合がある。

本発明によれば、ＴＳＮ情報のために特別に設けられたタイプ、特にリソースレコードタイプに基づいて、ＴＳＮ特有の情報のみが要求に応じて受け取られる。特に、「小さい」ＴＳＮ ＲＲのみが戻り、ＲＲごとに最大６４Ｋのサイズに達する可能性のある他のＴＸＴ ＲＲは戻らない。

また、本発明による手法では、ＴＳＮ特有のサブドメインは強制的に必要とはされない。

ＤＮＳ更新が成功した場合、他の情報が誤って影響を受けていたり、他のＤＮＳクライアント自体がこれらの新しいデータを誤って損傷したりしていないことが保証される。コントロールのための（繰り返される）フォローアップは不要である。

ＤＮＳ更新が失敗した場合、既に以前に格納されている第２のタイプのＴＳＮストリーム識別子を、個々の後続のＤＮＳクエリによって読み取ることができる。

さらに、本発明による手法は、アプリケーションの設定の枠において、最初に、第１のタイプの１つ以上の複数のストリーム識別子のみにアクセスし、実際に「最後の瞬間に」はじめて、第２のタイプのストリーム識別子へのリンクを、ＤＮＳサーバーを用いて確立することを可能にする。さらに、第１タイプのストリーム識別子の（プランニング）プロセスと第２タイプのストリーム識別子の（プランニング）プロセスとが、構造および時間の点で互いに分離される。このようにして、ＴＳＮコントロールプレーンにおいて使用される、第２のタイプの最終的な識別子を定める前に既に、第１のタイプの識別子を定めることができる。

これに相応に、要求メッセージは、たとえば、エンジニアリングツールからアプリケーションをＩＯ機器にダウンロードすることによって、ストリーム参加部材が参加するアプリケーションの設定が完了した後に、少なくとも１つのストリーム参加部材からはじめて送信されてよい。

少なくとも１つのストリーム参加部材からＤＮＳサーバーに送信される要求メッセージは、新たな所定のタイプを含む。これは、ネームサービスにおいて、エントリ、特にリソースレコードに対してのみ使用され、これらはそれぞれ、ストリームに割り当てられている第１のタイプのストリーム識別子と、第１のタイプのストリーム識別子とは異なる、各ストリームに割り当てられている第２のタイプのストリーム識別子とを含んでおり、すなわち、ＴＳＮ特有の、もしくはストリーム特有の情報を含んでいる。

ネームサービスは、特に、（数値の）ＩＰアドレス、たとえばＩＰｖ４またはＩＰｖ６ＩＰアドレスに、機器、計算機、サービス等の名前、特にドメイン名を割り当てるサービスとして理解される。ドメインネームシステム（ＤＮＳ）は、その主なタスクが通常、特にＩＰベースのネットワークにおいて、名前解決の要求に応答すること、すなわち、名前をアドレスに変換することであるサービスである。ＤＮＳに属する規格は、特にＲＦＣ１０３４およびＲＦＣ１０３５である。ネームサービスを提供するサーバーは、ネームサービスサーバー（英語でＮａｍｅｓｅｒｖｅｒ）とも称され、ＤＮＳの場合は、ＤＮＳサーバーとも称される。

本発明に従って使用されるＤＮＳサーバーはまた、ローカルＤＮＳサーバーであり得る。ＤＮＳサーバーが「どこから」自身のサービスを提供するかは無関係であり、提供するＤＮＳサーバーへのＩＰアクセシビリティ（ＩＰ接続）がある限り、サービスをどこにでも提供することができる。「ローカル」は、たとえば、同じサブネットワーク内であってよく、またはクラウド内の任意の場所、たとえば会社の任意の場所であってもよい。このような自由性もしくは独立性は、ネームサービス、特にＤＮＳの重要な特性である。

ストリームを介したデータの伝送は、ＴＳＮネットワークにおいて行われる。ここでＴＳＮネットワークは、Ｔｉｍｅ Ｓｅｎｓｉｔｉｖｅ Ｎｅｔｗｏｒｋｉｎｇ（ＴＳＮ）と称される１つ以上の規格を満たし、特に、スイッチおよび／またはブリッジ等の１つ以上のＴＳＮ対応ノードを含むネットワークとして理解される。ＴＳＮ規格には、たとえば、時刻同期（ＩＥＥＥ ８０２．１ＡＳ−Ｒｅｖ）、フレーム・プリエンプション（ＩＥＥＥ ８０２．１Ｑｂｕ）および予約（ＩＥＥＥ ８０２．１Ｑｃａ、ＩＥＥＥ ８０２．１Ｑｃｃ）ならびにその他の規格が含まれる。

有利にはこれは、特に産業用自動化設備の産業用ネットワークである。

少なくとも１つのストリーム参加部材が、第２のタイプのストリーム識別子を用いてストリームに登録したことに続いて、ストリームを介してデータを送信することができる。

ストリームに対して設定された予約に関する限り、基本的に、従来技術から知られている種々の手法が利用可能である。たとえば、ＩＥＥＥ ８０２．１Ｑｃｃは、これに対する少なくとも３つのアプローチを記載しており、具体的には、たとえばＰＲＯＦＩＮＥＴ ＩＲＴで使用される、いわゆる「完全分散型モデル」、「完全集中型モデル」およびハイブリッドモデル「集中型ネットワーク、分散型ユーザー」を記載している。

予約の経過はとりわけ、特にＩＥＥＥ ８０２．１Ｑｃｃに従った各予約プロトコルに依存する。使用できる予約プロトコルの例として、ＭＳＲＰが挙げられる。

当然、２つ以上のストリーム参加部材がＤＮＳサーバーに要求メッセージを送信してよく、この場合には、各ストリーム参加部材の要求メッセージは、少なくとも、各ストリーム参加部材に既知の、第１のタイプのストリーム識別子と、所定のタイプとを含んでいる。さらに各ストリーム参加部材が、ストリームに属する、第２のタイプのストリーム識別子を含んでいる応答メッセージをＤＮＳサーバーから受け取ってよく、各ストリーム参加部材が受け取ったストリーム識別子を使用してストリームに登録してよい。各要求メッセージと共に送信される、ストリーム参加部材に既知の、第１のタイプのストリーム識別子は、すべてのストリーム参加部材に対して同じであってよい。第１のタイプの異なるストリーム識別子がストリームに対して存在する可能性もある。

通常、コントロールプレーン内のストリームに対しては、常に厳密に１つのストリーム識別子のみが存在する、もしくは使用されるため、ＤＮＳサーバー上に、第２のタイプの厳密に１つのストリーム識別子に対して、第１のタイプの異なるストリーム識別子を有する複数のエントリが存在可能である。

さらに、本発明による方法を実施して、ネットワーク内に１つのストリームのみを設定することができる、または複数のストリームも設定することができる。

ストリーム参加部材は、たとえば、（端末）機器の形態で存在していてよい。ストリーム参加部材は、アプリケーションによって、もしくは特に、分散型アプリケーションの場合にはアプリケーション部分によって提供されてもよい。

２つ以上のストリーム参加部材が、たとえばＰＬＣ等の制御部およびストリームを介して測定データをＰＬＣに伝達する自動化設備の１つ以上のセンサーによって提供されていてよい。ストリームを介してＰＬＣに送信するセンサーが複数ある場合、複数のトーカーと厳密に１つのリスナーとがいるシナリオが提供されている。たとえば、制御値等のデータを制御部、特にＰＬＣから１つ以上のアクチュエーターに送信する場合、厳密に１つのトーカーと１つ以上のリスナーとがいるシナリオが与えられるだろう。

ストリーム参加部材は、分散型アプリケーションの参加部材もしくは一部であってよい。センサー／アクチュエーターおよびＰＬＣは、たとえば、分散型ＴＳＮアプリケーション「制御部」の一部を形成してよい。

２つ以上のストリーム参加部材がネットワーク内の異なる（端末）機器であってよいが、これらが１つの（端末）機器上に位置していることも可能であるということに留意されたい。たとえば、ストリームに参加することを望む２つ以上のアプリケーションもしくはアプリケーションの一部を、ブリッジ、場合によっては純粋にソフトウェアで実装されたブリッジ、もしくはブリッジ機能を含んでいる機器上で実行することができる。これは、特に仮想化の分野の場合であり得る。純粋に例として、計算機上の仮想ＣＰＵおよびヒューマンインターフェイス（ＨＭＩ）が挙げられる。

第１のタイプのストリーム識別子は、有利には、ストリームを識別するために少なくとも１つのストリーム参加部材によって使用されるストリーム名、有利には、ストリームに割り当てられているドメイン名、特にＲＦＣ１０３４に従った、ストリームに割り当てられている所有者名である。

第１のタイプのストリーム識別子は、特にＲＦＣ７７１９の意味において、完全修飾ドメイン名（ＦＱＤＮ）であってよい。

さらに第１のタイプのストリーム識別子は有利には、ユーザーによって使用されるものである。

第２のタイプのストリーム識別子を照会するために、要求メッセージと共に少なくとも１つのストリーム参加部材からＤＮＳサーバーに伝達される第１のタイプのストリーム識別子は、少なくとも１つのストリーム参加部材に知られている。たとえば中央箇所による割り当てによって、任意の様式で、これが少なくとも１つのストリーム参加部材に知らせられてよい、もしくは知らせられていてよい。第１のタイプのストリーム識別子が、ストリーム参加部材によって生成されていてもよい。単なる例として、この関連において、同様に本出願人に帰属する、ファイル番号ＥＰ１７１８７４７３．８の出願を参照されたい。これは対応する方法を開示している。

第２のタイプのストリーム識別子は、特にＴＳＮアプリケーションレベル（「ＴＳＮ Ａｐｐｌｉｃａｔｉｏｎ Ｐｌａｎｅ」）において使用されるものである。

第２のタイプのストリーム識別子は、ネットワークによって、特に、有利にはＩＥＥＥ ８０２．１Ｑａｔに従って、ストリームを識別するためにネットワークの（ＴＳＮ）コントロールプレーン、すなわちコントロールレベルにおいて使用されるストリームＩＤであってよい。

第２のタイプのストリーム識別子もまた、有利には６４ビットのサイズである。これによって、ネットワークのブリッジおよび／またはスイッチ等のノードにおけるメモリバジェットに不必要に負荷がかからないようになる、もしくは過負荷がかからないようになる。

ネットワークが１つ以上のノード、特にブリッジおよび／またはスイッチを含み、第２のタイプのストリーム識別子がネットワークの１つ以上のノードに格納されてよい。

ビットで示される、第１のタイプのストリーム識別子のサイズは、有利には、ビットで示される、第２のタイプのストリーム識別子のサイズを上回る。第１のタイプの「長い」もしくは比較的長いストリーム識別子を選択することによって、アプリケーションレベル上での管理不足を確実に回避することができる。

別の実施形態は、要求メッセージがＤＮＳクエリの形式で送信されることを特徴とする。択一的または付加的に、応答メッセージがＤＮＳクエリの形式で送信されてよい。

本発明による機器は、有利な構成において、これに相応に構成および／または設定されている。

エントリを、第２のタイプのストリーム識別子への第１のタイプのストリーム識別子の割り当てを伴って、たとえばＤＮＳ更新を介して、ＤＮＳサーバー上に格納する種々の手法がある。

たとえば、１つ以上のストリームに対する両方のタイプの識別子を知っている機器もしくはアプリケーションから、情報が分散方式でネームサービスサーバーに伝達されてよい。

したがって、本発明による方法のさらなる実施形態は、特に、少なくとも１つのストリーム参加部材から、要求メッセージが、ＤＮＳサーバーに送信される前に、少なくとも１つの、特にストリームのイニシエーターである別のストリーム参加部材から、少なくとも１つの更新メッセージが、ＤＮＳサーバーに送信されるという特徴を有している。ここでこの更新メッセージは、ストリームに対する第１のタイプの少なくとも１つのストリーム識別子と、第２のタイプの少なくとも１つのストリーム識別子と、所定のタイプの表示とを含んでいる、ネームサービスサーバー用のエントリを含んでいる。

本発明による機器は、ストリームに対する第１のタイプの少なくとも１つのストリーム識別子と、第２のタイプの少なくとも１つのストリーム識別子と、所定のタイプの表示とを含んでいる、ＤＮＳサーバー用のエントリを含んでいる更新メッセージを、特に、ＤＮＳ更新の形式で、有利にはＲＦＣ２１６３に従ってＤＮＳサーバーに送信するように相応に構成および／または設定されていてよい。

更新メッセージからの第１のタイプのストリーム識別子は、有利には、ＲＦＣ７７１９に従って正規名で与えられている。

択一的または付加的に、情報が中央箇所から到来してもよい。

これに相応に、択一的または付加的に、特に、少なくとも１つのストリーム参加部材によって要求メッセージがＤＮＳサーバーに送信される前に、中央箇所(zentralen Stelle)から、少なくとも１つの更新メッセージが、ＤＮＳサーバーに送信されてよく、ここでこの更新メッセージは、ストリームに対する第１のタイプの少なくとも１つのストリーム識別子と、第２のタイプの少なくとも１つのストリーム識別子と、所定のタイプの表示とを含んでいる、ＤＮＳサーバー用のエントリを含んでいる。

更新メッセージからのエントリは、２つのタイプのストリーム識別子と所定のタイプの表示との他に、有利にはクラスおよび／またはＴＴＬ表示および／または有利には６４ビットのサイズのＲＤＡＴＡ領域を含んでいる。

更新メッセージからのエントリは、さらに、有利には、第１のタイプのストリーム識別子がそれぞれ先頭にあり、その後にタイプ、クラス、ＴＴＬ表示およびＲＤＡＴＡ領域が続くように構築されている。

第２のタイプのストリーム識別子は、別の有利な構成では、エントリのＲＤＡＴＡ領域において表示され、ここで特に、第２のタイプのストリーム識別子が最上位オクテットと共に最初に指定され、最上位ビットがビット０としてカウントされる。これは、いわゆるネットワーク順序に対応する。最上位ビットを０としてカウントすることは、ＩＥＴＦ規則に従っている。

更新メッセージは、特に有利には、特にＲＦＣ２１６３に従って、ＤＮＳ更新の形式でＤＮＳサーバーに送信される。

本発明の対象は、さらに、ストリーム識別子情報を提供するための方法であり、ここでは、少なくとも１つのストリーム識別子ファイルがＤＮＳサーバー上に提供され、ここでこのストリーム識別子ファイルはエントリを含んでおり、このエントリはそれぞれ、ストリームに割り当てられている第１のタイプのストリーム識別子と、第１のタイプのストリーム識別子とは異なる、各ストリームに割り当てられている第２のタイプのストリーム識別子と、このようなタイプのエントリに対してのみ使用されている、もしくは使用される、所定のタイプの表示とを含んでいる。

エントリはＤＮＳサーバー上に提供されており、もしくは提供され、それぞれ、ストリームに割り当てられている第１のタイプのストリーム識別子と、第１のタイプのストリーム識別子とは異なる、各ストリームに割り当てられている第２のタイプのストリーム識別子とを結び付け、かつこのようなタイプのエントリに対してのみ使用されている、もしくは使用される所定のタイプの表示を含んでおり、このエントリは有利には、ここでは更新メッセージからのエントリに対して表示されている同じ構造によって特徴付けられ、すなわち有利には、付加的に、クラスおよび／またはＴＴＬ表示および／または有利には６４ビットのサイズのＲＤＡＴＡ領域を含んでおり、有利には、第１のタイプのストリーム識別子がそれぞれ先頭にあり、その後にタイプ、クラス、ＴＴＬ表示およびＲＤＡＴＡ領域が続くように構成されており、ここで特に、第２のタイプのストリーム識別子は、有利には、いわゆるネットワーク順序に従って表示されている。

本発明はさらに、ストリーム識別子ファイルを提供するためのＤＮＳサーバーの使用に関する。ここでストリーム識別子ファイルはエントリを含んでおり、エントリはそれぞれ、ストリームに割り当てられている第１のタイプのストリーム識別子と、第１のタイプのストリーム識別子とは異なる、各ストリームに割り当てられている第２のタイプのストリーム識別子と、このようなタイプのエントリに対してのみ使用されている、もしくは使用される所定のタイプの表示とを含んでいる。

ストリーム識別子ファイルからのエントリは、上記のように、中央箇所から伝達されても、もしくは伝達されていてもよく、分散されて、たとえばストリーム参加部材によって、伝達されても、もしくは伝達されていてもよく、ここでこれは有利には更新の形式で、特にＤＮＳ更新の形式で行われる、もしくは行われている。

本発明は、ストリームを設定するための本発明による方法もしくはストリーム識別子情報を提供するための本発明による方法のステップを実行するためのプログラムコード手段を含んでいるコンピュータープログラムにも関する。

最後に、本発明の対象は、命令を含んでいるコンピューター可読媒体であり、この命令は、それらが少なくとも１つのコンピューター上で実行されると、少なくとも１つのコンピューターに、ストリームを設定するための本発明による方法もしくはストリーム識別子情報を提供するための本発明による方法のステップを実行させる。

コンピューター可読媒体は、たとえば、ＣＤ−ＲＯＭまたはＤＶＤまたはＵＳＢまたはフラッシュメモリであってよい。コンピューター可読媒体は、物理媒体として排他的に理解されるべきではなく、むしろ、そのような媒体は、たとえば、データストリームおよび／またはデータストリームを表す信号の形式でも存在し得ることに留意されたい。

本発明の実施形態の以下の説明に基づいて、添付の図面を参照して、本発明のさらなる特徴および利点を明確にする。

自動化設備の産業用ネットワークにおける２つの端末機器の純粋に概略的な図を示している。これらはＤＮＳサーバーからストリーム識別子情報を得る。 ネームサービスサーバーへのストリーム識別子情報の伝達の純粋に概略的な図を示している。 図１の端末機器を示しており、ここで端末機器によって、ＤＮＳサーバーに対してＤＮＳ更新が実行される。

図１は、産業用ネットワーク、具体的には、図には詳細に示されていない自動化設備の産業用ネットワークの純粋に概略的な部分図を示している。

ネットワークは、大幅に簡略化された図１には示されていない、ＴＳＮ対応スイッチの形式の複数のネットワークノードを介して接続されている多数の参加部材を含んでいる。多数のネットワーク参加部材のうち、純粋に例として、２つの参加部材１、２のみが図１に示されている。図１の左側の参加部材は、ここでは、自動化設備のプログラマブルロジックコントローラ（ＰＬＣ）１によって与えられる端末機器１である。別の参加部材は、示されていないアクチュエーターを含んでいる、もしくはそのようなアクチュエーターと接続されている、自動化設備のＩＯ機器２によって与えられている。

自動化設備の動作中、制御値がＰＬＣ１からＩＯ機器２に、十分に知られている方法で周期的に伝達され、アクチュエーターはこの制御値に従って、詳細に示されていない技術プロセスに周期的に作用する。

ここでＰＬＣ１とＩＯ機器２との間のデータ伝送は、リアルタイムで行われなければならない。具体的には、ＰＬＣ１から発信されるデータがそれぞれ、所定の時間後に、損失なくＩＯ機器２に到着することが保証されていなければならない。これは、２つの参加部材１、２の間にＴＳＮストリーム、すなわち保護された通信接続を設定することによって可能になる。

データを送信するＰＬＣ１はトーカー（送信側）であり、ＩＯ機器２はリスナー（受信側）である。

ＰＬＣ１とＩＯ機器２との間での、保証されたサービス品質（ＱｏＳ）でのリアルタイムのデータ交換を必要とする制御プロセスを、アプリケーションの一部がＰＬＣ１上で実行され、一部がＩＯ機器２上で実行される分散型ＴＳＮアプリケーションと見なすこともできる。図１では、ＴＳＮアプリケーションの２つの部分「制御部」は、参照番号３もしくは４が付けられているブロック図要素によって示されている。

Ｔｉｍｅ Ｓｅｎｓｉｔｉｖｅ Ｎｅｔｗｏｒｋｓ（ＴＳＮ）に対して、より正確には「ＴＳＮコントロールプレーン」（コントロールレベル）に対して、アプリケーションは、属するストリーム識別子、特にいわゆるストリームＩＤを介して個々のストリームを識別する。ＴＳＮの観点から、これらは、内部構造のない６４ビットストリングである。

２つ以上のストリーム参加部材１、２が、同じストリームＩＤを有する共通のストリームと接続できるように、参加部材１、２は、ストリームに属する、コントロールプレーンに対する識別子、つまりストリームＩＤを知っていなければならない。

ＴＳＮアーキテクチャでは、ストリーム識別用のストリームＩＤは、６４ビットのみを有する、比較的短いものになるように意図的に選択されている。これは、技術的な理由から、ネットワーク内に設定されたすべてのストリームのすべてのストリームＩＤがそれぞれ、関与するすべてのノード、たとえばスイッチにおいて知られている必要があるということに起因する。比較的長いストリームＩＤが用いられる場合、ノードにおけるメモリバジェットをすぐに使い果たすだろう、もしくはこれを超えてしまうだろう。

長さが短いため、ストリームＩＤはこれまで「管理不足」の対象となっており、これによって常に占有率を綿密に比較する必要が生じる。Ｅｘｃｅｌテーブルを作成することによって、ストリームＩＤを手動で管理することでこれを阻止することができる。しかし、これには相当な手間が伴う。特に、ストリームＩＤを新たに全体的に計画する必要なく、「プラグアンドプレイ」だけで、新しいＴＳＮアプリケーション３、４をネットワークに追加できるようにするには、自動管理も望まれるだろう。

この場合、これは、本発明による、ストリームを設定するための方法の実施形態によって可能になる。

具体的には、２つの異なるタイプのストリーム識別子がストリームを識別するために使用され、すなわち、第１のタイプのストリーム識別子が使用され、これはこの場合、２つのストリーム参加部材１、２によって、ストリームを識別するために使用されるストリーム名、具体的にはストリームに割り当てられている、ＲＦＣ１０３４に準拠した所有者名であり、これは、たとえば、最大２０４０ビットのサイズで特徴付けられていてよい。ストリーム所有者名は、２つのストリーム参加部材１、２のそれぞれに知られている。図１では、参加部材１、２に知られているストリーム所有者名は、参照番号５が設けられているブロック要素によって純粋に概略的に示されている。

さらに、第２のタイプのストリーム識別子が使用される。これは、ストリームを識別するためにＴＳＮネットワークのコントロールプレーンにおいて使用される、ＩＥＥＥ ８０２．１Ｑａｔに準拠した６４ビットの長さのストリームＩＤである。

アプリケーションレベルおよびコントロールレベルでの識別子の二分割は、一方では、コントロールプレーン側で、関与しているすべてのノードに格納される比較的短い長さのストリーム識別子を引き続き使用でき、したがってメモリバジェットを超えないことが保証されるという大きな利点を提供する。すなわち、ＴＳＮのコントロールプレーンは引き続き、短い、ひいてはメモリ最適化されたストリームＩＤで機能し、これらはＴＳＮによって自動的に、関与しているすべてのＴＳＮスイッチにおいて複製される。

他方で、アプリケーション側、すなわちＴＳＮアプリケーションプレーン（アプリケーションレベル）においては、長いストリーム名が使用される。これらは個々の機器１、２にのみ格納され、関与するすべてのノードに格納されるのではない。したがって、機器１、２では、より少ないが、その代わりより長い識別子を扱うために必要なメモリスペースが使用可能である。これによって、ネーム空間を意図的に「まばらに占有」するだけで、衝突をスマートに回避することができる。この原理は、たとえばドメインネームシステム（ＤＮＳ）から既知である（特にＲＦＣ１０３４および１０３５を参照）。

比較的長い、アプリケーション側の、第１のタイプのストリーム識別子および比較的短い、ＴＳＮ側の、第２のタイプのストリーム識別子の割り当てに対して、本発明では、ネームサービスサーバー６がアクセスされる。ここに記載する実施例の枠では、これは、簡素なブロック要素によって純粋に概略的に図１に示されているＤＮＳサーバー６である。

ＤＮＳサーバー６を用いて、割り当てが可能になるように、従来のネームサービスに必要な情報に加えて、ストリーム識別子情報がこれに格納されている。付加的にＤＮＳサーバー６で利用可能なストリーム識別子情報は、図１において、ＤＮＳサーバー６上の、参照番号７が付けられている要素によって示されている。

ここに記載する実施例では、具体的に、付加的な情報を含んでいるストリーム識別子ファイルがＤＮＳサーバー６にファイルされている。これは、たとえば、特にＲＦＣ１０３４および１０３５に従ったゾーンファイルの形式で、またはそれに基づいて作成されたファイルの形式で得られていてよい、または別のフォーマットを有していてもよい。

ストリーム識別子ファイルは、リソースレコード（ＲＲ）の形式のエントリを含んでおり、これらのエントリはそれぞれ、ストリームに割り当てられている第１のタイプのストリーム識別子（この場合はストリーム所有者名）と、第１のタイプのストリーム識別子とは異なる、各ストリームに割り当てられている第２のタイプのストリーム識別子（この場合はＴＳＮコントロールプレーンにおいて使用されるストリームＩＤ）とを結び付け、さらにそれぞれネームサービスサーバー６でこのようなタイプのエントリに対してのみ使用されている、もしくは使用される、所定のタイプ「ＴＮＳ」の表示を含んでいる。

新しいタイプ「ＴＳＮ」のリソースレコード（ＲＲ）はここで、次のように構築されている。
１．所有者：ドメイン名、ＲＦＣ１０３４を参照。
２．タイプ（１６ビット）：「ＴＳＮ」−正確な値は、適切に、ＩＥＴＦによる標準化の過程でＩＡＮＡによって割り当てられる。
３．クラス（１６ビット）：「ＩＮ」、ＲＦＣ１０３４を参照。
４．ＴＴＬ（３２ビット）：ＲＦＣ１０３４において規定されている。
５．ＲＤＡＴＡ：いわゆるネットワーク順序における６４ビットＴＳＮストリームＩＤ（ストリーム識別子）。すなわち最上位オクテットが最初になり、ここでＩＥＴＦ規則に従って、最上位ビットがビット０（！）としてカウントされる。

従来技術から既知のリソースレコード（ＲＲ）に対する新しいフィールドは、このリストにおいて太字で強調されていることに留意されたい。たとえば、既知のリソースレコードはＲＦＣ１０２５から生じる。

このような形式のリソースレコードに対する例は
ｒｏｃｋｅｔ−ｌａｕｎｃｈｅｒ．ｃｏｙｏｔｅ．ａｃｍｅ．ｃｏｒｐ． ＴＳＮ ＩＮ ｄｅａｄｂｅｅｆｃａｆｅｂａｂｅ
であり、これは、単に例示的に選択された、完全修飾ドメイン名（ＦＱＤＭ）の形式でのストリーム所有者名「ｒｏｃｋｅｔ−ｌａｕｎｃｈｅｒ．ｃｏｙｏｔｅ．ａｃｍｅ．ｃｏｒｐ．」と、同様に純粋に例示的に、「ｄｅａｄｂｅｅｆｃａｆｅｂａｂｅ」として選択された、リソースレコードのＲＤＡＴＡ領域における１６進表記の６４ビットストリームＩＤとを伴う。

上記の例では、ＴＴＬ（「Ｔｉｍｅ ｔｏ Ｌｉｖｅ」）に対する値が挙げられていないことに留意されたい。これは、たとえば６００であってよく、これは１０分のＴＴＬに対応する。またはこれとは異なっていてもよい。このような値はＤＮＳキャッシングにとってのみ重要であり、ＴＳＮにとっては重要ではない。

ストリーム識別子情報がＤＮＳにおいてどのように提供されたかについて、以下でさらに詳しく言及する。

ストリームに属するストリームＩＤを知るために、ＰＬＣ１とＩＯ機器２との両方が、ＤＮＳサーバー６へ要求メッセージ８を送る。これは、具体的にＤＮＳクエリの形式で行われる。図１では、要求メッセージもしくはＤＮＳクエリは、ＤＮＳサーバー６を指す矢印の隣に、参照番号８が付けられたブロック図要素として示されている。

要求メッセージ８はそれぞれ、ストリーム所有者名５の形式の、ＰＬＣ１もしくはＩＯ機器２に知られている第１のタイプのストリーム識別子と、所定のタイプ「ＴＮＳ」とを含んでいる。

例として上で挙げられたストリーム名の場合、要求は、
ＤＮＳ ＱＵＥＲＹ：
ｒｏｃｋｅｔ−ｌａｕｎｃｈｅｒ．ｃｏｙｏｔｅ．ａｃｍｅ．ｃｏｒｐ． ＴＳＮ ＩＮ
となるだろう。

ここでは、ＰＬＣ１およびＩＯ機器２は、第１のタイプのストリーム識別子と同じストリーム所有者名５を知っているということに留意されたい。しかしこれは必須ではない。むしろ、さまざまな参加部材が、ストリームに対する第１のタイプのさまざまなストリーム識別子を知っていてもよい。次に、第２のタイプのストリーム識別子としてのストリームＩＤに対して複数のリソースレコードが存在し、具体的には第１のタイプの各ストリーム識別子に対して１つのＲＲである。

ＤＮＳクエリに応答して、ＰＬＣ１とＩＯ機器との両方がそれぞれＤＮＳサーバー６から応答メッセージを受け取る。これはここで同様に、ＤＮＳクエリの形式である。応答メッセージは、図１において、ＤＮＳサーバー６からＰＬＣ１もしくはＩＯ機器２を指す矢印の隣に、参照番号９が付けられた要素によって示されている。

ここに記載した実施例の枠では、ＰＬＣ１およびＩＯ機器２はそれぞれストリームＩＤモジュール１０を含んでおり、これは、要求メッセージ８の送信、応答メッセージ９の受け取り、すなわちＤＮＳクエリを処理するように構成されている。このために、ストリームＩＤモジュール１０は、相応に構成および／または設定されている。ストリームＩＤモジュール１０は、たとえば、純粋にソフトウェアで実装されていてよく、その場合、ソフトウェアを、特に、機器１、２のいずれにせよ設けられている一般的なハードウェア上で実行することができる、またはソフトウェアは純粋にハードウェアで実装されていてもよく、特に、特別にモジュール１０のために設けられたハードウェアによって実装されていてもよく、またはソフトウェアと、特に、特別にモジュール１０のために設けられたハードウェアとの組み合わせも含んでいてよい。

ＤＮＳサーバー６から受け取った応答メッセージ９は、ストリームに属するストリームＩＤを含んでいる。これは、ストリームＩＤモジュール１０によって応答メッセージ９から取得され、これに続いて、ＰＬＣ１およびＩＯ機器２は、属するストリームＩＤによってストリームに登録し、このストリームを介してＰＬＣ１からＩＯ機器２へデータをリアルタイムで伝送することができる。ストリームへの登録を、それに応じて構成および／または設定されているストリームＩＤモジュール１０によって処理することもできる。

たとえば、関与しているノードでのリソースの予約およびその後のデータパケットの伝送もしくは転送を、従来技術から十分に知られているのと同じように実行することができるということに留意されたい。そのため、このような態様は詳細には議論されない。

ここでは、ストリーム識別子情報が、標準化されたゾーンファイルの形式で、特にＲＦＣ１０３４およびＲＦＣ１０３５に従って、エンジニアリングツールから伝送されている。このエンジニアリングツールによって、図１に示された機器１、２が参加するネットワークが構築された。ゾーンファイルはここで中央のエンジニアリングツールによって提供されており、次にＤＮＳサーバー６からインポートされる。

これは、純粋に概略的に図２に示されている。ここでは、ゾーンファイルには参照番号１１が付けられており、ここからＤＮＳサーバー６を指す矢印を介してインポートが示されている。

たとえば、ＤＮＳデータを、特にＲＦＣ２１３６「ドメインネームシステムのダイナミック更新（ＤＮＳ ＵＰＤＡＴＥ）」に従って、ＤＮＳ更新操作を使用して直接的に転送することもできる。

エンジニアリングツールを用いることに対して択一的にまたは付加的に、ストリーム識別子情報を含むファイルが、中央のオンラインツールによって提供されてもよく、これに続いて、特に、ＲＦＣ２１３６に準拠したＤＮＳ更新操作によって、ネームサービスサーバー６に伝送されてよい。

図２では、オンラインツールが、参照番号１２が付けられているブロック要素として概略的に示されており、ここからＤＮＳサーバー６を指す矢印によって、ＤＮＳ更新が示されている。

ストリーム識別子情報が中央箇所からＤＮＳサーバー６に伝達されるのに対して択一的に、この情報が分散して、ストリーム参加部材を表すネットワーク参加部材から、同様に、ＤＮＳ更新を介してサーバー６に伝達されていてもよく、もしくは継続的に伝達されてもよい。たとえば、少なくとも各ストリームイニシエーター、すなわち、ネットワーク内でストリームをアナウンスもしくは開始する参加部材に、ストリームに属する識別子が、この様式において、ＤＮＳサーバー６を介してではなく、他の様式で知らされてよい、もしくは知らされていてよい。

次に、ストリームイニシエーターは、ネームサービスサーバーに対するエントリを含んでいる少なくとも１つの更新メッセージをネームサービスサーバーに伝達することができる。ここでこのエントリは、少なくとも１つの第２のタイプのストリーム識別子、特にストリームＩＤおよび１つ以上の第１のタイプのストリーム識別子、特にドメイン名もしくは所有者名を含んでいる。

これは、特にＤＮＳ更新を介して、たとえばＲＦＣ２１３６に従って行われ得る。各ストリームイニシエーターがこのようにしてデータをネームサービスサーバーに伝達すると、他の参加部材はこれらを呼び出すことができる。

ストリームイニシエーターによるＤＮＳ更新のプロセスは、図３に純粋に概略的に示されている。ここでは、同じコンポーネントもしくは同じ要素に同じ参照番号が付けられている。

ストリームイニシエーターを表すＰＬＣ１によって実行されるＤＮＳ更新は、ＰＬＣ１からＤＮＳサーバー６を指す矢印の隣に、参照番号１３が付けられたブロック要素によって表されている。ネームサービスにおけるＴＳＮ情報もしくはストリーム情報の（分散型）提供のためのＤＮＳ更新は、ここで、それに応じて構成および／または設定されている、ＰＬＣ１のストリームＩＤモジュール１０によって処理される。ＰＬＣ１は既にストリームＩＤを知っているので、図１によるシナリオのように、自身の側で、それを照会するためのＤＮＳクエリをもはや必要としない。

しかし、ＤＮＳクエリはＩＯ機器２によって、正確に図１のシナリオと同じように実行される。ここで、上記の記載を参照されたい。

ストリームは原則的にトーカーとリスナーとの両方によって開始することが可能であるということに留意されたい。すなわち、ストリームイニシエーターはトーカーまたはリスナーによって与えられていてよい。厳密に１つのトーカーからデータを受信する複数のリスナー、または厳密に１つのリスナーにデータを送信する複数のトーカーがいる状況では、それぞれ「個々の」参加部材、すなわち複数のリスナーを有するこの１つのトーカー、または複数のトーカーが与えられているこの１つのリスナーが、ストリームのイニシエーターになるだろう。

ストリーム識別子に関する情報がＤＮＳサーバー６においてどのように提供されたかに関係なく、この目的のために特別に導入された新しいタイプのエントリ、特にリソースレコードを使用することに基づいて、特に、ストリーム識別子情報がＴＸＴタイプのリソースレコードに格納されていることと比較して、特別に容易な更新が可能になるということが当てはまる。

ＴＳＮ情報の条件付き更新は、条件がＴＸＴ ＲＲに過度に非特異的に関連するのではなく、ＴＳＮ情報に十分に特異的に関連するので簡素化される。さらに、ＴＳＮ特有のサブドメインは必ずしも必要ではない。

更新はたとえば次のようになる。
ＤＮＳ ＵＰＤＡＴＥ：
ＺＯＮＥ：
ｃｏｙｏｔｅ．ａｃｍｅ．ｃｏｒｐ． ＳＯＡ ＩＮ
ＰＲＥＲＥＱＵＩＳＩＴＥＳ： −−
（空のＲＤＡＴＡ領域は、ＴＳＮに対するＲＲｓｅｔがまだ存在してはならない、もしくは存在すべきではないことを示している。）
ｒｏｃｋｅｔ−ｌａｕｎｃｈｅｒ．ｃｏｙｏｔｅ．ａｃｍｅ．ｃｏｒｐ． ＴＳＮ ＩＮ （ｅｍｐｔｙ）
ＵＰＤＡＴＥＳ：
ｒｏｃｋｅｔ−ｌａｕｎｃｈｅｒ．ｃｏｙｏｔｅ．ａｃｍｅ．ｃｏｒｐ． ＴＳＮ ＩＮ ｄｅａｄｂｅｅｆｃａｆｅｂａｂｅ
ＡＤＤＩＴＩＯＮＡＬＳ：
−−

更新メッセージからのエントリは、これに相応に、２つのタイプのストリーム識別子および所定のタイプの表示の他に、クラスおよび／またはＴＴＬ表示および／または有利には６４ビットのサイズのＲＤＡＴＡ領域を含むことができる。これは、たとえば、第１のタイプのストリーム識別子がそれぞれ先頭にあり、その後にタイプ、クラス、ＴＴＬ表示およびストリームＩＤを有するＲＤＡＴＡ領域が続くように構築されていてよい。これに対する例は、「ｒｏｃｋｅｔ−ｌａｕｎｃｈｅｒ．ｃｏｙｏｔｅ．ａｃｍｅ．ｃｏｒｐ． ＴＳＮ ＩＮ ｄｅａｄｂｅｅｆｃａｆｅｂａｂｅ」によって与えられている。

ＤＮＳ更新が成功した場合、他の情報が誤って影響を受けていたり、他のＤＮＳクライアントが自身の側でこの新しいデータを誤って損傷させたりしていないことが保証される。コントロールするための（繰り返される）フォローアップは不要である。

ＤＮＳ更新が失敗した場合、個々の後続するＤＮＳクエリによって、以前に格納されたＴＳＮストリームＩＤを読み取り、迅速に利用することができる。
ＤＮＳ ＱＵＥＲＹ：
ｒｏｃｋｅｔ−ｌａｕｎｃｈｅｒ．ｃｏｙｏｔｅ．ａｃｍｅ．ｃｏｒｐ． ＴＳＮ ＩＮ

１つまたは複数の応答ＴＳＮ ＲＲは、捜索されたストリームＩＤを含んでいる。

本発明の手法はさらに次のことを可能にする。すなわち、アプリケーションの設定の枠において、最初に、第１のタイプの１つ以上のストリーム識別子のみにアクセスし、実際に「最後の瞬間に」はじめて、ネームサービスサーバーを用いて、第２のタイプのストリーム識別子へのリンクが確立されることを可能にする。さらに第１のタイプのストリーム識別子の（プランニング）プロセスと第２のタイプのストリーム識別子の（プランニング）プロセスとが、構成および時間の点で互いに分離される。このようにして、ＴＳＮコントロールプレーンにおいて使用される、第２のタイプの最終的な識別子が定められる前に既に、第１のタイプの識別子を定めることができる。

本発明の細部を、有利な実施例によってより詳細に例示および説明したが、本発明は、開示されたこれらの例によって制限されず、ここから、他の変形が、本発明の保護範囲から逸脱することなく当業者によって導出され得る。

たとえば、図１および図３に、純粋に例として２つのストリーム参加部材だけが示されていても、当然、任意の数のさらなるストリーム参加部材が、これらがＤＮＳサーバー６を用いてストリームＩＤを照会した後、ストリームに登録することができる。

当然、ネットワークにおいて、１つよりも多くのストリームが、本発明の方法を実施して、設定されてもよい。

Claims (21)

1. ＴＳＮネットワークにおいてストリームを設定するための方法であって、
   前記ストリームを介して少なくとも１つの別のストリーム参加部材（１，２）にデータを送信することを望む、かつ／または少なくとも１つの別のストリーム参加部材（１，２）から前記ストリームを介してデータを受信することを望む少なくとも１つのストリーム参加部材（１，２）から、エントリが格納されているＤＮＳサーバー（６）へ要求メッセージ（８）を送信し、前記要求メッセージはそれぞれ、ストリームに割り当てられている第１のタイプのストリーム識別子と、前記第１のタイプのストリーム識別子とは異なる、各前記ストリームに割り当てられている第２のタイプのストリーム識別子と、前記タイプのエントリに対してのみ使用されている、もしくは使用される、所定のタイプの表示とを含んでおり、前記要求メッセージ（８）は少なくとも１つの、前記少なくとも１つのストリーム参加部材（１，２）に既知の前記第１のタイプのストリーム識別子と、前記所定のタイプとを含んでおり、
   前記少なくとも１つのストリーム参加部材（１，２）は前記ＤＮＳサーバー（６）から応答メッセージ（９）を受け取り、前記応答メッセージは、前記ストリームに属する前記第２のタイプのストリーム識別子を含んでおり、かつ
   前記少なくとも１つのストリーム参加部材（１，２）は、受け取った前記ストリーム識別子を使用して前記ストリームに登録する、
   方法。
2. 前記第１のタイプのストリーム識別子は、前記ストリームを識別するために前記少なくとも１つのストリーム参加部材（１，２）によって使用されるストリーム名であり、かつ／または前記第２のタイプのストリーム識別子は、前記ストリームを識別するために前記ネットワークによって使用されるストリームＩＤである、請求項１記載の方法。
3. ビットで示される、前記第１のタイプのストリーム識別子のサイズは、ビットで示される、前記第２のタイプのストリーム識別子のサイズを上回る、請求項１または２記載の方法。
4. 前記要求メッセージ（８）をＤＮＳクエリの形式で送信し、かつ／または前記応答メッセージ（９）をＤＮＳクエリの形式で送信する、請求項１から３までのいずれか１項記載の方法。
5. 前記ＤＮＳサーバー（６）に格納された前記エントリは、前記所定のタイプによって特徴付けられたリソースレコードである、請求項１から４までのいずれか１項記載の方法。
6. 少なくとも１つの別のストリーム参加部材（１，２）から、少なくとも１つの更新メッセージ（１３）を前記ＤＮＳサーバー（６）に送信し、前記更新メッセージは、前記ストリームに対する前記第１のタイプの少なくとも１つのストリーム識別子と、前記第２のタイプの少なくとも１つのストリーム識別子と、前記所定のタイプの表示とを含んでいる、前記ＤＮＳサーバー（６）用のエントリを含んでいる、請求項１から５までのいずれか１項記載の方法。
7. 中央箇所から、少なくとも１つの更新メッセージを、前記ＤＮＳサーバー（６）に送信し、前記更新メッセージは、前記ストリームに対する前記第１のタイプの少なくとも１つのストリーム識別子と、前記第２のタイプの少なくとも１つのストリーム識別子と、前記所定のタイプの表示とを含んでいる、前記ＤＮＳサーバー（６）用のエントリを含んでいる、請求項１から６までのいずれか１項記載の方法。
8. 前記更新メッセージ（１３）からの前記エントリは、前記２つのタイプのストリーム識別子と前記所定のタイプの表示との他に、クラスおよび／またはＴＴＬ表示および／または有利には６４ビットのサイズのＲＤＡＴＡ領域を含んでいる、請求項６または７記載の方法。
9. 前記更新メッセージ（１３）からの前記エントリは、前記第１のタイプのストリーム識別子がそれぞれ先頭にあり、その後にタイプ、クラス、ＴＴＬ表示およびＲＤＡＴＡ領域が続くように構築されている、請求項６から８までのいずれか１項記載の方法。
10. 前記第２のタイプのストリーム識別子を、前記エントリのＲＤＡＴＡ領域において表示する、請求項６から９までのいずれか１項記載の方法。
11. 前記更新メッセージ（１３）を、ＤＮＳ更新の形式で前記ＤＮＳサーバー（６）に送信する、請求項６から１０までのいずれか１項記載の方法。
12. 前記少なくとも１つのストリーム参加部材は、分散型アプリケーションの参加部材である、請求項１から１１までのいずれか１項記載の方法。
13. 前記ネットワークは１つ以上のノードを含んでおり、前記第２のタイプのストリーム識別子を前記ネットワークの１つ以上のノードに格納する、請求項１から１２までのいずれか１項記載の方法。
14. ストリーム識別子情報を提供するための方法であって、
    前記方法では、少なくとも１つのストリーム識別子ファイル（１１）をＤＮＳサーバー上（６）に提供し、前記ストリーム識別子ファイル（１１）はエントリを含んでおり、前記エントリはそれぞれ、ストリームに割り当てられている第１のタイプのストリーム識別子と、前記第１のタイプのストリーム識別子とは異なる、各前記ストリームに割り当てられている第２のタイプのストリーム識別子と、前記タイプのエントリに対してのみ使用されている、もしくは使用される、所定のタイプの表示とを含んでいる、
    方法。
15. ストリーム識別子ファイル（１１）を提供するためのＤＮＳサーバー（６）の使用であって、
    前記ストリーム識別子ファイル（１１）はエントリを含んでおり、前記エントリはそれぞれ、ストリームに割り当てられている第１のタイプのストリーム識別子と、前記第１のタイプのストリーム識別子とは異なる、各前記ストリームに割り当てられている第２のタイプのストリーム識別子と、前記タイプのエントリに対してのみ使用されている、もしくは使用される所定のタイプの表示とを含んでいる、
    ＤＮＳサーバー（６）の使用。
16. 機器（１，２）であって、
    エントリが格納されているＤＮＳサーバー（６）へ要求メッセージ（８）を送信するように構成および／または設定されており、前記要求メッセージはそれぞれ、ストリームに割り当てられている第１のタイプのストリーム識別子と、前記第１のタイプのストリーム識別子とは異なる、各前記ストリームに割り当てられている第２のタイプのストリーム識別子と、前記タイプのエントリに対してのみ使用されている、もしくは使用される、所定のタイプの表示とを含んでおり、前記要求メッセージは少なくとも１つの、前記機器に既知の、前記第１のタイプのストリーム識別子と、前記所定のタイプとを含んでおり、
    前記ＤＮＳサーバー（６）から応答メッセージ（９）を受け取るように構成および／または設定されており、前記応答メッセージは、前記ストリームに属する前記第２のタイプのストリーム識別子を含んでおり、かつ
    受け取った前記第２のタイプのストリーム識別子を使用して、属するストリームと接続するように構成および／または設定されている、
    機器（１，２）。
17. 前記第１のタイプのストリーム識別子は、前記ストリームを識別するために前記機器（１，２）によって使用されるストリーム名であり、かつ／または前記第２のタイプのストリーム識別子は、前記ストリームを識別するためにネットワークによって使用されるストリームＩＤである、請求項１６記載の機器（１，２）。
18. 前記機器（１，２）は、前記要求メッセージ（８）をＤＮＳクエリの形式で送信するように、かつ／または前記応答メッセージをＤＮＳクエリの形式で受け取るように構成および／または設定されている、請求項１６または１７記載の機器（１，２）。
19. 前記機器（１，２）は、ストリームに対する前記第１のタイプの少なくとも１つのストリーム識別子と、前記第２のタイプの少なくとも１つのストリーム識別子と、前記所定のタイプの表示とを含んでいる更新メッセージ（１３）を前記ＤＮＳサーバー（６）に送信するように構成および／または設定されている、請求項１６から１８までのいずれか１項記載の機器（１，２）。
20. 請求項１から１４までのいずれか１項記載の方法を実施するためのプログラムコード手段を含んでいるコンピュータープログラム。
21. コンピューター可読媒体であって、
    前記コンピューター可読媒体は命令を含んでおり、前記命令は、前記命令が少なくとも１つのコンピューター上で実行されると、前記少なくとも１つのコンピューターに、請求項１から１４までのいずれか１項記載の方法のステップを実行させる、
    コンピューター可読媒体。

Images