Month: November 2016

There has been a lot of talk about service modeling, and I’ve contributed my own fair share.  However, there have also been some developments in the space and I’ve gotten some questions from operators too.  Given this, a re-examination of the key points seems to be in order.

My conception of a service model is that it’s a hierarchical structure, something that looks a bit like an organizational chart.  Each of the boxes in the chart is an element in the model, and each element represents a building-block that’s used to describe service deployment and the service lifecycle.

The best way to look at service modeling is through a series of examples, all of which start where all models should—at the top.  The top element in any service model should be a representation of the service overall, meaning that Service should be presented as a combination of SLA attributes, orderable parameters, and decomposition instructions.  The customer sees everything but the latter; the operator is responsible for decomposing the element and propagating parameters downward toward resources, and propagating parameters upward to form the SLA parameters.

Underneath this nice, solid, vision we start to see some variations in approach.  Broadly, we can decompose to one (or more) of three things:

1. To resources, which would mean that the high-level service can directly commit resources. I think that’s a rare outcome, but I’m introducing it here because in theory any layer of a service model might decompose to a resource commitment.
2. To functional elements, which are logical subdivisions of the service. The classic example is that a VPN service could decompose into “MPLSVPN or “2547VPN” and a set of “EthernetAccess” elements, one for each site.
3. To administrative elements, meaning requests for decoding of the element by a geographic or network-or-vendor subdivision. An example is “Firewall”, which might decompose to a virtual function in some places and a physical appliance in others.

In fact (as I suggested in the first point), any element in a service model could decompose the way I’ve just described.

You can see a combination of elements in the following example.  If our VPN service includes an element MPLSVPN, we could say that element could be decomposed into administrative domains representing various parts of the prime operator’s network and/or network services obtained from other operators.  Our EthernetAccess element might decompose into HighLevelFeatures and ConnectionFeatures, and HighLevelFeatures could decompose into VirtualEquipped or LegacyEquipped, in which domains Firewall would either deploy a VNF or generate a ship order to send an appliance.

Where decomposition results in resource commitment, the service model can continue to describe the decomposition steps, or hand off to a lower-layer model or management process.  The primary difference between these approaches is the way that service lifecycle management is supported, and that’s our next topic.

All services have a specific set of states that represent their progress from orderable to ordered to deploying, to deployed, to operational, and to decommissioning.  How many states and what they are is somewhat open for discussion, but the broad set I’ve outlined is the basic minimum.  Generally, a “state” is a context in which service events have to be interpreted, so if you start something with an event there’s a good chance that will generate a new state, where you await its completion or failure.

Events are conditions that are significant to a service lifecycle, and they’re a lot more variable than states.  Events can come from two general sources—from adjacent model elements (higher or lower), and from sources outside the model, which could include management systems or resources.  They’re signals that something has happened, and thus are triggers for management processes.

The states and events are traditionally correlated with processes through a state/event table, which is a simple array whose rows and columns represent states/events (in either order) the intersection of a state and an event yields a cell that typically defines the process to be run and the state that will be set when that process has completed.  Example: “If I get an ACTIVATE event in the ORDERED state, initiate the DEPLOY process and set state to DEPLOYING.”  The navigation through the service states based on service events defines an often-heard term, the service lifecycle.  Service lifecycle automation and management is simply the use of state/event-driven processes to respond to events.

Since everything from ready-to-order onward can be a lifecycle phase, this approach could subsume NFV and SDN deployment steps into a standard service model.  That would eliminate the boundary between SDN/NFV orchestration and service orchestration.  It would also bridge SDN/NFV and legacy technologies, since any provisioning approach would work as the resource end of the modeling process.

The problem with the approach is on the vendor side.  Every operations and management task would be individually orchestrable in the state/event model, which would break the lock that vendors now have on software tools in both areas.  The approach also demands broad strategic engagement with prospects, engagement that would take time and cost money to sustain.  It’s easier to blow kisses at benefits with some low apple like virtual CPE or SDN in data centers.

Operators are currently in a position of supreme contradiction with all of this.  On the one hand, nearly all of them recognize that they need, critically need, opex reduction and service lifecycle automation or they’ll never achieve any significant gains in profit per bit.  They also recognize that the scope of benefit delivery will be limited to the scope of the service model.  Despite this, they don’t call out full-scope solutions in RFPs and they aren’t even fully aware of who can deliver them.

