はじめに

みなさんは単にネットワークという言葉を聞くと、どのようなイメージを持たれるでしょうか。単純にパケットが通過するだけのケーブル的なイメージでしょうか。それとも、ロードバランスやパケットフィルタリングを行う箱のようなイメージでしょうか。

これまでのネットワーク機器はRFC（RequestFor Comment）などの標準で定義されたプロトコルに沿って動作し、ネットワーク機器を利用するユーザはメーカーが用意した記述ルールに従い設定を行うのが一般的でした。このような状況からネットワークは受け身でしか利用できないイメージが定着していると思いますが、次世代ネットワーク制御技術「OpenFlow[1]⁠」の登場により状況が変化しつつあります。

ネットワークをプログラムするOpenFlow

OpenFlowを用いればネットワークの動きをプログラムにより制御することができます。ネットワークの動きを自由にプログラムで記述可能ということは、既存のプロトコルの制約をまったく受けないことを意味します。ユーザはOpenFlowを利用することで何の制約もなく自分の思いどおりにネットワークをコントロールできます。

図1に従来のネットワーク機器では実現不可能なネットワークの構成例を示します。本来はVLAN（Virtual LAN）を用いないかぎり、図1のように1台のL2スイッチに同じIPアドレスを持ったサーバを複数台接続しても正常に通信できません。ところが、OpenFlowではこの構成でも正常に通信させることができます。　実現方法は簡単です。仕組みは後述しますが、IPアドレスが同じであっても送信先L4ポート番号[2]が異なる場合はL4ポート番号に対応したサーバにパケットを送信するようにネットワークをプログラムすればよいのです。

OpenFlowスイッチングコンソーシアム

OpenFlowは米スタンフォード大学を中心に2008年に設立された「OpenFlowスイッチングコンソーシアム」が提唱している次世代ネットワーク制御技術です。コンソーシアムへの主要参加メンバーは米スタンフォード大学、CiscoSystems、Hewlett-Packard、Juniper Networks、NECであり、OpenFlowへの注目が高まる中、コンソーシアムに参加する企業／大学は増加しています。米スタンフォード大学が推進するCLEAN SLATEプログラムを通してOpenFlowに関与している企業はWebサイトで確認できるだけでも10社[3]にのぼり、注目度の高さが伺えます。

コンソーシアムではOpenFlowに関する標準化を行っており、すでにOpenFlowバージョン1.1の策定が完了しています。コンソーシアムでは標準化に合わせて、OpenFlowの実装も積極的に進めています。実装はWeb上でオープンソースとして公開されています。

ONF（Open Networking Foundation）

これまでOpenFlow の標準化はOpenFlowスイッチングコンソーシアムを中心に進められてきましたが、OpenFlowの実用化をより促進するため2011年3月21日にONFが発足しました。ONFはSDN（Software-Defi ned Networking）の推進を目標に掲げる組織で、SDNの中核技術がOpenFlowになります。今後、OpenFlowの仕様策定はOpenFlowスイッチングコンソーシアムに代わりONFが実施します。

ONF のボードメンバーはドイツテレコム、Facebook、Google、Microsoft、Verizon、Yahoo!であり、大規模データセンターや大規模WANを保有する企業が中心です。初期メンバーもメジャーな企業が多く、Broadcom、Marvellといったネットワーク機器チップベンダ、Brocade、Ciena、Cisco Systems、Dell、Ericsson、Force10、Hewlett-Packard、IBM、Juniper Networks、NEC、Netgear、Riverbed Technologyといったネットワーク機器ベンダ、Citrix、VMwareといった仮想化ソフトウェアベンダ、NTT（NTTデータ含む）といった大規模WAN保有企業の計17社が参加しています。世界のメジャーベンダが中心となって設立された本組織は今後ネットワークのオープン化を強力に推進していくと予想されます。Data Center Knowledgeの記事にもONFについての話があります。記事ではAmazonの研究者が「OpenFlowによりネットワーク構築サービスのビジネスモデルは崩壊するだろう」と述べています。

各社の取り組み、動向

ネットワーク機器を開発するメーカーもOpenFlowに関心を寄せています。NECは2011年3月9日よりOpenFlow対応製品の販売を開始しました（出荷は5月上旬⁠）⁠。アメリカのベンチャーでもOpenFlow対応スイッチの販売が開始されています。

