ORAN: OpenFlow Routers for Academic Networks

Size: px
Start display at page:

Download "ORAN: OpenFlow Routers for Academic Networks"

Transcription

1 ORAN: OpenFlow Routers for Academic Networks A. Rostami,T.Jungel,A.Koepsel,H.Woesner,A.Wolisz Telecommunication Networks Group (TKN), Technical University of Berlin, Germany {rostami, European Center for Information and Communication Technologies (EICT GmbH), Berlin, Germany {tobias.jungel, andreas.koepsel, Abstract We present the design and prototyping of an OpenFlow-enabled Gigabit Ethernet switch based on an ATCA industrial standard platform. Our work consists of an architectural design for introducing OpenFlow switch functionalities to the ATCA switching platform, design and development of an enhanced library for OpenFlow protocol stack, and porting the data-path functionalities and protocol end-point to the selected platform. We also carry out several performance evaluation tests on the developed switching platform and present selected results. The results demonstrate the successful introduction of OpenFlow protocol to the ATCA platform and contribute, among other things, to the identification of performance bottlenecks and crucial design issues in OpenFlow switches. I. INTRODUCTION OpenFlow [1] proposes decoupling at least partially the intelligence from data-path of a switch/router and delegating it to an external controller that can easily be programmed by network operators. In this approach, different control protocols (e.g., for signaling and routing) can be implemented or modified in the external controller without needing to make modifications to the switches data-path forwarding algorithms. To facilitate this process, OpenFlow defines an open standard interface for programming the switches datapath, that in turn enables network operators/researchers to design their own control logic and incorporate it into the network. The introduction of such a standard interface allows the development of control protocols and switching hardware to evolve independently from each other, that can lead to amorecompetitivemarket.anotherconsequenceofhaving astandardopeninterfaceforcontrollingswitches data-path is the simplicity in management of a network composed of switches developed by different vendors. In addition to that, with this approach the creation of new services are facilitated, since the network operators in an OpenFlow-enabled network are not bound to limitations imposed by different switch vendors. While the idea of OpenFlow has attracted a lot of attention in the networking community, the number of switches following high-performance industry standards on one hand, and being open for flexible configuration and supporting OpenFlow on the other hand is rather limited. Although several networking equipment vendors have already introduced OpenFlowenabled Ethernet switches, the available OpenFlow switches have a closed architecture, which limits the integration of 1 This work was supported in part by the Deutsche Telekom Innovation Laboratories. new components and functionalities, if at all possible. In fact, OpenFlow provides only the first step towards opening the switches and routers for developing and experimenting new control mechanisms and integrating them into the network. To achieve a fully programmable network that supports quick integration of new services, e.g. in wireless or optical domains for mobility or service aware transport networks, we need OpenFlow switches and routers that are flexible and extensible for the integration of new functionalities. These features are unfortunately missing in most of the currently available OpenFlow switches. In order to address this problem, we design and prototype an OpenFlow-enabled Gigabit Ethernet switch based on the Advanced Telecommunications Computing Architecture (ATCA) [2] industrial standard. The standard defines highly modular and vendor-independent components and platforms that are mostly used by telecommunications operators to create networks consisting of processing elements (computers) and data transport modules (e.g., Ethernet switches, mobile basestations and optical transmission cards). The modularity and the fact that there is a large market for ATCA components lead to low prices for the individual components. The advantages of using ATCA for an experimental network are manifold: flexibility and composability of components that support quick system development and extension for special purposes (e.g., wireless or optical networking), a well-introduced and widelydeployed industrial standard, which guarantees the availability of components over years, and finally the low cost, which is acrucialfactorindevelopingexperimentalset-ups. Design and implementation of an OpenFlow switch based on an ATCA platform introduces several challenges, as to our knowledge it is the first of its kind. The challenges are mainly related to the architectural design of the switch, i.e., mapping functional elements of an OpenFlow switch to the ATCA platform as well as to the development of an OpenFlow protocol library and porting it to the platform. In our work, we address the challenges and develop a prototypical composition of ATCA components that supports OpenFlow. This establishes an example for other universities and research institutions to follow the same strategy and build their own platforms that can jointly create a larger experimental facility, and hence we name our switch ORAN (OpenFlow Routers for Academic Networks). There are many examples for a successful implementation of this strategy like XORP [3] or NetFPGA [4], where through the use of standard hardware components and a publicly available software extension the

2 Fig. 1. OpenFlow Switch OF Protocol end point Flow Table secure channel control protocols OF Protocol end point OpenFlow Controller Functional elements of an OpenFlow switch and a controller whole branch of research has been opened. The rest of this paper is organized as follows. In Section II the concept of OpenFlow is reviewed and its building blocks are discussed. In Section III we introduce our selected ATCA platform and detail its capabilities and functional elements. In Section IV we present the architectural design of the ORAN switch and the mapping of the OpenFlow data-path functionalities to the selected hardware platform. In Section VwediscussthedesignandimplementationofanOpenFlow firmware for our switch. Section VI describes selected results on evaluation tests of the ORAN switch. Finally, we conclude in Section VII by summarizing the achieved results and discussing future works. II. OPENFLOW CONCEPT The concept of OpenFlow is based on separating forwarding logic and control functions of a (Ethernet) switch and implementing the latter in a remote control unit. To realize this, the proposed architecture for OpenFlow is composed of three main building blocks as depicted in Fig. 1. The building blocks are namely the OpenFlow switch, the controller and the OpenFlow protocol that enables the connection between the first two blocks over a secure channel [1]. In the following, we explain each of the three blocks in more details. An OpenFlow switch includes a data-path element that realizes the packet forwarding engine. In the heart of the data-path there is a table that is used to decide about how to forward incoming packets 1. The table has an entry per identified flow of packets, and hence it is called flow table 2. Each flow entry in the flow table includes rules for identifying the associated frames, a set of actions to be executed on the associated frames, and counters for collecting statistics about the frames that have successfully matched that entry. The datapath element is exposed to an external control unit by means of a standard application programming interface (API) (the OpenFlow protocol end-point in Fig. 1). The rules for matching incoming frames with flow entries are based on the values of frames L1-L4 header fields. Fig. 2 1 Throughout this paper we use packet and frame interchangeably. 2 Throughout this work we assume OpenFlow switch specification version [5]. More recent versions of the OpenFlow switch specification allows more than one flow table per switch [6]. depicts the header fields that are used for the matching process in OpenFlow version 1.0. The value of a field for a flow entry can also be set to a wildcard, which means the content of that field in an incoming frame does not influence the result of the matching process. This facilitates a flexible definition of flows ranging from micro flows (e.g., an individual TCP/UDP flow) to highly aggregated flows (e.g., all packets originated from agivenautonomoussystem(as)domain).theflowtableis usually implemented in hardware using the ternary content addressable memory (TCAM) [7], which enables efficient matching of frames with flow entries at line rates. TCAMs are quite expensive as compared to conventional random access memories (RAMs), which can put a limit on the size of the flow table in an OpenFlow switch. Accordingly, it is of great importance to utilize the space of a flow table in an efficient manner. Once a frame enters the switch and hits a flow entry in the flow table, a set of actions associated with that entry are executed on the frame. The actions could be for example forwarding the frame to one or all switch ports. If no match can be found for an incoming Ethernet frame in the flow table, it is encapsulated in an OpenFlow frame and forwarded to the remote controller to which the switch is connected. The controller then decides about what to do with the frame and if necessary can cache its decision into the flow table in form of a new entry. In that case, the switch can directly handle upcoming frames of the same flow without consulting the controller. To realize that, an OpenFlow controller utilizes the API provided by the OpenFlow protocol to implement a control layer for a network of OpenFlow switches. A single controller can manage several OpenFlow switches if it enjoys enough resources (e.g., processing power). This is an important feature, which facilitates realization of a centralized control plane for a network of OpenFlow switches. The standard open API provided by the OpenFlow further offers the flexibility that any network provider can develop its own controller, which can also be used to control OpenFlow switches developed by different vendors. Therefore, there is no standard specification for developing an OpenFlow controller, which has led to the development of several controllers with different features. Examples of developed OpenFlow controllers are NOX [8] and SNAC [9], where the former one is available as an open-source implementation. In addition to that, through developing appropriate OpenFlow controllers one can realize the network virtualization, which can improve the network utilization and offer a possibility for running experimental activities in production networks. An example for an OpenFlow controller that enables virtualization of Ethernet switches is FlowVisor [10]. FlowVisor is a controller that acts between a network of physical OpenFlow switches and several OpenFlow controllers, where each controller controls a slice of the network. The responsibility of FlowVisor is to harmonize the usage of resources at the physical switches by the controllers in a way that no conflict occurs. In this approach, the physical switches do not need to be aware of the virtualization.

3 Ingress port Ether. Src. Ether. Dst. Ether. type VLAN id VLAN prior. IP Src. IP Dst. IP Proto. IP ToS TCP/UDP Src. port TCP/UDP Dst. port platform, which facilitate the development of large testbeds for OpenFlow. In addition, the AMC slots allow for extension of processing capacity for different use-cases (e.g., using network processor for further protocol de/encapsulation). Fig. 2. Header fields used for matching frames to flow entries III. ATCA PLATFORM OF THE ORAN SWITCH ATCA is a set of standard specifications for developing next-generation high-performance, carrier-grade communication equipments. The set of specifications have been developed in a cooperation among a large number of telecommunication equipment vendors and providers with the coordination of the PCI Industrial Computers Manufacturers Group (PICMG) [11]. The specifications, denoted as PICMG 3.X, are aimed at addressing the requirements of telecommunication equipment providers to have a standardized and carrier-grade common platform. This can help network equipment providers to offer solutions within a short time by integrating components from different vendors. That is, the ATCA contributes to improving simplicity, interoperability and time to market. These features have contributed to the popularity of ATCA platforms among equipment providers over the last several years. It has been estimated that the ATCA market grow to 6.7 billion USD by 2012 [12]. The hardware equipment used to develop the ORAN switch is an ATCA integrated platform with 10 GbE fabric and uplink modules from Kontron (Kontron OM5080 [13]). The platform, as shown in Figs. 3, is a 2U 19 platform with slots for two carrier boards. Each carrier board (Kontron AT8404) includes agigabitethernetswitchbasedonbroadcomchipset(bcm 56502) [14] with two 10GbE and twenty-four GbE ports, out of which 3 ports (two GbE and a 10GbE) appears on the front side of the platform as uplinks. A carrier board can host up to four mid-size advanced mezzanine cards (AMC). AMC slots can be used to extend the carrier boards for example with I/O functionalities (e.g., GbE ports) or processing modules (e.g., network processors). Each AMC slot is connected to the Gigabit Ethernet switch on the carrier board through five GbE ports. Additionally, the Gigabit Ethernet switches of the two carrier boards are interconnected through the backplane with a 10GbE link. The switching chipset enjoys internal packet memories and a TCAM-based flow table that can accommodate up to 2048 flow entries. Fig. 4 depicts a high-level architecture of AT8404 carrier boards. The Ethernet switch on each board is managed by an embedded PC (PowerPC 405GPr) running at 400 MHZ with 128 MB flash memory, 256 MB SDRAM and 16 kb D-cache. The PowerPC manages the Ethernet switch over a 32bit/33MHZ PCI bus. The switch controller (PowerPC processor) is accessible via a RS232 port on the front side of the platform. The carrier boards further support intelligent platform management interface (IPMI) and simple network management protocol (SNMP) for system management [13]. The dual interconnected GbE switching systems and the high total capacity are important features of the selected ATCA IV. ARCHITECTURAL DESIGN OF THE ORAN SWITCH We have designed and prototyped an architecture for supporting OpenFlow protocol stack on the AT8404 carrier board. The work is composed of two main parts namely, designing an architecture for introducing OpenFlow switch functionality into the ATCA carrier board as wells as the design and implementation of a new library for OpenFlow protocol and porting the developed protocol stack to the carrier board. In this section we focus on the architectural design of our switch. The first step in developing an OpenFlow hardware switch is to deal with mapping OpenFlow functional architecture to the selected hardware architecture. This is an important step since a proper architectural design would have a direct impact on the performance of the switch. A switch is composed of a data-path (also called fast path) for forwarding of data packets and a control path (also called slow path) to exchange routing, signaling and management information. As discussed in Section II, the idea of OpenFlow is to push the intelligence out of the switch as much as possible and to keep only the data-path and a minimal control/management interface inside the switch and expose this interface to a remote controller. Accordingly, in this work we focus on the design and implementation of the data-path and the OpenFlow protocol end-point inside the switch. A natural choice for the protocol end-point would be to implement it in the embedded system of the platform. The mapping of other functional elements of the data-path to the platform is a crucial step in our switch design process. According to the OpenFlow specification [5], once an Ethernet frame arrives at an input switch port and successfully passes the low layer processing, it will be delivered to the OpenFlow forwarding engine. The forwarding engine consists of a header parser, a flow matching processor (including the flow table), an action execution unit (e.g., forwarding, dropping) as well as an OpenFlow protocol encapsulation unit for delivering unknown frames to a remote OpenFlow controller. In general, there are two possibilities for implementing a functional element of the data-path on the platform. Specifically, each of the functional elements can be realized either in hardware (switch chipset) or alternatively in the software, i.e., running in a software on the embedded system. Obviously, the hardware realization of a functional element leads to a higher performance in terms of packet forwarding rate. Nonetheless, making a decision with this regard depends to a high extent on the capabilities and features of the selected platform. The features to be considered include the processing power of the embedded system, the available bandwidth between the embedded system and the switch chipset (the PCI interface) and above all the switch chipset itself and the functions that it supports. In case any functional element of the data-path, which deals with every incoming frame, cannot be directly supported in the chipset then the forwarding rate of the switch would

4 Fig. 3. Kontron OM5080 ATCA integrated platform Fig. 4. Schematic of the internal architecture of Kontron OM5080 ATCA platform [13] be limited by capabilities of the embedded system. The limiting factors here include the communication path between the switch chipset and the processor (i.e., the PCI bus) as well as the processing and buffering resources available at the embedded system. On the other hand, todays Ethernet switching platforms are designed in a way that almost all packet processing functions are supported in the switch chipset using ASIC (application specific integrated circuit), and the embedded system is typically responsible for table updates and other simple configuration functionalities. That is, the resources available in the embedded system of switches are usually limited. For example as detailed in the last section, the embedded system in our ATCA platform has a limited processing power and buffering capacity. It also has a connection with limited bandwidth to the switching chipset. This leads us to the conclusion that the data-path elements should be pushed into the hardware if the required functionalities can be supported by the switch chipset. We should also note that the performance of the switch in terms of the flow-entry handling rate would be in any case dependent on the embedded processor since the protocol end-point is implemented there. Therefore, the embedded processor of an OpenFlow switch can become a bottleneck of an OpenFlow switch if it is not powerful enough, regardless of how capable the switching chipset is. The chipset available on the selected ATCA platform directly supports header parsing, packet classification as well as frame forwarding based on a combination of header fields values of frames. As a result we map all these functionalitiesto the Broadcom Ethernet chipset of the carrier board in order to maximize the forwarding capacity of the switch. Nevertheless, the encapsulation of frames for which no match is found in the flow table cannot be directly supported in the hardware and therefore it is delegated to the embedded processor. In Section VI we will discuss the performance implications of pushing OpenFlow encapsulation into the embedded system. Fig. 5 shows a logical architecture and functional elements of the data-path in an OpenFlow switch and the mapping to our hardware platform. V. IMPLEMENTATION OF OPENFLOW FIRMWARE FOR ATCA CARRIER BOARD Various implementations of OpenFlow have recently been developed by academic and commercial institutions. Porting one of these available libraries seems to be a natural starting point for introducing OpenFlow to the ORAN switch. However, when having a closer look at the actual OpenFlow specification 3,itbecameclearthatOpenFlowisstillonits way to become more mature and a number of desirable features, although being already proposed, are still missing in the OpenFlow specification. Below, we review some of such desirable features in detail. First, let us consider the FlowVisor approach to defining a mechanism for virtualizing and slicing the overall name-space under the control of a data-path element [10]. While OpenFlow restricts itself to a single controller being responsible ofadatapath element, FlowVisor allows different controllers to control disjunct parts of the overall flow name-space in parallel. However, configuring name-spaces and name-space/controller mappings is done in FlowVisor via an external management interface, rather than allowing the controller and the data-path to negotiate these name-space parameters during establishment of the OpenFlow control connection. Proposition 1: An OpenFlow implementation should integrate OpenFlow and FlowVisor functionalities, thereby extending the basic OpenFlow API with means to enable the controller and the data-path to negotiate parts of a name-space under control by this control connection. The OpenFlow API binds mutually user and control plane, and OpenFlow s messages define the set of information exposed by the user plane towards the controlling entity. FlowVisor reveals immediately another interesting property of OpenFlow: its self-similarity. Acting as a proxy entity, FlowVisor manipulates OpenFlow messages that are traveling upstream from user to control plane and vice versa. This is aquiteusefulfeatureallowingnetworkoperatorstoreveal different levels of detail of their network towards a customer, and to change these exposed network properties dynamically over time if needed. Proposition 2: An OpenFlow implementation should enable native stacking of OpenFlow compliant layers on each other, not only on a single device, but rather distributed among different controlling entities. The OpenFlow framework makes specific assumptions about the information exposed by a user plane and its functional elements: consider OpenFlow s interface definition (i.e., Ethernet-based port with static behavior in terms of bandwidth). In fixed network deployments these assumptions will most likely prove valid. However, other link types exist, 3 Although we assume OpenFlow 1.0 in this project, things haven t changed considerably with OpenFlow 1.1.

5 IN Ports OUT Ports To Controller Buffer Embedded System Linux Kernel eth0 PCI Subsystem NIC Pkt In Parser Flow matching no match Action execution BCM ASIC (parser, flow matching, processing) Flow Table OF encapsulation Ethernet Ports Functional Elements of OpenFlow Data Path Hardware Data Path Fig. 5. Mapping OpenFlow functional elements to the ATCA carrier board e.g., dedicated transport channels with associated physical resources as in GMPLS-controlled optical paths, or in the wireless domain, where the channel s capacity underlying the logical link may vary considerably over time. Such properties make interfaces much more dynamic and exposing these dynamic characteristics is crucial for advanced control entities. Proposition 3: An OpenFlow implementation should expose more details about the functional elements in the user plane, e.g., interface details, where applicable. The level of details sent to the control plane should be negotiable to relieve implementors from dealing with unnecessary details. Processing in OpenFlow is typically limited to a restricted number of protocols, typically bounded by the capabilities of the underlying switching chipset. The ATCA platform facilitates integration of additional processing entities, e.g., network processor units or FPGA-based designs. Such entities differ from fixed switching chipsets as they support dynamic deployment of processing logic. OpenFlow s current specification assumes a rather static set of available processing capabilities (i.e., actions) and lacks means to dynamically manipulate processing logic on a data-path element. Various options for integrating such functionality compete with each other, e.g., virtual ports hosting processing entities, or generic actions that refer again to independent processing entities. The impact of advanced processing capabilities on other OpenFlow functional elements (like the packet classifier) must be taken into account carefully. Proposition 4: An OpenFlow implementation should allow integration of more advanced processing capabilities based on network processors or FPGA. Starting from these observations and desired features, we decided to create a new OpenFlow implementation from beginning. Based on C++ and the standard template library (STL), the implementation comprises a library based on the OpenFlow 1.0 specification and provides a hardware abstraction layer in order to facilitate porting the code to various hardware designs. Based on this core library, a data-path element was developed for a Linux PC environment and the AT8404 carrier board that serves as testing environment. As already outlined, the AT8404 carrier board hosts a PowerPC based embedded system for controlling the Broadcom BCM switching chipset. The data-path implementation has been ported to the PowerPC environment and the hardware abstraction layer has been extended by the functionality for controlling the Broadcom chipset API. Some of the key features of the developed library are as follows. AbaseclassprovidesfullOpenFlow1.0compatibility and supports arbitrary (only limited by memory and processing constraints) number of lower layer data-path elements and higher layer controlling entities. It uses RPC stub class for transforming OpenFlow messages transparently from TCP to C++ and vice versa. Full stacking supports for an arbitrary number of instances. The hardware abstraction layer is integrated with Broadcom chipset API. It supports multiple controlling entities per data-path element (FlowVisor like) using vendor extensions. We are planning to make our OpenFlow library available to public in the near future.

6 VI. PERFORMANCE EVALUATION OF THE ORAN SWITCH In this section we present selected results from the performance evaluation of the ORAN switch. One of the most important metrics in evaluating any switch is the maximum achievable throughput, i.e., the rate at which the switch can forward arriving frames without loss. In general, the throughput is evaluated for different packet sizes since for example small packets might saturate the maximum access rate of buffers in the switch. In addition, the throughput of an OpenFlow switch depends on flow-table matching results, because if an incoming frame is not matched to the existing flow entries, it should wait for a remote controller decision and it cannot be forwarded at the line rate. To account for both factors, i.e., frame sizes and the matching results, we have designed and carried out the following sets of experiments. In the first set of experiments we measure the throughput of the switch with a known input flow, i.e., we populate the flow table with flow entries and inject frames that match an installed flow entry. The action part of the flow entry is set to forward associated frames to a given port of the switch. The experiments are run for an exhaustive combination of 4 different frame sizes (64, 500, 1000 and 1518 Bytes) and 4 different number of flow entries pre-installed in the flow table (1, 100, 1000, 2048). In case of more than one flow entries, only one entry is relevant for the injected traffic and the rest are randomly generated just to fill the table to the desired level. Our measurements demonstrate that the ORAN switch can successfully forward incoming frames at the line rate. We have measured successful forwarding of frames at the line rate for up to 25 Gb/s input data rate. We should note that this is the maximum data rate at which we can inject frames to the switch due to limitations of our equipment. To further account for the impact of packet modifications as introduced by the OpenFlow specification on the throughput, we have repeated the experiments with updating the action part of the known flow to add a VLAN tag and forward associated frames to a given port of the switch. Also in this case, we have observed line rate forwarding and modification of frames for up to 25 Gb/s input data rate. This comes at no surprise, since in our switch forwarding of frames belonging to configured flows and per packet modifications such as VLAN tagging are carried out completely in the hardware. In the second set of experiments our aim is to evaluate the switching performance of the ORAN with the input traffic that does not hit existing entries in the flow table. For this kind of traffic, input frames are first copied over the PCI bus to the memory space of the embedded system, then the embedded processor encapsulates part of the frame into an OpenFlow frame and send it to the controller. Upon receiving apositiveanswerfromthecontrollerthepacketshouldbe copied again over the PCI bus to the Ethernet switch so it can be forwarded to the right output port. That is, as already discussed in Section IV, the PCI bus and the embedded system are the major limiting factors of the switch throughput in that case. To quantify the impact of the these limitations on the switch performance we measure the throughput of the PCI bus as well the packet throughput of the switch for the input traffic which is unknown to the flow table. For the PCI bus test we generate and inject to the switch frames again with different sizes as mentioned above for which there is no matching flow entry. Then, on the embedded PC we measure the rate of successfully delivered frames. That is, no extra processing is performed on the frames and they are simply discarded by the embedded PC. Fig. 6 depicts the results of our experiments on the PCI throughput. We observe that the maximum throughput is around 1500 kpps for the 64- Byte-long frames and it reduces with the frame size to around 20 kpps for the larger frames (1518 Bytes). Note that these numbers should be regarded as the maximum forwarding rates of the switch for unknown frames (with no matching flow entries). Next we measure the switch throughput for the same input traffic, i.e., the traffic flow with no matching flow entries. For this purpose, we use a combination of OpenFlow Packet-In and Packet-Out messages [5] as follows. Once a frame arrives to the switch it is encapsulated by the embedded PC and forwarded to the controller (Packt-In), which is attached to the embedded PC via a Fast Ethernet link. The controller is configured in a way to send a Packet-Out message for instructing the switch to send the incoming packet out on a given output port. Fig. 7 presents the results of the test for different values of input packet size. For the sake of comparison, we also conduct the same measurements on two commercial OpenFlow-capable Gigabit Ethernet switches. The first commercial switch we use, denoted by CS1 in Fig. 7, has a PowerPC for switch management running at 533 MHZ and 512 MB RAM. The second switch, denoted by CS2, has an embedded system with a PowerPC running at 666 MHZ and 256 MB RAM. From the figure we observe that our implementation outperforms both commercial switches in terms of the Packet-In/Packet-Out throughput test although both commercial switches have a relatively more powerful embedded system. Nevertheless, we see that in all considered cases the throughput of the switch for unknown flows is limited by the embedded switch management system to a few hundred packets per second. Also, note that for the ORAN and CS1 the throughput reduces with the packet size. In our case this is due to the requirements for copying every packet from the kernel space to the user space and back. The main point to take away from the above experiments is that although the switch can successfully forward at the line rate when incoming frames find matching flows in the flow table, for input frames with no pre-configured flow entry the embedded system of the switch becomes a major bottleneck. VII. CONCLUSION We presented the design and implementation of the Open- Flow switching protocol on an ATCA industrial platform. The programmability of the OpenFlow protocol combined with the modularity and composability of the ATCA as present in the ORAN make it an ideal platform for developing and testing various networking ideas. As an example, different OpenFlow protocol extensions can be easily tested on the ORAN. We also presented the performance results of the ORAN switch. The results demonstrate that the switch can success-

7 K Packets Per Second (KPPS) 1,600 1,400 1,200 1, ,000 1,518 Frame Size (Bytes) Fig. 6. Throughput of the PCI Bus connecting embedded system to the switch chipset Packets Per Second (PPS) ORAN CS1 CS ,518 Frame Size (Bytes) Fig. 7. Throughput of the ORAN switch for unknown flows in comparison with two commercial OpenFlow switches fully forward the packets at the line rate on the condition that the incoming traffic hits the entries already installed in the flow table. Nevertheless, if the input traffic is unknown to the flow table and the switch needs to consult the controller for forwarding packets, the switch forwarding rate appears to be inadequate for many applications. This is due to the resource limitation of the embedded system and its PCI connection to the switch chipset, which is unfortunately quite typical in today s switching platforms. This together with the fact that consulting an external controller for packet forwarding is one of the most important add-ons of the OpenFlow concept lead us to the following conclusion. In an OpenFlow network under a realistic mix of traffic flows, the required packet processing capacity seems to be beyond what can be offered by the embedded system of the switch. This is particularly an issue if we take into account that some control protocols require more packets to be sent to the controller. There are several approaches that can be used to address this issue. One possibility is to minimize the need for communication between the switch and the controller for example through proactive flow installations. This can be further complemented by developing a new generation of switching platforms with more powerful embedded systems and more bandwidth between the embedded system and the switch chipset. Nevertheless, the embedded system in a typical switching platform is not envisaged to be used as a packet processing module. Therefore, we believe that the focus should be on offloading the required packet processing of the embedded system onto another interface, if this cannot be directly realized in the switch chipset. This is the topic of our future work, where we are going to make use of the flexibility of the ATCA platform and push the OpenFlow encapsulation process into one of the available processing modules (AMC cards). REFERENCES [1] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, Openflow: enabling innovation in campus networks, SIGCOMM Comput. Commun. Rev., vol. 38, pp , March [2] PICMG 3.0 Revision 3.0, AdvancedTCA Base Specification, [3] M. Handley, O. Hodson, and E. Kohler, Xorp: an open platform for network research, ACM SIGCOMM Computer Communication Review, vol. 33, no. 1, pp , [4] J. Lockwood, N. McKeown, G. Watson, G. Gibb, P. Hartke, J. Naous, R. Raghuraman, and J. Luo, Netfpga an open platform for gigabit-rate network switching and routing, in Proc. IEEE International Conference on Microelectronic Systems Education, pp ,IEEE,2007. [5] openflow switch consortium, Openflow switch specification, version , [Online]. Available: [6] openflow switch consortium, Openflow switch specification, version , [Online]. Available: [7] K. Pagiamtzis and A. Sheikholeslami, Content-addressable memory (cam) circuits and architectures: A tutorial and survey, IEEE Journal of Solid-State Circuits, vol.41,no.3,pp ,2006. [8] N. Gude, T. Koponen, J. Pettit, B. Pfaff, M. Casado, N. McKeown, and S. Shenker, Nox: towards an operating system for networks, ACM SIGCOMM Computer Communication Review, vol.38,no.3,pp , [9] Simple network access control (snac), [Online]. Available: [10] R. Sherwood, G. Gibb, K. Yap, G. Appenzeller, M. Casado, N. McKeown, and G. Parulkar, Flowvisor: A network virtualization layer, tech. rep., Openflow-tr , Stanford University, [11] PCI Industrial Computers Manufacturers Group (PICMG) [12] S. Stanley, Atca, amc and microtca market: update and forecast, Heavy Reading, vol.7,no.9,2009. [13] Kontron, Om5080: Technical reference manual, [Online]. Available: [14] Broadcom, Bcm 56502: product brief, [Online]. Available:

OpenFlow: Enabling Innovation in Campus Networks

OpenFlow: Enabling Innovation in Campus Networks OpenFlow: Enabling Innovation in Campus Networks Nick McKeown Stanford University Presenter: Munhwan Choi Table of contents What is OpenFlow? The OpenFlow switch Using OpenFlow OpenFlow Switch Specification

More information

Multiple Service Load-Balancing with OpenFlow

Multiple Service Load-Balancing with OpenFlow 2012 IEEE 13th International Conference on High Performance Switching and Routing Multiple Service Load-Balancing with OpenFlow Marc Koerner Technische Universitaet Berlin Department of Telecommunication

More information

Information- Centric Networks. Section # 13.2: Alternatives Instructor: George Xylomenos Department: Informatics

Information- Centric Networks. Section # 13.2: Alternatives Instructor: George Xylomenos Department: Informatics Information- Centric Networks Section # 13.2: Alternatives Instructor: George Xylomenos Department: Informatics Funding These educational materials have been developed as part of the instructors educational

More information

Introduction to OpenFlow:

Introduction to OpenFlow: Introduction to OpenFlow: Bringing Experimental Protocols to a Network Near You! Chris Tracy, Network Engineer ESnet Engineering Group Overview Fundamentals and Terminology Hardware Options for Deploying

More information

Limitations of Current Networking Architecture OpenFlow Architecture

Limitations of Current Networking Architecture OpenFlow Architecture CECS 572 Student Name Monday/Wednesday 5:00 PM Dr. Tracy Bradley Maples OpenFlow OpenFlow is the first open standard communications interface that enables Software Defined Networking (SDN) [6]. It was

More information

OpenFlow: Enabling Innovation in Campus Networks

OpenFlow: Enabling Innovation in Campus Networks : Enabling Innovation in Campus Networks March 14, 2008 Nick McKeown Stanford University Guru Parulkar Stanford University Scott Shenker University of California, Berkeley Tom Anderson University of Washington

More information

OpenFlow and Onix. OpenFlow: Enabling Innovation in Campus Networks. The Problem. We also want. How to run experiments in campus networks?

OpenFlow and Onix. OpenFlow: Enabling Innovation in Campus Networks. The Problem. We also want. How to run experiments in campus networks? OpenFlow and Onix Bowei Xu boweixu@umich.edu [1] McKeown et al., "OpenFlow: Enabling Innovation in Campus Networks," ACM SIGCOMM CCR, 38(2):69-74, Apr. 2008. [2] Koponen et al., "Onix: a Distributed Control

More information

Router Architectures

Router Architectures Router Architectures An overview of router architectures. Introduction What is a Packet Switch? Basic Architectural Components Some Example Packet Switches The Evolution of IP Routers 2 1 Router Components

More information

基 於 SDN 與 可 程 式 化 硬 體 架 構 之 雲 端 網 路 系 統 交 換 器

基 於 SDN 與 可 程 式 化 硬 體 架 構 之 雲 端 網 路 系 統 交 換 器 基 於 SDN 與 可 程 式 化 硬 體 架 構 之 雲 端 網 路 系 統 交 換 器 楊 竹 星 教 授 國 立 成 功 大 學 電 機 工 程 學 系 Outline Introduction OpenFlow NetFPGA OpenFlow Switch on NetFPGA Development Cases Conclusion 2 Introduction With the proposal

More information

High-Performance IP Service Node with Layer 4 to 7 Packet Processing Features

High-Performance IP Service Node with Layer 4 to 7 Packet Processing Features UDC 621.395.31:681.3 High-Performance IP Service Node with Layer 4 to 7 Packet Processing Features VTsuneo Katsuyama VAkira Hakata VMasafumi Katoh VAkira Takeyama (Manuscript received February 27, 2001)

More information

Xperience of Programmable Network with OpenFlow

Xperience of Programmable Network with OpenFlow International Journal of Computer Theory and Engineering, Vol. 5, No. 2, April 2013 Xperience of Programmable Network with OpenFlow Hasnat Ahmed, Irshad, Muhammad Asif Razzaq, and Adeel Baig each one is

More information

Open Flow Controller and Switch Datasheet

Open Flow Controller and Switch Datasheet Open Flow Controller and Switch Datasheet California State University Chico Alan Braithwaite Spring 2013 Block Diagram Figure 1. High Level Block Diagram The project will consist of a network development

More information

Open Source Network: Software-Defined Networking (SDN) and OpenFlow

Open Source Network: Software-Defined Networking (SDN) and OpenFlow Open Source Network: Software-Defined Networking (SDN) and OpenFlow Insop Song, Ericsson LinuxCon North America, Aug. 2012, San Diego CA Objectives Overview of OpenFlow Overview of Software Defined Networking

More information

Software Defined Networking What is it, how does it work, and what is it good for?

Software Defined Networking What is it, how does it work, and what is it good for? Software Defined Networking What is it, how does it work, and what is it good for? slides stolen from Jennifer Rexford, Nick McKeown, Michael Schapira, Scott Shenker, Teemu Koponen, Yotam Harchol and David

More information

OpenFlow with Intel 82599. Voravit Tanyingyong, Markus Hidell, Peter Sjödin

OpenFlow with Intel 82599. Voravit Tanyingyong, Markus Hidell, Peter Sjödin OpenFlow with Intel 82599 Voravit Tanyingyong, Markus Hidell, Peter Sjödin Outline Background Goal Design Experiment and Evaluation Conclusion OpenFlow SW HW Open up commercial network hardware for experiment

More information

OpenFlow: Load Balancing in enterprise networks using Floodlight Controller

OpenFlow: Load Balancing in enterprise networks using Floodlight Controller OpenFlow: Load Balancing in enterprise networks using Floodlight Controller Srinivas Govindraj, Arunkumar Jayaraman, Nitin Khanna, Kaushik Ravi Prakash srinivas.govindraj@colorado.edu, arunkumar.jayaraman@colorado.edu,

More information

OpenFlow: History and Overview. Demo of OpenFlow@home routers

OpenFlow: History and Overview. Demo of OpenFlow@home routers Affan A. Syed affan.syed@nu.edu.pk Syed Ali Khayam ali.khayam@seecs.nust.edu.pk OpenFlow: History and Overview Dr. Affan A. Syed OpenFlow and Software Defined Networking Dr. Syed Ali Khayam Demo of OpenFlow@home

More information

Securing Local Area Network with OpenFlow

Securing Local Area Network with OpenFlow Securing Local Area Network with OpenFlow Master s Thesis Presentation Fahad B. H. Chowdhury Supervisor: Professor Jukka Manner Advisor: Timo Kiravuo Department of Communications and Networking Aalto University

More information

Autonomicity Design in OpenFlow Based Software Defined Networking

Autonomicity Design in OpenFlow Based Software Defined Networking GC'12 Workshop: The 4th IEEE International Workshop on Management of Emerging Networks and Services Autonomicity Design in OpenFlow Based Software Defined Networking WANG Wendong, Yannan HU, Xirong QUE,

More information

Network Virtualization Based on Flows

Network Virtualization Based on Flows TERENA NETWORKING CONFERENCE 2009 June 9, 2009 Network Virtualization Based on Flows Peter Sjödin Markus Hidell, Georgia Kontesidou, Kyriakos Zarifis KTH Royal Institute of Technology, Stockholm Outline

More information

OpenFlow Overview. Daniel Turull danieltt@kth.se

OpenFlow Overview. Daniel Turull danieltt@kth.se OpenFlow Overview Daniel Turull danieltt@kth.se Overview OpenFlow Software Defined Networks (SDN) Network Systems Lab activities Daniel Turull - Netnod spring meeting 2012 2 OpenFlow Why and where was

More information

Getting to know OpenFlow. Nick Rutherford Mariano Vallés {nicholas,mariano}@ac.upc.edu

Getting to know OpenFlow. Nick Rutherford Mariano Vallés {nicholas,mariano}@ac.upc.edu Getting to know OpenFlow Nick Rutherford Mariano Vallés {nicholas,mariano}@ac.upc.edu OpenFlow Switching 1. A way to run experiments in the networks we use everyday. A pragmatic compromise Allow researchers

More information

Software Defined Networking and the design of OpenFlow switches

Software Defined Networking and the design of OpenFlow switches Software Defined Networking and the design of OpenFlow switches Paolo Giaccone Notes for the class on Packet Switch Architectures Politecnico di Torino December 2015 Outline 1 Introduction to SDN 2 OpenFlow

More information

The Lagopus SDN Software Switch. 3.1 SDN and OpenFlow. 3. Cloud Computing Technology

The Lagopus SDN Software Switch. 3.1 SDN and OpenFlow. 3. Cloud Computing Technology 3. The Lagopus SDN Software Switch Here we explain the capabilities of the new Lagopus software switch in detail, starting with the basics of SDN and OpenFlow. 3.1 SDN and OpenFlow Those engaged in network-related

More information

Software Defined Networking

Software Defined Networking Software Defined Networking Richard T. B. Ma School of Computing National University of Singapore Material from: Scott Shenker (UC Berkeley), Nick McKeown (Stanford), Jennifer Rexford (Princeton) CS 4226:

More information

OpenFlow Based Load Balancing

OpenFlow Based Load Balancing OpenFlow Based Load Balancing Hardeep Uppal and Dane Brandon University of Washington CSE561: Networking Project Report Abstract: In today s high-traffic internet, it is often desirable to have multiple

More information

Survey: Software Defined Networks with Emphasis on Network Monitoring

Survey: Software Defined Networks with Emphasis on Network Monitoring Survey: Software Defined Networks with Emphasis on Network Monitoring Prashanth prashanth@cse.iitb.ac.in Indian Institute of Technology, Bombay (IIT-B) Powai, Mumbai, Maharastra India 31 Oct 2015 Abstract

More information

A collaborative model for routing in multi-domains OpenFlow networks

A collaborative model for routing in multi-domains OpenFlow networks A collaborative model for routing in multi-domains OpenFlow networks Xuan Thien Phan, Nam Thoai Faculty of Computer Science and Engineering Ho Chi Minh City University of Technology Ho Chi Minh city, Vietnam

More information

Software Defined Networking Basics

Software Defined Networking Basics Software Defined Networking Basics Anupama Potluri School of Computer and Information Sciences University of Hyderabad Software Defined Networking (SDN) is considered as a paradigm shift in how networking

More information

Outline. Institute of Computer and Communication Network Engineering. Institute of Computer and Communication Network Engineering

Outline. Institute of Computer and Communication Network Engineering. Institute of Computer and Communication Network Engineering Institute of Computer and Communication Network Engineering Institute of Computer and Communication Network Engineering Communication Networks Software Defined Networking (SDN) Prof. Dr. Admela Jukan Dr.

More information

How Router Technology Shapes Inter-Cloud Computing Service Architecture for The Future Internet

How Router Technology Shapes Inter-Cloud Computing Service Architecture for The Future Internet How Router Technology Shapes Inter-Cloud Computing Service Architecture for The Future Internet Professor Jiann-Liang Chen Friday, September 23, 2011 Wireless Networks and Evolutional Communications Laboratory

More information

Network Virtualization and Resource Allocation in OpenFlow-based Wide Area Networks

Network Virtualization and Resource Allocation in OpenFlow-based Wide Area Networks Network Virtualization and Resource Allocation in OpenFlow-based Wide Area Networks Pontus Sköldström Acreo AB, Kista, Sweden Email: ponsko@acreo.se Kiran Yedavalli Ericsson Research, San Jose, CA, USA

More information

Extensible and Scalable Network Monitoring Using OpenSAFE

Extensible and Scalable Network Monitoring Using OpenSAFE Extensible and Scalable Network Monitoring Using OpenSAFE Jeffrey R. Ballard ballard@cs.wisc.edu Ian Rae ian@cs.wisc.edu Aditya Akella akella@cs.wisc.edu Abstract Administrators of today s networks are

More information

Tutorial: OpenFlow in GENI

Tutorial: OpenFlow in GENI Tutorial: OpenFlow in GENI GENI Project Office The current Internet is at an impasse because new architecture cannot be deployed or even adequately evaluated [PST04] [PST04]: Overcoming the Internet Impasse

More information

libnetvirt: the network virtualization library

libnetvirt: the network virtualization library libnetvirt: the network virtualization library Daniel Turull, Markus Hidell, Peter Sjödin KTH Royal Institute of Technology, School of ICT Stockholm, Sweden Email: {danieltt,mahidell,psj}@kth.se Abstract

More information

OpenFlow. Ihsan Ayyub Qazi. Slides use info from Nick Mckeown

OpenFlow. Ihsan Ayyub Qazi. Slides use info from Nick Mckeown OpenFlow Ihsan Ayyub Qazi Slides use info from Nick Mckeown Why Openflow? Deployment of new experimental protocols is challenging Huge installed base of protocols and equipment Reluctance by network operators

More information

OpenFlow/So+ware- defined Networks. Srini Seetharaman Clean Slate Lab Stanford University July 2010

OpenFlow/So+ware- defined Networks. Srini Seetharaman Clean Slate Lab Stanford University July 2010 OpenFlow/So+ware- defined Networks Srini Seetharaman Clean Slate Lab Stanford University July 2010 Outline MoFvaFon OpenFlow - Technical details Overall ecosystem Deployments We have lost our way RouFng,

More information

IMPLEMENTATION AND EVALUATION OF THE MOBILITYFIRST PROTOCOL STACK ON SOFTWARE-DEFINED NETWORK PLATFORMS

IMPLEMENTATION AND EVALUATION OF THE MOBILITYFIRST PROTOCOL STACK ON SOFTWARE-DEFINED NETWORK PLATFORMS IMPLEMENTATION AND EVALUATION OF THE MOBILITYFIRST PROTOCOL STACK ON SOFTWARE-DEFINED NETWORK PLATFORMS BY ARAVIND KRISHNAMOORTHY A thesis submitted to the Graduate School New Brunswick Rutgers, The State

More information

Implementation of Address Learning/Packet Forwarding, Firewall and Load Balancing in Floodlight Controller for SDN Network Management

Implementation of Address Learning/Packet Forwarding, Firewall and Load Balancing in Floodlight Controller for SDN Network Management Research Paper Implementation of Address Learning/Packet Forwarding, Firewall and Load Balancing in Floodlight Controller for SDN Network Management Raphael Eweka MSc Student University of East London

More information

Openflow: Enabling Innovation in Campus Networks

Openflow: Enabling Innovation in Campus Networks Openflow: Enabling Innovation in Campus Networks Filip Stankovski Jacobs University Bremen f.stankovski@jacobs-university.de April 30, 2014 Filip Stankovski (JUB) OpenFlow April 30, 2014 1 / 16 Table of

More information

SDN, OpenFlow and the ONF

SDN, OpenFlow and the ONF SDN, OpenFlow and the ONF OpenFlow/Software-Defined Networking (SDN) OpenFlow/SDN is emerging as one of the most promising and disruptive networking technologies of recent years. It has the potential to

More information

Software Defined Networking for Telecom Operators: Architecture and Applications

Software Defined Networking for Telecom Operators: Architecture and Applications 2013 8th International Conference on Communications and Networking in China (CHINACOM) Software Defined Networking for Telecom Operators: Architecture and Applications Jian-Quan Wang China Unicom Research

More information

Steve Worrall Systems Engineer. sworrall@foundrynet.com

Steve Worrall Systems Engineer. sworrall@foundrynet.com Steve Worrall Systems Engineer sworrall@foundrynet.com Agenda 100GbE Load sharing/link aggregation Foundry Direct Routing 2 100 Gigabit Ethernet 3 Current Status PAR approved, 802.3ba task force set up

More information

COMPSCI 314: SDN: Software Defined Networking

COMPSCI 314: SDN: Software Defined Networking COMPSCI 314: SDN: Software Defined Networking Nevil Brownlee n.brownlee@auckland.ac.nz Lecture 23 Current approach to building a network Buy 802.3 (Ethernet) switches, connect hosts to them using UTP cabling

More information

Programmable Networking with Open vswitch

Programmable Networking with Open vswitch Programmable Networking with Open vswitch Jesse Gross LinuxCon September, 2013 2009 VMware Inc. All rights reserved Background: The Evolution of Data Centers Virtualization has created data center workloads

More information

Software Defined Networking Architecture

Software Defined Networking Architecture Software Defined Networking Architecture Brighten Godfrey CS 538 October 8 2013 slides 2010-2013 by Brighten Godfrey The Problem Networks are complicated Just like any computer system Worse: it s distributed

More information

Building an Accelerated and Energy-Efficient Traffic Monitor onto the NetFPGA platform

Building an Accelerated and Energy-Efficient Traffic Monitor onto the NetFPGA platform Building an Accelerated and Energy-Efficient Traffic Monitor onto the NetFPGA platform Alfio Lombardo Department of Computer Science and Telecommunication Engineering V.le A. Doria, 6 95125, Catania, Italy

More information

Sockets vs. RDMA Interface over 10-Gigabit Networks: An In-depth Analysis of the Memory Traffic Bottleneck

Sockets vs. RDMA Interface over 10-Gigabit Networks: An In-depth Analysis of the Memory Traffic Bottleneck Sockets vs. RDMA Interface over 1-Gigabit Networks: An In-depth Analysis of the Memory Traffic Bottleneck Pavan Balaji Hemal V. Shah D. K. Panda Network Based Computing Lab Computer Science and Engineering

More information

Fibre Channel over Ethernet in the Data Center: An Introduction

Fibre Channel over Ethernet in the Data Center: An Introduction Fibre Channel over Ethernet in the Data Center: An Introduction Introduction Fibre Channel over Ethernet (FCoE) is a newly proposed standard that is being developed by INCITS T11. The FCoE protocol specification

More information

Comparisons of SDN OpenFlow Controllers over EstiNet: Ryu vs. NOX

Comparisons of SDN OpenFlow Controllers over EstiNet: Ryu vs. NOX Comparisons of SDN OpenFlow Controllers over EstiNet: Ryu vs. NOX Shie-Yuan Wang Hung-Wei Chiu and Chih-Liang Chou Department of Computer Science, National Chiao Tung University, Taiwan Email: shieyuan@cs.nctu.edu.tw

More information

How To Make A Vpc More Secure With A Cloud Network Overlay (Network) On A Vlan) On An Openstack Vlan On A Server On A Network On A 2D (Vlan) (Vpn) On Your Vlan

How To Make A Vpc More Secure With A Cloud Network Overlay (Network) On A Vlan) On An Openstack Vlan On A Server On A Network On A 2D (Vlan) (Vpn) On Your Vlan Centec s SDN Switch Built from the Ground Up to Deliver an Optimal Virtual Private Cloud Table of Contents Virtualization Fueling New Possibilities Virtual Private Cloud Offerings... 2 Current Approaches

