特別研究報告 SCTPにおける通信媒体選択手法の検証および評価

特別研究報告
題目
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
3
2.4
add ip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5
SCTP の問題点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
22
実験
3.1 シナリオ 1. 現行の SCTP 通信通信の動作検証 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 シナリオ 2. add ip を用いた SCTP 通信の動作検証 . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 シナリオ 3. パケットロス率とパス切替の関係についての調査 . . . . . . . . . . . . . . . . . . . . 25
4
5
26
実験の結果と評価
4.1 シナリオ 1.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 シナリオ 2.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3 シナリオ 3.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
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
2 回目の再送
2
4
3
3 回目の再送
3
8
7
4 回目の再送
4
16
15
5 回目の再送
5
32
31
宛先アドレスの切替
6
32
63
14
2.3.4
ハートビート
本節では，SCTP の障害検知や再送制御に使用される制御チャンクであるハートビートについて詳細に説明する．
SCTP では，送信側のエンドポイントから宛先のエンドポイントのアドレスが使用可能であるかを，そのアド
レスから制御チャンク，データチャンク，ハートビートチャンクの ACK が返信されているかどうかに基づいて判
断する．これらの ACK がある一定期間に返信されていない場合は，ハートビートチャンクを送信することで通信
可能であるかを確認する．このハートビートを送出する期間をハートビート周期 (heartbeat period) という．ハー
トビート周期は通常，以下の式で与えられる．
Hi = RT Oi + HB.Interval(1 + δ)
(2.1)
式 2.1 において i は宛先アドレスをあらわす．RT Oi はその宛先アドレスにおける最新の 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 = RT OInitial + HB.Interval(1 + δ)
(2.2)
式 2.2 の RT OInitial は 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
3.1
endpoint B
Destination
Gateway
Destination
Gateway
7
3
1
5
8
4
2
6
シナリオ 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 を用いて追加する．
図 3.3: シナリオ 2 のトポロジー
はじめは 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 間のパケットロス率をさまざまな値に設定し，その影響を調査する．
図 3.4: シナリオ 3 のトポロジー
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
count2 00:00:13 RTO4
count3 00:00:17 RTO8
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 Reconfigration” September，2002 Internet Draft http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-addip-sctp06.txt
35

Download Report