JP2007258846A

JP2007258846A - 通信システム及びネームサーバ装置

Info

Publication number: JP2007258846A
Application number: JP2006077826A
Authority: JP
Inventors: Homare Murakami; 誉村上
Original assignee: National Institute of Information and Communications Technology
Current assignee: National Institute of Information and Communications Technology
Priority date: 2006-03-20
Filing date: 2006-03-20
Publication date: 2007-10-04
Anticipated expiration: 2026-03-20
Also published as: JP4635261B2

Abstract

【課題】デバイスの移動性を確保しながら、アドレスを不必要に他者に公開しないネームネーミング方法を実現する通信システムとネームサーバ装置を提供すること。
【解決手段】デバイスに対して、通信ネットワーク上の第１の領域において使用され、デバイスとネットワークアドレスとの対応付けを行う第１のネームシステムレイヤ上のネームと、より限定的な第２の領域において使用される第２のネームシステムレイヤ上のネームとをそれぞれ付与し、第１及び第２の２つのネームシステムレイヤを用いる通信システムを提供する。
【選択図】図２

Description

本発明は通信システムと、通信システム上で用いられるネームサーバ装置に関し、特にそのネーミング方法に係るものである。

RF-IDやセンサーによる実空間情報がネットで得られるようになったり、ネットワーク接続機能を持つ家電製品がネットワークを経由した制御を受け付けるようになるなど、実空間とネットワークの融合を図ったユビキタス通信環境の整備が急速に進んでいる。
一方、通信ネットワークは有線・無線共に高速・大容量化が急速に進み、また通信時間や通信料によらない定額課金サービスが導入されてきた。これらの組み合わせにより、ユーザがどこにいても気軽に、ネットワークを経由して自宅やオフィスのデバイスを遠隔操作したり、必要な情報を取り出すことができるようになってきている。

このような環境ではユーザの利便性が高まる反面、システムの複雑さからユーザに高度な知識を要求したり、設定のミスやシステムの不具合などから第三者によって自分のデバイスや情報への予期せぬアクセスを許してしまう可能性が高くなるなど、危険性も同時に発生し得る。
そのため、設定が容易もしくは不要で、セキュリティ問題が発生しないように
設計されたシステムの実現が望まれる。

これに対応する方法として、ネットワークアドレスに２つのレイヤを用意し、１つはグローバルなアドレス空間、もう１つはプライベートなアドレス空間とする。これによれば、相互のアドレス空間はルータを介してのみ変換できるから、プライベートなアドレス空間にあるデバイスには他者がアクセスできない利点がある。

このように２つのレイヤのアドレス空間を提案する従来技術として、非特許文献１がある。該文献に開示されるIST-MAGNETプロジェクトでは、PNレイヤとIPレイヤとの２つのレイヤにおいて、PNアドレス空間とグローバルIPアドレス空間とを用意することが提案されている。
そして、あるデバイスはPNアドレスのみを有し、あるデバイスはPNアドレスと共にIPアドレスを有することで、IPレイヤにおいて外部からの接続も可能になっている。

非常に多くのデバイスがネットワークに接続されるようになると、自分の利用したいサービスや接続したいデバイスを発見・特定する手段が重要となる。例えば、今夜放送されるテレビ番組を録画しようとするとき、ユーザは自宅のビデオデッキに対して予約操作を行う必要がある。このとき、ビデオデッキ自体はネットワークに接続されていたとしても、それがＩＰアドレスのような数字列や記号列で表されているのみであれば、ユーザがネットワーク上からビデオデッキを発見して操作を行うことは難しい。

この問題を解決するためには2つの方向性が考えられる。ひとつは、各デバイスにアドレスとは別にユーザがわかりやすい名前をつけることである。とはいえ、実際の通信時にはアドレスを頼りにパケット転送が行われるので、どこかでそのデバイスの名前とアドレスの対応付け(binding)のリストを管理し、適宜変換を行うことでユーザがアドレス列を暗記する必要性を回避することができる。この仕組みをネーミング(naming)と呼んでいる。

上記非特許文献１では２つのレイヤのアドレス空間を用いた構成は開示しているが、ネーミング方法については考えられていない。また、非特許文献２ではネーミング方法について提案されているが、PNレイヤのような２つのレイヤとする技術は実現できていない。

もうひとつの解決法としては、各デバイスが「できること」(サービス)を事前に特定のサーバに登録しておく方法である。ユーザはサーバにしたいこと、例えば「テレビ番組の録画をしたい」と要求を出すと、サーバはリクエストに合致するサービスを提供しているデバイスを検索しその情報を返答することで、ユーザは適切なデバイスにアクセスすることができる。この仕組みはサービス発見(Service Discovery)と呼ばれる。

一般に、サービス発見技術はネーミング技術に比べて複雑性が高くなるため、スケーラビリティを確保するのが難しいと言われる。
この2種の技術は排他的なものではなく、組み合わせて使うことでいっそうユーザの利便性を改善できる。例えば、過去の提案技術の中ではIntentional Naming System (INS)（非特許文献３参照）がこの双方の特徴を有している。

INSでは、各デバイスが名前要素としてそのデバイスの位置、サービスの種類、アクセス特性などを有し、それらが木構造を構成することにより、ユーザが近隣に存在する欲しいサービスを容易に発見できるという特性を持つ。しかし、この名前空間の伝播・共有をホップ・バイ・ホップで行っているため、インターネットレベルでのスケーラビリティを確保することは難しい。

