Month: August 2012

When Cisco announced its ONE architecture I was pleased that they were addressing the issue of higher-layer SDN intelligence.  As I blogged at the time, and as I still believe, there is no practical commercial conception of SDN possible absent a set of layers on top of the SDN controller to couple forwarding table entries to a true conception of a connection service.  Cisco took the lead in recognizing the need for this “higher vision” of SDN, and it was and is a good thing.

Then, apparently under some pressure from the “virtual networking” announcements related to Nicira and Xsigo being acquired, Cisco’s CTO Padmasree Warrior blogged a bit on SDN last week, and some of the comments she made left me confused, not about SDNs but about what Cisco plans for them.

First, Warrior implies that SDNs, network virtualization, and overlay networks are the same thing (“choose your favorite descriptor”) and I have to disagree.  Yes there are similarities; one of the properties of virtual networks is that connection behavior doesn’t map 1:1 with physical infrastructure connectivity.  VLANs and VPNs, in the best of the implementations, are segments of Ethernet and IP connectivity.  So is Nicira’s network virtualization, but I think there is a very fundamental difference, the difference between being on it and in it.

Overlay networks of any sort, including Nicira’s, inherit the properties of the underlying network as USERS OF THAT NETWORK would.  They can only present, in some form, what’s offered from below.  They’re “on it”, network-wise.  But if the virtualization strategy is recognized by the network nodes, embedded in the forwarding processes, it can be managed co-equally with normal network protocols, be given separate QoS, etc.  These protocols are “in it”, and so they are very different from overlay approaches.

Here’s an analogy.  Suppose I have a trucking company that runs a thousand trucks on a couple hundred routes, and my trucks carry containers.  I use some big trans-shipping centers to offload and reload trucks and route containers.  I can hub and spoke and get stuff to a bunch of destinations efficiently.

Somebody could create a “virtual trucking company” by buying containers and taking advantage of my trucks and routes and shipping centers.  They can serve fewer destinations, segment shipping zones differently, but they can’t go anywhere I don’t go or get there any faster than I do.  That’s an overlay strategy.  These guys are just shippers on my service like anyone else.

Somebody could also buy their own trucks and use the same shipping centers, but manage their loading and even their routing between centers differently.  They may have to run on the same roads as I do, but they run their own stuff at their own speed, prioritize trans-shipping in their own way.  They can build source-to-destination routes through different transit shipping points.  These guys aren’t overlays, they’re real.

The whole point of “software defined networking” is defining networking, and to most that means doing something to network behavior in a direct sense.  That, in turn, means having some way of controlling traffic handling, meaning forwarding.  Certainly OpenFlow does that, so it’s “in” the network.  I agree with Cisco’s assertion that other VPN and VLAN mechanisms that live at the forwarding level can also be made to respond to software control, but certainly OpenFlow has the same credentials, so it’s not the same as overlay networking or Nicira’s virtual networking.  You can’t pick your favorite descriptor if they don’t all describe the same thing.

Lumping SDNs with overlay tunnel segmentation may lead to the next problem I have, the blog’s characterization of the SDN goal as “network slicing” or “multi-tenancy”.  As I already noted, segmented connectivity is a property of virtual networking so you can do it with SDNs and OpenFlow.  Some of the research projects have focused on creating more flexible Level 2 partitioning as the blog points out.  But this isn’t the singular goal of SDN, nor is it the only application that’s been demonstrated.  SDN is about software control of virtual network services at any layer.  You can do that at Layer One or Two or Three, and even in a shim layer above it (the “overlay networks”).  Sure SDNs can create limitless segmentation in both Ethernet and IP, which is network slicing, but that’s not all.

SDNs can combine layers and simplify operations.  SDNs can mimic physical layers and help groom traffic in OTN.  They can eliminate discovery and autonomic route selection in favor of traffic managed central control.  They can build an IP core or a data center network, a CDN, or a cloud, and in all of these missions they can offer benefits incremental to vanilla IP and Ethernet.  And sure, maybe at some future point with the right components in place, SDNs could be built right on simple, cheap, switches that didn’t run traditional protocols at all.  This is the SDN fast lane, the place where it can be a distinctive value-add, and it’s not network slicing.  (If you’d like to view our three-part tutorial on SDN that includes commentary on the various deployment models that parallel and augment Ethernet and IP, click HERE for the first video in the series.)

