Northdound APIは、Software-Defined Networkにとって重大な欠落だ

Northbound APIがSoftware-Defined Network/OpenFlowの分野で新しい議論の対象になっていることを、1つ前の記事「SDN/OpenFlowの新しい課題：Northbound APIとは何か？」で紹介しました。

現在のNorthbound APIの状況をよく伝えているのが、米国でネットワーク構築のコンサルタントや教育を行っているIvan Pepelnjak氏のブログ「ipSpace.net」にポストされたエントリ「SDN CONTROLLER NORTHBOUND API IS THE CRUCIAL MISSING PIECE」（Northdound APIは、Software-Defined Networkにとって重大な欠落だ）です。

1カ月ほど前に書かれたこのエントリでは、Northbound APIへの取り組みがまだ実質的にほとんど始まっていないことを伝えています。本人の許可を得て、翻訳を紹介しましょう。

SDN CONTROLLER NORTHBOUND API IS THE CRUCIAL MISSING PIECE

（2012/9/27 Ivan Pepelnjak）

PerlあるいはPython、Ruby、JavaScriptなどで、サーバ上の面倒な処理の自動化スクリプトを書こうと考えてみてほしい（さまざまなベンダ製のルータやスイッチとLinux/BSDなどが関連しているはずだ）。その場合でも、ベンダの違いによって実装が面倒になるといったことは起きないはずだ。

スクリプトのインタプリタはOSが提供する多くのAPIに依存している -- プロセス関連のAPIからファイルシステムAPI、メモリマネジメントAPI、ほかにもあるだろう。

もしも現在、こうしたAPIがすべて標準化されていないとしたらどうだろう（相互に互換性のない各種方言を持ったCISCO IOSで使われているTclが思い浮かぶ）。これがSoftware-Defined Networkの世界でいま直面している事態だ。

もしもOpenFlowをネットワークにおけるx86命令セットと例えるなら（実際にはそれはUCSD Pascalのp-codeマシンに似ていると思うが、その話は今日はやめておこう）、私たちがやりたいのは、たとえばネットワークの混雑時間帯にはテープバックアップのトラフィックを別のパスへ切り替えるといった単純なスクリプトを書きたいといったことであり、そのときに必要となるのはネットワークのトポロジを取得し、ネットワーク内の経路を生成し、トラフィックに対してその経路で転送されるようなForwarding Equivalence Class (FEC) を設定できるような標準化されたAPIである。

手短に言えば、これが求められている「SDN Controller Northbound API」である。

Nothbound APIは標準化されていない

しかし悪い知らせがある。だれもこの標準化作業に着手していないということだ（Brad Casemore氏が素晴らしいまとめ記事を書いているので、ぜひ文中のリンク先も含めて読んでほしい）。

IBM PCの初期のゲームソフトを覚えているだろうか？ ひとつもMS-DOSを使っていないものだ。フロッピーディスクでブートする組み込みソフトウェアのようなもので、ハードウェア全体を支配してしまう。これがまさにSDNの世界で起きていることだ。

「Flowvisorを忘れてないか？」という指摘はしないでいただきたい。これは個別のOpenFlowコントローラ群に実際のハードウェアをスライスして割り当てるものだ。しかしFlowvisorをこの問題解決に持ち出すのは、Xen（あるいはKVMやESXi）を、前述した組み込みソフトウェアのようなゲームソフトに対して仮想マシンを割り当てるようなものだ。ネットワークのトラフィックを制御したい通常の用途にはもっと高いレイヤを持ち出すべきではないかな？

また「それぞれのSDNコントローラだってAPIを持っているではないか？」という指摘も当たらない。NECやBigSwitch Networksのようなスタートアップはネットワークオペレーティングシステム的なものを開発し、それを使ってネットワークをプログラミングすることもできるようだが、その2つを比べればまったく似てもいないのだ。

かつてインテル8088プロセッサの上に数々のOSが移植されたことも思い出す。2、3のOSで動くようにするだけでも多大な移植の労力をかけなければならなかった。

なぜこうなのか、理由を推測してみる

この状況にはもっともな理由がありそうだ。4つほど推測してみた。

• 本当にOpenFlowについて興味を持っている少数の人は、Google世界の人だから（NiciraがOpenFlowだけでMAC-to-IPマッピングをvSwitchで実現している）
• デベロッパーは誰かほかの人が作った標準ライブラリやAPIを使いたがっているから
• Linux的ソリューションを作ることにだれも興味を持っていない。誰もがベンダーロックインを最大化しようとしているから
• 今の時点では、まだ誰もなにをすべきか理解できていないから

現実はこれらが混在したものなのだろう（ほかの理由もあるかもしれない）。いずれにせよ基本的な状況は変わらない。現時点までに（例えばSQL-86のような）マルチベンダのSDNコントローラを制御できるようなしっかりした標準APIは存在しないのだ。その代わりにCisco ONEやJunos XML APIや、ロックインされるかだ。

一方で私がCiscoやJuniperを利用したとして（そして私は両方のAPIで動作するようなアプリケーションのためのシンプルな抽象化レイヤを実装するとしても）、彼らが2～3年はこういう状況のままであることは間違いないだろうと思っている。