- Cisco Active Network Abstraction Customization User Guide, 3.6.6
Table Of Contents
Understanding IMO
What Is IMO?
The Information Model Objects (IMO) framework in Cisco ANA is a standard for generic information representation. It defines representation of multiple-vendor, multiple-technology, and multiple-layer network and service information, based on TMF-513/608 Multi-Technology Network Management (MTNM) recommendations. Internally within Cisco ANA, IMO is implemented as a set of interface classes for representing all network and service information objects. However, for external integration purposes, the IMO specification defines 1:1 bidirectional translation of all IMO objects to XML. External applications that access Cisco ANA via BQL are exposed only to the XML formatting of the Cisco ANA information.
IMO is only a temporary "packaging" mechanism. The live network data model maintained in Cisco ANA is stored within the Virtual Network Element (VNEs) in the form of Device Component (DC) hierarchies, while persistent information (such as events, alarm history, or service identifiers) is kept in the Cisco ANA database. When interfacing with external systems, Cisco ANA works with transient IMO objects, which translate to and from the actual data elements in the system. This enables sending information from and to Cisco ANA in a generic, consistent way (analogous to SNMP, in which the MIB is not the actual information repository, but only a data reference map, interacting with client applications through transient protocol data units [PDUs]).
IMO Basics
IMO is the data schema of the network. All network and service information is modeled in IMO objects. Each IMO object has a unique Object Identifier (OID), analogous to OIDs in SNMP MIBs.
Each IMO object has properties, which contain the actual data. Properties can be of several types:
•
Primitive types, such as strings or integers.
•
•
Properties can appear as single scalars (for example, the IP address of a network element [NE]) or as part of an array (such as a list of physical ports in a card).
IMO objects can contain aspects, which are dynamic properties used to extend IMO objects at runtime. This mechanism enables extending IMO objects (representing network resources) that have additional information from the Cisco ANA database. For example, an IMO object representing a port can be extended with an aspect that contains subscriber information. Another example is an IMO construct of an NE with its associated alarms; the IMO object representing the NE is extended with aspects, which contain the associated alarms.
As described above, most IMO objects contain references to other, related IMO objects. These relations describe network dependencies:
•
•
•
The interobject references enable Cisco ANA to pack and provide IMO data in the form of object constructs. A construct is a set (hierarchy) of interrelated objects. Every IMO construct has a "root" object, which is the entry point to the objects collection, through which the construct can be traversed.
The object constructs can contain any graph of objects (supporting references in any direction), and not just "top-down" hierarchical trees. For example, an IMO construct whose root object is a specific NE card might contain a reference to the chassis in which it resides and which is its ancestor in the physical network hierarchy.
Dereferencing
Each IMO has a unique ID called IOid. When one IMO serves as a property of another IMO, there might be no direct object and property relationship between them, but instead a reference relation using the IOid. For example, instead of an IMO instance serving as a property of another, there might be an IOid instance representing the IMO instance. In this case, to retrieve the data, two queries are required.
For example, when we execute a Get command on IVirtualRouter, observing its retrieval methods, we see that it contains a method called getVrf(). It would be expected that, when invoked, this retrieves an IVrf, but actually this method return type returns IVrfOid, that is, the ID of the IVrf. To retrieve the IVrf data, we need to execute another Get command using the IVrfOid to retrieve the IVrf data. Dereferencing is a method of retrieving the IVirtualRouter data including the referenced IVrf in one query, by retrieving the IVrf data as an aspect of IVirtualRouter.
In the required aspects of the RS, insert "com.sheer.imo.keys.IReferencedImosAspectOid" in the IMO to be dereferenced:
<key name="req_aspects">...<key name="com.sheer.imo.keys.IVirtualRouterOid"><entry name="com.sheer.imo.keys.IReferencedImosAspectOid"></entry></key></key>Specify the dereferenced method inside the required properties:
<key name="req_prop">...<key name="com.sheer.imo.IReferencedImosAspect"></entry name="Vrf"></entry></key></key>Specify the properties to be retrieved on the dereferenced IMO. In this example, the properties to be retrieved are on the IVrf:
<key name="req_prop">...<key name="com.sheer.imo.IReferencedImosAspect"></entry name="Vrf"></entry></key><key name="com.sheer.imo.IVrf"><entry name="*"></entry></key></key>Thus, one query is performed, and the IVrf is received as an aspect of the IVirtualRouter.
IMO by Example
This section provides some examples of IMO objects and constructs. It describes their content structure as well as their XML encoding.
Simple IMO Object Example
Consider the following IMO object:
<technologies.IAdsl><ID type="Oid">{[ManagedElement(Key=DallasPE)][PhysicalRoot] [Chassis][Shelf(ShelfNum=1)][Slot(SlotNum=LT3)][Module] [Port(PortNumber=9)][PhysicalLayer]} </ID><AdminStatusEnum type="Integer">1</AdminStatusEnum><OperStatusEnum type="Integer">2</OperStatusEnum><MaxSpeed type="com.sheer.types.Speed">0.0 bps</MaxSpeed><TypeEnum type="Integer">94</TypeEnum></technologies.IAdsl>The IMO object type is technologies.IAdsl and represents the Layer 1 properties of an asymmetric digital subscriber line (ADSL) port. Table 24-1 summarizes the properties contained in this IMO object.
The full details and enumerations of every IMO object type are available in the Cisco Active Network Abstraction 3.6.6 Technology Support and Information Model Reference Manual.
IMO Construct Example
The following is an example of a physical inventory IMO construct, specifying an NE with its contained cards, ports, and CTPs:
In this example, the construct provides a complete hierarchy of the device physical inventory. Each level (NE, card, or port) contains its own properties, as well as an array of nested objects, if relevant.
The root IMO object of the construct is the NE itself, which is of IMO type IManagedElement. It contains the list of NE properties and an array of chassis elements, which are of type IChassis (in this device, there is only one chassis). The chassis object contains an array of slots (of type IEquipmentHolder). Each slot has a single property (ContainedEquipment), which is an IMO object representing a card (IMO type IModule). Each card contains an array of ports (IPortConnector), which contains the Connection Termination Points (CTPs) - representing specific layers in the port's communication stack). In this case, there is only one CTP (Layer 1, represented by IPhysicalLayer).
Note that the NE object (IManagedElement) contains an IMO reference for the logical inventory branch (ILogicalRoot), which is empty in this example. This branch can contain all logical inventory of the device. It is empty here because it was filtered out in the RS.
Typical IMO Constructs
This section includes:
•
Inventory Containment
Figure 24-1 illustrates how a typical NE physical inventory is modeled in IMO.
Figure 24-1 IMO Modeling for Inventory Containment
Note
Port Connections
IMO models a port as a construct. The root object is the physical port, or physical termination point (PTP), which is of type IPortConnector. It contains a hierarchy of connection termination points (CTPs), which are IMO objects representing the connections at specific network layers. The CTP hierarchy is mapped to the network stack; every CTP at Layer N contains all its associated CTPs at layer N+1. In addition, CTPs can also contain related logical entities (such as traffic profiles). This type of modeling follows TMF-513/608 recommendations.
This relationship (CTP/Traffic profile) demonstrates how, in IMO, the cross-relationship between objects is based on the network functionality and is not restricted to "classic" hierarchy. Objects have multiple relations with other objects in all directions, and can be constructed and contained within each other in various ways.
Figure 24-2 provides examples of port modeling.
Figure 24-2 IMO Port Modeling
The following is an example of the modeling in Figure 24-2 with XML representation:
<IPortConnector><Location type="String">1.NTA.1</Location><ContainedCurrentCTPs type="IMObjects_Array"><technologies.ISonetSdh><AdminStatusEnum type="Integer">1</AdminStatusEnum><ContainedCurrentCTPs type="IMObjects_Array"><technologies.IAtm><Bandwidth type="technologies.IAtmBandwidthTrafficDescriptor"><TxMaxBandwidth type="com.sheer.types.Speed"> 0.0 bps</TxMaxBandwidth><TxUbrAllocBandwidth type="com.sheer.types.Speed"> 13.86 Mbps</TxUbrAllocBandwidth></Bandwidth><VcsTableSize type="Integer">50</VcsTableSize><VpVcRange type="String">[VP: 0..4096, VC: 0..65536]</VpVcRange></technologies.IAtm></ContainedCurrentCTPs></technologies.ISonetSdh></ContainedCurrentCTPs></IPortConnector>Subnetwork Connections (SNCs)
IMO models Subnetwork Connections (SNCs) according to TMF-513 recommendations. The general object hierarchy that represents an SNC is illustrated in Figure 24-3.
Figure 24-3 IMO Modeling for SNC
The root of the hierarchy is the SNC object, representing the entire service path. The SNC contains multiple Route objects, one for each networking layer (defining the end-to-end path for that layer). Each Route object contains a list of Cross-Connect objects, representing the cross-connection in each NE along the path (according to the network layer), and each cross-connect contains its respective A side and Z side CTP objects.
Note
Figure 24-4 provides an example of a DSL/ATM service path.
Figure 24-4 DSL/ATM Service Path
In this example, the DSL service starts from an ATM Virtual Circuit (VC) on the DSL port and terminates on an IP interface in the Broadband Remote Access Server (BRAS). The relevant cross-connections are in Layer 2 (up to the BRAS) and Layer 3 (in the BRAS), as described in Figure 24-5.
Figure 24-5 Cross-Connect Sequence
Figure 24-6 provides the IMO representation for this SNC.
Figure 24-6 IMO Representation for SNC
The path is defined as an ordered list of cross-connects. Each cross-connect object contains a running index (shown above in parentheses inside the cross-connect blocks), starting at 1. The indices determine the order of cross-connects constituting the path (1 to 11 in this example).
Tracing an end-to-end path would require modeling only the cross-connects of the layer in which the service path is routed in each device.
This would mean that, in the above example, it would have been enough to provide only Layer 2 cross-connects for the DSLAM and ATM switches (devices A and B) and Layer 3 cross-connects for the BRAS (device C). The SNC IMO provides information on all layers, thereby providing richer information and a fuller context for the SNC.
