Author: CIMI

We’re a long way from the scheduled end of the ETSI NFV ISG’s work, but the initiative is already spawning implementations and perhaps a tad of NFV-washing.  We have two more NFV-related announcements to talk about today, in fact.  One represents the “mainstream” of NFV activity among vendors and the other represents a second orchestration implementation.

Any NFV implementation ultimately needs virtual functions to deploy, and in theory pretty much any current network software, embedded or hosted, could be made into a virtual function.  The level of work needed would depend on just how much the NFV platform expected its deployable functions to participate in deployment and management processes.  Procera, a member of the ISG, has announced “NFV” virtualization of its policy control and DPI software.

Virtual PacketLogic platforms are cloud-hosted versions of custom policy elements in a variety of network applications to control traffic flows based on traffic type, subscriber, etc.  I’ve long believed that in the two-tier SDN model I see as the future, policy control is a valuable coupler between the upper connectivity layer and the bottom traffic-handling layer.  It’s very possible that Procera’s software-based approach would facilitate that kind of integration, though there’s nothing in the release to offer specific insight into that point.

There’s no question that the Procera approach is virtual, or that it’s cloud-ready, but it may be a bit early to say that it’s NFV.  The problem is that it’s not yet clear what being “NFV-ready” would mean.  The ISG has not fully defined the requirements for hosted virtual functions, and in particular the NFV platform services that they’d be expected to use.  It’s not clear whether multiple copies of the Procera stuff could be created ad hoc for scale-out, and how traffic could be shared among them.  It’s also not clear whether this logic could be composed into end-to-end services or share with existing IMS components, since the ISG has not yet defined exactly how a service that deploys once for multiple uses (like all the IMS elements for example) would be treated versus one that deployed per-user (like managed firewall).

Despite the fact that we can’t prove that Procera is really NFV, we can’t prove it isn’t either, and it still proves some valuable points.  First, it shows that there will be a source of useful virtual functions to be deployed when NFV implementations are available.  That’s critical because without them there’s no business case for NFV.  Second, it shows that many of those involved in NFV implementation are thinking cloud when they think of the infrastructure to be used.  I’ve said all along that the implementation of NFV is facilitated by presuming a cloud management system sits between iron and NFV.  Third, it shows that the NFV process has game, that it is considered an asset to brand something as being compatible with NFV.  Commercial forces will sustain momentum for any effort that gets enough good publicity to become a marketing platform for vendors.  Eventually they have to implement it, and improve their implementation, to retain access to the bully pulpit that NFV represents.

What I’d like to see from players like Procera is a complete re-architecting of the “old” notions of policy control, content delivery, and other mobile/metro services.  As I’ve said before, it makes no sense to take a flexible technology and stake it to the ground by replicating the exact devices we’re replacing.

For my other NFV announcement, I turn to Amartus Software Defined Service Orchestration (SDS).  Amartus is focusing not on the virtual functions but on network service orchestration, which makes it a bit more like CloudBand.  However, comparisons between SDS and CloudBand make it clear that there are going to be a lot of different approaches to the ETSI NFV process.

Amartus is different from CloudBand first and foremost because it’s not focused on virtual functions at all, it’s focused on the automated provisioning and lifecycle management of business network services.  CloudBand is about hosting functions in the cloud and SDS doesn’t host functions at all.  Amartus is also about service modeling and the conversion of those models into end-to-end services, where CloudBand is more about the deployment of virtual functions and relies on higher-layer OSS/BSS processes to model and create/connect end-to-end services.

There’s a lot to like about the Amartus approach, particularly the notion of creating a set of abstract service models that are instantiated by linking them to an API.  It seems to me that this concept could be fairly easily extended to drive a cloud management API set and deploy virtual functions, which would make Amartus into a real NFV architecture.  Amartus also integrates classical FCAPS management into their architecture and models, which is at least congruent with how I think NFV management has to work, but it’s not integrated with hosted service features because Amartus doesn’t host them.  Finally, Amartus doesn’t at this point model consumer or “infrastructure” services, though I don’t see why they couldn’t make changes to do that too.

Overall, Amartus hasn’t gone the last mile in creating NFV integration, which means that they are tantalizingly close to being a true NFV orchestration package but not yet there.  The company was not in the NFV ISG when I looked yesterday, but they indicated they were in the process of joining it.  I’d suggest they do that and then look at how they could add in the seemingly minimal elements needed to make SDS into NFV SDS.

What Amartus shows, in addition to the value of NFV association, is that there are many products out there that could be pressed into service as a foundation for NFV deployment and management.  I’d welcome as many approaches from as many different directions as we can get, because if this NFV stuff is to be made to work we need as much hard experience and real-world deployment as we can get to pick the best options.  NFV’s stated goals of cost savings can be met only if we optimize implementation, and the value of NFV as the future platform for cloud service operationalization is even more delicately balanced on the edge of implementation efficiency.  We have to get this right, and every test and trial helps.

There are always two components to any software-based solution to a problem—the software that implements the solution and the platform that software runs on.  It’s not uncommon for us to take the latter for granted, but in the world of virtualization that’s a big mistake.  For SDN and NFV in particular, platforms are really important stuff.

Servers are where virtualization starts, of course, and everyone knows that things like the total memory available and the number of cores/processors will impact the performance of systems, but it’s more complicated than that.  The availability of a complex system is reduced when you add components unless the components are redundant and load-balanced effectively (meaning that the load balancer isn’t a single point of failure), so server reliability is actually likely to be more important for SDN/NFV.  Remember, those atomic appliances were engineered for higher availability, and so you may actually lose uptime if you pick a cheap server to host the equivalent function on.