現在のインターネットにおいては、ネーミング方式としてDomain Name System (ＤＮＳ)（非特許文献４参照）がデファクトスタンダードとして利用されている。
ＤＮＳは階層的な名前空間を有しており、名前はデバイス名とドメイン(組織)名の組み合わせで構成される。例えば、www.nict.go.jpという名前は、はじめの”www”がデバイス名、残りの”nict.go.jp”の部分がドメイン名を示す。このドメイン名の部分が階層化構造を有し(前記の例では、jp→go→nict)、各組織が有するネームサーバは同様の階層構造を有するように構成される。これにより、各組織内で独立してデバイス名を管理でき、ドメイン数やデバイス数が増えても階層構成中に分散収容することでインターネットサイズでのスケーラビリティを獲得している。

ＤＮＳを引き続き本発明が対象とする次世代ネットワークでも利用していくことが好ましいと考えられるが、そのままでは次世代ネットワークに求められる機能のいくつかが実現できない。
まず、次世代ネットワークではユーザが動くことを前提としており、特にＰＡＮ上に存在するデバイスは移動に応じ、頻繁にRadio Access Network (RAN、例えばEthernet（登録商標）、無線LAN 802.11g、 W-CDMA（登録商標）などのアクセス方式)を変更しながら、インターネット(もしくはＩＰベースのバックボーンネットワーク)上の接続点を変更していく。このとき、新しい接続点が同一のドメインに所属するとは限らない。ＤＮＳにおいては、デバイスの名前は接続点に依存するため、本質的にデバイスの移動性に追従しているとは言えない。

また、ＤＮＳを次世代ネットワークに適用する問題として、基本的に全てのデバイスの情報が公開されてしまうことがある。あらゆるデバイスがネットワークに接続されたとき、ユーザにとっては簡単な名前で各デバイスにアクセスできることがＤＮＳの利点である。しかし、ＤＮＳに登録された名称は他のユーザからも参照可能であるので、一般名称や想像の容易な名称をデバイスに付けた場合、不必要に他者からのアクセスを誘引することになりかねない。適切にアクセス制御の設定をしていれば問題とはならないはずではあるが、個人的に使用したいデバイスについては他者に情報を開示しないほうが管理上好ましい。

関連する従来技術として、特許文献５はローカルエリアネットワーク上の装置を探索するシステム及び方法を開示している。
該システムにおいて、ネットワーク上の装置のＩＰアドレスをグループ名に関連付けるアドレスサーバーと、ネットワークの第１サブネットに配置された発見可能な装置であって、ＩＰアドレスを有してそれがグループ名に関連付けされている発見可能な装置と、ネットワークの第２サブネットに配置され、ネットワーク上の既知のサブネット及び既知の装置のリストを形成し、グループ名に関連したＩＰアドレスのリストについてネームサーバーに問合せし、発見可能な装置のＩＰサブネット情報についてグループ名に関連した発見可能な装置の各戻りアドレスにコンタクトし、発見可能な装置のサブネットを決定し、そして発見可能な装置及びそのサブネットをリストに追加する発見装置を含むことが開示されている。

IST-MAGNET Consortium ウェブページ http://www.ist-magnet.org/ H.Murakami, R.L.Olsen, H.Schwefel, R.Prasad, User-centric Name Services for personal networks, Proc. Of WPMC 04, vol.3, pp.58-62, 2004年9月 W. Adjie-Winoto, et al., ‘The design and implementation of an intentional naming system,’ Proc. of ACM SOSP’99, pp. 186 - 201, １９９９年１２月 P. Mockapetris, ‘DOMAIN NAMES - CONCEPTS AND FACILITIES,’ IETF RFC 1034,１９８７年１１月特開２００３−２５８８３２号公報

本発明は、上記従来技術の有する問題点に鑑みて創出されたものであり、デバイスの移動性を確保しながら、アドレスを不必要に他者に公開しないネームネーミング方法を実現する通信システムとネームサーバ装置を提供することを目的とする。

本発明は、上記の課題を解決するために、次のような通信システムを提供する。
請求項１に記載の通信システムは、デバイスに対して、通信ネットワーク上の第１の領域において使用され、デバイスとネットワークアドレスとの対応付けを行う第１のネームシステムレイヤ上のネームと、より限定的な第２の領域において使用される第２のネームシステムレイヤ上のネームとをそれぞれ付与し、第１及び第２の２つのネームシステムレイヤを用いる。

該通信システムにおいて、両方のネームシステムレイヤにおいて機能するネームサーバ装置を備えて、該ネームサーバ装置が、第２のネームシステムレイヤでは、場所毎にデバイスの集合として定義されるクラスタ毎に設けられ、クラスタ内の単数又は複数のデバイスから少なくともネットワークアドレスを含むデバイス登録情報を取得し、該クラスタにおけるデバイスとネットワークアドレスとの対応付けリストを記憶すると共に、第２のネームシステムレイヤ内にある他のクラスタのネームサーバ装置と該対応付けリストを交換するリンクを有して、第２の領域に属するユーザのみに対して該対応付けリストによるデバイスとネットワークアドレスとの変換機能を提供する。

請求項２に記載の通信システムは、ネームサーバ装置が、他のクラスタのネームサーバ装置と対応付けリストを交換する際に、通信システムに各クラスタのルータとなるエッジサーバ装置を備え、各クラスタにおいて、該エッジサーバ装置が該ネームサーバ装置が取得したデバイス登録情報に基づいて、該エッジサーバ装置に付与された第１の領域におけるネットワークアドレスを該デバイスに通知することを特徴とする。

