Building NetOpen Networking Services over OpenFlow-based Programmable Networks

Building NetOpen Networking Services over -based Programmable Networks Namgon Kim and JongWon Kim Networked Media Lab., School of Information and Communications, Gwangju Institute of Science and Technology (GIST), Gwangju, 500-712, Korea, Email:{ngkim, jongwon}@nm.gist.ac.kr Abstract As the heterogeneity of end systems and their networking applications grows, networking challenges to meet the various requirements of traffics from different applications should be coped with new networking features, not possible in today s Internet. proposes an open programmable interface to leverage more network controllability by separating control and data path of a network device and delegating the control on the data path to a remote control point. Utilizing the deep programmability of, we introduce NetOpen networking services which attempt to support dynamic configuration of networking characteristics. In this paper, we explain how a NetOpen networking service is built over -based programmable network substrate. To validate the concept of NetOpen networking services, by taking networking connectivity as an example we show an early instantiation of NetOpen networking services over -based programmable network substrate. I. INTRODUCTION The Internet s success based on the adoption of the IP protocols has been facing significant networking problems, such as QoS (Quality of Service), security, mobility and management. As new networking applications emerge, the network research community is currently designing Future Internet that can address the networking challenges and eventually replace today s Internet [1][2]. While it is possible to deploy new networking services 1 at end systems based on overlay networks, implementing them at nodes interior to the network often offers better functionality and performance [3]. To address the problem of slow network service evolution, several approaches have been proposed to build network services using programmability inside of the network infrastructure itself. The ANTS (Active Network Transport System) [4] opens up the possibilities of computation on user data inside the network and tailoring of the packet processing functions in network nodes according to service-specific or user-specific requirements. T. Wolf et al. propose a shift towards network services, where services are not just optional add-on features. Instead, they consider every processing step for data communication as a service. Based on this view on network service, they introduced a design of a network service architecture that can handle networking flexibly by composing network services [5][6]. Recently Software-Defined Network (SDN) is proposed and getting a lot of attention. SDN restructures 1 We use networking service instead of network service to show that we focus more on networking between end hosts. network and exposes network APIs so that any softwares can configure the network as they want with the APIs. SDNs are emerging as a new (but backwardly compatible) way for networks to be architected [7][8]. They have developed [9] as a realization of their envisioned SDN. SILO (Services Integration, control, and Optimization) [10] combines services meeting networking requirements to accomplish complex communication tasks. It optimizes the performance of communication by controlling the service parameters to match the application s QoS requirements and improve network resource utilization. In [6], T. Wolf et al. present a service socket abstraction that can be used by end-system applications to specify data path services in connection requests. These requests are then used by the network to setup and control data path services accordingly. Software-Friendly Network (SFNet) [8] also initiates work on supporting applications to interact with the network based on SDN. By presenting highlevel APIs to the program and hiding the details of the implementation, SFNet exposes network services to application developers to improve application performance. In this paper, by applying SOA (Service-Oriented Architecture) [12] to networking support, we propose the NetOpen networking service. A NetOpen networking service is a selfcontained function for supporting networking features and it can be used to provide complex networking features by composing several services. We use the term NetOpen to express that we are developing those services utilizing features supported by -enabled network devices optionally equipped with NetFPGA [11]. As examples of the NetOpen networking service, L2 (Layer 2) switching, MAC-in-IP tunneling, and L2 VLAN translation can be represented as individual NetOpen networking services with control parameters. By composing L2 packet switching and MAC-in-IP tunneling, L2 network connectivity can be provided among networks having L3 connectivity only. For flexible NetOpen networking service implementation, we define reusable and configurable components of the NetOpen networking service by extracting elementary building blocks from NetOpen environment. We named them NetOpen networking primitives. A NetOpen networking service is composed of the NetOpen networking primitives. In the rest of the paper, in Section 2, we present the initial design of NetOpen networking service and list NetOpen networking primitives from -based programmable 978-1-61284-663-7/11/$26.00 2011 IEEE 525 ICOIN 2011

network substrate. Sections 3 discuss how a NetOpen networking service is built using NetOpen networking primitives. We conclude in Section 4. II. NETOPEN NETWORKING SERVICES OVER OPENFLOW-BASED PROGRAMMABLE NETWORK SUBSTRATE A. Software-Defined Networking and -based Programmable Network Substrate SDNs are emerging as a new yet backward compatible way for networks to be architected [8]. To repartition the way networks are built, SDNs abstract the existing network switch as a combination of datapath and the associated control. That is, it separates control from the switch and place an controller to control the datapath in anyplace in the network. The key advantage of SDN is that it becomes much easier to add new features to the networks. The owners and operators of networks can improve their networks without having to wait for vendors and standards bodies. To achieve this, an SDN is composed of three components: a packet-forwarding datapath, a network-wide operating system, and networking features. The switches, routers and access points through which packets pass are the packetforwarding datapath. The datapath should have an open vendor-independent API to control from outside. The networkwide operating system assists the control of the datapath. The NOX (Network OS) has a global view of the network state and has full programmatic control of the forwarding. Networking features are implemented on the NOX using the open APIs supported by the datapath. Various services, such as routing (e.g. OSPF, BGP, multicast, multipath), mobility management, and QoS control, can be implemented and hosted on the NOX. Controller table. The controller uses the network operating system to implement networking features via the applications of controller. The control plane decides the granularity of flows and how flows are routed, which ones are admitted, and where they are replicated. A network configured by switches are called a programmable network substrate since any experimenter can program an application on controller. makes packet handling decisions based on a common subset of the information that different switches extract from a packet during its processing. -enabled network devices store tuples of this data in their Flow Table and associate them with an action, e.g. dropping the packet or sending it out on a specific network interface. An module that resides on an controller determines the use of actions. B. NetOpen Networking Services By applying SOA on the programmable, we introduce the NetOpen networking service to support dynamic configuration of networking features. For example, a routing algorithm can be represented as a NetOpen networking service with control parameters. Figure 2 shows the concept of NetOpen networking service and how it is created over -based programmable network substrate. A NetOpen networking service has connection with one or more -enabled network devices to perform its functionality. For example, NetOpen L2-Switching service is related to all switches in the substrate, on the other hand, NetOpen MAC-in-IP Tunneling service only uses two network devices in the substrate. It is also possible to cope with changing networking environment by utilizing various monitoring information from end hosts and the network substrate. Composition S C,1 Switching + Tunneling Control Plane Data Plane Network Operating System Protocol B1 L2-Switching Service (Switching) S A,1 S B,1 MAC-in-IP Tunneling Service (Tunneling) B2 Virtualized Switch Flow Table Flow Table Flow Table A1 Physical Switch Networking Commodity Network A2 Fig. 1. An switch communicates with a controller over a secure connection using the protocol. Fig. 2. Concept of NetOpen Networking Service. is the representative implementation of SDN which provides controllability on the network. defines a flow based on a combination of L2- L4 packet headers for packet flows. Figure 1 depicts the elements of and their connections to realize SDN. An -enabled network device (i.e., switch) works as a packetforwarding engine by abstracting its data-plane as a flow table and providing control interface on the flow A NetOpen networking service is built by 1) service control interfaces for applications utilizing it, 2) a service-specific logic to run specific operations to achieve required functionalities. The service control interfaces provide methods for experimenters to interact with the NetOpen networking service. Examples are start/stop interfaces to start and stop the service, a config interface to configure the service by passing required parameters, and a monitor interface to inform 526

NetOpen Networking Service Start/Stop Service State Event Config Configur ations Service-specific Logic Switch Fig. 3. Monitor Monitoring Result Switch Start/Stop Config Monitor Event Switch NetOpen Networking Service. NetOpen Networking Service experimenter of the service status. The service-specific logic defines the way how a service performs its functionality. As inputs, it utilizes events invoked by the switches, configurations, and monitoring results. As outputs, it gives a set of NetOpen networking primitives and parameters to set each NetOpen networking primitives. C. NetOpen Networking s NetOpen networking primitives are the networking features supported by -based programmable network substrate. They are the elementary building blocks for composing a NetOpen networking service. Various NetOpen networking services can be composed by choosing a set of NetOpen networking primitives according to the networking functions to provide. We first categorize NetOpen networking primitives based on their usage: environment access, flow classification, flow manipulation, and forward operations. Most of current NetOpen networking primitives are brought from specification [13] which are not the final version and to be updated later. 1) Environment access: To query the switch information, link states and flow tables, and to configure the resource capabilities Nodes: Retrieve information about switches and end hosts Links: Retrieve information about links in network Packet: Get information from a packet s header fields 2) Flow classification: To retrieve flow from packets meeting certain constraints based on packet s header fields Flow filter: Create a flow filter containing the header fields an incoming packet is compared against Packet to Flow: Create a flow filter from a packet 3) Flow manipulation: To access and modify packet header fields of a flow Set VLAN ID - If no VLAN is present, a new header is added with the specified VLAN ID. If a VLAN header already exists, the VLAN ID is replaced with the specified value. Modify Ethernet source MAC address - Replace the existing Ethernet source MAC address with the new value Modify Ethernet destination MAC address - Replace the existing Ethernet destination MAC address with the new value Modify IPv4 source address - Replace the existing IP source address with new value and update the IP checksum (and TCP/UDP checksum if applicable) Modify IPv4 destination address - Replace the existing IP destination address with new value and update the IP checksum Modify transport source port - Replace the existing TCP/UDP source port with new value and update the TCP/UDP checksum. This action is only applicable to TCP and UDP packets. Modify transport destination port - Replace the existing TCP/UDP destination port with new value 4) Forward operations: To determine the destination of the packet to forward, broadcast or discard packets Forward - Forward packets to physical network interfaces and the virtual network interfaces Drop - Drop all matching packets Enqueue - Forward packets through a queue attached to a network interface III. BUILDING NETOPEN NETWORKING SERVICES BASED ON NETOPEN NETWORKING PRIMITIVES In this section, we will describe how specific NetOpen networking services are built by using NetOpen networking primitives and used in real networking scenario. As the representative examples of networking features, we explain NetOpen L2-Switching service for packet switching and NetOpen L2-VLAN translation service for in-network packet processing. A. NetOpen L2-Switching Service The NetOpen L2-Switching service is a basic service in providing network connectivity among end hosts connected to network substrate. Enabling network connection between a pair of end hosts through network substrate is only possible when the switches along the path between the two end hosts have flow entries for connecting them. The NetOpen L2-Switching service performs the L2- switching operations by 1) managing connectivity information between an end host and its corresponding switch, 2) installing flow entries to the switches along the path for connecting the two end hosts. Figure 4 shows the details of NetOpen L2-Switching service. 527

