特別研究報告 - 九州工業大学infonet.cse.kyutech.ac.jp/paper/2002/TaekoTAMADA-200302...ポートプロトコルであり，電話のシグナリング制御のためにIETF

特別研究報告

題目

SCTPにおける通信媒体選択手法の検証および評価

指導教官

尾家祐二教授

報告者

玉田妙子

平成 15年 3月 10日

九州工業大学情報工学部電子情報工学科

平成 14年度特別研究報告

SCTPにおける通信媒体選択手法の検証および評価

玉田妙子

内容梗概

近年，冗長性の確保やトラヒックの負荷分散のためにマルチホーム環境が整いつつある．しかし現在のインター

ネットにおける通信の大部分を占める TCPでは，このマルチホームの利点を生かした通信をおこなうことはでき

ない．これは，TCPが通信経路の切替に伴う IPアドレスの変更時に，通信を継続できないことに起因する．そこ

でマルチホーム通信が可能な新しいトランスポートプロトコルである SCTP (Stream Control Transmission

Protocol)が注目されている．

SCTPにおける通信は一組の送信元・宛先アドレスでおこない，現在使用している以外に保持している送信元・

宛先アドレスは再送時のみ利用する．このため現行の SCTPは負荷分散に関して全く考慮していない．また SCTP

では，通信開始時に双方の端末で通信可能なアドレスリストを交換することによりアソシエーションを確立する

が，一度確立したあとはこのアドレスリストに動的にアドレスを追加できない．これは，端末の移動に応じて動

的にアドレスを変更する必要がある移動体通信を考慮すると，極めて大きな問題となる．そこで，この問題を解

決し，動的にアドレスを追加できる add ipという機構が提案されている．しかし，add ipは実装依存である部

分が多いため，実際に実験をおこない，その動作を評価する必要がある．

本研究では現行の SCTPの動作を SCTPの実装である KAMEを用いて実験をおこない，詳細に評価する．そ

して，動的にアドレスを追加して通信をおこなうことができるように拡張した add ipを用いた実験により，移動

体通信環境においても SCTPが利用できる可能性を示す．最後に移動体通信環境において SCTPを用いて効率的

に通信をおこなうためには，パス切替機構の改善が重要となることを示す．

主な用語

SCTP，RTO，ハートビート，パス切替，add ip

目次

1 はじめに 1

2 SCTP(Stream Control Transmission Protocol) 3

2.1 SCTPの概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 SCTPの通信機構 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.2 SCTPの機能 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 SCTPのパケット構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 SCTPのデータ転送 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 アソシエーションの確立と解放 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.2 データ転送 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.3 再送制御 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.4 ハートビート . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.5 パス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4 add ip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5 SCTPの問題点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 実験 22

3.1 シナリオ 1. 現行の SCTP通信通信の動作検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.2 シナリオ 2. add ipを用いた SCTP通信の動作検証 . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 シナリオ 3. パケットロス率とパス切替の関係についての調査 . . . . . . . . . . . . . . . . . . . . 25

4 実験の結果と評価 26

4.1 シナリオ 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2 シナリオ 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.3 シナリオ 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 まとめと今後の予定 33

謝辞 34

i

参考文献 35

ii

1 はじめに

近年，インターネットは世界規模の通信基盤として広く普及している．このインターネット上の通信において確

実にデータを送り届けるためには，経路の冗長性の確保が必要である．また，固定あるいは移動端末などを利用し

てインターネットに接続する端末数は年々増加し，通信トラヒック量もこれに応じて増大しているため，トラヒッ

クの負荷分散をおこなうことが重要となっている．これら双方の目的のため，複数の通信経路を持つことができる

マルチホーム (multihoming)環境が整いつつある．一方，移動端末環境に着目すると，携帯電話，PDA，ノートパ

ソコン等によるモバイルアクセスの要求が年々高まっている．この要求の高まりに伴い，IEEE 802.11b Wireless

Local Area Networkに代表される無線 LANや IMT-2000(International Mobile Telecommunications-2000)など

の多様な無線接続技術が普及している．移動端末においてこれらの多様な無線接続技術を生かしマルチホーム環境

を達成できれば，切断がなく効率の良い通信を実現できる．しかし現在のインターネットにおける通信の大部分を

占める TCP(Transmission Control Protocol)は，マルチホーム環境を前提とする通信はできない．これは TCP

が通信継続中に一つのアドレスのみしか使用できないためである．このため，通信経路の変更によって IPアドレ

スが変更されると通信が継続できない．そこで，現在マルチホーム通信が可能な新しいトランスポートプロトコ

ルである SCTP(Stream Control Transmission Protocol)に注目が集まっている．

SCTPは，2000年 10月に RFC2960として IETF(Internet Engineering Task Force)で標準化されたトランス

ポートプロトコルであり，電話のシグナリング制御のために IETF SIGTRANワーキンググループにより開発さ

れたものが基礎となっている．SCTPは TCP の機能の大部分を受け継ぎ，マルチホーム対応であることから次世

代汎用トランスポートプロトコルとして期待されている．

しかし標準化されてから間もないため，既存の機構のままインターネット上で通信をするのには不備な点も多

い．現行の SCTPでは，同時にマルチホーム通信をおこなっているわけではなく，実際の通信は一組の送信元・

宛先アドレスによって行う．この送信元・宛先アドレスをプライマリアドレス (primary address)とよぶ．プラ

イマリアドレス以外に持っている送信元・宛先アドレスをセカンダリアドレス (secondary address)とよぶ．そし