Brocade Communications Systems、CiscoSystems、Hewlett-Packard、Juniper Networks、Netgearといった主要ネットワーク機器ベンダはOpenFlowスイッチのプロトタイプを開発中です。

OpenFlowの導入を積極的に検討している企業もあります。Googleは自社が保有するデータセンタを高度に効率化する方式の一つとしてOpenFlowに興味を持っているようです。Googleはオープンソースで提供されている仮想スイッチをOpenFlowバージョン1.1に対応させるプロジェクトに参加しており、実際に実装の支援も行っています。筆者が属するNTTデータもOpenFlowによるネットワーク設計効率化や運用自動化を目指し研究開発に着手しています。

OpenFlowが注目される背景

OpenFlowが注目される理由を説明するには、ネットワークの仮想化を説明する必要があります。ネットワークの仮想化という言葉に正式な定義はありませんが、世の中では「1台のネットワーク機器を複数の機器に論理分割する」「⁠複数のネットワーク機器を1台のネットワーク機器として扱えるようにする」という意味で利用されることが多いようです。

クラウドが普及するにつれてネットワークの仮想化が重要視されるようになりました。図2は1つのプラットフォームを複数のテナントで共用する例です。ネットワーク機器ごとに仮想化の設定が必要となるため、設定ミスの増加が懸念されます。また、仮想化の世界では設定ミスがプラットフォームを共有する他社に影響を及ぼす可能性があり、設定変更を従来よりも慎重に行う必要があります。

仮想化のもう一つの特長に「仮想サーバが物理サーバ間を移動する」があります。そして、仮想サーバの移動に合わせてネットワーク側の設定も変更する必要があります（図3⁠）⁠。仮想サーバが移動した場合、最低でも仮想スイッチやL2スイッチのVLAN設定を変更する必要があります。他にも仮想スイッチのQoS（Quality of Service）設定の変更や、移動前に仮想スイッチに蓄えられたトラフィックなどの統計情報をクリアし、移動先の仮想スイッチに付け替える処理が必要です。

クラウド利用者は意識することは少ないと思いますが、クラウド運用者には従来よりも複雑な保守／運用が要求されています。このようにネットワークの仮想化は多くの課題を抱えていますが、これらの課題の大部分を解決可能なOpenFlowに注目が集まっています。

OpenFlowの基本動作

ここからはOpenFlowの基本的な動作について説明します。OpenFlowは「OpenFlowスイッチ」と「OpenFlowコントローラ」の2種類で構成されます。OpenFlowスイッチは自身に投入されたフローエントリと呼ばれるルールに沿って動作します。OpenFlowコントローラはOpenFlowスイッチにフローエントリを書き込みます。OpenFlowスイッチとOpenFlowコントローラ間は「OpenFlowプロトコル」により情報をやり取りします。OpenFlowスイッチとOpenFlowコントローラ間はTCP/IPで通信します。よってスイッチとコントローラ間にL2スイッチなどのネットワーク機器が存在しても問題ありません。

より具体的なイメージを持っていただくため、図を用いて説明します。図4はOpenFlowを動かすための最小構成の例[4]です。図4で示すとおり、OpenFlow スイッチはOpenFlow コントローラから投入されたフローエントリを保持しています。サーバ1はOpenFlowスイッチの1番L1ポートに接続されており、サーバ2は2番L1ポートに接続されています。管理L1ポートはOpenFlowスイッチがOpenFlowコントローラと通信を行うために利用する特別なL1ポートです。図4を用いて、いくつかの通信パターンを説明します。

サーバ1からサーバ2にHTTPリクエストを送信する場合

サーバ1からサーバ2上で動作するWebサーバに対してHTTPリクエストを送るパターンを考えてみます。HTTPなので送信先L4ポート番号は80番です。OpenFlowスイッチはサーバ1から送信されたHTTPリクエストを受け取り、そのパケットがフローエントリのヘッダフィールドにマッチするか調べます。HTTPリクエストはサーバ1から送信されているので「L1ポート番号＝1」になります。また、送信先ポート番号はHTTPなので「送信先L4ポート番号＝80」になります。以上により、このパケットは1番のフローエントリ（図4でNoが1であるフローエントリ）にマッチすることがわかります。1番のフローエントリのアクションを見ると2番ポートからパケットを送信すればよいとわかるので、OpenFlowスイッチはHTTPリクエストをサーバ2に転送します。

サーバ1からサーバ2に対してPingを送信する場合

