2022.06.0 2 北川リサ
6 . 6 . 5 - 6 . 7
コ ン ピュ ー タ ネ ッ ト ワ ー ク 特 論

Header Compression
6 . 6 . 5

3
6 . 6 . 5 H e a d e r C o m p r e s s i o n
帯 域 幅 が 制 限 さ れ た 状 況 で の パ フ ォ ー マ ン ス
ソフトウェアのオーバーヘッドを削減する
✔︎
モバイルコンピュータをより効率的に動作させるのに役立つ
ネットワークリンクがボトルネックになっている場合
パフォーマンスを向上させることはできない

4
6 . 6 . 5 H e a d e r C o m p r e s s i o n
帯 域 幅 を 有 効 に 利 用 す る た め に
帯域幅を有効に利用するためには…
プロトコルのヘッダー と ペイロード を
最小限のビット数で伝送する
アプリケーションレベルのキャッシュ機構も必要
ペイロードの場合、
ビットマップではなくJPEG形式の画像や、圧縮を含むPDFなどの文書形式など、
情報のコンパクトなエンコーディングを使用する

5
6 . 6 . 5 H e a d e r C o m p r e s s i o n
プ ロ ト コ ル ヘ ッ ダー に つ い て
ワイヤレスネットワークのヘッダーは
少ない帯域幅を考慮して設計されているため、コンパクト
すべてのリンクレイヤで1つのバージョンになっており、
コンパクトなヘッダーで設計されているわけではない
リンク層
IP、TCP、UDPなどの上位レイヤーのプロトコル

6
6 . 6 . 5 H e a d e r C o m p r e s s i o n
上 位 レ イ ヤ ー の ヘ ッ ダー
上位レイヤーのヘッダーは、パフォーマンスに大きな打撃を与える可能性がある
IP、UDP、RTPの組み合わせで伝送されるVoice-over-IPデータ
これらのプロトコルは40バイトのヘッダを必要とする
IPv4は20バイト、UDPは8バイト、RTPは12バイト
IPv6ではさらに状況が悪化し、40バイトのIPv6ヘッダを含めて60バイトに
ヘッダーは送信データの大部分を占め、帯域幅の半分以上を消費

7
6 . 6 . 5 H e a d e r C o m p r e s s i o n
ヘ ッ ダー 圧 縮
上位層のプロトコルヘッダがリンク上で
占有する帯域幅を削減するために使用される
汎用的な方式ではなく、特別に設計された方式が使用される
ヘッダーが短いため、個々にうまく圧縮できない
伸長するためには、それ以前のデータをすべて受信している必要がある

8
6 . 6 . 5 H e a d e r C o m p r e s s i o n
ヘ ッ ダー 圧 縮 の 特 徴
プロトコル形式の知識を利用することで大きな利点を得られる
最初のスキームの1つ
低速のシリアルリンク上でTCP/IPヘッダーを圧縮するために設計
by Van Jacobson（1990）
40バイトの典型的なTCP/IPヘッダーを平均3バイトに圧縮
ヘッダーフィールドの多くはパケットごとに変化しない
IPのTTLやTCPのポート番号などは，パケットごとに同じものを送る必要はない
リンクの送信側で省略し受信側で埋めればよい

9
6 . 6 . 5 H e a d e r C o m p r e s s i o n
予 測 可 能 な 方 法 で 変 化 す る
ロスがなければ、TCPシーケンスナンバーはデータとともに進む
受信側では、予想される値を予測することができる
実際の番号は、予想と異なる場合にのみ伝える必要がある
その場合でも、新しいデータを逆方向で受信したときにACKが増加するように
以前の値からの小さな変化として伝送されるかもしれない

10
6 . 6 . 5 H e a d e r C o m p r e s s i o n
ヘ ッ ダー 圧 縮 に よ る 効 果
上位層のプロトコル
低帯域のリンク
シンプルなヘッダ
コンパクトなエンコーディング

11
6 . 6 . 5 H e a d e r C o m p r e s s i o n
R O H C ( R O b u s t H e a d e r C o m p r e s s i o n ) と は
• 無線リンクで発生しうるロスを許容するように設計
• IP/UDP/RTPなど、圧縮するプロトコルのセットごとにプロファイルが用意
RFC 5795 でフレームワークとして定義されている現代版ヘッダー圧縮
ヘッダーフィールドは、同じ接続のパケットでは容易に予測できるが、
異なる接続のパケットでは予測できない
• IP/UDP/RTPヘッダーを40バイトから1〜3バイトに圧縮
• 圧縮されたヘッダーは、基本的に接続であるコンテキストを参照して運ばれる

