First of all thanks Iwase for your reply to this thread.

Yes, currently we do not have a functional code which supports all the 
features supporting the OF version 1.5.
And that is the reason we are planning to implement the EXT features to 
support the handling of Flow statistics for flexible encoding fro Egress 
tables which is currently not been supported.

I have gone through the OFV1.5 Specification for EXT-334 and EXT-335 and 
started with prototyping the features requirement code and will share with 
you once the patch with the EXT-335 is available.
The idea is to test the RYU controller with the EXT-335 switch 
functionality so that it becomes easy to validate the requirement and to 
check how the statistics is responded to the controller.

The below query was to understand on the bitmap flags and how are the 
thresholds been calculated to decide on the setting of the bitmap flags 
and under what conditions the OXS stats are responded as part of the FLOW 
STATS REPLY (for the corresponding FLOW_MOD).

Primarily i will keep this thread of technical discussion Open for 
discussing the RYU v1.5 changes and how can we leverage the controller 
behavior to be tested with the switch functionality.

Thanks & Regards,
Poonam Ghosh
Technical Architect,TCS

From:   Iwase Yusuke <>
Date:   09/22/2016 06:07 AM
Subject:        Re: [Ryu-devel] Query regarding the Statistics Trigger 
Instruction -- OFPInstructionStatTrigger


On 2016年09月22日 17:08, Poonam Ghosh wrote:
> Hello,
> We have been referring the RYU source code to understand the OF Specific 
instructions primarily OFV1.1, OFV1.2, OFV1.3,OFV1.4 and OFV1.5.
> Currently while simulating the tests with Instruction 
OFPIT_STAT_TRIGGER(Specification EXT-335) we got couple of Open points to 
understand more on the implementation part which needs more clarity to 
> As part of the Specification details for the EXT-335 we understand that 
"This Instruction is primarily required to send out Openflow Extensible 
stats (as part of flexible encoding) to Controller based on certain 
thresholds which are user defined". Please correct my understanding for 
the same?
> So this is how the Instruction looks  with the bitmap Flags shown below:
> enum ofp_stat_trigger_flags {
> OFPSTF_PERIODIC = 1 << 0,   /* Trigger for all multiples of thresholds. 
> OFPSTF_ONLY_FIRST = 1 << 1, /* Trigger on only first reach threshold. */
> };
> /* Instruction structure for OFPIT_STAT_TRIGGER */
> struct ofp_instruction_stat_trigger {
> uint16_t type; /* *OFPIT_STAT_TRIGGER* */
> uint16_t len;
> uint32_t flags;
> struct ofp_stats thresholds;
> };
> OFP_ASSERT(sizeof(struct ofp_instruction_stat_trigger) == 16);
> Based on the above understanding and the current RYU implementation it 
is unclear of how the Flags and thresholds are derived and based on what?
> Because if we really see the RYU python scripts for VERSION1.5 we see 
the hardcoded values for duration, idle_time , flow_count, packet_count, 
and byte_count as part of the OXS fields filling.

What do you exactly mean "hardcoded"?
"OFPStats" class can compose the arbitrary flow stats fields which are 
defined in OpneFlow 1.5.
And the API is similar to OFPMatch.

> For our understanding we are not clear on how can we decide on the above 
Fields of when the Instruction trigger needs to set the*PERIODIC FLAG* or 
*ONLY_FIRST* flag as part of the FLOW_STATS REPLY To controller.

For example, if you want to send the OFPIT_STAT_TRIGGER instruction with 
the PERIODIC flag and
packet_count=100 in the stats field:
    instructions = [

BTW, unfortunately we haven't found the switch implementation which fully 
supports OpenFlow 1.5
including EXT-335.
Do you know or have any implementation for supporting OpenFlow 1.5?


> Much appreciate your response for the same.
> Thanks & Regards
> Poonam Ghosh
> Technical Architect, TCS
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
> _______________________________________________
> Ryu-devel mailing list

Ryu-devel mailing list

Reply via email to