Another thing about servers that transitions us into software is the input/output.  Most commercial servers are optimized for disk I/O for the good reason that disk systems are typically critical in the performance of the applications they run.  SDN and NFV may use storage for images and parameters but in general will be pushing their I/O through network connections.  Network data path performance is fairly sad on a typical system; you need to be sure that you have optimized adapters but also that you have optimized software for the data path.

A recent article in SDNCentral about software data path acceleration firm 6WIND has a pretty good explanation of why network I/O needs path optimization in SDN and NFV applications; http://www.sdncentral.com/education/6wind-nfv-interview-2013/2013/08/.  Virtual switching and routing, even when used outside SDN/NFV, is also going to benefit significantly from data path acceleration, to the point where operators tell me that some of their virtual switch/router applications aren’t going to make the business case without it.

Hypervisors and Linux are two other big factors in efficient virtual-function or virtual-network applications.  Users report some pretty significant differences in hypervisor performance, and with both hypervisors and Linux there may be issues with the support of the installed platforms since many of the products are open-source.  Most operators say they expect to get their open-source tools from vendors who will offer support contracts, and many want the software and hardware pre-integrated to insure that there’s no finger-pointing.

Data center networking is also very important in virtual-function/network applications.  I’ve been working pretty hard on the architecture of NFV applications, for example, and it’s clear that one attribute of these applications is that not only are there more horizontal traffic paths in a typical application than you’d find in a commercial business application, they are much higher in speed.  Less than 20% of commercial data centers get any significant benefit from horizontally optimizing switching in the data center, and even for the cloud the number isn’t much more than 25%, but my model says that virtual-function hosting would require better (fewer-hop) horizontal performance in over 75% of cases.

In SDN and NFV, I also think that the metro connectivity is part of the “platform”.  Operators tell me that eventually NFV would involve deploying at least mini-data-centers everywhere they had real estate, meaning in every CO and many depot facilities as well.  In the US, for example, we could end up with between 14,000 and 35,000 of these data centers, and future services would be composed by linking virtual functions and application components across data center boundaries.  That means that those data centers will have to be networked very efficiently, at a high level of performance and availability, to insure that operations costs or QoS/availability problems don’t explode.

From a management perspective, you can see this is a bit of a brave new world too.  In a network of real devices, you have today what’s typically an adaptive system that fixes itself to the greatest possible degree.  Yes you have to “manage” it in the sense of sending a tech out to replace or repair something, but it’s a different management mission than would be needed to sustain a system of virtual functions.  Where you put them in the first place matters, and there’s a bunch of connecting tissue (the network paths) that stitch a virtual device together, and each of these have to be managed.  That means that we may have to rethink the notion of autonomous processes for service remediation, and we’ll darn sure have to think hard about how we even find out the status of a virtual-based service.

The final question for all of this platform stuff is, as I suggested in my opening, the functionality that runs on it.  What exactly has to be done to write virtual components of services?  Is a service cloud close to an IaaS service in that it has little more than operating system and basic OS-related middleware, or does it also include APIs to manipulate the environment, manage components, etc?  Is it like Azure for services, a PaaS?  If the answer is the latter, then we have no virtual functions out there today and we’ll have to write or rewrite to create them.  For that to work, we’d need some standards for the platform APIs, or no development would be portable among platforms and we’d have chaos in trying to put pieces of services together.  But if a virtual-function system is based on standard software, how do we add in the NFV-specific or SDN-specific elements needed to organize and manage services?

The cloud, SDN, and NFV are fusions of network and IT.  Most vendors don’t cover the full range of products needed to build this new model, and so not surprisingly most of them are dissecting it to pick out what they can sell.  The problem is that we’ve not done much of a job of putting the system together in the first place, so the dissection is breaking down the ecosystem into disconnected pieces.  Whatever is different about the network of the future versus that of the present, both of them will still rely on connected pieces.

 

One of the primary design goals of CloudNFV was to create a viable management framework for networks composed in whole or in part from virtual or cloud-hosted functions.  Along the way we needed to deal with another of our principles; that the cloud, SDN, and NFV had to be united into a single concept.  While management in this new world of virtual resources, virtual services, and virtual everything (except perhaps for payments!) isn’t easy, I think that picking the right approach is helpful.

One primary principle of virtual management is that you can’t let virtual functions poll real resources for management information.  The IETF’s i2aex project has the right idea; there has to be a repository between resources and applications that need management data to decouple the two.  Otherwise the growth in virtual functions creates an exploding load on devices and the network just to exchange control telemetry.  In recent conferences, operators were already reporting an explosion in management traffic; it can’t get worse if we hope to reduce network costs with NFV.

A second primary principle is that while you want to be able to support legacy management practices in an evolution to virtual functions, SDN, and the cloud, you don’t want to constrain modern virtual-cloud environments by tying them to device-oriented management systems.  I had a meeting with a Tier One recently, and two people sitting right next to each other had diametrically opposed views of whether traditional OSS/BSS frameworks had to be supported, or had to be discarded!  Both are right in some situations, so you have to support both.

The third principle is that virtual management is all about context.  Real devices have real, fixed, relationships both with each other and with services.  Virtual devices can’t have real relationships at all, so you have to be able to create a framework for management using the same principles of virtualization that you applied to services.  If it’s convenient for you to manage the network like it’s one enormous god-box device, so be it.  If you want to manage it as virtual devices that map closely to previous real devices, that’s your call.  Whatever you pick, though, the same resource status has to feed your view.  You can’t mold real resources to suit virtual management dimensions.

