RE: Re: sFlow and OpenFlow

From: Peter Phaal <peter.phaal@inmon.com>
Date: 01/19/10
Message-ID: <1CD02DC711C748E2B0BCE63E92DA5FE1@peterphaald04f>

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