OpenFlow のスイッチ仕様 1.2 は、以前の 1.1 と全く違うマッチパターン設定になっており、ハードウェアスイッチを作る人には大変更だと思うが、あまり話題になっていない。
OpenFlow のスイッチ仕様 1.2 は、以前の 1.1 と全く違うマッチパターン設定になってる。そして従来の固定フィールド相手の記述法は完全に廃止予定扱いとなってる。うーん。。。これ、スイッチ作っている人たちにとっては相当な大変更だと思うのだけれど、どうして話題として出てこないのだろう。。。
v1.2 スイッチ仕様については以下のページにリンクあり。
https://www.opennetworking.org/standards/12-and-pending
そこの A.2.3 Flow Match Structures を見ると、マッチフィールドが ver 1.1 と完全に違うものになっていることがわかる。またそのすぐ下（page 32 最下部）にこんな記述がある。
The only valid match type in this specification is OFPMT_OXM, the OpenFlow 1.1 match type OFPMT_STANDARD is deprecated.
（超訳：v1.2で採用された OXM マッチパターン記述方式が唯一だからね。v1.1の STANDARD 方式はもう廃止予定で行くから。）
少し補足説明。
v1.1 まではマッチパターンなどは固定長で、複数の対象フィールドからなるビット列だった。つまり入ってきたパケットから、対応するビットフィールドを寄せ集めて TCAM に並んだマッチパターンにドンと掛けてやれば良い、という感じ。
v1.2 ではマッチパターンが遂に（仕様上は）固定長でなくなった。TLV (type length value) structureと呼ばれているが、IP option と同じ構造で、マッチフィールド、マッチする値（必要ならビットマスクつけて）を列挙する。
ただし、さすがにどの type ならどのビット位置から何ビットをどうマッチさせるか、についてはプログラマブルにされておらず、ユーザがスイッチに教えることはできない。単に v1.2 仕様で定義されたものだけをスイッチベンダーは実装すれば良い。
というわけで、恐らく v1.2 対応スイッチは単にコントローラとの通信において TLV データ構造をパースするだけで、（幾らか長くなったとは言え）従来同様にTCAM に突っ込むべきマッチパターンは固定長で持つことになる、かな。 （に、しても後方互換性を一切要求しない、のかなあ。。清々（すがすが）しい、、、とは思う。）
それにしても既存のハードウェアスイッチを作ってしまったところは，果たしてこの v1.2 によるTLVパースをファームウェア更新で対応できるんだろうか。。。理屈では障害は無いけど、果たして現実にはファームウェア用のメモリサイズの問題、v1.1 との併存、開発工数そのものなど、いろいろ頭が痛い問題があるのではないか。
また、まともに対応して設計すると結構大変。ファームどころの話ではなく根本的に設計が変わるように思える。
つまりプロトコル的にはとても簡単にマッチ対象フィールドを増やせる構造になったので（ONF側で type を新しく一つ定義するだけ）、それを前提に設計することになる。
が、これはとても大変だ。。最終的に固定長のマッチパターンに落とすのであれば TCAM のビット幅が決められなくなる。ただでさえ高価で、OpenFlow では行は目一杯、しかしビット列についてはスカスカの利用率になる可能性があるのに、将来のために予約しないといけないという。
HPのスイッチはマニュアルによれば TCAM を使ってマッチする（彼らはこれを「ハードウェア」で処理すると表現している）フィールドはv1.1のマッチフィールドですら部分的で、それ以外のフィールドはソフトで処理する（恐らくはメモリ中の辞書を引く）。
つまりハードウェアスイッチと言えども、今後のことを考えれば v1.1までの「固定長マッチフィールド」という視点を捨てて、どのフィールドを TCAMに入れて、どのフィールドを辞書で引くかをファームウェアで自由にする、といった構造にしないといけない。
そう考えると、v1.2 てのは結構大きな話をしているように思えるんだけれど、、、、まあ余り話題として表に出てこないのは、
ということなのかな。。。
2012.04.18