Month: August 2013

It should be clear to everyone in networking this week that the industry is moving to a very different place.  There was a time when the limiting factor in entertainment, communications, and empowerment was delivery.  We spent like sailors (as they say) to get better delivery because we had a business case for what we could deliver and it was hampered by the limits of network capacity and connectivity.  Practically nobody bothered with a strict business case.  I remember when financial analysts valued an Internet customer at $50 thousand, and valued Internet companies by multiplying that by the subscriber base.  The good old days.

This morning on one of the financial channels, a tech markets specialist was talking about an interview with Cisco’s CEO, and he commented that he didn’t understand how Cisco harmonized the fact that the industry was supposed to be getting better according to Chambers, but oh by the way we’re cutting staff.  I think the answer is pretty clear; Cisco knows darn straight well that the industry’s not going to sustain their growth expectations.  Business cases have caught up with networking…with tech, in fact.

We are starting to see in networking what we’re seeing in computers, which is an exhaustion of the value proposition for further investment.  Clearly we’re not going to toss servers out and go back to high stools and accountants wearing green eye shades pouring over ledgers, but we are already looking for cheaper servers just as Chambers is looking for lower human costs at Cisco.  ROI is the ratio between return and investment, and if you can’t eke out any more return you’ve got only one way to make ROI better.

In the computer space, we heard this week that Dell had gained on both IBM and HP, increasing its server sales when rivals saw theirs dropping.  I think that underneath all the disorder created by potential going-private or getting raided, Dell is facing the transformation in computing as well as anyone could.  In fact, in some ways, the current mess sets Dell up with some ashes from which its Phoenix can rise.  All they need to do is to face the future squarely.

Which is what?  In my terms, it’s the “supercloud”, an architecture for computing, networking, service creation, service delivery, that focuses on agility through virtualization.  Right now, we as an industry are stuck in conventionalism.  It’s like giving a kid a chance to play doctor, or lawyer, or police officer or maybe soldier, and they decide to play “wage slave” instead.  What good is imagination if all you can do with it is replicate the current reality?  Cloud computing, SDN, NFV are all simply applications of virtualization, the realization of flexibility through the creation of a dynamic system of “abstraction-creation” and a generalized way of converting abstractions into reality by making dynamic resource assignments.  That’s what we should be doing, and we’re not.

The cloud lowers costs, they say.  SDN lowers costs, they say.  NFV will lower costs, they say.  All this lowering is just cutting the heart out of the industry, and for no reason.  We have, by my reckoning, almost three trillion dollars per year of available benefits to harness.  Dell, I think, sees that pie (or a piece of it) and is thinking about how to get it.  Who, in networking, can say the same?

Ironically, the vendors that seem to have the best grasp of the current reality are the vendors who for one reason or another would seem the least likely to have any grasp at all.  Alcatel-Lucent is a company that’s struggled with multiple personality disorder from its formation, and that’s never been able to tell an exciting story except maybe over a drink.  Huawei is a company who’s going to win in the current networking game because all its competitors are too dull to recognize that if there is no revolution in networking’s future, the future will be price-based commoditization that only Huawei can hope to win.  That Huawei is already winning.  Yet Alcatel-Lucent has taken some concrete steps toward the supercloud model with CloudBand, and Huawei is really looking at software-defining the network.

Network operators believe in the supercloud concept even if they’d not likely call it that.  They believe that by moving away from static appliances into virtual elements they can improve agility and service creation, and thus address opportunities faster and better.  They believe that the OTTs have nothing on them except the ability to exploit “free” services, and ad sponsorship is both not-free and inherently limited.  The whole global advertising budget is about one quarter of that available revenue upside for the industry.  Operators know how to sell services; OTTs know how to give them away.  In the end, which model wins?