Start/Stop Service State IN_PORT Connectivity Table Fetch Flow from Packet No NetOpen networking primitive. The combination of the NetOpen networking primitives generates an command. The command is sent back to the switch through the secure channel and installs an entry for the received packet into the flow table. B. NetOpen L2-VLAN Translation Service FLOW PORT FLOW_FILTER FORWARD FLOOD Start/Stop Configure Service State Configurations / SRC_VLAN / DST_VLAN _IN IN_PORT Fetch Flow from Packet SRC_VLAN FLOW DST_VLAN Fig. 4. NetOpen L2-Switching Service. FLOW_FILTER MOD_VLAN_VID FORWARD _IN 1) Service control interfaces: As a simplest implementation prototype of NetOpen networking service, the NetOpen L2-Switching service provides only one control interface, the start/stop interface. The start/stop interface is the primary one among all the control interfaces of the NetOpen networking service. With this, experimenters using NetOpen L2-Switching service can determine whether to provide network connectivity among end hosts or not. 2) Service-specific operation: To perform layer 2 switching, the NetOpen L2-Switching service maintains a connectivity table that contains the connectivity information between each switch and each end host. Required connectivity information is retrieved from the IN message passed from the secure channel. As a packet arrives, an switch looks up its flow table for matching flow entry for the packet. If it fails to find the matching flow entry, it sends the IN message for the received packet through the secure channel. The IN message contains the packet itself, IN PORT where the packet comes in, and DATAPATH ID identifying the switch itself. NetOpen L2-Switching service puts DATAPATH ID, IN PORT, and the MAC address of the packet s source end host into the connectivity table. Next, NetOpen L2-Switching service tries to find a matching entry for the packet s destination MAC address from the connectivity table. If a matching entry is found, the service retrieves IN PORT from the entry and pass it to the FORWARD NetOpen networking primitive. If no matches are found, the service uses FLOOD NetOpen networking primitive instead. By flooding the packet, we can figure out the switch which the target end host is attached to. NetOpen L2-Switching service now fetches flow information from the packet and pass it to FLOW FILTER Fig. 5. NetOpen L2-VLAN translation service. L2-VLAN translation provides flexibility in managing VLAN by replacing the VLAN ID of an incoming packet to the other VLAN ID to enable inter-vlan communication. Building L2-VLAN translation as a NetOpen networking service could be an extended example of NetOpen networking service implementation. L2-VLAN translation is rather simple compared to L2-switching that it is enough to change the VLAN ID of incoming packets. But it requires three parameters, a pair of VLAN IDs to translate and ID of the switch to perform L2-VLAN translation. We describe the details of NetOpen L2-VLAN Translation service in Fig. 5. 1) Service control interfaces: The NetOpen L2-VLAN Translation service provides two control interfaces, the start/stop interface and config interface. The config interface provides a way for experimenters to pass parameters required to configure NetOpen networking service. Experimenters can pass two VLAN IDs (SRC VLAN, DST VLAN) and ID of the switch (DATAP- ATH ID). 2) Service-specific operation: The NetOpen L2-VLAN Translation service operates on all the incoming packets whose VLAN ID is either SRC VLAN, DST VLAN on the switch having DATAPATH ID. For a IN message, the NetOpen L2-VLAN Translation service first checks the DATAPATH ID. If the DATAPATH ID matches with the one in configuration, secondly it compares VLAN ID of the packet with the SRC VLAN. If the VLAN ID matches, NetOpen L2-VLAN Translation service sets FLOW FILTER NetOpen networking primitive with the flow information from the packet and gives MOD VLAN VID 528

