Hi Rean,
Some comment inline. Hope they are useful.
> 2) When NOX delivers an event to a component, is there a way to
> access/check the xid associated with the event message or is this
> information stripped off by the controller before passing the event onto
> the component?
>
> Looking at the guts of a port stats reply event it looks like the low
> level details like xid either a) were not set automatically b) have been
> stripped off before handing the event to the component or c) may be
> hidden behind the opaque pyevent*:
>
> {'this': <Swig Object of type 'pyevent *' at 0xadc58d8>, 'datapath_id':
> 150874213227L, 'ports': [{'rx_over_err': 0L, 'tx_dropped': 0L,
> 'rx_packets': 0L, 'rx_frame_err': 0L, 'rx_bytes': 0L, 'tx_errors': 0L,
> 'rx_crc_err': 0L, 'collisions': 0L, 'rx_errors': 0L, 'tx_bytes': 1380L,
> 'rx_dropped': 0L, 'tx_packets': 69L, 'port_no': 0}, {'rx_over_err': 0L,
> 'tx_dropped': 0L, 'rx_packets': 0L, 'rx_frame_err': 0L, 'rx_bytes': 0L,
> 'tx_errors': 0L, 'rx_crc_err': 0L, 'collisions': 0L, 'rx_errors': 0L,
> 'tx_bytes': 1360L, 'rx_dropped': 0L, 'tx_packets': 68L, 'port_no': 1}]}
The C/C++ components see the xid since Ofp_msg_event has buf object
that contains all the bytes of the packet. Feel free to parse xid and
export this to Python via swig. Patches are gladly accepted.
> 3) If a stats request message goes unanswered does a subsequent stats
> request message to the same switch supersede it. In the toy example does
> stats_req2(sw2) cause any late replies to stats_req1(sw2) to be
> ignored/dropped?
Each stats request should be treated independently. As it stands,
OpenFlow does not ensure order of execution, i.e., req2 can be
processed after req1. If you want to ensure order, use the barrier
request. Not sure what switches you are using, but do check that
barrier is supported.
> 4) Do stats request messages time out? If so is there a way to be
> notified of the time out?
Not that I know of. In OpenFlow, it is perfectly valid for a switch
to decide that it cannot handle the stat request and discard it. You
can't really know without sending a barrier request again. Finger
crossed on it being supported in your platform, again.
Regards
KK
On 8 March 2010 21:05, Rean Griffith <[email protected]> wrote:
> Hello all,
>
> I am currently building a monitoring component on top of NOX.
>
> As part of monitoring I am trying to make use of the transaction id
> field (xid) in open flow messages to detect whether stats replies from
> switches are being lost, delayed or re-ordered.
>
> The simplified scenario we have in mind is shown below where stats
> replies from a switch are delayed or reordered:
>
> collection
> window
> (time t): | t=1 | t=2
> switch 1: | stats_req1(sw1) | stats_req2(sw1)
> | stats_reply1(sw1) | stats_reply2(sw1)
> -----------------------------------------------------------
> switch 2: | stats_req1(sw2) | stats_req2(sw2)
> | [reply delayed] | stats_reply1(sw2), stats_reply2(sw2) OR
> | | stats_reply2(sw2), stats_reply1
>
>
> I have 4 questions about event delivery in NOX:
>
> 1) When stats request messages are issued from a python component is a
> transaction id (xid) set in the openflow message header automatically by
> the underlying controller/C++ plumbing? Are there any examples in python
> of setting the xid on an outgoing stats request message (or other type
> of openflow message)? The ripcord flowinstaller is close just wondering
> if a better example existed?
>
> 2) When NOX delivers an event to a component, is there a way to
> access/check the xid associated with the event message or is this
> information stripped off by the controller before passing the event onto
> the component?
>
> Looking at the guts of a port stats reply event it looks like the low
> level details like xid either a) were not set automatically b) have been
> stripped off before handing the event to the component or c) may be
> hidden behind the opaque pyevent*:
>
> {'this': <Swig Object of type 'pyevent *' at 0xadc58d8>, 'datapath_id':
> 150874213227L, 'ports': [{'rx_over_err': 0L, 'tx_dropped': 0L,
> 'rx_packets': 0L, 'rx_frame_err': 0L, 'rx_bytes': 0L, 'tx_errors': 0L,
> 'rx_crc_err': 0L, 'collisions': 0L, 'rx_errors': 0L, 'tx_bytes': 1380L,
> 'rx_dropped': 0L, 'tx_packets': 69L, 'port_no': 0}, {'rx_over_err': 0L,
> 'tx_dropped': 0L, 'rx_packets': 0L, 'rx_frame_err': 0L, 'rx_bytes': 0L,
> 'tx_errors': 0L, 'rx_crc_err': 0L, 'collisions': 0L, 'rx_errors': 0L,
> 'tx_bytes': 1360L, 'rx_dropped': 0L, 'tx_packets': 68L, 'port_no': 1}]}
>
> 3) If a stats request message goes unanswered does a subsequent stats
> request message to the same switch supersede it. In the toy example does
> stats_req2(sw2) cause any late replies to stats_req1(sw2) to be
> ignored/dropped?
>
> 4) Do stats request messages time out? If so is there a way to be
> notified of the time out?
>
> by the way, which mailing list is appropriate for these kinds of questions?
>
> thanks,
> Rean
>
> _______________________________________________
> nox-dev mailing list
> [email protected]
> http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>
_______________________________________________
nox-dev mailing list
[email protected]
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