I think the industry could have an exciting future, but as long as enterprises have the CIO reporting to the CFO instead of the CEO and as long as “transformation” means radical cost-cutting, we’re not going to reach it.  And this is the fault of the vendors, because there has never been a free market that succeeded by demanding that the buyer go out and evangelize to convince the seller to produce something.  Innovation, revolution, doesn’t work by demanding buyer risks.  Watch “Jobs” if you don’t agree with that.

People tell me that SDN isn’t going to work, and I agree.  Same for NFV, and for the cloud.  But my agreement isn’t based on a conviction that these concepts can’t work, but on the conviction that the goal we’ve set for them—the goal of wringing some pathetic chump change from re-execution of the tired junk we’ve relied on for decades—can never inspire the market.  We have tied virtualization, as a concept, to a tree and then criticized it for not getting around.  Well, we’re the problem here, and so we as an industry have got to fix it by fixing ourselves.

Well, if you thought that a telecom spending spree or an enterprise market flush with unexpected cash were going to drive Cisco and the industry to unprecedented growth, Cisco’s call likely disabused you of that notion.  While Cisco beat most estimates very slightly, its guidance was considered tepid and certainly the continued references to “challenging macroeconomic environment” on the call didn’t boost confidence.

Telecom spending is certainly ramping up a bit, and mobile is the biggest focus of that incremental spending and Cisco’s gains in mobile infrastructure are consistent with the market reality that you invest where you get the biggest return.  Enterprise spending is down a bit, and that’s consistent with the fact that networking has become a cost center and not an opportunity at the enterprise level.  Cisco’s success with UCS was impressive, but as I said yesterday it’s not enough to pick the low apples of server opportunity here.  Cisco needs to drive the bus to the future, not ride along as a passenger.

An area I think is a missed-so-far opportunity is metro.  Yes, it’s true that mobile gets the lion’s share of investment but mobile investment is transforming metro networking.  There are at least twenty to 100 times as many mobile POPs in a metro as there are wireline POPs, and with LTE each of these will have more data feed than a whole CO did fifteen years ago.  Seamless handoff between WiFi and LTE also create changes in topology, and CDN evolution is pushing caching out toward the edge.  What we need is a new metro infrastructure where all of the services that we create for mobile and content are created virtually from a mixture of SDN and NFV technologies.  I’m talking about “MaaS” or “Metro as a Service”, in effect.  If Cisco is doing well in mobile, they need to be talking MaaS to leverage that success.

The data center is another example.  Even leaving the cloud aside for the moment, we have this data-center-as-a-service thing going on in the media, which is for the most part vacuous hype and nonsense.  Underneath it, though (as is the case with most vacuous hype) is a kernel of truth that could be profound if anyone took the time and effort to deal with it.  We need to be thinking about a future where security, access rights, application coupling, big data, governance, business policies, and all that good stuff are attributes of the platform and not glue-on-and-hope-it-works extensions.  We need to replace data busses with knowledge busses, replace “big data” with “big insights”.  We’ve gotten so used to the idea of managing complexity that we’re risking slipping into creating more of it just so it can be managed.  The network is a necessary arbiter of information exchange, an element in every horizontal and vertical flow and every IT-driven productivity process.  Cisco is in a strong position to make a name for itself by creating DCaaS that means something.

And then, of course, there’s the cloud.  Let me spell things out for you here, Mister Chambers.  If you look at all of the things that could drive cloud data center deployment incremental to current deployments the only one that sticks its head above the statistical noise level is Network Functions Virtualization.  When we run our model on this, as I’ve said before, we find that an optimum NFV deployment would add between 14 thousand and 35 thousand metro-cloud data centers (small to mid-sized to be sure, but still data centers) in the US alone, about three times that globally.  If you want to succeed in the cloud, all you’d need to do is to win big in the optimum NFV space and you’re there.

Cisco has an NFV strategy they’ve been quietly developing in dialogs with Tier One carriers.  They need to expand it, to embrace the full potential of function hosting not only for the current services built on current middle-box technology but also for future services where there are no current box models to draw on.  The wonder of virtualization as an abstraction/instantiation process is that you can create new abstractions and instantiate them with many of the components you already have.  That would provide service agility to operators, and better top-line growth.  Top-line growth equates to bottom-line cost tolerance—more spending on infrastructure.

