As networks have evolved, there has been an evolution in how they are managed as well. This evolution has seen a move from manual configuration via command line interface (CLI) to script-based automation and eventually to a template-based approach with workflow to coordinate multiple templates and scripts. The next step in this evolution is the introduction of models to provide a more dynamic capability than is in place today. This chapter will discuss three major layers of modelling that should be considered during implementation of this approach: device models focused on the configuration of the hardware itself; service models focused on the customer or network facing services that leverage the hardware level configuration; and operational models focused on people, processes, and tools involved in application of device and service models. This includes the orchestration of activities with other tools, such as operational support systems (OSS) and business support systems (BSS).
TopIntroduction
As networks have become more complex, the ability of traditional management tools to scale has decreased. With the introduction of more dynamic networks, enabled by Software Defined Networking (SDN) and Network Function Virtualization (NFV) technologies, performance will only get worse. Legacy tools for managing the network have struggled to maintain accurate data about the current, mostly static networks. As such, there is little to support the ability to manage the more dynamic networks of the future.
Much like the network itself, these management tools were designed to be static. As a result, it has been a challenge to maintain the synchronization of Operational Support Systems (OSS) inventory with network reality, even with infrequent changes taking place. The author’s experience is that the accuracy of data in OSS inventory when audited against what is configured in the network falls into the 65-75% range. A change to the network can often involve more time and effort to update the OSS than it takes to execute the change itself.
With the virtualization of some network functions, new tools are being introduced. The resulting divergence of management between physical and virtual networks has created an “Operations Gap.” This gap will continue to grow as operations teams are required to optimize the maintenance of these new infrastructure types, while continuing to support existing ones.
There has been a natural evolution in network management, as networks have themselves evolved. There has been a move from manual configuration via Command Line Interface (CLI), to script-based automation, to a template-based approach that involves workflow to coordinate multiple templates and scripts to accomplish highly repeatable actions. The next step in this evolution is the application of models to replace the script and template-based management in place today.
This chapter discusses closing the “Operations Gap”. Three primary levels of modelling are discussed:
- •
Device Models: These are primarily the configuration options involved in the hardware itself, how it functions and provides a platform for services to traverse. This includes modelling virtual hardware.
- •
Service Models: These are the internal or customer-facing services that exist in the network, which provide functionality that leverages the Device level configurations. Internal services are technology specific, such as Carrier Grade NAT (CGN), while customer-facing services are technology-agnostic and traverse the devices and internal services defined to supply functionality to the customer.
- •
Operational Models: These are the combination of what is required to be completed at the Device layer, Service Layer, and any workflow and orchestration actions required.
There are many paths forward to solve the problem, and this chapter focuses on solutions within the installation and configuration management domains, with less emphasis on fault and performance management. Additionally, these techniques are most applicable to the service provider space, though each is directly applicable to an Enterprise network as well.
The traditional OSS vendors champion an approach to retrofitting these new technologies into their existing OSS solution. There is some value to this due to the very large investment service providers have in these tools. It seems to make sense to leverage this investment and not start from scratch. The issue is SDN/NFV concepts being introduced to network management do not play well together.
Other vendors espouse a total model-based approach that takes the NFV approach and extends it to the entire network. This would be valid if the average network did not have devices, or whole segments, not capable of being managed in this manner. Too many networks still have legacy devices that, at best, can only be scripted.
The middle ground approach is also put forth by some of the newer vendors on the scene. These vendors recognize that there is the legacy network to deal with, and that it will not be going away in the near term. They also recognize that network operators are going to be reluctant to throw away their significant investment in the current toolchain and will be introducing the new SDN/NFV model-based applications in conjunction. The resulting approach is to federate the data, capabilities, and functions of these various application domains using an automation platform to provide a unified automation tool. There are a few variations in how these vendors propose for this to work, but conceptually they align on this approach.