1

卒論最終発表 (2004/01/10)「非構造的な名前空間に対応した名前解決機構の研究」

環境情報学部　廣瀬峻（ tuffy@sfc.wide.ad.jp ）

親 . kwkt さん sub 親 . hada さん

04/24/23 卒論最終発表 2

卒論最終発表• 研究背景、問題意識• 本研究における設計• 実装、評価• 今後の課題• まとめ

04/24/23 卒論最終発表 3

研究背景（ 1/2 ）• RFID 技術の進歩、小型化

– 本や缶にタグをつけて一意に識別• Auto-ID ：ネットワーク型 ID システム

– ID がついた製品のメタ情報をネットワーク上に展開– 製品の ID に関する「メタ情報サービス」がどこで提供さ

れるか、の対応付けが必要

情報の場所ID: 1.2.4.200

製造年月日製造工場著者etc

Internet

メタ情報この書籍に関する情報？ 問い合わせID: 1.2.4.200

04/24/23 卒論最終発表 4

研究背景 (2/2)• EPC の構造

96bits

8bitsHeader（バージョン）

28bitsEPC Manager（製造会社）

24bitsObject Class（製品）

36bitsSerial Number（シリアル番号）

01.0000A89.00016F.000169DC0

• ＩＤが構造化され、それ自体が意味を持つ– 一意性の確保– 管理権限の割譲– ID を取得した時点で、プライバシの漏洩の恐れ

• 本研究でのプライバシは、 ID を読み取ることで製品の情報が推測される、あるいは漏洩すること

EPC 1.2.24.400

urn:epc:1.2.24.400

24.2.1

24.2.1.onsroot.org

ONS1.0 での仕様

04/24/23 卒論最終発表 5

非構造的な ID の必要性• 非構造的な ID の必要性

– 非構造的な ID ： UID (Unstructured ID)– ID 自体から情報を取得するのが困難– プライバシを守るための手段として必要

HID

ServiceLocation

Contents

A third party

04/24/23 卒論最終発表 6

本研究における目的• 非構造的な ID から情報の位置を特定するシステムの構築

– 製品に非構造的な ID をつけることで、その製品がなんであるかという情報を隠蔽する– ID を暗号化しておき、名前解決時に複合化という提案

• 複合化にともなうオーバーヘッド• 複合化された ID の盗み見

– DNS を用いるのは困難

新しい名前解決システムの構築

04/24/23 卒論最終発表 7

想定される製品トレースモデル非構造化された ID

ID 12345EPCIS

宅配業者ID 12345

Yokohama

Location: 横浜を追加したい

①ID が 12345 の製品のPML サーバはどこ？

IP addr 　 123.2.3.4

②123.2.3.4 です

③ID 12345 の製品は今横浜にある、という情報の追加ID が非構造化されていることで宅配業者はその製品が何であるか、ということは分からないが、その製品の情報を EPCIS に追加することができる

ONS

04/24/23 卒論最終発表 8

要件• 非構造的な ID を扱う• 耐故障性• 分散処理• ID の一意性

04/24/23 卒論最終発表 9

要件に基づいた問題

ONS resolver

Domain name

1.a89.16f.169dc0

16f.a89.1.autoid.org

EPC3F7CA9507F2664UID

ONS Server

?Query

04/24/23 卒論最終発表 10

非構造的な ID を扱う• ハッシュした ID から階層構造を構成する

– 利点• 負荷分散• 局所性

– 欠点• Single Point of Failure

• 分散ハッシュテーブル(DHT)– ハッシュテーブルを複数のノードで分割統治– 利点

• 負荷分散– 欠点

• 検索の柔軟性

04/24/23 卒論最終発表 11

DHT に関する考察• 利点

– データの保持に際し、データのフォーマット、中身などに依存しない– 耐故障性– 負荷分散

• 欠点– データ検索は完全一致

• ロンゲストマッチなど、柔軟性のある検索には不向き– システム内にあるノードの信頼性