More information

Networking Virtualization Using FPGAs

Networking Virtualization Using FPGAs Networking Virtualization Using FPGAs Russell Tessier, Deepak Unnikrishnan, Dong Yin, and Lixin Gao Reconfigurable Computing Group Department of Electrical and Computer Engineering University of Massachusetts,

More information

Cloud Networking Disruption with Software Defined Network Virtualization. Ali Khayam

Cloud Networking Disruption with Software Defined Network Virtualization. Ali Khayam Cloud Networking Disruption with Software Defined Network Virtualization Ali Khayam In the next one hour Let s discuss two disruptive new paradigms in the world of networking: Network Virtualization Software

More information

White Paper Abstract Disclaimer

White Paper Abstract Disclaimer White Paper Synopsis of the Data Streaming Logical Specification (Phase I) Based on: RapidIO Specification Part X: Data Streaming Logical Specification Rev. 1.2, 08/2004 Abstract The Data Streaming specification

More information

Scalable Network Virtualization in Software-Defined Networks

Scalable Network Virtualization in Software-Defined Networks Scalable Network Virtualization in Software-Defined Networks Dmitry Drutskoy Princeton University Eric Keller University of Pennsylvania Jennifer Rexford Princeton University ABSTRACT Network virtualization

More information

The proliferation of the raw processing

