【 通信インフラストラクチャを目指したIPネットワーク 】


電子情報通信学会会誌
Vol.83, No,4 pp.257-262

Brian E. CARPENTER

寺 本 昌 作(訳)

Brian E. CARPENTER:IBM Corporation 寺本昌作:正員 日本アイ・ビー・エム株式会社 公共システム事業部
E-mail: stera@jp.ibm.com

IP Networks Prepare to Become a Communications Infrastructure.By Brian E.CARPENTER, Nonmember(IBM Corporation, Evanston, IL 60201, USA),Translated by Shohsaku TERAMOTO, Member(Public Sector, IBM japan, Tokyo, 103-8510 Japan).


Abstract
インターネット上の通信は,もともとエンドツーエンドにわたる途中のノードでいかなる遷移状態をも持たぬ(ステートレス)透過性に基づく堅牢性(robustness)を維持してきた.それがゆえにエンドツーエンドでのサービス品質(QoS)保証は困難であった.昨今のインターネットビジネス拡大はこの透過性を脅かしてきているが,IPv6及びエンドツーエンドのIPセキュリティ導入によりこの問題も解決されるであろう.リアルタイムサービスに対しては,"インテグレーテッドサービス(IntServ)"並びに"ディファレンシエーテッドサービス(DiffServ)"の概念に基づく品質保証(QoS)技術が適用されてゆこう.

キーワード:サービス品質保証(QoS),インターネット透過性,インターネットアーキテクチャ,IPv 6,ディファレンシエーテッドサービス


1. は じ め に

 インターネットは,その歴史について既に少なくとも3冊の本が出版されたごとく,もう十分に成熟したといってよい.World Wide Web(Web)の歴史についてさえ既に世に本が出された.しかし,インターネットやWebが研究者の世界やシリコンバレーの一部企業の手から,一大潮流となってコンピュータ業界と通信業界へ移ったのは,わずか過去4年の間の話である.これはビジネス,技術の両面から,カルチャーの対立をもたらした.本稿では,技術面での対立の背後にある課題を探索し,将来の解決案を議論する.
この対立には二つの主要な課題がある.すなわち透過性(Transparency)と,サービス品質保証(QoS : Quality of Service)である.これらの課題を,インターネットアーキテクチャの古典的な見解を簡単に紹介した上で,順に論議したい.



2. オリジナルインターネットアーキテクチャと現在の問題点

  1970年代からインターネット技術仕様は,RFC(当初の意味は"request for comments"であった)として長らく出版されてきたが,インターネットアーキテクチャに関するRFCは,驚くべきことに1996年に至ってようやく出版された(1).ただ初期の学術出版物には,アーキテクチャに関する若干の著述が見受けられる(2),(3).
 アーキテクチャの基本理念の一つは,よく知られているとおり,すべてのデータは,インターネットプロトコル(IP)パケットに分割され,各々のパケットには目的地と出発地のアドレスを含む固有のヘッダが付与されて送信されることにある.そして各パケットは完全に独立してネットワーク上をたどり,目的地に到着する.この方式は,ISDNやATMのような回線交換ベースのネットワークと全く異なるのみならず,その他の主要なパケット交換プロトコル,例えばX.25とも大きく異なる(X.25では同一のフローに属するすべてのパケットはネットワークを通して同じパスをたどる).
 本来のインターネット原則は,ネットワーク上のルータがいかなる遷移状態をも持たない("ステートレス")点にある.すなわち,ルータは個々のコミュニケーションセッションの状態についていかなる情報も持たない.より一般的には,これを"エンドツーエンド原則"とも呼ぶ.セッションの両端のコンピュータ以外にはセッション間にクリティカルな単一故障点を持たないことが, 良いインターネットデザインの必要条件である. セッションの切断は,いずれかのエンドシステムの故障でしか生じるべきでない.もし,すべての中間システムがステートレスであれば,自動的にこのエンドツーエンド原則が重んじられることになり,ネットワークは部分的な故障に対して堅牢となる.
 この基本的なアーキテクチャは,今日二つの主要な問題を抱えている.第1の問題は,エンドツーエンド原則が,無視されている点にある.本来パケットは,出発地から目的地まで変更されることなく利用可能なルートで送られることでネットワーク透過性が確保されるべきなのに,この原則はほとんど守られていない.第2の問題は,インターネットのe−ビジネスや,音声・ビデオといったリアルタイムアプリケーションが,より良い品質保証(QoS)を要求している点にある.ステートレスなルータは個別のトラヒックのフローについて全く関知できないことから,これはアーキテクチャ上の挑戦課題であるといえる.



3. 透過性の損失

   透過性の損失が増大している原因究明が文献(4)で行われている.主因は,企業のイントラネット並びに付随するセキュリティファイアウォール,Webプロキシ,及びキャッシュにある.最も問題なのは,ネットワークアドレストランスレータ(NAT)である.これらの装置は,イントラネットとインターネットの境界においてインターネットパケットを遮断し,その出発地から目的地への自由なフローを妨害する.時には,この妨害はアプリケーションの正常な稼動を妨げる(例えば,いわゆる透過性があるはずのWebキャッシュが,実際にはパケットのソースアドレスを書き換え,これによってWebサーバがそのパケットの本来の出発地を判断できずにアプリケーションを破壊することすらあり得る).NATは同様のインパクトを持っており,かつエンドツーエンドのネットワークレベルのIPセキュリティの利用を妨害する.
 一般に,パケットストリームを仲介する装置は,すべて単一故障ポイントになり得る.ファイアウォールは,元来企業ネットワークを保護するために意図されたものだが,これゆえ逆に最も弱点となる可能性がある.
 Webプロトコルを正しく利用すれば,Webプロキシ及びキャッシュの透過性への影響を最小限にとどめることは可能である.しかしながら,根本的にその他すべての透過性の損失を避けるためには,インターネットプロトコルを新しいバージョン6(IPv6)(5)にアップグレードし,そしてファイアウォール型セキュリティではなくエンドツーエンド型IPセキュリティの利用を促進することが,唯一の方法である.これはネットワークアドレス変換を不要とし,トラヒックを仲介する従来型のファイアウォールを不要とする.この技術によってのみ,ステートレス原則が復活し,そのメリットを享受することができる.




4. 今日のインターネット品質

  パブリックなインターネットが,ビジネス及び社会の広範なインフラストラクチャであるためには,そのサービス品質の継続的な改善が必要である.しかし,この改善を議論するにあたっては,ネタ話的なレベルよりいくらかましな程度には,まずインターネットのサービス品質の現状について理解し,その特徴を洗い出してみることが必要である.ここで一つ困ったことは,「良い」品質を定義するパラメータがインターネットの場合に自明ではないことである.
 伝統的なアナログあるいは固定速度のコネクションの場合は,二,三の単純なパラメータによって完全にサービスが特徴づけられる.しかしインターネットの場合は,更に最低二つは考慮に入れねばならない側面がある.一つは,ある程度のパケット損失や遅延揺らぎ(ジッタ)が,正常かあるいは許容範囲と見なされている点,もう一つは,個々のセッションの品質要求レベルが,その時々で変り得る点である.更には,ある種のアプリケーションはサービスの一時的な停止に対して脆弱である側面もある.
 突き詰めればインターネットの振舞いは,根底において伝統的なネットワークよりもはるかに統計的である.これらはちょうど,道路システム(パフォーマンスは統計的に決定)と鉄道システム(パフォーマンスはあらかじめ決定的)との比較にたとえることができよう.
  もちろん,個々のインターネットサービスプロバイダ(ISP)は,契約されたトラヒックの疎通を最適化するようネットワークを設計できる.ただ,通信の両端に単一のISPのみが介する場合にはそのサービス品質は満足でき得るかもしれないが,現実的には,複数のISPをまたがってトラヒックが流れるケースを考えてゆかねばならない.このケースだと,インターネットパフォーマンスは信頼性も一貫性も失いかねないという懸念が生じるが,実際ほとんどのインターネットユーザは個人的にそう見ているようだし,更に十分客観的に裏付けられた証拠もある
 例えば,テルコーディア(6)は,Webのレスポンスタイムについて毎日の調査を行っている.その結果として,ランダムに選ばれたWebサーバに対し,平均してWebの1ページを取り出すために5秒の遅れが報告されている.しかし,5%のページは到着に20秒以上も費やしたり,あるいは3,200bit/s以下の速度でしか到着しない(いうまでもなく,これはテルコーディアの処理容量全体のほんの僅少な部分でしかない). 観測された遅れのうち約33%は,コンテンツにアクセスするためにリモートサーバ自身によって費やされた時間である.残りの2/3の時間は,ネットワーク遅延である.更に,約15%のサイトは,レスポンスを返す以前に完全に故障している.これらの数字は,ざっくばらんに見て1997年末以来ほぼ一定である.
