Agile Cat — in the cloud

VMware の考える SDN は、OpenFlow だけでは完成しない

Posted in .Selected, OpenFlow, SDN, VMware by Agile Cat on April 25, 2012

VMware isn’t going to let network virtualization pass it by
Stacey Higginbotham Apr. 11, 2012

_ Gigaom

VMware teamed up with Stanford and Berkeley on Tuesday to create an industry consortium around software defined networks, called the Open Networking Research Center. The company, famous for hypervisors that virtualize servers isn’t about to watch while companies attempt to build the same disruption in networking. The consortium counts CableLabs, Cisco, Ericsson, Google, Hewlett-Packard, Huawei, Intel, Juniper, NEC, NTT Docomo, Texas Instruments and VMware as its founding sponsors.

この火曜日に VMware は、Open Networking Research Center という SDN に関する業界コンソーシアムを立ち上げるために、Stanford および Berkeley とチームを構成した。 いくつかの企業は、ネットワークにおける急激な刷新(破壊)を共有しようと試みるが、サーバーの仮想化において、つまりハイパー・バイザで実績を積み上げてきた同社は、そのようには見ていないようだ。なお、このコンソーシアムは、CableLabs/Cisco/Ericsson/Google/Hewlett-Packard/Huawei/Intel/Juniper/NEC/NTT Docomo/Texas Instruments/VMware を、そのファウンディング・スポンサーとして数える。

Much as server virtualization abstracts the hardware for the software that runs on it, allowing people to put different virtual machines on top of one server, virtualizing the network abstracts the cables and ports from the demands of the applications. But that’s not enough. To really achieve the flexibility that webscale and cloud companies demand, the network must be both virtualized and programmable.

サーバーの仮想化はハードウェアを抽象化し、その上でソフトウェア走らせるようにする。 そして、その数だけの仮想マシンを、1台のサーバー上に配置できるようにする。 さらに、ネットワークの仮想化は、アプリケーションの要求に応じて、ケーブルとポートを抽象化していく。 しかし、それでは十分と言えない。 Web スケールとクラウド・カンパニーが必要とする柔軟性を、ほんとうの意味で達成するには、仮想化とプログラマブルという要因をネットワークに加えなければならない。

The current enabler for this shift in networking is OpenFlow, a protocol developed out of Stanford and championed by a group formed last March called the Open Networking Forum. Many of the companies that have joined the VMware at the ONRC are also members of the ONF, including VMware. OpenFlow is a means to separate the intelligence associated with moving packets around the network with the gear that does the moving. At that point the intelligence can run on commodity servers, a factor that was seen as bad news for Cisco, Juniper and other networking companies which may see their margins drop and profits erode.

現時点において、このネットワークのシフトを可能にする存在は、Stanford で開発されたプロトコルの OpenFlow となる。それは、この 3月に組織化された、Open Networking Forum というグループにより支持されている。 ONRC で VMware と行動をともにする数多くの企業は、この ONF のメンバーであり、また、VMware も参加している。 OpenFlow とは、パケットを転送する装置を用いて、ネットワーク上を飛び交うパケットから、インテリジェンスを分離するための手段である。 その点において、このインテリジェンスは普及品サーバーで動作するため、Cisco や Juniper などのネットワーク・デバイス会社にとって BAD ニュースとなる。 なぜなら、それらの企業はマージンが下がり、利益が圧迫されるからだ。

imageAllwyn Sequeira, CTO and VP for security and networking for VMware says that the creation of the ONRC is designed to push the concepts of software defined networks in general rather than the OpenFlow protocol. He said an SDN requires three elements: a controller that manages the networking gear; the controller protocol fused to control the devices (this may not be OpenFlow); and the apps on top of the controller that direct the network.

VMware の CTO であり、 VP for Security and Networking でもある Allwyn Sequeira は、OpenFlow プロトコルというより SDN のコンセプトをプッシュするところに、ONRC を結成した意味があると発言している。 SDNを構成するには、① ネットワーク・ギアを管理するコントローラおよび、② いくつかのデバイス(OpenFlow 非対応も含む)を制御するために結合されたプロトコルのコントローラ、そして、③ コントローラを介してネットワークを操作するアプリケーションという、3つの要素が必要になると彼は言う。

And he notes that OpenFlow adds the critical element of programmability to networking, likely residing in the controller with other protocols, but the creation of a software defined network doesn’t need it. He points to VMware’s own firewall and load balancing products as well as its VXLAN and other networking software as an example.

また、OpenFlow などのプロトコルを用いる既存のコントローラには、ネットワークをプログラミングするための重要な要素が加えられているが、それらが SDN の作成において必要とされることはない、彼は指摘している。 なぜなら、VMware のファイヤー・ウォールやロード・バランシングのプロダクトに加えて、VXLAN などのネットワーク・ソフトウェアが、その例として挙げられるからだと、彼は言う。