12
6 . 6 . 5 H e a d e r C o m p r e s s i o n
ヘ ッ ダー 圧 縮 に よ る も う 一 つ の 効 果
必要な帯域幅を減らす 遅延を減らす
遅延
ネットワーク経路によって固定される伝搬遅延
帯域幅と送信データ量に依存する伝送遅延
Ex. 1Mbpsのリンクでは、1ビットを1μ秒で送信する
無線ネットワーク上のメディアの場合
伝送遅延は全体の遅延の重要な要因となる可能性
一貫して低い遅延はサービス品質にとって重要

13
6 . 6 . 5 H e a d e r C o m p r e s s i o n
キ ュ ー イ ン グ 遅 延
ヘッダー圧縮と同じ効果 より小さなパケットを送信する
ソフトウェアのオーバーヘッドの増加を、
伝送遅延の減少と交換することになる
もう一つの潜在的な遅延の原因
無線リンクにアクセスするための キューイング遅延
無線リンクはリアルタイムパケットに低遅延を与える
QoS メカニズムを備えている必要がある

Protocols for Long Fat Networks
6 . 6 . 6

15
6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
ロ ン グ フ ァ ッ ト ネ ッ ト ワ ー ク
ファットパイプ
長い遅延時間 ロングファットネットワーク
1990 年代以降、データを長距離伝送するギガビットネットワークが存在
様々な問題が発生
これらのネットワークの上で既存のプロトコルを使おうとした

16
6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
問 題 そ の 1 シ ー ケ ン ス 番 号 の 不 足
多くのプロトコルが
32ビットのシーケンス番号を使用していること
問題その1
…
ホストが全速力で爆走すると、シーケンス番号を一回通過するのに一週間以上かかった
古いパケットが送信後1週間経っても残っている危険性はほとんどなかった
当時のルーター間の回線はほとんど56kbps

17
6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
問 題 そ の 1 シ ー ケ ン ス 番 号 の 不 足
10MbpsのEthernet
1GbpsのEthernet
57分
34秒
管理可能
危険性アリ
最大パケット寿命である120秒を大きく下回る
古いパケットがまだ存在する間にシーケンス空間を循環させることができる

18
6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
問 題 そ の 1 シ ー ケ ン ス 番 号 の 不 足
多くの
プロトコル設計者
シーケンス空間を使い切るために必要な時間
＞＞＞最大パケット寿命
ギガビットの速度ではこの前提が成り立たない
各パケットのTCPヘッダーにオプションとして搭載できる
タイムスタンプを上位ビットとして扱うことで、
有効なシーケンス番号を拡張できることが判明
PAWS (Protection Against Wrapped Sequence numbers)
※RFC1323で説明

19
6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
問 題 そ の 2 フ ロ ー コ ン ト ロ ー ル ウィ ン ド ウ の サ イ ズ
フローコントロールウィンドウのサイズを
大幅に大きくしなければならないこと
問題その2

20
6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
問 題 そ の 2 フ ロ ー コ ン ト ロ ー ル ウィ ン ド ウ の サ イ ズ
サンディエゴからボストンへ
64KBのバーストデータを送信する
パイプは空 先頭のセグメントは
南カルフォルニアのブラウリー近辺の
どこかにいる
送信機はウィンドウの更新を
取得するまで停止
t=0 500μsec

21
6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
問 題 そ の 2 フ ロ ー コ ン ト ロ ー ル ウィ ン ド ウ の サ イ ズ
パイプは空
リードセグメントがボストンへ
→ACK
100msecのうち1.25msecは
伝送路を使用している
→効率は1.25%程度
ACKが送信者へ
2番目のバーストを送信
t=0 500μsec
20msec 40msec

22
6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
問 題 そ の 2 フ ロ ー コ ン ト ロ ー ル ウィ ン ド ウ の サ イ ズ
帯域幅
bandwidth-delay product（帯域幅-遅延積）
往復の遅延時間
（単位：ビット／秒） （単位：秒）
送信側から受信側までのパイプの容量
（単位：ビット）
図の例では、パイプの容量は4000万ビット
50万ビットのバーストが1.25%の効率しか達成できないのはこのため