In CloudNFV, we started off by saying that the context of all management is services.  This management stuff is all being done so operators can sell something credible to consumers or enterprises, and so we have to reflect everything back to that context from the first.  We structured our service model from top to bottom based on the TMF GB922 Services hierarchy, part of the Frameworx/SID model.  To accommodate NFV and cloud principles, we added NFV-based elements at the “bottom” of the Service hierarchy, and we also added virtual-cloud-driven connectivity to the entire hierarchy so that cloud principles could deploy and connect elements of services—whether virtual or real.

To get resource data, CloudNFV has a concept we call Active Resource, which is an unstructured semantically overlaid repository of everything we know about any resource in the infrastructure.  Things we call “Visualizers” take traditional management interfaces and MIBs and reflect them into Active Resource.  There are no restrictions on either the source or nature of the data collected.  Anything that can feed a Visualizer can contribute management state, and management state is stored and correlated in real time so any view of it is always up-to-date and in the format you expect, regardless of what you expect or how the information was collected to begin with.

But this doesn’t provide full context, so we’ve done even more.  A virtual function or software application either has a management interface of its own (in which case we can connect to it through a Visualizer) or it is comprised of components that have a collective, systemized, management view.  So we associate a Management Visualizer with each layer of the GB922 hierarchy, so that any time you group a bunch of devices or virtual functions or even combinations of the two into a cooperative system, you define how that system is supposed to appear in a management sense.  And because you can browse up and down one of those GB922 service hierarchies from retail service to virtual function and back, you can also browse through the management views in a similar way.

Another way that context is critical is in management of hybrid services.  If a word processor is included in a unified communications and collaboration service, do we manage it as a cloud application and manage the rest of the service as a network service?  Hardly.  The fact that our word processor is part of UC/UCC means it’s a carrier service and should be managed as one.  Put that same word processor in a SaaS application, though, and it’s a cloud application, managed as software would be.  That’s context-sensitive management.

That’s still not enough.  Suppose you want to consider a hundred customer-specific iterations of a single set of virtual functions as one collective virtual device?  We build VPNs not by deploying sets of customer-specific routers, but by inducing customer-specific behavior from a system of shared routers.  So we can, with CloudNFV, collect virtual functions into horizontal systems based on common elements and manage that.  And if you don’t like vertical service-based management or horizontal device-based management, we can go diagonal for you too (if you can figure out what that means!)  Any view of resource/service relationships that creates efficient operations processes is fine—in fact, they’re all just different designs on the same coin to us.

When you ask CloudNFV whether a given service is meeting its SLA, what CloudNFV does is drill down through the GB922 layers, viewing the Management Virtualizers along the way.  Each one of these presents a virtual MIB that has elements whose values are set by the relationships of real resource states in the network and data centers.  A virtual firewall’s state might be the sum of the state of the VM it’s hosted on, the data center network it runs in, and the WAN connectivity that links it to the user and to the network.  All that’s defined in the Visualizer, and if you want a different management derivation you just change the rules.  Same for presentation; a GUI based on HTML or a management API are just different presentation formats to CloudNFV.

This structure also allows CloudNFV to offer what could be called “management services” including configuration and reconfiguration.  “Daemon” processes can use Visualizers to check the state of services, resources, etc. and activate management processes in response to the conditions they find.  That means that you can use congestion at a given virtual function level to invoke management processes to spawn more copies of something and load-balance them—what the NFV ISG calls “horizontal scaling”.  If applications can detect the need for scale-out or scale-back internally, they can also use a management services API to invoke this process themselves.

“Federation” or pan-provider services are important to both service providers and users, and so CloudNFV management is inherently federation-ready.  Services are composed using either a provider’s own assets or assets made available by partners, and can span multiple networks.  We support federation at the cloud infrastructure level (one provider hosts all service logic and deployment tools and uses IaaS services from other providers) up to the service level (partners provide wholesale service components that can be integrated into retail services as needed).  To provide controlled management visibility, federation partners are linked through a Federation Connector, which is a form of Visualizer that allows for management interaction only on the components of a federated service where providers have agreed to visibility.

A final point on CloudNFV management is that it’s based on totally scalable, fault-tolerant-distributed-cloud technology itself.  Resources, whether data storage or processing, can be added dynamically and the logic is all distributed-state-based to allow for both fail-over and scale-in/out.  CloudNFV management can even expand itself if needed using its own principles, to scale as necessary to support uniform, cloud-ready, NFV and cloud service management using a completely open and extensible platform.

Everyone agrees that management of virtual resources of any sort is a complicated problem.  Because SDN, NFV, and the cloud are all based on a slightly different vision of virtualization, they create a compound challenge for planners who know the three must be one at some point.  We’ve tried to face that challenge head-on, and to define an architecture that anticipates the multi-dimensional challenges of virtualization.  We think that’s the only way to address them effectively.

 

Remember the concept of NGN—the “Next-Generation Network?”  Some people think the Internet is it, but the Internet is a service and not really a network.  Some think that it was accomplished by IP convergence, but if that’s true then what’s all the fuss about SDN and NFV about?  So are we anywhere near the NGN concept, and how would we know if we were moving there?  Maybe the best way to find out is to look not at what NGN is, but to start at least with what it isn’t.

It isn’t OSI.  The OSI model was first articulated in 1974, and anyone who thinks that technical visionaries could anticipate 40 years of network evolution back then is delusional.  We had a world where economies of scale in terms of bandwidth were prodigious because practically everything was terminal-to-host.  Applications used bandwidth at such a low duty cycle that it was routine to oversubscribe trunks by 500%.  A T3 trunk cost over $9000 per month in just access charges.  Now we have video streaming on the demand side and flattened bandwidth/cost curves on the supply side that can make the notion of aggregation to more efficient trunking levels seem simplistic.  The network of old tried to structure services in layers, and that made sense given the price/cost pictures of the time.  Today, every layer is a big hit on Opex that can likely never be made up in capex.

