Table of Contents

Cisco Network Order Manager Solution

Cisco Network Order Manager Solution

This chapter provides an overview of the Cisco Network Order Manager (CNOM), which is a simple-to-use management configuration provisioning tool for the following Cisco element managers:

CNOM insulates the operator from the network and device detail by providing a high-level network order interface for directing the actions of element managers in the network.

This chapter includes the following sections:

Using the Cisco Network Order Manager Solution

Use the Cisco Network Order Manager (CNOM) to launch the DSL service life cycle: the creation, modification, and deletion of customer services achieved by performing specific network equipment reconfiguration in a specific order. You can use CNOM to manage Layer 2 connections between subtended digital subscriber line access multiplexers (DSLAMs), in a WAN (managed by CWM), and between Cisco 6400 Universal Access Concentrators (UACs).

CNOM can be used to manage the following entities in equipment managed by Cisco SCM:

CNOM also supports the management of the following entities in equipment managed by CDM:

CNOM supports the following northbound integration methods:

CNOM is made up of a number of processes that work together to execute network management tasks. The processes all use the same API that is used to develop CEMF-based element managers and are able to access all aspects of the CEMF information model. CNOM uses several CEMF capabilities to perform specific activities related to connection management, as shown in Table 1-1.

Table 1-1: CEMF Capabilities and Typical CNOM Activities
CEMF Capability Typical CNOM Activities

Access/navigate CEMF views

Find the chassis object that contains a specified ATM interface. Find a mapping object with the specified name.

Create/delete CEMF objects

Create profiles which will later be applied to PVC objects.

Read/write attributes

Read topology attributes to determine which interface on another device is connected to a particular port.

Perform EMS user actions

Create a PVC connection within a device.

Supported Element Management Systems

The Cisco Network Order Manager Solution supports the following environments:

You can configure CNOM from components, associated line cards, and management software listed in Table 1-2. Cisco Element Management Framework (EMF) allows the individual element management systems associated with CNOM system components to reside within a common framework. CNOM has access to each element manager through CEMF to perform provisioning of a service or a subscriber.

Table 1-2: CNOM System Components
Management System Device Description Module Types and Cisco IOS Releases

Cisco DSL Manager

Cisco DSLAMs

Perform Layer 2 aggregation of DSL traffic into one or more ATM uplinks.

Cisco 6130


NI-2 (hardware line card)

Cisco 6160


NI-2 (hardware line card)

Cisco 6260


NI-2 (hardware line card)

Cisco WAN Manager

ATM Cloud

A network of ATM switches managed by CWM.


An ATM switch.

Service Connection Manager

Cisco 6400 UAC

Performs Layer 2 and Layer 3 aggregation of DSL traffic and manages subscribers and services.

For SCM Release 2.2(2):

NSP—Cisco IOS Release 12.1(5)DB

NRP—Cisco IOS Release 12.1(5)DC

NRP2—Cisco IOS Release 12.1(5)DC


Receives network orders from order management systems through CORBA, or a command line interface.

CORBA (Common Object Request Broker Architecture)

Used as a standard for object management in which components are objects that can communicate with each other across boundaries such as networks, different operating systems, and programming languages.

TCP Socket Interface

Cisco Network Order Manager Components and Features

CNOM provides order management systems with a consistent interface for requesting services when the network equipment that supports the services vary within an operator, and will vary over time. Key CNOM components that support successful operation in complex, evolving environments include:

Network Order Policies

CNOM carries out processes defined in network order policies (NOPs). Each NOP defines the work flow required to implement a particular activity, such as adding a profile or connecting a subscriber to service. Each NOP uses an ASCII representation of UML state-machine notation to describe a work flow that implements the required network activity.

NOPs are stored in a set of text files in the directory <CEMF_ROOT>/config/ddmGateway/policies. Each CNOM process (including ddmGateway and each individual CNOM module) reads all of the policy files at startup, and when you run the CNOM command policyFileParser.