The proliferation of the raw processing TECHNOLOGY CONNECTED Advances with System Area Network Speeds Data Transfer between Servers with A new network switch technology is targeted to answer the phenomenal demands on intercommunication transfer

More information

HyperFlow: A Distributed Control Plane for OpenFlow

HyperFlow: A Distributed Control Plane for OpenFlow HyperFlow: A Distributed Control Plane for OpenFlow Amin Tootoonchian University of Toronto amin@cs.toronto.edu Yashar Ganjali University of Toronto yganjali@cs.toronto.edu Abstract OpenFlow assumes a

More information

Intel DPDK Boosts Server Appliance Performance White Paper

Intel DPDK Boosts Server Appliance Performance White Paper Intel DPDK Boosts Server Appliance Performance Intel DPDK Boosts Server Appliance Performance Introduction As network speeds increase to 40G and above, both in the enterprise and data center, the bottlenecks

More information

Software Defined Networking

Software Defined Networking Software Defined Networking Dr. Nick Feamster Associate Professor In this course, you will learn about software defined networking and how it is changing the way communications networks are managed, maintained,

More information

Carrier-grade Network Management Extensions to the SDN Framework

Carrier-grade Network Management Extensions to the SDN Framework Carrier-grade Network Management Extensions to the SDN Framework Alisa Devlic, Wolfgang John Ericsson Research Kista, Sweden {alisa.devlic, wolfgang.john}@ericsson.com Pontus Sköldström Acreo AB Kista,

