第 3部

パケット 交換網25

第 1章はじめに

近年、スタンドアロンで使用されていた計算機がイーサネットの発達によりネットワークに接続されるようになった。その数もここ数年の間に数台から数百台へと大規模になりつつある。これは、計算機の低価格化のみなどのようなネットワークオペレーティングシステムの発ならず、展が大きく関与している。情報に対するある種の付加価値が重要となってきた現在、ネットワークは高度情報化社会の中でなくてはならないものになっている。それにともない、計算機研究者の間で主に使われていたコン
ピュータネットワークも生活の一部として、一般社会に浸透し始めている。

UNIX

最近では 、複数の計算機に役割分担をさせ、それらを水平結合することによりあたかも一台の計算機であるかのような環境をユーザに対して提」の研究がさかんに行なわれている。ローカルエリアネッ
供する「分散トワークでは、通信速度が早く、時間差が少ないため分散環境を構築するのは容易である。これは、お互いの計算機同士が個々の役割を認識しているため、必要な情報が得られやすいためであり、必要な情報をどの計算機から収集してよいのか分からない時は、ブロードキャストを用いることにより要求を満足する計算機がどれであるのかを知ることができる。しかしながら、例えばイーサネットでの接続は、電気的な制約から最大長までのネットワークしか構築できない。

OS

2.5 Km

それに対し最近では、ローカルエリアネットワーク同士を結合して新が盛んたに大きなネットワークを構築しようという動き
である。ネットワークの広域化による最大の利点は、計算機環境の地
理的、物理的拡大により、遠隔地にあるリソースを共有したり、数多くの人々の間でコミュニケーションを可能にしたりすることである。特に、電子メールは、不特定多数の相手と比較的短時間に文章のやりとりができる
ため、計算機研究者の間で活発な意見交換が可能である。アメリカなどでは、以前から電子メールを用いた議論が数多くなされ 、その結果として、計算機科学はまれに見る急速な発展をとげている。その意味で、電子メー
ルの果たした役割は非常に大きいと言える。

(Internetworking)

[15]

27

28

1989 年度 WIDE 報告書

UUCP

接続
日本におけるネットワーク同士の接続は、電話回線によるが主流である。このプロトコルは、ファイル転送を基本としたプロトコル
であり、一定時間ごとにゲートウェイが電話回線を利用して電子メールやでは、電子メールサービスを
ニュースを転送する方式である。
年から行なっているが、メールを目的地に直接配送するのではなく、隣接ノードへ送ることにより、バケツリレー方式でメールやニュースを伝搬させていく。しかしながら、電子メールやニュースシステムなどの情報交換だけではなく、遠隔サイトにあるデータベースなどの計算機資源を対話形式で利用したいという要求がある。この遠隔データアクセスは、次世である分散を構築する上で、なくてはならない基本要素でもあ代る。広域分散環境下においては、遠隔地にある資源をアクセスするアプリ
ケーションが、ローカルエリアネットワークと同等のスピードで透過的に実行されなければならない。そのためには、かなり高速な広域ネットワー
クの実現が必要とされる。

JUNET[28]

1984

OS

OS

7

T1(1.544

アメリカでは、全米で ヶ所あるスーパーコンピュータセンタをという高速専用回線で結合している。これをバックボー
ンとして、各地域ごとのネットワークがこれに接続されている。地域ごとのネットワークは、専用線もしくは、公衆パケット交換網によりネットワーク
的に接続されているのが一般的である。このよ
レイヤが形成されている。
うにして、全米中のネットワークを結合して、Mbps)(NSFnet)(Internet Protocol)

Internet

日本とアメリカのコンピュータネットワークを見た時、享受できるサービスの差異は大きい。アメリカでは、計算機同士がネットワークレ イヤ的に接続されているので 、 データグラムが直接相手の計算機に届く。こやなどのようなリモートコマンドがローカルエリア
れにより、
ネットワークと同等に利用できる。それに対し日本の場合、直接目的とする計算機とは接続されていないため、利用できるサービスがローカルエリ
アネットワークの時と異なり、かなり制約されてしまう。

telnet ftp

IP

Internetのような広域ネットワークの構
そこで、日本でもアメリカの築の必要性が高まりつつある。広域ネットワークの構築方法としては、専用回線の利用、回線交換網の利用、パケット交換網の利用などが考えられるが、信頼性やコストパフォーマンスの点からパケット交換網を利用した通信が 、最も適していると思われる。しかしながら、パケット交換は、一般的に通信速度が遅く、また、コネクションにもとづいた通信を行なっているために、回線設定までに時間的な遅延が生じるという欠点がある。そこで、いかにパケット交換において、通信速度を向上させるかが広域ネッ
トワークを構築する上での重要な課題であると言える。
ここで、パケット交換において通信速度が遅い理由を考えてみると、

第 3部

29

パケット 交換網

 交換機の転送速度の限界
 パケットサイズの制限
 ウィンド ウサイズの制限

NTT DDX-のなどが挙げられる。このうち、交換機の転送速度に関しては、ではとの 種類のサービスが提供されているに過ぎない。しかし 、ハード ウェアの発展に伴いこれらは、徐々に改善されていくものと思われる。
次のパケットサイズとウィンドウサイズの制限に関しては、各仮想回線ごとに定められた値であり、フローコントロールおよび網内での輻輳制御のために設定されるものである。ところが、網および計算機の双方に計算機資源の余裕がある場合でさえも、この制約により通信速度がある一定限度に押えられてしまう。このパケットサイズとウィンドウサイズはのプロトコルで定められた値なので、この値を無視することはできない。
そこで 、本研究では、同一通信相手に対して、仮想回線を複数本設立するというマルチリンク手法を導入し 、パケットサイズやウィンド ウサイ
ズを全体的に増加させる。これにより、従来のプロトコルを破壊することなく、パケット交換の通信速度を向上させることが可能となる。
プロ
第 章では、パケット交換プロトコルについて説明し 、特にトコルの問題点について言及する。また、広域分散ネットワークの構築をめざす WIDE プロジェクトの概要と本研究の位置付けに関して説明する。
第 章では、WIDEの全体的な設計思想について述べる。また、仮想回線の設立の手順、およびデータ転送手順に関して議論を行なう。第章では、WIDEの つのサブレ イヤの実装方法について詳しく解の評価を行ない、第 章で考察および説する。第 章で、WIDE
今後の課題について述べるものとする。

P

9.6Kbps 48Kbps 2

CCITT

X.25

2

X.25

3

/X.25

5

/X.25 4

4

/X.25

6

第 2章
パケット 交換プロト コル

この章では、パケット交換プロトコルの特徴およびその問題点について述べる。

2.1[87][86]

広域ネット ワークを構築するための 3 つの方法

現在、広域ネットワークを構築するための基礎技術として確立されている伝送形態には以下のようなものがある。

1. 回線交換網の利用
2. 専用線の利用
3. 公衆パケット交換網の利用
第一の回線交換方式は、回線契約者が多いため比較的簡単な方法でネッで広く用いら
トワークを確立することができる。これは、従来のの普及により最近注目されている方法である。回線交換網の利用は、れてきている。
により回線品質もディジタル化され、従来のアナログ系の電話回線と比較してかなり向上した。また、データ転送速度もと高速になった。しかしながら、従来の電話回線によるアクセスでは、相手とコネクションを確立するためにダイヤリングという操作を必要とした。
この時間的制約のため、回線交換方式による通信では、即答性を必要とす
るアクセスは極めて困難である。この制約を排除するためには、一度確立されたコネクションは二度と切断しないという方法が考えられるが、これは経済的に実用的ではない。また、回線交換方式では、通信中は物理的に回線を占有してしまうために、二ヶ所以上の相手と同時に通信することができない。このため、分散環境のように、いついかなる時でも任意の相手と通信する必要性がある通信には、この方式は向いていない。また、相手が通話中であったり、回線に空きがない時には通信する手段がないというのもこの方式の欠点である。

ISDN

ISDN

JUNET

64Kbps30

第 3部

パケット 交換網

31

第二の方法は、近接したサイト間を専用線で接続し 、それを結合して広域ネットワークを構築する方法である。この方法は、かなり実用的であり、かつ、高速通信を期待できる。しかし 、各サイト間で専用線を維持するために、莫大な運用資金を要するであろう。そのため、バックボーンのようにトラフィックが大きいなところでないと効率が悪い。また、専用線
はあくまで私的な利用目的のために構築されるため、そのサイトにとって無関係なパケットまで中継するかど うかは、そのサイト間の取り決めによる。したがって、それを基盤として公衆な広域ネットワークを構築することは、各サイト間で合意がない限り困難であると考えるべきであろう。
そこで 、第三の方法として考えられるのが 、パケット交換網を利用する方法である。パケット交換とは、データをある一定の規則によりパケッ
トという形に区切り、それを回線上に流すことによって通信する方法であ通信である回線交換方式とは異なり、各パケッる。これはトが多重化されているために 、ユーザが回線を占有することがなくなる。
このため、同時に複数の相手と通信を行なうことが可能となる。また、網はデータパケットを相手に確実に配達することを保証しているために、タイムアウトによる再送などを考慮する必要がなく、信頼性がかなり期待できる。課金に関しては、転送された情報量によって計算されるため、回線が保留状態であっても課金されない。また、通信距離による料金の格差がほとんどないのも特徴のひとつである。

Point-to-Point

以上のことをまとめるとそれぞれの利用形態について以下のようになる。

2.1

からも明らかな様に、平均呼率が低い場合には電話網が有利
この図であり、逆に高い場合は、専用線が有利となる。また、平均保留時間が長い場合には、回線交換方式が有利であり、短い場合にはパケット交換方式が有利である。以上のようにトラフィック量と通信時間により最適な回線が異なってくる。不特定多数の相手と通信する可能性のある広域分散環境
では、あらゆる使われ方を想定しなければならない。そのため、有効範囲の広いパケット交換網を有効に利用できるように改良することは有意義なことである。

2.2

パケット 交換の特徴

パケット交換方式は、大別して仮想回線（バーチャルサーキット ）方式とデータグラム方式に分類される。仮想回線方式は、データ通信に先だって論理的に回線を設立する方式である。回線交換のように物理的に回線を占有するのではなく、交換機内のメモリ上で仮想的に回線が管理される。
このためデータが混信することなく相手に届けられる。また、パケットの32

1989 年度 WIDE 報告書

平均呼率

6

