sFlow and OpenFlow

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
Received on Tue Oct 13 22:08:00 2009