World's first ETSI NFV Plugfest

As all know in the telecom industry, the transition from standard to implementation can be painful, as vendors and operators translate technical requirements and specifications into code. There are always room for interpretation and desires to innovate or differentiate that can lead to integration issues. Open source initiatives have been able to provide viable source code for implementation of elements and interfaces and they are a great starting point. The specific vendors and operators’ implementations still need to be validated and it is necessary to test that integration needs are minimal.

Networks Function Virtualization (NFV) is an ETSI standard that is a crucial element of telecom networks evolution as operators are looking at their necessary transformation to accommodate the hyper growth resulting from video services moving to online and mobile.

As a member of the organization’s steering committee, I am happy to announce that the 5G open lab 5Tonic will be hosting the world’s first ETSI NFV plugfest from January 23 to February 3, 2017 with the technical support of Telefonica and IMDEA Networks Institute.  

5Tonic is opening its doors to the NFV community, comprising network operators, vendors and open source collaboration initiatives to assert and compare their implementations of Virtual Network Functions (VNFs), NFV Infrastructure and Virtual Infrastructure Manager. Additionally, implementations of Management and Orchestrations (MANO) functions will also be available.

43 companies and organizations have registered to make this event the largest in NFV interoperability in the world.

Companies:

•           Telefonica

•           A10

•           Cisco

•           Canonical

•           EANTC

•           EHU

•           Ensemble

•           Ericsson

•           F5

•           Fortinet

•           Fraunhofer

•           HPE

•           Huawei

•           Inritsu

•           Intel

•           Italtel

•           Ixia

•           Keynetic

•           Lenovo

•           Mahindra

•           Openet

•           Palo Alto

•           Radware

•           RIFT.io

•           Sandvine

•           Sonus

•           Spirent

•           RedHat

•           VMWare

•           WIND

Open source projects:

•           OSM (Open Source MANO)

•           Open Baton

•           Open-O

•           OPNFV

 OSM is delivering an open source MANO stack aligned with ETSI NFV Information Models. As an operator-led community, OSM is offering a production-quality open source MANO stack that meets the requirements of commercial NFV networks.

Testing will take place on site at the 5TONIC lab near Madrid, as well as virtually for remote participants.

NFV costs expectation gap

I am fresh off from an interesting week in sunny San Jose, at the NFV World Congress, where I chaired the operations stream on the first day.

As usual, it is a week where operators and vendors jostle to show off their progress since last year and highlight the challenges ahead. before I speak about the new and cool developments in terms of stateless VNFs, open source orchestration, containers, kubernetes and unikernels, I felt the need to share some observations regarding diverging expectations from traditional telecoms vendors, VNF vendors, systems integrators and operators.

While a large part of the presentations showed a renewed focus on operations in NFV, a picture started to emerge in my mind in terms of expectations between vendors, systems integrators and operators at the show.

Hardware
Essentially, everyone expects that the hardware bill for a virtualized network will reduce, due to the transition to x86 hardware. While this transition might mean less efficiency in the short term, all players seem to think that it will resolve itself over the next few years. In the meantime, DPDK and SR-IOV are used to address the performance gap between virtualization and traditional appliance, even at the cost of agility. By my estimate, the hardware cost reduction demonstrated by VNF vendors and systems integrators still falls short of operators expectations. Current figure places them around a 30% cost reduction vs. traditional model, whereas operators' expectations hover between 50 to 66%.

Software
This is an area where we see sharp expectations variations between all actors in the value chain.
VNF vendors expect to be able to somehow capture some of the hardware savings and translate them into additional license fees. This thinking is boosted by the need for internal business case to transition from appliance to software, to virtualized and eventually to orchestrated VNF. We are still very early in the market and software licensing models for VNFs are all over the place, in many case simply translated from the appliance model in other cases built from scratch but with little understanding of he value of specific functions in the overall service chain. Increased competition and market entering from non-traditional telco vendors will level the licensing structure over time.

Systems integrators are increasingly looking at VNFs as disposable. Operators tell them that they want to be able to have little dependency on vendors and to replace VNFs and vendors as needed, even running different vendors for the same function in different settings or slices. Systems integrator are buying into the rationale and are privileging their own VNFs, putting emphasis (and price premium) on their NFVI (infrastructure) and VNFM (management). Of course this leads also to the conclusion that while VNFs (and VNF vendors) should be interchangeable, the NFV MANO (management and orchestration) function will be very sticky and will likely stay a single vendor proposition in a given network. As a result, some are predicted the era of orchestrators war, which certainly feels timely, after the SDN management war (winner OpenStack), southbound interface war (winner OpenFlow), hypervisor war winner (KVM)...
I have spoken at length about the danger operators expose themselves if they vacate the orchestration field and leave systems integrators to rule it. It seems to have gained some traction with open source orchestration projects being pushed in standards. In any case, VNF vendors expect a growth in software licensing vs. appliance model, whereas integrators and operators expect a reduction.

Professional services
This is the area where everyone sees to agrees that an increase is inevitable. SDN and NFV provide layers upon layers of abstraction and while standards and open source are not fully defined, there is much integration and "enhancements" necessary to make a service on NFV work.
VNF vendors and operators who do not want to perform integration themselves usually expect a 50% increase vs. appliance projects, whereas integrators budget a robust 100% increase in average. This, of course, increases even further if the integrator is managing the infrastructure / service itself.

Maintenance and support
Vendors and integrators expect the ratio of these to be essentially comparable  to appliance models, whereas operators expect a sharp reduction, in light of all professional services being extended for integration and automation.

Total
VNF vendors behind closed doors will usually admit that, in the short term, the cost of rolling out a new VNF function /service might be a little higher than appliance, due to the performance gap and increase in professional services. There are sharp variations between traditional vendors that are porting their solutions to NFV and new vendors that cloud-native and have designed their solution for a software defined virtualized environment.
Systems integrator can show an overall cost reduction but usually because of proprietary "enhancements and optimization".
All are confident, though that automation and orchestration makes operation of existing services much cheaper and ramping up of new ones much faster. Expectations are that VNF architecture will be much more cost effective than appliance on a 3 to 5 years TCO model. Operators, on their end expect a NFV architecture to yield savings from day one, compared to appliance and to further increase this gap over a 3 years period.

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.

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.