スライド 1

第十一講

ネットワークアーキテクチャ

2006年度秋学期 授業日程 （後半）

z

11/14

Internet Protocol version 6

z

11/28

移動体通信技術 （代講 三屋光史朗）

z

12/05

次世代トランスポート層技術 （代講 西田佳史）

z

12/12

コネクションレス型の通信技術とサービス

z

12/19

P2P通信技術

z

01/09

授業総括

コネクションレス型通信技術の特徴

z

パケットが途中でロストしても気にしない

z

信頼性は非保証

z

確認応答（ACK)は利用しない

z

再送制御を行わない

z

一定ビットレートでの通信が可能

z

輻輳制御は非サポート

z

ネットワークの混雑状況は気にしない

※前回説明したDCCPは輻輳制御をサポートする方向

コネクションレス型の通信形態

z

1対1通信（片方向 or 双方向）

z

1対多通信（ブロードキャスト or マルチキャスト）

A B A B A B C D A B C D E E 流布範囲にいる全ノード 流布範囲にいる対象ノードのみ

コネクションレス型通信を利用するサービス例

z

パケット損失率や伝播遅延の変動が少ない安定

した通信路を想定

z

NFS, TFTP, SNMP

z

即時性、実時間性重視

z

DNS, Real Time Audio / Video

z

一対多通信

本日の講義内容

コネクションレス型通信と関連技術

z

リアルタイム通信を支える技術

z

Real-time Transport Protocol（RTP）

z

RTP Control Protocol（RTCP）

z

双方向型通信を支える技術

z

Session Initiation Protocol（SIP）

z

Session Description Protocol（SDP）

z

マルチキャストを実現する技術

z

マルチキャストグループ管理プロトコル

リアルタイム通信を支える技術

Real-time Transport Protocol（RTP）

RTP Control Protocol（RTCP）

コネクションレス型通信を利用する場合の注意点①

z

注意点①

z

順序違いにパケットが届いても検知出来ない！

z

アプリケーションは異なる順序でデータを処理する

z

受信者は送信者の想定したデータを再生できない

ただ送るだけ 1,2,3の順に送信 ただ受け取るだけ 2,3,1の順に処理 3 2 1 1 3 2

受信者側で正しいパケット順序を知るための仕組みが必要

ÎReal-time Transport Protocolの機能

コネクションレス型通信を利用する場合の注意点②

z

注意点②

z

輻輳が起こっても送受信者ともに検知出来ない

z

送受信者間のパケットロスが解消されない

z

輻輳はさらなる輻輳を引き起こす

輻輳発生

ただ送るだけ ただ受け取るだけ

送受信側で輻輳状態を知るための仕組みが必要

ÎRTP Control Protocolの機能

RTP and RTCP

z

RFC1889、1890で標準化

z

主にReal Time Audio / Video Applicationのデータ

通信に利用されるプロトコル

z

RTP, RTCPを利用するアプリケーション

z

VoIP（Voice over IP）

TCPでは無くなぜにRTP？

z

RTPはUDPの上位プロトコルとして定義されている

z

TCPはリアルタイム通信では不適合

z 再送・輻輳制御により、相手にデータが確実に届く事を保証 z セッション管理を行った上でデータ送信するため、UDPに比べ 送信するまでに時間がかかってしまう z 遅れて届いたデータはリアルタイム通信では意味をなさない場 合が多い z 電話で一瞬で音が飛んでも会話は継続可能

RTPの機能概要

z

ストリーミング用の標準プロトコル

z

様々なリアルタイムデータに共通する情報を記述

z

シーケンス番号

z

タイムスタンプ

z

送信者識別子

z

データ圧縮方法に依存する情報は拡張ヘッダに記述

z

データ圧縮方法毎にRFCで定義されている

z

ペイロードタイプ

でデータ圧縮方法を規定

RTPの機能

z

受信時にフレームの順序を整頓

z シーケンス番号に応じて受信フレームを並び替える z インターネットでは送信した順序で受信される保証は無い z

再生時に、送信側で付与された時刻を元に行う

z リアルタイムデータを再生するために相対的な時刻をフレーム に付与 z インターネットでは送信した間隔で受信される保証は無い

RTCPの機能概要

z

RTPだけでも

受信者だけは

通信状況を把握できるが…