Cisco knows about cost management.  They’re cutting 4 thousand jobs to improve their profits in a market where they believe they can’t raise revenues enough to provide the needed boost.  Why would they think their operator or enterprise customers are dancing to a different financial drummer?  Don’t they also have to face quarterly calls?  Won’t they respond to a lack of convincing revenue growth by cutting costs, and isn’t buying Cisco gear a “cost” to those buyers?  It’s time to pull your head out of the sand here.  Arguing that an Internet of Things or immersive telepresence or whatever is going to drive up traffic inexorably, and force operators to build out even at a loss, is as stupid as arguing that the need for employment drives Cisco to employ regardless of whether they can earn a profit on the result.

Networking is commoditizing, Mister Chambers.  Your buyers, in both the carrier and enterprise space, would be happy to spend more to get more return, but they won’t spend more while getting less.  It’s your responsibility, Cisco’s responsibility, to make it possible to justify more spending, and to justify it in a solid financially sensible way—the way you justify your own.

Cisco reports its earnings tonight, so you might wonder why I’d blog about Cisco before the Big Event.  The answer is that I’m not blogging about what Cisco did in the last quarter, but what it’s facing in 2014 (I may get to that last quarter on my blog on Thursday!)

Chambers has been very clear in his statements that Cisco’s future lies in becoming the top IT company, meaning that Cisco wants to grow out beyond networking.  Its UCS servers have in fact been very instrumental in placing Cisco in the forefront of the cloud revolution, and certainly they’ve helped Cisco expand its total addressable market (TAM).  The challenge Cisco faces is that servers aren’t enough.

According to my surveys, Cisco’s UCS successes have been in the best possible areas—network-related server applications like cloud computing.  That’s helped Cisco to gain market share in the server space by leveraging its network incumbency and also helped to sustain reasonable margins on its servers, no mean feat given that servers are commodities in the broad market.  The thing is, Cisco’s aspirations commonly lead to the statement that it wants to be the “next IBM”, and taken literally that would be a bad thing.  IBM is suffering now, suffering from loss of strategic engagement created in part by poor articulation and in part by the diminishing role of computer hardware.  Dell gained market share on both IBM and HP, demonstrating that servers don’t have the old-time strategic shine.  And servers, stripped of the Cisco cachet, are what UCS is.

I think that most of the smart strategists at Cisco—and there are many—realize that the “next IBM” path has to take Cisco through the cloud, not through the server.  In fact, cloud computing anonymizes servers because it virtualizes them.  However, “the cloud” can’t mean cloud stack software because the fact is that no new proprietary strategy has a ghost of a chance of competing with current cloud stacks.  Surely the cloud can’t mean “applications” to Cisco; they’d have to buy a bunch of companies to be credible.  So what does it mean?

One path, which Cisco has sort-of-taken with WebEx, is the “cloud-means-cloud-services” track.  Cisco’s biggest customers (network operators, government, and big enterprises) are generally happy to buy software as a service, and the former group would be happy to resell cloud-based services from others too.  The problem with cloud services is that margins on IaaS are very thin, PaaS is something for platform/OS providers to offer, and SaaS means you either have to own software or have a killer developer strategy.  I think this approach could ice some cloud cake if Cisco could get the lower layers baked, but it’s not going to fill the pan on its own.

Another path would be to look at the cloud-to-network boundary.  Software-defined networking is IMHO evolving into a two-layer architecture with a software connectivity framework on top and a hardware layer driven more by policy than by centralized controllers at the bottom.  Cisco has done a number of SDN-related acquisitions but it’s not really articulating a cohesive two-layer strategy at this point.  Might Cisco meld all its stuff into a new software-overlay model that’s designed from the first for this new two-layer SDN approach?  That would be a smart move in some ways.

