pusuke0418’s diary

異常にマルチタスクな社内SEのブログ

Open FlowのReserved Portと設計のなぞ

Open Flowは、コントローラへの通信は、その空っぽのスイッチはどうやってやるんだろうとふと疑問に思った。実は実装を知っているような機器もあるのだけれども、なんとなく単純にOpen FlowのSpecificationをかいつまんで読んでみた。

たとえばv1.3.4を読むと、p.13 にReserved Portなるものがあった。1.3.4を読んでみたのは、実装されているもので新しいものは1.3.xが多いのかなという思い込みと、その系で新しそうだったから。

引用すると

"They specify generic forwarding actions such as sending to the controller, flooding, or forwarding using non-OpenFlow methods, such as “normal” switch processing.A switch is not required to support all reserved"

いわゆる普通のスイッチングのようにOpen Flowではない方法を使うものっぽい。その中に、CONTROLLERという種類のものがある。

"Represents the control channel with the OpenFlow controllers. Can be used as an ingress port or as an output port. When used as an output port, encapsulate the packet in a packet-in message and send it using the OpenFlow switch protocol (see 7.4.1). When used as an ingress port, this identifies a packet originating from the controller."

私にはポエムのようにしか見えないのだけれども、コントローラとの通信に使われるようだ。ingressまたはoutputのポートとして使われるとか、ingressとして使われる場合は、というような部分がよくわからないんだけれども(別にポートが2つ要るとかじゃないよね)。

さしあたって、「ふつうの通信」するポートでコントローラと通信しているのかな。それなら、フロー情報無くてもコントローラと通信できるということは理解できる。

ただし、その場合、Open Flowで形成されるネットワークとは別に、コントローラ接続用のネットワークの系が必要になることになるということか。線新しく引いたりする必要が出てきたりするのかな。その場合、そこも冗長取りたくなるわけで、そうしたら、その部分ではメーカーの実装に依ったりして、冗長プロトコルを動かせるのだろうか。華々しい?Open Flowの実際の全体の設計イメージとして、特に使うこともなさそうな寂しい私ですが、なんとなくもやもやしてます。