A further note is that operators are voting with their own specs on the issue.  Both AT&T and Verizon have multi-layer orchestration, which I think is an attempt to harmonize their own need for broad service modeling and automation with the fact that the industry isn’t delivering it.  The problem is that where you have different models you have additional integration requirements, and we don’t know how complex it would be to deliver a state/event lifecycle management description that had to whiz back and forth across model and orchestration boundaries.  One model to rule them all.

There is no topic in all the transformation space as important as service modeling.  There’s probably no topic we know less about.  What would an SDN or NFV service model look like?  Bet you can’t find anyone who could draw one.  We’re not short of areas of transformation that have gotten superficial attention, but service modeling is at the top of the list, and also at the top of the list of places where we need focus, and need it now.

Across the various places I write on networking topics, the topic that consistently outperforms the rest is OSS/BSS.  I also get more comments and questions on that topic, and operators tell me that it’s become the most important issue.  That all means that this is a good time to look at just where we are on OSS/BSS modernization.  That the TM Forum, the standards leader for OSS/BSS, has just dumped its CEO makes the topic of modernization positively poignant.

I have to start the topic with an important truth, which is that the CIO who drives OSS/BSS transformation is still largely outside the network planning process.  Across the spectrum from Tier One through Tier Three, just short of nine out of ten operators say that they separate operations and network planning.  About the same number say that integrating new services and technologies with OSS/BSS is a matter of creating the right record formats, or perhaps the right APIs.  Even though the Tier One operators almost universally created “transformation teams” to cross organizational boundaries in evolving their services and infrastructure, the great majority of them have quietly dropped or de-emphasized these teams.  We’re back to business as usual.

The isolation of CIO/OSS/BSS has been a major contributor to the limited target adopted by SDN and NFV standards.  It’s also why there’s been a sharp division within operators on what should be done on the operations side.  In fact, just as you could divide CTO and COO people based on whether they saw next-gen networking as a virtual revolution or a minimal transformation, you can divide OSS/BSS people on both the goals and the path to operations renewal.  Some simply wanted software modernization, a more open way of selecting operations tools that broke traditional monolithic stacks that locked an operator into a vendor.  Others wanted something “event-driven”, where service lifecycle changes drove specific OSS/BSS activity in a more automated way.

What SDN and NFV have done is empowered the latter view, in no small part because creating service lifecycle management in a separate MANO-like process would threaten to turn all of operations software into a kind of passive record-keeper.  Some OSS/BSS vendors (Netcracker, Amdocs) have framed architectures for OSS/BSS orchestration, but operators think they’re as vague as NFV strategies.  In fact, there are a lot of common issues between event-driven OSS/BSS and NFV.

Most operators would say that the two problems that NFV has at the technical architecture level is that VNFs don’t have a solid architectural framework in which to run, and service lifecycle management is simply the wild west in disorder.  In event-driven OSS/BSS, the problem is that OSS/BSS components have no solid architectural framework in which to run, and that service lifecycle management is also the wild west.

The issue of the architectural framework for either VNFs or OSS/BSS components is significant because without some specific interface through which these can connect with the rest of the management/orchestration and operations software, every service would require customization.  That’s already being experienced in the NFV world, giving rise to the “snowflakes versus Legos” analogy that reflects the uniqueness of each VNF.  This issue, then, is both a threat to easy on-boarding of elements and to the openness of the overall deployment.

The service lifecycle management problem is critical for everything in next-gen networking, and it’s actually the thing that provides both a technical and benefits linkage between SDN, NFV, and OSS/BSS modernization.  The goal is simple; to activate software processes in response to service and infrastructure events, to reduce significantly or eliminate the need for manual activity.  Since the cost of all this manual activity and related costs currently runs more than 50% higher than the total capital budget of operators, that’s a pretty significant goal.  By 2020, my model says that capex will decline under spending constraints and opex (absent software automation) would continue to expand.  The result is that opex could exceed capex by 90%.