The only problem with it is that any virtual-overlay model of SDN tends to make the underlay part, the hardware, into a commodity even faster than before.  If hardware is where you make your bucks, that’s not good news.  I think it’s possible to meld the layers to create a whole greater than the sum of the parts, but I don’t know whether Cisco would be willing to take the risk…I don’t know that I would if I were in their place.

That leaves the last approach, which is to create a cloud platform from the network side, what I’ve called a “supercloud”.   OS players have a lock on PaaS now because most PaaS is a step up the stack from bare metal, meaning bare server.  Why not think about PaaS as a step above bare resources in a more general way?  Extend both hosting and networking in a common model, with the features exposed as platform APIs?

This is a notion with some precedent; Alcatel-Lucent’s CloudBand is in fact a model like this, though the company doesn’t position it that way (at least in a public sense).  And if you look at CloudBand’s architecture you find a cloud-plus-network framework in another way—the Carrier Platform as a Service is an overlay on the cloud that adds additional network functionality.  That’s where Alcatel-Lucent proposes to host network functions virtualization, for example.

The fact that a competitor is doing something like this could be a stimulus for Cisco or a negative.  Cisco likes to be a “fast follower” rather than a leader, letting others take the big risks, but they also don’t like to look like they’re embracing a competitor’s approach.  Alcatel-Lucent doesn’t represent any major threat to Cisco’s core router/switching business (nobody does) but they are a force to be reckoned with in the carrier space.

What might bring Cisco’s ultimate plan out into the open is NFV, and in particular the proof-of-concept initiative that’s developing in the NFV ISG itself.  PoCs aren’t supposed to be competitive, they’re supposed to validate or refine elements of the NFV specification process.  But it’s hard to see how a highly visible and highly credible PoC from a big network vendor wouldn’t be a standard against which other vendors would be judged.  Can Cisco keep its own approaches under wraps if somebody like Alcatel-Lucent jumps out and does something highly credible?  And remember, CloudBand is already an NFV platform as well as a platform for SaaS.

Cisco needs to make a move here, and soon.  There are only a few opportunities to grab onto a credible “supercloud” mission, and other little grasping fingers are already brushing the prize.

We have a bit of an interesting counterpoint story this morning, involving the future of networking and how we navigate transitions.  Let’s open with Blackberry, who has announced they will be forming an activity to seek bids for JVs, acquisitions, or whatever.

Blackberry was the darling of the mobile phone space prior to the iPhone, and while it’s tempting to think that what won for Apple and lost for Blackberry was the coolness, the truth is that Apple won because they realized that the smartphone market would be won by somebody who could sell the phones to consumers.  A mass market, when it exists, subsumes all the specialized markets, and iPhone success drive Blackberry out of its little niche.

I think everyone realizes now that the right move for Blackberry was to be more aggressive in the consumer space; in fact, they should have realized all along that this sort of thing would happen and even realize who’d be the player likely to make the move.  Instead, Blackberry (RIM, then) hunkered down to defend its old position and withered there.

We now have a similar transition going on in networking.  There was a time when a third of all network revenue was attributed to business services and when businesses were the only consumer of broadband.  A typical T1 access connection (one end, not including the interexchange part) cost about nine hundred bucks per month.  Now we have services in the hundreds of megabits per second for a fraction of that price.  Networking overall has gone mass-market.

Business networking was about connectivity, and consumer networking is about experience delivery.  Everyone knows that if you’re getting something delivered, all you care about is that it gets there in one piece, and it follows that experience networking doesn’t offer a lot of opportunity for differentiation for the delivery part.  Bits are bits—ones and zeros, so differentiate that!  But it also follows that if experiences are what you care about, producing them is where the money is, and will be.

This is what’s driving the business of networking.  We are in an era where what matters is cheap transport and valuable experiences.  That’s what the revolution to the real “next-generation network” will have to contend with.  Produce bits as cheaply as possible and then toss them out like Johnny Appleseed to pave the way for profitable overlays.  The telcos, like RIM, made a mistake by not realizing this and grabbing some of those profitable overlays when they had the chance.