Flattening the OSI layers has been a watchword for a decade, maybe even a generation.  If you look at the SDN story objectively, you can see that a big part of the value proposition could be based on the notion that service connectivity can be overlaid on anything that provides for path meshing.  Build Level 3 on top of Level 1.  Or maybe build Level 4 that way.  With every layer you eliminate you eliminate a level of complexity that raises management costs, and thus raises TCO.

This is why I’m a cynic with respect to SDN thinking, why NGN isn’t SDN either.  We can argue that software-defined networking is networking that’s responsive to software needs, and that’s very reasonable.  It’s also something very evolutionary; we can make current networks more software-controllable.  We can define software-defined networking as the replacement of Level 3 architectures based on adaptive per-device behavior with one based on centrally managed behavior.  That’s something more revolutionary but we’re taking new-generation network thinking and applying it to recreating what we had all along, which isn’t much of a “next generation” to me.

SDN in pure form is about contextless forwarding.  You simply tell a device to do this or that with packets and screw OSI layers or other traditional models.  You don’t necessarily even have to base forwarding on traditional concepts of addressing, you only need to say that for any given packet, identified by some unique set of header information, you know a forwarding rule that gets it along its path to the destination.

NGN has to be able to embrace this kind of thinking.  Services are a combination of connectivity and features.  SDN provides the connectivity and the cloud and NFV concepts provide the features.  We should be able to build both on optics and one layer of electrical handling, and we should be able to declare that the way that connectivity and features mix is totally under the control of some great service-arbiter up in the sky…or in the cloud.  Ethernet and IP are just systemic collections of forwarding rules and adaptive behavior.  NGN should be able to embrace them of course—you can’t destroy the past to prepare for the future.  But NGN should be able to overcome them too, to create a set of service rules that build in all the things that we have to add on in today’s networks.  Otherwise it’s not NGN at all, it’s the same old generation with a face lift.

I think one of the opportunities—the greatest perhaps—that the NFV ISG has today is the opportunity to reshape NGN.  Obviously NFV can define the features of the NGN in a cloud-friendly way.  Less obviously, it can define the way that services relate to features.  When a cloud application is built, it’s necessary to create not only component instances for the software to run, it’s necessary to create the connection framework.  Does NFV simply embrace the strategies of old?  Or does it redefine the notion of services and connectivity itself, to move beyond both current infrastructure models and new cloud models into something that’s both….and more?

Software defines networking if it can break the barriers of the old protocol and service models.  If all we do with SDN, with NFV, is to replicate the tired old crap we’ve been using since the OSI days, why are we calling this the “next-generation network?”  We are stuck in intellectual neutral here.  Yes, we have to have user-network interfaces that look like IP and Ethernet, but inside the black box of the network we now have the technology and the insight to create something totally new, a black box that has external properties that are familiar and that has internal properties that are revolutionary.

This is our challenge.  This is what our generation, as opposed to the generations past, have to seize.  Yes, the Internet and IP were revolutionary but revolutions don’t stop with the first rush to the barricades.  We have to carry on from those visionaries, even the ones who invented OSI, and not simply accept the paradigms they created when the world was a very different place than it is today.  Can we do that?  The answer to that question will determine whether there’s really an NGN—or just the Old-Generation Network with a new do.

I was finally able to fit in a briefing by Alcatel-Lucent on their CloudBand ecosystem and NFV strategy (not because they were unwilling but because of mutual scheduling issues).  The briefing was very helpful in conveying what Alcatel-Lucent is really doing in NFV and the cloud, and it also illustrates the positioning challenges vendors face in this new world of virtualization.

CloudBand is a two-level process—Nodes that run resources like VMs and storage and the CloudBand Management System which is the functional heart of the process.  Pretty much anything that can run OpenStack or CloudStack can be used as a node.  Functionally, CloudBand operates as a work distributor that makes hosting and connection decisions based on policy, acting through the cloud management APIs (Nova and Neutrino in the case of OpenStack).  Unlike “vanilla” OpenStack, CloudBand can apply policies to make decisions based on security, affinities in location, load, etc.  All of this is a very cloud-friendly process.  There’s a strong focus on application lifecycle management (ALM) and Chef or Puppet DevOps scripts can be imported to use as provisioning frameworks.

Virtual functions are deployed using “Recipes” that define what some cloud tools call “packages” of deployable components and instructions for their connection.  It’s these Recipes that can set policies and determine how specific components are instantiated and then connected.  The Nuage SDN technology Alcatel-Lucent previously announced creates an agile connection framework for the collection of nodes and functions, and Alcatel-Lucent’s previously announced Nuage-related links between SDN and infrastructure would apply to facilitate traffic management.

CloudBand supports federation at the IaaS level; as long as OpenStack or CloudStack APIs are available you could deploy across a large community of data centers.  I think that it would be possible to connect even things that didn’t run Nuage, but it might require some customization of Neutron plugins.  I happen to like Nuage’s capabilities so it would make sense to assume that a CloudBand deployment was a Nuage deployment, but clearly federation might change that.

The CloudBand Ecosystem is a developer program that’s designed to create an NFV-friendly test and deployment framework for virtual functions. Developers of virtual function logic are obviously constrained in terms of testing in the real world, and the Alcatel-Lucent program gives them an opportunity to test across a community of providers.  It would be a small step from this to providing a complete pan-provider repository for virtual function logic and also to provide for pan-provider services based on developer-program virtual functions.  Nobody talked about resurrecting the old Application Exposure Suite or Open API Program but there are clearly some similarities in terms of objectives.