IP

UDP

RTP

Payload

z

RTP＋RTCPにより

送信者も通信状況を把握できる

！

！

RTCPは基本的にセッションやアプリケーションの情報を伝達するために利用される

IP

UDP

RTCP（

送信データに関連する情報等

）

IP

UDP

RTCP（

RTPヘッダを基にした統計情報等

）

？

_！

RTCPメッセージタイプ

SR （Sender Report） RTPセッションにおける送信者の状態通知 に使用されるRTCPメッセージ RR （Receiver Report） RTPセッションにおける送信者以外の参加 者の状態通知に使用されるRTCPメッセージ SDES （Source Description） セッション参加者の識別や、電子メールアド レス、電話番号といった捕捉情報を提供する RTCPメッセージ BYE セッションからの離脱を通知するRTCPメッ セージ APP （Application-Defined） RTCP規定外アプリケーション固有の制御情 報を通知するRTCPメッセージ

リアルタイム通信を支える技術 まとめ

z

RTP（Real Time Protocol）

z 多くのストリーミングアプリケーションが利用する情報は必ず記述 z アプリケーション依存の情報は拡張ヘッダに記述 z 受信アプリからセッション・ネットワーク状況がわかる z RTCP（RTP Control Protocol） z 送受信側でセッション情報、ネットワーク情報を交換するために利用 z アプリケーションがセッション情報・ネットワーク情報を知ることで z アプリケーション主体の輻輳制御、フロー制御の目安となる

双方向通信を支える技術

SIP（Session Initiation Protocol）

SDP（Session Description Protocol）

コネクションレス型通信で

双方向通信を確立するまで

ポート番号、アプリケーション情報 手順１：アプリケーションで必要な設定を相互に交換する （通信ポート番号やデータ圧縮技術など） 手順２：送受信者同時に片方向通信を開始する（片方向×２＝双方向）

双方向通信は難しい？

z

双方向通信の準備は大変

z 利用するポート番号を決める z 利用するアプリケーションを決める z 利用するデータ圧縮方法を決める z 送受信者が相互に、同時に通信開始する必要がある z

どのような通信を行うか定義できたら嬉しい⇒SDP

z ポート番号、アプリケーション、圧縮方法等の交渉機能 z

呼制御ができると嬉しい⇒SIP

z 呼制御が出来れば電話のようなコミュニケーションがインター ネット上で用意に実現出来るようになる ① ②

SIP （Session Initiation Protocol）

z

呼シグナリングおよび制御プロトコル

z

単純なテキストプロトコル

z

セッションの開始や終了を規定

z

双方が対等な関係を持つ通信の開始時に利用

SIPコンポーネント

z ユーザエージェント（UA） z

SIPサーバ

z SIPプロキシサーバ z リダイレクトサーバ z レジストラ z

ロケーションサーバ

z DNS、LDAPなどのデータ ベース UAとして想定される機器 （他にも情報家電など）

プロキシサーバの動作概要

（着信まで）

①Bobに電話したい Alice ②Bobのアドレスは？ ③xxx.xxx.xxx.xxxです ②Bobへ中継 プロキシサーバ RING R ING !! ロケーションサーバ Bob プロキシサーバはUAや別のプロキシサーバから SIPリクエストを受け取り、他の宛先に転送する

プロキシサーバの動作概要

（セッション確立まで）

②Response Hello!! ③セッション確立 ロケーションサーバ ①Response プロキシサーバ プロキシサーバはUAや別のプロキシサーバから SIPリクエストを受け取り、他の宛先に転送する

リダイレクトサーバの動作概要

（着信まで）

①Bobに電話したい Bob ②Bobのアドレスは？ ③xxx.xxx.xxx.xxxです RING R ING !! ④Bobに電話 ④xxx.xxx.xxx.xxx です リダイレクトサーバ ロケーションサーバ リダイレクトサーバはUAやプロキシサーバからの リクエストを受け取りリダイレクトレスポンスを返す

リダイレクトサーバの動作概要

（セッション確立まで）

Hello!! リダイレクトサーバ ロケーションサーバ ②セッション 確立 ①Response リダイレクトサーバはUAやプロキシサーバからの リクエストを受け取りリダイレクトレスポンスを返す

レジストラの動作概要

