OpenFlow is an open standard ( http://www.openflowswitch.org/ ) that allows a central traffic controller to manage forwarding decisions in network switches. For anyone unfamiliar with OpenFlow, the following white paper provides an overview: http://www.openflowswitch.org/documents/openflow-wp-latest.pdf
It has been proposed that version 1.0 of OpenFlow protocol will add the concept of a "flow cookie". The value of including a cookie in the OpenFlow protocol and exporting the cookie in sFlow has been discussed on the openflow-dev mailing list: https://mailman.stanford.edu/pipermail/openflow-spec/2009-October/ Exporting the cookie in sFlow allows an sFlow collector to associate sampled packets with OpenFlow forwarding policies. Being able to make this association will be critical to managing traffic flows in an OpenFlow environment. The following structure would add the needed support to sFlow: /* Extended OpenFlow data */ /* opaque = flow_data; enterprise = 0; format = 1017 */ struct extended_openflow { opaque flow_cookie[8]; } In theory the cookie could be used to retrieve all the settings associated with the forwarding entry. However, there may be additional information that should be added to this structure in order to assist an sFlow analyzer in interpreting the traffic flows. One possible addition is a bit array identifying the header fields that are being used to make the forwarding decision. OpenFlow currently forwards based on combinations of the following fields: 1. ingress port 2. VLAN 3. Priority 4. L2 source 5. L2 destination 6. L2 type 7. L3 source 8. L3 destination 9. L3 protocol 10. L4 source port 11. L4 destination port An unsigned int value would encode the 11 bits and leave room for future expansion. The bits would identify fields that were matched (1) or were wildcards (0). An OpenFlow switch may also rewrite packet fields (e.g. changing the VLAN, MAC address, IP address) if it is performing functions like NAT, tunneling etc. Again, a bit array could be used to identify the fields that are being rewritten. The value of rewritten fields should be reported using existing sflow structures (extended_switch, extended_nat etc.) Proactively defining the extended_openflow structure will ensure interoperable monitoring of OpenFlow switches as they start to become widely available. Peter