More information

BROCADE NETWORKING: EXPLORING SOFTWARE-DEFINED NETWORK. Gustavo Barros Systems Engineer Brocade Brasil

BROCADE NETWORKING: EXPLORING SOFTWARE-DEFINED NETWORK. Gustavo Barros Systems Engineer Brocade Brasil BROCADE NETWORKING: EXPLORING SOFTWARE-DEFINED NETWORK Gustavo Barros Systems Engineer Brocade Brasil Software- Defined Networking Summary Separate control and data planes Networks are becoming: More programmatic

More information

OpenFlow MPLS and the Open Source Label Switched Router

OpenFlow MPLS and the Open Source Label Switched Router OpenFlow MPLS and the Open Source Label Switched Router James Kempf, Scott Whyte, Jonathan Ellithorpe, Peyman Kazemian, Mart Haitjema, Neda Beheshti, Stephen Stuart, Howard Green james.kempf@ericsson.com,

More information

Facilitating Network Management with Software Defined Networking

Facilitating Network Management with Software Defined Networking Facilitating Network Management with Software Defined Networking Nick Feamster Georgia Tech feamster@cc.gatech.edu Steve Woodrow, Srikanth Sundaresan, Hyojoon Kim, Russ Clark Georgia Tech Andreas Voellmy

