Month: June 2015

Virtual CPE (vCPE) is one of the hotter topics these days, and even though it has its roots in NFV the concept seems to be taking some tottering steps on its own.  As it does, it may be exposing some evolutionary trends that could supplement or replace aspects of the NFV value proposition, and even help us understand where services are heading.

vCPE is part of a very well-established trend toward “service-sourcing” in networks.  In the old days, businesses built networks from circuits and nodal devices—routers most recently.  As IP convergence and Carrier Ethernet matured, this model was gradually replaced by an edge-networking model, where an operator provided architected multi-site connectivity (VLANs or VPNs) and users simply attached to it at each site.  In most cases the edge devices were essentially members in the architected connectivity operators provided, and in some cases they were even “customer-located equipment” or CLE, provided by and owned by the operator but located on the premises.

The benefit of architected connectivity is that you don’t have to build a network from trunks and nodes on your own.  The value proposition for this type of service is much the same as for the cloud, so if it’s good to buy architected L2 or L3 services, then it follows it might be helpful to buy higher-layer services as well.  In many cases, users of VLANs and VPNs purchase equipment or features to add to basic L2/L3 connectivity, and it’s these devices that were among the primary targets of the early NFV work.  Why buy and install devices that add specific functionality and have to be maintained, updated, changed in and out, when you can do that virtually, as-a-service?

Generalizing service deliveries, meaning true networking-as-a-service, requires a general access model or you end up with access connections waiting for something to connect with.  Elasticity of services demands, in a realistic world, an access pipe with enough capacity and capability to terminate all the variable stuff you plan to use/sell.  Adva’s latest agile access notion, which is only vaguely NFV-ish in detail, is a good example of an agile demark.  You could in theory set up multiple L2 terminations on a trunk, a combination of L2 and L3.  This also seems compatible with Brocade’s elastic edge concept, which uses a hosted router/firewall inside the carrier cloud to serve as the L3 ramp to a simple L2 dmarc.  It’s not NFV but it might be important in exploiting what NFV can do.

Another approach that’s being touted is the “agile CPE” model, where a device that has general hosting capability is used to replace multiple special-function devices like firewalls and routers.  This could look a lot like NFV in that you could add “VNFs” to the box to add functionality, but unlike classic NFV there’s no need to host the VNFs in a cloud.  RAD, Overture, and other vendors are now offering boxes that do this.

Silver Peak just announced another slant on next-gen vCPE; their Unity EdgeConnect uses the Internet to create secure VPNs that can either augment or replace standard carrier VPNs (MPLS).  Their approach lets users employ a single access connection to support the cloud, the Internet, and VPNs.  It wouldn’t be difficult to add hosted NFV-ish features to such a model, either.

If the virtual CPE model is based on hosting at the dmarc, then it’s logical to associate it with more versatile edge devices.  Logical but maybe not necessary.  Any server with the right network card could terminate a carrier connection and be used to host connection-point or network-based functions, of course.  Given the fact that operators are looking to replace specialized network devices with servers, it seems inevitable that there’d be interest in vCPE that’s hosted on such a box at the termination point, whoever owns it.

And whoever supplies it.  If vCPE is a good idea, if higher-layer services are a good idea, then the dmarc might be very valuable real estate indeed.  There’s a lot of stuff that is best done there, either on a transient basis (like “service chaining”, where local function hosting could alleviate massive first-cost problems associated with building cloud data centers for VNFs) or permanently.  Firewalls and encryption obviously belong close to the service termination, and voice services benefit from having a local virtual IP PBX locally for intra-facility calls.  Application acceleration belongs at the dmarc too, or very close to it.  Get a good camel’s nose under the dmarc tent and there’s a lot of follow-on business you could do.

You might even have a lot of carrier partnership opportunities.  A lot of cloud services and even advanced network services could benefit from local representation, and the owner of the dmarc device might have a chance to promote deals with network/cloud providers based on their incumbency.  If the device vendor could induce the user to take a “vCPEaaS” deal, retaining ownership and management of the edge, then the opportunity could get a lot larger.

Something like this could be a boon not only to Carrier Ethernet companies who have been finding it harder to get into the NFV-and-SDN revolution, but even for consumer equipment vendors.  There’s no reason why a Level 2 service interface with multiple L3 terminations couldn’t work with any consumer broadband service model—telco or cable.  You could even envision models where a user’s mobile broadband service has multiple virtual terminations, perhaps for direct access to wearables or simply to add service features.

This is where vCPE cuts both ways, in NFV or even SDN terms.  Because vCPE could be an agent for services it could promote services by facilitating their use.  vCPE, for example, could make services “appear” at a dmarc, a trivial-sounding but essential element in getting user access to those services.  I’ve already noted that vCPE could be used as an on-ramp to NFV-type service chaining in the cloud, offering operators a way of providing VNF hosting before they have enough customers to justify cloud data centers.  But sometimes the access road is as far as you need to go.  vCPE could tap off a significant segment of early NFV opportunity if those VNFs you start hosting in vCPE stay there and never move to a carrier cloud at all.   Similarly, SDN services could be terminated in vCPE to make them easy to access, or you could use CPE to create what looked like SDN from legacy service technologies.

“Real” NFV offers broader services, greater agility, and lower mass-cost points, providing that you actually design your implementation to do all of that.  As vCPE becomes hotter, proponents of real NFV will have to pay more attention to how to differentiate their expressway from the on-ramp, rather than just promoting the notion of chaining VNFs.  And vCPE vendors may make that hard to do, if they learn their own positioning lessons in the crucible of competition.  Or maybe they’ll form a common cause.  It could be an interesting marriage, or struggle, to come.

For those who, like me, find the current NFV activity diffused and missing the point more often than not, the prospect of yet another body with their fingers in the pie stirs mixed emotions.  The New IP Agency (NIA) was launched at the Light Reading Big Telecom Event last week with (according to the group) four missions; information, communications, testing and education.  Since NIA is born out of a realistic picture of where we are with NFV, there’s hope.  Since we already have a couple dozen groups working on NFV, there’s risk NIA will simply be another of them.

On the “hope” side, there is no question that there are major problems developing with NFV.  The original mission of NFV was to reduce costs by substituting lower-cost hosting for higher-cost appliances—a capex-driven argument.  This was discounted by most operators I’d met within the first year of NFV’s existence; they said there weren’t enough savings attainable with that model versus just forcing vendors to discount their gear.  NFV’s benefit goals have shifted to opex reduction and service agility, both of which could be substantial.

The operative word is “could”, because while the goals shifted the scope of NFV’s efforts did not.  The specifications still focus on the narrow range of services where large-scale substitution of virtual functions for appliances has been made.  Since legacy equipment is outside NFV’s scope, you can’t do end-to-end orchestration or management within the specs, which means that opex efficiency and service agility are largely out of reach—in standards terms.  There is also a very limited vision of how services are modeled and managed even inside the scope of the spec, and that’s largely what contributed to the situation Light Reading called the “Orchestration zoo”.

