Software- Defined Networking: Beyond The Hype, And A Dose Of Reality

Transcription

1 ANALYST BRIEF Software- Defined Networking: Beyond The Hype, And A Dose Of Reality Author Mike Spanbauer Overview Server virtualization has brought the network to its knees. Legacy architectures are unable to keep pace with the dynamic needs of a virtualized or cloud- enabled environment. Software- defined networking (SDN) proposes a solution that is designed to solve, reduce, or eliminate many of the networking challenges that are the product of the past 30 years of network evolution. Industry reaction to SDN has been wide- ranging; the technology has resulted in more discussion for enterprise network architectural design than has any other since the advent of Ethernet. With many standards groups and technology governance bodies contributing to the best practice soup that is the SDN ecosystem, enterprises are often left to assess for themselves which vendor, approach, and time frame will best suit their own adoption of SDN. Further complicating matters is the fact that the adjacent and complementary, yet completely separate, network functions virtualization (NFV) solution has been mistakenly viewed as a feature of SDN. SDN introduces new risks and challenges: The idea of centralized control conjures images of single point of failure (SPOF) risk; redundant controllers require peer trust capabilities; centralized intelligence provides cyber criminals with the ability to subvert or disrupt using just a single point; and there is the traditional challenge of multi- vendor interoperability within networking. Regardless of whether an enterprise considers itself aggressive or conservative in its adoption of technology, there are a number of questions that must be addressed in order to ensure selection of the correct architecture on the path toward adoption of SDN. While SDN as a concept is quite open in terms of the direction an enterprise can choose to take, an enterprise s choice of solution today will lock it into this partner ecosystem for years to come. The greatest potential lies in the future of application- driven environment controls: when permissions are authorized, applications are able to autonomously adjust network parameters based on traffic patterns, application priority, and service level agreements (SLAs). Although this particular solution is years from realization, SDN will undoubtedly dominate enterprise networks in the future.

2 NSS Labs Findings With computing scale virtualization and cloud infrastructure demands, networking automation and management has become crucial for the enterprise. Purchasing decisions are no longer a matter of determining port density and speed due to unique application and server team requirements. While SDN, NFV, and other new technologies offer network value- add and provide customers with a robust set of solution options in the marketplace, non- partisan education and impartial guidance are key. Interoperability between SDN ecosystems will likely continue to be an issue. Performance claims are implied but unstated, and there is a lack of data on real- world networking throughput across these emerging SDN products. Any choice of an SDN solution today will have a significant technological impact on future network and virtualization projects, specifically cloud management solutions and NFV. NSS Labs Recommendations Perform due diligence and commit to true non- partisan education during selection of SDN architecture. Monitor standards groups and investigate which framework or model best aligns with the organization s technical requirements and organizational structure. Challenge incumbent technology vendors as well as new entrants on the interoperability capabilities and depth of their solutions. Ensure proof of concept (POC) tests are thorough and that the network- enabled applications are tested together rather than individually. Thoroughly review security controls, and validate trust capability against existing policies. If exact security controls do not exist, a compensating control will be needed, such as a jump box. Include cross- functional representation during planning and testing, i.e., network, developers, operations. Adopt a conservative approach during the long- term process of migrating to SDN enablement. Begin with basic overlay capabilities to optimize the organization s existing virtualized application infrastructure. Depending on SDN commitment and budget limits, seek requests for proposal (RFPs) from leading infrastructure suppliers to investigate the more advanced, though often proprietary, technology that is available with a single vendor solution. Evaluate the organization s existing orchestration and management solutions to determine whether additional features or capabilities will require incorporation into an SDN adoption. Evaluate cloud management systems and NFV solutions in the context of SDN options. Prepare a long- term, multiphase budget for operation of a cloud management solution, using a roadmap approach for services and capabilities. Initial integration of SDN can be simple, but there is potential for unexpected operational expenditure (OPEX) and capital expenditure (CAPEX). 2

3 Table of Contents Overview... 1 NSS Labs Findings... 2 NSS Labs Recommendations... 2 Analysis... 4 A Software- Defined Networking Primer... 4 Proposed Benefits Of SDN... 4 The Physical Network Got Us Here... 4 Virtualization Changed The Rules... 5 SDN Solutions... 5 Virtual Switching... 5 Hybrid Solution... 6 NFV, Not SDN... 6 Adoption Rate To Date... 6 Contact Information

