You can use CNOM to manage DSL service life cycle: the creation, modification, and deletion of customer services achieved by performing specific reconfiguration of network equipment in a specific order. 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:

Internal Network Order—The mechanism by which information is passed between CNOM processes.
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 specifies the following:

Starting point
End point
Quality of service for the connection

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.
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 which provide functionality for navigating views, getting and setting attributes, and for deploying and deleting objects. NOAs provide specialized primitives that encapsulate complex sequences of operations that are specific to the device (CDM NOA and SCM NOA).
Data Recovery—A feature that enables:

Logging of most CNOM network orders
Ability to replay the network orders that were entered between the time of backup (used to restore the system) and the last time the system operated

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.

Each NOA:

Wraps device-specific detail into high-level, generic primitives
Is a specialized CEMF controller process
Communicates with element managers using standard CEMF interfaces
Works with a particular underlying EMS, and the code of the EMS is not modified

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 includes no central managing process. The state of individual network orders is distributed among CNOM components. The ddmGateway process maintains a persistent store of network orders in progress and logs completion details. The internal network order passes information between NOAs during policy execution.

CNOM provides a capability to manage Layer 2 connections in network architectures which contain the following devices:

Cisco DSLAM 6000 series devices
Cisco 6400 UACs

CNOM is versatile enough to use in a variety of environments (see "Using Cisco Network Order Manager in a DSLAM Architecture," "Configuring a Multiple Cisco 6400 UAC Architecture," and "Configuring a WAN Environment").

System Architecture

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. Table 2-1 describes CEMF aspects:

Access and navigate CEMF views
Create and delete CEMF objects
Read and modify attributes of any managed object in CEMF
Perform user actions within CEMF-based element managers

CNOM is focused on connection management, and in this application uses each of the above capabilities to perform specific activities within that context. See the examples in Table 2-1.

Table 2-1: CEMF Capabilities and Typical CNOM Activities

CEMF Capability	Typical CNOM Activities
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 action	Create a PVC connection within a device.

Network Orders

A network order is a list of attributes or value pairs set on the processes:/ddmGateway object. At a minimum, a network order contains the following:

The name processes:/ddmGateway
The name of the policy to execute
A connection identifier (unique among connections)

Note Disconnect and query network orders are limited to having only these items.

Connection, service, and profile management scripts require you to set other attributes. The attributes you set depend on which policy you invoke and on which features of the policy are required.

When a network order appears as arguments to a CNOM command such as socketDaSet, you must supply appropriate escape characters to prevent the shell from interpreting the parentheses.

If a network order command is generated in a different language (for example, a perl script), you must escape further. For example, the following is from the getConnectionData script:

$command = "/opt/cemf/bin/socketDaSet processes:/ddmGateway workOrder:DDMWorkOrder.connectionIdentifier \"(@ARGV[0])\" workOrder:DDMWorkOrder.workOrderPolicy \"(getATMConnectionData)\" workOrder:DDM.finalWorkOrder \"()\" ";

system($command);

Submitting Network Orders

Enter a network order into CNOM for processing by sending an ASCII string containing the network order to a TCP port or by setting attributes on a ddmGateway object. The attributes you set depend on the policy you are invoking.

Set network orders in any of the following ways:

Using the CNOM command socketDaSet
By way of a TCP socket
Through the CEMF CORBA Gateway
Using the C++ API

These methods are described in the following sections.

You can use any or all of these methods on a CNOM system. Network orders are processed asynchronously, which means that new network orders may be submitted before previous orders have been completed. Several network orders may execute simultaneously, subject to the value of maxExecuting in the ddmGateway.init file.

Submitting Network Orders Using the CNOM socketDaSet Command

The CNOM command socketDaSet submits its arguments in the form of an ASCII message to the ddmGateway TCP socket interface on a specified CEMF server.

Use the socketDaSet command to:

Submit network orders from a remote machine
Test connectivity of remote systems to a CEMF server running CNOM
Prototype in integration projects

Submitting Network Orders Using a TCP Socket

To submit network orders directly to the ddmGateway process, send them to a specified port (10531, by default) on the machine on which CNOM is running. The network order has the same form as the arguments to socketDaSet. The ddmGateway process starts processing text when it receives a new line character. Responses are sent back to the calling process on the return channel of the socket on which the network order was submitted.

Submitting Network Orders Using the CEMF CORBA Gateway

The CEMF CORBA Gateway provides a way to set attributes on objects in CEMF. You can use it to set network order attributes on processes:/ddmGateway.

Note To build a client that can access CEMF services, use the CEMF CORBA Gateway Developer Kit.

Note For projects involving integration of CNOM with other systems, use the TCP socket interface or the CEMF CORBA Gateway.

Network Order Policies

The network processes carried out by CNOM are defined in network order policies (NOPs) which use an ASCII representation of UML state-machine notation to describe a work flow that implements the required network activity.

An NOP is defined by a set of states, each of which executes a code block known as a primitive. Primitives run inside Network Order Adapter (NOA) processes and are able to:

Read attributes from any part of the internal network order
Write only in their own section

