What are your intentions with my network?

Over the last few months, there has been much talk about intent rather than prescription in telecom networks connectivity and traffic management. Intent is expressing a desired outcome, whereas prescription is describing the path and actions necessary for that outcome.

For instance, in a video optimization environment, intent can be "I want all users in a cell to be able to stream video to their requested definition, but if the total demand exceeds capacity, I want all videos to downgrade until they can all be simultaneously served".

The current prescriptive model could look more like:

• Append cell ID to radius / diameter traffic
• Segregate HTTP traffic at the DPI 
• Send HTTP to web gateway
• Segregate video traffic at the web gateway
• Send video traffic to video optimization engine
• Detect if video is 
• HTTP progressive download or
• HLS or
• Adaptive bit rate or
• other
• Detect video encoding bit rate
• Measure video delivery bit rate
• Aggregate traffic per Cell ID
• If video encoding bit rate exceeds video delivery bit rate in a given cell
• Load corresponding rule from PCRF (diameter Gx interface)
• transcode if progressive download
• transrate if HLS
• Pace / throttle if Adaptive bit rate or other
• until delivery bit rate consistently exceed encoding bit rate for all streams in that cell

The problem so far is that an intent can be fairly simply expressed but can result in very complex, arduous, iterative prescriptive operations. The complexity is mostly due to the fact that there are many network elements involved in the "stream video" and "demand vs. capacity" operands of that equation and that each element can interpret differently the semantics "exceed" or "downgrade".

ETSI ISG NFV and ONF have included these topics in their workload lately and ONF presented last month at the SDN & OpenFlow world forum where I participated in a panel. ONF is trying to tackle intent-based connectivity in SDN by introducing a virtualizer on the SDN controller.

The virtualizer is a common API that abstracts network-specific elements (type of elements such as router, DPI, gateways... vendors, interface, protocol, physical or virtual...) and translates intents into a modeling language used to program the different network element for the desired outcome. That "translation" requires a flexible and sophisticated rendering engine that holds stateful view of network elements, interfaces, protocols and semantics. The SDN controller would be able to arbitrate resource allocation as it does today but with a natural language programming interface.
ONF started an open source project BOULDER to create an opensource virtualizer initially for OpenDaylight and ONOS controllers.
While this is very early, I believe that virtualizer has vocation to change the balance between network engineers and programmers in mobile networks, provided that it is implemented widely amongst vendors. No doubt, much work will be necessary, as the virtualizer's rendering of natural language towards prescriptive policies looks too much like magic at that point, but the intent is good.

This and more in my "SDN & NFV in wireless networks" report and workshop.

SDN world 2015: unikernels, compromises and orchestrated obsolescence

Last week's Layer123 SDN and OpenFlow World Congress brought its usual slew of announcements and claims.

From my perspective, I have retained a contrasted experience from the show. 

On one hand, it is clear that SDN has now transitioned from proof of concept to commercial trial, if not full commercial deployment and operators are now increasingly understanding the limits of open source initiatives such as OpenStack for carrier-grade deployments. The telling sign is the increasing number of companies specialized in OpenFlow or other protocols high performance hardware based switches.

It feels that Open vSwitch has not hit its stride, notably in term of performance and operators are left with either going open source, cost efficient but not scalable nor performing or compromising with best of breed, hardware-based, hardened switches that offer high performance and scalability but not the agility of software-based implementation yet. What is new, however, is that operators seem ready to compromise for time to market, rather than wait for a possibly more open solution that could -  or not - deliver on its promises.

On the NFV front, I feel that many vendors have been forced to lower their silly claims in term of performance, agility and elasticity. It is quite clear that many of them have been called to prove themselves in operators' labs and have failed to deliver. In many cases, vendors are able to demonstrate agility, through VM porting / positioning using either their VNFM or an orchestrator's integration, they are even, in some cases, able to show some level of elasticity with auto-scaling powered by their own EMS, and many have put out press releases with Gbps or Tbps or millions of simultaneous sessions of capacity...
... but few are able to demonstrate all three at the same time, since their performance achievement has, in many cases been relying on SR-IOV to bypass the hypervisor layer, which ties the VM to the CPU in a manner that makes agility and elasticity extremely difficult to achieve.
Operators, here again, seem bound to compromise between performance or agility if they want to accelerate their time to market.

Operators themselves came in troves to show their progress on the subject, but I felt a distinct change in tone in term of their capacity to effectively get vendors deliver on the promises of the NFV successive white papers. One issue lies flatly on the operators' attitude themselves. Many MNO are displaying unrealistic and naive expectations. They say that they are investing in NFV as a means to attain vendor independence but they are unwilling to perform any integration themselves. It is very unlikely that large Telecom Equipment Manufacturer will willingly help deconstruct their value proposition by offering commoditized, plug-and-play, open interfaced virtualized functions.

SDN and NFV integration is still dirty work. Nothing really performs at line rate without optimization, no agility, flexibility, scalability is really attained without fine tuned integration. Operators won't realize the benefits of the technology if they don't get in on the integration work themselves.

At last, what is still missing from my perspective is a service creation strategy that would make use of a virtualized network. Most network operators still mention service agility and time to market as a key driver, but when asked what they would launch if their network was fully virtualized and elastic today, they quote disappointing early examples such as virtual (!?) VPN, security or broadband on demand... timid translations of existing "services" in a virtualized world. I am not sure most of the MNOs realize their competition is not each other but Google, Netflix, Uber, Facebook and others...
By the time they launch free and unlimited voice, data and messaging services underpinned by advertising or sponsored model, it will be quite late to think of new services, even if the network is fully virtualized. It feels like MNOs are orchestrating their own obsolescence.

At last, the latest buzzwords you must have in your presentation this quarter are:
The pet and cattle analogy, 
SD WAN,
5G

...and if you haven't yet formulated a strategy with respect to containers (Dockers, etc...) don't bother, they're dead and the next big thing are unikernels. This and more in my latest report and workshop on "SDN NFV in wireless networks 2015 / 2016".