１．担当ＰＭ

　竹内　郁雄 　　（東京大学大学院教授）

２．採択者氏名

３．プロジェクト管理組織

　株式会社創夢

　3,000,000円

５．テーマ名

　インターネットにおけるプレゼンテー ション、セション層相当、汎用プロトコルの開発

６．関連Webサイト

　なし

７．プロジェクト概要

　現在のインターネッ トは，OSI基本参照モデルのアプリケーション層，プレゼンテーション層，セション層を一つのアプリケーション層とすることで規模拡張性を確保している． 従来のインターネットではアプリケーション (以下APP) は単純であり，プレゼンテーション層，セション層相当の機能は必要ないことも多かった．
　しかし，近年のインターネットAPPの多くに対して共通に求められる機能がある．すなわち，認証，暗号化，セション管理である．また，今後求められる機 能として，構文変換 (文字コード，他のフォーマットなどの変換)，圧縮，コネクションの仮想化，QoSに応じた通信品質保持，新規に導入される下位層プロトコルへの自動対応 などでが挙げられる．

　これらの次世代ネットワークAPPの要求に応えるプロトコルの設計と開発が，本プロジェクトの目的である．
　プロトコルの最終目標は以下の通りである．各カッコ内はメリットを表す．
(1) 自由度の高い認証システム [認証方式の統一]
(2) 暗号化 [APP開発の負荷軽減，セキュリティ確保]
(3) セション管理 [APP開発の負荷軽減]
(4) 圧縮 [ネットワークリソースの有効利用]
(5) 構文変換 [APPのサービス提供対象の拡大]
(6) 拡張機能のモジュール化 [機能拡張がより柔軟・容易になる]
(7) 既存プロトコルを使ったトネリング [環境制約の軽減]
(8) APPのQoS要求に対応 [APPのQoS管理からの解放]
(9) P2Pを用いた独自の (非階層分散型ベストエフォート) アドレス解決システム
[新しいアドレス空間の提供，NAT，FW越え]
(10) P2Pによるマルチキャストシステムおよびキャッシュ持ち合いシステム
[ネットワークリソースの有効利用]

　本プロジェクトの開発期間では下記の項目を実装した初期バージョンのWindows版リリースを目標とする．
　2種類以上の認証，暗号化，圧縮．文字コード，及び画像フォーマットの動的変換．セション管理．HTTPプロクシを使用したトネリング．

　

８．採択理由

　若いのになかなかの筋 金入りと見た．提案はあまりにも盛りだくさんで，本当に大丈夫かいなと思いたくなるが，これまで有名無実だったプレゼンテーション層とセッション層をプロ トコルとして実体化するという提案は7層モデルの「落し前」をつけるという意味で面白い．通信ミドルウェアとどう違うの?という質問にしっかりと答えられ るような成果を上げてほしい．ちょっと欲張った計画だが，優先順位をつけてきちんとやれば，多くの人に認められて，サポートも増えるだろう．実際，プロト コルというのは政治的に大変だが，まず技術を固めるというステップだ．

９．成果概要

　(1) IQLの定義
　当初インターネットアプリケーション層からOSI 7階層モデルのセション層とプレゼンテーション層を切り離して，プロトコルを定義する計画だったが，開発を進めるにつれ，開発内容・目的が上記の2層で定 義されている機能の範囲には収まらず，よりインターネットに相応しい切り分けが必要であると考え，インターネットのアプリケーション層の下に位置する独自 のレイヤIQL (Intelligence and Quality Layer) を定義した．
　IQL上で定義した機能はインターネットアプリケーションが共通して必要とするものであり，現在のインターネットアーキテクチャのアプリケーション層で 個別に実装されている機能である．具体的には，IQL上の機能として，暗号化，認証，下位層通信媒体の管理単位として定義したJarad (従来のセションに相当するものとして新たに命名) の管理を含ませた (圧縮，フォーマット変換は未実装)．
　また，IQLの下位層は基本的には従来のトランスポート層となるが，今後のインターネットの拡張を考え，あらゆる媒体 (レイヤ) を下位層にもてるように，IQL内にIQ Media副層 (IQML) を定義し，そこで通信媒体の抽象化を行なった．これは既存のトランスポート層や，データリンク層が提供するメディア抽象化の概念を拡張したものであり，読 み書きさえ可能であれば，あらゆる媒体をIQLの下位媒体として利用できるようにするための仮想レイヤである．
　End-to-Endで実装し，かつアプリケーションに深く関連する機能をアプリケーション層の下にIQLとして定め，下位層すべてをIQ Mediaとして抽象化したネットワークアーキテクチャが当開発の特徴である．
　IQLを導入したインターネットアーキテクチャを図2.4.1 IQLを導入したインターネットアーキテクチャ に示す．また，IQLを用いたサービスの構成を図2.4.2 IQLを用いたービスの構成図 に示す．

