Software-Defined Networks

Transcription

1 Software-Defined Networks Steve Goeringer Abstract This white paper provides an introduction to software-defined network concepts. It covers related areas of work, discusses deficiencies of current networking practices, and defines software-defined networking (SDN). Discussion includes a review of SDN architecture, components, interfaces, and applications Polar Star Consulting, LLC This paper includes Polar Star Consulting Proprietary Information

2 Introduction Software-defined networking continues to be one of the most hyped technology evolutions in information and communication technology. It s been forecasted to achieve massive market growth, in one study touching a market of $1T US by Certainly, the market will not achieve $1T by 2019, but the study certainly emphasizes how very excitable the market has become about software-defined networking. Behind the hype, however, is a technology with profound benefits to industry and possibly essential to intelligent evolution of today s massive and complicated network infrastructures. Software-defined networking (SDN) centralizes network control, moving it from switches and routers to SDN controllers. This allows network traffic to be managed in the context of an entire network rather than from interconnected but locally controlled devices. SDN controllers use a standard interface, often OpenFlow, to program tables in controlled network elements. These tables, called flow tables, allow very granular control of network traffic, much more so than Ethernet based switching or IP based routing. Finally, SDN allows network operators to programmatically interface with controllers. See Figure 1. This white paper reviews SDN at a very high level. It discusses problems of current network solutions. Then it reviews SDN as a concept and shows how it mitigates some current problems. General architectural considerations are shown, and SDN components are defined. The paper concludes with a discussion of the challenges of implementing SDN and recommends that new information and communications technology initiatives consider SDN. Figure 1: Open Network Foundation s software-defined network architecture (11) P a g e 2

3 Related work Polar Star Consulting has multiple on-going research efforts on SDN. Several white papers are available upon request. A lab tutorial has been prepared and we continue to do research into the myriad of SDN use cases. The driving organization behind SDN is the Open Network Foundation (ONF). The ONF published standards, recommended practices, and published case studies. Two critical documents are Software- Defined Networking: The New Norm for Networks (1) and OpenFlow Switch Specification, now on version 1.5 (2). Implementation of SDN, however, varies widely and the hype cycle is in full swing. Each information and computing technology solutions provider has their own notion of how their customers can best implement and benefit from SDN. However, their ability to deliver must be scrutinized carefully with many providers offering SDN solutions that you can t actually buy yet. However, there are important initiatives that can give insight and from which insights can be earned. Specifically, open source software solutions for creating SDN controllers and switches. The most impactful SDN controller today is probably OpenDaylight (3), a Linux Foundation collaborative project. OpenDaylight (ODL), in fact, is breathtakingly audacious when the full scopes of their initiatives are understood. SDN switches are as important as SDN controllers. There are three initiatives to understand and track here. One is the OpenWrt initiative(4). Initially targeted at providing an open distribution to create Linux firmware for consumer grade wireless routers, several modern system on a chip (SoC) routers are able to implement rather complete Linux networking solutions. Consequently, some researchers have integrated OpenFlow versions 1.0 and 1.3 into OpenWrt. This puts doing SDN experimentation in the hands of the hobbyist or serious scientist at prices that are remarkable ($35 for a fully featured OpenFlow router is compelling). A more notable initiative is Open vswitch (5)(6). This largely independent open source software project provides a virtual switching solution suitable for deployment on a wide range of platforms, including Linux. It opens the door to developing high performance open SDN switching solutions on bare metal switches. A final open switch initiative that must be understood is still in infancy. Open Network Linux (7) is a subproject of the Open Compute Project (8). Network Functions Virtualization (NFV) is a key related work area to SDN. The European Telecommunications Standards Institute (ETSI) is spearheading work on NFV. NFV compliments SDN nicely, but they are mutually independent NFV can be implemented without SDN solutions, and SDN does not require NFV (9). Polar Star has prepared white papers on NFV that are available on request. P a g e 3

