JP5006452B2

JP5006452B2 - Ｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅネットワーク

Info

Publication number: JP5006452B2
Application number: JP2010538361A
Authority: JP
Inventors: ペトリヨケラ，; ペッカニカンデル，; ティームリンタ−アホ，; ミッコセルエレ，
Original assignee: テレフオンアクチーボラゲットエルエムエリクソン（パブル）
Priority date: 2007-12-19
Filing date: 2007-12-19
Publication date: 2012-08-22
Anticipated expiration: 2027-12-19
Also published as: US20100312898A1; WO2009080096A1; EP2223501A1; US9154571B2; JP2011507113A; EP2223501B1

Description

本発明は、ｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅネットワークに関し、特に、複数の別個のｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅネットワークを相互接続する方法及び装置に関する。

インターネットは主として、ホスト間のポイント・ツー・ポイント接続を確立する手段として創造された。インターネットは、ｆｔｐやｔｅｌｎｅｔのようなホスト・ツー・ホスト・アプリケーションを活用する。インターネットの歴史的な起源の結果として、インターネットは、主要な名付けられたエンティティとしてホスト及びエンドポイントに焦点を当てている。即ち、ホストはＵＲＬによって特定され、エンドポイントはＩＰアドレスによって特定される（多くの場合、ホストはエンドポイントでもあるが）。このように焦点を当てることは、多数のよく知られている問題を生み出す。例えば、現在の相互接続のパラダイムは、自己中心的なユーザがいたり悪意あるユーザがいたりする場合にはあまり適していないオープンネットワークを提供する。攻撃者がＩＰアドレスに対してトラヒックを氾濫させてそのＩＰアドレスを「所有する」当事者によるインターネットへのアクセスが場合によっては拒否される結果をもたらすことを防止するアーキテクチャは、インターネットには元々備わっていない。更なる問題は、インターネットは、データ認証のためのメカニズムを元々提供しないということである。例えば、ｈｔｔｐＧＥＴ及び公開されたＵＲＬを使用してウェブページを取得するユーザは、取得されたデータが真正であるか否かを知る術を持たない。

インターネットは今では、主としてデータ取得及びサービスアクセスのために使用されるシステムへと進化した。実際、インターネットを介してアクセスされるデータの多くは静的（スタティック）である。即ち、少なくとも短期間では変化しない。動的（ダイナミック）なウェブページですら、少量のクライアント固有（即ち、可変）ＨＴＭＬコードと共に張り合わされた多数の静的なコンポーネントから構成される傾向にある。一般化すると、音声呼のようなリアルタイムの双方向（インタラクティブ）トラヒックという例外の可能性もあるが、現在のネットワークトラヒックの大部分は、データ指向である。インターネットを使用する（ユーザ）アプリケーションは、接続を生成することには関心を持っておらず、むしろ、明確なデータピースを伝送することに関心を持っている。マルチキャスティングネットワーク及びピア・ツー・ピア・ネットワークにようなメカニズムは一部の固有の問題を扱うが、インターネットに存在する基本的な欠陥を扱ってはいない。

「ｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅ」又は「ｐｕｂｓｕｂ」として知られているネットワークパラダイムが開発中であり、多くのこれらの基本的な欠陥を扱う。このパラダイムは、データに対して暗号的に結び付けられている発行ＩＤ(publication identifier)を使用してｐｕｂｓｕｂネットワーク内でデータを特定することに基づいている。発行ＩＤは例えば、データの発行者(publisher)が所有する秘密鍵のハッシュであってもよい。そして発行者は、関連付けられた秘密鍵を使用することにより、データに対して、データに乗せられる署名を添付し、ネットワーク上にデータを発行する。データは多数の異なる場所で保持されてもよい。データを取得するために、ユーザは、発行者ＩＤ及び自分の場所を含んだＳｕｂｓｃｒｉｂｅメッセージをローカルルータへ送信する。ルータは、何らかのランデブーシステムを使用してデータのコピー（一般的には、最も近いコピー）の場所を特定し、Ｓｕｂｓｃｒｉｂｅメッセージをその場所へとルーティングする。自律システム（例えば、単一のオペレータが所有するネットワーク）内で、ランデブーシステムは、発行者ＩＤとデータの場所との間のマッピングを維持管理する単一のランデブーサーバを備えることができる。署名付きのデータのコピー（複製）と公開鍵とが、何らかの最適化された経路を通って、要求側ユーザへと配信される。ユーザは必ずしも、どの場所からデータが取得されたかを知っていたり気にしたりする必要がない。更に、ｐｕｂｓｕｂネットワークは、ＵＲＬをＩＰアドレスに変換(resolve)するために実行される別個のＤＮＳルックアップを必要としない。むしろ、Ｓｕｂｓｃｒｉｂｅメッセージが、供給源特定（ソースロケータ）及びデータ要求の両方として機能する。