Another critical (and often-ignored) point is that both SDN and NFV increase complexity, and that unless the cost impact of that complexity increase is mitigated by software automation, you’ll not see any net benefit to either technology even where it can be applied.  Service modeling and automation is thus critical in even defending capex reductions.

I’ve argued for literally years that the only path to achieve savings in process opex was model-driven service automation that defined, for each model element, the service lifecycle in state/event form.  I produced an open model that I called “ExperiaSphere” (the name was taken from a previous service-automation project I’d done for the TMF SDF activity) that’s represented by five PowerPoint/PDF tutorials running an average of 30-odd slides each.  This, in about six months’ part time, one-person, effort.  Yet we’ve had a NFV management and orchestration project and a TMF project staffed by dozens each, and neither has generated even a high-level picture of such a model.  Since I know many of the people and they’re far from dumb, you can attribute this failure only to a lack of motivation.

Modeling isn’t a new concept for software deployment and lifecycle management.  Complex software deployments are typically handled by a set of tools called “DevOps”, and there are two models of DevOps in use.  One lets you define modular scripts for deploying things, and it’s called the “imperative” model—it tells you what to do.  The other defines end-state goals, so it’s called the “declarative” approach.  Both support modular nesting of compositions, and both have a provision for event-handling.  The OASIS TOSCA cloud model has the same capabilities.  With all of this, why have we not accepted this most basic rule of software automation for network service deployment—you have to model it in a structured way?

Model-driven automation of the service lifecycle is a given.  It’s a simple extension of software and cloud practices.  It’s going to happen either within the OSS/BSS or outside it.  We can already see that operators like AT&T and Verizon have acknowledged that limited-scope NFV orchestration wasn’t enough; their models are based on multi-layered orchestration.  Interestingly, their models seem to live below the OSS/BSS.

And that’s where the solution may end up.  While it would be possible, even logical, to build orchestration and service modeling into an OSS/BSS, the OSS/BSS (and CIO) disconnect from initiatives like SDN and NFV make it harder to integrate high-level orchestration with emerging technical developments.

Fortunately, it’s also very possible to build modeling and orchestration outside the OSS/BSS, and to represent services to operations systems as virtual devices.  If that happens, then the future belongs to whatever activity ends up owning the service automation piece, and it wouldn’t be the current CIO group.  For that opportunity, though, the outside-the-OSS/BSS vendor would have to accept a challenge.

The difference in where the model lives could make a difference in how well the model can work.  Models that live inside the OSS/BSS can easily integrate operations processes, but to work they’d force the OSS/BSS to be aware of service lifecycle and resource conditions that are now typically handled by management software outside the OSS/BSS.  In contrast, service modeling below the OSS/BSS would preserve the current “virtual-device” mechanism for making OSS/BSS systems aware of the network, and potentially make it easy to integrate management processes, but harder to automate the OSS/BSS.

Logically, the only good solution to service modeling is to require that both management and operations processes be presented via an API and then be orchestrated into state/event handling that’s defined in the service model, wherever it lives.  If you do that, then you really support a third option for service modeling, an option where it forms a boundary layer between “management” and “operations” and composes both.

To make this sort of thing work, you first need a broad and agile service modeling and orchestration strategy.  I believe that the boundary-layer approach, if optimal, would foreclose having layers of orchestration based on dissimilar modeling.  Such firm technology borders would invite breaking up the boundary function into things that had to be firmly on one side or the other of the operations/management DMZ.

The second thing you’d need is a standard API set to describe the model-to-process linkages.  We don’t have to demand that current interfaces be rewritten, only that they be adapted via a software design pattern to a standard API.  Eventually, I think that API would be accepted by vendors because operators would prefer it.

We could do all of this very quickly if a group of powerful players (vendors, operators, or both) got behind it.  Absent that kind of support, I think we’ll end up in this place eventually, but only after wasting half-a-decade in diddling.  During which investment in infrastructure and vendor revenues are likely to suffer.

If I were a network equipment vendor I’d be jumping on this approach with every resource I could bring to bear.  It would take the pressure off my sales and reduce the threat that SDN or NFV (or both) would permanently reduce my total addressable market.  If I were a server vendor I’d be jumping on it too, because to control the hosting opportunity I have to control the overall business case, and that business case is established by the boundary-layer approach.