23
6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
問 題 そ の 2 フ ロ ー コ ン ト ロ ー ル ウィ ン ド ウ の サ イ ズ
受信機のウィンドウは
少なくとも帯域幅-遅延積と同じ大きさでなければならない
結論
大陸横断のギガビット回線では最低でも5MBが必要

go-back-nプロトコルのような単純な再送信方式では、
帯域-遅延積の大きな回線では性能が低下すること
24
6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
問 題 そ の 3 単 純 な 再 送 信 方 式 で は 性 能 が 低 下 す る
問題その3

25
6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
問 題 そ の 3 単 純 な 再 送 信 方 式 で は 性 能 が 低 下 す る
selective-repeatのような、より複雑なプロトコルが必要
結論
1Gbpsの大陸横断回線で、往復の伝送時間が40msec
送信者は一回の往復で5MBを送信する
エラーが検出された場合
送信者がそれを知るまでに40msecかかり
問題のパケット＋5MB分のパケットも再送信

長いギガビット回線は帯域制限ではなく、
遅延制限を受けるという点こと
26
6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
問 題 そ の 4 ギ ガ ビ ッ ト 回 線 は 遅 延 制 限 を 受 け る
問題その4

27
6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
問 題 そ の 4 ギ ガ ビ ッ ト 回 線 は 遅 延 制 限 を 受 け る
1Mbps 1Gbps
1Mbit のファイルを 4000km 転送するのにかかる時間を、様々な伝送速度で示したもの

28
6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
問 題 そ の 4 ギ ガ ビ ッ ト 回 線 は 遅 延 制 限 を 受 け る
RPC のような停止して待つプロトコルは、
その性能に固有の上限がある
結論
この上限は光速によって決定されるため、問題は改善されない
ギガビット回線に何か他の用途が見つからない限り、
ギガビット回線はメガビット回線と変わらないどころか、より高価なものに

通信速度が計算速度より速くなったこと
29
6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
問 題 そ の 5 通 信 速 度 が 計 算 速 度 よ り 速 く な っ た こ と
問題その5
1970年代のARPANETは56kbpsで、1MIPS程度のコンピュータで動いていた
1Gbpsの回線でパケット交換をする1000MIPSのコンピュータ
1バイトあたりの命令数は10分の1以上に減少
プロトコルの処理に使える時間は少なくなり、シンプルにならざるを得ない

30
6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
問 題 そ の 5 通 信 速 度 が 計 算 速 度 よ り 速 く な っ た こ と
「帯域の最適化ではなく、速度のための設計」
旧プロトコル ワイヤ上のビット数を最小限に抑えるように設計
プロトコルの処理に問題があるため、
それを最小限に抑えるように設計
ギガビットネットワーク
IPv6の設計者は、この原則を明確に理解していた
高速ネットワークの設計者が心得ておくべき基本原則

6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
高 速 化 す る た め の 方 法
高速なネットワークインターフェースをハードウェアで構築
31
ハードウェアは、第2のCPUと独自のプログラムを持つプラグインボードに
プロトコルをシンプルにして、メインCPUに仕事をさせるのがベスト

6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
32
ハードウェアは、第2のCPUと独自のプログラムを持つプラグインボードに
• ネットワークコプロセッサーはメインCPUよりも安価であることを確認する
ために、より低速なチップに
• メイン（高速）CPUは多くの時間、第2（低速）CPUが重要な仕事をするの
を待つためにアイドル状態に
• 2つのプロセッサ間で正しく同期をとり、
レースを回避するための精巧なプロトコルが必要
高 速 化 す る た め の 方 法

6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
33
パ ケ ッ ト レ イ ア ウ ト
ヘッダ
フィールド
できるだけ少ないフィールドで構成されるべき
仕事をするのに十分な大きさで
高速処理のためにワードアラインされている
・古いパケットがまだ存在しているのにシーケンス番号が回り込んでしまう
・フィールドが小さすぎて受信者が十分なウィンドウスペースをアドバタイズできない
などの問題が発生しないこと

6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
34
パ ケ ッ ト レ イ ア ウ ト
最大データサイズは大きくする必要がある
ソフトウェアのオーバーヘッドを減らし、効率的な運用を可能にするため
ギガビットイーサネット 9KBまでのジャンボフレーム
IPv6 64KBを超えるジャンボパケット
1500バイトは高速ネットワークでは小さすぎ