ｐｕｂｓｕｂネットワーク内では、ルータは、Ｓｕｂｓｃｒｉｂｅメッセージが宛先から受信された場合にデータを配信するだけである。サービス拒否という結果をもたらすフラッディング攻撃は、これにより、効果的に防止される。

あり得ることであるが、短中期的には、ｐｕｂｓｕｂネットワークは、スタンドアロンネットワーク（即ち、インターネットに接続するためにゲートウェイを使用する「アイランド」）として確立されよう。予想可能なことであるが、１つのｐｕｂｓｕｂアイランドに接続しているユーザは、インターネット（又は、場合によっては他のＩＰネットワーク）を介して他のｐｕｂｓｕｂアイランドからデータを取得することを望むかもしれない。この場合、ユーザは、データに対する発行ＩＤを含んだＳｕｂｓｃｒｉｂｅメッセージをローカルルータへと送信することになるかもしれない。ルータが適切に設定されているとすれば、ルータは、その発行ＩＤがローカルＩＤではないということを認識可能であり、インターネットゲートウェイへとそれを転送するであろう。しかしながら、現在のＤＮＳシステムは、発行者ＩＤとリモートノード（この場合、要求されたデータが保持されている場所）のＩＰアドレスとの間の逆マッピングを実行するいかなる手段も提供しない。

本発明の目的は、上述した問題に対処することである。これは、ＩＰネットワーク（例えば、インターネット）内を拠点とするランデブーシステムを使用して複数のｐｕｂｓｕｂネットワークのローカル・ランデブーシステムを一緒に接続することにより、達成される。

本発明の第１の態様によれば、通信ネットワーク内で使用するための装置であって、前記通信ネットワークはローカル・ランデブーシステムを備え、前記ローカル・ランデブーシステムにおいてデータが発行ＩＤを使用して発行され、前記ローカル・ランデブーシステムは発行されたデータを取得するためにローカルホストによって使用される、装置が提供される。前記装置はＩＰネットワークに接続されて使用されるように構成され、前記装置は更に、前記発行ＩＤに関連するＳｕｂｓｃｒｉｂｅ要求をローカルホストから受信し、前記ＩＰネットワークに備えられるランデブーシステムのディセミネーションハンドラに対して前記発行ＩＤに関連する更なるＳｕｂｓｃｒｉｂｅ要求を送信し、前記発行ＩＤを伴って発行されたデータを前記ＩＰネットワークを介して受信し、前記受信したデータを前記ローカルホストへルーティングするように構成される。

本発明の好適な実施形態では、前記装置は前記更なるＳｕｂｓｃｒｉｂｅ要求の送信に続いてピアノードとのＴＣＰセッションを確立するように構成され、前記データは前記セッションの中で受信される。前記ピアノードはピアゲートウェイノード又はＩＰネットワークホストであってよい。いずれの場合でも、前記装置は前記Ｓｕｂｓｃｒｉｂｅ要求をＴＣＰＳＹＮメッセージとして扱う。

本発明は、ｐｕｂｓｕｂネットワークがＩＰマルチキャストを購読できるようにするために採用可能である。この場合、前記装置は、前記Ｓｕｂｓｃｒｉｂｅ要求に対する応答を前記ＩＰネットワークに備えられる前記ランデブーシステムから受信するように構成され、前記応答はＩＰマルチキャストグループアドレスを含み、前記装置は、前記グループアドレスに対してマルチキャストＪｏｉｎ要求を送信するように構成される。

本発明の第２の態様によれば、通信ネットワーク内で使用するための装置であって、前記通信ネットワークはローカル・ランデブーシステムを有するローカルネットワークを備え、前記ローカル・ランデブーシステムにおいてデータが発行ＩＤを使用して発行され、前記ローカル・ランデブーシステムは発行されたデータを取得するためにローカルホストによって使用される、装置が提供される。前記装置はＩＰネットワークに接続されて使用されるように構成され、前記装置は更に、発行ＩＤに関連するＰｕｂｌｉｓｈ要求を前記ローカルネットワーク内のローカルホストから受信し、前記ＩＰネットワークに備えられるランデブーシステムのディセミネーションハンドラに対して前記発行ＩＤに関連する更なるＰｕｂｌｉｓｈ要求を送信し、前記発行ＩＤに関連するＳｕｂｓｃｒｉｂｅ要求を前記ランデブーシステムから受信し、前記発行ＩＤを伴って発行されたデータを前記ＩＰネットワークを介して購読者ホストへ配信するように構成される。