The key point to remember here is that the business case isn’t going to be established any other way.  We know now, if we look at the work of the last four years objectively, that there is no way that SDN or NFV are going to make a business case without the largest contribution coming from service lifecycle automation.  Without some unification of management and operations processes for service lifecycle automation, that maximum contribution isn’t possible.

If there is a winner in the sad commoditization of networking, it’s surely Huawei.  Their sales have climbed steadily as everyone else struggles or ties into narrow market niches.  They’ve won a lot of battles in legacy networking, but that doesn’t mean it’s all beer and roses from here on.  Three reports of their Operations Transformation Summit that Light Reading cited HERE, HERE, and HERE show that all vendors (even Huawei) have threats, and also opportunities to exploit new areas.  Most of all, they show that the industry is slowly realizing that we have a long way to go to “transformation”.

SDN and NFV are the big news in network technology, promising a whole series of benefits but posing a pretty significant infrastructure churn as the price.  The theory of both is that the old model of networking, based on switches and routers and devices in general, would be displaced by a server-hosted model.  Since Huawei is clearly winning (and winning big) with the old model, it might be surprising that they’ve also been pushing transformation to something new.

So have other vendors, of course.  Cisco, Nokia, Ericsson, Juniper…almost every network equipment vendor you can name has talked transformation that was really a substitution of software functionality for hardware.  The dualism of their positioning has frustrated me for sure, because it seems like they’ve been blowing kisses at change while hoping it will just go away.  Network operators have been telling me for a year that they are also frustrated with the wishy-washy positioning of their suppliers.  The first of the two Light Reading references, from an event Huawei hosted, shows that even Huawei is the target of criticism for their lack of a decisive stand—by some of their customers.

If you read this blog regularly, you know that this week I’ve done some blogs that add up to recommending a shift of direction.  There is a current challenge for operators, a challenge of a shrinking gap between revenue per bit and cost per bit.  SDN and NFV were supposed to reopen the gap, but I’m now of the view that can’t happen in time.  My proposal is to forget infrastructure transformation as a solution to the current critical problem, and focus instead on operations transformation.  That will get operators over the hump, and fund the next step, which is to address the transformation of services from dumb connectivity to smart experiences.  To do that, you focus not on SDN and NFV but on the carrier cloud.

This leads us to the second story out of the conference, which talks about the debut of the OPEN-O initiative.  OPEN-O is seen by many as simply a competitor of Open Source MANO (OSM), but Huawei speaker Joe Hou says that “OSM is focused on MANO and NFV, whereas OPEN-O covers cloud and the data center as well.”  Would it then be fair to say that OPEN-O differs in that it offers at least partial support for carrier cloud?

I think this issue of a cloud transition point is the core of the frustration that operators feel.  No operator I’ve ever talked with actually wants to transform infrastructure—it’s too expensive and presents too much risk.  What they’d really like is to transform costs and revenues without having to do a lot of infrastructure fork-lifting.  The goal of OPEN-O, which the article says is “helping telcos shorten time-to-market for new service provisioning from an average of between six and eight weeks to just one week,” could also be said to address service lifecycle automation.  Since that could transform costs without fork-lifting, and since OPEN-O is also aimed at cloud orchestration and could then transform the revenue side, it’s a nice positioning.

To get to our final story, Vodafone says that it has aggressive plans to virtualize its networks but that vendors overall need to step up their development of NFV.  This isn’t the first time that operators have said that, and I’ve certainly said that NFV vendors have generally been dawdling, but I think that there’s a dangerous risk here of mistaking motion for progress.

Vodafone, like most operators, has been vague about just what functions it’s targeting, so the notion that they’d like to have 60% of them virtualized by 2020 lacks as much specificity as the vendor strategies to help achieve that goal.  There are a lot of detailed issues about NFV support, integration, the pricing of VNFs, and so forth.  There’s also a bigger issue, which is whether any of that would matter even if it were resolved.  We still lack any firm and sensible framework for service lifecycle automation, and absent that we have no way of validating even a single dollar’s worth of savings.

So, let’s circle back to that point of software and hardware.  Every vendor has software, even hardware vendors, and obviously network operators aren’t asking vendors to drop hardware for software, or the other way around.  I think what they’re asking is for a vision to deploy to.  How do virtualized things, meaning hosted features/functions, play in the network of the future?  They won’t do everything; anyone who thinks that general-purpose technology will push photons in transport applications is dreaming.