①僕のアドレスは xxx.xxx.xxx.xxxです。 ②アドレスを登録 レジストラ ロケーションサーバ レジストラはSIPの登録リクエストを受け取り、ロケー ションサーバに登録されているUAの情報を更新する

SIP URI

（リクエストメッセージのヘッダ例）

INVITE

sip:[email protected]

SIP/2.0

From : Hanako <

sip:[email protected]

>

To : Taro <

sip:[email protected]

>

Call-ID : [email protected]

Subject : test

Content-Type : application/sdp

（レスポンスメッセージのヘッダ例）

SIP/2.0 100 Trying

From : Hanako <

sip:[email protected]

>

To : Taro <

sip:[email protected]

>

SIP URI

z

SIP URI：SIPの通信リソースの識別子

z

URI：Uniform Resource Identifier

z

URIは世界中のリソースを一意に識別するもの

z

URL（Uniform Resource Location）もURIの一部

z

SIPのURIは「sip:」「sips:」から始まる

sip: [email protected]

SDP(Session Description Protocol)

z

SIPでは通信内容の定義を行うために利用

z SDPはINVITEメッセージに格納される z SDPを利用してこれから確立する通信内容の交渉を行う z

SDPにより表現される情報

z セッション記述（セッション名、セッション生成者） z メディア記述（データ受信・再生に必要な情報） z 時間記述（セッションの有効期間） z

SDPタグを用いて記述

（おまけ）SIPとモビリティ

SIP URIとIPアドレスは独立であり、組合せを自由自在に変更することが出来る 職場の電話 自宅の電話 _{1. REGISTER} 移動 職場の電話の IPアドレスとSIP URIiの対応付け 2. UPDATE 3. Response 4. 200 OK 1. REGISTER _{職場の電話の} IPアドレスとSIP URIを非対応に 2. UPDATE 3. Response 4. 200 OK 1. REGISTER 2. UPDATE _{自宅の電話の} IPアドレスとSIP URIiの対応付け 3. Response 4. 200 OK

双方向通信を支える技術 まとめ

z

双方向通信を実現するための2つの技術

z SIP（Session Initiation Protocol）

z 呼制御をはじめ、様々なシグナリングを実現する仕組み

z 呼制御を利用することで双方向に同時セッション確立を実現

z SDP（Session Description Protocol）

z セッション確立前に通信内容を定義する仕組み

マルチキャストを実現する技術

マルチキャストグループ管理プロトコル

マルチキャストルーティングプロトコル

IPマルチキャスト概略①

同一パケット×4 40Mbpsの負荷 10Mbps 10Mbps 10Mbps 10Mbps Source

ユニキャストの場合

規模性を確保するためには回線の利用効率の高い配信技術が必要ÎIPマルチキャスト

IPマルチキャスト概略②

Source 同一パケット×１ 10Mbpsの負荷 10Mbps 10Mbps 10Mbps 10Mbps

マルチキャストの場合

IPマルチキャストを利用することで各リンクへの負荷を効果的に減少可能

IPマルチキャスト技術の問題点

Source 10Mbps 10Mbps 10Mbps 10Mbps マルチキャスト対応ルータに求められる機能 ・マルチキャストグループ管理 ・マルチキャストルーティング IPマルチキャストを利用するにはルータのマルチキャストサポートが必要不可欠

IPマルチキャスト普及の兆し①

z

IPTVフォーラム

z 2006年10/23 総務省が放送番組などのIP配信に関する技術 やルールを検討するために発足 z 次世代ブロードバンドコンテンツ流通フォーラムの中で発足 z メンバー z 主査：安田泰彦東大名誉教授 z 構成員：村井純慶大教授 z メーカー：シャープ，ソニー，松下など z 通信事業者：KDDI，NTTなど z TV局：民法，NHKなど z 総務省

IPマルチキャスト普及の兆し②

z

IPTVでのIPマルチキャストの利用が決定

z 今後IPマルチキャストの普及活動が進められる z IPマルチキャストのサポート体制の強化 z IPマルチキャストを利用するサービスの普及 参考：『IPTVフォーラムの発足』http://www.soumu.go.jp/s-news/2006/061023_2.html

マルチキャストを実現するための3要素

z

マルチキャストアドレス

z

マルチキャストグループ管理プロトコル

