平成17年度
ＪＧＮⅡ研究開発プロジェクト（拠点研究）

研 究 開 発 報 告 書

平成１８年３月

独立行政法人 情報通信研究機構

はじめに研究開発テストベッドネットワーク JGNⅡは、独立行政法人情報通信研究機構（NICT：
National Institute of Information and Communications Technology）により構築・運用されているオープンな超高速・高機能研究開発テストベッドネットワークである。平成 11年度から 15 年度まで運用された研究開発用ギガビットネットワーク JGN(Japan Gigabit
Network)は、わが国のブロードバンドの進展、インターネットの IPv6 化などを支えるために、産学官連携のもと、日本全国で超高速ネットワーク技術や高度アプリケーション技術などに関する研究開発を促進し、多くの成果を残してきた。この後継として、NICT では、
平成 16 年 4 月、政府 IT 戦略本部策定の「e-Japan 戦略Ⅱ」（平成 15 年 7 月）を受け、情報通信の高度化を持続的に推進していくため、JGN を発展させた新たな研究開発テストベッド
ネットワークとして、JGNⅡの運用を開始した。さらに同「e-Japan 戦略Ⅱ」では、ユビキ
タスネットワーク社会実現のために、研究開発用テストベッドネットワークを活用して、(I)高信頼コアネットワーク技術 (II)アクセス系ネットワーク技術 (III)拠点連携型資源共有技術(IV)プラットフォーム・アプリケーション技術、の４つの重点領域に関する先導的な研究開発を早急に実施する必要性を指摘している。これらの背景から、NICT では、平成 16 年 4 月より、JGNⅡ研究開発プロジェクトを開始した。本プロジェクトで実施する研究開発は、アクセスポイントから接続する一般の大学・研究機関による研究、共同利用型研究開発施設の利用者による研究、情報通信研究機構が自ら全国７箇所の JGNⅡリサーチセ
ンターにおいて実施する拠点研究に分類される。本報告書は、このうち拠点研究として平成 17 年度に実施された内容に関して報告するものである。
拠点研究においては、前述の４つの重点技術領域をコアテーマとして、ユビキタスネッ
トワーク時代に向けたネットワーク関連技術の一層の高度化・相互接続性確保や多彩なア
プリケーションの創出に資するために、次世代高機能ネットワーク基盤技術・利活用技術
に関する先導的研究開発を、１１名の拠点研究員と７９名の特別研究員を中心に、産学連
携や国際連携にも配慮しながら実施している。今年度は、初年度の活動を順調に進展させ、各リサーチセンターの特色を生かしながら、本プロジェクトの今後の研究の方向性を確立しつつあると言える、順調な研究進捗となっている。また、研究成果の公開や産学官の研究者の連携・交流のために、昨年度に引き続き、JGNⅡシンポジウムや JGNⅡワークショッ
プを開催し、好評であった。本報告書の内容が JGNⅡを利用して研究開発を進める研究者・技術者をはじめとしてネットワーク研究、プロトコル研究、アプリケーション研究等の関係者にとって参考になれば幸いである。
JGNⅡ研究開発プロジェクト
総括責任者

尾家

（九州工業大学祐二
教授）

平成１７年度 JGNⅡ研究開発プロジェクト（拠点研究）研究開発報告書
目

次

はじめに
第１章

全体概要 ····························································· 1

１．１

研究の背景 ··························································· 1

１．２

JGNⅡ ································································ 1

１．３

拠点研究の目的························································ 3

１．４

プロジェクト推進体制·················································· 5

１．５

研究テーマ ··························································· 8

１．６

各リサーチセンターの特色と活動······································· 12

１．７ JGNⅡ主催研究発表会等················································ 25
第２章

高信頼コアネットワーク技術に関する研究開発··························· 31

２．１

概要 ································································ 31

２．２ IRIDES ネットワークアーキテクチャの研究開発 ·························· 33
２．３

ネットワーク構築運用支援ツール群の研究開発··························· 57

２．４

広域高信頼ネットワーク接続性提供技術の研究開発······················· 83

２．５ IPv6 機器検証評価手法とツールの研究開発 ······························ 90
２．６

次世代インターネット相互接続性検証の研究開発························· 98

２．７

GMPLS ネットワーク運用・管理技術の研究開発 ·························· 113

第３章

アクセス系ネットワーク技術に関する研究開発·························· 129

３．１

概要 ······························································· 129

３．２

ネットワーク計測に基づく適応経路制御技術の研究開発 ·················· 131３．３

品質を考慮したシームレスな資源利用・割当て制御技術の研究開発 ········ 145

３．４

多様性・可変性に適応する E2E 通信制御技術の研究開発 ·················· 164

第４章

拠点連携型資源共有技術に関する研究開発······························ 181

４．１

概要 ······························································· 181

４．２

拠点連携のためのセキュアな資源共有技術の研究開発 ···················· 185

４．３

広域ネットワークにおける大規模データ処理連携技術の研究開発 ·········· 199

第５章

プラットフォーム・アプリケーション技術に関する研究開発·············· 217

５．１

概要 ······························································· 217

５．２

アプリケーション指向型運用管理プラットフォーム技術の研究開発 ········ 219

５．３

サラウンディング・コンピューティング技術の研究開発 ·················· 259

５．４

高度 HCI 技術を活用した適応型サービス制御の研究開発 ·················· 274

第1章
全

体

概

要

第1章 全体概要
1.1

研究の背景

現在の IT 革命の持続的発展を維持するためには、基盤となるネットワーク関連技術の一層の高度化や、多彩なアプリケーションの実現が重要であり、これらに対応できる新たな機能を備えた次世代の研究開発ネットワークを構築、活用することにより、豊かな IT 社会の実現が加速されることが期待されており、「e-Japan 戦略Ⅱ(平成 15 年 7 月 IT 戦略本部決定)」においても、研究開発テストベッドネットワークの整備が掲げられ、現在、次世代の研究開発ネットワークとして JGNⅡが整備されたところである。
これらの動きを受け、平成 15 年 7 月に総務省でとりまとめられた「『ユビキタスネットワ
ーク時代に向けた次世代研究開発ネットワークの在り方に関する調査研究会』報告書」では、次世代の研究開発ネットワークの構築とともに、これを利用して以下の 4 つの重点テーマに関する先導的な研究開発を行うことの必要性が取り上げられている。本プロジェクトは、この提言に基づき、これらの研究開発を実施するものである。
I.

高信頼コアネットワーク技術に関する研究開発

II.

アクセス系ネットワーク技術に関する研究開発

III. 拠点連携型資源共有技術に関する研究開発IV.

プラットフォーム・アプリケーション技術に関する研究開発

これらのテーマの内容は１．５節で述べるが、４つの技術が一体となってはじめて、ユビ
キタス時代に向けた、高度ＩＴ化の持続的浸透と応用の加速を実現する多彩なアプリケーシ
ョンやサービスを支える基盤となりうるという点が重要である。
1.2

JGNⅡ

JGNⅡは、独立行政法人情報通信研究機構（NICT：National Institute of Information andCommunications Technology）により構築・運用されているオープンな超高速・高機能研究
開発テストベッドネットワークである。平成 11 年度から 15 年度まで運用された研究開発用
ギガビットネットワーク JGN（Japan Gigabit Network）は、わが国のブロードバンドの進展、インターネットの IPv6 化など産学官連携のもと、日本全国で超高速ネットワーク技術や高度アプリケーション技術をはじめとする研究開発が活発に行われ、多くの成果を残してきた。この後継として、NICT では、平成 16 年 4 月、政府 IT 戦略本部策定の「e-Japan 戦略Ⅱ」（平成 15 年 7 月）を受け、情報通信の高度化を推進していくため、JGN を発展させた新
たな研究開発テストベッドネットワークとして、JGNⅡの運用を開始した。
1.2.1

JGNⅡの概要と特徴

JGNⅡは、全国規模の光（光波長ネットワーク、光テストベッド）とＩＰ（Ethernet ベース）を基本としたネットワークで全国の大学や研究機関、民間企業、地方自治体などの研究

1-1-

者に広くオープンに研究環境を提供している。さらに、平成 16 年 8 月からは、日米回線（10Gbps）を整備し、海外の研究機関とも連携して研究活動の推進を計っている。平成 17
年度は、アジアへの展開として 11 月にタイ・シンガポールとの回線を整備し運用を開始すると共に、光関連の研究開発促進のために、秋葉原に新たなアクセスポイントを設置（全国
64 箇所のアクセスポイント）、10Gbps の高速回線と光テストベッドを整備した。アクセスポ
イントは、各都道府県に設置されており、利用者はアクセスポイントまでの接続回線を確保
し使用目的が研究開発であれば、NICT に利用申請し、共同研究契約を締結することにより誰でも利用可能である。コアネットワーク構成およびネットワーク構成は、図 1.2.1、図1.2.2 に示す。

NW -A : NW運用管理技術の研究開発

金沢

福岡

大 手町
10G (1G× 8)

堂島

札幌
GM PLS相互接続技術

産 学IT北 九州
福岡

金沢
堂島

岡山

N IC T鹿島

当初10Gベ ー ス

N IC T
けいは んな1G

つ くば

NW -B : テラ ビ ットクラ ス実現のためのテストベ ッド

仙台
N IC T産学 IT北九 州
福岡

10G

10G
(1G× 8)金沢
N IC T神戸
10G

10G

1G

堂島

岡山
高知
1G

10G
(1G× 8)

1G

光

10G

1G

名 古屋

10G

長野
10G
(1G× 8)10G

N IC T
小 金井本 部

10G× 2N IC T鹿島

1G

10G
10G
光

大 手町

つ くば
大手町 つ くば

堂島
小金井

N IC T
けいは んなN IC Tけ い は んな
沖縄

秋葉原

1

光 NW : 物理的な検証も可能な光テストベ ッド

図 1.2.1 JGNⅡコアネットワーク構成

2-2-

[凡 例 ]

20Gb ps
10Gb ps
1Gb ps
光 テスト ベ ッド
全 国都道 府県の アク セスポ イ ント
コ アネ ット ワ ー ク 拠点
(ア ク セスポ イ ント と しても 利 用可能）

北陸

北海道

< １ ０ G>・ 北陸基 幹通信 網構成 拠点（ 金 沢市）・ い しかわクリ エ イトラ ボ（ 石川県能美市）< １ ０ ０M >・ ( 株) 富山県総 合情報セ ンター（ 富山市）
・ 福井県 情報ス ー パー ハイウ ェ イAP * （ 福井 市）< １ G>
・ 北海道 基幹通 信網構 成拠点（ 札幌 市）・ NPO 法人北海道 地域ネ ッ トワ ー ク協 議会（ 札幌市）

東北

札幌

近畿
中国
< １ ０ G>・ 中国基 幹通信 網構成 拠点（ 岡山市）< １ G>
・ テ レポ ー ト 岡山
（ 岡山市）
・ 広島大 学( 広島県東広島 市)< １ ０ ０M >・ 鳥取環境大学( 鳥取市)・ テクノ アー ク しま ね
（ 松江市）・ ニ ュー メ デ ィ ア プラザ 山口（ 山口市）

九州< １ ０ G>・ 九州基 幹通信 網構成 拠 ( 福岡市)
・ Ｎ ＩＣ Ｔ 北九州 ＩＴ研 究開発
支援セ ンタ ー ( 福岡 県北九 州市)
・ 九州大学( 福岡 市)< １ ０ ０M >・ Ne tCo m さ が（ 佐賀市）
・ 長崎大 学( 長崎 市)・ 熊本県 庁
( 熊本市)
・ 豊の国 ハイパ ー ネ ッ トワ ー ク AP *（ 大分市）
・ 宮崎大 学( 宮崎市)
・ 鹿児島 大学( 鹿児島市)< １ ０ G>・ 近畿基 幹通信 網構成 拠点(大阪 市)・ NI CTけ い はん な 情報通 信融合セ ンター( 京都府精 華町)
・ 京都大学( 京都市)
・ 大阪大 学( 大阪府茨木市)< １ G>
・ NICT関西 先端研 究セ ンタ ー
( 神戸市)< １ ０ ０M >・ び わ湖情 報ハ イウ ェ イA P *（ 大津市）
・ 奈良県 工業技 術セ ンター（ 奈良市）・ 和歌山 大学
( 和歌山市)・ 兵庫県 西播磨 総合庁 舎（ 兵庫県上郡 町）

NICT北九州
福 岡 IT研究開発支援
セン ター

信越
< １ Ｇ>
・ 信越基 幹通信 網構成 拠点( 長 野市)< １ ０ ０M >・ 新潟大 学( 新潟 市)・ まつ も と 情報 創造館（ 長野県 松本市）

タ イ バンコク

長野

岡山< １ Ｇ>
・ 沖縄基 幹通信 網構成 拠点 （ 那覇市）

四国

シ ンガ ポ ー ル

NICT
小金井本部

NICTけ い はん な
情報通信融合研究
セン ター

名 古屋

NICT
つ くばRC

大 手町

東海< １ Ｇ>
・ 四国基 幹通信 網構成 拠点 （ 高知市）
< １ ０ ０M >・ 香川県 新規産 業創出 支援セ ン ター
（ 高松 市）・ 徳島大 学( 徳島市)
・ 愛媛大 学( 松山市)
・ 高知工 科大学 ( 高知 県土佐 山田町)

< １ Ｇ>
・ 東海基 幹通信 網構成 拠点( 名古屋市)< １ ０ ０M >・ 名古屋 大学
( 名古 屋市)
・ 静岡県 立大学
( 静岡市)
・ ソフト ピ ア ジャパ ン（ 岐阜県大垣市）
・ 三重県 立看護 大学( 津市)< 1 ０ G>・ 関東基 幹通信 網構成 拠点Ａ
・ 関東基 幹通信 網構成 拠点Ｂ
・ Ｎ ＩＣ Ｔ 小金井 本部
・ Ｎ ＩＣ Ｔつ く ばJG NⅡリ サ ー チ セ ンター( 東京都千 代田区)
( 東京都 千代田 区)( 東京都小 金井市)

( 茨城 県つ くば 市)
・ 秋葉原ダ イビ ル
（ 東京 都千代 田区）
・ 東京大 学( 東京都文京区)
・ NI CT鹿島 宇宙通 信研究セ ンター( 茨城県 鹿嶋市)
< 1 G>・ ( 株) 横須賀ﾃﾚｺ ﾑﾘ ｻｰ ﾁﾊﾟ ｰｸ（ 神奈 川県横 須賀市）
< 1 0 0 M>
・ 宇都宮 大学
( 宇都宮市)・ 群馬産 業技術セ ンター（ 前橋市）
・ 麗澤大 学( 千葉県柏市)
・ NI CT本庄 情報通 信研究 開発支 援セ ンタ ー
（ 埼玉県本庄市）
・ 山梨県 開放型 研究開 発セ ンター（ 山梨県 玉穂町）

* IX:Internet eXchange

AP:Access Point

図 1.2.2 JGNⅡネットワーク構成
主要なネットワークは、最大 20Gbps（10Gbps×2）に高速化を計っており、特定の区間には、光波長に関する GMPLS（Generalized Multiprotocol Label Switching）ルータや OXC（Optical Cross Connect）装置を設置し、更に光テストベッド環境を併せて整備していることから、多様な実証実験が可能なテストベッドネットワークとなっている。
1.2.2

利用可能なサービス

JGNⅡでは、次のサービスを提供しています。
○ Ethernet 接続（L2）サービス○ IP 接続（L3）サービス（IPv4/IPv6 デュアルスタック）○ OXC 接続サービス（特定のアクセスポイントで利用可能）○ 10G 接続サービス（特定のアクセスポイントで利用可能）○ 光テストベッドサービス（特定のアクセスポイントで利用可能）
1.3

拠点研究の目的

ＪＧＮⅡでは、東北 JGNⅡリサーチセンター、大手町 JGNⅡリサーチセンター、つくば JGN
Ⅱリサーチセンター、大阪 JGNⅡリサーチセンター、岡山 JGNⅡリサーチセンター、高知 JGN
Ⅱリサーチセンター、北九州 JGNⅡリサーチセンターの計７ヶ所に NICT が自ら研究開発を

3
-3-

US A

関東

高知

沖縄

ア メリカ シカゴ

仙台

金沢

大阪

那覇

< １0 G>・ 東北基 幹通信 網構成 拠点( 仙台市)< １ G>
・ 東北大 学( 仙台市)・ NI CT岩手 IT研 究開発 支援セ ン タ ー（ 岩手県 滝沢村）
< １ ０ ０M >・ 八戸工業大学( 青森 県八戸 市)
・ 秋田地 域IX *（ 秋田 市）・ 慶応義 塾大学 鶴岡キ ャ ンパス( 山形県 鶴岡市)
・ 会津大 学( 福 島県会 津若松 市)

実施するリサーチセンターを設置している。設置場所を、図 1.3.1 に示す。
これらのリサーチセンターで実施される拠点研究は、その性格上、民間では実施が困難な、より先に視点を置いた国際レベルの研究を意図し、ユビキタスネットワーク時代に向けたネットワーク関連技術の一層の高度化・相互接続性確保や多彩なアプリケーションの創出に資するため、超高速・高機能なテストベッドネットワークを基盤とする研究開発環境を国内外に段階的に構築し、次世代高機能ネットワーク基盤技術・利活用技術に関する先導的研究開発をおこなっている。
これらのリサーチセンターを各地に設置するにあたっては、JGN で培われた研究コミュニティーや資産の有効活用も考慮しながら、以下の点を重要視した。一つは、各研究テーマに合わせて、それに関する技術分野に強みを持ち日本での研究開発のリーダシップを取っているような特定の研究組織（大学や企業等）の近くに設置することで、それらとの密着した連携を可能にし、効率的な研究開発を実現できるようにすることである。もう一つは、日本各地に分散したリサーチセンターが JGNⅡで接続されることで、リサーチセンター間の連携によって、容易に広域分散実験環境を構築できるようにすることである。このように、リサー
チセンターは、各地域の特徴を生かした産学官共同研究によって研究開発を効率よく進め、さらにリサーチセンター間の連携によって JGNⅡを有効に使った共同研究や実証実験を実施することを狙っている。

■JGNⅡリサーチセンター (全国に7箇所）
【宮城
【宮城県】
県】
東東北JGNⅡリ
北JGNⅡリササーチ
ーチセンタ
センターー

【岡山
【岡山県】
県】
岡岡山JGNⅡリ山JGNⅡリササーチ
ーチセンタ
センターー
・次世代イン ターネット相互接続性検証
・次世代イン ターネット相互接続性検証
の研究開発
の研究開発

【福岡
【福岡県】
県】
北北九州JGN
九州JGNⅡリサ
Ⅱリサーーチセンタ
チセンターー・アプ リケーショ ン指向型運用管理
・アプ リケーショ ン指向型運用管理
プラ ットフォ ーム技術の研究開発
プラ ットフォ ーム技術の研究開発

【茨城
【茨城県】
県】
つつくくばJGN
ばJGNⅡリサ
Ⅱリサーチ
ーチセンタ
センターー

・ネットワ ーク計測に 基づ く適応経路制御
・ネットワ ーク計測に 基づ く適応経路制御技術の研究開発
技術の研究開発
・品質を 考慮したシームレスな資源利用・・品質を 考慮したシームレスな資源利用・割当て制御技術の研究開発
割当て制御技術の研究開発
・多様性・可変性に 適応する E2E通信・多様性・可変性に 適応する E2E通信制御技術の研究開発
制御技術の研究開発

・高度HCI技術を 活用した適応型
・高度HCI技術を 活用した適応型
サービ ス制御の研究開発
サービ ス制御の研究開発
・GMPLSネットワ ーク運用・管理
・GMPLSネットワ ーク運用・管理技術の研究開発
技術の研究開発

【東京
【東京都】
都】
大大手町JGN
手町JGNⅡリサ
Ⅱリサーチセンタ
ーチセンターー
【高知
【高知県】
県】
高高知JGNⅡリ
知JGNⅡリササーチ
ーチセンタ
センターー
・サラ ウン ディング ・コンピュ ーティング・サラ ウン ディング ・コンピュ ーティング
技術の研究開発
技術の研究開発

【大阪
【大阪府】
府】
大大阪JGNⅡリ阪JGNⅡリササーチ
ーチセンタ
センターー
・拠点連携のためのセキュ アな資源共・拠点連携のためのセキュ アな資源共有技術の研究開発
有技術の研究開発
・広域ネットワ ークに お ける 大規模データ
・広域ネットワ ークに お ける 大規模データ処理連携技術の研究開発
処理連携技術の研究開発

・ネットワ ーク構築運用支援ツ ール群・ネットワ ーク構築運用支援ツ ール群
の研究開発
の研究開発
・広域高信頼ネットワ ーク接続性提供
・広域高信頼ネットワ ーク接続性提供
技術の研究開発
技術の研究開発
・IP v6機器検証評価手法とツ ールの・IP v6機器検証評価手法とツ ールの
研究開発
研究開発
15

図 1.3.1 JGNⅡの研究開発拠点

4
-4-

1.4

プロジェクト推進体制

研究開発は、先に述べた研究開発テストベッドネットワーク JGNⅡによって接続された拠点研究開発のための各拠点で実施する。各拠点では、ネットワーク関連技術の一層の高度化や多彩なアプリケーションの開発など、基礎的・基盤的な研究開発から実証実験までを実施する。拠点研究員は平成１７年度末において１１名（北九州とつくばに各３名、大阪２名、大手町と岡山及び東北に各１名）、特別研究員７９名、各々の専門分野の観点から各研究グ
ループに助言を与えると共に共同研究も実施する。また、研究テーマの内容および進捗に応じて、外部機関との共同研究も積極的に推進して、より広い視野から研究成果が得られる体制を構築している。
以下に、本プロジェクトの研究開発体制を示す。
総括責任者：尾家 祐二（九州工業大学教授 情報科学ｾﾝﾀｰ長）

副総括責任者：江﨑 浩 （東京大学情報理工学系研究科教授）

同：下條 真司（大阪大学教授 ｻｲﾊﾞｰﾒﾃﾞｨｱｾﾝﾀｰ長）

同：曽根 秀昭（東北大学教授 情報ｼﾅｼﾞｰｾﾝﾀｰ副ｾﾝﾀｰ長）

同：古賀 達蔵（つくば JGNⅡリサーチセンター長）

同：小林 和真（倉敷芸術科学大学産業科学技術学部教授）

同：福本 昌弘（高知工科大学情報ｼｽﾃﾑ工学科助教授）

主席拠点研究員 ：鶴 正人 （九州工業大学情報工学部助教授）
同：馬場 健一（大阪大学大学院情報科学研究科助教授）

拠点研究員：増田 尚則（東北 JGNⅡリサーチセンター）

同：奥中 淳三（つくば JGNⅡリサーチセンター）

同：岡本 修一（つくば JGNⅡリサーチセンター）

同：岡野 介英（つくば JGNⅡリサーチセンター）

同：山森 雅文（大手町 JGNⅡリサーチセンター）

同：野呂 正明（大阪 JGNⅡリサーチセンター）

同：長谷川一郎（大阪 JGNⅡリサーチセンター）

同：美甘 幸路（岡山 JGNⅡリサーチセンター）

同：熊副 和美（北九州 JGNⅡリサーチセンター）同：北辻 佳憲（北九州 JGNⅡリサーチセンター）

同：古閑 宏幸（北九州 JGNⅡリサーチセンター）

特別研究員：白鳥 則郎（東北大学電気通信研究所教授）

同：菅沼拓夫（東北大学電気通信研究所助教授）

同：北形 元 （東北大学電気通信研究所助手）

同

：木下

同

：阿部 亨 （東北大学情報シナジーセンター助教授）

哲男（東北大学情報シナジーセンター教授）

5
-5-

同

：脇山俊一郎（仙台電波工業高等専門学校情報通信工学科教授）

同：菅野浩徳（仙台電波工業高等専門学校情報通信工学科助教授）

同

：キニ

グレン

同

：菅原

研次（千葉工業大学情報科学部教授）

同：柴田 義孝（岩手県立大学ｿﾌﾄｳｪｱ情報学部教授）

同：橋本 浩二（岩手県立大学ｿﾌﾄｳｪｱ情報学部助教授）

同：岩田洋夫（筑波大学システム情報工学研究科教授）同：大田友一（筑波大学システム情報工学研究科教授）同：亀田壽夫（筑波大学システム情報工学研究科教授）

同：山海嘉之（筑波大学システム情報工学研究科教授）同：葛岡英明（筑波大学システム情報工学研究科助教授）

同：小木哲朗（筑波大学システム情報工学研究科助教授）

同：木村

成伴（筑波大学システム情報工学研究科助教授）

同：宗像

恒次（筑波大学人間総合科学研究科教授）

同：橋本佐由理（筑波大学人間総合科学研究科助教授）

同

：須田

同

：工藤 知宏（産業技術総合研究所ｸﾞﾘｯﾄﾞ研究ｾﾝﾀｰｸﾗｽﾀ技術ﾁｰﾑ長）

同

：織田

同

：森川 治 （産業技術総合研究所主任研究員）

同：小田部文彦（つくばマルチメディア代表取締役）

同：高田俊和（日本電気基礎・環境研究所主席研究員）

同：佐藤一雄（防災科学技術研究所総括主任研究員）

同：大谷 朋広（KDDI 研究所統合ｺｱﾈｯﾄﾜｰｸ制御ｸﾞﾙｰﾌﾟ ｸﾞﾙｰﾌﾟﾘｰﾀﾞｰ）

同：鮫島 康則（NTT 未来ねっと研究所主任研究員）

同：大原 拓也（NTT 未来ねっと研究所ﾌｫﾄﾆｯｸﾄﾗﾝｽﾎﾟｰﾄﾈｯﾄﾜｰｸ研究部）

同：小野澤 晃（NTT ﾏｲｸﾛｼｽﾃﾑｲﾝﾃｸﾞﾚｰｼｮﾝ研究所主幹研究員）

同：藤原 和弘（NTT ｺﾐｭﾆｹｰｼｮﾝｽﾞ先端 IP ｱｰｷﾃｸﾁｬｾﾝﾀ）同：田中 崇彦（NTT ｺﾐｭﾆｹｰｼｮﾝｽﾞﾌﾟﾗｯﾄﾌｫｰﾑｻｰﾋﾞｽ部）

同

：金海

同

：月岡 陽一（日立製作所ﾈｯﾄﾜｰｸｿﾘｭｰｼｮﾝ事業部技師）

同：中川 郁夫（ｲﾝﾃｯｸ・ﾈｯﾄｺｱ取締役 CSO）

同

：永見 健一（ｲﾝﾃｯｸ・ﾈｯﾄｺｱ研究開発部長）

同：山内 一郎（NTT ｺﾐｭﾆｹｰｼｮﾝｽﾞｿﾘｭｰｼｮﾝ事業部課長代理）

同：長谷部克幸（NTT ｺﾐｭﾆｹｰｼｮﾝｽﾞﾌﾞﾛｰﾄﾞﾊﾞﾝﾄﾞ IP 事業部主査）

同

：長橋

同

：宇多 仁 （北陸先端科学技術大学院大学情報科学ｾﾝﾀｰ助手）

マンスフィールド（東北大学客員研究員）

裕之（筑波技術大学産業技術学部教授）
勝也（慶應義塾大学 SFC 研究所）

好彦（日本電気ﾋﾞｼﾞﾈｽ開発本部主任）

賢吾（東京大学情報理工学系研究科）

6
-6-

同

：福田 健介（NTT 未来ねっと研究所研究主任）

同：宮田 宏 （横河電気技術開発本部ﾈｯﾄﾜｰｸ開発ｾﾝﾀｰ ﾏﾈｰｼﾞｬ）

同

：福岡

同

：伊達 進 （大阪大学大学院情報科学研究科特別任用助教授）

同：秋山 豊和（大阪大学ｻｲﾊﾞｰﾒﾃﾞｨｱｾﾝﾀｰ助手）

同：武田 伸悟（大阪大学ｻｲﾊﾞｰﾒﾃﾞｨｱｾﾝﾀｰ）

同：田代 孝仁（大阪大学ｻｲﾊﾞｰﾒﾃﾞｨｱｾﾝﾀｰ）

同：為重 文覚（大阪大学ｻｲﾊﾞｰﾒﾃﾞｨｱｾﾝﾀｰ）

同：中川 真志（大阪大学ｻｲﾊﾞｰﾒﾃﾞｨｱｾﾝﾀｰ）

同：横山 恵一（NEC ｼｽﾃﾑﾃｸﾉﾛｼﾞｰ ｻｰﾊﾞｿﾌﾄｳｪｱ事業部技術ﾏﾈｰｼﾞｬｰ）同：藤井 省吾（NEC ｼｽﾃﾑﾃｸﾉﾛｼﾞｰ ｻｰﾊﾞｿﾌﾄｳｪｱ事業部主任）

同：松田 正宏（富士通研究所 Web&IP サービス研究部長）

同：松倉 隆一（富士通研究所 Web&IP サービス研究部）

同：岡本 裕子（NTT 西日本ｿﾘｭｰｼｮﾝ営業本部）

同：三宅 喬 （倉敷芸術科学大学大学院産業科学技術研究科）

同：村上 元英（ﾊﾟﾅｿﾆｯｸﾈｯﾄﾜｰｸｻｰﾋﾞｼｽﾞ主任技師）

同：近堂 徹 （広島大学大学院工学研究科）

同

：島村

同

：岩田 誠 （高知工科大学情報システム工学科教授）

同：濱村昌則（高知工科大学情報システム工学科講師）

同：酒居敬一（高知工科大学情報システム工学科講師）

同：妻鳥貴彦（高知工科大学情報システム工学科講師）

同：都築伸二（愛媛大学工学部電気電子工学科助教授）

同：山口 巧 （高知工業高等専門学校電気工学科助教授）

同

：林

同

：北口 善明（ｲﾝﾃｯｸ･ｳｪﾌﾞ･ｱﾝﾄﾞ･ｹﾞﾉﾑ･ｲﾝﾌｫﾏﾃｨｸｽ）

同：池永

全志（九州工業大学大学院工学研究科助教授）

同：川原

憲治（九州工業大学情報工学部電子情報工学科助教授）

同：福田 豊 （九州工業大学情報科学センター助手）

同

：堀

同

：田頭

秀樹（九州電力電子通信部）

同：神山

勝司（九州電力電子通信部）

同：本庄 一法（ﾊﾟﾅｿﾆｯｸｺﾐｭﾆｹｰｼｮﾝｽﾞ開発研究所主任技師）

同：原口 浩朗（安川情報システム組込ｺﾝﾎﾟｰﾈﾝﾄ事業本部課長）

同

：勝野

同

：山崎 克之（KDDI 研究所学術ﾈｯﾄﾜｰｸ推進特命ﾌﾟﾛｼﾞｪｸﾄﾘｰﾀﾞ）

寛之（KDDI 研究所主任研究員）

和典（高知工科大学教授

情報ｼｽﾃﾑ工学科長）

秀樹 （日本テレコム情報通信研究所主任研究員）

良彰 （九州大学大学院システム情報科学研究院助教授）

聡 （KDDI 研究所主任研究員）

7
-7-

同

：石原 智裕（ﾊﾟﾅｿﾆｯｸﾓﾊﾞｲﾙｺﾐｭﾆｹｰｼｮﾝｽﾞ R&D センター）

同：飯田

勝吉（東京工業大学学術国際情報センター講師）

上で述べた研究推進体制を図 1.4.1 に示す

ＪＧＮⅡ研究開発
ＪＧＮⅡ研究開発プロジェクトの推進体制
プロジェクトの推進体制

尾家祐二
総括責任者（リー ダー）（東北J GNⅡRC）（つ くば
JGN ⅡRC）（大手 町
JGN ⅡRC）

曽根秀昭

古賀達蔵

江崎 浩

下條真司

小林和真

福本昌弘

尾家祐二

副総括責任者（ｻﾌﾞﾘｰﾀﾞｰ）

副総括責任者（ｻﾌﾞﾘｰﾀﾞｰ）

副総括責任者（ｻﾌﾞﾘｰﾀﾞｰ）

副総括責任者（ｻﾌﾞﾘｰﾀﾞｰ）

副総括責任者（ｻﾌﾞﾘｰﾀﾞｰ）

副総括責任者（ｻﾌﾞﾘｰﾀﾞｰ）

総括責任者（ﾞﾘｰﾀﾞｰ）

拠点研究 員

拠点研究 員

拠点研究 員

拠点研究 員

拠点研究 員

拠点研究 員

拠点研究 員

特別研究 員

特別研究 員

特別研究 員

特別研究 員

特別研究 員

特別研究 員

特別研究 員

テ ー マⅣテ ー マⅣテ ー マⅠテ ー マⅢテ ー マⅠテ ー マⅣテ ー マⅡ（大阪J GNⅡRC）（岡山J GNⅡRC） （高知J GNⅡRC）（北九 州
JGN ⅡRC）

テ ー マⅠ2JGN Ⅱ R &D N OC (側面支援）

外部研究 機関と の共同 研究

図 1.4.1 JGNⅡ研究開発プロジェクト推進体制
1.5

研究テーマ

研究開発テーマとして、４つのコア・テーマがあり、7 つのリサーチセンター（RC）が１
つまたは２つのテーマを分担し、それぞれが連携して研究開発を行っている。以下にその概要を示す。また、研究テーマと関連組織等の関連を図 1.5.1 に、研究体制を図 1.5.2～1.5.5
に示す。
1.5.1

高信頼コアネットワーク技術に関する研究開発

多種多様かつ大容量のネットワークサービス、コンテンツ、アプリケーション等を、超高速かつ高品質に伝送可能なネットワーク環境の提供を実現するため、高信頼なコアネットワークを構築し、ネットワークや機器の相互接続性、運用管理技術に関する研究開発を実施し、総合的な検証評価環境を確立する。
具体的研究項目は以下の６つに分かれる。
(1) IRIDES ネットワークアーキテクチャの研究開発(大手町 JGNⅡRC)

8-8-

(2) ネットワーク構築運用支援ツール群の研究開発 (大手町 JGNⅡRC)(3) 広域高信頼ネットワーク接続性提供技術の研究開発 (大手町 JGNⅡRC)(4) IPv6 機器検証評価手法とツールの研究開発(大手町 JGNⅡRC)(5) 次世代インターネット相互接続性検証の研究開発 (岡山 JGNⅡRC)(6) GMPLS ネットワーク運用・管理技術の研究開発 (つくば JGNⅡRC)
1.5.2

アクセス系ネットワーク技術に関する研究開発

超高速なコア網と無線やモバイルを含む不均一なアクセス網を最大限に有効利用して、それらの網を横断する様々な通信の良好なエンドツーエンド品質を効率的に実現するために、
端末、アクセス網、コア網が適切に役割分担し、ネットワーク状態とトラヒック特性の把握に基づいた様々なネットワーク資源の動的・大域的な割り当て・利用を行う技術の研究開発を実施する。
具体的研究項目は以下の３つに分かれる。
(1) ネットワーク計測に基づく適応経路制御技術の研究開発 (北九州 JGNⅡRC)(2) 品質を考慮したシームレスな資源利用・割当て制御技術の研究開発 (北九州 JGNⅡRC)(3)多様性・可変性に適応する E2E 通信制御技術の研究開発 (北九州 JGNⅡRC)
1.5.3

拠点連携型資源共有技術に関する研究開発

地域等の研究拠点におけるアプリケーション・サービス資源を共有・管理し、利用者の要求・状況・環境に応じた資源提供を可能とするネットワークを実現するため、セキュアなデータ共有と大容量データ処理を前提とした資源割り当てのための研究開発を実施する。
具体的研究項目は以下の２つに分かれる。
(1) 拠点連携のためのセキュアな資源共有技術の研究開発 (大阪 JGNⅡRC)(2) 広域ネットワークにおける大規模データ処理連携技術の研究開発 (大阪 JGNⅡRC)
1.5.4

プラットフォーム・アプリケーション技術に関する研究開発

映像等大容量ブロードバンド情報の有効活用を実社会で実現させるため、アプリケーショ
ンごとに最適な運用管理を可能にするプラットフォーム技術と，リアルタイムで遠隔地の映像とマーカ情報に身体動作等を組み合わせて合成・制御するコミュニケーション技術，およびネットワーク上に分散する資源の自由な活用を図るとともに効率的な情報転送・再現のための信号処理の技術について，研究開発を実施する。
具体的研究項目は以下の３つに分かれる。
(1) アプリケーション指向型運用管理プラットフォーム技術の研究開発 (東北 JGNⅡRC)(2) サラウンディング・コンピューティング技術の研究開発 (高知 JGNⅡRC)(3) 高度 HCI 技術を活用した適応型サービス制御の研究開発 (つくば JGNⅡRC)

9-9-

次世代高度ネットワー ク推進会議

情 報通信 研究機 構

幹事会
一般共同研究JGN Ⅱ

JGNⅡ研究開発プロジェ クト

研究推進部会

戦略的情報通信研究開発推進制度
ｲﾍﾞﾝﾄ利用

実ﾄﾗﾋｯ ｸﾃﾞｰﾀの利用

利用促進部会

国際共同研究推進部会

拠点研究ﾘ ｻｰﾁｾ ﾝﾀｰ連携
IT研究開発支援ｾ ﾝﾀｰ

拠点研究

次世代高機能ネットワー ク基盤技術・利活用技術に関す る研究開発
プロジェクトリーダー 尾家祐二

高信頼コアネットワー ク技術に関する 研究開発

I

• IRID ESネ ット ワ ー ク アー キ テク チ ャ の研究 開発• ネ ット ワ ー ク 構築運用 支援ツ ー ル群の 研究開 発• 広域高 信頼ネ ット ワ ー ク 接 続性提 供技術 の研究 開発• IPv6 機器 検証評 価手法 とツ ー ルの研 究開発• 次世代イ ン ター ネ ット 相互接 続性検 証の研 究開発• GMPL Sネ ット ワ ー ク 運用・ 管理 技術の 研究開 発

II

アクセス系ネットワー ク技術に関する 研究開発
• ネ ット ワ ー ク 計測に 基づ く 適応経 路制御 技術の 研究開 発• 品質を 考慮し た シー ムレ スな 資源利 用・ 割当 て制御 技術の 研究開 発• 多様性・ 可変 性に 適応す る E2E通信 制御技 術の研 究開発

拠点連携型資源共有技術に関す る研究開発III• 拠点連携 のため のセ キ ュ ア な資源 共有技 術の研 究開発

江﨑副総
江﨑副総 括責任
括責任 者
者
（サブリー
（サブリーダダー）ー）

尾家総括
尾家総括 責任者
責任者（リーダ（リーダー）
ー）

下條副総
下條副総 括責任
括責任 者
者
（サブリー
（サブリーダダー）ー）• 広域ネ ット ワ ー ク に お け る 大規模デ ー タ処理 連携技 術の研 究開発

プラットフォー ム・アプリケー ション 技術に関する 研究開発

IV

• アプ リケ ー ショ ン 指向型運用管理プ ラ ット フ ォ ー ム 技術の研究開発

曽根副総
曽根副総 括責任
括責任 者
者
（サブリー
（サブリーダダー）ー）• サラ ウ ン ディ ン グ・ コン ピ ュ ー ティン グ 技術の研究開 発• 高度HC I技 術を 活用し た適 応型サー ビ ス 制御の 研究開 発

図 1.5.1 研究テーマと関連組織等の関連

テー マⅠ 研究開発体制
メイ ンテーマ： 次世代高機能ネッ トワーク基盤技術・ 利活用技術に関する研究開発
総括責任者：尾家 祐二（ 九州工業大学教授）
副総括責任者： ： 曽根 秀昭（東北大学教授） 、古賀 達蔵（ 元筑波大学副学長）、 江﨑 浩（東京大学教授）
下條 真司（ 大阪大学教授） 、小林 和真（ 倉敷芸術科学大学教授） 、福本 昌弘（ 高知工科大学助教授）
研

究 テ ー

マ

研究開発実施サイトおよび 人員
大手町JGNⅡリサーチ セン ター（ ＮＴＴ大手町ビル内）
副総括責任者： 江﨑浩（東京大学）
拠点研究員 ： 山森雅文（インテックW & G）
特別研究員 ： 宇多仁（ 北陸先端大学 院大学） 、

高信頼コ ア ネッ トワ ー ク技術 に関 す る研究 開発
テー マ責任者：江﨑 浩

金海好彦（ 日 本電気） 、月岡 陽一（ 日立 製作所） 、中川
郁夫（ イン テッ ク・ ネ ッ ト コ ア） 、長橋 賢吾（ 東京 大学） 、
永見健一（ イ ン テッ ク・ ネ ッ トコ ア） 、 長谷部 克幸（ N TTCO M） 、 福田健 介（ N TTみら い ネ ッ ト研） 、宮田 宏（ 横河電機） 、 山内一 郎（ N TT-CO M)

IR IDESネ ットワ ーク アー キ テクチャ の研究開発(新規)
ネ ット ワーク 構築運用支援ﾂｰﾙ 群の研究開発

広域高信頼ﾈｯ ﾄﾜｰｸ接続性提供技術の研究開発

岡山JGNⅡリサーチ セン ター（ テレポ ート 岡山内）
副総括責任者： 小林和真 （ 倉敷芸術科学大学）
拠点研究員 ： 美甘幸路（オ ー ビス）
特別研究員 ： 岡本裕子(西日本電信 電話)、 三宅IPv 6機器検証評価手法とﾂｰﾙ群の研究開発

喬( 倉敷 芸術科 学大学) 、村上 元英( ﾊﾟ ﾅｿﾆｯ ｸ ﾈｯ ﾄﾜ ｰｸ
ｻ-ﾋ ﾞｼｽﾞ) 、近堂 徹(広島大 学大学 院工学 研究科)

共同研究機関東京大学、NTT -COM、インテック・ネ ットコ ア、インテ ッ
クW & G、日立製作所、日本電気、 NT Tみらいネ ット
研、 IIJ技術研、横河電機、
オ ムニサイ、北陸先端大学
院大学、JPNIC、IPv6協議
会、L ive E!、DIST IX

倉敷芸術科学大学、
西日本電信電話、ﾊﾟﾅｿﾆ ｯｸ
ﾈｯﾄﾜ ｰｸｻｰﾋﾞｼ ｽ、広島大学

つ くばJGNⅡリサーチ セン ター
次世代ｲﾝﾀｰﾈｯ ﾄ相互接続性検証の研究開発(つ く ばJGNⅡRC & KDDI大手町ビル内）

GMPLSﾈｯ ﾄﾜｰｸ運用・ 管理技術の研究開発

特別研究員 ： 大谷朋広（ K D D I 研） 、織田勝也

副総括責任者： 古賀達蔵（ NIC T）
拠点研究員 ： 岡野介英(NTT-AT ）岡本修一（KDDI研）（ 慶応大学） 、 大原拓 也（ N TTみ らい ネ ッ ト研） 、亀田寿夫（ 筑波大 学） 、木 村成伴（ 筑 波大学） 、工藤 知宏（ 産総研） 、佐 藤一雄（ 防 災研） 、 鮫島康 則（ N TTみ ら
い ネ ッ ト研） 、高 田俊和（ N E C基礎 研） 、藤 原和弘（ N TT- CO M）

注： 研究員お よび 研 究フェ ロ ー 欄の 氏名は 、2 0 0 6 年 2 月1 日 現在

図 1.5.2 テーマⅠ10
- 10 -

研究開発体制筑波大学、 KDDI研究所、
産総研、農研機構、防災研、NEC基礎研究所、
NT T-COM、 NTT みらい ネ ッ
ト研

JGNⅡ研究開発プロジェクト

テーマⅡ 研究開発実施体制
メインテーマ：次世代高機能ネットワーク基盤技術・利活用技術に関する研究開発
総括責任者：尾家 祐二（九州工業大学教授）
副総括責任者：曽根 秀昭（東北大学教授）、古賀 達蔵（元筑波大学副学長）、江﨑 浩（東京大学教授）
下條 真司（大阪大学教授）、小林 和真（倉敷芸術科学大学教授）、福本 昌弘（高知工科大学助教授）
研 究 テ ー マ

研究開発実施サイトおよび人員

アクセス系ネットワーク技術に関する研究開発
テーマ責任者：尾家 祐二
ネットワーク計測に基づく適応経路制御技術の研究開発
品質を考慮したシームレスな資源利用・割当て制御技術の研究開発
多様性・可変性に適応するE2E通信制御技術の研究開発

北九州JGNⅡリサーチセンター
総括責任者：尾家 祐二
主席拠点研究員： 鶴 正人（九工大）
拠点研究員：北辻 佳憲（ＫＤＤＩ研）
特別研究員：田頭秀樹（九電）
勝野聡（ＫＤＤＩ研）、山崎克之（ＫＤＤＩ研）、
川原憲治（九工大）、池永全志（九工大） （兼）北九州JGNⅡリサーチセンター
総括責任者：尾家 祐二
主席拠点研究員： 鶴 正人（九工大）
拠点研究員：古閑 宏幸
特別研究員：原口浩朗（安川情報システム)、石原智裕(パナソニックモバイルコミュニケー
ションズ）、本庄一法（パナソニックコミュニ
ケーションズ）、池永全志（九工大）、福田豊（九工大）、堀良彰（九大） （兼） 、
飯田勝吉（東工大）

共同研究機関

ＫＤＤＩ研、
九電、九工大、東工大

安川情報システム、
パナソニックモバイル
コミュニケーションズ、
パナソニックコミュニ
ケーションズ、
九工大、九大、東工大

北九州JGNⅡリサーチセンター
総括責任者：尾家 祐二
主席拠点研究員： 鶴 正人（九工大）
拠点研究員：熊副 和美（ＪＴＩＳ)
特別研究員：神山勝司（九電）、
北口善明（ＩＮＴＥＣ Ｗ＆Ｇ）、堀良彰（九大）

図 1.5.3 テーマⅡ

九電、ＩＮＴＥＣ Ｗ＆Ｇ、
ＪＴＩＳ、九工大、九大、研究開発体制テー マⅢ 研究開発体制
メイ ンテーマ：次世代高機能ネッ トワーク基盤技術・ 利活用技術に関する研究開発
総括責任者：尾家 祐二（ 九州工業大学教授）
副総括責任者： 曽根 秀昭（東北大学教授） 、古賀 達蔵（ 元筑波大学副学長）、 江﨑 浩（東京大学教授）
下條 真司（ 大阪大学教授） 、小林 和真（ 倉敷芸術科学大学教授）、 福本 昌弘（ 高知工科大学助教授）
研

究 テ ー

マ

研究開発実施サイ トおよび 人員

拠点連携 型資源 共有技 術に 関 する研 究開発
テー マ責任者：下條 真司
拠点連携のため のセキ ュ アな資源共有技術の研究
開発

共同研究機関大阪JGNⅡリサーチ セン ター（ 大阪大学サイ バー メディ アセン ター 内）
副総括責任者： 下條 真司

阪大、 ＮＥＣ、

主席拠点研究員： 馬場 健一（ 阪大)

ＮＥＣＳＴ

拠点研究員：長谷川 一郎（ ＮＥＣＳＴ）
特別研究員：伊達進（ 阪大）、

広域ネットワー クにお ける大規模デー タ処理連携技術の研究開発高田俊和（ ＮＥＣ） 、横山恵一（ ＮＥＣＳＴ）、藤井省吾（ ＮＥＣＳＴ） 、武田伸悟（阪大） 、
田代 孝仁(阪大）
大阪JGNⅡリサーチ セン ター（ 大阪大学サイ バー メディ アセン ター 内）
副総括責任者： 下條 真司
主席拠点研究員： 馬場 健一（ 阪大)拠点研究員：野呂 正明（ 富士通研)特別研究員：秋山豊和（阪大） 、
松田正宏（ 富士通研）、 松倉隆一（ 富士通研） 、
福岡寛之（ ＫＤＤＩ研）、 為重文覚(阪大）、
中川真志（ 阪大）

注： 研究員お よび 研 究フェ ロ ー 欄の 氏名は 、2 0 0 5 年２月 １ 日現在

図 1.5.4 テーマⅢ

11
- 11 -

研究開発体制阪大、富士通、
富士通研、
ＫＤＤＩ研

JGNⅡ研究開発プロジェクト

テーマⅣ 研究開発実施体制
メインテーマ：次世代高機能ネットワーク基盤技術・利活用技術に関する研究開発
総括責任者：尾家 祐二（九州工業大学教授）
副総括責任者：曽根 秀昭（東北大学教授）、古賀 達蔵（NICT専攻研究員）、江﨑 浩（東京大学教授）
下條 真司（大阪大学教授）、小林 和真（倉敷芸術科学大学教授）、福本 昌弘（高知工科大学助教授）
研 究 テ ー マ と 研 究責任者

研究開発実施サイトおよび人員
東北JGNⅡリサーチセンター(東北大電気通信研究所内）
副総括責任者：曽根秀昭（東北大学）
専攻研究員：増田尚則
特別研究員 ：白鳥則郎,木下哲夫,菅沼拓夫,
阿部亨,北形元（以上東北大）
脇山俊一郎,菅野浩徳（以上仙台電波高専）,
菅原研次（千葉工大）,柴田義孝,橋本浩二（岩手県立大）,キニ・グレン・マンスフィールド（ｻｲﾊﾞｰ･ｿﾘｭｰｼｮﾝｽﾞ）プラットフォーム・アプリケーション技術に関する研究開発；曽根 秀昭（東北大学教授）
アプリケーション指向型運用管理プラット
フォーム技術の研究開発

高知JGNⅡリサーチセンター
副総括責任者：福本昌弘（高知工科大学）
特別研究員 ：島村和典,濱村昌則,岩田誠,
酒居敬一,妻鳥貴彦（以上高知工科大学）
都築伸二（愛媛大学）,山口巧（高知高専）
林秀樹(日本テレコム)

サラウンディング・コンピューティング技術の研究開発

高度HCI技術を活用した適応型サービス制御の研究開発

共同研究機関東北大学、仙台電波高専、
千葉工大、岩手県立大、
サイバーソリューションズ

高知工科大学,愛媛大学
高知高専、日本テレコム

つくばJGNⅡリサーチセンター
副総括責任者：古賀達蔵（NICT）
特別研究員 ：岩田洋夫,大田友一,山海嘉之,
宗像恒次,葛岡英明,小木哲朗,橋本佐由理（以上筑波大）,須田裕之(筑波技術大),森川治（産総研）,二宮正士（農研機構）,小野澤晃(NTT－ＭＩ研),小田部文彦（つくばﾏﾙﾁﾒ
ﾃﾞｨｱ）筑波大学,筑波技術大,
産総研,農研機構、
NTT－ＭＩ研、つくばマルチメディア、つくば市

注：研究員および研究フェロー欄の氏名は、2006 年２月１日現在

図 1.5.5 テーマⅣ
1.6

各リサーチセンターの特色と活動

1.6.1

東北 JGNⅡリサーチセンター

研究開発体制東北JGNⅡリサーチセンターでは，JGNⅡ研究開発プロジェクトのテーマⅣ「プラットフォーム・アプリケーション技術に関する研究開発」のうち，「アプリケーション指向型運用管
理プラットフォーム技術の研究開発」の実施を主たる目的として，アプリケーションを強く意識し，アプリケーションが求める的確なネットワーク情報を，的確に，必要十分な品質で，オンデマンドに提供する運用管理プラットフォーム技術の開発に取組んでいる．
この研究開発テーマについて，平成17年度の東北RCでは，3つのサブテーマを設定し，それぞれに研究グループを構成する体制をとっている．図1.6.1は，3つのサブテーマの関係を表したものである．この全体について，アドバイザとして白鳥則郎（東北大学教授），RCを担当するサブリーダとして曽根秀昭（東北大学教授），および専攻研究員の増田尚則と招聘研究員１名が総括している．3つのテーマと体制は以下の通りである．
(1) 超高速大規模ネットワーク向きネットワーク計測・解析技術の開発
研究テーマとりまとめ・専攻研究員：増田尚則，特別研究員：菅沼拓夫（東北大学助教授），特別研究員：北形元（東北大学助手）
共同研究機関：(株)サイバー・ソリューションズ，特別研究員：キ二・グレン・マンスフィールド12- 12 -

(2) アプリケーション指向型運用管理技術とセキュリティ技術の開発
研究テーマとりまとめ・専攻研究員：曽根秀昭（東北大学教授），特別研究員：脇山俊一郎（仙台電波高専・教授），菅野浩徳（同・助教授）
協力者：加藤寧（東北大学教授）(3) フレキシブルネットワークミドルウェア技術の開発
研究テーマとりまとめ・特別研究員：木下哲男（東北大学教授），特別研究員：阿部亨（東北大学助教授），特別研究員：柴田義孝（岩手県立大学・教授）、橋本浩二（同）共同研究機関：千葉工業大学，特別研究員：菅原研次（同・教授）

アプリケーション指向型運用管理
技術とセキュリティ技術の開発

利用者

運用管理
システム

複数の
情報ビュー
高次ネット ワーク情報

アプリケーショ ン
制御

侵入検知

監視要求

アプリケーショ ン指向型運用管理ミ ドル ウェ ア
エージェ ント

フレキシブルネットワークミドルウェ
ア技術の開発・要求駆動型分 析・異なった視点での 情報管 理・協調型解析 による高次 情報提 供Event Detection by Network Traffic Data Analysis
ネットワーク情報の収集[ リンクレイヤ（ VLAN， etc.） ]ネットワーク情報の収集[ ネットワークレイヤ（ IPv4/IPv6， etc.） ]パッシブモニタ

超高速大規模ネットワーク向き
ネットワーク計測・解析技術の開発[ アプリケーションレイヤ]

パッシブモニタ

超高速大規模ネットワーク

図1.6.1
超高速大規模ネットワーク向きネットワーク計測・解析技術の開発について，最近のネットワーク管理における問題点は，管理対象となる機器が増大することと，ユビキタスネット
ワークに参加する機器は移動可能であることである．このサブテーマの目的は，ネットワー
クトラフィック予測によるイベント検知とし，時系列多変量解析/確率過程に基づく特異点の検出について，予測値と実測値に誤差に基づいて何らかのイベントが存在したことを検出する技術を研究している．今年度はネットワークトラフィックとアプリケーションログの計
測・解析に基づくネットワークイベント検出モデル（Ver.0.5）の詳細設計を行い、実トラ
フィックデータを用いた実験によりその有効性を確認した。また、イベント検出・分析のための支援ツールとして、広域ネットワーク環境におけるトラフィック情報のリアルタイム分

13- 13 -

析を支援する「Top-Nトラフィック分析支援システム」を完成し、Winny等による異常トラフ
ィックの検出・分析を効果的に支援することが可能となった。これらの成果を学会，研究会等で発表し，国内発表6件を著し，修士学位論文(指導)1件を出した。
アプリケーション指向型運用管理技術とセキュリティ技術の開発について，アプリケーシ
ョン単位のネットワーク観測技術として，観測情報からのアプリケーション制御情報の抽出と，アプリケーションレベルで通信の特性を計測・集約し，高効率に収集する方式を研究している．また，高品質・高効率なネットワーク管理のための技術として，アプリケーション
特性や利用者活動を考慮した知的な運用管理と，多様なアプリケーション間の公平な利用，
および大局的な最適制御を含む技術について研究している．今年度は，アプリケーション単位のネットワーク観測技術として、ネットワーク管理のための運用・統計情報統合化システ
ムの情報選択機能の実装、また、多地点間相互映像配信システムの送受信ノード機能のプロ
トタイプ実装を行った。また，JGNⅡ接続における地域間広帯域コンテンツ流通基盤実験ネットワークの構築・運用接続及びLANにおける計測実験を実施した．これらの実験等について，学会，研究会等で発表し，国内論文誌 1件(掲載予定)を著し，国内研究会・ワークショ
ップ等の発表9件を出した。
フレキシブルネットワークミドルウェア技術の開発について，やわらかいネットワークコ
ンセプトに基づく知識型ネットワークの実現を目標として，例えば，利用者・アプリケーシ
ョンの要求やネットワーク環境／特性に柔軟に対処できることを目指している．
このために，
フレキシブルネットワークミドルウェア(FNM)の研究開発として，エージェント型ミドルウ
ェアコンポーネントにより，領域知識を利用した動的な構成／再構成に取組んでいる．これにより，誰でも簡単に利用できるネットワーク，多様なアプリケーション／サービス／機器に対応できるネットワーク，および発展するネットワーク／ネットワークサービスの支援（FNMライブラリ）が期待される．具体的な研究内容は，トランスポート層の上位で稼動する新たな機能層の提案，FNMエージェント指向アーキテクチャの開発，およびエージェント
型ミドルウェア（FNM/A）としてのFNMの実装である．今年度は，ＦＮＭ/Aを構成するエージ
ェントの処理方式を与える知識として、多人数参加型コミュニケーションのためのミドルウェアレベルマルチキャスト（ＭＬＭ）ツリー構成法の検討を行い，JGN-IIを基盤としたネットワーク環境上の利用者向きネットワークサービスの具体例の調査・検討を継続して推進している。また，JGN-II向きミドルウェアの開発に使用するエージェントシステム設計開発支
援環境の拡張・改良を、他プロジェクトと連携して推進している。これらの成果の外部発表
として，国内研究会・ワークショップ等 3件を行なった。
東北JGN2RCでは，JGNⅡを用いた実証実験のためのプロジェクトとして，地域間広帯域コンテンツ流通基盤実験（JGN2-A16028）とCATVコンテンツ流通実験(JGN2-A17007)がある．前者は，2006年3月末時点で，「東北大学情報シナジーセンタ（宮城県）」，「NICT東北JGN2RC（宮城県）」，「八戸工業大学（青森県）」，「NICT 岩手IT研究開発支援センター（岩手県）」，「株式
会社データコア（秋田県）」，「山形県」，「会津大学（福島県）」，「滋賀県」，「ソフトピアジャ14- 14 -

パン（岐阜県）」，「東京大学情報基盤センター」の１０組織がメンバーとなっている．また「NICT 北九州IT研究開発支援センター（福岡県）」にもサーバ設置等のご協力を頂いている．
後者は，今年度の5月に新たに立ち上げたもので，「NICT東北JGN2RC（宮城県）」と「（社）日本ケーブルテレビ連盟」が中心となり，日本ケーブルテレビ連盟に加盟する全国のケーブルテレビ会社の自由な参加が可能となっている．
例えば，仙台CATV(株)，宮城ネットワーク(株)，岩手ケーブルテレビジョン（株），（株）ニューメディア（米沢市）などの参加を得ている．
この実験プロジェクトおよびJGNⅡ上に構築した実験網を用いて，定常的な動画像配信実験，地域のイベント利用等の支援などを通じた実証実験，などを行っている．ここでは，イ
ベントを中心とした本年度の実績について以下に述べる。
 ＩＣＴ推進フェア2005 in東北–

2005.5.18～5.19（総務省東北総合通信局、東北地方ＪＧＮⅡ利用推進協

議会、(独)情報通信研究機構、等）–

広島→仙台会場（HD映像/JGNv6）–

仙台会場→全国11拠点（NORTH，八戸工大，NICT岩手IT，データコア，山形県，会津大，つくばRC，群馬産業技術センター，京都府，兵庫県，NICT北九州
IT） 仙台七夕前夜祭花火中継–

2005.8.5（東北RC）–

東北大キャンパスからの撮影→東北RC青葉山–

東北RC青葉山→八戸工大，会津大，山形県，京都府–

会場音の伝送にPHS回線を利用 東北大学サイエンスカフェ特番中継–

2005.10.3（東北RC，東北大学）–

スペインからの日食の模様をJGNⅡにより東北JGN2RCで受信し，東北大サ

イエンスカフェに映像提供．さらにその模様を各地へ再中継–

Live!Eclipse映像（スペインから）→東北RC青葉山→会場–

会場→東北RC青葉山→TOPIC→秋田大（サテライト会場）–

会場→東北RC青葉山→CATV局（特別番組の生中継素材として）素材交換・番組共同制作を試行（仙台CAT-V，宮城ネットワーク）–

会場→東北RC青葉山→八戸工大，NICT岩手IT，山形県

 みちのくYOSAKOI中継–

2005.10.8（東北RC）–

みちのくYOSAKOIまつりの模様を、地元のCATV局である仙台CAT-VからJGN

Ⅱにより各地に配送–

会場→仙台CAT-V→東北RC青葉山→岩手ケーブルテレビ、ニューメディア

15- 15 -

 ＪＧＮⅡシンポジウムin仙台–

2006.1.18-1.19（(独)情報通信研究機構）–

会場→東北RC青葉山→八戸工大，データコア，群馬産業技術センター，鳥取環境大学，けいはんな，関西先端研究センター，和歌山県，兵庫県，岡山県–

岡山県はIPv6で複数の受信ノードへ中継 グリッド・ユビキタス コンピューティング シンポジウム中継–

2006.2.27–

会場（会津大学）→東北RC青葉山→東北大学–

Tony Hey, Jack Dongarraらの講演をJGNⅡにより東北大の第二会場へ中継 東北大学学位記授与式

1.6.2

–

2006.3.24（東北RC，東北大学）–

学内中継にマルチキャストを使用，一般向けにはRealシステム–

会場→仙台CATV→東北RC青葉山→各キャンパス–

会場から仙台CATV間は通常のアナログ映像

大手町 JGNⅡリサーチセンター

大手町 JGNII リサーチセンターは、東京都千代田区大手町の NTT コミュニケーションズ
大手町ビル内の一室を拠点とし、江崎浩センター長を始め、拠点研究員 1 名(山森雅文)、
特別研究員 10 名で構成されている。
研究活動では、次世代のネットワークアーキテクチャの検討・開発として「IRIDES ネッ
トワークアーキテクチャの研究開発」、そして、現在実際に構築されているネットワークの現状の把握として日本国内の総トラフィック量の測定や、エンドユーザまでも含めたトラフィックの品質測定アプリケーションの開発などの「ネットワーク構築運用支援ツール群の研究開発」、SIP に特化しての国内 IP 電話サービスの相互接続試験活動を通しての接続性の向上を目指す｢広域高信頼ネットワーク接続性提供技術の研究開発」、更には次世代の通信プロトコルとして期待されている IPv6 に関して、TAHI プロジェクト、IPv6 普及高度化推進協議会、IPv6 Forum との協調関係を構築し、グローバルな IPv6 機器検証評価を推進する IPv6 Ready Logo に対して、基盤となる評価検証仕様とテストソフトウェアなどの「IPv6 機器検証評価手法とツールの研究開発」に関する研究開発を展開している。
このように大手町 JGNII リサーチセンターでは、多くの研究機関と連携を取りながら幅広くネットワークに関する研究開発に取り組んでいる。
(1) ネットワークアーキテクチャの研究開発
エニキャストの概念を拡張した誘導経路情報の広告を用いたインターネットパス制御
アーキテクチャ(IRIDES; Invitation Routing Information aDvertisement for path
Engineering System)の提案と、本アーキテクチャを適用した OSPF ネットワークにおけ16- 16 -

るトラフィックエンジニアリングアーキテクチャの提案と動作検証を行った。更にはセンサーネットワークへの適用に向けて研究を進めている。
(2) ネットワーク構築運用支援ツール群の研究開発
実ネットワークにおいて必要となるネットワークの構築運用支援ツールを研究開発し、これを、可能な限りオープンソフトウェアとして提供することを目指している。本年度
行った成果としては、商用 ISP 各社、WIDE プロジェクト、総務省などの協力による日本の総トラフィック量と特性の計測と解析を行った。また、これまでのトラフィック測定
では計測できなかったユーザと ISP などの間でのトラフィック測定アプリケーションの開発を行った。このアプリケーションは IPv6 に対しても測定することが可能であり、IPv6 システムの品質向上に資する今後の IPv6 ネットワークへの戦力的なツールとなる。
研究の推進にあたっては、DISTIX と協調しながら行った。
(3) 広域高信頼ネットワーク接続性提供技術の研究開発
超広帯域および高信頼の接続性を提供するための基盤技術の研究開発を行うことを目的としている。VoIP/SIP システムの相互接続性確立のための研究開発を行った。 本研究
課題の推進にあたっては、JPNIC や TTC、VoIP 推進協議会、HATS など、あるいは 大手
ISP など、極めて多数の組織との協調関係を確立しながら行った。
(4) IPv6 機器検証評価手法とツールの研究開発
TAHI プロジェクト、IPv6 普及高度化推進協議会、IPv6 Forum との協調関係を構築し、グローバルな IPv6 機器検証評価を推進する IPv6 Ready Logo に対して、基盤となる評
価検証仕様とテストソフトウェアに関する貢献を行った。 具体的には、MIP、IPSec な
どである。
1.6.3

つくばＪＧＮⅡリサーチセンター

つくばＲＣでは、筑波研究学園都市に集積された大学、公的研究機関、民間企業等の研究者を結集して情報通信分野をリードする研究開発を行うとともに、自治体、公共団体、個人等の参加・協力をえて地域ネットワークを利用した実証実験を行うことにより、拠点研究としての特色を生かした成果を目指している。
つくばＲＣの研究テーマは、「ＧＭＰＬＳネットワーク運用・管理技術の研究開発」（GMPLS:
Generalized Multi Protocol Label Switching）及び「高度ＨＣＩ技術を活用した適応型サービス制御の研究開発」（HCI: Human-Computer Interaction）の２件をコア・テーマとし、関連する以下のサブテーマからなる。
ＧＭＰＬＳ関連サブテーマ：「マルチメディア配信のためのネットワーク制御に関する研究」、「GMPLS ネットワーク
における最適ルーティングとフロー制御」、「Grid ミドルウェアによる GMPLS ネットワーク
利用技術の研究開発」、「グリッドコンピューティングにおける JGN の有効性実証」
ＨＣＩ関連サブテーマ：

17- 17 -

「ハプティック・コミュニケーション」、「地域住民の健康増進行動のための SAT 遠隔カウ
ンセリングシステム研究」、「身体的遠隔コミュニケーション空間の研究」、「実空間における
ビデオアバタコミュニケーション技術の研究」、「ギガビット回線でのハイパーミラー対話の研究」、「ギガビットネットワーク上でのミラーインターフェースを用いたコラボレーション
環境に関する研究開発」
つくばＲＣの人員構成は、センター長１名（古賀達蔵）、拠点研究員３名（奥中淳三、岡本修一、岡野介英）、及び特別研究員２２名、合計２６名からなる。特別研究員の研究テー
マ別配置は、ＧＭＰＬＳ関連１０名（亀田壽夫、木村成伴（以上、筑波大）、織田勝也（慶応大）、工藤知宏（産総研）、佐藤一雄（防災研）、高田俊和（ＮＥＣ基礎・環境研）、大谷朋広（ＫＤＤＩ研）、藤原和弘、（ＮＴＴ－ＣＯＭ），鮫島康則、大原拓也（以上、ＮＴＴ－未
来ねっと研））、ＨＣＩ関連１２名（岩田洋夫、大田友一、山海嘉之、宗像恒次、葛岡英明、
橋本佐由理、小木哲朗（以上、筑波大）、須田裕之（筑波技術大）、森川 治（産総研）、小野澤 晃（ＮＴＴ－ＭＩ研）、田中崇彦（ＮＴＴ－ＣＯＭ）、小田部文彦（つくばマルチメディア））である。
本年度の研究成果として、GMPLS 関連：11 件（うち国際学会発表 6 件）、HCI 関連：9 件（うち国際学会発表 1 件）の外部研究成果発表を行った。GMPLS 関連では、岡本修一拠点研究員
が、電子情報通信学会平成 17 年度学術奨励賞を受賞した。
つくばＲＣでは、毎月１回構成員及び関係者を招集してスタッフミーティングを開催し、研究計画の策定、研究成果の向上、構成員の意思疎通などを図っている。同時に、つくばＪ
ＧＮⅡＲＣセミナーを開催し一般に公開している。
つくばＪＧＮⅡＲＣセミナーは、原則として、毎月１回中旬の月曜日、１４：００～１５：００に開催する。会場は、つくばＪＧＮⅡリサーチセンターの２階会議室（約３０人収容）とし、実況をＪＧＮⅡ経由にて受信希望者にマルチキャスト配信する。テーマに関心のある方なら誰でも参加でき、参加は無料である。セミナーの内容は、つくばＪＧＮⅡリサーチセンターが実施する GMPLS 関連及び HCI 関連の研究テーマを中心にした話題を交互に提供することにしている。
平成１７年度の開催記録は以下のとおりである。
第１回：４月 18 日、「独立分散最適化によるネットワークにおける性能劣化パラドックス」、
亀田壽夫（NICT 拠点研究員 筑波大学）、参加者約５０人
第２回：５月１６日、「遠隔対話での一体感と画面理解モード」、森川治（つくばＲＣ特別研究員、産総研）、参加者３５人
第３回：６月１３日、「GMPLS のユーザインターフェースに関する検討」、鮫島康則（つくばＲＣ特別研究員、NTT-未来ねっと研）、参加者２５人
第４回：７月１１日、「テレ・イマーシブ・カンファレンス」、小木哲朗（つくばＲＣ特別研究員、筑波大学）、参加者３０人

18- 18 -

第５回：９月１２日、「人間・機械・情報系の一体化技術最前線－身体機能を拡張するロ
ボットスーツ HAL－」、山海嘉之（つくばＲＣ特別研究員、筑波大学）、参加者約５０人
第６回：１０月１７日、「RSVP Route Updating Methods for Mobility of Sender or
Receiver」、木村成伴（つくばＲＣ特別研究員、筑波大学）、参加者３０人
第７回：１１月 1４日、
「ポインティングインタフェースについて」、小野澤 晃（つくばＲＣ特別研究員、NTT-MI 研）、参加者３０人
第８回：１２月１２日、「ＪＧＮII を用いたＧＭＰＬＳとグリッドの連携実験」、工藤知宏（つくばＲＣ特別研究員、産総研）、参加者３０人
第９回：１月２３日、「ネットワークによる自由視点映像のライブ配信とインタラクティ
ブ提示」、大田友一（つくばＲＣ特別研究員、筑波大）、参加者３０人
第１０回：２月２０日、「大容量光通信技術～1000 チャネル波長多重伝送～」、大原拓也（つくばＲＣ特別研究員、NTT-未来ねっと研）、参加者２０人
第１１回：３月２０日、「地域ネットワークと社会システムへのユニバーサルアクセスに向けて」、須田裕之（つくばＲＣ特別研究員、筑波技術大）、参加者２１人
つくば市、茨城県を中心とした高度情報化に向けた地域活動に積極的に関与し、関東ＪＧ
ＮⅡ懇話会、茨城県ＩＴ戦略会議、筑波研究学園都市交流協議会、つくばＷＡＮ推進会議、
つくばＷＡＮ運用管理委員会、つくばＷＡＮ研究交流委員会等に参加した。また NICT、つくば市間で HCI に関する研究開発の共同研究契約が結ばれたことにより、つくば市が参加する形の実証実験に向けての予備検討など両者間の連携活動が活発になった。

1.6.4

大阪 JGNⅡリサーチセンター

大阪ＲＣでは、「拠点連携型資源共有技術」というテーマのもとに、広域ネットワークを介して接続された複数の拠点に分散設置された計算機群を利用し、計算サービスを実施する
場合の CPU やストレージ、ネットワークの帯域などの資源の利用に関する研究開発を実施している。
「拠点連携型資源共有技術」の研究テーマは 2 つのサブテーマからなり、各サブテーマ
は「拠点連携のためのセキュアな資源共有技術の研究開発」「広域ネットワークにおける大規模データ処理連携技術の研究開発」というテーマで計算資源の共有に関するセキュリティと広域分散処理におけるネットワークとその効率的利用方法に関する研究開発を実施している。
本研究分野は、ネットワーク、ミドルウェアからアプリケーションまでさまざまな領域に跨る研究であるため、国内外の関係分野の研究プロジェクトと連携して研究効率向上を目指している。また、この連携により、研究開発した技術のアプリケーションへの適用や、大規模な実験を行う事なども視野にいれて研究開発を実施している。この連携の成果として、平19- 19 -

成 17 年度は昨年に引き続き、SuperComputing2005(シアトル)において、大阪大学と共同でブースを出展し、大阪 RC における研究開発内容をアピールすると共に、JGNⅡの国際回線を利用して、大阪とアメリカの間でのアプリケーションのデモンストレーションを実施した。
なお、このうち、口腔領域のアプリケーションのデモンストレーションについては報道発表も行った。
学会などにおける外部発表としては、国際学会 1 件、国内学会 5 件、その他 1 件を実施した。また、学会などにおける研究発表やデモンストレーションの他にも、JGNⅡおよび大阪
ＲＣの活動を多くの場で積極的にアピールすることにも取り組んでおり、昨年度はSuperComputing2005 の他にも JGNⅡワークショップを大阪で開催すると共に、JGNⅡシンポ
ジウムにおいても、大阪と仙台を接続し、遠隔でのデモンストレーションを実施した。

研 究 テ ー マ

研究開発実施サイトおよび人員拠点連携型資源共有技術に関する研究開発
テーマ責任者：下條 真司
拠点連携のためのセキュアな資源共有技術の研究
開発

共同研究機関大阪JGNⅡリサーチセンター（大阪大学サイバーメディアセンター内）
副総括責任者：下條 真司

阪大、ＮＥＣ、

主席拠点研究員：馬場 健一（阪大)

ＮＥＣＳＴ

拠点研究員：長谷川 一郎（ＮＥＣＳＴ）
特別研究員：伊達進（阪大）、広域ネットワークにおける大規模データ処理連携技術の研究開発高田俊和（ＮＥＣ）、横山恵一（ＮＥＣＳＴ）、藤井省吾（ＮＥＣＳＴ）、武田伸悟（阪大）、
田代 孝仁(阪大）
大阪JGNⅡリサーチセンター（大阪大学サイバーメディアセンター内）
副総括責任者：下條 真司
主席拠点研究員：馬場 健一（阪大)拠点研究員：野呂 正明（富士通研)特別研究員：秋山豊和（阪大）、
松田正宏（富士通研）、松倉隆一（富士通研）、
福岡寛之（ＫＤＤＩ研）、為重文覚(阪大）、

注：研究員および研究フェロー欄の氏名は、2005 年２月１ 日現在

中川真志（阪大）

図 1.6.4.1 : 大阪 RC 研究開発体制20- 20 -

阪大、富士通、
富士通研、
ＫＤＤＩ研

拠点Ｂ

拠点Ａ

ユーザ利用PC

ポータル
User ID
Role

ログイン
User ID

管理

Role

結果の
表示

リソースブローカー(スーパースケジューラ)

Policyrepository
管理

・QoS制御・Firewall制御

・センサー類から発生するデータに対する実時間処理
・対話的処理のためのデータの生成(3次元グラフィックス等)
・大規模Data Gridにおけるファイルの配布

Policyrepository

ルータ管理
サーバ

Role
ＡｃｔｉｏｎRole
Ａｃｔｉｏｎ管理・並列画像処理・３次元画像合成

大規模クラスタ(ローカルスケジューラ)

ルータ

拠点Ｄ

ルータ
制御情報
データ

観測データ
逐次送信
観測装置専用
観測装置
ゲートウェイサーバ
拠点Ｃ

図 1.6.4.2 : 拠点連携システムイメージ

図 1.6.4.3 : 口腔領域の流体および音響シミュレーション(画面サンプル)1.6.5

岡山 JGNⅡリサーチセンター

岡山 JGNⅡリサーチセンターでは、IPv6 ネットワークに代表される次世代ネットワークの早期普及、啓蒙という視点で研究開発内容を定めている。その一旦として、現在行っている IPv6 マルチキャストの相互接続性や、L2 スイッチの STP に関する相互接続性があるわけだが、新たな取り組みとして普及促進の鍵になると考えている Firewall の IPv6 化について研究を開始した。IPv6 ネットワークは既に、コンシューマ環境での導入期を迎え、ISP
サービス利用の付加価値として IPv6 サービスが提供さえるようになってきた。残された実務環境での普及が計れれば、真の移行が達成されるわけで、そのためには Firewall の IPv6化は急務である。岡山 RC では、Firewall ベンダーへの周知を終え、研究開発を開始可能な状態となった。
研究開発の姿勢／体制は、実検証にて精度向上を図る手法は全てにおいて共通である。

21- 21 -

Firewall についても自治体環境をピックアップして実運用上での実施を検討している。この手法は、既に岡山 RC を取り巻く環境において浸透しており、対象団体も柔軟に対応してくれると共に、それに期待もされている。
研究開発内容が、様々なベンダーや機関と同期を取りながらとなるため、短期で結果が出ることは少ないが、全体を巻き込んで行うことの重要性を過去の研究開発の進捗により重要だと判断している。
・ 技術課題の適切な抽出・ 市場へのフィードバック
・ IPv6 ネットワークの早期普及という研究方式を中心に、エンタープライズ、コンシューマ等のターゲットを意識し、さらに研究精度の向上に努めて行く。
1.6.6

高知 JGNⅡリサーチセンター

高知 JGNⅡリサーチセンターは，
全国 7 リサーチセンターの 1 つとして JGNⅡ研究開発プロ
ジェクトに参加するとともに，四国内唯一の JGNⅡリサーチセンターとして，四国での JGN
Ⅱを用いた研究開発や，相互接続による共同実験などに積極的に参画していくことを期待されている．高知 JGNⅡリサーチセンターは高知工科大学内（教育研究棟 A501-503, A552, 連
携研究センター 101）にあり，福本昌弘をセンター長として，高知工科大学情報システム工学科（島村和典, 濵村昌則, 岩田誠, 酒居敬一, 妻鳥貴彦）を中心にして，愛媛大学工学部（都築伸二），高知高騰工業専門学校（山口巧），日本テレコム（林秀樹）からの特別研究員で構成されている．
高知 JGNⅡリサーチセンターでは，テーマ 4.プラットフォーム・アプリケーション技術に関する研究開発のうち，サラウンディング・コンピューティング技術の研究開発を担当している．サラウンディング・コンピューティング技術とは，来るべきユビキタス・ネットワー
ク時代における，しなやかで快適な情報環境の実現をめざすものであり，JGNⅡのような次世代超高速ネットワーク上でやり取りされる膨大な情報をユビキタス環境で効率的に転送し，利用者の望むようなかたちで提示するためのシステムとなる．このため，データ駆動型プロセッサに基づくユビキタス環境での情報伝送制御技術を中心に，ネットワーク分散資源の有
効活用と分散情報の自動配信処理，利用環境に応じた情報再現技術に関する研究開発を行う．
高知 JGNⅡ利用連絡会との連携を通じて，高知県新情報ハイウェイとその接続機関である大学や研究機関，市町村，小中高校，県内企業等との相互接続により，JGNⅡを用いた地域での研究開発の活性化や高知県新情報ハイウェイの有効活用に協力している．また，四国４県のネットワーク研究者・利用者・研究機関・企業等で組織されている JGNⅡ四国連
絡協議会とも連携して，JGNⅡの周知をはかるとともに JGNⅡの利用促進と四国における地域ネットワークの相互接続の増進などをはかっている．
平成 17 年 11 月 25 日には，高知 JGN II 利用連絡会，総務省四国総合通信局，JGN II

22- 22 -

四国連絡協議会の後援と NTT コミュニケーションズ株式会社と株式会社愛媛 CATV の協力を受けて，高知市内の高知医療センター内 くろしおホールにて「インターネットの利活用－教育と医療の現場から」というテーマで JGN II 高知リサーチセンターセミナーを開催している．このセミナーでは，JGNⅡを用いた遠隔地でのデモや遠隔講演を含む 7 つの講演と，（１）教育現場などでのインターネットの利活用を続けるためには？

（２）相手との連携方法や継続する意欲を保つためには？（３）所要資金の手当ての手段は？

の 3 つのテーマに関するパネルディスカッションを行なっている．なおこのセミナーの模様はJGNv6 を通じて全ての JGNⅡアクセスポイントに中継されるとともに，愛媛 CATV や東北大学 林優一氏の協力で全国にインターネット配信されている．
1.6.7

北九州 JGNⅡリサーチセンター

北九州 JGNⅡリサーチセンターは、テーマⅡ「アクセス系ネットワーク技術に関する研究開発」を担当し、有限なネットワーク資源を効率良く共有するための効果的な資源制御の役
割分担・連携を目指して、地域で集約されたアクセス網間のトラヒック交換のために超高速コア網を最適に利用するような適応的経路・トラヒック制御技術（アクセス集約）、多種多様な無線網・移動網の資源をその制約下で通信品質を考慮して適応的に割当てる制御技術（アクセス展開）、多様な網を経由する多様な要求品質のエンドツーエンド通信を効率よく公平に実現する適応的通信制御技術（端末間通信制御）の３つの構成要素を並行・連携して研究開発を進めている。
具体的には、以下の３つのサブテーマを設定し、各々1 名の拠点研究員と企業や大学との共同研究に基づく多数の特別研究員を割り当てて、その全体を総括責任者と主席拠点研究員
が統括・指導し、産学官が一体となって研究開発を進めている。これらの３つのサブテーマ
は、全体として、
9

超高速コア網を効率的に利用し、

9アクセス網資源を効率的に利用・割当て、

9

アプリケーションに、いつでもどこでも適切なエンドツーエンド通信を提供することの実現を目指している。
(A) ネットワーク計測に基づく適応経路制御
トラヒックフロー計測，経路選択，トラヒック制御等の技術を基本として、超高速コア網を横断する通信に対する品質と利用効率の向上のためのエッジにおける経路及びトラヒッ
ク制御を目標としている。また、GMPLS 研究グループ（テーマⅠ）との連携を進めている。
主な研究者は、北辻拠点研究員と特別研究員（九州電力、KDDI 研究所、九州工業大学）である。
平成１７年度は、パスに沿った可用帯域幅の推定手法・ツールの特性や精度の実験による分析や、エッジルータ間でトラヒック特性の異なる複数フローを２つのパスに分散させる場
合の、各々のパスに沿った遅延特性の悪い方を最良にする振り分け手法の考案を行った。

23- 23 -

(B) 品質を考慮したシームレスな資源利用・割当て制御
無線網，マルチホップ無線，モバイル端末等の技術を基本として、多様な無線網での通信品質と利用効率の向上のための資源利用・割当制御を目標としている。特に、様々な資源利用・割当て技術に関して手法を提案するだけでなく、実用化への試作や特許を狙っている。
主な研究者は、古閑拠点研究員と特別研究員（パナソニックモバイルコミュニケーションズ、
パナソニックコミュニケーションズ、安川情報システム、東京工業大学、九州工業大学）である。
平成１７年度は、複数アクセスポイント（AP)を持つ無線 LAN 内の端末における、アクセス集中や電波干渉を考慮した自律分散的な AP 選択手法の考案や、端末が複数の網（通信メディア）を利用可能な場合の、状況やアプリに応じた最適通信メディアの選択・シームレ
ス切替・同時利用のためのアーキテクチャの提案を行った。
(C) 多様性・可変性に適応するＥ２Ｅ通信制御
End-to-End 通信プロトコル（トランスポート，アプリケーション），ルータでのパケッ
ト処理等の技術を基本として、多様で可変な網を経由するＥ２Ｅ通信の品質と利用効率の向上のための通信プロトコルやルータ支援を目標にしている。また、高速トランスポートプロ
トコル技術に関して JGNⅡの国際回線を利用し、国際共同実験（イリノイ大）を実施している。主な研究者は、熊副拠点研究員と特別研究員（九州電力、インテック・ウェブ＆ゲノ
ムインフォマティクス、九州大学、九州工業大学）である。
平成１７年度は、ルータでの早期パケット廃棄による実時間通信の遅延特性の改善手法の考案や、各種高速データ転送方式の環境変動及び異種フロー混在時の特性の分析のための実験を行った。
これらの研究開発を通して、各サブテーマとも初年度の研究を発展させ、段階目標を達成した。具体的には、論文誌３件、査読付国際会議８件、を含む２２件の対外研究発表と特許申請２件、プロトタイプ試作やイリノイ大学との国際共同実験などの成果を上げた。
2006 年 1 月の「JGNII シンポジウム 2006 in 仙台」では、鶴研究員による研究紹介（「アクセス系ネットワーク技術の研究動向」）と、デモブースにおける各テーマの研究成果に関するデモンストレーションを行った。
一方、北九州 JGNⅡリサーチセンターは、NICT 北九州 IT 研究開発支援センターと同じフロアにあるが、そこは JGNⅡの九州内の 2 つのコア・アクセスポイントの１つになっており、リサーチセンターと IT 支援センターが連携して、JGNⅡを使った各種ネットワー
クイベント等をサポートしており、九州地区の JGNⅡ活動の中核としての役割を果たしている。例えば、筑波ＲＣとの定期交流（筑波セミナ）、岡山ＲＣの国体中継協力など、ＲＣ間の連携にも積極的に関与した。

24- 24 -1.7

JGNⅡ主催研究発表会等

1.7.1

JGNⅡシンポジウム

JGNⅡの研究成果の積極的公開と利用促進、および学会との連携等によるネットワーク研
究者との交流促進を目的として、平成 18 年 1 月 18 日（水）～20 日（金）に「JGNⅡシンポ
ジウム 2006 in 仙台」を開催し、延べ 800 名（1 月 20 日に行われた共催研究会分を除く）の参加を得た。以下にシンポジウムのプログラム（図 1.7.1）、パネル展示及びデモ展示内
容（図 1.7.2）並びに NICT ニュースに掲載した開催報告（図 1.7.3）を示す。

「JGNⅡシンポジ ウム2006 in 仙台」 プログラム
1/18（水）（午前）

1/19（木）サブ テーマ：あ らゆる リソースを 繋ぐ「知の創発」
仙台国際セン ター（午後）

1/20（金）

10:3 0～12:00 研究発表
チェ ア ： 島村 和典 （高知工科大学 教授）
発表者 ：小林 和 真（ 岡山JG N ⅡＲＣ /倉 敷芸術 科学大 学 教授）
鶴 正人（ 北 九州JG N ⅡＲＣ /九 州工業 大学 助教 授）
楠田 友 彦( JANO G/ インテッ ク・ウ ェブ・ アンド・ ゲノム・ インフォマ ティクス株式会社)
下川 俊 彦( Q AI/ IA/ T AI合 同研究 会/ 九州産 業大学 助教 授) [ 遠 隔出演 ]研究
会発表

13:3 0～13:50 開会挨拶
総務省、NICT理事、宮城県
13:3 0～14:10 特別講演3 [遠隔出演]
Jian p in g W u (D irecto r o f CE RN ET Cen t er/中 国清華 大学 教授）

13:5 0～14:10 基調講演 テーマ：次世代IT戦略とJGNⅡ
野口 正一 （(財)仙台応用情報学研究振興財団 理事長）
14:1 5～14:45 特別講演1 テーマ： 「イノベ ーター日本」の実現におけ るJGNⅡへの期待柘植 綾夫 （総合科学技術会議議員）
14:5 0～15:20 特別講演2 テーマ：4Ｋ非圧縮ライブデモン ストレーショ ン
青山 友紀 （東京大学 教授）
15:3 0～15:50 コンテスト表彰式など「JGNⅡを 活用した研究開発アイデアコン テスト」最優秀賞、優秀賞、総務大臣賞

16:1 0～18:10 パネ ルディスカ ッショ ン1（地域研究者を交えたジョ イントセッショ ン）
テーマ ： ICTを 活用した地域の活性化
チェ ア ： 相原 玲二 （広島大学 教授）
パネ リスト ： 菊地 豊 （高知工科大学 助教授）
古賀 達蔵 (つくばJGNⅡＲＣセン ター長)
近藤 弘樹 (佐賀大学 教授)
曽根 秀昭 （東北大学 教授）
長友 信裕 （アボック株式会社 代表取締役社長）

14:3 0～16:00 海外パネルディスカッショ ン（英語）
テーマ ： 超高速で世界が繋がる
チェ ア ： 池田 佳和 （東京工業大学 特任教授）
パネ リスト： Dai Davies (DANTE General Manager）
Jianping Wu (D irecto r o f CERN ET Cen t er/中国 清華大 学 教 授）
Matthew J.Zekauskas（Senior Engineer Internet2）
江﨑 浩 （東京大学 教授）
後藤 滋樹 （早稲田大学 教授）

16:1 5～18:00 パネ ルディスカッショ ン2
テーマ ： JGNⅡの今後の展開
チェ ア ：尾家祐二 （ JG N Ⅱ研究開発ﾌﾟﾛｼﾞ ｪｸﾄ 総括責 任者/ 九州工 業大学 教 授）
パネ リスト ：坂内 正夫 （国立情報学研究所 所長）
下條 真司 （大阪大学 教授）
村井 純 （慶應義塾大学 教授）
河内 正孝（ＮＩＣＴ 理事）

図 1.7.1 JGNⅡシンポジウム 200６ in 仙台

25- 25 -

プログラム

研究
会発表

26
- 26 -

図 1.7.2 パネル展示及びデモ展示内容

27- 27 -

「JGNⅡシンポジウム 2006 in 仙台」開催報告

NICT では、研究開発テストベッドネットワーク「JGNII」に関す

く海外パネルるシンポジウムを平成 18 年 1 月 18 日（水）から 20 日（金）まで、

ディスカッショ

仙台国際センターにおいて開催しました。本シンポジウムでは、

ンでは、海外国内外のネットワーク関係の有識者に多数ご参加いただき、講の研究者を交演、パネルディスカッション、JGNII を活用した研究活動紹介等、

えたセッションJGNII を利用して実施する各種実験のデモンストレーションやパがセットされ、ネル展示を行いました。

欧州、米国、

開催初日は、河内理事による開会挨拶の後、総務省の松本

中国のテストベッドネットワークの紹介や、JGNII の国際展開の技術総括審議官、地元宮城県の三浦副知事から来賓挨拶をい

重要性と国際的なコラボレーションの必要性について認識を共ただきました。続いて仙有しました。

台応用情報学研究振興

最後のセッションでは、「JGNII の今後の展開」と題し、河内理財団の野口理事長と総事をはじめ、著名な先生方によるパネルディスカッションが展開

合科学技術会議の柘植され、「JGNII の活動はユビキタスネット社会の実現を見据え、議員から、「JGNII は産学地球規模で、かつ長期的な視野に立った新世代のネットワーク

官による研究開発の重要

アーキテクチャを意識していく必要がある」、などの議論がなさなプラットフォームとすべれました。 また、JGNII を利用した各種実験のデモンストレーシきであり、関係者一同の一層の奮起に期待する」、などのメッセョン（20 ブース）とパネル展示（80 プロジェクト）の会場は、本シンージをいただきました。

ポジウムが研究成果を一同に披露する場でもあったため、多く続いて、東京大学の青山教授の講演では、世界初の 4K 非圧の見学者が入り大変盛り上がりました。
今回のシンポジウムは、1 月 18 日、19 日の 2 日間でのべ約縮映像の IP 伝送デモンストレーションを行い、東京と会場の仙台国際センターを JGNII で結び、4K 映像を非圧縮の状態で IP
パケット化し、6Gbps の伝送速度でライブ中継しました。スクリー
ンに映し出された映像は、その立体感で参加者を魅了し、超高速な JGNII をアピールできました。
2 日目の研究発表では、岡山 JGNII リサーチセンターが毎年行なっている IPv6 マルチキャストによる「さっぽろ雪まつり」の伝送実験、そして北九州 JGNII リサーチセンター
からはアクセス系ネットワーク技術に関する研究と課題などの発表がありました。

電子情報通信学会（IA、TAI）、情報処理学会（QAI）、また、 中国清華

ICOIN2006(※1)や JANOG17(※2)などでも多数の参加者を得大学の Jianpingて、活発な意見交換が行われ盛況なうちに幕を閉じました。

Wu 教授による北図 1.7.3

800 名の参加があり、また共催イベントとして 20 日に開催された

最後にこのシンポジウム開催にあたり、ご協力をいただいた

京からの遠隔特多くの皆様方に感謝を申し上げます。

別講演が中継※1 The International Conference on Information Networking 2006

されました。続※2 Japan Network Operators' Group 17 Meeting

NICT ニュース 2006.№359 に掲載した開催報告28- 28 -

1.7.2JGNⅡワークショップ

JGNⅡワークショップは、次世代高度ネットワーク推進会議研究推進部会の活動の一環として位置づけられ、情報通信技術開発等の更なる活性化のために、JGNⅡリサーチセンターの研究開発テーマに対し、年 2～3 回程度の割合でワークショップを開催し、NICT 拠点研究等の研究者と外部機関の研究者との間で意見交換・交流を行い、JGNⅡを用いた研究開発の促進と連携強化を意図し推進している。
開催に当っては、該当テーマの JGNⅡリサーチセンター（又はその他の NICT 部門）の中から推進者を決め、プログラムの構成・スピーカーの決定等ワークショップの企画・推進を行っている。
平成 17 年度は、
「地域 ICT ネットワークとその運用・管理」と「グリッドとセンサーネッ
トワーク」をテーマに、東北 JGNⅡリサーチセンター（第３回）と大阪 JGNⅡリサーチセン
ター（第４回）がワークショップを開催し、活発な討論を行った。図 1.７.4 と図 1.７.5にその模様を示す。

第３回ワークショップの模様
名称：研究推進部会JGNⅡ第３回ワ ーク ショ ップ ～地域 ICTネ ットワー ク とその運用・管理～
場所：せん だい メディ アテー ク１Ｆ オープン スク エア
時期：平成１７年５月１８日（ 水）概要
JGNⅡの東北地域を 中心に した、次世代ネットワー ク アプ リケー ショ ン（防災ネ ット ワーク や
ヘ ルスケ アなど）につい て、研究サイドと利用サイドの意見交換を行うこ とによ り、JGNⅡの研究・利用の促進を図るこ とを 目的に、オ ープン参加による討論を主体としたワ ーク ショ ップを開催した。
５ 参加者数
約１１０名（ せん だい メディ アテーク）
６ プログラム（ １） 開会挨拶 貝沼孝二（ 総務省東北総合通信局長）、曽根秀昭（ JGNⅡ副総括責任者、東北大教授）（ ２） NICT・研究開発戦略と総務省・研究開発支援施策の紹介
島田淳一（ NICT・ 総合企画部企画戦略室マネ ージャー）、
翁長 久（ 総務省情報通信政策局技術政策課課長補佐）（ ３） JGNⅡリサー チ センター の関連研究状況①東北RCの地域間広帯域コン テンツ流通基盤実験の状況
菅野浩徳・ 脇山俊一郎（東北RC,仙台電波高専）、曽根秀昭（ 東北RC,東北大）②JGNⅡとつ くばWANの連携に おけるつ くばRCの役割： 岡野介英（つ くばRC拠点研究員）③高知RCの最新研究状況（ 高知情報ハイウェイとの接続など ）福本昌弘（ JGNⅡ副総括責任者、高知工科大学助教授）（ ４） 第１部： ヘルスケ ア支援①総務省SCOPE健康福祉プロ ジェ クトにおけるネ ット ワーク 活用と疾病予防システムの構築
富樫敦、吉田俊子（宮城大）、板橋吾一（ サイエン ティ ア）、 野口正一（ 仙台応情研財団）②高精細映像による遠隔ヘ ルスケ ア支援システムの評価
佐々木由香（三重県立看護大）、佐々木淳（ 岩手県立大）、柴田義孝（ 東北RC,岩手県立大）③地域医療に おける有線・ 無線ネ ットワ ーク の高度利活用事例
みやぎ県南中核病院における 実証実験： 菅沼拓夫（ 東北大・ 電気通信研究所,東北RC）（ ５） 第２部： 地域BB
①いばらきブロー ドバンドネットワー ク（ IBBN） と利用実績： 北村友朗（ 茨城県企画部）②トラ ンスコ ーディング 機能による多地点ＴＶ会議システム： 橋本浩二（ 岩手県立大）（ ６） 第３部： 防災・ 災害支援
①JGNⅡを 利用した大規模災害支援ネ ットワー ク： 柴田義孝（ 東北RC,岩手県立大）②東北大学に おける地震・ 火山観測ネ ット ワーク ：三浦哲（ 東北大・ 地震・ 噴火予知研究観測セン ター）③遠隔ロボ ットを用い た災害時メルチ メディ ア情報収集技術に 関する 研究開発： 吉田和哉（ 東北大）
１２
３
４

東北総合通信局

聴講の模様

聴講の模様

図 1.7.4 第３回ワークショップの模様29- 29 -

貝沼局長挨拶

第４回ワークショップの模様
１ 名称
研究推進部会JGNⅡ第４回ワ ークショ ップ ～グ リッドとセン サーネ ット ワーク ～２ 場所
国立大学法人大阪大学 中之島セン ター 10F
３ 時期
平成１７年１０月１８日（火）４ 概要
JGNⅡのグ リッドとセンサーネ ットワ ークに つい て、研究サイ ドと利用サイドの意見交換を 行うこ とによ り、
JGNⅡの研究・ 利用の促進を図るこ とを 目的に、オ ープン参加による討論を主体としたワ ークショ ップを開催した。
５ 参加者数
約１４０名（ 大阪大学 中之島セン ター 10F）
６ プログラム（ １） 開会挨拶 下條真司(JGNⅡ副総括責任者、大阪大学サイ バーメディ アセン ター長・教授）（ ２） セン サーネ ット ワーク とグ リッド
村田正幸（ 大阪大学大学院情報科学研究科教授）（ ３） JGNⅡを 用い たGMPLSとグ リッド連携実験工藤知宏（ 独立行政法人産業技術総合研究所 グ リッド研究セン ター クラスタ技術チーム長、
つ くばJGNⅡRC特別研究員）（ ４） PlanetLab： 国際協調型次世代広域分散処理プラ ットフォ ーム
砂原秀樹（ 奈良先端科学技術大学院大学教授）（ ５） 大阪JGNⅡRCの関連研究状況①広域ネ ットワ ークに おける大規模データ処理連携技術の研究開発：野呂研究員②拠点研究のためのセキュアな資源共有技術の研究開発：長谷川研究員（ ６） Liv e E！プロジェ クト～オープン センサーネ ットワ ーク の構築～
江崎浩（ 東京大学大学院情報理工学系研究科教授）（ ７） デモンストレーショ ン
HDTV画像による特別対談
宮原秀夫（ 大阪大学総長）
渡辺克信（ 朝日放送 代表取締役専務）

JGNⅡ副総括責任者

聴講の模様

聴講の模様

図 1.7.5 第４回ワークショップの模様30- 30 -

下條大阪大学教授挨拶

第２章
高信頼コアネットワーク技術に関する研究開発

第２章

高信頼コアネットワーク技術に関する研究開発

2.1 概要本研究課題は、これまでのインターネットには不足していた安心安全な情報通信サービ
スを提供するとともに、今後も進展するブロードバンド化(高帯域化)に対応するための基盤技術の確立と、技術の確立することをその研究目的としている。 具体的には、以下の研究開発活動を展開している。
・ IRIDES ネットワークアーキテクチャの研究開発
・ ネットワーク構築運用支援ツール群の研究開発
・ 広域高信頼ネットワーク接続性提供技術の研究開発
・ IPv6 機器検証評価手法とツールの研究開発
・ 次世代インターネット相互接続性検証の研究開発
・ GMPLS ネットワーク運用管理技術の研究開発
これらの研究開発課題を、以下のリサーチセンターにおいて実施している。
(1) 大手町 JGNⅡリサーチセンター (統括責任者：江崎浩)
東京都千代田区大手町の NTT コミュニケーションズ大手町ビル内を拠点とし、拠点研究員 1 名(山森雅文)、特別研究員 10 名で、(a) IRIDES ネットワークアーキテク
チャの研究開発、(b) ネットワーク構築運用支援ツール群の研究開発、(c) 広域高
信頼ネットワーク接続性提供技術の研究開発、(d) IPv6 機器検証評価手法とツールの研究開発 に関する研究開発を展開している。
(2) 岡山 JGNⅡリサーチセンター(統括責任者：小林和真)
岡山市大内田のテレポート岡山ビル内を拠点とし、拠点研究員 1 名(美甘幸路)、特別研究員 4 名で、次世代インターネット相互接続性検証の研究開発に関する研究開発を展開している。
(3) つくば JGNⅡリサーチセンター(統括責任者：古賀達蔵)
茨城県つくば市吾妻を拠点とし、拠点研究員 3 名(奥中淳三、岡本修一、岡野介英)、特別研究員 22 名で、GMPLS ネットワーク運用管理技術の研究開発 に関する研究開発を展開している。
各リサーチセンターとも、多数の特別研究員を産業界から招聘し、さらに、研究開発活動を推進する上では、積極的に産業界や学会の研究開発機関やコンソーシアムとの協力関係を確立しながら研究開発活動を推進している。 協力関係は、国内のみならず、既に国際的な展開を見せている。
以下、各研究課題の本年度の成果の概要を述べる。
(1) ネットワークアーキテクチャの研究開発
エニキャストの概念を拡張した誘導経路情報の広告を用いたインターネットパス制御
アーキテクチャ(IRIDES; Invitation Routing Information aDvertisement for path
Engineering System)の提案と、本アーキテクチャを適用した OSPF ネットワークにおけるトラフィックエンジニアリングアーキテクチャの提案と動作検証を行った。更にはセンサーネットワークへの適用に向けて研究を進めている。
(2) ネットワーク構築運用支援ツール群の研究開発
実ネットワークにおいて必要となるネットワークの構築運用支援ツールを研究開発し、これを、可能な限りオープンソフトウェアとして提供することを目指している。本年度行った成果としては、商用 ISP 各社、WIDE プロジェクト、総務省などの協力による日本の総トラフィック量と特性の計測と解析を行った。また、これまでのトラフィッ

31- 31 -

ク測定では計測できなかったユーザと ISP などの間でのトラフィック測定アプリケー
ションの開発を行った。このアプリケーションは IPv6 に対しても測定することが可能であり、IPv6 システムの品質向上に資する今後の IPv6 ネットワークへの戦力的なツールとなる。研究の推進にあたっては、DISTIX と協調しながら行った。
(3) 広域高信頼ネットワーク接続性提供技術の研究開発
超広帯域および高信頼の接続性を提供するための基盤技術の研究開発を行うことを目的としている。VoIP/SIP システムの相互接続性確立のための研究開発を行った。 本研
究課題の推進にあたっては、JPNIC や TTC、VoIP 推進協議会、HATS など、あるいは 大
手 ISP など、極めて多数の組織との協調関係を確立しながら行った。
(4) IPv6 機器検証評価手法とツールの研究開発
TAHI プロジェクト、IPv6 普及高度化推進協議会、IPv6 Forum との協調関係を構築し、グローバルな IPv6 機器検証評価を推進する IPv6 Ready Logo に対して、基盤となる評
価検証仕様とテストソフトウェアに関する貢献を行った。 具体的には、MIP、IPSec な
どである。

32
- 32 -

2.2 IRIDES ネットワークアーキテクチャの研究開発
2.2.1 誘導経路情報を用いたインターネットパス制御アーキテクチャ
2.2.1.1 概要
インターネットシステムにおける経路制御は、ますます複雑化するインターネットの構造と要求に対応しなければならない。しかし、現在の経路制御システムはグローバルスケ
ールで、宛先アドレスをルートとしたスパニングツリー型のパスを形成するために、必ずしも自由なパスの制御(トラフィックエンジニアリング)や Ingress 側での迅速な制御を実現することが容易ではない。 本論文では、エニキャストの概念を拡張した誘導経路情報の広告を用いたインターネットパス制御アーキテクチャ(IRIDES; Invitation Routing
Information aDvertizement for path Engineering System)の提案を行っている。 誘導経路情報を用いて、送信ノードにより近いポイント(誘導ポイント)において、トラフィック
エンジニアリング可能なルーティング空間(誘導空間)に IP パケットを誘導する。
誘導空間
におけるトラフィックエンジニアリングは任意の手法を用いて実現することができる。提案アーキテクチャは、既存の経路制御システムとの共存が可能であり、十分なスケーラビ
リティーを持つ。 さらに、提案アーキテクチャをもとに、いくつかの具体的なアプリケー
ション(e.g.,マルチエージャント型マルチホーム NEMO/MIP)が実現されることを明らかにする。
2.2.1.2 研究活動の背景
TCP/IP を基盤技術とするインターネットシステムは、エンドーツーエンドアーキテクチ
ャを基本原理として、1980 年代後半から驚異的な成長を遂げてきた。その成長は、インターネットに接続されるノードの数とネットワークの数のみならず、その利用者の多様度の増大に関しても著しいものがある。 インターネットの成長とともに、インターネットシス
テムにおいて、その根本的な機能を提供するルーティング制御技術(経路制御技術)も、変遷を遂げてきた。 インターネットが運用を開始した当初は、ノードのインターフェースを識別するための IP アドレス長は 4 ビットであり、今日広く利用されている動的経路制御は適用されず、すべて、Static Routing で運用することができたし、ノードの IP アドレスの解決は、DNS のようなディレクトリサービスを利用することなく、Static なテーブル
を各計算機のファイルに書き込む形態であった。 やがて、インターネットシステムの成長とともに、IP アドレスは、8 ビットに拡張され、その後、今日の 32 ビットに拡張さて、今日、128 ビットのアドレス長(IPv6)へと拡張された。その過程で、グローバルな IP アドレ
スと計算機の論理的な名称(FQDN; Fully Qualified Domain Name)のマッピング情報を提供する DNS システムが導入された。
一方、経路制御システムは、当初の Static Routing 方式のみで運用されたが、やがて、
ネットワークの状況に応じて、到達可能な最適の経路を自動的に決定して、IP パケットの転送経路の制御と管理を行う、動的経路制御が導入されるようになった。現在でも、Static
Routing(あるいは Default Routing)は、実際のネットワーク運用において、広く適用されているが、経路の冗長度の確保や宛先ネットワークへの接続性の確保を実現するために、
インターネットのコア部では、動的経路制御が適用されているのが一般的である。動的経路制御として、インターネットにおいて、現在広く適用されているプロトコルは、
IGP(Interior Gateway Protocol)としては RIP および OSPF/ISI であり、EGP(Exterior
Gateway Protocol)としては BGP である。これらのプロトコルはそれぞれ、固有の経路決定
アルゴリズムを採用しているが、根本的には、すべて共通のアーキテクチャを適用することで、大規模化(スケーラビリティー)への対応を行っている。 これは、宛先 IP アドレスのみを用いた経路表の作成と管理と、それに基づいた IP パケットの転送処理である。 これは、宛先ノードをルート(頂点)とする、スパニングツリーをグローバルに形成すること33- 33 -

によって、経路制御の複雑度をオーダーO(n)に押さえ込んでいる。 ただし、ここで、n は、
経路制御ドメインに存在するノード/ネットワークの数を表す。
ますます複雑化および多様化するインターネットの構造と要求に対して、インターネッ
トシステムにおける経路制御は、適切に対応することが要求されている。しかし、現在の経路制御システムは、上述の通り、グローバルスケールで、宛先 IP アドレスをルートとしたスパニングツリー型のパスを形成するために、必ずしも自由なパスの制御(トラフィック
エンジニアリング)や、DOS 攻撃に対する Ingress 側での迅速な制御など、現在のインター
ネットシステムが必要としている機能を実現することが容易ではない。 これまで、インターネットにおける経路制御システム全体の抽象化を行い、問題点の整理を行わず、解決すべき技術課題に対応するための具体的な手法やアーキテクチャの提案と実装および適用が、ある意味、場当たり的な解決策によって行われてきた。 その結果、本質的には、同じ手法
やアプローチを用いているのも関わらず、個別の技術エレメントに整合性がなく、それぞれ、個別の技術が新たに提案され適用されてきた。
そこで、本論文では、改めて、現在のインターネットで適用されている経路制御アーキ
テクチャの整理と抽象化を行い、その問題点と新たな要求条件を整理し、その一般的な解決手法を整理し抽象化した形で提案することを目的としている。具体的には、エニキャス
トの概念を拡張した誘導経路情報の広告を用いたインターネットパス制御アーキテクチャ(IRIDES; Invitation Routing Information aDvertizement for path Engineering System)の提案を行っている。 誘導経路情報を用いて、送信ノードにより近いポイント(誘導ポイント)において、トラフィックエンジニアリング可能なルーティング空間(誘導空間)に IP
パケットを誘導する。誘導空間におけるトラフィックエンジニアリングは任意の手法を用いて実現することができる。 提案アーキテクチャは、既存の経路制御システムとの共存が可能であり、十分なスケーラビリティーを持つ。 さらに、提案アーキテクチャをもとに、
い く つ か の 具 体 的 な ア プ リ ケ ー シ ョ ン (e.g., マ ル チ エ ー ジ ャ ン ト 型 マ ル チ ホ ー ム
NEMO/MIP)が実現されることを明らかにする。
2.2.1.3 インターネット経路制御技術の問題点
2.2.1.3.1 既存の経路制御技術の分析
本節では、本論文で提案するアーキテクチャに関連する 2 つの既存の経路制御技術の特徴を議論する。
2.2.1.3.2 Destination-Based Routing
インターネットにおいて、現在広く適用されている経路制御プロトコルは、IGP(Interior
Gateway Protocol)としては RIP と OSPF/ISIS であり、EGP(Exterior Gateway Protocol)
としては BGP である。RIP は Distance Vector 方式、OSPF および ISIS は Link State 方式、
さらに BGP は Path Vector 方式といった、それぞれに異なる固有の経路決定方式を用いている。一般的に、(大規模な)AS 内部での経路制御では OSPF および ISIS が、一方、AS 間での経路制御では BGP が適用されている。これらの経路制御プロトコルは、異なる経路決定方式を用いているが、根本的には、宛先 IP アドレスのみを用いた経路表の作成と管理と、それに基づいた IP パケットの転送処理を行っている。 すなわち、一見異なる経路制御決定方式を用いているように見えるが、すべて共通のアーキテクチャを適用することで、大規模化(スケーラビリティー)への対応を行っているといえよう。すなわち、宛先ノード(あるいはネットワーク)をルート(頂点)とする、スパニングツリー(Spanning Tree)を与えられたルーティングドメインにおいて形成することによって、経路制御の複雑度をオーダー
O(n)に押さえ込んでいる。 Inter-Domain ルーティングを司る BGP における Default-Freeな運用形態では、いわゆる フルルート(Full Routes)を隣接する(Peering している)BGP
ルータと相互交換することで、基本的にはグローバルスケールのスパニングツリーを管理

34- 34 -

している。 一方、Intra-Domain を司る OSPF や ISIS では、そのルーティングドメイン内
部のネットワークにおけるスパニングツリーの管理を行っている。
スパニングツリーは、閉じたトポロジー部分を持たない開放型のトポロジー構成を持つ。
スパニングツリーが閉じた部分を持たないので、経路制御プロトコルに要求されるループ
フリー機能の提供が実現されていると考えることが可能である。 すなわち、ルーティング
ドメイン上のすべてのオブジェクト(=ノードあるいはネットワーク)から、注目する宛先オ
ブジェクト(=ノードあるいはネットワーク)、
すなわちツリーの Root ノードへのループ(閉じた部分)のないパスを提供することができている。このスパニングツリーは、すべてのリーフ(Leaf)ノード、すなわち、すべての送信元オブジェクトで共有されたスパニングツリーとなっている。 送信元オブジェクトごとのスパニングツリーを形成管理することで、ルータが管理すべき経路情報の量のオーダーを O(n^{2}) から O(n)に削減することに成功しているわけである。これが、インターネット経路制御システムにおけるDestination-Based Routing であり、すべての経路制御プロトコルが、この原理を共通に適用している。
2.2.1.3.3 経路情報の集約化
もともと各組織は、個別の IP アドレス空間(=Portable IP Address Space)を持ち、このアドレス情報を経路制御情報としてインターネットに対して広告していた。しかし、インターネットの大規模化に伴い、このような個別の IP アドレス空間を各組織がインターネッ
トに広告すると、ルータは、経路テーブルのエントリーとして各組織ごとに生成/管理しなければならなくなってしまう。 そこで、この問題を解決するために、アドレスの集約化(Address Aggregation)が適用されるようになった。 これは、インターネットの成長に伴う経路表の増大に対応するための運用方法である。アドレスの集約化を実現するために、IP アドレス空間は、各組織が独立に取得管理するものではなく、集約化を行うネットワー
ク単位ごとに行い、そのネットワーク単位に属する組織は、そこから IP アドレスの部分空間を割り当ててもらう形態が一般的になってきた。 集約化を行うネットワーク単位は、一
般的には、ISP(Internet Service Provider)や NIR(National Internet Registry)となり、最上位は 3 つの RIR(Regional Internet Registry)となる。したがって、結果的に、IP ア
ドレス空間に関して、階層的なツリー構造が構築されていると見ることができる。なお、
経路制御における IP アドレスの集約化によって、このような IP アドレス空間の階層構造と IP パケットの転送経路との間には強い相関関係が存在することになる。
2.2.1.4 経路制御システムへの要求事項
インターネットシステムにおける経路制御は、ますます複雑化および多様化するインターネットの構造と要求に対して、適切に対応できることが要求されている。前節における議論の通り、
現在の経路制御システムは、
以下の 2 つの技術的な特徴(=制約)を持っている。
・ ルーティングドメイン内において、宛先オブジェクト(=宛先ノードや宛先ネットワーク)をルートとした、すべての送信元オブジェクトで共有されたスパニングツリーパスを生成管理している。
・ グローバルスケールに階層的な IP アドレス空間の割り当てが行われている。
インターネットの経路制御システムは、この 2 つの技術的な制約を持つために、さまざ
まな課題が現れ、これまで、それぞれに対してアドホックな対応がとられてきた。 これらの課題は、以下の 3 点に集約化することができる。
・

共有されない転送パスの提供 ： 宛先オブジェクトごとに管理されるスパニングツ
リー上のパスに依存しない IP パケットの転送パスの提供は、トラフィックエンジ

35- 35 -

・・

ニアリングに必要となる重要な要素技術の一つである。 現在の経路制御システム
では、異なる送信元オブジェクトから、同一の宛先オブジェクトに向けて転送される IP パケットは、共通のパス(スパニングツリー)を使用しなければならなくなってしまう。 宛先オブジェクトへの複数の IP パケット転送パスの提供は、シングル
ISP 内でのサービス品質提供の冗長度の向上に貢献するだけではなく、複数の ISPが関与するマルチホーム環境の提供における通信品質の向上にも貢献する。
プラグアンドプレイ環境の提供 ： IP アドレス空間の階層化と集約化に伴い、オブジェクト(ノードあるいはネットワーク)の、物理的あるいは論理的な移動時には、該当するオブジェクトシステムにおいては、IP アドレスのリナンバリングなど、さまざまな、ネットワーク関連に設定変更を行う必要がある。 オブジェクトの論理的な移動は、物理的な移動時には、ほぼ、必然的に発生するが、物理的な移動が伴わない場合でも、契約先の ISP を変更する場合などに発生する。 契約先の ISP を変更する場合には、一般的には、そのオブジェクト(ノードあるいはネットワーク)が使用する IP アドレスが変更になってしまい、それに伴い、ネットワーク関連の設定を多数変更しなくてはならない。すなわち、本論文で議論するプラグアンドプ
レイは、設定フリーの環境を提供する自動構成認識技術ではなく、設定"変更"フリーの環境を提供するものを意味する。
Ingress 側での迅速な対応を実現するフレームワークの提供 ： Destination-Based
Routing を適用した経路制御システムにおいては、送信元オブジェクトに近い地点
での迅速な対処や制御が、一般的に難しい。 特に、DDoS(Distributed Denial ofService)攻撃への対処のための IP パケットフィルタリングなど、基本的には、現在は、Egress 側に近い地点(すなわち受信オブジェクト側)で対処している。Ingress
側での迅速な対応が実現すれば、ネットワーク内に本質的に不必要なトラフィックを削減できるなどの効用も期待できるであろう。

2.2.1.5 提案アーキテクチャ; IRIDES
2.2.1.5.1 IRIDES アーキテクチャ
Destination-based Routing アーキテクチャに伴う不十分な転送パス制御とアドレスの集約化にともなう階層化が原因で発生する不十分なプラグアンドプレイ機能の 2 つの問題を解決するために、誘導経路情報の広告を用いた IRIDES(Invitation Routing Information
aDvertizement for path Engineering System)アーキテクチャの提案を行う。 本アーキテ
クチャでは、通常のレイヤ 3 転送空間とは別に、トラフィックエンジニアリング可能なルーティング空間(誘導空間)を定義し、誘導空間と通常のレイヤ 3 転送空間との間には複数の誘導ポイント(IIR;Ingress IRIDES Router)ルータを設置する。 なお、誘導空間は、物理的に独立したネットワーク空間でもよいし、通常のレイヤ 2 やレイヤ 3 の基盤上に構築される仮想的なオーバーレイネットワークのどちらでも構わない。 すなわち、独立したネットワーク空間を持つ構造にするか、それとも オーバーレイ方の仮想的な誘導空間を構築するかは、アーキテクチャの具体的な実装方法の選択肢である。
図 2-2-1 に、IRIDES システムにおける通常のレイヤ 3 空間の概念図を示した。 図では、2 つの IIR(IIR1 および IIR2)が、インターネット上に分散配置されている。 IIR1 と IIR2
は、まったく同一の経路情報をインターネットに対して広告する(エニキャスト)。送信元
ノードから転送された IP パケットは、経路制御プロトコル的により近い IIR(誘導ポイン
ト)に転送(誘導)され、IIR を通して誘導空間に誘導転送される。

36- 36 -

Fig 2-2-1 通常のレイヤ空間での IRIDES の構成概念図
図 2-2-2 に、誘導空間(Traffic Engineering Plane)上に存在する宛先ホスト(DH1)に、3
つの異なるホスト(SH1,SH2,SH3)から IP パケットが転送される場合を示した。送信側から送信された同一宛先 IP アドレスを持つ IP パケットは、経路制御的にもっとも近接する誘導ポイント(IIR)に誘導される。 IIR を通じて誘導空間に転送された IP パケットは、誘導空間で適用されている経路制御方式に従って、宛先ホスト(DH1)に転送される。IIR では、受信した IP パケット内の宛先 IP アドレス情報(+その他の IP パケットフロー識別子情報)から、誘導空間での経路制御で使用されるパケットの転送のための識別子を選択し、適切なデータフォーマットに変換し、これを誘導空間に転送する。なお、誘導空間で使用される経路制御のための識別子としては、MPLS のラベルや VLAN タグ、IP トンネル用 IP アドレ
ス、あるいは IPv6 アドレスなど、誘導空間ネットワークの運用者が適切な識別子を自由に選択可能とすることができる。

37- 37 -

図 2-2-2 IRIDES における IP パケットの転送概念図
さらに、図 2-2-3 には、いったん誘導空間に転送された IP パケットが、EIR(Egress IRIDES
Router)を経由して、再び、通常のレイヤ 3 空間上の宛先ネットワークに転送される場合を示した。宛先ネットワークが、トランジットを行わないスタブ型のネットワークであれば、誘導空間をバイパス経路として、誘導空間が接続するルーティングドメイン上で自由な転送パスを定義利用することを可能とすることができる。

38- 38 -

図 2-2-3 誘導空間をバイパス経路とする構成例
図 2-2-4 に、IIR から EIR あるいは宛先ホストに対して、複数の経路を提供する場合の構成例を示した。 図では、2 つの誘導ポイント(IIR)から、それぞれ、2 つの独立なデータ
転送パスを提供しており、合計で 4 本の転送パスが提供されている。 IIR においては、どのようなポリシーで、2 つのパスを利用するかの判断をローカル判断で行うことができる。

図 2-2-4 誘導空間におけるマルチパスの提供
上述した IRIDES アーキテクチャは、以下に示したような技術的な特長を持つ。
(1) エニキャスト技術を用いた誘導ポイント(IIR)の分散配置(a)
スケーラビリティー39- 39 -

IIR の負荷分散が経路制御によって実現されるとともに、宛先オブジェクトへの転送パスを分散させることができる。IIR は、原理的には、グローバルインター
ネット上に分散配置することも可能である。
(b)
転送経路の最適化
送信元オブジェクトにもっとも近接する IIR を経由して IP パケットの転送を行うことができるために、結果的に、より適切な経路を利用可能にすることができる。
(c)
Ingress 側での制御の可能性
DDOS への対応、輻輳制御、あるいは、ポリシー制御を、IIR において実行することが可能となる。
(2) 既存の IP インフラストラクチャーとの共存
エッジを既存の IP インフラストラクチャ、コアをトラフィックエンジニアリング可能な誘導空間として構築することで、すべての既存ホストおよびネットワークとの共存を可
能にする。
(a)
誘導空間で使用する IP パケットのトランスポート技術は、特定の技術に固定されず、任意の転送方法を適用可能にすることができる。
(b)
図 2-3-2 および図 2-3-3 に示したように、既存の IP インフラと誘導空間をまたがったネットワーク上で、宛先オブジェクトからすべての送信元オブジェクトへのスパニングツリーが形成される。 このスパニングツリーは、既存の経路制御システムで形成されるスパニングツリーよりも、共有部分を小さくすることが可
能となる。
(c)
誘導空間(トラフィックエンジニアリングプレーン)での IP パケットの転送パス
は、既存の経路制御をもとに計算される転送パスとは独立に定義することができる。
(d)
既存の経路制御システムとの共存が容易に実現可能である。
(e)
誘導空間におけるネットワークトポロジーの定義は、既存の IP インフラのものとは独立に定義可能であり、不均一なネットワーク基盤でも、同一の機能を持ったノードからなる均一な仮想ネットを定義することができる。現実のネットワー
クにおいては、仮に、単一ベンダーで構成されたネットワークも、各ノードごろに提供機能には、不均一性が存在する場合が一般的である。
(3) ポータブルアドレス環境の提供
エンドツーエンドでの IP パケット通信のための IP アドレスと、誘導空間におけるトラフィックエンジニアリングのためのアドレス(識別子)の分離により、エンドオブジェ
クト(ノードあるいはネットワーク)は、結果的に、ポータブルな IP アドレス空間を獲得することができるようになる。 ポータブルアドレスの提供により、モバイルオブジ
ェクトへの対応とプラグアンドプレイ環境(設定変更フリーという意味での)の提供を可能とする。
IRIDES アーキテクチャでは、現在のインターネットシステムにおける、エンドノード(正確にはインターフェース)の識別を行うためのグローバルな識別子と、そこへの IP パケッ
トの配送に必要な経路制御に必要となる識別子を同一のものとし、この識別子のみを用いて転送パスの決定を行っているという、現在のインターネットの本質的な識別子管理と利用のアーキテクチャへの改善を提案している。すなわち、少なくとも、誘導空間においては、エンドノード識別子 と 転送経路決定のための識別子を分離することで、多様な、転送ポスのエンジニアリングを可能としている。

40- 40 -

2.2.1.5.2 IRIDES プロトコルアーキテクチャ
IRIDES シ ス テ ム の プ ロ ト コ ル ア ー キ テ ク チ ャ は 、 有 線 と 無 線 の 区 別 、 お よ び 、Stable/Nomadic/Mobile/Adhoc の区別を行わず、プロトコルアーキテクチャとしては、個別の要素技術を選択/定義可能なメタ言語の構造に似たフレームワークのみの定義を行う
アーキテクチャとして設計する。 これにより、同一のプロトコルアーキテクチャおよびこれを実現するソフトウェアアーキテクチャにおいて、個別技術を取替え可能な構造にする
こと可能にする。
IRIDES システムでは、以下の 3 つのフレームワークを提供する具体的なプロトコル設計
を、今後、進める予定である。
(1)
(2)

(3)

誘導空間(トラフィックエンジニアリングプレーン)におけるデータ転送方式/プ
ロトコルを選択可能にする API(Application Interface)。
EIR と IIR 間でのデータベース同期プロトコル。 具体的に必要な作業は、iBGPにおける作業とほぼ同一であるので、iBGP ベースのプロトコルアーキテクチャが現実的であろう。また、大規模化(IIR や EIR の数の増大への対処)は、RR(Route
Reflector)と同様の手法を導入することによって、必要となるデータ同期の量を、O(n^2)から O(n)に削減させることが可能である。
送信元オブジェクトからのポリシー登録プロトコル。 IIR における制御ポリシ
ーは、送信元オブジェクト(あるいはネットワーク運用者)が指定/登録可能にすることが望ましい。

2.2.1.6 問題点と今後の課題
IRIDES アーキテクチャの問題点と課題としては、以下の点が挙げられる。
[問題点]
(1)
ルーティングループへの対処: 既存の経路制御プロトコルが決定する IP パケッ
トの転送経路とは異なるパスを利用するので、本質的に、ルーティングループの発生の可能性がある。 この問題は、類似の機能とサービスを提供する MPLS において、既に、議論され、ループ検出のためのプロトコルの提案と標準化が完了している。 IRIDES システムにおいても、同様のループ検出プロトコルを定義する必要があるかは、実運用の形態などを鑑み決定されるべきであろう。
(2)
エンドエンドアーキテクチャ: IIR および EIR においては、透明なレイヤ 3 以上の処理を行っており、エンドエンドアーキテクチャの特長を喪失していないかの検討を行う必要がある。
(a) 中継ノードでの処理: IIR および EIR で必要となる機能は、現在のルータで行われているものとほぼ同程度のものであり、IP パケットの転送パフォーマンス
上の問題は、発生しないと考えられる。
(b) エンドエンド到達性の保障: IIR および EIR では、アーキテクチャ上、NAT ア
ーキテクチャと同様に、IP アドレスの変換も可能とすることができる。これによる、エンドエンドでの到達性の喪失の可能性が発生することは、十分に留意され、実システムへの適用と運用が行われなければならない。
[今後の課題](1) 宛先のアドレス解決と表現手法
誘導空間での EIR および宛先ホストへのデータ転送に必要な識別子(=アドレス)の解決手法とその表現手法の正規化と標準化を行う必要がある。

41- 41 -

(2) トラフィックエンジニアリングツールの汎用化
ルーティングループの検出、転送経路の把握とエンジニアリングツールの確立など、現在のインターネットシステムでは、確立してないツール群の汎用化と整備を行う必要がある。
(3) 個別プロトコルの設計上述した 3 つのプロトコルコンポーネントフレームワークの具体的な設計定義を行わなければならない。
2.2.1.7 IRIDES アーキテクチャの適用例
本章では、IRIDES アーキテクチャのアプリケーション(適用例)という観点から、いくつかの既存のアーキテクチャを考察する。 本報告では、IRIDES アーキテクチャとして、エッジが既存インターネットシステムでコアがトラフィックエンジニアリング可能なネットワークとしているが、実際には、これらは、基本的には双対の関係にすることが可能である。 すなわち、上述のアーキテクチャとは逆の構成で、コアが既存のインターネットシス
テムで、エッジが、新しいネットワーク(例えば、IPv6 やプライベートネットワーク)とすることも可能である。
2.2.1.7.1 MIP と NEMO
マルチホームアーキテクチャでは、複数の HA(Home Agent)をインターネット上に分散配置し、複数の IP アドレスを持つ MH(Mobile Host)あるいは MR(Mobile Router)に対して、
HA から複数のパケット転送パスを設定することで、マルチホーム環境を、MH および MRに接続された移動ネットワークに提供するものである。 複数の HA は、すべて同一の経路情報をインターネットに広告し(誘導経路情報＝エニキャスト)することによって、インターネットからの誘導ポイント(IIR)へのアクセスを地理的に分散することができる。また、
NEMO での議論においては、HA 間では、iBGP に似た HA-HA プロトコルを用いた HA が持つデータベースの同期が行われる。
2.2.1.7.2 SHAKESHAKE(SHAred multiple paths protocol for cluster networK Environment)は、Mobile
IP を拡張して、複数の External への接続性を持つノードが、広帯域な Internal リンク(e.g., WiFi や BlueToorh)を利用しながら協力しあい、より、広帯域な External 通信を実現するアーキテクチャである。このアーキテクチャは図 2-3-3 に示した構成と捕らえることができる。 SHAKE では、HA が IIR(誘導ポイント)に対応する。
2.2.1.7.3 MPLS
MPLS のエッジルータが、IIR(誘導ポイント)と考えればよい。ただし、IRR は、基本的には、誘導経路情報の広告は行わず、通常のレイヤ 3 の転送経路上で、MPLS エッジルータが、IP パケットを強制的にトラップして、誘導空間に導入するアーキテクチャであると、解釈することができる。 誘導空間における IP パケットフローの識別と転送経路の決定のための識別子は、データプレーンとコントロールプレーンに別れていて、これらのマッピング
が、各ルータでとられている。データプレーンでは、MPLS ラベルが、両方に共通の識別子となる。コントロールプレーンでは、IP パケットフローの識別は FEC(Forward EquivalentClass)で行われ、経路決定のための識別子は宛先の IP アドレスとなる。
2.2.1.7.4 NAT
エッジが Private アドレスを用いたネットワーク、コアがグローバル IP アドレスを用いたネットワークという構成である。NAT ルータは、IIR にあたる。 図 2-3-3 に示した EIR

42- 42 -

が存在する場合も、さまざまな技術を用いて実現することは不可能ではない。 一般的に、IIR(NAT ルータ)は、NAT セグメントに対しては、グローバルには重複のある(＝同一の)Default Route の情報を広告することになる。 IIR では、IP アドレスの変換テーブルが生成される。 誘導空間での IP パケットフローの識別子はグローバルな宛先ホストの IP
アドレスか EIR(=NAT ルータ)の誘導空間側のグローバルな IP アドレスになる。
2.2.1.7.5 6to4, ISATAP
6to4 は、IPv4 のネットワーク上で、IPv6 のネットワークセグメントを相互接続しルー
ティングを行うアーキテクチャである。IPv6 のネットワークセグメントには、IPv6 のアドレスプレフィックスとともに、中継ルータの IPv4 アドレスが割り当てられる。 IPv4 ネッ
トがコアネット(誘導空間)、IPv6 ネットがエッジとなり、6-to-4 ルータが IIR および EIRに対応することになる。誘導空間でのフローの識別子は宛先ホストの IPv6 のアドレス(プレフィックス)であり、経路制御決定のための識別子は 6-to-4 ルータ(=EIR)の IPv4 アドレ
スとなる。
ISATAP は、IPv6 アドレスフォーマットの下位 32 ビット中に、IPv4 のアドレスを埋め込
むアーキテクチャである。6-to-4 と同様に、IPv4 ネットがコアネット(誘導空間)、IPv6
ネットがエッジとなる誘導空間でのフローの識別子と経路制御決定のための識別子は、ともに、宛先ホストの(宛先 IPv6 アドレス中の)IPv4 のアドレス部分である。
NAT や MPLS と同様に、IIR からの誘導経路の広告は行われない。
2.2.1.7.6 マルチキャスト
現在のインターネットは、ユニキャストサービスを基本としており、必ずしもマルチキャストサービスを本格的に提供はしていないし、ネットワーク内で使用されているルータのマルチキャスト機能のサポートの状況は、同一ベンダーが提供するルータですら、残念ながら、一様ではない状況である。 また、現在最も広く利用されている PIM(Protocol
Independent Multicast)は、RPF(Reverse Path Forwarding)のメカニズムを用いたマルチ
キャストパケットの転送を行っており、マルチキャストパケットの転送ツリーは、ユニキ
ャストの転送経路から一意に決められてしまう。
これら 2 つの問題を、IRIDES アーキテクチャを適用することで解決することができる可能性がある。 PIM における RP(Rendevous Point)を IIR とし、誘導空間のネットワークトポ
ロジーをマルチキャスト機能を持った適切なノードのみから構成されるネットワークにすることで、不均一なノードから構成されるネットワークにおいても、ユニキャストのパケ
ット転送経路に独立なマルチキャストサービスが実現可能となる。
2.2.1.8 まとめ
現在の経路制御システムがグローバルスケールでの、宛先アドレスをルートとしたスパ
ニングツリー型のパスをもとに IP パケットの転送を行っているために、必ずしも自由なパスの制御を実現することが容易ではない。 本節では、エニキャストの概念を拡張した誘導
経路情報の広告を用いたインターネットパス制御アーキテクチャ(IRIDES; Invitation
Routing Information aDvertizement for path Engineering System)の提案を行った。 提案アーキテクチャは、既存の経路制御システムとの共存が可能であり、十分なスケーラビ
リティーを持つ。 さらに、提案アーキテクチャをもとに、いくつかの具体的なアプリケー
ション(e.g.,マルチエージャント型マルチホーム NEMO/MIP)が実現されることを示した。
今後は、誘導空間における汎用的な宛先のアドレス解決と表現手法と、 トラフィックエ
ンジニアリングツールの汎用化、さらに、3 つのプロトコルコンポーネントの設計を行う予定である。

43- 43 -

2.2.2. センサーネットワーク(Live E!) の応用について
2.2.2.1. 概要
頻発する異常気象や震災によって影響を受ける都市活動や市民/経済生活などに関して、近年のセンサデバイスや情報処理技術の発達に伴い、詳しい因果関係の解明や事前予知の可能性が期待されている。一方で、先進国での都市活動の変化と、アジアを中心とした人口集
中地域での大都市化の進展は、地球上での気象変化をより一層複雑化しており、COP3（気候変動枠組条約第3回締約国会議）で採択され2005年2月に発効した京都議定書による温暖化対策等の展開も含めて、今後の経済社会活動に対して多くの変革を要請している。こうした中で、インターネットへの接続性を高めた環境情報観測ユニット（「ディジタル百葉箱」）
が研究開発され、その低コスト化とともに観測や分析ツールも充実しつつある。さらに、IP技術を基盤としたブロードバンドインターネット環境の整備とユビキタスネットワーク環
境の構築は、これら環境情報センサをインターネットに接続可能とし、自立的な環境情報の共有と加工を実現する環境の構築を推進可能としつつある。高度な環境情報について、WEB
カメラや関連する他のデバイスとの組み合わせによる効果、さらにはバスや鉄道といった移動体が生成する環境情報も含めて、従来の常識を超えた密度と精度、そしてリアルタイム性を伴って地球上に設置することが可能となりつつある。それらを活用した分析や予測が、市民生活に及ぼす効果と貢献の大きさは計り知れず、市民ニーズから派生する新しいビジネスやサービスに対する期待もまた大きい。個人および組織が自律的に設置運営する「ディジタル環境情報センサ」が生成する種々の地球環境に関するディジタル情報を流通させ、自由に利用・加工・共有することが可能なインフラ構築を実現することができれば、そこから教育、
公共サービスならびにビジネス分野における新たな活動の展開により、安心安全で効率性の高い活動空間（=環境）の創造が期待される。
インターネットに代表される計算機ネットワークは、電力消費量を増加させた1つの要因とも言われている。事実、計算機は多量の発熱をし、その発熱密度はムーアの法則に従い指数関数的に増大している。インターネットはもともと、計算機が高価であった時代に、ある業務や作業の効率化や支援を行うための計算処理を、遠隔に存在する高価な計算機を用いて実行することを目的として研究開発されたものであった。（ディジタル）情報は、生成、収集、流通、加工、共有の5つの過程から、人々や組織の活動の効率化や高機能化を実現することができる。また、ITを用いた、地球環境保全に関する取り組みと貢献は、IT先進国としての、グローバル社会への責任でもあろう。無駄なエネルギー消費への対策、有害物質の生成排出への対策や、諸外国への展開は、我々が生活および企業活動を展開する“地球”を健全な状態に維持するために、必須の施策でもあるはずである。
2.2.2.2. インターネットシステムの新たな挑戦
2.2.2.2.1 インターネットシステムの再確認
インターネットは、ディジタル情報が自由に流通され、利用されるロジカルな（論理的な）アーキテクチャであり、そのように運用されるべきである。ユビキタスネットワーキ
ングの環境が、徐々に現実性を見出していく中で、このような情報の“流通と加工”に関する「透明性」と「自律性」を提供するシステムアーキテクチャとシステム運用を、どのようにして実現するかは、無駄のない情報空間/活動空間を形成する上で、極めて重要なことである。
「インターネットの父」と呼ばれている CNRI 社（http://www.cnri.reston.va.us/）のRobert Kahn 博士は、
「インターネットはロジカルなアーキテクチャである。いろいろなメディアを自由に選択することができ、そのメディアを介してディジタル情報が流通され利用されることが、インターネットアーキテクチャの鍵である。TCP/IP を用いた、いわゆるインターネットは、その 1 つの実装形態にすぎない。ディジタル情報が自由に流通され利用される基盤を作ること、ディジタル情報の属性をグローバル規模で認識可能な基盤44- 44 -

を作ることが重要ある。
」と言っている。インターネットは、計算機を相互接続し、ディジ
タルデータが多様な通信メディアを介して自由に流通する基盤を提供し、その情報を用いて目的の計算処理を行うものである。インターネットは、(a)利用法（Application）に依存しない、(b)利用者（User）を制限しない、(c)情報を伝達するインフラの種別に依存しないインフラになることができる。これは、人々が自由に情報とインフラを流通利用可能
な、排他性を持たない共用可能なインフラ(=コモンズ[1])を実現したものととらえることができる。これが、広い意味での「オープンシステム」である。
インターネットは、これまで 3 つの大きな波を経験してきている。第 1 の波は、共有言語としての TCP/IP を用いたクローズドな専用システムからグローバルなオープンシステ
ムへの展開、第 2 の波は、初期の WEB 技術を用いた利用者の一般化と利用者数の増加であった。第 3 の波は、WEB サービス/ビジネスを核とした TCP/IP 技術と WEB 技術を用いた、ミッションクリティカルなビジネス領域へのインターネットの導入である。
そして、現在、「第 4 の波」と言われるブロードバンド化とユビキタス化の波を経験しつつある。ブロードバンド化とは、広帯域の通信容量と常時接続を意味し、ユビキタス化とはセンサやアクチュエータなどを含めたいわゆるノンコンピュータ機器のインターネッ
トシステムへの相互接続を意味している。すなわち、ユビキタス環境では、家庭内の冷蔵庫やガスメータ、屋外の車や自動販売機、さらには販売店で販売される商品、ペットや人間が身につけるディジタル機器、さらにセンサなどの微小デバイスがインターネットに接続される。
インターネットはもともと、ある業務や作業の効率化や支援を行うための計算処理を遠隔に存在する高価な計算機を用いて実行することを目的として研究開発されたものであった。しかし、インターネットは、いくつかの発展段階を経て、すべてのディジタルデバイ
スを相互接続するユビキタスネットワーク環境へと進展しようとしている。ユビキタスネ
ットワーク環境においては、（ディジタル）情報に関する、生成、収集、流通、加工、共有の 5 つの過程から、人々や組織の活動の効率化や高機能化を目指さなければならない。
2.2.2.2.2 ディペンダブルなインターネット基盤の構築
社会生活や産業活動を支えるに資するファシリティネットワークを構築するためには、システムがディペンダブル（Dependable=（頼ることのできる））である必要があり、そのためには、システムの独立性、すなわち自律性（Autonomous）とそれを支えるシステム間での相互接続性の確立が必要となる。システムの自律性は、ユーザに対して利用する機器の選択性と自由度を提供し、その結果から、システム全体の可用性の向上、サービスの継続性の提供などを実現することができる。情報通信システムのディジタル技術は、情報処理と情報伝達の2つの観点から、異なるオブジェクト間での統一的なインタフェースの提供を可能にするためのさまざまな抽象化を提供することができる(すなわちオープンシステム)。我々は、オブジェクトの自律性（Autonomous性）と相互接続性を実現するために、システム設計におけるコモンズ（Commons）[1]の概念の導入とその実践を行わなければならない。
近年になって、従来の計算機システム、特に組み込み系のディジタル機器で仮定しなければならなかった以下のような条件・制約が否定されつつある。
(1) エンドノード/ユーザは低能力である。
(2) ノードは移動しない。
(3) クライアントサーバシステムが安定で効率的である。
(4) 垂直統合システムであるべきである。
(5) 内部は信用可能で、外部に悪漢が存在する。
“ディペンダブル”を考えるとき、大きくは、1つのとても頑丈なシステムをデザインする方法と、複数のそれなりに頑丈なシステムを組み合わせる方法とが考えられる。IP技術を45- 45 -

用いたインターネットシステムの最大の特徴は、いろいろな選択肢が提供可能なことであり、これを、積極的に考慮したディペンダブルの提供を考えるべきであろう。これにより、継続的なサービス提供を行いながら、異なる技術・製品やインフラにスムーズに移行することが可能となる（シームレス性）。
いくつかの視点で、システムのデザインを行う場合のアーキテクチャ的な選択肢に関する議論を行い、ディペンダブルインターネットに向けた情報制御システムのアーキテクチャデ
ザインを以下の5つの視点から簡潔に議論する。
(1) オープンシステム
インタフェースを公開することがオープンシステムの本質である。オープンシステムでは、モジュール（ハードウェア/ソフトウェア）の取替えの可能性を提供することで、結果的に複数の選択枝をユーザに提供する。これにより、市場での競争が発生し、コスト削減と品質向上がもたらされるともに、結果的にはモジュールの継続的供給が実現される。
(2) ピア・ツー・ピアシステム
経済性の観点からは、サービスの集中化と集約化は、基本的にコストダウンを生み、また、
一方で、ビジネスモデルにおけるユーザの囲い込みを可能にする。したがって、多くの場合、
ビジネス性を考慮し、基本的にシステムをClient-Server型で設計する傾向にある。一般的に、Client-Server型のシステムは、Single-Point-of-Failureの構造になり、1つの障害が、システム全体に影響を及ぼすことになってしまう。そのような観点から、ディペンダブルなシステムの構築に向けて、ビジネスモデルとは一見背反するPeer-to-Peerシステムの適切な導入と応用が多くのシステム設計において必要となる。
(3) エンド・ツー・エンドセキュリティ
既存のファイアウォールモデルでは、もはやシステムのセキュリティを守ることができな
いことが明らかとなった。すなわち、エンドエンドセキュリティを基本にした新しいセキュ
リティアーキテクチャと運用の確立が必要となる。
(4) プラグアンドプレイ
機器を設置すれば、動作するために必要な情報をすべてネットワークから獲得し、自律的に動作を開始するシステムの提供である。プラグアンドプレイ技術による各機器の設定の容易性は、システムの構築コスト（設置作業に必要なエンジニアの単価と人数の削減という点での貢献）に直接影響するものであり、システムの導入時の効率化とコスト削減にとって重要な技術要素となる。
(5) グローバルな接続性
すべてのシステムは、もはや単独で運用されるものではなく、すべてのネットワークやネットワーク内のすべての電子機器が自立的に相互にディジタル情報を交換/加工/共有されることを前提に設計運用されることが重要となりつつある。単独のローカルシステムを設計する時点で、それが、グローバルに相互接続されることを想定して、システムデザインを行わないと、個別に設計構築されたシステムが相互接続される際に大きな設定変更が必要となってしまう。過去に、イントラネット（Intranet）がエクストラネット（Extranet）化した際に、非常に大きな金銭面と時間面でのコスト負担が必要であった経験を無駄にしないようにしなければならない。すなわち、「Think Global、Act Local」の思想にたった、“ローカル”システムの設計と実装が必要である。
2.2.2.2.3. ファシリティシステムへの IP 技術の適用
ビルに代表されるファシリティシステムの設計/構築/運用/改修に関するコストモデルの考え方、およびビルシステムが提供すべき機能は、近年、ファシリティ管理システムのアー
キテクチャと運用方法にとって、大きな変革を要求している。ファシリティに関する、改修の容易性、改修によるファシリティの価値の創出が、ファシリティのオーナーにとって、非常に重要な点として認識されるようになってきている。

46- 46 -

ファシリティの経営管理におけるエネルギー（電気/ガス/水道/燃料）に関する支出の比率
は極めて大きく（特に我が国においては）、ファシリティのライフサイクルコストという観点での、エネルギー費の比率は、ビルの設計建築を含む全管理の1/3以上となっていることが報告されている。ある報告では、電算機室に多数の温度センサを配置し、空調関連装置の制御の高機能化を行うことで、40%以上の電力消費量の削減を達成している。
さらに、1997年（平成9年）12月に京都で開催されたCOP3（気候変動枠組条約第3回締約国会議）では、先進国が6種類の地球の温室効果ガスを削減する数値目標と目標達成期間が合意された。我が国では、この京都議定書を受け、省エネ対策強化策の1つとして、「エネ
ルギーの使用の合理化に関する法律（省エネ法）」の改正案が1998年5月に成立した。本改正省エネ法では、例えば特定建築物（2,000平方m以上の新設建築物、あるいは改装建築物）の照明設備の消費エネルギーの判断基準を10～20%強化することなどが義務付けされている。
現在の建築物の制御システムは、残念ながら、空調システムや照明システムなど機能ごとに、独立に、言い換えれば縦割り状に構築運用され、それぞれが、独自（Proprietary）の通信プロトコルを用いて制御情報の交換を行っている。ファシリティに導入される機器（センサノードや制御モジュールを含む）が、オープンで共通仕様に準拠していることは、装置の製造会社間での健全な競争に伴うコストダウン、製造会社に依存しない機器のメンテナン
ス性の確保など、ビルシステムのライフサイクルにわたる低コスト化と安全性向上に大きく寄与するものである。
このような観測制御システムは、単独のファシリティに閉じて独立に運用される形態から、それらが相互に接続され、より高度な計測制御システムへと進化しなければならない。環境
情報がインターネット化され、それぞれのファシリティ運用主体は、これらの環境情報を用いて、所有するファシリティの最適化を行うとともに、ファシリティ間での情報の相互交換/共有による、より高度な効率化へと向かわなければならない。環境情報のインターネット
化、すなわちユビキタスに存在する環境情報センサが生成する環境情報が自由に流通し、加工され共有/再利用される環境を構築し、この環境情報を用いたファシリティの最適化と効率化を推進しなければならない。このような活動は、各企業活動における利益になるばかり
でなく、地球環境の保全という意味での貢献が期待されるものであり、我が国以外の地域における積極的な取り組みを援助・推進することは、我が国の地球に対する責任でもあると言える。
すでに、IPv6 技術を BACnet のシステムに適用して構築されたビルシステムが 8 月末
時点で 10 例以上にのぼっているとの報告が行われている。一方、LonWorks の IPv6 化も精力的に進められているようである。IPv6 普及高度化推進協議会のファシリティーネット
ワーキング分科会では、2004 年 11 月に東京で開催された Global IP Business Exchange
および、2005 年 6 月に幕張で開催された Interop 東京 2005 において、マルチベンダー環
境での IPv6 技術を用いた BACnet システムと LonWorks システムのマルチベンダー環境
での相互接続運用のデモンストレーションを行った。特に、Interop 東京 2005 においては、
会場外のファシリティを NTT 東日本殿のご協力のもと、インターネットにより遠隔接続
し、幕張の会場から遠隔監視ならびに遠隔操作のデモンストレーションを行うことに成功した（図 2-2-2-1）。

47- 47 -

Fig 2-2-2-1. Global IP Business Exchangeにおける相互接続デモンストレーションの概念図
2.2.2.3. Live E!：環境情報のインターネット化に向けて
2.2.2.3.1 Live E!プロジェクトの活動趣旨
2005 年 5 月、IPv6 普及高度化推進協議会と WIDE プロジェクトが主体となって、Live
E!プロジェクト（http://www.live-e.org/）を発足させた。以下の 4 つが本プロジェクトの趣旨である。
(1) みんなが、いろいろな地球環境に関するディジタルデータを持ちよって、自由に利用できるような情報基盤/情報環境を作り出そう。小さなデータを集めて大きな力にしよう。
(2) 地球環境情報の生成と利用に、各人が責任を感じ貢献しよう。
(3) “生”データへの所有権は、公共サービス（Public Service）のために忘れよう。デー
タを自由に利用してもらおう。
(4) みんなで、若い世代の理科/科学への関心を高めよう。
具体的には、個人や組織により、設置運営される「ディジタル百葉箱」等が自律的に生成・取得する、気象情報や都市活動に関する情報など、広義の地球（Earth）に関する生きた（Live）環境（Environment）情報が自由に流通し共有される電子（Electronics）情報基盤を形成発展させ、自律的で自由な環境情報の利用法、安心安全で効率性の高い活動
空間（=環境）の創造を目指す。
地球温暖化対応のような環境保護対策での利用はもちろんのこと、
教育、
公共サービス、
ビジネスアプリケーションなどの分野での自由で自律的な利用法について、積極的な働きかけを促進することを目的としている。本プロジェクトでは、以下の 3 つの分野における環境情報の利用を推進する予定である。
(1) 教育プログラム気象情報をはじめとする環境情報は、物理学関連の教育材料としての利用価値が大きい。初等教育から高等教育まで多様な利用が期待される。
(2) 公共サービス
広域災害の発生時における環境情報の提供は、災害状況の正確な把握と対処法の判断にとって有用となる。また、より詳細で多量の環境情報は、例えば都市部におけるヒートア
イランド現象の把握と分析など、さまざまな環境状態の分析や解析および対策の検討材料として利用可能であろう。あるいは、環境情報を公開することによって、人々や企業の日
常生活において有用な情報となることも期待される。

48- 48 -

(3) ビジネス利用
環境情報を加工して有益な情報を顧客に提供するビジネスや、環境情報を用いて所有する
ファシリティ最適運用を行うなど、多量のデータを利用した精度の高い情報の提供や高度な効率化などが実現される可能性がある。例えば、電力供給会社では、気象情報を用いて、ファシリティ電力消費量を制御することで、必要となる電力供給設備の最適化の可能性も考えられよう。
2.2.2.4 ディジタル百葉箱を用いた気象情報共有システム
Live E! プロジェクトにご賛同いただいた企業、大学、あるいは個人の方々からの機材のご提供と運用へのご協力により、2005年9月末現在で、既に50式以上のディジタル百葉箱が設置され、これらがインターネット接続されている（図2-2-2-2、2-2-2-3）。

Fig. 2-2-2-2. Live E!システムの概要（2005年9月末時点）

49- 49 -

Fig 2-2-2-3. ディジタル百葉箱のシステム構成
各ディジタル百葉箱には、インターネットに接続された世界中の計算機からアクセスすることが可能である。現在のシステムは、データ構造やディレクトリシステム、あるいは認証機能やデータの暗号化あるいはプライバシーにかかわるセキュリティアーキテクチャの研究開発と実証実験を通した技術検証ならびにシステム検証の段階にあり、インターネ
ットからの自由なアクセスは制限させていただいている。しかし、システムの研究開発と技術ならびにシステムの検証後には、インターネットからの自由なアクセス（セキュリテ
ィ機能を導入した上で）を実現させる予定である。
WIDEプロジェクトにおけるインターネット「ディジタル百葉箱」の概念とその利用法を探る先駆的な研究開発活動は、2001年のInterop東京に、横河電機（株）殿との共同研究の
活 動 の 成 果 と し て 行 っ た 、 IPv6 の 通 信 機 能 を 組 み 込 ん だ 温 度 セ ン サ ノ ー ド で あ る“Hot-Node”を用いたデモンストレーションに遡る（図2-2-2-4）。

Fig. 2-2-2-4. Hot-Node（IPv6温度センサ）
100個を超える温度センサノードを幕張の国際展示場に分散配置し、会場の温度分布をリ
アルタイムにインターネット経由で観測するシステムを動態展示した。現在のシステムは、
地上に固定設置した気象センサノードを対象としているが、地上のみならず、海上や空中50- 50 -

を移動する乗り物などに搭載された気象センサノード（あるいは、これらが持つ気象情報）
も、Live E!システムの中の気象センサノードとして取り込む予定である。
WIDEプロジェクトでは、InternetCARプロジェクトにおいて、自動車の持つ種々の環境に関する情報を収集・加工する活動を過去に推進してきており、この活動の成果との融合
も、今後の活動の大きな方向性の1つである。
2.2.3. 大規模小型ノードネットワークにおける XML 翻訳機構の導入
2.2.3.1. 概要
小型ノードを大量にかつ広域に配置したシステムにおいては，アプリケーションへ提供するノードのインタフェース表現に XML 言語を用いる場合が急速に一般化している．アプ
リケーションからの XML で記述された要求に対し，このようなシステムが応答する方法は種々提案されているが，既存の方法では小型ノードへの適用が事実上不可能であるか，あるいは設置可能なノード数に限界が生じてしまう．また，ノードの種類が追加される度にシステムが複雑化してしまうなどの問題もある．そこで本研究では，まず XML の翻訳機構について検討を行い，この機構を実行環境と翻訳手続きとに分離することを提案している．
アプリケーションが実行されるコンピュータに翻訳機構の実行環境を新たに導入し，DNSを利用した翻訳規則提供フレームワークで翻訳手続きを配布する仕組みを新たに導入することで，従来システムの問題点を解決する手法を提案する．すなわち，小型ノードには抽象度の低い様々な形式のインタフェースが備わっていて，かつ，大規模に様々な種類の小型ノードが分散的に配置されているとしても，小型ノードの個別のインタフェースは維持
したままアプリケーションには XML で統一的に表現された抽象的なインタフェースを提供し，かつ，大規模なシステムでも柔軟かつ良好に動作するアーキテクチャを提案する．
2.2.3.2. インタフェース表現形式を統一する一般的な手法
アプリケーションには抽象度が高く統一的な XML インタフェースが提供されるが，対象とするマイコンノードのインタフェースは多様であり，表現形式も様々である．例えば，
UDP ノードであれば，パケット構造でインタフェースを表現することになるであろうし，
TCP ノードであれば，テキスト文などでインタフェースを表現することになるだろう．こ
こでは，このようにノードごとに異なるインタフェースの表現形式を，他の表現形式に変換するための機構として翻訳機構を導入する．
どのようなプロトコルを備えたノードであっても，アプリケーションから見て最終的に同等の機能を持つ場合，それらは「統合可能である」と，ここでは表現することにする．
例えば，温度情報を取得するノードの UDP インタフェース A と，同じく温度情報を取得するノードの TCP インタフェース B があった場合，(精度や誤差といった付随情報などを考慮しても)アプリケーションから見てそれらを同等のものとして扱えるならば，これらは別のプロトコル上でデータを表現しているだけであって，統合可能であると判断できる．統51- 51 -

合可能なノードのインタフェースは，アプリケーションからは唯一のインタフェースに見えるようにすべきで，その唯一のインタフェースの表現を XML で記述するのが目標となる．
統合可能なインタフェースを XML インタフェースに集約する一般的な方法を図 2-2-3-1に示す．

Fig.2-2-3-1 各ノードのインタフェースを XML インタフェースに統合する方法
図 2-2-3-1 は，各ノード A,B,C,D のインタフェースはそれぞれ独自の表現および形式を持っており，それぞれの専用機構を用いて，XML で表現されるインタフェースに統合される
様子を示している．
2.2.3.3. XML 翻訳機構
XML 翻訳機構はミドルウェアとしてではなく，XML 翻訳機構をアプリケーションが搭載されたコンピュータ側に導入することにより翻訳機構を実現するものである．さらに，翻訳の手続きと翻訳の実行環境を分離することで，より柔軟な翻訳機能を実現可能にしている．図 2-2-3-2 に示すように，本研究では XML 翻訳機構をアプリケーション側のクライ
アント・コンピュータに導入する．アプリケーションはローカルにある翻訳機構が持つインタフェースを通じて，ネットワーク上のマイコンノードと通信する．

Fig 2-2-3-2. XML 翻訳機構の配置

52- 52 -

Fig 2-2-3-3. 翻訳機構の構造上の相違点
左が静的翻訳機構，右が動的翻訳機構
静的翻訳機構は，各翻訳機が翻訳手続きと翻訳実行環境とを一体化させて組まれており，それらのコレクションとして構成されていた．しかし，本研究で提案している翻訳機構は，
翻訳手続きと実行環境とが分離されている．すなわち，翻訳機構自体は翻訳の実行環境のみを提供するものであって，具体的な翻訳の方法をあらかじめ知っておく必要はないが、動的翻訳機構は，アプリケーションが通信対象とするノードを指定することで，具体的な翻訳の方法が記述された文書(以下，翻訳規則と呼ぶ)を導入・適用し，その翻訳規則に従って，翻訳を実行するインタプリタ方式をとる．
静的翻訳機構と動的翻訳機構の決定的な違いは，各ノードのインタフェースに関連する情報を翻訳機構の内部に含むか含まないかにある．静的翻訳機構の場合は，翻訳機自体をインタフェースに合致するようにハードコーディングするため，開発段階においてノードの提供者と翻訳機の開発者との間で詳細なプロトコルを規定し，システムに組み込む必要がある．一方，動的翻訳機構の場合は，翻訳規則を翻訳機構から分離することが可能になるため，ノードの提供者は翻訳機の開発者やシステムの管理者に依頼することなく，ノードの実体と抽象的なインタフェースを提供することが可能になる．
2.2.3.4. DNS を用いた翻訳規則提供フレームワーク
アプリケーションがノードと通信する場合に必要となる情報は，ノード名とそれに対する翻訳規則である．翻訳規則を入手することさえできれば，特定のメソッドを使って対象とするノードと通信することが可能になる．本研究では，翻訳規則の配布および入手のためのフレームワークを，ディレクトリサービスとして実現する．
図 2-2-3-4 に具体的な構成を示す．まず，ノードの登録について解説する．ノードの管理53- 53 -

者はノードの実体をネットワーク上に設置したら，そのノードの翻訳規則を翻訳規則サーバに登録する．次に，翻訳規則サーバを DNS で問合わせることができる特別なサービスとするため，ZONE ファイルに NAPTR レコードおよび SRV レコードで翻訳規則サーバの場
所を記述する．

Fig 2-2-3-4 翻訳規則提供フレームワークの構成
ノード名を node01.hogehoge.org とし，そのノードの翻訳規則サーバの場所を FQDN でtrans.hogehoge.org ， IP ア ド レ ス で 192.168.0.3 ， ポ ー ト 番 号 3078 と し た 場 合 ，
node01.hogehoge.org に対する DNS の記述は図 2-2-3-5 のようになる．
node01IN NAPTR 0 0 “s” “trans+tcp” “” _trans._tcp_trans._tcp

IN SRV 0 0 3078 transtrans

IN A 192.168.0.3
Fig 2-2-3-5 node01.hogehoge.org に対する ZONE ファイル記述

NAPTR レコードは，ホスト名に付随しているサービスの場所を SRV レコードのエント
リ，もしくは URI 形式などで示すもので，RFC2915 にて規定されている．図 2-2-3-5 のNAPTR レコードの第 1 項目，第 2 項目はレコードの優先度を示すもの，第 3 項目の”s”は，
後 に 続 く サ ー ビ ス の 場 所 を SRV レ コ ー ド で 記 述 し て あ る こ と を 示 す ． 第 4 項 目の”trans+tcp”はサービス名で，この”trans+tcp”は翻訳規則提供サービスを意味する．第 5
項目は第 3 項目が”u”，すなわち URI でサービスの場所指定をする場合に URI が入る．最後は，_trans._tcp のレコードを引くように指示するものである．
SRV レコードはホスト名で示されたサービスの場所を指定するもので，RFC2782 にて規定されている．NAPTR はホストが複数のサービスを持つことが可能で，サービス名でそれらを識別することが可能であるのに対し，SRV レコードはホストが提供するサービスの場
所を別のホスト名とポート番号で指定するもので，サービス提供場所を複数指定すること

54- 54 -

が可能である．図 2-2-3-5 では，ホスト trans の 3078 番ポートが_trans._tcp のサービス提供場所であることを示している．trans の A レコードを見ると，このホストの IP アドレス
は 192.168.0.3 であることがわかる．
次に，翻訳規則の取得方法について解説する．node01.hogehoge.org を NAPTR レコード
で 問 合 わ せ る と ， DNS は NAPTR レ コ ー ド の 他 に 関 連 す る SRV レ コ ー ド とtrans.hogehoge.org の A レコードを返す．これにより，node01.hogehoge.org の翻訳規則
サーバは，192.168.0.3:3078 にあることがわかる．この情報が得られれば，その翻訳規則
サーバに問合わせを行うことで，目的の翻訳規則を取得することができる．
2.2.3.5. 全体のシステム構成
翻訳規則をネットワーク上から取得し，翻訳機構に提供するための仕組みとして翻訳規則管理機構を導入した全体の構成図を図 2-2-3-6 に示す．

fig 2-2-3-6. 全体の構成図
翻訳規則管理機構は，ノード名に対して翻訳規則を取得し管理する機能をすべて引き受け，翻訳機構に要請のあったノードの翻訳規則を提供する．
2.2.3.6. 動作確認とアプリケーションの実行
翻訳機構と翻訳規則管理機構を実装した後，その処理経過が外部にわかるように，プログラムの各所で標準出力にログメッセージを出力させるように改造を加えたときの結果を
図 2-2-3-7 に示した．

55- 55 -

Fig 2-2-3-7. デバッグ実行の結果
ISNNCommand の postCommand メソッドが呼ばれると，翻訳規則管理機構が指定されたノードの翻訳規則を提供するために，まずキャッシュを検索している．図 2-2-3-7 では，キャッシュに目的の翻訳規則が見つからなかったため，DNS へ node01.jo2lxq.jp の NAPTR
レコードを問い合わせている．その結果，node01.jo2lxq.jp の翻訳規則を管理しているサーバが IP アドレス 192.168.0.3 のポート番号 3078 にあるとわかり，翻訳規則の取得を試みている．翻訳規則の取得に成功すると，それをキャッシュに登録し翻訳機構に渡している．
その後，翻訳機構は翻訳を実行し，メッセージを送信し，メッセージの受信を待ち，受信するとデータグラムを逆翻訳して XML 文を生成しており，最後に，その結果を表示している．
一方，翻訳規則管理機構が翻訳規則の問合わせを受けたときに，目的の翻訳規則がすでにキャッシュに登録されている場合は，キャッシュから読み出された結果を返すだけで，
DNS および翻訳規則サーバへの問い合わせが実行されないことも確認することができた．

56- 56 -

2.3

ネットワーク構築運用支援ツール群の研究開発

2.3.1 マルチホームアーキテクチャ
2.3.1.1

概要

あらましインターネットの発展に伴い，重要度の高いネットワークへの到達性の向上を目指したマルチホーム接続が広く行われるようになった．しかし，現在用いられているマルチホーム方式は，インターネット経路制御に対するインパクトが大きく，さらなるマル
チホーム利用者の増加に耐えられない．また，障害時の到達性向上は実現できるが，流入
トラフィックの制御が困難であるために，正常時にマルチホームによる複数の接続を有効に使い分けることが困難である．我々は，本論文で，これらの問題点を解決する新たなマルチホームアーキテクチャとして多重ルーティングを用いたマルチホームアーキテクチャを提案する．本方式により，マルチホームの主目的である障害時の到達性の向上を実現しつつ，利用者数に対する対規模性の向上と，流入トラフィックの柔軟な制御を可能とする．
2.3.1.2

研究の背景

インターネットは急激に拡大を遂げ，現在では，情報通信における社会基盤の1 つとなっている．このように成長したインターネットにおいては，接続されるネットワークの重要度も様々である．重要度の高いネットワークにおいては，接続回線の障害や輻輳などによるサーバへの到達性の喪失などの問題を回避するために，複数の接続事業者(ISP)等と複数の回線で接続するマルチホーム接続が広く利用されている． 現在広く用いられているマルチホーム接続は，利用者網に対する経路到達性を経路制御システムの作用で冗長化し実現するものが一般的である．この方式では，特に，利用者網宛トラフィックの制御が難しいために，複数の接続をより柔軟かつ効率的に利用したいといった利用者の要求に応えることが困難である．さらには，インターネット上の経路情報数の増加といった大きな問題を抱えており，さらに多くの利用者がマルチホーム接続を利用することは困難である． 本
節では，既存マルチホーム技術の問題点をまとめた上で，指摘した問題点を解決する新たなマルチホームアーキテクチャとして多重ルーティング技術を用いたマルチホーム接続を提案する．そのアーキテクチャに基づいてプロトタイプ実装および運用実験を行なった経験をまとめる．
2.3.1.3

マルチホーム技術の現状と問題点

現在のマルチホーム技術は，利用者網を複数のISP へ接続し，経路制御システムの作用により利用者網に対する経路到達性を向上させるものが一般的である．マルチホーム接続
利用者網は，そのアドレス空間において経路制御プロトコルを用いインターネットへ広告する．該当利用者網宛のパケットは，この経路情報に基づき，いずれかの接続ISP を介し該当利用者網へ到達する． マルチホーム接続の増加に伴い，この方式に基づくマルチホー

57- 57 -

ム接続では，次の問題が表面化しつつある．
-

インターネット上の経路情報の増加-

複数接続の柔軟な制御と有効利用の難しさ-

マルチホーム利用者網の運用の難しさ

まず，インターネット上の経路情報の増加に関する問題について述べる．2003 年現在のイ
ンターネット上の経路数は12 万経路を越え，今なお増加を続けている．経路数の増加は，
バックボーンルータのメモリ空間を圧迫するため，大きな問題となっている．このような経路数の増加を抑制するため，CIDR (Classless Inter-Domain Routing)を用いたプロバイ
ダ集約が広く用いられている．マルチホーム接続では，複数の接続を介しての利用者網への経路到達性を確保するため，利用者網のアドレス空間を利用者網が接続する全てのISP
から広告する必要がある．利用者網の接続先ISP が単一ISP であれば該当ISP における経路集約が可能であるが，冗長性確保の点で不安が残るため，このような形態は極めて稀である．つまり，多くの場合，各ISPは，マルチホーム接続する利用者のアドレス空間を経路集約することなくインターネットへ広告する必要があり(図2-3-1-1)，マルチホーム接続利
用者毎にインターネット上の経路数が1つづつ増加することになる．現在では，インターネ
ット上の経路数の半分以上である約6万経路を，プレフィックス長24 ビット以上の小さな
アドレス空間の経路が占めるに至っている(表2-3-1-1)．これは，マルチホームをはじめとする小さなアドレス空間の利用者の経路がインターネットの経路の半分以上を占めていることを示す．

Fig.2-3-1-1 既存マルチホーム接続における経路広告

58- 58 -

表2-3-1-1

表2-3-1-1 インターネット上の経路数(プレフィックス長毎)次に，複数接続の有効利用の難しさに関して述べる．既存マルチホーム技術の大きな問題は利用者網へ流入するパケットの制御が難しいことである．マルチホーム利用者網とISP との間の経路制御にはAS(Autonomous System)間経路制御プロトコルであるBGP-4 (Border Gateway Protocol version4) を用いるが，BGP-4 では，パケット受信側から流入パケットの制御に関する細かな要求を伝えることは難しい．例えば，利用者網への流入トラフィックをマルチホーム接続する
複数のリンクに均等に割り振るといった制御は非常に難しい．また，流入パケットの制御が経路制御の枠内での制御に限られると，複数のリンクの使い分けは，パケットの始点と宛先の情報のみをもとにしか行なうことができない．例えば，マルチホーム接続において各接続ISP の特性に違いがある場合(一方が広帯域・低品質，もう一方が狭帯域・高品質など)，利用アプリケーション毎にこれらのリンクを使い分けたいといった要求が生じる．既存のマルチホーム技術では，このような要求に応えることは困難である．最後に，マルチ
ホーム接続利用者網の運用の難しさに関して述べる．BGP-4 による経路制御は，インター
ネットのバックボーン上で用いられる高機能で複雑な経路制御プロトコルであり，この運用には高い技術を要する．既存マルチホーム技術では，各利用者網においても，上流ISP との接続にBGP-4 を用いる必要があり，さらに，複数の接続のより有効な利用には，このBGP-4による経路交換において繊細なパラメータ調整が必要である．BGP-4 による経路制御を用いたトラフィック制御は，今日でも技術者の勘に頼る部分も大きく，高い技術力と経験が必要である．

59- 59 -

Fig.2-3-1-2 提案マルチホームアーキテクチャの概要
2.3.1.4

多重ルーティング型マルチホーム

前章で述べた既存マルチホーム技術の問題点を解決するために，我々は経路制御技術だ
けに頼らない，多重ルーティング技術にもとづいたマルチホームアーキテクチャを提案する．
2.3.1.4.1

提案アーキテクチャ概要

既存のマルチホーム方式において，流入トラフィックの制御が困難な点に着目すると，その原因として，利用者網へパケットを送出する側のルータが利用者の制御可能範疇にないことが挙げられる．そこで，提案方式では，トラフィック分散制御装置(DR)と呼ぶ装置をインターネットバックボーン上に導入し，利用者網宛のトラフィックをDR を介して転送することとした．DR では，利用者網宛パケットを解析し利用者のポリシに応じたパケット
配送経路選択等を実現する(図2-3-2-2)．利用者網とDR の間は，マルチホーム接続毎にトンネル等の仮想接続を用いて接続する．また，利用者網側では利用者側終端装置(UR)と呼ぶ装置を導入し，仮想接続を終端する．例えば，2つのISP(ISP-A, ISP-B)を用いてマルチ
ホーム接続する利用者網は，2 種類(ISP-A 経由およびISP-B 経由)の仮想接続でDR と結ばれることとなる．UR においてこの仮想接続を終端する端点アドレスには，各接続ISP から
割り当てられたアドレスを用いる．つまり，ISP-A 側のリンクに割り当てられたアドレス，
および，ISP-B 側のリンクに割り当てられたアドレスである．このようにISP-A および
ISP-B からみると利用者網は，それぞれのISP のアドレスのみを用いた通信を行っているように見え，また，インターネット上のノードから見て，利用者網はDR の先に接続されて60- 60 -

いるように見える．利用者網宛トラフィックは，DR においてパケット解析とポリシに応じたパケット配送経路選択が行われ，利用者宛仮想接続のいずれかを用いてUR へと転送される．DR-UR 間の仮想接続は，利用者網が物理的に接続している接続に対応しており，このDR の選択機能により，利用者網宛各パケットの通るべき物理回線等を選択することが可能である．この経路選択機構においては，一般的な経路選択手法(つまり宛先アドレスのみにもとづいた経路選択)を越えて，より詳細なパケットの特性まで解析した経路選択が可能である．例えば，リアルタイムアプリケーションの通信に対しては低ジッタの経路選択を行
なうようなことも可能となる．また，各物理リンクのトラフィック状況を計測し，その結果を回線選択ポリシにフィードバックすることで，複数のリンクのトラフィックを同等にし, 回線の利用率を高めるような制御も可能である．もちろん，マルチホーム接続において一部接続の障害時にも利用者網への到達性を維持することは最も重要なことである．本アーキテクチャにおいては，経路選択機構と利用者網を接続する仮想接続の状態を常時監視する．経路選択機構では，障害による仮想接続の切断を検出し，該当仮想接続を利用しない経路選択へと動的に経路選択ルールを変更する．これにより，障害のある経路をパケット転送に用いなくなり，利用者網への接続性は維持される．

Fig.2-3-1-3 複数のDR を用いた構成
2.3.1.4.2

利用者網経路情報の広告提案方式においては，利用者網が利用するアドレス空間は，DR を運用する事業者に対して割り当てられたCIDR ブロックから割り当てる．利用者網の経路情報は，複数の利用者網の経路情報を経路集約した上で広告する．これは，提案方式では，各利用者網が物理的に

61- 61 -

どのようなISP 等を介して接続されているかにかかわらず，DR の先に同等に接続されているかのように見えるため，DR における経路集約が可能となるのである．これにより，既存
マルチホーム技術の問題点の1 つとして挙げた，経路数の増加による経路制御システムへの影響を大幅に改善することが可能である．また，利用者網の物理接続先に変更が生じた
場合においても，本方式では，仮想接続の利用者網側端点が変更となるのみで，アドレス・
リナンバリングなどの必要はない．これも，仮想接続の利用者網側端点の変更後も，利用者網は変更前と同等にDR の先に接続されているかのように見えるためである．
2.3.1.4.3

DR の複数化

上述のアーキテクチャにより，利用者網への流入トラフィックの制御は可能となる．また，マルチホーム接続の本来の目的である，一部接続の障害時における利用者網への到達性の維持も可能である．しかし，利用者網宛トラフィックが全てDR を介して配送されるアーキテクチャを採っているため，DR が単一点障害(a single point of failure)の要因となる．この回避のために，複数のDR をインターネット上に分散配置することとする．全DR
は利用者網のUR との間に仮想接続を確立し，利用者網宛のトラフィックは，発信点から最も近いDR を経由し，仮想接続を通して各利用者網に設置されたURへと配送する．つまり，分散配置したDR は通常時は全DR が利用者網宛のパケット配送を行うこととなる(図2-3-1-4)．このように，全DR が同等なパケットの中継処理等を行うために，DR間で利用者
網などに関する情報を常に共有する．DR の障害時，あるいは，DR の保守作業時には，DR からの利用者網経路情報広告を停止することで，該当DR による利用者網宛パケットの中継処理を安全に停止することが可能である．該当DR からの経路広告が停止すると，それまで該当DR で処理されていたトラフィックは，経路制御システムの作用により自動的に次候補のDR において処理されることとなる．

Fig.2-3-1-4 複数のDR 群を用いた構成

62- 62 -

また，この構成により，DR の障害に対する耐故障性の向上のみならず，パケット配送遅延の低減と並列処理によるトラフィック集中の回避といった利点も挙げられる．先に述べた通り，提案アーキテクチャでは，利用者網宛トラフィックは常にDR を介して配送されるが，この影響で利用者網に対して直接配送を行った場合に対しての配送遅延が生じる．ここで，複数のDR がインターネット上に分散配置されることで，この配送遅延を小さなものとできる．また，単一DR 構成では利用者網宛のトラフィックが全て単一のDR を介して配送されるために，DR の負荷増大が懸念されるが，DR の複数化によりDR でのパケット転送処理を分散化できる．
2.3.1.4.4

対規模性の向上手法

前節で述べたDR の複数設置により，DR でのパケット転送処理を分散化することは可能である．しかし，全DR が各利用者宛の仮想接続を保持しているために，利用者数の増加に
より利用者や仮想接続の管理負荷が増大する．このような利用者数の増加に対して，前節で述べたDR 群を複数用意することで対規模性の向上が可能である．最も単純な手法としては，あらかじめ利用者を複数のグループに分割し，各グループに対応するDR 群を設置する．
この場合，各DR 群は群間で完全に独立して動作可能であり，利用者の増加に対し，利用者
グループおよびそれに対応するDR 群を追加設置することでより多くの利用者の収容が可能となる．実際には，インターネット上に分散してDR 設置箇所を確保し，各箇所に利用者
グループ数ずつのDR を設置することとなる(図2-3-1-5)．

Fig.2-3-1-5 実験ネットワークトポロジ

63- 63 -

2.3.1.5

プロトタイプ実装と動作実験

本提案の多重ルーティング型マルチホームアーキテクチャの動作実証のため，プロトタ
イプ実装を行なった．本プロトタイプは，既存方式と比較し提案方式で新たに実現可能となった機能である利用者網への流入トラフィックの細かな制御の実証を目的とした．本プ
ロトタイプで実現した機能は，-

DR-UR 間の仮想接続の確立-

DR での利用者網宛パケット中継-

DR からの利用者網経路広告-

DR における細粒度トラフィック制御である．
本実装は，UR およびDR の実装から構成される．DR-UR間の仮想接続技術としては，IP overIP トンネリング技術の一つであるGRE (Generic Routing Encapsulation)トンネルを採用した．DR では，利用者網アドレス空間の経路広告機能，トラフィック制御に用いる仮想接続の管理，複数の仮想へのトラフィック振り，仮想接続の状態監視機能を実現する機能を実装した．UR では，仮想接続の確立処理，仮想接続を介したパケットの受信処理を実現する機能を実装した．UR およびDR の実装は，ソフトウェアルータとしても広く用いられているNetBSD オペレーティングシステムに対して行なった．この実装は，NetBSD 1.6 RELEASEに対するカーネル拡張とユーザランドアプリケーションの追加から成る．この実装を用いて，図2-3-1-5 に示す実験網を構築し，動作実験を行なった．本実験では，実験網上の任
意のノードからの利用者網宛パケットが，提案アーキテクチャの設計通り，DR を介し，仮想接続(ここではGRE トンネル)を通り，UR へ伝送される基本動作の確認ができた．さらに，
DR において，利用者網宛トラフィックの処理ポリシを設定し，アプリケーション(ポート番号)毎に異なった接続を介してパケットを配送することが可能となっている点も確認した．また，一部の接続の障害時における障害検出と経路切り替えに関しても実験を行った．
利用者網の接続のうち実際にトラフィックが流れている側の接続を切断したところ，約200ms でそのトラフィックが他方の接続を介しての配送へと自動変更されることを確認した．実アプリケーションにおける実験として，DVによる動画伝送アプリケーションを用いた利用者網への動画配信中の回線切断実験を行ったが，回線切り替えの影響は目視上ほとんど気にならない範囲内であり，アプリケーションのセッション断なども生じないことを確認した．
さらに，本提案システムの実運用における知見の獲得を目的とし，本実装の実運用網上で運用する広域運用実験を予定している．
2.3.1.6
2.3.1.6.1

考察と課題
既存方式との比較

本節では，我々の提案する多重ルーティング型マルチホームアーキテクチャの評価とし64- 64 -

て，既存方式に基づくマルチホーム方式との比較を行う．ここでは，マルチホームの主目的である障害時の利用者網への到達性向上効果とともに，2.3.1.3章で既存マルチホームの問題点として挙げた以下の項目に着目し比較した．
-

インターネット上の経路数に与える影響-

複数のリンクの有効な使い分けの容易さ-

利用者網側での運用の容易さ

まず，マルチホーム接続の主目的である，障害時の対象ネットワークへの到達性の向上効
果に関して述べる．既存マルチホームアーキテクチャでは，障害時には，(1)障害箇所でのBGP-4による経路交換が停止し，(2)障害箇所を経由する利用者網宛の経路情報が消失し，(3)他の網を経由する経路が選択され，(4)利用者網への経路到達性が回復する．ところが，
そもそもBGP-4 は頻繁な経路変更を想定したプロトコルではないため，障害を検出した後，経路が安定し到達性が回復するまでにはネットワークの構成にも依るが10 秒から数分程
度の時間を要する．我々の提案方式では，DR-UR 間の生存確認により障害を検出されると，
該当仮想接続を指すDR の経路表エントリを非障害トンネル側に変更するのみで，経路切り替えが完了し利用者網への経路到達性が回復する．このため，生存確認間隔にも依存するが，1 ～数秒程度の時間で経路切り替えが完了し到達性が回復する．
次に，マルチホーム利用者数の増加がインターネット上の経路数に与える影響については，
既存方式が1 ユーザあたり経路数を1 エントリ増加させるのに対し，提案方式では経路選択機構が経路広告時に複数利用者の経路を集約可能となっており，利用者数の増加が経路数に与える影響は限定的なものとなる．また，マルチホーム接続時の複数接続の柔軟な制御という点では，BGP-4 の広告コスト調整のみでしか流入トラフィックを制御できない既存方式は，複数のリンクにトラフィックを均等に割り振るといった制御や，アプリケーシ
ョンの要求に応じた品質のリンクを使用する制御などは不可能である．提案方式では，経路選択機構による柔軟な経路選択(ポリシルーティング)により利用者の要求に柔軟に応じられ，UR 側トラフィック監視機能との連携により先に挙げたようなトラフィック割り振りなどが実現可能である．
さらに，マルチホーム利用者網側の運用コストに関しては，既存方式に高度な経路制御知識が必要であったのに比べ，提案方式では，経路制御などの複雑な運用はDR の運用者(マルチホームサービスの提供者)が行うこととなる．利用者側は，URの設置・運用を行うことになるが，UR では経路制御システム等を動作させる必要はなく，既存方式でのマルチホーム運用に比べ運用は容易となる．その一方で，提案方式では，利用者網と外部ネットワー
クとの間のトラフィックがトンネル等の仮想接続を介して転送されるため，トンネルによる転送オーバヘッド等が問題となる可能性が挙げられる．これに関しては，次節で述べる．
ここまで述べた項目について，表2-3-1-2 にまとめた．これから，我々の提案手法は，既存手法の問題点を解決しつつ基本的機能である障害時の到達性回復時間の短縮も実現した

65- 65 -

と言える．

Table.2-3-1-2 既存方式と提案方式の比較
2.3.1.6.2

仮想接続の利用による影響

前節で述べた通り，提案方式によるマルチホーム接続では，トンネル等の仮想接続を介して転送を行うことによる影響が生じる．これは，パケットがトンネル中を配送される際，トンネル自体を示すIP ヘッダとトンネルヘッダが元のIP パケットに付加されることによる．例えば，今回のプロトタイプ実装のようにトンネル方式としてGRE トンネルを用いた場合，最低28バイト(IP ヘッダ20 バイトとGRE ヘッダ8 バイト)が付加される．
インターネット上の各リンクには，そのデータリンクの特性等に応じてMTU (MaximiseTransfer Unit)が定められている．ここで，トンネル両端点間のMTU (Maximise TransferUnit)を1500 と仮定すると，上記GRE トンネルによる仮想リンクのMTU は28 バイトの縮退により1472 バイトバイトとなる．ところが，実際のインターネット上には，パケットフィ
ルタリング等の設定の誤りからMTU 超過の際の動作を正常に行えないネットワークが数多く存在する．これは大きな問題であるが，MTU 超過処理を正しく行えないネットワークとの通信を維持するために，通常，構築するネットワークのMTU を1500 未満にしないという運用がなされている．先のGRE トンネルの例では，仮想リンクのMTU として1500 を維持す
ると，1472バイトを超過するサイズのパケットをカプセル化した場合，トンネルの両端点間ではIP 断片化された状態で配送される．この場合，1500 バイト長の1 つのパケットを
トンネルを介して送達する際には，1500 バイト長のパケットと48 バイト長のパケットの2つのパケットに断片化し送達される(図2-3-1-6)．

66- 66 -

図2-3-1-6 カプセル化によって生じるIP 断片化
表2-3-1-3 カプセル化前後のパケット長分布の比較

表2-3-1-3 は，インターネットバックボーン上でトラフィックを24時間観測し，パケット総数と消費帯域をそれぞれ100 として，パケット長毎の比率をまとめた．さらに，このトラフィックを提案手法におけるトンネルを介して送った場合，つまり，48 バイト長のカプ
セル化ヘッダを付加し必要に応じてIP 断片化処理を行った場合のパケット数および消費帯域を示している．この結果から，カプセル化処理により，パケット数が約22%，帯域が約6%追加消費されていることが分かる．さらに，パケット長毎のパケット数分布にも変化が見られる．まず，パケット長48 バイトのパケットの増加が顕著だが，これはパケット長1500
バイトのパケットがカプセル化後に断片化された結果生じたものである．さらに，パケッ
ト長1500 バイトのパケットの増加，パケット長48 バイト未満のパケットの急減が見られる．このように，提案アーキテクチャがトンネルを用いたインターネットと利用者網の接続を行っていることによりある程度の影響が生じることが観測された．この影響は，パケ67- 67 -

ット数にしてみると20%を越える増加と大きなものであるが，帯域に対する影響は高々6%程度である．この高々6%の帯域増に関しては，提案アーキテクチャが提供するリンクの有効利用とトラフィック制御に関する利点と比較するとその影響は限定的なものであると言える．
この問題に対する改善手法としては，カプセル化時のパケットサイズに対する影響の小さな方式を用いた仮想接続を用いる方法が挙げられる．例えば，DR-UR 間の網においてMPLS
によるLSP の確立が可能であれば，LSP を用いた接続も利用可能である．さらに，我々は，トンネリングによるMTU 縮退の影響を回避するために，MTU 値に影響を与えないトンネリ
ング手法の開発を試みている．これは，利用者網のアドレス空間が比較的狭域であることなどを利用し，カプセル化の際，IP ヘッダ圧縮技術等を用いることでMTU 縮退を防ぐもの
である．
2.3.1.6.3

DRの設置状況と配送遅延

本アーキテクチャでは，利用者網宛のパケットは，常にDRを経由して配送される．このため，利用者網への最短経路による配送と比較すると，DR へと迂回するためにパケット配
送時間の増加が懸念される．しかし，DR はインターネットバックボーン上に分散配置されるため，十分な数のDR を分散配置することで，その送達遅延の増加は軽微なものとできると考える．具体的には，主要IX の近傍や本マルチホーム利用者の多数接続している網内にDR を設置することで，送達遅延に関する問題は殆んど生じないと考える．そこで、この送達遅延時間の増加問題に関しては，DR の配置状況と遅延時間に関し，予定している実ネッ
トワーク上での広域運用実験を通して評価する予定である．
2.3.1.6.4

セキュリティ

提案アーキテクチャでは利用者網のインターネットとの接続に仮想接続を用いているが，仮想接続の確立時やDR の制御時には，インターネット上での利用者認証が必要である．特に，提案アーキテクチャでは，DR が真正なUR によってのみ正しく制御されることが重要である．DR の制御権あるいはDR-UR間の仮想接続が第三者によって奪取されると，該当利用者網全体が第三者の制御下に陥る恐れがある．このため，UR-DR 間の制御プロトコルの設計においては，制御の正当性検証などセキュリティーの面での考察が重要である．現在，
このような考察のもと，DR-UR 間の制御プロトコル設計と実装を進めている．
2.3.1.7

まとめ

本節では，既存マルチホーム技術の問題点をまとめ，その解決として多重ルーティング型マルチホームアーキテクチャを提案した．このアーキテクチャは，インターネット上の経路数の増加といった既存マルチホームの大きな問題を解決するばかりでなく，利用者ア
プリケーションの要求特性に応じた回線選択といった新たなサービス体系の実現への可能68- 68 -

性を持っている．さらに，特に利用者網への流入トラフィック制御を実現するプロトタイ
プ実装を行ない，その動作を確認した．また，既存方式との比較により提案方式の有効性を示した上で，広域運用実験へ向けて現在進めている実装の拡張や制御プロトコルの設計に関して議論した．

69- 69 -

2.3.2

我が国の国内ブロードバンドトラフィックの測定と解析

2.3.2.1 概要
本節では、インターネットサービスプロバイダ(ISP)７社のバックボーントラフィックを２ヶ月にわたり測定、解析した結果を報告する。 主要な結果は以下の通りである。
1. 国内ブロードバンドカスタマートラフィックは、100Gbps 以上で、年２倍のペースで増加中。さらにトラフィックの方向はほぼ対称
2. 約 70％のブロードバンドカスタマートラフィックは昼夜を問わず一定。
3. カスタマートラフィックの総量は、オフィスユーザトラフィックやアカデミックトラフ
ィックより多く、バックボーントラフィックの統計的な性質は、カスタマートラフィッ
クの性質によって決定される
4. 各 ISP 間でのプライベートピアリングに流れるトラフィックは、６大インターネットイ
クスチェンジ(IX)向けのトラフィックとほぼ同程度であり、IX のトラフィックのみから
国内トラフィック量を推定することは過小評価となる。
5. 海外向けトラフィックは、ISP トラフィックの 23％を占めるが、その方向については非
常に強い非対称性を有する。
2.3.2.2 トラフィックデータ
本研究で、用いたトラフィックデータは国内大手 ISP7 社(IIJ, NTT コミュニケーション
ズ、K-Opticom, KDDI, ソフトバンク BB、日本テレコム、パワードコム)の協力により取得された。 データの取得にあたっては、数 10ms のオーダから、一日レベルのオーダまでの測定粒度が考えられるが、今回は、国内ブロードバンドトラフィックの動向を探るという目的のため、2 時間粒度のトラフィックデータを収集した。これは、各 ISP が既存の良く知られた測定ツールである MRTG/RRDTool を利用しており、2 時間粒度のデータを一ヶ月測定することが比較的容易であったことにも起因する。MRTG/RRDTools では、トラフィックデータを各ルータのインターフェイスごとに取得することが可能である。そのため、データの収集に当たっては、各 ISP の担当者に各ルータのインターフェイスを以下で述べるトラフィックグループに分類する作業を依頼した。そして、各 ISP ごとに得られた一ヶ月分のデータを総計し、その合計トラフィック時系列データを国内ブロードバンドトラフ
ィックデータとした。トラフィックデータグループは５つのクラスから構成される。
A1. 国内ブロードバンドカスタマートラフィック: ADSL、FTTH、CATV 等、各 ISP のカスタマーエッジのトラフィック
A2. A1 以外のカスタマートラフィック: データセンター、専用線、ダイアルアップ、第 2、第 3 レベルの ISP
B1. 6IX トラフィック: 各 ISP と国内大手 IX(JPNAP、JPIX、NSPIXP のそれぞれ東京
および大阪間の IX)トラフィック
B2. 他の国内トラフィック: プライベートピアリングトラフィック、地域 IX トラフィッ

70- 70 -

ク
B3. 国際トラフィック
これ以外に、地域のトラフィック特性を調査するために
C. 都道府県別データを収集した。C は A1 をさらに細かく分類したものであるが、全ての ISP データを取得することが技術的に困難であるため、2 社のデータのみを使用した。
また、各トラフィックグループのデータはそれぞれ方向(In, Out)を持ち、In は各 ISP への
トラフィックを表し、Out は各 ISP からのデータを表す。例えば、A1 の In は ISP よりカスタマーへのトラフィック(いわゆるダウンロードトラフィック)であり、Out はカスタマー
より ISP へのトラフィックとなる。
2.3.2.3 データ解析結果(国内トラフィックの挙動)

図 2.3.2.1: A1 トラフィック
図 2.3.2.1 は一ヶ月分の A1 トラフィックデータを一週間表示として表したものである(各プ
ロット 5 週間分の平均値である)。In トラフィックが黒、Out トラフィックが灰色であるが、(Out が若干多いものの)両者のトラフィックはほぼ対称であることがわかる。これは、一般的に言われている「カスタマーのインターネットの利用はダウンロードがほとんどである」という主張が当てはまらないことを意味している。同様に両トラフィックデータは100Gbps 程度であるが、その 70％程度は一定となっている。このような一定量のトラフィ
ックは、昼夜を問わずに P2P 等の大きな帯域を必要とするアプリケーションが支配的であることを示唆している。また、ダイアルアップサービスが主流であった際の特徴である、
23 時近辺でのトラフィックの急激な増加は観測されず、21 時から 23 時にかけてピークとなる。これは、カスタマーのインターネットの利用パターンが、テレビを見るのと同じよ
うに、日々の生活時間に浸透していると考えられる。他方、アカデミックトラフィックや
オフィストラフィックで典型的な昼間のアクティビティーは平日では確認できない。さらにトラフィックパターンは平日ではほぼ同じであるものの、週末では昼間のトラフィック

71- 71 -

の増加により、平均トラフィックが増えていることがわかる。

図 2.3.2.2: A2 トラフィック
次に、それ以外のカスタマートラフィックである A2 の結果を図 2.3.2.2 に示す。このデー
タは技術的な問題で 7 社のうち 4 社のみのデータとなっているため、A1 と絶対量を比較することができないことに注意が必要である。データを見ると、In/Out の対称性およびピー
ク時間帯の傾向は A1 データとほぼ同じであることがわかる。しかしながら、オフィス時間(8 時〜18 時)にも 15Gbps 程度のトラフィックを観測しており、これはオフィスユーザの挙動が反映していると考えられる。

図 2.3.2.3: アカデミックトラフィック
A1 および A2 データとの比較のために、同時期に取得したアカデミックトラフィックのト
ラフィックパターンを図 2.3.2.3 に示す。このデータは ABILENE(Internet2)のバックボー
ントラフィックである。図より明らかなとおり、アカデミックトラフィックの傾向はカス
タマートラフィックのそれと大きくことなることがわかる。特徴的なポイントは(1)平日のピークは昼間、(2)平日に比べて週末は平均トラフィックが減少することである。すなわち、ブロードバンドトラフィックをモデル化する際には、従来の研究で得られてきたアカデミ
ックトラフィックの傾向をそのまま適用することが困難であることがわかる。

72- 72 -

図 2.3.2.4: B1 トラフィック

図 2.3.2.5: B2 トラフィック
次に、カスタマーから生成されたトラフィックならびにカスタマーへのトラフィックがどのような経路を経由するかについて着目する。図 2.3.2.4、図 2.3.2.5 は国内トラフィックのうち 6 大 IX を経由するもの、およびそれ以外の国内経由トラフィックを表している。これらのトラフィックパターンはほぼ同じであり、それぞれブロードバンドカスタマートラフ
ィック(A1)の傾向が反映されている。つまり、国内バックボーンを流れるトラフィックはほぼブロードバンドカスタマートラフィックの統計的性質によって支配されているものと考えられる。
表 2.3.2.1: ISP での収集データと IX での収集データの比較
7ISP による 6IX Out データ(B1)

6IX での収集データ

2004 年 9 月

30.9Gbps

74.5Gbps

2004 年 10 月

31.8Gbps

77.1Gbps

表 2.3.2.1 は今回の解析で ISP において収集された 6IX のトラフィック量および、同時期に直接 6IX で収集されたトラフィック量を表している。両者を比較すると、今回の７社の測定データは 6IX データ中の 40％程度を占めていることがわかる。これより、他のデータにおいても、国内総トラフィックの 40%程度が取得できたものと考えられる。

73- 73 -

図 2.3.2.6: B3 トラフィック
同様に、海外トラフィックに関するデータを図 2.3.2.6 に示す。海外トラフィックデータは今までに見てきたトラフィックデータのパターンと大きく異なり、トラフィックの方向に強い非対称性があることが見てとれる。In トラフィックが Out トラフィックと比べて 40％程度大きく、これは海外コンテンツのダウンロードが支配的であることを意味する。また、In と Out のピーク時間帯が同じであることから、Out トラフィックもまた主として国内のアクティビティーに起因しているものと考えられる。すなわち、ほとんどのトラフィック
は国内から発生していることを表している。
表 2.3.2.2: 国内ブロードバンドトラフィックの増加傾向
2004 年 9 月
2004 年 10 月

2004 年 9 月
2004 年 10 月

A1 (7ISP)

A2 (4ISP)

98.1Gbps(in),14.0Gbps(in)111.8Gbps(out)

13.6Gbps(out)108.3Gbps(in)15.0Gbps(in)124.9Gbps(out)

14.9Gbps(out)B1(7ISP)

B2(7ISP)

B3(7ISP)

35.9Gbps(in)48.2Gbps(in)25.3Gbps(in)30.9Gbps(out)37.8Gbps(out)

14.1Gbps(out)36.3Gbps(in)53.1Gpbs(in)27.7Gbps(in)31.8Gbps(out)41.6Gbps(out)

15.4Gbps(out)

表 2.3.2.2 は各トラフィックグループの一ヶ月ごとの値を表している。各トラフィックグル
ープを比較すると、一ヶ月あたり 6〜7％のトラフィックの増加となっている。これは、年換算ではほぼ２倍となり、ブロードバンド加入者数や 6IX のトラフィックの増加傾向とほぼ同じ割合である。また、6IX のデータ(表 2.3.2.1)より、国内ブロードバンドカスタマー(A1)のトラフィック総量は、133Gbps 程度であると推定できる。同様に、B1(6IX)および B2(プ74
- 74 -

ライベートピアリング他)を比較すると、トラフィック量はほぼ同程度の結果となった。これまでの研究では、データ取得の容易さゆえに IX のデータを用いることが多かった。しかしながら、プライベートピアリングトラフィックが IX トラフィック並に存在することを考えれば、IX トラフィックデータのみで、トラフィック総量を推定することは、大きな下方推定となっていることを意味している。逆に言えば、今後のトラフィック解析において、
プライベートピアリングデータは無視できないことを表している。さらに、国内トラフィ
ック(B1, B2)と国際トラフィック(B3)を比較すると、国際トラフィックは全トラフィックのうち 20％程度を占めていることがわかる。
[解析結果(地方別トラフィックの挙動)]

図 2.3.2.7: 首都圏トラフィック

図 2.3.2.8: 地方トラフィック
次に、都市部および地方部での、ブロードバンドカスタマートラフィックの違いについて解析する。図 2.3.2.7、図 2.3.2.8 は県別のブロードバンドカスタマー(首都圏、地方)のトラ
フィックパターンである。両者を比較すると、トラフィック量は異なるものの、ピーク時
間帯や週末のパターンはほぼ同じであることがわかる。すなわち、都市、地方によるユーザの違いは少ないものと予想される。しかしながら、都市部のトラフィックでは、平日の昼間にも一定量のトラフィックが観測されている。これは、オフィスユーザの挙動と考えられ、都市部のブロードバンドカスタマートラフィックに、ホームユーザだけでなく、75- 75 -

SOHO ユーザも含まれているとみなせば、妥当な結果である。

図 2.3.2.9: 県別人口とトラフィック
さらに、県別データのトラフィック量の違いを知るために、図 2.3.2.9 に県別人口とトラフ
ィック量の関係をプロットした。仮に、都市部において人口に占める(いわゆる)ヘビーユー
ザーの割合が多ければ、人口の大きな領域でプロットが大きく直線からはずれると予想される。しかしながら、データを見てみると、関係はほぼ線形であると読み取れる。この結果は、ヘビーユーザーの存在する確率は、都市、地方に依らずほぼ一定であることを示唆している。

図 2.3.2.10: 県別トラフィックの累積分布

76- 76 -

県別トラフィックの累積分布を図 2.3.2.10 に示す。これは、今後のトラフィックの成長割合を示すものと解釈できる。分布は 700Mbps より手前ではほぼベキ的減衰をとなっている(両軸が対数表示であることに注意)。ベキ的減衰は、多数の都道府県では、トラフィック
量は非常に小さいものの、県当たりの典型的なトラフィック量というものが存在せず、いくつかの多量のトラフィックを送信・受信している都道府県が存在することを表している。
つまり、ネットワークの設計論としては、大多数の都道府県では大きな設備投資が必要でないものの、いくつかの都道府県では集中的に設備の投資が必要となることを示唆している。しかしながら、このベキ的減衰はトラフィックの使用パターンに由来するものではな
く、純粋に人口の関係から導かれることは、県別人口の累積分布を示した図 2.3.4.10 のサ
ブグラフからわかる。つまり、都道府県別の人口比がベキ的減衰を伴うため、そのトラフ
ィックもまたベキ的減衰を示すわけである。
さらに次に示す図は、週間のトラフィックパターンを In、Out で分けて表したグラフである。このデータは、平成 16 年 11 月と平成 17 年 5 月での IN データを計測し書き表したものである。図 2.3.2.11、図 2.3.2.12 と、ほぼ同様の傾向が表れていてトラフィック量の差は IN よりも OUT のほうが増大の幅が大きくなっていることが見て取れる。年度や季節が異なる月の比較であるが、計時的なトラフィック量の傾向はほぼ同じとなったり、平成 16
年 11 月から平成 17 年 5 月までの半年間でトラフィック量が IN は約 50G・OUT は約 80G程度増大してきていることが見て取れる。

平成17年5月(IN)平成16年11月(IN)

図 2.3.2.11: ブロードバンドユーザの週間トラフィック(IN)パターン

77- 77 -

平成17年5月(OUT)

平成16年11月(OUT)

図 2.3.2.12: ブロードバンドユーザの週間トラフィック(OUT)パターン
このようにブロードバンドを利用するユーザの利用形態は時間的な見地からは、それほど変化はないように思えるが、トラフィック量は予想通り指数関数的な増大を見せている。
国内全体のトラフィック量について大変意義のある計測結果が得られており、今後、国内の ISP などのネットワーク設計における指標となると考えられる。
2.3.2.4 まとめと今後の課題
本研究では、国内ブロードバンドトラフィックの増加並びにそのトラフィックパターン
を、国内主要 ISP7 社のデータより明らかにした。収集されたトラフィックデータは、国内
トラフィックのほぼ 40％を占めており、得られた知見は、現在の国内トラフィックデータの統計的性質を忠実に反映したものとなっていると考えられる。解析による主な結果は以下のとおりである。
1. 国内ブロードバンドカスタマートラフィックは、100Gbps 以上で、年２倍のペースで増加中。さらにトラフィックの方向はほぼ対称
2. 約 70％のブロードバンドカスタマートラフィックは昼夜を問わず一定。
3. カスタマートラフィックの総量は、オフィスユーザトラフィックやアカデミックトラフ
ィックより多く、バックボーントラフィックの統計的な性質は、カスタマートラフィッ
クの性質によって決定される
4. 各 ISP 間でのプライベートピアリングに流れるトラフィックは、６大インターネットイ
クスチェンジ(IX)向けのトラフィックとほぼ同程度であり、IX のトラフィックのみから
国内トラフィック量を推定することは過小評価となる。
5. 海外向けトラフィックは、ISP トラフィックの 23％を占めるが、その方向については非常に強い非対称性を有する。
主要 IX の公表データだけでは、日本のトラフィックの総量と実状が正確 には、把握できなかった。そこで、高信頼コアネットワーク技術に関する研究開発において、我が国の総トラフィック量試算ならびにインターネッ トトラフィックの実状分析を、実ネットワーク

78- 78 -

におけるトラフィックデータをもとに、解析把握する試みを、産学官連携で取り組み、その測定解析技術を確立しデータの解析を継続的に行っている。 その結果、試算による総ト
ラヒック量は、2004 年 10 月で 324Gbps、2005 年 5 月で 472Gbps となっており、引き続
き年 200％-300％の速度でトラフィックが増加していることを確認するととともに、ユーザ
トラフィック量の対称化など今まで明らかにされていなかったインターネットトラフィッ
クの実状を解析することができた。
2.3.3

エンドユーザ向け品質測定アプリケーションの開発

2.3.3.1 背景
インターネットのユーザ数の急伸やマルチメディア化によって、ISP はインフラ整備の対応に追われている。品質の高いネットワークを構築するためには、ネットワーク特性を十分に把握した上で、それに基づいたアプリケーション制御、アプリケーションシステム設計が必要になる。特に、従来のネットワーク設計手法論が単一キャリアを前提にした閉じたものであったのに対して、インターネットにおいては広域分散環境において自立的に相互接続するネットワーク設計論が必要になっている。
現在、現状のインターネット環境において品質の測定をいろいろな形で行われてきたが、いずれもある特定の地点間においての測定であり、実際に使っているユーザには直接意味のある区間を計ることのできるものではなかった。そこで、本計測システムを作成した。
2.3.3.2 Inetq(ユーザ計測)の概要
次世代 IX 研究会(Distix)のワーキングループの１つである計測ワーキング(Resilient
Project)グループ活動において、ユーザの端末から特定のサイトに対してエンドツーエンド
で、インターネット品質を測定できるソフトウェア(Inetq)を開発した。このソフトウェア
では、管理サーバにより検証対象となるサイト、ポート数、ペイロード長などを一括管理
し、行き方向の遅延、帰り方向の遅延、RTT や行き TTL、帰り TTL の変動に合わせて経路計測をすることができる。現在、負荷試験などをおこなっており、今後一般ユーザに広く導入してもらい計測を開始する。
計測の区間は、本ソフトウェアと対となるクライアント側のソフトウェアがインストー
ルされている計測 PC から、あらかじめ設置してある特定の被計測サーバ(全国の主要な拠点に複数配置予定)間である。内容は、行きのパケット遅延、帰りのパケット遅延、RTT、行きの TTL、帰りの TTL、そしてパケットロス率である。これらの計測結果より、一般ユーザと特定のサーバ間におけるインターネットの現状をほぼリアルタイムに知ることができるものである。
※ ただし、可視化によりインターネットの状態を知ることができるツールは別で提供される。

79- 79 -

2.3.3.3. エンドユーザ向け品質測定アプリケーションの構成
以下の図 2-3-3-1 は、本ソフトウェアのハードウェア構成図になる。計測対象として協力いただいた全国各地に配置された被計測サーバに対し、本ソフトウェアを導入したユーザの PC 間で遅延や経路を計測し、遅延・パケットロスなどのネットワークの品質を計測する。
また計測して得られたデータはデータ収集サーバに集められ、ほぼリアルタイムでそのネットワーク状況がグラフ化され、WEB により確認できるシステムである。

Fig.2-3-3-1 計測システム構成図
図 2-3-3-2 は、ユーザ側ソフトウェアの機能ごとにモジュール化したシステム構成である。
パラメータや遅延計測データ・経路計測データのアップロードはサーバと定期的に行われる構成になっている。

Fig. 2-3-3-2 ソフトウェア構成図80- 80 -

2.3.3.4. 測定結果の例
図 2-3-3-3、2-3-3-4 では、実際に本ソフトウェアを使用しその結果をグラフ化してみたものである。図 2-3-3-3 は実験室内における測定結果である。こちらは RTT はほぼ一定で推移しているが、行きの遅延時間・帰りの遅延時間の 11 時のあたりでクロスして遅延時間が反転している。これは PC 内の時間が NTP へ接続し時間長されたからではないかと考えられる。このようにμs の時間レベルでは OS の持つ時間に大きく影響を受けてしまう問題もある。

Fig. 2-3-3-3 実験室内でのクライアント－サーバ間の遅延計測
次の図 2-3-3-4 は実験室に設置した被計測サーバに対して、外部で用意した計測クライア
ント間での計測結果である。このように朝 4 時頃から 15 時までの間はそれほどトラフィッ
クの遅延は発生していなかったが、17 時頃から徐々に増え始め日をまたぐ頃には遅延時間は大きくなっている。このように ISP のトラフィック測定の結果とほぼ同様の結果が得られたことより、この計測システムが信頼できるものであるといえる。

Fig. 2-3-3-4 実ネットワークにおけるクライアント－サーバ間の遅延計測81- 81 -

2.3.3.5. まとめ
今年度、ソフトウェアの開発は終了し、テストを行ってきた。今後は、サーバの負荷との兼ね合いもあり、徐々にユーザを増やし、また多くのユーザに参加を促していき、ユー
ザが使用するネットワーク・アプリケーションの品質評価の指標になるように展開していく。また、IPv6 での計測も可能なソフトウェアであることから今後の IPv6 普及時における戦略的なソフトウェアになると考えられる。

82- 82 -

2.4. 広域高信頼性ネットワークの接続性提供
2.4.1 VoIP/SIP 相互接続検証タスクフォースの取り組み
2.4.1.1 概要
IP 電話は２００２年に大手 ISP が IP 電話サービスを始めたのをきっかけとして、現在では企業内だけでなくプロバイダのサービスとして一般家庭にも広く普及し始めている。しかし、VoIP サービスの聡明期では各キャリアや各ベンダーが独自に開発し展開されてきたサービスであり、相互接続性を求めるとなるとサーバ間のみならず、端末間でも十分な相互接続性を確立した相互接続運用には至っていないのが状況である。
そして今後 VoIP システムが現在の「電話」と同様に本格的に普及し、さらに VoIP 技術を核にしたマルチメディアサービスの展開が伴い、産業社会活動において広く利用されるためには、ベンダー間のみならず、プロバイダ間で基本的な相互接続性が実現されなければならない。そこで VoIP システムの相互接続性実現のため JPNIC・WIDE プロジェクトと協力体制を築き、TF を設立し、マルチプロバイダ環境・マルチベンダー環境での相互接続性の確立に向けて検証を進めている。
本文では、本 TF の活動目的を紹介した上で、まず SIP の簡単な例を示し、実際の相互接続検証のモデルを紹介する。そして、これまでに行ってきた相互接続検証の結果を最後にまとめる。
2.4.1.2

VoIP/SIP 相互接続検証タスクフォースの活動

2.4.1.2.1 VoIP/SIP 相互接続検証タスクフォースの活動目的
1) SIP を用いた VoIP システム間での相互接続性の確立を、以下の２つの環境において実現するための技術的検証を行う。
1-1)マルチベンダー環境
1-2)マルチプロバイダ環境
2) 相互接続性の確認と評価を行うために必要な以下の環境を整備する。
2-1)最低限の評価仕様ならびに試験仕様
2-2)評価仕様ならびに試験仕様に従った試験評価ソフトウェア
2-3)相互接続性の確認と評価を行うためのテストベッド環境の提供とイベントの開催
3) 上記の目的を達成するためにグローバルな協力体制の確立とビジネス活動に対して貢献する。
3-1)VoIP システム評価検証シナリオ3-2)VoIP システム評価検証ソフトウェアを公開する。
3-3)VoIP 関連機器のソフトウェアの品質向上と相互接続性の確立

83- 83 -

3-4)VoIP システム間での相互接続性の確立
3-5)VoIP 機器のポータビリティーの確立
3-6)国内外技術標準化機関(IETF, ITU-T, TCC, HATS など)への成果提供・提案
2.4.1.3 実検証モデル

相互接続性の検証では、実運用で考えられるいくつかの検証モデルを想定し検証を進めている。以下が、現在実運用より考えている検証モデルである。
1) TE-ISP 検証
SIP server

TE
検査対象I/F (UNI)

Fig. 2-4-1-1 TE-ISP 検証試験モデル
図 2-4-1-1 の検証モデルは、SIP サーバ下に配置された SIP 端末間での UNI(User
Network Interface)を検証対象として相互接続性を検証するモデルであり、１つのプロバイダに接続する異なるベンダーの端末によるマルチベンダー試験となる。検証内容としては SIP サーバと SIP 端末の接続性と同一 SIP サーバ配下に配置されたベンダーの異なる SIP 端末間での接続性について検証することを目的とする。
2) ISP-ISP 検証
SIP server

TE

検査対象I/F (NNI)

Fig.2-4-1-2 ISP-ISP検証試験モデル

図 2-4-1-2 の検証モデルは、この検証は、SIP サーバ間での NNI(Network–Network
Interface)を検証対象として相互接続性を検証するモデルであり、異なるプロバイダが用意する SIP サーバに接続する異なるベンダーの端末によるマルチプロバイダ/マルチベ84- 84 -

ンダー試験となる。検証内容としては異なる SIP サーバの配下に配置された SIP 端末間での接続性を検証することを目的とする。一方の SIP サーバに接続している SIP 端末と別の SIP サーバに接続している SIP 端末との接続性の検証である。
3) CampusNet-ISP 検証
SIP serverTE

CampusNet

検査対象I/F(UNI/NNI)

Fig.2-4-1-3 CampusNet-ISP検証試験モデル

図 2-4-1-3 の検証モデルは、プロバイダが用意する SIP サーバとプライベートネットワーク内にある SIP サーバ（IP-PBX など）との UNI/NNI を検証対象として相互接続性を検証するモデルであり、マルチプロバイダとマルチベンダー（SIP サーバ、SIP 端末）
による検証試験となる。検証内容としてはプロバイダが用意する SIP サーバに接続する
SIP 端末とプライベートネットワーク内にある SIP サーバに接続する SIP 端末間での接続性の検証である。
4) CampusNet-ISP-(???)-ISP-CampusNet 検証
検査対象I/FSIP server

CampusNet

TE

Fig.2-4-1-4 CampusNet-CampusNet検証試験モデル

図 2-4-1-4 の検証モデルは、プライベートネットワーク内にある SIP サーバ（IP-PBXなど）同士が複数のプロバイダが用意する SIP サーバを経由し繋がっており、UNI/NNIを検証対象として相互接続性の検証を行うモデルである。検証内容としてはあるプライ

85- 85 -

ベートネットワーク内にある SIP 端末が複数の SIP サーバを経由し、違うプライベート
ネットワーク内にある SIP 端末との接続性を検証することを目的とする。
2.4.1.4 検証結果

これまでに TE-ISP 検証試験をフュージョン・コミュニケーションズ株式会社、KDDI
株式会社、NTT グループ（NTT サービスインテグレーション基盤研究所、NTT コミュニケーションズ株式会社、東日本電信電話株式会社、西日本電信電話株式会社）、日本テ
レコム株式会社に対し、各１回～２回程度行ってきた。参加端末ベンダーは、岩崎通信機株式会社、インテック・ウェブ・アンド・ゲノム・インフォマティクス株式会社、NEC
アクセステクニカ株式会社、シスコシステムズ株式会社、株式会社ソフトフロント、株式会社日立コミュニケーションテクノロジー、富士通株式会社、ヤマハ株式会社である。いずれの検証結果も 99％を超える高い成功率を上げている。
(端末が機能未実装の場合は、検証項目から省く。)

また、これらの検証で明らかになった不具合問題につきまして

は、SIP サーバ側・端末側双方にヒアリングを行い、また TTC 標準を判断基準とし、不具合に対応していただいている。また、これらの不具合事例で特に重要と思われる現象があった場合には、国内標準化団体である TTC へ提案作業を行っている。
Table. 2-4-1-1 TE-ISP検証試験リスト
プロバイダ

参加端末数

試験項目数
(基本＋拡張)(1 回目)６端末

７＋１０項目(2 回目)４端末

７＋５４項目KDDI

６端末

７＋３０項目NTT グループ５端末

７＋５４項目

日本テレコム５端末

７＋５４項目

フュージョン・コミュニケーションズ

次に示す表は、各テストにおける成功率を表したものである。表 2-4-1-2 は、実装がない端末はテスト失敗に含めていないものであり、表 2-4-1-3 は、実装がない端末をテ
スト失敗に含めたものである。
Table.2-4-1-2 実装なしを含めないテスト結果
成功率

試験項目
Test run

ISP A ISP B

ISP C ISP D

セッションの確立、発側切断 100

96

100

100

100

セッションの確立、着側切断 100

96

100

100

100

発信のキャンセル

96

100

100

100

着信拒否

91.3

100

95.6

98.6

セッションの保留・保留解除

91.3

96.8

100

100

86
- 86 -

100rel

100

100

セッションタイマー

100

100

100

番号通知

100

100

100

番号非通知

78.8

100

88.9

Table.2-4-1-3 実装なしを含めたテスト結果
成功率

試験項目
Test run

ISP A ISP B

ISP C ISP D

セッションの確立、発側切断 100

96

100

100

100

セッションの確立、着側切断 100

96

100

100

100

発信のキャンセル

88

100

100

100

着信拒否

32.7

88.3

72.5

98.6

セッションの保留・保留解除

51.3

43.6

60.0

58.3

100rel100

41.7

セッションタイマー

47.1

100

100

番号通知

95.0

100

100

番号非通知

43.3

40.0

88.9

この結果を比べてみると、高機能のテストになるにつれて成功率が悪くなると共に、端末の実装状況も少なくなっているのが分かる。端末と事業者間での相互接続試験の度重なる検証の充実と、端末・SIP サーバの実装の向上が必要である。
また、ISP-ISP 検証を上位プロバイダとして NTT グループ（NTT サービスインテグレ
ーション基盤研究所、NTT コミュニケーションズ株式会社、東日本電信電話株式会社、
西日本電信電話株式会社）、KDDI 株式会社、日本テレコム株式会社からの参加があり、端末ベンダーからは、株式会社アズジェント、岩崎通信機株式会社、沖電気工業株式会
社、シスコシステムズ株式会社、富士通株式会社、ヤマハ株式会社の６社７端末で検証を行いました。
検証は 2 段階で行い、まず基本接続の繋がるかどうかの検証を行い、成功率 99.6％の結果を得ることができました。(端末が機能未実装は省く。) その後、高機能接続についての検証を行った。次に示す表 2-4-1-4,2-4-1-5 はその試験内容別の成功率である。
また、この検証でも同様に発生した不具合事例につきましては、特に重要と思われる減少について国内標準化団体である TTC へ提案作業を行っている。

87- 87 -

Table.2-4-1-4 実装なしを含めたテスト結果
試験項目

成功率
未実装を除く

未実装を含むセッションの確立、発側切断

100

100

セッションの確立、着側切断

100

100

発信のキャンセル

100

100

着信拒否

98.6

98.6

Table.2-4-1-5 実装なしを含めたテスト結果
成功率

試験項目
未実装を除く

未実装を含む

着信拒否

99.9

77.3

セッションの保留・保留解除

99.8

72.9

100rel99.2

85.0

セッションタイマー

99.3

85.9

番号通知

100

87.5

番号非通知

99.6

81.6

Fig.2-4-1-5 相互接続検証試験中の様子
2.4.1.5 デモンストレーションによる検証結果の公開

本年度、6 月に開かれました Interop 2005 の IP Communication Pavilion において第一回 ISP-ISP 検証試験結果の「異なる事業者間における相互接続検証試験」のデモン
ストレーション展示を行った。カンファレンスにおいて本活動の紹介もあり、多くの見学者の方やプレスの方々にデモンストレーション会場へ足を運んでいただき、実際に手に触れて体験していただいた。また、12 月に行われた VoiceCon Tokyo 2005 でも第 2
回 ISP-ISP 検証結果のデモンストレーション展示を行いこちらも多くの見学者の方に88- 88 -

本活動を体験していただいた。

2-4-1-6 各イベントにおけるデモンストレーションの様子
2.4.1.6 まとめと今後の課題
本文では、まず VoIP/SIP 相互接続検証タスクフォースの活動概要と SIP の技術について述
べ、当 TF がこれまでに行ってきた検証試験報告をした。各検証モデルの検証で発見された
不具合事例につきましては、国内の標準化団体に対し提案している。また、来年度 4 月に
SIP の国際的な相互接続イベントである SIPit18 を WIDE プロジェクト・JPNIC が中心となり日本で初めて開催することなり、準備を進めた。
今後は、シナリオの拡充と共に新たな組み合わせの検証、各種検証モデルについて検証を進めていく。また国内だけではなく、海外 SIP 端末ベンダーなども含めたよりグローバ
ルな検証活動を推し進め、国内外での VoIP システムの相互接続性の確立を目指す。

89- 89 -

2.5

IPv6 機器検証評価手法とツールの研究開発

2.5.1 概要
IPv6 の最大の特徴である、膨大なアドレス空間により、非 PC 系の機器がネットワークに接続する事が期待されている。一方で、多種多様な機器がネットワークに接続されるため、その相互接続性が重要視されている。本研究開発においては、IPv6 Core Protocol, IPsec,
IKE, MIPv6, SIP といった、各種機能が相互接続を確保するために必要な機能を洗い出し、検査仕様を作成し、検査ツールの開発を行った。本研究開発の一部は、IPv6 Forum のサブ
コミッティで IPv6 Ready Logo を運用する IPv6 Logo Committee や、SIP フォーラムや、
VoIP/SIP 相互接続検証タスクフォースと連携して行った。これにより、各国の識者からのフィードバックを得ることができ、検査仕様をより適切なものにする事ができた。
より詳細な活動範囲を表 2.5.1 に示す。
表2.5.1
技術領域

IPv6機器適合性に関する調査の全体構成
サブテーマ

調査対象

IPv6 Core Protocol

基本仕様

相互接続テストシナリオ

IPsec

基本仕様

相互接続テストシナリオ

IKE

基本仕様

仕様適合性検査仕様およびツール開発

MIPv6

基本仕様

相互接続テストシナリオ

MIPv6 with IKE

仕様適合性検査仕様およびツール開発

基本仕様

相互接続テストシナリオ

SIP接続手順拡張

仕様適合性検査仕様およびツール開発

SIP Forum実装仕様

仕様適合性検査仕様およびツール開発

SIP

2.5.2 研究の背景
IPv6 ネットワークでは、多種多様な機器が接続される事から、その相互接続性が重視されている。IPv6 の関連技術においても同様である。一部のプロトコルにおいては、既に商用利用されているにも拘らず、その相互接続性が問題視されているものも有る。このような相互接続性の欠落した環境が普及すると、機器を購入するユーザや、システムをイング
レーションするエンジニアが、機器の選択をする際に機器の相互接続性を確認する事が必要となる。各々の機器が相互接続性を確保する事で、ユーザが安心して機器を選択・購入できる環境を提供できる事が可能になるため、このような相互接続性の確保をこれからのネットワークを支えるプロトコルに対して提供していく必要が有ります。
本活動においては、IPv6 Core Protocol, IPsec, IKE, MIPv6, SIP を対象とする。
また、本活動は世界中の機器同士が相互接続性を保つ事でより大きな意味を持つため、海外の組織とも協調して推進していく必要が有る。したがって、IPv6 Forum のサブコミッテ

90- 90 -

ィである IPv6 Logo Committee、SIP フォーラムや VoIP/SIP 相互接続タスクフォース等の
国内外の組織と連携しながら、検証評価手法および検査ツールの研究開発を行った。
2.5.3 活動内容
2.5.3.1 IPv6 Ready Logo Program
IPv6 Ready Logo Program とは、IPv6 機器の認定プログラムで、IPv6 Logo Committee の定義する検査をパスしたものにロゴの仕様権を認めると言うものである。2003 年の 10 月にPhase-1 プログラムを開始し、2005 年 2 月に Phase-2 プログラムを開始している。検査は個別の機能がプロトコル仕様に則っている事を確認するための、仕様適合性検査と、機器同士がお互いに接続できる事を確認するための、相互接続検査が有り、認定を受けるためには、これらの両検査をパスする必要が有る。Phase-1 はコネクティビティを確保するために必要な機能にフォーカスしており、Phase-2 はプロフェッショナルな利用に必要な機能にフォーカスしている。
2.5.3.2 IPv6 Core Protocol
IPv6 Core Protocol については、2003 年度に仕様適合性検査仕様の策定、検査ツールの開発を行っている。したがって、2004 年度は、主に Phase-2 プログラム向けの相互接続性
テストシナリオの策定を行った。Phase-1 プログラムにおいては、IPv6 プロトコル仕様、
近隣探索、ステートレスアドレス自動設定、ICMPv6 を対象としていたが、Phase-2 ではこ
れに、経路 MTU 探索機能を加えた。各機能における Phase-1 の相互接続テストシナリオとの違いを以下に述べる。IPv6 プロトコル仕様においては対象とする機能は変わらない。近
隣探索においては、Redirect メッセージの送受信処理を検査対象に加えた。ステートレス
アドレス自動設定においては、複数のプレフィックスを含むルータ広告の送受信処理を検査対象に追加した。また、アドレスの expiration の処理も追加した。ICMPv6 においては、
Multicast Address 宛の ICMPv6 Echo Request の送受信、それに対する、ICMPv6 Echo Replyの送受信処理を追加した。
検査対象となる機器には様々な制約が有るため、検査対象機器上で操作を行うと、できる検査できない検査の違いが大きくなる可能性がある。これを避けるため、極力検査対象ではない参照機器において操作を行う事で、検査対象機能が検査対象機器に依存しないように設計した。
2.5.3.3.

IPsec

IPsec については、2003 年度に仕様適合性検査仕様の策定、検査ツールの開発を行っている。したがって、2004 年度は、主に Phase-2 プログラム向けの相互接続性テストシナリオの策定を行った。IPv6 Core Protocol では機器をホストとルータの 2 つに分類していたが、IPsec では End-Node と Security Gateway(SGW)に分類している。End-Node は IPsec の91- 91 -

SA を終端し、かつ、通信を終端する機器であり、SGW は IPsec の SA を終端し、通信を終端しない機器である。AH と ESP の認証機能は、認証範囲は異なるとはいえ、ESP もパケットの認証機能を持つ事から、今後 AH の利用は減り、ESP の利用が多くなると考え、ESP のみを検査の対象とした。End-Node は Transport モードを必須とし、Tunnel モードをオプションとした。一方、SGW は、Tunnel モードを必須とし、Transport モードをオプションとした。
暗号アルゴリズムとしては、End-Node、SGW 共に 3DES-CBC を必須とし、AES-CBC(128bit)、
DES-CBC および NULL をオプションとした。同様に認証アルゴリズムとしては、HMAC-SHA1を必須とし、AES-XCBC、HMAC-MD5 および NULL をオプションとした。
IPsec は選択しなければならないパラメータが多く、機器によってサポートしいているものが異なるため、相互接続性に影響を及ぼす事、あるいは相互接続できるように数多くのパラメータをサポートする事が要求されていたが、上記のように定義する事で、以下のように最小限の実装で相互接続性が確保できる事になり、かつパラメータの選択肢も保つ事ができる。
表2.5.2
パラメータ

IPsecにおけるパラメータ

必須

オプション

End-Node

Transport

TunnelSGW

TunnelTransport

セキュリティプロトコル

認証機能付き ESP

N/A

暗号アルゴリズム

3DES-CBC

AES-CBC(128bit),DES-CBC,NULL

認証アルゴリズム

HMAC-SHA1

AES-XCBC, HMAC-MD5, NULL

モード

表 2.5.2 に示すように、End-Node と SGW 間は必須となるモードの組み合わせはない。
End-Node が Tunnel モードをサポートするか、SGW が Transport モードをサポートするかの何れかが必要になる。このような使い方の場合、
SGW は End-Node の役割であるため、End-Nodeの要件である Transport をサポートするのが望ましい。同様に End-Node と SGW を超えたノード間の通信は End-Node が Tunnel モードをサポートする必要が有る。IPv6 ネットワーク
における Virtual Private Network 用途の IPsec は今後の動向に追随する必要が有る。

92- 92 -

表2.5.3

IPsecにおけるモードの組み合わせ
TO 必須

オプション

FROM
End-Node と End-Node 間Transport

Tunnel

SGW と SGW 間

TunnelTransport

End-Node と SGW 間-

Transport or Tunnel

End-Node と SGW を超えたノード間-

Tunnel

2.5.3.4.

IKE

IKE については、実装が多く出ている IKEv1 を対象とした。2004 年度は仕様適合性検査仕様の策定、検査ツールの開発を行っている。IKE においても IPsec 同様に機器を End-Nodeと Security Gateway(SGW)に分類している。
IKE においては、ISAKMP SA のネゴシエーションを行うフェーズ１と、IPsec SA のネゴシエーションを行うフェーズ２とに分類される。メッセージ交換タイプには、フェーズ１においては、ID まで保護が可能なメインモードを必須とし、アグレッシブモードをオプションとした。企業における VPN クライアントのような用途では、外出先の PC から会社の SGW と
IPsec SA を確立する必要が有る。このような場合は、VPN クライアントのアドレスが固定されないため、アグレッシブモードが適している。フェーズ１のメッセージ交換タイプについては、今後の動向に追随する必要が有る。フェーズ２においては、クイックモードのみを検査対象とした。
ISAKMP SA のネゴシエーションにおいて交換される、暗号アルゴリズムは 3DES-CBC を必須とし、DES-CBC, AES-CBC(128bit)をオプションとした。ハッシュアルゴリズムは、
HMAC-SHA1 を必須とし、HMAC-MD5 をオプションとした。認証方式は、事前共有秘密鍵暗号方式を必須とし、デジタル署名認証方式（RSA 署名）をオプションとした。Diffie-Hellman
グループは安全性を高めるためにグループ２を必須とし、グループ１をオプションとした。
また今後の計算機の計算能力の向上を考えグループ５、グループ１４もオプションに加えた。ライフタイムのタイプは秒を必須とし、キロバイトをオプションとした。
IPsec SA のネゴシエーションにおいて交換される、カプセル化モードについては、IPsecの検査仕様に習い、End-Node では、Transport モードを必須とし、Tunnel モードをオプシ
ョンとした。同様に SGW は、Tunnel モードを必須とし、Transport モードをオプションとした。セキュリティプロトコルについては、AH と ESP の認証機能は、認証範囲は異なるとはいえ、ESP もパケットの認証機能を持つ事から、今後 AH の利用は減り、ESP の利用が多くなると考え、認証付き ESP を必須とし、ESP をオプションとした。暗号アルゴリズムは、
３DES-CBC を必須とし、DES-CBC、AES-CBC(128bit)、NULL をオプションとした。認証アル
ゴリズムは、HMAC-SHA1 を必須とし、HMAC-MD5、AES-XCBC をオプションとした。ライフタ
イムのタイプは秒を必須とし、キロバイトをオプションとした。

93- 93 -

IKE フェーズ２において、IPsec SA を確立するために、再度 Diffie-Hellman 交換を行ってIPsec SA に使用する秘密対称鍵を生成することで、ISAKMP SA の鍵が破られた場合に、IPsec
SA の秘密対称鍵が解読されないようにする Perfect Forward Secrecy(PFS)と呼ばれる仕組みがある。PFS は鍵の解読に対して有用な手段ではあるが、必ずしも必要ではない上に、処理に時間がかかるため、オプションとした。IPsec SA の確立を完全にしてから、その SA を使用開始したい場合に用いられる Commit Bit は、ISAKMP Informational Exchange のCONNECTED Notify Message と共に使用される。計算処理の遅い装置などが、Commit Bit をセットして相手に ISAKMP メッセージを送信すると、相手に自分の処理が終わった事を
CONNECTED Notify Message で通知するまで、確立した SA の使用を待たせることができ、確立した SA の使用によるパケットのロスを防ぐことができるため、今後要求が高くなる事が考えられる。したがって、Commit Bit と ISAKMP Informational Exchange（CONNECTED Notify
Message）をオプションに加えた。IPsec SA が確立した後で、IPsec SA のライフタイムが経過する前に再度フェーズ２を開始し、新しい IPsec SA を生成する Re-key は、IPsec SAの管理において非常に重要な機能であるため、必須検査対象とした。
IKE の役割は、IPsec SA の確立までを自動で行う事であるが、確立した IPsec SA を使って、実際に IPsec 通信できなくてはならないため、確立した IPsec SA に含まれる、カプセル化
モード、セキュリティプロトコル、暗号アルゴリズム、認証アルゴリズムを使用して IPsec
通信できることも IPsec SA のネゴシエーションと同様に検査対象とした。IPsec 通信における、Anti-replay は再送攻撃を防ぐために重要な機能であるため、パケットを送信ノードにおいては必須機能とし、受信ノードにおいてはオプションとした。

94- 94 -

表2.5.4

IKE検査におけるパラメータ

パラメータ

必須

オプション

メインモードアグレッシブモード

クイックモード-

3DES-CBC

DES-CBC, AES-CBC(128bit)

SHA1
事前共有秘密鍵
暗号方式
グループ 2

MD5
デジタル署名認証方式（RSA）

ライフタイムのタイプ
End-Node
カプセル化モード
SGW

秒
Transport
Tunnelキロバイト
TunnelTransport

セキュリティプロトコル

認証付き ESP

ESP

暗号アルゴリズム

3DES-CBC

DES-CBC ,AES-CBC(128bit),
NULL

認証アルゴリズム

HMAC-SHA1

HMAC-MD5 ,AES-XCBC

ライフタイムのタイプ
IKE フェー PFS
ズ２Commit bit
ISAKMP Informational Exchange(CONNECTED Notify Message)
Re-keyIPsec 通信
End-Node
カプセル化モード
SGW
セキュリティプロトコル

秒
-

キロバイト
○
○

-

○

○
Transport
Tunnel認証付き ESP

暗号アルゴリズム

3DES-CBC

認証アルゴリズム

HMAC-SHA1

TunnelTransport
ESP
DES-CBC ,AES-CBC(128bit),
NULL
HMAC-MD5 ,AES-XCBC

メ ッ セ ー フェーズ１
ジ交換タ
フェーズ２
イプ
暗号アルゴリズムISAKMP SA

ハッシュアルゴリズム
認証方式
Diffie-Hellman グループ

IPsec SA

Anti-replay

2.5.3.5.

送信ノード

グループ 1,5,14

受信ノード

MIPv6

MIPv6 については、2003 年度に基本仕様に関する仕様適合性検査仕様の策定、検査ツールの開発を行っている。したがって、2004 年度は、Phase-2 プログラム向けの相互接続性
テストシナリオの策定を行った。また、Mobile Node(MN)が Home Agent(HA)に位置登録をする際に利用する IPsec SA を IKE により確立する機能(MIPv6 with IKE)について検査仕様書の策定と、検査ツールの開発を行った。
相互接続性テストシナリオについては、基本機能で利用するすべてのメッセージを一本の95- 95 -

シナリオで、検証できるような設計とした。さらに、被検証機器がある機能を有さない場
合、その機能に関わる手順を割愛した場合でも、継続して検査を続けられるように設計した。この策定した検査シナリオは European Telecommunications Standards Institute(ETSI)の主催する 5th IPv6 Plugtests や TAHI Project の主催する 6th TAHI Test Event さらに
Sum Microsystems の主催する Connectathon 2005 において利用しており、高い完成度となっている。
MNがHAに位置登録をする際に利用するIPsecのSAは、今後IKEの利用が多くなると考え、
IPsec SA の確立に鍵交換プロトコル IKE を使用する機能の検査仕様の策定と検査ツールの開発を行った。
MIPv6 における位置登録にIPsecを利用する手法を定義したRFC3776において、ISAKMP SAのネゴシエーションを行うIKEのフェーズ1 にはアグレッシブモードを使用すると定義されている。したがって、フェーズ１のモードに関してはアグレッシブモードのみを対象とする。様々な機器に対応するために、テストを実行する際のいくつかのパラメータを選択できるように設計した。フェーズ1で使用する識別子は、FQDN とUSER FQDN のいずれかを選択可能とした。暗号アルゴリズムとしては、3DES-CBC、DES-CBC および NULL から選択可能とした。認証アルゴリズムとしては、HMAC-SHA1、HMAC-MD5 および NULL から選択可能とした。また、Delete Payload の使用/不使用、テスト項目毎に IPsec SA を確立するか否かを選択可能とした。また、MIPv6 の機能毎に、IPsec で保護するプロトコルを選択可能とした。2004年度の拡張によりIPsec SA の確立方法として、手動による方法と IKE による方法が選択可能となった。
表2.5.5

MIPv6 with IKEにおいて設定可能なパラメータ

設定項目

値

ID_TYPE フェーズ 1

ID_FQDN / ID_USER_FQDN

ID_TYPE フェーズ 2

ID_IPV6_ADDR / ID_IPV6_ADDR_SUBNET

暗号アルゴリズム

3DES-CBC / DES-CBC / NULL

認証アルゴリズム

HMAC-SHA1 / HMAC-MD5 / NULL

Delete Payload

使用 / 不使用

テスト項目毎にIPsecSA確立

使用 / 不使用96- 96 -

表2.5.6

MIPv6 の機能とIPsecの対応表

機能

IPsecモード

保護するプロトコル

IPSec SA確立方法

BU/BA

ESP Transport

MH / any

manual / IKE

RR

ESP Tunnel

MH / any

manual / IKE

MPD

ESP Transport

ICMPv6 / any

manual / IKE

Payload ESP Tunnel

ESP Tunnel

anymanual / IKE

2.5.4. まとめ
IPv6 Core Protocol に関する検査ツールや相互接続テストシナリオは、2005 年 2 月にプログラムスタートした IPv6 Ready Logo Phase-2 において利用されている。また、様々なテストイベントや研究機関においても参照され、利用されている。MIPv6 や IPsec に関する検査ツールや検査シナリオも、IPv6 Ready Logo Program は未だ開始されていないが、多くの開発者、研究機関およびテストイベント等で利用されている。同様に、SIP の検査ツール
や検査シナリオについても、SIP forum の主催する、相互接続テストイベントである SIPit
や、VoIP/SIP 相互接続タスクフォースの主催する相互接続テストなどで利用されている。
このように本活動の成果物が多くのユーザに利用される事により、多くの有益なフィードバックが得られ、結果物そのものが改善されていく。そしてそれらが改善される事でまたユーザが増えていくと言う好循環が生まれている。質のよい検査ツールが多くの開発者に利用されていく事で、ベンダから提供される機器の相互接続性は高まり、結果、ユーザが安心して機器を選択できる環境が整う事になる。また、このような活動が認知される事で、ベンダの相互接続性への関心が高まるという効果も得られている。
以上の事から、このような活動は、IPv6 の機器のみならず、ネットワーク機器等が普及する上で非常に重要な活動であると感じた。また、上述したように、このような活動は長く継続する事で、より大きな効果を得られるものであると感じた。

97- 97 -

２．６ 次世代インターネット相互接続性検証の研究開発
２．６．１

概要

通信・放送融合というキーワードが囁かれ初めて数年が経過した。その間、次世代インターネットの相互接続性という観点から IPv6 ネットワークを構築するルータ、スイッチ類にネットワーク側での研究開発という立場から、IPv6
マルチキャストの相互接続性について検証を実施してきた。これは、次世代イ
ンターネットが目指すライフラインとしての機能を具現化するための技術と位置づけており、通常イメージする地上放送をネットワークで配信するようなことは、現実には、さまざまな制限が存在するわけであるが、単にこれらの利用は、一部であって適用範囲は非常に広い。特に、防災情報の一斉配信技術として、この研究期間中に現実に自治体で実証したケースも実在した。
このように、マルチキャスト技術の高度化と市場へのフィードバックは、新た な ビ ジ ネ ス モ デ ル を 形 成 す る こ と が 可 能 な も の で も あ り 、注 目 を 集 め て い る 。
岡山 RC ではより分かり易いターゲットを用い、①広域的な検証、②スケールの検証、③異ネットワークとの連携による検証といった普及するために不可欠な 要 素 を 個 別 、統 合 し て 行 う 方 式 を 取 っ た 。具 体 的 に は 、「 岡 山 国 体 」を 素 材 とした大規模配信、放送利用の技術レベルを確保するための「さっぽろ雪祭り中継」がそれにあたる。
岡山 RC が過去に行ってきた研究により、ルータの IPv6 マルチキャストに関する性能は飛躍的に向上したと言っても過言ではない。特に、過負荷に対する能力は、コアルータに関して問題の無いレベルに達した。従って、性能評価から 実 運 用 と い う フ ェ ー ズ に 進 む こ と と な り 、信 頼 性 の 確 保 が 重 要 な 課 題 に な る 。
特に、放送利用ということが最有力であることから、信頼性確保については言
うまでもない。
ま た 、 岡 山 R C が 取 り 組 む べ き 事 柄 と し て 、「 技 術 の デ プ ロ イ 」 が あ る 。 研 究
成果を対外的に発表するだけでは、どの程度利用可能なものであるとか、実業務で使えるものなのか対外的には把握しにくい。それに加え、殆どの人は通常利用しているものではない技術であるため、内容的にも解りにくく、必要なものすら見えないということに陥る。従って、先にも述べたが異ネットワークとの連携を積極的に実施し、技術者の交流や技術動向のデプロイ等行うことが必要となっている。今年度実施した実検証では、すべてにおいてさまざまな研究者、技術者、関係者を招聘し、技術のデプロイに関して行ってきた。我々が与えるものも多いが、他の団体が抱える問題や取り巻く環境について等、得るものも非常に多い。
このような環境下において、本報告書では IPv6 マルチキャスト技術の相互接98- 98 -

続性の検証について報告する。
２．６．２

IPv6 PIM-SM RP（Rendezvous Point）の信頼性確保

２．６．２．１

手順の推移

RP の信頼性は、PIM-SM というプロトコルの性質上不可欠なものである。
すべてのソーストラフィックは、ショーテストパス（最短経路）によるマルチ
キャストツリーを確立するまで RP 経由になるため、本プロトコルにおいては
最も負荷のかかるものになる。従って、次のようなフェーズで RP の信頼性確保に関する研究を進めた。
① RP の正副の設置(ア) Candidate-RP による 2 重化理論
② RP の分散(ア) すべてのソーストラフィックを同一 RP にマッピングするのではなく、マルチキャストソース毎に RP を分ける
③ ①、②の複合による強化
２．６．２．２

検証結果

ま ず 最 初 に 行 っ た 取 り 組 み と し て 、① の R P 正 副 が あ る 。こ れ は 、図 2 . 6 . 2 . 2 . 1 、
図 2.6.2.2.2 のとおり、通常は正のルータ A を RP として運用し、Candidate
指定により正がダウンした場合ルータ C を RP として運用させるものである。

図 2.6.2.2.1

RP の正副運用（正常状態）99- 99 -

図 2.6.2.2.2

RP の正副運用（バックアップ状態）

当 然 、こ れ に は ル ー タ A 自 身 が 断 に な っ た 場 合 と 、R P プ ロ セ ス が 断 に な っ た 場
合 と が あ る わ け だ が 、 ど ち ら の 場 合 も R P は 副 に 引 き 継 が れ る 。 N W- A に 接 続
し た 端 末 は 、 N W- A か ら N W- B へ 代 替 え 経 路 が あ る 場 合 の み 切 り 替 わ る 。
この構成の問題としては、ルータ A は RP 負荷が相当高くなるため、パフォ
ー マ ン ス が 十 分 で な け れ ば な ら な い こ と と 、R P 切 替 時 に は マ ル チ キ ャ ス ト が す
べてのサイトにおいて停止することにある。すべてのマルチキャストが一時断になることは、放送利用という点では課題があるが、動作的には保証される。
先述した①のルータ負荷が、信頼性に多大な影響を及ぼすことが実証を通じてわかってきた。特に、コアルータと言われるシャシー型の大型ルータでは、性能に関して問題がないと述べたが、すべてのサイトにおいて高価なものを準備できる環境には無い。従って、これを回避させるため②の方式を実証することとした。
②では、図 2.6.2.2.3 のようにルータ A、B、C をそれぞれ RP とするグループが存在しマルチキャストツリーを形成する。マルチキャストグループは、実質 3 分 割 で き た こ と に な り 、ル ー タ の 負 荷 は 文 字 通 り ３ 分 の 1 に な る 。こ こ で 、図 2.6.2.2.4 のようにルータ A が断または PIM-SM のプロセスが断になった場
合、ルータ A に属していたグループはマルチキャスト断になるが、その他ルータ B、C 配下については影響を受けない。ルータＡ配下が全滅ということは問題があるが、他の箇所に影響を与えないことは実証できた。また、最も考慮して い た 負 荷 の 低 減 に つ い て は C P U 使 用 率 レ ベ ル で 減 少 し て お り 、高 負 荷 に よ る
システム全体の不安定な状態を起こさせないためには、不可欠な構成であることだといえる。

100- 100 -

図 2.6.2.2.3

図 2.6.2.2.4

RP の分散（正常状態）

RP の分散（ルータＡ不具合状態）② の 補 完 を 目 的 と す る ③ で は 、 V R R P （ Vi r t u a l R o u t e r R e d u n d a n t
P r o t o c o l ）＋ P I M - S M と い う 構 成 で 検 証 を 実 施 し た 。② の 全 滅 箇 所 が 補 完 で き
れ ば 、信 頼 性 確 保 に は 最 も 効 果 的 で あ り 、V R R P を 用 い る こ と と し た 。構 成 は 、
図 2 . 6 . 2 . 2 . 5 の よ う に 、ル ー タ A 部 分 を 拡 大 し て 記 述 し た 。ル ー タ A 、A’ は V R R P
により仮想的に 1 台に見える。このとき、図 2.6.2.2.6 のようにルータ A が断101
- 101 -

図 2.6.2.2.5 VRRP+PIM-SM（正常状態）

図 2.6.2.2.6

VRRP+PIM-SM（バックアップ状態）と な れ ば 、 V R R P に よ り ル ー タ A’ が 見 え る 。 こ の 時 、 R P も 引 き 継 ぐ こ と が 今回の検証であるが、実際に RP 動作は問題ないことがわかった。
現実的には、すべてのインターネット通信の冗長性確保のために VRRP を用いるわけであるが、ルータ B をルータ A の Candidate-RP として動作させてい た 場 合 に ど う な る の か ？ と い う 疑 問 が 残 る 。V R R P と P I M - S M の 動 作 順 位 か 、プロトコル実装がどこまで行われているかによって、結果バタつくことも予想される。これは今後の検証としたい。

102- 102 -

２．６．３

実証実験による検証

２．６．３．１

岡山国体映像配信を素材とした地域ネットワークとの連携による IPv6 マルチキャストスケーラビリティの検証

研究成果の精度向上は、JGNⅡの恵まれた研究開発ネットワーク下だけで行
うだけでは達成できない。それは、機器の整備状況、トラフィック量等、実運用環境とは隔たりが大きい。特に、機器の整備状況については顕著であり、キャリアではともかく、地域ネットワークで整備してある機器とはかなりの格差
が あ る 。自 治 体 で は 、こ の よ う な ネ ッ ト ワ ー ク 環 境 下 で I P v 6 マ ル チ キ ャ ス ト の利用用途が見い出されており、地域ネットワークとの連携研究は非常に重要なものだと考えている。
そこで、我々は岡山国体における競技中継を素材とした IPv6 マルチキャスト
検 証 を 、岡 山 情 報 ハ イ ウ ェ イ と い う 地 域 ネ ッ ト ワ ー ク を 介 し て 行 う こ と と し た 。
国体を選択した理由は、ロケーションフリーなコンテンツであることが、視聴
意 欲 を 高 め 、一 次 的 な 受 信 対 象 と な る J G N Ⅱ ア ク セ ス ポ イ ン ト と 、そ れ を 介 して繋がる全国のネットワーク利用者へ本研究開発を通して次世代ネットワークの 周 知 を し た い た め で あ る 。ま た 、ソ ー ス を 設 置 す る 地 域 ネ ッ ト ワ ー ク 側 で は 、技術習得の大きな機会であり、積極的に参加してもらうことにより技術浸透を直接図ることが可能となる。
２．６．３．１．１

検証方式とネットワーク構築

地域ネットワーク連携検証であるため、ソースはすべて岡山情報ハイウェイの IPv6 ネ ッ ト ワ ー ク 上 に 設 置 し た 。 物 理 構 成 的 に は 図 2.6.3.1.1.1 、 図
2 . 6 . 3 . 1 . 1 . 2 の と お り で あ り 、各 拠 点 最 低 1 つ の 送 信 用 P C を 設 置 し て い る 。また 、全 体 イ メ ー ジ は 図 2 . 6 . 3 . 1 . 1 . 3 の よ う な 環 境 で あ り 、す べ て が I P v 6 マ ル チ
キ ャ ス ト に 適 し た 環 境 で は 無 い こ と を 示 し て お く 。AT M 系 も 残 っ た 状 態 で あ り 、ネットワークの過渡期といえる。

103- 103 -

図 2.6.3.1.1.1

岡山国体検証物理構成−１

図 2.6.3.1.1.2

岡山国体検証物理構成−2104- 104 -

図 2.6.3.1.1.3

岡山国体検証イメージ図

105- 105 -

ソ ー ス 数 は 、 D V 系 4 3 c h （ 3 0 M b p s / c h ）、 H D 系 1 c h （ 2 5 M b p s / c h ） で あ り 、
表 2.6.3.1.1.1 のような 24 拠点へカメラを設置した。構成からわかるとおり、岡山情報ハ
イウェイでは POP 毎にルータが存在している 。各 P O P ル ー タ は 、ス タ ー で コ ア ル ー タ へ接続される構成となっている。従って、ほぼ
全 POP ルータが PIM-SM のソース DR となる。また、今回は利用するツールを、運用及び設置、視聴者の参加し易さ等全体的に工夫を施した。
具 体 的 に は 、 ① We b カ メ ラ の 利 用 、 ② チ ャンネル対応 DV 受信アプリケーションである。①は、通常 DV カメラを用いるが、設置するには三脚が必要であることや高価なことがネックになる。ただ映像を流すということではなく、映像の面白さから IPv6 ユニキャ
ス ト に よ る We b コ ン ト ロ ー ル を 利 用 者 が 行
え、映像自身は高精細な DV で送る方式である。②では、図 2.6.3.1.1.3 のような IPv6
マルチキャストに対応させたチャンネル型ア
プリケーションを用いることで、利用者がグ
ル ー プ ア ド レ ス 、ポ ー ト 番 号 の 入 力 を 行 わ ず 、
テレビの操作感覚で利用できるものである。
すべての受信拠点が、我々の研究内容に精通しているわけではなく、操作性、利便性の確保は重要である。

図 2.6.3.1.1.3

表 2.6.3.1.1.1

マルチキャスト受信端末用ソフトウェア

106- 106 -

ソース拠点

２．６．３．１．２

検証結果と考察本研究開発において、まず帯域計算のミスによりルータ帯域が溢れるという
こ と と 、地 域 ネ ッ ト ワ ー ク 側 の ル ー タ が 小 型 ル ー タ の み で 構 成 さ れ て い る た め 、
スタートポロジのコアルータのパフォーマンスが不足し、マルチキャスト配信
全 体 に 影 響 を 与 え る と い う 事 象 が 発 生 し た 。帯 域 溢 れ は 、5 0 本 の ソ ー ス（ 5 0 c h
用ソフトのため、未配信チャンネル表示部分も配信）を終端した地域ネットワー ク 側 ル ー タ か ら J G N Ⅱ 側 へ 流 す 必 要 が あ り 、1 G b p s の 通 常 接 続 構 成 で 溢 れ たも の で あ る 。さ ら に 、こ の ル ー タ は C P U 負 荷 も 相 当 高 く な っ て た め 、全 体 的 に
パフォーマンス不足となった。従って、JGN 側の 10G ルータで終端せざるを得 な い 状 況 に 陥 っ た 。1 0 G ル ー タ で の 終 端 後 、P I M - S M の N e i g h b o r が 切 断 されることは無く、正常な Mroute が確立できた。
また、もう一つの課題として MLD Snooping の必要性を改めて認識すること と な っ た 。こ れ は 、図 2 . 6 . 3 . 1 . 2 . 1 の よ う に P O P セ グ メ ン ト で は 複 数 の 市 町
村 を 収 容 す る WA N の セ グ メ ン ト が 存 在 す る 。 通 常 、 I P v 4 / v 6 デ ュ ア ル ス タ ッ

図 2.6.3.1.2.1

MLD-Snooping の必要性

ク 構 成 で ネ ッ ト ワ ー ク を 構 成 す る と 、当 然 各 P O P で は 共 通 の 収 容 セ グ メ ン ト が出 来 上 が る 。そ の 際 、マ ル チ キ ャ ス ト パ ケ ッ ト が 不 要 な 市 町 村 ル ー タ へ も M L D
S n o o p i n g 機 能 が 無 い と パ ケ ッ ト が 流 れ て し ま う 。こ の セ グ メ ン ト へ 接 続 す る ルータの帯域が裕福であればいいが、図のように 100Mbps だとすれば 4 本で帯域が埋まることになる。検証中実際にこの現象に陥った。A 市町村配下で 4 本の送受信検証中、B 市町村側で 100Mbps 接続の箇所があり、B 市町村側で受信しようとしたところパケットロスが頻発とした。他の拠点で起きていることが影響するため、B 市町村内では原因究明に時間がかることとなった。通常、自組織内の LAN セグメントで必要だと思っていた MLD Snooping であるが、こ の よ う な 状 況 に お い て も 、 必 須 の 機 能 で あ る 。 コ ア ス イ ッ チ で の MLD
Snooping に つ い て は 、 L3 イ ン タ ー フ ェ ー ス で は 動 か な い こ と が わ か っ た

107- 107 -

AlaxalA 系スイッチと現時点でも実装できていない Cisco 系コアスイッチという状況であり、ベンダーへのフィードバックを再度実施することとした。
２．６．３．２

さっぽろ雪祭り中継による IPv6 マルチキャストの放送利用の検証

本検証は、放送素材のインターネットでの伝送を定常化するための課題抽出の場として行っている。放送用途は、通常のイベント利用とは当然異なり、品質（ 信 頼 性 、安 定 性 ）、操 作 性 、機 能 性 と い っ た 業 界 が 現 在 確 保 し て い る も の と同様以上のものをインターネットで実現することが求められる。従って、我々は過去 2 年間ルータの性能評価を中心に行ってきた。昨年の評価において、マルチキャストソースを増やしたことによる小型ルータのソフトウェア処理時のC P U 負 荷 が 問 題 と な り 、マ ル チ キ ャ ス ト 経 路 の 安 定 化 さ せ 、ハ ー ド ウ ェ ア 処 理にさせておくということを生放送本番前に実施した。そのため、本番中はマルチキャスト配信しているにも関わらず、チャンネル変更を PC 上では行わない
ようにというお達しをするに至った。ソースの数は、雪祭り生中継のものと、裏でプロ野球キャンプ素材の伝送を行い、一昨年より過度に増えていた状況となり、ルータの性能問題が顕著に表れた形となった。
これを踏まえ、今年度は小型ルータの性能向上は既にハードウェアスペック
上 限 界 で あ る こ と が わ か っ て い る た め 、キ ャ リ ア グ レ ー ド で あ る J G N Ⅱ v 6 の コ
アルータを用いることとした。また、先に述べた信頼性確保について RP の冗
長 化 の た め の 実 証 の 場 と し て 活 用 し た 。（ 詳 細 は 、 ２ ． ６ ． ３ ． １ 項 を 参 照 ）さらに、今年度の着目点として、IPv6 マルチキャスト利用のネットワーク側
でのセキュリティ確保を検討することとした。これは、今年度 JNN 系の他、
A N N 系 の 放 送 局 に も 参 加 し て い た だ い た た め 、こ の よ う な 議 論 が 必 要 と な っ たためである。
２．６．３．２．１

検証方式とネットワーク構成

検証ネットワークは、JGNⅡv6 と一部地域ネットワークとの連携を行っている箇所がある。ただし、地域ネットワークとは L2 の接続とし、L3 連携は岡山国体の検証で実施たため、今回は行っていない。
図 2 . 6 . 3 . 2 . 1 . 1 に 構 成 を 示 す が 、今 年 度 は 海 外 と の 連 携 も 実 施 し て い る 。I P v 6
マルチキャスト技術は、国外ではあまり浸透していない技術であり、技術のデプ ロ イ と い う 観 点 か ら J G N Ⅱ 海 外 線 を 用 い て 韓 国 、シ ン ガ ポ ー ル へ 配 信 し て いる。
ネットワーク構成を詳細に述べると、コアサイトから L2 接続により各設置箇
所 へ は ネ ッ ト ワ ー ク を 延 ば し た 。従 っ て 、各 設 置 箇 所 を 束 ね る J G N Ⅱ ア ク セ ス
ポイント（例えば、KDDI 沖縄等）には、ルータは設置していない。唯一雪祭

108- 108 -

り 会 場 プ レ ハ ブ 内 に ル ー タ の 検 証 と し て A l a x a l A 製 コ ア ル ー タ を 設 置 し た 。これは、VRRP による RP の冗長化の検証を行う目的のため設置した。

図 2.6.3.2.1.1
２．６．３．２．２

2006 さっぽろ雪祭り、プロ野球キャンプ素材中継構成
IPv6 マルチキャストグループと RP の冗長化

下記の表 2.6.3.2.2.1 に、マルチキャストチャンネルとグループアドレスの一部を表記した。ここで、gr の欄がマルチキャストアドレスの下位部分を示しているが、最終オクテットの一つ前のオクテット値によって RP を選択させている。表 2.6.3.2.2.2 に RP との対応表を示しているが、方式としては、::d が堂
島、::0 が岡山、::9 が九大とそれぞれのルータを選択するようになる。
表 2.6.3.2.2.1
ch

port

Gr

1

8001

::0:1012

8002::9:102

3

8003

4
5

マルチキャストチャンネル、グループ表（一部抜粋）
PC アドレス

場所

利用用途

HBC

HBC お天気カメラ::d:103

大通り

中継車 Out

8004::0:104

大通り

中継予備 Out

8005::9:105

大通り

南プレハブ屋上

172.30.15.10

172.30.27.101

109- 109 -

6

8006::d:106

172.30.27.103

大通り

広場出先

7

8007

::0:107172.30.122.22

CBC

サブアウト

8

8008

::9:108

MBS

サブアウト

9

8009

::d:109

MBS

天カメ

10

8010

::0:110

ABC

天カメ

11

8011

::9:111

RSK

サブアウト

12

8012

::d:112

RCC

サブアウト

13

8013

::0:113172.30.174.21(rbc-koubo)

RBC

サブアウト

14

8014

::9:114172.30.174.31(rbc-kusa)

RBC

天カメ

15

8015

::d:115

NECTECタイ

表 2.6.3.2.2.2
RP ルータ岡山 gr4000
堂島 gr4000
九大 sb78

２．６．３．２．３

RP 対応表グループアドレスfe30:2001:e38:0::xxx
fe30:2001:e38:d::xxx
fe30:2001:e38:9::xxx

検証結果と考察

まずネットワーク側の検証結果と考察を述べる。ネットワーク側で昨年度までの検証で起きた不安定な状態は皆無であった。これは、今回の構成が功を奏したと考えている。高性能なコアルータ配下ですべての端末がぶら下がる状態
を作ったことがこの成果をあげた理由だと考える。コアルータの性能について問題のないレベルに達したというのは、この実証をもっていえたことである。
さらに、RP の分散を確認するため、ルータの（S,G）の状況を確認し、正し
くマルチキャスト経路が出来ていることを確認した。ラボ環境だけではなく、実環境においても RP の分散動作が検証できた。これにより JGNⅡv6 では、JGNⅡ全体で利用するマルチキャストグループについて定義し、今後の研究開発で活用可能なモデルを形成させた。
また、VRRP での RP の冗長化についても実環境で検証を実施した。方式としては、「 同 一 ベ ン ダ ー 、同 一 型 番 の 機 器 」と し た 。V R R P は 、標 準 化 さ れ た もの で あ り 、異 機 種 間 で も 動 作 す る 。し か し 、R P の 冗 長 化 と い う 状 況 で は 、異 機種で行うことはほぼ無いため、検証して課題提起しても意味が無い。従って、
IPv6 PIM-SM について仮想ルータ上で動作するかを検証することとした。
結 果 と し て 、切 り 替 え 時 間 1 0 秒 程 度 。ル ー タ 切 り 替 え と 同 時 に マ ル チ キ ャ ス トも復帰した。RP の分散及び冗長化は、VRRP＋PIM-SM が最も有効だと考えられ、信頼性確保の手段として利用可能である。
今後追加検証必要なものとして、他のベンダー製機器の検証と、同一ベンダ

110- 110 -

ー 、異 型 番（ L 3 ス イ ッ チ と ル ー タ な ど ）で 実 施 す べ き だ と 考 え て い る 。他 の ベ
ンダー機器間は言うまでもないが、異型番の必要性は高価なルータを 2 台所有
するこが困難な場合は十分にあり得るためである。
放送技術の側からも課題が発見された。それは、次のようなものである。
・ 利用する PC の性能により送受信の安定性にバラツキがある・ DV メディアコンバータの不具合による音声問題¾

音声信号（LR）の位相反転が発生

PC の性能差は、我々でも把握しており安定性には確かに差がある。汎用 PC
を 利 用 し た 検 証 で あ る た め 、あ る 程 度 仕 方 な い の か も し れ な い が 、P C の デ ィ ス
プレイ上で描画させるとパケットロスが発生するケースがあった。また、音声の位相反転は、我々が行う検証では見つけることができないレベルのものである。いわゆる放送クオリティの部類であって、昨年と同様の PC 周りの環境であるため、ずっと発生していたのかもしれない。今年度は、ネットワーク側のトラブルが無く安定していたため、他の問題が見つけられる余裕のせいだろうか。とはいえ、この問題は DV メディアコンバータを変更することで解決できたため、放送素材の伝送について非常に良い結果を得られることができた。
セキュリティ対策の検討については、今回実証することができなかった。方
式 に つ い て 模 索 し て み た が 、I P s e c + P I M - S M は プ ロ ト コ ル 上 実 装 が な く 、I P s e c
はユニキャストベースということもあり、有効な手段としては疑問がある。今後どのような方式が望ましいか、多方面と検討していきたい。まずは、アプリ
ケーション側での確保が最も有効であることは間違いない。
２．６．３．３

まとめ

IPv6 マルチキャストの検証を始めてここまでの期間、飛躍的に実装レベルやハードウェアの処理能力が向上した。当初は、ネットワークベンダー間に温度差があり、PIM-SM は日本でしか利用しないのではないか？というような疑心暗鬼の状態もあったが、さまざまな実証実験を行うことや、その結果をベンダーにフィードバックすることにより、今や不可欠な機能として位置づけられている。PIM-SM の BSR 情報の転送ができなかった Juniper 社から、6 ヶ月の開発期間を経て今年度末ベータソフトウェアの提供を受けた。Juniper 社製のルータが途中にあると、マルチキャストツリーが形成できなくなるという状況を避けなければ、次世代ネットワークを構築する機器とはいえないという強い意志を伝えた経緯がある。このベータソフトウェアの検証を実施し、正しく動作することを確認した。今後、正規版でのリリースを待つ状態である。
IPv6 マルチキャストは、PIM-SM と PIM-SSM という 2 つの対極なプロト
コ ル が あ り 、 M L D v 2 を M i c r o s o f t Wi n d o w s が 実 装 す れ ば P I M - S S M 利 用 の111- 111 -

目が出てくる。PIM-SSM では RP が不要となるため、非常にシンプルな網構成ができ、ルータの負荷も軽減できる。ルータの実装はある程度進んでいるた
め、クライアントの実装次第では今後の鍵になる技術だと考えている。
岡山 RC では、ICT 社会を形成する次世代ネットワーク技術を、さまざまな機関と連携し、普及促進を図って行きたい。そのためには、的確に技術動向を把握し、必要な技術に着目して研究開発を行っていかなければならない。

112- 112 -

２．７ GMPLS ネットワーク運用・管理技術の研究開発
2.7.1 概要
2.7.1.1 研究の目的
高精細画像伝送やＧＲＩＤなど、ユーザ要求に応じて高速に大容量回線を提供するサービスを必要とするアプリケーションが今後増加すると予想される。これらは既存のネット
ワークでは実現不可能で、次世代の情報ネットワーク基盤であるＧＭＰＬS＊技術の適応が必要と考えられる。
＊ Generalized Multi-Protocol Label Switching：IP ネットワークにおいて使われている MPLS の考え方を、複数の異なるレイヤに拡張、発展させたプロトコル群。
GMPLS は、次世代フォトニックネットワークを制御するプロトコルとして注目されている。
ＧＭＰＬＳおよびフォトニックネットワーク技術は我が国のＩＴ戦略上重要な要素技術であると位置付けられている。オンデマンドの大容量回線を要求するアプリケーションをサポートするためのサービスインタフェースおよび運用管理技術の確立が必須であるとともに急務であり、JGNII を用いた GMPLS ネットワーク運用管理技術の確立は、我が国の IT政策に大きく寄与するものである。
本研究では、上記のアプリケーション等の要求条件に柔軟に対応できるサービスネット
ワークを実現するため、GMPLS ネットワークの運用・管理に関する研究開発を実施する。
（JGNII 上に構築された GMPLS ネットワークを活用し、GMPLS ネットワークの運用・管理技術の確立を行う。
）本研究は、従来のブロードバンドサービスネットワーク環境の研究に関する研究開発の推進だけでなく、実環境を用いた研究開発・検証を推進することによる運用・管理技術の確立に総合的に資することを目的とする。
2.7.1.2 研究テーマ
ＪＧＮⅡおよびＧＭＰＬＳのネットワーク構成を図 2.7.1.2 に示す。ＧＭＰＬＳネットワークとしては、北回りと南回りの２つのネットワーク（マルチドメイン）で構成されている。本研究テーマではＪＧＮⅡ上に構築されたＧＭＰＬＳネットワークを活用し、GMPLS
ネットワークの運用・管理に関する技術検証等を行い、運用・管理技術を確立する。具体的な研究課題は次の 4 項目であり、2.7.2 章以降にこれらの研究状況を個別に報告する。
（１）マルチレイヤネットワーク運用管理技術の研究開発（２）ＧＭＰＬＳネットワーク高機能・高信頼化に関する研究開発（３）マルチドメイン（Ｅ－ＮＮＩ）統合管理技術に関する研究開発（４）アプリケーションとの連携（ＵＮＩ）に関する研究開発113- 113 -

なお、コアテーマの「GMPLS ネットワーク運用・管理技術の研究開発」に加え、サブテー
マとして以下を設定している。
・「マルチメディア配信のためのネットワーク制御に関する研究」

・「GMPLS ネットワーク における最適ルーティングとフロー制御」

・「Grid ミドルウェアによる GMPLS ネットワーク利用技術の研究開発」

・「グリッドコンピューティングにおけるＪＧＮの有効性実証」

GMPLSネットワーク
Kanazawa

北周りＮＷ

Kanazawa
金沢

Fukuoka
Fukuoka
福岡

OtemachiA
大手町

10 G (1G x×8)8)

Osaka
堂島

Sapporo10G

Kanazawa
金沢
Osaka
堂島
Osaka

Fukuoka
南周りＮＷ 福岡

Okayama
岡山x2
当初 10 G ベース

10G Kitakyushu

10G

Kobe
10G

Okayama
1G

Kochi

1G

1G

10G

Osaka
10G

Nagano
10G

1G

10G

Kashima
10G

Otemachi A

Koganei
10 G x 2

Tsukuba

1G

NagoyaSendai

10G

Kanazawa

10G

Fukuoka

1G

Otemachi B

NICT けいはんな
Keihanna

Otemachi B

KeihannaNaha

図 2.7.1.2 JGNII ネットワークと GMPLS ネットワーク

2.7.2 マルチレイヤネットワーク統合管理技術に関する研究開発
GMPLS ネットワークの運用管理手法について、ここでは 2 つの研究開発課題について報告する。一つは GMPLS ネットワークと IPv6/MPLS というマルチレイヤ運用管理手法に関する研究開発であり、もう一つは GMPLS ネットワークとユーザ・アプリケーションの連携手法に関する研究開発である。
マルチレイヤ運用管理手法に関する研究開発では、本年度は GMPLS ネットワークと上位レイヤとなる IPv6/MPLS ネットワークとの連携を図る上で基礎となる技術について研究開発を行った。具体的には、IPv6/MPLS ネットワーク収容機能の研究開発である。
IPv6/MPLS ネットワーク収容機能研究については、昨年度に引き続きコアネットワーク
として JGNII の GMPLS ネットワーク、エッジに IPv6/MPLS ネットワークが接続される

114- 114 -

ことを想定した場合の収容手法を検討し、エッジ IPv6 ネットワークとして IPv6 ルータおよび IPv6 測定器を接続して、IPv4 ベースの GMPLS ネットワークを越えた IPv6 ネットワーク同士でのデータ伝送について実験を行った。実験内容は主に『GMPLS 光パスを通した
IPv6 経路広告の設定実験』および『GMPLS 光パスによる IPv6 データ転送実験』の 2 つから成り立っており(実験系は図 2.7.2.1 参照)、これらの実験の成功により、JGNII のGMPLS ネットワークによる IPv6 データストリームの安定した収容性を確認できた。これらの成果について、フォトニックネットワーク研究会(PN)にて発表を行った。

IPv6
Router

GMPLScontrolled
Routerwith 6PE
GbE

FEx4

GbE

OXC

OXC

GbE

OXC

GbE

GMPLScontrolled
Routerwith 6PE
GbE

IPv6
RouterGbE

Core GMPLS network

IPv6
Test set

Edge IPv6 network

FEx4

IPv6
Test set

図 2.7.2.1 IPv6 transport over GMPLS 実験系
また、GMPLS ネットワークによる MPLS ネットワーク接続については、JGNII のコア
ルータを用いて、外部の実運用 MPLS ネットワークである distix と大手町(関東-2)～金沢(北陸-1)間で相互接続を実施し（接続構成は図 2.7.2.2 参照）、GMPLS パスを介した MPLS
パスの設定と長期間の接続運用に成功した。
大手町-2

金沢
MPLS
Distix ルータ

GMPLS
ルータ

OXC

OXC

MPLS
network

MPLSパス

GMPLS
ルータ

MPLS
ルータ Distix
MPLS
network

Core GMPLS network

GMPLSパス

図 2.7.2.2 GMPLS ネットワークと MPLS ネットワーク接続
GMPLS ネットワークとユーザ・アプリケーションの連携手法に関する研究開発においては、昨年度実施したユーザオリエントな光パスプロビジョニング技術に関する基礎検討結果（ユーザ・アプリケーション側がネットワーク側に求めるパラメータの抽出・絞り込み、およびユーザ側とネットワーク側の接続手法・通信手順などの検討結果）を踏まえ、GMPLS
エミュレータ上で動作する Web ベースの GUI（Graphical User Interface）機能を開発し115- 115 -

て GMPLS エミュレータに実装し、JGNII の GMPLS ネットワーク上で実験を行った。本
システムは『ユーザ主導型波長パス設定システム』と名づけた。実験系は図 2.7.2.3 の通りであり、データプレーンにはユーザ装置を直接接続することを想定し、IP 測定器を接続した。本 GUI 機能には、各パラメータにエイリアス(任意の文字列)を割り当てて設定を簡単化すると共に、誤って別のユーザのポートを設定しないよう、ユーザ毎のアクセス制限
機能も具備させた。これらの結果、Ingress の GMPLS エミュレータに対して Web ブラウ
ザ上で表 2.7.2.4 の情報を入力し、”セットアップ”のボタンを押すだけで、大手町・金沢・福岡の各拠点間で GbE の帯域を持つ GMPLS 波長パスがいずれも約 5 秒で設定できることを確認した。これらの成果については JGNII シンポジウムでデモを実施すると共に、電子情報通信学会 2005 総合大会で発表を行った。なお、本 GUI 機能は、安定性について検証したのち、JGNII の『OXC 接続サービス』を利用するユーザに対してサービスの補助機能として提供する予定である。今後の課題としては、ユーザ～GUI システム間のアクセスネ
ットワークのセキュリティ向上手法を検討すること、および本システムにアプリケーショ
ンが直接アクセスできる API を開発し、ユーザ(人)の手を介することなく、マシン to マシ
ンで GMPLS パスの設定ができるようにすることが挙げられる。
波長パス
利用ユーザ

WebによるGUI

ユーザアクセス用ネットワーク(JGN2 L2サービス)

福岡
ユーザアクセス
ネットワークコントロール
プレーン

データ
プレーン

Web

金沢

Web

GUI

Web

大手町（東京）GUI

GMPLS
エミュレータOSPF-TE GMPLS
RSVP-TE エミュレータ
OXC

ユーザ機器

ユーザ機器

GbE

GbE

GUI

OSPF-TE
RSVP-TE
OXC
OXC

GMPLS
エミュレータ

ユーザ機器

GbE
GbE

GbE

図 2.7.2.3 ユーザオリエントな GMPLS パス設定実験
表 2.7.2.4 GMPLS エミュレータ GUI に入力が必要なパラメータ
パラメータ

値

Destination (Egress)ノード ID

IPv4 アドレス/エイリアス

Source (Ingress)ポート ID

正整数/エイリアス

Destination (Egress) ポート ID

正整数/エイリアス

帯域

GbE

116
- 116 -

また JGNII はテストベッドネットワークで日本初の GMPLS 技術の導入であり、昨年度に引き続き日々のネットワーク運用に関わることにより、上記テーマにおける課題の抽出や解決手法の検討にあたると共に、GMPLS ネットワークの実運用に関する問題点についても抽出を行った。
2.7.3 ＧＭＰＬＳネットワーク高機能・高信頼化に関する研究開発
ＧＭＰＬＳネットワークの高機能・高信頼化に関する研究開発を進めた。
サブテーマ３

NMS

カスタマコントルート端末

NE-OpS
UNI

AP

サブテーマ２

地域
ネット
ワーク
ユーザ端末

サブテーマ1

NE-MgrRouter
Type-X

OXC

NE-Mgr

λ

λ
OXC

E-NNI

NE-Mgr

OXC

Router
Type-X他GMPLS
ネットワーク

図 2.7.3.1 GMPLS ネットワークの研究課題
具体的には研究項目を、ＧＭＰＬＳルータ、ＯＸＣ（光クロスコネクト）、ＮＭＳ（ネットワークマネージメントシステム）に関する以下のテーマ設定に基づいて進めた（図 2.7.3.1 参照）。
（1）GPMLS フォトニックネットワークにおけるサービスインタフェースに関する研究(1.1)NW スケーラビリティに関する評価（2）GMPLS 技術を用いたフォトニックノードにおける光パスの高速制御性に関する研究(2.1) 高速可変波長レーザによる波長パス制御実験(2.2) 光プロテクション実験（3）GMPLS 網管理システムにおけるカスタマ制御を用いた網運用方式の検討(3.1) GMPLS におけるポリシー制御試験
以下に研究の概要を示す。
（1.1）ＮＷスケーラビリティに関する評価

117- 117 -ＪＧＮⅡ上の GMPLS ネットワークと測定器による擬似ネットワークを用いて、ＡＳ内およびＡＳ間の代表的ルーティングプロトコルである、OSPF および BGP についてスケーラビ
リティの検証を行った（図 2.7.3.2）。経路フラッピング、各種障害モード、リブートの影
響などについて評価し、OSPF で２万経路、BGP で１００万経路の経路注入に対し問題が無いことを確認した。各プロトコルの提供領域から判断し処理能力が十分実用レベルである
ことを示した。
NE-Mgr

NE-Mgr

NE-Mgr

2万経路

fe0/0
/2

OSPF評価実験構成

X320J 京阪奈
ge1/1
/0

AX
#1

OXC
京阪奈

OXC
堂島

OXC
大手町

fe0/0
/0

X320J 大手町

so1/0
/0

so1/1
/0

ge2/1
/0

AX
#2

SCパス作成OSPF area 0.0.0.0

AS
65001

AS 65000
NE-Mgr

fe0/0
/2

BGP評価
実験構成

X320J 京阪奈
AX
#1

ge1/1
/0

OXC
京阪奈

NE-Mgr

OXC
堂島

AS 65002
NE-Mgr

OXC
大手町

so1/0
/0

fe0/0
/0

100万経路

X320J 大手町
so1/1
/0

ge2/1
/0

AX
#2

SCパス作成図 2.7.3.2 ＮＷスケーラビリティの検証系構成（2.1）高速可変波長レーザによる波長パス制御実験
高速波長可変レーザを用いた下記についての実験（図 2.7.3.3）と性能評価等を行った。
実験項目１：波長可変域が広く、波長設定時間が高速な波長可変ﾚの実フィールドにおける動作の安定性検証を行った。
①パス設定／削除制御時の安定性の検証②長期安定性の検証
実験項目２：高速波長可変レーザの適用による、パス設定／削除時間高速化に関する性能検証
現在搭載している波長可変レーザは温度制御型で波長が安定するまで時間を要している。
このため電流制御型の高速波長可変レーザを用いて、波長および制御系の高速性、安定性を検証した。下図に、制御時間（SPC:OXC 単独および SC:GMPLS ルータを含む）の削減率を118- 118 -

示す。改善後の制御時間は 10 数秒であり、今後シグナリング、ガードタイムなどについて
一層の高速化を検討する。

【けいはんな】
OXC

【堂 島】

【大手町】

OXC

OXC

OTN

SDHアナライザ【凡例】：高速可変波長ﾚｰｻﾞ搭載光インタフェース：Data Communication Channel (In-band)95

削減率（％）

90
85
80
75①大⇒堂（SPC)②大⇒け(SPC)③大⇒堂(SC)④大⇒け(SC)

70
65
60
1

2

3

4

5

6

7

8

9

10

パス設定回数

図 2.7.3.3 高速可変波長レーザによる実験系と制御時間（2.2）光プロテクション実験
障害時のプロテクションもいろいろな方法がありえるが、南周り NW では冗長構成でパス端で切り替える方式を検討している。東京―大阪間でプロテクションの機能確認と、切替え時間の測定等を行った。図 2.7.3.4 に切替え時間の測定結果を示す。10ms 程度の保護時間を入れて１８ms 程度であり、規定値（５０ms）を十分クリアしている。
機能面、品質面ともに高信頼なバックボーンの提供に適用可能である事を確認した。

119- 119 -

0系

０系：下りパス⇒
TDR

SDH
アナライザ

０系：上りパス←

TDR

OSW

SEL

TDR

TDR

OSW

１系：下りパス⇒１系：上りパス←

TDR

OXC

TDR

SEL

SDH
アナライザ

TDR

OXC

1系

近畿基幹通信網構成拠点(近畿-1)

TDR

１＋１プロテクション
プロテクション

関東基幹通信網構成拠点Ａ(関東-1)

20
18
16
切替時間（ms)

1412

下りパス（＠関東‐1）0系⇒1系

1086

下りパス（＠関東‐1）1系⇒0系

4
20
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

度数

図 2.7.3.4 光プロテクション系の構成と切替え時間（3.1）ポリシー制御試験
GMPLS ネットワークでは、GMPLS ルータからの要求に応じて自由にパスが設定できる。
GMPLS ルータは現状ではネットワーク内の装置であり、ＪＧＮⅡにおいてもネットワーク
設備として設置されている。しかし将来的にはユーザ設置になり GMPLS ルータと OXC 間が UNI（ユーザネットワークインタフェース）になることも想定されている。その場合はNW 側でパス設定にある程度の規制をかける必要性が考えられる。そのため OXC ノードにポート単位のポリシー制御機能を実装し、オペレーションにより GMPLS パス単位で設定の許可／拒絶可能な機能を実装することで、システムの運用性を高めた。拒否ポリシーを適用した場合、適用パスについてルータからの要求を拒否すること、また逆に許可ポリシーを適用した場合はパス要求を許可する、等の機能をＪＧＮ上で確認した（図 2.7.3.5）。

120- 120 -

NMS

Port1に対してポリシー適用（Path Msg 1の拒否）

ポリシー適用Port1のパス生成：拒否Port2のパス生成：許可

NE-OpS

Port1経由
大手町～堂島間
GMPLSパス

Path Msg 1(Port1)

Port2経由
大手町～けいはんな間
GMPLSパス

Path Msg 2(Port2)

Path Msg 2

Path Msg 2

Rsv Msg 2(Port2)

Rsv Msg 2

Rsv Msg 2

Policy Err (Port1)

NE-Mｇｒ

Port2に対してポリシー解除（Path Msg 2の許可）

NE-Mｇｒ 1

大手町
X320J

Rsv Msg 2
NE-Mｇｒ

NE-Mｇｒ 2

１０Ｇ回線１

Ｐｏｒｔ１⇒ＮＧ

Path Msg 2

NE-Mｇｒ 3

堂島
OXC

１０Ｇ回線２

Ｐｏｒｔ２⇒ＯＫ

大手町
OXC

堂島
X320J

けいはんな
OXC

けいはんな
X320J

・NMSからのポリシー適用状態でRouterからのSCパス生成を拒否すること
・NMSからのSCパスの強制削除により、Routerからのパス生成を拒否すること（ポリシーを適用した状態で削除）
・NMSからのポリシー解除状態でRouterからのSCパスが生成できること

図 2.7.3.5 ポリシー制御試験の検証系構成
2.7.4 マルチドメイン(E-NNI)統合管理技術に関する研究開発
2.7.4.1 研究概要
JGNⅡにおいて個別に管理運用されている北回りと南回りの GMPLS ドメイン間の相互接続を実現するための研究開発を行う。
(1)複数 GMPLS ドメインにおける GMPLS コントロールプレーンネットワークの相互接続性研究- ネットワークアーキテクチャの検討- アドレス体系検討(2)複数 GMPLS ドメインでの GMPLS E-NNI 相互接続性研究- 経路情報交換方法の検討(BGP/OSPF 他)および検証- RSVP シグナリングにおける LSP 設定
2.7.4.2

実施内容

関東-1、関東-2 の間の STM-64 の実験用波長を用いて、データプレーンで OXC 間を接続。
コントロールプレーンについては、L2 サービスを利用して接続した（図 2.7.4.1 参照）。

121
- 121 -

C-Plane

北陸-1
Router

北陸-1
OXC

C-Plane

P2P接続

関東-2
OXC

E-NNI

関東-1
OXC

近畿-1
OXC

ドメイン内故障
復旧区間

近畿-1
OXC-2

近畿-1
Router

STM-64

図 2.7.4.1 Ｅ－ＮＮＩ実験構成図[結果]:(1) ルータ<->ルータ間接続
GMPLS-UNI を含むマルチドメインによる接続に成功した。但し一部パラメータ問題があり、片方向からのパス生成のみ確認した。
(2)

OXC<->OXC 間接続

他ドメインの経路情報を隠蔽する loose hop 指定によるマルチドメイン接続に成功。
(3) ドメイン内故障復旧技術の確認
階層化シグナリングを適用し、他ドメインへ影響を与えないドメイン内故障切替に成功した。
具体的には図 2.6.4.2 で示すように、ドメイン内を階層化パスにて構築する。ドメイン内で故障が発生した場合に、ドメイン内パスに閉じた故障通知、予備系への切替を行う事
で、他ドメインには当該故障、切替の情報を隠蔽可能である。

ドメイン内パス論理モデル

ドメイン間パス

故障通知

故障切替制御ドメイン間パス 状態保持
状態保持メッセージ

ドメイン内パスの切替制御によるドメイン内故障の他ドメインへの波及抑止

図 2.7.4.2 ドメイン内故障復旧

122- 122 -

障害検出

2.7.4.3

今後の予定

2006～2007 年度に掛けて E-NNI の BGP によるルーティング機能の確認を実施予定。2006
年度中に機能の作り込みを実施し、2006 年度下期又は 2007 年度に実験及びイベント等で成果発表する事を目指す。
2.7.5 アプリケーションとの連携
2.7.5.1 GRID との連携
GMPLS ネットワークとアプリケーションの連携のテーマについては、共同研究機関と共同で、JGNII の GMPLS ネットワークを活用した『GMPLS ネットワークとグリッドの連携』に関する実験を行うと共に、プレスリリースおよび国際会議 iGRID2005・SC’05・JGNII シンポ
ジウム in 仙台にてデモンストレーションを実施した。本実験/デモでは、GMPLS ネットワー
クリソースとして JGNII の GMPLS ネットワーク上の 5 拠点（福岡・金沢・大手町(東京)2 箇所・堂島(大阪)の各 GMPLS アクセスポイント）を利用した（図 2.7.5.1.1 の通り）。内容は、グリッド側のリソースマネージャ（GRM）とネットワーク側のリソースマネージャ（NRM）
が連携し、コンピュータリソースおよびネットワークリソースを時間予約する。予約された時間になると、NRM と GMPLS ネットワークが連携して GMPLS パスを設定し、コンピュータ
が GMPLS パスを利用して大規模計算を実施して、その結果をデモ会場に表示するというものである。つくば JGNII リサーチセンターでは、本実験に対して、JGNII の GMPLS ネットワ
ーク全体を活用できるよう、各拠点間の接続性に関する実験を進めると共に、GMPLS ネット
ワークの設定に関し、GMPLS パスが確実かつ効率良く設定できるよう、NRM と連携をはかった。その結果、本デモでは、GMPLS の特徴を活かして迅速な大容量光波長パスの設定が行われると共に、パスの状態をグラフィカルに表示できたため質問も多数寄せられ、大好評であった。

福岡クラスタふじみ野クラスタ

金沢クラスタ

つくば
クラスタ

大阪
クラスタ

JGNⅡ GMPLS
ネットワーク秋葉原
クラスタ

図 2.7.5.1.1 GMPLS ネットワークとグリッドの連携実験に用いたネットワーク構成

123- 123 -

0 .5
Gb
ps

1

5

利用者

GUI

10
1Gbps

グリッド資源スケジューラ
計算資源マネージャ

GRSとNRMの連携

ネットワーク資源管理システム
GMPLSネットワー
クとNRMの連携





GMPLSネットワーク


クラスタ計算機



クラスタ計算機

図 2.7.5.1.2 GMPLS ネットワークとグリッドの連携実験概要
2.7.5.2 ディジタルシネマ伝送実験
具体的な広帯域アプリケーションとしてディジタルシネマ非圧縮伝送（6Gbit/s）を行った（2006 年 1 月の JGNII シンポジウム in 仙台）。図 2.7.5.2.1 にデモ概要及び図 2.7.5.2.2に詳細な構成図を示す。
･慶應大学－大手町－大阪－（-大手町）－仙台－会場･NTT 武蔵野研究所－大手町－大阪－（-大手町）－仙台－会場の二つの系（コンテンツ）を用意しリアルタイムで切り替えた。
具体的には東大の青山教授の講演中に、以下を行った。
1.

慶応大学からの映像コンテンツ（ライブ映像含む）を大手町から大阪経由で仙台の会場に送ったあと、

2.

大手町からの操作で GMPLS ネットワークを制御して、コンテンツ切替えを行い

3.

NTT 武蔵野研究所からの映像コンテンツを会場に送った。

124- 124 -

NTT武蔵野研究開発センター（三鷹）慶應大学DMC機構（三田）
4Kカメラ

4Kシネマ
配信サーバ

4K-GW装置

仙台国際センター（仙台）4K-GW装置

4K-GW装置

4Kプロジェクタ

GMPLS制御による波長パス切替で4K映像をスイッチ

OXC 東京１

大阪

OXC

OXC

東京２

実験用ﾈｯﾄﾜｰｸ

JGNⅡ

映像データの流れ

図 2.7.5.2.1 ディジタルシネマ伝送／切替え（会場模様）
映像品質、切替えとも特段問題なく、多数の聴衆の前での実ネットワークを介したリ
アルタイムで伝送／切替えはこれまでに例を見ないものである。
切替に 3 分ほどかかったのは少し長い印象を与えたと思われるが、前述（2.７.3 章）の可変波長レーザの高速化やシグナリングの高速化、保護時間の見直しなどで今後かなりの高速化が可能である。今後高速化に向け、ここの課題の解決を図りたい。
出力:untagged
入力:tagged
他拠点への映像ストリームの流れ込みを防ぐため異なる
VLANにて設定

NTT堂島

GMPLSパス
で切替

OXC

大阪

RSVP-TE
messages
出力:untagged
入力:tagged

C-Plane三田

仙台

NE-OpS

１０G-LR

GMPLS制御

１０G-LW

慶應DMCへ

映像伝送系

１０G-LW

１０G-LR
大
ホ｜ル

ファイバ(実験波長)
NTT武蔵野へ
ファイバ(L2/L3サー
ビス用)

武蔵野
L2 Switch(GS4K)

OXC

NTT大手町
新設ポート

機器制御系

大手町

OXC

GS4K

KDDI大手町

GS4K

KDDI仙台100Base-T(untag)

L2 Switch
仙台国際センター

OXC用パッチパネル

新設VLAN(映像伝送用) VLAN: 3254

新設VLAN(映像伝送(慶應DMC用)) VLAN: 3252

既設VLAN(L2/L3サービス用)
新設VLAN(映像伝送(武蔵野用)) VLAN: 3253
新設VLAN(遠隔制御、拠点関連絡用) : 会場のL3サービスの一つのセグメントをVLANで延ばす。 VLAN: 3263

図 2.7.5.2.2 ディジタルシネマ伝送／切替え構成

125- 125 -

2.7.6 報道発表、イベント等
平成 17 年度における報道発表は下記一件。
“グリッドと超広帯域光ネットワークの連携実験に世界で初めて成功－GMPLS ネットワークを用いて通信経路と計算機を自在に組み合わせた情報処理基盤を構築“（２００５．９．２１）
また、イベント等におけるデモンストレーションは以下の通りである。
（１） グリッドとの連携実験･ｉGｒｉｄ２００５（２００５．９）･ＳＣ２００５（２００５．１１）･ＪＧＮⅡシンポジウム in 仙台（２００６．１）
内容については２．７．５．１章参照。
（２） ディジタルシネマ非圧縮伝送実験･ＪＧＮⅡシンポジウム in 仙台（２００６．１）
内容については、２．７．５．２章参照。
（３）ユーザ主導型波長パスサービスの開発
JGNII シンポジウム in 仙台 2006 では、JGNII の GMPLS ネットワークを活用した『ユーザ主導型波長パス設定システム』のデモンストレーションを行った。これは、今年度開発した GMPLS エミュレータのユーザアクセス用 GUI 機能(2.7.2 章参照)および JGNII のOXC 接続サービスを活用したものである。ユーザは会場である仙台から大手町・金沢・福岡の 3 拠点に設置した GUI に対して Web ブラウザでアクセスすることにより、各拠点から会場に至る GMPLS パスを簡単かつ迅速に設定するデモであり、パラメータの絞込みおよびそのエイリアス化によって入力項目を大幅に削減できたため、GMPLS 技術を意識することなく、通常の Web ブラウジング並み、もしくはそれ以上に簡単化なクリック操作で
GMPLS パスを設定できることを示した。

126- 126 -JGNII OXC接続サービス(GbE)
GbE接続
デモ動画配信・受信用PC
PXC (Access Point)
WebによるGUI

GMPLSエミュレータ
ユーザのGMPLSパス設定要求

仙台(JGNIIシンポ
ジウム会場)

福岡
動画表示
金沢
大手町-2
(東京)

2.7.7 対外発表
＜海外発表＞
１ ．「 Early Field Trial Demonstration of GMPLS based Next Generation IP+Optical
Network」、大谷朋広、岡本修一、TERENA Networking Conference（POZNAN、Poland）、２０
０５年６月６～９日
２．「The degree of a Braess-like paradox in a symmetric network can increase withoutbound」、亀田壽夫、Workshop on Game Theory and Computer Science, State University of
New York, Stony Brook, New York, ２００５年７月２２日
３ ．「 Nation-wide field trial of GMPLS optical networking 」、 大 谷 朋 広 、 European
Conference on Optical communication (ECOC) 2005、invited Paper Tu3.4.1、２００５
年９月２５～２９日
４．「IPv6 transport experiment using the GMPLS-controlled network of JGNⅡ」、岡本修一、大谷朋広、APOC2005（中国・上海）、２００５年１１月６日

127- 127 -

５．「GMPLS/OXC Network Testbed of JGN II」、大谷朋広、鮫島康則、岡本修一、岡野介英、TridentCom2006、２００６年３月１～３日
６．「Managing and controlling GMPLS network resources for GRID application」、林道

秋、宮本崇弘、大谷朋広、田中英明、竹房あつ子、中田秀基、工藤知宏、長津尚英、鮫島康則、岡本修一、OFC2006 (Optical Fiber Communication Conference)、米国カリフォル
ニア州アナハイム、２００６年３月５～１０日＜国内発表＞
１．「公平性を考慮した分散コンピュータシステムの最適負荷分散」、井家 敦、亀田壽夫、
TOUATI Corinne, 情報処理学会第１３回システム評価研究会（EVA 研究会）、２００５年６月２４日
２．「JGNⅡの GMPLS ﾈｯﾄﾜｰｸ上における IPv6 ｽﾄﾘｰﾑ転送実験」、岡本修一、大谷朋広、ﾌｫﾄﾆｯｸ
ﾈｯﾄﾜｰｸ研究会（PN 研究会）（とかちﾌﾟﾗｻﾞ、北海道帯広市）、２００５年８月１９日
３．「JGNII 上で展開する GMPLS ネットワークについて」、大谷朋広、岡本修一、次世代 IX
研究会、三菱総合研究所（東京・大手町）、２００５年１１月１５日
４．
「OOO 型光クロスコネクトにおける光プロテクション」、小池良典、鮫島康則、藤原和弘、
大原拓也、戸出武男、織田一弘、電子情報通信学会全国大会、国士舘大学世田谷キャンパ
ス、２００６年３月２４～２７日
５．
「JGNII の GMPLS ネットワークを用いたユーザ主導型波長パスサービス」、岡本修一、大谷朋広、電子情報通信学会全国大会、国士舘大学世田谷キャンパス、２００６年３月２４
～２７日

128
- 128 -

第３章
アクセス系ネットワーク技術に関する研究開発

第３章

3.1

アクセス系ネットワーク技術に関する研究開発

概要

アクセス系ネットワーク技術に関しては、有限なネットワーク資源を効率良く共有するための効果的な制御の役割分担・連携を目指して、アクセス集約技術、アクセス展開技術、端末間通信制御技術の３つの構成要素とその間の連携についての研究開発
を、北九州 JGNⅡリサーチセンターを中心に実施している。より具体的には、地域で集約されたアクセス網間のトラヒック交換のために超高速コア網を最適に利用するような適応的経路・トラヒック制御技術（アクセス集約）、多種多様な無線網・移動網の資源をその制約下で通信品質を考慮して適応的に割当てる制御技術（アクセス展開）、
多様な網を経由する多様な要求品質のエンドツーエンド通信を効率よく公平に実現す
る適応的通信制御技術（端末間通信制御）の研究開発を進めることで、超高速コア網を効率的に利用し、アクセス網資源を効率的に利用・割当て、ユーザ（アプリケーション）に、いつでもどこでも適切なエンドツーエンド通信を提供することを目指している。そのため、相互に関連した以下の３つのサブテーマを設定した。
（Ａ）ネットワーク計測に基づく適応経路制御（Ｂ）品質を考慮したシームレスな資源利用・割当て制御（Ｃ）多様性・可変性に適応するエンドツーエンド通信制御

超高速コア網超高速コア網アクセス集約網（高機能エッジ）
アクセス展開網（無線、移動網）

ユーザ（端末・アプリ）

図 3.1.1

アクセス系ネットワーク技術

平成１７年度は、各サブテーマとも初年度の研究を発展させ、段階目標を達成した。
具体的には、論文誌３件、査読付国際会議８件、を含む２２件の対外研究発表と特許申請２件、プロトタイプ試作やイリノイ大学との国際共同実験などの成果を上げた。

129- 129 -

またそれらを JGNⅡシンポジウムでのデモンストレーションで紹介した。
サブテーマ A では、フロー計測技術に関して、10G ビットクラスのトラヒックを対象に、複数のフローを同時に計測するシステムの設計と、ボトルネックとなる処理をハードウェアによって開発した。
また、トラヒック特性に基づくフローのパス選択に関して、ルータにおいて性質の異なるフローを複数のパスへ振り分ける際、パスのバッファ内キュー遅延を、従来の帯域に基づく振り分けより小さくする振り分け方式の開発、および、少量のデータを頻繁に転送する Grid(分散計算)アプリケーションが複数同時に実行されるような環境において、アプリケーションの実行性能に着目したネットワーク資源の割り当ての有効性の確認を行った。
サブテーマ B では、単一無線網での資源利用制御に関して、マルチホップ無線 LANに対応する AP（Access Point）選択方式に取り組み、シミュレーションにより有効性を明らかにした。また、無線 LAN に接続する端末（STA,Station）が下り方向中心のト
ラヒックを発生する従来のクライアント・サーバ型通信だけでなく、上り方向にも多くのトラヒックが発生する場合に対応するため、無線 LAN の MAC 機構に着目した利用効率向上のための機構を提案し、有効性をシミュレーションにより明らかにした。
また、複数異種アクセス網での資源利用制御に関しては、各通信ホストが持つ通信メディアの情報を管理し、状況に応じて動的に通信メディアを使い分けるための機構と し て 、 新 た な ネ ッ ト ワ ー ク ア ー キ テ ク チ ャ Media Optimization Network
Architecture（MONA）を考案し、その性能をシミュレーションや実機を用いた実験により明らかにした。
サブテーマ C では、高遅延帯域幅環境でのデータ転送技術に関しては、イリノイ大学とも協力して、既存の TCP に替わる、 新しいトランスポートプロトコルとして提案されている HSTCP(HighSpeedTCP)、 Scalable TCP、 FAST、 BIC、 HTCP、
UDT の各プロトコルを対象として、 JGN(Japan Gigabit Network)II の国内回線、 国
際回線を利用した実験を行い、インターネットのような 不特定多数のユーザが利用するネットワークでの利用を想定した性能評価・特性分析を行った。
ルータ支援によるパケット制御技術に関しては、実時間アプリケーションフローの遅延特性を改善することを目的として、アプリケーションフローにとって大きすぎる遅延を経験したパケットを中間ノードで適応的に廃棄する手法(MTQ 方式、QTL 方式)を提案し、その効果をシミュレーションによって明らかにした。

130- 130 -

3.2 ネットワーク計測に基づく適応経路制御技術の研究開発
将来のインターネットでは様々な分散アプリケーションがこれまで以上に利用されるようになり、多様なトラヒックが交換される中で、高い通信品質を要求するアプリ
ケーションなどが定常的に利用されると考えられる。さらに、バックボーンネットワ
ークではイベントに伴うトラヒックの急増が従来よりも頻繁に発生すると予想され、アプリケーショントラヒックへの動的かつ効率的なネットワーク資源の割り当てが大きな課題となる。トラヒックが急増した場合にも通信の品質を維持できるためには、
トラヒック特性に基づくトラヒック制御が不可欠と考えられる。
将来のバックボーンネットワークは、多量なトラヒックを交換できるよう、トラヒ
ックを集約するコア網と、比較的トラヒック量が少ないエッジルータで構成されると考えられる。エッジルータは他のエッジルータと複数の通信パス（以下では単に「パス」という）を持つことで、トラヒック分散などトラヒック制御をエッジが主体となって行うことが可能になり、バックボーンネットワークが通信品質の維持などの高度な機能を持つことができる。通信品質の維持を効果的に行うためには、•

トラヒックの特性の検出•

トラヒック特性に基づくトラヒックフローのパス選択•

コア網内でのパスの適切な配置が課題である。
具体的には、先ず、トラヒックフロー（以下では単に「フロー」という）単位に、
トラヒックパターンやバースト性を実時間で把握できる計測技術が求められる。次に、通信品質を維持するためには、エッジが多様な特性のフローを限られた数のパスへ配分する際、フローの多重特性を考慮して遅延変動が小さくなるフローの振り分け機能が必要となる。さらに、コア網のネットワーク資源を効率よく利用するためには、計測とトラヒック制御を行うエッジルータが相互に連携する必要である。
以上から、本研究では、以下の 3 つの研究課題に重点を置いてバックボーンネット
ワークの高効率な利用技術の開発を行っている。
•

フローのトラヒック特性の計測･実時間推定手法の開発•

トラヒック特性に基づくフローのパス選択手法の開発•

エッジルータ/コア網連携手法の開発
トラヒック特性の計測･実時間推定手法の開発では、10G ビットの回線を流れるトラ

ヒックについてフロー単位のトラヒック特性 (バースト性や速度) をリアルタイムに推定する手法の開発を目指している。平成 17 年度は 10G ビットクラスのトラヒックを対象に、複数のフローを同時に計測するシステムの設計と、ボトルネックとなる処理をハードウェアによって開発した。
トラヒック特性に基づくフローのパス選択手法の開発では、エッジルータにおいて131- 131 -

多様な性質のフローをトラヒック特性に応じて複数のパスへ配分する際の最適化方式の開発を目指している。平成 17 年度は、ルータにおいて性質の異なるフローを複数のパスへ振り分ける際、パスのバッファ内キュー遅延（以下では「キュー遅延」という）を、従来の帯域に基づく振り分けより小さくする振り分け方式の開発、および、少量のデータを頻繁に転送する Grid(分散計算)アプリケーションが複数同時に実行されるような環境において、アプリケーションの実行性能に着目したネットワーク資源の割り当ての有効性の確認を行った。
エッジルータ/コア網連携手法の開発では、エッジルータによるトラヒック特性計測
およびコア網でのトラヒック量計測の情報をもとに、コア網を通過するフローの通信
品質の劣化の検出、および、他のフローへ悪影響を与えるフローの分離を、複数のエッジルータの間で協調して行う連携方式の開発を目指している。この研究課題は平成
18 年度から着手する予定である。
本報告では、トラヒックの特性を考慮したフローの振り分けが、パスの利用率に基づくフローの振り分けよりもキュー遅延を減少させられることを3.2.1節で、パスの帯域が異なる場合に最適なフローの振り分けを求める方式を示し、パスの利用率に基づ
くフローの振り分けに比べキュー遅延を最大で 40%も改善可能なことを3.2.2節で、トラヒックフローの振り分け方式には不可欠なフロー単位のトラヒック特性の計測を、
10G クラスのトラヒックを対象に行う、トラヒック特性計測システムの開発を3.2.3節で説明する。なお、アプリケーションの実行性能に着目したネットワーク資源の割り当ての有効性の確認は、紙面の都合で割愛する。
3.2.1 トラヒック特性に基づく複数パスへのフロー振り分けの効果
通信品質を維持するためは、エッジルータが入力するフローを複数パスへ振り分け
る際、キュー遅延およびその変動を小さくできることが望ましい。本節では、先ず、
トラヒック特性に基づくフローの振り分けが、従来の、パスの利用率に基づくフローの振り分けよりキュー遅延を小さくできることを確認する。
エッジルータは入力するトラヒックに対して同一の転送先（ネクストホップ）に複数のパスを持ち、パス数よりも多い異なる性質のトラヒックをパスへ振り分ける。パスは予め帯域が設定されているものとする。従来の、パスの利用率に基づくフローの振り分けでは、トラヒック特性に着目しないため、パスの利用率が高い場合にバース
ト性の高いフローを含むパスはキュー遅延の変動が大きくなることが明らかになっている [1-3]。そこで、本項では、最も単純なケースとして、2 種類の性質が異なるフロー群を 2 つのパスへ振り分けることを考え（図 3.2. 1）、もしフローのトラヒック
特性を検知してそれに基づいてフローを適切に振り分けられるならば、従来の利用率に基づく振り分けよりもキュー遅延を減少できることを示す。

132- 132 -

Path1

Edge Router

Path2

Path2

図 3.2. 1

2 つの通信パスへの 2 種類のフローを振り分ける例

以下では、3.2.1.1 節にフローを 2 つのパスへ振り分けたときのキュー遅延の指標（遅延メトリック）を定義し、3.2.1.2 節にパスの帯域の組み合わせとキュー遅延を低くするフローの振り分け方法を分析する。
3.2.1.1 遅延メトリックの定義
フローをパスへ振り分けるとき、パスの帯域が異なる場合や、振り分けられるフローの数が異なる場合には、各パスのキュー遅延は異なる。そこで、あるフローの振り分けが適切であるかを示す指標として、各パスのキュー遅延の統計値を用いて、以下の 2 つの効用関数を定義する。

m(max) = min(−d1 ,−d 2 )2m(log) = ∑ wl ln(
l =1

(1)

D − dl)D(2)d l はフローを振り分けたときのパス l のキュー遅延の統計値（平均、標準偏差など）、
D は限界キュー遅延、 wl はパス l の重みを示している。式（1）は、2 つのパスの大きい（悪い）方のキュー遅延に着目している。式(2)は、アプリケーションによってはトラヒックを受信する際の遅延変動に許容量があると考えられ、得られるキュー遅延がエッジルータの守るべきキュー遅延の限界値（ D ）からどれくらい改善しているかを示す指標となっている。log を取ることで、キュー遅延が大きい場合の大小の違いをより明確にできる。重み（ wl ）は、パスの利用に関する管理者の方針を盛り込むために用いる。本項では、トラヒック量を反映させるため、総入力トラヒックの平均レートに対する各パスの平均レートの割合とする。

133- 133 -

どちらの効用関数を用いた場合にも、値が最も大きくなる振り分けを、最適な振り分けと定義する。式（1）、（2）の値を、それぞれ max 遅延、weighted-log 遅延とする。以下の解析および提案方式の評価では、max 遅延について述べる。
なお、本項の数値解析では、流体モデルから求めたキュー長の統計値を用いる [4]。
流体モデルでは、ルータへ入力するフローのトラヒック変動を、on 状態と off 状態で定義する。on 状態とは、フローがレート rk で入力している状態 ( ｋ はトラヒッククラス[ k =1, 2])を、off 状態とはレート 0（入力なし）の状態を示す。各フローon/off 状態
は指数分布に従い、独立に変化するものとする。なお、各パスのキュー遅延の統計値の推定方法の検討等は本課題では扱わず、実装では、実測値のサンプルなどから推定できるものとする。
3.2.1.2 パスの組み合わせとキュー遅延を小さくするフローの振り分け
表 3.2. 1 に解析に用いる 2 種類のフローのトラヒック特性を、表 3.2. 2 に 2 種
類のパスの組み合わせを示す。図 3.2. 2 は表 3.2. 1のフローをパス組み合わせ１へ振り分けたときの平均キュー遅延の max 遅延を示している。パス組み合わせ 1 は 2 つのパスの帯域が同じで、それぞれ 6Mbit/s である。このとき、総入力レートがパスの許容量の 80%となるように、高レートフローの数を 20 本、低レートフローの数を 147本とした（それぞれの合計平均レートは等しい）。図では、曲線に添えた数値が高レー
トフローの本数を、横軸が低レートフローの本数を示している。図中の▽は、パスの利用率を等しくする振り分けを行ったときの遅延メトリックを示している。
表 3.2. 1 フローのトラヒック特性
トラヒッククラス
on 状態の平均時間
off 状態の平均時間
on 状態のレート
on 状態の定常状態確率
平均レート

高レートフロー（H-1） 低レートフロー（L-1）
10 ms
10 ms
30 ms
10 ms
1 Mbit/s
64 Kbit/s
0.25
0.5
256 Kbit/s
32 Kbit/s

表 3.2. 2 パスの組み合わせ
パスの組み合わせパス 1 の帯域
パス 2 の帯域

1
6 Mbit/s
6 Mbit/s

134- 134 -

2
4 Mbit/s
8 Mib/ts

Min-max delay for mean queuing delay

0-0.0005
16

14

12

10

8

6

4

-0.001-0.0015
18

2

20

0

-0.002-0.0025-0.003-0.0035-0.004
0

20

40

60

80

100

120

140

Number of L-1 flow

図 3.2. 2

パスの帯域が同じ場合のフローの振り分けと遅延メトリック

図から、パスの帯域が同じ場合、最適なフローの振り分けは、入力するフローをト
ラヒッククラスごとに 2 分すれば良いことがわかる。また、遅延メトリックを十分大きくする振り分けが複数あることもわかる。このような特徴は、キュー遅延の標準偏差や 99.5 パーセンタイルをメトリック計算に用いたときや、表 3.2. 1 のトラヒック
特性と異なる組み合わせの場合にも、同様に見られた。
次に、パスの組み合わせ 2 について、フローの振り分けと遅延メトリックの関係を
図 3.2. 3 に示す。パスの帯域は 4 Mbit/s と 8 Mbit/s である。パスの帯域が同じ場
合と同様に、高レートフローは 20 本、低レートフローは 147 本とした。

Min-max delay for mean queuing delay

0-0.0005
6

8-0.001

4

0

2

10

-0.0015-0.002-0.0025-0.003-0.003512-0.0040

図 3.2. 3

20

40

60
80
Number of L-1 flow

100

120

パスの帯域が異なる場合のフローの振り分けと遅延メトリック

135- 135 -

図から、パスの帯域が同じときと同様に、遅延メトリックを十分大きくするフローの振り分けが複数あることがわかる。しかし、パスの帯域の比でそれぞれのトラヒッ
ククラスのフローを振り分けたとき（高レートフロー7 本と低レートフロー49 本をパ
ス 1 へ、残りをパス 2 へ）の遅延メトリックは、最適な振り分けの遅延メトリックよりも小さく、最適な振り分けとは著しい差がある。入力するフローの合計レートの平均をパスの帯域に一致させる振り分けの幾つかには、遅延メトリックを十分大きくできる振り分けがあるが、具体的な振り分け数はトラヒック特性に依存することが予想され、本数を求めることは困難である。
そこで、パスの帯域が異なる場合に着目して、遅延メトリックを十分大きくする振り分けを求める方式を開発したので、次節で説明する。
3.2.2 キュー遅延を小さくするフロー振り分け方式
本節で報告する遅延メトリックを大きくするフローの振り分け方式は、各パスのキュー遅延を推定できることが前提となっている。パスへ入力するフローの数が同じでも、パスの帯域が異なればキュー遅延は異なる。そのため、パスの帯域が異なる場合には、パスごとにキュー遅延を推定する必要がある。
推定方法を考案するために、3.2.2.1節では、一つのパスに着目して、入力するフローの本数とそのときのキュー遅延の関係を、パスの利用率と一方のトラヒッククラ
スの割合の観点から示す。次に、この関係を基に、遅延メトリックを最大にするフロー振り分け方法の提案を3.2.2.2節と3.2.2.3節で説明する。最後に、3.2.2.4節で提案
手法の評価を行う。
3.2.2.1 フロー数とキュー遅延の関係
図 3.2. 4 は、一つのパスに着目して、同じキュー遅延を与えるフローの振り分けの集合をプロットしている。ここでは、キュー遅延として 99.5 パーセンタイルを用いている。フローのトラヒック特性は表 3.2. 1 と同じで、パスの帯域は表 3.2. 2の組
み合わせ 2 を用いた。横軸は入力するフローの総平均利用率を、縦軸は高レートフローの割合を平均レートの観点から示している。以下では、この縦軸に着目するトラヒ
ッククラスは、on 状態の定常状態確率が小さい方のトラヒッククラスとする。

136- 136 -

1

Ratio of class 1 flow (s)

0.8

0.6

0.4

queuing delay: 0.00025 s
queuing delay: 0.00050 s
queuing delay: 0.00075 s
queuing delay: 0.00100 squeuing delay: 0.00125 s

0.2

0
0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Average path utilization (u)図 3.2. 4

キュー遅延（99.5 パーセンタイル）が一致するフローの振り分け

図から、キュー遅延が一致するフローの振り分けが複数存在することがわかる。以下では、このキュー遅延が一致するフローの振り分けを結ぶ曲線を、等遅延線と呼ぶ。
異なるトラヒック特性の様々な組み合わせ、および、パス帯域の様々な組み合わせについて調べたところ、等遅延線には次のような性質があることがわかった。
•

互いに交わらない•

キュー遅延が大きい等遅延線は、平均利用率の大きい領域（図の右側）に配置される•

トラヒック特性やパスの帯域によって等遅延線の配置（傾き）は異なる
もし、等遅延線の配置およびその傾きが事前にわかれば、ある数のフローをパスへ入力したときの、キュー遅延を推定できると考えられる。そこで、パスの帯域とトラヒック特性が与えられたときに等遅延線の配置を求めるアルゴリズムを開発した。
3.2.2.2 等遅延線配置の近似アルゴリズム
等遅延線の配置を求めるために、過去のフローの振り分けとそのときのキュー遅延の統計値を、サンプルデータとして用いることができるとする。まず、等遅延線が配置される空間を限定するための準備として、キュー遅延が起こるための条件を考える。
キュー遅延が発生するためには、式（3）に示すように、パス l にトラヒッククラス 1と 2 のフローがそれぞれ f (1,l ) 本と f ( 2,l ) 本が入力するときに、ピークレート（全てのフローの on 状態が重なるときのレート）がパスの帯域 C l を超えなければならない（ rk はトラヒッククラス k のフローの on 状態のレート）。

137- 137 -

r1 f (1,l ) + r2 f ( 2,l ) > C l

(3)
(on )

トラヒッククラス k のフローが on 状態である定常状態確率を p k( on )（ p1≤ p 2( on ) ）、

パスの利用率を u（ 0 < u < 1 ）、トラヒッククラス 1 の割合を s（ 0 ≤ s ≤ 1 ）とおくと、( on )

式（3）、 p1s>

r1 f (1,l ) = suC l 、 p 2( on ) r2 f ( 2,l ) = (1 − s )uC l の関係から、次の制約を得る。

p1( on )p 2( on )(− 1) ifp 2( on ) − p1( on ) up1( on ) < p 2( on )(4)

u > p1( on ) otherwize （ p1( on ) = p 2( on ) ）式（4）をもとに、等遅延線を反比例の関数（式[5]）に近似する。

s=

a
+b
u

(5)

この近似で得られる曲線は、図 3.2. 4 の等遅延線とよく一致し、トラヒック特性の他の組み合わせや、パス帯域の他の組み合わせの場合にも一致することがわかった。s式（5）から、同じキュー遅延をもつサンプルデータがあれば、等遅延線を描くことができる。次に一つのサンプルデータから等遅延線を描くアルゴリズムを、次に示す。
アルゴリズムは、i) 0 ≤ s ≤ 1 のもとでは 0 < u < 1 、ii) 式(4)の制約、iii) 3.2.2.1節
で明らかにした等遅延線の性質を用いて、初期値から繰り返し a と b を少しずつ動かして、等遅延線の配置を求める。等遅延線の移動は、複数を同時に動かし、それぞれの遅延線は独立したパラメータ（ a と b）を持つものとする。i 回目の繰り返しのとき、ある一つの等遅延線のパラメータを a i , bi とする。等遅延線は次のアルゴリズムで移動する。
1. a の初期値（ a 0 ）と a の移動量の初期値 α （ α > 0 ）を与える。 a 0 の例
( on )

としては、もし p1< p 2( on ) ならp1( on ) p 2( on )などとする。 b0 はサンプルデp 2( on ) − p1( on )ータと a 0 から得る。
2. i 回目の繰り返しでは、次の規則で ai を更新する。
①

もし等遅延線が上記制約の i)または ii)を侵す場合には、ai = ai −1 − αとする。

②

もし等遅延線がサンプルデータよりも高い（ s 値が大きい）領域で交わるとき、遅延が大きい方の等遅延線を ai = ai −1 − α 、遅延が小さい方の等遅延線を ai = ai −1 + α とする。

③

逆に、もし等遅延線がサンプルデータよりも低い（ s 値が小さい）領域
で交わるとき、キュー遅延が大きい方の等遅延線を ai = ai −1 + α 、遅延138- 138 -

が小さい方の等遅延線を ai = ai −1 − α とする。
上記の移動規則で、ai を増加すると等遅延線の傾きは緩やかになり、逆に、

ai を減少すると等遅延線の傾きは急になる。各繰り返しの等遅延線の移動
は、キュー遅延が大きい等遅延線から行う。 bi は、1と同様、サンプルデー
タと ai から求める。もし、ai の値が増減を繰り返す場合は、α を半減する。
なお、複数の等遅延線の中に、2 点以上のサンプルデータから生成される等
遅延線が存在すれば、その等遅延線は動かさない。
3. もし、全ての等遅延線について、上記制約 i)から iii)の全てを満たすか α
が十分小さくなるとき、等遅延線の移動を終了する。
以上の方法で、サンプルデータ数分の等遅延線の配置を決定する。
3.2.2.3 最適なフロー振り分けの探索
前節では、複数のサンプルデータから等遅延線の配置を求めるアルゴリズムを説明した。フローの振り分けを決定するためには、全ての振り分けの中から3.2.1.1節の遅延メトリックを最大化する振り分けを探索する。探索は、山登り方を適用する。具体的には、初期値として、パスの帯域の比でそれぞれのフローを分割する。そして、先ず、一方のフローの本数を動かして、遅延メトリックの極大値が得られるまで動かし続ける。次に、もう一方のフローの本数を一つ動かして、再び極大値を得られるまで
前者のフローの本数を動かしていく。これを繰り返し、後者のフローの本数を変更しても、極大値がさらに大きくならなければ、その極大値の振り分けを最適な振り分けとして、探索を終了する。
探索中、あるフローの本数に対するパスのキュー遅延を求めるとき、そのフローの本数に該当する点が前節で得た等遅延線上に乗ることは少なく、多くの場合等遅延線の間に位置することになる。このとき、最も近い 2 本の等遅延線からの距離の比を用いてキュー遅延を算出する。
以上の方法で、過去のサンプルデータから新規入力フローに対する最適な振り分けを求める。
3.2.2.4 提案方式の評価
前節で説明した手法が、パスの帯域に基づくフローの振り分け（以下ではこれを「帯域に基づく振り分け」という）よりもキュー遅延を改善できることを確認するため、帯域に基づく振り分けと提案手法による振り分けによって得られるそれぞれの遅延メ
トリックを比較する。
図 3.2. 5 は、3.2.1.2節で説明したフローをパス組み合わせ 2（表 3.2. 2）に振り分けるときの、99.5 パーセンタイルキュー遅延に関する max 遅延の比較を示している。パスの総容量（12 Mbit/s）に対する入力フローの総平均レートの割合（横軸）が139- 139 -

0.5 から 0.9 のそれぞれの場合について比較している。各利用率を与えるフローの本
数は複数あるため、それぞれの入力本数から得られる max 遅延値の平均を用いて比較した。さらに、提案方式によるフローの振り分けでは、サンプルデータによって、最適振り分け数が異なってくるため、10 から 40 のランダムに選んだサンプルデータを用いた場合に得られる最適な振り分けの max 遅延について、100 回分の平均値を用いている。帯域に基づくフローの振り分けの場合は、入力本数が決まると振り分け数が決まり、max 遅延が求められる。図 3.2. 5 の縦軸は、このようにして得られた帯域に基づく振り分けの max 遅延に対する、提案方式の max 遅延を示している。つまり、縦軸の値が小さいほど、提案方式の max 遅延の方が大きく、よりキュー遅延を小さくできることを示している。なお、max 遅延の改善の割合は実際のキュー遅延の改善のRatio of delay metrics for proposed algorithm and naive assignment

割合と一致するため、縦軸をキュー遅延の改善と読み替えることができる。

図 3.2. 51

10 data
20 data
30 data
40 data

0.9

0.8

0.7

0.6

0.5
0.5

0.55

0.6

0.65

0.7

0.75

0.8

0.85

0.9

Average utilization over two paths

max-min 遅延を指標としたときの提案手法のフロー振り分けの効果

図から、サンプルデータ数が 20 以上あれば、キュー遅延の大きな改善を見込める
ことがわかる。特に、パスの利用率が 75%から 90%の場合にその効果は大きく、最大で40％の遅延の改善が得られている。さらに、利用率が少ない場合であっても、約 20％の改善が得られている。この他に、異なるトラヒック特性の組み合わせや、パスの帯域が異なるときについても同様の改善を確認した。図を示していないが、weighted-log
遅延を用いた場合には、5%から 20%の改善を得られることがわかった。
3.2.3 10G クラスのトラヒック特性計測システムの開発
前節に示したフロー振り分け手法を用いるためには、トラヒック特性として、フローの on 状態のレートと、on 状態の定常状態確率が明らかになっている必要がある。
将来のバックボーンネットワークは、エッジルータであっても、10 Gbit/s 程度のト140
- 140 -

ラヒックを扱うことが予想される。既存の研究開発では、1Gbit/s のトラヒックを対象としたフロー計測システムが開発されているが[5, 6]、10G ビットクラスのトラヒ
ックを扱うシステムは存在しない。そこで、本年度から 10G ビットクラスの計測シス
テムの開発に着手した。
3.2.3.1 機能要求
トラヒック特性計測システムの機能として、以下の機能が必要である。
1. 長時間継続するフローの検出
2. 平均レート、on 状態のレートの計測
3. 100 マイクロ秒の解像度
4. 1000 以上のフローの特性を同時に計測
5. 10Gbit/s の速度に対応
6. 送信元/宛先 IP アドレス、プロトコル、送信元/宛先ポート番号を組み合わせたフローの定義が可能
7. 登録されたフローについて、パケット/バイトをカウントする
フローの振り分け処理では振り分けられたフローが長時間継続することが前提となっている。そのため、計測システムは長時間継続するフローを検出でき、それらのフローについてトラヒック特性の計測を行う必要がある。また、継続的に到着するフ
ローのトラヒック特性計測を行うため、複数フローを同時に計測できる必要がある。
さらに、フローには様々な定義があるが、アプリケーションを区別できる分類であれ
ばフローごとにトラヒック特性の特徴が現れやすいため、上述の 5 つ組みで区別されるフローを定義できなければならない。
3.2.3.2 基本設計
計測システムは、多量なトラヒックの中から長時間継続するフローを検出し、そのフローについて、トラヒック特性計測を行う。多数の短時間で終了するフローから長時間継続するフローを区別するためには、分類されたフローが特定の時間以上継続す
るか監視する必要があり、多量なメモリ資源を必要とする。そこで、発生するフローの登録処理は安価なメモリを多量に搭載可能な解析装置を用いる。なお、安価なメモリを用いる場合、処理速度が 10Gbit/s の高速なトラヒックについていけないことが予想されるため、複数の解析装置を用いてフローを監視することとする。その結果、入力するトラヒックをこれら解析装置へ振り分ける処理が第二のボトルネックとなるため、トラヒックの分散処理はハードウェア等を用いて高速に処理する必要がある。解析装置によって検出された長時間継続するフローについては、トラヒック特性を推定し、3.2.2節で説明したフロー振り分け方式を実装する装置へ通知する。
図 3.2. 6 に、基本構成を示す。エッジルータに入力する回線のトラヒックをタッ

141- 141 -

プするため、システムは複数の回線を収容できる必要がある。
本開発では、分散装置をハードウェアによって、解析装置およびフロー振り分け装置を汎用 PC によって開発する。本年度は開発費の関係で、分散装置の開発を行った。

図 3.2. 6

トラヒック特性計測システムの構成

3.2.3.3 分散装置
分散装置の開発には、Intel 社製 IXDP2800 Advanced Development Platform を使用
した[7]。同プラットフォームは、パケットの入力および出力処理用にそれぞれ 16 個のマイクロエンジンが並列で動作するネットワークプロセッサーを搭載している。ソフトウェアには、多数のネットワークプロトコルをサポートするライブラリが提供され、パケット転送処理に関係する開発を迅速に行える環境が整えられている。さらに、高速にバイト列のパターンマッチができる連想メモリ（Content Addressable Memory[CAM]）を搭載し、同時に 1000 本のフローを登録できる。
分散装置の処理として、入力するパケットの識別を行い、フロー識別子に該当する解析装置へパケットのヘッダを転送する。パケット転送処理の負荷を小さくするため、一つの転送データに複数のパケットヘッダを格納する。さらに、解析装置から計測を行うフローの指定を受けると、CAM にフローの情報を登録する。CAM に登録されたフローについては、バイト･パケットカウントを行い、定期的にカウンタ値を解析装置へ通知する。
以上の仕様の分散装置を開発し、10Gbit/s のトラヒックについて、平均 256 バイト

142- 142 -

以上のパケット長のトラヒックについて、ワイヤーレートの処理が可能なことを確認した。
3.2.3.4 平成 18 年度の開発
平成 18 年度の開発では、解析装置およびフロー振り分け装置の開発を行う。3.2.1
節で説明したフロー振り分け方式は、on 状態の定常状態確率および on 状態のレートを用いる。そこで、18 年度は、少量のメモリで on 状態の定常状態確率を推定可能な方式を開発する。さらに、ルータへ設定変更を投入可能なフロー振り分け装置を実装も行う。
3.2.4 まとめ
本年度は、先ず、バックボーンネットワークのエッジルータが、トラヒック特性に基づく複数パスへのフロー振り分け方式を開発し、パスの帯域が異なる場合に、パスの利用率に基づくフローの振り分けよりもキュー遅延を最大で 40% 減少可能なことを確認した。
本方式はフローのトラヒック特性（on/off 状態が指数分布で on の状態の定常状態
確率とレート）が予め明らかになっていることが前提であるため、フローのトラヒッ
ク特性を計測する 10G クラスのトラヒックのトラヒック特性計測システムの開発に着手した。同開発では、先ずシステムの要求機能を明らかにし、次に 10Gbps のトラヒッ
ク速度に対応できるための基本システム構成を設計した。設計では、各フローの継続
時間を監視する機能を複数の装置で処理する解析装置、フローの識別とその識別子にもとづいたフローの振り分けを行う分散装置と、フローのトラヒック特性に基づいてフローを振り分ける振り分け装置の 3 つの装置で構成することとした。さらに、処理負荷が最も大きくなる分散装置をハードウェアによって開発した。
その他に、本報告では割愛したが、本年度は、少量のデータを頻繁に転送し、通信の変化が実行性能に大きく影響するアプリケーションのトラヒックを対象としたトラ
ヒックエンジニアリングを行うことを想定して、アプリケーションのトラヒックがネットワーク資源の状態に与える影響と、逆にネットワーク資源の状態がアプリケーシ
ョンの実行性能に与える影響についても調査を行った。そして、ネットワーク特性とアプリケーションの実行性能の関係を予め明らかにしてアプリケーションの実行性能に着目したトラヒックエンジニアリングを行うことができれば、効率的な資源割り当てが可能なことを示した。

143- 143 -

参考文献
1. P. Siripongwutikorn, and S. Banerjee, “Per-flow Delay Performance inTraffic Aggregates,” Proc. of IEEE Globecom, vol. 21, no. 1, Taipei, (2002)
pp. 2641-2645.
2. V. Trecordi, and G. Verticale, “Per-flow Delay Performance in a FIFO
Scheduler fed by Policed UDP Sources,” Comp. Commun., vol. 23, (2000) pp.
309-316.
3. Y. Xu, and R. Guerin, “Individual QoS versus Aggregate QoS: A Loss
Performance Study,” in Proc. IEEE Infocom 2002, vol. 3, New York, (2002)
pp. 1170-1179.
4. V. Ramaswani, “Matrix analytic methods for stochastic fluid flows,”
Proceedings of ITC 16, pp.1019-1030, Elsevier, Amsterdam (1999).
5. Y. Kitatsuji, K. Yamazaki, M. Tsuru, and Y. Oie,

“Real-Time IP Flow

Measurement Tool with Scalable Architecture,” IEICE Trans. Inf. & Syst.,
Vol. E87-D, No. 12, pp. 2665-2677.
6. T. Murooka, M. Hashimoto, T. Miyazaki, “A High-Resolution Traffic
Monitoring System,”IEICE Trans. Inf. & Syst., Vol. E87-D, No. 12, pp.
2618-2626.
7. Intel IXDP2800 Advanced Development Platform,
http://developer.intel.com/design/network/products/npfamily/ixdp28x5.htm
8. Y. Kitatsuji, K. Yamazaki, H. Koide, M. Tsuru, and Y. Oie, “Influence of
Network Characteristics on Application Performance in a Grid Environment,”
Telecommunication Systems Vol 30 No 1/2/3 (2005), pp. 99-122.

144- 144 -

3.3. 品質を考慮したシームレスな資源利用・割当て制御技術の研究開発
無線通信技術の急激な発達とともに，様々な速度・特性を持つ無線網やモバイル網が利用されるようになってきている．すなわち，インターネットアクセス網が多様化してきているが，それらの無線を利用した新しいアクセス網は従来から用いられている有線アクセス網よりも品質の変動が激しいという特徴がある．一方で，インターネ
ット上で利用されるアプリケーションも多様化してきている．すなわち，高速なコア網と多様なアクセス網を通過するエンドツーエンドパス上を多様なトラヒックが横断するようになってきており，それらのトラヒックは従来のトラヒックよりも特性のレンジが広く変動も激しいという特徴がある．また，要求される品質も従来よりも多様化してきている．このような背景から，高品質なエンドツーエンド通信を公平かつ効率よく実現することが今後の多様化したインターネットでは大変重要な課題となる．
具体的には，アプリケーションの要求する品質を満たしつつ，様々なアクセス網をシームレスに利用できるような動的適応的な資源利用・割当制御技術が必要であるといえる．その際，利用者側からはその時々の状況に応じた資源の使い分けに関する要求があり，また提供者側からは効率的かつ公平な資源の割当てに関する要求があるため，
今後はこの利用者側・提供者側双方の要求を満たす資源利用・割当制御技術を確立しなければならない．
そこで，本研究課題では利用者側に近い有線，無線を含んだ多様な統合アクセス網を対象とし，その中でエンドツーエンド通信の品質や限られた資源の利用効率の向上を目的としている．その目標を達成するため，例えば単一の無線 LAN 内のようなシン
グルドメイン内の制御技術と，複数のドメイン間での制御技術の両側面から取り組み
はじめ，さらに本年度よりマルチホップ無線環境へ対象を広げ，またこれらと平行して通信品質制御技術も取り組みはじめた．本年度の主要な研究開発課題をまとめると，
シングルドメイン内制御技術（3.3.1 節），マルチドメイン間制御技術（3.3.2 節），および通信品質制御技術（3.3.3 節）となる．これらの研究課題に関する主要な成果を以下の節で報告する．

3.3.1. シングルドメイン内制御技術
近年，場所にとらわれない柔軟な導入が可能で，高速な通信を提供する IEEE802.11に準拠した無線 LAN の普及が進んでいる．これに伴い，通信容量の増強や通信範囲の拡大のために大規模な無線ネットワークを構築したいという要求が高まっている．しかし，1 台の AP（Access Point）が提供する通信範囲は 50 m 程度と狭く，その通信容量も限られるため，複数の AP を利用した大規模な無線 LAN の構築が行われている．
このような無線ネットワークでは，AP 間を結ぶバックボーンネットワークは有線で145- 145 -

接続することが多い．しかし，有線 LAN を新たに敷設するのは一般的にコストがかかり，また建物によってはイーサネットケーブルの敷設が困難な場合もある．そこで APを相互に無線で接続しメッシュ状に配置することで，低コストかつ高速な通信を提供可能なマルチホップ無線 LAN が実現できると考えられている．このようなネットワー
クでは，AP は端末（STA，Station）から送信されたデータを中継することで，STA 間や外部ネットワークとの通信を提供する．
一方で，このように AP が複数存在する無線 LAN で，各 STA が外部ネットワークもしくは他の STA と通信を確立するためには，各 STA は接続する AP を適切に選択する必要がある．しかし，既存方式では各 STA は RSSI（Received Signal Strength Indicator :受信電波強度）のみに基づいて接続先の AP を決定する．よって，複数の AP があったとしても 1 台の AP の近くに STA が偏在するような場合は，それらの STA はすべて RSSIが強い近くの AP に接続してしまい，AP 間の接続 STA 数に偏りが生じる．その結果，ホテルのロビーや駅構内，展示会場といった実際の使用環境を想定すると，既存手法（RSS, Received Signal Strength）では無線帯域を有効かつ公平にできない可能性があることが報告されている．そこで，その解決手法として，昨年度，予測したスルー
プットが最大になる AP を接続先に選択する MLT（Maximizing Local Throughput）ア
ルゴリズムと，そのアルゴリズムに従って動的に AP を選択する機構を研究開発した．
そしてこれまでの評価により，STA は MLT を用いて AP を選択することで，無線資源を有効かつ公平に利用できることを明らかにした．
しかし，この提案手法では，AP 同士は全て有線で接続される従来のシングルホップ
無線 LAN を想定しているため，AP 同士が無線で接続されているようなマルチホップ無線 LAN については考慮されていない．そのため，選択した AP がデータを他の AP へ中継する際にパケットロスが頻繁に発生するような場合，AP と STA 間だけの情報に基づいた従来の MLT による AP 選択手法では期待した程のスループットが獲得できず，無線資源を有効かつ公平に利用することができない可能性がある．そこで本年度は，マルチホップ無線 LAN に対応するために MLT を拡張した AP 選択方式に取り組み，シミュレーション評価により本手法は従来方式に比べスループット性能が最大で約 40％改善
することを明らかにし，その成果を情報ネットワーク研究会で発表した[1]．また，AP間で干渉が発生した場合や，マルチホップ無線 LAN での動的なトラヒック制御についても調査を行い，それぞれ情報ネットワーク研究会で発表した[2，3]．さらに，幾つかの性能指標に対する最適解を求め，本手法が自律分散型にもかかわらず無線 LAN 全体の資源を効率よく利用できることを示し，その成果を IEEE 主催の国際会議にて発表
した[4]．また，無線 LAN に接続する STA が下り方向中心のトラヒックを発生する従来のクライアント・サーバ型通信だけでなく，上り方向にも多くのトラヒックが発生す
る P2P 型通信も行う場合について，無線 LAN の MAC 機構に着目した利用効率向上のための機構を提案し，その有効性をシミュレーションにより明らかにした．その成果を146- 146 -

情報通信学会論文誌にて公表した[5].

3.3.1.1. マルチホップ無線 LAN におけるアクセスポイント選択機構
本節では，マルチホップ無線 LAN に対応するために，昨年度提案した MLT を拡張した AP 選択アルゴリズムの詳細について説明する．この MLT では各 STA は接続候補である全 AP に対して期待できるスループットを求め，それが最大となる AP を選択する．
期待できるスループットは式(1)で求まる重み関数で表すことができるため，MLT では
この重み関数を各 AP に対し計算する．

Wth =

1− P
(1)
N

式(1)の P は PER（Packet Error Rate）を示し，受信電波強度から求めることができる．N はその AP と接続して通信を行っている STA 数を示しており，重み関数の計算では式(1)に示すとおり N に自 STA が接続したとしてさらに 1 を足す．STA はこの重み関数が最大となる AP を最適と判断する．しかし，このアルゴリズムはシングルホップ無線 LAN を想定しており，AP 間もデータが無線で中継されるマルチホップ無線 LAN を想定していない．

Wireless link
Pup

Internet

Plow

AP1

AP0
Pm

図 3.3.1 トポロジ(2hop)
そこで，本年度は，マルチホップ無線 LAN 環境においてデータが AP 間を無線で中継される際の PER を考慮した MLTM（MLT extension for Multihop Environment）アルゴ
リズムを提案した．図 3.3.1 に示すトポロジを例に挙げ提案 AP 選択手法について説明する．ここで，図 3.3.1 において AP0 は有線ネットワークへのゲートウェイ（GW,
Gateway）とする．また，無線リンクで接続されたある 2 つの AP のうち，有線ネット
ワークに近い AP を上位 AP，他方を下位 AP と呼ぶ．ここで，有線ネットワークに近いとは，データが無線で伝達される回数（ホップ数）が少ないことを指す．すなわち，

147- 147 -

図 3.3.1 では下位 AP を AP1 とすると上位 AP は AP0 である．さらに，Pup は上位 AP と
STA 間の PER，Plow は下位 AP と STA 間の PER，Pm は下位 AP と上位 AP 間の無線リンク
における PER である．提案手法では AP 間の PER を考慮するためこの Pm を用いて，式(1)を式(2)に拡張する．

W1 =(1 − Plow ) × (1 − Pm )(2)
N low + 1

ここで，Nlow は下位 AP の接続 STA 数である．AP は Probe Response および Beacon フ
レームに接続 STA 数と AP 間の PER(Pm)，上位 AP を特定するために上位 AP の MAC アド
レスの情報を追加する必要がある．STA は式(2)より重み関数を計算した後(a)，上位
AP に対しては従来の MLT と同様の式(3)を用いて計算する(b)．

W2 =(1 − Pup )N up + 1(3)

ここで，Nup は上位 AP の接続 STA 数である．提案手法では，STA はこの(a), (b)の計算を全 AP に対して行い，求められた重み関数 W をそれぞれ比較し最も値が大きい AP
を接続先 AP として選択する．
また，STA が提案 AP 選択アルゴリズムを無線 LAN に参加する時のみしか実行しない
場合，その後の環境変化に伴い，STA にとって最適な AP は変化している可能性がある．
環境が変化しても最適な AP を各 STA が選択するためには，定期的に AP 選択アルゴリ
ズムを実行する必要がある．そこで昨年度提案したリンク監視機構も用いている．

3.3.1.2. シミュレーション評価モデル
本 方 式 の 有 効 性 評 価 の た め に ， Network Simulator 2 を マ ル チ ホ ッ プ や Static
Routing に対応するよう拡張した TeNs（The Enhanced Network Simulator）を用いてシミュレーション評価を行った．20 台の STA を図 3.3.2 に示すような 40 m × 80 mのエリア（AREA 1-4）に 10 秒間でランダムに配置し，配置後は移動しないものとした．
ここで，AREA 1 はエリア全体に STA が分布した場合を想定している．しかし，実際の使用環境は机や椅子の配置などの影響を受けるため，AREA 2 では AP 側へ STA の分布が偏った場合を想定した．AREA 3 および AREA 4 では STA の分布がさらに偏り，特定の AP 近傍に STA が集中した場合も想定しシミュレーションを行った．なお，各 STAは最も近い 2 つの AP のみと通信を確立できると想定している．また，ルーティングプ
ロトコルには Static Routing を用いた．本評価では，アプリケーションとして FTPのようなファイル転送を想定し，送信側（Source）である AP0 は TCP 通信を行うものとし，そのパケットサイズは 1500 Byte とした．従って，図 3.3.2 において AP1 へ接続した STA へのデータは，Source → AP0 → AP1 → STA と転送される．ここで，図148- 148 -

3.3.2 のトポロジにおいて最大ホップ数は 2 ホップである．また，無線 LAN は 802.11bによって構成されるものとし，無線区間のエラーモデルとして shadowing モデルを採用した．その PER 特性を図 3.3.3 に示す．さらに，各 AP は STA 用と中継用にそれぞれ
無線 LAN インターフェースを持つとし，利用するチャネル間で干渉は生じないとした．
また，リンク監視機構におけるパラメータは，表 3.3.1 に示すパラメータを用いた．

AREA

1

:
AREA

10m

2
AREA

:
3

:

10m

Source

AP

AREA

4

AP

:
図 3.3.2 STA 分布

PER(%)

100
80
60
40
20
0

0 10 20 30 40 50 60 70 80 90100
Distance(m)図 3.3.3 距離-PER 特性

149- 149 -

表 3.3.1 リンク監視機構の状態遷移パラメータ
パラメータ

値

SI

3.0 secBT0∼1.0 secIT

3.0 sec

提案方式の有効性は，全 STA 中の最大，平均，最小スループットや無線 LAN 内の総
スループットに加え，全シミュレーションを通じて得られたスループット確率分布を用いて検証した．さらに，STA 間のスループットの公平性を示す指標として BalanceIndex（BI）を用いて評価を行った．BI とは式(4)で表されるβの値であり，1 に近付
くほど均衡を表し，1/N に近付くほど不均衡を表す．ただし，Bi は STAi の平均スルー
プット，N は STA 数を表す．

β=(∑ β i )2

N × ∑ (β i )2(4)3.3.1.3. シミュレーション評価結果
本節では，受信電波強度のみで AP を選択する既存手法（RSS）と比較し提案手法の有効性について述べる．まず，STA が均一に分布している AREA1 について評価を行った．図 3.3.4 に示す各 STA の平均スループット確率分布より，スループットの分布はRSS では約 100 ∼ 500 Kb/s に分散しているが，提案手法では約 150 Kb/s ∼ 300 Kb/sに集中していることが分かる．さらに，表 3.3.2 に示すスループット特性から，RSSにおいて最大スループットと最小スループットとの差は約 220 Kb/s であったが，提案手法ではその差を約 80 Kb/s まで縮めていることが分かる．一方，提案手法の総スループットは RSS より低いものの，表 3.3.3 に示す公平特性から BI は RSS より高い．それに加え，表 3.3.2 から，提案手法は RSS よりも最小スループットを約 40 Kb/s 改善
できていることが分かる．したがって，STA が均一に分布している環境（AREA1）について，提案手法は最小・最大スループットの差を縮め，最小スループットを改善する
ことで，STA 間の公平性を向上させることが分かった．

150- 150 -

0.1

RSS
MLT-M

0.09
0.08
Probability

0.07
0.06
0.05
0.04
0.03
0.02
0.01
0
0

100

200
300
400
Throughput[Kb/s]

500

600

図 3.3.4 スループット確率分布（AREA1）
表 3.3.2 スループット特性（AREA1）
スループット(Kb/s)
AP 選択機構

最小

平均

最大

合計

RSS

138.34240.05359.264801.09

MLT-M

176.96228.41260.344568.19

表 3.3.3 公平特性（AREA1）
AP 選択機構

BI

RSS

0.8349MLT-M

0.9700

次に，STA が偏在している AREA2 について評価を行った．図 3.3.5 に示すスループ
ット確率分布から，RSS では STA の獲得スループットが約 80 Kb/s に集中しているが，約 600 Kb/s を越えるスループットを獲得している STA も存在していることが分かる．
一方，提案手法を用いた場合，スループットの分布が約 100 ∼ 250 Kb/s に集中していることが分かる．さらに，表 3.3.4 のスループット特性より，RSS を用いた場合，最大スループットと最小スループットの差が約 880 Kb/s と大きかったが，提案手法を用いることで約 100 Kb/s と大幅に改善できることが分かる．加えて，最小スループット
も約 60 Kb/s 改善していることが分かる．これにより，提案手法は RSS において一部の STA が独占的に獲得していた高いスループットを抑え，通信条件の悪い STA を保護できることが分かった．また，表 3.3.4 より提案手法の総スループットは RSS より低

151- 151 -

いものの，表 3.3.5 より公平性を示す BI は RSS より高い．以上から，STA が偏在している環境（AREA2）では，提案手法は RSS と比較して公平性を改善可能な AP 選択手法
であることが分かった．

0.18

RSS
MLT-M

0.16

Probability

0.14
0.12
0.1
0.08
0.06
0.04
0.02
0
0

100

200

300

400

500

600

Throughput[Kb/s]

図 3.3.5 スループット確率分布（AREA2）
表 3.3.4 スループット特性（AREA2）
スループット(Kb/s)
AP 選択機構

最小

平均

最大

合計

RSS

81.08

235.66963.524713.19

MLT-M

142.64

196.15239.403923.03

表 3.3.5 公平特性（AREA2）
AP 選択機構

BI

RSS

0.4116

MLT-M

0.9545

さらに，STA が極端に偏在している AREA3，AREA4 について，図 3.3.6，3.3.7 に示すスループット確率分布より，RSS では，スループットの分布が低い値で集中していることが分かる．これは RSS が受信電波強度によって AP 選択を行った結果，全 STA
が AP0 または AP1 に接続し，1 台の AP が提供する無線資源を全 STA で共有したためである．このように，既存手法である RSS では，マルチホップ無線 LAN において STA 分
布が極端に偏ると，無線資源を有効に利用できないことが分かる．一方，図 3.3.6，
図 3.3.7 から提案手法により STA が自律的に最大スループットを期待できる AP を選択

152- 152 -

することで他の AP へ STA の接続が分散し，STA のスループットは RSS と比較して全体的に向上していることが分かる．さらに，表 3.3.6，3.3.7 に示すスループット特性から，最小，平均，最大スループットともに RSS より提案手法の方が高い．加えて，総スループットに関しても RSS と比較して提案手法の方が AREA3 では約 2000 Kb/s，AREA4では約 1500 Kb/s 高いことが分かる．よって，STA が極端に偏在している場合，提案
手法は RSS と比較して無線資源をより有効に利用できると言える．しかし，表 3.3.8，
3.3.9 より RSS の BI はどちらの場合も提案手法より高い．これは先ほど述べたように，
全 STA が AP0 または AP1 に集中した結果，全 STA で帯域を共有し，スループット差がほとんど無くなったためである．一方で，提案手法は RSS と遜色ない BI の値をとっていることが分かる．したがって，STA が極端に偏在している環境（AREA3，AREA4）において，提案手法は公平性を充分高く維持しつつ，スループット特性を改善できることが分かった．

0.6

RSS
MLT-M

Probability

0.5
0.4
0.3
0.2
0.1
0
0

100

200
300
400
Throughput[Kb/s]

500

図 3.3.6 スループット確率分布（AREA3）153- 153 -

600

図 3.3.7 スループット確率分布（AREA4）
表 3.3.6 スループット特性（AREA3）
スループット(Kb/s)
AP 選択機構

最小

平均

最大

合計

RSS

59.70

70.46

73.80

1409.27

MLT-M

125.85168.73209.153374.65

表 3.3.7 スループット特性（AREA4）
スループット(Kb/s)
AP 選択機構

最小

平均

最大

合計

RSS

166.93167.90168.983358.00

MLT-M

211.58240.45368.734809.09

表 3.3.8 公平特性（AREA3）
AP 選択機構

BI

RSS

0.9683

MLT-M

0.9284

表 3.3.9 公平特性（AREA4）
AP 選択機構

BI

RSS

1.0000MLT-M

0.9419154- 154 -

以上の結果から，提案手法は最小スループット及び STA 間の公平性を RSS よりも改善できることがわかった．また，STA が遍在するような場合は，平均スループット特性も大きく改善できることも分かった．

3.3.2. マルチドメイン間制御技術
無線通信技術の急激な発達とともに，様々な速度・特性を持つ無線網が広く展開し，
いつでもどこでもインターネットアクセスが可能なユビキタス環境が整備されつつある．例えば，高速な通信が可能である無線LANや比較的低速ではあるがカバー範囲が広いセルラー網などはすでに利用されており，今後さらに多種多様なアクセス網が登場することも予想されている．一方で，インターネット上で利用されるアプリケーションも多様化してきており，様々な特性を持つトラヒックが高速なコア網や多様なアクセス網を横断し，また要求される通信品質も従来より多様化してきている．このような背景から，高品質なエンドツーエンド通信を効率よく実現することが今後の多様化したインターネットでは大変重要な課題となる．特に，無線アクセス網は従来の有線アクセス網や高速コア網よりも品質の変動が激しく，そのレンジも広いため，エンド
ツーエンド通信の品質に与える影響が大きい．そのため，アクセス網においてアプリ
ケーションが要求する品質を満たすような動的適応的な資源利用・割当制御技術が必要であるといえる．すなわち，このようなユビキタス環境において，高品質かつ高効率な移動通信を実現するためには，移動ホストは複数の通信メディアを持ち，そのネットワーク状況や通信フロー特性に応じて最適な通信メディアを選択し，通信を切断することなく独立的にそれらの通信メディアを利用可能なことが要求される．
そこで，本テーマでは，多種多様なアクセス網が相互に重なり合い配置される今後のユビキタスネットワークにおいて，同時に複数のアクセス網を利用可能なマルチホー
ム環境を利用する際に，通信メディアの状況や利用するアプリケーションの特性に応じて，通信フロー毎に通信中でも自由に複数の通信メディアを選択し，利用することが可能なシステムに関して取り組んだ．その結果，各通信ホストが持つ通信メディアの情報を管理し，状況に応じて動的に通信メディアを使い分けるための機構として，
新たなネットワークアーキテクチャ Media Optimization Network Architecture（ MONA）を考案した．本機構の主な機能としては，通信品質制御を行うフロー割り当て機能や信頼性を向上させるマルチパス通信機能，セキュリティを向上させる暗号化機能がある．本システムの詳細な設計，試作開発を行い，JGN2 シンポジウムにおいて，その有効性に関するデモンストレーションを行った．また，本機構の性能をコンピュータシ
ミュレーションや実機を用いた実験により明らかにし，その成果を IEEE の学術論文誌[6]，ACM 主催の国際会議[7]，および電子情報通信学会主催のネットワークシステム研究会[8，10]，ソサイエティ大会[9]において発表した．さらに，特許出願も 2 件行

155
- 155 -

った[14，15]．以下の節では，この MONA について簡単に説明する．

3.3.2.1. Media Optimization Network Architecture（MONA）の概要

HostβFlow AMedia 1HostαFlow BMedia 2
Flow C
HostγMedia 3

図3.3.8 通信メディア最適化の例

図3.3.9 ネットワーク階層におけるアソシエーション層
MONAは図3.3.8に示すように，各通信フローを独立的かつ動的に適した通信メディアに割り当てる機構を提供する． 従来の機構ではホストが複数の通信メディアを持っていたとしても通信開始時に利用したメディアを使い続けなければならず，また同時に1
つのメディアしか利用できないという制限があった．これはトランスポート層において，フローを識別するための識別子としてIPアドレスを用いているためである．そこ
で，MONAではフロー識別に用いるトランスポート層（4層）識別子と実際にパケットを送受信するために用いるネットワーク層（3層）識別子を分離し，その間で調整を行う
ためのアソシエーション層を新たに3.5層として挿入する．
このアソシエーション層を含むネットワーク階層の概念図を図3.3.9に示す．MONA
はこのようにアソシエーション層において，各トランスポートフローと利用すべき通156- 156 -

信メディアの間の対応を継続的に管理することで，通信中でも動的に適した通信メデ
ィアを選択し，切り替えることが可能となる．さらに，通信メディアの状況に応じて，同一フローを複数のメディアを利用して送受信すること（マルチパス通信）も可能となる．また，受信フローに関して，受信メディアを選択するためには，通信相手にその情報を通知する必要がある．そのため，MONAではそれらの必要な情報を相互に交換するために，トランスポートコネクションとは別に通信相手毎にアソシエーションと呼ぶ通信路を確立する．それにより，同じ通信ホスト間の制御情報はすべてのフローで共有することができ，通信オーバヘッドを抑えることができる．また，利用する通信メディアの変更，すなわちIPアドレスの変更をそのまま通信相手に伝えると，第三者にコネクションを乗っ取られるおそれがあるが，アソシエーションを暗号化することでその対策を行っている．
以上のように，MONA は直接通信相手と制御を行うため，ネットワーク上に特別な機構を必要とせず，モビリティ，マルチホーム環境，および通信メディア最適化を提供するという特徴を持つ．また，既存の通信層を変更せず，主要機構をトランスポート
層とネットワーク層の間に挿入するため，従来のアプリケーションや通信インフラをそのまま利用可能であり，さらに今後登場するであろう新たなトランスポートプロト
コルや通信メディアにも容易に対応が可能であるという利点がある．

3.3.2.2. アソシエーション層の機能
アソシエーション層は，ホスト間アソシエーションを管理する機能と各トランスポ
ートフローを通信メディアに割り当てる機能を有する．本節ではその2つの機能を説明する．
A) アソシエーション管理機能
アソシエーション層は各通信ホストが保持する通信メディアの組み合わせにより形成される論理的な通信路集合をアソシエーションとして管理する．そのアソシエーシ
ョンの管理に必要な機構を以下にまとめる．
¾

アソシエーション確立機構
通信開始時に，そのホスト間でアソシエーションが未確立の場合，アソシエーション情報を交換し，アソシエーションを確立する．

¾

アソシエーション解放機構
ホスト間のすべての通信が終了した場合，アソシエーションを解放し，アソ
シエーション情報を破棄する．

¾

アソシエーション情報通知機構

157- 157 -

利用可能な通信メディア情報が変化した場合，通信相手にその変化を通知する．
¾

アソシエーション診断機構
周期的にアソシエーション状態確認パケットを送信し，ホスト間アソシエー
ション情報の確認，更新を行う．

¾

フロープリファレンス通知機構
フロー毎の受信メディア情報を通信相手に通知する．

¾

マルチパス通信要求機構
通信相手に複数の受信メディア利用を要求する．

B) 通信メディア割当機能
アソシエーション層は自ホストと相手ホストから広告されたアソシエーション情報をもとに，各トランスポートフローを通信メディアに割り当てる．ここで，アソシエーション情報とは各ホストが保持する通信メディアのIPアドレスやその利用優先度，フロー毎の通信メディア情報などである．基本的には，すべてのフローは優先度の最も高いIPアドレス（デフォルトアドレス）を利用する．ただし，ユーザはデフォルト
アドレス以外を利用するフローを設定することができ，その場合フロー毎に通信メデ
ィアを使い分けることが可能となる．そのフローの識別・設定には，トランスポート
プロトコル種別とポート番号を用いる．この通信メディア割当機能は，主に以下の4つの機能部から構成される．その機能ブロック図を図3.3.10に示す．

図3.3.10 機能ブロック図¾

通信メディア監視／診断部
自ホストが持つ通信メディアの状態を監視し，ネットワーク状態の変化を検

158- 158 -

出すると，アソシエーション情報を更新し，通信相手に通知する．
¾

送信部
上位層から受け取ったパケットに対し，送信すべき通信メディアをアソシエーション情報から検索し，適切なアソシエーションヘッダおよびIPアドレスを付加し送信する．

¾

受信部
下位層から受け取ったパケットに対し，アソシエーションヘッダの解析，ア
ソシエーション情報の検索を行い，通信開始時のIPアドレスに復元し上位層へ渡す．

¾

アソシエーション情報管理部
アソシエーションの維持に必要なアソシエーション識別子，通信メディアの状態，IPアドレスやその優先度，またフロー毎の通信メディア情報などを管理する．

3.3.2.3. アソシエーション層プロトコル
アソシエーション層はAssociation Management Protocol（AMP）を用いて，アソシ
エーションを管理する．AMPで用いるヘッダには基本ヘッダとオプションヘッダの2つがある．基本ヘッダはアソシエーションを識別するための情報を含み，すべてのデー
タパケットのIPヘッダとそのペイロード間に挿入される．オプションヘッダは制御情報毎に複数のヘッダを定義しており，アドレスオプション，プリファレンスオプショ
ン，暗号鍵オプションなどがある．これらのオプションヘッダは必要な個数だけ数珠繋ぎで，基本ヘッダとともにデータパケットとは独立して送られる．すなわち，アソ
シエーション情報を通知する必要が生じるとすぐに送信され，また必要に応じて再送制御を行うことができる．

Idle
send Init(socket open)

Init sent

invalid
response

recv Init(socket close)
send Init+Ack

No association

recv Init+Ack
send Ack

Init rcvd
recv Ack

Associated(socket close)

send/recv Release

Releaserecv/send Release

図3.3.11 状態遷移図159- 159 -

次に，アソシエーション層における状態遷移図を図3.3.11に示す．アソシエーションの確立は3-wayハンドシェイクにより行う．まず，“Idle”状態にあるホストが新規に通信を開始すると，アソシエーション確立要求を送信し，“Init sent”状態になる．
その際，Diffie-Hellmanアルゴリズムで用いる乱数とその公開値を生成し，アソシエーション確立要求に付加する．通信相手はその要求を受け入れると，乱数とその公開値を生成し，受信した通信相手の公開値をもとに共有秘密鍵を生成する．その後，生成した共有秘密鍵を用いて保持するIPアドレスのリストをAES暗号化し，公開値とともに確立応答を送信ホストへ返し，“Init rcvd”状態になる．送信ホストはその確立応答を受信すると，同じように共有秘密鍵を生成し，暗号化したアドレスリストを含む確認応答を送信する．その後，“Associated”状態となり，アソシエーションが確立される．もし，確立要求に対する確立応答が返ってこない場合は，通信相手がアソシ
エーション機構を持たないと判断し，“No association”状態となり，従来のTCP/IP，
UDP/IP 通信を行う．その後，そのホスト間ですべての通信が終了すると，各ホストは解放要求を相互に送りあい，アソシエーションを解放する．

3.3.2.4. 実証実験
本機構の実用性を検証するために，Linuxカーネルにアソシエーション層を実装した．
本節では，その実装を用いた実証実験の結果を述べる．まず，実験環境は本機構を実装したホスト2台（Host A，B）をルータを介して接続したものである．Host Aは無線
LANと有線LANによりルータへ接続しており，Host BからiperfによるTCPフローと5Mb/sのUDPフローを受信する．通信開始時は両フローとも無線LAN側から受信し，開始後10～20 秒間はTCPフローのみ有線LANを利用可能な場合を考える．このときのTCPスルー
プット特性とUDPジッタ特性として到着パケット間隔の変動を図3.3.12に示す．この結果から，MONAは通信中でもフロー毎に通信メディアを選択的に利用することができ，
複数メディアを有効に活用することでスループット特性やジッタ特性を向上させることが可能であることがわかる．

160- 160 -

100

160
140
120

60

Jitter [ms]Throughput [Mb/s]

80

40

100
80
60
40

20

20

0

0

0

5

10

15
Time [s]

20

25

30

0

5

10

15

20

25

30

Time [s](a) TCPスループット特性(b) UDPジッタ特性

図3.3.12 実験結果例

3.3.3. 通信品質制御技術
前述したドメイン内制御技術やドメイン間制御技術により，多様化したアクセス網
環境を効率的かつ効果的に利用することができ，また高品質な通信を実現することが可能となる．しかし，頻繁な通信メディア切り替えやネットワーク規模の拡大により，通信品質が低下するおそれも残されている．例えば，通信メディア切り替えの際には，利用可能な帯域や遅延などの通信メディア性能に急激な変化が生じるが，通信フロー
がこの変化に対応できずに通信品質が劣化するおそれがある．さらに，複数のアクセス網を同時に利用可能なマルチホーム環境においては，複数のフローがそれぞれ通信
メディアを選択するため，同じ通信メディアを流れていたフローが分かれて別々の通信メディアを流れたり，それまで別の通信メディアを流れていたフローが切り替えによって合流することがある．特に，フローの合流時には，合流するフローの可用帯域が変化する影響だけでなく，もともと流れていたフローに対する影響も発生する．これは，単一フローのハンドオフでは見られない問題である．したがって，合流時には切り替えるフローだけでなく別のフローへの影響も考慮する必要がある．また，通信
フローには，IP電話などの即時性を求める実時間通信やファイル転送などの効率性に重点を置く非実時間通信がある．これらの通信フローは要求する特性も異なり，またそのためフロー制御のやり方も異なっている．すなわち，このように異なったフロー
特性にあわせた通信品質制御が必要となる．
そこで，トランスポートプロトコルやネットワーク内部との連携やネットワーク内部における制御によって，通信品質の向上を図る手法に関して検討を行った．具体的には，ドメイン間制御手法とトランスポートプロトコルが連携することにより高品質
実時間通信を実現するメディア間フロー制御手法や，ネットワーク内部の通信エージ
ェントを利用することにより通信性能を向上させるアクセス網制御手法，また，ネットワーク内部においてフィードバック制御を用いた帯域割当手法を提案した．コンピ161- 161 -

ュータシミュレーションの結果，これらの手法は既存手法に比べ，実時間通信の遅延・ジッタ特性を60%以上，非実時間通信のスループット特性を2倍以上改善可能であることを明らかにした．以上の成果をIEEE主催の国際会議[11，12]や電子情報通信学会主
催の情報ネットワーク研究会において，発表した．本節の報告の詳細は各参考文献を参照されたい．

参考文献[1] 大藪 赳, 福田 豊, 尾家 祐二, “マルチホップ無線 LAN におけるアクセスポイ
ン ト 選 択 手 法 の 提 案 と そ の 評 価 ,” 電 子 情 報 通 信 学 会 技 術 研 究 報 告 ,IN2005-207, pp.299-304, 2006 年 3 月.
[2] 金子 仁, 福田 豊, 尾家 祐二, “無線 LAN における干渉を考慮した Access
Point 選択方式の提案と評価,” 電子情報通信学会 技術研究報告 , IN2005-205,
pp.287-292, 2006 年 3 月.
[3] 福田 淳平, 福田 豊, 尾家 祐二, “マルチホップ無線 LAN における動的なトラ
ヒ ッ ク 制 御 ,” 電 子 情 報 通 信 学 会 技 術 研 究 報 告 , IN2005-218, pp.365-370,
2006 年 3 月.
[4] Y. Fukuda, A. Fujiwara, M. Tsuru, and Y. Oie, “Analysis of Access Point
Selection Strategy in Wireless LAN,” Proc. IEEE 62nd Semiannual VehicularTechnology Conference (VTC2005-Fall) , pp.25-38, September 2005.
[5] Y. Fukuda and Y. Oie, “Unfair and Inefficient Share of Wireless LAN
Resource among Uplink and Downlink Data Traffic and its Solution,” IEICE

Transactions on Communications , vol.E88-B, no.4, pp.1577-1585, April
2005.
[6] H. Koga, S. Kashihara, Y. Fukuda, K. Iida, and Y. Oie, “A Quality-aware
VoWLAN Architecture and Its Quantitative Evaluations,” IEEE WirelessCommunications , vol.13, no.1, pp.52-59, February 2006.
[7] H. Koga, H. Haraguchi, K. Iida, and Y. Oie, “A Framework for Network Media
Optimization in Multihomed QoS Networks,” Proc. ACM First International

Workshop in Dynamic Interconnection of Networks (DIN2005) in conjunction
with MobiCom2005 , pp.38-42, September 2005.
[8] 古閑 宏幸, 原口 浩朗, 飯田 勝吉, 尾家 祐二, “マルチホーム環境における通信品質を考慮した通信メディア最適化機構の提案,” 電子情報通信学会 技術研究報告 , NS2005-82, pp.25-28, 2005 年 9 月.
[9] 原口 浩朗, 古閑 宏幸, 飯田 勝吉, 尾家 祐二, “マルチホーム環境における通信メディア最適化方式の実装と評価,” 電子情報通信学会 2005 年ソサイエ

162- 162 -

ティ大会 , B-7-39, p.166, 2005 年 9 月.
[10] 古閑 宏幸, 原口 浩朗, 飯田 勝吉, 尾家 祐二, “通信品質を考慮したマルチ
ホーム通信メディア最適化機構の設計と実装,” 電子情報通信学会 技術研究

報告 , NS2005-201, pp.173-176, 2006 年 3 月.
[11] M. Shimamura, K. Iida, H. Koga, Y. Kadobayashi, and S. Yamaguchi,“Performance Evaluation of Hose Bandwidth Allocation Method Using
Feedback Control and Class-based Queueing for VPNs,” Proc. IEEE Pacific

Rim Conference on Communications, Computers and Signal Processing(PacRim2005) , pp.241-244, August 2005.
[12] H. Koga, K. Iida, H. Haraguchi, and Y. Oie, “Handover Latency Reduction
on Host-based Mobility in Multihomed Networks,” to appear in Proc. IEEE

63rd Vehicular Technology Conference (VTC2006-Spring) , May 2006.
[13] 馬場 宏基, 古閑 宏幸, 飯田 勝吉, “高品質実時間通信を維持するためのメ
デ ィ ア 間 フ ロ ー 制 御 手 法 の 提 案 ,” 電 子 情 報 通 信 学 会 技 術 研 究 報 告 ,IN2005-187, pp.183-188, 2006 年 3 月.

出願特許[14] 古閑 宏幸, 原口 浩朗 , “通信装 置, 通信方 法および通 信プロトコ ル処 理 方法,” 特願 2005-245037, 2005 年 8 月.
[15] 古閑 宏幸, 原口 浩朗, “通信端末装置および通信方法,” 特願 2006-45758,
2006 年 2 月.

163
- 163 -

3.4 多様性・可変性に適応する end-to-end 通信制御技術の研究開発
現在のインターネット網の構成はアクセス網とコア網から構成され,ネットワーク
環境としては 無線網と有線網が混在している状況である.これらの網が提供する速度とサービス品質は様々であり, このようなネットワーク網の混在は今後もさらに進むものと考えられる. 一方, ユーザの利用するアプリケーションフローが End-to-End
でネットワークに期待する品質要求もその種別によって異なる. 例えば, 速度を第一と考えるか, 信頼性を第一と考えるか, ネットワーク環境の多様性を背景に, アプリ
ケーションの要求するサービス品質は多様化しており, 今後このように異なった品質要求を持ったフローが多様な環境を持ったネットワーク上に同時に投入され混在する状況がさらに進むものと考えられる. そこで 本テーマでは, このようなネットワー
ク環境の多様性, 可変性 それからその上で動作するネットワークアプリケーションの多様性, 可変性を考慮した制御方式を対象として研究活動を実施している. 制御方式の枠組みとしては 次の２方式 end-to-end の端末上で動作する方式と, end-to-endの端末と中間ノードにおける制御を組み合わせた方式を対象としている.
本章では3.4.1 章に end-to-end の端末間で動作する方式に関して実施した研究活動に関して 3.4.2 章に end-to-end 中間ノードで動作する方式に関して実施した研究活動に関してそれぞれ平成１７年度に得られた成果を報告する.

3.4.1 end-to-end 端末間で動作する制御方式
3.4.1.1 JGNII を利用した高速トランスポートプロトコル伝送実験
本章では 既存の TCP に替わる, 新しいトランスポートプロトコルとして提案されている HSTCP(HighSpeedTCP), Scalable TCP, FAST, BIC, HTCP,UDT の各プロトコルを対象として, JGN(Japan Gigabit Network)II の国内回線, 国際回線を利用して行った実験内容を報告する.[1][2]現在, 長距離・大容量ネットワークにおける効率的な高速データ転送の実現を目的として提案された様々な高速トランスポートプロトコルを対象として, プロトコルの提案者や研究者によって シミュレーションやテストベッドを利用した性能評価実験が進められている.トランスポートプロトコル TCP は,確認応答制御による信頼性の提供, ウィンドウサイズの増減に基づく輻輳制御の実施, 実装の容易さなどから イン
ターネット上の多くのアプリケーションのトランスポートプロトコルとして利用されている.しかし,その輻輳制御アルゴリズムに起因して,長距離・大容量のネットワーク
資源を効率よく利用することは難しいことが知られている.そこで, 分散化（信頼性を保った上での長距離伝送が必要となる）・大容量化するネットワーク資源の 効率な利用を目的として高速トランスポートプロトコルの検討がスタートし, これまでに様々なプロトコルが提案されている(HSTCP, Scalable TCP, FAST, BIC, HTCP,
本報告書では

UDT).

次のような観点から考えたシナリオにおける高速トランスポートプ

164- 164 -

ロトコルのこれらの性能を報告する.これまでに提案されている高速トランスポート
プロトコルの中には, 現在すでに OS に組み込まれて配布されているものや（BIC),ア
プリケーションレイヤで配布されているもの(UDT)もあり,ユーザが端末側で設定を行
えば すぐに利用可能な状況である.このような状況において, インターネットがさらに高速化すると, ユーザはデータ伝送に高速トランスポートプロトコルを利用することを考え始めることが想定される.しかし 本来, 高速トランスポートプロトコルは十分な帯域がある状況で 限られた数のフローが資源を効率的に利用することを目的として提案されたものであり,インターネットのような 不特定多数のユーザが利用するネットワークでの利用は想定されておらず, また そのような状況における性能に関する報告も行われていない.そこで本テーマでは昨年度

高速トランスポートプロ

トコルを将来の高速インターネットで利用した場合の性能を調査することを目的として実験シナリオを設定して実験を実施している.高速インターネットへの適用を考えた場合, 以下の状況における性能を調査することが重要になると考える.
(1) 可用帯域幅や遅延の変動などネットワーク状況の変化に対する追従性,(2) 異種高速トランスポートプロトコル共存時の特性.
このような状況を考えて, 下記のようなシナリオにおける特性を調査した.
(a)既存トランスポートプロトコルフローの基本特性
1)シングルフロー確立時のスループット特性
2)様々な受信側ＯＳの端末に対してコネクションを確立した場合の特性(b)ネットワークの状況の変化に対する追随性
1)遅延の変動
2)帯域幅の変動(c) パス上に共存するフロー間の影響
1)RTT の異なるフローが共存した場合
2)異なる高速トランスポートプロトコルフローが共存した場合
3)Web トラヒックと高速トランスポートプロトコルフローが共存した場合
4)実時間トラヒックと高速トランスポートプロトコルフローが共存した場合
本報告書ではここで得られた実験結果の例（(a-1), (c-1),(c-3),(c-4)）を報告する.

3.4.1.2 実験環境
図 3.3.1.2.1 にネットワーク構成を示す. 実験は(a)ネットワークエミュレータを利用した場合, (b),(c) ネットワークエミュレータと JGNII 国内折り返しパスを利用した場合, (d)に JGNII 国際回線, を利用した構成で実施した. 送信側端末の OS として Linux(RedHat 9.0 Kernel 2.4.20)を利用した.これは 対象としたプロトコルの
うち, UDT 以外の実装が Linux kernel に対するパッチコードとして提供されているか
らである.また 受信側端末の OS も(受信側 OS の種類が性能に与える影響を調べる以165- 165 -

外)Linux を利用した.また 各プロトコル開発者のホームページで提供されている情報に従って,各種パラメータ（Linux txqueuelen, システムメモリ, NIC の持つパラメータやプロトコルが固有に持つパラメータ）の調整を実施した.性能指標としては ス
ループット特性を用い,UDT プロトコルは, UDT が提供するスループットモニタ機構を利用して, その他プロトコルは iperf を利用して観測される値を示す.

10Gbps
北九州
北九州

JGNII
(国内)

北九州
1Gbps

1Gbps

北九州

1Gbps
GS4000

1Gbps

GS4000

PacketStorm

GS4000GS4000(a) ネットワークエミュレータ
10Gbps

北九州

北九州

北九州

PacketStorm

Chicago(c) エミュレータとJGNII国内回線
1Gbps

1Gbps

GS4000

JGNII
(国内)

1Gbps

10Gbps

JGNII(国際)

GS4000

1Gbps

StarLight

GS4000

PacketStorm(d) JGNII国際回線(b) エミュレータとJGNII国内回線

図 3.4.1.2.1

実験構成図

3.4.1.3 実験結果
図 3.4.1.3.1 に, TCP のソケットバッファサイズを変化させた時(iperf の -w コマ
ンドで指定）のスループット特性を示す.(a)は FAST, (b)は BIC プロトコルを利用した場合の特性である.JGNII 国際回線利用時の RTT は 180[ms]であり, 図(d)に示す構成のボトルネック帯域幅 1[Gbps]に到達するために必要なソケットバッファサイズは22.5[Mbps](=bdp)となる.
(a)に示す FAST 利用時, ソケットバッファサイズとして bdp よりも小さい値を設定した場合,到達する最大スループット値に制限が見られるが, 最大値に到達した後は,安定した特性が得られることがわかる. ソケットバッファサイズを BDP 以上に設定した場合は, スループットの最大値は大きくなっているが, 最大値に到達した後,ス
ループットが低下し, その後 増加するということを繰り返している様子がわかる.BIC 以外の TCP ベースプロトコルでは, ソケットバッファサイズとスループット特性の関係において(a)と 同様の傾向が観測された.(b)に BIC を利用した場合の特性を示す. 本図より, BIC を利用した場合は, ソケットバッファサイズを変化させても,ス
ループット特性は変わらないことがわかり, プロトコルによってソケットバッファの大きさの影響は異なることがわかった.

166- 166 -

高速インターネットに限らず, ネットワーク上には 異なる RTT を持ったフローが混在する. そこで次に, 異なる RTT を持つフローが混在した状況で各プロトコルを利用した場合に見られるスループット特性を図 3.4.1.3.2 に示す.図 3.4.1.2.1(b)に示す構成で 2 本のフロー flow1(RTT=38[ms]), flow2 を設定し,flow1 と flow2 の RTT の比を 1:1, 1:2, 1:4 と設定した場合に見られる平均スループット値の割合を示す. 図
3.4.1.3.2 より,RTT 比が 1:1 の時は いずれのプロトコルを利用した場合もフロー間のスループット値に違いは見られないが, RTT 比 1:2 の場合は, FAST,BIC プロトコルの利用において, RTT 比が 1:4 の場合は, HSTCP,FAST, BIC プロトコルの利用において,フロー間のスループット値に RTT 比以上の大きな違いが見られることがわかる.
これに対して HTCP, UDT プロトコル利用時には RTT 比の違いがスループット特性に影響しないことがわかる.

高速トランスポートプロトコルフローのスループット特性

50
45
40
35
30
25
20
15
10
5
0
T
UD

CP
HT

BI
C

FA
ST

St
an
da
rd

HS
TC
P
Sc
ala
bl
e
TC
P

RTT比：１
RTT比：２
RTT比：４TC
P

Throughput の割合

図 3.4.1.3.1

図 3.4.1.3.2 異なる RTT を持つフローが共存した時のスループット特性
将来のインターネットにおいて, 高速トランスポートプロトコルを利用してデータ転送を行うユーザが増加した場合も, 既存の Standard TCP, UDP プロトコルを利用したデータトラヒックは残ることが考えられる. そこで次に高速トランスポートプロ

トコルフローが, 共存するバックグランドトラヒックに与える影響を示す.バックグ

167- 167 -

ランドトラヒックとしては(1) FTP に代表される long-lived Standard TCP フロー(2)Web トラヒックに代表される short-lived TCP フローと,(3)voip に代表されるリア
ルタイムアプリケーションである CBR トラヒックを対象とした.
(1) に 関 し て は す で に 多 く の 文 献 で 高 速 ト ラ ン ス ポ ー ト プ ロ ト コ ル フ ロ ー がlong-lived Standard TCP フローに対して与える影響が大きいことが報告されている.
本 実 験 環 境 に お い て も 図 3.4.1.3.3(a) に 示 す よ う に 同 様 の 傾 向 が 観 測 さ れた .Standard TCP フ ロ ー を 同 時 に 2 本 流 し た 時 の 各 フ ロ ー の ス ル ー プ ッ ト 値 は200[Mbps]であるが 高速トランスポートプロトコルフローと StandardTCP フローを 1本ずつ同時に設定した場合に観測される Standard TCP のスループットデータと比較す
ると, いずれの場合においても 200[Mbps]より低くなっており 高速トランスポート
プロトコルフローが Standard TCP フローのスループット特性に影響を与えることがわ
かる.本実験では Standard TCP に対する影響の大きさは UDT フローが最も大きく,次が HTCP の順という結果となった.

1.2
1

Throughput[Mbps]

(2)
(1)

0.8
bdp
0.7bdp

0.6
0.4
0.2

T

CP

UD

HT
th

wi
th

BI
C
th
wi

wi

TC
P

FA
ST

wi

th

wi
th

th
wi

Sc
al a
ble

on
ly

rd

TC
P

an
da

ed

St
th

wi

tli v
sh
or

(1
)S
ta
n

(a) long-lived TCP との共存時の特性

TC
P
HS
TC
P

0

da
rd
:(
(1
2)
)S
St
ta
an
nd
da
ar
(1
rd
d
)S
:
(
2)
ta
nd
HS
ar
TC
d
:(
P
(1
2)
)S
Sc
ta
ala
nd
bl
ar
e
d
:(
(1
2)
)S
F
ta
AS
nd
T
(1
ar
)S
d
:(
ta
2)
nd
BI
ar
C
d
:(
(1
2)
)S
HT
ta
nd
C
P
ar
d
:(
2)
UD
T

Throughput[Mbps]

1000
900
800
700
600
500
400
300
200
100
0

(b) short-lived TCP フローとの共存時の特性

図 3.4.1.3.3 Standard TCP フローとの共存時の特性
次に (2)の short-lived TCP フローに与える影響を示す.
実験では パレート分布に従って発生する平均長 500[KB]のファイルが, 300 秒間に3000 フローする発生する状況において, 高速トランスポートプロトコルが共存している状態で, ユーザから見た short-lived TCP フローの平均スループット[Mbps]を図3.4.1.3.3(b)に示す.本図より,いずれの 高速トランスポートプロトコルフローと共存した場合も short-lived TCP フローのスループット特性は低下することがわかる.
特に, UDT フロ-と共存した場合の short-lived TCP フローのスループットは 他のプ
ロトコルフローと共存した場合と比較して低くなっているが これは図 3.4.1.3.3(a)に示す long-lived Standard TCP と共存した場合の特性と同様に short-lived TCP と共存した場合も UDT フローで観測される平均スループットが他の高速トランスポー
トプロトコルと比較して高い(650[Mbps])ことが影響していると考える.
TCP ベースのプロトコルに関しては ソケットバッファサイズを BDP よりも小さくした場合(0.7bdp)の特性をあわせて示した.ソケットバッファサイズを BDP 値よりも小168- 168 -

さくすることで short-lived TCP フローのスループットが改善されていることがわかる.これは, 図 3.4.1.3.1(a)で見られたように,ソケットバッファサイズを小さくすることで, 高速トランスポートプロトコルフローのスループット特性の振る舞いを安定させることができ, このことが 共存するバックグランドトラヒックへの影響を抑えているものと考える.図 3.4.1.3.1(b)でソケットバッファの違いによって スルー
プット特性に違いが見られなかった BIC プロトコルを利用した場合は, ソケットバッ
ファの大きさの違いによって short-lived TCP フローのスループット特性に違いが見られないことがわかる.
次に,(3)高速トランスポートプロトコルフローが共存する CBR フローに与える影響を示す.ここでは, アプリケーションとして VoIP を考え, パケット長を 200[byte]に設定した２本の 3.2Mbps のフロー（64Kbps x 50 本に相当）が高速トランスポートプ
ロトコルフローと共存した時の 高速トランスポートプロトコルフローのスループッ
ト特性と, 各 UDP フローのジッタの変動を図に示す.TCP ベースのプロトコルを利用した場合, いずれにおいても同様の傾向が観測されることが確認されたため,

図

3.4.1.3.4 に BIC フローと共存した場合の特性を示す.((a)は UDP フローが先にスタートした場合, (b)は BIC フローが先にスタートした場合)
場合のジッタの平均値は 0.01[ms]であることから,

UDP フローのみが存在する

いずれのパターンにおいてもTCP ベースの高速トランスポートプロトコルとの共存は CBR フローのジッタ特性に大きな影響を及ぼすことがわかる.

(a) UDP フローが先にスタートした場合(b) BIC フローが先にスタートした場合

図 3.4.1.3.4 BIC フローと UDP フローの共存字の特性

3.4.1.4 イリノイ大学との共同研究
本章では JGNII 国際回線を通して実施しているイリノイ大学との国際連携活動を紹介する. JGNII 国際回線を通してイリノイ大学と実施している連携活動としては, 大きく２つがあげられる.１つめが前章で紹介した高速トランスポートプロトコルの伝送実験であり, 実験で イリノイ大学が管理している

169- 169 -

Teraflow テストベッドの端末を利用して伝送実験を実施している. 実験では主に, 東京に設置されているノードとStarLight 上に設置されているノードを利用している. 2 つめの活動としては

今年度

イリノイ大学と共同で, iGrid2005[3], SuperComputing 2005 にエントリーし, JGNII
国際回線を利用したデモを実施した.

SuperComputing2005 で デ モ を 実 施 し ,Bandwidth Challenge にエントリーした際のネットワーク構成を

図 3.4.1.4.1に示す.
(2) Telescope at Mt. hopkins(1) Telescope at New Mexico(4) 2Mass data

(3) SDSS data

SCP, FTP (not so fast)
storedstoredTokyo
Chicago

10Gbps

10Gbps

UDT

UDT

merge

SC|05 venue(5) Brown Dwarf

図 3.4.1.4.1 SC05 における JGNII 国際回線を利用したデモネットワーク構成
イリノイ大学との JGNII 国際回線を利用した共同実験は平成１８年度も引き続き継続する予定である.

3.4.1.5 まとめと今後の予定
本章では平成１７年度に

JGNII 国内回線, 国際回線を利用して実施した高速トラ

ンスポートプロトコルを対象とした伝送実験の結果とイリノイ大学と共同で実施している共同実験活動の内容を紹介した. 引き続き, 平成 1８年度は JGNII 国内回線,
国際回線を利用して以下の項目の実施を予定している.

・ ボトルネック帯域 1[Gbps]/10[Gbps]環境での高速トランスポートプロトコル伝送
実験 (1[Gbps]端末と 10[Gbps]端末が共存する状況)
・

イリノイ大学との

JGN2 国際回線を利用した共同実験の継続

3.4.2 中間ノードでの制御も組み入れた方式
本章では end-to-end だけの制御だけでなく, 中間ノードでの制御も組み入れた方式の例として実時間トラヒックの遅延特性を改善するために, 中間ノードで実施する

170- 170 -

優先パケット廃棄方式の性能をシミュレーションによって評価した内容を紹介す
る.[4][5]実時間アプリケーションの品質は, 廃棄特性だけでなく end-to-end の遅延特性に大きな影響を受ける. 実時間アプリケーションは 実時間という特性上, その品質を保持するために 許容できる遅延値がアプリケーションごとに規定されている.許容値を越えた 遅延を経験して 目的地に到着したパケットは アプリケーションによって廃棄される.すなわち, 網内で経験した遅延値が 許容遅延値を越えた時点でそのパケットはアプリケーションから見ると 有効なデータではない. さらに網内の他のフローからすると余分な負荷であると考えられる.そこで,この点に着目して 実時間トラ
ヒックの end-to-end の遅延値を改善することを目的として許容遅延値を越えて網内に存在するパケットを中間のルータで検出した場合, 優先的にそのパケットを廃棄する手法を適用した場合の特性を シミュレーションによって検証した内容を報告する
実時間アプリケーションの品質は, 通過するネットワークでの遅延特性に大きな影響を受ける. アプリケーションの中には許容できる遅延値が規定されているものもあり,
その場合, 許容値を越えた遅延を経験して目的地に到着したパケットは, アプリケー
ションの品質の向上に寄与しないだけでなく,他のパケットの遅延を増大させることによって, 品質の劣化の原因にもなる. そこで本稿では, 実時間アプリケーション
フローの遅延特性を改善することを目的として, アプリケーションフローにとって大きすぎる遅延を経験したパケットは, 中間ノードで適応的に廃棄する手法を提案する.
本手法の適用により, 実時間アプリケーションフローの遅延特性が改善することをシミュレーションによって示す.

3.4.2.1 MTQ/QTL 方式
voip に代表される実時間トラヒックの品質は, 廃棄特性だけでなく,網内で経験する遅延特性にも大きな影響を受ける.
このため 多くのアプリケーションでは, 許容遅延値が規定されており, また,遅延値を基準としてサービス品質のクラス分けが規定されているものもある.
網内で 許容されている遅延値以上の遅延を経験したパケットは, 受信側に無事に到着した場合でもアプリケーションによって廃棄される.すなわち, 網上でパケットの経験遅延値が許容遅延値を越えた時点で, そのパケットはアプリケーションにとって意味のないデータとなる.本稿では この点に着目し, 実時間アプリケーションの遅延特性を改善するために中間ノードに, パケットがノードで経験する遅延値にもとづ
い て 適 応 的 に パ ケ ッ ト の 廃 棄 を 行 う MTQ(Maximum to Queue)方 式 と QTL(Queue toLive)方式を適用することを提案する.
図 3.4.2.1.1 に,本稿で対象とする MTQ/QTL 方式の概要を示す. MTQ 方式では 実時
間アプリケーションパケットに対して 各ノードでの最大許容滞在時間を基準とした

171- 171 -

制御が, また QTL 方式では, 網内での最大許容滞在時間を基準とした制御が行われる.

(a) MTQ 方式(b) QTL 方式
図 3.4.2.1.1 MTQ/QTL 方式

MTQ/QTL 方式を, 実時間アプリケーションの遅延特性の改善を目的として適用した場合に期待する, ２つの効果を示す.
・

実時間アプリケーションの経験遅延値を, MTQ,QTL 値として各パケットに設定した値に制御することができる.

・

中間ノードで許容遅延条件に見合わないパケットが早期に廃棄されるため,網上の負荷が減少し, 網資源を共有しているその他のフローの遅延特性の改善に対する効果も期待できる.
パケットが, 網内で経験する遅延値には, リンクの固定遅延と中間ノード内で発生するキュー遅延がある.本方式では, 後者のキュー遅延を対象として制御を行う.また,中間ノードでは実時間フローは,TCP などの他の非実時間フローとは別のキューイン
グバッファで管理されるものとする.

3.4.2.2 シミュレーションモデル
本稿で対象としたネットワークモデルを図 3.4.2.2.1 に示す.
比較的長い固定遅延(=140[ms])を持ったパス上に, 実時間アプリケーションフロー
(3 種類の フローグループ 0, 1,２)が存在し,リンクを共有しているモデルを対象とす
る.各フローグループは 120 本の実時間アプリケーションフローから構成される.
エッジノードで各フローグループ内のパケットに対して MTQ, QTL 値の設定が行われ,各中間ノードで 設定値に基づいた制御が行われる.
実時間トラヒックフローとしては, ２種類のバースト性を持つトラヒックモデルを対象としてシミュレーションを実施した.
また, 10[ms], 20[ms], 30[ms]の許容遅延時間を持つアプリケーションを対象とし172- 172 -

ている.

図

3.4.2.2.1

シミュレーションモデル : 制御ノード 4 段

図 3.4.2.2.1 に お い て , 各 ノ ー ド の バ ッ フ ァ 長 (=200[packet]), パ ケ ッ ト 長(=200[byte])と出力リンク幅(=20[Mbps])から 1 ノードでのパケットの最大待ち時間
は 16[ms]と算出できる.このためパス上に他のフローとの競合点を 2 箇所持つ フローグループ 0 の最大累計バッファ内待ち時間は 32[ms], 競合点が 1 箇所であるフローグ
ループ１,2 の最大バッファ内待ち時間は 16[ms]となる.このことから, 許容遅延時間
特性が 10[ms]のアプリケーションは, 非常に厳しい条件を持つアプリケーション,
20[ms]は中間クラス, 30[ms]は緩やかな要求を持つアプリケーションを想定している.
性能指標としては, 実時間アプリケーションから見た実質的なパケット廃棄率 Plossを用いる. Ploss は２種類の廃棄率の和 Ploss = Ploss_of + Ploss_apl からなる.ここ で Ploss_of ： 網 内 の ノ ー ド の バ ッ フ ァ あ ふ れ に 起 因 す る パ ケ ッ ト 廃 棄 率 ,Ploss_apl : 目的地に到着したパケットの中でアプリケーションによって許容されない遅延時間を経験しているパケットの廃棄率である.
本構成を利用して, 中間ノードで, パケットがヘッダに持つ情報を参照して廃棄制御を行う, バッファ管理機能を追加した, ns-2 を用いてシミュレーションを実施した.

3.4.2.3

MTQ を適用した場合のパケット廃棄率特性

実時間トラヒックが経験する遅延値を改善する方法の 1 つとして, 中間ノードのバッファ長を短くする手法が考えられる.バッファ長を短くすると, バッファでのパケ
ット廃棄率は増加すると考えられるが, 遅延特性を改善できる可能性がある.そこで,この点を明らかにするために, 本章では各パケットに対してノードでの最大許容待ち
時間（すなわちバッファ長）を指定する MTQ 方式を利用した場合の特性を示す.

173- 173 -

図 3.4.2.3.1(a) に, 各パケットに設定する MTQ 値（=最大待ち時間すなわちバッファ長）を変化させた時に, バッファあふれによって生じるパケット廃棄率 Ploss_of）を示す.また, 図 3.4.2.3.1(b)に, 許容遅延時間を 10[ms]とした時の, アプリケーショ
ンから見た実質的なパケット廃棄率（Ploss）を示す.
各ノードのバッファ内最大待ち時間は 16[ms]であることから, 図 3.4.2.3.1(b)において MTQ=16[ms]の時の Ploss は, 制御を行っていない場合の特性を示す.
図 3.4.2.3.1(b)より MTQ を設定することで Ploss が大きく改善される領域があることがわかる.MTQ 値として小さな値を設定すると(＝バッファ長が短い状況),Ploss が高くなっているが これは, Ploss_of が高くなるためである.
また 逆に, MTQ 値を大きくした場合も, Ploss の上昇が見られる. これはバッファ内
待ち時間が増加し, Ploss_apl が増加するためである.
本稿で対象としたモデルは, 全フローのトラヒック要件が同一で,ノードにおける

フローの競合状況が既知であるため, 廃棄率特性を改善する MTQ 値を, 許容遅延時間から推定することが可能である.その値は フローグループ 0 に対して 5[ms], フローグループ 1,2 では 10[ms]である.

図 3.4.2.3.1(b)より, この値よりも大きい MTQ 値を利用すると, Ploss が急激に増加していることがわかる. これは, MTQ 値が許容遅延時間から推定できる値よりも大きくなると,パケットがバッファ内で経験する遅延

値が許容遅延時間よりも大きくなり, 結果的に Ploss_apl が増加するためである.

(a) バッファで観測されるパケット廃棄率
図 3.4.2.3.1(b) 実質的なパケット廃棄率

パケット廃棄率（許容遅延値

10[ms]）

以上のことから, MTQ を設定する(= バッファ長を変更する)ことにより, 実時間ト
ラヒックの遅延特性を改善する効果を持つことがわかった.MTQ は バッファ長を再設定する場合と比較して, ユーザ側,アプリケーション側から見たバッファ長を個別に設定できる手段であるため, 柔軟性が高い手法であると言える.
今回 対象としたモデルのように, 各フローのトラヒック要件が同一でフローの競174- 174 -

合状況が既知である場合, Ploss を改善する MTQ 値を推定することは容易であり, 推
定した MTQ を設定することによって パケット廃棄率特性を改善する効果が見られる.
しかし 一般に, 網上の全フローのトラヒック要件, 各ノードの競合条件を把握する
ことは容易ではないため, Ploss を改善する MTQ 値を推定することは困難である.

3.4.2.4 QTL 制御機能を利用した場合のパケット廃棄率特性
本章では 各パケットに QTL 値を設定した時の, パケット廃棄率特性を示す. 各パケットのバッファ内での累計待ち時間が, パケットのヘッダーに付与されている QTL
値を超えることが検出された時点で, そのパケットは中間ノードで廃棄される.
図 3.4.2.4.1(a)に, 許容遅延時間を 10[ms]とした時の, 各パケットに設定する QTL
値を 変化させた時のパケット廃棄率特性を示す.

(a) QTL を設定した場合のパケット廃棄率(b) MTQ+QTL を設定した場合のパケット廃棄率

図 3.4.2.4.1 パケット廃棄率（許容遅延値 : 10[ms])図 3.4.2.4.1 より, 各パケットヘッダーに設定する QTL 値を許容遅延値（=10[ms])とすることで, パケット廃棄率が最も大きく改善していることがわかる.QTL 値として許容遅延時間よりも大きな値を設定した場合, 急激に Ploss が劣化しているがこれは, 累計遅延時間が, 許容遅延時間を越えたパケットが増加 して, Ploss_apl が高くなったためである.取得した他のシミュレーションデータから,最適な QTL 値に関しては, トラヒックのバースト性, 許容遅延時間の大きさの影響を受けることはなく,いずれにおいても同様の傾向(最適な QTL 値が許容遅延時間である)が観測された.
以上のことから QTL を利用する場合は, 許容遅延時間を QTL 値として設定することが有効であるということがわかる.

3.4.2.5 QTL と MTQ を同時に設定した場合のパケット廃棄率特性
本章では, MTQ と QTL を同時に設定した場合の特性を示す.この時, 制御ノードにパ175- 175 -

ケットが到着した際, 各パケットがヘッダーに持つ MTQ/QTL 値が参照され, 少なくとも一方の条件を満たしていないパケットはノードで優先的に廃棄される.図3.4.2.4.1(b)に, QTL 値として 10[ms]を設定し,MTQ 値を 0[ms]からバッファの最大待ち時間(=16[ms])まで変化させた時の特性を示す.
図 3.4.2.4.1(b)で, MTQ 値をバッファの最大待ち時間(=16[ms])と設定した場合は,QTL 値のみを設定した場合の特性を示す.この QTL 値のみを設定した場合(MTQ=16[ms])と, QTL と MTQ 値をあわせて設定した場合（MTQ＜16[ms])のパケット廃棄率を比較す
ると, MTQ を 1.6～10[ms]と設定した時に, QTL のみを設定した時よりも Ploss が改善されており, QTL と MTQ を同時に設定する効果が見られる.
MTQ 値が 10[ms]を超えると, フローグループ 0 のパケット廃棄率が増加し,その後は一定の値となっているが これは次の理由による.

本モデルで MTQ 値として 10[ms]よりも大きな値を設定すると, １つのバッファ内での最大待ち時間が許容遅延時間(=10[ms])を越える場合が生じる.この場合, QTL の設定値（=10[ms])の制限から, バ
ッファ内待ち時間が 10[ms]を越えた時点で, 常にパケットが廃棄されてしまうため,
MTQ の値に関わらず, 廃棄率は一定となる.
また 図 3.4.2.4.1(b)を, 図 3.4.2.3.1(b)に示した MTQ だけを設定した場合の特性と比 較す る と, MTQ の みを 設定 し た場 合は,MTQ 値 が適 した 値よ り も大 きく な ると
Ploss_apl が高くなり, それに伴い Ploss も高くなるが, 図 3.4.2.4.1(b)に示すように, QTL をあわせて設定することで,許容遅延時間から推定される値よりも大きなMTQ を設定している場合でも, Ploss の増加を抑えられることがわかる.また QTL とあわせて設定する MTQ 値が小さいと, 図で観測されたように Ploss_of が増加し, 結果的に Ploss も増加する.
以上の結果から, QTL と MTQ を同時に設定することで, MTQ のみ また, QTL のみを設定した場合よりも 廃棄率特性が改善される MTQ の設定値があることがわかった.
このことから 例えば 許容遅延時間から MTQ 値を推定するのが困難な場合に,MTQ 値を
バッファ長の X％, または許容キュー遅延の Y％に設定し, あわせて QTL(=許容遅延時間)を設定するという利用法が有効であると考えられる.

3.4.2.6 MTQ/QTL/MTQ+QTL の適用によって見られる廃棄率特性の比較
本章では, MTQ/QTL/MTQ+QTL を適用した場合の, バッファ内待ち時間分布とパケッ
ト廃棄率特性の比較を行う.
図 3.4.2.6.1(a)に, バースト性の低いトラヒックを収容し, 許容遅延時間を 10[ms]として, 次のような MTQ/QTL 値を設定した時のフローグループ 0 に属するパケットの,end-to-end 遅延分布(累計バッファ内待ち時間分布)を示す（(1)：制御なし,(2)：最適な MTQ の設定,

(3)：最適な QTL のみの設定,(4)：最適な MTQ＋QTL の組み合わせ, (5) : QTL と長めの MTQ の組み合わせ）.

176- 176 -

図 3.4.2.6.1(a) より, QTL, MTQ を設定することによって, 遅延分布の最大値が許容バッファ内待ち時間(=10[ms])となっていることがわかる.また 許容遅延時間から推定される MTQ((2))を利用した場合と, その MTQ 値と QTL 値を同時に設定した場合((4))は,同様の分布を示しており,

許容遅延時間から推定される MTQ 値を利用する効果が大きいことがわかる.推定値よりも大きい MTQ を利用した場合((5))も, QTLを同時に設定することで遅延分布の最大値を許容遅延値に抑えることができ, さらに遅延特性は QTL のみを設定した場合((3))よりも改善していることがわかる.

(1)制御なし(3)QTL(2)MTQ1(a) 遅延時間分布
図 3.4.2.6.1(4)QTL+MTQ1(5)QTL+MTQ2(b) パケット廃棄率
MTQ / QTL / MTQ + QTL の比較

また, 図 3.4.2.6.1(b)に, MTQ,QTL の設定を行った時のパケット廃棄率を示す.図より,制御を行わない場合と比較して((1)), MTQ,QTL を設定することによって((2)～(5)),
パケット廃棄率特性が大きく改善していることがわかる.特に MTQ として利用する値
を, 許容遅延時間から推定できる場合は((2)), その値を MTQ として利用することの効果が大きいことがわかる.
MTQ として利用する値が推定できない場合も,（(5)),QTL と MTQ を両方設定することで

QTL のみを設定した場合((3))の特性と比較して, 各フローで観測されるパケット廃棄率のバランスが (2)の特性に近付いており, MTQ と QTL を同時に設定することで QTL のみを利用する場合よりも, より安定した特性を得られることがわかる.
本章では 許容遅延時間が 10[ms]の場合の結果を示した.この結果を,その他の許容
遅 延 時 間 (20[ms], 30[ms])を 対 象 と し た 結 果 と 比 較 す る と ,遅 延 条 件 が 厳 し い 場 合(=10[ms])に MTQ,QTL を設定する効果が大きいこと,特に, QTL を単独で設定した時よりも, QTL と MTQ をあわせて設定した場合の改善率が, 他の許容遅延値の場合に観測される割合よりも大きい, という傾向が観測された.

177- 177 -

3.4.2.7 まとめ
本稿では, 実時間トラヒックの遅延特性の改善を目的として,中間ノードに, 適応的早期パケット廃棄手法(MTQ,QTL)を適用した時の基本特性を, シミュレーションに
よって検証した.
その結果,
・

MTQ を設定して,ノードでの最大待ち時間を制限することで(実質的にバッファサ
イズを制限することで), 実時間トラヒックの遅延特性を改善できることを示した.特に許容遅延時間から,適切な MTQ 値を推定できる場合は, その値を MTQ として設定することで, 遅延特性を最適な状況に改善することができる.
しかし 一般的に, 最適な MTQ 値を推定することは多くの場合困難であり,ある
適切な範囲より大きいまたは小さい値を設定した場合, 遅延特性, 廃棄率特性は悪化する傾向が見られた.

・ノードで経験する遅延の総計を規定する QTL を適用することにより, パケット廃棄率特性を改善できることを示した.
各フローにとってそのフローの廃棄率特性を最も改善する最適な QTL 値は許容遅延時間である.

・ 最適な MTQ 値が不明な場合は, 許容遅延値をホップ数で割ったもの以上, かつ 許容遅延未満の, ある MTQ 値(例えば許容遅延時間の半分)を設定し,あわせて QTL を
許容遅延値に設定することで, 各フローのパケット廃棄率特性を改善できることを示した.

3.4.3. まとめと今後の課題
本テーマでは 今年度 JGNII を利用した高速トランスポートプロトコルを対象として実施した伝送実験の結果と,実時間アプリケーションの遅延特性を改善するために中間ノードでの制御を組み入れる提案方式の性能評価の結果を示した. 今後の課題
としては,JGNII 上での伝送実験では 1[Gbps]と 10[Gbps]の端末が混在した状況における伝送実験の実施と ルータ支援を組み入れた方式では, ノードの段数を増加させ,
より実ネットワーク環境に近い状況での評価を実施する予定である.

参考文献[1]“JGNII を利用した高速トランスポートプロトコルの評価 ,”熊副
神山

勝司, 堀

報告,IN2005-67，

良彰, 鶴

正人, 尾家和美,

祐二, 電子情報通信学会 技術研究

pp.37-42, 仙台市, 2005 年 9 月[2] “Can high-speed transport protocols be deployed on the Internet? :178- 178 -

Evaluation through experiments on JGNII”, 熊副
堀
[3]

良彰, 鶴

“ Data正人, 尾家和美, 神山勝司,

祐二, PFLDnet 06, Nara, Japan, Feb 2006

Mining Middleware for Wide Area High Performance Networks,”

Robert L. Grossman, Yunhong Gu, David Hanley, and Michal Sabala, Joe
Mambretti, Alex Szalay, Ani Thakar, Kazumi Kumazoe, Yuji Oie, Minsun
Lee, Yoonjoo Kwon, and Woojin Seok,

to appear in the Journal of Grid

Computing : Theory, Methods and Applications , Future Generation
Computer System (FGCS) ’06 , Elsevier[4]“ルータ支援機構を利用した実時間トラヒックの End-to-End 遅延特性改善方式の提案,”電子情報通信学会 技術研究報告，熊副和美, 鶴正人, 尾家祐二,
IN2005-46，pp.103-108，北海道，2005 年 7 月[5]“Improving Delay Characteristics of Real-Time Flows by Adaptive Early
Packet Discarding,” Kazumi Kumazoe, Masato Tsuru, Yuji Oie, ICOIN2006,
Sendai, Japan, Jan 2006179
- 179 -

- 180 -第４章
拠点連携型資源共有技術に関する研究開発

第4章

拠点連携型資源共有技術に関する研究開発

4.1 概要
近年、Grid や Web サービス等の分散コンピューティングに代表される、複数の組織が計算資源（CPU やストレージ）やサービスを出し合ってひとつの計算サービスを提供する技術の研究開発がさかんに行われている。すなわち、1 箇所に資源やサービスを集中させることなく、広域ネットワークを活用することにより、広域分散環境の構築やその利用が可能となる。
このような環境においては、多数の組織に属し、地理的にも分散した提供者やユーザがひとつの環境においてさまざまな資源を共有するため、資源の管理は非常に重要な問題である。特に、ひとつの環境に対する新たな資源の追加や削除、資源に対するアクセス制御やユーザに対する資源の分配方法など、数多くの研究課題が残されている。
本研究サブテーマでは、インターネットなど、一般のユーザがアクセス可能な広域
ネットワークを介して接続されている環境を想定し、その上での複数の拠点（組織）の資源管理の問題についてセキュリティと資源の割り当て（スケジューリング）の 2
つの側面について研究開発を実施している。
4.1.1 研究開発の必要性(1) 多数の資源提供者によって構成される大規模分散環境における資源管理問題
複数の組織によって計算資源（CPU やストレージ）が提供されて構成された環境では、全ての資源の管理を一元化して実施することは困難になる。特に、関係者が増えれば増えるほど資源の追加、削除、移動などが発生し、少数の管理者による手作業の管理は破綻する。現在の技術では資源の追加、削除などは管理者の手作業が必要であり、これは非常に大きな問題である。そのため、ユーザが自分の権限で資源の追加や削除が実施でき、自分で追加した資源を関係者以外に非公開にできるようなセキュリ
ティ（アクセスコントロール）の手段の研究開発を行っている。
(2) ネットワーク品質の計算性能への影響
広域な分散処理にかかわる広域ネットワークの品質もまた問題となる。図 4.1.1に示すような広域ネットワークを経由して大量のデータを処理する分散計算では、デー
タサイズの規模拡大に伴い、拠点間ネットワークの性能が計算性能に影響を及ぼす。
この問題に対し、現状ではダークファイバを専用に準備するなど、広帯域なネットワー
クを用意する方向で解決を図る場合が多い。しかし、広域、広帯域専用ネットワークを準備する方法はコストが非常に問題となる。ISP 等の通常のネットワークも広帯域化が進んでおり、帯域保証型のサービスも行われ始めている。このようなネットワー
180- 181 -

クで計算品質を確保できれば分散コンピューティングを広く普及させることが可能と考えられる。
帯域に十分に余裕のない状況でデータ転送の品質を確保するには、フロー単位で帯域を割り当て、各データ転送が必要とする帯域をネットワーク側で保証する必要がある。分散計算では、ある計算に必要な帯域の要求が満たされない場合、ネットワークの帯域や計算資源に余裕のある別の場所に計算を再割付けする等の処理が発生する。
そのため、同一ネットワーク帯域でより多くの帯域要求（データ転送）を処理できれば、システム全体の利用効率を向上させられる可能性がある。これに着目し、システ
ム全体の利用効率向上のため、分散計算の特質に着目してユーザの帯域要求をなるべく損失させないような品質制御技術とデータ転送プロトコルについて研究開発を実施
している。

拠点A
観測装置等

測定データ
逐次送信

拠点B
大規模クラスタ

拠点C
並列計算機

拠点D
ユーザ利用PC

並列画像処理(オリジナルソフト) 3次元画像合成(商用アプリ利用)

結果の表示と保存

図 4.1.1 : 広域網を使った計算サービスの例
4.1.2 拠点連携のためのセキュアな資源共有技術の研究開発
我々の周囲にすでに存在する様々なセンサを用いた計測システムは閉じたシステム
であり、取得したセンサ情報はシステム内の特定の目的のためだけに利用されることが一般的であった。近年、これらのセンサ情報を広域ネットワークを介して共有、有効利用するためのシステム化技術の研究開発が要求されている。これらのセンサ情報に対して遠隔地からのリアルタイムアクセスが実現されることにより、ネットワーク
上のセンシングノードが収集したデータを、用途に応じて高速かつ効率的に加工することができる。このことは、すなわちこれまでの計測システムでは得られなかった新しい知見や事象に対する認識発見のプロセスの効率化を意味する。
広域ネットワークを介してセンシングデバイス、計算システム等の多様な計算資源を動的に接続するための技術としてグリッドが注目されている。しかし、現在のグリッド技術は、計算能力をダイナミックに集約・利用することを主な目的として発展してきたため、アクセス制御や資源管理のための実装技術が不足している。そのため、ネットワークを介した安全かつ動的な計測システムをグリッド技術によって構築することが困難であった。

181- 182 -

本研究では、センシングデバイスを資源としてグリッド環境に収容し、広域ネット
ワーク上で安全に共有し活用できるようにするためのグリッドアーキテクチャを提案する。本提案方式は、アプリケーションの実装に依存しない認証システムと認可シス
テムとの連携により、総合的で細密なアクセス制御を特徴とするため、ユーザやシス
テム運用者に対して高度なネットワーク技術を要求することなく、多拠点間で資源を柔軟に共有することが可能となる。
4.1.3 広域ネットワークにおける大規模データ処理連携技術の研究開発
ここでは、広域ネットワークにおける大規模データ処理連携技術の研究開発について概略を簡単に報告する。巨大なデータを複数の拠点（サイト）に存在する計算資源（CPU やストレージ）間で相互に転送しながら処理するようなアプリケーションでは、データの転送性能がアプリケーションの性能に大きく影響する。特に、観測装置から出力されるデータをリアルタイムで計算処理する場合は、データ発生源の速度以上の性能で計算を実施する必要がある。このような処理では、各処理に時間的な制約が存在するため、データ転送の品質を広域ネットワークにおいて保証することが非常に重要である。
拠点間のデータ転送の品質を確保するためには、十分に広帯域なネットワークを利用するか、個別の通信に必要なネットワーク資源を動的に割り当てるかのどちらかの対応が必要である。しかしながら、広域ネットワークにおいて事前に十分な帯域を確保しておくことは非常にコストが高く、多くの場合実現するのは困難である。
一般に、多くの組織(拠点)では計算資源は組織のネットワーク内部や通信事業者のホスティングサービス拠点に設置していると考えられる。このような状況では、外部との通信回線は他のユーザと共有することになるため、外部向けリンクの帯域全てを利用できるわけではない。このようなネットワーク環境で計算資源の利用効率を上げるためには利用可能な帯域を有効に利用し、同一帯域でより多くのデータ転送に対して性能保証できれば良い。これを実現するために、動的に QoS 設定を調整することで全体の必要帯域を圧縮する制御技術と、データ転送プロトコルの研究開発を実施している。
実際の利用帯域
契約以上に利用した帯域

他のフロー発生により利用可能帯域減少
必要帯域を再計算し帯域一部返却

当初契約
帯域

見直し後
契約帯域

再見直し後
契約帯域

図 4.1.2 : 動的 QoS 制御方式によるフローの帯域利用イメージ
182- 183 -

動的 QoS 制御方式では図 4.1.2に示すように、各フローが当初の予定帯域以上のス
ループットが得られた場合に確保済みの帯域を返却していくことで、空き帯域を作り出し、フローが予約している帯域の合計を削減する。今年度は、昨年度から継続している定量評価の結果をまとめて国際学会において発表すると共に、実証実験に向けてプロトタイプシステムの開発を実施した。
また、データ転送プロトコルの研究では、JGN2 クラスの広域ネットワークと既存ア
プリケーションを対象に、TCP をベースにしたデータ転送プロトコルと、長期的な課題として、UDP を利用した高速データ転送プロトコルの 2 つについて研究開発を実施した。
TCP ベースのプロトコルは 2 つの TCP コネクションを利用することで、輻輳時の性
能保証と非輻輳時の帯域有効利用を実現する方式(図 4.1.3)を提案し、計算機シミュ
レーションにより性能を評価した。
また、UDP を利用した高速転送プロトコルの研究では既存高速プロトコルの問題点
である、多数のフロー混在時の多量のパケット発生による輻輳の発生を抑制する帯域推定方式と、輻輳を早期に発見し、連続したパケット損失を抑制するルータにおけるキュー管理方式を提案し、定量評価を実施した。

制御なし・通常のTCP動作

空き帯域の利用
帯域予約無し

追加フロー
基本フロー

安定した性能最大ウィンドウサイズの制限
送信レート ＜ 契約帯域
帯域契約あり図 4.1.3: TCP ベースプロトコルの特性

183- 184 -

4.2 拠点連携のためのセキュアな資源共有技術の研究開発
複数の組織によって計算資源 (CPU やストレージ) が提供されて構成された環境では全ての資源を一元化して管理することは困難になる。特に、その環境にアクセスするユーザの増加は、資源の追加、削除、移動などの多発につながり、少数の管理者による手作業の管理は多大なものになる。現在の技術では資源の追加、削除などは管理者の手作業が必要であり、これが複数組織でのグリッド環境構築の大きな障害、すな
わちグリッド技術のスケーラビリティを妨げる要因となっている。そのため、ユーザが自分の権限で資源の追加や削除が実施でき、自分で追加した資源を必要に応じて関係者以外に非公開にできるようなセキュリティ (アクセスコントロール） の手段の研究開発は、グリッドコンピューティングの普及に大きな意義がある。
本研究項目では、今後ますますその必要性と重要性が高まる傾向にあるセンサネッ
トワーク、グリッドのための技術に着目している。具体的には、カメラ、温度計、湿度といったリアルタイムモニタリングを特徴とするセンシングデバイスを、大 規模
データ処理を目的としたグリッドに統合し、グリッド上の各種サービスを活用することにより、多様なデータ処理が容易に実現できるような資源共有技術の開発を行っている。すなわち、多様なセンシングデバイスを安全にネットワーク上で共有可能にする技術の実現である。より具体的には、(1) 動的ファイアウォール設定機構、(2) 分
散センシングデバイスのためのデータ管理メカニズム、(3) 資源情報通知サービス、と本項目をさらに細分化して研究開発を推進する。各項目の目的は、次のとおりである。
(1) 動的ファイアウォール設定機構：
多拠点で共有される個々のセンシングデバイスについて、管理者の人手によるネットワークセキュリティの対応が必要である。適切な資源アクセスの設定を維持しつつセンシングデバイスをネットワークに追加、削除するための管理コストは大きく、タ
イムリーな機器の利用が困難である [3]。本機構は、ファイアウォールの動的な設定変更を達成するための手段を提供する。
(2) 分散センシングデバイスのためのデータ管理メカニズム：
センシングデバイスは搭載メモリ等のハードウェア制約からグリッドミドルウェア
を自身で動作させることが困難あるいは不可能であることが一般的である。このため、ユーザのシングルサインオンによる認証や権限委譲の機能とセンシングデバイスを連携させる場合、認証、権限委譲の機能を実現するシステムを外部に構成する必要がある。本項目では、これを実現するための方式を提案し、センシングデバイスの安全な接続や隔離のための手法の確立を目指す。

184- 185 -

図 4.2.1 センシングデバイス収容広域計算ネットワーク(3) 資源情報通知サービス：
センシングデバイスはオンデマンドで接続されることが多いが、接続されたデバイスに関する情報を遠隔の利用者にタイムリーに提供することは現在の技術では困難であるという事実がある。本項目では、どのセンシングデバイスがどの時点で利用可能であるのかを、利用者が一元的に容易に知るための手段を提供する。
これらの実現により、従来は環境構築の複雑さゆえ困難であった各種資源を活用したデータ処理が容易に実現でき、各種研究開発や実業務への幅広い適用が期待できる。
これまでに、サブ項目 (1) の動的ファイアウォール設定、および、サブ項目 (2) の分散センシングデバイスのためのデータ管理メカニズムに関する方式の提案とプロト
タイプシステムの構築を実施しており、さらなる改良を目指し研究開発を進めている。
本年度実施したサブ項目 (2) の分散センシングデバイスのためのデータ管理メカニ
ズムについて、研究開発の内容を以下に報告する。
4.2.1 従来技術
我々の周囲にすでに存在する様々なセンサを用いた計測システムは閉じたシステ
ムであり、取得したセンサ情報はシステム内の特定の目的のためだけに利用されるものであった。近年、これらのセンサ情報を広域ネットワークを介して共有、有効利用するためのシステム化技術の研究開発が要求されている。遠隔地からのリアルタイム
なアクセスが可能になるとネットワーク上のセンシングノードが収集したデータを、多様な用途に応じて加工することが可能になるため、これまでの計測システムでは得られなかった新しい知見や事象に対する認識発見の効率化につながる可能性が ある[8]。
しかし、上述のようなセンシングデータの共有環境を構築するには、取り扱われる
185- 186 -

データ自身のセキュリティ確保が非常に重要となる。セキュアに拠点間を接続するための既存技術の一例として、VPN を構築した上で資源共有を行う方法がある。しかし、VPN の構築はネットワーク層での設定を必要とするために、ネットワークの高度な技
術と知識を必要とする場合があり、センシングデバイスを実際に利用するユーザとなる当該分野の研究者や技術者では非常に困難である。また、多数の拠点間を連携する
際には、その設定作業が煩雑かつ膨大になり、柔軟性・拡張性に欠ける。このようなことを鑑み、ユーザやシステムの運用者に対して高度なネットワーク技術を要求することなく、柔軟に多拠点間で資源を共有するための環境を構築できるようにするためには、アプリケーション層による問題の解決が必要であると考える。
広域ネットワークを介してセンシングデバイスと計算システムとをダイナミックに接続するための技術としてグリッド技術が注目されている。しかし、現在のグリッド技術は、計算能力をダイナミックに有効活用することを主たる目的として発展してきたため、センシングデバイスに対するアクセス制御や資源管理のための実装技術が不足している。そのため、ネットワークを介したダイナミックな計測システムの構築が困難であった。また、図 4.2.2 左に示すように、テレサイエンスの分野では大型・高価な観測装置を共同利用するための技術開発が行われてきた。すなわち、１拠点で生成されたデータを複数の拠点に配布し、処理するための技術である。一方、図 4.2.2
右に示すような分散するデータソースを、組み合わせ統計処理等を行うことでより有益な情報へと加工するための技術は不足している。本研究では、広域に分散して配置された複数のセンシングデバイスを資源としてグリッド環境に収容し、広域ネ ット
ワーク上で安全に共有し活用できるようにするためのグリッドアーキテクチャを検討した。

図 4.2.2 大型観測装置における共同利用の形態 (左)、分散したセンシングデバイスの利用形態 (右)186- 187 -

4.2.2 提案方式
複数のセンシングデバイスを資源としてグリッド環境に収容することを考慮し、集中型のデータ管理を行うためのメカニズムを提案する。データの取得から加工、表示
までのデータ管理をグリッドミドルウェア層で行う。(1) デバイス層からのデータの抽出を管理するセンシングデバイスのためのグリッド接続方式、(2) ユーザのセキュ
リティ要件をシステムに反映するための細粒度アクセス制御機構、(3) 大規模なデー
タを表示するための高精細表示システムの３側面からの研究開発が必要であると考える。以下、それぞれについて記す。

図 4.2.3 集中型データ管理による分散センシングデバイスの利用形態 (左)分散センシングデバイスのためのデータ管理メカニズム (右)(1) センシングデバイスのためのグリッド接続方式
センシングデバイスはそのハードウェアの制約からグリッドミドルウェアを自身で動作させることが不可能であることが多く、そのためにユーザのシングルサインオンによる認証や権限の委譲を代替で行う機能を外部に別途構築する必要がある。したがって、センシングデバイスからのデータを取り込むためのグリッドノードを用意する。それぞれのセンシングデバイスの種類に応じた手段を用いてデータをグリ ッド
ノードに集めることで、データをグリッドミドルウェア上で取り扱えるようになる。
カメラからの映像データを拠点間で転送する場合、現在のグリッド技術におけるデータ転送の能力では目的のフレームレート、もしくは、ビットレートを確保することが困難である。つまり、GridFTP [11] はファイルベースであり、また、SOAP メッ
セージへのデータのインクルードはノードに負荷がかかるために必要な性能が得られない。したがって、グリッド層ではグリッドサービスによるアプリケーションの起動、および、終了の制御のみとし、データの転送はアプリケーション間で直接的に行うこととする。これにより、センシングデバイスによって生成されるデータに対して、ネッ
トワーク上の計算資源との連携によるリアルタイムなデータ処理が可能となる。

187- 188 -

センシングデバイスのためのグリッド接続方式を適用したシステムのモデルを図4.2.4 に示す。C はユーザクライアントを、D は表示システムを、P はポータルサー
バを、I はインデクシングサーバを、S はセンシングノードを、V はコンピューティ
ングノードを示す。C は必要に応じて P に接続し、P 上でログイン処理を経た後、I により自分のアクセスできるセンシングデバイスと処理サービスのリストを得る。ユー
ザが目的のセンシングデバイスと処理サービスを選択すると、P は S、または、V 上のサービスを実行し、結果を D に表示する。
動作例について述べる。処理サービスとしてデータ配送サービスを選択した場合、
P は S 上のデータ配送サービスを実行し、センシングデバイスから取得したデータをD に表示する。また、処理サービスとして計算サービスを選択した場合、P は V 上の計算サービスを実行し、S から得られたデータを用いた計算処理結果を D に表示する。

図 4.2.4 センシングデバイスのためのグリッド接続方式

188- 189 -

(2) 細粒度アクセス制御
様々な資源を連携して一連の処理を実行する場合、ユーザサイドにはできるだけセ
キュリティについて気にせずアプリケーションを利用したいという要求がある。一方、管理者サイドには個々のアプリケーションに対してきめ細かいセキュリティポリシの適用、および、共有されるデータに対する詳細なアクセスレベルの設定の要求がある。
これらの相反する要求が、シングルサインオンによる認証、委譲システムの実現を困難にしている。アプリケーションの実装に依存しない、電子証明書ベースの認証、認可システムを実現するため、公開鍵基盤である Public Key Infrastructure (PKI)、
権限管理のための Privilege Management Infrastructure (PMI)、ユーザや管理者の役割に対して制御を行う Role Based Access Control (RBAC) を利用する。PKI、PMI、RBAC をグリッド環境に構築されたアプリケーションに適用し、連携して動作させることで、管理者の人員削減、管理業務のためのコスト削減、および、総合的なセキュリ
ティポリシの適用が期待でき、かつ、細密なアクセス制御を簡単に安全にシス テマ
ティックに実現できるようになる。
(3) 高精細表示システム
広域ネットワークを介して接続された観測装置を複数用いる大規模アプリケー
ションの実行には、大きなサイズの可視化情報の閲覧や数多くの情報への同時アクセスを伴うことがある。ユーザによる効率的なアプリケーションの利用を可能にするためには、複数のデータソースから直接ネットワークを通してデータを広範囲に高精細に表示するための装置が不可欠である。複数のディスプレイを縦横に配置することで、観測データや可視化データのための広大な表示可能領域を確保できる。

図 4.2.5 細粒度アクセス制御の適用例 (左)、高精細表示システム (右)189- 190 -

4.2.3 実装
センシングデバイスによって生成されるデータをグリッド環境で利用するための方式を検証することを目的として広域ネットワーク上に観測システムを構築した。観
測システムは、ネットワークカメラを用いた静止画像取得システム、および、USB カ
メラを用いた動画像取得システムの２種類を実装した。それぞれの実装について、以下に詳細を説明する。
4.2.3.1 静止画像取得システム
センシングデバイスによって生成されるデータをグリッドミドルウェア上で取り扱うための方式を検証することを目的としてシステムを構築した。カメラデバイスとしてモーション検知機能を有するネットワークカメラを採用することで、常に最新の画像をユーザに提供できるようにした。本システムの主な構成要素は、(1) Web クラ
イアント、(2) ポータルサーバ、(3) センシングノードの３つである。
(1) Web クライアント：
グリッド資源を利用するためのユーザインタフェースである。多様なユーザクライ
アント環境とインターネットでの利用を考慮して、アーキテクチャ中立である Web
ベースのシステムとし、HTTP プロトコル上でデータを扱うこととした。入力情報は、
GET パラメータ (もしくは Web フォームからの POST パラメータ) として転送され、出力情報は、タグ等のフォーマット情報とともに HTML ページの中に埋め込まれる。

図 4.2.6 静止画像取得システム

190- 191 -

(2) ポータルサーバ：
ユーザがネットワーク上の資源を利用する際の入り口であり、拠点として必ず利用するサイトである。動的に変化する HTML コンテンツの生成と他拠点にあるグリッド
資源へのアクセスを実現するため、サーブレットコンテナ (Tomcat [12]) とグリッド
技術 (Globus) を用いた。ポータルサーバとセンシングノードとの間で GridFTP プロ
トコルによるファイル転送を実現し、センシングノード上の画像ファイルを取得できるようにした。サーブレットコンテナ上への GridFTP クライアント機能の実装にはCommodity Grid Kits (CoG) [13, 14] を用いた。
(3) センシングノード：
ネットワークカメラを専用ネットワークで接続したグリッドノードであり、カメラからの画像を他の拠点に転送する。センシングノードの構築には、モーション検知機
能付きネットワークカメラ、FTP サーバ (ProFTPD [15])、GridFTP サーバを用いた。
ネットワークカメラのモーション検知機能により、撮影領域に物体の動きが表れた瞬間の画像が自動で FTP サーバにアップロードされる。GridFTP サーバは FTP サーバに保存された画像ファイルにアクセスすることで、常に最新の画像をグリッド 上のユーザに提供することができる。

図 4.2.7 グリッドミドルウェアにより獲得したカメラからの静止画像

191- 192 -

4.2.3.2 動画像取得システム
センシングデバイスによって生成されるデータに対して、計算資源との連携によるデータ処理を達成するための方式を検証することを目的としてシステムを構築した。
カメラデバイスとして USB カメラを採用し、グリッドミドルウェアを搭載するマシン
上で直接に動画を取り扱えるようにした。本システムの主な構成要素は、(1) Web ク
ライアント、(2) ポータルサーバ、(3) インデクシングサーバ、(4) センシングノー
ド、(5) コンピューティングノードの５つである。
(1) Web クライアント：
グリッド資源を利用するためのユーザインタフェースである。多様なユーザクライ
アント環境とインターネットでの利用を考慮して、アーキテクチャ中立である Web
ベースのシステムとし、HTTP プロトコル上でデータを扱うこととした。入力情報は、
GET パラメータ (もしくは Web フォームからの POST パラメータ) として転送され、出力情報は、タグ等のフォーマット情報とともに HTML ページの中に埋め込まれる。
なお、動画の表示には Windows Media Player を採用した。

図 4.2.8 動画像取得システム

192- 193 -

(2) ポータルサーバ：
ユーザがネットワーク上の資源を利用する際の入り口であり、拠点として必ず利用するサイトである。ポータルサーバに求められる基本的な機能は、ユーザの入力の処理、動的に変化する HTML コンテンツの生成、他拠点にある資源へのアクセスである。
さらに、複数のユーザ間でグリッド上の様々な資源やデータを共有し活用するためには、ポータルサーバに高度なプレゼンテーション能力が求められる。これらの要求を満たすため、基本プラットフォームをサーブレットコンテナ (Tomcat) として、フロントエンド部分に Laszlo プレゼンテーションサーバ [16]、バックエンド部分に Web
サービス技術 (Axis [17]) とグリッド技術 (Globus) を用いた。
フロントエンド部分に採用した Laszlo (Open Laszlo) は、リッチ・インターネッ
ト・アプリケーションを開発、配布するためのプラットフォームであり、サーバサイドで生成したコンテンツを Flash としてクライアントの Web ブラウザに配信することができる。Laszlo によって提供される Web クライアントは、従来の HTML、DHTML、CSS、JavaScript 等による Web クライアントと比較して、高度な GUI ユーザー・エ
クスペリエンスを実現できる (ユーザがしたいことを心地よく行える) 点で期待できる。Laszlo アプリケーションサーバを採用する主な利点を以下にあげる。
z

ページを切り替えることなく一連の操作が行えるようなユーザインタフェース
を Web クライアント上に実現できるz

Java、オブジェクト指向、XML、JavaScript 技術により、開発の導入コストを低く抑えることができるz

コンテンツは Flash Player に対応しているため、多くのクライアント環境で動作可能である

バックエンド部分では、Web サービス技術を用いてポータルサーバとインデクシン
グサーバとの間を疎結合し、グリッド資源に関する情報を専用ネットワーク上で取得できるようにした。また、広域ネットワーク上の各種グリッド資源を利用できるようにするため、ユーザのプロキシ証明書を管理する MyProxy サーバ、および、広域ネッ
トワーク上のグリッドノード上で公開される各種サービスにアクセスするためのクライアント機能を搭載した。
(3) インデクシングサーバ：
グリッド資源に関する情報を提供するサーバであり、Web サービス技術によりサービスを公開する。ここで取り扱われる情報はシステムを正常な状態に維持する上で重要である。そのため、システム情報の改ざん等のセキュリティ対策の観点からポータ
ルサーバとの接続には専用ネットワークを用いることとした。さらに、システムの拡張に備えて Web サービスによる機能の搭載を行った。
(4) センシングノード：
USB カメラを接続したグリッドノードであり、カメラからの映像を他の拠点に配信する。本ノードで公開されるグリッドサービスは、カメラからの映像にアクセスする193- 194 -

ための URL をポータルサーバに転送する。USB カメラからの映像の取り込みと動画ファイル形式への変換をリアルタイムで行うために、コマンドラインツールで ある
ffmpeg (FFmpeg [18]) を用いた。動画ファイルのストリーミング配信には、HTTP マ
ルチメディア・ストリーミング・サーバである ffserver を用いた。
(5) コンピューティングノード：
画像処理を行うための計算グリッドである。本ノードで公開されるグリッドサービ
スは、画像処理プログラムの起動を行い、加工後の画像にアクセスするための URL を
ポータルサーバに転送する。画像処理の例として、convert コマンド (ImageMagick[19]) による画像フィルタリングの機能を搭載した。加工後の画像の公開には、Apache
HTTP サーバを用いた。

図 4.2.9 ログイン画面 (上段左)、カメラおよびアプリケーションの選択画面(上段右)、カメラからの映像のストリーミング配信とリアルタイムの画像処理 (下段)194
- 195 -

4.2.4 高精細表示システム
広域ネットワークを介して接続された複数の観測装置からの情報やアプリケー
ションの可視化結果を高精細に表示することを目的として高精細表示システムを構築した。
本システムの構成は、液晶ディスプレイモニタ 20 台、描画用計算機 10 台、および、制御用計算機 1 台からなる。液晶ディスプレイは、対角 19 インチの TFT 型であり、SXGA (1280×1024 ドット) の表示領域を持ち、ディスプレイ周辺部のフレームが四辺ともに同じ幅である、この液晶ディスプレイを横方向に 5 台、縦方向に 4 台とな る よ う に 並 べ て 配 置 し 、 デ ィ ス プ レ イ 全 体 の 表 示 領 域 を 、 6400 × 4096 ド ッ ト(26,214,400 pixels) とした。ディスプレイラックの寸法は、横幅 2122mm、高さ 2400mm、奥行き 300mm であり、脚部分を除くディスプレイ部分のみの寸法は、横幅 2122mm、高さ 1430mm、奥行き 300mm である。描画用計算機、および、制御用計算機には、Sun
Java Workstation W2100z を使用した。いずれも、メインメモリを 8GB 搭載しており、
DVI-I ディスプレイコネクタを 2 つ装備している。描画用計算機は、1 台で液晶ディスプレイ 2 台分の描画を行う。なお、本システムのソフトウェアには、SAGE [20] を利用している。
このように、複数の液晶ディスプレイを縦横に配置することで広大な表示可能領域を実現しており、１つの可視化結果を複数のディスプレイを使って大きく表示させることができる。これにより、全体を見ながら細部を検討するといった作業が可能になる。また、複数の可視化結果を各々のディスプレイに表示させることで、同時に複数の結果を比較するといった作業が可能になる。

液晶ディスプレイ

描画用計算機

制御用計算機図 4.2.10 高精細表示システムの構成

195- 196 -

図 4.2.11 ディスプレイの組立て (上段左)、ディスプレイ装置 (上段右)、
描画用計算機 (下段左)、アプリケーションの実行 (下段右)4.2.5 まとめ
今期は、広域ネットワーク上で安全にセンシングデバイスを共有し活用することを目的として、センシングデバイスのためのグリッド接続方式を提案した。また、提案
方式に基づいてカメラを用いた観測システムを実験ネットワーク上に構築し、グリッ
ド環境におけるカメラからの画像の取得と任意のデータ加工に成功した。拠点連携技
術を用いて広域ネットワーク上に計測や観測のためのシステムを容易に構築で き、ユーザがシングルサインオンでセンシングデバイスのデータにアクセスできることを示した。
これまでに、多様なセンシングデバイスを安全にネットワーク上で共有可能にするためのプラットフォームの開発を行ってきた。動的ファイアウォール設定機構では、グリッド通信ライブラリを機能拡張することで、アプリケーション要求に応じてファイアウォールを動的に設定できるようにした。センシングデバイスのためのグリッド接続方式では、アプリケーションの実装に依存しない認証システムと認可システムとの連携により、総合的で細密なアクセス制御が可能となる。これらの技術は、共有される資源のセキュリティ低下を抑止することができ、また、ユーザ要求や市場の変化に対応可能な観測や計測のためのシステムを構築することができる。
今後は、グリッド環境に収容された資源に関する情報を管理するための方式を検討
し、利用者が利用可能な資源を容易に知るための手段を検討していく。また、本研究
196- 197 -

サブテーマは、拠点連携を容易かつ高効率にするミドルウェア層の技術に主たる着眼を有するため、実践的かつ実際的な大規模アプリケーションへの適用を行うことで有用性の検証を重ね、さらに実用的な技術にしていく。
4.2.6 文献
[1] The Globus Alliance, http://www.globus.org/[2] Ian Foster, Carl Kesselman and Steven Tuecke:
The Anatomy of the Grid: Enabling Scalable Virtual Organizations,
http://www-unix.globus.org/alliance/publications/papers/anatomy.pdf (2001).
[3] Von Welch: Globus Toolkit Firewall Requirements: Version 7,
http://www.globus.org/toolkit/security/firewalls/Globus%20Firewall%20Requirements-7.pdf (2005).
[4] Richard E. Smith: オーム社, 認証技術 パスワードから公開鍵まで (2003)[5] マイケル・ホイットマン, ハーバート・マトード: トムソンラーニング, インフォ
メーションセキュリティ入門 (2004)[6] 社団法人 電子情報通信学会: オーム社, 情報セキュリティハンドブック (2004)[7] 谷口 功: オーム社, 図解 ネットワークセキュリティ 第２版 (2005)[8] 安藤 繁, 田村陽介, 戸辺義人, 南 正輝: 東京電機大学出版局, センサネットワー
ク技術 ユビキタス情報環境の構築に向けて (2005)[9] 日本 BEA システムズ 株式会社: 翔泳社, SOA サービス指向アーキテクチャ (2005)[10] Steve Graham, Simeon Simeonov, Toufic Boubez, Doug Davis, Glen Daniels,
Yuichi Nakamura, Ryo Neyama: ソフトバンクパブリッシング, Java による Web サー
ビス構築 (2002)[11] GT Data Management: GridFTP, http://www.globus.org/toolkit/data/gridftp/[12] Apache Tomcat - Apache Tomcat, http://tomcat.apache.org/[13] Cog Kit Home Page, http://www.globus.org/cog/[14] Globus Toolkit CoG Kits, http://www-unix.globus.org/toolkit/cog.html[15] The ProFTPD Project: Home, http://www.proftpd.org/[16] OpenLaszlo | the premier open-source platform for rich internet applications,
http://www.openlaszlo.org/[17] WebServices –Axis, http://ws.apache.org/axis/[18] FFmpeg, http://ffmpeg.sourceforge.net/index.php[19] ImageMagick: Convert, Edit, and Compose Images,
http://www.imagemagick.org/script/index.php[20] SAGE, http://www.evl.uic.edu/cavern/sage/index.php

197- 198 -

4.3 広域ネットワークにおける大規模データ処理連携技術の研究開発
近年の傾向として、分散計算において取り扱うデータの大容量化が進行し、ひとつの組織で準備できる計算能力を超える処理が必要となる状況が起こりつつある。これに対応するため、Grid では仮想組織 (VO; Virtual Organization) を構成するが、これらの組織間を広域網で接続して、計算データを他組織へ転送する。従って、この広域網を利用した転送性能が計算性能に大きく影響する。
特に、多数のセンサーからの出力を処理するようなアプリケーションでは、全てのセンサーからのデータを一定の制限時間内で処理する必要がある。この場合、各セン
サーから出力されるデータの転送に際し、データ転送の性能を保証し処理が制限時間内に終了できるように図ることが重要である。必要十分な帯域を持つ回線を事前にエンド to エンドで準備すれば容易に性能保証を達成することは可能であるが、全てのエンド to エンドに必要十分なネットワークを事前に敷設しておくのは、コスト的にも物理的にも困難である。
一般に、多くの組織では計算資源は組織の内部ネットワークや ISP 等の提供するハ
ウジングサービスを利用して設置される。このため、計算資源で利用できる帯域は入り口のリンクの総帯域のごく一部に限られてしまう。すると、この入り口リンクの帯域により同時に性能保障可能なデータ転送の総数が決定され、システムの稼動効率がリンクの利用可能帯域で制限されることになる。
そのため、本研究開発ではネットワークの品質保証技術(QoS 技術)を用い、各デー
タ転送に対して帯域を予約することで、性能保証を実施する方式について研究開発を行っている。本研究では、Diffserv の AF サービスを提供するネットワークを前提とし、拠点の入り口のリンクにおける予約が必要となる総帯域を減少させることで、計算資源の効率を向上させることを目指している。現在までに、動的に各データ転送の予約帯域を調整する QoS 制御技術および、動的 QoS 技術と組み合わせて利用するための、大規模データ転送向けのデータ転送プロトコルについて研究開発を行っている。
4.3.1 動的 QoS 制御技術
昨年度から個別のフローに対して AF で最低帯域を保証しつつ、呼の開始時に契約した帯域をファイルの転送が進むにつれて、見直す方式を提案して、定量評価を実施してきた。H17 年度はその性能評価結果をまとめて国際学会において発表した。詳細は H16 年度に既に報告しているため、本稿では方式の概要を簡単に紹介するのみにと
どめる。

198
- 199 -

実際の利用帯域

他のフロー発生により利用可能帯域減少

契約以上に利用した帯域

必要帯域を再計算し帯域一部返却
当初契約
帯域

見直し後
契約帯域

再見直し後
契約帯域

図 4.3.1: 提案方式の帯域利用法(3) 契約済み帯域確認、受付制御(7) フロー削除
管理サーバ

制御情報

(2) 帯域確保申請(6) 帯域開放申請(4) 契約帯域、フロー情報通知(8) 契約帯域開放指示発信クライアントルータ(4) データ送信(1) 必要帯域計算

データ

ルータ

着信
クライアント(5) フロー単位でAFでマーキング

定期的に必要帯域再計算、利用帯域削減

図 4.3.2: 提案方式の実現例(1) 提案方式概要
本方式は図4.3.1 に示すように帯域を利用し、定期的に必要帯域を見直して、契約
帯域を徐々に削減する。

199- 200 -

(3) 契約済み帯域確認、受付制御(7) フロー削除
管理サーバ

制御情報

(2) 帯域確保申請(6) 帯域開放申請(4) 契約帯域、フロー情報通知(8) 契約帯域開放指示発信クライアントルータ(4) データ送信(1) 必要帯域計算

データ

ルータ

着信
クライアント(5) フロー単位でAFでマーキング

定期的に必要帯域再計算、利用帯域削減

図 4.3.2は本提案方式の実現例である。ファイル転送の発生時に、送信側端末はルータを管理するサーバに要求帯域を通知し、帯域を契約する。サーバはルータの設定を変更し、フローに最低帯域を保証する。また、個々のパケットに対してはエッジルー
タにおいて、契約帯域内かどうかでマーキングを実施する。
本方式では、AF を用いたフローに対する最低帯域保証に加えて、予定以上にスループットを得られた場合に、契約帯域を削減していくことで、以下のような効果を得ることを目指している。
•

個別のフロー単位で最低帯域保障を実施することにより、経路の帯域に空きがある場合の利用効率を向上させる。

•

総契約済み帯域を低く抑えることにより、新たな呼の受理可能性を増加させる。

(2) 帯域の見直し手法
提案方式では、想定した帯域以上にスループットが得られた場合にのみ、契約帯域の見直しを実施する。そのため、契約帯域の増加はないので、各フローがいったん契約した帯域はフローの終了まで維持されるか、減少するかしかない。よって、帯域要求の失敗による呼損はフロー発生時しか起こりえない。すると、帯域の再契約処理は残りデータを転送しながら実施してもかまわないため、帯域見直しに伴うデータ転送の中断は発生しない。
なお、本提案手法では、事前に定められたブロックサイズ分だけファイル転送が終了した時点で必要帯域の見直しを実施する。
(3) スループットの予測と契約帯域の算出方法
契約帯域の見直しには、要求した帯域に対してどの程度の性能が得られたかを計算する必要がある。TCP ではフローに対して帯域を契約していても、その性能が得られない。そのため、期待できるスループットを計算し、その値に基づいて必要帯域の見200- 201 -

直しを行う。

ウィンドウサイズ
ウィンドウサイズ

Wmin=Wmax/2

Wmax

平均スループット=台形の面積/1周期の時間
時間

時間

図 4.3.3: TCP のウィンドウサイズの変化 図 4.3.4: ウィンドウサイズ変化（1 周期分）

契約帯域とスループットの関係
まず、輻輳回避フェーズにおける TCP の性能について議論する。TCP の挙動は単純化すると、パケットの破棄により、ウィンドウサイズが 1/2 となり、そこから 1RTT
時間毎にウィンドウサイズが 1 パケットサイズ分だけ増加するという動作を繰り返す。
（図 4.3.3）また、パケットロスによるウィンドウサイズの変化の 1 周期分の様子を図 4.3.4 に示す。
次に、各種の変数を以下のように定義する。

T : 経路の RTT （秒）P : パケットサイズ(byte)
B : 契約帯域(bps)
Wmax : 可能な最大ウィンドウサイズ(byte)
Wmin : 小さくなったウィンドウサイズ(byte)
すると、ウィンドウサイズの回復に必要な時間は式(1)で表すことができる。

(Wmax − Wmin )T / P(1)

さらに、最大のウィンドウサイズ、最小のウィンドウサイズの関係は式(2)である
ので、この区間での平均スループットは式(3)となる。

Wmin = Wmax / 2(2)

S = 8(Wmax + Wmin ) / T = 6Wmax / T (bps) (3)Wmax (byte)のデータが T （秒）の間に、経路を流れて、それが可能な最大帯域となることから、契約帯域 B と Wmax の関係は式(4)で計算できる。
Wmax =

BT(byte)
8201- 202 -

(4)

すると、スループットは以下の式(5)で与えられる。

S = 3B / 4(5)

しかし、実際には、TCP のヘッダや再送、さらにはスロースタートの影響や、契約
帯域を越えてもすぐにパケットは破棄されないため、アプリケーションレベル のス
ループットはこれを多少前後した値となる。
契約帯域の見直し
提案方式では、以上の式を利用して契約済みの帯域と転送に成功したデータ量を比較した上で契約済み帯域を削減可能かどうか判断する。
時刻 t において契約済み帯域が削減可能かどうかを初期の契約帯域 B とファイルサ
イズ F 、現在の契約帯域 Bt に基づいて判断をする。
まず、 B と F および T から予測されるスループット S 0 を計算する。次に、 S 0 から
ファイル転送の予想終了期限 tlim を計算して記憶しておく。ここで、時刻 t において転送しなければならない残りのファイル容量を F t とすると、F t と t lim −t から必要となる'

最低のスループット S t を計算する。S t を用いて、必要となる契約帯域 Bt を計算し、Bt'と Bt を比較して、再契約が可能かどうか決定する。

4.3.2 大規模データ転送向け TCP ベースプロトコル技術
従来のアプリケーションで利用されている TCP を利用した大規模データ転送において、性能保証のために帯域を予約すると、実際に得られるスループットが予約した帯
域に対して小さくなるという問題点がある。そのため、TCP を用いない新たな研究開発も実施されているが、それらの新しいプロトコルには他のトラフィックと混在した
場合に他のトラフィック(主として Web 閲覧などの TCP トラフィック)の性能を圧迫してしまい、他のユーザのネットワーク利用状況が悪化するという問題がある。
そのため、本研究では TCP を利用しつつ帯域の利用効率を最大化するためのデータ転送方式について研究開発を実施した。本方式は 2 種類の TCP コネクションを利用することで、ネットワークが輻輳している場合の確実な性能保証と非輻輳時の利用可能帯域の有効利用を特徴としている。
本節では、Diffserv AF(最低帯域保証サービス)環境下での TCP に対する性能保証の問題点とそれに対する解決策(提案方式)について説明する。
(1) Diffserv AF 環境における TCP の問題点
TCP を用いたデータ転送に対して最低帯域保証サービスで性能保証を実施する際に発生する問題は TCP の輻輳回避アルゴリズムによって発生する。ネットワークが輻輳し、契約以上のレートのパケットが全て破棄されるような環境では、TCP のウィンド
ウサイズは図 4.3.5のように変化する。輻輳回避フェーズにおける TCP の挙動は、パ202- 203 -

ケットのロスを検知すると、ウィンドウサイズを半分にし、その後 1RTT 毎にウィンド
ウサイズを線形に増加させる。そのため、契約帯域を越えたパケットが全て破棄される環境では実際のスループットは契約帯域の 75%程度になる。
Window size

Packet loss

契約帯域

OUT
IN

実スループット＝3/4
実スループット＝3/4 契約帯域

½ window sizeTime

図 4.3.5 : 輻輳時における TCP のウィンドウサイズの変化
この問題を回避するため、TCP のウィンドウサイズの上限を固定し、ウィンドウサ
イズを固定することで、契約帯域に近いスループットを得る方法がある。しかし、この方法では、ネットワークが輻輳しておらず、さらに大きなスループットを得る可能性がある状況においても、契約以上のスループットでデータ転送を実施することができない。
Window size

契約帯域

契約帯域≒実スループット
Time

図 4.3.6 : ウィンドウサイズの制限時のスループットと契約帯域の関係(2) 提案方式
本研究では、2 本の TCP コネクションを利用し、輻輳時における予約帯域に近い実
スループットを獲得することと、非輻輳時の帯域の有効利用を両立させる方式を提案した。本方式では、図 4.3.7に示すように帯域の契約を 2 本のうちの 1 つの TCP コネ
クションに対してのみ実施し、契約対象の TCP コネクションのウィンドウサイズに上限を設定することで、輻輳時においても、契約帯域に近い実スループットを得ることができる。さらに、非輻輳時における帯域の有効利用を実現するため、もう 1 本の TCP
コネクションを利用し、ベストエフォートでデータ転送を行うことで、非輻輳時において契約以上の帯域を活用することが可能となる。
203- 204 -

制御なし・通常のTCP動作

空き帯域の利用
帯域予約無し

追加フロー
基本フロー

安定した性能最大ウィンドウサイズの制限
送信レート ＜ 契約帯域
帯域契約あり図 4.3.7 : 提案方式におけるスループット(3) 性能評価
図 4.3.8は性能評価で用いたネットワークモデルである。図における各リンクの帯域は 100Mbps であり、発着端末間の伝播遅延は 20ms となっている。このネットワーク
において、性能保証が必要な TCP コネクションに対して 50Mbps で帯域を契約し、提案
方式と 1 本の TCP に対して 50Mbps で最低帯域保証した場合の性能を比較した。

Link: 100Mbps
RTT: 20ms

Cross Traffic
UDP(CBR)
OUT Marked

1ms

1ms

SenderContract:50Mbps

IN
OUT

1ms

2ms

receiver

2ms
4ms

2ms

2ms

1ms

Diffserv Domain
図 4.3.8: 性能評価モデル

図 4.3.9 は提案方式において、帯域を契約する TCP コネクションの上限ウィンドウサ
イズを少しずつ変えた場合の 2 本の TCP の合計スループット(6 種類)および、1 本のTCP で帯域契約した場合のスループットのグラフである。

204- 205 -

100

windowsize 124
windowsize 128
windowsize 132
windowsize 136
windowsize 140
windowsize 144
conventional

Throughput (Mbps)

80

60

40

20

0

0

20

40

60

80

100

Cross traffic load (Mbps)

図 4.3.9 : スループットグラフ
この図から読み取れるように、50Mbps 以上の CBR を投入した場合(輻輳時)に、従来の方式では契約帯域の約 78%にあたる 39Mbps 程度のスループットしか得られていないが、提案方式では、85%～95%程度のスループットを得ることができた。
4.3.3 大規模データ転送向け UDP ベースプロトコル技術
前節で述べたように、現在提案されている各種の高速転送プロトコルは他のトラフィックと混在しない単独の環境では良い性能を得られるが、一般のネットワークで用いる際には各種の問題がある。しかし、TCP を利用したデータ転送はネットワーク
が高速になればなるほど、TCP の欠点が大きくなってくる。そのため、長期的な課題
として、将来の超高速ネットワークでの利用を考慮して、現在の高速プロトコルの欠点を少しずつ軽減していく研究開発も実施している。
現在、この研究開発では、既存の高速データ転送プロトコル UDT を用い、そのプロトコルの持つトラフィック混在環境下での問題点を軽減する方式(gentle UDT)を提案した。
(1) 高速データ転送プロトコル UDT
UDT はネットワークの状態を計測し、その結果から利用可能な帯域を予測して、そのレートでデータ転送を実施する。この際、ネットワークの測定には連続した 2 つのパケットを送信し、着信端末でそのパケットの到着時間差を計測し、利用可能帯域を予測する。これにより、他のトラフィックが利用してない帯域全てを利用することを目指すプロトコルである。

205- 206 -

他のトラフィック
到着時間間隔から利用可能帯域を予測
データパケット

広域網
発信端末

着信端末

パケットロスの検出とNACK (Negative Ack)の送信

図 4.3.10 : UDT の動作原理
しかし、オリジナルの UDT の利用可能帯域の予測アルゴリズムには実際の利用可能帯域より、大きい帯域を予測するという問題点がある。このため、実際の利用可能帯
域以上のレートでパケットを送信してしまい、ネットワークを輻輳させてしまう。このため、混在する他のトラフィックの利用帯域を圧迫し、TCP を利用した場合はほとんど通信できなくなる。
本研究では、これらの問題を軽減するため、利用可能帯域の予測方式の改良と、UDTを流すのに適したネットワークにおけるパケットの管理方式(ルータのキュー管理方式)を提案した。
(2) 利用可能帯域の予測方式
UDT における利用可能帯域の予測では、パケットペア方式による利用可能帯域の推定を行っている。パケットペア方式における利用可能帯域の予測は輻輳時に実際の利用可能帯域よりも大きな値をしめすという問題点がある。これに対し、パケットトレインと呼ばれる方式がある。この方式では多数のパケットを連続して送信し、これらの到着間隔を着信側で測定し、それに基づいて利用可能帯域を予測する。パケットト
レイン方式は輻輳時に比較的良い予測値を出すものの、非輻輳時においては過小な値を出すという問題点がある。
そのため、本研究では両方式の良い特性を生かすため、非輻輳時はパケットペア方
式で利用可能帯域を予測し、輻輳時は 2 つのパケットの到着間隔をパケットトレイン
方式で評価することで、パケットトレイン方式に似た特性を得るようなアルゴリズムを採用した。

206- 207 -

非輻輳時

推定帯域値

推定帯域値

輻輳時

望ましい推定帯域

パケットペア方式
パケットトレイン方式

望ましい推定帯域

パケットペア方式
パケットトレイン方式
時間

時間

Packet pairによる推定帯域は過大評価
過剰なパケット送信
他フローに対する影響大

到着レートによる推定帯域が過小評価
帯域を十分に使い切れない
フロー間の公平性が劣化

図 4.3.11 : 利用可能帯域推定技術
ここで問題となるのは、輻輳しているかどうかの判定であるが、この判定にもパケットの到着間隔を用いている。到着するデータパケットの間隔が増加傾向を示している場合は徐々に輻輳状態になっていると判断し、利用可能帯域の推定をパケットト
レイン方式のアルゴリズムに切り替えて実施している。さらに、本提案方式では輻輳状態の緩和を早期に実施するために、予測帯域が現在の目標帯域を下回った場合の次の目標帯域の設定値の算出方法も変更した。オリジナルの UDT では、0.125 をパラメータとした加重移動平均を取っているが、そのパラメータを変更し、輻輳状態の緩和を早期に実施できるアルゴリズムとした。

SYNタイマ非輻輳時

輻輳時

Pathloadによる遅延増加傾向

ネットワーク状況の推定

レート制御の指標にBE

ペアパケット方式によるFSBW推定
Median Filter を使用

レート制御の指標にRE

到着パケットレートをパケットトレイ
ンとして扱うことでFSBW推定
Mean Filter を使用

If (BW_ave < BW_curr)
BW_ave = BW_ave * 0.875 + BW_curr * 0.125
else
BW_ave = BW_ave * (1 - α) + BW_curr * α

DAIMDアルゴリズムに従ったレート制御

図 4.3.12: 提案方式
(3) キュー管理技術
利用可能帯域の予測方式の改良により、UDT パケットの送信レートを抑えることで207- 208 -

ある程度他のトラフィックへの影響はある程度小さくなるが、十分な性能を得ることはできない。この問題に対応するため、ネットワーク側でのパケットの取り扱いも変
更し、UDT と他のトラフィックが混在した場合の他のトラフィックへの影響を小さくする方式を提案した。本提案では、ルータにおけるバッファ管理のアルゴリズムを変更することで、UDT と TCP が混在した場合の TCP への影響を小さくする。
ルータにおけるキュー管理では、実際にパケットを送信する出力インターフェース
で送信待ちとなっているパケットを蓄積する出力キューがあり、そのキューの長さによって、次に到着するパケットの取り扱いを変化させる。この時、パケットの取り扱いを決めるために用いるキュー長はパケットの変動に伴う細かな変動を取り除くため、一定時間におけるキュー長の平均値を用いるのが一般的である。

実キュー長 平均キュー長

図 4.3.13 : ルータの出力インターフェースにおけるキュー管理
図 4.3.14 に 示 す の は 、 一 般 的 に 良 く 用 い ら れ て い る キ ュ ー 管 理 技 術 で あ る 。
DropTail とは、特になにも制御せずバッファが一杯になった時点で次に到着したパケットを無差別に捨てるキュー管理技術である。それに対して、RED といわれる方式
は TCP の輻輳回避の性質を利用し、出力キューに送信待ちのパケットがある程度存在する時点でパケットの破棄を開始する。これにより、破棄された TCP は送信レートを減少させるため、徐々に到着するパケットが減少し、極端な輻輳が発生する前にこれを予防することが可能となる。

パケット破棄率

DropTail

パケット破棄率

1

1

実キュー長

図 4.3.14

RED

平均キュー長: 従来のキュー管理手法におけるパケット破棄確率グラフ

208- 209 -

ただし、これらの方式を UDT と TCP が混在する環境で利用した場合、TCP の利用できる帯域が極端に小さくなるという問題点がある。この問題に対応するため、本研究では最近新たに提案されたキュー管理技術をさらに修正して用いることとした。そもそも、RED において TCP の得られる帯域を改善するためには、非常に高速にネットワー
クの変化に追従して送信レートを変化させる UDT のパケットが早期に破棄されるような特性が望ましい。そのため、パケットの破棄確率を変化させる基準の値を平均キュー
長から実キュー長に変更するとともに、破棄確率特性として早期から小さな破棄確率
で破棄しつづけるようなキュー管理技術が望ましい。そのため、本研究では easyREDとよばれる簡易な RED の一方式に着目し、これのパケット破棄確率の変化のキーを平均キュー長から実キュー長に変更したものを用いることにした。
パケット破棄率

ERED

1

平均キュー長実キュー長に変更

図 4.3.15 : 本研究におけるキュー管理(提案方式)(4) 評価提案方式とオリジナルの UDT の性能を定量的に評価するため、計算機シミュレー
ションを実施した。図 4.3.16が本評価におけるネットワークモデルである。本評価では、長距離、広帯域ネットワークを想定したモデルを用い、複数の大規模データ転送(UDT および gentle UDT)のフローと混在する TCP のコネクションを作成し、それぞれの性能データを収集した。
大規模データ転送
×
5本
TCP

5ms

1Gbps, 40ms

5ms
RTT=100ms

図 4.3.16 : 性能評価モデル
209- 210 -

図 4.3.17は混在するトラフィックとして、FTP を用いた場合のグラフである。図から読み取れるように、UDT、gentleUDT ともに、帯域は有効に活用できているが、UDTの場合は混在する FTP の性能が極端に劣化している。それに対し、gentleUDT および
gentleUDT+eRED では輻輳の緩和により、FTP の性能の劣化を減少させている。

UDT+
DropTailgUDT+
DropTail

gUDT
+
eRED

1

図 4.3.17 : 帯域利用と混在する FTP への影響

210
- 211 -

図 4.3.18は混在するトラフィックとして http を用いた場合の http トラフィックの 平 均 所 要 転 送 時 間 の 変 化 の グ ラ フ で あ る 。 こ れ も FTP の 場 合 と 同 様 に 、 UDT、
gentleUDT、gentleUDT+eRED の順番で http の転送所要時間が回復している。
UDT+
DropTailgUDT+
DropTail

gUDT
+
eRED

1

図 4.3.18: 混在する web トラフィックへの影響
4.3.4 プロトタイプ
本研究開発では、実際のネットワークでの性能評価やアプリケーションとの連携を実現するために、プロトタイプソフトウェアの開発と、各種のネットワーク状況が再現できる実験システムの構築も同時に行った。この現在のプロトタイプソフトでは、動的な QoS 制御技術と TCP を利用したデータ転送プロトコルを実装している。また、
実験システムでは、各種の品質のネットワーク状況を再現することができるため、プ
ロトタイプソフトウェアを用いた実環境での性能評価が可能となっている。
今後はこれらのシステムを用いて、実際のネットワークや機材を用いた定量的な性
能評価を実施する予定である。

211- 212 -

イベント・ログ
収集サーバ
呼制御サーバ QoS要求(COPS等)

ネットワーク制御サーバ
システム全体の動作ログデータ

帯域確保要求(独自プロトコル)
設定変更
発端末(データ転送データ
クライアントソフト) 転送

ルータ

擬似広域網

ネットワークエミュレータ

着端末

トラフィック発生装置

図 4.3.19 : プロトタイプシステム概要
4.3.5 まとめ大規模なデータ転送(ファイル転送)に対する品質保証が必要な DataGrid 等のアプ
リケーション向けのネットワークにおける QoS 制御技術および、データ転送プロトコルに関する研究開発を実施した。本稿では、従来の方式の問題点と研究開発の成果である各種提案方式について報告した。
現在の研究開発は多数のユーザが同時にアクセスするネットワーク環境に対して最低帯域保証サービスを適用し、その環境において、性能保証に必要となる予約帯域を最小化することを目指している。大規模なファイル転送が必要なアプリケーション
では、ネットワークの帯域不足により、データ処理を行う計算機の稼動効率が制約されるため、これらの提案方式により、システム全体の稼動効率を向上させることを狙っている。
現在は QoS 制御方式と TCP を利用したデータ転送プロトコルについてプロトタイプの開発を実施しており、計算機シミュレーションによる評価だけでなく、実際の環境での性能評価を計画している。また、長期的課題として取り組んでいる高速データ転
送プロトコルについては、最低帯域保証サービスへの対応などさらなる研究開発が今後の課題となっている。
4.3.6 文献[1] 野呂正明, 長谷川一郎, 馬場健一, 下條真司, “Grid における大量データ送信に適した品質保証方式”, 電子情報通信学会技術研究報告 IA2004-22, pp. 21– 16,
January 2005.
[2] T. Li, Y. Rekhter, “A Provider Architecture for Differentiated Services andTraffic Engineering (PASTE)”, RFC2430, October 1998.
[3] K. Nichols, S. Blake, F. Baker, D. Black, “Definition of the Differentiated212- 213 -

Services Field (DS Field) in the IPv4 and IPv6 Headers”, RFC2474, December
1998.
[4] D. Grossman, “New Terminology and Clarifications for Diffserv”, RFC3260,
April 2002.
[5] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, “AnArchitecture for Differentiated Service”, RFC2475, December 1998.
[6] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, “Assured Forwarding PHBGroup”, RFC2597, June 1999.
[7] S. Floyd, V. Jacobson, “Link-sharing and Resource Management Models for
Packet Networks”, IEEE/ACM Transactions on Networking, Vol.3, No.4, pp.
365-386, August 1995.
[8] 鶴正人, 熊副和美, 尾家祐二, “長距離高速通信のための TCP 性能改善技術の動向”, 情報処理学会誌, vol.44, No.9, pp.951-957, September 2003.
[9] S. Floyd, V. Jacobson, “Random Early Detection gateways for Congestion
Avoidance”, IEEE/ACM Transactions on Networking, Vol.1 No.4,
pp. 397-413, August 1993,.
[10]

W. Feng, D. Kandlur, D. Saha, K. Shin,“Understanding and improving

TCP performance over networks with minimum rate guarantees”,

IEEE/ACM

Transactions on Networking, Vol.7, Issue.2, pp.173-187, April 1999
[11]

The Globus Alliance , “Grid FTP”
http://www-fp.globus.org/datagrid/gridftp.html[12]

VINT project, “ns2”,

http://www.isi.edu/nsnam/ns/[13]

OptIPuter, http://www.optiputer.net/[14]

Y.Gu, X. Hong, and R. Grossman, “ Experiences in the design andimplementation of a high performance transport protocol”, in Proceedingsof SC2004, Nov. 2004.
[15]

野呂正明, 長谷川一郎, 馬場健一, 下條真司, “Grid における大規模ファイル転送向け QoS 制御方式の性能評価”, 信学技報 IN2005-83, Sep. 2005.
[16]

Masaaki Noro, Ken-ichi Baba and Shinji Shimojo, “QoS Control Method to

ReduceResource

Reservation

Failurein

DataGrid

Applications”,

In

Proceedings of PACRIM2005, August 2005.
[17]

為重 文覚, 馬場 健一, 野呂 正明, 下條 真司, “高帯域遅延積ネットワー

クにおける UDT の帯域推定手法の一検討”, 電子情報通信学会ソサイエティ大会
B-7-8,pp135, Sep. 2005.
[18]

為重 文覚, 馬場 健一, 野呂 正明, 下條 真司, “高帯域遅延積ネットワー

クにおける UDT を用いた効率的な高速転送方式”, 信学技報 , NS2005-133, Dec.
2005.
213
- 214 -

[19]為重 文覚, 馬場 健一, 野呂 正明, 下條 真司, “長距離広帯域ネットワー

ク に お け る 高 速 デ ー タ 転 送 手 法 の 性 能 評 価 ”, 信 学 技 報 , IN2006-133, Mar.
2005.
[20]

檜山亜佑子, 野呂正明, 馬場健一, 下條真司, “転送時間を保証するための大規模データ転送手法の提案”, 電子情報通信学会 2006 総合大会公演論文集,
Mar. 2006.

214- 215 -

- 216 -第５章
プラットフォーム・アプリケーション技術に関する研究開発

第5章
5.1

プラットフォーム・アプリケーション技術に関する研究開発

概要

JGNⅡ研究開発プロジェクトのテーマⅣ「プラットフォーム・アプリケーション技術に関する研究開発」では，映像等大容量ブロードバンド情報の有効活用を実社会で実現させることを目指した研究開発を行っている．この目標のために，以下の３つのサブテーマを設けて，実施している．
アプリケーションごとに最適な運用管理を可能にするプラットフォーム技術について「アプリケーション指向型運用管理プラットフォーム技術の研究開発」を東北 RCで実施している．これは，アプリケーションを強く意識し，アプリケーションが求める的確なネットワーク情報を，必要十分な品質で，オンデマンドに提供する運用管理
プラットフォーム技術の開発を行うものである．今年度は，ネットワークトラフィッ
クとアプリケーションログの計測・解析に基づくネットワークイベント検出モデルの詳細設計を行い，実トラフィックデータを用いて有効性を確認した.また，広域ネット
ワーク環境におけるトラフィック情報のリアルタイム分析を支援する「Top-N トラフ
ィック分析支援システム」を完成し,Winny 等による異常トラフィックのイベント検
出・分析の効果的な支援が可能となった.アプリケーション単位のネットワーク観測技術として,ネットワーク管理のための運用・統計情報統合化システムへの情報選択機能の実装と,多地点間相互映像配信システムの送受信ノード機能のプロトタイプ実装を行った.フレキシブルネットワークミドルウェアについて、高速広帯域ネットワーク向けマルチキャストツリーの構成手法を開発し,シミュレータの設計と実装を行った.
ネットワーク上に分散する資源の自由な活用のための情報転送と効率的な情報転送・再現のための信号処理の実現を図る「サラウンディング・コンピューティング技術の研究開発」を高知 RC で実施している．これは，大量に転送される情報，特に映像情報が容易に利用できるよう，利用者が自然に情報を活用できるようなシームレスな
ネットワーク環境の実現を目指し，ネットワーク上の分散資源の自由な活用を図るための技術及び映像情報転送・再現のための処理方式の研究開発を行うものである．今
年度は，サラウンディング・コンピューティング環境での柔軟な伝送処理を実現するためのネットワーク・プロセッサの実現技術を示した．また，音響を効果的に再現できる方式とそれに適した信号処理アルゴリズムを開発した．
高精細映像を用いる,複数遠隔地との“空間共有型のリアルタイム映像コミュニケーション”技術について,「高度 HCI 技術を活用した適応型サービス制御の研究開発」としてつくば RC において実施している.これは通称“ミラーインタフェース”と呼ばれる技術をベースに、１）複数地点間の広帯域映像伝送方式,並びに遠隔地会場毎の映像を適切に合成して作成する空間共有方式,２）遠隔地へのポインティングによる機器制御技術,３）プロトタイプシステムを利用した地域連携による実証実験,を実施すること215- 217 -

である.今年度は,1)は,通信量と処理量とのバランスを考慮した 3 地点間通信・対話方式の研究,２）は,指示操作手段として新しく素手によるポインティングを加えた指示制御方式の検討,３）遠隔講義・遠隔カウンセリング等に適用したユーザビリティの評
価・つくば市との地域連携等を推進した.

216- 218 -

5.2 アプリケーション指向型運用管理プラットフォーム技術の研究開発
5.2.1 超高速大規模ネットワーク向きネットワーク計測・解析技術の開発- 5.2.1 章目次 5.2.1.(1) ネットワークトラフィックとアプリケーションログの計測・解析に基づくネットワークイベント検出モデル
5.2.1.(2) Detecting and diagnosing events from monitored data in awide area network

5.2.1.(1) ネットワークトラフィックとアプリケーションログの計測・解析に基づくネットワークイベント検出モデル
5.2.1.(1)-1 序論
近年, ネットワークシステムがインターネットの普及とともに広く運用されるようになり, 情報化社会において重要な役割を果たすようになった. そのため, ネットワ
ークシステムの適切な運用管理が不可欠となっている.
ネットワーク管理者は, 運用管理上特に重要な「イベント」に対して適切な対応をとる必要がある. イベントの具体例としては, リンク障害, ポートスキャンやパスワ
ードクラックといった不正侵入, DoS 攻撃, 禁止されている P2P ファイル交換ソフトの使用など, さまざまな例が挙げられる. 一般に, 管理者は, イベントを検出し, イ
ベントを識別し, イベントに対処するという 3 つの段階を踏んで, イベントに対してリアルタイムに対応する必要がある.
第 一 段 階 で あ る イ ベ ン ト を 検 出 す る 手 法 は , 不 正 検 出 （ Misuse Detection,
Signature Detection）と異常検出（Anomaly Detection）に大別される. 近年, ネッ
トワークトラフィックを利用したイベント検出手法として, 後者の異常検出手法を利用したものが盛んに研究されている. 不正検出は検出したい状態を逐一定義する手法
であるが,一方で異常検出は, 正常状態を定義することにより, そこから外れたものを異常として検出する手法であり, 日々発生する新種のウィルスやワーム等へ効率的に対応できると期待され, 注目されている. しかし, 実運用においてネットワーク
トラフィックの異常検出を行った場合, 異常検出手法の長所であった, 検出したい状
態を逐一定義する必要がない, ということが逆に短所となりうる. すなわち, イベン
ト検出後に, 具体的にどういった事象が起きたために異常と判断され, 検出されたのかという情報, つまりイベントを識別するための情報が乏しいということである. そ217- 219 -

のため, ネットワーク管理者はイベント検出後にあらためて大量のログを調査しイベントの識別や具体的な内容の把握を行う必要があり, 管理負担が増大したり, 対応に遅れが出たりするなどの問題が起こる.
以上を踏まえ, 本研究では, 異常検出手法によるイベント検出時において, 異常検
出結果からログの情報を自動的に絞り込み, 管理者によるイベントの識別を支援する「ログの要約」を提供する仕組みを提案する. これにより管理者の管理負担を軽減し,
またイベントへの迅速な対応を可能にすることでシステムの安定運用に貢献することが可能になる.
5.2.1.(1)-2 関連研究
従来の異常検出に関する研究 1) 2) は, 異常検出の精度をいかに向上するかを目的としている. これに対し, 本研究では検出後の異常内容の識別が実用上重要であると考える.
一方では, 本研究と同様に, イベント検出時の管理者の作業負担の軽減に注目した
研究 3)があり, 不正検出型のイベント検出時に原因推定や被害状況確認を自動化し,管理負担を軽減する手法を提案している. しかし, この手法は特定の不正検出手法に特化した手法であり, より汎用的な情報源により異常内容の識別を行える手法が期待される.
5.2.1.(1)-3 ログ要約システムの提案
本研究では, 異常検出結果とログの情報を組み合わせることにより, ログの要約を提供する手法を提案する. 図 5.2.1.(1)-1 に提案システムの概念図を示す. 従来, 管理者は異常検出結果として異常の有無を通知されるのみであったため, イベントの識別については改めて管理者が大量のログの調査などを行う必要があった. これに対し
提案システムではイベント検出時にイベントの具体的な内容を含む小さなログの要約を提供するため, 管理者はイベントの識別が容易に行えるようになる. 異常検出モジ
ュールは, トラフィックデータを入力とし, 異常検出時刻と異常検出に関連するデー
タの時間範囲, そしてバイト数, フロー数などの異常検出に使用したトラフィックデータの種類を出力する. ログ要約モジュールでは, 上記出力とログを入力とし, 関連するログを要約する処理を行い, ログの要約を出力する.
5.2.1.(1)-4 提案システムの設計
5.2.1.(1)-4.1 異常検出結果に基づく情報の絞り込み
まずはじめに, ログマイニングの精度を向上し, かつマイニング対象のログの量を減らすことでリアルタイム性を確保するため, 異常検出結果を元に, ログ要約モジュールで使用するログの情報を絞りこむ. これは異常検出モジュールが出力する, 異常

218- 220 -

検出に使用したトラフィックデータの種類に基づいて決定する. トラフィックデータの種類は 2 つの観点に大別でき, 1 つは異常検出に用いたトラフィックのプロトコルの種別と, もう 1 つはバイト数やパケット数, フロー数といった異なる着目点での統計値である.
前者については, 異常が判定されたトラフィックのプロトコルと, ログマイニングの対象ログとの対応付けに利用する. 例えば, HTTP トラフィックでの異常検出時はHTTP サーバのログを調査することが当然考えられる. それ以外にも, 一般に DNS トラ
フィックの異常検出時に DNS サーバのログだけでなく, メールサーバのログにも同時に影響が見られるというように, プロトコルとログの間には 1 対 1, 1 対多, 多対多の関連がある. この関連に従い, 異常検出結果から調査対象となるログを限定する.
次に後者については, バイト数やパケット数などのトラフィックの着目点によって,ログ内に記録されているどの情報に注目するべきか, という対応付けに利用する. 例
えば, バイト数において異常が検出された場合には, 転送ファイルサイズなどのコン
テンツの情報に注目すべきであるし, フロー数において異常が検出された場合には,ファイルサイズよりもリモートホストやセッションの頻度, リクエストの特徴に注目するべきである.
以上の 2 つの方針により, ログ要約モジュールが要約処理の対象とする情報を絞り込む.

219- 221 -

Eventinfluence

influence

applicationroutersystemtraffilogs
Anomaly Detection

Log files

ModuleresultAuthentication

Log
Summationlog,
access log,

Summary of Logs

Network

図 5.2.1.(1)-1

提案システムの概念図

5.2.1.(1)-4.2 クラスタリングによるログ内容の分類
次に, マイニング対象のログのレコードをクラスタリングにより分類する. これは特徴ベクトルの設定と, それに対するクラスタリングアルゴリズムの適用の 2 つの段
階に分けられる.
特徴ベクトルの設定は, ログのレコードに含まれる各フィールド値を数値化することで行う. フィールド値とは, 例えば HTTP サーバのアクセス履歴であれば, リモー
トホスト, HTTP リクエスト文字列, HTTP レスポンスコードなどが挙げられる. ただし,
特徴ベクトルの構成に当たって, 常に全てのフィールドを利用するのではなく, 先の異常検出結果に基づく情報の絞り込み結果に応じて, 必要なフィールドを取捨選択することが重要である. これはすでに述べたように, ログマイニングの精度向上及びリ
アルタイム性の確保のためである.
特徴ベクトルを生成した後, その特徴ベクトルに基づきログのレコードをクラスタリングする. クラスタリングの目的は異常検出と関連した特徴的なログのレコードを分類し, 抽出することである. それを踏まえ, 以下の手順で処理を行う. まず, 異常
検出直前の一定期間のレコードから生成した特徴ベクトルを用いてクラスタリングを220- 222 -

行い, 初期クラスタを生成する. これは対象ログの通常時の振る舞いを表しているといえる. 続いて, 異常検出時刻付近のレコードを追加しクラスタリングを行い, 初期
クラスタを更新する. このときクラスタの構成がどのように変化するかに注目する.
これにより, 通常時のログの振る舞いと, 異常検出時のログの振る舞いを比較することが可能となる.
なお, クラスタリングのアルゴリズムとしては, リアルタイム性を重視して単一パス法を採用した. このアルゴリズムは以下のようになる.
1) 最初の要素を初期クラスタとする.
2) クラスタに属していない要素 e i と, その時点での全てのクラスタとの類似度を計算する.
3) e i と最も類似度の高いクラスタ C j との類似度が閾値以上ならば, e i を C j に所属させ, クラスタを更新する. そうでなければ, e i を新しいクラスタとする.
4) 2), 3) を, 全ての要素がクラスタに割り当てられるまで繰り返す.

単一パス法では, 以上の通り初期クラスタの生成からクラスタの更新までが 1 パスで完了する. また, ベクトル間の類似度の尺度と, 同一のクラスタとみなす閾値の設定がクラスタリング結果に大きく影響する. 本手法では, ベクトル間の類似度として
文章比較などに用いられるコサイン尺度を用いた. これはユークリッド距離のようにフィールド間の絶対値の差に左右されず, またマハラノビス距離のように計算量が増大することもなく, リアルタイム処理に適している. また, 閾値については, 十分近いレコードのみを同一クラスタとみなすことで, 情報の欠損を防ぐことを目的に, 非常に高い類似度を持つレコードのみが同一クラスタとなるように設定する. 以上のア
ルゴリズムにより, 十分なリアルタイム性を実現した上で効果的にクラスタリングを行うことが可能である.
5.2.1.(1)-4.3 クラスタリング結果に基づくログの要約の作成
最後に, クラスタリングが終了した後, そこからイベントを特徴づける重要なクラスタを取捨選択し, ログの要約を作成する. 重要なクラスタとは, 通常時の振る舞いである初期クラスタの分布と, 異常検出時刻付近のレコードを追加しクラスタの更新を終えた段階のクラスタの分布との違いを決定付けるものである. 重要なクラスタを決定する具体的な方針として, 次の 2 つを挙げる.
1.

フロー数が多い場合には, 要素数の多いクラスタ, 要素数の増加率の大きいク
ラスタを重視する

2.

フロー数が少ない場合には, 要素数の少ないクラスタ, 新規に生成されたクラ221- 223 -

スタを重視する

1.は多数のフローがイベントを特徴付けており, 各フローの痕跡がログに記録されていると考えられるためで, 例えば, 異常検出時刻付近で急激にレコード数が増大したクラスタがそれに当たる. 逆に 2.では, 少数のフローが特異な挙動を示していると考えられるためで, 初期クラスタの段階では見られなかった新規に発生したクラス
タなどがそれに当たる.
これらの方針の下, 重要なクラスタを取捨選択した後, それらの選択されたクラス
タに含まれるレコード数と, レコードの時間範囲, 代表値としてレコードを数個抽出してログの要約を作成する.
5.2.1.(1)-5 実験および評価提案手法により, ネットワーク管理者が異常検出時に調査する必要のあるログの量が大きく減少し, 管理負担の軽減やシステムの安定運用へ貢献できることを示すため,
提案手法を実装し, 実際に運用しているネットワークで実験を行った. 実験項目は次の 2 つである.
1. 不要なログ情報の削減量の計測
2. アルゴリズムの計算時間の計測
図 5.2.1.(1)-2 に実験環境を示す. 実験環境は単独の HTTP サーバが存在する LAN
で, 対象ログとしては HTTP サーバが出力するアクセス履歴, エラー履歴の 2 つのログを使用した. トラフィックは 5 分毎の合計値でサンプリングし, 異常検出アルゴ
リズムには deviation score 2) を用いた. 以下, 本実験の結果に基づき, 次の 3 点について評価及び考察を行う.
1. 要約情報の有効性
2. アルゴリズムのリアルタイム性
3. 提案手法の汎用性・有効範囲

222- 224 -

外部ネットワーク
ルータ

トラフィックLAN

HTTP server

提案システム(Apache httpd)- Athlon64 2800+(1.8 GHz)
- 1GB RAM

異常検出モジュールアクセス履歴
エラー履歴

ログ

判定結果
ログ要約モジュール

図 5.2.1.(1)-2 実験環境

5.2.1.(1)-5.1 要約情報の有効性に関する評価
表 5.2.1.(1)-1 に, HTTP フロー数からの異常検出結果を元に, アクセス履歴・エラ
ー履歴ログを要約した際のログのレコード数の削減状況を示す.表 5.2.1.(1)-1 より,異常検出時刻付近のアクセス履歴 116 件を, 提案手法により 3 件に要約できることを確認した. 同様にエラー履歴においては 98 件を 12 件に要約できた. また, アクセス
履歴・エラー履歴ともに不要なレコードのみを排除し, 必要なレコードは排除しなかった. 以上により, 管理者がログを調査する負担を大幅に減らすことができたといえる.
次に表 5.2.1.(1)-2 に, HTTP バイト数・パケット数からの異常検出結果を元に, ア
クセス履歴・エラー履歴ログを要約した際のログのレコード数の削減状況を示す.表
5.2.1.(1)-2 より, 異常検出時刻付近のアクセス履歴 212 件を, 提案手法により 48 件に要約できることを確認した. 同様にエラー履歴においては 18 件を 7 件に要約できた.
しかし, アクセス履歴 48 件中 47 件は異常と無関係な不要なレコードであり, エラー
履歴では 7 件全てが不要なレコードであった. 先の結果と比較して不要なレコードが多く含まれてしまったが, 依然として必要なレコードが排除されることはなく, 全体のレコード数は削減できているため, 管理者がログを調査する負担をある程度減らす

223- 225 -

ことができたといえる.
表 5.2.1.(1)-1

HTTP フロー数の異常検出時のレコード数の削減状況

レコード数

アクセス履歴エラー履歴

1,846,419

15,7601,450179

異常検出時刻付近の数

116

98

最終的に選択されたクラスタに含まれる数

7995

最 終 的 に 含 ま れ る 必 要 の な か っ た 数 (false

0

16

0

0

3

12

総数
クラスタリングに使用した数

positive)
最 終 的 に 必 要 だ が 含 ま れ な か っ た 数 (false
negative)
要約情報として提供された数

表 5.2.1.(1)-2

HTTP バイト数・パケット数の異常検出時のレコード数の削減状況

レコード数

アクセス履歴エラー履歴

1,846,419

15,760

クラスタリングに使用した数

2516

195

異常検出時刻付近の数

212

18

最終的に選択されたクラスタに含まれる数

48

7

最 終 的 に 含 ま れ る 必 要 の な か っ た 数 (false

47

7

0

0

48

7

総数

positive)
最 終 的 に 必 要 だ が 含 ま れ な か っ た 数 (false
negative)
要約情報として提供された数

5.2.1.(1)-5.2 アルゴリズムのリアルタイム性に関する評価
クラスタリングのアルゴリズムを解析的に評価すると, クラスタ数 m の時, 1 個のサンプルの所属クラスタの決定には m 個の既存クラスタとの比較が必要であるため,
1 個のサンプルのクラスタリングの計算時間は O(m)となる. これを n サンプル繰り返
すため, 全体の計算時間は O(mn)となる. m が大きい時には O(n 2)に近づき, 逆に m が小さい時には O(n)に近づくことがわかる.
一方, 図 5.2.1.(1)-3 に, クラスタリングの実行時間とレコード数の関係を実測した結果を示す. 特徴ベクトルとして, ログ内で定義した全てのフィールドを利用して高次の特徴ベクトルを構成した場合と, 必要と思われるフィールドを絞って特徴ベク

224- 226 -

トルを構成した場合では, 計算時間の増加傾向に大きな差が出ている. 前者は情報過多によるクラスタの細分化によりクラスタ数 m が急速に増大したと考えると, 実測結
果は解析結果とよく一致している.
以上より, 特徴ベクトルに用いるフィールドを絞り込み m を一定値以下とすれば,サンプリング間隔内にクラスタリングが終了し, 十分なリアルタイム性を実現できる
といえる.

700

all features(18D-vector)
selected features(10D-vector)
sampling period

600

time [sec]

500

400

300

200

100

0
0

10000 20000 30000 40000 50000 60000 70000 80000 90000 100000# of records

図 5.2.1.(1)-3

クラスタリングの実行時間とレコード数の関係

5.2.1.(1)-5.3 提案手法の汎用性・有効範囲に関する考察
提案手法はログの利用が前提であるため, ログを直接管理し, 参照可能な環境でしか使用できない. よって, ネットワークの上流よりは下流の環境での使用が想定される. また, 対応可能なイベントの種類は, ログに記録する項目を変更することで柔軟に対応できると考えられる.
5.2.1.(1)-6 結論
本研究では, 異常検出時のイベントの識別に有効な, ログの要約を作成するログ要約システムを提案した. また, 実験により, 提案手法を用いてイベントの識別に有効なログの要約をリアルタイムに作成することが可能であることを示し, 管理者の作業

225- 227 -

負担の軽減, システムの安定運用に貢献できることを示した.
参考文献
1) Kenji Yamanishi, Jun-ichi Takeuchi, “On-Line Unsupervised Outlier Detection
Using Finite Mixture with Discounting Learning Algorithms”, Data Mining andKnowledge Discovery, 8, pp. 275-300, 2004.
2) Paul Barford, Jeffery Kline, David Plonka and Amos Ron, “A Signal Analysis
of Network Traffic Anomalies”, Internet Measurement Workshop 2002.
3) 福士賢二, 竹内春夫, 倉内博, 森井昌克, 辻井重男, “不正アクセス被害解析支援システムの試作”, 情報処理学会研究報告, 2002-CSEC-18-4, pp.21-26, 2002 年
7 月.

5.2.1.(2) Detecting and diagnosing events from monitored data in a wide
area network
5.2.1.(2)-1 Introduction
Network traffic monitoring is an important aspect of network management. The
monitored data needs to be processed and analyzed to know what needs to be looked at andwhere. To give an example, some observations may reveal the effects of events such as a
network failure, and operational failure or a security incident, on network traffic.
Towards this end we have set out on this project to develop a model of events of interest
which will use the monitored traffic data of the JGN-II network. We have developed a set oftools to aid the analysis of data, both online and off-line.
This year (H17) we have carried out experiments with the proposed event model. We
implemented new analysis algorithms to detect events. We used the category transform
technique to have a deeper look at network traffic from a different angle. With the proposed
event model and the new analysis technique, DDos attacks as well as Winny application
traffic could be detected with ease.
Having detected events, the network operator will generally want to diagnose the events.
For example if a traffic surge event was detected the network operator would want to know
the source of the traffic surge and, perhaps, the contents of the traffic surge. We designed anddeveloped a Top-N traffic analyzer. That works in conjunction with a CpMonitor traffic probe.
It analyzes the contents of the traffic to detect the source and contents of the major traffic
generators.

226- 228 -

We have then experimented with an event based management system where events aredetected and serve as trigger for the start or stop of automated collection of detailed data
which can be used to diagnose the event at a later time. We carried out the experiments on an
operational network and showed its effectiveness.
Our final goal is to provide a wide spectrum of users with information on events ofinterest. The target for H17, developing new algorithms for detecting events of interest andexperimentation with real data to evaluate/refine the model, has been met.
5.2.1.(2)-2 Traffic analysis techniques: Category transform
A category is the property which is defined by a value of one or more fields in a packet or
datagram. The fields may be in the header in the payload part of the packet. For example theprotocol field in the IP-header categorizes packets. All packets with protocol = TCP belong to
the same category. We may consider a special category, the TOTAL category, as the wild card
category - all packets belong to this category.
Monitors/probes look at the packets and their contents. Traditional statistics concerning
statistics are collected by sampling the monitors which count the- number of packets (all packets)- number of packets (for a particular category)e.g. number of packets with Header field indicating Protocol = TCP
Total

TCP Packets

UDP Packets

ICMP Packets

10:01

181

123

46

0

10:02

142

100

32

10

10:03

206

140

0

13

10:04

217

120

87

10

etc.
In the Category Transform (C-Transform) technique we look at the number of categories
to which the detected packets belong.. Thus if we are looking at the C-Transform of thepacket counts for the protocol field we get
Total

TCP

Packets

UDP

Packets

ICMP

Packets

10:01

181

123

46

0

2

10:02

142

100

32

10

3

10:03

206

140

0

13

2

10:04

217

120

87

10

3

C-Transform

etc.

227
- 229 -

Some of the header fields take a finite number of values and thus define a small numberof categories - for example- Version- Protocol
These can take values from the predefined set of values.
Some of the header fields can take a large number of values e.g. both the source anddestination addresses can take values in the range 0 .. 2**32.
The C-Transform becomes particularly interesting when it is applied to one or moreheader fields which can take a very large number of values. Examples of the c-transformstatistics will be
Total

C-Transform (SourceAddress, traffic)

10:01

191

15

10:02

142

18

10:03

206

60

10:04

217

72

• Category Transforms– Amplification of symptoms– Easier to correlate/interpret

Case(1): Only Addresses increases
Case(2): Only Octets increases
Case(3): There is a DoS attack?

Fig. 5.2.1.(2)-1:Category Transform

In Fig.5.2.1.(2)-1 the concept of Category transform is explained. The traditional traffic
octets measurement is shown in the upper graph. The corresponding traffic address based
C-transformed data is shown in the lower graph. In the segment labeled Case-1 there is no228- 230 -

significant variation in the traffic measurements but the number of addresses shows asignificant increase. This is a significant event and requires investigation. It may be due to ascan or due to some Winny-type application that is interacting with multiple peers. In thesegment labeled Case-2 the traffic increases but there is no significant increase in the numberof addresses. This is an often seen pattern, some large file download or DNS zone-transfer
application may be causing this. In the segment labeled Case-3 there a small increase intraffic but a very heavy increase in the number of addresses. This is the symptom that we
expect to see in the case of a distributed denial of service attack (DDoS). In all three cases it
is clear that the C-transform gives us a different view of the network dynamics. The
symptoms are amplified and are easier to correlate.
5.2.1.(2)-3 Diagnosing network events: Top-N technique
Having detected events, the network operator will generally want to diagnose the events.
In one of the primary modes of monitoring, traffic is monitored at the trunk routes. If the total
traffic or the traffic for a particular type protocol or application exceeds the threshold of what
can be considered to be normal, the operator’s attention is drawn to the event. In other words,
this is considered to be an event of interest and the operator must be notified of this event.
Once notified, the network operator would want to know the source of the traffic surge and,perhaps, the contents of the traffic surge.
We designed and developed a Top-N traffic analyzer. That works in conjunction with a
CpMonitor traffic probe. It analyzes the contents of the traffic to detect the source andcontents of the major traffic generators. The scenario is described in Fig.5.2.1.(2)-2. In an
organization there are two sites where, several, probably thousands of terminals are in use.
These terminals connect to the Internet via the Data Center. Two CpMonitor traffic probes
monitor the traffic interchange points between the sites and the Data Center. If a significant
surge in traffic is observed in the traffic an event is generated and the network operator isnotified.

229- 231 -

Terminal

Site-A

CpMonitor
Probe

Site-B

Data Center

ManagerInternet

Fig.5.2.1.(2)-2: Diagnosing Events using Top-N

The Top-N application allows the network operator to carry out the diagnosis online. The
operator can see the terminals that are the top N (N = 1..10) traffic generators or consumers.
Further for each terminal the network operator can see the content of the traffic by protocol(TCP, UDP, ICMP, other), and for each transport protocol (TCP/UDP) the operator can see the
top–N (N = 1..10) applications (ports) that are acting as source or sink of traffic. This enables
the operator to pin point the cause of the event
The logic of the Top-N application is as follows:i. Select CpMonitor and interface
ii. For the selected CpMonitor and interface get data for the following MOsiii. Show top ‘N’ rows from the data obtained from CpMonitor
iv. Show top ‘N’ records of the selected source (terminal) and protocol
The steps of operation are shown below
5.2.1.(2)-3.1

The Top-N application discovers the CpMonitors present in the domain of its

management and displays the list to the network operator.
The operator will select the appropriate CpMonitor and interface from the list and click on
the show button to see the results of the traffic analysis.

230- 232 -

Fig. 5.2.1.(2)-3: List of CpMonitors and Interfaces
5.2.1.(2)-3.2

The Top-N application gets the traffic details it fetches from the followingMOs

5.2.1.(2)-3.3•

cpmSnapStatsDescr.interfaceIndex•

cpmSnapStatsV4IpOctets.interfaceIndex•

cpmSnapStatsV4UdpOctets.interfaceIndex•

cpmSnapStatsV4TcpOctets.interfaceIndex•

cpmSnapStatsV4IcmpOctets.interfaceIndex•

cpmSnapStatsV4OtherOctets.interfaceIndex•

cpmApSnapStatsV4IpOctets.interfaceIndex•

cpmApSnapStatsV4UdpOctets.interfaceIndex•

cpmApSnapStatsV4TcpOctets.interfaceIndex•

cpmApSnapStatsV4IcmpOctets.interfaceIndex•

cpmApSnapStatsV4OtherOctets.interfaceIndex

The traffic details are sorted and the top N traffic handlers are detected anddisplayed. Note that N may be chosen by the user.

231- 233 -

Fig. 5.2.1.(2)-4: Top-3 traffic sources/consumers
If the user selects the detailed display option then the protocol contents of the traffic are
shown .

Fig. 5.2.1.(2)-5: Top-3 traffic sources/consumers with Protocol-wisedetails
The analysis results may be updated by clicking on the update button.

232- 234 -

Fig. 5.2.1.(2)-6: The tool bar with Update / Previous and Next
buttons.
The user can navigate through the history of analysis results by clicking on the Previous
and/or Next buttons. The currently displayed page number and the updated time are displayed
as and when Next or Previous button is clicked.
5.2.1.(2)-3.4

To see the application-wise distribution of the traffic for a certain source(terminal) and protocol (IP/TCP/UDP), the operator will select the source by clicking on thecorresponding row and then double click on the protocol column. Application-wise(Port-wise) traffic distribution in kbps is displayed for IP protocol.

Fig. 5.2.1.(2)-7: The application-wise distribution of IP traffic
Application-wise (Port-wise) traffic distribution in kbps is displayed for UDP protocol.

233- 235 -

Fig. 5.2.1.(2)-8: The application-wise distribution of UDP traffic

Similarly the port information for TCP and others can be obtained.
5.2.1.(2)-4 Event based management: Integrated Console for Events (ICE)In routine network monitoring, the interest is in events. If there are no events of interest,
the network manager will probably not want to "look" at the traffic. The traffic data in suchcases is destined for archiving. From there it will probably be backed-up on off-line media ordiscarded. Present monitoring systems do not have a mechanism of detecting events ofinterest. So it appears that the operator will either look at all the traffic to detect events ofinterest or will not look at the traffic at all. In our earlier work we defined events of interestin terms of changes in the statistics and the persistence of the change. These are the events
that a network operator will be primarily interested in. There may be micro-events e.g. a file,
web-page or mail transfer. There may be also macro-events e.g. an experimental session
between two points over which several micro-events or a data-streaming activity takes place.
A network fault may also be noticed as an event, where the traffic suddenly drops to zero, or
the RTT abruptly changes. The proposed event model makes it possible to mechanicallydetect such events of interest. Further, the traffic that caused the event is recorded andarchived for perusal by interested parties.
As an application of the event model we have developed an event based management
system. It is incorporated into an Integrated Console for Events (ICE) which is part of the
NetSkate series software packages for monitoring and managing networks.
NetSkate ICE displays a list of all events that have been detected in the network. The listof events is archived and can be searched/retrieved at any point of time. The outline of the
ICE module is given below

234- 236 -

Event Console
ExecuteEvent Notification

Get details of selected event

Manager
Event Listener
Event Log

Event.conf

Event

Fig. 5.2.1.(2)-9: Architecture of the Integrated Console for Events (ICE)
1. On receiving an event, the management module notifies the ICE about the event, andthe corresponding action and parameters. If the action mode is ON then the action is
executed at the console. The list of events is displayed on ICE.
2. Events can be selected from the event console and an action may be requested. The
console then carries out the corresponding action by interfacing with the management
module for relevant information and data.
5.2.1.(2)-4.1

List of events displayed on ICE.

If the operator or administrator is interested in a particular event, the operator will haveto select the event of interest and delve deeper into the event. Three possible actions are
possiblea.

Look at the progress of the event online (if the event is in progress)b.

Diagnose the traffic by using the Top-N application (if the event is inprogress)c.

Look at the traffic history of the event.

In the figure below an event is selected and the corresponding online and offline graph isdisplayed.

235- 237 -

Fig. 5.2.1.(2)-10: Events displayed on ICE
5.2.1.(2)-5 Summary
We have set out on this project to develop a model of events of interest which will use themonitored traffic data of the JGN-II network. To evaluate the model, we have developed a setof tools to aid the analysis of data, both online and offline. This model will be used to detect
events of interest. We will subsequently work on classifying the events as operational events,
security events, trouble events etc. Our final goal is to provide a wide spectrum of users withinformation on events of interest. The target for H17, developing new algorithms for
detecting events of interest and experimentation with real data to evaluate, has been met.

236
- 238 -

5.2.2 アプリケーション指向型運用管理技術とセキュリティ技術の開発- 5.2.2 章目次 –5.2.2.(1) 観測データとアプリケーション状態の収集・管理（運用・統計情報統合化システムの開発）
5.2.2.(2) 多地点間相互映像配信ネットワークの運用管理技術

5.2.2.(1) 観測データとアプリケーション状態の収集・管理（運用・統計
情報統合化システムの開発）
5.2.2.(1)-1 概要
運用・統計情報統合化システムは,映像配信ネットワークの運用時に,各拠点のオペレータ間でチャット・メイル等の文字コミュニケーションとして交わされる運用情報と SNMP で計測可能なネットワーク機器等の統計情報の両者を,時間軸に沿って関連付
け・提示するシステムである.図 5.2.2.(1)-1 のように各種情報を時間軸で関連付ける
ことにより.「ある現象が起きたときの前後の操作および状況」と「ある操作をしたときの状況の変化」を把握することが容易になるため,映像配信時の状況把握やトラブル
シューティングのツールとして有用である.
今年度の研究開発では,以下の 3 項目についてシステムの改良を行った.

ネットワーク状況??
Webチャット
メーリングリスト時間

図 5.2.2.(1)-1

時間軸による運用・統計情報の関連付け(1) 昨年度までに開発した運用・統計情報統合化システムでは,ネットワーク状況の統計値として,SNMP で容易に取得できるデータを取り扱ってきた.すなわち,レイヤ 1,2 では入出力ユニキャストパケット数やエラーで破棄されたバケット数,レ
イヤ 3 では無効なアドレスのパケット数や経路不明で破棄されたパケット数,レ
イヤ 4 では待機アプリケーションが不在である受信ポートへの受信データグラム
数などである.しかしながら,映像配信ネットワークにおいてもっとも重要である配信映像・音声の品質については,統計的なデータは一切計測されておらず,オ237- 239 -

ペレータ間での文字コミュニケーションによる報告に頼るのみであった.そこで,今年度の研究開発においては,受信地点での映像・音声の品質をアプリケーショ
ンレベルで定量的かつ定常的に計測する手法を検討し,実装した.
(2) 時間軸による運用・統計情報の関連付けは,関係する情報の一覧可読性において優れているが,映像配信ネットワークの規模拡大に伴う計測拠点の増加や,各計
測拠点での計測項目の増加により,従来のユーザインタフェースでは操作性や情報の一覧可読性が損なわれてしまった.そこで、必要な情報のみを選択・表示できるようユーザインタフェース部の改良を図った.同時に操作性に問題のあった
時間範囲指定のユーザインタフェースも改良した.
(3) 運用・統計情報統合化システムは,固定されたネットワーク構成を前提に構築・利用されてきたが,JGNⅡ上でしばしば行われるイベント中継では,その都度映像
配信ネットワークが構築され,かつ,イベント本番までの間にその構成に変更が生じることが多い.そこで,システムをネットワーク構成の時間変化にも対応できるようにするため,ネットワーク構成管理データベースを試作し,データベー
スから各種運用･統計情報を参照することで,シームレスな統計情報の可視化を実現した.
5.2.2.(1)-2 アプリケーションレベルでの計測技術の開発
5.2.2.(1)-2.1 アプリケーションプログラムの解析
映像配信に用いているアプリケーション DVTS は,受信側においては図 5.2.2.(1)-2のように UDP パケット受信プロセスと IEEE1394 パケット送信プロセスから構成されている.
1 つ目のプロセスでは映像パケットから DIF(Digital Interface Format)ブロックを取り出し,その種類を判断して共有メモリのフレームバッファに格納する.2 つ目のプロセスではフレームバッファから DIF ブロックを取り出し,IEEE1394 パケットにカプセル化する.
フレームバッファには 150 個の DIF ブロックがあり,図 5.2.2.(1)-3 に示すようにデータの種類ごとに適切な位置に格納される.このフレームバッファへの DIF ブロック
格納時に映像・音声の DIF ブロック損失率を計測することで,アプリケーションレベル
での映像・音声品質評価の基礎データが得られる.

238- 240 -

RTP/DVパケット
UDPパケット
受信プロセス

共有メモリ

IEEE1394パケット
送信プロセス

DV機器

H0
0
A0
6

SC0
1
V0
7

SC1
2
V1
8

VA0
3
V2
9

VA1
4
V3
10

VA2
5
V4
11

DIF block(80Byte)
V13
V14
20
21

A8
134

V120
135

V121
136

V122
137

V123
138

V124
139

V133
148

フレームバッファ0
フレームバッファ1
フレームバッファ2

配列(recvbuf)
判断
DIFブロック

フレームバッファ9

配列(outbuf)

図 5.2.2.(1)-2

受信側 DVTS の構造

H:headerSC:subcode

A:audio

V:video

図 5.2.2.(1)-3

V134
149

VA:VAUX

フレームバッファの構造

5.2.2.(1)-2.2 品質評価のためのデータ計測

図 5.2.2.(1)-4 パケットロスと損失フレーム
まず,フレーム毎に DIF ブロックの損失状況を計測した.1 フレームは 1500 個の DIF
ブロックで構成されるが,DIF ブロックが 1 つでも損失したフレームを損失フレームとし,その割合を計測した.図 5.2.2.(1)-４に従来計測していたパケットロスのグラフと今回計測した損失フレームのグラフを示す.パケットロスが比較的少ない状態でも損失フレームが多いことがわかる.
5.2.2.(1)-2.3 音声 DIF ブロック損失率と実際の音声品質の対応関係
DUMMYNET を利用したネットワークを構築し,音声 DIF ブロック損失率と実際の音声品質の対応関係を調査した（表 5.2.2.(1)-1）.この結果から図 5.2.2.(1)-5 のような音声品質の推定が可能となった.

239- 241 -

DIFブロック損失率 音声品質

図 5.2.2.(1)-5 損失率からの音声品質推定

0% － 1%ほぼ良好

1% － 10%

小さな雑音がする

10% － 40%

やや大きな雑音がする

40% － 70%

音声と雑音が同程度

70% － 100%

雑音にしか聞こえない

表 5.2.2.(1)-1 損失率と音声品質の対応

5.2.2.(1)-3 運用・統計情報統合化システムのユーザインタフェース改良
5.2.2.(1)-3.1 情報選択機能の実装
各計測拠点での計測項目の増加により,従来の単純なユーザインタフェースではデータの一覧可読性が得られなくなった.また,ユーザが必要な情報は配信実験の進行状
況やユーザの立場によって異なる.従って,大量のグラフ項目から閲覧者が必要なもののみを選択し,比較できるシステムが必要になる.

必要なグラフだけを見たい

閲覧者

図 5.2.2.(1)-6

情報選択機能の必要性

図 5.2.2.(1)-7

情報選択機能の概要

従来は 1 つのウィンドウに全ての情報を統合していたが,グラフの比較は様々なパターンで行われることが考えられるため,統計情報グラフ表示部をグラフ選択とグラフ比較の２つに分けた（図 5.2.2.(1)-7）.また,グラフ選択の方法として,どの機器の何の計測項目なのかを選択するツリー表示と,実際のグラフから選択するプレビュー表示を設けた.

240- 242 -

グラフ比較ウィンドウ

グラフ選択ウィンドウ
ツリー表示

プレビュー表示

図 5.2.2.(1)-8

情報選択機能を実装したユーザインタフェース

図 5.2.2.(1)-8 に情報選択機能を実装したシステムのユーザインタフェース画面を示す.グラフ選択ウィンドウのツリー表示ないしはプレビュー表示から選択された項目のグラフが,グラフ表示ウィンドウに描画される.選択されたグラフの表示順は矢印
アイコンを操作することで変更できる.また特定のグラフを一時的に非表示にすることも可能である.
5.2.2.(1)-3.2 時間範囲指定機能の操作性向上

直感的な時間範囲の絞りこみ

視覚的な時間範囲の移動

8
0

11
6

12
0

図 5.2.2.(1)-9

12

14
18

15
6

12

24

18
18

24

視覚的かつ直感的な操作による時間範囲指定

運用・統計情報統合化システムの特徴は,各種情報を時間軸で関連付けて表示するところにある.時間範囲の指定を視覚的かつ直感的な操作で行えるようにすれば,システ

241- 243 -

ムの操作性向上が期待できる.
そこで,現在表示されているグラフを基準にし,時間範囲を絞り込んでグラフを詳細に見たい場合はその時間範囲のドラッグ操作で,また時間範囲を前後に移動したい場
合はスライドバーの操作で,時間範囲の指定ができるように改良した.
5.2.2.(1)-4 ネットワーク構成等の時間変化への対応
5.2.2.(1)-4.1 映像配信ネットワークの時間変化
JGNⅡ上でイベント中継を行う場合,映像配信ネットワークの構築から実際の中継までのスケジュールは,概ね図 5.2.2.(1)-10 のようなものになる.従来,運用･統計情報
統合化システムが利用されてきたのは,配信ネットワークの構成が固まったあとの期間である.しかし,当システムの機能は,ネットワークの構築段階でこそ必要とされるものである.
ネットワーク構築段階では,図 5.2.2.(1)-11 に示すような段階的なネットワークの構築・テスト,設計変更やトラブル発生による機器や構成変更などが起こりうる.このようなネットワーク構成等の時間的な変化にも対応可能なシステムを実現するために,ータベースによるネットワーク構成管理と,データベース検索に基づく統計情報のシームレスな可視化方法について検討を行った.

拡張が要求される運用期間
設計期間

 メーリングリストの立ち上げ
 オペレータ間で配信実験に関する情報を交換 簡単なネットワーク
構成の設計

従来の運用期間

確認期間

 各拠点間で通信実験
 トラブルが起こると，トラブルシューティングに伴ってネットワーク
構成が変化

図 5.2.2.(1)-10

 ネットワーク構成が固定化
 従来はこの期間でのみシステムを運用

ネットワーク構成が時間的に変化する

ネットワーク構築スケジュール例242- 244 -

山形県庁

小金井

マシンの変更192.107.42.7
東北大192.107.42.10

役割の変更

IPアドレスの変更

Recv

図 5.2.2.(1)-11

Send

ネットワーク構成等の時間変化

5.2.2.(1)-4.2 統計情報のシームレスな可視化
ある特定の役割を持ったホストの IP アドレスが,ネットワークの設計変更により変更されたという例を取り上げる.運用･統計情報統合化システムでは,IP アドレスごとに統計情報を管理しているため,同一のホストであっても,IP アドレスが変更されると別ホストとして情報が管理されることになる.このため,IP アドレスが変更された
時間を跨いで当該ホストの統計情報を統合して可視化することはできず,２つのグラ
フを並べて見るほかなかった.
試作したネットワーク構成管理データベースは,図 5.2.2.(1)-13 に示す構造をもつ
RDB で,ホストのハードウエア構成,ホストに与えられるネットワーク設定,ホストの役割などが別テーブルとして管理されている.ある特定の役割を持ったホストの IP ア
ドレスが途中で変更された場合でも,このデータベースを検索することにより,分散した統計情報のデータリストを取得することができ,それをもとに統計情報を統合・可視化した単一のグラフを得ることができる.

時間軸

IPアドレスの
変更

変更前
……

統計情報
の分散

変更後

図 5.2.2.(1)-12

IP アドレス変更により生ずる問題

243- 245 -

図 5.2.2.(1)-13

ネットワーク構成管理 DB の構造

5.2.2.(1)-5 評価と今後の課題
従来より開発を行ってきた運用・統計情報統合化システムにおいて,(1) アプリケーションレベルでの計測技術の開発(2) 情報選択機能および時間範囲指定機能の実装(3) ネットワーク構成等の時間変化への対応の３項目について研究開発を行った.
(1)については,アプリケーション内での DIF ブロックの損失状況を計測することで,受信地での映像･音声の状態を定常的に把握することが可能となった.拠点オペレータ
からのメイル・チャットでの報告によらず受信状況が推測できるようになったことは,イベント中継等での映像配信ネットワークの運用コスト低減につながる.しかしながら,映像･音声の定量的な計測には至っておらずその手法確立が今後の課題となる.
(2)については,固定化されたネットワーク構成のもとでのシステム利用においては,必要とされる情報選択および時間範囲指定の機能が実装されたといえる.今後は(3)のネットワーク構成管理データベースとの連携において,ユーザインタフェースやデータ可視化の方法について検討する必要がある.
(3)については,現時点では簡単な例についての試作実験に留まっている.時間変化への対応が可能となれば,ネットワークの構築段階で経験する様々なトラブルとトラ
ブルシュートの状況を時系列で追えるようになり,運用知識の整理・蓄積のツールとしての利用も期待できる.データベースの基本設計をはじめ,各種検討が必要である.
運用・統計情報統合化システムの各種機能拡張がなされたが,全般的に実際のイベント中継等でのフィールドテストが十分ではない.今後,イベント中継等の機会があるごとにフィールドテストを重ね,実装した機能の検証を行う予定である.

244- 246 -

5.2.2.(2) 多地点間相互映像配信ネットワークの運用管理技術
5.2.2.(2)-1 概要
昨年度に引き続き，多地点間で効率的に相互利用可能な動画像配送ネットワークの実現を目標として，運用知識に基づく映像配信システムの開発を進めた．
本システムは，配信元からのストリームを受信し，さらに複数のストリームとして再配信可能な中継ノードと，それら全体を管理する管理ノードからなる．当システムの概要を図 5.2.2.(2)-1 に示す．中継ノードは，マルチキャストとユニキャストの変
換や IPv4 と IPv6 との変換といったプロトコル変換機能，帯域変動に応じた伝送レー
ト制御，映像確認のための映像出力，などを可能

Sとする．管理ノードは，時間，配信先，ポート番

NM

号，必要帯域，などといった放送情報の管理や，それらの情報に基づいて，各中継ノード同士の配JGNII

ラヒック，ロス値，ジッタなど）に応じて，動的にツリーの再構成なども行う．管理ノードの設定

SN

SN

送ツリーを決定し，各ノードに対して自動的に設定を行うことを可能とする．また，運用状況（ト

SN

SN

SN

県域ネットワークなど

SN

SN

は Web ブラウザを用いた，視覚的にも操作が容易な仕様とする．当システムにより，網全体での利用帯域の効率化や，運用管理負荷の低減が図れる．
5.2.2.(2)-2 背景

S: Sender
SN: Splitter Node
NM: Node Manager

図 5.2.2.(2)-1 システム概要

動画像配信技術の進歩やソフトウェアの充実によって，ネットワーク技術にあまり詳しくなくとも比較的簡単に動画像配送を行えるようになってきている．しかし，２地点間での利用は比較的容易でも，多地点への配送を考えた場合，配送方式（WMT，MPEG2/IP，DV/IP，etc.）の決定，配送先情報（必要帯域，IP アドレス，etc.）の取りまとめと管理，最適なネットワーク構成の検討（ユニキャスト・マルチキャスト，
配送ツリー，etc.），ネットワーク機器（ルータ，スイッチ，送受信ノード，etc.）の設定，導通テスト，仮運用，本番などといった一連の手順と，専門的な知識が必要であり，その作業工数も決して少なくない．また一方向配送に加えて双方向配送のニーズも高まっており，さらに作業工程が増え，作業内容も複雑となる．このようなことから，広く一般の利用を促進するためにも，より簡単に利用できる技術の開発が求められている．加えて，当システムを利用する上で既存の送受信用アプリケーションがそのまま利用できることも大事である．このため，既存の送受信用アプリケーション
について，新たな機能の追加や変更などは行わないことが前提となる．

245- 247 -

5.2.2.(2)-3 中継ノードの開発
当年度は，昨年度に引き続き中継ノード（スプリッタ）の開発に重点を置いた．配送方式は，JGNⅡでも利用が多く，比較的取り扱いの容易な DV ストリームを扱っていることから，DVTS を対象とした．
多地点へのストリーム伝送を考えるとき，ユニキャストは，データを伝送する受信側の数だけセッションが生成されるため，伝送されるデータ量は受信側の数に比例して増大する．また，同一のネットワーク経路を同一のデータが複数流れることもあり効率的でない．データを伝送できる受信側の数は送信側のホストの処理能力とネットワークの帯域に制限される．一方，マルチキャストは送信側と受信側の間の経路上の適切なルータでパケットの複製が行われるため，同一のデータが複数伝送されることはない．そのため，受信側の数が増えても伝送されるデータ量は増大しない．従って，同一のデータを複数の受信側へ伝送する場合にはマルチキャストが有効であるが，経路上の全てのルータがマルチキャストに対応していることが条件である．マルチキャ
ストを使用できるかどうかはネットワークの構成に依存する．現実的には，ネットワ
ークの状況に応じてこれらの伝送方式を使い分けることが望ましい．
IP ネットワークでは，経路上の混雑などの要因によって，パケットの到着時間の揺らぎ (ジッタ) やパケットロスが発生する．これらの影響により，映像や音声が正し
く表示，再生されないことやノイズが発生することがある．一般的には個々のルータやスイッチにおいて，ジッタの補正やパケットロスの補償を行うことは困難であり，
アプリケーションレベルによる対処が求められる．これについては，中継ノードにおいてジッタの補正や，パケットロス対策としての伝送レートの変更が可能となれば，映像品質の向上が期待できる．
映像伝送システムの中には，映像の送信側と受信側で個別に操作し動作するものがある．これには本研究で対象としている DVTS や Ruff などが該当する．その利用形態
としては，以下の 2 つのケースが考えられる．一つは，予め受信側がデータを受信できる状態で待機し，後から送信側がデータの送信を開始するもので，もう一つは，先に送信側がデータの送信を開始し，後から受信側がデータの受信を開始するものである．前者では受信側からデータの送信を開始できず，後者では受信側の都合の良い時に受信を開始できるが，受信を始めるまでの間，利用の無い無駄なトラヒックが流れる．また，受信側が停止して受信を終了しても送信が継続される．これらの問題は，受信側から送信側の動作を制御する機構があれば解決できる．

# dstnameipaddrport(ifname ttl)
rcv1
192.42.107.6
8000# To dv recver
split2 192.42.107.7
8000# To splitter no.2
rcv2
2001:218:479:1100:290:feff:fe21:3dde
8000
IPv6
v4mcast1 239.1.1.10
8000
bge0
64
lti
t

246
- 248 -## v4

図 5.2.2.(2)-3

設定ファイルの例

これらの問題点を踏まえ，加えて IPv6 環境への対応なども考慮して，以下を本シス
テムの満たすべき機能とした．
–

ストリームデータの中継–プロトコル変換（IPv4 と IPv6 の変換，ユニキャストとマルチキャストの変換）–

中継ノード間での情報交換–

ジッタの補正–伝送レートの動的変更–

受信ノードからの指示に基づく伝送（開始，終了）の制御

各ノードの機能と連携の概要を図5.2.2.(2)-2 に示す．送信ノードと受信ノードは既存システムをそのまま利用可能とする．中継ノードは送信側からは１つの受信ノードに，受信側からは１つの送信ノードとして認識され，必要に応じて多段接続が可能である．中継ノード間の情報交換は，RFC1889 において規定される
RTCP（RTP Control Protocol）による．DVTS においても送受信間でのパケットロス情報の伝達のために
RTCP が実装されているため，親和性も良い．下流ノードの情報（動作・非動作，ジッタ，パケットロス，RTTなど）は，RTCP により交換する．プ

図 5.2.2.(2)-2

各ノードの機能と連携概要

ロトタイプ実装では，まだ管理ノードが存在しないため，中継ノードの動作設定を設定ファイルに予め記述する．設定ファイルの例を図 5.2.2.(2)-3 に示す．
設定ファイルでは，中継先の名前（任意の文字列），IP アドレス，ポート番号を記述する．また，マルチキャストの場合には，インタフェース名と TTL（IPv4 の場合）も加える．中継ノードがマルチキャストを受信する場合には，プログラム起動時のオプションとして，”–j multicast_address”を指定する．
5.2.2.(2)-4 評価
現在までに，ストリームデータの中継，プロトコル変換，中継ノード間での情報交247- 249 -

換，ジッタの補正の各機能について，α版の実装を完了している．評価については，
実験室における基礎的な動作確認実験に加え，JGNⅡ上に構築した実験網や，イベントを利用した実証実験により行っている．実験網としては，地域間広帯域コンテンツ流
通基盤実験（JGN2-A16028）と CATV コンテンツ流通実験(JGN2-A17007)があり，イベン
トにおいても活用されている．それぞれの詳細については，末章にて述べる．本年度，
イベントを利用した実証実験は以下のとおりである．
ＩＣＴ推進フェア2005 in東北（2005.5）
仙台七夕前夜祭花火中継（2005.8）
東北大学サイエンスカフェ特番中継（2005.10）
みちのくYOSAKOI中継（2005.10）
JGNⅡシンポジウムin仙台（2006.1）
東北大学学位記授与式中継（2006.3）
いずれのイベントにおいても大きな障害は発生せず，極めて良好な結果を得た．こ
こではＩＣＴ推進フェア 2005 in 東北と東北大学学位記授与式中継について述べる．
ＩＣＴ推進フェア 2005 in 東北では，会場である仙台メディアテークと JGNⅡ東北-1 アクセスポイント間を地元 CATV（仙台 CAT-V）の光幹線等を利用して接続し，会場から直接全国の１１拠点に対して本システムを用いた IPv4 ユニキャストによる配信を行った．受信側は DVTS（WindowsXP および FreeBSD）もしくは DVcommXP（WindowsXP）であった．イベントなので実際の視聴者がいることと，このとき用いた中継ノード機の性能（Celeron2.0GHz）を考慮し，安全を見越して中継ノードを４台として分散配送した．それぞれ各拠点からの報告によれば，パケットロスも全体的に 1％未満であり良好に視聴できた．原因は不明であるが，つくば RC では２日間を通じてブロックノイ
ズがときどき見られたようである．
東北大学学位記授与式中継においては，東北大学キャンパス内の 5 拠点（青葉山北，
青葉山南，川内，星陵，片平）に中継ノードを分散配備し，会場である仙台市体育館
からの映像を仙台 CAT-V で Ruff および DVTS により東北大学情報シナジーセンタへ送った．そこから各中継ノードに対しては，IPv4 ユニキャストで送り，中継ノードから先は IPv4 マルチキャストによる配送を実施した．このような配送形態をとることで，必要な拠点にのみユニキャストでストリームデータを配送して，学内の全てのルータ
がマルチキャスト処理に追われることを防いだ。また，マルチキャストに対応していないルータをもつ拠点においても，本中継ノードを設置するだけで比較的簡単にマルチキャストによる受信が可能となることを実証した．
5.2.2.(2)-5 今後の予定
来年度においては，中継ノードにおける伝送レートの動的変更，受信ノードからの指示に基づく伝送の制御についての実装を進める．また，管理ノードの設計について

248- 250 -

も行ってゆく．

249- 251 -

5.2.3 フレキシブルネットワークミドルウェア技術の開発- 5.2.3 章目次 5.2.3.(1) エージェント型ネットワークミドルウェアのアーキテクチャの検討

5.2.3.(1) エージェント型ネットワークミドルウェアのアーキテクチャの検討
JGNⅡの超高速ネットワーク上で稼動するアプリケーションを支えるミドルウェア
として，フレキシブルネットワークミドルウェア技術の開発を目標に，本年度は，高速広域ネットワーク向けマルチキャストツリー構成法の検討を行った．検討の結果，探索範囲の段階的拡大によって，完全グラフを使用可能にすると同時に，探索時間の短縮化を行う新しい高速広域ネットワーク向けマルチキャストツリー構成法を確立した．さらに，提案手法に基づいたシミュレータの設計と実装を行い，実装したシミュ
レータを用いたシミュレーションを通じ，メディアデータの送信帯域の大容量化と許容遅延以内の ALM ツリーの構築，および探索時間の短縮化が可能となることを示した．
5.2.3.(1)-1 高速広域ネットワーク向けマルチキャストツリー構成法
JGNⅡの超高速ネットワーク上で稼動するアプリケーションとして利用が期待される例として，ビデオ会議のような多人数参加型マルチメディアコミュニケーションが挙げられる．多人数参加型コミュニケーションでは，多数のユニキャストストリームが存在する．そのため，基幹ネットワークに比べアクセスネットワークの帯域が狭い
一般的なホストでは，各ストリームに対し少量の帯域しか割当てることができない．
また，各ストリーム毎に異なる帯域を割当てることが必要である．この 2 つの課題に対 す る 解 決 策 と し て ， ア プ リ ケ ー シ ョ ン レ ベ ル マ ル チ キ ャ ス ト(Application Level
Multicast：ALM)が挙げられる．ALM とは，受信端末が受信しているデータを複製し別端末へと中継する方式である．しかしながら，ALM を使うことで送信ホスト–受信ホス
ト間の遅延が大きくなるというデメリットがある．一方マルチメディア通信を行う場
合，一般に許容遅延が存在する(約 200msec)．特に ALM においては，受信端末により繰り返し中継を行うため，遅延が大きくなる傾向がある．そこで，遅延を許容遅延以内保ちつつ ALM 配信ツリーを構築する手法の確立が必要となる．本研究では，ALM を用いてメディアデータの送信帯域の大容量化を行い，同時に多人数参加型コミュニケーションにおける許容範囲内の遅延を実現するための ALM ツリー構築手法を提案する．

250- 252 -

5.2.3.(1)-2 アプリケーションレベルマルチキャスト
実際に ALM を用いる場合，あらかじめ ALM に参加する端末のみでアプリケーション
レベルのネットワーク(アプリケーションレベルネットワーク)を形成し，そのネットワーク上の仮想リンクを用いてデータを送信する．この時，データが流れるパスのことを，ALM ツリーと呼ぶ．ALM ツリーを構築するためにはパスを探索する必要があるが，その探索はグラフ問題として解くことができる．端末をノード，アプリケーションレ
ベルネットワーク上の仮想リンクをエッジとして，ノード集合を V，エッジの集合を E，
アプリケーションレベルネットワーク全体を 1 つのグラフ G とすると，
G=(V,E)と表すことができる．グラフ化することで，アプリケーションレベルネットワークをIP 層等の下位レイヤから切り離して考えることができる．なお，本研究ではエッジのコストとして帯域と遅延を扱い，これらのコストの値は与えられているものとする．

30

30

50

送信ノード

10
30

30
50

次の要求先ノード

要求を満たすパスが存在
End
10
30

30
50

ALMツリー構築
図. 5.2.3-1 探索範囲の段階的拡大法の概要

251- 253 -

Ｓｔｅｐ．１へ

遅延

50

10

Step.2
受信ノードは探索範囲を拡大

パスが見つからない

30

探索開始

Start
受信ノード
10
30

Step.1
受信ノードは最も遅延の短いノードにツリー構築を要求

5.2.3.(1)-3 探索範囲の段階的拡大手法の提案
要求を満たすパス，すなわち許容遅延を満たすパスを発見するには，アプリ
ケーションレベルネットワークのモデルとして全てのノードが互いに結ばれた完全グラフを扱うことが有効だが，探索時間が非常に長くなるというデメリッ
トが存在する．そこで，本研究では探索範囲の段階的拡大によりパス候補を探索する手法を提案する．これは，まず許容遅延を満たす可能性の高い候補(範囲)から探索を開始していき，探索目標(帯域・遅延)を満たすパスを発見できた時点で探索を終了するというものである(図 1.1.3-1)．探索範囲の段階的拡大手法によって，現実的な時間内で完全グラフを利用した探索を完了することが可能になる．
5.2.3.(1)-4 シミュレーションおよび評価提案手法を実装したシミュレータを用いてシミュレーションを行い，提案手法の有効性を評価した．シミュレーション内容は，参加ノード数を変化させてそれぞれのノード数について１００回ランダムにツリー構築要求を行い，それに従い構築さ れた
ALM ツリーの要求の達成具合，遅延，探索時間を調べた．パラメータは以下の通りである．
・ 参加ノード数: 20，30，40，50
・ 要求帯域： (0Mbps,5Mbps)の範囲でランダムに与える．
・ 許容遅延： 150msec とする

図 5.2.3-2 にユニキャスト手法と提案手法との要求失敗数の比較を，図 5.2.3-3 に
全範囲探索と提案手法との平均探索時間の比較を示す．シミュレーション結果から，提案手法は従来のユニキャスト手法に比べ，ALM ツリーの消費帯域を大容量化することが分かった．特に，図 5.2.3-2 より提案手法は要求失敗数を大きく減少させることができる．また，構築された全ての ALM ツリーが許容遅延以内の遅延を実現していることも分かった．さらに，図 5.2.3-3 より，提案である探索範囲の段階的拡大手法を用いることにより全範囲を探索した場合に比べ探索時間が大きく短縮されることも分かった．以上の結果から，多人数参加型コミュニケーションにおいて，提案手法により許容遅延を満たす ALM ツリーを実時間で構築できることが検証された．

252- 254 -

70

Unicast
Proposal

Number of requests

60
50
40
30
20
10
0

0

図 5.2.3-2

10
20
30
40
Number of participating hosts

50

ユニキャスト手法と提案手法との要求失敗数の比較

200

Max
ProposalTime of search (sec)

150

100

50

0

0

10
20
30
40
Number of participating hosts50

図 5.2.3-3 全範囲探索と提案手法との平均探索時間の比較

253- 255 -

5.2.3.(1)-5 フレキシブルネットワークミドルウェア技術の開発のまとめ
JGNⅡの超高速ネットワーク上で稼動するアプリケーションを支えるミドルウェアとして，フレキシブルネットワークミドルウェア技術の開発を目標に，ALM を用いてメ
ディアデータの送信帯域の大容量化を行い，同時に多人数参加型コミュニケーションにおいて遅延を許容範囲内する新しい高速広域ネットワーク向けマルチキャストツリ
ー構成法を提案し，提案方式を詳述した．さらに，提案手法に基づいたシミュレータの設計と実装を行い，実装したシミュレータを用いたシミュレーションを通じ，メディアデータの送信帯域の大容量化と許容遅延以内の ALM ツリーの構築，および探索時
間の短縮化が可能となることを示した．

254- 256 -

5.2.4

東北ＲＣ

平成 17 年度分

業績リスト

[1]長尾真宏, 北形元, 菅沼拓夫, 白鳥則郎, ``差分フィルタを用いたトラフィック
解析とログマイニングによるネットワークイベントの自動判断'', 情報処理学会
研究報告, 2005-DPS-123, pp.19-24, Jun. 2005.
[2]長尾真宏, 北形元, 菅沼拓夫, 白鳥則郎, ``Summarized Network Event Detection
based on Multiple Traffic Monitoring'', 電気関係学会東北支部連合大会講演
論文集, pp.4, Aug. 2005.
[3]長尾真宏, 北形元, 菅沼拓夫, 白鳥則郎, ``トラフィック検出とログマイニングに よ る ネ ッ ト ワ ー ク イ ベ ン ト の 自 動 要 約 '', 電 子 情 報 通 信 学 会 技 術 研 究 報 告 ,IN2005-70, pp.55-60, Sep. 2005.
[4]長尾真宏, 北形元, 菅沼拓夫, グレン マンスフィールド, 白鳥則郎, ``トラフィックの異常検出システムにおけるアプリケーションログのクラスタリング手法'',
第 2 回先端的ネットワーク&コンピューティングテクノロジーワークショップ予稿集, pp.4-9, Oct. 2005.
[5]長尾真宏, 北形元, 菅沼拓夫, グレン マンスフィールド, 白鳥則郎, ``ネットワ
ーク異常検出システムのためのログ要約手法'', 第 3 回先端的ネットワーク&コン
ピューティングテクノロジ ワークショップ, Feb. 2006.
[6]Glenn Mansfield Keeni， Masahiro Nagao and Norio Shiratori, ``Event BasedManagement'', 第 3 回先端的ネットワーク&コンピューティングテクノロジ ワー
クショップ, Feb. 2006.
[7]高橋友和,脇山俊一郎：DVTS のプロセス解析に基づく配信映像・音声の品質評価手法,平成 17 年度電気関係学会東北支部連合大会講演論文集,pp.165(2005.8)[8]相澤裕千,脇山俊一郎：時間的な変化を追跡できるネットワーク構成管理データベースの開発,平成 18 年東北地区若手研究者研究発表会講演資料,pp.1-2(2006.2)[9]鶴田えりか,脇山俊一郎：映像配信ネットワークの運用･統計情報統合化システムにおけるユーザビリティの向上,平成 18 年東北地区若手研究者研究発表会講演 資料,pp.3-4(2006.2)[10]高橋友和,安孫子一敏,脇山俊一郎：DVTS 映像配信における映像・音程の品質評価
手法－データ提示方法の検討と多様な受信環境への対応－,平成 18 年東北地区若手研究者研究発表会講演資料,pp.7-8(2006.2)[11]高橋友和,脇山俊一郎：DVTS 映像配信における映像・音程の品質評価手法－プ

ロセス解析に基づく計測と評価－,第 3 回先端的ネットワーク＆コンピューティン
グテクノロジワークショップ(2006.2)[12]林優一，高橋輝樹,農人聡，菅野浩徳，曽根秀昭：“ RingServer 群のログ集約と利用状況の解析” ，日本学術振興会インターネット技術第 163 委員会(ITRC)第 17255- 257 -

回研究会

(2005.5)[13]櫻井健一，菅野浩徳：“DV/IP 多地点配信システムの設計と実装”，平成 17 年度電気関係学会東北支部連合大会講演論文集,1E10,p.166(2005.8)[14]佐藤彰洋，菅野浩徳：“スループットを指標とした動的レート制御手法”，平成 17
年度電気関係学会東北支部連合大会講演論文集,1E11,p.167(2005.8)[15]佐藤彰洋，菅野浩徳：“映像配信における実効帯域幅を指標とした伝送レート制御に関する一考察”，日本学術振興会インターネット技術第 163 委員会(ITRC)第２回
先 端 的 ネ ッ ト ワ ー ク ＆ コ ン ピ ュ ー テ ィ ン グ テ ク ノ ロ ジ ワ ー ク シ ョ ッ プ ,ITRC
Technical Report No.37,pp.24-31(2005.10)[16]佐藤彰洋，菅野浩徳：“実効帯域幅を指標とした DV/IP ストリーム伝送レート制御
方式”，日本学術振興会インターネット技術第 163 委員会(ITRC)第３回先端的ネッ
トワーク＆コンピューティングテクノロジワークショップ (2006.2)[17]櫻井健一，菅野浩徳：“多地点配送型 DV/IP システムの開発”，日本学術振興会イ
ンターネット技術第 163 委員会(ITRC)第３回先端的ネットワーク＆コンピューティングテクノロジワークショップ (2006.2)[18]菅野浩徳，曽根秀昭：“広域分散 FTP サービスへのデマンド型配送方式の適用と評価”，情報処理学会論文誌 Vol.47 No.4

(2006.4)

掲載決定[19]長谷川大介，高野健一郎，北形元，菅沼拓夫，白鳥則郎, "多対多ビデオ会議シス
テ ム の た め の ア プ リ ケ ー シ ョ ン マ ル チ キ ャ ス ト ツ リ ー 構 成 手 法 の 提 案 と 実 装 ,"情報処理学会研究報告, DPS 研究会 2005-DPS-123, Vol.2005, No.58, pp.41-46,
2005.6.2-3, 宮城県黒川郡.
[20]長谷川大介，高野健一郎，長田俊明，北形元，菅沼拓夫，白鳥則郎, "多人数参加型リアルタイム通信における参加者毎の品質要求に応じた資源割当と中継ツリー
構築手法," 電子情報通信学会技術研究報告書, Vol.105.No.279, 情報ネットワー
ク研究会 IN2005-84, pp.137-142, 2005.9.15-16, 宮城県仙台市.
修士学位論文取得(指導)[21]長尾真宏，「ネットワークトラフィックの異常検出における異常内容の識別」，東北大学大学院情報科学研究科修士学位論文
博士学位論文取得(専攻研究員)[22]Hisanori Masuda, “A Study of Visual Search Based on User's Cognitive
Characteristics in Visual Communication Environment,” Doctoral Thesis,
Univeristy of Yamanashi, March 2006.

256- 258 -

５．３

サラウンディング・コンピューティング技術の研究開発

ユビキタス環境では，データを集約する必然性はそもそもなく分散処理することが自然である．そこで本研究開発では，ネットワークや端末の機能を意識せずにネット
ワーク上の計算資源や DB 資源を自由に活用できる進化するユビキタス環境である，
サラウンディング・コンピューティング環境の確立を目指す．
情報ネットワークを介して転送される情報をより有益なものにするには，あらゆる情報の有機的な連携や分散している情報の自動配信処理が求められるため，サラウン
ディング・コンピューティング環境で提供される情報への高度な価値の付与とその情報を転送・提示するための技術を開発する．更に，多様な価値を付与された情報を転送するためには，送信するデータの種類や用いる通信媒体，その他外的要因によらず
リアルタイムでの送受信や再現を可能にすることが求められる．そこで，高速・高効率符号化処理，画像・音声情報など多種多様な情報を統合的に再現するための信号処
理システムの研究開発を行う．
本節では，これらの目的を達成するための基礎として，まず，サラウンディング・コンピューティング環境での柔軟な伝送処理を実現するための，データ駆動型プロセッサを用いたネットワーク・プロセッシングについて示す．また，JGNⅡなどの超高速・大容量ネットワーク上では大量の情報が転送されているが，いつでもどこでも，といったユビキタス環境での情報提示のためには，ユビキタス端末での情報再現を可能にする情報提示方式が必要である．そこで，音響空間をユビキタス端末でも効果的に再現できる方式と，その方式に適した信号処理アルゴリズムを提案する．
5.3.1

DDNP を用いたネットワーク・プロセッシング

近年，ネットワークの伝送速度の劇的な向上と，モバイル端末の性能向上に伴い，
モバイル・コンピューティングが急激に普及している．さらに将来は，ユーザの周囲に偏在する，モバイル端末，情報家電，センサー等の多くのネットワーク接続可能な機器が相互に協調動作し，ユーザの移動に追従して，周辺環境に応じてダイナミッ
クにネットワークを形成することでより能動的なコンピューティング環境が実現するだろう[9][10]．そこで，エンド端末のプロトコル処理，通信品質保証(QoS) 制御，ユーザ認証，セキュリティ制御などを担うネットワークプロセッサ(NP) として，低消費電力で，かつ，ソフトウェア実現が可能なデータ駆動アーキテクチャ[11] によるデータ駆動型ネットワークプロセッサ(DDNP) を検討している．本研究では，ネットワ
ーク内の QoS 制御やセキュリティ制御を中央集約的に制御することが困難なネット
ワーク環境において，各端末が送受信するパケットストリームを検査し，選択的にフィルタリングする機構に着目し，レイヤ 3/4 ヘッダ情報とフィルタリング条件の照合を高速に行うパイプライン並列パケット分類方式を提案する．さらに，ネットワーク
エンドにおけるヘッダ情報の傾向からフィルタリングルールを最適化する．また，本257- 259 -

提案方式の DDNP 向け実現法を延べ，フィルタリング性能および回路規模を示す．
5.3.1.1

パケットフィルタリングとデータ駆動型ネットワークプロセッサ:DDNP

パケットフィルタリングには，パケットのヘッダ情報を基に静的にパケット分類するものと，パケットフローの相互関係よりフロー特性を求めフィルタリングするもの，
パケットが保持するコンテンツによってフィルタリングするものがある．いずれも，
フィルタリングアルゴリズムのためのデータの構造化と，メモリアクセス回数がフィルタリング性能に大きく影響する．レイヤ 3/4 の静的パケットフィルタリングは，パケット分類アルゴリズムによってフィルタリングルールとパケットのヘッダ情報を照合し，一致するものにより通過／廃棄などを決定する．現在のコア／エッジノード向けネットワーク装置の多くは，パケットフィルタリングに TCAM(Ternary Content
Addressable Memory) を用いて，メモリアクセス回数を O(1) に限定し高速化を図っている．しかし，CAM は単位面積当たりの電力消費が大きく，また，エンコード用
付加回路が必要なことから，ハードウェア資源の限られたモバイル端末では，NP と汎用メモリによるソフトウェア実現が望ましい．本研究で検討している DDNP は，
自己同期型パイプラインにより自然なパイプライン並列化と極少電力化が期待できる．
また，データ駆動原理に基づいておりプロセッサ間の協調制御の必要がないため，モ
バイル端末のハードウェア資源に応じてスケーラビリティを確保できる．本プロセッ
サによるパケットフィルタリング機構のソフトウェア実現には，(1) スループット向
上のボトルネックとなるメモリアクセス数の削減と，スループットとトレードオフの関係にあるメモリ使用量の削減を実現するパケット分類方式の検討，および(2) メモ
リアクセスのサイクル時間を実効的に短縮できる特徴命令，ないしプロセッサ構成の検討が必要である．
5.3.1.2

パイプライン並列パケット分類方式

レイヤ 3/4 静的パケットフィルタリングは，入力パケットのヘッダやペイロードの中のいくつかの情報(フィールド) を，フィルタリングルール中の条件(入力パケット
中の複数のフィールドに対する照合規則) と照合し，照合結果に基づいて必要なパケット操作を決定するパケット分類により実現される．以下に提案方式を示す．
（１）ルール照合法
パケット分類のための，条件(入力パケット中の複数のフィールドに対する照合規則) には，完全一致だけではなく，プレフィックス一致，範囲一致がある． n 個のフィールドを対象とした( n 次元) パケット分類では，ルールセットの大規模化に伴い計算量が激増する．そこで，完全一致や範囲一致をプレフィックス一致で代替し，最長一致検索によるプレフィックス一致照合に統一し計算量を削減するとともに，検索処
理時のボトルネックとなるメモリアクセス遅延を隠蔽するために各フィールドの照合

258- 260 -

処理を流れ作業的にパイプライン並列に順次実行する方式を提案した[1][4]．

図 5.3.1

パケット分類処理のパイプライン並列化

図 5.3.2

パケット分類処理の分類木構造（２）LC-Trie 木によるメモリアクセス削減
最長一致検索アルゴリズムとして，メモリアクセス数の極小化による検索遅延の削減，かつパイプライン並列化が容易な LC(Level Compress)-Trie 木構造[13] を用いた．
LC-Trie は各ノードが 2 k の子ノードを保持する一種の MultiWay ツリー構造をとることでツリーを深さ方向にさらに圧縮する方式であり，検索木の深さは検索エントリ

259- 261 -

数に対し O (log log n ) で増加するという特徴を持つ．これより得られた LC-Trie は平均深度を削減でき，ツリー検索に必要なメモリアクセス回数の削減およびメモリ使用量の削減が望める．LC-Trie 木を用いた最長一致検索手法は，(a)LC-Trie 木検索，(b)プレフィックス検査の処理からなり，それぞれにメモリアクセスが発生する．そこで，
図 5.3.1 に示すとおり，各処理で発生する 1 メモリアクセスを 1 ステージとし，LC-Trie
木検索，およびプレフィックス検査を各 5 ステージに展開し，各ステージの処理が完了し次第，次ステージに移行するようパイプラインを構成した．
（３）LC-Trie 木の分散
LC-Trie 木構造を用いた検索アルゴリズムのパイプライン並列化によりメモリアクセス遅延時間の隠蔽が可能となった．しかし，パケット分類のためのフィルタセットの大規模化に伴って，フィルタに偏りがあると，検索木が不均質になる．そこで，各フィルタ条件の先頭数ビットを基に検索木を分割する手法[14]を導入した．これにより，サブツリーおよび各次元のバランスを改善できる．分割された検索木は，Index
Jump 部とツリー検索部の 2 つのモジュールで構成され，ツリー検索部は,LC-Trie 検索部と Prefix 検査部から成る(図 5.3.2)．Index Jump に使用されるアドレスは図 5.3.3に示すように, 各フィールドの先頭 x ビットを取り出し, これらのビットを連結した値であり，平均的に分散したルールセットの場合，検索木は選択ビット数にかかわらず，Index Jump テーブルにほぼ均等に割り当てられる．

図 5.3.3
表 5.3.1

Index Jump に用いる Index 生成法

フィルタリングルールセットのメモリ使用量とメモリアクセス回数260- 262 -

5.3.1.3

フィルタリングルールの最適化

エッジノードや企業ネットワーク，ローカルネットワークにおけるフィルタリング
ルール数はおよそ数 10 から 2000 程度であることが分かっている[12]．そして，使用されるフィルタリングルールセットの平均的な傾向は，(a) プレフィックス長が 0，21，23，24，25，28，30，32，(b)IP アドレスの約半分がワイルドカードである，(c)ルールセットの約 5%のポート番号が範囲指定である，(d) トランスポート層フィール
ドの約 90%が 1～4 個の IP アドレスフィールドに重複している．このことから，まず送信元/宛先 IP アドレスのペアに対するルール照合を行い，そのあと，ポート番号のルール照合を行うようにした．このとき，必要なメモリ使用量，およびメモリアクセ
ス回数を評価した．その結果，表 5.3.1 に示すメモリ使用量とメモリアクセス回数が得られた．ファイアウォールの平均的なルール数は 150 前後であることから，約 8K
バイトのメモリ領域があれば十分格納できることが判った．
5.3.1.4

DDNP による実現法

ここでは，提案パケットフィルタリング方式の DDNP による実現方を示す．そして，
DDNP アーキテクチャの回路規模および性能評価をハードウェアレベルで行うため，
FPGA に最長一致検索用の複合命令 SearchTrie 命令と CheckPrefix 命令，ならびに各種テーブルメモリアクセス命令を含む命令セットを備えた nPE を実装した性能評
価システムの構成を示す．
（１）特徴命令
メモリアクセス回数の削減，およびパイプライン並列による性能向上を達成するた
めに，平均メモリアクセス回数の少ない LC-Trie 法を採用した．そして，木検索の計算処理にかかる遅延をメモリアクセス遅延に漸近させるため，LC-Trie 木の 1 レベル分の検索を行うための特徴命令である SearchTrie と，SearchTrie 命令によって得られたプレフィックスの正当性を検査し，次処理へのポインタを出力する命令で あるCheckPrefix を提案した．これにより，プログラム中の命令数を極小化し，自然な木
検索アルゴリズムを表現可能とするとともに，検索遅延のメモリアクセスレートへの漸近をはかった．また，両命令は，IPv4 用と IPv6 用の 2 組の命令を用意した．
（２）プロセッサ構成
本命令を実現するナノプロセッサとして，(a) 必要最低限のハードウェア追加により追加命令を実現でき，既存の命令セットも実行可能なこと，(b) メモリアクセスの並列パイプライン化によって，メモリアクセス遅延を隠蔽できること，および(c) ルールセットの分布に応じて，最適なプログラム，およびメモリ割当てを柔軟に設定可能であるという用件を満たすように設計した．
（３）パケットフィルタリングソフトウェア
パケットフィルタリング用のデータ駆動プログラムは，Index Jump 部および Field

261- 263 -

Classification 部からなる．入力フィールドより，まず Index Jump テーブルのアク
セスポインタを得るための Index 計算を行う．Index 計算は単純なビット演算命令の組み合わせにより表現される．その後，フィールド数 n に応じて，SearchTrie 命令および CheckPrefix 命令を用いた最長一致検索処理を n 回行う．図 5.3.4 は，１段の完全一致検索と，3 段の LC-trie 検索からなるレイヤ 4 パケットフィルタリングを行う
ソフトウェアである．
5.3.1.5

性能評価

パケットフィルタリング機構を含む，DDNP アーキテクチャの回路規模および性能評
価をハードウェアレベルで行うため，DDNP 用評価ボード(図 5.3.5) を試作した．本
ボードは，信号処理用 32bit データ駆動型プロセッサ，および FPGA チップを搭載し，完全な自己同期パイプラインを形成し，32bit データ駆動型プロセッサの動作性能に対して等価的にスケーリングして FPGA に回路実装すれば，測定結果がそのまま比例換算可能となる．以下に，本評価ボードを用いた提案方式実装のための回路規模評価，
およびフィルタリング性能評価について述べる．

図 5.3.4

レイヤ 4 パケットフィルタリングソフトウェア

262- 264 -

USB2.0 I/F

FPGA

32bit DDMP
DVI I/F
図 5.3.5

DDNP 用評価ボード（１）回路規模評価
最長一致検索のための特徴命令を FPGA 上に実装したときに必要な回路規模を試算した．論理合成に Menter Graphics 社の Leonard Spectrum を用い，前述の FPGA
をターゲットとしてゲートレベルの回路規模を見積もった．なお，論理合成ツールが出力するデータは FPGA の論理セル数となるため，これを論理セル辺りの使用ゲート数を基に換算した（表 5.3.2）．これより，約 6%程度のゲート数増加で IPv4 用の回路拡張で構成可能であることが分かった．さらに，IPv6 用回路は IPv4 用回路に高々1.4%のゲート数増加で拡張可能であることが明らかとなった．
（２）フィルタリング性能評価
まず，Mae West のルーティングテーブルを用いた IPv4，IPv6 のルーティングテーブル検索より，最長一致検索機構の性能を評価した結果，平均的な IPv4 パケット
(2000bit) の場合 96G bit/sec，IPv6 パケットの場合 54G bit/sec の性能を達成できる
ことがわかった．次に，4 次元のルールセットを用いたパケット分類を評価したところ，ルールセットをバランス良く分割すると，約 24G bit/sec 程度の IPv4 パケットス
トリームを分類可能なことが判った．そして，パーソナルゲートウェイ向けにフィル
タリングルールを最適化したときの処理速度は図 5.3.6 に示す結果を得た．オンチッ
プ メ モ リ を 使 用 す る と 1 プ ロ セ ッ サ で 平 均 3.8M packet/sec ， 最 悪 で も 約 3M
packet/sec の処理を達成できることが分かった．これは，TCP パケットの最小サイズ
である 64 バイトのパケットストリームを受けた場合，約 1.5G bit/sec を達成できることを示す．

263- 265 -

表 5.3.2

機能拡張に伴うゲート数，および増加数

図 5.3.6
5.3.1.6

処理速度

まとめ

本研究では，端末に流入／から流出するパケットをパイプライン並列に高速処理するパケットフィルタリング機構として，LC-Trie 検索木構造を用いたパイプライン並列パケット分類方式を提案した．さらに，フィルタリングルールの傾向を基にパケットの照合順序を決定し，照合データを縮退することで，DDNP の 1 プロセッサが保持する内部メモリに格納できることが判った．そして，DDNP により実現する方法を示した．評価ボードを用いた提案方式の性能性能評価および回路規模評価により，大規模フィルタリングルールにおいて，10 プロセッサで 24G bit/sec の性能を達成し，パーソナルゲートウェイ向けのパケットフィルタリングにおいて，1 プロセッサで 1.5G
bit/sec を達成できることを明らかにした．また，特徴命令の追加による回路規模の増
加は，IPv4 用で高々6%であった．さらに，IPv6 用回路は IPv4 用回路に約 1.4%程度のゲート数増加で拡張できることが判った．今後の課題として，本研究にて提案した
機構，およびパケットインスペクション，コンテンツフィルタリングなどの動的フィルタリング機構を包括的に実装し，その性能評価を行う必要がある．

264- 266 -

参考文献
[1] D.Morikawa, M.Iwata, H.Hayashi, and H.Terada,“Superpipelined IP-Address
Lookups on a Data-Driven Network Processor,” in Proc. of Int. Conf.on Paralleland Distributed Computing and Systems,pp.431-436, Aug. 2001.
[2] 森川, 岩田, “データ駆動型最長一致検索機構の超高速パケット分類処理への応用,” FIT 2002, pp.63-64, Sep, 2002.
[3] 森川, 岩田, “データ駆動型ネットワークプロセッサにおける高速パケット分類処
理,” SWoPP2003, 情処研報 Vol.2003, No.84, pp.37-42, Aug. 2003.
[4] D. Morikawa, M. Iwata, and H. Terada, “Super-Pipelined Implementation of IP
Packet Classification,”Journal of Intelligent Automation and Soft Computing,
Vol.10, No.2, pp.175-184, Aug. 2004.
[5] D. Morikawa, T. Matsumoto, M. Iwata, “FastPacket Filtering in Data-Driven
Embedded Firewall,” NEINE ’04, pp. 361-366, Sep. 28, 2004.
[6] M. Iwata, D. Morikawa, et, al., “Design Conceptof An Embedded Data-Driven
Firewall Processor,” NEINE’04, pp. 80-87, Sep. 28, 2004.
[7] 森川, 岩田, 寺田, “IP アドレス検索処理の超高速パイプライン実現法,” 情処学会第 62 回(平成 13 年前期) 全国大会講演論文集(3), pp.395, Mar, 2001.
[8] 森川, 大森, 岩田, “データ駆動方式による IP アドレスの一実現法,” 平成 12 年
電気関係学会四国支部連合大会, pp.207, Oct. 2000.
[9] Mark Weiser, “Ubiquitous Computing,” IEEE Computer Hot Topics, August.
1993.
[10] “Mobile Ad-hoc Networks (manet),” IETF,
http://www.ietf.org/html.charters/manetcharter.html,
June, 2005, work in progress.
[11] H. Terada, et al., “DDMP’s: Self-Timed Super-Pipelined Data-Driven
Multimedia Processors,” Proc. of the IEEE, 87(2), pp.282-296, 1999.
[12] M. E. Lounavis, et al., “Directions in Packet Classification for Network
Procesors,” Proceedings of the 2nd Workshop on Network Processors, pp.148-157,
2003.
[13] S. Nilsson, et al.,“IP-address lookup using LCTries,” IEEE J. on Sel. AIC,
17(6), pp.1083-1092, 1999.
[14] T.Y.C. Woo,“A modular approach to packet classification:algorithms andresults,” Proc. of IEEE INFOCOM, vol.3, pp.1203-22, March, 2000.
[15]

L.Qiu,

et

al.,

“Fast

Firewall

Implementations

for

SoftwareHardware-Based Routers,” Proc. of ICNP’01, pp.241-250, Nov., 2001.

265- 267 -

and

5.3.2

多入力信号補正システムによる音響空間再現

原音場の特性を再生音場において再現するためには，室内の反響などの影響を考慮
しなければならない．その再現方法として，多チャネル-多点制御系が有効とされている．しかし，この手法はスピーカの増加により制御系が複雑になったり，残響時間が長い空間では演算量が増加してしまうなどの問題があるため実用化には至っていない．
この問題に対して，多入力信号補正システムが提案された[1]．この提案手法では，制御した点（制御点）のみの補正を考慮しており，制御点近傍の点に対しての補正は考慮されていない．本研究では，多入力信号補正システムにおける制御点を増やすこと
で，制御点近傍に対しての補正を考慮したシステムを提案する．
5.3.2.1

多入力信号補正システムの拡張

多入力信号補正システムにおいて制御点を 2 つにした 4 点制御系を用いて，制御点近傍に対して補正を行う．本来 1 つの制御点に対して補正を行うものなので，2 つの制御点の観測音の平均をとり１つの制御点の観測音として用いる．多入力信号補正シ
ステムは，図 5.3.7 の制御点 B のように 2 つのスピーカから出る音の制御点までの伝達経路が左右対象であるときに最も有効とされている．このことから，図 5.3.7 の制
御点 A， C のように 2 つの制御点に対する 2 組の伝達経路が左右対象となる位置関係にあるとき，各制御点において補正が行われると考えられる．また，2 つの制御点の間の受聴点においても再現が行われると考えられる．そのため，4 点制御系に用いる
2 つの制御点を A と C とすることで，制御点近傍に対して補正を行うことができる．

図 5.3.7
5.3.2.2

多入力信号補正システムの構成

計算機シミュレーション

多入力信号補正システムにおける従来の 2 点制御系と，提案した 4 点制御系について計算機シミュレーションを行う．その結果より導いた評価値を用いて，それぞれの266- 268 -

制御点とその近傍の受聴点を比較することにより 4 点制御系が範囲に対する補正において有効であることを示す．
（１）シミュレーション条件
反響性のある部屋において，図 5.3.7 のようにスピーカとマイクの位置関係を変えた受聴点を 15 種類用意した．それぞれの点において逐次最小 2 乗法により再生音場の伝達特性を実測し，出力信号として音声信号を用いる．多入力信号補正システムにおいて，制御点を B とした従来の 2 点制御系と，制御点を A ，C をとした提案手法である 4 点制御系を行い，各手法における制御点およびその近傍における再現精度を求める．ここで，再現精度は

SNR = 10 log10∑∑ xi2 ( t )[ yi2 ( t )− xi2 ( t )]で表されるものとする．制御せずに観測した SNR と，制御を行い観測した SNR の差を，それぞれの受聴点における改善量として評価を行う．
（２）シミュレーション結果
2 点制御系と 4 点制御系における各受聴点における改善量を表 5.3.3 に示す．ただし*は制御点を表す．表 1 より 4 点制御系は 2 点制御系に比べ，制御点における補正効果は小さくなるが，制御点近傍の改善量の平均値は向上していることが確認できた．
表 5.3.3

シミュレーション結果

I : 2 チャネル-2 点制御系, II : 2 チャネル-4 点制御系
5.3.2.3

まとめ

本研究では，2 チャネル-4 点制御系において従来手法と比べると制御点近傍への再現精度の向上が確認できた．しかし，ステップゲインや重み付けなどのパラメータの設定値については未検討である．より多くの環境を想定してパラメータの関係を明らかにする必要がある．
参考文献[1] 浜崎真二, 福本昌弘, “クロストーク成分における相互相関係数に着目した音場再267- 269 -

生システム,”信学技報, SIP2004-115, Vol.104, No.559, pp.31-36, Jan.2005.
[2] M. Fukumoto, S. Hamasaki and T. Kubo, “Sound Field Reproduction System
Focused on Cross-correlation of Cross-Talk Components,” Proceedings of theInternational Conference on Next Era Information Networking (NEINE’05),
pp.561-568, Sept.2005.
[3] 下上泰治, 福本昌弘, “制御点の移動を考慮した音場再生,” 電気関係学会四国支部
連合大会, 1-24, p.24, Sept.2005.
5.3.3

音響空間再現に適した適応信号処理アルゴリズム

学習同定法[1] は，演算量が少なく実現が容易であることから代表的な適応アルゴ
リズムのひとつとして広く用いられている．学習同定法で不安定な動作が生じるという問題に対し，状態ベクトルのノルムがしきい値以下になったときに係数更新を停止する方法が知られており，筆者らは既にこの方式を用いた場合の保証値（推定誤差の上限）及び確率的最速ステップゲインを示している[2-3]．しかしながら，この手法では保証値を係数更新打切りにより実現しているため，扱う信号の性質によっては収束速度が著しく劣化する場合も想定される．そこで更に，係数更新を打ち切ることなく保証値を満足するステップゲインの上限を解析的に与えている[4]．これらの方式では，収束後（期待値）の保証値を与えていたため収束速度を向上させる余地が残されている．本研究では，以前の推定誤差を保証値に設定することにより，保証値を満足する
学習同定法の収束速度が改善されることを示す．
5.3.3.1

学習同定法

ここでは，まず，学習同定法[1]で用いる記号の定義を行い，次いで，学習同定法の係数更新手順について述べる．
時刻 i における入力信号 x(i)に対して，適応フィルタの状態ベクトルを

x N ( i ) = [x ( i ), x ( i − 1),L x ( x − N + 1)]

Tとする．ここで， N は適応フィルタのインパルス応答長であり， T は転置を表す．
適応フィルタの係数ベクトルを hN(i) とすると，入出力関係は

y ( i ) = hN T ( i )x N ( i )で与えられる．一方，所望信号を

d (i ) = w N T x N (i )とし，観測出力 z(i) をz (i ) = d (i ) + v (i )とすると，出力誤差は

e (i ) = z (i ) − y (i ) = d (i ) − y (i ) + v (i )268
- 270 -

となる．ここで， v(i) は観測雑音である．
学習同定法の係数更新手順は

hN ( i + 1) = hN T ( i ) + α

x N (i )x N (i )2e (i )と表される．ここで，αはステップゲインである．

5.3.3.2

UL-NLMS アルゴリズム
2

保証値（推定誤差の上限）[2]を確保するためには，判定式 ε ≤ xN (i ) が常に満たされればよい．そこで

ε = x N (i )2とする．保証値 q はq=

Nσ v 2αx N (i ) 2 − α
2となる．但し，σ x2 ，σ v2 はそれぞれ，入力信号 x(i)，観測雑音 v(i)の分散を表す．
この保証値を満足するためには，ステップゲインαをα=

2q x N ( i )22q x N ( i ) + Nσ v 2とすれば良い．即ち，このαを用いると，係数更新打切りを行わなくても常に保証値を満足する．ただし，一般にα≦ 1 とするから， x N (i )

2

≥

Nσ 2
のときα = 1 とすればqよいことがわかる．
以上をまとめると，保証値を満足するステップゲインの上限を用いた学習同定法の係数更新手順はhN ( i + 1) = hN ( i ) + γ ( i )x N (i )x N (i )2e (i )となる．ただし，γ (i) は保証値を満たすステップゲインの上限であり
2⎧
2q x N (i )⎪⎪γ (i ) = ⎨ q x N (i ) 2 + Nσ v 2 , if⎪⎪⎩ 1 , otherwise269- 271 -

2x N (i ) <

Nσ v
q

2

となる [4] ．

5.3.3.2

収束特性の改善法

ここでは，推定誤差の上限は維持しながら追従性を向上することを考える．

UL-NLMS アルゴリズムでは，収束後の推定誤差の上限を保証値としたために追従性が劣化するという問題を引き起こしていた．そこでまず，追従性を重視して，保証値
として統計量にもとづく一定の値を与えるのではなく，前の時刻の誤差を用いることにする．すなわち，時刻 i における保証値 q ( i ) を時刻 i における推定誤差 e ( i ) を正規化した量e 2 (i )d 2 (i )と変更する．このとき，ステップゲイン γ (i ) は
q (i ) =2⎧2q(i ) x N (i )⎪,γ (i ) = ⎨ q(i ) x (i) 2 + Nσˆ 2 (i)
N
v
⎪
1,
⎩

2

if x N (i ) <Nσˆ v2q(i )otherwiseとすればよい．ここで， σˆ v (i ) , v ( i ) は時刻 i における観測雑音の 2 乗 v (i ) の推定値
2

2

である．
この方式の収束特性を確認するため，計算機シミュレーション結果を図 5.3.8 に示す．

図 5.3.8収束特性の比較

図 5.3.8 より，ここで示した方式では， UL-NLMS アルゴリズムに比べて追従性が大幅に向上していることがわかる．

270- 272 -

5.3.3.3

まとめ

本研究では，保証値を満足するステップゲインの上限を用いた UL-NLMS アルゴ
リズムと最適なステップゲインを用いた場合の学習同定法の特性を比較し，保証値による推定誤差の上限を与えつつ追従性を向上するための方法を示した．今回示した方式の実用上の課題を克服するためには，観測雑音の推定値を推定する手段を確立する必要がある．
参考文献[1] 野 田 淳 彦 , 南 雲 仁 一 , “ シ ス テ ム の 学 習 的 同 定 法 ,” 計 測 と 制 御 , Vol.7, No.9,
pp.597-605, Sept.1968.
[2] 福本昌弘 , 久保田一 , 辻井重男 , “ 安定性を保証した確率的最速な学習同定法 ,” 信
学論 (A), Vol.J78-A, No.7, pp.778-787, July 1995.

[3] 福本昌弘 , 久保田一 , 辻井重男 , “ 安定性を保証した確率的最速な学習同定法の簡略化 ,” 信学論 (A), Vol.J84-A, No.3, pp.269-277, March 2001.

[4] 福本昌弘 , 久保田一 , 辻井重男 , “ 安定性を保証した学習同定法のステップゲインの上限 ,” 信学論 (A), Vol.J87-A, No.9, pp.1196-1204, Sept.2004.

[5] M. Fukumoto, “Convergence Properties of NLMS Algorithm in Noisy
Environment,” Proceedings of the International Conference on Next Era
Information Networking (NEINE’05), pp.457-463, Sept.2005.
[6] 福本昌弘 , 久保田一 , “ 安定性を保証した学習同定法の収束特性の向上 ,” 信号処理
シンポジウム , B5-1, Nov.2005.

271- 273 -

5.4

高度 HCI 技術を活用した適応型サービス制御の研究開発

5.4.1 研究開発の概要
5.4.1.1

研究開発の背景

通信の究極の目標の一つの形は、遠隔に存在する相手とあたかも同じ空間に存在しているかのような状況を作り出すこと、すなわち遠隔の相手と空間を共有することである。従来、例えば、CG 映像を駆使してユーザを包囲する巨大な仮想空間を構築し、それを高速ネットワークを介して共有することによってこのような目標を実現しようとする試みは幾つか見られた。しかし、言うまでもなく、実世界に居住するユーザを仮想空間に置くことは不自然であって、ユーザが実世界に存在したまま遠隔に存在す
る相手と空間を共有する状況を作り出すことが理想である。
一方、従来の超高速ネットワークに関する研究開発では、大容量の映像等を効率的に伝送する方式等については重点的に研究開発が進められてきたが、実世界をベースに空間共有を実現するために必要な、実世界の環境やオブジェクトの情報も同時に伝送することを考慮した技術開発はあまりなされてこなかった。すなわち、今後は映像コンテンツに代表されるブロードバンド情報と実世界の様々な環境・オブジェクト情報の双方を効果的に組み合わせた、新しいコミュニケーション技術を開発していく必要がある。現状では、これらの情報を統合してサービスを提供するプラットフォーム
技術は存在せず、またその上の優れたユーザインタフェースを持つシステムは開発されていない。つまり、本研究では実世界のユーザ（人間）とその環境情報を忠実に送り合った上で、双方が同一空間を実感し合える仮想空間を実現することにある。
5.4.1.2

研究開発の目的

本研究では、超高速ギガビットネットワークによって伝送される映像と実世界に存在する各種の情報の双方を、ユーザに利用しやすい形で統合してサービスを展開する
ためのプラットフォーム技術を確立し、遠隔の相手との空間共有を可能にして従来の映像コミュニケーションを質的に越えるコミュニケーション方式を確立することを目的とする。検討にあたっては、本方式を双方向、さらには多地点間で展開することを念頭に、多地点間の複数大容量リアルタイム映像の配信及びそれと連携した遠隔制御
情報伝送に関する技術の検証を行うことも目的とする。
研究の過程では、地域利用型アプリケーション実験を行い、今後の超高速ギガビッ
トネットワークの一つの利用イメージを具体的に提示することにより、広帯域・高品質の超高速ギガビットネットワークの実用的応用例による利用促進に資するものである。

272- 274 -

5.4.1.3

研究開発の進め方

本研究では、ミラーインタフェースと呼ばれる AR（=Augmented Reality）技術をベースに、実世界の映像やオブジェクトの情報から成る共有 AR 空間を超高速ネットワー
クを介して構築し、その中でユーザの動作によるインタラクションが可能なサービスを実現する技術開発を行う。
単なる映像コミュニケーションを越えて、遠隔に存在する物や人にごく自然な身体動作によって制御情報の伝送を可能にする。また、それらを双方向、多地点の場合に拡張し、共有画面上を自在に移動しながら身体動作でコミュニケーションできる技術を確立する。具体的には以下の 3 つについて進めていく。
（１） 適応型サービス制御技術に関する研究開発
多地点に存在するミラーインタフェースの間を、ユーザがシームレスに渡り歩きながら物や人とコミュニケーションを行うための、ユーザ身体動作適応型サービス制御
手法とシステム構成、映像・マーカ情報転送・管理手法、映像合成手法等について研究する。検討にあたっては、まずこれらの技術を用いて超高速ギガビットネットワー
クで結ばれた 2 地点間コミュニケーションの実現を行い、その知見を用いて多地点間へ拡張する（図 5.4.1参照）。さらに、ユーザの多様なインタラクションに対応できる
動的サービス制御手法の検討を行う。

アイコン

Camera共有空間表示：実世界デスクトップ

Camera

ON
L

OFF

H

ここ。

NW

ディスプレイ
ここ。

共有空間表示：自分の映
共有空間表示：自分の映像、相手の映像、情報を像、相手の映像、情報を重合して描画（AR）
重合して描画（AR）

触らずタッチ：共有空間内の物
触らずタッチ：共有空間内の物や情報に、映像上で手を重ねや情報に、映像上で手を重ねる（“タッチ”）だけで作動る（“タッチ”）だけで作動
AR：Augmented Realityの略

図 5.4.1

ミラーインタフェースを用いたコミュニケーションイメージ273- 275 -

（２） 高度 HCI 技術に関する研究開発
ミラーインタフェースを用いて多地点間で自在に人や物とのコミュニケーションを実現するための、ユーザ身体動作認識手法、マルチモーダルなインタラクション手法等に関する研究を行う。システムが一方的に認識するのではなく、ユーザとシステムの協調によって安定して実世界情報の取得、制御、制御情報の伝送が行える環境の実現を目指す。
（３） プロトタイプアプリケーションの研究と検証実験
自然な身体動作やマルチモーダルな入力を用いて超高速ギガビットネットワークで結ばれた多地点間をシームレスに移動し、移動先に応じたサービスが合成されるア
プリケーションを、上記で検討したプラットフォームを利用しながら検討する。この
アプリケーションを用いて、HCI の観点から総合的に評価・実験を行い、本研究の実用性について評価・検証を実施する。
また、ミラーインタフェースと JGNⅡとの関連性を以下に述べる。
本研究開発テーマの究極の目標は、コミュニケーションの相手と、あたかも同じ空間を共有しているかのような状況を作り出すことである。通信の究極の目標の一つの形は、遠隔にいてもその相手と同じ場所に居るかのような状態を作り出すことであると考えられる。本研究開発テーマでは、鏡のメタファを用いることで上記の目標を目指す。同じ鏡に映っていることを利用して、相手も自分と同じ場所に居るかのような状況を実現する。そのような鏡を、現実の鏡と同じように高画質、かつリアルに構築するには、高精細の映像を遠隔地から伝送することが必要である。さらに多地点間において同様な環境を実現するには、映像を多数同時に伝送する必要があり、JGNⅡのよ
うな広域・広帯域のネットワークが必須となる。そして、映像コミュニケーション技術を最高のレベルで行おうとすれば、高精細画像で行う必要があり、そのための通信手段としてもその時代の最先端技術（最高速、最大伝送容量）で試行してみる必要がある。JGNⅡは現時点で実現されている最高性能である。
5.4.1.4

研究開発の目標

実世界のマーカ情報や遠隔地のリアルタイム映像といった様々なブロードバンド
情報を伝送し、ユーザに利用しやすい形で統合し、双方向あるいは多地点間でサービスを展開するプラットフォーム技術の実現、およびプラットフォーム上でユーザの動作を利用して遠隔地に存在する機器の操作指示や制御等が自然に可能になる技術の実現を目標として、具体的には以下の数値目標を設定する。
z 平成 17 年度：（１）3 拠点を結んで上記を実現

274- 276 -

（２）1 人のユーザがマーカ無しで操作を行える手法の考案
z ３年後：（１）4 拠点を結んで上記を実現（２）2 人以上のユーザが居てもマーカ無しで（すなわち素手で）種々の操作を行える環境を実現
以下に多地点（3 拠点以上）の場合のシステムの実現イメージを示す。
JGNⅡ
多地点間の映像伝送
ON

L

H

ON

OFF

Camera３地点の共有空間表示

L
ここ。

H

OFF
ここ。

ON
OFF

ここ。

図 5.4.2

ミラーインタフェースを用いた多地点コミュニケーションイメージ

5.4.2 平成１７年度の成果
本研究における実験システム構築の目的は、実世界の映像やオブジェクトの情報から成る AR 空間を超高速ネットワークを介して共有し、その中におけるユーザの動作によるインタラクションが可能な遠隔地間でのコミュニケーションサービスに関する基盤的技術を検討、整備することにある。
平成１６年度は、遠隔の２地点の映像を用いて仮想的に共有空間を構築し、その中で互いにインタラクションが可能な環境を構築した。具体的には、遠隔地にいるユー
ザの映像を互いに送信しあい、各々の地点においてその地点の映像と遠隔地映像を半透明にして重畳表示することにより共有空間を構築するミラーインタフェースを採用
し、２地点間で共有を可能にするシステムを構築した。
従来、遠隔地間の映像コミュニケーションには、TV 会議システムや TV 電話等様々な方法が提案されている。しかし、このような従来の方式では、映像と音声の通信は可能であっても、互いの映像は画面上で別々の画像として表示され、相手映像中に存在する人や物体を選択したり、相手映像中の位置を指示したりする等、相互に関わり合う作業が不可能であったため、意図の伝達が困難であった。このことは、有効な映像コミュニケーションを実現し普及する上で大きな問題であると考えられる。

275- 277 -

ミラーインタフェースでは、同一画面にユーザを表示することで、画面内に構築された共有空間内で身振りや指示動作など互いに関わり合う作業が可能になった。
平成１７年度は、16 年度に検討した手法を活かしつつ、更に多地点化、高機能化について検討し、実験システムを構築した。また、ミラーインタフェースを活用した映像コミュニケーションの応用について、遠隔講義・カウンセリングの実証を目指した検討を進めた。
平成 17 年度の成果は、主に以下の通りである。
（１） 適応型サービス制御技術に関する研究開発
平成１６年度に構築した双方向システムを拡張し、以下の開発と実験を実施した。
z 資料共有機能の開発、カメラ切り替え機能の開発（平成１７年度目標項目）
z 遠隔地間の対話を通じて資料を作成する協調作業を想定した被験者実験
さらに、これらの機能を有し、より多くの地点間でのコミュニケーションの可能性を検証するために、２地点間の対話を基盤に、話題・対話者の切り替わりに合わせて対話地点を切り替え可能な構成とすることにより、より多くの地点間のコミュニケー
ション支援を目指して、以下の開発を実施した。
z ３地点対話システムの構築（平成１７年度目標項目）
これらの開発したシステムを用いて、ＪＧＮⅡ上で以下を実施した。
z ＪＧＮⅡ上の接続実験･デモンストレーション（平成１７年度目標項目）（２） 高度 HCI 技術に関する研究開発
現在、特定色のタグやシール状のものを、ユーザのポインティング位置認識のためのマーカとして用いている。より自然な HCI を目指して素手によるポインティング技術の研究を進めた。（平成１７年度目標項目）
立体視カメラによる距離抽出、肌色領域抽出、画面の変化領域（動き）抽出を行い各抽出情報を複合して素手位置を検出・追跡する手法を提案、プロトタイプ実験にて、実時間動作と既存手法に比較して動きの少ない状態での追跡性能の向上を確認した。
（３） プロトタイプアプリケーションの研究とフィールド実験
ミラーインタフェースを活用したアプリケーションとして、筑波大学と共同で遠隔講義・遠隔カウンセリングについて検討を進めた。システム構成として、資料共有機
能を用いたカウンセリング、さらに、カメラ切り替え機能を活用し、対話者の客観視点映像による話者間視線の一致や、生徒側グループ単位の作業・ロールプレイへの教師の指導介入を可能とする実験システムを構築した。
さらに、筑波大学及びつくば市と連携して、つくば市におけるフィールド実験・地域住民貢献活動の平成 18 年度実施に向けた検討を開始した。（平成 17 年度目標項目）

276- 278 -

以下、順にその詳細を記述する。
5.4.2.1
5.4.2.1.1

適応型サービス制御技術に関する研究開発
資料共有機能の開発・カメラ切り替えによる仮想空間移動の実現（１） コンテンツサーバを用いた共有機能の実現
ミラーインタフェースシステムは、各地点にz 画像の合成やコマンド処理を行う画像重畳用ＰＣ、z マーカ位置を認識する画像処理用ＰＣ、を配置している。資料共有を実現する
ために、ネットワーク上に新たにz 資料・コンテンツの配信を行うコンテンツサーバ、を接続した。また、コンテンツサーバ上で動作するコンテンツ共有プログラムを開発した。コンテンツ共有プログラムは、コンテンツサーバ画面を一定時間毎に取得してネットワーク上の各地点の画像重畳用ＰＣに対して画像を配信する。
（２） スライドの共有
コンテンツ共有プログラムは、各地点からのコマンドを受信して、予め設定された
スライドファイル（Windows Office PowerPoint ファイル）を起動し、スライドショ
ーを実施可能とした。スライドショー画面は、上記の配信機能によって各地点の画像
重畳用ＰＣに配信される。
コンテンツサーバが受信可能なコマンドは、z スライドショーの起動、終了、
z １ページ送り、１ページ戻し、z 開始ページ，最終ページへの移動、である。ユーザは、ミラーインタフェース画面に表示されたアイコンに仮想的にタッチすることでこれらのコマンドを実施し、画面を指差しによって指示、指示語（「こそあど」言葉）を用いたコミュニケーションが可能になる。図 5.4.3に、スライドを共有した画面の例を示す。

図 5.4.3

ミラーインタフェースにおけるスライドの共有

277- 279 -

（３） 書画の共有
コンテンツサーバにカメラを接続・画面表示を行うことにより、書画の共有が実現できる。コンテンツ共有プログラムは、自動的に画面を取得して配信するため、カメラで撮影された画像が共有できる。この機能は、通常のＴＶ会議システムで用いられる書画カメラと同等の機能を提供する。
コンテンツサーバと書画カメラを一地点に配備し、コンテンツサーバから両地点へ画像を配信する。両地点の画像重畳ＰＣでは，自己及び相手画像を鏡像反転した上に書画画像を重畳する．両ユーザは隣に相手が座って互いに鏡を覗き込みつつ，鏡上に書画を投影したような画像を見ることになる．

ディスプレイディスプレイ
ユーザカメラ

画像重畳ＰＣ
指示側

画像重
畳ＰＣ

書画取
り込み
ＰＣ

ユーザカメラ

書画
カメラ
作業側

ネット
ワーク
図 5.4.4

書画共有におけるシステム構成

本機能を利用した協調作業を想定して被験者実験による評価を行った。評価実験については第5.4.2.1.2節で延べる。
（４） カメラ切り替え機能
ミラーインタフェースの活用シーンとして、博物館のウォークスルーのように、視点を移動させることで仮想的に遠隔地点を訪問、探索する応用が考えられる。このよ
うな応用では、視点の移動のために、ミラーインタフェースの入力装置であるカメラそのものを遠隔地側から操作する必要がある。ミラーインタフェースの実物体操作の一貫としてカメラ操作を取り込むことで、ユーザにとって自然なインタフェースで仮想的な移動を実現することを検討している。平成１７年度は、複数のカメラをＡＶ切り替え機を使って切り替えることで実現した。ミラーインタフェースは、ＡＶ切り替
え機のリモコン信号を出力することにより、コマンドを実行する。
本機能は、第5.4.2.3.1節で述べる、遠隔講義システムにおいて生徒グループの画面切り替え機能として利用している。

278- 280 -

5.4.2.1.2

資料共有機能を用いた遠隔協調作業の評価

書画カメラ画像を半透明合成して協調作業するシステムを構築し被験者実験によりＴＶ会議との簡単な比較を行った。システムは図 5.4.4に示した構成で接続し、ミラーインタフェースと通常のＴＶ会議を模擬した表示の両方が選択可能な環境を構築した。
作業として、図面や特定様式の書類作成を想定した作画指示の伝達実験を行った。
作画課題として、幾何学図形 4 個からなる幾何図面 2 枚と一冊の絵本から 2 枚の挿絵の計 4 枚を選んで (幾何，挿絵)対を 2 対で一組として独立に 2 組（合計８枚）準備し、ミラーインタフェースを用いた場合(MP)とＴＶ会議を模した場合(TP)を比較した。
図 5.4.5に、実験時の様子を示す。図 5.4.5a は MP の指示者側で、画面上の書画領
域に指示者が手を掲げて、図の大きさや位置を手振りで直接伝えている様子が見られる。一方、図 5.4.5b は TP の作業者側で、書画画面の指差し等ができないため、主に口頭でのみ指示が伝えられた。

(a) 指示者側(MP)
図 5.4.5(b) 作業者側(TP)作画指示伝達実験の様子

被験者は二人一ペアとし、図が特定の要件を満たすように指示者が内容を伝え作業者が作画した。ペアの一人を指示者として MP・TP の両ケースで各々１対ずつ 2 対（一組）の作画を行い、もう一人を支持者として別の一組の課題で作画を行った。シス
テムに対する慣れの影響と図の難易度差を避けるため MP と TP の実施順の入れ替え、
MP・TP と図の対の対応付けを入れ替えて全体で 4 ペア実施した。図面の完成度は問
わず、図 1 枚 8 分の時間制限を設け、指示者が完成を宣言するか制限時間に達した段階で指示の終了とした。
MP，TP について指示の伝わりやすさを
z 全く伝えられなかった：０～z ～まあ伝わった：５～z ～実際に対話している位スムーズだ：１０の 11 段階で、指示者になった場合と作業者になった場合の両方について、主観評価
による評定を行った．

279- 281 -

評定結果の平均と標準偏差を表 5.4.1に示す．MP 作業者と TP 作業者との間には評定差が 3 ポイント以上あり，ミラーインタフェースが協同作業を行う Tool として、作業者間の意思の伝達に優位性が示される結果となった．また，作業者側の場合に若干評定が良く，指示を受ける立場で理解の容易さに差が出易いと推定できる．
表 5.4.1

MPTP

作画指示伝達実験評定結果

指示側
作業側
平均 標準偏差 平均 標準偏差
7.875
1.356 8.375
1.408
4.875
1.553 4.75
1.581

MP（ミラーインタフェース）と TP（ＴＶ会議）の間に評定値が平均で３以上の大きい評定さがあり、分散分析の結果、１％有意水準で有意差が認められた。また、MPのとき、作業者側のケースで表低地が情報しており、指示を受ける立場になることで、指示のわかりやすさの違いを強く感じたという可能性が考えられる。
5.4.2.1.3

３地点対話システム

平成１６年度では、2 地点間の実空間映像を合成した共有空間を構築する双方向通信に限ったシステムの検討を行った。しかし、一般の多地点では、地点数 n の増加に伴い、通信ペア数は n (n − 1) / 2 で増加し、各地点で重畳する画像数も n 枚に増加し、通信量・計算量ともに、非実用的な規模になる。例えば、高画質かつ遅延の少ない映像である DV 映像（30Mbps）を用いる場合には、NW 上で通信される映像数（通信量）
は、ｎ＝３地点で既に 90Mbps（ 3 ペア×30Mbps）であり、また各地点での計算量も 90Mbps
分の画像の重畳処理が必要となる。しかし更に地点数が増えた場合、例えばｎ＝１０
地点では、1350Mbps（45 ペア×30Mbps）もの通信料が NW 上を行き交うことになるとともに、各地点では 300Mbps 分の画像重畳処理が必要になる。これらから、NW 上で DV
映像等の大容量の映像を多数通信し合うこと、また各地点で多数の大容量映像に対するリアルタイムな画像処理を行うことは、現在の PC の処理性能では３地点を越える地
点数では遅延等の問題が課題となって来る。将来の計算機の処理能力の向上・ 画像
Codec の処理速度・通信伝送速度の更なる高速化等を期待したい。

（１）３地点化システム構築の目的
上記の課題を受け、平成１７年度では、２地点の対話をベースとして多地点に自然に展開可能な共有空間の構成方式とそれに必要な通信方式を確立するために、３地点を想定したミラーインタフェースの拡張を検討した。本検討は、一般的な多地点化を進める上で必要な要素として、

280- 282 -

z 各地点のユーザが対等に対話への参加が可能、
z 地点数に対して通信量の爆発が起こらない、z 共有空間に対話者が同時に存在するミラーインタフェースの特徴を備えた、共有空間の構成方法を検討することを目的としている。
システムを新たに多地点化用のサーバ PC を配置し、複数地点からの映像やコマンド等を制御する方法と、遠隔地間でのドキュメント共有表示する方法について検討した。
（１） ２者対話の拡張による多地点会話
３人以上が会話する場合、一般には、全員が同時に話し・身振り手振りなどの情報の発信を行うことも可能であるが、会議やパネル討論などコーディネートされた会話の場面では余り行われない。日常的な会話においても、誰か一人の話者が全員或いは、
特定の聞き手に対して語りかける行為が、話者を次々に切り替えて行われているように思われる。
上記の推定に基づき、次の仮説を設けた。その上で、できるだけ自然な会話の妨げとならないように留意しつつ３地点化システムの検討を行った。
仮説：「３人以上の会話のための共有空間は、１対１の対話をベースとして、対話に参加している二人の対話者の共有空間（対話空間）を構築し、対話者を動的に切り替えることで、不自然さを大きく損なわずに構築できる。」
検討したシステムの特徴を以下に示す。
z ２地点のミラーインタフェースの画像合成方法に基づき画面を構成する
z 対話に直接参加していないユーザ（非対話者）は対話を観察することができる¾

非対話者の画面では、対話者の合成画像にさらに自己像（鏡像）を重畳する

z 非対話者でも音声による参加は可能とする
z 画面内に各地点に対応するアイコン（子画面）を設け、ユーザのアイコン操作
により対話者の切り替えを行う¾

対話者、非対話者のいずれも、アイコン操作によって対話者を選択可能

上記の特徴を持つ３地点化システムでは、対話者のいる２地点では、当該２地点の重畳合成により共有空間を構築する。一方で、非対話者（３地点目）では、対話者の２地点の映像に加え、自らの鏡像を加えた３地点分に重畳が必要になる。
さらにこの方式を n 地点に拡張した場合、２地点分の映像のみを本人以外の n − 1 地
点にマルチキャストすることになり、非対話者の映像は配信する必要がない（子画面用に小さい画像は配信されるかもしれない）。また、各地点では、最大３画面の重畳（＋
アイコン、子画面）を実施すればよい。
従って、通信量は概ね地点数に比例し、各地点での合成処理量は一定値に押えられ

281- 283 -

る。これにより、将来 n 地点へ拡張する場合のスケーラビリティが確保できる。
平成１８年度では、上記システムの使用感を確認し、仮説の正当性・提供可能な条件等を検証する。さらに、実際の多地点化に向けてより具体的な問題点の洗い出し・
解決策の検討を進める。多地点化に際して、複雑化するアイコン・子画面の構成、３地点以上の重畳における画面の不鮮明度を低減する背景処理法などについても、次年度以後の課題である。
（２） ３地点化システムの実現
以下に本研究で実現した 3 地点（SITE）間コミュニケーションのシステム構成を示す。

≪SITE A

≪SITE B

カメラ（ユーザ
画像）≪SITE C

カメラ（ユーザ
画像）

ココポインタ情報

100BAS
E HUB

ミラーPC2ミラーPC1

GigaHUB

100BASE LAN カード

アプリケーション画面

100BASE LAN ケーブル

Giga,GigaLAN=Gigabit
ether

1000BASE LAN カード
1000BASE LAN ケ ー ブ

図 5.4.6

ユーザ画像
アプリケーション画像
コマンド情報ミラーサーバ PC

３地点コミュニケーションのシステム構成

Ａ地点（SITE A）、Ｂ地点（SITE B）、及びＣ地点（SITE C）それぞれに、大画面ディスプレイ（PDP）、カメラ、PC 及び周辺機器があり、Ａ地点、Ｂ地点、Ｃ地点はギガ
ビットネットワークで接続している。また、各地点はローカルにネットワーク接続された 2 台の PC で分担して処理を行っており、同地点で入力された１つのカメラ画像は、
2 台の PC に分配して入力される。そのうち 1 台の PC（画像重畳用 PC）は、自地点映282- 284 -

像と、送られてくる遠隔地画像と、CG 映像を各々半透明化して重合する処理を主として行う。もう 1 台の PC（画像処理用 PC）は、入力画像からマーカの位置を認識する画
像処理を行い、得られた結果（x,y 座標値）はローカルネットワークを介して重畳処
理 PC へリアルタイムに送られる。重畳処理 PC 側では送られてきたマーカ認識位置情報（画像上での x,y 座標値）と、物体やアイコンの表示位置情報から、マーカの“タッチ”判定を行い、その結果に応じて機器操作や情報表示等のコマンドを発行する。
以下に本システムの全体構成図、レイアウト図、設備写真及び使用風景を掲載する。

図 5.4.7｢高度 HCI 技術を活用した適応型サービス制御の研究開発システム｣
全体構成図

283
- 285 -

図 5.4.8｢高度 HCI 技術を活用した適応型サービス制御の研究開発システム｣
設備写真（左上：A 地点側、右上：B 地点側、下：Ｃ地点側）

284- 286 -

(a)３地点の重畳の様子(b)３地点でドキュメント（PowerPoint）共有表示の様子(c)３地点で
図 5.4.9

ドキュメント（書画カメラ）共有表示の様子｢高度 HCI 技術を活用した適応型サービス制御の研究開発システム｣
使用風景

285
- 287 -

5.4.2.1.4

JGN Ⅱネットワーク遠隔地間でのデモンストレーション（１） 仙台－つくば間接続
18 年 1 月 18 日～19 日に開催された「JGNⅡシンポジウム 2006 in 仙台」において、
ミラーインタフェースを用いた本システムをデモ出展し、実際に仙台とつくば 間で
JGNⅡを介して接続し、実際に遠隔の２地点間で双方向コミュニケーションの動作確認試験を行った。その結果、つくばと仙台間での双方向通信は良好に作動し、実回線による機能・制御動作等の安定性をも確認した。
（２） 北九州－つくば間接続
18 年 3 月 29 日に実施されたＪＧＮⅡ中間評価ヒアリング（北九州）において、つくば RC の研究成果デモのため、ＪＧＮⅡを介して、北九州 RC とつくば RC を接続したデモを行うとともに、接続実験を行った。つくば RC に１地点、北九州 RC に２地点分の映像通信端末を置き、３地点間映像通信のデモ及び実験を行った。その結果、問題なく正常に接続及び動作を確認できた。つくば RC と北九州 RC 間の接続状態は良好で、フレーム落ち等の問題も発生していない。
（３） JGNⅡを利用したセミナー配信
つくば JGNⅡセミナー（毎月開催）において、16 年度同様に、遠隔地の他拠点に対して、JGNⅡを介したリアルタイム映像配信を行った。下図（18 年 3 月 20 日の場合）に示すように、北九州ＲＣ、宇都宮大学、岐阜（ソフトピアジャパンおよび IAMAS の２箇所）の各アクセスポイント宛につくばＪGNIIRC セミナーの DV 映像マルチキャス
ト配信を実施した。

図 5.4.10

JGNⅡを用いた DV 映像のマルチキャスト配信実験（つくば JGNⅡセミナー映像のリアルタイム配信を実施）
286- 288 -

5.4.2.2

高度 HCI 技術に関する研究開発

16 年度に、遠隔地の人やモノに対する、操作や情報表示等のユーザによる働きかけを可能にするため、自己像表示とマーカを用いた画像認識処理による非接触型のポイ
ンティング機能を採用、実現した。これによってユーザは共有空間の中で遠隔の物体等に「触る」ことができるようになった。しかし、この手法では、マーカを手に持つ必要があり、ユーザビリティの点で問題があった。そこで、ユーザにとって更に自然な操作を可能にするため、手に何も持たず（マーカレスで）素手のみで画面への“タッチ”が可能な手法の基盤的検討を実施した。
本研究でのポインティング手法は、画面に映っている自己像を、映像中の物体像やアイコンに画面上で重ねる（“タッチ”させる）ことを基本としている。これによって、
あたかも実際に触っているような印象で、遠隔地にある家電機器等に“タッチ”して操作をしたり、その関連情報を画面に表示させたりすることが実行可能である。
平成 16 年度は、ユーザは、色の付いた 1 個のマーカ（認識可能な彩色であれば任意の物体で可能）を持ち、それを物体像やアイコン等の上に画像上で重ねることで実現した。ソフトウェアによる色認識処理により、ユーザが持つマーカの位置をリアル
タイムに認識することができる。これにより、従来のタッチパネルと異なり、画面に直接触らずに、離れた位置から画面上の物体やアイコンへの“タッチ”が可能になった。また、マーカの認識は、予めマーカの色を登録することにより任意の色の物体を使用できるようにした。
これに対し、今年度（17 年度）は、マーカを持たず素手そのものの位置を画像認識処理により検出する手法を検討した。カメラからの入力画像を用いて、ユーザの素手の位置を認識する方法としては、手の肌色を認識する方法、手の動きを認識する方法、手の形状を認識する方法、また距離画像を用いて手の位置を絞り込む方法、更にその組合せ手法等、多くの研究、開発が行われてきている。ここではまず手の色に着目し、肌色認識をベースとした手法を検討した。しかし、単に画像中から肌色を抽出するだけでは、顔やその他の物体を誤認識する可能性が高い。そこで、追跡したい手の存在確率を入力画像上での手領域確率分布として表わすとともに、CAMSHIFT アルゴリズムと呼ばれる手法を用いて確率分布に対する矩形領域最適化を適用して、手領域を検出する方法を新たに考案した。具体的には、まず Step1 として手領域確率分布を計算する。次に Step2 として、Step1 での手領域確率分布を使用し、前フレームでの手領域を始点とし、決められた条件を満たす間、CAMSHIFT 法を用いながら矩形領域サイズを
繰返し最適化する方法とした。

287- 289 -

実際にシミュレーション実験を行った結果、１人程度の操作であれば、高い確率で素手を認識･追跡するとともに、画面上でアイコンへの“タッチ”操作を行えることも動作確認できた。図 5.4.11に、本手法により素手を追跡する様子を示す。
今後は、複数人数にも対応可能なマーカレスポインティング手法実現に向けて、更なる機能･精度向上に向けた検討を行っていく予定である。

アイコン

手追跡位置

結果画像

距離画像（処理後）
手の距離： 遠近図 5.4.11

時間

素手追跡の例

5.4.2.3 プロトタイプアプリケーションの研究と実証実験
5.4.2.3.1

遠隔講義・カウンセリングシステムの構築

具体的なアプリケーションとして、遠隔講義・カウンセリングを検討している。
本ミラーインタフェース･システムを JGNⅡに接続し、映像通信による遠隔カウンセリング実証実験を行っている、筑波大学大学院人間総合科学研究科宗像教授、橋本助教授（つくば RC 特別研究員）らと共同で、遠隔講義の内容や、つくば市との連携方法について、検討を進めている。
（１） カメラ切り替えによる班別活動の実施
遠隔講義を想定したシステム構成等の実現方法について図 5.4.12を用いて説明する。
講義は、通常の座学スタイルより共有空間の必要性の高い、ロールプレイやグループ
討論などワークショップスタイルの講義を想定する。そのような講義では、学生側は幾つかの班に分かれた活動が実施される。本システムでは、学生側に座学状態で用いる大型の全体ディスプレイに加え、各班毎の個別ディスプレイを設置する。ロールプ

288- 290 -

レイ等の班毎の活動が開始されれば、教師は、各班を観察し、必要の応じて特定の班との共有空間に入って指導を行う。
全体ディスプレイを用いた講義状態や班毎の活動に入り込む仮想的移動を行うた
めに、教師は、第5.4.2.1.1節で述べたカメラ切り替え機能を利用する。教師は、遠隔操作によって、全体俯瞰用カメラや班毎のカメラに切り替えることにより、講義を行ったり、特定の班との空間共有を利用できる。
なお、講義、班別活動いずれにおいても、表示される画像は一つなので、全ての班で同一の画像が表示される。従って、班別活動の場合、教師の居る（空間共有している）
班以外の班では、他班での教師の指導の様子を観察して参考にすることが容易にできる。この点は、実際に教師が同室にいる場合以上に学生にとって有意義な情報となる可能性もあると考えられる。
全体俯瞰用カメラ

講師

講師

A１

A2

A１
主観視点
映像

A１

正面
１
ﾃﾞｨｽﾌﾟﾚｲ A

側面
講師用
側面ﾃﾞｨｽﾌﾟﾚｲ ﾃﾞｨｽﾌﾟﾚｲ

講師用
側面ﾃﾞｨｽﾌﾟﾚｲ

客観視点映像

A１

A2

A2

Ａ班

A2

正面
ﾃﾞｨｽﾌﾟﾚｲ

B1
B2

A１

客観視点映像

講師側

図 5.4.12

主観視点
映像
Ｂ班カメラ

全体俯瞰用ﾃﾞｨｽﾌﾟﾚｲ

A1 A2

A2

講師

A2

Ａ班カメラ

A1

A2

講師用正面ﾃﾞｨｽﾌﾟﾚｲ（Ａ班表示時）

A１ A2

主観視点
映像

講師用カメラ側面
ﾃﾞｨｽﾌﾟﾚｲ

客観視点映像
受講者側

Ｂ班

遠隔講義アプリケーションの実施イメージ（２） 左右ディスプレイを用いた客観視点の導入
講義或いはカウンセリング等の対話における臨場感を増大させるために、本システ
ムでは、正面のカメラとディスプレイに加え、左あるいは右にもディスプレイを設置した（図 5.4.12参照）。
姿勢を変えて横のディスプレイを向くと、カメラでは横顔が撮影され、画面では横顔が重畳合成される。結果として、教師と学生が画面上で向かい合って対談する画像が合成される。この際、両者の目線は、画像上で相手側を向くことになり、対話への臨場感が増すと期待できる（図 5.4.13参照）。
臨場感の増大効果については平成１８年度以後のフィールド実験等を通じて検証

289- 291 -

する予定である。

図 5.4.13

5.4.2.3.2

客観視点画像の例

つくば市との連携

つくば市をフィールドとした実証実験に関し、引き続き検討している。本研究開発による成果をつくば市のような実フィールドに展開することによって、本研究の実用性について評価・検証できるのみならず、地域活性化、市民サービス向上、業務効率化等への貢献が期待できる。
平成１７年度は、実証実験の基礎検討を実施した。第 5.4.2.3.1 で述べた遠隔講義システムを用いた筑波大講師による講義の開催を基本案として、つくば市・筑波大を交えた検討を進めている。実施においては、つくば JGNⅡリサーチセンターが研究開
発の実施主体となり、つくば市が実証実験のためのフィールド提供を行うことを想定している。つくば市関係者との打合せでは、既につくば RC にある実機のシステムを用いたデモンストレーションを行いながら検討を進めており、実証実験の実施に向けて、つくば市に適した応用内容について具体化を図っているところである。
また、適用可能性の高い遠隔講義システムに関しては、既に遠隔講義を実験している専門家である筑波大の橋本助教授等を交えて議論を始めており、本実験システムを使いながら、遠隔講義の実現イメージについての検討を進めている。
5.4.2.4

対外発表

以下に対外発表について示す。
１．「遠隔コミュニケーションシステムにおけるエコロジーの二重性とその解決法」、
葛岡英明、山崎敬一、VR 学会サイバースペースと仮想都市研究会、筑波大学、290- 292 -

２００５年５月２０日
２ ．「 Internet Based Remote Counseling to Prevent Interruptions to Regular
Exercise in Elderly People」、橋本佐由理、宗像恒次、樋口倫子、第１８回世界
心身医学会議、神戸国際会議場、神戸ポートピアホテル、２００５年８月２１－
２６日
３．「安心感を生み出す遠隔抱擁システムの試作」、森川 治、橋本佐由理、宗像恒次、
奥中淳三、(ヒューマンインタフェースシンポジウム 2005、ヒューマンインタフ
ェース学会、慶応大学湘南藤沢キャンパス、２００５年９月１７日
４．「ハイパーミラーを用いた遠隔抱擁システム」、森川治、橋本佐由理、宗像恒次、

奥中淳三、情報処理学会インタラクション２００６、学術総合センター／一橋記
念講堂、２００６年３月２～３日
５．「パネルディスカッション：

つくば WAN を用いた研究の連携」、古賀達蔵、第５回つくば WAN シンポジウム、研究交流センター、つくば市、２００６年３月
３日
６．「JGNII におけるミラーインタフェースを用いた遠隔講義システムの実現」、細谷英一、原田育生、佐藤秀則、小野澤晃、橋本佐由理、奥中淳三、古賀達蔵、電子
情報通信学会全国大会、国士舘大学世田谷キャンパス、２００６年３月２４日
７．「手領域確立分布を用いた素手追跡方法の検討」、佐藤秀則、細谷英一、原田育生、
小野澤晃、電子情報通信学会全国大会、国士舘大学世田谷キャンパス、２００６
年３月２４日８．「ミラーインターフェースによる遠隔強調作業と作画指示伝達実験」、原田育生、
細谷英一、佐藤秀則、服部静枝、小野澤晃、電子情報通信学会全国大会、国士舘
大学世田谷キャンパス、２００６年３月２４日

291- 293 -JGNⅡ研究開発プロジェクト研究開発報告書
発行日：平成１８年３月３１日
報告者：JGNⅡ研究開発プロジェクト
東北 JGNⅡリサーチセンター
大手町 JGNⅡリサーチセンター
つくば JGNⅡリサーチセンター
大阪 JGNⅡリサーチセンター
岡山 JGNⅡリサーチセンター
高知 JGNⅡリサーチセンター
北九州 JGNⅡリサーチセンター
発行者：独立行政法人情報通信研究機構（拠点研究推進部門）〒184-8795
東京都小金井市貫井北町４－２－１
TEL ０４２－３２７－７４２９（代）