What You Will Learn
Many network equipment vendors talk about end-to-end multivendor network management systems (NMSs), but few can actually deliver one. When evaluating a multivendor NMS, service providers must look beyond basic fault, configuration, accounting, performance, security (FCAPS) functionality and examine critical operational considerations that affect its viability, cost-effectiveness, and ongoing sustainability, including:
● Abstraction of management information
● Standards-based management interfaces
● Fast integration of device releases
● Independent release of device drivers
● Field extensibility
● Native device integration
● Third-party partnerships for integration
This paper discusses these requirements and how Cisco® Active Network Abstraction (ANA) effectively meets them for operating in a multivendor network environment.
As enterprise and residential customers demand more differentiated services, the market landscape for service providers has never been more competitive - or more complex. Seeking to differentiate their services and boost customer satisfaction, many network operators have taken a “best-of-breed” approach to their network investments. By retaining the flexibility to add devices from multiple vendors, service providers have the freedom to innovate with the latest technology and introduce new capabilities, without being dependent on any single incumbent network vendor. While this approach makes sound business sense, the inherent complexity of a multivendor environment can create significant operational challenges. More than ever, the success of an operator’s network strategy depends not just on the interoperability of networking interfaces among equipment but also on a practical and sustainable multivendor network management system.
The service provider industry has seen many attempts to achieve an end-to-end multivendor NMS, using various “manager-of-manager” and platform designs. However, while several network vendors today claim to provide an end-to-end multivendor NMS, closer examination reveals that most fall short of that goal. Delivering a true multivendor NMS requires a deep understanding of the issues encountered by operators of the NMS in real-world environments. For example, to reduce training costs, the NMS operators should not be required to operate each device or service differently because of differences among device makers. More important, to reduce time-to-market for new services and differentiating capabilities, service providers require a means to accommodate the constant change that characterizes today’s dynamic network environments.
Through years of experience operating in some of the largest and most successful networks in the world, Cisco has developed a clear understanding of what the practical, day-to-day management of a multivendor network environment entails. Cisco has embedded this exhaustive knowledge base into the Cisco Active Network Abstraction platform. As a result, Cisco ANA offers a number of features and capabilities to manage Cisco IP next-generation networks (IP NGNs) consisting of a large variety of device families running different variations of device software, as well as non-Cisco devices that complement or run in parallel to the Cisco devices. The Cisco ANA virtual network element (VNE) driver technology is the key enabler for the network and service model and the end-to-end event monitoring in Cisco ANA. As a result, Cisco can provide a comprehensive multivendor NMS that meets the requirements of today’s dynamic networking environments.
Meeting Real-World Requirements for Multivendor NMSs
Some NMS providers emphasize management features without explicitly stating how the solution addresses the essential, yet more subtle requirements for cost-effective and efficient day-to-day operation of a multivendor network environment. Those requirements encompass:
● Abstraction of management information
● Embedded support for standard management interfaces
● Fast integration of device releases
● Independent release of device drivers
● Field extensibility
● Native device integration
● Third-party partnerships for integration
Let’s explore these requirements in detail, and examine how Cisco ANA addresses them.
Abstraction of Management Information
A common approach for managing a network is to use element manager software for each device type. In practice, this often means the operator’s engineering personnel must learn different user interfaces, different element manager concepts for representing the equipment, and unique methods of operating a certain feature. An effective multivendor NMS should not simply pass through the same element manager interfaces and combine them. To help enable the NMS operator to focus on the network and services supported by the network devices, the NMS must play the role of normalizing the differences among the managed devices regardless of maker. That means abstracting the network devices, supported connectivity, and services into a common information model, making management functions for the entire network available through a consistent workflow, and providing visibility to the managed network in a single “pane of glass.”
As the governing principle behind its development, Cisco ANA provides a single abstracted network model for the network for any managed Cisco devices and typically extends the same principle to third-party devices. This means the NMS operator need only learn about the Cisco ANA features and not worry about the differences in management interfaces of each managed device. Moreover, Cisco ANA provides a single point of integration with northbound operations support systems (OSSs) and business support systems (BSSs) and allows operators to maintain a single database system for the entire network. Through this core value addition, Cisco ANA is easily adapted for multivendor network environments and helps reduce an operator’s training and operational costs.
Embedded Support for Standard Management Interfaces
Management interfaces of network devices ideally should all follow some industry standard. In practice, however, they tend to have enterprise-specific implementations, with different devices following standards at different paces. This can happen even when comparing devices from a single vendor. For this reason, any viable multivendor NMS requires a concentrated development and maintenance effort to accommodate constantly changing devices and variation in management interfaces, especially when supporting a device family for the first time. Fortunately, the majority of devices use some mature standard that is common across the industry, and as more new standard definitions are adopted, integration of devices with multivendor NMSs should become easier. The utopian ideal of universal standards may be a long way off, if it ever arrives, but the industry is taking steps in that direction. Any sustainable multivendor NMS should be designed to capitalize on these efforts.
Cisco ANA was designed from the ground up to take advantage of industry standards wherever possible. It integrates all widely implemented standard instrumentations, allowing network operators to, at the very least, discover and identify new devices added to the network and provide instant management coverage.
For example, Cisco ANA supports the IETF standard RFC 1213 management information base (MIB), facilitating topology discovery and standard event monitoring of IP interfaces, routing, and bridging. As more equipment vendors embrace standard management interface MIB implementation, Cisco ANA helps network operators take advantage of the multivendor integration and management that these standards enable to lower the cost.
Fast Integration of New Devices and Software
As network devices become more software enabled, new networking and control features can be enhanced, simply with software upgrades. This also means that device software changes are becoming more frequent to support new requirements and necessary bug-fix patches.
The traditional service provider recertification process is not equipped to efficiently accommodate these much more frequent device software changes and upgrades. A new approach to reduce effort and time is a must. The same challenge is faced by the multivendor NMS, because it is impractical to assume that it can keep up with all the software changes from all the different vendors’ equipment. Given this dynamic environment that defies off-the-shelf support of constantly changing devices, the concept of a preintegrated management solution is simply not practical.
The essential question for any multivendor NMS is not which vendors and devices it can already support but how quickly it adapts to new devices and unexpected software updates. Network operators also need to know what will be involved if any development or testing projects are needed to accommodate device software changes; this translates directly to the velocity at which they can introduce new service capabilities.
Cisco recognizes that a service provider’s ability to differentiate services and satisfy customers often lays in the speed at which it can roll out new capabilities. Cisco ANA was designed from the ground up to be highly adaptable and to readily accommodate constantly changing devices and software. The customization tools of Cisco ANA are extensible at run time to recognize additional device software and hardware modules and additional Simple Network Management Protocol (SNMP) traps and syslogs that typify device maintenance releases. Like bug-fix patches, these releases typically do not change the management interfaces and maintain backward compatibility. Cisco ANA can be extended to accept those device releases as if they ran the same previously supported device software. This helps avoid the need for an additional development cycle of Cisco ANA in order to certify the new device release.
In addition, Cisco invests in a significant ongoing maintenance program to assure that software changes to Cisco IP NGN devices are quickly verified with Cisco ANA. For all Cisco IP NGN-related devices, network operators can expect any necessary Cisco VNE driver updates within 30 days of a new release, or sooner. Network operators have the option to continue using Cisco ANA with its customization tools in the meantime while they wait, if they choose.
For third-party device software changes, network operators can use Cisco ANA customization tools to adapt to the new device release and submit a request to Cisco to make any necessary enhancements to the VNE drivers. In either case, as long as the device maintains backward compatibility in the management interface, the new device release can be integrated into Cisco ANA without the need to wait for a development cycle from Cisco. This capability helps tremendously in reducing the time and cost of recertifying new device releases for deployment.
Independent Device Driver Architecture
Device software changes, whether due to maintenance releases or patches, can occur for a variety of reasons. The vendor may be enhancing the device’s capabilities, for example, enabling it to support new hardware modules for different variations of port density configuration. A vendor may revise the hardware module to address new environmental requirements, to enhance throughput and capabilities, or to enable additional alarms. In all of these cases, the changes typically require a new release of the device OS software.
For the service provider managing a large network, this means they can expect to see a near constant stream of software updates for their various network devices. This presents a significant challenge for any multivendor NMS, simply due to the variety of devices and software versions involved. Each managed device may have software updates released on a different schedule. The network operator may also choose to update different devices at different times (for example, if the operator is migrating a large-scale network in phases), resulting in periods when multiple device OS software versions are running in the network at the same time. How an NMS deals with this extremely complex and dynamic state of affairs is one of the most important factors in its effectiveness.
Given the constant state of flux in device software, it is essential that a multivendor NMS driver architecture be sufficiently isolated from the rest of the software. If it isn’t, then even relatively minor updates to a device’s management interface will require updating and recertification of the entire NMS architecture.
Cisco ANA employs a much more flexible and adaptable device driver architecture that eliminates these issues. Its layered architecture concentrates all device driver software and isolates it from other management functions, allowing it to support driver changes much more readily. The operator can update the device driver software, and those changes dynamically cascade throughout the rest of the management system.
Using this capability, Cisco ANA supports multivendor environments by maintaining vertical divisions in the device driver architecture for each managed device family. As a result of this approach, updating device software will only affect the associated device driver in ANA. In addition, backward compatibility with the previous device software is maintained by the device driver.
This model allows Cisco to make updated drivers available for download on top of a service provider’s existing Cisco ANA installation. In this way, Cisco allows network operators to keep pace with device software changes as economically and efficiently as possible, minimizes the need to update the entire NMS software, and enables service providers to take advantage of new device capabilities more quickly.
Most device maintenance software releases (patches and enhancements) will not require changes to the device’s interface with the NMS. No reintegration cycle for such releases should be necessary; the only activity needed to assure compatibility is regression testing, at most. Recognizing this, an effective multivendor NMS should be designed to be extensible by the network operator - allowing the operator to define additional hardware equipment at run time, without the need for an additional integration cycle when the management interface has not changed.
Cisco ANA provides this capability, reducing the time and cost involved in device software integration. Even more important, this field extensibility gives network operators control over how quickly they introduce new device software - and how quickly they can deliver new networking features and hardware modules in a competitive marketplace.
Also critical for an effective multivendor NMS, Cisco ANA allows network operators to define, at run time, additional SNMP traps and other autonomous messages for recognition and parsing by the NMS. This is important because each device’s alarm-reporting attribute in a multivendor environment may be different and based on a different factory default. To facilitate a true end-to-end view through a single pane of glass, the NMS must provide a common way to modify reporting attributes (for example, the severity or description of a particular alarm condition) across all devices, without affecting the devices themselves. Cisco ANA provides this capability, letting the network operator define which events should be reported as alarms. Ultimately, service providers can tailor alarm reporting attributes for all devices, regardless of maker, to fit their unique network and service environment.
Native Device Integration
Service providers should be aware that network equipment providers inherently have more control over the cost of NMS integration than a vendor-neutral NMS provider. Typically, vendor-neutral NMS providers do not have control over device management interface implementation, backward compatibility, or prior knowledge about device software release status. Hence, they tend to repeat the integration process for each device release and transfer the cost to the network service providers.
Often in such integrations, service providers must employ specialized device experts to understand the device’s proprietary interfaces and device management capabilities. These specialists can be costly, may not always be available, and must rely strictly on information that the device manufacturer has released in the public domain. Since device management interfaces vary from vendor to vendor - and sometimes even from family to family from the same vendor - this integration may require specialists to engage in extensive software design analysis and research into the interface specification, all of which requires time and resources. The service provider also must allow for integration testing in a lab environment.
All of these inherent disadvantages of a vendor-neutral NMS can significantly increase the development cycle and the associated hourly labor cost to integrate new or updated device software with a vendor-neutral NMS. In addition, it is not uncommon for such neutral NMS vendors to view these reintegration processes as a revenue generator and charge ongoing fees to analyze subsequent software releases for all devices in the multivendor network.
Alternatively, using an NMS from the vendor that provides some or most of the equipment in the network eliminates most of these issues and provides built-in advantages. When network operators are using Cisco ANA, they benefit from Cisco’s ability to integrate the Cisco device management interface with Cisco ANA in parallel with the device software development cycle. As a result, Cisco can tailor the NMS to work with the various device OS versions of the Cisco devices and can release device driver software closely with the device release. Network operators using Cisco ANA and Cisco IP NGN equipment together benefit from such built-in advantages of Cisco ANA. For non-Cisco devices, Cisco is also working with third-party vendors to facilitate their development of device drivers for devices that complement Cisco IP NGN systems and expand Cisco coverage for service provider multivendor environments.
Investment in Third-Party Partnerships
All of the considerations previously discussed are foundational for the management of a multivendor network environment. Tactically, delivering a multivendor network management solution entails working with third-party vendors to integrate third-party devices and device releases with the NMS or, in the case of Cisco ANA, with device drivers.
Cisco is investing in developing these third-party vendor relationships today to make Cisco ANA even more effective as an end-to-end multivendor NMS. Cisco ANA’s independent device driver architecture makes it easier for third-party vendors to develop and release drivers for the solution and helps enable them to take full ownership of the driver release. Third-party vendors can also make use of Cisco ANA’s field extensibility attributes to reduce development costs when a new device software release includes no changes to the management interface.
Ultimately, these capabilities will also one day allow non-Cisco equipment vendors to handle all of the necessary native device integration in-house, without requiring Cisco’s involvement. In this way, Cisco ANA will not present a bottleneck for integrating with a new device release, and service providers will be able to more quickly take advantage of any enhancements or new capabilities. In the future, non-Cisco equipment vendors will control the development and release of their drivers, while Cisco controls the certification process to assure compatibility with Cisco ANA. Both Cisco and the equipment vendor can then publish the certified drivers, while the equipment vendor retains responsibility for maintaining and supporting the drivers for their equipment. The cost of the integration will become a matter entirely between the service provider and the third-party equipment provider; Cisco will have no need to act as middleman in the integration.
This operational model for multivendor cooperation may sound idyllic, but it is already widely used in other industries, such as applications on mobile phones and device drivers for personal computers. Cisco is investing in making this multivendor model a reality for Cisco ANA by designing an independent device driver architecture and developing toolkits to help enable third parties to more effectively develop, integrate, maintain, and support non-Cisco devices for use in multivendor networks managed by Cisco ANA. Ultimately, Cisco believes these kinds of investments will allow service providers to make the most effective use of their networking equipment regardless of the device maker, to bring differentiated service capabilities to market more quickly, and to operate a multivendor environment more cost effectively.
Service providers have good reason for wanting to maintain multivendor network environments, but they need the right tools to effectively manage them. Sustainable end-to-end manageability, however, requires much more than standard management functionalities and network devices that are compliant with standard interfaces. To be practical, it requires a solution with an architecture that addresses the challenge of constantly changing devices and software in the network, field extensibility that minimizes device integration costs, and the ability to partner with third parties and equipment makers to provide and support device management drivers for the multivendor network management system.
Cisco ANA provides a powerful platform for managing the multivendor network environment. With its ability to intelligently abstract both Cisco and non-Cisco devices and services, to quickly adapt to device software updates by independently upgradeable device drivers, and field extensibility, it allows service providers to make the most of their multivendor environments and differentiate their services in a competitive marketplace.
For More Information
For more information about Cisco ANA multivendor network management, visit, contact your local Cisco account representative, or send an email to .