もう一つの直ちに取得可能な統計値として,パケット損失の割合がある.これは,"ping"としてもよく知られている,インターネットコントロールメッセージプロトコル(ICMP)エコー要求の使用によって概要を測ることができる.この測定はネットワークに余分なトラヒックを注ぎ込むため,過剰な注入は測定値を誤らせ得るが,少量のICMPトラヒックならば,ふくそうしたルート上での本質的な測定誤差とはならないであろう.pingテストを走らせて時々刻々としたパケット損失の割合を求め,往復時間の分散の評価値を得ることは,簡単である.複数の大陸間にわたるルート上での組織的な調査が粒子物理学会(7)によって行われたが,幾つかのルート上で,長期平均で最大20%ものパケット損失率が示された.
  もちろん,過剰設備のネットワークでは,パケット損失率やジッタが無視できるほど状況は良好であろう. しかし,いくらネットワーク容量のコストが低下し,劇的にWDM(Wave Division Multiplexing)やテラビット/秒のルータらが開発されてきたといえども,広範な容量過剰状態があまねくこれからの基準(norm)だと思うのは,錯覚である.
 第1に,今後何年にもわたって需要は指数関数的に伸びてゆく一方,ネットワーク容量は非常に限定的なステップでしか増大しないため,容量不足の到来は避けられない.第2に,我々は例えば回線断が起きた際にでも,ネットワーク内にふくそう・閉塞ポイントを生じぬよう対策を打つところまでは,なかなかいかない.第3に,もし成長が安定すれば,経済競争は利ざやの縮小に向かうであろう.ネットワーク容量はいくら安くなるといっても,決して無料ではないため,過剰設備はいずれ淘汰されよう.このように,ネットワーク中には常にふくそうがつきまとうであろう.
  我々が上記から学ぶことは,ふくそう管理こそがインターネットにとって鍵となる要求条件だということである.




5. エンドシステムによる伝統的なふくそう管理

  長距離伝送に9 600ボーモデムが標準に使われていた時代にインターネットが出現して以来,ふくそうは絶えず問題であった.かつ,それはトランスミッションコントロールプロトコル(TCP)(8)開発のための実質的な原動力となった.エンドツーエンド原則は,末端のシステム間にエラー回復機能を限定し,途中のネットワーク要素には非依存であることを求めている.TCPの場合だと,ネットワーク自身がパケット損失のシグナルを送らない(かつ,送れない)ことを意味する.すなわちTCP送出者は,ある時間経過しても相手からパケット受領確認が届かないときに初めてパケットが損失したと見なす.その時点でTCP送出者は損失パケットを再送する.もし一つ以上のパケットが往復時間中に更に失われれば,その伝送速度を低下させる.このようにネットワークがふくそうし,パケット損失が発生すると,TCPはネットワークからの明示的な速度制御を必要とせず,自発的に速度を落とす.
 なお,この方式で速度を低下させない(すなわち,TCPのルールをごまかそうとする)TCP送出者を罰するための技術が幾つか知られている.この場合,ネットワーク要素としてのルータが罰則(9)を課すが,このときもネットワークとエンドシステムの間で信号の授受はない.
  TCPのふくそう応答は現在良好に動作しており,インターネットの動作は完全にこれに依存している.これなくして,ハイパテキスト転送プロトコル(HTTP)及びWebは機能することができないであろう.しかし,パケット損失率が重大なふくそうによって上記に述べたような高いレベルに達したとき,Webスループットへの影響は,非常に厳しいものとなる.TCPは速度が低下したモードの中でほとんどの時間を費やすことになろう.
