Standards approach or Open Source?

Extracted from SDN / NFV in wireless networks.

[...] Over the last few years, wireless networks have started to adopt enterprise technologies and trends. One of these trends is the open source collaborative model, where, instead of creating a set of documents to standardize a technology and leave vendors to implement their interpretation, a collective of vendors, operators and independent developers create source code that can be augmented by all participants.

Originally started with the Linux operating system, the open source development model allows anyone to contribute, use, and modify source code that has been released by the community for free.

The idea is that a meritocratic model emerges, where feature development and overall technology direction are the result of the community’s interest. Developer and companies gain influence by contributing, in the form of source code, blueprints, documentation, code review and bug fixes.

This model has proven beneficial in many case for the creation of large software environments ranging from operating system (Linux), HTTP servers (Apache) or big data (Hadoop) that have been adapted by many vendors and operators for their benefit.

The model provides the capacity for the creation and adoption of new technologies without having necessarily a large in-house developer group in a cost effective manner.

On the other hand, many companies find that the best-effort collaborative environment is not necessarily the most efficient model when the group of contributors come from very different background and business verticals.

While generic server operating system, database technology or HTTP servers have progressed rapidly and efficiently from the open source model, it is mostly due to the fact that these are building block elements designed to do only a fairly limited set of things.

SDN and NFV are fairly early in their development for mobile networks but one can already see that the level of complexity and specificity of the mobile environment does not lend itself easily to the adoption of generic IT technology without heavy customization.

In 2016, open source has become a very trendy buzzword in wireless but the reality shows that the ecosystem is still trying to understand and harness the model for its purposes. Wireless network operators have been used to collaborating in fairly rigid and orthodox environments such as ETSI and 3GPP. These standardization bodies have been derided lately as slow and creating sets of documentations that were ineffective but they have been responsible for the roll out of 4 generations of wireless networks and the interoperability of billions of devices, in hundreds of networks with thousands of vendors.

Open source is seen by many as a means to accelerate technology invention with its rapid iteration process and its low documentation footprint. Additionally, it produces actual code, that is pre tested and integrated, leaving little space for ambiguity as to its intent or performance. It creates a very handy level playing field to start building new products and services.

The problem, though is that many operators and vendors still treat open source in wireless as they did the standards, expecting a handful of contributing companies to do the heavy lifting of the strategy, design and coding and placing change requests and reviews after the fact. This strategy is unlikely to succeed, though. The companies and developers involved in open source coding are in for their benefit. Of course they are glad to contribute to a greater ecosystem by creating a common denominator layer of functional capabilities, but they are busy in parallel augmenting the mainline code with their customization and enhancements to market their products and services.

One of the additional issues with open source in wireless for SDN and NFV is that there is actually very little that is designed specifically for wireless. SDN, OpenStack, VMWare, OpenFlow… are mostly defined for general IT and you are more likely to find an insurance a bank or a media company at OpenStack forums than a wireless operator. The consequence is that while network operators can benefit from implementation of SDN or OpenStack in their wireless networks, the technology has not been designed for telco grade applicability and the chance of it evolving this way are slim without a critical mass of wireless oriented contributors. Huawei, ALU, Ericsson are all very present in these forums and are indeed contributing greatly but I would not rely on them too heavily to introduce the features necessary to ensure vendor agnosticism...

The point here is that being only a customer of open source code is not going to result in the creation of any added value without actual development. Mobile network operators and vendors that are on the fence regarding open source movements need to understand that this is not a spectator sport and active involvement is necessary if they want to derive differentiation over time.

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-NFV in wireless 2015/2016 is released

As previously announced, I have been working on my new report "SDN-NFV in wireless 2015/2016" and I happy to announce its release.

The report features primary and secondary research on the state of SDN and NFV standards and open source, together with an analysis of the most advanced network operators and solutions vendors in the space.

You can download the table of contents here.

Released September 2015
130 pages

• Operators strategy and deployments review: AT&T, China Unicom, Deutsche Telekom, EE, Telecom Italy, Telefonica, ...

• Vendors strategy and roadmap review: Affirmed networks, ALU, Cisco, Ericsson, F5, HP, Huawei, Intel, Juniper, Oracle, Red Hat...

• Drivers for SDN and NFV in telecom networks 
• Public, private, hybrid, specialized clouds 
• Review of SDN and NFV standards and open source initiatives
• SDN 
• Service chaining
• Apache CloudStack, Microsoft Cloud OS, Red Hat, Citrix CloudPlatform, OpenStack, VMWare vCloud, 
• SDN controllers (OpenDaylight, ONOS) 
• SDN protocols (OpenFlow, NETCONF, ForCES, YANG...)
• NFV 
• ETSI ISG NFV 
• OPNFV 
• OpenMANO 
• NFVRG 
• MEF LSO 
• Hypervisors: VMWare vs. KVM, vs Containers
• How does it all fit together? 
• Core and RAN networks NFV roadmap

