As you do not have a flow to match the packet in the flow table, yes. Or you will cause a loop.
Regards, Eder. On 18 December 2012 03:17, Mrinmoy Das <mrinmoy.bluem...@gmail.com> wrote: > Hi Eder, > > So, after getting packet-in message, controller needs to add a matching > flow entry before sending a packet-out message with OFPP_TABLE. Is this > what you are saying? > So, the spec lines what I had mentioned assumes that before sending a > packet-out message controller will send a matching flow entry. Right? > > Thanks & Regards, > Mrinmoy > > > On Mon, Dec 17, 2012 at 8:19 PM, Eder Leão Fernandes < > ederleaofernan...@gmail.com> wrote: > >> Hi, >> >> Your scenario only makes sense if you install a flow to match the packet >> after you receive it in the controller, just sending the packet-out will >> cause a loop. However OpenFlow messages are not guaranteed to be processed >> in order, so you will need to prevent the processing of the packet-out >> before the flow-mod. It's written in the spec, page '89', as follows. >> >> "In some cases, packets sent to OFPP_TABLE may be forwarded back to the >> controller as the result of a flow entry action or table miss. Detecting >> and taking action for such controller-to-switch loops is outside the scope >> of this speci cation.In general, OpenFlow messages are not guaranteed to be >> processed in order, therefore if a OFPT_PACKET_OUT message using OFPP_TABLE >> depends on a flow that was recently sent to the switch (with a >> OFPT_FLOW_MOD message), a OFPT_BARRIER_REQUEST message may be required >> prior to the OFPT_PACKET_OUT message to make sure the flow entry was >> committed to the flow table prior to execution of OFPP_TABLE." >> >> Regards, >> Eder. >> >> >> On 17 December 2012 02:53, Mrinmoy Das <mrinmoy.bluem...@gmail.com>wrote: >> >>> Hi All, >>> >>> In section 4.5 (Reserved Ports) of OpenFlow 1.3.1 Spec says: >>> >>> "Required: TABLE: Represents the start of the OpenFlow pipeline. This >>> port is only valid in an >>> output action in the action list of a packet-out message, and *submits >>> the packet to the first >>> flow table* so that the packet can be processed through the regular >>> OpenFlow pipeline." >>> >>> When packet comes to switch and don't find any matching flow, switch >>> sends the packet to controller encapsulated in a packet-in message. So, >>> switch already consult its first table to match the packet. Now, in >>> response to the packet-in message, controller sends a packet-out message >>> which may contain output action & output port may be mentioned as TABLE. >>> >>> According to the spec, switch will submit the packet to the first flow >>> table for processing. My question is, what is the logic in putting the >>> packet again in the first table? It seems that the switch >>> may consult the tables again where it can't find the match last time. >>> >>> Could anyone please explain the scenario and validate the spec lines? >>> >>> Thanks & Regards, >>> Mrinmoy >>> >>> _______________________________________________ >>> openflow-discuss mailing list >>> openflow-discuss@lists.stanford.edu >>> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss >>> >>> >> >> >> -- >> Eder Leão Fernandes >> >> Bacharelado em Ciências de Computação >> Instituto de Ciências Matemáticas e de Computação >> Universidade de São Paulo >> >> > -- Eder Leão Fernandes Bacharelado em Ciências de Computação Instituto de Ciências Matemáticas e de Computação Universidade de São Paulo
_______________________________________________ openflow-discuss mailing list openflow-discuss@lists.stanford.edu https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
