Trema Day #1でOpenFlow 1.3について思ったこと

Trema Day #1に参加した。まったりとした雰囲気の中、Tremaに限らずSDN関連のいろんな発表聴けて休日を潰しても十分元を取れた。その中でOpenFlow 1.3の話がいくつか出てきたので、まとめておきたいと思う。当日の様子はust録画されているとのことなので、まだ視聴できると思う。

1.0から1.3への変更について、機能レベルでIPv6やMPLS、PBBなどに対応したというのはあちこちで耳にするので、ここでは踏み込まない。グループやQoSのあたりも、具体的にどう使うのかいまいち分かっていないし。個人的には予想以上にプロトコルが変わっているという印象を強く受けた。詳しくは後で書くけど、packet inに関わる部分は特に変わりすぎじゃないかな。現実に即すように変更されたのだとは思うけど。Trema開発の中心人物である須堯さんは、1.0と1.3の互換性を取りながらコントローラを作るのは無理じゃないかとおっしゃっていた。このレベルの変更をあの頻度にやられると、確かにベンダは着いて来られないよな。1.3で仕様策定をペースダウンしましょうというONFの判断は納得できる。

packet inはOpenFlowがもたらす柔軟性の肝である。OpenFlowが出てきたとき、フローテーブルはproactiveにもreactiveにも設定できるけど、packet inを使ってreactiveにやるのがOpenFlow流みたいに私は受け取った。その後、本当にそうなのかなと悶々としていたけど、ComSys 2012で藤田@NTTさんが「packet inしたら負け」というのを講演冒頭からおっしゃっていて、スッキリした。OpenFlowだから何でもできるわけじゃなくて、適用できる範囲というものが徐々に明らかになってきたのだろう。OpenFlowの仕様もそれに合わせて変わってきたのだと思う。@tsuboiさんによると、クラウド/通信事業者がOpenFlowを適用するときの動機として、運用の自動化が大きい。reactiveでは、自動化の阻害要因になりかねないので、proactiveを中心にしたアーキテクチャとして検討され直したのだろうとのことである。なるほど。

まず1.3になると、デフォルトではpacket inはコントローラに上がってこない。これは結構衝撃的だった。packet inが必要な場合は、コントローラが明示的にflow modで設定する必要がある。packet inに付属する情報も（後述するように）変わっていて、肥大化の傾向にある。当然コントローラの負荷は増える。そこでセキュアチャネル以外に、Auxiliary Connections（これはUDP？）を使って、packet inをオフロードしようという話もあるようだ。また、1.0のflow modはマッチしたらアクションを実行するという単純なものだったが、インストラクションが入って、アクションをパイプライン化することが可能になった。会場からは本当にハードウェア化できるのか、やるなら何段？という質問も出ていた*1。

あとはスイッチのポート情報がfeatures replyで上がってこないので、自力で検索する必要があるとか。たぶん大規模データセンタでの運用を見据えた変更だろうけど、Tremaアプリを書く人は気をつける必要がある。

話は変わるが、OpenFlow対抗？として、JuniperやCiscoらがIETFで標準化を進めているI2RS (Interface to the Routing System)ワーキンググループの動向も気になる。何でもプログラマブルに対する揺り戻しとして、どのあたりに着地点を設定してくるのだろうか。

ちなみに上の写真は懇親会でもらったTrema Tシャツ。packet_in構造体の定義がなぜTrema?と思ったら、Trema独自の抽象化が入っているので、Open vSwitchのものとは違うそうだ。TシャツにもあるTremaの定義(src/lib/openflow_application_interface.h)は次の通り。

typedef struct {
  uint64_t datapath_id;
  uint32_t transaction_id;
  uint32_t buffer_id;
  uint16_t total_len;
  uint16_t in_port;
  uint8_t reason;
  const buffer *data;
  void *user_data;
} packet_in;

これに対して、Open vSwitchの定義(include/openflow/openflow-1.0.h)ではこうなる。

struct ofp10_packet_in {
    ovs_be32 buffer_id;     /* ID assigned by datapath. */
    ovs_be16 total_len;     /* Full length of frame. */
    ovs_be16 in_port;       /* Port on which frame was received. */
    uint8_t reason;         /* Reason packet is being sent (one of OFPR_*) */
    uint8_t pad;
    uint8_t data[0];        /* Ethernet frame, halfway through 32-bit word,
                               so the IP header is 32-bit aligned.  The
                               amount of data is inferred from the length
                               field in the header.  Because of padding,
                               offsetof(struct ofp_packet_in, data) ==
                               sizeof(struct ofp_packet_in) - 2. */
};

なるほど、datapath_id、transaction_id、user_dataあたりがTremaでは追加されている。ちなみにOpenFlow 1.3ではtable_inやcookieが追加され、in_portが削除されている。packet_inでin_portはわからないのでmatchを検索しろと言うことらしい。

Open vSwitchのmasterブランチにはopenflow-1.3.hは含まれているけど、次のlong term supportになる1.9系ではOpenFlow 1.3は対応されないらしい。OpenFlow 1.3対応がそろってくるのはもう少し先になるのかな。Tremaが1.1と1.2を飛ばして1.3対応したことに対して、会場では概ね納得という反応だった。Pica8は最近のUpdate（PicOS 1.6）でOpen vSwitch 1.7.1ベースになり、OpenFlow 1.2対応と刻んできた。AcctonもOpenFlow 1.2対応と言っていたはず（AcctonのスイッチもOpen vSwitchベースなのかな？）。その辺にはいろいろ大人の事情があるんだろう。

Trema edgeが正式リリースされれば、packet_inの定義も1.3対応されるので、新しいTシャツが作られるとのこと。Trema DayでLTしたり、Tremaにパッチを投げたりしたら、Tシャツもらえるかも。ちなみにTrema Dayは、今後も3ヶ月に一度ぐらいの頻度で開催予定ということだ。

個人的にはOpenFlowの仕様書を一度真面目に読んでみようと思った。

（追記）はてブにPlan9日記なのにPlan 9について書かれていないじゃないかみたいなことが書かれていたので、ちょっとだけ蛇足。Trema Dayの懇親会でPlan 9とacmeの話が出ていたらしい。次回は宴会芸として、acmeへの愛を語りたい！？

*1:ONFの仕様策定方法についても話題に上った。スタンフォード大学が音頭を取っていた1.0までは、実装がないと標準化しないというポリシだった。しかし、ONF設立後、実装がないまま1.1がなし崩し的にリリースされてしまうと、それが慣習となってしまった。ONF内の力関係がどうなっているか知らないけど、ハードウェアベンダよりもNiciraのようなソフトウェアベンダの力の方が強く、ハードウェア化が困難なものも入ってしまうのかなと思ったり。