On Thu, Sep 29, 2016 at 04:40:04PM +0530, Sravya Chava/HYD/TCS wrote:
> Hi Ben en all,
>
> With reference to the OpenFlow Specification version 1.5 we have picked up
> the Implementation for B.18.4 Flow Entry Statistics Trigger EXT-335.
> we are reaching out to you to correct our understanding on the above
> requirement and help us clarify our Open questions for the same.
>
> Technical Understanding from the EXT-335
>
> 1. From the specification it is understood that this new Instruction
> "OFPIT_STAT_TRIGGER" is a mechanism to synchronously send Flow entry
> thresholds statistics to the Controller(which is currently an application
> overhead).
> 2. From the Implementation perspective there will be two defined trigger
> flags to allow updated thresholds to be sent out periodically or as requested
> by the Controller.
> So here are the Bitmaps representation with the below Instruction and Flow
> statistics structure:
> 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*/
> };
> /* Flow statistics structure - list of statistic fields. */
> struct ofp_stats {
> uint16_t reserved;
> uint16_t length;
> uint8_t oxs_fields[0]; /* 0 or more OXS stat fields */
> uint8_t pad[4];
> };
> struct ofp_instruction_stat_trigger {
> uint16_t type; /* *OFPIT_STAT_TRIGGER* */
> uint16_t len;
> uint32_t flags;
> struct ofp_stats thresholds;
> };
>
> 3. The above mechanism needs to be handled for Single flow messages as
> well as for Multipart
I don't understand the distinction you're making here. What is a single
flow message? What is a multipart flow message?
> and the message is a status generated when one of the flow statistic
> threshold was crossed in a stat trigger instruction . /* Reason for
> generating flow stats. */ enum ofp_flow_stats_reason {
> OFPFSR_STATS_REQUEST = 0, /* Reply to a OFPMP_FLOW_STATS request. */
> OFPFSR_STAT_TRIGGER = 1, /* Status generated by OFPIT_STAT_TRIGGER. */
> };
>
> Let us know if the above artifacts holds good to our understanding on the
> implementation or we missing something.
>
> Open Questions:
>
> 1. We are unclear on what is the mechanism of sending these updates to
> controller based on the "various statistics thresholds"?
>
> Could you please clarify on the calculation mechanism or there are
> predefined values which can be compared to check this operation ?
I don't understand the question. The instruction defines the
thresholds. The specification includes this example:
The thresholds is a list of statistic field thresholds. When one of
the statistic field values of the flow entry crosses its threshold a
stat trigger event is sent to the controller. The flow entry is
unmodified by this operation. For example, if the threshold list
includes a byte count of 10000, when the flow entry byte count goes
from 9000 to 10500, a message must be generated.
> How is the Controller keeping a Count / Monitor these OXS thresholds ?
> Or is it proactively sent once the Event is triggered based on the above
> Flags?
I don't think that the controller keeps track of anything. Instead, the
switch sends a multipart flow stats message when a trigger threshold is
crossed:
When a stat trigger event must be sent to the controller, the switch
must add a flow stats entry with reason OFPFSR_STAT_TRIGGER in a
flow stats multipart message (see 7.3.5.3), and that message must be
sent to the controller.
> 2. From the Implementation perspective we should be comparing the
> ofp-flow-stats values [Duration(secs/nsecs), idle_timeout, packet_count,
> byte_count etc.]
> for every OFPT_FLOW_MOD, OFPT_MULTIPART_REQUEST(currently not been
> supported) and then based on "any one threshold change" Or "Multiple
> Threshold changes" set the OFPSTF_ONLY_FIRST and OFPSTF_PERIODIC
> accordingly. Correct my understanding for the same ?
I don't understand the question. Thresholds are triggered by packets,
not by controller requests.
> 3. Kindly help explain the given statement from the specification and where
> does it apply from the messaging persepctive
> "The switch may drop or delay any stat trigger event
> due to congestion and backup on the control channel or to optimize usage of
> the control channel. A
> controller is strongly advised to use this instruction in such a way that the
> event rate is manageable by
> the switch. "
If the switch can't send a multipart flow stats message resulting from a
trigger immediately, because its TCP socket buffer is full, it can send
it later or drop it.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
