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

2012年10月22日

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にとって重大な欠落だ)です。

SDN Controller northbound API is the crucial missing piece « ipSpace.net by @ioshints

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つほど推測してみた。

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

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

このエントリーをはてなブックマークに追加
follow us in feedly

タグ : Northbound API , OpenFlow , Software-Defined Network , ネットワーク



≫次の記事
クラウド基盤を継続的デリバリで毎週アップデートするRackspace。OpenStack Summit 2012
≪前の記事
SDN/OpenFlowの新しい課題:Northbound APIとは何か?

Loading...

Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています。
詳しいプロフィール


Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed



Publickey 最新記事 10本

Publickey Topics 最新記事 10本


PR - Books


fig

fig

fig

fig



blog comments powered by Disqus