I had an interesting exchange with a planner in a mid-sized carrier, and got some insight into how network operators are seeing SDN. Coming from an exchange with some other operators, my contact gave me a tutorial on the “models” of deployment the operators are seeing as promising. Some are familiar, and some approaches we think of (and read/hear about) often seem to be getting discounted a bit in the real world.
The model that got mentioned first by operators in this exchange was the “vSwitch-plus” model. In cloud or NFV data centers, SDN and OpenFlow are often used to set up the connectivity at the virtual level, through control of vSwitches. Operators like that explicit model of setup—you connect what you say you want to connect—and so they are looking at a white-box data center where data center switches are OpenFlow-programmed as well.
One interesting point about this particular SDN application is that it’s seen primarily as a tool in reducing errors and advancing security and compliance. Operators didn’t think the cost savings involved would excite senior management, and they didn’t expect operations costs to be materially impacted either, except as it would relate to perhaps the security/compliance area.
The second model that got some attention was the metro grooming model. Operators made the point that it was becoming a practice to use lower-layer tunnels to separate traffic, services, applications, and users. Physical media like fiber or Ethernet copper are examples, but they lack the granularity needed because advances in technology keep boosting the capacity physical media can support. SDN could provide what might be called a “protocol-less tunnel”, an extension of physical media.
Where these tunnels should be supported is clear to operators too; primarily in fiber and in particular agile-optics gear. There is already a strong interest in redefining networking as a series of parallel Level 3 universes separated at the physical level, rather than as a universally connected Level 3 world as Internet advocates might see it. Right now this interest is focused in the metro because (logical, huh?) that’s where most of the capex is flowing. It’s also true that metro is the focus of a lot of different services, and also a focus of net neutrality planning for operators.
Neutrality is a big reason to worry here. If you were to build a hypothetically fully connected IP network as your metro foundation, you could (in the US and Europe in particular) find yourself defending any special service capacity against neutrality complaints because what you did would look and act much like an extension of the Internet.
There’s also an opex dimension here, but it’s more indirect. Operators say that the opex cost per handled bit is highest at Level 3 and declines as you drop through to the OSI basement. They also say that compartmentalized IP, particularly with topology and resiliency ceded to agile lower layers, is cheaper to run and the per-device traffic (being that of a single compartment) is low enough to make a hosted router/switch solution practical.
Some of you may recall a blog I did on this topic a while back—making the point that the network of the future could be far more virtual than we think if we compartmentalized applications and services at a virtual Level 1. Maybe I’m self-fulfilling here, but I see some of that working its way into operator planning as this group sees it, at least.
The third model of SDN is one of end to end service separation. The thought is that this would build out from metro commitments, meaning that operators would establish metro grooming as above, then extend it to do things like provision Carrier Ethernet using explicit OpenFlow forwarding. These Level-1-separated services at the metro level would then be interconnected using “core grooming” to create end-to-end services.
I had hoped to see some interest in building cloud computing services this way. It’s easy to say that you could combine the vSwitch-plus and metro grooming infrastructure choices to build a cloud data center with an application-specific network, then tunnel it to CPE in multiple sites to offer access. This model didn’t get much attention, though. It may be that it combines too many service areas. Most operators run their clouds and their networks independently. It may also be that they’re not seeing the end-game for that approach yet, and so can’t really justify diving into it.
One thing I didn’t hear from my operator source here was a goal of displacing traditional switching and routing with SDN. I was somewhat surprised by the very focused interest, and wondered if that were simply an indication of the operators identifying low-apple opportunities from which they could build to their real goal. No, they say—these low-apple opportunities are the real goal. Strategic use of SDN, meaning the conceptualizing of a pure, true, SDN model for switching and routing, is simply not something they were thinking about.
I wonder whether this might not have a significant impact on SDN, but also on NFV and even carrier cloud computing. In a way, it makes sense. Here are the operators, saying that they are facing profit compression because of the commoditization of bit services. Do they then re-architect bit services to offer better cost points in a technology-driven revolution, or do they just focus on the stuff that’s 1) costing a lot and 2) getting currently refreshed or capitalized? The latter, they say.
If this is the case, then SDN needs to focus a lot more on “interworking”, both in a vertical sense with the L2/L3 stuff and horizontally from network segment to network segment. Explicit SDN interworking beyond that accomplished using network-to-network gateway processes from L2 and L3 is essential if you’re trying to do internetworking below L2 and L3, after all.
For NFV, the challenge is that the views expressed by these operators challenges the notion of new services driving substantial NFV deployment. This group would simply do an NFV-ish (probably more cloud-like, or agile-CPE like in the case of vCPE) low-apple implementation that’s not even particularly designed to go anywhere else. To build NFV on a systemic scale you’d then need some overriding operations and orchestration benefit.
For the carrier cloud services, things could be really tough. There really are no obvious low apples for cloud services. IaaS is generalized but not much more profitable than pushing bits. PaaS and SaaS require a specific market target that operators might have trouble even finding and later have problems addressing in an engaging way.
Maybe we’re asking too much here. Maybe we need a technology vision of the future that operators can build toward without actually endorsing or even knowing about. That goes against my own planning-intensive grain, but the market will ultimately decide what it’s willing to do.