It would be possible, in my view, to assemble a complete model for NFV that embraced end-to-end services and even organized management and operations processes.  My ExperiaSphere example shows that you could build such a thing largely from open-source elements and that it could support the ISG’s work as well as embrace TMF and OASIS cloud specifications.  The TMF has run some Catalyst demos on operations integration, and there are at least four NFV vendors whose orchestration strategies could provide enough integration breadth to capture the full benefit case.  Arguably all of these conform to standards.

Stevens once said that the “wonderful thing about standards is that there are so many of them to choose from.”  NIA doesn’t propose to write more, but I wonder whether it could even hope to do the choosing.  What it could do is to shine some light on the real problems and the real issues.

Example:  An “orchestration zoo” isn’t necessarily a disaster.  The cost of orchestration tools is hardly significant in the scope of NFV infrastructure costs.  If multiple orchestration tools delivered better benefits then they could be better than having a single standardized one.  What we can’t afford, and what NIA would have to help the industry to avoid, is either a loss of benefits or a loss of infrastructure economies.  Multiple orchestration approaches could lead to that more easily than a unified approach, but if we managed how orchestration processes related to both infrastructure and operations processes we could avoid real harm.

Example:  Service modeling is really important both in preserving benefits and preserving economies of scale in infrastructure.  A good service model both describes deployment and records results of deployment.  You need it to organize the components of a service, and to reorganize them if you have to scale horizontally under load or replace a piece.  You need a service model to start with goals—an intent model.  You need it to decompose downward in an orderly way, with each transition between modeling approaches represented by a hard service/intent-modeled boundary.  You need to end up with an abstract vision of hosting and connection services that doesn’t expose technology specifics upward to services, but models it as features across all possible implementations.  There’s been next to no discussion of service modeling, and NIA could help with that.

Example:  Current PoCs focus too much on individual services and not enough on broad opportunities or systemic infrastructure choices.  That’s because we started with the notion of use cases, which were service-based applications of NFV.  Since there was no notion of unity, only of use cases, it’s not surprising that we exploded the number of “orchestrators.”  We’re beyond that now, or should be.  A PoC can validate technology, but deployment requires we validate the totality of carrier business practices, the whole service lifecycle, and that we do so inside a universal vision of NFV that we can reuse for the next service.  NIA could help PoCs “grow up”, elevate themselves into business cases by embracing both the other horizontal pieces of a service and the vertical components of operations processes.

Where NIA could help might be easier to decide than how it could help.  We don’t know how it will be constituted, other than that LR will have at least a temporary board membership.  From the early sponsorship and support it appears likely it will have vendors involved, and also likely that it will charge for membership as bodies like the ONF do.  One thing that’s unusual and could be exploited is the notion of an explicit partnership with a publisher, and perhaps through that an analyst firm (Heavy Reading).  It’s my view that simply having good coverage, meaning objective and thorough coverage, of NFV could be helpful by putting the right issues out front in the discussions.

In my view, the critical factor in making NIA successful is whether vendors who offer SDN and NFV products see it as a path to making the business case, not just proving the technology.  Operators tell me that current PoCs don’t have the budget for deployment in the great majority of cases, and operator CFOs say that they don’t make the business case to get the budget either, at least as they’re currently constituted.  Vendors need to sell something here, not just play in the science sandbox, so they could mutually gain from efforts to elevate the mission of trials so that it includes the operations efficiency and meaningful new-service and service-agility elements.

Obviously that could be tricky.  Vendor cooperation tends to fall down at the first sign of somebody being able to drive things to a competitive advantage.  The “zoo” Light Reading describes wouldn’t be an issue if vendors were in accord with respect to how to approach NFV or SDN.  In fact, as we know, there are vendors who’d like to see both ideas fall flat on their faces.  I witnessed some sharp operator-to-vendor exchanges even in the early days of NFV as operators tried to assure that vendors wouldn’t poison the NFV well.  If NIA falls prey to that kind of behavior then there would be no consensus to drive the industry to, and likely no useful outcome.  How can it avoid it, though?  Ultimately all the industry forums are driven by whoever funds them most.

Light Reading’s participation, or that of any publication or analyst group, will also raise concerns.  Everyone wants to be a sponsor of a popular forum, after all, and the NIA charter says that the body will buy services from Light Reading for at least the first year.  How will that impact the way NIA issues are covered by other publications, or treated by other analyst firms?  Might other firms want to launch their own initiatives, or at least cast a few stones in the direction of an initiative launched by a competitor?  Light Reading has always been fair in their coverage of my own NFV-related activities and I don’t think they’d be unfair in covering NIA, but will everyone believe that?

I’ll be honest here.  If I believed that the path to SDN and NFV success was clear and that we had a good chance of getting or being on it with the initiatives underway, my skepticism would overcome my enthusiasm on NIA and I’d probably be against the notion.  The problem is that the founders, including Light Reading, are absolutely right; something is needed.  I guess that unless and until NIA proves it can’t do something positive, I’ll be supporting whatever it can do.

NFV is going to require deploying VNFs on something; the spec calls the resource pool to be used “NFV Infrastructure” or NFVI.  Obviously most NFVI is going to be data centers and servers and switches, but not all of it, and even where the expected data centers are deployed there’s the question of how many, how big, and what’s in them.  I’ve been culling through operator information on their NFV plans and come up with some insights on how they’re seeing NFVI.

First, there seem to be three primary camps in terms of NFVI specifics.  One group I’ll call the “edge-and-inward group”, another that I’ll call the “everywhere” group, and finally the “central pool” group.  At the moment most operators put themselves in the middle group, but not by a huge margin, and they’re even more evenly divided when you ask where they think they’ll be with respect to NFVI in the next couple of years.

The “edge-and-inward” group is focused primarily on virtual CPE.  About half of this group thinks that their early NFV applications will involve hosting virtual functions on customer-located equipment (CLE), carrier-owned, generalized boxes, kind of an NFVI-in-a-box approach.  This model is useful for two reasons.  First, it puts most of the chained features associated with vCPE close to the customer edge, which is where they’re expected to be.  Second, it offers costs that scale with customers—there’s no resource pool to build and then hope you can justify.

Where the “and-inward” part comes in is that at some point the customer density and service diversity associated with virtual CPE would justify hosting some features further inward.  Since this is customer and revenue driven, it doesn’t worry the operators in cost-scaling terms, and they could site small data centers in COs where there were a lot of customers and services.  Over time, these small-edge centers might then be backstopped by deeper metro centers.  In short, this model builds NFVI resources as needed.

Some of the operators in this group expect that services could eventually be offered from the deeper hosting points only, eliminating the NFVI-in-a-box CLE in favor of dumb service terminations.  The same group also notes that some functionality like DNS, DHCP and even application acceleration fit better when hosted deeper because they’re inherently multi-site services.

This is the group that has the slight edge in early deployments, meaning for the next several years.  Obviously one reason is that while NFV is waiting to prove itself out as a broadly beneficial model, you don’t want to start tossing data centers all over your real estate.  In the long run, though, operators think that NFVI-in-a-box would be a specialized piece of functionality for high-value sites and customers.  For everyone else, it’s the larger resource pool with better economies of scale that make sense.

The second group is the “everywhere” group, so named because when I asked one member of the group where they’d put NFVI, the answer was “everywhere we have real estate”.  This group expects to distribute NFV functions efficiently and widely and to have function hosting move around to suit demand and traffic trends.

