Constructing scalable hierarchical switched openflow network using adaptive replacement of flow table management
01 Dec 2013-pp 1-3
TL;DR: This paper devise a large hierarchical switched network using OpenFlow and propose the concept of adaptive replacement in flow table to evict uncertain flows at a particular time.
Abstract: The need for building large networks is on the rise due to rapid growth of number of internet users and also in data centers where large number of switched networks are formed. Hierarchical structure is the most preferable way of handling complex systems of any kind. Hence in this paper we devise a large hierarchical switched network using OpenFlow and propose the concept of adaptive replacement in flow table to evict uncertain flows at a particular time. Open Flow is a protocol which separates the control plane and data plane which helps in managing flow table and also to place controllers in large hierarchical networks.
Citations
More filters
Patent•
20 Jan 2014TL;DR: In this paper, a method, unit and computer program performed by a packet separation unit in a communications network for enabling of data traffic separation comprising: obtaining a traffic rule set from a rule manager, determining a complementary rule related to the traffic rules set, arranging the rules in an hierarchical order such that a received data packet will be evaluated with the rule with the most likeliness to comply with a received packet, receiving the data packet, directing the packet to a local shared environment.
Abstract: A method, unit and computer program performed by a packet separation unit in a communications network for enabling of data traffic separation comprising: obtaining a traffic rule set from a rule manager, determining a complementary rule related to the traffic rule set, arranging the rules in an hierarchical order such that a received data packet will be evaluated with the rule with the most likeliness to comply with a received data packet, receiving the data packet, directing the data packet to a local shared environment.
1 citations
TL;DR: In this article , a variant of trie based approach was proposed to find a solution for longest prefix match (LPM) problem using GPU in the Switch/Router devices.
Abstract: Due to increases in communication link capacity and growth of the Internet traffic, packet processing like IP address lookup and classification becomes a major concern in the network. The packet processing performed at Switch/Router does not cope up with the growing link speed. Since Graphics processing unit (GPU) has high parallelism and more flexibility for the programmers, it can be used for solving IP address lookup problem in the Switch/Router devices. This paper proposes a variant of trie based approach to find a solution for longest prefix match (LPM) problem using GPU. In this paper, IP address database is partitioned into a different table based on first k bits of IP address, then a variant of trie approach is proposed to find the next hop. The proposed lookup approach shows 64.46% and 94.32% improvement than binary trie and BST implementations.
References
More filters
31 Mar 2008
TL;DR: This whitepaper proposes OpenFlow: a way for researchers to run experimental protocols in the networks they use every day, based on an Ethernet switch, with an internal flow-table, and a standardized interface to add and remove flow entries.
Abstract: This whitepaper proposes OpenFlow: a way for researchers to run experimental protocols in the networks they use every day. OpenFlow is based on an Ethernet switch, with an internal flow-table, and a standardized interface to add and remove flow entries. Our goal is to encourage networking vendors to add OpenFlow to their switch products for deployment in college campus backbones and wiring closets. We believe that OpenFlow is a pragmatic compromise: on one hand, it allows researchers to run experiments on heterogeneous switches in a uniform way at line-rate and with high port-density; while on the other hand, vendors do not need to expose the internal workings of their switches. In addition to allowing researchers to evaluate their ideas in real-world traffic settings, OpenFlow could serve as a useful campus component in proposed large-scale testbeds like GENI. Two buildings at Stanford University will soon run OpenFlow networks, using commercial Ethernet switches and routers. We will work to encourage deployment at other schools; and We encourage you to consider deploying OpenFlow in your university network too
9,138 citations
"Constructing scalable hierarchical ..." refers methods in this paper
...The adaptive replacement flow table management is the efficient way to build flow table in Openflow network....
[...]
...Also the increasing flexibility of Openflow networks can allow flow table with other replacement algorithms such as optimal replacement policy in which we must predict the flow in advance and then the probability distribution of the flow must be maintained....
[...]
...This protocol removes the control plane authority of a switch and also scalability issue to shift it to centralized Openflow controller....
[...]
...To overcome this we use Openflow [1] protocol which separates control plane and data plane in a switch....
[...]
...Hence the same functionality is still obtained with Openflow with less complexity around control plane....
[...]
17 Aug 2008
TL;DR: The experiments show that SEATTLE efficiently handles network failures and host mobility, while reducing control overhead and state requirements by roughly two orders of magnitude compared with Ethernet bridging.
Abstract: IP networks today require massive effort to configure and manage. Ethernet is vastly simpler to manage, but does not scale beyond small local area networks. This paper describes an alternative network architecture called SEATTLE that achieves the best of both worlds: The scalability of IP combined with the simplicity of Ethernet. SEATTLE provides plug-and-play functionality via flat addressing, while ensuring scalability and efficiency through shortest-path routing and hash-based resolution of host information. In contrast to previous work on identity-based routing, SEATTLE ensures path predictability and stability, and simplifies network management. We performed a simulation study driven by real-world traffic traces and network topologies, and used Emulab to evaluate a prototype of our design based on the Click and XORP open-source routing platforms. Our experiments show that SEATTLE efficiently handles network failures and host mobility, while reducing control overhead and state requirements by roughly two orders of magnitude compared with Ethernet bridging.
425 citations
"Constructing scalable hierarchical ..." refers background in this paper
...In [7], they describes an alternative network architecture called SEATTLE that achieves scalability of IP combined with the simplicity of Ethernet....
[...]
22 Aug 2008
TL;DR: Monsoon is described, a new network architecture, which scales and commoditizes data center networking monsoon realizes a simple mesh-like architecture using programmable commodity layer-2 switches and servers, which creates a huge, flexible switching domain, supporting any server/any service and unfragmented server capacity at low cost.
Abstract: Applications hosted in today's data centers suffer from internal fragmentation of resources, rigidity, and bandwidth constraints imposed by the architecture of the network connecting the data center's servers. Conventional architectures statically map web services to Ethernet VLANs, each constrained in size to a few hundred servers owing to control plane overheads. The IP routers used to span traffic across VLANs and the load balancers used to spray requests within a VLAN across servers are realized via expensive customized hardware and proprietary software. Bisection bandwidth is low, severly constraining distributed computation Further, the conventional architecture concentrates traffic in a few pieces of hardware that must be frequently upgraded and replaced to keep pace with demand - an approach that directly contradicts the prevailing philosophy in the rest of the data center, which is to scale out (adding more cheap components) rather than scale up (adding more power and complexity to a small number of expensive components).Commodity switching hardware is now becoming available with programmable control interfaces and with very high port speeds at very low port cost, making this the right time to redesign the data center networking infrastructure. In this paper, we describe monsoon, a new network architecture, which scales and commoditizes data center networking monsoon realizes a simple mesh-like architecture using programmable commodity layer-2 switches and servers. In order to scale to 100,000 servers or more,monsoon makes modifications to the control plane (e.g., source routing) and to the data plane (e.g., hot-spot free multipath routing via Valiant Load Balancing). It disaggregates the function of load balancing into a group of regular servers, with the result that load balancing server hardware can be distributed amongst racks in the data center leading to greater agility and less fragmentation. The architecture creates a huge, flexible switching domain, supporting any server/any service and unfragmented server capacity at low cost.
336 citations
"Constructing scalable hierarchical ..." refers background in this paper
...In order to redesign the data center infrastructure, [5] has proposes a new architecture which scale data center network....
[...]
TL;DR: The Tempest framework presented here extends beyond the provision of simple network programmability to address larger issues of how such advanced control systems can coexist both with each other and with more conventional ones.
Abstract: Most research in network programmability has stressed the flexibility engendered by increasing the ability of users to configure network elements for their own purposes, without addressing the larger issues of how such advanced control systems can coexist both with each other and with more conventional ones. The Tempest framework presented here extends beyond the provision of simple network programmability to address these larger issues. In particular, we show how network programmability can be achieved without jeopardizing the integrity of the network as a whole, how network programmability fits in with existing networks, and how programmability can be offered at different levels of granularity. Our approach is based on the Tempest's ability to dynamically create virtual private networks over a switched transport architecture (e.g., an ATM network). Each VPN is assigned a set of network resources which can be controlled using either a well-known control system or a control system tailored to the specific needs of a distributed application. The first level of programmability in the Tempest is fairly coarse-grained: an entire virtual network can be programmed by a third party. At a finer level of granularity the Tempest allows user supplied code to be injected into parts of an operational virtual network, thus allowing application specific customization of network control. The article shows how the Tempest framework allows these new approaches to coexist with more conventional solutions.
80 citations
Additional excerpts
...In [6], they have implemented new network functionality by programming switches or remotely controlling their forwarding tables....
[...]
01 Jan 2012
TL;DR: It is found that as timeouts increase, the miss rate decays exponentially while the table size grows near-linearly, and 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.
Abstract: 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.
45 citations