SDNの基本動作とアジャイルな開発が可能なSDN実装、「Trema」：TremaでSDNを手のひらに（1）（2/2 ページ）

[＠SRCHACK.ORG，＠IT]

OpenFlowのバージョン

　OpenFlowは、当初のバージョン1.0から始まり、最新のバージョン1.3までいくつかの仕様がリリースされています。ここで単純に「新しいバージョンを選択すべきだ」と考えてはいけません。というのも、1.0、1.1、1.2、1.3（1.3.1）の各バージョンで互換性が考慮されたプロトコルではないからです。

　従って、ユーザーがOpenFlowを利用して実現したい内容に基づいて、利用するバージョンを決めていく必要があります。例えば「グループ」を利用したい場合は1.1以降、「IPv6」を利用したい場合は1.2以降といった具合になります。

バージョン	機能
1.0	ベースと考えるバージョンなので省略
1.1	Multiple Tables Groups Tags : MPLS & VLAN Virtual ports Controller connection failure
1.2	Extensible match support Extensible 'set_field' packet rewriting support Extensible context expression in 'packet-in' Extensible Error messages via experimenter error type IPv6 support added Simplified behaviour of flow-mod request Removed packet parsing specification Controller role change mechanism
1.3	Refactor capabilities negotiation More exible table miss support IPv6 Extension Header handling support Per flow meters Per connection event filtering Auxiliary connections MPLS BoS matching Provider Backbone Bridging tagging Rework tag order Tunnel-ID metadata Cookies in packet-in Duration for stats On demand ow counters
1.3.1	Improved version negotiation

　また、OpenFlowプログラミングフレームワークによっても、利用できるバージョンは制約を受けます。もちろん、ユーザー側が一からプログラムを書けば制限はありませんが、開発の効率化などを狙ってフレームワークを利用する場合は、どうしても制約を受けることになります。

　これ以外にもまだ、バージョンによる制約はあります。例えば、現時点では物理スイッチ側の対応が遅れている状況です。従って物理スイッチを用いる場合、利用できるバージョンはさらに限られることになります。

図5　プログラミングフレームワークのOpenFlowバージョン対応状況

　これら制限を考慮した上で利用するバージョンを選択していく必要がありますが、まずOpenFlowを初めていじる場合には、基礎となる1.0を利用するのがよいでしょう。

OpenFlow標準仕様の特徴をかいつまむ

　OpenFlowはとかく「複雑」だというイメージを持たれがちです。しかし、OpenFlowが仕様として定義しているのは、「OpenFlowコントローラとOpenFlowスイッチ間のプロトコル」と「フローエントリに対するOpenFlowスイッチのアクション」になります。

　OpenFlowの仕様については、openflow.orgで公開されている「OpenFlow Switch Specification」を確認することになります。公開されているPDFファイルの内容はわずか42ページで、非常に小さな仕様（＝簡潔な仕様）であることが分かるかと思います。

　このファイルをすべて読み解いていくのも良いですが、今回は、その中からOpenFlowをいじる時に使う要所をかいつまんで紹介します。

　OpenFlowの動作は、以下のようにまとめることが可能です。

1. OpenFlowスイッチにアクション方法の分からないパケットが入ってきた時には、OpenFlowコントローラに「Packet In」メッセージが送られます。

図6　

2. OpenFlowコントローラからOpenFlowスイッチに対し「Flow Mod」メッセージを送り、OpenFlowスイッチのフローエントリを更新します。フローエントリは、「どのようなパケットに対し、どのようなアクションを取るか」という処理内容をまとめた一覧表と考えると分かりやすいでしょう。

図7　

3. OpenFlowコントローラからOpenFlowスイッチに対し、「Packet Out」メッセージを送り、パケットを転送します。

図8　

　……と、このようにわずか3枚の絵でOpenFlowの動作紹介が終わってしまいました。OpenFlowは一般に思われているほど複雑ではないのです。

アジャイルなOpenFlowプログラミングフレームワーク、「Trema」

　先に、OpenFlowプログラミングフレームワークが複数存在することを紹介しましたが、ここからは、扱いやすさに定評のある「Trema」について紹介していきます。

【関連リンク】

Trema

http://trema.github.com/trema/

　Tremaの特徴としては、以下の点が挙げられます。

1. Rubyによる簡潔な記述
2. フルスタック（ノートPC 1台で開発できる）
3. OpenFlow規格に忠実
4. ドキュメントが豊富
5. 日本語での情報が豊富
6. GitHub上でのオープンな開発（GPL2）

　1. は、Rubyの採用により簡潔にプログラミング可能ということを意味します。4.と5.は、Trema開発メンバーの努力の成果といったところでしょうか。6.は文字通り、オープンソースソフトウェアとして開発、公開されているということですね。

　注目すべきポイントは2.と3.になります。

　3.については、ネットワーク分野における世界最大規模のイベント、Interop Tokyo 2012でのShowNetで構築されたOpenFlowネットワーク（多種多様なベンダのOpenFlowスイッチの相互接続環境）でも利用された実績があり、信頼ある実装だといえるでしょう。

Interop Tokyo 2012の「OpenFlow Showcase」では、多種多様なベンダのOpenFlowスイッチが一堂に集まり、相互接続のデモンストレーションを行った

　2.は、Tremaが「アジャイルなOpenFlowプログラミングフレームワーク」だといわれるゆえんです。Tremaは他のOpenFlowプログラミングフレームワークとは異なり、テスト用にOpenFlowネットワークをシミュレートする機能も備えており、ノートPC 1台でのアジャイルな開発が可能となっています。

図9　PC 1台でアジャイルな開発が可能なことがTremaの特徴

　つまり、Tremaは単なるOpenFlowプログラミングフレームワークではなく、OpenFlow開発のための統合開発環境とも表現できるものです。この点も、多くのエンジニアがOpenFlow開発にTremaを利用する理由ではないでしょうか。

【関連記事】

Interop Tokyo 2012で見えたOpenFlowのこれから

http://www.atmarkit.co.jp/ait/articles/1207/25/news139.html

次回は実際にいじってみよう！

　今回はSDN/OpenFlowをいじっていく上で押さえておきたい情報を紹介しました。

　これであなたもSDN/OpenFlowをいじりたくなったに違いありません。次回は、アジャイルなOpenFlowプログラミングフレームワークであるTremaの導入から、実際にOpenFlowをいじっていく方法について紹介する予定です。