Terms and conditions: message me at patrick.lopez@coreanalysis.ca

The orchestrator conundrum in SDN and NFV

We have seen over the last year a flurry of activity around orchestration in SDN and NFV. As I have written about here and here, orchestration is a key element and will likely make or break SDN and NFV success in wireless.

A common mistake associated with orchestration is that it covers the same elements or objectives in SDN and NFV. It is a great issue, because while SDN orchestration is about resource and infrastructure management, NFV should be about service management. There is admittedly a level of overlap, particularly if you define services as both network and customer sets of rules and policies.

To simplify, here we'll say that SDN orchestration is about resource allocation, virtual, physical and mixed infrastructure auditing, insurance and management, while NFV's is about creating rules for traffic and service instantiation based on subscriber, media, origin, destination, etc...

The two orchestration models are complementary (it is harder to create and manage services if you do not have visibility / understanding of available resources and conversely, it can be more efficient to manage resource knowing what services run on them) but not necessarily well integrated. A bevy of standards and open source organizations (ETSI ISG NFV, OPNFV, MEF, Openstack, Opendaylight...) are busy trying to map one with another which is no easy task. SDN orchestration is well defined in term of its purview, less so in term of implementation, but a few models are available to experiment on. NFV is in its infancy, still defining what the elements of service orchestration are, their proposed interfaces with the infrastructure and the VNF and generally speaking how to create a model for service instantiation and management.

For those who have followed this blog and my clients who have attended my SDN and NFV in wireless workshop, it is well known that the management and orchestration (MANO) area is under intense scrutiny from many operators and vendors alike.

Increasingly, infrastructure vendors who are seeing the commoditization of their cash cow understand that the brain of tomorrow's network will be in MANO.
Think of MANO as the network's app store. It controls which apps (VNFs) are instantiated, what level of resource is necessary to manage them and stitch (service chaining) VNF together to create services.
The problem, is that MANO is not yet defined by ETSI, so anyone who wants to orchestrate VNFs today either is building its own or is stuck with the handful of vendors who are providing MANO-like engine. Since MANO is ill-defined, the integration requires a certain level of proprietary effort. Vendors will say that it is all based on open interfaces, but the reality is that there is no mechanism in the standard today for a VNF to declare its capabilities, its needs and its intent, so a MANO integration requires some level of abstraction or deep fine tuning,
As a result, MANO can become very sticky if deployed in an operator network. The VNFs can come and go and vendors can be swapped at will, but the MANO has the potential to be a great anchor point.
It is not a surprise therefore to see vendors investing heavily in this field or acquiring the capabilities:

• Cisco acquired TailF in 2014
• Ciena acquired Cyan this year
• Cenx received 12,5m$ in funding this year...

At the same time, Telefonica has launched an open source collaborative effort called openMANO to stimulate the industry and reduce risks of verticalization of infrastructure / MANO vendors.

For more information on how SDN and NFV are implemented in wireless networks, vendors and operators strategies, look here.

Announcing SDN / NFV in wireless 2015

On the heels of my presentation at the NFV world congress in San Diego this spring, my presentation and panels at LTE world summit on network visualization and my anticipated participation at SDN & OpenFlow world Summit in the fall, I am happy to announce production for "SDN / NFV in wireless networks 2015".

This report, to be released in September, will feature my review of the progress of SDN and NFV as technologies transitioning from PoC to commercial trials and limited deployments in wireless networks.

The report provides a step by step strategy for introducing SDN and NFV in your product and services development.

• Drivers for SDN and NFV in telecom networks 
• Public, private, hybrid, specialized clouds 
• Review of SDN and NFV standards and open source initiatives
• SDN 
• Service chaining
• Apache CloudStack, Microsoft Cloud OS, Red Hat, Citrix CloudPlatform, OpenStack,  VMWare vCloud, 
• SDN controllers (OpenDaylight, ONOS) 
• SDN protocols (OpenFlow, NETCONF, ForCES, YANG...)
• NFV 
• ETSI ISG NFV 
• OPNFV 
• OpenMANO 
• NFVRG 
• MEF LSO 
• Hypervisors: VMWare vs. KVM, vs Containers
• How does it all fit together? 
• Core and RAN networks NFV roadmap
• Operators strategy and deployments review: AT&T, China Unicom, Deutsche Telekom, EE, Telecom Italy, Telefonica, Verizon...
• Vendors strategy and roadmap review: Affirmed networks, ALU, Cisco, Ericsson, F5, HP, Huawei, Intel, Juniper, Oracle, Red Hat... 