For the network vendors, the people who make money pushing bits, we’re at a similar crossroads.  The bits get cheaper and the experiences get better in our future, so you can try to capitalize on either or both of these moves.  The embodiment of the trends that impact these two directions are the concepts we call SDN and NFV.  Vendors have to accept that one or both these options will dominate their future, or they go the way of RIM.

SDN is IMHO a pure defense, a bet that commoditizing bits will provide a mechanism to retool networks to simplify operations and so reduce its cost, and also to specificize services to the exact connection model needed for delivery, tossing out the more generic architectures of IP and Ethernet communities that have dominated our thinking for decades.  I don’t disagree that it could be something that helps some vendors gain market share, but it’s still a less-than-zero-sum game here.  The bit-pushing pie is going to get smaller over time, more dominated by cost-based leaders like Huawei.  If you’re honest with yourself you can see this already.

NFV is more complicated.  Yes, the initial Call for Action white paper issued nearly a year ago was all about cutting costs by substituting general-purpose servers for more expensive appliances, but I think the founding operators knew all along that the architecture that hosted the virtual functions could rule the world later on, so to speak.  NFV is the potential union of all the networking concepts of the modern age, all directed at framing that elusive NGN model.  Whoever wins in NFV wins in NGN.

So who is that?  A recent report suggests it will be Cisco and NSN, but I’m not convinced.  Cisco does have the best inventory of NFV-related assets because it has (alone among the major network vendors) a strong server position.  But even a strong server position isn’t a durable asset in an initiative that’s targeting commercial off-the-shelf servers.  Cisco is going to get a RIM-like lead in the NFV space, an opportunity to shape its total vision based on a unique and early access to a subset of the market.  We don’t know how to do NFV now, and somebody with all the pieces that could be used might well figure it out.  But they still have to be able to exploit that knowledge in a durable, profitable way.  And they have a big problem, which is that network transformation always hurts the incumbent the most.  That’s why RIM thought they should stick their head in the sand with consumer smartphones.

Cisco shares that risk of overhanging old products with NSN.  NSN’s “Liquid” stuff is smart positioning, but it’s not SDN and its not NFV, and if NSN were to make a big thing out of either of these technologies it would lead it down a path that would demand more network equipment, some of the very stuff NSN has been shedding in fact.  NFV and SDN collide and cohabit in the metro, and NSN is more about mobile than metro.

Huawei is the Apple of networking, not because they have the consumer integration smarts but because they have the key asset in the network equipment space—cost leadership.  All they have to do is not-lose and they win.  For the rest of the vendors, the time has come to step up and take some proactive steps, before the Fate of RIM befalls them.

T-Mobile has been shaking up the mobile industry with its no-contract-and-phone-upgrades plans, and they’ve worked to gain post-pay customers for the carrier, not a first but certainly a recent first.  The problem is that this “good news” really isn’t more than a “transient good” because this model isn’t sustainable.

Suppose you’re in the milk business.  Milk is tough to differentiate on features and you don’t want a milk price war, so you decide to offer people a free glass with their milk, in return for their committing to buy from you for the next six months.  Your competitor will quickly match that, and maybe raise it to a two-glass set.  Next thing you know you’re offering a complete set of dishes and a table, and competitors are quickly matching every stride you take.  All that happens is that everyone’s profit margins go down the tube.

The answer, as we can likely see from this example, is to find a way to feature-differentiate what you’re actually selling.  As simple as this may seem, the telecom industry has done a truly awful job of facing the obvious, for a variety of reasons.  Biggest of these is that it takes time to find service differentiation, and operators are like every other business these days—focused on delivering the next quarter.  And network equipment vendors are in the same boat.

I talked to some sales people at some of the giant equipment vendors over the last month, and one thing I found interesting was that all of them said that their company was committed to strategic selling.  The problem was that they were also dedicated to meeting quota for the current period, and you get paid for the latter and not for the former.  Hint to sales managers:  Sales people sell what you commission them to sell, not what you tell them to sell.