Most of the operators who put themselves in this group are looking at a diverse early service target set.  Most have some virtual CPE, nearly all have mobile infrastructure as a target, and many also have content delivery and even cloud computing aspirations.  Their plan is to harmonize all of their possible hosting around a common set of elements that create a large and efficient (in capital cost and opex) resource pool.

Obviously most edge-and-inward players end up in this category unless their NFV strategies fail, and that’s why this group is the largest overall when you look at the longer-term state of infrastructure.  The group has the smallest (by a slight margin) early adherents because most operators are concerned they lack the breadth of applications/services to justify the deployment.

The central group is the smallest of the three, both in the near term and long term—but again not be a huge margin.  This group is made up of operators who have very specialized metro-centric service targets, either aspects of mobile infrastructure or large-business vCPE.  Some also have cloud computing services in place or planned.  All of them serve geographies where users are concentrated—no vast sprawling metropolis here.

The service targets for this group seem vague because they’re not particularly focused.  The sense I have is that the group believes that NFV success depends on “everywhere” and think that you should start “everywhere” somewhere other than in a bunch of NFVIs in a box out on customer sites.  Some have cloud infrastructure already, and plan to exploit that, and a few even plan to start hosting in the same data centers that currently support their operations systems.

What goes into the data centers varies as much as the data center strategies vary.  The “everywhere” group has the greatest range of possible server configurations, and the central group (not surprisingly) wants to standardize on as small a range of configurations as possible.  However, all the groups seem to agree that somewhere between 10% and 20% of servers will be specialized to a mission.  For software, Linux and VMs are the most popular choice.  VMware gets a nod mostly from centralists, and containers are seen as the emerging strategy by about a third of operators, with not much difference in perspective among the three groups.

For switching, there’s little indication in my data that operators are running out to find white-box alternatives to standard data center switching.  They do see themselves using vSwitches for connecting among VNFs but they seem to favor established vendors with more traditional products for the big iron in the data center.  “If Cisco made a white-box switch I’d be interested,” one operator joked.

Of the three groups, the edge-and-inward guys are the ones least concerned about validating the total NFV benefit case in current trials, because they have relatively little sunk cost risk.  However, the CFOs in the operators of this group are actually more concerned about the long term NFV business case than those of other groups.  Their reasoning is that their current trials won’t tell them enough to know whether NFV is really going to pay back, and if it doesn’t they could end up with a lot of little NFVI-in-a-box deployments that will gradually become too expensive to sustain.

You can probably guess who ends up with the largest number of data centers and servers—the “everywhere” group.  Given that a lot of operators start in that camp and that some at least in the other two camps will migrate in the “everywhere” direction, it follows that for NFVI vendors the smart move is to try to get customers at least comfortable with the everywhere deployment model as quickly as possible.

Right now, executing on that strategy seems to involve the ability to demonstrate a strong and broad NFV benefit case and building as big a VNF ecosystem as you can.  Financial management wants to see an indicator that benefits can be harvested in large quantities before they deploy/spend in large quantities.  CTO and marketing types want to see a lot of use cases that can be demonstrated (says the CFO, demonstrated within that strong benefit context).

All of the approaches to NFVI could lead to broad deployment of NFV, but they get there by different means, and it may be that the credibility of the path is more important than the destination for that reason.  If we presume proper orchestration for operations efficiency and agility (a whole different story I’ve blogged about before), then matching VNFs to early needs is the biggest factor in determining how quickly and how far NFVI can extend, and the extensibility of NFVI is critical in developing a broad commitment to NFV.

I blogged yesterday about the need to create mission-specific “upperware” to facilitate the development of new services and experiences.  The point that was that NFV is not enough for that; you have to be able to develop and organize functional atoms for assembly according to some application model or all you’re doing is pushing VMs around.

If upperware is what generates new services, then NFV’s service agility has to lie in its support of upperware.  That assumption, I think, offers us an opportunity to look in a more specific and useful way at the “services” NFV actually offers and how it offers them.  That can help us prepare for service agility by properly considering NFV features, and also to assess where additional work is needed.

An “upperware application” would be a collection of virtual functions deployed in response to a need or request.  If we presume that NFV deployments are designed to be activated by a service order, then clearly any need or request could be made to activate NFV because it could trigger such an order.  The order-based path to “deployment” of upperware would be essential in any event, since it could be used to validate the availability of advertising revenue or direct payment for the service being committed.

From the user’s perspective, this “service” isn’t just VNFs, it’s a complete packaged experience that will almost certainly contain components that aren’t SDN or NFV at all, but rather “legacy” services created by traditional network or hosting facilities.  We’d need to commit these too, or we have no experience to sell, which is why it’s essential that we think of NFV deployment in the context of complete service/experience deployment.  That means that you either have to extend the orchestration and management model of NFV software to embrace these non-VNF elements, or you have to consider NFV to be subordinate to a higher-level operations orchestration process.

OK, let’s say we have our upperware-based service deployed.  In the orderly operation of the service, we might find that additional resources are needed for a virtual function, and so we’d want to scale that function horizontally.  The presumption of the ISG is that we’d either detect the need to scale within the functional VNFs and communicate it to VNF Management, or that a VNF Manager would detect the need.  The Manager would then initiate a scale-out.

This poses some questions.  First and foremost, committing resources requires trusting the requesting agent.  Would a network operator let some piece of service logic, presumably specific not only to a service but to a customer, draw without limits on infrastructure?  Hardly, which means that the request for resources would have to be validated against a template that said what exactly was allowed.  This is a centralized function, obviously, and that begs the question of whether centralized functions should make the determination to scale in the first place.

The second question is how the scaling is actually done.  It’s easy to talk about spinning up a VM somewhere, but you have to connect that VM into the service as a whole.  That means not only connecting it to existing elements in an appropriate way, but also insuring that the new instance of the function can share the load with the old.  That requires having load-balancing somewhere, and possibly also requires some form of “load convergence” where multiple instances of a front-end component must feed a common back-end element.

The third point is optimization.  When you start spinning up (or tearing down) components to respond to load changes, you’re changing the topology of the service.  Some of the stuff you do is very likely to impact the portion of the service outside NFV’s scope.  Front-end service elements, for example, are likely close to the points of traffic origination, so might you be impacting the actual user connection?  Think of a load-balancer that’s sharing work across a horizontally scaled front-end VNF.  You used to be connected to a specific single instance of that VNF, but now the connection has to be to the load-balancer, which is likely not in the same place.  That means that your scaling and NFV stuff have to cause a change in service routing outside the NFV domain.  And that means that you may have to consider the issue of that out-of-domain connection when optimizing the location of the load-balancing virtual function you need.

I think this makes it clear that the problems of supporting upperware with service agility are going to be hard to solve without some holistic service model.  A service, in our SDN/NFV future, has to be completely modeled, period.  If it’s not, then you can’t automate any deployment or change that impacts stuff outside the NFV domain.  You may not need a common model (I think one would help a lot) but you darn sure need at least a hierarchical model that provides for specific linkage of the lower-level NFV domain modeling to the higher-level service domain modeling.