この状況は,音声あるいはビデオといった新たなリアルタイムサービスにとっては,一層深刻である.これらのサービスは,純粋にデータ転送用に設計されたTCPを利用しない.これら音声,ビデオには,しばしば,確認,再送,または速度低下メカニズムを持たないユーザデータグラムプロトコル(UDP)が適用される.もしパケット損失率が高ければ,リアルタイムストリームは,著しく妨げられ,オーディオあるいはビデオのストリームは,破綻するであろう.しかし送出者はこれについて何も関知せず,単にフルスピードでストリームを送り続け,最初にパケット損失を引き起したふくそうを一層悪化させることになるであろう.
 リアルタイムアプリケーションには,リアルタイムストリーミングプロトコル(RTSP)(10)が使用されたり,RTSP自身も活用できるリアルタイムプロトコル(RTP)(11)が使用されたりする.しかしふくそうしたネットワークの中で,TCP型のプロトコルだけが,パケット損失に対しスループットを弾力的に対応することで生き延び得るのに対し,上記技術はこれら諸問題に対して対処できない.




6. 先行した作業

  前述した課題は古くからある問題であり,当然,この解決を図る試みが過去より行われてきた.インターネットプロトコルのオリジナルのデザインには「低遅延」,「高スループット」,「高信頼性」を示すビット群が「タイプオブサービス(TOS)」のヘッダオクテットに含まれていた.しかし残念なことに,これらの特性がネットワーク間にまたがってどのように実装され得るかを記述した説明は存在しなかった.後の研究(12)で,これらの定義は拡張されたが,依然として実装のためのレシピはなかった. ある種のソフトウェアはこれらのビットをセットしていたが,現実にはそれらはほとんど利用されず,一般的には無視された.より実践的な例として,IBMのシステムズネットワークアーキテクチャ(SNA)では,複数のサービスクラスを定義して識別しており,これによって例えば対話型トランザクションをバッチ処理より優先させていた.
  ST(13)として知られるインターネットストリームプロトコルは,IPと並行して別のコネクションオリエンテッドネットワークプロトコルを付加することで,TCP/IPトラヒックと共存するリアルタイムトラヒックストリームを流すという試みであった.しかしこれは,限定的な実験コミュニティの外に出ることはなかった.
  近年,インターネットエンジニアリングタスクフォース(IETF)において,インテグレーテッドサービス(IntServ)実現のために多大な努力が払われてきた.これは,インターネットにおける特定のサービス品質 (例えばピーク時処理能力や最大伝送遅延)を要求するエンドツーエンドセッションをサポートするメカニズムを規定しようとするものである.IntServモデル(14)は,各々のセッションのためにパス上のすべてのIPルータにリソース確保のモジュールを導入し,各データパケットがルータを通過する際,どの確保されたリソースにパケットを割り当てるべきかをチェックしてアサインする.リソース予約のためには,特別に設計されたリソースリザベーションプロトコル(RSVP)を使用せねばならない.
 IntServの重要な概念は,アドミッション制御である(詳しくは後述する).これは,もし不十分なリソースしか利用できない場合,ネットワークへのトラヒック流入を拒絶するプロセスを意味する.もしRSVP要求が失敗した場合,セッションは開始されない(または品質を落としたモードで開始される).IntServはまた,ネットワークへの入力時に,トラヒック速度を制限(シェーピング)する概念を持っており,パケットは,RSVPによって確保されたリソースに対応した時間間隔をあけて転送される.
 IntServは多くの魅力を持つが,一方で二つの欠点を有する.第1にIntServの実現には,ネットワークパスにかかわるすべてのルータに新しいソフトウェアあるいはファームウェアの導入が必要である.第2は,毎秒数百万パケットもの転送を行う大規模なISPトランクコネクションで使われたとき,必要なチェックとリソース管理にかかるパケット当たりのオーバヘッドが,容認できるレベルを超えると見られていることである.これらの理由から,IntServ及びRSVPは当初は大学構内やまたは小規模企業のネットワークで限定的にしか利用されないであろうと見られている.