More information

The new frontier of the DATA acquisition using 1 and 10 Gb/s Ethernet links. Filippo Costa on behalf of the ALICE DAQ group

The new frontier of the DATA acquisition using 1 and 10 Gb/s Ethernet links. Filippo Costa on behalf of the ALICE DAQ group The new frontier of the DATA acquisition using 1 and 10 Gb/s Ethernet links Filippo Costa on behalf of the ALICE DAQ group DATE software 2 DATE (ALICE Data Acquisition and Test Environment) ALICE is a

More information

HANIC 100G: Hardware accelerator for 100 Gbps network traffic monitoring

HANIC 100G: Hardware accelerator for 100 Gbps network traffic monitoring CESNET Technical Report 2/2014 HANIC 100G: Hardware accelerator for 100 Gbps network traffic monitoring VIKTOR PUš, LUKÁš KEKELY, MARTIN ŠPINLER, VÁCLAV HUMMEL, JAN PALIČKA Received 3. 10. 2014 Abstract

More information

D1.2 Network Load Balancing

D1.2 Network Load Balancing D1. Network Load Balancing Ronald van der Pol, Freek Dijkstra, Igor Idziejczak, and Mark Meijerink SARA Computing and Networking Services, Science Park 11, 9 XG Amsterdam, The Netherlands June ronald.vanderpol@sara.nl,freek.dijkstra@sara.nl,

