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ロードマップとして統合されるのではないだろうか。

あわせて読みたい

ハードウェア OpenFlow Software-Defined Network ネットワーク




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

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

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

最新記事10本