本発明の第３の態様によれば、データを第１のｐｕｂｌｉｃａｔｉｏｎ／ｓｕｂｓｃｒｉｂｅネットワーク上に発行して第２のｐｕｂｌｉｃａｔｉｏｎ／ｓｕｂｓｃｒｉｂｅネットワーク内のホストで入手可能にする方法であって、前記第１及び第２のネットワークはＩＰネットワークを介して相互接続されている、方法が提供される。前記方法は、前記ＩＰネットワーク内に配置されるランデブーシステムに前記データの発行ＩＤを登録するステップと、前記発行ＩＤに関連するＳｕｂｓｃｒｉｂｅ要求を前記第２のネットワークから前記ランデブーシステムへ転送するステップと、前記ランデブーシステムにおいて、前記第１のネットワーク内での前記データの場所を特定するステップと、前記ランデブーシステムにおいて、前記Ｓｕｂｓｃｒｉｂｅ要求を前記第１のネットワークへ転送するステップと、前記第１のネットワークから前記第２のネットワークへ前記ＩＰネットワークを介して前記データを配信するステップと、を備える。

本発明の第４の態様によれば、データを第１のｐｕｂｌｉｃａｔｉｏｎ／ｓｕｂｓｃｒｉｂｅネットワーク上に発行して第２のｐｕｂｌｉｃａｔｉｏｎ／ｓｕｂｓｃｒｉｂｅネットワーク内のホストで入手可能にする方法であって、前記第１及び第２のネットワークはＩＰネットワークを介して相互接続されている、方法が提供される。前記方法は、前記ＩＰネットワーク内に配置されるランデブーシステムに前記データの発行ＩＤ及び対応するマルチキャストグループアドレスを登録するステップと、前記発行ＩＤに関連するＳｕｂｓｃｒｉｂｅ要求を前記第２のネットワークから前記ランデブーシステムへ転送するステップと、前記ランデブーシステムにおいて、前記マルチキャストグループアドレスを特定するステップと、前記ランデブーシステムにおいて、前記特定されたマルチキャストグループアドレスを前記第２のネットワークへ返すステップと、前記第２のネットワークから前記グループアドレスへマルチキャストＪｏｉｎ要求を送信するステップと、を備える。

ＤＯＮＡアーキテクチャを概略的に示す図である。ｐｕｂｓｕｂネットワークのペアを相互接続するＤＯＮＡアーキテクチャの使用法を概略的に示す図である。ｐｕｂｓｕｂネットワークからＤＯＮＡシステム上へのデータの発行、及びこれに続くそのデータの購読(subscription)に関連するシグナリングフローを示す図である。インターネットホストからＤＯＮＡシステム上へのデータの発行、及びこれに続くそのデータの購読に関連するシグナリングフローを示す図である。ｐｕｂｓｕｂネットワークのゲートウェイノード、及び本発明の実装を概略的に示す図である。図２のシステムにおいてデータを発行するプロセスを示すフロー図である。図２のシステムにおいて発行されたデータを購読するプロセスを示すフロー図である。マルチキャスト経由でのｐｕｂｓｕｂネットワークからＤＯＮＡシステム上へのデータの発行、及びこれに続くそのマルチキャストデータの購読に関連するシグナリングフローを示す図である。

上述のように、ｐｕｂｓｕｂネットワークは、ネットワーク上に発行されたデータを特定しその位置を特定するために、発行ＩＤを使用する。ネットワーク内のランデブーシステムは、購読者(subscriber)から発行されたデータへとＳｕｂｓｃｒｉｂｅメッセージをルーティングする。孤立した各ｐｕｂｓｕｂネットワークをインターネット経由の効率的なやり方で一緒にリンクさせることを可能にするために、更なるランデブーシステムをインターネット内に提供すべきである。

ここで提案されることは、既存のインターネット上にオーバーレイされ（重ねられ）、「フラットネーム」ＩＤを使用してデータを特定するランデブーシステムを使用することである。フラットネームＩＤは、階層構造（例えば、"username.company.com"）を持たないＩＤである。フラットネームはネットワークトポロジとの厳密な結合を持たず、それゆえ、攻撃者がトポロジの詳細を推定する（或いは、トポロジにおいて選択された点へ望まれていないトラヒックを送信する）ためにフラットネームを使用することができないので、フラットネームは望ましい。トポロジと名付け（ネーミング）との間のこの分離はまた、マルチホーミング及びモビリティを簡単にする。フラットネームはまた、複数の場所にデータをキャッシュして最適な（即ち、最も近い）場所からそのデータを取得することも可能にする。更に、ここで提案されることは、場所の特定及びデータの取得開始を基本的に単一のステップで実装するランデブーシステムを利用することである。

従来のインターネットの多数の欠点に対処するために、データ指向ネットワークアーキテクチャ（ＤＯＮＡ）として知られている白紙からの再設計が提案されてきている。"A Data-Oriented (and Beyond) Network Architecture", Koponen, T. et al, I. Proceedings of the Sigcomm 2007, pages 181--192, ACM Press New York, NY, USA.を参照のこと。ＤＯＮＡは、データに対して持続性、入手可能性、及び信頼性を与え、データへの到達可能性に影響を与えずにデータをキャッシュして移動することを可能にすることを目的とする。ＤＯＮＡによって提案される名付けシステムは、自己証明を行いＰ：Ｌの形式を持つ名前を提供する。ここで、Ｐは、本人（発行者）の公開鍵に関する暗号法によるハッシュであり、Ｌは、本人によって選択された文字列である。