I also think that this picture makes it clear just how risky the whole notion of having separate, multiple, VNF Managers could get.  The service provider will have to trust-manage anything that can impact network security and stability.  Giving a VNF Manager the ability to commit resources or even to test their status gives that manager the power to destroy.  We now generate a major function of certification, a kind of “VNF lifecycle management” corresponding to software Application Lifecycle Management, that has to prove that a given new or revised VNF Manager does only what it’s supposed to do.

What it’s supposed to do could get complicated, too.  Does every VNF that might scale get a preemptive load-balancer element deployed so the scaling can be done quickly?  That’s a lot of resources, but the response of a service to load changes might depend on having such a manager in place, and if it’s not there then load changes would probably result in disruption of the data path for at least the time needed to reconnect the service with the load balancer in place.  And of course failures and faults create even more complication because while we can predict what components we might want to horizontally scale, we can’t easily predict which ones will break.

The biggest effect of this sort of assessment of future requirements is demonstrating we’re not fully addressing current requirements.  Which of the functions that upperware might expect are we willing to say will not be available early on?  No scaling?  No fault management?  No changes in service by adding a feature?  Aren’t all those things missions that we’ve used to justify NFV?

If NFV doesn’t deliver service agility then it makes no real contribution to operator revenues, it can only cut costs.  But without the ability to model a service overall, can it really even do that?  I think it’s clear that we need to think services with NFV and not just functions.

At Light Reading’s Big Telecom Event, Cisco SVP of Global Service Provider Delivery Cedrik Neike said that telcos have to transform themselves into platform providers.  Well, telcos would agree at least that they have to transform themselves into something other than what they are now—connection and transport providers.  Maybe platform providers would be better, but the question is just what a platform provider is and does…and perhaps most important what one would buy in the way of equipment.

If Cisco wanted converts to their view they could have picked a more flattering term.  The term “platform” is usually taken to mean “that on which something is built” and that meaning would create a few scowls in operator circles I’m familiar with.  It sounds like the operator is being asked to get out of commodity bit-pushing and into some other commodity business.  The OTTs have milked your bandwidth long enough so give them something else to milk!

A rose by any other name, though.  The truth is that some operator executives yearn for the role of platform provider, because it would get them out of the business of merchandizing new stuff to consumers, which network operators have not proved to be particularly facile at doing.  It’s also true that for many operators, regulatory requirements would put them in the platform business whether they wanted it or not; retail OTT-like services would either have to be pure OTT plays or exploit something about the underlying network.  In the latter case they’d likely have to be offered at reasonable rates to OTTs too.  That begs the question of whether it’s worth being a direct retail player.

It doesn’t answer the question of what a platform provider is or does, though, and it doesn’t suggest just what platform-building would look like either.  Cisco seems to see the cloud as the platform, and I would agree that the cloud, meaning cloud computing on a large scale, seems the inevitable destination of operator infrastructure evolution.  However, that’s about as insightful as saying that the sun rises.  Some specific detail would be helpful.

Operators have three paths they could take toward platformization.  First, they could build cloud infrastructure as they’ve built networks in the past and let buyers purchase capacity at utility rates.  Second, they could build some other kind of infrastructure that requires significant utility-like levels of investment, like IoT, and make a wholesale service of it.  Third, they could build a series of “platform services” by exposing elements of current networks and information gathered from the network.

In all of these cases, it would seem likely the operators would have to devise some special sauce to coat their offering with to boost margins and drive rapid acceptance.  The logical thing to do would be to build “PaaS-like” platforms of APIs upward from whatever low-level infrastructure and information the operator exposes.  If these would facilitate development of services they could provide an easy path to revenue for startups and gain at least some revenue for the telcos too.

It’s not that the cloud isn’t valuable, or that SDN doesn’t do connections.  We have architectures that can probably do what the future calls for.  The challenge is making those architectures pay off quickly.  Middleware in the traditional sense may be obsolete as a solution, because we need to empower people with less skill and less delay/cost tolerance quicker if we want our platform to be successful.  Hence, I think we need to have upperware.

Upperware is what I’m (jokingly) calling a set of problem-directed tools that get a developer or service architect quickly to value.  I blogged about two possible upperware examples recently; Alcatel-Lucent’s Rapport and HP’s IoT Platform.  These are not general-purpose service platforms, but rather are something that gets you part-way there—close enough to be functional quickly and earn some revenue.  If the network operators had platform tools of that type, I think they could attract a following.

One of the challenges of upperware is that it has to be problem-specific.  General-purpose tools are like general-purpose programming languages.  You can do anything in them, but the price you pay for all that adaptability is difficulty in using the tool, which means it’s more expensive.  We’ve had “database programming languages” for ages, designed to do database access simply.  We have web development tools, and tools for most other specialized tasks.  The thing is that even these kinds of “horizontal” tools may be too specific.

That doesn’t mean that we don’t need lower-level stuff (dare we say “underware?”) that would provide a kind of tool-for-tool-builder repertoire, and an architecture to define the ways that all the layers relate.  Think of upperware as building on foundation capabilities, one of which would be to call for dynamic deployment (NFV) and another to call for dynamic NaaS (SDN).  We could also define information interfaces to allow various contextual, behavioral, and social/collaborative information to be presented to upperware applications.

The upperware concept exposes one of the issues that NFV and cloud computing both need to face more squarely.  It’s clear that utility in either of these technologies depends on the ability to quickly assemble functional atoms into useful services or applications.  Well, there’s more to that than just stuffing something into a VM or container, or doing a service chain.  You need to think of “class libraries” of “foundation classes” that build upward to create our problem-specific upperware tools.

You can probably see that there are a lot of ways of creating upperware, meaning a lot of different places you could start.  For example, you could focus your upperware on information exposure, the presentation of data to services/applications to help refine an experience and make it more contextual and valuable.  That might be HP’s approach.  You could also focus it on relationships, on the collaborative exchanges between people.  That may be what Alcatel-Lucent intends.

It would be nice to be able to present some upperware plans for a variety of players, because it would be nice to think that vendors were projecting their customers’ needs for new revenue into vendor product plans in a realistic way.  Beyond my two examples here, though, I can’t see much going on.  That is almost certain to create problems down the line, and you can see a likely problem spot when you look at the notion of the “service catalog”.

Most NFV supporters envision an architect grabbing stuff from a service catalog and stringing it into a service.  Functionally that’s a good approach, but how exactly do the pieces end up fitting?  We could connect a router to a server or a switch in a dozen different ways, most of which would do nothing useful.  If we expand our functionality to that of a software component, knowledge of traffic status or the temperature in the basement, you can see how the chances of random pairing producing utility fall to near-zero levels.  Call it what you will, we need upperware to create function communities that can then build upward to something interesting.

And here again we have the question “Where does upperware come from, mommy?”  This sort of thing is clearly out of scope for the NFV ISG, for ONF, for the TMF, even if we assumed the bodies could make a respectable contribution if they tried to go there.  Do we need (perish the thought!) another forum?  Or do we just need vendors making their own contributions?