Another Light Reading story, I think, offers further clarity.  Vodafone, here, is saying that you’d need features developed for the cloud, from the ground up, to fulfill the promise of virtualization.  I agree with this too; I think it’s another way of saying that virtual network functions (VNFs) have to be built to a specific cloud-middleware or platform-as-a-service API set, which I’ve called “NFVPaaS”.  NFVPaaS would be an element in a vision of a software architecture for the network of the future.

We need a strong focus on service and network management lifecycle automation, right now, to address profit compression.  We need a vision of functions virtualization that can step off from that first step and define what SDN and NFV and the cloud combine to create.  Without it, operators are forced to invest in technology today without knowing whether the initiatives they’re supporting as they make their purchases will obsolete what they’re trying to buy.  That’s certainly something to complain about.

A popular song of my youth was “How Deep is the Ocean, How High is the Sky?”  We may be adding another semantically related question to that list, which is “How High is the Top?”  Top-down planning for technology change has always been a favorite notion of mine, and we’re now starting to wonder as an industry just how high that top might be.

This isn’t a topic of idle interest.  There’s a fundamental question here, one argued for decades in the tech world.  Do new products and services create new social/behavioral patterns and shape demand, or does demand shape the new products and services?  If the former is true, then you can start with demand goals and work products/services to align.  If the latter is true, then you’ll have to actually analyze demand shifts in order to form product/service policies.

What’s true in networking?  From a networking perspective, you can argue either way.  The Internet, surely the most revolutionary development of our time, was technology/service-driven.  There was no demand for the Internet, even after the Web came along.  The service was a fulfillment of an operator goal, which was advancing the consumer from limited-value voice services to something else.  Smartphones were a savvy assessment of the way mobile demand would evolve.

How should we assess the “top” of the technologies that we’re looking to as drivers or the future of networking?  Overall, I’d say that we’ve stumbled on a course that doesn’t accept either of these two models.  Instead, we’re assuming a third—the future is a lower-cost version of the past.

You could argue that this model overlaps both the others.  The presumption of SDN and NFV and even the cloud is that they could lower service costs, perhaps dramatically.  If that savings were applied to improving return on infrastructure, it could facilitate a build-out of new infrastructure that could then support new models of consumption.  If it were applied to lowering prices, it could stimulate new applications directly.  Two tops in one.

I think that a cost-reduction transformation overlaps the other approaches to setting the top in impact terms, but it also sets a different top of its own.  Here the key is to start by identifying the costs you’re targeting, which should be large in comparison to the investment/impact of your solution.  I blogged this week (and earlier too) arguing that opex reduction through software modeling, orchestration, and automation was the logical place to start.  One reason is that it could address the immediate problem of infrastructure profit compression, obviously essential if you want to spend more on a service-level transformation.

Getting to that service-level transformation is the next logical step.  Operators have also always promoted “service agility” as a goal, which is a nice way of saying that you’d make more money by being able to accelerate the full-service lifecycle—from market plans to deployment of customers.  It’s at that point that we have to jump off the cost-reducing top, and land somewhere on one of the other revenue-augmenting paths.

The big problem with new revenue from new services is squaring the new-service notion with the buyers’ own priorities, which (no surprise) are also largely cost-targeted.  When I last surveyed enterprises on this point less than a year ago there was no statistically significant interest in any new telecom service that didn’t lower costs.  That would mean that all the hype about dialing up bandwidth increases or selling virtual CPE is just that—hype.  It also means that future revenue gains will have to come from selling not different forms of the same stuff, but different stuff.

What do buyers want in the way of new services?  They respond with a laundry list of stuff that all boils down to two points of focus.  Some want new over-the-top services, meaning services modeled on what OTTs would deliver today.  Others say that if you want to augment today’s telecom/connection services, do so by composing application features into them instead of network features.  In either case, it would be fair to say that they want delivered experiences, not delivered bits.

The compelling thing about this point is that such services would look more like cloud computing than like NFV or SDN.  Google, who has been very open about its own network evolution and structure, clearly sees the goal of the network as “feature delivery” and sees the network as a cloud.  To me, that raises a very critical point about our pathway to transformation.

