Operationalizing the Network: SDN

Transcription

1 Operationalizing the Network: SDN Our world, our relationships, and our businesses are being transformed by applications. SDN promises to transform the networks responsible for delivering them. White Paper by Lori MacVittie

2 Contents Introduction 3 Business Transformation 3 Network Transformation 3 A Solution for an Application World: SDN 4 Classic SDN 4 Emerging SDN 4 Stateful Versus Stateless Networking 5 How SDN Operationalizes the Network 5 Benefits of SDN 6 Improve Time to Market 6 Decrease Risk 6 Reduce Operating Costs 6 The Role of F5 in SDN 6 Conclusion 7 2

3 Introduction Applications are changing the world around us. Every facet of our lives has been affected by the explosion of applications on the web; on our phones; and in the common, everyday things we use to manage our homes, our cars, and our lives. Whether we re managing the efficiency of our appliances, our business and personal relationships, or just playing around, applications are enabling us to connect and communicate with everyone and everything around us. This explosive growth is not without consequences for those who provide the applications. Whether service provider or enterprise, retailer, or manufacturer, applications are driving new requirements for both businesses and networks that require disruptive, radical change. Business Transformation Business leaders are constantly under pressure to find new ways to attract, engage, and retain customers to encourage the growth necessary to succeed in a highly competitive world. Applications offer an opportunity to redefine convenience with new business models that take advantage of advancements in technology, enabling affordable and powerful computing options across a wide variety of consumer devices. As the market attempts to satisfy its nearly insatiable appetite for more convenience, more connectivity, and more control over their lives through applications, businesses must be able to adapt quickly or risk losing an increasingly fickle and hard-to-please consumer base to competitors. Pressure is increasing on data center leaders to transform the network to support rapid changes in direction and demand. Network Transformation The networks in place today were designed and built to support a web-based economy. Scalability models, security, and topology were as fixed as the users and ecosystem of partners and distributors supporting the business. Change was forecasted, growth anticipated, and network capabilities expanded and enhanced on a fairly predictable schedule. The explosion of new applications and application models has changed that. Users are no longer fixed, ecosystems are selected on demand, and consumers are increasingly 3

4 application-oriented shifting the burden of customer support and engagement from simple web applications and call centers to interactive mobile applications. Networks were not built to handle the rapid changes in demand for one application over another, nor were they built to scale and adapt as quickly as business requires today. A Solution for an Application World: SDN To transform the network from its fixed and predictable architecture to an agile and adaptable one is no small task, particularly without significantly increased costs. Softwaredefined networking (SDN) promises to do just that, with an architectural approach that reduces operating expenses and improves time to market. SDN achieves this by operationalizing the network through programmatic interfaces (APIs), automation, and abstraction across a standardized platform. Classic SDN SDN is not a new concept. The notion of separating control and data planes has been around since well before it became the industry darling du jour. Automation and APIs Automation, supported by APIenabled infrastructure, is key to SDN architectures and scaling network operations to support the next generation of apps being driven by mobile, cloud, and the Internet of Things. F State of Application Delivery survey results: 46% of respondents rate APIs as very important for infrastructure. 71% who want SDN to reduce OpEx rate APIs as important/ very important. Initial definitions of SDN by the Open Networking Foundation (ONF) restricted it to stateless network services by relying on OpenFlow as its primary protocol and the inability of its architecture to scale when presented with the need to manage stateful network services. Over the past few years it has become evident that the classic definition of SDN was insufficient to meet the expectations of a market under pressure to transform the entire data center. The classic focus on stateless networking leaves unaddressed the challenge of operationally scaling stateful network services. A new SDN model is now emerging that is better able to support the entire network stack. Emerging SDN When F5 asked the market its opinion, 59 percent agreed that classic SDN could not support the stateful services applications need. The emergent definition of SDN takes that into consideration and focuses instead on operationalization of the entire network, which offers benefits that align with those the market is demanding. Why IT Wants It One of the primary benefits touted by classic SDN proponents of its architecture was a reduction in CapEx. That benefit came in third in the F5 survey. 38% of respondents want SDN to reduce CapEx. 66% want SDN to reduce OpEx. 44% want SDN to improve time to market. SDN achieves this by separating control and data planes, and using programmability to encourage automation and orchestration of service provisioning. SDN also uses integration 4

