[ovs-dev] Openflow 1.4: Eviction mechanism implementation

Saloni Jain saloni.jain at tcs.com
Fri Aug 22 11:47:32 UTC 2014


 
Thanks Ben for your reply.

Dear Ben/Team,

Kindly validate following approach for implementation of eviction mechanism and vacancy events as specified in openflow specification 1.4.
According to specification eviction and vacancy events are set through table_mod messages. 

Based on this scenerio, there are two cases:

CASE 1: When both Eviction and Vacancy Events are set.
When the remaining space in flow table decreases to vacancy_down, a vacancy down event is generated and sent to the controller. 
This will start Eviction mechanism on the switch. 
Eviction will be performed on the basis of "importance" or "lifetime" or both. If "importance" flag is the only flag set, flow entry with less importance will be deleted and comparison is done between the current vacancy and vacancy_up value. 
If current vacancy is less than vacancy_up value, vacancy_up events are generated. Otherwise eviction process will be continued till vacancy_up events are generated. 
In the above scenerio for flow entries with same importance, "priority" field in flow table is taken into consideration. Flow entry with less priority will get deleted before flow entry with higher prority.
 If in case, for flow entries having same value of importance and priority, an offset value obtained by dividing counter field(no. of packets passed using that flow entry) by the age(time duration/age of the flow entry) is calculated. Flow entry having less value of the offset will be evicted first. 


CASE 2: When only Eviction is set.
If "importance" flag is the only flag set, flow entry with less importance will be deleted. 
For flow entries with same importance, "priority" field in flow table is taken into consideration. Flow entry with less priority will get deleted before flow entry with higher prority.
If in case, for flow entries having same value of importance and priority, an offset value obtained by dividing counter field(no. of packets passed using that flow entry) by the age(time duration/age of the flow entry) is calculated. Flow entry having less value of the offset will be evicted first.

Kindly suggest at what percentage eviction should be done in this scenerio when vacancy events are not set ?

For the case when both importance and lifetime flags are set for eviction. First eviction will be done on the basis of "importance". For flow entries having same value of "importance", "lifetime"(hard_timeout and idle_timeout) will be considered. Flow entries with same value of importance and lifetime, priority field in the flow entry will be considered.If in case, for flow entries having same value of importance, lifetime and priority, an offset value obtained by dividing counter field(no. of packets passed using that flow entry) by the age(time duration/age of the flow entry) is calculated. Flow entry having less value of the offset will be evicted first.
Please provide your inputs for this case as well.

It will be great help if someone can review the approach as early as possible, it will help us to fasten our implementation process.

Thanks and Regards,
Saloni Jain
Tata Consultancy Services
Mailto: saloni.jain at tcs.com
Website: http://www.tcs.com
____________________________________________
Experience certainty.	IT Services
			Business Solutions
			Consulting
____________________________________________

-----"dev" <dev-bounces at openvswitch.org> wrote: -----
To: Shashwat Srivastava <shashwat.srivastava at tcs.com>
From: Ben Pfaff 
Sent by: "dev" 
Date: 08/11/2014 10:46PM
Cc: dev at openvswitch.org
Subject: Re: [ovs-dev] Openflow 1.4: Eviction mechanism implementation

On Fri, Aug 08, 2014 at 05:39:26PM +0530, Shashwat Srivastava wrote:
> I want to incorporate "Eviction mechanism" as per the openflow 
> specification 1.4
> 
> As per the openflow specification 1.4 (Section 7.3.4.1), there are three 
> eviction flags: importance,lifetime and other. If importance flag is the 
> only flag set (lifetime and others not set), eviction is performed 
> strictly in order of importance field specified in flow entry, that is 
> flow entry with lower importance will be evicted before flow entry with 
> higher importance. 
> 
> But if all flow entries are of same importance, it has been specified that 
> "the eviction mechanism is switch defined ", therefore it is not possible 
> to predict in which order flow entries of same importance will get 
> evicted.
> At present (without implementation of eviction), when a flow table is 
> full, new flow entries are not inserted in the flow table and an error is 
> returned to the controller, controller needs time to work on flow table 
> and thus may cause a disruption of service. Does this means that, users 
> should therefore take care to use importance field wisely to ensure the 
> behaviour they expect and avoid disruption of service. It would be great 
> help if someone could explain how eviction will be done in this case.
> 
> Also kindly suggest action when both the flags for importance and lifetime 
> are simultaneously set, as this is missing in the openflow specification 
> 1.4 

Open vSwitch already implements eviction that can be configured to
meet the requirements of "other" and "lifetime" based eviction.  I
believe that all that we would have to do to comply with OpenFlow 1.4
in this area is to make the feature configurable via the OpenFlow 1.4
table_mod message.

OpenFlow 1.4 does not appear to define how "importance" interacts with
the "lifetime" and "other" eviction policies. ÿIf we implement
importance-based eviction, we will have to decide what would be most
useful for our users.
_______________________________________________
dev mailing list
dev at openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
=====-----=====-----=====
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





More information about the dev mailing list