画像情報特論 (9) 放送と通信の統合

画像情報特論 (9)
- CDN/P2P、IPTV、放送と通信の統合
放送と通信の統合
情報ネットワーク専攻 甲藤二郎
E-Mail: [email protected]
総務省資料 (1)
年表
出典： 総務省, 通信・放送の在り方に関する懇談会 (2006)
海外
総務省資料 (2)
映像配信（国内）
総務省資料 (3)
出典： 総務省, 通信・放送の在り方に関する懇談会 (2006)
出典： 総務省, 通信・放送の在り方に関する懇談会 (2006)
AT&T UU-verse
出典： AT&T (SBC)
1
IPTVの一般形
IPTVの一般形
Microsoft TV
（デジタル放送再送信？）
コンテンツサーバー
DVB, DAB
放送局
Carrier (Telephone, CATV, Satellite)
WM9S Server
パブリック
インターネット
IP
encapsulation
コアノード
Media
優先制御
Mobile
ホームゲートウェイ
WM9S
Encoders
エッジノード
IP (DSL)
IPマルチキャスト、IPv6 等
映像配信IP網 (CDN)
ホームネットワーク
IPIP-based
Streaming
アクセスネットワーク
= Managed Network
出典： Microsoft
総務省資料 (4)
総務省資料 (5)
サービス
Triple Play = Voice + Video + Data
出典： 総務省, 通信・放送の在り方に関する懇談会 (2006)
出典： 総務省, 通信・放送の在り方に関する懇談会 (2006)
サーバ型放送（サービス）
ブロードバンド接続と大容量ホームサーバの活用
ワンセグ
携帯端末向けデジタル放送
諸外国の動向：
（欧州） DVB-H
H.264
（米国） MediaFLO
＋メタデータの活用、DRM
インターネット
さらにネットに誘導
出典： 総務省関東総合通信局
（韓国） DMB
出典： 総務省関東総合通信局
2
マルチキャスト
ホスト (受信端末)
サーバ
ルータ
(a) ユニキャスト
IPマルチキャスト
サーバ
ホスト (受信端末)
マルチキャスト
ルータ
(b) マルチキャスト
サーバ
スプリッタ
ホスト (受信端末)
(c) スプリッタ (アプリケーション層マルチキャスト)
IPマルチキャスト
IPマルチキャスト (1)
IPマルチキャスト
IPマルチキャスト (2)
• Shortest Path Tree と Shared Tree
マルチキャスト
サーバ
Shortest Path Tree : (S, G)
マルチキャスト
ルータ
マルチキャスト・ルーティング・
プロトコル
マルチキャスト
ルータ
(S,G): マルチキャストグループ
IGMP
G: マルチキャストアドレス
各ルータは、パケットを受信したインタフェ
ース以外のすべてのインタフェースにパケ
ット転送。(S,G) エントリによる経路管理。
送信者 (S)
下流のルータは、状況に応じて転送停止・
再開要求を出し、経路を確定。
② 経路の確立・削除
S: 送信者アドレス
フラッディング：
Shared Tree : (*, G)
コアルータ：
マルチキャストグループ毎に特定のコア
ルータにパケットをいったん集約。ここま
では、(S, G) エントリによる経路管理。
① Join/Leave
送信者 (S)
クラスDアドレス：
224.0.0.0 ～ 239.255.255.255
下流のルータは、必要に応じてコアルータ
に参加要求を出し、経路を確定。コアルー
タ以下は、(*, G) エントリによる経路管理。
コアルータ
IPマルチキャスト
IPマルチキャスト (3)
• DVMRP version 3
• PIM-SM
Prune メッセージ
Prune (刈り取り)：
下流にマルチキャストグループ参加者が
いない場合、上流ルータにパケット配送
停止を要求。
Prune
送信者
IPマルチキャスト
IPマルチキャスト (4)
Prune
Join メッセージ
Join (参加)：
Join
送信者
Join
途中のルータ： (S, G) エントリ削除。
途中のルータ： (*, G) エントリ追加。
コアルータ
Prune
Graft メッセージ
Graft (接ぎ木)：
Prune メッセージ
Prune (離脱)：
下流にマルチキャストグループ参加者が
送信者
下流にマルチキャストグループ参加者が
現れた場合、上流ルータにパケット配送
開始を要求。
現れた場合、上流ルータにパケット配送
再開を要求。
Graft
Prune
送信者
Prune
下流のマルチキャストグループ参加者が
離脱した場合、上流ルータにパケット配送
停止を要求
Graft
途中のルータ： (*, G) エントリ削除
途中のルータ： (S, G) エントリ追加。
コアルータ
Distance Vector Multicast Routing Protocol
Protocol Independent Multicast – Sparse Mode
3
IPマルチキャスト
IPマルチキャスト (5)
IPマルチキャスト
IPマルチキャスト (6)
• まとめ
• SSM
Any Source
ASM (Any Source Multicast: 従来)
同じマルチキャストアドレス G を使用するセッ
受信者
(R2, G)
送信者
(S1, G)
プロトコル名
特徴
長所
短所
DVMRP
最小経路 (S, G)
最小経路
フラッディングによる不要
なトラヒックの増加
ションのすべての参加者にパケット配信
送信者
(S2, G)
送信者がパケットを投げると、フラッデ
⇒ 同じマルチキャストグループに複数の送信
者が送信可能 (many-to-many)
PIM-SM
⇒ 多人数会議
送信者・コアルータ： 最小経路 (S, G)
フラッディングが不要
共有経路が必ずしも最短
コアルータ・受信者： 共有経路 (*, G)
⇒ 拡張性
経路にならない
コアルータの決定方法
受信者
(R1, G)
Source Specific
受信者
(R2, G)
送信者
(S1, G)
⇒ 拡張性
ィングによって最小経路を確定、配信
送信者がコアルータに「登録」すると、
プロトコルが若干複雑
SSM:
最小経路を確定
(最短経路と共有経路の
送信者によって限定される (S, G) セッション
受信者がコアルータに「参加」すると、
動的切替え)
参加者のみにパケット配信
共有経路を確定、配信
SSM
送信者
(S2, G)
最小経路 (S, G)
⇒ 送信者を一人に限定 (one-to-many)
⇒ インターネット放送
(232.0.0.0 ～ 232.255.255.255)
受信者
(R1, G)
1 対多の放送型アプリケ
1 対多に限定
ーション
IGMP v3 が必須
受信者が送信者に subscribe すると
PIM-SM とのハイブリッド
最小経路を確定、配信
構成 (PIM-SSM)
Source Specific Multicast
マルチキャスト放送 (1)
マルチキャスト放送 (2)
• (1) WWW による番組案内
• (2) SAP による番組案内
サーバ
SAP: Session Announcement Protocol
定期的に番組案内 (SDP) をマルチキャスト
クライアント
SAP (by IP Multicast)
① ファイル要求
WWW
WWW
サーバ
サーバ
クライアント
サーバ
HTTP
Web
Web
ブラウザ
ブラウザ
① 番組案内
② メタファイル
メタファイル
③ ビューアの起動
IGMP
IGMP
ライブ入力
④ 参加
ライブ入力
ストリーム
ストリーム
サーバ
サーバ
ストリーム
ファイル
ビューア
ビューア
ストリーム
ストリーム
サーバ
サーバ
② 参加
ビューア
ビューア
ストリーム
ファイル
⑤ ストリーミング
③ ストリーミング
IP Multicast
IP Multicast
RFC 2974： vic/rat/sdr
マルチキャスト放送の長所と短所
ユニキャスト放送
マルチキャスト放送
トラヒックの削減 (原理的に冗長なパケット
クライアントの接続状況に合わせたふくそう は発生しない) 、およびサーバ負荷の削減
制御が可能
既存のシステムの変更が不要
長所
短所
階層化マルチキャスト
クライアントの増加に伴うトラヒックの爆発、 マルチキャストルータの普及と各種設定
ならびにサーバ負荷の増大 (線形増加)
クライアント毎のふくそう制御が困難
マルチキャストルーティングプロトコル
課題
ふくそう制御アルゴリズム
例： 階層化マルチキャスト
4
スケーラブル符号化
階層化マルチキャスト (1)
レイヤ3
空間スケーラビリティ
or SNRスケーラビリティ
EI
EP
マルチキャスト
サーバ
マルチキャスト
ルータ
EP
広帯域
ベースライン
I
B
P
B
P
階層化されたマルチキャストストリーム
B
＝ 複数のマルチキャストグループ
時間スケーラビリティ
レイヤ1
レイヤ2
狭帯域
Leave
Receiver-Driven Layered Multicast
レイヤ1のみ： 低品質、低レート
• 空間解像度の階層化：空間スケーラビリティ
• 時間解像度の階層化：時間スケーラビリティ
• SNRの階層化：SNRスケーラビリティ
すべてのレイヤ： 高品質、高レート
受信者主導で、各端末の帯域に合わせて
階層の取捨選択 (= マルチキャストグループ
への加入と離脱) を行う
S.MaCanne et al: “Receiver-driven Layered Multicast,” SIGCOMM’96.
階層化マルチキャスト (2)
階層化マルチキャスト (3)
• Join Experiment
• Shared Learning
Join 実験の他の端末への通知
Join、Leave (ふくそう検出)、バックオフを繰り返し、レートを安定させる
RH
廃棄
廃棄
RL
廃棄
広帯域
detection time
狭帯域
RL
レイヤ4
Join
S
Leave
RL
レイヤ3
join timer *= α (バックオフ)
Join
1回目
レイヤ2
2回目
Join 実験
RL
RL
Join
レイヤ1
• 端末数の増加に伴う Join 実験の回数の増加を防ぐ
join timer (レイヤ毎)
• 上流の広帯域 Join 実験と下流の狭帯域 Join 実験の結果の混同を防ぐ
TCP タイムアウトと同様のバックオフメカニズム
階層化マルチキャスト (4)
• RLM の状態遷移図
Steady
Join 実験成功 (レイヤ増加)
S
Join 実験失敗 (レイヤ削減)
Hysterisis
CDN
Join 実験
以外の廃棄
H
D
Drop
Content Delivery Network
廃棄率大 (レイヤ削減)
遷移状態
M
Measurement
detection time の終了
5
サイト内負荷分散 (1)
CDN
• サーバの負荷分散 & 転送遅延の改善
• L3 スイッチ
サーバ群
• 複数サーバによるサイト内負荷分散
サーバ
• 複数サイトによる負荷分散・遅延改善
負荷の集中
サーバ群
L3 スイッチ
サーバ群
インターネット
オリジン
サイト
ミラーリング
CDN
オリジン
サイト
リモート
サイト#1
ラウンドロビン
インターネット
接続要求 ＆
コンテント配信
接続要求
インターネット
ミラーリングとラウンドロビンによる負荷分散：
遅延の増大
クライアント
クライアント
リモート
サイト#n
コンテント
配信
長所： スイッチの負荷が軽い
短所： ミラーリングの効率が悪い (すべてのサーバが同じデータを持つ)
サーバ群
サイト内負荷分散 (2)
サイト内負荷分散 (3)
• L4 スイッチ
• L4/L7 スイッチ
サーバ群
サーバ群
Web (80番)
テキスト
L4/L7 スイッチ
L4 スイッチ
インターネット
インターネット
画像
ストリーミング
(RTSP: 554番)
ストリーム
コンテンツ (URL) 単位の振り分け
ポート番号で振り分け
アプリケーション (ポート番号: L4情報) に応じた分散サーバ配置：
コンテンツ (URL: L7情報) に応じた分散サーバ配置：
長所： アプリケーションに応じたきめこまかい負荷分散が可能
長所： コンテンツ単位のさらにきめこまかい負荷分散が可能
(短所： L3 スイッチよりはスイッチの負荷が大きい)
短所： スイッチの負荷が大きい
サイト内負荷分散 (4)
サイト内負荷分散 (5)
• Delayed Bound (1)
クライアント
• Delayed Bound (2)
L4/L7スイッチ
サーバ#1
サーバ#2
クライアント
SYN
クライアント・スイッチ間、
ACK
スイッチ・サーバ間で
複数の TCP コネクション
SYN/ACK
HTTP GET
を終端
＝ Delayed Bound
SYN
L4/L7スイッチ
サーバ#1
サーバ#2
Data #1
Data #2
Data #1+ #2
SYN/ACK
ACK
SYN
SYN/ACK
サーバ#1、サーバ#2
ACK
からのデータを集約
= Aggregate
HTTP GET #1
HTTP GET #2
HTTP 1.1 の例
HTTP 1.1 の例
6
サイト間負荷分散
リクエストルーティング (1)
• サイト間負荷分散 & 転送遅延の改善
サーバ群
• DNS リダイレクション (1)
サーバ群
CDN’s
DNS サーバ
複数サイト (サーバ群)
の分散配置
オリジン
サイト
リモート
サイト#1
リモート
サイト#1
② DNS 要求
クライアントからの要求
接続要求
③ DNS 応答
インターネット
に応じて、適切なサイト
インターネット
クライアント
オリジン
サイト
を選択、誘導
ローカル
DNS サーバ
リモート
サイト#n
ストリーム
配信
⑤ 接続要求
① DNS 要求
リモート
サイト#n
サロゲート
(surrogate)
サイト間負荷分散 &
④ DNS 応答
転送遅延の改善
⑥ ストリーミング
クライアント
サーバ群
解像度： ドメイン単位 (粗い)
リクエストルーティング (2)
リクエストルーティング (3)
• DNS リダイレクション (2)
• DNS リダイレクション + L4 スイッチ
DNS リダイレクション
Single Reply
方式
CDN’s
DNS サーバ
CDN 内 DNS サーバが最適サロゲートを A レコード (IP アドレス) で返す方式
(例： stream.com → 192.168.0.1)
Multiple Reply
オリジン
サイト
リモート
サイト#1
CDN 内 DNS サーバが複数のサロゲート候補を A レコードで返し、ラウンドロビンで
サロゲートを選択する方式
(例： stream.com → 192.168.0.1, 192.168.0.2, 192.168.0.3 → 192.168.0.2)
NS Redirection
CDN 内 DNS サーバが、第三の DNS サーバに NS レコード (ネームサーバ) を返
し、その DNS サーバが最適サロゲートを A レコードで返す方式
サロゲート
(surrogate)
② DNS 要求
③ DNS 応答
インターネット
⑥ 接続要求
(例： stream.com → server1.site1.stream.com → 192.168.0.3)
CNAME Redirection
CDN 内 DNS サーバが、第三の DNS サーバに CNAME レコード (エイリアス) を返
ローカル
DNS サーバ
し、その DNS サーバが最適サロゲートを A レコードで返す方式
(例： stream.com → site1.stream.com → 192.168.0.4)
Object Encoding
L4 スイッチ
① DNS 要求
⑤ 接続要求
(サイト選択)
DNS の名前にオブジェクトのタイプ等を埋め込んでしまい、それに応じてサロゲー
④ DNS 応答
トの IP アドレスを振り分ける方式
(例： stream.com → mpeg_content1.site1.stream.com → 192.168.0.5)
⑦ ストリーミング
クライアント
サロゲートの IP アドレスを返す代わりに L4 スイッチの IP アドレスを返す (負荷分散)
リクエストルーティング (4)
リクエストルーティング (5)
• URL リライティング (L7 スイッチ)
• URL リライティング (2)
CDN’s
L7 スイッチ
URL リライティング
オリジン
サイト
Header Inspection (1)
リモート
サイト#1
サロゲートへの 302 リダイレクションコードを返す
① メタファイル、
レイアウト記述要求
(例) “302” Moved Temporarily
Header Inspection (2)
② メタファイル、
レイアウト記述応答
方式
RTSP 記述内に仮想的なサロゲートの URL を記述しておき、アクセスが来たら最適
MIME ヘッダ内の Language、Cookie 等のフィールド情報に応じて、適切なサロゲー
トへのルーティングを行う
インターネット
(例) stream.com → japanese.stream.com
rtsp://server-n
③ 接続要求
リモート
サイト#n
サロゲート
(surrogate)
Content Modification
クライアントからのリクエストに応じて、メタファイルやレイアウト記述ファイル内の
URL フィールドを最適サロゲートの URL に書き換えて返す
(例) rtsp://stream.com → rtsp://site1.stream.com
④ ストリーミング
URLの書き換え
クライアント
解像度： クライアント単位 (細かい)
7
オーバーレイネットワーク
リクエストルーティング (6)
• 最適サロゲートの推定方法
リモート
サイト#1
CDN #1
推定方法
オリジン
サイト
方式
Proximity Measurement
リモート
サイト#2
クライアントに最も近いサロゲートの推定方法
(1) Active Probing ： ping 等のプローブパケットの利用
CDN #2
(2) Passive Measurement ： クライアントパケットのモニタリング
基準： 遅延、パケットロス、ホップ数、等
オリジン
サイト
関連分野： インターネットの帯域測定技術
Surrogate Feedback
リモート
サイト#2
リモート
サイト#1
管理サーバとサロゲートの情報交換： エージェントを用いた Probing
クライアントから見れば
基準： CPU 負荷、インターフェース負荷、コネクション数、等
CDNはひとつのサイト
関連分野： 負荷分散技術
インターネット
クライアント
Akamai FreeFlow (1)
オリジナルデータの
ミラーリング
(オフライン)
Origin Site
L7 swtich
Akamai FreeFlow (2)
Origin DNS
• Akamai DNS System
Akamai DNS Servers
High-Level DNS Servers (世界中に13台？)
with Akamizer
① ファイル要求
＆応答
za.akamaitech.net
zb.akamaitech.net
…
zr.akamaitech.net
③ DNS検索
監視
② DNS検索
a100.g.akamaitech.net → ?
ak.foo.com
Akamai
Contents
Servers
→ a100.g.akamaitech.net
Low-Level DNS Servers (50以上)
n1g.akamaitech.net
n2g.akamaitech.net
…
n9g.akamaitech.net
rtsp://ak.foo.com/…
Contents Servers (2000以上)
a0000.g.akamaitech.net
a0001.g.akamaitech.net
…
annnn.g.akamaitech.net
④ コンテンツ配信
URL
↓
ARL (Akamai Resource Locator)
クライアント
① URLリライテイング、③ DNSリダイレクション
P2P (1) 基本
(1) 探索・発見
P2P
(peer-to-peer)
(2) 通信
P2Pネットワーク
探索
P2Pネットワーク
通信
発見
Peer A
Peer D
Peer B
Peer A
Peer C
従来：
Peer D
Peer B
検索エンジン
クライアント
Peer C
Webサーバ等
クライアント
探索・発見
通信
8
P2P (2) Napster
(1) 登録＋探索・発見
P2P (3) Gnutella
(2) 通信
管理サーバ
(1) 探索・発見
(2) 通信
管理サーバ
ブロードキャスト
探索・発見
Single point of failure
冗長
P2Pネットワーク
P2Pネットワーク
通信
登録
探索
Peer A
Peer D
Peer B
Peer A
Peer C
Peer D
Peer B
通信
発見
Peer A
Peer B
Peer A
Peer B
Peer C
P2P (4) Plaxton’
Plaxton’s Algorithm
P2P (5) CAN
ファイル名とノードアドレスをハッシュ関数で数値化 … ( ObjectID, NodeID )
Plaxton’s Algorithm の変形、拡張
ノード番号が ObjectID に等しいノードに、そのファイルの保有ノード情報を登録
各ノードは、d 次元空間中の特定の範囲の ObjectID を有するファイルの保有ノード情報を保持
探索・発見： ***8 ⇒ **98 ⇒ *598 ⇒ 4598 の順に探索 (ObjectID = 4598 の場合)
Node 04F8 ’s Routing Table
04F8
*0F8
**08
***0
14F8
*1F8
**18
***1
24F8
*2F8
**28
***2
34F8
*3F8
**38
***3
4598
問合せノード
04F8
ObjectID の d 次元空間
ObjectID = 4598
2
**98
探索
IPアドレス
4
6
5
7
探索
10
4
9
登録 (事前)
7598
・ ObjectID に近い peer に転送
3
3
発見
(4598, 3425)
2BB8
(例) ノード6におけるルーティング：
・ 隣接 peer に限定
8
3425
9098
通信
1
通信
0325
ObjectID
11
問合せ
ノード
11
4598
9
7
発見 (ObjectID, 8)
87CA
Structured P2P
S.Ratnasamy et al: “A Scalable Content-Addressable Network,” SIGCOMM’01.
アプリケーション層マルチキャスト (1)
P2P (6) Chord
Plaxton’s Algorithm の変形、拡張
• スプリッタ
各ノードは、1次元円周上の特定の範囲の ObjectID を有するファイルの保有ノード情報を保持
サーバ
(例) Key (ObjectID) = 46 の探索：
K51～K0
問合せ
ノード
N0
発見 (K46, N13)
N4
Key
Interval
Successor
5 (=4+20)
[5,6)
13
6 (=4+21)
[6,8)
13
(=4+22)
[8,12)
13
12 (=4+23)
[12,20)
13
20 (=4+24)
[20,36)
35
36 (=4+25)
[36,4)
43
8
K1～K4
N50
ObjectID
探索
登録 (事前)
46
N13
K36～K43
K5～K13
N35
K14～K35
ホスト (受信端末)
ユニキャスト
• P2P (Peer-to-Peer)
ユニキャスト
Node 43 のfinger table
通信
Key = 46
N43
スプリッタ
Node 4 のfinger table
ノード数64、NodeID = 0, 4, 13, 35, 43, 50 の場合
K44～K50
6
登録
(事前)
Key
Interval
Successor
44 (=43+20)
[44,45)
50
46 (=43+21)
[46,48)
50
48 (=43+22)
[48,51)
50
(=43+23)
[51,59)
59 (=43+24)
[59,11)
0
11 (=43+25)
[11,43)
13
51
送信者 (S)
0
受信端末
兼 送信端末
I.Stoica et al: “Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications,” SIGCOMM’01.
9
アプリケーション層マルチキャスト (2)
Skype (1)
• P2P 型 VoIP システム
• P2Pマルチキャスト
ストリーム
サーバ
管理
サーバ
- 音質向上 : Global IP Sound (広帯域音声符号化)
ルーティング
テーブル
(2) Peer 選択
Peer
- NAT超え : UDP ⇒ TCP ⇒ HTTP (80) ⇒ HTTPS (443) ⇒ proxy
- 暗号化 : AES (Advanced Encryption Standard, 256 bit)
- SkypeIn / SkypeOut : 黒電話との発着信
(1) 接続要求
ゲートウェイ
(3) 配信
新ノード
Skype ネットワーク
電話網
黒電話
Skype
Client
長所： 簡単、既存ルータの変更不要
短所： 転送トラヒックの増加、経路の準最適性、管理サーバの負荷
検討事項： ノードの追加と削除への対応、動的な経路変更、負荷分散
Skype (2)
Skype (3)
• システムの構成要素
• Global IP Sound
Login Server
広帯域音声 (16/32kHz) ～ 狭帯域音声 (8kHz)
Bootstrap Super Node
Super Node
② ログイン
① 問合せ
③ ユーザ探索
① 問合せ (first time)
Skype Client
④ 通話
http://www.globalipsound.com/
Skype (4)
Super Node
• NAT超え
Super Node
探索
(1) Public ～ Public
通話
Skype Client
(2) Public ～ NAT
(3) NAT ～ NAT
Skype Client
Super Node
Super Node
探索
firewall
通話
Skype Client
UDP Hole Punching
Skype Client
UDP ⇒ TCP ⇒ HTTP (80) ⇒ HTTPS (443) ⇒ proxy
10