て，通常はプライマリアドレス同士で通信をおこない，セカンダリアドレスは再送のときのみ使用する．よって

現在の SCTPでは，複数の通信経路を使用した負荷分散を達成することはできない．また，SCTPでは，TCPに

おけるコネクションに相当するものとして，通信開始時に複数のアドレスによって構成されるアソシエーション

(association)を確立し，信頼性のある通信を実現する．しかし，一度アソシエーションを確立すると動的なアド

レスの追加はできない．これは，端末の移動に応じて動的にアドレスを変更する必要のある移動体通信において

1

は，極めて大きな問題となる．また SCTPでは，プライマリアドレスはアソシエーション確立時に決定された後

は変更できない．加えて，プライマリアドレスの選択手法は実装依存となっており，明確な決定方法が定義されて

いない．よって，他に高速に通信できるアドレスが存在するにもかかわらず通信速度が低速であるアドレスがプ

ライマリアドレスに選択された場合，非常に効率の悪い通信となってしまう．そこで 2002年 9月に，動的なアド

レス追加を可能とする add ipという機能が提案された．この add ipにはプライマリアドレスを動的に変更する

ために Set Primary Addressというパラメータが追加されている．これを用いると，あらたに取得した IPア

ドレスをプライマリアドレスとして使用することが可能となる．しかし SCTP自体と同様に，add ipについても

提案されて間もないため，実装依存となっている部分が多い．

また，無線区間の伝送誤りを考慮したフロー制御については，現在のところ規定されていない．

以上のように，現行の SCTPでは実装依存の部分や考慮していない条件が多いため，現在開発されている実装

を用いて実験をおこない，その動作を評価する必要がある．

本研究では SCTPを用いたマルチホーム環境における通信経路の切替に着目した．まず SCTPの実装である

KAMEを用いて SCTPが実際に動作する実験環境を構築し，通信切替特性に関して調査する．つぎに，add ipを

用いて動的にアドレスを追加できることを確認し，移動体通信にも適応可能であることを示す．その後，実際の

移動体通信を想定し，通信経路上でパケットロスが生じた場合におけるパス切替時間に着目し，効率の良い通信

を実現するためにはパスの切替機構の改善が重要となることを明らかにする．

本論文の構成を述べる．まず，2章で SCTPの基本特性，通信方法，問題点について述べる．3章では本研究で

おこなった実験モデルと各シナリオについて述べる．4 章では実験結果にもとづき考察をおこなう．5章でまとめ

と今後の予定を述べる．

2

2 SCTP(Stream Control Transmission Protocol)

本章では，本研究で着目する SCTPの各機能の詳細について説明する．

2.1 SCTPの概要

ここでは，SCTPの基本的な機能について簡単に説明する．

2.1.1 SCTPの通信機構

SCTPの通信機構を図 2.1に示す．SCTPでは，それぞれのホストをエンドポイント (endpoint)と呼ぶ．エン

ドポイントは一つまたは複数の IPアドレスを持ち，双方の端末が互いに通信に使用可能なアドレスリストを交換

することによりアソシエーションを確立する．SCTPのアソシエーションは，TCPのコネクションに相当するも

のである．

図 2.1: SCTP 通信機構

SCTPは TCPと同様にコネクション指向型のプロトコルである．TCPでは，送信元・宛先の IPアドレスと

ポート番号を交換することでコネクションを確立していた．これに対し SCTPでは，送信元・宛先の IPアドレ

スリストとポート番号を交換することでアソシエーションを確立する．アソシエーション確立の詳細については

2.3.1節で述べる．

3

2.1.2 SCTPの機能

SCTPは，トランスポートプロトコルとして現在主に使われている TCPからスロースタート，輻輳回避，ファ

ストリカバリを含む輻輳制御機能，パケットロスの回復，再送のために選択的確認応答 (SACK：selective acknowl-

edgement)を使用する再送機能などを受け継いでいる．したがって，TCPで動く全てのアプリケーションは，SCTP

でその機能を失うことなく動作できる．

SCTPは TCPから受け継いだ機能に加えて，新たに以下のような機能も提供する．

• メッセージ境界の保持 (message boundary presevation)

– チャンク (chunk)により，バイト単位ではなくメッセージ単位で通信できる．

∗ チャンクについては 2.2節で詳細を述べる．

– サイズの小さなメッセージは，複数まとめて一つのチャンクに格納できる．また，サイズの大きなメッ

セージは，複数のチャンクに渡って分割できる．

• 複数の転送モード (multiple delivery mode)

– 以下のような，さまざまな転送モードが存在する．

∗ TCPのような厳密な順序転送．

∗ ストリームに応じた部分的な順序転送．

∗ UDPのような順序を保証しない転送．

• データの分割 (user data fragment)

– MTU(Maximum Transmit Unit)のサイズにしたがってメッセージを分割する．

– この機能は，任意で使われる．

• ハートビートによる生存確認 (hertbeat keep-alive mechanism)

– ある一定期間データ送信に使用していない宛先アドレスに対して定期的にハートビートパケットを送

り，その使用していなアドレスが activeかどうかを確認する．ACKがあるしきい値の回数返ってこな

ければ，そのアドレスを inactiveと認識し，通信には使用しないようにする．

• DoS攻撃からの保護 (DoS protection)

4

– TCPで起こる SYNフラッディングアタック (SYN flooding attacks)の影響を受けないように，アソ

シエーションを確立する段階でクッキー (cookie)というセキュリティ技術を使う．クッキーの詳細につ

