Transport Software Defined Networking: Part 1 Grabbing the Low-Hanging Fruit

Transcription

1 Advisory Report Transport Software Defined Networking: Part 1 Grabbing the Low-Hanging Fruit February 27, 2013 Rick Talbot Current Analysis Senior Analyst, Transport and Routing Infrastructure Contents Introduction SDN Development The Service Provider Case Challenges in Delivering SDN A Role for Transport SDN Potential Key for Realizing Transport SDN Open Transport Switch Europe +33 (0) Or visit our Web site: 1

2 Transport Software Defined Networking: Part 1 Grabbing the Low-Hanging Fruit In October 2012, network operators and vendors gathered with software-defined networking (SDN) developers and academics in Darmstadt, Germany, at the SDN & OpenFlow World Congress to give the SDN community a voice to share its thoughts and provide some structure to what has become a broad, and in many ways, unstructured, debate. This was the first SDN conference to draw heavy service provider participation, so it provided a stage on which operators and vendors could address what SDN should (or could) mean for service providers. While the concepts of SDN as a programmable or intelligent network have been developed since the 1980s, the current interest in SDN is associated with the development of OpenFlow, which was originally (circa 2008) a method for researchers to run experimental protocols in their existing networks. OpenFlow is now referred to as the first standard interface designed specifically for SDN. Service providers, meanwhile, have begun to discover a number of opportunities, in both cost reduction and revenue generation, offered by SDN. This service provider interest appears to be reaching critical mass in 2012, and now some vendors are calling their solutions SDN-based, while others are developing SDN solutions. All the while, vendors and carriers have created a mélange of messaging that while increasing SDN s visibility, has muddied the waters as to exactly what SDN means and how vendors and carriers should be planning now to best address the concept. This report is the first of a two-part series that examines the fundamentals of SDN and describes the emerging role of Transport SDN, and then, in the second installment, compares the key vendor approaches as they stand today. This first installment examines the reasons why service providers are considering SDN for their networks and presents some of the challenges to deploying SDN in service provider networks. It defines a relatively new variant of SDN, Transport SDN, and describes how it can be used to overcome some traditional service provider challenges. Finally, the report looks at a particular Transport SDN challenge multi-vendor interoperability - and a potential solution to the challenge Open Transport Switching (OTS). Current Perspective At the heart of SDN is the concept that a central controller decides what paths traffic takes through the network (a function called the control plane), while the physical switching of the traffic takes place out in the switches and routers of the network (a function called the forwarding plane). This centralization of the network intelligence and state provides a central global network view. Centralized control has been the norm for optical and TDM transport networks, but packet networks, under the influence of the ubiquitous Internet, have been developed with distributed control planes (that is, paths being determined by network switches and routers). In addition to centralizing a previously distributed control plane, SDN also provides a programmable network operating system (NOS) that controls the network and offers open application programming interfaces (APIs). SDN can be depicted diagrammatically as in the figure below: Europe +33 (0) Or visit our Web site: 2

3 Source: Current Analysis In the figure, multiple applications provide requirements (or requests) for the centralized SDN controller to fulfill by directing configurations of the network elements. The OpenFlow protocol can be used on the links between the SDN controller and the network elements to provide an open method of controlling the network. SDN Development Today s SDN, which has garnered so much attention, has at its roots the development of networking concepts in several universities, particularly Stanford University and the University of California at Berkeley, in the mid-2000s. This development led by 2008 to the concept of OpenFlow, a network architecture that featured a central programmable controller of simple Ethernet switches. By 2010, data center operators were considering employing OpenFlow in their environments. Google expanded the vista of SDN by building its own OpenFlow network hardware from merchant silicon and deploying it in its global G-scale wide area network (WAN). Interest in SDN continued to increase to the point that VMware purchased SDN start-up Nicera in July 2012 for $1.26 billion, indicating that SDN concepts had moved far beyond academic discussions and lab trials; the industry was now making significant investments in the technology. The Service Provider Case Network service providers see the value of SDN inside the data center and are investigating SDN as a disruptor to address a number of needs in their WAN networks. They see content and virtualized processing resources being distributed among multiple data centers, and applications within the data centers, such as data backup and time-of-day shifts in access and processing, invoking tremendous changes in data flows between the data centers. Some of these flows are unpredictable, such as when videos taken during natural disasters go viral, or when emerging cloud computing Infrastructure-as-a-Service (IaaS) moves server instances. This increase in data center interconnection (DCI) traffic (and its unpredictability) is occurring as overall network traffic is increasing, driving the need to rapidly scale the network at an acceptable cost. SDN may solve these network challenges by rapidly provisioning network resources to meet the dynamic traffic flows and providing real-time software-driven network optimization to achieve higher network scaling at lower cost through increased network utilization. Europe +33 (0) Or visit our Web site: 3