Logically, the solution to this situation would be for vendors to build future service growth into current product sales, so that new stuff was suitable to build differentiation and ARPU.  The problem in that picture is that it’s extremely difficult to do much in the way of future-proofing at zero marginal cost.  With Huawei out there cutting margins for everyone as it is, who would want to go into a head-to-head with Huawei with a five or ten percent cost disadvantage created by adding features need in the future but not in the present?  Sounds like a gold-edged milk cap to me!

This is background for the whole SDN and NFV thing, IMHO.  Underneath it all, what operators are trying to do is transform their business model in a way that doesn’t require them to pay too much forward—they have to control “first cost” and return on infrastructure.  In the surveys I do, I see a clear signal that they want to transform in two phases—a phase that delivers next-gen infrastructure justified by current-period cost reduction, and another phase that exploits that infrastructure to create differentiated services.

SDN was a failure as a strategy here.  First, it doesn’t deliver revolutionary savings.  Second, it is a connection-plane model so it’s not going to create higher-level feature value-add, and at the end of the day pushing a bit with Technology A isn’t much different to the bit-pushee than it would be with Technology B.  Now the torch has been passed to NFV, and NFV has the advantage of being primarily an IT technology rather than a network technology.  You can say that it’s a “virtualization” approach, but it’s really more a software approach.  With NFV you say goodbye to boxes and run applications that replicate the features those boxes provided.  If you demand sanctioned, standardized, interfaces and functionality for each virtual element then it’s easy to play best-of-breed and lowest-price with competing vendors, so your costs are managed.  That’s where the first-phase benefit comes.

For the second phase, you’ve got to be more of a visionary.  The cloud is the future of IT, so the cloud is the future of NFV.  If NFV can create an architecture that can deploy and manage services created by cooperative virtual functions, it can deploy multi-component cloud computing applications, and hybrids of these two things.  This means that the operator gets a future-proof service layer as a byproduct of getting the benefits of capital cost reduction.  No first-cost risk any more.

Vendors, of course, are largely un-thrilled with this model.  While it’s possible that it might create as much or more trouble for Huawei as it does for the rest of the field, it creates a whole new host of competitors and it also eliminates the proprietary lock that appliance-based services tends to create.  At any rate, the vendors are all very careful to guard the boundaries of whatever NFV they’re thinking about in an attempt to protect what they have while chasing what their competitors might have.  But with NFV established as a common goal of network operators, can vendors ignore it?  The first guy who conforms gets an advantage, so in the end the vendors will follow along just like the other operators followed T-Mobile’s lead in plans and phones.

The challenge for NFV in meeting its goals, and those of the operators, is partly technical and partly procedural.  On the technical side, the management of this new “supercloud” is something out of the twilight zone in terms of issues and changes.  Attempts to solve the management problem of NFV infrastructure through traditional means risks compromising opex and the whole NFV business case.  On the procedural side, the big question is whether the ISG can sustain an open model at the three layers of NFV—the virtual network functions that replace appliances, the ecosystem that deploys and manages them, and the infrastructure they run on.  Implementations will be the final proof of this point, and we’ll likely see many more coming this fall.

NSN has changed ownership but not its name, it’s simply changed what the acronym decodes to.  “Nokia Solutions and Networks” is actually kind of appropriate at two levels.  First, obviously, it conveys Nokia’s sole ownership of the venture.  Second, it conveys that what NSN has been turning into is a “solutions” or professional services player.  By shedding more product lines, NSN has actually anticipated a general trend among the giant telecom vendors—spin off or sell off the low-margin stuff where you can’t differentiate on features and abandon those fields to Huawei or ZTE.

