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:

SCM (Cisco 6400 Service Connection Manager)
CDM (Cisco DSL Manager)
CWM (Cisco WAN Manager)

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:

ATM connection templates
NSP PVC cross-connections for subscribers and services
NRP services and service profiles
NRP subscriber PVCs

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

XDSL profiles
ATM QoS profiles
PVC and SPVC connections

CNOM supports the following northbound integration methods:

TCP socket
CEMF CORBA Gateway

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:

Cisco 6400 UAC—Use this environment to manage a single Cisco 6400 UAC.
Cisco 6400 UAC to Cisco 6400 UAC—Use this environment to create a network architecture based on the Cisco 6400 UAC. Use this architecture to manage a virtual switch architecture.
DSLAM—Use this environment to connect valid DSLAM devices from Table 1-2 and valid subtend configurations.
WAN—Use this environment to connect PVCs through an ATM WAN (BPX) environment.

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	Cisco DSLAM	NI-2 (hardware line card)
	Cisco 6160	Cisco DSLAM	NI-2 (hardware line card)
	Cisco 6260	Cisco DSLAM	NI-2 (hardware line card)
Cisco WAN Manager	ATM Cloud	A network of ATM switches managed by CWM.	—
Cisco WAN Manager	BPX	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
—	Gateway	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—A simple, convenient interface for order management systems to use for DSL connection management which maintains stability when the network architecture changes. A network order is submitted to the ddmGateway process to execute a network order policy. When making connections, the network order contains the following elements.

A start point and end point
Required Quality of Service (QoS)
A unique connection identifier
Any service-specific attributes for the subscriber

Internal Network Order—The mechanism used to pass information between CNOM processes.
Network Order Policy (NOP)—A method for implementing operator-specific connection procedures that can tolerate varying and evolving network architectures. These are defined in an ASCII file format that represents UML state-machine notation. Each NOP defines one connection management operation for a particular network architecture.
Network Order Adapter (NOA)—A specialized CEMF controller process that connects to specific management modules in CDM, CWM, or SCM. Each NOA interprets the actions of the management module to which it is connected and forwards this information to CNOM. NOAs, which are used in policies:

Place device-specific detail inside high-level primitives
Communicate with element managers using standard CEMF interfaces
Work with a particular underlying EMS, and the code of the EMS is not modified

Primitives—The instructions that are executed in each state in an NOP by a Network Order Adapter (NOA). CNOM provides a set of generic primitives for navigating views, getting and setting attributes, and for deploying and deleting objects. NOAs provide specialized primitives that encapsulate complex operations that are specific to the device (CDM NOA and SCM NOA).

Data Recovery—A feature that:

Logs most CNOM network orders
Restores the CNOM configuration in case of a system failure

Data Synchronization—The CNOM Synchronization controller is responsible for data integrity checks for all connection objects not created or deleted by CNOM. The CNOMSync controller is informed of all objects and reports those which should be managed by CNOM, but were deployed or deleted by other means. CNOM reports deployment activity in the following format:

Date
Object Name
Parent Name
Class Name
Action (Created/Deleted)

Infrastructure Library—A component that:

Provides support for the key features listed above and is linked into each NOA. The NOAs perform a process that mediates between the detailed device operations involved in connection management and high-level primitives, which are the building blocks of NOPs.
Supports the definition of policies in a file. Each NOA reads this library at startup and whenever changes are made.

ddmGateway process—A special NOA that receives network orders from order management systems through the Common Object Request Broker Architecture (CORBA) or through a TCP port, controls their execution by the CNOM system, and receives notification of network order completion.

Note CNOM does not have any central managing process. The ddmGateway process maintains a persistent store of in-process network orders and logs their completion details. The internal network order is used to pass information between NOAs during policy execution and to maintain state information.

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:

States

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

A state name that is unique within the policy
The target process in which the state is executed
The name of the primitive (code block) to execute
Optionally, one or more aliases which allow attributes to be copied within the internal work order

Transitions

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:

Successfully—The success transition defines which state to execute next.
Unsuccessfully—The failure transition causes the policy to try to find alternative routes to complete the policy successfully, or to stop its processing and exit gracefully.

Primitives

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:

Deploying CEMF objects
Getting and setting CEMF attributes
Invoking element manager actions

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

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:

Awareness of policies
Work orders
Primitives

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:

Are developed using the same API as CEMF element managers and are installed in the same way. This commonality is leveraged to allow NOAs to access the element manager objects, attributes, and user actions to perform device-specific functionality.
Provide a mediation between the primitives that are used in policy definition and the detailed, device-specific attribute manipulation required to perform the function of the primitives.

ddmGateway Process

The ddmGateway process performs the following tasks:

Receives network orders from external sources
Creates an internal network order and places the contents of an external network order in it
Creates a network order object and places it in the workOrderObjects view
Processes network orders in the workOrderObjects view in the order received
Identifies the policy to be invoked from an attribute in the network order being processed
Identifies, from the policy, the NOA that owns the first state
Passes the internal network order to the appropriate NOA
The NOAs complete the execution of the policy
Receives each internal network order upon completion of a policy
Signals success or failure to the system that submitted the network order
Optionally, sends the contents of the internal network order back to the calling system
Creates a connection object in the connectionObjects view
If a policy fails, the ddmGateway process retries according to the retry configuration setting
If a network order retry fails, the ddmGateway process invokes a cleanup policy
Deletes the original network order object

Profiles

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:

connectionObjects—This view is always visible. By default, connections are visible in this view. You can, however, hide connections to improve system performance (see the "Viewing and Hiding Connection Objects" section).
connectionObjectsStore—This view is always hidden, as are the connection objects stored here. This view is used to maintain performance when a system has a large number of connections.

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:

connectionObjectsStore:/bucket-50/bucket-98/CONN-12345

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:

/opt/cemf/config/CNOMSync/objectClasses

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:

./updateCNOMSync

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.

Table of Contents

connectionObjectsStore View

Hash Algorithm