4 Problem statement Enterprises and service provider s information and computing technology infrastructure encompass thousands of network elements and tens of thousands of servers supporting hundreds of applications. These applications each have diverse information and computing technology requirements. And the information and computing infrastructure installed to support them has typically been deployed over one or two decades. The result is complexity, and complexity leads to stasis. (1) Figure 2: Complexity as illustrated by the Concorde Cockpit Consider a typical IT environment. Traditional IT solutions require a great deal of activity to make any change. To add, move, or configure any device, staff must touch multiple network elements (switches, routers, firewalls, and more) and server support applications (authentication portals, identity databases, etc ) and configure interdependent access control lists (ACLs), virtual local area networks (VLANs), quality of service (QoS), and many other mechanisms using device-level interfaces and tools. Interdependencies of all these policy elements are context specific, needing to account for network topology, proprietary network element uniqueness (including which versions of software and firmware are on each network element). Service providers, enterprises, carriers, and solutions providers (both hardware and software) find it increasingly difficult to scale IT and network solutions to provide the applications employees and processes need to satisfy customers and execute missions. Enterprises today cannot be static. Traffic patterns within modern networks are highly varied and change rapidly. Most enterprises must support access to corporate infrastructure from mobile devices such as smartphones, tablets, and notebooks both locally and remotely. Rapidly evolving IT strategies and business needs require agile and dynamic access to applications, telecommunications infrastructure, and a wide range of IT resources on demand. Managing operations expenditures require streamlined staffing which drives a need for self-service provisioning and trouble resolution. Big data applications need unprecedented numbers of connections supporting large flows of data on demand. Service providers and carriers have similar requirements. They need to deploy capabilities and services in response to the needs of enterprises. If the enterprise environment is dynamic, so must be the service provider environment. Unfortunately, traditional service provider services are enabled by proprietary solutions limited according to solution providers product release cycles (hardware and software). Moreover, scalability requires solutions to support concurrent customers (multi-tenancy) each requiring different combinations of services implemented using diverse policies with industry unique performance requirements. Achieving high-performance, low-cost connectivity supporting millions of devices requires scalability (hyper-scale) that cannot be achieved through traditional network methods and practices. P a g e 4

5 Solution Software-defined networking (SDN) employs a few fundamental engineering concepts to achieve flexibility and agility. It centralizes network control so that traffic can be managed in context of multiple network elements rather than one. This control is facilitated by fine grain control at network elements using a flow table that defines flows on which to take specific action. Flows are defined in terms of packet characteristics (10) relevant to the application supported (see side bar). Finally, SDN introduces interfaces for interacting with network control and interconnecting network control with network elements. The overall architecture as defined by the Open Network Forum (11) is shown Figure 3. Does this solve the problems outlined previously? It does to at least some degree. The network appears to the applications using the network as a single, logical switch. Centralizing network state and providing interfaces to interface with network control provides network managers the features they need to programmatically interface with the network to configure, manage, secure, and optimize network resources dynamically. (1) What is a flow? The concept of a flow is not defined in the body of SDN standards and other supporting documentation. Given the nature of OpenFlow, the definition for a traffic flow (10) as defined by the IETF is insufficient. Nor are the definitions of flow as applied to traffic characterization (e.g., NetFlow and sflow). Why is such a fundamental and pervasive term missing in the body of SDN documentation? Because flows are application specific, in terms of which OpenFlow version is employed, in terms of the actual ICT applications being supported (e.g., Microsoft Office, Web Servers, Hadoop, etc ), and the SDN functions being invoked. For a given SDN service, the notion of flow should be explicitly defined. This should include packet header elements, protocol state considerations, and more. Thorough research of OpenFlow standards is highly recommended. Design goals SDN will exhibit several characteristics. These are identified by the ONF as follows (11): Direct programmability Agility Central management Reliable Secure Granular network control Open standards-based Vendor-neutral Figure 3: ONF s software-defined network (11) P a g e 5

6 Architecture The SDN architecture is not much more complicated than the concepts defined above. Architecture components are organized functionally into three planes the application plane, controller plane, and data plane. These are nominally referred to as levels to differentiate from OSI layers in the data plane. The layers are interconnected by Figure 4: ONF s SDN architecture controller plane interfaces the Application-Controller Plane Interface (A-CPI) and the Data-Controller Plane Interface (D-CPI). Management interfaces will inevitably be necessary to administer many features of each plane. The resulting architecture is illustrated in Figure 4. (12) It s essential to view this architecture as a functional representation actual implementation may have a given physical device participate in multiple planes. Components Conceptually, SDN encompasses only a few components. Components are realized primarily as software elements, but are often distinct physical devices. Controllers The primary element of the controller plane. Implemented as software on a server, controllers have exclusive control over a set of resources exposed by the D-CPI. The purpose of the control plane is to provide network services to the applications it supports. A controller may support many applications. A given SDN control plane may contain multiple controllers organized as necessary for reliability and scalability. Controllers can be implemented as stand-alone servers or installed on virtual machines in a virtualized environment. Network elements The data plane is comprised of network elements. Network elements contain traffic forwarding and processing capabilities. These capabilities are locally controlled by a flow table as specified in ONF s OpenFlow standards. Controllers interface to network elements (and specifically the flow table) via the D-CPI interface. The most common examples of SDN network elements are routers and switches, but network appliances should be included as well. Examples include firewalls, application delivery controllers, SSL accelerators, WAN optimizers, load balances, and more. Applications Applications bridge business and mission needs to the SDN infrastructure. Applications may be very primitive and encompass very basic features such as the SDN equivalent of the Internet Protocols ping functionality or creating a MAC learning domain such P a g e 6