4 Service providers are also seeking to deploy intelligent services that make use of network appliances such as firewalls, deep packet inspection (DPI) processors and session border controllers (SBCs). In an effort to optimize the performance of the network, they also use a host of probes, data collectors, data tools and analytics engines. The network lacks traffic steering that would send only appropriate data flows to these network appliances, so operators currently must distribute innumerable appliances of various types throughout the network. Network operators view a continuation of this proliferation of various appliances throughout the network as untenable, so a group of operators recently formed the Network Functions Virtualization (NFV) initiative to explore the use of virtualization technologies to implement these specialized functions in software and run it on top of standard data center compute resources to increase scale and speed deployment. However, the network would still require a switching mechanism to steer the appropriate data flows to these specialized servers. SDN appears to be well-suited to provide this traffic steering. SDN promises multiple capabilities that may enhance service provider ability to monetize/leverage their networks to differentiate existing services, increase revenues, introduce new intelligent services and offset the competitive threat of over-the-top (OTT) services. SDN s centralized network abstraction and network optimization applications promise to supply end-to-end service connection designs of known quality of service (QoS), even in complex multi-layer, multi-vendor and multi-domain networks. Further, the comprehensive modeling of services in software before deployment and centralized control facilitates rapid service provisioning, resulting in reduced time to revenue and in services that can be differentiated based on their immediate availability. In addition, the SDN controller APIs offer the prospect of providing next-generation services that are driven directly by service provider or business applications, and that should also stimulate new application development as the SDN economy develops. A service provider could introduce the ideal cloud service in which an application running on a server signals the network, via the SDN controller, to provision for it a network connection. Challenges in Delivering SDN While SDN certainly offers tantalizing capabilities for service providers, it also presents them with formidable challenges. Perhaps the greatest challenge is the fact that service providers are operating complex infrastructures that perform a myriad of functions ranging from switching packets to billing customers. As such, they cannot simply switch out that infrastructure. Similarly, if operators were to build a complete overlay infrastructure and gradually transfer customers to it, they would bear the operating cost for both infrastructures during the transfer, which would likely be an intolerable expense. Some of the challenge of delivering SDN in a service provider network springs from limiting the concept of SDN to OpenFlow. Though OpenFlow is generally defined today as the protocol between the controller and the network switching elements, its developers definitely had an OpenFlow architecture in mind that envisioned commodity-priced switching elements based on merchant silicon to minimize network CapEx and a controller based on commercial off-the-shelf (COTS) servers in a data center that could run various applications. Whereas this model might have been appropriate for the limited number of services required in the defined environment of the data center, many operators and their vendors doubt that it can addresses the complexities of service provider networks. Another challenge of today s general SDN definition, and specific OpenFlow protocol, is that its controller only directs Layers 2 through 4 in routers and switches. Service providers also must Europe +33 (0) Or visit our Web site: 4