There is nothing we can do to add “telecom or VPN service features” to connectivity that will move the ball for network operators overall.  Repeat, nothing.  There are a lot of things that could add revenue above those basic service features, but they’d look like application elements or OTT services hosted using the cloud.  Thus, we should be talking about transformation’s “service agility” dimension only in cloud computing terms.  Carrier cloud is the goal, the top.  Everything else is either a step toward it or a detour into financial waste.

I said before that you could achieve opex savings galore without changing out a dollar’s worth of infrastructure.  You simply model services formally with something like TOSCA, and use the models to integrate operations and management tasks and automate their completion.  Think of this as a kind of hybrid of the cloud notion of DevOps and what we could call “ServOps”.

This doesn’t mean we don’t do SDN or NFV.  Google, who’s my poster-child for the right approach to “next-gen” services, uses SDN extensively.  What it does mean is that both SDN and NFV have to be focused very specifically on creating value for the carrier cloud.  We’ve not done enough to either technology to optimize that mission, and in the case of NFV we’ve done a lot that has no relevance to it.

That raises the inevitable “What now, then?” question.  Carrier cloud cannot emerge from SDN-driven modernization of facilities, nor can it emerge from NFV’s prevailing model of virtual CPE.  We’re not going to churn out current wireless infrastructure; too much displaced cost.  That means that it’s probably going to stand or fall based on 5G deployment, and that in turn means we’re not going to get anywhere until slightly beyond 2020.

The timeline gets us back to one of the earlier points; we need to introduce effective and pervasive software automation of the service lifecycle, and do it quickly to sustain operator investment in infrastructure.  We also need to stop thinking about SDN and NFV in terms of what they do for services, and focus entirely on what they do for the carrier cloud.  That’s not going to be hard for SDN, but for NFV we have a challenge (of ETSI’s own making).  We should forget most of what’s been done and focus on the question of how useful carrier-cloud services would modify prevailing cloud tools, tools like OpenStack.  That’s right; all of our NFV activity should be looked on as exploiting, modifying, and supporting traditional cloud deployment.  Why?  Because nothing else will help.

Ironically, this could help vendors.  There’s far less pressure to revolutionize connection infrastructure under this model, and far more pressure to revolutionize operations and to prepare a model of cloud computing that’s more agile, better connected, more distributed.  Think Google’s model.  Which, of course, is what we should have been doing all along.

One consequence of commoditization is consolidation, and since networking is clearly commoditizing it’s not surprising that we’ve seen a wave of M&A.  The most recent M&A rumor is that Brocade is for sale, and that Broadcom is a likely buyer.  The obvious question is whether the move would be a good one for both companies.  The less obvious one is whether there’s a broader industry meaning here.

Brocade has three rather distinct businesses, the SAN business was their original space, and they expanded into network hardware by buying Foundry and into network software with the acquisition of Vyatta.  SAN growth has been limited, and network hardware has been under pressure both in the enterprise and service provider spaces.  Hosted routing and network virtualization would clearly be the space where Brocade’s value would have to be established, unless you believe in a miraculous transformation of market conditions.

Network virtualization, and specifically the transformation of networks from appliances to hosted features, has gotten a lot of ink with the SDN and NFV initiatives.  Brocade got an early credibility boost in my surveys of strategic influence when they told operators that NFV was really a data center story.  Hosting equals data center: clearly true.  Anyway, they took the biggest upward jump my survey of operators had ever recorded.  Within six months, most of it was gone.  Within a year, it was all gone.

There were two issues that were responsible for the rise-and-back phenomena.  One was that while software hosting of router instances was inherently attractive to operators (as NFV was for functions overall), it became clear pretty quickly that there was a whole ecosystem of stuff associated with a transformation of this sort.  Operators wanted to hear about all of that ecosystem and how to resolve all the issues, and Brocade didn’t talk about it.  The other was that in truth, NFV wasn’t about router function hosting as much as “higher-layer” function hosting.  That offered Brocade a possible benefit and a risk, and the latter is what they (probably inadvertently or by default) selected.