6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
35
高 速 プ ロ ト コ ル の フィ ー ド バ ッ ク
スライディングウィンドウプロトコルを用いて送信レートを制御
フィードバックの例 その1
将来のプロトコルは、受信者が送信者にウィンドウの更新を送信する際に
固有の（長い）遅延を回避するために、レートベースのプロトコルに切り替えることができる
遅延ループが比較的長いため、フィードバックは避けなければならない
ある速度よりも速く送信しない限り、送信したいものをすべて送信することができる

6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
36
高 速 プ ロ ト コ ル の フィ ー ド バ ッ ク
Jacobsonのスロースタートアルゴリズム
フィードバックの例 その2
半ダースほどのプローブを作ってネットワークの反応を見ると膨大な帯域幅を浪費
ネットワークがどの程度処理できるかを確認するため、複数のプローブが行われる
送信側、受信側、ネットワーク側で、
接続時に必要なリソースを確保する方式が効率的

6 . 6 . 6 P r o t o c o l s f o r L o n g F a t N e t w o r k s
37
高 速 プ ロ ト コ ル の フィ ー ド バ ッ ク
事前にリソースを確保することで、ジッターを低減しやすくなる
高速になればなるほど、コネクションオリエンテッドな運用になる
通常のデータ量を接続要求と一緒に送信できること
1往復分の時間を節約することができる

DELAY-TOLERANT NETWORKING
6 . 7 . 0

トランスポートプロトコルは、
送信者と受信者が何らかの作業経路で
連続的に接続されているという前提で成り立っている
6 . 7 . 0 D E L AY-T O L E R A N T N E T W O R K I N G
39
新 し い 種 類 の ト ラ ン ス ポ ー ト
ネットワークによっては、
エンドツーエンドのパスが存在しないこともよくある

6 . 7 . 0 D E L AY-T O L E R A N T N E T W O R K I N G
40
新 し い 種 類 の ト ラ ン ス ポ ー ト
ある衛星が地上局と通信できるのは特定の時間帯だけで、
2つの衛星は地上局を経由しても、片方の衛星が常に圏外にあるため、
お互いに通信できないことがある
潜水艦やバス、携帯電話など、
移動体や過酷な条件下で断続的に接続されるコンピュータを搭載した機器もある
宇宙ネットワーク

6 . 7 . 0 D E L AY-T O L E R A N T N E T W O R K I N G
41
メ ッ セ ー ジ ス イ ッ チ ン グ と D T N
時折接続されるネットワークでは、
データをノードに保存しておき、
後でリンクが使えるようになったときに転送する
メッセージスイッチング
このようなアーキテクチャを持つネットワークを
DTN（Delay-Tolerant Network、またはDisruption-Tolerant Network）

6 . 7 . 0 D E L AY-T O L E R A N T N E T W O R K I N G
42
D T N
Kevin Fall
惑星間インターネットのアイデアが、
地球上のネットワークに適用できる
IETFが研究グループを立ち上げ
「宇宙でパケットを送ろう！」
DTNの研究の始まり
宇宙ネットワークは、断続的な通信と非常に長い遅延に対処する必要
通信中に蓄積と遅延が発生しうるインターネットを有用に一般化
（2003）

6 . 7 . 0 D E L AY-T O L E R A N T N E T W O R K I N G
43
グ ロ ー バ ル サ ー ビ ス の 問 題 点
2002年以降、DTNアーキテクチャは改良され、DTNモデルのアプリケーションは拡大
世界中の異なる場所にあるデータセンターにコピーする必要がある、
何TBもの大きなデータセットについて考える
この大量トラフィックをオフピーク時に送信して、
すでに支払われているが使用されていない帯域幅を利用したい
多少の遅延は許容
オフピークの時間帯が世界中の拠点で異なる

6 . 7 . 0 D E L AY-T O L E R A N T N E T W O R K I N G
44
D T N モ デ ル の 利 点
DTNモデルでは、転送中のストレージと遅延を許容
ボストン パース
アムステルダム
オフピークとなる時間帯は、ほとんど重ならないかもしれない
オフピークの帯域幅を
使用して送信
オフピークの帯域幅を
使用して送信
オフピークになるまで保管

6 . 7 . 0 D E L AY-T O L E R A N T N E T W O R K I N G
45
D T N モ デ ル の 利 点
Laoutaris et al.
わずかなコストでかなりの容量を提供できる
DTNモデルを使用することで、従来のエンドツーエンドに比べて
容量が2倍になることが多い
（2009）

DTN Architecture
6 . 7 . 1

