Cookie つき振り分けスイッチ

先に作成した振り分けスイッチに対して、フローエントリへの追加に際して、どのルール（あるいはロジック）でそのポートに出力されることになったのかを示す Cookie をつけるよう機能拡張する。

実装

コード

Cookie つき振り分けコントローラ：panierswitch.py

実際に設置する場合は ./nox/build/src/nox/coreapps/examples 以下あたりに置けば良い。 同ディレクトリの meta.json へのエントリ追加も忘れず。 実際に末端につないだ PC から外部（インターネット）のホストに対してアクセスし、HTTP など指定されたトラフィックとそれ以外のトラフィックが振り分けられていることが確認できる。
（単純に NIC のランプでもよし、スイッチホスト上で tcpdump するもよし。）
その際、ovs-ofctl dump-flows br0 などとしてフローテーブルの中身を見れば、当該トラフィックについては、その種別に従った Cookie が付けられていることが確認できる。
なおこのコードは Cookie 記入拡張 で示したパッチの適用を必要とする。

修正箇所

方法としては、OPORTSについて、その値を従来の [ RULE, outport ] に cookie を追加して [ RULE, outport, cookie ] とした。

# outport check table, format= { vport: [[ RULE, outport, cookie ]] } 
OPORTS = { SW1: { 2:  [ [ ANY, 2, 0 ] ],
                  V1: [ [ RULE80, 3, 101 ], [ RULE443, 3, 102 ],
                        [ RULE25, 3, 103 ], [ ANY, 1, 0 ] ] }, 
           SW2: { 3:  [ [ ANY, 3, 0 ] ],
                  V2: [ [ RULE80, 2, 201 ], [ RULE443, 2, 102 ],
                        [ RULE25, 2, 103 ], [ ANY, 1, 0 ] ] } }

出力先が仮想ポート 3 （実際には物理ポート 3 に同じ）の場合は、全ての場合に物理ポート 3 に Cookie=0 で出力。
V2: [ [ RULE80, 2, 201 ], [ ANY, 1, 0 ] ]　なら、
出力先が仮想ポート V2 （物理ポート 2 と 1 の二本からなる）の場合は、RULE80 にマッチすれば物理ポート 2 に
Cookie=201 で出力。それ以外の全ての場合に物理ポート 1 から Cookie=0 で出力。
となる。

RULE80 などのルールは getOutport( ) で参照される。ルールは柔軟性が必要なので関数内にハードコードしている。
    ops=OPORTS[dpid][vport] << 仮想ポート一つぶんの出力先候補リストを得る
    for (rule, outport, cookie) in ops:
        if rule == RULE80 and testTCPport(80, packet):
            return (outport, cookie) 
        elif rule == RULE443 and testTCPport(443, packet):
            return (outport, cookie )
        elif rule == RULE25 and testTCPport(25, packet):
            return (outport, cookie) 
        elif rule == ANY: # no condition match
            return (outport, cookie) 
getOutport( ) が出力ポートだけでなく、そのポートとすべき判定処理のなかで決定された Cookie も返すように拡張されている点に注意。
最終的にこの Cookie 値は inst.install_datapath_flow( ) 関数の最後の引数として使われる。

展望

現在の目論見は OpenFlow スイッチで組まれたネットワーク中のフローを可視化することである。
それも単なる入出力ポート単位やアドレス単位で集約したパケット数・バイト数などによる流量の把握ではなく、この経路を通っているトラフィックの大きな部分であるこのフロー群は、どこのスイッチでのどのような判定理由によってここにやってきたのか、といったことを直感的に把握できるようなものを検討している。
また、OpenFlow は複雑な各スイッチごとの配送ルールの整合性を必ずしも確証できない状況が想像され、オペレータが予想しない経路にトラフィックが流れ込んだまま、それを把握できない場合などでも有用だろう。
そのためにはコントローラプログラムが各フローの出力ポートを決めた理由(*)をフローエントリに入れてカウンタ数字とともに集積する必要があり、そのコンテナとして Cookie を用いる。
なおその「理由(*)」はコントローラプログラムのみが知るはずのことなので、コントローラプログラムから容易に Cookie が設定できなければならないが、それについては既に準備が整っていることが今のタイミングで確認できた。
Cookie は 64bit あるので効率の良い使い方を検討中。