続いて、サーバ1からサーバ2に対してPing（ICMPエコー）を送信するパターンを考えてみます。サーバ1から送信されたパケットなので「L1ポート番号＝1」になり、Pingなので「プロトコル種別＝ICMP」になります。以上により、2番目のフローエントリにマッチすることがわかり、OpenFlowスイッチはアクションに書かれたとおりパケットを破棄します。

サーバ2からサーバ1に対してPingを送信する場合

それではサーバ2からサーバ1にPingを送信した場合はどうなるのでしょうか。サーバ2から送信されたパケットなので「L1ポート番号＝2」となりますが、OpenFlowスイッチは「L1ポート番号＝2」にマッチするフローエントリを持っていません。この場合、OpenFlowスイッチは管理L1ポート経由でOpenFlowコントローラに受信したパケットをどのように制御するべきか問い合わせます。問い合わせを受けたOpenFlowコントローラはOpenFlowスイッチにフローエントリを新たに書き込み[5]⁠、パケットをどのように制御するかOpenFlowスイッチに指示します。

OpenFlowスイッチにどのようなフローエントリを書き込むかはすべてプログラムにより自由に制御できます。OpenFlowスイッチはフローエントリが書き込まれると、有効期限が切れるまでその情報を保持し続けます。よって、再びサーバ2からサーバ1にPingが送信された場合、OpenFlowスイッチはOpenFlowコントローラに問い合わせることなしにパケットを制御できます。

ヘッダフィールドに設定可能な条件式

図4の例ではヘッダフィールドに2つの条件を指定していますが、実は最大で12種類の条件を指定可能です。この12 種類の条件のことをOpenFlowでは12タプルと呼んでいます[6]⁠。

表1に12タプルの一覧を示します。それぞれの条件の詳細説明は避けますが、Ethernet やTCP/UDPでよく利用されている値になります。

アクションに設定可能な値

アクションにはパケットをどのように処理するかを記述可能です。表2にアクションに指定可能な代表的な値を示します。1つのフローエントリに複数のアクションを指定することも可能です。

実際にヘッダフィールドに設定する値

実際にヘッダフィールドに指定する値は図4で挙げた例とは若干異なります。図4では誌面の都合でヘッダフィールドを次のように指定しました。

• L1ポート番号=1
• 送信先ポート番号=80

正確に次のように12タプルを用いて設定します（ANYは「どのような値が格納されてもよい」という意味になります⁠）⁠。

故障時の動作

隣接のOpenFlowスイッチが故障しパケットを故障前と同様に転送できなくなった場合、OpenFlowスイッチはコントローラに新しい経路を問い合わせ、新しい経路でパケットを転送します（OpenFlowコントローラが故障前と同様の送信先にパケットを転送するように実装されていることが前提です⁠）⁠。これはかなり強力な機構で、OpenFlowの世界ではスイッチを適当にメッシュ状に接続するだけでスイッチの3重化や4重化が簡単に実現できることを意味します（詳細は今後の連載で紹介する予定です⁠）⁠。

OpenFlowコントローラの故障にはコントローラの2重化により対応することが可能です。運悪くコントローラが2台とも故障してしまった場合は、故障前にOpenFlowスイッチに保存されたフローエントリに沿ってパケットが転送されます。

まとめ

今回はOpenFlowの動向や基本的な動作について説明しました。各ベンダからOpenFlowスイッチとOpenFlowコントローラがセットで発売されることが多いと思いますが、スイッチとコントローラ間は標準化されたプロトコルで通信するため、別々のベンダで構成しても問題なく動作すると期待できます。本稿を読むとOpenFlowはコントローラを自分で実装しないと使えないと勘違いされるかもしれませんが、それは違います。OpenFlowは他社製品を購入し利用することも、自社で機能拡張することも可能です。

OpenFlowで注目していただきたいのは、MACアドレスやIPアドレスをまったく使わずにパケットを転送可能な点です。OpenFlowの世界では従来のL2やL3といったOSI参照モデルの概念が崩壊し、ネットワークは完全にプログラムにより制御される世界になります。特に説明はしていませんが、OpenFlowを用いれば従来煩雑であったリンクアグリゲーションやVLAN 設定からも解放されます。また、OpenFlowを高度に応用すれば従来では考えられないような機能も実現できます。

次回はOpenFlowを高度に利用することで実現できる新しい世界について説明します。