Editor's note: This is the first in a three-part series by the president of CIMI Corp., Tom Nolle, about the telecom networking challenges that are (or should be) keeping operators up at night. First up, we look at the issue of how to link services sold to customers to the growing number of network resources and elements used to create them. Due to the rise of cloud, software-defined networking and network functions virtualization, virtual elements must be linked to a physical network infrastructure. But it doesn't stop there. They must also be recorded to enable service management, especially where service-level agreements must be met. Nolle looks at the issues that need to be sorted out so new and promising technologies don't become also-rans.
Providing telecom and network services has always been about linking actual network resources to the services customers are actually paying for. Of course now that we're in the age of virtualization, associating network resources and elements to services is no longer as simple as literally running wires and connecting terminal blocks. Nor does it just mean setting new parameters so network hardware knows how to provide the customer's VPN, for example.
You need to bring a third dimension to operations practices -- a virtual assembly process that describes how abstract services, features and even devices are realized on real infrastructure.
With the cloud, software-defined networking and network functions virtualization, any virtual devices must be created before they can understand the parameters of the customers' services and be used to provide them.
At the same time, as IT and the network merge in the cloud, traditional operations support systems, business support systems and network management systems may be merging into a cloud-related operations model. That model focuses on the emerging concepts of management and orchestration, and of managing bindings, which are records of the physical and virtual elements that make up a service.
Operations practices in advanced IP networks have to be viewed from two perspectives:
1. The network and IT elements that host content and features have to be managed as real devices. The old service provider adage, "You can't send a real technician to fix a virtual problem," is even more valid in an age where the devices used in a service might be nothing more than software processes hosted on a shared server pool.
2. The service that the customer is paying for must be the basis of customer relationship management, the management element from which most problem identification, resolution and remediation processes come from.
When you combine cloud, SDN and NFV, you need to bring a third dimension to operations practices -- a virtual assembly process that describes how abstract services, features and even devices are realized on real infrastructure. That's what orchestration is really all about. Instead of creating a service by linking shared and fixed functional devices, we create a service by deploying and integrating virtual functions hosted on servers. Only when that functional level of cooperation has been created can we talk about service management.
In the virtual age of the cloud, management and orchestration is a bridge between the resource management and service management views of the network. Like all bridges, it has to be anchored on both sides, meaning that service providers have to see the orchestrated virtual structure from a customer and service perspective, as well as from a resource and operations perspective. That process binds services to these virtual processes, which in turn are bound to real resources. So binding builds the essential bridges of next-generation operations from the service to the virtual and physical processes used to create it. (The European Telecommunications Standards Institute Network Functions Virtualization Industry Specification Group calls this management and orchestration bridging MANO.)
When something is orchestrated, the orchestration process needs to know or somehow record what resources were committed to what service features. The records can then be used to provide a service-specific view of the status of a customer's service, derived from the state of those resources. Operations personnel need the ability to drill down into resource status to fix problems. In an era where both services and resources are increasingly virtual, bindings link what the user buys with the resource commitments that fulfill them.
Extend binding to service management and increase automation
Binding also helps in another operations issue that next-gen services create -- getting the benefits new technologies promise in order to drive profit for operators. Survey after survey shows that service agility and operations efficiencies are the primary goals of operators. But we can't make revolutionary changes in either without a revolution in how we create and operate services.
We can't make revolutionary changes in either without a revolution in how we create and operate services.
An essential question is how that can be harmonized with network operators' enormous investment in operations tools (OSS/BSS/NMS) and the necessary human processes. If binding can describe how we deploy a service, why not also let it describe how we manage the service? That change would make it possible to mold the management of binding (or recording) network elements to services to suit the needs of operators' current practices and tools and evolve both at the pace that technology and opportunity can support.
Binding-driven management practices focus on building a management view while you assemble the pieces of a distributed, virtual service. It lets operators create any convenient management view of a service or a set of service resources, so it helps adapt the emerging virtual-service and virtual-resource technologies now emerging to existing OSS/BSS/NMS systems.
Binding-driven management can do more, though. It can support new levels of service automation that would deploy a service when ordered and then sustain it according to preset service-level agreements with little or no intervention.
The challenge is that binding isn't currently recognized as an element of operations. The prevailing OSS/BSS standards from the TM Forum recognize Service, Product and Resource Domains, for example. A binding domain designed to record virtual and physical network elements isn't in the current or emerging TeleManagement Forum (TMF) specifications. Binding is not an explicit feature of cloud DevOps tools either, even though the tools do orchestration.
Who decides how to provide managed binding guidelines?
The fact that there is no binding domain today means that one could be provided by multiple standards groups or within multiple product classes. The NFV ISG, for example, will have to address at least some of the issues of binding for its own MANO implementations. If it were to offer its approach generally (so that it could orchestrate and manage legacy networks, SDN and NFV elements together), it could potentially harmonize existing OSS/BSS practices with the new virtual-based network service technologies.
The Open Networking Foundation has a similar opportunity, and bodies like the 3rd Generation Partnership Project, OASIS and TMF could all define an approach. Multiple options are good if they provide multiple choices but bad if they generate opposing notions about how to approach binding-based operations that result in incompatible products.
The risk to next-generation practices for management and orchestration is that a lack of specific articulation of the concepts might mean that none of the possible approaches to next-gen operations will take the optimum path -- or even an effective one. The future of operator infrastructure investment depends on the future profits of future services, and pairing these services efficiently with next-gen infrastructure.
It's a circular dependency, and one that only management and orchestration that focuses on relationships and not on services or resources can fulfill. A workable solution to binding management is essential to realize the full potential of SDN, NFV and the cloud.