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
<mailto: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
<mailto: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 <mailto:c...@av.it.pt>
MSN Contact -> carlosmf.pt <http://carlosmf.pt>@gmail.com
<http://gmail.com>
Skype & GTalk -> carlosmf.pt <http://carlosmf.pt>@gmail.com
<http://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