If you ran a plumbing supply store, you might find yourself with a mixture of pipes and fittings on which you earned maybe 15% gross margins, some fixtures like toilets that gave you 30% margins, and some gilt-edged toilet seats that delivered 100% margins.  You might also have an installation department that delivered 40% margins.  If customers were looking for one-stop shop, your profits on an overall plumbing job could be decent.  The problem comes when they start shopping around for all the pieces, acting as their own “general contractor”.  Then you’re forced to stop carrying the low-end stuff because you can’t compete on price, and that low-margin basement product set doesn’t pull through the good things.

The question is whether, once you’ve done this, you see enough deals.  When a customer wants a new toilet they likely want a new seat, and if you sell only seats they get used to seeing the guy who sells both seat and toilet.  They then go to that supplier when they need a seat alone.  The moral is that you can’t shed pieces of a natural ecosystem.  NSN wants to supply mobile technology, which at one level seems like an ecosystem but which is really a part of a larger system called “metro”.  That makes them vulnerable.

You probably know by now that I’m a champion of metro networking as the foundation for carrier spending and vendor opportunity, but I have a good reason.  First, everybody invests where they get return, and metro return is in some cases ten times core return.  Nearly all the profitable traffic operators carry never gets out of the metro network.  Second, metro is being transformed by ecosystemic pressure, which means that the combination of metro toilets and metro seats (so to speak) is highly valuable to buyers.

One ecosystemic pressure on metro is SDN, which is a technical response to the problem of low return on access bandwidth.  Operators want to flatten the OSI layers to reduce both capital and operations costs, and SDN offers a theoretical way of doing that.  I emphasize the “theoretical” because there have been few presentations of SDN that actually live up to potential.  Operators today tell me that there has been no significant improvement in metro economics other than the consistent reduction in unit cost we’ve seen all along.  Price is falling faster, so that’s not enough.

Another ecosystemic pressure on metro is created by NFV.  NFV is a kind of one-two punch in terms of impact.  In the near term, NFV evolution is justified by the reduction in capital spending on custom devices.  In the middle term, the key is the operationalization of cloud-hosted services and features, and in the long term it’s the agility that software-based networks offer in responding to market trends.  But whatever drives NFV deployment, the impact of it is to create a different style of metro network, almost an overlay or parallel structure.  The “metro cloud” is a highly meshed collection of NFV-justified data centers, some as small as perhaps a rack or two of gear and some large enough to change local weather.  Metro today is an aggregation network.  Further, this future metro cloud becomes the way that we deliver things like content and even the way we manage mobility.  There’s a continuous connection between it and the old aggregation structure, and that creates this highly dynamic ecosystem.  If you can supply the metro of the future, then you win.  You can supply the metro of the future if you can supply the key elements in the metro cloud.  The rest of the infrastructure is just those low-margin pipes and fittings.

So where does that leave NSN?  My view is that they believe that because mobile networking, meaning things like IMS and the RAN, are getting more capital attention than the rest of the network, they can leverage a mobile win and control enough accounts.  My view is different; NSN wants the toilet seat to pull through the toilet.  In order to gain conclusive control of metro without having all those cheap pipes and fittings, NSN has to command the metro cloud and that’s a very tall order for a company without a shred of cloud DNA.

Even that won’t be enough, though.  Anyone who has ever shopped for bathroom fixtures knows that advertising is a big part of any victory a seller might gain.  Nobody becomes a retail giant by building a store somewhere and then hoping people will stop in on their way by.  You have to draw people in, and that’s something network vendors are truly awful at in general, but that the Eurogiant vendors have been particularly bad at.  Does NSN have an SDN, NFV, and cloud position?  Not really; they said they were addressing “business issues first and technology issues second”.  The problem is that buyers in the metro space are looking for technology that transforms their business, and the NSN articulation seems to be a set of goals without any realizations (see http://www.lightreading.com/packet-core/nsn-unveils-its-technology-vision/240156505).

NSN didn’t change their acronym, and that’s a good thing for people like me who would otherwise struggle for six or more months getting used to a new name.  The real question is whether they changed anything, and that’s the question I now want them to answer…for me and for the market.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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