The news that Google has joined the CORD (“Central Office Re-Architected as a Data Center”) project, and that the project is now independent under the Linux foundation, is good news for next-gen networks. I’ve always thought CORD was important because it describes what operators would face in an infrastructure transformation—a massive shift in data center architecture. CORD doesn’t have an easy path, though, and it’s hard to say at this point just how much influence it will really exercise.
CORD faces the “Does the Destination Define the Trip? Challenge. Suppose you were a promoter of boats, and you traveled back in time to the days of dugout canoes to meet with the chief dugout architect. Suppose you presented a plan for a jet boat as the logical end-game for the evolution of the dugout. Yes, you could darn sure expect to create a lot of interest, but how much momentum could be created just by describing the end-game to somebody who’s still in the first inning?
The point here is that while it’s important to understand just what a CO re-architected as a data center would look like, if for nothing else to validate the direction of evolution, it’s the evolution that will probably be the focus in the near term. Can we get to a rational evolution from the end-state? Perhaps. Can we get there from where we are now? Also, perhaps.
The basic CORD model is a series of “PODs” which are server/switch complexes that are combined into a data center through additional switch connections. This structure isn’t a service-specific product set as it would be today, but rather a resource pool for the hosting of virtual stuff. What we see today as elements of a CO, including the subscribers, access, Internet, etc., are framed in as-a-service form and hosted on the POD complex. Users, whether they’re consumers or enterprises, wireline or mobile, consume these -aaS elements because they’re used to compose and deliver the services.
The CORD documentation describes CORD evolution as follows: “Given this hardware/software foundation, transforming today’s Central Office into CORD can be viewed as a two-step process. The first step is to virtualize the devices, that is, turn each purpose-built hardware device into its software counterpart running on commodity hardware. The key to this step is to disaggregate and refactor the functionality bundled in the legacy devices, deciding what is implemented in the control plane and what is implemented in the data plane. The second step is to provide a framework that these virtualized software elements—along with any cloud services that the operator wants to run in the Central Office—can be plugged into, producing a coherent end-to-end system. This framework starts with the components just described, but also includes the unifying abstractions that forge this collection of hardware and software elements into a system that is economical, scalable, and agile.”
If you took this statement literally, you’d say it describes a fork-lift upgrade. If you assume that it describes not a one-shot transformation but a controlled set of evolutions, then it’s not a radical shift from the NFV notion of defining network functions and then virtualizing them. The primary difference with NFV would be the second step, which presumes establishing a complete ecosystem (the transformed CO) into which the individual steps make contributions.
CORD also inherits the business issue NFV faces, which is how you justify even controlled sets of evolutions. By now, only unbridled optimists think telcos would simply commit to an evolution to a hosted framework for infrastructure with no specific drivers. We’ve seen a lot of attempts to promote NFV broadly, and none have been anything more than exercises in self-delusion. We’ve also seen some limited NFV service validations emerge, and it’s these that would probably have to form those controlled sets of evolutions.
Of all the things that have emerged as candidate for transformation, virtualization, and hosting, it’s mobile infrastructure that stands out. The reason is simple, and in fact it’s the same thing that makes mobile infrastructure a prime NFV target—scale. Virtual CPE is so far deploying more as open premises devices than as cloud-hosted elements. IoT is promising in the long term, but in the short term it’s not clear anyone is yet presenting a viable service model. But mobile services are ubiquitous, growing in volume and competitive importance, already receiving a massive share of capex, on the cusp of 5G, and 5G is emerging as a copper-loop alternative. What more could you ask?
Well, you could ask for incredibly broad support for an open model, and that’s another problem CORD inherits shares with NFV. We have not, as an industry, even defined a complete “platform vision” for portability of resources and hosted functions (we’re nearer to the former than to the latter). Vendors who can deliver a strong mobile-centric CORD would have a massive temptation to try to leverage it in other services, rather than to share it selflessly with others.
If CORD can drive a business case, the question of where it drives one still arises. There are a three areas where CORD has the potential to generate significant progress in transformation. One is in the area of creating an open framework hosted functions, the second is in the use of Docker/containers as the platform for control software overall, and the third is resource-pool and service networking.
The ONOS project, from which CORD was spawned, was about a network OS that would provide middleware services that included stuff appropriate to hosted functions. That could easily turn into an initiative to define a set of standard middleware functions that VNFs could call for lifecycle management and for information about the resources they’re hosted on. If all VNFs could be expected to run on a specific function set, they the onboarding of VNFs could be made trivial.
The control functions of CORD are expected to be Docker-hosted, and while that doesn’t demand that they be designed for elasticity, resilience, and scalability, it at least supports those goals. CORD seems to mandate them, so it seems likely that reference and real implementations of CORD would be made up of microservices (or “microfunctions”) that were hosted in a highly dynamic ecosystem. This is a departure from the framework for NFV, which doesn’t demand any such capability set.
Interestingly, one of the OpenStack vendors (Mirantis) has just pledged to create a version of OpenStack that runs in containers and is orchestrated by the popular Docker/container tool Kubernetes. The argument is that it would make OpenStack scalable, which it currently isn’t. One of the backers of this model for OpenStack is Google, who also happens to have just joined the CORD initiative.
The final point, networking, is a serious issue for all virtual environments, and one that nobody has really addressed properly. OpenStack Neutron, which is currently called out by CORD, has some significant limitations, to the point where I tell clients that they should adopt one of the vendor SDN approaches rather than rely on native Neutron. I believe that Kubernetes could be used to orchestrate in third-party SDN tools, and I think that if OpenStack becomes containerized it would likely mean that CORD would use it in that form, which might then create momentum to address the whole virtual-network question as it applies to hosted service features.
Virtual networking in an SDN sense or overlay sense is important to any infrastructure that has to separate tenants and maintain the isolation of its own control and management planes. However, for all these applications it’s also important to address the question of how something could maintain membership in multiple VPNs, in effect. It’s worth noting here that Google’s Andromeda project is arguably the most cloud-driven model of virtual network access out there, and it specifically addresses these “multiplicity” issues. If Google contributes and enhances Andromeda, it could give CORD capabilities that the OTT giant has used for its own services, and that could be a major boon to operators wanting to enter the OTT service space (listening, Verizon?) and to NFV as well.
In the end, CORD is perhaps the most promising path to next-gen infrastructure, but it comes back to that “the destination isn’t the route” problem, and that comes down to making a business case. In a sense, a commitment to transforming the CO sets the bar for CORD higher than for NFV, which can still be said to succeed with virtual CPE and no real infrastructure transformation at all. But that’s also a virtue; CORD has to promote a holistic vision of benefits because it’s a total transformation. We darn sure need to find such a vision somewhere.