The broader a problem is, the less likely it is that we can sit down a bunch of interested parties and hammer out the details.  Groups aren’t doing what they’re currently tasked with doing in a complete and timely way, so they’re unlikely to be the answer to a call for additional structure in our service thinking.  I’m hoping both Alcatel-Lucent and HP frame their stories out fully, and I’m hoping other vendors develop their own upperware responses, whatever they decide to call them.

The OPNFV project released its first (“Arno”) build, and it may be more noteworthy for how the pieces it contains were selected than for its functionality.  There’s logic to how OPNFV did its work, but there are also risks that its order and timing of releases pose.

Arno is a platform that includes the infrastructure (Network Functions Virtualization Infrastructure or NFVI) and the Virtual Infrastructure Manager (VIM) components of the ETSI ISG’s E2E model.  The combination offers the ability to deploy and connect VNFs in a cloud architecture based on OpenStack and OpenDaylight.  The features are based on the ETSI ISG’s Phase 1 work, and the model does not include orchestration or management (MANO, VNFM).

OPNFV is, as a group, in a challenging position.  Open source development is often done from the bottom up, simply because it’s hard to test something that sits on top of the functional stack and looks downward into nothing but vague specifications.  If the software design is done top-down, which I’d contend is the normal practice for the software industry, the bottom-up development doesn’t pose any major risks.

In the case of NFV, the problem is that ETSI’s work was also bottom-up.  The understandable desire to complete a model of the technical core of NFV—deployment and management of virtual functions—led the body to limit its scope, excluding things like control of legacy elements, end-to-end service management, operations integration, and federation of elements to/from other providers or partners.  Some of these may be addressed in Phase 2, but all of them create requirements that probably could be more easily addressed by being considered up front, before the high-level architecture of NFV was laid out.

OPNFV has a commitment to tie its activities to the work of the ISG, which means that the development will also have to contend with these issues as it evolves.  That might involve either making significant changes to achieve optimal integration of the features/capabilities, or compromising implementation efficiency and flexibility by shoehorning the capabilities in.

One interesting aspect of the OPNFV Arno release that demonstrates this tension is that Arno includes NFVI and VIM, which in my view implies that the two go together.  In the ETSI E2E model, though, VIMs are part of MANO, which is otherwise not represented in Arno.  I’ve argued that VIMs should have been considered to be part of NFVI from the first because a VIM is essentially the agent that transforms between an abstract model of a deployment/connection and the realization of that abstraction on actual resources.

The good news here is that OPNFV may be quietly rectifying a wrong here, and that this may be an indication it will continue to do that.  The bad news is that it’s a wrong that should never have crept in, and that significant divergence from the ISG specification as we evolve OPNFV begs the kind of disorder that creeps into development project that don’t have a firm spec to begin with.

Let’s go with the good first.  In the real world, infrastructure for NFV is totally abstracted, meaning that a VIM proxies for all of the stuff it can deploy/connect on or with.  This seems to be the approach OPNFV takes, but if that’s so then one thing I’d like to see is how multiple VIM/NFVI plugins would actually work and be connected with MANO.

If there are multiple VIM-plugins, then MANO presumably has to be given a specific plugin to use in a specific situation, meaning that MANO models would have to have selective decomposition so you could pick the right plugin.  If MANO doesn’t do that, then there has to be some sort of generic plugin that further decomposes requests into the individual infrastructure-specific plugins needed depending on configuration, service parameters, etc.  I’m not aware of either of these capabilities in the current MANO model.

Then there’s management.  If a VIM carries infrastructure upward into orchestration, management needs to know how that carrying chain is handled so that resources actually involved in a service can be associated with the service.  I don’t know how that’s supposed to work either.

Finally there’s federation.  If I have a VIM representing resources, why not have a VIM represent federated resources?  Does the current approach have the necessary hooks to be used across organizational boundaries?  Don’t know.  So to summarize, we have a lot of potential for good here but not enough information to realize it fully.

On the bad side, the challenge is both that we may have insufficient specifications to back up development, and that we may have too many.  The ETSI ISG, for example has tended to look at service and resource data in an explicit sense, like most of the TMF SID applications do.  You need a field called “maximum instances per load-balancer” so you define it.  The problem with that is that you end up with a billion or so fields most of which are irrelevant to a given service, and every new service or feature is likely to spawn a chain of new fields.  What developers would do is simply to declare variable attributes, in an XML-like way, and say that any “field” is fine as long as something fills it and something else uses it.  No need for names or pre-defining.

So what does the OPNFV group do about this?  Do they do the right kind of development or follow the ETSI model explicitly?  Right now we don’t have the answer because nobody has really defined what the northbound interface of a VIM should look like in detail.  In both my NFV projects (CloudNFV and now ExperiaSphere) I modeled this stuff as either XML (or a derivative) or TOSCA and presumed a structure that defined an “abstraction-type” and then type-dependent details.  I’d like to see somebody say what the ISG/OPNFV presumption is.

NFV has a way to go before it defines all the functions and features needed to make its own benefit case.  Where OPNFV could help is to address the places where that benefit connection is anemic.  But if the body wants to stay “technical” then the key point to look at would be the abstractions that define service models and that should define the interface between VIMs or other “infrastructure managers” and MANO.  You are, service-wise, what you orchestrate, and you orchestrate what you model.

The big challenge for OPNFV remains time.  Operators need something by the critical 2017 revenue/cost crossover, and markets are advancing with per-vendor solutions whose scope matches benefit needs, in part because nobody has a sanctioned open approach that does.  At some point, further work will get so far behind the state of the market it will be too late to influence things.

There are a lot of ways to get to LA from NYC and a lot of ways to realize the service agility benefits expected for NFV.  Some paths are likely better than others in both these examples, and in both cases it may be necessary to travel a little to know what the best choice is.  Thus, it’s interesting to note that the two leading vendors in NFV have different approaches, and that we’ll likely see some proof points of both in the next six to nine months.

Service agility is one of the most credible goals for NFV, and it’s also the goal that could in theory generate the most benefit.  Capex savings are unlikely to amount to even $20 billion per year.  Opex efficiency-driven savings could reach $100 billion providing that NFV principles were extended universally to all infrastructure and all operations levels.  The revenue stream associated with agile services based on cloud principles is, by my current modeling, over $2.5 trillion, with a trillion coming from the enterprise space and the remainder from consumer mobile and content services.  Some of this could be addressed without NFV, but NFV would be critical in wringing the most profit from it all, and in addressing all but the low apples.

The problem we have is that most of the service agility discussions relating to NFV are crap.  When you wade through the morass you find two basic ideas—adding higher-level network features to services and bandwidth on demand.  Buyers have told me for decades that things like firewalls and NAT are per-site features that don’t change much once you have them deployed, and that their only interest in bandwidth on demand is lowering overall network spending.

I’ve speculated in the past that there are many new services that will emerge out of mobile users and their focused, contextual, view of network services and information resources.  There’s little point in my going over this opportunity side again.  What’s worth looking at is how vendors seem to be approaching the question of how you really could create services with NFV and grab some of those bucks.

