Abstract
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.
Key Terms in this Chapter
Model: A model is an intelligent representation of a device or service that indicates the available configuration attributes, default values, required values, decision points based on values entered, and the ability to be translated into network device understandable language to deploy the configuration. Common modelling languages include YANG and TOSCA.
Controller: Typically associated with software-defined networking. The controller is the functional component that manages the control plane of the network and can be utilized to apply some level of configuration management to devices and how those devices interact with one another.
Artificial Intelligence for Networks: Tools and techniques that extend AI practices into the network management domain. These include the integration of Big Data concepts to receive a constant feed of information and make decisions on the configuration of the network with no human intervention, and automatically applying those changes.
Orchestrator: An orchestrator defines and manages policies and service levels by utilizing automated workflows and change management. Orchestrators are typically purpose built for a specific domain, such as the NFV Orchestrators defined by the ETSI NFV MANO standard. Network orchestrators provide a communication layer with the network devices that is vendor agnostic and exposes that communication northbound to other systems via APIs.
CI/CD: Continuous integration/continuous deployment. This is the concept that development of a solution, in this case a network automation solution, is an on-going process. Small incremental changes are constantly being coded, and then tested and deployed into product on a continuous, automated basis. This approach is central to DevOps as a methodology.
Intent-Based Networking: This is the application of models and intelligent network automation to present a simplified way of requesting network services. Instead of the traditional manner of entering relevant configuration data, a request will communicate the “intent” and rely on the intelligence built into the models to define the technical details required to provision the service. For example, a request for video connection between two locations will give no more detail than that. That request will then rely on the models involved to define details, such as circuit type, bandwidth, QoS, etc.
YANG: Stands for yet another next generation. YANG is a data modelling language developed for use with the NETCONF protocol for speaking to network devices. YANG has been adopted for use beyond NETCONF, such as use by some NFV orchestrators for cloud-based services.
TOSCA: Stands for topology and orchestration specification for cloud applications. TOSCA is a cloud services specific modelling language.
DevOps: Develop operations, or DevOps, is an agile methodology that merges the functions of software development and operations in the enterprise software development domain. This approach has been adopted in the networking world to facilitate a programmable approach to network operations. Often when applied to networking the term is changed to NetOps.
Software-Defined Networking: Is the separation of the data and control planes of the network. Often associated with OpenFlow, the purpose of SDN is to enable the network to be programmed in a similar manner to software applications.
Network Function Virtualization (NFV): This is the decomposition of network devices into the specific network functions they each provide, and the virtualization of those network functions in the cloud. These virtual network functions (VNFs) can then be “chained” together to replicate the capabilities of physical devices, or to provide a single source of a combined network service that no single physical device can offer. NFV features a management layer referred to as management and orchestration, or MANO.