7. ディファレンシエーテッドサービスモデルの勃興 

  過去2年にわたり,IETFと産業界では,ディファレンシエーテッドサービス(DiffServ)として知られるInt Servを補足するモデルに対する精力的な作業が行われてきた.これは,大規模システムに適用可能なように,シンプルなシナリオ提供をねらっている.
   DiffServの基本原則は,ネットワークトラヒックが,粗い方法で複数の「ビヘイビアアグリゲート」に振り分けられることにある.一つのアグリゲート(総計)にあるすべてのトラヒックは同じように扱われ,単一のサービスクラスを適用される.例えば,すべての電子メールトラヒックを第1のアグリゲートに,すべてのWebブラウジングトラヒックを第2のアグリゲートに,すべてのオーディオ,ビデオトラヒックを第3のアグリゲートに,というように振り分けられる.同様に,ISPは,顧客Aのすべてのトラヒックを一つのアグリゲートに,顧客Bはもう一つのアグリゲートに入れるということもできる.
  同じビヘイビアアグリゲートのすべてのトラヒックは,すべてのパケットのヘッダのフィールドにセットされる,いわゆる"DiffServコードポイント"として知られる特定の値によって識別される.この値を使ってルータからルータへそれぞれのホップを行う際の特別のビヘイビアを決定する.これはパーホップビヘイビア(PHB)と呼ばれている,この名称は,特に本振舞いがホップ単位であり,グローバルな振舞いの意味を持たないことを強調している.PHBは,本質的に各ルータによって実行されるキューハンドリングアルゴリズムである.これらは,それぞれのビヘイビアアグリゲートに規定されたトラヒックタイプに合わせて選択される.例えばすべての音声トラヒックパケットは,その出発地及び目的地にかかわらず,すべて特有の一つのビヘイビアが適用される一方で,すべての電子メールには別のビヘイビアが適用される.
  DiffServモデルは,本質的に非常にシンプルで,効率的で,そして極めてスケーラブルであり,ルータのキューイングメカニズムの長年の経験に基づいて構築されている.これはまた,IntServのために開発された分類制御及びアドミッション制御メカニズムにも基礎を置く.最終的には,すべてのデータパケットは,シンプルな分類方針によってパケット送出点あるいはその近辺で分類され,直ちに適切なDiffServコードポイントが付与されるとともに,アドミッション制御が行われる(すなわち,過多トラヒックは遅延させられるか廃棄される).この地点から,データパスに沿った各々のルータは,それぞれのパケットに記されたコードポイントに従ったPHBを適用しなければならない.すなわち,パケットをそのコードポイントに応じて異なる優先度を持つ複数の出力キューに配送し,これによって各パケットに対し出力リンクへの優先/非優先性を選択的に与えているわけである.
  IntServモデルにおいては,ある特定の通信セッションは,それ自身のネットワーク容量について個々の分配額を得る.対照的に,DiffServモデルでは,ビヘイビアアグリゲートが規定された分配額を得る.同じアグリゲートに分類されたすべてのセッションは,この分配額を共有する.これは,大規模システムへの拡張性に対する対価である.この結果,それぞれの個々のセッションによってとらえられてきたエンドツーエンドサービスは,それが分類された先のビヘイビアアグリゲートの特性によって特徴づけられることになる.
  例えば,すべてのWebブラウジングトラヒックを第1のアグリゲートへ,すべての電子メールを第2のアグリゲートへ,すべてのIPテレフォニーを第3のアグリゲートへ入れるとしよう.注目すべきはTCPトラヒックがリアルタイムトラヒックから分離され,かつ更に対話的なTCP (ブラウジング)がバックグラウンドTCP (電子メール)から分離されていることである.この分類に対し,もしIPテレフォニーアグリゲートにあらかじめ想定された最大電話回線数をサポートできる十分な容量を与えつつ,対話的なアグリゲートに残存能力の大部分を配置すれば,次の二つの目標が達成できる.効能として第1に,TCP及び非TCPのトラヒックのふくそうに対する相反する反応が分離されるので,ふくそう管理をはるかにたやすくする.第2に,アプリケーションに適合する形でネットワーク容量が分離される.
  ビヘイビアアグリゲートのもう一つの有効な利用法は,バーチャルプライベートネットワーク(VPN)の概念の一般化である.ISPは,技術的には同一でありながら,異なったサービスクラスを規定し,これらを主要な顧客に販売することができる.これによって,容量管理手法はフレームリレーやATMに類似しつつ,IPベースのVPNと同等のサービスを提供することができる.あるいはISPは,サービスグレードに応じて異なる価格設定を行うサービスも可能であろう.
  本稿執筆時において,DiffServのためのすべての基本的な標準は,IETF(15)によって規定されてきた.一方で,LDAPディレクトリのような中央レポジトリに保持された管理ポリシーに基づくDiffServネットワーク管理の標準と技術に関する作業が,現在進行中である.また多くの異なるユーザが利用許可を受け,異なるグレードのサービスに対して対価を支払うような環境のための認証・許可・課金といった分野についての標準化の議論は,始まったばかりである.実用的な実験が開始される段階では,エンドツーエンドのサービス品質についての標準化が,追加作業として必要となるであろう.
  多くの点でインターネットは,長年回線交換型のテレコミュニケーションで存在した大規模サービスマネジメントの課題に今,直面している.しかしながらこれらの課題は,パケットベースのサービスの特殊性や,インターネットの強い競争環境,及び直裁で汎用的な課金モデルの欠如といった問題によって更に複雑化されている.顧客とサービスプロバイダの間で,かつ互いにトラヒックを交換するISP間で,精緻なサービスレベルについての合意が必要とされよう.これらの問題は互いに相関関係があり,かつ現実にこのような合意を実現するには多くのことを学ぶ必要がある.





