SDN/OpenFlowの新しい課題:Northbound APIとは何か?

2012年10月22日

いまSoftware-Defined Network/OpenFlowの新しい課題として、Northbound APIの標準化をどうするのか? という議論が持ち上がってきています。スイッチを制御するプロトコルとしてOpenFlowという標準がOpen Network Foundationによって作成され、普及しつつありますが、それを実際にアプリケーションから制御するには、何らかのAPIが必要となります。

そのAPIがネットワーク機器ベンダやOpenFlowコントローラごとに固有のものとして定義されてしまったら、OpenFlowが標準化されたとしても意味がないのではないか? その部分も標準化されるべきではないか? という議論です。この、ネットワークをソフトウェアで操作するためのAPIが「Northbound API」と呼ばれています。

Brent Salisbury's The Northbound SDN API - A Big Little Problem

そのNorthbound APIとは何か? を解説した、米国で州立大学のネットワークアーキテクトであるBrent Salisbury氏のブログ「NetworkStatic」に今年6月にポストされたエントリ「The Northbound API- A Big Little Problem」(The Northbound API:小さな大問題)を、本人の許可を得て翻訳しました。

The Northbound API:小さな大問題

(2012/6/10 Brent Salisbury)

Software-Defined NetworkにおけるNorthbound APIとは何か? Northbound APIは、アプリケーションからSDNコントローラを制御できるAPIだ。

コントローラはそこからネットワーク機器に対してOpenFlowプロトコルを使ってフローテーブルなどを制御し、ネットワークを操作する。この部分を私はSouthbound APIと呼ぶことにしよう。Software-Defined Networkの領域において、コントローラは接着剤(Glue)のようなものだ。

長期的に見てこれは今のx86サーバの状況に似て、スケールアップやスケールアウトのための新しいリソースプールのようなものとなるだろう。ここではそのOpenFlowコントローラにおいて3つの基本的要素を挙げてみた。

SDNコンポーネント

  1. データパス(経路)をネットワーク機器に対してOpenFlowプロトコルを用いて、マッチ/アクション/カウントをベースにしたルールで指示
  2. エコシステム全体を統合するため、ネットワーク機器に対してSouthbound APIを提供
  3. エコシステムにアプリケーションをアタッチするためにNorthbound APIを提供
fig

時期が重要

APIについては、Webサイトをみるかぎり2つのOpenFlowプロジェクトが活発なようだ。それはNOX/POXFloodlightで、それぞれNicira陣営とBigSwitch陣営から登場したもので、どちらも非常に優秀なメンバーを抱えている。

私はどちらかといえばFloodlight APIのほうがやや好ましいと思っている。FloodlightのJSON/REST APIはHTTP GET/POST/DELETE方式の分かりやすい機能を提供している。これまでの技術に慣れたエンジニアにとって、プロビジョニングやトラブルシューティングしやすい環境を作るには、うまく抽象化されたAPIは重要だ。特にネットワークにおいては、くだらないコードを相手にするのが好きなエンジニアはいないだろう。少なくともNOX APIはGoogleで検索した限りそんな感じであった。

Art Fewellが昨年行われたOpen Network Summitでマーチン・カサド氏にインタビューを行っている。マーチンはOpenFlowの生みの親の一人であり、Open vSwitchの開発者であり、そして彼と話して思うのは彼はコミュニティの大いなる信奉者である。それは彼の知性だけでなく、おそらく彼の自我といったものがより重要であり、それが彼を多くの卓越したプロジェクトの先端に関わらせているのだと思う。

マーチン・カサド氏はインタビューでこう言っている。

私の個人的な意見だが、いまは1つのレイヤに特に集中すべきときだと思っている。OpenFlowが登場してさまざまなハードウェアやマルチベンダに対応し、それによって良好なエコシステムが出来ていくのをとても興味深く見ているが、こうしたことが起きている中で、私たちはそのパズルの1つに集中すべきだと考える。

そこにはネットワークに対するより高度なやりとりを求める声もあるが、私にとってそれがNorthboudn APIかどうかはまだ明確ではないし、ネットワークオペレーティングシステムの上にくるものが何か、それがどのように見えるのかも明確ではない。まだ全く未成熟なものなのだ。

私はOpenFlowをBIOSのようなものだと見ている。ハードウェアと対話するための独立したうまい仕掛けだ。もしこれがうまくいけば非常に大きな成果であり、そのときにはそれに続くものが出てくるはずだ。

fig

ベンダに期待することもある

まもなくNorthbound APIについて一貫性のある統合されたものが登場するとか、まもなく驚異的なアプリケーションが登場して一大市場が開かれるとか、コミュニティが、複雑なレイヤなしにオープンでフレキシブルな標準をうまく設定できるといったことはないだろうと思う。

あるいはシスコとジュニパーが協力してビジョンを共有するといったことは期待していない。残念ながら、個人や組織の利益の追求は、アイデアの共有よりもつねに優先してしまうのだから、私はむしろどこかのベンダがこの欠落を素早く補完するのではないかと期待している。

来週にはCisco Live USとInterop Japanが行われる(訳注:このブログは2012年6月に書かれた)。ここで何らかのSDNに関する前向きな発表があるのではないかと期待する。業界のビッグプレイヤーがこれに関わっていくことを期待するが、彼らはNorthbound APIに本格的に取り組むことはないかもしれない。というのも、そういったアプリケーションとの連係部分は彼らにとって囲い込みの非常に大事な資産だからだ。

しかしうまくいけば、それは本当に革新的なソフトウェアとなるようなアプリケーションの開発が始められるような、コミュニティによって支持され、安定したRESTful/JSON APIロードマップとして統合されるのではないだろうか。

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

カテゴリ サーバ / ストレージ / ネットワーク
タグ  Northbound API , OpenFlow , Software-Defined Network , ネットワーク


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

前の記事
見えてきた「ECMAScript 6」。JavaScriptの生みの親が書く「Harmony of Dreams Come True」


カテゴリ



Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

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



新着記事 10本


PR - Books


fig

fig

fig