DST VLAN. Finally, the NetOpen L2-VLAN Translation service makes an command by composing FLOW FILTER, MOD VLAN VID, and FOWARD NetOpen networking primitives. One important thing to note is to set output port of FOWARD NetOpen networking primitives to use the flow table in the Open- Flow switch. This is to pass the packet using the flow table entry configured by the NetOpen L2-Switching Service or other NetOpen networking services providing network connectivity. GIST POSTECH KREONET KOREN CNU Network Substrate KHU Switch Switch (with NetFPGA) Fig. 6. Tunnel VLAN #1 Experiment Data Plane VLAN #2 Implementation RENCI VM A BEN VM B Substrate NetFPGA-based MAC in IP tunnel C. Demonstration We demonstrated an initial implementation of NetOpen networking services at GEC8 (GENI Engineering Conference). As depicted in Fig. 6, we configured an network substrate in Korea and attached two virtual machines (VMs) to it. The two VMs were instantiated on an Eucalyptus cluster at Renci in United States, initially on a same VLAN. By creating Ethernet-over-IP tunnel with OpenVPN ethernet bridging, each VM worked as if it was directly connected to the network substrate. In the demonstration, we first showed that network connectivity can be provisioned between the two VMs by applying NetOpen L2-Switching service. Then we modified each VM to be in different VLAN and provided network connectivity between the two VMs by using NetOpen L2- VLAN Translation service. IV. CONCLUSIONS In this paper, we presented our preliminary work on the NetOpen networking service. Based on -based programmable network substrate, we described how NetOpen networking services are built using NetOpen networking primitives by showing example NetOpen L2-Switching service and NetOpen L2-VLAN Translation service. ACKNOWLEDGMENTS This work has been supported by the project (2009-F-050-01), Development of the core technology and virtualized programmable platform for Future Internet sponsored by MKE and KCC. REFERENCES [1] M. S. Blumenthal and D. D. Clark, Rethinking the design of the internet: The end to end arguments vs. the brave new world, ACM Transactions on Internet Technology, vol. 1, no. 1, Aug. 2001. [2] T. Anderson, L. Peterson, S. Shenker, and J. Turner, Overcoming the internet impasse through virtualization, Computer, vol. 38, no. 4, Apr. 2005. [3] D. Wetherall, U. Legedza, and J. Guttag, Introducing new Internet services: Why and how, IEEE Network, vol. 12, no. 3, May 1998. [4] D. J. Wetherall, J. V. Guttag, and D. L. Tennenhouse, ANTS: A toolkit for building and dynamically deploying network protocols, in Proc. IEEE OPENARCH, Apr. 1998. [5] S. Ganapathy and T. Wolf, Design of a Network Service Architecture, in Proc. of Sixteenth IEEE International Conference on Computer Communications and Networks (ICCCN), Aug. 2007. [6] S. Shanbhag and T. Wolf, Implementation of End-to-End Abstractions in a Network Service Architecture, in Proc. ACM International Conference On Emerging Networking Experiments And Technologies (CoNEXT), Dec. 2008. [7] POMI 2020: Programmable Open Mobile Internet. [Online]. Available: http://pomi.stanford.edu/index.php [8] K.-K. Yap, T.-Y. Huang, B. Dodson, M. Lam, and N. Mckeown, Towards software-friendly networks, in Proc. the First ACM Asia- Pacific Workshop on Systems (APSys2010), Aug. 2010. [9] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, Openflow: Enabling innovation in campus networks, ACM SIGCOMM CCR, vol. 38, no. 2, Mar. 2008. [10] R. Dutta, G. N. Rouskas, I.Baldine, A.Bragg, and D.Stevenson, The silo architecture for service integration, control, and optimization for the future internet, in Proc. of IEEE International Conference on Communications (ICC), Jun. 2007. [11] NetFPGA: Programmable networking hardware. [Online]. Available: http://netfpga.org [12] T. Erl, Service-Oriented Architecture (SOA): Concepts, Technology, and Design. Prentice Hall, 2005. [13] Switch Specification, Version 1.0.0 ( Wire Protocol 0x01 ), Dec. 2009. 529