More information

Software Defined Networking (SDN) OpenFlow and OpenStack. Vivek Dasgupta Principal Software Maintenance Engineer Red Hat

Software Defined Networking (SDN) OpenFlow and OpenStack. Vivek Dasgupta Principal Software Maintenance Engineer Red Hat Software Defined Networking (SDN) OpenFlow and OpenStack Vivek Dasgupta Principal Software Maintenance Engineer Red Hat CONTENTS Introduction SDN and components SDN Architecture, Components SDN Controller

More information

SAN Conceptual and Design Basics

SAN Conceptual and Design Basics TECHNICAL NOTE VMware Infrastructure 3 SAN Conceptual and Design Basics VMware ESX Server can be used in conjunction with a SAN (storage area network), a specialized high speed network that connects computer

More information

Software Defined Networking

Software Defined Networking Software Defined Networking Stefano Giordano Dipartimento di Ingegneria dell Informazione Università di Pisa 3D Reference model of ISDN Hourglass reference model of a TCP/IP network Network Ossification

More information

Enabling Practical SDN Security Applications with OFX (The OpenFlow extension Framework)

Enabling Practical SDN Security Applications with OFX (The OpenFlow extension Framework) Enabling Practical SDN Security Applications with OFX (The OpenFlow extension Framework) John Sonchack, Adam J. Aviv, Eric Keller, and Jonathan M. Smith Outline Introduction Overview of OFX Using OFX Benchmarks

