調査と解説

IntServ の概要

IntServ (Integrated Services) [Bra 94] [She 97b] とは，フローごとに帯域などのネットワーク資源を確保することによって QoS を確保しようとする QoS 保証通信サービスである．

IntServ については情報的 RFC である RFC 1633 [Bra 94] にその概要が記述されている． また，RSVP は IETF 標準の RFC 2205 [Bra 97] において規定され，IntServ における RSVP の使用法については IETF 標準である RFC 2210 [Wro 97a] において規定されている．

IntServ にはつぎの 2 つのサービスモデルがある．

Guaranted Service (品質保証型サービス)

帯域と最大遅延を保証するサービス [She 97a]．

Controlled Load Services (負荷制御型サービス)

遅延の目標値をもち，流量をみずから制御する適応型アプリケーションを想定したサービス [Wro 97b]． ネットワークが混雑している場合であっても，利用率がひくいベストエフォート・ネットワークと同等程度に動作することをめざしている．

実時間のアプリケーションの QoS 保証には帯域，遅延のほかにジッター (遅延のばらつき) に関する保証も必要だが，IntServ の機構ではその実現は困難であり，保証項目としてふくまれていない．

上記のサービスを実現するため，IntServ においてはアプリケーションが特定のフローに対する保証を要求するプロトコルとして RSVP が用意されている． また，RSVP のメッセージがそのフローとおなじパスを通過することを保証し，そのメッセージが通過する際に資源を予約することによって，要求されたサービスが実現されるようにしている． 後述するように IntServ はコアルータのオーバヘッドがおおきいために普及しなかったが，RSVP の複雑さなどの問題点も普及をさまたげる原因となっていたとかんがえられる． RSVP にかわるプロトコルを設計してそれらの問題点を解決しようというこころみもおこなわれている．

RSVP による資源予約

IntServ においては，これから通信しようというときに受信者が資源 (帯域など) を確保するために RSVP (Resource reSerVation Protocol, Version 1) というプロトコル [Wro 97a] を使用する． そこで，このプロトコルについて説明する．RSVP の特徴 [Cho 98] のなかから，いくつか重要なものを抜粋する．

• 一方向のデータフローに対する資源予約をおこなう．
• 送信者ではなく受信者が予約を起動する．
• ソフトステートである． すなわち，電話網のように途中の装置が状態を保持しているのではなく，状況に応じて状態を常に更新し続けるシステムとすることで，自動的に障害への対応が行われるシステムとなっている．
• ルーティングプロトコルから分離している． ルーティングプロトコルが確立したパスの上に，独立して資源を予約していくシステムとなっている．
• RSVP をサポートしないネットワークを透過して動作する．

RSVP のモデルを図 2 にしめす．「上流である A/B/B' から，下流である C/D/D' にデータが流れる場合に送られる，メッセージの種別を示しています．」

RSVP の主要なメッセージタイプについて説明する．

Path

送信者がフロー情報をアナウンスするメッセージである． 送信者は定期的にこのメッセージを送り，フローを指定するための情報とオリジナルのフロー情報とを通知する． 中間のルータはフロー情報をかきかえながら，このメッセージを中継する．

Resv

Path メッセージに応答して受信者が予約を確立するためのメッセージである． 受信者は到着した Path メッセージに応答してこのメッセージを送信し，予約したい QoS 指定情報とフローの指定を通知する． 中間のルータはこのメッセージに従って予約を確保して，上流 (送信者にちかい側) に中継する．

他のメッセージ

PathTear，ResvTear は予約を終了させるためのメッセージであり，PathErr，ResvErr は予約の失敗を通知するためのメッセージであり，Confirm は予約を確認するためのメッセージである．DiagReq は診断を要求するメッセージであり，DiagRep は診断結果を報告するメッセージである．

IntServ においては通信前に通信路において資源を確保するために RSVP の Path メッセージを発行する． Path メッセージは目的の通信とおなじ通信路上を伝播する． Path メッセージが通信相手に到達すると実際に資源予約をおこなうための Resv メッセージが発行される． Resv メッセージは，Path メッセージがたどったのと逆の経路をたどりながら資源を確保していく． したがって，Resv メッセージが Path メッセージの送信元にただしくとどくと資源確保は完了し，目的の通信をおこなうことができる． Path メッセージおよび Resv メッセージは通信中も一定間隔で送信しつづける． すなわち，これらのメッセージは keep-alive メッセージとして使用される． その送信がとまってタイムアウトすると確保されていた資源は解放される．

IntServ とくに RSVP はつぎのような理由から実際にはあまり利用されなかった [Cho 99]．

• スケーラブルでない． すなわち中間ルータにおいてフローごとの状態を記憶することが必要であり，バックボーンにおいては状態数が膨大になるためスケールしない．
• 技術主導であり，現状とのギャップがおおきかった． メカニズムが複雑すぎ，システム管理が困難であり，課金やコスト等のビジネスモデルと整合しないなど，実際の運用にはおおくの問題点があった．
• シグナリングが本質的にむずかしい． 動的な状態管理を行うアドミッション制御は，本質的に解決がむずかしい問題をいろいろともっていることがわかった．

関連項目

• QoS とはなにか
• RSVP にかわるプロトコルの開発

参考文献

• [Bra 94] R. Braden, D. Clark, and S. Shenker, “Integrated Services in the Internet Architecture: an Overview”, RFC 1633, IETF, 1994.
• [Bra 97] R. Braden ed., L. Zhang, S. Berson, S. Herzog, and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification”, RFC 2205, IETF, 1997.
• [Cho 98] 長 健二朗, “QoS 技術 ～ IntServ と DiffServ”, Internet Week 98, (社) 日本ネットワークインフォメーションセンター, http://www.nic.ad.jp/ja/materials/iw/1998/notes/C12.pdf, 1998.
• [She 97a] Shenker, S., Partridge, C., and Guerin, R., “Specification of Guaranteed Quality of Service”, RFC 2212, IETF, September 1997.
• [She 97b] Shenker, S. and Wroclawski, J., “General Characterization Parameters for Integrated Service Network Elements”, September 1997.
• [Wro 97a] J. Wroclawski, “The Use of RSVP with IETF Integrated Services”, RFC 2210, IETF, 1997.
• [Wro 97b] Wroclawski, J., “Specification of the Controlled-Load Network Element Service”, RFC 2211, IETF, September 1997.

• IntServ (Wikipedia)
• Resource Reservation Protocol (Wikipedia)