Rawpixel - Fotolia
In networking, the term virtualization is normally applied to technologies that create a clear separation between service features and the underlying resources that create them. Most often, this means working with software-defined networking, or SDN, software-defined WAN, or SD-WAN, and network functions virtualization, or NFV -- the technologies most associated with network transformation in the minds of network operators.
Network services are a combination of connectivity and embedded service features. And because the services are what the customer sees, and are guaranteed by service-level agreements (SLAs) and paid for under contract, they should form the basis for service management. Virtualization defines the service components in the abstract, or virtual, sense and maps them to network resources as needed.
This indirect link between service features and network components means service features and practices can be truly independent of network resources, which facilitates transformation. It also complicates figuring out exactly what is happening in the network at any given moment, which makes virtualization-driven transformation strategies a balance of risk and reward.
The only way to make that kind of balance work is to make it concrete and explicit. That means the virtualization layer has to be as real as possible, treated by the virtual service management processes above like it was a device, and by the devices below like it was a contract. The modern term for this kind of abstraction is an intent model, something that describes external properties that can be guaranteed and provides directions to produce those properties inside.
With this approach, services are the result of assembling the intent models for features, without regard for how they'll actually be fulfilled. A service architect using operational support systems/business support systems tools could build a service model without knowing whether it was based on a router service, SDN or SD-WAN, or whether the routers were real devices or software routers deployed using NFV. Similarly, operations processes relating to service creation that include ordering, customer assurance and billing can be designed to work with the intent models, and no changes would be required as the underlying infrastructure evolved.
Virtual service management model requires orchestration
Obviously, the physical underlying infrastructure has to play a role, and every intent model has to support at least one set of directions to describe how the feature is actually deployed on hardware or software. This process is increasingly described as orchestration because it requires cooperative behavior from a collection of resources and technologies, as a conductor might elicit a symphony from an orchestra. In a network transformation, each stage of the transformation, as well as every resource and each stage added or removed, has to be reflected in the directions for the intent models.
A number of technical approaches to orchestration exist -- some evolving from the cloud, such as DevOps software and OASIS Topology and Orchestration Specification for Cloud Applications, and some with roots in network technology, like the YANG data modeling language and Netconf protocol. So, inducing cooperation is at least well-defined. The missing link to managing virtual network transitions is, ironically, virtual service management.
Two models for network service features management
A customer looking at a service from the outside in would see only features, not technologies. A virtual private network service might be expected to present IP-routing status information, for example, whether any routers or even any IP elements were involved. As infrastructure diverges to nontraditional fulfillment of features through transformation, it is essential to decide how the management aspects of services relate to the evolving implementation of the features. Looking at the extreme cases, as is often the case, can be helpful. We have the "integrated" model and the "ships in the night" model.
Integrated service features management. The integrated service feature management model says, as a part of the intent model for a virtual network feature, an explicit set of management variables can be read from above and set by any set of resources assigned below. Because every service condition can then be related to a set of resource conditions, operators can write tighter SLAs, and it's possible to relate service state and the SLA to specific resource state. That makes fault correlation easy, but defining and maintaining all the variables is a complex challenge.
"Ships in the night" service features management. On the other extreme, the ships-in-the-night model of management, the resources available to the services and service features are managed in their native form to conform to an SLA determined by how the intent model representing each feature selects resources for use. The presumption is, if the resource selection is correct and the resources are behaving, so is the service. This approach dodges all of the complexities of translating resource status to service status, but it makes it more difficult to do fault correlation between services -- from the customer or customer-service-rep view -- and resources -- from the network operations center view.It's likely virtual network transformation is best supported by having both virtual service management models available, but over time, the most effective management model for service-level agreements is a variant on the ships-in-the-night model. This hybrid approach could be supported by one or both of two management practices -- end-to-end management at the service level and analytics-based management.
Both the NFV virtual CPE approach to service-building and the SD-WAN service models place devices at the customer edge, and these could help measure service parameters to supplement ships-in-the-night resource management. This approach has the advantage of creating independent telemetry on SLA parameters that can act as a check on the management practices of the resource layers below. Since it is based on what happens end to end, it also offers the best picture of what the service user sees.
The analytics approach uses data collection from resources, combined with predictive algorithms, to forecast service conditions and provide fault correlation. The link between service state and resource state would be maintained, but it wouldn't be necessary to continually derive the service-to-resource management relationships. As long as the data collection portion of the virtual service management systems are compatible with new network technology being introduced, it's a good transformation management approach.
Virtualization created a disconnect between the apparent resources and the real ones, but the flexibility it introduces actually opens options for network transformation. The new model isn't as different as it might seem, and it's probably the best tool network operations will have to advance to the future.
When network virtualization benefits have to be re-evaluated
Why management systems need to support the virtual and physical worlds
NFV management should focus on legacy and virtual resource orchestration