From an architecture perspective, NFV isn’t enough to support highly flexible assembly of services from features.  Yes, you can deploy and connect elements with NFV, but while “chaining” works for things that have a simple “cascade-in-the-data-path” relationship with each other, it doesn’t support microservices and APIs fully.  Future services, that two-and-a-half trillion bucks, have to be seen more as transactional activities or workflows, not connections.  So what you need is a kind of platform-as-a-service framework that lives on top of NFV, meaning that NFV deploys and manages it, but that provides services to build feature applications.  Alcatel-Lucent and HP have each shown they have a vision for that.

Alcatel-Lucent’s approach is embodied in its Rapport product.  Rapport is a session-services framework that lets operators or even enterprises build applications (especially collaborative ones) based on IMS mobility control.  It leverages Alcatel-Lucent’s virtualized IMS/EPC elements and is compatible with CloudBand and NFV.  You can manage services using the Motive operations tools.

Despite the fact that IMS is hardly news (it dates back to about 1999), the fact is that IMS has been a target for NFV from the first, and it is an asset that operators own and would like to leverage for differentiation.  Rapport is also targeting the same opportunity that Google’s Fi MVNO strategy seems to target, augmenting basic mobile voice services with what are essentially extended forms of custom calling features (remember “custom local access special services?”)  Since transactional services based on sessions would generate a massive increase in signaling traffic, agile and scalable IMS would make sense.

The HP approach is different.  They see new services being tied at least in part to new exploitable information resources, most notably to IoT.  In their model, the network connections to resources, their controllers, and repositories and analytics to store them are all bundled into a kind of “USB-of-services” that you can plug in as needed.  Each of these plugins expose a set of APIs that then become available to service-creating applications.

This model is more “cloud-like” or “Internet-like” in that it exposes APIs for presumably open consumption either on the Internet or in some VPN subset of users/resources.  For now, at least, there’s no specific model of how the services would relate to each other or to the plugin microservices.  HP may have plans for “superservices” like IMS to plug into this (they’ve talked about MVNO-based IoT so they’re clearly thinking about it) but they’ve not exposed them as yet.

There’s a common thread in all of this, I think; several in fact.  High-level services are going to be built more like cloud applications than like connection services.  NFV can play a role in that where dynamism (either transient services or the need for scalability) is a significant requirement.  High-level services are going to be built inside a “sandbox” of APIs.  We don’t know what exactly will stick with respect to this approach.  We’re hoping somebody will tell us.  I like both the Alcatel-Lucent and HP approaches in no small part because they’re bold adventures into a world we need to get to, but don’t quite know how to describe.

Cloud services, to be optimally deployed, useful, and profitable, have to become highly agile and tactical.  So do NFV-deployed features.  So do SDN connections.  The future differs from the present largely in that concentrations of humans, computing, and connectivity associated with traditional worker relationships and homebound consumers are increasingly irrelevant.  With the elimination of natural human mash-ups we also lose opportunity to address those humans as a group.  Personalization is a natural part of addressing mobility.  Agility is the fundamental requirement of a personalized service set.

Network and IT/cloud vendors approach this differently, which is one of the interesting things about the Alcatel-Lucent and HP positions.  It’s hard to say whether networking or IT has the most natural connection, or even to say that there’s enough of a difference to matter.  If we have to transform both, then we’d end up starting where it’s convenient, or compelling.

It’s also interesting that both of these approaches nibble at the tenuous border between service management as a pre-service conditioning of resources and service logic as a real-time management of workflows.  As networks and the cloud become more tactical, it’s going to get harder to distinguish between coordinating deployment and simply running the application.  Might, for example, a transaction direct the deployment of its own resources?  That will generate some interesting shifts in both worlds.

Alcatel-Lucent’s Rapport addresses the model for personal connection in a world without branch offices and couches (philosophically, at least) and HP’s IoT and plugin model for information-driven services addresses how those mobile/personal users interact with the world around them.  We’ll have to do both of these things, and more.  The winning approach may be the one that can validate its vision of the future and link it to profitable steps in the present.

OpenStack is hot.  IBM is going to acquire Blue Box and Cisco is acquiring Piston.  You could look at this as a kind of consolidation signal, but I think it has other implications.  In fact, it might signal some SDN maturity, some NFV questions, and some cloud directions.

OpenStack is obviously the premier approach to cloud deployment, despite the fact that the project has been growing like crazy, changing often, and generating a little angst on the part of vendors and users for limitations in functionality and perceived lack of stability.  One thing that’s clear from the two OpenStack M&A deals is that big-time cloud pressure is going to land on OpenStack and that it’s going to get a lot better.  Of course, if OpenStack is already winning, what would all that betterness mean?

From a competitive perspective, obviously it would mean a lot.  OpenStack would crush alternative approaches, frankly, and that’s what is likely to happen very quickly.  If you have a cloud product or a cloud strategy, it better be based on OpenStack at this point.  I’d guess that CloudStack, Eucalyptus, Nimbus, and OpenNebula proponents have six to nine months to prepare some graceful shifts in strategy, after which time they’ll end up being even more hurt by OpenStack momentum than they’ve been so far.

For vendors who have already accepted OpenStack as the cloud answer, this is good news in one sense and a warning of risks to come in another.  Obviously Cisco and IBM are in this camp, but so are giants like Alcatel-Lucent and HP.  The problem they all face is that differentiation of cloud strategies will now become more important and more difficult at the same time.  Nobody wants to be selling exactly the same product as a competitor, and so all the OpenStack-committed players are going to be casting around for something that makes them different, better.

For the cloud industry, public and private, a clear OpenStack victory may be important primarily for the fact that it will push OpenStack and Amazon’s AWS/EC2 into a clear face-off.  Competition between Amazon and OpenStack clouds will be driving down basic IaaS pricing, which I think is going to create a public-cloud focus on things that can extend profits.  That will be true for both Amazon, whose AWS services already include a lot of optional value-added features, and for OpenStack which has been slow to develop any specific PaaS or SaaS extensions.

The impact on the industry overall is complicated.  It’s even more complicated when you consider that SDN’s OpenDaylight is also generating a lot of M&A interest too.  Maybe all these acquiring vendors see the future.  Maybe they are all just knee-jerking to the same doctor’s mallet.  Whatever the case, I think what we’re seeing has a common theme and that is the notion that the future will demand more agility, more personalization than the present.

Wireline networking isn’t going to change very quickly because what you network with it is either branch offices or homes.  Nobody is going to build either of these just to consume more efficient connectivity, so it’s fair to say that favorable pricing and features won’t build new customer connections.  You’d have to sell more services to the same location.

Location services that we know about are bulk transport.  That’s not going to be more profitable for operators in the future, so it won’t be profitable for vendors to support it.  What we’re looking for is stuff that’s above the connection/transport zone, and that means features and applications.  Networking these things is different from networking branch offices and homes, because there’s a variability in higher-level service relationships that branches and homes don’t generate.  The cloud and NFV justify SDN.

Mobility is the instrument of personalization, and also what justifies the cloud, and that’s the causal chain that ultimately changes everything.  A hundred workers sitting in a branch office present a fairly consistent network requirement.  If that same hundred workers runs out into the wide world and connects via mobile networking, it’s a whole new ball game.  Even if those workers did the same jobs, they’d need a different level of support from networking in the form of connectivity, and from IT in the form of productivity enhancement.  This is what injects change, in the form of dynamism, into the network market.

