This chapter describes the connection attributes and processes of a Cisco Network Order Manager architecture consisting of a series of Cisco 6400 Universal Access Concentrators (UACs).

Configuring Cisco 6400 UACs

This section details the use of CNOM for managing PVCs in a network containing Cisco 6400 UAC devices. CNOM enables you to manage PVCs in a single UAC or between UACs. CNOM uses the ATM subscriber and service management features of the Cisco 6400 Service Connection Manager (SCM) to interact with the 6400 UACs. The SCM Network Order Adapter (NOA) specifies the ingress and egress PVCs used, and also the name of the connection template applied to the PVCs.

In addition to supporting stand-alone UACs, the Cisco 6400 UAC architecture supports clusters of Cisco 6400 UACs arranged in two layers—Remote Terminal (RT) and Competitive Local Exchange Carrier (CLEC)—with full interconnection between the layers. In a cluster topology, each cluster acts as a virtual switch, and CNOM must make PVC connections across the virtual switches. To do this, CNOM creates a pair of PVCs, one on each device, which makes a connection between a port on one Cisco 6400 UAC in a cluster to a port on another Cisco 6400 UAC in a cluster. See Figure 5-1.

Figure 5-1: Cisco 6400 UAC to Cisco 6400 UAC Configuration

CNOM uses the following types of connection objects to manage PVCs and subscriber services:

ATM cross-connections (set up through the connectSubscriberToATMService policy) connect an ingress port to an egress port.

In a single UAC, the policy sets up the cross-connection within the device.
In an environment with multiple UACs, the policy creates a pair of PVCs, one on each device, to set up the ATM cross-connection between the RT UAC and the CLEC UAC chassis.

SCM service connections (set up through the connectSubscriberSCM policy) connect a subscriber to a service on an NRP in the UAC.

: SCM service connections can exist only within a single UAC. You cannot set up a service connection from an ingress port on one UAC to an NRP on another.

To run CNOM SCM policies successfully, meet the following conditions:

The Cisco 6400 UACs are deployed and commissioned.

The ingress and egress ports are identified and configured with line IDs. See the "Configuring Line IDs for CNOM Modules" section for more details.
For connections between UACs, the inter-machine tie ports are configured using the policy set-IMT.

The services are configured and commissioned using the appropriate createserviceprofile and createservicefromprofile policies.

Prerequisites

Before you can use CNOM to configure Cisco 6400 UACs, you must install the following software:

CEMF Release 3.0.4 and appropriate CEMF patches (see the Release Notes for Cisco Network Order Manager Release 1.3)
Cisco 6400 Service Connection Manager (SCM)
CNOM software

Refer to the installation guides for each product for installation procedures. The CNOM installation and upgrade procedures are described in "Installing Cisco Network Order Manager."

Configuring the System

This section describes how to set up CNOM to manage connections in a network with multiple Cisco 6400 UACs. Connection management is possible only after you configure the following:

Connection templates in SCM for the cross-connects
Mapping objects for ingress and egress ports (only if CEMF names will not be supplied in the network orders)
Inter-machine tie port information

The procedures for performing these configuration tasks are detailed in the following sections.

Connection Templates

An SCM connection template is a type of CEMF profile that contains ATM QoS settings to apply to a connection. By applying the profile (that is, by specifying the profile name in the connection command), you can apply those ATM QoS parameter settings to the connection rather than having to specify each parameter value separately. CNOM requires that at least one connection template is configured in SCM to facilitate connections in a network of multiple Cisco 6400 UACs.

Manage the connection templates using the SCM GUI (refer the Cisco 6400 Service Connection Manager User Guide), or using the CNOM network order interface.

To manage:

SCM connection templates through the CNOM network order interface, use the policies createConnectionTemplate, modifyConnectionTemplate, and deleteConnectionTemplate.
Utility scripts create_qos, modify_qos, and delete_qos to enable connection templates, use the command line on the CEMF server.

Connect and Disconnect Scripts

The following connect* and disconnect* perl scripts provide a wrapper around socketDaSet to provide a command line option to invoke the policies. You run these scripts from a CEMF shell.

