Bootstrapping OpenFlow requires a configuration protocol like OF-Config or ovs-vsctl. Enabling sFlow sampling in the switch forwarding plane can easily be handled through a common configuration protocol.
OpenFlow and sFlow share many architectural similarities. In the same way that OpenFlow moves intelligence to the off switch controller, the sFlow architecture shifts flow analysis to off switch software. http://blog.sflow.com/2013/05/software-defined-analytics.html The task of efficient, scaleable traffic monitoring is very different from the control task performed by OpenFlow. For example, shoehorning packet sampling into OpenFlow multiplexes measurement and control over the same TCP connection and is likely to generate performance and stability problems for the OpenFlow controlled network. With a combined sFlow/OpenFlow solution the packet samples and interface counters are sent over a separate UDP channel to traffic analysis software and don't interfere with the OpenFlow controller. The best places to bring together the measurement and control functions that are needed to for the traffic engineering use cases mentioned is in the initial configuration and through northbound APIs to SDN applications. http://blog.sflow.com/2013/08/northbound-apis-for-traffic-engineering.html >From a pragmatic point of view, most of the OpenFlow capable merchant silicon, physical switches, and virtual switches available today include sFlow support. Building effective SDN traffic engineering, DDoS mitigation etc. solutions doesn't need to wait for new standards and hardware - they can be built today. Peter On Wed, Sep 11, 2013 at 5:11 AM, Zoltán Lajos Kis < zoltan.lajos....@ericsson.com> wrote: > Hi, > > Looking at the proposal, it seems it could be implemented with existing > group entries (available since OF 1.1). > Just install a select group with two buckets, one sending packet_in's, the > other dropping packets, and set the > Bucket weights to get the desired sampling rate. > OpenFlow 1.3 also adds support for meters, which helps you avoid flooding > the controller. > > I think Sample application 2 would be better implemented by the switch, > transparent to the controller. Assuming > that the controller is aware of switch internals (i.e., it knows these > flows go to TCAM, those flows go to SRAM) is > risky. So far none of the efforts that were aiming on this level of > capability exchange yielded usable results. > If you want to keep this OpenFlowy with the wildcard/exact match > distinction, you could look at OVS's learn action, > and extend it to not only maintain a flow cache for wildcarded flows, but > also clean up unfolded flows entries > from the TCAM. > > Best Regards, > Zoltan > > > > > > >-----Original Message----- > >From: openflow-discuss-boun...@lists.stanford.edu [mailto:openflow- > >discuss-boun...@lists.stanford.edu] On Behalf Of Philip Wette > >Sent: Wednesday, September 11, 2013 11:05 AM > >To: openflow-discuss > >Subject: [openflow-discuss] Adding Packet Sampling to OpenFlow > > > >Hello, > > > >i would like to suggest an extension to the OpenFlow standard for packet > >sampling. > >I already presented the extension at this years SIGCOMM in the poster > >session and now i would like to know how you people think about the idea. > > > >In environments with a high arrival rate of new flows, such as in a data > center, > >it is not feasible to install one rule for each flow. A doable approach > here is to > >group flows by wildcard rules. Thus the network is equipped with a bunch > of > >default routes. This of course makes traffic engineering very hard because > >you no longer know which flows are hiding behind which wildcard rule. So > you > >need some kind of elephant detection to extract large flows from the > wildcard > >rule and install a custom route for this flow. One default technique here > is > >packet sampling. > >To do packet sampling today one needs a protocol like sFlow or netFlow to > >control packet sampling at the switches. Since we already use OpenFlow to > >manage our switches for me it makes a lot of sense to include this into > the > >OpenFlow protocol. > > > >We developed a very simple extension to the OpenFlow standard that can be > >found here: > >http://conferences.sigcomm.org/sigcomm/2013/papers/sigcomm/p541.pdf > > > >I'm looking forward to your comments. > > > >Best, > > > >Philip > > > >-- > >Philip Wette, M.Sc. E-Mail: we...@mail.upb.de > >University of Paderborn Tel.: 05251 / 60-1716 > >Department of Computer Science > >Computer Networks Group http://wwwcs.upb.de/cs/ag-karl > >Warburger Straße 100 Room: O3.152 > >33098 Paderborn > > > >_______________________________________________ > >openflow-discuss mailing list > >openflow-discuss@lists.stanford.edu > >https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > _______________________________________________ > openflow-discuss mailing list > openflow-discuss@lists.stanford.edu > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >
_______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
