Guest

Cisco BTS 10200 Softswitch

PacketCable Feature Guide (Release 4.1)

  • Viewing Options

  • PDF (909.7 KB)
  • Feedback
Cisco BTS 10200 Softswitch Release 4.1 PacketCable Feature Guide

Table Of Contents

Cisco BTS 10200 Softswitch Release 4.1 PacketCable Feature Guide

Contents

Sections In This Document

Cross-Reference of Database Tables Provisioned In These Procedures

Prerequisites for Provisioning PacketCable Features

Restrictions for Provisioning PacketCable Features

Information About PacketCable Features for Release 4.1

New Features and Functions for Release 4.1

Hardware and Software Overview

Network Architecture and External Interfaces

How to Configure the System and Enable DQoS Feature

Using the Command Line Interface—Introduction

Provision DQoS On CMS

Prerequisites

Data Values for DSCP and TOS Parameters

Background Information

Provisioning the TOS and DSCP Values

Provision DQoS on CMTS and MTA Interfaces

Prerequisites

Provisioning DQoS Parameters for Codec Negotiation Service

Prerequisites

Provision DQoS and TGCP On TGW Interface

Prerequisites

COPS Interface Measurements for DQoS Feature

Events and Alarms Specific to PacketCable-Based Nodes

How to Provision the Event Messaging Feature

Billing Data Options

Description of Event Message Feature

Timestamp Support for Event Messages

Event Message Transport

Event Message Storage on CA

Event Message Provisioning

Provisioning Support for EM Transmission and Storage

Provisioning the System to Generate EMs for Billing

Manual Recovery and Transfer of Stored EMs

Recover the Billing Files

FTP Billing Files to the RKS

Compare Checksums

Provisioning Media_Alive Verification for Event Messages

Event Message Generation Details and Content

Measurements for the EM Feature

Events and Alarms for the EM Feature

How to Provision the Security Interface Feature

Security of PacketCable-Based Networks

Configuring System Security Parameter at Software Installation Time

Provisioning Security Interfaces to the MTA

Provisioning Security Interfaces to the CMTS

Provisioning Security Interfaces to the TGW

Provisioning Security Interfaces to the RKS

Provisioning IPsec Security Associations

Provisioning Ciphersuite Encryption and Authentication Algorithms

Events and Alarms for the Security Interface Feature

Appendix A: DQoS Feature Description

DOCSIS Specifications

DQoS Architecture

Appendix B:
Event Message Generation Details and Content

EM Generation Details

EM Content

References

Related Cisco BTS 10200 Softswitch Documentation

Obtaining Documentation

Cisco.com

Documentation CD-ROM

Ordering Documentation

Documentation Feedback

Obtaining Technical Assistance

Cisco.com

Technical Assistance Center

Cisco TAC Website

Cisco TAC Escalation Center

Obtaining Additional Publications and Information


Cisco BTS 10200 Softswitch Release 4.1 PacketCable Feature Guide


The Cisco BTS 10200 Softswitch is a class-independent network switching element. In a PacketCable-based network, it functions as both a call management server (CMS) and a media gateway controller (MGC). It provides call control, call routing, and signaling for several types of multimedia terminal adapters (MTAs and embedded MTAs (EMTAs)), cable modem termination systems (CMTSs), and trunking gateways (TGWs) in PacketCable-based networks. It provides interfaces to record keeping servers (RKSs) and key distribution centers (KDCs). The Cisco BTS 10200 Softswitch also communicates with announcement servers, SS7-based signaling gateways, MGCP-based media gateways (MGWs), and SIP networks.

This Cisco BTS 10200 Softswitch Release 4.1 PacketCable Feature Guide is intended for use by service provider management, system administration, and engineering personnel who are responsible for designing, installing, configuring, and maintaining networks that use the Cisco BTS 10200 Softswitch system in a PacketCable-based network. A familiarity with cable products and networking systems is recommended.

Feature History
 
Release
Modification

Release 3.3

PacketCable feature introduced, including COPS, NCS, DQoS and EM support.

Release 3.5

New alarms added for Release 3.5.

Updates, corrections and clarifications added to this document.

Release 4.1

TGCP and IP Security support added for Release 4.1.
Updated provisioning commands, feature descriptions, and user interfaces.
Removed compliance matrices from scope of this document—these are now provided by the Cisco account team.
Moved operational information about EMs to Appendix B of this document.
Updated wording of BILLING_EM_RETRANS measurement.
Emphasized caution related to storage of EMs on local CA disk when transmission to RKS is unsuccessful.

05/10/2004—Clarified the descriptions of cipher suite tokens.

06/01/2004—Corrected spelling of the token name MAX-DQOS-SESSIONS.

Supported Platforms

Cisco BTS 10200 Softswitch



Caution This document is applicable to Release 4.1 software for the Cisco BTS 10200 Softswitch. If you are running Release 3.5 software, use the document applicable to Release 3.5.

Contents

This feature guide describes the software architecture, external interfaces, provisioning commands, and operational functions provided by the Cisco BTS 10200 Softswitch for support of PacketCable-based features and protocols.

Sections In This Document

The following sections provide an overview of the PacketCable-based features supported by the Cisco BTS 10200 Softswitch:

"Cross-Reference of Database Tables Provisioned In These Procedures"

"Prerequisites for Provisioning PacketCable Features"

"Restrictions for Provisioning PacketCable Features"

"Information About PacketCable Features for Release 4.1"

"New Features and Functions for Release 4.1"

"Hardware and Software Overview"

"Network Architecture and External Interfaces"

The following sections contain provisioning procedures for the PacketCable-based functions:

"How to Configure the System and Enable DQoS Feature"

"How to Provision the Event Messaging Feature"

"How to Provision the Security Interface Feature"

The following additional information is provided:

Measurements:

"COPS Interface Measurements for DQoS Feature"

"Measurements for the EM Feature"

Events and alarms:

"Events and Alarms Specific to PacketCable-Based Nodes"

"Events and Alarms for the EM Feature"

"Events and Alarms for the Security Interface Feature"

"Appendix A: DQoS Feature Description"

"Appendix B: Event Message Generation Details and Content"

"References"

"Related Cisco BTS 10200 Softswitch Documentation"

"Obtaining Documentation"

"Obtaining Technical Assistance"

"Obtaining Additional Publications and Information"

This document should be treated as an addition to the existing Cisco BTS 10200 Softswitch documentation set. See the "Related Cisco BTS 10200 Softswitch Documentation" section.

Cross-Reference of Database Tables Provisioned In These Procedures

Each major section in this document covers a specific task. Several database tables are provisioned in more than one section of this document. Following is a list of tables that are provisioned in more than one section of this document. (Tables that appear in only one section of this document are not included in this cross-reference list.)


Tip The procedures in this document highlight the parameters specifically related to PacketCable-based features in the Cisco BTS 10200 Softswitch. For a complete set of provisioning procedures covering all services and protocols, refer to the Cisco BTS 10200 Softswitch Provisioning Guide.


call-agent-profile table:

"Provision DQoS On CMS" section

"Provisioning Support for EM Transmission and Storage" section

"Provisioning the System to Generate EMs for Billing" section

ca-config table:

"Provision DQoS On CMS" section

"Provisioning Support for EM Transmission and Storage" section

aggr table:

"Provision DQoS on CMTS and MTA Interfaces" section

"Provisioning Security Interfaces to the CMTS" section

mgw-profile table:

"Provision DQoS on CMTS and MTA Interfaces" section

"Provision DQoS and TGCP On TGW Interface" section

"Provisioning Security Interfaces to the MTA" section

"Provisioning Security Interfaces to the TGW" section

mgw table:

"Provision DQoS on CMTS and MTA Interfaces" section

"Provision DQoS and TGCP On TGW Interface" section

termination table:

"Provision DQoS on CMTS and MTA Interfaces" section

"Provision DQoS and TGCP On TGW Interface" section

radius-profile table:

"Provisioning Support for EM Transmission and Storage" section

"Provisioning Security Interfaces to the RKS" section

Tables for IPsec, Kerberos, and Ciphersuite-profile—These tables are specific to the "How to Provision the Security Interface Feature" section.

Prerequisites for Provisioning PacketCable Features

The following tasks should already be completed before starting to provision PacketCable features on the Cisco BTS 10200 Softswitch:

The Cisco BTS 10200 Softswitch hardware should already be installed, cabled, and powered, and the Release 4.1 software should already be installed. Use the applicable documentation for those tasks (refer to the "Related Cisco BTS 10200 Softswitch Documentation" section).

The other network elements (NEs), such as MTAs, CMTSs, TGWs, and RKSs (as applicable to your network) should already be deployed and provisioned according to the documentation provided with those NEs.

Restrictions for Provisioning PacketCable Features

It is recommended that you verify interoperability of the Cisco BTS 10200 Softswitch with other NEs in the network as described in the "Component Interoperability" section in the Release 4.1 Release Notes document.

Information About PacketCable Features for Release 4.1

This section provides information about Cisco BTS 10200 Softswitch support for PacketCable functions:

New Features and Functions for Release 4.1

Hardware and Software Overview

Network Architecture and External Interfaces

New Features and Functions for Release 4.1

The following PacketCable-based features and functions have been introduced in the Cisco BTS 10200 Release 4.1 software, and are included in the descriptions and procedures of this document:

PacketCable-based security features

Common Open Policy Service (COPS) interface measurements

DQoS gate coordination function

TGCP support

In addition, this document provides the following updated information for PacketCable-based features:

Command line interface (CLI) provisioning

Alarms and events

Traffic measurements


Note For detailed information on compliance to specific paragraphs of the Internet Engineering Task Force (IETF) standards (for TGCP, IP Security, NCS, and so forth), please contact your Cisco account team.


Hardware and Software Overview

The PacketCable features are built on the existing Cisco BTS 10200 Softswitch software and hardware platform. There are no new hardware features required for the Cisco BTS 10200 Softswitch for the PacketCable features described in this document.

The following features are included in the Cisco BTS 10200 Softswitch Release 4.1 software:

Call Agent (CA) software subsystems for PacketCable-based features:

Event Messages for PacketCable billing

Common Open Policy Service (COPS) stack

COPS adapter

Network-Based Call Signaling (NCS) stack

NCS adapter

Trunking Gateway Control Protocol (TGCP) stack

TGCP adapter

Support for IPsec functions

Support for Internet key exchange (IKE) and Kerberos interfaces

Updates to external interfaces for DQoS, COPS, Event Messages, NCS, TGCP, CALEA, IPsec, IKE and Kerberos functions, and gate coordination

Network Architecture and External Interfaces

Figure 1 shows a typical network with PacketCable-based network elements and the applicable external interfaces of the Cisco BTS 10200 Softswitch. In the PacketCable-based network, the Cisco BTS 10200 performs the functions of both the CMS and MGC.

Figure 1 Example of PacketCable-Based Network Architecture


Note The office applications referred to in Figure 1 include announcements, voice mail, and interactive voice response systems.


As shown in Figure 1, the following external interfaces (and protocols) are supported for PacketCable features on the Cisco BTS 10200 Softswitch. The Cisco BTS 10200 Softswitch also provides user interfaces for configuring and provisioning these features.

CMS/MTA (NCS)—CMS to MTA interface for subscriber access, with Kerberos support for security


Note The Cisco BTS 10200 supports communications with stand-alone MTA units, and with embedded MTA (EMTA) units. EMTAs are MTAs that are built into cable modem sets. In this document, reference to MTAs is intended to include EMTAs.


CMS/CMTS (COPS)—CMS to CMTS interface for gate management, with IPsec/IKE support for encryption and authentication

CMS/RKS (EM over RADIUS)—CMS to RKS interface for EM-based billing functions, with IPsec/IKE support for encryption and authentication

MGC/RKS (EM over RADIUS)—MGC to RKS interface for EM-based billing functions, with IPsec/IKE support for encryption and authentication

CMS/CALEA (EM over RADIUS)—CMS to CALEA interface, with IPsec/IKE support for encryption and authentication

MGC/TGW (TGCP)—MGC to TGW interface for TGW management, which allows calls to be connected between the PacketCable network and the PSTN


Note For a description of Cisco BTS 10200 Softswitch support for CALEA, see the Cisco BTS 10200 Softswitch System Description. For provisioning procedures related to CALEA support, see the Cisco BTS 10200 Softswitch Provisioning Guide.


The following additional interfaces are not part of the PacketCable feature set, but they provide other important functions useful in the service provider network.

Cisco BTS 10200 Softswitch/Signaling Gateway (SIGTRAN)—This interface allows calls to be made between the PacketCable network and the PSTN. The CA of the Cisco BTS 10200 Softswitch interfaces to an Internet transfer point (ITP) signaling gateway (SG), for example, the Cisco 7500 Series Router. The ITP SG provides an SS7-based interface to the STP (PSTN). The supported ISDN user part (ISUP) types are North American ANSI ISUP, China ISUP, and Mexico ISUP.

MGCP Interface—The Cisco BTS 10200 Softswitch communicates with MGCP-based TGWs that provide bearer path to the PSTN.

SIP Interface—Session initiation protocol (SIP) signaling is used for access to voice mail. In addition, SIP can be used for tandem calls from one Cisco BTS 10200 Softswitch to another.

Cisco BTS 10200 Softswitch /office applications (SNMPv3 and CORBA over TCP/IP)
This interface provides communication with OSS and office applications servers (applications such as announcements and interactive voice response (IVR) systems).

As shown in Figure 1, There is no interface between the KDC and the Cisco BTS 10200 Softswitch. To ensure secure NCS signaling, the dynamic key exchange for IPsec security operation between the MTA and the Cisco BTS 10200 Softswitch is achieved as follows. (These procedures are described in the PacketCable Security specification under Kerberized IPsec and other sections.)

Manual key provisioning must be used to match data stored in the KDC with data stored in the Cisco BTS 10200 Softswitch (pre-setup)

The MTA must contact the KDC to obtain the key to talk to the server, which is in this case the Cisco BTS 10200 Softswitch.

The Cisco BTS 10200 Softswitch performs the gate coordination functions of a CMS, including the gate controller (GC), in the PacketCable environment. Gate coordination signaling is based on the COPS stack. Each CMTS informs the CMS when a gate is successfully opened or closed. Two gate coordination messages are used, GATE-OPEN and GATE-CLOSE. Gate coordination is required to avoid several theft-of-service scenarios, as described in Appendix K of the PacketCable Dynamic Quality-of-Service Specification, PKT-SP-DQOS-I05-021127, November 27, 2002. The gate coordination process for GATE-OPEN signaling is illustrated in Figure 2. The process for GATE-CLOSE signaling is similar.

Figure 2 Gate Coordination Signaling Example (GATE-OPEN Signaling Shown)


Note A more detailed description of the DQoS architecture is presented in "Appendix A: DQoS Feature Description" at the end of this document.


How to Configure the System and Enable DQoS Feature

This section describes how to provision the Cisco BTS 10200 Softswitch to perform the functions of the CMS and MGC in a DQoS capable network. It also describes how to provision signaling links to the other network elements (NEs) involved in the DQoS function—CMTS, MTA, and TGW.

The following procedures use the Cisco BTS 10200 Softswitch command line interface (CLI).

Using the Command Line Interface—Introduction

"Provision DQoS On CMS" section

Data Values for DSCP and TOS Parameters

Provision DQoS on CMTS and MTA Interfaces

Provisioning DQoS Parameters for Codec Negotiation Service

Provision DQoS and TGCP On TGW Interface

Using the Command Line Interface—Introduction


Note The description below is a brief summary of CLI usage, intended to highlight the type of commands used to provision PacketCable-related features. For more complete information about using the CLI, including a complete list of all possible commands and parameters, refer to the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.


To use the command line interface (CLI), begin by opening a secure shell (SSH) session to the active EMS unit of the Cisco BTS 10200 Softswitch. Use the user name and password assigned to you for logging into the CLI application. When you are in the CLI application, only the command prompt (CLI>) appears on the screen.

To enter commands using the CLI, enter the entire command as shown in the examples that follow, along with all of its required parameters (tokens). Most commands are written as:

add [name of database table] parameter1=<value1>; parameter2=<value2>; ...

Only the database tables and parameters applicable to the specific PacketCable feature are shown in this document. Additional tables and parameters (applicable to other features) are presented in theCisco BTS 10200 Softswitch Provisioning Guide and the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.

In some cases, you will be entering a command for a table instance that does not yet exist. In this case you must use the add command as shown above. However, if that table instance already exists, and you will be adding or changing some of the parameters, then you must use the change command instead of the add command:

change [name of database table] parameter1=<value1>; parameter2=<value2>; ...

You can find out if a table instance already exists by using the show command, including optional parameters to narrow the query:

show [name of database table]

show [name of database table] parameter1=<value1>; parameter2=<value2>; ...


Note Unless otherwise noted, commands and values must be entered in the exact format shown in the examples.



Tip When provisioning the database using CLI, keep in mind that some of the default values for parameters are acceptable for the application at hand. But some default values are not acceptable for the specific application, and you must enter a value that is compatible with PacketCable-based functionality.


This document uses the notation defined in the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide:

Brackets < > indicate a user-defined value.

If only a single option from a list is allowed, the choices are separated by a vertical bar ( | ).

The following conventions apply to the commands:

All commands start with a verb.

A noun immediately follows the verb if appropriate.

Each value is terminated by a semicolon.

In some cases, a token can contain several values separated by commas.

All parameter (token) names, command verbs, and command nouns are case insensitive.

Typically, values entered after the equal sign (=) in a command are case insensitive, except component names.


Caution You must enter system component names in the case in which they were originally added to the system. For example, if a Call Agent ID was entered in uppercase (CA146), you must always enter it in uppercase or you will get an error message.

White space is allowed in a value field if the value type is an ASCII character string.

The following characters are invalid in all ASCII character commands:

Double quotation marks (" ")