It’s hard not to think that the blog’s point that SDNs don’t commoditize existing equipment isn’t the whole purpose of the exercise.  There’s been a lot of buzz around virtual networks, and perhaps Cisco thinks it has to put a stake in the ground.  And it’s true that overlay virtual networks don’t commoditize network equipment, and you can watch my Hangout on Nicira dealing with that very question of commoditization to see why.  But remember that SDN isn’t an overlay, it’s an “inlay”.  The no-commoditization conclusion leads from the false premise that SDNs are just overlay networks that support multi-tenancy.  That’s not what SDNs are.

So DO SDNs in their true sense commoditize network equipment?  The answer to that is both “no” and “yes”.  “No” in you can’t build a virtual network without a real network built from real devices.  It’s far from clear whether even in a decade SDNs will be built on anything other than traditional switches and routers, so don’t expect cheap SDN switches to sweep the market.  But “Yes” in the sense that SDN principles can draw valuable features out of both IP and Ethernet, reducing differentiation and thus commoditizing.  And they will if vendors don’t address SDN’s real value.

I’m not saying Cisco has no SDN strategy, has a totally cynical one, or has a bad one.  I’m just becoming concerned that it has a purely defensive one.  The question for Cisco has always been whether its support for the most general case of SDN (which is what they have done) would be offset by an internal resistance to adopting any of the more radical, revolutionary, and potentially compelling interpretations that grow out of that general case.  Is Cisco’s characterization of SDNs as “network slicing” true in Cisco’s vision, because they’ve painted a thin coat of “overlay” on a rich SDN tapestry?

Cisco didn’t step away from SDN in the blog.  They did step aside, into a kind of “SDN slow lane” that tries too hard to accommodate and preserve the present, and when you do that someone can get past you.  Somebody is going to do this right.  It could still be Cisco, but it’s hard to see why they’d take the stance the blog post takes if they intend to draw the full potential from their ONE positioning on SDN.  And that’s disappointing.

 

AT&T’s decision to buy NextWave is clearly a gamble, though insiders tell me that it’s not as much a wing and a prayer as it might seem.  NextWave has a bunch of 2.3GHz spectrum (WCS or Wireless Communications Services) that was never certified for mobile use, and the payoff for the deal seems linked to an appeal to the FCC based on safeguards proposed by Sirius XM and AT&T.  This would open that spectrum for 4G, if the FCC approves.  There were 128 licenses sold to 17 bidders, so there are others who have spectrum to sell or to use when and if the FCC clears the usage.

The truth is that we DO need more spectrum and better coverage because, as I’ve noted before, mobile is changing its face.  In the past, the goal was to create a poor stepchild of wireline that could be used when we weren’t tethered, a kind of backfill communications strategy.  Today, mobile is a mechanism for supporting ubiquitous access to online services, increasingly cloud services, and building entirely new relationships between ourselves and information.  These relationships are possible only because mobile really is (or can be) with us always, and so we can mold new behaviors around it.

What those new behaviors might be is still an open question.  Apple has demonstrated, via Siri, that we can view mobile broadband as a kind of personal supergeek, somebody who can get us what we want and answer all our questions.  So far, the great majority of wants and questions are fairly conventional, not in the least because Siri isn’t yet capable of complicated syntax.  Down the line, we can expect agents like it to take a much bigger role in our minute-to-minute living, but it’s going to take applications to accomplish that, and it’s not clear that operators have a real vision of the mobile/behavioral future.