More information

SOFTWARE-DEFINED NETWORKING AND OPENFLOW

SOFTWARE-DEFINED NETWORKING AND OPENFLOW SOFTWARE-DEFINED NETWORKING AND OPENFLOW Freddie Örnebjär TREX Workshop 2012 2012 Brocade Communications Systems, Inc. 2012/09/14 Software-Defined Networking (SDN): Fundamental Control

More information

SDN AND SECURITY: Why Take Over the Hosts When You Can Take Over the Network

SDN AND SECURITY: Why Take Over the Hosts When You Can Take Over the Network SDN AND SECURITY: Why Take Over the s When You Can Take Over the Network SESSION ID: TECH0R03 Robert M. Hinden Check Point Fellow Check Point Software What are the SDN Security Challenges? Vulnerability

More information

POX CONTROLLER PERFORMANCE FOR OPENFLOW NETWORKS. Selçuk Yazar, Erdem Uçar POX CONTROLLER ЗА OPENFLOW ПЛАТФОРМА. Селчук Язар, Ердем Учар

POX CONTROLLER PERFORMANCE FOR OPENFLOW NETWORKS. Selçuk Yazar, Erdem Uçar POX CONTROLLER ЗА OPENFLOW ПЛАТФОРМА. Селчук Язар, Ердем Учар УПРАВЛЕНИЕ И ОБРАЗОВАНИЕ MANAGEMENT AND EDUCATION TOM IX (6) 2013 VOL. IX (6) 2013 POX CONTROLLER PERFORMANCE FOR OPENFLOW NETWORKS Selçuk Yazar, Erdem Uçar POX CONTROLLER ЗА OPENFLOW ПЛАТФОРМА Селчук

More information

TCP Offload Engines. As network interconnect speeds advance to Gigabit. Introduction to

TCP Offload Engines. As network interconnect speeds advance to Gigabit. Introduction to Introduction to TCP Offload Engines By implementing a TCP Offload Engine (TOE) in high-speed computing environments, administrators can help relieve network bottlenecks and improve application performance.

More information

Enabling Software Defined Networking using OpenFlow

Enabling Software Defined Networking using OpenFlow Enabling Software Defined Networking using OpenFlow 1 Karamjeet Kaur, 2 Sukhveer Kaur, 3 Vipin Gupta 1,2 SBS State Technical Campus Ferozepur, 3 U-Net Solutions Moga Abstract Software Defined Networking

More information

Quantifying the Performance Degradation of IPv6 for TCP in Windows and Linux Networking

Quantifying the Performance Degradation of IPv6 for TCP in Windows and Linux Networking Quantifying the Performance Degradation of IPv6 for TCP in Windows and Linux Networking Burjiz Soorty School of Computing and Mathematical Sciences Auckland University of Technology Auckland, New Zealand

More information

OpenFlow and Software Defined Networking presented by Greg Ferro. OpenFlow Functions and Flow Tables

OpenFlow and Software Defined Networking presented by Greg Ferro. OpenFlow Functions and Flow Tables OpenFlow and Software Defined Networking presented by Greg Ferro OpenFlow Functions and Flow Tables would like to thank Greg Ferro and Ivan Pepelnjak for giving us the opportunity to sponsor to this educational

More information

Scaling 10Gb/s Clustering at Wire-Speed