Single quotation marks (` ')

Using either of these characters will return an error message.

Provision DQoS On CMS

This section describes how to provision DQoS functionality for the CMS logical entity on the Cisco BTS 10200 Softswitch (Call Agent). The following tables are provisioned:

Call Agent Profile (call-agent-profile) table—Includes a DQoS support parameter

Call Agent Configuration (ca-config) table—Defines the default timer values for each CMS

Prerequisites

You must be logged into a CLI session to enter these commands.

SUMMARY STEPS

1. Enable DQoS support in call-agent-profile table

2. Set CMS timers (optional—if using other than default values)

3. Set local ringback flag (optional—default is Y)

4. Set the differential service code point (DSCP) for COPS (optional—default is 96)

DETAILED STEPS


Note The token values shown in this section are examples.



Step 1 To enable DQoS support for a specific Call Agent Profile (call-agent-profile) table enter the following command:


Tip The following command is shown as "change call-agent-profile ...". However, if the system responds that the call-agent-profile ID does not exist, reenter the command as "add call-agent-profile" instead of "change call-agent-profile".


change call-agent-profile id=CA146; dqos-supp=y; description=BostonCA33

where:

id—Domain name of the specific Call Agent (CA), in the format CAnnn, where nnn = 3-digit number previously assigned to the CA. This value is case-sensitive (CA146 and ca146 are not the same). This is the unique identifier for this CA (CMS/MGC) node, which was permanently assigned at time of software installation on the Cisco BTS 10200 Softswitch. CA profile IDs are used for EM correlation at the RKS.

dqos-supp—Determines whether DQoS is supported by this CA (CMS). The value of this optional token is a single ASCII character (Y or N); the default value is N (no), which means that DQoS is NOT supported. The token must be set to Y (yes) to provide support for DQoS by this CA.

description—A user defined description of the CA, 1 to 64 ASCII characters in length.

Step 2 To specify values other than the defaults for each CMS timers in the CA configuration (ca-config) table, you can complete any (or all) of the following sub-steps:


Tip The following commands are shown as "change ca-config ...". However, if the system responds that the parameter does not exist, reenter the command as "add ca-config" instead of "change ca-config".



Tip The default values for these timers may be adequate for your specific case. In each case, you can use the show command to find out how the parameter is currently set.


a. To reset the timeout value for the DQOS-T1-TIMER, enter the following command:

change ca-config type=DQOS-T1-TIMER; datatype=integer; value=250;

where:

type—DQOS-T1-TIMER is used by the CMTS for dynamic quality of service (DQOS). It starts when a gate is allocated, and is reset when a gate goes into a committed state. The T1 timer is provided by CMS to CMTS in a GATE-SET message.The DQOS-T1-TIMER value is used by a CMTS to limit the time that can elapse between the authorization and the commit to ensure that DQoS resources are released in case of an error.

datatype—Defines the characteristic of the value that follows.

value—Defines the timeout period in seconds for the DQOS-T1-TIMER. The range of values is 0 through 500 seconds, but it is recommended to use values only in the range 200 to 300. The default value is 200 seconds.

b. To reset the timeout value for the DQOS-T5-TIMER, enter the following command:

change ca-config type=DQOS-T5-TIMER; datatype=integer; value=10;

where:

type—DQOS-T5-TIMER timer controls the synchronization between local MTA resource release and CMTS verification of the closure of the local gate (ECN-02148-v7). When the CMS (CA) sends the MTA a message to delete (DLCX) a connection, the CMS must ensure that the gate is closed in the CMTS within T5. This timer is cleared when the CMS receives a confirmation for the local gate closure using the gate-close message from the CMTS. On expiration of this timer, the CMS (CA) deletes the gate at the CMTS using gate-delete message with "Local gate-close failure" described in the reason-code.

datatype—Defines the characteristic of the value that follows.

value—Defines the timeout period in seconds for the DQOS-T5-TIMER. The range of values is 1 through 60 seconds. The default (recommended) value is 5 seconds.

c. To reset the timeout value for the DQOS-T7-TIMER, enter the following command:

change ca-config type=DQOS-T7-TIMER; datatype=integer; value=180;

where:

type—DQOS-T7-TIMER is sent from the CMS to the CMTS in a GateSet message. It defines the timeout period in seconds that the CMTS must hold resources for a service flow's Admitted QoS Parameter Set while they are in excess of its Active QoS Parameter Set. It is used by the CMTS to ensure that DQoS resources are released in case of an error.

datatype—Defines the characteristic of the value that follows.

value—Defines the timeout period in seconds for the dqos-t7-timer. The range of values is 0 through 300 seconds. The default (recommended) value is 200 seconds.

d. To reset the timeout value for the DQOS-T8-TIMER enter the following command:

change ca-config type=DQOS-T8-TIMER; datatype=integer; value=100;

where:

type—DQOS-T8-TIMER is sent from the CMS to the CMTS in a GateSet message. The DQOS-T8-TIMER value defines the period of time in seconds that committed CMTS resources can remain unused. It is used by a CMTS to ensure that DQoS resources are released in case of an error.

datatype—Defines the characteristic of the value that follows.

value—Defines the timeout period in seconds for the DQOS-T8-TIMER. The range of values is 0 through 300 seconds. The default value is 0 seconds, which instructs the CMTS not to poll for activity on the service flow.

e. To reset the value for the DQOS-US-SLACK-TERM, enter the following command:

change ca-config type=DQOS-US-SLACK-TERM; datatype=integer; value=<upstream slack term>;

where:

type—DQOS-US-SLACK-TERM is a value provided by the CMS, and used by the CMTS for tolerated grant jitter for upstream flows, in microseconds.

datatype—Defines the characteristic of the value that follows.

value—The range of values is 0 through 60000. The default value is 800 microseconds for the upstream direction.

f. To reset the value for the DQOS-DS-SLACK-TERM, enter the following command:

change ca-config type=DQOS-DS-SLACK-TERM; datatype=integer; value=<downstream slack term>;

where:

type—DQOS-DS-SLACK-TERM is a value provided by the CMS, and used by the CMTS for tolerated latency for downstream flows, in microseconds.

datatype—Defines the characteristic of the value that follows.

value—The range of values is 0 through 60000. The default value is 0 for the downstream direction, which indicates no restrictions on latency.

g. To reset the timeout value for a CMTS to respond to a Gate command issued by the CMS,
enter the following command:

change ca-config type=DQOS-GATE-TIMER; datatype=integer; value=3;

where:

type—DQOS-GATE-TIMER specifies the CMTS gate operation response timer in seconds.

datatype—Defines the characteristic of the value that follows.

value—Defines the timeout period in seconds for the DQOS-GATE-TIMER. The range of values is 0 through 10. The default value is 2.

Step 3 To turn the local ringback option on or off, enter the following command:


Note This feature should be turned on for the calling party to receive a local ringback for on-net to on-net calls in a PacketCable network. Note that this feature is different from the "ringback on connection" feature that is provisioned for the MTA in the mgw-profile table.


change ca-config type=LOCAL-RINGBACK; datatype=boolean; value=Y;

where:

type—LOCAL-RINGBACK specifies whether the Cisco BTS 10200 sends a local ringback to the calling party. The system checks this flag only for basic on-net to on-net calls.

datatype—Defines the characteristic of the value that follows.

value—Y or N, specifies whether local ringback is turned on (Y) or off (N). The default value is Y (yes).

Step 4 To set the differential service code point (DSCP) for signaling packets on COPS interfaces between the CMS and CMTS, enter the following command:

Example:

change ca-config type=COPS-DSCP-TOS; datatype=integer; value=240;

where:

type—COPS-DSCP-TOS specifies the Differentiated Services Code Point (DSCP) value or type of service (TOS) value Used for the signaling packets on COPS interfaces between CMS and CMTS. For DSCP, only bits 0-5 are used; for TOS, bits 0-2 are used for IP Precedence, and bits 3-6 for IPv4 IP TOS.

datatype—Defines the characteristic of the value that follows.

value—A number from 0 through 255; the default value is 96. These DSCP and TOS values are described more fully in Table 1 and Table 2 in the "Data Values for DSCP and TOS Parameters" section.


Note The call-agent-profile and ca-config tables have many other tokens that support other characteristics of the Call Agent (CMS). For more detailed information, see the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.



Data Values for DSCP and TOS Parameters

This section describes the DSCP and IP TOS parameter values. (In this section, x-dscp-tos refers to any of these three parameters.)

DQOS-CMTS-DSCP-TOS in the QOS table (applicable to voice traffic)

COPS-DSCP-TOS and RADIUS-DSCP-TOS in the CA-CONFIG table (applicable to signaling traffic)


Tip (DSCP provides a greater differentiation of service precedence levels than TOS, but some network routers are currently able to support TOS only.)


Background Information

The provisionable values for the x-DSCP-TOS parameters are the decimal numbers 0 to 255. They are based on the binary data described in this section.


Note The bit map diagrams in this section can be found in IETF RFC791 for TOS, and IETF RFC2474 for DSCP.


For TOS, the bits are mapped as follows (see Figure 3):

Bits 0-2: Precedence

111 = Network Control

110 = Internetwork Control

101 = Critical

100 = Flash Override

011 = Flash

010 = Immediate

001 = Priority

000 = Routine

Bit 3: 0 = normal delay, 1 = low delay

Bit 4: 0 = normal throughput, 1 = high throughput

Bit 5: 0 = normal reliability, 1 = high reliability

Bits 6-7: Reserved for future use

Figure 3 IPv4 TOS Bits

For DSCP, the bits are mapped as follows (see Figure 4):

Bits 0-5: 0 = DSCP value

Bits 6-7: Reserved for future use

Figure 4 DSCP Bits

Provisioning the TOS and DSCP Values


Note The default values shown in this section are the recommended values.


If you are using TOS precedence levels, use the values in Table 1.

Table 1 Values for x-dscp-tos Token Using TOS Precedence Levels 

TOS Precedence Level
P 1
D 1
T 1
R 1
     
Level Number
Description
       
Binary
Value
Decimal (Value To Provision
for Token)
Comments

0

Routine

000

0

0

0

000 000 00

0

 

0

0

1

000 001 00

4

 

0

1

0

000 010 00

8

 

0

1

1

000 011 00

12

 

1

0

0

000 100 00

16

 

1

0

1

000 101 00

20

 

1

1

0

000 110 00

24

 

1

1

1

000 111 00

28

 

1

Priority

001

Note See 2

001 000 00

32

 

2

Immediate

010

010 000 00

64

 

3

Flash

011

011 000 00

96

Default value for signaling traffic
(applicable to COPS-DSCP-TOS and RADIUS-DSCP-TOS tokens)

P=011 (Flash), D=0, T=0, R=0 (Normal)

4

Flash Override

100

100 000 00

128

 

5

Critical

101

101 000 00

160

Default value for voice traffic (applicable to DQOS-CMTS-DSCP-TOS token)

P=101 (Critical), D=0, T=0, R=0 (Normal)

6

Internetwork Control

110

110 000 00

192

 

7

Network Control

111

111 000 00

224

 

1 P = Precedence, D = Delay, T = Throughput, R = Reliability

2 To provision values for D, T, and R, change bits 3, 4, and 5 as necessary and convert to decimal.


If you are using DSCP codes, use the values in Table 2.

Table 2 Values for x-dscp-tos Token Using DSCP Codes 

DSCP Code
Value To Provision for Token
Comments

0

0

 

1

4

 

2

8

 

3

12

 

4

16

 

5

20

 

6

24

 

7

28

 

8

32

 

9

36

 

...

...

 

23

92

 

24

96

Default value for signaling traffic
(applicable to COPS-DSCP-TOS and RADIUS-DSCP-TOS tokens)

25

100

 

...

...

 

40

160

Default value for voice traffic
(applicable to DQOS-CMTS-DSCP-TOS token)

...

...

 

63

252

 

Provision DQoS on CMTS and MTA Interfaces

This section describes how to provision the interfaces to the CMTS and MTA nodes:

CMTS—The Aggregation (aggr) table is used to define the aggregation device used in PacketCable or MGCP based networks. This table holds Cable Modem Termination System (CMTS) and Edge Router (ER) related information. PacketCable networks use CMTSs, while MGCP networks use ERs. The CMTS node configuration table is user-created and user-maintained through the CLI and is used by the COPS adapter to establish and terminate TCP connections to the CMTS. When a TCP connection is established, the CMTS initiates a client-open procedure to establish end-to-end client connectivity.

MTA—MTA provisioning involves three commands:

add/change mgw-profile

add/change mgw

add/change termination


Note The Cisco BTS 10200 Softswitch uses the media gateway (MGW) and MGW profile commands to provision connections to the MTAs. The supported MGCP variant is NCS.


The mgw-profile table provides templates for defining each type of MTA by hardware vendor. It identifies the specifications and settings necessary for communications between the Cisco BTS 10200 Softswitch (which functions as the CMS) and each type of MTA. A media gateway profile ID must be created in this table before entries can be added to the media gateway (mgw) table. Several tokens have values that can be overwritten after the Cisco BTS 10200 Softswitch (CMS) queries the MTA for supported capabilities. If the MTA returns a value different from the value originally provisioned in the Cisco BTS 10200 Softswitch, the returned value automatically replaces the originally provisioned value.

The Media Gateway (mgw) table holds information about each MTA managed by the Cisco BTS 10200 Softswitch (CMS). The MTA can be uniquely addressed by domain name, an IP address, or the TSAP address.

The Termination (termination) table holds information about each endpoint in MTAs managed by the CMS. Termination events and signals are grouped into packages, which are groupings of events and signals supported by a particular type of endpoint, such as an MTA endpoint. One or more packages can exist for a given endpoint-type.

Prerequisites

You must be logged into a CLI session to enter this command.

SUMMARY STEPS

1. Enable DQoS support in the aggr table for a CMTS

2. Enable DQoS support for each type of MTA in the mgw-profile table

3. Enable DQoS support in the mgw table for an MTA

4. Bring the MTA into service

5. Add the line termination for an MTA

6. Equip the termination and place it in service

DETAILED STEPS


Note The token values shown in this section are examples.



Step 1 To create a CMTS node, and enable DQoS support, enter the following command:

add aggr id=[aggr-name]; tsap-addr=[DNS/IP-address]; dqos-supp=[y|n]; ka-timer=[timeout-period];

where:

id—Specifies the user-defined ID for the CMTS (or ER). The ID can be from 1 to 16 ASCII characters. There is no default value.

tsap-addr—Specifies the DNS/IP address for the CMTS (or ER). The entry can be 1 to 64 ASCII characters. There is no default value.


Note If you enter a DNS address for tsap-addr, it must be a fully qualified domain name (FQDN).



Note The aggr id and tsap-addr are both required to create a CMTS (or ER) node.


dqos-supp—This token must be set to Y for the CMTS (or ER) to support DQoS.

ka-timer—Specifies the time to wait (in seconds) before sending a keep-alive message to a CMTS. The range of values is 1 through 10 seconds, the default value is 2 seconds.

Example

add aggr id=CMTS1; tsap-addr=190.101.100.123; dqos-supp=y; ka-timer=2;

The system also supports a status aggr command to display the service state of the aggregation device. The aggr service state can be INS (in service), OOS (out of service), or CONNECTING. CONECTING state means that the Cisco BTS 10200 Softswitch is reattempting to connect to the CMTS.


Note The aggr table has other tokens that support other characteristics of aggr devices (CMTS). For more detailed information, see the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.


Step 2 To enable DQoS support for this type of MTA, enter the following command:

add mgw-profile id=cvmdqos; vendor=cisco; mgcp-version=MGCP-1-0; mgcp-variant=NCS-1-0; mgcp-default-pkg=LINE; codec-neg-supp=[y|n]; pc-mptime-supp=[y|n]; mgcp-hairpin-supp=[y|n]; mgcp-hairpin-z2-supp=[y|n]; rbk-on-conn-supp=[y|n]; mgcp-xdlcx-supp=[y|n]: domain-name-caching-supp=[y|n]; mgcp-conn-id-at-gw-supp=[y|n];

where:

id—ID assigned to this mgw-profile by the service provider. This ID is required and can be 1 through 16 ASCII characters. There is no default value.

vendor—Name of the gateway manufacturer. This token is required and can be 1 through 32 ASCII characters. There is no default value; however, "Cisco" is preferred.

mgcp-version—Set to MGCP-1-0 for an MTA (this is the default value)

mgcp-variant—Set to NCS-1-0 to create a MGW profile for an MTA

mgcp-default-pkg—Set to LINE for an MTA.

codec-neg-supp—This token instructs the Cisco BTS 10200 Softswitch whether to use codec negotiation for calls on the MTA configured with this mgw-profile. The possible values of this token are Y (default) and N.

If codec-neg-supp=Y — Codec negotiation is supported. This enables the Cisco BTS 10200 Softswitch to negotiate codec usage between the originating and terminating MGW. The Cisco BTS 10200 Softswitch uses the preferred codec type (the value of the codec-type parameter in the qos table for the subscriber on this MTA) as the highest priority in the codec list.

If codec-neg-supp=N — Codec negotiation is not supported. The Cisco BTS 10200 Softswitch uses only the preferred codec type (the value of the codec-type parameter in the qos table for the subscriber on this MTA). The Cisco BTS 10200 Softswitch does not attempt to negotiate other codec types with the MTA.


Note (Refer to the "Provisioning DQoS Parameters for Codec Negotiation Service" section for additional information on codec types.)


pc-mptime-supp—Specifies whether MGW (MTA) supports "MP" (multiple packetization) which means individual packetization periods for each codec as defined by PacketCable ECN MGCP-N-02101. This flag is applicable only if MGCP-VARIANT=NCS-1-0 or TGCP-1-0. Verify that this parameter is set to Y, which is the default value.

mgcp-hairpin-supp—Specifies whether the MGW supports TDM bus hairpinning. The possible values are Y (yes) and N (no). The default value is Y. If the MTA supports TDM hairpinning, this token can be set to Y, and the Cisco BTS 10200 Softswitch will instruct the MTA to perform TDM hairpinning. If the MTA does not support TDM hairpinning, the value of this token must be set to N, and the Cisco BTS 10200 Softswitch will use the RTP hairpinning method.


Note TDM = time-division multiplexing; RTP = real-time transfer protocol.


mgcp-hairpin-z2-supp—The possible values are Y (yes) and N (no). The default value is N. If the mgcp-hairpin-supp token is set to Y, you should also provision the mgcp-hairpin-z2-supp token, which specifies the hairpin connection type. If this token is set to Y, the Cisco BTS 10200 Softswitch sends a single create connection (CRCX) message specifying both endpoints in the hairpin connection. If this token is set to N, two separate CRCX messages are sent to the originating and terminating endpoints on the MTA.


Note The mgcp-hairpin-supp token has precedence over this token. If mgcp-hairpin-supp is set to N, the mgcp-hairpin-z2-supp field is ignored.


rbk-on-conn-supp—Specifies whether the MGW has the ability to send a ringback signal to the calling party on connection setup. The default value of rbk-on-conn-supp is Y.

mgcp-xdlcx-supp—Specifies whether the MGW supports the Request Identifier (X) parameter in the received DLCX messages without the CallId (I) and ConnectionId (I) parameters. Verify that this value is set to N (the default value).

domain-name-caching-supp—Specifies whether the MGW supports IP address caching. Set this value to Y (default value) for best processing performance.

mgcp-conn-id-at-gw-supp—Determines how the Cisco BTS 10200 Softswitch interprets and handles audit endpoint (AUEP) ACK messages. If set to Y (default), the system deletes only the connections on the endpoint identified in the AUEP ACK messages. If set to N, the system deletes all connections on the endpoint upon receipt of an AUEP ACK message. For an MTA, use the default value (Y) for this token.


Note The mgw-profile table has many other tokens that support other characteristics and other types of media gateways. For more detailed information, see the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.


Step 3 To enable DQoS support for a specific MTA, enter the following command:

add mgw id=cvm50; tsap-addr=<DNS or IP address of the MTA>; call-agent-id=CA146; mgw-profile-id=cvmdqos; type=rgw; aggr-id=cmts1;

where:

id—Media Gateway identifier, assigned by the service provider. This required token can be from 1 through 32 ASCII characters. There is no default value.

tsap-addr—Specifies the DNS/IP address for the MTA. You can also enter the DNS/IP address and port number. The entry can be 1 through 64 ASCII characters. There is no default value.

call-agent-id—ID of the call-agent the subscriber is assigned to in the Call Agent table. This required token can be from 1 through 8 ASCII characters. There is no default value.

mgw-profile-id—ID of the mgw-profile the subscriber is assigned to in the MGW Profile table. This required token can be from 1 through 16 ASCII characters. There is no default value.

type—The value of this token is three ASCII characters (RGW or TGW). This optional token must be set to RGW if the gateway is a PacketCable-based MTA.

aggr-id—ID of the aggregation device (CMTS). This token is mandatory if supporting PacketCable DQoS; it is how the Cisco BTS 10200 Softswitch (CMS) determines the CMTS to which an MTA is attached, so it can issue gate control commands to the correct CMTS. This required token can be from 1 through 16 ASCII characters. There is no default value.


Note The mgw table has many other tokens that support many other characteristics of media gateways. For more information, see the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.


Step 4 Provision MTA terminations by entering a command similar to the following:

add termination prefix=aaln/; port-start=1; port-end=2; type=LINE; mgw-id=cvm50;

where:

id—This is a composite value that identifies the termination. The termination's id is generated from the prefix, port-start and port-end token parameters, as follows:

prefix—This user-assigned token is required and can be from 1 to 32 ASCII characters.

port-start—This required token can be from 1 to 4 numeric characters. The default is 1.

port-end—This required token can be from 1 to 4 numeric characters. The default is 24.

type—Termination type. The value of this token should always be "LINE" for MTAs.

mgw-id—The id previously assigned to this MTA in the mgw table. (See Step 3 above.)

Step 5 Enter the following command to bring the MTA into service, and verify.

control mgw id=cvm50; target-state=INS; mode=forced;

status mgw id=cvm50;

Step 6 Use the following commands to equip the termination, place it in service (INS state), and verify:

equip subscriber-termination id=sub11;

control subscriber-termination id=sub11; target-state=INS; mode=FORCED;

status subscriber-termination id=sub11;


Note The termination table has other tokens that support other termination characteristics. For more information, see the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.



Provisioning DQoS Parameters for Codec Negotiation Service

The Quality of Service (qos) table is used in providing the codec negotiation service. Codec negotiation is the process the Cisco BTS 10200 Softswitch uses to find a common codec for the compression or decompression of a signal between two gateways. The qos table is pointed to by the subscriber table.

The following commands allow you to specify the required characteristics for the qos table.

Prerequisites

You must be logged into a CLI session to enter this command.

SUMMARY STEPS

1. Provision QoS parameters

2. Repeat, if necessary, for additional QoS levels

DETAILED STEPS


Note The token values shown in this section are examples.



Step 1 At the CLI prompt enter the following add command:

add qos id=gold-service; max-dqos-sessions=5; lptime=20; hptime=20; codec-type=PCMU; max-dqos-auth-bandwidth=HIGH; dqos-cmts-dscp-tos=240;

where:

id—User-defined qos profile name. This mandatory token can be 1 to 16 ASCII characters. There is no default value.

max-dqos-sessions—The maximum number of DQoS sessions allowed for this subscriber. The range of values for this mandatory token is 1 through 50; the default value is 5.

lptime—Lower packetization time in milliseconds. This is a numeric value from 5 to 50 (default 10).

hptime—Higher packetization time in milliseconds. This is a numeric value from 5 to 50 (default 10).


Note For a PacketCable-based call to be set up, the two CMTSs involved in a call (the originating and terminating CMTSs) must agree on the packetization rate when they connect to the Cisco BTS 10200 (CMS). Normally, the two CMTSs report their packetization rate automatically. However, if one of the CMTS units fails to report dynamically, the provisioned values for lptime and hptime will be used in the call.

This feature applies to CMTSs only, and is not active for MGCP-based signaling.


codec-type—Preferred codec type, such as PCMU, PCMA, G.728, and so forth, to be used on calls originating from the subscriber configured with this QoS. When communicating with a MGW, the Cisco BTS 10200 Softswitch checks the provisioning of this token to look up the preferred codec type for the originating end point. This is the highest priority codec in the list sent by the Cisco BTS 10200 Softswitch to the MTA in the CRCX message.


Note The rest of the codec list is based on the data in the AUEP ACK message.


max-dqos-auth-bandwidth—A value of HIGH refers to codec G.711. A value of LOW refers to codec G.72x. For DQoS functionality, set this token to HIGH.

dqos-cmts-dscp-tos—The Differentiated Services Code Point (DSCP) value or type of service (TOS) value to be sent to the CMTS in the gate-set message. This affects the QoS level for the packets (media traffic) that are about to enter the service provider network from the CMTS. The range of values for this optional token is 0 through 255; the default value is 160.


Note The operator can provision a value either for the DSCP byte, or for the IPv4 TOS byte, for each subscriber. When the subscriber makes a call, the DSCP/TOS value is provided to a CMTS in the gate-set message. The CMTS inserts the DSCP/TOS value into IP packets before delivering the packets to the IP core. Routers in the IP network use this value to make pre-hop behavior (PHB) decisions about packet classification and traffic conditioning functions.


These DSCP and TOS values are described more fully in Table 1 and Table 2 in the "Data Values for DSCP and TOS Parameters" section.

Step 2 If necessary, repeat this command for additional QoS services (additional IDs).


Note The qos table has several other tokens. For more information, see the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.



Provision DQoS and TGCP On TGW Interface

The Cisco BTS 10200 Softswitch uses the media gateway (MGW) and MGW profile commands to provision connections to the trunking gateways (TGWs). The supported MGCP variant is TGCP.
TGW provisioning involves three commands:

add/change mgw-profile

add/change mgw

add/change termination

The mgw-profile table provides templates for defining each type of TGW by hardware vendor. It identifies the specifications and settings necessary for communications between the Cisco BTS 10200 Softswitch (which functions as the MGC) and each type of TGW. A media gateway profile ID must be created in this table before entries can be added to the media gateway (mgw) table. Several tokens have values that can be overwritten after the Cisco BTS 10200 (MGC) queries the TGW for supported capabilities. If the TGW returns a value different from the value originally provisioned in the Cisco BTS 10200, the returned value automatically replaces the originally provisioned value.

The Media Gateway (mgw) table holds information about each TGW managed by the Cisco BTS 10200 (MGC). The TGW can be uniquely addressed by domain name, an IP address, or the TSAP address.

The Termination (termination) table holds information about each endpoint (TGW) managed by the MGC. Termination events and signals are grouped into packages, which are groupings of events and signals supported by a particular type of endpoint, such as a TGW. One or more packages can exist for a given endpoint-type.

To enable TGW support, complete the following steps.

Prerequisites

You must be logged into a CLI session to enter this command.

SUMMARY STEPS

1. Enable DQoS and TGCP support for each type of TGW in the mgw-profile table

2. Link each TGW to a MGW profile in the mgw table

3. Add the line termination for a TGW

4. Provision QoS parameters

DETAILED STEPS


Note The token values shown in this section are examples.



Step 1 To enable TGCP protocol support for this type of TGW, enter the following command:

add mgw-profile id=tgwprf222; vendor=cisco; mgw-type=MGX8850; mgcp-version=MGCP-1-0; mgcp-variant=TGCP-1-0; mgcp-default-pkg=TRUNK; codec-neg-supp=[y|n]; pc-mptime-supp=[y|n]; mgcp-hairpin-supp=[y|n]; mgcp-hairpin-z2-supp=[y|n]; rbk-on-conn-supp=[y|n]; mgcp-xdlcx-supp=[y|n]; mgcp-cas-block-supp==[y|n]; mgcp-term-init-level=[0|1|2|3]; mgcp-conn-id-at-gw-supp==[y|n];

where:

id—ID assigned to this mgw-profile by the service provider. This ID is required and can be 1 through 16 ASCII characters. There is no default value.

vendor—Name of the gateway manufacturer. This token is required and can be 1 through 32 ASCII characters. There is no default value; however, "Cisco" is preferred.

mgw-type—Media gateway type, used when the gateway is auto-provisionable from the CLI. VARCHAR(16). Permitted values are:

UBR—residential gateway (RGW)

2420—RGW and CAS trunking gateway

2421—RGW and CAS trunking gateway or SS7 and ISDN gateway.

3660—CAS trunking gateway, SS7 or ISDN gateway.

3810—RGW or CAS trunking gateway, or SS7 and ISDN gateway.

AS5300—CAS, ISDN, SS7 or announcement gateway.

MGX8850—CAS, ISDN, SS7 or announcement gateway.

5850—CAS, ISDN, SS7 or announcement gateway.

mgcp-version—Set to MGCP-1-0 for a TGW.

mgcp-variant—Set to TGCP-1-0 for a TGW.

mgcp-default-pkg—Set to TRUNK for a TGW.

codec-neg-supp—This token instructs the Cisco BTS 10200 Softswitch whether to use codec negotiation for calls on the trunk group configured with this mgw-profile. The possible values of this token are Y (default) and N.

If codec-neg-supp=Y — Codec negotiation is supported. This enables the Cisco BTS 10200 Softswitch to negotiate codec usage between the originating and terminating MGW. The Cisco BTS 10200 Softswitch uses the preferred codec type (the value of the codec-type parameter in the qos table for the trunk group) as the highest priority in the codec list. (Refer to Step 4 in this section for additional information on codec types.)

If codec-neg-supp=N — Codec negotiation is not supported. The Cisco BTS 10200 Softswitch uses only the preferred codec type (the value of the codec-type parameter in the qos table for the trunk group). The Cisco BTS 10200 Softswitch does not attempt to negotiate other codec types with the TGW.

pc-mptime-supp—Specifies whether TGW supports "MP" (multiple packetization) which means individual packetization periods for each codec as defined by PacketCable ECN MGCP-N-02101. This flag is applicable only if MGCP-VARIANT=NCS-1-0 or TGCP-1-0. Verify that this parameter is set to Y, which is the default value, for a TGW. (For a Cisco MGX8850 VISM gateway, the MP function is not available. Therefore, set this token to N for a Cisco MGX8850 VISM gateway.)

mgcp-hairpin-supp—Specifies whether the MGW supports TDM bus hairpinning. The possible values are Y (yes) and N (no). The default value is Y. If the TGW supports TDM hairpinning, this token can be set to Y, and the Cisco BTS 10200 Softswitch will instruct the TGW to perform TDM hairpinning. If the TGW does not support TDM hairpinning, the value of this token must be set to N, and the Cisco BTS 10200 Softswitch will use the RTP hairpinning method.


Note TDM = time-division multiplexing; RTP = real-time transfer protocol.


mgcp-hairpin-z2-supp—The possible values are Y (yes) and N (no). The default value is N. If the mgcp-hairpin-supp token is set to Y, you should also provision the mgcp-hairpin-z2-supp token, which specifies the hairpin connection type. If this token is set to Y, the Cisco BTS 10200 Softswitch sends a single create connection (CRCX) message specifying both endpoints in the hairpin connection. If this token is set to N, two separate CRCX messages are sent to the originating and terminating endpoints on the TGW.


Note The mgcp-hairpin-supp token has precedence over this token. If mgcp-hairpin-supp is set to N, the mgcp-hairpin-z2-supp field is ignored.


rbk-on-conn-supp—Specifies whether the TGW has the ability to send a ringback signal to the calling party on connection setup. The default value of rbk-on-conn-supp is Y.

mgcp-xdlcx-supp—Specifies whether the MGW supports the Request Identifier (X) parameter in the received DLCX messages without the CallId (I) and ConnectionId (I) parameters. Verify that this value is set to N (the default value).

mgcp-cas-block-supp—This token applies to CAS TGWs only. For CAS TGW, set to N (default value) to be PacketCable compliant. PacketCable signaling does not send a blocking signal.

mgcp-term-init-level—This token applies to certain TGWs, such as the Cisco MGX-8850. Set this to a numerical value 0, 1, 2, or 3 as follows:

0 (Level 0—default value): All terminations are initialized individually (TGW: S0/DS1-1/1)

1 (Level 1): Level 1 group of terminations (Span/T1/port) are initialized in bulk (TGW: S0/DS1-1/*)

2 (Level 2): Level 2 group of terminations (Slot/board) are initialized in bulk (TGW: S0/*)

3 (Level 3): Level 3 group of terminations (Gateway) are initialized in bulk (TGW: *)

mgcp-conn-id-at-gw-supp—Determines how the Cisco BTS 10200 Softswitch interprets and handles audit endpoint (AUEP) ACK messages. If set to Y (default), the system deletes only the connections on the endpoint identified in the AUEP ACK messages. If set to N, the system deletes all connections on the endpoint upon receipt of an AUEP ACK message. For a TGW, use the default value (Y) for this token.


Note The mgw-profile table has many other tokens that support other characteristics and other types of media gateways. For more detailed information, see the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.


Step 2 To enable TGCP support for a specific TGW, enter the following command:

add mgw id=tgw50; tsap-addr=<DNS or IP address for the TGW>; call-agent-id=CA146; mgw-profile-id=tgwprf222; type=tgw;

where:

id—MGW identifier, assigned by the service provider. This required token can be from 1 through 32 ASCII characters. There is no default value.

tsap-addr—Specifies the DNS/IP address for the TGW. You can also enter the IP address and port number. The entry can be 1 through 64 ASCII characters. There is no default value.

id—Domain name of the specific Call Agent (CA), in the format CAnnn, where nnn = 3-digit number previously assigned to the CA. This value is case-sensitive (CA146 and ca146 are not the same). This is the unique identifier for this Call Agent (CMS) node, which was permanently assigned at time of software installation on the Cisco BTS 10200 Softswitch.

mgw-profile-id—ID of the mgw-profile the subscriber is assigned to in the MGW Profile table. This required token can be from 1 through 16 ASCII characters. There is no default value.

type—The value of this token is three ASCII characters (RGW or TGW). This optional token must be set to TGW.


Note The mgw table has many other tokens that support many other characteristics of media gateways. For more information, see the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.


Step 3 Provision TGW terminations by entering the following command (example shown):


Note A termination can only be added in the unequipped state. After adding the termination, use the control command to control the termination to the in-service (INS) state.


add termination prefix=S0/ds1-2/; mgw-id=tgw50; port-start=1; port-end=24; type=TRUNK;

where:

id—Composite value that identifies the termination. The termination's id is generated from the prefix, port-start and port-end token parameters, as follows:

prefix—This user-assigned token is required and can be from 1 to 32 ASCII characters.

port-start—This required token can be from 1 to 4 numeric characters. The default is 1.

port-end—This required token can be from 1 to 4 numeric characters. The default is 24.

type—Termination type. The value of this token should always be TRUNK for TGWs.

mgw-id—The id previously assigned to this TGW in the mgw table. (See Step 2 above.)


Note The termination table has other tokens that support other termination characteristics. For more information, see the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.


Step 4 To provision QoS parameters, enter the following command (example shown):

add qos id=gold-service; lptime=20; hptime=20; codec-type=PCMU;

where:

id—User-defined qos profile name. This mandatory token can be 1 to 16 ASCII characters. There is no default value.

lptime—Lower packetization time in milliseconds. This is a numeric value from 5 to 50 (default 10).

hptime—Higher packetization time in milliseconds. This is a numeric value from 5 to 50 (default 10).

codec-type—Preferred codec type, such as PCMU, PCMA, G.728, and so forth, to be used on calls from the trunk group configured with this QoS. When communicating with a TGW, the Cisco BTS 10200 Softswitch checks the provisioning of this token to look up the preferred codec type for the trunk group. This is the highest priority codec in the list sent by the Cisco BTS 10200 Softswitch to the TGW in the CRCX message.


Note The rest of the codec list is based on the data in the AUEP ACK message.



Note The qos table has several other tokens. For more information, see the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.



COPS Interface Measurements for DQoS Feature

The following additional DQoS peg counts are provided in Release 4.1 to support the COPS interface.


Tip The Cisco BTS 10200 Softswitch tracks and reports measurements separately for each of the CMTS units (aggregation routers) it supports.


DQOS_GATESET_ATTMP—The number of DQOS gate set attempts of all types on the reporting CMTS.

DQOS_GATESET_SUCC—The number of successful DQOS gate set attempts of all types on the reporting CMTS.

DQOS_GATE_COMMIT—The number of successfully committed DQOS gates of all types on the reporting CMTS.

To create a report file of the DQoS counters for all time intervals in the period starting and ending at specific times, enter the following command. The system will prepend the file with the string "Tm_" and write the file to the /opt/ems/report directory on the active EMS.

report measurement-dqos-summary; start-time=[start-time]; end-time=[end-time]; aggr-id=[ID of the aggregation router (CMTS) for which data should be reported]; output=[desired file name for the report]; output-type=[CSV | XML]

where:

start-time and end-time have a format of yyyy-mm-dd hh:mm:ss

CSV = comma-separated value


Note Time intervals can be every 5, 15 minutes, 30 minutes, or 60 minutes. This is provisionable in another command, change measurement-prov, as described later in this section.


Use any of the following commands to display DQoS counters on your monitor.


To display DQoS counters for all time intervals in the past 48 hours for all CMTS IDs, enter the following command.

report measurement-dqos-summary; interval=ALL;


To display DQoS counters tracked at every interval in the period starting at a specific start-time and for all aggregation IDs, enter the following command.

report measurement-dqos-summary; start-time=[start-time];

(start-time has a format of yyyy-mm-dd hh:mm:ss, and the end-time defaults to the most recent interval)


To display DQoS counters for the most recent time interval for all aggregation IDs, enter the following command.

report measurement-dqos-summary;

(start-time and end-time both default to the most recent interval)

Example:

CLI>report measurement-dqos-summary

Reply : Request was successful.

TIMESTAMP       20020310184428

DQOS_GATESET_ATTMP       10

DQOS_GATESET_SUCC           9

DQOS_GATE_COMMIT            9

Example using display token to specify desired counters (separated by commas):

CLI>report measurement-dqos-summary; display=DQOS_GATESET_ATTMP,DQOS_GATE_COMMIT;

Reply : Request was successful.

TIMESTAMP 20020310184428

DQOS_GATESET_ATTMP 10

DQOS_GATE_COMMIT            9

To manage the collection of DQoS measurements, use the following commands.

To display the current provisioning settings of DQoS measurements (enabled or disabled status), enter the following command.

show measurement-prov type=DQOS;

To change the current provisioning settings of DQoS measurements (enabled or disabled status) and/or the time interval (5, 15 [default], 30 or 60 minutes), enter the following command.

change measurement-prov type=dqos; enable=yes; time-interval=30;


Note Additional details about measurement provisioning commands can be found in the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.


Events and Alarms Specific to PacketCable-Based Nodes

The following events and alarms can be generated in response to processing problems or network connection issues with PacketCable-based nodes.


Note This list provides only the events and alarms that are specifically for PacketCable-based nodes, and includes only the name and description of each alarm. Detailed descriptions of all events and alarms (for all network protocols and NEs connected to the Cisco BTS 10200 Softswitch), and recommended corrective actions, are presented in the Cisco BTS 10200 Softswitch Operations, Maintenance, and Troubleshooting Guide.



Note Events and alarms related to PacketCable-based event message (EM) and security functions are presented in separate sections in this document ("Events and Alarms for the EM Feature" and "Events and Alarms for the Security Interface Feature").


CALL PROCESSING Event #15
CMTS ER ID Not found in MGW table (INFO)

SIGNALING Alarm #103
AGGR Connection Down (MAJOR)

SIGNALING Event #104
AGGR Unable To Establish Connection (INFO)

SIGNALING Event #105
AGGR Gate Set Failed (INFO)

SIGNALING Alarm #106
ESA BTS DF Connection Down (MINOR)

How to Provision the Event Messaging Feature

This section describes how to provision EM parameters on the Cisco BTS 10200 Softswitch.

Billing Data Options

The Cisco BTS 10200 Softswitch has the ability to provision billing support using either of the following billing data generation methods:

Call Detail Blocks (CDBs)—This is traditional post-call billing data, which is assembled into Call Detail Records (CDRs) by an external billing mediation system or billing server.

PacketCable event messages (EMs)—This is real-time call data flow, which is transferred to an external Record Keeping Server (RKS) that assembles CDRs from the EMs.

The Cisco BTS 10200 should be provisioned to generate either EMs or CDBs, but not both.


Caution Provision the Cisco BTS 10200 to generate either EMs or CDBs, but not both. Attempting to generate both types of records simultaneously can significantly degrade the call processing rate. Refer to the "Provisioning the System to Generate EMs for Billing" section for provisioning details.


Note The contents of CDBs is outside the scope of this document. Refer to the Cisco BTS 10200 Softswitch Billing Interface Guide for information about CDBs.


Description of Event Message Feature

EMs are real time data records containing information about network usage and activities. They must not be confused with system event messages that report events and sometimes trigger alarms. EMs are used in PacketCable networks to collect resource usage data for billing purposes. In the PacketCable architecture EM generation is based on the half-call model. A single EM can contain a complete set of usage data or it might contain only part of the usage information.

The Record Keeping Server (RKS) is a PacketCable network element that receives EMs from network elements, such as the Call Management Server (CMS), Media Gateway Controller (MGC), and the Cable Modem Termination System (CMTS). The physical Cisco BTS 10200 Softswitch contains both CMS and MGC logical network elements. The EMs generated by both the CMS and MGC are sent to the RKS. The RKS correlates the information in multiple EMs and provides the complete record of service for a call, which is referred to as a Call Detail Record (CDR).


Note For information about EM-related operations on the Cisco BTS 10200 Softswitch, refer to "Appendix B: Event Message Generation Details and Content" at the end of this document.


Figure 5 illustrates the PacketCable network elements that are involved in the EM process.

Figure 5 Event Message Interfaces

The EM related interfaces illustrated here are described as follows:

1. MGC to RKS—EMs generated by MGC (Cisco BTS 10200 Softswitch) are sent to RKS

2. CMS to RKS—EMs generated by CMS (Cisco BTS 10200 Softswitch) are sent to RKS

3. CMTS to RKS—EMs generated by CMTS are sent to RKS. The Cisco BTS 10200 Softswitch (MGC/CMS) is not involved

4. CMS to CMTS—CMS (Cisco BTS 10200 Softswitch) sends the Billing Correlation ID (BCID) to the CMTS using the DQoS GateSet message

5. CMS to MGC—An internal exchange of originating/terminating information such as BCID and FEID.

PacketCable EMs can support billing and settlement activities for single-zone architectures. The originating and terminating CMSs exchange unique Billing Correlation IDs (BCIDs) and Financial Entity IDs (FEIDs) for each half of the call. The originating CMS sends a BCID and an FEID in the INVITE message. The Cisco BTS 10200 Softswitch allocates the BCID for calls it originates or terminates. Along with the FEID, the BCID is used across network elements to reference calls. The FEID is provisioned on a system-wide basis (a single setting for the Cisco BTS 10200 Softswitch) as defined in the "Provisioning the System to Generate EMs for Billing" section. It is configured by the operator and made available for the Cisco BTS 10200 Softswitch Basic Call Module (BCM) to use in billing EMs for billing record reporting on a per-call basis.

Timestamp Support for Event Messages

The system-generated timestamps for EMs are based on the host operating system (OS) time and time zone. This data is not affected by CLI provisioning. The Solaris OS obtains the time automatically through network time protocol (NTP) services.


Caution Users should never attempt to modify the system date or time in their Cisco BTS 10200 Softswitch host machines while system components (CA, FS, EMS, and BDMS) are running. This could cause the system to have serious problems. Allow the Solaris OS to obtain the time automatically through NTP services.

Event Message Transport

The RADIUS transport protocol is used between the Cisco BTS 10200 Softswitch (CMS/MGC) and the RKS. EMs are sent to an RKS without waiting for acknowledgement of the previous message. The maximum number of pending ACK messages is 256.

EMs are first sent to the primary RKS and, after the specified number of retry attempts fail, they are sent to the secondary RKS. If one RKS is found to be unreachable, then the other RKS is considered for subsequent messages. If both the primary and secondary RKS become unreachable, the EMs are stored in an error file on the hard disk (as described in the "Event Message Storage on CA" section) and a timer is started. When the timer expires, newly-arriving EMs will be sent to the primary RKS.


Note If EMs are being sent to the primary RKS, and the primary RKS goes down, the Cisco BTS 10200 Softswitch sends subsequent EMs to the secondary RKS. When the primary RKS comes back up, the Cisco BTS 10200 Softswitch will continue to send EMs to the secondary RKS. (It will not automatically begin sending them to the primary RKS.)



Note Provisioning of timers and retry attempts is described in the "Provisioning Support for EM Transmission and Storage" section.



Note Alarms and events applicable to the EM feature are listed in the "Events and Alarms for the EM Feature" section.


Event Message Storage on CA

EMs are stored in the network element (CA) that generates them until successful transfer to the RKS. Once receipt of the EMs is acknowledged by the RKS, they are deleted. The number of EMs generated by the Cisco BTS 10200 Softswitch depends on the number of calls processed. Multiple EMs are generated for each call. Depending on call-agent-profile provisioning, and the type of call, EMs can be generated by the CMS or MGC (or both) within the CA. The exact storage requirement varies depending on the rate of EM generation and how long the Cisco BTS 10200 Softswitch is required to keep the records before transferring them to an RKS.

The Cisco BTS 10200 Softswitch generates and stores EMs with the following characteristics:

EMs are generated in real time during a call. EMs contain timestamps with a granularity of 1 millisecond. The time interval between generation and transmission is not specified.

The Cisco BTS 10200 Softswitch synchronizes with the network clock using NTP at least once per hour. The deviation of the clock in the Cisco BTS 10200 Softswitch remains within ± 100 milliseconds between NTP synchronizations.

EMs that cannot be successfully transferred to the RKS due to loss of communication are stored in the /opt/BTSem directory on the CA. The system uses the file naming conventions specified in the PacketCable Event Messages Specification (PKT-SP-EM-I07-030815) for the stored EMs. The maximum EM file size, and the time limit on keeping a file open, are provisionable as described in the "Provisioning Support for EM Transmission and Storage" section. These files are not automatically deleted nor transferred out of the CA—the operator must transfer these files to the RKS when communication is restored. The procedure for doing this is provided in the "Manual Recovery and Transfer of Stored EMs" section.


Caution Event messages that cannot be successfully transferred to the RKS due to loss of communication are not automatically deleted nor transferred out of the CA. You must transfer these files to the RKS when communication is restored.

The procedure for doing this is provided in the
"Manual Recovery and Transfer of Stored EMs" section .

Each time an EM file is placed in local storage, the system checks current disk usage and takes the following actions:

The system generates an alarm if the disk space allocated to EMs fills up to a certain level—
50% (Minor alarm), 70% (Major alarm), or 100% Critical alarm.

When the critical condition is reached, and after raising the critical alarm, further EMs are dropped without any additional warning.

When the critical condition is reached, the disk usage is monitored periodically (one time every minute) to check if disk space usage has decreased and EMs can be stored again.

Event Message Provisioning

This section explains how to provision EM functionality on the Cisco BTS 10200 Softswitch.

Provisioning Support for EM Transmission and Storage

The commands in the following procedure specify the required IDs for the primary and secondary RKSs, and link them with the Call Agent (CMS/MGC). They also control parameters related to the transmission of EMs to the RKS, and parameters related to storage of EMs on the CA.

Remote Access Dial-In User Service (RADIUS) is a client/server protocol used for Authorization, Authentication, and Accounting (AAA). The RADIUS protocol is an industry standard for remote access AAA defined in a set of Internet Engineering Task Force (IETF) standards; RFC 2865 and RFC 2866. The RADIUS Profile (radius-profile) table is required in PacketCable networks when using an EM-based billing system and a RADIUS-based Record Keeping Server (RKS). Primary and secondary RKS node IDs, IP address and port address, RADIUS retry intervals and retry counts, and other parameters must be created in the radius-profile table.

The Call Agent Profile (call-agent-profile) table establishes a link between the Call Agent (CMS) and the primary and secondary RKSs.


Step 1 At the CLI prompt enter the following add command:

add radius-profile id=[primary RKS id | secondary RKS id]; tsap-addr=[ip-address | ip-address:port-number]; encryption-key=[16- bit encryption key]; description=[user defined]; acc-rsp-timer=[1 ... 10]; acc-req-retransmit=[1 ... 5];

where,

The following tokens are mandatory:

id—A string that identifies the primary or secondary RKS. This required token can be from 1 to 16 ASCII characters. There is no default value.

tsap-addr—Unique IP address or IP address and port number of the primary or secondary RKS. This required token can be from 1 to 64 ASCII characters (max). There is no default value. This value must be an IP address (not a domain name).


Note The value of TSAP-ADDR can be updated dynamically using the following command. No system restart is required.

change radius-profile id=[primary RKS id | secondary RKS id]; tsap-addr=[IP address:port-number];


The following optional tokens can also be provisioned:


Tip The default values of these parameters are sufficient for some networks. Before making any changes, you can use the show command to determine if changes are needed to any of the default values.


encryption-key—Specifies an optional 16-byte encryption key. Any hexadecimal characters (0-9, A-F) can be used, The default value is all zeros (0000000000000000).

description—Service provider's description of this RADIUS profile. This optional token can be from 1 to 64 ASCII characters.


Note The following tokens, acc-rsp-timer and acc-req-retransmit, control the retransmission of EMs from the CA to the RKSs when the first attempt does not go through. acc-rsp-timer controls how long the system waits before retransmitting, and acc-req-retransmit controls how many retransmission attempts are made to the target RKS.


acc-rsp-timer—Specifies the accounting response timer value in seconds. This is the time the Cisco BTS 10200 Softswitch waits for the target RKS to acknowledge receipt of a transmitted EM. When this timer expires, the Cisco BTS 10200 Softswitch retransmits the EM. This optional token is an integer in the range of 1 through 10. The default value is 2 seconds.

acc-req-retransmit—Specifies the number of accounting request retransmissions. This is the number of times the Cisco BTS 10200 Softswitch will attempt to retransmit an EM to the target RKS. When this limit is reached, the Cisco BTS 10200 Softswitch treats the target RKS as nonresponsive, and begins transmitting to the other RKS. (In the unlikely event that the Cisco BTS 10200 Softswitch tries, but fails, to receive acknowledgement from both RKSs, it begins storing EM files on the currently active CA.) This optional token is an integer in the range of 0 through 5. The default value is 3.

Examples

add radius-profile id=prirks; tsap-addr=100.100.100.100; encryption-key=abcdef1234567890; acc-rsp-timer=7;  acc-req-retransmit=4; description=primary_billing_server

add radius-profile id=secrks; tsap-addr=100.100.100.101; encryption-key=abcdef1234567890; acc-rsp-timer=6;  acc-req-retransmit=2;  description=secondary_billing_server

Step 2 To specify how the system stores EMs in files on the CA (when loss of communication with the RKSs prevents EMs from being transmitted to the RKSs), enter the following commands (examples shown):

change ca-config type=retry-pri-rks-timer; datatype=integer; value=14;

change ca-config type=em-file-open-time; datatype=integer; value=900;

change ca-config type=em-file-size; datatype=integer; value=50;

where,

datatype—Defines the characteristic of the value that follows.

type—retry-pri-rks-timer specifies the length of time, in minutes, the Cisco BTS 10200 Softswitch waits after losing all communication with both RKSs before attempting to establish communication with the RKS again. During this time, the Cisco BTS 10200 Softswitch writes all newly generated EMs to a file on the CA that created the EMs. The range of values (value token) is 0 to 30, and the default is 10.

type—em-file-open-time specifies the maximum time that an EM file can be open, in seconds. While the file is open, additional EMs can be written to the file. When this time limit is reached, this file is closed and a new file is opened (if communication with the RKS has not yet been reestablished). The range of values (value token) is 1 to 1800, and the default is 600.

type—em-file-size specifies the maximum size of an EM file, in MB. If the current file size is under this limit, additional EMs can be written to the file. When this limit is reached, this file is closed and a new file is opened (if communication with the RKS has not yet been reestablished). The range of values (value token) is 1 to 100, and the default is 20.


Note An open EM file does not close automatically when communication to the RKS is restored. The file closes automatically according to the provisioned values in em-file-open-time and em-file-size, whichever occurs first.



Note The radius-profile and ca-config tables also have many other tokens that support many other characteristics of the Call Agent (CMS). For more information, see the Cisco BTS 10200 Softswitch Command Line Interface Guide.



Step 3 To provision batch mode handling of event messages (EMs), enter the following commands:

change ca-config type=batch-mode-supp; value=Y;

change ca-config type=batch-latency; value=240;

where:

batch-mode-supp—Indicates whether batch mode is supported. The value of this optional token is a single ASCII character (Y or N); the default value is N (no), which means batch mode is not supported. The token must be set to Y (yes) to provide support for batch mode.

batch-latency—When batch-mode-supp=Y, batch-latency defines the maximum time (in seconds) to hold any EM before sending the batched RADIUS message. The value of this optional token is a number from 1 through 999. The default value is 60.

Step 4 To set the differential service code point (DSCP) for signaling packets on RADIUS interfaces between the CMS and RKS, enter the following command:

change ca-config type=RADIUS-DSCP-TOS; value=240;

where:

type—RADIUS-DSCP-TOS specifies the Differentiated Services Code Point (DSCP) value or type of service (TOS) value. Used for the signaling packets on RADIUS interfaces between CMS and RKS, and CMS and DF server. For DSCP, only bits 0-5 are used; for TOS, bits 0-2 are used for IP Precedence, and bits 3-6 for IPv4 IP TOS.

value—A number from 0 through 255; the default value is 96. These DSCP and TOS values are described more fully in Table 1 and Table 2 in the "Data Values for DSCP and TOS Parameters" section.


Note The radius-profile and ca-config tables also have additional tokens that support many other characteristics of the Call Agent (CMS). For more information, see the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.



Provisioning the System to Generate EMs for Billing

The Cisco BTS 10200 Softswitch has the ability to provision billing support using either Call Detail Blocks (CDBs), which are assembled into Call Detail Records (CDRs) by an external billing server, or PacketCable EMs, which are transferred to an external RKS that assembles CDRs from the EMs.

The Cisco BTS 10200 Softswitch contains two PacketCable-based logical network elements, the CMS and MGC. Per PacketCable specification, the CMS and MGC must each have a separate, unique element ID. The applicable element ID is included in each EM sent from the CMS and MGC.

To provision the Cisco BTS 10200 Softswitch to generate EMs for billing, complete the following steps:


Note The value for id shown in this section (CA146) is an example.



Step 1 Use the following command to display the current values for the call-agent-profile table:

show call-agent-profile id=CA146;

where:

id—Domain name of the specific Call Agent (CA), in the format CAnnn, where nnn = 3-digit number previously assigned to the CA. This value is case-sensitive (for example, CA146 and ca146 are not the same). This is the unique identifier for this Call Agent (CMS) node, which was permanently assigned at time of software installation on the Cisco BTS 10200 Softswitch.

Step 2 If the system response indicates that this table does not exist, then you must create it using the following command. Otherwise, the EM function is not supported and EMs will not be generated.

add call-agent-profile id=CA146; cdb-billing-supp=N; em-billing-supp=Y; pri-rks-profile-id=prirks; sec-rks-profile-id=secrks;


Caution If the call-agent-configuration table is not created, the Cisco BTS 10200 Softswitch will generate CDBs but not EMs.

Step 3 If the call-agent-profile table already exists, check (in the display from Step 1) to see if cdb-billing-supp is set to N (no) and em-billing-supp is set to Y (yes). If not already shown in the display, enable EM billing support by entering the following command:

change call-agent-profile id=CA146; cdb-billing-supp=N; em-billing-supp=Y; pri-rks-profile-id=prirks; sec-rks-profile-id=secrks;

where:

cdb-billing-supp—Specifies whether to generate Call Detail Blocks (CDBs). The value of this optional token is a single ASCII character (Y or N); the default value is Y (yes). The value of this token must be set to N (no) if the Cisco BTS 10200 Softswitch is to provide EM billing in a PacketCable network.

em-billing-supp—Specifies whether to generate PacketCable EMs. The value of this optional token is a single ASCII character (Y or N); the default value is N (no). The value of this token must be set to Y (yes) if the Cisco BTS 10200 Softswitch is to provide event message billing in a PacketCable network.

pri-rks-profile-id—The primary RKS profile ID. This value must be the same as the radius-profile ID for the primary RKS. This required token can be from 1 to 16 ASCII characters. There is no default value.

sec-rks-profile-id—The secondary RKS profile ID. This value must be the same as the radius-profile ID for the secondary RKS. This required token can be from 1 to 16 ASCII characters. There is no default value.


Caution If you want your system to generate EMs, be sure to configure the system as shown in this section, above, with cdb-billing-supp=n; em-billing-supp=y. This allows the system to generate EMs and not CDBs.

Do not set both of these tokens to y. Attempting to generate both types of records simultaneously can significantly degrade the call processing rate.

Step 4 Enter the following command to generate EMs based on CMS and MGC logical network elements, and to specify the financial entity ID.


Note The Cisco BTS 10200 Softswitch contains both the CMS and MGC logical entities. For PacketCable systems, the cms-supp token must be set to y, and the cms-id must be entered. If your Cisco BTS 10200 Softswitch communicates with a TGW, you must also set the mgc-supp token to y and enter the mgc-id. The cms-id and mgc-id cannot be given the same value. The feid value is also required for EM billing.


change call-agent-profile id=CA146; cms-supp=y; cms-id=12345; mgc-supp=y; mgc-id=67890; feid=feid0001;


Note In the above command, use different (unique) IDs for cms-id and mgc-id.


where:

cms-supp—Specifies if EMs are generated based on CMS functionality. The value of this optional token is a single ASCII character (Y or N); the default value is N (no). Set this value to Y (yes) to generate EMs based on CMS functionality.

cms-id—Specifies the 5-digit element ID of the CMS. The range of values is 0 through 99999. This token is mandatory if the value of the cms-supp token is set to Y.

mgc-supp—Specifies if EMs are generated based on MGC functionality. The value of this optional token is a single ASCII character (Y or N); the default value is N (no). Set this value to Y (yes) to generate EMs based on MGC functionality.

mgc-id—Specifies the 5-digit element ID of the MGC. The range of values is 0 through 99999. This token is mandatory if the value of the mgc-supp token is set to Y.

feid—Financial entity ID (FEID) of the Cisco BTS 10200 Softswitch (CMS/MGC) that is included in event messages sent to the RKS for billing purposes. The value must be a string from 1 to 255 ASCII characters in length. PacketCable zones can be divided into one or more logical financial entity IDs. A single CMS/MGC is assigned at most one FEID; however, more than one CMS can be assigned the same FEID. This optional token becomes a mandatory token if the cms-supp token, the mgc-supp token, (or both) are set to Y (yes).


Manual Recovery and Transfer of Stored EMs

This section describes how to manually transfer stored EM files from the CA to the RKS. This procedure must be used if communication to both RKS units goes down. Perform these procedures after communication is restored.

Recover the Billing Files

Billing data is normally transferred to the Record Keeping Server (RKS) on a real-time basis. In the unlikely event that communications with the RKS go down, alarms are raised and billing data files are written to a local drive on the Cisco BTS 10200 Softswitch (see the /opt/BTSem directory on the Call Agent (CA) that generated the Event Messages. If communications are not promptly restored, additional billing alarms of increasing severity are raised at time intervals of 1 hour (minor), 3 hours (major), and 5 hours (critical).

Event messages that are not successfully transferred to the RKS are stored on the Call Agent. The system uses the naming conventions in the PacketCable Event Messages Specification (PKT-SP-EM-I07-030815), with file names in the format PKT-EM-yyyymmddhhmmss-pri-nodeid-seq.bin, where

PKT-EM—is fixed and does not change across files

yyyymmddhhmmss—is a timestamp, where

yyyy-is the year, such as 2003

mm-is the month, from 01 through 12

hh—is the hour, from 00 through 23

mm-is the minute, from 00 through 59

ss-is the second, from 00 through 59

priority—which is always set to 1, but can change according to the PacketCable specification

CMS ID or MGC ID—depending on whether the file contains event messages generated by the CMS or the MGC function of the Call Agent

file sequence number—the CMS and MGC files are numbered independently

.bin—binary file type designation

An example of a typical event message file name would look similar to

PKT-EM-20030915103142-1-00001234-000002.bin

All billing data generated during the period of the communication outage are stored in the /opt/BTSem directory. If communication with the RKS is lost for an extended period, the available disk space on the local Softswitch drives can begin to fill up with Event Message (EM) files. The system monitors the amount of space available on the disks and raises alarms of increasing severity when the disks are 50 percent (minor), 70 percent (major) and 100 percent (critical) full.


Note There could be billing data files on both CAs, primary and secondary, depending on whether there have been any switchovers during the loss of communication with the RKS.


Cisco recommends that you monitor the available disk space on a regular basis to prevent the possible loss of billing data. If the disks should become full, the data on the disk is preserved and new EMs are discarded.


Caution Do not allow the disk to become full. If you do not transfer the billing data files to the RKS, billing data might be lost. If Event Messages are discarded, they cannot be recovered and revenue will be lost.

FTP Billing Files to the RKS

To send billing files from the Call Agent (CA) to the RKS, perform the following steps:


Step 1 On the CA, navigate to the subdirectory to which the billing data is written.

cd /opt/BTSem


Step 2 At the prompt, establish an FTP session with the RKS.

ftp <record keeping server name>


Step 3 When prompted, enter your user name and password for the RKS. The FTP prompt should appear.

Step 4 At the FTP prompt, enter bin to enable binary transfer:

bin


Step 5 On the RKS, navigate to the subdirectory to which the billing files will be written.

cd /.../.../Billing_Data


Step 6 Place the applicable billing files in the billing data subdirectory.

put <billing-filename>


Step 7 After the transfer is complete and the FTP prompt reappears, exit the FTP session.

bye



Compare Checksums

To compare the checksums to ensure that the data was transferred correctly, perform the following steps:


Step 1 Login to the RKS, using your user name and password for that system.

Step 2 Navigate to the subdirectory to which the billing data files were written.

cd /.../.../Billing_Data


Step 3 List the files in the billing directory. The following command will list the files in reverse order by creation date.

ls -lrt


Step 4 Run a cksum on the files that were backed up.

cksum <billing-filename>


Step 5 Compare these cksum values to the corresponding cksum values on the CA.

a. If the cksum values are the same, the file transfer has completed without error.

b. If the cksum values are not the same, repeat Step 1 through Step 5.

If the cksum values are still different, contact Cisco TAC for assistance.


Provisioning Media_Alive Verification for Event Messages

Use the ACTIVITY table to schedule and configure Media_Alive EMs. These EMs are used during longer-duration calls to verify that the media connection is still alive.


Step 1 Log on to a CLI session on the Cisco BTS 10200 Softswitch.

Step 2 Configure Media_Alive generation according to local requirements (example shown here):

add activity id=MEDIA-ALIVE-EM; freq=6H; start-time=HH:MM;

where:

id—The value must be MEDIA-ALIVE-EM, which is a fixed system value listed in the ACTIVITY-BASE table.


Note You can view other tokens in the ACTIVITY-BASE table by using the command:
show activity-base id=media-alive-em;
However, you cannot change any values in that table.


freq—Frequency: Number of times to schedule the specified EM Media_Alive activity.

start-time—Time of day in the format of HH:MM ranging from 00:00 to 23:59 (default is 00:00).


Note The ACTIVITY table has many other tokens that support other EM Media_Alive options. For more detailed information about these options, see the Cisco BTS 10200 Softswitch Command Line Interface Reference Guide.


Step 3 To view the MEDIA-ALIVE-EM activity enter the following command:

show activity id=media-alive-em;

Example Command Line Output:

ID -> media-alive-em

FREQ -> 30 minutes

DAY OF MONTH -> NONE

DAY OF WEEK -> NONE

DATE -> NONE

START-TIME -> 00:00

FIXED-TIME-INTERVAL -> No

END-TIME -> NONE

ENABLED -> Yes

SWITCHOVER ENABLED -> Yes

RESTART ENABLED -> Yes

LAST CHANGED -> 2002-SEP-13 07:05:00


Event Message Generation Details and Content

See "Appendix B: Event Message Generation Details and Content" for information on EM data.

Measurements for the EM Feature

The following operational measurement counts and/or statistics are supplied as peg counts for the EM feature:

BILLING_EM_ACKED—The number of EMs acknowledged by the RKS.

BILLING_EM_LOGGED—The number of EMs written to disk but not sent to any RKS.

BILLING_EM_RETRANS—The number of EMs that were transmitted to an alternate RKS due to the lack of a response from a previously-tried RKS, excluding retries. The counter is incremented when an EM is first sent to an alternate RKS. Any retries that occur at the RADIUS stack level (as provisioned in the "radius-profile" table) are not included in this count.

Use the following CLI command to retrieve these measurements:

report measurement-em-summary

A typical system response is as follows:

CLI>report measurement-em-summary

TIMESTAMP

CALL_AGENT_ID

CONDITION

BILLING_EM_ACKED

BILLING_EM_LOGGED

BILLING_EM_RETRANS

2003-07-10 16:15:00

CA146

Normal

2

3

3

Reply : Success: Entry 192 of 192 returned.

CLI>


Events and Alarms for the EM Feature

The following alarms and events can be generated by the EM feature.


Note This list provides only the events and alarms that are specifically for the EM feature, and includes only the name and description of each alarm. Detailed descriptions of all events and alarms (for all network protocols and NEs connected to the Cisco BTS 10200 Softswitch), and recommended corrective actions, are presented in the Cisco BTS 10200 Softswitch Operations, Maintenance, and Troubleshooting Guide.



Note Events and alarms related to PacketCable-based NEs and security functions are presented in separate sections in this document ("Events and Alarms Specific to PacketCable-Based Nodes" and "Events and Alarms for the Security Interface Feature").


BILLING Alarm #38
EM log file access error (MAJOR)

BILLING Alarm #39
RADIUS accounting receive failure (MINOR)

BILLING Alarm #40
EM encode failure (MINOR)

BILLING Alarm #41
Message content error (MINOR)

BILLING Event #42
Error reading provisioned data-using default (WARNING)

BILLING Event #44
RKS switch occurred (INFO)

BILLING Event #45
Event Message log file opened (INFO)

BILLING Event #46
Event Message log file closed (INFO)

BILLING Alarm #47
RKS unreachable for 1hr (MINOR)

BILLING Alarm #48
RKS unreachable for 3 hours (MAJOR)

BILLING Alarm #49
RKS unreachable for 5 hours (CRITICAL)

BILLING Alarm #53
Event Message disk space 50 percent full (MINOR)

BILLING Alarm #54
Event Message disk space 70 percent full (MAJOR)

BILLING Alarm #55
Event Message disk space 100 percent full (CRITICAL)

How to Provision the Security Interface Feature

This section describes the PacketCable-based security interface feature and how to provision security options. The subsections are as follows:

Security of PacketCable-Based Networks

Configuring System Security Parameter at Software Installation Time

Provisioning Security Interfaces to the MTA

Provisioning Security Interfaces to the CMTS

Provisioning Security Interfaces to the TGW

Provisioning Security Interfaces to the RKS

Provisioning IPsec Security Associations

Provisioning Ciphersuite Encryption and Authentication Algorithms

Events and Alarms for the Security Interface Feature

Security of PacketCable-Based Networks

Release 4.1 enables the Cisco BTS 10200 Softswitch to perform the security functions of a call management server (CMS) and media gateway controller (MGC) in the PacketCable environment. The Cisco BTS 10200 Softswitch implements the signaling security features of the PacketCable Security Specification, PKT-SP-SEC-I07-021127, November 27, 2002, and supports the media security features of PKT-SP-SEC-I07-021127 for the connected CMTSs and MTAs.

This implementation of PKT-SP-SEC-I07-021127 provides a security scheme for the voice-over-cable network based on a set of security protocols. These protocols, based on the documents listed below, provide authentication (to help prevent theft of bandwidth, denial-of-service attack, replay, and so forth) and enable message integrity, privacy, and confidentiality.

IETF documents covering IP security (IPsec) architecture:

RFC 2401, Security Architecture for the Internet Protocol, IETF (S. Kent, R. Atkinson), Internet Proposed Standard, November 1998.

RFC 2406, IP Encapsulating Security Payload (ESP), IETF (D. Piper), Internet Proposed Standard, November 1998.

IETF documents covering key management protocols IKE and Kerberos with extensions:

RFC 2409, The Internet Key Exchange (IKE), IETF (D. Harkins, D. Carrel), Internet Proposed Standard, November 1998.

RFC1510, The Kerberos Network Authentication Service (V5), IETF (J. Kohl, C. Neuman), September 1993, with updates presented in PKT-SP-SEC-I07-021127.

Configuring System Security Parameter at Software Installation Time

A special parameter, IPSEC_ENABLED, must be set in the opticall configuration file (opticall.cfg) prior to software installation. This parameter will enable or disable the IPsec feature on the Cisco BTS 10200 Softswitch. If IPSEC_ENABLED is set to "Yes" in the opticall.cfg, the installation script will enable the key management services (KMS) process. If IPSEC_ENABLED is set to "No", the installation script will disable the KMS process. The default value is "Yes".

The value of IPSEC_ENABLED in the opticall configuration file will also determine the availability of the CLI tables and tokens to configure the IPsec feature on the EMS.

The IPSEC_ENABLED value cannot be changed using CLI commands. It can only be changed by reinstalling the entire Cisco BTS 10200 Softswitch application on both the CA and the EMS, and rebooting the CA.


Tip The value of this parameter, and all other opticall.cfg parameters for your installation, is listed in the Network Information Data Sheet that was provided to you at time of system delivery.



Caution All existing provisioned data is lost during reinstallation of the application. Do not reinstall software on a system carrying live traffic. Contact your network administrator or Cisco account team if you have any questions.

Provisioning Security Interfaces to the MTA

The MTA is the only device class that uses Kerberos key management. There are three provisioning steps for the MTA IP security (IPsec) interface:

Kerberos provisioning

IPsec policy provisioning

Enable IPsec


Note The token values shown in this section are examples.



Step 1 Login to a CLI session on the Cisco BTS 10200 Softswitch.

Step 2 To provision Kerberos parameters, enter the following command:

add ipsec-kerberos krb-fqdn=cms-ca1.ciscolab.com; krb-realm=cisco-realm.com; krb-srv-key=546869732069732061206b6579206f66203234206368612e; srv-key-version=12345; krb-srv-key-comp-flag=Y; krb-max-old-srv-keys=<1 to 256 (default 32)>; krb-ack-flag=Y; krb-timeout=<1 to 60 (default 32)>; krb-max-retry=<1 to 100 (default 10)>; krb-max-retry-time=<1 to 60 (default 20)>; krb-exp-retry-time=<1 to 60 (default 2)>; krb-reest-sa-ack-flag=<Y|N>;


Note If the krb-serv-key is changed, the srv-key-version must also be changed, and if the srv-key-version is changed, the krb-srv-key must also be changed.
The krb-serv-key and the srv-key-version must not exist in the ipsec-kerberos-keys table.


The mandatory parameters for this command are defined as follows:

krb-fqdn—Kerberos fully qualified domain name for the CA. It is used to create the CMS principal name. The KRB-FQDN must be the FQDN used on the KDC for this node. The entry must be from 1 to 256 ASCII characters. The source KRB FQDN must be valid hostname as described in gethostbyname(3XNET).


Note 'getprotobyname' is a Unix system function that refers to Internet protocols TCP, UDP, and so forth.


krb-realm—Kerberos realm, used to create the CMS principal name. The entry must be from 1 to 256 ASCII characters.

krb-srv-key—Kerberos service key, used for Kerberos communication. When assigning a new krb-srv-key, the existing krb-srv-key is added to the IPSEC Kerberos Keys table. The length must be 48 Hex characters, (0-9, A-F, a-f). Input is permitted with a delimiter for readability. For example:
"6854 7369 6920 2073 2061 656b 2079 666f 3220 2034 6863 2e61"
is equivalent to:
"68547369692020732061656b2079666f3220203468632e61."

srv-key-version—CMS server keys. This allows support to the CMS using different versions for a server key. The entry can be any integer from 1 to MAXINT.


Note MAXINT is defined as the largest possible 4-byte integer:  [2 to the power 32] - 1.


The optional parameters for this command are defined as follows:


Tip The default values for these optional parameters may be adequate for your specific case. In each case, you can use a show command to find out how the parameter is currently set.


krb-srv-key-comp-flag—Kerberos Service Key Compromised Flag. If enabled, tickets using the old service key are not accepted and a message is sent to the MTA instructing it to obtain a new ticket. If disabled, the old service key is accepted until the date and time specified in the ticket. Allowed values are Y and N (default value is N).

krb-max-old-srv-keys—Maximum number of records to be kept in the rolling list of old Kerberos service keys. The entry must be from 1 to 256 ASCII characters (default value is 32).

krb-ack-flag—Kerberos Acknowledgement Flag. If enabled, an acknowledgement is requested in the AP_REPLY. Allowed values are Y and N (default value is Y).

krb-timeout—Kerberos Timeout. The amount of time (in seconds) that the CMS waits for receipt of an AP_REQ following a WAKEUP. The range of values is 1 to 60 (default value is 3).

krb-max-retry—Kerberos Maximum Retries. The maximum number of times the CMS will send a WAKEUP without the receipt of an AP_REQ. The range of values is 1 to 100 (default value is 10).

krb-max-retry-time—Kerberos Maximum Retry Time. The maximum or the total time (in seconds) that the CMS sends WAKEUP messages before it stops. The range of values is 1 to 60 (default value is 20).


Note krb-max-retry-time must be greater than krb-timeout and krb-exp-retry-time.


krb-exp-retry-time—Kerberos Exponential Retry Time. The exponential backoff time (in seconds) for WAKEUP retries. The range of values is 1 to 60 (default value is 2).

krb-reest-sa-ack-flag—Kerberos Reestablish SA Acknowledgement Flag. If this flag is enabled, the CMS reestablishes the outbound SA before the hard expiration occurs. Allowed values are Y and N (default value is Y).

Step 3 To display the rolling list of old Kerberos service keys, enter the following command:

show ipsec-kerberos-keys;

The system will display the following parameters and their values:

krb-srv-key—Kerberos service key, used for Kerberos communication. The ipsec-kerberos-keys table contains the old Kerberos service keys used by IPsec and the associated key management application. When a new krb-serv-key is created in the add/change ipsec-kerberos command, the existing KRB-SRV-KEY is added to this table. This is a rolling list; when the list becomes full, the oldest service key is overwritten. The range of values is 1 to 48 ASCII characters (0 to 9, A to F [or a to f]).

Example: 546869732069732061206b6579206f66203234206368612e

srv-key-version—CMS server key versions, for example, 12345. This token supports use of different server key versions on the CMS. The entry can be any integer from 1 to MAXINT.


Note MAXINT is defined as the largest possible 4-byte integer:  [2 to the power 32] - 1.


srv-key-timestamp—A system-generated timestamp with the date and time that the entry was added. (This timestamp value must be entered if you want to delete an individual entry from the rolling list.)

Step 4 To add an IPsec policy for all incoming and outgoing traffic on the MTA, enter the following commands as applicable. (All of the token definitions for these commands are listed at the end of these steps.)

a. When the MTA vendor applies security policy on all ports, use action=apply for outbound traffic and action=permit for inbound traffic. Alternatively, you can use a single command with action=ipsec for all outbound and inbound traffic. (This is called a full-duplex security policy.)


Note You can enter a value for src-fqdn, or a value for src-ipaddr, but not both.
You can enter a value for dest-fqdn, or a value for dest-ipaddr, but not both.


Provisioning example using FQDNs:

add ipsec-policy id=mta01-out; src-fqdn=cms-ca1.ciscolab.com; dest-fqdn=mta1.ciscolab.com; action=apply;

AND

add ipsec-policy id=mta01-in; src-fqdn=mta1.ciscolab.com; dest-fqdn=cms-ca1.ciscolab.com; action=permit;

OR

add ipsec-policy id=mta01; src-fqdn=cms-ca1.ciscolab.com; dest-fqdn=mta1.ciscolab.com; action=ipsec

Provisioning example using IP addresses:

add ipsec-policy id=mta02-out; src_ipaddr=aaa.bbb.ccc.0; src_ipmask=255.255.255.0; dest_ipaddr=iii.jjj.kkk.lll; action=apply;

AND

add ipsec-policy id=mta02-in; src_ipaddr=aaa.bbb.ccc.0; src_ipmask=255.255.255.0; dest_ipaddr=iii.jjj.kkk.lll; action=permit;

OR

add ipsec-policy id=mta02; src_ipaddr=aaa.bbb.ccc.0; src_ipmask=255.255.255.0; dest_ipaddr=iii.jjj.kkk.lll; action=ipsec

b. When the MTA vendor applies security policy on a specific signaling port only, use action=apply for outbound traffic, and action=permit and dest-port=<destination port> for inbound traffic. This is called a half-duplex security policy.

add ipsec-policy id=mta01-out; src-fqdn=cms-ca1.ciscolab.com; dest-fqdn=mta1.ciscolab.com; action=apply;

AND

add ipsec-policy id=mta01-in; src-fqdn=mta1.ciscolab.com; dest-fqdn=cms-ca1.ciscolab.com; action=permit; dest-port=2727;

The token descriptions are as follows:

id—Policy ID. Service provider assigns, based on network configuration. Suggested format is <devicetype>NN, i.e. mta01, cmts01, rks01. The range is 1 to 8 ASCII characters. This is a mandatory token.

action—The action defines if security is applied to outbound or inbound traffic, both, or neither. This is a mandatory token. The allowed values are:

PERMIT—Security on inbound traffic.

APPLY—Security on outbound traffic.

IPSEC—Security on both inbound and outbound traffic.

BYPASS—No security

src-fqdn—Fully qualified domain name for the source network element that this security policy applies to. The source fqdn must be valid hostname as described in gethostbyname(3XNET). You cannot specify both a SRC-FQDN and a SRC-IPADDR at the same time. The entry must be from 1 to 256 ASCII characters.


Note 'getprotobyname' is a Unix system function that refers to Internet protocols TCP, UDP, and so forth.


src-ipaddr—IP Address for the source network element(s) that this security policy applies to. The source fqdn must be valid hostname as described in gethostbyname(3XNET). You cannot specify both a SRC-FQDN and a SRC-IPADDR at the same time. The range is 1 to 15 ASCII characters in IPv4 Internet decimal dot notation.

src-ipmask—(Valid only if SRC-IPADDR is specified) IP address mask used to establish the range of IP addresses for the source network element(s) that this security policy applies to. The range is 1 to 15 ASCII characters in IPv4 Internet decimal dot notation.

src-port—The specific port for the source network element that this security policy applies to. Range of values is 1 to 65534.

dest-fqdn—Fully qualified domain name for the destination network element that this security policy applies to. The destination fqdn must be valid hostname as described in gethostbyname(3XNET). You cannot specify both a DEST-FQDN and a DEST-IPADDR at the same time. The entry must be from 1 to 256 ASCII characters.

dest-ipaddr—IP Address for the destination network element(s) that this security policy applies to. The destination fqdn must be valid hostname as described in gethostbyname(3XNET). You cannot specify both a DEST-FQDN and a DEST-IPADDR at the same time. The range is 1 to 15 ASCII characters in IPv4 Internet decimal dot notation.

dest-ipmask—(Valid only if DEST-IPADDR is specified) IP address mask used to establish the range of IP addresses for the destination network element(s) that this security policy applies to. The range is 1 to 15 ASCII characters in IPv4 Internet decimal dot notation.

dest-port—Specific port for the destination network element that this security policy applies to. Range of values is 1 to 65534.

ulp-name—Upper layer protocol that the entry is matched against. You cannot specify both ULP-NAME and ULP-NUMBER at the same time. The value is a string as described in getprotobyname(3XNET), 1 to 8 ASCII characters long.

ulp-number—Upper layer protocol that the entry is matched against. You cannot specify both ULP-NAME and ULP-NUMBER at the same time. The value is a number as described in getprotobyname(3XNET), from 0 to 255.

Step 5 If necessary, enter values for additional security parameters for this MGW profile:

change mgw-profile id=cvmdqos; krb-reest-flag=[y|n]; ipsec-sa-esp-cs=[cipher suite for ESP]; ipsec-sa-lifetime=[IPsec SA expiration time]; ipsec-sa-grace-period=[expiration grace period]; ipsec-ulp-name=[IP | UDP | TCP]; ike-group=[1|2]; ike-sa-lifetime=[IKE SA expiration time]; ike-cs=[cipher suite for IKE]; ike-key=[IKE pre-shared key];

The following acronyms are used in the descriptions below:

IPsec — Internet protocol security

SA — Security association

ESP — Encapsulating security payload

IKE — Internet key exchange

id—ID assigned to this mgw-profile by the service provider. This ID is required and can be 1 through 16 ASCII characters. There is no default value.

krb-reest-flag—Kerberos reestablishment flag. If the flag is enabled, the Kerberos SA will be reestablished automatically upon expiration. The value of this optional token is a single ASCII character (Y or N); the default value is Y (yes), which means that automatic Kerberos SA reestablishment is supported. The token must be set to N (no) to disable automatic reestablishment.

ipsec-sa-esp-cs—Specifies the IPsec SA ESP cipher suite list in priority order. This list is used to negotiate an encryption-authentication algorithm pair that will be used by IPsec. The default value is the list 3DES-MD5, 3DES-SHA1, NULL-MD5, NULL-SHA1. This list can be changed to a subset of this initial list, and may be reordered to specify a new priority selection. Note that the list contains cipher suites using the authentication algorithms HMAC-MD5 and HMAC-SHA and the encryption algorithms ESP-3DES and ESP-NULL only.

ipsec-sa-lifetime—Sets the IPsec SA expiration in seconds. This is the hard expiration. The range of values is 0 through MAXINT, the default value is 86400.


Note MAXINT is defined as the largest possible 4-byte integer:  [2 to the power 32] - 1.


ipsec-sa-grace-period—Sets the IPsec SA key expiration grace period in seconds. This is used to calculate the soft expiration. The range of values is 0 through MAXINT seconds, the default value is 21600.


Note ipsec-sa-grace-period must be less than or equal to 25% of the provisioned value for ipsec-sa-lifetime. If not specified when provisioning a new ipsec-sa-lifetime, the ipsec-sa-grace-period defaults to 25% of the ipsec-sa-lifetime.


ipsec-ulp-name—Specifies a single IPsec SA upper layer protocol. Use this token if the SA should be created only for specific protocol traffic for this device class. The value is a string as described in gethostbyname(3XNET). The allowed values are IP, TCP, and UDP (default value is IP).


Note 'getprotobyname' is a Unix system function that refers to Internet protocols TCP, UDP, and so forth.


ike-group—Identifies the available groups in which the Diffie-Helman exchange may occur. The possible values are 1 and 2. The default value is 2.

ike-sa-lifetime—Specifies the IKE SA expiration in seconds. The range of values is 0 through MAXINT, the default value is 86400.

ike-cs—Specifies a list of cipher suites supported by IKE, in priority order. This list is used to negotiate an encryption-authentication algorithm pair that will be used by IKE. The default value is the list 3DES-MD5, 3DES-SHA1. This list can be changed to a subset of this initial list, and may be reordered to specify a new priority selection. Note that the list contains cipher suites using the authentication algorithms HMAC-MD5 and HMAC-SHA and the encryption algorithm ESP_3DES only.

ike-key—IKE preshared key. The entry must be from 1 to 256 ASCII characters. There is no default value.


Provisioning Security Interfaces to the CMTS

Follow these steps to provision security interfaces to the CMTS.


Note The token values shown in this section are examples.



Step 1 Login to a CLI session on the Cisco BTS 10200 Softswitch.

Step 2 To add a security policy for the CMTS, enter the following command:

add ipsec-policy id=cmts01; src-fqdn=cms-ca1.ciscolab.com; dest-fqdn=cmts1.ciscolab.com; action=ipsec;


Note You can enter a value for src-fqdn, or a value for src-ipaddr, but not both.
You can enter a value for dest-fqdn, or a value for dest-ipaddr, but not both.


id—Policy ID. Service provider assigns, based on network configuration. Suggested format is <devicetype>NN, i.e. mta01, cmts01, rks01. The range is 1 to 8 ASCII characters. This is a mandatory token.

action—The value of the action token defines whether security is applied to outbound or inbound traffic, both, or neither. This is a mandatory token. The allowed values are:

PERMIT—Security on inbound traffic.

APPLY—Security on outbound traffic.

IPSEC—Security on both inbound and outbound traffic.

BYPASS—No security

src-fqdn—Fully qualified domain name for the source network element that this security policy applies to. The source fqdn must be valid hostname as described in gethostbyname(3XNET). You cannot specify both a SRC-FQDN and a SRC-IPADDR at the same time. The entry must be from 1 to 256 ASCII characters.


Note 'getprotobyname' is a Unix system function that refers to Internet protocols TCP, UDP, and so forth.


dest-fqdn—Fully qualified domain name for the destination network element that this security policy applies to. The destination fqdn must be valid hostname as described in gethostbyname(3XNET). You cannot specify both a DEST-FQDN and a DEST-IPADDR at the same time. The entry must be from 1 to 256 ASCII characters.

Step 3 To enable IPsec on the CMTS, enter the following command:

change aggr id=cmts1; tsap-addr=[DNS/IP-address]; ike-key=<IKE preshared security key>;

id—ID assigned to this CMTS by the service provider. This ID is required and can be 1 through 16 ASCII characters. There is no default value.

tsap-addr—Specifies the DNS/IP address for the CMTS. The entry can be 1 to 64 ASCII characters. There is no default value.


Note If you enter a DNS address for tsap-addr, it must be a fully qualified domain name (FQDN).


ike-key—IKE preshared key. The entry must be from 1 to 256 ASCII characters. There is no default value.

Step 4 If necessary, enter values for additional security parameters for this CMTS:


Tip The default values for these optional parameters may be adequate for your specific case. In each case, you can use a show command to find out how the parameter is currently set.



Note The aggr id and tsap-addr are both required in this command.


change aggr id=cmts1; tsap-addr=[DNS/IP-address]; ipsec-sa-esp-cs=[cipher suite for ESP]; ipsec-sa-lifetime=[IPsec SA expiration time]; ipsec-sa-grace-period=[expiration grace period]; ipsec-ulp-name=[IPsec SA upper layer protocol]; ike-group=[1|2]; ike-sa-lifetime=[IKE SA expiration time]; ike-cs=[cipher suite for IKE]; ike-key=234; description=CMTS_City1;

The following acronyms are used in the descriptions below:

IPsec — Internet protocol security

SA — Security association

ESP — Encapsulating security payload

IKE — Internet key exchange

ipsec-sa-esp-cs—IPsec SA ESP cipher suite list in priority order. This list is used to negotiate an encryption-authentication algorithm pair that will be used by IPsec. The default value is the list 3DES-MD5, 3DES-SHA1, NULL-MD5, NULL-SHA1. This list can be changed to a subset of this initial list, and may be reordered to specify a new priority selection. Note that the list contains cipher suites using the authentication algorithms HMAC-MD5 and HMAC-SHA and the encryption algorithms ESP-3DES and ESP-NULL only.

ipsec-sa-lifetime—Sets the IPsec SA expiration in seconds. This is the hard expiration. The range of values is 0 through MAXINT, the default value is 86400.

ipsec-sa-grace-period—Sets the IPsec SA key expiration grace period in seconds. This is used to calculate the soft expiration. The range of values is 0 through MAXINT, the default value is 21600.


Note ipsec-sa-grace-period must be less than or equal to 25% of the provisioned value for ipsec-sa-lifetime. If not specified when provisioning a new ipsec-sa-lifetime, the ipsec-sa-grace-period defaults to 25% of the ipsec-sa-lifetime.


ipsec-ulp-name—Specifies a single IPsec SA upper layer protocol. Use this token if the SA should be created only for specific protocol traffic for this device class. This value is a string as described in gethostbyname(3XNET). The allowed values are IP, TCP, and UDP (default value is IP).


Note 'getprotobyname' is a Unix system function that refers to Internet protocols TCP, UDP, and so forth.


ike-group—Identifies the available groups in which the Diffie-Helman exchange may occur. The possible values are 1 and 2. The default value is 2.

ike-sa-lifetime—IKE SA expiration in seconds. The range of values is 0 through MAXINT. The default value is 86400.

ike-cs—Specifies a list of cipher suites supported by IKE, in priority order. This list is used to negotiate an encryption-authentication algorithm pair that will be used by IKE. The default value is the list 3DES-MD5, 3DES-SHA1. This list can be changed to a subset of this initial list, and may be reordered to specify a new priority selection. Note that the list contains cipher suites using the authentication algorithms HMAC-MD5 and HMAC-SHA1 and the encryption algorithm ESP-3DES only.

ike-key—IKE preshared key. The entry must be from 1 to 256 ASCII characters. There is no default value.

description—User-defined description, 1 to 64 ASCII characters in length.


Provisioning Security Interfaces to the TGW

Follow these steps to provision security interfaces to the TGW.


Note The token values shown in this section are examples.



Step 1 Login to a CLI session on the Cisco BTS 10200 Softswitch.

Step 2 To add a security policy for the TGW, enter the following command:

add ipsec-policy id=tgw01; src-fqdn=cms-ca1.ciscolab.com; dest-fqdn=tgw1.ciscolab.com; action=ipsec;


Note You can enter a value for src-fqdn, or a value for src-ipaddr, but not both.
You can enter a value for dest-fqdn, or a value for dest-ipaddr, but not both.


id—Policy ID. Service provider assigns, based on network configuration. Suggested format is <devicetype>NN, i.e. mta01, cmts01, rks01. The range is 1 to 8 ASCII characters. This is a mandatory token.

action—The action defines if security is applied to outbound or inbound traffic, both, or neither. This is a mandatory token. The allowed values are:

PERMIT—Security on inbound traffic.

APPLY—Security on outbound traffic.

IPSEC—Security on both inbound and outbound traffic.

BYPASS—No security

src-fqdn—Fully qualified domain name for the source network element that this security policy applies to. The source fqdn must be valid hostname as described in gethostbyname(3XNET). You cannot specify both a SRC-FQDN and a SRC-IPADDR at the same time. The entry must be from 1 to 256 ASCII characters.


Note 'getprotobyname' is a Unix system function that refers to Internet protocols TCP, UDP, and so forth.


dest-fqdn—Fully qualified domain name for the destination network element that this security policy applies to. The destination fqdn must be valid hostname as described in gethostbyname(3XNET). You cannot specify both a DEST-FQDN and a DEST-IPADDR at the same time. The entry must be from 1 to 256 ASCII characters.

Step 3 To enable IPsec on the TGW, change the MGW profile entry associated with this TGW. Changing this entry will enable security for all TGWs that use this profile so you may want to have a security-enabled and security-disabled profile for each vendor class.

change mgw-profile id=tgw1; ike-key=<IKE preshared security key>;

where:

ike-key—IKE preshared key. The entry must be from 1 to 256 ASCII characters. There is no default value.

Step 4 If necessary, enter values for additional security parameters for this MGW profile, using the tokens described in Step 5 of the "Provisioning Security Interfaces to the MTA" section.


Provisioning Security Interfaces to the RKS

Enter the following commands to provision security interfaces to the RKS.


Note The token values shown in this section are examples.



Step 1 Login to a CLI session on the Cisco BTS 10200 Softswitch.

Step 2 To add a security policy for the RKS, enter the following command:

add ipsec-policy id=rks01; src-fqdn=cms-ca1.ciscolab.com; dest-fqdn=rks1.ciscolab.com; action=ipsec;


Note You can enter a value for src-fqdn, or a value for src-ipaddr, but not both.
You can enter a value for dest-fqdn, or a value for dest-ipaddr, but not both.


id—Policy ID. Service provider assigns, based on network configuration. Suggested format is <devicetype>NN, i.e. mta01, cmts01, rks01. The range is 1 to 8 ASCII characters. This is a mandatory token.

action—The action defines if security is applied to outbound or inbound traffic, both, or neither. This is a mandatory token. The allowed values are:

PERMIT—Security on inbound traffic.

APPLY—Security on outbound traffic.

IPSEC—Security on both inbound and outbound traffic.

BYPASS—No security

src-fqdn—Fully qualified domain name for the source network element that this security policy applies to. The source fqdn must be valid hostname as described in gethostbyname(3XNET). You cannot specify both a SRC-FQDN and a SRC-IPADDR at the same time. The entry must be from 1 to 256 ASCII characters.


Note 'getprotobyname' is a Unix system function that refers to Internet protocols TCP, UDP, and so forth.


dest-fqdn—Fully qualified domain name for the destination network element that this security policy applies to. The destination fqdn must be valid hostname as described in gethostbyname(3XNET). You cannot specify both a DEST-FQDN and a DEST-IPADDR at the same time. The entry must be from 1 to 256 ASCII characters.

Step 3 To enable IPsec on the RKS, enter the following command:

change radius-profile id=[primary RKS id | secondary RKS id]; tsap-addr=[ip-address | ip-address:port-number]; ike-key=<IKE preshared security key>;

id—A string that identifies the primary or secondary RKS. This required token can be from 1 to 16 ASCII characters. There is no default value.

tsap-addr—Unique IP address or IP address and port number of the primary or secondary RKS. This required token can be from 1 to 64 ASCII characters (max). There is no default value. This value must be an IP address (not a domain name).

Step 4 If necessary, enter values for additional security parameters for this RADIUS profile:


Tip The default values of these security parameters are sufficient for some networks. Before making any changes, you can use the show command to determine if changes are needed to any of the default values.


change radius-profile id=[primary RKS id | secondary RKS id]; tsap-addr=[ip-address | ip-address:port-number]; ipsec-sa-esp-cs=[cipher suite for ESP]; ipsec-sa-lifetime=[IPsec SA expiration time]; ipsec-sa-grace-period=[expiration grace period]; ipsec-ulp-name=[SA upper layer protocol]; ike-group=[1|2]; ike-sa-lifetime=[IKE SA expiration time]; ike-cs=[cipher suite for IKE];

The following acronyms are used in the descriptions below:

IPsec — Internet protocol security

SA — Security association

ESP — Encapsulating security payload

IKE — Internet key exchange

id—ID assigned to this rks-profile by the service provider. This ID is required and can be 1 through 16 ASCII characters. There is no default value.

tsap-addr—Unique IP address—or IP address and port number—of the primary or secondary RKS. This required token can be from 1 to 64 ASCII characters. There is no default value. This value must be an IP address (not a DNS name).

ipsec-sa-esp-cs—IPsec SA ESP cipher suite list in priority order. This list is used to negotiate an encryption-authentication algorithm pair that will be used by IPsec. The default value is the list 3DES-MD5, 3DES-SHA1, NULL-MD5, NULL-SHA1. This list can be changed to a subset of this initial list, and may be reordered to specify a new priority selection. Note that the list contains cipher suites using the authentication algorithms HMAC-MD5 and HMAC-SHA and the encryption algorithms ESP-3DES and ESP-NULL only.

ipsec-sa-lifetime—Sets the IPsec SA expiration in seconds. This is the hard expiration. The range of values is 0 through MAXINT, the default value is 86400.


Note MAXINT is defined as the largest possible 4-byte integer, that is, [2 to the power 32] - 1.


ipsec-sa-grace-period—Sets the IPsec SA key expiration grace period in seconds. This is used to calculate the soft expiration. The range of values is 0 through MAXINT, the default value is 21600.


Note ipsec-sa-grace-period must be less than or equal to 25% of the provisioned value for ipsec-sa-lifetime. If not specified when provisioning a new ipsec-sa-lifetime, the ipsec-sa-grace-period defaults to 25% of the ipsec-sa-lifetime.


ipsec-ulp-name—Specifies a single IPsec SA upper layer protocol. Use this token if the SA should be created only for specific protocol traffic for this device class. This value is a string as described in gethostbyname(3XNET). The allowed values are IP, TCP, and UDP (default value is IP).

ike-group—Available groups in which the Diffie-Helman exchange may occur. Possible values are 1 and 2 (default value is 2).

ike-sa-lifetime—IKE SA expiration in seconds. The range is 0 to MAXINT (default value is 86400).

ike-cs—Specifies a list of cipher suites supported by IKE, in priority order. This list is used to negotiate an encryption-authentication algorithm pair that will be used by IPsec. The default value is the list 3DES-MD5, 3DES-SHA1. This list can be changed to a subset of this initial list, and may be reordered to specify a new priority selection. Note that the list contains cipher suites using the authentication algorithms HMAC-MD5 and HMAC-SHA and the encryption algorithm ESP-3DES only.

ike-key—IKE pre-shared key, from 1 to 256 ASCII characters. There is no default value.


Provisioning IPsec Security Associations

The IPsec security association (SA) table, IPSEC-SA, contains the IPsec SAs that are not associated with IKE or Kerberos key management. Provision the SAs as described in this section.


Note The token values shown in this section are examples.



Step 1 Login to a CLI session on the Cisco BTS 10200 Softswitch.

Step 2 To add a security association for a device, enter the following command:

add ipsec-sa id=cmts01; auth-algo=HMAC-SHA-1; auth-key=2069732061206b6579206f66203234206368612e; dest=aaa.bbb.ccc.ddd; encrypt-algo=DES; encrypt-key=4bb586a120532c07; spi=-85723; src=eee.fff.ggg.hhh; soft-lifetime=3600; hard-lifetime=7200;

where:

id—Service Provider assigns the ID or SA Identifier, based on network configuration. Range of values is 1 to 8 ASCII characters; suggested format is <device-type>NN, i.e. mta01, cmts01, rks01. This token is mandatory.

auth-algo—Specifies the authentication algorithm for an SA. The possible values are HMAC-MD5 or HMAC-SHA-1. This token is mandatory.

auth-key—This mandatory token specifies the authentication key for this SA, expressed as a string of hexadecimal digits (0 to 9, A to F [or a to f]). The length of the key varies depending on the value provisioned for auth-algo:

= If auth-algo=HMAC-MD5, you must use an auth-key with 32 ASCII characters.

= If auth-algo=HMAC-SHA-1, you must use an auth-key with 40 ASCII characters.

dest—This mandatory token specifies the destination address of the SA. The range is 1 to 15 ASCII characters, in IPv4 Internet decimal dot notation. The destination address value must be a valid host as described in gethostbyname(3XNET).

encrypt-algo—This mandatory token specifies the encryption algorithm for an SA. The possible values are DES or 3DES.

encrypt-key—This mandatory token specifies the authentication key for this SA, expressed as a string of hexadecimal digits (0 to 9, A to F [or a to f]). The length of the key varies depending on the value provisioned for encrypt-algo:

= If encrypt-algo=DES, you must use an encrypt-key with 16 ASCII characters.

= If encrypt-algo=3DES, you must use an encrypt-key with 48 ASCII characters.

spi—The SPI is the security parameters index of the SA. The value can be any valid integer. from -MAXINT to MAXINT. This token is mandatory.


Note MAXINT is defined as the largest possible 4-byte integer:  [2 to the power 32] - 1.


src—This optional token specifies the source address of the SA. The range is 1 to 15 ASCII characters, in IPv4 Internet decimal dot notation. The destination address value must be a valid host as described in gethostbyname(3XNET).


Note 'getprotobyname' is a Unix system function that refers to Internet protocols TCP, UDP, and so forth.


soft-lifetime—This optional token specifies the number of seconds that this SA can exist. When the soft lifetime expires, an SADB_EXPIRE message is transmitted by the system, and the SA is changed to DYING. The range is 0 to MAXINT (default value is 0). Elapsed time is measured from the time the SA was added.


Note If soft-lifetime is set to 0 (which is the default value), the SA does not expire based on the time elapsed


hard-lifetime—This optional token specifies the number of seconds that this SA can exist. When the hard lifetime expires, the SA is deleted automatically by the system. The range is 0 to MAXINT (default value is 0). Elapsed time is measured from the time the SA was added.


Note If hard-lifetime is set to 0 (which is the default value), the SA does not expire based on the time elapsed.



Provisioning Ciphersuite Encryption and Authentication Algorithms

A cipher is an algorithm that transforms data between plain text and encrypted text. A ciphersuite consists of both an encryption algorithm and a message authentication algorithm. The CIPHERSUITE-PROFILE and CIPHERSUITE tables provision the allowed ciphersuites for media security (encryption of bearer path data) between two MTAs.

Enter the following commands to create the ciphersuite profile and specify the allowed ciphersuites.


Step 1 Login to a CLI session on the Cisco BTS 10200 Softswitch.

Step 2 To create a ciphersuite profile, enter the following command:

add ciphersuite-profile id=cp1gold; description=This ID is used for QoS gold.

where:

id—ID of this ciphersuite-profile, 1 to 16 ASCII characters in length.

description—Description of this ciphersuite (optional parameter), 1 to 64 ASCII characters in length.

Step 3 To create ciphersuite data supporting the ciphersuite profile, enter the following command:

add ciphersuite id=cp1gold; proto-type=RTP; auth-algo=RTP-NULL; encrypt-algo=RTP-NULL; priority=1;

where:

id—ID of the ciphersuite-profile to which this data applies, 1 to 16 ASCII characters in length.

proto-type—Specifies whether the authentication and encryption algorithms apply to RTP or RTCP.


Note RTP = Real-time protocol. Encrypted packets are carried end-to-end in RTP packets.

RTCP = Real-time control protocol. RTCP is a protocol for encapsulating the encoded voice and video streams.


auth-algo—Specifies the authentication algorithm to use. The allowed values for this parameter depend on the value entered for proto-type:

for proto-type=RTP, auth-algo can be any of the following: RTP-NULL, RTP-MMH-2, or RTP-MMH-4

for proto-type=RTCP, auth-algo can be any of the following: RTCP-NULL, RTCP-HMAC-SHAI-96, or RTCP-HMAC-MD5-96.

encrypt-algo—Specifies the encryption algorithm to use. The allowed values for this parameter depend on the value entered for proto-type:

for proto-type=RTP, encrypt-algo can be any of the following: RTP-NULL, RTP-AES, RTP-XDESX-CBC, RTP-DES-CBC-PAD, RTP-3DES-CBC, RTP-RC4.

for proto-type=RTCP, encrypt-algo can be any of the following: RTCP-NULL, RTCP-AES-CBC, RTCP-XDESX-CBC, RTCP-DES-CBC-PAD, RTCP-3DES-CBC.


Note Authentication and encryption algorithms are identified in the PacketCable Security Specification, PKT-SP-SEC-I07-021127.


priority—Specifies the priority of the ciphersuite. The ciphersuite parameters are sent in the Local Connection Options (LCO) in the order specified. The values for this parameter are 1 to 32, with 1 being the highest priority and 32 the lowest.

For example, if 64/51 has priority 10 and 62/53 has priority 15 then they will go as sc-rtp:64/51; 62/53. The gateway will choose 64/51 if it is able to do so. If the gateway is not able to handle 64/51 then it will choose 62/53.


Note Refer to the PacketCable Network-Based Call Signaling Protocol Specification, PKT-SP-EC-MGCP-I06-021127, for additional information on the sc-rtp and sc-rtcp parameters.


Events and Alarms for the Security Interface Feature

The following events and alarms can be generated in response to PacketCable-related security signaling conditions.


Note This list provides only the events and alarms that are specifically for the PacketCable-based security feature, and includes only the name and description of each alarm. Detailed descriptions of all events and alarms (for all network protocols and NEs connected to the Cisco BTS 10200 Softswitch), and recommended corrective actions, are presented in the Cisco BTS 10200 Softswitch Operations, Maintenance, and Troubleshooting Guide.



Note Events and alarms related to PacketCable-based NEs and event messages are presented in separate sections in this document ("Events and Alarms Specific to PacketCable-Based Nodes" and "Events and Alarms for the EM Feature").


The following alarms and events are added for the security functions:

SECURITY Alarm #3
IPsec connection down (MAJOR)

SECURITY Event #4
IPsec MTA Key Establish Error (WARNING)

SECURITY Event #5
IPsec outgoing SA not found (WARNING)

Appendix A: DQoS Feature Description

This section provides a brief overview of the features provided by a PacketCable DQoS network. For more detailed information, refer to the PacketCable Dynamic Quality of Service Specification, PKT-SP-DQOS-I05-021127, dated November 27, 2002. This industry-standard specification was developed to deliver dynamic QoS for enhanced communications services using packet data transmission technology to consumers' homes over existing cable networks.

PacketCable DQoS defines a QoS architecture for the "access" portion of the PacketCable network, which is defined as the segment between the MTA and the Cable Modem Termination System (CMTS), including the Data Over Cable System Interface Specification (DOCSIS) network. For more detailed information on PacketCable network components see http://www.cablemodem.com/specifications/.

DOCSIS Specifications

The DOCSIS specifications provide the network layer QoS mechanisms responsible for classifying, policing, scheduling, and marking packets once the traffic flows are established by the DQoS signaling protocols. The DOCSIS QoS architecture is based on the following objects:

Service Class—A collection of settings maintained by the CMTS that provide a specific QoS service tier to a cable modem that has been assigned a service flow within a particular service class.

Service Flow—A unidirectional sequence of packets transported across the RF interface between the cable modem and the CMTS. The basic unit of QoS is the service flow, which is characterized by a set of QoS parameters such as latency, jitter, and throughput assurances.

Every cable modem establishes a primary service flow in both the upstream and downstream directions. The primary flows maintain connectivity between the cable modem and CMTS at all times. In addition, a DOCSIS-compliant cable modem can establish multiple secondary service flows. Secondary service flows can be permanent (they persist until the cable modem is reset or powered off) or they can be created dynamically to meet the needs of on-demand traffic.

Each service flow has a set of QoS attributes associated with it. These QoS attributes define a particular class of service and determine characteristics, such as the maximum bandwidth for the service flow and the priority of its traffic. The class of service attributes can be inherited from a preconfigured CMTS local service class (class-based flows), or they can be individually specified at the time of the creation of the service flow.

Packet Classifier—A set of packet header fields used to classify packets in a service flow to which the classifier belongs. Each service flow has multiple packet classifiers associated with it, which determine the type of application traffic allowed to be sent on that service flow.

Payload Header Suppression (PHS) rule—Determines the set of packet header fields that are suppressed by the sending entity before transmitting on the link. These packet header fields are restored by the receiving entity after receiving a header-suppressed frame transmission. The PHS rule increases the bandwidth efficiency by removing repeated packet headers before transmission.

DQoS Architecture

The basic PacketCable architecture defines the softswitch architecture for voice-over-IP. The core set of PacketCable specifications describe how to move the basic functions that are typically consolidated on a single, expensive Class 5 central office switch onto several general-purpose servers, which leads to a low-cost, highly flexible, scalable, distributed architecture. The PacketCable architecture is flexible and can be extended to support a wide variety of advanced real-time multimedia services.

For purposes of managing QoS, the bearer RTP channel for a session is managed as three segments:

an access network for the originating side of the session

a backbone network for the bearer channel portion of the session

an access network for the terminating side of the session

DOCSIS "access" network resources are managed as a pair of dynamic service flows, using the mechanisms defined in the DOCSIS specifications. Backbone resources can be managed on either a per-flow basis or through an aggregated QoS mechanism. The management of backbone resources is beyond the scope of this document; here we will deal only with the access portions of the network.

Figure 6 is a high level diagram of a PacketCable DQoS network architecture that shows the three segment model. In this diagram, the network elements impacted by DQoS are the Multimedia Terminal Adapter (MTA), the Cable Modem Termination System (CMTS), the Call Management Server (CMS), and the Record Keeping Server (RKS).

The Cisco BTS 10200 Softswitch performs the functions of the CMS in a DQoS capable network.

Figure 6 PacketCable DQoS Architecture

The following paragraphs describe each of the components in the PacketCable DQoS network:

Multimedia Terminal Adapter (MTA)

The MTA is the network client device that resides at the customer site and is connected through the DOCSIS 1.1 channel to the network. All MTAs are assumed to implement the NCS multimedia signaling protocol. An MTA can be either a device with a standard two-wire telephone set, or it can add video input/output capabilities.

Cable Modem (CM)

The CM is the PacketCable network element responsible for classifying, policing, and marking packets once the traffic flows are established by the DQoS signaling protocols.

Cable Modem Termination System (CMTS)

The CMTS is responsible for allocating and scheduling upstream and downstream bandwidth in accordance with MTA requests and QoS authorizations established by the network administrator. The CMTS implements a "DQoS Gate" between the DOCSIS cable network and an IP backbone. The DQoS Gate is implemented using the packet classification and filtering functions defined for DOCSIS 1.1. Once use of network resources are authorized on a DQoS Gate by the Gate Controller, the QoS interface between the MTA/CM and the CMTS is used to reserve, commit (activate), and de-allocate network resources for the authorized DQoS Gate.

Call Management Server (CMS)

The Call Management Server entity performs services that permit MTAs to establish Multimedia sessions (including voice communications). A CMS using the Network-Controlled Call Signaling (NCS) model implements a call agent that directly controls the session and maintains per-call state.

The CMS ID is a PacketCable network element identifier. A unique value for each network element must be chosen by the service provider and datafilled. These ids are used for event message correlation at the RKS. All element ids in the network, their financial entities, and their RKS are expected to be assigned initially at the planning stage for proper management.

The portion of the CMS that performs QoS-related functions is called the Gate Controller (GC). In the DQoS model, the GC controls the operation of the DQoS gates implemented on a CMTS. The DQoS authorization interface between the GC and the CMTS is used to allocate and authorize the use of network resources by an MTA. The functionality described in this document specifically address the Gate Controller functions provided by the Cisco BTS 10200 Softswitch operating in the dual roles of Call Management Server and Gate Controller (CMS/GC).

Media Gateway Controller (MGC)

The Cisco BTS 10200 Softswitch performs the function of a media gateway controller (MGC), providing signaling to trunking gateways (TGWs). This allows calls to be connected between the PacketCable network and the PSTN. The MGC-TGW signaling protocol is Trunking Gateway Control Protocol (TGCP).

Record Keeping Server (RKS)

The Record Keeping Server is a PacketCable network element that receives information only from the PacketCable elements described in this document. The RKS is used in the Cisco implementation as a billing server.

Appendix B:
Event Message Generation Details and Content

This section describes the internal processes for EM generation and the content of the EMs. These features are based on the PacketCable Event Message Specification (PKT-SP-EM-I07-030815) and a number of PacketCable ECNs.


Note For information on compliance to specific paragraphs of PacketCable standards and ECNs, please contact your Cisco account team.


EM Generation Details

The event messages generated by specific call configurations are listed in Table 3. The details of what event messages are required in each call configuration along with supported services are found in the PacketCable Event Message Specification (PKT-SP-EM-I07-030815).

Table 3 Event Messages Generated by Call Configuration 

Cisco BTS 10200 Generates Event Messages for —
Call Configuration
on-net to on-net
on-net to off-net
off-net to on-net

Originating CMS

X

X

 

Terminating CMS

X

 

X

Originating MGC

 

 

X

Terminating MGC

 

X

 


The specific event messages that can be generated by the CMS and MGC are listed in Table 4:

Table 4 Event Messages Generated by Logical Entity 

Event Message
CMS
MGC

Signaling_Start

X

X

Signaling_Stop

X

X

Interconnect_Start

 

X

Interconnect_Stop

 

X

Call_Answer

X

X

Call_Disconnect

X

X

Database_Query

X

 

Service_Instance

X

 

Service_Activation

X

 

Service_Deactivation

X

 

Media_Alive

X

X

Time_Change

X

X


The details of what event messages are required in each call configuration along with supported services are found in the PacketCable Event Message Specification (PKT-SP-EM-I07-030815). Table 5 lists the event messages for a call and the triggers that generate them (single zone scenario only) in the appropriate logical entities running in the Cisco BTS 10200 Softswitch (CMS/MGC).

Table 5 Event Message Triggers by Logical Entity 

Event Message
Originating CMS
Terminating CMS
Originating MGC
Terminating MGC

Signaling_Start

Timestamp: Receipt of NCS NTFY
Send: after translation

Prop trigger

1. Receipt of IAM
or
2. Receipt of TGCP NTFY

Receipt of Invite (prop)

Signaling_Stop

If T-CMS releases first: receipt of 250RSP to DLCX

If O-CMS releases first: before deallocating call block

If O-CMS releases first: receipt of 250RSP to DLCX

If T-CMS releases first: before deallocating call block

If T-MGC releases first: upon last of following events: 1.Receipt/Transmit RLC from/to SG 2.Receipt/transmit of Ack for TGCP DLCX 3.Receipt/transmit last msg from/to T-CMS (prop)

If O-MGC releases first: before deallocating call block

Receipt of 250OK to DLCX

Interconnect_Start

 

 

Transmit/receipt of ACM

Transmit/receipt of ACM

Interconnect_Stop

 

 

Release of PSTN bandwidth

Release of PSTN bandwidth

Call_Answer

Receipt of 200OK to Invite with call answer

Receipt of NCS NTFY for off-hook of T-MTA

1. Receipt of ANM or
2. answer ind on op.service

1. Receipt of ANM or
2. answer ind on op.service

Call_Disconnect

Transmit DLCX or
delete connection on errors

Transmit DLCX

1. Receipt of REL or 2. Transmit BYE for REL

1. Receipt of REL or 2. Disconnect ind on op. service trunk disconnect

Database_Query

Receipt of response from DB/Intelligent peripheral

Receipt of response from DB/Intelligent peripheral

 

 

Service_Instance

Operation of service

Operation of service

 

 

Service_Activation

Successful activation

Successful activation

 

 

Service_Deactivation

Successful deactivation

Successful deactivation

 

 

Media_Alive

Periodic, based on provisioned parameters

Periodic, based on provisioned parameters

Periodic, based on provisioned parameters

Periodic, based on provisioned parameters

Time_Change

When time is adjusted

When time is adjusted

When time is adjusted

When time is adjusted


Table 6 lists the PacketCable 1.0 features, the event messages generated for them, and the event that triggers the message. Some of the triggering events include the logical entities—Originating CMS (O-CMS) and Terminating CMS (T-CMS)—running in the Cisco BTS 10200 Softswitch.

Table 6 PacketCable 1.0 Features and Associated Event Messages 

PacketCable 1.0 Feature
EMs Sent in Addition to Basic Call EMs
Comments
Event Message
Trigger

1.

911 service - similar to on-net to off-net call on a unique trunk group ID.

none

 

 

2.

Other N11 services - similar to above

none

 

 

3.

Database query

 

a. Send all database queries to PSTN
on special trunk

none

 

 

 

b. Query database and route accordingly

db_query

O-CMS on receipt of response to database dip

Query types:

1=Toll Free Number Lookup

2=LNP Number Lookup

3=Calling Name Delivery Lookup


If the query is successful—that is, the query returns the calling party's name—the query type (1, 2, or 3) is included in the EM.

For types 1 and 2, the value in the EM Return_Number field contains the new called party digits.

For type 3, the value in the EM Return_Number field contains a valid string, such as "O" or "P". (See footnote). 1


If the query fails, no EM is sent.

4.

Operator service

 

a. 0- service (no digit after 0)

none

Called party # 0 is replaced by Operator Service Provider #

Only call routing

 

b. 0+ service (digits after 0, not needed in PacketCable 1.0)

 

 

Only call routing

5.

Call block service (with new call to announcement server)

service instance

O-CMS and T-CMS decide to block call

If announcement server is connected, event messages are generated for call with same BCID

6.

Call waiting

 

a. Announcement server on net

Service instance

O-CMS and T-CMS when call waiting is initiated. Second call BCID for service instance

Only two calls, one active and one on hold is required. Each half call generates EM. Half call for on-net announcement server for call waiting tone need not generate EM.

A calls B, C calls A (CfiA AfiB) BCID1 for A(O), other leg BCID2
BCID2 for B(T), other leg BCID1
BCID3 for C(O), other leg BCID4
BCID4 for A(T), other leg BCID3

BCID4 for CW service instance, related BCID = BCID1

 

b. Announcement server on PSTN

not supported

 

 

7.

Call forwarding

Service instance

CMS (O/T) when forwarded call leg is initiated

A calls B, B forwards to C. (AfiBfiC)
BCID1 for A(O), other leg BCID2
BCID2 for B(T), other leg BCID1
BCID3 for B(O), other leg BCID4
BCID4 for C(T), other leg BCID3
BCID3 for CFW service instance, related BCID=BCID2

8.

Return call (with caller ID privacy restriction)

CMS-CMS signaling is not supported in this release.

 

a. Announcement server on net

service instance

O-CMS on feature initiation

 

 

b. Announcement server on PSTN

not supported

 

 

9.

Repeat call (*66)

CMS-CMS signaling is not supported in this release.

 

a. Announcement server on net

service instance

Repeat call is initiated

Separate BCID for service instance

 

b. Announcement server on PSTN

not supported

 

 

10.

Voice mail (voice mail server on off-net)

none

   
 

Deposit & retrieval: similar to on-net to off-net call

none

 

 

11.

Message waiting indicator

none

 

No event messages for message waiting.

1 "O" = Name is out of area, unknown, or not available. "P" = Name presentation is restricted.


EM Content

The following event messages for a call contain the attributes listed, and are based on the four logical entities—Originating CMS (O-CMS), Terminating CMS (T-CMS), Originating MGC (O-MGC), and Terminating MGC (T-MGC)—running in the Cisco BTS 10200 Softswitch.

Signaling Start
Attribute
O-CMS
 
T-CMS
 
O-MGC
off-net to on-net call
T-MGC
on-net to off-net
call
 

Direction Indicator

X

X

X

X

MTA endpoint name

originating

terminating

name of endpoint (EP) in MGW

name of endpoint (EP) in MGW

Calling party number

X

X

X

X

Called party number

X

X

X

X

Routing number

X

X

X

X

Location routing number

X

X

X

X

CIC

 

 

X

X

Trunk Group ID

 

 

X

X


Signaling Stop
Attribute
O-CMS
 
T-CMS
 
O-MGC
off-net to on-net call
T-MGC
on-net to off-net
call
 

BCID of T-CMS or T-MGC

X

 

X

 

BCID of O-CMS or O-MGC

 

X

 

X

FEID of T-CMS or T-MGC

X

 

X

 

FEID of O-CMS or O-MGC

 

X

 

X


Interconnect Start
Attribute
O-CMS
 
T-CMS
 
O-MGC
off-net to on-net call
T-MGC
on-net to off-net
call
 

Routing number

 

 

X

X

CIC

 

 

X

X

Trunk Group ID

 

 

X

X


Interconnect Stop
Attribute
O-CMS
 
T-CMS
 
O-MGC
off-net to on-net call
T-MGC
on-net to off-net
call
 

CIC

 

 

X

X

Trunk Group ID

 

 

X

X


Call Answer
Attribute
O-CMS
 
T-CMS
 
O-MGC
off-net to on-net call
T-MGC
on-net to off-net
call
 

Charge Number

X

X

X

X

BCID of T-CMS or T-MGC

X

 

X

 

FEID of T-CMS or T-MGC

X

 

X

 

BCID of O-CMS or O-MGC

 

X

 

X

FEID of O-CMS or O-MGC

 

X

 

X


Call Disconnect
Attribute
O-CMS
 
T-CMS
 
O-MGC
off-net to on-net call
T-MGC
on-net to off-net
call
 

Call Termination Cause

X

X

X

X


Service Instance
Attribute
O-CMS
 
T-CMS
 
O-MGC
off-net to on-net call
T-MGC
on-net to off-net
call

 

Service Name (plus specified attributes in the table below)

X

X

 

 



Note These are the only services supported in the PacketCable 1.0 Specification. The Cisco BTS 10200 Softswitch supports many other features; however, it does not send event messages for those features to a standard RKS because the feature codes for those features have not yet been defined by PacketCable.


Service Specific Attributes
Call Forward
Call Waiting
Repeat Call
Return Call
Call Block
Three-Way Call

Related BCID

X

X

 

 

 

X

Charge Number

X

X

X

X

 

X

1st Call Calling Party #

 

X

 

 

 

 

2nd Call Calling Party #

 

X

 

 

 

 

Called Party Number

 

X

 

 

 

 

Routing Number

 

 

X

X

 

 

Calling Party Number

 

 

X

X

 

 

Termination Cause

 

 

 

 

X

 

Service Activation
Attribute
O-CMS
 
T-CMS
 
O-MGC
off-net to on-net call
T-MGC
on-net to off-net
call

 

Service Name (plus specified attributes in the table below)

X

X

 

 


Service Specific Attributes
Call Forward
Call Waiting
Call Block
Customer Originated Trace

Charge Number

X

X

X

X

Calling Party Number

X

X

X

X

Forwarded Number

X

 

 

 

Service Deactivation
Attribute
O-CMS
 
T-CMS
 
O-MGC
off-net to on-net call
T-MGC
on-net to off-net
call

 

Service Name (plus specified attributes in the table below)

X

X

 

 


Service Specific Attributes
Call Forward
Call Waiting
Call Block

Charge Number

X

X

X

Calling Party Number

X

X

X


Database Query
Attribute
O-CMS
 
T-CMS
 
O-MGC
off-net to on-net call
T-MGC
on-net to off-net
call
 

Database ID

X

X

 

 

Query Type

X

X

 

 

Called Party Number

X

X

 

 

Returned Number

X

X

 

 


Activity
Attribute
O-CMS
 
T-CMS
 
O-MGC
off-net to on-net call
T-MGC
on-net to off-net
call
 

Media Alive

X

X

X

X


Time Change
Attribute
O-CMS
 
T-CMS
 
O-MGC
off-net to on-net call
T-MGC
on-net to off-net
call
 

Time Adjustment

X

X

X

X


References

[1] IETF RFC 2748, "The COPS (Common Open Policy Service) Protocol", January 2000.

[2] PKT-SP-DQOS-I05-021127, "PacketCable Dynamic Quality of Service Specification", November 27, 2002.

[3] PKT-SP-EC-MGCP-I06-021127, "PacketCable Network-Based Call Signaling Protocol Specification", November 11, 2002.

[4] PKT-SP-TGCP-I04-021127, "PacketCable PSTN Gateway Call Signaling Protocol Specification", November 27, 2002.

[5] PKT-SP-EM-I07-030815, "PacketCable Event Message Specification", August 15, 2003.

[6] PKT-SP-SEC-I07-021127, "PacketCable Security Specification", November 27, 2002.

[7] PKT-SP-ESP-I01-991229, "PacketCable Electronic Surveillance Specification", December 29, 1999.

Related Cisco BTS 10200 Softswitch Documentation

This document should be used in conjunction with the following books in the Release 4.1 user documentation set:

Cisco BTS 10200 Softswitch Release Notes for Release 4.1

Cisco BTS 10200 Softswitch System Description

Cisco BTS 10200 Softswitch Operations, Maintenance, and Troubleshooting Guide

Cisco BTS 10200 Softswitch Provisioning Guide

Cisco BTS 10200 Softswitch Billing Interface Guide

Cisco BTS 10200 Softswitch Command Line Interface Reference Guide

Please contact your Cisco account team for the following documents:

Cisco BTS 10200 Softswitch Physical and Network Site Surveys and Data Sheets

Cisco BTS 10200 Softswitch Cabling Procedures

Cisco BTS 10200 Softswitch Application Installation Procedures

Cisco BTS 10200 Softswitch protocol compliance-matrix documents

Obtaining Documentation

Cisco provides several ways to obtain documentation, technical assistance, and other technical resources. These sections explain how to obtain technical information from Cisco Systems.

Cisco.com

You can access the most current Cisco documentation on the World Wide Web at this URL:

http://www.cisco.com/univercd/home/home.htm

You can access the Cisco website at this URL:

http://www.cisco.com

International Cisco web sites can be accessed from this URL:

http://www.cisco.com/public/countries_languages.shtml

Documentation CD-ROM

Cisco documentation and additional literature are available in a Cisco Documentation CD-ROM package, which may have shipped with your product. The Documentation CD-ROM is updated monthly and may be more current than printed documentation. The CD-ROM package is available as a single unit or through an annual subscription.

Registered Cisco.com users can order the Documentation CD-ROM (product number DOC-CONDOCCD=) through the online Subscription Store:

http://www.cisco.com/go/subscription

Ordering Documentation

You can find instructions for ordering documentation at this URL:

http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm

You can order Cisco documentation in these ways:

Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Networking Products MarketPlace:

http://www.cisco.com/en/US/partner/ordering/index.shtml

Registered Cisco.com users can order the Documentation CD-ROM (Customer Order Number DOC-CONDOCCD=) through the online Subscription Store:

http://www.cisco.com/go/subscription

Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, U.S.A.) at 408 526-7208 or, elsewhere in North America, by calling 800 553-NETS (6387).

Documentation Feedback

You can submit comments electronically on Cisco.com. On the Cisco Documentation home page, click Feedback at the top of the page.

You can e-mail your comments to bug-doc@cisco.com.

You can submit your comments by mail by using the response card behind the front cover of your document or by writing to the following address:

Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883

We appreciate your comments.

Obtaining Technical Assistance

Cisco provides Cisco.com, which includes the Cisco Technical Assistance Center (TAC) Website, as a starting point for all technical assistance. Customers and partners can obtain online documentation, troubleshooting tips, and sample configurations from the Cisco TAC website. Cisco.com registered users have complete access to the technical support resources on the Cisco TAC website, including TAC tools and utilities.

Cisco.com

Cisco.com offers a suite of interactive, networked services that let you access Cisco information, networking solutions, services, programs, and resources at any time, from anywhere in the world.

Cisco.com provides a broad range of features and services to help you with these tasks:

Streamline business processes and improve productivity

Resolve technical issues with online support

Download and test software packages

Order Cisco learning materials and merchandise

Register for online skill assessment, training, and certification programs

To obtain customized information and service, you can self-register on Cisco.com at this URL:

http://www.cisco.com

Technical Assistance Center

The Cisco TAC is available to all customers who need technical assistance with a Cisco product, technology, or solution. Two levels of support are available: the Cisco TAC website and the Cisco TAC Escalation Center. The avenue of support that you choose depends on the priority of the problem and the conditions stated in service contracts, when applicable.

We categorize Cisco TAC inquiries according to urgency:

Priority level 4 (P4)—You need information or assistance concerning Cisco product capabilities, product installation, or basic product configuration.

Priority level 3 (P3)—Your network performance is degraded. Network functionality is noticeably impaired, but most business operations continue.

Priority level 2 (P2)—Your production network is severely degraded, affecting significant aspects of business operations. No workaround is available.

Priority level 1 (P1)—Your production network is down, and a critical impact to business operations will occur if service is not restored quickly. No workaround is available.

Cisco TAC Website

You can use the Cisco TAC website to resolve P3 and P4 issues yourself, saving both cost and time. The site provides around-the-clock access to online tools, knowledge bases, and software. To access the Cisco TAC website, go to this URL:

http://www.cisco.com/tac

All customers, partners, and resellers who have a valid Cisco service contract have complete access to the technical support resources on the Cisco TAC website. Some services on the Cisco TAC website require a Cisco.com login ID and password. If you have a valid service contract but do not have a login ID or password, go to this URL to register:

http://tools.cisco.com/RPF/register/register.do

If you are a Cisco.com registered user, and you cannot resolve your technical issues by using the Cisco TAC website, you can open a case online at this URL:

http://www.cisco.com/en/US/support/index.html

If you have Internet access, we recommend that you open P3 and P4 cases through the Cisco TAC website so that you can describe the situation in your own words and attach any necessary files.

Cisco TAC Escalation Center

The Cisco TAC Escalation Center addresses priority level 1 or priority level 2 issues. These classifications are assigned when severe network degradation significantly impacts business operations. When you contact the TAC Escalation Center with a P1 or P2 problem, a Cisco TAC engineer automatically opens a case.

To obtain a directory of toll-free Cisco TAC telephone numbers for your country, go to this URL:

http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml

Before calling, please check with your network operations center to determine the level of Cisco support services to which your company is entitled: for example, SMARTnet, SMARTnet Onsite, or Network Supported Accounts (NSA). When you call the center, please have available your service agreement number and your product serial number.

Obtaining Additional Publications and Information

Information about Cisco products, technologies, and network solutions is available from various online and printed sources.

The Cisco Product Catalog describes the networking products offered by Cisco Systems as well as ordering and customer support services. Access the Cisco Product Catalog at this URL:

http://www.cisco.com/en/US/products/products_catalog_links_launch.html

Cisco Press publishes a wide range of networking publications. Cisco suggests these titles for new and experienced users: Internetworking Terms and Acronyms Dictionary, Internetworking Technology Handbook, Internetworking Troubleshooting Guide, and the Internetworking Design Guide. For current Cisco Press titles and other information, go to Cisco Press online at this URL:

http://www.ciscopress.com

Packet magazine is the Cisco monthly periodical that provides industry professionals with the latest information about the field of networking. You can access Packet magazine at this URL:

http://www.cisco.com/en/US/about/ac123/ac114/about_cisco_packet_magazine.html

iQ Magazine is the Cisco monthly periodical that provides business leaders and decision makers with the latest information about the networking industry. You can access iQ Magazine at this URL:

http://business.cisco.com/prod/tree.taf%3fasset_id=44699&public_view=true&kbns=1.html

Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in the design, development, and operation of public and private internets and intranets. You can access the Internet Protocol Journal at this URL:

http://www.cisco.com/en/US/about/ac123/ac147/about_cisco_the_internet_protocol_journal.html

Training—Cisco offers world-class networking training, with current offerings in network training listed at this URL:

http://www.cisco.com/en/US/learning/le31/learning_recommended_training_list.html