第 16 部
衛星通信によるネット ワーク構築実験453

第 1章はじめに

1.1 WISH タスクフォース
WISH タスクフォースでは、衛星通信ネットワークと従来の地上網を融合しインターネッ
トの新しい課題の解決を目的とするネットワーク構築実験を行なっている [140]。
インターネットは大きく成長を遂げ、次世代の情報通信基盤として注目を集めている。接続地域が広がるにつれ、その規模性はより一層重要となっており、地理的普遍性をもつ衛星通信はこれを満たすインターネット メディアとして期待できる。また、衛星通信には回線設定の柔軟性や通信局の設置の簡易性といった利点や、片道約 250ms の遅延といった特徴がある。WISH タスクフォースではこれらの特性を考慮した WISH ネットワークの構築
実験や運用を行なっている。
本稿では、1995 年度における以下のような研究・実験を報告する。

 衛星通信ネットワークと地上ネットワークを統合した動的なネットワーク形成に関する研究 衛星通信ネットワークに対応したトランスポートプロトコルの研究 衛星通信ネットワークを利用したマルチキャスト配送実験
なお、WISH タスクフォースにおける衛星通信は、「ディジタル衛星通信の大学間高度共同利用研究協議会」の実験可搬局免許を用いた (株) 日本サテライトシステムズの衛星通信
回線、および (株) 日本サテライトシステムズとの随時分割契約による衛星通信専用サービスを用いて行なわれている。

