On Tue, May 17, 2016 at 7:14 AM, Ali Volkan Atli <volkan.a...@argela.com.tr> wrote: > > Hi > > What if I want to match packet-in and flow-mod without buffering (buffer_id). > According to OF 1.5.1 spec, the buffer_id refers to a packet buffered at > the switch and sent to the controller by a packet-in message. > If no buffered packet is associated with the flow mod, it must > be set to OFP_NO_BUFFER. > > Spec is not clear for me. If I want to see the whole packet, I set the > table-miss > entry's max_length to OFP_NO_BUFFER, then switch sends packet-in with > buffer-id > set to OFP_NO_BUFFER and the controller also sends flow-mods with buffer-id > set to OFP_NO_BUFFER. In this case, how can I match packet-in and flow-mod? > I think, xid must be used to relate the packet-in and flow-mod. I think, you > are > assigning a different meaning to buffer-id.
As Iwase pointed out on OVS, PacketIn's will always have the xid of 0: https://github.com/openvswitch/ovs/blob/master/lib/ofp-util.c#L3840-L3841 I'm far from an openflow expert, but I don't really think that PacketIn should be thought of as a request/reply, as there was no request from the controller for a reply. It is an asynchronous action as a result of a flow rule. It doesn't matter where that flow came from, it may have come from a controller, or it may have been configured via the cli (or in the case of openflow < 1.3 an implicit table miss action). I'm not sure I understand what you want to do. If you want to react to a PacketIn and install a flow as a result of that (assuming you have the whole packet (OFP_NO_BUFFER)) then you install a flow (the xid doesn't matter, and you don't have to set it, ryu will fill one in during the send), and follow it up with a PacketOut (an example of this is at https://github.com/osrg/ryu/blob/master/ryu/app/simple_switch_13.py#L108-L119). Because OFP_NO_BUFFER was specified it is the responsibility of the controller to buffer the packet data and send it as a PacketOut if the controller wants to forward the packet. If you have multiple actions=CONTROLLER flows and want to know which flow the PacketIn came from, I would suggest allocating a bitmask in the metadata field of the flows and assign each actions=CONTROLLER a bit in that mask, you'll get the metadata field in the PacketIn's match which you can then correlate to the flow that triggered it to send the packet, and then react as you want to. Of course this all assumes OVS, I don't know about hardware implementations but I would assume they would act the similarly. Happy Hacking! 7-11 ------------------------------------------------------------------------------ Mobile security can be enabling, not merely restricting. Employees who bring their own devices (BYOD) to work are irked by the imposition of MDM restrictions. Mobile Device Manager Plus allows you to control only the apps on BYO-devices by containerizing them, leaving personal data untouched! https://ad.doubleclick.net/ddm/clk/304595813;131938128;j _______________________________________________ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
