24th - OF-PI と計測装置

僕は 21 日の記事で、誰がスイッチ ASIC のドライバをどのようにして書き、最終的にどのようにオープンになっていくのだろうか、と書いた。しかしこの ASIC ドライバについて全く異なるアプローチがある。OpenFlow 2.0 的アプローチ、とでも言うべきものだが、今は ONF でちゃんとした名前がつけられている。OF-PI (A Protocol Independent Layer) だ。

ONS2014

3月に行われた ONS2014 の幾つかのセッションで僕は OpenFlow 2.0 の話を聞いた。しかし内容が良く分からなかった。具体的には Prelary session の一つ、Jennifer Rexford のセッションだ。ここで P4 のことを少し聞いたが、とてもではないが分かる内容では無かった。たぶん今聞いても分からない自信がある。

Nick のスピーチ

9月、ONF Member Workday に行われた Nick のビデオがある。これが恐らく分かりやすくその全貌を語っている。ONF の "Protocol Independent Forwarding" プロジェクトのページには、このスピーチのビデオ、その直前に出た OF-PI (A Protocol Independent Layer) 仕様 v1-1 とともに、概要がまとめられている。一読を勧める、が、まずビデオをざっと見るのが良いと思う。とても良い入り口となるだろう。

OF-PI

OF-PI のアイディアはプロジェクト・ページの Figure 2 に集約されている。 つまりスイッチ ASIC を直接プログラミングするのではなく、スイッチハードウェアに対して抽象化層を一段設けよう、という提案だ。
これを IR (Intermediate Representation) と呼ぶ。


source: ONF, https://www.opennetworking.org/protocol-independent-forwarding

これまでスイッチ ASIC は、かなり低レベルなプログラミングをチップそれぞれに独自の SDK を用いてプログラマが直接プログラミングしていた（はずだ）。OF-PI では、スイッチ ASIC はいつまでもスイッチ ASIC だとしても、今後は IR を設けて、その上下それぞれにコンパイラを用意しようとしている。
つまり（図中の）下層つまり Back-end コンパイラは抽象化層から ASIC それぞれの設定情報（命令セットもあるだろう）を生成する。上層つまり Front-end コンパイラは高級言語によって抽象化されたスイッチをプログラミングする。
構造的には「下層」によって ASIC ごとの（設定情報の）差異を吸収し、「上層」によって OpenFlow 1.x なり、通常の L2/L3 スイッチなりの処理、つまりプロトコル処理を記述しよう、という設計だ。上層の記述言語については P4 が挙がっている。重要なのはプロトコル処理は全て P4 によって記述されており、スイッチ自身はプロトコル処理について何も意識しない点だ。どんなプロトコルであったとしても、スイッチは P4 がそれを書ける限り、プロトコルに依存せずパケットを処理することができる。これが Protocol Independent の意味だ。
そして下層では、スイッチ ASIC がどのようなハードウェアリソース（機能と容量）を持っているか、初めに上層のコンパイラに通知することになっている。たとえば L2 マッチングテーブルを何エントリぶん持っているか、といったことだ。するとその情報に合わせて、上層のコンパイラは適切な組み合わせで ASIC の設定情報を生成してくれる。
上層でもまた「自分の用途では L2 のエントリにそんなに割く必要は無い、TCAM は L3 処理に使おう」といったことが可能になる。理屈の上では、これで ASIC の機能を充分に活かし、ユーザの必要に応じた最適のセットアップができあがる、ということになる。もう手でドライバをコツコツと書き続ける必要は無い。標準的で、一般的な用途でおよそ性能が出るバランスなどにこだわらず最適化できる。

性能問題

僕はこのアイディアをとても気に入った。が、一つ問題がある。 最適化が本当に進んでしまうと、上層、下層のコンパイラのバージョン、ASIC のモデル、P4 によるプロトコル処理でのリソース配分のポリシーの差などの組み合わせによって、各サイトで全く異なった機能・性能のスイッチが使われることになる。
するとある組み合わせでは性能が出ていた OpenFlow ネットワークシステムが、ある組み合わせでは突然に遅くなってしまう、ということが充分にありうる。特にハードウェアリソースの割り当てが足りず、その処理がソフトウェアにフォールバックしたような場合は 1000 倍も遅くなることが普通に生じる。
これが分からぬまま自分のサイトに新しい P4 プログラムで generate したスイッチファームウェアを突っ込もうとするネットワーク管理者は居ない。
そこで自分たちが必要とするフロー処理設定を行った時に、どのような性能が出るか実際に計測する仕組みが必要だ。それで極端に性能が出ないところがあれば予めチェックできるように。
安価な計測装置の必要性 もちろん IXIA や Spirent を買えば可能なのだが、そんなものを各所のネットワーク管理者が買えるはずがない。つまり買える価格の、しかし 10G 領域で間違い無く処理能力が（オンサイトで）測れるシステムが必要になる。
そう思っていま正にそのような装置を開発している。1月に米国に行くので、その時に幾らかの人にアイディアを聞いて貰って、もう一段進めてみたい。

おまけ："Protocol Independent"

"Protocol Independent" と言えば、Nick の ONS2013 セッションを思い出す人も多かろう。彼は本当にこれをずっと追い続けている。会ってみたい。

References