If there is a profit-per-bit problem, how much of it could SD-WAN solve? How much could SDN or NFV solve? What are the fundamental attributes of a strategy to address profit-per-bit, and where can we expect to see features to fulfill the potential? These are all critical questions at a time when operators are struggling with the issue of ROI on infrastructure investments, meaning capex. They matter to operators, of course, but they also matter to the SDN and SD-WAN vendors.
The overlay-network space revolves around sales, like everything else. For SDN and SD-WAN, sales success depends on sales to network operators and cloud providers, not to end users or even MSPs. For SD-WAN, in particular, focusing on that market is going to require some convulsive changes in positioning and features. If anyone finds a profit-per-bit hook, they’re way ahead of the pack.
For operators and even users, overlay technology could also be critical. It frees user services from a direct protocol relationship with transport/access infrastructure. That can allow services to federate across multiple providers and even technologies, which is the current most-common mission for SD-WAN. It can provide a different model of logical connectivity, support the integration of new features (the universal CPE or uCPE model). It’s an easy new revenue source for network operators, and a defense against technology complexity at the service level complicating management of infrastructure. It could be huuuuuuuge, if it works.
Let’s start with what I don’t think will work, at least not in a practical timeframe. I do not believe that SDN (in the form of OpenFlow white-box switching/routing) or NFV in any form can have any meaningful impact on network operator capex overall, certainly not fast enough to stave off profit-per-bit pressure over the next five years. I think operator comments quoted by networking websites and my own conversations with operators are totally consistent with that view.
What I think might help, if it’s done right, is adoption of a variant SDN/SD-WAN model based on overlay technology. This would have the effect of creating a service layer that’s transport-independent, and that would create three specific benefits in the fight to improve operator profit per bit.
The first benefit would be taking infrastructure out of the service-feature business. All overlay technology relies on an “agent element” that forms the new service edge. This element can construct an interface to the user, add in features that might otherwise be supplied by additional appliances, and simplify the features actually used in infrastructure-network devices. Think, for example, of an “MPLS router” that does only MPLS ad nothing else, or packet-optical pipes.
All of that would combine to facilitate the paring down of complexity and cost, both capex and opex, for network infrastructure. New “services” could be built by augmenting only the service layer. There’s less risk of constant service changes to infrastructure, less risk that network operations would have to adapt to different features in the network, and less risk of updates creating instability.
The corollary benefit to this is that any infrastructure transport service or combination of services that offer basic connectivity and required QoS/SLA could be used. A service overlay can overlay today’s IP, today’s Ethernet, emerging OpenFlow SDN (to the extent it emerges, wherever it emerges), the MEF’s “third network” model, anything built on the P4 flow-programming protocol, etc. As long as different network technologies had some mechanism to gateway across the differences (which could be offered at the service level, of course), anything goes.
The biggest value this brings is the ability to exploit the present equipment and at the same time facilitate the introduction of new stuff. There are no fork-lift upgrades, because the service layer glosses over everything underneath. The biggest problem that “transformational” technologies have is that you have to deploy a lot of a given technology to gain a benefit, and that increases both premature asset displacement and technology risk. No such risk with the overlay.
The next benefit is that service overlays introduce a great place to make management and test and measurement connections. You can get end-to-end information easily with a service overlay, and you have a convenient set of places to connect management tools and probes for detailed analysis and even test data injection. One of the paradigms of SLA enforcement is that there has to be a place where provider and user come together on what’s being seen/experienced. The service edge is the only logical place that can happen.
You can do management of transport services at a transport demarcation point, of course, including one inside a service-layer termination. But you can also health-check other features. For IP services, for example, you need at the minimum a gateway, DNS, and DHCP to create connectivity. It’s easy, if those features are projected to or provided by a service-layer element, to validate their health. If the service layer does dynamic QoS measurements for transport selection, that’s easy to leverage, and if it’s session-aware you may be able to get dynamic packet loss data. Obviously, you can also do protocol analysis and test data injection.
This should be making service overlays a hot button, and in fact they sort-of are. The qualifier is needed because the products that offer overlay service-layer capability divide into two families that are typically directed at missions only peripheral to these mainstream issues. SDN in overlay form is more common in data centers, and SD-WAN is most often used simply to unify connectivity in enterprises where VPN services are either impractical or unavailable in some sites.
What’s needed to get things moving are a vision of the mission I’m describing, and movement toward exposing some specific APIs from service-edge elements to facilitate the development of ecosystems that support and exploit service-edge deployments. These are far more important than defining transport interfaces in developing momentum and new service-layer features quickly.
For service-layer technology targeted for network operator deployment, one of the API sets should facilitate integration between the service and transport layers, as an option. All providers of service layer technology won’t have the option to integrate with transport, either because they’re not incumbent network operators or because regulatory issues constrain the integration. Where it’s available, though, it could be a powerful incentive for network operators to adopt a service overlay model, because it would differentiate their offering from that of third parties.
In the short term, management APIs and features will be the primary requirement to help meet profit-per-bit goals for operators. The APIs have to expose the state of the service, of each connected site, and each connecting transport resource. They should also be wrapped in policy management to control the nature of information that can be viewed/changed according to role, since operators may want a deeper management view for their own personnel if they sell the service.
In the longer term, logical networking features will be the primary requirement. The cloud, containers, virtualization, and componentization of applications are combining to create a whole new model of connectivity, a model that direct IP network features can’t address easily. Overlay technology could address all these new requirements easily, and for vendors getting something very strong in this area should be viewed as a co-equal requirement to the management features.
Right now, SDN and SD-WAN vendors have a roughly equal shot at the feature space; SDN players generally have better management and may also have better integration with transport resources, but SD-WAN players tend to have better logical-network support. Both classes of vendor are about equally represented in operator plans for service-layer deployment at present, so it’s fair to say that there’s no convincing leader in the overlay space. That’s likely to change, even this year, as both operators and potential service buyers do more planning and understand their requirements better. It’s going to make for an interesting fall, in particular.