efficient automation platform. When a tenant VPN connectiv- ity request is received, the cloud-network plugin forwards the user request to our SDN controller.
A Software Defined Cloud-Gateway Automation System using OpenFlow Sriram Natarajan, Anantha Ramaiah, Mayan Mathen NTT Innovation Institute Inc.
Abstract—The notion of programming the forwarding device using an open protocol is a key feature of Software-defined Networks (SDN). This improves network visibility and control thereby reducing vendor dependency. OpenFlow protocol provides a standardized approach to realize these goals of SDN. In this paper, we illustrate our progress with a Software-defined Cloud-Gateway automation system using OpenFlow. In addition, based on our deployment experience, we highlight two technical challenges when using OpenFlow. First, with the standardization being an evolving effort, we highlight some of the programming challenges and missing features within the OpenFlow protocol. Secondly, existing OpenFlow-based network stack lacks some architectural components that reduces the level of flexibility we achieve when programming the network. Most SDN controllers expose limited abstractions to build network applications thereby primarily functioning as an OpenFlow driver. This imposes an application programmer to work with several OpenFlow primitives. To address this problem, we elaborate our current work in extending the SDN stack to improve our overall network programmability experience. Index Terms—OpenFlow; Software-defined Networks; Network Programmability; Cloud Networking; VPN; Service Provider
I. I NTRODUCTION Software-defined Networks (SDN) provide the architectural support to program the forwarding devices using a standardized programmable interface [1]. A typical SDN stack consists of the following entities: 1) infrastructure layer wherein each forwarding device consists of one or more tables (i.e., FlowTable) to determine how data packets should be forwarded, 2) control plane layer (e.g., OpenFlow controller), which is responsible for updating the FlowTable based on application requests, and 3) an application layer providing network services (e.g., routing protocols, security service, network debugger) and handling business support system, as shown in Figure 1. This split architecture model introduces standardized control of network resources, reduces vendor dependency as well as facilitates in achieving customers business agility goals. A programmable forwarding device provides interfaces for applications to modify the network state dynamically. This changes the paradigm from traditional network appliances wherein such programmability is not standardized and possible. From Service Providers (SP) point of view, the flexibility in using a programmable device allows us to improve our operations by building novel network services (e.g., interactive debugging) as well as redesigning the control plane logic. Therefore, our goal here is to leverage the programmability
Fig. 1.
Software-defined Network Stack.
feature by introducing an OpenFlow-based Gateway to function as a Provider Edge (PE) router in our network. NTT group identifies this project as key to unlocking value for our enterprise clients as they accelerate cloud migration and adoption because open, standards-based SDN increases feature velocity in the next-generation network. This paper contributes the following: •
•
•
Cloud-Gateway Automation Introduce NTT’s Enterprise Cloud offering and discuss our experience in building and deploying a Software-defined Cloud-Gateway automation system using OpenFlow. The primary goal of this system is to provide seamless operation of both cloud and network resources thereby improving our customers experience. Network Programmability Challenges Specific to our use case, we exhibit some network programmability challenges that we encountered in our deployment. In particular, 1) analyze the programming challenges associated with several OpenFlow attributes and determine any new security issues within our deployment consideration, 2) understand the impact of using various communication channels (e.g., TCP/TLS, UDP/DTLS) between the data and control plane on the packet forwarding functionality. SDN Architecture Extensions Enlist some potential missing pieces in the SDN stack and elaborate our SDN stack extensions to improve our network programmability experience.
The remainder of this paper is organized as follows: Section II discusses our Cloud Gateway Automation system, Section III discusses some of the architectural and programming challenges in an OpenFlow-based deployment, Section IV
!"#$!%%&$ 20#&304 *'#!)0#5!"
'(#!)&$ *++&(( ,-&. /!$#0%1
=>? @ 67&"8%!3 !"#$!%%&$ 67&"8%!3
Data Center Network
9/: ; &
