この記事は吉田氏から寄稿いただきました。感謝。

24th - OpenFlowは、再びQoSの夢を見せてくれるか

我らが安田先生が、OpenFlow Advent Calender で孤軍奮闘なさっているので、自分も微力ながら寄稿させていただくことにしました。
ネタとしてはもう古いのですが、昨年8月、公開されていたOpenFlow 1.3の仕様を見たときに考えたことを中心に書いてみます。OpenFlow自体はいじったことはないのであくまでも机上実験として。
そもそもの動機
 OpenFlowを見た時に最初に感じたのは、「これ、managed networkじゃないか」でした。managed networkというのは、要求されたサービスを実現するために集中的にトラフィック管理が行われるネットワークドメインのことを指します。インターネットはOSPF（AS内）などの経路制御により自律的に動作し、トラフィックを集中管理するサーバのようなものは存在しません。これがインターネットのよい点でもあった訳ですが、運用管理の視点からすると必ずしもプラスには働きませんでした。ルータ、スイッチ類は設定後は自律的に動作しますが、設定自体は整合性を持ったものでなくてはいけません。また、機器や要求の変更があった場合の設定のやり直しも負荷のかかる話でした。つまり、「動作は分散、管理は集中」というのがあるべき姿だった訳です。
この視点に立つと、OpenFlowネットワークはまさにmanaged networkです。コントローラの設定に従い、管理ドメインのネットワークは自律的に動きます。コントローラが集中サーバになっているからといって、コントローラがボトルネックになることもありません。機器や要求の変更があった場合も即座に対応できます。
ここまでは、専門家の方が言われていることで、特に私などが力説することでもありません。ここでは、managed networkのコンセプトがネットワークにおけるQoSの実現から来ていることを書こうと思います。QoSとはQuality of Serviceの略で、指定されたトラフィックのジッタ（ゆらぎ）、遅延、帯域などの特性を保証するという概念です。ジッタ、遅延については「何msに抑える」、帯域については「何Mbpsを確保する」というような保証で、用途としては、音声、映像といったリアルタイムトラフィックが対象になります。
インターネット上にQoSを実現しようという試みは1990年代に始まります。この試みは、RSVPという帯域予約プロトコルを生み出し、DiffServというフレームワークを生み出しました。こうして、2000年前後、ホットトピックとなっていたQoS保証はその後、実運用のされないないままシュリンクしていきます。
このように実現されなかったQoS保証ですが、managed networkからかつてのDiffServを連想した私は、OpenFlowを使ってQoS保証が実現できるかもしれないと思いました。これがそもそもの動機になります。
DiffServとBandwidth Broker
 ここで準備として、DiffServとBandwidth Brokerについて紹介します。 この説明はかなり長くなるため、過去に作ったスライドをslideshareにアップすることにしました。この資料（020910 QoS_kibayo）をざっと見ていただいて、概念を掴んでいただければと思います。他の資料ですが、ググってみると、Wikipedia:DiffServ と長さんがInternetWeek2000で講演された資料（Diffservの仕組みと動向）が見つかります。前者は概要、後者は詳細な技術資料として参考になると思います。
