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

研 究 開 発 報 告 書

平成１７年３月

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

はじめに研究開発テストベッドネットワーク 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Ⅱリサーチセ
ンターにおいて実施する拠点研究に分類される。本報告書は、このうち拠点研究として 16
年度に実施された内容に関して報告するものである。
拠点研究においては、前述の４つの重点技術領域をコアテーマとして、ユビキタスネッ
トワーク時代に向けたネットワーク関連技術の一層の高度化・相互接続性確保や多彩なア
プリケーションの創出に資するために、次世代高機能ネットワーク基盤技術・利活用技術
に関する先導的研究開発を、１０名の拠点研究員と７０名以上の特別研究員を中心に、産学連携や国際連携にも配慮しながら実施している。今年度は、初年度にもかかわらず前研
究開発プロジェクト（JGN）の資産等を上手く承継し、順調な研究進捗となっている。また、研究成果の公開や産学官の研究者の連携・交流のために、JGNⅡシンポジウムや JGNⅡワー
クショップを開催し、好評であった。本報告書の内容が JGNⅡを利用して研究開発を進める
研究者・技術者をはじめとしてネットワーク研究、プロトコル研究、アプリケーション研
究等の関係者にとって参考になれば幸いである。
JGNⅡ研究開発プロジェクト
総括責任者

尾家

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

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

次

はじめに
第１章

全体概要 ···························································· １

１．１

研究の背景 ·························································· １

１．２

JGNⅡ ······························································· １

１．３

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

１．４

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

１．５

研究テーマ ·························································· ８

１．６

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

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

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

概要 ······························································ ２９

２．２

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

２．３

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

２．４

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

２．５

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

２．６

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

第３章

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

３．１

概要 ···························································· １２７

３．２

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

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

３．４

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

第４章

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

４．１

概要 ···························································· １７９

４．２

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

４．３

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

第５章

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

５．１

概要 ···························································· ２０３

５．２

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

５．３

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

５．４

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

第１章
全

体

概

要

第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-

者に広くオープンに研究環境を提供している。さらに、平成 16 年 8 月からは、日米回線（10Gbps）を整備し、海外の研究機関とも連携して研究活動の推進を計っている。アクセス
ポイントは、各都道府県（全 63 箇所）に設置されており、利用者はアクセスポイントまでの接続回線を確保し使用目的が研究開発であれば、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
(1G× 8)N IC T鹿島

1G

10G

10G
10G

N IC T
小 金井本 部

つくば
大 手町 つ く ば

光

10G× 2

堂島

名 古屋

大 手町
N IC T
け い は んな

N IC Tけ い は んな
沖縄

10G

8

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

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

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

北海道
< １ G>
・ 北海道 基幹通 信網構 成拠点（ 札幌 市）< １ ０ ０M>
・ NPO 法人北海道 地域ネ ッ トワ ーク協 議会（ 札幌市）札幌近畿

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

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

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

セン ター

長野
NICT
小金井本部

大阪
岡山

関東

NICT
つ くばRC高知

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

ア メリカ
シカ ゴ

仙台

金沢

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

四国

NICTけ い はん な
情報通信融合研究セン ター< １ Ｇ>
・ 四国基 幹通信 網構成 拠点 （ 高知市）
< １ ０ ０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-3-

Ⅱリサーチセンター、北九州 JGNⅡリサーチセンターの計７ヶ所に NICT が自ら研究開発を実施するリサーチセンターを設置している。設置場所を、図 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-

1.4

プロジェクト推進体制

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

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

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

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

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

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

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

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

拠点研究員：奥中 淳三（つくば JGNⅡリサーチセンター）

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

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

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

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

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

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

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

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

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

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

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

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

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

-5-

同

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

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

同：キニ グレン同：菅原 研次（千葉工業大学情報科学部教授）

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

同：海老原義彦（筑波大学システム情報工学研究科教授）

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

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

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

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

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

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

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

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

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

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

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

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

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

同：大谷 朋広（KDDI 研究所主任研究員）

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

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

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

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

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

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

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

同

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

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

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

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

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

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

同：福岡 寛之（KDDI 研究所主任研究員）

同：伊達 進 （大阪大学大学院情報科学研究科助手）

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

-6-

同

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

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

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

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

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

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

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

同：島村 和典（高知工科大学教授 情報ｼｽﾃﾑ工学科長）

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

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

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

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

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

同：山口 巧 （高知工業高等専門学校電気工学科講師）

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

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

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

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

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

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

同：田頭 秀樹（九州電力電子通信部）

同：神山 勝司（九州電力電子通信部）

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

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

同：勝野 聡 （KDDI 研究所主任研究員）

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

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

同：飯田 勝吉（東京工業大学学術国際情報センター講師）
上で述べた研究推進体制を図 1.4.1 に示す-7-

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

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

曽根秀昭

古賀達蔵

江崎 浩

下條真司

小林和真

福本昌弘

尾家祐二

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

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

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

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

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

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

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

拠点研究 員

拠点研究 員

拠点研究 員

拠点研究 員

拠点研究 員

拠点研究 員

拠点研究 員

特別研究 員

特別研究 員

特別研究 員

特別研究 員

特別研究 員

特別研究 員

特別研究 員

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

テ ー マⅠ外部研究 機関と の共同 研究

2
JGNⅡ R&D NOC (側面支援）

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

研究テーマ

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

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

多種多様かつ大容量のネットワークサービス、コンテンツ、アプリケーション等を、超高速かつ高品質に伝送可能なネットワーク環境の提供を実現するため、高信頼なコアネットワークを構築し、
ネットワークや機器の相互接続性、運用管理技術に関する研究開発を実施し、総合的な検証評価環境を確立する。
具体的研究項目は以下の５つに分かれる。
(1) ネットワーク構築運用支援ツール群の研究開発 (大手町 JGNⅡRC)(2) 広域高信頼ネットワーク接続性提供技術の研究開発 (大手町 JGNⅡRC)(3) IPv6 機器検証評価手法とツールの研究開発 (大手町 JGNⅡRC)(4) 次世代インターネット相互接続性検証の研究開発 (岡山 JGNⅡRC)(5) GMPLS ネットワーク運用・管理技術の研究開発 (つくば JGNⅡRC)-8-

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-情 報通信 研究機 構

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

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

JGN Ⅱ

幹事会
一般共同研究研究推進部会

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

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

利用促進部会

国際共同研究推進部会

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

拠点研究

次世代高機能ネットワーク基盤技術・利活用技術に関す る研究開発

I
総 括 責任 者 尾 家祐 二

高信頼コアネットワーク技術に関する 研究開発
• ネ ットワーク構築運 用支援ツ ール群 の研究 開発

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

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

尾家総括 責任者（リーダ ー）• 広域高 信頼ネ ットワ ーク接 続性提 供技術 の研究 開発• IPv6機器 検証評 価手法 とツ ールの研 究開発• 次世代イ ン ターネ ット相互接 続性検 証の研 究開発• GMPL Sネ ットワ ーク 運用・管理 技術の 研究開 発II• ネ ットワ ーク計測に 基づ く 適応経 路制御 技術の 研究開 発• 品質を 考慮し た シームレ スな 資源利 用・割当 て制御 技術の 研究開 発• 多様性・可変 性に 適応する E2E通信 制御技 術の研 究開発

III

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

下條副総 括責任 者（サブリー ダ ー）

• 広域ネ ットワ ークに おけ る 大規模デー タ処理 連携技 術の研 究開発IVプラットフォーム・アプリケー ション 技術に関する 研究開発

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

曽根副総 括責任 者（サブリー ダ ー）

• サラ ウ ン ディン グ・コン ピ ューティン グ 技術の研究開 発• 高度HCI技 術を 活用し た適 応型サービ ス 制御の 研究開 発

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

テーマⅠ 研究開発体制
高信頼 コア ネッ トワ ー ク技術 に関 す る研究 開発
テ ー マ責任者：江﨑 浩
研究開発実施サイ トおよび 人員
大手町JGNⅡリサーチ セン ター（ ＮＴＴ大手町ビル内）
副総括責任者： 江﨑浩（東京大）拠点研究員 ：山森雅文（イ ンテック W&G）
特別研究員 ： 長谷 部克 幸（NTT-COM）、山内

ﾈｯ ﾄﾜｰｸ構築 運用支 援ﾂｰﾙ 群の研 究開発

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

一郎 （NTT-COM)、中川 郁 夫（インテック ・ネ ットコア）、永見 健一 （インテック ・ネ ットコ ア）、月岡 陽一（日立 製作 所 ）、金 海 好彦 （日本 電 気）、福 田健 介
（NTT みら い ネ ット研 ）、宇多 仁（北 陸先 端 大学 院
大学 ）IP v 6 機器検証評価手法と ﾂｰﾙ 群の研 究
開発

岡山JGNⅡリサーチセンター（ テレポ ート 岡山内）
副総括責任者： 小林和真（ 倉敷芸科大）拠点研究員 ：美甘幸路（オービ ス）
特別研究員 ：岡本裕子（西日本電信電話）、
三宅 喬（倉敷芸科大）次世代ｲ ﾝﾀｰﾈｯ ﾄ相互 接続性 検証の 研究
開発

つ くばJGNⅡリサーチ セン ター
副総括責任者： 古賀達蔵（ NIC T）
拠点研究員 ：岡野介英（ NTT-AT）
岡本修一（ KDDI研）
特別研究員 ： 海 老原 義彦 （筑 波大 ）、亀田 壽

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

夫 （筑 波大 ）、工藤 知宏 （産 総研 ）、佐藤 一雄 （防災 研）、高 田俊 和（NE C基礎 研）、大 谷朋 広（KDDI研 ）、藤原 和弘 （NTT -COM）、鮫 島 康則
（NT T みら いネ ット研 ）、大原 拓也 （NTT み ら いネ ット研）

図 1.5.2 テーマⅠ 研究開発体制- 10 -

共同研究機関東京大、 NTT-COM、
イ ンテック ・ネ ット コ ア、
イ ンテック W &G、 日立製作所、 日本電気、
NTTみらい ネット研、
北陸先端大学院大学

倉敷芸術科学大、
西日本電信電話、
オ ービス

筑波大、 KDDI研究所、
産総研、 農研機構、防災研、 NEC基礎研究所、
NTT-COM、 NTT-AT、NTT未来ねっ と研テーマⅡ 研究開発体制
ア クセス 系 ネット ワ ーク 技術 に関 する 研究開 発
テ ー マ 責任者：尾家 祐二
研究開発実施サイ トおよび 人員

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

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

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

北九州JGNⅡリサーチ セン ター（ 小倉ＡＩＭビル内）
総括責任者：尾家 祐二
主席拠点研究員： 鶴 正人（ 九工大）
拠点研究員：北辻 佳憲（ ＫＤＤＩ研）
特別研究員：勝野聡（ ＫＤＤＩ研）、
山崎克之（ ＫＤＤＩ研）、 神山勝司（ 九電）
川原憲治（ 九工大） 、池永全人（九工大） （ 兼）北九州JGNⅡリサーチ セン ター（ 小倉ＡＩＭビル内）
総括責任者：尾家 祐二
主席拠点研究員： 鶴 正人（ 九工大）
拠点研究員：古閑 宏幸
特別研究員：原口浩朗（安川情報システム)、
池永全人（ 九工大） 、福田豊（ 九工大） 、
堀良彰（ 九大）（ 兼）北九州JGNⅡリサーチ セン ター（ 小倉ＡＩＭビル内）
総括責任者：尾家 祐二
主席拠点研究員： 鶴 正人（ 九工大）
拠点研究員：熊副 和美（ ＪＴＩＳ)
特別研究員：北口善明（ ＩＮＴＥＣ Ｗ ＆Ｇ）、
田頭秀樹（ 九電）、堀良彰（ 九大）

共同研究機関九工大、 ＫＤＤＩ研、
九電

九工大、 九大、
安川情報システム

九工大、 九大、 ＪＴＩＳ、
ＩＮＴＥＣ Ｗ＆Ｇ、 九電

図 1.5.3 テーマⅡ 研究開発体制

テーマⅢ 研究開発体制
拠点連携 型資源 共有技 術に 関す る研 究開発
テー マ責任者：下條 真司
研究開発実施サイ トおよび 人員
大阪JGNⅡリサーチ セン ター（ 大阪大学サイ バー メディ アセン ター 内）
副総括責任者： 下條 真司

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

主席拠点研究員： 馬場 健一（ 阪大)拠点研究員：長谷川 一郎（ ＮＥＣＳＴ）

共同研究機関阪大、 ＮＥＣ、ＮＥＣＳＴ特別研究員：伊達進（ 阪大）、

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

高田俊和（ ＮＥＣ） 、横山恵一（ ＮＥＣＳＴ）、藤井省吾（ ＮＥＣＳＴ）

大阪JGNⅡリサーチ セン ター（ 大阪大学サイ バー メディ アセン ター 内）
副総括責任者： 下條 真司
主席拠点研究員： 馬場 健一（ 阪大)拠点研究員：野呂 正明（ 富士通研)特別研究員：秋山豊和（阪大） 、
松田正宏（ 富士通研）、 松倉隆一（ 富士通研） 、
福岡寛之（ ＫＤＤＩ研）

図 1.5.4 テーマⅢ 研究開発体制- 11 -

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

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

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

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

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

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

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

つ くばJGNⅡリサーチ セン ター
副総括責任者： 古賀達蔵（ NICT）
拠点研究員 ： 奥中淳三（ NICT）
特別研究員 ： 岩田洋夫,大田友一,山海嘉之,
宗像恒次,葛岡英明,小木哲朗,橋本佐由理（ 以上筑波大） ,森川治（ 産総研） ,小田部文彦（つ くばﾏﾙ ﾁﾒ ﾃﾞｨｱ）、 田中崇彦（ NTTCOM),小野澤晃（ NTT-M・ I研)

高知工科大学,愛媛大学
高知高専

筑波大学、 産総研、つくばマルチ メディ ア、NTT-COM、 NTT-M・ I
研

図 1.5.5 テーマⅣ 研究開発体制
1.6

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

1.6.1

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

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

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

利用者

運用管理
システム

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

アプリケーショ ン
制御

侵入検知

監視要求

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

フレキシブルネットワークミドルウェ
ア技術の開発・要求駆動型分析
・異なった視点での情報管理・協調型解析による高次情報提供

Event Detection by Network Traffic Data Analysis
ネットワーク情報の収集[ リンクレイヤ（ VLAN， etc.） ]ネットワーク情報の収集[ ネットワークレイヤ（ IPv4/IPv6， etc.） ]パッシブモニタ

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

パッシブモニタ

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

図 1.6.1(2) アプリケーション指向型運用管理技術とセキュリティ技術の開発
研究テーマとりまとめ・専攻研究員：曽根秀昭（東北大学教授）
共同研究機関：仙台電波高専，特別研究員：脇山俊一郎（同・教授），菅野浩徳（同・助教授）
協力者：加藤寧（東北大学教授）(3) フレキシブルネットワークミドルウェア技術の開発
研究テーマとりまとめ・特別研究員：木下哲男（東北大学教授），特別研究員：阿部亨（東北大学助教授）共同研究機関：岩手県立大学，特別研究員：柴田義孝（同・教授）
共同研究機関：千葉工業大学，特別研究員：菅原研次（同・教授）
超高速大規模ネットワーク向きネットワーク計測・解析技術の開発について，最近のネットワーク管理における問題点は，管理対象となる機器が増大することと，ユビキタスネット
ワークに参加する機器は移動可能であることである．このサブテーマの目的は，ネットワー
クトラフィック予測によるイベント検知とし，時系列多変量解析/確率過程に基づく特異点の検出について，予測値と実測値に誤差に基づいて何らかのイベントが存在したことを検出する技術を研究している．今年度は基礎的トラフィックイベントモデルの開発を目標とし，- 13 -

基礎的トラフィックイベントモデルの検討と JGNⅡにおける実験を実施して，新手法によるイベント検出の有効性を提示した．研究成果を学会，研究会等で発表し，国際論文 2 件，
国内発表 19 件，修士論文 2 件を著した．
アプリケーション指向型運用管理技術とセキュリティ技術の開発について，アプリケーシ
ョン単位のネットワーク観測技術として，観測情報からのアプリケーション制御情報の抽出と，アプリケーションレベルで通信の特性を計測・集約し，高効率に収集する方式を研究している．また，高品質・高効率なネットワーク管理のための技術として，アプリケーション
特性や利用者活動を考慮した知的な運用管理と，多様なアプリケーション間の公平な利用，
および大局的な最適制御を含む技術について研究し，併せて，サービス保全技術としてネットワーク攻撃に耐え得る技術も検討している．今年度は，ネットワーク情報の計測と収集を行うためのネットワーク情報基盤の超高速大規模ネットワーク上への構築を目標とし，運用情報の統合化による運用管理支援技術について多地点間相互映像配信ネットワークの運用
管理技術と観測データとアプリケーション状態を収集・管理する技術，配信映像利活用のためのエンドユーザ環境構築について地域連携によるアプリケーション開発を行い，また，JGN
Ⅱ接続及び LAN における計測実験を実施した．研究成果を学会，研究会等で発表し，研究発表 5 件を著した．
フレキシブルネットワークミドルウェア技術の開発について，やわらかいネットワークコ
ンセプトに基づく知識型ネットワークの実現を目標として，例えば，利用者・アプリケーシ
ョンの要求やネットワーク環境／特性に柔軟に対処できることを目指している．
このために，
フレキシブルネットワークミドルウェア(FNM)の研究開発として，エージェント型ミドルウ
ェアコンポーネントにより，領域知識を利用した動的な構成／再構成に取組んでいる．これにより，誰でも簡単に利用できるネットワーク，多様なアプリケーション／サービス／機器に対応できるネットワーク，および発展するネットワーク／ネットワークサービスの支援（FNM ライブラリ）が期待される．具体的な研究内容は，トランスポート層の上位で稼動する新たな機能層の提案，FNM エージェント指向アーキテクチャの開発，およびエージェント
型ミドルウェア（FNM/A）としての FNM の実装である．今年度は，フレキシブルミドルウェ
アの論理アーテクチャの開発を目標とし，JGNⅡを基盤としたネットワーク環境を対象として，利用者向きネットワークサービスの具体例について調査・検討を進め，上記サービスを実現するエージェント型ミドルウェアの基本アーキテクチャの検討，および JGNⅡ向きミド
ルウェアの開発に有用と考えられるエージェントシステム設計開発支援環境の検討を実施
した．研究成果として，研究発表 4 件を著した．
これまで述べたような主たる研究テーマに関する研究開発とともに，JGNⅡの利用に関係する地域貢献のために，JGNⅡ利用推進と JGNⅡ利用技術の普及活動を実施している．JGNⅡ
利用の推進として，地域の接続・利用の技術的支援，全国各地の映像配信・イベント利用への参加（測定実験を兼ねる），講演会，ワークショップなどの開催などを実施しており，これらの実施については東北地方 JGNⅡ利用推進協議会と連携して，地元情報通信分野企業等，- 14 -

自治体，東北総合通信局とも協同して推進している．また，JGNⅡ利用技術の普及のために，
JGNⅡテクニカルセミナーの開催による地元企業技術者への技術移転，啓発，および多様な
地域内アクセス接続技術の実証的検証として CATV や B フレッツの利用実験を実施している．
研究者が利用者と一緒になって利用環境の構築に取り組むことにより，新たな研究課題等のフィードバックも期待できる．東北JGNⅡRCでは，このような観点から，地域イベント等の支援，地域プロジェクトとの連携，などを積極的に受け入れ，例えば，地域内および地域間の放送分野や遠隔教育への応用といった，地域連携によるアプリケーション開発にも取り組んでいる．
本年度の実績について以下に述べる．
(1)

JGNⅡ中継イベント支援
学校間交流実験及び「JGNⅡ 推進フォーラム2004 in 東北」映像交換・配信実験支援
H16.5.24～H16.7.17（東北総合通信局・東北JGNⅡRC）
仙台七夕市民花火大会中継
H16.8.5
実学の森 JABAS 2004 映像配信実験
H16.8.18～H16.9.11 JABAS実行委員会（岩手IT研究開発支援センター）
高大連携理科教育実験授業（遠隔実験授業）
H16.10.30～H16.10.31（東北大学，岩手県立大学）
電子自治体人材セミナー
H16.11.25～H16.11.26（山形県，ほか）(2) 地域支援白石，米沢小学校間交流（2004.5-6）
各市内～JGNⅡAP間をBフレッツ
米沢～仙台～白石
DVTS双方向による小学生を対象とした長期間トライアル
JGNⅡ 推進フォーラム2004

in 東北（2004.6.24）

DVTS/JGNⅡ
上記学校間交流をフォーラム会場でも実施
米沢～仙台～白石
DVTSリフレクタによる配信
仙台→八戸，岩手，秋田，会津，千葉，九州
JABAS 2004（2004.8.27-28）
岩手→各地
技術支援
電子自治体人材セミナー（2004.11.25-26）
DVTSリフレクタによる配信- 15 -

酒田→仙台→八戸，秋田，群馬，岩手，会津，千葉，鳥取，滋賀，けいはんな，兵庫，九州，（仙台市内）JGNⅡシンポジウムin大阪（2005.1.17-18）
防災情報シンポジウム（2005.1.28）
岩手→東北以外の各地
岩手→仙台→東北各地
防災情報シンポジウム（2005.3.18）(3) 地域貢献
JGNⅡの門戸拡大や地元企業への技術移転などを目的として，東北地域（在仙）のIT関連企業における若手技術者を対象に，総務省東北総合通信局，東北地方JGNⅡ利用推進協議会との共催により，JGNⅡテクニカルセミナーを以下の要領にて開催した．
3 月 7 日（月）全体レク，JGNⅡ紹介，JGN 曽根※1 菅沼※1
Ⅱ関係デモ

3 月 11 日（金）ブロード MPEG ストリーミ 曽根※1・曽根研究室 富田院生
ングの輻輳実験

3 月 14 日（月）NTP stratum1 サーバの構築 脇山※2

3 月 18 日（金）PICNIC での遠隔制御等

曽根※1・曽根研究室 作田院生

東北大学・東北JGNⅡRC※1，仙台電波工業高等専門学校・東北JGNⅡRC※2，
開催時間はいずれも18時～21時で，複数日の設定であったが，延べ約30名の参加を得て好評であった．
1.6.2

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

大手町リサーチセンターは、東京都千代田区大手町の NTT コミュニケーションズ大手町ビル内を拠点とし、拠点研究員 1 名(山森雅文)、特別研究員 12 名で、(a) ネットワーク構築
運用支援ツール群の研究開発、(b) 広域高信頼ネットワーク接続性提供技術の研究開発、(c)IPv6 機器検証評価手法とツールの研究開発 に関する研究開発を展開している。
以下が具体的な研究課題の現状と成果であるが、どの研究課題も、商用ビジネスに深く関係した方々との連携や協調活動を基本方針として活動を推進している。すなわち、研究と実ビジネスの間のギャップを埋めることを大きな目標としており、技術の確立と普及に貢献す
るための活動を産業界の方々とご相談しながら進めている。
(1) ネットワーク構築運用支援ツール群の研究開発
実ネットワークにおいて必要となるネットワークの構築運用支援ツールを研究開発し、これを、可能な限りオープンソフトウェアとして提供することを目指している。
本年度は、MPLS
ネットワークにおける LSP の設定と管理を支援し、さらに、ネットワーク運用を支援するツール群の研究開発、ならびに、レイヤ２やレイヤ 1 の情報とレイヤ３の情報を統合化したマルチレイヤネットワークトポロジー管理ツールの研究開発を行った。
研究の推進にあたって- 16 -

は、DISTIX と協調しながら行った。
(2) 広域高信頼ネットワーク接続性提供技術の研究開発
超広帯域および高信頼の接続性を提供するための基盤技術の研究開発を行うことを目的としている。本年度は、次世代経路制御アーキテクチャ(IRIDES)の基礎検討、マルチホーム
サービス提供アーキテクチャの研究開発、VoIP/SIP システムの相互接続性確立のための研究開発、さらに、我が国の総インターネットトラフィック量の測定と解析に関する研究開発を行った。 本研究課題の推進にあたっては、JPNIC や TTC、VoIP 推進協議会、HATS など、あるいは 大手 ISP など、極めて多数の組織との協調関係を確立しながら行った。
(3)

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

TAHI プロジェクト、IPv6 普及高度化推進協議会、IPv6 Forum との協調関係を構築し、グ
ローバルな IPv6 機器検証評価を推進する IPv6 Ready Logo に対して、基盤となる評価検証
仕様とテストソフトウェアに関する貢献を行った。 具体的には、MIP、IPSec などである。
(4) 次世代インターネット相互接続性検証の研究開発
本年度は、(a) JGN から JGNⅡへの移行とそれに伴う運用管理体制の整備、(b) IPv6 ならびに広域イーサーネット技術に関する相互接続性の検証、(c) 地域ネットワーク・研究ネッ
トワークとの連携活動 を展開した。 特に、IPv6 を用いて高品質マルチキャスト技術の確立を目指した JGNⅡ上での大規模実証実験を行った。
1.6.3

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

つくばＲＣでは、筑波研究学園都市に集積された大学、公的研究機関、民間企業等の研究者を結集して情報通信分野をリードする研究開発を行うとともに、自治体、公共団体、個人等の参加・協力をえて地域ネットワークを利用した実証実験を行うことにより、拠点研究としての特色を生かした成果を目指している。このように、最先端研究開発のみならず地域社
会の高度情報化にも貢献できることを期待している。
つくばＲＣは、研究開発用テストベッドネットワークＪＧＮⅡの接続点（10 Gbps）であり、ここから全国６３ヶ所のＪＧＮⅡアクセスポイントに接続することができる。また、筑波研
究学園都市内の大学・研究所等を高速アクセスリングで結ぶつくばＷＡＮ（10 Gbps）がつ
くばＲＣ施設内でＪＧＮⅡに接続されているので、つくばＷＡＮ参加機関の研究者はつくば
ＷＡＮ経由でＪＧＮⅡを利用することができる。
つくばＲＣの研究テーマは、「ＧＭＰＬＳネットワーク運用・管理技術の研究開発」（GMPLS:
Generalized Multi Protocol Label Switching）及び「高度ＨＣＩ技術を活用した適応型サービス制御の研究開発」（HCI: Human-Computer Interaction）の２件をコア・テーマとし、関連する多くのサブテーマからなる。サブテーマは以下のとおりである。
ＧＭＰＬＳ関連サブテーマ：「マルチメディア配信のためのネットワーク制御に関する研究」、「GMPLS ネットワーク
における最適ルーティングとフロー制御」、「Grid ミドルウェアによる GMPLS ネットワーク- 17 -

利用技術の研究開発」、「グリッドコンピューティングにおける JGN の有効性実証」
ＨＣＩ関連サブテーマ：「ハプティック・コミュニケーション」、「地域住民の健康増進行動のための SAT 遠隔カウ
ンセリングシステム研究」、「身体的遠隔コミュニケーション空間の研究」、「実空間における
ビデオアバタコミュニケーション技術の研究」、「ギガビット回線でのハイパーミラー対話の研究」「、ギガビットネットワーク上でのミラーインタフェースを用いたコラボレーション環
境に関する研究開発」
つくばＲＣの人員構成は、センター長１名（古賀達蔵）、拠点研究員３名（奥中淳三、岡本修一、岡野介英）、及び特別研究員２０名、合計２４名からなる。特別研究員の研究テー
マ別配置は、ＧＭＰＬＳ関連９名（海老原義彦、亀田壽夫（以上、筑波大）、工藤知宏（産総研）、佐藤一雄（防災研）、高田俊和（ＮＥＣ基礎・環境研）、大谷朋広（ＫＤＤＩ研）、藤
原和弘、（ＮＴＴ－ＣＯＭ），鮫島康則、大原拓也（以上、ＮＴＴ－未来ねっと研））、ＨＣＩ
関連１１名（岩田洋夫、大田友一、山海嘉之、宗像恒次、葛岡英明、橋本佐由理、小木哲朗（以上、筑波大）、森川 治（産総研）、小野澤 晃（ＮＴＴ－ＭＩ研）、田中崇彦（ＮＴＴ－ＣＯＭ）、小田部文彦（つくばマルチメディア））である。
つくばＲＣでは、毎月１回構成員及び関係者を招集してスタッフミーティングを開催し、研究計画の策定、研究成果の向上、構成員の意思疎通などを図っている。同時に、つくばＪ
ＧＮⅡＲＣセミナーを開催し一般に公開している。つくばＪＧＮⅡＲＣセミナーは、原則として、毎月１回中旬の月曜日、１４：００～１５：００に開催する。会場は、つくばＪＧＮ
Ⅱリサーチセンターの２階会議室（約３０人収容）とし、実況をＪＧＮⅡ経由にて受信希望者にマルチキャスト配信する。テーマに関心のある方なら誰でも参加でき、参加は無料である。セミナーの内容は、つくばＪＧＮⅡリサーチセンターが実施する二つの研究テーマ①「GMPLS ネットワーク運用・管理技術の研究開発」②「高度 HCI 技術を活用した適応型サービス制御の研究開発」
を中心にした話題を交互に提供することにしている。
平成１６年度の開催記録は以下のとおりである。
第１回１０月、１４：００～、 参加者１７人①「JGNⅡつくば-大手町高速回線について」
岡本修一 （NICT 拠点研究員 つくばＲＣ（大手町分室））
第２回、１１月１５日（月）、１４：００～、参加者２０人②「遠隔コミュニケーションシステムにおける予期の支援」
葛岡英明（つくばＲＣ特別研究員、筑波大学助教授）
第３回、１２月１３日（月）、１４：００～、参加者２７人①「リアルタイム災害監視への取り組み」（A Trial to the Real-Time Disaster Monitoring」
佐藤一雄（つくばＲＣ特別研究員、防災科技研室長）
第４回、１月２４日（月）、１４：００～、参加者２４人- 18 -

②「ハプティック・コミュニケーション
Communication－

次世代の五感通信に向けて」（Haptic

Toward next generation five-sense telecommunication）

岩田洋夫（つくばＲＣ特別研究員、筑波大学教授）
第５回、２月１４日（月）、１３：００～、産総研と共催、会場：産総研、参加者約６０人①

GMPLS セミナー 「アプリケーションとの連携をめざして」

第６回、３月１４日（月）、１４：００～ 参加者２４人②「JGN 遠隔カウンセリングによる高齢者の精神健康と健康運動行動支援－つくばから北海道岩見沢市高齢者を支援する－」
宗像恒次 （つくばＲＣ特別研究員、筑波大学教授）②「ミラーインタフェースを用いた双方向コミュニケーション」
細谷英一 （NTT-MI 研）、 小野澤 晃 （つくばＲＣ特別研究員、NTT-MI 研）
また、つくばＲＣでは、つくば市、茨城県を中心とした高度情報化に向けた地域活動に積極的に取り組んでいる。各種委員会等への参加状況は以下のとおりである。
関東ＪＧＮⅡ懇話会副委員長（古賀センター長）、茨城県ＩＴ戦略会議委員（古賀センター長）、筑波研究学園都市交流協議会情報交流委員会委員（奥中拠点研究員）、つくばＷＡＮ推進会議委員（上野拠点研究推進部門長）、つくばＷＡＮ運用管理委員会委員（岡野拠点研究員）、つくばＷＡＮ研究交流委員会委員長（古賀センター長）、同委員（岡本拠点研究員）
1.6.4

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

大阪ＲＣでは、「拠点連係型資源共有技術」というテーマのもとに、複数の拠点に跨って設置された計算機群を利用し、計算サービスを実施する場合の CPU やストレージ、ネットワ
ークの帯域などの資源の利用に関する研究開発を実施している。
「拠点連係型資源共有技術」の研究テーマは 2 つのサブテーマからなり、そのすべてを大阪ＲＣ単独で実施している。また、各サブテーマは「拠点連携のためのセキュアな資源共有技術の研究開発」「広域ネットワークにおける大規模データ処理連携技術の研究開発」というテーマで計算資源の共有に関するセキュリティと広域分散処理におけるネットワークとその効率的利用方法に関する研究を図 1.5.4 のような体制で研究開発を実施している。
本研究分野は、ネットワーク、ミドルウェアからアプリケーションまでさまざまな領域に跨る研究であるため、国内外の関係分野の研究プロジェクトと連係して研究効率向上を目指している。また、この連係により、研究開発した技術のアプリケーションへの適用や、大規模な実験を行う事なども視野にいれて研究開発を実施している。この連係の成果として、平成 16 年度はＪＧＮⅡの国際回線を利用し、大阪とアメリカの間を結んで大型電子顕微鏡を用いたアプリケーションのデモンストレーションを実施した。
学会などにおける研究発表やデモンストレーションの他にも、ＪＧＮⅡおよび大阪ＲＣの活動を多くの場で積極的にアピールすることにも取り組んでおり、ＳＣ２００４で他のプロ- 19 -

ジェクトと共同でブースを出展し、パネルの展示やデモを実施した。
1.6.5

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

岡山 JGNⅡリサーチセンターでは、研究開発としての視点だけではなく、市場へどのようなものを普及・発展させていくことが次世代インターネットを進展していくために必要かということに視点を置いて研究項目を選択している。それには、地域ネットワークの岡山情報
ハイウェイとシームレスに接続できている環境があるが、その地域ネットワークと一体的な研究開発環境を地元自治体が積極的に推進していただけることが重要な要素となっている。
このため、岡山情報ハイウェイは、自治体ネットワークとしては始めて IPv6 ネイティブへ早々に対応した。独自 pTLA を取得しての本格的な対応となっている。
このような実環境を活用して岡山 RC では次のような手法・考え方により研究開発を行っている。
１）技術課題の抽出(ア) カテゴリー／利用者毎のトレンド・ニーズに基づいた検証項目を抽出(イ) 地域ネットワークを接続するためには異機種間接続が不可欠(ウ) ベンダー毎に異なる技術動向価値観が顕著①

実装レベルの差異が必然的に起きる所以

２）市場へのフィードバック(ア) 浸透・拡大させるためのアプローチ(イ) 地域ネットワークの高度化と活用術を牽引
３）IPv6 ネットワークの早期普及(ア) JGNⅡv6 へ緩やかな AUP を適用し、普及させることを大前提で取り組む① 他 AS との Peer を実施(イ) JGNⅡv6 上で、理想の次世代インターネットを具現化①

利用者は 1 つのポートで全てが利用できる（ユニバーサルサービス化）(ウ) IPv4 から移行するために必要なものを検証評価し、モデル化（セキュリティ等）
このような環境化において、研究開発という分野だけに傾注せず、エンタープライズやコンシューマなど、多方面で必要なものを積極的リサーチすることで、研究内容の精度向上に努めている。
1.6.6

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

高知 JGNⅡリサーチセンターは，全国 7 リサーチセンターの 1 つとして JGNⅡ研究開発プロ
ジェクトに参加するとともに，四国内唯一の JGNⅡリサーチセンターとして，四国での JGN
Ⅱを用いた研究開発や，相互接続による共同実験などに積極的に参画していくことを期待されている．高知 JGNⅡリサーチセンターは高知工科大学内（教育研究棟 A501-503, A552, 連- 20 -

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

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

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

- 21 -

（Ａ）ネットワーク計測に基づく適応経路制御
トラヒックフロー計測，経路選択，トラヒック制御等の技術を基本として、超高速コア網を横断する通信に対する品質と利用効率の向上のためのエッジにおける経路及びトラヒッ
ク制御を目標としている。また、GMPLS 研究グループ（テーマⅠ）との連携を進めている。
主な研究者は、北辻拠点研究員と特別研究員（九州電力、KDDI 研究所、九州工業大学）である。
（Ｂ）品質を考慮したシームレスな資源利用・割当て制御
無線網，マルチホップ無線，モバイル端末等の技術を基本として、多様な無線網での通信品質と利用効率の向上のための資源利用・割当制御を目標としている。特に、様々な資源利用・割当て技術に関して手法を提案するだけでなく、実用化への試作や特許を狙っている。
主な研究者は、
古閑拠点研究員と特別研究員（パナソニックモバイルコミュニケーションズ、
パナソニックコミュニケーションズ、安川情報システム、東京工業大学、九州工業大学）
である。
（Ｃ）多様性・可変性に適応するＥ２Ｅ通信制御
End-to-End 通信プロトコル（トランスポート，アプリケーション），ルータでのパケット処理等の技術を基本として、多様で可変な網を経由するＥ２Ｅ通信の品質と利用効率の向上のための通信プロトコルやルータ支援を目標にしている。また、高速トランスポートプロト
コル技術に関して JGNⅡの国際回線を利用し、国際共同実験（イリノイ大）を実施している。
主な研究者は、熊副拠点研究員と特別研究員（九州電力、インテック・ウェブ＆ゲノムイン
フォマティクス、九州大学、九州工業大学）である。
これらの研究において、平成１６年度は、サブテーマ A ではフロー計測技術及びフロー多重化技術に関する研究開発を、
サブテーマ B では単一無線網での資源利用制御及び複数異種アクセス網での資源利用制御に関する研究開発を、
そしてサブテーマ C では高遅延帯域幅環
境でのデータ転送技術及びルータ支援によるパケット制御技術に関する研究開発を行い、査読付き国際会議８件を含む１４件の対外発表、プロトタイプ試作や国際共同実験などの成果を上げた。
また、6 月の第一回 JGNⅡワークショップでは熊副研究員が研究報告（「高速大容量ネット
上の通信技術」）を行い、11 月には、北九州 JGNⅡリサーチセンターにおいて、「ユビキタス時代のアクセス系ネットワーク研究」と題して、第二回 JGNⅡワークショップを主宰し、会
場参加者８４名、ストーリミング視聴者５２件の参加を得ることができた。そこでは、古閑研究員の研究報告（「ユビキタス時代の新たなネットワークアーキテクチャ」）と福田研究員の研究報告（「アクセスネットワーク資源管理」）も行われた。
さらに、1 月に行われた「JGNII シンポジウム 2005 in 大阪」では、鶴研究員による研究紹介（「北九州 JGNII リサーチセンターにおける研究開発」）と、デモブースにおける各テー
マの研究デモンストレーションを行った。
サブテーマ A：トラヒック特性に着目したトラヒックフローのパス割り当ての効果を細粒- 22 -

度フロー計測とフロー多重の観点から実演し、トラヒックエンジニアリングに通信の品質保証を取り入れることの有効性を紹介。
サブテーマ B：複数のアクセス網へ同時に接続するマルチホーム環境において、新たな通信層として提案しているアソシエーション層をプロトタイプ実装した PC を用い、シームレ
スな通信メディア切り替えを実演。
サブテーマ C：JGNII 国際回線を利用して、北九州リサーチセンターと米国に設置されている PC 端末間で様々な高速トランスポートプロトコル(HSTCP, FAST, CUBIC, UDT)を利用した伝送実験を実施。
一方、北九州 JGNⅡリサーチセンターは、NICT 北九州 IT 研究開発支援センターと同じフロアにあるが、そこは JGNⅡの九州内の 2 つのコア・アクセスポイントの１つになっており、
リサーチセンターと IT 支援センターが連携して、JGNⅡを使った各種ネットワークイベント
等をサポートしており、九州地区の JGNⅡ活動の中核としての役割を果たしている。

- 23 -1.7

JGNⅡ主催研究発表会等

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

JGNⅡシンポジウム2005 in 大阪 プログラム
1/18（火）大阪国際会議場
10:30

サブ テーマ：新たなValueを 創出する JGNⅡ
1/1 ７（月）大阪国際会議場

12:00（ NICT 理事長）

12:00

あ い さ つ 長尾

14:00

鬼頭 達男（ 総務省 大臣官房技術総括審議官）
宮原 秀夫（ 大阪大学 総長 ）14:30

齊藤 忠夫 (東京大 学 名誉教 授)

14:50 議題 J GN Ⅱへの 期待

特別講演 １
秋山 正樹 (松下電器産業(株)パナソニックシス テムソリューションズ社 社長)
議題 ユ ビキタス ネッ トワーク社 会に向けて

15:20

特別講演２
村井 純 (慶應義塾大学 教授:遠隔出演）
議題 JGNⅡ:グローバルR&Dへの貢献と責任

15:20
16:00

特別講演３（同時通訳）
テーマ「Using Op tIPuter Inn ov ation s to En able
Lambd aGrid Application s」
14:10
Larry Smarr (米国UCSD Professor:遠隔出演)

14:30

16:20 ス ペシャルセ ッ ショ ン
テーマ ： 新た な Valu e を 創出す るネットワー ク
コーディネータ： 下條 真 司 （ 大 阪大学 教授）
相原 玲二 （ 広島 大学 教授）
パネラー ： 香取 啓志 (朝日 放送株 式会社 放送 技術局 局 次長)
塚 本 昌 彦 (神 戸大学 教 授)
森 広 芳 照 (京 都大学 教 授)

16:00

16:15

18:10
18:30～

シンポ ジウム懇親会[於:大阪国際会議場10 F 1001,1002会議室]

18:00

1/19（水）大阪大学中之島セン ター
9:00

共催研究会によるパラレルセッショ ン
電子情報通信学会 IA研究会
MoMuC委員会
TAI委員会
情報処理学会
QAI研究会

昼 食（各 自）13:30

14:30 基調講演

14:50

研究 発表
チ ェア : 青山 友紀 (東京 大学 教授)
発表 者 :清水 克 宏(三菱電 機(株) 情 報技術 総合研 究所
光通 信技術 部 チー ムリーダ ー）
尾家 祐二 (JGN Ⅱ プロ ジェ クト 総括 責任者)
鶴 正人 ( 北九州JGN Ⅱ RC 主 席拠点 研究員)
馬 場 健一(大阪JG N Ⅱ R C 主席拠 点研究 員)
久保 田 文人(N ICT情 報通信 部門 研究 主管)

パ ネルデ ィスカ ッショ ン１： 国際連 携（同 時通訳 ）テ ーマ： 研究開 発テス トベッ ドの国 際連携
チ ェア： 池田 佳和（ 東京工 業大学 特任 教授）
パ ネラー ：青山 友紀 （東京 大学 教授）
後藤 滋樹 （早稲 田大学 教授 ）M a ll i k T at i pa m ula(米 国ｼ ｽ ｺｼ ｽ ﾃﾑ ｽ ﾞ社 S en i or Pr o du c t M an a ge r )五十 嵐 喜 良（ NI C T国際 連携室 室 長: 遠隔出 演）

パネルディス カッシ ョン ２：
テーマ ：グロー バルミド ルウェア（u- Ja pan のバッ クエ ンド）チ ェア： 尾家 祐二（ 九州工 業大学 教授 ）パ ネラー ：阿留 多伎 明良 ( NE C ｼｽ ﾃ ﾑﾌ ﾟ ﾗｯ ﾄ ﾌｫ ｰ ﾑ研究 所 所 長)
江﨑 浩（ 東京大 学 助 教授）
島村 和典 （高知 工科大 学 教 授）
薮崎 正実 （M o Mu c 委員長 ）山口 英（ 奈良先 端科学 技術大 学院大 学 教 授）

12:00

食
自）

13:00

共催研究会によるパラレルセッショ ン
電子情報通信学会 IA研究会
MoMuC委員会
TAI委員会
情報処理学会
QAI研究会

18:20

パネ ル展示およびデモ展示 [於:大阪国際会議場 3 F イベント ホールC～D,E:デジタルシネ マのデモ]※スケ ジュー ル、出演者等は、予告なく 変更す ること がござい ますので、あ らかじ めご了承くだ さ い 。

図 1.7.1 JGNⅡシンポジウム 2005 in 大阪 プログラム- 24 -

昼（各図 1.7.2 パネル展示及びデモ展示内容- 25 -

NICT では、研究開発テストベッドネットワーク「JGN2 」に関する、初めてのシンポジウムを 1 月 17 日（月）から 19 日（水）まで、大阪国際会議場などで開催しました。シンポジウムでは、JGN2 での研究活動の紹介や地域における JGN2 の利活用、国際連携の方向性などをテーマとした多彩なプ
ログラム、パネル・デモ展示が行われました。
長尾理事長の開会挨拶、ご来賓の総務省の鬼頭技術総括審議官、大阪大学の宮原総長からの挨拶に続き、東京大学名誉教授の齊藤先生から「JGN2 への期待」と題した基調講演をいただき、 JGN2 を取り巻く環境の変化や多様なネットワークサービスの展開などについてお話を伺うことができました。
産業界からは松下電器産業株式会社パナソニックシステムソリューション
ズ社の秋山社長より、情報家電の取り組みなど、ユビキタスネット社会への展望について、様々な角度から講演をいただきました。一般生活者の未来像についての具体例を示されるなど、大変夢のある講演でした。
引き続いて行われた慶應義塾大学の村井教授の講演、そして 2 日目に行われたカルフォルニア大学サンディエゴ校の Larry Smarr 教授の講演は、共に遠隔地から HD 伝送技術を利用し、高精細画像による講演となりました。
スクリーン上に映し出された映像は高精細で臨場感があり、参加者の興味を大いに誘いました。また、デモ展示会場では、高精細な 4k デジタルシネマ
技術を用いた映像が上映され、デジタルシネマの迫力を実感してもらうことができました。これも超広帯域（20Gbps ）なネットワークを提供している「JGN2 」ならではの演出ではなかったかと自負しております。
今回のシンポジウムの大きなテーマの 1 つである国際連携については、
Smarr 教授の遠隔出演による講演と、「研究開発テストベッドの国際連携」をテーマとしたパネルディスカッションがあり、双方の会場全体を巻き込み活発な質疑応答がかわされるなど、大変興味深い内容となりました。両プログラ
ムとも、「JGN2 」の国際連携の可能性を感じさせるものであり、国際共同研
究の今後の推進について参加者からも多くの期待を集めていました。
さらに拠点連携型資源共有技術、教育、ブロードバンド、ウエアラブル、
関西のネットワーク事情、グローバルミドルウエアなどについて、各界から参加していただいたパネリストによる、白熱した議論が展開されました。
今回のシンポジウムは、1 月 17 日、18 日の 2 日間でのべ約 750 名の参加をいただき、また、1 月 19 日には共催の電子情報通信学会インターネット
アーキテクチャ研究会などでも多数の参加者を得て、活発な意見交換が行われ、盛況なうちに幕を閉じました。 最後に、このシンポジウム開催にあたり、ご協力をいただきました皆様方にこの場をお借りしてお礼を申し上げます。

図 1.7.3

NICT ニュース（№348）に掲載した開催報告- 26 -

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

第１回ワークシ ョッ プの模様
１１ 名名 称称研究推進部会 JGNⅡ第１回ワ ークショップ ～光コ アネットワ ー クとGMP LS研究～研究推進部会 JG NⅡ第１回ワ ークショップ ～光コ アネットワ ー クとGMP LS研究～２２ 場場 所所
KDDI大手町ビ ル２F K DDIホール
KDDI大手町ビ ル２F K DDIホール
３３ 時時 期期
平成１６年６
平成１６年６月２８日（月月２８日（月））４４ 概概 要要JGJGNⅡの光コア
NⅡの光コアネットワーク
ネットワークについて、研について、研究サイドと利究サイドと利用サイドの意
用サイドの意見交換を行う
見交換を行うことことによりJG NⅡの研究 ・利用の促進 を図ることを 目的に、オー プン参加によ る討論を主体 とによりJG NⅡの研究 ・利用の促進 を図ることを 目的に、オー プン参加によ る討論を主体 としたワークショップを開催した。
したワークショッ プを開催した 。
５５ 参加者数
参加者数
約約１１０名（KD
１１０名（KDDIホール）
DIホール）
６６ プログラムプログラム（１）開催挨拶 ・ワークショ ップ趣旨説明 （尾家研究推 進部会長/総括 責任者）
（１）開催挨拶 ・ワークショ ップ趣旨説明 （尾家研究推 進部会長/総括 責任者）
（２）JGNⅡ光（２）JGNⅡ光コア
コアネットワーク
ネットワーク研究担当リサ
研究担当リサーチーチセン
センター（つくばRC
ター（つくばRC古賀セ
古賀センター長）
ンター長）
JGNⅡ テストベッド ：JGNⅡ テストベッド ：GNⅡの構築（NICT
総合企画部企
画戦略室
島田マネージャー）（３）J（３）J GNⅡの構 築（NICT 総合企画部企 画戦略室 島田マネージ ャー）（４）J
GNⅡの研究開発および
究開発および利用（NI
利用（NICT拠点研究推
CT拠点研究推進部門テスト
進部門テストベッド推進室
ベッド推進室河野室
河野室（４）JGNⅡの研長）
長）（５）国際回線（５）国際回線（日米）の状（日米）の状況（総務省情況（総務省情報通信政策局
報通信政策局宇宙通信調査
宇宙通信調査室室岡野室
岡野室長）長）
コアネットワーク 研究の発表：
コアネットワーク 研究の発表：（６）GMPLSネットワーク運用・管理技術に技術に関する
関する研究（つくばR
研究（つくばRCC岡本拠点研究
岡本拠点研究員）
員）（６）GMPLSネットワーク運用・管理（７）GMPLSネットワ
ークにおけおける管理情報流る管理情報流通技術の通技術の研究（つ研究（つくばRC
くばRC藤原特別藤原特別研究員）
研究員）（７）GMPLSネットワークに通信研究部門久保田
研究主管）（８）けいはんなオープンラボの研究開発（NICT情報（８）けいはん なオープンラ ボの研究開発 （NICT情報 通信研究部門 久保田 研究主管）
利用側の研究・技術動向；
利用側の研究・技 術動向；
（９）グリッド とネットワー ク（つくばR C 工 藤特別研究員 ）（９）グリッド とネットワー ク（つくばR C 工 藤特別研究員 ）（10）光ネット（10）光ネットワークとグリ
ワークとグリッド（大阪R
ッド（大阪RCC野野呂拠点研究員
呂拠点研究員））（11）高速大容 量ネット上の 通信技術（北 九州RC 熊副拠点 研究員）
（11）高速大容 量ネット上の 通信技術（北 九州RC 熊副拠点 研究員）
（12）波長パス（12）波長パスをベースとすをベースとするIXの研究（KDるIXの研究（KDDI研究所
DI研究所田中グルー
田中グループリーダー）
プリーダー）（13）グローバ
ルな１０Gラムダネッ
Gラムダネットワークの研
トワークの研究開発動向（
究開発動向（江﨑副総括責
江﨑副総括責任者）
任者）（13）グローバルな１０
討論会： J GNⅡ光 コアネットワ ークの研究と 利用に向けて
討論会： J GNⅡ光 コアネットワ ークの研究と 利用に向けて

図 1.7.4 第１回ワークショップの模様- 27 -

研究推進部会 尾家部会長の挨拶

つ くばRC 古賀セン ター長の挨拶

聴講の様子第2回ワークショップの模様
１ 名 称 研 究推進部会 JG NⅡ第2回ワー クショップ： ユビキタス時 代のアクセス 系ネットワ
１ 名 称 研 究推進部会 JG NⅡ第2回ワー クショップ： ユビキタス時 代のアクセス 系ネットワ
ーク研究
ーク研究
２ 場 所 小 倉AIMビル８ Ｆ（北九州市 ）２ 場 所 小 倉AIMビル８ Ｆ（北九州市 ）３ 時 期 平成 １６年１１月 １日（月）３ 時 期 平成 １６年１１月 １日（月）
４ 概 要
４ 概 要
JGN Ⅱのアクセス 系ネットワー ク研究につい て、J GNⅡの 研究・利用促 進を図ること を目JGN Ⅱのアクセス 系ネットワー ク研究につい て、J GNⅡの 研究・利用促 進を図ること を目的に、オープン参 加による討論 を主体とした ワークショッ プを開催した 。
的に、オープン参 加による討論 を主体とした ワークショッ プを開催した 。
５ 参加者数 ８４名 （小倉AIMビ ル８Ｆ）
５ 参加者数 ８４名 （小倉AIMビ ル８Ｆ）
６６ プログラムプログラム（１）開会挨 拶 松井房樹 (総務省九 州総合通信局 長)（１）開会挨 拶 松井房樹 (総務省九 州総合通信局 長)（２）J GNⅡ リサーチセン ターの最新研 究状況（２）J GNⅡ リサーチセン ターの最新研 究状況①大阪 RC①大阪 RC
大阪RCの
大阪RCの最新研究状況
最新研究状況（下條副総括（下條副総括責任者)
責任者)
大阪RCの 拠点連携型資 源共有技術に 関する 研究報告（大阪R C 野呂 拠点研究員 )大阪RCの拠点連携型資源共有技術に関す る 研究報告（大阪R C 野呂 拠点研究員 )②つくばRC②つく ばRC
つ くばRCの 最新研究状況 （古賀副総括 責任者)
つ くばRCの 最新研究状況 （古賀副総括 責任者)
つ くばRCの GMPLS 関連研究報告（つ くばR C 大 谷特別研究員 )つ くばRCの GMPLS 関連研究報告（つくばR C 大 谷特別研究員 )③東北 RC③東北 RC
東北R Cの最新研 究状況（曽根 副総括責任者 )東北R Cの最新研 究状況（曽根 副総括責任者 )④高知④高知RC：RC：
高知R
高知RCの最新研
Cの最新研究状況（福本究状況（福本副総括責任者
副総括責任者) )（３）NI（３）NICTの最新研究
CTの最新研究状況（NI
状況（NICT総合企画部企
CT総合企画部企画戦略室
画戦略室住友主任研
住友主任研究員)
究員)（４）総務省 におけるＲ＆ Ｄの動向（総 務省情報通信 政策局技術政 策課 翁 長課長補佐 )（４）総務省 におけるＲ＆ Ｄの動向（総 務省情報通信 政策局技術政 策課 翁 長課長補佐 )（５）モバイ ルインターネ ットワーキン グへのロード マップ（５）モバイ ルインターネ ットワーキン グへのロード マップ（NICT横 須賀無線通信 研究セン ター 井上主 任研究員 )（NICT横 須賀無線通信 研究セン ター 井上主 任研究員 )（６）テーマ パークを舞台 にしたユビキ タスシーンと その可能性（６）テーマ パークを舞台 にしたユビキ タスシーンと その可能性（ 富士通プ ラ イムソフトテ クノロ ジ 第4開発統括部 第1開発部 木全課長代 理)（ 富士通プ ラ イムソフトテ クノロ ジ 第4開発統括部 第1開発部 木全課長代 理)（７）IE EE 802.16(WiMAX)関連の技 術動向（ K DDI研究所YRPリ サー チ セン ター 野原セン ター長)
（７）IE E E802.16(WiMAX)関連の技 術動向（ K DDI研究所YRPリ サーチ セン ター 野原セン ター 長)（８）ユ ビ キタス時代の新 たな ネットワ ークアー キテ クチ ャ（北九州R C 古 閑拠点研究員 )（８）ユビ キタス時代の新 たな ネットワ ークアー キ テ クチ ャ（北九州R C 古 閑拠点研究員 )（９）ア クセ スネッ トワ ー ク資源管理～ワ イ ヤレスLANに お い て（北九州R C 福 田特別研究員 )（９）ア クセ スネッ トワ ー ク資源管理～ワ イ ヤレスLANに お い て（北九州R C 福 田特別研究員 )（１０）トークセ ッション～今 後のJ GNⅡ利用 研究に向けて ～（尾家総括 責任者・下條副 総括（１０）トークセ ッション～今 後のJ GNⅡ利用 研究に向けて ～（尾家総括 責任者・下條副 総括
責任者)
責任者)

図 1.7.5 第２回ワークショップの模様- 28 -

松井九州総合通信局長の挨拶

聴講の模様

ト ークセッショ ンの模様

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

第2章
2.1

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

概要

本研究課題は、これまでのインターネットには不足していた安心安全な情報通信サービスを提供するとともに、今後も進展するブロードバンド化(高帯域化)に対応するための基盤技術の確立と、技術の確立することをその研究目的としている。 具体的には、以下の研究開発活動を展開している。
・ ネットワーク構築運用支援ツール群の研究開発
・ 広域高信頼ネットワーク接続性提供技術の研究開発
・ IPv6 機器検証評価手法とツールの研究開発
・ 次世代インターネット相互接続性検証の研究開発
・ GMPLS ネットワーク運用管理技術の研究開発
これらの研究開発課題を、以下のリサーチセンターにおいて実施している。
(1) 大手町 JGNⅡリサーチセンター (統括責任者：江崎浩)
東京都千代田区大手町の NTT コミュニケーションズ大手町ビル内を拠点とし、拠点研究員 1 名(山森雅文)、特別研究員 12 名で、(a) ネットワーク構築運用
支援ツール群の研究開発、(b) 広域高信頼ネットワーク接続性提供技術の研究
開発、(c) IPv6 機器検証評価手法とツールの研究開発 に関する研究開発を展開している。
(2) 岡山 JGNⅡリサーチセンター(統括責任者：小林和真)
岡山市大内田のテレポート岡山ビル内を拠点とし、拠点研究員 1 名(美甘幸路)、
特別研究員 2 名で、次世代インターネット相互接続性検証の研究開発に関する研究開発を展開している。
(3) つくば JGNⅡリサーチセンター(統括責任者：古賀達蔵)
茨城県つくば市吾妻を拠点とし、拠点研究員 3 名(奥中淳三、岡本修一、岡野介英)、特別研究員 21 名で、GMPLS ネットワーク運用管理技術の研究開発 に関する研究開発を展開している。
各リサーチセンターとも、多数の特別研究員を産業界から招聘し、さらに、研究開発活動を推進する上では、積極的に産業界や学会の研究開発機関やコンソーシアムとの協力関係を確立しながら研究開発活動を推進している。 協力関係は、国内のみならず、
既に国際的な展開を見せている。
以下、各研究課題の本年度の成果の概要を述べる。
(1) ネットワーク構築運用支援ツール群の研究開発- 29 -

実ネットワークにおいて必要となるネットワークの構築運用支援ツールを研究開発し、これを、可能な限りオープンソフトウェアとして提供することを目指している。本年度は、MPLS ネットワークにおける LSP の設定と管理を支援し、さらに、ネットワーク運用を支援するツール群の研究開発、ならびに、レイヤ２やレイヤ 1の情報とレイヤ３の情報を統合化したマルチレイヤネットワークトポロジー管理
ツールの研究開発を行った。研究の推進にあたっては、DISTIX と協調しながら行った。
(2) 広域高信頼ネットワーク接続性提供技術の研究開発
超広帯域および高信頼の接続性を提供するための基盤技術の研究開発を行うことを目的としている。本年度は、次世代経路制御アーキテクチャ(IRIDES)の基礎検
討、マルチホームサービス提供アーキテクチャの研究開発、VoIP/SIP システムの相互接続性確立のための研究開発、さらに、我が国の総インターネットトラフィ
ック量の測定と解析に関する研究開発を行った。 本研究課題の推進にあたっては、
JPNIC や TTC、VoIP 推進協議会、HATS など、あるいは 大手 ISP など、極めて多数の組織との協調関係を確立しながら行った。
(3) IPv6 機器検証評価手法とツールの研究開発
TAHI プロジェクト、IPv6 普及高度化推進協議会、IPv6 Forum との協調関係を構築し、グローバルな IPv6 機器検証評価を推進する IPv6 Ready Logo に対して、基盤となる評価検証仕様とテストソフトウェアに関する貢献を行った。 具体的には、
MIP、IPSec などである。
(4) 次世代インターネット相互接続性検証の研究開発
本年度は、(a) JGN から JGNⅡへの移行とそれに伴う運用管理体制の整備、(b) IPv6
ならびに広域イーサーネット技術に関する相互接続性の検証、(c) 地域ネットワーク・研究ネットワークとの連携活動 を展開した。 特に、IPv6 を用いて高品質
マルチキャスト技術の確立を目指した JGNⅡ上での大規模実証実験を行った。
(5) GMPLS ネットワーク運用管理技術の研究開発
本研究課題では、(a)マルチレイヤネットワーク統合管理技術、(b) GMPLS ネット
ワークの高機能高信頼化技術、(c) マルチドメイン(E-NNI)統合管理技術 に関する研究開発を推進した。

- 30 -

2.2
2.2.1

ネットワーク構築運用支援ツール群の研究開発
ネットワーク構築運用支援ツール群の研究開発(a) MPLS 網における LSP 監視ツールの検証
この節では、MPLS 網におけるＬＳＰ監視ツールの検証について記述する。
ＭＰＬＳは、トラフィックエンジニアリング・高速パス切り替え・マルチサービス
等の特徴を持ち、通信キャリアや広域研究バックボーンなど大規模なネットワークのコア網技術として広く使われている。ＭＰＬＳは、ＩＰヘッダとレイヤ２ヘッダ（例
えば、イーサネットヘッダ）の間に、シムヘッダとよばれるＭＰＬＳで使われるラベ
ルによって転送される。このラベルを使って、物理網の上に論理的なパス（ＬＳＰ：
Label Switched Path）を構成する。これは、イーサネットのＶＬＡＮやＡＴＭなどと同じ論理パスが構成される。
ＩＰのネットワークでは、ルータとそのルータを接続するリンクという単純な構成であるため、例えば、下の図のように簡単に絵画することができ、様々な、ＩＰネッ
トワークの監視ソフトウエアが存在する。しかし、ＭＰＬＳは、上記で説明したようにＩＰネットワーク上に乗る論理ネットワークであるため、視覚的な監視ソフトウェ
アを作成するのが困難である。例えば、図 2-2-1-1 の矢印は、ＭＰＬＳパスを示している。このように複数のルータを介して接続する論理パスのため、監視ソフトウェア
での表現が難しい。また、マルチベンダーでは、それぞれのルータでのＭＰＬＳパスの出力方法が異なるために、実装が困難である。
本検証では、インテック・ネットコア社が作成しているＭＰＬＳパス監視ツールをお借りして、JGN II 上に構築している MPLS 網の監視を行った。この監視を通して、
マルチベンダーの時に問題となることをまとめ、マルチベンダー環境におけるＭＰＬ
Ｓ網のＬＳＰ監視に必要な技術を列挙する。
まず、図 2-2-2-2 に示した実験ネットワーク構成を用いて、説明する。実験ネット
ワークでは、３種類のルータで構成されている。シスコシステムズ社製 GSR, ジュニ
パーネットワーク社 M シリーズルータ、古河電工社製ルータである。下図の拠点にルータを設置し、JGN II の L2 接続によってそれぞれのルータを接続している。
各ＭＰＬＳコアルータには、図 2-2-2-3 のようなＭＰＬＳエッジルータを接続し、様々な実験トラフィックを流している。これは、本検証環境を出来るだけ実際の運用
環境に近づけるためである。

- 31 -

図 2-2-2-1

札幌

JAIST
九大

金沢

福岡

富山
KDDI
大手町

大阪
TP岡山

岡山

高知
大手町

図 2-2-2-2- 32 -

2005.5 現在

高知工科大

QGPOP

HTCN

FITWeb

HOTnet

大分大

あやめ

W&G

北海道大

JAIST

九大

NORTH

富山
札幌

岡山

高知

堂島

IAMAS

NTT大手町

MCI

麗澤大

CSI

名古屋大

HOTnet

山口大

ASTEM

データコア

改

SQEX

hi-ho

KDDI大手町

mpls ASSOCIO

inetcore
山梨女短大

図 2-2-2-3
本実験環境で、ＭＰＬＳパス監視ソフトを使い、ＭＰＬＳ LSP の登録および表示を確認した。結果は、下図のように各ルータから設定されている LSP が画面上に表示されている。表示上は、どのベンダーでも同じように表示しているが、ルータからの出力される形式が違うので、多数のベンダーの監視ソフトを現状のルータの実装で作成するのは困難だと考えられる。例えば、シスコシステムズ社製ルータは、Internet-Draft に沿った MIB の実装を行っている。ジュニパーネットワークス社製ルータは、ベンダー独自 MIB で実装している。古河電工社製ルータは、RFC 準拠の標
準 MIB で実装している。このように３社のベンダーによって、実装方法が異なっている。また、ＭＩＢでは取得できない情報もあり、この情報は、XML を使う junoscript
や telnet による CLI からの取得を行う必要があり、これもベンダーごとに異なる。
このように、複数のベンダーを統合的に監視するには、現状の仕組みだけでは困難であることがわかる。また、標準 MIB を使っていても、ＭＰＬＳ LSP の経路の表現方
法が異なることがわかった。例えば、シスコシステムズ社製ルータでは、あるバージ
ョンまでは、ルータの出口側のＩＰアドレスを記載していたが、他のバージョンでは、ルータのループバックアドレスが記載される。

- 33 -

図 2-2-2-4
このように、telnet, XML, SNMP のようにルータからの取得方法が異なったり、SNMPという標準のプロトコルがあるが、その枠組みでは定義されていない情報も存在する
ことがわかった。
そこで、マルチベンダー環境のＭＰＬＳ網の監視を単純化するためには、マルチベ
ンダー環境でも使用できる、情報取得アーキテクチャを作成する必要がある。標準的なＳＮＭＰを用いて情報取得できるばあいは、それを使用する。ただし、取得できる情報が異なる場合があるので、必要に応じてＭＩＢ定義を改訂・明確化する必要がある。SNMP で取得できない情報に関しては、各社の CLI で取得するには標準を作成し、それをもとに情報取得できるようにすると複雑になってしまうため、新しい情報取得
アーキテクチャ（例えば、XML conf 等）を作成し、それを標準として実装していく必要がある。

- 34 -

2.2.22.2.2.1

マルチレイヤトポロジー管理ツール
概要

ネットワーク上に流れるデータ量は依然として指数関数以上の速度で増大している。 それに伴いネットワーク基盤の継続的な整備が行われているが、 様々なネット
ワーク機器が必要に応じて適宜配置されることにより、ネットワークトポロジはます
ます複雑化している。このように、ネットワーク上を流れるトラフィックの流量が増
大し、トポロジも複雑化してきた結果、ネットワークの状態を把握するのが困難になり、ネットワーク上に輻輳などの障害が頻繁に発生するようになってきている。
本節では AS 内のネットワークのトラフィック情報を収集し、それを視覚化することで、予想される輻輳などの障害を回避し、より効率的なネットワークの運用を支援するためのツールの作成を行った。 具体的には以下を実現した。
ネットワーク上にある各リンクの帯域幅とトラフィック量の関係を視覚化
1. snmpwalk を定期的に実行し、帯域幅とトラフィック量の情報を収集
2. 収集した情報から帯域幅に応じた線の太さの表示
3. 各リンクの入力と出力を有向グラフで表示
4. 帯域占有率に対する閾値の導入
5. レイヤ 2 スイッチの概念の導入
これらの機能を実現することにより、ネットワーク上で問題が発生している場合には、その場所の特定がより正確に、より容易に実現されるようになる。 また、問題の原因が輻輳かリンクダウンかといったことも容易に判断可能となる。 さらに、シミュレー
ションツールを用いることによって、ネットワーク上で新たにトラフィックに発生させたり、リンクのコストを変化させた場合のネットワーク全体に及ぼす影響を予測することなどが可能になった。しかし、本研究で実現した機能では実際のネットワーク
において、トラフィックがどのように流れているかということを把握することができない。また、リンクのコストを変更することは可能であるが、より効率的にネットワークを運用するためにはどのようなコストを与えればよいか、という問題は解決するには至っておらず今後の課題である。
2.2.2.2

研究の背景

常時接続を前提としたブロードバンドなインターネット環境の家庭への普及が急速に進展しており、その結果個人が映像や音声のような広帯域で高速なディジタル通信行うことができるようになった。このような広帯域のディジタル通信を収容しサービスするために、インターネットのバックバーンではギガビット単位でのパケット転送を行うためのネットワーク基盤の整備が進められている。インターネットはネット
ワークのネットワークであり、しかも特にバックボーンのトポロジは単純なスター状- 35 -

ではなく、複雑な網の目状の構成となっているのが一般的である。 複雑なネットワー
クトポロジにおいて、データを送信元の計算機から、送信先の計算機へと正しく配送する機能のことをルーティングと呼ぶ。
インターネットにおいて一般的に導入利用されている経路選択の方式としては
RIP(Routing Information Protocol)や OSPF(Open Shortest Path First)、BGP(Border
Gateway Protocol)といったものがあり、これらをルーティングプロトコルあるいは経路制御プロトコルと呼ぶ。 ルーティングプロトコルを用いて IP パケットの中継作業を行う計算機のことをルータと呼ぶ。各ルータは、ルーティングプロトコルを用いて自律的に経路の選択を行っており、ある計算期間でのデータ通信においてその通信が生成するパケットが実際にどのような経路を経由して目的の計算機に転送されるのか正確に把握するのは容易ではない。その結果、ネットワークの運用管理者が想像していない場所においてトラフィックの輻輳が起こってしまい効率的なネットワーク運用が困難になってきてしまっている。また、ネットワーク内にあるリンクに障害が発生すると、他のリンクに負荷がかかることになるが、どの程度の負荷を生じるかということを正確に把握することできず、最悪の場合には連鎖的な輻輳を起こすなど、ネットワークに混乱を来たす場合もある。このような問題を回避、解決し、効率的なネッ
トワークの運用を行う手法のことをトラフィックエンジニアという。トラフィックエ
ンジニアリングを実現する方法としては、コンストレイントルーティング(Constrained Routing)という手法を用いることにより、通常の選択される経路とは異なるものを明示的に指定する方法や、MPLS(Multi Protocol Label Switching)を用いた経路制御で選択される経路以外を LSP(Label-Switched Path)によって設定する方法などが上げられる。 これらの他にもトラフィックエンジニアリングを実現するための方法が数多くなされているが、決定的な解決法は未だ見出されていないのが現状である。
ネットワークを運用する際に、障害などが発生した際に、発生地点と原因を究明し、速やかに対処を行うことが重要である。そのためには、ネットワークの現状がどのようになっているかということを把握必要がある。このような、ネットワークの状況を把握する方法としては、様々な方法が用いられている。例えば、MRTG は任意のルータのトラフィックを時系列で観測する事が可能である。
しかしながら、複数のマシンの情報を一度に表示し、状態を評価する事は容易な機能ではない。一方で、ネットワークの状態を把握するには、ネットワーク上にあるマシンの全てのインターフェイスにおける情報を同時的に観測していなければならない。
そうすることで、初めてネットワーク上の障害検知などが可能となり、また障害がどの程度の範囲で生じているかの判断も可能となる。しかし、障害を検知してから対処するまでに時間を要してしまう。また、効率的なネットワークの運用を実現するために、様々なトラフィックエンジニアリング技術が提案され、導入されているが、その- 36 -

効果を安全な場所で検証するのは難しい。 なぜなら、その効果を検証するためには実ネットワークを再現する必要が出てくるが、大規模なネットワークをそのまま再現する事は難しく、実験室で小規模なネットワークを再現せざるを得ないからである。
2.2.2.3

提案実装するトラフィック監視管理手法

2.2.2.3.1

システムの要求条件

現在ネットワークを効率的に運用するには、様々な問題があると考えられる。以下の 2 点に焦点を絞り研究を行った。
(1) ネットワーク全体の状況の把握
ネットワーク全体の状況を一目で判断可能となると、障害が起こっている場所を瞬時に特定でき、それが輻輳によるものなのか、リンクダウンによるものなのかということがわかる。また、輻輳であった場合にはその範囲を特定することも可能となり、輻輳を引き起こしているフローにも、推測が可能となる。
(2) 実ネットワークの安全な環境での再現
実ネットワークを再現し、また、ネットワークのトラフィックに関する十分なデータを収集しておくことにより、障害の原因の検証を行いやすくなる。また、新たなトラフィックを流す際に、そのフローがネットワーク全体に対してどのような影響を与えるかということも推測可能となる。
このような要求条項を満たすために、具体的には本研究では、以下の 2 点の実現をその目標と設定した。
1.

ネットワークのトポロジを視覚的に描写し、各リンクに流れるトラフィッ
クをその図にマッピングすることにより、ネットワーク状態を視覚化する

2.

OSPF ネットワークにおいてフローを流たり、コストの変更などを行い、その影響をシミュレーションする環境の構築

以下では、ネットワーク状態の視覚化をするのに必要な要件について議論し、さらに、これをもとにシミュレーションをするために必要な要件について議論する。
2.2.2.3.2

帯域幅とトラフィック量の関係を視覚化

2.2.2.3.2.1

実装システムの概要

ネットワークの状態を把握するには、現在ネットワークにかかっている負荷率や、帯域にどの程度余裕があるかという情報が必要になってくる。 それを満たすために本研究では、以下の 5 点を実現した。
(1)

snmpwalk を定期的に実行 ： snmpwalk をネットワーク上にある全ての計算機に対して実行し、各計算機のインターフェイスの帯域幅情報、トラフ- 37 -

ィック情報を取得することにより、同時的にネットワーク全体の状態を把握することが可能となる。
(2)取得した情報から帯域幅に応じた線の太さの表示：

1 で取得した情報の中に、帯域幅が含まれているので、ネットワークトポロジを作成する際に、帯域幅の対数をとったもので線の太さを描写し、それにより、各リン
クにどの程度トラフィックを流すことが可能かの判断が容易になる。
(3)

各リンクの入力と出力を有向グラフで表示 ： OSPF ネットワークの場合、あるリンクに対して、アップ方向とダウン方向に対してそれぞれ別にコストを設定することが可能である。 両者でコストが異なる場合、どちらのトラフィックにより負荷がかかっているかといった判断が容易になる。

(4)

帯域占有率に対して段階的な閾値を導入することによる、各リンクの利用率(負荷率)の視覚化 ： 帯域占有率に応じて色分けをすることで、現在リンクにどの程度負荷がかかっているかを認識することが容易になる。 そこで、負荷がかかっている場所の発見が視覚的に可能になり、対処を行な
いやすくなる。

(5)

レイヤ 2 スイッチの概念を導入することによりきめ細かなネットワーク
トポロジの再現 ： レイヤ 2 スイッチをトポロジに再現することにより、
VLAN のように、一つの物理インターフェイスに複数の IP アドレスが割り当てられているものや、逆に複数のインターフェイスに同一の IP アドレスが付与されているものを表現することが可能となる。

具体的にはこれらの機能を実現するために、以下の 2 つのソフトウェアの研究開発を行った。
[1] 定期的に snmpwalk を実行し各リンクの帯域幅及びトラフィック情報を収集するツール[2] それらの情報を Perl/Tk に視覚的に表示するツール
2.2.2.3.2.2

ネットワークの状態視覚化ツール

2 つ目のツールに対しては永見<nagami@wide.ad.jp>が作成したプログラムを参考に実装を行なった。

- 38 -

図 2-2-2-1 WIDE インターネットにおけるルータ間のリンク状態
上記の program では OSPF ネットワークにおいては、リンクステート情報を全ての計算機が共有しているという特徴を用いて、AS 内にある、一つの計算機に対して snmpwalkを実行することで、OSPF の LSA 情報を収集しファイルを生成する。そして、LSA ファイルを基に、図 2-2-2-１のように OSPF を利用している各ルータ間のリンクの情報、そのネットワークの構成を視覚化することができる。
既存のプログラムでは各リンクの描写をする際、リンクの識別子をその両端に存在する計算機のルータ ID で表現していた。このため、ある計算機に複数のネットワーク
インターフェイスがあった場合には、それらに付与されているアドレスは考慮に入れられず全て同じアドレス(ルータ ID)から出ているように認識されていた。そこで、各リンクにおける端点とそれに対応するネットワークインターフェイスに付与されているアドレスとの間で整合性をとることにより、明示的に各リンクを区別するように実装に変更を加えた。具体的には以下の手順で行なった。
各リンクのリンク情報はリンクタイプによって Link ID、Link Data に入る情報が異なる。Link ID、Link Data に含まれる情報を 表 2-2-2-1 に示す。

- 39 -

表 2-2-2-1 LinkID、LinkData に含まれる情報
リンクタイプLink ID

Link Data

ピ ア ツ ー ピ ア 隣接するルータの ID

インターフェイスの IP アドレス

(P2P)
トランジットDR のルータ ID

トランジットに接続している IP アドレス

スタブ

ネットワークアドレ

ネットワークのサブマスク

ス
リンクタイプがトランジットとスタブである場合には、その情報からそれぞれに接続しているアドレスを知ることができる。あるルータから隣接するルータまでの接続がP2P であった場合には、以下の手順によって、リンクがどの IP アドレスを端点に持つかということを知ることができる。まず隣接するルータと P2P 接続であるとわかった
時点で、以下の 3 つの情報が得られる。
1. 自分(Src)のルータ ID
2. 隣接ルータ(Dst)のルータ ID
3. 隣接ルータに接続されているインターフェイスの IP アドレス
ここで、隣接するルータ(Dst)のリンクステート情報を参照し、リンクタイプが P2P
で自分(Src)のルータ ID が記載されているものを検索する。その情報の中には送信元(Src)に接続されているリンクのインターフェイスに付与されている IP アドレスが含まれているはずである。この整合を取ることにより、自分と隣接ルータのルータ ID、
そのリンクの端点にあるインターフェイスのアドレスを知ることができるようになる。
また、既存のプログラムにおいては、入力として OSPF のリンクステート広告情報のみを用いたが、視覚化における機能追加を実現するために、さらに、本研究で作成したツールより得られた帯域幅、トラフィック量の情報を入力とした。これにより、
ネットワーク管理者はネットワークの状態がどのようになっているかを知ることができ、リンクがダウンしていたり、輻輳が起こっていた場合には問題となっている場所
を視覚的に判断し、対策をすることが可能となる。
さらに、既存のプログラムではそれぞれのルータがどのように結ばれているかという点に注目しており、実際にはどのように回線が引かれているかということを考慮していなかった。ここで、一つの物理インターフェイス、これを仮に帯域幅 100Mbps をする、に対して複数の IP アドレス、5 つのアドレスとする、が割り当てられている場合を想定してみる。既存のままでは付与されている 5 つの IP アドレスそれぞれが- 40 -

100Mbps の帯域幅を保有しているものとして扱われてしまう。このため、あたかも 5
つのアドレスから出るリンクに流すことの可能なトラフィック量が 500Mbps のように見えてしまう。
こうした問題を解決するために、レイヤ 2 スイッチの概念を導入し、一つのインターフェイスに複数のアドレスが割り当てられている場合には、今まで別々のものとして扱われていたものを一つにまとめる必要があると考えられる。
2.2.2.4

評価および考察2.2.2.4.1
2.2.2.4.1.1

帯域幅とトラフィック量の関係を視覚化について
帯域幅及びトラフィック情報収集ツール

本研究で提案したツールを実行し、収集したデータを図 2-2-2-2 に示す。

図 2-2-2-2 snmpwalk の実行結果
図 2-2-2-2 に示した snmpwalk により得られたデータを基に、本ツールを用いた結果、出力された各リンクのトラフィック情報を図 2-2-2-3 に示す。

IpAddress:192.41.197.1

IfSpeed:100000000 IN:5.97389186666667

OUT:9.7033692

IpAddress:202.243.16.205 IfSpeed:9000

IN:1.07851851851852

IpAddress:202.249.26.114

IN:0.337693333333333 OUT:1.7698012

IfSpeed:100000000

IpAddress:203.178.138.231 IfSpeed:100000000 IN:11.1535750666667

OUT:0
OUT:7.81618746666667

図 2-2-2 3 本ツールを用いて得られたトラフィック情報
このように、トラフィック情報として、OSPF を利用しているルータが持っている IP
アドレス、そのアドレスが付与されているインターフェイスの帯域幅、及び入出力の帯域使用率を得ることができる。ルータによっては帯域幅などが定義されていないも- 41 -

のもあったので、もし、帯域幅が定義されていなければ 100Mbps、入出力バイト長が定義されていなければそれぞれ 0 を初期値として与えた。実際に 100Mbps や入出力が0 であるものと区別するために、定義されていないものに関しては図 2-2-2-4 のような警告ファイルの作成を行った。

図 2-2-2-4 本ツールを用いて得られたトラフィック情報
本ツールは OSPF を利用している全ての計算機に対して snmpwalk を実行しており、各計算機へのアクセスと各計算機から送出されるトラフィック量などの情報により、新たにネットワーク上にトラフィックを発生することになるが、データの大きさとしてはネットワークインターフェイスの 5 つある計算機から取得されるもので 1.5kB 程度であり、ネットワークにかかる負荷も小さく影響は少ないと考えられる。任意の時間にトラフィック情報を収集することができるが、連続した情報を収集することが現状ではできておらず、収集可能な情報は snmpwalk を実行した際の時系列で見た断片的なもののみである。
一方、連続に近い頻度で情報を収集しようとすると、トラフィックの量が増大し、本ツールを使用することによる影響が出て来てしまう。ここで、連続に近い形での情報を収集することと新たにトラフィックを発生してしまうことによる二律排反の問題が出てきてしまう。
また、snmpwalk を実行し、各計算機から順次情報を取得していくので、それぞれの計算機から取得される情報に時間の差が生じてしまうという問題が存在する。
2.2.2.4.1.2

ネットワークの状態視覚化ツール

本研究で開発実装したソフトウェアを、実証的環境で動作検証を行なった結果を図2-2-2-5 に示す。
本ツールは正常なネットワークトポロジを LSA ファイルから得ることができていれば、1 つ目のツールによって得られた情報から異常を検知することが可能となる。輻
輳がリンク間で連続的に起こっている場合など、テキストベースの情報だけでは認識が困難なものを視覚的に判断可能となる。

- 42 -

図 2-2-2-5 WIDE インターネットの各リンクの帯域幅及びトラフィック量
2.2.2.4.1.3

レイヤ 2 スイッチの表現について

レイヤ 2 スイッチの概念を導入することにより、よりきめ細かいネットワークトポ
ロジを再現できると考えられる。ただ、VLAN などの場合には単純に snmpwalk を各ルータに対して実行しただけでは、物理インターフェイスに対してどのアドレスが割り当てられているかということを知ることができない。これを実現するためには実際にVLAN がどのように設定されているかという情報を別に取得しなければならいが、現状でそうした設定情報を自動で取得するのは困難である。そのため人手に頼らなければならない。
また、レイヤ 2 スイッチの概念を導入しても、実際のネットワーク置かれている機器類が十分な機能を持っていない場合には、各インターフェイスを流れるトラフィッ
ク量を測定することができない。

- 43 -

2.2.2. 4.2
2.2.2.4.2.1

コストを変更した際に起こるフロー変化のシミュレーションについて
概要

2.2.2.3.3 で作成したツールのシミュレーションの結果を 図 2-2-2-6 に示す。

図 2-2-2-6 コスト変更前のフロー
これに対して、ネットワーク内においてトラフィックは変化させずに、一箇所のコストを変えた場合の結果を図 2-2-2-7 に示す。

- 44 -

図 2-2-2-7 コスト変更後のフロー本ツールでは OSPF を利用している任意の計算機間にトラフィック流して、シミュレー
ションを行うことが可能である。また、3.2 で提案したツールにより得られた情報と組み合わせることにより、現在の状態に新たにフローを流した際にどのような影響が起こるかということもシミュレーションすることが可能となる。しかしながら、このツールではネットワークのトラフィック情報の収集は snmpwalk で行っており、各イン
ターフェイスを流れるトラフィックの量を知ることはできるが、ネットワーク全体でどのようなフローが存在しているかということを知ることはできない。つまり、コストを変更した場合にネットワーク全体に与える影響をシミュレーションすることができない。実際のネットワークを再現しようとする際には、各ルータを流れるフローがどの送信元から送信先に向けられているであるかということを知る必要が出てくる。
ここで、sFlow などを複数箇所の計算機において使うことにより、フローがどの送信
元から送信先へ向けられているものであるかを概算として把握することが可能となると考えられる。この情報を基にネットワークの状態をシミュレータ上に再現し、もし問題のある部分が存在していれば、シミュレータ上でコストの変更などを行い影響を確認することができる。また、これは実ネットワーク上で作業を行うよりも安全に行うことができる。

- 45 -

2.2.2.5

結論

本節では、ネットワークの視覚化について述べた。ネットワークの状態を視覚的に捉えることにより、問題点の認識が容易になり、対策を講じやすくなると考えられる。
最後に、現状ではまだ解決されていないネットワーク全体のフローを知るという問題に対しては、netflow や sflow などのフロー単位でのトラフィックの測定手法を取ることにより解決を図ることができると考えられる。 本研究では WIDE Project のバックボーンネットワークにおいて、測定を行っていたが、現状では sFlow などによりトラフィックを解析する環境が十分ではなく、実際のフローをシミュレーション上に再現するということはできなかった。現状のシミュレータではコストを変更してその影響を確かめることができるが、輻輳などを回避し、ネットワークを効率的に運用するのに最適なコスト値として何を与えればよいかという問題が存在する。
また、シミュレーションを行う際に計算量を減らし、高速化を実現するための方法について述べたが、これは実際に検証を行う必要がある。

- 46 -

2.3

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

2.3.1
2.3.1.1

誘導経路情報を用いたインターネットパス制御アーキテクチャ
概要

インターネットシステムにおける経路制御は、ますます複雑化するインターネットの構造と要求に対応しなければならない。しかし、現在の経路制御システムはグロー
バルスケールで、宛先アドレスをルートとしたスパニングツリー型のパスを形成する
ために、必ずしも自由なパスの制御(トラフィックエンジニアリング)や Ingress 側での迅速な制御を実現することが容易ではない。 本論文では、エニキャストの概念を拡張した誘導経路情報の広告を用いたインターネットパス制御アーキテクチャ(IRIDES;
Invitation Routing Information aDvertizement for path Engineering System)の提案を行っている。 誘導経路情報を用いて、送信ノードにより近いポイント(誘導ポイント)において、トラフィックエンジニアリング可能なルーティング空間(誘導空間)に IP パケットを誘導する。誘導空間におけるトラフィックエンジニアリングは任意の手法を用いて実現することができる。提案アーキテクチャは、既存の経路制御システ
ムとの共存が可能であり、十分なスケーラビリティーを持つ。 さらに、提案アーキテ
クチャをもとに、いくつかの具体的なアプリケーション(e.g.,マルチエージャント型
マルチホーム NEMO/MIP)が実現されることを明らかにする。
2.3.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- 47 -

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

マルチエージャント型マルチホーム NEMO/MIP)が実現されることを明らかにする。
2.3.1.3
2.3.1.3.1

インターネット経路制御技術の問題点
既存の経路制御技術の分析

本節では、本論文で提案するアーキテクチャに関連する 2 つの既存の経路制御技術の特徴を議論する。
2.3.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 ルータと相互交換することで、基本的にはグローバルスケールのスパニングツリーを管理している。
一方、Intra-Domain を司る OSPF や ISIS では、そのルーティングドメイン内部のネッ
トワークにおけるスパニングツリーの管理を行っている。
スパニングツリーは、閉じたトポロジー部分を持たない開放型のトポロジー構成を持つ。スパニングツリーが閉じた部分を持たないので、経路制御プロトコルに要求されるループフリー機能の提供が実現されていると考えることが可能である。 すなわち、ルーティングドメイン上のすべてのオブジェクト(=ノードあるいはネットワーク)から、注目する宛先オブジェクト(=ノードあるいはネットワーク)、すなわちツリーの
Root ノードへのループ(閉じた部分)のないパスを提供することができている。このス
パニングツリーは、すべてのリーフ(Leaf)ノード、すなわち、すべての送信元オブジ
ェクトで共有されたスパニングツリーとなっている。 送信元オブジェクトごとのスパ
ニングツリーを形成管理することで、ルータが管理すべき経路情報の量のオーダーをO(n^{2}) から O(n)に削減することに成功しているわけである。これが、インターネ- 49 -

ット経路制御システムにおける Destination-Based Routing であり、すべての経路制
御プロトコルが、この原理を共通に適用している。
2.3.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.3.1.3.4

経路制御システムへの要求事項

インターネットシステムにおける経路制御は、ますます複雑化および多様化するイ
ンターネットの構造と要求に対して、適切に対応できることが要求されている。前節における議論の通り、現在の経路制御システムは、以下の 2 つの技術的な特徴(=制約)を持っている。
・

ルーティングドメイン内において、宛先オブジェクト(=宛先ノードや宛先ネッ
トワーク)をルートとした、すべての送信元オブジェクトで共有されたスパニ
ングツリーパスを生成管理している。

・

グローバルスケールに階層的な IP アドレス空間の割り当てが行われている。

インターネットの経路制御システムは、この 2 つの技術的な制約を持つために、さまざまな課題が現れ、これまで、それぞれに対してアドホックな対応がとられてきた。
これらの課題は、以下の 3 点に集約化することができる。
・

共有されない転送パスの提供 ： 宛先オブジェクトごとに管理されるスパニン- 50 -

グツリー上のパスに依存しない IP パケットの転送パスの提供は、トラフィッ
クエンジニアリングに必要となる重要な要素技術の一つである。 現在の経路
制御システムでは、異なる送信元オブジェクトから、同一の宛先オブジェクトに向けて転送される IP パケットは、共通のパス(スパニングツリー)を使用しなければならなくなってしまう。 宛先オブジェクトへの複数の IP パケット転送パスの提供は、シングル ISP 内でのサービス品質提供の冗長度の向上に貢献するだけではなく、複数の ISP が関与するマルチホーム環境の提供における通信品質の向上にも貢献する。
・

プラグアンドプレイ環境の提供 ： IP アドレス空間の階層化と集約化に伴い、オブジェクト(ノードあるいはネットワーク)の、物理的あるいは論理的な移動時には、該当するオブジェクトシステムにおいては、IP アドレスのリナンバリ
ングなど、さまざまな、ネットワーク関連に設定変更を行う必要がある。 オ
ブジェクトの論理的な移動は、物理的な移動時には、ほぼ、必然的に発生するが、物理的な移動が伴わない場合でも、契約先の ISP を変更する場合などに発生する。 契約先の ISP を変更する場合には、一般的には、そのオブジェクト(ノードあるいはネットワーク)が使用する IP アドレスが変更になってしまい、それに伴い、ネットワーク関連の設定を多数変更しなくてはならない。すなわち、本論文で議論するプラグアンドプレイは、設定フリーの環境を提供する自動構成認識技術ではなく、設定"変更"フリーの環境を提供するものを意味する。

・Ingress 側 で の 迅 速 な 対 応 を 実 現 す る フ レ ー ム ワ ー ク の 提 供：

Destination-Based Routing を適用した経路制御システムにおいては、送信元
オブジェクトに近い地点での迅速な対処や制御が、一般的に難しい。 特に、DDoS(Distributed Denial of Service)攻撃への対処のための IP パケットフィ
ルタリングなど、基本的には、現在は、Egress 側に近い地点(すなわち受信オ
ブジェクト側)で対処している。Ingress 側での迅速な対応が実現すれば、ネッ
トワーク内に本質的に不必要なトラフィックを削減できるなどの効用も期待できるであろう。
2.3.1.4

提案アーキテクチャ; IRIDES

2.3.1.4.1

IRIDES アーキテクチャ

Destination-based Routing アーキテクチャに伴う不十分な転送パス制御とアドレスの集約化にともなく階層化が原因で発生する不十分なプラグアンドプレイ機能の 2
つの問題を解決するために、誘導経路情報の広告を用いた IRIDES(Invitation Routing
Information aDvertizement for path Engineering System)アーキテクチャの提案を行う。 本アーキテクチャでは、通常のレイヤ 3 転送空間とは別に、トラフィックエン
ジニアリング可能なルーティング空間(誘導空間)を定義し、誘導空間と通常のレイヤ- 51 -

3 転送空間との間には複数の誘導ポイント(IIR;Ingress IRIDES Router)ルータを設置する。 なお、誘導空間は、物理的に独立したネットワーク空間でもよいし、通常のレイヤ 2 やレイヤ 3 の基盤上に構築される仮想的なオーバーレイネットワークのどちらでも構わない。 すなわち、独立したネットワーク空間を持つ構造にするか、それとも
オーバーレイ方の仮想的な誘導空間を構築するかは、アーキテクチャの具体的な実装
方法の選択肢である。
図 2-3-1-1 に、IRIDES システムにおける通常のレイヤ 3 空間の概念図を示した。 図では、2 つの IIR(IIR1 および IIR2)が、インターネット上に分散配置されている。 IIR1と IIR2 は、まったく同一の経路情報をインターネットに対して広告する(エニキャス
ト)。送信元ノードから転送された IP パケットは、経路制御プロトコル的により近い
IIR(誘導ポイント)に転送(誘導)され、IIR を通して誘導空間に誘導転送される。

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

に転送する。なお、誘導空間で使用される経路制御のための識別子としては、MPLS のラベルや VLAN タグ、IP トンネル用 IP アドレス、あるいは IPv6 アドレスなど、誘導
空間ネットワークの運用者が適切な識別子を自由に選択可能とすることができる。

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

- 53 -

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

図 2-3-1-4 誘導空間におけるマルチパスの提供- 54 -

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

エンドツーエンドでの IP パケット通信のための IP アドレスと、誘導空間におけるトラフィックエンジニアリングのためのアドレス(識別子)の分離により、エンドオブジェクト(ノードあるいはネットワーク)は、結果的に、ポータブルな IP ア
ドレス空間を獲得することができるようになる。 ポータブルアドレスの提供により、モバイルオブジェクトへの対応とプラグアンドプレイ環境(設定変更フリーという意味での)の提供を可能とする。
IRIDES アーキテクチャでは、現在のインターネットシステムにおける、エンドノード(正確にはインターフェース)の識別を行うためのグローバルな識別子と、そこへの IP
パケットの配送に必要な経路制御に必要となる識別子を同一のものとし、この識別子のみを用いて転送パスの決定を行っているという、現在のインターネットの本質的な識別子管理と利用のアーキテクチャへの改善を提案している。すなわち、少なくとも、誘導空間においては、エンドノード識別子 と 転送経路決定のための識別子を分離することで、多様な、転送ポスのエンジニアリングを可能としている。
2.3.1.4.2

IRIDES プロトコルアーキテクチャ

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

誘導空間(トラフィックエンジニアリングプレーン)におけるデータ転 送方式/プロトコルを選択可能にする API(Application Interface)。

(2)

EIR と IIR 間でのデータベース同期プロトコル。 具体的に必要な作業は、iBGPにおける作業とほぼ同一であるので、iBGP ベースのプロトコルアーキテクチ
ャが現実的であろう。 また、大規模化(IIR や EIR の数の増大への対処)は、
RR(Route Reflector)と同様の手法を導入することによって、必要となるデータ同期の量を、O(n^2)から O(n)に削減させることが可能である。

(3)

送信元オブジェクトからのポリシー登録プロトコル。 IIR における制御ポリ
シーは、送信元オブジェクト(あるいはネットワーク運用者)が指定/登録可
能にすることが望ましい。

- 56 -

2.3.1.4.3

問題点と今後の課題

IRIDES アーキテクチャの問題点と課題としては、以下の点が挙げられる。
[問題点]
(1)

ルーティングループへの対処: 既存の経路制御プロトコルが決定する IP パ
ケットの転送経路とは異なるパスを利用するので、本質的に、ルーティング
ループの発生の可能性がある。 この問題は、類似の機能とサービスを提供する MPLS において、既に、議論され、ループ検出のためのプロトコルの提案と標準化が完了している。 IRIDES システムにおいても、同様のループ検
出プロトコルを定義する必要があるかは、実運用の形態などを鑑み決定されるべきであろう。

(2)

エンドエンドアーキテクチャ: IIR および EIR においては、透明なレイヤ 3以上の処理を行っており、エンドエンドアーキテクチャの特長を喪失していないかの検討を行う必要がある。
(a) 中継ノードでの処理: IIR および EIR で必要となる機能は、現在のルータで行われているものとほぼ同程度のものであり、IP パケットの転送パフォ
ーマンス上の問題は、発生しないと考えられる。
(b) エンドエンド到達性の保障: IIR および EIR では、アーキテクチャ上、NAT
アーキテクチャと同様に、IP アドレスの変換も可能とすることができる。
これによる、エンドエンドでの到達性の喪失の可能性が発生することは、十分に留意され、実システムへの適用と運用が行われなければならない。

[今後の課題](1) 宛先のアドレス解決と表現手法
誘導空間での EIR および宛先ホストへのデータ転送に必要な識別子(=アドレス)の解決手法とその表現手法の正規化と標準化を行う必要がある。
(2) トラフィックエンジニアリングツールの汎用化
ルーティングループの検出、転送経路の把握とエンジニアリングツールの確立など、現在のインターネットシステムでは、確立してないツール群の汎用化と整備を行う必要がある。
(3) 個別プロトコルの設計上述した 3 つのプロトコルコンポーネントフレームワークの具体的な設計定義を行わなければならない。

- 57 -

2.3.1.5

IRIDES アーキテクチャの適用例

本章では、IRIDES アーキテクチャのアプリケーション(適用例)という観点から、いくつかの既存のアーキテクチャを考察する。 本報告では、IRIDES アーキテクチャとして、エッジが既存インターネットシステムでコアがトラフィックエンジニアリング
可能なネットワークとしているが、実際には、これらは、基本的には双対の関係にすることが可能である。 すなわち、上述のアーキテクチャとは逆の構成で、コアが既存のインターネットシステムで、エッジが、新しいネットワーク(例えば、IPv6 やプラ
イベートネットワーク)とすることも可能である。
2.3.1.5.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.3.1.5.2

SHAKE

SHAKE(SHAred multiple paths protocol for cluster networK Environment)は 、
Mobile IP を拡張して、複数の External への接続性を持つノードが、広帯域な Internal
リンク(e.g., WiFi や Bluetooth)を利用しながら協力しあい、より、広帯域な External
通信を実現するアーキテクチャである。 このアーキテクチャは図 2-3-1-3 に示した構成と捕らえることができる。 SHAKE では、HA が IIR(誘導ポイント)に対応する。
2.3.1.5.3

MPLS

MPLS のエッジルータが、IIR(誘導ポイント)と考えればよい。ただし、IRR は、基本的には、誘導経路情報の広告は行わず、通常のレイヤ 3 の転送経路上で、MPLS エッ
ジルータが、IP パケットを強制的にトラップして、誘導空間に導入するアーキテクチ
ャであると、解釈することができる。 誘導空間における IP パケットフローの識別と転送経路の決定のための識別子は、データプレーンとコントロールプレーンに別れていて、これらのマッピングが、各ルータでとられている。データプレーンでは、MPLS
ラベルが、両方に共通の識別子となる。コントロールプレーンでは、IP パケットフローの識別は FEC(Forward Equivalent Class)で行われ、経路決定のための識別子は宛先の IP アドレスとなる。

- 58 -

2.3.1.5.4

NAT

エッジが Private アドレスを用いたネットワーク、コアがグローバル IP アドレスを用いたネットワークという構成である。NAT ルータは、IIR にあたる。 図 2-3-1-3に示した EIR が存在する場合も、さまざまな技術を用いて実現することは不可能ではない。 一般的に、IIR(NAT ルータ)は、NAT セグメントに対しては、グローバルには重複のある(＝同一の)Default Route の情報を広告することになる。 IIR では、IP アド
レスの変換テーブルが生成される。 誘導空間での IP パケットフローの識別子はグローバルな宛先ホストの IP アドレスか EIR(=NAT ルータ)の誘導空間側のグローバルなIP アドレスになる。
2.3.1.5.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.3.1.5.6

マルチキャスト

現在のインターネットは、ユニキャストサービスを基本としており、必ずしもマルチキャストサービスを本格的に提供はしていないし、ネットワーク内で使用されているルータのマルチキャスト機能のサポートの状況は、同一ベンダーが提供するルータですら、残念ながら、一様ではない状況である。 また、現在最も広く利用されている
PIM(Protocol Independent Multicast)は、RPF(Reverse Path Forwarding)のメカニズ
ムを用いたマルチキャストパケットの転送を行っており、マルチキャストパケットの転送ツリーは、ユニキャストの転送経路から一意に決められてしまう。
これら 2 つの問題を、IRIDES アーキテクチャを適用することで解決することができる
可能性がある。 PIM における RP(Rendezvous Point)を IIR とし、誘導空間のネット
ワークトポロジーをマルチキャスト機能を持った適切なノードのみから構成されるネットワークにすることで、不均一なノードから構成されるネットワークにおいても、- 59 -

ユニキャストのパケット転送経路に独立なマルチキャストサービスが実現可能となる。
2.3.1.6

まとめ

現在の経路制御システムがグローバルスケールでの、宛先アドレスをルートとした
スパニングツリー型のパスをもとに IP パケットの転送を行っているために、必ずしも自由なパスの制御を実現することが容易ではない。 本節では、エニキャストの概念を拡張した誘導経路情報の広告を用いたインターネットパス制御アーキテクチャ(IRIDES; Invitation Routing Information aDvertizement for path Engineering
System)の提案を行った。 提案アーキテクチャは、既存の経路制御システムとの共存が可能であり、十分なスケーラビリティーを持つ。 さらに、提案アーキテクチャをもとに、いくつかの具体的なアプリケーション(e.g.,マルチエージャント型マルチホー
ム NEMO/MIP)が実現されることを示した。
今後は、誘導空間における汎用的な宛先のアドレス解決と表現手法と、 トラフィ
ックエンジニアリングツールの汎用化、さらに、3 つのプロトコルコンポーネントの設計を行う予定である。

- 60 -

2.3.22.3.2.1

マルチホームアーキテクチャ
概要

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

研究の背景

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

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

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

- 61 -

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

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

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

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

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

表2-3-2-1

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

- 63 -

図2-3-2-2 提案マルチホームアーキテクチャの概要
2.3.2.4

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

前章で述べた既存マルチホーム技術の問題点を解決するために，我々は経路制御技
術だけに頼らない，多重ルーティング技術にもとづいたマルチホームアーキテクチャを提案する．
2.3.2.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 のアドレスのみを用いた通信を行っているように見え，また，インタ- 64 -

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

図2-3-2-3 複数のDR を用いた構成- 65 -

2.3.2.4.2

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

DR の複数化

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

- 66 -

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

対規模性の向上手法

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

- 67 -

図2-3-2-5 実験ネットワークトポロジ
2.3.2.5

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

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

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

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

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

DR における細粒度トラフィック制御である．
本実装は，UR およびDR の実装から構成される．DR-UR間の仮想接続技術としては，IPover IP トンネリング技術の一つであるGRE (Generic Routing Encapsulation)トンネ
ルを採用した．DR では，利用者網アドレス空間の経路広告機能，トラフィック制御に用いる仮想接続の管理，複数の仮想へのトラフィック振り振り，仮想接続の状態監視機能を実現する機能を実装した．UR では，仮想接続の確立処理，仮想接続を介したパケットの受信処理を実現する機能を実装した．UR およびDR の実装は，ソフトウェア
ルータとしても広く用いられているNetBSD オペレーティングシステムに対して行なった．この実装は，NetBSD 1.6 RELEASE に対するカーネル拡張とユーザランドアプリ
ケーションの追加から成る．この実装を用いて，図2-3-2-5 に示す実験網を構築し，動作実験を行なった．本実験では，実験網上の任意のノードからの利用者網宛パケッ- 68 -

トが，提案アーキテクチャの設計通り，DR を介し，仮想接続(ここではGRE トンネル)
を通り，UR へ伝送される基本動作の確認ができた．さらに，DR において，利用者網
宛トラフィックの処理ポリシを設定し，アプリケーション(ポート番号)毎に異なった接続を介してパケットを配送することが可能となっている点も確認した．また，一部の接続の障害時における障害検出と経路切り替えに関しても実験を行った．利用者網の接続のうち実際にトラフィックが流れている側の接続を切断したところ，約200ms
でそのトラフィックが他方の接続を介しての配送へと自動変更されることを確認した．
実アプリケーションにおける実験として，DVによる動画伝送アプリケーションを用いた利用者網への動画配信中の回線切断実験を行ったが，回線切り替えの影響は目視上ほとんど気にならない範囲内であり，アプリケーションのセッション断なども生じないことを確認した．
さらに，本提案システムの実運用における知見の獲得を目的とし，本実装の実運用網上で運用する広域運用実験を予定している．
2.3.2.6

考察と課題

2.3.2.6.1

既存方式との比較

本節では，我々の提案する多重ルーティング型マルチホームアーキテクチャの評価として，既存方式に基づくマルチホーム方式との比較を行う．ここでは，マルチホー
ムの主目的である障害時の利用者網への到達性向上効果とともに，2.3.2.3章で既存マルチホームの問題点とした挙げた以下の項目に着目し比較した．
-

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

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

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

まず，マルチホーム接続の主目的である，障害時の対象ネットワークへの到達性の向上効果に関して述べる．既存マルチホームアーキテクチャでは，障害時には，(1)障害箇所でのBGP-4による経路交換が停止し，(2)障害箇所を経由する利用者網宛の経路情報が消失し，(3)他の網を経由する経路が選択され，(4)利用者網への経路到達性が回復する．ところが，そもそもBGP-4 は頻繁な経路変更を想定したプロトコルではないため，障害を検出した後，経路が安定し到達性が回復するまでにはネットワークの構成にも依るが10 秒から数分程度の時間を要する．我々の提案方式では，DR?UR 間の生
存確認により障害を検出されると，該当仮想接続を指すDR の経路表エントリを非障害
トンネル側に変更するのみで，経路切り替えが完了し利用者網への経路到達性が回復する．このため，生存確認間隔にも依存するが，1 ～数秒程度の時間で経路切り替えが完了し到達性が回復する．
次に，マルチホーム利用者数の増加がインターネット上の経路数に与える影響については，既存方式が1 ユーザあたり経路数を1 エントリ増加させるのに対し，提案方式- 69 -

では経路選択機構が経路広告時に複数利用者の経路を集約可能となっており，利用者数の増加が経路数に与える影響は限定的なものとなる．また，マルチホーム接続時の複数接続の柔軟な制御という点では，BGP-4 の広告コスト調整のみでしか流入トラフ
ィックを制御できない既存方式は，複数のリンクにトラフィックを均等に割り振るといった制御や，アプリケーションの要求に応じた品質のリンクを使用する制御などは不可能である．提案方式では，経路選択機構による柔軟な経路選択(ポリシルーティング)により利用者の要求に柔軟に応じられ，UR 側トラフィック監視機能との連携により先に挙げたようなトラフィック割り振りなどが実現可能である．
さらに，マルチホーム利用者網側の運用コストに関しては，既存方式に高度な経路制
御知識が必要であったのに比べ，提案方式では，経路制御などの複雑な運用はDR の運用者(マルチホームサービスの提供者)が行うこととなる．利用者側は，URの設置・運用を行うことになるが，UR では経路制御システム等を動作させる必要はなく，既存方式でのマルチホーム運用に比べ運用は容易となる．その一方で，提案方式では，利用者網と外部ネットワークとの間のトラフィックがトンネル等の仮想接続を介して転送されるため，トンネルによる転送オーバヘッド等が問題となる可能性が挙げられる．
これに関しては，次節で述べる．ここまで述べた項目について，表2-3-2-2 にまとめた．これから，我々の提案手法は，既存手法の問題点を解決しつつ基本的機能である
障害時の到達性回復時間の短縮も実現していると言える．
表2-3-2-2 既存方式と提案方式の比較

2.3.2.6.2

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

前節で述べた通り，提案方式によるマルチホーム接続では，トンネル等の仮想接続を介して転送を行うことによる影響が生じる．これは，パケットがトンネル中を配送される際，トンネル自体を示すIP ヘッダとトンネルヘッダが元のIP パケットに付加されることによる．例えば，今回のプロトタイプ実装のようにトンネル方式としてGREトンネルを用いた場合，最低28バイト(IP ヘッダ20 バイトとGRE ヘッダ8 バイト)が付加される．
インターネット上の各リンクには，そのデータリンクの特性等に応じてMTU (Maximise- 70 -

Transfer Unit)が定められている．ここで，トンネル両端点間のMTU (MaximiseTransfer Unit)を1500 と仮定すると，上記GRE トンネルによる仮想リンクのMTU は28
バイトの縮退により1472 バイトバイトとなる．ところが，実際のインターネット上には，パケットフィルタリング等の設定の誤りからMTU 超過の際の動作を正常に行えないネットワークが数多く存在する．これは大きな問題であるが，MTU 超過処理を正しく行えないネットワークとの通信を維持するために，通常，構築するネットワークのMTU を1500 未満にしないという運用がなされている．先のGRE トンネルの例では，仮想リンクのMTU として1500 を維持すると，1472バイトを超過するサイズのパケットをカプセル化した場合，トンネルの両端点間ではIP 断片化された状態で配送される．この場合，1500 バイト長の1 つのパケットをトンネルを介して送達する際には，1500 バ
イト長のパケットと48 バイト長のパケットの2 つのパケットに断片化し送達される(図2-3-2-6)．

図2-3-2-6 カプセル化によって生じるIP 断片化- 71 -

表2-3-2-3 カプセル化前後のパケット長分布の比較

表2-3-2-3 は，インターネットバックボーン上でトラフィックを24時間観測し，パケット総数と消費帯域をそれぞれ100 として，パケット長毎の比率をまとめた．さらに，
このトラフィックを提案手法におけるトンネルを介して送った場合，つまり，48 バイ
ト長のカプセル化ヘッダを付加し必要に応じてIP 断片化処理を行った場合のパケッ
ト数および消費帯域を示している．この結果から，カプセル化処理により，パケット数が約22%，帯域が約6%追加消費されていることが分かる．さらに，パケット長毎のパケット数分布にも変化が見られる．まず，パケット長48 バイトのパケットの増加が顕著だが，これはパケット長1500 バイトのパケットがカプセル化後に断片化された結果生じたものである．さらに，パケット長1500 バイトのパケットの増加，パケット長48
バイト未満のパケットの急減が見られる．このように，提案アーキテクチャがトンネルを用いたインターネットと利用者網の接続を行っていることによりある程度の影響が生じることが観測された．この影響は，パケット数にしてみると20%を越える増加と大きなものであるが，帯域に対する影響は高々6%程度である．この高々6%の帯域増に関しては，提案アーキテクチャが提供するリンクの有効利用とトラフィック制御に関する利点と比較するとその影響は限定的なものであると言える．
この問題に対する改善手法としては，カプセル化時のパケットサイズに対する影響の小さな方式を用いた仮想接続を用いる方法が挙げられる．例えば，DR?UR 間の網においてMPLS によるLSP の確立が可能であれば，LSP を用いた接続も利用可能である．
さらに，我々は，トンネリングによるMTU 縮退の影響を回避するために，MTU 値に影響を与えないトンネリング手法の開発を試みている．これは，利用者網のアドレス空間が比較的狭域であることなどを利用し，カプセル化の際，IP ヘッダ圧縮技術等を用いることでMTU 縮退を防ぐものである．

- 72 -

2.3.2.6.3

DRの設置状況と配送遅延

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

セキュリティー

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

まとめ

本節では，既存マルチホーム技術の問題点をまとめ，その解決として多重ルーティ
ング型マルチホームアーキテクチャを提案した．このアーキテクチャは，インターネ
ット上の経路数の増加といった既存マルチホームの大きな問題を解決するばかりでな
く，利用者アプリケーションの要求特性に応じた回線選択といった新たなサービス体系の実現への可能性を持っている．さらに，特に利用者網への流入トラフィック制御を実現するプロトタイプ実装を行ない，その動作を確認した．また，既存方式との比較により提案方式の有効性を示した上で，広域運用実験へ向けて現在進めている実装の拡張や制御プロトコルの設計に関して議論した．

- 73 -

2.3.3

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

2.3.3.1

概要

本節では、インターネットサービスプロバイダ(ISP)７社のバックボーントラフィッ
クを２ヶ月にわたり測定、解析した結果を報告する。 主要な結果は以下の通りである。
1. 国内ブロードバンドカスタマートラフィックは、100Gbps 以上で、年２倍のペースで増加中。さらにトラフィックの方向はほぼ対称
2. 約 70％のブロードバンドカスタマートラフィックは昼夜を問わず一定。
3. カスタマートラフィックの総量は、オフィスユーザトラフィックやアカデミックト
ラフィックより多く、バックボーントラフィックの統計的な性質は、カスタマート
ラフィックの性質によって決定される
4. 各 ISP 間でのプライベートピアリングに流れるトラフィックは、６大インターネッ
トイクスチェンジ(IX)向けのトラフィックとほぼ同程度であり、IX のトラフィック
のみから国内トラフィック量を推定することは過小評価となる。
5. 海外向けトラフィックは、ISP トラフィックの 23％を占めるが、その方向については非常に強い非対称性を有する。
2.3.3.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)トラフィック- 74 -

B2. 他の国内トラフィック: プライベートピアリングトラフィック、地域 IX トラフ
ィックB3. 国際トラフィック
これ以外に、地域のトラフィック特性を調査するために
C. 都道府県別データを収集した。C は A1 をさらに細かく分類したものであるが、全ての ISP データを取得することが技術的に困難であるため、2 社のデータのみを使用した。
また、各トラフィックグループのデータはそれぞれ方向(In, Out)を持ち、In は各 ISPへのトラフィックを表し、Out は各 ISP からのデータを表す。例えば、A1 の In は ISP
よりカスタマーへのトラフィック(いわゆるダウンロードトラフィック)であり、Outはカスタマーより ISP へのトラフィックとなる。
データの収集は、2004 年 9 月および 10 月の二ヶ月に渡って行われた。
2.3.3.3

データ解析結果(国内トラフィックの挙動)

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

いると考えられる。他方、アカデミックトラフィックやオフィストラフィックで典型的な昼間のアクティビティーは平日では確認できない。さらにトラフィックパターン
は平日ではほぼ同じであるものの、週末では昼間のトラフィックの増加により、平均
トラフィックが増えていることがわかる。

図 2-3-3-2 A2 トラフィック
次に、それ以外のカスタマートラフィックである A2 の結果を図 2-3-3-2 に示す。このデータは技術的な問題で 7 社のうち 4 社のみのデータとなっているため、A1 と絶対量を比較することができないことに注意が必要である。データを見ると、In/Out の対称性およびピーク時間帯の傾向は A1 データとほぼ同じであることがわかる。しかしながら、オフィス時間(8 時

18 時)にも 15Gbps 程度のトラフィックを観測しており、これはオフィスユーザの挙動が反映していると考えられる。

図 2-3-3-3 アカデミックトラフィック
A1 および A2 データとの比較のために、同時期に取得したアカデミックトラフィックのトラフィックパターンを図 2-3-3-3 に示す。このデータは ABILENE(Internet2)のバックボーントラフィックである。図より明らかなとおり、アカデミックトラフィッ
クの傾向はカスタマートラフィックのそれと大きくことなることがわかる。特徴的なポイントは(1)平日のピークは昼間、(2)平日に比べて週末は平均トラフィックが減少す- 76 -

ることである。すなわち、ブロードバンドトラフィックをモデル化する際には、従来の研究で得られてきたアカデミックトラフィックの傾向をそのまま適用することが困難であることがわかる。

図 2-3-3-4 B1 トラフィック

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

30.9Gbps

74.5Gbps

2004 年 10 月

31.8Gbps

77.1Gbps

表 2-3-3-1 は今回の解析で ISP で収集された 6IX のトラフィック量および、同時期に- 77 -

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

図 2-3-3-6 B3 トラフィック
同様に、海外トラフィックに関するデータを図 2-3-3-6 に示す。海外トラフィックデ
ータは今までに見てきたトラフィックデータのパターンと大きく異なり、トラフィッ
クの方向に強い非対称性があることが見てとれる。In トラフィックが Out トラフィ
ックと比べて 40％程度大きく、これは海外コンテンツのダウンロードが支配的であることを意味する。また、In と Out のピーク時間帯が同じであることから、Out トラ
フィックもまた主として国内のアクティビティーに起因しているものと考えられる。
すなわち、ほとんどのトラフィックは国内から発生していることを表している。
表 2-3-3-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-3-2 は各トラフィックグループの一ヶ月ごとの値を表している。各トラフィッ
クグループを比較すると、一ヶ月あたり 6

7％のトラフィックの増加となっている。

- 78 -

これは、年換算ではほぼ２倍となり、ブロードバンド加入者数や 6IX のトラフィックの増加傾向とほぼ同じ割合である。また、6IX のデータ(表 2-3-3-1)より、国内ブロードバンドカスタマー(A1)のトラフィック総量は、133Gbps 程度であると推定できる。
同様に、B1(6IX)および B2(プライベートピアリング他)を比較すると、トラフィック
量はほぼ同程度の結果となった。これまでの研究では、データ取得の容易さゆえに IXのデータを用いることが多かった。しかしながら、プライベートピアリングトラフィ
ックが IX トラフィック並に存在することを考えれば、IX トラフィックデータのみで、
トラフィック総量を推定することは、大きな下方推定となっていることを意味している。逆に言えば、今後のトラフィック解析において、プライベートピアリングデータは無視できないことを表している。さらに、国内トラフィック(B1, B2)と国際トラフ
ィック(B3)を比較すると、国際トラフィックは全トラフィックのうち 20％程度を占めていることがわかる。
[解析結果(地方別トラフィックの挙動)]

図 2-3-3-7 首都圏トラフィック

図 2-3-3-8

地方トラフィック

次に、都市部および地方部での、ブロードバンドカスタマートラフィックの違いについて解析する。図 2-3-3-7、図 2-3-3-8 は県別のブロードバンドカスタマー(首都圏、地方)のトラフィックパターンである。両者を比較すると、トラフィック量は異なるも- 79 -

のの、ピーク時間帯や週末のパターンはほぼ同じであることがわかる。すなわち、都市、地方によるユーザの違いは少ないものと予想される。しかしながら、都市部のト
ラフィックでは、平日の昼間にも一定量のトラフィックが観測されている。これは、オフィスユーザの挙動と考えられ、都市部のブロードバンドカスタマートラフィックに、ホームユーザだけでなく、SOHO ユーザも含まれているとみなせば、妥当な結果である。

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

- 80 -

図 2-3-3-10 県別トラフィックの累積分布
最後に、県別トラフィックの累積分布を図 2-3-3-10 に示す。これは、今後のトラフィックの成長割合を示すものと解釈できる。分布は 700Mbps より手前ではほぼベキ的減衰をとなっている(両軸が対数表示であることに注意)。ベキ的減衰は、多数の都道府県では、トラフィック量は非常に小さいものの、県当たりの典型的なトラフィック
量というものが存在せず、いくつかの多量のトラフィックを送信・受信している都道
府県が存在することを表している。つまり、ネットワークの設計論としては、大多数の都道府県では大きな設備投資が必要でないものの、いくつかの都道府県では集中的に設備の投資が必要となることを示唆している。しかしながら、このベキ的減衰はトラフィックの使用パターンに由来するものではなく、純粋に人口の関係から導かれる
ことは、県別人口の累積分布を示した図 2-3-3-10 のサブグラフからわかる。つまり、都道府県別の人口比がベキ的減衰を伴うため、そのトラフィックもまたベキ的減衰を示すわけである。
2.3.3.4

まとめと今後の課題

本研究では、国内ブロードバンドトラフィックの増加並びにそのトラフィックパタ
ーンを、国内主要 ISP7 社のデータより明らかにした。収集されたトラフィックデー
タは、国内トラフィックのほぼ 40％を占めており、得られた知見は、現在の国内トラ
フィックデータの統計的性質を忠実に反映したものとなっていると考えられる。解析による主な結果は以下のとおりである。

- 81 -

1. 国内ブロードバンドカスタマートラフィックは、100Gbps 以上で、年 2 倍のペー
スで増加中。さらにトラフィックの方向はほぼ対称
2. 約 70％のブロードバンドカスタマートラフィックは昼夜を問わず一定。
3. カスタマートラフィックの総量は、オフィスユーザトラフィックやアカデミック
トラフィックより多く、バックボーントラフィックの統計的な性質は、カスタマートラフィックの性質によって決定される
4. 各 ISP 間でのプライベートピアリングに流れるトラフィックは、6 大インターネ
ットイクスチェンジ(IX)向けのトラフィックとほぼ同程度であり、IX のトラフィ
ックのみから国内トラフィック量を推定することは過小評価となる。
5. 海外向けトラフィックは、ISP トラフィックの 23％を占めるが、その方向については非常に強い非対称性を有する。
今回の解析により、国内バックボーントラフィックのマクロな性質は明らかになった
ものの、ミクロな性質は以前未知のままである。将来的な目標としては、(1)フローレ
ベルの解析により、ユーザーレベルでの In/Out トラフィックの関係、フローの方向
性およびアプリケーショントラフィックの性質の同定、さらに、(2)諸外国データとの比較(とりわけブロードバンド先進国である韓国ならびに、多数のユーザがいるアメリカ)により、今回の解析結果のさらなる理解を目指すことが挙げられる。

- 82 -

2.3.4

VoIP/SIP システムの相互接続性確立に関する研究開発

2.3.4.1

概要

SIP を用いた VoIP システムのマルチベンダー環境、マルチプロバイダ環境での相互接続性の確立を目指し、JPNIC・WIDE プロジェクト共に”VoIP/SIP 相互接続検証タス
クフォース”(以後、TF)を設立した。VoIP/SIP 相互接続検証テストベッドの構築と運用、シナリオ作成など相互接続性検証の環境を整備し、プロバイダ・SIP 端末ベンダーと共に相互接続性の検証を行っている。今後は、シナリオの拡充と共に各種検証モ
デルについて検証を進める予定である。
2.3.4.2

研究背景

IP 電話は 2002 年に大手 ISP が IP 電話サービスを始めたのをきっかけとして、現在
では家庭、企業、プロバイダのすべての領域において急速に普及し始めている。しかし、これまで各ベンダーおよびプロバイダは、VoIP 技術に対してそれぞれ独自に開発、サービスを提供してきたことより、十分な相互接続性を確立した相互接続運用には至っていないのが状況である。
今後 VoIP システムが現在の「電話」と同様に本格的に普及し、さらに VoIP 技術を核にしたマルチメディアサービスの展開が伴い、産業社会活動において広く利用されるためには、ベンダー間のみならず、プロバイダ間で基本的な相互接続性が実現されなければならない。
そこで VoIP システムの相互接続性実現のため JPNIC・WIDE プロジェクトと協力体制を築き、TF を設立し、マルチプロバイダ環境・マルチベンダー環境での相互接続性の確立に向けての一助になることを目指す。
2.3.4.3

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

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

して貢献する。
3-1)VoIP システム評価検証シナリオ3-2)VoIP システム評価検証ソフトウェアを公開する。
3-3)VoIP 関連機器のソフトウェアの品質向上と相互接続性の確立
3-4)VoIP システム間での相互接続性の確立
3-5)VoIP 機器のポータビリティーの確立
3-6)国内外技術標準化機関(IETF, ITU-T, TCC, HATS など)への成果提供・提案
2.3.4.4

実検証モデル

検証モデルとしては、以下に挙げるパターンを想定し検証を行っていく。
(1) TE (1) -ISP 検証
この検証は、SIP サーバと SIP 端末間での UNI(User Network Interface)の検証対象として相互接続性を検証するモデルである。SIP サーバと SIP 端末の接続性、さらに同一 SIP サーバ配下に位置する SIP 端末間での接続性について検証することを目的とする。

図 2-3-4-1.

TE-ISP 検証モデル図(2) ISP-ISP 検証
この検証は、異なる SIP サーバ間での NNI(Network Network Interface)を検証対象として相互接続性を検証するモデルである。異なる SIP サーバの配下に位置す
る SIP 端末間での接続性を検証することを目的とする。

- 84 -

図 2-3-4-2.

ISP-ISP 検証モデル図(3) CampusNet (2)-ISP 検証
この検証は、ISP などの一般網が用意する SIP サーバとプライベートネットワー
ク内にある IP-PBX や SIP サーバなどとの UNI/NNI を検証対象とし、相互接続性を検証するモデルである。異なるネットワーク間でのそれぞれのネットワークの配下に位置する SIP 端末間での接続性を検証することを目的とする。

図 2-3-4-3.

CampusNet-ISP 検証モデル図(4) CampusNet-ISP-(???)-ISP-CampusNet 検証
この検証は、プライベートネットワーク同士が複数の ISP が用意する SIP サーバ
を経由し、UNI/NNI を検証対象として相互接続性の検証をするモデルである。あるプライベートネットワーク内の SIP 端末が複数の SIP サーバを経由し、違うプ
ライベートネットワーク内にある SIP 端末との接続性を検証することを目的とする。

- 85 -

図 2-3-4-4.
2.3.4.5

CampusNet-ISP 検証モデル図

評価および考察

まず活動本体である TF を設立する前に、VoIP/SIP 相互接続検証テストベッドの構
築と運用、更にはシナリオ作成に関する議論の場として準備会を設立し、多くの VoIP
技術に携わる方と共に本格運用に向けた議論を月 1 回のペースで行った。
そして平成 16 年 12 月 1 日に当 TF の設立、そして設立のプレスリリースを行った
後は、実運用に向けての運用会議なども月 2 回のペースで行っている。会議と並行して参加組織が相互接続性の検証する場としての検証相互接続検証実験室を大手町 JGN
Ⅱリサーチセンター（KDDI 大手町ビル 21F KBQ 内）に設置し、検証環境の整備・検証
ネットワークの構築を行った。また、相互接続検証の当 TF への参加促進と活動の PRの場として、ホームページを開設し広く活動を紹介することにも勤めている。
次に、実検証としては、第１回目の検証を平成 17 年 1 月 20 日に TE-ISP 検証について行った。参加組織は、SIP サーバを提供頂いたフュージョン・コミュニケーショ
ンズ㈱、TE は、5 社 6 端末である。検証項目は以下である。
Register リクエストによる新規登録
Register リクエストによる登録更新
Register リクエストによる登録削除
セッションの確立、発信者側切断
セッションの確立、着信者側切断
対戦数 20、チェック項目数 17 項目（1 対戦あたり）で検証を行い、成功率 100％の結果を得ることができた。
また、この検証では TE-ISP の UNI 接続検証だけではなく、特に当 TF の用意する検証環境の確認も合わせて行った。1 つ目は、KDDI 大手町ビルに用意した当 TF 検証室
が、実検証で機能する環境であるかを確認しました。また、検証室を運用する上での実際の搬入・搬出などのサポート環境についても確認した。次に、この検証では SIP- 86 -

サーバをフュージョン・コミュニケーションズ(株)にご用意頂き、その SIP サーバと当 TF 検証室とのネットワークの接続確認を行った。また、当 TF が接続性確認の指標として用意する検証シナリオが、検証を行う上で適切なシナリオであるかについて検証を進めていく中で確認を行った。
さらに、平成 17 年 3 月 4 日に SIP サーバを KDDI(株)提供頂き TE-ISP 検証を行った。
参加組織は、SIP サーバを提供頂いた KDDI(株)、TE は、5 社 6 端末である。検証項目
は以下である。
Register リクエストによる新規登録
Register リクエストによる登録更新
Register リクエストによる登録削除
セッションの確立、発信者側切断
セッションの確立、着信者側切断
発信のキャンセル
着信拒否
セッションの保留・保留解除
対戦数 15、チェック項目数 36 項目（1 対戦あたり）で検証を行い、成功率 99.6％の結果を得ることができた。(端末が未実装の場合は、検証項目から省く。)
また、テストラン時と同様に TE-ISP の UNI 接続検証と合わせまして、KDDI(株)が用意する SIP サーバと当 TF 検証室とのネットワークの接続確認も合わせて行った。

図 2-3-4-5.

相互接続検証時の様子１- 87 -

図 2-3-4-6.

相互接続検証時の様子 2

2.3.4.6 まとめと今後の課題
本節では、VoIP/SIP 相互接続検証タスクフォースが中心となり、VoIP 技術のマルチ
ベンダ・マルチプロバイダ環境による相互接続性の確立のための検証環境の構築、更に実検証を行った。検証では、設置した検証環境と接続性の指標となる検証シナリオが適切であるのかの確認と共に、100%に近い成功率上げることができた。
今後は、シナリオの拡充と共に新たな組み合わせの検証、各種検証モデルについて検証を進める予定である。また国内だけではなく、海外 SIP 端末ベンダーなども含め
たよりグローバルな検証活動を推し進め、国内外での VoIP システムの相互接続性の確立に努めたい。

- 88 -

2.4

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

2.4.1

概要

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

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

調査対象

IPv6 Core Protocol

基本仕様

相互接続テストシナリオ

IPsec

基本仕様

相互接続テストシナリオ

IKE

基本仕様

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

MIPv6

基本仕様

相互接続テストシナリオ

MIPv6 with IKE

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

基本仕様

相互接続テストシナリオ

SIP接続手順拡張

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

SIP Forum実装仕様

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

SIP

2.4.2

研究の背景

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

海外の組織とも協調して推進していく必要が有る。したがって、IPv6 Forum のサブコミッティである IPv6 Logo Committee、SIP フォーラムや VoIP/SIP 相互接続タスクフ
ォース等の国内外の組織と連携しながら、検証評価手法および検査ツールの研究開発
を行った。
2.4.3
2.4.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.4.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.4.3.3

IPsec

IPsec については、2003 年度に仕様適合性検査仕様の策定、検査ツールの開発を行っている。したがって、2004 年度は、主に Phase-2 プログラム向けの相互接続性テス- 90 -

トシナリオの策定を行った。IPv6 Core Protocol では機器をホストとルータの 2 つに分類していたが、IPsec では End-Node と Security Gateway(SGW)に分類している。
End-Node は IPsec の 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.4.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.4.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 は今後の動向に追随する必要が有る。

- 91 -

表2.4.3

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

オプション

FROM
End-Node と End-Node 間Transport

Tunnel

SGW と SGW 間

TunnelTransport

End-Node と SGW 間-

Transport or Tunnel

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

Tunnel間
2.4.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 クライ
アントのアドレスが固定されないため、アグレッシブモードが適している。フェーズ
1 のメッセージ交換タイプについては、今後の動向に追随する必要が有る。フェーズ 2
においては、クイックモードのみを検査対象とした。
ISAKMP SA のネゴシエーションにおいて交換される、暗号アルゴリズムは 3DES-CBCを必須とし、DES-CBC, AES-CBC(128bit)をオプションとした。ハッシュアルゴリズム
は、HMAC-SHA1 を必須とし、HMAC-MD5 をオプションとした。認証方式は、事前共有秘
密鍵暗号方式を必須とし、デジタル署名認証方式（RSA 署名）をオプションとした。
Diffie-Hellman グループは安全性を高めるためにグループ 2 を必須とし、グループ 1
をオプションとした。また今後の計算機の計算能力の向上を考えグループ 5、グルー
プ 14 もオプションに加えた。ライフタイムのタイプは秒を必須とし、キロバイトをオプションとした。
IPsec SA のネゴシエーションにおいて交換される、カプセル化モードについては、
IPsec の検査仕様に習い、End-Node では、Transport モードを必須とし、Tunnel モードをオプションとした。同様に SGW は、Tunnel モードを必須とし、Transport モード
をオプションとした。セキュリティプロトコルについては、AH と ESP の認証機能は、
認証範囲は異なるとはいえ、ESP もパケットの認証機能を持つ事から、今後 AH の利用は減り、ESP の利用が多くなると考え、認証付き ESP を必須とし、ESP をオプションとした。暗号アルゴリズムは、3DES-CBC を必須とし、DES-CBC、AES-CBC(128bit)、NULL- 92 -

をオプションとした。認証アルゴリズムは、HMAC-SHA1 を必須とし、HMAC-MD5、AES-XCBC
をオプションとした。ライフタイムのタイプは秒を必須とし、キロバイトをオプションとした。
IKE フェーズ 2 において、IPsec SA を確立するために、再度 Diffie-Hellman 交換を行って IPsec SA に使用する秘密対称鍵を生成することで、ISAKMP SA の鍵が破られた場
合に、IPsec SA の秘密対称鍵が解読されないようにする Perfect Forward Secrecy(PFS)と呼ばれる仕組みがある。PFS は鍵の解読に対して有用な手段ではあるが、必ずしも必要ではない上に、処理に時間がかかるため、オプションとした。IPsec SA の確立を完全にしてから、その SA を使用開始したい場合に用いられる Commit Bit は、ISAKMPInformational 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 は再送攻撃を防ぐために重要な機能であるため、パケットを送信ノードにおいては必須機能とし、受信ノードにおいてはオプションとした。

- 93 -

表2.4.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

秒
-

キロバイト
○
○

-

○

○
Transport
Tunnel認証付き ESP

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

暗号アルゴリズムISAKMP SA

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

IPsec SAIKE フ ェーズ２

IPsec 通信

ライフタイムのタイプ
PFS
Commit bit
ISAKMP Informational Exchange(CONNECTED Notify Message)
Re-keyカ プ セ ル 化 モ ー End-Nodeド
SGW
セキュリティプロトコル
暗号アルゴリズム

3DES-CBC

認証アルゴリズム

HMAC-SHA1

Anti-replay

2.4.3.5

送信ノード

グループ 1,5,14

受信ノード

MIPv6

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

本のシナリオで、検証できるような設計とした。さらに、被検証機器がある機能を有さない場合、その機能に関わる手順を割愛した場合でも、継続して検査を続けられるよ う に 設 計 し た 。 こ の 策 定 し た 検 査 シ ナ リ オ は 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のモードに関してはアグレッシブモ
ードのみを対象とする。様々な機器に対応するために、テストを実行する際のいくつかのパラメータを選択できるように設計した。フェーズ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.4.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確立

使用 / 不使用- 95 -

表2.4.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

anymanual / IKE

Payload ESP Tunnel ESP Tunnel

2.4.3.6

VoIP/SIPSIP については、2003 年度に SIP 端末の基本機能に関する仕様適合性検査仕様の策
定、検査ツールの開発を行っている。したがって、2004 年度は、SIP 機器に関する機器適合性検査仕様をさらに拡張し、SIP 接続時における拡張手順に対応し、また、SIPの普及推進を進めている団体である SIP Forum において、SIP 機器間の相互接続の問
題事例をまとめたドキュメントである、実装仕様に対応した検査仕様を策定した。更に、SIP の基本機能に関する相互接続テストシナリオを策定した。
SIP 接続の拡張手順への対応として、以下の項目に対する検査仕様を策定し・検査ツールの開発を行った。
a) 信頼性b) サービスを考慮した追加機能であるセッションタイマー機能c) 信頼性のある暫定応答機能d) SIP サーバからのダイジェスト認証の要求に対応しない SIP 端末への対応
SIP Forum の実装仕様への対応として、以下の項目に対する検査仕様を策定し・検査ツールの開発を行った。
a) 不正メッセージ処理b) ダイジェスト認証処理c) 登録処理d) ダイアログ確立および確立後処理
SIP を用いた接続形態は、大きく以下の二つに分類される。
-

ユーザ・ネットワーク間インターフェイス（UNI）-

ネットワーク・ネットワーク間インターフェイス（NNI）

これらの二つの構成に対応した相互接続テストシナリオを策定した。
UNI 接続に関する検査シナリオにおいては以下の項目を検査している。

- 96 -

a) 新規アドレス登録処理b) 同一ドメインへの発信処理
c) 同一ドメインからの着信処理d) 同一ドメインへの発呼切断要求処理e) 同一ドメインからの発呼切断受理処理f) 同一ドメインへの着呼切断要求処理g) 同一ドメインからの着呼切断受理処理h) 同一ドメインへの発呼保留要求処理i) 同一ドメインへの発呼保留解除要求処理j) 同一ドメインからの発呼保留受理処理k) 同一ドメインからの発呼保留解除受理処理l) 同一ドメインへの着呼保留要求処理m) 同一ドメインへの着呼保留解除要求処理n) 同一ドメインからの着呼保留受理処理o) 同一ドメインからの着呼保留解除受理処理p) 同一ドメインへの発信取り消し処理q) 同一ドメインからの着信拒否処理
NNI 接続に関する検査シナリオにおいては以下の項目を検査している。
a) 他ドメインへの発信処理b) 他ドメインからの着信処理c) 他ドメインへの発呼切断要求処理d) 他ドメインからの発呼切断受理処理e) 他ドメインへの着呼切断要求処理f) 他ドメインからの着呼切断受理処理g) 他ドメインへの発呼保留要求処理h) 他ドメインへの発呼保留解除要求処理i) 他ドメインからの発呼保留受理処理j) 他ドメインからの発呼保留解除受理処理k) 他ドメインへの着呼保留要求処理l) 他ドメインへの着呼保留解除要求処理m) 他ドメインからの着呼保留受理処理n) 他ドメインからの着呼保留解除受理処理o) 他ドメインへの発信取り消し処理p) 他ドメインからの着信拒否処理- 97 -

2.4.4

まとめ

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

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

概要

次世代インターネットを実現するためのインフラ技術の浸透は、現在のインターネ
ットが実現している社会インフラとしての地位をより高め、高度なライフラインとしてさらに新しい価値観を生み出すことが実現可能となる。しかし、次世代インターネ
ットをたやすく市場に浸透させることは困難である。何故なら、必要性の周知や構築
手法は、口頭説明程度ではユーザが踏み込むレベルにはない。さらに、次世代インターネットの技術構成要素は、カタログスペックで実装を明記しているものの、実際の現場で適用しても全体として機能しないことがわかっている。それは、現在のネット
ワーク環境が地域ネットワークの発達によってそれを核にしたネットワーク造りが浸透し、複数のネットワークと相互接続する環境が主流になっているためで、相互接続性の確保が不可欠になっている。
このため、岡山 JGNⅡRC（以下「岡山 RC」という）では前身の通信・放送機構

岡山 IPv6 システム検証評価センター時代に、初期レベルの IPv6 通信の確保を目指して、
コアルータ及びスイッチの相互接続性について検証を行ってきた。具体的には IPv6
パケット処理のパフォーマンス評価と一般的な通信プロトコルについて行い、概ね改- 98 -

善が進んだことを発表した。IPv6 の早期普及は、この成果を元に着実に浸透しつつある。しかし、この間ネットワークの構築手法は JGN 時代の ATM から Ethernet をレイヤ
2 に利用するものにシフトし、我が国における地域ネットワークの大部分がそれを用いることに至っている。
このような状況を踏まえ、本報告書では JGNⅡ上に新たに構築した JGNⅡv6（JGNⅡ
上に構築した研究開発用 IPv6 ネットワーク）についてと、次世代インターネットのコア要素として注目されている通信・放送融合を IPv6 ネットワーク上で実現させるための研究について報告する。
2.5.2

JGNⅡv6 の構築

2.5.2.1 JGN2v6 のポリシー
我々が考えている IPv6 ネットワークで実現する事は、非常に単純な考え方を基礎としている。現在の IPv4 ネットワークは、インターネットの発達とともに進化してきた
経緯もあり、ユニキャストを中心とした利用方法で且つ、アドレスの不足をサーバ経由の通信で補うというスタイルとなっている。これをそもそものインターネットの原点である P2P 接続が可能なものであるとか、ここが重要だが、1 つのポートでユニキ
ャストもマルチキャストもユーザが意識せずに（ポート接続替え等）サービスが利用できることを実現させることにある。
そこで、Ethernet ベースの研究開発用ネットワーク JGNⅡ上に新たに IPv6 ネットワ
ーク JGN2v6 を構築することとした。これには、フェーズ 1 として次のような要素を盛り込んだ。
① IPv6 マルチキャスト対応(ア) PIM-SM RP（Rendezvous Point）の正副配置運用(イ) MLD-Snooping 対応によるマルチキャスト不要ポートへのフラッディング抑止(ウ) ネットワーク全体でのマルチキャスト対応（性能評価含めて）② 他ネットワークとの連携(ア) IPv6 普及のための AUP レベル(イ) 実証実験への積極的な参加要請③ 信頼性の確保(ア) レイヤ 2、3 レベルの冗長(イ) 運用者（NOC）との連携により、運用課題の抽出
これら、①③を基本として、さらに次世代インターネットして必要な要素をリサーチし、導入するような体制としている。

- 99 -

2.5.2.2

JGNⅡv6 の構成

JGNⅡv6 では、障害時の切り分けを L2、L3 同値に判断できるようにするため、コア
サイトでは、L2 コア拠点を同時に L3 拠点とする方式とした。図 2.5.2.2.1 に論理的な構成を示すが、数的には、コアサイト 8 拠点、ルータサイト 19 拠点、ブリッジサイ
ト 42 拠点となっており、これによって全国に研究開発用 IPv6 ネットワークを提供す
る環境となっている。
アドレッシングは、 JGNv6 では WIDE プロジェクトから借用した pTLA を用いていたが、NICT として独自に取得している 2001:e38::/32 のアドレスブロックの範囲を利用
し、より他ネットワークと相互接続し易い環境とした。

図 2.5.2.2.1

JGNⅡv6 論理構成図（概要）

図 2.5.2.2.2 では、詳細なアドレッシングを示す。コアサイト毎にアグリゲートし、配下組織の管理を委ねる方式とした。また、現在はコアサイト間を iBGP 化していないが、他ネットワークとの接続を考慮して、BGP 化を検討している。図中のコアサイト
間フルメッシュ点線はそれを意味する。

- 100 -

図 2.5.2.2.2
2.5.2.3

JGNⅡv6 論理構成図（詳細）マルチベンダー環境の実現

構築手法として、JGNⅡの L2 スイッチとして動作してした機器を L3 化したため、基本的にコア拠点は単一ベンダー環境となってしまった。これでは、相互接続性の検証を大規模ネットワーク上で評価する環境が無くなってしまうため、堂島にでは他の機種を用いる等、マルチベンダー環境を実現している。
具体的には表 2.5.2.3 のとおりであり、ルータサイトでは、自ら所有している機器を利用することにより、全体では大幅なマルチベンダー環境が実現した。
表 2.5.2.3

構成ルータの種類（ルータサイトは一部）

ベンダー名

製品名

拠点名

GS4000

コアサイト

GR2000-2B

ルータサイトCatalyst6500

コアサイト（堂島）

GSR12406

コアサイト

Juniper Networks

T320

コアサイト（N 大手町）

PROCKET Networks

PRO8801

ルータサイト

日立製作所
Cisco Systems- 101 -

この状況は、地域ネットワークとの接続に際しても同様であり、マルチベンダー環
境での接続は、必然的に発生していくことがわかる。
2.5.2.4

経路制御

ルータサイトにおける利用者ネットワーク収容の方式を、経路制御レベルとして次のように規定した。
① プロトコル(ア) OSPFv3 を全ルータ、広告対象全論理 I/F（loopback 含む）で設定※ Authentication key はルータ未対応のため、今後設定(イ) area0：コア間(ウ) 個別 area：ルータサイト接続利用者収容エリア
拠点名

area ID

N 大手町

1.0.0.0

K 大手町

2.0.0.0

東大

3.0.0.0

堂島

4.0.0.0

岡山 RC

5.0.0.0

九大

6.0.0.0

石川

7.0.0.0

東北大

8.0.0.0(エ) 経路制御イメージ- 102 -

2.5.2.5

IPv6 マルチキャスト対応

ポリシー部分でも触れたが、岡山 RC での研究内容を実現するために、JGNⅡv6 には設計段階から IPv6 マルチキャストが定常利用可能な構成とした。Primary-RP：九大
GS4000、Secondary-RP：堂島 Catalyst6500 とし、異機種間での RP フェイルオーバー
が可能かどうかも検証する環境にある。これについては、先に記述する IPv6 マルチキ
ャストの具体的な研究報告欄で記述するが、想定した異機種間フェイルオーバーには課題があることが判明している。
2.5.3

IPv6 マルチキャストの相互接続性の検証

2.5.3.1

マルチキャスト技術利用の背景

岡山 RC では、IPv6 マルチキャストの相互接続性の検証をラボレベルはもちろんであるが、実ネットワークでの通信・放送融合モデルとして実証実験を主体に行った。
マルチキャストといえば、「映像などのソースを複数の受信者に同時に配信する」という場合に利用するイメージが主流である。しかし、現在の著作権等放送利用する場合、実際には解決しなければならない障壁は高い。最終的にはそれも一つの利用方法だと規定すれば良いわけであり、利用方法はこれに限定されない。また、これらの検証を進めてきたことと、それを利用するための市場形成をこれらの実証実験により行ってきたため、機器ベンダーの意識として早期に実装する必要があると認識されてきた。
従って、IPv6 マルチキャストができるという次元での検証ではなく、次世代インター
ネットの構築手法・提供方法を考慮しものでなければならない。
2.5.3.2

過去の検証状況

IPv6 マルチキャストは、IPv6 移行を加速させるためのキラー要素である通信・放送
融合を達成するための次世代インターネットの重要なキーワードとしてとらえ、2004
年 2 月通信・放送機構岡山 IPv6 システム検証評価センター時代に、最初の実証実験を行った。
この時の目的として次の 2 つを掲げ、実利用可能かどうかを含めた初期のテストとして実施した。
① IPv6 マルチキャストの長距離、マルチベンダー運用の実証② 地上波テレビの映像中継に利用できることを実証
また、詳細な内容としては次の 4 点を柱とし、1 ストリームの１方向通信に留めた。
理由としては、この検証は大規模ネットワークを使ったものでは始めてであり、ルータの性能がラボ検証通りかどうか未知なためであった。
① さっぽろ雪祭り会場の映像を複数拠点で同時受信し、品質評価を行う② 最長距離の沖縄 札幌間での地上波生中継用素材として用いる- 103 -

③ 同時期に実施されるプロ野球春季キャンプの話題をクロストークするなど、生の比較を番組に生かしながら放送に利用できることの実証④ 放送中継に必須の連絡回線及びキャスター音声折り返し回線をインターネット電話（VoIP）技術で伝送することも実証する
図 2.5.3.2.1 に 2004 年実証実験ネットワーク構成図を示す。利用するネットワーク
は、当然 JGNv6 であるが、PIM-SM の相互接続性に当初から問題があるルータが存在していたため、ATM パスによる専用ネットワークを構築し最適なネットワーク構成として臨んでいる。我々が考える次世代ネットワークのあり方には到底至っていない。

図 2.5.3.2.1

2.5.3.3

2004 年 2 月実証実験構成

本実証実験の概要

今回の実証実験の方式は、放送局のグループ企業が放送素材として同時に同じ素材を利用するようなモデルを想定した。また、前回と同様よりクリティカルな実放送の一部として IPv6 マルチキャストを利用した地上波本放送の素材として利用するという内容とすることはもちろん、1 ヶ月間放送素材を収集する手段として常時利用することとした。

- 104 -

本実証実験へは、表 2.5.3.3 に示す JNN 系列の放送局 6 社が参加し、複数の素材を必要な放送局が取得できるという方式である。
表 2.5.3.3

2.5.3.4

IPv6 マルチキャスト実証実験参加放送局

目的の遷移

2.5.3.2 に昨年の検証目的についてと、JGNⅡv6 構築の際、IPv6 マルチキャストを意識した構築を行ったことに触れた。そこで、今回の検証目的には、大きく実運用を意識した項目を追加した。具体的には次の②がそれに当たる。
① IPv6 マルチキャストの長距離、マルチベンダー運用の実証（前回と同様）② 多地点双方向での IPv6 マルチキャストの同時利用の放送利用実証
また、実証実験の内容を整理すると、次のとおりとなる。
① さっぽろ雪祭り会場の映像を複数拠点で同時受信し、品質評価行う（前回と同様）② 最長距離の沖縄 札幌間での地上波生中継用素材として用いる（前回と同様）③ プロ野球春季キャンプの放送素材の伝送も平行して実施④ 最大で 23 ソースの同時配信⑤ 放送中継活動に必須の連絡用回線及びキャスター音声送り返し回線もインターネ
ット電話（VoIP）技術で伝送（VoIP を使うことは前回と同様）⑥ 放送用途での要求項目の洗い出し(ア) 品質、操作性、遅延等
このように、2004 年の検証内容と比較すると、実証実験の範囲をネットワーク分野に加えて、放送分野にまで拡大した。それは、次世代インターネットを普及させるところに重点を置き、市場と一体となって実施することがその近道だと考えているため- 105 -

である。
2.5.3.5

ネットワーク構成と検証結果

IPv6 マルチキャストプロトコルの相互接続性検証の項目は次のとおりである。
① IPv6 マルチキャストグループ管理---MLD(Multicast Listener Discovery)② IPv6 マルチキャスト経路制御---PIM-SM(Protocol Independent Multicast-Sparse
Mode)
特に、MLD に関しては、レイヤ 2 機能である MLD Snooping について検証を行う。MLD
Snooping については、マルチキャストが不要なポートへ当該パケットを流さないようにするために必要な機能であり、ユーザ側で利用するネットワークを意識させずに（差し替えがない）利用することが可能となる。
図 2.5.3.5.1 MLD Snooping 動作概要を示すが、図中のレシーバクライアント

図 2.5.3.5.1 MLD Snooping 動作概要
（PC）と同じ VLAN 上に VoIP 端末を接続する。MLD Snooping が無い或いは問題があれ- 106 -

ば、VoIP 端末へマルチキャストパケットが漏れることになる。IPv6 マルチキャストにおいて、ユーザ側がネットワークを意識せず使えるようにするということは、正にこの機能である。
次に、ネットワークの構成を図 2.5.3.5.2 及び、図 2.5.3.5.3 に示す。放送本番利
用を検証無しで行うのはリスクが大きいため、「JGNⅡシンポジウム in Osaka」において機能評価を行った。

図 2.5.3.5.2 JGNⅡシンポジウム検証構成
この検証において判明した問題としては次のとおりである。
① 受信グループ Expire 後、再度マルチキャスト経路を構築する時間が長い（最長 15秒程度）② ①を防ぐため、上位ルータへ Static Join を記述すると CPU 使用率が増加。パフォーマンスに影響②においては、2004 年 2 月に同じベンダーのルータで行った際にも発生しており、他機種においても同様の事象が発生することから、ベンダーへ問題としてフィードバ
ックを行った。これは、マルチキャストによるインターネット TV を実現する場合、レスポンスを考え途中のルータ上には全てのグループが存在するように設定する方が望- 107 -

ましいと考えるためで、下流の受信状況に応じてマルチキャスト経路をコントロール
する方法は現実的ではない。
図 2.5.3.5.3 が本番用実証実験構成である。図 2.5.3.2.1 に示した 2004 年 2 月との相違は、特別な専用ネットワークを構築していないという点で、ネットワーク機器の性能と IPv6 マルチキャストの実装が 1 年間で大幅に進化してきたことが理由である。

図 2.5.3.5.3

実証実験構成図中の各拠点においては、通常時放送素材の伝送検証としてプロ野球春季キャンプの素材を本社へ伝送する用途に用いた。検証期間を 1 ヶ月としたのは、沖縄でのキャンプ期間と合わせたことと、長期的に安定して動作するかどうかを評価するためである。
生中継を行うための映像・音声の接続図について、図 2.5.3.5.4 に示す。この例は美浜メディアステーションにおけるものであるが、映像・音声全てをこのネットワー
ク上で展開させていることを示している。
本検証で判明した課題を整理すると、次のようになる。
① マルチキャスト受信する Windows

XP との MLD Snooping のバージョン違いにより、

Cisco Catalyst6503 で Snooping が動作しない。

- 108 -

(ア) Allied Telesis AT9812：Version1(イ) Cisco Systems Catalyst6503：Version2(ウ) Windows XP：Version1(エ) ルータ：Version1,2 両方② Cisco6503 の DR（Designated Router）機能に関する問題（以下状態遷移）(ア) 存在しないはずのマルチキャスト経路が存在(イ) RP に Registration を始める
(ウ) RP へはトラフィックが届かないため、Register Stop は発行されない(エ) Registration 中のまま状態が停止(オ) ハードウェア処理されないため、CPU 利用率が 100%になる(カ) パケット転送ができなくなる③ L2 ループ(ア) 配線問題によりローカルループが発生(イ) 広域ループに発達

ここで、①は MLD Snooping バージョンが、Version2 が Version1 の上位互換として報告を受けている。しかし、今回そのような動作にはなっておらず、ベンダーへ解析- 109 -

を依頼した。
また、②については、(ア)存在しないはずのマルチキャスト経路が存在するという
ところがトリガーになる。どのような場合に発生するかの原因は正確に現状つかめていない。これも、先のソフトウェア処理による CPU 負荷が増大することと同様であり、今後ラボにおいて原因となるトリガー発生について検証を行う予定である。
最後に、③に関して、一つのローカルループが広域ネットワークへ多大な影響を及ぼすことになる（図 2.5.3.6.1）。レイヤ 2 のループ回避として、STP（Spanning Tree
Protocol）があるが、相互接続性には課題があり回避できないという問題が判明している。岡山 RC では、地域ネットワーク間の相互接続という Ethernet ベースによるネットワーク間接続の際に必ず問題になる STP について、今後検証を行っていくこととしている。

図 2.5.3.6.1 ループの発生
2.5.3.6

新たなプロトコルの必要性について

一つのコアネットワーク（広域 Ethernet

L3 環境）へ他のネットワークを接続して地域ネットワーク等大規模ネットワークを構築するモデルでは、利用者収容ネット
ワーク接続セグメント（以下接続セグメントという）が P2P ではなく、ブロードキャ
ストセグメントとなるケースが殆どである。接続ルータには、PIM-SM の設定が入って い る が 、 IPv6 マ ル チ キ ャ ス ト を 利 用 す れ ば 、 接 続 セ グ メ ン ト に あ る 他 の PIM
neighbor のあるルータに不要なマルチキャストトラフィックが流れることになる。さらに、（*,G）等経路学習も発生し、負荷が増える。従って、PIM を Snooping する機構があればそれは防げるため、今後ベンダーとそのプロトコルについて検討を行いた- 110 -

いと考えている。回線が裕福で、機器が高性能であれば垂れ流しても問題ないのかもしれないが、全てがそのような条件にはならない。
本機能のイメージを図 2.5.3.6.2 に示す。

図 2.5.3.6.2PIM による不要トラフィックの発生
2.5.3.7

まとめ

IPv6 ネットワークの普及について、現時点では様々な課題があり実現がスムーズには進んでいない。それには、技術的な課題もあるが、機能的に IPv4 で問題がないという市場の受け止め方がある。現在のインターネットが Web を基本としたサービス体系が確立し、それをインターネットだと誰もが理解し、それをそのまま IPv6 に置き換えるという発想なら必要性が無いと思われても仕方がない。
このような社会浸透の中、岡山 RC では次世代インターネットの基盤技術として IPv6を普及させるという考え方としている。それには、自ら実証し、見せることが必要であり、その成果が普及へと繋がると考えている。
従って、IPv6 ネットワークの構築や、マルチキャスト技術の研究開発は、FTTH 等のコンシューマネットワークが発達した今こそ必要だと考え、本報告のような実証を行った。2004 年度末から ISP においてもようやく IPv6 サービスがコンシューマ向けに提供されるようになり、IPv6 マルチキャストで映像配信を行うという事業者が現れた。
岡山 RC の研究によるベンダーフィードバックにより、それを構成するネットワーク
機器の性能は、格段に向上した段階で事業者はサービスを提供することが可能になっている。研究の初期段階では、どの程度使われるかといった議論がベンダーからあるが、市場に必要な技術トレンドを的確にリサーチすること、研究開発項目の的確な抽出を今後も進めて行くことが普及への近道だと考えている。今後も、このような手法で研究開発を進めて行く予定である。

- 111 -

2.6

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

2.6.1

概要

2.6.1.1

研究の目的

高精細画像伝送やＧＲＩＤなど、ユーザー要求に応じて高速に大容量回線を提供するサービスを必要とするアプリケーションが今後増加すると予想される。これらは既存のネットワークでは実現不可能で、次世代の情報ネットワーク基盤であるＧＭＰＬS＊技術の適応が必要と考えられる。
＊ Generalized

Multi-Protocol Label Switching：IP ネットワークにおいて使われている MPLS の考え方を、複数の異なるレイヤに拡張、発展させたプロトコル群。GMPLS
は、次世代フォトニックネットワークを制御するプロトコルとして注目されている。
ＧＭＰＬＳおよびフォトニックネットワーク技術は我が国のＩＴ戦略上重要な要素技術であると位置付けられている。オンデマンドの大容量回線を要求するアプリケーションをサポートするためのサービスインタフェースおよび運用管理技術の確立が必須であるとともに急務であり、JGNII を用いた GMPLS ネットワーク運用管理技術の確立は、我が国の IT 政策に大きく寄与するものである。
本研究では、上記のアプリケーション等の要求条件に柔軟に対応できるサービスネット
ワークを実現するため、GMPLS ネットワークの運用・管理に関する研究開発を実施する。
（JGNII 上に構築された GMPLS ネットワークを活用し、GMPLS ネットワークの運用・管理技術の確立を行う。）本研究は、従来のブロードバンドサービスネットワーク環境の研究に関する研究開発の推進だけでなく、実環境を用いた研究開発・検証を推進することによる運用・管理技術の確立に総合的に資することを目的とする。
2.6.1.2

研究テーマ

ＪＧＮⅡおよびＧＭＰＬＳのネットワーク構成を図 2.6.1.1 に示す。ＧＭＰＬＳネット
ワークとしては、北回りと南回りの２つのネットワーク（マルチドメイン）で構成されている。本研究テーマではＪＧＮⅡ上に構築されたＧＭＰＬＳネットワークを活用し、GMPLS
ネットワークの運用・管理に関する技術検証等を行い、運用・管理技術を確立する。具体的な研究課題は次の 4 項目であり、2.6.2 章以降にこれらの研究状況を個別に報告する。
（１）マルチレイヤネットワーク運用管理技術の研究開発（２）ＧＭＰＬＳネットワーク高機能・高信頼化に関する研究開発（３）マルチドメイン（Ｅ－ＮＮＩ）統合管理技術に関する研究開発（４）アプリケーションとの連携（ＵＮＩ）に関する研究開発
なお、コアテーマの「GMPLS ネットワーク運用・管理技術の研究開発」に加え、サブテーマ
として以下を設定している。

- 112 -

・

「マルチメディア配信のためのネットワーク制御に関する研究」

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

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

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

GMPLSネットワーク
NW -A : NW 運用管理技術の研究開発

北周りＮＷ

金沢
Kanazawa

福岡
Fukuoka

堂島
Osaka

南周りＮＷ

大手町
OtemachiA

10 G (1G x×
8) 8)

札幌
Sapporo
GMPLS 相互接続技術

IT 北九州
産学Kitakyushu

Kanazawa
金沢
堂島
Osaka

福岡
Fukuoka

NICT 鹿島
Kashimax2
当初 10 G ベース

岡山
Okayama

NICT けいはんな
Keihanna

1G

Otemachi B

Tsukuba
つくば

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

仙台
Sendai

NICT Kitakyushu
北九州 IT センター
Fukuoka
福岡

10G
10 G

10 G
10G
(1G × 8)10 G
10G

NICT Kobe
神戸
10 G
10G

1G
1G

1
G
1G

1G

10G
10
G
(1G × 8)

光

10G
10 G

長野
Nagano

10 G
10G 8)
(1G
×

堂島
Osaka

岡山
Okayama
高知
Kochi

10G
1G

金沢
Kanazawa

1G
1G

名古屋
Nagoya

10G
10 G

10 G
10G
10 G
10G

Koganei
NICT 小金井

10 G ×10G
x 22

NICT 鹿島
Kashima

1G
1G

10G x 2光Otemachi
A RC
NICT つくば
Tsukuba
大手町
堂島

Otemachi B
大手町

NICT Keihanna
けいはんな センター
沖縄
Naha

つくば RC

NICT
けいはんな センター

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

図 2.6.1.2.1 JGNII ネットワークと GMPLS ネットワーク
2.6.2

マルチレイヤネットワーク統合管理技術に関する研究開発

GMPLS ネットワークの運用管理手法について、ここでは 2 つの研究開発課題について報告する。一つは GMPLS と IPv6/MPLS というマルチレイヤ運用管理手法に関する研究開発であり、もう一つは GMPLS ネットワークとユーザ・アプリケーションの連携手法に関する研究開発である。
マルチレイヤ運用管理手法に関する研究開発では、本年度は GMPLS ネットワークと上位
レイヤとなる IPv6/MPLS ネットワークとの連携を図る上で基礎となる技術について研究開発を行った。具体的には、JGNII コアルータの GMPLS 機能拡張および IPv6/MPLS ネットワー
ク収容機能について研究開発である。
JGNII コアルータの GMPLS 機能拡張については、IP ベースの JGNII コアルータに GMPLS
機能を付与し、GMPLS 経路広告機能(OSPF-TE)、光パス設定機能(RSVP-TE)、同一ドメイン内
での OXC・コアルータとの相互接続性確認などの実験を行い、それらの機能の正常性を確認
し、OXC 接続サービスにおいて JGNII コアルータにユーザが直接収容可能であることを示し- 113 -

た(図 2.6.2.1 参照)。

Kanazawa

Fukuoka

GbEx4

GbEx2

GbEx2

GbEx6

GbEx4

GbEx2

GbEx6

GbEx4

GbEx6

GMPLS-controlledrouterPXC

Otemachi(Tokyo)Dojima(Osaka)User’s Node

図 2.6.2.1 GMPLS 技術による JGNII の OXC 接続サービス
また IPv6/MPLS ネットワーク収容機能研究については、コアネットワークとして JGNIIの GMPLS ネットワーク、エッジに IPv6/MPLS ネットワークが接続されること想定した場合の収容手法を検討し、エッジ IPv6 ネットワークとして IPv6 ルータおよび IPv6 測定器を接続して、IPv4 ベースの GMPLS ネットワークを越えた IPv6 ネットワーク同士でのデータ伝送について実験を行った。実験内容は主に『GMPLS 光パスを通した IPv6 経路広告の設定実験』
および『GMPLS 光パスによる IPv6 データ転送実験』の 2 つから成り立っており(実験系は図2.6.2.2 参照)、これらの実験の成功により、JGNII の GMPLS ネットワークによる IPv6 デー
タストリームの収容性を確認できた。また、MPLS ネットワーク収容については、GMPLS ネ
ットワーク上における MPLS 制御データの接続性を JGNII のコアルータを用いて検証した。
こ れ ら の 成 果 に つ い て 、 国 際 会 議 The International Conference on IP + Optical
Network(iPOP2005)および電子情報通信学会 2005 総合大会にて発表を行った。

IPv6
Router

GMPLScontrolled
Routerwith 6PE
GbE

GbE

PXC

PXC

GbE

PXC

GbE

GMPLScontrolled
Routerwith 6PE
GbE

IPv6
Router

GbE

FEx4

FEx4
Core GMPLS network

IPv6
Test set

Edge IPv6 network

IPv6
Test set

図 2.6.2.2 IPv6 transport over GMPLS 実験系- 114 -

GMPLS ネットワークとユーザ・アプリケーションの連携手法に関する研究開発においては、
本年度はユーザオリエントな光パスプロビジョニング技術に関する基礎検討を実施し、ユーザ・アプリケーション側がネットワーク側に求めるパラメータの抽出・絞り込みを行う
と共に、ユーザ側とネットワーク側の接続手法・通信手順などに関する検討を行った。こ
れらの成果については第 1 回・第 2 回 JGN2 ワークショップにて発表し、また外部研究機関と共同で GMPLS ネットワークとアプリケーションが連携するための実験について検討および実験準備を行った。

光波長パス
プロビジョニング技術
接続要求
ルータ
OXC

OXC
接続要求

設定に必要
十分な情報

HTTP等

ユーザ
装置

ルータ

JGNⅡ
ネットワークWeb等

GMPLS
エミュレータ

ユーザ
装置

セキュ
リティ

ユーザ
インターフェース

接続
要求

やり取りの
ルール

ユーザ
装置

図 2.6.2.3 GMPLS ネットワークとユーザアプリケーションの連携技術
また JGNII はテストベッドネットワークで日本初の GMPLS 技術の導入であり、日々のネッ
トワーク運用に関わることにより、上記テーマにおける課題の抽出と解決手法の検討にあ
たった。
2.6.3

GMPLS ネットワークの高機能・高信頼化技術に関する研究開発

ＧＭＰＬＳネットワークの構成技術、運用管理に関する研究を進めた。
サブテーマ３

NMS

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

NE-OpS
UNI

AP

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

サブテーマ２
サブテーマ1

NE-MgrRouter
Type-X

OXC

NE-Mgr

λ

λ
OXC

OXC

図 2.6.3.1 GMPLS ネットワークの研究課題- 115 -

E-NNI

NE-MgrRouter
Type-X他GMPLS
ネットワーク具体的には研究項目を、ＧＭＰＬＳルーター、ＯＸＣ（光クロスコネクト）、ＮＭＳ（ネッ
トワークマネージメントシステム）に関する以下のテーマ設定に基づいて進めた（図 2.6.3.1 参照）。
（１）GPMLS フォトニックネットワークにおけるサービスインタフェースに関する研究（２）GMPLS 技術を用いたフォトニックノードにおける光パスの高速制御性に関する研究（３）GMPLS 網管理システムにおけるカスタマ制御を用いた網運用方式の検討
以下に研究の概要を示す。
（１）GPMLS フォトニックネットワークにおけるサービスインタフェースに関する研究
ＪＧＮⅡ上の GMPLS フォトニックネットワークにおいて、サービスインタフェースの必要条件を明確にすることを目標として以下の研究を行う。
■安定性、スケーラビリティを含めたプロトコルの機能、性能評価の検討■サービスインタフェースとしての必要条件、課題及びボトルネックの明確化とネットワーク運用管理などへの影響の検討。
■広帯域アプリケーション伝送によりネットワーク性能評価
具体的には大規模・高信頼コアルータ Type-X320 を用いた以下の検証を進めた。
･パス設定･解除機能確認･設定パスの安定性、品質等の評価･ＮＷスケーラビリティに関する評価
また、Optical UNI 機能に関するフィールド検証として、・パス設定（Ⅰ、Ⅱ）・グレースフル削除（Ⅰ、Ⅱ）・強制削除（Ⅰ、Ⅱ）・エラー制御 （Ⅱ）
・リカバリー （Ⅱ）などの動作の正常性確認、Optical UNI 機能と要求条件の検討を進めた。なお上記で（Ｉ、ＩＩ）はルータ、ＮＭＳからの操作、（ＩＩ）はルータからの操作を示す（図 2.6.3.2 参照）
機能確認と並行して、不具合部については修正し、ファイル更新を適宜行った。
ＧＭＰＬＳネットワークの設定、検証等の概要を表 2.6.3.1 に示す。

- 116 -

NMS

NE-OpSⅠ
NE-Mgr【大手町・堂島】

10GPOS

OXC

NE-Mgr【堂島・京阪奈】λλⅡRouter
Type-X

NE-MgrOXC

OXC

Optical Path

10GPOS

Router
Type-X

図 2.6.3.2 GMPLS ルータの検証系

表 2.6.3.1 GMPLS ルータの操作、検証
作業概要
確認項目
結果
H16.9 ・東京国際映画祭事前調査（大手町）・回線PKGの搭載と事前環境調査
実装完了
H16.10 ・東京国際映画祭事前調査（けいはんな）
・回線PKGの搭載と事前環境調査
実装完了
・東京国際映画祭事前検証（六本木、大手町、けいはんな）・大手町、けいはんなでの環境構築、検証OK・大手町、けいはんなでのアクセス回線込みの事前検証
・東京国際映画祭当日対応(六本木、大手町、けいはんな)・けいはんな->大手町(六本木)のSHD転送確認
完了
H16.11 ・Type-X320J GMPLS検証事前調査
・検証に向けたGPSシステムの動作確認
OK
H16.12 ・Type-X320J GMPLS検証(けいはんな～大手町)
・Src UNI-Cからのグレースフル削除機能の確認
・Src UNI-N, Dst UNI-Nからの強制削除機能の確認（削除後、新規パス生成有）・パス生成時、生成後のエラーシーケンス確認
・GPS試験装置の動作確認（約4時間でGPSロック完了）
・大手町～けいはんな間遅延測定≒4ms
OK・パス生成動作に伴う、シグナリング完了時間の測定≒2s
・パスの強制削除に伴う、シグナリング完了時間の測定≒2s
・パスのSrc UNI-Cグレースフル削除に伴う、シグナリング完了時間の測定≒5s・パラメータ誤り時のPathErr msg.内Objectの差分を確認(Type-Xトリガのみ)
・RSVPパス過負荷設定確認（Max5000本までの設定を確認（試験機制限））
H17.1 ・JGNⅡシンポジウムｉｎ大阪環境構築
・大手町～堂島間、けいはんな～堂島間ＧＭＰＬＳパス設定
完了
・大手町、堂島、けいはんなにＶＬＡＮ設定
H17.2 ・iPOP環境構築、動作確認
・けいはんな～大手町間GMPLSパス設定
・マルチキャスト設定
完了
・edge側導通設定/確認
・動作確認(けいはんな～大手町)
・動作確認(けいはんな～会場(TFT))（２）GMPLS 技術を用いたフォトニックノードにおける光パスの高速制御性に関する研究
GMPLS 技術を用いた OXC が、ユーザの要求応じられるだけの性能条件を実現可能かどうかの検証を目的に以下の研究を行う。
■

プロトコルベースの対話型制御による光パスの制御における光パスの設定/解除などの高速性の追求。
■

ノード数や光パス規模に対するスケーラビリティと迅速性のトレードオフの明確化- 117 -

具体的には、高速波長可変レーザを用いた下記についての実験（図 2.6.3.3）と性能評価等を行った。
･パス設定･解除の機能確認･光学特性･動作特性･安定性･回線品質などの評価
実験項目１：波長可変域が広く、波長設定時間が高速な波長可変ﾚの実ﾌｨｰﾙﾄﾞにおける動作の安定性検証を行った。
①パス設定／削除制御時の安定性の検証②長期安定性の検証
実験項目２：高速波長可変レーザの適用による、パス設定／削除時間高速化に関する性能検証
現在搭載している波長可変レーザは温度制御型で波長が安定するまで時間を要している。
このため電流制御型の高速波長可変レーザを用いて、波長および制御系の高速性、安定性を検証した。制御系全体として９０秒程度から数１０秒レベルに改善した。

OXC

OXC
TDR

OSOR

TDR

OSOR

TDR
TDR

OSOR

TDR

OSOR

TDR

OTN

TDR
TDR

OSOR

OSOR

TDR
TDR

TDR

TDR

測定器

測定器

：高速可変ﾚｰｻﾞ搭載＊けいはんなー堂島－大手町の系で実施

図 2.6.3.3 高速波長可変レーザによる性能評価実験- 118 -

（３）GMPLS 網管理システムにおけるカスタマ制御を用いた網運用方式の検討
GMPLS 機能に、NMS による複数レイヤ統合管理（マルチレイヤ管理）を組合せることにより、さらなるサービス提供や迅速かつ効率的なネットワーク運用が可能となるよう、以下の研究を進めている。
■カスタマコントロール機能（図 2.6.3.4 参照）として、GMPLS 機能に基づく複数レイヤを跨るパス開通機能ならびに開通したパスの構成情報や故障情報の表示機能についての検討。
■カスタマコントロールユーザに対して複数の権限種別を設定する（表 2.6.3.2）ことにより、ユーザ区分に応じた柔軟な権限付与および管理制御機能の提供の実現についての検討。
具体的には、･カスタマコントロール関連の機能･安定性確認、評価･ネットワーク管理情報に関する機能確認、評価･ユーザ向けメール通知機能に関する機能･安定性の確認、評価などを目指した検討を進めた。
また、インターネット等外部ネットワークを介してサービス利用ユーザに JGN2 ネットワー
クの運用情報を提供するカスタマコントロール機能について実フィールドの動作検証を行う予定であるが、今年度は内部ネットワークで以下の検証を行った。
（１）カスタマコントロールサーバ/外部ネットワーク接続の検証（２）ネットワーク管理情報検索表示機能の検証（３）メール通知機能の検証

HMI
HMI
端末
端末

ﾌｧｲｱｳｫｰﾙ（新規）
ﾌｧｲｱｳｫｰﾙ（新規）

NMSｻｰﾊﾞ
NMSｻｰﾊﾞ

オペレータ

ｶｽﾀﾏｺﾝﾄﾛｰﾙｻｰﾊﾞ
ｶｽﾀﾏｺﾝﾄﾛｰﾙｻｰﾊﾞ

擬似ｶｽ
擬似ｶｽ
ﾀﾏ端末
ﾀﾏ端末

ｲﾝﾀｰﾈｯﾄ等外部NW※既存あり/接続変更必要※既存あり/接続変更必要

X320J
X320J

NE-OpS
NE-OpS

OXC
OXC

GMPLS

ﾒｰﾙｻｰﾊﾞ（新規）
ﾒｰﾙｻｰﾊﾞ（新規）

NE-Mgr
NE-MgrDMZ

図 2.6.3.4 カスタマコントロール機能- 119 -

擬似ｶｽ
擬似ｶｽ
ﾀﾏ端末
ﾀﾏ端末
カスタマコントロールユーザ

表 2.6.3.2 カスタマコントロールに関するユーザの分類

機能リソース管理ネットワーク構成管理

サービス管理故障管理

操作内容

・装置情報表示

・パス情報表示・サービスオーダ検索
・パス登録/削除/切替

・原因故障表示・サービス故障表示

管理者

○

○

○

○

特権ユーザ

×

○（※1）

○（※1）

○

特別ユーザ

×

○（※2）

×

○

一般ユーザ

×

×

×

○

(※1)自パスのパス情報表示/制御（登録/削除/切替）が可能(※2)自パスのパス情報表示が可能

2.6.4

マルチドメイン(E-NNI)統合管理技術に関する研究開発

2.6.4.1

研究概要

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

実施内容

12 月 14～21 日: 関東-1、関東-2 の間の STM-64 の実験用波長を用いて、データプレーンで OXC 間を接続。コントロールプレーンについては、L2 サービスを利用して接続した- 120 -

（図 2.6.4.1 参照）。
STM-64

C-Plane
北陸-1
OXC

C-Plane

GMPLS
E-NNI
接続

関東-2
OXC

関東-1
OXC

近畿-1
OXC

C-PlaneP2P接続(VLAN使用)

図 2.6.4.1 Ｅ－ＮＮＩ実験構成図[結果]: OXC-OXC 間の接続については、相互に接続を確認。ルータ-ルータ間について
は、STM-64 を用いた場合について、お互いのパラメータに齟齬が有るため、ルータベンダ
での改修を必要とする(改修要望を挙げている)。
2.6.4.3

今後の予定

上半期中に JGNⅡの Gigabit Ether を利用した E-NNI 相互接続実験を再度実施予定している。検討線表を図 2.6.4.2 に示す。

2004 Q4

2005
Inter AS Signaling

簡易E-NNI接続
JGN相接実験（第1回）

アーキテクチャ ＆ アドレッシング
シグナリング （OIF or IETF?）
警報転送

Peer – Overlay接続

E-NNI接続JGN相接実験（第2回）
White Paper作成
相接仕様Fix

JGN相接実験 JGN相接実験（第3回事前）（第3回）

内容により実施
可能時期はシフト

外部投稿予定外部投稿予定E-NNI接続JGN相接検証
（第4回）

実運用への
移行開始
(要検討)

Inter AS Routing
アーキテクチャ (PCE or BGP?)
プロトコル検討

相接仕様Fix※標準化の動向に従い適宜計画修正

図 2.6.4.2 E-NNI に関する検討線表- 121 -

2.6.5

アプリケーションとの連携

２．６．２項～２．６．４項で述べたＧＭＰＬＳネットワークおよび運用管理に関する研究に加え、最終ユーザであるアプリケーションとの連携についての検討を進めた。
つくばＪＧＮⅡリサーチセンターでは毎月セミナーおよびスタフミーティングを開催し、拠点研究員、特別研究員で議論の場を設けている。ＧＭＰＬＳに関してはネットワーク関係者８名、アプリケーション関係者３名である。開始時点ではネットワーク関係者はＧＲ
ＩＤ等のアプリケーションについて充分な知識がなくまた、アプリケーション関係者はＧ
ＭＰＬＳについて不案内であったことから、基礎的な理解を深めることから始めた。
つくば地域では産業総合研究所、高エネルギー＊＊、など高速アプリケーションを扱う研究機関があり、オンデマンドでの高速回線要求も考えられることから、公開でのセミナーを開催し、アプリケーションとネットワークの連携について可能性を探った。
表 2.6.5.1 に概要を示す。
今後、さらに具体的な連携法について検討を深めていく予定である。
表 2.6.5.1 ＧＭＰＬＳセミナー
日時２００４年２月１４日

場所

産業技術総合研究所（つくば本部）

主催

つくば JGNII リサーチセンター
産業技術総合研究所（グリッド研究センター）

プログラム▼開会の挨拶：(古賀つくば JGNⅡリサーチセンター長)●ユーザから見た GMPLS ネットワーク●大容量ネットワークのトレンド●GMPLS 入門(GMPLS とは何か。その仕組みをわかりやすく解説。)●GMPLS が実現する未来のネットワーク(JGNII の紹介を含む)●講演：『グリッドコンピューティングからみた JGN への期待』●パネルディスカッション：～GMPLS 技術がユーザにもたらすもの～▼ 閉会の挨拶：(横川グリッド研究センター副センター長)

参加者

約５０名（約６０％が AP 関係者）

主な意見、等・AP と NW を結ぶミドルウェアは NW が細いことを今は前提にしている。
（GMPLS で高速回線が自由に使えるようになれば構造変革が起こる？）
・帯域はあればあるほど使いきれる（どんどん出してほしい）（高速専用線の時間貸し／高速プロビジョニング
・

イメージ）

リクエストがクラスタ相互に跳びかっている（ある時間飛ばして、休んでまた飛ばす）・時間は指定しないがある時間帯のどっかで５分ほどということもある。

- 122 -

・リクエストして使えなかったときのリスクの検討も必要。
・料金はとりあえず３分１０円で。
（超高速の電話網／回線交換網のイメージ？）・もっと短い保留時間のリクエストもあるかもしれない。
（光バーストのイメージ？）
その他：料金やユーザ、等

2.6.6

イベント等

(1)東京国際映画際におけるデジタルシネマ伝送実験デモ(H16.10.26、東京デジタルシンポ
ジウム 2004、六本木ヒルズ 49F オーディトリアムイベント会場である六本木ヒルズ 49F
オーディトリアムに対して、JGNⅡ拠点である NICT けいはんな情報通信融合研究センター(以降では単にけいはんなとする)から関東基幹通信網構成拠点 A(以降では単に大手町とする)を経由して、デジタルシネマ及び HDTV のライブ映像を伝送した。JGNⅡでは、
X320J(ルータ)を用いた 1 波長を占有した GMPLS パス上での伝送である。ネットワーク
構成図は以下の図の通りである。参加者は会場一杯の 150 名程でハリウッドを中心とした国内外の映画関係者に日本の光ネットワークの普及の速さとシネマ配信の可能性を
示した。

HDTV
Camera

けいはんな

六本木ヒルズ

大手町

堂島

NMS

L2
SW

X320J

GS4000

デジタルシネマ
server

OXC

OXC

OXC

X320J

X320J

M
/
C

M
/
C

GS4000

L2、L3サービス向け

L2、L3サービス向け

けいはんなのサーバから六本木へデータ転送
・デジタルシネマ(評価用映像)
JPEG2000 (TCP)・HDTVライブ映像
MPEG2 (UDP)
図 2.6.6.1 東京国際映画祭でのデジタルシネマ伝送のネットワーク構成- 123 -

(2)JGNⅡシンポジウムにおけるＧＭＰＬＳネットワーク制御デモ（H17.01.17～18、大阪国際会議場）
JGNII シンポジウムでは、『GMPLS 波長パス設定システム』という表題にてデモンストレーションを行った。
内容は、つくば RC にて研究開発を行っている GMPLS 技術を使い、JGNII
における『OXC 接続サービス』の光波長パスが簡単に設定できることを示すものである。
図 2.6.2.2 の通り、実際に GMPLS ネットワークの運用管理に使用しているシステムを用い、福岡・金沢・大手町(東京)と堂島(大阪)を結ぶ大容量光波長パスを即座に確立し、パスの状態をグラフィカルに表示できたため質問も多数あり、好評であった。

JGN2九州-1
アクセスポイント(福岡)

JGN2北陸-1
アクセスポイント（ 金沢)

JGN2関東-2
アクセスポイント
（ 東京)

金沢OXC

測定器
福岡OXC

東京OXC

データ
デモ用PC

ビデオカメラ

大手町からの眺望

GMPLSとOXCの連携により、ギガビットの光パスを迅速に設定可能光パスの設定指令

ギガビットの
データ転送

JGNIIシンポジウム
2005 in 大阪会場

測定器
プラズマ
ディスプレイ

データ
デモ用PC

マネージメント
デモ用PC

図 2.6.2.2 ＧＭＰＬＳネットワーク制御デモ構成図(3) JGNⅡシンポジウムにおける NMS カスタマ制御端末デモ及びデジタルシネマ伝送（H17.01.17～18、大阪国際会議場）
NMS: JGNⅡに導入されている GMPLS ネットワーク対応 NMS に関して、遠隔のネットワー
ク利用ユーザの権限に応じて情報を提供するカスタマコントロール機能について実運
用中の NMS に、会場に伸ばした管理ドメインを介して、さまざまなユーザ権限でアクセスし、その利用イメージを紹介した。
デジタルシネマ: つくば→大阪、けいはんな→大阪の 2 本の GMPLS パスによるデジタル
シネマの伝送を確認。距離の異なる 2 つのパスを用いた伝送であったが、距離を感じさ- 124 -

せない良好な伝送性能を示した。

NMS

他トラ
フィック

X320J

GS
4K

大手町

けいはんな
デジタル
シネマ
サーバ

つくば

HDTV
HDTV
カメラ
エンコーダ

実験用波長
X320J

OXCS2

OXCS2

JGNⅡ
JGNⅡ
ネットーワーク

JG
JG
NNⅡ
Ⅱ
L2
L2
NW
NW

GS
4K

L2
SW
デジタル
シネマ
サーバ

OXCS2

大阪国際会議場

GMPLSパスデジタル
シネマデコーダ

X320J

他トラ
フィック

GS4K

堂島

GS
4K

プロジェクタL2
SW
HDTVデコーダ

図 2.6.6.3 JGNⅡシンポジウム 2005 でのデジタルシネマ伝送のネットワーク構成(４) iPOP2005 における高画質画像伝送（H17.02.21～22、東京ファッションタウン）
イベント会場である東京ファッションタウンビルに対して、JGNⅡ拠点である NICT け
いはんな情報通信融合研究センター(以降、JGNⅡ呼称名の「近畿-4」とする)から NTT
大手町ビル(以降、JGNⅡ呼称名の「関東-1」とする)を経由して、DVTS を利用したライブ映像を伝送した。なお、JGNⅡ上は、X320J(GMPLS ルータ)を用いた GMPLS パス上での伝送である。また X320J への設定により、会場の各受信端末へ multicast にて映像伝送した。ネットワーク構成は以下の図の通りである。これにより国内外の GMPLS 研究
者に GMPLS を具備した最先端のテストベッドとしての JGNⅡを印象付けることが出来た。
東京ファッションタウンビル

ﾒﾃﾞｨｱｺﾝﾊﾞｰﾀ

DDSS
U 135M専用線 U

ﾒﾃﾞｨｱｺﾝﾊﾞｰﾀ

L2SW
関東‐１

X320J
JGN
JGNIIII
Type-X網
Type-X網

近畿‐４
NW室

X320J
L2SW

PC

PC

PC
ラボ室

PC

パ
パ
図 2.6.6.4 iPOP2005 での DVTS ライブ映像伝送のネットワーク構成
ッ
ッ

カメラ

PDP

ﾌﾟﾛｼﾞｪｸﾀ

Hall300

ホワイエ

Hall500

カメラ
カメラ- 125 -

チ
パ
ネ
ル

チ
パ
ネ
ル

PC

L2SW

カメラ

2.6.7

対外発表●国際会議（１）古賀：「JGNII and a Research Project on GMPLS at Tsukuba JGNII Research enter」
iPOP2005(international conference on IP + Optical network) ,2005/2/21-22, Tokyo（２）岡本、大谷、古賀：「Operational Experience on GMPLS Network Test Bed of Japan
Gigabit Network II」
iPOP2005 (international conference on IP + Optical network), 2005/2/21-22,Tokyo●国内学会（１）岡本：「JGNII のＧＭＰＬＳネットワークを用いたＩＰｖ６転送実験」
2005 年 3 月 21 日、2005 年電子情報通信学会総合大会（大阪大）
電子情報通信学会 2005 総合大会 [2005/3/21-24](発表：岡本拠点研究員)（２）小内伸夫・柳沼英樹・大原拓也・鮫島康則「GMPLS 対応ネットワークにおけるカスタ
マコントロール管理に関する一検討」2005 年 3 月 21 日、2005 年電子情報通信学会総合大会（大阪大）●その他（１）第 1 回 JGN2 ワークショップ 2004/6/28、大手町（岡本拠点研究員、藤原現特別研究員）（２）第 2 回 JGN2 ワークショップ

2004/11/1(大谷特別研究員)（３）GMPLS セミナー[2005/2/14、産業技術総合研究所(つくば市)]（岡本拠点研究員、岡野拠点研究員、大谷特別研究員、藤原特別研究員、鮫島特別研究員）（４）第 4 回つくば WAN シンポジウム 2005/3/8、研究交流センター／つくば市](岡本拠点研究員)（５）つくば RC セミナー
「JGNⅡつくば-大手町高速回線について」2004/10(岡本拠点研究員)「リアルタイム災害監視への取り組み」2005/1（佐藤特別研究員）- 126 -

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

第3章
3.1

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

概要

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

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

ユーザ（端末・アプリ）

図 3.1.1

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

これら３つのサブテーマに関して、平成１６年度は、査読付き国際会議８件を含む
１４件の対外発表、プロトタイプ試作や国際共同実験などの成果を上げ、またそれらを JGNⅡシンポジウムでのデモンストレーションで紹介した。
サブテーマ A では、フロー計測技術に関して、高精度タイムスタンプ（百ナノ秒ク- 127 -ラス）を用いたパケット遅延・パケット間隔計測の有効性評価（実験）、ギガビットイーサ上での細粒度フロー計測システムの試作を行い、フロー多重化技術に関して、分散計算型アプリケーションがネットワークへ与える影響及びネットワーク状態がアプ
リケーション性能へ与える影響の調査（実験）や、バースト性・継続時間・平均レートなどの特性の異なるフローを多重化した場合の遅延特性の調査（モデルシミュレーション）を行った。
サブテーマ B では、単一無線網での資源利用制御に関して、無線 LAN における複数
AP(アクセスポイント）の自律分散的選択手法とその特性分析（シミュレーション）、
W-CDMA 網‐インターネット間の実時間通信における品質向上のためのフロー制御手
法評価（シミュレーション）、固定 AP 間が高速無線 LAN で結ばれるマルチホップ無線網における経路制御・チャネル割当の実験環境構築を行い、また、複数異種アクセス
網での資源利用制御に関しては、マルチホーム端末環境におけるアクセス網の効果的な利用切り替えのためのアソシエーション層手法評価（シミュレーション、試作）を行った。
サブテーマ C では、高遅延帯域幅環境でのデータ転送技術に関しては、高速トラン
スポートプロトコルの変動する環境及び異種フローの混在環境での特性調査（JGNII、JGNII 国際回線を用いた実験）と超高速ネットワーク(10Gbps)を用いる実験環境構築を行い、ルータ支援によるパケット制御技術に関しては、実時間通信フローの競合時の遅延特性の改善のための早期パケット廃棄手法評価（シミュレーション）を行った。

- 128 -

3.2
3.2.1

ネットワーク計測に基づく適応経路制御技術の研究開発
はじめに将来のインターネットは、アクセス網を接続するバックボーンネットワークにおいてトラヒックの時間的/空間的集中が頻繁に発生すると考えられる。さらに高い通信品
質を要求するアプリケーションも定常的に利用されることが考えられ、バックボーン
ネットワークでは集中するトラヒックを網全体で分散しつつ通信品質を保証することが不可欠となる。
多量なトラヒックが交換されるバックボーンネットワークのコア網において通信品質を保証するためには、トラヒックのパターンやバースト性などトラヒック特性に基づくトラヒックの分類を可能とするトラヒックフローの実時間計測が求められる。また、コア網に確立される限られた数の通信パスへ多様な特性のトラヒックフローを配分することが求められ、トラヒックフローの多重特性を考慮したトラヒック制御 (通信パス選択) が必要となる。さらに、コア網のネットワーク資源を効率よく利用する
ために、コア網を取り巻くエッジルータが互いに協調して、これらの計測と制御を行う必要がある。
そこで、本研究開発では 3 つの研究課題に重点を置いてバックボーンネットワークの高効率な利用技術の開発を行う。
トラヒックフローの多重特性の解析
トラヒックフロー特性の計測･実時間推定手法の開発
エッジ/コア網連携手法の開発
トラヒックフローの多重特性の解析では、エッジルータにおいて多様な特性のトラ
ヒックフローをトラヒック特性に基づいて複数の通信パスへ配分する際の最適化方式の開発を目指している。平成 16 年度は、組み合わせると他のトラヒックフローへ悪影
響を及ぼすトラヒックフローや、通信パスの利用率を高めても特性変化を起こしにくいトラヒックフローの組み合わせを明らかにするため、解析手法の検討を行い解析プ
ログラムの開発を行った。また、開発されるトラヒック多重の最適化方式の実証に向けて、ギガビットクラスのトラヒックを対象としたフロー計測システムの開発を行った (0 節)。さらに、通信の変化が実行性能に大きく影響するアプリケーションのトラ
ヒックに通信パスを割り当てるトラヒック制御を行う場合に、アプリケーションの実
行性能に着目することの有効性を調査するため、ネットワーク特性がアプリケーショ
ンの実行性能へ及ぼす影響の分析を行った (0 節)。
トラヒックフロー特性の計測･実時間推定手法の開発では、10G ビットの回線を流れるトラヒックのフロー特性 (バースト性や速度) をリアルタイムに推定する手法の開発を目指している。平成 16 年度は高速回線のトラヒック計測に不可欠な高精度タイム
スタンプの有効性を、実際にトラヒック計測の実験を行って示した (0 節)。

- 129 -

エッジ/コア網連携手法の開発では、エッジルータによるトラヒックフロー特性計測
およびコア網でのトラヒック量計測の情報をもとに、コア網を通過するトラヒックフ
ローの品質劣化の検出および他のトラヒックフローへ悪影響を与えるトラヒックフロ
ーの分離を、複数のエッジルータのペアの間で協調して行う連携方式の開発を目指している。この研究課題は平成 17 年度から着手する予定である。
3.2.2

流体解析手法を用いたトラヒックフロー多重解析の検討と分散型リアルタイ

ムフロー解析システムの開発
3.2.2.1

概要

通信品質を保証するトラヒック制御技術には、シェーピング、パケットスケジュー
リング、受付制御がある。これらの技術は通信パスの一つひとつに複数のトラヒック
クラスを定義し、各トラヒッククラスに対して異なるパラメータを用いてトラヒックを制御することが求められる。しかし、超高速コア網では通信パスはエッジルータの間にフルメッシュに確立され、エッジルータのペアの間で複数本の通信パスが確立されることが予想される。コア網において、通信パスに複数のトラヒッククラスを定義
して通信パスを複数制御することは、コア網のトラヒック速度の観点から処理負荷を著しく増大させることが懸念される。コア網は高速なパケット転送に特化し、エッジ
ルータが通信パス単位にシェーピングを行うシンプルな制御が望ましい。そして、組
み合わせてもトラヒック特性が余り変化しない親和性の高いトラヒックフローを優先して組み合わせる、または、他のトラヒックに悪影響を及ぼすトラヒックフローを分離するなどのトラヒックフロー単位の通信パス選択が可能になれば、品質保証とコア網の効率化が可能と考えられる。
そこで、どのような特性をもつトラヒックフローをどの程度多重すれば互いに悪影響を及ぼすか、または悪影響を及ぼすトラヒックフローをどの程度減らせばその影響を小さく抑えられるかなど、トラヒックフロー多重特性を明らかにするため、平成 16
年度は流体解析手法を用いたトラヒックフロー多重解析について検討し、解析プログ
ラムの開発を行った。さらに、トラヒックフローの多重方式の実証に向けて、ギガビ
ットの速度のトラヒックを対象にトラヒックフロー計測を実時間で行うシステムの開発を行った。
以下では、0 節に検討した解析モデルの概要を、0 節に分散型リアルタイムフロー
計測システムの概要を述べる。
3.2.2.2

解析モデル

コア網とエッジルータで構成されるネットワークにおいて、エッジルータのペアが同一の宛先のトラヒックフローを複数の通信パスへ分配し、コア網全体の利用効率の向上を図る状況を考える。同一の宛先に対して 2 つの通信パスを使い分けることができるエッジルータに、転送先が同じで異なるトラヒック特性を持つ 2 種類トラヒック- 130 -

が入力するとする ( 図 3.2.2 )。

図 3.2.2

2 つの通信パスへのトラヒックフローの配分

エッジルータではトラヒック特性を検知してトラヒックフローを通信パスへ配分し、トラヒックが通信パスへ入力するときの遅延変動を小さく抑えることを目標とする。
遅延変動の解析に統計的流体解析手法を用い遅延変動を小さくするトラヒックフローの配分の組合せを求める。
ルータに入力するトラヒックフローを on-off が交互に起こる流体ととらえ、トラヒ
ックフローのトラヒック特性を、on-off 期間の平均および on 期間の流量で表す。トラヒックが入力する各パスのキュー長を流体が入力する無限バッファの滞留量ととらえることで、[1]から滞留量の分布および平均を求める。平成 16 年度は本モデルの解析プログラムを開発した。
平成 17 年度は、実際にトラヒック多重の解析を行い、多様なトラヒック特性のトラ
ヒックフローから最適な組み合わせの方式を開発する。さらに、トラヒックフローの組み合わせが解析のとおりの結果を示すか実トラヒックを用いて実証する。

3.2.2.3

分散型リアルタイムフロー計測システムの開発

トラヒックフロー多重の実証を行うためは、トラヒックフローのトラヒック特性を計
測 す る 装 置 が 必 要 と な る 。 ト ラ ヒ ッ ク フ ロ ー の 計 測 ツ ー ル に は 、 Entremets [2],Application Traffic Monitor [3]などがあるが、ギガビットの速度で複数のトラヒッ
クフローを同時に計測できない。そのため、下記の機能を持つフロー計測装置の開発を行った。
実時間計測が可能- 131 -

マイクロ秒の解像度を有す
20 以上のトラヒックフローを同時に計測可能
ギガビットの速度のトラヒックをワイヤーレートで計測可能
動作中に計測フローの追加･変更･削除が可能
IP ヘッダからアプリケーションまでのフィールドのビットパターンを用いて柔軟にフローを定義可能
GPS に同期する計測装置は、柔軟なフロー定義を可能とするため、パケット解析処理を PC 上のソフ
トウェアで行い、ギガビットの速度に対応するため複数の PC による分散処理を行うこととした。システムへ入力するトラヒックはギガビットに達するため、入力するパケットを解析処理へ分散する処理をハードウェアで実現した。
開発したシステムは 84Kpps の性能を達成し、一方向のトラヒックを計測する場合は平均 128 バイト以上のパケット長を持つトラヒックであれば１Gbit/s の速度に対応でき、双方向同時計測の場合平均 256 バイト以上のパケット長を持つトラヒックであれ
ば２Gbit/s の速度に対応できることがわかった。
システムのタイムスタンプの誤差を把握するため、同じ 1000Base-TX 回線を流れる
トラヒックを二つのシステムを用いて計測し、同じパケットに振られるタイムスタン
プの差の頻度分布を求めた ( 図 3.2.3 )。誤差の最大が 8 マイクロ秒以下になることがわかった。

時刻差頻度分布 - 実測(修正後)、表5 0.18
0.16
0.14
0.12
0.1
k

0.08
0.06
0.04
0.02
0
-9

図 3.2.3

-8

-7

-6

-5

-4

-3

-2

-1 0
1
マイクロ秒

2

3

4

5

6

7

8

分散型リアルタイムフロー計測システムの時刻誤差の分布- 132 -

3.2.2.4

まとめ

トラヒックフロー多重の最適化を行うため、平成 16 年度は解析モデルの検討を行い、流体解析手法を用いることとした。そして、解析プログラムを開発して平成 17 年度から実際に開発を行う準備を行った。また、トラヒックフロー多重の最適化方式の実証を行うため、ギガビットの速度でトラヒックフローの特性を計測可能な分散型リアル
タイムフロー計測システムの開発を行った。
3.2.3

ネットワーク特性が分散計算アプリケーションの実行性能へ及ぼす影響の分析
3.2.3.1

概要

多様な分散アプリケーションが並行して実行される環境では、性能を十分に引き出すために求められるネットワーク資源はアプリケーション (またはその処理アルゴリズム) によって異なり、限られた資源の効率的な割り当てが課題となっている。デー
タ転送時間がアプリケーションの実行性能に無視できないほど大きい影響を与える場
合には、資源の割り当てによってネットワーク特性が変化するとアプリケーションの通信がその影響を受けて実行性能が劣化する恐れがあり、アプリケーションの実行性能を考慮したトラヒックエンジニアリングが有効と考えられる。
そこで、平成 16 年度は Grid 上でも動作可能な分散計算アプリケーションについて、
アプリケーショントラヒックがネットワークへ及ぼす影響と、ネットワーク資源がア
プリケーションの実行性能に及ぼす影響について調査を行った。具体的には、アプリ
ケーションのトラヒックパターンの解析と、通信パスの遅延時間およびボトルネック
回線の帯域に対するアプリケーションの実行性能 (計算完了時間) の変化の解析を行った。そして、通信の変化が実行特性に大きく影響するアプリケーションのトラヒッ
クを対象としたトラヒックエンジニアリングを行う際、アプリケーションの実行性能に着目することの有効性を示す。
なお、本節の報告の詳細は[4]を参照されたい。
3.2.3.2

分散計算アプリケーションの特徴

調査対象のアプリケーションは次の 3 つとした。
N クィーン問題
ジグゾーパズル [6]タスクスケジューリング [7]N クィーン問題およびジグゾーパズルの分散計算はタスクフレーム型に、タスクス
ケジューリングはワークフロー型に分類される[8]。タスクフレーム型は、まずマスタに該当する計算機が複数のスレーブとなる計算機へ処理に必要なデータを転送する。
スレーブはタスク毎に設定されている実験パラメータを用いて処理を実行し、処理結果をマスタへ転送する。通常、演算開始直後または終了直前に多量なデータ転送が発- 133 -

生する。ワークフロー型は、一連の処理を複数の段階に分けてパイプラインに処理する。各段階は 1 つあるいは複数のタスクで構成され、タスクの出力結果は次の段階を構成するタスクの入力データとして扱われる。通常、タスク間でデータ交換が行われ、演算処理の間に頻繁に入力データ・出力結果の転送が発生する。
3.2.3.3

実験環境

図 3.2.4 に 0 節および 0 節で述べる実験に用いたネットワーク構成を示す。前節で説明したアプリケーションは、PC1 から PC4 の計算機で実行する。PC1, 2 と PC3, 4を接続するギガビットイーサネットスイッチはネットワークエミュレータを介して接続される。ネットワークエミュレータでは、通過するパケットに遅延を挿入したり、
ボトルネック回線として帯域制限を行ったりする。機器は全てギガビットイーサネッ
トで接続されている。同一のスイッチに接続される PC 間の往復遅延時間 (RTT) の平均は 0.141 ミリ秒、エミュレータを介して接続される PC 間の RTT の平均は、遅延を挿入しない場合で、0.331 ミリ秒であった。
実験は各アプリケーションの起動を PC1 から行う。タスクフレーム型アプリケーシ
ョンでは、PC1 をマスタとし全ての計算機 (PC1 も含む) をスレーブとする。0 節に示す各アプリケーションのトラヒックパターン、フロー数、パケット間隔の解析には、
TCPDUMP を用いて取得した各計算機を出入りする全てのパケットデータを使用した。

図 3.2.4

実験環境- 134 -

3.2.3.4

分散計算アプリケーションのトラヒック特性

十分なネットワーク資源が得られる状態 (各回線の帯域は 1Gbit/s、RTT は 0.141
ミリ秒および 0.331 ミリ秒) で、各アプリケーションが転送するデータ量、トラヒッ
クパターンを調べた。全てのアプリケーションは、その通信に TCP のみを用いており、処理の間複数のコネクションが並行して確立されていた。
各アプリケーションの処理時間、PC3 における転送データ量および平均スループッ
ト (各値は 20 回の試験の平均) を表 3.2.1 に示す。全てのアプリケーションにおいて、問題の規模が大きくなると実行時間が増加し、転送データが増大している。また、転送データ量と実行時間の間の関係は、アプリケーションごとに異なる特徴を示している。
表 3.2.1
アプリケー
ション

N クィーン問題
15×15 マスN クィーン問題
16×16 マス
ジグゾーパズル
4 ピース
ジグゾーパズル
36 ピース

各アプリケーションのトラヒックの特徴

PC3 への入力方向

PC3 からの出力方向

実行

転送デー

平均スルー

転 送 デ 平均スルー

タ量 [MB]

プット

ー タ 量

プット

[Mbit/s][MB][Mbit/s]

時間
[秒]

0.926

0.878

39.2

37.2

40.78

4.07

1.45

210

75.4

191.330.07800.04430.117

0.0666

13.70

101

4.56

194

8.79

176.48

116

7.68

132

8.78

131.83

163

10.1

188

11.6

132.52

タスクスケジュー
リング 300 タス
ク
タスクスケジューリング 500 タス
ク

20 回の計測の一つについて、PC3 で送受されたトラヒックのスループット変化を図3.2.5 に示す。PC2 および PC4 においても同様の変化を示していた。また、各アプリ
ケーションで問題の規模を変えても変化のパターンは類似していた。

- 135 -

図 3.2.5

各アプリケーションのスループットの変化

図から、アプリケーション間でスループットのパターンは大きく異なっていることがわかる。N クィーン問題では、処理が終了する直前にスレーブからマスタ (PC3 から
PC1 の方向) へ非常に多くのデータが転送されていた。ジグゾーパズルでは、絶えず一定レートで小量のデータが交換されていた。タスクスケジューリングでは、間欠的に多量のデータが交換されていた。

3.2.3.5

ネットワーク特性がアプリケーションの実行特性へ及ぼす影響

A) 遅延の増大が実行性能へ及ぼす影響
RTT の増大が各アプリケーションの実行時間に及ぼす影響を調査した。図 3.2.4 のネットワークエミュレータにおいて、通過するすべてのパケットに片道 1 から 32 ミリ秒の遅延を挿入した。遅延の影響に注目するため、全ての回線の帯域は 1Gbit/s とした。N クィーン問題とジグゾーパズルでは TCP コネクションのソケットバッファの大きさを 16KB に設定し、タスクスケジューリングでは 64KB と 256KB の二つについて調査した。RTT の増大による実行時間 (各値は 20 回の試験の平均) の変化を図 3.2.6 に示す。実行時間は、遅延を挿入しない場合 (RTT は 0.331 ミリ秒) を 1 として正規化している。

- 136 -

図 3.2.6

通信パスの遅延に対する実行特性

全てのアプリケーションにおいて、RTT が増加するにつれて、実行性能が劣化する
ことがわかる。タスクスケジューリングでは、ソケットバッファが 256KB の場合に実行性能の劣化が低く抑えられている。このとき、各 TCP コネクションの送信ウィンド
ウの最大値が 64KB のときよりも大きくなることが確認された。タスクスケジューリン
グの様な多量なデータを頻繁に転送するアプリケーションでは、遅延に対して送信ウィンドウの拡大は効果的である。
N クィーン問題は RTT 増大の影響を受けて実行時間が劣化しているが、ジグゾーパ
ズルは劣化が小さいことが分かる。このような違いが起きる理由を明らかにするため、これら二つのアプリケーションで生成されるフロー(方向別の一つひとつの TCP コネ
クション)のパケット間隔の解析を行った (図は割愛する)。N クィーン問題の通信はRTT が大きくなると、それまで 70%以上あった 0.01 ミリ秒以下のパケット間隔が 60%に減少し、その分新しい RTT と等しい間隔の割合が増加したことわかった。つまり、バースト性の高い通信が RTT の影響でスループットの低下を招き、実行性能が劣化することがわかった。ジグゾーパズルの通信はでは、パケット間隔が RTT 以上の値を示
すパケットの割合が 50％以上あり、対話型の通信の頻度が多かった。次に割合が多い(40％) 0.01 秒以下のパケット間隔は RTT が増大してもその割合が変化 (減少) しな
かったことから、一度に送信されるデータが送信ウィンドウサイズよりも少なく、遅延の増大で送信待ちになるパケットの数が増大しないと考えられる。つまり、対話型の通信が、RTT の増加に対して、必ずしもその影響を受けて実行性能が劣化するとは限らないことがわかった。

- 137 -

多様なアプリケーションが並行して実行される環境で、アプリケーションのトラヒ
ックを異なる RTT の通信パスの一つに通すような状況では、このような RTT に対する
アプリケーションの実行特性の情報は有効と考えられる。
B) ボトルネック回線の帯域が実行性能に及ぼす影響
図 3.2.4 のネットワークエミュレータにおいて帯域を 80Kbit/s から 1Gbit/s に絞り、ボトルネック回線の帯域が各アプリケーションの実行時間に及ぼす影響を調査した。
ボトルネック回線の帯域を 1Gbit/s から縮小させたときの実行時間の変化 (各値は20 回の試験の平均) を図 3.2.7 に示す。ボトルネック回線の帯域が 1Gbit/s のときの実行時間を 1 として正規化を行っている。ボトルネックの影響に注目するため、遅延は挿入しなかった。ソケットバッファは、N クィーン問題とジグゾーパズルでは 16KBに、タスクスケジューリングでは 256KB に設定した。

図 3.2.7

ボトルネック回線の帯域に対する実行特性

実行時間がある値 (例えば、1.1) に達するまでは、ボトルネック回線の帯域の縮小に対する実行時間の増大は緩やかなことがわかる。このような実行時間への影響が小さいボトルネック回線の帯域はアプリケーションによって異なる。さらにボトルネッ
ク回線の帯域を縮小すると、実行時間がある値 (例えば、1.3 倍) を越えてからは、
実行時間の増大が急激になることがわかる。また、実行時間が急激に劣化し始めるボ
トルネック回線の帯域の大きさの順 (N クィーン問題 > タスクスケジューリング >ジグゾーパズル) は、表 3.2.1 で示した平均スループットの大小の順と一致し、アプ
リケーショントラヒックの平均スループットと大きく関係すると考えられる。

- 138 -

このようなボトルネックの制約に対するアプリケーションの実行特性の情報は、多様なアプリケーションが並行して実行されるネットワークにおいて、アプリケーショ
ンのトラヒックにどれくらいの帯域を割り当てるか判断する場合に有効と考えられる。
3.2.3.6

まとめ

通信の変化が実行性能に大きく影響するアプリケーションのトラヒックを対象としたトラヒックエンジニアリングを行う際、アプリケーションの実行性能に着目することの有効性を検証するため、分散計算アプリケーションのトラヒックがネットワーク
資源の状態に与える影響と、逆にネットワーク資源の状態がアプリケーションの実行性能に与える影響を調査した。そして、ネットワーク特性とアプリケーションの実行
性能の関係を予め明らかにしてアプリケーションの実行性能に着目したトラヒックエ
ンジニアリングが効果的なことを示した。
3.2.4
3.2.4.1

高精度タイムスタンプによるトラヒック計測の有効性の検証
概要アクティブ計測およびパッシブ計測では，1 点もしくは複数点においてパケットの通過時刻を記録するタイムスタンプが必要になるが，ネットワークの高速化に伴い，従来の低精度なタイムスタンプではネットワークの正しい計測ができなくなり，より高精度なタイムスタンプが開発されるようになってきた。本研究課題では、300ナノ秒の誤差でGlobal Positioning System (GPS) へ同期し100ナノ秒の解像度をもつタイム
スタンプシステムを用いて取得されたデータの解析を行い、高精度タイムスタンプでなければ得られないトラヒック特性を示し、高精度なタイムスタンプの有効性を実証する。
なお、本節の報告の詳細は[5]を参照されたい。
3.2.4.2

実験の概要

JGNv6 ネットワークの北九州ギガビットリサーチセンター(計測地点 1)および大手町 IPv6 システム運用技術開発センター(計測地点 2)にあるルータ接続拠点に高精度タ
イムスタンプシステム (HIM) [9]を設置し、JGNv6 ネットワークを通過する試験パケ
ットを高精度タイムスタンプ付きで取得した。実験ネットワークは様々な速度の回線(100Base-TX, 1000Base-SX, OC-3/ATM, OC12-ATM) で接続されている。計測地点 HIMの他に TCPDUMP を用いてパケットを取得し、タイムスタンプの精度の比較を行った。
TCPDUMP では Pentium III クラスの CPU を搭載する高性能 PC (FreeBSD) を用いても100 マイクロ秒以上の誤差が発生し、数百 M ビットの高速回線の計測には向かないことがわかった。
計測環境は、JGN2 上に構築された JGN2v6 ネットワーク移行後も利用し、より高速なネットワークでのデータ収集を継続して行っている。
実験は次の 3 つの計測を行った。

- 139 -

様々なパケット長の ICMP/UDP パケットの片道遅延
TCP フローのパケット間時刻差
DVTS トラヒックのパケット間隔時刻差
3.2.4.3

実験結果A) 様々なパケット長の片道遅延
計測地点 1 を ICMP パケット (Echo) および UDP パケットの送信元とし、先ず、片道
キュー遅延について実験を行った。表 3.2.2 に片道キュー遅延の平均、標準偏差、99
パーセンタイル値を示す。ICMP Echo に対しては Echo Reply を得られるため、計測地
点2を送信元とする片道遅延の計測も行った。ICMP パケットは 10pps の速度で 1000

秒間送出し、UDP パケットは、100 バイトペイロードを１Mbit/s の速度で、他のペイロードサイズを 100Kbit/s の速度で同じく 1000 秒間送出した。片道キュー遅延は各パケット長について片道遅延と最小片道遅延の差とした。
表 3.2.2
ICMP Echo/UDP パケットの片道キュー遅延の平均、標準偏差、99 パーセンタイル値
パケット長

ビット速度

平均

標準偏差

99 パーセンタイル値

プロトコル

パケット速度

[ミリ秒]

[ミリ秒]

[ミリ秒]

148 バイト1050Kbit/s

UDP

1300pps

148 バイト

12Kbit/s

ICMP
548 バイトUDP
548 バイトICMP
948 バイトUDP
948 バイト
ICMP
1448 バイト
UDP
1448 バイト
ICMP

10pps
107Kbit/s
27pps
44Kbit/s
10pps
106Kbit/s
15pps
76Kbit/s
10pps
104Kbit/s
9116Kbit/s
10pps

0.03620.04320.239

0.03500.03860.140

0.05460.07430.410

0.05800.08820.478

0.06220.08450.433

0.0857

0.114

0.498

0.06640.08920.436

0.0860

0.111

0.494

これらの結果から、片道キュー遅延はパケットのプロトコルタイプ、パケット長に- 140 -

よって大きく異なることがわかる。たとえば、パケットサイズに着目すると、UDP では 148 バイトパケットと他のパケット長の間でビットレートが 10 倍異なるにもかかわらず、パケット長に従って遅延時間が増大する。プロトコルタイプに着目すると、148バイト長ではパケット速度が 100 倍以上違うにもかかわらず平均遅延はほぼ等しい。
しかし、548 バイト長以上のパケット長のときには、パケット長が大きくなるにした
がって ICMP と UDP の間で平均遅延が大きくなっている。
次に、様々なパケットサイズの最小片道遅延を図 3.2.8 に示す。各サイズの最小片
道遅延の値を結んで得られる直線の y 軸切片から伝搬遅延 (パケット長に無関係) を、
同直線の傾きから通信パス中の各回線の帯域の逆数の和をそれぞれ推定できる。さらに、全てのパケット長において、ICMP Echo/UDP パケットと ICMP Echo Reply パケッ
トの間で最小遅延時間が 0.06 ミリ秒分異なることがわかる。実験中は試験パケットが通信パスの各方向のルータを逆順に通過していたため、データリンク層または物理層において非対称な経路が存在することが予想される。
TCPDUMP では図のようなまっすぐな直線を得ることはできず、図 3.2.8 は HIM のよ
うな高精度タイムスタンプの有効性を示していると言える。このような高精度タイム
スタンプを用いればパス中で明らかになっていないストアアンドフォワード型装置の検出なども可能と考えられる。

図 3.2.8

最小片道遅延- 141 -B) 双方向 TCP ストリームのパケット間時刻差
TCP トラヒックのデータパケットと ACK パケットについて、各方向の送信元ホスト
および受信ホストでパケット間時刻差を求め、その比較を行った。データパケットのほとんどはパケットサイズが 1488 バイトで、全ての ACK パケットは 60 バイトであった。図 3.2.9 に送信元ホストおよび受信ホストで得られたパケット間時刻差の累積分布を示す。

図 3.2.9

TCP データパケットのパケット間時刻差の累積分布

送信元ホストでは 0.12 ミリ秒のパケット間隔(転送速度: 99 Mbit/s = 1488 バイト/0.12 ミリ秒)が全体の 60％以上を占め、第 2 の主要なパケット間時刻が 0.2 ミリ秒(転送速度: 60Mbit/s)であった。少なくとも、これら二つの主要なパケット間隔は TCP
データトラヒックのバースト性を示しているといえる。

- 142 -

図 3.2.10

ACK パケットのパケット間時刻差の累積分布

TCP の ACK パケットのパケット間隔の累積分布を図 3.2.10 に示す。ACK パケットの送信元での主要な間隔は 0.2, 0.4, 0.6, 0.8 となっていた。図 3.2.9 では TCP デー
タパケットの受信ホストでのパケット間時刻差は 0.12 ミリ秒が最も多かったため、データパケットの受信ホスト内部で 0.2 秒間隔に受信パケットが保持され、そのような間隔空いたデータパケットの到着に対して、0、1、2、3 パケットおきに ACK パケットが送信された可能性が考えられる。また、ACK パケットを受信するホストでは、0.01
ミリ秒以下の大変短いパケット間隔が 5％以上観測された。このような短いパケット
間隔は ACK Compression を示しており、その程度を表していると言える。
このような高精度のパケット間隔の分布は TCPDUMP では得られなかったことから、高精度タイムスタンプがネットワークを通過するトラヒックの特性変化の検出に有効であることがわかる。
C) DVTS ストリームのパケット間時刻差
DV ストリームの送受信ホストでのパケット間時刻差の累積分布を図 3.2.11 に示す。送信元ホストでのパケット間隔は、多い順に、0.37 ミリ秒(29Mbit/s)、0.25 ミリ秒(43Mbit/s)、0.5 ミリ秒(22Mbit/s)の 3 種類が主に観測された。また、少量ではあるが、98Mbit/s に対応するパケット間隔 (0.1 ミリ秒) も観測さえた。これらの値は、高速なストリームを送信するアプリケーションを用いるためのネットワークへの要求
条件と言え、ネットワーク資源の確保に有効な情報である。

- 143 -

図 3.2.11

3.2.4.4

DVTS ストリームのパケット間時刻差まとめ

本研究課題では、100 ナノ秒の精度をもち GPS に対して 300 ナノ秒以下の誤差でタ
イムスタンプを取得できる HIM を用いて取得したトラヒックデータの解析を行い、高速回線でのネットワーク特性計測に高精度タイムスタンプが不可欠なことを示した。
試験パケットを用いた片道遅延の計測とでは片道キュー遅延の推定では最小片道遅延比例がパケット長に比例し、伝搬遅延の推定とストアアンドフォワード装置の検出が可能なことを示唆した。また、片道キュー遅延の分布がパケットサイズおよびプロ
トコルタイプ (ICMP/UDP) によって異なることを示した。TCP ストリームのパケット
間時刻差の計測では、データトラヒックが最大 99Mbit/s のバーストトラヒックを発生させていたこと、ACK パケットの受信では ACK Compression が実際に起こっていたことを示した。UDP ストリームのパケット間時刻差では、送信ホストでの主要なパケッ
ト間隔から 3 つの主要なストリーム送信レートを明らかにし、ネットワークが UDP ス
トリームアプリケーションの通信品質を保証するためにはこのような情報が有効であることを示した。
TCPDUMP ではこのような結果を得ることができなかったことから、高速回線でのネットワーク計測では高精度なタイムスタンプシステムが必要不可欠である。

- 144 -

参考文献
1. V. Ramaswani, “Matrix analytic methods for stochastic fluid flows,”
Proceedings of ITC 16, pp.1019-1030, Elsevier, Amsterdam (1999).
2. NeTraMet, http://www2.auckland.ac.nz/net/NeTraMet/
3. MD1230A-20, MX123001A-20, “Application traffic monitor,” Anritsu
Corporation, http://www.anritsu.com/
4. Y. Kitatsuji, S. Katsuno, K. Yamazaki, H. Koide, M. Tsuru

and Y. Oie, “On

the Influence of Network Characteristics on Application Performance in the
Grid Environment,” Proc. of the 4th ICN (2005) 9-18
5. Y. Kitatsuji, T. Masato, S. Katsuno and Y. Oie,“Usefulness of precise timestamping for exposing network characteristics on high-speed links,” Proc.
of the SPIE OpticEast Vol. 5598 ITCom (2004) 163-170
6. ICPC Asia Regional Contest, Japan Hakodate. http://www.fun.ac.jp/icpc/
7. Kasahara Laoratory, Waseda University.
http://www.kasahara.elec.waseda.ac.jp/schedule
8. H. Koide, and Y. Oie, “A New Task Scheduling Method for Distributed Programs
which Require Memory Management in Grids,” Proc. of Proposed SAINT2004
Workshop 8: High Performance Grid Computing and Networking, Tokyo (2004)
666 673
9. S. Katsuno, K. Sugauchi, O. Tsunehiro, K. Yamazaki, K. Yoshida and H. Esaki,“Asymmetric Characteristics of Internet based on Traffic Measurement andAnalysis,” IEICE Trans. Inf. Syst. E86-D (2003)
10. K. Kobayashi and A. Ogawa and S. Casner and C. Bormann, “RTP Payload Format
for DV (IEC 61834) Video,” Network Working Group, RFC3189 (2002)
11. http://dast.nlanr.net/Projects/Iperf/- 145 -

3.3

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

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

アクセスポイント選択手法

携帯型端末の技術発展とどこでもインターネットに接続したいという要求から，
IEEE802.11b を代表とする無線 LAN の需要が高まっている．すでに，家庭およびオフ
ィス内 LAN の無線化や，駅構内やホテル，展示会場などからインターネットへ接続できるようにする公衆無線 LAN アクセスサービスが始まっており，市場は無線 LAN を次世代インフラとして期待している．無線 LAN の利用形態には，各無線ステーション（STA,
Station)が直接通信 し 合うアドホ ックモー ド と，無線 LAN アクセス ポイント（AP,Access Point）を介した通信を行うインフラストラクチャーモードがある．現在，主- 146 -

にインフラストラクチャーモードが利用されている．この場合，AP に接続する STA 数が増加するに伴って，STA1 台当たりのスループットが大きく低下する．よって今後の需要の拡大により，収容すべき STA 数が増加した場合には，無線 LAN 網内に複数の APを設置する必要がある．
AP が複数存在する無線 LAN 網において，各 STA が無線状況のみを指標として接続先のAP を選択すると，AP 間の接続 STA 数が偏り，無線帯域を有効かつ公平に利用できなくなる．現在の無線 LAN 製品には負荷分散機能を有するものがあるが，これらの製品はベンダー独自の負荷分散ポリシーにより AP 側で STA を再分配するもので，異なるベン
ダーの機器間に互換性が無いほか，非常に高価なものとなっている．
そこで本サブテーマでは，無線 LAN 網から得られる様々な情報をもとに，STA が自律的に AP を選択するアルゴリズムを提案し，シミュレーション評価により本手法は従来方式に比べスループット性能が約 50％改善することを明らかにし，その成果を国際会
議にて発表した[1]．また，既存方式と混在する場合の浸透性や AP の故障などにより
無線 LAN 内の状況が大きく変化した場合の強靱性を評価し，本手法が実際の運用に耐えうる実用性を備えていることを明らかにし，その成果を IEEE 主催の国際会議にて発表した[2]．さらに，幾つかの性能指標に対する最適解を求め，本手法が自律分散型にもかかわらず無線 LAN 全体の資源を効率よく利用できることを示し，その成果をネッ
トワークシステム研究会にて発表した[3]．また，無線 LAN に接続する STA が下り方向
中心のトラヒックを発生する従来のクライアント・サーバ型通信だけでなく，上り方
向にも多くのトラヒックが発生する P2P 型通信も行う場合について，無線 LAN の MAC機構に着目した利用効率向上のための機構を提案し，その有効性をシミュレーションにより明らかにした．その成果を情報通信学会論文誌にて公表予定である[4]．
3.3.1.1

AP 選択アルゴリズム機構

AP が複数存在する無線 LAN 網においては，STA が接続する AP を適切に選択することが非常に重要である．例えば，STA が AP 間との無線状況のみを指標として接続する
AP を選択すると，AP 間の接続 STA 数が偏り，無線リソースを有効かつ公平に利用できなく な る ．こ の 問題 を 解決 す る ため に AP ご とに 異 なる ESSID（Extended Service
Set-Identifier）を設定し，静的に接続 STA 数を分配する方法があるが，これは STA
が AP 間をローミングできなくなり，無線状況が悪くても同じ AP と接続し続けることになる．
上記問題点を解決するために，複数の AP が存在する無線 LAN 網において，STA が接続する AP を自律的に選択する機構を提案した．具体的には，1)自 STA が最も高いスルー
プットを期待できる AP を最適と判断する throughput-oriented 機構と，2)他 STA に与える影響を考慮しながら AP を選択する fairness-oriented 機構の 2 種類を提案した．
両提案機構は STA が無線 LAN 網に参加する際と，AP と接続中において定期的に実行さ- 147 -

れる．
1) throughput-oriented 機構
throughput-oriented 機構では，自 STA が最も高いスループットを期待できる AP を最適とする.そのため事前に全 AP に対してスループットを予測しなければならない．ここで，AP に N 台の STA が接続し，データサイズが Data [bit]のパケットが送受信されるのに要する時間を t T [s]，STA と AP 間の Packet Error Rate（PER）を P とし，パケットの衝突が発生しないと仮定した場合，スループット

はData (1 P )tT Nとなる．このうち STA がどの AP を選択したとしても t T および Data は同じであるため，

Wth

1 P
N

で表される重み関数

Wthの値が最も高くなる AP が STA にとって最適となる．

IEEE802.11b の場合，フレーム中に 1bit でもエラーがあると再送処理が行われるので，
Bit Error Rate（BER）を Pe とした時， P

1 (1 Pe) PacketSize で表される．この BER

は受信電力によって求めることができるので，AP から送信される Probe Response お
よび Beacon フレームに接続 STA 数情報を追加することで，STA は PER と接続 STA 数を得ることができる．
2) fairness-oriented 機構
fairness-oriented 機構では，STA は他の STA の通信状況を考慮して最適な AP を選択する．ここでは，無線 LAN 網内において通信状況が最も悪い STA（最悪 STA）に着目し，この特性が更に劣化することを防ぐ．すなわち STA は最悪 STA が接続している AP をなるべく選択しないようになる．この機構の重み関数を0 1 Pmax
W fair

0 .5

の場合，

1
2(1 Pmax )2

0 .5

0.5 1 Pmax

1

Wth
，

の場合，

- 148 -

W fairWthと定義する．ただし，

Pmaxは計算対象の AP に接続している STA のうちの最大 P 値とする．

P

上式は， max が 1 に近いほどとを意味する．また，

Pmax

W fairは小さくなり，STA がその AP と接続しにくくなるこ

が 0.5 よりも小さいときは，最悪 STA を過度に保護するあまり，自 STA にとって条件の悪い AP を選択することのないように，fairness-oriented
機構を適用しないことを意図している．
この機構を実装するためには，PER，接続 STA 数に加えて，

Pmax（最悪 STA の PER）が必要となるので，AP から送信される Probe Response および Beacon フレームにはこの情報も付加する必要がある．
STA が提案 AP 選択機構を無線 LAN 網参加時でしか行わない場合，その後の環境の変化
により，STA にとって最適な AP は変化している可能性がある．このため，接続中においても AP 選択機構を定期的に実行する必要がある．本研究ではこの機構をリンク
監視機構と呼ぶ．

図 3.3.1

リンク監視機構における状態遷移図

図 3.3.1 に示すように，リンク監視機構において STA はサーチ状態，リサーチ状態，
アイドル状態の計 3 つの状態を遷移する．サーチ状態とは，STA が Search Interval（SI）間隔で全 AP に対して重み関数を計算する状態である．この状態において最適
AP が変化してもローミングは行わない．リサーチ状態とは，サーチ状態において最適
AP が変わった時の遷移先の状態で，この状態で最適 AP が変わったならば，STA はロー
ミングを実行する．アイドル状態とはローミングを行った直後の STA の状態であり，この時の STA はどの AP に対しても重み関数の計算を行わない．以下に STA がローミン- 149 -

グするまでの状態遷移を図 3.3.1 と対応させて説明する．
(1)

Search Interval（SI）間隔で全 AP に対する重み関数を計算する．

(2)

接続中の AP-1 よりも AP-2 の重み関数の値が上回った場合，Backoff Time（BT)
時間後に再び全 AP に対して重み関数を計算するバックオフアルゴリズムに入る．
このバックオフアルゴリズムを終えた STA はリサーチ状態に入る．

(3)

再計算の結果，AP-2 への重み関数の値が最大となれば，ローミングを実行する．

(4)

再計算の結果，AP-1 への重み関数の値が最大となれば，サーチ状態に戻る．

(5)

再計算の結果，新たな AP-3 への重み関数の値が最大となれば，再びバックオフ
アルゴリズムに入る．

(6)

ローミン グを 実行 した STA は Idle Time(IT)時間待 った 後，サ ーチ状 態に 戻り，AP サーチを行う．

3.3.1.2

性能評価

まず，本提案 AP 選択機構を評価するためのシミュレーションモデルおよび評価指標について説明する．シミュレータとしては NS-2.1b9a を用いた．また，見通し外通信による影響を考慮し，無線区間のエラーモデルには shadowing モデルを採用した．
そのネットワーク構成を図 3.3.2 に示し，設定パラメータを表 3.3.1 に示す．また，
AP 間で干渉することが無いようにチャネルを設定し，合計 4 台の AP を図 3.3.3 に示すように配置した．

- 150 -

図 3.3.2

表 3.3.1

シミュレーションモデル

シミュレーションパラメータ

パラメータ

値

トラヒックタイプ

TCP/Sack

パケットサイズ

1500 Bytes

フローの向きAP → STA

通信速度

11 Mb/s fixed- 151 -

図 3.3.3

AP の配置図

はじめ 40 台の STA を 10 秒間で任意に配置させ，定常状態になってから 3 分後にさらに 10 台の STA を追加した．STA は常に TCP 通信を行い，配置後は位置を移動しないものとする．また STA が配置されるエリアを 3 種類用意した．図 3.3.3 に示すように，
Area-1 は 50m 50m 内を表し，STA はこのエリア内に均等に配置されることになる．
Area-2，Area-3 においても同様に STA は均等に配置されるが，エリアの広さがそれぞれ，40m 40m，30m 30m となる．Area-1 では各 AP の周りに均等に STA が配置される
が，Area-2 では AP-3，4 の周りに配置される STA が少なくなる．Area-3 になるとその効果はより顕著になる．以上を理由に，Area-1 に STA が配置される環境を偏りレベル
1 とし，Area-2 ではレベル 2，Area-3 ではレベル 3 と設定する．偏りレベルが高いほど，AP 周りの STA 数の偏りが大きくなる．AP 選択機構には，1) throughput-oriented機構，2) fairness-oriented 機構に加え，単に無線状況の最も良好な AP を選択する
3) radio-condition-oriented（radio-oriented）機構を用いた．
提案方式の有効性は，無線 LAN 網内の総スループット，全 STA 中の最小および最大ス
ループット，全 STA の平均スループット分布に加え，STA 間の公平性を示す指標として，balance index を用いて評価を行った．balance index とは次式で表される値であり，1 に近いほど均衡を表し，不均衡になればなるほど 1 / N に近づく．

Bi

2

N

Bi2

．

- 152 -

の

ただし

Bi

は

STA i

の平均スループット， N は STA 数を表す．またリンク監視機構においては，BT=[0,1)秒および IT=3 秒に固定し，SI を 0.1～5 秒まで 0.1 秒刻みで変化させ，安定するまでに要するローミング回数と時間を評価した．
以上のシミュレーションモデルを用いて得られた代表的な結果として，既存機構と提案機構の最小スループットおよび総スループット特性を表 3.3.2 にまとめる．
表 3.3.2

スループット特性

最小スループット

総スループット

既 存 機 構提 案 機 構既 存 機 構提 案 機 構[Kb/s][Kb/s][Mb/s][Mb/s][50m × 50m]

271.47327.66

17.59

17.50

[40m × 40m]

206.52308.99

17.38

17.10

[30m × 30m]

154.73271.50

13.07

15.05

ホスト配置

この表から提案機構はホスト配置の偏り度合いに関係なく最小スループット特性が大きく改善されることがわかる．また，ホスト配置の偏りが大きい場合には総スループ
ット特性が改善されることがわかる．すなわち，本機構は STA 間の公平性を大きく改善し，特にホストが偏って配置される場合には無線 LAN 全体の利用効率を改善することを示した．
3.3.2

トランスポートプロトコルによる通信品質制御手法

エンドツーエンド通信の品質は，実際にエンドホスト間でフロー制御や輻輳制御を行うトランスポートプロトコルによる影響が大きく，その性能が重要となる．また，
アプリケーションの多様化に伴い，アクセス網を通過するトラヒックの特性も多様化してきており，従来の非実時間通信用トランスポートプロトコルである TCP や実時間
通信用の UDP だけではなく，新しい輻輳制御機能を持った実時間通信用トランスポー
トプロトコルとして Datagram Congestion Control Protocol（DCCP）が提案されている．そのような複数のトラヒックが混在するような場合には，特に通信品質の制御が重要となる．例えば，通信帯域の保証や，公平な利用帯域の割り当てなどがあるが，従来はこのような制御はほとんどの場合ネットワーク内部のルータなどで実現していた．しかし，近年のフロー数の増大や，要求品質の多様化により困難さが増加してきており，ネットワーク内部ではなくトランスポートプロトコルによってエンドツーエ
ンドで品質制御を行う手法が検討されてきている．
そこで，本サブテーマでは，実時間通信と非実時間通信が混在する環境において，
トランスポートプロトコルによる通信品質制御手法を検討し，従来方式よりも実装・- 153 -

運用コストが低い受信者制御型トランスポートフロー制御手法を提案し，シミュレー
ションにより従来方式と同程度の性能が得られることを示し，その成果を IFIP 主催の国際会議にて発表した[5]．さらに，新しい実時間通信向けプロトコルである DCCP フローと非実時間通信向けプロトコルである TCP フローが混在する場合のフロー間公平性に関する特性および問題点をシミュレーションにより明らかにし，その成果をIEEE/IPSJ 主催の国際会議にて発表した[6]．また，拠点間 1 対 1 ではなくある拠点から他のすべての拠点に対して契約を行う VPN ホースモデルにおいて，拠点間の最低帯
域保証を実現するための動的なフィードバック型帯域割り当て方式を提案し，その有効性をシミュレーションにより明らかにし，その成果を情報ネットワーク研究会にて発表した[7]．
3.3.2.1

受信制御型フロー制御機構

携帯電話などの移動体通信端末が広く普及し，その無線技術の発達とともに，移動体通信網からインターネットを利用した電子メールや World Wide Web（WWW）閲覧な
どのデータ通信サービスに対する期待が高まってきている．そこで，次世代移動体通信システムとして，従来の携帯電話網よりも高速なデータ通信や国際ローミングをサポートするために，International Mobile Telecommunications-2000（IMT-2000）の標準化が International Telecommunication Union（ITU）によって進められている．
そ の IMT-2000 で 用 い ら れ る 通 信 方 式 の 1 つ と し て ， Wideband-Code Division
Multiple Access（W-CDMA）が 3rd Generation Partnership Project（3GPP）により規定されている．W-CDMA では，最大 384Kb/s（屋外移動時）の伝送速度が提供される．
通信媒体として無線リンクを利用する場合，従来のインターネット技術を利用するには大きな問題がある．有線環境では，伝送リンクは比較的広帯域・低遅延であり，データの伝送誤りはほとんど発生せず，ネットワークの輻輳によりパケットロスが発生する．一方，無線環境では，電波の干渉等の影響により伝送誤りが発生し，その結果
パケットロスを生じることになる．そこで，W-CDMA では，無線リンクにおいて誤り訂
正符号を用い，回復できなかったパケットは再送制御を行うことによってパケットの伝送誤りを回復している．特に，音声や動画のストリーミングなどの実時間通信の場
合，非実時間通信とは異なった特性が要求される．非実時間通信で用いられる TCP は，
データ伝送の信頼性や効率性を重要視するため，利用可能なリンク帯域を最大限利用するためのフロー制御を行い，またパケットが正しく受信者に届けられなかったと判断した場合には再送制御による誤り回復を行う．一方，実時間通信は非実時間通信に比べ伝送データの欠落には比較的寛容であり，それよりも伝送遅延時間やジッタ（伝送データの到着間隔のゆらぎ）を重要視する．そのため，一般に実時間通信は，再送制御を行わない UDP を利用した Constant Bit Rate（CBR）通信を用いる．有線環境においては，この要求特性が異なる通信である TCP トラヒックと UDP トラヒックが混在- 154 -

する場合の相互に与えあう影響については多くの研究が行われてきている．例えば，
TCP トラヒックが UDP トラヒックに対して悪影響を及ぼすことが報告されている．そのため，実時間通信の品質を保証するための Quality of Service（QoS）制御機構が提案され，これまで多くの研究がなされてきている．また，無線環境を考慮した QoS制御機構に関する研究も行われているが，IMT-2000 環境における QoS 制御機構に関しては，十分に調査が行われていない．そこで本研究では，非実時間通信と実時間通信が混在する W-CDMA 環境において，実時間通信の品質を向上させ，かつ非実時間通信に対する悪影響を抑えるための QoS 制御機構を提案した．
本機構の有効性を検証するために，特に UDP トラヒックのパケットロス率や遅延時間
特性，および TCP トラヒックのスループット特性に着目したシミュレーション実験を行った．ここではその中から代表的な結果として，UDP トラヒックのパケットロス特性および TCP トラヒックの平均スループット特性を表 3.3.3，3.3.4 にまとめる．
表 3.3.3

UDP のパケットロス特性 [%]UDP レート [Kb/s]

QoS 制御なし

提案機構

32

17.86

0.56

64

6.73

0.36

128

5.74

0.49

表 3.3.4

TCP の平均スループット特性 [Kb/s]

UDP レート [Kb/s]

QoS 制御なし

提案機構

32

277.53273.9864

241.89238.74128

185.18190.29これらの表から提案機構は UDP のパケットロス率を 1％以下と十分に小さく抑えることができ，良好な実時間通信の品質を提供できることがわかる．さらに，本機構は TCPのスループット特性にほとんど悪影響を与えないことがわかる．
3.3.2.2

実時間通信のための輻輳制御機構

テレビ会議やストリーミングビデオ・オーディオおよびオンラインゲームなど，遅延に敏感で実時間性の求められるアプリケーションが一般化し，それらのトラフィッ
ク量が増加している．これらのアプリケーションは一般に，トランスポート層プロト
コルとして UDP を用いている．しかし UDP はそのシンプルな設計により輻輳制御を行っていないため，アプリケーションレベルでその機能を実装するか，あるいは実装していない．輻輳制御されていないトラフィックが急激に増加すると，やがて輻輳制御- 155 -

機構をもつ TCP などのトラフィックまで阻害し，ネットワークは不安定な状態に陥ってしまう．過去にもバックボーンネットワークにおいて輻輳崩壊と呼ばれる問題が発生しており，今後リアルタイムアプリケーションのような新しいタイプのトラフィッ
クにより同じ問題が発生するおそれがある．よって輻輳制御を行うことは，今後ネッ
トワークにおいて最低限必要とされるべき機能である．これに基づき，UDP より上層のアプリケーションレベルで輻輳制御機構をもつプロトコルが設計されている．既に
アプリケーションに実装され，主にストリーミングに用いられているのが，Real-time
Transport Protocol（RTP），RTP Control Protocol（RTCP）である．RTP は，制御用のプロトコル RTCP を使って実効帯域幅や遅延時間などをサーバに報告し，サーバはその通信状態に合わせたレートでデータを送信する．また，エンドツーエンドでのリア
ルタイムストリーミング再生に適した Rate Adaptation Protocol（RAP）では，TCP と同様の Additive Increase Multiple Decrease（AIMD）アルゴリズムを使って，TCP
フローと親和性の高い通信を可能としている．さらに，Rate Control Scheme（RCS）
は UDP/RTP 上で動き，ダミーパケットを送信することでネットワークの混雑具合を判断し送信レートを適切に変動する仕組みを提供している．しかし，これらのプロトコ
ルには共通している問題点がある．それは，いずれもトランスポート層で UDP を用い，さらに上のアプリケーションで輻輳制御を行っていることである．言い換えると，ア
プリケーション側で帯域制御ができてしまうため，容易にネットワークの秩序が乱される危険性が高い．そこで，トランスポート層でエンドツーエンドの輻輳制御を行う
新しいプロトコル，Datagram Congestion Control Protocol（DCCP）が提案された．
このプロトコルの特徴は，トランスポート層プロトコルに最低限必要な機能 輻輳制御
機構だけを組み込んだシンプルな設計であることである．また，DCCP の新しい機能として，Congestion Control ID（CCID）と呼ばれる値を通信開始時にネゴシエーションを行うことによる，輻輳制御アルゴリズムの選択機能がある．将来的に UDP に代わる次世代トランスポート層プロトコルとして期待されている．しかし，現時点で DCCPの性能に関して評価がされておらず，このままでは利用できるかどうかの判断ができない．そこで本研究では，DCCP の基礎特性のうち，既存のトランスポート層プロトコ
ルに与える影響をシミュレーションにより評価・検討した．
特に実時間通信向け DCCP フローと非実時間通信向け TCP フローが混在する場合のフロー間公平性を評価するために，両プロトコルのスループット特性に着目したシミュレーション実験を行った．ここではその中から代表的な結果として，TCP と DCCP が混在する場合の平均スループット特性を表 3.3.5 に示し，ネットワーク規模が変化する場
合の平均スループット特性を図 3.3.4 に示す．

- 156 -

表 3.3.5

Reno

NewrenoSack

TCP フローと DCCP フローの平均スループット特性
TCP

DCCP

Total

TCP first

4.73

4.66

9.37

DCCP first

3.75

5.76

9.54

TCP first

4.84

4.50

9.30

DCCP first

4.10

5.28

9.38

TCP first

4.42

4.96

9.38

DCCP first

3.69

5.97

9.66

図 3.3.4

リンク遅延に対するスループット特性

これらの結果から，TCP フローが DCCP フローよりも先に流入する場合には，両プロト
コルは公平に帯域を利用することができるが，DCCP フローが先に流入する場合やネッ
トワークの規模によっては公平性が悪くなることがわかる．さらに，この原因が TCPの Fast Recovery アルゴリズムと DCCP のフロー制御間の不整合によって生じることを明らかにしている．

3.3.2.3

VPN ホース動的帯域割り当て手法

複数の拠点を持つ組織が組織内部での情報ネットワークを構築するために，安価に仮想的な専用線を実現する Virtual Private Network（VPN）が注目されている．現在
は先進的な組織のみが組織内部に VPN ルータを設置する事で組織内情報網を構築しているが，規模が大きくなるにつれて管理や設定が困難となる．今後はほぼ全ての組織
が VPN 専用プロバイダによるサービスを用いて，今より容易に VPN による組織内情報- 157 -

網を構築するであろうと考える．ベストエフォート型である通常のインターネットでは品質の保証はされず，専用線と同等の品質が求められる VPN ではサービス品質保証制度（SLA）に基づいて契約を行う．VPN では SLA を満たすために帯域や遅延時間といったサービス品質（Quality of Service, QoS）の保証を提供する事が重要となる．QoSには帯域や遅延時間など様々な指標があるが，TCP によるデータ通信では帯域が一番重要なネットワーク資源であるため，本研究においては最低帯域保証について着目する．最低帯域保証を実現するために，ある拠点間であらかじめ保証する最低帯域を他の拠点が使用出来ないように割り当てる手法も存在するが，通信が行われない場合にVPN プロバイダ内のネットワーク資源が無駄になり帯域利用率を高める事が出来ない．
VPN プロバイダは安価に VPN サービスを提供するために，プロバイダ内の帯域利用率を高める必要がある．また VPN プロバイダは最低帯域の保証だけではなく，未使用帯
域を公平に割り当てなければならず偏りがあってはならない．従来のフィードバック
情報を用いた動的な帯域割当方式を用いる事で，各拠点に対して重み付けを行い，公平に帯域を割り当てる事は可能であるが，VPN 間の公平性を満たす事は出来ない．そこで，本研究では，最低帯域保証，高帯域利用率，組織間の公平性（VPN 間の公平性），
拠点間の公平性（VPN 内の公平性）を 4 つの要求項目として，それらの全てを満たす
VPN 向けネットワークシステムの提案を行った．提案方式では新たな VPN モデルとして提案されているホースモデルと，フィードバック情報を用いた動的な帯域割当方式を用いる．本方式は各拠点に対して重み付けを行うだけではなく，各組織に対しても重み付けを行い，VPN 間と VPN 内の公平性を同時に実現する．
本機構の有効性を検証するために，TCP フローのスループット特性に着目したシミュ
レーション実験を行った．ここではその中から代表的な結果として，通信拠点が A，Bの 2 拠点の場合，A が 2 拠点，B が 1 拠点の合計 3 拠点の場合，A が 1 拠点，B が 2 拠点の合計 3 拠点の場合，それぞれの平均スループットと帯域利用率を表 3.3.6 にまとめる．表中，括弧内の数値は設定された重みに基づき期待される結果を示しているが，従来方式はその仕様的な制限のため厳密に割り当てることができない．

表 3.3.6

各拠点フローのスループット特性[Mb/s]および帯域利用率[%]
提案方式

従来方式

A

56.95 (60.00)

66.02 (60.00)

B

41.25 (40.00)

32.39 (40.00)

帯域利用率

98.3

98.4

A1

29.32 (30.00)

41.70 (37.50)

A2

29.38 (30.00)

41.74 (37.50)- 158 -

B

40.01 (40.00)

16.06 (25.00)

帯域利用率

98.7

99.5

A

56.76 (60.00)

35.02 (42.86)

B1

21.04 (20.00)

32.16 (28.57)

B2

21.03 (20.00)

32.20 (28.57)

帯域利用率

98.8

99.4

この結果から，提案方式はすべての結果において従来方式よりも正確に帯域を割り当て可能であることがわかる．また，帯域利用率も良好な結果が得られている．この結果は定常状態における結果であるが，さらに過渡状態から定常状態への移行時間も提案方式は従来方式の約半分に短縮できることも示している．
3.3.3

アクセス網選択手法

インターネットアクセス網は多様化してきており，特に無線通信技術の急激な発達とともに今後さらに多様化が進むことが予想されている．例えば，従来より無線イン
ターネットアクセスに用いられている無線 LAN だけではなく，携帯電話や PHS なども
直接インターネットへ IP 接続する準備が進められてきている．また，局所的な通信技術ではあるが bluetooth や赤外線通信に対する期待も高まってきている．しかし，これらの通信技術は従来の有線アクセス網に比べて通信品質の変動が激しいという問題があり，また，これらの通信技術はそれぞれ様々な通信速度，特性を持っている．例
えば，無線 LAN は高速な通信が可能であるが，そのサービス範囲は小さく，一方で携帯電話網は広いサービス範囲を持っているが，その通信速度は比較的小さいという特性がある．そのため，サービス範囲が広いネットワークの中に，小規模ではあるが比較的高速サービス可能なもの，さらに局所的なサービスしかできないが非常に高速な通信が行えるものなど多種多様な無線アクセス網が相互に重なり合い配置されることが予想されている．
一方で，インターネット上で用いられるアプリケーションも多様化してきており，従来からの電子メールや Web 閲覧だけではなく，IP 電話やビデオ配信，ネットワークゲ
ーム，P2P 通信など様々なアプリケーションが用いられるようになってきている．つまり，従来のトラヒックよりも特性のレンジが広く変動も激しいという特徴があり，また要求される品質も従来よりも多様化してきている．そこで，今後の様々な無線ア
クセス網を利用するインターネット上でも高品質なエンドツーエンド通信を公平かつ効率よく実現することが重要な課題となっており，アプリケーションの要求する品質を満たしつつ，様々な無線アクセス網をシームレスに利用できるような動的適応的な資源利用技術の開発が必要である．
そこで，本サブテーマでは，多種多様な無線アクセス網が相互に重なり合い配置され- 159 -

る今後のユビキタスネットワークにおいて，時々刻々と無線アクセスメディアの品質が変動する環境で，通信途中でも通信メディアの状況に応じて，アクセス網を切り替
えたり，利用するアプリケーションの特性に応じて，利用するアクセス網を選択する
ような動的なアクセス網選択・切り替え手法に関して取り組んだ．その結果，アクセ
ス網を選択するための新しい通信層であるアソシエーション層をトランスポート層とネットワーク層の間に挿入することを考案し，その詳細な設計を行い，そのシステムの試作開発を行った．また，そのプロトタイプ実装を用いたデモ実験を含む研究紹介
を JGN2 ワークショップおよびシンポジウムにて行った．さらに，特にエンドホスト間の Round Trip Time（RTT）が長く，またエンドホストが利用する通信メディアを頻繁に切り替える場合に着目した本機構の性能をシミュレーションにより明らかにし，その成果を情報ネットワーク研究会にて発表した[8]．
3.3.3.1

アソシエーション層

無線アクセスメディアの品質を考慮した切り替えを行うためには，各通信メディアの状況に応じて利用するメディアを選択する必要がある．自エンドホストがデータを送信するアップリンクに関しては，そのホストが送信メディアを選択すればよいため，比較的簡単に実現できる．しかし，データを受信するダウンリンクに関しては，通信相手ホストに受信したいメディアを広告し，その宛先へデータを送信してもらわなけ
ればならない．また，その送受信メディア情報は時々刻々と変動する無線状態などに応じて動的に更新される必要がある．そこで，各エンドホストが保持する通信メディ
アの情報を相互に管理しあい，最適な通信メディアを選択し切り替えるための新しい
アソシエーション層を提案している．このアソシエーション層は，図 3.3.5 に示すようにトランスポート層とネットワーク層との間に挿入する 3.5 層であり，エンドホス
ト間でアソシエーションを確立する．この 3.5 層と間に挿入するのは，トランスポー
ト層やネットワーク層が本来持つフロー制御・輻輳制御やルーティングなどの複雑な機能から分離することにより，それらの機能と独立して開発できるようにするためである．さらに，トランスポート層よりも下で実現するため，Socket API に変更を必要とせず，従来のアプリケーションがそのまま利用可能である．また，ネットワーク層の上位層であるため，複数の IP アドレスを管理し，フローの特性やネットワーク状況に応じて通信メディアを選択することができ，通信品質制御に有効である．

- 160 -

アプリケーション層

アプリケーション層

Flow

トランスポート層 （L4）

Association

アソシエーション層 (L3.5）
ネットワーク層 （L3）

Routeトランスポート層 （L4）
アソシエーション層 （L3.5）
ネットワーク層 （L3）

データリンク / 物理層

データリンク / 物理層

図 3.3.5

アソシエーション層

Transport flow
Host
Association

Route

Network
interface

図 3.3.6

アソシエーション

このアソシエーション層はトランスポートフローと実際の通信路との対応付けを行う．
具体的には，各エンドホストが保持する複数のネットワークメディアの組み合わせから形成される通信路の集合をアソシエーションとして管理し，その集合の中からメデ
ィアの状況，フローの特性に応じて，最適な通信路を選択する．また，このアソシエーションはホストの移動や無線状況の変化により動的に更新される．図 3.3.6 は，トランスポートフローやアソシエーションなどの関係を示したものである．アソシエー
ションは各ネットワークメディア間の経路の集合となり，この場合各ホストは２つのメディアを持っているため合計 4 本の経路集合を管理する．また，そのエンドホスト
間のトランスポートフローすべてをこのアソシエーションに対応づける．そうすることで，フローの特性に応じた最適な経路を選択することが可能となる．
モビリティを実現するためには，トランスポート層とネットワーク層の識別子を分離することが多い．このアソシエーション層でも新規に各ホスト固定のホスト識別子- 161 -

を定義し，このホスト識別子ペアでアソシエーションを識別する．そして，トランスポート層で用いるフロー識別子とネットワーク層の実際に通信に用いる送受信 IP ア
ドレスの間で，3.5 層のアソシエーション情報をもとに選択，変換を行う．そうする
ことで，無線状況に応じた最適なメディアを選択し，切り替えながらトランスポート
層のコネクションを継続することが可能となる．さらに，アソシエーション層ではフローを意識した管理を行うため，最適なフロー割り当てなどの通信品質制御や，無線環境で特に問題となるコネクションハイジャックや盗聴などへの対応が比較的容易であると考えられる．
3.3.3.2

設計・実装

ユーザランドユーザランド管理DB
コンフィグレーション
GUI

汎用アプリケーション（TCP/UDPアプリ)

管理DB
コンフィグレーション
GUI

汎用アプリケーション（TCP/UDPアプリ)

X-Windows

X-Windows

カーネル

カーネル
Socket Layer

Socket Layer

TCP/UDP Layer

TCP/UDP Layer

Association Layer

Association Layer

管理DB

IP Layer(IPv4)

イーサネット802.11
a/b/g

管理DB

IP Layer(IPv4)

携帯電話
etc

イーサネット802.11
a/b/g

携帯電話
etc

アクセス網

図 3.3.7

システム概要上記アソシエーション層を実現するために，アソシエーション情報のデータ構造，アソシエーション情報の交換に用いるアソシエーションプロトコル，アソシエーション
状態遷移，およびパケットデータ構造を設計し，Linux カーネル内に実装を行った．
図 3.3.7 に全体システム概要を示す．各エンドホストは，有線 LAN（Ethernet），無線
LAN（802.11a/b/g），携帯電話カードなど複数の異なるインターフェースを持つマルチ
ホーム環境のホストである．通常はある特定のインターフェースにより通信を行う．

- 162 -

エンドホストが移動し通信中のインターフェースが接続するネットワークの状態が変化したとき，そのネットワークの状態変化を検出し，適切なインターフェースに切り替えて通信を継続する．
両エンドホストが保持するネットワークインターフェースの組み合わせにより形成される経路の集合をアソシエーションとして管理する．そのアソシエーションの管理に必要な機能およびその定義を以下に簡単にまとめる．
エンドホスト間アソシエーション確立機能
エンドホスト間通信開始時に（TCP コネクション確立時，および UDP データグラム送
受信開始時），そのエンドホスト間でアソシエーションが未確立の場合，アソシエーシ
ョン情報を交換し，アソシエーションを確立する．
エンドホスト間アソシエーション解放機能
エンドホスト間通信終了時に（TCP コネクション切断，UDP データグラム送受信完了時），
そのエンドホスト間のすべての通信が終了した場合，アソシエーション管理データベースから，アソシエーション情報を解放する．
エンドホスト間アソシエーション診断機能
エンドホスト間において，周期的にアソシエーション情報パケットを送信し，アソシ
エーション管理データベースの調整を行う．
エンドホスト間アドレスリスト通知機構
一方のエンドホストで利用可能な IP アドレス，データリンク情報が変化した場合，相手エンドホストに対してアドレスリストの通知を行う．
アソシエーション管理データベース
エンドホスト間のアソシエーション（状態遷移，アドレスリスト）を管理し，このデータベース情報を元に，アソシエーションの確立，解放，診断，および通知を行う．
ネットワーク状態監視機能
自エンドホストのネットワーク層，およびデータリンク層を監視し，それらの層で変化を検出した場合，アソシエーション層情報を更新する．
ネットワーク切り替え機能
アソシエーション管理データベースの情報を元に，使用する IP アドレス，データリン
クを切り替える．
非アソシエーション対応エンドホスト通信機能
アソシエーション機能に対応していないエンドホストと通信を行う場合，アソシエー
ション層間通信，およびアソシエーション機能を使用せず，通常の TCP/IP，UDP/IP
通信を行う．
以上の機能を実装したプロトタイプを用い，JGN2 シンポジウムにおいてデモ実験を- 163 -

行った．構築した実験環境は，アソシエーション層を組み込んだクライアント PC とサーバ PC がルータを介して接続しており，その際マルチホーム環境として，クライアン
ト PC には有線 LAN によるアクセス網と無線 LAN によるアクセス網の 2 つが利用可能な環境である．この環境で，サーバからクライアントへ動画像をストリーミング配信し，クライアントにおいてその動画を再生した．アクセス網としては一般に有線 LAN の方が品質が高いため，有線 LAN が利用可能な場合はそれを用い，移動などの理由で無線LAN しか利用できない場合には無線 LAN へ切り替え，また有線 LAN が利用可能になると有線 LAN へ切り替えるというデモを行った．その際，アクセス網を切り替えても，動画が切れることなく継続する様子を実演した．
3.3.4

マルチホップ無線実験環境の構築

インターネット

A 2
AP-4

A 2
AP-2
AP-1

AAP-3
3

図 3.3.8

AAP-5
3

マルチホップ無線環境

従来の無線 LAN 環境では，一般にアクセスポイント（AP）は有線網で相互接続されている．すなわち，各 AP は以下の無線網は有線網を経由し，相互接続されている状態である．しかし，今後の無線 LAN 環境では，図 3.3.8 で示すような各 AP 間も無線を用いて相互接続されることが望まれている．AP 間を無線化することにより，運用・設置コストの低減や無線網の柔軟な構成が可能となるためである．この図のように，各 AP間を無線により接続すると，従来 AP とホスト間でのみ利用していた貴重な無線資源が使われることとなり，現在のシステムでは大幅な性能劣化が予想される．そのため，
マルチホップ無線環境においても，AP 間が有線網で相互接続された従来と同程度の通信品質および無線 LAN 網全体の利用効率の確保が重要な課題となる．
そこで，各無線 AP が無線で相互接続されるようなマルチホップ無線環境において，各ホストの通信品質および利用率特性などを調査するための実験環境を構築した．また，無線 LAN 内の各ポイントのトラヒック状況を active 計測および passive 計測し，

- 164 -

その情報をサーバで集中管理するためのシステムを開発した．
参考文献[1] Y. Fukuda, T. Abe, and Y. Oie, “Decentralized Access Point Selection
ArchitectureforWireless

LANs,”

Proc.

Wireless Telecommunications

Symposium 2004, Pomona, USA, May 2004.
[2] Y. Fukuda and Y. Oie, “Decentralized Access Point Selection Architecture
for Wireless LANs

Deployability and Robustness ,” Proc. IEEE VehicularTechnology Conference 2004-Fall (VTC2004-Fall) , Los Angeles, USA, September
2004.
[3] 福田 豊, 藤原 暁宏, 鶴 正人, 尾家 祐二, “無線 LAN におけるアクセスポイン
ト 選 択 戦 略 の 性 能 解 析 ”, 電 子 情 報 通 信 学 会 技 術 研 究 報 告 , NS2004-145,
TM2004-48, pp. 1-4, 鎌倉市, 2004 年 11 月.
[4] Y. Fukuda and Y. Oie, “Unfair and Inefficient Share of Wireless LAN Resource
among Uplink and Downlink Data Traffic and its Solution,” to appear in IEICE

Transactions on Communications, April 2005.
[5] H. Koga, K. Iida, and Y. Oie, “Receiver-based Flow Control Mechanism with
Interlayer Collaboration for Real-Time Communication Quality in W-CDMA
Networks,” Proc. IFIP 9 th International Conference on Personal WirelessCommunications (PWC2004) , Lecture Notes in Computer Science, vol. 3260, pp.
286-300, Delft, The Netherlands, September 2004.
[6] S. Takeuchi, H. Koga, K. Iida, Y. Kadobayashi, S. Yamaguchi, “Performance
Evaluations of DCCP for Bursty Traffic in Real-time Applications,” Proc.

IEEE/IPSJ 2005 International Symposium on Applications and the Internet(SAINT2005) , pp. 142-149, Trento, Italy, January/February 2005.
[7] 嶋村 昌義, 飯田 勝吉, 古閑 宏幸, 門林 雄基, 山口 英, “動的重み配分アル
ゴリズムによる VPN ホース帯域割当手法の提案とその性能評価”, 電子情報通信学会 技術研究報告 , IN2004-130, pp. 1-6, 広島市, 2004 年 12 月.
[8] 岡本 拓二, 古閑 宏幸, 飯田 勝吉, 門林 雄基, 山口 英, “マルチホーム環境下においてホストモビリティがトランスポートフローに与える影響 ～激しい移動強度と長い RTT への対応～”, 電子情報通信学会 技術研究報告 , IN2004-141,
pp. 67-72, 広島市, 2004 年 12 月.

- 165 -

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
3.4.1.1

end-to-end 端末間で動作する制御方式
JGNII を利用した高速トランスポートプロトコル伝送実験

本章では 既存の TCP に替わる, 新しいトランスポートプロトコルとして提案されている HSTCP(HighSpeedTCP), Scalable TCP, FAST, UDT の各プロトコルを対象として,
JGN(Japan Gigabit Network)II の国内回線, 国際回線を利用して行った実験内容を報告する.
TCP はエンド-エンドで実施する確認応答制御による信頼性の提供, ウィンドウサイ
ズの増減に基づく輻輳制御の実施, 実装の容易さなどから, インターネット上の多くのアプリケーションで, トランスポートプロトコルとして利用されている. しかし
TCP は その輻輳制御アルゴリズムに起因して, 長距離・大容量ネットワーク上のトラ
ンスポートプロトコルとしては適していないことが知られている.このため現在, 広帯域化, 広域化したバックボーンネットワークを背景として出現してきた Grid, ネットワークストレージ等の新しいアプリケーションに適したトランスポートプロトコ
ル実現のための研究開発が活発化している.
そこで今年度, 既存の高速トランスポートプロトコルを対象として, JGNII 上で伝送実験を行い, その性能評価を実施した.性能指標としてはスループット特性に着目した . TCP を ベ ー ス と し た プ ロ ト コ ル フ ロ ー (Standard TCP,
TCP,FAST)のスループットは iperf を利用して,- 166 -HSTCP, Scalable

UDP をベースとした UDT プロトコル

フローの スループットは, UDT コードの実装の中でカウントされている受信パケット数をもとに算出している.図 3.4.1.1.1 に実験構成図を示す.

図 3.4.1.1.1

JGNII を利用した実験ネットワーク構成図

実験では JGNII 国内回線（ボトルネック帯域幅：1[Gbps], RTT=50[ms]）と JGNII 国
際回線(ボトルネック帯域幅：1[Gbps], RTT=180[ms]) の 2 種類のパスを利用した.
今年度 実施した実験では各プロトコルの基本特性に加えて, 次のような視点から検討した実験シナリオによる評価を実施した. インターネットが高速になるにしたがって,ユーザはインターネット上で高速トランスポートプロトコルをデータ伝送に利用することを考えはじめることが想定される.実際, OS の中には高速トランスポー
トプロトコルの実装が組み込まれて配布されているものや

アプリケーションレイヤ

で配布されているプロトコルもあり ユーザが端末側で設定を行えば, すぐに利用可
能な状況にある. しかし もともと高速トランスポートプロトコルは十分な帯域がある状況で限られた数のフローが帯域幅を効率的に利用することが目的として提案されたものであり,インターネットのようなネットワークでの利用を想定されているものではない. そこで 実験では将来のインターネットにおいて, 提案されている高速トランスポートプロトコルを利用した場合の各プロトコルの性能を調べることを目的として実験を実施した. インターネットという状況を想定した場合, 以下の２つの状況における性能について検討することが重要になると考えられる.
・

可用帯域幅や遅延の変動など

ネットワーク状況の変化に対する追随性

・

異種高速トランスポートプロトコル共存時の特性- 167 -

昨年度, 実験を実施した項目を以下に示す.
（基本特性）(a) シングルプロトコルフローのスループット特性,(b) 受信側の OS の種別を変更した時のスループット特性,(c) 両方向から同時にプロトコルフローを流した時のスループット特性,（ネットワーク状況の変化に対する追随性）(d) 遅延の変動における特性,(e) 帯域幅の変動における特性,(異種高速トランスポートプロトコル共存時の特性)(f)

異なるプロトコルフローを１本ずつ２本共存している時の特性,(g)

UDP フローと高速トランスポートプロトコル共存時の特性,(h)short-lived TCP フローと高速トランスポートプロトコル共存時の特性

以下に 結果の中から(a), (d), (e), (f) で得られた結果を示す.

(1) シングルプロトコルフローのスループット特性

図 3.4.1.1.2

シングルプロトコルフローのスループット特性

図 3.4.1.1.2 に シングル高速トランスポートプロトコルフローのスループット特性を示す.図 3.4.1.1.2 において Standard TCP は HSTCP, Scalable TCP のスループッ
ト特性と同様に急峻に立ち上がっているが, これは Txqueuelen を大きくしていることの効果である. UDP を除く 他のすべての高速トランスポートプロトコルの利用において Txqueuelen を大きくする（>1000)設定となっていることから,Standard TCP においても同じ値としている. しかし Standard TCP は 一度パケット廃棄が生じると, 輻輳回避モードに移り, スループットの増加が非常にゆるやかになっている. これに対して HSTCP と Scalable TCP における 輻輳回避モードでのスループットとの増加の傾
きは Standard TCP のそれと比較して 大きくなっている様子がわかる.図 3.4.1.1.2
において, FAST プロトコルは 一度スループットが低下した後の立ち上がりが, 急峻である様子がわかる. これは, FAST は主に遅延値をベースとして明示的に, ウィンド

- 168 -

ウサイズを決定する制御を行っているためと考える. また BIC の特性が安定していることは これまでも報告されているが,これは BIC が急激なウィンドウサイズの増減を行う代わりに binary search を利用して,廃棄が生じたウィンドウサイズまでの制御を行うためであると考える. UDP プロトコルをベースとした UDT プロトコルは,定期的な 可用帯域の測定と, 廃棄されたパケット数からレート制御を行うプロトコルであり, 最初から 高いスループットが観測される.途中何度かスループットの低下が見られるが,これは直前に 複数の NACK パケットが受信され,その結果,ウィンドウサ
イズが縮んでスループットが低下している.
(2) 遅延の変化,可用帯域幅の変化がスループット特性に及ぼす影響

RTT=50[ms]10GbpsJGNII(domestic)

Kitakyushu RC

Kitakyushu RC

1Gbps

1Gbps
GR2000-BH

GR2000-BH

PacketSphere

RTT=150[ms]図 3.4.1.1.3

遅延値の異なるパスを切り替えた時のスループット特性

図 3.4.1.1.3 に パスの遅延値が 最初の 30[s]間は 50[ms] 次の１分間は 150[ms],次の１分間は 50[ms]と 遅延が変化した場合の特性を示す. 図 3.4.1.1.3 より,遅延が変化することによって FAST プロトコルのスループット値が影響をうけていることがわかる. UDT 以外のその他のプロトコルは 遅延値が変化した直後はスループットを低下させているが,状況に追随して動作し,RTT が元の値に戻ると スループット値をもとのレベルまで急速に回復させていることがわかる.

- 169 -

Bandwidth = 1[Gbps]
10GbpsJGNII(domestic)

Kitakyushu RC

Kitakyushu RC

1Gbps

1Gbps
GR2000-BH

GR2000-BH

PacketSphere

Bandwidth = 500[Mbps]
図3.4.1.1.4

帯域値の異なるパスを切り替えた時のスループット特性

図 3.4.1.1.4 に パスの帯域が 最初の 30[s]間は 1[Gbps] 次の１分間は 500[Mbps],
次の１分間は 1G[bps]と変化した場合の特性を示す.図 3.4.1.1.4 より, 各プロトコ
ルフローはいずれも帯域幅の変化に追随していることがわかる. 特に UDT は 帯域幅の増減にほぼ遅れることなく 追随できている様子がわかる. これは UDT が パケッ
トペアを利用して可用帯域幅を計測しレート制御を行っているためであると考える.
(3) 異種プロトコルフローが混在した場合の特性
次に, 異なるプロトコルフローが複数本同じパス上に共存した場合のスループット
特性を図 3.4.1.1.5 に示す.

将来,高速トランスポートプロトコルを利用してデータ転送を行うユーザが増加した場合も残ると考えられる. そこで

既存の TCP を利用したデータ伝送トラヒックはStandard TCP とした場合の特性を図 3.4.1.1.5(a)に示す.

高速トランスポートプロトコルが共存
公平性の定義に関しては

高速トランスポートプロトコルフローと Standard TCP フローが同様のスループットを取得できた場合に公平性を実現という定義がよく見られるがここでは次のように考える. 図

3.4.1.1.5(a) に 示す Standard TCP フローを同時に 2 本流した時の各フローのスループット値と同等のスループットを達成できるかどうかによってStandard TCP フロ

ーへの影響を考察する.図 3.4.1.1.5(a) に示すように Standard TCP フローを２本流した時の１本あたりのスループットは200[Mbps]でありこの値と高速トランスポー

トプロトコルフローを同時に流した場合の他のデータと比較すると, 高速トランスポートプロトコルフローと同時に流した場合の方がスループット特性は低下していることがわかる. プロトコルごとに見ると, Standard TCP に対する影響の大きさはUDT

フローが最も大きく,次が Scalable TCP であることがわかる.

(1

t
)S

an

da

rd

:(

2)

(2)
(1)
Throughput[Mbps]

Throughput[Mbps]

1000
900
800
700
600
500
400
300
200
100
0

a
St

)
(1

nd

St

d
ar

an

rd
da

H
2)
:(

(1

t
)S

ST

an

C

d

P

d
ar

:

)
(2

a
Sc

(1

b
la

)S

ta

le

a
nd

rd

F
2)
:(

AS

T

t
)S
(1

d
an

ar

d

2
:(

)B

)
(1

IC

d
an
St

d:
ar

)
(2

U

D

1000
900
800
700
600
500
400
300
200
100
0

(2)
(1)

T

(1

)U

- 170 -

DT

2
:(

)H

ST

C

P

(1

D
)U

T

Sc
2)
:(

al

ab

le

(

U
1)

D

T

:

)
(2

FA

ST

)
(1

UD

T

2)
:(

BI

C

(a) Standard TCP:高速トランスポートプロトコル (b)UDT:高速トランスポートプロト
コル
図.3.4.1.1.5

異なるプロトコルフローが共存した時の特性

また 図 3.4.1.1.5(b)に異なる２本の高速トランスポートプロトコルフローを共存させた場合のスループット特性を示す. 本例では UDT フローを１本と他の高速トランス
ポートプロトコルフローを１本

それぞれ流した時の特性を示している. 本図より

UDT フローは他の高速トランスポートプロトコルフローに対して及ぼす影響が大きい
ことがわかる. 同様に他の高速トランスポートプロトコルをそれぞれ１本ずつ合計２本流した場合の特性に関しても調査したが, いずれのプロトコルフローの組み合わせにおいても公平性を実現できる組み合わせはなかった. 他の高速トランスポートプ
ロトコルに及ぼす影響が最も大きいプロトコルはUDT で TCP をベースとしたプロト

コルでは Scalable TCP の及ぼす影響が最も大きいことがわかった.
次に表 3.4.1.1.1 に異種のプロトコルフローを１本ずつ, 合計２本流した時の合計のスループット特性を示す. 例えば HSTCP フローを１本ずつ 合計２本流した場合の合計の平均スループットは 643[Mbps]で Scalable TCP フローを合計 2 本流した場合の平均スループットは692[Mbps]となる.これに対して HSTCP と Scalable TCP フローを１本ずつ合計２本流した場合の合計の平均スループットは 315[Mbps]であり, この値は同種のプロトコルフローが２本流れている場合の合計スループットのいずれよりも低くなっている.また同様に FAST と HSTCP,UDT と Scalable TCP, FAST と HSTCP, BIC とFAST の組み合わせにおいて合計スループット特性が, 異種プロトコルフローを組み合わせた場合と比較して低くなっていることがわかる. 本表から, 高速トランスポー
トプロトコルの組み合わせによっては合計スループットが低下するものがあり, 他のプロトコルフローの性能に対して悪影響を与えるプロトコルがあることがわかる.
表 3.4.1.1.1
HSTCP
Scalable
FAST
BIC
UDT

3.4.1.2

異なるプロトコルフロー共存時のスループット特性

HSTCP
Scalable FAST
BIC
643
315
273
315
692
493
273
493
402
621
592
274
803
647
747

UDT
621
592
274
533
781

803
647
747
781
756

イリノイ大学との共同研究

本章では JGNII 国際回線を利用した活動として イリノイ大学との共同実験を紹介する. 図 3.4.1.1.1 に JGNII 国際回線を利用した高速トランスポートプロトコルで利用した実験ネットワーク構成を示したが, 受信側端末としてイリノイ大学が- 171 -StarLight ネットワーク上に設置している端末を利用して実験を行った.（1[Gbps]インターフェースを持っ たマシン２台と10[Gbps]インターフェースを持ったマシン

２台）また, 大手町の NOC にイリノイ大学が展開している TeraFlow Testbed のノードとして 10[Gbps]のインターフェースを持ったマシンが１台と1[Gbps]のインターフ

ェースを持ったマシンが２台設置された. また１１月にアメリカで行われた Super
Computing 2004 では

ＵＤＴプロトコルを利用したデータ伝送デモに共同で参加し,

図 3.4.1.2.1 に示す構成で 1.5[TB]の大容量・高品質データ伝送実験に成功した.

図 3.4.1.2.1

SC2004 におけるネットワーク構成

イリノイ大学との JGNII 国際回線を利用した共同実験は今年度も継続する予定である.
3.4.1.3

まとめと今後の予定

本章では平成１６年度に

JGNII 国内回線, 国際回線を利用して実施した高速トラ

ンスポートプロトコルを対象とした伝送実験の結果とイリノイ大学と共同で実施している共同実験活動の内容を紹介した. 引き続き, 平成 17 年度は JGNII 国内回線, 国際回線を利用して以下の項目の実施を予定している.

・

ボトルネック帯域 1[Gbps]環境での高速トランスポートプロトコル伝送実験

・

ボトルネック帯域 10[Gbps]環境での高速トランスポートプロトコル伝送実験

・

イリノイ大学との

JGN2 国際回線を利用した共同実験の実施- 172 -

3.4.2

中間ノードでの制御も組み入れた方式

本章では end-to-end だけの制御だけでなく, 中間ノードでの制御も組み入れた方式の例として実時間トラヒックの遅延特性を改善するために, 中間ノードで実施する
優先パケット廃棄方式の性能をシミュレーションによって評価した内容を紹介する.
実時間アプリケーションの品質は, 廃棄特性だけでなく end-to-end の遅延特性に大きな影響を受ける. 実時間アプリケーションは 実時間という特性上, その品質を保持するために 許容できる遅延値がアプリケーションごとに規定されている.許容値を越えた 遅延を経験して 目的地に到着したパケットは アプリケーションによって廃棄される.すなわち, 網内で経験した遅延値が 許容遅延値を越えた時点でそのパケッ
トはアプリケーションから見ると 有効なデータではない. さらに網内の他のフローからすると余分な負荷であると考えられる.そこで,この点に着目して 実時間トラヒ
ックの end-to-end の遅延値を改善することを目的として許容遅延値を越えて網内に存在するパケットを中間のルータで検出した場合, 優先的にそのパケットを廃棄する手法を適用した場合の特性を シミュレーションによって検証している内容を報告す
る
3.4.2.1

MTQ 方式と QTL 方式

実時間アプリケーションの遅延特性を改善するために, 中間ノードでノードの混雑状況に応じて到着パケットを優先的に廃棄する MTQ 方式と QTL,方式を提案する. MTQ
方式は,各パケットに対して パス上の各ノードで滞在することのできる時間の最大値を規定するものであり,バースト的な混雑の緩和のみでなく 本稿で対象とする実時間
アプリケーションで重要な指標となる end-to-end 遅延特性の改善にも効果が見られると考える. また MQL を設定することは各ノードの 物理的なバッファサイズを制限することと同等となる. QTL 方式は end-to-end の遅延値を指標として各ノードで動作する. MTQ, QTL 方式の制御内容を図 3.4.2.1.1 に示す. また, 中間ルータにおける MTQ,QTL 方式の処理の流れを以下に示す.
MTQ

パケットヘッダーに各ノードでの最大許容待ち時間の設定

パケット到着時 ：① ノード内での待ち時間をキュー長から計算② 最大許容待ち時間 ＞= ノード内での待ち時間：
ノードにキューイング
最大許容待ち時間 ＜ ノード内での待ち時間
:
廃棄

・・・・
エッジノード・・・・
中間ノード

パケットヘッダーにEnd-toEnd-での最大許容待ち時間の設定

QTL

図 3.4.2.1.1

中間ノード

エッジノードパケット到着時 ：① ノード内での待ち時間をキュー長から計算② 許容待ち時間 ＞= ノード内での待ち時間： 許容待ち時間＝許容待ち時間ーノード内での待ち時間に更新して ノードにキューイング
許容待ち時間 ＜ ノード内での待ち時間:
廃棄

MTQ,QTL 方式の概要- 173 -

・

MQL 方式(1) 各 パ ケ ッ ト は ヘ ッ ダ に , 各 ノ ー ド で 許 容 で き る 遅 延 値 の 最 大 値 (time-canwait-mql)を持つ.
(2) 中間ノードでは パケット到着時のキュー長からそのパケットが該当ノード内で待つことになる時間 time を計算し, その値と, パケットヘッダー内の許容待ち時間(time-can-wait-mql)を比較して,time-can-wait-mql>= t の場合はノード内に格納する. time-can-wait-mql < t の場合は 許容遅延時間を超えて網内に存在することとなるため キューに格納されず パケットは廃棄される.
・

QTL 方式(1)

各パケットはヘッダに, 利用アプリケーションによって end-to-end で許容できる遅延値 time-can-wait-qtl を持つ.
(2) 中間ノードでは パケット到着時のキュー長からそのパケットが該当ノード内で待つことになる時間 time を計算し, その値と, パケットヘッダー内の許容待ち時間(time-can-wait-qtl)を比較して,time-can-wait-qtl>= time の場合はノード内に格納する. time-can-wait-qtl < time の場合は 許容遅延時間を超えて網内に存在す
ることとなるため キューに格納されず パケットは廃棄される.
(3) 許容待ち時間以内のパケットは, ヘッダ内の (time-can-wait-qtl)値をtime -

time-can-wait-qtl に更新する.
実時間アプリケーションが経験する遅延値をアプリケーションで許容されている値に制御することを目的として 本方式を適応する. 実時間アプリケーションで規定されている許容遅延値をもとに, ネットワーク上での経過遅延がそれ以上であるパケット
はネットワークの状況に応じて早期に廃棄し, 網内の全フローのサービス品質を考慮した制御を行う手段として利用する.この場合, 各パケットに許容遅延時間を設定するのはネットワーク管理者であり.ユーザフローを収容するエッジノードで設定が行われる.
3.4.2.2

シミュレーション構成

提案手法を対象に, ns2(network simulator2)を利用して シミュレーションを行った

ネットワークモデルを図 3.4.2.2.1 に示す.

図 3.4.2.2.1 に示すように比較的長い遅延(固定遅延：140[ms])を持ったパス上に 複数の実時間アプリケーションフローが存在し,リンクを共有しているモデルを対象とする.

- 174 -

Flow Group 1

Flow Group 2

5[ms]

5[ms]
15[ms]

15[ms]

20[Mbps]20[Mbps]20[Mbps]20[Mbps]…

10[ms]…

100[ms]1[Mbps]1[Mbps]Flow Group 0.

Flow Group 0 と Flow
Group 1が競合

図

3.4.2.2.1

Flow Group 0 と Flow
Group 2が競合

制御ノード

シミュレーションモデル

実時間トラヒックフローとしては音声トラヒックモデルを基準として(1) バース
ト性の低い実時間トラヒックモデル, (2) バースト性の高い実時間トラヒックモデルの２パターンを対象としてシミュレーションを実施している.性能指標としては フローグループ単位の平均パケット廃棄率を対象としている. パケット廃棄は 次の２種類からなる. 1 つめが 網内のノードのバッファあふれで廃棄されたパケット廃棄(パケット廃棄率 A)と,目的地に到着したパケットの中で,アプリケーションによって許容されない遅延を経験しているパケット(パケット廃棄率 B) であり,アプリケーシ

ョンから見た実質的な廃棄率は(A+B)となる.
3.4.2.3

シミュレーション結果

本章では シミュレーションによって得られた結果を示す.
図 3.4.2.3.1 に MTQ を各制御ノードに適用した場合のアプリケーションから見たパケット廃棄率特性を示す.

(a)バースト性の低いトラヒックを収容した場合, (b)バースト性の高いトラヒックを収容した場合
図 3.4.2.3.1

MTQ 方式の効果

MTQ を各制御ノードに適用することはノードのバッファサイズを一時的に制限することである. そのため小さなＭＴＱを利用することによってキューでの遅延が短くな- 175 -

り,

end-to-end の遅延値が短くなる. 図 3.4.2.3.1 に示すようにいずれのトラヒッ

クパターンにおいても MTQ が 60[packet]を越えると, end-to-end の遅延値が急激に増加してアプリケーションって廃棄されるパケットの数が増加していることがわかる.
これは MTQ 値（バッファサイズ）が end-to-end 遅延値を決定し, その値が許容遅延値
を超えた値になった時点でパケット廃棄率が増加するためである.図に示すように小さな MTQ 値を設定することで 実時間トラヒックにとっては遅延特性を改善できる.
しかしあまり小さく設定しすぎるとバッファあふれによるパケット廃棄率が増加して性能の劣化につながるため,適した値を見つけることが現実的には困難である.
次に図 3.4.2.3.2 に許容遅延値が 20[ms]である時に設定する QTL を変化させた

場合のスループット特性を示す.

(a) バースト性の低いトラヒックを収容した場合(b) バースト性の高いトラヒックを収容した場合図 3.4.2.3.2

QTL 方式を適用した場合

図 3.4.2.3.2 よりトラヒックのバースト性にかかわらず, 最適な QTL 値は延値とした場合であることがわかる.このことから, QTL を設定する場合は

許容遅
許容遅延

値を利用することが有効であることがわかり, MTQ の設定とは異なり, QTL の設定においては最適値の選択が容易であることがわかる.

したがって, 平成 17 年度は QTL を対象とした評価をさらにすすめていく予定である.
3.4.2.4

まとめ

本章では,網上の実時間アプリケーションのデータの経験遅延値をもとに中間ノー
ドにおいて 許容遅延値を越えて存在するパケットを優先的に廃棄する手法の効果を
実時間トラヒックフローのみが存在する場合において シミュレーションによって検証した. そして 本手法の適用によって パケット廃棄率特性）に,次のような効果が見られた.

- 176 -

・

中間ノードのバッファ長が大きくなるに従って, 中間ノードで何の制御を行わない場合は 遅延特性は著しく悪化する.

バッファサイズを調整することにより, 遅延特性を改善することができる.
・ MQL を設定して, 各ノードでのパケットの滞在時間の最大値を規定することで バ
ッファサイズを調整した場合と同様の効果が見られ 遅延特性が改善される. しかし,
MQL の設定値の最適値を見つけるのは困難である.
・

許容遅延時間をベースとした QTL 値を設定することであるフローの遅延値を A以下にすることができる. 中間ノードのバッファ長が大きくなるに従って QTL をつけていない場合の遅延特性は著しく悪化するが QTL をつけると 特性の悪化は小さ
い.
3.4.3

まとめと今後の課題本テーマでは 今年度 ボトルネック帯域幅 1[Gbps]の JGNII を利用した高速トラン
スポートプロトコルを対象とした伝送実験と, 中間ノードでの制御を組み入れた実時
間アプリケーションの遅延特性の改善方式の検討と評価に実施した. 今後の課題としては,ボトルネック帯域幅 10[Gbps]の環境とした JGNII 上での伝送実験の実施と平成
１６年度に基本特性の評価を実施した ルータ支援を組み入れた方式の 評価の実施を予定している.
参考文献
・``The LAC/UIC experiences through JGN2/APAN during SC04,神山勝司, 熊副和

美 ,Robert L. Grossman!''Yunhong Gu!''Xinwei Hong!''Michal Sabala!''David
Handley, 19th APAN Meetings, Jan 2005
・``Transport Protocols for Fast Long-Distance Networks : Evaluation of Their

Penetration and Robustness on JGNII,'' Kazumi Kumazoe, Katsushi Kouyama,
Yoshiaki Hori, Masato Tsuru, Yuji Oie, PFLDnet 2005

- 177 -

- 178 -第４章
拠点連携型資源共有技術に関する研究開発

第 4 章 拠点連携型資源共有技術に関する研究開発
4.1 概要
近年、グリッドや Web サービス等の分散コンピューティングに代表される、複数の組織が計算資源（CPU やストレージ）やサービスを出し合ってひとつの計算サービスを提供する
技術の研究開発がさかんに行われている。すなわち、1 箇所に資源やサービスを集中させる
ことなく、広域ネットワークを活用することにより、広域分散環境を構築し、その環境の中でさまざまな計算サービスの利用が可能となる技術である。
このような環境においては、多数の組織に属し、地理的にも分散した提供者やユーザがひとつの環境においてさまざまな資源を共有するため、資源の管理は非常に重要な問題である。特に、ひとつの環境に対する新たな資源の追加や削除、資源に対するアクセス制御やユーザに対する資源の分配方法など、数多くの研究課題が残されている。
本研究サブテーマでは、インターネットなど、一般のユーザがアクセス可能な広域ネッ
トワークを介して接続されている環境を想定し、その上での複数の拠点（組織）の資源管理の問題についてセキュリティと資源の割り当て（スケジューリング）の 2 つの側面について研究開発を実施している。
4.1.1 研究開発の必要性(1) 多数の資源提供者によって構成される大規模分散環境における資源管理問題
複数の組織によって計算資源（CPU やストレージ）が提供され、構成された環境では、全ての資源の管理を一元化して実施することは困難になる。特に、その環境にアクセスする
人数が増えれば増えるほど資源の追加、削除、移動などが発生し、少数の管理者による手作業の管理は破綻する。現在の技術では資源の追加、削除などは管理者の手作業が必要であり、これは非常に大きな問題である。そのため、ユーザが自分の権限で資源の追加や削除が実施でき、自分で追加した資源を関係者以外に非公開にできるようなセキュリティ（アクセスコントロール）の手段が重要となる。
(2) ネットワーク品質の計算性能への影響
次は広域な分散処理にかかわる広域ネットワークの品質の問題である。図 4.1.1 に示すような広域ネットワークを利用した分散計算では、データサイズが大きくなればなるほど拠点間のネットワークの性能が計算性能に影響を及ぼす。そのため、現在はダークファイ
バーを専用に準備するなど、広帯域なネットワークを用意する方向で解決を図っているが、コスト面で大きな問題となる。一方、ISP 等の通常のネットワークも広帯域化が進んでおり、帯域保証型のサービスも行われ始めている。このようなネットワークで計算品質を確保できれば分散コンピューティングを広く普及させることが可能と考えられる。
帯域に十分に余裕のない状況でデータ転送の品質を確保するには、フロー単位で帯域を割り当て、各データ転送が必要とする帯域をネットワーク側で保証する必要がある。分散計算では、帯域の要求が満たされない場合、よりネットワークや計算資源に余裕のある別の場所に計算を再割付けする等の処理が発生する。そのため、同一ネットワーク帯域でより多くの帯域要求（データ転送）を処理することができれば、システム全体の利用効率を向上させることが可能となる。システム全体の利用効率向上のため、分散計算の特質に着目してユーザの帯域要求をなるべく損失させないような品質制御技術についての研究開発が重要となる。

- 179 -

拠点A
観測装置等

測定データ
逐次送信

拠点B
大規模クラスタ

拠点C
並列計算機

並列画像処理(オリジナルソフト) 3次元画像合成(商用アプリ利用)

拠点D
ユーザ利用PC

結果の表示と保存

図 4.1.1 広域網を使った計算サービスの例
4.1.2 拠点連携のためのセキュアな資源共有技術の研究開発
グリッド技術はさまざまな資源を組織を超えて相互に接続するために用いられる技術である。これは、システムへの不正侵入の観点で言うならば、グリッド技術を用いて相互に接続された複数の拠点は、一度、ある拠点で外部からの不正侵入を許すと、連鎖的に不正侵入が達成されやすいということであり、サイバーテロのための踏み台や不正なファイル
交換のための場に利用されるといった被害が拡大しやすいということを意味する。
各拠点における外部からの不正侵入を防ぐためには、ファイアウォールの適切な運用・管理が重要である。しかし、現在のグリッド技術はファイアウォールに対する考慮が十分でなく、広域ネットワークに接続された資源に対して不必要なポートに対しても外部からの接続を恒久的に許可するといった設定がされる傾向がある。そのため、各拠点において
外部ネットワークからの不正侵入のきっかけを与えるようなセキュリティ状況となることが問題となっている。
本研究では、資源共有の際に発生するトランザクション単位でファイアウォールを制御する機構を提案する。本提案方式は、拠点への接続に関わる IP アドレス、および、ポートをも限定するため、セキュアな拠点間の連携を実現することができる。

図 4.1.2 不必要なポートも恒久的に接続を許可している資源- 180 -

図 4.1.3 トランザクション単位でファイアウォールが制御されている資源
4.1.3 広域ネットワークにおける大規模データ処理連携技術の研究開発
ここでは、広域ネットワークにおける大規模データ処理連携技術の研究開発について概略を簡単に報告する。DataGrid に代表されるような、巨大なデータを複数の拠点（サイト）に存在する計算資源（CPU やストレージ）に配布するようなアプリケーションでは、データの転送性能がアプリケーションの性能に大きく影響する。特に、観測装置から出力されるデータをリアルタイムで計算処理する場合のように、データ発生源の速度以上の性能で計算を実施する必要があり、各処理に時間的な制約が存在するため、データ転送の品質を広域ネットワークにおいて保証することが非常に重要である。
拠点間のデータ転送の品質を確保するためには、十分に広帯域なネットワークを利用するか、個別の通信に必要なネットワーク資源を動的に割り当てるかのどちらかの対応が必要である。しかしながら、広域ネットワークにおいて事前に十分な帯域を確保しておくことは非常にコストが大きく、多くの場合実現するのは困難である。
動的に帯域を割り当てる方法のうち、各フローに要求帯域を固定的に割り当てる場合、ルータにおいて、制御対象となるフロー数だけバッファを準備すると共に、バッファの長さ等のパラメータ設定を頻繁に変更する必要があり、ルータの負荷が非常に高くなる。また、契約帯域以上のスループットを各フローに提供しないため、未使用となる帯域が発生し、資源の利用効率はあまり良くない。
次に、フロー単位で最低帯域保障を実施した場合は固定的に割り当てる場合より帯域の利用効率は向上するものの、図 4.1.2 のように、バースト的な帯域要求が発生した場合に対応できない問題がある。もし、全体の帯域に余裕がある状態で急に大きな帯域を要求するフローが発生した場合、時間方向に全体の要求をならせば、全ての処理が可能であるのに、先行するフローが予約した帯域を開放しないため、図 4.1.2 のような要求が拒否される。
このような帯域要求の損失（呼損）を防止することで、ネットワークの回線の利用効率向上と分散処理システム全体の利用効率向上を目指して研究開発を実施している。

- 181 -

帯域

資源獲得要求失敗(呼損)

利用可能
帯域上限
2

余裕帯域2
1

時間
余裕帯域1
図 4.1.4 帯域の無駄による呼損の例

実際の利用帯域
契約以上に利用した帯域

他のフロー発生により利用可能帯域減少
必要帯域を再計算し帯域一部返却

当初契約
帯域

見直し後
契約帯域

再見直し後
契約帯域

図 4.1.5 提案方式によるフローの帯域利用イメージ
そこで、我々の提案方式では図 4.1.3 に示すように、各フローが当初の予定帯域以上のスループットが得られた場合に確保済みの帯域を返却していくことで、空き帯域を作り出し、新たなフローの要求を受理できる確率を向上させようとしている。現在のところ、計算機上のシミュレーションにおいて、他の方式と提案方式を評価しているが、提案方式は呼損率（帯域確保要求の失敗率）では他の方式より有利であり、トータルスループット（単位時間あたりのデータ転送量）でも他の方式と同等以上の性能というデータが得られている。

- 182 -

4.2 拠点連携のためのセキュアな資源共有技術の研究開発
複数の組織によって計算資源 （CPU やストレージ） が提供されて構成された環境では全ての資源の管理を一元化して実施することは困難になる。特に、その環境にアクセスする
人数が増えれば増えるほど資源の追加、削除、移動などが発生し、少数の管理者による手作業の管理は破綻する。現在の技術では資源の追加、削除などは管理者の手作業が必要であり、これが複数組織でのグリッド環境構築の大きな障害となっている。そのため、ユー
ザが自分の権限で資源の追加や削除が実施でき、自分で追加した資源を関係者以外に非公開にできるようなセキュリティ（アクセスコントロール）の手段の研究開発は、グリッド
コンピューティングの普及に大きな意義がある。
本研究項目では、今後ますますその必要性と重要性が高まる傾向にあるセンサーネット
ワーク、グリッドのための技術の研究開発に着目している。カメラ、温度計、湿度といったパラメータのリアルタイムモニタリングを特徴とする小型センサーデバイスを大規模データ処理を目的としたグリッドに統合し、各種サービスを活用することにより、多様な
データ処理が容易に実現できるような資源共有技術の開発を行う。より具体的には、①動的ファイアウォール設定機構、②小型センサーデバイスのための軽量型グリッド接続プロ
トコルの実現、③資源情報通知サービス、と本項目をさらに細分化し、研究開発を推進する。各項目の目的は、次のとおりである。
① 動的ファイアウォール設定機構：
個々のデバイスについて資源管理者の人手によるグリッドサービス化の作業、および、ネットワークセキュリティの対応が必要となるため、ネットワークに追加、削除されるセンサーデバイスの増加に従って、管理コストが大きくなり、タイムリーな機器の追加・削除が不可能となる。本機構は動的にファイアウォールの設定変更を達成するための手段を提供する。
② 小型センサーデバイスのための軽量型グリッド接続プロトコルの実現：
センサーデバイスはそのハードウェアの制約からグリッドミドルウェアを自身で動作させることが不可能であるため、グリッドサービス化されたデバイス機能の公開やユーザ利用時の相互認証処理を代替で行うシステムを外部に必要とする。本項目はこれを実現するためのプロトコルを開発する。
③ 資源情報通知サービス：
遠隔でセンサーデバイスを利用する者に対して、どのセンサーデバイスがその時点で利用可能であるかどうかを一元的に容易に知る手段を提供する。
これらの実現により、従来は環境構築の複雑さゆえ躊躇されていた各種資源を活用したデータ処理が容易に実現でき、各種研究開発や実業務への幅広い適用が期待できる。これまでに、サブ項目①の動的ファイアウォール設定に関する方式の提案、および、プロトタ
イプシステムの構築に成功しており、さらなる改良を目指し研究開発を進めている。
4.2.1 従来技術
グリッド技術はさまざまな資源の組織を超えて相互に接続するために用いられる技術である。これは、システムへの不正侵入の観点で言うならば、グリッド技術を用いて相互に接続された複数の拠点は、一度、ある拠点で外部からの不正侵入を許すと、連鎖的に不正侵入が達成されやすいということであり、サイバーテロのための踏み台や不正なファイル
交換のための場に利用されるといった被害が拡大しやすいということを意味する。各拠点における外部からの不正侵入を防ぐためには、ファイアウォールの適切な運用・管理が重要である。しかし、各拠点のファイアウォールにおいて常に適切なルールが設定された状態を維持することは、次の 3 つのグリッド技術の特徴のために困難である。

- 183 -

図 4.2.1 センサーデバイスを遠隔で利用するための仮想組織
１． アプリケーションによっては外部拠点との通信に用いるポートがジョブの実行時に動的に決定される場合がある
２． 仮想組織は多数の拠点が相互に接続されたネットワーク形態になっており、その構成が常に同じであるということが保障されていない
３． ジョブの実行期間のどの時点で拠点間の通信が発生するかを予測することが不可能である
すなわち、現在のグリッド技術はファイアウォールに対する考慮が十分でなく、広域ネッ
トワークに接続された資源に対して不必要なポートに対しても外部からの接続を恒久的に許可するといった設定がされる傾向がある。そのため、各拠点において外部ネットワーク
からの不正侵入のきっかけを与えるようなセキュリティ状況となることが問題となっている。
セキュアに拠点間を接続するための既存技術の一例として、VPN を構築した上で資源共有を行う方法がある。しかし、VPN の構築はネットワーク層での設定を必要とするために、高度な技術を要する。また、多拠点間を連携する際の柔軟性に欠ける。本研究では、ユー
ザやシステムの運用者に対して高度なネットワーク技術を要求することなく、柔軟に多拠点間で資源を共有するための環境を構築できるようにするため、アプリケーション層による問題の解決を試みる。

- 184 -

図 4.2.2 既存のグリッド技術を利用する場合のファイアウォール設定状況
4.2.2 グリッド技術におけるファイアウォールの設定に関する要求
拠点のセキュリティを維持しつつ、多拠点間で資源共有のための環境を構築する場合、資源提供者のファイアウォールの設定に対する要求は次のようなものである。
①オープンなネットワークに対してはできるだけ資源を曝さない。
②拠点間の資源の共有に必要な接続は許可する。
特に、センサ系デバイスのようなアドホックな外部からのネットワーク接続を伴う資源を共有する場合、その接続・切断のたびに各拠点において常に適切なファイアウォールの設定を行うことは、管理コスト面の問題から困難である。オンデマンドで拠点の外部からのアクセスに対して資源共有のために必要な最小の許可だけをファイアウォールの設定に与え、仮想組織の中であればファイアウォールの存在を意識することなく資源を共有できるようにする技術が求められている。

図 4.2.3 デバイスの共有とファイアウォールの設定- 185 -

図 4.2.4 トランザクション単位で行うファイアウォール制御
4.2.3 提案方式
拠点間で発生する通信に応じてファイアウォールの設定を変更するため、ファイア
ウォールのルール変更の機会をサインオン単位やジョブ単位のような長期に渡る期間ではなく、トランザクション単位とする。
これを実現するため、資源共有の際に発生するトランザクションを正確に検出するための機能拡張を、グリッドミドルウェアの通信ライブラリに適用する方式を提案する。本提案方式は、拠点間の各々の通信の契機だけでなく、接続先の IP アドレス、および、ポートを検出することができる。なお、ファイアウォールの設定を変更するリモートサイトへのトランザクション情報の伝達は HTTP プロトコルを用いて実現する。
この提案方式を図 4.2.5 に示す。ここで、１つのトランザクションに対してグリッドミ
ドルウェアが行う一連の処理は以下のとおりである。
(1) トランザクション発生の直前に接続元の IP アドレス、および、ポート番号といった
トランザクション情報を収集、保存し、接続先のファイアウォールの設定を変更する
ためのリクエストメッセージとしてリモートサイトへ送信する。
(2) トランザクション情報を含むリクエストメッセージは HTTP プロトコルを用いて接続先に伝達される。
(3) リモートサイト側でユーザ認証を行う。
(4) リモートサイト側で受信したリクエストメッセージに含まれるトランザクション情報を元にファイアウォールの設定を変更する。
(5) 接続元から接続先に対して接続を行い、本来の目的の I/O 処理を行う。
トランザクションの終了直後には、上の (1) で保存された情報を取り出し、上記 (2)～(4) を行い、リモートサイトのファイアウォールの設定を元に戻す。
本提案方式に基づくプロトタイプシステムの構成を図 4.2.6 に示す。ファイアウォール
制御通信機構は、グリッド用 API・ファイアウォール制御通信発信機能・ファイアウォー
ル制御通信着信機能を有する。グリッド用 API は、本システムをグリッドシステム （Globus
Toolkit） に連動させるための API であり、グリッドシステムにより呼び出される。ファイアウォール制御通信発信機能は、グリッドシステムが他サイトに接続する場合に呼び出され、他サイトに設置された本開発ソフトウェアに接続し、他サイトのファイアウォールの制御を指示する。ファイアウォール制御通信着信機能は、他サイトに設置された本開発- 186 -

図 4.2.5 グリッドミドルウェアによるファイアウォール制御
ソフトウェアから呼び出され、他サイトのグリッドシステムが自サイトのグリッドシステ
ムへ接続できるよう、自サイトのファイアウォールを制御するためにファイアウォール制
御機構を呼び出す。ファイアウォール制御機構は、ファイアウォール制御通信機構より呼び出され、自サイトのファイアウォールを制御する。
また、これらの機構の状態表示のための GUI と、設定を行うための GUI を有する評価システムを構築した。

図 4.2.6 ファイアウォール制御システム構成図- 187 -

図 4.2.7 設定を行うための GUI

図 4.2.8 状態表示のための GUI

4.2.4 評価
提案方式に基づくプロトタイプシステムは、接続元の要求に応じて拠点間の通信に必要なポート、アドレス、および、期間を制限して接続先のファイアウォールの設定を動的に変更することができる。
Globus Toolkit に含まれる globusrun コマンドを実行したときのファイアウォール制- 188 -

御リクエストメッセージの送受信の様子を図 4.2.9 に示す。 globusrun コマンドを実行したホストと gatekeeper が動作しているホストとの間で、相互に接続・切断のリクエスト
メッセージが交わされ、各々のリクエストに応じてそれぞれのホストで動的にファイア
ウォールの設定が変更される。

図 4.2.9 globusrun コマンド実行時のファイアウォール制御リクエストメッセージ

1～4 ではユーザ認証が行われており、5～6 ではユーザジョブを転送している。
gatekeeper 側でジョブの実行が終了した後、7～10 でジョブの実行結果を転送している。
本提案方式では、ジョブの実行時にグリッドミドルウェアによってファイアウォール制御のための一連の処理を動的に行うため、各拠点のファイアウォールに対しては拠点間の通信に必要な最低限の設定だけを施すことができ、かつ、システム管理者はファイアウォー
ルの存在を意識する必要がない。
従来の方法で、同等のことを実現しようとした場合、(1) ファイアウォールを制御できる機会は人間が管理できる事実上の最小の単位であるジョブ単位であること、(2) 接続許可の対象となるホストは、実際にどのホスト間で通信が発生するかをジョブ実行前に知ることができないのであれば、ジョブの実行が割り当てられるホストすべてが対象であること、(3) 対象となるポートは、ジョブ実行時の拠点間の通信に使用されるポートが事前に分からないのであれば、すべてのポート番号が対象であること、(4) ファイアウォールの設定はジョブの実行に関わるすべての拠点について行われなければならないこと、(5) その際、ジョブを実行するユーザは、そのジョブが利用するすべての資源の管理者らと連絡をとり、ジョブを実行する予定時刻を知らせ、ジョブ終了時にはその旨を知らせること、(6) 各拠点のシステム管理者は、ジョブを実行するユーザからジョブの開始、および、終了の知らせがあるまで待機し、連絡があれば速やかにファイアウォールの設定を変更する
こと、以上すべての処理が拠点のセキュリティを維持するために必要であり、これらを正しく実現することは実際には極めて困難であるということが予想できる。さらに、ジョブの実行が長期に渡る可能性もあることを考えると、ジョブの実行に伴う各拠点のセキュリ
ティの悪化が懸念される。
なお、本提案方式は、資源構成の変更にも柔軟に対応でき、システム管理者の煩雑なファイアウォールの設定作業を削減できるため、センサーデバイスを共有して利用するような場合に特に有効である。

- 189 -

4.2.5 まとめ
セキュアな拠点間の連携を実現する動的ファイアウォール制御技術の開発とその有効性を検証した。提案方式である動的ファイアウォール設定機構は、連携した多拠点間でアプ
リケーション要求に応じてファイアウォールの設定を動的に変更するための機能拡張をグ
リッド通信ライブラリに適用することで、アドレス、ポート、期間を限定する細粒度のファ
イアウォールの接続許可の設定を可能にする。提案方式に基づくプロトタイプシステムでは、ミドルウェア層によるファイアウォール制御のための一連の処理が、ユーザにファイ
アウォールの存在を意識させることなく、多拠点間での連携をセキュアに実施できることを検証した。
今後は、提案中の動的ファイアウォール設定機構の実用化に向けて、ファイアウォール制
御のセキュリティ向上、および、ファイアウォール製品への適用範囲の拡大を図る。多拠点の連携においては認証の連鎖によって一連のジョブが達成されるため、ファイアウォー
ル制御においても GSI による認証機能を拡張することを検討する。また、仮想組織内の資源の柔軟な構成変更と資源運営の利便性向上を図るため、資源共有の設定の自動化の手法を検討する。
また、今年度の成果を元に、センサーデバイスのグリッド環境への組み込み方式を検討し、利用者がそれを利用するための手段を検討していく。

- 190 -

4.3 広域ネットワークにおける大規模データ処理連携技術の研究開発
近年の傾向として、分散計算において取り扱うデータの大容量化が進行し、ひとつの組織で準備できる計算能力を超える処理が必要となる状況が起こりつつある。これに対応するため、グリッドでは仮想組織 （VO; Virtual Organization） を構成するが、これらの組織間を広域網で接続して、計算データを他組織へ転送する。従って、この広域網を利用した転送性能が計算性能に大きく影響する。
特に、観測を継続しながら観測装置から出力されるデータを処理する場合、データの処理速度が実験のターンアラウンドに直結するため、各処理に時間的な制約が存在する場合がある。例えば、テレサイエンスでは、高精細の電子顕微鏡による試料のスライスデータ
や、MRI による人体の断層撮影の画像データ等が観測装置等から発生し、そのデータを実時間で処理することが望ましい。例えば、電子顕微鏡による観測の場合、ひとつの試料あた
り、数十 Mbyte 程度の画像データを 100 以上発生させる。このような要求に対応するためには、データ転送の品質を広域ネットワークにおいて保証することが非常に重要である。
4.3.1 従来技術
拠点間のデータ転送の品質を確保するためには、十分に広帯域なネットワークを利用するか、個別の通信に必要なネットワーク資源を動的に割り当てるかのどちらかの対応が必要である。また、動的に資源を割り当てる場合、割り当ての方法により、最低帯域保証型
サービスを利用するか、固定レート（帯域）を保証するかの 2 つの方法がある。
(1) 広帯域な専用ネットワークの利用
OptIPuter 等では VO を構成するサイト間の接続にダークファイバ等、大容量かつ占有可能な経路を準備することにより、通信品質の問題を軽減している。この方法は非常に高価であり、一般的には適用は困難である。

拠点B
大規模クラスタ
拠点C
並列計算機
並列画像処理拠点A
観測装置等

3次元画像合成
広域網
広域網

測定データ
逐次送信

拠点D
ユーザ利用PC

結果の表示と保存
図 4.3.1 広域網を利用した処理の例- 191 -

図 4.3.2 Diffserv 概念(2) 最低帯域保証による品質確保
最低帯域を保証する方式として、Diffserv の AF による方法を説明する。図 4.3.2 のように、対象ネットワークを DS ドメインと呼ぶ。DS ドメインと他のネットワークの境界となるDS エッジにおいて事前に設定された情報に基づき、流入する IP パケットのヘッダの情報に従って、パケットの DSCP （Diffserv Code Point）に値を書き込み、DS ドメイン内に転送する。
DS ドメイン内部の装置（コアデバイス）では、各 IP パケットの DSCP の値に応じて各パケットに対する操作を差別化することで品質を制御する。AF では、図 4.3.3 に示すように、ユーザとネットワークの間で保証する帯域を事前に契約する。次に、流入するパケットの流入量をエッジルータにおいて監視し、契約帯域内のパケットは IN に、契約帯域を上回るパケットを OUT にマーキングする。DS ドメイン内部のコアルータは、輻輳状態になると OUT
パケットから先に破棄し、IN パケットを極力廃棄しないことで、ユーザに対して最低帯域を保証する。
実際には、帯域の契約段階において、IN パケットが破棄されないように、DS ドメイン内のルータ間のリンク帯域設計を行っておく必要がある。さらに、図 4.3.3 のように、RIO と呼ばれるルータのキュー管理技術では、実際に輻輳状態（ルータの出力バッファのキュー長が規定を超える）となる前に、OUT パケットを先行して破棄することで、TCP のフロー制
御メカニズムを利用し、輻輳を抑制することが可能となっている。
ここで、ファイル転送に対して、フロー単位に AF で最低帯域保障を実施した場合を想定する。ネットワークの利用率が低い場合には、フロー単位に帯域を制御しない場合と同様に、次のような公平性に関する問題がある。
時間差を伴って同一の契約帯域を持つ、2 つの TCP フローが発生したと仮定する。
この場合、先行して発生したフローが余っている帯域の大部分を利用してしまい、要求した帯域に対して実際に得られるスループットは非常に偏ったものとなってしまう。
(3) 固定帯域割り当てによる品質確保
各フローに要求帯域を固定的に割り当てる場合について説明する。図 4.3.4 のように、各フローに対してバッファを割り当てると共に、パケットのスケジューラに対して設定を行い、各フローに対して契約した値のスループットを提供する。この方式でファイル転送に帯域制御を実施する場合、ルータにおいて、制御対象となるフロー数だけバッファを準備すると共に、バッファの長さ等のパラメータ設定を頻繁に変更する必要があり、ルータの負荷が非常に高くなる。また、契約帯域以上のスループットを提供しないため、公平性は確保されるものの、未利用となる帯域が発生し、資源の利用効率はあまり良くない。
そのため、図 4.3.5 のように、帯域に余裕のある場合に空き帯域の利用で、新規フローの要求を満たすことが可能な場合でも、帯域を固定で割り当てているために、新規フローの帯域獲得の要求が呼損となる場合がある。

- 192 -

図 4.3.3

AF サービス

図 4.3.4 固定帯域割り当て

帯域

資源獲得要求失敗(呼損)

利用可能
帯域上限
2

余裕帯域2
1

時間
余裕帯域1

図 4.3.5 帯域の無駄による呼損の例- 193 -

4.3.2 ファイル転送と必要とされる品質
まず、分散計算環境におけるファイル転送に対して実際に提供すべき品質について検討する。新規のファイル転送の発生時の品質確保要求が拒絶された場合、そのファイル転送（呼）のオーナーである Job の処理時間の増加もしくは Job をよりネットワーク資源に余裕のある場所に再割付する必要があるなど、好ましくない結果をもたらす。
また、ネットワークで提供する品質の指定方式としては、ジッタ、遅延、パケットの損
失率の 3 つの指標がある。ただし、専用のネットワークを構成する場合と異なり、一般のISP の環境を利用した場合は経路を指定することができないため、品質の契約時は帯域を指定することとなる。
ここで、あるファイル転送に対して帯域を指定した場合、利用プロトコルとファイルのサイズが既知であるため、帯域の指定は転送の終了予定（希望）時間を指定するのとほぼ同義である。さらに、ファイル転送は非インタラクティブトラフィックであるため、各フローに対して保証するスループットを契約した帯域をフローの生存期間中、常に一定にする必要はない。実際に保証する品質は、フローの生存期間の平均で契約した条件を満たしていれば良いと考えられる。
以上の議論から、Job と初期に契約した帯域を目標スループットと捉え、そのスループッ
トを確保しつつ、全体の帯域を有効に利用することで、新たな帯域確保の要求をより多く受け入れることができれば、CPU も含めた全体の計算資源を有効に活用することが可能と考えられる。
4.3.3 提案方式
個別のフローに対して AF で最低帯域を保証しつつ、呼の開始時に契約した帯域をファイルの転送が進むにつれて、見直す方式を提案する。
(1) 提案方式概要
本方式は図 4.3.6 に示すように帯域を利用し、定期的に必要帯域を見直して、契約帯域を徐々に削減する。図 4.3.7 は本提案方式の実現例である。ファイル転送の発生時に、送信側端末はルータを管理するサーバに要求帯域を通知し、帯域を契約する。サーバはルータの設定を変更し、フローに最低帯域を保証する。また、個々のパケットに対してはエッジルータにおいて、契約帯域内かどうかでマーキングを実施する。
本方式では、AF を用いたフローに対する最低帯域保証に加えて、予定以上にスループットを得られた場合に、契約帯域を削減していくことで、以下のような効果を得ることを目指している。
個別のフロー単位で最低帯域保障を実施することにより、経路の帯域に空きがある
場合の利用効率を向上させる。
総契約済み帯域を低く抑えることにより、新たな呼の受理可能性を増加させる。
(2) 帯域の見直し手法
提案方式では、想定した帯域以上にスループットが得られた場合にのみ、契約帯域の見直しを実施する。そのため、契約帯域の増加はないので、各フローがいったん契約した帯
域はフローの終了まで維持されるか、減少するかしかない。よって、帯域要求の失敗による呼損はフロー発生時しか起こりえない。すると、帯域の再契約処理は残りデータを転送しながら実施してもかまわないため、帯域見直しに伴うデータ転送の中断は発生しない。
なお、本提案手法では、事前に定められたブロックサイズ分だけファイル転送が終了した時点で必要帯域の見直しを実施する。

- 194 -

実際の利用帯域
契約以上に利用した帯域

他のフロー発生により利用可能帯域減少
必要帯域を再計算し帯域一部返却

当初契約
帯域

見直し後
契約帯域

再見直し後
契約帯域

図 4.3.6 提案方式の帯域利用法(3) 契約済み帯域確認、受付制御(7) フロー削除
管理サーバ

制御情報

(2) 帯域確保申請(6) 帯域開放申請(4) 契約帯域、フロー情報通知(8) 契約帯域開放指示発信クライアントルータ(4) データ送信(1) 必要帯域計算

データ

ルータ

着信
クライアント(5) フロー単位でAFでマーキング

定期的に必要帯域再計算、利用帯域削減

図 4.3.7 提案方式の実現例(3) スループットの予測と契約帯域の算出方法
契約帯域の見直しには、要求した帯域に対してどの程度の性能が得られたかを計算する必要がある。TCP ではフローに対して帯域を契約していても、その性能が得られない。そのため、期待できるスループットを計算し、その値に基づいて必要帯域の見直しを行う。
契約帯域とスループットの関係
まず、輻輳回避フェーズにおける TCP の性能について議論する。TCP の挙動は単純化す
ると、パケットの破棄により、ウィンドウサイズが 1/2 となり、そこから 1RTT 時間毎にウィ
ンドウサイズが 1 パケットサイズ分だけ増加するという動作を繰り返す（図 4.3.8）。また、
パケットロスによるウィンドウサイズの変化の 1 周期分の様子を図 4.3.9 に示す。
次に、各種の変数を以下のように定義する。
T : 経路の RTT （秒）P : パケットサイズ（byte）
B : 契約帯域（bps）
Wmax : 可能な最大ウィンドウサイズ（byte）

Wmin : 小さくなったウィンドウサイズ（byte）- 195 -

ウィンドウサイズ

ウィンドウサイズ

Wmax

Wmin=Wmax/2

平均スループット=台形の面積/1周期の時間
時間

時間

図 4.3.8

図 4.3.9

TCP のウィンドウサイズの変化

ウィンドウサイズ変化（1 周期分）すると、ウィンドウサイズの回復に必要な時間は式(1)で表すことができる。
(Wmax Wmin )T / P(1)
さらに、最大のウィンドウサイズ、最小のウィンドウサイズの関係は式(2)であるので、この区間での平均スループットは式(3)となる。

Wmin
S

8(WmaxWmax / 2 (2)Wmin ) / T

6Wmax / T （bps）(3)

Wmax （byte）のデータが T （秒）の間に、経路を流れて、それが可能な最大帯域となる
ことから、契約帯域 B と Wmax の関係は式(4)で計算できる。

Wmax

BT
（byte） (4)8すると、スループットは以下の式(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 を比較して、再契約が可能かどうか決定する。

- 196 -

4.3.4 評価
定量評価は NS2 によるシミュレーションで実施するが、現在のところは以下の 2 つの評価を予定している。
単位時間あたりの、実際に送信が終了したデータ量 （性能）
単位時間あたりの新規に発生したフロー（呼）の帯域確保要求が失敗する確率 （呼損率）
さらに、提案方式と比較する対象として以下の 2 つの方式を予定している。
個別フローに最低帯域保障のみを実施する方式
個別フローに固定の契約帯域を割り当てる方式(1) 評価モデル
図 4.3.10 と図 4.3.11 は評価モデルである。評価モデルには、広域網を構成するネット
ワークとファイル転送のフローの性質の条件の 2 つがあるが、ネットワークに関しては、
JGNⅡを想定し、アクセス網、基幹網共にギガビットレベルのネットワークを設定している。
また、発生するファイル転送に対しては以下のような性質を想定している。
フローの発生確率
多数のユーザが同時に利用する環境を想定した場合、各ユーザは独立に Job を投入するものと考えることができるため、現在はフローの発生時間間隔を指数分布としている。
ファイルサイズテレサイエンス分野の画像処理アプリケーションでは、処理対象の画像サイズは 1 枚あたり数十 Mbyte、場合によっては 1 画像あたり 100Mbyte を越える。観測器装置の品質や測定対象の形状により、データ容量は異なるものの、本評価では平均 100Mbyte の Pareto 分
布を利用し、10Mbyte から 100Mbyte 程度のファイルを多数発生させ、かつ極少量ながらGbyte を超えるようなファイルの転送を発生させている。
図 4.3.12 に実際に発生した各フローのファイルサイズの分布の例を示す。このグラフを見てもわかるように、20Mbyte 前後に多くのファイルが集中しており、最大では 26Gbyte のファイルも存在し、全体として平均は 94Mbyte 程度となっている。

発生確率 : 指数分布に従う時間間隔で起動
ファイルサイズ : paretoで生成(平均100Mbyte)
初期要求帯域 : 一様分布 (min 1mbps～)

バックグラウンド
トラフィック発信
クライアント1Gbps 1ms
DropTail

1Gbps 1ms
DropTail
クロストラフィックは
すべてRed1Gbps 1ms

1Gbps 1ms
DropTail

1Gbps 1ms

フロー単位でAFでマーキング

着信
クライアント1Gbps 1ms

1Gbps 5ms

1Gbps 1ms

RIO

図 4.3.10 AF（最低帯域保障）方式の評価モデル- 197 -

1Gbps 1ms
Drop Tail発生確率 : 指数分布に従う時間間隔で起動
ファイルサイズ : paretoで生成(平均100Mbyte)
初期要求帯域 : 一様分布 (min 1mbps～)

発信クライアント1Gbps 1ms
DropTail

1Gbps 1ms

1Gbps 5ms

CBQで各フローのレートを契約帯域で規制

DropTail

1Gbps 1ms

着信
クライアント1Gbps 1ms
Drop Tail

図 4.3.11 従来方式の評価モデル

ファイル転送が要求する初期帯域
今回の評価モデルでは、ルータの処理遅延等を除いた純粋な経路の RTT は 18ms とした。
RTT の値が 18ms で、経路の物理的要因によるパケットの損失確率を 10 12 と想定した場合の1 本の TCP コネクションが出しうる最高性能は約 8Mbps 程度である。そのため、今回の評価
では呼の発生時に、1Mbps～8Mbps の間の一様分布の乱数を発生させ、各フローが要求する初期の要求帯域として利用している。
その他の項目
要求帯域の見直しのタイミングを定めるファイル転送のブロックサイズは 20Mbyte としている。さらに、ファイル転送には ftp を想定し、1 つの TCP フローでデータを転送するとともに、ウィンドウサイズ等は標準の TCP の値を利用している。

図 4.3.12 ファイルサイズ分布- 198 -

ただし、大規模な環境では、広帯域かつ、遅延の大きなネットワーク（帯域と遅延の積の大きなネットワーク）でデータ転送の性能を引き出すために、TCP のウィンドウサイズを変更したり、データ転送に複数の TCP フローを利用したりする対策も行われている。そのため、標準的な TCP によるシミュレーションの他にウィンドウサイズを変化させた TCP を利用した場合や、複数の TCP を利用した場合の比較や、転送するファイルおよびデータ転送の 1 ブロックのサイズを変化させた場合の評価についても現在検討している。
(2) 評価状況
現在、データ転送に 1 つの TCP セッションを利用し、バックグラウンドトラフィックがある場合と、インターネットのトラフィックを意識した分布をもつ UDP トラフィックが存在する場合の 2 通りについてシミュレーションにより以下の 2 種類のデータを収集した。
スループット : 測定時間内に発生し、かつ同時間内に終了したファイル転送の転
送データ量の総和を単位時間で割ったもの
呼損率 : ファイル転送（呼）のうち、ネットワークの帯域不足により、帯域契約に失敗した呼の率
呼損率
図 4.3.13 と図 4.3.14 にバックグラウンドトラフィックがある場合と無い場合のそれぞれの呼損率を示す。呼損率で重要となるのは、呼損が継続的に発生する負荷が各方式でどれぐらいになるかである。バックグラウンドトラフィックの有無にかかわらず、提案方式（実線）は呼損率のグラフが立ち上がるのが一番遅い（大きい負荷も呼損させない）ことが読み取れる。つまり、アプリケーションレベルで見ると、同一のネットワーク資源で単位時間あたりより多くの処理を実行可能であるになる。

図 4.3.13 呼損率 バックグラウンドトラフィック無し- 199 -

図 4.3.14 呼損率 バックグラウンドトラフィック有り

図 4.3.15 スループット バックグラウンドトラフィック無し- 200 -

図 4.3.16 スループット バックグラウンドトラフィック有り

スループット
図 4.3.15 と図 4.3.16 のグラフはバックグラウンドが無い場合と有る場合のスループッ
ト（単位時間あたりの総データ転送量）である。提案方式と契約帯域の見直しの無い最低帯域保証での方式は固定的に帯域を割り付ける方法に比べて良い性能である。しかし、この二つの方式の差はあまり無いものの、ごくわずか提案方式の方が負荷の大きい領域で性能がよくなっている。
呼損率のグラフとスループットのグラフを見比べると、3 つの方式のグラフが分岐する場
所は呼損率が立ち上がる地点とほぼ同じであり、呼損率の差がスループットの差に出ていると考えられる。
4.3.5 まとめ大規模な DataGrid 等の分散計算のアプリケーションを想定した、ネットワークの品質保証方式および、実施中の定量評価の評価方法、評価モデルについて報告した。現在複数の従来方式と提案方式の定量的評価をすすめている。
今後は方式のチューニングを進めて、さらにデータ収集を大規模に実施して詳細な評価を実施する。なお、具体的なアプリケーションの動作について詳細に把握するため、他の研究グループと共同で実際のアプリケーションの発生する通信の統計情報も実環境を用いて収集することも計画している。

- 201 -

参 考 文 献[1] 野呂正明, 長谷川一郎, 馬場健一, 下條真司, “Grid における大量データ送信に適した品質保証方式”, 電子情報通信学会技術研究報告 IA2004-22, pp. 21–16, January 2005.
[2] T. Li, Y. Rekhter, “A Provider Architecture for Differentiated Services and Traffic Engineering(PASTE)”, RFC2430, October 1998.
[3] K. Nichols, S. Blake, F. Baker, D. Black, “Definition of the Differentiated Services Field (DSField) 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, “An Architecture forDifferentiated Service”, RFC2475, December 1998.
[6] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, “Assured Forwarding PHB Group”, 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 performanceover 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/- 202 -

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

第5章
5.1

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

JGN Ⅱ研究開発プロジェクトのテーマⅣ「プラットフォーム・アプリケーション技
術に関する研究開発」では，映像等大容量ブロードバンド情報の有効活用を実社会で実現させることを目指した研究開発を行っている．この目標のために，以下の３つのサブテーマを設けて，実施している．
アプリケーションごとに最適な運用管理を可能にするプラットフォーム技術について「アプリケーション指向型運用管理プラットフォーム技術の研究開発」を東北RCで実施している．これは，アプリケーションを強く意識し，アプリケーションが求める的確なネットワーク情報を，必要十分な品質で，オンデマンドに提供する運用管理プ
ラットフォーム技術の開発を行うものである．今年度は，アプリケーションごとに最適な運用管理を可能にするプラットフォーム技術について，ネットワーク情報の計
測・収集を行うための実験環境の構築及び基礎検討を行った．
ネットワーク上に分散する資源の自由な活用を図るとともに効率的な情報転送・再現のための信号処理の技術について「サラウンディング・コンピューティング技術の研究開発」を高知RCで実施している．これは，大量に転送される情報，特に映像情報が容易に利用できるよう，利用者が自然に情報を活用できるようなシームレスなネッ
トワーク環境の実現を目指し，ネットワーク上の分散資源の自由な活用を図るための技術及び映像情報転送・再現のための処理方式の研究開発を行うものである．今年度
は，ネットワークに分散する資源の自由な活用を図るとともに効率的な情報転送・再現のための信号処理の技術について，サラウンディング環境におけるネットワーク構成の検討，RFIDを用いた実験環境の構築，基礎的データの収集を実施し，信号処理ア
ルゴリズムを開発した．
リアルタイムで遠隔地の映像とマーカ情報に身体動作等を組み合わせて合成・制御
するコミュニケーション技術について「高度 HCI 技術を活用した適応型サービス制御の研究開発」をつくばRCにおいて実施している．これは，実世界のマーカ情報や遠隔地のリアルタイム映像といった様々なブロードバンド情報を伝送し，ユーザーに利用
しやすい形で統合してサービスを展開するプラットフォーム技術及びシステムやネッ
トワークが遠隔地の環境や状況を自動的に把握し，ユーザーの行動をもとに遠隔地に存在する機器の制御等が可能になる技術の研究開発を行うものである．今年度は，リ
アルタイムで遠隔地の映像とマーカ情報に身体動作等を組み合わせて合成・制御する
コミュニケーション技術に関しては基礎技術の開発，研究機材一式の製作，地域密着型の研究開発を実施した．

- 203 -

5.2

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

5.2.1
5.2.1.1

超高速大規模ネットワーク向きネットワーク計測・解析技術の開発
Detecting Events from monitored data in a wide area network(1) Introduction
Network traffic monitoring is an important aspect of network management and security.
Monitoring by itself is not a goal. The monitored data needs to be processed and analyzed to knowwhat needs to be looked at and where. To give an example, some observations may reveal the effectsof events such as a network failure, and operational failure or a security incident, on network traffic.
There are several other usages of network traffic monitoring: like in QoS estimation, bandwidthplanning etc.
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-Ⅱ network. To evaluate the model we havedeveloped a set of tools to aid the analysis of data, both online and offline. This model will be used
to detect events of interest and we will then 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 task of monitoring a network may turn out to be non-trivial due to the complexity andtedious configuration requirements. To simplify the task of configuring a network monitoring system,
we have developed Switch monitor configuration system that aids the network administrator in
configuring the monitoring system.
We have developed Piped NetGrapher to aid online visualization of (traffic) data generated byapplications. The Summary statistics is generated by Summary Traffic Data module. The output is in
CSV format and can be easily visualized using standard tools. To trace the source of (unauthorized/interesting) traffic across a layer-2 network, we have developed Traffic Tracker Bar Graph (TTBG)
system, which shows the port-wise traffic of a switch. The Event Detection and Management system
is used to define events and detect them both online and offline.
Our final goal is to provide a wide spectrum of users with information on events of interest. The
target for H16., modeling and analysis of events of interest and experimentation with real data toevaluate/refine the model, has been met.

(2) Switch Monitor Configuration
Switch Monitor Configuration application enables the user to collect the interface/port
information from the switches and creates configuration files for monitoring these Interface/ports.

- 204 -

conf

MO-ListSwitch List

Switch Monitor
Configuration
Application

Poller Conf Dir as
Argument

UI Notification

ConsolePoller
Conf
SNMP
Agent

User Interface

Fig. 5.2.1-1 Switch Monitor Configuration¾ MO- list and Switch- list are the inputs with Poller Configuration Directory as theargument.
¾ Application can be started either in the User Interface mode or on Console.
¾ If started on UI mode, allow user to select /deselect MO and Interface¾ Switch Monitor Configuration Application collects these inputs and generates Poller
Configuration Files for all these selected MOs and Interface.

Fig. 5.2.1-2 Switch Configuration U/I(3) Piped NetGrapher
Piped NetGrapher (P-NetGrapher) can take data from standard input or from a data file.

- 205 -

Conf File

P-NetGrapher

Definition
file

Data
Archive
Index
File
NetGrapher

Fig. 5.2.1-3 Piped NetGraper¾ Select the GraphType : RawData, Hourly, Daily or Monthly.
¾ Input the MO Name in the field- Select Add¾ Group them.
¾ Specify whether it needs to be Auto Time Generation, by checking the box.
¾ Provide the Host name and Domain name.
¾ Specify whether it needs to be File Based System.
¾ Click on Apply to save the data
¾ Click Discard to delete the input data.

Fig. 5.2.1-4 P-NetGrapher UI(4) Summary Traffic Data
The raw data is the result of sampling at 60 second intervals. This raw data is processed to- 206 -

generate statistics. The statistics has an aggregation level and an output periodicity.
- aggregation level: The level to which the statistics may be aggregated.
e.g. hourly, daily, weekly, monthly, yearly.
- output-periodicity: the periodicity at which the statistics will be generated –e.g. Hourly, Daily, W-daily, M-daily, Weekly, Monthly, YearlyThis application processes the data and gives the Total, Maximum, Minimum, peak and Mean inrequired format to the User.
Existing Monitoring Environment

Traffic
Archive
Target module to develop
parsingArchive

Output traffic
summary

DisplayFile
area1: max xxx, min xxx, peakxxx, mean xxx
area2: max xxx, min xxx, peakxxx, mean xxx

Fig. 5.2.1-5 Summary Traffic Data

Fig.5.2.1-6 Summary Traffic Data UI- 207 -

400000

350000300000250000FridayM onday
Saturday
SundayThursdayTuesday
W ednesday

200000150000100000

50000

0
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

W ednesday
Tuesday
T hursday
SundaySaturdayM onday
Friday23

Fig.5.2.1-7 Summary Traffic data visualization - Web-traffic (octets/hour)
500000450000400000350000300000FridayMondaySaturday
SundayThursdayTuesday
Wednesday

250000200000150000100000
50000
0
1

2

3

4

5

6

7

8

9

10 11
12 13

14

15

16

17

18

19

20

21

22

Wednesday
Tuesday
Thursday
SundaySaturdayMondayFriday23

Fig.5.2.1-8 Summary Traffic data visualization - Mail-traffic (octets/hour)

300000250000200000FridayMondaySaturday
SundayThursdayTuesday
W ednesday

150000100000

50000

0
1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

W ednesday
T uesdayThursday
SundaySaturdayMondayFriday23

Fig.5.2.1-9 Summary Traffic data visualization - Others (octets/hour)- 208 -

(5) Traffic Tracker Bar Graph
Traffic Tracker Bar Graph (TTBG) module displays the traffic of related ports of a

specifiedport. Related ports of a specified port are the ports of the switch to which the specified port isconnected. Please refer to functional specifications for example and more details.
TTBG Applicationmap(cf and disp)

Map Display
TTBG Panel

Data Collector
No

SNMPDataCollec
tor

JPOLLER

ColorCodeYes
mographPollerDataCollect
or

SNMP
Agent

OnlineDBReader

Fig.5.2.1-10 Traffic Tracker Bar Graph

Fig.5.2.1-11 Traffic Tracker Bar Graph UI(6) Event Detection and Management- 209 -

In routine network monitoring, the interest is in events. If there are no events of interest, thenetwork manager will probably not want to "look" at the traffic. The traffic data in such cases is
destined for archiving. From there it will probably be backed-up on off-line media or discarded.
Present monitoring systems do not have a mechanism of detecting events of interest. So it
appears that the operator will either look at all the traffic to detect events of interest or will not lookat the traffic at all. In this work we define events of interest in terms of changes in the statistics andthe 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-eventse.g. an experimental session between two points over which several micro-events ora data-streaming activity takes place. A network fault may also be noticed as an event, where thetraffic suddenly drops to zero, or the RTT abruptly changes. We attempt to mechanically detect such
events of interest and draw the operator’s attention to these events.
This Application detects events based on rules provided. From the event report, an operator candirectly visualize the relevant traffic information graph.

Event Information Servicing
Network Management System

Network Information
Warehouse
InformGraph Generator

Event List Generator

Show traffic graphs

Event List
Time

Where

Description

2004/04/16

A point

TCP SYN Flooding

2004/04/17

B point

DDoS for Web Servicing

2004/04/17

C point

Network Equipment is down

Fig.5.2.1-12 Event Detection and Management- 210 -

Fig.5.2.1-13 Rule definition UI

Fig.5.2.1-14 List of Alarms

Fig.5.2.1-15 Traffic graphs corresponding to the event- 211 -

(7) 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-Ⅱ network. To evaluate the model, we have developed a set oftools to aid the analysis of data, both online and offline. This model will be used to detect events ofinterest. 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 with information on eventsof interest. The target for H16., modeling and analysis of events of interest and experimentation withreal data to evaluate/refine the model, has been met.
5.2.1.2 An Engineering Approach to Dynamic Prediction of Network Performance from
Application Logs
(1) Introduction
In some works the authors show network past history may be an excellent source for estimating
network behavior in the future. However, except presenting a gross measurement, that is, normal
statistical average over different time slices of the 24 hour day and inferring that network throughput
has some relation with the period at which it operates, no further analysis was made. Since mere
statistical averages are prone to error induced by non representative data, the outliers, thisinformation is not enough for deployment purposes. This is revealed clearly in Figure 5.1.2-16.
Here, we plot the average and median of network throughput between two networks (RIEC-net andgoo-net) at different times of a day computed over a month (March 1998). This clearly indicates thatat least in fifty percent of the cases, average overestimated the network throughput.

Fig. 5.1.2-16 Comparison of average and median of network traffic
In this report, we therefore propose a model for prediction of network performance thatconsiders median as the base statistics.

We then take help of standard statistical tools likepercentiles, quartiles, SIQR (Semi Inter Quartile Range) and their aggregates. Since we propose an- 212 -

engineering approach to network performance prediction based on network measurements, rather
than a complex mathematical framework, our model introduces some new heuristic based operators
similar to the basic Genetic Algorithm (GA) operators. These new operators and associated actions
will be referred to by the same name as their GA counterparts in this text.

(2) Our Estimation Model
As stated before, the essential requirement of a measurement based dynamic network
performance prediction mechanism is to have practical significance. Internet traffic has acontinuously varying pattern. Therefore, predicting a single value to represent network throughput in
immediate future is almost meaningless. This fact leads us to propose a range based prediction
model. The idea is to make prediction of a range within which we wish our network to operate. At
the two ends of this, lie Optimistic Network Performance Index(ONPI) and Robust Network
Performance Index(RNPI) which we describe later. The reason for using the term performance index
is that, in addition to predicting network throughput, this model can be used for other network
performance parameters like round trip delay etc. In this report, we however, focus on network
throughput only and the term performance index would correspond to throughput in a network.
Our model essentially depends on continuous measurement of network throughput. We consider
both the historical network traffic information as well as immediate past network traffic information
to forecast a meaningful range for network throughput in immediate future. This type of prediction
can enhance the performance of various applications over the Internet quite significantly.
A. Definitions and Assumptions
We are using median of network performance indices as our base statistics. This gives us anestimate of the central tendency of observed data. At the same time, it helps us wiping the outliers
away from active considerations. Once we have chosen the measure of central tendency, we needsome way to characterize the measure of dispersion. There are many ways like range,
variance/standard deviation, mean absolute deviation, semi interquartile range etc. for the
purpose. Among them, semi interquartile range or SIQR is very much resistant to outliers. Similar istrue for percentile ranges. We have therefore used percentile ranges in our mathematical framework.

- 213 -

Fig.5.1.2-17 Medians of network traffic at different times of different days of the week
Figure 5.1.2-17 shows median of network throughput on different working days of a week at
different times of each day. From this figure we easily observe that at a particular time of each day,network throughput follows similar patterns for different working days of a week. We also inferthat operating period is one of the parameters governing network performance. We consider
this time dependence dividing them into discrete time slices, △t. The length of these time slices
may vary depending on the requirements. We may also consider variable time slices △t for some
applications. For the sake of easy representations, from now on, we shall refer to different time slices△t as t, t+1,t+2 and so on. We can have many observations l, l-1, l-2, etc. at the past for the same
set of time slices. Similarly, we can have many observations l+1,l+2,l+3 etc. for the present and also
the future for the same set of time slices.
In this model we consider two types of time dependence. One is the historical dependence of
network throughput for a particular time slice t. The other one is the dependence on current state of
network throughput.
In our mathematical model, we have taken the first type of dependence into account through thehistorical factor ht,l+1. The idea is that at time slice t in observation l+1, network throughput should
show a behavior close to some derivation from several past observed behaviors of the network
throughput at the same time slice, t.
The second category of time dependence stands for the effect of currently obtained network
throughput. The idea is, if at time slices t-1,t-2,t-3 etc. in observation l+1 we have some amount of
network throughput, the probable throughput at time t may be partly characterized by thoseobservations. This is a sort of rolling over of network performance from one time slice to another.
Therefore we call the effect as the roll over factor. In our current approach, the roll over factor has- 214 -

been considered to be determined by a roll over function. The roll over function itself is considered
to be depending on the characteristic function, gt(l+1) and the roll over ratio ρt(l+1). In this model,
we have assumed a simple characteristic function considering dependence on only one time slice t-1
at observation l+1 as follows,

Generally, there is some dependence between two different time slices. However, we have notedthat at certain point in time, there is no relation between performance index at some time slice with
the next time slice.
It is also observed that at times the network performance shows some abrupt changes. We haveintroduced a 'dynamic cross over operator' described later in the report to adjust to the abrupt change
in network behavior.
In our model, instead of estimating some single value to be the expected network performance,
we have introduced a new concept of predicting a range within which we wish network throughput
would probably be in. At two ends of this range, lie the Optimistic Network Performance Index(ONPI) and the Robust Network Performance Index (RNPI). If the network operates at nearly thehighest efficiency, the throughput would be near ONPI. Of course, the fraction of time whenthroughput can be this high would be small. On the other hand if the network operates nearly at its
normal efficiency, i.e. at least at an efficiency which is expected in most of the cases, then network
throughput would be near RNPI. Most of the time the network is expected to operate near this value.
We may consider ONPI and RNPI to be analogous to the first and third quartiles or 10 and
90-percentiles respectively and so on. ONPI and RNPI vary with time and load on the network.
Therefore, if we need to know what at the least should we expect the network throughput be at an
instance of time, we should consider RNPI as our index. To the contrary, if some applications are toomuch sensitive to network bandwidth availability,
ONPI should be used as the predicted network throughput.
B. Mathematical Modeling
Using the mathematical framework and assumptions described in the previous subsection, we
employ techniques having some resemblance with those of Genetic Algorithm to predict our
performance indices.
In our model, we consider the statistical parameters of interest to be genes of a chromosome. We
may look upon a chromosome, ct,i corresponding to the statistical parameters of interest at time slice
t in observation I to be a vector as follows.
ct,i = (mt,i,sot,i,srt,i,nt,I)- 215 -

Here,
mt,i: median of performance index at time t in observation i
sot,i: optimistic performance index at time t in observation i
srt,i: robust performance index at time t in observation int,i: number of accesses at time t in observation isot,I and srt,I may correspond to10 and 90-percentiles or the first and third quartiles. In this text,
we consider the former pair, i.e., the percentiles. Number of accesses, nt,i, indicates
representativeness of the data in consideration. A higher value of nt,i assures a higher weight forcorresponding historical performance data.
Once we have our chromosomes defined, we can describe the alive population as a matrix as

Therefore, at time t, we have l numbers of chromosomes in the alive population. That is, eachrow i of Pt corresponds to an observation i for the time slice t. The ages of different chromosomes
differ. We are considering a model of fixed alive population. Then, in order to accommodate places
for newly born offsprings, the old ones have to die. Here, a new offspring, forexample ct,l+1

corresponds to a new observation l+1 for time slice t. The chromosome that dies due to the inclusionof a new offspring normally goes beyond our active consideration.
In order to obtain the prediction of network performance for observation l+1 at time slice t, wenormally employ a subset of all these observations or chromosomes. Therefore, we will use a
sub-matrix of Pt to be our learning set or learning window. The learning window can be defined as,

In order to account for the first type of time dependence, we use a strategy that the nearest pastbears the closest resemblance with the immediate future. As such, while generating the statistics
indicating historical time dependence}, we assign highest preference on the chromosome
corresponding to the nearest past for a fixed time slot. In doing so, we use the following normalized
weight vector P,
P= (pl-w+1,pl-w+2,…pl)- 216 -

We then compute the historical time dependence, ht,l+1 as the product of normalized weightvector p and the learning set, Wt.
ht,l+1= p.Wt
The second type of time dependence, i.e. the roll over factor, rt,l+1 may be computed with the aidof roll over function, which itself depends on several parameters. These are, the roll over ratio, ρt,l+1
defined as,

the characteristic function gt(l+1) and the chromosome ct-1,l+1.
The vector roll over factor, rt,l+1 can then be defined asrt,l+1= ρt,l+1 *gt(l+1) *ct-1,l+1
The roll over factor, however influences our prediction model depending on its importancedetermined by the following parameter,
nA,l+1= nt-1,l+1
which will later be normalized for actual prediction. Here nt-1,l+1 corresponds to the chromosome
ct-1,l+1. The implication of taking this number of accesses into account is that the roll over factor
would be more meaningful if there is more number of accesses and less meaningful if there is lessnumber of accesses.
The other factor involved in this process is,
nÀ,l+1 = median {nt,i | 1 ≤ i ≤l }We then define the roll over weight as follows,

mutation: Once equipped with the above tools, we describe prediction as a mutation of all genes inthis case, in the chromosomes of learning set, Wt and ct-1,l+1. That is, all chromosomes concerned inthis case change to some extent and thus we have the prediction vector,
vt,l+1 = (1- at,l+1) *ht,l+1 + at,l+1 * rt,l+1
It is worth noting that we have employed a somewhat new type of mutation to have an estimate
for prediction. In ideal case, the prediction vector vt,l+1 should be close to the vector corresponding to
the chromosome for actual observed performance, i.e. ct,l+1
birth and death: Using mutation, we had an estimate or prediction of how the network is expected
to behave. Then as we observe the actual performance, we have a new chromosome ct,l+1. As
mentioned before, similar to the natural process of life and death, the oldest chromosome dies in- 217 -

order to make room for the new chromosome in the alive set. The implication is to emphasize on thelatest set of network performance information for use in future. The matrix corresponding to thealive population set after one such birth-death process is as follows,

The learning set after a birth and death process would also change accordingly as,

cross-over: Sometimes, network performance changes abruptly. Then it is likely that the prediction
model would not be able to provide so good an estimate of the throughput. Mathematically, we shallcall an estimate to be not so good if the difference between the predicted and actually observed
chromosomes, dt,l+1
dt,l+1 = | ct,l+1 - vt,l+1|
exceeds some threshold T, i.e., dt,l+1 > T
In such cases, if dt,l+1 remains high for a considerably long time, a cross over would take place.
The idea is to replicate all the genes of the latest chromosome} in the oldest ones in the learning set
excluding the one corresponding to number of accesses. Then the system is tested for determining
whether dt,l+1 is below the threshold value. If not, the process issuch iterations has limit at therepeated. However, the number ofwindow size. The value of T could be some α percent of vt,l+1.

The matrix for learning set after one birth and death and one cross over would be something likeas follows,(3) Experiments and Evaluation
A. Experimental Set Up
Since we propose an engineering approach rather than a complex mathematical one,experimental verification is essential for its validation. We therefore tested our model over a long

- 218 -

time data between several networks. Our model performed equally well in these cases to predict
network throughput dynamically. In the following text, we therefore would focus on only one ofsuch pairs. This particular pair consists of inbound traffic to RIEC-net from goo-net. RIEC-net(riec.tohoku.ac.jp) is an academic network of Tohoku University Research Institute of ElectricalCommunication. Goo-net (goo.ne.jp) is a popular commercial network in Japan providing a variety
of services including free web mail account, important news, advertisement etc.
Data traffic log for downstream traffic between RIEC-net and goo-net for a period of one year
was analyzed. We considered some portion of network trace data as the learning set and tried tomake predictions, using our model, for the the remainder of it. This is done with a view to imitate
real time dynamic prediction of network traffic. We then compare the degree to which thepredictions and the actual values are in agreement. We also analyze the effects of varying learning
set sizes. Furthermore, the behavior of the prediction model facing some abrupt changes in network
performance is also analyzed.
As described earlier, no existing work predict network throughput dynamically like our one. At
the same time, we propose a range bounded by two performance indices rather than predicting one
single value. This is completely new and practical in addressing the problem. Therefore validationand performance comparison of our approach can be made solely with actual data which we present
in the following subsections. We compare our predicted ONPI with 10th percentile and RNPI with
90th percentile of the descending network throughput data.
B. Accuracy of Prediction
We first consider how accurately our prediction model could perform. In presenting our results,
we naturally emphasize on the characteristics of our model for the period of the day when the
demand for network bandwidth is most crucial. A correct prediction for this period is likely to be
more important than any other time. Also, we show the accuracy for a particular day in Figure
5.1.2-18. Other days follow similar convergence characteristics.
Figure 5.1.2-18 shows our predicted RNPI and ONPI network throughput for a particularlearning set size of 8, with broken lines and the corresponding actual values using solid lines. We
can easily notice that both ONPI and RNPI predictions by our model fit quite well with the actual
values. For all the cases, except some abrupt change in network traffic, both ONPI and RNPI matchwithin 10 percent of the actual value. Therefore we can infer that under normal network behavior,
our model works well enough.

- 219 -

Fig. 5.1.2-18 Accuracy of Prediction
One interesting point to note would be that, in case of ONPI, there is a higher difference between
what we expected to see and what we observed actually. However, in case of RNPI, both theprediction and the observation are quite close. This is important because at RNPI, we want a robust
estimate of performance index. The significance is that the reliability of the model increases with theincrease in requirement.
C. Effect of Learning Set SizeIn our experiments, we have observed that size of the learning set often influences accuracy ofthe prediction. More interestingly, although a reasonably large learn set size is essential for optimum
prediction, much large a learning set size may not always be something we should opt for.
In figure 5.1.2-19 we observe that in comparison with a reasonable learning set size, a learning
set with higher cardinality (here l=12) performs worse in predicting both the ONPI and RNPI. It
should still be noted that the down gradation effect caused by too large a learning set is more
prominent for ONPI than for RNPI.

This is good for the users of this model as the error in

predicted RNPI is still near the range of acceptability.

- 220 -

Fig. 5.1.2-19 Effect of Learn Set Size
D. Effect of Abrupt Changes
Any model that learns through experience is not supposed to be predicting well at the occurrenceof an impulse behavior. Therefore, it is quite natural that the accuracy of prediction of our model
suffers when some abrupt changes occur in network performance. Figure 5.1.2-20 shows one such
example. One interesting point to note in this context is that here also, the predicted ONPI differs toa great extent from actual behavior. But on the other hand, the predicted RNPI does not differ thatmuch from actual value. This, once again reaffirms that our model has been working well where it isneeded.

Fig. 5.1.2-20 Erroneous prediction in case of abrupt change- 221 -

However, the model shows some much better characteristics in some other occurrences of abrupt
behavior (Fig. 5.1.2-21) when learning about the abrupt change is achieved fast.

Fig. 5.1.2-21 Abrupt change not affecting the prediction considerably(4) Conclusion
Network performance prediction based on network measurement traces appears to be a daunting
challenge to network researchers. Several works in different contexts have been done in the past.
These contributions, however, mostly focus on devising complex mathematical formulations topredict mostly pseudo-static network behavior in the future. In this report, we address network
throughput prediction to be an engineering problem. The main contribution of this report is to predict
network throughput dynamically for immediate future. Our proposal also considers the practical
implication of prediction. Therefore, instead of following the conventional approach to predict one
single value, we predict a range within which network performance may lie. This range is boundedby our two newly proposed indices, namely, Optimistic Network Performance Index (ONPI) andRobust Network Performance Index (RNPI). This approach has practical implication for various
applications. We examine our model through one year long data transaction between several pairs of
networks. It is found that our model performs quite good in predicting network performance
dynamically. Besides forecasting network throughput, this model can also be a candidate forprediction of other network performance parameters like round trip delay, unidirectional delay etc.

- 222 -

5.2.2

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

5.2.2.1

はじめに

イ ン タ ー ネ ッ ト に 代表 さ れ る ネ ッ ト ワ ー ク シ ス テ ム は ， 利用者数 の 急速 な 増加や利用形態 の 著 し い 多様化 に 伴 っ て 高速化 ・ 大規模化 が 急速 に 進 ん で お り ， そ れ に 伴
っ て ， ネ ッ ト ワ ー ク を 円滑 に か つ効率的 に 運用 ・ 管理す る た め の 運用管理技術 の 早期確立 が 強 く 求 め ら れ て い る ． 従来 の ネ ッ ト ワ ー ク 管理 で は ， ト ラ ヒ ッ ク 量や特性 ，
パ ケ ッ ト ロ ス ， 経路情報 な ど い っ た 下位層 に 重点 を お い た も の が 主流 で あ っ た が ，
利用形態 の 多様化 に 対応す る た め に は ， ア プ リ ケ ー シ ョ ン 層 ま で の 上位層 に つ い ても 考慮す る こ と が 必要 か つ有効 で あ る と 考 え る ． 東北 JGN Ⅱ RC （ 運用管理 グ ル ープ ） で は ， 「 ア プ リ ケ ー シ ョ ン 指向型運用管理 プ ラ ッ ト フ ォ ー ム 技術 の 研究開発 」
を メ イ ン テ ー マ と し て ， (1) ア プ リ ケ ー シ ョ ン レ ベ ル で 通信 の 特性 を 計測 ・ 集約 し ，
得 ら れ た 観測情報 か ら ア プ リ ケ ー シ ョ ン 制御情報 の 抽出 を 行 う ， ま た ， そ れ ら 観測
デー タ を 高効率 で 収集す る ， と い っ た ア プ リ ケ ー シ ョ ン 単位 の ネ ッ ト ワ ー ク 観測技術 ， (2) ア プ リ ケ ー シ ョ ン 特性や利用者活動 を 考慮 し た 知的 な 運用管理 と 大局的 な最適制御 に よ っ て ， 多様 な ア プ リ ケ ー シ ョ ン 間 の 公平 な 利用 を 図 る と い っ た ， 高品
質 ・ 高効率 な ネ ッ ト ワ ー ク 管理技術 ， (3) ネ ッ ト ワ ー ク 攻撃 に 耐 え 得 る ， サ ー ビ ス
保全技術 ， な ど を 要素技術 と し て ， ア プ リ ケ ー シ ョ ン を 強 く 意識 し ， ア プ リ ケ ー シ
ョ ン が 求 め る 的確 な ネ ッ ト ワ ー ク 情報 を ， 必要十分 な 品質 で ， オ ン デ マ ン ド に 提供
す る ， 運用管理 プ ラ ッ ト フ ォ ー ム 技術 の 開発 を 目指 し て い る ．
5.2.2.2

今年度の活動実績

この目標の達成のため，今年度は，(1) 運用情報の統合化による運用管理支援技術の開発(2) 配信映像利活用のためのエンドユーザ環境構築
について検討を行った．そして，その評価基準を「ネットワーク情報の計測と収集を行うためのネットワーク情報基盤の超高速大規模ネットワーク上への構築」と定め，地域間広帯域コンテンツ流通基盤実験（ JGN Ⅱ -A16028 ）ネットワークの構築・運用や JGN Ⅱ上の IPv6 ネットワークの構築と，それを用いた，定常的な動画像配信実験，地域のイベント利用等の支援などを通じた実証実験，などを行った．これら実験においては，アプリケーションレベルでの通信特性の計測・集約を目的とした計測手法についての検討を進めた．それらの具体的内容について以下に述べる．
5.2.2.2.1

地域間広帯域コンテンツ流通基盤実験

当研究における実証実験プロジェクトであり，各種実験・測定に用いるため JGN
Ⅱ上にその実験網を構築している． 2005 年 3 月末時点で，「東北大学情報シナジー
センタ（宮城県 ）」， 「 NICT 東北 JGN ⅡRC（宮城県 ）， 「八戸工業大学（青森- 223 -

県 ）」， 「 NICT 岩手IT研究開発支援センター（岩手県 ）」， 「株式会社データコ
ア（秋田県 ）」， 「山形県 」， 「会津大学（福島県 ）」， 「滋賀県」の８組織がメンバーとなっている．また「 NICT 北九州IT研究開発支援センター（福岡県 ）」 にもサーバ設置等のご協力を頂いている．

Webブラウザ上での操作と閲覧
時間範囲
トラフィックグラフ

Webチャットのログ

メール

図 5.2.2-1 Web ブラウザ上に統合した事後検証支援システム

5.2.2.2.2

運用情報の統合化による運用管理支援技術の開発

本項目においては， (1) 観測データとアプリケーション状態の収集・管理技術，(2) 多地点間相互映像配信ネットワークの運用管理技術， (3) 大容量分散配信シス
テムの効率的運用技術，について行った．
(1) 観測データとアプリケーション状態の収集・管理技術
映像配信の運用を支援するために，各地のネットワーク状況を把握するトラフィックグラフ，実験参加者間のコミュニケーションの場を提供するメーリング
リストと Web チャットを利用している．これらの運用・統計情報は，ネットワ
ーク状況やオペレーションの記録となる．この記録を組み合わせると，「いつ，何があったか」がわかり，配信時のトラブルなどの事後検証の手がかりとなる．
しかし，この運用・統計情報はすべて独立していて何の関連付けもなされておらず，その閲覧は面倒であった．そこで，運用・統計情報を時間軸で関連付けて Web ブラウザ上に統合する事後検証支援システムを開発した（図 5.2.2-1 ）．
時間軸で関連付けることで「ある現象が起きたときの前後の操作および状況」と「ある操作をしたときの状況の変化」がわかる．

- 224 -

図 5.2.2-2 JGN Ⅱネットワークにおける下位層とアプリケーションレベルでの通信特性の計測

図 5.2.2-3

映像配信に利用した DVTSの内部構造

統 計情報はSNMPによる計測を行っており，図 5.2.2-2 のように配信ネットワーク
上 の主な地点で下位層での入出力トラフィック，破棄パケット数，エラーデータグ
ラム数など計25項目を計測している．計測した値は RRDTool によって可視化して統計情報を視覚的に把握ができるようになっている．従来は配信ネットワークの下位層での計測に留まっており，受信地での映像・音声自体の品質についての計測がな
されていなかった．そこで，映像・音声の品質を定量的に計測する手法として，映像の受信地点においてパケットロス値，パケット到着間隔のゆらぎであるジッタの二つの値を計測し， SNMPで取得できるようにして本システムに統合した．これによってアプリケーションレベルでの状況把握も定常的に行えるようになった．現在は
アプリケーションレベルの状況把握をより詳細に行うためにアプリケーション内部のデータ構造を利用した計測を行っている．図 5.2.2-3 に映像配信に利用している
DVTSの内部構造を示す．受信側には２つのプロセスがあり， UDP パケット受信プロ
セスでは正しくデータを受信しているか，そうでなければ欠落したデータが実際の映像・音声にどう対応しているのかを明らかにする．計測を行っていると，パケッ
トロスが観測されていないにもかかわらず，映像・音声にノイズが混入する場合が- 225 -

見受けられる．このため， IEEE1394 パケット送信プロセス側においても，DVパケッ
トの送出タイミング等についての計測・検証が必要であると考え，その具体的手法について検討中である．

S
NM

JGNII

SN

SN

SN
SN

SN

県域ネットワークなど

SN

SN

S: Sender
SN: Splitter Node
NM: Node Manager

図 5.2.2-4

運用知識に基づく映像配信システムの概要(2) 多地点間相互映像配信ネットワークの運用管理技術
動画像配信技術の進歩やソフトウェアの充実によって，ネ ットワーク技術にあまり 詳しくなくとも比較的簡単に動画像配送を行えるようになってきている．しかし，２地点間での利用は比較的容易でも，多地点への配送を考えた場合，動画像配送シ
ステム（ WMT ， MPEG2/IP ， DV/IP ， etc. ）の決定，配送先情報（必要帯域，IPアド
レス， etc. ）の取りまとめと管理，最適なネットワーク構成の検討（ユニキャス
ト・マルチキャスト，配送ツリー， etc. ）， ネットワーク機器（ルータ，スイッチ ，送受信ノード， etc. ）の設定，導通テスト，仮運用，本番などといった一連の手順と，専門的な知識が必要であり，その作業工数も決して少なくない．また一方向配送に加えて双方向配送のニーズも高まっており，さらに敷居が高くなる．このようなことから，広く一般の利用を促進するためにも，より簡単に利用できる技術の開発が求められている．そこで多地点間で相互利用可能な動画像配送ネットワークの実現を目標として，運用知識に基づく映像配信システムの開発を進めている．当システムの概要を図 5.2.2-4 に示す．本システムは，配信元からのストリームを受信し，さらに複数のストリームとして再配信可能な中継ノードと，それら全体を管理する管理ノードからなる．中継ノードは，マルチキャストとユニキャストの変換やIPv4 と IPv6 との変換，中継ノードでの映像出力などを可能とする．管理ノードは，- 226 -

時間，配信先，ポート番号，必要帯域，などといった放送情報の管理や，それらの情報に基づいて，各中継ノード同士の配送ツリーを決定し，各ノードに対して自動的に設定を行う．また，運用状況（トラヒック，ロス値，ジッタなど）に応じて，動的にツリーの再構成なども行う．管理ノードの設定は Web ブラウザを用いた，視覚的にも操作が容易な仕様とする．当システムにより，網全体での利用帯域の効率化や，運用管理負荷の低減が期待できる．現在，中継ノード数 100 程度のＤＶ / Ｉ
Ｐを想定して，中継ノードのプロトタイプは完成しており， JGN Ⅱ上にて，その評価を行っている．管理ノードについても，その仕様策定とプロトタイプの作成を進行中である．

O1

O3

O2

S1

S2
D

S4
S3
O4
O5
Sx: Secondary Server
Ox: Origin Server
D: Directory Server

図 5.2.2-5

ディレクトリ情報
ファイルデータ

デマンド型分散ファイルシステムの概要(3) 大容 量分散 配信システムの効率的運用技術
インターネットにおける主要なサービスの一つ である広域分散ファイルサー
ビ スは，分散設置した複数のサーバのどれからも同一なファイルを取得できるものである．クライアントはより良好なスループットが得られ，また，サーバの負荷分散や可用性向上の効果が期待できる．一方で，配信されるファイルは数とサイズが共に増加しており，サーバ間で分散蓄積を行うための通信トラヒ
ックの増加や各サーバにおける蓄積領域の大容量化など，その運用と管理にかかるコストが増大している．しかし，配送されたファイルには，削除されるまでに全く利用されないものも多く存在し，無駄な配送と蓄積を生じている．例
えばＲｉｎｇサーバのひとつである ring.tains.tohoku.ac.jp の観測によれば，700GB を超えるファイル蓄積に対して，その 9 割が利用されていない．その大- 227 -

き な要因の一つは，ファイルの配送が網羅的であり，需要を反映する仕組みを有しないことである．そこで，大容量分散配信システムにおける効率的な運用
技術の実現を目的として，デマンド型分散ファイルシステムの開発を進めている．当システムの概要を図 5.2.2-5 に示す．本システムは，オリジナルのファイル（一次ファイル）を提供する一次サーバのディレクトリ情報や二次サーバの状態管理などを行うディレクトリサーバと，クライアントからのリクエストに応じて一次サーバやディレクトリサーバの代理としてディレクトリ情報やファイルを提供する二次サーバから成る．二次サーバは，リクエストされたファ
イルを持っていない場合には，一次サーバや他の二次サーバから得て，自分に蓄積すると共にクライアントに転送する．本システムにより，従来方式の性能や機能を損なわずに，サーバ間の不要な配送トラヒックの抑制や不要なファイルの蓄積の抑制，ファイルの利用効率の向上，などが期待できる．現在，一次サーバ数20，二次サーバ数 100 程度を想定して， JGN Ⅱ上にて， FTP 対応のプ
ロトタイプを用いた評価を行っている．また，既存の分散ファイルシステムにおける実際の運用環境をより詳細に分析するために，システム全体の運用ログを収集・解析するシステムの開発も行っており，実際に Ring サーバに適用して，調査を進めている．
利用者
AP層
コミュニティ指向ユビキタス認証ユニット

グループ認証機能

メディアエレメント機能 ﾐﾄﾞﾙｳｪｱ
ｻｰﾋﾞｽ
メディア変換機能
ﾕﾆｯﾄ

QoS要求獲得機能

接続提供機能グループ接続機能

スーパーFN層
利用者・AP情報獲得機能
利用者・AP情報獲得ユニット
QoS制御ユニット
多元
異常検知

Ad-NW QoS解決機能

接続要求獲得機能

トラフィック
異常検知

位置変化獲得機能
位置解決機能流量調整機能流量解決機能NW情報収集機能

経路多重化機能

経路解決機能Ad-NW情報収集機能

Ad-NW 経路解決機

無線リン

高レベル通信ユニット

NW運用ユニット ク

制御機能

TCP
Giga-bit EtherNet

図 5.2.3-1

IP

能

FN層
プラット
フォーム
情報獲得
ユニット
プラットフォーム
情報収集機能

無線端末
計算機
資源情報
獲得機能

無線NIC監視機能

LN層
xDSL

無線LAN

エージェント型ネットワークミドルウェアアーキテクチャ- 228 -

5.2.3

フレキシブルネットワークミドルウェア技術の開発

5.2.3.1

エージェント型ネットワークミドルウェアのアーキテクチャの検討

JGN Ⅱの超高速ネットワーク上で稼動するアプリケーション を支えるミドルウェ
ア として，フレキシブルネットワークミドルウェア技術の開発を目標に，本年度 は，
フレキシブルネットワークミドルウェアアーキテクチャの検討を行った．検討の結果，新たにスーパーFN層と呼ぶアプリケーション支援のための機能層を追加したエージェント型ネットワークミドルウェアアーキテクチャの基本構成を確立した．図5.2.3-1 に，エージェント型ネットワークミドルェアのアーキテクチャを示す．ス
ーパーFN層は，次の１～３の３つの機能ユニットから構成される．
1.

コミュニティ指向ユビキタス認証ユニット
超高速広域ネットワークに分散するユーザ間で，ユーザレベルで 自由に構成可
能な論理的な仮想ネットワークを構成するた めに，グループに所属するメンバ
を各メンバが相互に自律分散的に認証するユニットである．

2. ミドルウェアサービスユニット
上記1.により構成される仮想ネットワーク上で稼動するマルチ メディアコミュ
ニケーションアプリケーションの 構成に必要なソフトウェアコンポーネントを，エージェントとして段階的に設計・実装し，実装したエージェントを実行時に利用者要求に基づき動的に組織化し，アプリケーションを構成するユニットである．
3. 利用者・ＡＰ情報獲得ユニット
上記2.に より構成されるマルチメディアコミュニケーションアプリケーションの動作に必要な利用者に関する情 報，および他に同時に稼動するアプリケーシ
ョンに関する情報を獲得し，効率的な QoS 制御に利用するためのユニットである．
本年 度は特に，ミドルウェアサービスユニット内のグループ認証機能について方式の検 討を行 い，グループを構成するメンバ数 n に対し O(log n) のメッセージ数でメンバの追加・削除を可能とする新しい自律分散型グループ認証法の提案を行った．
次節以降，提案方式を詳述する．
5.2.3.2

自律分散型グループ認証 法

提案方式ではグループの各メンバが生成した公開鍵を他のメンバが保持・管理し，こ の公開鍵を使ってメンバ間認証を行う ．この提案方式の詳細を以下に述べる．
A. グループ認証
利用者が作成した グループのメンバ同士が通信を行う際には，メンバの本人性の- 229 -

確認と，同じグループのメンバかどうかの確認が必要となる．本研究ではこの２つの確認をまとめてグループ認証と呼ぶものとする．
B. 公開鍵の分散管理
ログオン状態の各メン バは自分の公開鍵リポジトリに一部のグループメンバの公開 鍵を保持する．公開鍵を保持しないメンバと認証を行う際には，メンバ間の公開鍵を使った認証によって出来る信頼関係を連鎖的につなげることでグループメンバ間の認証を実現する（図 5.2.3-2 ）．

図 5.2.3-2

グループメンバによる公開鍵の分散管理

C.認証経路の特定
メンバ A があるメ ンバ B を認証したいとき，どのメンバを経由すれば目的のメン
バ B に到達する認証経路が出来るかを各メンバの公開鍵リポジトリから特定するのは困難である．そこで，提案方式では認証経路を特定するために，各メンバが独自に参照テーブルという経路制御表を構成する．これは，参照のための中継メンバとそのメンバを中継して参照できるメンバの集合の対応を記したテーブルである．この参照テーブルは大きく次の 2 つの役割を持つ．
1.

参照経路を特定するための経路制御表としての 役割．
参照テーブルには, 目的のメンバを参照するために次にどのメンバを経由する- 230 -

かが記されている．
2.

メンバの公開鍵を渡す相手を決定する役割．
経路制御表に記された 中継メンバに対して何らかの安全な方法で公開鍵を渡す ．

図 5.2.3-3

認証経路と参照経路の関係

参照 テーブルに従ってあるメンバを参照するときの経路を参照経路 と呼ぶものとする．ここで，メンバ A の参照テーブルに記されたメンバ B にメンバ A の公開鍵が渡されメンバ B がメンバ A を認証する関係になることから，参照経路を逆方向にたどったものが認証経路となる．よって，メンバA がメンバB を認証したい場合 , メン
バ A を始点としメンバ B を終点とする認証経路を構成するが，この構成の際には各メンバの参照テーブルに基づいてメンバB を始点としメンバ A を終点とする参照経路の特定が行われる．このような認証経路と参照経路の関係を図 5.2.3-3 に示す．
D.参照テーブルの構成法
提案方式では，参照テー ブルにおける中継メンバの決定方法，および構成のための メンバ間通信について，分散ハッシュテーブルの研究の1 つとして知られる
Chord を活用している．参照テーブルの詳細と構成法について以下に述べる．
まず，グループの各メンバの ID から m ビット長のハッシュ値を算出し，これ を各メン バのインデックスとする．参照テーブルでは，このインデックスのある値から ある値までのメンバといった指定によってメンバの集合を抽象的に扱う．次に，ハッシュリングと呼ぶサイズ 2m のリング状のハッシュ空間をグループに１つ構成し，
このハッシュリングにメンバをインデックスに基づき仮想的に配置する．そして，で提案されているメンバ間通信を活用することで各メンバは m 行からなる自分の参
照テーブルに自分のインデックスからハッシュ空間上を 2k (0 ≦ k ≦ m-1) だけ正の方向に移動した場所に位置するメンバを記していく．ただし，この位置にメンバ- 231 -

が存在しない場合は，ハッシュリング上で正の方向に位置するメンバのうちこの位
置に最も近いメンバを記す．また，このメンバ間通信では隣り合うメンバの存在を監視して常に各メンバの参照テーブルの更新を行う．

図 5.2.3-4

参照テーブルに基づく参照経路の特定

図 5.2.3-4 は m=6 ビット長のハッシュ値をインデックスとするメンバが， サイズ
6

2 のハッシュリングに配置され，参照テーブルを構成している例である．グループ
α においてメンバ A が 1 ，B が 8 ，C が14，…， J が56といったインデックスを持ち，このインデックスに対応するハッシュリング上の位置に配置されている．ここで，インデックスが 8 であるメンバB の参照テーブルは 8 から距離 1 ， 2 ， 4 ， 8 ，16，32だけ進めた位置に配置されたメンバを示すテーブルである．
参照テーブルを使って参照経路を特定する手順を述べる．まず，参照を行うメン
バは目的のメンバのIDから目的のインデックスを算出する．次に，自 分の参照テー
ブルを使って目的のインデックスへの参照を中継するメンバを調べ，このメンバに対して参照の中継を要求する．この要求を受け取ったメンバは，自分の参照テーブ
ルを使って目的とするインデックスへの参照を中継するメンバを調べ，このメンバに対して参照の中継を要求する．この要求をグループメンバ間で繰り返すことで，目的のインデックスを持つメンバに到達する．
具体例として，図 5.2.3-4 でメンバ B がメンバ J への参照経路を特定する手順を述べる．まず，メンバ B はメンバ J のIDのハッシ ュ値を求めることで，J のインデックスが 56 であることを知る．次に，メンバ B は自分の参照テーブルを使って，- 232 -

56への参照を中継するメンバを調べる．ハッシュリング上で 56 は40から 7 の間であるので，テーブルを調べて40から7 に対応するインデックス42のメンバに参照の中継を要求する．次に，インデックスが42であるメンバ G が56への参照の中継を行う．メンバ G は自分のテーブルで 56 への参照を中継するメンバを調べ，インデックス 51 の メ ン バ に参照の中継 を 要求す る ．

表 5.2.3-1

提案方式における公開鍵の数および認証経路の長さ

グ ループ全体の鍵数

１ メ ン バ の持つ鍵数

認証経路の長 さO(n log n)

平均 O(log n)O(log n)

そこで， インデック スが 48 で あるメンバ I が 56への参 照の中継 をする．メンバ I
は自分のテーブルで目的の 56 を直接参照している．このようにして，メンバB からメンバ J への参照経路が B ， G ， I ， J という順番であることが特定される．
参照テーブルを使った認証経路の特定を以上のように行った場合の認証経路の長さ，つまり，グループ認証時に中継するメンバ数について考察する．まず，グループのメンバ数を n ，メンバにつけるインデックスのビット長を m と定義する．ここで，ハッシュリングのサイズは 2m となるため， n<2m であることが m の条件となる．
また，参照テーブルにおいて，各メンバはハッシュリング上の自分の位置から 2k(0≦ k ≦ m-1) だけ移動した場所に位置するメンバの情報を持つ．よって，参照テーブルに記されるメンバの数は O(log n) となり，これらは公開鍵を保持するメンバであることから，あるメンバの公開鍵は O(log n) 人のメンバが保持する．このため，グループ全体の公開鍵の数は O(n log n) となる．このように，各メンバの参照テー
ブルに記されたメンバに対して公開鍵が配置されるため，各メンバが公開鍵を保持する数にはばらつきが出ることが予想される．ただし，グループ全体の公開鍵数がO(n log n) で，グループのメンバ数が n 人であるため， 1 メンバあたり平均 O(logn)個の公開鍵を保持することになる．また，認証経路は参照テーブルによって特定されることから，認証経路の長さ，つまり認証の際に中継するメンバ数は O(logn) になる．提案方式における公開鍵の数および認証経路の長さを表 5.2.3-1 に示
す．
E.メン バの削除・鍵の更新
グループの一員であったメ ンバ A を今後グループメンバとして認証しない場合に，
メ ンバの削除を行う．提案方式では，グループの一部のメンバが保持しているメン- 233 -

図 5.2.3-5

鍵の更新

バ A の公開鍵を全て削除することで，グループメンバによって認証されないようにする．一方，メンバ A の鍵の更新の際はグループの一部のメンバが保持するメンバ
A の公開鍵を全て新しい公開鍵に入れ換える．つまり，グループにおけるメンバの削除，メンバの鍵の更新の際には，対象となるメンバの公開鍵の保持者の特定が必要であり，この保持者に対して公開鍵の削除や更新を通知するメッセージの送信を行う．提案方式では，公開鍵の保持者の特定に参照テーブルを用いる．
（図 5.2.3-5 ）5.2.3.3

フレキシブルネットワークミドルウェア技術の開発のまとめ

JGN Ⅱの超高速ネットワーク上で稼動するアプリケーションを支えるミ ドルウェ
アとし て，フレキシブルネットワークミドルウェア技術の開発を目標に，本年度は，
フ レキシブルネットワークミドルウェアアーキテクチャの検討を行った．検討の結果，新たにスーパーFN層と呼ぶアプリケーション支援のための機能層を追加したエージェント型ネットワークミドルウェアアーキテクチャの基本構成を確立した．加えて，ミドルウェアサービスユニット内のグループ認証機能について方式の検討を行い，グループを構成するメンバ数 n に対し O(log n) のメッセージ数でメンバの追加・削除を可能とする新しい自律分散型グループ認証法の提案を行い，提案方式について詳述した．

- 234 -

東北 RC

平成 16 年度分

業績リスト

1. Z. U. M. Abusina, S. M. S. Zabir, A. Ashir, D. Chakraborty, T. Suganuma and N.
Shiratori, "An Engineering Approach to Dynamic Prediction of Network Performancefrom Application Logs," International Journal of Network Management (採録決定)
2. Sega Diallo, Kshirasagar Naik, Debasish Chakraborty, Gen Kitagata, and Norio
Shiratori, "RFGBP: A reliable Feedback Guarantee Broadcast Protocol for Ad Hoc
Wireless Networks," IEEE Transactions on Parallel and Distributed Systems, (投稿中)
3. 山田勇二, 小出和秀, 北形元, 白鳥則郎, "Mobile IPv6 環境における認証型ファイアーウ
ォールに関する検討", 電子情報通信学会技術報告, MoMuC 研究会, MoMuC2004-28,
pp.89-94, 2004.
4. 菅沼拓夫, 北形元, Mansfield Glenn, 白鳥則郎, "超高速大規模ネットワークのためのネットワーク計測・解析技術," 2004 電気関係学会東北支部連合大会講演論文集, p.210,
2004.08.
5. Zhang Ding Hui，北形 元，小出和秀，Glenn Mansfield Keeni，白鳥則郎, "Detectionof Network event via Traffic Informaition," 2004 電気関係学会東北支部連合大会講演論
文集, p.39, 2004.08.
6. 阿部勝久，キニ・グレン・マンスフィールド，白鳥則郎, "Event Detection by Traffic
Monitoring," 2004 電気関係学会東北支部連合大会講演論文集, p.38, 2004.08.
7. Kazuhide Koide, Glenn Mansfield Keeni, Takeo Saito and Norio Shiratori, "TBRA:
Tree-Based TCP Retransmission Analysis for Locating Network Pathologies," 2004 電気関係学会東北支部連合大会講演論文集, p.12, 2004.08.
8. Takara Iwamoto, Salahuddin Muhammad Salim Zabil, Gen Kitagata and Norio
Shiratori, "A Scheme for Improved TCP Congestion Avoidance using Low Priority
Packet", 2004 電気関係学会東北支部連合大会講演論文集, p.35, 2004.08.
9. Sega Diallo, Kshirasagar Naik, and Norio Shiratori, "Partial
UnicastRetransmissions in Reliable Tree Based Broadcast for MANET," 2004 電気関係学会東北支部連合大会講演論文集, p.36, 2004.08.
10.Zhang Ding Hui, Koide Kazuhide, Gen Kitagata, Glenn Mansfield Keeni, and Norio
Shiratori, "Detection of Network Events using Digital Signal Processing Techniques,"
電子情報通信学会技術報告, CS/IN/NS 研究会, IN2004-66, pp.37-41, 2004.09.
11.阿部勝久，キニ・グレン・マンスフィールド，白鳥則郎, "Experiments on Event
Detection by Traffic Monitoring," 電 子 情 報 通 信 学 会 技 術 報 告 , CS/IN/NS 研 究 会 ,IN2004-48, pp.23-26, 2004.09.
12.小出和秀, キニ・グレン・マンスフィールド, 齋藤武夫, 北形元, 白鳥則郎, "フロー解析に基づくネットワーク障害箇所推定手法", 電子情報通信学会技術報告, CS/IN/NS 研究会,
CS2004-43, pp.17-22, 2004.09.
13.岩本貴良, 北形元, 白鳥則郎, "低優先度パケットを用いた TCP 輻輳制御方式の改善", 電- 235 -

子情報通信学会技術報告, CS/IN/NS 研究会, CS2004-71, pp.79-84, 2004.09.
14.ディアロ・セガ, ナイク・クシラサガール, 北形元, チャクラボルティ・デバシシュ, 白
鳥則郎, "Reliable Total Dominant Pruning: MANET のための部分的ユニキャスト再送に
よ る 高 信 頼 フ ラ ッ デ ィ ン グ 方 式 ", 電 子 情 報 通 信 学 会 技 術 報 告 , CS/IN/NS 研 究 会 ,CS2004-76, pp.107-112, 2004.09.
15.山田勇二, 小出和秀, 北形元, 白鳥則郎, "階層型 Mobile IPv6 を用いた認証型ファイアー
ウォールの提案", 電子情報通信学会技術報告, CS/IN/NS 研究会, CS2004-67, pp.61-65,
2004.
16. Katsuhisa Abe, Glenn Mansfield Keeni, Norio Shiratori, "Network Traffic Analysis
on the basis of RTT measurements," 電子情報通信学会技術報告, MoMuC 研究会,
MoMuC2004-92, pp.27-32, 2005.01.
17. Z. U. M. Abusina, T. Suganuma and N. Shiratori, "Enhanced Medium Access Control
for IEEE 802.11 using DistributedCoordination Function," 先端的ネットワーク＆コンピューティングテクノロジワークショップ予稿集, 2005.01.
18.阿部勝久，菅沼拓夫，キニ・グレン・マンスフィールド，白鳥則郎, "Detecting Events frommonitored data in a wide area network," 先端的ネットワーク＆コンピューティングテク
ノロジワークショップ予稿集, 2005.01.
19. Zhang Ding Hui, Gen Kitagata, Takuo Suganuma and Norio Shiratori, "Network
Event Detection using Digital Filtering Technique," 先端的ネットワーク＆コンピューティングテクノロジワークショップ予稿集, 2005.01.
20. Z. U. M. Abusina, T. Suganuma and N. Shiratori, "Exhaustive MAC: Efficient QoS
Mechanisms for IEEE 802.11 Based Wireless Mobile Ad Hoc Networks," 情報処理学会東北支部研究会, 2005.03.
21. Zhang Ding Hui, Koide Kazuhide, Gen Kitagata, Glenn Mansfield Keeni, Norio
Shiratori, "Detection of Network Events based on Digital Filtering," 情報処理学会研究報告, DPS 研究会, 2005.03
22.松島悠, 北形元, 木下哲男, 白鳥則郎, “コミュニティ指向ネットワークミドルウェアにおけるグループ認証手法", 信学技報 NS200４-111/IN200４-70/CS200４-66, pp.55-59,
2004.923.吉村智志, 今野将, 岩谷幸雄, 阿部亨, 木下哲男, “AIR-NMS における状態情報エージェ
ントの設計“, 第 3 回科学技術フォーラム(FIT2004), 講演論文集 F-025, pp.269-270,電子情報通信学会/情報処理学会, 2004.9.
24.打矢隆弘, 前村貴秀, 菅原研次, 木下哲男, “エージェントシステムのインタラクティブ
開発環境”, Proc. JAWS2004（エージェント合同ワークショップ・シンポジウム 2004）,
pp.447-454, JAWS04/IEICE・MACC・IPSJ・JSAI, 2004.10.
25.打矢隆弘, 前村貴秀, 阿部亨, 菅原研次, 木下哲男, “エージェントシステム開発におけるインタラクティブ設計法とその支援環境”, マルチメディア通信と分散処理ワークショップ- 236 -

予稿集, pp.71-76, 情報処理学会, 2004.12.
26. T.Ishida, A.Miyakawa, Yoshitaka Shibata, "Virtual Traditional Japanese Crafting
System using JGN Ⅱ in Collaborative Work Environment", Proc. of the 18th
International Conference on Advanced Information Networking and Applications(AINA2005), pp.229-234, Mar.2005.
27.石田智行, 宮川明大, 杉田薫, 柴田義孝, “次世代ネットワーク上における協調支援を考慮した高臨場感伝統工芸システム”, 情報処理学会マルチメディア通信と分散処理ワークシ
ョップ,IPSJ Symposium Series, Vol.2004, No.12, pp137-142, Dec.2004
28. 石田智行, 宮川明大, 柴田義孝, “多様性を考慮したバーチャル伝統工芸システム”, 情報処理学会第 118 回マルチメディア通信と分散処理（DPS）研究会,June.2004
29. 石田智行, 宮川明大, 柴田義孝, “JGNII を用いたバーチャル伝統工芸システムの提案”,
情報処理学会第 53 回グループウェアとネットワークサービス(GN)研究発表会, Sep.2004
30.石田智行, 宮川明大, 柴田義孝, “高速ネットワーク上における協調バーチャル伝統工芸システム”,情報処理学会 第 67 回全国大会, 2X‐2, Mar.2005.
31.越後博之 湯瀬裕昭 干川剛史 高畑一夫 柴田義孝,”大規模運用が可能な安否情報データ
ベースシステム", 情報処理学会 第 67 回全国大会 1V-4, March, 2005
32.脇山俊一郎，菅野浩徳，林優一，奈良岡豪，錦部政朋，曽根秀昭,「ＪＧＮII 推進フォー
ラム 2004 in 東北」における映像配信ネットワークの構築と運用, 平成 16 年度電気関係学会東北支部連合大会, 1F4, p.198 (2004.8.26).
33.曽根秀昭，菅沼拓夫，木下哲男，東北 JGNⅡリサーチセンターにおける研究活動，平成16 年度電気関係学会東北支部連合大会, 1F5, p.199 (2004.8.26).
34. 林優一，菅野浩徳，曽根秀昭，キャンパス間周回 VLAN を用いた動画像伝送実験，日本学術振興会インターネット技術第 163 委員会研究会，2004.5.27
35. Satoshi Nounin, Hironori Kanno, Hideaki Sone ，Information management andserver selection of a distributed delivery system，Joint Seminar of Core University
Program and JSPS 163rd Committee on NGI, Daejon，(2004.11.26) A23-1
36. Kazuo Tomita, Yuichi Hayashi, Hironori Kanno, Hideaki Sone，A measurement of a
network system load of a MPEG2 streaming，Joint Seminar of Core University Programand JSPS 163rd Committee on NGI, Daejon , (2004.11.26) A23-6
37.富田和雄，林 優一，菅野浩徳，曽根秀昭，学内ネットワークを用いた動画像伝送実験とそのトラフィック特性，先端的ネットワーク＆コンピューティングテクノロジワークショ
ップ (2005.1.24) A-3
38.高橋輝樹，林 優一，農人聡，菅野浩徳，曽根秀昭，管理ポリシーの異なるミラーサーバ
群におけるログ集約手法の提案と検証，先端的ネットワーク＆コンピューティングテクノ
ロジワークショップ (2005.1.24) C-3- 237 -

5.3

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

ユビキタス環境では，データを集約する必然性はそもそもなく分散処理することが自然である．そこで本研究開発では，ネットワークや端末の機能を意識せずにネット
ワーク上の計算資源や DB 資源を自由に活用できる進化するユビキタス環境である，サ
ラウンディング・コンピューティング環境の確立を目指す．
情報ネットワークを介して転送される情報をより有益なものにするには，あらゆる情報の有機的な連携や分散している情報の自動配信処理が求められるため，サラウン
ディング・コンピューティング環境で提供される情報への高度な価値の付与とその情報を転送・提示するための技術を開発する．更に，多様な価値を付与された情報を転送するためには，送信するデータの種類や用いる通信媒体，その他外的要因によらず
リアルタイムでの送受信や再現を可能にすることが求められる．そこで，高速・高効率符号化処理，画像・音声情報など多種多様な情報を統合的に再現するための信号処
理システムの研究開発を行う．
本節では，これらの目的を達成するための基礎として，まず，サラウンディング・コンピューティング環境での柔軟な伝送処理を実現するための，データ駆動型プロセッサを用いたネットワーク・プロセッシングについて示す．次に，ユビキタス環境での快適なサラウンディング・コンピューティング環境創出のために不可欠である各種センサによる情報収集を実現するための，RFID リーダ・ライタの伝送性能について示す．また，JGNⅡなどの超高速・大容量ネットワーク上では大量の情報が転送されているが，いつでもどこでも，といったユビキタス環境での情報提示のためには，ユビキ
タス端末での情報再現を可能にする情報提示方式が必要である．そこで，まず音響空
間をユビキタス端末でも効果的に再現できる方式と，その方式に適した信号処理アル
ゴリズムを提案する．
5.3.1

DDNP を用いたネットワーク・プロセッシング

近年，光増幅技術や光波長多重技術 DWDM (Dense Wavelength Division Multiplexing)
等，光伝送技術の発展により，あらゆる形式の情報を自由に疎通できる情報環境の実現がまさに可能になろうとしている．このような情報ネットワーク上で多様な新サー
ビスを柔軟に実現するためには，多様なパケット流を受容し，それぞれのリンクの実速度に対応した処理能力を持つ超高速プログラマブル・ルータチップの実現が中心的な課題となる．近年，これらの要求を満たすべく，プログラム可能な高速パケット処理プロセッサである，ネットワーク・プロセッサ NPU(Network Processor Unit)が各所で開発されつつある[6]．
本研究では，将来のサラウンディング・コンピューティング環境のキー・デバイス
として，省電力・並列処理能力に優れたセルフタイム回路によるデータ駆動型チップ・
マルチプロセッサをネットワーク向きに最適化した，データ駆動型ネットワーク・プ- 238 -

ロセッサ DDNP(Data-Driven Network Processor)の基本構成とその応用例について検討を進める．
5.3.1.1

DDNP の基本構成

DDNP は，ATM を始めとして，IPv4，IPv6 を対象としたマルチプロトコル・パケット処理向きの命令セットを搭載したデータ駆動型マルチプロセッサ・チップである．
DDNP は，主に 32bit 演算処理を行う整数演算ナノプロセッサ５個，主に 8bit，16bit
演算処理を行う SIMD 演算ナノプロセッサ３個，主に外部メモリアクセスを行う機能メ
モリナノプロセッサ２個をチップ上のパケット・ルータを介して相互に接続したチッ
プ・マルチプロセッサ構成となっている．マルチプロトコル処理に専用化した命令として，CRC 演算，ラップアラウンド加算，オクテット単位での各種演算命令が搭載されている．
この DDNP チップは，0.18μmCMOS で実現され，IPv4，IPv6 パケットが混在する条件の下で，7.5MPPS の性能が達成できることが実証されている[1]．
5.3.1.2

DDNP の組込みファイアウォールへの応用

昨今、携帯電話やノート PC などの個人用携帯機器の普及に伴って、ネットワーク用
ファイアウォールに加えて、個人用ファイアウォールの需要が高まっている。しかし、現状の個人用ファイアウォールのほとんどはソフトウェアであり、端末のオペレーティング・システムがウィルス等に感染すると、機能しなくなる。したがって，我々は，
オペレーティング・システムとは独立に動作可能なハードウェア・ベースの組込み型
ファイアウォール・プロセッサとして，DDNP を応用する検討を進めている[2,3]．図5.3.1 にその概要を示す．

図 5.3.1

組み込み型ファイアウォールの機能概要- 239 -

現在までのところ，レイヤー４パケット(TCP)の静的フィルタリング，動的フィルタ
リング SPI(Stateful Packet Filtering)，および，URL フィルタリングの機能を対象として，FPGA 上に拡張 DDNP プロセッサを実装し、単一プロセッサの性能を実測した．
その結果を表１に示す．この結果からも判るように，単一プロセッサでも 100Mb/s を超えるリンク速度でファイアウォール機能を実現できる見通しが得られている[3]．今後は，各個人がより快適で安全にサラウンディングなネットワーク環境を活用するために必須となる，コンテンツフィルタリングの高速化手法等の検討を進める予定である．
表 5.3.1

DDNP のフィルタリング性能
StaticSPI

URL Filtering

3.5M－5.0M

329K

9.1K－1.5M

16

443

1027

FilteringThroughput[IP Packets/sec.]
Program size
[DDNP Nodes]

参考文献[1] 岩田，寺田, ”セルフタイム回路によるデータ駆動型プロセッサとその応用,”
信学会集積回路研究会, ICD2004-197, pp.53-58, Dec.2004 [招待講演].
[2] M. Iwata, D. Morikawa, R. Zhang, W. Su, Y. Zheng, L. Kong, H. Terada, “Design
Concept of An Embedded Data-Driven Firewall Processor,” International Conference on
Next Era Information Networking NEINE’04, pp. 80-87, Sep. 2004.
[3] 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.3.2

RFID リーダ・ライタの精度予測

RFID とは微細な無線 IC チップのことであり，内部メモリに記録された情報をリーダライタ(質問器)からのリクエストに応えて送り返す[1]．電池非搭載のパッシブ型
RFID チップでは，リーダ・ライタから送出される搬送波を整流し，これを動作に必要な電源として利用する．ここでは，チップとリーダ・ライタのアンテナにパッチアン
テナ（マイクロストリップアンテナ）を用いた場合の読み書き精度及び読み書き可能なレンジを予測する．
5.3.2.1

4 素子円状配置アレーアンテナ

Array Antenna とは複数の小さな素子アンテナを並べ，一つのアンテナとして機能させるというもので，素子アンテナの一つ一つに受信信号の位相や振幅を調整し，それらを合成することで期待している電波を受信しようとする方式である．本研究では，- 240 -

4 素子の Circular（円状）Array Antenna を用いた（図 5.3.2）．

図 5.3.2

円状配置アレーアンテナ

図 5.3.2 のようにアンテナ素子 K 素子を半径 R の円周状に等間隔で配置すると， k
番目 (k =0,1,・・・K -1)の素子の x 軸からみた配置角は φ k =2 kπ / K[rad]として与えられる．また本研究では，x 軸から π /4[rad]だけ初期配置角を回転させた素子配置についても検討を行う．その場合には φ k =2 kπ / K + π /4 となる．このような場合の円状配置アレーアンテナの指向特性は，F( , )

K 1

Ak e

j[ k

2

R cos(k ) sin]k 0となる[2]．ここで， Ak e

j k

は k 番素子の複素重みを表しており， A k は振幅定数， φ kは位相定数で 3 次元空間の角度( φ 0 , θ 0 )にメインビームを向けるときにはk2

R cos( 0k ) sin 0となる．4 素子円状配置アレーアンテナの指向特性の例を図 5.3.3 に示す．ただし，このときの各素子にはオムニアンテナを仮定している．

図 5.3.3

4 素子円状配置アレーアンテナの指向特性の例- 241 -

5.3.2.2

パッチアンテナ

本研究では IC チップ及びリーダ・ライタ共にパッチアンテナを用いるものとする[3]．想定するパッチアンテナの大きさは縦横 2 a=2b= λ g /2 ( λ g はパッチ内部の波長)とする．パッチアンテナの xz 面( φ =0)及び yz 面(φ = π /2)を考えると，それらの面内での電界は次のようになる．

xz 面(φ = 0): E 0

sinyz 面(φ =π /2): E

5.3.2.3

2

E 0 cos

E0

2
2

sin

sin

, E

0

cos
, E

0

sin

計算結果

IC チップの配置とリーダ・ライタの読み書き精度の関係について検討した．結果の一例を図 5.3.4 に示す．図 5.3.4 は，IC チップをリーダ（アレーアンテナ）から z 軸
方向に離し，その位置でリーダの xz 平面内で IC チップを回転させた場合の特性であり，読み取り率 80％が得られる距離とチップ回転角の関係を示している．リーダのアンテナとしては(1): 1 素子パッチアンテナ，(2): (1)を素子とする 4 素子円状配置アレー，(3): (2)を要素とする 4 素子円状配置アレー(計 16 素子)を仮定した．図 5.3.4
より，(3)のリーダを用いることで読み取り率 80％が得られるチップ位置を拡大できることがわかる．

図 5.3.4

読み取り率が 80％以上となるリーダ－IC チップ間距離の推定値（IC チップの配置角と距離の関係）- 242 -

5.3.2.4

まとめ

ここでは RFID リーダ・ライタの読み書き精度をパッチアンテナを要素とするアレーアンテナの理論から推定した．
参考文献[1] 根日屋英之，植竹古都美，“ユビキタス無線工学と微細 RFID，”東京電機大学出版局，2003．
[2]

John

Litva ， Titus

Kwok-Yeung

Lo ， “Digital

BeamforminginWireless

Communications，”Artech House Publishers，1996．
[3] 後藤尚久，“図解・アンテナ，”電子情報通信学会，1995．

5.3.3

音響情報再現システム

本節では，構成が最も単純で実現容易なステレオ型音響情報再現システムを提案する．要求される音響空間を再現させるにはスピーカ（2 次音源）からマイク（制御点）
までの伝達特性の影響を打ち消す，すなわち伝達特性の逆特性を近似する必要がある．
現在までに逆特性を近似する手法についてはシステム論的立場から様々な検討がなされてきた．現在最も有効とされている手法に MINT 理論に基づいた多チャネル－多点制
御系がある[1]．これは制御点数 M に対し 2 次音源数を M +1 用意することで，逆特性の推定と同時にクロストーク現象を除去し音の再現を可能にしている．しかし多くのスピーカを用いることから制御系が複雑になってしまう．そこで，制御点数 2 に対し 2
次音源数 2 で構成される新たな制御系を提案する．
5.3.3.1

多入力信号補正システム

ここでは提案する 2 チャネル－2 点制御系（多入力信号補正システム）について述べる．図 5.3.5 はその構成図である．適応フィルタ H 11 は右側入力信号 d 1 (t )とフィル
タ通過後の信号 s 11 ( t )から出力誤差を算出しているため G 11 の逆特性に近似させるフィルタとなる．ここで得られた係数を右側補正フィルタ係数 c 1 として与えることによって右側所望信号 x 1 ( t )と右側観測信号 y 1 ( t )を近似させることができる．しかしクロストーク G 12 に対する補正処理により左側観測信号 y 2 ( t)を右側所望信号 x 1 ( t)に近似させるような動作をするため，これを防ぐ工夫が必要となる．適応フィルタ H 21 は左側入力信号 d 2 ( t )と s 21 ( t )から出力誤差を算出しているため G 21 の逆特性を近似させる
フィルタとなる．通常ここで得られるフィルタ係数は右側補正フィルタ係数 c 1 として与えることはできないが，クロストークの伝達特性 G 12 と G 21 が互いに強い相関をもつことに着目すると， H 21 によって得られるフィルタ係数は G 12 の特性を予測するフィル
タとして代用できる．これを右側補正フィルタ係数 c 1 として与えることで， G 12 を通- 243 -

過するクロストーク成分を左側所望信号 x 2 ( t )に近似させることができる．したがって H 11 で得られたフィルタ係数と H 21 で得られたフィルタ係数を合成させたものを右側補正フィルタ係数として与えることによってクロストークの影響を軽減させる働きをもつ補正フィルタが設計できる．ここで左右の補正フィルタ係数はそれぞれ

c 1, L (t+1)=w1h 11, L (t)+(1-w1)h 21, L (t)c 2, L (t+1)=w2h 22, L (t)+(1-w2)h 12, L (t)として与えられる．w i は第 1 項と第 2 項に対する重み付けパラメータ（0 ＜ w i ≦ 1）
である．適応フィルタ H ij のフィルタ係数の更新には

hij,L (t 1) hij,L (t )yj , L (t )eij (t )∥yj , L (t )∥2で示される学習同定法[2]を用いる．ここで α はステップゲイン， e ij はフィルタの出力誤差を示す．

図 5.3.5
5.3.3.2

多入力信号補正システムの構成

聴覚特性に基づく出力誤差の算出

音場再生システムでは適応フィルタを可能な限り速く収束させることが望ましい．
このことに対する一提案手法として，出力誤差を算出する際に人間の聴覚特性に基づき重み付けを行うことで余分な周波数帯域を縮小し計算効率の向上をはかる．人間の聴覚特性には騒音測定の指標として利用されている A 特性音圧レベル[3]を用いる．こ- 244 -

の特性から周波数毎の重み付け関数を(k )Res(k ) |min Res||min Res|により算出する．ここで Res( k)，minRes はそれぞれ A 特性における周波数応答およびその中の最小値を示す．入力信号 d i ( t )と適応フィルタの出力信号 s ij ( t )に対して周波数領域で φ ( k )との積をとり，時間領域での差を新たな出力誤差 e ij として扱う．
5.3.3.3

計算機シミュレーション

提案手法の有効性を検証するために，計算機によるシミュレーションを行う．ステップゲイン α や重み付けパラメータ w i の違いによる収束特性を比較する．
（１）シミュレーション 1
所望信号 x i (t )として成人男性の声を 8kHz でサンプリングした音声信号を与える．
また，適応フィルタのインパルス応答長 L =512 とする．シミュレーションで用いる伝達関数は，反響性のある部屋においてスピーカとマイクロフォンの位置関係を変えた
もの 3 パターンの実環境を想定し，原信号（白色雑音）と観測信号により実測したものを用いる．ここでは聴覚特性の重み付けは行わず，ステップゲイン α や重み付けパラメータ w i の違いによる収束特性を比較する．評価量には次に示す原音に対する再現
音の再現精度（SNR）を用いる．
SNR 10log10

E xj 2 (t )E yj 2 (t ) xj 2 (t )(5.3.1)

ここで E [・]は期待値を表す．ただし，左右の所望信号に対して一切補正を行わずに算出した SNR と提案手法を適用し算出した SNR との差を改善量とし評価を行う．
表 5.3.2

最大改善量と各パラメータおよび相互相関係数

表 5.3.2 に 3 パターンそれぞれの場合の左右チャネルに対する改善量の平均が最大となった条件を示す．これらの結果より，重み付けパラメータに大きなばらつきが見られるが，ステップゲイン α =0.05 付近で最も高い改善量が得られた．また 2 本のク
ロストーク成分の相互相関係数 r N が大きい値を示すほど改善量も高い値を示している．

- 245 -

（２）シミュレーション 2
出力誤差 e ij を算出する際に聴覚特性の重み付けを行い，改善量の最も高い条件下で収束特性を比較する．ただし所望信号 x i ( t )および観測信号 y j ( t)のそれぞれの周波数帯域において φ ( k )を重み付け，式(5.3.1)の SNR から改善量を算出する．

図 5.3.6

収束特性の比較

図 5.3.6 はパターン 1 において α =0.05，w 1 =0.35，w 2=0.25 を与え，改善量を比較したものである．この結果から聴覚特性の重み付けを行ったことで 0.63 秒程度の速度向上が確認された．
5.3.3.4

まとめ

本節ではクロストーク成分の相互相関に着目した新たな多入力信号補正法を提案
し，計算機シミュレーションによりクロストーク成分の相互相関係数が大きいものほ
ど本提案手法が有効であることを示した．また適応フィルタ係数更新のための出力誤差を導出する過程で，聴覚特性に基づき重み付けを行うことにより収束速度を向上させることができた．今後は様々な環境の室内インパルス応答を与え，2 本のクロストークにおける伝達特性の相互相関と最適な重み付けパラメータとの関連性を明らかにしていく必要がある．

- 246 -

参考文献
[1] P.A.Nelson, H.Hamada and S.J.Elliott,“Inverse Filters for Multi-Channel Sound
Reproduction,”IECE Trans. Fundamentals, vol.E75-A, no.11, pp.1468－1473, Nov. 1992.
[2] J.Nagumo and A.Noda, “A Learning Method for System Identification,”IEEE Trans. AC,
vol.12, no.3, pp.282－287, 1967.
[3]“JIS C 1502-1990, 普通騒音計,”日本工業規格, 1997.
[4] S.Hamasaki and M.Fukumoto, “Stereo type sound reproduction systems using multi-input
correction,”International Conference on Next Era Information Networking, NEINE-129,
pp.468-475, Sept. 2004.
[5] 浜崎真二, 福本昌弘,“多入力信号補正によるステレオ型音場再生システム,”電子情報通信学会信号処理シンポジウム, A4-3, Nov.2004.
[6] 浜崎真二, 福本昌弘,“クロストーク成分における相関係数に着目した音場再生シ
ステム,”電子情報通信学会技術報告, SIP2004－115, pp.31－36, Jan.2005.

5.3.4

音響情報再現のための信号処理アルゴリズム

学習同定法[1]は，演算量が少なく実現が容易であることから代表的な適応アルゴ
リズムの一つとして広く用いられている．しかしながら，このアルゴリズムでは係数更新手順において正規化のために状態ベクトルのノルムの 2 乗による除算を必要とすることから，小さい入力信号が連続した場合には動作が不安定になるという問題が生じる．不安定な動作を抑制するための方法としては，入力信号がしきい値よりも小さくなったときには係数更新を行わないといった方法が知られている．しかしながら，この手法では小さな入力信号が連続した場合に係数更新を打ち切っているため，扱う信号の性質によっては，収束速度が大幅に劣化する恐れがある．例えば，音響空情報
再現システムなどでは，推定すべきパラメータは常に変動し続けるため追従性が要求されることから，係数更新を打ち切ることは好ましくない．更に，収束速度と推定精度の高いレベルでの両立も望まれる．
これまでに提案してきた方式[2,3]では，保証値を満足するために，小さな入力信号が続いた場合に係数更新を打ち切るためのしきい値を設定していたが，本研究では，
このしきい値を見直して係数更新を打ち切らないように変更し，かつ，保証値を満足するステップゲインの上限を与える．
5.3.4.1

準備

ここでは，まず，学習同定法[1]で用いる記号の定義を行い，次いで，学習同定法の係数更新手順について述べる．
まず，観測雑音が存在する場合のパラメータ推定モデルを図 5.3.7 に示す．

- 247 -

図 5.3.7

パラメータ推定モデル

時刻 i における入力信号 x (i )に対して，適応フィルタの状態ベクトルを

x N (i )x ( i ), x ( i 1),

x (x

N

1)

T

とする．ここで， N は適応フィルタのインパルス応答長であり， T は転置を表す．
適応フィルタの係数ベクトルを h N ( 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 )となる．
ここで， v ( i )は観測雑音である．
学習同定法の係数更新手順は

hN ( i 1) hN T ( i )x N (i )x N (i )と表される．ここで， α はステップゲインである．

- 248 -2e (i )

5.3.4.2

保証値を満足するためのステップゲインの上限
2

保証値（推定誤差の上限）[2]を確保するためには，判定式 x N ( i ) ≧ が常に満たされればよい．そこでx N (i )2とする．保証値 q は

N v2

q

2
x N (i ) 2となる．但し， σ x 2 ， σ v 2 はそれぞれ，入力信号 x( i)，観測雑音 v (i )の分散を表す．
この保証値を満足するためには，ステップゲイン α を
2q x N ( i )q x N (i )

2

2

N v2

とすれば良い．即ち，この α を用いると，係数更新打切りを行わなくても常に保証値2を満足する．ただし，一般に α ≦1 とするから， x N ( i ) ≧N v2のとき α = 1 とすれqばよいことがわかる．
以上をまとめると，保証値を満足するステップゲインの上限を用いた学習同定法の係数更新手順はhN (i 1) hN (i )(i )x N (i )x N (i )2e (i )となる．ただし， γ (i)は保証値を満たすステップゲインの上限であり
2q x N ( i )(i )q x N (i )

2

2

N v

2

, if

x N (i )

2

N v2
q

1 , otherwiseとなる．
5.3.4.3

計算機シミュレーション

保証値を満足するステップゲインの上限を用いた学習同定法の性能を評価するた
めに計算機シミュレーションを行う．
(1) シミュレーション条件
入力信号 x ( i )として

- 249 -

音声信号：成人男性の声を遮断周波数 2.2 kHz の低域フィルタに通し，8 kHz で
サンプリングした分散 1/48 の信号を用い，観測雑音 v ( i )を
音声信号：成人男性の声を遮断周波数 2.2 kHz の低域フィルタに通し，8 kHz で
サンプリングした信号（入力信号として用いた音声信号とは独立）としてシミュレーションを行った．
収束特性の比較のために用いた，簡略化 SF-NLMS アルゴリズムの確率的最速ステップゲインは α F =0.816 とした．保証値としては q

v
d

2
2

（ S/N の逆数に相当）を想定した．ステップゲインの上限 γ ( i )と簡略化 SF-NLMS アルゴリズムの係数更新打切り
判定のしきい値 ε を求める際，時刻 i における

d

2

2

の推定値 ˆd は，1 次の IIR フィル

タを用いて
ˆd 2

(1 b )

b k z 2 (i

k)

k 0

により求めた．ただし， b は IIR フィルタの係数であり， b=0.9999 とした．
(2) シミュレーション結果
収束特性の比較を図 5.3.8 に示す．ただし，図中の SF-NLMS は簡略化 SF-NLMS ア
ルゴリズム[3]を表す．図 5.3.8 より，入力信号，観測雑音ともに非定常な信号である
場合，係数更新打切りを行う SF-NLM アルゴリズムの方が推定誤差の劣化が少ないことがわかる．これは，SF-NLM アルゴリズムでは条件が悪い場合（入力信号が小さい）には係数更新を行わないため，推定すべきパラメータ（未知系）が変動しないという前提のもとでは推定精度が大きく劣化することはなく，保証値よりも高い収束精度を望めるためである．一方，保証値を満足するステップゲインの上限を用いた方式ではいかなる状況でも係数を更新しているため，定常状態の推定誤差の分布のばらつきこそ大きくなっているが，十分実用に耐える推定精度を維持しつつ，収束速度を大幅に向上している．
5.3.4.4

むすび

ここでは，SF-NLMS アルゴリズム[2]で用いた保証値を，係数更新を打ち切ることなく満足するステップゲインの上限を明らかにした．特に，音響情報再現システムなどのように非定常な信号を扱う場合には追従性の向上の効果は大きく，幅広い分野への応用に期待が持てる．

- 250 -

図 5.3.8収束特性の比較参考文献[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] 福本昌弘, 久保田一,“雑音の影響下での学習同定法の収束特性,” 情報理論とその応用シンポジウム, 14.1, Dec. 2004.
[6] M.Fukumoto, “Upper Limit of Step Gain for NLMS Algorithm in Noisy Environments,”
International Conference on Next Era Information Networking (NEINE'04), NEINE-149,
pp.507-514, Sept.2004.

- 251 -

5.4

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

5.4.1
5.4.1.1

研究開発の概要
研究開発の背景

通信の究極の目標の一つの形は、遠隔に存在する相手とあたかも同じ空間に存在しているかのような状況を作り出すこと、すなわち遠隔の相手と空間を共有することである。従来、例えば、CG 映像を駆使してユーザを包囲する巨大な仮想空間を構築し、それを高速ネットワークを介して共有することによってこのような目標を実現しようとする試みは幾つか見られた。しかし、言うまでもなく、実世界に居住するユーザを仮想空間に置くことは不自然であって、ユーザが実世界に存在したまま遠隔に存在す
る相手と空間を共有する状況を作り出すことが理想である。
一方、従来の超高速ネットワークに関する研究開発では、大容量の映像等を効率的に伝送する方式等については重点的に研究開発が進められてきたが、実世界をベースに空間共有を実現するために必要な、実世界の環境やオブジェクトの情報も同時に伝送することを考慮した技術開発はあまりなされてこなかった。すなわち、今後は映像コンテンツに代表されるブロードバンド情報と実世界の様々な環境・オブジェクト情報の双方を効果的に組み合わせた、新しいコミュニケーション技術を開発していく必要がある。現状では、これらの情報を統合してサービスを提供するプラットフォーム
技術は存在せず、またその上の優れたユーザインタフェースを持つシステムは開発されていない。
5.4.1.2

研究開発の目的

本研究では、超高速ギガビットネットワークによって伝送される映像と実世界に存在する各種の情報の双方を、ユーザに利用しやすい形で統合してサービスを展開する
ためのプラットフォーム技術を確立し、遠隔の相手との空間共有を可能にして従来の映像コミュニケーションを質的に越えるコミュニケーション方式を確立することを目的とする。検討にあたっては、本方式を双方向、さらには多地点間で展開することを念頭に、多地点間の複数大容量リアルタイム映像の配信及びそれと連携した遠隔制御
情報伝送に関する技術の検証を行うことも目的とする。
研究の過程では、地域利用型アプリケーション実験を行い、今後の超高速ギガビッ
トネットワークの一つの利用イメージを具体的に描き出すことにより、広帯域・高品質の超高速ギガビットネットワークのアプリケーションによる実利用の促進に資するものである。
5.4.1.3

研究開発の進め方

本研究では、インタラクションミラーと呼ばれる AR（=Augmented Reality）技術をベースに、実世界の映像やオブジェクトの情報から成る共有 AR 空間の超高速ネットワ- 252 -

ークを介して構築し、その中でユーザの動作によるインタラクションが可能なサービスを実現する技術開発を行う。
単なる映像コミュニケーションを越えて、遠隔に存在する物や人にごく自然な身体動作によって制御情報の伝送を可能にする。また、それらを双方向、多地点の場合に拡張し、地点間を自在に移動しながら身体動作でコミュニケーションできる技術を確立する。具体的には以下の 3 つについて進めていく。
（１） 適応型サービス制御技術に関する研究開発
多地点に存在するインタラクションミラーの間を、ユーザがシームレスに渡り歩きながら物や人とコミュニケーションを行うための、ユーザ身体動作適応型サービス制
御手法とシステム構成、映像・マーカ情報転送・管理手法、映像合成手法等について研究する。検討にあたっては、まずこれらの技術を用いて超高速ギガビットネットワ
ークで結ばれた 2 地点間コミュニケーションの実現を行い、その知見を用いて多地点間へ拡張する（「図 0.1

インタラクションミラーを用いたコミュニケーションイメ

ージ参照）。さらに、ユーザの多様なインタラクションに対応できる動的サービス制
御手法の検討を行う。

アイコン

Camera共有空間表示：実世界デスクトップ

Camera

ON
L

OFF

H

ここ。

NW

ディスプレイ
ここ。

共有空間表示：自分の映
共有空間表示：自分の映像、相手の映像、情報を像、相手の映像、情報を重合して描画（AR）
重合して描画（AR）

触らずタッチ：共有空間内の物
触らずタッチ：共有空間内の物や情報に、映像上で手を重ねや情報に、映像上で手を重ねる（“タッチ”）だけで作動る（“タッチ”）だけで作動
AR：Augmented Realityの略

図 0.1

インタラクションミラーを用いたコミュニケーションイメージ- 253 -

（２） 高度 HCI 技術に関する研究開発
インタラクションミラーを用いて多地点間で自在に人や物とのコミュニケーションを実現するための、ユーザ身体動作認識手法、マルチモーダルなインタラクション
手法等に関する研究を行う。システムが一方的に認識するのではなく、ユーザとシス
テムの協調によって安定して実世界情報の取得、制御、制御情報の伝送が行える環境の実現を目指す。
（３） プロトタイプアプリケーションの研究と検証実験
自然な身体動作やマルチモーダルな入力を用いて超高速ギガビットネットワークで結ばれた多地点間をシームレスに移動し、移動先に応じたサービスが合成されるア
プリケーションを、上記で検討したプラットフォームを利用しながら検討する。この
アプリケーションを用いて、HCI の観点から総合的に評価・実験を行い、本研究の実用性について評価・検証を実施する。
また、インタラクションミラーと JGNⅡとの関連性を以下に述べる。
本研究開発テーマの究極の目標は、コミュニケーションの相手と、あたかも同じ空間を共有しているかのような状況を作り出すことである。通信の究極の目標の一つの形は、遠隔にいてもローカルにいても、その相手と同じ場所に居るかのような状態を作り出すことであると考えられる。本研究開発テーマでは、鏡のメタファを用いることで上記の目標を目指す。同じ鏡に映っていることを利用して、相手も自分と同じ場
所に居るかのような状況を実現する。そのような鏡を、現実の鏡と同じように高画質
かつリアルに構築するには、高精細の映像を遠隔地から伝送することが必要である。
さらに多地点間において同様な環境を実現するには、映像を多数同時に伝送する必要があり、JGNⅡのような広域・広帯域のネットワークが必須となる。
5.4.1.4

研究開発の目標

実世界のマーカ情報や遠隔地のリアルタイム映像といった様々なブロードバンド
情報を伝送し、ユーザに利用しやすい形で統合し、双方向あるいは多地点間でサービスを展開するプラットフォーム技術の実現、およびプラットフォーム上でユーザの動作を利用して遠隔地に存在する機器の操作指示や制御等が自然に可能になる技術の実現を目標として、具体的には以下の数値目標を設定する。
平成 16 年度：

（１）2 拠点を結んで上記を実現（２）1 個のマーカを利用した操作を実現- 254 -

4 年後：（１）4 拠点を結んで上記を実現（２）2 人以上のユーザが居てもマーカ無しで（すなわち素手で）種々の操作を行える環境を実現

以下に多地点（3 拠点以上）の場合のシステムの実現イメージを示す。

JGNⅡ
多地点間の映像伝送
ON

L

H

ON

OFF

３地点の共有空間表示

Camera
L

ここ。

H

OFF
ここ。

ON
OFF

ここ。

図 0.2

5.4.2

インタラクションミラーを用いた多地点コミュニケーションイメージ

平成 16 年度の成果

平成 16 年度の成果は、主に以下の通りである。
（１） 適応型サービス制御技術に関する研究開発
つくば JGNⅡリサーチセンター内に、インタラクションミラーを用いた、2地点間を接続した双方向コミュニケーション実験システムを構築（5.4.1.4 研究開発の目標における平成 16 年度の数値目標を達成）
JGNⅡ上での DV 映像マルチキャスト配信実験による映像配信動作確認試験を実施（２） 高度 HCI 技術に関する研究開発
実験システムにおいて、ユーザがディスプレイに触らずに画像上の物体やアイコンとインタラクションするために、入力画像中から色の付いた１個のマーカをリアルタイムに認識する機能を実現（5.4.1.4 研究開発の目標における平成 16 年度の数値目標を達成）- 255 -

（３） プロトタイプアプリケーションの研究と検証実験
つくば市との連携に向けた体制とプロトタイプアプリケーション（案）を検討
順にその詳細を記述する。
5.4.2.1

実験システムの構築

5.4.2.1.1

構築した実験システム

今年度はつくば JGNⅡリサーチセンター内にインタラクションミラーを用いた、双方向コミュニケーション機能をもつ実験システム（高度 HCI 技術を活用した適応型サービス制御の研究開発システム）を構築した。以下にシステムの実現内容を示す。
（１）2 拠点の環境構築（平成 16 年度目標）
ネットワークで接続した遠隔地間（2 地点間）で、自分の映像と、遠隔地の映像、情報、CG 等を重合表示する以下の擬似的な共有空間を実現した。
2 地点を Gigabit LAN で結合し、カメラ映像を相互に伝送
各地点では、自地点の映像と相手地点の映像を、鏡像かつ半透明にして重合し共有空間表示を実現
アイコン等の CG 画像も重ねて表示
各アイコンには実物体（家電製品等）の機能が対応（２）1 個のマーカを利用した操作（平成 16 年度目標）
画像認識により、共有空間に存在するもの（リアル・バーチャル双方）に、直接触らずに“タッチ”して作動する以下の機能を実現した。
手に持った 1 個のマーカの位置を色認識によって追跡し、アイコンに“タッチ”することによってインタラクションを実現
本システムは「こそあど」言葉等のあいまいな表現を使った指示で、注目箇所等のこちらの作業意図を伝達したり、相手と同じ場所に居るような同室感を醸成することができるなど、ユーザが利用しやすいという特徴をもつ。
以下に本研究で実現した双方向コミュニケーションのシステム構成を示す。

- 256 -

≪SITE B≪SITE A ≫カメラ

カメラ
100BASE
HUB

マーカ位置情報

マーカ位置情報

画像処理用 PC
画像重畳用 PC

GigaHUB
ユーザ画像
コマンド情報100BASE LAN カード
100BASE LAN ケーブル
1000BASE LAN カード

管理用 PC

1000BASE LAN ケーブル

図 0.3

双方向コミュニケーションのシステム構成

Ａ地点（SITE A）、Ｂ地点（SITE B）それぞれに、大画面ディスプレイ（PDP）、カ
メラ、PC 及び周辺機器があり、Ａ地点とＢ地点はギガビットネットワーク（1000M）で接続している。また、各地点はローカルにネットワーク接続（100M）された 2 台のPC で分担して処理を行っており、同地点で入力された１つのカメラ画像は、2 台の PCに分配して入力される。そのうち 1 台の PC（画像重畳用 PC）は、自己像と、送られてくる遠隔地画像と、CG 映像を各々半透明化して重合する処理を主として行う。もう 1台の PC（画像処理用 PC）は、入力画像からマーカの位置を認識する画像処理を行い、得られた結果（x,y 座標値）はローカルネットワーク（100M）を介して重合処理 PC へ
リアルタイムに送られる。重合処理 PC 側では送られてきたマーカ認識位置情報（画像上での x,y 座標値）と、物体やアイコンの表示位置情報から、マーカの“タッチ”判定を行い、その結果に応じて機器操作や情報表示等のコマンドを発行する。
以下に本システムの全体構成図、レイアウト図、設備写真及び使用風景を掲載する。

- 257 -

図 0.4｢高度 HCI 技術を活用した適応型サービス制御の研究開発システム｣
全体構成図- 258 -

図 0.5｢高度 HCI 技術を活用した適応型サービス制御の研究開発システム｣
レイアウト図- 259 -

図 0.6｢高度 HCI 技術を活用した適応型サービス制御の研究開発システム｣

設備写真（左上：A 地点側、右上：B 地点側、下：研究開発システム設備類）

図 0.7｢高度 HCI 技術を活用した適応型サービス制御の研究開発システム｣
風景写真（左：A 地点側、右：B 地点側）

- 260 -

5.4.2.1.2

実験システムの実現機能

実験システム構築において必要な機能について検討した。検討内容及びその結果実現した機能について、以下具体的に説明する。
（１）2 拠点の環境構築
本研究における実験システム構築の目的は、実世界の映像やオブジェクトの情報から成る AR 空間を超高速ネットワークを介して共有し、その中におけるユーザの動作によるインタラクションが可能な遠隔地間でのコミュニケーションサービスに関する基盤的技術を検討、整備することにある。
従来、遠隔地間の映像コミュニケーションには、TV 会議システムや TV 電話等様々な方法が提案されている。しかし、このような従来の方式では、映像と音声の通信は可能であっても、互いの映像は画面上で別々の画像として表示され、相手映像中に存在する人や物体を選択したり、相手映像中の位置を指示したりする等、相互に関わり合う作業が不可能であったため、意図の伝達がしにくいという問題があった。これは、TV 電話等の映像コミュニケーションの普及を促進する上で大きな問題であると考えられる。これを解決するために、本研究では、ヒューマンインタフェースとして、映像を用いて仮想的に共有空間を構築し、その中で互いにインタラクションが可能な環境を構築することにした。具体的には、相手の映像と自分の映像を各々半透明にして、それぞれの地点でユーザが見ている画面に重合表示する方式を採用した。これはインタラクションミラーと呼ばれる。相手の映像も自分の映像も重ねて表示することにより、ユーザは相手の映像中の人やモノの画面上の位置を相手と一緒に指さして、容易かつ自然に意図を伝達することが可能になる。
遠隔地間で映像を重合する従来手法には、どちらかのユーザの人物領域を画像中から切り出して（背景を除去して）、もう一方の映像に重ねる手法がいくつか提案されている。このような方法では、一方のユーザ側（人物領域を切り出す側）の撮影条件として、ブルーバックのような大掛かりで特殊な撮影環境が必要であった。これに対し、本手法は、両映像を画像処理によって半透明にして重合するという方式であるので、いずれの地点のユーザも任意背景での撮影が可能であり、様々な利用シーンに応用可能となるとともに、高い利便性が期待できる。
また、同じ鏡に映っていることを利用して、相手も自分と同じ場所に居るかのような状況を実現することが本手法の特徴であるが、その鏡を現実の鏡と同じように高画質かつリアルに構築するには、高精細かつ低遅延で映像を遠隔地間で伝送することが必要である。映像を伝送する方法には、一般に MPEG2 や MPEG4 等のように画像を圧縮した上でネットワーク上をリアルタイムに伝送する方法と、近年の PC やビデオカメラ
等でも広く用いられている DV 映像（IEEE1394）を用いる方法が候補として挙げられる。

- 261 -

前者の MPEG 映像は、画像を圧縮して伝送するので、帯域幅が狭い伝送路を用いる場合には非常に有効であるが、エンコードとデコードの処理時間による遅延が生じることと、圧縮による映像品質劣化の問題がある。これに対し、後者の DV 映像は、伝送時に、より大きな帯域幅を必要とするが、圧縮等による処理遅延や映像品質劣化はほとんど生じない。
本研究では、将来の大容量ネットワークを想定したギガビット実験ネットワークであるJGNⅡを効果的に利用し、未来の先端的な映像通信コミュニケーションの研究及び実験を行うために、DV映像を用いたリアルタイム映像通信実験が可能なシステムを構築することとした。具体的には、遠隔地間で伝送する映像の方式をDV映像とし、その他に操作結果のコマンドもネットワーク上で送受信する。MPEG映像を用いた映像伝送については、利用シーンによっては必要な場合も考えられることから、今後具体的なアプリケーションを検討する上で必要に応じて構築等の検討を行う。
（２）1 個のマーカを利用した操作
遠隔地の人やモノに対する、操作や情報表示等のユーザによる働きかけを可能にするため、自己像表示とマーカを用いた画像認識処理による非接触型のポインティング機能を採用、実現した。これによってユーザは共有空間の中で遠隔の物体等に「触る」ことができるようになる。
自己像表示を用いてポインティングを行う従来手法として、画面上のコマンドアイ
コン等を選択してローカル PC 上のアプリケーションのインタフェースとする手法は発表されている。しかし、本研究で必要となる実世界中のリアルな物体に対する直接的な機器操作やその情報へのアクセス、更には遠隔地の物体に対する操作は考慮されてこなかった。これに対し、インタラクションミラーは、実物体情報の登録を可能とし、リモートコントロールによる登録済み物体の操作や関連情報提示を行うインタフ
ェースを備えることで、コンピュータの外の実世界とのインタラクションも可能とす
る、新規な実世界指向インタフェースシステムとなっている。
本研究におけるポインティングは、画面に映っている自己像を、映像中の物体像やアイコンに画面上で重ねる（“タッチ”させる）ことを基本としている。これによって、
あたかも実際に触っているような印象で、遠隔地にある家電機器等に“タッチ”して操作をしたり、その関連情報を画面に表示させたりすることが実行可能である。“タッチ”の認識は、自己像を撮影しているカメラの入力画像を用いた画像認識処理で行う。
平成 16 年度は、ユーザは、色の付いた 1 個のマーカ（認識可能な彩色であれば任意の物体で可能）を持ち、それを物体像やアイコン等の上に画像上で重ねることで実現することとした。システムは、ソフトウェアによる色認識処理により、ユーザが持つマーカの位置をリアルタイムに認識することができる。これにより、従来のタッチ
パネルと異なり、画面に直接触らずに、離れた位置から画面上の物体やアイコンへの- 262 -

“タッチ”が可能になった。マーカの認識は、予めマーカの色を登録することにより任意の色の物体を使用できるようにした。ただし背景に同じ色の物体等がある場合は誤認識する可能性があるが、その場合には背景に少ない色のマーカに登録を変更すればよい。色の登録・変更は、使用したい物体をカメラに提示するだけで登録できるインタフェースを作成することにより、システム動作中でも容易に変更可能とし、実使用時の利便性を確保した。
16 年度構築したこれら機能及び特徴を持った基盤システムについては、今後引き続き実験しつつ問題点を検討しながら改善を図っていくとともに、具体的なアプリケー
ションシステム実現に向けた検討を行っていく予定である。
5.4.2.2

JGNⅡネットワーク利用のための確認試験

双方向コミュニケーション機能をもつ実験システムの構築にあたり、今後実験ネッ
トワークとして JGNⅡを利用していくことを目的として、利用手順の確認及び動作の確認を行うために、実際に JGNⅡを用いた映像配信を試みた。
（１） つくばアクセスポイントの利用者への接続設定・通信確認などの支援を通じて、下記の把握をした。
a. 足回り回線と JGNⅡスイッチ間の 100Base-TX 関連の設定確認（たとえば、AUTO-FULL の不一致時は、リンク確立ができないか、FULL-HALF の不一致となり、双方向通信ができなくなる）
b. 足回り回線で 10G の光接続時の到達性をロス測定により確認
c. 実際に流れているトラヒック図（MRTG）を参照し、疎通状況を把握し、異常の有無を判断する。
（２）これまでの JGNⅡを利用した映像配信として、6Mbps の中規模の帯域を使用する
MPEG-2 映像と、最近普及している 30Mbps の大規模の帯域を使用する DV 映像が広く利用されている。HCI 研究では相手側との操作性の一体感が重要であることから、遅延が少なく映像品質の良い DV 映像を用いることとした。
そのための JGNⅡ利用の事前評価用回線として、つくばから北九州折り返し、及び関東折り返しの 2 つのパスを設定し、つくばにて送受信が出来るようにした。
最初に実施したつくばからの PING 試験では、北九州が 40ms（送りまたは受けのみ
で 10ms の遅延を生じる）、関東が 2ms を得た。またロングサイズの PING も良好に通じていることを確認した。
また、使用ビデオ機器にもよるが、カメラで撮影してそのままプロジェクタ表示するだけでも 100ms 程度の遅延が生じることから、発生の遅延は通信に依存するという- 263 -

よりも、各地点で使用している機器に依存する割合が大きいと分かった。
映像通信試験としては、既製の DVcommXP のソフトを用いて、ユニキャスト、マルチキャストそれぞれの JGNⅡの通信試験を実施し、遅延の少なさと良好な映像品質（MPEG2 に比較して、PPT の表示をカメラ撮影しても、受信映像の文字の可読性が格段に良い）を確認した。
実際の通信評価として、2005 年 3 月 14 日に実施したつくば JGNⅡリサーチセンタ
ーセミナーの実況を図 5.4.8 のように折り返して北九州、関東各地、岩見沢宛にマルチキャスト配信をした。マルチキャストの場合は、トラヒック量が増えることが無いだけでなく、各受信側の状況を確認することなく受信側の意図で参加･離脱ができるという利点がある。
つくばＪＧＮＩＩリサーチセンター
関東５
Mcasｔ（234.5.6.7）
カメラ

（つくば）

関東2

関東１

（ＫＤＤＩ）（ＮＴＴ）

九州２

北九州ＪＧＮＩＩリサーチセンター（NICT北九州）

送信PC
PDP
関東７
（宇都宮）

ＳＷ-ＨＵＢ

受信ＰＣ
宇都宮大

関東９
（NICT本庄）

ADVC

VLAN：
1095
1094

NICT本庄センター

DVIP
北海道

1093
1092

岩見沢自治体ネットワークセンター

ＪＧＮＩＩ－ＳＷ

1035

図 0.8

JGNⅡを用いた DV 映像のマルチキャスト配信実験（つくば JGNⅡセミナー映像のリアルタイム配信を実施）
5.4.2.3

つくば市との連携

本研究の実用性について評価・検証を実施するために、つくば市をフィールドとした実証実験を行うことを検討している。本研究開発による成果をつくば市のような実フィールドに展開することによって、地域活性化、市民サービス向上、業務効率化等に貢献できるかどうかを検証する。
今年度は、実証実験の基礎検討を実施した。体制としては、つくば JGNⅡリサーチセンターが研究開発の実施主体となり、つくば市が実証実験のためのフィールド提供を行うことを想定している。つくば JGNⅡリサーチセンターにおける研究開発は、センター長、拠点研究員及び特別研究員が中心となって進める。またつくば市は、市内- 264 -

の市関連施設の利用とともに、研究者、学生等の IT サポータの参加を検討している。
また研究開発時の技術的なサポート担当として、NTT コミュニケーションズ及び NTT
マイクロシステムインテグレーション研究所が支援する。
また、具体的なアプリケーションとして現段階では、以下のような博物館美術館等を対象とした遠隔教育における活用を検討している。本アプリケーションでは、つくば市の市民、特に学生、生徒等に臨場感あふれるシステムを活用した学びの場を提供するとともに、最先端ＩＴ技術に直接触れることの出来る機会、場所の提供を実現することを想定している。

遠隔地の史跡や名所、美術館、博物館等とネットワークで接続し、遠隔地のリアルタイム映像に自分の像（姿）を投影することで、あたかもその場所にいるような感覚で、実体験的な学習を可能とする
ローマ
ローマ
BC500年頃
BC500年頃
作者不詳
作者不詳

現実の博物館内の部屋

ユーザ：
他所に居る

：マーカ

左手挙げる→左に進む。
右手挙げる→右に進む。

手を出す→前に進む。
手を戻す→後に進む。

マーカに“タッチ”→オブジェクトの情報表示

説明員

他のミラーから遠隔見学に来ている人たち

その部屋に実在している人
マーカを付けた説明員に“タッチ”すると説明をしてくれる。

ドアに“タッチ”すると他の部屋（別の博物館かもしれない）に移動。

図 0.9
5.4.2.4

自分だけでなく他所からも遠隔見学。
（多地点間コミュニケーション）

実証実験アプリケーションイメージ

対外発表

以下に対外発表について示す。
細谷、北端、佐藤、原田、小野澤＜特別研究員＞:“ミラーインタフェースを用いた双方向型インタラクティブコミュニケーシ
ョンの実現”, 2005 年電子情報通信学会総合大会, A-16-20, 2005 年 3 月 23日.
：インタラクションミラー（=ミラーインタフェース）を用いた双方向コミュ
ニケーションシステムの概要について発表。

- 265 -JGNⅡ研究開発プロジェクト研究開発報告書
発行日：平成１７年３月３１日
報告者：JGNⅡ研究開発プロジェクト
東北 JGNⅡリサーチセンター
大手町 JGNⅡリサーチセンター
つくば JGNⅡリサーチセンター
大阪 JGNⅡリサーチセンター
岡山 JGNⅡリサーチセンター
高知 JGNⅡリサーチセンター
北九州 JGNⅡリサーチセンター
発行者：独立行政法人情報通信研究機構（拠点研究推進部門）〒105-0014
東京都港区芝 2-31-19 バンザイビル
TEL 03-3769-6865

FAX 03-5439-7320