Table Of Contents
Cisco BTS 10200 Softswitch Release 4.2 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.2
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.2 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.2 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.
|
Release 4.2
|
Added new rule for IPSEC-POLICY table for source and destination identifiers.
Corrected the spelling of token name: MAX-DQOS-SESSIONS.
|
Supported Platforms
|
Cisco BTS 10200 Softswitch
|
Caution 
This document is applicable to Release 4.2 software for the Cisco BTS 10200 Softswitch. If you are running a different release of the software, use the document applicable to that release.
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.2"
–"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 application 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.2 Release Notes document.
Information About PacketCable Features for Release 4.2
One new PacketCable-based function has been introduced in the Cisco BTS 10200 Release 4.2 software—A new rule was added regarding source and destination identifiers in the IPSEC-POLICY table.
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.
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
|
|
|
|
|
|
|
|
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
|
|
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