　　 図 2.4.1 IQL を導入したインターネットアーキテクチャ

　(2) YJPの開発
　YJP (開発コード名) は本プロジェクトで開発，実装を行なったIQL上のプロトコルである．Windows (2000以降) 上のサービスとして実装した．データ変換，認証，IQ Mediaをプラグイン形式で実装し，ユーザが自由に追加できるようにした．アプリケーションとの接続は名前つきパイプとラッピングしたDLLで提供す る．ただし，ネットワークプロトコルとして公開できるまでにはさらに仕様を固める必要がある．
　YJPではIQLのサービスアクセスポイントを名前つきパイプで実装し，名前つきパイプ上にAPIを定義した．実際にYJPを利用するアプリケーション が名前付きパイプを管理するのは手間がかかるので，名前付きパイプをラッピングしたDLLを実装し，通常のAPIを使用する感覚でYJPを利用できるよう にした．Windows標準のDLLで実装してあるため，DLLが利用可能な言語であればYJPを使用することができる．

　　

　　　 図 2.4.2 IQL を用いたービスの構成図

　　 プラグインは認証プラグイン，プレゼンテーションプラグイン，公開鍵暗号プラグイン，共通鍵暗号プラグイン，IQ Mediaプラグインに分類される．認証プラグインはIQL間の認証機能を提供し，プレゼンテーションプラグインはデータ変換に関わる拡張機能を提供す る．レイヤ上のデータ変換には，圧縮，暗号化など送受信双方でデータ変換を行なうものと，文字コード変換のように送信または受信の一方のみで行なうものと の2種類があるが，同種のプラグインとした．IQ MediaプラグインはIQLのサブレイヤIQ Mediaレイヤの実装であり，通信媒体のラッピングである．データの読み書きさえ可能であればあらゆる媒体をアプリケーションで利用できるようになる． 効率，遅延を無視するなら (実用性は別にして) 通常のファイルやマイクとスピーカーでもネットワークの通信媒体として利用可能となる．既存のアプリケーションプロトコルを利用したプラグインを作成すれ ば，トネリングも容易に実装できる．プラグインによるMediaのこのような抽象化は今後新しい通信媒体，プロトコル上への対応を容易にする．
　開発期間には，YJP用のAESによる共通鍵暗号プラグイン，RSAによる公開鍵暗号プラグイン，TCP用のIQ Mediaプラグインを実装した．また，機能拡張が目的のプラグインではないが，ログメッセージなどの文字列を管理する関数群をプラグイン形式で実装し た．メッセージの翻訳さえできれば，容易に複数の言語に対応可能である．今回は日本語のみ作成した．
　YJPではIQ Mediaプラグインがコネクション型であるかどうかに関わらず通信コネクションの仮想化をJarad (ルーン文字で約束を表すJaraと乗り物を表すRadを合成した造語) という単位で行なう．これは従来の階層モデルのセションに当たるものであり，コネクションの状態を管理し，切断時の再接続をサポートする．アプリケーショ ンはJarad IDによりJaradを制御する．
　Jaradは実装できなかったが，Jaradのスリープ及びシリアライズの仕様を定義した．この機能により接続をデータとして保存しておき，通信が必要 なときに随時復元が可能となる．さらに，Jaradを複数まとめて管理する単位としてPort Townという概念を定義した．Port Townはマルチキャストをインターネット上に実現するための機能である．
　プレゼンテーション相当機能のデータ変換用にIDCF (IQL Data Conversion Format) を定義した．これは既存のWebのMIMEと似たもので，今回の実装ではテキスト形式のみ定義した．今後，画像やXML等にも対応していく予定である．

