Network Abstraction: The Key to Agility
As if the above factors were not challenging enough, other changes to the functional requirements for management applications can further complicate the nature of these systems.
The range of networking devices found in a modern network has grown exponentially and today the list includes routers, switches, gateways, media servers, content distribution systems, and load balancers to name just a few. Multiple vendors, each with varying approaches to network management, supply these network devices. New software versions, fixing bugs and providing enhancements are regularly available. Management systems need to be able to understand the differences in models and versions and quickly take advantage of new capabilities from networking vendors.
In addition, CSPs have new requirements for management protocols. On the OSS side, the management system needs to provide some type of application programming interface (API) for configuration, provisioning and activation, as well as SNMP for fault and performance management. Many CSPs mandate an MTOSI interface. A Java programming API for custom extensions is also often required as is a RESTful interface. In addition, a software application in the network needs to provide local user interfaces (both command-line and graphical) for lab trials and expert trouble-shooting.
Existing Approaches Fall Short
As much as CSPs would like to streamline their list of networking vendors, there will always be multiple vendors within their network. Integrating multiple EMS platforms into an OSS/BSS environment is a costly and time-consuming undertaking. Rather, today, configuration management is handled by a hodgepodge of manual processes, ad-hoc scripts, and large domain-specific systems integration projects. These approaches are inflexible, prone to error, and do not scale. Examples of pain points with existing systems include:
- Delays in introducing new services and activating service orders due to inflexibility in the service structure
- Outages and intermittent failures due to fragile provisioning and activation technologies
- Slow return to service when problems occur due to lack of consistency across service and network inventories
- Increasing systems support and administration costs due to largely manual and time-consuming processes for repetitive tasks
- Network and inventory views perpetually out of synchronization
Introducing a Network Abstraction Layer
The key to solving this problem is to provide a network abstraction layer between the OSS/BSS environment and the network. This layer needs to perform two main tasks:
- Get a desired service configuration from the OSS/BSS environment, calculate the corresponding configuration changes in the network, then provision and activate the service and deploy the configuration changes into the network; and
- Collect status information and alarms from the network, map this to service-level status and alarms, and then forward these to performance and alarm management systems in the OSS/BSS environment.
Tail-f advocates that the specifics of both services and network configurations are stringently defined in data models written in the YANG language (YANG is specified in IETF RFC 6020). The network abstraction layer needs to maintain a semantically rich database of both service instances and the current configuration of the network, including bi-directional relationships between service instances and the corresponding network configuration elements. It also needs to provide fail-safe service activation and provisioning to avoid configuration errors, network policy violations, and other inconsistencies.
