JP4682329B2

JP4682329B2 - 通信ネットワークにおけるネームシステム及びネーミング方法

Info

Publication number: JP4682329B2
Application number: JP2006038669A
Authority: JP
Inventors: 誉村上
Original assignee: National Institute of Information and Communications Technology
Current assignee: National Institute of Information and Communications Technology
Priority date: 2006-02-15
Filing date: 2006-02-15
Publication date: 2011-05-11
Anticipated expiration: 2026-02-15
Also published as: US8145771B2; JP2007221396A; US20090222566A1; WO2007094398A1

Description

本発明は通信ネットワークにおけるネームシステム及びネーミング方法に関し、特にユーザが自分のデバイスやデータにアクセス可能なパーソナルネットワークとインターネット環境においてセキュリティを確保したネーミングを実現する技術に係るものである。

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

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

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

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

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

一般に、サービス発見技術はネーミング技術に比べて複雑性が高くなるため、スケーラビリティを確保するのが難しいと言われる。
この２種の技術は排他的なものではなく、組み合わせて使うことでいっそうユーザの利便性を改善できる。例えば、過去の提案技術の中では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（登録商標）などのアクセス方式)を変更しながら、インターネット(もしくはＩＰベースのバックボーンネットワーク)上の接続点を変更していく。このとき、新しい接続点が同一のドメインに所属するとは限らない。ＤＮＳにおいては、デバイスの名前は接続点に依存するため、本質的にデバイスの移動性に追従しているとは言えない。

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

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

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,１９８７年１１月特開２００３−２５８８３２号公報

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

本発明は、上記の課題を解決するために、次のようなネームシステムを提供する。
すなわち、本発明の請求項１に記載の発明は、通信ネットワーク上で、デバイスとネットワークアドレスとの対応付けを行うネームシステムが、他者からのアクセスを許すデバイスのみを登録する第１のネームシステムレイヤを形成すると共に、特定のアクセス権限を有するユーザだけがアクセス可能なデバイスを登録する第２のネームシステムレイヤを形成する。

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

一方、第１のネームシステムレイヤでは、階層的なドメインを構成する機能付加ネームサーバ装置と接続して、該第２のネームシステムレイヤにおける他者からのアクセスを許すデバイスについての該対応付けリストを提供し、該機能付加ネームサーバ装置のデバイス・ネットワークアドレス変換により他者からの当該ドメインに属するデバイス宛のアクセスが到達するようにする。

請求項２に記載のネームシステムは、上記の第１のネームシステムレイヤにおいて、ユーザが所属するホームネットワークのドメインを管理する機能付加ネームサーバ装置であるホームネームサーバ装置と、ユーザが現在位置するクラスタの前記ネームサーバ装置が接続している機能付加ネームサーバ装置である接続先ネームサーバ装置とが異なる場合に、ネームサーバ装置は、接続先ネームサーバ装置に対して他者からのアクセスを許すデバイスについての対応付けリストを提供する。
また、接続先ネームサーバ装置は、該ホームネームサーバ装置に自己のネットワークアドレス及び、該対応付けリストを受け取ったデバイスの情報を送信し、
該ホームネームサーバ装置宛にデバイスへのアクセスがあった時にはホームネームサーバ装置が該接続先ネームサーバ装置のネットワークアドレスを他者に通知することを特徴とする。

請求項３に記載の発明は、上記のデバイス登録情報において、デバイスを第１のネームシステムレイヤにおいて公開するか否かを設定する公開設定フラグと、公開時における該デバイスのデバイス名とを含むことを特徴とする。

本発明は次の通りのネーミング方法を提供することもできる。
すなわち請求項４に記載の発明は、通信ネットワーク上で、デバイスとネットワークアドレスとの対応付けを行うネーミング方法が、他者からのアクセスを許すデバイスのみを登録する第１のネームシステムレイヤを形成すると共に、特定のアクセス権限を有するユーザだけがアクセス可能なデバイスを登録する第２のネームシステムレイヤを形成する。

そして、両方のネームシステムレイヤにおいて機能するネームサーバ装置が、第２のネームシステムレイヤでは、場所毎にデバイスの集合として定義されるクラスタ毎に設けられ、クラスタ内の単数又は複数のデバイスから少なくともデバイスの種類とネットワークアドレスとを含むデバイス登録情報を取得し、該クラスタにおけるデバイスとアドレスとの対応付けリストを記憶するステップ、第２のネームシステムレイヤ内にある他のクラスタのネームサーバ装置と該対応付けリストを交換して特定のアクセス権限を有するユーザがいずれのクラスタのデバイスにもアクセスできるようにするステップ、第１のネームシステムレイヤでは、階層的なドメインを構成する機能付加ネームサーバ装置と接続して、該第２のネームシステムレイヤにおける他者からのアクセスを許すデバイスについての該対応付けリストを提供するステップ、該機能付加ネームサーバ装置のデバイス・ネットワークアドレス変換により他者からの当該ドメインに属するデバイス宛のアクセスが到達するようにするステップの各ステップを有する。

