Thanks for the reply, this makes sense. What still creates some confusion, though, is the fact that ODL controller does use some non-zero xid in its FLOW_MOD replies. But this might be more of ODL's issue.
What I am trying to do is find a simple way to match OpenFlow requests and responses in order to measure latencies. For symmetric messages like ECHO's the xid seems to do the job. For PACKET_IN - FLOW_MOD pairs I might need to use the buffer_id field for the same purpose, but if my understanding is correct, it's up to the controller to request from the switches to use buffering or not (via OFPCML_NO_BUFFER). Is this correct? On Sat, Apr 30, 2016 at 8:17 PM, André Mantas <andremant...@gmail.com> wrote: > Hi. > I think that the xid is only used in messages that are considered > "requests" (mainly from the controller) and require a reply. > Because a PacketIn is not a request, it is an "asynchronous" message, it > is not "mandatory" to set a xid. > > Nikos Anastopoulos <n.anas...@gmail.com> escreveu no dia quinta, > 28/04/2016 às 16:29: > >> Hi, >> >> I am exploring traffic captures from tests with Mininet/Openvswitch 2.5 >> and OpenDaylight controller, and try to understand why the transaction ID >> (xid) field in PACKET_IN messages is always zero, while for the rest >> message types (either switch- or controller-initiated) it is correctly set >> to some unique value, which is reused in the reply as it should. Am I >> missing something basic here specified in the OF protocol, or is it and >> implementation decision of OVS? >> >> Thanks in advance, >> Nikos >> _______________________________________________ >> discuss mailing list >> discuss@openvswitch.org >> http://openvswitch.org/mailman/listinfo/discuss >> >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