DiffServの原理は、IPパケットのToSフィールドを使ってパケットをクラス分けし、ルータにおいてクラス毎に異なる設定のされたキューイングアルゴリズムを使って、サービスの違いを出すところにあります。例えば、HTTPのパケットと映像のパケットが同時に来た場合は、映像の方を優先的に処理するということで、できるだけ映像のパケットを落とさないようにします。
DiffServにおいて、帯域などのリソース管理は分割されたドメイン毎に任されていて、DiffServでは特に規定はされていません。ここで登場するのが、Bandwidth Brokerです。Bandwidth Brokerは管理ドメインのトポロジーや帯域の割り当て状況を完全に把握しています。スライドの中でポリシーという言葉が出てきますが、これはBandwidth Brokerに与える運用ルールのようなものです。例えば、毎週月曜日の9時から10時までの間、部門A内でネットミーティングがある場合に、その時間帯だけ部門A内のマシンから送信されるパケットに優先クラスをセットし、かつ、映像パケットがドロップしないよう、部門A内のマシン間で使うネットワークのリンク帯域を例えば5Mbps以上空きがでるようにする、といった内容です。（スライドp.26～32にその例があります）
ここで、「5Mbps以上のリンク帯域の空きがでるようにする」ところですが、実際にはルータは接続されているリンクの空き帯域を制御することはしません。Bandwidth Brokerが頭の中で、ドメイン内を流れる優先パケットの使用帯域を計算し、空き帯域の確保に支障をきたすようなトラフィックの流入を拒否します。これをアドミッション制御といいます。（スライドp.13～25にその例があります）これは電話が混み合っている時に、呼び出しが拒否されるのと似ています。
ここまでの説明で、クラス分けされたパケットをキューイング制御するルータやスイッチがData Planeであるなら、制御をつかさどるBandwidth Broker は、まさにControl Planeと言うことができます。これで、OpenFlowのフレームワークとDiffServ+Bandwidth Brokerのフレームワークが似通ったものであることを理解していただけたと思います。
OpenFlowでQoSは扱えるか
 ここまで理解が深まると、OpenFlowを使ってDiffServのQoS保証が実現できるかどうかについて追求したくなります。これが技術者の性というものです。(^^;;
ですが、最初にOpenFlowのスペック（OpenFlow Switch Specification 1.0、以降OpenFlow 1.0と略）を見た時には必要な機能が欠けていました。パケットを識別するための条件に ”IP ToS bits” があり、ToSフィールドのチェックはできますし、アクションには ”Modify-Field” があり、ToSフィールドの変更もできそうですが、肝心のキューイングアルゴリズムを指定するところが見当たりません。ところがその後、OpenFlow 1.3の仕様を見て、set-queueアクションとmeter tableが追加されているのを見つけました。これは期待が持てます。
ここで、QoS保証、つまりBandwidth Brokerの実現のための要件をまとめてみます。
  • OpenFlowドメイン
    • トポロジー情報を収集できること。
  • OpenFlowスイッチ
    • 指定された(protocol, src address, src port, dst address, dst port) の5つ組にマッチするパケットがinされた時に、そのパケットのToSフィールドに指定のマーキングができること。
    • マーキングされたパケットがinされた時、そのパケットを指定のキューに流すこと。
      • 尚、指定のキューは、少なくともpriority queueの機能を持つ。
    • マーキングされたパケットが指定されたレートを越えてinされた時に、そのパケットをdropすること。
  • OpenFlowコントローラ
    • 2.の機能を各OpenFlowスイッチに対して指示できること。
1.のトポロジー情報の収集は、ノード間の経路計算を頻繁に行うBandwidth Brokerには必ず必要となる機能です。トポロジー情報の収集はOpenFlowの仕様には記載されていませんが、標準的なOpenFlowスイッチで動作するLLDP（Link Layer Discovery Protocol）を使って実現することができます。LLDPについては、こちらの資料（LLDP（IEEE 802.1AB））を参考にしてください。
3.のOpenFlowコントローラの機能については言うまでもありません。2.aは先に書きました ”IP ToS bits” と ”Modify-Field” を使ってできますので、問題は、2.b,cの機能がサポートされているかにあります。そこで、OpenFlowの各バージョンについて、2.に記載した機能のサポート状況を調べてみました。下が表にまとめたものです。
バージョン リリース QoS関連機能のサポート状況
1.1.0 Feb. 28, 2011 optional actionとして、set-queueが追加される。但し、queue configurationは、minimum-rate queueのみ
1.2.0 Dec. 5, 2011 queue configurationに、maximum-rate queueとexperimenter queueが追加される。
1.3.0 June 25, 2012 per-flow meterを持つmeter tableが追加される。（rate limiterとしての用途）
1.4.0 Oct. 14, 2013 meter change noticationが追加される。
※OpenFlowの各バージョンの仕様書は、ONF Specifications からダウンロードできます。
2.bの機能ですが、バージョン1.1から、マッチしたパケットに対して、queueを指定するアクション（set-queue）が追加されています。queue configurationはminimum-rate queueのみと書いていますが、これは、priority queueとの組み合わせを意味します。これはバージョン1.2の仕様書の「A.3.5.6 Queue Statistics」の文中に ”The queue_id field identifies one of the priority queues,...” と書かれていることからうかがえます。set-queueアクションはoptionalなので、スイッチがサポートしていない可能性もありますが、仕様として記載されている点は心強いです。
次に2.cの機能ですが、これは1.3からサポートされているmeterを使って実現できます。meterについては、「5.7 Meter Table」に記載がありますが、この記載（以下に抜粋）を見るとDiffServを意識した機能であることがうかがえます。
5.7 Meter Table
A meter table consists of meter entries, defining per-flow meters. Per-flow meters enable OpenFlow to implement various simple QoS operations, such as rate-limiting, and can be combined with per-port queues (see 5.12) to implement complex QoS frameworks, such as DiffServ.
具体的には、レートを越えたパケットをdropするrate-limitingのアクションを使います。DiffServではpolicingと呼ばれる機能です。このアクションもoptionalなので、2.bと同様、スイッチがサポートしていない可能性があります。
以上、机上検討ですが、OpenFlow 1.3以降の機能を使って、QoS保証、具体的にはBandwidth Brokerの実現について期待した通りの感触をつかむことができました。
OpenFlow へのさらなる期待
 DiffServがRFCとして定められた当時は、OpenFlowのようにフロー毎の経路設定を自由にすることができず、static routingを使って経路を固定化するか、MPLSのラベルを使ってコントロールするしか方法はありませんでした。自律分散の原理で動作するインターネットのルーティングとDiffServの持つmanaged networkのコンセプトが相容れない状況にあったと言えます。この点、OpenFlowは最初からmanaged networkのコンセプトを持つため、QoSの実現はよりやりやすくなったと言えるでしょう。
DiffServがホットトピックであった時代には、セキュリティとQoSのためのルールを一元管理するポリシーフレームワークという概念も提唱されました。加えて、ネットワークサービスにおける SLA（Service Level Agreement）も規定され、セキュリティ＋QoSがネットワークサービスの持つ付加価値として位置づけられました。
その後、QoSは実現の困難さと、ネットワークの広帯域化とオーバープロビジョニングにより細かな帯域制御自体が不要になったことで、技術的には停滞してしまいます。しかしながら、DiffServが生み出したポリシーフレームワークや SLA の枠組みは、QoSがOpenFlowによって実現された場合には、必ず必要となる技術になります。期待の大きいOpenFlowですが、コントローラ自体はまだ単機能で、ライブラリとして使えるモジュールの拡充とその枠組の策定が望まれています。今後、OpenDaylight のようなフレームワーク策定の動きもどんどん出てくることでしょう。時代は繰り返すといいますが、過去に埋もれた技術が新たな形で活用されることに期待したいものです。

References