超高速通信プロトコル群と実装法に関する研究 Study of Ultra Fast

超高速通信プロトコル群と実装法に関する研究
Study of Ultra Fast Protocol Suite
and its Implementation Model
2003 年 3 月
村上健一郎
目次
第 1 章 序論 ...............................................................9
1.1 研究の背景 ...........................................................9
1.2 研究の目的 ..........................................................10
1.3 論文の構成 ..........................................................12
第 2 章 本研究に関連する技術と研究状況 ....................................15
2.2 インターネットの概要とインターネットプロトコル群 .....................16
2.2.1 インターネットモデル ............................................16
2.2.2 インターネットにおけるデータ転送 ................................17
2.2.3 インターネットプロトコル群 .....................................18
2.2.4 エンキャプシュレーション ........................................20
2.3 高速リンクプロトコル ................................................21
2.3.1 SONET / SDH .....................................................21
2.3.2 ATM .............................................................25
2.3.3 POS .............................................................28
2.3.4 イーサネット ....................................................30
2.4 ネットワークプロトコル実装方式 ......................................33
2.4.1 従来のネットワークのプログラミングパラダイム ....................34
2.4.2 従来のアプローチの問題点 ........................................35
2.5 本研究の位置付け ....................................................36
第3章
MAPOS プロトコル群 .................................................38
3.1 はじめに ............................................................39
3.2 従来の高速プロトコルの問題点と超高速リンクプロトコルの要件 ..........39
3.2.1 従来の高速プロトコルの問題点 ....................................39
3.2.2 フレームとセルの転送効率 ........................................40
3.2.3 MTU と細分化 .....................................................42
3.2.4 LAN と WAN とのシームレス性 .......................................42
3.2.5 アドレス体系と経路制御 ..........................................43
3.2.6 超高速リンクプロトコルの要件 ....................................43
3.3 MAPOS のアーキテクチャとプロトコル概要 ...............................44
3.3.1 プロトコルの概要と特徴 ..........................................44
1
3.3.2 MAPOS ネットワークのアーキテクチャ ...............................46
3.3.3 MAPOS のフレーム形式とエンキャプシュレーション ...................47
3.3.4 MAPOS プロトコル群の構成 .........................................49
3.4 アドレス長と中継速度に関する検討 ....................................50
3.5 VRPB ブローキャスト/マルチキャスト転送アルゴリズム ...................51
3.6 評価 ................................................................54
3.6.1 COREswitch のアーキテクチャと動作 ................................54
3.6.2 ホストインタフェースのアーキテクチャと動作 ......................56
3.6.3 中継処理における経路テーブル検索時間の評価 ......................57
3.6.4 ベンチマークプログラム netperf による長大 MTU の効果 ..............59
3.6.5 実アプリケーションによる長大 MTU と伝送エラーの評価 ..............63
3.6.6 実装の容易さに関する検証 ........................................65
3.7 むすび ..............................................................68
第4章
TPV アルゴリズムと MAPOS 経路制御プロトコルへの応用 .................70
4.1 はじめに ............................................................71
4.2 従来の問題点と TPV でのアプローチ ....................................71
4.2.1 代表的な 2 つのタイプのプロトコル ................................71
4.2.2 Path Vector 型プロトコルとその問題点 .............................72
4.2.3 TPV のアプローチ .................................................74
4.3 TPV の概要 ...........................................................75
4.3.1 TPV の特徴 .......................................................75
4.3.2 想定するネットワーク ............................................76
4.3.3 仮想時間 ........................................................78
4.3.4 パス情報の表現形式 ..............................................79
4.3.5 メッセージ処理の概要 ............................................80
4.4 仮想時間の処理 ......................................................87
4.4.1 仮想時間の初期値と更新 ..........................................87
4.4.2 メッセージの受信における仮想時間の処理 ..........................87
4.5 VT 処理のオーバヘッドと効率化 ........................................89
4.5.1 予想されるオーバヘッド ..........................................89
4.5.2 メモリオーバヘッドの抑制 ........................................91
4.5.3 CPU オーバヘッドの抑制 ...........................................93
4.6
評価 ...............................................................95
4.6.1 シナリオ ........................................................95
4.6.2 結果と考察 ......................................................96
2
4.7 TPV の MAPOS 経路制御プロトコルへの応用 ...............................97
4.7.1 TPV 導入の目的と設計条件 .........................................97
4.7.2 ESSP プロトコル群 ................................................98
4.7.3 STP の概要 .......................................................99
4.7.4 MTP の概要 .......................................................99
4.7.5 ESSP プロトコルの処理概要 .......................................100
4.7.6 ESSP プロトコル処理系の概要 .....................................103
4.7.7 ブロードキャストとマルチキャストの中継 .........................106
4.7.8 指定サクセサ DS .................................................108
4.7.9 マルチキャスト経路の枝刈り ......................................108
4.7.10 FT の利用による転送停止方式 ....................................109
4.8 むすび .............................................................110
第 5 章 パス指向プロトコル実装モデル POM ..................................112
5.1 はじめに ...........................................................113
5.2 探索的プロトコル開発の必要性 .......................................113
5.3 参照モデルと従来のプロトコル実装モデル LOM の問題点 .................114
5.3.1 参照モデル .....................................................114
5.3.2 従来のモデル LOM による実装とその問題点 .........................115
5.4 POM 実装モデル ......................................................118
5.4.1 POM の概要 ......................................................118
5.4.2 パケットの処理 .................................................119
5.4.3 プロセス .......................................................120
5.4.4 コネクションレス型通信への POM モデルの適用 .....................120
5.5 POM モデルとオブジェクト指向 ........................................121
5.5.1 オブジェクト指向による設計の概念 ...............................121
5.5.2 オブジェクト指向による実装のための言語処理系 ...................122
5.5.3 オブジェクト ...................................................122
5.5.4 POM のパラダイム ................................................124
5.5.5 レイヤクラスとコネクションクラス ...............................125
5.5.6 プロトコルソフトウェアのカスタマイズ ...........................126
5.6 考察 ...............................................................127
5.6.1 2 つのクラス継承方式 ............................................127
5.6.2 継承方式の考察 .................................................128
5.6.3 プロセススイッチと並列処理 .....................................130
5.7 言語への要求条件 ...................................................131
3
5.8 むすび .............................................................131
第6章
POM によるプロトコル実装 ..........................................133
6.1 はじめに ...........................................................134
6.2 記号処理計算機 TAO/ELIS .............................................134
6.2.1 Lisp マシン ELIS ................................................134
6.2.2 マルチパラダイム言語 TAO ........................................136
6.3 TAO/ELIS のネットワークシステム .....................................138
6.3.1 特徴 ...........................................................138
6.3.2 TAO/ELIS のプロトコルスタック ...................................139
6.3.3 クラス階層 .....................................................141
6.3.4 プロセスとオブジェクトとの関係 .................................144
6.3.5 状態還移とメッセージパッシング .................................146
6.4 評価 ...............................................................147
6.4.1 プログラム規模 .................................................147
6.4.2 POM のオブジェクト指向との適合性 ................................147
6.4.3 オーバヘッドの評価 .............................................149
6.4.4 方式の汎用性に関する考察 .......................................150
6.4.5 実装上の問題点に関する考察 .....................................150
6.5 むすび .............................................................151
第 7 章 本研究の結論と今後の課題 .........................................153
謝辞 ...................................................................157
参考文献 ...............................................................159
研究業績 ...............................................................167
付録.A 収束ステップ - 従来のパスベクタの場合 ...........................170
付録.B 収束ステップ - TPV の場合 ........................................175
4
図目次
2.1 インターネットモデル........................................................................................ 17
2.2 TCP/IP プロトコル群のレイヤ構造 .................................................................... 18
2.3 エンキャプシュレーションの例.......................................................................... 20
2.4 ルータによる中継 ............................................................................................... 20
2.5 SONET / SDH の階層構造 ................................................................................. 22
2.6 SONET/SDH のネットワーク例 ........................................................................ 23
2.7 SONET / SDH フレームの構造例 (STM-1) ....................................................... 24
2.8 SONET / SDH フレームの多重化 ...................................................................... 25
2.9 セル形式 ............................................................................................................. 26
2.10 ATM のネットワーク ........................................................................................ 27
2.11 ATM におけるエンキャプシュレーション ........................................................ 28
2.12 POS のレイヤ構造............................................................................................ 29
2.13 PPP のフレーム構造......................................................................................... 29
2.14 イーサネットのフレーム形式とアドレスの構造 ............................................... 30
2.15 IP アドレスの階層的構造 ................................................................................. 32
2.16 従来のモジュール構造...................................................................................... 35
3.1 ATM と MAPOS の場合の転送効率.................................................................... 41
3.2 MAPOS ネットワークの構成 ............................................................................. 46
3.3 MAPOS8/16 および PPP のフレーム形式 .......................................................... 48
3.4 MAPOS16 のアドレス構造 ................................................................................ 48
3.5 エンキャプシュレーション................................................................................. 49
3.6 MAPOS のプロトコルレイヤ ............................................................................. 50
3.7 S1 の successor と predecessor ........................................................................... 52
3.8 スパニングツリーと RPB ................................................................................... 52
3.9 COREswitch の構成 ........................................................................................... 54
3.10 COREswitch の概観......................................................................................... 55
3.11 ホストインタフェースカードの構成 ................................................................. 56
3.12 MAPOS ホストインタフェースカードの概観................................................... 57
3.13 フレームの流れ ................................................................................................ 58
3.14 実験システムの接続形態 .................................................................................. 59
3.15 UDP におけるセグメントサイズとスループットの関係................................... 60
3.16 UDP におけるセグメントサイズとパケット処理数の関係 ............................... 60
3.17 TCP におけるメッセージサイズとスループットの関係 ................................... 62
3.18 TCP におけるメッセージサイズとパケット処理数の関係 ................................ 62
5
3.19 非圧縮 HDTV 転送システムの構成................................................................... 63
3.20 IP データグラムサイズとデータグラム欠損率および映像欠損率の関係........... 64
3.21 cisco12000 アーキテクチャ .............................................................................. 65
3.22 cisco12012 外観(左側が 12012、右が COREswitch)........................................ 66
3.23 スループット測定システムの形態 .................................................................... 67
3.24 最大フレームレート ......................................................................................... 67
3.25 スループット .................................................................................................... 68
4.1 経路バウンシング ............................................................................................... 73
4.2 ネットワークの例 ............................................................................................... 77
4.3 想定する TPV のプトロコルスタック................................................................. 78
4.4 仮想時間 ............................................................................................................. 78
4.5 TT の構造 ........................................................................................................... 81
4.6 計算ステップ ...................................................................................................... 86
4.7 経路情報の流れ .................................................................................................. 86
4.8 VT 処理の位置.................................................................................................... 88
4.9 想定するネットワーク........................................................................................ 95
4.10 ESSP の構成要素 ............................................................................................. 99
4.11 STP のフェーズ .............................................................................................. 100
4.12 update メッセージの構造............................................................................... 100
4.13 Forwarding Table .......................................................................................... 102
4.14 経路情報の流れ .............................................................................................. 103
4.15 ESSP の処理モジュール概要.......................................................................... 104
4.16 BRT................................................................................................................ 107
4.17 RPB................................................................................................................ 107
5.1 OSI の 7 レイヤモデルとアーキテクチャ ......................................................... 114
5.2 TCP/IP のレイヤモデル.................................................................................... 115
5.3 LISP Machine におけるプロトコル実装 .......................................................... 116
5.4 x-kernel のモジュール構造............................................................................... 117
5.5 バーチャルサーキット...................................................................................... 119
5.6 POM モデルの概念........................................................................................... 120
5.7 オブジェクトとメッセージ............................................................................... 122
5.8 クラスとインスタンス...................................................................................... 123
5.9 継承 .................................................................................................................. 124
5.10 バージョンの異なるプロトコルの混在 ........................................................... 125
5.11 間接継承 ......................................................................................................... 127
5.12 直接継承 ......................................................................................................... 128
6
5.13 プロセスとオブジェクトの関係...................................................................... 130
6.1 ELIS のアーキテクチャ.................................................................................... 135
6.2 TAO/ELIS のプロトコルスタック .................................................................... 140
6.3 TAO/ELIS におけるネットワークのクラス階層............................................... 142
6.4 単一オブジェクト上の単一プロセス................................................................. 144
6.5 POM モデルにおける単一オブジェクト上の多重プロセス............................... 145
6.6 ファイル転送中の CPU 使用率......................................................................... 149
7
表目次
2.1 SONET / SDH の速度体系と名称 ...................................................................... 22
2.2 無中継最大延長距離 ........................................................................................... 23
2.3 リンクレイヤのネットワークの特徴と問題 ........................................................ 33
3.1 MAPOS の諸元................................................................................................... 47
3.2 COREswitch の諸元........................................................................................... 56
3.3 MAPOS インタフェースカードの種類 ............................................................... 57
3.4 測定結果 ............................................................................................................. 58
3.5 使用した PC の諸元............................................................................................ 59
3.6 cisco12000 シリーズ諸元.................................................................................... 65
3.7 ソフトウェアモジュールの流用と新規開発 ........................................................ 66
4.1 BGP におけるベストパスの変化 ........................................................................ 96
4.2 TPV におけるベストパスの変化......................................................................... 96
5.1 POM モデルとオブジェクト指向との対応 ....................................................... 126
5.2 適用範囲 ........................................................................................................... 129
6.1 ELIS の諸元 ..................................................................................................... 136
6.2 各クラスの機能 ................................................................................................ 141
6.3 クラスやメソッドの継承度............................................................................... 148
6.4 インスタンス変数の継承率................................................................................. 148
8
第 1 章 序論
1.1 研究の背景
近年、インターネットは爆発的な成長を見せ、すべての産業に不可欠な情報基盤とな
っている。これに伴い、そのトラフィックは急激な増大を続けている。また、Fiber To
The Home (FTTH)、Asynchronous Digital Subscriber Line (ADSL)、Cable Television
(CATV) 等によるアクセス網のブロードバンド化は、インターネットバックボーンに対
して一層の高速化を迫っている。例えば、世界のインターネットのバックボーンとして
機能している米国のネットワークでは、半年に 2 倍というペースでトラフィックが増大
している。また、その総トラフィックのピークレートは 2001 年に毎秒 240 ギガビット
を越えたが、2005 年から 2010 年にかけては 1 ペタビットを越えると予想されている。
このような状況の中で、インターネットのリンクレイヤとして、さまざまな高速ネッ
トワークプロトコルが開発され、標準化が続けられている。例えば、Asynchronous
Transfer Mode (ATM)、 High Performance Parallel Interface (HIPPI)、Packet over
SONET (POS)、Resilient Packet Ring (RPR)、ギガビットイーサネット (GbE) 等であ
る。これらの中には、既存のプロトコルとの互換性に注目するあまり効率を犠牲にした
もの、適用範囲を広くねらいすぎたために複雑なプロトコルとなってしまったもの、取
り得るトポロジがリングに制限されてしまっているもの等、総合的な見地から見ると不
充分なものもある。
インターネットが、益々増大するトラフィックに対応し、効率の良いデータ転送サー
ビスを提供するためには、インターネットと親和性のあるデータ転送方式がその下位の
リンクレイヤのプロトコルに求められる。また、リンクレイヤのネットワークをシステ
ムとして運用するためには、複数のネットワークセグメントから構成されるネットワー
クシステムの経路制御やネットワーク管理まで含んだ、高速なデータ転送システムへの
体系的アプローチが必要となる。即ち、超高速を指向したプロトコルは、データ転送プ
ロトコルとネットワーク制御プロトコルの両方を含む体系的なプロトコル群として提
供される必要がある。しかし、既存のネットワークプロトコルではこの両方の条件を満
たすようなアプローチが行われていない。
本論文では、このような背景のもと、転送効率と経路制御の収束性という総合的な視
点にたって超高速データ通信向きプロトコルを開発し、それを実際に超高速で動作する
装置として実現することによって検証を行う。また、そのようなプロトコルのプロトタ
イピングを容易にするプロトコル実装モデルを提案し、実際にそのモデルに基づいてネ
ットワークカーネルを実装することによってその実現性を示す。
9
1.2 研究の目的
本研究の目的は、以下に述べるように、エンドツーエンドの超高速データ通信向きリ
ンクプロトコル群の要件を明らかにすること、データ転送プロトコルとネットワーク制
御プロトコルの両方を含む体系的なプロトコル群として超高速データ通信向きプロト
コルを提示すること、そして、探索的なプロトコル開発とプロトタイピングの効率化を
目指し、同一レイヤに僅かに異なるプロトコルの混在を許すプロトコル実装方式を提示
することである。
(1) インターネットプロトコルとの親和性がある低オーバヘッドのプロトコル
ネットワークのエンドツーエンドの速度を低下させる要因の一つは、データグラム
の細分化である。細分化は、エンドノード、即ち、ホストにおけるヘッダ処理のオー
バヘッドを高め、スループットを低下させる。また、ネットワーク部分における転送
に際しては、転送するデータ量に比較して必要なヘッダの量が増大するためにスルー
プットが低下する。例えば、5byte のヘッダ、48byte のペイロードから構成される
53byte の固定長セルを使用する ATM では、一割程度のオーバヘッドがある。また、
固定長のセルは可変長 IP データグラムとの相性が悪く、48byte のペイロードをわず
かに 1byte 越えても、53byte 長のセルが発生してしまう。これに加え、細分化され
たセルのうちの一つに伝送エラーが発生しても、残りのセルはそのままエンドノード
まで転送されるために無駄に帯域が使用される。
これに対し、本研究ではインターネットで使用される Internet Protocol (IP)デ
ータグラムの最大長である 64Kbyte を細分化せず、しかも、可変長のフレームを転送
できるプロトコルを開発する。
(2) LAN と WAN とのシームレスな接続
超高速の領域では、わずかなフレームの損失が大きなパフォーマンス低下となって
表われる。例えば、Transmission Control Protocol (TCP)プロトコルでは、効率化
のために相手ホストからの確認応答の前に次のデータを転送し、パケット損失が発生
すれば、それ以降のパケットを再転送する。ところが、超高速の世界では、パケット
損失が発生してそれが検出されるまでに大量のパケットが先行的に送信される。この
ため、膨大な数のパケットが再転送される。通常の場合には、TCP プロトコルにおけ
るエンドツーエンドのフロー制御によって著しいパケットの損失は発生しない仕組
となっているが、Local Area Network (LAN)と Wide Area Network (WAN)の接続点に
おいて異なるスピードの媒体が接続された場合、WAN の速度が LAN のそれに比較して
10
遅ければ、そこにおけるバッファ効果でスループットが過大に見積られる。結果とし
て、大量のパケットが先行的に送られてバッファオーバフローが発生し、それらの再
転送によって大きな転送パフォーマンスの低下となる。これに加え、LAN と WAN のプ
ロトコルが異なる場合には、変換装置やその制御が複雑になる。
これに対し、本研究では、LAN においても WAN においても利用可能であり、シーム
レスな接続が可能なリンクプロトコルの開発を目指す。そのためには、このプロトコ
ルが LAN 用に多重アクセス機能を備える必要がある。また、WAN においては、既存の
世界標準の超高速専用線プロトコル Synchronous Optical Network / Synchronous
Digital Hierarchy (SONET/SDH)との接続が必須となる。このため、リンクプロトコ
ルが SONET/SDH を下位レイヤに持つ必要がある。
(3) 従来技術からの容易な移行を可能とする互換性
新たなプロトコルの実装において最も問題となることは、新規の開発コストと開発
に要する時間である。これらの新規の開発オーバヘッドを最小に抑えるには、従来の
ハードウェアやソフトウェアを利用できるように、新たなプロトコルに従来のプロト
コルとの互換性を持たせる必要がある。従来のプロトコルとは、従来のリンクプロト
コルだけに限らず、プロトコルが使用する下位のレイヤのプロトコルとの互換性も含
む。
(4) ネットワークトポロジの変動に対して迅速に収束する経路制御
これまでの超高速向きリンクプロトコルは、そのデータ転送能力だけが着目され、
ネットワークシステムを構成した場合のシステム構成制御には目が向けられていな
い。例えば、イーサネットでは、非階層的アドレスが使用されている。このために、
複数のセグメントから構成されるネットワークでは、各ホストがどのセグメントに接
続されているかわからず、最適な経路制御を行うことは困難である。また、使用中の
経路に障害が発生すると予備の経路に切り替えるが、経路の切替に数十秒以上の時間
がかかる。更に、並列経路があるとループが発生するために、そのうちの一つだけを
残して他は転送に使用できないという問題もある。
これに対し、本研究では、まず、リンクプロトコルのアドレス体系に階層化アドレ
スを導入するとともに、その経路切替時間を数十から数百ミリ秒程度に収まる経路制
御アルゴリズムとプロトコルとを考案する。開発にあたっては、Border Gateway
Protocol (BGP) のようなインターネットの広域経路制御にも広く適用できる汎用性
のあるプロトコルを目標とする。
11
(5)段階的なプロトコル設計や開発が可能なプロトコル開発方式
新たなプロトコルを開発する場合には、設計と試行を繰り返す。即ち、プロトコル
の一部を変更した後に、変更前のプロトコルとの動作を比較して検証し、更に、次の
変更を加えることによって完成されたものとしてゆく。このため、開発を効率的に行
うには、探索的かつ段階的なプロトコル実装を可能とする方式、および、それを可能
とする開発環境が不可欠となる。しかし、従来のプロトコル実装方式では、システム
には各プロトコルに唯一のバージョンしか存在を許さず、僅かに異なるバージョンの
プロトコルが混在できない。
そこで、本研究では異なるプロトコルのバージョンが一つのシステム内に混在でき、
しかも、互いに影響を及ぼすことなく動作できるプロトコル実装法を提示する。実装
法の開発にあたっては、一般のネットワークシステムの開発に適用できるような汎用
性のある方式を目標とする。
1.3 論文の構成
第 2 章では、本研究に関連する研究状況を説明し、本研究の位置付けを明確にする。
本研究は、インターネットにおいて超高速データ転送を実現すること、そして、プロト
コルの開発を探索的に行うことのできる実装方式を明らかにすることを目的としてい
る。このため、まず、インターネットプロトコル群について概要を述べる。そして、さ
まざまな LAN のプロトコルを説明した後、プロトコル実装方式に言及する。
第 3 章では、IP データグラム長をすべて包含できる 64Kbyte の長大な Maximu
Transmission Unit (MTU)、極めて短時間のうちにトポロジの変化に追従できる経路制
御、従来の高速伝送システム SONET / SDH との互換性、という特徴を持つ超高速多重ア
クセスプロトコル群 Multiple Access Protocol over SONET / SDH (MAPOS) について
述べる。ここでは、まず、基本的なプロトコルアーキテクチャとプロトコル群を構成す
るサブプロトコルについて説明する。そして、このプロトコル群を実装した総容量
87.04Gbps の高速スイッチ COREswitch と 2.4Gbps の高速ホストインタフェースのアー
キテクチャを示す。次に、エンドノードに Pentium III 1.26Ghz CPU を使用した最大
1.5Gbps のストリームを必要とする非圧縮 HDTV 伝送システムへのアプリケーションを
例にとり、汎用の PC 間でも、MAPOS の長大フレームであれば最大 1.5Gbps のストリー
ムを 10-9 から 10-10 程度のエラーレートで転送することができるということを示す。ま
た、POS との互換性による実装の容易さを検証するために、業界標準の cisco 社ルータ
へ実装し、ハードウェアに一切の改造を加えることなく、ソフトウェアの変更だけで
MAPOS が稼働することを明らかにする。
第 4 章では、時間の概念を経路情報に導入した経路制御アルゴリズム Temporal Path
12
Vector (TPV)と、それを応用した MAPOS プロトコル群の経路制御プロトコル Extended
Switch-Switch Protocol (ESSP) について述べる。まず、これまでの経路収束の遅延が、
ネットワークに分散したノードが非同期に経路を更新することによって発生すること
を明らかにする。これに対し、経路の接続性を観測した時間を経路情報に含ませること
によって、非同期更新から発生する問題、即ち、古い経路情報による新しい経路情報の
上書きや古い経路情報の長期滞留を防止できることを示す。そして、その収束特性を従
来のパスベクトルプロトコルである BGP と比較する。それにより、従来、4 ノードから
構成される簡単なネットワークにおいても収束に 45 ステップかかっていた例に対し、
TPV ではわずか 4 ステップで収束を完了できることを示す。また、TPV の適用によって
発生するメモリや計算量のオーバヘッドの増加を、ガーベージコレクションによって抑
制できることを示す。
更に、TPV アルゴリズムを MAPOS の経路制御プロトコルへ適用した ESSP について、
そのプロトコル構成と実装アーキテクチャを説明する。そして、指定サクセサの概念を
使用すればユニキャストで並列パスを使用する場合でも、マルチキャスト/ブロードキ
ャストのスパニングツリーを作成できること、スパニングツリー配下のマルチキャスト
グループのリストを指定サクセサに渡すことで無駄なマルチキャストの転送を抑制で
きること、MAPOS 固有の高速中継用テーブル Forwarding Table (FT)を利用して一時的
なループを防ぐための転送抑制機構をオーバヘッドなしに作成できることを示す。
第 5 章では、Open Systems Interconnection (OSI)の 7 レイヤ参照モデルと従来の実
装方式を概観し、プロトコル実装の方式研究においてこれまでどのようなアプローチが
行われてきたのかを説明する。そして、パス指向実装モデル POM (Path Oriented Model)
を提案し、従来の実装方式の問題点とそれに対するアプローチについて論じる。POM モ
デルでは、各レイヤの関係をモジュール間のポインタとして持ち、そのポインタを変更
することによって同一システム内に異なるバージョンの実装が可能となることを示す。
また、パケットが共通のデータ構造として各モジュールに共有されるためにパケットの
コピーフリーが実現でき、このことで処理速度を落すことなくネットワークプロトコル
を実装できることを明らかにする。更に、POM がオブジェクト指向の枠組を利用して実
装できることを示す。
第 6 章では、POM に基づいて記号処理計算機 Electrical Communications Laboratories
List Processor (ELIS)上のマルチパラダイム言語 TAO のオブジェクト指向を使って
Transmission Control Protocol / Internet Protocol (TCP / IP)プロトコルを実装す
る方式について言及する。ここでは、まず、記号処理計算機 ELIS の概要とその上の言
語 TAO のマルチパラダイムについて概要を説明する。次に、オブジェクト指向によるネ
ットワークカーネル実装の内部構造を明らかにする。そして、POM がオブジェクト指向
の機能を有効に利用できていることを評価によって示し、更に、実測された速度を示し
て本モデルによる実装がパフォーマンスへ影響を及ぼさないことを示す。
13
第 7 章では、本論文の結論と今後の研究課題について述べる。
14
第 2 章 本研究に関連する技術と研究状況
概要
本章では、本研究と関係を持つ超高速リンクプロトコル、経路制御プロトコル、プロト
コル実装方式の研究概要を述べる。まず、本研究が対象とするインターネットのモデル
及びプロトコルの概要を説明し、次に、インターネットで使用されるさまざまな高速通
信向きのプロトコルを説明する。そして、プロトコルのレイヤモデルとそれに沿ったプ
ロトコル実装方式に言及する。最後に、本研究とこれまでの技術との比較によって本研
究の位置付けを明確にする。
15
2.1 はじめに
本章では、本研究の関連研究を概観し、本研究の位置付けを説明する。本研究は、イ
ンターネットにおいて超高速データ転送を実現すること、そして、プロトコルの開発を
探索的に行える実装方式を明らかにすることを目的としている。このため、まず、イン
ターネットプロトコル群について概要を述べる。
インターネットでは、超高速ネットワークプロトコルの研究が、主にトランスポート
レイヤにおけるフロー制御方式とリンクプロトコルとを対象として行われてきた。この
うち本研究の対象はリンクプロトコルである。そこで、ここでは、インターネットでリ
ンクプロトコルとして使用されているいくつかの技術に焦点に当てる。リンクプロトコ
ルの機能は、主にデータ転送機能と経路制御機能に分けることができる。後者は、複数
のネットワークセグメントから構成されるリンクレイヤのネットワークにおいて、セグ
メントの相互接続を行うスイッチが、フレームを最適な経路で転送するにはどの経路で
転送すれば良いかを決定する機能である。以下では、これらの 2 つの視点から、代表的
なリンクプロトコルである Asynchronous Transfer Mode (ATM)、Packet over SONET/SDH
(POS)、Gigabit Ethernet (GbE)や 10 Gigabit Ethernet (10GbE)等の高速イーサネッ
トについて概要を説明する。なお、本論文で述べる MAPOS プロトコル群も含め、いくつ
かのリンクプロトコルは、その下位のプロトコルとして、世界の通信網の基礎となって
いる超高速専用線のプロトコル SONET / SDH を使用する。そこで、リンクプロトコルの
説明に先だって、SONET / SDH についても概要を述べる。
リンクプロトコルに続き、プロトコル実装方式の問題に関して概要を説明する。ここ
では、従来のプロトコルレイヤをモジュールと考えるプロトコル実装方式について説明
する。そして、例として、TCP/IP プロトコル群を実装した Symbolics 社の LISP Machine
や x-kernel におけるアプローチを紹介する。
最後に、従来の研究をとりまとめ、それと比較することによって本研究の位置付けと
意義を明らかにする。
2.2 インターネットの概要とインターネットプロトコル群
本節では、インターネットのモデルを示し、プロトコル群の構成と機能を説明する。
2.2.1 インターネットモデル
インターネットとは、多くの異なる組織の運営するネットワークを相互に接続したも
ので、全体があたかも単一のネットワークのように協調して動作するメタネットワーク
(ネットワークのネットワーク) である。このモデルとなるのが、インターネットモデ
16
AS1
R12
AS2
H1
R23
H2
AS3
H3
AS : Autonomous System
R : Router
H : Host
図2.1 インターネットモデル
ル [1] である。これを図2.1に示す。
インターネットモデルは、自律システム Autonomous System (AS) [1]とパケット交
換機であるルータ (Router) [1]とから構成される。自律システムとは、同一の組織に
よって管理運営されるネットワークのことである。例えば、各大学や企業のネットワー
クは自律システムである。ルータとは、自律システム間でパケットを中継する装置のこ
とである。自律システムの内部は、イーサネットケーブルのようなネットワークセグメ
ント、および、それに接続されたサーバやパーソナルコンピュータなどのエンドノード
から構成される。しかし、AS の内部が、更に、ルータで接続された AS の集合になって
おり、インターネットワークを構成している場合もある。例えば、大学のキャンパスネ
ットワークは、その内部が各学部の AS から構成されており、インターネットワークを
形成していることが多い。このように、インターネットワークは繰り返し構造を持つ。
2.2.2 インターネットにおけるデータ転送
インターネットはルータ、ルータ同士を結ぶ回線、エンドノードであるホストの 3 つ
の要素から構成される。インターネットでは、転送元のホストにおいて、データを IP
データグラムと呼ばれるパケットに分割して転送する [2][3][4]。個々のホストやルー
タはインターネット内で一意に識別できるアドレスを持っている。IP データグラムを
送り出すホストは、その際に、転送先のエンドノードに割り当てられた IP アドレス[5]
を転送先アドレスとして IP データグラムに埋め込む。そして、回線に送り出して隣接
するルータに渡す。そのルータは、IP データグラム内にある転送先アドレスを参照し
て次に渡すべきルータを決定し、そこへ接続されている回線に送り出す。このようにし
ていくつものルータによって中継された IP データグラムは、最終的に転送先のホスト
17
に到着する。転送された一連の IP データグラムは、転送先のホストによって元のデー
タに復元される。例えば、図 2.1 のホスト H1 で、IP データグラムに細分化されたデー
タは、ネットワーク上を 2 つのルータ R12、 R23 によって中継されながら転送先のホスト
H3 へ転送されてゆき、そこで元のデータに組み立てられる。
2.2.3 インターネットプロトコル群
インターネットで使用されているプロトコル群は Transmission Control Protocol /
Internet Protocol (TCP/IP)プロトコル群[6][7]と呼ばれる。このプロトコル群は以下
の 5 つのレイヤから構成される。
(1) 物理レイヤ
(2) リンクレイヤ
(3) ネットワークレイヤ
(4) トランスポートレイヤ
(5) アプリケーションレイヤ
これらの関係を図 2.2 に示す。
このうち、物理レイヤおよびリンクレイヤの機能は、同一回線上の隣接するルータや
ホストまでIPデータグラムを転送することである。回線として、イーサネット[8]や専
用線などのあらゆる種類のものが使用可能である。これは、カプセル化によってIPデー
タグラムを回線固有のフレーム (リンクレイヤにおけるパケット)内のデータとして転
送するからである。これをエンキャプシュレーション[9]と呼ぶ。
インターネットレイヤのIPプロトコル[4]は、リンクレイヤから受け取ったIPデータ
HTTP
SMTP
FTP
TELNET
TCP
VoIPなど
UDP
IP
イーサネット
専用線
アプリケーションレイヤ
トランスポートレイヤ
ネットワークレイヤ
MAPOS
リンクレイヤ
物理レイヤ
図2.2 TCP/IPプロトコル群のレイヤ構造
18
グラム中の転送先IPアドレスを基に、次に渡すべき隣接したホストあるいはルータを決
定し、リンクレイヤを使用してそこへ転送する。IPプロトコルでは、IPデータグラムの
喪失などの誤りが発生しても、回復を行わない。このようなエラーは、両エンドノード
上にあるトランスポートレイヤで検出され、TCPプロトコル[10]に従って再転送による
誤りからの回復が行われる。これに加え、TCPプロトコルは、同一ホスト上の複数のア
プリケーションに対して、それぞれ独立した通信路 (バーチャルサーキット)[11][12]
を提供する。また、インターネット内部や相手のホストの負荷を推測し、過負荷を避け
ながら最大の転送速度が得られるようにフロー制御を行う。TCPはエラーの検出やフロ
ー制御のために、データのバイトごとに番号を付けて転送先のホストへ送る。受信側の
ホストでは、受信した最後の番号に1を加えた番号(即ち、次に受信を期待するデータの
番号)を送信側のホストへ応答確認として返す。トランスポートレイヤには、TCPと異な
り、応答確認を行わないUser Datagram Protocol (UDP)プロトコル[13]もある。これは、
誤りからの回復の必要のない音声や画像等のストリーム転送に使用される。
ア プ リケ ー ショ ン レイ ヤ に は 、 ウ ェ ブ を 閲 覧 す るた め の Hyper Text Transfer
Protocol (HTTP)プロトコル[14]、リモートログインを行うためのTELNETプロトコル
[15]、ファイル転送を実現するFile Transfer Protocol (FTP)プロトコル[16]、そして
メール転送を行うSimple Mail Transfer Protocol (SMTP)プロトコル[17]などがある。
これらは、トランスポートレイヤのTCPプロトコルが提供するバーチャルサーキットを
使用する。一方、UDPプロトコルは、インターネット電話Voice over IP (VoIP)の音声
やインターネット放送の画像の転送等[18]に使用される。
なお、これら以外に、経路制御[19]のためのプロトコルがある。各ルータは、隣接す
るルータと経路テーブルの情報あるいはルータ間の接続情報を交換する。これによって
各ルータは最適経路を計算し、経路テーブルを設定する。経路テーブルとは、各ルータ
が次に渡すべきルータを決定する時に参照するテーブルであり、転送先のIPアドレスと
次に渡すべきルータのIPアドレスとの対応表である。経路情報の交換は動的に行われる
ため、ネットワークに障害が発生した場合、その経路を避けて別の経路が使われるよう
に経路テーブルが変更される。
経路制御のプロトコルは2つに分類することができる。一つは、AS内の経路制御を行
うInternal Gateway Protocol (IGP)、もう一 つはAS 間の経路制御 を行う External
Gateway Protocol (EGP)である。IGPの代表として、Routing Information Protocol
(RIP)[20][21] や Open Shortest Path First (OSPF)[22] 、 EGP の 代 表 と し て Border
Gateway Protocol (BGP)[23]がある。なお、インターネットでは、ルータのことをかつ
てゲートウェイと呼んでいた。このために、ゲートウェイという言葉が経路制御プロト
コルの名称に残っている。
19
2.2.4 エンキャプシュレーション
パケットは、データを転送する場合の単位である。これは、転送先や転送元のホスト
を表すアドレス等を含むヘッダ領域と、データを入れるデータ領域とから構成される。
データ領域はペイロードと呼ばれることもある。
インターネットでは、パケットをレイヤごとに区別するため、リンクレイヤにおいて
はフレーム、インターネットレイヤにおいてはデータグラム、トランスポートレイヤに
おいてはセグメントと呼ぶ[24]。これらのエンキャプシュレーションの関係を図 2.3 に
示す。エンドノードのアプリケーションはデータを分割し、TCP のセグメントに入れる。
セグメントは IP のデータグラムに入れられる。データグラムはリンクレイヤのフレー
ムに入れられる。そして、このフレームが回線上を転送される。フレームを受信したル
ータは、データグラムを取り出し、そのヘッダにある転送先アドレスから次に渡すべき
ルータを決定し、そのルータへ接続されている回線に合ったフレームにエンキャプシュ
レーションして送り出す。これによってデータグラムがエンドツーエンドで中継される。
この様子を図 2.4 に示す。
アプリケーション
データ部
TCP/UDPヘッダ
TCPやUDPセグメント
データ部
IPヘッダ
IPデータグラム
データ部
イーサネットヘッダ
イーサネットフレーム
データ部
図 2.3 エンキャプシュレーションの例
ホスト
ホスト
アプリケーション
アプリケーション
ルータ
ルータ
IP
IP
IP
IP
イーサネット
ｲｰｻﾈｯﾄ 専用線
専用線 ｲｰｻﾈｯﾄ
イーサネット
TCP
UDP
イーサネット
専用線
TCP
UDP
イーサネット
図 2.4 ルータによる中継
20
転送の際、ホストやルータは、その回線のリンクプロトコルが許しているフレーム内
の最大データ長を考慮する。これを Maximum Transmission Unit (MTU)[9]と呼ぶ。セ
グメント長が MTU を越える場合には、それ以下になるようにルータやホストはその分割
を行い、複数のデータグラムにエンキャプシュレーションして転送する。これをフラグ
メンテーションと呼ぶ。これによって生じたフラグメントは、転送先のエンドノードで
一つのデータグラムに組み立てられる。
2.3 高速リンクプロトコル
本節では、代表的な高速リンクプロトコルとそれらの特徴について言及する。それに
先だち、本研究の MAPOS プロトコルを含めて、いくつかの高速リンクプロトコルが下位
レイヤとして使用している SONET / SDH について説明する。
2.3.1 SONET / SDH
ここでは、SONET / SDH の特徴、速度体系、ネットワークの概要、フレーム形式、多重
化の方式を説明する。
(1) SONET / SDH の特徴と背景
SONET [25][26][27]/ SDH[28][29][30]は、世界の通信システムで共通に使用され
ている超高速の光ファイバによる専用線のシステムおよびプロトコルである。その速
度は 52Mbps から 40Gbps まで階層的な体系を持つ。特徴は、低速な回線を高速な回線
に多重化し、その高速な回線を更に高速な回線に多重化するという多重化技術、そし
て、異なる通信会社の光ファイバネットワーク同士を容易に接続できる相互接続性に
ある。
SONET / SDH は、異なる通信会社同士を接続するための方式として最初に米国ベル
コ ア に よ っ て International Telecommunications Union - Telecommunication
(ITU-T)1 に提案された。しかし、その速度体系は米国の旧通信網の速度体系との整
合性だけに配慮し、日本やヨーロッパのそれには配慮していなかった。このため、
ITU-T では、世界の旧通信網との整合性が確保できるように変更を行い、Synchronous
Digital Hierarchy (SDH) として標準化した。また、SDH は、後述する ATM ネットワ
ークを構築するベースとして ATM の標準化の一環として位置付けられ、標準化が行わ
れた。以上の背景から米国では SONET / SDH を SONET と呼び、日本やヨーロッパで
1
旧 Comité Consultatif International Télégraphique et Téléphonique (CCITT)
21
は SDH と呼ぶ。本論文では、これらをまとめて SONET / SDH と呼ぶ。
(2) 回線の階層構造
図 2.5 に SONET/SDH の速度体系を示す。また、表 2.1 に SONET/SDH の速度体系と名
称を示す。SONET/SDH では、従来の低速専用線である 1.5Mbps (日米)、6.3Mbps (日
本)および 2Mbps (ヨーロッパ)等の回線を多重化し、52Mbps の STM-0 (米国および日
本)または 155Mbps の STM-1 (ヨーロッパ) へまとめる。
また、
3 つの STM-0 (約 52Mbps)
が多重化されて STM-1 (約 155Mbps) へ、4 つの STM-1 が多重化されて STM-4 (約
622Mbps) へ、更に、4 つの STM-4 がまとめられて STM-16 (約 2.4Gbps)に多重化され
る。現在、STM-256 (約 40Gbps)までの多重化が標準化されている。なお、正確には、
SONET/SDH の速度体系は 51.840Mbps の整数倍になっている。
40Gbps
STM-256 / STS-768 / OC-768
×4
10Gbps
STM-64 / STS-192 / OC-192
×4
2.4Gbps
STM-16 / STS-48 / OC-48
×4
STM-4 / STS-12 / OC-12
622Mbps
×4
155Mbps
×3
×63
52Mbps
STM-0 / STS-1 / OC-1
×7
×28
2Mbps専用線
STM-1 / STS-3 / OC-3
1.5Mbps専用線
6.3Mbps専用線
図 2.5 SONET / SDH の階層構造
表 2.1 SONET / SDH の速度体系と名称
光レベルの名前
OC-1
OC-3
OC-12
OC-48
OC-192
回線速度
51.84 Mbps
155.52 Mbps
622.08 Mbps
2488.32 Mbps
9953.28 Mbps
対応する伝送フレームの名称 (SONET / SDH)
STS-1 / STM-0
STS-3 / STM-1
STS-12 / STM-4
STS-48 / STM-12
STS-192 / STM-48
22
(3) SONET/SDH の回線とネットワーク
SONET / SDH は 2 点間を結ぶポイントツーポイントのサービスを提供するが、それ
自身は、図 2.6 に示すような光ファイバの回線を相互に接続したネットワークになっ
ている。回線の接続はクロスコネクトと呼ばれる装置で行われる。また、回線をより
高速な回線に入れる(多重化)したり、取り出したり(逆多重化)するのは、マルチプレ
クサの役目である。なお、クロスコネクトも回線の中に多重化されているより低速の
回線を相互接続できる。
SONET/ SDH の超高速専用線サービスを提供する場合には、SONET/SDH のネットワー
クの中で 2 地点間に回線が設定される。なお、図 2.6 では、メッシュネットワークを
示したが、一つのリングに多数のマルチプレクサを接続するリングネットワークの方
式もある。
SONET / SDH のマルチプレクサやクロスコネクトあるいはルータ間は光ファイバで
接続される。その無中継最大距離は使用する光ファイバによって異なる。これを表
2.2 に示す。このうちマルチモードは LAN でしか使用されない。
マルチプレクサ クロスコネクト マルチプレクサ
OC-3c
OC-48
OC-12c
ルータ
ルータ
OC-12
OC-12c
OC-48
OC-12
OC-48
OC-3c
ルータ
ルータ
マルチプレクサ
クロスコネクト マルチプレクサ
図 2.6 SONET/SDH のネットワーク例
表 2.2 無中継最大延長距離
光ファイバおよびトランシーバ種別
無中継最大延長距離
マルチモード
約 200m
シングルモード 波長 1300nm
約 40Km
シングルモード 波長 1500nm
約 80Km
23
(4) フレーム形式
SONET / SDH の転送単位はフレームと呼ばれ、これが連続して転送される。フレー
ムは、SONET では Synchronous Transport Signal (STS)、SDH では Synchronous Transfer
Module (STM)と呼ばれる。ここでは簡単化のために SONET/SDH フレームあるいは単に
フレームと呼ぶ。フレームの一例を図 2.7 に示す。これは、STM-1 (155Mbps)のフレ
ーム形式である。1 つのフレームは、9 行×270 列のバイトから構成される。転送は
左上から同じ行の右のバイトへと行われ、右端に到達すると次の行の左端から同様に
右に向って転送が行われる。右下まで到達すると今度は次のフレームを同様に転送す
る。どの速度のフレームでも、1 フレームを転送する時間は 125 マイクロ秒である。
フレームは、ネットワークの管理や監視に使用するオーバヘッドバイト部と、デー
タを入れるペイロード部から構成される。STM-1 の場合には、左から 9 列がオーバヘ
ッドバイト部である。但し、ペイロード部の左一列もオーバヘッドバイトとして使用
されるので、実際に利用できるペイロードは 9 行 260 列となる。SONET/SDH の特徴の
1 つは、このように豊富なオーバヘッドバイトを持つことにある。このおかげで、強
力なネットワーク管理機能が備わっており、誤り率を測定したり、障害の発生場所を
特定することが容易である。
(5) フレームの多重化と連結
回線の多重化を行う際には、フレームを次の上位階層のフレームに入れる。この一
例を図 2.8 に示す。図 2.8 では、4 つの STM-1 のフレームを一つの STM-4 フレーム中
オーバヘッド部
ペイロード部
9行
9列
261列
270列
図2.7 SONET / SDHフレームの構造例 (STM-1)
24
STM-4フレーム
STM-4フレーム
ポインタ
STM-1フレーム×4
STM-1フレーム×4
図2.8 SONET / SDHフレームの多重化
に入れている。この際に、4 つの STM-1 フレームの先頭が一致する必要はない。それ
ぞれの STM-1 のバイトが到着次第、ラウンドロビンで単に STM-4 フレームに入れてゆ
く。但し、それぞれの STM-1 フレームの先頭が STM-4 のオーバヘッド部にあるポイン
タで指される。このため、受信側で逆多重化を行って STM-4 を 4 つの STM-1 に戻す際
には、ポインタを参照してそれぞれの STM-1 フレームの先頭バイトを認識する。
STM-4 は、STM-1 を多重化して転送するだけでなく、それ全体を一つの通信路とし
て使用することもできる。これを連接 (concatination)と呼び、STM-1 を多重化した
STM-4 と区別するために STM-4c と記述する。この場合には、ポインタの最初にはフ
レームの先頭が入っているが、残りは連結されているという表示が行われる。
2.3.2 ATM
ここでは、非同期転送モード Asynchronous Transfer Mode (ATM)について概要を説明
する。
(1) ATM の概要
ATM は、音声やデータ等の異なる性質のトラフィックが混在するマルチメディアの
ネットワークを想定して開発されたプロトコルである。各々のトラフィックのピーク
が異なれば、個別のピークに合わせた多数の独立した回線を用意するよりも、回線の
帯域を有効に利用できる。これに対し、前述の SONET/SDH の方式は同期転送モード
Synchronous Transfer Mode (STM)と呼ばれ、それぞれの回線は予め決まった帯域を
占有する。ATM では、どのような種類のトラフィックでも正味が 48byte のセルと呼
ばれる細かいパケットに分割して転送する[31][32][33]。セルの形式を図 2.9 に示す。
25
53byte
5byte
48byte
ヘッダ
ヘッダ
ペイロード
ペイロード（データ部）
VPI
VCI
HEC
図 2.9 セル形式
セルのヘッダは 5byte であり、総セル長は 53byte である。ATM 交換機は、セルを
受信し、そのヘッダに従って回線を選択して送り出す。同一方向へのセルは同じ回線
上を運ばれる。多量のトラフィックは多くのセルを使用し、少量のトラフィックは少
量のセルを使用するので、ある単位時間で見れば、それぞれのトラフィックに応じて
帯域が動的に割り当てられることになる。
(2) フレーム形式とデータ転送
ATM のネットワーク例を図 2.10 に示す。ATM スイッチ間を接続する回線には
SONET/SDH の専用線が使用される。ATM は、通信の前に予め通信する 2 地点間のエン
ドツーエンドの経路をその経路上にあるすべての ATM スイッチのテーブルに設定す
る。即ち、ATM は通信の前に通信路を設定し、通信の終了後には、その通信路を解放
するコネクション指向のプロトコルである。セルの先頭にあるヘッダには、ATM スイ
ッチが経路を選択するための情報 Virtual Path Identifier (VPI) / Virtual Circuit
Identifier (VCI) 、エラー検出やセルを認識して同期をとるための Header Error
Check (HEC)が入っている。通信する 2 地点間のエンドツーエンドの経路はパス呼ば
れ、VPI がそれを表す。一つのパス内には複数の仮想回線を持つことができる。それ
を識別するのが VCI である。
転送元のエンドノードでは、データや音声をセルに分解して SONET/SDH のフレーム
に入れて送り出す。スイッチはセルを受信すると、そのセル内の VPI/VCI の値でテー
ブルを検索し、出側の回線を決定する。それとともに、テーブルの同じエントリに入
れられている新たな VPI/VCI の値でヘッダ内の VPI/VCI を書換える。そして、セルを
その SONET/SDH 回線のフレーム内に入れて送り出す。このようにして、セルはエンド
エンド間で転送される。目的のエンドノードに到着したセルは、再び元のデータや音
声ストリームに組み立てられる[34][35][36]。
26
ホスト
Application
ホスト
Application
TCP/UDP
IP
TCPTCP/UDP
/UDP
IPIP
AAL5
ATMスイッチ
ATMスイッチ
AAL5
ATM
ATM
ATM
ATM
SONET/SDH
SONET/SDH SONET/SDH
SONET/SDH SONET/SDH
SONET/SDH
SONET/SDH専用線
SONET/SDH専用線
SONET/SDH専用線
図 2.10 ATM のネットワーク
(3) ATM の特徴と問題点
ATM はすべてのトラフィックを細かいセルに分割することにより、あるトラフィッ
クが帯域を連続して占有しないことを保証する。その基準は音声トラフィックである。
これまでの通信網は 64Kbps の帯域を使用する電話の音声を設計の基準としてきた。
これは 8bit 長のバイトが 125 マイクロ秒ごとに転送されなければアンダーランが発
生することを意味する。そのアンダーランが発生しないようにセルは 53byte という
長さに決められた。また、スイッチングの容易さから、その長さは固定長とされた。
53byte 長は、少くとも 1 つのセルが転送されて回線や ATM スイッチ内の資源を占有
する時間が 125μ秒を越えないことを保証するが、この値は、数 Mbps から数十 Mbps
の回線速度を想定したもので、専用線の速度が数 Gbps や数十 Gbps になると、そのセ
ルが回線を占有する時間は短くなり、より長いデータの単位で転送しても問題はない。
また、データ転送での利用を想定すると、セルへの細分化がいくつかの問題を引き起
す。
それらの代表が cell tax や patches and bandaids と呼ばれる問題である。IP パ
ケットを転送する場合には、ATM Adaptation Layer type 5 (AAL5)による分解と組み
立ての方式が使用される[38]。この方法では、IP データグラムにパディングと 8byte
の Segmentation and Reassembly (SAR)トレイラを付加した後に 48byte ごとの長さ
に分割し、それぞれをセルに入れて送る。パディングは、AAL5 のデータ長が 48byte
の倍数になるように調整するためのものである。このエンキャプシュレーションの様
子を図 2.11 に示す。この時、2 つの問題が発生する。
27
IPデータグラム
ヘッダ
データ
パディング
SARトレイラ
AAL5
ATMセル
図2.11 ATMにおけるエンキャプシュレーション
(i) 固定長セルのため、最後のセルに 1byte から 47byte の未使用領域が発生して
転送効率が低下する場合がある。また、細分化するためにヘッダの割合が多く転送
効率が低下する[38]。これは cell tax と呼ばれる。
(ii) 細分化されたうちの一つのセルが転送中に損傷を受けて廃棄されても、残り
のセルは目的のノードまで転送され、無駄に帯域が使用される[39][40]。これを防
止するためには、細分化前のデータグラムを意識して廃棄する仕組みが必要である。
これは、patches and bandaids と呼ばれる。
これら以外にも、ATM は通信の前にコネクションの設定が必要となるために交換機や
エンドノード等の装置が複雑となるという問題もある[41]。
2.3.3 POS
ここでは ATM と同様に SONET/SDH を下位に使用する Packet over SONET (POS) につ
いて、その概要と問題点を説明する。
(1) フレーム形式とデータ転送方式
POS [42]は、SONET / SDH 上で IP データグラムを転送する方式である。このレイ
ヤ構造を図 2.12 に示す。プロトコルとして、PPP[43][44]、または、業界標準である
米国 cisco 社の cisco HDLC が使用される。PPP はインターネット標準のプロトコル
であり、専用線上で IP データグラムを転送するためのフレーム形式や転送手順を規
定したものである。一方、ciscoHDLC は、国際標準化機構 International Standards
Organization (OSI)によって開発された High-level Data Link Control (HDLC)フレ
ーム形式をベースにし、PPP と同じく専用線上で IP データグラムを転送するために
開発された。
28
アプリケーション
TCP/UDP
IP
POS (PPPまたはciscoHDLC)
SONET/SDH
図2.12 POSのレイヤ構造
Flag Address Control
0x7F
0xFF
0x03
8bit
8bit
8bit
Protocol
16bit
Data
FCS
0から4470byte
16bit
図2.13 PPPのフレーム構造
図 2.13 に PPP のフレーム形式を示す。フレームは、その先頭を識別するためのフ
ラグフィールドで始まる。次に、ブロードキャストを示すオール 1 の値であるアドレ
スフィールド、応答確認を行わないフレームであることを示す 0x03 の値を持つコン
トロールフィールド、そして、データ部に何のプロトコルのパケットが入っているか
を示すプロトコルフィールドが続く。データフィールドの後には、フレームの誤りを
検出するための Frame Check Sequence (FCS) フィールドが付く。
PPP における通信は、まず、オプションのネゴシエーションから開始される。これ
が終了すると接続が完了し、データの転送ができるようになる。アプリケーションか
らのデータは、TCP や UDP セグメントのデータ部にエンキャプシュレーションされる。
それは、次に IP データグラムのデータ部にエンキャプシュレーションされる。そし
て、そのデータグラムが、PPP のフレームにエンキャプシュレーションされ、
SONET/SDH
の専用線上を転送される。相手側では、逆の操作により処理され、アプリケーション
にデータが渡される。ATM と異なり、POS の場合にはレイヤ構造が簡単である。また、
IP データグラムはセルには細分化されないため、転送のオーバヘッドも少ない。
(2) POS の特徴と問題点
POS は SONET/SDH の専用線で結ばれたルータ間でデータグラムを転送するポイント
ツーポイントのプロトコルである。この方式では、対向する 2 つのルータしか通信で
29
きない。このことは、長距離を結ぶ WAN では問題にならないが、多重アスセスが必要
な LAN としては使用できないことを意味する。例えば、インターネットサービスプロ
バイダ Internet Service Provider (ISP) は、いくつかのインターネット接続点
Internet Exchange (IX)で他の ISP と相互接続を行うが、その際には IX に 設置され
たリンクレイヤの多重アクセススイッチで複数の ISP を結ぶ。POS はこのような用途
には用いることができない。
2.3.4 イーサネット
ここではイーサネットの概要を説明し、MTU および経路制御上の問題点について述べ
る。
(1) フレーム形式とデータ転送方式
イーサネット[8][45]は、同一のセグメントに複数のホストを接続できる多重アク
セス方式のリンクプロトコルである。オリジナルのイーサネットでは同軸ケーブルを
共有し、フレームの送信時に衝突があると再送信を行う Carrier Sense Multiple
Access with Collision Detection (CSMA/CD)方式[8][45]が取られていたが、現在で
は、スイッチを内蔵したハブを中心としたスター型のトポロジになっている。また、
当初 10Mbps であった転送速度も、100Mbps[46]、1Gbps [47][48]、そして、10Gbps [49]
へと高速化が行われた。しかし、フラットなアドレス構造と 1500byte の MTU に関し
ては、既存のイーサネットとの互換性を重要視したために変更がなされていない。
イーサネットフレームの構造とアドレス構造を図 2.14 に示す。フレームは転送先
アドレスから始まり、転送元アドレスが続く。アドレスの上位は製造者を表す番号で
6byte
6byte
転送先
アドレス
転送元
アドレス
2byte
48から1500byte
4byte
FCS
データ
データ長またはプロトコル
製造者番号
3byte
個別番号
アドレス構造
3byte
図2.14 イーサネットのフレーム形式とアドレスの構造
30
あり、下位は製品個々で異なる番号である。その次に、データ長のフィールドが続く。
なお、オリジナルのイーサネットでは、この部分はデータ部に入っているデータのプ
ロトコルを示すタイプフィールドになっている。現在、両方の規格が使用されている。
フレームの最後には、エラーを検出するための Frame Check Sequence (FCS)がある。
高速イーサネットでは小さい MTU とフラットなアドレス体系によって、以下の問題
が発生する。まず、MTU の問題に関して説明する。ホストが IP データグラムを転送
する場合には、転送する IP データグラムの長さをリンクレイヤの MTU 以下にする。
これはフラグメンテーション[4]が発生しないようにするためである。即ち、IP デー
タグラム長は、最大が 64Kbyte まで許されているが、下位のリンクレイヤの MTU によ
って制約を受ける[4]。このため、あるデータ量を転送する場合、MTU によって転送
に必要な IP データグラムの数が異なる。ネットワークが高速になれば単位時間に多
数のフレームが転送できるようになるが、送信側や受信側のエンドノードが単位時間
に処理しなければならないフレーム数も増大する。フレーム処理やデータグラム処理
が、送信側では前のフレームの転送が完了するまで、受信側では次のフレームが到着
するまでに完了しない場合には、それらが転送上のボトルネックとなって転送速度が
向上しない。フレームとデータグラム処理の大部分はヘッダ処理であるため、オーバ
ヘッドの増大を抑制するためには、ヘッダの処理回数、即ち、フレーム数を減らす必
要がある。このことは、大きな MTU によって長い IP データグラムを使用すれば良い
ことを意味する。ところが、イーサネットでは速度によらず 1500byte に MTU が制限
されているため、高速になるほど単位時間のヘッダ処理オーバヘッドが増大して転送
のボトルネックとなる。
次に、アドレス体系の問題がある。イーサネットではアドレス体系が階層的にでき
ていないために、最適な経路制御ができない。以下では、これを詳しく説明する。
(2) ブリッジングと Spanning Tree Protocol (STP)
複数のネットワークセグメントから構成されるイーサネットのネットワークでは、
それぞれのセグメントをスイッチで相互接続する。そのスイッチの役目は、パケット
を転送することと、パケットを転送するための経路のデータベースを保持したり作成
することである。
インターネットのようにアドレスが階層的である場合には、それぞれのセグメント
はネットワークアドレスを持ち、その配下のホストはセグメント内で一意のホストア
ドレスを持つ。各ホストは、ネットワークアドレスとホストアドレスから構成される
インターネットアドレスを持つことから、アドレスを見れば、それがどのセグメント
に接続されているかが識別できる。図 2.14 のイーサネットアドレスの構造と比較す
るため、IP アドレスの構造[50]を図 2.15 に示す.ルータは、ネットワークアドレス
31
32 bit長
ネットワークアドレス部
(可変長)
ホストアドレス部
(可変長)
図2.15 IPアドレスの階層的構造
と次に渡すべきルータのアドレスとの対応表を持ち、それに基づいてパケットを送り
出す。この対応表(経路テーブル)を作成するため、各ルータは、相互接続情報あるい
は経路情報を交換する。そして、転送先のネットワークアドレスごとに最適経路を計
算し、ネットワーク全体として、転送先アドレスをルートとするスパニングツリーを
形成する。パケットはその転送先ホストが接続されているセグメントをルートとする
スパニングツリーに沿って最適な経路で転送されることになる。これをルーティング
と呼ぶ。
一方、イーサネットは、インターネットアドレスと異なり、図 2.14 に示すように、
そのアドレスは階層的になっていない。即ち、接続されているネットワークセグメン
トを示すネットワークのアドレスが各ホストの持つアドレスにないため、パケット内
の転送先アドレスを見ただけでは、その転送先のホストがネットワーク内のどのセグ
メントに接続されているかがわからない。この問題に対処するため、ブリッジング
[51][52]を行う。ブリッジングでは、隣接するスイッチ同士が 2 秒ごとに接続情報を
通知し合い、ネットワーク接続のループを検出した場合には、ブリッジが中継機能を
停止する。これによってネットワーク全体で唯一のループのないスパニングツリーを
作成する。このプロトコルを Spanning Tree Protocol (STP) [50][51]と呼ぶ。それ
ぞれのイーサネットスイッチはネットワーク内で一意に識別される番号を持ち、その
最小値のものがスパニングツリーのルートとなる。STP ではネットワーク全体で一つ
のスパニングツリーしか持てないため、必ずしも転送先ごとに最適な経路でフレーム
が転送されるわけではない。
スパニングツリーができても、転送先のイーサネットアドレスを持つホストの接続
されているセグメントがわからないので、フレームを全セグメントに転送する必要が
ある。つまり、不要なフレームが全セグメントに転送されてしまう。そこで、スイッ
チは、自分に接続されているイーサネットセグメント上で転送されるすべてのフレー
ムの転送元を観測してテーブルに持つ。そして、フレームを受信した際には、その転
送先アドレスをテーブルで検索する。同一セグメント側ですでに観測されている転送
元アドレスであれば、そのホストが当該セグメント側に存在するということになるの
で他のセグメントに転送しない。それでも、テーブルは定期的にクリアされ、また、
32
観測中にフレームを送信していないホストあてのフレームはテーブルに入っていな
いので、不要なフレームの中継が発生してしまう。
以上の、最適経路制御が的確にできないアドレス体系を持つために発生する問題を
以下にまとめる。
(i) 少くともループのない経路を作成することができるが、ネットワーク全体で一
つのスパニングツリーを持つので、すべてのパケットが最適経路で転送されるわけ
ではない。また、ホストの場所が認識されるわけではないので、明らかに他のセグ
メントに存在しないことが認識された場合を除き、無駄にパケットの中継が行われ
ることがある。
(ii) 経路の変動が発生した場合には、ループの発生を防止するため、新たなルー
トが選択されても、ネットワークトポロジが安定すると予測される時間まで中継が
再開されない。STP では、他スイッチからの経路情報の収集に 20 秒、セグメント
上にあるホストのアドレスの学習に 15 秒、中継開始に更に 15 秒待つことになって
いる。即ち、スパニングツリーの切替に少くとも数十秒以上の時間がかかることに
なる。なお、切替時間を短縮した Rapid STP (RSTP)[53]では、より短時間で転送
が再開されるがそれにも数秒以上を要する。
これまでに説明したインターネットのリンクレイヤに使用される代表的プロトコルを
表 2.3 にまとめる。この表には、第 3 章で説明する MAPOS も比較のために示しておく。
表 2.3 リンクレイヤのネットワークの特徴と問題
プロトコル
トポロジ
コネクション
アクセス方式
MTU (byte)
ATM
メッシュ
POS
ポイントツー
ポイント
バス / メッシ
ュ
メッシュ
コネクション
指向
コネクション
レス
コネクション
レス
コネクション
レス
ポイントツーポイ
ント
ポイントツーポイ
ント
多重アクセス
(マルチポイント)
多重アクセス
(マルチポイント)
9180
(RFC1626)
4K
ethernet
MAPOS
1500
64K
動的経路
制御
なし
SONET/SDH との
接続性
あり
なし
あり
ブリッジ
ング
ルーティ
ング
なし
(10GbE はあり)
あり
2.4 ネットワークプロトコル実装方式
この節では、インターネットプロトコルを対象としたプロトコルの実装方式について
説明する。説明にあたっては、レイヤとプロトコルとを一対一に対応させ、従来方式を
踏襲した Symbolics 社の LISP Machine や x-kernel のアプローチを説明する。
33
2.4.1 従来のネットワークのプログラミングパラダイム
ネットワークプロトコルは、2.2.3項で説明したようにレイヤ構造でモデル化され、
明確にモジュール化されて設計されている[11][12]。それぞれのレイヤでは、それが提
供するサービスとインタフェースだけが規定されており、その実現方法を隠蔽すること
ができるようになっている。このため、それぞれのプロトコルに対応するソフトウェア
をモジュールとして設計し、それらの入出力を結合することによって全体のシステムを
構成する。モジュールは、下位レイヤのモジュールからパケットを受け取ると、それを
処理し、上位レイヤのモジュールへ渡す。また、上位レイヤのモジュールからパケット
を受け取った場合には、それを処理した後に下位のレイヤのモジュールに渡す。これに
基く一般的な実装のモジュール構造、および、パケット処理の流れを図2.16に示す。
この方式では、各レイヤのプロトコルに対応するレイヤモジュールLは、受信したパ
ケットの処理を行うサブモジュールと転送するパケットの処理を行うサブモジュール
から成り、レイヤモジュール間では、キューQを介して処理すべきパケットをやり取り
する。レイヤLnのモジュールは、下位レイヤLn-１のモジュールの処理が完了したパケッ
トをキューQin-1, nから取り出し、そのパケットの処理を行った後、それを上位レイヤLn+
のモジュールへ渡すためにキューQin, n+1に入れる。レイヤLnのモジュールは、この処理
１
を繰り返す。
レイヤモジュール L n+1
レイヤモジュール L ｋ
Q on+1,n
Q in,n+1
レイヤモジュール L n
Q on,n-1
Q in,k
Q in-1,n
レイヤモジュール L n-１
図2.16 従来のモジュール構造
34
2.4.2 従来のアプローチの問題点
Symbolics社のLISP Machine [54] やx-kernel [55] に代表されるこれまでのアプロ
ーチは、レイヤのプロトコルとオブジェクトを1対1に対応させたものである [54][55]。
この方法は、プロトコル間の関係が静的なものであれば問題ない。しかし、プロトコル
開発では、その効率を向上させるため、探索的にプログラミングを進める必要がある。
即ち、変更前と変更後のプロトコルの動作比較や検証のために、わずかに異なるバージ
ョンのプロトコルがシステムに混在できる必要がある。このような状況では、プロトコ
ル間の関係は動的に変化する。
例えば、図2.16のレイヤLnのプロトコルを変更する必要があれば、そのモジュールを
直接書き換えなければならない。また、レイヤLnの上位に新たなプロトコルレイヤLkを
新設する場合、レイヤLnからの出力が、Qin, kに向けられるようにレイヤLnの出力すべき
キューを選択する部分を書き換えなければならない。この方式では、すべてのパケット
が、同一のレイヤモジュールで処理されるため、モジュールの変更の失敗は、すべての
パケットの処理に影響が及ぶ。即ち、影響の局所化が困難である。また、モジュールの
変更中は、ネットワークのサービスが全面的に止まってしまう。
これらの問題を以下にまとめる。
(1) 異なったプロトコルモジュールの共存ができない静的なモジュール間結合
これまでのアプローチでは各レイヤのプロトコルに対応するモジュールは、システ
ムの初期化の時点からサービスの終了の時点まで永続的に存在するものであった。し
かし、新たなプロトコルの設計/評価を行うワークベンチやプロトコルの進化に合わ
せてソフトウェアの改良を行う場合には、従来のプロトコルモジュールも同時に走行
させて機能を確認しながら開発が行える必要がある。従来の実装方式では、受信した
パケットすべてが同一プロトコルモジュールで処理されるため、図2.16に示すように
新たなレイヤモジュールLkを用意して切り替えた場合、これまでのレイヤモジュール
Ln+1にはパケットを渡すことができない。
(2) 問題の波及
従来の方式で新規モジュールを開発する場合、新旧モジュールの混在ができないた
めに、すべてのパケットが新規モジュールで処理されることになる。従って、新規モ
ジュールに問題が発生した場合には、すべての通信にその問題が波及してしまう。こ
のような問題の波及を制限できる手段はない。
35
2.5 本研究の位置付け
この節では、これまでに説明してきた従来の方式と比較することによって、本研究の
位置付けを明確にする。本研究の目的は、エンドツーエンドの超高速データ通信向きリ
ンクプロトコル群の要件を明らかにすること、データ転送プロトコルとネットワーク制
御プロトコルの両方を含む体系的なプロトコル群として超高速データ通信向きプロト
コルを提示すること、そして、探索的なプロトコル開発を可能とするために、同一レイ
ヤに僅かに異なるプロトコルの混在を許す実装方式を提示することである。
まず、2.3節における議論から、インターネットにおけるエンドツーエンドの高速化
を行うためには、インターネットプロトコルと親和性があり処理オーバヘッドの小さい
プロトコルが重要であることがわかった。ネットワークのエンドツーエンドの速度を低
下させる要因の一つは、データグラムの細分化である。細分化は、エンドノード、即ち、
ホストにおけるヘッダ処理のオーバヘッドを高め、スループットを低下させる。これに
対し、本論文で提示するMAPOSではIPデータグラムの最大長である64Kbyteを細分化せず、
しかも、可変長のフレームを転送できる長大MTUを実現する。 2.3.1項の議論では、超
高速の専用線がSONET / SDHに基づくものであることを示した。LANだけではなく、WAN
への適用を考えると、そのシームレスな接続のために、SONET / SDHを下位レイヤに使
用することが不可欠となる。また、LANとしての利用を想定すると、このプロトコルが
多重アクセス機能を備える必要がある。
2.3.4 項の議論では、フレームを最適な経路で転送するためには、ブリッジングでは
なくルーティングが必要であることがわかった。これに加え、 ネットワークトポロジ
の変動に対して迅速に収束する経路制御が行えることが重要となる。これまでの超高速
向きリンクプロトコルは、そのデータ転送能力だけに目が奪われ、ネットワークシステ
ムを構成した場合のシステム構成制御には目が向けられていない。これに対し、本研究
では、まず、アドレス体系に階層化アドレスを導入するとともに、その経路切替時間を
数十から数百ミリ秒程度に収まる経路制御アルゴリズムとプロトコルを考案する。開発
にあたっては、MAPOS だけでなく、BGP のようなインターネットの広域経路制御にも適
用できる汎用性を持つものを目標とする。
新たなプロトコルを開発する場合に最も問題となることは、新規の開発コストと開発
に要する時間である。これらの開発オーバヘッドを最小に抑えるには、新規のプロトコ
ルが従来のハードウェアやソフトウェアを利用できるように、従来のプロトコルとの互
換性を持たせる必要がある。従来のプロトコルとは、従来のリンクプロトコルだけでな
く、リンクプロトコルが使用する下位のレイヤのプロトコルとの互換性も含む。そこで、
本論文でとりあげる MAPOS では、従来の POS のフレーム形式および SONET/SDH 上の転送
方式と互換性を持たせることによって、最小限の工数で実現できることをねらう。
以上説明してきたプロトコル群の開発を短時間で進めるためには、探索的なプロトコ
36
ル設計が重要になる。しかし、従来の開発システムでは、プロトコルとモジュールは 1
対 1 に対応しており、同一のシステム内に異なるバージョンのプロトコルが共存できな
い。各レイヤに相当するモジュールがシステム内に唯一つしか存在しないために、当該
モジュールの変更の影響がすべての通信中のサービスにも及んでしまう。そこで、本論
文では、上位レイヤが下位レイヤの性質を継承するというパラダイムに基づく実装方式
を開発する。この方法では、個々のバーチャルサーキットをオブジェクトとする。その
オブジェクトは、必要なプロトコルを継承したものである。このため、バーチャルサー
キットごとに異なるバージョンのプロトコルモジュールを継承すればプロトコルの組
み合わせを変更でき、僅かに異なるプロトコルが一つのシステム内に混在することにな
る。それらは、互いに影響を及ぼすことなく動作する。実装方式の開発にあたっては、
一般のネットワークシステムの開発に適用できるような汎用性のある方式を目標とす
る。この方式の検証を行うため、NTT 研究所で開発された記号処理計算機 ELIS 上の言
語 TAO のオブジェクト指向を用いて実装する。そして、実装したプログラムのオブジュ
クト指向との親和性やオーバヘッドを明らかにする。
37
第 3 章 MAPOS プロトコル群
概要
本章では超高速データ通信向きの多重アクセスプロトコル群 MAPOS について説明する。
MAPOS は、超高速専用線の標準である SONET/SDH プロトコル上に HDLC フレームを乗せ
た極めて簡明なデータ転送プロトコルを中心とするプロトコル群である。リングやメッ
シュ等のトポロジの制約なしに自由なトポロジのネットワークを構築することができ
る点、WAN と LAN との接続におけるシームレス性、速度および距離のスケーラビリティ、
従来の POS との互換性、長大フレームによるエンドノードのプロトコル処理オーバヘッ
ドの軽減、極めて短時間のうちにトポロジの変化に追従できる経路制御等を特徴とする。
この機能検証を行うため、MAPOS プロトコル群を、総容量 87.04Gbps の高速 MAPOS スイ
ッチ COREswitch および 2.4Gbps の高速ホストインタフェースとして実装した。そして、
非圧縮 HDTV 伝送システムのアプリケーションにおいて、MAPOS のスループットとエラ
ー率を測定することによって長大フレームの効果を検証した。また、POS との互換性に
よる実装の容易さを検証するために、業界標準の cisco 社製ルータへ実装し、ハードウ
ェアに一切の改造を加えることなく、ソフトウェアの変更だけで MAPOS が稼働すること
を実証した。
38
3.1 はじめに
本 章 では 超 高 速 デ ータ 通 信 向 き の 多 重 アク セ ス プロ ト コ ル 群
MAPOS[56][57][58][59][60][61][62][63]について説明する。MAPOS は、超高速専用線
の世界標準である SONET/SDH プロトコル上に PPP が使用するものと同じ HDLC フレーム
を乗せた極めて簡明なプロトコル群である。このプロトコル群は、ATM における転送効
率の問題、GbE/10GbE における経路収束の遅さの問題や速度のスケーラビリティの問題、
多重アクセスができないという POS の問題、速度体系の相違による LAN と WAN との相互
接続性の問題等を解決すべく開発された。その特徴は、(1) プロトコルの簡明さ (2) 長
大フレームによる転送効率の高さ (3) LAN と WAN とのシームレス性、 (4) 速度および
距離のスケーラビリティ (5) POS との互換性による実装の容易さ (6) アドレスの自動
割り当てや動的経路制御によるプラグアンドプレイ (7) 経路収束の速さ (8)特定のト
ポロジに制限されない自由なネットワーク構成 等にある。
この機能検証を行うため、MAPOS プロトコル群を、総容量 87.04Gbps の高速 MAPOS ス
イッチ COREswitch[64][65][66]および 2.4Gbps の高速ホストインタフェース[67]とし
て実装した。そして、非圧縮 HDTV 伝送システムのアプリケーション[68]において、MAPOS
のスループットとエラー率を測定することによって長大フレームの効果を検証した。そ
の結果、Pentium III 1.26Ghz CPU を使用した汎用の PC 間でも、MAPOS の長大フレーム
であれば最大 1.5Gbps のストリームを 10-9 から 10-10 程度のエラーレートで転送するこ
とができるということが明らかになった。また、POS との互換性による実装の容易さを
検証するために、業界標準の cisco 社ルータへ実装し、ハードウェアに一切の改造を加
えることなく、ソフトウェアの変更だけで MAPOS が稼働することを実証した。
3.2 従来の高速プロトコルの問題点と超高速リンクプロトコルの要件
本節では、従来の高速リンクプロトコルの効率や経路の収束性等の問題点を明らかに
し、これらの問題に対する MAPOS のアプローチを説明する。
3.2.1 従来の高速プロトコルの問題点
これまで、数百 Mbps から数 Gbps の転送遠度をターゲットとするいくつかのプロトコ
ルが開発され、データ通信用のリンクレイヤプロトコルとして利用されている。例えぱ、
ATM、GbE/10GbE、POS などである。しかし、ATM は Cell Tax と呼ばれる細分化によるベ
イロードの減少[38][39]、Patches and Bandaids と呼ばれるフレームを意識したセル
廃棄アルゴリズムの複雑さ[40]、コネクション設定[41]のオーバヘッドなどの問題があ
る。また、GbE や 10GbE では、1Gbps から 10Gbps までの間の中間速度がなく、速度のス
39
ケーラピリティに欠ける。また、アドレス体系が階層的になっていないために最適経路
制御が困難であり、ルーティングの代りに STP プロトコル[51][52][53]を使用して単一
のスパニングツリーを形成し、その上でブリッジングを行っている。このため、経路の
収束時間が長く、トポロジに変化があると数十秒間停止してしまう。一方、POS で使用
される PPP や ciscoHDLC プロトコルでは、HDLC フレームを単位として転送するために、
すでに述ぺた ATM の間題を避けることができるものの、ポイントツーポイントの接続し
かできず、多重アクセス機能は提供していない。
3.2.2 フレームとセルの転送効率
MAPOS や POS のようにフレーム単位でデータ転送を行った場合と ATM のセル単位で転
送を行った場合の転送効率を比較する。ATM の場合、53byte の固定長セルを使用する。
ペイロードは 48byte であり、
これを 1byte でも超過すれば、次の 53byte 長セルが 47byte
のパディングを含めて転送される。また、ATM の AAL5 エンキャプシュレーション方式
[37]で転送した場合、Segmentation and Assembly (SAR)トレイラが 8byte 付加される。
更に、AAL5 のデータ長をセルの整数倍にするためにトレイラの付加前にパディングも
行われる(図 2.11 を参照)。一方、
MAPOS や POS のヘッダ長は HDLC のヘッダ長である 4byte
にフラグ 1byte、そして、2 ないし 4byte の FCS が付加され、合計で最大 9byte のオー
バヘッドとなる。これらに加え、TCP による転送を想定すると、IP と TCP ヘッダ長の合
計 40byte(オプションのない場合)を考慮しなければならない。
まず、ATM の場合の帯域使用率を以下に示す。
n =
┌
(L + 40 + 8) / 48┐
u = L / (n × 53)
(1)
ここで、
L : 転送するデータ長
n : 転送に必要なセル数
u : 帯域利用率
である。一方、フレーム単位でデータ転送を行う MAPOS や POS の場合には以下のように
なる。
u = L / (L + 40 + 9)
(2)
以下ではこれら 2 つの場合の転送効率を、SONET/SDH の OC-3 (155.52Mbps)回線を想定
して具体的に比較する。まず、OC-3 の SONET/SDH フレームのオーバヘッドを考える。
40
OC-3 のフレームは 9 行×270 列であり、そのうち、ヘッダにあたるオーバヘッドバイト
の部分は、セクションオーバヘッドが 9 行×9 列、パスオーバヘッドが 9 行 1 列である。
このため、155.52Mbps の帯域のうち使用できる帯域は、
その 260 / 270、即ち、
149.76Mbps
である。この帯域を MAPOS や ATM が使用する。これに、式(1)(2)を適用して、1byte か
ら 10Kbyte までのデータに対するスループット (Mbps) を計算したものが、図 3.1 であ
る。
ATM の場合には、パディングが 1byte から 47byte まで変化するために、48byte ごと
に効率の落ちこみが発生する。TCP による転送を想定し、その IP と TCP ヘッダ(IP ヘッ
ダが 20byte、TCP ヘッダも 20byte の合計 40byte)もオーバヘッドに含めると、データ
長が 10Kbyte 以下の領域では全体のオーバヘッドが 99.1%から 9.9%の範囲になる。一方、
MAPOS の場合には、可変長フレームのため、このような落ちこみは発生しない。また、
どの長さのデータも 9byte のオーバヘッドを持つ 1 フレームで転送されるため、そのオ
ーバヘッドは、TCP による転送を想定した場合、データ長が 10Kbyte 以下の領域では
98.0%から 0.5%の範囲となる。以上から、転送の効率を高めるには、セルよりもフレー
ム単位で転送を行わなければならないことがわかる。
MAPOS
ATM
図 3.1 ATM と MAPOS の場合の転送効率
41
3.2.3 MTU と細分化
インターネットで転送できる最大の IP データグラム長は、データグラムの送信元か
ら送信先までの経路中にあるネットワークセグメントの最小 MTU サイズに依存する。IP
データグラムを生成するエンドノード、即ち、ホストの IP プロトコルでは、IP データ
グラム長を、送り出すネットワークセグメントの最小 MTU サイズ以下にして転送する2。
一方、IP データグラムを中継するルータは、IP データグラムを中継する際、次に送り
出すネットワークセグメントの MTU をデータグラム長が越えた場合には、それを MTU 以
下の複数の IP データグラム (フラグメント) に分割する。これらのフラグメントは、
転送先のエンドノードによって元の IP データグラムへ組み立てられる。
同一のデータ量を転送する場合、できるだけ長い IP データグラムで転送したほうが
エンドノードの CPU オーバヘッドが少なくなる。それは、ヘッダ処理の回数が少なくな
るからである。例えば、TCP では、データグラムの処理時間が長くなると、それに対す
る確認応答(acknowledge)パケットの返送も遅れ、ボトルネックとなる[69]。また、UDP
においては、受信バッファのオーバフローが発生し、動画等のストリームにおいて画像
の乱れや欠落が発生する。このような問題を抑制するためには、リンクレイヤが大きな
MTU サイズを持つことが必要となる。特に、超高速の通信においては、上位レイヤであ
る IP が提供する 64Kbyte の最大 IP データグラムがそのまま転送できる MTU サイズが必
要である。この効果については 3.6 節で実測値を示して説明する。
3.2.4 LAN と WAN とのシームレス性
LAN のネットワークセグメントに遠隔地にある LAN やエンドノードを収容する場合に
は、専用線等の WAN の回線を使用する。通常、LAN と WAN ではプロトコルや速度体系が
異なるため、接続には変換装置を使用せざるを得ない。例えば、インターネットサービ
スプロバイダ Internet Service Provider (ISP) 同士を接続するインターネット接続
点 Internet Exchange (IX)では、各 ISP のルータを LAN の同一ネットワークセグメン
トに接続しなければらない。これは、相互接続用経路制御プロトコル BGP (Border
Gateway Protocol)[23]の制約条件によるものである。もし、離れた場所にある各 ISP
のルータを IX に設置された相互接続用 LAN スイッチに直接収容できるのであれば、相
互接続のシステムは簡単になる。しかし、LAN をそのまま延長できないため、IX 内に各
ISP がルータを設置し、それらと各 ISP の建物内のルータとを WAN で接続するという複
雑な構成を取る。即ち、IX に設置されたルータは LAN と WAN との変換装置の役割を負
う。この方法では、大規模な IX の場合、ルータの設置場所が不足したり、ルータの設
場合によっては、経路中の最も小さい MTU を検出してその MTU 以下で送り出す。これ
は、Path MTU Discovery (RFC1191)と呼ばれる。
2
42
置によってその料金の支払が各 ISP に必要になるという問題がある。
これらの問題は、LAN のプロトコルが WAN のプロトコルとの親和性がないことから発
生する。もしも、それらがシームレスに接続できれば、各 ISP の建物内にある相互接続
用のルータを IX 内の LAN スイッチへ直接接続することができ、システムが簡素化され
る。また、ルータ設置場所や料金の問題を解決できる。そこで、WAN に使用される超高
速専用線がすべて SONET/SDH[25][26][27][28][29][30]であることを考慮すると、WAN
と LAN がシームレスに接続できるためには、LAN のプロトコルが SONET/SDH をその下位
に使用する必要があることがわかる。下位に SONET/SDH を使用することにより、次のよ
うな利点も得られる。即ち、LAN が SONET/SDH の速度体系と長距離にわたる無中継伝送
機能を継承することとなり、速度と距離のスケーラビリティを得ることができる。また、
既存の SONET/SDH の装置をそのまま使用してネットワークを構築することもできる。
3.2.5 アドレス体系と経路制御
2.3.4 項で説明したように、イーサネットアドレスにはエンドノードが接続されてい
るネットワークセグメントを示すネットワークのアドレスが存在しないため、最適な経
路でのフレームの中継ができない。これに加え、障害などによる経路の切替えに数十秒
以上を要する。たとえ Rapid STP (RSTP)[53]を使用しても数秒以上かかるという問題
もある。また、どのセグメントに転送先アドレスを持つエンドノードが接続されている
かがわからないため、学習による転送の抑制は行うものの、無駄にすべてのセグメント
へフレームの中継が行われることがある。
これらのさまざまな問題は、フラットなアドレス体系にその根本的原因がある。各フ
レームを最適経路で転送するためには、フラットなアドレス体系ではなく、インターネ
ットアドレスのような階層的なアドレス体系が必要である。このようなアドレス体系で
は、経路制御が可能となり、それぞれの転送先アドレスごとにフレームが最適経路で転
送される。また、障害が発生した場合にも、高速に経路を収束させることができる。
3.2.6 超高速リンクプロトコルの要件
これまでの議論によって、超高速プロトコルには少くとも以下の要件が必要であること
がわかる。
(1) 一つのネットワークセグメントに多数のエンドノードを接続できる多重アクセ
ス機能が提供できること。
(2) 効率の良い転送を行うためにフレーム転送をベースとし、エンドノードでのフレ
43
ーム送信や受信のオーバヘッドを少くするために大きな MTU を持つこと。
(3) LAN と WAN とのシームレスな接続が可能であること。そのためには、LAN であっ
ても超高速専用線で唯一のプロトコル SONET/SDH をベースとする必要がある。これに
よって、SONET/SDH の速度および距離のスケーラビリティが継承される。
(4) 最適経路でフレームが転送され、また、速い経路収束が行われるためには、経路
制御を必要とする。そのためには、アドレス体系が階層的でなければならない。
これら以外に、特定のトポロジに制限されない自由なネットワークが構成できること、
実装を容易にするため、プロトコルの簡明さや従来のプロトコルとの互換性をリンクプ
ロトコルが持つことが必要である。また、利用者の設置作業を最小限にするため、リン
クレイヤのアドレスの自動割り当てや動的経路制御というプラグアンドプレイの機能
も必要とされる。本論文で述べる MAPOS プロトコル群は、これらの要件をすべて満たす
ものである。
3.3 MAPOS のアーキテクチャとプロトコル概要
この節では、まず、MAPOS のプロトコル概要を説明し、MAPOS ネットワークのアーキ
テクチャを示す。そして、MAPOS のフレーム形式と転送方式について、概要を説明する。
3.3.1 プロトコルの概要と特徴
MAPOS は 3.2.6 項で述べた超高速リンクプロトコルの要件を満し、以下のような特徴
を持つ。
(1) MAPOS スイッチによる多重アクセス
MAPOS は、フレーム中の転送先アドレスを判断して中継を行う MAPOS スイッチによ
り多重アクセス機能を提供する。エンドノードは、光ファイバにより、この MAPOS ス
イッチに接続される。また、MAPOS スイッチ同士を接続し、多数のエンドノードを持
つ自由なトポロジのネットワークを構築することができる。
(2) 最大 65280byte の長大フレーム
MAPOS はフレーム単位で転送を行うコネクションレスのプロトコルである。
44
65280byte までの長大フレームを転送することができるので、最大長の IP データグ
ラムであってもフラグメントが発生しない。これにより、エンドノードにおけるヘッ
ダ処理のオーバヘッドを滅らし、エンドツーエンドでのワイヤスピード転送を実現す
る。
(3) SONET/SDH の継承によるシームレス性、距離と速度のスケーラビリティ
MAPOS は、その下位レイヤに超高速専用線のプロトコルである SONET/SDH を使用す
る。これによって、距離と速度のスケーラビリティを継承する。即ち、SONET/SDH と
同じ 51.84Mbps ( STS-1 / STM-0 ) から 10Gbps ( STS-192 / STM-48 ) あるいはそ
れ以上の速度までのスケーラビリティを持つ。また、シングルモードの光ファイバを
使用した場合、40Km から 80Km までネットワークセグメントを延長できる。更に、LAN
から WAN に至るまで、シームレスなネットワークの構築ができる。ネットワークの構
築にあたっては、既存の SONET / SDH 用の伝送システムや超高速専用線サービスをそ
のまま利用できる。
(4) フレームの最適経路制御と経路収束の速さ
MAPOS は階層的なアドレス体系を持ち、ブリッジングではなく、各ネットワークセ
グメントがどこに位置するかを示す経路情報の交換によって経路制御(ルーティン
グ)を行う。このため、それぞれのフレームがその転送先までの最短経路(スパニング
ツリー)を通って転送される。また、経路制御にあたっては、経路情報の発生時間を
経路情報に含める時相パスベクトル経路制御アルゴリズム Temporal Path Vector
Algorithm (TPV)[70]によって、古い経路情報による新しい経路情報の上書きや古い
経路情報の滞留を防止する。その結果、経路の収束が極めて短い時間で済む。なお、
TPV については第 4 章で説明し、この章では、マルチキャストの転送アルゴリズムだ
けを示す。
(5) シンプルさと効率の高さ
MAPOS は、コネクションレス[7][11][12]のプロトコルで、ATM と異なり通信の前後
にコネクションの設定や切断が必要ない。このため、呼制御やコネクションの管理の
オーバヘッドがない。また、IP などのコネクションレスのプロトコルとの親和性を
持つ。
45
(6) PPP フレームとの互換性
POS[42]の PPP[43]で使用する HDLC フレーム[44]と MAPOS のフレームに互換性を持
たせることにより、既存の POS ハードウェアの改造なしにソフトウェアの変更だけで
プロトコルの実装を可能とし、開発コストの低減と開発時間の短縮を可能とする。
(7) プラグアンドプレイ
ホストアドレスや経路テーブルなどの設定は、ユーザにとって重荷になるばかりで
なく障害の原因となりがちである。MAPOS では、スイッチがエンドノードにアドレス
を自動的に割り当てるプロトコル[58]、動的経路制御のプロトコル[59][70]により、
ユーザは機器を接続するだけでサービスを利用できる。
3.3.2 MAPOS ネットワークのアーキテクチャ
MAPOS ネットワークは、ホストやルータ等のエンドノード、MAPOS スイッチ、エンド
ノードとスイッチを結ぶ光ファイバによって構成される。図 3.2 に示すように、MAPOS
スイッチはいくつもの SONET/SDH のポートを持っており、それぞれのエンドノードに全
二重の多重アクセス機能を提供する。
ホストやルータ等のエンドノードは、MAPOS ネットワーク内で一意に識別されるアド
レスを持つ。エンドノードが IP デークグラムを転送する際には、それを HDLC フレーム
のデータ領域に入れ、ヘッダには転送先のエンドノードが持つ MAPOS アドレスを設定し
て MAPOS スイッチヘ送り出す。MAPOS アドレスは、各 MAPOS スイッチのアドレスを示す
ネットワークアドレス部と、そのスイッチに接続されたエンドノードを示すホストアド
レス部とから構成される。ネットワークアドレス部は、各 MAPOS スイッチを MAPOS ネッ
トワーク内で一意に識別するためのものである。スイッチがフレームを転送する際には、
エンド
ノード
エンド
ノード
MAPOSスイッチ
エンド
ノード
エンド
ノード
エンド
ノード
エンド
ノード
MAPOSスイッチ
エンド
ノード
エンド
ノード
図3.2 MAPOSネットワークの構成
46
そのネットワークアドレス部をキーにスイッチが保持する経路テーブルを検索する。経
路テーブルには転送先アドレスと次に渡すべきスイッチやホストへ接続されているポ
ート番号が入れられている。スイッチは、検索された結果に従って指定されたポートか
らフレームを送り出し、次のスイッチへ中継する。このようにして中継されたフレーム
は最終的に目的のホストまたはルータヘ渡される。経路テーブルにエントリがない転送
先アドレスの場合には、当該フレームをそのまま破棄する。なお、MAPOS では、ユニキ
ャストだけでなく、ブロードキャストやマルチキャストもサポートしている。これにつ
いては 3.5 節で説明する。
MAPOS ネットワークの諸元を表 3.1 に示す。下位のプロトコルとして SONET/SDH を使
用しているため、その速度体系および最大延長距離は SONET/SDH と同じである。
表 3.1 MAPOS の諸元
項目
回線速度
無中継延長可能距離
最大ノード数
最大フレーム長 (MTU)
経路収束速度
アクセス方式
サポートするフレーム
ネットワークトポロジ
光キャリア名
回線速度
伝送シグナル仕様名
(SONET / SDH)
OC-1
51.84 Mbps
STS-1 / STM-0
OC-3
155.52 Mbps
STS-3 / STM-1
OC-12
622.08 Mbps
STS-12 / STM-4
OC-48
2488.32 Mbps STS-48 / STM-12
OC-192
9953.28 Mbps STS-192 / STM-48
マルチモード : 約 200m
シングルモード : 波長 1300nm で約 40Km
シングルモード : 波長 1500nm で約 80Km
RFC2171 (8 ビット長アドレス) で約 60 台
RFC2175 (16 ビット長アドレス) で約 8 千台
約 64Kbyte
数十ミリ秒から数百ミリ秒程度
MAPOS フレームスイッチを使用する多重アクセス方式
ユニキャスト、マルチキャスト、ブロードキャスト
制限なし
3.3.3 MAPOS のフレーム形式とエンキャプシュレーション
図 3.3 に MAPOS と POS(PPP)のフレーム形式を示す。MAPOS のフレームの形式は、PPP
が使用する HDLC フレームと互換性を持つ。8 ビット幅のアドレスを使用する MAPOS8 で
は PPP で固定値(0xFF)が入れられているアドレスフィールドを MAPOS のアドレスフィー
ルドとして利用する。また、16 ビット幅のアドレスを使用する MAPOS16 では PPP のア
ドレスフィールドと、それに続くコントロールフィールド(PPP では 0x03 の固定値)の
連続 16 ビットを MAPOS のアドレスフィールドとして利用する。その他の部分は、MTU
が長いことを除いて変更がない。
47
Address
8 bits
Control
8 bits
Protocol
16 bits
Information (Data)
0∼65280 byte
FCS
16/32 bits
MAPOS8 フレーム形式
Address
16 bits
Protocol
16 bits
Information (Data)
0∼65280 byte
FCS
16/32 bits
MAPOS16 フレーム形式
0xFF
8 bits
0x03
8 bits
Protocol
16 bits
Information (Data)
0∼4470 byte
FCS
16/32 bits
PPP のフレーム形式
図 3.3 MAPOS8/16 および PPP のフレーム形式
エンドノードのアドレスは、スイッチによって自動的に付与される。この 8 ビットも
しくは 16 ビットのアドレスは、上位がネットワークアドレス、下位がホストアドレス
である。ネットワークアドレスは、MAPOS スイッチがフレームを転送する際に、次に渡
すべきスイッチやエンドノードを決定するために使用する。これらのビット幅は構築す
るネットワークによって自由に選択することができる。このため、経路情報の交換の際
には、ネットワークアドレスとホストアドレスとの境界を示すネットマスクもアドレス
と一緒に交換される。
MAPOS のホストやルータ等のエンドノードがフレームを転送する場合には、転送先の
エンドノードの MAPOS アドレスをフレームの転送先アドレス部に入れる。なお、アドレ
スの最上位ビットは、ユニキャストでは 0 である。マルチキャストやブロードキャスト
の場合には、最上位ビットが 1 となる。マルチキャストの場合には、残りのビットはマ
ルチキャストを受信すべきエンドノードが属するグループの識別子 Group ID (GID) が
入る。ブロードキャストの場合には、オール 1 である。ブロードキャストはすべてのエ
ンドノードで受信されるが、マルチキャストはアドレスで指定されたグループに属する
エンドノードでのみ受信され、所属していないグループあてのマルチキャストを受信し
たエンドノードはそれを破棄する。図 3.4 に MAPOS16 のアドレス構造を示す。
16bit長
ネットワークアドレス部(可変長)
ホスト(エンドノード)アドレス部(可変長)
図 3.4 MAPOS16 のアドレス構造
48
IPデータグラム
MAPOSフレーム
SONET/SDHフレーム
図3.5 エンキャプシュレーション
エンドノードが IP データグラムを転送する際には、それを MAPOS フレームのデータ
部へエンキャプシュレーションする。更に、この MAPOS フレームを SONET/SDH のペイロ
ード部に入れて転送する。これを図 3.5 に示す。スイッチは、SONET/SDH のペイロード
から、MAPOS フレームを取り出し、次に転送すべきポートを判断し、送りだす回線の
SONET/SDH のペイロード部へ入れてそのポートから送り出す。転送先のエンドノードで
は、SONET/SDH のペイロードから MAPOS フレームを取り出した後、MAPOS フレームのデ
ータ部から IP データグラムを取り出す。そして、ネットワークレイヤにある IP に渡す。
IP では、その上位プロトコルを判断して、トランスポートレイヤにある TCP あるいは
UDP に渡す。
3.3.4 MAPOS プロトコル群の構成
MAPOS におけるプロトコルレイヤを図 3.6 に示す。MAPOS の下位には SONET/SDH のレ
イヤがある。また、MAPOS の上位には IP のレイヤがある。MAPOS は、単一のプロトコル
ではなく、アドレスの自動設定や経路制御プロトコルも含むプロトコル群である。以下
では、個々のプロトコルについて概要を説明する。
(1) 8 ビットのアドレスフィールドを持つ MAPOS8 のフレームの形式と中継方式を規
定する基本プロトコル (RFC2171)[56]
(2) エンドノードへの動的な MAPOS アドレスの割り当てを規定する NSP (Access-node
Switch Protocol) (RFC2173)[58]
49
TCP/UDP
IP
MAPOS (RFC2171/RFC2175)
Tunneling
(RFC3186)
ARP
NSP
(RFC2176) (RFC2173)
SSP/ESSP
(RFC2174)
SONET/SDH
図3.6 MAPOSのプロトコルレイヤ
(3) Distance Vector (DV) アルゴリズムに基づくスイッチ間の経路制御を規定する
SSP (Switch-Switch Protocol)
(RFC2174)[59]
(3)' 時相パスベクトルを導入し収束時間の短縮を行った拡張経路制御プロトコル
ESSP (Extended Switch-Switch Protocol)[70]
(4) 16 ビットのアドレスフィールドを持つ MAPOS16 のアドレス形式を規定する基本
プロトコル (RFC2175)[60]
(5) IP を使用する場合に必要な IP アドレスと MAPOS アドレスとの動的な対応付けを
行う ARP (Address Resolution Protocol) (RFC2176)[61]
(6) MAPOS ネットワーク上で、POS の PPP を使用したノード間にポイントツーポイン
トのサービスを提供するためのトンネリングプロトコル (RFC3186)[62]
これらの他、HDLC フレームのプロトコルフィールドの値を割り当てる RFC2172[57]など
も規定されている。
3.4 アドレス長と中継速度に関する検討
一般にスイッチは、あるポートからパケットを受信するとその転送先アドレス部を検
査し、その値をキーとして経路テーブルを検索し、そのパケットを渡すポートを決定す
る。そして、そのポートからパケットを送り出す。例えば、IP データグラムを中継す
るルータでは、処理対象となるアドレス部の長さは 4byte である。それに必要なテーブ
ルのエントリ数は 232 となる。また、イーサネットのフレームを中継するイーサネット
スイッチの場合には、処理対象となるアドレス部の長さが 6byte である。このため、そ
50
れに必要なテーブルのエントリ数は 248 となる。これらを実装する場合には、必要なメ
モリサイズと検索のオーバヘッドが問題となる。これらの問題に対し、テーブルの一部
をハードウェアあるいはソフトウェアによってキャッシュとして持ち、ヒットしない場
合には経路テーブル内からキャッシュにロードする方法が用いられる。しかし、ハード
ウェアやソフトウェアの複雑さ、出現するパケット転送先の頻度のパターンに性能が左
右されるという問題がある。
そこで、MAPOS では、簡易なハードウェアで高速な中継性能を得るため、フレームの
設計においてアドレス部を高々2byte とした。2byte のアドレスを処理するためのテー
ブルのエントリ数は、216 であり、汎用の 64K ワード Static RAM (SRAM) を、そのまま
アドレス検索テーブルの連想メモリとして利用できる。検索は、どのようなアドレスに
対しても 1 回で終了し、検索速度は一律に十数ナノ秒である。また、実装を行う場合の
回路が簡単となるために、スイッチに内蔵する MAPOS のインタフェースカードのサイズ
を小さくできるという利点もある。2byte という短かいアドレス長は以下の理由によっ
て MAPOS を利用する場合の制約とはならない。
(1) ブロードキャストやマルチキャストトラフィックを抑え、健全なネットワークを
運用するためには、1 セグメントに 216 ものホストを接続することはあり得ない。こ
のため、高々2byte でもアドレス長は十分である。
また、以下の利点も得られる。
(2)アドレスを従来の HDLC フレーム内に収めることができる。このため、MAPOS のフ
レームに、従来の POS の PPP が使用する HDLC フレームとの互換性を持たせることが
できる。
3.5 VRPB ブローキャスト/
ブローキャスト/マルチキャスト転送アルゴリズム
MAPOS では、階層的アドレスを採用し、ルーティングによって経路制御を行う。ルー
ティングに関しては第 4 章で詳細に説明する。ここでは、ユニキャスト転送の概要とマ
ルチキャストおよびブロードキャストの経路制御アルゴリズムについて説明する。
まず、アドレスについて用語の定義を行う。フレームには転送先のアドレスが入って
いる。MAPOS スイッチはこれを元に経路テーブルを検索して、次に渡すべきスイッチへ
接続されているポート番号を知る。フレーム内のアドレスと経路テーブル内のアドレス
を明確に区別するため、本論文では、前者を転送先アドレス、後者を終点アドレスと呼
ぶ。また、同様に、フレームの転送元エンドノードのアドレスを転送元アドレスと呼ぶ
のに対し、経路テーブル内に登録される転送元のアドレスを始点アドレスと呼ぶ。
51
ユニキャストのルーティングでは、MAPOS スイッチ間で経路テーブルを交換してベス
トパスを計算する。ベストパスとは、終点アドレスまでの距離が最も短いものである。
スイッチを結ぶ各回線は、その距離を示すメトリックを属性として持つ。メトリックが
小さいほど距離が近いと解釈する。始点と終点間のパス上にあるすべての回線メトリッ
クを加算したものを総メトリックと呼ぶが、この最も小さいものがベストパスである。
特定のエンドノードの転送先アドレスが指定されたユニキャストフレームは、ベストパ
スに沿ってプレデセサ(predecessor)からサクセサ(successor)へと中継され、最終的に
目的のアドレスを持つエンドノードへ転送される。サクセサとは、あるスイッチから見
て終点アドレスへつながる次のスイッチのことである。プレデセサとは、その逆に、自
スイッチをサクセサとするスイッチのことである。図 3.7 には、スイッチ S1 から見た
サクセサとプレデセサの関係を示す。
ところで、ルーティングを行う場合、マルチキャストやブロードキャストの経路制御
にあたっては、Reverse Path Broadcast (RPB) [71][72][73]が使用される。RPB では、
ユニキャストの逆の経路でマルチキャストやブロードキャストのフレームを最短距離
predecessor
successor
S1
predecessor
destination
（終点）
図3.7 S1 のsuccessorとpredecessor
ルート (終点アドレス)
ユニキャストの場合
ルート (始点アドレス)
ブロード/マルチキャストの場合
図3.8 スパニングツリーとRPB
52
で転送する。例えば、図 3.8 左側のユニキャストのスパニングツリーを想定すると、マ
ルチキャストやブロードキャストは、その右に示すように、その逆に辿って転送される。
ユニキャストのスパニングツリーは終点アドレスごとに作成される。一方、マルチキ
ャスト / ブロードキャストでは、RPB を実現するため、各スイッチでユニキャストの
経路制御情報をもとにブロードキャスト/マルチキャストの始点アドレスごとに経路テ
ーブルを用意する。その概要を以下に示す。
(1) 各スイッチでは、あるアドレスに関して隣接するスイッチのどれかをサクセサと
して選択した場合、経路情報の交換の際に、その旨をサクセサのスイッチに対して通
知する。サクセサとは、転送先のアドレスへの経路上にある隣接したスイッチのこと
である。
(2) サクセサとして選択されたスイッチでは、それを通知してきたスイッチ(プレデ
セサ)、および、それがどのアドレスに関するプレデセサであるのかを記録する。こ
れが、ユニキャストとは逆方向の中継を行うための経路テーブルとなる。プレデセサ
は一つとは限らない。複数のスイッチからサクセサとして指定された場合には、プレ
デセサも複数となる。
(3) スイッチはブロードキャストやマルチキャストを中継する際に、その中の転送元
アドレスをチェックし、それに対応する全てのサクセサを経路テーブルから検索する。
そして、それらにフレームを転送する。
ところが、MAPOS では HDLC フレームを使用しているために、フレーム中に転送元ア
ドレスが存在しない。そこで、以下のアルゴリズムによって、この問題を解決する。
(1) ユニキャストの経路テーブル中で数値として最も小さいアドレスを、すべてのブ
ロードキャストやマルチキャストパケットの転送元アドレスと仮定する。そのアドレ
スを持つスイッチを Virtual Source Switch (VSS)[59][70]と呼ぶ。
(2) ブロードキャストやマルチキャストパケットを受信した際には、VSR に対応した
ブロードキャスト/マルチキャストの経路テーブルエントリにあるプレデセサとサク
セサのすべてに対して当該パケットを転送する。但し、そのパケットを受信したポー
ト側へは転送しない。
(3) ユニキャストの経路テーブルが変動した場合には、テーブル中で最も小さいアド
レスを新たな VSR とする。
53
(4) 経路テーブルが変動した場合、変動が収束しないうちにマルチキャストやブロー
ドキャストパケットを転送すると、ループが発生する可能性もある。ユニキャストと
異なり、ブロードキャストやマルチキャストはすべてのエンドノードが受信するため
に、影響が大きい。そこで、テーブルの変動後、経路変動が収まるまで、暫くブロー
ドキャストやマルチキャストの中継を停止する。
RPB と異なり、以上の VRPB アルゴリズムはネットワーク全体で単一のスパニングツ
リーを使用することになる。このため、どの転送元アドレスからのブロードキャストや
マルチキャストでも最短距離で転送できるわけではない。しかし、少なくともループの
ない経路が保証され、ブロードキャストおよびマルチキャストの転送が可能となる。
3.6 評価
この節では、MAPOS の機能の検証および評価について述べる。まず、機能検証および
評価のため実装したスイッチ COREswitch およびホストインタフェースについて説明す
る。
3.6.1 COREswitch のアーキテクチャと動作
図 3.9 に COREswitch[64][65][66]の構成を、図 3.10 に外観を示す。COREswitch は、ク
ロスバ方式のスイッチであり、87.04Gbps の総容量を持つ。Circuit InterFace (CIF)
はホストや他のスイッチへ接続するインタフェースで、各インタフェースの最大速度は
XSW
ABT
C-bus
IFP
CIF
CIF
SONET/SDH SONET/SDH
CIF
SONET/SDH
図3.9 COREswitchの構成
54
図3.10 COREswitchの概観
2.4Gbps である。また、InterFace Processor (IFP)はシステム監視/制御用プロセッサ、
Cross Bar Switch (XBS)はクロスバスイッチ、ArBiTer (ABT)は XBT の制御を行うアー
ビタである。すべての CIF は XBS に接続されており、XBT 経由でフレームを中継する。
また、CIF はバス C-bus で接続され、IFP により管理される。
COREswitch での中継は以下のように行われる。
(1) CIF がフレームを受信する。
(2) 各 CIF は経路テーブルのコピーを持つ。受信したフレームの転送先アドレスをキ
ーとしてこのテーブルを検索し、次に渡すべき CIF を決定する。そして、その CIF へ
の接続要求を ABT に出す。
(3) (2)の要求に従って ABT は XSW の接続を行う。
55
(4) (2)の CIF はフレームを相手の CIF に XSW を経由して転送する。これを受け取っ
た CIF はすぐにポートから転送を開始する。なお、(2)の CIF は、転送完了後も XSW
解放要求を ABT に出さない。それが解放されるのは、他の CIF によって転送要求が出
された場合である。このようにして、連続転送に対するアービトレーションの抑制を
行い、転送遅延を小さくし、スイッチング能力を向上させている。
COREswitch の諸元を表 3.2 に示す。
サイズ
バックプレーン総容量
XSW
スロット数
CIF 最大速度
CIF ボードサイズ
光インタフェース
C-bus 速度
CPU
表 3.2 COREswitch の諸元
430 × 386 × 500 mm
87.04 Gbps
17 ×17、1 段、32bit 幅
17
2.4Gbps
233 × 160 mm
シングルモード (1300nm, 1500nm)
マルチモード
最大 40Gbps (64bit 幅)
Intel 960HD 33/66Mhz
3.6.2 ホストインタフェースのアーキテクチャと動作
図 3.11 に PCI バスに接続して使用する MAPOS ホストインタフェースカード[67]の構
成を示す。また、図 3.12 に 2.4Gbps インタフェースカードの外観を示す。
E/O
変換部
光ファイバ
シリアル/
パラレル
変換部
SONET/
HDLC
SDH
フレーマ部
フレーマ部
FIFO
メモリ
FIFO
メモリ
SONET/
HDLC
SDH
フレーマ部
フレーマ部
PCI-64/66 MHz バス
図 3.11 ホストインタフェースカードの構成
56
図 3.12 MAPOS ホストインタフェースカードの概観
MAPOS ホストインタフェースは、SONET/SDH の処理を行う SONET/SDH フレーマ、HDLC
の処理を行う HDLC フレーマ、そして、受信バッファから構成されている。表 3.3 に開
発したインタフェースカードの種類を示す。これらのカード を一般のシステムで使用
できるようにするための FreeBSD、Linux、Windows、Solaris 等の OS 用ネットワークド
ライバソフトウェアも開発した。
表 3.3 MAPOS インタフェースカードの種類
速度
バス
OC-48c
PCI 64bit / 66Mhz
OC-12c/OC-3c
PCI 64 bit / 66Mhz
OC-12c
S-bus
OC-3c
S-bus
3.6.3 中継処理における経路テーブル検索時間の評価
中 継 処 理 に お け る 経路 テ ー ブ ル 検 索 時 間を 評 価 す る た め 、 MAPOS を 実 装 し た
COREswitch において平均のスイッチング時間を観測した。極めて短いスイッチ時間を
57
ABT
XBT要求/ 許可
XBT要求/ 許可
CIF
OC-12c/48c
XBT
フレーム
CIF
OC-12c/48c
フレーム
図3.13 フレームの流れ
要求する 64byte 長フレームを中継し、インタフェース速度の違いを見るために 2.4Gbps
の場合と 622Mbps の場合を測定した。この測定条件は以下の通りである。
(1) 2 枚の同一速度のインタフェース(2.4Gbps および 622Mbps)を使用して測定した。
(2) クロスバスイッチの競合はない。
(3) 64byte フレームの先頭が入力を開始した時点からフレームの先頭が回線から出
力されるまでの時間をロジックアナライザによって実測した。
フレームのフローを図 3.13 に、測定結果を表 3.4 に示す。
表 3.4 測定結果
項目
2.4Gbps インタフェース
間の平均遅延 (μs)
SONET オーバヘッド処理
0.3
HDLC 受信部遅延
0.3
受信フレームバッファリン 0.2
グ
受信 FIFO 遅延
0.3
経路検索、スイッチ設定
0.2
クロスバスイッチ転送遅延
0.025
送信 FIFO 遅延
0.7
HDLC 送信部遅延
0.2
合計
2.2
622Mbps インタフェース
間の平均遅延(μs)
4.9
0.3
0.8
0.3
0.2
0.025
0.7
0.4
7.6
表 3.4 から、経路検索とスイッチ設定に要する時間は、インタフェースの速度によら
ず、0.2 マイクロ秒、即ち、200 ナノ秒で完了していることがわかる。これを詳細に測
定したところ、アドレスの検索は制御部の 40Mhz クロックの 3 クロック分、即ち、75
58
ナノ秒を要していた。経路探索の速度はインタフェースの速度によらず一定である。こ
の探索時間は、2.4Gbps の場合には、中継処理全体のわずか 3%である。また、622Mbps
の場合には、全体の処理の 1%である。これらのことから、経路テーブルが SRAM で実装
できる 2byte 長アドレスがスイッチの経路決定機構の遅延抑制に有効であることがわ
かる。
3.6.4 ベンチマークプログラム netperf による長大 MTU の効果
MTU サイズとスループットの関係を調べるため、COREswitch を介して接続した 2 つの
PC 間でネットワークパフォーマンス測定用プログラム netperf[74]を用いて測定した。
ここでは、その結果を示し長大 MTU の効果を検証する。
(1) 評価システムの構成と諸元
PC に内蔵した MAPOS インタフェースの速度は 2.4Gbps (OC-48c)である。その接続
形態を図 3.14 に、使用した PC の諸元を表 3.5 に示す。測定用プログラム netperf は、
送信側と受信側の両方の PC で動作させる。送信側ではメモリを読み出して、TCP ま
たは UDP のデータを転送する。受信側では、ヘッダのチェックはするものの、受信し
たデータは捨てる。即ち、netperf はメモリ間の転送を行なって、そのスループット
や 1 秒当りのパケット処理率を測定する。
PC
OC-48C
MAPOS スイッチ
OC-48C
PC
図 3.14 実験システムの接続形態
CPU
メモリ
マザーボード
OS
測定プログラム
表 3.5 使用した PC の諸元
Pentium III-S 1.26GHz
512Mbyte
Supermicro P3TDE
Linux 2.4.14
netperf 2.1pl3
59
(2)
UDP における長大 MTU の効果
ここでは、MTU を MAPOS の最大値である 65280byte に設定し、UDP のセグメントサ
イズを変更することによって、MTU を変更した場合と等価な条件にして測定を行った。
この際、一つの UDP セグメントはまとめられることなく、一つの MAPOS フレームで転
送されていることを確認している。測定結果の結果を図 3.15 と図 3.16 に示す。図
3.15 は UDP のセグメントサイズとスループットとの関係を示したもので、図 3.16 は
セグメントサイズと時間当りのパケット処理数との関係を示したものである。
throughput (Mbps)
10000
1000
100
10
1
1
10
100
1000
10000
UDP segment size (byte)
100000
図 3.15 UDP におけるセグメントサイズとスループットの関係
packets per second (pps)
1000000
100000
10000
1000
1
10
100
1000
10000
UDP segment size (byte)
100000
図 3.16 UDP におけるセグメントサイズとパケット処理数の関係
60
メッセージサイズが 512byte 以下の場合、スループットはメッセージサイズにほぼ
比例し、このとき、単位時間当りのパケット処理数(メッセージ処理数)は一定(約
140Kpackets/s)となった。つまり、処理能力はパケットサイズに関係なく、パケット
数で決定された。一方、8Kbyte 以上のメッセージサイズでは、スループットはぼ限
界値(約 2.3Gbit/s)を達成した。また、イーサネットの MTU である 1500byte に相当
するメッセージサイズでは、ヘッダ処理がボトルネックとなってしまい、ワイヤスピ
ードでの転送を行うことができない。MTU が約 9000byte 付近になると、ほぼ十分な
MTU サイズであると判断される。但し、PC の CPU がここで使用したものよりも遅い場
合には、ボトルネックとなる MTU サイズは更に低下すると考えられる。このため、リ
ンクレイヤがより大きな MTU を提供できることがネットワーク性能を有効に利用す
るための要件となる。以上のことから、MAPOS が IP データグラムとの親和性を考慮
し、最大 64Kbyte の長大フレームを提供することの妥当性が示された。
(3) TCP における長大 MTU の効果
図 3.17、図 3.18 に、UDP の場合と同じ条件で測定した TCP のスループットとパケ
ット処理数を示す。ここでは、MTU サイズを 1500、9000、65280byte の 3 種類に設定
して測定を行った。PC のソケットバッファサイズは、十分に大きな値(512Kbyte)と
した。但し、netperf で指定できたパラメータは、TCP セグメントのサイズのため、
それが小さい場合には、それらの複数のセグメントを入れた一つの IP データグラム
が一度に送り出されていることを観測した。このため、メッセージサイズが小さい場
合には、複数の TCP セグメントが 1 度に処理されており、1 フレームに 1 データグラ
ムが入っていた UDP の場合に比較して、その分だけパフォーマンスが向上しているよ
うに結果が読めるので注意が必要である。TCP セグメントが大きい領域では、そのよ
うな影響はない。
これらの測定結果から、以下のことが言える。
(i) メッセージサイズが 64byte 以下の領域では、スループットはメッセージサイ
ズにほぼ比例し、単位時問当りのメッセージ処理数は一定(約 600K メッセージ/ 秒)
となった。つまり、処理能力はメッセージサイズに関係なく、メッセージ数で決定
された。
(ii) 1024byte 以上のメッセージサイズでは、スループットはほぼ飽和状態となっ
た。最大スループットは、1.59Gbps (MTU = 65280byte、メッセージサイズ = 4096byte
のとき)であった。
61
(iii) MTU が 65280byte と 9000byte では、ほぼ同じ性能が得られたが 1500byte
の場合、最大 707Mbps と性能が半分以下に低下した。
以上のことから、MTU が 9000byte 以上必要であり、UDP の測定結果と同じく、長大
MTU がスループット向上に効果があることが示された。
10000
throughput (Mbps)
1000
100
MTU=65276
MTU=9000
MTU=1500
10
1
1
10
100
1000
10000
TCP segment size (byte)
100000
図 3.17 TCP におけるセグメントサイズとスループットの関係
1000000
packets per second
100000
10000
1000
MTU=65276
MTU=9000
MTU=1500
100
10
1
1
10
100
1000
10000
TCP segment size (byte)
100000
図 3.18 TCP におけるセグメントサイズとパケット処理数の関係
62
3.6.5 実アプリケーションによる長大 MTU と伝送エラーの評価
以上説明してきた COREswitch および MAPOS インタフェースカードを使用して非圧縮
の High-Definition TeleVison (HDTV)システム[68]を構築し、このシステム上で MTU
サイズとエラー率の測定を行った。
(1) システム構成と諸元
システム構成を図 3.19 に示す。HDTV カメラで撮影された映像データは、送信側 PC
で分割され、IP データグラムに入れられて転送される。受信側 PC では、映像データ
を再構成して出力する。非圧縮 HDTV 信号は、74.25MHz サンプリング、10bit 量子化
の輝度信号と、37.125MHz サンプリング、10bit 量子化との 2 種類の色差信号からな
るビットレート 1.5Gbit/s のデイジタル信号である。TV カメラや TV モニタは、業務
用映像機器問で使用される High Definition - Serial Data Interface (HD-SDI)規
格のインタフェースを用いて接続した。このシステム上で、IP データグラムサイズ
を変化させ、非圧縮 HDTV 転送を行ったときの IP データグラムの欠損率、および映像
フレームの欠損率を測定した。トランスポートのプロトコルとして UDP を使用し、欠
損した IP データグラムの再送処理は行っていない。なお、1 映像フレーム分のデー
タ転送の際に、1 データグラム以上の IP データグラム欠損があった場合を映像フレ
ーム欠損としている。そのため、IP データグラム欠損率が同じであっても、データ
グラムサイズが小さい場合には、1 映像フレームに含まれるパケット数が多いことか
ら、映像フレーム欠損率は高くなる。
PC
TVカメラ
HD-SDI
PC
MAPOSｶｰﾄﾞ
OC-48C
MAPOSスイッチ
OC-48C
MAPOSｶｰﾄﾞ
HD-SDI
ｲﾝﾀﾌｪｰｽ
HD-SDI
ｲﾝﾀﾌｪｰｽ
TVモニタ
HD-SDI
図3.19 非圧縮HDTV転送システムの構成
63
データグラムサイズ (byte)
1000
1
10000
100000
0.1
0.01
0.001
欠損率
0.0001
1E-05
1E-06
1E-07
1E-08
IPパケット欠損率
映像フレーム欠損率
1E-09
1E-10
図3.20 IPデータグラムサイズとデータグラム欠損率および映像欠損率の関係
(2) 長大 MTU の効果
図 3.20 に実験結果を示す。本実験により、以下の結果が得られた。
(i) データグラムサイズ 6Kbyte 以下の時、送信側の処理が間に合わず、送信側で
すでに映像落ちが発生した。パケットサイズ 6∼16Kbyte では、受信側でのデータ
グラム欠損が大きく、映像品質が著しく悪い。
(ii) 3.6.4 項で述べた UDP 転送のパフォーマンス測定では、8Kbyte 以上のデータ
グラムサイズで性能が飽和した。一方、HDTV 映像転送プログラムを用いた実験に
おいては、8Kbyte 程度では不十分で、より大きなデータグラムサイズの利用が必
要である。 64Kbyte 長データグラムでは、高品位の転送(1 週問に 1 フレーム以下
の欠損)での転送が達成された。使用するデータグラムサイズが大きくなるに従い、
IP パケット欠損率、映像フレーム廃棄率はともに低下している。
以上から、HDTV 映像転送プログラムでは、送信側での映像データの取り込み・分割、
64
受信側での映像データの再構成・出力の処理が行われているため、受信したデータグ
ラムを単に破棄する netperf での測定結果よりも、より大きなデータグラム、即ち、
大きな MTU が必要となっていることがわかる。 これに対し、MAPOS は最大 64Kbyte
の MTU により、1.5Gbps の映像ストリームを 10-8 から 10-9 の低いエラー率で伝送する
ことを可能とした。
3.6.6 実装の容易さに関する検証
MAPOS は、そのフレーム形式に、POS の PPP が使用する HDLC フレーム形式との互換性
を持たせている。これは、既存の POS 製品のハードウェアを修正することなしに、また、
ソフトウェアの大規模な修正なしに実装できる移植性を持たせるためである。この移植
性を検証するため、業界標準のルータである米国 cisco 社のハイエンドルータ 12000 シ
リーズへの実装を行った。このルータの諸元を表 3.6 に示す。また、そのシリーズの一
つの製品である cisco12010 の内部構造と外形を、それぞれ図 3.21 と図 3.22 に示す。
表 3.6 cisco12000 シリーズ諸元
サイズ (H×W×D)
最大 1842 × 476 × 610 mm
重量
最大 177Kg
バックプレーン容量(クロスバ)
最大 80Gbps
スロット数
15
最大ラインカードスピード
2.4Gbps (OC-48c)
ラインカードサイズ (H×D)
356 × 457mm
CPU
R5000, 200 MHz
SFC
CSC
RP
LC
LC
SONET/SDH SONET/SDH
LC
SFC : Switching Fabric Card
CSC : Cloeck and Scheduler Card
RP : Route Processor
LC : Line Card
SONET/SDH
図 3.21 cisco12000 アーキテクチャ
65
図 3.22 cisco12012 外観(左側が 12012、右が COREswitch)
実装は、既存の cisco ルータの OS である IOS の POS のドライバを MAPOS 用に改造す
ることで行った。IOS の規模は約 100 万ステップと言われており、POS 関連の規模は 5
から 6K ステップである。MAPOS の実装では、ポイントツーポイントの専用線インタフ
ェースを多重アクセスのできるインタフェースに改造する必要がある。このためのアド
レス解決 Address Resolution Protocol (ARP)は、既存のイーサネットの ARP モジュー
ルを流用した。また、IP アドレスと MAPOS アドレスの対応表をクリアするように要求
する unARP、スイッチから自動的に MAPOS アドレスを取得する NSP については、新規に
開発した。これらを表 3.7 に示す。
表 3.7 ソフトウェアモジュールの流用と新規開発
モジュール
ARP (RFC2176)
unARP (RFC2176)
keep-alive (RFC2173)
NSP (RFC2173)
対応
イーサネットのアドレス解決モジュールを流用
新規開発
従来の専用線のモジュールを流用
新規開発
66
OC-12cトラフィック入力
測定装置IXIA
IX400
cisco12008
中継
OC-12cトラフィック出力
図2.23 スループット測定システムの形態
表 3.7 のうち、ARP と keep-alive に関しては既存のモジュールの 9 割がそのまま利
用できた。その結果、全体の規模が 6K ステップの MAPOS のドライバに関し、再利用率
が 50%以上となり、実装するために必要とした工数が 2 人月であった。また、ハードウ
ェアには一切の改造が必要なかった。以上から、MAPOS の特徴の一つである従来の POS
との互換性が開発コストの低減と開発期間の短縮を可能とするという検証ができた。
次に、cisco ルータ上に実装した MAPOS の性能を評価するために、OC-12c インタフェ
ースを塔載した cisco 12008 を IXIA 社の IX400 スループット測定装置と対向させて、
RFC2544 に準拠した方法で測定した。IX400 からは、OC12c のトラフィックを cisco12008
に送り込み、それに中継させたトラフィックを IX400 が受信する。このようにして、
cisco12008 がパケットをドロップしない最大のトラフィックを、PPP、MAPOS それぞれ
について計測した。この測定システムの接続形態を図 3.23 に示す。
まず、パケットロスがない最大フレームレートを測定した結果を図 3.24 に示す。こ
の図から、MAPOS の最大処理可能フレームレートは PPP の場合と変らず、MAPOS が何ら
性能に影響を与えていないことがわかる。
500000
450000
フレームレート
400000
350000
300000
PPP
MAPOS
250000
200000
150000
100000
50000
0
0
200
400
600
800
1000
データグラム長
1200
1400
1600
図 3.24 最大フレームレート
67
120
100
スループット (%)
80
MAPOS
PPP
60
40
20
0
0
200
400
600
800
データグラム長
1000
1200
1400
1600
図 3.25 スループット
次に、回線速度の何%が出ているかを MAPOS、PPP それぞれで測定した。測定条件は同
じである。これを図 3.25 に示す。この結果もスループット計測の結果と同じであり、
MAPOS のスループットは PPP のそれと同じである。以上の結果から、ソフトウェアの改
造だけで MAPOS の実装が可能なだけではなく、PPP と同等の性能が得られることが検証
された。
3.7 むすび
本章では超高速データ通信向きの多重アクセスプロトコル群 MAPOS について説明し
た。MAPOS は、超高速専用線の世界標準である SONET/SDH プロトコル上に HDLC フレー
ムを乗せた極めて簡明なプロトコル群である。その特徴は、(1) プロトコルの簡明さ
(2) 長大フレームによる転送効率の高さ (3) LAN と WAN とのシームレス性、 (4) 速度
および距離のスケーラビリティ (5) POS との互換性による実装の容易さ (6) アドレス
の自動割り当てや動的経路制御によるプラグアンドプレイ (7) 経路収束の速さ (8)特
定のトポロジに制限されない自由なネットワーク構成 等にある。これらにより、ATM
における転送効率の問題、GbE/10GbE における経路収束の遅さの問題や速度のスケーラ
ビリティの問題、POS における多重アクセスができないという問題、速度体系の相違に
よる LAN と WAN との相互接続性の問題等を解決した。
MAPOS の機能検証を行うため、MAPOS プロトコル群を、総容量 87.04Gbps の高速 MAPOS
スイッチ COREswitch および 2.4Gbps の高速ホストインタフェースとして実装した。そ
して、非圧縮 HDTV 伝送システムのアプリケーションにおいて、MAPOS のスループット
とエラー率を測定することによって長大フレームの効果を検証した。その結果、Pentium
68
III 1.26Ghz CPU を使用した汎用の PC 間でも、MAPOS の長大フレームであれば最大
1.5Gbps のストリームを 10-9 から 10-10 程度のエラーレートで転送できるということを明
らかにした。また、POS との互換性による実装の容易さを検証するために、業界標準の
cisco 社ルータへ実装し、ハードウェアに一切の改造を加えることなく、ソフトウェア
の変更だけで MAPOS が稼働することを実証した。この場合、ソフトウェアの半分は既存
のモジュールが流用できた。
なお、本論文で紹介した MAPOS ネットワークシステムは東京都内の 5 つのサイトを最
大 2.4Gbps で結ぶメトロポリタンネットワークとして稼働中である。また、非圧縮 HDTV
転送システムは、約 20km の距離がある MAPOS メトロポリタンネットワーク中の NTT 武
蔵野研究開発センタ(東京都武蔵野市)と電気通信大学 (東京都調布市)間で実験を行な
った。
69
第 4 章 TPV アルゴリズムと MAPOS 経路制御プロトコルへの
応用
概要
本章では、Border Gateway Protocol (BGP) に代表されるパスベクタ経路制御アルゴリ
ズムの経路収束の不安定性 (route bouncing) に対し、経路情報発生時間を属性として
付加することによって問題の解決を図った時相パスベクタ経路制御アルゴリズム
Temporal Path Vector (TPV) について述べる。TPV では、経路発生時間として、送信
時間ではなく受信時間を使用する。また、実時間ではなく、リンクの変化ごとに進む仮
想時間を使用する。そして、経路情報の受信の際には時間を比較し、新しい情報を古い
情報による上書きから保護し、古い情報の消滅を加速する。
ここでは、机上でのシミュレーションを行い、同一シナリオの下で TPV の経路収束性
を従来のパスベクトルアルゴリズムと比較する。そして、従来の方式で収束に 48 ステ
ップを要した場合に、TPV ではわずか 4 ステップで収束することを示す。また、TPV ア
ル ゴ リ ズム を MAPOS の経 路 制 御 プ ロト コ ル へ 適 用 し た Extended Switch-Switch
Protocol (ESSP)について、そのプロトコル構成と実装アーキテクチャを説明する。
70
4.1 はじめに
本章では、Border Gateway Protocol (BGP) に代表されるパスベクタ経路制御アルゴ
リズムの経路収束の不安定性 (route bouncing) に対し、経路情報発生時間を属性とし
て付加することによって問題の解決を図った時相パスベクタ経路制御アルゴリズム
Temporal Path Vector (TPV) について述べる。
route bouncing の原因は、経路計算の過渡期に、ネットワーク内に混在する新旧の
経路情報の区別ができないことに起因する。これに対し、TPV は、パスの属性に情報発
生時間を付加することによって古い情報による新しい情報の上書きを防止し、更に、古
い情報源（キャッシュ）を消去する。しかし、分散したノード（ここではスイッチやル
ータ等を総称する）が実時間を合せるのは困難である。また、新旧の判別をするための
時間の分解能(精度)をどの程度にするかが問題となる。更に、経路送信側ノードで情報
発生時間を付加していたのでは、リンクの切断が発生した場合にそれが届かないという
問題が発生する。そこで、TPV では、次の方法によって問題を解決する。即ち、情報発
生時間としてリンクごとのローカルな時間を使用するが、実時間ではなく、リンクのイ
ベントごとに進む仮想時間を使用する。また、送信側の時間を使用するとリンクダウン
の場合にその情報が伝わらないため、受信側ノードにおける仮想時間を使用する。
ここでは、机上でのシミュレーションを行い、同一シナリオの下で TPV の経路収束性
を従来のパスベクトルアルゴリズムと比較する。その結果、従来の方式で収束に 48 ス
テップを要した場合に、TPV ではわずか 4 ステップで収束することを示す。また、TPV
アルゴリズムを MAPOS の経路制御プロトコルへ適用した Extended Switch-Switch
Protocol (ESSP)について、そのプロトコル構成と実装アーキテクチャを説明する。そ
して、指定サクセサの概念を使用すればユニキャストで並列パスを使用する場合でもマ
ルチキャスト/ブロードキャストのスパニングツリーを作成できること、ツリー配下に
あるノードが属す GID のリストを指定サクセサに渡すことで無駄なマルチキャストの
転送を抑制できること、MAPOS 固有の高速中継用テーブル FT を利用して一時的なルー
プを防ぐための転送抑制機構をオーバヘッドなしに作成できることを示す。
4.2 従来の問題点と TPV でのアプローチ
本節では、従来の代表的な経路制御プロトコルの問題点を説明し、TPV によるアプロ
ーチを説明する。
4.2.1
4.2.1 代表的な 2 つのタイプのプロトコル
現在、広く使用されている経路制御プロトコルには、
71
(1)Distance Vector (DV) 型プロトコル[75]
(2)Link State (LS) 型プロトコル[75]
などがある。
DV 型プロトコルは、隣接するノード同士が、すべてのノードまでの最短距離（メト
リック）を示す経路テーブル(Routing Table = RT) を定期的に交換する。各ノードは、
受信した情報に基づいて最短経路を計算し、今度はそれを隣接するすべてのノードにブ
ロードキャストする。この繰り返しによって、各ノードは最短経路からなる経路テーブ
ルを得ることができる。その例として、最短経路計算に分散ベルマンフォードアルゴリ
ズム(Bellman-Ford)を使用した Routing Information Protocol (RIP) [20] [21]や cisco
社の Interior Gateway Routing Protocol (IGRP) [76]などがある。
DV 型には実装が簡単であるという利点があるが、定期的な経路情報のブロードキャ
ストによるネットワーク帯域の消費、count-to-infinity 等の bouncing effect [75]
によるループの発生、収束遅延 (slow convergence) 等の問題がある。これらを緩和す
るため、ホールドダウンタイマー、triggered update, split-horizon with poison
reverse [75]による対処方法が用いられてきた。しかし、ホールドダウンタイマーの使
用は、障害の発生から新経路の選択までに長時間を要するという問題を生じる。
一方、LS 型プロトコルは、各ノードがノード間のリンクの情報をネットワーク全体
に中継して行き渡らせる (flooding)。そして、各ノードは独自にネットワーク全体の
トポロジを認識し、最短経路を計算する。この例として、最短経路計算にダイクストラ
(Dijkstra)のアルゴリズム [12]を使用した Open Shortest Path First (OSPF)プロト
コル [22] がある。LS 型は、収束時間が早いという利点を持つが、すべてのノードが
トポロジデータベースを持ち全体の経路を計算しなければならないという処理のオー
バヘッドや、設定や管理が複雑であるという問題を持つ。
4.2.2
4.2.2 Path Vector 型プロトコルとその問題点
これまで、特に DV 型の問題に対するいくつかの解決策が研究されてきた。例えば、
Path Vector (PV) 型プロトコルは、実装が簡単でループの検出を的確に行ってそれを
防止できる。これは、BGP の設計にあたり開発された。
PV 型プロトコルでは、DV 型プロトコルのメトリックである距離の代わりに、経路情
報が運ばれてきたパス（その経路情報を中継した一連のノード番号の列）を使用する。
各ノードでは、隣接するノードから受信したパスの中からベストパスを選択するが、そ
の際に、パスの中に自分のノード番号が入っていないかどうかをチェックする。入って
いれば、ループが発生した無効な経路情報として、その経路情報を破棄する。そして、
72
有効な経路情報の中からベストパスを選定する。ベストパスを隣接するノードへ経路情
報としてブロードキャストする際には、そのパスに自分のノード番号を追加して渡す。
このようにして、PV 型プロトコルでは、ループの発生を的確に把握する。
しかし、PV 型でも、経路情報の更新は DV 型と同じく各ノードで非同期に行われる。
そして、古い情報による新しい情報のオーバーライトが発生する。このため、収束中に
多くの更新情報が生成されたり、route bouncing による収束の遅延が発生してしまう
[77]。 例えば、図 4.1 のような簡単なリング型のネットワークを想定する。[77] こ
の図において route bouncing がどのように発生するかを説明する。ここでは、ノード
N4 への経路を考える。定常状態においてリンク N4-N1 に障害が発生してダウンしたと想
定する。ダウン前の各ノードの N4 への経路テーブルは以下のようになっている。
(1)ノード N1
保持しているパス: (N4)のみ
選択されているベストパス: (N4)
(2)ノード N2
保持しているパス: (N1, N4), (N3, N1, N4)
選択されているベストパス: (N1, N4)
(3)ノード N3
保持しているパス: (N1, N4), (N2, N1, N4)
選択されているベストパス: (N1, N4)
①
N1
①
障害
N4
N2
N3
②
③
図4.1 経路バウンシング
73
なお、括弧は一つのパスを表し、括弧の中はパスの経路を表している。一番左が始点ノ
ードであり、一番右が終点ノードである。
N4-N1 のリンクがダウンすると N1 は、N2 と N3 へ N4- N1 が切れたことを示す withdrawal
メッセージを送る(①)。（ここでは、BGP と同じプロトコルを想定する。BGP では、
withdrawal は、経路が到達不能になった場合に送られる。）しかし、N3 へのメッセージ
のほうが先に N3 に到着したと仮定する。N3 は、パス(N1,N4)を無効し、残りのパス(N2, N1,
N4)を選択する。この結果は、N2 へ新たな経路を選択したことを示す update メッセージ
として通知される(②)。このメッセージによって、N2 は以前のパス(N3, N1, N4)の代わ
りの新たなパス(N2, N1, N4)を検査するが、このパスの中に N2 が入っているので無効と
する。この結果、N2 の持つパスは、(N1, N4)のみとなる。
次に、N2 は N1 からの withdrawal メッセージを受け取るので、(N1, N4)を無効とし、
その withdrawal メッセージを N3 に伝える(③)。これにより、(N2, N1, N4)を有効として
選択していた N3 は、やっとそれを無効なパスとして認識する。
以上のように、N4 が直ちに到達不能となるのではなく、一旦、無効なパスを採用した後
に、到達不能となるという収束の遅れや不安定な収束性 Route Bouncing が発生する場
合がある。参考文献[77]には、リング状ネットワークにおいて、収束までに 48 ステッ
プを要する例が示されている。
4.2.3 TPV のアプローチ
4.2.2 項で述べた route bouncing 問題が発生する原因は、古い経路情報と新しい経
路情報とが識別できず、古い情報によって新しい情報が更新されてしまうからである。
例えば、障害位置が特定できないために、障害の発生したリンクを通るパスを有効なも
のとして受理してしまう。また、古い情報源がすぐには消されることなく残ってしまう
という問題もある。
これらの問題に対して、TPV では、以下のアプローチを行う。
(1)パス属性に情報発生時間を導入し、情報の新しさを判別できるようにする。
(2)時間として、仮想時間 Virtual Time(VT)を使用する。これは、リンクのアップ/
ダウン、メトリックの変化などのイベントが発生するごとに 1 だけ進むポート(イン
タフェース)ごとの時間である。
(3)経路を送信したノード(リンク)の仮想時間ではなく、それを受信したノード(リン
ク)の仮想時間を採用する。これによりリンクダウン時も仮想時間がわからなくなる
ことはない。
74
VT は、各リンクのメトリックと同様に、パス属性として経路情報に入れられる。こ
れを受信したノードでは、以下のように処理を行う。
(a) 古い情報による更新の防止
経路情報を受け取るごとに VT をチェックし、すでに保持している情報よりも古い
要素が含まれていれば、情報は受け取るもののベストパス計算の対象に含めない。
また、すでに保持している情報の要素に、受信した経路情報の要素よりも古いものが
あれば、それを無効なものとしてベストパスの計算対象から外す。
(b) 古い情報源の刈り取り
(a)の場合には、その情報を送ってきたノードに対して無効であることを通知し、
破棄するようにアドバイスを行う。
VT は、ベストパスの通知(update)だけでなく、無効情報の通知(withdrawal)の場合
にも使われる。これにより、パスの切り替えの原因、場所、時間が的確に把握でき、そ
のパス要素を含む古い経路情報を排除できるので route bouncing が防止でき、迅速な
経路収束特性が得られる。
4.3
4.3 TPV の概要
この章では、TPV のアルゴリズムとプロトコルの概要を示す。
4.3.1 TPV の特徴
TPV によるアプローチには以下の特徴がある。
(1) 情報発生時間の考慮
TPV はパスベクタをベースとしながら、パス属性として各ノードにおける情報の発生
時間を含める。これによって情報の新しさを判断することができる。そして、古い情
報による新しい情報の更新を防止し、更に、古い情報（キャッシュ）を無効とする。
(2) 仮想時間の使用
情報発生時間として、各ノードのポートにローカルな仮想時間 VT を使用する。これ
は、メトリックの増減やリンクのアップ/ダウンなどのイベントごとにインクリメン
トされる。ここにリアルタイムを使用した場合、複数のイベントが同じ時間に記録さ
75
れないよう、分解能が問題となる。しかし、仮想時間の場合には、イベントごとに必
ず時間が異なることが保証されている。
(3) 受信側における仮想時間の記録
仮想時間を経路情報の送信側ポートでカウントする場合、そのリンクがダウンした時
に、その仮想時間を含む経路情報を受信側に伝えられないという問題が発生する。そ
こで、TPV では受信側ポートにおける仮想時間を使用して経路情報に刻印する。
(4) 経路キャッシュ
隣接するノードからの経路情報の受信、メトリックの減少増大やリンクのアップダウ
ン等のイベントが発生した場合には、その時点で受信した経路情報も含め、それまで
の経路情報の中からベストパスを選択する。即ち、経路情報はキャッシュに保持し、
直ちに交代経路を選択できるようする。なお、古い情報やループを含む経路情報は、
ベストパスの計算対象から除外する。
(5) VT のガーベージコレクション
VT の利用によってループの発生は抑制されるものの、パス情報への VT の付加によっ
て、パス情報を受信するごとに、その中のすべてのパス要素を比較するという CPU オ
ーバヘッドが発生する。また、VT の付加によってメッセージ長や最新の VT を記録し
ておく Virtual Time Table (VTT)のテーブルサイズも増大する。そこで、ネットワ
ークが安定した後には、これらを回収する。回収の対象は、メッセージ中の VT と VTT
のエントリである。回収後は、VT の比較が行われなくなるために、CPU のオーバヘッ
ドもなくなり、VT のためのメモリも減少する。即ち、CPU やメモリのオーバヘッドが
増大するのは、過渡期だけであり、安定期にはオーバヘッドが抑制される。
以下では、仮想時間付きのメッセージがどのように処理されるのかについて説明する。
4.3.2 想定するネットワーク
TPV は、リングを含む任意のトポロジを構成するメッシュネットワークで利用できる。
ネットワークは、パケットを交換するノード（ルータやスイッチ等）とノード間を接続
するリンク(ネットワークセグメント)とから構成される。これを図 4.2 に示す。
図 4.2 において、Nx はノード番号、Py はポート番号、NSz はリンクを示す。ここでは、
リンクとして、イーサネットのようにマルチアクセスのできるネットワークセグメント
を想定する。各リンク NSz のメトリックは、双方向で同じメトリックを持つものとし、
Mz と記述する。
76
NS4
N1
P1
A 11
NS1
M1
NS5
P3
A 52
P2
A 31
NS3
M3
P1
A 12
N2
P3
A 41
NS2 M 2
P2
A 22
P1
A 23
P2
A 33
N3
P3
NS6
A 63
図4.2 ネットワークの例
以降の説明では、アドレス体系として、IP プロトコルと同じく、ネットワークアド
レス部とホストアドレス部から構成されるものを想定する[50]。ネットワークアドレス
部は、それぞれのネットワークセグメント NSm を全ネットワーク内で一意に識別するも
のである。ここでは、これを NAm と記述する。ホストアドレス部は、ネットワークセグ
メント内で一意にポートを識別するためのもので、Hn と記述する。即ち、各ポートのア
ドレス Amn は、NAm と Hn から構成される。
各ノードは、RT に変化があった時のみ、すべての隣接するノードに新ベストパスを
update メッセージで通知する。また、それまで別の旧ベストパスがあった場合には、
旧ベストパスの交代原因（原因となったノード番号、メトリック、VT)も同じ update メ
ッセージで通知する。ノード間におけるメッセージ通信には、誤りのない転送を保証す
るトランスポートプロトコルを使用する。どのようなトランスポートプロトコルでも使
用できる。例えば、TPV のアルゴリズムを BGP へ応用する場合には、BGP が使用してい
る TCP [10] をそのまま使用すれば良い。リンク層、ネットワーク層のプロトコルに関
しても任意のプロトコルが使用できる。これらのプロトコル階層を図 4.3 に示す。ここ
で、Hello は、定期的ブードキャストによって隣接するノードを自動的に発見するプロ
トコルであり、Auth は、発見したノードとの隣接関係を確立する時に使用する認証の
プロトコルである。各ノードはメッセージ交換の前に、隣接関係の確立を完了していな
ければならない。
77
TPVメッセージ
Auth
トランスポート層 - 任意
ネットワーク層 - 任意
Hello
リンク層 - 任意
図4.3 想定するTPVのプロトコルスタック
4.3.3 仮想時間
ノードは、パス情報を受信した時間とその時のリンクのメトリックとを、そのパス情
報内に記録しておく。その時間として、ポートごとの仮想時間を使う。これは、メトリ
ックの増減やリンクのアップダウンなどのイベントが発生するごとにインクリメント
される一種の順序番号である。これを図 4.4 に示す。パスの選択を行う場合、そのパス
自体に各ノードにおける受信時間が含まれているので、情報の発生した時間の関係を考
慮にいれた選択が可能となる。注意しなければならないのは、仮想時間は受信側のポー
トの仮想時間であり、送信側ポートの仮想時間ではないことである。
なお、情報の時間を比較する際には、パス情報を送り出した側のポートの番号とパス
情報を受信した側のポート番号のペアが同じものについて VT を比較する。ポイントツ
ーポイント接続の場合には、送信側と受信側にポートのペアが一意に決定されるので、
メ ト リ ック
l in k do wn
l in k up
メ ト リ ック 増加
メ ト リ ック 減少
時間
仮想時間
実時間
1
1
2
2
3
図 4 .4
4
3
4
5
6
7
8
仮 想 時間
78
どちらかのポートを比較するだけでも良い。
4.3.4 パス情報の表現形式
本論文では、ノード間で交換されるパス情報を以下のリスト形式で表現する。
（終点アドレス
(ノード番号 (受信したポート番号 受信相手アドレス) (送信したポート番号 送
信相手アドレス）受信時の VT 受信時のメトリック）
(ノード番号 (受信したポート番号 受信相手アドレス) (送信したポート番号 送
信相手アドレス）受信時の VT 受信時のメトリック）
……..)
リストの最初の要素は終点アドレス3である。次に、当該情報を受信し中継したノード
の情報が新しい順番に続く。これは 5 つの要素から構成される。最初の要素は、ノード
番号である。2 番目は、受信したポート番号、受信した時の相手ノードのアドレスから
構成されるリストが続く。3 番目は、このパス情報を送信したポート番号、送信相手の
アドレスから構成されるリストである。4 番目は、このパス情報を受信した時の仮想時
間 VT である。そして最後がこのパス情報を受信した時のポートのメトリック(ディスタ
ンスとも呼ばれる)である。
このパス情報を最初に生成したノード(この終点アドレスを持つネットワークセグメ
ントに直結されたノード)では、終点アドレスと最初のノードの情報を入れて、隣接す
るすべてのノードへパス情報を送る。例えば、図 4.2 の N2 におけるネットワークアド
レス NA2 に関するパス情報を考える。N2 は、N1 と N3 に対し、それぞれ
(NA2 (N2 ( - - ) (P1 A11) - 0 ) ) --
①
(NA2 (N2 ( - - ) (P2 A23) - 0 ) ) --
②
というパス情報を送る。N2 はパス情報のソースなので、受信したポート番号、受信相手
アドレス(next hop)、および、受信時の VT の部分は don't care ( - )である。また、
メトリックは、直接接続されているという意味の 0 である。
このパス情報には、これを受信したノードによって情報が追加されてゆく。例えば、
①の経路が N1 でベストパスとして選択され、それが N3 へ通知される場合には、
3
終点アドレスは転送先アドレスと同じ意味である。ここでは、経路情報中のアドレスとフ
レーム中のアドレスを区別するために、経路情報の場合には終点アドレス、フレーム中の
それを指す場合には転送先アドレスと呼ぶ。
79
(NA2
(N1 (P1 A12) (P2 A33) VTP1 M1)
(N2 ( - - ) (P1 A11) - 0 ) )
が送られる。ここで、VTP1 は、N1 が①を P1 で受信した時の仮想時間である。
なお、ここで用いるパス情報の表現にはいくつか冗長な部分がある。まず、受信した
ポート番号、送信したポート番号は、それぞれ、受信相手アドレスと送信相手アドレス
からポートが割り出せるので省略可能である。また、ポイントツーポイント接続の場合、
通信相手のアドレスはリンクごとに一意に決定されるので、送信したポート番号や送信
相手アドレスのフィールドも省略可能である。
4.3.5 メッセージ処理の概要
この項では、TPV におけるメッセージ処理の概要について説明する。各ノードは、経
路情報を保持するために以下の 4 つのテーブルを持つ。
(1) 隣接するノードに関する情報を保持する Neighbor Table (NT)
NT は隣接関係にあるノードごとに用意され、それぞれのノードに関する情報を保
持する。これは、当該ノードとの隣接関係の確立によって生成され、隣接関係の喪失
によって削除される。
そのスロットには、リンク層、ネットワーク層、トランスポート層に関するすべて
の情報が置かれる。リンク層に関するものの例として、up/down 等のリンク層の状態
を示すフラグ、隣接するノードまでのリンクのメトリック等がある。また、ネットワ
ーク層に関するものの例として、自ノードアドレスと隣接関係にある相手ノードのア
ドレス等がある。トランスポート層に関するものとして、隣接するノードの TPV の処
理プロセスへ接続されているバーチャルサーキット、open / established / closed
等のバーチャルサーキットの状態[10]等がある。また、受信した経路情報につけるタ
イムスタンプ(仮想時間)用の時計を保持するのも、NT である。これは、リンクのア
ップダウン、コネクション(バーチャルサーキット)のアップダウン、メトリックの変
化等が発生する度にインクリメントされる。
(2) 隣接するノードからの経路情報を保持する Topology Table (TT)
TT は、ノード内に一つ存在し、隣接したノードから通知された最新の経路情報が
80
すべて入れられている。TT テーブルのエントリは終点アドレスごとになっており、
各エントリ内は複数のサブエントリから構成される。終点アドレスが同一でも、異な
るノードからは異なるパスが通知される。これらは、それぞれの終点アドレスに対応
したエントリ内のサブエントリとして保持される。これを図 4.5 に示す。
各エントリは、経路の終点アドレス、ベストパスとして選択されているサブエント
リの番号を保持する。また、サブエントリ部分には、このエントリの終点アドレスに
関するすべての受信したパス情報が入れられる。サブエントリには、当該サブエント
リ中のパス情報の有効性を示すフラグ、このパス情報送ってきたノード、即ち、サク
セサのアドレス、それを受信したポート番号、受信したパス情報に受信時のリンクの
メトリックと仮想時間を加えたものが入る。
たとえば、図 4.2 のノード N1 の TT には終点 NA1, NA2, NA3 それぞれに対するエント
リがある。そして、各エントリ内にそれぞれ２つのサブエントリを持つ。NA2 に対し
ては、パス(N2)と(N3)のサブエントリであり、NA3 に対してはパス(N1)と(N1 N2 N3)の
サブエントリである
以下では、ノード N1 での終点 NA2 へのパスについて具体的に説明する。ここで VTmn
は、ノード Nm のポート Pn におけるある時間の VT とする。N1 で受信した NA2 に関す
るパス情報は N2 からのものが、以下のようになる。
(NA2 (N2 ( - - ) (P1 A11) - 0 ) )
一方、N1 で受信した NA2 に関する N3 からのパス情報は以下のようになる。
(NA2 (N3 ( - - ) (P2 A12) - 0 ) )
これらには当該ノードアドレス、ポート番号、受信時の VT、受信時のリンクのメト
リックが付加されて TT に保存される。従って、その際の各経路情報は以下のように
終点アドレスエントリ
サブエントリ
サブエントリ
終点アドレスエントリ
サブエントリ
サブエントリ
サブエントリ
図 4.5 TT の構造
81
なり、これらが TT の NA2 のエントリに入れられるサブエントリとなる。
(NA2
(N1 (P1 A12) ( - - ) VTP1 M1)
(N2 ( - - ) (P1 A11) - 0 ) )
(NA2
(N1 (P2 A33) (- -) VTP2 M3)
(N3 ( - - ) (P2 A12) - 0 ) )
なお、DV 型プロトコルと異なり、ベストパス以外の有効な経路情報も捨てられる
ことなく、TT テーブルにすべて保持される。このため、ベストパスが無効となった
場合、直ちに、次善のパスを選択できるというキャッシュ効果が生まれる。update
メッセージ内のパス情報は隣接したノードベストパスのコピーであるので、すべての
隣接するノードの RT のコピーが TT というキャッシュに入っていることになる。
(3) ベストパスを保持しパケットの中継のたびに参照される Routing Table (RT)
Routing Table (RT)は、ノードがパケットを転送するごとに参照する経路テーブル
である。その各エントリは、終点アドレス、次のノード(サクセサ)のアドレス、この
エントリ作成の元となったパス情報等から構成される。ノードは、パケットの転送先
アドレスを RT で検索し、一致する終点アドレスを探す。一致するものがあれば、そ
のエントリに入っているパケットを送り出すべきポートと渡すべきノードを取り出
し、そこへ送信する。
RT の更新は、そのベストパスが経路のメトリックの変更やリンクの切断により無
効になった時や、隣接するノードから経路情報を受信して TT テーブルが変更された
時に行われる。その場合、TT テーブルからベストパスを選択してその情報で RT を更
新する。その際、TT 内の無効フラグの立っていないパスを候補として次善のパスを
探す。それがあった場合には、直ちにそれを RT のベストパスとして採用する。例え
ば、図 4.2 で、N1 におけるアドレス NA2 への経路がどのように選択されるかを示す。
(2)に示したように、N1 における TT 内のサブエレメントは以下の２つになる。
(NA2
(N1 (P1 A12) ( - - ) VTP1 M1)
(N2 ( - - ) (P1 A11) - 0 ) )
82
(NA2
(N1 (P2 A33) (- -) VTP2 M3)
(N3 ( - - ) (P2 A12) - 0 ) )
ここで M1 < M3 と仮定すると、後者のパスが選択される。そして、RT には、以下の情
報が登録される。
終点アドレス
NA2
サクセサアドレス
A33
パス情報
(NA2
(N1 (P2 A33) (- -) VTP2 M3)
(N3 ( - - ) (P2 A12) - 0 ) )
(4) 最新の VT を保持する VTT (Virtual Time Table)
仮想時間テーブル VTT は、ノード間のリンク（接続されたポートの対）に対する最
新の VT の値を保持するマトリクスである。実際にはネットワーク中のすべてのリン
クに対応するマトリクスが必要となるわけではないので、リンクごとのエントリを動
的に生成/消滅させる VT のリストでも十分である。図 4.2 を例にした場合の VTT の一
例を以下に示す。
((A11 A12) VT12 M1)
(A12 A11) VT11 M1)
(A22 A23) VT23 M2)
(A23 A22) VT22 M2)
(A33 A12) VT12 M3)
(A12 A33) VT33 M3) )
各エントリは、リンクがいずれかのパスに初めて現れた時に生成され、それがいずれ
のパスにも含まれなくなり、その後一定時間が経過した時に消去される。
83
(5) update メッセージの概要
(5-1)メッセージの送信
RT が変更されるたびに、そのベストパスのパス情報は、update メッセージによっ
て隣接するすべてのノードへ通知される。また、あるノードと新たに隣接関係が確立
した時にも、RT の内容がそのノードへ通知される。この update メッセージは、new
エレメントと withdrawal エレメントから構成される。前者は新たなパス情報を通知
するもので、後者は、これまでとは異なるパスへの交替があった場合、旧パスが無効
となった原因、場所（ノード番号）
、そのメトリック、VT を通知するためのものであ
る。従って、新規にあるアドレスへの経路ができた場合には、new エレメントだけが
伝えられる。また、これまでのパスが無効になり、次善のパスもない場合には、後者
のエレメントだけが伝えられる。
update メッセージには、以下のように必要に応じて new や withdrawal、あるいは、
両方のエレメントが入れられる。
(i)新たなベストパスが追加された場合(これまでにベストパスがなかった場合や
パラレルパスが出現した場合)には、new エレメントだけで withdrawal エレメント
は含まれない。
(ii)これまでとは異なるベストパスが選択された場合には、新たなパスに対する
new と無効となった旧パスに対する withdrawal の両方が含まれる。
new エレメントでは、隣接するノードへ新規のベストパスを通知する。パスは、そ
の情報が選択されて中継されてきた一連のノード番号である。また、それぞれのノー
ド番号に対応し、属性として当該情報を受信した時のリンクのメトリックと情報発生
時間 VT が含まれている。
withdrawal エレメントでは、終点アドレス、パス番号を示した上で、これまでの
ベストパスがどのノードのどういうイベントで無効となったのかを示す理由が識別
子の形で入れられる。以下にその例と通知される情報の内容を示す。
(i) metric increased
スイッチ S において仮想時間 VT にメトリックが M に増大した。これにはリンクダ
ウンも含む。
84
(ii) metric decreased
スイッチ S において仮想時間 VT にメトリックが M に減少した。
(iii) better route found
スイッチ S においてより良いパスが見つかった。
(5-2) メッセージの受信
メッセージを受信すると、以下のステップでベストパスの更新を行う。なお、自ノ
ードと隣接するノード間のリンクが up/down したり、そのメトリックが増減した場合
も、隣接するノードから経路情報を受信したものと見なして処理を行う。
(i) TT の更新
メッセージやイベントによって TT を更新する。TT に変更があっても、ベストパ
スが代わるような影響がなければ、そのまま終了する。
メッセージを受信した場合には、まず、withdrawal の対象を TT から削除する。
次に、new エレメントをその終点アドレスに対応する TT エントリのサブエントリ
として登録する。new エレメントで伝えられるパス情報は、いくつかの属性を持つ。
例えば、その情報が選択され、中継されてきた一連のノード番号である。また、そ
れぞれのノード番号に対応し、別の属性としてメトリックと情報発生時間 VT が含
まれている。受信したパス情報で TT を更新する場合には、情報発生時間 VT をチェ
ックし、VTT に保持している最新の VT よりも古い場合には、そのパス情報に無効
のマークをつける。また、パス内に自ノード番号があれば、ループが発生している
ものとして無効のマークをつける。更に、すでに保持しているパス情報で、受け取
った情報よりも古い VT を含むものが TT にあれば、そのパスに対しても無効
(obsolete)を示すマークをつける。その際には VTT も更新する。VTT を更新した場
合には、既存の RT や TT 内のすべてのパスも有効性を再検査し、古い情報がある場
合には、それに無効のフラグをつける。
なお、登録の際には、受信したパス情報に自ノード番号、受信したポート番号、
受信相手アドレス、受信した時の VT およびメトリックを付加しておく。
(ii) ベストパスの計算
対象の終点アドレスに関する TT エントリの中から、最も総メトリックの小さいベ
ストパスを選択する。なお、無効のマークのついている経路は対象から外す。計算
の結果、旧ベストパスと同じものが選択された場合には、そのまま処理を終了する
85
(iii) RT の更新と update による通知
(ii)の計算結果を RT に反映し、それ以前と比較して変化があれば、新ベストパス
を new エレメントとして、RT からなくなった旧ベストパスを withdrawal エレメン
トとして隣接するすべてのノードへ update メッセージで通知する。なお、
withdrawal エレメントの場合には、その原因と変化したパス要素のみを通知する。
以上のステップを図 4.6 に示す。また、経路情報の流れを図 4.7 に示す。
TT更新
ベストパス計算
RT更新
no
RTに変更があるか？
yes
update転送
図4.6 計算ステップ
ポート
ポート
NT
NT
TT
RT
VTT
NT
NT
ポート
ポート
図4.7 経路情報の流れ
86
(6) リンクのアップ/ダウンイベント
リンクのアップ、ダウン等のイベントは、基本的に update を受信した時と同じ処
理を行う。まず、リンクダウンが発生した場合には、問題の発生したポート経由で受
信していた TT サブエントリのパス情報をすべて無効とする。無効とされたパス情報
がベストパスとして RT に採用されていた場合には、update メッセージが隣接するす
べてのノードへ送られる。その withdrawal エレメント内に入れられる障害の発生し
たパス要素のメトリックは、到達不能(unreachable)を示すオール 1 である。
リンクアップの場合、リンクレイヤ(回線)のアップだけでなく、隣接関係の確立、
そして、トランスポートレイヤにおける TPV プロセス同士のコネクションの確立がす
べて完了した時点をイベントの発生と見なす。ノードはこれを検出すると、それによ
って新たに接続されたノードへ update メッセージを送り、RT のベストパスを交換す
る。
4.4 仮想時間の処理
この節では、仮想時間がどのように処理されるかを具体的に説明する。
4.4.1 仮想時間の初期値と更新
リスタート（スタート）したノードは 0 から VT を始める。この 0 はリセットと同じ
意味を持ち、他のノードでは、どの VT の値を持つ他のパス要素よりも優先して採用す
る。ポートでイベントが発生した時に、ノードは VT をインクリメントする。また、VT
が最大値に達した場合、1 から繰り返す。すでに述べたように、リンクの切断などのイ
ベントを検出し、下流に通知できるのは受信側のポートであり、送信側のポートでは検
出はできても下流への通知ができないので、VT は受信ポートに付随するものとしてい
る。
0 の VT を持つ update を送り出したノードは、それがネットワーク全体に行き渡ると
予想される時間まで、次の update を抑制する。というのは、直後にイベントが発生し
て VT が 1 の経路情報を転送しても、VT の値が 0 の古いパス情報が滞留していた場合、
到着順序が逆転し、新しい経路情報が古い経路情報によって消される恐れがあるからで
ある。
4.4.2 メッセージの受信における仮想時間の処理
図 4.8 に、VT の検査が受信処理のいつの時点で行われるのかを示す。
87
パス番号の検査
withdrawalのVT検
査、処理
newのVT検査、処理
newのループ検査、
処理
新ベストパスの選択
図4.8 VT処理の位置
(1) VT の新旧関係の判別
VT の比較を行う場合、以下のような基準で新旧の判断を行う。即ち、VT の最大値
を n とした場合、以下の条件を満たす場合には a は b よりも古い(VT の値が小さい）
と判断する。
a<b の場合には b-a<n/2
a>b の場合には a-b>n/2
ただし、以下の場合には、特別な処理を行う。
(a) 受信した VT が 0 の場合
VT が 0 の場合、そのリンクを持つノードがリスタートしたことを示す。この場合、
上記の判断は行わず、受信した VT が 0 の経路情報を最新のものと判断する。しか
し、一旦これが TT テーブルに入ると、その TT テーブル内容と受信した経路情報の
VT との比較は通常通り行われる。
(b) VTT の VT エントリの値が 0 である場合
VTT の対応するエントリが 0 の場合には、どの値の VT でも受理する。
88
(c) VTT に対応するエントリがない場合
これは、リンクが新たに経路情報に現れた場合に発生する。この場合には、VT の
値にかかわらず受理し、VTT にエントリを作成して記録する。
(2) VTT のエントリの処理
VTT のエントリは以下のように処理される。
(a) エントリの生成
新たなパスの要素（リンク）が出現した場合には、それに対応するエントリを生成
し、当該 VT の値を記録する。また、エントリのガーベージコレクションのために
タイマを起動する。
(b) エントリのアップデート
パスを受信するたびに、すべてのパスの要素について VT エントリを調べる。もし、
更新された VT がパスに含まれていれば、その値でエントリを更新し、ガーベージ
コレクション用のタイマをリフレッシュしてリセットする。また、逆の場合には、
アップデートしない。但し、VT が 0 の時にはエントリを 0 で更新する。
4.5 VT 処理のオーバヘッドと効率化
この節では、TPV の CPU オーバヘッドとメモリオーバヘッドおよびその問題への対策を
示す。
4.5.1 予想されるオーバヘッド
ここでは、インターネットの経路情報の統計から CPU とメモリのオーバヘッドを予測す
る。
(1) メモリオーバヘッド
パス情報に VT を付加することによって以下の 2 つが原因でメモリ量が増大する。
(i) TT に保持するパス内の VT に関するメモリ量
(ii) VTT エントリのメモリ量
89
このオーバヘッドを推測するには、パスベクトルプロトコル BGP における平均パス長
が参考になる。例えば、http://bgp.potaroo.net によると 2002 年 8 月 7 日の
AS2828(Internix)における観測では、以下のようになっている。
パス総数 約 11 万経路
パス要素 13618 種類。うち、
1 つだけのパスに出現する物 9557 個(70%)。
オリジンだけに出現する物 9529 個(70%)
Transit+Origin に出現する物 3826 個
パス情報の平均パス要素数 3.4 個/パス情報
最大長 17 個/パス情報
TPV を適用したと仮定し、VT が 4byte を必要とすると仮定すると、TT のほうは、平
均パス要素数とパス総数を掛けて、約 1.5Mbyte の増大となる。また、VTT エントリ
のメモリ量は、約 14 万のパス要素がそれぞれ 4 つのパス要素との接続があり、エン
トリが 4byte を必要と仮定すると、約 2Mbyte の増大となる。
(2) CPU オーバヘッド
TPV では、受信したパス情報の要素をスキャンしてループの有無や VT の比較を行う。
VTT のメモリ量抑制や処理オーバヘッド抑制のために、後述する VT の不要なエント
リの回収を行うものの、目的別にパス情報のスキャンを行うと、以下のように 3 回の
スキャンが発生する。
(i) ループの検査を行う。
(ii) パス中の VT と VTT とを比較して新旧を判断するとともに、VTT の更新を行う。
(iii) (ii)で更新された VTT エントリに関して、既存の TT エントリを検査する。
(iv) (ii)で VT が付いていないパス要素に関し、VTT を参照して新旧を判断する。
特に、(ii)(iv)に関しては、ポート番号と VT の両方をアクセスすることになる。ま
た、(iv)に関しては、(ii)の検査対象となった以外のすべての VTT エントリとパス要
素とを比較しなければならない。更に、既存の TT エントリが多い場合には、(iii)
のオーバヘッドが大きくなる。これらの処理のオーバヘッドは、平均パス要素数、VTT
エントリ数、TT エントリ数等に比例する。
メモリオーバヘッドの場合と同じく AS2828(Internix)における観測データを元に
CPU のオーバヘッドを推測すると、(iii)については 11 万ものエントリについてチャ
90
ックを行わなければならないことになって現実的ではない。また、(i)(ii)(iv)のパ
スのスキャンは、平均が 3 の長さのため、オーバヘッドは大きくないが、これがより
長くなることを ESSP では想定しておいたほうがリスクが少ない。そこで、以降で説
明するアルゴリズムで処理のオーバヘッドを軽減し、効率化を図る。
4.5.2 メモリオーバヘッドの抑制
メモリオーバヘッドの抑制には、不要なエントリを回収するガーベージコレクション
(以下 GC)を行う。
(1) VTT の GC
仮想時間は、経路変動の際に経路情報の新しさを判別するために使用する。これを
逆に言えば、変動がない期間および変動の最初の更新については常に最新の経路情報
だけが存在するので仮想時間を比較する必要はない。このため、ネットワークが安定
している時には、VTT の大きさは 0 で良い。
そこで、最後の経路変動から一定時間を経過した VTT のエントリを GC によって消
去する。これによりメモリ量を抑制することができ、すべての終点に関するパスが一
度に変動しない限り、VTT の大きさを小さく保つことができる。
GC のため、VTT の各エントリにはタイマをつける。このタイマはリアルタイムに更
新され、タイムアウトが発生した場合には、当該エントリが消去される。また、タイ
マのリフレッシュのため、パス情報の受信の際には、以下の処理を行う。
(i) VTT エントリを生成した場合、消去のためのタイマを起動する。
(ii) 経路情報が更新された場合、それに含まれるリンクに対応するエントリのタ
イマをリフレッシュする。ループの存在などによって無効な情報と判断された経路
情報に関しても、タイマのリフレッシュやエントリの生成を行う。
なお、一時に多数のパスの変動が発生した場合には、VTT にメモリ制限を付け、そ
れ以上エントリを作成できなくする。メモリに制限を加えても、効果がなくなるわけ
ではない。即ち、VTT にエントリのない経路情報の場合、新しさが比較できないため
にバウンシングは生じる可能性があるものの、それは従来の PV と同じ程度であって
致命的な問題とはならない。また、すべての終点に関する経路で言えば、トータルの
経路のバウンシングは確実に減少する。メモリ制限を行っても、時間が経過すれば、
すでにあるエントリが GC によって回収され、新たなエントリが生成できるようにな
91
る。
(2) TT 内パス要素中にある VT の GC
VTT だけではなく、TT 内に保持しているパス情報内の VT も、ネットワークが安定
した時には比較する必要がない。そこで、パス要素内の VT も GC を行う。これによっ
て、経路数が増大したとしても、安定期には従来の PV 型のプロトコルと同じメモリ
量だけが使用される。
GC のため、TT の各エントリにはタイマが設けられる。このタイマはパス情報が TT
に登録される時にスタートする。そして、タイムアウトが発生した場合には、当該パ
スに含まれるパス要素の VT が消去される。ところが、消去はパス情報内のすべての
パス要素に関して一斉に行われる上に、このタイマは VTT のタイマと独立したもので
ある。更に、スイッチごとに消去のタイミングが異なる。このため、VTT 内のエント
リの消去、TT に記憶されたパス内のフラグのクリアが非同期に発生し、以下の問題
が起る。
(i) パス内の VT が VTT よりも先に消去された場合
このパスが受信された場合、VTT と比較され、VTT にはエントリがあるために受信
された情報が古い物と判断される。
(ii) VTT のエントリが先に消去された場合
受信したパス情報内には対応するパス要素に VT が付けられている。従って、VTT
に再度エントリが作成されることになる。
そこで、(i)に対応するため、VTT エントリに記憶されたメトリックと対応するパ
ス要素のメトリックとを比較する。そして、その値が等しいければ、パス要素に VT
がなくとも無効のフラグを立てないようにする。(ii)については、VTT エントリの GC
の時期が延びるが、いずれタイムアウトによって消去されるので対処しなくとも大き
な問題とはならない。
(3) パス情報の受信処理
パス情報を受信する際には、個々のパス要素の VT を VTT と比較するが、VTT のエン
トリが GC によって回収されている場合がある。この場合、以下のように新旧を判断
すれば問題は発生しない。
92
(i) VTT に対応するエントリがない場合
受信したパス情報は、新たな変動が発生したために生成されたものと考えられ
る。従って、最新のものと解釈する。そして、VTT にその VT を登録する。
(ii) VTT に対応するエントリがある場合
パス要素にも VT がある場合には、対応する VTT のエントリと比較して新旧の判
断を行う。また、パス要素のほうに VT がない場合には、すでに他のパス情報によ
ってネットワークが変動したことが通知され VTT が更新されたものと判断し、それ
を古いパス情報と解釈する。
(4) パス情報受信時における VT の付加の抑制
ノードは、ポートでメッセージを受信し、TT に蓄積する前に、それを受信した時
のメトリックと VT を付加する。しかし、そのリンクが安定した時には、VT は使用さ
れないので、付加することは無駄である。そこで、各ポートに VT 付加に関する抑止
用タイマを設ける。そして、ポートの VT がアップデートされて一定時間を経過した
後は、そのポートで受信したパス情報に VT を付加しない。これによって、メモリの
抑制だけでなく、不要な VT の比較が他ノードで行われることを防止することができ
る。
4.5.3 CPU オーバヘッドの抑制
CPU オーバヘッドは以下の計算の効率化によって抑制できる。
(1) パス情報内の各要素に VT が含まれているかどうを示すビットマップの導入
受信したパス要素内の VT は、リンクの安定時には空になっている。空になってい
れば、比較を行わない分だけオーバヘッドが減るはずである。ところが、それが空か
どうかは、それをアクセスするまでわからない。従って、すべてのパス要素に対する
サーチが発生してしまう。
そこで、new エレメントに各パス要素の VT に対応したビットマップのフラグを持
つ。それが有効であれば 1、空であれば 0 としておく。このため、このフラグをチェ
ックし、オール 0 であれば、VTT エントリの対応する VT をアクセスするだけで良い。
VTT にエントリがあれば、その方が新しいと解釈し、無効のフラグを立てて TT に保
持する。
ビットマップがオール 0 でなれば、対応するビットの位置にあるパス要素の VT だ
93
けをチェックし VTT 内の VT と比較すれば良い。また、このパス情報が TT 中で一定時
間が経過し、VT の GC を行う際には、このフラグの部分をクリアするだけで、VT の無
効化が完了する。
(2) パス要素アクセスの多重化
何 度 も パ ス 要 素 の ス キ ャ ン が 発 生 し な い よ う に 、 4.5.1 項 の (2) で 述 べ た
(i)(ii)(iv)のステップを独立して行うのではなく処理を多重化する。また、(iii)
に関しては、既存のすべての TT エントリとの比較を行うのではなく、ベストパス選
択の対象となる受信したパス情報の終点アドレスと同じエントリとの比較だけを行
う。その他の TT エレメントに関しては、RT のエントリをメッセージで転送する時に
有効性のチェックを行う。即ち、以下を受信したパス情報内のすべてのパス要素に対
して行う。
(i) スイッチ番号を自スイッチ番号と比較する。一致すれば、このパス情報に無効
のフラグを立てる。
(ii) VT の有効性を示すビットマップが１であれば VTT 内の対応するエントリとの
VT の比較を行う。VTT の更新を行った場合にはそのエントリを記憶しておく。また、
対応するビットマップの値が 0 であれば、すべての VTT のエントリとの比較を行う。
VTT にそれがあれば無効のフラグを立てる。
(iii) 更新された VTT のエントリに関して、受信したパス情報と同一終点アドレス
を持つ TT 内のエントリ（パス情報）のスキャンを行う。
この処理のループの中で、(ii)においてパス情報内のパス要素とすべての VTT エント
リとの比較が発生する。しかし、VTT エントリは安定すれば GC で回収されることか
ら、実際には、比較すべき対象は少ないと予想される。以上の処理によって、受信し
たパス情報の一回のスキャンと、それと同一終点アドレスに関する TT エントリそれ
ぞれのスキャンだけにオーバヘッドを抑制することができる。後者のオーバヘッドは
TT のエントリ数に比例する。
(3) 既存 TT と更新された VTT エントリとの比較の分散化
VTT エントリが更新されると、既存の TT 内のパス情報が古いものでないかどうかを
チェックする必要がある。しかし、これが膨大な数の場合、オーバヘッドが問題とな
る。そこで、以下の処理を行う。
94
(i) 既存 TT との比較は、VTT 更新のきっかけとなった受信したパス情報と同一終点
アドレスのものだけとする。
(ii) その他の既存 TT は、それを隣接するスイッチへ転送する時点で行う。もしも、
そのパス情報が無効であったことがわかった場合には、ベストパスの再計算を行って、
その結果を隣接するスイッチへ通知する。
以上の処理によって、既存 TT の有効性をチェックするために発生する恐れのある CPU
オーバーロードを分散させることができる。
4.6 評価
TPV の収束性を検証するため、従来のプロトコル BGP と比較する。
4.6.1 シナリオ
シナリオは、参考文献[77]において、収束に 48 ステップを要している BGP の例であ
る。このトポロジを図 4.9 に示す。Nn はノード番号 n を持つノード、Pnm はノード n に
おけるローカルな番号 m を持つポートである。また、TTn と RTn をそれぞれノード Nn の
トポロジテーブルとルーティングテーブルとする。以下では、ノード N3 がダウンした
場合を想定し、N0、N1、N2 が N3 への経路を完全に到達不能(unreachable)とするまでの
ステップをシミュレーションする。
付録 1 に、VT のない従来のパスベクタアルゴリズムの場合に N3 への経路がどのように
収束して行くのかを示す。付録 2 には、VT を導入した TPV が、このような場合でも 4
ステップで収束することを示している。なお、これらの例では、わかりやすくするため
パス情報にメトリックは含めていない。パスの選択にあたっては、ホップ数だけを考慮
する。また、無効な経路情報は TT に入れてフラグを付けるのではなく、破棄する。
N0
P00
P02
P32
P20
N2
P30
P22
P21
P01
N3
P31
P12
P11
P10
N1
図 4.9 想定するネットワーク
95
4.6.2 結果と考察
従来のパスベクトルでは、付録 1 に示したように、N0, N1, N2 間の古いパス情報のた
らい回しによって、N0, N1, N2 から N3 への経路が収束して完全に到達不能(unreachable)
となるのは、48 ステップ後となる [77]。この様子を表 4.1 に示す。一方、付録 2 に示
した TPV の場合には、表 4.2 に示すように RT が変化する。
表 4.1 BGP におけるベストパスの変化
ノード
ステップ
1
ステップ
2
ステップ
3
ステップ
4
N0
N1 N3
N1 N3
N2 N3
N1
N0 N3
N2 N3
N2 N3
N2
N0 N3
N1 N3
N0 N1 N3
到 達 不 N1 N2 N3 N1 N2 N3 省略
能
N2 N0 N3 N2 N0 N3 到 達 不 省略
能
N0 N1 N3 N0 N1 N3 N0 N1 N3 省略
ノード
N0
N1
N2
ステップ
5
ステップ
6
表 4.2 TPV におけるベストパスの変化
ステップ 1
ステップ 2
ステップ 3
N1 N3
N1 N3
N2 N3
N0 N3
N2 N3
N2 N3
N0 N3
N1 N3
到達不能
ステップ
7 .. 47
ステップ
48
到達不
能
到達不
能
到達不
能
ステップ 4
到達不能
到達不能
到達不能
以下では、両者の収束時間を比較するとともに、経路に一時的に発生するループについ
て考察する。
(1) 収束時間
BGP の場合、収束に 48 ステップを要しているのに対し、TPV の場合には、わずか 4
ステップで収束していることがわかる。これは、古い情報が update メッセージで通
知されても、TPV ではその新旧が判断できるために、無効としてベストパス選択の候
補に入れないからである。一方、BGP のほうは、古い情報であっても、それが判断で
きずにベストパスに採用する。その情報が更に次のノードへ通知されるために、収束
が遅くなる。
(2) 経路の一時的ループ
BGP の場合も、TPV の場合も、N0、N1、N2 は到達不能となるまでそれぞれ、2 回のバ
96
ウンスが発生している。ステップ 1 から 2 までは、N0,N1 が N2 をサクセサとし、N2 が
N1 をサクセサとするループである。これは、TT によるキャッシュ効果によってすべ
てのノードで同時に次善のパスが選択されることが原因である。TT を使用しなけれ
ばこのループは発生しない。しかし、その場合には、一般的な状況での収束性能が落
ることになる。というのは、通常は、この例題のように一度に複数の経路が無効とな
るような障害が発生する確率は小さいからである。
4.7 TPV の MAPOS 経路制御プロトコルへの応用
本節では、TPV を MAPOS の経路制御に適用した Extended Switch-Switch Protocol (ESSP)
について述べる。
4.7.1 TPV 導入の目的と設計条件
初期の MAPOS では、経路制御に距離ベクタアルゴリズム DV (Distance Vector) [12]
を使用した Switch-Switch Protocol (SSP) [59]を使用していた。このプロトコルは実
装が比較的簡単なものの、経路の収束までに数十秒以上を要する。これは、DV におけ
る count-to-infinity [75]に代表されるループの発生や route bouncing [75]等の経路
収束における問題を回避するため、収束が収まるまで中継を停止するからである。そこ
で、この問題を解決し、数十ミリ秒から数百ミリ秒オーダの経路切替えを行うという目
標を達成するため、TPV アルゴリズムを新しい MAPOS の経路制御プロトコル ESSP に導
入した。
以下では、TPV を ESSP に適用する際に MAPOS の制約によって生じる機能の縮退を説
明する。また、MAPOS のネットワークアーキテクチャ上の特徴によって使用しない機能
も明らかにする。
(1) MAPOS の制約
(a)
MAPOS では、フレームのヘッダに転送元アドレスがないために、リバースパ
スブロードキャスト Reverse Path Broadcast (RPB) [71][72] ができない。これ
を解決するため、すでに 3.5 章で述べた Virtual Reverse Path Broadcast(VRPB)
[59] を行う。即ち、すべてのブロードキャスト/マルチキャストフレームはシステ
ム中で最も小さい値のアドレスを持つスイッチを転送元アドレスに持つものと仮
定して中継を行う。
(b) MAPOS のもう一つの制約として、フレームのヘッダには、IP プロトコルで使
97
用されているような無限の中継を防止するための Time-to-Live (TTL)フィールド
がないことがあげられる。このため、経路に一時的ループが発生した場合には、そ
のループがなくなるまでフレームが回り続けリンクの負荷が急激に上昇する危険
がある。特にこれが問題となるのは、すべてのホストがフレームを受信するブロー
ドキャスト/マルチキャストフレームである。これを避けるため、経路に変動があ
った場合には、中継を短時間だけ停止し、経路の安定化を待つ。
(2) 使用しない機能
MAPOS スイッチ同士はポイントツーポイントの SONET/SDH リンクで接続される。従
って、イーサネットのような多重アクセス可能なリンクと異なり、隣接するスイッチ
を動的に探して隣接関係を設立する必要はない。このため、隣接するノードを発見す
るための Hello メッセージは使用しない。また、リンクがアップした後、すぐにトラ
ンスポートにおけるバーチャルサーキットの接続を行う。このように、隣接関係が静
的であるため、NT は静的に持ち、動的に生成しない。
4.7.2 ESSP プロトコル群
この項では、ESSP のプロトコル群の構成を説明する。これは以下の 2 つのサブプロト
コルから構成される。
(1) 簡易トランスポートプロトコル STP
Simple Transport Protocol (STP)は、ESSP を構成するサブプロトコルの一つであ
る。これは、隣接するスイッチ間で TPV のメッセージをやり取りするための簡易トラ
ンスポートプロトコルである。その役目は、誤りのない転送路であるバーチャルサー
キットを上位レイヤへ提供することである。TPV と異なり、ESSP では hello を使用し
ないので、この STP のセッションの確立をもって隣接関係(adjacency)が確立された
ものとする。
(2)ESSP メッセージ転送プロトコル MTP
Message Transfer Protocol (MTP)は、スイッチ間でパス情報を交換するための ESSP
のサブプロトコルである。メッセージは、STP の提供するバーチャルサーキットを使
用して転送される。
98
ESSPメッセージ処理プロセス
メッセージ転送プロトコル(MTP)
( Update, Refresh)
簡易トランスポートプロトコル (STP)
リンクプロトコル (MAPOS)
図4.10 ESSPの構成要素
図 4.10 にこれらの構成要素の関係を示す。
4.7.3 STP の概要
STP は、ESSP のメッセージ転送のために設計された簡易なコネクション指向のトラン
スポートプロトコルである。これは、誤りのない転送路であるバーチャルサーキットを
上位レイヤのメッセージ転送プロトコル MTP へ提供する。しかし、代表的なトランスポ
ートプロトコルである TCP[10]と異なり、リンクごとにバーチャルサーキットを 1 つし
か提供しない。
STP における通信は、呼設定フェーズ、認証フェーズ、メッセージ転送フェーズ、呼
解放フェーズから構成される。これを図 4.11 に示す。呼設定では、双方向のバーチャ
ルサーキットを設定する。認証が完了すると、メッセージ転送フェーズに移行する。STP
では確認応答を行い、応答が規定時間内に返ってこない場合には、再転送によるエラー
からの回復を行う。この規定時間は、TCP と同じく、それまでの応答確認に要する時間
を観測しておくことによって最適値を決め、動的に変更する。なお、STP データグラム
は、MAPOS フレームを使用して転送する。
4.7.4 MTP の概要
MTP は、STP によって提供されたバーチャルサーキットを使用して隣接するスイッチ
間で ESSP のメッセージを転送する。メッセージには、経路情報を通知する update メッ
セージと、経路情報の不一致やシステムダウンを検出するために定期的に転送する
refresh メッセージとがある。メッセージは、MTP メッセージヘッダとペイロードから
構成される。これを図 4.12 に示す。 update メッセージのペイロードは、複数のパス
情報から構成される。単一のメッセージに異なる終点アドレスに関する複数のパス情報
を入れることが可能である。各パス情報は、パス情報ヘッダと複数のパス情報エレメン
トから構成される。エレメントには、(a) new route エレメント、(b) withdrawal route
99
呼設定フェーズ
認証フェーズ
No
認証成功？
Yes
メッセージ転送
フェーズ
呼開放フェーズ
図 4.11 STP のフェーズ
MTP メッセージヘッダ
パス情報１
パス情報ヘッダ
パス情報エレメント
パス情報２
パス情報３
パス情報エレメント
パス情報エレメント
図 4.12 update メッセージの構造
エレメント、(c) multicast route エレメント等がある。multicast route エレメント
については、4.7.9 項で説明する。
4.7.5 ESSP プロトコルの処理概要
この項では、ESSP プロトコルの処理概要を示す。
(1) ESSP の役割
ESSP の役割は、最終的に MAPOS スイッチがフレーム中継に使用するために使用す
る経路テーブル Forwarding Table (FT)を作成することである。このために ESSP は、
TPV のアルゴリズムに基づいて隣接するスイッチ間でメッセージを交換し、ベストパ
スを計算する。MAPOS のスイッチにおいて経路制御のために使用するテーブルは NT,
100
TT, VTT, RT, BRT, FT の 6 つである。このうち、FT を除く 5 つは TPV に関するテー
ブルである。
ESSP における処理は、隣接するすべてのスイッチからパス情報を受信し、それら
の中からベストパスを選択し、選択されたベストパスに自スイッチに関するパス要素
を加えたものを隣接するすべてのスイッチへ通知するという手順の繰り返しである。
リンクがダウンした場合には、そのリンク経由で接続していた相手のスイッチから到
達不能のメトリック(unreachable)値でパス情報を受け取った場合と同じ動作を行う。
(2) 六つのテーブル
ここでは、ESSP の処理系が使用する TT, NT, RT, VTT, BRT, FT の構造を説明する。
(i) TT
TT では、すべての隣接するスイッチからの経路情報を終点アドレスごとにまと
めて保持する。TPV と同じく、エントリは終点アドレスごと、サブエントリはパス
情報ごとである。
(ii) NT
NT は、メトリック、VT、STP 等の隣接するスイッチとの通信に関する情報を保持
する。NT はスイッチのブート時にポートごとに固定的に用意される。
(iii) VTT
Virtual Time Table(VTT)は、経路情報から抽出したスイッチ間のリンク(実際に
は受信ポート)に関する最新の仮想時間 VT を保持する。エントリは、パス要素が初
めて現れた時に生成され、GC 用タイマのタイムアウトで消去される。
(iv) RT
RT は、各終点アドレスごとのベストパスを保持する。実際の中継には RT は使用
されず、それをメモリに展開しテーブルの検索を不要とした FT が使用される。な
お、各終点アドレスごとに中継抑制タイマーのスロットが用意される。これは、経
路が変動してから安定するまでの時間、ユニキャストの転送を抑制するためのもの
である。
(v) BRT
BRT はブロードキャストとマルチキャストフレームの転送のために使用される。
これについては、4.7.7 項で詳しく説明する。
101
(vi) FT
RT や BRT をフレームの中継のたびに検索していたのでは高速な中継処理ができ
ない。そこで、MAPOS スイッチは、ハードウェアの中継テーブル Forwarding Table
(FT)を使用してそれを高速化する。FT は、MAPOS のアドレス長が最大 16 ビットで
あることを生かし、64K ワードの RAM で実現される。これを図 4.13 に示す。
FT には MAPOS アドレス空間全体をリニアにマッピングする。この場合、ホスト
アドレスを含む全アドレス空間に経路情報を展開してビットマップを作るので、ホ
ストが接続されているポートも、隣接するスイッチへのリンクが接続されているポ
ートも取り扱いは同じである。また、ユニキャストの場合もブロードキャスト/マ
ルチキャストの場合も、取り扱いは同じである。
中継を行う場合には、フレームの転送先アドレスをメモリアドレスとして一度に
エントリを取り出す。そのエントリには、そのフレームを送り出すべきポートに対
応するビットが立てられたビットマップが入れられているので、単に対応するポー
トへフレームを送り出す。この単純な処理だけで、転送先アドレスが直接接続され
ているホストの場合にはそれへ、そうではない場合には経路情報に従った次のスイ
ッチへフレームが渡される。
ユニキャストアドレスの場合、立っているビットは一つである。マルチキャスト
やブロードキャストに対応するアドレスの場合、複数のビットが立っている場合が
ある。まったくビットが立っていない場合、フレームはそのまま捨られる。
転送先アドレス
ユニキャスト域
ブロードキャスト/
マルチキャスト域
ビットマップ
図4.13 Forwarding Table
102
NT
RT
NT
FT
TT
BRT
VTT
NT
図4.14 経路情報の流れ
(3) MAPOS スイッチ内の経路情報の流れ
図 4.14 に経路情報の流れを示す。受信したパス情報は、VTT を使用して新旧を判
断し、有効/無効のフラグを付けて TT に保持する。そのパス情報によって VTT も更新
される。TT 内では、同一終点アドレスごとにパス情報が保持され、その中からベス
トパスが選択されて RT に入れられる。ベストパスとは、パスに含まれるリンクのメ
トリックを合計したものが最も小さいパスである。RT のベストパスは FT に展開され、
一度のアクセスだけで次に転送すべきポートのビットマップが検索できるようにな
っている。一方、ブロードキャスト/マルチキャストに関しては、受信したパス情報
からユニキャストとは逆方向の経路を生成する。この経路は、VRPB に使用するため
のものである。実際のブロードキャスト/マルチキャストフレームの転送にあたって
は、BRT を展開した FT が使用される。
(4) FT への経路の展開
経路情報が変動し RT や BRT が変更される度に、それらのテーブルからビットマッ
プを生成し、FT に書き込む。ユニキャストの場合には、サブネットマスクを使用し
て終点アドレスの展開を行い、カバーするアドレス空間の範囲に同じ値をコピーする。
RT や BRT の変動後、すぐに FT の書き換えを行なって中継を開始すると一時的にフレ
ーム中継のループが発生して急激に負荷が上昇することがある。そこで、一定時間、
中継を停止する。これについては、4.7.10 項で詳しく説明する。
4.7.6 ESSP プロトコル処理系の概要
本章では、ESSP の処理系の例を示してメッセージの処理を具体的に説明する。
103
(1) 処理モジュール構成
ESSP の処理系は、リンク制御モジュール、メッセージ処理モジュール、スーパー
バイザモジュールの 3 つに大きく分けることができる。その例を図 4.15 に示す。リ
ンク制御モジュールは、隣接するスイッチとの接続を行う部分で、ポートごとに存在
する。また、メッセージ処理モジュールは、受信したメッセージの処理を行うモジュ
ールで、システムに一つ存在する。スーパーバイザモジュールは、リンク制御モジュ
ールやメッセージ処理モジュールの制御や管理を行う。
(2) リンク制御モジュール
リンク制御モジュールは、物理レイヤ、リンクレイヤ、認証を含むトランスポート
レイヤの制御や管理を行う。これは、更に以下の 3 つのサブモジュールから構成され
る。
(i) ダンぺニングサブモジュール
リンクのアップ/ダウンはダンぺニングサブモジュールが管理する。このモジュ
ールでは、ある時間内にアップダウンの頻度が閾値を越えると、たとえポートがア
ップしたとしても、ダウンしたままと見なす。ポートのアップダウンが発生すると、
それを、(ii)のトランスポートサブモジュールに伝える。
メッセージ処理モジュール
リンク制御モジュール（ポートごと）
ポート
トランスポート
サブモジュール
reset
TT
refresh
NT
ディスパッチャ
サブモジュール
ダンぺニング
サブモジュール
refreshモニタサ
ブモジュール
reply, query, update
refresh
FT
refresh
スケジューラ
ESSPスーパーバイザモジュール
DC
LC
reply, query, update
リンク管理サブモジュール
経路計算サブ
モジュール
BRT
reply監視
タイマ
RT
メッセージ管理サブモジュール
図4.15 ESSPの処理モジュール概要
104
(ii)トランスポートサブモジュール
トランスポートモジュールの役割はメッセージ制御部に対してエラーのないバ
ーチャルサーキットを提供することである。これは、メッセージ処理モジュールか
らのオープン、クローズ、リセット、リード、ライト等の要求を処理する。また、
回線のダウン、応答確認メッセージのタイムアウトやリセット要求の受信等によっ
てトランスポートレイヤ以下に障害が発生した場合には、それをメッセージ処理モ
ジュールに伝える。
受信したメッセージは、受信したポート番号、VT、メトリックを付加してメッセ
ージ処理モジュールへ渡す。
(iii) リンク制御サブモジュール
このモジュールは、ESSP スーパバイザモジュールからの要求によって、 (i)(ii)
のリセットを行ったり、これらの状態を報告する。
(3) メッセージ処理モジュール
メッセージ制御モジュールは、受信したメッセージの処理を行う。これは、更に以
下の 6 つのサブモジュールから構成される。
(i) ディスパッチャサブモジュール
このサブモジュールは、受信したメッセージを分類し、update メッセージの場
合には、メッセージ処理モジュールへ、情報の矛盾やソフトウェアのダウンを検出
するための refresh メッセージの場合には refresh モニタモジュールへ送る。また、
リンク制御部からリンクダウンなどのイベントを受け取ると、それをメッセージ処
理モジュールへ渡す。
(ii) 経路計算サブモジュール
経路計算サブモジュールは、パス要素を付加して受信したメッセージを TT に登
録する。そして、ベストパスの計算を行い、RT や FT を更新する。また、リンクダ
ウン等のイベントも処理し、必要に応じて隣接するスイッチへ update メッセージ
を送る。
(iii) refresh モニタ
refresh モニタは、隣接するスイッチから送られてくる refresh メッセージを処
理する。パス情報の送信側スイッチは、パス情報の矛盾を検出するために定期的に
105
refresh メッセージでベストパスを通知する。受信側では矛盾を発見したり、
refresh メッセージが指定期間送られてこない場合には、異常が発生したものと見
なす。このタイムアウトを検出した場合には、リンク制御モジュールに対してバー
チャルサーキットのリセット要求を行う。これにより、トランスポートのリセット
が行われる。その結果、リンクダウンが発生するので、ディスパッチャサブモジュ
ールへダウンが通知されてイベント処理が行われる。
(iv) refresh スケジューラ
refresh スケジューラは、RT を参照し、一定の間隔で refresh メッセージを転送
する。
(v) メッセージ管理サブモジュール
メッセージ管理サブモジュールは、メッセージ制御モジュール内のサブモジュー
ルを管理する。例えば、各サブモジュールをリスタートしたり、状態の報告を要求
する。
(4) ESSP スーパーバイザモジュール
スーパーバイザモジュールは、リンク制御モジュールとメッセージ処理モジュール
の両方を管理する。例えば、システムリセットを行う場合には、両者にリセットを要
求する。また、オペレータがリンクのメトリック等のパラメータを変更する場合には、
スーパーバイザモジュールがその要求をリンク制御モジュールに要求する。オペレー
タによって状態の報告が求められた場合には、スーパーバイザ部は両モジュールに対
して状態のレポートを要求する。
4.7.7 ブロードキャストとマルチキャストの中継
TPV では、ユニキャストフレームに加え、すべてのノードが受信するブロードキャス
トフレームと、特定のグループに属するノードだけが受信するマルチキャストフレーム
の転送をサポートする。ブロードキャストフレームの転送先アドレスは、通常オール 1
で表すブロードキャストアドレスである。一方、マルチキャストフレームの転送先アド
レスは、これを受信すべきグループ識別子(GID)になっている。これらの経路制御には、
RPB を使用する。
各ノードは、図 4.16 のようなブロードキャスト/マルチキャスト用の経路制御テーブ
ル BRT(Broadcast Routing Table)を持つ。これは、マルチキャストやブロードキャス
トフレームの始点アドレスごとにエントリがある。そのサブエントリには終点アドレス、
106
始点アドレス
転送抑制タイマ
終点アドレス(GID)
中継ポート(ビットマップ)
終点アドレス(GID)
中継ポート(ビットマップ)
終点アドレス(GID)
中継ポート(ビットマップ)
始点アドレス
転送抑制タイマ
終点アドレス(GID)
中継ポート(ビットマップ)
終点アドレス(GID)
中継ポート(ビットマップ)
図 4.16 BRT
N1
プレデセサ
プレデセサ
N2
ブロード/マルチキャスト
N3
N4
N bs
サクセサ
ブロードキャストの始点
ユニキャスト
図4.17 RPB
即ち、GID やブロードキャストアドレスに対応して、フレームを次に中継すべきポート
が指定されている。ノードはブロードキャストパケットやマルチキャストパケットを受
信すると、BRT を参照する。まず、そのパケットの始点アドレスに対応するエントリの
中で、そのパケットの終点アドレス(GID)に対応するサブエントリを見つける。そのサ
ブエントリを参照して、指定されたポートからフレームを送り出す。該当するエントリ
やサブエントリがない場合には、フレームは破棄される。
BRT はユニキャストの経路情報から作成する。例えば、図 4.17 の N3 では、ユニキャ
ストのある終点 Nbs に関して自スイッチをサクセサとする旨を通知してきたノード N1、
N2 を、ブロードキャストやマルチキャストフレームを中継すべき次のノードとして登録
する。ここで、マルチキャストの場合には、ある GID に属するノードが転送先になけれ
ば、中継は行わない。これは、中継先にあるノードによって異るので、GID ごとにサブ
エントリが作成されることになる。MAPOS では、フレーム中のヘッダに転送元アドレス
を持たないため、VRPB によって、すべてのフレームがネットワーク内で最小のアドレ
スを持つスイッチから送信されたと想定して処理を行う。
MAPOS では、フレームに TTL が無いため、ネットワークが安定しないうちにマルチキ
107
ャストやブロードキャストを中継すると、ループが発生する恐れがある。そこで、ネッ
トワークに変動が発生した場合には、短期間だけ中継を停止する。この目的で、図 4.16
に示す BRT には転送抑制タイマのスロットが用意されている。RT に変動が発生した場
合には、ユニキャストの経路情報を基に作成されている BRT にも変動が発生する場合が
ある。これに加え、RT で最も小さい終点アドレスが変化した場合にも VRPB の VSS が変
更されることになる。これらの場合には、直ちにタイマを起動し中継を停止する。再開
されるのは、このタイマがタイムアウトになった時点である。FT を使用した中継停止
の仕組については、4.7.10 項で更に詳しく説明する。
4.7.8 指定サクセサ DS
ユニキャストで複数のパスをベストパスとして選択し、両方のパスを並列に使用する
ダイナミックロードバランシングと呼ばれる方法がある。この場合、ユニキャストのベ
ストパスから生成されるブロードキャスト/マルチキャストの経路も複数になってしま
いループが発生する恐れがある。このような場合にも、ループのないスパニングツリー
を生成するため、各ノードが複数のサクセサのうち一つを代表サクセサとして選択する。
ここで選択されたサクセサを指定サクセサ Designated Successor (DS)と呼ぶ。
DS に指定したことを相手のノードに伝えるため、ESSP では update メッセージの new
エレメントを利用する。通常、選択したサクセサに対し、そのパス情報を逆に通知する
ことは無駄である。なぜならば、選択されたものは、サクセサから受信したパス情報だ
からである。しかし、ESSP では、選択したサクセサにも、そのパス情報を通知する。
そして、DS として選択したサクセサに対しては、その旨を示すフラグを付けておく。
これによって、複数のサクセサのうち、一つのサクセサだけからブロードキャストある
いはマルチキャストフレームが転送されることになり、ループは発生しない。
4.7.9 マルチキャスト経路の枝刈り
ブロードキャストフレームと異なり、エンドノードは、自分の属するグループあての
マルチキャストフレームしか受け取らない。属していないグループあてのマルチキャス
トフレームを受信したエンドノードはそれを破棄する。このようなオーバヘッドを抑制
するためには、配下にフレームのあて先の GID に属するエンドノードがない場合に、ス
イッチがそれを中継しない仕組が必要となる。
そこで、ESSP では、自スイッチの下流にあるノードが属する全 GID のリストに自ス
イッチの GID を加えたものを update メッセージの multicast route エレメントで上流
の DS に伝える。これを受信したスイッチでは、そのリストに含まれている GID あての
マルチキャストフレームは中継するが、それ以外のものは破棄する。GID のリストは、
108
DS として指定されている間だけ有効である。DS 指定が外された場合には、そのノード
へのマルチキャストフレームの中継を停止する。
multicast route エレメントは、new route エレメントで指定した DS だけに対して、
当該スイッチ配下あるいは、当該スイッチ経由で転送する GID のリストを通知する。こ
れがない場合には、通知する必要はない。また、サクセサではないスイッチに対して通
知する必要もない。(ここでは、単一の終点アドレスに関する GID のリストを議論して
いる。GID リストは、ユニキャストの終点アドレス、即ち、マルチキャストの始点アド
レスごとに存在する。)
GID メンバはダイナミックに変更される。例えば、自スイッチを DS としていたスイ
ッチが DS の指定を外せば（プレデセサではなくなる）その配下の GID のメンバが減る
ことになる。また、新たに自スイッチを DS に指定して multicast route エレメントで
配下の GID のリストを通知してきたスイッチがある場合、GID のメンバが増えることに
なる。そのようにメンバーに変化があるごとに、当該スイッチは DS に対して multicast
route エレメントだけを含む update メッセージを送って、現時点の GID のリストを渡
す。
4.7.10 FT の利用による転送停止方式
MAPOS では、一時的なループを回避するため、経路が変動した直後は転送を一時停止
し、一定時間後に転送を再開する。このための転送抑制タイマを RT と BRT に持つ。経
路テーブルにフラグを用意し、フレームの中継時に転送あるいは破棄を判断した場合、
通常状態での中継の際もフラグのアクセスと判断のオーバヘッドが加わる。そこで、以
下のように、スイッチがフレームの転送に FT を使用することを利用する。
(1) 経路が変動し、RT および BRT のエントリが更新されると、直ちにそれらの終点
アドレスあるいは始点アドレスに対応する FT エントリをクリアする。また、RT およ
び BRT のエントリにあるタイマを起動する。
(2) RT および BRT のタイマがタイムアウトになった後に、新しい経路情報を FT に反
映する。
以上の仕組により、中継停止の対象となるフレームは、転送すべきポートを示す FT の
ビットマップがクリアされているため、そのまま破棄される。フレームの破棄も、フレ
ームの転送と同様に一回のメモリアクセスで行われるので、中継の判断に要する CPU や
メモリのオーバヘッドもない。なお、以下に、RT や BRT から FT ヘのビットマップへの
展開アルゴリズムを示しておく。
109
(1) RT から FT への展開
RT の終点アドレスとサブネットから FT のアドレス範囲を求め、サクセサへのポー
トに対応するビットを立てる。これによってフレームの中継が開始される。
(2) BRT から FT への展開
BRT エントリの中継抑制タイマが切れると、以下の処理を行って中継を再開する。
(i) RT で最も小さい終点アドレスを見つける(VSS の決定）
(ii) そのアドレスに対応する BRT の始点アドレスのエントリを見つける
(iii) ブロードキャストも含め、その各 GID サブエントリに対応する FT のアドレ
スを指定して、そのサブエントリ内のビットパターン(中継するポートに 1 を立て
たもの)をそのままコピーする。 なお、自スイッチ配下のホストに関しては、GID
に属するホストが接続されているポートに対応するビットを立てる。
4.8 むすび
本章では、Border Gateway Protocol (BGP) に代表されるパスベクタ経路制御アル
ゴリズムの経路収束の不安定性 (route bouncing) に対し、経路情報発生時間を属性と
して付加することによって問題の解決を図った時相パスベクタ経路制御アルゴリズム
Temporal Path Vector (TPV) について述べた。
まず、route bouncing の原因は、経路計算の過渡期に、ネットワーク内に混在する
新旧の経路情報の区別ができないことに起因することを明らかにした。これに対し、パ
スの属性に情報発生時間を付加することによって古い情報による新しい情報の上書き
を防止し、更に、古い情報源（キャッシュ）を消去する TPV アルゴリズムが有効である
ことを示した。そして、情報発生時間としてリンクのイベントごとに進む仮想時間を使
用し、受信側ノードにおける仮想時間を使用することによって、分散したスイッチが的
確に経路情報の新旧を判断できることを明らかにした。
次に、机上でのシミュレーションを行い、同一シナリオの下で TPV の経路収束性を従
来のパスベクトルアルゴリズムと比較した。そして、従来の方式で収束に 48 ステップ
を要した場合に、TPV ではわずか 4 ステップで収束することを示した。
更に、TPV アルゴリズムを MAPOS の経路制御プロトコルへ適用した Extended
Switch-Switch Protocol (ESSP)について、そのプロトコル構成と実装アーキテクチャ
を説明した。そして、指定サクセサの概念を使用すればユニキャストで並列パスを使用
する場合でも、マルチキャスト/ブロードキャストのスパニングツリーを作成できるこ
110
と、GID リストを指定サクセサに渡すことで無駄なマルチキャストの転送を抑制できる
こと、MAPOS 固有の高速中継用テーブル FT を利用して一時的なループを防ぐための転
送抑制機構をオーバヘッドなしに作成できることを示した。
111
第 5 章 パス指向プロトコル実装モデル POM
概要
本章では、探索的なプロトコル開発を可能とするパス指向のプロトコル実装モデル POM
(Path Oriented Model)を提案し、従来の実装方式の問題点とそれに対するアプローチ
について論じる。まず、従来の実装モデルでは異なるバージョンのプロトコルが同一シ
ステム内に混在できず、探索的なプロトコル開発が困難であることを説明する。次に、
POM が、パケットを処理する各レイヤのプロトコルをポインタで持ち、そのポインタを
変更することによってコネクションごとに異なるバージョンのプロトコル処理を可能
とすることを示す。また、POM のモデルが、オブジェクト指向の枠組みを用いて実現で
きることを説明する。その場合、上位レイヤは下位レイヤの性質や機能を継承するとい
うパラダイムに基づいて、レイヤのプロトコルをレイヤクラスに対応させ、バーチャル
サーキットについてはレイヤクラスを多重継承したコネクションクラスに対応させる。
このオプションには直接継承方式と間接継承方式の２つの方式がある。ここでは、それ
らの特性を論じ、下位レイヤの変更に対しては前者の方式が向いており、上位レイヤの
変更に対しては後者が向いていることを明らかにする。最後に、POM ではパケットがす
べてのレイヤで共有され、プロセススイッチなしに複数のレイヤのプロトコル処理がで
きることを明らかにする。また、ユーザプロセスとプロトコル処理を行うプロセスとが
同時に同一オブジェクト上を走行することによって、ユーザプロセスによるパケット内
のデータへのアクセスとシステムプロセスによるパケットの組立とを並行して処理で
きることを示す。
112
5.1 はじめに
ネットワークプロトコルは、OSIの7レイヤモデル[11][12]に見られるように、明確に
モジュール化されて設計されている。それぞれのレイヤでは、提供するサービスとイン
タフェースだけが規定されており、その実現方法を隠蔽することができるようになって
いる。このため、通常、それぞれのプロトコルに対応するソフトウェアをモジュールと
して設計し、それらを結合することによってプロトコル処理系を構成する。これにより、
新たなサービスの追加やプロトコルの変更などによってプロトコルモジュールを変更
しなければならない場合には、変更の影響の及ぶ範囲が局所化でき、変更によって発生
するバグの影響を最小限にできる。しかし、プロトコル開発の側面からは、それぞれの
プロトコルソフトウェアモジュールが静的に結合している従来のアーキテクチャだけ
では、プロトコルを段階的に変更しながら探索的にプロトコルを完成させてゆく開発手
法との乖離が大きく、開発効率の向上が難しい。
そこで本章では、ネットワークソフトウェアのモジュール化の方式について議論する。
そして、パケットを処理する各レイヤのプロトコルをポインタで持ち、そのポインタを
変更することによってコネクションごとに異なるバージョンのプロトコルによる処理
ができる実装モデルを提案する[79][80[81][82]。これをパス指向実装モデル Path
Oriented Model (POM)と呼ぶ。
ここでは、まず、従来のプログラミングパラダイムに基づいた実装方法を示し、それ
が持つ問題点について言及する。次に、POMのモデルについて概要を説明する。そして、
それがオブジェクト指向の枠組で、バーチャルサーキットに沿ったプロトコルソフトウ
ェアパスをオブジェクトとしてモジュール化を行うことで実現できることを示す。また、
この継承の方式には、直接継承と間接継承とがあることを示す。前者では、上位レイヤ
が、利用するすべてのレイヤを直接に継承する。一方、後者では、各レイヤがその直下
のレイヤを継承することにより、上位レイヤがすべての必要なレイヤを継承する。ここ
では、それらの特性を論じ、下位レイヤの変更に対しては前者の方式が向いており、上
位レイヤの変更に対しては後者が向いていることを明らかにする。最後に、POMではパ
ケットがすべてのレイヤで共有され、プロセススイッチなしに複数のレイヤのプロトコ
ル処理ができることを明らかにする。また、ユーザプロセスとプロトコル処理を行うプ
ロセルとが同時に同一オブジェクト上を走行することによって、ユーザプロセルによる
パケット内のデータへのアクセスとシステムプロセスによるパケットの組立とを並行
して処理できることを示す。
5.2 探索的プロトコル開発の必要性
インターネットにおけるプロトコル開発は実証的に行われる。標準化の原案となるプ
113
ロトコルの仕様を提案する場合には、それを別々に実装した複数のプロトタイプが必要
となる[78]。これによって、プロトコルの完全性を検証するとともに、プロトコル仕様
書の記述に曖昧性がないことを検証する。この実装にあたっては、プロトコルの仕様を
規定する作業と、それを実装して検証する作業の繰り返しによって探索的にプログラム
が開発される。また、一度決定されたプロトコルも永続的なものではない。ネットワー
クの技術の進歩に合わせて、既存のプロトコルにも変更が加えられてゆく。この場合に
も、上記の探索的なプログラム開発過程が必要となる。
これらの作業を効率的に行うには、わずかに異なるバージョンのプロトコルの混在を
許し、探索的にプロトコルの実装を行えるネットワークプログラムの開発環境とプログ
ラミングのパラダイムが不可欠となる。POMは、このような探索的プロトコル開発の要
求に答えるべく開発したもので、オブジェクト指向の枠組で実現されている。プロトコ
ル開発者は、通信に必要なプロトコルのモジュールをスーパークラスとして継承したス
トリームのクラスを定義し、そのインタンスを生成する。これが、通信のチャネルとな
る。プロトコルを変更する場合には、従来のモジュールの代りに、新規モジュールを継
承したクラスを定義し、そのインスタンスを生成すれば良い。このようにして、わずか
に異なるバージョンのプロトコルが同一システムに混在できることになる。
5.3 参照モデルと従来のプロトコル実装モデル LOM の問題点
5.3.1 参照モデル
ネットワークシステムは、レイヤ構造でモデル化される。例えば、図5.1は、OSIの7
レイヤの参照モデル[11][12]である。各レイヤの役目は、上位レイヤへサービスを提供
ホスト
ホスト
アプリケーション レイヤ
アプリケーション レイヤ
プレゼン テーション レイヤ
プレゼン テーション レイヤ
セッション レイヤ
セッション レイヤ
トラン スポートレイヤ
パケット交換機
トラン スポートレイヤ
ネットワークレイヤ
ネットワークレイヤ
ネットワークレイヤ
データリンクレイヤ
ﾃﾞｰﾀﾘﾝｸﾚｲﾔ
ﾃﾞｰﾀﾘﾝｸﾚｲﾔ
データリンクレイヤ
物理レイヤ
物理ﾚｲﾔ
物理ﾚｲﾔ
物理レイヤ
図5.1 OSIの7レイヤモデルとアーキテクチャ
114
アプリケーション
トランスポートレイヤ
ネットワークレイヤ
リンクレイヤ
物理レイヤ
図5.2 TCP/IPのレイヤモデル
するとともに、内部構造を隠蔽することによってモジュール化を行うことである。通信
は同じレイヤ同士で行われる。この際の通信手順やメッセージの意味の集合をプロトコ
ルと呼ぶ。あるレイヤからのメッセージは、下位レイヤへと渡されていき、伝送路を通
ったあとに同位レイヤへ渡される。
レイヤ内には、メッセージを処理するプロセスがある。メッセージの受け渡しのため、
レイヤ間ではインターフェースが規定されている。このインタフェースを通じて、上位
レイヤへサービスが提供される。レイヤの数や、各レイヤの役割はプロトコル群によっ
て異なる。例えば、OSIの場合には、7つのレイヤから構成される。一方、TCP/IPプロト
コル群の場合には、図5.2に示すように、5つのレイヤから構成される。
従来、プロトコルを実装する場合には、上記の参照モデルをそのままソフトウェアに
マッピングしていた。即ち、レイヤのプロトコルをモジュールへ一対一に対応させ、モ
ジュール間を通信路で接続する。各モジュールはその隣接するモジュールへパケットを
渡し、それを受け取ったモジュール内のエージェントが処理を進めてゆく。ここでは、
この実装モデルをレイヤ指向モデルLayer Oriented Model (LOM)と呼ぶ。
5.3.2 従来のモデル LOM による実装とその問題点
本項では、本研究が対象としているTCP/IPプロトコル群のネットワークソフトウェア
について、LOMモデルに基く従来の実装方式を示し、その問題点を明らかにする。
(1) Symbolics社のLISP Machineにおける実装
Symbolics社が開発したLISP Machineにおけるネットワークの実装[54]は、LOMのモ
デルに忠実に従ったものである。これを図5.3に示す。LISP Machineは、LISP言語を
そのマシン語として実行する記号処理計算機であり、オブジェクト指向システムであ
るFlavorを使用してネットワークプロトコルの実装が行われた。各レイヤのプロトコ
ルごとに対応するモジュールがあり、受信の場合、下位のレイヤからキューを経て渡
されたパケットはモジュール内で処理された後、上位のレイヤのプロトコル処理を行
うモジュールにキューを介して渡される。送信の場合、その逆の順で処理が行われる。
115
アプリケーション
TCP/UDP
IP
イーサネット
：オブジェクト
図5.3 LISP Machineにおけるプロトコル実装
なお、オブジェクト指向では、プロトコルが扱うデータ構造と処理はクラスとして定
義され、そのインスタンスであるオブジェクトがモジュールに相当する。これらにつ
いては、5.5節で説明する。
(2) x-kernelにおける実装
Symbolics社のLISP Machineと同様、オブジェクト指向に基いてプロトコルを実装
したものに、x-kernelのアプローチ[55]がある。これは、プロトコル評価や設計のた
めのワークベンチを目指したものである。x-kernelから派生したものとして、プロト
コルをオプション別の粒度の小さなマイクロプロトコルに分割して実装し、アプリケ
ーションが必要なオプションを選択して使用できるようにしたmicroprotocols [83]、
x-kernelと同じアプローチによって柔軟なグループ通信システムを目指したHorus
[84]等のアプローチもある。これらは、LOM同様に各レイヤをモジュールに一対一に
対応させているものの、モジュール間のインターフェースを統一し、必要なプロトコ
ルを自由に組み合わせて使用できるようにしている。
x-kernelのモジュール構造を図5.4に示す。x-kernelでは、プロトコルモジュール
が上下のモジュールに提供するインタフェースの雛型(クラス)を定義している。そし
て、各モジュールがこの定義を継承することによってインタフェースの共通化を実現
する。インタフェースが共通であるため、ユーザは、任意のプロトコルモジュールを
接続できる。即ち、ユーザは、プロトコルを利用する場合に、利用したいプロトコル
モジュールと各モジュール間の階層関係を決定するプロトコルグラフを指定する。シ
ステム側は、指定された階層関係から、セッションオブジェクトというプロトコルモ
ジュール間の関係を保持するモジュールを生成する。そして、これがユーザにサービ
スを提供する。
116
Application
User-IP
TCP
TCP-IP
IP
IP-ether
Ether
: セッションオブジェクト
: プロトコルオブジェクト
図5.4 x-kernelのモジュール構造
(3) LOMの問題点
従来の実装方式のソフトウェア構造とその弱点については、すでに2.4.2項で議論し
た。以下では、それを踏まえてLOMの問題点を整理する。
(i) プロトコル変更による影響の拡大
LOMでは、あるレイヤのプロトコルを変更する必要があれば、そのモジュールを
直接書き換えなければならない。しかし、すべてのパケットが、同一のレイヤモジ
ュールで処理されるため、モジュールの変更の失敗は、すべてのパケットの処理に
影響が及び、影響の局所化が困難である。また、モジュールの変更中は、ネットワ
ークのサービスが全面的に止まってしまうという問題がある。
(ii) 異なるバージョン間の排他性
プロトコルとモジュールの関係が一対一になっているため、異なるバージョンの
プロトコルソフトウェアを混在させたり、モジュールに頻繁な変更を加えることが
困難で、プロトコルの探索的な開発を行うことができない。例えば、x-kernelでは、
インタフェースのクラス定義によってプロトコルの組み合わせの変更を支援する
ものの、それぞれのプロトコルモジュール(プロトコルオブジェクト)の異なるバー
ジョンが同一システム内に複数存在することを許してはいない。
117
これらの問題は、プロトコルのレイヤ構造のみに着目してモジュール化を行ってい
るところから発生する。そこで、通信のストリームに着目し、各ストリームに異なる
プロトコルの関係付けができようにすれば、各ストリームの独立性を高め、相互の影
響を排除することができる。ここでは、ストリームが通るバーチャルサーキットに沿
っ た 通 信 の パ ス を モ ジ ュ ー ル と 考 え る 実 装 モ デ ル Path Oriented Model
(POM)[79][80][81][82]を提案する。パスを表わすデータ構造には、そのパスを通る
パケットがどのプロトコルモジュールで処理されるのかがレイヤごとに記述されて
いる。従って、これを変更すれば、パスごとに異なるプロトコルのバージョンを使用
することができ、プロトコルの拡張および変更に対して柔軟なネットワークシステム
の構築が可能となる。即ち、モジュールの変更による影響の局所化、異なるバージョ
ンのプロトコルソフトウェアの混在、ネットワークサービスの中断を必要としない変
更などが可能となる。
5.4 POM 実装モデル
この章では、バーチャルサーキットをモジュールとするPOMの実装モデルを説明し、そ
れをどのようにしてバーチャルサーキットのないコネクションレス型の通信へ適用す
るのかを示す。
5.4.1 POM の概要
ネットワークシステムの主な機能の一つは、一つの実伝送路を多重化し、アプリケー
ションに対して、複数の仮想的な伝送路を提供することである。この仮想的な伝送路を
バーチャルサーキットと呼ぶ[11][12]。このバーチャルサーキットの概念図を、図5.5
に示す。バーチャルサーキットは、それぞれユニークな識別子を持ち、一つのシステム
内に複数存在する。実際には、これらのバーチャルサーキットは、それぞれの状態や識
別子を含むデータ構造として実現される。ここでは、それをコネクションと呼ぶ。
探索的にプロトコル設計/評価を行うためには、まず、システム内で同一レイヤに対
応する複数の異なったプロトコル処理モジュールの混在が可能でなければらない。とこ
ろが、従来のモデルでは、バーチャルサーキット上を転送されているパケットが、どの
プロトコルモジュールで処理がなされてユーザに渡されるかはシステム内でグローバ
ルに決定されていた。そこで、POMモデルでは、パケットがバーチャルサーキット上で
処理されるパスをモジュールの単位とする。つまり、バーチャルサーキットを示すデー
タ構造であるコネクションには、処理される一連のプロトコルモジュールを指定する情
報を持つ。これによって、バーチャルサーキットごとに異なったプロトコルモジュール
で処理することが可能となる。
118
ホストA
ホストB
A0 A1 A2
A0 A1 A2
C0 C1 C2
C0 C1 C2
V0 V1 V2
V0 V1 V2
実伝送路
Cn :コネクション
An :アプリケーション
V0 :バーチャルサーキット
図5.5 バーチャルサーキット
5.4.2 パケットの処理
パケットの受信の際には、それに入っているリンクレイヤ、ネットワークレイヤ、ト
ランスポートレイヤ等におけるバーチャルサーキットの識別子を先にデコードする。そ
して、それが属するコネクションにパケットを渡す。これによって、それが指定するプ
ロトコルで処理が行われる。また、パケットの送信の際には、処理すべきプロトコルの
識別子がコネクションに指定されているので、それに従ったプロトコルで処理を行って
転送する。この場合、コネクションごとにモジュールを用意していたのでは、多数のバ
ーチャルサーキットのあるようなシステムでメモリを圧迫する。そこで、バーチャルサ
ーキットを示すデータ構造にはモジュールへのポインタのみを持ち、モジュールの共有
を行う。また、既存モジュールに変更を加える場合にも、当該モジュールからの変更分
だけを持つことによって、元のモジュールの共有を更に進めるとともに変更に伴う影響
を局所化する。
以上のPOMモデルの概念図を図5.6に示す。コネクションモジュールは、バーチャルサ
ーキットにおける処理や変数を持つデータ構造である。これには、処理すべきパケット
を格納するバッファ、各レイヤＬごとの処理を行ういくつかの手続きへのポインタ、そ
して、コネクション固有の状態や識別子を格納しておくための各レイヤごとのレジスタ
Ｒなどが含まれる。
119
･･
レイヤモジュール
Ln-1
レイヤモジュール
Ln
レイヤモジュール
Ln’
レイヤモジュール
Ln＋1
レジスタRn+1
レジスタRn+1
レジスタRn
レジスタRn’
レジスタRn-1
レジスタRn-1
バッファ
レジスタ群
コネクションモジュール
イベント
デーモンプロセス Dn-1
バッファ
･･
レジスタ群
コネクションモジュール
イベント
デーモンプロセス Dn
イベント
イベント
デーモンプロセス Dn+1
図5.6 POMモデルの概念
5.4.3 プロセス
LOMでは処理の単位がレイヤのプロトコルであり、プロトコル別にプロセスの割り当
てが行われていた。これに対し、POMでは、バーチャルサーキットを単位としてプロセ
スを割り当てる。即ち、ネットワークのシステムは、レイヤごとにデーモンプロセスを
用意しておき、あるバーチャルサーキットに対するイベントが発生すると、そのコネク
ションモジュール内に格納されているポインタを手掛かりに対応する手続きを呼び出
す。このデーモンプロセスは、各コネクションモジュールにプロセスを割り当てるディ
スパッチャとして機能する。プロセスは、コネクションモジュール内のバッファに格納
されたパケットを対象とし、各レイヤごとに用意されているレジスタを作業用に使用し
ながら処理を進める。
5.4.4 コネクションレス型通信への POM モデルの適用
コネクションモジュールは、コネクションの確立に先だって生成される。このため、
新たなプロトコルのサポートやプロトコルの変更を行いたい場合には、モジュール生成
時に、従来の手続きに変えて、新たな手続きへのポインタをコネクションモジュールに
入れればよい。手続きそのものをモジュール内に持つのではなく、その手続きへのポイ
ンタだけを保持するので、コネクション間では、コードの共有がなされる。従って、た
120
とえ、コネクションの数が多くとも、モジュールのメモリがそれにつれて増大すること
はない。
ところで、これまでの説明では、バーチャルサーキットの存在を前提としてきた。バ
ーチャルサーキットは、通信の前にコネクションを設定し、通信の後に解放するという
コネクション型通信によって提供される。しかし、コネクションレス型通信の場合には、
その設定なしに通信が開始されるのでPOMのモデルを適用できない。そこで、コネクシ
ョンレス型の通信でも、データ転送の前に仮想的にバーチャルサーキットが設定される
ものと考えれば、POMのモデルを適用できる。
以上説明してきたように、POMのモデルでは、コネクション指向だけでなくコネクシ
ョンレスの通信にも適用でき、新たにプロトコルを実装したり、プロトコルを変更して
も、既存のシステムへ影響を及ぼすことなく変更を行うことができる。また、同一レイ
ヤ内で異なるバージョンのプロトコルが使用可能となる。
5.5 POM モデルとオブジェクト指向
ここでは、POMモデルがオブジェクト指向の枠組にマッピングできることを説明する。
また、POMモデルが、これまでのLOMモデルと対立するものではなく、レイヤをベースと
して構成されることを示す。まず、オブジェクト指向の概要から説明する。
5.5.1 オブジェクト指向による設計の概念
プロトコルソフトウエアのプログラマがコンピュータ上で実装を行う際には、データ
表現や処理の流れなど、対象をどのようにモデル化するかが問題になる。このような問
題に対し、これまで手続き指向パラダイム、関数型プログラミング、論理型プログラミ
ング、オブジェクト指向などのプログラミングパラダイムが研究されてきた。オブジェ
クト指向の概念では、プログラミングの対象をオブジェクトという単位でモデル化する。
オブジェクトは、データとその上の手続きを一体化したものであり、内部のデータ構造
や内部の処理を隠蔽する。また、各オブジェクトは、他のオブジェクト(もしくは自分)
にメッセージを送ることによって処理を進める。これを図5.7に示す。
注意しなければならないことは、オブジェクト指向に基づく設計とオブジェクト指向
をサポートした言語による実装とを区別しなければならないことである。例えば、シス
テムを設計する時に、オブジェクト指向による設計を行っても必ずしもオブジェクト指
向をサポートした言語が必要なわけではない。設計したものを既存の言語にマッピング
することによって、これまでの手続き型言語等によって実装することが可能である。但
し、言語にオブジュクト指向をサポートする機能が備わっていれば、オブジェクト指向
の枠組を個別に作り込む必要がないので、効率の良い開発やデバグを行うことができる。
121
メッセージ
オブジェクト1
メッセージ
オブジェクト2
メッセージ
図5.7 オブジェクトとメッセージ
5.5.2 オブジェクト指向による実装のための言語処理系
オブジェクト指向は1980年代のSmalltalk-80 [85]の処理系から本格的な研究が行わ
れるようになった。Smalltalk-80では、オブジェクト、クラス、継承、メッセージ伝達
などの現在のオブジェクト指向の基本的な概念を含んでいる。クラスとは、オブジェク
トのテンプレート的なもので、クラスから個々のオブジェクトが動的に生成される。継
承とは、新たなクラスを定義する際に、既存のクラスの機能やデータ構造を引き継ぎ、
更に修正や追加を行うことである。Smalltalk-80では機能の抽象化のみに着目して単一
のクラスしか継承できない単一継承をサポートしていた。これに対し、Zetalispのオブ
ジェクト指向パッケージFlavor System [86]では、部品の集積という観点からいくつも
のクラスを継承できる多重継承が導入された。最近では、C言語にオブジェクト指向を
付加したC++ [87]、プラットホーム非依存の特徴があるJava [88]などの言語が使用さ
れている。C++は多重継承機能を提供し、Javaは、単一継承機能を提供する。
5.5.3 オブジェクト
オブジェクト指向では、オブジェクトはメソッドと呼ばれる手続きを持つ能動的なも
のである。オブジェクトは自分ないしは他のオブジェクトへメッセージを送信すること
ができ、それを受信したオブジェクトは、メッセージに対応してオブジェクト内で予め
定義されていた手続きを実行する。各オブジェクトは内部に状態を持つ。この状態を保
つオブジェクト内の変数をインスタンス変数と呼ぶ。また、メッセージに対応した手続
きをメソッドと呼ぶ。
122
クラス
ク ラ ス 変数
イ ン ス タン ス1
イ ン ス タン ス2
イ ン ス タン ス3
図 5 .8 ク ラ ス と イ ン ス タ ン ス
(1) クラス
インスタンスオブジェクトは、そのテンプレートであるクラスから動的に生成され
る。つまり、クラスは、それから生成されたオブジェクトの振舞いを決定する。但し、
それぞれの振舞いは、内部状態を保持するインスタンス変数に依存する。なお、クラ
スは、それから生成された全部のオブジェクトが共通にアクセスできる変数を持つこ
とができる。これは、クラス変数と呼ばれる。クラスとインスタンスの関係を図5.8
に示す。
(2) 継承
継承は、新たなクラスを定義する場合に、既存のクラスのメソッドや変数をそのま
ま利用できるようにするものである。これは、新たな機能を持つクラスをスクラッチ
から定義するのではなく、既存のクラスの機能をそのまま受け継いだ上に、新たな機
能を付加するという再利用を可能とする。あるクラスが継承をした上位のクラスをス
ーパクラスと呼ぶ。スーパクラスから見て、それを継承したクラスをサブクラスと呼
ぶ。オブジェクトはクラスからインスタンスを生成したものであるが、クラスによっ
ては、インスタンスを持たないものもある。このようなクラスを抽象クラスと呼ぶ。
オブジェクト指向をサポートする言語には、クラスが単一のスーパクラスしか継承で
きない単一継承と、複数のスーパクラスを継承することのできる多重継承とがある。
これを図5.9に示す。
クラスのインスタンス(実体)であるオブジェクトは任意の時点で動的に生成され
る。その際に、多重継承したそれぞれのクラスのメソッドを結合し、一つの統一され
たオブジェクトとして動作できるようにメソッド同士を結合する。
123
クラスA
クラスB
クラスB
クラスA
クラスC
クラスC
クラスD
クラスD
(a)単一継承
(b)多重継承
図5.9 継承
(3) メッセージ伝達
オブジェクト指向では、オブジェクトが別のオブジェクトや自オブジェクトへメッ
セージを送ることによって処理を進める。即ち、オブジェクトはメッセージを受け取
ることも送ることもできる。メッセージにはパラメータを付加することができる。メ
ッセージを受け取ったオブジェクトでは、それに対応するメソッドを実行するという
点において、メッセージ送信をプロセスの移動と考えることができる。オブジェクト
上では複数のメソッドを受信して、複数のメソッドを並列に実行することができる。
5.5.4 POM のパラダイム
POMモデルをオブジェクト指向の枠組にマッピングするにあたって、ここでは、次の
ようなパラダイムでネットワークをとらえる。即ち
「上位レイヤは下位レイヤの性質や機能を継承する。」
という立場を取る。
これまでのネットワークシステムでは、各レイヤは独立したものと考えられてきた。
レイヤはその内部を隠蔽するものであるが、レイヤ間の関係は対等なものである。従属
関係や部分集合の関係はない。ところが、上位レイヤから下位レイヤを眺めると、直前
の下位レイヤしか見えずに間接的にサービスを提供している。更に、下位のレイヤは直
前の下位レイヤに含まれている。これを継承関係に置き直せば、あたかも、上位レイヤ
が下位レイヤの性質や機能を継承しているようにとらえることができる。オブジェクト
指向は、このようなパラダイムに基づく設計に適合している。また、実装にオブジェク
ト指向を提供する言語を利用すると、さまざまな機構や言語の支援環境を利用すること
124
ができ、効率的な実装が可能となる。
上記のパラダイムは更に、2つの考え方に分けられる。第一は、最も下位のレイヤが、
その上のレイヤに継承され、それがまた更に次のレイヤに継承されるという考え方であ
る。第二は、各レイヤは、それ以下のレイヤの性質を直接継承するという考え方である。
5.5.5 レイヤクラスとコネクションクラス
POMモデルをオブジェクト指向の枠組みで実現する場合、まず、各レイヤのプロトコ
ルをオブジェクト指向のクラスで表現する。即ち、各プロトコルを一対一にクラスへマ
ッピングする。そして、コネクションをそれらの中から必要なクラスを選択して多重継
承したクラスとする。従って、本方式におけるクラスは、レイヤクラスとコネクション
クラスの二つに大きく分けられる。レイヤクラスとは、各レイヤに相当するクラスのこ
とであり、コネクションクラスとは、各コネクションに相当するクラスのことである。
コネクションモジュールは、コネクションクラスのインスタンスとして実現される。例
えば、図5.6では、各レイヤLとレジスタRの組がレイヤクラスとなり、コネクションC
がコネクションクラスへマッピングされる。なお、レイヤクラスは、インスタンスを持
たない抽象クラスである。
レイヤクラスで定義されたメソッドは、そのレイヤ固有のプロトコル処理を行うもの
であり、その処理対象であるバッファや状態を保持する変数は、インスタンス変数とし
て定義する。統計情報などの同一クラスのインスタンスから共通に使用される変数は、
クラス変数として定義される。アプリケーションは、通信に先立って適切なコネクショ
プロトコル
D
プロトコル
A
バッファ
プロトコル
C
プロトコル
D
プロトコル
バッファ
プロトコル
B
コネクションオブジェクト１
プロトコル
C
プロトコル
D
A’
A’
プロトコル
A
バッファ
プロトコル
B
プロトコル
C
コネクションオブジェクト2
プロトコル
B’
コネクションオブジェクト3
ディスパッチ
デーモンプロセス
パケット受信
図5.10 バージョンの異なるプロトコルの混在
125
ンクラスを選択し、インスタンスを生成する。なお、プロトコルソフトウェアを変更す
る場合には、既存のクラスを継承する新たなコネクションクラスを定義し、そのインス
タンスを生成することになる。このようにして、さまざまなバージョンが同一システム
内に混在可能となる。このオブジェクトの様子を図5.10に示す。
デーモンプロセスは、パケット受信の際に、そのパケットがどのコネクションに属す
ものかを決定し、対応するオブジェクトにメッセージを送る。また、イベント発生時に
も、対応するオブジェクトへメッセージを送る。そのため、コネクションに対応するイ
ンスタンス(オブジェクト)を保持しておかなければならないが、この目的にも、レイヤ
クラスのクラス変数を使用する。クラス変数への登録は、インスタンスの生成時に自動
的に行われるように、レイヤクラス定義のオプションとして指定しておく。これらの、
POMモデルとオブジェクト指向の枠組みとのマッピングを表5.1に示す。
表5.1 POMモデルとオブジェクト指向との対応
POMモデル
レイヤ
レイヤ内作業レジスタ
各レイヤの統計情報
コネクション
イベントの発生
オブジェクト指向
レイヤクラス(抽象クラス)
レイヤクラスのインスタンス
レイヤクラスのクラス変数
コネクションクラス(レイヤクラスを多重継承したクラス)
メッセージパッシング
5.5.6 プロトコルソフトウェアのカスタマイズ
次に、プロトコルレイヤの組み合わせの変更や、プロトコルレイヤ自体の変更をどの
ように行うかを説明する。新たなプロトコルレイヤの組み合わせが必要な場合には、既
存のクラス継承関係を変更し、必要なレイヤクラスを多重継承した新たなコネクション
クラスを定義すればよい。この変更が、すでに生成されているインスタンスへ影響を与
えることはない。
あるレイヤのプロトコルを変更する場合には、既存のレイヤクラスを直接変更する必
要はない。この場合には、まず、既存のレイヤクラスを継承した新たなレイヤクラスを
定義する。次に、変更する必要のあるメソッドだけを既存のメソッドと組み合わせて使
用したり、新たなメソッドを定義する。この新しいレイヤクラスを継承したコネクショ
ンクラスを定義すれば、変更されたプロトコルが使用可能となる。このように、オブジ
ェクト指向の持つメカニズムを利用することにより、容易にPOM実装モデルに基づいて
ネットワークシステムを実現することが出来る。
126
5.6 考察
ここでは、TCP/IPプロトコルを前提とし、POMモデルの柔軟性や拡張性について考察す
る。
5.6.1 2 つのクラス継承方式
POMは、プロトコルの特徴である階層性を考慮し、レイヤを一つのレイヤクラスとす
る。そして、それらを多重に継承することによってコネクションクラスを定義する。既
存のプロトコルソフトウェアの変更にあたっては、これらの既存のクラスを直接変更す
るのではなく、既存のクラスを継承する新たなクラスを定義する。その継承の方式は、
以下のように2つの方式が考えられる。
(1) 間接継承方式
間接継承方式は、レイヤとクラス階層を一対一に対応させた上で、上位プロトコル
レイヤは、下位プロトコルレイヤの性質を継承するものと考え、下位レイヤクラスを
スーパークラスとしてコネクションクラスを実現する方式である。図5.11に、この継
承関係を示す。これは木構造の継承関係を持っているが、それはレイヤの構造と上下
関係が逆になっているという特徴がある。
ここでは、TCP/IPプロトコル群を簡素化したものを例として示している。クラス名
にmixinがついているものはインスタンスを持たない抽象クラスである。まず、最上
位のスーパクラスとしてether-streamがある。これはリンクレイヤに対応するコネク
ションクラスであり、イーサネットを想定している。IPはether-streamとIP-mixin
とを多重継承したコネクションクラスである。IP-mixinは、IPの機能を定義したレイ
ヤクラスであり、インスタンスを持たない抽象クラスである。TCP-streamは、コネク
ションクラスであり、TCPプロトコルの機能を定義したレイヤクラスTCP-mixinとIP-
ether-stream
IP-stream-mixin
IP-stream
TCP-stream-mixin
TCP-stream
：レイヤクラス
：コネクションクラス
図5.11 間接継承
127
ether-stream
IP-stream-mixin
IP-stream
TCP-stream-mixin
TCP-stream
：レイヤクラス
：コネクションクラス
図5.12 直接継承
streamとを多重継承する。
なお、図5.11のクラスのうち、細枠で囲んであるのは、レイヤクラスであり、太枠
で囲んであるのは、コネクションクラスである。レイヤクラスは、インスタンスを持
たない抽象クラスである。
(2) 直接継承方式
もう一つの継承方式には、図5.12のように、各プロトコルに対応するクラスを部品
のように取り扱い、すべての必要なレイヤクラスを直接継承してコネクションクラス
を実現する方式である。この継承の方式は、くし型になっている。
直接継承方式では、必要なレイヤクラスを選択して部品として利用する。例えば、
コネクションクラスであるTCP-streamは、ether-stream、IP-mixin、そして、TCP-mixin
を多重継承する。このため、上位レイヤになるほど、継承するクラスの数が増加する
という特徴がある。
5.6.2 継承方式の考察
(1) 下位レイヤに対する変更の柔軟性
まず、スーパクラス、即ち、下位レイヤの変更や拡張に関する柔軟性について考察
する 。 ここ で 、 ether-stream をス ーパ ク ラス と して持 つ TCP-stream に 加え て 、
ether-stream'というリンクレイヤに対応するクラスをスーパクラスとして持つTCPstream'を新たに作成する場合を考える。ここで、ether-stream'は、ether-stream
とはまったく別に定義されたクラスであっても、ether-streamとの差分を規定したレ
イヤクラスether-stream-mixin'とether-streamとを多重継承するクラスであっても
構わない。
128
間接継承方式では、変更するスーパクラス、すなわちether-streamを継承している
すべてのサブクラスにわたって、それぞれのスーパークラスを変更しなければならな
い。例えば、図5.11の例で、ether-stream 'をTCP-stream 'まで継承させるためには、
IPについても、ether-stream-mixin'を継承したIP-stream 'という別のコネクション
クラスを作成する必要が生じてしまう。
一方、直接継承方式では、必要なレイヤクラスを選択して直接継承しているので、
間接継承方式のようなIP-stream 'という新たな中間のクラスを定義する必要がない。
単に、TCP-stream 'がether-streamの代わりにether-stream 'を継承するだけでよい。
(2) 上位レイヤに対する変更の柔軟性
次に、サブクラス、即ち、上位レイヤの変更や拡張を行う場合の柔軟性について考
察するため、TCP/IP上に、新たなアプリケーションプロトコルAPを作成する場合を想
定する。
間接継承方式では、アプリケーションプロトコルの機能を定義するレイヤクラス
AP-mixinを用意し、APでは、既存のクラスTCP-streamとAP-mixinを継承するだけで良
い。一方、直接継承方式では、APが使用するすべての下位プロトコルに対応するクラ
スをスーパクラスとして継承しなければならない。これは、間接継承方式で、上位レ
イヤの変更や拡張を行う場合には、それが利用するすべての下位レイヤ、即ち、すべ
てのスーパクラスについての知識が必要なことを意味する。
(3) 特性の比較
以上の議論から、スーパクラスに相当する下位レイヤの変更や拡張を行う際には、
直接継承方式が有利であり、サブクラスに相当する上位レイヤの変更や拡張を行う際
には、間接継承方式が有利であることが言える。
実際のプロトコルの開発においては、通常、下位レイヤが完成してから、その次の
上位レイヤへ実装を進めて行く手順を踏む。このため、サブクラス(上位レイヤ)の修
正がほとんどである。このことを考慮すると、実際には間接継承方式でも開発に支障
の出ることはない。表5.2にその有効性をまとめておく。
表5.2 適用範囲
継承方式
新規開発
間接継承
直接継承
○
×
上位イレヤのカス
タマイズ
○
×
下位レイヤのカス
タマイズ
×
○
129
5.6.3 プロセススイッチと並列処理
POMモデルでは、設計時にはレイヤごとにレイヤクラスを用意する。バーチャルサー
キットに対応するオブジェクトを生成するコネクションクラスは、利用するすべてのク
ラスを継承する。従って、一つのオブジェクト中にはすべてのレイヤが含まれる。そこ
で、処理の対象となるパケットを入れるバッファをスーパクラスとしてコネクションク
ラスで継承すると、このバッファは、オブジェクト中のすべてのレイヤによって共有さ
れる。そして、送信するパケットの処理はメッセージを上位レイヤから下位レイヤヘ送
ることによって進められる。但し、メッセージは自オブジェクトへ送られる。これを図
5.13 (a)に示す。
これは従来のLOMモデルがレイヤごとに別のオブジェクトを用意するのとは対照的で
ある。LOMでは、各オブジェクトごとにエージェントを持ち、独立してパケットの処理
を行う。そして、処理の終わったパケットは、キューを介して隣接するレイヤのオブジ
ェクトに渡す。このために必ずプロセススイッチが発生する。これに対し、POMモデル
のアーキテクチャでは、バッファはどのレイヤからでもアクセスできるので、上位レイ
ヤの処理が完了すれば、その処理を行っていたメソッドが下位レイヤへ直接メッセージ
パッシングを行う。つまり、キューを介することなくバッファを渡すことができ、プロ
セススイッチを発生させずに連続したプロトコル処理を行うことが可能である。従って、
プロセススイッチのオーバヘッドを減らすことができる。
また、POM のモデルでは、バッファが共有されるために、同一オブジェクト上の別の
メソッドが並行してバッファ上で処理を行うこともできる。例えば、ユーザがバッファ
にデータを入れているのと並行してパケットのヘッダを組み立てることができる。これ
を図 5.13 (b)に示す。但し、クリチカルセクションではバッファの排他制御を行う必
要がある。これに対し、従来方式では、あるパケットはそれが処理されているレイヤだ
けしかアクセスするこができない。これは、レイヤ全体で処理中のパケットに対する排
メッセージ
メッセージ
TCP
バッファ
ether
TCP
バッファ
ether
メッセージ
IP
IP
メッセージ
(a) プロセスス イッチなしの場合
(b) 並列処理
図5.13 プロセスとオブジェクトとの関係
130
他制御されていると考えることができる。あるレイヤがパケットを処理している時間を
排他制御の時間と見なせば、POM モデルでのパケットが排他制御される時間は、はるか
に短い。
5.7 言語への要求条件
POMによる設計は、多重継承やメッセージパッシングのような、オブジェクト指向の
一般的な概念や枠組みを利用する。このため、一般のオブジェクト指向をサポートした
言語で実装可能である。しかし、すでに述べたように、POMによる設計とその実装は別
のものであり、オブジュクト指向をサポートしていない言語でも実装可能である。その
場合には、多重継承、クラス、メッセージパッシングをエミュレートするマクロなどが
必要となる。
これまでに説明してきた枠組によって、POMでは、バッファ中のパケットを共有した
単一オブジェクト内で閉じた処理を行うことができる。その処理のパフォーマンスを向
上させるのは、以下のような並列処理の仕組が必要である。
(1) 同一オブジェクト上でマルチプロセスが走行する機能
オブジェクトへのメッセージパッシングは、オブジェクト上のメソッドへ制御を渡
すという点で、従来のOSにおけるプロセスディスパッチと等価である。ユーザがデー
タをアクセスしている最中にも、パケットの受信や送信の処理を行うなどの効率の良
い並行処理を行うためには、複数のメソッドが同時に走行する必要がある。
(2) セマフォなどのプロセス間の同期の手段
並列にメソッドを走行させる場合、それらがオブジェクト内のバッファに代表され
る同一資源をアクセスする可能性がある。このため、上記並列処理には排他制御の機
能が不可欠である。
5.8 むすび
本章では、まず、プロトコルの拡張および変更に対して柔軟なネットワークシステム
を実現するためのPOMモデルを提案した。POMモデルでは、バーチャルサーキットに沿っ
たソフトウェアのパスをモジュールの単位とする。
次に、このモデルが、オブジェクト指向の枠組みを用いて実現できることを示した。
そして、プロトコルの階層性に基づいてレイヤをレイヤクラスに対応させ、バーチャル
131
サーキットはレイヤクラスを多重継承したコネクションクラスに対応させれば良いこ
とを明らかにした。これは、上位レイヤは下位レイヤの性質や機能を継承するというパ
ラダイムに基づいている。
次に、POMでは、直接継承と間接継承の2つの継承方式があることを示した。前者では、
上位レイヤは利用するすべてのクラスレイヤをすべて直接に継承する。一方、後者は、
下位レイヤをスーパークラスとし、隣接する上位レイヤがその下位レイヤを継承する木
構造の継承関係を持つ。これは、レイヤの構造とは逆の構造である。プロトコルの変更
がこれらの継承関係にどのような影響を及ぼすかを検討した結果、下位レイヤの変更に
対しては前者の方式が向いており、上位レイヤの変更に対しては後者が向いていること
がわかった。最後に、パケットがすべてのレイヤで共有されることを示し、オブジェク
ト上でのプロセススイッチなしに複数のレイヤのプロトコル処理ができることを明ら
かにした。また、ユーザプロセスとシステムプロセスが同一パケットを並行処理できる
ためには、実装言語が同一オブジェクト上の並列メソッド実行や排他制御の機能が必要
であることを示した。
132
第 6 章 POM によるプロトコル実装
概要
第 5 章で述べた POM モデルの有効性を検証するために、記号処理計算機 ELIS 上のマル
チパラダイム言語 TAO のオブジェクト指向を使って、TCP/IP プロトコル群をサポート
するネットワークシステムを実装した。本章では、まず、記号処理計算機 ELIS の概要
とその上の言語 TAO について概要を説明する。次に、TAO/ELIS 上に構築したネットワ
ークシステムの概要について述べる。そして、そこで使用されているクラス階層につい
て説明する。このネットワークシステムの特徴は、TAO の I/O ストリームの基本となる
ストリームクラスを継承しているためにマイクロコードの速さで入出力処理ができる
こと、一つのオブジェクト上で複数のプロセスが走行して処理が行われることである。
次に、POM モデルをオブジェクト指向で実装するという妥当性を検証するため、メソッ
ドやインスタンス変数の継承率を調査する。そして、本モデルがオブジェクト指向の枠
組との親和性を持つことを明らかにする。また、ファイル転送中のネットワークカーネ
ルの CPU 使用率を観測し、少くとも、このモデルがシステムに著しいパフォーマンス低
下をもたらさないことを示す。
133
6.1 はじめに
第5章では、上位レイヤは下位レイヤの性質/機能を継承するというネットワークプロ
グラミングのパラダイムに基くパス指向実装モデルPOMを示した。また、POMのモデルが、
オブジェクト指向の枠組みを用いて実現できることを説明した。その場合、レイヤのプ
ロトコルをレイヤクラスに対応させ、バーチャルサーキットについてはレイヤクラスを
多重継承したコネクションクラスに対応させる。
本章では、記号処理計算機TAO/ELIS[89][90][91][92]上で実装したオブジェクト指向
によるネットワークシステム[81][82]について説明し、POMモデルの有効性を検証する。
実装したプロトコルは、インターネットで使用されているTCP/IPプロトコル群[3]であ
る。ここでは、まず、本ネットワークシステムを実装した記号処理計算機ELISとその上
のマルチパラダイム言語TAOについて概要を説明する。次に、TAO/ELIS上に構築したネ
ットワークシステムの概要について述べる。そして、そこで使用されているクラス階層
について説明する。このネットワークシステムの特徴は、TAOのI/Oストリームの基本と
なるストリームクラスを継承しているためにマイクロコードの速さで入出力処理がで
きること、および、一つのオブジェクト上で複数のプロセスが走行して処理が行われる
ことである。最後に、POMモデルをオブジェクト指向で実装するという妥当性を検証す
るため、メソッドやインスタンス変数の継承率を調査する。そして、本モデルがオブジ
ェクト指向の枠組との親和性を持つことを明らかにする。また、ファイル転送中のネッ
トワークカーネルのCPU使用率を観測し、少くとも、このモデルがシステムに著しいパ
フォーマンス低下をもたらさないことを示す。
6.2 記号処理計算機 TAO/ELIS
本節では、ネットワークを実装するプラットホームとなった、LispマシンELISとその
上のマルチパラダイム言語TAOについて説明する。これらを総称して記号処理計算機
TAO/ELISと呼ぶ。
6.2.1 Lisp マシン ELIS
最初のELISは、1980年代にブレッドボードでTTL論理回路を用いて試作され、フロン
トエンドとしてPDP-11を使用したTTL-ELISが開発された[89]。また、その後、CPUをVLSI
化したVLSI-ELISが開発された。これらは、システムソフトウェアや人工知能のような
アプリケーションプログラム開発、プログラミング環境[91]の研究に使用された。その
後、ELISのエミュレータがFreeBSDのOS上で開発され、現在では、FreeBSDやLinux上で
TAO/ELISが動作するようになっている[92]。このELISエミュレータはC言語で書かれて
134
いるために、CELISと呼ばれる。エミュレータであっても、CELISはマイクロコードで書
かれたTAOの核をそのままCに変換してしまうので、十分な処理能力を確保している。例
えば、同一ホスト上で走行する代表的なLisp処理系であるGNU Common Lisp (GCL)の1/4
程度までしか速度は劣化しない。また、従来のELISと比較した場合、AMD社のAthlon
1900+ (1.6Ghzクロック)上で、10倍以上の速度で動く。本章で説明するネットワークシ
ステムは、いずれのシステム上でも動作するように実装されている。
ここでELISのアーキテクチャ[89]について簡単に説明しておく。図6.1にELISのアー
キテクチャを、表6.1に、TTL-ELIS、VLSI-ELIS、CELISの諸元を示す。ELISは、マイク
ロプログラムの分岐を可能とするタグアーキテクチャのLISPマシンである。マイクロプ
ログラム命令の最上位の1byteがタグとなっており、256方向までの分岐ができる。シス
テムは、CPU、マイクロコードを収める Writable Control Storage (WCS)、メインメモ
リ、高速な操作のできるハードウェアスタック等から構成される。Stack Pointer (SP)
はスタックポインタ、Stack Top Register (STR)はスタックトップをコピーするレジス
タである。また、一度のメモリアクセスでセル全体を読み出せる64ビット幅のバス、読
み出したセル内のアドレスをレジスタ間でコピーすることなくアドレスバスに出力で
きるメモリ汎用レジスタMemory General Register (MGR)などを持つ。MGRは64bit長で、
それぞれ32bit長のLISPセルのCAR部とCDR部が入る。Source Destination Counter (SDC)
はMGRの任意のバイト位置を指すことのできるインデクスレジスタである。これらの機
能によって高速なLispの実行や柔軟なマイクロプログラム開発などが可能となってい
る。これら以外に、ネットワークやディスク等の外部インタフェース制御を受持つFront
End Processor (FEP)が外部に接続される。
32
A-BUS
MGR
CAR3
CAR2
CAR1
CAR0
CDR3
CDR2
CDR1
SDC3
SDC2
SDC1
SP3
SP2
SP1
STR3
PSW0
STR2
STR1
CDR0
ALU
PSW1
Register
File
ACR
SBR
Shifter
Y-BUS
Path
Control
32
64
EMIT
Data
Path
Control
Stack
YBR
Main Memory
Sequencer
Micro Instruction Data
Micro Instruction Address
図6.1 ELISのアーキテクチャ
135
表6.1 ELISの諸元
TTL-ELIS
プロセッサ内部バス幅
内部レジスタ
メモリ汎用レジスタ
ソース先行カウンタ
スタックポインタ
スタック
32bit
32ワード(32bit)
4(各64bit)
3(各5bit)
3(各14bit)
16Kワード(32bit幅)
WCS & 16Kワード(64bit
幅)
16Kワード(64bit幅)
マシンサイクル
制御方式
180nsec(可変)
マイクロプログラム
CPU
Am2903 * 8
メモリアドレス形式
バイトアドレス
64bit
8Mbyte
380nsec
550nsec
なし
メモリ読み出し幅
メモリ最大実装容量
メモリアクセスタイム
メモリサイクルタイム
仮想空間
VLSI-ELIS
CELIS
(エミュレータ)
32bit
同左
32ワード(32bit)
同左
4(各64bit)
同左
3(各6/5bit)
同左
3(各16bit)
同左
最 大 32K ワ ー ド 同左
(32bit幅)
最 大 64K ワ ー ド 静的コード変換によ
(64bit幅)
るエミュレーション
60nsec
ホストに依存する
マイクロプログラム 静的コード変換によ
るエミュレーション
CMOS セ ミ カ ス タ ム エミュレーション
20KゲートVLSI
バイトアドレス
バイトアドレス
64bit
ホストCPU依存
128Mbyte
128Mbyte
360nsec
ホストに依存する
720nsec
ホストに依存する
16Gbyte
なし
(64bitワード)
6.2.2 マルチパラダイム言語 TAO
(1) TAOの特徴
ELIS上の言語TAO[90]は、対象となるプログラムにあったパラダイムを利用者が選
択でき、しかも、それが一つの言語上で記述できるようにしたマルチパラダイム言語
である。この核の部分はマイクロプラグラムで記述されており、WCSに収められてい
る。TAOは、手続き型、論理型、オブジェクト指向をサポートする実用的な人工知能
向きプログラミング言語として開発された。また、TAOは、インタプリタの性能を重
視したLisp処理系を基本とし、1000以上の基本関数のうち半数をマイクロコード化し
ている。更に、並行プログラムとマルチユーザをサポートしている。このため、セマ
フォなどのプロセスの同期や排他制御、プロセスへの割り込みなど、基本的なマルチ
プログラミングのための機能を提供する。走行させることのできるプロセス数は、シ
ステム全体で128個である。
136
(2) TAOのオブジェクト指向
TAOは、ZetaLispのオブジェクト指向パッケージであるFlavours [86]を仕様のベー
スとしている。インタプリタの核でオブジェクト指向を組み込んでいるため、他のパ
ラダイムとの融合がなされながらも高速な実行が可能である。
(i) クラスとインスタンス
クラスは、オブジェクトを生成するテンプレートである。つまり、オブジェクト
はどれかのクラスのインスタンスになっている。個々のオブジェクト内部の変数は
インスタンス変数と呼ばれ、同じクラスのインスタンスから共通にアクセスできる
共有変数はクラス変数と呼ばれる。各オブジェクトは、名前を持つ手続きであるメ
ソッドを持っており、このメソッドは関数と同様に値を返す。インスタンス変数な
どの内部の変数は外部から直接アクセスできず、メソッドを通じてのみ変更される。
クラスの定義は、以下のように行う。ここで、class-nameはクラス名、classvariablesはクラス変数のリスト、instance-variablesはインスタンス変数のリス
ト、super-class-listは継承するクラス名4である。TAOは多重継承をサポートして
おり、その場合には、super-class-listは継承するクラスの名前のリストになる。
また、継承するクラスがない場合には、省略される。defclass-optionは、このク
ラスのいろいろなオプション機能を指定する。
(defclass class-name
(class-variables)
(instance-variables)
{super-class-list}
defclass-option)
以下は、メソッドの定義である。class-nameは、このメソッドを定義するクラス
の名前、method-conbination-typeは後述するメソッド結合を指定するオプション
であり、省略できる。selectorはメソッド(メッセージ)の名前、argument-listは、
このクラスのインスタンスであるオブジェクトへメッセージを送る時の引数、そし
て、formではメソッドのプログラムを指定する。
4
継承される側のクラスをスーパークラス、それを継承する側のクラスをサブクラスと呼ぶ。
137
(defmenthod (class-name {method-conbination-type} selector)
argument-list
form ...)
インスタンスは、以下のように生成される。class-nameはクラス名であり、initoptionには、インスタンスを生成した時にインスタンス変数に設定する値を指定す
る。
(make-instance class-name init-option ...)
(ii) メッセージ伝達式
オブジェクト指向では、オブジェクトにメッセージを送信することによって処理
を進める。メッセージとはメソッド名と引数のリストである。その式は、以下に示
すように、まずこのメッセージを受信すべきオブジェクト名(object)、メッセージ
名(message-name)、そして引数(argument)の順序になる。TAOのメッセージ伝達式
は、[ ]を用いたS式である。しかし、リスト形式で()を使用することもできる。
[object message-name argument]
6.3 TAO/ELIS のネットワークシステム
6.3.1 特徴
記号処理計算機TAO/ELISにおけるネットワークの実装[81][82]の目的は、(1) オブジ
ェクト指向によってPOMの実装方式を検証すること、そして、(2)オブジェクト指向のリ
アルタイムシステムへの適用性を検証することである。ネットワークの実装にあたって
は、以下のような特徴を備えることを目標としている。
(1) 柔軟性
第5章で説明したように、POMモデルに基づく実装は、探索的なプロトコルの開発を
可能とする。従来のネットワークソフトウェアは、各レイヤのプロトコルに一対一に
対応するモジュールから構成されていたため、新旧のプロトコルが同一システム内に
混在することができなかった。TAO/ELISでは、各レイヤのプロトコルに対応するモジ
ュールがクラスとして定義されている。このため、既存のレイヤクラスに代って新た
138
なレイヤクラスを定義し、それを継承するコネクションクラスを追加することで、変
更したプロトコルも既存のプロトコル同様に使用できる。各コネクション(バーチャ
ルサーキット)が独立したオブジェクトとなっているため、たとえ、新たなクラスを
継承したコネクションで障害が発生しても、それが既存のコネクションに波及するこ
とはない。
(2) アクセス方式の一貫性
従来、ネットワークのアプリケーションインターフェースは、ファイル等のアクセ
ス方式とはまったく別のインタフェースを持っていた。例えば、UNIXオペレーティン
グシステムのように、ファイルの場合には、ファイルディスクリプタ、ネットワーク
の場合にはソケット等を使用している[93]。これに対し、TAO/ELISでは、ネットワー
クをアクセスする場合にも、ファイルなどの他の入出力とまったく同じ共通のアクセ
ス方法を提供する。これは、TAOの汎用ストリームをネットワークストリームが継承
することによって実現される。これにより、プログラマは、デバイスごとの個々のア
クセス法を意識する必要がない。
(3) ネットワークプログラムインタフェースの簡素化
UNIXオペレーティングシステムでは、アプリケーションプログラムが、通信の前に
複雑な呼び出し手順を実行しなければならない[94]。例えば、TCPプロトコルを使用
する場合には、まずソケットを用意し、次に、そのソケットをアクセスポイントに結
合し、更にソケットへの受信を可能としたあと、相手からの接続要求を待つ。これに
加え、ローカルホストがリモートホストからの通信開始要求(バーチャルサーキット
の設定)を待つ場合と、ローカルホストから通信を開始する場合では、異なる手順で
ソケットの設定を行わなければならない。これに対し、TAO/ELISでは,ファイルスト
リームの場合と同様にストリームをオープンするという処理だけで通信を行うこと
ができる。
6.3.2 TAO/ELIS のプロトコルスタック
TAO/ELIS上のネットワークシステムで実装されているプロトコルのスタックを図6.2に
示す。TCP/IPプロトコル群は、インターネットで使用され、UNIXをはじめとする、さま
ざまなコンピュータ上でインプリメントされたことから、事実上の標準として広く使用
されている。
139
FTP
telnet
SMTP
NNTP
DNS
X-window
finger, whois, rshなど
NFS, SNMPなど
UDP
TCP
ARP
IP
ethernet
シリアル回線
図6.2 TAO/ELISのプロトコルスタック
(1) リンクレイヤ
リンクレイヤとして、TAO/ELISではイーサネットやシリアル回線などをサポートし
ている。但し、ELISは、入出力のためのハードウェアを持たず、イーサネットインタ
フェースなどの制御やパケットの送信受信などはFEP上で動くリアルタイムモニタ
(FEP OS)を介して行う。FEP側では、ELIS側からコマンドを受信し、イーサネットイ
ンタフェースのオープン、クローズ、ELIS本体との送受信パケットのコピーを行う。
(2) ネットワークレイヤ
ネットワークレイヤでは、IPプロトコルをサポートしている。また、ネットワーク
レイヤそのものではないが、IPアドレスをリンクレイヤのイーサネットアドレスに動
的に変換するためのAddress Resolution Protocol (ARP)[95]も実装している。この
レイヤでは、IPデータグラムの転送先アドレスを見て、次にそれを渡すべきルータを
決定し、そこへパケットを送るという処理を行う。
(3) トランスポートレイヤ
トランスポートレイヤでは、TCP [10]とUDP [13]をサポートしている。前者は、再
転送によってエラーからの回復を行い、アプリケーションに対し、エラーのない仮想
的な伝送路(バーチャルサーキット)を提供する。一方、UDPは、コネクションレスの
転送サービスを提供する。UDPではエラーからの回復を行わず、それはアプリケーシ
ョンに任される。POMモデルでは、UDPの場合も、TCPと同様にバーチャルサーキット
が設定されるものと考え、通信前にインスタンスの生成とオブジェクトの初期化を行
う。
(4) アプリケーションレイヤ
アプリケーションレイヤでは、遠隔ホストへのアクセスを提供するtelnet [15]、
140
ファイル転送サービスを提供するFTP [16]、電子メールの転送を行うSMTP [17]、電
子ニュースの転送を行うNetwork News Transfer Protocol (NNTP)、ウィンドウシス
テムであるX-window等をサポートしている。また、これら以外にTCPを使用するもの
として、遠隔ホストでコマンドを実行するためのremote shell (rsh)プロトコル、遠
隔ホストを使用中の人を知るためのremote who (rwho)プロトコル、UNIXオペレーテ
ィングシステム独自の遠隔ログイン用プロトコルrlogin、遠隔ホストを使用中してい
るユーザの状態を知るためのfingerプロトコルを実装している。一方、UDPを使用す
るものとして、ネットワーク管理を行うSimple Network Management Protocol (SNMP)
やファイル共有を行うNetwork File System / eXternal Data Representation (NFS /
XDR) [96][97]などを実装している。
6.3.3 クラス階層
TAO/ELISでは、上位レイヤは下位レイヤの性質や機能を継承するというパラダイムの
下に、POMの間接継承に基づく実装を行っている。POMでは、バーチャルサーキットに沿
ったソフトウェアモジュールのパスをモジュールの単位と考え、それをオブジェクトと
する。
図6.3に、クラス階層を示す。アプリケーションレイヤを除き、TCPレイヤ以下のネッ
トワークカーネルをPOMに基づいて実装している。これらのクラスのうち、各レイヤの
プロトコルに相当するレイヤクラスは、インスタンスを持たない抽象クラスである。一
方、コネクションクラスは、レイヤクラスを多重継承し、インタスンスを持つ。表6.2
に、それぞれのクラス名と機能をまとめておく。
表6.2 各クラスの機能
クラス名
fundamental-stream
ether-stream-mixin
ether-stream
ip-stream-mixin
ip-stream
tcp-stream-mixin
tcp-stream
udp-stream-mixin
udp-stream
telnet-stream-mixin
telnet-server-stream
telnet-client-stream
機能
TAOの入出力ストリームのクラス
イーサネットのアクセスプロトコルを定義する抽象クラス
イーサネットの入出力ストリーム
IPのプロトコルとデータ構造を定義する抽象クラス
IPの入出力ストリーム
TCPのプロトコルとデータ構造を定義する抽象クラス
TCPの入出力ストリーム
UDPのプロトコルとデータ構造を定義する抽象クラス
UDPの入出力ストリーム
UDPのプロトコルとデータ構造を定義する抽象クラス
telnetサーバの入出力ストリーム
telnetクライアントの入出力ストリーム
141
fundamental-stream
ether-stream-mixin
IP-stream-mixin
ether-stream
ARP-mixin
UDP-stream-mixin
IP-stream
ARP
UDP-stream
FEP-mixin
TCP-stream-mixin
TCP-stream
telnet-server-stream
telnet-stream-mixin
telnet-client-stream
: レイヤクラス
: コネクションクラス
図6.3 TAO/ELISにおけるネットワークのクラス階層
(1) fundamental-stream
最も上位のスーパクラスであり、TAO/ELISの基本的な入出力のストリームのクラス
である。このクラスを継承することによって、マイクロコード化されたTAOの入出力
関数が、ネットワークのアクセスにも使用できる。このため、ストリームアクセスの
オーバヘッドを、TAO (Lisp)のS式で記述した場合に比較してはるかに小さく押える
ことができる。また、このクラスを継承することによって、ネットワークストームを
ネットワーク以外の入出力のストリームとまったく同一の方法でアクセスすること
が可能となる。
(2) ether-stream-mixinとether-stream
ether-stream-mixinは、リンクレイヤであるイーサネットのサービスを上位レイヤ
に提供するクラスであり、これ単独ではオブジェクトを持たない抽象クラスである。
オブジェクトを持つのは、fundamental-streamとether-stream-mixinを多重継承した
142
ether-streamである。ether-stream-mixinでは、受信したイーサネットパケットのヘ
ッダ処理と適切な上位プロトコルへの分配、および、送信するイーサネットパケット
のヘッダ組み立て等が定義されている。これを継承すれば、イーサネットのパケット
の送信や受信ができる。例えば、イーサネットアドレスとIPアドレスの対応を取るた
めのプロトコルARPは、イーサネット上で動くので、それに対応するクラスARPではARP
のプロトコル処理を行うarp-mixinとether-streamとを多重継承している。
(3) ip-stream-mixinとip-stream
ip-stream-mixinは、パケットをエンドノード間で中継するIPプロトコルのサービ
スを定義した抽象クラスである。このクラスは、パケットのIPヘッダ部分を完成して
送り出したり、受信したパケットのヘッダが損傷を受けていないかどうかをヘッダの
チャックサムを計算することによって判断する。そして、損傷を受けている場合には、
それを破棄する。更に、受信したパケットを上位のプロトコルのクラスへ分配する。
なお、実際に上位レイヤに対してサービスを提供するip-streamは、ip-stream-mixin
とether-streamを多重継承したものである。
(4) tcp-stream-mixinとtcp-stream
tcp-stream-mixinは、TCPプロトコルのサービスを定義する抽象クラスである。TCP
プロトコルはコネクション指向のプロトコルで、通信を行う前にコネクションの確立
(バーチャルサーキットの設定)を行う。また、再転送による誤りからの回復や、アプ
リケーションプロセスごとに独立したバーチャルサーキットを提供するための多重
化機能を定義している。tcp-streamは、このtcp-stream-mixinとip-streamを多重継
承している。
(5) UDP-stream-mixinとUDP-stream
udp-stream-mixinは、プロセスごとの独立したサーキットを定義している。TCPと
異なり、UDPプロトコルでは、誤りの回復やコネクションの確立を行わない。udpstreamは、このudp-stream-mixinとip-streamを多重継承している。なお、UDPはコネ
クションレスであるが、TAO/ELISのオブジェクト指向による実装では、udp-stream
もtcp-stream同様、最初の通信を行う前に仮想的にコネクションを確立するものと考
える。これによって、UDPに対しても、TCPと同様の実装が可能となる。
fundamental-stream以外については、TCP/IPのプロトコルレイヤとクラスがほぼ一
143
対一に対応しているため、きわめて簡単で明解な構造となっている。特殊なクラス継
承は、telnet-server-streamのスーバークラスの一つであるfep-mixinである。telnet
サーバは、実端末からログインする場合と全く同じように、ネットワークからELIS
へのログインを可能とする。ただし、実端末の場合には、FEP側で、フロー制御、割
り込みコードの処理、コード変換などのいくつかの処理を行っている。このFEPをシ
ミュレートするのがfep-mixinである。
6.3.4 プロセスとオブジェクトとの関係
ここでは、TAO/ELISのネットワークシステムがどのようにして動作するのかを、プロ
セスとオブジェクトとの関係を中心として説明する。
(1) LOMモデルとPOMモデルにおけるオブジェクトとプロセスの関係
第5章で説明した、従来のネットワークシステムの実装方式LOMでは、レイヤごとに
オブジェクトがある。各オブジェクト上では、それぞれ一つのプロセスしか走行しな
い。そして、オブジェクトである各レイヤは、すべてのパケットの処理を行う。その
オブジェクトは、パケットの処理が完了すると、次にそれを処理すべきオブジェクト
の入力キューに入れる。キューにより、パケットの処理はシリアライズされる。この
Single-Process on Single-Objectによる処理の様子を図6.4に示す。
オブジェクト
プロセス
オブジェクト
プロセス
オブジェクト
プロセス
レイヤn+1
レイヤn
レイヤn-1
図6.4 単一オブジェクト上の単一プロセス
144
これに対し、本方式では、個々のコネクションがそれぞれオブジェクトとして実現
されるため、オブジェクトは、コネクションの数だけシステム内に存在する。また、
各コネクションオブジェクトは、自分のバッファが処理されるべき全レイヤについて
のメソッドを持っている。これらのメソッドは、デーモンプロセスによって、パケッ
ト受信等のイベントの発生時に呼び出される。これに加え、ユーザプロセスからのバ
ッファのアクセス等が非同期に発生するため、一つのオブジェクト上で、同時にいく
つかの処理が行われる。この Multi-Process on Single-Objectの様子を次に詳しく
説明する。
(2) POMモデルにおける単一オブジェクト上の多重プロセス
ここでは、tcp-streamの例で単一オブジェクト上の多重プロセスを具体的に説明す
る。図6.5は、バーチャルサーキットに相当するtcp-streamのインスタンス(オブジェ
クト)とプロセスとの関係を示している。ユーザプロセスは、このtcp-streamオブジ
ェクトに対するreadあるいはwriteメッセージでデータを読み書きする。
TCP のデーモンプロセスは、二つ存在する。一つは再転送のタイマを管理する
tcp-out-daemonであり、もう一つはそれぞれのtcp-stream オブジェクトの状態に応
じてそのオブジェクトへメッセージを送り、受け取ったパケットに対する処理を起動
するtcp-in-daemonである。tcp-out-daemon は、タイマの管理を行い、一定時間ごと
ユーザ
プロセス
write
read
入力
ストリーム
ユーザ
プロセス
ユーザ
プロセス
出力
ストリーム
read
入力
ストリーム
write
write
read
出力
ストリーム
入力
ストリーム
出力
ストリーム
received
syn-sent
established
received
received
TCP-in-daemon
closing
tick
tick
tick
TCP-out-daemon
図6.5 POMモデルにおける単一オブジェクト上の多重プロセス
145
にタイマのインクリメントを行うようにtickメッセージを送る。タイムアウトの検出
は各tcp-stream オブジェクトのメソッドによって行われ、タイムアウトを検出する
と、当該オブジェクトはパケットを再転送する。つまり、tcp-out-daemonは、タイマ
の起動のためのメッセージパッシングしか行わない。一方、tcp-in-daemonは、パケ
ットの到着などの事象の発生を検出して、そのパケットを処理すべきtcp-stream オ
ブジェクトへメッセージを送り、そのオブジェクトの状態に応じたメソッドを起動す
る。すなわち、tcp-in-daemonは、ディスパッチャとしての機能を果たす。
これら二つのプロセス加えて、ユーザプロセスも、同時に、同一のオブジェクト上
を走行する。これは、ユーザがtcp-stream オブジェクトに対してデータの書き込み
を行った場合や、ストリームからデータを読み出した場合に発生する。このように、
複数のデーモンプロセスおよびユーザプロセスは、非同期に発生し、独立して同じユ
ーザストリームにメッセージを送る。このため、同じオブジェクト上で、複数のプロ
セスが同時走行することになる。
デーモンプロセスと、tcp-stream オブジェクトとの通信は、原則的に、クラスの
各インスタンスから共通にアクセス出来るクラス変数を頼りに行われる。クラス変数
は、オブジェクトに直接メッセージを送る必要がある場合には、ユーザストリームID
とユーザストリーム（オブジェクト）自身の連想リストである。また、メールボック
スを通じて通信する場合には、ユーザストリームIDとメールボックスの連想リスト使
用される。この連想リストへの登録は、ユーザストリームのインスタンス生成時にTAO
の defclass オ プ シ ョ ン で あ る イ ン ス タ ン ス 生 成 時 実 行 機 能 (:eval-wheninstantiation)によって自動的に行われる。これらのプロセスは、同じインスタンス
変数をアクセスするので、必要に応じてセマフォを使用したり、割り込み禁止で走行
させることにより、排他制御を行う。
6.3.5 状態還移とメッセージパッシング
プロトコルの動作は、プロセスの状態とそれら状態間の還移を引き起こす事象により
規定される。6.3.4項 (2)で述べたように、tcp-stream オブジェクトは、還移を引き起
こす可能性のある事象を検出したtcp-in-daemonデーモンによって起動される。例えば、
あるユーザあてのパケットの到着は、還移を引き起こす可能性のある事象なので、デー
モンプロセスは、該当するtcp-stream オブジェクトへメッセージを送る。このとき、
tcp-stream オブジェクトの状態に応じたメソッドを起動しなければならない。この処
理を簡単にするため、ユーザストリームの状態名とその状態にあるときに起動しなけれ
ばならないメソッド名（正確にはメソッドセレクタ）に同じ名前を使用する。すなわち、
ユーザストリームは、インスタンス変数に自分の状態の名前を入れておき、デーモンは、
この変数を参照して、ユーザストリームに対して、名前そのものをメッセージとして送
146
る。図6.5において、tcp-stream オブジェクトが自分自身へ送るメッセージestablished、
syn-sent、closingは、そのようなメッセージである。
パケットの処理や、状態還移は、すべてtcp-stream オブジェクト側で行われる。例
えば、コネクションがすでに確立されている場合には、まず、送られてきたパケットの
シーケンス番号をチェックし、重複したパケットや不連続なパケット以外であれば、そ
のパケットを正しく受信した旨を示すACK(確認応答)パケットを転送する。次に、再転
送キューにいれられていたパケットのうち、リモートホストで受信が確認されたパケッ
トを回収する。さらに、パケットが制御情報を含むときには、状態名を格納しておくイ
ンスタンス変数を次の状態名に変更する。これにより、状態還移が起こり、次のパケッ
トが到着した時には、その状態に応じた適切なメソッドが起動されることになる。
6.4 評価
この節では、メソッドやインスタンス変数の継承率を実測することによって、POMに
基づくネットワークシステムがオブジェクト指向で無理なく実装できていることを示
す。また、通信中のCPUオーバヘッドを実測することによって、この実装方式がシステ
ムに著しいパフォーマンス低下をもたらすものではないことを明らかにする。
6.4.1 プログラム規模
本プログラムは、FEP上のイーサネットドライバを除き、すべてS式で記述されており、
その規模は、TCP/IPのネットワークカーネルとFTPやtelnet等の基本的なアプリケーシ
ョンを合計して約1万3千行である。ただし、これに加え、パフォーマンス向上のため、
チェックサム演算などの若干の関数をマイクロコード化している。
6.4.2 POM のオブジェクト指向との適合性
POMの実装がオブジェクト指向の枠組とどの程度の親和性を持つのかを調査するため、
TAO/ELIS上でネットワークプログラムを使用後、クラスやメソッドの継承の度合を調査
した。これを表6.3に示す。なお、比較のため、TAO/ELIS上でオブジェクト指向を使用
して作成されたエディタZenについて調査した値も示した。
147
表6.3 クラスやメソッドの継承度
調査項目
プログラム行数
インスタンスを持つクラス
インスタンスを持たない抽象クラス
メソッド総数
実際に起動されたメソッド総数
プログラム中のdefmethod数
継承で作られたメソッド総数
メソッド継承率
ネットワークNet
12654
11
10
667
218 (33%)
154
513
0.77
エディタZen (参考)
18386
24
13
5569
750 (13%)
453
5516
0.92
POMに基づいて実装したTAO/ELISのネットワークでは、抽象クラス、即ち、レイヤクラ
スが10個あり、それらを継承して実際にオブジェクトが生成されるコネクションのクラ
スが11個あることがわかる。TAOのオブジェクト指向では、クラスを継承するごとにそ
のメソッドがコピーされる。このため、プログラム中のdefmethod数が154であるのに対
し、メソッドの総数は667となっている。実際に起動されたメソッド総数の割合は、起
動されたメソッド数が218で、メソッド総数が667なので33%である。エディタのほうが
13%と低い理由は、エディタには多数のユティリティが用意されており、使用される割
合が低くなっていると考えられる。これに比較してネットワークカーネルのほうは、パ
ケットが処理されるパス上にあるメソッドが多く、これらはユーザが利用を選択できる
オプションではないので、割合は相対的に大きい。
メソッド継承率は、メソッド総数のうちスーパークラスを継承してメソッド総数の割
合であり、継承されているメソッドが多いほど1に近くなる。ネットワークの場合、こ
の割合が77%となっており、POMのベースとなっている、上位レイヤは下位レイヤの性質
や機能を継承するというパラダイムが無理のないものであることが実証された。これは、
表6.4のインスタンス変数の継承率からも検証できる。この継承率は、各クラスのイン
スタンス変数の個数を合計したもののうち、スーパークラスから継承してきたインスタ
ンス変数の個数が占める割合であり、継承がないとき0、インスタンス変数が全部継承
したものの時(即ち、自分で定義せずに全部が継承したものである時)に1となる。表6.4
では、これが87%となっている。これは、POMが無理なくオブジェクト指向で実装できた
ことを示している。
表6.4 インスタンス変数の継承率
ネットワークNet
クラス総数
21
抽象クラスまたはインスタンスのない 10
クラス
インスタンスの平均サイズ
51
インスタンス変数継承率
440/508=0.87
エディタZen
37
13
112
1294/1457=0.89
148
6.4.3 オーバヘッドの評価
本ネットワークシステムによって実現したFTP（ファイル転送プログラム）の転送ス
ピードは、10Mbpsのイーサネットを使用したオリジナルのELISで30Kbyte/sec前後であ
った。この速度は、同一マシン上でのファイルコピーの速度とオーダが一致している。
このため、FEPのファイル入出力やネットワーク入出力、FEPとELISを結ぶチャネルの速
度等で制限されていると考えられる。
また、CELISにおいてファイル転送を行い、速度と各プロセスのCPU消費量を計測した。
計測に使用したcelisは、Athlon 1900+ (1.6Ghzクロック)上で動作するものであり、相
手側のホストは、FreeBSD OSを塔載したPentium III 800MHzのPCである。これらを
100Mbpsのイーサネットで接続した。その計測結果を図6.6に示す。
celisからのファイル転送速度は、バイナリファイルの場合で、1Mbyte/secであった。
また、celisへのファイル転送速度は、約1.6Mbyte/sec程度であった。ファイル転送中
にホストOSであるFreeBSDのCPU負荷と、ゲストOSであるcelisの負荷を計測した。その
結果、ネットワークカーネルが使用するCPU利用率は、受信したパケットの処理を行う
TCP-inのプロセスが20%から40%程度を使用し、イーサネットの受信処理を行うetherの
80%
ファイル転送中のホストOS
(FreeBSD)のC PU使用率
celis
その他
36%
ファイル転送中のcelis
上のCPU使用率
(ASCIIファイルのget)
2%
TCP-in
ether
20%
ファイル転送中のcelis
上のCPU使用率
(ASCIIファイルのput)
3%
TCP-in
ether
43%
ファイル転送中のcelis
上のCPU使用率
(バイナリ ファイルのget)
1.5%
TCP-in
ether
22%
ファイル転送中のcelis
上のCPU使用率
(バイナリ ファイルのput)
20%
3%
TCP-in
ether
図6.6 ファイル転送中のCPU使用率
149
プロセスが2から3%を使用することがわかった。このことから、少くともPOMモデルによ
って実装したネットワークカーネルがCPUに著しい負荷をかけてはいないと言うことが
できる。なお、TCP-inは受信したTCPパケット中のデータバイトごとにつけられた順序
番号をもとに再転送やフロー制御を行うため、その番号の計算にCPUが使用されている
ものと考えられる。送信するプロセスであるTCP-outの負荷は0に近く、受信に比較して
送信の処理が著しく軽い処理であることがわかる。
以上の測定によって、POMモデルに基く実装が、少なくともネットワークシステムの
性能を著しく低下させるものではないことが検証された。
6.4.4 方式の汎用性に関する考察
本ネットワークシステムを実現するにあたっては、多重継承やメソッドコンビネーシ
ョンのような、オブジェクト指向言語が一般的に持つ枠組みを利用した。この点では、
POMに基づく実装方式の実現性は高いと考えられる。しかし、システムのパフォーマン
スを低下させないためには、6.3.4項で説明したように、同一オブジェクト上でのマル
チプロセスが必要である。これに加え、独立したプロセスが、コネクションオブジェク
ト内のバッファに代表される同一資源をアクセスする可能性があるので、セマフォなど
の、従来のマルチプログラミングシステムの持っていた機能も同時に必要である。
デーモンプロセスによるコネクションオブジェクトへのメッセージパッシングは、コ
ネクションオブジェクトへ制御を渡すという点で、従来のOSにおけるプロセスディスパ
ッチと等価である。したがって、ネットワークシステムのようなマルチタスクリアルタ
イムシステムを実現するためには、メッセージパッシング後に、速やかなメソッドの起
動が必要である。並列オブジェクト指向言語の中には、同一オブジェクトへのメッセー
ジがシリアライズされ、単一オブジェクト上では単一プロセスの走行しか出来ないもの
もある。この場合、メソッドの起動が遅れてしまうため、パフォーマンスの低下は免れ
られない。
以上のことから、オブジェクト指向の継承という機能を生かしつつ、本実装モデルの
ようなパフォーマンスの要求されるリアルタイムシステムを実現するには、それを実現
するオブジェクト指向言語に、単一オブジェクト上で複数の排他制御や同期の機能が必
要であると言える。
6.4.5 実装上の問題点に関する考察
本実装方式で、TAO/ELIS上にネットワークを実現した場合の問題は、排他制御であっ
た。同一ストリームオブジェクト上で、ユーザの入出力プロセスといくつかのデーモン
プロセスとが同時に走行し、しかも、それらがバッファやバッファポインタ等の同一資
150
源を使用するので、クリティカルセクションが存在する。入出力プロセスとデーモンプ
ロセスとの排他制御の場合、デーモン側では、出来るだけ排他制御領域を小さくするよ
うに注意を払いながら、割り込み禁止状態で処理を行うよう設計した。これは、入出力
のマイクロコード内で、ネットワーク以外のストリームアクセスにもパフォーマンス低
下をもたらすような、ネットワークのための特別な排他制御を避けるためである。デー
モンプロセス同士の排他制御の場合には、比較的、排他制御の時間が長いため、割り込
み禁止状態で処理を行うのではなく、セマフォを使用した。
もう一つの問題は、サスペンドあるいはエラーによるデーモンプロセスの停止問題で
あった。デーモンプロセスは、多くのストリームオブジェクト上で処理を行う。このた
め、そのストリームオブジェクト上でプロセスがサスペンドする可能性のあるメソッド
を実行するデーモンプロセスのうち、処理対象となるストリームの数が少ない場合には
ストリームごとにデーモンプロセスを用意した。それ以外の場合には、デーモンプロセ
スが停止しないようにメソッドの設計を行い、さらに、エラーの発生時には、エラーを
発生したストリームだけを切り離して、その他のストリームへのサービスを再開するよ
うに、デーモンプロセス内にエラー処理ルーチンを用意した。
6.5 むすび
本章では、コネクションをモジュール単位とするパス指向型プロトコル実装モデル
POMがオブジェクト指向の枠組みを用いて用意に実現できることを、記号処理計算機
TAO/ELIS上のTCP/IPネットワークを実装することによって示した。本ネットワーク構成
上の主な特徴は、以下の三つである。
(1) プロトコルの特徴である階層性を考慮し、各プロトコルレイヤに対して、一つのク
ラスを対応させ、下位プロトコルレイヤをスーパークラスとしたオブジェクトとしてネ
ットワークストリームを定義した
(2) ネ ッ ト ワ ー ク ス ト リ ー ム が fundamental-stream を 継 承 し て い る た め 、 readchar,write-charなどのマイクロプログラムで書かれた関数が、直接適用可能である。
これにより高速なアクセスを可能とした。
(3) 本ネットワークシステムでは、イベントが発生すると、メッセージがストリームに
送られ、処理の起動が行われる。各レイヤにおけるイベントは非同期に発生するので、
単一オブジェクト上で多重プロセスが走行するシステムとなっている。
POMモデルをオブジェクト指向で実装するという妥当性を検証するため、メソッドやイ
151
ンスタンス変数の継承率を調査した。その結果、メソッドの継承率は77%、インスタン
ス変数の継承率は87%の結果を得、本モデルがオブジェクト指向の枠組との親和性を持
つことが明らかになった。また、ファイル転送中のネットワークカーネルのCPU使用率
を観測し、その割合が20%から40%程度であり、少くとも、このモデルがシステムに著し
いパフォーマンス低下をもたらさないことを検証した。
152
第 7 章 本研究の結論と今後の課題
本研究では、エンドツーエンドの超高速データ通信向きリンクプロトコル群の要件を
明らかにし、データ転送プロトコルとネットワーク制御プロトコルの両方を含む体系的
なプロトコル群として MAPOS の開発を行なった。そして、それをスイッチおよびホスト
インタフェースに実装し、本プロトコルおよびアルゴリズムが有効であることを示した。
また、MAPOS の経路制御プロトコル ESSP に使用する経路制御アルゴリズム TPV を提示
し、従来のプロトコルに比較して 10 倍程度の収束性の改善が行われることを示した。
更に、プロトコルの探索的な開発やプロトタイピングの効率化を目指し、同一レイヤに
僅かに異なるプロトコルの混在を許すプロトコル実装モデル POM を提示して、それがオ
ブジェクト指向言語の枠組を使用して実装できることを示した。以下、各項目について
結言を述べる。
(1)
超高速データ通信向きの多重アクセスプロトコル MAPOS
効率良くデータ転送ができる多重アクセスプロトコルを目指し、MAPOS を開発した。
まず、超高速データ通信プロトコルの要件が (1) プロトコルの簡明さ (2) 長大フレ
ームによる転送効率の高さ (3) LAN と WAN とのシームレス性、 (4) 速度および距離
のスケーラビリティ (5) 従来方式との互換性による実装の容易さ (6) アドレスの自
動割り当てや動的経路制御によるプラグアンドプレイ (7) 経路収束の速さ (8)特定
のトポロジに制限されない自由なネットワーク構成 であることを明らかにした。そ
して、これらの要件を満足するプロトコル群 MAPOS を示した。更に、MAPOS プロトコ
ル群を、総容量 87.04Gbps の高速 MAPOS スイッチ COREswitch および 2.4Gbps の高速
ホストインタフェースとして実装した。これらを使用したネットワークは、東京都内
の 5 つのサイトを最大 2.4Gbps で結ぶメトロポリタンネットワークとして稼働中であ
る。
実際のアプリケーションで MAPOS を評価するため、非圧縮 HDTV 伝送システムでの
転送特性を測定し、長大フレームであれば最大 1.5Gbps のストリームを 10-9 から 1010
以下のエラーレートで転送することができるということを明らかにした。更に、POS
との互換性による実装の容易さを検証するために、業界標準の cisco 社ルータへ実装
し、ハードウェアに一切の改造を加えることなくソフトウェアの変更だけで MAPOS が
稼働し、しかも、そのソフトウェアの半分は既存のモジュールの流用が可能であるこ
とを実証した。
153
(2) 時相パスベクタ経路制御アルゴリズム TPV
経路の収束速度を向上させるために、時相パスベクタ経路制御アルゴリズム TPV を
開発した。まず、route bouncing の原因は、経路計算の過渡期に、ネットワーク内
に混在する新旧の経路情報の区別ができないことに起因することを明らかにした。こ
れに対し、パスの属性に情報発生時間を付加することによって古い情報による新しい
情報の上書きを防止し、更に、古い情報源を消去する TPV アルゴリズムが有効である
ことを示した。そして、情報発生時間としてリンクのイベントごとに進む仮想時間を
使用し、受信側ノードにおける仮想時間を使用することによって、分散したスイッチ
が的確に経路情報の新旧を判断できることを明らかにした。
次に、机上でのシミュレーションを行い、同一シナリオの下で TPV の経路収束性を
従来のパスベクトルアルゴリズムと比較した。そして、従来の方式で収束に 48 ステ
ップを要した場合に、TPV ではわずか 4 ステップで収束することを示した。
更に、TPV アルゴリズムを MAPOS の経路制御プロトコルへ適用した ESSP について、
そのプロトコル構成と実装アーキテクチャを説明した。そして、指定サクセサの概念
を使用すればユニキャストで並列パスを使用する場合でも、マルチキャスト/ブロー
ドキャストのスパニングツリーを作成できること、GID リストを指定サクセサに渡す
ことで無駄なマルチキャストの転送を抑制できること、MAPOS 固有の高速中継用テー
ブル FT を利用して一時的なループを防ぐための転送抑制機構をオーバヘッドなしに
作成できることを示した。
(3) プロトコル実装モデル POM
探索的なプロトコル開発を可能とし、プロトコルの拡張および変更に対して柔軟な
ネットワークシステムを実現するため、バーチャルサーキットに沿ったソフトウェア
のパスをモジュールの単位とするプロトコル実装モデルPOMを提案した。次に、この
モデルが、オブジェクト指向の枠組みを用いて実現できることを示した。そして、プ
ロトコルの階層性に基づいてレイヤをレイヤクラスに対応させ、バーチャルサーキッ
トはレイヤクラスを多重継承したコネクションクラスに対応させれば良いことを明
らかにした。
また、POM では、利用するすべてのレイヤのクラスを直接に継承する直接継承と、
隣接する上位レイヤがその下位レイヤを継承することによって最終的にすべてのク
ラスを継承する間接継承の 2 つの継承方式があることを示した。プロトコルの変更が
これらの継承関係にどのような影響を及ぼすかを検討した結果、下位レイヤの変更に
対しては前者の方式が向いており、上位レイヤの変更に対しては後者が向いているこ
154
とを明らかにした。そして、パケットがすべてのレイヤで共有されることを示し、オ
ブジェクト上での並列処理やプロセススイッチなしに複数のレイヤのプロトコル処
理ができることを明らかにするとともに、実装言語に同一オブジェクト上の並列メソ
ッド実行や排他制御の機能が必要であることを明らかにした。
(4) POM に基づくプロトコルの実装
コネクションをモジュール単位とするパス指向型プロトコル実装モデルPOMがオブ
ジェクト指向の枠組みを用いて用意に実現できることを示すため、記号処理計算機
TAO/ELIS上のTCP/IPネットワークを実装して実証した。また、POMモデルとオブジェ
クト指向との親和性を検証するため、メソッドやインスタンス変数の継承率を調査し、
メソッドの継承率は77%、インスタンス変数の継承率は87%の結果を得、本モデルがオ
ブジェクト指向の枠組との親和性を持つことを明らかにした。また、ファイル転送中
のネットワークカーネルのCPU使用率を観測し、その割合が20%から40%程度であり、
少くとも、このモデルがシステムに著しいパフォーマンス低下をもたらさないことを
示した。
現在、超高速ネットワークを目指し、多くのプロトコルが標準化されようとしている。
それらの中には、既存のプロトコルとの互換性に注目するあまり効率を犠牲にしたもの、
適用範囲を広くねらいすぎたために複雑なプロトコルとなってしまったもの、取り得る
トポロジがリングに制限されてしまっているもの等、総合的な見地からのアプローチが
十分であるとは言えないものが多い。また、プロトコルのプロトタイピングにあたって
は、レイヤをモジュール単位とする従来のパラダイムにとらわれずぎ、探索的なプロト
コル開発を可能とすることによって生産性を向上させるアプローチもとられていない。
本論文では、このような背景のもと、転送効率と経路制御の収束性という総合的な視
点にたって超高速データ通信向きプロトコルを開発し、それを実際に超高速で動作する
装置として実現してきた。また、そのようなプロトコルのプロトタイピングを容易にす
るネットワークログラミンングパラダイムを提案し、実際にそのパラダイムに基づいて
ネットワークカーネルを実装することによって実現性を示した。
SONET/SDH の技術開発が進んで光ファイバ上で 40Gbps の信号を伝送する技術が視野
に入った。ここで述べた MAPOS プロトコルは SONET/SDH を継承しているために、その限
界速度まで使用できる。しかし、光の信号を電気の信号に変換してパケット交換を行う
電気スイッチの開発がますます困難になり、その開発コストと開発時間の問題を解決す
るために新たなアプローチが必要である。また、一本の光ファイバで多量のトラフィッ
クが運ばれるようになると、障害対策のために、ますます高速に収束する経路アルゴリ
ズムが必要となる。そこで、今後以下の研究課題にアプローチしたい。まず、超高速ス
155
イッチを単一のスイッチで実装するのではなく、複数の電気スイッチを高速の光スイッ
チバックボーンで結合し、動的にその結合形態を変化させることによってあたかも単一
の超高速スイッチのように動作する構造可変スイッチである。ここでは、結合を動的に
変更する制御アルゴリズムが特に問題となる。また、より高速な経路収束を可能とする
ため、ネットワークの経路に複数のスパニングツリーを持ち、それらのツリーを瞬時に
切り替えることのできる経路制御アルゴリズムにもチャレンジしたい。
156
謝辞
本論文をまとめるにあたり、ご指導をたまわり、ご助言をいただきました早稲田大学
理工学部 村岡洋一教授、後藤滋樹教授、中島達夫教授に心から感謝いたします。また、
筆者がプロトコル研究にとり組むきっかけを与えていただいた米国コロンビア大学中
央計算機センタのFrank Da Cruzネットワーク部長とChristine Gianoneプロトコル開発
プロジェクト責任者に深く感謝の意を表します。Kermitプロトコルプロジェクトにかか
わることによってプロトコルの基礎を学ぶことができ、両氏には特別のご支援をいただ
きました。
本研究は、NTT基礎研究所、NTTソフトウェア研究所、NTT未来ねっと研究所において
業務の一環として行われました。この間、上司であった早稲田大学 後藤滋樹教授およ
び電気通信大学 竹内郁雄教授には、大変な援助をいただき、ご指導をいただきました。
心から感謝の意を表します。また、株式会社NTTデータ 青木利晴社長には、当時、研究
開発本部長として格別のご支援をいただきました。
超高速プロトコルの研究に関しては、初期のアイデアに関する議論をしていただき、
アドバイスをいただいた米国NetStar社 John Mulleny 最高技術責任者に感謝いたしま
す。この研究を進めるにあたっては、国立情報学研究所 山田茂樹教授、NTT未来ねっと
研究所 小柳恵一部長のあたたかいご支援を受けました。また、プロジェクトを一緒に
進めてきた、名古屋工業大学 高橋直久教授、NTT未来ねっと研究所の丸山充主幹研究員、
同 川野哲生研究主任、同 八木哲研究主任、同 小倉毅研究員、同 清水健司研究員に感
謝します。この方々は、MAPOSのハードウェア開発にすばらしい能力を発揮されました。
これらのハードウェアなしには本研究はありえませんでした。
cisco社におけるルータ上へのプロトコル実装に関しては、我々の希望を受け入れて
いただいた米国cisco Systems社 Ed Kozel 最高技術責任者と日本cisco Systems社 松
本孝利 会長 (当時)に感謝の意を表します。また、この実装を行なったNTT未来ねっと
研究所 清水奨 研究主任のすばらしい能力と努力に深く感謝いたします。
プロトコル開発にあたっては、たくさんの方々のご支援をいただきました。NTT未来
ねっと研究所 釘本健司 研究主任には、開発環境の整備や維持に多大な努力をしていた
だきました。Sun Microsystems社の安光正則 部長には、格別のご配慮とご支援をいた
だきました。また、 同社 佐島 隆博 氏には、プロジェクト推進の核として実装をおこ
なっていただいたばかりではなく、英語の指導もしていただきました。海外との交渉に
あたっては、萬弁護士事務所の萬幸男弁護士にお世話になりました。東京都内のメトリ
ポリタンネットワークの開発は、東京大学医科学研究所 高木利久教授 のご理解とご協
力なしには実現できませんでした。ここに深く感謝いたします。
プロトコルのプロモーションに関しては、ネットワン株式会社 大石雅彦 取締役、同
157
細井滋樹 部長、AmplifyNet社 上村文五 ディレクタ、株式会社IDGジャパン 三橋昭和
編集長、同 平野孝副編集長、同 威能契副編集長にご支援とアドバイスを賜りました。
MAPOSのハードウェア開発は、株式会社 中央システム技研、株式会社 未来技術研究所、
株式会社 センチュリーシステムズの方々と、ここに名前を挙げきれないほどの極めて
多くの方々のご努力によって遂行されました。
プロトコル実装方式の研究は、LispマシンTAO/ELISなしには進めることができません
でした。このハードウェアは、北陸先端技術大学院大学 日比野靖教授とNTTエレクトロ
ニクス株式会社 渡邊和文 担当部長によって開発されました。また、ソフトウェアは、
電気通信大学 竹内郁雄教授および京都大学 奥乃博教授、大阪工業大学 大里延康教授、
NTT未来ねっと研究所 天海良治主任研究員、NTTドコモ研究所 山崎憲一主幹研究員によ
って開発されました。ここに深く感謝いたします。プロトコル実装の研究を進めるにあ
たって、ハードウェアに関して NTT-IT社 吉田雅治 担当部長、NTT情報流通プラットフ
ォーム研究所 三上博主幹研究員のアドバイスをいただきました。また、不断の研究の
ディスカッションとネットワークアプリケーションとしての知的システムに関する多
くの助言をしていただいた、NTT未来ねっと研究所の菅原俊治主幹研究員、明石修 主任
研究員に感謝いたします。
158
参考文献
[1] Cerf, V.: The Catenet Model for Internetworking, IEN-48, Information
Processing Techniques Office, Defense Advanced Research Project Agency, 1978.
[2] Postel, J.B.: Internetwork Protocol Approaches, IEEE Trans. Comm., Vol.COM-28,
No.4, pp.604--611, 1980.
[3] Postel, J.B., Sunshine, C.A. and Cohen, D.: The ARPA Internet Protocol,
Computer Networks, Vol.5, No.4, pp.261-271, 1981.
[4] Postel, J.: Internet Protocol, RFC791, USC/ISI, 1981.
[5] S. Kirkpatrick, M. Stahl, M. Recker : INTERNET NUMBERS, RFC1166, July 1990.
[6] Comer, D.: Internetworking with TCP/IP Volume I, Prentice-Hall, 1991. [村
井，楠本訳: TCP/IPによるネットワーク構築 Vol. I，共立出版，1991].
[7] Davidson, J.: An Introduction to TCP/IP, Springer-Verlag，1988. [後藤，村
上，野島訳: はやわかりTCP/IP，共立出版，1991].
[8] Xerox Corporation: The Ethernet: a local area network: Data link layer and
physical layer specification, X3T51/80-50, Xerox Corporation, 1980.
[9] Postel, J. and Reynolds, J.: A Standard for the Transmission of IP Datagram
over IEEE 802 Networks, RFC1042, USC/ISI, 1988.
[10] Postel, J.: Transmission Control Protocol, RFC793, USC/ISI, 1981.
[11] Tanenbaum, A.S.: Computer Networks (second edition)}, Prentice-Hall, 1988.
[斉藤，小野，発田訳: コンピュータネットワーク，丸善, 1992].
[12] Dimitri Bertsekas and Robert Gallager著、八星礼剛 著、データネットワーク、
オーム社、1990.
159
[13] Postel, J.: User Datagram Protocol}, RFC768, USC/ISI, 1980.
[14] R. FieldingJ., Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T.
Berners-Lee : Hypertext Transfer Protocol -- HTTP/1.1, RFC2616, June 1999.
[15] Postel, J. and Reynolds, J.: TELNET Protocol Specification, RFC854, USC/ISI,
1983.
[16] Postel, J. and Reynolds, J.: File Transfer Protocol (FTP), RFC959, USC/ISI,
1985.
[17] Postel, J.: Simple Mail Transfer Protocol, RFC821, USC/ISI, 1982.
[18] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson :
RTP: A Transport
Protocol for Real-Time Applications, RFC1889, January 1996.
[19] Christian Huitema : Routing in the Internet, Prentice Hal, 2000. [前村昌
紀訳、インターネットルーティング、翔泳社, 2001]
[20] C. Hedrick :
Routing Information Protocol, RFC1058, June 1988.
[21] Malkin, G.: RIP Version 2 Protocol Analysis, RFC1387, January 1993.
[22] J. Moy : OSPF Version 2, RFC2178, July 1997.
[23] Y. Rekhter, T. Li : A Border Gateway Protocol 4 (BGP-4), RFC1771, March 1995.
[24] Braden, R., : Requirements for Internet Hosts - Communication Layers,
RFC-1122, October 1989.
[25] American National Standard for Telecommunications - Digital Hierarchy Optical Interface Rates and Formats Specification, ANSI T1.105-1991.
[26] American National Standards Institute : Synchronous Optical Network (SONET)
- Basic Description including Multiplex Structure, Rates and Formats, ANSI
160
T1.105-1995.
[27] American National Standards Institute : Synchronous Optical Network
(SONET)--Payload Mappings, T1.105.02-1998.
[28] CCITT Recommendation G.707: Synchronous Digital Hierarchy Bit Rates, 1990.
[29] CCITT Recommendation G.708: Network Node Interface for Synchronous Digital
Hierarchy, 1990.
[30] CCITT Recommendation G.709: Synchronous Multiplexing Structure, 1990.
[31] ITU-T Recommendation I.361 : B-ISDN ATM layer specification, 1992.
[32] ITU-T Recommendation I.362 : B-ISDN ATM adaptation layer (AAL) functional
description, 1991
[33] ITU-T Recommendation I.363 : B-ISDN ATM adaptation layer (AAL) specification
(AAL1, AAL2, AAL3/4, AAL5), 1993.
[34] ITU-T Recommendation I.311 : B-ISDN General Network aspects, 1992.
[35] ITU-T Recommendation I.321 : B-ISDN protocol reference model and its
application, 1991.
[36] ITU-T Recommendation I.327 : B-ISDN functional architecture, 1991.
[37] R. Cole, D. Shur, C. Villamizar : IP over ATM : A Framework Document, RFC1932,
April 1996
[38] Cavanaugh, J. : Protocol Overhead in IP/ATM Networks, Minnesota Supercomputer
Center, Inc., Minneapolis, MN, August 1994.
[39] Kent C., and J. Mogul : Fragmentation Considered Harmful, Proceedings of the
ACM SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology,
August 1987.
161
[40] Romanow, A., and Floyd, S. : Dynamics of TCP Traffic over ATM Networks. IEEE
JSAC, Vol. 13 No. 4, pp.633-641, May 1995.
[41] ITU-T Recommendation Q.2931 : B-ISDN User-Network Interface Layer 3
Specification for Basic Call/Bearer Control, 1993.
[42] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, June, 1999.
[43] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC1661, July 1994.
[44] Simpson, W., editor, "PPP in HDLC-like Framing," RFC-1662, July 1994.
[45] IEEE Std. 802.3 : Carrier Sense Multiple Access with Collision Detection (CSMA
/ CD) access method and physical layer specifications, IEEE, 2000.
[46]IEEE Std. 802.3u : Type 100BASE-T MAC Parameters, Physical Layer, MAUs, and
Repeater for 100 Mb/s Operation, IEEE, 1995.
[47] IEEE Std. 802.3z : Physical Layers, Repeater, and Management Parameters for
1000 Mb/s Operation, IEEE, 1998.
[48] IEEE Std. 802.3ab : Physical Layer Parameters and Specifications for 1000
Mb/s Operation Over 4-Pair Category 5 Balanced Copper Cabling, Type 1000BASET--DRAFT, IEEE, 1998.
[49] IEEE Draft 802.3ae : Media Access Control (MAC) Parameters, Physical Layer
and Management Parameters for 10Gb/s Operations, IEEE, 2001.
[50] Y. Rekhter, T. Li : An Architecture for IP Address Allocation with CIDR,
RFC1518, September 1993.
[51] IEEE 802.1D-1993 : Media Access Control (MAC) Bridges, ISO/IEC 15802-3:1993
ANSI/IEEE Std 802.1D, 1993 edition, July 1993.
[52] Radia Perlman : Interconnections : bridges, routers, switches, and
162
internetworking protocols, 2nd edition, Addison Wesley, 2000. [加藤朗訳 : イン
ターコネクションズ 第二版, 翔泳社, 2001
[53] IEEE Std. 802.1w : Mesia Access Control (MAC) Bridges -Amendment 2 : Rapid
Reconfiguration, IEEE, 2001,
[54] Symbolics, Inc. : Networks Manual, June 1986.
[55] Norman C. Hutchinson and Larry L. Peterson : The x-Kernel:An Architecture
for Implementing Network Protocols, IEEE Transactions on Software Engineering,
Vol.17, No.1, Jan. 1991.
[56] K. Murakami and M. Maruyama : MAPOS - Multiple Access Protocol over SONET/SDH,
Version 1, RFC2171, June 1997.
[57] M. Maruyama and K. Murakami : MAPOS Version 1 Assigned Numbers, RFC2172, June
1997.
[58] K. Murakami and M. Maruyama : A MAPOS version 1 Extension -Node Switch Protocol,
RFC2173, June, 1997.
[59] K. Murakami and M. Maruyama : A MAPOS version 1 Extension - Switch Switch
Protocol," RFC2174, June, 1997.
[60] K. Murakami and M. Maruyama : MAPOS 16 - Multiple Access Protocol over
SONET/SDH with 16 Bit Addressing, RFC2175, June 1997.
[61] K. Murakami and M. Maruyama : IPv4 over MAPOS Version 1, RFC2176, June, 1997.
[62] S. Shimizu, T. Kawano, K. Murakami, and E. Beier : MAPOS/PPP Tunneling mode,
RFC3186, Dec. 2001.
[63] 村上、高橋、丸山、八木、小倉、川野：超高速データ通信用プロトコル MAPOS の
概要、情報処理第 56 回全国大会、3-440 - 3-441, 1998
[64] 高橋、村上、丸山、八木、小倉、川野：並列分散型高速通信スイッチ COREswitch、
163
情報処理第 56 回全国大会、3-442 - 3-443, 1998.
[65] 丸山、川野、小倉、八木、村上、高橋：OC-48c MAPOS ネットワークシステムの実
現、コンピュータシステム研究会、信学会 CPSY99-75 pp.17-24, 1999.
[66] T. Ogura, S. Yagi, T. Kawano, M. Maruyama, and N. Takahashi : Crossbar Arbiter
Architecture for High-speed MAPOS Switch, IEICE TRANS. INF. & SYST., VOL.E83D, No.5, May 2000.
[67] 清水健司、川野哲生、小倉毅、丸山充 : MAPOS 対応 OC-48c PCI カードの実現と
性能評価、信学技報、TECHNICAL REPORT OF IEICE NS2002-55 (2002-06), pp.9-12, 2002.
[68] 川野哲生、清水健司、小倉毅、丸山充 : インターネット非圧縮 HDTV 転送システ
ムにおける高速プロトコル処理技術, NTT R&D Vol.51 No.7, pp.596(64)-602(70), 2002.
[69] Jacobson, V. Braden, R. and Borman, D.: TCP Extensions for High Performance,
RFC1323, 1992.
[70] 村上健一郎 : 時相パスベクタ経路制御アルゴリズム TPV、マルチメディア、分散、
協調とモバイル DICOMO2002 シンポジウム、情報処理学会、2002.
[71] Deering, S. : Multicast Routing in Internetworks and Extended LANs, SIGCOMM
Summer 1988 Proceedings, August 1988.
[72] Yogan K. Dalal and Robert M. Metcalfe : Reverse Path Forwarding of Broadcast
Packets, Comm. ACM 21, 12, pp1040-1048, Dec. 1978.
[73] D. Waitzman, C. Partridge, S. Deering : Distance Vector Multicast Routing
Protocol, RFC1075, November 1988.
[74] S. Parker, C. Schmechel : Some Testing Tools for TCP Implementors, RFC2398,
August 1998.
[75] Douglas Comer : Internetworking With TCP/IP Volume 1: Principles Protocols,
and Architecture, 4th edition, 2000.
164
[76] C. Hedrick, "An Introduction to IGRP," Center for Computers and Information
Services, Rutgers University, August 1991.
[77] Craig Labovitz, Abha Ahuja, and Abhijit Bose : Delayed Internet Routing
Convergence, Proceedings ACM SIGCOMM'2000, Computer Communications Review, Vol
30, No 4, pp. 175-187, October 2000.
[78]
S.
Bradner
:
The
Internet
Standards
Process
--
Revision
3,
RFC2026, October 1996.
[79] 村上健一郎、奥乃博 : オブジェクト指向によるネットワークプログラム構成法、
情報処理学会代32回全国大会予稿 集6F-6,1986.
[80] 村上健一郎 :
LANプロトコルのオブジェクト指向による実現、情報処理学会第34
回全国大会予稿集1F-7,1987.
[81] 村上健一郎 : オブジェクト指向によるTCP/IPプロトコルの実現、コンピュータ
ソフトウェア、Vol.6、No.1、pp.30-40, 1989.
[82] K. Murakami : An Object-oriented Implementation of TCP/IP Network Protocols,
Advances in Software Science and Technology, Vol.3, pp.37-pp.52, 1991.
[83] O'Malley, S. and L. Peterson : A Dynamic Network Architecture, ACM
Transactions on Computer Systems, Vol. 10, No. 2, pp. 110-143, May 1992.
[84] Robbert van Renesse, Kenneth P. Birman and Silvano Maffeis : Horus, a flexible
Group Communication System, Communications of the ACM, Communications of the ACM
Vol. 39, No. 4, 76-83, April 1996.
[85] Adele Goldberg and David Robson
: Smalltalk-80: The Language and Its
Implementation、 Addison-Wesley, 1983.
[86] S. E Keene : Flavors : Object-oriented Programming on Symbolics Computers.
Technical report, Symbolics, Inc., 1985.
[87] B. Stroustrup
: The C++ Programming Language, Third Edition, Addison Wesley,
165
1997.
[88] Ken Arnold and James Gosling : The Java Programming Language, Addison-Wesley,
1998.
[89] 日比野靖、渡辺和文、大里延康： LISP マシン ELIS のアーキテクチャ、情報処理
学会処理研究会資料 24-3,1983.
[90] Ikuo Takeuchi, Hiroshi G. Okuno and Nobuyasu Osato, A List Processing Language
TAO with Multiple Programming Paradigm, New Generation Computing Ohmsha /
Spriger-Verlag Vol.4 Num.4, 401-444, 1986.
[91] T. Sugimura, H. Sugiyama, Y. Amagai, K. Murakami and I. Takeuchi : TAO/ELIS:An
AI Software Development Environment Based on a Multiple Programming Paradigm
Language、REVIEW of the Electrical Communications Laboratories, Vol.37, No. 1,
pp.77-pp.84, 1989.
[92] 天海良治 : マイクロプログラムの静的変換による記号処理システムの移植とその
性能評価, 信学会論文誌 D-1 Vol.J84-D-1, No.1 pp.100-107, January 2001.
[93] Marshall Kirk McKusick, Keith Bostic, Michael J. Karels, and John S.
Quarterman :
The Design and Implementation of the 4.4BSD Operating System,
Addison-Wesley 1996.
[94] Richard Stevens : UNIX Network Programming, Volume 1, Second Edition:
Networking APIs: Sockets and XTI, Prentice Hall, 1998.
[95] D.C. plummer : Ethernet Address Resolution Protocol, RFC 826, November1982.
[96] Sandberg, R., Goldberg, D., Kleinman, S.,Walsh, D., and Lyon, B.: Design and
Implementation of the Sun Network Filesystem, Proc. USENIXConference, pp.ll9-130, 1985.
[97] Sun Microsystems : XDR : External Data Representation standard, June, 1987.
166
研究業績
種類別
論文誌
○
○
○
○
○
RFCs
題名、発表発行掲載誌名、発表発行年月、連名者(申請者含む)
O. Akashi, T. Sugawara, K. Murakami, M. Maruyama, and K. Koyanagi : Agent
System for Inter-AS Routing Error Diagnosis, IEEE Internet Computing,
Vol.6, No.3 (2002), pp.78-82
Sugawara T., Murakami K. and Goto S.: A multi-agent monitoring and
diagnostic system for TCP/IP-based network and its coordination,
Knowledge-Based Systems, Elsevier, Vol.14, No.7, Nov. 2001, pp.367-383
明石、菅原、村上、丸山、高橋：マルチエージェントを用いた自律組織間診断
シ ス テ ム ： ENCORE 、 情 報 処 理 学 会 誌 論 文 誌 Vol.40, No.6, June 1999,
pp2659-2668
明石、村上、天海、 奥乃: Nue-Linda モデルと自己記述による実装、コンピュ
ータソフトウェア Vol15, No.1, 1998, pp.24-33
奥乃、明石、村上、天海 : 非均質システム Nue-Linda インタプリタの自己記述、
情報処理論文誌、Vol.34, No.4, 1993, pp.568-579
Murakami : An Object-oriented Implementation of TCP/IP Network Protocols,
Advances in Software Science and Technology, Vol.3, 1991, pp.37-52
村上 : オブジェクト指向による TCP/IP プロトコルの実現、コンピュータソフ
トウェア、Vol.6、No.1、1989、pp.30-40
Murakami, Matsumoto, Kurata and Nakao : A Scheduler Based on the Demand
Page-Stealing for Large-Scale Programs, Systems and Computers in Japan,
Vol.17, No.8, 1986, pp.1600-1608
村上、松本、倉田、中尾 : デマンドページスチールによる大型ジョブの実行制
御方式、信学会論文誌、Vol.J68-D-No.9、1985、pp.1600-1608
明石、菅原、村上、丸山、小柳：広域 IP 網自動診断システム:ENCORE、 NTT R&D
Vol.51 No.7, 2002, pp.603(71)-611(79)
村上、天海、釘本、岡、伊藤、後藤、伊藤 : 高速インターネット - Long, Fat
Pipe -、NTT R&D, Vol.43, No.9, 1994, pp.973-982
T. Sugimura, H. Sugiyama, Y. Amagai, K. Murakami and I. Takeuchi :
TAO/ELIS:An AI Software Development Environment Based on a Multiple
Programming Paradigm Language、REVIEW of the Electrical Communications
Laboratories, Vol.37, No. 1, 1989, pp.77-84
T. Matsumoto and K. Murakami : Resource Management for Large Scale Programs
in the DIPS-106 Network OS, Review of the Electrical Communications
Laboratories, Vol.33, No.4, 1985, pp.707-715
松本、村上 : DIPS-106 ネットワーク OS における大規模プログラム実行制御方
式、電気通信研究所研究実用化報告、Vol.34、No.2, 1985、pp.287-299
S. Shimizu, T. Kawano, K. Murakami and E. Beier, MAPOS/PPP Tunneling mode,
RFC-3186, Dec. 2001
Murakami, K. and M. Maruyama, MAPOS - Multiple Access Protocol over
SONET/SDH, Version 1 RFC-2171, June 1997
Maruyama, M. and K. Murakami : MAPOS Version 1 Assigned Numbers, RFC-2172,
June 1997
167
Murakami, K. and M. Maruyama : A MAPOS version 1 Extension - Node Switch
Protocol, RFC-2173, June 1997
Murakami, K. and M. Maruyama, A MAPOS version 1 Extension - Switch-Switch
Protocol, RFC-2174, June 1997
Murakami, K. and M. Maruyama : MAPOS 16 - Multiple Access Protocol over
SONET/SDH with 16 Bit Addressing, RFC-2175, June 1997
Murakami, K. and M. Maruyama : IPv4 over MAPOS Version 1, RFC-2176, June
1997
査読付き Akashi, Sugawara, Murakami, and Maruyama : Multiagenet-based Cooperative
国際会議 inter-AS Diagnosis in ENCORE, IEEE NOMS2000, 2000, pp.521-534
Kugimoto, Murakami, Amagai and Oka : An Experience with a Long Fat Pipe,
Proceedings of The 9th International Conference on Information Networking
(ICOIN-9), 1994, pp.535-540
Sugawara and Murakami : A Multiagent Diagnostic System for Intenet
Problems, Proceedings of INET'92, 1992, pp.317-325
Murakami and Sugawara : ISDN Internet for FIPTH : Fast IP to The Home,
Proceedings of INET'92, 1992, pp.127-131
Murakami, Akashi, Amagai and Okuno : TOPS: A Tuple Operation Protocol Suite
for Nue-Linda Computation Model, JWCC 91, 1991
K. Murakami, A Pseudo Network Approach to Inter-Process Communication on
a Shared-memory Multi-Processor MacELIS, LNCC 441, Springer-Verlag, 1990,
pp.300-305
解説論文 村上: インターネットワークのパラダイムと基礎技術、コンピュータソフトウ
ェア、Vol.10, No.4, 1993、pp.10-21
村上 : TCP/IP によるコンピュータネットワークの構築技法, 情報処理、Vol.31,
No.11, 1990, pp1586-1595
著書など 村上 : インターネット、1994、岩波書店
後藤、村上、野島 訳(C. Maramud 著)：インターネット縦横無尽、1994、共立
出版
後藤、村上、野島 訳(J. Davidson 著) ： はやわかり TCP/IP、1991、共立出版
特許
特許第 3026457 号：構内網パケット監視方式(菅原、村上)、 1991 年
特許第 1662621 号、資源管理方式 (村上、倉田、松本)、1991 年
全 国 大 村上：時相パスベクトル経路制御アルゴリズム TPV、マルチメディア、分散、協
会、研究 調とモバイル(DICOMO)シンポジウム、2002
会
清水、釘本、天海、村上：スケーラブルな知的制御クラスタスイッチ Dynatera、
マルチメディア、分散、協調とモバイル(DICOMO)シンポジウム、2002
丸山、小倉、八木、川野、村上、高橋：並列分散型高速通信スイッチ COREswitch、
コピュータシステム研究会、信学会 CPSY98-156 , 1999, pp.41-48
丸山、川野、小倉、八木、村上、高橋：OC-48c MAPOS ネットワークシステムの
実現、コンピュータシステム研究会、信学会 CPSY99-75, 1999, pp.17-24
明石、菅原、村上、丸山：協調動作による AS 間障害解析の有効性、インターネ
ットテクノロジーワークショップ、1999
明石、菅原、村上、丸山、高橋：リフレクタエージェントを用いた自律組織間
診断システム、システムソフトウェアとオペレーティングシステム 77-28、マ
ルチメディアと分散処理 87-28、1998, pp161-166
168
高橋、村上、丸山、八木、小倉、川野：並列分散型高速通信スイッチ COREswitch、
情処第 56 回全国大会、1998, pp.3-442 - 3-443
村上、高橋、丸山、八木、小倉、川野：超高速データ通信用プロトコル MAPOS
の概要、情処第 56 回全国大会、1998, pp.3-440 - 3-441
村上健一郎 : リフレクタモデルに基づくインターネット管理アーキテクチャ、
情報処理第 52 回全国大会、1996, pp.1-121 - 1-112
岡、釘本、天海、村上 : 長距離超高速インターネット(1) -実験概要について -、
情処第 50 回全国大会、1995
釘本、村上、天海、岡 : 長距離超高速インターネット(2) -スループット -、
情処第 50 回全国大会、1995
天海、村上、釘本、岡 : 長距離超高速インターネット(3) -特性解析 -、情処
第 50 回全国大会、1995
村上、釘本、天海、岡 : 長距離超高速インターネット(4) - ボトルネック -、
情処第 50 回全国大会、1995
天海、村上、釘本、岡 : 長距離超高速インターネットの特性解析、情処マルチ
メディアと分散処理ワークショプ、1994
記号処理計算機 SILENT のネットワークアーキテクチャ、記号処理 72-4、1994,
pp.25-32
奥乃、明石、村上、天海: 非均質システム Nue-Linda インタプリタの自己記述,
並列処理シンポジウム JSPP'92, 1992
村上、菅原 : マルチプロトコルのための IP-over-ISDN プロトコル、信学会 交
換情報システム研究会、SSE92-39, IN92-30, 1992,pp.13-18
村上、菅原 : マルチベンダ環境のための IP-over-ISDN プロトコル,情処 44 回
全国大会、1992
奥乃、明石、天海、村上 : 非均質システム Nue-Linda 上での ATMS の実現、並
列処理シンポジウム JSPP'91、1991
村上：コンピュータネットワークの自己組織化について、日本ソフトウエア科
学会第 8 回大会論文集、1991、pp.465-468
村上、明石、天海、奥乃 : 計算モデル Linda の TAO への導入 -- 近傍系理論に
基づく計算モデルのための動的計算場について, 情処学会記号処理研究会,
57-4, 1990
三上、村上 : マルチプロセッサ Lisp マシン MacELIS II、第 31 回プログラミン
グシンポジウム報告集、1990、pp.135-146
村上、天海、明石、山崎、三上、奥乃 : 非均質システム NueLinda の検討、信
学会秋季全国大会、D-52、1990、pp.6-52
村上、天海 : NTT-Internet 構築の経験と実際、情報処理学会第 30 回プログラ
ミングシンポジウム報告集、1989、pp.43-53
村上、菅原 : インターネットワーク診断システム (1) - 障害診断の技法 - 、
情処第 39 回全国大会予稿集、1989, pp.1984-1985
菅原、村上 : インターネットワーク診断システム (2)、情処第 39 回全国大会
予稿集、1989, pp.1986-1987
明石、佐島、村上 : NueLinda の実現、ソフトウェア科学会第 7 回大会予稿集、
1989, pp.193-196
村上 : TCP/IP におけるインターネットワークの構築に関する考察、情報処理学
会利用者指向の情報システムシンポジウム予稿集、1988、pp.137-145
村上 : オブジェクト指向による TCP/IP の実現、ソフトウェア科学会オブジュ
クト指向ワークショップ WOOC'88、1988
169
付録.A
付録.A 収束ステップ - 従来のパスベクタの場合
ここでは、従来の BGP プロトコルを使用した図 1 のネットワークで、ノード N3 がダウ
ンしてから N0, N1, Nすべてが N3 への到達不能を認識するまでのステップ数を示す。こ
れは、参考文献 77 の例を示したものである。ここで、Nn はノード番号 n を持つノード、
Pm は各ノードにおけるローカルなポート番号である。
N0
P0
P2
P1
P2
N3
P0
N2
P0
P1
P2
P2
P1
P0
N1
P1
図 1 想定するネットワーク
(0) 安定した状態では、TT と RT は以下のようになっている。
ノード
N0
N1
N2
N0 からの情報
N0 N3
N0 N3
TT の内容
N1 からの情報
N2 からの情報
N1 N3
N2 N3
N2 N3
N1 N3
-
N3 からの情報
N3
N3
N3
各パスの標記は終点ノードが一番右になるようになっている。例えば、N0 N3 は、終点
N3 へのパスで、その経路は N0, N3 であることを表わす。
ノード
N0
N1
N2
RT の内容
N3
N3
N3
(1) N3 がダウンしたと仮定する。これによって、それぞれのノードから直接 N3 の経路が
消される。ここで、TT は以下のようになる。
170
ノード
N0
N1
N2
N0 からの情報
N0 N3
N0 N3
TT の内容
N1 からの情報
N2 からの情報
N1 N3
N2 N3
N2 N3
N1 N3
-
N3 からの情報
消滅
消滅
消滅
TT の変更を契機としてベストパスの再計算が行われ、RT は以下のようになったと仮定
する。
ノード
N0
N1
N2
RT の内容
N1 N3
N0 N3
N0 N3
RT が更新されたので、以下の update メッセージが転送される。
N0 から N1 と N2 へ : withdrawal N0 N3, new N0 N1 N3
N1 から N0 と N2 へ : withdrawal N1 N3, new N1 N0 N3
N2 から N0 と N1 へ : withdrawal N2 N3, new N2 N0 N3
ここでタイミングの関係で N0, N1, N2 の順でメッセージが送信され、その順番で各ノー
ドで受信されたと仮定する。これらは FIFO の待ち行列に入れられて処理を待つ。従っ
て、処理される順番も N0, N1, N2 からのメッセージの順である。
(2)まず、N0 からのメッセージ withdrawal N0 N3, new N0 N1 N3 が N1 と N2 で処理された
とする。すると TT は以下のようになる。
ノード
N0
N1
N2
TT の内容
N1 からの情報
N2 からの情報
N0 からの情報
N1 N3
N2 N3
N0 N1 N3 は自ノ
N2 N3
ード N1 を通る
ので破棄
N0 N1 N3
N1 N3
-
N3 からの情報
なし
なし
なし
TT の変更を契機としてベストパスの再計算が行われ、RT は以下のようになる。
171
ノード
N0
N1
N2
RT の内容
N1 N3
N2 N3
N1 N3
ここで、RT に変化のあった N1 と N2 から以下の update メッセージが送信される。
N1 から N0 と N2 へ : withdrawal N1 N0 N3, new N1 N2 N3
N2 から N1 と N0 へ : withdrawal N2 N0 N3, new N2 N1 N3
(3) 次に (1)で生成された N1 からのメッセージ withdrawal N1 N3, new N1 N0 N3 が N0, N2
で処理されたとする。
ノード
N0
N0 からの情報
-
N1
N2
なし
N0 N1 N3
TT の内容
N1 からの情報
N2 からの情報
N1 N0 N3 は自ノ N2 N3
ード N0 を通る
ので破棄
N2 N3
N1 N0 N3
-
N3 からの情報
なし
なし
なし
TT の変更を契機としてベストパスの再計算が行われ、RT は以下のようになったとする。
ノード
N0
N1
N2
RT の内容
N2 N3
N2 N3
N0 N1 N3
ここで、RT に変化のあった N0 と N2 から以下の update メッセージが送信される。
N0 から N1, N2 へ : withdrawal N0 N1 N3, new N0 N2 N3
N2 から N0, N1 へ : withdrawal N2 N1 N3, new N2 N0 N1 N3
(4)次に (1)で生成された N2 からのメッセージ withdrawal N2 N3, new N2 N0 N3 が N0 と
N1 で処理されたとする。
172
ノード
N0
N0 からの情報
-
N1
N2
なし
N0 N1 N3
TT の内容
N1 からの情報
N2 からの情報
なし
N2 N0 N3 に N0 が
含まれるため
破棄
N2 N0 N3
N1 N0 N3
-
N3 からの情報
なし
なし
なし
TT の変更を契機としてベストパスの再計算が行われ、RT は以下のようになったとする。
ノード
N0
N1
N2
RT の内容
なし
N2 N0 N3
N0 N1 N3
ここで、RT に変化のあった N0 と N1 から以下のメッセージが送信される。
N0 から N1, N2 へ : withdrawal N0 N2 N3
N1 から N0, N2 へ : withdrawal N1 N2 N3, new N1 N2 N0 N3
(5)次に (2)で生成された N1 からの withdrawal N1 N0 N3, new N1 N2 N3 が N0, N2 で処理
される。
ノード
N0
N1
N2
N0 からの情報
なし
N0 N1 N3
TT の内容
N1 からの情報
N2 からの情報
N1 N2 N3
なし
N2 N0 N3
N1 N2 N3 に N2 が
含まれるため
破棄
N3 からの情報
なし
なし
なし
TT の変更を契機としてベストパスの再計算が行われ、RT は以下のようになる。
ノード
N0
N1
N2
RT の内容
N1 N2 N3
N2 N0 N3
N0 N1 N3
ここで N0 だけに RT の変化があったので、N0 から以下のメッセージが生成される。
N0 から N1, N2 へ : new N0 N1 N2 N3
173
以上のような N0, N1, N2 間の古いパス情報のたらい回しがこの後も続き、参考文献 77
に示されているように N0, N1, N2 から N3 への経路が収束して完全に到達不能となるのは
48 ステップ後となる。この様子を以下に示す。
ノード
ステップ
1
ステップ
2
ステップ
3
ステップ
4
ステップ
5
ステップ
6
ステップ
7 .. 47
N0
N1 N3
N1 N3
N2 N3
N1
N0 N3
N2 N3
N2 N3
N2
N0 N3
N1 N3
N0 N1 N3
到 達 不 N1 N2 N3 N1 N2 N3 省略
能
N2 N0 N33 N2 N0 N3 到 達 不 省略
能
N0 N1 N3 N0 N1 N3 N0 N1 N3 省略
ステップ
48
到達不
能
到達不
能
到達不
能
174
付録.B
付録.B 収束ステップ - TPV の場合
ここでは TPV を採用した場合の経路収束をステップを追って説明する。シナリオは付
録 A と同じであり、付録 A の図 1 のネットワークにおいて、N3 がダウンした後、それへ
の経路がすべてのノードで到達不能となるまでのステップを考える。これにより、TPV
では、付録 A で 48 ステップを要した経路の収束が、僅か 4 ステップで完了することを
示す。
各標記の意味は以下の通りである。
Pnm : ノード n のポート m。例えば、付録 A の図 1 における N1 の P1 をここでは P11 と記
述する。
TnmK : ノード n のポート m における仮想時間 K
Nm(Pnm, TnmK) : ポート Pnm で仮想時間 TnmK にノード Nm から受信したことを示すパス要
素の属性
(0) 安定した状態では、各ノードにおける TT, RT, VTT は以下のようになっていると仮
定する。RT と TT は付録 A の場合と同じである。TTn, RTn, VTTn は、それぞれノード Nn
の TT, RT, VTT を表す。TT では、RT に採用されているベストパスに○をつけておく。
また、無効なパスと判別された TT 内のパスは取り消し線で表示する。VTT のエントリ
が変化した場合、古い値から新しい値への変化を矢印で示す。この場合、括弧内はメト
リックである。例えば、T022 →3 (∞)は、ノード 0 のポート 2 における仮想時間が 2
から 3 へ変化し、その変化後のメトリック値が∞(到達不能)となったことを示す。
TT0
N0 から
N1 から
N2 から
N3 から
VTT0
N0 関連(自ノード)
N1 関連
N2 関連
N3 関連
パス
N1(P01,T014)N3(P12,T123)
N2(P00,T001)N3(P22,T226)
N3(P02, T022)
ポート 0
T001
-
RT0
○
ポート 1
T014
-
ポート 2
T022
T123
T226
-
175
TT1
N0 から
N1 から
N2 から
N3 から
VTT1
N0 関連
N1 関連(自ノード)
N2 関連
N3 関連
TT2
N0 から
N1 から
N2 から
N3 から
VTT2
N0 関連
N1 関連
N2 関連(自ノード)
N3 関連
パス
N0(P10, T105)N3(P02,T022)
N2(P11, T111)N3(P22, T226)
N3(P12,T123)
ポート 0
T105
-
ポート 1
T111
-
パス
N0(P20, T204) N3(P02, T022)
N1(P21, T215) N3(P12, T123)
N3(P22, T226)
ポート 0
T204
-
ポート 1
T215
-
RT1
○
ポート 2
T022
T123
T226
-
RT2
○
ポート 2
T022
T123
T226
-
(1) N3 がダウンしたと仮定する。N0,N1,N2 は、このダウンを検出し、直接接続されてい
る N3 への経路を消す。また、各ノードにおけるノード N3 へのポートの仮想時間がイン
クリメントされる。これは、そのメトリックが無限大に変化したからである。 インク
リメントされると同時にガーベージコレクションのためのタイマがスタートする。その
タイムアウト時間は、経路変動が収束する時間に比較して十分大きい。以下に変化した
TT, RT, VTT を示す。
TT0
N0 から
N1 から
N2 から
N3 から
パス
N1(P01,T014)N3(P12,T123)
N2(P00,T001)N3(P22,T226)
N3(P02, T022)
RT0
○
176
VTT0
N0 関連(自ノード)
N1 関連
N2 関連
N3 関連
TT1
N0 から
N1 から
N2 から
N3 から
VTT1
N0 関連
N1 関連(自ノード)
N2 関連
N3 関連
TT2
N0 から
N1 から
N2 から
N3 から
VTT2
N0 関連
N1 関連
N2 関連(自ノード)
N3 関連
ポート 0
T001
-
ポート 1
T014
-
パス
N0(P10, T105)N3(P02,T022)
N2(P11, T111)N3(P22, T226)
N3(P12,T123)
ポート 0
T105
-
ポート 1
T111
-
パス
N0(P20, T204) N3(P02, T022)
N1(P21, T215) N3(P12, T123)
N3(P22, T226)
ポート 0
T204
-
ポート 1
T215
-
ポート 2
T022 →3 (∞)
T123
T226
-
RT1
○
ポート 2
T022
T123→4 (∞)
T226
-
RT2
○
ポート 2
T022
T123
T226→7 (∞)
-
各ノードから N3 へのパスをまとめると以下のようになる。
N0->N1->N3, N1->N0->N3, N2->N0->N3
N0 では RT が変化したので、N1、N2 へ以下の update メッセージを転送する。
withdrawal N0N3, reason N3(P02, T023)=∞, new N0(-, - )N1(P01,T014)N3(P12,T123)
177
これが N1,N2 で受信され、それぞれ以下のように受信したポートと仮想時間が付加され
てキューに入れられる。
withdrawal N0N3, reason N3(P02, T023)=∞, new N0(P10, T105 )N1(P01,T014)N3(P12,T123)
withdrawal N0N3, reason N3(P02, T023)=∞, new N0(P20, T204 )N1(P01,T014)N3(P12,T123)
N1 でも RT が変化したので、N0、N2 へ以下の update メッセージを転送する。
withdrawal N1N3, reason N3(P12, T124)=∞, new N1(-, -)N0(P10, T105)N3(P02,T022)
これが N0,N2 で受信され、それぞれ以下のように受信したポートと仮想時間が付加され
てキューに入れられる。
withdrawal N1N3, reason N3(P12, T124)=∞, new N1(P01, T014)N0(P10, T105)N3(P02,T022)
withdrawal N1N3, reason N3(P12, T124)=∞, new N1(P21, T215)N0(P10, T105)N3(P02,T022)
N2 でも RT が変化したので、N0、N1 へ以下の update メッセージを転送する。
withdrawal N2N3, reason N3(P22, T227)=∞, new N2(-, -)N0(P20, T204)N3(P02, T022)
これが N0,N1 で受信され、それぞれ以下のように受信したポートと仮想時間が付加され
てキューに入れられる。
withdrawal N2N3, reason N3(P22, T227)=∞, new N2(P00, T001)N0(P20, T204)N3(P02, T022)
withdrawal N2N3, reason N3(P22, T227)=∞, new N2(P11, T111)N0(P20, T204)N3(P02, T022)
(2) ここで、N0 からのメッセージが N1 と N2 で処理されたとする。
withdrawal N0N3, reason N3(P02, T023)=∞, new N0(P10, T105 )N1(P01,T014)N3(P12,T123)
withdrawal N0N3, reason N3(P02, T023)=∞, new N0(P20, T204 )N1(P01,T014)N3(P12,T123)
すると、それぞれの TT, RT は、以下のようになる。
TT0 (変化なし)
N0 から
N1 から
N2 から
N3 から
VTT0 (変化なし)
N0 関連(自ノード)
N1 関連
N2 関連
N3 関連
パス
N1(P01,T014)N3(P12,T123)
N2(P00,T001)N3(P22,T226)
ポート 0
T001
-
RT0
○
ポート 1
T014
-
ポート 2
T023(∞)
T123
T226
-
178
TT1
N0 から
N1 から
N2 から
N3 から
パス
N0(P10, T105 )N1(P01,T014)N3(P12,T123)
N2(P11, T111)N3(P22, T226)
-
RT1
○
注意しなければならないのは、N0(P10, T105 )N1(P01,T014)N3(P12,T123)が以下の 2 つの理由
で無効となることである。
(a) N1(自ノード)をパスに含むこと
(b) 仮想時間 T123 が VTT1 内の値 T124 よりも古いこと
VTT1
N0 関連
N1 関連(自ノード)
N2 関連
N3 関連
TT2
N0 から
N1 から
N2 から
N3 から
VTT2
N0 関連
N1 関連
N2 関連(自ノード)
N3 関連
ポート 0
T105
-
ポート 1
T014
T111
-
パス
N0(P20, T204 )N1(P01,T014)N3(P12,T123)
N1(P21, T215) N3(P12, T123)
ポート 0
T204
-
ポート 1
T014
T215
-
ポート 2
T022→3 (∞)
T124(∞)
T226
-
RT2
○
ポート 2
T022→3 (∞)
T123
T227(∞)
-
各ノードから N3 へのパスをまとめると以下のようになる。
N0->N1->N3, N1->N2->N3, N2->N1->N3
変化のあった N1 と N2 からそれぞれ以下の update メッセージが送信される。
withdrawal N1N0N3, reason N3(P02, T023)=∞, new N1( -, -)N2(P11, T111)N3(P22, T226)
withdrawal N2N0N3, reason N3(P02, T023)=∞, new N2( -, -)N1(P21, T215) N3(P12, T123)
前者は、N0 と N2 で受信され、それぞれ以下のように受信したポートと仮想時間が付加さ
179
れてキューに入れられる。
withdrawal N1N0N3, reason N3(P02, T023)=∞, new N1( P01, T014)N2(P11, T111)N3(P22, T226)
withdrawal N1N0N3, reason N3(P02, T023)=∞, new N1( P21, T215)N2(P11, T111)N3(P22, T226)
また、後者は N0 と N1 で受信され、それぞれ以下のように受信したポートと仮想時間が
付加されてキューに入れられる。
withdrawal N2N0N3, reason N3(P02, T023)=∞, new N2( P00, T001)N1(P21, T215) N3(P12, T123)
withdrawal N2N0N3, reason N3(P02, T023)=∞, new N2( P11, T111)N1(P21, T215) N3(P12, T123)
(3) 次に未処理である(1)で生成された以下の N1 から N0,N2 への update が処理されたと
する。
withdrawal N1N3, reason N3(P12, T124)=∞, new N1(P01, T014)N0(P10, T105)N3(P02,T022)
withdrawal N1N3, reason N3(P12, T124)=∞, new N1(P21, T215)N0(P10, T105)N3(P02,T022)
すると、それぞれの TT, RT, VTT は、以下のようになる。
TT0
N0 から
N1 から
N2 から
N3 から
パス
N1(P01, T014)N0(P10, T105)N3(P02,T022)
N2(P00,T001)N3(P22,T226)
-
RT0
○
注意しなければならないのは、N1(P01, T014)N0(P10, T105)N3(P02,T022)が以下の 2 つの理由
で無効となることである。
(a) N0(自ノード)をパスに含むこと
(b) 仮想時間 T022 が VTT0 内の値 T023 よりも古いこと
VTT0
N0 関連(自ノード)
N1 関連
N2 関連
N3 関連
TT1 (変化なし)
N0 から
N1 から
ポート 0
T001
T105
パス
-
ポート 1
T014
-
ポート 2
T023(∞)
T123→4 (∞)
T226
RT1
180
N2 から
N3 から
VTT1 (変化なし)
N0 関連
N1 関連(自ノード)
N2 関連
N3 関連
TT2
N0 から
N1 から
N2 から
N3 から
N2(P11, T111)N3(P22, T226)
ポート 0
T105
-
ポート 1
T014
T111
-
パス
N0(P20, T204 )N1(P01,T014)N3(P12,T123)
N1(P21, T215)N0(P10, T105)N3(P02,T022)
-
○
ポート 2
T023(∞)
T124(∞)
T226
-
RT2
注意しなければならないのは、N1(P21, T215)N0(P10, T105)N3(P02,T022)の仮想時間 T022 が
VTT2 内の値 T023 よりも古いことである。従って、このパスは無効となる。
また、N0(P20, T204 )N1(P01,T014)N3(P12,T123)のほうは、withdraw reason N3(P12, T124)に
よって VTT が更新されたために N3(P12,T123)のパス要素が無効となり、このパスも無効
となる。
VTT2
N0 関連
N1 関連
N2 関連(自ノード)
N3 関連
ポート 0
T105
T204
-
ポート 1
T014
T215
-
ポート 2
T023(∞)
T123→4 (∞)
T227(∞)
-
以上をまとめるとベストパスは以下のようになる。
N0->N2->N3, N1->N2->N3, N2-unreachable (旧サクセサは N0)
ここで、RT に変化のあった N0 から以下の update メッセージが送信される。
withdrawal N0N1N3, reason N3(P12, T124)=∞, new N0(-, -) N2(P11, T111)N3(P22, T226)
これは N1 と N2 で受信され、それぞれの受信したポートと仮想時間が付加された後にキ
ューに入れられる。
withdrawal N0N1N3, reason N3(P12, T124)=∞, new N0(P10, T105) N2(P11, T111)N3(P22, T226)
withdrawal N0N1N3, reason N3(P12, T124)=∞, new N0(P20, T204) N2(P11, T111)N3(P22, T226)
181
また、メトリックが増大(∞)して有効な経路のなくなった N2 は以下の update メッセー
ジを旧サクセサ N0 を除くノードへ送信する。
withdrawal N2N1N3, reason N3(P12, T124) =∞
これは、N1 で受信されそのままキューに入れられる。
(4)次に未処理である(1)で生成された
N2 からの N0 と N1 への以下のメッセージが処理さ
(4)
れたと仮定する。
withdrawal N2N3, reason N3(P22, T227)=∞, new N2(P00, T001)N0(P20, T204)N3(P02, T022)
withdrawal N2N3, reason N3(P22, T227)=∞, new N2(P11, T111)N0(P20, T204)N3(P02, T022)
すると、それぞれの TT, RT, VTT は以下のようになる。
TT0
N0 から
N1 から
N2 から
N3 から
パス
N2(P00, T001)N0(P20, T204)N3(P02, T022)
-
RT0
注意しなければならないのは、N2(P00, T001)N0(P20, T204)N3(P02, T022)が以下の 2 つの理
由で無効となることである。
(a) N0(自ノード)をパスに含むこと
(b) 仮想時間 T022 が VTT0 内の値 T023 よりも古いこと
VTT0
N0 関連(自ノード)
N1 関連
N2 関連
N3 関連
TT1
N0 から
N1 から
N2 から
N3 から
ポート 0
T001
T105
T204
-
ポート 1
T014
-
パス
N2(P11, T111)N0(P20, T204)N3(P02, T022)
-
ポート 2
T023(∞)
T124 (∞)
T226→7 (∞)
RT1
ここで注意しなければならないのは、N2(P11, T111)N0(P20, T204)N3(P02, T022)の
仮想時間 T022 が VTT1 内の値 T023 よりも古いことである。
182
VTT1
N0 関連
N1 関連(自ノード)
N2 関連
N3 関連
TT2 (変化なし)
N0 から
N1 から
N2 から
N3 から
VTT2 (変化なし)
N0 関連
N1 関連
N2 関連(自ノード)
N3 関連
ポート 0
T105
T204
-
ポート 1
T014
T111
-
パス
-
ポート 2
T023(∞)
T124(∞)
T226→7 (∞)
-
RT2
ポート 0
T105
T204
-
ポート 1
T014
T215
-
ポート 2
T023(∞)
T124(∞)
T227(∞)
-
ベストパスをまとめると以下のようになる。
N0-unreachable (旧サクセサは N2)
N1-unreachable (旧サクセサは N2)
N2-unreachable (旧サクセサは N0)
メトリックが増大(∞)して有効な経路のなくなった N0 と N1 は旧サクセサ N2 を除くノー
ドへ以下の update メッセージを送信する。
N0 から N1 へ : withdrawal N0N2N3, reason N3(P22, T227)=∞
N1 から N0 へ : withdrawal N1N2N3, reason N3(P22, T227)=∞
(5)次に未処理である(2)で生成された
N1 から N0 と N2 への update メッセージを処理する。
(5)
withdrawal N1N0N3, reason N3(P02, T023)=∞, new N1( P01, T014)N2(P11, T111)N3(P22, T226)
withdrawal N1N0N3, reason N3(P02, T023)=∞, new N1( P21, T215)N2(P11, T111)N3(P22, T226)
前者は、パス要素 N3(P22, T226)の仮想時間が VTT0 のそれよりも古いので無効である。ま
た、後者は、パス要素 N3(P22, T226)の仮想時間が VTT2 のそれよりも古いこととパスに N2
自信を含むので無効である。従って、どの TT, RT, VTT にも変化はない。
183
(6) 次に未処理である(2)で生成された N2 から N0 と N1 への update を処理する。
withdrawal N2N0N3, reason N3(P02, T023)=∞, new N2( P00, T001)N1(P21, T215) N3(P12, T123)
withdrawal N2N0N3, reason N3(P02, T023)=∞, new N2( P11, T111)N1(P21, T215) N3(P12, T123)
前者は、VTT0 よりも古い仮想時間のパス要素 N3(P12, T123)を持つので無効である。また、
後者は、VTT1 よりも古い仮想時間のパス要素 N3(P12, T123)を持ち、しかも、パスに N1 自
信を含むので無効である。従って、TT, RT, VTT に変更はない。
(7) 次に(3)で生成された N0 から N1, N2 への update メッセージを処理する。
withdrawal N0N1N3, reason N3(P12, T124)=∞, new N0(P10, T105) N2(P11, T111)N3(P22, T226)
withdrawal N0N1N3, reason N3(P12, T124)=∞, new N0(P20, T204) N2(P11, T111)N3(P22, T226)
前者は VTT1 よりも古い仮想時間のパス要素 N3(P22, T226)を持つので無効である。また、
後者は、VTT2 よりも古い仮想時間のパス要素 N3(P22, T226)を持つので無効であり、しか
も、パス中に自ノード N2 を持つので、これも無効である。従って、TT, RT, VT とも変
化はない。これで N2 は全メッセージの処理を完了する。
(8) N1 は、(4)における N0 から N1 への update を処理する。
withdrawal N0N2N3, reason N3(P22, T227)=∞
これで N1 はすべてのメッセージの処理を完了する。
(9) N0(active)は、(4)における N1 からの upadte を処理する。
withdrawal N1N2N3, reason N3(P22, T227)=∞
これで N0 はすべてのメッセージの処理を完了する。
以上の各ステップにおける各ノードの RT の変化を示す。
N0 (R0)
N1 (R1)
N2 (R2)
ステップ 1
N 1 N3
N 0 N3
N 0 N3
ステップ 2
同左
N 2 N3
N 1 N3
ステップ 3
N 2 N3
同左
到達不能
ステップ 4
到達不能
到達不能
同左
N0,N1,N2 は到達不能となるまでそれぞれ、2 回の bounce が発生している。しかし、48
184
ステップを要する付録 A の場合に比較して bounce は少なく、収束性が良いことがわか
る。また、すべての処理を終了するためには 9 ステップかかっているが、RT の収束だ
けに関して言えば、要したステップ数はわずか 4 ステップである。
185