図１に、ＤＯＮＡアーキテクチャを概略的に示す。ＤＯＮＡアーキテクチャは、レゾリューションハンドラ(Resolution Handler)と呼ばれる場合もあるディセミネーションハンドラ(Dissemination Handler)（ＤＨ）から構成される。典型的には、１つ（それより多い場合もあるが）のＤＨが各自律システム（ＡＳ）内に配置される。予想されることとして、ＤＨヒエラルキーのレイヤーは、インターネットのサービス提供ビジネスモデルの階層(tier)へとマッピングされる。階層１のＤＨは、他のネットワークからのトランジットを受け入れないグローバルサービスプロバイダのネットワーク内に配置される。階層２のＤＨは、他のネットワークのピアになると共に階層１のＡＳからのトランジットを受け入れるサービスプロバイダのネットワーク内に配置される。階層３のＤＨは、他のネットワークのピアとはならずに階層１又は階層２のＡＳからのトランジットを受け入れるだけのサービスプロバイダのネットワーク内に配置される。ＤＨアーキテクチャをビジネスモデルにマッピングすることにより、より高い階層のネットワークが自分たちより下のネットワークに対して供給者／顧客(supplier/customer)の関係を持ち、下のネットワークのＤＨがより高い階層のＤＨのサービスを必要とするということが確実にされる。

ＤＨは、２つのプリミティブ（基本型）、ＦＩＮＤ（Ｐ：Ｌ）及びＲＥＧＩＳＴＥＲ（Ｐ：Ｌ）をサポートする。ＤＨがクライアント（即ち、発行者）からＲＥＧＩＳＴＥＲ（Ｐ：Ｌ）を受信すると、ＤＨは発行ＩＤ及び場所情報（例えば、ＩＰアドレス）を自分のキャッシュに入れ、その要求をより高い階層のＤＨ及びピアのＤＨへと転送する。こうして、階層１のＡＳのＤＨは、全ての登録された発行に関する場所情報を持つことになる。購読者であるクライアントがＦＩＮＤ（Ｐ：Ｌ）要求をローカルＤＨへ送信すると、そのＤＨは、自分の登録テーブルの中で発行の最も近い複製の場所を判断して要求をその場所へ転送するか、又は、より高い階層のＤＨへとその要求を転送する。より高い階層のＤＨは、このプロセスを繰り返す。

ＤＨは、Ｓｕｂｓｃｒｉｂｅ要求のルーティングを処理することに加えて、発行されたデータのためのローカルキャッシュとして機能することができる。それゆえ、Ｓｕｂｓｃｒｉｂｅ要求を受信するＤＨは最初に、要求されたデータがキャッシュ内に保持されているか否かを判定するために自分のローカルキャッシュをチェックする。キャッシュされている場合、データはキャッシュから直接提供され、要求を更に転送する必要は無い。

既に論じてきたように、発行者がデータをｐｕｂｓｕｂネットワークに発行する際に、そのデータに関する入手可能性情報がローカル・ランデブーシステム内に生成される。ｐｕｂｓｕｂネットワーク及びインターネットの両者が共存する期間である移行フェーズに効率的に対処するために、インターネットをルーティング及び転送のメカニズムとして使用することによりｐｕｂｓｕｂネットワーク・アイランドを相互接続するためのランデブーメカニズムとしてＤＯＮＡを使用することがここでは提案される。ｐｕｂｓｕｂネットワークのゲートウェイノード（ＧＷ）は、ｐｕｂｓｕｂ発行ＩＤをＤＯＮＡシステムで使用される形態（即ち、Ｐ：Ｌ）に変換することを担う。ゲートウェイノードは、ＤＯＮＡＤＨとして効果的に動作し、データをＤＯＮＡシステムに発行してデータの実際の場所として自分のＩＰアドレスを提供する。この複合アーキテクチャを図２に概略的に示す。

（ｐｕｂｓｕｂネットワークの）ユーザのホストＡ１がデータアイテムを購読したが、そのデータアイテムがローカルｐｕｂｓｕｂネットワーク２のランデブーシステムからは発見されない場合を考える。要求はそれゆえ、ｐｕｂｓｕｂネットワークのゲートウェイノード３経由で、インターネット５内に配置されるＤＯＮＡシステム４へとルーティングされる。ＤＯＮＡシステムは次に、発行を特定し、発行されたデータが配置されているｐｕｂｓｕｂネットワーク７のゲートウェイノード６のＩＰアドレスを特定する。ＤＯＮＡシステムは、Ｓｕｂｓｃｒｉｂｅメッセージをそのゲートウェイノード６へ転送する。ＤＯＮＡシステムは、メッセージ内に、要求側ユーザ１に関連付けられたゲートウェイノード３のＩＰアドレスを含める。次いで発行側のゲートウェイノード６は、既存のＩＰルーティングシステムを使用することにより、要求されたデータをインターネット５経由で購読側のゲートウェイノード３へ配信可能である。

