But you will only track the request packets, right? So unless you have hundreds or thousands of requests per switch, I don't see why it wouldn't scale. Also, the packet would go directly to the central decision system, which would immediately react and act if necessary, over several Openflow switches in order to establish the necessary rules for the multicast session. It could also reconfigure the network to provide a better service.
Anyway, you should check the hybrid switch concept in the Openflow Specifications. I believe it provides the path for the objective you want to achieve. On 10 September 2013 14:28, Carlos Guimarães <cguimar...@av.it.pt> wrote: > I agree with you when you say that I'm adding old concepts to the > OpenFlow Switches. The thing is that (for the behavior that I want) if the > OpenFlow Switch does not support learning, it will need to send all packets > to the OpenFlow Controller in order to keep track of the request messages, > allowing the response to be sent only for the ports that received the > request message. If I'm doing this for all messages in all switches in the > path, the solution will not scale. > > Best regards, > Carlos Guimarães > > > On 09/10/2013 11:56 AM, Carlos Ferreira wrote: > > Well, you could extend it by transforming the Openflow Switch into a > hybrid switch, by adding the necessary pipes through where those special > packets will be redirected and the actual learning is done. > The specifications clearly accept that, but in my opinion, it goes against > the Openflow concept which is to centralize all decision making. By > centralizing decisions related to the multicast concepts, it is much easier > to optimize the network paths through where the data flows goes, since the > central decision system has a higher view of the network state. It also has > increased processing power which enables it to run improved optimization > algorithms. > By doing what you want to do, you are actually adding the old multicast > concepts in normal routers to the Openflow switches. > But yes, its certainly feasible, one way or another. > > Hope it helps! > > > On 9 September 2013 17:25, Carlos Guimarães <cguimar...@av.it.pt> wrote: > >> You understood it correctly. That learning functionality is what I need >> to support the desired behavior. >> So, if I intend to support this functionality, allowing it to be >> configured by the OpenFlow Controller (i.e., the OpenFlow Controller may >> configure the OpenFlow Swtich defining how it should "learn"), I'm thinking >> in extending the set of actions. >> >> Do you think this is the most feasible approach? >> >> Best regards, >> Carlos Guimarães >> >> >> On 09/06/2013 06:14 PM, Wes Felter wrote: >> >>> On 9/6/13 9:14 AM, Carlos Guimarães wrote: >>> >>>> Hi, >>>> >>>> Using the 1.3.2 OpenFlow specification, is it possible to define an >>>> action that whenever the OpenFlow switch receives a packet to a specific >>>> DST to add the INGRESS_PORT to a group table? The objective is to send >>>> the response from the DST towards all ports that received the request >>>> message to the DST (like a multicast response). >>>> >>>> From my understanding of OpenFlow specification, I can send the >>>> incoming packets destined to a specific DST to the OpenFlow Controller, >>>> and then the OpenFlow Controller is responsible for updating the group >>>> table. But I would like to avoid doing this using the OpenFlow >>>> Controller everytime I received a packet from a different port. >>>> >>> >>> It sounds like you're talking about some kind of learning. OpenFlow >>> doesn't have learning (yet). OVS has a learning extension, but I think it >>> can only create normal flow mods, not group table entries. >>> >>> >> _______________________________________________ >> openflow-discuss mailing list >> openflow-discuss@lists.stanford.edu >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >> > > > > -- > > Carlos Miguel Ferreira > Researcher at Telecommunications Institute > Aveiro - Portugal > Work E-mail - c...@av.it.pt > MSN Contact -> carlosmf...@gmail.com > Skype & GTalk -> carlosmf...@gmail.com > LinkedIn -> http://www.linkedin.com/in/carlosmferreira > > > > _______________________________________________ > openflow-discuss mailing list > openflow-discuss@lists.stanford.edu > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > > -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - c...@av.it.pt MSN Contact -> carlosmf...@gmail.com Skype & GTalk -> carlosmf...@gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira
_______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
