> > 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];
> > }
>
> It seems likely that OpenFlow will add the flow cookie as an
> unsigned 64-bit integer. Perhaps sFlow should use the same type,
> if so.
I agree, we should match the semantics of the OpenFlow cookie.
If it is 64 bit integer, then the following XDR encoding is a better match,
enduring the platform byte ordering will not affect the transport and
interpretation of the cookie.
unsigned hyper flow_cookie;
> OpenFlow has an existing type that it uses to encode the
> wildcards for a flow. It would be convenient for OpenFlow
> implementors of sFlow if sFlow specified the same encoding:
>
> /* Flow wildcards. */
> enum ofp_flow_wildcards {
> OFPFW_IN_PORT = 1 << 0, /* Switch input port. */
> OFPFW_DL_VLAN = 1 << 1, /* VLAN. */
> OFPFW_DL_SRC = 1 << 2, /* Ethernet source address. */
> OFPFW_DL_DST = 1 << 3, /* Ethernet destination address. */
> OFPFW_DL_TYPE = 1 << 4, /* Ethernet frame type. */
> OFPFW_NW_PROTO = 1 << 5, /* IP protocol. */
> OFPFW_TP_SRC = 1 << 6, /* TCP/UDP source port. */
> OFPFW_TP_DST = 1 << 7, /* TCP/UDP destination port. */
>
> /* IP source address wildcard bit count. 0 is exact match, 1 ignores
> the
> * LSB, 2 ignores the 2 least-significant bits, ..., 32 and higher
> wildcard
> * the entire field. This is the *opposite* of the usual convention
> where
> * e.g. /24 indicates that 8 bits (not 24 bits) are wildcarded. */
> OFPFW_NW_SRC_SHIFT = 8,
> OFPFW_NW_SRC_BITS = 6,
> OFPFW_NW_SRC_MASK = ((1 << OFPFW_NW_SRC_BITS) - 1) <<
> OFPFW_NW_SRC_SHIFT,
> OFPFW_NW_SRC_ALL = 32 << OFPFW_NW_SRC_SHIFT,
>
> /* IP destination address wildcard bit count. Same format as source.
> */
> OFPFW_NW_DST_SHIFT = 14,
> OFPFW_NW_DST_BITS = 6,
> OFPFW_NW_DST_MASK = ((1 << OFPFW_NW_DST_BITS) - 1) <<
> OFPFW_NW_DST_SHIFT,
> OFPFW_NW_DST_ALL = 32 << OFPFW_NW_DST_SHIFT,
>
> /* Wildcard all fields. */
> OFPFW_ALL = ((1 << 20) - 1)
> };
>
> > 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.)
>
> I agree that it would be a good idea to provide this information
> in fields already included in sFlow.
Here is a new definition for the Extended OpenFlow structure that better
addresses your points:
/* Extended OpenFlow data */
/* opaque = flow_data; enterprise = 0; format = 1017 */
/* Data structure for exporting OpenFlow forwarding state
See http://www.openflowswitch.org/ for field definitions */
/* 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 {
unsigned hyper flow_cookie;
wildcards flow_match;
actions flow_actions;
}