いては 2.3.1節で述べる．

5

2.2 SCTPのパケット構造

SCTPのパケット構造を図 2.2に示す．

図 2.2: SCTP パケットフォーマット

6

図 2.2に示すように，SCTPパケットは一つの SCTP共通ヘッダと複数のチャンクからなる．チャンクには制

御チャンクとデータチャンクがあるが，図ではデータチャンクの場合について示している．制御チャンクはアソ

シエーションの確立や解放のときなどに送信され，その際にはデータチャンクよりも必ず前に配置しなければな

らない．

SCTP共通ヘッダについて説明する．まず送信元・宛先ポート番号は，SCTPパケットの受信者を見分けるため

に使う．verification tagは，以前のアソシエーションからの古い SCTPパケットの到着を防ぐ．したがって，TCP

では以前のコネクションの内容を消去するために必要としていた timed-wait stateは，SCTPでは必要ない．最

後にチェックサムは，SCTPパケットが IPネットワーク上を通る際のデータの完全性を保証する．

次にチャンクについて説明する．チャンクは PMTU(Path Maximum Transmit Unit)が許す限り，一つの SCTP

パケットにまとめることができる．チャンクの先頭には，チャンクの種類や長さが記される．TSN(Transport

Sequence Number)は単純に，転送の順番を表す番号である．ストリーム ID(Stream Identifier)は，ストリームご

とに付けられる番号である．よって，図 2.3に示すようにアソシエーションは複数のストリームを束ねたものとな

る． SSN(Stream Sequence Number)は，ストリーム内の転送の順番を表す番号である．プロトコル ID(Protocol

Identifier)には，SCTPのプロトコル番号が格納され，ユーザデータ (User Data)には送信したいメッセージが格

納される．

図 2.3: アソシエーションとストリーム

7

2.3 SCTPのデータ転送

本節では，SCTPのデータ転送に必要となる機能の詳細について説明する．

2.3.1 アソシエーションの確立と解放

アソシエーションの確立は，図 2.4の 4ウェイハンドシェイク (4 way handshake)により行う．

図 2.4: アソシエーションの確立

SCTPの 4ウェイハンドシェイクと TCPの 3ウェイハンドシェイクの最大の違いは，クッキーを使っている点

である．クッキーの使用により，SYNフラッディングアタックを受けても影響を受けない．SYNフラッディング

アタックとは，頻繁に TCPが受ける攻撃であり，攻撃者から続々と送信される SYNに対して受信側が SYN-ACK

を返信し続けることで記憶する情報が膨大となり，システムリソースが不足し通信継続が困難になる状況をいう．

送信側は，送信されてきた情報をもとに相手を特定するためのクッキーを作成して通信相手に送信する．通信相

手を確実に特定できるまではリソースの確保をおこなわないため，SYNフラッディングアタックを防ぐことがで

きる．

図 2.4の INITチャンク，INIT-ACKチャンク，COOKIE-ECHOチャンク，COOKIE-ACKチャンク

8

は，制御チャンクとして扱われる．ここではエンドポイント Aがエンドポイント Bに対してアソシエーションを

確立する場合を示している．

アソシエーション確立の手順を説明する．まずエンドポイント Aは，アソシエーションを確立するために必要な

情報の初期値を含んだ INITチャンクを送信し，COOKIE WAIT状態に入る．エンドポイント Bは，INITチャン

クを受け取るとクッキーを含んだ INIT-ACKチャンクを送信する．クッキーを用いることにより，メモリに保存す

る予定であった情報を INIT-ACKチャンクの中に詰め込む．エンドポイント Aは，INIT-ACKチャンクを受け取る

と，その中からクッキーを取り出し COOKIE-ECHOチャンクとして送信し，COOKIE ECHOED状態に入る．

エンドポイント Bは，COOKIE-ECHOチャンクを受け取るとそこからクッキーを取り出し，COOKIE-ACK

チャンクを送信する．以上の動作を経てアソシエーションが確立される．

図 2.5は各状態について示したものである．

図 2.5: アソシエーションの確立時の状態

なお，INITチャンク，INIT-ACKチャンクの転送に使われているアドレスは，アソシエーション確立のための

アドレスリストに含まれていなくても，アソシエーションの一部となる．

9

SCTPのアソシエーションの解放には，図 2.6に示すような 3ウェイハンドシェイクを用いる．TCPでは，デー

タを受信している最中でもコネクションを解放できた．しかし SCTPでは TCPとは違い，丁寧な方法でアソシ

エーションの解放を行う．

図 2.6: アソシエーションの解放

図 2.6の SHUTDOWNチャンク，SHUTDOWN-ACKチャンク，SHUTDOWN-COMPLETEチャン

クは，制御チャンクとして扱われる．ここではエンドポイント Aがエンドポイント Bに対してアソシエーション

を解放する場合を示している．

アソシエーションの解放の手順を説明する．エンドポイント Aは，アソシエーションの解放を決定したあとは，

上位層からのデータを受け付けない．そして，SHUTDOWN PENDING状態に入り，現在キューにたまっている

データチャンクを送信する．エンドポイント Aは，キューにたまっている全てのデータチャンクを送信したあと，

SHUTDOWNチャンクを送り，SHUTDOWN SENT状態に入る．エンドポイント Bは，SHUTDOWNチャン

クを受け取ったあとは上位層からのデータを受け付けない．そして，SHUTDOWN RECEIVED状態に入り，現

在キューにたまっているデータチャンクを送信する．エンドポイント Aは，エンドポイント Bからデータチャン

クが届くたびに SHUTDOWNチャンクを送信する．エンドポイント Bは，キューにたまっている全てのデータ

チャンクを送信したあと，SHUTDOWN-ACKチャンクを送り，SHUTDOWN-ACK SENT状態に入る．エン

ドポイント Aは，SHUTDOWN-ACK チャンクを受け取ると SHUTDOWN-COMPLETEチャンクを送信す

10

る．これでアソシエーションの解放が完全なものとなる．

図 2.7は各状態について示したものである．

図 2.7: アソシエーションの解放時の状態

11

2.3.2 データ転送

図 2.8に SCTPのデータ転送のようすを示す．

図 2.8: SCTPのデータ転送

図 2.8に示すように，SCTPパケットが到着するごとに SACK チャンクを返す．SACKチャンクには，受信

側 (ここではエンドポイント B)がどのデータチャンクを受け取ったかの情報が格納される．具体的には，SACK

チャンク中にある Gap Ack blockというパラメータに受信した TSNを格納している．データチャンクの送信者

は，これをもとに，どのデータチャンクを再送すべきかを特定できる．

SCTPは TCPと同様に，ファスト・リトランスミットとタイムアウトという二つの手法による再送アルゴリズ

ムを提供する．プライマリアドレス同士で通信している際にパケット廃棄を SACKチャンクにより検出すると，

セカンダリアドレスに向けて再送をおこない，エラーカウンタを 1ずつ増加させる．セカンダリアドレスが通信

可能であるかの確認は，ハートビート (heartbeat)によりおこなう．再送後は再びプライマリアドレス同士で通信

を継続する．再送制御についての詳細は 2.3.3節で，ハートビートの詳細については 2.3.4節で説明する．

12

2.3.3 再送制御

本節ではデータの再送制御について説明する．

送信した SCTPパケットに対する SACKチャンクを受信せずにタイムアウトが経過した場合には，同じ内容の

SCTPパケットをセカンダリアドレスに対して再送する．その後，セカンダリアドレスに再送した SCTPパケッ

トに対する SACKチャンクを受信すると，それからの通信はプライマリアドレスによって再開される．このとき，

再送タイマの値を前回の 2倍に設定する．この再送タイマの値をRTO (Retransmission TimeOut)という．また，

タイムアウトをむかえるごとに RTOを 2倍に設定するアルゴリズムを指数バックオフという．

図 2.9に指数バックオフによる RTOの値の増加のようすを示す．

図 2.9: 指数バックオフによる RTO，RTTの増加

13

このように，再送タイマの RTOは，再送をおこなうたびに 2倍に設定され，指数的に増加する．

再送を行った回数はアドレスごとにエラーカウンタで保持される．エラーカウンタは再送時やハートビートの

送信時に加算される．送信したデータに対する SACKチャンクもしくはハートビート応答チャンクを受け取ると，

エラーカウンタはリセットされる．同時に RTOも初期値である 1秒となる．

SCTPでは再送はあるしきい値に達するまで連続しておこなわれる．このしきい値 (Path Max Retransmission：

以下，PMRと略す)を超えると，その宛先のプライマリアドレスを inactiveとし，通信に使用しない．そして，

宛先のセカンダリアドレスでの通信に切り替える．ただし，全ての宛先アドレスが inactiveとなった場合や，セ

カンダリアドレスを持たない場合は，アソシエーションそのものが喪失する．現行の SCTPでは，PMRの値は 5

が推奨されている．

表 2.1は再送時のエラーカウンタと RTOの値ならびに障害が発生してからの累積時間を示している．前述した

とおり，エラーカウンタは一つずつ増えていき，RTOは指数的に増加する．それに伴い，累積時間は表 2.1のよ

うに増加する．したがって表 2.1より，宛先アドレスの切替には障害が発生してから 63秒要することがわかる．

表 2.1: 再送時のエラーカウンタ，RTO，累積時間

エラーカウンタ RTO(秒) 累積時間 (秒)

通常の転送 0 1 0

1回目の再送 1 2 1



4回目の再送 4 16 15

5回目の再送 5 32 31

宛先アドレスの切替 6 32 63

14

2.3.4 ハートビート

本節では，SCTPの障害検知や再送制御に使用される制御チャンクであるハートビートについて詳細に説明する．

SCTPでは，送信側のエンドポイントから宛先のエンドポイントのアドレスが使用可能であるかを，そのアド

レスから制御チャンク，データチャンク，ハートビートチャンクの ACKが返信されているかどうかに基づいて判

断する．これらの ACKがある一定期間に返信されていない場合は，ハートビートチャンクを送信することで通信

可能であるかを確認する．このハートビートを送出する期間をハートビート周期 (heartbeat period)という．ハー

トビート周期は通常，以下の式で与えられる．

Hi = RTOi + HB.Interval(1 + δ) (2.1)

式2.1において iは宛先アドレスをあらわす．RTOiはその宛先アドレスにおける最新のRTO値が入る．HB.Interval

は 30秒が推奨されているが，ハートビート送信のタイミングは δを用いて制御されている．これにより，ハート

ビートを送信する際のトラヒックの増加を防いでいる．δ は −0.5～+0.5の間のランダムな値であるので，式 2.1

の右辺第 2項は HB.Intervalの値を± 50％した秒数となる．したがって右辺第 2項は 15～45秒の間の値をとり

うる．

ハートビートチャンクを受け取ったエンドポイントは，ハートビートチャンクの送信元アドレスへとハートビー

ト応答チャンク (heartbeat acknowledgement chunk)を送信する．

ハートビートは idle状態のパスにのみに送信することで，トラヒックの増大や必要以上の処理の増加を防いでい

る．ここでいう idle状態とは，RTTの計測を行えるチャンク (例：再送でない DATA，INIT，COOKIE ECHO,

HEARTBEAT)がハートビート周期内に一つも送られていない状態であり，active，inactiveどちらの場合にも適

用される．宛先アドレスが idle状態かつ activeであるときのハートビート周期は式 2.1であらわされる．宛先ア

ドレスが idle状態かつ inactiveであるときのハートビート周期は式 2.2で与えられる．

Hi = RTOInitial + HB.Interval(1 + δ) (2.2)

式 2.2の RTOInitialは RTOの初期値であり，通常 3秒に設定されている．

ハートビートの送出を決定するハートビートタイマはエンドポイントごとに保持されており，このタイマをタ

イムアウトするごとにハートビートを一つ送信する．ハートビートを実際にどの idle状態の宛先アドレスに送信

するかは実装依存となっている．

15

2.3.5 パス

本節では実際のデータ転送について簡単に説明したあと，本研究で提案するパスという概念について述べる．

実際のデータ転送のようすを図 2.10を使って説明する．

図 2.10: データ転送

アドレス 1.2，3.2をプライマリアドレス，アドレス 2.2，4.2をセカンダリアドレスとして認識したものとする．

また，IP層によってデフォルト・インターフェイスが，IF 1，3と決められたものとする．デフォルト・インター

フェイスとは，そのエンドポイントにおいてデータを送出するインターフェイスのことである．

通常のデータ転送はプライマリアドレス同士でおこなうため，図 2.11に示すようにアドレス 1.2－ 1.1－ 3.1－

3.2の経路でおこなう．

図 2.11: 通常のデータ転送

16

ここで図 2.12に示すようにアドレス 3.1に障害が起こった場合は，エンドポイント Aからエンドポイント Bへ

の再送はアドレス 1.2－ 1.1－ 4.1－ 4.2の経路でおこなう．

図 2.12: 障害発生時のデータ転送

この再送パケットを受け取ったエンドポイント Bはエンドポイント Aへ SACKチャンクを送信するが，このと

きエンドポイント Bはデフォルト・インターフェイスであるアドレス 3.2から SACKチャンクを送出する．しか

しアドレス 3.2の先にある IP アドレス 3.1のルータ 3で障害が発生しているため，SACKチャンクをエンドポイ

ント Aに送ることはできない．このため，アドレス 3.1での障害がアソシエーション全体を不安定にし，最終的

にはアソシエーションが喪失してしまう．一つの部分の障害がアソシエーション全体に波及することから，このよ

うな問題を単一点障害と呼ぶ．

単一点障害を防ぐためには，宛先アドレスごとに経路を明示的に指定してやる必要がある．図 2.10でいうと，

アドレス 1.2－ 1.1－ 3.1－ 3.2の経路，アドレス 2.2－ 2.1－ 4.1－ 4.2の経路である．このように経路を指定す

ることにより，アドレス 3.1に障害が起こった場合，エンドポイント Aからエンドポイント Bへの再送はアドレ

ス 2.2－ 2.1－ 4.1－ 4.2の経路でおこなわれ，エンドポイント Bからエンドポイント Aへ SACKチャンクはア

ドレス 4.2から，2.2－ 2.1－ 4.1－ 4.2の経路で送られる．このため，上記のように経路を設定することで単一点

障害を解決することができ，複数の IPアドレスを使用して通信をおこなう SCTPの特徴を生かすことができる．

本研究ではこれらの経路をパス (path)と呼ぶことにする．具体的には，アドレス 1.2－ 1.1－ 3.1－ 3.2の経路

をプライマリパス (primary path)，アドレス 2.2－ 2.1－ 4.1－ 4.2の経路をセカンダリパス (secondary path)と

呼ぶ．

17

図 2.13: パス設定

18

2.4 add ip

現行の SCTPでは，最初にアソシエーションを確立してからは動的なアドレスの追加を許可していない．そこ

で，動的にアドレスを追加するための機能として addipという機構が提案されている．

addipは，Internet Draft[2]として IETFにより提案された．以下に，addipで新しく提案された二つのチャン

クと六つのパラメータを示す．

• チャンク

– ASCONFチャンク (Address Configuration Cange Chunk)

– ASCONF-ACKチャンク (Address Configuration Acknowledgement Chunk)

• パラメータ

– Add IP Addressパラメータ

– Delete IP Addressパラメータ

– Set Primary Addressパラメータ

– Adaption Layer Indicationパラメータ

– Error Cause Indicationパラメータ

– Success Indicationパラメータ

ASCONFチャンク，ASCONF-ACKチャンクは，上記のパラメータを含むことができる．各パラメータのうち，

動的にアドレスを追加するパラメータは，Add IP Addressパラメータである．また，動的にアドレスを追加した

あとで，その追加したアドレスをプライマリアドレスとして設定するパラメータは，Set Primary Addressパラ

メータである．

19

ASCONFチャンクの構造を図 2.14に示す．

図 2.14: ASCONFチャンク

先頭には，チャンクの種類や長さが記される．続くシリアル番号 (Serial Number)には，このチャンクの順番が

書かれ，アドレスパラメータには，現在使っているアドレスが記される．最後に ASCONFパラメータには，六つ

のパラメータのうち，設定したいパラメータを一つずつ格納する．

