"Peter Phaal" writes:
> 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
> > 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
"Peter Phaal" writes:
> Here is a new definition for the Extended OpenFlow structure that better
> addresses your points:
This looks good to me.
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 ve
> 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
sFlow is currently able to report on FCoE traffic since fiber channel
addresses, message types and traffic volumes can all be obtained by decoding
and analyzing the sampled packet headers.
However, fiber channel has its own forwarding logic and the addition of an
extended flow structure to capture