6 . 7 . 1 D T N A r c h i t e c t u r e
47
D T N が 緩 和 す る 際 の 前 提
DTNが緩和するインターネットの前提
送信元と送信先の間のエンドツーエンドのパスが
通信セッションの全期間にわたって存在すること
これが成立しない場合、通常のインターネットプロトコルは失敗

6 . 7 . 1 D T N A r c h i t e c t u r e
48
D T N ア ー キ テ ク チ ャ
メッセージスイッチングに基づくアーキテクチャによって、
エンドツーエンドの接続性の欠如を回避
また、信頼性の低いリンクや大きな遅延を許容
RFC 4838で規定

6 . 7 . 1 D T N A r c h i t e c t u r e
49
D T N ア ー キ テ ク チ ャ
永続的
メッセージ 動作していない
動作している

6 . 7 . 1 D T N A r c h i t e c t u r e
50
D T N ノ ー ド と ル ー タ の 違 い 1
DTNノードでのバンドルの蓄積と転送
ルータでのパケットのキューイングと転送
何時間もバンドルが保存されることがある
キューイングはミリ秒から長くても秒単位で発生する
似ているように聞こえるが 質的な違いがある

6 . 7 . 1 D T N A r c h i t e c t u r e
51
D T N ノ ー ド と ル ー タ の 違 い 2
DTNノードでのバンドルの蓄積と転送
ルータでのパケットのキューイングと転送
ノードが移動する可能性がある
ルーターは移動することができない
似ているように聞こえるが 質的な違いがある
Store-carry-forward

6 . 7 . 1 D T N A r c h i t e c t u r e
52
宇 宙 で の D T N プ ロ ト コ ル
Wood et al. 宇宙で初めてDTNプロトコルを使用したシナリオ
地球画像を記録しているLEO衛星
地上局
収集地点

6 . 7 . 1 D T N A r c h i t e c t u r e
53
宇 宙 で の D T N プ ロ ト コ ル の 利 点
画像撮影時に接続性がないため、
衛星が画像を保存する必要がある状況に自然に適合すること
利点その1

6 . 7 . 1 D T N A r c h i t e c t u r e
54
宇 宙 で の D T N プ ロ ト コ ル の 利 点
画像を送信するのに十分な長さのコンタクトが存在しない場合
3つの地上局とのコンタクトに分散させることができる
利点その2
衛星のダウンロードが、
低速の地上波リンクによって制限されない
利点その3
中継が可能になるまで地上局でバンドルが保存され、フルスピードで進めることができる

6 . 7 . 1 D T N A r c h i t e c t u r e
55
宇 宙 で の D T N プ ロ ト コ ル の 問 題
DTNノードを経由する良い経路をどのように見つけるか
問題
良いルートは、アーキテクチャの性質によって、
いつデータを送るか、また、どのコンタクトを送るかが記述されている
いくつかのアドレスは事前に知られている
例：宇宙の例で天体の動き
コンタクトの間隔は各地上局とのパスごとに5分から14分であること、
ダウンリンクの容量は8.134Mbpsであることが事前に分かっていた
事前に計画できる

6 . 7 . 1 D T N A r c h i t e c t u r e
56
宇 宙 で の D T N プ ロ ト コ ル の 問 題
接触が予測できる場合もあるが、その確実性は低い
ISPネットワークのオフピーク帯域の時間や量は
過去のデータから予測されるが、接触は時折でランダムな場合がある
接触に予測不可能性がある場合、1つのルーティング戦略は、
寿命に達する前にコピーの1つが宛先に届けられることを期待して、
異なる経路に沿ってバンドルのコピーを送信する

The Bundle Protocol
6 . 7 . 2

6 . 7 . 2 T h e B u n d l e P r o t o c o l
58
I E T F プ ロ ト コ ル
スタート地点としては適しており、
重要な問題の多くを浮き彫りにしている
DTNは新しい種類のネットワークであり、
実験的なDTNではさまざまなプロトコルが使用されている
IETFのプロトコルを使用するという要件はない

6 . 7 . 2 T h e B u n d l e P r o t o c o l
59
B u n d l e プ ロ ト コ ル
BundleプロトコルがUDPなどの他の種類のプロトコル、
あるいは他の種類のインターネット上で実行される可能性がある