You don’t need NFV to do router hosting.  Most network applications of virtual routers would tend to place them in static locations, so certainly hosted router networks would look more like cloud applications than NFV applications.  Brocade could have jumped on this point to get some early traction.

The second point is that if you have a rational vision of SDN, you’d see it as providing agile transport or virtual-wire services to a network that still did traditional routing/switching.  Again, this model of network-building would have been able to proceed without NFV standards sanction, and it could support the SDN work already done.  Brocade could have jumped on this to get long-term traction.

They didn’t jump, and in the eyes of the network operators they still haven’t.  Thus, the rise and fall of strategic influence.  But all the potential traction sources are still out there, and this year Brocade bought StackStorm to at least address cloud/virtual networking in a sense.

What then about Broadcom?  This is a chip vendor, after all.  To become a product vendor, wouldn’t they face a big problem of what’s popularly called “channel conflict?”  That’s when either your business plan collides with your partners instead of supporting them, or your partners collide with each other.  If Broadcom became a network equipment vendor, would that make other vendors less likely to incorporate Broadcom chips?  Well, it’s hard to see how it would help the relationship.

But that doesn’t mean Broadcom couldn’t find a reason to buy Brocade.  We are in an age of “semiconductor activism”.  Look at Intel, who bought Wind River and who has been extremely active pushing things like NFV.  They do that because they believe that the traditional providers of hardware are not maximizing opportunity for chip sales.  That means they think hardware vendors are hunkered down and protecting current markets while revolutionary opportunities rot on the vine.

Broadcom buying Vyatta would be a classic mimicry of the Intel/Wind River move translated into the network device/equipment space.  Of course, Brocade already bought them.  Thus, Broadcom would have to buy Brocade, or someone else who has convincing assets in the network space.  Might Broadcom reason that if Brocade saw a big jump in their strategic influence based on technology assets they didn’t follow up with, Broadcom could follow up after the M&A?  Might Broadcom see an opportunity to link these software assets more tightly with their chips?  Sure might.

A strategy to position Brocade’s assets would be a necessary condition for making an acquisition a success for Broadcom, but would it be a sufficient condition?  Unless something was done to recoup the lost influence, it would not be.  To make things more complicated, that “something” couldn’t be just picking up the pieces of 2013 positioning.  Time marches on.  NFV doesn’t have the cache it once had.  Where there was a big upswing of interest and potential back in 2013, the whole market is now slowly declining into capex starvation.

Which leaves two possible Broadcom motives.  Motive One: It’s my best shot.  The Titanic sunk, and there’s a small box floating nearby.  It’s clearly not the Carpathia, but it’s better than treading water.  Motive Two: I think I can assemble enough of the total value proposition to offer it to the end-buyer, and perhaps inspire some of my chip customers to get into the race as well.

I think the best-shot angle presumes a level of desperation that I can’t see Broadcom having reached.  They have a good business and no current threat seems to justify doing a big M&A just to grab a floating box.  So, they have to assemble the total value proposition.

That’s a logical conclusion but not an easy one to implement.  Frankly, Intel (even with Wind River) hasn’t done what’s needed to drive their own hosting-of-functions opportunity.  If they acquire Brocade, Broadcom will have to do better, and perhaps with less in-house expertise on just what has to be done.  But the opportunity remains untapped by others, so they’d have a chance.

Ciena made a very interesting announcement this week, one that combines agile optics with software automation and intelligence.  WaveLogic AI is a programmable chip/module that adds considerable capacity and agility to Ciena’s inventory, and opens the possibility for extensive software automation at the optical level.  Given that Ciena has one of a very few totally capable orchestration platforms in Blue Planet, this could be very interesting.

WaveLogic AI brings capacity agility and reach in combination.  At metro distances, you can get anything from 100G to 400G in 50G increments per lambda (per wavelength of light carrier), and for backbone distances you can go up to 300G.  With lower 200G capacity you can push out to over 8,000 miles.  All of this comes with greater density and with low-level telemetry on the data stream to facilitate software decisions on route and capacity management.  The density and capacity combination would be pretty compelling by itself, and adding in the agility and detailed telemetry dimension could make it totally game-changing.