Can't wait for the report? Want more in-depth and personalized training? A 5 hours workshop and strategy session is available now to answer your specific questions and help you chart your product and services roadmap, while understanding your competitors' strategy and progress.

NFV world congress: thoughts on OPNFV and MANO

I am this week in sunny San Jose, California at the NFV World Congress where I will chair Thursday the stream on Policy and orchestration - NFV management.
My latest views on SDN / NFV implementation in wireless networks are published here.

The show started today with a mini-summit on OPNFV, looking at the organization's mission, roadmap and contribution to date.

The workshop was well-attended, with over 250 seats occupied and a good number of people standing in the back. On the purpose of OPNFV, it feels that the organization is still trying to find its mark a little bit, hesitating between being a transmission belt between ETSI NFV and open source implementation projects and graduating to a prescriptive set of blueprints for NFV implementations in wireless networks.

If you have trouble following, you are not the only one. I am quite confused myself. I thought OpenStack had a mandate to create source code for managing cloud network infrastructure and that NFV was looking at managing service in a virtualized fashion, which could sit on premises, clouds and hybrid environments. While NFV does not produce code, why do we need OPNFV for that?

Admittedly, the organization is not necessarily deterministic in its roadmap, but rather works on what its members feel is needed. As a result, it has decided that its first release, code-named ARNO will be supporting KVM as hypervisor environment and will feature an OpenStack architecture underpinned by an OpenDaylight-based SDN controller. ARNO should be released "this spring" and is limited in its scope as a first attempt to provide an example of a carrier-grade ETSI NFV-based source code for managing a SDN infrastructure. Right now, ARNO is focused on VIM (Virtual Infrastructure Management), and since the full MANO is not yet standardized and it is felt it is too big a chunk to look at for a first release, it will be part of a later requirement phase. The organization is advocating pushing requirements and bug resolution upstream (read to other open source communities) to make the whole SDN / NFV more "carrier-grade".

This is where, in my mind the reasoning breaks down. There is a contradiction in terms and intent here. On one hand, OPNFV advocates that there should not be separate branches within implementation projects such as OpenStack for instance for carrier specific requirements. Carrier-grade being the generic analogy to describe high availability, scalability and high performance. The rationale is that it could be beneficial to the whole OpenStack ecosystem. On the other hand, OPNFV seems to have been created to implement and test primarily NFV-based code for carrier environment. Why do we need OPNFV at all if we can push these requirements within OpenStack and ETSI NFV? The organization feels more like an attempt to supplement or even replace ETSI NFV by an opensource collaborative project that would be out of ETSI's hands.

More importantly, if you have been to OpenStack meeting, you know that you are probably twice as likely to meet people from the banking, insurance, media, automotive industry as from the telecommunications space. I have no doubt that theoretically, everyone would like more availability, scalability, performance, but practically, the specific needs of each enterprise segment rarely means they are willing to pay for over-engineered networks. Telco carrier-grade was born from regulatory pressure to provide a public infrastructure service, many enterprises wouldn't know what to do with the complications and constraints arising from these.

As a result, I personally have doubts for the success of the Telcos and forums such as OPNFV to influence larger groups such as OpenStack to deliver a "carrier-grade" architecture and implementation. I think that Telco operators and vendors are a little confused by open source. They essentially treat it as a standard, submitting change requests, requirements, gap analysis while not enough is done (by the operators community at least) to actually get their hands dirty and code. The examples of AT&T, Telefonica, Telecom Italia and some others are not in my mind reflective of the industry at large.

If ETSI were more effective, service orchestration in MANO would be the first agenda item, and plumbing such as VIM would be delegated to more advanced groups such as OpenStack. If a network has to become truly elastic, programmable, self reliant and agile, in a multi vendor environment, then MANO is the brain and it has to be defined and implemented by the operators themselves. Otherwise, we will see Huawei, Nokialcatelucent, Ericsson, HP and others become effectively the app store of the networks (last I checked, it did not work very well for operators when Apple and Android took control of that value chain...). Vendors have no real incentive to make orchestration open and to fulfill the vendor agnostic vision of NFV.

Report from SDN / NFV shows part I

Wow! last week was a busy week for everything SDN / NFV, particularly in wireless. My in-depth analysis of the segment is captured in my report. Here are a few thoughts on the last news.

