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 < [email protected]> 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 <[email protected]> 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 >> [email protected] >> 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 > >
_______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