NOPs are stored in a set of text files in the directory <CEMF_ROOT>/config/ddmGateway/policies and are read by CNOM processes (ddmGateway and each individual CNOM module) at startup, or when you run the CNOM command policyFileParser. A file can contain the definition of more than one policy, and all the files in the policy directory are parsed by each CNOM process.

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

Aliases define mappings between attributes in the internal network order, which allow you to copy values from one internal network order attribute to another.

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 among all policies
The target process in which the state is executed
The primitive name which contains the code block to be executed
Optionally, one or more aliases which allow you to copy attribute values within the internal network 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 try to clean up and exit gracefully.

Primitives

Primitives are high-level instructions executed in NOAs during invocation of a policy. Each state in a policy specifies an NOA and a primitive which runs 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 it.

Primitives typically provide a wrapper for functionality that requires many steps involving:

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 complex functions such as making PVC connections across a subtended tree of DSLAMs.

Primitives enable you to develop policies with a minimum knowledge of device-specific detail.

Aliases

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, but can be used to copy information from any part of the internal network order.

Cleanup Policy

Each policy defines a cleanup policy which runs if a policy invocation returns to the ddmGateway process through the failure primitive. The purpose of the cleanup policy is to remove any objects from CEMF together with corresponding device configurations that may have been created during a failed policy invocation, and to clean out any cached data from the NOAs relating to that connection.

Profiles

CNOM uses profiles in CEMF element managers to store sets of attribute values that can be applied from a menu item or programmatically. CNOM leverages this feature to allow a network order to specify a single serviceCharacteristics attribute value which corresponds to the name of profiles in different element managers.

Topology Attributes

CNOM uses topology attributes to navigate between physically and logically connected devices. Topology attributes are created at run time. Because the CEMF dynamic object model allows these attributes to be created on objects without requiring a system halt or database regeneration, CNOM is able to create topology attributes. When an attribute is defined in a policy and the policy is read by the ddmGateway process, the necessary metadata for the attribute is created. After the attribute is created, it is available for set and get operations.

Some topology attributes used in CNOM include:

connectedTP—Contains the CEMF object ID of the interface or port that is connected to this object
region—Allows a subset of possible exit ports in a mesh network to be selected by way of a query

Note You can create attributes for any purpose in policies (not just to hold topology information), but navigation is the main use for dynamically created attributes in CNOM.

When you deploy new equipment in CEMF, set the attributes using script utilities. Refer to each supported architecture which uses attributes for details on the specific topology attributes.

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 allow policies to which CEMF object and external name refers.

Mapping objects are located in a special view (ObjectMapView) which is not visible in the CEMF View application. 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.

Use the following command to list all the mapping objects in a CNOM system.

% 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. In order to be able to retrieve a list of mapping objects that refer to a given CEMF object without performing a query over all mapping objects, an attribute is set 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 the directory <CEMF_ROOT>/config/ddmGateway/policies. Use the genPolicyDoc command to generate an HTML representation of policies.

Network Order Adapters

Network Order Adapters are processes that execute primitives to fulfill a network order.

To develop NOAs, use a library that supplies:

Awareness of policies
Work orders
Primitives

NOAs are typically developed to implement primitives specific to a device type such as DSLAM, or a Cisco 6400 UAC.

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

Use the following list as a reference of the ddmGateway processes.

Receives network orders from external sources
Creates a network order object and places it in the workOrderObjects view
Processes network orders in workOrderObjects view in the order received
Creates a connection object in the connectionObjects view
Creates an internal network order and places the contents of an external network order in it
Identifies the policy to be invoked from an attribute in the network order being processed
Identifies, from the policy, which NOA owns the first state
Passes the internal network order to the appropriate NOA
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
If policy execution failed, the ddmGateway process retries according to the retry configuration setting
If a network order retry fails, the ddmGateway process invokes a cleanup policy
The original network order object is deleted

Data Synchronization

CNOM uses a CEMF controller (syslog) to monitor for object create and delete events through the participation framework. When an event is detected the controller logs the information to a file using standard CEMF facilities. CNOM Synchronization logs the following data:

Creation of ATM connections
Creation of ATM services
Creation of DSL connections
Creation of subscribers
Deletion of ATM connections
Deletion of ATM services
Deletion of DSL connections

Using syslog provides a means to log data on a remote machine for use in a recovery process.

Data Recovery

When CEMF is restored from backup, and VCs were created between the backup and the time when the CEMF system last operated, VCs configured on devices, which do not exist in the element manager object models, are present. Also, VCs that were created in the same time period exist in CEMF, but not on the device. The CNOM recovery feature enables logging of all network orders that create or delete VC connections, and to replay the network orders that were entered between the time of the backup that is used to restore the system, and the last time the system operated. The replay re-creates or deletes the objects in the CEMF that correspond to the VCs that were created or deleted in the period following the backup.

Table of Contents

Submitting Network Orders Using the CNOM socketDaSet Command

Submitting Network Orders Using a TCP Socket

Submitting Network Orders Using the CEMF CORBA Gateway