5 manage wavelength and TDM (Layer 1) switching, so OpenFlow may need to be extended and augmented, perhaps with additional protocols, to support these lower layers. In addition, it remains to be seen if the model scales to move beyond the limited data center WAN implementation by Google, who has tens of nodes, to a full service provider network with hundreds and thousands of nodes. Further, in a fully centralized model, all controller connections with the switches extend across the network, which could be a scale and reliability issue (since a widespread network outage could disrupt those controller connections). These multi-layer and scale issues pertain not only to the original OpenFlow protocol, but they must also be addressed for any SDN architecture. A significant set of challenges in delivering SDN pertains to the existing network switching elements that make up service provider infrastructures. Besides the fact that service providers are not in position to replace their infrastructure, they also need some of the features provided by their existing network elements. For example, rapid network protection requires that the decision to switch be triggered in the switch itself, even if the back-up path is pre-provisioned by an SDN controller. Further, many vendors have designed unique features in their network elements (and networks populated by those elements), including some GMPLS control plane capabilities that network operators may not want to sacrifice. In addition, transport elements are managed by rich, proactive, element management systems (EMS) that are specific to each vendor. The network operators depend on these EMSs to manage their networked platforms; they will likely insist that the EMS functionality be implemented in any SDN context, or require that they end up running as applications on top of the SDN controllers. Similarly, SDN must be interworked with each service provider s existing operations support system (OSS)/business support system (BSS). These systems are thoroughly integrated with, and enable, the service providers operations, providing centralized ordering, provisioning, monitoring, control and billing, so any of these functions (such as provisioning) provided by SDN must be transitioned from the OSS/BSS, and the functions of the SDN controller and the OSS/BSS must be coordinated. This coordination will be complex, because it touches many, if not most, of the operations of the service provider. A Role for Transport SDN Whereas much of the current development of standard SDN is applied to data center and Layer 2-4 requirements, service providers may achieve a number of SDN-driven benefits for their transport networks (defined as wavelength/layer 0, Layer 1 and Layer 2/Layer 2.5 networks) from a concept called Transport SDN. Transport SDN configures and provisions transport network connections with defined transmission characteristics under centralized control that provides an abstraction of the network and open APIs for service and/or business applications. With this extension of SDN to the transport layers, an SDN controller could deliver multi-layer (Layer 0 through Layer 4) configuration based on user or application needs. There are various approaches to Transport SDN, some of which provide many of the centralized control functions of SDN in a way that could allow service providers to leverage their installed base while they migrate to a centralized SDN control approach. Transport SDN promises multi-layer network optimization (e.g., superior bandwidth utilization and defined QoS for connections), rapid multi-vendor, multi-layer and multi-domain provisioning, as well as the enabling of applications to leverage the information contained in the SDN controller to satisfy a connection request via the most cost effective layer of the network. SDN has visibility to, and control of, layers 0 4 and fundamentally presents the operations staff a global and virtualized view of the network that will let applications, whether operated by a human (such as with an NMS) or completely automated, request a network service to satisfy a particular application need. Addition- Europe +33 (0) Or visit our Web site: 5

6 ally a network operator can use the abstracted view of the network and the servers to develop and run simulations of the full-sized network for additions, reconfigurations for network failures, and models of unusual traffic patterns, such as in emergency situations. One of the key benefits targeted for Transport SDN is the ability to provision services across multiple data and transport layers and across multiple vendors. Transport SDN may eventually be able to cross these multiple networking domains to more efficiently deliver services end-to-end. These benefits not only enable speedier service provisioning, making service providers more competitive, but they can save costs by eliminating the significant manual processes that exist today between the data and transport departments. On the revenue side, Transport SDN promises to make the transport network flexible and available enough for it to be a viable revenue-generating service platform, itself. Potential Key for Realizing Transport SDN Open Transport Switch Despite the promises of Transport SDN for the service provider environment, developers need to overcome a fundamental challenge to unlock SDN s potential. The SDN controller must interwork with transport elements from multiple vendors, each of which employs an EMS, and many of which utilize their own control planes. One promising approach which is being widely discussed is to create a control agent, for each transport platform, that provides a common/standard interface to the SDN controller. This solution is called Open Transport Switch (OTS), a virtual transport switch that exposes an abstraction of the physical network element to the SDN controller over a standard (perhaps OpenFlow and other web-based protocols) connection. Source: Infi nera In the figure, OTS acts as an open interface that communicates topology information and network data to the SDN control layer while accepting provisioning and configuration commands from the SDN control layer. OTS will require development in the operating system and/or the EMS of the transport system and significant cooperation between the SDN controller vendors and systems vendors via standards bodies. Europe +33 (0) Or visit our Web site: 6