There’s a clear dualism between NFV and the cloud here.  CloudBand is an implementation of NFV (as much as anyone would be able to do that given the early state of the definitions from the ISG), and it stays pretty close to the structural mission of the ISG itself in that it’s about cloud-hosting virtual functions rather than about creating end-to-end services.  Alcatel-Lucent indicated that they expect to run under a service management process to accomplish that.  NFV management practices have not been defined in detail at this point so we can’t really compare what Alcatel-Lucent does with NFV specifications.  It does appear that they have the ability to both “self-manage” inside NFV-defined functional black boxes, or reflect management state at a composite level.  The latter would likely be the responsibility of the developer, at least to a degree.

Developers can build fairly generic virtual functions, potentially even using generic cloud-ready code, and I think that most cloud software components could be composed into hybrid software/virtual-function services as well.  This seems logical given that Alcatel-Lucent says that some operators are using CloudBand to deploy cloud computing services, and it’s a dualism that I think is essential for the credibility of NFV.  We can’t be inventing a new virtualization-driven infrastructure for every new mission, after all.

This is a pretty credible NFV framework in my view, and since it comes from a major network vendor it’s one that’s going to be taken seriously.  My spring survey results showed that only two vendors were credited with having a useful NFV platform in play, and Alcatel-Lucent was one of them.  The only problem with the survey as a guide here is that nothing was available from anyone at the start of the survey period and some operators may have gotten a view of other vendor platforms after they’d already turned in their responses.  The fall survey should provide a better guide on how operators see CloudBand and also how Alcatel-Lucent’s competitors respond and are perceived.

As far as I can determine, there are now about seven NFV platforms at some state of development/deployment, and all of the major network vendors are said to have an NFV strategy that they’re shopping around.  Ericsson’s is said to be fairly OSS/BSS-centric (no surprise given Telcordia’s acquisition), but I’ve not heard much about the other approaches.  The one to watch is Cisco, of course, given that they have considerable server assets and thus direct cloud credibility.  Cisco is in fact the only major network vendor who could actually make a boatload of money on NFV deployment, given that the main impact of NFV will be to explode the number of carrier data centers as hosted functions gain adoption.

How much of an explosion could NFV create?  Here’s my model’s answer.  Between 2013 and 2018, an optimum NFV architecture could create an increase in operator spending on data center equipment of over $25 billion per year. By 2018, NFV will impact nearly 60% of all operator network equipment purchase decisions. By 2020, an optimum NFV architecture could add so many operator NFV data centers that it would double the global number of data centers.

The operative word here is “optimum” of course.  It’s very difficult at this point to assess just what an optimum architecture would be, and even harder to tell if a given NFV solution fits the mold given that articulation of the strategies (including Alcatel-Lucent’s) is still rather lightweight.  I think that this will sort out, though, because the NFV ISG is making it very clear that the operators are serious about creating an NFV solution, and the fact that there are already examples of NFV implementation means vendors are taking them seriously.

 

Yesterday I blogged a bit about mobile video and mobile viewing behavior, and today I want to follow up with some commentary and data on the fixed-line side of OTT video.  The industry data shows convincingly that channelized consumption of video isn’t dropping even for fixed-line customers, but my own modeling and research shows that’s not necessarily the case.  You have to look deeper to get the real situation, and you have to look at households rather than people.

You can divide households into three primary groups; those with children living at home, those where young adults are independently living without children, and those where children have grown up and moved away.  My data continues to show that the viewing habits of two of those three groups has remained fairly constant; you can likely guess that it’s the independent adults who represent the force of change.  The fact that this group is the smallest of all is part of the reason why industry viewing data doesn’t show a significant behavioral shift.

If you look at the independent adults group (unmarried, married and childless, group living) you find that this group consumes about five times the quantity of OTT video that the rest of the groups do, to the point where it actually exceeds their channelized viewing.  However, most of this is consumed while the people are away from home.  While at home, they consume somewhat more OTT than the other groups, but not a lot more.  They do, however, consume a lot less channelized TV, and this is the group that provides most of the cord-cutters.  Why?  The viewing data shows that this group watches primarily sporting events and late-night TV.  They are in their social prime-of-life and their entertainment activities are focused on “going out”.  They were never much for TV to begin with, and so their own viewing habits haven’t changed much either—which is the other part of why industry data doesn’t show a change.

If we dig a little deeper into this, we find what I think is the interesting stuff.  The independent adults group, when they watch something other than sporting events, etc. tend to watch a potpourri of documentaries, movies, and other shows.  About a quarter of their viewing is stimulated by social referral, the same process that drives them to share links to YouTube videos during the day or even when out at a social gathering.  The remainder is essentially ad hoc diversion, and here we find something interesting.  Since 2008, there has been a steady slippage in the number of viewing hours spent on channelized material in this ad-hoc viewing category.  This year, my model says that this group will watch as much full-length material in ad-hoc episodes as they watch channelized material.  Since people with children in the household watch more TV and there are more of them, this little shift in ad-hoc independent adult viewing hasn’t been noticed much.

The issue for this group is the “nothing-on” problem.  Remember that ad hoc viewing is to fill a specific time slot, a whim.  That generates two problems for the viewer; first that the whim may not come at an hour boundary and so channelized material isn’t aligned with their period of interest.  Second, the material in a given time period is what it is; if you aren’t planning viewing ahead of time you have to accept what you find—or go to OTT.

TV provider VoD doesn’t answer the question of “what’s on” for this group either.  Most VoD users are either supporting child entertainment or catching up on shows they usually watch and have missed.  The independent adult group doesn’t have scheduled viewing except for sports, and most say they are less interested in watching a game non-real-time because they know the outcome.  So this is where watching a movie on Amazon or Hulu or Netflix comes in.

