Wednesday, November 4, 2015

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.


No comments: