Editor’s Note: Welcome to our weekly Reality Check column where C-level executives and advisory firms from across the mobile industry share unique insights and experiences.
Software-defined networking is definitely on the radar screen of carriers, who are ahead of enterprises when it comes to adoption. The real promise of SDN is programmability – the ability to create adaptive networks that can be configured automatically to accommodate changing business demands. Indeed, there are several applications that are particularly suited to SDN in carrier networks. However, one stumbling block for everyone is network management. Until the elements in the FCAPS model – fault management, configuration, accounting, performance, and security – are addressed, SDN will remain more of an aspiration than a reality.
SDN applications for carriers
The most prominent SDN application so far is network virtualization. This is mainly a data center application and relevant to carriers who want to compete with over-the-top providers with value added services. In addition, there are three SDN applications in particular that carriers are considering or deploying to improve customer service in the wide-area network. These applications have some stumbling blocks that need to be overcome before becoming a reality.
Bandwidth calendaring
The current way of allocating bandwidth for applications in a carrier network is not suitable to offering stringent performance service-level agreements. Using a bandwidth broker can improve the situation. Applications such as video conferencing make API calls to a bandwidth broker to request a certain amount of bandwidth for an immediate need or at a future time. The broker either denies the request or accepts it and routes the applications’ traffic on existing paths or sets up new ones.
The trouble is that many applications do not know their needs ahead of time. Also, making the request may introduce additional latency. In addition, the number of flows on carrier networks is too large to be handled by the broker – and the per-flow paths are too numerous to be handled by the switches – in a scalable fashion.
As a result, the network needs to operate with both conforming and non-conforming applications. This presents a huge challenge since the broker cannot monitor all traffic demands accurately (and basing bandwidth decisions on instantaneous link utilizations has been proven to be unreliable).
SDN is a natural way to implement bandwidth calendaring. After receiving the bandwidth request, the controller computes a path that satisfies the requirements and sets it up using a south-bound protocol such as OpenFlow, ForCES or PCEP. However, before bandwidth calendaring becomes a reality, the stumbling blocks mentioned above need to be overcome.
Demand placement
In this application, users request to access some content (e.g., a video file) that is replicated and distributed geographically. The demand placement application directs the user to the closest copy of the content. This is a win-win situation for both the carrier and the user: The user has a better experience since the copy of the content is closer, and the carrier does not need to transmit the content across its network for every user who wants it.
There are already non-SDN solutions to this application. For example, GeoDNS, which is based on the domain name system, is widely deployed. Demand placement is an ideal application for SDN. This application would have access to the locations of the content as well as of the user, and using the topology provided by the SDN controller, would direct the user to the best location. The stumbling block here, however, is whether the SDN solution adds benefits beyond what is available with GeoDNS to justify the cost of deployment.
Rapid provisioning
Carriers are often criticized for taking days or even weeks to provision new services. There are often good reasons for this. For example, configuration changes typically must be done during maintenance windows and require expensive human resources, both of which need to be scheduled. A request may also involve physical resources (such as ports) that may not be immediately available.
Removing the human involvement from provisioning saves a precious resource, the operator, but more importantly reduces possible human error. Rapid provisioning is indeed surfacing as the killer SDN application for carriers beyond the data center. Network function virtualization makes many traditional hardware solutions available as virtual solutions. These solutions can now be introduced into the network programmatically without an operator involvement. Examples here include firewalls, deep-packet inspection appliances, load balancers, distributed denial of service appliances, radio and mobility devices and/or controllers for mobile networks. NFV overcomes the major stumbling block for rapid service provisioning, but carriers still need to be able to monitor the service once it’s deployed.
Management challenges
These applications are great use cases for SDN and promise to help carriers provide better customer service, but SDN does not eliminate the need for management best practices and tools. Instead, automation creates even more stringent demands for management visibility and control. The challenge is that traditional, manual management methods are inadequate in a programmable, automated network environment. Human operators lose most of the visibility and control they are used to in managing complex networks.
Always-current network models and traffic load profiles are required for real-time network provisioning by the SDN controller. They are also critical for successful monitoring and management of SDN applications such as bandwidth calendaring and workload placement, as well as virtualized network functions and overlay networks. This is especially true in the WAN that has more complicated management issues than typically found in the data center.
With any SDN application, the moment the traffic hits the WAN, resources such as bandwidth become scarce. Carriers and enterprises need a way to determine whether the required resources are available. They must verify if the network can handle the traffic demands of the application without impacting other applications adversely. This requires understanding how the topology is changing and what commitments have been made in the network, so that when new requests come in via the SDN controller, network professionals can understand whether or not those can be met.
SDN presents new challenges as well. Questions abound including how many controllers should carriers have in a large WAN, where should they be placed, and what should happen if two controllers talking to the same switch give contradictory instructions? It will be crucial to mediate competing requests for network resource requests as well as set up new paths in the first place.
Historically, the availability of management tools has lagged the introduction of new technologies. Storage virtualization and server virtualization are two recent examples. SDN is no different: Most forays into SDN are being deployed as pilots in carefully controlled lab environments where there is minimal risk to the business. However, before they can be widely deployed in production environments, management tools and best practices are needed. The industry needs to adapt today’s time-tested management practices in security, monitoring, troubleshooting, capacity planning, and others to the programmable world.
Cengiz Alaettinoglu has been with Packet Design since its founding in 2003, and as CTO provides the technical direction for the company’s product portfolio. He is currently developing a prototype of a network access broker, which will verify if SDNs can handle the path requirements and traffic demands of applications without impacting other applications adversely. Prior to Packet Design, he was with the University of Southern California’s Information Sciences Institute where he worked on the Routing Arbiter project. He was co-chair of the Internet Engineering Task Force (IETF) Routing Policy System Working Group. He has published widely and lectured at industry technical conferences and workshops. Alaettinoglu holds a B.S. in Computer Engineering from Middle East Technical University, Ankara, and a M.S. and Ph.D. in Computer Science from the University of Maryland. Follow Packet Design on Twitter @PacketDesign.