5 with other systems to transform the network from a fixed, manual model to an agile, automated set of services. Stateful Versus Stateless Networking A key inhibitor of classic SDN success is that its design principles were largely based on the behavior and needs of stateless network services (L2 4). Stateful network services (L4 7) introduce significant technical challenges that are not easily addressed by classic SDN architectures. Stateless SDN assumes that all state is centralized in the controller. Rules regarding forwarding of packets are distributed to the data plane as needed. About one in every million packets requires a query to the controller. Stateful networking services, however, are named as such because they maintain state on a per-flow basis at layers 4 7. Assuming a classic SDN architecture, this would require a query to the controller every four packets at most. Additionally, the controller would need to maintain a massive session table (one per flow) to ensure proper forwarding across the network. The classic, stateless SDN model does not scale to meet the needs of stateful layer 4 7 services. Without support for stateful layer 4 7 services, SDN fails to operationalize the entire network and organizations will not realize its full potential. How SDN Operationalizes the Network Traditional networks comprise hundreds of network devices providing a robust set of services. These range from routing and switching to application performance, availability, security, identity, and access control and mobility. Manually configuring these devices and services for each and every application consumes a considerable amount of time for both network and operations teams. By shifting the burden of provisioning and configuration to scripts, templates, and orchestration systems, network services can be deployed in much less time and with greater consistency. To enable this, network and infrastructure devices must be programmable; they must enable configuration and provisioning via open APIs at a minimum. Application services 5

6 templates can further reduce risk and improve time to market by encapsulating common tasks in an executable package easily deployed with a single command. Using open APIs further enables integration with network automation and orchestration systems such as Cisco ACI, OpenStack, and VMware NSX. This approach provides an end-to-end network services provisioning model in which app deployments can be supported in hours or days instead of weeks or months. Benefits of SDN Improve Time to Market Operationalizing the network with a software-defined architecture enables faster time to market through automation and orchestration of network service provisioning. By using API-enabled infrastructure, application-driven service templates, and data path programmability, network services can be provisioned in hours instead of months. Decrease Risk Human error is a significant contributor to network downtime. Troubleshooting configuration errors across the hundreds of devices that make up the network takes time. By centralizing the state of the network, engineers gain greater visibility and control and can easily pinpoint trouble, minimizing disruptive downtime. Reduce Operating Costs Operationalizing provisioning processes results in greater efficiency, which can translate into lower costs per application deployment. The use of automation and orchestration enables an economy of operational scale not achievable using traditional, manual provisioning methods. The Role of F5 in SDN The F5 Synthesis architectural vision fills the need for stateful L4 7 services required of a comprehensive SDN architecture. It is application-driven and delivers F5 Software-Defined Application Services (SDAS) critical to delivering modern applications that can meet user expectations while complying with business and regulatory requirements. F5 Synthesis focuses on transforming the delivery of application services from the static and siloed topologies of yesterday to the dynamic, virtualized, and programmatic model required today to take advantage of the emerging application economy. 6

7 Conclusion The focus of SDN is on transforming the network to support applications and meet the expectations of users and businesses that rely on them. Scaling modern networks is challenging due to the explosive growth of compute, network, and application resources combined with increased mobility of apps migrating to the cloud and users across multiple devices. As an approach to operationalizing the network, SDN enables organizations to achieve greater economies of operational scale through the use of APIs to automate and orchestrate the network, as well as the application services that support applications. F5 Networks, Inc. 401 Elliott Avenue West, Seattle, WA Americas Asia-Pacific Europe/Middle-East/Africa Japan 2014 F5 Networks, Inc. All rights reserved. F5, F5 Networks, and the F5 logo are trademarks of F5 Networks, Inc. in the U.S. and in certain other countries. Other F5 trademarks are identified at f5.com. Any other products, services, or company names referenced herein may be trademarks of their respective owners with no endorsement or affiliation, express or implied, claimed by F5. WP-SDN