このため，移動端末が新たに IPアドレスを取得し，そのアドレスをプライマリアドレスとして指定し通常の通

信をおこなうためには，ASCONFチャンクによって，Add IP Addressパラメータと Set Primary Addressパラ

メータを通知する必要がある．この際，パラメータの順序としては，まず Add IP Addressパラメータを先に設定

し，そのアドレスをアソシエーションに追加する．その後に Set Primary Addressパラメータを設定し，そのア

ドレスをプライマリアドレスに変更する必要がある．

20

2.5 SCTPの問題点

以下に，現行の SCTPにおける問題点をあげる．

(1) 負荷分散に関して全く考慮していない

現行の SCTPにおける通信は，通常はプライマリパスによりおこない，セカンダリパスは再送のときのみ利

用する．このため，負荷分散に関して全く考慮していないといえる．

(2) 動的にアドレスを追加できない

SCTPでは，通信開始時に双方の端末で通信可能なアドレスリストを交換することによりアソシエーション

を確立するが，一度確立したあとはこのアドレスリストに動的にアドレスを追加できない．これは，端末の

移動に応じて動的にアドレスを変更する必要がある移動体通信を考慮すると，極めて大きな問題となる．

(3) プライマリアドレスの変更ができない

一度アソシエーション確立の際にプライマリアドレスを決定した後は，プライマリアドレスの変更はおこな

うことができない．加えて，アソシエーション確立時のプライマリアドレスの選択手法については実装依存

となっており，明確な決定方法が定義されていない．これでは，他に高速に通信可能であるアドレスが存在

するにもかかわらず，低速な通信をはかるアドレスがプライマリアドレスに選択された場合，非常に効率の

悪い通信となってしまう．

問題 (2)，(3)を解決する手段として，動的にアドレスを追加できる add ipの利用が考えられる．この add ipに

は，プライマリアドレスを動的に変更できる Set Primary Address パラメータが存在する．これを用いると，新

たに取得した IPアドレスをプライマリアドレスとして使用することが可能となる．

また，add ipと Set Primary Addressパラメータを用いて自在にパス選択が可能であれば，問題 (1)の解決に

もつながる．

しかし，add ipは実装依存である部分が多いため，実際に実験をおこない，その動作を評価する必要がある．

21

3 実験

本研究では現行の SCTPの動作を SCTPの実装である KAMEを用いて検証し，詳細に評価する．そして，ア

ソシエーション確立後ににアドレスを追加して通信をおこなうことができるように拡張した add ipを用いた実験

により，移動体通信環境においても SCTPが利用できる可能性を示す．その後，SCTPおよび add ipのパス切替

に注目し，その切替時間を短くする手法を提案し，その効果を実験によって評価する．

本研究では，図 3.1に示すトポロジーで実験を行った．

図 3.1: シナリオ 1，2，3のトポロジー

エンドポイント A，ルータ，エンドポイント Bとして PCを 3台用意した．エンドポイント A，Bには，ネット

ワークインターフェイスをそれぞれ二つずつ，ルータにはネットワークインターフェイスを四つ装着した．IF nは

ネットワークインターフェイスをあらわす．これらのネットワークインターフェイスを，レイヤー 2スイッチを用

いて，それぞれ 1－ 3，5－ 7，2－ 4，6－ 8にセグメントを分けた．セグメントを分けることにより，パス全体

ではなくパス内の部分的な経路だけを操作することができる．例えば，プライマリパス全体に障害を起こすのでは

なく，IF 5－ 7にだけ障害を発生させることができる．また各 PCの OS(Operating System)として，FreeBSD

4.6.2をインストールした．

FreeBSD自体は SCTPに対応していない．そこで SCTPに対応するための手段を模索した結果，IPv6プロト

コルスタックである KAMEに SCTPプロトコルスタックが含まれていることがわかった．よって 2002年 10月

21日版 FreeBSD4.6用の KAMEを導入，実験をおこなった．

本実験では，単一点障害を防ぐために表 3.1の経路表を用いて，図 3.1のようにプライマリパスとセカンダリパ

スを明示的に設定した．

以降に本研究でおこなった実験のシナリオを示す．

22

表 3.1: エンドポイント A，Bの経路表

endpoint A endpoint B

Destination Gateway Destination Gateway

7 3 1 5

8 4 2 6

3.1 シナリオ 1. 現行の SCTP通信通信の動作検証

この実験では，現行の SCTP通信がリンク障害時に正常に動作するかについて詳細に調査する．

図 3.2において，エンドポイント Aをサーバ，エンドポイント B をクライアントとし，IF 5－ 7間に障害が起

こることを想定する．また，スループットの計測は，IF 7，8でおこなう．

図 3.2: シナリオ 1のトポロジー

はじめにプライマリパスで通信をおこない，IF 5－ 7間に障害を発生させる．そして現行の SCTPで規定され

ているとおり，63秒でセカンダリパスへの通信切替がおこなわれるかを確認する．その後，IF 5－ 7間の障害を

取り除く．現行の SCTPでは，inactiveと認識されたプライマリアドレスが，ハートビートによって activeと認

識されしだい，すぐにセカンダリパスの通信からプライマリパスでの通信に切替える．この規定されている動作

にしたがってパスの切替がおこなわれるかを確認する．

23

3.2 シナリオ 2. add ipを用いた SCTP通信の動作検証

この実験では，add ipを用いた際の SCTP通信が正常に行われるかの確認を目的としている．