It’s also what’s injecting the motivation for M&A.  I think vendors are starting to see that things are changing.  Yes, they’re into denial.  Yes, they see the symptoms and not the sweep of the future.  But they see something, and they’re reacting to it.  Most of the moves so far are tactical in nature; “We’re hearing a lot about OpenStack lately, so maybe we should do/know something there.”  It would be dangerous for us to assume that Cisco had suddenly changed its view of the future because it bought an OpenStack player, or that IBM did that.

Cisco probably does see that there are going to be a lot of clouds, and that services and applications are probably going to have to span them.  “Intercloud” is Cisco’s cloud strategy so that’s probably good at one level, but they have to make Intercloud more than a title on a PowerPoint.  Piston might help in that regard.

IBM probably realizes that private cloud is as likely (or more likely) to be driven by business operations as by the CIO, and that they need a nice wide on-ramp with an easy gradient if they want to succeed in private and hybrid cloud.  There are much broader implications to the notion of business-driven cloud than the ease of using the cloud stack software, but IBM would have to change a lot to address these.  So they’ll focus, via Blue Box, on what they feel they’re ready to accept.

If you have a sense of déjà vu here it’s not surprising.  We have at the same time a vision of a radically different future and a bunch of people who are tying themselves to the starting gate in the race to own it.  This isn’t a great surprise, of course, but it does raise the question of whether these early movers in OpenStack are really attacking anything or simply preparing a defense.  That would raise the question of who the attacker might be.  Amazon might yet end up a winner here, simply because a drive toward OpenStack and OpenDaylight by major vendors, driven more by turf protection than opportunity realization, might well stall OpenStack progress completely.

There’s also the impact on NFV.  I said years ago, in the ETSI NFV dialogs leading up to work on the specs, that if all NFV proposed to do was to deploy VNFs they might as well simply reference OpenStack.  There’s a project within OpenStack to telco-ize the model, and if enough vendors jump to support OpenStack that project might get enough backing to tap off the opportunity for “limited-scope” NFV.  That would force differentiation to address higher-level orchestration and management issues, which most vendors are still dabbling in.

What this means is that all this OpenStack stuff could be very important indeed, and something we’ll all have to keep an eye on.

SDN, NFV, and the cloud all suffer from a common challenge.  You have to start somewhere and exercise prudence on creeping scope, but the changes all could make in IT/network practices are so profound that you need to look beyond early applications in search of both an architecture and a mission broad enough to cope with growth.  I’ve said several times recently that current NFV projects in particular were perhaps examining the toes of the technology too much rather than stepping boldly toward the future.  That puts more pressure on vendors to make that broad business case.

HP is IMHO the functional lead in NFV; their stuff is the most complete and the most credible of all the solutions I’ve examined.  This week at their Discover event in Las Vegas, they opened up a bit on their vision of the future, both for their OpenNFV approach and for how NFV marries to SDN, the cloud, and future operator business models.

One of the critical issues in NFV is how NFV deployment in the explicit ETSI sense of virtual functions and hosting can be integrated with legacy elements of the same service, SDN components, and perhaps most critically operations and management systems.  HP proposes this be done using a combination of “universal orchestration” and an extended model of infrastructure management.

HP’s Director has been enhanced to offer analytics integration and a dual-view option for service management or OSS/BSS versus an NFV view of management data.  It’s underpinned by a universal data model for structuring services and resources alike.  I like the unified approach, though I confess it might be a personal bias since I’ve not really been able to line up a divided-model approach against an equally good integrated-model approach to see if the benefits are real.

The new version of the model supports both the relatively limited MTOSI states and more generic and flexibly defined states.  If you can make the former work the result is easier to integrate with TMF-level material like SID but I think that MTOSI states are probably not adequate to represent complex NFV stuff like horizontal scaling.  The model also supports the notion of a “virtual VIM” that lets you model multiple options for deployment, like NFV versus legacy.

The extended infrastructure manager concept, which I’ll call “IM” just to save typing, is based on creating a unified data model to represent infrastructure that can generate services—you can model SDN, NFV, and legacy with the same model, which means that a common IM approach above the data model can link everything to higher-level functionality.  It’s this approach that gives HP’s OpenNFV product breadth to address a service end-to-end.

This all links to some of the future-trend stuff.  HP talked about a “service factory” and “mall” approach.  Architects can assemble stuff in the service factory and wring it out, sending it to the mall for retail offers.  The services can take advantage of underlying transport, higher-layer connectivity, network-related features like firewalls, network information gleaned from service operations, and data from other sources (more on this in a minute).  This creates a multi-layer operator business model rooted in traditional networking and building up to a more OTT-like picture.

HP’s view is that as time goes by, NFV will become more “cloud-like”, not so much by changing any of its technologies but by supporting services and applications that evolve as operators look for new revenues—for new stuff to sell in the “mall”.  They offered a vision of how that might work, too.  Users, both consumer and business, are evolving their position on what “the network” has to offer them as they become more dependent on mobile devices.  Mobile users move through what look like “information fields” created by their own behavior (social networking, for example) and by the sum of their environment.  These fields intersect with the users’ interests to create what the HP slides call a “Decision Fabric”.  From this fabric, you can build applications that support not knowledge but action, something that’s of higher value.

You can get information fields from what you already have.  Location-based services are an example, and so is that social-media context.  You can also visualize new developments like IoT as an information field, and in fact you can see the difference between the Decision Fabric approach and conventional IoT models pretty easily.  IoT in the HP view is almost a self-organizing concept, a marriage of data from sensors and analytics presented not as a bunch of IP addresses but as a service.

In fact, they shared the architecture of their IoT solution, and that’s exactly how it works.  You have a collection of devices on public or private networks that contribute to a repository of IoT knowledge that can be passed through filters in real time or in the form of analytic results.  While this model is specifically aimed at IoT, HP said that it would be the general model for their drawing data into their Decision Fabric.

They also said that the OpenNFV tools would be used to deploy the components of the Decision Fabric, and that it was applications like this that would shift NFV from provisioning relatively fixed pieces of service technology to coordinating highly dynamic services.  That’s where NFV is most useful of course; you don’t need a lot of service management technology to deploy something under a two-year contract.

The HP positioning on NFV, SDN, and the cloud poses an interesting challenge for the industry and for operators.  It may also challenge HP itself, all because of the fact that it extends the current rather narrow notion of NFV, brings in related technologies like SDN and the cloud, and magnifies the need to orchestrate everything related to service deployment and behavior and not just virtual functions.  A big story can have big benefits, but it’s also more complicated.

That’s the root of the dilemma we have with SDN, with NFV, and with the cloud.  We have glorious future visions of these things and we have a generally pedestrian view of their near-term evolution.  The cloud is going to change everything, yet most think of it as hosted server consolidation.  SDN is a revolution, but it’s a revolutionary way of building the very same services we already consume.  NFV is about orchestrating for dynamic service creation, but we think it will be dynamic creation of the very functional pieces we already have in a forty-dollar network access box you can buy at a technology store.