Another interesting point about this independent adult group and its ad hoc viewing is that they say the biggest problem they have isn’t the material itself but finding it.  Nearly all say that they don’t like the channel guides their TV provider offers for VoD because it’s hard to find something.  If you want a TV show you need either to know the network it’s on or find it through laborious keypad manipulation.  This group is therefore the group that wants integration of phones/tablets with TV—not to pick a channel but to find videos on demand.

They’re also the group that drives the integration of the Internet and TV, the group who Apple and Google target with their TV offerings.  Because this group gets a big chunk of their viewing time on mobile devices, and in terms of number if discrete videos watched gets most of it that way, they’re accustomed to online navigation and browsing for things on their gadgets.  For them, the ideal would be to simply “switch” the video to the big screen when they were near one (which, sadly for them, violates the licensing rules of most video distribution agreements).  The tech-savvy among them are virtually the only people who set up their TV as the external monitor of a computer so they can navigate to videos without restrictions.

There’s more, though.  In families with children, the consumption of OTT video increases when the children reach about age 10 (because they get their own appliances).  What’s happening here is that the kids are in their rooms or on the deck or even in the living room with a headset watching their own thing.  This drives up OTT consumption, but doesn’t drive down channelized viewing because the household still has other members “watching TV”.  It’s for this reason that cable companies see the congestion created by OTT as a greater threat to their business model than the cord-cutting.  People aren’t really cord-cutting in any significant numbers, and likely won’t be even as far out as 2020 when my model runs out of steam.  But they are very likely to keep increasing OTT use, and that means that the return on infrastructure is lower because per-user consumption of capacity is higher.

So there we have it.  OTT video is a threat, but not to the revenue side.  It’s a problem for return on infrastructure, and ROI in that sense is already in deep brown.  This is the problem that the real NGN will eventually have to solve; the problem that what most think is the “NGN”—the Internet—has created.

We all know the old song, “Video killed the radio star.”  The question now is whether something is killing or at least wounding the video star.  The latest research on video shows, not to my personal surprise, that the impact of OTT video is primarily to increase viewing hours rather than to displace traditional channelized viewing.  What my own models have been saying is that if you let somebody watch video on a smartphone or tablet, the portability of the platform opens video-view entertainment options that did not previously exist, and guess what?  People take advantage of them.

Many would have us believe that traditional television is dead, that Apple and Google are taking over the world, video-wise.  The numbers don’t bear that out, and in fact no respectable research I’ve ever read shows anything but either consistent or even increasing channelized viewing even in the face of OTT.  This proves, obviously, that exciting news is a lot more interesting than the truth, but it also disguises some questions/issues for people who want to make money on OTT video.

People have always told the same story when asked why they’re watching an OTT video.  First reason; they’re where they can’t view a normal TV show.  Second reason; nothing is on their available channels.  Third reason; some friend sent them a link.  To understand the future of OTT video you have to address these points.

I think every generation has at some point leaned back in disgust during a session of channel-flipping and said “TV sucks anymore!”  The fact is that TV is always going to suck for some portion of the population, and in a world where youth has more manipulable spending than their elders do you can expect programming to shift in their direction.  Personally, I hate “Twitter-like” or even actual Twitter feeds superimposed onto shows.  I also hate action shows that spend half their air time developing their characters’ lives.  I have a life; I’m interested in the action.  The point is that all these likes and dislikes are personal and subjective, and producers try to walk a line of keeping every just happy enough not to switch channels.

Where OTT could help is with the cost side.  If we could produce content at a lower cost we could offer content that was more tuned to the personal whims of more classes of viewers.  That would mean OTT might be better than channelized TV in a content sense.  But even companies like Netflix are spending more acquiring content rights than developing fresh content, and so we’re not playing this quality-and-personalization card effectively.

The issue of “can’t watch where I am” is relevant because my data at least suggests that what people watch when they’re out and about tends to be either short clips suitable for viewing on the run, or something they don’t want to miss.  YouTube satisfies the first of these, but the second means getting what’s essentially live TV feeds into OTT.  Clearly that could be done even today in a technical sense, so why aren’t we doing more of it?  Because nobody wants to kill the advertising revenue stream.  If a major sporting event were to support live feeds to portable devices they might lose a ton of money because online ads earn less than TV ads per viewer-minute.  Why?  Because they’re less effective at manipulating purchasing, and that’s because mobile users are more distracted (hopefully) by their surroundings and tune out the ads more effectively.  Not only that, we’re all being conditioned to tune out online ads by being bombarded with them.  Clearly we need more research on how to engage somebody with in-content mobile advertising.

That leaves our last point, the issue of link-sending or “viral video”.  People send others YouTube clips almost a hundred times as often as any other video link according to my numbers.  Why?  Because you probably don’t have to watch for an hour to see what’s interesting.  When you share a link with others you are injecting your thoughts into their context, and unless they can quickly sync with your mindset they’ll not be able to appreciate what you send.  The obvious conclusion is that we need to have accurate metadata indexing of material and also have a way to send a link that includes positioning data on videos if we want to take advantage of viral properties for normal TV or movie video content.  Again this shouldn’t be rocket science at a technical level, but neither of these are common and we’re making particularly poor progress with metadata scene coding, even where it would be easy to use the script to develop it.