First, as is now almost traditional, a third white paper was released by network operators on Network Functions Virtualizations. Notably, the original group of 13 who co-wrote the first manifesto that spurred the creation of ETSI ISG NFV has now grown to 30. The Industry Specification Group now counts 235 companies (including yours truly) and has seen 25 Proof of Concepts initiated. In short the white paper announces another 2 year term of effort beyond the initial timeframe. This new phase will focus on multi-vendor orchestration operability, and integration with legacy OSS/BSS functions.

MANO (orchestration) remains a point of contention and many start to recognise the growing threat and opportunity the function represents. Some operators (like Telefonica) seem actually to have reached the same conclusions as I in this blog and are starting to look deeply into what implementing MANO means for the ecosystem.

I will go today a step further. I believe that MANO in NFV has the potential to evolve the same way as the app stores in wireless. It is probably an apt comparison. Both are used to safekeep, reference, inventory, manage the propagation and lifecycle of software instances.

In both cases, the referencing of the apps/VNF  is a manual process, with arbitrary rules that can lead to dominant position if not caught early. It would be relatively easy, in this nascent market to have an orchestrator integrate as many VNFs as possible, with some "extensions" to lock-in this segment like Apple and Google did with mobiles.

I know, "Open" is the new "Organic", but for me, there is a clear need to maybe create an open source MANO project, lets call it "OpenHand"?

You can view below a mash-up of the presentations I gave at the show last week and the SDN & NFV USA in Dallas the week before below.



More notes on these past few weeks soon. Stay tuned.

NFV & SDN part III: mobile video

I have spent the last couple of months with some of the most brilliant technologists and strategists working on the latest networking technologies, standards and code.

Cloud, SDN, NFV, OpenStack, network virtualization, opendaylight, orchestration...

Everyone looks at making networks more programmable, agile, elastic, intelligent. Some of the sought benefits are faster time to market for new services, lower cost of operation, new revenue from new services, simpler network operation and service orchestration... This is very much about making IT more flexible and cost efficient.

Telcos, wireless vendors and operators are gravitating towards these organizations, hoping to benefit from these progress and implement them in wireless networks.

Here is what I don't quite get:

Mobile is the fastest growing ICT in the world (30% CAGR). Video is the largest (>50% of data volume) and fastest growing service in mobile (75% CAGR). 

Little, if any, of the working groups or organizations I have followed so far have dedicated telco (let alone wireless) working groups and none seem to address the need for next generation video delivery networks.

I am not half as smart as many of the engineers, technologist and strategist contributing to these organizations so I am missing something. Granted, in most cases, these efforts are fairly recent, maybe they haven't gotten to video services yet? It strikes me, though that no one speaks of creating better mobile video networks.

If wireless video is the largest, fastest growing consumer service in the world, shouldn't we, as an industry, look at improving it? A week doesn't go by where a study shows that wireless video streaming demand is increasing and that quality of experience is insufficient.

I am afraid that, as an industry, we are confusing means and goals. Creating better generic networks, using more generic hardware, interfaces and protocols to reduce costs of operation and simplify administration is a noble ambition, but it does not in itself guarantee cost reduction and even less new services. What I have seen so far are more complex network topology with layer upon layer of hierarchical abstraction sure to keep specialized vendors busy and rich for the decades to come.

In parallel, we are seeing opposite moves made by the like of Google, Netflix, Apple, or Facebook. When it comes to launching new services, it doesn't feel that these companies are looking first at network architecture, costs savings, service orchestration, interfaces... I am sure that it gets addressed at some point in the process, but it looks like it starts with the customer. What is the value proposition, what is the service, what is the experience, how will it be charged, who will pay...

Comparing these two processes might be unfair, I agree, but if you are a mobile network operator today, shouldn't you focus your energy on what is the largest and fastest growing service on your network, which happens to not be profitable? 
85% of the video traffic is OTT and you get little revenue from that. You are struggling to deliver an acceptable video quality for a service that is growing and uses already the majority of your resources and you have no plan to improve it. 
Why aren't we looking as an industry at creating a better wireless video network? Start from there and look at what could be the best architecture, interfaces, protocols... I bet the result could be different from our current endeavors. 
None of the above mentioned technology have been designed specifically for video. Of course it is generic networking, so video can be part of it, but I doubt it will be able to deliver the best mobile video experience if not baked-in at the design and architectural phase. Then, if these are not the venue for it, what is?

I am not advocating against SDN, NFV, OpenStack, etc... but I would hope that sooner rather than later, wireless and video specific focus are brought to bear in these organisations. It wouldn't feel right if we found out down the line that we created a great networking framework that is great for IT enterprise but not so good for the most important consumer service. Just saying...