Auto-Configuration of SDN Switches in SDN/Non-SDN Hybrid Network Rohit Katiyar cs13m1016@iith.ac.in Prakash Pawar cs13m1015@iith.ac.in Kotaro Kataoka kotaro@iith.ac.in Abhay Gupta cs12b1041@iith.ac.in ABSTRACT This paper proposes an auto-configuration mechanism for a newly attached SDN (Software-defined Networking) switch and intermediate switches in an SDN/non-SDN hybrid network. Automation of initial configuration of SDN switches brings the benefit of reducing the installation costs and maintaining the operational consistency in an enterprise network. However, the heterogeneity of a hybrid network introduces difficulty in achieving such benefits. The proposed system achieves the following features: 1) detecting a new SDN switch in a hybrid network, 2) providing the switch with appropriate configuration parameters in an SDN/non-SDN hybrid network and 3) ensuring seamless service across the SDN and non-sdn segments. The proposed solution also introduces DHCP-SDN as an extension of Dynamic Host Configuration Protocol (DHCP) to support SDN parameters. The proposed system enables a new SDN switch to automatically start operating even though the intermediate switches are not configured with the SDN-specific VLAN setup. Categories and Subject Descriptors C.2.3 [Network Operations]: Network Management; C.2.2 [Network Protocols]: Bootstrap Protocols General Terms Management, Design, Experimentation Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from Permissions@acm.org. AINTEC 15, November 18 20, 2015, Bangkok, Thailand. Copyright 2015 ACM 978-1-4503-3914-8/15/11... $15.00. http://dx.doi.org/10.1145/2837030.2837037. Keywords Software Defined Networking, OpenFlow, Auto Configuration, DHCP/BOOTP 1. INTRODUCTION The benefits of SDN [10][13] have been well recognized in recent years. A variety of options are available for SDN controllers and switches, that can be easily deployed as both hardware and software. The scenario of SDN deployment is now flexible and heterogeneous due to technologies such as dual stack support of SDN and non-sdn mode on a single switch, partial or full replacement of non-sdn switches with SDN switches in the network architecture and etc. Given that existing non-sdn switches are still positive assets, incremental or partial deployment of SDN might be more realistic. Panopticon [12] was proposed to locate the best point where the installation of an SDN switch maximizes its benefit. The question is how the installation process of SDN switches in heterogeneous conditions can be simplified. Such process still relies on prerequisite configuration such as IP address of SDN controller, VLAN ID for Control and Data Plane and IP address to a new SDN switch and etc. Manually configuring switches not only introduces the risk of human errors but also adds to operational costs. To the best of the authors knowledge, automating SDN switch installation in an SDN/non-SDN hybrid network has not been achieved, while bootstrapping an SDN switch in an SDN-only network has already been proposed [14]. This paper proposes an auto-configuration mechanism for installation of an SDN switch in an SDN/non-SDN hybrid network. The proposed mechanism includes Locator, Configurator and DHCP-SDN which is an extension of DHCP [2] enabling plug-and-play functionality for an SDN switch. DHCP-SDN provides an SDN switch with 1) Network configuration of SDN switch, 2) Information of single or multiple controllers and 3) Seamless service across both SDN and non-sdn segments. In our system 1) Locator detects where a new SDN switch is installed and 2) Configurator enables 48
reachability between known SDN controllers and a new SDN switch if not available. The benefit of extending DHCP is the very high maturity with the broader network equipment including DHCP relay. We can expect the rapid deployment of the proposed mechanism with almost zero impact to the existing networks. The proof of concept implementation has been attained by making an Open vswitch [9] plug-and-play and then testing it in a small testbed network inclusive of both SDN and non-sdn switches. The contribution of this paper is to examine the best practices of automated SDN deployment and to report how it can happen with the minimum set of preparedness. The proposed methodology is implemented using Floodlight [3] SDN controller and hybrid networks that involve Open vswitch (OVS) and non-sdn L2/L3 switches. 2. RELATED WORK [14] proposed automatic bootstrapping of OpenFlow [7] networks where the controller establishes control network through the neighboring OpenFlow-enabled switches. The existing solution has been tested on a homogeneous SDN network with no backward compatibility over non-sdn switches. It is also assumed that the controller is at a one hop distance to the DHCP server. OF-CONFIG [5] extends NETCONF [4] to support the remote management of OpenFlow switches. OF-CONFIG enables applications to retrieve switch status, configure a switch, get event notice etc., similar to SNMP [11]. OF- CONFIG expects secure connection over TCP between a switch and a server called OpenFlow Configuration Point. This method contributes to the automation of SDN management after the switches are bootstrapped in a particular domain. However, OF-CONFIG assumes pre-configuration of switches before they are bootstrapped into the network. The design of hybrid network using SDN switches in enterprise networks is addressed in [12]. The solution assumes the presence of an operator who knows the best location for a switch and also provides guarantee that traffic destined to operator-selected end-points passes through at least one SDN switch. Automatic discovery and configuration of the control plane of switches to controllers is discussed in [15]. The module suggested has been plug-and-play for an In-Band SDN Control Network. The key insight is that there is a need of automatically configuring SDN switches in a hybrid SDN/non-SDN network so as to ensure seamless service across all segments of the network. There is also a need to avoid operator overhead and, at the same time, make the auto-configuration mechanism plug-and-play. In this paper, we propose an approach to reduce operator overhead and ensure plug-and-play reliable auto-configuration of SDN switches in hybrid networks. 3. INSTALLING SDN SWITCH IN SDN/NON- SDN HYBRID NETWORK 3.1 Basic Configuration of Switch-Controller Connectivity In OpenFlow, an SDN controller and a switch communicate using TCP/IP, which is called as secure channel. Once the switch establishes a secure channel, the rest of the operation is taken over by the controller. To install an SDN switch, the following information is required at a new SDN switch and intermediate switches. 1. For new SDN Switch: Available IP address Netmask and Gateway IP address to Controller Controller IP address and its type (Master, Slave or Equal) Port number of secure channel Control Plane and Data Plane VLAN (if link is truncated) 2. For Intermediate Switch: Network Configuration including ports with appropriate VLAN 3.2 Automating SDN Configuration Auto-configuration of an SDN switch in a heterogeneous network requires at least five steps as shown in Figure 1. 1. New SDN switch joins the network and solicits configuration parameters for the controller and itself. 2. AutoConf Server Triggers: Solicitation reaches Auto- Conf server and it initiates configuration for the new SDN switch. 3. SDN Switch Locator and Intermediate Switch Configurator: Start locating SDN switch in the network using device discovery mechanism in order to provide the prerequisite configuration to intermediate switches. 4. Exchange of messages (discover, offer, request and acknowledgement) as a part of the proposed method between the AutoConf Server and the new SDN switch in a heterogeneous network. 5. OpenFlow Session Triggers: Instantiation of an Open- Flow session with the SDN controller and assignment of connection identifiers for connecting the new SDN switch to the SDN controller. Figure 1: Basic steps involved in auto-configuration 49
3.3 Multiple Controllers A network can have multiple controllers [8] and SDN switches can be configured for one or more controllers. In the event that one or more controllers fail, the switch can continue to operate seamlessly and network failure can be avoided. A network involving multiple controllers addresses issues such as controller fail-over and load balancing. Initially, the proposed mechanism provides the required configuration parameters for every available controller with its type (role of the controller i.e. Master, Equal or Slave). When an OpenFlow session is initiated, the switch tries to connect to all controllers with given type, and try to maintain connectivity with all of them concurrently. The multiple controllers coordinate the management of the switch amongst themselves, which may cause a change in the type of one of the controllers later. In this paper, multiple controllers have been used in an active-standby mode to address controller fail-over. 4. SYSTEM DESIGN OF AUTO CONFIGU- RATION 4.1 System Components The proposed system contains the following components: 1. SDN AutoConf Server (ACS): An extended implementation of a DHCP/BOOTP Server. It is used to provide basic configuration to the newly introduced SDN switches. 2. SDN AutoConf Client (ACC): An OVS used as an SDN switch. 3. Intermediate Switch Configurator (ISC): A module that provides automatic configuration to intermediate switches to prepare them for connecting to a new SDN switch. The newly joined SDN switch becomes a part of the SDN/non-SDN hybrid network and now it can successfully communicate with the SDN controller. 4. New Switch Locator (NSL): A module that locates the newly joined SDN switch in a hybrid network. 5. SDN Controllers: SDN controllers like Floodlight with a given type (Master, Slave and Equal). 6. Non-SDN Switch: Traditional L2/L3 switches. Figure 2: Components/Entities used in Auto-Configuration Figure 2 shows the logical connectivity between the entities involved in the auto-configuration of SDN switches. The logical architecture contains ACS and the SDN controller that are connected (physically) with a sequence of SDN and L2/L3 non-sdn switches. Using the functionality provided by NSL and ISC, the ACS identifies a newly joined SDN switch in the hybrid network and the new SDN switch gets registered to all controllers. 4.2 AutoConf Event Sequence Figure 3: State diagram of event in Auto-Configuration Referring to Figure 3, the ACC broadcasts a discover message (1) and waits for an offer message from any ACS in the vicinity. However, the intermediate network may not be configured to ensure reachability between an SDN controller and the new added SDN switch (existing switch ports may not be in required Control Plane VLAN or Data Plane VLAN). Hence, the ACS calls an ISC component (2) with NSL (3) to establish connectivity between the SDN switch and the SDN controller. The communication between the new SDN switch and existing controllers should be transparent. To achieve this, some prior configuration is required in the intermediate switches. For example, to enable communication between the newly added SDN switches and SDN controller in the hybrid network, required ports of the intermediate switches should either be configured as trunk or with proper VLAN (Native VLAN) configuration (more details are given in Section V). ISC traverses the network from ACS (5) and reaches the new SDN switch using LLDP [1] and MAC address resolution (6) and configures the intermediate switches. Both SDN and non-sdn in the path ensure reachability between the new SDN switch and controller in the hybrid network (7). MAC address resolution in SDN is done using the help of SDN controller [16]. For auto-configuration, ACS maintains a range of available IP addresses. When a new SDN switch is introduced into the network, it goes through a sequence of message exchanges with the extended DHCP server on ACS and then the switch gets registered with the controller. We thus ensure that prerequisite configuration is done on all intermediate switches using the mechanism proposed. 50
5. IMPLEMENTATION Auto-configuration of an SDN switch in a heterogeneous network can be achieved through the following steps: Intermediate Switch Configurator (ISC): This module ensures the assignment of configuration parameters to intermediate switches as a prerequisite. Each switch has native VLAN enabled to ensure reachability of discovery/ offer/ request/ acknowledge messages between ACC and ACS. For example in the case of CISCO, VLAN 1 is enabled natively. This is an assumed prerequisite for auto-configuration. DHCP discover message from DHCP-SDN message at ACS. Offer Message: Offer message contains the minimum configuration parameters, i.e., Offered IP Address for the switch, the controller IP address, port number, the type of controller, the netmask and gateway IP address for an SDN Switch as shown in Figure 5. When a new SDN switch is introduced in the traditional network, it transmits a Discover message (extended DHCP Discover Message) through its local port with its MAC address. By traversing the sequence of the switches, the Discover message reaches ACS. Upon receiving the message, it triggers ISC which in turn configures the intermediate switches. ISC has the core functionality of configuring both intermediate SDN and non-sdn switches. When configuring intermediate SDN switches, the ISC packet simply bypasses the traditional switches and vice-versa. Intermediate SDN switches use LLDP as a network discovery mechanism, but do so with the help of the SDN controller. The flow chart in Figure 4 describes the algorithm to add Control Plane VLAN (prerequisite) to ports of intermediate switches. Figure 4: Flow chart to add Control Plane VLAN and Data Plane VLAN ACS: ACS is implemented as traditional DHCP server with extra parameters in DHCP/BOOTP message format. Discover Message: SDN option number 222 is added in the DHCP option field available in DHCP Discover message. The added option differentiates traditional Figure 5: Extended DHCP/BOOTP Protocol Offer Message, SDN Option 222 ACS has been implemented as a separate system from the SDN controller to provide the following features: Backward Compatibility Scalability Generalization (avoid controller specific design) ACC: ACC works similar to a DHCP client. The newly joined SDN switch acts as a traditional DHCP client and sends a request for SDN configuration parameters through a Discover message. In reply, it receives configuration parameters which are then used for controller registration. The flow of messages between ACC and ACS is shown in Figure 6. Flow of messages during Auto-Configuration: ACS Discover Message, which is sent by ACC, is a broadcast message and it has to pass through Layer 3 switches or router and reach ACS which provides SDN configuration parameters in Offer Message. As Layer 3 switches (both SDN and non-sdn) and routers do not allow these broadcast packets to pass through, we take the advantage of DHCP relay on these devices to avoid packet drop. These relay agents receive the broadcast packets and forward them to a particular ACS using unicast. The proposed method also supports networks that have multiple ACS. However, that requires complex relay agent configuration at the L3 switch. The rest of the system functionality is used as it is. In autoconfiguration, ACS exchanges a sequence of messages in a similar way with DHCP. This flow of messages is shown in Figure 6. OpenFlow Session: After all the configuration parameters have been received by the client, a TCP connection is 51
Figure 6: Message Exchanges between SDN Controller and newly added SDN Switch Figure 7: Network Diagram with available VLANs on each inter-switch links established between the new SDN switch and controller, and this initiates the registration process for the switch. Extended DHCP/BOOTP Option: Inherently, DHCP does not support SDN configuration and can be used for standard L3/L2 configuration. By enabling the 222 option in the extended offer packet, we provide support for SDN configuration. Generally, DNS-SD [17] is used for service discovery in networks. This requires identity parameters to be provided for every component associated with the network. By using our extension of the DHCP/BOOTP option, we remove the need for providing identity parameters to the different components of the network, reducing system overhead of parameter configuration. OF-CONFIG assumes pre-configuration of switches before they are bootstrapped into a network. However, the use of our option enables autoconfiguration of switches when they are plugged into the network, as explained above. Hence, instead of using three protocols for performing individual tasks, a single extension of the DHCP option covers auto-configuration in hybrid networks. 6. New SDN Switch: OVS 1.9.3 SDN Controller: Floodlight 0.9 6.2 6.3 Achievement and Suggestions for Practical Deployment The proposed system has been confirmed to work in the following scenarios. SYSTEM VALIDATION 6.1 Performance Metrics The above suggested auto-configuration mechanism is a one-time deployment scenario for any new switch that is added to an existing hybrid network. If the intermediate switches in a network are not configured, then ISC packets are sent out into the network, adding some overhead to the existing network links and introducing increased latency in the process. The response time however, is completely dependent on the time taken for the switch to obtain its configuration parameters from ACS, as explained in Figure 6. Type of upstream switch: SDN and non-sdn switch Case Study We developed the proposed system and tested in the SDN/nonSDN hybrid network described in Figure 7. The proposed method coordinates configuration for a newly joined SDN switch and intermediate switches without disturbing the existing network setup. We examine the behavior of a new SDN switch and existing network under the following conditions. A new SDN switch is connecting to a non-sdn L2 switch. One non-sdn switch does not have VLAN configuration of Control Plane and Data Plane. Connectivity from upstream switch to ACS: Same VLAN or DHCP Relay Connectivity between the new SDN switch to ACS: Same VLAN or VLAN deployment on intermediate switches using ISC. Selection of the best SDN controller based on network topology to solve run time issues in case multiple controllers are available. This work is limited to address controller fail-over problem. Based on the examination of proposed system, the following points contribute to making auto-configuration of SDN switch easier in the existing network. For testing purposes, the following components were used: Non-SDN L2 Switch: Cisco SG300 Native VLAN on a trunk port enables to capture Discover message from ACC running on a new SDN switch. Existing SDN Switch: HP 3800-24G-PoE+2SFP+ 52
Use of DHCP Relay is realistic if the existing network is large. MAC-Port matching mechanism is a must on the non- SDN switches if the existing network needs ISC. 6.4 Discussions Security Challenges: The improvements in the system in terms of ease of deployment comes at the cost of security. It is possible that a malicious user who manages to get a physical access to an existing switch can connect an OVS to it and obtain a direct connection to the network controller. Once this malicious user has established connection, the user can very easily launch a DoS attack on the controller, tearing down the network. Network Loops: One drawback with introducing a new switch to the network is that it may introduce a loop in the network, that is caused by the changes made to the intermediate network (converting a few access VLAN to trunk mode). Prior to the switch being added, the Spanning Tree Protocol removes loops in the network, and with the addition of the switch, if loops are introduced, it is still not studied whether the Spanning Tree Protocol will remove the newly created loop in the network. 7. CONCLUSION AND FUTURE WORK This paper proposed a method that provides a new SDN switch with the configuration parameters for the SDN controller and itself. We also developed a system that dynamically configures intermediate switches to enable SDN functionality between the new switch and controller in an SDN/non-SDN hybrid network. As part of the future work, we can implement DHCP relay function at the SDN switch itself so that the impact of broadcast messages can be further minimized. Auto-configuration of a new switch as the replacement of damaged one can also be explored by estimating the switch location. Some challenges will be there to verify whether the installation of a new switch is conducted as a replacement or a brand new one. Another study that can be conducted is the use of multiple controllers for enabling auto-configuration of SDN switches in a hybrid network. A further work that can be done is to implement secure bootstrapping of SDN switches in hybrid networks. 8. REFERENCES [1] 802.1AB. http://standards.ieee.org/getieee802/ download/802.1ab-2009.pdf. [2] DHCP. https://www.ietf.org/rfc/rfc2131.txt. [3] Floodlight. http://www.projectfloodlight.org/floodlight/. [4] NETCONF. https://tools.ietf.org/html/rfc6241. [5] of-config. https: //www.opennetworking.org/standards/of-config. [6] onf-overview. https: //www.opennetworking.org/about/onf-overview. [7] openflow. https://www.opennetworking.org/ sdn-resources/onf-specifications/openflow. [8] openflow-spec-v1.4.0. https://www.opennetworking.org/images/stories/ downloads/sdn-resources/onf-specifications/ openflow/openflow-spec-v1.4.0.pdf. [9] OpenVSwitch. http://openvswitch.org/. [10] sdn-definition. https://www.opennetworking.org/ sdn-resources/sdn-definition. [11] SNMP. https://www.ietf.org/rfc/rfc1157.txt. [12] Dan Levin, Marco Canini, Stefan Schmid, Anja Feldmann, and Tu Berlin T-labs. Toward transitional sdn deployment in enterprise networks, proc. open networking summit (ons), 2013. [13] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer Rexford, Scott Shenker, and Jonathan Turner. Openflow: Enabling innovation in campus networks. SIGCOMM Comput. Commun. Rev., 38(2):69 74, March 2008. [14] S. Sharma, D. Staessens, D. Colle, M. Pickavet, and P. Demeester. Automatic bootstrapping of openflow networks. In Local Metropolitan Area Networks (LANMAN), 2013 19th IEEE Workshop on, pages 1 6, April 2013. [15] Schiff, Liron and Schmid, Stefan and Canini, Marco Medieval: Towards A Self-Stabilizing, Plug & Play, In-Band SDN Control Network [16] ONF Testing Interopability White Paper, March 2012, Whitepaper-v-1.0 https://www.opennetworking.org/ images/stories/downloads/sdn-resources/ onf-specifications/openflow-test/ onf-testing-interop-march-2012-whitepaper-v1. 0.pdf [17] DNS-SD. http://www.ietf.org/rfc/rfc6763.txt. 53