You can’t leap into a totally new world of networking, not in an industry with capital cycles of five to seven years on the average.  But you can’t evolve by just doing the same old stuff either.  I think what HP’s visions prove is that there are solutions out there that can create a real future for NFV and not just an extension of the present.  That’s true for other vendors too, and so the question for the industry and the vendors may now be whether they can show buyers that future without scaring them into immobility, or whether they can lead them step by step to the right place without ever telling them just where that is.  If one or the other can’t be done, then all our revolutions risk diffusing into footnotes on the technology story.

In a couple blogs last week I was critical of Alcatel-Lucent’s positioning of a new product (NSP) and their expressions of SDN/NFV opportunity in a white paper done in conjunction with AD Little.  I also raised questions about their positioning overall, and their ability to deliver on SDN/NFV benefit needs.  I had a chance to talk at length with them about their portfolio, and the good news is that they have a lot better technology than I thought.  The bad is that they’ve been presenting it even more inconsistently than I’d feared.

NFV poses a lot of vendor challenges, and one we don’t often think about is that it can cross over product-group boundaries.  A complete NFV implementation that does everything I think is essential would have to include operations tools, NFV MANO and VNFM, a VIM/NFVI strategy, SDN, and legacy device control via something.  You’d also likely need some VNFs.  However, an ETSI-compliant NFV implementation could need only the MANO/VNFM/VIM/NFVI story.  Almost every NFV supplier out there takes a holistic view of NFV and touts as many things as they have from my full list.  What I’ve found out is that Alcatel-Lucent doesn’t do that, which means that if you look at their NFV material you don’t see things that operators and I would all put into the NFV story.  You’d think Alcatel-Lucent didn’t have the stuff, in fact.

If you want to see a complete picture of NFV from Alcatel-Lucent, there is one, but you don’t find it in NFV material.  Instead you have to look at Motive and in particular SURE, and neither of these is easy to find on the company website or easy to connect with either Alcatel-Lucent’s SDN or NFV strategy.  Here’s some helpful links to save you the problems I had!  Motive is HERE and SURE is HERE.

Motive is the family of products that Alcatel-Lucent aims at service management and operations.  If you look at the components of Motive you see all the familiar operations stuff but you don’t see specific links to emerging critical technologies like SDN, NFV, and the cloud.  It’s not that they aren’t there, but you have to dig even deeper, into the modeling approach itself, which is SURE.  There’s a little blurb on Sure on the Alcatel-Lucent site, but it doesn’t even scratch the surface.  I got some slides on it but they’re NDA, so I’ll have to try to verbalize.

SURE is the acronym for Motive Service and Unified Resource Engine, which the company presents as a “data model” but which is in effect an operations architecture.  An Alcatel-Lucent slide on SURE shows it as being a TMF-modeled service management framework that actually looks quite a bit like the package that Oracle has announced as an SDN strategy.  Interestingly, Alcatel-Lucent’s SURE is actually a bit more modern and arguably more complete even than Oracle’s, even though Alcatel-Lucent seems not to present it in an NFV/SDN context.

My secret slides show SURE as a data model that integrates the Motive components with services and with each other.  SURE and Motive create a complete service management framework that includes both customer-facing service (CFS) and resource-facing service (RFS) models that correspond to the TMF modeling and also generally to my own CloudNFV and ExperiaSphere models of a service and resource domains.  The models that make up services are “fractal” in that either CFS objects or RFS objects can decompose into lower-level objects of the same type.  CFSs can also cross the service/resource border and link to RFSs that then commit the resources.

Under the SURE model structure, Alcatel-Lucent explicitly places SDN, NFV, and legacy elements.  Each of these is represented by what could be called a resource or infrastructure manager.  I think that would suggest that each could then be considered the realization of an RFS.  You could organize, orchestrate, and manage hybrid SDN/NFV/legacy services with the SURE/Motive approach, which raises two interesting questions.

The first and most obvious question is why Alcatel-Lucent doesn’t tout this in their SDN and NFV positioning.  I was able to find the Motive approach on their website only with some difficulty after knowing it existed and what it was called.  I didn’t get any comment from operators on Motive in association with SDN/NFV, and in fact a couple of operator transformation plans I just received outline an almost perfect mission for Motive and identify vendor candidates, but don’t list Alcatel-Lucent among them.  SURE, which should be the heart of an Alcatel-Lucent SDN/NFV positioning, gets perhaps a paragraph on the website, and its description isn’t even all that helpful.

I don’t want to get hung up on the lack of positioning, though I think the fact that key operator staff don’t even know about the stuff demonstrates there’s an issue.  With Motive and SURE, Alcatel-Lucent is surely superior to Oracle and nibbling at the functional heels of (IMHO) market leader HP.  There’s enough substance here for Alcatel-Lucent to drive an effective NFV engagement and to take rational NFV services to field trial and deployment.  Not many vendors can say that.

The second question is whether an approach like this (which Oracle also takes) that separates OSS/BSS orchestration from whatever goes on in NFV/MANO is better than one that integrates orchestration across everything that needs orchestrating.  It’s an unfair question at one level because the NFV ISG doesn’t consider operations or legacy network elements in-scope, though it seems to be expanding at least its legacy strategy for connections in association with NFV deployment.  If the standard doesn’t consider broad orchestration a goal, you can’t fault vendors for not broadly orchestrating.

Well, maybe you can.  I think that there are significant advantages to be gained from a common data modeling from the top of a service to a bottom.  This structure means that all of the tools for modeling and linking process elements are common, which means that it’s easy to make a model hierarchical.  If you have to cross modeling approaches, you first have to define an open boundary and second have to insure that you have everything you need passed across it.  Even then there is a concern that you may have different visibility/management tools at different places.

Despite the possible benefits of a common model, vendors who have it seem to be uneasy about trotting it out in association with NFV.  I suspect the issue comes down to sales.  The value of a common model is linked to broad application of orchestration.  If you have engagement in the NFV PoCs, do you want to expand the scope of your effort to involve new carrier constituencies and potentially new and complicated issues?  Or do you want to press forward, order-book in hand?

The problem is that I don’t think that blind momentum on current PoCs is going to take operators, or NFV, where we need to go.  I think it’s going to take harmonized efforts involving operations, the cloud, SDN…and NFV.  We can’t get those efforts if all the pieces except NFV are walled off.  Silos are what we’re trying to get rid of, so we don’t need to invent a philosophical siloing level for our key technologies.

Alcatel-Lucent has other hidden-gem assets, some of which I’ve seen demonstrated in a very impressive way.  Their virtual IMS and Rapport strategy is exceptionally strong I think, and could be easily coupled with a strong NFV and operationalization positioning.  You can get all of that with the right combination of people but not on the website or in any public marketing material.

The whole is supposed to be greater than the sum of the parts, which is true in Alcatel-Lucent’s sense but hard to determine given that the parts are difficult to locate.  While Alcatel-Lucent is far from the only vendor to have under-positioned their NFV-and-SDN-related assets, they have more to lose by doing so.  I saw, at an HP event this week, a broadening of NFV scope and positioning.  Given that HP is Alcatel-Lucent’s primary functional rival in NFV, Alcatel-Lucent needs to start singing their own multi-product song—in harmony.