The connect_atm script invokes the policy connectSubscriberToATMService, which creates an ATM cross-connection between an ingress and egress port.
The disconnect_atm script invokes the policy disconnectSubscriberAndService, which removes an existing ATM connection.
The connect_scm script invokes the policy connectSubscriberSCM, which creates an SCM service connection used to connect an ingress port (or subscriber) to a service.
The disconnect_scm script invokes the policy disconnectSubscriberSCM, which disconnects an ingress port (or subscriber) from a service.

Invoking these scripts without arguments displays the usage statement for the scripts.

These scripts generate a connection identifier using a config file /opt/cemf/db/conncount by default. The connection identifier is generated as string CONN-<conncount> where <conncount> is incrementally generated.

Note When you run a connect or disconnect script with the -syslog option, the system only records part of the work order in the syslog file. This is because the buffer on the CNOM system is too small to store the entire work order in the syslog record.

Connection Status

If a connection is:

Successful—The socketDaSet command returns a success message and creates connection objects in the connectionObjects view to represent the connection. If you include the -hide option when you create the connection, connection objects are hidden in connectionObjects.

: At the root level of connectionObjects, an object with the same name as the workOrder:DDMWorkOrder.connectionIdentifier value appears. Expand this object to show the objects C6400DMMServices and C6400DMMConnection.

Unsuccessful—The socketDaSet command returns the message "Failed to set the following." Refer to log files ddmGateway.audit, ddmGateway.log, and C6400DMMCtrller.log for more information.

To disconnect a connection made through the connectSubscriberToATMService policy, use the policy disconnectSubscriberAndService. The policy is assigned the connection identifier supplied for the connection in the attribute workOrder:DDMWorkOrder.connectionIdentifier and removes it.

Creating Mappings for ATM Interfaces

Network orders for creating connections in a multiple Cisco 6400 UAC network architecture supply names for the ingress and egress ATM interfaces. Use mapping objects to define the aliases available for use in network orders. If the names in the network order are not CEMF names, you must resolve each supplied name to be a CEMF name. To resolve supplied names to CEMF names, use mapping objects.

The mapping objects for a multiple Cisco 6400 UAC network architecture are called line IDs. Manage line IDs using the following scripts:

./set_line_ids <ContainmentPath> <LineId,LineId,LineId> <SubdomainId>—Creates a list of line ID mapping objects, and sets the line ID attribute to be the comma-separated list of mappings. Previous mapping objects for the interface are removed.

./add_line_id <ContainmentPath> <LineId> <SubdomainId>—Adds a line ID alias to an interface.

./remove_line_id <ContainmentPath> <LineId>—Removes a single line ID alias from an interface. This step must be completed before you can remove a chassis.

./cleanup_line_id <LineId>—Removes line IDs that were not deleted before you removed a chassis or uninstalled CNOM.

Note Use the cleanup_line_Id script only to remove line IDs that were not deleted before a chassis was removed or CNOM was uninstalled. For instance, if you attempt to use or remove a line ID from a removed chassis and receive an error message that you can not use that particular line ID, run the command ./cleanup_line_Id [<LineId>] [<ContainmentPath>].

./reset_line_ids <ContainmentPath>—Removes line ID mapping objects for an interface, and clears the line ID attribute.

./get_line_id <ContainmentPath>—Returns the value of the line ID attribute which may consist of a comma-separated list of line ID aliases.

./get_object_for_line <LineId>—Returns the name of the interface with the specified line ID alias.

The values of the line ID aliases may contain any alphanumeric characters plus (-), (.), and (_).

Managing Inter-Machine Tie Links

In CNOM, the connections between two Cisco 6400 UAC devices are called inter-machine tie (IMT) links. You must set up IMT links in order for CNOM to be able to create ATM connections between two Cisco 6400 UACs. Each IMT link represents a physical connection between the UACs. When you create an ATM connection in CNOM, you can specify which IMT link the connection is to use or you can allow CNOM to decide.

Consider the following as you set up and manage IMT links:

You must configure an IMT link for each physical connection between Cisco 6400 UACs that you want to make use of. For example, if there are three physical connections between a pair of UACs and you create two IMT links, CNOM will only be able to make use of the two physical connections represented by the IMT links.
You can create multiple IMT links for a single physical connection, although this is not necessary.
When you use the connect_atm script to create an ATM connection, you can specify which IMT link the connection is to use or you can let CNOM select the link (see the "Creating ATM Connections" section).
You can rename an IMT link.

Creating and Removing IMT Links

CNOM uses IMT links to establish ATM connections between two Cisco 6400 UACs. To create an IMT link between two UACs, enter the following command:

./set-IMT <RT-Port-Containment-Path> <CLEC-Port-Containment-Path> <link_name>

Where:

<RT-Port-Containment-Path> is the containment path of the tie link's ingress port.
<CLEC-Port-Containment-Path> is the containment path of the tie link's egress port.
<link_name> is a unique identifier to assign to the IMT link. When you create an ATM connection, you can assign the connection to an IMT by specifying its link name.

To remove an IMT link, enter the following command (where <link_name> is the IMT link to remove):

./unset-IMT <link_name>

Renaming IMT Links

This script allows you to create a new IMT name with a different name. Enter the following command:

./rename-IMT <old_name> <new_name>

Where:

<old_name> is the original name for the IMT link.

<new_name> is the new IMT link name. In addition to renaming the IMT link, this action resets the connection counter on this new IMT link and modifies all related connection objects to make certain that the "getConnection Data" script shows the correct new IMT name.

If all operations are successful, then this script deletes the old IMT link name.

Setting the Active IMT Link

When multiple IMT links exist between two Cisco 6400 UACs, you must designate one of the links as the active IMT link. When you create an ATM connection and do not assign the connection to a particular IMT link, CNOM assigns the connection to the active IMT link.

To set the active IMT link between a pair of UACs, use the following command (where <link_name> is the name of the IMT link to configure as the active link):

./setactive-IMT <link_name>

Getting Information about IMT Links

To retrieve information about IMT links, use the following command:

: ./getinfo-IMT [-link <link_name> | -chassis <chassis1> [<chassis2>] ]

Where:

-link <link_name> retrieves information about the IMT link specified by <link_name>.
-chassis <chassis1> retrieves information about all IMT links on the chassis specified by <chassis1>. You can use this option alone or with the <chassis2> option.
<chassis2> is an optional second chassis. The system retrieves information about all IMT links that exist between both chassis.

Managing ATM Connections

This section describes how to create, delete, and query PVC connections across a pair of Cisco 6400 UACs.

Creating ATM Connections

Use the network order policy connectSubscriberToATMService to create a pair of PVCs that form an end-to-end ATM connection across two connected Cisco 6400 UACs. Using PVC information supplied in the network order, the policy locates the ingress and egress interfaces in CEMF, finds their inter-machine tie (IMT) link, and creates an end-to-end connection from the ingress interface to the egress interface through the IMT link. SCM autoallocates the PVCs used for tie links. If the ingress and egress interfaces are on the same UAC, CNOM makes a single cross-connection within that device.

The policy connectSubscriberToATMService requires that the network order contain the attributes listed in Table 5-1.

Table 5-1: Network Order Attributes for Network Order Policy connectSubscriberToATMService

Attribute	Description
`workOrder:DDMWorkOrder.connectionIdentifier`	A unique identifier for the connection.
`workOrder:DDMWorkOrder.ingressIdentifier`	A line ID value that resolves to an interface in the ingress Cisco 6400 UAC.
`workOrder:DDMWorkOrder.egressIdentifier`	A line ID value that resolves to an interface on the egress Cisco 6400 UAC.
`workOrder:DDMWorkOrder.serviceCharacteristics`	The name of an SCM connection template.
`workOrder:DDMWorkOrder.ingressVPI`	The VPI value to be used on the ingress interface.
`workOrder:DDMWorkOrder.ingressVCI`	The VCI value to be used on the ingress interface.
`workOrder:DDMWorkOrder.egressVPI`	The VPI value to be used on the egress interface.
`workOrder:DDMWorkOrder.egressVCI`	The VCI value to be used on the egress interface.
`workOrder:DDMWorkOrder.linkAction`	Optional IMT primitive action. Tells CNOM how to choose the TieLink.
`workOrder:DDMWorkOrder.linkName`	Optional TieLink name attribute.
`workOrder:DDMWorkOrder.saveForRestore`	Optional attribute. Tells the system not to save information for Data Recovery.
`workOrder:DDMWorkOrder.saveInSysLog`	Optional attribute. Save Data Recovery information to system log file.
`workOrder:DDMWorkOrder.saveInLogFile`	Optional attribute. Save Data Recovery information to specified log file.
`workOrder:DDMWorkOrder.logFileName`	Optional attribute. Defines log file name.
`workOrder:DDMWorkOrder.MakeInvisible`	Optional Attribute. Hide connection object.
`workOrder:DDM.finalWorkOrder`	Optional attribute which when set, causes the contents of the internal work order to be returned to the user. To view error messages, this attribute must be set.

You can run the following script connect_atm to invoke the connectSubscriberToATMService policy:

./connect_atm <ingressID> <egressID> <serviceChar> <ingressVPI> <ingressVCI> <egressVPI> <egressVCI> [ConnId] [-link <TieLink_Name> | -linkAuto] [-noSave | [syslog] -save <file_path_name>] [-hide]

Table 5-2 shows the options available for connect_atm script and the corresponding Network Order attributes.

Table 5-2: Script Options, Corresponding Network Order Attributes and Their Actions

Script Option	Network Order Attributes Set by Option	Attribute Value	Action of Script Option	Action if Option is Not Set
`-noSave`	`workOrder:DDMWorkOrder. saveForRestore`	"NO"	System does not save information for data recovery.	Data recovery information is saved as it was configured in DDMGencUserData.ini file or as defined by `-save -syslog` options, if any.
`-save <file_name>`	`workOrder:DDMWorkOrder.` `saveInLogFile`	"1"	System saves data recovery information to the specified file.	Data recovery information is saved as configured in DDMGencUserData.ini file.
`-save <file_name>`	`workOrder:DDMWorkOrder. LogFileName`	log file name
`-syslog`	`workOrder:DDMWorkOrder. saveInSysLog`	"1"	System saves data recovery information to the system log file.	Data recovery information is saved as configured in DDMGencUserData.ini file.
`-hide`	`workOrder:DDMWorkOrder.MakeInvisible`	"YES"	System hides the connection object created by the connect script to improve system performance.	Connection object is shown in the ConnectionObjects view. Large numbers of connection objects in this ConnectionObjects view can reduce system perfomance.
`-link <Tie link name>`	`workOrder:DDMWorkOrder. linkAction`	"GetLinkInfoByName"	The operator configures CNOM to use a specific Tie Link between two Cisco 6400 chassis.	If you do not specify which IMT link should be used to create an ATM connection by using the -link, -linkAuto, or -linkActive option, then CNOM chooses the IMT link that is configured in the ini file. See the following note for details.
`-link <Tie link name>`	`workOrder:DDMWorkOrder. linkName`	Tie Link Name
`-linkAuto`	`workOrder:DDMWorkOrder.linkAction`	"GetAutoLinkByChassis"	CNOM automatically chooses the IMT link between RT and CLEC chassis with the least number of connections currently assigned.
-linkActive	`workOrder:DDMWorkOrder.linkActive`	"GetActiveLinkByChassis"	CNOM assigns the IMT link that is currently configured to active state.

Note If you do not specify which IMT link should be used to create ATM connection, then CNOM will look into <CEMF>/config/C6400DMMCtrller/C6400DMMCtrllerUserData.ini file to determine the behavior.
For example, this file may contain:
[LoadBalancing] IMTaction=GetActiveLinkByChassis
Possible values for IMTaction are GetActiveLinkByChassis, GetAutoLinkByChassis, where:
- GetActiveLinkByChassis option will make CNOM to choose active IMT when creating connection
- GetAutoLinkByChassis option will make CNOM to choose IMT with the least number of connections on it (use LoadBalancing).