図 3.3において，エンドポイント Aをサーバ，エンドポイント B をクライアントとし，IF 5－ 7間に障害が

起こることを想定する．また，スループットの計測は，IF 7，8でおこなう．インターフェース 8は，アソシエー

ション確立後に add ipを用いて追加する．


はじめは IF 8を停止した状態で通信を開始する．プライマリパスで通信している途中で，add ipにより IF 8を

認識させる．その後，IF 5－ 7間に障害を発生させる．そして現行の SCTPの記述のとおり，63秒でセカンダリ

パスへの通信切替がおこなわれるかを確認する．この切替が確認された時点で，add ipによる動的なアドレスの

追加が成功したことを示す．その後，IF 5－ 7間の障害を取り除き，inactiveと認識されたプライマリアドレス

が，ハートビートによって activeと認識されしだい，すぐにセカンダリパスの通信からプライマリパスでの通信

に切替えられるかを確認する．

24

3.3 シナリオ 3. パケットロス率とパス切替の関係についての調査

この実験では，最も効率の良い切替手法を実現することを目的としている．

図 3.4において，エンドポイント Aをサーバ，エンドポイント B をクライアントとし，IF 5－ 7間に障害が

起こることを想定する．また，スループットの計測は，IF 7，8でおこなう．さらに，通常の通信時においてイン

ターフェース 5－ 7，6－ 8間のパケットロス率をさまざまな値に設定し，その影響を調査する．


Free BSDでは，帯域やパケットロス率を制御するために dummynetというツールが提供されている．本実験

では図 3.4のルータに dummynet機能を使用できるよう設定し，dummynetを用いてパケットロス率をさまざま

な値に設定した際に，パス切替とどのような関係が見られるかを調査する．パケットロス率が高くなってきたに

もかかわらずパス切替が行われていない場合は，スループットが著しく低下することが予想される．そこで効率

的なパス切替をするためにはパケットロス率がどの程度のときに切替えるべきかを模索する．

25

4 実験の結果と評価

本章では，各シナリオの実験の結果を示し，その評価をおこなう．

4.1 シナリオ 1.

シナリオ 1では現行の SCTPの動作を詳細に調査した．ここではパス切替時の通信について詳しく考察する．

シナリオ 1の実験結果を図 4.1に示す．図 4.1は，通信開始後 200秒間のスループット特性について示している．

図 4.1のように，通信開始時にはプライマリパスで通信し，通信開始後 10秒の時点でプライマリパスに障害を発

生させた．

図 4.1: シナリオ 1

ここでは，プライマリパスからセカンダリパスへの切替時間に着目する．現行の SCTPでは障害発生から 63秒

後にセカンダリパスで通信が再開される．しかし，図 4.1に示すように，本実験ではパス切替に 90秒ほど要した．

これは，再送時における RTOやハートビートによるものであることがわかった．以下にパス切替に 90秒かかる

26

理由を示す．

27

ハートビートの送信間隔について説明する．

今，00:00:00に通信を開始したとする．はじめにプライマリアドレスで通信をし，通信開始から 10秒で IF 5-7

に障害が起こったとする．送信側であるサーバは，30秒後の 00:00:30にデータを送受信していないセカンダリア

ドレスに向けてハートビートを送信する．その 30秒後の 00:01:00には，まだプライマリパスは通信に使用してい

るので，セカンダリアドレスに向けてハートビートを送信する．このとき，プライマリアドレスでの再送は 4回目

であり，RTO 値は 16である．SCTPでは，ハートビートを送信すると現在の RTOを 2倍する規則があるので，

RTOは 32となる．ホストのタイマが 16で切れた瞬間，RTOは 2倍され，64となるが，RTOの上限は 60と定め

られているので，RTOは 60となる．しかしサーバは RTO16のあとは RTO32だと認識しており，32秒後にセカ

ンダリパスでの通信がはじまると判断する．だが，実際にセカンダリパスに通信が切り替わるのは 00:00:41から

60秒後の 00:01:41である．サーバは，00:01:13からプライマリパスが idle状態だと認識しているので，00:01:00

から 30秒後の 00:01:30にはプライマリアドレスにハートビートを送信する．そして，今，RTOは 60であるの

で，ハートビートの式より，60+30=90秒後，つまり 00:03:00にプライマリアドレスにたいしてハートビートを

送信する．

start 00:00:00

failure 00:00:10 RTO1

count1 00:00:11 RTO2



count4 00:00:25 RTO16

count5 00:00:41 RTO32

secondary 00:01:13

28

図 4.2: tcpdump

29

4.2 シナリオ 2.

図 4.3: シナリオ 2

シナリオ 2では，通信開始前に IF 8を停止させ，アソシエーション確立時に IF 8のアドレスをアドレスリス

トに含めないようにした．そして add ipを用いて通信開始後 5秒で IF 8を認識させ，その後はシナリオ 1と同様

の検証をおこなった．

図 4.2に示すように add ipによりセカンダリパスが認識され，プライマリパスからセカンダリパスへの切替が

行われている．add ipを用いない場合は，最初のアドレス交換の段階で存在しないアドレスに対しては，アソシ

エーション確立後に認識しない．しかし，add ipを用いることでアドレスリストに新たなアドレスを追加するこ

とができ，さらに通信障害が発生したときにパス切替をおこなうことができることを確認した．スループット特

性は図 4.1とほぼ等しいものとなり，前節で説明したようにパス切替時間が必要以上に長くなってしまっている．

add ipを用いることで移動体通信端末は通信を継続できることがわかった．しかし，切替時間は許容できない

