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-sflow@sflow.org [mailto:owner-sflow@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;
}
Received on Tue Jan 19 12:00:59 2010
This archive was generated by hypermail 2.1.8 : 02/17/10 PST