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