請求項３に記載の通信システムは、エッジサーバ装置間をVPN(Virtual Private Network：仮想私設網）を用いて接続することを特徴とするものである。

請求項４に記載の通信システムは、上記の通信システムにおいて、各クラスタのエッジサーバ装置に付与された第１の領域におけるネットワークアドレスを前記デバイス又は、前記ネームサーバ装置、前記エッジサーバ装置の少なくともいずれかから取得し、他のクラスタの少なくともエッジサーバ装置に通知することにより、エッジサーバ装置間でのネットワークアドレスの交換を可能にするエージェントサーバ装置を備えたことを特徴とする。

請求項５に記載の通信システムは、第２のネームシステムレイヤにおける各デバイスのネームの一部に、該クラスタのクラスタ名を含む構成において、各ネームサーバ装置が、他のクラスタのネームサーバ装置に向けて該クラスタ名を広告することを特徴とする。

本発明は、次のようなネームサーバ装置を提供することができる。
すなわち、請求項６に記載の発明はは、デバイスに対して、通信ネットワーク上の第１の領域において使用され、デバイスとネットワークアドレスとの対応付けを行う第１のネームシステムレイヤ上のネームと、より限定的な第２の領域において使用される第２のネームシステムレイヤ上のネームとをそれぞれ付与し、第１及び第２の２つのネームシステムレイヤを用いる通信システムにおいて用いるネームサーバ装置である。

該ネームサーバ装置は、両方のネームシステムレイヤにおいて機能し、第２のネームシステムレイヤでは、場所毎にデバイスの集合として定義されるクラスタ毎に設けられ、クラスタ内の単数又は複数のデバイスから少なくともネットワークアドレスを含むデバイス登録情報を取得し、該クラスタにおけるデバイスとネットワークアドレスとの対応付けリストを記憶すると共に、第２のネームシステムレイヤ内にある他のクラスタのネームサーバ装置と該対応付けリストを交換するリンクを有して、第２の領域に属するユーザのみに対して該対応付けリストによるデバイスとネットワークアドレスとの変換機能を提供する。

請求項７に記載の発明は、上記の第２のネームシステムレイヤにおける各デバイスのネームの一部に、該クラスタのクラスタ名を含む構成において、各ネームサーバ装置が、他のクラスタのネームサーバ装置に向けて該クラスタ名を広告することを特徴とする。

本発明は、上記構成を備えることにより次のような効果を奏する。
すなわち、請求項１に記載の発明によれば、第１の領域と第２の領域における２つのネームシステムレイヤを用いることで第２の領域に属するユーザ以外から、第２の領域にあるデバイスへのアクセスを防ぐことができ、セキュリティの向上に寄与する。
同時に、第２の領域に属するユーザには、異なる場所のクラスタでも、自由にデバイスへのアクセスが可能であり、移動時の利便性が向上する。

請求項２に記載の発明は、エッジサーバ装置を別に備えることにより、ネームサーバ装置が直接通信ネットワークに接続しないので、セキュリティの向上に寄与する。
請求項３に記載の発明は、VPN接続により、信頼性の高いエッジサーバ装置間接続を実現する。

請求項４に記載の発明は、エージェントサーバ装置を用いることによりエッジサーバ装置間のネットワークアドレス交換を、エッジサーバ装置から行う必要がない。各エッジサーバ装置を一括して管理することができる。

請求項５に記載の発明は、クラスタ名をネームサーバ装置が広告することで、他のクラスタのデバイスへのアクセスを容易に実現することができる。

請求項６及び７に記載の発明によれば、上記の通信システムで用いられるネームサーバ装置を提供することができる。

以下、本発明の実施形態を、図面に示す実施例を基に説明する。なお、実施形態は下記に限定されるものではない。
まず、図１を用いて本発明におけるパーソナルネットワーク（ＰＮ）と、クラスタ、さらにＰ−ＰＡＮ（Private Personal Area Network）の定義について説明する。
通常のＰＡＮはブルートゥースや無線ＬＡＮなど、ユーザの近傍に存在するデバイス群で形成された(無線)リンクレベルのネットワークである。一方、本発明では、デバイスの所有者の情報を考慮し、単一ユーザのデバイス群のみで形成される第２の領域であるＰＡＮをＰ−ＰＡＮ（１）と呼ぶ。
このＰ−ＰＡＮ内は信頼済みとしてデータの送受やアクセスが自由に行える一方、Ｐ−ＰＡＮ外のデバイスとの通信は制限される。

同様に、自宅や会社、車などユーザが長時間滞在する場所においても同様に、単一ユーザの所有するデバイスのみで小規模なネットワークが形成される。
この局所的なデバイスの集合体をクラスタ（２）（３）（４）と呼ぶ。Ｐ−ＰＡＮ（１）と同様にこのクラスタ内はセキュアなものとして自由に通信が行えるが、クラスタ外との通信は制限される。

Ｐ−ＰＡＮや各クラスタは、インターネットやＵＭＴＳ(Universal Mobile Telecommunications System）、無線ＬＡＮやadhoc通信などの第１の領域である相互接続ネットワーク（５）によって接続される。
その際、ユーザの必要に応じて動的に例えばＶＰＮ（Virtual Private Network）を用いてセキュアな方式で結ぶことで、ユーザは場所を気にすること無く自分の所有する全てのデバイスやデータにアクセスすることが可能となる。

ユーザから見たときに、クラスタ（２）（３）（４）に存在するデバイスも手元、すなわちＰ−ＰＡＮ内に存在するかのように簡単に扱えるようになる。このＰ−ＰＡＮとクラスタから構成される仮想ネットワークをパーソナルネットワーク(ＰＮ)（６）と呼ぶ。

次に、本発明の特徴であるネームシステムの構成について説述する。
前述のとおり、ＤＮＳサーバに登録したデバイス名はすべてのユーザに対して公開されることになり、セキュリティの観点からすべてのデバイスの名前を登録するのは好ましいとはいえない。
そこで、ＤＮＳ持つ名前空間を２つのネームシステムレイヤに分け、一方を自分自身のみがアクセス可能な名前空間（第２ネームシステムレイヤ）に、もう一方には他者からアクセスを許すデバイスのみを登録する名前空間（第１ネームシステムレイヤ）として分離する。前者のレイヤをＰＮレイヤ、後者のレイヤをＩＰレイヤと呼ぶものとする。図２にその全体図を示す。

ＩＰレイヤ（１０）とはすなわち、現在のＤＮＳアーキテクチャそのものである。他者からのアクセスを受け入れるデバイスの名前は階層的な名前空間中に記録され、グローバルに有効となる。
一方、ＰＮレイヤ（２０）は自分からのみアクセス可能な名前空間を構成する。すなわち、ＩＰレイヤ（１０）はグローバルに1つしか存在しないが、ＰＮレイヤ（２０）はユーザごとに1つずつ存在する。

ＰＮレイヤ（２０）がユーザごとに名前空間を構成するのは、セキュリティ面以外にもメリットがある。それぞれのユーザの名前空間は独立であるので、ユーザごとに同一のデバイス名を使っても問題にならないということである。例えば、“tv“や“pc“、“printer“などの名称は直感的に理解しやすいので多くのユーザが使用することが考えられる。ユーザＡとユーザＢの名前空間は独立であるので、両ユーザが自分のパソコンに“pc“というデバイス名を付けても問題とならず、それぞれ異なるPCのアドレスをバインドすることができる。

ただし、これはＰＮレイヤ（２０）についてであり、ＩＰレイヤ（１０）ではＦＱＤＮ(Fully Qualified Domain Name、ドメイン名も含めた名前)のレベルで独立である必要がある。
つまり、ユーザＡとユーザＢが同一ドメインに所属し、それぞれ自分のパソコンを他者からのアクセスを受け入れるように公開する場合、それぞれのパソコンに対して重複しない名前をつける必要がある。

図２において、各クラスタに配置されるＰＮＳ（Personal Name Server）が本発明のネームサーバである。クラスタ中の全てのデバイスは、後述するようにサブセットプログラムを備えたデバイス間通信部を備えており、その中で比較的リソースが豊かなデバイス(例えばパソコンや携帯電話端末)を定めてサーバとして機能させる。
その他のデバイス上ではクライアントとして動作させる。特に、このサーバとして動作するデバイスがＰＮＳである。ホームクラスタのＰＮＳ（２１）は例えば家庭においてあるパソコンであり、家庭内の通信端末、テレビ、エアコン等のさまざまな機器がクライアントとなるデバイスである。

一方、ＩＰレイヤ（１０）において、ＰＮＳは機能付加ネームサーバと接続する。機能付加ネームサーバは、ＤＮＳ本来の機能を有する基本部分と、追加機能を実装した拡張部分の組み合わせによって構成される。拡張部分を使用しなければ既存のＤＮＳサーバと同様の振る舞いができる。
一時にインターネット上のすべてのＤＮＳサーバを機能付加ネームサーバに置き換えることは現実的に不可能であるので、段階的な移行を考えたときにもこの構成は有効である。

この機能付加ネームサーバをＮＮＳ(New NamingScheme)サーバという。ＮＮＳサーバは、現在のＤＮＳサーバと同様に階層的に配置される。インターネット(１１)には多数のＮＮＳサーバが配置されるが、図２においてＨＮＳ(Home Name Server)(１２)はユーザが通常使うドメインのＮＮＳサーバである。

ＦＮＳ(Foreign Name Server)(13)は、ユーザのＰ−ＰＡＮがインターネット(１１)へ接続するときに接続しているドメインにあるＮＮＳサーバであり、例えばそのインターネットプロバイダのデバイスの名前情報を管理している。
したがって、ユーザがオフィスクラスタ(１４)にいるときにはその会社のドメインのＦＮＳ(１３)が、ホームクラスタ(１５)にいるときには家庭のインターネットプロバイダのＦＮＳ(１６)が用いられることになる。

ＮＮＳサーバは、このような本発明の機能を備えたネームサーバ一般を指しており、ＨＮＳ、ＦＮＳはユーザとの関係における区別のために名称を異にして説明しているだけで、構成は同一である。また、前述のＰＮＳのデバイス間通信部の機能は、ＮＮＳサーバが有する機能のサブセットである。

次に、図３には本発明における各サーバ・デバイスの構成を示す構成図を示す。また、図４は、１つのクラスタにおけるＰＮＳとデバイスの関係を示している。図５はＰＮＳとデバイスの間のメッセージフローである。
ＰＮＳ（３０）は、Ｐ−ＰＡＮ/クラスタ（３１）中でいわゆるマスターノードとして機能する。ＰＮＳ（３０）は、デバイス間通信部（３１）から自分のＰ−ＰＡＮ/クラスタ中に定期的に広告パケット(advertisement)をブロードキャスト（５０）し、他のデバイス（４０）に自分の存在を伝える。
この広告パケットには、そのＰ−ＰＡＮ/クラスタ固有のID情報としてクラスタ名(cluster_name)を含める。このcluster_nameは手動で設定される(例えば“home“や“office“などのユーザが理解しやすいもの)のが好ましい。

一方、ＰＮＳにならなかったデバイスは、デバイス間通信部（４１）のクライアント機能によって自分の情報をＰＮＳに登録する。クライアントは、自分がどのＰ−ＰＡＮ/クラスタに存在しているかをＰＮＳがブロードキャストしたcluster_nameから把握する。
電源投入直後など、まだどのＰＮＳにも登録されていない場合や、デバイスが新しいＰ−ＰＡＮ/クラスタに移動したことを検出した場合、デバイス間通信部（４１）はＰＮＳ（３０）に対して登録(registration)パケットを送信（５１）する。

この登録パケットには、少なくともＩＰアドレス（address）が含まれていなくてはならない。そのほか、デバイスの種類(device_type）や、ユーザがそのデバイスを他者に対して公開したい場合にデバイス公開フラグ（public_flag）、また多数のデバイスがネットワークにつながるので、デバイスの名前は自動付与されるのが利便性の点で好ましいが、ユーザが任意の名前を付与したい場合はデバイス名（device_name）を明示しても良い。

このような手順で、ＰＮＳ（３０）はそのＰ−ＰＡＮ/クラスタ中の全てのデバイス（４０）について情報を得、デバイスデータベース（３２）に格納する。
得た情報のうち、任意の名前が設定されていないデバイスに対しては名前の自動生成（５２）を行うこともできる。収集したデバイスの種類の情報とcluster_nameを利用して、device_type[serial_number].cluster_nameの書式での名前の生成をしてもよい。具体的には、“tv01.livingroom“や、“printer03.office“といった名前が生成される。
デバイスの種類と場所の情報を含むので、ユーザにとって理解しやすい名前が得られる。

なお、シリアル番号は同種のデバイスがＰ−ＰＡＮ/クラスタ内に存在したときに名前が重複するのを回避するためのものであり、名前の重複が無い場合は必須ではない。”tv01”と”tv02”のようにシリアル番号で重複を回避した場合、”tv01”が2台のテレビのうちどちらを指すのかを認識するのは難しい。サービス発見機能やコンテキスト管理技術などと連携してより詳細なデバイス情報を得て、メーカ名やディスプレイの大きさなど、２台間で差異のある部分を名前に組み込むと好適である。

なお、一度ＰＮＳに登録を行ったクライアントは、変更や移動が無い限り低い頻度でＰＮＳに対して周期的に通知(alive signal)（５３）を行う。
以上の過程で得られたデバイスの名前とアドレスのbindingリストは、ＰＮＳによって一定期間記憶される。この一定期間内にデバイスから周期的に送られてくるべきalive signalを受け取れなかったとき、ＰＮＳはそのデバイスが移動したかアクティブではなくなった(例えばバッテリーが切れた)と判断し、リスト（デバイスＤＢ）から抹消する。

このようにしてＰＮＳ(３０）に集められたデバイスの情報は、ユーザ自身が利用するためにＰＮレイヤ中の各ＰＮＳ間で共有される。図６にこのＰＮＳ間の通信を説明する構成図を、図７に情報共有する時のメッセージフローを示す。
ＰＮレイヤ及びＰＮレイヤが構成する名前空間はフラットな構成をとっているため、各ＰＮＳは対等な関係となる。よって、ＰＮレイヤのネーミング方式とは、各ＰＮＳが持っているデバイスの情報をどのようにして共有するか、と言い換えることができる。

本発明では、各ＰＮＳが所有する情報を他のＰＮＳとの間であらかじめ交換しておくproactive方式を採用している。各ＰＮＳは、ＰＮＳ間通信部（３３）により他のＰＮＳを探すために定期的にＰＮ全体に広告パケット(hello packet)をブロードキャスト（７０）する。この時、この広告パケットには自分のcluster_nameを付加して送信する。

クラスタ名の広告は、各クラスタとインターネットとの間でルータとして作用するエッジサーバ（６０）（６１）間でＶＰＮ接続（６２）を予め確立し、該エッジサーバを介してＰＮＳ間で行われる。これによってセキュアな通信が実現する。
なお、本発明の実施には、必ずしもエッジサーバを用いず、ＰＮＳが直接にインターネットと接続してクラスタ名の広告を行ってもよい。
する。

このブロードキャストを受け取った他のＰＮＳのＰＮＳ間通信部（３３’）は、受け取ったcluster_nameが既知か未知かを確認する。未知であった場合、そのＰ−ＰＡＮ/クラスタのデバイス情報をまだ知らないということであるので、相互にデバイス情報を交換する。
そこで、ブロードキャストを受け取ったＰＮＳ（３０’）は、送信側ＰＮＳ（３０）に対して応答パケット(acknowledgement)を送信（７１）する。このとき、応答パケットに受け取り側のcluster_nameを付加する。

こうして双方のcluster_nameの交換をした後に、互いのＰＮＳが持つ、自分のＰ−ＰＡＮ/クラスタ下に存在するデバイスの情報を交換する。すなわち、cluster_nameと、該クラスタ内のデバイスとアドレスの対応付けリストall_bindingsをＰＮＳ（３０）が送信（７２）すると、その応答及び受け取り側の同内容を返信（７３）する。

このような手順を全ＰＮＳ間で行うことで、各ＰＮＳが完全な名前空間情報を有することができる。つまり、各ＰＮＳは全てのクエリに対して自力でリゾルブ可能となり、他のＰＮＳなどにクエリを転送する必要は無くなる。
名前空間の交換が終わった後に、あるＰ−ＰＡＮ/クラスタに新しいデバイスが接続されるなどデバイス情報が更新された場合、そのＰ−ＰＡＮ/クラスタのＰＮＳは情報交換を行った全てのＰＮＳに対して即座にユニキャスト(もしくは可能であればマルチキャスト)でその変更差分を送り、各ＰＮＳが常に最新の情報を有するように維持する。

各ＰＮＳ中では、交換したデバイス情報にcluster_nameとタイマ情報を付加してデバイスＤＢに記憶される。各ＰＮＳは、前述のように定期的にhelloパケットをブロードキャストしているので、このブロードキャストが一定時間(タイマの設定値)中に受信できなかった場合、該当するＰ−ＰＡＮ/クラスタに存在する(していた)デバイスの情報は破棄される。

本実施例ではproactive方式を利用しているが、クエリの発生が少ない環境においてはreactive方式の方が通信効率が良くなる可能性もある。この場合のreactive方式とは、helloパケットで相手を知ってもデバイス情報の交換は行なわず、クエリが来たときにそれを他のＰＮＳに転送を行ってリゾルブする方式を指す。上記のような名前の自動生成を行う場合、例えば“tv01.livingroom“というデバイス名に対するクエリが来た場合、このクエリは“livingroom“クラスタに問い合わせるとリゾルブ可能であることが明確であるため、高い通信効率を期待できる。

本発明に係るＰＮレイヤは、ＩＰレイヤの名前空間とは何らの関連も持たないので、上記したＰＮレイヤにおける対応付けリストの交換はＩＰレイヤにおける階層とは関連がない一方、ユーザはどのクラスタに移動しても共有されたデバイス情報を利用することができる。
さらに本発明は、ＩＰレイヤにおいてアクセス可能なデバイスについて、Ｐ−ＰＡＮが変化してもそれを追跡して利用可能とする仕組みを備えている。以下にＩＰレイヤにつき説述する。

ＩＰレイヤの名前空間は、既存のＤＮＳが構成する名前空間と同じく階層構造を有している。全てのデバイスは特定のドメインに所属することで分散管理を可能としていると共に、名前自身に階層構造を含むので、反復検索(iterative query)によってそのデバイスの所属ドメインのネームサーバまで到達できるという特徴を有する。
現状では、ＤＮＳに登録されているインターネット上のデバイスの大半は固定的であり、ほとんど変化しない。ダイヤルアップのユーザなど、割り当てられるＩＰアドレスが動的に変化するユーザのために、ＤＮＳの登録を動的に更新できる仕組み（非特許文献６）も提案・実装されているが、想定している更新の頻度はそれほど高くない。

P. Vixie, et al., ‘Dynamic Updates in the Domain Name System (DNS UPDATE),’ IETF RFC 2136, １９９７年４月

一方、次世代ネットワークは携帯電話サービスのような高いモビリティを持つものも収容していかなくてはならない。ネットワークへの接続点を変えながら高速移動していく場合、そのデバイスのＩＰアドレスを頻繁に更新され、ネームサーバにも頻繁な更新を行うことになるだろう。そのような頻繁なbindingの更新にも耐えうるようなネーミング方式が求められる。

ＮＮＳのＩＰレイヤに登録するデバイスは全てのユーザが参照可能となるので、必要最低限のデバイス、すなわち他者からのアクセスを許可するデバイスのみ登録するべきである。そのため、デバイス（４０）のデバイス間通信部（４１）から送信される「デバイス公開フラグ」をonにセットされたデバイスのみが登録される。

公開フラグがonのデバイスは、ユーザにより固有の名前を設定されていなくてはならない(例えば“pc01“)。ユーザの、いわゆるホームネットワークのドメイン名(例えば“nict.go.jp“)と合わせて、そのデバイス固有のＦＱＤＮ(この例の場合は“pc01.nict.go.jp“) が得られる。
つまり、誰かがこの“pc01.nict.go.jp“にアクセスしようとするとき、そのユーザはnict.go.jpドメインのネームサーバに記録されている情報からリゾルブすることになる。

上述した通り、ユーザのホームネットワークのドメインを管理するＮＮＳがＨＮＳである。図８にＩＰレイヤのネームサーバと名前空間の構成を示す。
デバイスのＩＰアドレスが変更になったとき、ＰＮＳはＨＮＳに最新のアドレス情報（対応付けリスト）を送信することで、ＨＮＳに記録されているbindingを更新するのが原則である。

しかし、ＨＮＳとＰＮＳがネットワーク的に遠い場合や、Ｐ−ＰＡＮとインターネット間をつなぐ回線の通信速度が遅い場合、頻繁にbinding更新を行うとデータ転送に使うべき帯域までこの更新で占有してしまうことにもなりかねず、工夫が必要となる。

そこで、Ｐ−ＰＡＮ/クラスタが接続しているネットワーク(attaching network)のＮＮＳサーバ（上記の通りＦＮＳと呼んでいる）が連携動作する。
本来のＰＮＳとＨＮＳ間でbinding更新を行う代わりに、ＰＮＳとＦＮＳ間でbinding更新を行う。

合わせて、ＨＮＳとＦＮＳ間の連携も必要となる。ＦＮＳは、自分のアドレスと、自分が代理でアップデートを受け取っているＰ−ＰＡＮ/クラスタ中のデバイス名をＨＮＳに通知する。

図８及び図９を用いて説明すると、comm.univ.jpドメインを介してインターネットに接続しているＰ−ＰＡＮ内のデバイスは、そのドメインのネームサーバ(８１)に収容され、ユーザのホームネットワークがprovider.jpドメインであっても、そのドメインのネームサーバ(８２)には接続性を示す情報は収容されない。
これを本発明では、ＰＮＳ(８１)が定期的にprovider.jpにあるＨＮＳ(８２)に対して公開するデバイスの名前とアドレスの対応付けリスト(binding)を送信し、ＨＮＳ（８２）でそのbinding情報を保持する。

さらに、接続先のドメインがＮＮＳサーバ機能を提供する場合、そのＮＮＳサーバをＦＮＳ(８０)とする。ＰＮＳ（８１）は、ＨＮＳ（８２）の代わりにbinding情報をＦＮＳ（８０）に送信して保持・更新させ、ＦＮＳ（８１）は自己のアドレスと代理管理しているデバイス名のみをＨＮＳ（８２）に送信（９３）することで、ネットワーク上の流れる管理トラフィックを減少させる効果がある。

図１０は各サーバの構成を示す図であり、ＰＮＳ（８１）のＩＰレイヤ通信部（１００）から上記で作成されたデバイスＤＢの情報をＦＮＳのＰＮ通信部（１０１）に送信し、ＰＮ通信部は受信した情報をbindingデータベース（１０２）に格納する。ＩＰ通信部（１０３）がインターネットを介して、ＨＮＳ（８２）のＩＰ通信部（１０４）にＦＮＳの自己のアドレスと、デバイス名を通知し、ＩＰ通信部（１０４）はbindingデータベース（１０５）にそれを格納する。

この結果、図９に示すようにまず公開デバイスにアクセスしたいユーザ(corresponding node)（９０）の送信した最初のクエリ（９１）はＨＮＳ（８２）まで到達できる。このクエリ（９１）をＦＮＳ（８０）に届けるために、ＨＮＳは次に参照すべきネームサーバとしてＦＮＳのＩＰアドレスを通知することで、corresponding node（９０）に２段目のクエリ（９２）を起こさせる。

すなわち、hom-pan.provider.jpというデバイスにアクセスするために、corresponding nodeはＨＮＳであるprovider.jpのネームサーバ（８２）まで到達する。ＨＮＳ（８２）はデバイスのアドレスを返す代わりに、ＦＮＳ（８０）である現在Ｐ−ＰＡＮが接続しているcomm.univ.jpドメインのネームサーバにアクセスするように促す。このＦＮＳが実際のhom-pan.provider.jpのアドレスをリゾルブする。

図８に示すように、ＩＰレイヤのネームサーバ構成は従来のＤＮＳサーバが混在していてもまったく問題はない。最低限、ホームネットワークのＨＮＳ（８２）とＰ−ＰＡＮ/クラスタ中のＰＮＳ（８１）が存在すればそれだけで動作可能であり、ＦＮＳが介在する仕組みでもＦＮＳが機能付加サーバであればよい。
corresponding nodeは本発明システムをサポートしている必要はない。それは、corresponding nodeから見たとき、ＨＮＳやＦＮＳに対して送信するクエリも、受け取る応答も完全にＤＮＳサーバに対する問い合わせのプロセスと同一であるためである。ＤＮＳとＮＮＳＩＰレイヤの差異は、ＨＮＳ-ＦＮＳ-ＰＮＳ間のアップデートの仕組みと、ＦＮＳ介在時のＨＮＳからＦＮＳへのもう一段のクエリの追加のみである。

本発明の別実施例として、クラスタの管理を行うエージェントサーバを通信システムに備える構成を次に説述する。
図１１はエージェントサーバ（１１０）を備えた通信システムの全体構成図であり、エージェントサーバ（１１０）にはＩＰレイヤにおける通信を行い、エッジサーバ（６０）（６１）を介してＰＮＳ間通信部（３３）（３３’）とも通信可能な通信部（１１１）と、クラスタの記録と、ＰＮＳへの他のクラスタ情報を送信するクラスタ管理部（１１２）、クラスタの情報を格納したクラスタデータベース（１１３）を備える。

図１２は本発明においてエージェントサーバ（１１０）を用いたときのデバイス（４０）の登録におけるメッセージフローである。
上述した通り、デバイス（４０）からＰＮＳ（３０）、エッジサーバ（６０）は１つのクラスタ（２）（３）（４）に設けられており、エッジサーバ（６０）とエージェントサーバ（１１０）間はインターネット等（５）で接続されている。

まず、図５と同様にＰＮＳ（３０）がクラスタ名を広告（５０）すると、デバイスが自アドレスを応答（５１）し、その際に少なくともアドレスを送信する。
次いで、ＰＮレイヤにおけるデバイス名を生成（５２）する。

このようにしてＰＮＳ（３０）のデバイスデータベース（３２）にデバイス名が登録されると、それをＰＮＳがエッジサーバ（６０）に通知し、あるいはエッジサーバ（６０）が定期的にデバイスデータベース（３２）を監視してデバイスの登録を検出し、エッジサーバから該エッジサーバに付与されたＩＰアドレスを各デバイスに対して広告（１２０）する。

このエッジサーバのネットワークアドレスは、クラスタのアドレスを意味しており、各デバイスは、ＩＰレイヤにおいてその指し示すアドレスのクラスタ内のデバイスというように特定することができる。ただし、公開されていなければＰＮレイヤにしか属さないため、外部からのアクセスはＰＮレイヤにアクセス可能なユーザからしか行えないことは上記した通りである。

一方、以上の処理（５０）〜（１２０）に前又は後に、エッジサーバ（６０）のＩＰアドレスがＤＮＳサーバ又は機能付加サーバから付与又は更新（１２１）される。
エッジサーバにＩＰアドレスが付与・更新されたことをＰＮＳ間通信部（３３）で検出したＰＮＳ（３０）は、ユーザ名、クラスタ名、エッジサーバのＩＰアドレスを、エッジサーバ（６０）を介してエージェントサーバ（１１０）に通知（１２２）する。

エージェントサーバの通信部（１１１）がこれを受信し、クラスタ管理部（１１２）において、クラスタデータベース（１１３）に受信した情報をデータベースとして登録する。
そして、クラスタ管理部（１１３）は所定の契機、例えばクラスタデータベース（１１３）の更新時や、所定間隔時に、クラスタデータベース（１１３）に記載された各エッジサーバ（６０）（６１）に向けてユーザ名、クラスタ名、他のエッジサーバのＩＰアドレス等を通信部（１１１）に送出する。

以上の構成により、エッジサーバ（６０）（６１）は互いにＶＰＮ接続を確立することが可能となる。このようにエージェントサーバ（１１０）を設けることにより、エッジサーバ（６０）の一括管理が可能であり、エッジサーバ間から自己のアドレス等を広告する必要がない。

本発明は、以上説述したとおり、２つのレイヤをもつネーミング方式を提案するものであり、これによりセキュリティを確保しながら移動するユーザやデバイスにアクセスする他者に対して好適なネットワーク環境を提供するものである。

本発明に係る通信システムの全体図である。本発明のＩＰレイヤとＰＮレイヤの関係を示す構成図である。ＰＮレイヤに係るＰＮＳとデバイスの構成を示す構成図である。クラスタ内のＰＮＳとデバイスの関係を示す説明図である。クラスタ内のＰＮＳとデバイス間のメッセージフローである。ＰＮレイヤにおけるＰＮＳ間の関係を示す説明図である。ＰＮレイヤにおけるＰＮＳ間のメッセージフローである。ＩＰレイヤのサーバと名前空間の構成を示す全体図である。ＩＰレイヤにおけるサーバ間の関係を示す説明図である。ＩＰレイヤに係るサーバの構成を示す構成図である。本発明にかかるエージェントサーバを用いる通信システムの構成図である。本発明にかかるエージェントサーバを用いる構成におけるメッセージフローである。

符号の説明

１０ＩＰレイヤ
１１インターネット
１２ＨＮＳ
１３ＦＮＳ
１４オフィスクラスタ
１５ホームクラスタ
１６ＦＮＳ
２０ＰＮレイヤ
２１ＰＮＳ

Claims

デバイスに対して、通信ネットワーク上の第１の領域において使用され、デバイスとネットワークアドレスとの対応付けを行う第１のネームシステムレイヤ上のネームと、より限定的な第２の領域において使用される第２のネームシステムレイヤ上のネームとをそれぞれ付与し、第１及び第２の２つのネームシステムレイヤを用いる通信システムにおいて、
両方のネームシステムレイヤにおいて機能するネームサーバ装置を備えて、該ネームサーバ装置が、
第２のネームシステムレイヤでは、場所毎にデバイスの集合として定義されるクラスタ毎に設けられ、クラスタ内の単数又は複数のデバイスから少なくともネットワークアドレスを含むデバイス登録情報を取得し、該クラスタにおけるデバイスとネットワークアドレスとの対応付けリストを記憶すると共に、
第２のネームシステムレイヤ内にある他のクラスタのネームサーバ装置と該対応付けリストを交換するリンクを有して、第２の領域に属するユーザのみに対して該対応付けリストによるデバイスとネットワークアドレスとの変換機能を提供する
ことを特徴とする通信システム。
前記ネームサーバ装置が、他のクラスタのネームサーバ装置と対応付けリストを交換する際に、
前記通信システムに各クラスタのルータとなるエッジサーバ装置を備え、
各クラスタにおいて、
該エッジサーバ装置が該ネームサーバ装置が取得したデバイス登録情報に基づいて、該エッジサーバ装置に付与された第１の領域におけるネットワークアドレスを該デバイスに通知する
ことを特徴とする請求項１に記載の通信システム。
前記通信システムにおいて、
前記エッジサーバ装置間をVPN(Virtual Private Network：仮想私設網）を用いて接続する
ことを特徴とする請求項２に記載の通信システム。
前記通信システムにおいて、
各クラスタのエッジサーバ装置に付与された第１の領域におけるネットワークアドレスを前記デバイス又は、前記ネームサーバ装置、前記エッジサーバ装置の少なくともいずれかから取得し、他のクラスタの少なくともエッジサーバ装置に通知することにより、エッジサーバ装置間でのネットワークアドレスの交換を可能にするエージェントサーバ装置を備えた
ことを特徴とする請求項２又は３に記載の通信システム。
前記第２のネームシステムレイヤにおける各デバイスのネームの一部に、該クラスタのクラスタ名を含む構成において、
各ネームサーバ装置が、他のクラスタのネームサーバ装置に向けて該クラスタ名を広告する
ことを特徴とする請求項１ないし４のいずれかに記載の通信システム。
デバイスに対して、通信ネットワーク上の第１の領域において使用され、デバイスとネットワークアドレスとの対応付けを行う第１のネームシステムレイヤ上のネームと、より限定的な第２の領域において使用される第２のネームシステムレイヤ上のネームとをそれぞれ付与し、第１及び第２の２つのネームシステムレイヤを用いる通信システムにおいて用いるネームサーバ装置であって、
該ネームサーバ装置は、両方のネームシステムレイヤにおいて機能し、
第２のネームシステムレイヤでは、場所毎にデバイスの集合として定義されるクラスタ毎に設けられ、クラスタ内の単数又は複数のデバイスから少なくともネットワークアドレスを含むデバイス登録情報を取得し、該クラスタにおけるデバイスとネットワークアドレスとの対応付けリストを記憶すると共に、
第２のネームシステムレイヤ内にある他のクラスタのネームサーバ装置と該対応付けリストを交換するリンクを有して、第２の領域に属するユーザのみに対して該対応付けリストによるデバイスとネットワークアドレスとの変換機能を提供する
ことを特徴とするネームサーバ装置。
前記第２のネームシステムレイヤにおける各デバイスのネームの一部に、該クラスタのクラスタ名を含む構成において、
各ネームサーバ装置が、他のクラスタのネームサーバ装置に向けて該クラスタ名を広告する
ことを特徴とする請求項６に記載のネームサーバ装置。