In my blog yesterday I talked about the need for something “above” SDN and NFV, and in the last two blogs about the need for an architecture to define the way that future cloud and NGN goals could be realized. What I’d like to do to end this week is flesh out what both those things might mean.
Networking today is largely built on rigid infrastructure where service behaviors are implicit in the characteristics of the protocols. That means that services are “low level” and that changes are difficult to make because it requires framing different protocol/device relationships. Operators recognize that they need to evolve to support higher-level services and also that they need to make their forwarding processes more agile. NFV and the cloud, and SDN (respectively) are aimed at doing that.
The challenge for operators at my “boundary” between technology and benefits has been in securing an alignment at reasonable levels of cost and risk. We can define transformative principles but can’t implement them without a massive shift in network infrastructure. We can contain risks, but only if we contain benefits and contaminate the whole reason for making the change in the first place.
What we need to do have is an architecture for transformation that can be adopted incrementally. We take steps as we want, but we remain assured that those steps are heading in the right direction.
Let me propose three principles that have to guide the cloud, NFV, and SDN in how they combine to create our next-gen network:
- The principle of everything-as-a-service. In the cloud and NGN of the future we will compose both applications and services from as-a-service elements. Everything is virtualized and consumed through an API.
- The principle of explicit vertical integration in the network. OSI layers create an implicit stack with implicit features like connectivity. In the future, all network layers will be integrated only explicitly and all features will be explicit as well.
- The principle of universal orchestration. All applications and services will be composed through the use of multi-level orchestration, orchestration that will organize functionality, commit resources, and compose management/operational behaviors.
You can marry these principles to a layered structure that will for all intents and purposes be an evolution of the cloud and is generally modeled on both SDN and NFV principles:
- The lowest layer is transport, hosting and appliances, which makes up physical media like fiber, copper, and servers, along with any “real” devices like data center switches. The sensor/control elements of the IoT and user access devices and mobile devices also live here. Most capex will be focused on this layer.
- The second layer is the connectivity, identity, security, and compliance layer which is responsible for information flows and element relationships. This layer will be built from overlay protocols (tunnels, if you like, or overlay SDN). You can think of it as “virtual networking”.
- The third layer is the feature/component layer where pieces of software functionality are presented (in as-a-service form) to be used by services and applications. This is where the VNFs of NFV or application components or the product catalogs from which architects build stuff lives.
- The top layer is the service and application composition layer which builds the features and applications users pay for.
If we combine these principles and our structural view, we can propose a framework for an NGN implementation.
First, network and compute resources at the bottom layer will inevitably be compartmentalized according to the technology they represent, the vendor who provided them, and perhaps even the primary service target. That means that the implementation of this resource layer (which NFV calls the NFVI) has to be visualized as a set of “domains”, each represented by its own Infrastructure Manager. That manager is responsible for creating a standard set of resource-facing (in TMF terms) services. There will thus be many IMs, and unlike the model of the NFV ISG, the IM is part of infrastructure.
The resource services of these domains are “exported” upward, where they join the second element of the implementation, which is a universal model of services and applications. The purpose of the model is to describe how to deploy, connect, and manage all of the elements of a service from the domain resource services, through intermediary building-blocks that represent useful “components”, up to the retail offerings. The important thing about this model is that it’s all-enveloping. The same rules for describing the assembly of low-level pieces apply to high-level pieces. We describe everything.
One of the main goals of this model is to provide for service- and application-specific network connectivity that is built from a mixture of domain resource services (like fiber pipes) and virtual and completely controllable switching and routing. Every application and service can have its own connectivity model or can share a model, so the scope of connectivity can be as refined or large as needed. This layer is based on an SDN, virtual routing, and virtual switching model and I’d expect it would use an overlay-SDN protocol on top of traffic engineered paths and tunnels (used as resources from below).
Above this, we have a set of functions/components that can be harnessed to create that “higher-layer” stuff we always hear about. Firewall, NAT, and other traditional NFV-service-chain stuff lives here, but so do the components of CRM, ERP, CDN, and everything else. Some of these elements will be multi-tenant and long-lived (like DNS) and so will be “cloud-like”, while others will be customer-specific and transient and the sort of thing that NFV can deploy. NFV’s value comes in what it can deploy, not what it does as service functionality (because it doesn’t have any).
Applications and services are at the top level. These are assembled via the model from the lower components, and can live persistently or appear and disappear as needed. The models that define them assemble not only the resources but also the management practices, so anything you model is managed using common processes.
Users of this structure, consumer or worker, are connected not to a service with an access pipe, but to a service agent. Whether you have a DSL, cable, FiOS, mobile broadband, carrier Ethernet, or any other connection mechanism, you have an access pipe. The things you access share that pipe, and the service agent (which could be in-band control protocol driven or management API driven) would help you pick models for things you want to obtain.
Universal orchestration orchestrates the universal model in this picture. The purpose of the model is to take all current service-related tasks and frame them into a data-driven description which universal orchestration can then put into place. Management tasks, operations processes, and everything related to the service lifecycle create components at that third layer, components orchestrated into services just as functional elements like firewalls or CRM tools would be.
I don’t know how farfetched this sounds, but I believe you could build this today. I also think that there are four or five vendors who have enough of the parts that with operator “encouragement” they could do enough of the right thing to keep things moving. Finally, I think that any test or trial we run on carrier cloud, SDN, or NFV that doesn’t explicitly lead to this kind of structure and cannot demonstrate the evolutionary path that gets there is taking operators and the industry in the wrong direction.