１０． ＰＭ評価とコメント

　OSIの7階層モデル は教科書では見たことはあれど，セッション層 (前田君はセション層と書くが，慣例に従い，私はセッションと書く ― 実はSessionと打つと自動的にそういうカタカナになる仕掛けになっている) とかプレゼンテーション層は一体どこへ行ったという疑問を関係者は一度はもったことあるだろう．OSIは御上的なところなので，草の根デファクトスタン ダードのインターネットは関係ないといってしまえばお仕舞いだが，それなりの理由があってこの2つの層が提案されたという事実は無視できまい．
　前田君は議論は次の通りである．本来のネットワーク階層化のメリットはレイヤ間に抽象化の壁をつくることであり，同レイヤであれば，プロトコルの入れ替 えを可能にすることであった．しかし，現在のインターネットにおいては，ネットワーク層以上はアプリケーションが決まれば各レイヤのプロトコルも自動的に ほとんど決まってしまう．また，特定の目的に対して定番のプロトコルがあり，そういう意味での階層化のメリットもなくなってきている．
　さらに，SSHのポートフォワードや，VPNに見られるように単純な固定階層のネットワークアーキテクチャ (7レイヤ，5レイヤモデル) を適用できないネットワーク形態が現れてきている．今後，P2Pによるオーバーレイネットワーク等が普及すると，単純な固定階層ネットワークアーキテク チャが適用できない状況がさらに増すと考えられる．
　ネットワークアプリケーションに求められる機能が高度になればなるほど，簡略化した現在のアーキテクチャではアプリケーションが本来持つ必要のないネッ トワークの機能まで負担しなければならず，肥大化，複雑化していく．近年のWebサーバーなどがその典型例である．今後更にネットワークアプリケーション の高機能化が進むことは必至であり，アプリケーション開発の負担は更に増すことになる．このまま進めば全てのアプリケーションが個別にTCPを実装するの と同じ位，冗長で歪んだ状況になる可能性がある．この流れを止め，ネットワークをあるべき姿に戻すことが重要である．すなわち，端末のアプリケーションに 関わる部分のネットワークアーキテクチャをきちんと定めて，階層を抽象化することが有効である．
　ならば，セッション層とプレゼンテーション層を一度真面目に設計・実装しようと前田君は考えた．すでにそのあたりのものは，通信ミドルウェアとしていろ いろなものが出回っているが，それに対抗して，ちゃんとしたプロトコルとして提案・実装しようとしたわけである．
　ちょっと考えただけでも相当無謀な計画であることがわかる．少なくとも独りで半年で終えられるスケールではない．だが，PMは敢えてGoサインを出し た．誰もあまりやろうとしていないのであれば，この問題に突っ込むことで，なにか新しい展開が見えるかもしれなかったからである．
　実際，プロジェクトが始まってから前田君は単純にセッション層とプレゼンテーション層をOSIの階層通りにつくっても間尺に合わないことにすぐに気づ き，IQLとその上のプロトコルYJP (この名前の由来が面白い．Googleで非常に見つかりにくい3文字で，プロトコルっぽいものを探して見つかった名前だそうである) さらに，すべてのメディアを下位層にもてるようにIQMLを設計し，いってみればインターネットの階層に久々にメスをいれた感じのものを設計してしまっ た．
　さすがにこれだけのことをしたので，設計も実装も作成途上になってしまった．実装作業を考慮すると，これからも相当長い道のりが必要と思われるが，重要 なところから順番につくりあげていって，世の中に問うていけばいい．プロトコロ設計について新しい知見を提唱していることは間違いないので，仲間を増やし ていく努力がこれから必要だろう．まずはこのプロトコル体系でアプリケーションをつくるとこんなに旨味があるということを実証することが肝要である．

　前田プロジェクト自体は特に実装に関して未完の状態で終わったが，ここまでに得られたプロトコル設計の概念はとても面白いし，有用性も高いと思う．彼自 身のプログラミング能力も十分に高い．インターネット新時代に向けて，まだ若い前田君の将来の伸びに期待して，ちょっと甘めかもしれないが，スーパークリ エータの称号を上げたい．