請求項５に記載の発明は、上記の第１のネームシステムレイヤにおいて、ユーザが所属するホームネットワークのドメインを管理する機能付加ネームサーバ装置であるホームネームサーバ装置と、ユーザが現在位置するクラスタの前記ネームサーバ装置が接続している機能付加ネームサーバ装置である接続先ネームサーバ装置とが異なる場合に、該ネームサーバ装置は、接続先ネームサーバ装置に対して他者からのアクセスを許すデバイスについての対応付けリストを提供するステップ、該接続先ネームサーバ装置は、該ホームネームサーバ装置に自己のネットワークアドレス及び、該対応付けリストを受け取ったデバイスの情報を送信し、
該ホームネームサーバ装置宛にデバイスへのアクセスがあった時にはホームネームサーバ装置が該接続先ネームサーバ装置のネットワークアドレスを他者に通知するステップを有する。

請求項６に記載の発明は、上記のデバイス登録情報において、該デバイスを第１のネームシステムレイヤにおいて公開するか否かを設定する公開設定フラグと、公開時における該デバイスのデバイス名とを含むことを特徴とする。

本発明は、上記構成を備えることにより次のような効果を奏する。
すなわち、請求項１および４に記載の発明によれば、２つのネームシステムレイヤを用いることで、プライベートな名前空間と、パブリックな名前空間を分離することができ、前者の名前空間のアドレスが他者に公開されることがない。
これにより、デバイスの情報を開示せず、他者からの不正なアクセスを防止することができる。

請求項２及び５に記載の発明によれば、移動先のクラスタのネームサーバ装置が、その接続先ネームサーバ装置に対して対応付けリストを提供し、接続先ネームサーバ装置とホームネームサーバ装置とが連携動作することにより、ユーザの移動に対応したネーミング技術を提供することができる。

請求項３及び６に記載の発明によれば、デバイス登録情報に公開設定フラグと、公開時における該デバイスのデバイス名とを含むことで簡便に第１のネームシステムレイヤにおける公開情報を設定することができる。

以下、本発明の実施形態を、図面に示す実施例を基に説明する。なお、実施形態は下記に限定されるものではない。
まず、図１を用いて本発明におけるパーソナルネットワーク（ＰＮ）と、クラスタ、さらにＰ−ＰＡＮ（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)パケットを送信（５１）する。