8. む  す  び

  インターネットが今後e−ビジネスへ利用され,リアルタイムオーディオやビデオサービスの基本的なインフラストラクチャに成長してゆくためには,インターネットプロトコルの伝統的なステートレスで透過性のあるモデルは,断片化されたイントラネットの世界との調和,並びにエンドツーエンドのサービス品質との調和が共に図られなければならない.前者に対しては,IPv6及びエンドツーエンドIPセキュリティの広範な採用が必要である.後者は,多種多様な技術によってその問題が解決されようとしている.
 いうまでもなくインターネットも,すべての通信インフラストラクチャが遭遇するのと同じく,24時間連続運用サポート,問題管理,顧客リレーション管理,容量計画等々の運用課題に直面している.しかしその一方で,コネクションレスのパケット交換に固有の問題,特にふくそうの回避不能性や,品質的に異なるクラスのトラヒックの間での競合といった問題によって,独自の解決課題が課せられている面もある.TCPはほとんど20年にわたって効率的なふくそう管理を提供してきたとはいえ,IntServやDiffServといった新技術が,今ローカルに,あるいはまたグローバルな規模でより洗練された解決案を提供しようとしている.





■ 謝 辞


 本稿には,テレコム99インフラストラクチャフォーラム(1999年10月ジュネーブにて開催)で著作者が提示した文献を含む.また,ジェームス・ケリー氏(IBM)及びジョエル・マンブレッティ氏(iCAlR,ノースウェスタン大学)からの貴重なコメントを頂いたことに感謝する.