04/24/23 卒論最終発表 12

名前解決機構としての特徴比較DNS DHT

局所性 あり アルゴリズムに依存運用実績 あり なし

各サーバの信頼性

Root に近いほど信頼性 なし耐故障性 ○ アルゴリズムに依存

局所性 あり アルゴリズムに依存負荷分散 ○ ○

非構造的な IDへのサポート × ○

04/24/23 卒論最終発表 13

設計• 場面の限定• 二つのネーミングシステムを想定

– リゾルバで振り分ける– 先頭ビット（ EPC のヘッダあるいはビット長）での振り分け

• EPC は DNS• UID は DHT

API

ONS Resolver

DNS DHT

EPC, UID

Naming System

EPCIS Location

QueryNAPTR RR IP Address

EPC UID

ONS

Application

システム図

04/24/23 卒論最終発表 14

設計

API

ONS Resolver

EPCIS location

UID

UID IPaddr

IPaddr

Node Node Node NodeNode Node Node NodeNode NodeNodeNodeNode join( )

AuthenticationServer

authenticate( )

lookup (UID)register (UID)delete (UID)

分散ハッシュテーブル

04/24/23 卒論最終発表 15

実装（ 1/2 ）• FreeBSD5.1-Realease• C言語• データの保持

– ID が検索キー– SHA-1 アルゴリズムによって生成した UID をもとにデータをマッピング

04/24/23 卒論最終発表 16

実装 (2/2)

メッセージ受信モジュール メッセージ送信モジュール

データ処理モジュール

メッセージの受信 メッセージの送信

ID によるNS 振り分けモジュール

ID の受信

ルーティング処理モジュール

メッセージの交換

メッセージの交換

モジュール図API

ONS Resolver

DNS DHT

EPC, UID

Naming System

EPCIS Location

Query NAPTR RR IP Address

EPC UID

ONS

Application

ユーザによるID の入力

04/24/23 卒論最終発表 17

評価• 目的

– 非構造的な ID と情報サーバの位置情報との対応データを登録し、検索する部分の動作を確認• 評価項目

– データがシステム内のノードに分散して登録できるか– 非構造的な ID を基にサーバの位置情報を検索できるか

• 評価環境– データの登録・検索クライアント– 2台のデータ保持サーバを設置

Client

Server

Server Data

Data

Internet

04/24/23 卒論最終発表 18

• 一つのノードに対してデータ登録を行い、両方のノードにデータが登録できることを確認• 非構造的な ID を検索キーとした検索が行えることを確認• 本機構により、非構造的な ID に対応した名前解決機構の構築可能性を確認した

133.27.4.9

57F4953DA 位置情報HID登録

検索57F4953DA

位置情報HID

サーバ サーバ

データ データ取得133.27.4.9

A035003DCCC2AD6F56475FE1C1B0b0EB2ABE7D

3FCA9507F2E6407EC94DE5F33D11CD2D28BF56B

UID から算出したHID によってデータの登録・検索を行う

ハッシュ空間

クライアント

評価結果

04/24/23 卒論最終発表 19

今後• 実装を行った部分

– データの保持、検索モジュール– Chord を利用した分散ハッシュテーブル

• ノードの故障、ルーティングテーブルの整合性に対するサポートが不十分•未実装の部分

– リゾルバ部

04/24/23 卒論最終発表 20

今後の課題• プロトコルに依存しないシステム

– IPv4,IPv6両方をサポート•規模性の検証• ノードの信頼性

– 性善説から性悪説へ– セキュリティの確保– 認証

• 運用レベルでの問題– ID の発番、管理

04/24/23 卒論最終発表 21

まとめ　非構造化された ID と情報保持サーバとのマッピング機構

– UID からダイレクトに名前解決• プライバシ保護

– 想定利用場面での必要事項に基づいた実装• DHT を用いた名前解決機構の設計、実装• 耐故障性を考慮した分散処理システム

04/24/23 卒論最終発表 22

FIN