4 Analysis Software- defined networking has changed forever the conversation that enterprise information technology (IT) departments have when discussing the network. While few enterprises have aggressively deployed the technology, most have asked, What is it, and why do I care? To answer these questions, the technology foundation must be established, and this can only be accomplished by understanding the evolution of network technology to date. A Software- Defined Networking Primer Proposed Benefits Of SDN SDN aims to make networking easier to deploy, more scalable, and less prone to error. For example, a reduction in the number of configurations that are controlled manually will result in fewer outages due to user error. Through self- healing heuristics and intelligence, networks can autonomously address weak or broken links without the consequences associated with legacy network technology. Applications or cloud orchestration systems can petition for, or configure, temporary application or system links for a specific period of time, thus limiting the costs of over buying or over- provisioning fee- based links. SDN promises these benefits and others; however, to understand the advantages of SDN, it is necessary to understand the evolution of networks and their accompanying problems. The Physical Network Got Us Here For years, networks evolved fairly predictably: speed increases occurred in factors of 10, routing and switching incrementally improved the management domain and reduced broadcast noise, and cabling economics followed the adoption curve (copper to fiber, custom to commonplace.) The network device formats that accompanied this progression remained relatively static or unchanged, whether fixed or chassis- based devices. A networking device (for example, a switch or a router) moves traffic (generally Ethernet frames) around the network. Traffic is directed to a destination either through programming, or by devices learning the path, or through shared intelligence from a peer device. Manual programming of devices is a laborious process, although it does provide some certainty as to the traffic s destination and the time it will take to arrive, which is useful in tenant service assurance environments, such as Multiprotocol Label Switching (MPLS), or in other traffic- engineered deployments. Within the learned environment, devices broadcast or use discovery mechanisms, for example, to determine which devices are either directly attached or paths to use to get to other networks (use port 2 to get to New York, port 3 for Tampa, and so on). With shared intelligence, devices share address tables, routes, or other path intelligence to reduce the learning period and improve the traffic performance (for example, ebgp). The traffic is moved about on the data plane and the directions for moving from one point to another are managed by the control plane. The control plane itself is a complex and powerful software stack that each networking vendor has developed and must maintain and update as new features are added, which further complicates the update process: consider the magnitude of updating software across an enterprise of thousands or tens of thousands of ports. Software- defined networking proposes that enterprises can separate the two aspects, data and control, operating the control plane remotely and merely providing updates to the data plane on some frequency or an as- needed basis. 4

5 Virtualization Changed The Rules Commercial virtualization enabled hardware abstraction of immense proportion resulting in unprecedented networking demands. Instead of data centers with hundreds of servers or hosts, environments can be constructed based on tens to hundreds of thousands of servers, all of these enabled as a result of a server s ability to virtualize the host, and therefore host addresses, across the network. To provide for this, virtualization vendors evolved their own network adapter, a virtual switch, to manage traffic both onto and across the physical environment. However, bound by legacy routing, address space rules did not scale. The original specification of 4096 virtual LANs apparently could not manage the machine scale required within these emerging multi- tenant, hyper- scale data centers, or even in the more traditional enterprise data centers where virtual local area networks (VLANs) were used as a form of management. In addition, many Ethernet access switches had MAC table capabilities that were insufficient for the growth proposed. As virtualization had already proven its business worth, and as its adoption accelerated, the market needed to counter the networking limits of legacy technology. SDN Solutions An enterprise can pursue two models for SDN enablement. The all- virtual solution focuses on virtual machines and their supporting virtual network, which operates on top of the physical network and remains a separately managed discipline. The second model is a hybrid of the virtual and physical SDN solutions, enabling a combination of the virtual switching and physical switch integration through a controller and the protocols that coordinate resources. Both models require significant investment and, since the process of SDN enablement will require significant change, a shift in the mindset of enterprise IT staff. Virtual Switching Customers that seek to improve or optimize performance, applications, or ease of management within a virtualization environment may select an overlay. Overlay networks assess and manage the links and virtual machines, and they assist in the real- time configuration and deployment of new machines as they spin up and spin down, either reducing or eliminating the lengthy task of manually configuring a new machine. These overlays employ agents that are often tightly integrated or can even replace the virtual switch network stack within the virtual machine. Coupling these agents, or vswitch alternates, with the central control function results in a centrally configurable and highly resilient SDN solution that is tailored for virtualization. Additionally, there are software vendors that focus on enablement of the SDN ecosystem as a whole. Vendors such as BigSwitch Networks have adopted a big picture perspective and have invested in the optimization and productization of the controller intelligence itself. In addition to the controller, BigSwitch is investigating value- add services, such as network test access points (TAPs). PLUMgrid is another software- only, hardware- agnostic vendor that focuses on the controller element, thus enabling a host of multi- tenant applications that can run in virtualized contexts secure from the adjacent network service, such as those required by multi- tenant hosting providers. Through its concept of overlay networks, the second model offers the least disruptive migration to SDN. Solutions such as Midokura MidoNet, VMware s NSX, or PLUMgrid s VNI Platform allow customers to use their existing network infrastructure while capitalizing on the centralized management benefits offered with SDN. 5

