Despite the industry focus over the past year being predominantly around the transformation of networks through virtualization (SDN and NFV), one of the primary challenges facing network operators today that can be solved with software-control has nothing to do with virtualization but rather something far less exciting; service automation and orchestration.
Today network operators provision services piece-meal across their networks, one hop or node at a time, without end-to-end visibility or coordination. Adding yet another dimension of complexity is that often times different network layers are operationally siloed. This makes it impossible for an operator to make path computation decisions across a multi-layer service offering. This is the first great use case that can test out SDN in carrier networks.
So how do network operators solve this? Especially in an environment where most large network operators are challenged by issues such as network size, the number of vendors in the network, and incomplete inventory systems.
These problems are solvable. For instance, as an industry, we have figured out how to put several billion transistors on a 2” x 2” footprint (1.9 billion to be exact, on an Intel Xeon MP series CPU) and we know exactly how every transistor is connected to every other. It stands to reason that we should be able to figure out how to manage networks that have tens or hundreds of thousands of elements.
I spend a lot of time with network operators of all shapes and sizes. Each one is different and yet they are all striving for better network efficiencies; they want to use their networks more intelligently. There is urgency – perhaps that is why SDN has received so much attention. SDN promises to make networks easier to use, turn them into a resource pool, and make them programmable. This in turn takes knowledge; knowledge about the network topology, knowledge about the inventory and state, and knowledge about the network layers and their relationships. When equipped with this meta-data about a network, a controller can help reap the promise of SDN.
This brings me back to service automation and orchestration. Once an SDN controller understands the network and can make intelligent service orchestration decisions for that network, programming the network is a mechanical exercise and whether one uses CLI or TL1 or OpenFlow or NETCONF/YANG models is really of little consequence. Being able to provision across multiple vendors or multiple-interface types isn’t in-and-of-itself a service-orchestration solution nor is it SDN– it’s just Google Translate for CLI.
There are various service-orchestration approaches being proposed; most solutions are advocating a translation layer and some solutions even place a requirement on the network-element to expose specific data-models (YANG for example). These solutions provide a shim-layer providing an abstraction between an OSS and the network-element, but do nothing to help an operator use a network more intelligently. They are essentially scripting solutions, not SDN controllers. That difference should not be understated.
A controller, by definition, understands the network, the topology, the connectivity and the state and intelligently orchestrates services leveraging all of that intelligence. A scripting engine automates service-orchestration, but the heavy-lifting (service design, capacity management, inventory management) has to be done prior to service provisioning.
Using YANG data-models can help with abstraction of network and service layers, but these approaches actually discourage openness since they mask the true complexity of the underlying vertically integrated solutions. Though a shim-layer may provide an operator some interim relief for provisioning across multi-vendor environments, it is a stretch to call it SDN or a long-term solution providing the operational benefit for which operators are longing. Why? Where is the path-computation? Where is the virtualization of the service from the network topology? Where is the multi-layer optimization? Without that intelligence, an operator is not making any better use of the networking resources, nor taking advantage of multi-layer optimization. Nor are they actually establishing a layer of software-control that is separate from the hardware.
Network operators need to expect more from their networks and their vendors. There is no reason to constrain how networks are managed today by limitations of the past. There’s no reason to try to provision a service and roll it back if it fails. WAN automation and orchestration should know if a service is going to work before it is provisioned. We should know if an SLA is going to be met because we designed the service that way. Trial and error is no way to operate networks.
The result is services that are provisioned in minutes or hours instead of months. Errors are reduced. Time to market and revenue is greatly accelerated. These are all benefits the industry can all understand.
So break through the status quo and let’s build intelligent, software-defined and orchestrated networks – because service automation, the first great use case of a software-controlled and defined network, is a problem that can, and is being solved today.