インターネット上でのゲートウェイノード間の送信は保護されてもよく、ゲートウェイノードは何らかの適切なメカニズムを使用して相互に認証することができる。例えば、ゲートウェイノードは、相互間でセキュリティアソシエーション（セキュリティ関連付け）を確立するために、ＨｏｓｔＩｄｅｎｔｉｔｙＰｒｏｔｏｃｏｌ（ＨＩＰ）を使用してもよい。

図３は、図２の複合アーキテクチャ内での典型的なシグナリングフローを示す。以下のステップを特定可能である。

１．ホストＢが、発行ＩＤとしてＳｕｂＩＤを持つデータを発行する。データへの経路は、ローカル・ランデブーシステムに格納され、データは他のローカルｐｕｂｓｕｂホストに対してそのシステムから直接入手可能である。この経路は、イーサネット（登録商標）アドレス又はＭＡＣアドレスであってよく、加えて、イーサネット（登録商標）ルーティングである。

２．次にゲートウェイＢは、発行ＩＤであるＳｕｂＩＤをＤＯＮＡネームＰ：Ｌにマッピングする。ここで、Ｐはゲートウェイの公開鍵の暗号法によるハッシュであり、Ｌは発行されたデータに対してゲートウェイＢによって割り当てられた固有ＩＤである。ゲートウェイＢは、あたかも自分自身がＤＨであるかのようにデータ情報をＤＯＮＡシステムに発行し、自分のＩＰアドレスをデータの場所として与える（即ち、Ｐ：ＬからＩＰアドレスへのマッピングを発行する）。

３．ＤＯＮＡシステムは、発行されたマッピングを格納する。このことは、マッピングを複数のＤＨの間に拡散させることを伴う。

４．ホストＡが、ＩＤとしてＳｕｂＩＤを持つデータを購読する。

５．ゲートウェイＡは、このデータはローカルネットワークにおいては入手不可能であると判断し（この判断には、ローカル・ランデブーシステムに対するクエリが必要であろう）、それゆえ、ＤＯＮＡシステムに対してクエリを送信する。

６．発行者からの応答を待つ間に、ゲートウェイＡは、自分自身から購読者のホストＡへの転送パスを構築するために、ローカルｐｕｂｓｕｂネットワーク内のルーティング機能にコンタクトする。

７．ローカルルーティング機能は、パスを生成し、パスのルータ内の転送テーブルを設定する。
注：ステップ６及び７は、このプロセスにおいてもっと後で発生してもよい。例えば、データが配信されることを確信したいとゲートウェイＡが望む場合、ローカルルーティングパスの確立の前である。

８．ＤＯＮＡシステムは、自分のランデブーシステムにおいてルックアップを実行し（例えば図１を参照）、ＤＯＮＡシステムにおいては発行を入手不可能であるが（即ち、この発行はＤＨのいずれかにおいて以前にキャッシュされてはいない）、ゲートウェイＢから注文可能であると判断する。

９．ＤＯＮＡシステムは、ＳｕｂｓｃｒｉｂｅをゲートウェイＢ（「プロキシＢ」）へ送信し、ゲートウェイＡのＩＰアドレス（「プロキシＡ」）をパケットヘッダに含めることにより購読者ホストのゲートウェイＡを特定する。Ｓｕｂｓｃｒｉｂｅ要求は、ゲートウェイＢによってＴＣＰＳＹＮと見なされてもよい。

１０．データがゲートウェイＢにキャッシュされていないとすると、データはローカルｐｕｂｓｕｂネットワークから購読される必要がある。このステップは、ホストＢ（又は、他のノード。例えば、ネットワークサーバ）に対してデータを要求し、ホストＢとゲートウェイＢとの間の転送パスを構築することを伴う。

１１．標準のＩＰ転送メカニズムを使用して、データがゲートウェイＢとゲートウェイＡとの間で転送される。ＴＣＰの場合、ゲートウェイＢは、ゲートウェイＡのＩＰアドレスに対してＴＣＰＳＹＮ＋ＡＣＫを送信することにより（ＴＣＰＳＹＮに対して）応答する。

１２．ゲートウェイＡで受信されたデータは、ステップ７で設定された転送パスを使用して転送される。