7 as an Ethernet hub. Applications might also leverage other applications and implement complex, transformational services such as a business aware connectivity manager that considers current business bandwidth needs against available network resources and optimizes connectivity of key business centers in real time. Applications interface with controllers via the A-CPI. Applications may run remotely from controllers, or may even run on the controller server or virtual machine. Interfaces As described above, the SDN architecture includes both an application-controller interface (A-CBI) and a data-controller interface (D-CBI). The ONF specifies D-CBI interfaces under their OpenFlow technical specifications, available on-line at The A-CBI is not specified by the ONF. However, SDN components may support additional interfaces as well. ONF specifies two D-CBI interfaces the OpenFlow Switch Protocol (OF-SWITCH) and the OpenFlow Management and Configuration Protocol (OF-CONFIG). There are already several versions of each of these, with the most recent switch protocol being version 1.5 and the most recent management and configuration protocol being version 1.2. When most people talk about OpenFlow, they are usually referring to the switch protocol; the management and configuration protocol is usually explicitly referred to as OF-CONFIG. OF-SWITCH provides an SDN controller an interface to add, update, and delete flow entries of flow tables in SDN network elements (nominally switches). See Figure 5. Each flow table contains a set of entries and each entry consists of match fields, counters, and actions to apply to matching packets (flows). (13) OF-SWITCH is the only standard protocol supporting this functionality. Figure 5: ONF OF-Switch components (13) OF-CONFIG provides a management interface to SDN network elements. It connects an OpenFlow configuration point process, which is not required to be associated with an SDN controller, to an operation context of the network element. Network elements must implement NETCONF as the transport protocol for management functions to support OF-CONFIG. OF-CONFIG implements a UML compliant data model encoded in XML for SDN network elements. OF-CONFIG has a companion YANG module distributed separately to aid in implementation of this data model. (14) P a g e 7

8 The A-CBI interface is not specified by ONF. Typical implementations use RESTful (Web 2.0) interfaces, Java, and Python. Some SDN controllers also include a graphical user interface, though functionality will be relatively limited. OpenDaylight uses a full Java code management system, including YANG support. Applications Given all the abstraction included in describing SDN, it might be hard to understand what an SDN application (service) might be or look like. At the most fundamental level, SDN applications are everything you may want a network element to do. This is very important to understand. Without specifically configuring a flow table, an SDN network element will not do anything. Some of the first applications an SDN network programmer might create are these basic applications (15): Network connectivity ( ping ). A basic hub that will flood any packet that arrives on a particular port of a switch out all the other ports (it s interesting to do this at both Ethernet and IP layers). A MAC learning switch that keeps track of where the host with each MAC address is located and accordingly sends packets towards the destination and not flood the packet like a hub (e.g., SDN network elements don t just know ARP). Stateless load-balancer for HTTP. Content-aware load balancer. Basic is relative there is a lot to learn and do when programming these applications. Fortunately, many of the basic switching and routing services are already written and available for inclusion in your network. Integrating these are controller specific, however. At a more meaningful level, SDN applications allow development of highly sophisticated services very hard to create in legacy networks. For example, an SDN programmer could create a service that interfaced with OSPF routing logic and packet header information to determine which flows should be forwarded to an encryption device. Fortunately, the ONF provided support for hybrid operation. Hybrid operations allow legacy switching and routing functions to be used for some ports and SDN applications applied to other ports. After all, it took a long time and a lot of work to build Ethernet and IP to work as well as they do today. Network operators should be reluctant to move to SDN unless there is specific functionality legacy network technologies cannot achieve. Analysis Does SDN fulfill its design goals? Within the enterprise environment where campuses, data centers, and cloud environments prevail, the SDN design goals are expected to achieve very specific benefits. Campuses should benefit from converged infrastructure, eliminating multiple overlay networks to support different services, including support of mobile environments. User experience in campus P a g e 8

9 networks should also be more managed. Data centers should achieve hyper-scalability, automated VM migration, improved integration and efficiency. (1) See Figure 6. Service providers and carriers have different needs but can also expect to achieve important benefits. SDN should enable service providers to implement a utility compute model approach to services, enabling an ITas-a-Service (ITaaS) paradigm. They should be able to orchestrate custom and on-demand services, and also enable a wide range of self-service capabilities. And they should be able to improve cost management by multitenancy, improved resource efficiency, proactive and service oriented cost management, and improved service delivery intervals. (1) See Figure 7. Figure 6: SDN benefits in the enterprise environment SDN is not essential to achieving these goals, however. Even using legacy techniques, many of these features can be implemented by programming mediation environments. In fact, this is largely what OSS/BSS (Operations and Business Support Systems) do. However, adaptation interfaces need be written for every equipment and application vendor and updated for each version of vendors software or hardware. Figure 7: SDN benefits in the service provider environment The ONF summarizes how SDN is essential to evolving networks in the foundation white paper, Software-Defined Networking: The New Norm for Networks. (1) Some specific feature benefits highlighted in the white paper are quoted below: P a g e 9

