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
