[ Top page ]

« NGN の QoS 保証基本アーキテクチャ | メイン | NGN のセッション確立における QoS のあつかい »

NGN, QoS 保証

バックボーン網を経由するときの端点間 QoS 保証法

NGN (次世代ネットワーク) において呼がバックボーン網を経由するときの端点間 QoS 保証法についてのべる.

1. 参照モデル

TR 23.802 [3GP 06f] によれば,バックボーン網を経由する接続における端点間 QoS の制御をかんがえるときは,まず図 1 のような参照モデル (reference model) が基本だという. この図に関してはつぎのような説明がくわえられている.

アプリケーションはバックボーン網とも通信できる (図の “App. node-backbone control plane interface”). アプリケーションとバックボーン網との交換情報としてはつぎのようなものがありうる.

  • 間接的な制御情報 (たとえばマーキング ― 静的な DiffServ)
  • Aggregate された資源予約をふくむ明示的な制御機能 (シグナリングをともなう DiffServ)
  • フローごとの資源予約をふくむ明示的な制御機能 (IntServ)
  • 交換しない

ただし,図 1 にはバックボーン網だけが記述され,アクセス網が記述されていない.

NGNBBmodel.png
図 1 参照モデル [3GP 06f]

2. アクセス網とバックボーン網の協調方式

3GPP においては,IMS をもつ網とバックボーン網をふくめて外部のネットワークと接続するときのそことの協調動作 (interworking) のしかたをさだめている. バックボーン網においては DiffServ が使用されることを想定し,UMTS 網が DiffServ のエッジ機能 (マーキング,ポリシングなど) をもつことを要請しているが,DiffServ にしばられているわけではない. 協調動作のための方法としてつぎの 3 つが例としてあげられている [3GP 06e] が,これにしばられてはいない.

  1. フローパスにそったシグナリング: RSVP メッセージなどによって協調動作する.(これはかならずしも RSVP メッセージがバックボーン・ルータによって解釈されることを意味するわけではない.)
  2. ネットワーク管理機能間の相互作用: 網間で資源要求を陽に交渉し,プロビジョンする.
  3. SLA の交渉: サービスレベル仕様を交渉する.

TR 23.802 [3GP 06f] にはバックボーンを介する UMTS における端点間 QoS 保証に関するいくつかの方式が図とともに説明されている. 図 2 は上記の 1. のようなフローパスにそったシグナリング*を使用する方式の説明図である. また図 3 はこれとはちがってフローパスを経由しない BCF (Bearer Control Function) 経由のシグナリングを使用する方式 (上記の 2. に相当するとかんがえられる) の説明図である. TR 23.802 [3GP 06f] には上記の 3. の方式の説明図もあげられている.

* “フローパスにそった” に相当することばとして 3GPP においては "on-path” ということばが使用され,RFC 4080 においては “path-coupled” があたえられている. また,“フローパスを経由しない” に相当することばは 3GPP においては “off-path” であり RFC 4080 においては “path-decoupled” である.

OnPathSignaling.png
図 2 フローパスにそったシグナリングを使用する方式 [3GP 06f]

OffPathSignaling.png
図 3 フローパスを経由しないシグナリングを使用する方式

これらのうち,フローパスを経由しない BCF 経由のシグナリングを使用する方式においては,UMTS における PDF とバックボーン網における BCF とが連携して QoS 保証を実現する (TR 23.802 の 5.4.2 節を参照)が,そのためには複数のバックボーン網があるときでも PDF が連携相手の BCF を発見できるようにする必要がある.

フローパスにそったシグナリングを使用する方式については次節以降でよりくわしく説明する.

3. フローパスにそったシグナリングを使用する方式

フローパスにそったシグナリングを使用する方式においては,シグナリングのためのわくぐみとして TR 23.802 [3GP 06f] (その 5.5 節) にはつぎの 4 つがあげられている (これらは排他ではない).