If the ini file is not configured, then the LoadBalancing feature will be used (and CNOM will choose the IMT link with the least number of connections on it). The ini file is not configured by default.

The default behavior of Data Recovery subsystem is defined in <CEMF>/config/DDMGenc/DDMGencUserData.ini file.

For example, if you use the DDMGencUserData.ini file, then Data Recovery information is saved in /opt/cemf/log/connectionsLog.log file only. Use the following script:

[ConfigSave]

ConfigSave.saveInFile=1

ConfigSave.logFileName=/opt/cemf/log/connectionsLog.log

ConfigSave.saveInSyslog=0

Script options {-save, -noSave, -syslog} (and corresponding Network Order attributes) override defaults defined in the DDMGencUserData.ini file.

If you do not use any options with the connect_atm script, then:

Connections are created using the currently active Tie Link
Connection objects are shown in the connectionObject view
Data recovery information is saved in the /opt/cemf/log/connectionsLog.log file.

Note For more information about Common script options (-noSave, -save<file_name>, -syslog, -hide), see Common Arguments for Scripts section on page 3-3.

CNOM Internal Work Flow for connectSubscriberToATMServiceConnection

The following list summarizes the steps that CNOM performs to execute the connectSubscriberToATMService policy:

Initial State: ddmGateway:DDMGenc:C6400DMM.findCLECInterface_CSAS

1. Finds Interface Object: FindMappedObject

2. Finds Chassis Object: GetAncestorPrimitive

3. Gets RT Object: FindMappedObject

4. Finds RT Chassis: GetAncestorPrimitive

5. Gets CLEC Interface name: GetContainmentPath

6. Gets RT Interface name: GetContainmentPath

7. Creates Connection Object: ObjectDeployPrimitive

8. Creates Service Object: ObjectDeployPrimitive

9. Copies values to egress point: Annotate

a. Find RT Egress and CLEC Ingress Interfaces: FindTieLink

b. Copy values to RT Ingress: Annotate

10. Sets attributes of ATM Service: SetupATMService

11. Connects Subscriber: ConnectSubscriber

12. Copies RT values to Egress: Annotate

13. Copies RT values to Ingress: Annotate

14. Sets attributes of ATM Service: SetupATMService

15. Connects Subscriber: ConnectSubscriber

Querying Connections

Use the network order policy getATMConnectionData to gather information about existing connections. The network order policy getATMConnectionData requires the following attributes (Table 5-3).

Table 5-3: Attributes for Network Order Policy getATMConnectionData

Attribute	Description
`workOrder:DDMWorkOrder.connectionIdentifier`	A unique identifier for the connection.
`workOrder:DDM.finalWorkOrder`	Must be set in order for the internal work order to be returned to user. The internal work order contains the results of the query.

The getATMConnectionData policy returns the values of the attributes set on a connection object during execution of the network order policy connectSubscriberToATMService.

Deleting Connections

Use the network order policy disconnectSubscriberAndService to delete the PVCs associated with an end-to-end connection (Table 5-4). You can use the script disconnect_atm to invoke the policy.

Table 5-4: Attributes for Network Order Policy disconnectSubscriberAndService

Attribute	Description
`workOrder:DDMWorkOrder.connectionIdentifier`	The unique identifier assigned to the connection.
`workOrder:DDM.finalWorkOrder`	Optional attribute, which, when set, causes the contents of internal work order to be returned to user.

Managing Service Connections

This section provides information about managing service connections, which are used to connect a subscriber to a service on the Cisco 6400 UAC. CNOM provides policies for managing the following types of services:

PPP over ATM (PPPoA) service
L2TP service
Bridging service
IRB service
RFC 1483 service

To manage services on a Cisco 6400 UAC, you must perform the following steps in CNOM, each of which is described in the sections that follow.

1. Create a service profile.

2. Create a service from a service profile.

3. Connect a subscriber to a service.

Creating Service Profiles

CNOM provides several policies for creating different types of service profiles. Each service profile describes the characteristics for a particular type of service, such as PPPoA or L2TP. After you create a service profile, you can run one of the createservicefromprofile policies to create a service from the settings in the profile.

