The OpenFlow version 1.0 specification has now been released: http://www.openflowswitch.org/documents/openflow-spec-v1.0.0.pdf
Based on previous discussions, the following draft describes an sFlow extended_flow structure for reporting on forwarding decisions in OpenFlow switches: http://www.sflow.org/draft-sflow-openflow.txt If there are any additional comments or corrections, please raise them promptly. Timely publication of this extension will significantly enhance the utility of sFlow monitoring in OpenFlow environments as they are deployed more widely. Finally, for anyone interested in experimenting with OpenFlow and sFlow, the Open vSwitch virtual switch implements OpenFlow and will soon support sFlow: http://openvswitch.org/ Peter -----Original Message----- From: owner-sf...@sflow.org [mailto:owner-sf...@sflow.org] On Behalf Of Peter Phaal Sent: Wednesday, October 14, 2009 3:00 PM To: 'Ben Pfaff' Cc: sflow@sflow.org Subject: RE: [sFlow] Re: sFlow and OpenFlow > Since OpenFlow is not a final standard, it would be good to > either specify a particular version of OpenFlow (in case the bit > fields change in later versions) or to somehow include a version > number in the packet. I would assume that most changes to the bit fields would be additive in order to try and maintain backward compatibility as the protocol evolves. If a major change alters the format of these data structures then a new sFlow structure would need to be defined. We should make the OpenFlow version 1.0 spec normative (it sounds like it will be released soon) and specify that any OpenFlow switch exporting sFlow would need to export these fields in a way that was consistent with the OpenFlow 1.0 specification. All the bits in the bit arrays would need to be consistent with the 1.0 spec, although additional bits would be permitted. Here is a new definition for the Extended OpenFlow structure that attempts to address this issue: /* Extended OpenFlow 1.0 data */ /* opaque = flow_data; enterprise = 0; format = 1017 */ /* Data structure for exporting OpenFlow 1.0 forwarding state See http://www.openflowswitch.org/ for field definitions Note: Bit definitions must be consistent with the OpenFlow version 1.0 specification. If later versions of OpenFlow define additional bits, then these additional bits may be included. However, if future versions of the OpenFlow protocol alter the meaning or order of existing bits then the information must be translated into a semantically equivalent 1.0 structure before exporting (possibly resulting in some loss of information). If major structural changes to the OpenFlow protocol invalidate the 1.0 structures, then the agent must not export the openflow_v1 structure. */ /* A bit array describing the fields in the packet header that are used to form the flow key. See ofp_match for the definition of wildcards. */ typedef unsigned int wildcards; /* A bit array describing fields that may have been altered by the flow action. The ofp_action_type enum is used to determine the bit positions, with OFPAT_OUTPUT assigned to the least significant bit. The bit is set if an action of the corresponding type has been specified. Note: OFPAT_VENDOR is encoded using the most significant bit */ typedef unsigned int actions; struct extended_openflow_v1 { unsigned hyper flow_cookie; wildcards flow_match; actions flow_actions; }