RSVP
RSVP にポリシーを反映させる方法として RFC 2750 [Her 00b] があり,関連する RFC として RFC 2752 [Yad 00],RFC 2872 [Ber 00b] がある. また,資源予約をまとめる (aggregate) 方法は RFC 3175 [Bak 01] に記述されている (これが IntServ と DiffServ をくみあわせるためにつかえる). まとめた予約に関するデータ・パケットが予約されたパスにしたがうようにするには,トンネル (IP-in-IP, GRE, MPLS など) を使用する必要がある. トンネル技術のなかで MPLS はトラフィック・エンジニアリングがおこなえる利点がある. また,UMTS においては IP-CAN Gateway (GGSN) が RSVP メッセージ転送に責任をもつ. 関連するインタネット・ドラフトとして Le Faucheur ら [Fau 06b] がある.
MPLS-TE (MPLS トラフィック・エンジニアリング)
MPLS-TE においては LSP (ラベル・スイッチ・パス) に 8 個の優先度がつけられている. また,setup priority と hold priority という 2 つの型がある.資源が不足しているときは,これらをつかって資源わりあてがされるが,その詳細は RFC 3346 [Boy 02] に記述されている. 関連するインタネット・ドラフトとして Le Faucheur ら [Fau 06a] がある.
フィードバックにもとづくアドミッション制御
トラフィックが経由するネットワークからのフィードバック情報にもとづき,ポリシーにもとづいてアドミッション制御をおこなう. DiffServ のリマーキングを使用するのがひとつの実現法だが,それを図 3 [3GP 06f] にしめす. この目的では端点においてマーキングするのがよいという [Bab 06]. 関連するインタネット・ドラフトとして Chan ら [Cha 06] がある.
NSIS
???においてのべたように,IETF の NSIS (Next Step In Signaling) ワーキンググループは QoS をはじめとするさまざまな目的につかえるあたらしいシグナリング・プロトコルとして NSLP と NTLP (GIST) とをさだめている. RSVP は受信者がシグナリングをはじめるようにきめられていたが,NSLP においてはこのように特定の QoS モデルに限定されずに,シグナリング方式に関しても QoS 仕様に関しても,さまざまなモデルが実現できる点で NGN の要求にあっている. QoS 仕様に関する基本ドキュメント [Ash 06a] においては RSVP にもある帯域や遅延の記述法にくわえて,ジッターの記述法,DiffServ の PHB クラスの記述法や Y.1541 QoS クラスの記述法も規定されている.

FB-mark-remark.png
図 4 フィードバックとマーキング / リマーキングにもとづくアドミッション制御 [3GP 06f]

参考文献

  • [3GP 06e] 3rd Generation Partnership Project (3GPP), “Technical Specification Group Services and System Aspects; End-to-end Quality of Service (QoS) Concept and Architecture (Release 6)”, 3GPP TS 23.207 V6.6.0, September 2005.
  • [3GP 06f] 3rd Generation Partnership Project (3GPP), “Technical Specification Group Services and System Aspects; Architectural Enhancements for End-to-end Quality of Service (QoS) (Release 7)”, 3GPP TR 23.802 V7.0.0, September 2005.
  • [Ash 06a] Ash, J., Bader, A., and Kappler, C., “QoS NSLP QSPEC Template”, draft-ietf-nsis-qspec-10, Internet Draft, IETF, June 2006.
  • [Bab 06] Babiarz, J., Chan, K., and Baker, F., “Configuration Guidelines for DiffServ Service Classes”, draft-ietf-tsvwg-diffserv-service-classes-02, Internet Draft, IETF, February 2006.
  • [Bak 01] Baker, F., Iturralde, C., Le Faucheur, F., and Davie, B., “Aggregation of RSVP for IPv4 and IPv6 Reservations”, RFC 3175, IETF, September 2001.
  • [Ber 00b] Bernet, Y. and Pabbati, R., “Application and Sub Application Identity Policy Element for Use with RSVP”, RFC 2872, IETF, June 2000.
  • [Boy 02] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., Christian, B., and Lai, W. S., “Applicability Statement for Traffic Engineering with MPLS”, RFC 3346, IETF, August 2002.
  • [Cha 06] Chan, K., Babiarz, J., and Baker, F., “Aggregation of DiffServ Service Classes”, draft-ietf-tsvwg-diffserv-class-aggr-00, Internet Draft, IETF, June 16, 2006.
  • [Fau 06a] Le Faucheur, F., Ed., “Aggregation of RSVP Reservations over MPLS TE/DS-TE Tunnels”, draft-ietf-tsvwg-rsvp-dste-03, Internet Draft, IETF, June 2006.
  • [Fau 06b] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and Hamilton, B. A., “Generic Aggregate RSVP Reservations”, draft-ietf-tsvwg-rsvp-ipsec-01, Internet Draft, IETF, June 2006.
  • [Her 00b] Herzog, S., “RSVP Extensions for Policy Control”, RFC 2750, IETF, January 2000.
  • [Yad 00] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., and Herzog, S., “Identity Representa-tion for RSVP”, RFC 2752, IETF, January 2000.
Keywords: リソース予約, リソース要求, 資源割当て, 資源割り当て, リソース割当て, リソース割り当て, リソースわりあて

コメントを投稿

Powered by
Movable Type 3.36