Two related things make this harder to assess in detail.  First, this is a chip announcement not a product announcement, so the specific way Ciena plans to use it aren’t completely clear.  Second, a lot of the benefits of WaveLogic AI depend on having the software intelligence to back it up.  That’s hard to judge without the product context, and doubly so when Ciena hasn’t really provided a super-strong link between Blue Planet software and the SDN/optical layer.

There are applications for 100-400G metro already, in areas like DCI and probably even in CDN.  It’s probable that 5G could consume it when it deploys, at least in the denser metro areas, and for sure NFV could use it as a link between cloud data centers.  In fact, my models say that almost all NFV DCI would end up at the high end of the range.  The question is whether these applications could really demand agility, and if so whether WaveLogic AI could meet the demands.

Carrier-internal stuff like NFV or CDN applications probably couldn’t benefit much from agility because if you’re going to allocate a lambda to a connection like that, you’d go for whatever it could carry.  There’d be no benefit to throttling down.  The application of the agility feature would come where either you’re offering a customer connection service or where you’re aggregating customer connection services with other stuff.  That’s a key point because this kind of aggregation could come only if you have services that are packet-multiplexed first then committed to an optical route.  Which means hybrid optical-electrical planning.

There are not going to be a whole lot of applications that can justify a dedicated lambda, and so the value of WaveLogic AI’s agility would come primarily in applications that offer aggregated routes, which means routes between electrical-layer (L2/L3) devices.  The question is how often transport-layer capacity agility would benefit these applications, and what would magnify the benefits.

If a lambda is used to transport several routes in parallel, then it’s very possible that the offered load of electrical-layer combination would vary depending on just how each route was being used.  However, the condition would occur only if you had what I’ll call “switched” optical traffic on the route.  If we had a series of routers all linked with lambdas, I can’t see why it wouldn’t make sense to just run them all at full capacity.  The electrical-layer device is doing all the multiplexing.  If we have several trans-switched routes, it’s a different story because the traffic on each of them is controlled by something different at the electrical layer.

This is why I’d have liked to see a product instantiation with the announcement.  If Ciena were to pair WaveLogic AI with something like OpenFlow forwarding at the electrical layer, they could create transit routes with SDN that could then link two L2/L3 devices across a bunch of optical switches.  Now, traffic conditions on any of the optical paths could benefit from agile capacity assignment.  It’s my view that without some tie with an electrical-layer route overlay that creates a virtual wire for L2/L3 devices to use, it will be hard to gain full benefit of all the WaveLogic AI features.

The other point, the Blue Planet linkage, relates directly to the virtual wire theme.  Yes, you could sell a “lambda buyer” elastic capacity that linked WaveLogic AI features directly to that customer’s service parameters.  However, few are going to buy a whole lambda.  For other agility applications, you have to assume that network management or traffic engineering is somehow altering the virtual wires and thus impacting the capacity requirement of the underlying lambdas.  This is the role of a high-level management system, which Blue Planet could certainly be.

When Ciena made their big Blue Planet announcement, one of my comments was that I didn’t see the tie-in I expected between Blue Planet and transport networking, which would include both optics and virtual-wires like OpenFlow could create.  I still don’t see that link being presented effectively, and so I’m not sure just how much Ciena has developed the notion of agile topology and capacity as a vertically integrated feature of the transport layer.  Without an explicit link to a high-level model, a link that’s then percolated downward to the optical layer, you’re left with agile capacity applications on a per-customer basis, which won’t sell the feature to many operators.

Link-level telemetry, which WaveLogic AI includes, seems clearly aimed at supporting higher-level route and capacity management decisions.  Without a product context to show the feature off, and without specific Blue Planet integration through the notion of virtual-wire routes mapped flexibly to lambdas, these features are just features when they need to be valuable features to differentiate Ciena.

Now that they’ve put this out, Ciena has to make WaveLogic AI valuable, which means that it has to validate the features they’ve chosen to include and emphasize.  If you strip out the agility and the link-level telemetry you’re left with a 400G high-density optical modem.  You could probably get that at a lower cost without the features.  That means Ciena has to quickly step up and defend its feature decisions, and to me that means announcing a compelling transport architecture that builds on them through virtual-wire services and integrated multi-layer capacity and topology management.  They need that, and a product context for it, quickly or they risk a competitor jumping into the voids they’ve left and taking control of the space.