1.2 WISH における衛星通信環境
WISH のネットワーク環境では、超小型地球局 VSAT による衛星通信地球局が日本全国9 地点に 12 局設置されている (図 1.1)。
VSAT はパラボラアンテナ、屋外装置 ODU 、屋内装置 IDU から構成される (図 1.2。
データの送受信のための計算機との接続は、双方のシリアルインターフェースを通じて最455

1995 年度 WIDE 報告書

456

WNOC-SPKJAISTWNOC-NARA(AIST-NARA)
WNOC-FUK(KYUSHU-U)
WNOC-KYOTO

U-TOKYO
JSAT-TOKYO
JSAT-EDC
WNOC-SFCJCSAT-1

図 1.1: WISH ネットワーク

第 16 部

衛星通信によるネットワーク構築実験457

大 2Mbps の通信速度で IDU と接続される [141]。また、通信の各種設定も IDU によって行なわれる。

RS-449/422
DTE

RS-232CIDU

ODU

ANTENNA

図 1.2: VSAT の構成

VSAT における通信は、送信局の送信チャネルと受信局の受信チャネルを合致させて行う。ここでいうチャネルとは、衛星へ送信するアップリンク周波数と衛星から受信するダウンリンク周波数の組を意味する。
また、本研究で使用した地球局では、TDMA (Time Division Multiple Access) の機能はなく、同時に複数局から通信を受信することは出来ない。

第 2章
インターネット のための衛星通信制御機構の構築
世界的規模へと成長したインターネットでは、接続地域が広がるにつれ、その規模性はより一層重要となっている。また、インターネットの利用形態は多様化し 、動的に自由にトポロジを形成する通信媒体に対する要求も高い。このような状況における通信媒体として、衛星通信の重要性が高まっている。
これらの要求を満たす衛星通信と従来の地上ネットワークを統合したインターネットの構築を目的に、衛星通信ネットワークにおけるトポロジモデルを考案した。このモデルを実現するための衛星通信ネットワーク制御機構の設計・実装を行なった [142][143]。
また、本機構を用いた実験を、実際の衛星通信ネットワーク環境や衛星通信ネットワー
クをシミュレートした環境の上で行ない、実用性を実証した。
本機構で用いた機構により衛星通信ネットワークを統合したインターネットの構築が実現することで、今後同報型マルチメディア通信の効率化、地理的条件に因われない接続性を得ることが可能になる。また、衛星通信局の設置簡易性から非常時におけるバックアップ回線としての利用も実現できる。

2.1

研究課題

2.1.1 多地点間の相互通信の仕組みに関する課題
1 つ以上の送信周波数を複数の衛星通信局でいかに効率良く共有しながら、多地点間の相互通信を実現することが出来るかを考えなければならない。
解決方法の 1 つとして、ALOHANET[144] のようなデータリンク層の通信プロトコルによる方法がある。この方法は、複数の通信局で単一の周波数を共有し衝突の検出と再送を行なうため、回線利用率が高い場合の通信効率が低下する。
そこで本研究では、データリンクプロトコルに依らず地上ネットワークを併用することによって送受信局間で相互通信が出来る機構の構築を行なう。

458

第 16 部

衛星通信によるネットワーク構築実験

459

2.1.2 経路制御に関する課題
巨大なインターネット上の全てのネットワークに対する経路情報を静的に設定することは非効率的であることは明らかである。そのため、経路を動的に制御するためのプロトコルが規定されており、これに基づく実装もいくつか存在する。しかし 、そのどれもが隣接ノードを通して経路情報の交換を行なうことによって経路の設定を行なう。しかし 、衛星通信ネットワークを単方向の同報型ネットワークとして構築する場合既存の経路制御技術の利用はできない。このような点から衛星通信ネットワーク上で経路制御プロトコルが動作可能な環境の構築を図る。

2.2

設計

以下のような方針に基づいて衛星通信制御システムの設計を行なった。

 形成する衛星通信ネットワークは 1 つにする
 切替可能な同報型ネットワークトポロジを形成する
一対多型トポロジを形成することが出来れば 、一対一型通信に対応することも出来る
ため、この中で送信者の切り替えを制御するものとする。

A

B

C

D

A

B

A

C

B

C

D

D

図 2.1: トポロジ切り替え
また、受信者間の通信、および受信者から送信者への通信は地上ネットワークを併用する。

 トポロジの制御は 1 台の計算機で集中制御する
 使用する通信周波数チャンネル、データの通信帯域は一定とする

これらの方針のもと、図 2.1で示すような疑似多対多型衛星通信ネットワークを構築する。

1995 年度 WIDE 報告書

460

2.3

システム構成本システムは以下のモジュールから構成される。

 衛星通信ネットワーク対応データリンク層
VSAT におけるデータ通信には IDU のシリアルインターフェースが用いられる。一般的にシリアルインターフェースを用いたネットワークは一対一型の接続以外考慮されていない。しかし衛星通信の同報性を利用するためには、データリンクのアーキテクチャとして一対多型の接続に基づかなくてはならない。そこで、一対多型接続が可能なシリアルインターフェースを用いたネットワークドライバが必要となる [145]。

 衛星通信機器制御部

本研究で用いる衛星通信は、各所に設置された IDU の設定を通して行なわれる。そのため IDU の制御を通じて計算機から実際の衛星通信に関する設定を操作するモジュールが必要となる。

 トポロジ制御部

オペレータの判断に合わせた衛星通信ネットワークのトポロジを形成するためには、全ての地球局で統一的な協調作業が必要となる。このために各所の IDU を制御する
計算機をさらに統合管理する機構が必要となる。

 ネットワーク構成部
次章にて詳述。

2.4

ネットワーク構成部概要

衛星通信ネットワークが任意のホスト間の通信経路に含まれるようになるためには、動的に経路情報を制御するプロトコルを動作させる必要がある。しかし 、衛星通信ネットワー
クを単方向型ネットワークとして構築するため既存の経路制御技術をそのまま使用することは出来ない。また、送信衛星通信ホストの切り替えによる他ネットワークへの影響は大きい。このような問題を考慮に入れ衛星通信ネットワーク上で経路制御プロトコルが動作する環境を設計する。

2.4.1 仮想リンク完全結合方式
送信衛星ホストと受信衛星ホスト間において地上側ネットワークインターフェースを用いた仮想リンクを設定し 、更に衛星側インターフェースと仮想リンクインターフェースを統合した仮想インターフェースを用意する (図 2.2) 。これにより、送信衛星ホストが任意の受信衛星ホストとの双方向通信を行なうのに往路には衛星通信ネットワークを使用でき、復路には仮想リンクネットワークを使用できる。

第 16 部

衛星通信によるネットワーク構築実験

461

SAT

SAT: 通信衛星
S:
送信衛星通信ホスト
R:
受信衛星通信ホスト
通信衛星ネットワーク
地上ネットワーク
仮想ネットワーク

sif:
pif:
vif:

衛星通信ネットワーク
インターフェース
地上ネットワーク
インターフェース
仮想インターフェース

(vif)

(sif)
S (vif)
(le)
(sif)
R2
(vif)
(pif)

(sif)
(vif)
R1
(vif)
(pif)

(vif)

インターネット

図 2.2: 仮想リンク完全結合方式
衛星ホストの数を n とすると送信衛星ホストが切り替わることを考えた場合、全ての衛星ホスト間で完全結合グラフを形成するためには n(n-1)/2 個の仮想リンクを設定する必要が生じ 、n に対する規模性は乏しい。

2

2.4.2 仮想ゲート ウェイ方式
SAT

SAT: 通信衛星
S:
送信衛星通信ホスト
R:
受信衛星通信ホスト(sif)S

通信衛星ネットワーク
地上ネットワーク
仮想ネットワーク

sif:
pif:
vif:

衛星通信ネットワーク
インターフェース
地上ネットワーク
インターフェース
仮想インターフェース

(vif)
(sif)
R1

(vif)

VGW
(pif)

(vif)

(sif)
R2

インターネット

図 2.3: 仮想ゲートウェイ方式

衛星通信ネットワークへの仮想ゲートウェイを作り、仮想ゲートウェイと送信衛星ホス
ト間で仮想リンクを設定する (図 2.3)。受信衛星ホストから送信衛星ホスト、受信衛星ホス

1995 年度 WIDE 報告書

462

ト間の通信についても仮想ゲートウェイマシンへの仮想リンクを通して行なえる。
経路制御に関しては、仮想リンク完全結合方式と同様に衛星側インターフェースと仮想リンクインターフェースを統合した仮想インターフェースを仮想ゲートウェイと各衛星ホスト間に設ける。
送信衛星ホストがほぼ固定され近隣に仮想ゲートウェイが配置されている場合には有効な方式となるが、送信衛星ホストの切替が瀕雑に起こったり、地上ネットワークにおける仮想ゲートウェイと送信衛星ホスト間の経路コストが大きい場合には冗長な経路が生ずる可能性がある。
仮想リンクに関する設定は VGW と衛星通信ホスト間で必要であり、その個数は n である。

2.4.3 仮想ゲート ウェイ仮想リンク完全結合併用方式
仮想リンク完全結合方式と仮想ゲートウェイ方式を組み合わせた方式である (図 2.4)。近隣の衛星ホストでは仮想ゲートウェイを共有することで、両方式のそれぞれの長所を取り入れることが出来る。
しかし 、仮想ゲートウェイの配置方法に対する最適な解を見付けることが難しい。

SAT

SAT:
S:
R:

通信衛星ネットワーク
地上ネットワーク
仮想ネットワーク

sif:
pif:
vif:

(vif)

通信衛星
送信衛星通信ホスト
受信衛星通信ホスト

衛星通信ネットワーク
インターフェース
地上ネットワーク
インターフェース
仮想インターフェース

(sif)
R1

(vif)

(sif)
S
(vif)

(sif)
R2

VGW2
(vif)
(pif)
(vif)
(vif)

VGW1
(vif)
(pif)

(sif)
R3
(vif)

VGW3
(pif)

インターネット

図 2.4: 仮想ゲートウェイ仮想リンク完全結合併用方式

2.4.4 ネット ワーク構成部のまとめ
ネットワーク構成部として 3 つの方式を提示した。これらの方式の特徴を表 2.1まとめ
ると、

第 16 部

463

衛星通信によるネットワーク構築実験

表 2.1: ネットワーク構成方式のまとめ
大規模性
仮想リンク完全結合方式
仮想ゲートウェイ方式
仮想ゲートウェイ仮想リンク完全結合併用方式

×○△

経路の冗長性○×△

広域ネットワークおいては仮想ゲートウェイ仮想リンク完全結合併用方式は最も適した方式である。しかし 、経路に関する設定の複雑さと本研究の現在の環境を考慮し 、仮想リ
ンク完全結合併用方式の実装を行った。

2.5

評価

2.5.1 ト ポロジ制御部の評価
衛星ネットワーク上で送信衛星ホストの切替えが起こった場合のオーバーヘッドについて評価を行なった。
衛星通信ネットワーク上にない計算機から任意の衛星ホストへ 64 バイトの ICMP エコー
要求を送り続けながら、トポロジ制御ホスト (TC) を通じて衛星ネットワークの送信者を切替えることを行なった。この時の ICMP エコー要求パケットのシーケンス番号と RTT
時間の変化を図 2.5に示す。

現送信衛星ホスト (S) への送信停止命令から、次の送信衛星ホスト (S') の送信開始まで
は数秒の時間がかかり、その期間中は衛星通信ネットワークへの通信が行なえなくなる。図2.5から 2 度目の送信衛星ホスト変更においてシーケンス番号 59 のパケットが 1 つ到達していないことが分かる。
また、送信衛星ホスト切替えに要する時間を計測した (10 回当たりの平均)。これは IDU制御に関する時間、すなわち IDU 内での処理時間と IDU 制御計算機との通信時間の合計を一定とすると、TC-S 間、TC-R1 間の往復時間 (RTT: Round Trip Time) に左右される。
そこで、トポロジ制御計算機から各 IDU 制御計算機間の通信状況からトポロジ変更に要す
る時間についても計測し 、RTT と合わせて表 2.2に示す。
表 2.2の切替え所要時間には、TC{S 、TC{R1 間の通信のオーバヘッドなどが含まれている。この間の RTT がより大きい衛星通信ホスト間において同様な送信者切替えを行なった
場合にはより多くの所要時間が費される。特に本実装では、TCP を用いたために 3 ウェイ
ハンドシェークなど通信のオーバヘッドが大きく、UDP を用いるなどして改善する余地がある。しかし 、会議システムにおいて発言者に合わせてトポロジを切替える場合等には十分短い時間である。

464

1995 年度 WIDE 報告書









% ping 133.4.120.1
PING 133.4.120.1 (133.4.120.1):
icmp_seq=10 time=4.142 ms
icmp_seq=11 time=4.307 ms<- この後、切替
icmp_seq=12 time=339.609 ms
icmp_seq=13 time=421.229 ms...
icmp_seq=57 time=4.793 ms
icmp_seq=58 time=3.877 ms<- この後、切替
icmp_seq=60 time=292.877 ms^C--- 133.4.120.1 ping statistics --60 packets transmitted, 54 packets received,
9% packet loss
round-trip min/avg/max = 3.748/117.971/421.229 ms
図 2.5: トポロジ変更の様子

表 2.2: 送信者切替所要時間

IDU 処理 TC{S 間 TC-R1 間 切替所要
419 ms3 ms
110 ms 1450 ms

第 16 部

衛星通信によるネットワーク構築実験

465

2.5.2 経路制御部の評価
送信衛星ホストの切替えに応じて、衛星通信ネットワークで経路制御プロトコルが正しく動作するか評価を行なった。ここでの評価は実際の衛星通信ネットワーク上ではなく疑似的な環境のもとで行なった。図 2.6にこの環境を示す。
受信衛星通信ホスト

送信衛星通信ホスト
S

R

代替衛星通信ネットワーク
1

133.4.68.0

2
33

34

133.4.68.32
34

ルータ

13

3

133.4.34.0
2

地上ネットワーク

トポロジ制御ホスト

H2

H1

図 2.6: 中継ネットワークとしての評価環境
高速シリアルインターフェース間を回線エミュレータを用い 64Kbps の通信速度で設定
し 、衛星通信ネットワークとして想定する。S を送信衛星通信ホスト、R を受信衛星通信
ホストとして想定した。
図 2.6における H1 、H2 の経路表 (一部省略、以下同様) をそれぞれ図 2.7 、図 2.8に示す。

$ netstat -rn
Routing tables
Internet:
Destination
133.4.34/27
133.4.68/27
133.4.68.32/27



Gatewaylink#1133.4.34.3
133.4.34.3

Flags
UC
UG
UG

Interface
we0
we0
we0

図 2.7: H1 における経路表



これにより、ホスト H1 からネットワーク 133.4.68.32 への経路は代替衛星通信ネットワー
クを経由することが分かる。また、逆にネットワーク 133.4.68.32 上のホスト H2 からネッ

466



$ netstat -rn
Routing tables
Internet:
Destination
133.4.34/27
133.4.68/27
133.4.68.32/27

1995 年度 WIDE 報告書

Gateway133.4.68.34
133.4.68.33
link#5

Flags
UG
UG
UC

Interface
ne0
ne0
ne0

図 2.8: H2 における経路表



トワーク 133.4.34.0 への経路は代替衛星通信ネットワークを経由せず地上ネットワークを経由することが分かる。
ここで、送信衛星通信ホストを S から R へ切り替えトポロジを変更する。経路の再設定がなされ安定した後の H1 、H2 の経路表をそれぞれ図 2.9 、図 2.10に示す。 ホスト H1 か$ netstat -rn
Routing tables
Internet:
Destination
133.4.34/27
133.4.68/27
133.4.68.32/27


Gatewaylink#1133.4.34.3
133.4.34.13

Flags
UC
UG
UG

Interface
we0
we0
we0

図 2.9: トポロジ変更後の H1 における経路表

らネットワーク 133.4.68.32 への経路は代替衛星通信ネットワークを経由せず、逆に H2 からネットワーク 133.4.34.0 への経路は経由するよう変更されたことが分かる。
トポロジ変更の前後双方共に、送信衛星ホストから受信衛星ホストへは中継ネットワー
クとして機能し 、逆の経路は仮想リンクを経由せずに地上ネットワークを用いるように設定され、適切な経路設定がなされていることが確認できた。



第 16 部$ netstat -rn
Routing tables
Internet:
Destination
133.4.34/27
133.4.68/27
133.4.68.32/27



2.6

衛星通信によるネットワーク構築実験

Gateway133.4.68.34
133.4.68.33
link#5

Flags
UG
UG
UC

467

Interface
ne0
ne0
ne0

図 2.10: トポロジ変更後の H2 における経路表




まとめ

既存の地上ネットワーク上では実現出来なかった動的トポロジ形成の仕組みを衛星通信を用いることで実現した。衛星通信の特徴である同報性、接続形態の柔軟性、地理的な普遍性を活かすだけでなく、通信形態や目的などの要求に応じてネットワークトポロジの管理・制御をすることが可能となった。
本機構での特徴は、次の通りである。

 衛星通信ネットワークの接続形態を必要に応じて自由に設定・変更できる点
 接続形態を変更した場合他のネットワークにあたえる影響を抑制する点
 双方型通信媒体を基本とするインターネットにおいて同報型単方向の衛星通信ネット
ワークを統合した点
また、衛星通信ネットワークを用いた実験及びシミュレーションによって評価を行ない衛星通信を用いたネットワークがインターネットの 1 つとして十分利用可能であることを示した。
今後の課題は、実際に衛星通信ネットワークをインターネットの一部として運用することである。また、形成するネットワークの個数やトポロジを限定しないより複雑なトポロジの形成や、ネットワークの状態を地上ネットワークと合わせて監視し最もトラフィックの多い地点間へ接続を切り替えるといった自動的なトポロジ切替え機能の研究が必要である。

第 3章
衛星回線における TCP の研究
WISH のこれまでの実験結果より、従来の TCP では、衛星回線のような広帯域高遅延の環境において、ウインド ウサイズの限界により、帯域を有効に利用することができない
ことがわかった [146][147]。

Van Jacobson は、RFC1323[148] においてギガビットネットワークに対する TCP の改善案を提案した。RFC1323 による提案の中には、TCP の新しいオプションとしてウインド
ウスケールオプションを追加することが含まれている。ウインド ウスケールオプションを用いることにより、TCP では、230 1 までのウインド ウサイズを指定することができる。

0

本節では、RFC1323 を用いた場合の衛星回線上における効果をシュミレーションなどから解析し 、その問題点と解決策の考察を行なった [149]。

3.1

ネットワーク構成

図 3.1に、本シミュレーションで使用したネットワークの構成をを示す。ノード 1 、2 は、それぞれ Ethernet に接続されている。Ethernet の帯域は、10Mbps 、伝搬遅延は 50nsec に設定した。ルータ 3 、4 の間は衛星回線に接続されている。衛星回線の帯域は、2Mbps 、伝搬遅延 500msec に設定した。ルータのバッファサイズは 20Kbyte とした。

10Mbps50nsec delay

2Mbps
500msec delay

Router3

10Mbps50nsec delay

Router4

Node1

Node2

図 3.1: ネットワーク構成468

第 16 部

3.2

衛星通信によるネットワーク構築実験

469

シミュレーション結果

ある経路上の通信における最適なウインド ウサイズは、以下の計算式で求めることができる。

最適なウインド ウサイズ =経路上の一番細いリンクの帯域
経路全体の伝搬遅延(3:1)

この式を用いて、図のネットワーク構成の場合の最適なウインド ウサイズを求めると、2Mbps=8 2 500msec = 125Kbyteとなる。この構成において、ウインドウサイズを変えてノード 1 からノード 2 に向けて、
60Mbyte のデータ転送を行なった。
図 3.2 に 従来の TCP のウインド ウサイズの最大値 (65535byte) で通信を行なった場合の結果を示す。転送開始後、最初の数秒でウインド ウサイズが 65535 バイトに達し 、以後変化がないことがわかる。図 3.3に帯域の利用率を示す。50%程度で帯域利用率が安定していることがわかる。
この場合は、ウインドウが最大値の 65535 バイトまで達しているが、ネットワークの帯域に対して、ウインドウサイズが小さすぎるために、帯域の 50%程度しか利用できていない。
図 3.4 に、計算で求めた最適なウインドウサイズ (125Kbyte) で通信を行なった場合の結果を示す。図より、最初の数秒でウインド ウサイズが最大値の 125Kbyte に達し 、以後変化がないことがわかる。図 3.5にこの時の帯域利用率を示す。帯域利用率がほぼ 100%に達していることがわかる。
この場合、ネットワークの帯域に対しウインド ウサイズが最適なため、ネットワーク資源を有効に利用できている。
図 3.6 に、最適なウインドウサイズの 2 倍の大きさ (250Kbyte) で通信を行なった場合の結果を示す。この場合、ウインド ウが最大値まで開き切る前に、輻輳が起こり、再度ウイ
ンド ウが開き始め、また輻輳するというウインド ウサイズの振動現象が観測されている。
図 3.7にこの場合の帯域利用率を示す。帯域利用率が頻繁に変化し 、平均帯域利用率が低くなっていることがわかる。この場合、ネットワークの帯域に対してウインド ウサイズが大きすぎるため、輻輳が発生し 、ネットワーク資源を有効に利用することができない。

3.3

シミュレーションによる考察

以上の結果により、TCP による通信では、帯域を有効に利用するためには最適なウインド ウサイズを指定する必要があることがわかった。ウインド ウサイズが小さくても大きくても帯域を有効に利用することができない。

1995 年度 WIDE 報告書

470

Window (Kbyte)

200

100

0
0

50

100

150
time (sec)

200

250

300

図 3.2: 最大ウインドウサイズ 65535byte のデータ転送時のウインド ウサイズの変化

Utilization (%)

100

50

0
0

50

100

150
time (sec)

200

250

300

図 3.3: 最大ウインド ウサイズ 65535byte のデータ転送時の帯域占有率の変化
現在の TCP では、setsockopt() システムコールを用いてウインドウサイズの指定を行なう。しかし最適なウインド ウサイズは、通信を行なうノード 間の経路によって異なる。このため、setsockopt を用いて最適なウインド ウを指定する方法は以下のような方法に限定される。

1. 接続されるネットワーク毎にアプリケーションを用意する。
例えば 、衛星回線につながるインターフェースを持つノード 上でのアプリケーション
は、予め大きめのウインドウサイズで通信を行なうように設定しておく。

2. アプリケーションの起動時にウインド ウサイズを設定する。
アプリケーションの引数にウインドウサイズを指定をするように設計する。
しかし 、1 の方法では、2 つ以上のネットワークインターフェースを持つノードや、ネッ
トワークの構成変更に対応することができない。2 の方法では、アプリケーションの利用

第 16 部

衛星通信によるネットワーク構築実験

471

Window (Kbyte)

200

100

0
0

50

100

150
time (sec)

200

250

300

図 3.4: 最大ウインド ウサイズ 125Kbyte のデータ転送時のウインド ウサイズの変化

Utilization (%)

100

50

0
0

50

100

150
time (sec)

200

250

300

図 3.5: 最大ウインドウサイズ 125Kbyte のデータ転送時の帯域占有率の変化

者があらかじめ最適なウインド ウサイズを知っている必要がある。いずれの方法も柔軟性に欠け、良い解決策ではない。
この問題に対処するためには 、setsockopt() システムコールによる固定的なウインド ウ
サイズ指定の仕組みではなく、より柔軟なウインドウサイズの指定の仕組みが必要である。

3.4

新しいフロー制御機構

これまでの考察から、現在の TCP では最大のスループットを実現するためには最適なウインド ウサイズを指定する必要があることが分かった。しかし 、最適なウインド ウサイ
ズは、パケットが通過する経路ごとに異なり、コネクション毎に異なる値を決定する必要がある。
これらのことから、各コネクションがデータ転送を行ないながら最適なウインド ウサイ

1995 年度 WIDE 報告書

472

Window (Kbyte)

200

100

0
0

50

100

150
time (sec)

200

250

300

図 3.6: 最大ウインド ウサイズ 250Kbyte のデータ転送時のウインド ウサイズの変化

Utilization (%)

100

50

0
0

50

100

150
time (sec)

200

250

300

図 3.7: 最大ウインドウサイズ 250Kbyte のデータ転送時の帯域占有率の変化

ズを推測するアルゴ リズムの設計を行なった。

3.4.1 基本設計方針
新しいフロー制御機構は、以下の設計方針に基づいて行なった。

 広帯域、高遅延ネットワークにおいて高いスループットを実現する。
 狭帯域や低遅延のネットワークにおいても従来の TCP に劣らないスループットを実現する。

 TCP のウインド ウ更新アルゴ リズムを変更する。
 スロースタート、輻輳回避アルゴ リズムには変更を加えない

第 16 部

衛星通信によるネットワーク構築実験

473

 CPU の負荷が大きくなりすぎないように 、できるだけ簡単なアルゴ リズムで実現する。

3.4.2 ウインド ウサイズ決定アルゴリズム
最適なウインド ウサイズを決定するためには、ネットワークからのフィードバックを利用する必要がある。しかし 、現在のインターネットのアーキテクチャでは、様々な通信媒体の接続を可能にするため、ネットワークの状態をフィードバックする機構が最小限に抑えられている。また中継ノードがフローを制御する、始点抑制制御メッセージも定義されているがすべてのノードに実装されているわけではない。
本研究では、データを中継するルータに特別な機能を組み込まずに得られる情報を用いて、ネットワークの状態を推測するアルゴ リズムを設計した。
インターネットのアーキテクチャでネットワークから得られる情報には以下のものがあげられる。

 ラウンドトリップタイム
ネットワークの帯域の利用率が上がると、中継ノードは、転送しきれないパケットを一旦待ち行列に加えて、処理に余裕ができるまで待機させる。このため、ネットワー
クの利用率が増加すると、ラウンドトリップタイムが増加していく。

 スループット
パケットが通過する経路上のネットワークは、少なくともコネクションが現在実現しているスループットを許容できる。
以上のパラメータに着目し 、REAL シミュレータを用いて図 3.1のネットワーク構成で、60M バイトのファイル転送を行なった。図 3.8にラウンドトリップタイムの変化を、図 3.9に帯域の利用率の変化を、図 3.10にルータのバッファの大きさの変化を示す。
図 3.8からラウンドトリップタイムが定期的に変化していることがわかる。図 3.9と図 3.10と比較と、帯域の利用率が 100%に近づいた時点からルータのバッファに転送待ちのパケッ
トが溜り始め、ラウンドトリップタイムの遅延が大きくなり、輻輳の発生後にウインド ウを閉じた時点で遅延が小さくなることが分かる。
図 3.11にスループットの変化を示す。図 3.9と比較することにより、帯域の使用率が 100%になった時点でスループットがあがらなくなることが観測される。
これらのパラメータに着目した結果、ラウンドトリップタイムの遅延が大きくなり始めた時点、及びスループットがあがらなくなる時点のウインド ウサイズが最適なウインド ウ
サイズになることがわかった。
以上のことから、ラウンドトリップタイムとスループットの比が最大になる点のウイン
ド ウサイズを最適なウインド ウサイズと判断するアルゴリズムを設計した。図 3.12にラウンドトリップタイムとスループットの比の変化を示す。

1995 年度 WIDE 報告書

474
0.9

0.8

0.7

RTT (sec)

0.6

0.5

0.4

0.3

0.2

0.1

0
0

50

100

150
time (sec)

200

250

300

図 3.8: ラウンドトリップタイムの変化

Window (Kbyte)

100

50

0
0

50

100

150
time (sec)

200

250

300

図 3.9: 帯域占有率の変化

3.4.3 ウインド ウ更新アルゴリズム
ネットワークの状態は頻繁に変化する。ある時点の最適なウインド ウサイズは、時間が経てば大きくなり過ぎたりたり、小さくなり過ぎる場合がある。現在のウインド ウサイズ
が最適なウインド ウサイズよりも大きい場合は、ラウンドトリップタイムやスループットの変化から判断することができるが、小さい場合は、これらの値があまり変化しない可能性があり、判別が難しい。
このため、一定の間隔で常にラウンドトリップタイムとスループットの比を観測し 、ラウンドトリップタイムとスループットの比が増加している間は、ウインド ウサイズを増加させ、ラウンドトリップタイムとスループットの比が減少した場合、ウインド ウサイズを減少させる。
このアルゴ リズムにより、ウインド ウサイズは、最適なウインド ウサイズの間を中心に

第 16 部

衛星通信によるネットワーク構築実験

475

50

Window (Kbyte)

40

30

20

10

0
0

50

100

150
time (sec)

200

250

300

図 3.10: ルータの待ち行列の変化

300

Throuput (Kbps)

200

100

0
0

50

100

150
time (sec)

200

250

300

図 3.11: スループットの変化振動する。ウインド ウサイズの増加、減少の割合を適切に設定することで、輻輳を起こさずに有効な帯域の利用ができる。

3.4.4 公平性
ネットワーク資源を公平に利用するためには 、複数のユーザがネットワークを共有し 、
データ転送を行なう場合に、全てのユーザが同じ量の帯域を共有できなければならない。
このような機能を実現するためには、

 ウインド ウサイズが小さい場合、ウインド ウサイズの増加の割合を大きくする。
 ウインド ウサイズが大きい場合、ウインド ウサイズの減少の割合を大きくする。

1995 年度 WIDE 報告書

476
600

500

throupt / RTT

400

300

200

100

0
0

50

100

150
time (sec)

200

250

300

図 3.12: ラウンドトリップタイムとスループットの比の変化というアルゴ リズムが必要である。実装の負荷を考慮し 、以下のような比較的単純なア
ルゴ リズムでこの機能を実現した。

 ウインド ウサイズを増加する場合

ウインドウサイズ = ウインド ウサイズ +α

 ウインド ウサイズを減少する場合ウインドウサイズ = ウインド ウサイズ

2β (β < 1)

3.5 REAL への実装
CPU やネットワークインターフェースの処理能力の制限を除き、アルゴ リズムのみの評
価を行なうために REAL[150] シミュレータ内に実装を行なった。
REAL シミュレータのフロー制御アルゴリズムは、アルゴリズム毎に一つのファイルにまとめられている。例えば 、TCP Tahoe は jk tahoe.c 、TCP Reno は、jk reno.c というファ
イルに C 言語の形で実装されている。今回の実装は、TCP Reno を原型とし 、jk reno.c を元にウインド ウ更新アルゴ リズムに変更を加えたファイルを作成した。
図 3.13に実装したウインド ウ更新アルゴ リズムのフローチャートを示す。
ウインドウサイズを下げた直後の X の値は、スループットが減少するため値が 1 つ前のX の値 Last X よりも小さくなる可能性が高い。この場合、輻輳状態にないにもかかわらずウインド ウサイズを連続的に減少させてしまう。この状態を避けるために、ウインド ウ
サイズを下げた直後は、Down Flag 変数を 1 にセットし 、必ず一度ウインド ウサイズを増加させている。また、今回の実装では、設計の節で示したウインド ウサイズを増加する際に加算する量αを回線の最大セグ メント長に、振動の幅を小さくするため、ウインド ウサ
イズを減少させる際に乗じるβを 0.875 に設定した。浮動小数点演算を用いずに計算を行

第 16 部

衛星通信によるネットワーク構築実験

477

START

ウインドウ更新のタイミング?

No

Yes
パケットの送達時間と現在の時間の差からラウンドトリップタイムを算出

スループット = 現在のウインドウサイズ/
ラウンドトリップタイム
X=
スループット/
ラウンドトリップタイム

X > Last_X または、
Down_Flag = 1 ?

No

Yes

ウインドウサイズ = ウインドウサイズ+ 最大セグメント長
Down_Flag = 0

ウインドウサイズ = ウインドウサイズ
× 0.875
Down_Flag = 1

Last_X = X

END

図 3.13: フローチャート
なうため、0.875 の乗算は、3 ビット右シフトした値を元の値から減じることによって実現
している。

3.6

評価

3.6.1 広帯域、高遅延ネット ワークにおける評価
本論文で設計したアルゴ リズムの広帯域、高遅延ネットワークにおける挙動を評価する
ために、REAL シミュレータを用い、図 3.1の構成を用いて 60Mbyte のデータ転送を行なった。図 3.1において、Ethernet の帯域は、10Mbps 、伝搬遅延は 50nsec に設定した。ルータ
3 、4 の間は衛星回線に接続されている。衛星回線の帯域は、2Mbps、伝搬遅延 500msec に設定した。ルータのバッファサイズは 40960byte とした。

1995 年度 WIDE 報告書478

図 3.14にデータ転送時のウインドウサイズの変化を示す。図 3.2 に示した従来の TCP のウインド ウサイズの変化と比較してウインド ウサイズが、最適なウインド ウサイズの近辺
で小さく振動していることがわかる。
図 3.15に帯域の利用率を示す。図 3.3 に示した従来の TCP の転送時の帯域の利用率と比較し 、効率のよい帯域利用ができていることが観測できる。

Window (Kbyte)

200

100

0
0

50

100

150
time (sec)

200

250

300

図 3.14: 新しいアルゴ リズムのウインドウサイズの変化

Utilization (%)

100

0
0

50

100

150
time (sec)

200

250

300

図 3.15: 新しいアルゴ リズムの帯域利用率の変化

このシミュレーションでは、従来の TCP の平均帯域利用率が 76%であり、新しいアルゴ リズムの平均帯域利用率が 85%であった。

3.6.2 公平性の評価
ネットワーク資源の公平な利用の評価するために、4 つのコネクションを同時に開始し 、ファイル転送を行なうシミュレーションを図 3.1の設定を用いて行なった。

第 16 部

衛星通信によるネットワーク構築実験

479

図 3.16は、4 つのコネクションが 50 秒毎に起動した場合のウインド ウサイズの変化を示している。図より各コネクションのウインドウサイズの差が徐々に縮まり、最終的に同じ量に収束していることがわかる。図 3.17に帯域の利用率を示す。各コネクションが最適なウインド ウサイズへと遷移している状態でも 100%に近い帯域の利用ができていることがわかる。

Window (Kbyte)

200

100

0
0

50

100

150

200
time (sec)

250

300

350

400

図 3.16: 50 秒毎にコネクションを開始した場合のウインド ウサイズの変化

Utilization (%)

100

0
0

50

100

150

200
time (sec)

250

300

350

400

図 3.17: 50 秒毎にコネクションを開始した場合の帯域利用率の変化

3.7

まとめ

本章では、RFC1323 の問題点を考察し 、その解決案を提案した。本章のアイデアは単純な構成の広帯域、高遅延ネットワークにおいて有効に機能すると思われるが、広域なネット
ワークでの振るまいに関してはより詳細な解析が必要である。今後はさらに複雑なトポロ
ジでのシミュレーションや、実際のインターネット上での使用により解析を行ない、TCP480

1995 年度 WIDE 報告書

Vegas などの新しいアルゴ リズムなどとの比較検討を行っていく予定である。

第 4章
衛星通信ネット ワークによるマルチキャスト 配送
実験

4.1

はじめに

衛星通信は多くの特徴をもった通信媒体ではあるが、ここでは同報性と広域性に着目する。衛星通信媒体がそのフットプリント、すなわち、通信可能範囲全体にまたがる Ethernetのような同報媒体として使用できる機能を活かし 、適当な経路制御とトポロジモデルを前提として地上のインターネットとの役割分担を適正に行なえば 、広域にマルチキャストを効率よく転送できる可能性がある。衛星通信を用いたマルチキャスト部分と地上線を用いたユニキャスト部分の分散を全国レベルで実現し 、そのモデルを検証した。

4.2

概要

11 月 30 日の「坂本龍一 Tour * 95 D&L with 原田大三郎」の武道館でのコンサートを実験の場として提供頂くことができた [151]。
コンサート会場の日本武道館に衛星通信局を設置し 、慶應義塾大学湘南藤沢キャンパス(SFC)、九州大学、奈良先端科学技術大学院大学、(株) 日本サテライトシステムズ技術開発センターの 4 地点へ向けて衛星通信ネットワークを通じて中継を試みた。
ツールとしては、nv 、vat という従来の MBone アプリケーションに加え、Stream Worksを用いた。Stream Works は、Xing Technology 社による、動画像・音声をネットワーク上に配信するシステムである。ストリームジェネレータと呼ばれるハード ウェアを使って画像・音声をエンコードし 、ネットワークサーバ、プロパゲーションサーバと呼ばれる中継
サーバにデータが送られる。ユーザには中継サーバからデータが配送される。ユーザと中継サーバとの間の通信にはユニキャスト (1 対 1 通信) で通信が行なわれるが、ストリーム
ジェネレータと中継サーバ間、中継サーバど うしで通信を行なう際はユニキャストだけではなく、マルチキャスト (1 対多通信) も利用できる。そこでストリームジェネレータを日本武道館に設置し 、上記 4 地点に中継サーバを設置した。

481

1995 年度 WIDE 報告書

482

4.3

マルチキャスト の経路制御とトポロジ

日本武道館と SFC の地球局との間では片方向 2Mbps のリンクを双方向で設け、それ以外の 3 地点では日本武道館からの受信のみを設定した (図 4.1) 。これは、通信機器の制約から (1.2節) 日本武道館で複数の受信を行なうことはできないからである。インターネットから日本武道館への通信は全て SFC を経由して行なわれる。
このような衛星通信ネットワークを形成することによって、日本武道館から送信される
マルチキャストパケットは全ての地点で受信することができるが、MBone への中継は SFC
経由だけにとどめ、それ以外の地点では MBone への接続は行なわない。よって、Stream
Works ストリームジェネレータと各中継サーバの間は地上の MBone 上で結ばれることはない。
このようにネットワークトポロジを形成した理由は、現行のマルチキャスト経路制御の仕組みではパケットを転送する際に複数の経路が存在する場合、ユニキャストにおける逆向き経路 (Reverse Path) を基に 判断をするからである。
すなわち SFC 以外の各地点が MBone によって日本武道館と接続されている場合、ユニキャストの逆向き経路は SFC を経由した経路となるため、衛星通信ネットワークからのパケットの転送をゲートウェイが行なわなくなるためである。

4.4

実験結果と考察

MBone での中継は 100 台程度のホストが視聴し 、延べ 1 万回以上の Stream Works 中継
サーバへの接続が確認された。
また、衛星を使用したマルチキャストバックボーン、そのマルチキャストバックボーン
から StreamWorks を経由してユニキャストでクライアントにデータを送り込むことは無事に成功した。この成功により、衛星通信ネットワークを用いたマルチキャスト通信の有効性が明らかになった。しかし 、現行のマルチキャスト経路制御の方式の制約に合わせたネットワークトポロジの形成を図らなければなからなかった。WISH の課題の一つとして、衛星通信ネットワークの特徴を活かすためにも単方向の衛星通信ネットワークでも機能するマルチキャスト経路制御方式の検討が不可欠である。

第 16 部

483

衛星通信によるネットワーク構築実験

Stream Works
NV, VAT送出ホスト ストリームジェネレータ

日本武道館

SFC

衛星通信ネットワーク
ゲートウェイ

衛星通信ネットワーク

衛星通信ネットワーク
ゲートウェイ（マルチキャストルータ）

SFC以外

衛星通信ネットワーク
ゲートウェイ（マルチキャストルータ）

Stream Works
中継サーバ

Stream Works
中継サーバ

MBone

図 4.1: マルチキャスト配送実験ネットワークトポロジ

4841995 年度 WIDE 報告書