Comments
Description
Transcript
SIP - 電子情報通信学会
NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 インタラクティブマルチメディアを支える技術動向 −ＱｏＳを中心に− ２００３年１０月１０日 ＮＴＴネットワークサービスシステム研究所 森田 直孝 NSLAB© NTT 2003 目次 NTT秘(財産的情報) 1. 2. 3. 4. 5. ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 SIPに関する技術動向 ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞﾝｸﾞとﾌﾟﾚｾﾞﾝｽに関する技術動向 NAT/FW通過制御に関する技術動向 新しいQoS実現方式の提案(PPS方式) Q&A NSLAB© NTT 2003 2 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 １．SIPに関する技術動向 NSLAB© NTT 2003 SIPを中心とするIETFのワーキンググループ NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 ﾌﾟﾚｾﾞﾝｽ/ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞ機能(Application Area) 【SIMPLE: 【IMPP: 【IMPP: Instant Instant Messaging Messaging 【XMPP: 【XMPP: Extensible Extensible 【SIMPLE: SIP SIP for for Instant Instant Messaging and Messaging and Presence Presence Protocol】 Protocol】 Messaging and and Presence Presence Messaging and and Presence Presence Leveraging ﾌﾟﾚｾﾞﾝｽ/ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞの共 Protocol】 Protocol】 Leveraging Extensions】 Extensions】 •• ﾌﾟﾚｾﾞﾝｽ/ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞの共 •• SIPﾒｯｾｰｼﾞの拡張によるﾌﾟﾚ •• Jabberをｺｱﾌﾟﾛﾄｺﾙとする 通ﾃﾞｰﾀﾌｫｰﾏｯﾄを規定 Jabberをｺｱﾌﾟﾛﾄｺﾙとする SIPﾒｯｾｰｼﾞの拡張によるﾌﾟﾚ 通ﾃﾞｰﾀﾌｫｰﾏｯﾄを規定 ｾﾞﾝｽ/ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞ機能 •• 2002/11 XMLﾍﾞｰｽのIM 2002/11 終結 終結 XMLﾍﾞｰｽのIM ｾﾞﾝｽ/ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞ機能 •• 2002/11 2002/11 WG設立 WG設立 セッション制御機能 【SIP: 【SIPPING: 【SIP: Session Session Initiation Initiation 【SIPPING: Session Session Protocol】 Initiation Protocol】 Initiation Proposal Proposal •• SIPプロトコルの改良 Investigation】 SIPプロトコルの改良 Investigation】 •• 1999/11 •• 新機能の要求条件を明確化 1999/11 WG設立 WG設立 SIP 新機能の要求条件を明確化 •• 2001/8 2001/8 WG設立 WG設立 メディア転送/制御機能 【MMUSIC: 【AVT: 【MMUSIC: Multiparty Multiparty 【AVT: Audio/Video Audio/Video Multimedia Transport】 Multimedia Session Session Transport】 Control】 •• 音声や画像情報の転送ﾌﾟﾛﾄｺ Control】 音声や画像情報の転送ﾌﾟﾛﾄｺ ﾙ(RTP)を検討 ••ﾒﾃﾞｨｱ属性記述 ﾙ(RTP)を検討 ﾒﾃﾞｨｱ属性記述 (SDP/SDPng)、ｽﾄﾘｰﾐﾝｸﾞ制 (SDP/SDPng)、ｽﾄﾘｰﾐﾝｸﾞ制 御ﾌﾟﾛﾄｺﾙ(RTSP) 御ﾌﾟﾛﾄｺﾙ(RTSP) を検討中 を検討中 【IEPREP: 【IEPREP: Internet Internet Emergency Emergency Preparedness】 Preparedness】 •• 災害時の通信方法 災害時の通信方法 【XCON: 【XCON: Centralized Centralized Conferencing】 Conferencing】 •• 明確なﾒﾝﾊﾞｰｼｯﾌﾟ管理の 明確なﾒﾝﾊﾞｰｼｯﾌﾟ管理の ある会議サービス ある会議サービス ｱﾄﾞﾚｼﾝｸﾞ/ﾙｰﾁﾝｸﾞ制御機能 【ENUM: 【ENUM: Telephone Telephone Number Number Mapping】 Mapping】 •• E.164→IPアドレスへの番 E.164→IPアドレスへの番 号解決 号解決 【IPTEL: 【IPTEL: IP IP Telephony】 Telephony】 •• ｻｰﾋﾞｽｶｽﾀﾏｲｽﾞ記述 ｻｰﾋﾞｽｶｽﾀﾏｲｽﾞ記述 (CPL) (CPL) •• GWへのﾙｰﾁﾝｸﾞﾌﾟﾛﾄｺﾙ GWへのﾙｰﾁﾝｸﾞﾌﾟﾛﾄｺﾙ (TRIP) (TRIP) •• 2003/11 2003/11 終結予定 終結予定 転送系の制御方式 【MIDCOM: 【MIDCOM: Middlebox Middlebox Communication】 Communication】 •• NAT/FW機能を実現する NAT/FW機能を実現する 装置（middlebox）を制御 装置（middlebox）を制御 するプロトコルを検討 するプロトコルを検討 •• 2001/12 2001/12 WG設立 WG設立 【NSIS: 【NSIS: Next Next Steps Steps in in Signaling】 Signaling】 •• QoS, QoS, NAT/FW制御を目 NAT/FW制御を目 的としたRSVP型の新信 的としたRSVP型の新信 号方式を検討 号方式を検討 NSLAB© NTT 2003 4 SIP標準化動向 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 SIP基本部について、RFC2543bis04までと、その後約半年で改版されたRFC3261では、大幅に変更あり。主な変更点は、 SIP基本部について、RFC2543bis04までと、その後約半年で改版されたRFC3261では、大幅に変更あり。主な変更点は、 セキュリティ強化、および、複数サーバ環境を考慮したルーチング処理である。 セキュリティ強化、および、複数サーバ環境を考慮したルーチング処理である。 2000 2001 SIP基本部 99.2 RFC2543制定 2002 7月 △ 10月 △ bis04 bis05 構成 変更 バグ修正完 3月 △ bis09 2003 6月 △ 機能追加分の不明確点 議論中 RFC3261 6月 △ RFC3264, 3266 (SDPのoffer/answer, SDP IPv6 SIP拡張部 電話網 相互接続 電話系付加 サービス 6月 △ 12月 △ RFC2848 (PINT) RFC3204 (ISUP,QSIG用 メディアタイプ) 10月 △ RFC2976(INFO) Presence, IMサービス対応 6月 9月 △ △ RFC3262 (1xxレスポンスの 送達確認) ヘッダ名前空間にプライベイト(Pxxx)の導入 6月 △ RFC3265 (非同期イベント通知要求機能の 抽象クラス) 12月 △ セキュリティの強化 ・SIPS URL ・サーバはTLS対応必須化 ・S/C相互認証機能追加 ・基本認証廃止 ・S/MIMEによるボディの暗号化 ルーチング処理変更 ・複数サーバ環境での多段接続 サーバにおけるサービス起動 RFC3372,3398 (SIP-T) (SIP-ISUP連携) 11月 △ RFC3324,3325 (発ID通知・非通知制御、網内流通ID) 各サービス対応のイベント通知要求機 能の仕様はパッケージとして規定予定 (例) ・Presence ・Conference State ・Dialog State ・メッセージあり通知 NSLAB© NTT 2003 5 SIP仕様の差分-1 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 ●主な機能差分 1. セキュリティ関連規定の見直し • セキュアなトランスポートTLSの使用を指定するアドレス規定“SIPS”URIの追加サポート • サーバにTLSを必須化 • Message bodyの暗号化方式を、PGPからS/MIMEへ変更 • セキュリティの弱い基本認証の廃止 2. トランスポートの見直し ・ユーザにTCPを必須化（長いメッセージへの対応） 3. DNS手順の拡張 ・リソースレコードSRV/NAPTRへの対応 SRV(サーバ選択)型のみから、SRV,NAPTR(名前付け権限ポインタ)への拡張 NSLAB© NTT 2003 6 SIP仕様の差分-2 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 ●主な手順変更 1. 呼設定中の解放手順等、準正常手順の明確化 2. offer-answerモデルによるSDP交換手順の明確化 別draft化した後、RFC3264として規定 3. Max-Forwardsの必須化によるループ検出手順の簡素化 転送サービスの考慮漏れに対応 4. レコードルート手順の簡素化 ルーチング情報設定方法の変更（Strict routingとloose routingを規定） 5. via branchの必須化によるトランザクション識別の簡素化 6. tagの必須化によるダイアログ識別の簡素化 NSLAB© NTT 2003 7 SIPルーチング NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 ・ｲﾆｼｬﾙﾘｸｴｽﾄ(例:INVITE)と、後続のﾘｸｴｽﾄ(例:BYE)が同じ経路を用いるとは限らない。 ・ｲﾆｼｬﾙﾘｸｴｽﾄ(例:INVITE)と、後続のﾘｸｴｽﾄ(例:BYE)が同じ経路を用いるとは限らない。 ⇒Record-Route,Routeヘッダの設定により、同じ経路使用可。 ⇒Record-Route,Routeヘッダの設定により、同じ経路使用可。 ■Record-Route設定なし INVITE sip:[email protected] サーバ P1 ｲﾆｼｬﾙ・ﾘｸｴｽﾄ ﾚｽﾎﾟﾝｽ サーバ P2 後続ﾘｸｴｽﾄ ﾚｽﾎﾟﾝｽ BYE sip:[email protected] User A User B ■Record-Route(=RR)設定あり INVITE UserB User A サーバ P1 BYE UserB Route: P1,P2 INVITE UserB RR: P1 サーバ P2 BYE UserB Route: P2 INVITE UserB RR: P2 RR: P1 BYE UserB User B Record-Route: Proxyがinitialﾘｸｴｽﾄに挿入 UAが参照してRoute設定。 Route: UAがsubsequentﾘｸｴｽﾄに挿入 Proxyが参照してルーチング。 NSLAB© NTT 2003 8 SIPルーチング処理の変更 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 Looseルーチングの導入 Looseルーチングの導入 着アドレスが設定されるフィールド(Request-URI)について、Proxyで書き換えを行う場合があった。そ 着アドレスが設定されるフィールド(Request-URI)について、Proxyで書き換えを行う場合があった。そ のため、着アドレスがサービスを示す場合、サーバでサービス起動不可になってしまう。 のため、着アドレスがサービスを示す場合、サーバでサービス起動不可になってしまう。 ⇒Request-URI書き換えず、Routeヘッダを用いてルーチング。 ⇒Request-URI書き換えず、Routeヘッダを用いてルーチング。 ■Strictルーチング INVITE P1 Route:P2,UserB サーバ P1 INVITE P2 Route:UserBサーバ INVITE UserB P2 User A User B(0120) ■Looseルーチング INVITE UserB Route: P1:lr,P2:lr User A サーバ P1 INVITE UserB Route:P2:lr サーバ P2 INVITE UserB User B(0120) NSLAB© NTT 2003 9 SIP Asserted IDの概要(RFC3325) NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 •• 信頼関係が成立する範囲内で、ネットワークの保証したユーザIDを転送する機能。 信頼関係が成立する範囲内で、ネットワークの保証したユーザIDを転送する機能。 •• 信頼できないサーバや端末に対しては、ユーザIDは削除して転送される。 信頼できないサーバや端末に対しては、ユーザIDは削除して転送される。 •• ID自体は暗号化されていないため、信頼できる範囲での利用が前提。 ID自体は暗号化されていないため、信頼できる範囲での利用が前提。 発ID通知/非通知制御のための拡張ヘッダ(P-Asserted-Identity)で ネットワークが保証するＩＤを転送する。 ユーザからの最初のメッセージに対し、 プロキシは認証を要求することで、 ユーザの正当性を確認する。 SIP proxy #1 INVITE* (IDあり) SIP proxy #2 INVITE Trusted domain ユーザは、untrusted domainに対し IDを転送するか否かをPrivacyヘッダで指定できる。 好みのIDをP-Preferred-Identityヘッダで 指定することもできる。 INVITE (IDなし) INVITE (IDあり) SIP proxy #3 Untrusted domain INVITE (IDなし) INVITE*の例 INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP useragent.cisco.com;branch=z9hG4bK-124 Via: SIP/2.0/TCP proxy.cisco.com;branch=z9hG4bK-abc To: <sip:[email protected]> From: "Anonymous" <sip:[email protected]>;tag=9802748 ∼ P-Asserted-Identity: "Cullen Jennings" <sip:[email protected]> P-Asserted-Identity: tel:+14085264000 Privacy: id NSLAB© NTT 2003 10 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 2.ｲﾝｽﾀﾝﾄﾒｯｾｰｼﾞﾝｸﾞとﾌﾟﾚｾﾞﾝｽに関する技術動向 NSLAB© NTT 2003 IM+プレゼンス概要 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 プレゼンスサービスとは、通信相手の存在や状態を、事前に通知する機能であり、通信相手の状況 プレゼンスサービスとは、通信相手の存在や状態を、事前に通知する機能であり、通信相手の状況 に応じた通信手段の選択や、通信の開始が可能となる。一般に、このプレゼンスサービスと共に、 に応じた通信手段の選択や、通信の開始が可能となる。一般に、このプレゼンスサービスと共に、 IM(instant IM(instant messaging)サービスが提供される。 messaging)サービスが提供される。 見せる人Z (Presentity Z) ユーザX：着席 ユーザX：着席 ユーザY：通信中 ユーザY：通信中 プレゼンス ユーザZ：外出中 ユーザZ：外出中 等 等 見せる人Y (Presentity Y) サーバ 見る人Ａ (Watcher A) ①状態開示要求 ②状態開示要求 ／承認 ④状態通知 ③状態登録 Xさんは， 着席中です． •見る人の側では、複数の見せ る人の情報を集めて、お友達 リストを作成することが可能 •Watcher単位に多様な設定が 可能（通知拒否等） ①状態開示 要求 見る人B (Watcher B) ×拒否 私は今，着席 中です． 見せる人X (Presentity X) ④状態通知 Bさんには 通知しない． Xさんは今どうし ているかな？ 【状態例】 ･着席中 （キーボードがアクティブ） ･離籍中 （スクリーンセイバと連動等） ･通信中 ･外出中 （ユーザ設定） 等 NSLAB© NTT 2003 12 IMPP WG 検討状況 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 ••当初は、Instant 当初は、InstantMessagingとPresenceのための標準プロトコル仕様を追求していたが、 MessagingとPresenceのための標準プロトコル仕様を追求していたが、 合意に至らなかった。(SIMPLE, 合意に至らなかった。(SIMPLE,APEX, APEX,PRIMの３方式) PRIMの３方式) ••最終的には、独立なプロトコル間を相互接続するための論理的な共通仕様を策定した。 最終的には、独立なプロトコル間を相互接続するための論理的な共通仕様を策定した。 情報の書式 日付・時刻の表記：RFC3339 プレゼンス情報：PIDF(draft) メッセージ：MSGFMT(draft)...WGLC済み SIMPLE 論理的仕様 具体的仕様 （各プロトコルで設定） APEX ⇔ CPIM XMPP ⇔ CPI M ⇔ CPIM CP IM モデル：CPIM (draft) 用語：RFC2778 要求条件：RFC2779 PR IM SIMPLE ⇔ CPIM XMPP APEX APEX PRIM PRIM NSLAB© NTT 2003 13 SIP共通のイベント通知方式(RFC3265より) NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 • SIPが利用する状態変化通知手順を、Event Notificationとして汎用に規定。 • この手順に従って、プレゼンス等の具体的通知手順を規定する。 Subscriber メンバに加入 Event template package イベントの周辺情報 watcher information Notifier (=presence agent相当) Event package 通知対象となるイベント user presence SUBSCRIBE/200 OK NOTIFY/200 OK NOTIFY/200 OK 直前の加入期限が 切れる前に再度加入 加入時点の状態を 直ちに通知 状態変化 状態変化に応じて 通知 SUBSCRIBE/200 OK NOTIFY/200 OK NSLAB© NTT 2003 14 SIMPLE WG検討状況 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 規定済みの基本機能に加え、プレゼンスデータの操作手順や、交換されるメッセージの集約、新たな 規定済みの基本機能に加え、プレゼンスデータの操作手順や、交換されるメッセージの集約、新たな 登録メソッドであるPUBLISHなど、標準化範囲の拡大や手順の効率化を検討中。 登録メソッドであるPUBLISHなど、標準化範囲の拡大や手順の効率化を検討中。 ○Event(プレゼンス等)のリスト化による制御 端末（携帯等）の処理能力を考慮しWatcherServer間のメッセージ送受信数の削減 ○データ操作 ﾌﾟﾚｾﾞﾝｽﾘｽﾄなどのデータ の参照・編集動作規定 プレゼンス ①状態開示要求 サーバ 見る人Ａ (Watcher A) ④状態通知 [承諾] ○通知情報書式 CPIM(Common Profile for Instant Messaging)による、プレゼン スとメッセージの書式規定 ○通知情報の絞込み Watcherの都合に合わせた 、通知 情報のフィルタリング機能 ○状態開示判断時の情報 状態開示の承認に対する許 可の情報を含む、Watcher情 報とその書式の規定 ②状態開示要求 ／承認 ③状態登録 ④状態通知 [拒否] 見せる人X (Presentity X) ○複数端末からの状態登録 複数端末同時使用を考慮したプ レゼンス状態の登録。(PUBLISH) ①状態開示 要求 見る人B (Watcher B) ：基本機能決定 ：ﾒｿｯﾄﾞ決定・書式検討中 NSLAB© NTT 2003 15 SIPによるインスタントメッセージング NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 IM IM (Instant (Instant Messaging)の2つのモード(pagerモード、sessionモード)のうち、 Messaging)の2つのモード(pagerモード、sessionモード)のうち、 Pagerモードについての検討が終了。sessionモードを今後検討。 Pagerモードについての検討が終了。sessionモードを今後検討。 ■pagerモード ■sessionモード SIPの拡張であるMESSAGEメソッドを用いて メッセージを送信。一連のメッセージに関連なし。 通常のSIPメッセージと転送ルートを共有するため 輻輳制御等の注意が必要。 SIPのINVITE,BYEを用いて、セッション開始・終了を 識別。その間、media streamとしてメッセージを送信。 一連のメッセージの関連付け可。 SIP Proxy MESSAGE body: text or MSGFMT SIP Proxy MESSAGE INVITE INVITE message(ex. text) RFC3428にてMESSAGEメソッドを規定（pagerモードのみ） NSLAB© NTT 2003 16 XMPP NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 XMLの交換により、インスタントメッセージとプレゼンス機能を実現する。 XMLの交換により、インスタントメッセージとプレゼンス機能を実現する。 TCP上のXMLストリームにより、XMLスタンザ(メッセージ)を交換する。 TCP上のXMLストリームにより、XMLスタンザ(メッセージ)を交換する。 Gateway XMPP server XMPP server XMPP XMPP XMPP AからBへのメッセージ例 <?xml version='1.0'?> <stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> <message from='[email protected]' to='[email protected]' xml:lang='en'> <body>Art thou not Romeo, and a Montague?</body> </message> SIP/ SIMPLE XMPP BからAへのメッセージ例 <?xml version='1.0'?> <stream:stream from='example.com' id='id_123456789' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'> ... authentication ... <message from='[email protected]' to='[email protected]' xml:lang='en'> <body>Neither, fair saint, if either thee dislike.</body> </message> </stream:stream> </stream:stream> NSLAB© NTT 2003 17 XCON: Centralized Conferencing NTT秘(財産的情報) • • • ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 2003年7月にBoFを開催。今後WG化の予定。 集中管理型の会議サービスに必要なプロトコルの検討。 SIPを例題とする汎用な規定を目指す。 – A mechanism for membership and authorization control – A mechanism to manipulate and describe media "layout" or "topology" for multiple media types (audio, video, text) – A mechanism for notification of conference related events/changes (for example a roster) – A basic floor control protocol – Peer-to-peer cascading of conferences (one conference is a participant in another and vice versa) • • Loosely Coupled Conference: A loosely coupled conference is a conference without coordinated signaling relationships amongst participants. Loosely coupled conferences frequently use multicast for distribution of conference memberships. Tightly Coupled Conference: A tightly coupled conference is a conference in which a single user agent, referred to as a focus, maintains a dialog with each participant. The focus plays the role of the centralized manager of the conference, and is addressed by a conference URI. NSLAB© NTT 2003 18 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 3. NAT/FW通過制御に関する技術動向 NSLAB© NTT 2003 TCP/IPとUDP/IP NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 TCP/IPあるいはUDP/IPでは、５タプルでフローを識別する。 TCP/IPあるいはUDP/IPでは、５タプルでフローを識別する。 （送信元IPアドレス、宛先IPアドレス、送信元ポート番号、宛先ポート番号、プロトコル番号） （送信元IPアドレス、宛先IPアドレス、送信元ポート番号、宛先ポート番号、プロトコル番号） 0 4 バージョン 8 ヘッダ長 16 31(ビット) パケット長 サービスタイプ 識別子 生存時間 0 バージョン ヘッダチェックサム （20バイト） フラグメントオフセット フラグ ヘッダチェックサム プロトコル番号 送信元IPアドレス 宛先IPアドレス 宛先IPアドレス 宛先ポート番号 シーケンス番号 TCPヘッダ 確認応答番号 予約 生存時間 パケット長 サービスタイプ 識別子 IPヘッダ 31(ビット) 送信元IPアドレス 送信元ポート番号 Data Offset ヘッダ長 フラグメントオフセット フラグ プロトコル番号 16 コード ビット （20バイト） （20バイト） 送信元ポート 宛先ポート ＵＤPヘッダ パケット長 チェックサム （8バイト） データ ウィンドウサイズ 緊急ポインタ チェックサム IPヘッダ データ TCPヘッダフォーマット ＊IPアドレスは３２ビットなので０∼約４２億まで表現できる ＊ポート番号は１６ビットなので０∼６５５３９まで表現できる UDPヘッダフォーマット NSLAB© NTT 2003 20 ＩＰアドレスとポート番号による通信の識別 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 クライアント サーバー httpd1 １７２．２０．１００．３４ （８０） httpd2 （８０） httpd3 １７２．２０．１００．１０ （８０） １ ２ Webブラウザ 画面１ 画面２ (2001) (2002) TCP TCP ＩＰ ＩＰ 同一クライアントの通信の識別 （１）と（２）の通信は、画面を２つ開いて、同じ サーバ上の別のページを同時に見ようとしている。 このとき、送信元／宛先IPアドレスと、宛先ポート 番号が一緒であるが、送信元ポート番号が異なる ので、それぞれが別の通信であることを識別する。 (1) クライアント (2 ） Webブラウザ 画面１ (2002) １７２．２０．１００．２０ 画面１ TCP ＩＰ ＩＰヘッダ TCＰヘッダ (1) 送信元IPｱﾄﾞﾚｽ 172.20.100.10 宛先IPｱﾄﾞﾚｽ 172.20.10.34 TCP 6 送信元ﾎﾟｰﾄ番号 ２００１ 宛先ﾎﾟｰﾄ番号 ８０ データ (2) 送信元IPｱﾄﾞﾚｽ 172.20.100.10 宛先IPｱﾄﾞﾚｽ 172.20.10.34 TCP 6 送信元ﾎﾟｰﾄ番号 ２００２ 宛先ﾎﾟｰﾄ番号 ８０ データ 送信元IPｱﾄﾞﾚｽ 172.20.100.20 宛先IPｱﾄﾞﾚｽ 172.20.10.34 TCP 6 送信元ﾎﾟｰﾄ番号 ２００２ 宛先ﾎﾟｰﾄ番号 ８０ データ (3) 別クライアントの通信の識別 （２）と（３）の通信は、別々のコンヒュータから同じ 画面を見ようとしている。 このとき、宛先ポート 番号、宛先IPアドレスが一緒であるが、仮に 送信元ポート番号が同じであっても送信元IP アドレスが異なるので、それぞれが別の通信 であることを識別する。 (3) NSLAB© NTT 2003 21 セキュリティポリシーと運用 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 現在の企業NWの構成とFWポリシー FW/NAT インターネット 社内LAN 192.168.1.102 DMZ（非武装地帯） 企業NW Webサーバ ← ポート80（HTTP） メールサーバ ← ポート25（SMTP） ← ポート110（POP）内部からのみ FTPサーバ ← ポート21（FTP） DNSサーバ ← ポート53（DNS） 原則として、その他のポートはすべて閉鎖しておき、 余分なパケットは通過させない。 VoIPで利用されるポート 9シグナリングパケット ← 例）SIP ポート５０６０（TCP,UDP） ただしこのポート番号はデフォルト値であり、変更可能 9音声パケット （ＲＴＰ） ←1024∼65535（UDP） APLに依存。一般的に偶数が使われる 9音声制御パケット （ＲＴＣＰ） ←1024∼65535（UDP） APLに依存。一般的にRTPよりも１大きいポート番号を使う 少なくとも、これらのポートを通信時に許可する必要がある 少なくとも、これらのポートを通信時に許可する必要がある NSLAB© NTT 2003 22 セッション確立と連動したポート制御とセキュリティへの影響 NTT秘(財産的情報) 従来環境 従来環境 ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 FW User#1 パブリックIP網 パブリックIP網 プライベートＩＰ網 プライベートＩＰ網 HTTP FTP 必要最小限のポートのみ開放し、 余分な通信を防ぐ。 ⇒トロイの木馬型ウィルスでの悪用やセ キュリティホールへの攻撃を防ぐ。 Virus／ ｾｷｨﾘﾃｨﾎｰﾙ VoIP環境 VoIP環境 User#1 FW プライベートＩＰ網 プライベートＩＰ網 HTTP ＳＩＰ Virus/ ｾｷｭﾘﾃｨﾎｰﾙ Voice パブリックIP網 パブリックIP網 [１]認証や、端末間でのﾈｺﾞｼｴｰｼｮﾝがある ことから、従来のﾃﾞｰﾀ通信よりも相手を特 定しやすく信頼性が高い [２]動的にﾎﾟｰﾄを開放することにより侵入を 困難にしているだけでなく、用途を音声に限 定することにより、悪意のあるﾊﾟｹｯﾄの侵入 を防ぎやすい 従来のＨＴＴＰ等のためのポート開放と、セキュリティ面の差はない。 NSLAB© NTT 2003 23 SIPのNAT不通過問題 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 ■ＩＰヘッダのアドレスは「ＮＡＴ」が自動変換するが、ＳＩＰメッセージ内（ＳＤＰ部等）に記載 のＩＰアドレスは変換されないため、ＳＩＰプロトコルレベルでの通信ができないという問題が 発生している。 ホームネットワーク ﾌﾟﾗｲﾍﾞｰﾄ ｱﾄﾞﾚｽ P1 方 向 ⇔ ｸﾞﾛｰﾊﾞﾙ ｱﾄﾞﾚｽ G1 SDP （音声受信ﾎﾟｰﾄ） C=IN IP4 192.168.1.5（=P1） P1 SIPサーバ ｸﾞﾛｰﾊﾞﾙｱﾄﾞﾚｽ（G3） SDP （音声受信ﾎﾟｰﾄ） C=IN IP4 192.168.1.5 G1 G3 NAT プライベート端末 ＳＩＰメッセージ ﾌﾟﾗｲﾍﾞｰﾄｱﾄﾞﾚｽ（Ｐ１） G3 G3 G2 P1 G2 音声 プライベートアドレスを宛 先としたパケットなので ルーチングされない グローバル端末 ｸﾞﾛｰﾊﾞﾙｱﾄﾞﾚｽ（G2） ＳＤＰの内容に基づき、 返信パケットを生成 NSLAB© NTT 2003 24 STUNの機能(RFC3489) NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 • 第１の目的は、グローバル側からプライベート側へのパケット通過を可能とするために、ＮＡＴのグローバ ル側アドレス／ポートを検出すること。 • その他、サーバの認証と、後続メッセージの完全性保証のために利用する暫定パスワード入手手順と、 ＮＡＴの有無や種別を判定する手順、NATの有効時間を検出する手順を含む。 • ＳＩＰ以外のＡＰＬにも利用可能。ストリーム系配信で利用されるＲＴＳＰでの利用もＩＥＴＦにて検討中。 ①セキュリティ手順 ①セキュリティ手順 （サーバ認証、暫定パスワード決定） （サーバ認証、暫定パスワード決定） ①リクエスト ①レスポンス ②アドレス検出手順 ②アドレス検出手順 STUN Server ③NAT種別判定手順 ③NAT種別判定手順 NAT STUN Client （②の繰り返し） （②の繰り返し） Private NW Global NW ②リクエスト ②レスポンス 認証 Server ④NAT有効時間検出手順 ④NAT有効時間検出手順 （②の応用） （②の応用） NSLAB© NTT 2003 25 STUNにより通過可能なNATの種別（その１） NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 通信相手にかかわらず、同じIPアドレスとポート番号に変換するタイプのNAT(=下記の円錐型NAT)であれば、 STUNサーバへのアクセス結果で、NAT変換後のアドレスが推定でき、NATを通過したパケットの受信が可能。 X 192.168.1.1 port=10000 10.10.1.1 port=10 Y プライベート網 192.168.1.1 port=10000 プライベート網 NAT 10.10.1.1 port=10 Z X port=11 ? port=12 ? Y Z 円錐型ＮＡＴ(cone NAT) 相手端末にかかわらず、同じアドレスや ポート番号に変換するもの ⇒STUNサーバ(X)にアクセスすればク ライアントの変換後のアドレスは推定で きる （左記の例では、Xにアクセスするパケッ トのソースアドレスとポート番号を見れ ば、10.10.1.1のport=10を使うことがわか る） ＳＩＰで相手(YやZ)に 10.10.1.1 port=10を、 通知すれば 192.168.1.1 port=10000で パケットの受信が可能 対称型ＮＡＴ(symmetric NAT) 相手端末に応じてアドレスやポート番号 が変わるもの ⇒STUNサーバ(X)にアクセスしても、ク ライアントの変換後のアドレスは特定で きない （左記の例では、Xにアクセスしたパケッ トのソースアドレスとポート番号を見ても、 YやZにアクセスするときのポート番号は わからない） 通信相手に応じて 変換されるポート番号が 変わるので 相手に通信すべき ポート番号が不明 ⇒パケットの受信は不可能 NAPTの場合 注意 ○ＮＡＴは、プライベート網側にある端末のアドレスやポート番号を変換するもので、パブリック網側にあるアドレスを変換するものではない。 ○インターネットプロトコルは、送受のＩＰアドレスとポート番号で通信を識別するので、片方が同じＩＰアドレスとポート番号を使っていても、通信の識別は可能。 NSLAB© NTT 2003 26 STUNにより通過可能なNATの種別（その２） NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 NAT X, port=p Full cone NAT 192.168.1.1 port=10000 10.10.1.1 port=10 プライベート網 Y, port=r NAT 192.168.1.1 port=10000 10.10.1.1 port=10 プライベート網 プライベート網 X, port=p Restricted cone NAT X, port=q Y, port=r NAT 192.168.1.1 port=10000 X, port=q 10.10.1.1 port=10 一度プライベート網からパブリック網に パケットを送出すると、任意の端末から 通信可能。 ⇒ドアノブは一つ （左記の例では、X, port=pにパケットを 送出すると、Y, port=rからのパケットも 受信可能となる。） 一度プライベート網からパブリック網に パケットを送出すると、同一IPアドレスの 端末から通信可能。 ⇒ドアノブは相手IPアドレス毎 （左記の例では、X, port=pにパケットを 送出すると、X, port=qからのパケットも 受信可能となる。） X, port=p Port restricted cone NAT X, port=q Y, port=r 一度プライベート網からパブリック網に パケットを送出すると、同一ポートから は通信可能。 ⇒ドアノブはポート毎 （左記の例では、X, port=pにパケットを 送出しても、X, port=p以外からのパケッ トは受信不可能となる。） STUNでは、STUNサーバに 予備のポート／IPアドレスを 用意し、デフォルトのポートへ のアクセスに対し、予備の ポート／IPアドレスからメッ セージを返信することにより、 左記のNATの種別を判定す る。 （restricted cone NATは、予 備アドレスからの応答は通さ ないが、予備ポートからの応 答は通す。 port restricted cone NATは、 予備ポートからの応答も通さ ない。） NSLAB© NTT 2003 27 STUNの主な信号シーケンス NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 • STUNプロトコルは、STUNクライアント(=端末)からの要求メッセージに対し、STUNサーバ(=網内サーバ) からの応答メッセージにより実行される、クライアント／サーバモデル。 STUNクライアント サーバ認証 ＋ 暫定ﾊﾟｽﾜｰﾄﾞ取得 （ＴＬＳ／ＴＣＰ上） Shared Secret Request STUNサーバ a -> S A <- S Shared Secret Response USER NAME: 暫定ユーザ名 PASSWORD: 暫定ユーザ名に対する暫定パスワード アドレス検出 Binding Request a <- S a -> S Binding Request Binding Response A <- S ＮＡＴ種別判定 NAT アドレス検出 Binding Request a -> S RESPONSE-ADDRESS: 返信先アドレス（別のところに返信さ せたい場合） CHANGE-REQUEST: STUNサーバの予備のアドレスやポー トからの返信を要求する A -> S Binding Response NATで変換されたアドレスを クライアントに通知するのが STUNの基本機能 MAPPED-ADDRESS: Requestのソースアドレスとポート（＝ NATの外側のアドレス） SOURCE-ADDRESS: Responseのソースアドレスとポート（＝STUN サーバのアドレス） CHANGED-ADDRESS: STUNサーバの予備のソースアドレスと ポート（NAT種別判定用にあとでクライアント が利用） REFLECTED-FROM: Requestのソースアドレスとポート(Requestが 別のアドレスに返信を要求した場合の、オリジ ナルのアドレス) A <- S Binding Response さまざまなアドレスからパケットを返信させ、ＮＡＴの種別を判定 NSLAB© NTT 2003 28 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 5. 新しいQoS実現方式の提案 −Priority Promotion Schemeの概要− NSLAB© NTT 2003 IMM（P2P型）通信におけるQoS制御の課題 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 •• IMM通信では、中高速、任意の対地間で、オンデマンドの帯域保証が必要となり、従来の余剰帯 IMM通信では、中高速、任意の対地間で、オンデマンドの帯域保証が必要となり、従来の余剰帯 域によるベストエフォート型ではサービス上、許容されない危険性がある。 域によるベストエフォート型ではサービス上、許容されない危険性がある。 •• 実効帯域に応じた、端末での送信帯域の変更では、サービス品質が維持できず、従量制課金へ 実効帯域に応じた、端末での送信帯域の変更では、サービス品質が維持できず、従量制課金へ の発展性がない。 の発展性がない。 ⇒ ⇒ 中高速通信、任意対地、オンデマンドなどの特徴に適した、QoS制御が必要。 中高速通信、任意対地、オンデマンドなどの特徴に適した、QoS制御が必要。 従来型通信 （webや電子メール）の特徴 インタラクティブマルチメディア通信 （P2P型通信）の特徴 ∼64kbp以下 ⇒ 低速 数100kbps∼数Mbps ⇒ 中高速 （ユーザ主導のP2P型通信であるため、①ア プリケーションによっては、より大きな帯域が 期待され、また②任意の対地間に通信が発 生する可能性がある。） スループットの一時的な低下や、 再送は許容される。 ⇒ ベストエフォート型 会話の要求に応じて、しかもセッション が終了するまでの安定したQoS制御が 必要 ⇒ オンデマンドの帯域割当型 サービスの基準はスループット スループットに加えて、 遅延時間やジッタの低減が重要 ネットワーク全体の課題 ⇒ 受付制御方式 ルータ単体の課題 NSLAB© NTT 2003 30 フロー制御/トラヒック制御の実現方式の比較 ∼提案方式のポイント∼ NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 データ系通信 TCP リアルタイム系通信 （従来型） TCP 目標：通信したいユーザ間で、ＮＷリソースを公平に分割 （例 １０人なら１／１０、１００人なら１／１００） 実現方法： 端末側のＴＣＰによるフロー制御にて自律分散的に実現 ＮＷは土管のみ提供 目標：通信したいユーザ数にかかわらず、一定数のｾｯｼｮﾝの品質を確保 （例 １０人でも５人、１００人でも５人の通信品質は確保） 実現方法： 端末側のフロー制御なし。ＮＷのリソース管理にて実現 データ系では、端末の機能に依存しているため、網の データ系では、端末の機能に依存しているため、網の 機能が単純化でき、エンド･エンドのグローバルな制御 機能が単純化でき、エンド･エンドのグローバルな制御 が実現可能（↑）。 が実現可能（↑）。 リアルタイム系通信 （提案型） 一方、従来のリアルタイム系通信は、網機能への依存 一方、従来のリアルタイム系通信は、網機能への依存 度が高すぎるため、汎用性にかける（♂）。 度が高すぎるため、汎用性にかける（♂）。 端末とＮＷの機能分担を見直すことにより、汎用のＱｏ 端末とＮＷの機能分担を見直すことにより、汎用のＱｏ Ｓ保証方式をねらう（→）。 Ｓ保証方式をねらう（→）。 実現方法： 端末側で、受信品質に応じたＴｏＳ値の設定 ＮＷ側は、優先制御のみでリソース管理なし NSLAB© NTT 2003 31 プライオリティプロモーション方式とは NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 ■ねらい ■ねらい インタラクティブな音声・画像通信を対象に、ネットワークの混雑時でも、少なくとも接続中の通信 インタラクティブな音声・画像通信を対象に、ネットワークの混雑時でも、少なくとも接続中の通信 については、通信が完了するまで、所定の品質を維持することを狙いとしたQoS制御方式。 については、通信が完了するまで、所定の品質を維持することを狙いとしたQoS制御方式。 パケット単位に帯域を公平に分け合うのではなく、セッション単位に帯域を譲り合うサービス。 パケット単位に帯域を公平に分け合うのではなく、セッション単位に帯域を譲り合うサービス。 ■アプローチ ■アプローチ 多様化する通信網を考慮すると、エンドエンドの通信品質維持のためには、端末の協力（最終判 多様化する通信網を考慮すると、エンドエンドの通信品質維持のためには、端末の協力（最終判 断）が不可欠であることに着目。 断）が不可欠であることに着目。 端末側は、 本当に通信できるかどうか、 自分で試して、判断してください。 ただし、他人に迷惑をかけないように。 送信側は非優先クラスで試験パケットを送出し、 受信側からの受信結果で品質良好な場合のみ、 優先クラスで通信を確立。 さらにネットワーク側は、 ときどきチェックしますよ。 ネットワーク側は、 一度確立した通信は必ず最後まで保証します。 ただし、余裕のあるときだけです。 余裕があるかどうかは、最初に調べてください。 セッション単位ではなく、クラス単位の優先制御により、 確立墨の優先クラスの通信品質は保証するとともに、 非優先クラスを利用した残帯域の推定が可能。 ■メリット／ポテンシャル ■メリット／ポテンシャル ユーザ網や複数網を横断したエンドエンドでの品質保証 ユーザ網や複数網を横断したエンドエンドでの品質保証 ネットワーク機能の軽量化によるスケーラビリティ、多様なネットワークでも利用可能な汎用性 ネットワーク機能の軽量化によるスケーラビリティ、多様なネットワークでも利用可能な汎用性 NSLAB© NTT 2003 Priority Promotion Schemeが前提とするキュー方式 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 •• 下記のようなキュー方式を、MFクラス(Measurable 下記のようなキュー方式を、MFクラス(MeasurableForwarding; Forwarding;観測可能な転送クラス)と定義。 観測可能な転送クラス)と定義。 •• MFクラスでは、試験パケットにより、リンクの残帯域が推定可能。 MFクラスでは、試験パケットにより、リンクの残帯域が推定可能。 •• 基本動作は、既存の優先制御(=Diffserv)で容易に実現可能 基本動作は、既存の優先制御(=Diffserv)で容易に実現可能 通常のキュー方式 flow #1 flow #2 flow #1 flow #2 残帯域が測定可能なキュー方式 flow #1 flow #2 flow #2 品質劣化の 原因 リンク容量を上回るパケットが流入すると 区別なく廃棄が発生する。 ⇒フロー＃１のパケットの品質は保証されない。 リンク容量を上回るパケットを流入しても フロー＃１のパケット（優先クラス）は必ず転送される。 ⇒非優先クラスで試して、通過すれば優先クラスでも転送されるはず。 ⇒試験パケットにより、残帯域が測定可能 NSLAB© NTT 2003 33 プライオリティプロモーション方式の帯域空き判定 ∼動作概要∼ NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 •• ルータでは、帯域しきい値BWmf以下ではH+Mの転送を保証し、しきい値を越えた場合は、Mを優先的に廃 ルータでは、帯域しきい値BWmf以下ではH+Mの転送を保証し、しきい値を越えた場合は、Mを優先的に廃 棄する。 棄する。 •• 端末は、通信の前に試験パケットを非優先クラスMで送出し、通信可否判定をする。 端末は、通信の前に試験パケットを非優先クラスMで送出し、通信可否判定をする。 廃棄がなければ、通信可能と判断し、優先クラスHで通信を確立する。 廃棄がなければ、通信可能と判断し、優先クラスHで通信を確立する。 廃棄があれば、通信不可と判断し、通信を確立しない。 廃棄があれば、通信不可と判断し、通信を確立しない。 •• 上記動作の組み合わせにより、結果的に、品質が確保できる範囲で通信が確立されることになる。 上記動作の組み合わせにより、結果的に、品質が確保できる範囲で通信が確立されることになる。 回線が混んでいる時は、Mが廃棄されるため、端末は通信を確立しない。 回線が混んでいる時は、Mが廃棄されるため、端末は通信を確立しない。 試験パケットは、非優先なので、すでに確立されているHの通信は邪魔されない。 試験パケットは、非優先なので、すでに確立されているHの通信は邪魔されない。 loss loss M M M M M H H H M M H M H M 回線が空いている時は 回線が空いている時は 端末は、Hで通信を確立 端末は、Hで通信を確立 BWmf H M M H H H 再び回線が空いてきたら 再び回線が空いてきたら 端末は、Hで通信を確立 端末は、Hで通信を確立 NSLAB© NTT 2003 時間 キュー方式への要求条件 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 ネットワーク内の装置において、下記のMFクラスの実装が最低限の要求条件であり、これさえ実装されていれば、 ネットワーク内の装置において、下記のMFクラスの実装が最低限の要求条件であり、これさえ実装されていれば、 プライオリティプロモーション方式(=自律分散制御)によるエンド−エンドの品質保証が提供できる。 プライオリティプロモーション方式(=自律分散制御)によるエンド−エンドの品質保証が提供できる。 MF class(Measurable forwarding class)とは MF-HとMF-Mの二つのクラス(HとM)が存在する。 HとMの合計の利用可能帯域には上限があり その上限以下であれば転送は保証される。 また、Hが上記の上限以下であれば Mの有無にかかわらず転送が保証される。 MF-H MF-M MF 言い換えれば、Mで試すことにより、 Hに被害を与えることなく、Mの追加可否の判断ができる。 追加可の場合、Hに格上げすることで安定品質を確保する。 ? ? ? ? M Mで試して、ＯＫなら Ｈに格上げする。 H NSLAB© NTT 2003 35 自律分散型QoS制御（Priority Promotion Scheme: PPS） NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 安定的な品質を実現するために、端末とNWの機能分担を見直し、受信端末での品質の観測結果をもとに、 安定的な品質を実現するために、端末とNWの機能分担を見直し、受信端末での品質の観測結果をもとに、 送信端末がパケットの優先度を付与する、汎用的なセッションレベル（ＳＩＰと連携した）での品質制御方式。 送信端末がパケットの優先度を付与する、汎用的なセッションレベル（ＳＩＰと連携した）での品質制御方式。 契約ユーザ管理、 端末監視指示、 課金情報収集 通信可否、流量監視 （一次監視） 品質制御ﾒｶﾆｽﾞﾑ ①通信の前段で、非優先クラスの試験パケッ トを送出 ②受信端末で、受信ﾊﾟｹｯﾄから通信品質を測 定し、RTCPﾊﾟｹｯﾄとして返送 ③送信端末は、一定時間NW品質を観測し、 ・品質がよかった場合： 優先度を上げてRTPを送出 ⇒安定状態（優先権確保） ・品質が悪かった場合： 優先度を下げてRTPを送出 ⇒一般レベルに逆戻り ⇒一定時間後再挑戦 選択的な詳細監視 (二次監視) ﾓﾆﾀ ｻｰﾊﾞ SIP サーバ 利用可能帯域の測定と 通信可否判断 優先制御 エッジ装置 受信状況 報告 エッジ装置 IP端末 IP端末 RTP(非優先クラスの試験パケット) RTCP(受信状況報告) RTP(優先クラスの音声・画像パケット) ■ﾊﾟｹｯﾄ優先度の遷移例 ToS値 成功 （優先権獲得） Highﾚﾍﾞﾙ Middleﾚﾍﾞﾙ Lowﾚﾍﾞﾙ ﾄﾗｲ ﾄﾗｲ HとMのセットで帯域を保証し、Mを優先的に廃棄するキュー方式により、 Hの品質を保証しつつ、Mで通信可否が判定できる。基本はDiffServ ﾄﾗｲ loss M 失敗 M M M 失敗 M 通信経過時間 M ルータのキュー動作 M H H H H loss ←通信は確立されない 帯域 上限 M H H 時間 NSLAB© NTT 2003 36 プライオリティプロモーション方式の位置づけ NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 アドミッションコントロールのスケーラブル化へのアプローチとしては、従来、IntServの適用をアクセスネットワ アドミッションコントロールのスケーラブル化へのアプローチとしては、従来、IntServの適用をアクセスネットワ ークに限定したり、リソース予約のためのアクセスネットワークを軽量化するアプローチが検討されている。 ークに限定したり、リソース予約のためのアクセスネットワークを軽量化するアプローチが検討されている。 様々なアプローチの中でプライオリティプロモーション方式は 様々なアプローチの中でプライオリティプロモーション方式は アクティブ方式 アクティブ方式 として分類される として分類される スケーラブル化へのアプローチ スケーラブル化へのアプローチ IntServ IntServ // RSVP RSVP の軽量化 の軽量化 IntServ IntServ over over DiffServ DiffServ アクセスネットワークは「IntServ」、 バックボーンネットワークは「DiffServ」をサポートする。 IntServからはDiffServクラウドはIntServアクセス ネットワークを繋ぐ仮想リンクに見える。 サブネット間のリソース予約を集約したり、ルータが 管理する状態を集約することでスケーラビリティを 向上させることが考えられる アクティブ方式 アクティブ方式 エンドポイント間に、アドミッションを要求するフローと同等のレートで プローブフローを新たに加え、そのQoSの観測から内部状態を推定し、 アドミッションコントロールを行う エンドポイント方式 エンドポイント方式 ネットワークの内部状態を推定する ための機能をエンドポイントに持たせ アドミッションコントロールを行う方式 パッシブ方式 パッシブ方式 新たにプローブフローを加えること なくパケットを観測することにより、 網の内部状態を推定し、アドミッション コントロールを行う形式 *間瀬 憲一 「インターネットにおけるスケーラブルなアドミッションコントロール方式」 電子情報通信学会 vol.85 No.9 pp.655-661 2002.9 NSLAB© NTT 2003 37 セッション単位のQoS保証技術の比較 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 • • 現状は、ルータでの優先制御と余裕を持った設備設計により、間接的にQOSを保証している。 現状は、ルータでの優先制御と余裕を持った設備設計により、間接的にQOSを保証している。 • • 将来的には、リアルタイム系通信により数Mbps以上の継続的なトラヒックが、任意の対地間で発生するため、セッション単位 将来的には、リアルタイム系通信により数Mbps以上の継続的なトラヒックが、任意の対地間で発生するため、セッション単位 の受付判定による直接的なQOS保証が必要となる。 の受付判定による直接的なQOS保証が必要となる。 余裕をもった設備設計（現状） それまでの交流トラヒックをもとに 余裕をもった設備設計をし 明示的な受付制御なく 品質を維持する。 １．NWのﾘｿｰｽを把握しているサーバで受付判定 SIP proxy ルーチング情報を元に トポロジーと利用可能帯域を 完全把握し、受付判断する。 ３．ルータでフロー毎の受付判定（例 RSVP） 各ルータが フロー単位の通信状況を管理し 受付判定を行う。 ! 残余帯域の判定可能なQに対し SIP 端末から試験パケットを送出し 受信状態に応じて受付判定を行う。 ! ! SIP proxy ! ２．端末主導で受付判定 SIP proxy ! ﾘｿｰｽ管理ｻｰﾊﾞ !:受付判断機能 proxy ! NSLAB© NTT 2003 38 QoS制御／エッジルータ制御技術動向 NTT秘(財産的情報) ﾈｯﾄﾜｰｸｻｰﾋﾞｽｼｽﾃﾑ研究所 ∼２００２年 ２００３年 ■Diffserv WG EF, AF, BEの規定をもって完了 IETF ▲2003/3 ２００４年 ▲2003/7 ▲2004/8 ▲2004/2 ▲2003/11 ▲2004/11 ■MIDCOM WG (Middlebox communications) => SNMPv3 NATのような網内装置をミドルボックスと位置づけ、APL対応サーバから制御する方式を検討 ２００３年７月時点では、NAT制御に限定し、SNMPｖ３の適用を検討中 プロトコル議論中心 ■NSIS WG (Next Steps in Signaling) メディアの転送ルートを意識した新たな信号制御(RSVPの改良)を検討中 QoS制御とＮＡＴ／ＦＷ制御を想定 共通部(NTLP)と個別制御部(NSLP)から構成される。 ▲2003/7 ▲2003/9▲2003/11 ▲2004/1 ▲2004/2 全体会合 JRG ﾗﾎﾟｰﾀ会合 JRG 全体会合 ■SG13(アーキテクチャ) Q.16のY.qosarにてアーキテクチャを検討(集中管理型) Q.4にてルータ動作を検討 ITU-T ▲2002/11 全体会合 ▲2003/4 ﾗﾎﾟｰﾀ会合 ▲2003/9 全体会合 ▲2003? ﾗﾎﾟｰﾀ会合 アーキテクチャから検討 ▲2004? 全体会合 ■SG11(信号方式) Q.1,6のQ.ncap1, 2にてゲート制御プロトコル(GCP)の要求条件を検討 Q.11のQ.ncap3にてGCP用にmegaco profileを検討 Q.7,8,9のTRQ.IPQoS.Sig.CS1にてIP-QoSの要求条件を検討 プロトコル議論を先行 □ETSI 次世代NWアーキテクチャ検討の一環でMegacoの改良によるエッジ制御を２００２年６月に規定済み □Packet Cableや3GPPでは、COPSを規定 NSLAB© NTT 2003 39