6 . 7 . 2 T h e B u n d l e P r o t o c o l
60
B u n d l e プ ロ ト コ ル
宇宙ネットワークでは、リンクは非常に長い遅延を持つかもしれない
TCPの確認応答と再送信はこのリンク上でどの程度機能するか
→特に比較的短いメッセージの場合、うまくいかない
エラー訂正コードを使用する別のプロトコル か、
リソースに制約のある場合は、TCPよりも軽量なプロトコルを使う

6 . 7 . 2 T h e B u n d l e P r o t o c o l
61
B u n d l e プ ロ ト コ ル
Bundleプロトコルにはプロトコル間の機能的なギャップがあるはず
図に Convergence層を入れた理由
61

6 . 7 . 2 T h e B u n d l e P r o t o c o l
C o n v e r g e n c e 層
Convergence層
それが結合するプロトコルのインタフェースに一致する単なる接着剤層
異なる下位層トランスポートごとに異なるコンバージェンス層が存在
新規および既存のプロトコルを結合するための標準規格によく見られる
62

6 . 7 . 2 T h e B u n d l e P r o t o c o l
バ ン ド ル プ ロ ト コ ル メ ッ セ ー ジ
63
バンドルプロトコルメッセージのフォーマット
バンドルプロトコルによって処理される重要な問題

6 . 7 . 2 T h e B u n d l e P r o t o c o l
バ ン ド ル プ ロ ト コ ル メ ッ セ ー ジ
64
ヘッダー データ その他
ソースがそのバンドルを
より高いまたはより低い優先順位として
マークするためのサービスのクラスと、
宛先がバンドルを承認すべきかどうかなどの
他の処理要求を符号化

6 . 7 . 2 T h e B u n d l e P r o t o c o l
カ ス ト ディ ・ ト ラ ン ス フ ァ ー 設 計 の 特 徴 そ の 1
65
バンドルが配送されるのを
確認する責任を負う当事者

6 . 7 . 2 T h e B u n d l e P r o t o c o l
66
インターネット
DTN
ソースノードが再送信を行う
送信先に近いカストディアンが、
データを安全に届ける責任を負う
送信元ノードが常に接続されているとは限らない
「カストディ・トランスファー」
カ ス ト ディ ・ ト ラ ン ス フ ァ ー 設 計 の 特 徴 そ の 1

6 . 7 . 2 T h e B u n d l e P r o t o c o l
67
独 自 の 識 別 子 設 計 の 特 徴 そ の 2
Bundleプロトコルは、様々なトランスポートや
インターネット上で動作することを目的としているため、
独自の識別子を定義している
識別子がIPアドレスではない
IPアドレスのような低レベルのアドレスというよりも、
WebページのURLのような高レベルの名前に近い
DTNは、電子メール配信やソフトウェアアップデートの配布など、
アプリケーションレベルのルーティングという側面を持つ

すべての識別子は、
可変長のDictionaryフィールドへの参照として符号化されている
カストディアンやレポート・ノードが
ソースやデスティネーションと同じである場合に圧縮される
6 . 7 . 2 T h e B u n d l e P r o t o c o l
68
識 別 子 の エ ン コ ー ド 方 法 設 計 の 特 徴 そ の 3
識別子のエンコード方法
メッセージフォーマットの多くは、可変長フィールドのコンパクトな表現を使用することで、
拡張性と効率性の両方を念頭に置いて設計されている
コンパクトな表現は、無線リンクやリソースに制約のあるノードにとって重要

6 . 7 . 2 T h e B u n d l e P r o t o c o l
69
フィ ー ル ド
Creationフィールド
Lifetimeフィールド
バンドルが作成された時刻を示す
バンドルデータが有用でなくなる時刻を示す
データがDTNノードに長期間保存される可能性があり、
ネットワークから古いデータを削除する何らかの方法が必要なため
インターネットとは異なり、DTNノードが緩く同期されたクロックを持つことが必要

Lengthフィールド
Dataフィールド
6 . 7 . 2 T h e B u n d l e P r o t o c o l
70
フィ ー ル ド
Dictionaryフィールド
Typeフィールド
Flagsフィールド
ペ
イ
ロ
ド
ブ
ロ
ク

DTNの種類に依存
6 . 7 . 2 T h e B u n d l e P r o t o c o l
71
D T N に よ る 問 題
• 輻輳制御は、ノードにおけるストレージを
枯渇する可能性のある別の種類のリソースとして考慮しなければならない
ネットワーク内にデータを保存することによって提起される問題
• エンド・ツー・エンドの通信がないため、セキュリティの問題も深刻化
宇宙ネットワークはセンサーネットワークとは異なるため

END