An NOP defines the initial state in the policy, and defines a cleanup policy that runs if the policy fails to complete successfully.

The following sections describe the following policy components:


A state defines actions performed at a particular point in the network process. A state contains the following parameters:


Transitions in the policy define the flow of the network process between states. Transitions are either success-based or failure-based. When a primitive completes:


Primitives are high-level instructions executed in NOAs during the invocation of a policy. Each state in a policy specifies an NOA and a primitive to run when the state is entered. Primitives can read information from any part of the internal network order, but can only write into the section owned by the NOA that executes the primitive.

A primitive typically oversees functionality that involves many steps, such as:

Primitives in NOAs perform simple functions such as setting a CEMF attributes, and they also perform complex functions, such as making PVC connections across subtended DSLAMs. Primitives enable you to develop policies with a minimum knowledge of device-specific detail.


Aliases define mappings between attributes in the internal network order. If an attribute is used in a primitive, an alias allows the value of that attribute to be substituted for the value of another attribute. Aliases are most often used to allow primitives to access attribute values supplied in the original network order. They can also be used to copy values from one internal network order attribute to another.

Cleanup Policy

Each policy defines a cleanup policy to be run in case the policy fails (that is, the policy returns to the dmmGateway process through a failure transition). The cleanup policy removes any objects that the failed policy may have been created, but not deleted, in CEMF and in the corresponding device configurations, and deletes any cached data from the NOAs relating to that connection.

Network Order Adapters

NOAs are processes that execute primitives to fulfill a network order. NOAs are typically developed to implement primitives specific to a device (for example, a DSLAM or a Cisco 6400 UAC). To develop NOAs, use a library that supplies:

When an NOA starts up, it reads all the policies in the <CEMF_ROOT>/config/ddmGateway/policies directory. The NOA then has knowledge of all the policies and the part it plays in each one. States in a policy define the Network Order Adapter that will run the primitive for that state.

Network Order Adapters:

ddmGateway Process

The ddmGateway process performs the following tasks:


Because CNOM leverages the profile feature of element managers, a network order can include a single serviceCharacteristics attribute value that corresponds to the name of profiles in different element managers. A profile is a collection of attribute values that define the operating characteristics of an object in a single step. CEMF element managers use profiles to store sets of attribute values to apply to network objects, such as interface ports and PVCs.

Mapping Objects

In some operational environments, the system sending network orders to CNOM uses its own naming convention for CEMF objects and does not have access to CEMF names. CNOM uses mapping objects to allow network orders to refer to an object using a name other than a CEMF containment name. Mapping objects translate between external names for ports and CEMF object identifiers.

Mapping objects are located in a special view (ObjectMapView) which is not visible in the CEMF Map Viewer window. The mapping objects are assigned the names that will be used in network orders, and have an attribute whose value is the CEMF object ID of the CEMF object to which the name refers. To resolve an external name to a CEMF object ID, look up the name in the mapping view, and then get the value of the attribute LocalDB:DDMMappingObject.targetObject.

CNOM provides primitives and utilities for mapping objects. The use of the utilities is described in the following chapters in this guide.

From a CEMF shell, enter the following cemfql command to list all of the mapping objects in a CNOM system:

cd <CEMF_ROOT>/bin ./cemf shell % cemfql "select objects from containment ObjectMapView: (startLevel=1, endLevel=0)" Selected 5 objects
    ObjectName ObjectMapView:/DDMTopology.lineID/9782441032 ObjectMapView:/DDMTopology.lineID/4085254903 ObjectMapView:/DDMTopology.lineID/9493545962 ObjectMapView:/DDMTopology.lineID/4085436953 ObjectMapView:/DDMTopology.lineID

In the previous example, the mapping objects are used to resolve from a subscriber phone number to the object ID of an ATM interface on a DSLAM.

