Software-defined networking (SDN) abstracts low-level network functionalities to simplify network management and reduce costs. The OpenFlow protocol implements the SDN concept by abstracting network communications as flows to be processed by network elements. In OpenFlow, the high-level policies are translated into network primitives called rules that are distributed over the network. While the abstraction offered by OpenFlow allows to potentially implement any policy, it raises the new question of how to define the rules and where to place them in the network while respecting all technical and administrative requirements. In this paper, we propose a comprehensive study of the so-called OpenFlow rules placement problem with a survey of the various proposals intending to solve it. Our study is multifold. First, we define the problem and its challenges. Second, we overview the large number of solutions proposed, with a clear distinction between solutions focusing on memory management and those proposing to reduce signaling traffic to ensure scalability. Finally, we discuss potential research directions around the OpenFlow rules placement problem.

https://hal.inria.fr/hal-01251249/document

Rules Placement Problem in OpenFlow Networks: A Survey

STAR: Preventing flow-table overflow in software-defined networks

OpenFlow networks require installation of flow rules in a limited capacity switch memory (Ternary Content Addressable Memory or TCAMs, in particular) from a logically centralized controller. A controller can manage the switch memory in an OpenFlow network through events that are generated by the switch at discrete time intervals. Recent studies have shown that data centers can have up to 10,000 network flows per second per server rack today. Increasing the TCAM size to accommodate these large number of flow rules is not a viable solution since TCAM is costly and power hungry. Current OpenFlow controllers handle this issue by installing flow rules with a default idle timeout after which the switch automatically evicts the rule from its TCAM. This results in inefficient usage of switch memory for short lived flows when the timeout is too high and in increased controller workload for frequent flows when the timeout is too low.In this context, we present SmartTime - an OpenFlow controller system that combines an adaptive timeout heuristic to compute efficient idle timeouts with proactive eviction of flow rules, which results in effective utilization of TCAM space while ensuring that TCAM misses (or controller load) does not increase. To the best of our knowledge, SmartTime is the first real implementation of an intelligent flow management strategy in an OpenFlow controller that can be deployed in current OpenFlow networks. In our experiments using multiple real data center packet traces and cache sizes, SmartTime adaptive policy consistently outperformed the best performing static idle timeout policy or random eviction policy by up to 58% in terms of total cost.

/pdf/effective-switch-memory-management-in-openflow-networks-3n0ybbelyf.pdf

Effective switch memory management in OpenFlow networks

Software Defined Networks (SDN) such as OpenFlow provides better network management for data center by decoupling control plane from data plane. Current OpenFlow controllers install flow rules with a fixed timeout after which the switch automatically removes the rules from its flow table. However, this fixed timeout has shown many disadvantages. For flows with short packet interval, the timeout may be too large so that flow rules stay in the flow table for too long time and result in unnecessary occupation of flow table; for flows with long packet interval or periodic flows, the timeout may be too short, hence producing too many packet-in events and causing overload on the controller. In this paper, we propose the Intelligent Timeout Master, which can assign suitable timeout to different flows according to their characteristics, as well as conduct a feedback control to adjust the max timeout value according to the current flow table occupation, in an effort to avoid flow table overflow. In our experiments, we use real traffic trace and the result confirms that our Intelligent Timeout Master performs quite well in reducing the number of packet-in events as well as flow table occupation.

Intelligent timeout master: Dynamic timeout for SDN-based data centers

JumpFlow: Reducing flow table usage in software-defined networks

This paper explores the impact of the timeout length on performance, measured through the miss rate, and table occupancy. It finds that as timeouts increase, the miss rate decays exponentially while the table size grows near-linearly. We observe there is an operating point where any further increases in the timeout lead to insignificant reductions in the miss rate while unnecessarily swelling expanding the table occupancy. In one dataset this timeout is at 5 seconds, while it is centered around 10 for three others. Additionally, this paper introduces hybrid flow table management that combines timeouts with explicit controller eviction messages. It establishes a lower bound of 57% fewer table entries in one dataset without impacting the miss rate, while a practical TCP-based implementation reduces the table size by 42%, or almost 32,000 entries. Finally, this work compares the performance of different flow table replacement policies. It identifies that while LRU outperforms the other policies, it cannot be implemented in current OpenFlow switches. A FIFO replacement policy performs [AZ: number!] worse than LRU but less than 0.1% better than Random replacements. Based on our observations, the future of OpenFlow timeouts is to delegate the responsibility of assigning timeouts to a controlloop within the controller so the timeout can both be dynamically tuned to individual flows, as well as individual network requirements.

Adam Zarek

Papers

OpenFlow Timeouts Demystied