> 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 Wed Oct 14 16:00:48 2009
This archive was generated by hypermail 2.1.8 : 02/17/10 PST