So why are we doing badly at promoting a video model we all seem to think is the next big thing?  I think there are a number of reasons.  First and foremost, you don’t dig up all your wheat to plant corn if you’re depending on a crop in the near term.  The transition from a channelized to an OTT-driven video model could well trash the economics of content production, and we have to figure out a way to produce shows profitably or it won’t matter what viewing technology we can support.  Second, you have to develop a video deployment model that’s very agile in terms of viewing support, ad insertion, social-media integration, and even customization of the “overlay” concepts like Tweets.  Right now, we tend to always go for the lowest common denominator approach, and that’s encouraged everyone to sell the platforms short.  We have Internet-integrated TVs now, and most STBs could likely overlay Tweets on screens.  Why then are we sticking content many think are distracting on every screen?

Content is the least-realized of all the operator monetization goals.  Its projects are delayed, its technology is muddled, its proponents at the planning level are losing political credibility.  If we can’t fix the framework of OTT, if we can’t fit it into all the entertainment niches in a profitable way, we’re going to be either watching new reality shows or “I Love Lucy” reruns forever.

Alcatel-Lucent’s quarter was far from happy, but there were still happy signs in a small increase in revenues and continued improvement in margins.  The sales of IP products were also good, and all of this seems to indicate that the “Shift” plan the company outlined (and whose restructuring costs killed the bottom line this quarter) has a chance of success.  The question, of course, is whether that indication is real.

One thing that the Shift recognized is that there are too many low-margin things hanging around the bottom line.  About two-thirds of the company’s revenues come from what would be considered commodity or commoditizing products, and even the IP and mobile space are under margin pressure.  Some of this stuff is likely never going to see the high-margin light of day again, and the fact is that Alcatel-Lucent needs to shed that part of its business ASAP.  They will lose on price to Huawei every time, and where features can’t be made meaningful price competition is inevitable.  And even cutting stuff that needs to be cut won’t make the rest a safe haven.

It would seem logical that the service layer of the network is where Alcatel-Lucent would look for the value pot of gold, and in fact no company has done as much to build a coherent technical strategy in services.  Their strength in mobile ecosystems and content delivery give them two of the three monetization pillars operators are looking for, and that’s more than many of their competitors have.  Arch-rival Juniper, for example, has no convincing strength in any of the three.  I think that you can argue that Alcatel-Lucent’s technical coherence has been totally dissipated by an almost complete lack of effective articulation, but there’s also the matter of that missing monetization pillar—which happens to be the cloud.

Of all the monetization project categories operators generally recognize, cloud computing is the run-away winner.  Cloud monetization projects have advanced to trial-or-later in about 50% more cases than any other monetization project type, and content or mobile monetization projects that involve the cloud move faster and further than those that don’t.  In the cloud, Alcatel-Lucent has a problem because it has no servers, which market-leader Cisco has and is winning deals with.  What Alcatel-Lucent needs to do is to create a software-driven vision of the cloud and make it compelling.

CloudBand is obviously an attempt to do that.  Their Nuage SDN position is a good one (one of the best, perhaps even the best), and a marriage of the two would be a helpful thing for carrier-flavored cloud computing.  Alcatel-Lucent has just launched an NFV ecosystem inside CloudBand that could have great promise, but there isn’t much information available on it and that’s not the foundation for a compelling position.

I have to wonder whether there’s not a little of Bell Labs paranoia creeping in here.  Remember that Bell Labs is an innovation giant, even if sometimes it seems a lot of the scientists are studying where their laps go when they stand up.  With what is arguably their most politically powerful internal constituency aimed at creating intellectual property, could it be that Alcatel-Lucent is so afraid of having their thunder stolen by others (perhaps Huawei?) that they keep everything under wraps?  It’s hard to get buyers to purchase things you won’t describe.  At any rate, I’ve got a discussion scheduled on CloudBand, and it will be interesting to see how much gets revealed and what its impact might be.

Meanwhile, there is an important truth that Alcatel-Lucent needs to consider, cloud-wise.  I’ll call it the “commutative property of cloud”.  If I host virtual functions as cloud components, and if I host SaaS application components as cloud components, and if I can deploy and manage them with the same tools, then are they not the same thing?  And if SaaS and NFV are really the same under the skin, could it be that CloudBand’s NFV processes are actually steps toward a rational position for Alcatel-Lucent in cloud computing?  Remember that my CloudNFV initiative has always had the goal of supporting NFV and SaaS equally in both deployment and management/operations.  It’s possible to do that with the right approach.

Sprint also released numbers, and their subscriber losses are truly appalling.  Mobile services are a game for giants, and as soon as you lose the advantage of scale you fall into that murky category of being too big to be specialized and too small to be interesting to the masses.  Sprint, clearly, has a lot to gain from a stronger cost-and-services balance, and just as clearly something like a complete carrier cloud story would be helpful to them.  Inside, though, they seem to have some of the same challenges that Alcatel-Lucent has.  They need a big, bold, vision of the future and not just a mechanism for slowing the bleeding.  Cloud-based mobile/behavioral symbiosis would be the best, even the ideal, answer, but mobile monetization has the lowest rate of advance to trial-or-later of any of the three monetization classes.  This, despite the fact that it now has the highest priority and the highest level of “potential” revenue gain according to operators.

Sprint is considering the future.  Alcatel-Lucent is considering the future.  Both have to realize that the future is the cloud, for a bunch of reasons.  Huawei isn’t strong there.  Feature differentiation is good there.  Cisco is threatening to seize it, so everyone needs to get their turf staked out.  Operators are deploying cloud even where cloud computing isn’t the focus.  It’s a concept that cuts across the operator Tiers and the market geographies.  So the message for both Alcatel-Lucent and Sprint?  Think cloud before it’s too late.

 