Scaling 10Gb/s Clustering at Wire-Speed Scaling 10Gb/s Clustering at Wire-Speed InfiniBand offers cost-effective wire-speed scaling with deterministic performance Mellanox Technologies Inc. 2900 Stender Way, Santa Clara, CA 95054 Tel: 408-970-3400

More information

How To Understand The Power Of A Network In A Microsoft Computer System (For A Micronetworking)

How To Understand The Power Of A Network In A Microsoft Computer System (For A Micronetworking) Digitaalne andmeülekanne IRT0150 OpenFlow /nädal 6/ Avo Ots avo.ots@ttu.ee 12. märts 2015 1 Various Services Virtual Networks LINP1 LINP3 LINP2 LINP1 Manager LINP2 Manager LINP3 Manager Virtual Resources

More information

SDN. WHITE PAPER Intel Ethernet Switch FM6000 Series - Software Defined Networking. Recep Ozdag Intel Corporation

SDN. WHITE PAPER Intel Ethernet Switch FM6000 Series - Software Defined Networking. Recep Ozdag Intel Corporation WHITE PAPER Intel Ethernet Switch FM6000 Series - Software Defined Networking Intel Ethernet Switch FM6000 Series - Software Defined Networking Recep Ozdag Intel Corporation Software Defined Networking

More information

Isilon IQ Network Configuration Guide

Isilon IQ Network Configuration Guide Isilon IQ Network Configuration Guide An Isilon Systems Best Practice Paper August 2008 ISILON SYSTEMS Table of Contents Cluster Networking Introduction...3 Assumptions...3 Cluster Networking Features...3

More information

SDN. What's Software Defined Networking? Angelo Capossele

SDN. What's Software Defined Networking? Angelo Capossele SDN What's Software Defined Networking? Angelo Capossele Outline Introduction to SDN OpenFlow Network Functions Virtualization Some examples Opportunities Research problems Security Case study: LTE (Mini)Tutorial

More information

Funded in part by: NSF, Cisco, DoCoMo, DT, Ericsson, Google, Huawei, NEC, Xilinx

Funded in part by: NSF, Cisco, DoCoMo, DT, Ericsson, Google, Huawei, NEC, Xilinx Funded in part by: NSF, Cisco, DoCoMo, DT, Ericsson, Google, Huawei, NEC, Xilinx Nick McKeown, Guru Parulkar, Guido Appenzeller, Nick Bastin, David Erickson, Glen Gibb, Nikhil Handigol, Brandon Heller,

More information

BROADCOM SDN SOLUTIONS OF-DPA (OPENFLOW DATA PLANE ABSTRACTION) SOFTWARE

BROADCOM SDN SOLUTIONS OF-DPA (OPENFLOW DATA PLANE ABSTRACTION) SOFTWARE BROADCOM SDN SOLUTIONS OF-DPA (OPENFLOW DATA PLANE ABSTRACTION) SOFTWARE Network Switch Business Unit Infrastructure and Networking Group 1 TOPICS SDN Principles Open Switch Options Introducing OF-DPA

More information

Facility Usage Scenarios

Facility Usage Scenarios Facility Usage Scenarios GDD-06-41 GENI: Global Environment for Network Innovations December 22, 2006 Status: Draft (Version 0.1) Note to the reader: this document is a work in progress and continues to

More information

How To Understand The Power Of The Internet

How To Understand The Power Of The Internet DATA COMMUNICATOIN NETWORKING Instructor: Ouldooz Baghban Karimi Course Book: Computer Networking, A Top-Down Approach, Kurose, Ross Slides: - Course book Slides - Slides from Princeton University COS461

More information

Software Defined Networking What is it, how does it work, and what is it good for?

Software Defined Networking What is it, how does it work, and what is it good for? Software Defined Networking What is it, how does it work, and what is it good for? Many slides stolen from Jennifer Rexford, Nick McKeown, Scott Shenker, Teemu Koponen, Yotam Harchol and David Hay Agenda

More information

Switch Fabric Implementation Using Shared Memory

Switch Fabric Implementation Using Shared Memory Order this document by /D Switch Fabric Implementation Using Shared Memory Prepared by: Lakshmi Mandyam and B. Kinney INTRODUCTION Whether it be for the World Wide Web or for an intra office network, today

More information

Time-based Updates in OpenFlow: A Proposed Extension to the OpenFlow Protocol

Time-based Updates in OpenFlow: A Proposed Extension to the OpenFlow Protocol CCIT Report #835, July 2013, EE Pub No. 1792, Technion, Israel 1 Time-based Updates in : A Proposed Extension to the Protocol Tal Mizrahi, Yoram Moses Department of Electrical Engineering Technion Israel

More information

CS6204 Advanced Topics in Networking

CS6204 Advanced Topics in Networking CS6204 Advanced Topics in Networking Assoc Prof. Chan Mun Choon School of Computing National University of Singapore Aug 14, 2015 CS6204 Lecturer Chan Mun Choon Office: COM2, #04-17 Email: chanmc@comp.nus.edu.sg

More information

Software Defined Networking (SDN) - Open Flow

Software Defined Networking (SDN) - Open Flow Software Defined Networking (SDN) - Open Flow Introduction Current Internet: egalitarian routing/delivery based on destination address, best effort. Future Internet: criteria based traffic management,

More information

7a. System-on-chip design and prototyping platforms

7a. System-on-chip design and prototyping platforms 7a. System-on-chip design and prototyping platforms Labros Bisdounis, Ph.D. Department of Computer and Communication Engineering 1 What is System-on-Chip (SoC)? System-on-chip is an integrated circuit

More information

Software Defined Networks (SDN)

Software Defined Networks (SDN) Software Defined Networks (SDN) Nick McKeown Stanford University With: Martín Casado, Teemu Koponen, Scott Shenker and many others With thanks to: NSF, GPO, Stanford Clean Slate Program, Cisco, DoCoMo,

More information

Towards Software Defined Cellular Networks

Towards Software Defined Cellular Networks Towards Software Defined Cellular Networks Li Erran Li (Bell Labs, Alcatel-Lucent) Morley Mao (University of Michigan) Jennifer Rexford (Princeton University) 1 Outline Critiques of LTE Architecture CellSDN

More information

Extensible Datapath Daemon - A Review

Extensible Datapath Daemon - A Review A Datapath-centric Virtualization Mechanism for OpenFlow Networks R. Doriguzzi-Corin, E. Salvadori, M. Gerola CREATE-NET, Trento, Italy Email: {rdoriguzzi, esalvadori, mgerola}@create-net.org M. Suñé,

More information

An Intelligent Framework for Vehicular Ad-hoc Networks using SDN Architecture

An Intelligent Framework for Vehicular Ad-hoc Networks using SDN Architecture 435 An Intelligent Framework for Vehicular Ad-hoc Networks using SDN Architecture Balamurugan.V School of Computing Science and Engineering, VIT University Chennai Campus, 600127, Tamilnadu, India. Abstract

More information

OpenFlow Switching: Data Plane Performance

OpenFlow Switching: Data Plane Performance This full text paper was peer reviewed at the direction of IEEE Communications Society subject matter experts for publication in the IEEE ICC 21 proceedings OpenFlow : Data Plane Performance Andrea Bianco,

More information

Status of OpenFlow research and test facilities in Europe

Status of OpenFlow research and test facilities in Europe Status of OpenFlow research and test facilities in Europe Cape Town, Nov 14-15, 2011 Dr.-Ing. Hagen Woesner EICT GmbH, Berlin, Germany Agenda Software Defined Networks and OpenFlow Architectural Splits

More information

PE10G2T Dual Port Fiber 10 Gigabit Ethernet TOE PCI Express Server Adapter Broadcom based

PE10G2T Dual Port Fiber 10 Gigabit Ethernet TOE PCI Express Server Adapter Broadcom based PE10G2T Dual Port Fiber 10 Gigabit Ethernet TOE PCI Express Server Adapter Broadcom based Description Silicom 10Gigabit TOE PCI Express server adapters are network interface cards that contain multiple

More information

Software-Defined Infrastructure and the SAVI Testbed

Software-Defined Infrastructure and the SAVI Testbed Software-Defined Infrastructure and the SAVI Testbed Joon-Myung Kang 1, Thomas Lin 2, Hadi Bannazadeh 2, and Alberto Leon-Garcia 2 1 HP Labs., Palo Alto, CA, 94304, USA, joon-myung.kang@hp.com 2 Dept.

More information