Search Mailing List Archives
[openflow-spec] Flow Cookies and sFlow
peter.phaal at inmon.com
Thu Oct 8 15:45:31 PDT 2009
> If I understand it correctly, sFlow is used to monitor networks by
> sampling packets/packet headers (and possibly statistics) and
> forwarding them to an sFlow collector.
> Therefore, a version of OpenFlow which added a packet sampling action
> could be useful for implementing sFlow-like capabilities (or an sFlow
> client, for that matter.)
The OpenFlow switch would need to support packet sampling, but there is no
support for sampling needed in the OpenFlow protocol. The measurement and
control planes are orthogonal; the sFlow function is completely independent
of protocols used to determine forwarding decisions. Most L2/3 switch
fabrics already support packet sampling and sFlow.
> Without a sampling action, I think it would be hard to make sFlow -
> you'd have to do something crafty like rapidly expiring and replacing
> flows in order to get "sampled" packets out of the data path; this
> would probably not work particularly well.
You are right, without hardware support for sampling it is very hard to
implement sFlow (unless you are creating a software switch). However, as I
mentioned earlier, sFlow does not affect the forwarding/control plane and
packet sampling is already implemented in most switch ASICs.
Much of the confusion about sFlow arises from the similarity in the name
with NetFlow. Unlike NetFlow, which originated as a means of exporting
expired forwarding records, sFlow is not flow based, it is packet based. It
is a mistake to tie the definition of a flow used to forward a packet to the
mechanism used to monitor the traffic. By keeping the two mechanisms
independent, you can collect detailed information about traffic that will
help optimize forwarding policies (e.g. decide whether to split a flow, or
combine flows, or re-factor and use different flow keys for forwarding).
> It's not obvious to me how flow cookies would support sFlow - are you
> thinking that sFlow collectors could somehow be slightly modified to
> report flow match statistics as well as other statistics?
The benefit of the flow cookie is that the sFlow agent can attach the cookie
to packet samples that belong to the flow. The addition of the cookie allows
the sFlow analyzer to add an additional dimension to the traffic database
that can assist with traffic engineering. Being able to partition the site
traffic matrix by flow cookie allows the traffic analyzer to explore the
effects of alternate flow partitioning strategies and assess the
effectiveness of the current policy.
My understanding of the Open Flow protocol is that it supports multiple
controllers. Being able to pull the traffic apart by controller would be a
useful way to trouble shoot problems that may occur when different control
strategies interfere with each other by competing for shared resources.
Finally, think of sFlow as a distributed, sampling, mirror port. Packet
headers from all over the network marked with the flow keys would be a very
useful debugging tool when rolling out Open Flow deployments.
> p.s. (For some time I've been a fan of the idea of an OpenFlow API -
> both for application writers and switch implementors - which could be
> used to develop both network applications and internal switch
> functionality in a hardware-independent manner.)
I am also excited by the opportunity to control switches in a standard and
predictable way (rather than relying on expect scripts and CLIs). I am
particularly interested in being able to shape traffic through manipulating
QoS settings (priority, rate limits etc). Is this a capability that is
already in or planned for OpenFlow?
> On Oct 8, 2009, at 2:48 PM, Peter Phaal wrote:
> > I noticed the discussion about adding flow cookies to OpenFlow. One
> > of the
> > reasons for creating the cookie is to "enable information sharing
> > with other
> > switch features such as sFlow and NetFlow".
> > In the case of sFlow monitoring this sounds like a great idea. Since
> > sFlow
> > performs stateless packet sampling, the inclusion of the cookie in
> > the sFlow
> > samples would help unify the measurement and control planes by
> > allowing an
> > sFlow analyzer to group traffic together by flow cookie.
> > From what I have read of OpenFlow (and I must admit to fairly limited
> > knowledge), sFlow and OpenFlow appear very well matched. Both have a
> > centralized architecture with simple capabilities in the switch and
> > complexity shifted to the central controller. Both operate at layer
> > 2 and up
> > by controlling, forwarding, or monitoring based on packet headers.
> > There is
> > an interesting convergence between sFlow, OpenFlow, and the Open
> > vSwitch
> > projects that offers a lot of promise:
> > http://blog.sflow.com/2009/10/network-edge.html
> > If a decision is made to incorporate flow cookies in OpenFlow, it
> > would be
> > important to create a standard sFlow structure for reporting on
> > OpenFlow
> > forwarding state associated with each packet sample. sFlow is easily
> > extensible and already has data structures to report on many types of
> > forwarding decision (bridge, router, bgp, mpls, vlan tunnels). In
> > addition
> > to the flow cookie, are there any other attributes of the forwarding
> > decision (the ofp_action_type perhaps?) that could be usefully
> > associated
> > with a sampled packet? If there is interest we could work on the
> > extension
> > on the sFlow mailing list:
> > http://www.sflow.org/discussion/index.php
> > Peter P.
> > _______________________________________________
> > openflow-spec mailing list
> > openflow-spec at lists.stanford.edu
> > https://mailman.stanford.edu/mailman/listinfo/openflow-spec
> openflow-spec mailing list
> openflow-spec at lists.stanford.edu
More information about the openflow-spec