10 Providing self-service provisioning, whether in a private or public cloud, requires elastic scaling of computing, storage, and network resources, ideally from a common viewpoint and with a common suite of tools. Handling today s big data or mega datasets requires massive parallel processing on thousands of servers, all of which need direct connections to each other. By centralizing network state in the control layer, SDN gives network managers the flexibility to configure, manage, secure, and optimize network resources via dynamic, automated SDN programs. SDN architectures support a set of APIs that make it possible to implement common network services, including routing, multicast, security, access control, bandwidth management, traffic engineering, quality of service, processor and storage optimization, energy usage, and all forms of policy management, custom tailored to meet business objectives. There remain, however, significant challenges in realizing an SDN. Equipment and software providers have very smart people and many years bringing value to their customers. Proprietary implementations can provide key competitive advantages to enterprises and service providers. Hardware support varies dramatically. Many commercial switches and routers support only the first OF-Switch version 1.0 implementation, which is much less capable than OF-Switch version which is supported by only a few. Very few network appliances (load balancers, SSL hardware accelerators, WAN optimizers, encryption devices, etc ) support any version of OpenFlow. It is possible to integrate an SDN using open source tools and bare metal servers and switches. However, this moves all development responsibility to the IT enterprise or service provider. Moreover, achieving terabit/second scales as many environments now require may not be feasible with open hardware and software today. There are some fundamental issues to track in the SDN standards. Some level of control locality must continue to exist at each layer of SDN. Interaction and state management of distributed control is largely not resolved. This may not be a major issue for many network applications, however. A much more fundamental concern is deployment of SDN controllers in environments requiring high availability. The primary resiliency schemes used by industry seem to be traditional clustering and protection mechanisms at the link layer. This does not seem suitable for environments where service behavior is dependent on network state (such as agile management of shared risk groups or security domain management). Conclusions and Recommendations SDN promises specific and fundamental improvements in information and communication technology applicable to a wide range of environments. Benefits may include improved cost effectiveness, faster service delivery, improved customer experience, enhanced scalability, and simplified operations. Most equipment and software vendors in the ICT space are providing SDN solutions. Recommendations: P a g e 10

11 Current infrastructure should be evaluated to see how SDN can be employed for incremental improvements New initiatives should be required to consider SDN in the solution space, including complete cost benefit analyses. References 1. Software-Defined Networking: The New Norm for Networks [Internet]. Open Networking Foundation; Apr, Available from: 2. OpenFlow Switch Specification Version (Protocol version 0x06) [Internet]. Open Networking Foundation; Available from: 3. Meyer D. The OpenDaylight Project: Introduction and Overview [Internet]. Linux Foundation; 2014 Jan. Available from: dmm/talks/opendaylight_sdn_workshop_az.pdf 4. OpenWrt [Internet] Available from: 5. OpenvSwitch [Internet] Available from: 6. WhyOVS [Internet] Available from: 7. ONL [Internet] Available from: 8. OCPNetwork [Internet]. Open Compute Project; Available from: 9. Network Functions Virtualisation Introductory White Paper [Internet]. ETSI; 2012 Oct. Available from: Traffic flow (computer networking) [Internet]. Wikipedia; Available from: Software-Defined Networking (SDN) Definition [Internet]. Open Networking Foundation; Available from: Hood D. SDN architecture [Internet]. TR-502 Open Networking Foundation; Jun, Available from: Anders Nygren ZLK Ben Pfaff Bob Lantz Brandon Heller Casey Barker Curt Beckmann Dan Cohn Dan Talayco David Erickson David McDysan David Ward Edward Crabbe Fabian Schneider Glen Gibb Guido Appenzeller Jean Tourrilhes Johann Tonsing Justin Pettit KK Yap Leon Poutievski Lorenzo Vicisano Martin Casado Masahiko Takahashi Masayoshi Kobayashi Navindra Yadav Nick McKeown Nico dheureuse Peter Balland Rajiv Ramanathan Reid Price Rob Sherwood Saurav Das Shashidhar Gandham Tatsuya Yabe Yiannis Yiakoumis. OpenFlow Switch Specification Version (Wire Protocol 0x04) [Internet]. Open Networking Foundation; Apr, Available from: P a g e 11

12 14. Daniel Pitt AS Deepak Bansal Stuart Bailey Thomas Dietz Car Moberg Juergen Quittek Anantha Ramaiah. OF- CONFIG 1.2 OpenFlow Management and Configuration Protocol [Internet]. TS-016 Open Networking Foundation; Available from: Pseudo code of sample applications [Internet]. SDN Hub; Available from: P a g e 12