ほど長くなっているため，add ipが頻繁に利用されることが移動体通信環境ではパス切替時間を短くするなどの

改善をする必要がある．

30

4.3 シナリオ 3.

前節では，アドレスが次々と変化することが想定される移動体通信環境において add ipを用いることで通信

継続が可能であることを示した．そこで本節では，移動体通信環境のもうひとつの特徴である伝送誤りに注目し，

dummynetを利用してパケットロス率を変化させることでロス率と切替時間の関係を調査する．

実験は，各パケットロス率につき 10回おこなった．図 4.3は，各パケットロス率における通信開始時からセカ

ンダリパスに通信が切替えられるまでの時間を示している．

図 4.4: 各パケットロス率におけるパスが切り替えられるまでの時間

図 4.3からわかるように，パケットロス率が高くなるにしたがって，セカンダリパスに通信が切替えられるまで

の時間が短くなることがわかる．このようにロス率が高くなるにつれパケットが連続して廃棄されやすく，結果と

して切替時間が短くなっていくことがわかる．しかし，このようにロス率が高い場合，通信はほとんどおこなう

ことができないと考えられ，その間 91秒もパス切替を待つのは実用的ではない．よってロス率が高い場合は，素

早くパスを切り替える機構が必要である．

一方，パケットロス率が低い場合，パスが切り替わるまでの時間が長いことがわかる．この切り替わるまでの

31

間，パケットロスにより通信の効率は低下してします．また，切替時間が長いため，その間のスループットは大き

く劣化すると考えられる．よってロス率が低い場合でも，さらに良好なリンク特性をもつパスに素早く切り替え

ることができる機構が必要であるといえる．

パケットロス率が低い場合は，パスが切り替わるまでの時間が長くなる．この切り替わるまでの間は，エラー

を受けながら通信を継続すると考えられる．この場合，通信の効率は劣化するため，早期にパスを切替える必要

がある．一方，パケットロス率が高い場合は，パスが切り替わるまでの時間は 63秒と短いが，その間通信は高い

エラー率によりほとんどおこなえない．このような場合には一刻もはやくパスを切替える必要がある．以上より，

エラーが発生するような通信状況においては，素早くパスを切替える機構が必要になる．

32

5 まとめと今後の予定

本研究では，SCTPの実験環境を構築し，実装に依存している部分が多い SCTPでの通信について調査した．

まず，リンク障害発生時にパス切替により通信を継続することができることを確認した．しかし，パス切替に要

する時間は 91秒と，規定されている 63秒よりも長くかかってしまうことがわかった．

次に，新たに提案されている add ipを用いて動的にアドレスを追加することができるか調査した．そして，add

ipにより新たにアドレスを追加し，通信を継続することができることを確認した．しかし，この場合でもパス切

替に要する時間は 91秒と，規定されている 63秒よりも長くかかってしまうことがわかった．

最後に，無線区間で誤りが発生する場合のパス切替時間とロス率の関係について調査した．その結果，ロス率

が高いほど切替時間が短くなることがわかった．しかし，ロス率が高い場合は通信はほとんどおこなうことがで

きないため，すぐにパスを切り替える機構が必要であることを示した．また，ロス率が低い場合は，パス切替ま

での間のスループットはロス率の影響を受けて低下するので，よりリンク特性が良いパスに切り替える機構が必

要であることを示した．

今後は，PMRの値を動的に変化させて，再送決定をおこないたいと考えている．現行の連続で 5回エラーがあ

るときではなく，一定期間のエラーの合計回数があるしきい値を超えた場合に切替をした方が，より効率の良い

切替になると予想している．

33

謝辞

本研究を進めるにあたり，多くの方々からご指導，ご教授いただきました．これらの方々に心から感謝いたし

ます．

研究の方針を明確にご指導くださり，最後まで的確な助言をくださった尾家祐二教授に深く感謝いたします．

SCTPという新しくかつ興味深い分野の研究を進めることができたことを大変光栄に思っております．

研究の本質を冷静に見極め，熱心にご指導くださった池永全志助手に心から感謝いたします．お忙しい中，研

究手法に関して多くの助言をしていただきました．ありがとうございました．

また，SCTPに関してわかりやすく，かつ丁寧にご教授くださった奈良先端科学技術大学院大学情報科学研究

科の飯田勝吉助手に深く感謝いたします．ならびに，専門的な知識をご教授くださりました同大学 SCTP研究グ

ループの皆様にも厚くお礼を申し上げます．

本研究を忍耐強く熱心にご指導くださった福田氏，塚本氏に心より感謝いたします．ご迷惑をおかけしてばかり

なのにも関わらず適切な助言をくださり，本当にありがとうございました．先輩方のご協力に改めて感謝いたし

ます．

また，共に過ごし，さまざまな面でご協力くださりました尾家・川原研究室の皆様に感謝いたします．

最後に，いつも快く事務処理を引き受けてくださった竹村眞奈美事務補佐員に感謝いたします．

34

参考文献

[1] R. Stewart，Q. Xie “Stream Control Transmission Protocol (SCTP) Reference Guide” 2002 Addison-Wesley

[2] R. Stewart，Michel A. Ramalho “Stream Control Transmission Protocol (SCTP) Dynamic Address Recon-

figration” September，2002 Internet Draft http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp-

06.txt

35

Documents

特別研究報告 - 九州工業大学infonet.cse.kyutech.ac.jp/paper/2002/TaekoTAMADA-200302...ポートプロトコルであり，電話のシグナリング制御のためにIETF