(((
(
(
(
(
(
(
(((1(
(
(
(
(
(
(
(
((((((
11
1
1
1
1
パケット交換網
回線交換網
11
1
1
hhhhhhhhhh1h1 hhh
hhhhhhhhhhh
電話網
特定通信回線

平均保留時間図2.1: 伝送媒体における適応領域

順序制御は網が行なう。
一方、データグラム方式は、網がパケットをそれぞれ独立に扱い、各パケット間の連続性を考慮しない方式である。この方式では、混信防止や順序制御などをユーザ側で行なう必要がある。そのため現在の公衆パケット
網では、バーチャルサーキット方式が広く採用されている。逆にデータグ
ラム方式は、公衆パケット網としては例がない。
この章以降、パケット交換方式とは、バーチャルサーキット方式を意味するものとする。
パケット交換とは、データをパケットという一定の形式に変換し（ 図参照）、それを交換機を経由して送信することにより通信する方式である。この時、通信に信頼性を持たせるため、パケットのヘッダ部には誤り
符号や順序番号などが挿入されている。また、データ通信に先立ち、相手と仮想的に回線を設立するのもパケット交換の特徴である。仮想回線を設立する時に中継交換機が回線番号とアドレスの変換を行なう。データが流れる経路に関しては、この中継機が一切の責任を持つので、計算機は回線番号のみを意識すれば良い。

2.2

第 3部

33

パケット 交換網

IP データグラム?

X.25
packet

図

?

?

X.25
packetX.25
packet?

X.25
packet2.2: IP データグラムのパケット化

以下にパケット交換の特徴を示す。
回線の有効利用 回線を占有する回線交換方式と異なり、パケット交換では
あくまで仮想的に回線を設立しているに過ぎないので、実際にはデータを転送している時のみ交換機を占有している。交換機は、データパ
ケットのヘッダに挿入された仮想回線の番号により、パケットを目的は同時に複地に正しく転送する。
数本の仮想回線を設立することができるため、複数の相手と同時に通信することが可能となる（図）。また、通信時間に関係なく、デー
タ量によって課金することができるため、回線交換方式と比較してコストが安く済む。

DTE (Data Terminal Equipment)
2.3

DTE

から送出されたパケットは、網内の交換機に一旦蓄パケット の蓄積積される。その後、転送される回線の速度に応じてパケットが送出される。したがって、端末間の物理的な回線に速度差がある場合でも、ここで吸収することができる。しかしながら、パケットが交換機に蓄の網内遅延が発生する。このため、パケッ
積されるため、数百参照）
ト交換では、高速通信は期待できない。
（図

msec

2.4

(congestion)

がウィンド ウサイズの制限 パケット交換では、網内で輻輳起こらないようにあらかじめ、で確認応答なしに送信で

End-to-End34

1989 年度 WIDE 報告書

DTE




'
Public
Data
Network

0
0
,,
,
,

````H
&

DTE
0
0$

HHH
HHHj
%
DTE

図

2.3: パケット交換網

きるパケット数を決めておく。これをウィンドウサイズと呼ぶ。このウィンドウサイズは、仮想回線確立時にお互いに取り決めが行なわれる。このとき、交換機が通信に必要なバッファを用意するためデータパケットを取りこぼすことがなくなる。このことによって、網内の信頼性が向上する。送信側では、確認応答を受け取ることによりデータを新たに一つ送信することが可能になる。このように確認応答を受け取るたびにウィンド ウがスライド されていくので、このフロー制御はスライディングウィンド ウと呼ばれる。

パケット の到着順序の保証 データパケットのヘッダ中に順序番号が挿入されている。この順序番号は、ただ単に上述のウィンド ウサイズを認識するためだけでなく、パケットの到着順序を正しく認識することにも利用される。これによりフラグメントされたデータを再び組み立てることが可能となる。また、正しい順序でパケットが到着しなかった場
合は、エラーとみなし 、正しいデータパケットの再送要求を行なう。
これにより、高い伝送品質を保証している。

第 3部

パケット 交換網

交換機

交換機

パケット
端末

キュー

""
"
"

{{{

図

2.3

キュー

{{{

35

パケット
端末

bb
bb

2.4: パケット交換の原理

X.25 プロト コル

X.25 プロトコルは、国際電信電話諮問委員会 (CCITT) が勧告しているパケット交換プロトコル [10] である。X.25 は、レベル 1 (電気特性の規定), レベル 2 (伝送制御手順), レベル 3 (パケット交換手順) の 3 つのレベルに分かれる。レベル 2 の HDLC (High-level Data Link Control protocol)
は、ここでは説明を省く。

3

レベル のパケット交換プロトコルでは、データを送信する前に、仮に簡単に示す。
想回線の確立を行なう。この様子を図

2.5
[103]
CR パケットのフォーマットを図 2.6に示す。
まず、データを送信する前に、CR (Call Request) パケットを用い、仮想回線の設立要求を行なう。この CR パケットには、今後この通信で使用される論理チャネルグループ番号および論理チャネル番号が指定されていと通信するかを
アドレス形式で指定する。
る。さらに、どの桁の数字で、電話番号に相当するものである。まこれは、通常 からた、ファシリティフィールドを用いて、

7

DTE
12

X.121

 ウィンド ウサイズ スループットクラス
 パケットサイズなどを通信相手と取り決めることもできる。ただし 、最終的に決定される
値は、送信側、受信側、網の三者がすべて満足することのできる値である。

361989 年度 WIDE 報告書

発呼

DTE

着呼

DTE

XXX発XX呼 要XX求XX(CR)XXXXz(CA) 
了
完 
続
接 
9
2LL
22
L
2L データ転送
33
LL
3
XXX切X断 要 求
XXXXX(CQ)
XXXXz
(CF)


確認


断

切
9

図2.5: X.25 プロトコルにおけるパケット転送

これらの手順を踏んだ後に、初めてデータ転送が可能となる。データ転送が終了すると、切断パケットを送信し 、仮想回線を閉じる。
2.3.1

パケット 交換網の問題点

パケットをひとつ送信してから 、その確認応答が返ってくるまでの時
間を計算してみる。
（図）RTT (Round Trip Time)2.7
図 2.7 においてパケット長を P, 確認応答 (ACK) 長を A, 回線速度を s,
網内の伝送遅延を T, 計算機内の応答遅延を D とすると、ラウンドトリッ
プタイムは、パケットを送出するのに要する時間 (P/s) 、伝送遅延 T 、パケットを受信するのに要する時間 (P/s) 、計算機内遅延 D 、確認応答を送出する時間 (A/s) 、伝送遅延 T 、確認応答を受信するための時間 (A/s) の第 3部

パケット 交換網

ゼネラルフォーマット
識別子

37

論理チャネルグループ番号

論理チャネル番号
パケットタイプ識別子
発呼アドレス長着呼アドレス長着呼アドレス
および
発呼アドレス
ファシリティ長
ファシリティ
コールユーザデータ

図2.6: CR パケットフォーマット

総和になる。

RT T = (P
P
AA+
T + +D+ +T + )
s
s
s
s

(2:1)

この時間内に送出できるパケット数は、ラウンドトリップタイムをパケッ
ト送出に要する時間で割ることによって求められるので、

n=

RT T
P=s

(2:2)

となる。この個数よりもウィンド ウサイズが大きければフローコントロー
ルは起きない。 故に( Ps + T + Ps + D + As + T + As )= Ps  W(2:3)(3) を T について解くと、T

PW D P + A
2s 0 2 0 s

(2:4)

38

1989 年度 WIDE 報告書

送信側

P/s

パケット交換網

受信側

hhhhL
パケットL
hh#1hh L hh
hhhhhhhhhhhL
hhh hhhh T
L
パケットLLパケットL
hh#2hhhh#1hh L P/s

22((((
ACK
((
(
A
(
(
(
(
A
((((
(
T
(
(
(
(
((
2((ACK
2
A/s A((((
A
P: パケット長
A: ACK 長
図s: 回線速度
T: 伝送遅延D

A/s

D: 応答遅延

2.7: Round Trip Time と最小 window size

T 0
(D) 0

ここで、 > となるための条件を計算する。簡単化のために計算機内のを と置くと、
遅延(W 0 2)P > 2A
よって、

(2:5)

W >2

(2:6)
故に、パケット長や確認応答長に関係なく、最小ウィンド ウサイズは 3 以
上でなければならないことが分かる。すなわち、この値以下であると必ずプ
フローコントロールが起き、データ転送が中断される。ところが、ロトコルでは 、国際リンクは、ウィンド ウサイズが に固定されている。
それにもまして、国際接続では、衛星回線を用いている場合がほとんどでがかなり大きいことが予想される。これは、人工あるため、網内遅延

2

(T)

X.25

第 3部

36000 Km39

パケット 交換網

衛星が、赤道上の上空にあり、地上から発射されたパケットがの遅延を生人工衛星に反射されて再び地上に戻って来るまでに、にパケットサイズ
オクテット、ずるためである。先ほどの式、
オクテット、、
として値を代入
すると、= 9600 bps ack = 3

270 msec(3)= 259
T = 0.27 sec D = 0

s

W > 4:525(2:7)となり、人工衛星を利用した通信では、ウィンド ウサイズがあることが分かる。

5 以上必要ですなわち、国際接続では 、このウィンド ウサイズがボトルネックとなり高速な通信ができなくなっている。この問題を解決するためには、ウィ
プロトコ
ンド ウサイズを大きく取る方法が考えられるが、これではルを無視してしまうことになる。実際には、仮想回線設立時にウィンド ウ
サイズを規定よりも大きく要求しても網の制御により規定値以内に抑えられてしまう。また、通信中に故意にウィンド ウサイズを超えてパケットを転送すると網が回線を切断してしまう。そこで、通信相手に対して、仮想を用いることにより、回線を複数確立するといったマルチリンク手法
プロトコルで仮想的にウィンド ウサイズを増やす方法が考えられる。
は、同一通信相手に対する仮想回線の本数を規定していないため、このマに示す。
ルチリンク手法はプロトコルに違反しない。この概念図を図

X.25

[32]

X.25

2.8

しかしながら 、既存のソフトウェアとの互換性を図るためには 、効率やアルゴ リズムの点で注意しなければならないことが多々ある。この方式のプロトコル体系をいかに崩さずに通信の高速化を図るかが重
では、
要である。

X.25

2.4

WIDE /X.25 の目標

IP

現在、日本において、 接続を行なっているネットワークは、まだ数えるほどしかない。それもほとんどが 、専用線を用いた
接続である。この方式は高速通信には適しているが、費用の面から、このコミュニティに参加できる企業は限られてきてしまう。

Point-to-Point(NTT) DDX-の
わが国の公衆パケット交換網は、日本電信電話株式会社や学術情報センターのなどがあるが 、これらの上では 、ほとは稼働していない。 その理由としては、標準のは、んど
プロトコルをサポートしておらず、網上でを利用するには、ど うしても専用のボードを購入するか、特定の企業からソフトウェアを購入するしかない。これらは、稼働するマシンが限定されてしまったり、

P

X.25

TCP/IPNACSIS

X.25

UNIX

UNIX

40

1989 年度 WIDE 報告書

DTE





DTE

0
'
$
0

0
00
Public
0
Data
,#,#0
,
Network#,#`h`hh``H
hhhHHHHHHH
HHHHHHH
HHHjHjHj%&
DTE

図2.8: マルチリンク方式

ライセンスの問題でそれほど 普及していない。また、ソースコード も入手できないため各種の実験などもできない。
そこで、慶応義塾大学、東京大学、東京工業大学、大阪大学などを中心に、広域分散ネットワークの構築およびその問題点の検討、新たな技術の確立を目的として WIDE
プロジェクトが年に設立された。現在は、広域分散環境における名前空間、ユーザ認証機構、経路制御問題、広域通信におけるプロトコルの研究が行なわれている。本研究で設計・実装されるソフトウェアを WIDEと命名する。WIDE
は、研究目的だけではなく、実用的にも十分使えるように設計しなければならない。

[29] 1988/X.25(Widely Integrated Distributed Environment)/X.25

WIDE /X.25 は 、UNIX 4.3 BSD 上に X.25 プ ロトコルを構築し 、Public Domain Software として無償配布することを目的としている。これは、すべてソフトウェアで書かれるだけでなく、UNIX 4.3 BSD 自体がマシンにほとんど 依存しない OS であるために移植性も良い。これにより、
WIDE プロジェクトの目標である広域ネットワークを構築することが可能となるであろう。

UNIXのアプリケーションは、既存のコマンドを組み合わせたもまた、のが数多くあるのが特徴であるが、これらのものが何ら変更なしに再利用

第 3部

41

パケット 交換網

できた方が便利である。このことは、ユーザアプリケーションだけでなく、ネットワークコードを用いたアプリケーション全般について言える。これは、ネットワークプログラミングにおいて単純にレ イヤリングを守るということだけでは不十分であり、より注意深い考察が必要である。そこで、
WIDEでは 、既存のものについてなるべく変更点を伴わないように設計する。今回の設計では、高速な通信の実現に重点を置くが、通常のをサポートしている専用ボードやサードパーティのソフトウェアと通信できなければ 、WIDE プロジェクトの目標
異機種間接続をも考慮した広域ネットワークの実現を満たしているものとは言えない。
は、ただ単に従来のプロトコルを高速化
さらに、WIDEするだけではなく、先に挙げた経路制御問題や認証機構などの研究をする
際の基盤として利用することを考えている。そのためには、拡張しやすい形で提供されなければならない。そこで、なるべくユーザがあらゆることを細かにしかも動的に指定できるような柔軟なインタフェースを持つことが望ましい。
は以下のことを目標とし
これらのことを考慮した上で、WIDEて設計する。

/X.25

X.25

/X.25

==

==

X.25

/X.25

 効率の良いパケット通信の実現
 移植性の重視
 様々な研究のための柔軟なインタフェースの提供
 従来のアプリケーションに対する透過性
 既存の X.25 ソフトウェアとの接続
ここで、パケット通信の高速化に関しては、前述のマルチリンク手法によって実現する。この章の後半で、効率の良いコネクションの張り方、データソ
転送方式などについて議論する。なお、この議論の中には通常のフトウェアとの互換性をも追求する。移植性および従来のアプリケーショ
ンの再利用に関する実現方法は、この後のレイヤリングの節で論ずることににする。様々な研究のために用意する柔軟なインタフェースは、よって送受信したパケットもしくはフレームをコンソールに出力することができるとともに、各レイヤの情報を出力することができるようにする。

X.25

ioctl()

2.5

UNIX アーキテクチャの問題

ISO による OSI(Open System Interconnection) では 、ネットワーク
アーキテクチャを全部で 7 階層 (physical, data link, network, transport,

42

1989 年度 WIDE 報告書

session, presentation, application) に分割している。それぞれのレ イヤの具体的な機能については、ここでは詳しく触れないが、UNIX のネットワー
クアーキテクチャと比較すると、図 2.9のように対応付けがなされる。
OSI
Application
Sessiontelnetftp
sendmailsocketTransport

TCP / UDP

NetworkIP

Presentation

Datalink
Physical図

UNIX

Ethernet

2.9: UNIX 4.3BSD のレイヤリング

X.25を実装するにあたって、どのレイヤにここで、せるかが問題となってくる。考えられる方法としては、

X.25 の制御を任

1. アプリケーションとして構築する
2. ソケットレイヤの下に新しいプロトコルファミリを作る
3. TCP 内に X.25 の制御機能を持たせる
4. IP の下に新たに制御用のインタフェースを作るがある。ここでは、上記の目標を達成するためにどの構築方法が一番。
優れているかを議論する
プロトコルをユーザプロセスとして実現す
まず、第一の方法は、参照）る方法である。
（図
網を介した通信を行なう時にはまず、を制御しているユーザ
プロセスに要求を送る。この方式では、プロトコルは、
のネッ

X.25

2.10

[99][77]
X.25

X.25

X.25

UNIX

第 3部

USER

43

パケット 交換網

' $
user
' $


process9 : & %network process& %6? $KERNEL 'network
device& %図2.10: プロセスによる X.25 プロトコルの実現

トワークアーキテクチャと全く独立である。よって、比較的実現が容易で、以外のオペレーティングシステム上にも移植しやすい。しかしながのら、ソケットと同じ インタフェースを用意するのが困難なため
従来のネットワークアプリケーションをすべて書き換えなければならなくのユーザプロセスは、コンテクストスィッチによるなる。しかも、
オーバヘッドがあるため、リアルタイム性に欠ける。そのため、到着したパケットを頻繁に取りこぼすことが考えられ、通信効率が悪くなることが予想される。

UNIX

UNIX

UNIX

TCP/IP と同等のレイヤとして定義される（図 2.11 ）。

第二の方法は、

この方式は、ソケットと同じ インタフェースを用意しなければならなのコネクションの制御方式が似ていが、ソケットのコネクションといることを利用して、網内に転送されるパケット数を減らすことができる。
このことにより、転送効率を改善することができる。

X.25

X.25

プロトコルでは、通信に先立ち、呼をすなわち、ソケットおよび設定するためのパケットを送信する。これに対する確認応答が返り、仮想回線が確立されると、データ転送モードになる。データの転送が終ると仮では 、レイヤが異なるの
想回線を解放する。実際には、ソケットとで、ソケットレ イヤの仮想回線設定パケットやその確認応答などはレイヤでは、本来、データとして扱わなければならない。ところが、これ）することにより、
ら意味的に重複しているパケットをマッピング（図送出されるパケットの個数を減らすことができる。

X.25

X.25

2.12

これは 、第三の方式でも全く同じことが言えるが 、コネクションを張441989 年度 WIDE 報告書

telnet ftp
sendmailsocketTCP/UDPIP
Ethernet

図X.25
protocoldevicedriver

2.11: トランスポートレ イヤでの実装

らないデータグラムの時は、マッピングが不可能なので、また別の機能を新たに作らなければならない。
第一から第三の方法で問題となるのが 、ネットワーク間接続されてい
）である。
る場合（図
のインタフェースがこの場合、イーサネットのインタフェースと網に中継異なるために、イーサネットから到着したデータグラムをすることができない。そのためゲートウェイでは、アプリケーションレ イ
ヤで新たに網間接続のためのインタフェースを実現しなければならない。
網に対してもインタネットワークレ イヤを提供する第四
そこで、の方法が考えられる。
これは 、をと同等に考え、データリンクプロトコルと）である。本来、プロトコルは、ではネッ
して扱う方法（図トワークレイヤとして定義されているが、のネットワークアーキテ
クチャ上、データリンクレイヤに属することになる。この方式では、ソケッなどのコネクションを基本とした通信における制御パケットもトやデータとして扱うために 、パケット量が多い。また、すぐ 上のレ イヤは、
レ イヤなので、コネクション管理を行なう
データグラムを基本としたレイヤを作らなければならない。しかしながら、従来のネットワークアプ
リケーションの変更をなんら必要とせず、また、ゲートウェイとしても利用できるという利点があるため、本研究では、この方式を採用する。

2.13

X.25

X.25

X.25

X.25 Ethernet
2.14

TCP

IP

X.25
UNIX

OSI

第 3部

45

パケット 交換網

コネクション
設定要求

socket
layer

P#P
Z
Z


X.25
layer

データ破棄

#?
Call Request
packet"!
図

host A

2.12: パケットのマッピング

gateway
Ethernet

図転送'

X.25 網&$gateway

Ethernet%

2.13: 経路中に X.25 網を含む場合

host B46

1989 年度 WIDE 報告書

telnet ftp
sendmailsocketTCP / UDP
IP
X.25
protocolEthernet device
driver

図2.14: データリンクレ イヤとしての実装

第 3章
WIDE /X.25 の設計
ここでは、WIDE

3.1/X.25 の設計について述べる。

WIDE /X.25 の 4 つのサブレ イヤ

/X.25

4

HDLC, X.25, マルチリ
3.1に WIDE

WIDE
は 、全体で つのサブレ イヤ（
ンク インタフェースレ イヤ）に分割することができる。図
の全体像を示す。

,/X.25

IP-to-X.25

インタフェース
マルチリンクX.25 protocol
HDLC

図

3.1.1

3.1: WIDE /X.25 の全体像

HDLC レ イヤ

HDLC
HDLC

最下位のレイヤは、
モジュールと呼ばれ 、伝送制御手順を規定
では基本機能として、間の回している部分である。
線の接続、切断、データフレームの送信を行なう。回線の設定などのコントロールに関しては 、 ウェイハンドシェークを行ない、回線の状態遷移に矛盾の生じないようにしている。その他、通信の信頼性を高める

DTE - DCE

2

47

HDLC

48

1989 年度 WIDE 報告書

ためフレーム毎にシーケンス番号を振り、この番号の入った確認応答をやり取りすることで、順序誤りやフレームの消失などのエラーから回復でき間で輻輳を抑えるため、スライるようになっている。また、ディングウィンド ウというアルゴ リズムを用いてフロー制御をしている。

DTE - DCE

3.1.2

X.25 レ イヤ

X.25

その上のレイヤは、
モジュールで、通信するマシン間のコネクショで管理する。通常、このレイヤでは、通信したい相手にンを対して 対 で仮想回線を張ることになる。このため、仮想回線が設立されていない相手に対しては、通信に先だって呼の設定が必要となる。この時、相手に対して、ウィンド ウサイズ、スループット、その他のファシリと同様にスライディン
ティなどを取り決めることができる。また、
グウィンド ウを用いたフロー制御を各回線ごとに行なっている。ここで 、と異なるのは、
レ イヤがパケットの再送を行なわないという間は、がフレーム再送機能にことである。なぜなら、間は、網自身が信頼性
よって通信の信頼性を保証しており、でパケットが相手に到達することが保を保証している。結局、証されることになるためである。

End-to-End
1 1

HDLC

HDLC

X.25
DTE - DCE
End-to-End

3.1.3

HDLC
DCE - DCE

Multilink レ イヤ

その上位レ イヤにマルチリンクモジュールを設ける。このモジュール
は、一つの通信相手に対するコネクションを複数本管理する役割を持つ。
の論理回線を 本の回線であるかのすなわち、上位レ イヤに複数のように見せる。従来のでは、各通信相手に対して仮想回線は 本であったが、これを複数本確立する。そして、このレ イヤで、あるマシンに
データグラムを効率良く振り分けることによって、の高速向かう化を実現する。また、回線の使用状況を見て、動的に論理回線の本数を増減する機能を持つ。これにより、バンド 幅を広げ、スループットを向上させることが可能となる。ここで、注意しなければならないのは、 レ イヤ
から見るとただひとつの仮想回線が設立されているように見え、マルチリ
ンクを意識させないことである。つまり上位層からは、回線が太くなったようにしか見えない。

X.25

X.25

1

IP

1

X.25

IP

3.1.4

インタフェースレイヤ

IPIP

最上位のモジュールは、 レ イヤとのインタフェースをつかさどる部
アドレスへの変換、分である。このレイヤでは、 アドレスからその逆変換を受け持つ。そのための情報をテーブルとして持っており、ユー

X.121

[33]

第 3部

パケット 交換網

49IP

ザレベルから追加、削除が可能である。また、 リンクを統括的に管理するため、論理回線の接続、切断などの制御を指示する。

3.2

インタフェースの取り扱い

UNIX

通常、
では、ネットワークに接続されているデバイスに対してインタフェースが割り当てられている。具体的には、という構造体が割などがインタフェースごとに区り当てられ 、名前、ユニット番号、網を一つのネットワークと考え、た別される。この観点からするとだ一つのインタフェースを割り当てるのが自然であるように思われる。この場合、網に対してもネットワークアドレスをただ一つ決めなければ
ならない。

ifnet

MTU
X.25

X.25

しかしながら 、このようにするとルーティングに関して不都合が生じる。なぜならパケット交換方式は、コネクションに基づいた通信を行なう
上にあるため、ブロード キャストという概念が存在しない。現在、ルーティング情報を交換するアプリケーションとしては、やがあるが、これらはブロードキャストもしくは通信でなけ
網にインタフェースをひとつだけ割り当ればならない。したがって、てる方式では、ルーティング情報の交換ができない。この問題に対処するためには、通信するすべての相手に対するエントリを計算機の起動時に静的に登録するという方法が考えられる。しかしながら、広域ネットワーク
では計算機の故障やネットワークトポロジの変更などが頻繁に起こるので、これらの管理は動的に行なわれるのが望ましい。

X.25

UNIX
routed gated
Point-to-Point

そこで、通信する相手ごとにインタフェースを割り当てる方式が考えらになるた
れる。この方式では、通信する相手とのリンクがめ、ルーティング情報の交換も従来通り行なえ、また、通信相手ごとの情報や回線そのものの管理も簡単になる。ところが、このようなネットワー
網のゲートウェイではイ
クアーキテクチャの構築を行なっていくと、ンタフェースが爆発的に増大してしまうことになる。ここで問題になるのが、到着したデータグラムがゲートウェイ自身宛なのか、それとも別のネッ
トワークに転送しなければならないものなのかを判断する時に、膨大な時間を要することである。すなわち、データグラムが到着するたびに、デー
タグラムの目的地のネットワークアドレスに一致するインタフェースを探そうとするためである。

Point-to-Point

X.25

この問題に関しては 、インタフェースのリストの順番を意図的に操作することが必要となるが、この順番は、ゲートウェイ自身にどれくらいの割合でデータグラムが到着するかによっても左右されるものである。した50

1989 年度 WIDE 報告書

がって、何か新しいアルゴ リズムが必要であるが、本研究ではネットワー
クレ イヤまでの変更は考えないことにし 、相手ごとにインタフェースを割り当てる方式を採用する。

3.3

コネクション管理

X.25 プロトコルでは、通信を開始するに当たって、仮想回線を設立しなければならない。このときに、DCE に対して使用する論理回線番号を指定しなければならないが、通常はこの本数に限度がある。NTT の DDX の場合、9600bps で 23 本、48Kbps で 256 本である。したがって、これらの本数分だけ論理回線を張ってしまうと、他の相手と通信を行なうことができなくなってしまう。そこで、コネクションの管理が重要になる。
3.3.1

コネクションの確立

データを転送する一番簡単な方法は、データを送信するたびに仮想回線を設立する方法である。

send_datagram(X.121_addr, data){
open Circuit for X.121 address;
send dataclose Circuit}
しかしながら、この解決方法は二つの面で良くない。第一は、データを送信する際に仮想回線を張るための遅延を生じることである。第二は、経済
では 、コネクションの開設には基本的に的に不利である点である。
など ）では課は課金されないが、その他の公衆パケット交換網（
金されてしまうところもある。したがって、一度オープンした仮想回線はデータグラムの送出中はオープンしたままにしておく必要がある。そこで一般的には、以下のような方法が採られる。

DDX

Telenetif_output(IP_address, datagram){x25addr = convert_IP_to_X.121(IP_address);circuit = select_circuit(x25addr);
x25_output(circuit,datagram);
}

第 3部

convert IP to X.121()
X.121

51

パケット 交換網

32 bit Internet

関数
は非常に簡単で、のアドレス
アドレ スにマッピングするだけである。これはカーネル内のから
テーブル引きによってなされる。ここで、回線選択には、仮想回線の確立を含んでいる。すなわち、仮想回線が既に設定されていれば 、適切な回線を選択する。また、コネクションが存在しない場合は、新たに仮想回線を設立する。
ここで 、既に存在している仮想回線の数が限度以内であれば問題は生じないが、既に限度一杯に仮想回線が設立されている場合には、どれか一つ回線を選択し 、それを切断してから、新しいコネクションを確立する必要がある。すなわち、次のようなアルゴ リズムが必要である。

select_circuit(x25addr){
if (Circuit is open to x25addr)
return Circuit;else {
if (all circuits are in use)
select and close existing circuit;
open a new circuit to x25addr;
return Circuit;}}
ここで、コネクションが設立されるまでのデータグラムの取り扱い方としては、データを破棄してしまうやり方と、データを保存しておき、コネクの上位レイヤが信頼性のな
ションの確立後、転送するやり方がある。
いレ イヤであることを考慮すると、前者でも全く問題ない。この回復
もし くはそれ以上のレ イヤが行なうからである。しかしながら 、は上位レ イヤによるデータの再送までに遅延が生じる可能性があるので、本研究における実装については、データを保存しておく方式を採る。

X.25

IP
TCP

3.3.2

コネクションの切断

前述のように既に論理回線の限度一杯にコネクションが設立されている場合には、どれかの回線を選択して、切断しなければならない。
やでは、データパケットを転送しない限り課金されることはないが、網によっては、保留時間に対しても課金されることがある。そのため、保留時間（アイドルタイム）がある一定値を越えたら積極的に切断する必要がある。

NACSIS
X.25

DDX

52

1989 年度 WIDE 報告書

X.25のレイヤとその上位レイヤとは基本的に独立している
ところが、ため、どの契機でコネクションを切断すべきか判断できない。これは、ある一定時間アイドルしていたら、コネクションを切断するという単純な方法では決してうまく行かない。

DTE

N,
1
N+1
LRU (Least Recentlyに割り当てられている論理回線の本数を通信
たとえば 、あるある場合を考える。このとき、 番から順に
番の相
相手の数が
手に対して定期的にパケットを送出するような場合、
アルゴ リズムによって、切断する回線を選択するものとする。このに対して、 番目の相手に対して通信を試みとき、任意のアルゴ リズムによって最も長時間使用されていない回ようとすると、番目の回線を切断することになる。次に番目の相手線、すなわちに対してデータ送信をしなければならないので、今度は番目の回線を切断する。以後、この繰り返しを行なうと、
ど ちらのアルゴ
リズムを用いても パケット送出するために毎回コネクションの確立／切断をしなければならなくなる。実際問題として、この解決策としては、個以上の相手とは通信しないように限定してしまうか、最悪の場合、 パケット毎にコネクションの確立／切断を行なうかのど ちらかであろう。

N+1

Used)

i (1  i  N+1)
LRU
i+1

i

i+1
i+2
FIFO, LRU

1

1

N

今回の実装では、保留時間を見て、ある一定時間以上経ていればコネクションを切断する方式を採用する。また、どのコネクションも一定時間内であれば 、新しい相手とは通信をしないというポリシーで実装する。これは、既に設立されている回線に優先権を与えるものである。拒絶された
通信は、上位レイヤによる回復が期待される。

IDLETIME high cost low
IDLETIME 0

は、とここで、アイドル時間のパラメータのトレードオフである。なぜなら、を に近付けると、
コネクションを設立する回数が増大し 、不経済であるばかりでなく、デーを大きく取タを転送するまでの遅延も増加する。また逆に、り過ぎると、データ転送までの待ち時間は減少するが、限度以上の要求があった場合には、新たな回線を設立しにくくなる。これは、ネットワークの動的な負荷によるため予測が困難である。したがって、最適値とそれにでは 、デフォルトで 分にしともなう処理が課題である。WIDE
ている。

delay

IDLETIME

/X.25

3.4

1

コネクションの設立方法

X.25 プロトコルの欠点としては、ウィンド ウサイズに制限があることである。これが、網内の遅延と比較して非常に小さいとフローコントロー
ルが頻繁に起こってしまい、伝送速度が低速になってしまう理由となる。

第 3部

53

パケット 交換網/X.25

これを避けるために、WIDE
では 、仮想的にウィンド ウサイズを大きくするために、一ヶ所の相手に対して複数の仮想回線を設立する。
コネクションを設立する最も単純な方法は、 送信側が希望する本数
パケットを送信し 、 さらにこれに対して、受信分の側がパケットで応える、というものである。
では、コネクションを設定した側に課金されるので、この方式は課金論理と）。
の整合性もよい（図CR (Call Request)
CA (Call Accepted)

ii)

i)

X.25

3.2

送信側

受信側

CR (1) XXX
CR (2) XXXXXXXXXXXXzCR (3) XXXX XXXXXCR (4) XXX XXXX XXXXz

XXXX XXXXz
XXXX
(1)
Xz CA


CA
(2)



9 CA (3)9  CA (4)9 
9

CR: 回線設定要求
パケット

図

CA: 要求受け入れ
パケット

3.2: コネクションの設定方法１

2

この方式は、 フェーズでなされているため、シングルリンクの時とほとんど時間的な差はない。したがって、一見効率が良いように思える。しかし 、送信側が希望した本数分のバッファを受信側が用意できない場合、もしくは、通常の実装のようにマルチリンクを認識しないものに対しては、非常に効率が悪い。例えば 、図 では受信側がマルチリンクをサポートしていない場合、複数のコネクション設定要求に対して、最初の一つしか受け入れることができない。それ以外のものについては、
パケットによって着呼拒否をしなければならない。さらに 、送信側では 、パケットに対するとして、パケットを送信しなければならない。
では、合計個のパケットが網内に転送されたが、結果とこの図しては 本のリンクしか確立されていない。さらに、通信を行なうまでに

3.3

CQ (Clear Request)

CQ

Ack

1

3.3

11

CF (Clear Con rmation)

54

1989 年度 WIDE 報告書

送信側

受信側

CR (1) XXX
CR (2) XXXXXXXXX
CR (3) XXXX XXXXXXXXXz
CR (4) XXX XXXX XXXzXXXXXXXXXz
XXX
CA (1)Xz
CQ   CQ (2)9  CQ (3)(4)
9  
9
CF (2) X


X

X
X
9
X
CF (3) XXXXXXXX
CF (4) XXXX XXXXXXXXXXXX XXzXz
XXXXz
CR: 回線設定要求
CQ: 着呼拒否図

CA: 要求受け入れ
CF: 拒否確認

3.3: 通信相手がマルチリンクをサポートしていない場合

3 フェーズ必要である。無駄なパケットを網内に転送することは、むやみに網を混雑させるだけである。よって何か別のアプローチが必要となって
くる。

X.25

プロトコルの体系を崩さず、通常の実装とも通信
今回の目標は、）。これは、まができることにあるので、以下のような方法を採る（図パ
ず、送信側が全体で何本のマルチリンクを張りたいかという要求をケットのフィールドに挿入する。受信側では、
パケッ
トに対する受け入れ応答を返した後、要求された値を満たせるかど うかを
パケットを受信側から送信するという判断し 、満足できる数だけのパケットを受け取った送信側
ものである。この方式の利点は、複数のでは、着呼を拒絶することは絶対にありえないという点である。なぜならパケットを送出した段階で送信側は、将来のために必要な
ば 、最初のリソースを確保しておくからである。また、受信側がマルチリンクを認識
パケットに付加されているを無視する
しない場合は、ので、それ以上受信側からコネクションを設立することはない。結果として 本のリンクを確立することができる。これもやはり無駄なパケットは

3.4

Call User Data

CR

CR

CR

CR

CR

1

Call User Data

CR

第 3部

55

パケット 交換網

流れない。

送信側

受信側

CR (4) XXXX

XXXXX
XXXz
 CA   CR9    CR
9  CR
9XXCA X
9XXXXXXXCA X
XXXXXXXXXzCA XXXX
XXXXXXXXXz
XXXz

CR: 回線設定要求
図

CA: 要求受け入れ

3.4: コネクションの設定２
CRパケッ
この方式では、実際には送信側よりも受信側の方が多くのトを送出することになり、従来の課金体系をそのまま使用すると不公平が生じる。この問題は、着信課金サービスを利用することにより簡単に解決
パケットはすべて着信課金される。すなわち、受信側から送出される要求を行なうようにする。また、着信課金サービスが提供されていない場
合には、仮想回線を 本張ることで課金に対する平等性が保たれる。また、
学術情報網
では課金されないことから今回のような手順を採用
した。

CR

2
(NACSIS)

3.5

データ転送方式

IP データグラムを X.25 網を介して送信する際には、一度 X.25 パケッ
トに分解しなければならない。これを受信側で正し く組み立て、再び IP
データグラムにするためには、X.25 プロトコルの M bit (more bit) を利用する。
（図 3.5参照）
さて 、この IP データグラムをマルチリンク上に配送する方法として

56

1989 年度 WIDE 報告書

X.25

パケット

X.25

パケット

M=1

- M=1



IP データグラム
図

X.25

パケット

- M=0
-

3.5: More bit によるパケットの接続

CSNET INcard

1
がのインタフェースとして採用している方法がある。
は、データグラムを割り当てていく
これは 、マルチリンクの各回線ごとに方式である。すなわち、最初のデータグラムは、 番目の仮想回線に流し 、次のデータグラムは、 番目の回線に割り当てていく方式である）。この方式では、各仮想回線をそれぞれ全く独立なのものとして（図扱っている。このとき、のを使うことにより、データの連続性を認識することができ、 データグラムを組み立てることが可能となる。
これは、通常のの使用方法となんら変わりはない。また、 レ イヤ
では、データグラムの到着順序などを一切保証していないために、送信側
データグラムの到着順序が狂っても問題はない。したがっと受信側でて受信側では、どの仮想回線からデータパケットを取り出そうと自由である。ちなみに、データグラムの到着順序であるが、この方式では、各仮想回線に設けられているウィンド ウサイズの制限により、小さいデータグラ
ムの方が早く到着しやすいのは容易に推測できる。また、データグラムを送出する回線を選択するアルゴ リズムとしては、一番キューの短いものを選んでも良いし 、ラウンド ロビンで選択しても良い。基本的には、回線の使用率を平等にした方が効率が良いので、キューの短い回線を選択すべきであろう。

[13][12]

3.6

M bit

IP

2

X.25 M bit
IP

1

IP

IP

2

ところで、 章のパケット交換網の問題点のところで述べたように、確認応答を返答するまでの計算機内の遅延 は小さい方がフローコントロー
ルが起きにくい。つまり、パケットが到着したときになるべく計算機が混んでいない方が望ましいわけである。

D

今、送信されるデータグラムのサイズがすべて同一であると仮定する。
このとき、受信側では最初のパケットを受け取ってからはある一定の間、
1

INcard は 、Interactive Systems Corporation 社製の X.25 用インタフェースボード
VAX UNIBUS を X.25 ネットワークに接続することが可能である。

で、

第 3部

パケット 交換網

57

データグラム???
B
A A\ ZZ@ c hh
@H
H``

パケット

仮想回線

図

3.6: たてうなぎ方式

データグラムの組み立てを行なうことができない。そして、しばらくした
後、到着したパケットをすべての回線上で一斉にデータグラムとして組み立てなければならなくなる。これでは、確認応答を送出するまでに時間がかかってしまい効率が良くない。
データグラムを複数の回線にまた別のアプローチとしては、一つのがって送出する方法（図）が考えられる。
このアプローチでは、 データグラムを送信側と受信側で正しい順序で受け渡せるだけでなく、同一サイズのデータグラムを送信した場合でも、一定間隔でデータを受信することができる。これにより、一時的に計算機が混雑するということも防げる。ところが 、この方式では 、 データグのはただ単ラムを組み立てることができない。なぜならば 、にデータの連続性を意味しているだけなので、同一回線内でのみ有効である。ところが、回線をまたがってしまうと、はもはや意味をなさな
い。それどころか、の各回線は全く独立しているので、パケットの到
着順序は送信側と受信側では無関係であると考えた方が無難である。したがって、次はどの回線からデータを取り出して良いのか判断できない。

IP

3.7
IP

IP
X.25 M bit

M bit

X.25

IP データグラムを X.25 パケットに分割す

これを解決するためには、

58

1989 年度 WIDE 報告書

データグラム?
?
?
B
A A\ QQ@@ c hh
HH``

パケット

仮想回線

図

3.7: よこうなぎ方式

る際に順序番号の入ったヘッダを付加することである。このようにすれば 、が になった段
受信側では、順番通りにパケットを接続していき、
レ イヤの渡せば良い。この方式は、非常にシン階で、データグラムをプルで実装も簡単である。ところが、余分なヘッダを付加するために、通常のインプリメンテーションと通信ができない。これは、本研究の目標に反する。もしくは、シングルリンクのときは、ヘッダを付加しないような
アルゴ リズムにしなければならなくなる。これは、実装を繁雑にするだけ
でなく統一性に欠けるので良い解決策とは言えない。

M bit 0IP

そこで 、この問題を解決するためには 、送信側と受信側で次にデータパケットを送受信すべき回線をあらかじめ認識してさえすればよい。これ
は、通信を開始するにあたってネゴシエーション用のパケットを送出してフィールド を用いて行も良いが、コネクション設立時にでは 、すでにマルチリンクの本数をこなうことができる。WIDEのフィールドに用いているが、その時に回線の番号も同時に取り決めるよ）。このようにすれば 、余分なヘッダを付加する必要もな
うにする（図
く、受信側がマルチリンクをサポートしているか否かにかかわらず、アルゴ リズムの変更なしに通信することができる。

/X.25

Call User Data

3.8

IP データグラムがマルチリンク上を転送されて行く様子が 、

ここで 、

第 3部

パケット 交換網

送信側

59

受信側

XXXXX
XXXXX
XX
z CA (4-1)
 CR (4-2)
9 CR (4-3)
9  CR (4-4)
9XX
CA (4-2) X
9XXXXXXXCA (4-3) X
XXXXXXXXXz
CA (4-4) XXXXXXXXXXXXXz
XXXz
CR (4-1)

CR: 回線設定要求
図

CA: 要求受け入れ

3.8: 改良されたコネクションの設定

あたかもうなぎの串焼きのような形をしているので、前者の方式を「たてうなぎ方式」、また、後者を「よこうなぎ方式」と呼ぶことにする。
では 、データ転送方式においては各仮想回線
最終的に WIDEを平等に使用し 、一時的な計算機の負荷の増大を防ぐために「よこうなぎ
方式」を採用した。また、回線設立方式に関しては、回線設定要求パケッのフィールドを用い、マルチリンクの本数および
ト
何本目の回線かを明示するようにした。これにより、「よこうなぎ方式」であっても特別なヘッダを付加することなく、データグラムの組み立てが可能となった。

/X.25(CR) Call User Data

第 4章
実装
WIDE /X.25 では 、下から HDLC, X.25, Multilink, IP-interface の4 つの層からなる。どのレイヤも基本的には、3 つのモジュールから構成されており（ 図 4.1 ）、SONY NEWS (NWS 831) OS 3.2 (UNIX 4.3 BSD)
カーネル内に C 言語で 6500 行で実装されている。
'

6

$

タイマ
モジュール

'
送信
モジュール

&

& S%
Sw
$ '

$

% &

%

受信
モジュール

?
図

4.1: 各レイヤ内のモジュール構成

これらのモジュールのうち、送信モジュールは、上位レイヤから起動させられ 、送信するデータのある間はループしている。逆に受信モジュール
は下位レ イヤから起動をかけられ 、やはり処理すべきデータがある間は、ループして繰り返し処理を行なう。タイマモジュールは、オペレーティン
グシステムのタイマによって定期的に起動させられる。
送信モジュールは、データを上位レイヤとの間のキューから取り出し 、
そのレ イヤに必要な情報をヘッダとしてデータに付加し 、下位レイヤの出

60

第 3部

パケット 交換網61

力キューに入れる。

4.1

デバイスド ライバ

4.1.1

受信ルーチンSONY NEWS 831 では、デュアル CPU を採用しているため、IOP からの割り込みルーチンで呼び出される。この関数は、フレーム同期を取る
ための関数である。

syncrint(unit){if (データのサイズが 2 よりも小さい) {エラー処理;
return;}while (データサイズ > 0) {MGET;/* mbuf を取ってくる */mbuf にコピー;
データサイズを減らす;}
IF_ENQUEUE();/* 上位レ イヤの入力キューに入れる */schednetisr(NETISR_X25);/* スケジューリングする */ipc_send();/* IOP 側に処理が終了したことを知らせる */}4.1.2

送信ルーチン

if rsoutput()

デバ イスド ライバの出力ルーチンはで 、上位レ イヤのモジュールとは 、のインタフェースレ イヤの形を取っている。そのため、引数としては、ネットワークインタフェースの構造体へのポインタ、データ受渡し用のへのポインタ、カーネル内でアドレスを管理するための構造体へのポインタからなる。

HDLC

UNIX

sockaddr

mbuf

if_rsoutput(ifp, m, dst){
IF_ENQUEUEU();/* 出力キューにデータを入れる */

ifnet

62

1989 年度 WIDE 報告書
if (送信できる状態にない)
return;/* 出力キューからデータを取り出す */IF_DEQUEUE();/* mbuf --> buf コピー *//* mbuf の解放 *//* IOP へデータ送信の依頼 */bcopy();
m_freem();
ipc_send();}

4.2

HDLC レ イヤ

4.2.1

受信ルーチン

受信ルーチンは、スケジューラから呼び出される。このルーチンでは、
入力キューからデータを一つ取り出し 、その時点での状態に即した処理を行なう。制御フレームを受信した場合は、状態遷移を行なった後、適切なフレームを返送する。データフレームであった場合は、上位レイヤに受け渡す。

ccittintr(){
for (;;) {IF_DEQUEUE();/* 入力キューからデータを取り出す */if (データがない)
return;
アドレス部のチェック;

switch (状態遷移) {case 状態１:
フレームの認識;
状態変数の更新;
受信フレームに伴う Ack フレームの送信;

break;

第 3部

パケット 交換網

63

case 状態２:
処理２;

break;
default:
エラー処理;

m_freem();
}
}
}
4.2.2

出力ルーチン

このルーチンは基本的には上位レ イヤから呼ばれる。すなわち、上位
レイヤのパケットのみを
レ イヤのデータフレームに整形し 、転送すレ イヤ内の制御フレームの転送に関しては、このルーる。従って、
チンは責任を負わない。なお、データフレーム送信の際、網から再送要求が来る可能性があるので、フレームをコピーして格納しておく。これに対する確認応答を受信モジュールが受信したとき、このコピーは破棄される。
よって、再送用のキューは、送信ルーチンからも入力ルーチンからもアクセスされることになる。

HDLC

HDLC

hdlc_output(){
while (ウィンド ウサイズ < 最大ウィンド ウサイズ) {HDLC_DEQUEUE();/* 出力キューからデータの取りだし */if (データがない)
return;
フレーム送信;ウィンド ウサイズの更新;
状態遷移変数の更新;

}
}

64

1989 年度 WIDE 報告書

4.2.3

タイマルーチンWIDE /X.25 では、AF CCITT という新しいド メインを追加していhdlc fasttimo() 200 msec
hdlc fasttimo()

hdlc slowtimo()

は、毎、る。このド メインの追加によりは、の割合で起動される。関数
は、なんらかの原因によりリアルタイムで送信できなかったデータフレームを送信する。
送信すべきデータが無い時は何もせずに終了する。

500 msec

hdlc_fasttimo(){
if (送信可能状態) {while (ウィンド ウサイズ < 最大ウィンド ウサイズ) {HDLC_DEQUEUE();if (データがない)
return;
フレーム送信;}}}hdlc slowtimo() は、タイマ変数を減少させていき、タイムアウトになったかど うかを判断する。タイムアウトになった場合は、状態に適した処理を行なう。基本的には、制御フレームを送信することになる。

hdlc_slowtimo(){
タイマ変数を 1 減らす;if (タイマ == 0) {if (タイムアウト > 最大タイムアウト ) {switch (状態遷移) {case 状態１:
制御フレームの送信;
状態遷移変数の更新;
上位レイヤへ通知;

第 3部

65

パケット 交換網

break;
case 状態２:
処理２;
break;}}}
タイムアウトの回数を 1 増やす;}

4.3

X.25 レ イヤ

X.25

HDLC

ここでは、
レ イヤのモジュールについて説明する。
レ イヤと異なり、送信したデータを再送することはないので、再送用のキューは存在しない。
4.3.1

受信ルーチンx25 input() は、下位レイヤからデータを mbuf を介して受け渡される。
X.25 では、仮想回線という形で通信相手を管理しているため、まず最初に論理回線番号を調べ、対応するコントロールブロックを検索する。コント
ロールブロックとは、論理回線ごとの情報を管理しているデータの集合体のことである。

x25_input(m){LGCN と LCN から回線番号を調べる;
回線番号からコントロールブロックを探す;
パケットの種類を調べる;

if (データパケット ) {RR パケットを送信;
X25_ENQUEUE();66

1989 年度 WIDE 報告書
xml_input(x25cb);/* 上位レ イヤを呼び出す */} else {コントロールブロックの状態変数の更新;
m_freem();/* mbuf の解放 */

}
}
4.3.2

送信ルーチン

この送信ルーチンは 、上位レ イヤからデータを直接受け渡されるのではなく、上位レイヤがデータをキューに入れた後、呼び出す。

x25_data_send(x25cb){
if (HDLC 送信不可)
return;if (X.25 送信可) {while (ウィンド ウサイズ < 最大ウィンド ウサイズ) {X25_DEQUEUE();if (データがない)
return;
データのパケット化;

HDLC_ENQUEUE();
hdlc_output();
ウィンド ウサイズの更新;

}
}
}
4.3.3

X.25

タイマモジュール

500 msec

x25 slowtimo()
2
3

X.25
fasttimo()

レ イヤでは、ごとにが起動する。
レイヤでは、各状態のタイムアウトが長い（ 分から 分）ため、は必要ない。
では 、出力キューに溜っているデータパケッ
トを定期的に送信する役割をする。

x25 slowtimo()

第 3部

パケット 交換網

67

x25_slowtimo(){for (i = 0; i <= 最大コネクション数; i++) {コネクションごとのコントロールブロックを探す;
if (データ送信可)
データ送信;
タイマ変数を 1 減らす;if (タイマ変数 == 0)回線の切断;}}

4.4

マルチリンクレイヤ

X.25 レ イヤでは、各仮想回線ごとにデータを管理していたが、マルチリンクレ イヤでは、ホスト対ホストのデータを管理する。そのため、いく
つかの仮想回線をまとめて管理する必要がある。
4.4.1

コネクションの設立

ここでは 、マルチリンクのコネクションの設立方法に関する実装を説
明する。

/*

上位レ イヤからの接続指示 */xml connect() は 、回線設定要求をするための関数である。この関数が呼ばれると、カーネル内にあるアドレスマッピングテーブルから設立したい
リンク数を決定する。

xml_connect(xifcb){
if (X.25 の論理回線が足りない) {どれかの回線を切断する;
return;}status をコネクト中にする;68

1989 年度 WIDE 報告書
タイマ起動;
マルチリンクの本数を決定し 、下位レイヤに伝える;}/*

接続要求に対する Ack */xml connected() は、上記の xml connect() に対する応答を受け取った場合に下位レ イヤから呼ばれる。ここで、1 回呼ばれる毎にリンクカウントを増やす。それが 、要求した本数と一致すれば 、回線設定が終了したことをただちに上位レイヤに通知する。

xml_connected(x25cb){
if (status == コネクト中) {リンクカウントを 1 増やす;if (リンク数 == 要求した本数) {status = 使用中;
上位レ イヤに通知;}} else回線の切断指示;}/*

通信相手からの接続要求 */xml connectreq() は、網から回線設定要求が到着した場合の処理を行なう。
ここで、通信相手が WIDE /X.25 であるかど うかを判断し 、もしそうであればマルチリンクを何本要求しているかを確認する。相手の要求した値とこちら側の要求する値とを比較し 、少ない本数を最終的なリンク数とし 、
残りの本数分の回線設定指示を下位レイヤに伝達する。

xml_connectreq(x25cb,dte,data){if (通信相手 == \WIDE /X.25) {要求された本数の確認;
回線番号の認識;第 3部

パケット 交換網

69} else {要求は 1 本とみなす;}
for (i = 0; i < 最大ホスト数; i++) {マルチリンクコントロールブロックを探す;

if (X.121 アドレスが一致) {if (status == 使用中) {回線の切断指示;return;} else if (未使用)
status = コネクト中;
CA パケット送信指示; /* CR パケットに対する Ack */if (回線番号 == 0) {if (要求された本数 == 1) {status = 使用中;
上位レ イヤに通知;
return;}
残りの本数だけ CR パケット送信;} else {if (リンク数 == 要求された本数) {status = 使用中;
上位レ イヤに通知;}}
return;}}}70

1989 年度 WIDE 報告書

4.4.2

コネクションの切断/* 上位レ イヤからの切断指示 */上位レ イヤから切断指示があった場合は、該当する通信相手に対するマルレ イヤに切断指示を与える。
チリンクの本数分だけ

X.25

xml_disconnect(xifcb){
for (i = 0; i < リンク数; i++)X.25 レ イヤに切断指示;
上位レイヤに通知;}/* 切断指示に対する Ack */xml disconnected() は、こちら側から送信した接続指示に対する応答である。この関数が呼び出される度に使用していたリンク数を減らしていき、0になった段階で上位レイヤに切断終了を通知する。

xml_disconnected(x25cb){
リンクの本数を 1 減らす;
if (リンク本数 <= 0) {status = 未使用;
上位レ イヤに通知;}}/* 通信相手からの切断要求 */xml disconnreq() は、網側からの切断要求があった時に呼び出され、切断確認パケットを送信するように下位レ イヤに指示を与える。リンクの本数が になった段階で上位レイヤに通信終了を通知する。

0

xml_disconnreq(x25cb)
{

第 3部

パケット 交換網71

CF パケット（ 切断確認）送信指示;
リンクの本数を 1 減らす;

if (リンクの本数 == 0) {status = 未使用;
上位レ イヤに通知;
}
}
4.4.3

受信ルーチン

マルチリンクレイヤでは、「よこうなぎ方式」を採用しているために順
番にパケットを取り込まなければならない。データグラムが完成するまでの間、データパケットを保持している必要がある。このレ イヤでパケットの順序を入れ換えて組み立てるのは容易ではないため、この関数が呼ばれても期待した回線上にデータパケットが存在しない場合には、何もせずに処理を終了する。逆に、順序の正しい回線からパケットを取り出すことに成功すると、中途半端になっていたデータグラムの一番最後にこのパケッにより、データグラムが完成したかど うかトを追加する。その後、を判断する。完成していれば 、上位レイヤにデータグラムを渡す。

M bit

xml_input(x25cb){
for(;;) {X25_DEQUEUE(); /* 入力キューから取ってくる */if (データがない） /* 期待した回線ではない */return;if (M bit == 0) {データグラムを完成させる;
上位レ イヤにデータグラムを渡す;} else {パケットを途中まで組み立てる;

}
}
}

72

1989 年度 WIDE 報告書

4.4.4

送信ルーチン

X.25 のX.25
mbuf

上位レイヤから渡されたデータグラムはサイズが大きいので、の区切りとパケットサイズに分解する必要がでてくる。ここで、のパケットサイズが必ずしも一致しないため、パケットの区切りでをコピーする。

mbuf

xml_output(xifcb){
if (status == コネクト中)
return;for (;;) {IF_DEQUEUE();/* 出力キューからデータを取り出す */if (データがない)
return;for (;;) {if (データ長 > パケットサイズ) {パケットサイズ分だけ mbuf にコピー;
X25_ENQUEUE();
データ長からコピーした分を減らす;} else {データの残りを mbuf にコピー;
X25_ENQUEUE();
break;}}
xml_data_send();
}
}

4.5

IP-interface レ イヤ

IP

このレイヤは、 レ イヤとマルチリンクレ イヤとのインタフェースをつかさどるレ イヤである。このレイヤは、目的ホストに対してコネクションの存在性だけを管理しており、その他の情報は一切持たない。

第 3部
4.5.1

パケット 交換網

73

受信ルーチン

基本的には、下位レ イヤから渡されたデータをキューに入れた後、ス
ケジューリングする。

xif_input(xmlcb,m){
IF_ENQUEUE();/* データを入力キューに入れる */schednetisr(NETISR_IP);/* スケジューリングする */

}
4.5.2

送信ルーチン

telnet などのキータイプによる小さいデータや TCP などの回線を管理するための制御データは、緊急性を要す場合が多いので優先的にキューに入れる。また、回線が設立されていなければ 、接続指示を出す。接続中であれば 、ただちに送信指示を下位レイヤに対して行なう。

xioutput(ifp, m, dst){
小さいデータグラムを優先的にキューに入れる;

if (status == 未使用)
xml_connect();/* 接続指示 */else if (status == 使用中)
xml_output();/* データ送信指示 */}4.6

タイマルーチンこのルーチンは、回線がある一定値以上保留状態が連続した場合、コは、 のタイマによってネクションの切断指示を発行する。
秒に 回の割合で起動される。

1

xi timer()

xi_timer(){for (i =0; i < 最大ホスト数; i++) {コントロールブロックを探す;

OS

15

74

1989 年度 WIDE 報告書
if (status == 未使用)
continue;else if (status == コネクト中) {if (回線設定タイムアウト )xml_disconnect();/* 切断指示 */} else if (status == 使用中) {if (保留時間タイムアウト )xml_disconnect();/* 切断指示 */}}timeout(xi_timer, 0, TIMERINT*hz);}/* 関数の再設定 */

第 5章
評価
WIDE /X.25 は、本来のプロトコル体系をくずさないように設計・実装

NTT の DDX-P や学術情報センターのSun Micro Systems 社の SunLink および SONY ISDNされたため、公衆パケット網である上で、との接続に成功した。

NACSISnet
board
5.1

実験環境

(NACSIS)National Science Foundation

今回の実験は、学術情報網の国際衛星回線を利用して、東
にある
（米国科学
京大学とワシントン同士の接続を行ないマルチリンクの性能測財団）との間で WIDE定を行なった。

D.C.
/X.25

東京大学

使用機種
オペレーティングシステム
インタネットアドレス
アドレス

X.121

表

SONY NEWS-831 SONY NEWS-830
NEWS OS 3.2b NEWS OS 3.2b192.41.192.23
192.41.192.22
9315800
9415010

5.1: 国際回線を使用した実験環境

その他の情報交換機 富士通

米国科学財団

FETEX(NACSIS/X.25) 9600bps
転送データ長 12288 バイト (/bin/echo)
パケット サイズ 128 オクテット
ネット ワーク 学術情報網

75

76

1989 年度 WIDE 報告書

ウィンド ウサイズ

リンク数

1
2
3
4
5

表

2
3
4
5
6
7
2240 3200 2880 5200 5280 6240
2320 6240 6720 7040 5680 5760
3520 7120 7120 7600 7200 7280
7120 6880 6880 7120 7360 7360
6960 6880 7200 7200 7360 7120

5.2: スループット（単位は bps ）とマルチリンク数の関係

第 3部

77

パケット 交換網

throughput(bps)
8000 6

ウィンド ウサイズ=2

4hhhhhh4

7000
6000
5000
4000

,4
,
,
,
,
,
(
(
4
(
4(((

3000
2000

= 128 octets
データサイズ = 12288 Bytes

1000

パケットサイズ

0

図

1

2

3

4

5

-

マルチリンク数

5.1: ウィンド ウサイズ２におけるスループットとマルチリンクの関係

78

1989 年度 WIDE 報告書

throughput(bps)
8000 6ウィンドウサイズ

7000
6000
5000
4000

1
1
|1

3000

1
1
1

1
1
1

|hhhhhh|




11|
11

=3

|

2000
= 128 octets
データサイズ = 12288 Bytes

1000

パケットサイズ

0

図

1

2

3

4

5

-

マルチリンク数

5.2: ウィンド ウサイズ３におけるスループットとマルチリンクの関係

第 3部

throughput(bps)
8000 6

ウィンド ウサイズ

7000
6000

22 2
22 2
22 2
}

5000
4000
3000

79

パケット 交換網=4}} hhhhh

(((h
(

(
(
(
}
}
22
22 2
22 2

2000
= 128 octets
データサイズ = 12288 Bytes

1000

パケットサイズ

0

図

1

2

3

4

5

-

マルチリンク数

5.3: ウィンド ウサイズ４におけるスループットとマルチリンクの関係

801989 年度 WIDE 報告書

throughput(bps)
8000 6
7000

ウィンド ウサイズ






~

6000
5000



!!!~PPPPPP
!
!
~
~!!

=5

~

4000
3000
2000
= 128 octets
データサイズ = 12288 Bytes

1000

パケットサイズ

0

図

1

2

3

4

5

-

マルチリンク数

5.4: ウィンド ウサイズ５におけるスループットとマルチリンクの関係

第 3部

throughput(bps)
8000 6
7000
6000
5000

81

パケット 交換網

ウィンド ウサイズ=6( ((((((
%
%
%%
%%
%







4000
3000
2000
= 128 octets
データサイズ = 12288 Bytes

1000

パケットサイズ

0

図

1

2

3

4

5

-

マルチリンク数

5.5: ウィンド ウサイズ６におけるスループットとマルチリンクの関係

82

1989 年度 WIDE 報告書

throughput(bps)
8000 6ウィンドウサイズ%2%%%
P2 PPP %%
PP2%

7000
6000

=7

2hhhhhh
2

5000
4000
3000
2000
= 128 octets
データサイズ = 12288 Bytes

1000

パケットサイズ

0

図

1

2

3

4

5

-

マルチリンク数

5.6: ウィンド ウサイズ７におけるスループットとマルチリンクの関係

第 6章
考察および今後の課題

6.1

転送速度について前章からも明らかな様に、ウィンドウサイズが十分にとれない時は、本研究で提案したマルチリンクの手法により、通信の高速化が実現された。
倍
具体的には、衛星回線を利用した通信では、従来の方式と比較して通信速度が向上した。本来、この研究で最も効果が現れる状況としては 、
衛星通信などのように、ウィンド ウサイズが小さく、なおかつ遅延が大きいものに対してである。したがって、学術情報網などの遅延の小さい地上
リンクに関しては、物理的な伝送速度を満たしてしまい、マルチリンクの効果が現れにくい。

3.18

6.2

リンク数の動的な変化

今回の実装では、データ転送に先だつコネクション設立時にマルチリン
クの本数を静的に決定していた。ところが 、この方式では、新たに別のリンクを張りたいという要求が上位レイヤから来た時に、論理回線の制約か
ら、この要求を拒絶する可能性があった。また、この値は、あらかじめシ
ステム管理者が相手との平均データ転送量を考慮して決めるものである。
ところが、ネットワークの負荷は動的に変化するものなので、マルチリンクが必ずしも効率良く利用されているとは限らない。そこで、データ転送量にあった動的なリンク数の変更がなされるべきである。
さて、これを今回の実装を変更して実現するためには 、各リンクごとにタイマ変数を変えて、動的にリンク数を減らしていく方法が考えられる。
データ転送量が減れば 、自動的にリンク数が減少していくはずである。ところが、よこうなぎ方式では、すべてのリンクを平等に使用しているため、徐々にリンク数を減らしていくことは不可能である。また、データ転送中にリンクの本数を変化させることは、送信側と受信側でのネゴシエーショ
ンが取れないので矛盾を生じる危険がある。したがって、リンク数を増加

83

84

1989 年度 WIDE 報告書

していく場合でも、データ転送を一時中断して、送信側と受信側で回線の順序番号をネゴシエーションしなおす必要がある。このことは、よこうなぎ方式が、余分なヘッダを付加しない代わりに、各リンク毎に順序番号をつけたことに起因する。
これに対し 、たてうなぎ 方式では各回線をまったく独立に使用しているので、タイマ変数を変えることにより、動的にリンク数を減らすことも可能であるし 、また、過負荷になったときに新たにリンクを設立しても他のリンクに影響を与えることはない。
WIDEの目的として、色々な実験をするためのテストベッドとして利用することが今後あるので、たてうなぎバージョンも作る必要がある。だが、これもマルチリンクレ イヤにおいて、パケットをどの回線に流すかというアルゴ リズムの変更だけで済むので、簡単に実現できる。

/X.25

6.3

パケット の優先順位についてUNIX のインタフェースレ イヤでは、上位レ イヤおよび下位レ イヤとの間に一つずつキューを持つことで、上下のレイヤとデータを受渡ししていた。ところが、のようにコネクションを基本とした通信では 、パケットの種類にもデータとコントロールの 通りある。コントロールパケットは、基本的になるべく早く効力を発揮しなければならない。すなわち、普通のデータパケッ
やといっ
トに比べ、優先順位が高いパケットである。また、たユーザのキータイピングを転送するときにもスピードが要求される。これらのパケットに共通していることは、サイズが小さいということである。
そこで今回の実装では、送信の時にのみ、データサイズをみて、それがよりも小さいならば 、優先的にキューの先頭に割り込むのを許可するというものであった。これにより、稀にしか発生しないコントロールパケッ
トやキータイピングも比較的早くネットワークに転送され、と同時になどを実行しても、さほど遅さは感じられなくなった。

X.25

2

telnet rlogin2

ftp

telnet6.4

X.121 アドレスと IP アドレスのマッピングテー

ブルの更新

/X.25
IP

実装の章で示した通り、WIDE
では、起動時にアドレスマッピ
アドレスとアドレスの静的なテーブルをカー
ングテーブルからネル内に作っている。これは、WIDEに参加するホストが増えるたびに全サイトで一斉に更新

X.121

Internet

第 3部

85

パケット 交換網

されなければならない。このデータベースは、ネットワークインフォメー
ションセンターなどが一括管理して、定期的に配布すべきであろう。ところが、これでは通信する全ての相手のエントリが必要とされるため現実的のではない。アクセスする相手がデータベースになかった時のみ、ように知らない相手が誰なのかを尋ねる作業をする方が実用的である。パケット交換には、ブロードキャストという概念が存在しないので、別のアプローチが必要かも知れないが、ネットワークが大きくなるとテーブルの管理やアップデートを頻繁に行なうことが 、現実的に不可能になってくる
アドレ スとアドレ スのマッピングをどのように動的に行ので、なっていくかは、今後の重要な課題である。

named

X.121

6.5

IP

Maximum Transfer Unit について

Maximum Transfer Unit(MTU) とは、インタフェースレイヤで扱える最大データ長のことである。これよりも大きいデータは、インタフェース
レ イヤで細分化（フラグ メント ）される。さて、広域ネットワークでは 、網 専用線などあらゆる伝送媒体を経由
データグラムは、をいくつに取ると最も効率の良い転送
して転送される。このとき、ができるかという疑問が生じる。

Ethernet, X.25 ,
MTU

X.25

256
MTU 256のパケットサイズがあらかじめバイトだと分かっ
たとえば 、でのをバイトに設定しておていたものとすると、
レ イヤによるフラグ メントは起こらない。これにより、フラ
けば 、グ メントおよびリアセンブルによるオーバヘッドを減少させることができを小さくとることによりデータグラムが細分化る。しかしながら、され、それに付加されるヘッダが多くなくので、結果としてパケット中の有効データ量は減ることになる。

End-to-End

X.25

MTU

逆に大きく取り過ぎ ると、複数の伝送媒体を経由する間に何回もフラグ メントが起こる可能性が高くなる。また、最終目的地に到着した段階でリアセンブルすることになるが、このとき一つでもパケットが到着しないと、 データグラムを組み立てるために、すべてのデータを再送しなければならなくなる危険性も高い。

IP

MTU

はヘッダを付加することによるオーバヘッドとパケッ
このように、
ト喪失に伴う再送のオーバヘッドとのトレード オフである。これは、ネッ
トワークの形態にも左右されるので一概にはどの値が最適かは言えないが、これも今後の WIDE プロジェクトのなかで研究されていくであろう。

861989 年度 WIDE 報告書

6.6

経路選択に関する問題

ネットワークが拡大すると、ある目的地にデータを転送するのに経路のテスト段階で東京が複数存在する場合がでてくる。今回 WIDE大学 東京工業大学間がこのような状態になった。東京大学 東京工業大学間には 、既にの専用回線が敷設されており大部分のトラフィッ
クがこの上を流れている。
さて、このように経路が複数あった場合、現在はそれぞれのインタフェー
アドレ スが割り当てられており、ユーザが経路選択を行ないたい
スに
アドレスを明示しなければならない。これは 、複数の場合には 、このインタフェースを持つマシン上でのみ可能である。しかし 、これらのマシ
アドンを経由した通信を考えた場合、中継ノード のインタフェースのレスまでは指定することはできない。したがって、どちらの経路を通るかはゲートウェイに一切任されることになる。
ところが 、最近ではマルチメディアの研究が盛んになり、通信データ
もテキストファイルから音声、画像データと変化してきており、データ量も増加傾向にある。画像通信では、動画を実現するためには、大量のデー
タ転送をしかも瞬時に行なわなければならない。それに対して、ユーザがどこのマシンにログインしているかといった情報は、それほど高速通信を必要とはしていない。このように、各アプリケーションによって必要とす
る、通信量、遅延、スループット、信頼性、安全性などが異なる。そのため、アプリケーション自体が経路選択に関する要求をデータパケットに挿入する必要がある。
この問題を柔軟に解決する方法としては、 データグラムのヘッダにフィールドが用意されているので、これを利用する方法が考えられる。現在、フィールドは、 （遅延スループット
信頼性 の ビットが用意されている。
を小さく抑えるためのビットであり、このうち ビットは 、ビットは 、高いを、 ビットは、高信頼性をそれぞれ要求するためのビットである。これらのビットを上位レイヤでセットすることで、ポリシーを伝達することができる。このアプローチは、最適経路を選択す
る上でかなり有効である。
たとえば、今、あるサイトと通信するための経路として、衛星通信と専は高いが、衛星用線があるものとする。ただし 、衛星通信はかかるため、が大きい。
と地上の間を電波が伝搬するためにそれに対して専用線は、キャパシティが低いものとする。このとき、のようにユーザからのキーストロークを送る場合、を抑えるためにビットをセットしたとすれば 、専用線が選択される。また、ファイル転

/X.25

{

64Kbps

IP

{

IP

IP

Type Of Service
(

) 3

D

IP

TOS

D

), R

delay
throughput R

T

270ms

D

), T (

throughput
delay

delay

phone

第 3部

87

パケット 交換網

throughput

T

送のように高いを必要とするのであれば 、 ビットをセットすることにより、衛星通信が経路として選択される。
を意識した場合には、回線交換とパケット交換の選
また、特に択が迫られる。 まず、あるサービスにおいて回線交換を必要とするか、パケット交換を必要とするかを考えてみる。その交換方式を決定するための要素として、

ISDN

 Round Trip Time はどれくらい必要か throughput はどれくらい必要か packet size
 window size

throughputが挙げられる。このときも、ファイル転送などのように、を必要とするものは、 ビットを立てることで回線交換を選ぶことができる。
それに対し 、やなどのように、常に小さなデータを送が小さくて良い。また、それほど信するアプリケーションは、やを必要とはしていないので、パケット交換の方が適している。これは、 ビットを立てることで選択される。
伝送媒体の選択においては 、ゲートウェイのインタフェース部で、このフィールドを見て決定することになる。最適経路が、使用できない時に行なわれる経路変更（バックアップリンクの利用）もこの部分で行なわれる。そのため、この部分では、常に各伝送媒体の状態を保持している。
ヘッダのアプ リケーションによる経路選択に関する要求をフィールドに挿入できるので、今後はいかに伝送媒体の混雑度などの状態
をルーティングに積極的に反映させられるかが重要な課題である。WIDE
では、リンクの本数やパケットサイズ、ウィンドウサイズなどをユー
ザが簡単に変更できるインタフェースを提供しているので、これらの研究にも利用できる。

T
rwhod

routedpacket size
throughput round trip time
R

IP

TOS

/X.25

6.7

WIDE /X.25 を用いた研究/X.25

今後、WIDEを用いてどのような研究ができるのかを考察する。
WIDE
では、各仮想回線ごとに/X.25
 window size
 packet size

88

1989 年度 WIDE 報告書

 timeoutが設定できるように作られている。これらを組み合わせることにより様々な実験環境をシミュレートすることが可能となる。
例えば 、 本の仮想回線において、一方だけウィンド ウサイズとパケッ
トサイズを共に小さくしておく。このようにすると、同一目的地に対して速い回線と遅い回線がある状況をシミュレートすることができる。そのため、アプリケーションによってどちらの回線を選択するべきかといった上述の経路選択問題を実験する上で、非常に役立つ。
また、やはり 本の仮想回線を用い、片方のタイムアウト値を小さく設定しておく。すると一方だけ回線が切断されやすくなるので、故障率の大
きい伝送媒体をシミュレートできる。この値を変更すれば 、平均故障間隔や平均修復時間を調整することができ、動的な経路選択やルーティング情報の更新、デー
タグラムの再送などを実験することができる。
さらに 、信頼性の低い伝送路をシミュレートするためには 、通常のマルチリンクを「たてうなぎ方式」で使用し 、すべての回線上に同じデータを転送する。こうすることによって、例え信頼性が低くても多数決を行なうことにより冗長性を持たせることができる。また、バックアップリンクとしての利用も考えられる。
では、データの転送効率から「よこうなぎ方式」
現在の WIDEを採用したが、上記の 例では、すべて「たてうなぎ方式」によって実現される。このように「たてうなぎ方式」もマルチリンクでは重要な役割を演じていることからも、両方の方式をサポートすることが将来の課題である。

2

2(Mean Time Between Failures)(Mean Time To Repair)

/X.25
3

6.8

課金問題について

X.25

プロトコルでは、仮想回線を設立した側にすべて課金される体制になっている。このため、「よこうなぎ方式」では、送信側よりも受信側にほとんど 課金さてしまい経済的に不公平が生じる。現にプロトコル
では、受信側に課金する手段として、「着信課金サービス」が用意されていパケット中に着信課金ファシリティ
る。これは 、仮想回線設立時に、を挿入することによって実現可能である。公衆パケット交換網では課金さに追加するべきであれるのが普通なので、着信課金機能を WIDEろう。
しかしながら 、「たてうなぎ 方式」においても回線が切断される前に、受信側から大量のファイル転送などを実行された場合は、やはり一方だけが不利となる。この問題は、着信課金では解決しないであろう。

X.25

CR

/X.25

第 3部

パケット 交換網

89

また、課金を両方で二分したいといったケースも考えられるので、これらの要求に応えられるような機能を今後用意するべきであろう。

第 7章
結論

高度情報化社会を迎え、日常生活においてもコンピュータネットワー
クの重要性が認識されてきている。次世代である「分散」を実現するためにも、遠隔地に存在している計算機資源をいかに高速にアクセスするかが鍵となっている。

OS

OS

広域分散ネットワークを構築するには、電話網、公衆パケット交換網、、専用線、イーサネット、など様々な伝送媒体を利用した通信を考慮しなくてはならない。これらを統一的に利用するだけではなく、その媒体の持っているキャパシティを最大限に利用しなければならない。デー
タ転送量や回線保留時間、回線速度、転送遅延、課金体系など様々な観点からすると、各々の伝送媒体は一長一短である。

ISDN

FDDI

本研究では、広域分散ネットワークを実現する時に、最も汎用的に利用されるであろうパケット交換について、その高速化の研究を行なった。パ
ケット交換方式では、網内でパケットを蓄積することによる遅延が非常に大きい。また、輻輳制御のため、パケットサイズやウィンド ウサイズに制限が課されている。特に国際接続では、人工衛星までの物理的な距離が遠いため、網内遅延も大きい。そこで、仮想的にウィンド ウサイズを増やすために、同一通信相手に対して、複数の仮想回線を設立する手法（マルチリンク手法）を導入した。
通信相手が通常の実装形態であることも想定して、網内に無駄なパケッ
トが流出しないような回線設定アルゴ リズムを提案した。これは、送信側から複数の仮想回線を張りに行こうとせず、最初の回線設定要求パケットに全体で何本リンクを張りたいかという要求を便乗させる方式である。受信側では、残りのバッファや論理回線数を考慮に入れながら、可能な本数分だけ、逆に仮想回線の設立を試みる。ここで送信側では、最初の回線設
定要求を行なった段階で、あらかじめ希望した本数分の資源を確保してあるため、受信側から来た回線設定要求を拒絶することはない。この方式は、すべての回線が設立されるまでに フェーズ要するが 本目以降の回線設定要求が拒否されることがないなど 、効率面で優れている。

3

2

90

第 3部

91

パケット 交換網

また、データ転送方式においては 、マルチリンクをそれぞれ独立に扱
い、 データグラム単位で仮想回線に流入する「たてうなぎ 方式」とパケット単位でマルチリンクを並列に使用する「よこうなぎ方式」を提案した。本研究では 、データ転送の効率面から 、「よこうなぎ方式」を採用した。この時、マルチリンクのためのヘッダを付加すると、通常の実装方式と通信するのが不可能になる。そこで、回線を設定する段階で、通信相手とパケットを送受信する順番などを取り決めておくことにより、マルチリ
ンクを意識しない通信が実現された。
WIDE
は、
上
、
で開発された。パケット交換網としては 、学術情報センターのおよび 、のとの接続が確認された。また、WIDE以外の、の製品として、のとの接続試験を行ない、いずれも成功した。
WIDEの性能評価を行なうために、をワシントン
にある（米国科学財団）に設置し 、人工衛星を経由して東京大学との間でファイル転送を行なった。この結果、パケッ
ト交換方式において、ウィンド ウサイズが小さく、かつ遅延の大きい通信においては、同一相手に対して仮想回線を複数設立するマルチリンク手法が効果的であることが実証された。今回の測定では、ウィンドウサイズ 、オクテットとしたときに、従来の方式の 倍以上の通パケットサイズ
信速度の向上が確認された。
は、東京大学および東京工業大学において現在、WIDE
網を利用して稼働中である。
年 月をめどにαバージョンを配布予定である。また、 月からは、への移植も行ない、今後はへの移植も行なわれる予定である。

IP

/X.25

SONY NWS-831 NEWS OS3.2 (UNIX 4.3BSD)
NACSISNTT DDX/X.25
Sun Micro Systems SunLink
SONY ISDN board
/X.25
NEWS
D.C.
National Science Foundation

128

SIS/X.25

BSD

3

/X.25

3

1990 3Sun

2

NAC4.4

付録 A
付録

/X.25

CR

WIDE
とマルチリンク接続をするためには 、
パケット中のコールユーザデータフィールドに以下のようなデータを挿入する必要が
ある。
A.1

発呼

CR
1
RFC 877
Internet Protocol
/X.25
3
4 bit

送信側では、マルチリンクの本数を決定後、パケットをただ一つ送信する。このときコールユーザデータの最初の オクテットは、に基づきを挿入する。これは、の識別子である。
WIDE
では、次の オクテットは WIDEの識別子としてを挿入するものとする。また、第 オクテットの上位に要求さは何番目のリンクかを表すものとすれたマルチリンクの本数、下位
では、要求できるマルチリンクの最大数は、る。したがって WIDE
本までである。また、送信側におけるリンクの順番は、必ず でなければならない。

0x33

0xCC
/X.25

1

/X.25

15

A.2

4 bit

0

着呼

CN

受信した
パケットのコールユーザデータの値によって受信側は、異なった動作を行なう必要がある。
A.2.1

WIDE /X.25 識別子があるとき

2

コールユーザデータの第 オクテットに WIDE
場合は、以下の手順を踏まなければならない。

/X.25 識別子がある

リンク番号が 0 のとき受信された

CN パケットのリンク番号が 0 のときは、
92

第 3部

93

パケット 交換網

1. CA パケットを返す。
2. 要求された本数とアドレスマッピングテーブルから最終的なリンク数を決定する。

3. （ リンク数 - 1) 本分の CR パケットを送信する。
ただし 、CR パケットには IP 識別子、WIDE /X.25 識別子、最終的なリ
ンク数、リンク番号が挿入されていなければならない。
リンク番号が 0 以外のとき

CA パケットを返し 、最終的なリンク数およびリンク番号を格納する。
最終的なリンク数だけ回線が確立された後、データ通信を開始する。
A.2.2

WIDE /X.25 識別子がないとき

X.25

CA パケットを通信相手が、既存のプロトコルの実装と判断し 、ただ一つ返し 、ただちにデータ通信を開始する。

94

1989 年度 WIDE 報告書