マルチキャストアドレス

z

IPマルチキャストグループの識別子

z

IPv4におけるマルチキャストアドレス

z

ClassD

（224.0.0.0 – 239.255.255.255）

z

IPv6におけるマルチキャストアドレス

z

_FF00::/8

z

※IPマルチキャストグループ＝

マルチキャストパケットの送信対象グループ

マルチキャストグループ管理プロトコル

z

マルチキャストグループの管理

z IGMP（Internet Group Management Protocol） for IPv4 z MLD（Multicast Listener Discovery Protocol） for IPv6

z

主な機能（IGMP）

z グループへの参加管理

z IGMP Report

z グループへの参加継続確認

z IGMP Query / IGMP Report

z グループからの脱退管理

グループへの参加

z

ホストからルータへのIGMP Report送信

Report : グループXに参加 E0 E2 E1 _E0 E2 E1

グループへの参加継続確認

z ルータは定期的にIGMP Queryを送信 z ホストがルータへの返答タイマ設定

z タイマ切れホスト1台がルータへIGMP Report送信

z 誰も返答しない = 該当マルチキャストグループへの参加者無し

IGMP Query IGMP Report

タイマ 破棄

グループからの脱退（IGMPv3）

z

ホストからルータへのIGMP Report送信

IGMP Leave : グループXを脱退 E0 E2 E1 _E0 E2 E1

マルチキャストルーティング

z

マルチキャストツリーを構築する様々なプロトコル

z IGMPまたはMLDで管理されるグループ情報を利用する

Source

マルチキャストツリー保守の手法

z

シンプルな実現手法

z Flooding z 非効率な手法、不必要なパケット転送が多い z Spanning Tree z IEEE802.1dで定義される手法、不必要なパケット転送が多い z

送信元ベースの保守手法

z Reverse Path Forwarding

z ルータから送信元までの最短経路を基準にパケットを転送

z

共有ツリーベースの保守手法

z グループの全メンバーが共有する１つの配信ツリーを構築 z 送信元ベースの方法に比べ、規模性の面で有利

マルチキャストツリーの保守手法

Pruning（枝刈り）とGrafting（接ぎ木）

Receiver Pruning Receiver

①

②

Leave

マルチキャストツリーの保守手法

Pruning（枝刈り）とGrafting（接ぎ木）

Receiver Grafting JOIN Receiver

①

②

マルチキャストルーティングプロトコル色々

z PIM-DM（Protocol-independent Multicast Dense Mode）

z 狭いネットワーク範囲かつ受信者が多い場合に適している z Flooding方式

z

DVMRP（Distance Vector Multicast Routing Protocol）

z 距離ベクトル型のマルチキャストルーティングプロトコル

z Reverse Path Forwarding 方式

z PIM-SM（Protocol-independent Multicast Sparse Mode）

z 広いネットワーク範囲に配信する場合に適している z 共有ツリー方式（ランデブーポイントを利用）

PIM-DM①

Source

1st Stage:

Flooding

PIM-DM②

2nd Stage:

Pruning

Source

Pruning Message

PIM-DM③

2nd Stage:

Pruning

Source

Pruning Message

DVMRP①

Step.1 Flooding

Source ①

DVMRP②

Step.1 Flooding

Source ① ② ②

DVMRP③

Step.1 Flooding

Source ① ② ② ③ ③ ③ ③

DVMRP④

Step.1 Flooding

Source ① ② ② ③ ③ ③ ③ ④ ④ ④ ④

DVMRP⑤

Source

Step.2 Sourceまでの

DVMRP - Pruning - ①

Receiver

Pruning Pruning

DVMRP - Pruning - ②

Receiver

Pruning Pruning

DVMRP - Grafting - ①

Receiver

Grafting Grafting

DVMRP - Grafting - ②

Receiver

Grafting Grafting

マルチキャストを実現する技術 まとめ

z

マルチキャストを実現する要素技術

z Internet Protocol version 4, 6

z マルチキャストアドレスの定義

z IGMP version 1,2,3 , MLD version 1,2

z マルチキャストグループ管理

z PIM, DVMRP, MOSPF, MBGP, etc

z マルチキャストルーティングプロトコル

ƒ IGP：PIM, DVMRP, MOSPF

ƒ EGP：MBGP