(Sorry if you get this twice. Bad email source addr used.) While I might get some pushback (hopefully I will) for saying this, I would argue that NORMAL is not that well defined; at least, it is highly implementation dependent.
LOCAL is pretty well defined since in all implementations there is some agent that is processing OpenFlow messages and the implication of LOCAL is that that agent has an interface into the data plane. LOCAL means send the packet in question to that interface. One note here, you write: > while LOCAL for packets with switch IP as their destination IP, right? Although this would be a common use case, there is no restriction on what packets might have LOCAL applied. OpenFlow gets the packet to the aforementioned interface and once there, what happens will depend on that interface's configuration. (For example, the interface could be in a promiscuous mode and the packet dumped by tcpdump.) NORMAL implies that there is some "non OpenFlow" processing. But by the fact that it is non-OpenFlow, what this means is out of scope for the OpenFlow spec. The term "hybrid" has been used to broadly categorize the integration of OpenFlow with other functionality. A hybrid switch which supported routing might do something very different than a hybrid switch that only supported L2 functions. In either case, the configuration of those non-OpenFlow functions will be outside of OpenFlow protocol; a completely generic OpenFlow controller should not make any assumptions about what would happen to packets to which NORMAL was applied. However an "integrated" controller (one that had device specific information about the non-OpenFlow capabilities and configuration of the devices on the network) could use NORMAL more intelligently. That being said, in deployments where there is some knowledge about the configuration of the devices in the network (maybe there's the convention that all the devices have L2 learning enabled and L3 disabled), NORMAL could be used as an alternative to "packet-in" as the default action (with the obvious trade-offs). Hope this helps. -Dan On Tuesday, October 11, 2011 at 9:33 AM, Dan Talayco wrote: > While I might get some pushback (hopefully I will) for saying this, I would > argue that NORMAL is not that well defined; at least, it is highly > implementation dependent. > > LOCAL is pretty well defined since in all implementations there is some agent > that is processing OpenFlow messages and the implication of LOCAL is that > that agent has an interface into the data plane. LOCAL means send the packet > in question to that interface. One note here, you write: > > while LOCAL for packets with switch IP as their destination IP, right? > Although this would be a common use case, there is no restriction on what > packets might have LOCAL applied. OpenFlow gets the packet to the > aforementioned interface and once there, what happens will depend on that > interface's configuration. (For example, the interface could be in a > promiscuous mode and the packet dumped by tcpdump.) > > NORMAL implies that there is some "non OpenFlow" processing. But by the fact > that it is non-OpenFlow, what this means is out of scope for the OpenFlow > spec. The term "hybrid" has been used to broadly categorize the integration > of OpenFlow with other functionality. A hybrid switch which supported routing > might do something very different than a hybrid switch that only supported L2 > functions. > > In either case, the configuration of those non-OpenFlow functions will be > outside of OpenFlow protocol; a completely generic OpenFlow controller should > not make any assumptions about what would happen to packets to which NORMAL > was applied. However an "integrated" controller (one that had device specific > information about the non-OpenFlow capabilities and configuration of the > devices on the network) could use NORMAL more intelligently. > > That being said, in deployments where there is some knowledge about the > configuration of the devices in the network (maybe there's the convention > that all the devices have L2 learning enabled and L3 disabled), NORMAL could > be used as an alternative to "packet-in" as the default action (with the > obvious trade-offs). > > Hope this helps. > > -Dan > > > > On Tuesday, October 11, 2011 at 3:51 AM, Thapar, Vishal wrote: > > > Hi, > > > > I have some confusion regarding difference between LOCAL and NORMAL action. > > My [current] understanding is LOCAL refers to host's TCP/IP stack while > > NORMAL states "Process packets using traditional non-Openflow Pipeline of > > the switch". > > > > What I understand from it is that NORMAL action should only be used for > > packets passing through switch while LOCAL for packets with switch IP as > > their destination IP, right? > > > > Now, my question is, what if I setup specify NORMAL action for a packet > > that would've normally gone to the switch host stack? Conversely, what if I > > specify LOCAL action for a packet which wasn't destined for switch? What > > about packets destined for switch but not IP packets, like say, UDLD > > packets? > > > > I initially thought NORMAL was a superset of LOCAL and meant "fwd or send > > to host stack", but spec seems to restrict NORMAL to just forwarding > > pipeline and make NORMAL/LOCAL apply to mutually exclusive scenarios. > > > > Regards, > > Vishal Thapar. > > _______________________________________________ > > openflow-discuss mailing list > > [email protected] > > (mailto:[email protected]) > > https://mailman.stanford.edu/mailman/listinfo/openflow-discuss _______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