6 Hybrid Solution While the full software or virtualized solution is relatively simple, the hybrid solution marketplace is more diverse. Incumbent networking vendors, such as Cisco Systems, have developed their own virtual switch stack: network API agents that run at the access layer, as well as at the aggregation and core layers; a carrier set of API s to further extend this feature set; and, most recently, an application- centric architecture that was hinted at with Cisco s spin- in, Insieme. The hybrid marketplace also includes the open standards and interoperability stalwarts, such as Extreme Networks, HP Networking, and the Dell Enterprise Networking Group (formed after its acquisition of Force10). Along with the vendors, are the open standards support groups, such as the Open Networking Foundation, the Open Linux Foundation, the OpenStack initiative, CloudStack, and, most recently, the OpenDaylight project within the Open Linux Foundation. These groups collaborate to strengthen the SDN ecosystem, including the development of standards, interoperability, and common API development. NFV, Not SDN NFV was initially borne out of a carrier need to reduce the CAPEX and OPEX associated with proprietary, expensive network service appliances. New services for a carrier are costly and require between one and three years to deploy. The NFV goal is to standardize services on industry standard hardware (generally x86 servers) and to enable the remote provisioning of these services without an onsite engineer, thereby eliminating the need to have engineers visit every site. While NFV is a complement to SDN, it should not be confused with an SDN application such as varmor, the SDN network firewall solution. This distinction is discussed in the introductory white paper on Network Functions Virtualization. 1 Adoption Rate To Date If SDN will eliminate much of the network device maintenance tasks, reduce the error- prone steps to manual configuration, and increase performance and uptime, why has there not been widespread adoption? Barriers to enterprise adoption include risk of interoperability, lengthy POC tests, the potential for dependence on a large amount of new hardware, and a reluctance to deploy untested code on critical networks. Controller peer- to- peer security mechanisms are not yet established; thus, unless an enterprise controls and manages an entire network domain, virtual or physical, the benefits of SDN are limited to those areas in the domain under the enterprise s control. Ideally, an enterprise and a provider would have a trust agreement based on a service level agreement (SLA) that would establish the requests that could be made by a controller, as well as their frequency and their scope. Today, however, unless both customer and provider are on a single vendor s SDN controller solution, the ability to establish peer trust models has not even begun beta testing, much less been offered as a production solution

7 The biggest benefits of SDN occur within moderately- to highly- virtualized environments. Here, the SDN toolsets are the most evolved to accommodate virtual machine deployment. An enterprise with a large percentage of non- virtual machines will not realize the same economic benefits and therefore has less need for SDN. Application- driven environment controls have the greatest potential. Here, applications, when permissions are allowed, are able to autonomously adjust network parameters based on traffic patterns, application priority, and SLAs. Although this particular solution is years from realization, SDN will undoubtedly dominate enterprise networks in the future. 7

8 Contact Information NSS Labs, Inc. 206 Wild Basin Rd Building A, Suite 200 Austin, TX USA +1 (512) This analyst brief was produced as part of NSS Labs independent testing information services. Leading products were tested at no cost to the vendor, and NSS Labs received no vendor funding to produce this analyst brief NSS Labs, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the authors. Please note that access to or use of this report is conditioned on the following: 1. The information in this report is subject to change by NSS Labs without notice. 2. The information in this report is believed by NSS Labs to be accurate and reliable at the time of publication, but is not guaranteed. All use of and reliance on this report are at the reader s sole risk. NSS Labs is not liable or responsible for any damages, losses, or expenses arising from any error or omission in this report. 3. NO WARRANTIES, EXPRESS OR IMPLIED ARE GIVEN BY NSS LABS. ALL IMPLIED WARRANTIES, INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON- INFRINGEMENT ARE DISCLAIMED AND EXCLUDED BY NSS LABS. IN NO EVENT SHALL NSS LABS BE LIABLE FOR ANY CONSEQUENTIAL, INCIDENTAL OR INDIRECT DAMAGES, OR FOR ANY LOSS OF PROFIT, REVENUE, DATA, COMPUTER PROGRAMS, OR OTHER ASSETS, EVEN IF ADVISED OF THE POSSIBILITY THEREOF. 4. This report does not constitute an endorsement, recommendation, or guarantee of any of the products (hardware or software) tested or the hardware and software used in testing the products. The testing does not guarantee that there are no errors or defects in the products or that the products will meet the reader s expectations, requirements, needs, or specifications, or that they will operate without interruption. 5. This report does not imply any endorsement, sponsorship, affiliation, or verification by or with any organizations mentioned in this report. 6. All trademarks, service marks, and trade names used in this report are the trademarks, service marks, and trade names of their respective owners. 8