VMware’s networking products.

That’s a common argument from the industry, with folks from Juniper and Cisco pointing to their existing fabrics and products as an example of network virtualziation. So the key for the ONCR and the industry moving forward seems to be about how to make SDNs programmable since they already exist. Sequeira says this requires OpenFlow.

それは、仮想ネットワークの例として、現存のファブリックとプロダクトを指し示す、Juniper や Cisco のテーマというより、この業界における共通のテーマとなる。 この業界と ONCR には、すでに存在する資産があるため、SDN をプログラマブルにする方式が重要となり、また、それを模索しながら前進していくと思われる。 そして Sequeira は、そのために OpenFlow が必要になると発言している。

“We had a complete SDN stack with no OpenFlow and it was good enough for almost all the things that customers wanted to do,” Sequeira said. “There is the virtualization of the switches and firewalls and none of that requires OpenFlow. However, to program it requires OpenFlow even though even a little of that can be done without it.”

「 私たちは、OpenFlow に頼ることなく、完璧な SDN スタックを積み上げており、それは、ほとんど全ての顧客の要求に対応できる。 スイッチとファイアーウォールの仮想化は存在しており、そこでは、少しも OpenFlow を必要としない。 しかし、それをプログラムするためには、すべてにおいて必要というわけではないが、OpenFlow が要求される」と Sequeira は発言している。

And while Sequeira recognizes the importance of OpenFlow, he doesn’t see some wholesale migration to OpenFlow-only networks. Current networking software and gear will work with OpenFlow but will not solely use the protocol. Which, given the statements by Urs Hölzle, SVP of technical infrastructure at Google, that there is no easy way for OpenFlow to communicate with other network protocols, have me thinking that we’re going to need more efficient ways to communicate from one network protocol to OpenFlow.

そして Sequeira は、OpenFlow の重要性を認識する一方で、いくつかの Wholesale は OpenFlow-ony ネットワークへ移行しないだろうと見ている。 最新のネットワークを構成するソフトウェア/ギアは、OpenFlow に対応するだろうが、そのプロトコルだけを使うわけではない。 Google の VP of Technical Infrastructure である Urs Holzle のステートメントを前提にすると、OpenFlow と他のネットワーク・プロトコルを連携させるための、容易な方式は無いということになる。 つまり、こうした現実から生じるものとして、他のネットワーク・プロトコルから OpenFlow にコミュニケートするための、より効率の良い方式が求められるようになってくる。

So the biggest battle in SDNs looks like it will be for the controller, which companies such as IBM, Nicira and Big Switch have developed. The question is: will OpenFlow be the lingua franca between rival controllers or will each strive to create it’s own proprietary network — programmable, running on commodity hardware, but still a fundamentally locked ecosystem?

したがって、SDN における最大のバトルは、IBM/Nicira/Big Switch などが開発を進めている、コントローラに関するものになるだろう。 残される疑問は、以下のとおりである。 まず、OpenFlow は、ライバルであるコントローラ間の共通語になる気があるのか? それとも、それぞれのプロトコルは、自身によるプロプライエタリ・ネットワークを構築するために競い合うのか?つまり、プログラマブルであり、コモディティ・ハードウェア上で走るにしても、基本的にはロックインされているエコシステムに過ぎないのか?

Related research and analysis from GigaOM Pro:


TAG indexこの辺りの、OpenFlow をめぐる議論が、これから活発になってくるのでしょうね。 以前にポストした「OpenStack における SDN コネクションを探求する」にも、似たような記載がありました。 これは、OpenStack に OpenFlow を取り込む場合の記事ですが、VMware の指摘と同じことが語られています。 前後編で、ちょっと長いですが、お薦めのコンテントです。 ーーー __AC Stamp 2

したがって、OpenStack における Quantum と OpenFlow は、機能的に補完関係にあると説明されている。 ただし、Urquhart が指摘するように、OpenFlow の位置づけは、Quantum 抽象概念上のプラグインから利用できる、1つのメカニズムに過ぎない。 その点について、心に留めておいてもらいたいのは、OpenStack wiki で詳細に記述されるように、「OpenStack ネットワークにプラグインされる先進的なネットワーク・サービス(オープン・ソース/クローズド・ソース)」を構築するために、また、先進的なネットワーク機能を導入する、新しいプラグインの開発を容易にするために、Quantum  の利用が可能だという点だ。



Google と OpenFlow と SDN について本音を語ろう – Urs Holzle
Google 先生の OpenFlow 講座 – DC 間接続を低コストで達成するには
OpenFlow 1.2 が ONF の評議会で承認された – NTT Com も委員に
Juniper がデベロッパーに対して、OpenFlow ソースコードを提供し始めた
OpenFlow 関連ポストへのリンク集(20本強)


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: