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

Reply via email to