A Point of View
Enabling Optimized Network Operations
The Eviction Mechanism Approach to Managing Data Flows based on Importance
Introduction
The explosive growth in the number of users along with different types of network traffic such as YouTube, Skype, and chat pose a real
danger of bringing network traffic to an abrupt halt. This can happen in a switch or router based network if the actual number of data flows
exceeds the maximum number of flows the switch is equipped to handle. This essentially means that new data flows cannot be added to the
network beyond the specified limitation. To prevent this abrupt halt of network traffic and business disruption, existing data flows need to be
removed from the switch in order to accommodate the new ones.
Application interfaces such as OpenFlow help Software Defined Networks (SDNs) communicate with the switches and routers. As per
OpenFlow Specification 1.0 to 1.3,¹ data flow can be removed from the switch in only one of two ways:
n
Defining a flow expiry mechanism where the flow 'expires' upon reaching the hard or idle timeout. This timeout is defined by the user
while configuring the flow. When the idle or hard timeout is not defined, the flows are not removed unless the controller deletes them,
and therefore, they end up occupying space in the flow table.
n
Data flow eviction can also take place at the request of the controller.
OpenFlow Switch Specification 1.4² introduces a third option called the 'Eviction Mechanism' that can be used to remove excess data flows
based on any one of the three parameters. These parameters fall under three categories – importance of the data flow, lifetime of the data
flow, and other parameters. Importance is a new eviction precedence field added under specification 1.4.
When an eviction mechanism is enabled on the basis of importance as per OpenFlow switch specification 1.4, the switch deletes flows of
lesser importance as defined at the time of configuring the flow. However, the specification does not provide a preferred option in cases
where flows of the same importance are encountered.
This paper proposes an approach for data flow eviction when data flows with the same level of importance are encountered. There are many
switches that are capable of supporting OpenFlow specification 1.4. However, we have considered only Open vSwitch for the purpose of
this paper.
Understanding Data Flow Eviction
In the SDN approach to network management, networks are decoupled into two layers – the Control layer and the Data Link layer. As a result,
the SDN needs a mechanism to communicate between the Control and Data Link layers. OpenFlow protocol is one of the several methods
that can be used for enabling such communication. The connection between the controller and the switch is managed by a secure channel.
In the case of data flows written in an OpenFlow enabled switch of specifications (1.0 to 1.3), whenever a flow table is full, the switch
drops new flow entries irrespective of their priority. Old flows need to be manually removed from the flow table. This affects the quality of
network service.
[1] Open Networking Foundation, OpenFlow Switch Specification Version 1.0.0, December 31, 2009,
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.0.0.pdf. OpenFlow, OpenFlow Switch
Specification Version 1.1.0, February 28, 2011,
http://archive.openflow.org/documents/openflow-spec-v1.1.0.pdf. Open Networking Foundation, OpenFlow Switch Specification Version 1.2.0, December 5, 2011,
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.2.pdf. Open Networking Foundation,
OpenFlow Switch Specification Version 1.3.0, June 25, 2012,
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.3.0.pdf
[2] OpenFlow Switch Specification Version 1.4.0, Open Networking Foundation, October 14, 2013,
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.4.0.pdf
The newly introduced eviction mechanism for data flows in OpenFlow enables the switch to automatically eliminate entries of lesser
importance in order to make space for newer entries. This enables smoother degradation in performance when the table is full.
Here are some of the key concepts used in the eviction of data flows.
Flow Table
A flow table is a list of flows where the flow is defined as a rule consisting of match fields and a set of instructions to be performed on the
matching packet. There are a maximum of 255 flow tables in a switch, and if they are not specified, all flow entries are entered in Table 0.
The components of a flow table are given in Figure 1.
Match Fields
Priority
Counters
Instructuons
Timeouts
Cookies
Figure 1: Main components of flow table
In the Open vSwitch, the flow table contains the flow entries written by the controller. The incoming packets to the switch are matched with
the configured flow entries, and actions are performed when packets are matched. If there is no matching flow entry, the packet acts as per
the preset table-miss flow entry conditions. This means that it can be sent to the controller over a secure channel, dropped, or forwarded to
the next flow-table. When the packet reaches the controller, the controller can add or update the flow entry both reactively and proactively.
Flow Removal
In OpenFlow Switch Specification 1.4,⁴ a flow entry can be removed from the flow table in one of the following three ways:
n
At the request of the controller directly by sending a 'delete' message
n
By switching the flow expiry mechanism
n
By an optional switch eviction mechanism
Table 1 explains the flow removal by flow expiry mechanism.
In the case of flow removal using the eviction mechanism, eviction can be done based on three parameters –lifetime, importance, and other
Timeout Cases
OpenFlow (OF)
Parameter Definition
Results
Hard timeout
OF.Hard_timeout=20
OF.Idle_timeout=0
The flow expires after 20 seconds.
Idle timeout
OF.Hard_timeout=0
OF.Idle_timeout=20
The flow expires when none of the packets are matched through the flow for the last 20
seconds.
Hard timeout
Idle timeout
OF.Hard_timeout=20
OF.Idle_timeout=10
The flow expires after 20 seconds or if packets have not been matched through this flow
for the last 10 seconds.
Hard timeout
Idle timeout
OF.Hard_timeout=10
OF.Idle_timeout=20
The flow expires after 10 seconds, irrespective of any packets passing through that flow.
Table 1: Flow expiry mechanism
[4] Open Networking Foundation, OpenFlow Switch Specification Version 1.4.0, October 14, 2013,
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.4.0.pdf
2
parameters. Flows with lower lifetime are evicted when the eviction is based on the lifetime parameter. Similarly, flows of lower importance
are evicted when eviction is based on the importance of data flows. Finally, in the case of eviction based on other parameters, the
specification remains silent.
The Challenge: Enabling Optimized Network Operations
As mentioned earlier, multiple users and different types of traffic requests can cause a data flow overload that can bring a network to a
grinding halt. It therefore becomes necessary to manage data flows optimally for superior network performance. The problem arises when
an add-flow request is generated and the following events occur simultaneously:
n
The flow-table is full
n
Eviction is enabled on the basis of importance
n
The same value of importance is assigned for the least important flows
In this case, the behavior of OpenFlow switch is not defined under OpenFlow specification 1.4 on how to delete the flow entry. The next
section discusses an approach that can be leveraged to resolve this problem.
Using the Eviction Mechanism in OpenFlow: A Suggested Approach for Leveraging the New Feature
This approach applies when the eviction mechanism is set for eviction based on the importance of data flows and it encounters flows of the
same importance. In this case, the switch checks the priority of encountered flows and evicts the flow with the least priority. If the data flows
have the same priority, then the switch calculates an offset value and the flow with the lower offset value is evicted.
The following formula is used for calculating the offset value:
The four use cases given below further elaborate the approach to eviction based on importance.
offset =
Number of packets passed matching the flow
duration of flow
Use Case #1
Let's assume that the switch can handle only four flows with the importance and priority set as follows:
Flow 1 – importance 96, priority = 10
Flow 2 – importance 97, priority = 11
Flow 3 – importance 98, priority = 12
Flow 4 – importance 99, priority = 12
A new flow with an importance value of 95 enters the switch, but there is no space available in the switch to accommodate it. As the value of
importance for the incoming flow is lower than the least value of importance for existing flows, the incoming flow is discarded.
3
The path followed for this scenario is depicted by a dotted line in Figure 2.
Incoming flow
of lower importance
than existing flows
Switch
No
If space in
flow table
Check
importance
Yes
As the flow is of
lower importance
Eviction
mechanism
Error
message
Add
flow
Check
importance
Delete flow of
lowest
importance
Check
priority
Calculate
offset
Delete flow of
lower priority
Delete flow
of lower
offset
Add
flow
Add
flow
Add
flow
Figure 2: Flow chart depicting flows encountered with lower importance
Use Case #2
Again, we assume that the switch can handle only four flows with importance and priority set as follows:
Flow 1 – importance 96, priority = 10
Flow 2 – importance 96, priority = 10
Flow 3 – importance 98, priority = 12
Flow 4 – importance 99, priority = 11
Let's say a new flow with importance 97 enters the switch and there is no space currently available in the switch. As per the flow table entries,
two flows (Flow 1 and Flow 2) have the same level of importance and priority value. In this case, the value of offset (determined as per the
formula shown above) decides which of the flows with equal importance (of 96) is replaced by the new incoming flow.
4
The path followed for this scenario is depicted by the dotted line in Figure 3.
Incoming flow
of higher importance
than existing flows
Switch
No
If space in
flow table
Flow with
higher importance
Check
importance
Eviction
mechanism
Yes
As the flow is of
lower importance
Error
message
Add
flow
Flow with
same importance
Flow with
same priority
Check
priority
Check
importance
Flow with
different importance
Flow with
different priority
Delete flow of
lowest
importance
Calculate
offset
Delete flow of
lower priority
Delete flow
of lower
offset
Add
flow
Add
flow
Figure 3: Flow chart depicting flows encountered with the same importance and same priority
Use Case #3
In this scenario, let's again assume that the switch can handle only four flows with importance and priority set as follows:
Flow 1 – importance 96, priority = 10
Flow 2 – importance 96, priority = 13
Flow 3 – importance 98, priority = 12
Flow 4 – importance 99, priority = 11
5
Add
flow
A new flow with importance 98 enters the switch and there is no space available in the switch to accommodate it. In this case, the flow with
less importance and lower priority (Flow 1) is evicted. This scenario is depicted by the dotted path in Figure 4.
Incoming flow
of same importance
than existing flows
Switch
No
If space in
flow table
Flow with
higher importance
Check
importance
Eviction
mechanism
Yes
As the flow is of
lower importance
Error
message
Add
flow
Flow with
same importance
Flow with
same priority
Check
priority
Check
importance
Flow with
different importance
Flow with
different priority
Delete flow of
lowest
importance
Calculate
offset
Delete flow of
lower priority
Delete flow
of lower
offset
Add
flow
Add
flow
Add
flow
Figure 4: Flow chart depicting flows encountered with same importance and different priority
Use Case #4
For our final use case, we are yet again assuming that the switch can handle only four flows with importance and priority set as follows:
Flow 1 – importance 96, priority = 10
Flow 2 – importance 97, priority = 13
Flow 3 – importance 98, priority = 12
Flow 4 – importance 99, priority = 11
A new flow with importance 96 enters the switch and there is no space in the switch. In this case, as the importance value of the new flow
and the lowest importance value of the flows in the flow-table are the same, the switch checks the priority of the flow. If the new flow has
priority greater than 10, an existing flow (Flow 1) is evicted from the flow table and the new flow is added. In case the new flow has a priority
value of less than or equal to 10, the new flow is discarded.
6
This is depicted by the dotted line in Figure 5.
Incoming flow
of same importance
than existing flows
Switch
If space in
flow table
Yes
No
Check
importance
Flow with
same or higher
importance
As the flow is of
lower importance
Check
importance
Flow with
higher importance
Flow with
same importance
Error
message
Add
flow
Flow with same/
lower priority
Check
priority
Flow with
higher priority
Eviction
mechanism
Error
message
Check
priority
Calculate
offset
Delete flow of
lowest
importance
Check
priority
Calculate
offset
Delete flow of
lower priority
Add
flow
Delete flow
of lower
offset
Add
flow
Add
flow
Figure 5: Flow chart depicting flows encountered with different or same importance and different or same priority
Driving Business Agility
As virtualization and cloud computing become pervasive, there is a growing need for automation and rapid deployment of services.
Technologies such as SDN controllers help businesses gain increased business agility by separating network services and traffic management
from the underlying hardware. They enable the design of flexible and scalable networks that can readily adapt to evolving business
requirements. When adopting a switch-based approach to network design, it is imperative that data flows are optimized. Businesses that
adopt a combination of the eviction mechanism option provided by Open vSwitch and our suggested approach will be able to prioritize
data flows based on their importance. This will enable them to gain enhanced efficiencies and optimized network operations for better
business outcomes.
7
About the Authors
Shashwat Srivastava
Shashwat Srivastava is a developer in the Telecom business unit at Tata Consultancy Services (TCS), focusing on technologies such as IPnetworking, routing and switching, WLAN, and SDN products. Srivastava contributes to next generation technologies and is also an active
member in open source forums such as the Open vSwitch.
Chhavi Kant
Chhavi Kant is a developer in the Telecom business unit at TCS, focusing on technologies such as SDN, Chef, routing and switching, IPnetworking, and WLAN. Over the last two years, Kant has been a key contributor to next generation technologies.
Sheena Goyal
Sheena Goyal is a developer in the Telecom business unit at TCS, focusing on SDN products such as OpenDaylight, Floodlight, and other
vendor specific SDN controllers. Goyal has been contributing to next generation technologies and is also an active member of open source
forums such as OpenDaylightController.
7
About TCS' Telecom Business Unit
For over three decades, TCS has worked with companies in the Communications industry, helping them
develop world class solutions and systems, simplify operations, augment network services, diversify into
new markets, and stay ahead of the competition.
Our solutions address the entire landscape of telecom businesses, ranging from greenfield start-ups to large
cable and satellite companies and equipment vendors. Our partnership model leverages ready-to-deploy
platform solutions, proprietary frameworks, and solution accelerators to enable our clients to launch new
products and services quickly.
TCS' investments in next generation platforms, mobility solutions, capabilities, and lab infrastructure are
aligned to address our clients' key business imperatives of operational excellence, customer experience, and
revenue enhancement. We have helped enterprises unlock business value in the areas of Digital Channel
and Commerce, Customer Insights, Mobility Solutions, Hosted OSS/BSS (HOBS), IOT & M2M Platforms,
Connected Device Management, B2B Platform Ecosystem and Services and Network Abstraction layers.
Contact
For more information about TCS’ Telecom Business Unit, visit:
http://www.tcs.com/industries/telecom/Pages/default.aspx
Email: global.telecom@tcs.com
About Tata Consultancy Services Ltd (TCS)
Tata Consultancy Services is an IT services, consulting and business solutions organization that
delivers real results to global business, ensuring a level of certainty no other firm can match.
TCS offers a consulting-led, integrated portfolio of IT and IT-enabled infrastructure, engineering
and assurance services. This is delivered through its unique Global Network Delivery ModelTM,
recognized as the benchmark of excellence in software development. A part of the Tata Group,
India’s largest industrial conglomerate, TCS has a global footprint and is listed on the National
Stock Exchange and Bombay Stock Exchange in India.
IT Services
Business Solutions
Consulting
All content / information present here is the exclusive property of Tata Consultancy Services Limited (TCS). The content / information contained here is
correct at the time of publishing. No material from here may be copied, modified, reproduced, republished, uploaded, transmitted, posted or distributed in
any form without prior written permission from TCS. Unauthorized use of the content / information appearing here may violate copyright, trademark and
other applicable laws, and could result in criminal or civil penalties. Copyright © 2015 Tata Consultancy Services Limited
TCS Design Services I M I 07 I 15
For more information, visit us at www.tcs.com