The mapping object view is categorized by a mapping type (DDMTopology.lineID in the example) which allows mapping objects that are used for different purposes to be stored separately. To be able to retrieve a list of mapping objects that refer to a given CEMF object without performing a query on all mapping objects, set an attribute on each target object to contain a comma-separated list of mapping object names. The name of this attribute is specific to the mapping type.

Policy Storage

Policies are stored in a set of text files in the directory <CEMF_ROOT>/config/ddmGateway/policies. A single policy file may contain the definitions of multiple policies. Use the genPolicyDoc command to generate an HTML representation of policies.

CNOM Operation

The following sections provide background information about the way in which CNOM operates.

Storing Connection Objects

CNOM stores connection objects in two separate views:

connectionObjectsStore View

In the connectionObjectsStore view, CNOM stores connection objects among thousands of containment points (hash buckets). CNOM automatically pre-deploys thousands of hash buckets, then uses a hash algorithm to determine which hash bucket to place a newly deployed connection in.

Hash buckets are implemented as a two-layer containment structure. Following is an example of the containment structure for connection objects:

    connectionObjects:/bucket-1/bucket-1          .   .   .                               /bucket-100 connectionObjects:/bucket-2/bucket-1          .   .   .                               /bucket-100          .   .   .   
Hash Algorithm

CNOM uses a hash algorithm to distribute connection objects evenly among the hash buckets in the connection object store (connectionObjectsStore:/bucket-x/bucket-y). The hash algorithm performs the following steps to determine which hash bucket to place a connection into:

    1. CNOM applies the following function to the connection ID string (where s is a pointer to a character in the string and *s is the value of that character):

      for (i = 0; s*; s++) {        i = 131 * i + *s; } i = abs(i);

    2. CNOM divides the result by 100 and the remainder becomes the value of bucket-x.

    3. The resulting value is divided by 100 and the remainder becomes the value of bucket-y.

For example, running the hash algorithm on a connection whose ID is CONN-12345 produces the value 906919850. Dividing the value by 100 and then dividing the result by 100 produces remainders of 50 and 98, respectively, which results in the following containment path for the connection object:


Updating CNOM: Data Synchronization

The CNOMSync controller performs data synchronization to update the CNOM configuration with information about objects you create and delete outside of CNOM (for example, through an element manager like SCM or CDM). Data synchronization ensures that the CNOM configuration matches the actual configuration on the devices being managed. CNOMSync keeps track of all activity that occurs in CEMF and makes changes to the CNOM configuration as necessary (for example, to add or remove connections, profiles, or subscribers).

CNOMSync reads the files in the following directory for information about how to log information about specific objects:


Modifying Logging Information

Each file defines a type of object and provides instructions for logging events related to this object. To modify the logging information for a particular object (for example, to turn off logging or to change the location of the log file), you can use a text editor to make changes to the object class file for that object. For example, to turn off logging for Cisco 6400 subscriber objects created outside of CNOM, edit the Cisco6400Subscriber file and change enableLog=1 to enableLog=0.

After you change object-class files, you must run the following script (from a CEMF shell) to notify CNOMSync of the changes:


When you use syslog, it provides a means to log data on a remote machine for use in a recovery process.

Data Recovery

If the CNOM system stops responding and you have to restore the CEMF database from backup, you lose all of the configuration changes between the time of the last backup and the time of the system failure. This means that your CNOM configuration most likely will not match the actual configuration on the physical equipment (DSLAM or UAC) and the corresponding element manager (CDM or SCM). For example, connections and services may have been added on the UAC since the last backup.

CNOM provides data recovery by logging all network orders that modify the CNOM configuration (for example, creating and deleting VCs and services). In the event of a system failure, the system replays those network orders in order to re-create the CNOM configuration as it existed before the failure. See the "Performing Data Recovery to Restore CNOM from Backup" section for instructions on how to use this feature.

Posted: Sun Sep 29 05:31:43 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.