Using Common Incremental Device Support
Common Incremental Device Support (CIDS) is a mechanism allowing to add support for new types of devices to an NMS application without fully installing a newer version of the product. The CIDS layer encapsulates all mechanisms needed for this support.
EMBU products like CiscoView, DFM, RME, and Campus provide some form of incremental device support capabilities. Because each product has taken a different approach, there is a duplication of effort.
Instead of making each application IDS-capable individually and having a device package carry multiple pieces for each application separately, an architecture is proposed which introduces a new runtime component common for all applications. This architecture is CIDS and the common component is called Synchronous Device Interface (SDI).
SDI's purpose is to provide access to device-focused data and functionality by always accessing the live device (without caching). Hence the name, Synchronous Device Interface.
The new approach allows multiple applications to make use of the same device packages encapsulating device-specific functionality.
The new approach re-uses tools, processes, concepts, and resources developed for CiscoView. CiscoView incorporates a well-developed and tested model for incremental device support that has proven itself to be highly reliable and functional over a number of product releases.
CIDS allows you to:
•Add devices to an NMS application without fully installing a complete new version of the product.
•Re-architecture each individual application on top of a CIDS base layer.
•Have Synchronous Device Interface (SDI).
•Have de-centralized development.
Figure 33-1 gives a high-level overview of CIDS device package development and installation.
Figure 33-1
High-Level CIDS Package
For basic information on CIDS , see the "About the Common Incremental Device Support (CIDS) Component" section on page 29-5.
For more information about CIDS, see:
•The CIDS web site: http://mspring-u10/cids/
•The Common Incremental Device Support (CIDS) for Appliances Functional Specification, ENG-100419
•Packaging CIDS, EDCS-184284
•SDI/ADI/UDI - Device Interfaces for Applications, ENG-113265
•SDI/ADI/UDI Design Specification, ENG-118149
•SDI/ADI/UDI - A Developer's Guide, EDCS-186733
•The tools Java docs are available at: http://wwwin-nmbu/auto/cw/cdimages/uid1_0/daily/SOL_UID1_0_INTEGRATION_READY/kits/javadocs/
•The engine Java docs are available at: http://wwwin-nmbu/auto/em_storage/cw/cdimages/cids1_0/daily/SOL_CIDS1_0_LATEST_GOOD/kits/javadocs/
Understanding CIDS
From the customer's perspective there is just the Incremental Installation; Customer buys new hardware (entire new types of devices, or just new cards for existing devices). Customer wants to easily update his already running network management system to manage the new hardware.
From the NMS application development perspective there is the distributed development for device support: To avoid following every single new release from hardware Business Units within Cisco, the application development operates on device abstractions and delegates the actual implementation of these abstractions back to the hardware Business Units.
To understand a high level overview of CIDS architecture, see figure 1 of the CIDS system functional specification in EDCS (ENG-100419)
SDI Component
SDI is the runtime component of CIDS. It provides the glue between the Network Management Application and the managed device. All the device specific information is then defined in a set of Abstraction Groups (AGs). The need is to develop a generic engine to drive the device management application for each device type based on the corresponding device description.
SDI:
1.Facilitates incremental device support by abstracting the device specifics from the application and the ability to drop in device packages.
2. Provides a common framework for all applications to provide incremental device support.
3. Provides support to the Application by performing device management operations and thereby eliminates the need for every application to duplicate this functionality.
4. Performs actual retrieval and modification of configuration information from/to the managed device.
Abstraction Groups
The Abstraction Groups (AGs) consist of a set of base classes. Each AG is represented by one Java package and consists of one or more Java classes. The AGs provide a generic interface for the Applications and shield the application developer from dealing with the device specific details. Application teams, working with the CIDS team, define Abstraction Groups in accordance with their needs.
Runtime Architecture
The figure below explains the runtime architecture of CIDS.
For more information on the CIDS architecture and the behavior, go to: http://mspring-u10/cids/