CNOM provides the following scripts and policies for creating service profiles:

The create_B_profile script invokes the createBridgingServiceProfile policy to create a bridging service profile.
The create_IRB_profile script invokes the createIRBServiceProfile policy to create an IRB service profile.
The create_L2TP_profile script invokes the createL2TPServiceProfile policy to create an L2TP service profile.
The create_PPPoA_profile invokes the createPPPoAServiceProfile policy to create a PPP over ATM service profile.
The create_R_profile script invokes the createRFC1483ServiceProfile policy to create an RFC 1483 service profile.

Following is a summary of the steps performed by each createserviceprofile policy:

1. Finds the containment path for the profile.

2. Creates a profile object.

3. Sets the profile attributes based on command-line or policy parameters.

For more information about these policies, and the corresponding policies for modifying and deleting service profiles, see "Cisco Network Order Manager Policies."

Creating Services

CNOM provides several policies for creating a service from a service profile. Each policy for creating a service profile has a corresponding policy for creating a service from that profile. When you invoke a createservicefromprofile script or policy, you specify the name of the service profile to use to create the service. For example, you would use the policy createL2TPServiceProfile to create an L2TP service profile, and then use the corresponding policy createL2TPServiceFromProfile to create a service from that L2TP service profile.

CNOM provides the following scripts and policies for creating services from profiles:

The create_B_service script invokes the createBridgingServiceFromProfile policy to create a bridging service from the specified profile.
The create_IRB_service script invokes the createIRBServiceFromProfile policy to create an IRB service from the specified profile.
The create_L2TP_service script invokes the createL2TPServiceFromProfile policy to create an L2TP service from the specified profile.
The create_PPPoA_service invokes the createPPPoAServiceFromProfile policy to create a PPP over ATM service from the specified profile.
The create_R_service script invokes the createRFC1483ServiceFromProfile policy to create an RFC 1483 service from the specified profile.

Following is a summary of the steps performed by each createservicefromprofile policy:

1. Finds the NRP and chassis to create the service on.

2. Finds the service profile to use to create the service.

3. Creates a service object.

4. Applies the service profile settings to the service object.

5. Commissions the service object.

For more information about these policies, and the corresponding policies for modifying and deleting services, see "Cisco Network Order Manager Policies."

Connecting Subscribers to Services

The final step in managing SCM service connections is to connect a subscriber to a service. The policy connectSubscriberSCM sets up a connection between an ingress port and a service in a Cisco 6400 UAC. To run the policy successfully, meet the following conditions:

Cisco 6400 UAC is deployed and commissioned.
Service instances are deployed and commissioned.
Service name is configured in LocalDB:C6400DMM.serviceName for the service.
Connection Template objects are deployed and configured.
Line IDs are configured for Cisco 6400 UAC ingress ports.

See the "Configuring Line IDs for CNOM Modules" section for more details.

Following is a summary of the steps performed by the connectSubscriberSCM policy:

1. Identifies the ingress port using the line ID or CEMF object name in the incoming work order.

2. Deploys the subscriber object and configures the subscriber values.

3. Allocates a valid VPI/VCI value if one was not provided by the work order.

4. Invokes a connect action on the subscriber object to perform the connection.

The following optional attributes are supported in work orders for the connection. The attributes are dependent on the type of services to which the connection is made:

workOrder:DDMWorkOrder.rfc1483SubIfIPAddress
workOrder:DDMWorkOrder.rfc1483SubIfSubnetMask
workOrder:DDMWorkOrder.vcIPAddress
workOrder:DDMWorkOrder.rfc1483EncapsType
workOrder:DDMWorkOrder.cpeSupportInArp
workOrder:DDMWorkOrder.ptamdConnectionType
workOrder:DDMWorkOrder.ptamdEncapsType
workOrder:DDMWorkOrder.rbeSubIfIPAddress
workOrder:DDMWorkOrder.rbeSubIfSubnetMask

To disconnect a subscriber from a service, use the disconnectSubscriberSCM policy. You can invoke the policy through the disconnect_scm script.

Table of Contents