この登録パケットには、(1)デバイスの種類(device_type）と(2)ＩＰアドレス（address）が含まれていなくてはならない。また、ユーザがそのデバイスを他者に対して公開したい場合は(3)デバイス公開フラグ（public_flag）を、また多数のデバイスがネットワークにつながるので、デバイスの名前は自動付与されるのが利便性の点で好ましいが、ユーザが任意の名前を付与したい場合は(4)デバイス名（device_name）を明示しても良い。(1)(2)は必須であり、(3)(4)はオプションであるが、(3)の公開フラグがonの場合は、デバイス名の一意性を確保するために(4)のデバイス名の設定も必須となる。

このような手順で、ＰＮＳ（３０）はそのＰ−ＰＡＮ/クラスタ中の全てのデバイス（４０）について情報を得、デバイスデータベース（３２）に格納する。
得た情報のうち、(4)の任意の名前が設定されていないデバイスに対しては名前の自動生成（５２）を行うこともできる。収集した(1)デバイスの種類の情報と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を付加して送信する。
その際、ＰＮＳ間はインターネットと接続するためのedge（６０）（６１）間でＶＰＮ接続（６２）を確立し、セキュアな通信を可能にする。

このブロードキャストを受け取った他のＰＮＳのＰＮＳ間通信部（３３’）は、受け取った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

通信ネットワーク上で、デバイスとネットワークアドレスとの対応付けを行うネームシステムが、他者からのアクセスを許すデバイスのみを登録する第１のネームシステムレイヤを形成すると共に、特定のアクセス権限を有するユーザだけがアクセス可能なデバイスを登録する第２のネームシステムレイヤを形成する構成であって、
両方のネームシステムレイヤにおいて機能するネームサーバ装置が、
第２のネームシステムレイヤでは、場所毎にデバイスの集合として定義されるクラスタ毎に設けられ、クラスタ内の単数又は複数のデバイスから少なくともデバイスの種類とネットワークアドレスとを含むデバイス登録情報を取得し、該クラスタにおけるデバイスとアドレスとの対応付けリストを記憶すると共に、
第２のネームシステムレイヤ内にある他のクラスタのネームサーバ装置と該対応付けリストを交換するリンクを有して特定のアクセス権限を有するユーザがいずれのクラスタのデバイスにもアクセスできるようにする一方、
第１のネームシステムレイヤでは、階層的なドメインを構成する機能付加ネームサーバ装置と接続して、該第２のネームシステムレイヤにおける他者からのアクセスを許すデバイスについての該対応付けリストを提供し、
該機能付加ネームサーバ装置のデバイス・ネットワークアドレス変換により他者からの当該ドメインに属するデバイス宛のアクセスが到達するようにした
ことを特徴とする通信ネットワークにおけるネームシステム。
前記第１のネームシステムレイヤにおいて、ユーザが所属するホームネットワークのドメインを管理する機能付加ネームサーバ装置であるホームネームサーバ装置と、ユーザが現在位置するクラスタの前記ネームサーバ装置が接続している機能付加ネームサーバ装置である接続先ネームサーバ装置とが異なる場合に、
該ネームサーバ装置は、接続先ネームサーバ装置に対して他者からのアクセスを許すデバイスについての対応付けリストを提供すると共に、
該接続先ネームサーバ装置は、該ホームネームサーバ装置に自己のネットワークアドレス及び、該対応付けリストを受け取ったデバイスの情報を送信し、
該ホームネームサーバ装置宛にデバイスへのアクセスがあった時にはホームネームサーバ装置が該接続先ネームサーバ装置のネットワークアドレスを他者に通知する
請求項１に記載の通信ネットワークにおけるネームシステム。
前記デバイス登録情報において、
該デバイスを第１のネームシステムレイヤにおいて公開するか否かを設定する公開設定フラグと、公開時における該デバイスのデバイス名とを含む
請求項１又は２に記載の通信ネットワークにおけるネームシステム。
通信ネットワーク上で、デバイスとネットワークアドレスとの対応付けを行うネーミング方法が、他者からのアクセスを許すデバイスのみを登録する第１のネームシステムレイヤを形成すると共に、特定のアクセス権限を有するユーザだけがアクセス可能なデバイスを登録する第２のネームシステムレイヤを形成する構成であって、
両方のネームシステムレイヤにおいて機能するネームサーバ装置が、
第２のネームシステムレイヤでは、場所毎にデバイスの集合として定義されるクラスタ毎に設けられ、クラスタ内の単数又は複数のデバイスから少なくともデバイスの種類とネットワークアドレスとを含むデバイス登録情報を取得し、該クラスタにおけるデバイスとアドレスとの対応付けリストを記憶するステップ、
第２のネームシステムレイヤ内にある他のクラスタのネームサーバ装置と該対応付けリストを交換して特定のアクセス権限を有するユーザがいずれのクラスタのデバイスにもアクセスできるようにするステップ、
第１のネームシステムレイヤでは、階層的なドメインを構成する機能付加ネームサーバ装置と接続して、該第２のネームシステムレイヤにおける他者からのアクセスを許すデバイスについての該対応付けリストを提供するステップ、
該機能付加ネームサーバ装置のデバイス・ネットワークアドレス変換により他者からの当該ドメインに属するデバイス宛のアクセスが到達するようにするステップ
の各ステップを有することを特徴とする通信ネットワークにおけるネーミング方法。
前記第１のネームシステムレイヤにおいて、ユーザが所属するホームネットワークのドメインを管理する機能付加ネームサーバ装置であるホームネームサーバ装置と、ユーザが現在位置するクラスタの前記ネームサーバ装置が接続している機能付加ネームサーバ装置である接続先ネームサーバ装置とが異なる場合に、
該ネームサーバ装置は、接続先ネームサーバ装置に対して他者からのアクセスを許すデバイスについての対応付けリストを提供するステップ、
該接続先ネームサーバ装置は、該ホームネームサーバ装置に自己のネットワークアドレス及び、該対応付けリストを受け取ったデバイスの情報を送信し、
該ホームネームサーバ装置宛にデバイスへのアクセスがあった時にはホームネームサーバ装置が該接続先ネームサーバ装置のネットワークアドレスを他者に通知するステップを有する
請求項４に記載の通信ネットワークにおけるネーミング方法。
前記デバイス登録情報において、
該デバイスを第１のネームシステムレイヤにおいて公開するか否かを設定する公開設定フラグと、公開時における該デバイスのデバイス名とを含む
請求項４又は５に記載の通信ネットワークにおけるネーミング方法。