Flow-mod replies? Maybe because they are associated with a Flow-removed message sent by the switch? Not sure. Usually, messages initiated by the controller that don't expect a reply, should have xid=0 if I'm not mistaken.
The buffer_id is necessary if the switch is configured to buffer packets so that the controller doesn't have to send the whole packet back to the switch in a Packet-Out message. You want to match Openflow "requests and responses", those ones usually have a xid (because the reply is for a specific request). However, symmetric messages don't expect a reply, so the xid is always 0. Have you read the openflow spec? Section 6.1 covers this in a succinct way. https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.4.0.pdf Nikos Anastopoulos <n.anas...@gmail.com> escreveu no dia quarta, 4/05/2016 às 14:20: > 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
