How to listen to MESSAGE_TX Events

[checho]

Hi, 

My application is able to listen to Error Messages by implementing the MessageListener interface. Whenever an error occurs due to FLOW_MOD_FAILED#TABLE_FULL I am able to get the RX message and extract info like the transaction id (xid). However, in order for the xid to be useful, I'd need to store or know info about the corresponding TX message that caused the error (in particular the cookie value of the sent flow mod). How to do that?

HP's API doc states "Note that the MESSAGE_TX event type will never be seen by a message listener;" so I don't know how to get it.

One solution is to sendConfirmedFlowMods but due to its blocking nature my application significantly slows down. Errors are not frequent and that's why I use unconfirmed flowmods but I do need to capture them when the table is full.  

Thanks in advance. 

Checho

[ShaunWackerly]

Hi checho,

The VAN controller is designed to achieve significant performance in regard to packet processing (packet-in, packet-out) to exceed 2 million packets per second. Therefore we do not support a message listener that will listen on TX because that would slow the processing.

For your solution, would it be an acceptable workaround to do the following?

Workaround option #A:

1. Create a MessageListener and listen for an error response
2. Start sending unconfirmed flowmods, remembering the order they were sent
3. When an error response is received, change to confirmed flowmods.
4. Work backwards from the most recent flowmod to find which flowmods are rejected. Once you reach a flowmod that is accepted, you'll have the list of flowmods that exceeded the table limit.

Workaround option #B:

1. Create a MessageListener and listen for an error response
2. Start sending unconfirmed flowmods, remembering the order they were sent
3. When an error response is received, query the switch for the flowmods using ControllerService.getFlowStats(DataPathId, TableId).
4. Copy the cookie value from each MBodyFlowStats into a Map.
5. Work backwards from the most recent flowmod to see which cookies exist in the list retrieved from the switch.

We realize the workaround above isn't the most convenient method, and that it would be more convenient to be able to know the transaction ID before the message is sent. However, in order to keep transaction ordering consistent we must generate the transaction ID just prior to sending the message.

By the way, I'm assuming that the flowmods you're using have either a hard_timeout or idle_timeout specified, otherwise your app would know how many flowmods it has pushed to a switch (and therefore how many flows still exist on the switch). Assuming you're using switches with a known table size, you could perform that calculation before ever pushing a flowmod (so you'd never get an ERROR).

Shaun

[checho]

Too bad that it is not possible to listen to TX events but I understand the design decision behind that fact. Thank you for providing us with workarounds. I will get back if we come up with another alternative.