Any time you use wildcards you are being pro-active, improving scalability by reducing forwarding table size in the switches and reducing the load on the controller.
A couple of additional examples: 1. If you want to enforce iptables-like firewall rules on physical/virtual machines, then you can use Open Flow to distribute the rules to the edge of the network and simplify the configuration of core devices. 2. You can use Open Flow for load balancing, but rather than take the performance hit of routing each L4 flow, you use measurements to concentrate on large flows (http://blog.sflow.com/2011/05/openflow-and-sflow.html) and wildcard the rest. Peter On Wed, May 25, 2011 at 6:53 AM, Rob Sherwood <[email protected]> wrote: > The most conventional use case in my mind is cidr routing. If your > controller deals with flows at the CIDR prefix level, e.g., "send all > packets that match 192.160.0.0/24 out port 3", then it could make more > sense to insert this rule once and have it stay there until the path > is withdrawn, rather than going through the proactive flow setup for > every flow that happens to match that rule. On the other hand, I can > conceive of reasons why you would still want to remain re-active, for > example if you had some more fine grained (e.g., layer-4 based) > network access control policies. > > Really, reactive vs. proactive is a design decision: different things > will make sense in different scenarios. The critical thing is that > the OpenFlow protocol allows the controller to pick which style it > wants to use (or even a hybrid). > > - Rob > . > > > > On Wed, May 25, 2011 at 6:32 AM, Brian Lee <[email protected]> wrote: >> As someone new to openflow can you give some scenarios under which I >> proactively install flows. I thought the default behavior is to send the >> first packet? >> Regards >> Brian lee >> >> Sent from my iPhone >> >> On 25 May 2011, at 10:20, Ben Pfaff <[email protected]> wrote: >> >>> On Tue, May 24, 2011 at 08:47:05PM +0200, Jose Luis Franco Arza wrote: >>>> I am an doing some scalability testings for my Master Thesis related to >>>> OpenFlow. One of the aims is to obtain a limitation in the number of flows >>>> per second that the NOX controller can install. Using an UDP packet >>>> generator and sending packets in a UDP ports range (each port corresponds >>>> to >>>> a new flow) I have been trying to obtain a limit for the number of flows >>>> installed in the flow table and how many flows per second can be installed >>>> obtaining a good performance in the network. >>> >>> If your goal is scalability, I doubt that sending the first packet of >>> every flow up to the controller is a good way to achieve it. Your >>> network will scale better if you proactively install flows, reducing >>> the need to send traffic to the controller. >>> >>> You didn't say what version of OpenFlow you had installed, but it may >>> not make sense to use the OpenFlow reference implementation for >>> scalability testing. I don't think it's designed for performance but >>> rather for simplicity. >>> _______________________________________________ >>> openflow-discuss mailing list >>> [email protected] >>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>> >>> ______________________________________________________________________ >>> This email has been scanned by the MessageLabs Email Security System. >>> For more information please visit http://www.messagelabs.com/email >>> ______________________________________________________________________ >> >> _______________________________________________________________________ >> The information contained in this email is confidential and is designated >> solely for the attention of the intended recipient(s). If you have received >> this email in error, please do not use or transmit it for any purpose but >> rather notify us immediately and delete all copies of this email from your >> computer system(s). Unless otherwise specifically agreed by our authorised >> representative, the views expressed in this email are those of the author >> only and shall not represent the view of or otherwise bind Athlone Institute >> of Technology. Contact [email protected] or telephone 090 6424400. >> >> >> Please consider the environment before printing this e-mail or its >> attachment(s) >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> _______________________________________________ >> openflow-discuss mailing list >> [email protected] >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >> > _______________________________________________ > openflow-discuss mailing list > [email protected] > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > _______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