自分のデータを発行するためにＤＯＮＡを使用するインターネットホスト（例えば、図２のホスト９）からｐｕｂｓｕｂネットワークのホストがデータを取得できるようにするために、上述したアプローチを適合させることができる。インターネットホスト９が自分のデータを発行する際に、そのデータのためのＤＯＮＡＩＤ（Ｐ：Ｌ）が、前述（即ち、上のステップ２及び３）したようにＤＯＮＡシステムに挿入される。ｐｕｂｓｕｂゲートウェイが発行されたデータを要求すると（上のステップ５から６）、要求は、データの最も近い場所（データがＤＨにキャッシュされた場合はＤＨでもよいし、発行者ホストでもよい）へとルーティングされる。この要求パケットは、宛先では、ＴＣＰＳＹＮパケットであると見なされる。ＴＣＰ通信セットアップの残り（サーバＳＹＮ−ＡＣＫ及びクライアントＡＣＫ）が、データの場所とゲートウェイノードとの間で直接実行される。最後に、ＴＣＰ接続を介してゲートウェイノードへとデータが転送される。ゲートウェイノードがデータを受信した後に、ゲートウェイノードはデータをｐｕｂｓｕｂネットワークにおいて使用される発行フォーマットに変換し（例えば、ＩＰヘッダをｐｕｂｓｕｂヘッダに置き換えることにより）、これをローカルに発行することで、購読者ホストが入手可能なようにする（実際、このことは、ｐｕｂｓｕｂネットワークを介してホストへデータを送信することを意味し得る）。

図４は、データ発行者がインターネットホストである場合に関するシグナリングフローを示す。このフローは、図３に示したものに類似している。但し例外は、発行要求及び購読要求がＤＯＮＡシステムとインターネットとの間で直接交換されており、ゲートウェイ（即ち、ゲートウェイＢ）が関与していないことである。

図５は、上述したシステムでの使用のためのゲートウェイノード１０を概略的に示す。ノードは、ゲートウェイをｐｕｂｓｕｂネットワークに接続するための第１のインタフェース１１と、ゲートウェイノードをインターネットに接続するための第２のインタフェース１２とを備える。プロセッサ１３は、ｐｕｂｓｕｂネットワークから受信されたＳｕｂｓｃｒｉｂｅ要求をＤＯＮＡシステムへ転送し、ピアのゲートウェイとのＴＣＰ接続を確立することを担う。プロセッサはまた、ピアのゲートウェイから到着するＳｕｂｓｃｒｉｂｅ要求を処理する。

図６のフロー図は、データをＤＯＮＡシステムに発行する処理を示す。ステップ１００で、ゲートウェイＢは、Ｐｕｂｌｉｓｈ（ＳｕｂＩＤ）要求をローカルホストＢから受信し、ステップ１０１で、ゲートウェイＢは、その要求をＤＯＮＡシステムのＤＨへ送信する。ステップ１０２で、ＤＯＮＡシステムは、ＤＨヒエラルキーのあちこちへ発行場所を拡散させる。

図７のフロー図は、ＤＯＮＡシステム経由でデータを取得する処理を示す。ステップ２００で、ゲートウェイＡは、ホストＡからＳｕｂｓｃｒｉｂｅ（ＳｕｂＩＤ）メッセージを受信し、ＳｕｂＩＤをＰ：Ｌに変換し、ステップ２０１で、ゲートウェイＡは、そのメッセージをＤＯＮＡシステムのＤＨへ転送する。次にゲートウェイＡは、ローカル転送パスを構築する。ステップ２０２で、ＤＯＮＡシステムは、Ｐ：Ｌを使用してデータの場所を特定し、Ｓｕｂｓｃｒｉｂｅ要求をゲートウェイＢへ転送する。ステップ２０３で、ゲートウェイＢは、発行されたデータをホストＢから取得し、インターネットを介してデータをゲートウェイＡへ転送する。

ＤＯＮＡシステムは、ＩＰマルチキャストによりデータを発行するためにｐｕｂｓｕｂネットワークによって使用可能である。このシナリオに関連するシグナリングフローを図８に示す。フローは概ね、図３に示すものに沿っている。但し、例外として、ステップ２で、ゲートウェイＡは、ソースアドレスＳ（即ち、データが配置されているＩＰアドレス）及びマルチキャストの標準に従うグループアドレスＧによりデータの場所を発行する。ＤＯＮＡシステムが引き続いて（ゲートウェイＡにおけるローカルＳｕｂＩＤの変換に続いて）Ｐ：Ｌへ宛てられたＳｕｂｓｃｒｉｂｅ要求を受信し、マルチキャストアドレス（Ｓ，Ｇ）へとマッピングすると、ＤＯＮＡシステムは、グループアドレスを用いてゲートウェイＡに対して応答する。ステップ１０で、ゲートウェイＡは、標準のマルチキャストＪＯＩＮ要求をグループアドレスへ送信する。この要求はゲートウェイＡへルーティングされ、マルチキャストパスを構築可能になる。

当業者に理解されるであろうこととして、本発明の範囲から逸脱すること無しに、上述した実施形態に対して多様な修正を行うことが可能である。

Claims

