Cisco Active Network Abstraction BQL User Guide, 3.6.2
Understanding IMO
Downloads: This chapterpdf (PDF - 128.0KB) The complete bookPDF (PDF - 1.23MB) | Feedback

Understanding IMO

Table Of Contents

Understanding IMO

What Is IMO?

IMO Basics

Dereferencing

IMO by Example

Simple IMO object Example

IMO Construct Example

Typical IMO Constructs

Inventory Containment

Port Connections

Service Paths (SNCs)


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 and 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 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 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 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 and 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 through transient 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. The properties can be of several types:

Primitive types (for example, string, integer, and so on).

Cisco basic types (for example, IP address, MAC address and so on).

References to other nested IMO objects.

The properties can appear as single scalars (for example, IP address of a Network Element) or as part of an array (for example, 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 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:

Containment—for example, cards within a NE, ports within a card.

Logical reference—for example, traffic profile associated to a circuit.

Connectivity—for example, physical connection between ports, cross-connection between circuits.

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 (surfed).

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.

Dereferencing

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 relationship 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 retrieval methods, we see that 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. "Dereferencing" 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 "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 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 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 ADSL port. The following table summarizes the properties contained in this IMO object:

Property
Type
Value
Meaning

ID

Oid

{ManagedElement(Key=DallasPE)]

[PhysicalRoot][Chassis]

[Shelf(ShelfNum=1)]

[Slot(SlotNum=LT3)][Module]

[Port(PortNumber=9)][PhysicalLayer]}

Layer-1 properties of port 9 in slot LT3 in shelf 1 in the NE "DallasPE"

AdminStatusEnum

Integer

1

Up

OperStatusEnum

Integer

2

Down

MaxSpeed

com.sheer.types.Speed

0.0 bps

A Cisco basic type, which contains the speed (in this case, 0.0) and the units (bps)

TypeEnum

Integer

94

IANA protocol type


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 and CTPs:

1

NE properties

2

Logical inventory (empty)

3

Begin array of slots

4

Slot No. 0

5

Contained card

6

Card properties

7

Begin array of ports

8

Port No. 0

9

Port properties

10

Begin array of CTPs

11

Layer-1 CTP

12

Next slots


In this example, the construct provides a complete hierarchy of the device physical inventory. Each level (NE, card, port and so on) 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

This section includes the following:

Inventory Containment

Port Connections

Service Paths (SNCs)

Inventory Containment

A typical NE physical inventory is modeled in IMO as follows:

Figure 2-1 IMO Modeling for Inventory Containment


Note Different NE types can have a different IMO inventory hierarchy, such as a deeper hierarchy of shelves, modules and sub-modules.


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 (for example, 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 IMO Port Modeling for some examples of port modeling.

Figure 2-2 IMO Port Modeling

Following is an example with the XML representation of the modeling in the IMO Port Modeling diagram:

<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 As before, the objects in the SNC hierarchy contain references that can be traversed to pull in additional related data objects, such as traffic descriptors or port parameters.


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 Virtual Circuit (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).

Tracing an end-to-end path would require modelling 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.