■ 文 献

  • (1) Architectural Principles of the Internet, B.E. Carpenter, ed.,RFC 1958, June 1996, available from http://www.rfc-editor.org/
  • (2) J.H. Saltzer, D.P.Reed, and D.D.Clark, "End-To-End Arguments in System Design," ACM TOCS, vol.2, no. 4, pp 277-288, Nov.1984.
  • (3) D.D.Clark, "The Design Philosophy of the DARPA Internet Protocols," Proc SIGCOMM 88, ACM CCR, vol.18, no. 4, pp. 106-114,Aug. 1988 (reprinted in ACM CCR, vol.25, no. 1, pp.102-111, Jan.1995 ).
  • (4) B.E. Carpenter, Internet Transparency, 1999, work in progress, will be available from http://www.rfc-editor.org/
  • (5) See for example the web site, http://playground.sun.com/pub/ipng/html/ipng-main.html
  • (6) C. Huitema, Internet quality of service assessment, updated daily at ftp://ftp.telcordia.com/pub/huitema/stats/quality_today.html
  • (7) D.O. Williams, Status Report of ICFA Networking Task Force, CERN, July 1998, available at http://davidw.home.cern.ch/davidw/icfa/July98Report.html
  • (8) J.Postel, Transmission Control Protocol, RFC 793, Sept. 1981, available from http://www.rfc-editor.org/
  • (9) S. Floyd and V. Jacobson, =cd=ab2cRandom Early Detection gateways for Congestion Avoidance," IEEE/ACM Transactions on Networking, vol.1, no.4, pp.397-413, Aug. 1993.
  • (10) H. Schulzrinne, A. Rao, and R. Lanphier, "Real Time Streaming Protocol (RTSP)," RFC 2326, April 1998, available from http://www.rfc-editor.org/
  • (11) H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications," RFC 1889, Jan. 1996, available from http://www.rfc-editor.org/
  • (12) P.Almquist, "Type of Service in the Internet Protocol Suite," RFC 1349, July 1992, available from http://www.rfc-editor.org/
  • (13) =cd=ab2cInternet Stream Protocol Version2(ST2)Protocol Specification-Version ST2+," L.Delgrossi and L.Berger,  eds., RFC 1819, Aug. 1995, available from http://www.rfc-editor.org/
  • (14) R. Braden, D. Clark, and S. Shenker, " Integrated Services in the Internet Architecture: an Overview," RFC 1633, June 1994, available from http://www.rfc-editor.org/
  • (15) For all current diffserv documents, see http://www.ietf.org/html.charters/diffserv-charter.html

Brian E. CARPENTER
IBMコーポレーション インターネット標準・技術担当プログラムディレクター. 工博. 現在,iCAIR(International Center for Advanced Internet Research) 所属. iCAIRは,米国イリノイ州ノースウェスタン大学エヴァンストン校にあり,米国IBMの資金援助で運営されている研究機関である. カーペンター博士は,iCAIRのチーフアーキテクトを勤めるかたわら,ノースウェスタン大学で教鞭をとる.
これ以前に同博士は,1985から1996までスイスのジュネーブにあるCERNにおいて,プロセス制御システムのソフトウェア開発の10年の経験の後,CERN粒子物理学ヨーロッパ研究所でネットワーキンググループを統率した. また,ニュージーランドのマッセイ大学で3年間コンピュータサイエンスの教鞭を執った.
 同博士は,コンピュータサイエンス分野で学位及び博士号を取得,かつM.I.E.E.である. また,インターネットアーキテクチャボードのチェアを勤めるかたわら,IETFの主要メンバーとして,ディファレンシエーテッドサービス部会の共同チェアも勤める.同博士はまた,ユニコードコンソーシアムのボードメンバーである.




てらもと しょうさく
寺  本   昌 作  (正員)
昭44神戸大・経済卒.同年日本アイ・ビー・エム(株)入社.現在,同社公共システム事業部先進技術部長.

 
< 原文はこちら 


| TOP | Menu |

(C) Copyright 2000 IEICE.All rights reserved.