My research has been showing a relatively slow uptake rate on SDN and NFV, slower than many would like to believe, and I thought it would be helpful to understand why the model I use is predicting a slow ramp rather than the classic “analyst report” hockey stick adoption.  The truth is often less interesting than fiction, but no less true for that fact!  Surveys of both enterprises and network operators for more than two decades have showed me that there are three factors that influence the rate of adoption of a new technology.

One is the functional availability of the technology—can you actually buy it in a form where it delivers the promised benefits.  In most cases, our “revolutionary” technologies take years to achieve reasonably full functional availability, and yet we expect to see buyers jumping in when product changes year over year would alone jeopardize a buyer decision.

The second factor is buyer literacy.  We don’t expect everyone who buys a car to be an automotive engineer, but we should expect them to be able to frame the basic value proposition for purchase successfully.  A network technology buyer has to understand the cost/benefit equation sufficiently to make the business case or they can’t get anything approved.

The third factor is management validation; will senior management accept that a new technology is in fact ready for prime time and take what is always an objective risk by committing to deploy it?  In most cases, I’ve found, management validation comes about because of effective coverage of something in the media.

The challenge with both SDN and NFV is that none of these areas have reached critical mass.  Only the “distributed” model of SDN where network adaptive behavior is sustained but better harnessed to conform to software goals do we have the required level of functionality available before 2016.  That means that buyers with typical breadths of application needs won’t be able to meet them with the state of the products at the time of sale; they’d be betting on futures.  My model says that the big jumps in functional availability will come between 2016 and 2017.  In SDN buyer literacy, critical mass has been reached for all operators but won’t be reached for enterprises until 2018.  In management validation, operators can expect to have the necessary socialization of technology for SDN in 2014, but enterprises won’t see it until 2016.  With NFV, only Tier One and Two operators will achieve necessary levels of literacy by 2018, and functional availability and management validation will come in 2017.

You might wonder why this takes so long, and the primary reason comes from what my survey has always called buyer influences.  What influences a buyer the most?  For the whole lifetime of my surveys, the number one factor has been the experience of a trusted peer.  At the beginning of the surveys, the second-most-cited influence was the material published in a primary technology publication—Datamation, BCR, Network Magazine.  Two of the three no longer exist, and today media rates seventh on the list of influential factors even counting online material.  What’s worse is that the gap of influence between the top and second choices in influence has widened.  Today, the primary network vendor has less than half the influence of a trusted peer where 20 years ago they had 85% the influence.  Every influence factor except our trusted peers has dipped by at least a third in 20 years, which says that buyers have virtually nobody to trust these days.

In some ways, this should make things ripe for startups, but the fact is that it doesn’t.  Small vendors won’t spend the money to engage correctly through marketing channels.  When we ask buyers about the quality of website material and marketing material, nobody gets great scores but the major vendors to twice as well as the smaller ones.  When there are trade groups or forums created to mass up the little guys, the bigger guys join them and seize control, or buck them with their own marketing.

We have, according to my spring survey, no consensus buyer definition of what an SDN is, no specific understanding of what technology choices would be ideal to implement NFV.  We have in the case of SDN many different products but the products don’t aim at the same issues, don’t address the same opportunities, don’t afford the same benefits.  How then do we justify them?  In the case of NFV we might be 18 months away from a firm standard; what happens between now and then, and how does a buyer make a pre-standard decision (if they can find one) with confidence it won’t be obsolete a year later?

I am confident that there are sustainable SDN value propositions that could justify spending today at twice or more the levels that we’ll see.  I am confident that it will be possible to actually deploy NFV next year and gain even more benefits than the NFV ISG even targeted in their white paper.  I’m just not confident the buyers will know.

We have posted the following on the proof-of-concept mailing list for the ETSI NFV ISG, offering our participation in the NFV body’s work in this area and offering integration with other NFV members.  We invite parties interested in integrating with us to review our preliminary guidelines on our website, http://www.cloudnfv.com/ and also to apply to join the CloudNFV Group on LinkedIn.  We will approve the Join requests when the group opens up, which we now expect will be in August.

CIMI Corporation will be submitting three POC proposals for consideration, based on the CloudNFV platform created by seven member companies in the NFV.  CloudNFV is an NFV implementation built for OpenStack.  A formal POC proposal document will be contributed in August, but we will propose a three-phase POC because of the scope of the issues we hope to explore.

The first proposal is aimed at validating the data modeling of NFV processes from the retail service level down to the virtual function level.  We want to validate the information needed to describe a virtual function, deploy it, connect it with other functions, and connect the combination with live network equipment and user endpoints.  We will, in this phase, establish the requirements to deploy, run, and manage VNFs and aggregations of VNFs deployed as services or service components.  We expect that this POC proposal will be available for demonstration and review in September, and we will contribute the results.

The second proposal targets the actual deployment and management of VNFs on conforming infrastructure.  In this POC we seek to validate the links between NFV and OSS/BSS/NMS frameworks, based on our TMF GB922-compatible service model.  We also seek to validate our architecture for federating NFV at the cloud infrastructure level upward to the retail service level, and to confirm the structure needed for cross-management and settlement.

The third proposal targets deployment of retail end-to-end services and traffic management in a completely federated, global, NFV-compliant network.  In this POC we seek to identify the operational challenges of global-scale federated NFV infrastructure and to establish the parameters of the management model needed for things like horizontal scaling, availability and QoS guarantees, transitioning from legacy devices to virtual functions, and integration of virtual-function services with cloud SaaS.

We will be publishing guidelines for integrating with CloudNFV in August, and at that point we will consider proposals from NFV member companies to integrate with us by providing virtual functions to host, network and server/system technology on which to run both our platforms and functions, and management and deployment tools to explore further optimizations in this area.