ｐｕｂｓｕｂネットワークとＩＰネットワークとの間でゲートウェイとして動作するように構成される装置であって、
前記ｐｕｂｓｕｂネットワークはローカル・ランデブーシステムを備え、
前記ローカル・ランデブーシステムにおいてデータがローカル発行ＩＤを使用して発行され、
前記ローカル・ランデブーシステムは発行されたデータを取得するためにローカルホストによって使用され、
前記装置は更に、
指定されたローカル発行ＩＤを含んだＳｕｂｓｃｒｉｂｅ要求をローカルホストから受信し、
オーバーレイネットワーク用発行ＩＤを判定するために前記指定されたローカル発行ＩＤを変換し、
前記ＩＰネットワークに備えられるオーバーレイ・ランデブーシステムのディセミネーションハンドラに対して前記オーバーレイネットワーク用発行ＩＤに関連する更なるＳｕｂｓｃｒｉｂｅ要求を送信し、
前記オーバーレイネットワーク用発行ＩＤを伴って発行されたデータを前記ＩＰネットワークを介して受信し、
前記受信したデータを前記ローカルホストへルーティングする
ように構成される
ことを特徴とする装置。
前記更なるＳｕｂｓｃｒｉｂｅ要求の送信に続いてピアノードとのセッションを確立するように構成され、
前記データは前記セッションの中で受信される
ことを特徴とする請求項１に記載の装置。
前記セッションはトランスミッション・コントロール・プロトコル（ＴＣＰ）セッションである
ことを特徴とする請求項２に記載の装置。
前記ピアノードはピアゲートウェイノード又はＩＰネットワークホストである
ことを特徴とする請求項２又は３に記載の装置。
前記Ｓｕｂｓｃｒｉｂｅ要求をＴＣＰＳＹＮメッセージとして扱う
ことを特徴とする請求項１乃至４のいずれか１項に記載の装置。
前記Ｓｕｂｓｃｒｉｂｅ要求の受信に続いて自分自身と前記ローカルホストとの間でのローカルルーティングパスの構築を開始するように構成される
ことを特徴とする請求項１乃至５のいずれか１項に記載の装置。
前記装置は、前記Ｓｕｂｓｃｒｉｂｅ要求に対する応答を前記ＩＰネットワークに備えられる前記ランデブーシステムから受信するように構成され、
前記応答はＩＰマルチキャストグループアドレスを含み、
前記装置は、前記グループアドレスに対してマルチキャストＪｏｉｎ要求を送信するように構成される
ことを特徴とする請求項１に記載の装置。
通信ネットワーク内で使用するための装置であって、
前記通信ネットワークはローカル・ランデブーシステムを有するローカルｐｕｂｓｕｂネットワークを備え、
前記ローカル・ランデブーシステムにおいてデータがローカル発行ＩＤを使用して発行され、
前記ローカル・ランデブーシステムは発行されたデータを取得するためにローカルホストによって使用され、
前記装置は前記ローカルｐｕｂｓｕｂネットワークとインターネットとの間のゲートウェイを提供するためにＩＰネットワークに接続されて使用されるように構成され、
前記装置は更に、
ローカル発行ＩＤに関連するＰｕｂｌｉｓｈ要求を前記ローカルｐｕｂｓｕｂネットワーク内のローカルホストから受信し、
前記ローカル発行ＩＤをオーバーレイネットワーク用発行ＩＤに変換し、
前記ＩＰネットワークにオーバーレイされたランデブーシステムのディセミネーションハンドラに対して前記オーバーレイネットワーク用発行ＩＤに関連する更なるＰｕｂｌｉｓｈ要求を送信し、
前記オーバーレイネットワーク用発行ＩＤに関連するＳｕｂｓｃｒｉｂｅ要求を前記ランデブーシステムから受信し、
前記オーバーレイネットワーク用発行ＩＤを前記ローカル発行ＩＤに変換し、
前記発行されたデータを前記ローカルｐｕｂｓｕｂネットワークから取得し、
前記取得されたデータを前記ＩＰネットワークを介して購読者ホストへ配信する
ように構成される
ことを特徴とする装置。
前記Ｓｕｂｓｃｒｉｂｅ要求の受信に続いてピアノードとのセッションを確立するように構成され、
前記データは前記セッションの中で配信される
ことを特徴とする請求項８に記載の装置。
前記セッションはトランスミッション・コントロール・プロトコル（ＴＣＰ）セッションである
ことを特徴とする請求項９に記載の装置。
前記ピアノードはピアゲートウェイノード又はＩＰネットワークホストである
ことを特徴とする請求項９又は１０に記載の装置。
前記Ｓｕｂｓｃｒｉｂｅ要求の受信に続いて自分自身と前記ローカルホストとの間でのローカルルーティングパスの構築を開始するように構成される
ことを特徴とする請求項１乃至１１のいずれか１項に記載の装置。
前記ＩＰネットワークはインターネットである
ことを特徴とする請求項１乃至１２のいずれか１項に記載の装置。
前記発行ＩＤはフラットネームＩＤである
ことを特徴とする請求項１乃至１３のいずれか１項に記載の装置。
データを第１のｐｕｂｌｉｃａｔｉｏｎ／ｓｕｂｓｃｒｉｂｅネットワーク上に発行して第２のｐｕｂｌｉｃａｔｉｏｎ／ｓｕｂｓｃｒｉｂｅネットワーク内のホストで入手可能にする方法であって、前記第１及び第２のネットワークはＩＰネットワークを介して相互接続されており、前記方法は、
前記ＩＰネットワークにオーバーレイされるランデブーシステムに前記データのオーバーレイネットワーク用発行ＩＤを登録するステップと、
前記第２のネットワーク内で生成されたＳｕｂｓｃｒｉｂｅ要求に関して、当該Ｓｕｂｓｃｒｉｂｅ要求内の第２のローカルネットワーク用発行ＩＤをオーバーレイネットワーク用発行ＩＤに変換するステップと、
前記Ｓｕｂｓｃｒｉｂｅ要求を前記第２のネットワークから前記ランデブーシステムへ転送するステップと、
前記ランデブーシステムにおいて、前記第１のネットワーク内での前記データの場所を特定するステップと、
前記ランデブーシステムにおいて、前記Ｓｕｂｓｃｒｉｂｅ要求を前記第１のネットワークへ転送するステップと、
前記第１のネットワークにおいて、前記Ｓｕｂｓｃｒｉｂｅ要求を受信するステップと、
前記第１のネットワークにおいて、前記オーバーレイネットワーク用発行ＩＤを前記第１のネットワークのローカル発行ＩＤに変換するステップと、
前記発行されたデータを前記第１のネットワークから取得するステップと、
前記第１のネットワークから前記第２のネットワークへ前記ＩＰネットワークを介して前記データを配信するステップと、
を備えることを特徴とする方法。
前記ＩＰネットワークはインターネットである
ことを特徴とする請求項１５に記載の方法。
前記第１及び第２のネットワークは各自のゲートウェイノードを介してインターネットに接続され、
前記ゲートウェイノードはＰｕｂｌｉｓｈ要求及びＳｕｂｓｃｒｉｂｅ要求を前記ランデブーシステムへ転送することを担う
ことを特徴とする請求項１６に記載の方法。
前記第１のネットワークの前記ゲートウェイノードにおける前記Ｓｕｂｓｃｒｉｂｅ要求の受信に続いて前記各自のゲートウェイノード間でＴＣＰセッションを確立するステップを備える
ことを特徴とする請求項１７に記載の方法。
前記ランデブーシステムは、発行ＩＤと場所との間のマッピングを格納する複数のディセミネーションハンドラを備える
ことを特徴とする請求項１５乃至１８のいずれか１項に記載の方法。
前記複数のディセミネーションハンドラは階層構造に構成され、
発行ＩＤを含んだＳｕｂｓｃｒｉｂｅ要求をディセミネーションハンドラが受信したが当該ディセミネーションハンドラは当該発行ＩＤのためのマッピングを保持していない場合、当該ディセミネーションハンドラは当該要求をより高い階層のディセミネーションハンドラへ転送する
ことを特徴とする請求項１９に記載の方法。
前記発行ＩＤはフラットネームである
ことを特徴とする請求項１５乃至２０のいずれか１項に記載の方法。
データを第１のｐｕｂｌｉｃａｔｉｏｎ／ｓｕｂｓｃｒｉｂｅネットワーク上に発行して第２のｐｕｂｌｉｃａｔｉｏｎ／ｓｕｂｓｃｒｉｂｅネットワーク内のホストで入手可能にする方法であって、前記第１及び第２のネットワークはＩＰネットワークを介して相互接続されており、前記方法は、
前記ＩＰネットワーク内に配置されるランデブーシステムに前記データのオーバーレイネットワーク用発行ＩＤ及び対応するマルチキャストグループアドレスを登録するステップと、
前記第２のネットワーク内で生成されたＳｕｂｓｃｒｉｂｅ要求に関して、当該Ｓｕｂｓｃｒｉｂｅ要求内の第２のローカルネットワーク用発行ＩＤをオーバーレイネットワーク用発行ＩＤに変換するステップと、
前記Ｓｕｂｓｃｒｉｂｅ要求を前記第２のネットワークから前記ランデブーシステムへ転送するステップと、
前記ランデブーシステムにおいて、前記マルチキャストグループアドレスを特定するステップと、
前記ランデブーシステムにおいて、前記特定されたマルチキャストグループアドレスを前記第２のネットワークへ返すステップと、
前記第２のネットワークから前記グループアドレスへマルチキャストＪｏｉｎ要求を送信するステップと、
を備えることを特徴とする方法。