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 multi-Vendor, multi-technology, multi-layer network & service information, based on the TMF-513/608 MTNM (Multi-Technology Network Management) recommendations. Internally within ANA IMO is implemented as a set of interface classes for representing all network & service information objects. However, for external integration purposes, the IMO specification defines 1:1 bi-directional translation of all IMO objects to XML. External applications that access Cisco ANA via BQL, are exposed only to the XML formatting of the ANA information.
It is important to note, that 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 DC (Device Component) hierarchies, whereas persistent information (e.g. event/alarm history, Service identifiers etc.) is kept in the ANA database. When interfacing with external systems, ANA works with transient IMO objects, which translate to/from the actual data elements in the system. This enables sending information from/to 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 by through transient PDUs).
IMO Basics
IMO is the data schema of the network. All network & 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. The properties can be of several types:
•
Primitive types (e.g. string, integer, etc.)
•
•
The properties can appear as single scalars (e.g. IP address of an NE) or as part of an array (e.g. list of Physical Ports in a Card).
IMO objects may also contain Aspects, which are dynamic properties used to extend IMO objects at runtime. This mechanism enables extending IMO objects (representing network resources) with additional information from the 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 a NE with all 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, such as:
•
•
•
The inter-object references enable ANA to pack and provide IMO data in the form of object Constructs. A Construct is a set (hierarchy) of inter-related objects. Every IMO Construct has a "root" object, which is the entry point to the objects collection, through which the construct can be traversed ("surfed").
Note, that 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, may contain a reference to the Chassis in which it resides and which is its ancestor in the physical network hierarchy.
De-referencing
Each IMO has a unique id call IOid. When one IMO is serving as a property of another IMO, sometimes there is no direct Object and property relation between them but a reference relation using the IOid. For example, instead of the IMO instance serving as a property of another, there is an IOId instance representing the IMO instance. In this case, in order to retrieve the data, two queries are required, for example:
When we execute a "Get" command on IVirtualRouter, observing its "get" methods we see it contains a method called "getVrf()". It would be expected that when invoked this will retrieve an IVrf, but actually this method return type returns IVrfOid, e.g. 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. "De-Referencing" is a method of retrieving the IVirtualRouter data including the referenced IVrf in one query, retrieving the IVrf data as an aspect of IVirtualRouter.
In the required aspects of the RetrievalSpecification, insert the "com.sheer.imo.keys.IReferencedImosAspectOid" in the IMO to be de-referenced:
<key name="req_aspects">...<key name="com.sheer.imo.keys.IVirtualRouterOid"><entry name="com.sheer.imo.keys.IReferencedImosAspectOid"></entry></key></key>
Specify the de-referenced method inside the required properties, as follows:
<key name="req_prop">...<key name="com.sheer.imo.IReferencedImosAspect"></entry name="Vrf"></entry></key></key>Specify the properties to be retrieved on the de-referenced IMO, in this example, the properties to be retrieved 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 on the IVirtualRouter.
IMO by Example
This section provides some examples of IMO objects & constructs. It describes their contents 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 ADSL port. The following table summarizes the properties contained in this IMO object:
The full details and enumerations of every IMO object type can be looked up in the IMO reference document.
IMO Construct Example
Following is an example of a physical Inventory IMO Construct, specifying a NE with its contained Cards, Ports & CTPs:
In this example, the Construct provides a complete hierarchy of the device physical inventory. Each level (NE, Card, Port etc.) 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 and array of ports (IPortConnector) which contain the CTPs (Connection Termination Points - represent the 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 in this example is empty. This branch can contain all the logical inventory of the device. Here it is empty since it was filtered out in the Retrieval Specification.
Typical IMO Constructs
Inventory Containment
A typical NE physical inventory is modeled in IMO as follows:
Figure 2-1 IMO Modeling for Inventory Containment
Note
Port Connections
IMO models a port as a construct. The root object is the physical port (PTP - Physical Termination Point), which is of type IPortConnector. It contains a hierarchy of CTPs (Connection Termination Points) which are IMO objects representing the connections at the 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 (e.g., traffic profiles). This type of modeling follows the 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 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.
See the IMO Port Modeling section for some examples of port modeling.
Figure 2-2 IMO Port Modeling
Following is an example with the XML representation of the modeling in IMO Port Modeling:
<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>Service Paths (SNCs)
IMO models Sub-Network Connections (SNCs) according to the recommendations TMF-513. The general object hierarchy that represents a SNC is described in the IMO Modeling for SNC section.
Figure 2-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
Following is an example of a DSL/ATM service path:
Figure 2-4 DSL/ATM Service Path
In this example, the DSL service starts from an ATM VC on the DSL port and terminates on an IP interface in the BRAS. The relevant cross-connections are in Layer 2 (up to the BRAS) and Layer 3 (in the BRAS), as described below:
Figure 2-5 Cross Connect Sequence
The IMO representation of this SNC is given below:
Figure 2-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 (in this example from 1 to 11).
Note, that for tracing an end-to-end path it would have been enough to model 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 & ATM Switch (devices A & B) and Layer-3 cross-connects for the BRAS (device C). Still, The SNC IMO provides the information of all layers, in order to provide richer information and a fuller context for the SNC.