Apple was two things; a trend-setter and an impeccable trend-reader.  The former role was due in no small part to the fact that they could embody the new mobile age in a cool gadget or two.  But once they did that, they were able to figure out how the ecosystem had to evolve to support the opportunity.  Telcos typically respond to direct sales requests not to ecosystemic trends, so they’re far from expert or confident in addressing this brave new world of mobile.  Which is why, even though mobility/behavioral symbiosis is seen as a major monetization opportunity and that mobile is still the primary focus of capex, mobile projects in monetization lag all of the others by a substantial margin.

In some ways, this is a new opportunity—for vendors.  The content wave, the monetization projects aimed at multi-screen, has largely left the beach for the open sea and the operators have picked other paths than following the vendors’ product strategies.  The cloud wave is primarily an IT phenomena, and while there are enormous opportunities to be had in customizing the fit between the cloud and the network (via SDN principles) vendors have so far failed to find the right path.  Eventually they’ll lose the opportunity to IT guys too.  But in mobile?  There could be giant bucks there, and also an opportunity for the equipment vendors who lack a strong mobile story (Cisco and Juniper) to create one.

I think vendors are missing a major truth here, which is that nobody is going to build silo service layers on top of converged networks.  There is going to be ONE ARCHITECTURE for hosting advanced service features.  This is a win-all, lose-all sort of thing, in other words.  If you insist on a kind of recipe for success in this one-layer-for-all model, it’s going to be a combination of cloud, SOA, and SDN.

 

There’s been a lot of speculation on “who will buy NSN” these days, with candidates all over the map.  If you look at the mix who have been suggested or who might be logical, you see that there’s an issue in the marketplace that would have to be handicapped before you could pick from them, or possibly reject them all.  That issue is what powers the network of the future.  Until you decide that, forget who an NSN buyer might be.

Bits, you say.  Or Internet.  Or content.  Nope, it’s PROFIT.  Operators will buy and deploy what makes money for them, and that’s been changing over time because of the cost-of-bandwidth and utilization curves.  In the early days of broadband, cost per bit for fat pipes was a LOT lower than that for thin pipes, and this made aggregation a good business to be in.  We built networks that were hierarchical because that concentrated traffic to successively fatter (and cheaper in unit-cost terms) trunks.  But as technology has improved the cost curve has flattened out.  It’s harder now to justify boxes inside the network because there’s less difference in unit cost per bit.  This is the technical dimension of what’s behind the OTN craze.  The business dimension is simpler; revenue per bit is falling so cost per bit has to fall faster.

The big question would be what wireless’ durability would be as a profit generator.  The Street forecasts for wireless revenue suggest that in all major markets the ARPU growth in wireless will flatten in 2013 and decline beyond that.  This would mean that just offering wireless bits would quickly become as profitable as just offering wireline bits, which means “not profitable”.  In this situation it would be hard to get a payback from buying somebody like NSN…unless…

…unless there was some known kicker for profit growth that wireless could bridge to.  A lot of people think that mobile content is the answer, and I think they’re wrong.  First, mobile content in a true sense would demand a much larger investment in cellular infrastructure, and the willingness to pay for content doesn’t change much wireline versus wireless, which means that the revenue per bit couldn’t be much higher for this new buildout.  Which means there won’t be one.  Second, the percentage of consumers who view mobile content at least once per month has been pretty consistent according to research firm Comscore.  The hours viewed per month has grown, but it’s still a single-digit fraction of TV viewing.

So what’s the driver?  If there is one, I think it’s the cloud-hosted-services model.  Most operators have now accepted that the services of the future will be built on networks but built IN cloud data centers.  How that could be done is critical, and NSN does have some credentials in the cloud-as-a-service-layer business.  Their vision aligns pretty well with the operations-driven view the TMF espouses, but I think that’s their problem.  OSS/BSS guys have not driven the monetization bus in the surveys I’ve done.  So NSN would have to create not so much an approach to cloud services that’s TMF-friendly as an ARCHITECTURE, a productized element, that’s monetization friendly.  They could do this, but they’ve not done it yet, and until they do I think they pose a problem for any potential acquirer.  The problem is “will I get my money out?”

SDNs can be an element in fixing this problem too.  If we applied SDN principles to cloud-building we could likely reduce the cost of the cloud and also increase the value of cloud services by improving QoE.  We could also make the network more of a partner in the cloud.  NSN really doesn’t SDNs at this point; we can’t find any specific accommodation to the concept, which is too bad because if NSN were to create the “real” layered structure of SDNs I’ve talked about here before (the “cloudifier”, “SDN Central” and the “topologizer”) they could add a lot of value in network virtualization to pretty much anyone’s portfolio.  So, NSN, get SDN-ish quick.

 

Ben Verwaayen, in an interview with the Financial Times, took responsibility for Alcatel-Lucent’s problems, which is fair given that he’s the CEO.  My only issue is that I think he’s looking at the WRONG issues.  Ben seems to think the problem was too much optimism two months ago.  I think it was too much inertia two years ago.

Operators cite the need to build a flexible new web-service platform as their highest priority, and it’s really hard to find a player who brings more to that space than Alcatel-Lucent does.  They have service layer technology, orchestration, content, cloud, you name it.  And that may be part of the problem because they haven’t really named it.  High Leverage Network is more about network than service layer.  Two years ago, simply bundling all of their service assets into a single product with multiple faces would have made it clear to operators that they had a converged solution in the service layer, one that nobody at the time could match.

Today, operators are tired waiting for vendors.  They see next-gen services as being built primarily using cloud technology, which makes them an IT play rather than a network play.  By visualizing services as software applications running on clouds, operators create the model of the service layer they’ve wanted all along.  They just need a way of coupling agile cloud-hosted features with the network.  That’s a mission software-defined networking (SDN) is likely to fulfill.  Alcatel-Lucent has no real position there, no story that links the network to the cloud.  To be fair, other vendors have little in the way of public assets in that space either, but Alcatel-Lucent can’t move ahead in the market by arguing that they’re not really behind.

You have to cut costs if you can’t raise revenues, so Alcatel-Lucent will now do that.  A bunch of good, valuable, people will have to find other jobs, and some of them probably could contribute to a position in cloud and SDN that would have saved, and still could save, jobs.  You can’t make up for two years of inaction in two months, though, and it’s probably too late to change the cost measures that current profit balances dictate.  It’s not too late to prevent more problems down the line.  I’ve said it many times before but I have to say it now.  You have to sing pretty in this market to win.  Every player who expects their merits to surface spontaneously is in trouble.

Marissa Mayer is apparently making changes at Yahoo, but so far they seem to focus on how people eat and communicate more than what they produce.  The new CEO has taken Google’s “free-cafeteria” approach and open collaboration into Yahoo in the hopes of creating a new atmosphere.  That’s probably a smart move since it’s been a long time since Yahoo employees had much to look forward to, but it doesn’t obviate the need to do something revolutionary in a product/service sense.  Right now, Mayer needs to quickly decide what unfulfilled needs exist in the industry and fill a couple of them.  I continue to believe that the greatest opportunity available to Yahoo today is the potential service-layer partnership with the telcos.  These people all want service-layer architecture and they’ve given up on the traditional equipment vendors.  Why not then rely on Yahoo, who as an OTT pioneer certainly knows where things are in that business?  Time is passing with this one, though.  Operators, as I’ve noted above, have already started creating their own models, and once these projects advance far enough it will be hard to turn around and take a new path.

Finally in tech, Microsoft’s Outlook.com mail program may be a step in the right direction in changing hotmail, but it’s also perhaps too much of a step in Google’s direction.  There are cosmetic differences between the two mail systems but nobody would be likely to find a compelling thing about Outlook.com that would switch them over from Gmail.  Cloud-hosted office and communications services are fighting to create a cloud portal, fighting against players like Facebook or Twitter.  You don’t win that sort of battle by imitating the other competitors. That’s Microsoft’s problem in a nutshell; they need to have something that’s not just “cloud email” but something that’s “cloud portal”.  I think that the Outlook.com symbiosis with the rest of Office’s and Windows’ next-gen features is the key point and they can’t showcase that yet because it’s not ready.  They should have waited.  They’re offering users a hand to kiss instead of a marriage.