Guest

Cisco IOS Software Releases 12.4 Special and Early Deployments

Cisco Packet Data Serving Node (PDSN) Release 4.1 for Cisco IOS Release 12.4(15)XR7

  • Viewing Options

  • PDF (2.1 MB)
  • Feedback
Cisco Packet Data Serving Node (PDSN) Release 4.1 for Cisco IOS Release 12.4(15)XR7

Table Of Contents

Cisco Packet Data Serving Node (PDSN) Release 4.1 for Cisco IOS Release 12.4(15)XR7

Feature Overview

System Overview

How PDSN Works

Cisco PDSN Simple IP

Cisco PDSN Mobile IP

Randomized IMSI Handling

PMTU Discovery by Mobile IP Client

Cisco PDSN Proxy Mobile IP

PDSN on SAMI

Migration Steps

Features

New Features in This Release

Features From Previous Releases

PDSN Performance Metrics

Packet Data Service Access

Simple IP Based Service Access

Simple IP Routed Access

Simple IP VPDN Access

Proxy-Mobile IP Access

Mobile IP Based Service Access

Binding Update Procedures

Simple IPv6 Access

Configuring Simple IPV6

Session Redundancy Infrastructure

Functional Overview

In Process Sync Events

Handoff

Restrictions

Internals

AAA - Authentication and Authorization

AAA Accounting

AAA Accounting

New Features in This Release

Served MDN

Framed Pool

DNS Server IP

Virtual Route Forwarding (VRF) with Sub-interfaces

Configuring PDSN Session Redundancy

Configuring PDSN Session Redundancy Infrastructure

Configuring HSRP

Protocol Layering and RP Connections

Open RP Interface Connections

PPP Connections

Application Flows

PPPoGRE RP Interface

A11 Session Update

SDB Indicator Marking

Signaling of SDB Indication

Identification of Data Packets For SDB Indication

SDB Indicator Marking for PPP Control Packets

Multiple Service Connections

Session Creation—A11 Registration Request

Configuring Multiple Service Connections

Verifying the Configuration

Data Plane

QoS Signaling

Traffic Flow Templates (TFT)

Configuring TFTs

Verifying the Configuration

Subscriber QoS Policy

Configuring the Subscriber QoS Profile

Verifying the Configuration

Other QoS Parameters

Flow Remapping

Per-flow Accounting

Configuring Per-Flow Accounting

Verifying Per-Flow Accounting

Handoff Scenarios

Call Admission Control

Configuring Call Admission Control on the PDSN

Examples

Verifying the Configuration

Resource Management

Resource Revocation for Mobile IP

Packet of Disconnect

Radius Enhancements

Radius Server Load Balancing

Subscriber Authorization Based on Domain

IS-835 Prepaid Support

Prepaid Billing

Volume-based Prepaid Data Service Flow

Duration-based Prepaid Data Service Flow

Volume-based Prepaid Data Service with Tariff Switching

Support for G17 Attribute in Acct-Stop and Interim Records

Home Area, Maximum Authorized Aggregate Bandwidth and Inter-user Priority Attributes Downloaded from AAA

Configuring Subscriber Qos Profile to PCF

Configuring Bandwidth Policing

Configuring VSAs in Subscriber QoS Profiles

Verifying the Configuration

Mobile IP Call Processing Per Second Improvements

Always On Feature

PDSN MIB Enhancements

Cisco Proprietary Prepaid Billing

How Prepaid Works in PDSN

Prepaid Simple IP Call Flow

Prepaid Mobile IP Call Flow

3 DES Encryption

Mobile IP IPSec

Hardware IPSec Acceleration Using IPSec Acceleration Module—Static IPSec

Conditional Debugging Enhancements

Enhancements Prior to Release 3.0

Electronic Serial Number (ESN) in Billing

Support for Mobile Equipment Identifier (MEID)

1xEV-DO Support

Integrated Foreign Agent (FA)

AAA Support

Packet Transport for VPDN

Proxy Mobile IP

Multiple Mobile IP Flows

Redundancy and Load Balancing

PDSN Cluster Controller / Member Architecture

PDSN Controller-Member Clustering

Redundancy

Load Sharing

PDSN Cluster Member Selection

Load Balancing

Upgrading the Controller PDSN Software from R1.2 to R2.0

Upgrading the Member PDSN Software from R1.2 to R2.0 and Above

Scalability

High Availability

Related Features and Technologies

Related Documents

Supported Platforms

Supported Standards, MIBs, and RFCs

Configuration Tasks

System Requirements

Memory Requirements

Hardware Supported

Software Compatibility

Determining the Software Version

Upgrading to a New Software Release

Configuring the PDSN Image

Enabling PDSN Services

Creating the CDMA Ix Interface

Creating a Loopback Interface

Creating a Virtual Template Interface and Associating It With the PDSN Application

Enabling R-P Interface Signaling

Configuring User Session Parameters

Configuring PDSN Session Redundancy Infrastructure

Configuring AAA in the PDSN Environment

Configuring RADIUS in the PDSN Environment

Configuring Prepaid in the PDSN Environment

Enabling VPDN in a PDSN Environment

Configuring the Mobile IP FA

Configuring Proxy Mobile IP Attributes Locally

Configuring Mobile IP Security Associations

Configuring PDSN Cluster Controller

Configuring PDSN Cluster Member

Enabling Network Management

Configuring Always On Service

Configuring A11 Session Updates

Configuring SDB Indicator Marking

Configuring SDB Indicator Marking for PPP Control Packets

Configuring PoD on the PDSN

Configuring Mobile IP Resource Revocation on the PDSN

Configuring Closed-RP Interfaces

Configuring Short Data Burst Flagging

Configuring PDSN Accounting Events

Configuring CDMA RADIUS Attributes

Monitoring and Maintaining the PDSN

Configuration Examples

Cisco PDSN Configuration for Simple IP

Cisco PDSN Configuration for Simple IP with VPDN

Cisco PDSN Configuration for Mobile IP

Combined Configuration for Cisco PDSN

PDSN Cluster Configuration

Session Redundancy Configuration Examples

Simple IPV6 Configuration Example

PDSN Accounting

Flow Based Accounting

AAA Authentication and Authorization Profile

AAA Profiles for Various Service Types

Attributes

Authentication and Authorization RADIUS Attributes

Accounting Services RADIUS Attributes

Prepaid RADIUS Attributes

Mandatory AVPs in Connection Setup/Release Messages

Q.931 Cause Codes Used in Call Disconnect Notify Message

Glossary


Cisco Packet Data Serving Node (PDSN) Release 4.1 for Cisco IOS Release 12.4(15)XR7


Feature History

Release
Modification

12.4(15)XR7

Release 4.1 of the Cisco PDSN software. The following new features are introduced:

Attribute Support

Served MDN

Framed Pool

3GPP2 DNS Server IP

Virtual Route Forwarding (VRF) with Sub-interfaces support

Conditional Debugging Enhancements for Cisco PDSN Release 4.1

12.4(15)XR

Release 4.0 of the Cisco PDSN software. The following new features are introduced:

Multiple Service Connections

Data Plane

Subscriber QoS Policy (both downloading per-user profile from AAA and configuring a local profile

QoS Signaling

Traffic Flow Templates (TFT)

New Per-flow Accounting features

Call Admission Control

PDSN MIB Enhancements for PDSN Release 4.0

PDSN on SAMI

Removed Closed-RP support

12.4(15)XN

Release 3.5 of the Cisco PDSN software. The following new features are introduced:

Home Area, Maximum Authorized Aggregate Bandwidth and Inter-user Priority Attributes Downloaded from AAA

Subscriber QoS Policy

Bandwidth Policing

12.3(14)YX8

Updates to the PDSN Command Reference, including the following commands:

cdma pdsn cluster member prohibit administratively

subscriber redundancy rate

Deleted sections on ODAP and PDSN Selection Peer-to-Peer clustering.

12.3(14)YX1

Release 3.0 of the Cisco Packet Data Serving Node (PDSN) software. The following new feature is introduced:

Support for Mobile Equipment Identifier (MEID)

12.3(14)YX

Release 3.0 of the Cisco Packet Data Serving Node (PDSN) software. The following new features are introduced:

Packet Data Service Access

Simple IPv6 Access

Session Redundancy Infrastructure

Radius Server Load Balancing

PPPoGRE RP Interface (no longer supported in 4.0)

Subscriber Authorization Based on Domain

PDSN MIB Enhancements

Conditional Debugging Enhancements

12.3(11)YF3

Added support for Randomized IMSI Handling.

The following new command was added:

ip mobile cdma imsi dynamic

12.3(11)YF2

Added support for Identification of Data Packets For SDB Indication, SDB Indicator Marking for PPP Control Packets, and Support for G17 Attribute in Acct-Stop and Interim Records.

The following new commands were added or modified:

cdma pdsn a11 dormant sdb-indication match-qos-group

cdma pdsn compliance

cdma pdsn attribute send g17

12.3(11)YF1

A restriction for Registration Revocation was removed.

New commands were added, including:

cdma pdsn compliance

debug cdma pdsn prepaid

debug cdma pdsn radius disconnect nai

show cdma pdsn statistics prepaid

Existing commands were modified, including:

clear cdma pdsn session

clear cdma pdsn statistics adds RADIUS statistics

cdma pdsn mobile-advertisement-burst

ip mobile foreign-service

12.3(11)YF

Release 2.1 of the Cisco Packet Data Serving Node (PDSN) software. Four new features were added, including the Closed-RP Interface.

12.3(8)XW

Release 2.0 of the Cisco Packet Data Serving Node (PDSN) software.

12.3(4)T

This feature was integrated into Cisco IOS Release 12.3(4)T.

12.2(8)ZB8

One new CLI command was added.

12.2(8)ZB7

Six CLI commands were added or modified.

12.2(8)ZB6

Two CLI commands were added or modified.

12.2(8)ZB5

Four new CLI commands were added.

12.2(8)ZB1

This feature was introduced on the Cisco 7600 Internet Router.

12.2(8)ZB

This feature was introduced on the Cisco Catalyst 6500 Switch.

12.2(8)BY

This feature was introduced on the Cisco 7200 Series Router.


This document describes the Cisco Packet Data Serving Node (PDSN) software for use on the Cisco Service and Application Module for IP (SAMI) card that resides on the Cisco 7600 Internet Router. It includes information on the features and functions of the product, supported platforms, related documents, and configuration tasks.

This document includes the following sections:

Feature Overview

Features

Supported Platforms

Supported Standards, MIBs, and RFCs

Configuration Tasks

System Requirements

Monitoring and Maintaining the PDSN

Configuration Examples

PDSN Accounting

AAA Authentication and Authorization Profile

Attributes

Glossary

Feature Overview

A PDSN provides access to the Internet, intranets, and Wireless Application Protocol (WAP) servers for mobile stations using a Code Division Multiple Access 2000 (CDMA2000) Radio Access Network (RAN). The Cisco PDSN is a Cisco IOS software feature that runs on SAMI cards on the Cisco 7600 Internet Router, where it acts as an access gateway for Simple IP and Mobile IP stations. It provides foreign agent (FA) support and packet transport for virtual private networking (VPN). It also acts as an Authentication, Authorization, and Accounting (AAA) client.

The Cisco PDSN supports all relevant 3GPP2 standards, including those that define the overall structure of a CDMA2000 network, and the interfaces between radio components and the PDSN.

System Overview

CDMA is one of the standards for Mobile Station communication. A typical CDMA2000 network includes terminal equipment, mobile termination, base transceiver stations (BTSs), base station controllers (BSCs / PCFs), PDSNs, and other CDMA network and data network entities. The PDSN is the interface between a BSC / PCF and a network router.

Figure 1 illustrates the relationship of the components of a typical CDMA2000 network, including a PDSN. In this illustration, a roaming mobile station user is receiving data services from a visited access provider network, rather than from the mobile station user's subscribed access provider network.

Figure 1 The CDMA Network

As the illustration shows, the mobile station, which must support either Simple IP or Mobile IP, connects to a radio tower and BTS. The BTS connects to a BSC, which contains a component called the Packet Control Function (PCF). The PCF communicates with the Cisco PDSN through an A10/A11 interface. The A10 interface is for user data and the A11 interface is for control messages. This interface is also known as the RAN-to-PDSN (R-P) interface. Figure 2 illustrates the communication between the RAN and the Cisco PDSN.

Figure 2 RAN-to-PDSN Connection: the R-P Interface

The IP networking between the PDSN and external data networks is through the PDSN-to-intranet/Internet (Pi) interface. For the Cisco PDSN Release 2.0 and above, you can use either an FE or GE interface as the Pi interface.

For "back office" connectivity, such as connections to a AAA server, or to a RADIUS server, the interface is media independent. Any of the interfaces supported on the Cisco 7206 can be used to connect to these types of services; however, Cisco recommends that you use either an FE or GE interface.

How PDSN Works

When a mobile station makes a data service call, it establishes a Point-to-Point Protocol (PPP) link with the Cisco PDSN. The Cisco PDSN authenticates the mobile station by communicating with the AAA server. The AAA server verifies that the user is a valid subscriber, determines available services, and tracks usage for billing.

The method used to assign an IP address and the nature of the connection depends on service type and network configuration. Simple IP operation and Mobile IP operation are referred to as service types. The service type available to a user is determined by the mobile station, and by the type of service that the service provider offers. In the context of PDSN, a mobile station is the end user in both Simple IP and Mobile IP operation.

Once the mobile station is authenticated, it requests an IP address. Simple IP stations communicate the request using the Internet Protocol Control Protocol (IPCP). Mobile IP stations communicate the request using Mobile IP registrations.

The following sections describe the IP addressing and communication levels for each respective topic:

Cisco PDSN Simple IP

Cisco PDSN Mobile IP

PMTU Discovery by Mobile IP Client

Cisco PDSN Simple IP

With Simple IP, a service provider's Cisco PDSN assigns a dynamic or static IP address to the mobile station during the PPP link setup. The mobile station retains this IP address as long as it is served by a radio network that has connectivity to the address-assigning PDSN.

Therefore, as long as the mobile station remains within an area of RANs that is served by the same PDSN, the MS can move or roam inside the coverage area and maintain the same PPP links. If the mobile station moves outside the coverage area of the given PDSN, the mobile station is assigned a new IP address, and any application-level connections are terminated.


Note A static IP address can be requested by the mobile station, and will be assigned if the address is within the pool of addresses and is available. Also an IP address can be statically specified in the AAA profile of the user using the "Framed-IP-Address" attribute.


Figure 3 illustrates the placement of the Cisco PDSN in a Simple IP scenario.

Figure 3 CDMA Network - Simple IP Scenario

Cisco PDSN Simple IP with VPDN Scenario

A Virtual Private Data Network (VPDN) allows a private network dial-in service to span to remote access servers called Network Access Servers (NAS). Figure 4 illustrates a VPDN connection in the PDSN environment with Simple IP. In this scenario, the PDSN is acting as the NAS.

Figure 4 CDMA Network —Simple IP with VPDN Scenario

A VPDN connection is established in the following order:

1. A PPP peer (mobile station) connects with the local NAS (the Cisco PDSN).

2. The NAS begins authentication when the client dials in. The NAS determines that the PPP link should be forwarded to a tunnel server for the client. The location of the tunnel server is provided as part of the authentication by the Remote Authentication Dial-in User Service (RADIUS) server.

3. The tunnel server performs its own authentication of the user and starts the PPP negotiation. It performs authentication for both the tunnel setup and the client.

The PPP client is forwarded through a Layer 2 Tunneling Protocol (L2TP) tunnel over User Datagram Protocol (UDP).

4. The PPP setup is completed and all frames exchanged between the client and tunnel server are sent through the NAS. The protocols running within PPP are transparent to the NAS.

Cisco PDSN Mobile IP

With Mobile IP, the mobile station can roam beyond the coverage area of a given PDSN and still maintain the same IP address and application-level connections.

Figure 5 shows the placement of the Cisco PDSN in a Mobile IP scenario.

Figure 5 CDMA Network —Mobile IP Scenario

The communication process occurs in the following order:

1. The mobile station registers with its Home Agent (HA) through an FA; in this case, the Cisco PDSN.

2. The HA accepts the registration, assigns an IP address to the mobile station, and creates a tunnel to the FA. This results in a PPP link between the mobile station and the FA (or PDSN), and an IP-in-IP or Generic Routing Encapsulation (GRE) tunnel between the FA and the HA.

As part of the registration process, the HA creates a binding table entry to associate the mobile station's home address with its Care-of address.


Note While away from home, the mobile station is associated with a care-of address. This address identifies the mobile station's current, topological point of attachment to the Internet, and is used to route packets to the mobile station. In IS-835-B networks, the foreign agent's address is always used as the Care-of address.


3. The HA advertises that the network is reachable to the mobile station, and tunnels datagrams to the mobile station at its current location.

4. The mobile station sends packets with its home address as the source IP address.

5. Packets destined for the mobile station go through the HA; the HA tunnels them through the PDSN to the mobile station using the care-of address.

6. When the PPP link is handed off to a new PDSN, the link is re-negotiated and the Mobile IP registration is renewed.

7. The HA updates its binding table with the new care-of address.


Note For more information about Mobile IP, refer to the Cisco IOS Release 12.2 documentation modules Cisco IOS IP Configuration Guide and Cisco IOS IP Command Reference. RFC2002 describes the specification in detail. TIA/EIA/IS-835-B also defines how Mobile IP is implemented for PDSN.


Randomized IMSI Handling

The PDSN cannot recognize 1xRTT to EVDO as a handoff due to a change of IMSI. The result is that the "cdma-reason-ind" in the account stop message will not reflect the same.

By default, the PDSN keeps the first call session if the Mobile does a static home address. In this release, the PDSN supports deleting the first call session for dynamic home address cases (for example, 1x-RTT to EVDO handoff where the IMSI changes during the handoff).

The old call scenario is established as follows:

1. Mobile Node with IMSI = imsi1, NAI = nai1 establishes session.

2. When PDSN receives an RRQ from the same mobile node with the same NAI but with different IMSI (with IMSI = imsi2, NAI = nai1), currently a new session does not come up on the PDSN, and old session remains.

3. During the mobile handoff between 1XRTT and EVDO call, handoff will not succeed due to the above behavior of PDSN.

With the ip mobile cdma imsi dynamic command, the PDSN releases the old session and allows the new session to come up. In Cisco PDSN 12.4(15)XR7 release, the CLI command ip mobile cdma imsi dynamic is enabled by default. This CLI command will be obsoleted in future releases, and the functionality of this CLI command will be the default behavior on PDSN.

PMTU Discovery by Mobile IP Client

FTP upload and ping from the end node may fail when PMTU Discovery (done by setting the DF bit) is done by a MobileIP client (an end node) for packet sizes of about 1480. Due to failure of PMTUD algorithm, the IP sender will never learn the smaller path MTU, but will continue unsuccessfully to retransmit the too-large packet, until the retransmissions time out.

Please refer to http://www.cisco.com/warp/public/105/38.shtml#2000XP for disabling PMTUD for Windows 2000/XP platforms.

Cisco PDSN Proxy Mobile IP

Currently, there is a lack of commercially-available Mobile IP client software. Conversely, PPP, which is widely used to connect to an Internet Service Provider (ISP), is ubiquitous in IP devices. As an alternative to Mobile IP, you can use Cisco's proxy Mobile IP feature. This capability of the Cisco PDSN, which is integrated with PPP, enables a Mobile IP FA to provide mobility to authenticated PPP users.


Note In Proxy Mobile IP, the MS can have only one IP flow per PPP Session.


The communication process occurs in the following order:

1. The Cisco PDSN (acting as an FA) collects and sends mobile station authentication information to the AAA server.

2. If the mobile station is successfully authenticated to use Cisco PDSN Proxy Mobile IP service, the AAA server returns the registration data and an HA address.

3. The FA uses this information, and other data, to generate a Registration Request (RRQ) on behalf of the mobile station, and sends it to the HA.

4. If the registration is successful, the HA sends a registration reply (RRP) that contains an IP address to the FA.

5. The FA assigns the IP address (received in the RRP) to the mobile station, using IPCP.

6. A tunnel is established between the HA and the FA/PDSN. The tunnel carries traffic to and from the mobile station.

PDSN on SAMI

The SAMI blade supports the feature set of PDSN Release 4.1, and a Cisco 7600 chassis will support a maximum of 6 application modules. Each application module has 6 PPCs, each with 2 Gigabytes of RAM, and uses one instance of a Cisco IOS software application image. Each PPC can function as a PDSN.

Additionally, instances of the cluster controller functionality will be configured as required. One active and one standby controller are required for a cluster of 48 PDSN instances or less. Each PDSN image supports 25,000 user sessions. For every 10 PDSNs configured in the chassis, one active and one standby controller is required. Internal to the chassis, the PDSN images are configured on the same VLAN in order to support the Controller-Member architecture (although the architecture itself does not require this). Load balancing external to the chassis is determined by the physical proximity of the chassis and the network architecture. It is possible that you require both a VLAN approach, and a more traditional routed approach.

Migration Scenarios

The following table lists currently available or planned PDSN Releases and the migration path to the SAMI platform:

Table 1 Migration Path for Cisco PDSN 

 
PDSN R3.0 or older
PDSN R3.5
PDSN R4.0
Platform

7200 NPE400/NPE-G1 and MWAM Platform (5 Processor only)

MWAM (5 Processor only)

Service Application Module for IP - SAMI

Chassis/Power Supply, Fan Trays)

7200VXR

6500/7600 Chassis

7600 Chassis

   

SUP2/SUP720/

SUP720/RSP720/SUP 32

   

SUP32SUP IOS SX based

SUP IOS - SRC based image (for example: c7600s72033-advipservicesk9-mz.122-33.SRC.bin)

   

SUP-redundancy

SUP-redundancy


Based on Table 2, there are many possible migration scenarios. In this section, we focus on those scenarios closest to current customer deployments. The actual migration path has to be determined per-customer end-to-end deployment. Additionally, migration should be engineered, and we recommend that you perform the migration in a maintenance window.

Customers may take this opportunity to redesign their network, for example, redesigning IP addresses scheme and configuring the routing protocols, network connectivity between PDSN and Home Agent, applicationXR7connectivity between PDSN and AAA servers, routing on the new SAMI PDSN / Home Agent, and so on.

Table 2 lists the most common migration scenarios:

Table 2 Migrations Scenarios for PDSN 4.0 

Scenario
Migration From
To
Remarks

1

Non-SR,

Non- Clustering,

1- 7200VXR/NPE-G1 running PDSN

Non-SR,

Non- Clustering,

7600 Chassis,

One SUP720/SAMI (< 6 PPC ) running PDSN

Downtime: Yes

Other Comments: significant network provisioning changes in terms of,

Platform change

Configuration related to Platform (HW)

Configuration related to PDSN (SW) provisioning (For example, Creation of Sub interfaces, VLAN, PCF secure configs and so on).

Configuration migration from 7200 to SAMI Processor

Note The majority of the basic configuration tasks related to the CDMA component remains the same, unless you are planning to introduce additional features that are not enabled prior to migration.

2

Non-SR,

Non- Clustering,

Multiple 7200VXR/NPE-G1 running PDSN

Non-SR,

Non-Clustering ,

7600 Chassis,

One SUP720/SAMI (all 6 PPC ) running PDSN

Downtime: Yes

Other Comments:

Significant network provisioning change in terms of,

Platform change

New configuration related to Platform (SUP /SAMI ) - (HW)

New configuration related to PDSN (SW) provisioning (For example, Creation of Sub interfaces, VLAN, PCF secure configs and so on).

Configuration migration from 7200 to SAMI Processor

Note The majority of the basic configuration tasks related to the CDMA component remains the same, unless you are planning to introduce additional features that are not enabled prior to migration.

3

Non-SR ,

Non-Clustering

IPsec enabled between 7200 based PDSN and HA

Two-7200VXR/NPE-G1 running PDSN

SR enabled,

Non-Clustering

7600 Chassis,

SUP720 blade with redundancy

IOS based IPsec feature enabling

Two SAMI blades (Single chassis)

Downtime: Yes

Other Comments:

Significant network provisioning change in terms of,

Platform change

New Configuration related to Platform (SUP/SAMI) - (HW)

Crypto configuration to be done at Supervisor instead of PDSN processors. IPSec tunnel to be established between 7600 chassis running PDSN and HA application, instead of terminating the IPsec tunnels in PDSN/HA application itself (like that of 7200 platform).

New configuration related to PDSN (SW) provisioning (for example, creation of sub interfaces, VLAN, PCF secure configurations, and so on.).

Configuration migration from 7200 to SAMI processor

Note The majority of the basic configuration tasks related to the CDMA component remains the same, unless you are planning to introduce additional features that are not enabled prior to migration.

4

SR enabled,

Non-Clustering

7600/Redundant SUP2

Redundant MWAM blades (single chassis)

SR enabled,

Non-Clustering

7600/Redundant SUP 720

Redundant SAMI blades (single chassis)

Downtime: Yes

Other Comments:

Minimal changes in terms of HW:

Upgrading platform (SUP 2 to SUP 720) - requires chassis reset.

New configuration related to SAMI Platform (HW) to be enabled in SUP.

Configuration migration from MWAM processor to SAMI processor

Note The majority of the basic configuration tasks related to the CDMA component remains the same, unless you are planning to introduce additional features that are not enabled prior to migration.

5

SR enabled,

Non-Clustering

7600/Redundant SUP 720

Redundant MWAM blades(single chassis)

SUP IOS SXF

SR enabled,

Non-Clustering

7600/Redundant SUP 720

Redundant SAMI blades(single chassis)

SUP IOS SRC

Downtime: Yes

Other Comments:

Minimal Changes in terms of HW:

Upgrading the SUP Image (SXF to SRC) requires chassis reset.

New configuration related to SAMI Platform (HW) to be enabled in SUP.

Configuration migration from MWAM processor to SAMI processor.

Note The majority of the basic configuration tasks related to the CDMA component remains the same, unless you are planning to introduce additional features that are not enabled prior to migration.

6

SR enabled,

Non-Clustering

7600/Redundant SUP 720

Redundant MWAM blades (single chassis)

SUP IOS SXF

SR enabled,

Clustering enabled,

7600/Redundant SUP 720

Redundant SAMI blades (single chassis)

SUP IOS SRC

Downtime: Yes

Other Comments:

Minimal Changes in terms of HW:

Upgrading the SUP Image (SXF to SRC) requires chassis reset.

New configuration related to SAMI Platform (HW) is enabled in SUP.

Configuration migration from MWAM processor to SAMI processor.

Provisioning of clustering setup requires introduction of clustering related configurations in PDSN processor, configuration of Controller, and configuration changes on the PCF side.

Note We recommend that you allow the controller and member operate in different subnets.

Note The majority of the basic configuration tasks related to the CDMA component remains the same, unless you are planning to introduce additional features that are not enabled prior to migration.

7

SR enabled,

Clustering enabled,

7600/Redundant SUP 720

Redundant MWAM blades (single chassis)

SUP IOS SXF

SR enabled,

Clustering enabled,

7600/Redundant SUP 720

Redundant SAMI blades (dual chassis)

SUP IOS SRC

Downtime: Yes

Other Comments:

Significant changes in terms of HW:

Upgrading the SUP image (SXF to SRC) requires chassis reset.

Introduction of redundant chassis.

Provisioning the SUP configuration to operate in Inter- chassis redundancy environment.

New configuration related to SAMI platform (HW) is enabled in SUP.

Configuration migration from MWAM processor to SAMI processor.

Provisioning of clustering setup requires introducing clustering related configurations in the PDSN processor, configuration of controller, and configuration changes on the PCF side.

Note The majority of the basic configuration tasks related to the CDMA component remains the same, unless you are planning to introduce additional features that are not enabled prior to migration.


For all of these migration plans, both hardware and software configurations have significant changes. This requires prudent operation planning and network redesign. The Migration Steps section describes the possible migration steps to minimize both network reconfiguration and service disruption.

Migration Steps

Migration to the Cisco PDSN R4.0 image is more than replacing MWAM modules with SAMI modules. Your migration should be well planned and conducted in a way that has minimal impact on the existing mobile subscriber's service connections.

Here are the migration tasks that are based on the scenarios that were previously established in Table 2.

Table 3 Migration Steps from PDSN 3.x to 4.0

Scenario
Migration Steps

1 , 2

Install and configure PDSN on 7600/SUP720 (SRC based) with the SAMI.

Provision MS and PCFs to use the newly added SAMI-based PDSN (this may be a very large task).

Provision newly added PDSN with that of Home-agent to service Mobile IP calls. Also, modify the security association between PDSN and PCF's, PDSN and HA accordingly.

To minimize provisioning tasks, the SAMI PDSN instances can reuse the 7200 NPE-G1 based PDSN IP addresses and routing schemes (presuming this is done in a maintenance window, and that service will be disrupted).

3

Install and configure the PDSN on 7600/SUP720 (SRC based) with the SAMI, and put them in the same HSRP redundancy group as configured on the Cisco 7200-based PDSN (R3.0 release). At this stage, the Cisco 7200-based PDSN will act as the active PDSN and the SAMI-based PDSN will assume the role of standby.

Ensure in the newly introduced SAMI based PDSN, that R3.5 or R4.0 features are not enabled. Also ensure that the features enabled on the SAMI PDSN are same as that of the features already enabled in 7200-based PDSN. However, the IPsec feature enabled onthe 7200 PDSN must be disabled on a SAMI-based PDSN. Instead, the IPsec configuration will be moved to the 7600 Supervisor configuration, and the IPsec tunnel will be established between the chassis. Once the packet is taken out of the IPsec tunnel in the supervisor, the same is sent to the PDSN instances through the backplane.

Configure higher priority and HSRP preemption (with delay) on the SAMI-based PDSN.

Let the SAMI PDSN takes over the active role.

Bring down the Cisco 7200s and introduce another SAMI card (SAMI card 2) in the same chassis, and configure the redundancy. Let the SAMI card 2, takes over the role of standby PDSN.

Customers usually prefer to reconfigure their network in a maintenance window, so we continue to recommend the same for this configuration change as well. However, the above mentioned step does not need to be performed in a maintenance window.

However, introduction of new features (such as R4.0) should be done during a maintenance window.

4

Install and configure PDSN on 7600/SUP720 (SRC based) with SAMI and put them in the same HSRP redundancy group as configured on MWAM-based PDSN (R3.0 release). At this stage, the MWAM PDSN instances will act as the active PDSN and the SAMI-based PDSN will assume the role of standby.

Note The SAMI card can be configured for 6 instances of PDSN, whereas the MWAM will have only 5 instances. Customers can efficiently provision the network and distribute the load across 6 PDSN instances (instead of 5) during the upgrade process.

Configure SUP720 to support SAMI.

Make sure MWAM configurations are saved on SUP720 bootflash.

Configure the VLAN for SAMI VLAN groups on SUP720 as MWAM.

Build SAMI PPC configuration from MWAM processors configurations according to SAMI configuration file name convention in SUP720 bootflash.

Power down the standby MWAM and pull it out of the chassis.

Insert the SAMI in the same slot and boot it with the proper PDSN R4.0 image.

Verify SAMI PPC gets the proper PDSN configurations.

Ensure, the newly introduced SAMI-based PDSN does not enable any of the R3.5 or R4.0 features. Also ensure that the features enabled on the SAMI PDSN are the same as that of the features already enabled on the MWAM-based PDSN.

Configure higher priority and HSRP preemption (with delay) on SAMI based PDSN.

Let the SAMI PDSN takes over active role.

Bring down the standby MWAM and introduce another SAMI card (SAMI card 2) in the same chassis, and configure the redundancy. Let the SAMI card 2, takes over the role of standby PDSN.

Customers usually prefer to reconfigure their network in a maintenance window, so we continue to recommend the same for this configuration change as well. However, the above mentioned step does not need to be performed in a maintenance window.

However, introducing new features (such as R4.0) should be done during a maintenance window.

5

For a single chassis, changing from SUP720 SXF to SUP720 SRB resets the entire chassis. The whole chassis is reset so all service modules such as MWAM and SAMI will be reset, too. Same is the case for Sup2 to Sup 720 or Sup 32 or RSP 720 migration.

This should be performed in a maintenance window.

User service will be disrupted.

For MWAM to SAMI PDSN migration, follow the steps given in Scenario 4.

6

Since the SAMI blade does not support Inter-PPC communication on a same Vlan , the existing cluster-member architecture model of the PDSN on a single MWAM blade requires few configuration changes during provisioning using the SAMI platform (out of 5 processors in the MWAM, 1 is used as controller and rest of the processors are used as a PDSN member).You need to use the ip-address from different subnet on the controller and member interface, and enable explicit routing through the supervisor in order for them to communicate with each other.

Note This would call for additional configuration (i.e., change in Cluster controller IP address in PCF, routing, and so on.) on the PCF side as well.

Additionally, the cluster related configuration has to be newly introduced in PDSN member in order for the member to participate in a cluster environment.

The remaining migration steps are similar to Scenario 4 and 5.

The above migration must be performed in maintenance window.

7

The migration steps are very similar to scenario 5.

Note It is not recommended to have MWAM (R3.0 image) and SAMI PDSN (R4.0 image) members participating in same cluster controller based on R3.0 image, the reason being,

Handling of Rev. A calls: we need to enable the CLI to support multiple flows which cannot be done in R3.0 based controller.

Additionally, having a SAMI and an MWAM PDSN participating in a single controller might end up re-directing / suggesting MWAM R3.0 PDSN IP address for a Rev. A call.


Features

New Features in This Release

This section lists the features of the Cisco 4.1 PDSN Release:

Attribute Support

Served MDN

Framed Pool

3GPP2 DNS Server IP

Virtual Route Forwarding (VRF) with Sub-interfaces support

Conditional Debugging Enhancements for Cisco PDSN Release 4.1

Features From Previous Releases

This section lists features that were introduced prior to Cisco PDSN Release 4.1:

Multiple Service Connections

Data Plane

Subscriber QoS Policy (both downloading per-user profile from AAA and configuring a local profile

QoS Signaling

Traffic Flow Templates (TFT)

New Per-flow Accounting features

Call Admission Control

PDSN MIB Enhancements for PDSN Release 4.0

PDSN on SAMI

Removed Closed-RP support

Inter-User Priority

Inter-user priority attribute is used by the PCF to schedule packets to the mobile node. This attribute is received by the PDSN from AAA in a RADIUS access-accept message.

Roamer Identification

This Home Area attribute is defined by Lucent, and is received by the PDSN from AAA in a RADIUS access-accept message.

Bandwidth Policing

The PDSN polices downstream traffic towards the mobile node based on the "maximum authorized aggregate bandwidth" 3GPP2 attribute, downloaded from AAA.

Packet Data Service Access

Simple IPv6 Access

Session Redundancy Infrastructure

Radius Server Load Balancing

Subscriber Authorization Based on Domain

PDSN MIB Enhancements

PPP Counters in Release 3.0

RP Counters in Release 3.0

Conditional Debugging Enhancements

Trace Functionality in Release 3.0

Randomized IMSI Handling

Protocol Layering and RP Connections

PPPoGRE RP Interface

A11 Session Update

SDB Indicator Marking

Resource Revocation for Mobile IP

Packet of Disconnect

IS-835 Prepaid Support

Prepaid Billing

Mobile IP Call Processing Per Second Improvements

Always On Feature

PDSN MIB Enhancements

Conditional Debugging Enhancements

Cisco Proprietary Prepaid Billing

3 DES Encryption

Mobile IP IPSec

Hardware IPSec Acceleration Using IPSec Acceleration Module—Static IPSec

1xEV-DO Support

Integrated Foreign Agent (FA)

AAA Support

Packet Transport for VPDN

Proxy Mobile IP

Multiple Mobile IP Flows

PDSN Cluster Controller / Member Architecture


Note The Cisco PDSN software offers several feature options which are available on different images. Some features are image-specific, and are not available on all images. The PDSN Feature Matrix in Table 4 lists the available images for the PDSN, and identifies the features available on each image.



Note The Cisco PDSN 3.5 Release is only supported on the Cisco MWAM card on the Cisco 7600 or Cisco 6500 Series router platform. The features listed in the PDSN Feature Matrix reflect features that are still supported from previous releases.



Note Closed-RP clustering is not supported on PDSN Release 4.0.


Table 4 PDSN Feature Matrix 

Feature Name
c7svcsami-c6ik9s-mz

Session Redundancy

X

Simple IPv6

X(P)

Resource Revocation Per User

X

Trace Functionality

X

Radius server load balancing

X

Selection of RADIUS Server Based On Realm

X

PPPoGRE RP Interface

X(P)

A11 Session Update

X

SDB Indicator Marking

X

Packet of Disconnect

X

Resource Revocation

X

Always On Feature

X

NPE-G1 Platform Support

 

PDSN MIB Enhancements

X

Conditional Debugging

X

10000 Sessions

 

25000 Sessions

X

RevA Support

X

Prepaid Billing (IS-835-C)

X(P)

PDSN Controller / Member Clustering

X

1xEV-DO Support

X

ESN in Billing

X

3DES Encryption

X*

PPP Optimization

X


P indicates that this feature is only available with a Premium license.

* Requires appropriate hardware support.


Note If you require higher performance values for PDSN selection, use the c6is-mz images; these images contain the PDSN controller-member cluster feature for PDSN selection.


PDSN Performance Metrics

Cisco PDSN Release 4.x and above delivers the following performance improvements compared to Release 3.0 and R3.5 :

Significant improvement in 1XRTT Call setup rates

Performance Metrics on the Cisco 7600 series platform are as follows. The quoted figures are per image, and each SAMI can support 6 PDSN images.

25000 users sessions

Maximum call setup rate for Simple IP and Mobile IP sessions for a standalone PDSN

Throughput on the R-P interface for non-fragmented packets of size 64, 350,512 and 1472 bytes

Throughput on the R-P interface for fragmented packets of size 64,350,512 and 1472 bytes with fragmentation of 25 bytes

Call set up rate for a stand-alone PDSN for Simple IP and Mobile IP Sessions

Packet Data Service Access

The PDSN supports two types of service accesses. The type of service access for a mobile session is determined by the capabilities of the mobile station:

Simple IP based service access

Mobile IP based service access

Simple IP Based Service Access

The PDSN facilitates a mobile user to access the internet and corporate intranet by using Simple IP based service access. Simple IP mode of access, however, limits user mobility to the coverage area of the serving PDSN. Inter-PDSN handoff causes re-negotiation of PPP between the mobile station and the new PDSN. The old IP address assigned at the previous PDSN can usually not be assigned to the mobile user from the new PDSN, and results in reset and restart of user applications.

Some of the salient features for Simple IP based service access include:

Support for static IP Addresses

Public IP addresses

Private IP addresses, (for example, for VPDN service)

Support for dynamic IP Addresses

Support for PPP PAP/CHAP authentication

Support for MSID based service access

Support for packet data accounting per TIA/EIA/IS-835-B

Support for packet filtering

Ingress address filtering

Input access lists

Output access lists

User NAI is available during the PPP CHAP/PAP authenticating phase. Domain name information in the NAI determines the domain responsible for user authentication. Based on the type of packet routing model, Simple IP based service access can be categorized as follows.

Simple IP Routed Access

Simple IP VPDN Access

Proxy-Mobile IP services

Simple IP Routed Access

After receiving username and password during PPP LCP negotiations, the PDSN forwards authentication information to the local AAA server via an access request message. This, in turn, may be proxied to the AAA server in the user's home domain, via broker AAA servers, if necessary. On successful authentication, the user is authorized services based on its service profile. User Class/CDMA_IPTECH information, along with other authorization parameters are returned to the PDSN using an access accept message from the home AAA. On successful negotiation of an IP address, Simple IP based services are made available to the mobile user.

Simple IP routed access method is applicable for users that are not configured for VPDN or proxy-Mobile IP services. With PPP terminated at the PDSN, uplink user traffic is routed towards the IP network from the PDSN. The address assigned to the mobile user would be from within the PDSN routable domain. Private addresses may also be used if a NAT is configured. User mobility is limited to the PDSN coverage area. Inter-PCF handoffs do not disrupt service. Inter-PDSN handoffs, however, result in PPP renegotiation at the new PDSN, another IP address being assigned at the new PDSN, and reset and restart of user applications.

Simple IP VPDN Access

After receiving username and password during PPP LCP negotiations, the PDSN forwards authentication information to the local AAA server via an access request message. This, in turn, may be proxied to the AAA server in the user's home domain, via broker AAA servers, if necessary. On successful authentication, the user is authorized services based on user's service profile. If the user is configured for VPDN based access services, User Class information, along with other authorization parameters including tunneling options and tunneling parameters, are returned to the PDSN via an access accept message from the home AAA. The following types of VPDN services are supported at the PDSN:

L2TP - Layer 2 Tunneling Protocol

For L2TP type layer2 tunneling, the PDSN establishes an L2TP tunnel with the tunneling endpoints specified by the tunneling parameters. The L2TP tunnel would be established between the LAC at the PDSN and LNS at the NAS in user's home domain. The PPP connection would be between the mobile station and the LNS in the home network. Despite the PPP connection termination at the LNS, the PDSN monitors the PPP session for inactivity. Status of the PPP connection is also linked with the state of the underlying A10 connection. PPP connection is deleted when the underlying A10 connection is deleted. IPSec encryption methods can also be enabled over the L2TP tunnels for enhanced security.

On successful negotiation of an IP address between the mobile and the LNS, IP-based services are made available to the mobile.

The LNS may be configured to authenticate the mobile user based on the challenge and challenge response information from the PDSN. Additionally, the LNS may also be configured to challenge the user again after the layer2 tunnel has been established. The following authentication options are supported for L2TP:

L2TP With Proxy-Authentication

The LAC (PDSN) challenges the mobile user and forwards authentication related information to the LNS as part of tunnel setup parameters. The LNS may be configured to authenticate the user either locally or via the home AAA, based on the authentication related information from the LAC (PDSN). On successful authentication, the mobile and the LNS proceed with the IPCP phase and negotiate an IP address for the user session.

L2TP With Dual Authentication

The LAC (PDSN) challenges the mobile and forwards authentication related information to the LNS as part of tunnel setup parameters. The LNS may be configured to authenticate the user either locally or via the home AAA, based on the authentication related information from the LAC (PDSN). On successful authentication, the LNS challenges the mobile again. After successful authentication, the LNS and the mobile proceed with IPCP phase and negotiate the IP address for the user session.

Proxy-Mobile IP Access

After receiving username and password during PPP LCP negotiations, the PDSN forwards authentication information to the local AAA server via an access request message. This, in turn, may be proxied to the AAA server in the user's home domain, using broker AAA servers, if necessary. On successful authentication, the user is authorized services based on its service profile. User Class information, along with other authorization parameters are returned to the PDSN via an access reply from the home AAA.

If the user is configured for proxy-Mobile IP based access, authorization parameters from the home AAA include the Home Agent (HA) address, and the security parameter (SPI) to be used for computing the MN-HA Authentication extension for the mobile station. The Home Agent is allocated from the list of Home Agents configured at the home AAA server. Round robin or hashing algorithms based on user NAI can be used for allocating a Home Agent at the AAA. Other authorization attributes returned from the AAA include MN-AAA authenticating extension as defined in RFC 3012. Based on this information, the PDSN performs proxy-Mobile IP procedures on behalf of the mobile user by sending a Mobile IP Registration Request message to the allocated HA. On successful authentication of the mobile with the AAA, and registration at the Home Agent, the Home Agent assigns a home address for this mobile user This address is returned to the mobile during IPCP IP address negotiation phase.

On successful negotiation of an IP address, proxy-Mobile IP based services are made available to the mobile user. To the mobile, these services are no different from Simple IP services with tunneling being done via the Home Agent. This feature, however, extends the coverage area of the call beyond coverage area of the serving PDSN. If, as a result of a handoff event, another PDSN is allocated to the call, the target PDSN performs Mobile IP registration with the Home Agent thereby ensuring that the same home address is allocated to the mobile.

Mobile IP Based Service Access

The PDSN allows a mobile station with Mobile IP client function, to access the internet and corporate intranet using Mobile IP based service access. With this mode of service access, user mobility is extended beyond the coverage area of currently serving PDSN. Resulting from a handoff, if another PDSN is allocated to the call, the target PDSN performs Mobile IP registration with the Home Agent thereby ensuring that the same home address is allocated to the mobile.

Some of the salient features for Mobile IP services access include:

Support for static IP Addresses

Public IP addresses

Private IP addresses

Support for dynamic IP Addresses

Public IP addresses

Private IP addresses

Multiple Mobile IP user flows over a single PPP connection

Multiple flows for different NAIs using static or dynamic addresses

Multiple flows for the same NAI using different static addresses

Foreign Agent Challenge procedures in RFC 3012

Mobile IP Agent Advertisement Challenge Extension

MN-FA Challenge Extension

MN-AAA Authentication Extension

Mobile IP Extensions specified in RFC 2002

MN-HA Authentication Extension

MN-FA Authentication Extension

FA-HA Authentication Extension

Mobile IP Extensions specified in RFC 3220

Authentication requiring the use of SPI.

Mobile NAI Extension, RFC 2794

Reverse Tunneling, RFC 2344

Multiple tunneling Modes between FA and HA

IP-in-IP Encapsulation, RFC 2003

Generic Route Encapsulation, RFC 2784

Support for PPP PAP/CHAP authentication

Support for MSID based service access

Binding Update message for managing zombie PPP connections

Flow based packet data accounting per TIA/EIA/IS-835-B

Support for Packet Filtering

Ingress address filtering

Input access lists

Output access lists

A Mobile IP capable mobile client may be configured to skip PAP/CHAP based authentication during the PPP LCP phase. Once the PPP is established, the PDSN sends a burst of Mobile IP Agent Advertisement messages that include the Mobile IP Agent Advertisement Challenge extension specified in RFC 3012. The number and timing of the burst is configurable. The mobile user responds with a Mobile IP Registration Request message that includes the mobile user's NAI and MN-FA Challenge extension in response to the challenge in the Agent Advertisement message. If the mobile user does not respond to the initial burst, advertisements can be solicited.

The Foreign Agent function at the PDSN can be configured to authenticate the mobile user by forwarding an access request message to the local AAA server. The local AAA server would proxy the message to the home AAA server, via broker AAA server(s), if necessary. On successful authentication, the home AAA may assign a Home Agent to the call and return its address in the access reply message. Other authorization parameters in the access-reply message include the SPI and IPSec shared key to be used between the FA and the HA. The PDSN/FA and Home Agent establish a secure IPSec tunnel, if required, and the PDSN/FA forwards the Registration Request message to the Home Agent. The Registration Request message includes the NAI and MN-FA-Challenge Extension also. It may also include MN-AAA Authentication extension.

The Home Agent can be configured to authenticate the mobile again with the home AAA. On successful authentication and registration, the Home Agent responds with a Registration Reply message to the PDSN/FA, which is forwarded to the mobile station. The Registration Reply message contains the home address also (static or dynamically assigned) for the user session.

Potential home addresses are available to the PDSN from the following:

Mobile IP Registration Request received from the Mobile Node

FA-CHAP response received from the HAAA

Mobile IP Registration Reply received from the Home Agent

The mobile may be configured to perform PPP PAP/CHAP authentication in addition to performing Foreign Agent Challenge based authentication specified in RFC 3012. In this case the PDSN would support one Simple IP flow, in addition to one or more Mobile IP flows.

For Mobile IP services, the Home Agent would typically be located within an ISP network or within a corporate domain. However, many of the ISPs and/or corporate entities may not be ready to provision Home Agents by the time service providers begin rollout of third-generation packet data services. Access service providers could mitigate this situation by provisioning Home Agents within their own domain, and then forward packets to ISPs or corporate domains via VPDN services.

Binding Update Procedures

When a mobile first registers for packet data services, a PPP session and associated Mobile IP flow(s) are established at the PDSN. In the event of an inter-PDSN handoff, another PPP session is established at the target PDSN, and the mobile registers with the Home Agent via the new PDSN/FA. The Visitor list binding and the PPP session at the previous PDSN are, however, not released until the PPP inactivity timer expires.

Idle/unused PPP sessions at a PDSN consume valuable resources. The Cisco PDSN and Home Agent support Mobile IP Resource Revocation as defined in IS83C and Cisco Proprietary Binding Update and Binding Acknowledge messages for releasing such idle PPP sessions as soon as possible. Mobile IP Resource Revocation is described in Section 16 in greater detail

If Cisco Proprietary binding update feature is used, in the event of an inter-PDSN handoff and Mobile IP registration, the Home Agent updates mobility binding information for the mobile with the Care-of-Address (COA) of the new PDSN/FA. If simultaneous bindings are not enabled, the Home Agent sends a notification in the form of a Binding Update message to the previous PDSN/FA. The previous PDSN/FA acknowledges with Binding Acknowledge, if required, and deletes visitor list entry for the Mobile IP session. The previous PDSN/FA initiates the release of the PPP session when there are no active flows for that mobile station.

The sending of the binding update message is configurable at the Home Agent.


Note When multiple flows are established for the same NAI, a different IP address is assigned to each flow. This means that simultaneous binding is not required as this is used for maintaining more than one flow to the same IP address.


Simple IPv6 Access

The PDSN simple IP service has been enhanced to allow both simple IPv4 and simple IPv6 access. These protocols can be used one at a time, or at the same time. The ipcp and the ipv6cp are equivalent for each protocol.

An IPv6 access uses the same PPP LCP authentication and authorization procedures, as well as the AAA access. When an RP connection is established, the MS sends a PPP Link Control Protocol (LCP) Configuration-Request for a new PPP session to the PDSN. The PPP authentication (CHAP/PAP/none) is one of the parameters negotiated during the LCP phase. After the LCP parameters are negotiated between the MS and the PDSN, an LCP Configure-Acknowledge message is exchanged. Once LCP is up, the PPP authentication is started.

The authentication phase uses CHAP, PAP, or none, depending on the configuration and LCP negotiation. After authentication, the NCPs, ipcp and/or ipv6cp, can be started. A simultaneous IPv4 and IPv6 access from an MS shares the common LCP authentication and authorization as well as the AAA correlation-id parameter.

The ipv6cp protocol negotiates a valid non-zero 64-bit IPv6 interface identifier for the MS and the PDSN. The PDSN has only one interface-identifier associated with the PPP connection, so it will be unique. Once ipv6cp has been successfully negotiated, the PDSN and MS both generate unique link-local addresses for the IPv6 interface. The link-local addresses are generated by pre-pending the link-local prefix, FE80:/64, to the 64-bit interface-identifier negotiated during the ipv6cp phase (for example, FE80::205:9AFF:FEFA:D806). This gives a 128-bit link-local address.

The PDSN immediately sends an initial unsolicited Router Advertisement (RA) message on the PPP link to the MS. The link-local address of the PDSN is used as the source address and the destination address will be FF02::1, the "all nodes on the local link" IPv6 address. The PDSN includes a globally unique /64 prefix in the RA message sent to the MS. The prefix may be obtained from a local prefix pool or from AAA. The MS will construct a global IPv6 unicast address by prepending the prefix received in the RA to the lower 64-bit interface identifier. You should carefully configure the PDSNs so that the /64 prefix is globally unique for each MS.

After a successful ipv6cp negotiation phase and configuration of the link-local address, the MS transmits a Router Solicitation (RS) message if an RA message has not been received from the PDSN within some specified period of time. The RA is necessary for the MS to construct its 128-bit global unicast address.

In contrast to IPv4, an IPv6 MS will have multiple IPv6 addresses, including:

Link-local address

Global unicast address

Various multicast addresses used for IPv6 Neighbor Discovery and IPv6 ICMP messages

An IPv6 address is 128-bits for both source and destination addresses. The /64 designation means that 64-bits are used for the prefix (upper 64-bits). This is similar to an IPv4 netmask. A /128 address would mean that the entire address is used. Refer to RFC-3513 for additional IPv6 addressing details and information.

Configuring Simple IPV6

The following commands are used to configure simple IPV6 on the Cisco PDSN, and are listed in the Command Reference:

The cdma pdsn ipv6 command enables the PDSN IPv6 functionality.

The cdma pdsn ipv6 ra-count number command configures the number of IPv6 Route Advertisements (RA).

The cdma pdsn ipv6 ra-count number ra-interval number command controls the number and interval of RAs sent to the MN when an IPv6CP session comes up:

The cdma pdsn accounting send ipv6-flows command control the number of flows and UDR records used for simultaneous IPv4, IPv6 sessions.

The show cdma pdsn flow mn-ipv6-address command shows CDMA PDSN user information by MN IPv6 address.

The show cdma pdsn flow service simple-ipv6 command displays flow-based information for simple IPV6 sessions.

The debug cdma pdsn ipv6 command displays IPV6 error or event messages.

The following configuration commands are required for IPv6:

Global Configuration Commands

ipv6 unicast-routing - IPv6 is off by default

ipv6 cef - enables cef switching

ipv6 local pool PDSN-Ipv6-Pool 2001:420:10::/48 64 - enables a pool of IPv6 prefix addresses that can be sent to the MS as a Routing Advertisement (RA)

Virtual-template Interface Commands:

ipv6 enable - enables IPv6 on this interface

no ipv6 nd suppress-ra - do not suppress the Neighbor Discovery Routing Advertisement messages (suppressed on non-ethernet interfaces)

ipv6 nd ra-interval 1000 - send a ND Routing Advertisement every 1000 seconds

ipv6 nd ra-lifetime 5000 - lifetime for the ND Routing Advertisement is 5000 seconds

peer default ipv6 pool PDSN-Ipv6-Pool - use this pool for RA prefixes

Other commands

show ipv6

Please refer to the Cisco IOS IPV6 Command Reference at the following URL for more detailed information regarding these configuration commands:

http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_book09186a00801d661a.html

Session Redundancy Infrastructure

In PDSN Release 4.0, a redundant PDSN is updated with the session details at the following two different times:

Bulk sync when Standby PDSN comes up

When both Active and Standby PDSN are up and

Session comes up or goes down

Session is refreshed (includes details about updated auxiliary connections, IP flows and their mapping) upon receiving a re-registration

Flow comes up or goes down (includes SIP/MIP/PMIP)

Session goes from Active to dormant and vice versa

PPP renegotiation happens

TFT is received or updated

The new parameters introduced in this feature are synced to standby for both scenarios.

Functional Overview

PDSN session redundancy is focused on preserving user flows on fail-over. Support for the continuity of billing records, internal counters, and MIB variables is secondary. The following conditions need to exist for fail-over to be successful on the PDSN:

Users perceive no service interruption.

Users do not experience excessive or incorrect billing.

Users are able to re-initiate data service after fail-over.

The PDSN Session Redundancy feature provides user session failover capability to minimize the impact of a PDSN failure on the mobile user experience. The PDSN uses a 1:1 redundancy model, with a standby present for every active PDSN. The active PDSN sends state information to the standby PDSN for synchronization on an as-needed basis. When a PDSN failure occurs, the standby PDSN has the necessary state information to provide service to all existing sessions. It then takes over as the active PDSN and services user sessions, thus providing session redundancy. When the previously active PDSN comes back online, it assumes the role of standby for the now active PDSN, and receives state information for all existing sessions from the newly active PDSN.

Under normal operating conditions, the active and standby PDSN pairs are two separate PDSN images that have identical configurations. They share one or more HSRP interfaces, which are used by all external entities to communicate with them. The active PDSN synchronizes session data to the standby PDSN based on events described below.

Session Events

When a new user session needs to be established, the PCF first sets up an A10 connection to the active PDSN using the HSRP address known to the PCF. The MN then sets up a PPP connection with the active PDSN using the A10 tunnel. Once the call is in a stable state (the PPP session is successful), the active PDSN then syncs relevant state information to the standby PDSN. The standby then duplicates the actions of the active PDSN with regards to the A10 connection and the PPP session, and awaits further updates from the active. When any of the other events as listed below occurs, the active PDSN sends state information to the standby.

In order to minimize the loss of accounting data in the event of a failover, a periodic accounting update, with configurable frequency shall run on the active PDSN. Every periodic update for a session shall trigger a sync sent to the standby PDSN, which shall update its accounting data. Only counters and attributes that undergo a change on the active PDSN are synced to the standby periodically. Information since the last accounting synchronization point will be lost. Also, in order to ensure that the latest information is correctly conveyed to the billing system, the standby unit will never send out any accounting records to the AAA server. The records are always sent from the Active Unit.

Session events that lead to a sync are:

Call Setup

Call teardown

Flow setup

Flow teardown

Dormant-Active transition

Handoff

A11 Re-registrations

Periodic accounting sync

PPP renegotiation

Active PDSN Failure

In the event that the standby PDSN detects that the active PDSN has failed (using HSRP), it then takes over as the active PDSN. Since all external entities, including PCFs, AAA servers, and Home Agents are configured to communicate with the PDSN pair only using the HSRP addresses, once the standby PDSN takes over those addresses, they are unable to detect a failure. All stable calls also have their state synced to the standby; therefore the standby is able to start forwarding user traffic once it takes over as active. On the standby all timers (such as A11 lifetime, PPP timers, and Mobile IP lifetime) are started at the time it takes over as active. Accounting data is also synchronized to the extent that the periodic accounting sync timer has been configured on the PDSNs.

Standby PDSN Start-up

When a PDSN comes up when there is an existing active, it takes over the standby role. When the active PDSN learns that a standby PDSN is available, it goes through a process of transferring state data for all existing user sessions to the standby, called a Bulk Sync. Once this process is complete, the standby PDSN is then ready to take over as active in the event of a failure.

Handling Active-Active Scenario

If there is a link failure or a failure in an intermediate node, HSRP packets sent will not reach the peer and the standby node would assume that the active has reloaded and transitioned to active state. This leads to a situation of Active-Active PDSN nodes. The requirement is that, in case one of the PDSNs continues to receive traffic while the other is isolated from the network, it is ensured that the node which received traffic should remain active once the link is restored.

To achieve this, an application tracking object is introduced and HSRP priority is altered based on whether PDSN is processing traffic after the HSRP peer is lost. The PDSN will lower its HSPR priority once it detects that the peer PDSN is lost. Afterward, when the PDSN processes traffic (either control or data packets), it raises its priority back to the configured value. This helps to choose the active node after the link is restored between the PDSNs. So the node which received traffic in Active-Active situation remains to be Active after link restoration.

Other Considerations

A Redundancy Framework (RF) MIB is available in order to monitor the active and standby status of the two PDSNs. Other MIB variables and internal counters are not synchronized between the Active and Standby. They start from the values following IOS-Load or Reload on the backup image. The backup image is treated as a new box.

The PDSN redundant pair is treated as a single member by the cluster controller, and is transparent to the PDSN clustering mechanism. The cluster controller is oblivious to a failover from an active PDSN to its redundant standby.

Similarly, a PDSN redundant pair appears as a single PDSN to all external entities, such as the PCF, the HA, and the AAA server.

IPSec security associations for FA-HA connectivity are maintained across fail-over.


Note Currently, VPDN, Closed RP, IPv6, and Prepaid services are not supported by the Session Redundancy implementation.



Note Configuration synchronization between the active and standby units is not supported for R3.0. The operator needs to enter configuration commands on both the Active and Standby units.


In Process Sync Events

The following subsections explain the expected behavior of the PDSN under session redundancy for various sync events in process.

Call Setup

The state of "sessions-in-progress" is not preserved during fail-over. Mechanisms such as R-P connection retry from the PCF will ensure that sessions will be established as required.

It is possible that a fail-over can occur when the PCF has established an R-P session for a user flow, but user flow establishment is not completed. In this case, fail-over will result in the R-P session not being present on the standby. The PCF will timeout the R-P session on the next R-P session lifetime refresh. If the user attempts to establish a new session during this time, a new session will be created.

Call Teardown

There are four scenarios for session termination. These include the following:

Mobile Terminal initiates session teardown

PPP Idle Timeout expires on PDSN

PDSN initiates a Registration Update

PCF initiates a Registration request with lifetime 0

For each of these cases, session teardown is a multi-step process. For example, a fail-over can occur when a Registration Update message has been sent from the PDSN and the acknowledgement has not been received. In this case, the standby PDSN will already have been told to delete the session. The active PDSN will not wait for an update acknowledgement from the PCF.

If a fail-over occurs after sending the Registration Update to the PCF but before the standby has been told to delete the session, or the request to delete the session is lost, the session will remain established on the standby.

Another case is that the PPP context has been deleted as a result of mobile-initiated termination, and then fail-over occurs prior to the R-P session being terminated.

Similarly, expiry of the PPP Idle timer on the PDSN could also result in deletion of PPP context followed by fail-over prior to R-P session termination.

In these cases, either the Mobile IP Registration Lifetime or the PPP Idle Timeout will expire, and the session is terminated.

Flow Setup

Flows that are in the process of being established are not preserved. You will see this as failure to establish the flow, and you will have to re-establish the flow.

Flow Teardown

This section applies when a session has two or more flows. Currently only a MoIP call supports this case. For an SIP call, only one flow is allowed.

Although a MoIP flow is preserved after switchover, it is possible that registration lifetime expiration will lead to deletion of the flow. If the same user registers again before the lifetime expires, it will be considered as a re-registration since this is an existing visitor. However, the re-registration may or may not succeed, depending on the following conditions:

1. If the user got a Registration Reply (RRP) for its previous de-registration from the active node before the switchover and if the Foreign Agent Challenge (FAC) included in that RRP is not synced to the now active node (very likely, otherwise, the flow would have been deleted from this node), this re-registration will be rejected with an invalid challenge error. The user has to initiate a solicitation to the new active node, receive a new challenge and then resend a Registration Request (RRQ). This time, the RRQ is treated as a valid re-registration and the lifetime is refreshed. It also gets the same IP address as the previous one even though the user considers this as a new registration (it is a re-registration from the FA's and HA's view).

2. If the user did not get a RRP for its previous de-registration from the active node before the switchover, de-registration is resent to the now-active node. This de-registration is likely to be rejected due to invalid FAC, which depends on whether the latest FAC is synced to the standby before the switchover. Then the user can either send a solicitation to get a new FAC and then sends de-registration again or simply give up. In the latter case, 1 above applies.

Dormant-Active Transition

The transition is synchronized between active and standby, and would fall into following scenarios:

1. If the PCF receives a RRP in response to the RRQ, and if the transition state is synced to the standby before the switchover, the now-active node will have the right session state and the transition is successful.

2. If the PCF receives a RRP in response to the RRQ but the transition state is not synced to the standby before the switchover, the now-active node will have the wrong session state (e.g. session is marked as dormant while it should be active).

However, packets will be switched and counted. The PDSN-related show commands may not show all the right information about the session. The subsequent transition from active to dormant will not cause difficulties as the session remains dormant on the PDSN.

3. If the PCF did not receive an RRP in response to the RRQ before the switchover and if it tries again with the now-active node, this is handled as today.

4. If the PCF did not receive a RRP in response to the RRQ before the switchover, and if it exceeds the maximum number of retries with the now-active node, this is handled as 2 above.

Handoff

Inter-PCF Handoff (Dormant or Active) - Same PDSN

The most significant problem with hand-off is to re-establish the data path between the target PCF and the now-active PDSN for the preserved session, irrespective of whether this is an active or dormant handoff. Again, there is a window between handoff actually being completed and the state being synchronized within which a fail-over can occur.

These are the following scenarios:

1. If the target PCF received an RRP from the active PDSN, and the handoff state is synchronized to the standby before switchover, the data path between the target PCF and the now-active PDSN is established for the handed-off session and the user would not perceive any service disruption. The old PCF may or may not receive the Registration Update from the previously active node, depending on the exact point of switchover. If it receives the Registration Update and sends out a RRQ (lifetime=0), the call should be treated correctly at the old PCF. In case that the old PCF does not receive the Registration Update, and that the session is handled back to it again, it's not clear how PCF will handle this case (this is similar to that the PCF has an existing call for a user and then receives a new call request from the same user). If the PCF ignores the new request, the correct data path is not present and therefore a user is not able to transfer traffic.

2. If the target PCF received the RRP from the active PDSN, but the handoff state is NOT synchronized to the standby before switchover, the data path between the target PCF and the now-active PDSN will not be established (the session still points to the old PCF). As a result, the end user will notice service disruption. The user cannot gracefully de-register as PPP packets for call termination (TERMREQ) cannot reach the now-active PDSN, and the RRQ (lifetime=0) from the target PCF arrives on the now-active PDSN but the session does not recognize this as a valid remote tunnel endpoint. As a result, de-registration is ignored. The session will eventually be deleted on expiry of the PPP idle timer or registration lifetime. If the user re-registers again, this will be treated as hand-off since the session's current remote tunnel endpoint (the old PCF) is different from the target PCF. This time, the data path is established and the user will receive service.

3. If the target PCF did not receive an RRP from the active PDSN before switchover, and if the PCF tries again with the now-active PDSN, the hand-off is processed the same as of today.

Inter-PCF Handoff (Dormant or Active) - Different PDSN

This kind of handoff is indicated to the PDSN by receipt of an A11 Registration Request containing the PANID and CANID. It also includes the Mobility Event Indicator and Accounting Data (R-P Session Setup Air-link Record). From the perspective of High Availability, this looks like a new session establishment on the newly active PDSN and a 'regular' session termination on the old PDSN.

A11 Re-registrations

A11 Re-registration RRQ is received by the active unit. The registration life timer does not start on the standby, but it keeps track of the life timer value so that it can restart the life timer once it becomes active. If the lifetime in the re-registration RRQ is different from the previous RRQ, the new lifetime is synced to the standby. For example, if a previous RRQ carries a lifetime of 300 seconds and now a new RRQ has the value changed to 500 seconds, the new value is synced to the standby. Other significant parameters included in the re-registration RRQ are also synced to the standby.

Now, in the above example, if the failover occurs before syncing the new lifetime to the standby, the standby will start the lifetime for 300 seconds.

PPP Re-negotiation

Upon PPP renegotiation, the PDSN deletes all the flows on the RP session and sends accounting STOP for each flow. Once PPP is up again, the PDSN creates new flow(s) for the session. Therefore, when PPP renegotiation happens on the active, the active unit will send a PPP renegotiation notification to the standby which will then delete all the flows from the RP session on the standby. Once PPP is up again and a new flow is created on the active, the active unit sends each flow's data to the standby. If the failover occurs during PPP re-negotiation, the re-negotiation will fail, and the session may be torn down on the newly active unit.

Other Considerations

Timers

The following timers are normally running when a session is established

R-P Session Lifetime

PPP Idle Timeout

Mobile IP Registration Lifetime

PPP Absolute Session Timeout

The following timers may be running, depending on configuration

Periodic accounting (not to be confused with the sync timer mentioned above).

These timers are restarted on the standby when fail-over occurs, and the elapsed time is not synchronized to the standby. The effect will be to extend the timers beyond their original values by a time equal to the time that has already expired. This ensures that the user will not perceive a session failure on fail-over.

Restrictions

The following restrictions exist for the PDSN Session Redundancy Feature:

Limitation for Resource Revocation with SR Setup.

Setting the revocation timestamp to "msec" (ip mobile foreign-service revocation timeout 5 retransmit 4 timestamp msec) for PMIP flows with Session Redundancy is not permitted.

The "msec" option puts the uptime in the timestamp field, and the uptime of the standby router is expected to be lower after switchover when the standby PDSN takes over as active (and when the PMIP flow was closed). Therefore, revocation on HA will be ignored because the identifier value in the revocation message is less than what is expected by HA.

The ip radius source interface command does not support virtual address (HSRP), and hence the IP address configured under Loopback interface to be used as source interface (NAS IP address) for reaching AAA in SR setup

Internals

The following sections identify information that is synced to the standby unit:

AHDLC

The control character mapping per used AHDLC channel is preserved. As the default is normally used, only those that are different are synchronized. The AHDLC channel number is not synchronized; an available channel will be selected independently on the standby.

GRE - RP Interface

The GRE Key is synchronized. The flags are synchronized as the sequence flag can be set on a per user basis.

RP Signaling

The contents of the A11 messaging will be treated as described below.

Flags - Fixed - No synchronization required.

Lifetime - Synchronized.

Home Address - No synchronization required.

Home Agent - No synchronization - This is the HSRP address of the R-P interface. This is used for proposing a PDSN IP address when clustering is configured. This will be the HSRP address of the proposed PDSN. It is only used prior to session establishment.

Care-of-Address - Synchronized - This is the PCF IP address for the R-P Session.

A10 Source IP Address - Synchronized - This is the PCF's A10 IP Address.

Identification - Not synchronized - contains timestamp to protect against replay attacks.

Mobile-Home Authentication Extension - Not synchronized, calculated per message.

Registration Update Authentication Extension - Not synchronized, calculated per message.

Session-Specific Extension - Synchronized - covers Key, MN_ID and SR-ID.

C-VOSE - This contains multiple application types, Accounting, MEI and DAI. The accounting information will be synchronized. Details are in the accounting section.

N-VOSE contents - ANID will be synchronized, both as part of the session establishment and when it changes as a result of handoff. Fast handoff is not supported, so PDSN Identifier and Identifiers are not relevant to the session redundancy discussion.

RNPDIT - Synchronized - Radio Network Packet Data Inactivity Timer.

The source UDP port for the A11 traffic will be synchronized.

PPP

All LCP options are synchronized. For IPCP, only the IP address and IPHC parameters are synchronized. DNS server IP address negotiated during IPCP negotiation is not synchronized to the standby unit. All per user attributes downloaded from AAA during authentication/authorization are synchronized to the standby unit.

Compression - Header and Payload

There is no synchronization of compression context for either header or payload compression. Fail-over to a standby PDSN results in the compression context being re-established.

Header compression - First packet for a session after switchover is dropped, and peer retries the packet after acknowledge timeout.

Payload compression - There is no compression history present after switchover on the standby. A CCP reset is automatically generated when decode fails. No special treatment is needed.

IP Address Assignment

When an IP address is dynamically assigned from a pool configured on the PDSN, it is necessary that the standby associates the same address with the session. The IP address will be synchronized as part of PPP state. If the IP address is received from AAA or a static IP address is used that does not come from a local pool, this address will also be associated with the session on the standby. Similarly, the address pool will be synced.

AAA - Authentication and Authorization

Table 2 lists the relevant Authentication and Authorization parameters. This is required on the standby to allow accurate recreation of AAA state.

Table 5 Standard AVPs Supported for Authentication and Authorization 

Authentication and Authorization AVPs Supported By Cisco IOS Name
Synchronized
Description
Allowed In
     
Access Request
Access Accept

User-Name

Yes

User name for authentication and authorization.

Yes

No

User-Password

No

Password for authentication.

Yes

No

CHAP-Password

No

CHAP password.

Yes

No

NAS-IP-Address

No

IP address of the PDSN interface used for communicating with RADIUS server. A loopback address could be use for this purpose.

Yes

No

Service-Type

No

Type of service the user is getting. Supported values include:

"Outbound" for MSID based user access

"Framed" for other type of user access

Yes

Yes

Framed-Protocol

No

Framing protocol user is using. Supported values include:

PPP

Yes

Yes

Framed-IP-Address

Yes

IP address assigned to the user.

Yes

Yes

Session-Time-Out

Yes

Maximum number of seconds of service is to be provided to the user before session terminates.

This attribute value becomes the per-user "absolute time-out."

No

Yes

Idle-Time-out

Yes

Maximum number of consecutive seconds of idle connection allowed to the user before the session terminates.

This attribute value becomes the per-user "idle-time-out".

No

Yes

Calling-Station-ID

Yes

MSID identifier of the mobile user.

Yes

No

CHAP-Challenge (optional)

No

CHAP Challenge.

Yes

No

Tunnel-Type

No

VPN tunneling protocol(s) used. Supported values include:

1 for PPTP (not supported)

3 for L2TP

No

Yes

Tunnel-Medium-Type

No. Not supported

Transport medium type to use for the tunnel.

No

Yes

Tunnel-Client- Endpoint

No. Not supported

Address of the client end of the tunnel. When you specify Tunnel-Client-Endpoint, Tunnel-Server is not supported. Use L2TP

No

Yes

Tunnel-Server- Endpoint

No. Not supported

Address of the server end of the tunnel.

No

Yes

Tunnel-Password

No. Not supported

Password to be used for authenticating remote server.

No

Yes

Tunnel-Assignment-ID

No. Not supported

Indicates to the initiator of the tunnel, identifier of the tunnel to which the session is assigned.

No

Yes

addr-pool

No. Not supported

Name of a local pool from which to obtain address. Used with service=ppp and protocol=ip.

"addr-pool" works in conjunction with local pooling. It specifies the name of a local pool (which must have been pre-configured locally).

Use the ip-local pool command for configuring local pools. For example:

ip address-pool local

ip local pool boo 10.0.0.1 10.0.0.10

ip local pool moo 10.0.0.1 10.0.0.20

No

Yes

Inacl#<n>

Yes

ASCII access list identifier for an input access list to be installed and applied to an interface for the duration of the current connection.

Used with service=ppp and protocol=ip, and service service=ppp and protocol =ipx.

Note Per-user access lists do not currently work with ISDN interfaces.

No

Yes

Inacl

Yes

ASCII identifier for an interface input access list.

Used with service=ppp and protocol=ip.

Contains an IP output access list for SLIP or PPP/IP (for example, intacl=4).

The access list itself must be pre-configured on the router.

No

Yes

outacl#<n>

Yes

ASCII access list identifier for an interface output access list to be installed and applied to an interface for the duration of the current connection.

Used with service=ppp and protocol=ip, and service service=ppp and protocol=ipx.

No

Yes

Outacl

Yes

ASCII identifier for an interface output access list.

Used with service=ppp and protocol=ip, and service service=ppp and protocol=ipx.

Contains an IP output access list for SLIP or PPP/IP (for example, outacl=4).

The access list itself must be pre-configured on the router.

No

Yes

interface-config

Yes

User-specific AAA interface configuration information with Virtual Profiles.

The information that follows the equal sign (=) can be any Cisco IOS interface configuration command.

No

Yes

SPI

Yes

Carries authentication information needed by the home agent for authenticating a mobile user during MIP registration.

Provides the Security Parameter Index (SPI), key, authentication algorithm, authentication mode, and replay protection timestamp range.

The information is in the same syntax as the ip mobile secure host address configuration command. Essentially, it contains the rest of the configuration command that follows that string, verbatim.

No

Yes

IP-Pool-Definition

Yes

Defines a pool of addresses using the format: X a.b.c Z; where X is the pool index number, a.b.c is the pool's starting IP address, and Z is the number of IP addresses in the pool.

For example, 3 10.0.0.1 5 allocates 10.0.0.1 through 10.0.0.5 for dynamic assignment.

No

Yes

Assign-IP-Pool

Yes

Assign an IP address from the identified IP pool.

No

Yes

Framed-Compression

Yes

Indicates a compression protocol used for the link. Supported values include:

0: None

1: VJ-TCP/IP header compression

No

Yes

Link-Compression

Yes

Link compression protocol to be used.

Supported values include:

0: None

1: Stac

2: Stac-LZS

3: MS-Stac

No

Yes


GPP2 Packet Data Service Attributes

Table 3 lists the 3GPP2 Packet Data Service Attributes.

Table 6 3GPP2 Packet Data Service Attributes 

Name
Synchronized
Description
                             Allowed In
     

Access Request

Access Accept

mobileip-mn- lifetime

Yes

Defines lifetime used in Proxy MIP RRQ.

No

Yes

mobileip-mn- ipaddr

Yes

MN IP address for static address assignment. If this attribute is present, this address is used in Proxy MIP RRQ.

No

Yes

mobileip-mn- flags

Yes

Defines Flags used in Proxy MIP RRQ.

No

Yes

CDMA-Realm

Yes

For MSID based access, "realm" information for construction of user name in the form MSID@realm. User names constructed this way are used for accounting purposes only.

The format of realm information is:

ASCII string specifying realm of user's registered domain.

No

Yes

CDMA-User- Class

Yes

Type of service user is subscribed to.

Supported values are:

1 for Simple IP

2 for Mobile IP

No

Yes

3GPP2-Reverse- Tunnel- Spec

Yes

Indicates whether reverse tunneling is required or not.

Su.pported values are:

0 for reverse tunneling not required.

1 for reverse tunneling required.

No

Yes

3GPP2-Home- Agent- Attribute

Yes

Address of the Home Agent

Yes

Yes

3GPP2-IP- Technology

Yes

Indicates type of service user is subscribed to.

Supported values are:

1 for Simple IP

2 for Mobile IP

No

Yes

3GPP2- Correlation-Id

Yes

Identifies all accounting records generated for a particular user flow.

Yes

Yes

3GPP2-Always-On

Yes

Indicates Always On Service.

Supported values are:

0 for non always on users

1for always on users

No

Yes

3GPP2-Security Level

Yes

Indicates the type of security that the home network mandates on the visited network.

No

Yes

3GPP2- IKE Pre-shared Secret Request

No

Indicates that the PDSN needs a pre-shared secret for Phase 1 IKE negotiation with the HA.

Yes

No

3GPP2-Pre-shared secret

No

A pre-shared secret for IKE.

No

Yes

3GPP2-KeyID

No

Contains the KeyID parameter used during IKE exchange between the PDSN and the HA.

No

Yes

3GPP2-Allowed DiffServ marking

No

Specifies if the user is able to mark packets with AF (A), EF (E). The Max Class (i.e., Max Selector Class), specifies that the user may mark packets with a Class Selector Code Point that is less than or equal to Max Class.

No

Yes

3GPP2-MN-AAA Removal Indication

Yes

When received in a RADIUS Access-Accept message, the PDSN shall not include the MN-AAA.

No

Yes

3GPP2-Foreign- Agent Address

No

The IPv4 address of the PDSN CoA contained in RRQ.

Yes

No

Service Option

Yes

Indicates the type of service being used.

Yes

No

DNS Update Required

No. Not supported

Indicates whether DNS update is required.

No

Yes

RN PDIT

Yes

Radio Network Packet Data Inactivity Timer.

No

Yes

Session Termination Capability

Yes

Indicates the nature of resource revocation supported.

Yes

Yes


AAA Accounting

GPP2 Accounting Records Fields

Table 7 GPP2 Accounting Records Fields 

Item
Parameter
Description
Synchronized

A. Mobile Identifiers

A1

MSID

MS ID (e.g., IMSI, MIN, IRM)

Yes

A2

ESN

Electronic Serial Number

Yes

A3

MEID

Mobile Equipment Identifier

Yes

B. User Identifiers

B1

Source IP Address

IPv4 address of the MS.

Yes

B2

Network Access Identifier (NAI)

user@domain construct which identifies the user and home network of the MS.

Yes

B3

Framed-IPv6- Prefix

MS IPv6 prefix.

Not supported.

B4

IPv6 Interface ID

MS IPv6 interface identifier.

Not supported.

C. Session Identifiers

C1

Account Session ID

The Account Session ID is a unique accounting ID created by the Serving PDSN that allows start and stop RADIUS records from a single R-P connection or P-P connection to be matched.

Yes

C2

Correlation ID

The Correlation ID is a unique accounting ID created by the Serving PDSN for each packet data session that allows multiple accounting events for each associated R-P connection or P-P connection to be correlated.

Yes

C3

Session Continue

This attribute when set to "true" means it is not the end of a Session and an Accounting Stop is immediately followed by an Account Start Record. "False" means end of a session.

Yes

C4

Beginning Session

The attribute when set to "true" means new packet data session is established; "false" means continuation of previous packet data session. This attribute is contained in a RADIUS Accounting-Request (Start) record.

No

C5

Service Reference ID

This is the service instance reference ID received from the RN in an A11 Registration-Request message.

Yes

D. Infrastructure Identifiers

D1

Home Agent

The IPv4 address of the HA.

Yes

D2

PDSN

The IPv4 address of the PDSN.

No. Should be configured to be the same on the active and standby.

D3

Address Serving PCF

The IP address of the serving PCF (the PCF in the serving RN).

Yes

D4

BSID

SID + NID + Cell Identifier type 2.

Yes

D5

IPv6 PDSN Address

The IPv6 address of the PDSN.

Not supported

D6

Foreign Agent Address

The IPv4 address of the FA-CoA.

Not supported

E. Zone Identifiers

E1

User zone

Tiered Services user zone.

Yes

F. Session Status

F1

Forward FCH Mux Option

Forward Fundamental Channel multiplex option.

Yes

F2

Reverse FCH Mux Option

Reverse Fundamental Channel multiplex option.

Yes

F5

Service Option

CDMA service option as received from the RN.

Yes

F6

Forward Traffic Type

Forward direction traffic type - either Primary or Secondary.

Yes

F7

Reverse Traffic Type

Reverse direction traffic type - either Primary or Secondary.

Yes

F8

FCH Frame Size

Specifies the FCH frame size.

Yes

F9

Forward FCH RC

The format and structure of the radio channel in the forward Fundamental Channel. A set of forward transmission formats that are characterized by data rates, modulation characterized, and spreading rates.

Yes

F10

Reverse FCH RC

The format and structure of the radio channel in the reverse Fundamental Channel. A set of reverse transmission formats that are characterized by data rates, modulation characterized, and spreading rates.

Yes

F11

IP Technology

Identifies the IP technology to use for this call: Simple IP or Mobile IP.

Yes

F12

Compulsory Tunnel Indicator

Indicator of invocation of compulsory tunnel established on behalf of MS for providing private network and/or ISP access during a single packet data connection.

Yes

F13

Release Indicator

Specifies reason for sending a stop record.

Yes

F14

DCCH Frame Size

Specifies Dedicated Control Channel (DCCH) frame size.

Yes

F15

Always On

Specifies the status of Always On service.

Yes

F16

Forward PDCH RC

The Radio Configuration of the Forward Packet Data Channel. (This parameter can be used as an indication that the MS is 1xEV DV capable.)

Yes

F17

Forward DCCH Mux Option

Forward Dedicated Control Channel multiplex option.

Yes

F18

Reverse DCCH Mux Option

Reverse Dedicated Control Channel multiplex option

Yes

F19

Forward DCCH RC

The format and structure of the radio channel in the forward Dedicated Control Channel. A set of forward transmission formats that are characterized by data rates, modulation characterized, and spreading rates.

Yes

F20

Reverse DCCH RC

The format and structure of the radio channel in the reverse Dedicated Control Channel. A set of reverse transmission formats that are characterized by data rates, modulation characterized, and spreading rates.

Yes

F22

Reverse PDCH RC

The Radio Configuration of the Reverse Packet Data Channel.

Yes

G. Session Activity

G1

Data Octet Count (Terminating)

The total number of octets in IP packets sent to the user, as received at the PDSN from the IP network (i.e. prior to any compression and/or fragmentation).

Yes

G2

Data Octet Count (Originating)

The total number of octets in IP packets sent by the user.

Yes

G3

Bad PPP frame count

The total number of PPP frames from the MS dropped by the PDSN due to incorrect able errors.

Yes

G4

Event Time

This is an event timestamp which indicates one of the following:

The start of an accounting session if it is part of a RADIUS start message.

The end of an accounting session if it is part of a RADIUS stop message.

An Interim-Update accounting event if it is part of a RADIUS Interim-Update message.

Yes

G5

Remote IPv4 Address Octet Count

Contains the octet count associated with one or more remote IPv4 address; used for source/destination accounting.

Not supported

G6

Remote IPv6 Address Octet Count

Contains the octet count associated with one or more remote IPv6 address; used for source/destination accounting.

Not supported

G8

Active Time

The total active connection time on traffic channel in seconds.

Yes

G9

Number of Active Transitions

The total number of non-active to Active transitions by the user.

Not supported

G10

SDB Octet Count (Terminating)

The total number of octets sent to the MS using Short Data Bursts.

Yes

G11

SDB Octet Count (Originating)

The total number of octets sent by the MS using Short Data Bursts.

Yes

G12

Number of SDBs (Terminating)

The total number of Short Data Burst transactions with the MS.

Yes

G13

Number of SDBs (Originating)

The total number of Short Data Burst transactions with the MS.

Yes

G14

Number of HDLC layer octets received

The count of all octets received in the reverse direction by the HDLC layer in the PDSN.

Yes

G15

Inbound Mobile IP Signaling Octet Count

This is the total number of octets in registration requests and solicitations sent by the MS.

Yes

G16

Outbound Mobile IP Signaling Octet Count

This is the total number of octets in registration replies and agent advertisements sent to the MS prior to any compression and/or fragmentation.

Yes

G17

Last User Activity Time

This is a Timestamp (in number of seconds from Jan 1 1970 UTC) of the last known activity of the user.

Yes

I. Quality of Service

I1

IP Quality of Service (QoS)

This attribute is deprecated.

Not supported

I2

Airlink Priority

Identifies Airlink Priority associated with the user. This is the user's priority associated with the packet data service.

Not supported

Y. Airlink Record Specific Parameters

Y1

Airlink Record Type

3GPP2 Airlink Record Type.

No

Y2

R-P Connection ID

Identifier for the R-P Connection. This is the GRE key that uniquely identifies an R-P connection (an A10 connection) between the PCF and the PDSN.

Yes

Y3

Airlink Sequence Number

Sequence number for Airlink records. Indicates the sequence of airlink records for an R-P connection.

Yes

Y4

Mobile Originated / Mobile Terminated Indicator

Used only in SDB airlink records. Indicates whether the SDB is Mobile Originated or Mobile Terminated. (0=Mobile Originated and 1=Mobile Terminated).

Yes

Z. Container

Z1

Container

3GPP2 Accounting Container attribute. This attribute is used to embed 3GPP2 AVPs.

Not supported


Table 4 identifies the GPP2 accounting records fields.

Radius Server Group Support

The IP address of the AAA server chosen will not be synchronized.

Mobile IP Signaling

For Mobile IP service, the parameters to be synchronized, per MIP flow, include the following:

Mobile IP Registration Lifetime

Mobile IP Flags indicated in the Registration Request

MN-AAA Removal Indication received from AAA

Home Agent IP address

Mobile's IP Address

Reverse Tunneling indication

Care of Address from Mobile IP Registration Request

FA-Challenge (used during Mobile Node reregistration)

Mobile IP Tunneled Traffic

This traffic is carried in either GRE tunnels or IP-in-IP tunnels. The only information that needs to be synchronized is the tunnel endpoint of the peer.

Locally Configured IPSec

For the PDSN on the Cat76xx, IPSec tunnels are terminated on the VPN Acceleration Module. The role of the PDSN is to retrieve parameters from AAA and, based on these, 'trigger' IPSec tunnel establishment. Synchronization of these parameters is sufficient to preserve IPSec tunnels in the event of PDSN fail-over for intra-chassis configurations. PDSN failover is not coupled with VPN Acceleration Module/SUP failover. Inter chassis configurations and intra-chassis SUP failover does not currently support stateful IPSec.

FA-HA IPSec

FA-HA IPSec tunnels will be preserved when PDSN on 7600 fail-over occurs for intra-chassis configurations. They will not be preserved for inter chassis configurations.

AAA Accounting

Periodic Accounting Sync

Accounting information is optionally synchronized between the active and standby images. This synchronization occurs at the configured periodic accounting interval. The counters that are synchronized are g1 and g2, along with the packet counts. Sending an Interim Accounting record will trigger synchronization of the byte and packet counts. Setting the operator-defined periodic accounting interval determines the accuracy of the user-billing record as impacted by PDSN fail-over. It is possible that undercharging could occur; however, overcharging is not possible.

Accounting with VSA Approach

After a switchover takes place, the first interim or stop accounting record (as appropriate) includes a VSA (cdma-rfswact) indicating that a switchover has occurred. The inclusion of this VSA is controllable by issuing the cdma pdsn redundancy accounting send vsa swact command.


Note Please note that the G1 and G2 counters will not sync.


Here is a sample accounting debug with vsa:

Sep 13 18:23:10.179: RADIUS:   Cisco AVpair       [34]  16  
Sep 13 18:23:10.179: RADIUS:   63 64 6D 61 2D 72 66 73 77 61 63 74 3D 31        
[cdma-rfswact=1]

System Accounting

In a session redundancy setup, an accounting ON will be sent by the active unit only when the whole setup is brought up (accounting ON will not be sent by the newly active unit after a failover). The standby unit does not send any system accounting events under any scenarios. The events, however, are sent in a standalone mode.

A sys-off is sent if reload is issued on the active unit.

New Features in This Release

Served MDN

Served MDN is a vendor specific attribute defined by China Telecom. It is similar to the Class IETF attribute. The Served MDN attribute is received by the PDSN from AAA in a radius access accept message and is included in all the accounting request messages sent to AAA for the session or IP flow.

The Served-MDN attribute is a China Telecom VSA which is downloaded from AAA as part of radius access-accept message per user.

When you configure the cdma pdsn attribute vendor 20492 command, the PDSN will parse the served MDN attribute, and will send the attribute in accounting messages. If parsed successfully, the attribute value is stored as part of the flow structure for the user that has received the radius access-accept message.

If downloaded, this attribute is sent in all accounting request messages (start, stop, and interim-update) of the corresponding flow and its associated IP flows. If the PDSN receives multiple values of this attribute in a single access-accept message, and if they are parsed successfully, the last instance in the list of attributes downloaded is stored in the flow structure.

The PDSN drops the access-accept if it gets an invalid format or incorrect length for the Served-MDN VSA. The corresponding failure counter is then incremented. When a new value of the attribute is received in an access-accept during PPP-renegotiation or MIP re-registration, the latest value downloaded will update the existing value. And when a subsequent access-accept does not download this value, then the existing value is retained.

In case of inter-PCF handoff, this attribute is sent in both the accounting stop and accounting start message. In case of PPP renegotiation, if PDSN receives a new value, then the new value will be stored in flow structure. If a new attribute value is downloaded when the session is dormant and accounting start stop is not enabled, the accounting stop contains the old served MDN attribute value and the accounting start contains the new served MDN attribute value.

If unknown China Telecom attributes are received, these attributes are ignored.

If both IETF class attribute and CT VSA served MDN attribute is downloaded as a part of access accept, both attributes are sent to AAA in accounting messages for the session.

To support the served MDN attribute in accounting, show and debugs, perform the following task:

 
Command
Purpose

Step 1 

router (config)# cdma pdsn attribute vendor 20492

This new CLI enables the PDSN to parse the served MDN attribute, and send the attribute in accounting messages. The Served MDN CLI needs to be configured to support the served MDN attribute.

Here is an example of the configuration:

router(config)#cdma pdsn attribute vendor 20942

Framed Pool

The Framed Pool attribute is an IETF attribute downloaded by the PDSN from AAA in RADIUS access-accept message. This attribute value is used by the PDSN to match the IP pools configured in the PDSN, and allocates an IP address from the selected pool through PPP IPCP negotiation. The PDSN supports Cisco VSA for downloading the pool names from AAA. This feature is part of a requirement to download the pool name as an IETF VSA.

The PDSN downloads the IETF Framed-pool attribute from the AAA as part of the access-accept message per user flow. If the local pool name matches the pool name downloaded, and if the pool has an IP address available for allocation, an IP address will be allocated to the MN and the allocated IP address is sent as part of IPCP CONFNAK message to the MN.

If the MN requests a static IP address and the IETF pool name is downloaded as well during the access accept, the static IP address requested by the MN is given preference only when the IP address preferred is within the pool range configured in the PDSN. Otherwise, the IP address is assigned from the downloaded Pool.

If no local pool matches the pool name configured in the PDSN, or if the matched pool name does not have any address to allocate, the PPP IPCP negotiation fails, and the call is terminated. If framed IP pool and Cisco av pair pool name attributes are downloaded, the IP address is allocated from the framed pool. When multiple framed IP pool names are downloaded, the IP address is allocated from the first of the downloaded pools. If the IP addresses in the framed IP pool are exhausted, the session goes down.

The IETF pool name is synced to standby by AAA subsystem. And parsing and validation of this attribute is performed by the AAA subsystem.

Other Considerations

SIP calls are supported. For all other calls, IP address assignment will be done by the HA and the pool configuration in VAAA will be ignored by the PDSN.

For PMIP calls, the address allocated by the HA is negotiated with the MN as a part of IPCP even if a IETF pool name attribute value was downloaded.

DNS Server IP

The DNS server IP address attribute is a 3GPP2 VSA downloaded by PDSN from AAA in radius access-accept message. These IP addresses downloaded from AAA shall be sent to MN if requested during the IPCP negotiation.

The PDSN downloads the 3GPP2 DNS IP address VSA with a Vendor Id 117 from AAA as a part of access accept message. Downloaded attributes are parsed for the primary and secondary IP addresses and are stored in the AAA list for the user session. The values that are sent in sub type 3 and 4 are not used by the PDSN. This attribute (if requested) is sent to the MN during IPCP negotiation from the AAA list.

During PPP IPCP negotiation, the MN requests an IP address in the IPCP CONFREQ message by sending the primary DNS IP address as 0.0.0.0 and secondary DNS IP address as 0.0.0.0. If a user is authorized for the DNS IP addresses, addresses downloaded from AAA are sent to the MN through the IPCP CONFNAK message.

If invalid attributes are downloaded in the DNS VSA (for example, an invalid length or an invalid subtype), the PDSN drops the access accept, and the corresponding failure counter is incremented. The PDSN does not check the content of the IP address in the primary and secondary fields and the value is sent to the MN as received.

If a user requests is sent for the DNS IP address, but the PDSN does not download the DNS IP address VSA, an IPCP CONFREJ message is sent rejecting the DNS request sent by the MN. Then the MN sends a new CONFREQ without the primary DNS address or secondary DNS address in its CONFREQ.

The attributes downloaded are sent to the MN for SIP calls when configured in VAAA. Flags downloaded are ignored by the PDSN for SIP and PMIP calls. For MIP calls, DNS is sent by the HA through MIP RRP. No configuration is required in the VAAA.

For PMIP calls, the DNS address downloaded by the HA is given preference. If the DNS IP address is downloaded from AAA for PMIP calls, it would not be suggested to the MN even if the mobile node requests for DNS server IP address.

If multiple 3GPP2 attributes, or a combination of 3GPP2 attributes, and CISCO VSA DNS attribute are downloaded, the last downloaded attribute value is taken into consideration. In case the 3GPP2 DNS server IP address attribute is downloaded but not negotiated with the MN, it would be displayed on the session.

Virtual Route Forwarding (VRF) with Sub-interfaces

The Virtual Route Forwarding (VRF) attribute is a CISCO specific vendor attribute downloaded by the PDSN from AAA in a RADIUS access-accept message. The virtual access (sub-interface created per session on the PDSN) is added to the VRF matching the VRF attribute value downloaded from AAA. The PDSN downloads the Cisco vendor specific VRF attribute from AAA as a part of Access accept message. If this VSA is received in user authorization, and if the VRF name returned from RADIUS is configured globally on the PDSN, the PDSN will apply this VRF information for the session.

The current support on IOS creates a full Virtual Access interface for this user session in order to support VRF. VRF forces the creation of a full access interface that limits the number of sessions to 8000 (only 8K software IDBs exist).

The VRF, when configured in PDSN, creates an instance of the routing table. When the VRF is applied to the virtual access created, after the PPP IPCP negotiation, the route inserted is in the VRF routing table and not in the global routing table. The current implementation supports VRF as an LCP-based configuration request.

Basic Functionality

The PDSN downloads the Cisco vendor specific VRF attribute from AAA as a part of Access accept message. For sub-interface support of VRF, the VRF value is downloaded as an IP level attribute.

IP CEF has to enabled for VRF to work.

If this VSA is received in user authorization, and if the VRF name returned from RADIUS is configured globally on the PDSN, then the PDSN applies this VRF information to the Virtual Access interface created for this user session.

You must download the "ip unnumbered" attribute with the VRF in order to apply the VRF attribute in the session.

If the VRF attribute is downloaded as a IP level attribute, the Virtual access created for the session is a sub-interface, and this sub-interface is added to the VRF on the PDSN which matched the VRF attribute value downloaded. If the downloaded VRF name is not configured, the call is dropped.

You must download the "ip unnumbered" attribute with the VRF in order to create sub-interface support in the VRF routing table. If the access accept from AAA has both the LCP and IP VRF attributes downloaded, we always create a FULL vacces interface. The order of LCP VSA in the user profile does not matter. It will always be used, over-riding any VRF-id VSA specifications.

If the access accept from AAA has multiple IP VRF attributes downloaded, the session will be dropped.

If the VRF attribute is not downloaded in order (VRF id followed by unnumbered interface), the session will be dropped.

If the VRF attribute is configured in the virtual-template, and if no VRF is downloaded from AAA, the VRF attribute configured locally gets updated in the session.

If the VRF Attribute is configured in the virtual-template and if a different VRF attribute is downloaded from AAA, the VRF attribute downloaded from AAA gets updated in the session.

The errors in the AAA VRF attribute handling is handled by the AAA sub-system.

The PDSN supports overlapping IP addresses for the user session with VRF.

In case of PPP renegotiation, when a VRF name is downloaded the virtual access created for the session is now associated with new VRF.

In case a PPP renegotiation does not download a VRF name, then the virtual access for the session is not associated with the VRF.

In case a VRF attribute is downloaded during MIP and VPDN call, the VRF attribute is not used.

If for a PMIP call, the VRF attribute is downloaded, Virutal Access will be associated with VRF routing table and the reverse traffic will be sent only through the VRF enterprise.

In case of SIP+MIP calls, if the SIP call is established with VRF association, and if a MIP call is requested as the SIP call is associated with a VRF, the MIP call will not be up as the MIP RRQ from MN is sent to the VRF enterprise.

Any traffic received on VRF applied V-Access will always be forwarded to VRF enterprise, and this is an expected IOS behavior.

The PDSN supports only IPv4 addresses as a part of the VRF. IPv6 behavior is undefined.

The data traffic for a virtual access in the forward direction (towards the MN) is received from outside the enterprise, the packet would be dropped by the IOS.

Accounting of packets at the PDSN occurs normally.

MN to MN routing packets in case of associated to the same VRF are sent to the enterprise and routed back to the destination MN. The PDSN does not switch this traffic.

In cases where traffic is destined for the PDSN from the MN, the packets are not routed to the VRF, but are processed at PDSN.

VRF attributes are synchronized to standby only during session creation. Any changes in the VRF during PPP renegotiation are not synchronized to standby.

Other Considerations

VRF information on the PDSN is applied only when the call established is a Simple IP session.

In cases of Mobile-IP users and Proxy Mobile-IP users, this support is not needed since it can already handle over-lapping IP address.

Overlapping IP addresses in SIP are differentiated by its virtual access and the VRF interface configured. The VRF routing table has a Virtual Access entry that identifies the corresponding MN.

VRF support on the PDSN ensures there are separate routing tables per enterprise, and users accessing the enterprise/corporate network have a separate routing table. The packets originated from the user cannot be forwarded outside of this routing table ensuring there is no security risk.

Performance

Additional memory is needed to create the VRF routing table.

Scalability

This feature supports a maximum of 25,000 PDSN sessions.

The CPS might be impacted due to additional processing per session.

Configuring PDSN Session Redundancy

The following new commands have been introduced for PDSN Session Redundancy:

Enabling PDSN Session Redundancy

The active PDSN shall be able to synchronize the session and flow related data to its standby peer provided the redundancy capability has been enabled. By default this capability is disabled.

The commands syntax is as follows:

[no] cdma pdsn redundancy

When the above CLI is configured, session redundancy is enabled provided the underlying redundancy infrastructure has been configured. The redundancy functionality for PDSN is disabled when the above command with no is executed.

Periodic Accounting Counters Synchronization

The active PDSN by default will not try synchronizing accounting counters periodically. To enable periodic accounting counters synchronization, configure the following command:

[no] cdma pdsn redundancy accounting update-periodic

The no form of the command is used to go to the default behavior. When configured, the byte and packet counts for each flow are synced from the active to the standby unit (only if they undergo a change) at the configured periodic accounting interval (using aaa accounting update periodic xxx). If periodic accounting is not configured, the byte and packet counts will not be synced.

Debug Commands for PDSN-Session Redundancy

In order to facilitate the identification of problem areas of PDSN high availability, the following debug commands are introduced for debugging. All of these debug can be turned off using either undebug all or no debug all, if desired.

[no] debug cdma attribute

[no] debug cdma pdsn redundancy packets

To debug and collect any data pertaining to PDSN-SR, the above command is executed and the details pertaining to redundancy data is sent to the console.

[no] debug cdma pdsn redundancy errors

To debug the PDSN-SR redundancy errors the above command is executed and the details pertaining to A11 data is sent to the console.

[no] debug cdma pdsn redundancy events

To debug events for PDSN session redundancy events, above command is executed and the details pertaining to PDSN (e.g. RP) data is sent to the console.

Display of Redundancy Statistics

When a pair of PDSNs is operating in an active and a standby mode, it is desirable to show or display a variety of information about the sessions and its associated flows that have been synchronized to the standby. The following command shall allow the operator to view the session redundancy data for PDSN.

show cdma pdsn redundancy statistics

On execution the above command displays a number of data items; some of the examples are as follows:

Number of sessions synchronized

Number of SIP flows

Number of MoIP flows

Number of synchronized sessions up after a switch-over.

Number of sessions failed to synchronize.


Note show cdma pdsn redundancy statistics will be hidden until service internal is configured.


show cdma pdsn redundancy

On execution of this command, in addition to existing data being displayed, it will also output "pdsn redundancy is enabled," or "redundancy is not enabled," depending on whether the redundancy feature for PDSN has been turned on, or not.

Clearing of PDSN Session Redundancy Statistics

clear cdma pdsn redundancy statistics

On execution of this command, all the data counters associated with the PDSN session redundancy will be actualized to initial value.

Other Debug Commands

In addition to the PDSN-SR debugging commands described above, the following commands associated with high availability are also useful debugging aid:

debug redundancy inter-device

debug ccm

Other Show Commands

In addition to the PDSN-SR show commands described above, the following commands associated with high availability are also useful:

show redundancy inter-device

Configuring PDSN Session Redundancy Infrastructure

The PDSN-SR feature uses the Cisco IOS Check-point Facility (CF) to send stateful data over Stream Control Transmission Protocol (SCTP) to a redundant PDSN. Additionally, in conjunction with Cisco IOS HSRP, the PDSN uses the Cisco IOS Redundancy Facility (RF) to monitor and report transitions on Active and Standby PDSNs.

Before you configure PDSN-SR, you need to configure the inter-device redundancy infrastructure.

Configuring HSRP

The Hot Standby Router Protocol (HSRP) provides high network availability because it routes IP traffic from hosts on networks without relying on the availability of any single router. HSRP is used in a group of routers for selecting an Active router and a Standby router. HSRP monitors both the inside and outside interfaces so that if any interface goes down, the whole device is deemed to be down and the Standby device becomes active and takes over the responsibilities of an Active device.

When configuring HSRP, note that the following recommendation and restrictions apply:

At minimum, HSRP must be enabled and an HSRP a "master" group defined on one interface per PDSN instance. A "follow" group can be configured on all other PDSN interfaces using the standby interface configuration command with the follow keyword option specified. The advantages of using follow groups are:

The follow group feature enables all interfaces on which it is configured to share the HSRP parameters of the master group.

Interfaces that share the same group will follow the state of master interface and will use same priority as master interface. This will ensure that all interfaces are in the same HSRP state. Otherwise there is a possibility of one or more interfaces to assume another role than the master HSRP interface.

This optimizes HSRP group number and hence minimizes the configuration and maintenance overhead when having large configurations.

It eliminates unnecessary network traffic over all interfaces by eliminating HSRP Hello messages from follow groups, if configured.

Do not configure a preemption delay on the Standby PDSN using the standby preempt interface configuration command.

When the standby use-bia command is not used to allow bridge and gateways to learn the virtual MAC address, for optimization purposes, configure the standby mac-refresh command to a value greater than the default (hello messages are sent every 10 seconds) under the main interface (gig0/0). This value is used as the hello message interval.


Note If standby use-bia is configured, no hello messages are sent out of the follow group interfaces. We recommended that you use the default virtual MAC address with HSRP unless explicitly required not to.


An ARP multicast packet is sent out when there is a HSRP state change to Active. ARP requests for follow group virtual IP address are responded if HSRP state is Active. Also an ARP multicast is sent on the follow group VLAN when a slave virtual IP address is configured and if the master group is Active.

Use the same group number for each PDSN follow group as is defined for the primary group. Using the same group number for the primary and follow groups facilitates HRSP group setup and maintenance in an environment that contains a large number of PDSN interfaces and HRSP groups.

More information on HSRP configuration and HSRP groups can be found here:

http://www.cisco.com/en/US/partner/tech/tk648/tk362/tk321/tsd_technology_support_sub-protocol_home.html

and

http://www.cisco.com/en/US/partner/tech/tk648/tk362/technologies_configuration_example09186a0080094e90.shtml

Enabling HSRP and Configuring an HSRP Master Group

To enable HSRP on an interface and configure the primary group, use the following commands in interface configuration mode:


Step 1 Router(config-if)# standby [group-number] ip [ip-address [secondary]]

Enables the HSRP on the interface.

Step 2 Router(config-if)# standby [group-number] priority priority

Set the Hot Standby priority used in choosing the active router. The priority value range is from 1 to 255, where 1 denotes the lowest priority and 255 denotes the highest priority. Specify that, if the local router has priority over the current active router, the local router should attempt to take its place as the active router.

Step 3 Router(config-if)# standby [group-number] name name

Specifies the name of the standby group.

Step 4 Router(config-if)# standby use-bia [scope interface]

(Optional) Configures HSRP to use the burned-in address of an interface as its virtual MAC address instead of the preassigned MAC address.


Configuring Follow Groups

HSRP follow groups are configured to share the HSRP parameters of the primary group by defining a follow group on the interface using the standby interface configuration command with the follow keyword option specified. Interfaces that share a group track states together and have the same priority.

To configure an interface to follow a primary group, use the following command in interface configuration mode:


Step 1 Router(config-if)# standby group-number follow group-name

Specifies the number of the follow group and the name of the primary group to follow and share status.


Note It is recommended that the group number specified is the same as the primary group number.


Step 2 Router(config-if)# standby group-number ip virtual-ip-address

Specifies the group number and virtual IP address of the follow group.


Note The group number specified above should be same as the master group number.



Enabling Inter-Device Redundancy

To enable inter-device redundancy, use the following commands beginning in global configuration mode.


Step 1 Router(config)# redundancy inter-device

Configures redundancy and enters inter-device configuration mode.

To remove all inter-device configuration, use the no form of the command.

Step 2 Router(config-red-interdevice)# scheme standby standby-group-name

Defines the redundancy scheme that is to be used. Currently, "standby" is the only supported scheme.

standby-group-name-Must match the standby name specified in the standby name interface configuration command (see the "Configuring HSRP" section). Also, the standby name should be the same on both PDSNs.

Step 3 Router(config-red-interdevice)# exit

Returns to global configuration mode.


Configuring the Inter-Device Communication Transport

Inter-device redundancy requires a transport for communication between the redundant PDSNs. This transport is configured using Interprocess Communication (IPC) commands.

To configure the inter-device communication transport between the two PDSNs, use the following commands beginning in global configuration mode:


Step 1 Router(config)# ipc zone default

Configures the Inter-device Communication Protocol (IPC) and enters IPC zone configuration mode.

Use this command to initiate the communication link between the Active device and the Standby device.

Step 2 Router(config-ipczone)# association 1

Configures an association between two devices and enters IPC association configuration mode.

In IPC association configuration mode, you configure the details of the association, such as the transport protocol, local port and local IP addresses, and the remote port and remote IP addresses.

Valid association IDs range from 1 to 255. There is no default value.

Step 3 Router(config-ipczone)# no shutdown

Restarts a disabled association and its associated transport protocol. Note Shutdown of the association is required for any changes to the transport protocol parameters.

Step 4 Router(config-ipczone-assoc)# protocol sctp

Configures Stream Control Transmission Protocol (SCTP) as the transport protocol for this association and enables SCTP protocol configuration mode.

Step 5 Router(config-ipc-protocol-sctp)# local-port local_port_num

Defines the local SCTP port number to use to communicate with the redundant peer and enables IPC Transport-SCTP local configuration mode.

Valid port numbers range from 1 to 65535. There is no default value.


Note The local port number should be the same as the remote port number on the peer router.


Step 6 Router(config-ipc-local-sctp)# local ip ip_addr

Defines the local IP address that is used to communicate with the redundant peer. The local IP address must match the remote IP address on the peer router.

Step 7 Router(config-ipc-local-sctp)# keepalive [period [retries]]

Enables keepalive packets and specifies the number of times that the Cisco IOS software tries to send keepalive packets with a response before bringing down the interface or tunnel protocol for a specific interface.

Valid value for period is an integer value in seconds great than 0. The default is 10. Valid value for retries is an integer value greater than one and less than 355. The default is the previously used value or 5 if there was no value previously specified.

Step 8 Router(config-ipc-local-sctp)# retransmit-timeout interval

Configures the message retransmission time. Valid range is 300 to 60000 milliseconds. The minimum default is 1000. The maximum default is 60000.

Step 9 Router(config-ipc-local-sctp)# path-retransmit number

Configures the maximum number of keep-alive retries before the corresponding destination address is marked inactive. Valid range is 2 to 10. The default is 5.

Step 10 Router(config-ipc-local-sctp)# assoc-retransmit number

Defines the maximum number of retransmissions over all destination addresses before an association is declared failed. Valid range is 2 to 20. The default is 10.

Step 11 Router(config-ipc-local-sctp)# exit

Exits IPC transport - SCTP local configuration mode.

Step 12 Router(config-ipc-protocol-sctp)# remote-port port_num

Defines the remote SCTP port that is used to communicate with the redundant peer and enables IPC Transport-SCTP remote configuration mode. Valid port numbers range from 1 to 65535. There is no default.


Note The remote port number should be the same as the local port number on the peer device.


Step 13 Router(config-ipc-remote-sctp)# remote-ip ip_addr

Defines the remote IP address of the redundant peer that is used to communicate with the local device. All remote IP addresses must refer to the same device. To remove an association configuration, use the no form of the command.


Using the Loopback Interface For the PDSN-AAA Server Interface

To ensure that the AAA server views the active and standby units as a single NAS, the same NAS IP address should be used by both the units. Now, the NAS IP Address can be configured for the PDSN using the ip radius source-interface command. When configured, the IP address of that interface is used as the NAS IP Address.

However, the command does not support virtual IP addresses (HSRP). As a result, the only way to ensure that both the units appear as a single NAS is to configure a loopback interface, and use that interface as the source-interface. In short, the CLI would look something like:

ip radius source-interface Loopback1

Configuring Application Tracking to Handle Active-Active Situation


Step 1 Router(config) # track object-id application pdsn

Defines a tracking object for PDSN application.

Step 2 Router(config-if) # standby track object-id [decrement priority]

Associates the tracking object defined for PDSN with the HSRP config. HSRP would start tracking the state of this object. The configured decrement priority is used to change the HSRP priority based on the state of the tracking object. If the tracking object is "UP", HSRP will have the configured priority. If the tracking object is "DOWN", HSRP decrements its priority by the decrement priority specified in the standby track command.


Note If preemption is configured, the priority value should be greater than the difference in priorities of the active and standby PDSNs



Protocol Layering and RP Connections

Each mobile station has a single PPP connection with the PDSN, and for each PPP connection there is a corresponding R-P connection between the PDSN and the Base Station/ PCF. R-P connection-related information is maintained for the duration of the PPP connection.

Additionally, the PPP connection and the associated HDLC, LCP, CCP and IPCP state information is also maintained for the duration of the packet data session. One Simple IP flow and several Mobile IP flows can be supported over a single PPP connection.


Note Closed RP is not supported in the Cisco PDSN Release 4.0.


Open RP Interface Connections

An R-P connection represents the logical tunnel between the PDSN and the Base Station/PCF. It enables bearer data for a PPP connection to be transported between the PDSN and the Base Station/PCF. R-P connection state information is maintained at the PDSN for the duration of the PPP connection. During handoff, the mobile station may connect the PDSN through another Base Station/PCF entity resulting in establishment of another R-P connection between the PDSN and the new Base Station/PCF. This results in the release of the R-P connection between the PDSN and the old Base Station/PCF.

R-P connection state information is maintained at the PDSN even during the dormant phase of the session. When a mobile station transitions to active state, this information allows the PDSN to associate the mobile station with an already available PPP connection. Loss of R-P state information results in the release of the PPP connection by the PDSN. As a result, a mobile station accessing packet data services following the loss of an R-P connection results in the establishment of a new PPP connection, and the reset and restart of user applications. Therefore, the PDSN retains the R-P connection state information to ensure minimal disruption of user applications during transitions between active and dormant session phases.

PPP Connections

A PPP connection represents the link layer connectivity between the mobile station and the PDSN. It includes the HDLC state, negotiated LCP parameters, negotiated IP address and CCP compression state tables, and so on. Peer PPP entities may re-negotiate LCP and CCP parameters during an active session without compromising continuity of user sessions; however, user identity, authentication-related information and negotiated IP addresses are retained, thus ensuring that applications established over the SimpleIP flow are unaware that renegotiation has occurred. PPP connection state information is retained at the PDSN during dormant phase of the session to ensure minimal disruption of user applications during transitions between active and dormant session phases.

Application Flows

One Simple IP and several Mobile IP flow instances can be supported over a single PPP connection. For each Simple IP flow, the state information includes the associated IP address, NAI and billing related user data records (UDRs), and other related information. For each Mobile IP flow, the state information includes the Mobile IP visitor list information, NAI and UDRs, and other related information.

PPPoGRE RP Interface

The PDSN interfaces with the Radio Network/Base Station to provide a transmission path for the user data stream between the packet network and the radio access network. The PDSN interfaces to the Radio Network through the Packet Control Function (PCF) using the PPPoGRE RP interface.

The following list describes the transmission path between the Radio Network and the PDSN:

The PDSN provides a media-independent physical link that supports IP packet transport capabilities.

The PPPoGRE RP Interface supports both the signaling channel and the bearer data transport capabilities.

The PPPoGRE RP interface is based on 3GPP2 TIA/EIA/IS-835 standard for the control and bearer data transport capabilities. The following list describes the differences between the 3GPP2 standard and PPPoGRE RP Interface from the PDSN perspective:

The PCF connecting the PDSN that supports PPPoGRE functionality sends the A11 Registration request with the GRE Protocol Type field set to 0x880B.

Neither the PDSN, nor the mobile node requires AHDLC framing or de-framing for the PPPoGRE sessions.

A10 bearer data packets are sent and received in the GRE Protocol field set to 0x880B (PPPoGRE).

A11 Session Update

This feature is based on Interoperability Specification (IOS) for cdma2000 Access Network Interfaces (Part 7 (A10 and A11 Interfaces) (3G-IOSv4.3) Version 2.0.1 Date: July 2003) and Interoperability Specification (IOS) for cdma2000 Access Network Interfaces (Part 3 Features (3G-IOSv4.3) Version 2.0.1 Date: July 2003 standard). An A11 Session Update message is sent from the PDSN to the PCF to add, change, or update session parameters for an A10 connection. The following parameters are sent from the PDSN to PCF in an A11 Session Update message in a session parameters NVSE extension with Application Type 08H (Session Parameter). These session parameters NVSE extension will also be sent by the PDSN in the A11 Registration Reply messages.

Radio Network Packet Data Inactivity Timer [01H]

Application Sub- Type 01H, the Application Data field contains the Radio Network Packet Data Inactivity Timer (RN-PDIT) value in seconds. This field is one octet in length and has range 01H-FFH, corresponding to timer values 1-255 seconds.

Supported for Service types Simple IP, Mobile IP, Proxy Mobile IP, MSID, and VPDN.

Always On Indicator [02H]

For Application Sub Type 02H ((Always-on indicator), the Application Data is zero bytes in length.

Supported for Service types Simple IP and MSID.

As per the standard cdma2000® Wireless IP Network Standard TIA-835-C, AUGUST 2003, the PDSN will download the Always On Indicator VSA and RN-PDIT VSA from the Radius server (Visited/Home RADIUS) during the authentication phase. If a user initiates multiple packet data sessions, the PDSN may receive more than one RN PDIT VSA from different home domains. In this case, the largest RN PDIT value received from different home domains is sent from the PDSN to the RN. This update may happen during an ongoing packet data session when the PDSN receives a new RN PDIT value that is greater than the one previously sent to the RN. For Handoff scenario the RN-PDIT and Always-On indicator are sent the PCF in the A11 Registration Reply if the Airlink is not dormant.

SDB Indicator Marking

This feature supports short data burst (SDB) applications, such as SIP signaling for PTT applications, and proposes the interaction with the PDSN. SIP is used by PTT applications to signal a PTT call. The message is short and needs to be delivered to the end-user. The Short Data Burst support on the RAN can be used to send these to the end-user, especially when the messages are to be terminated to the mobile. This is especially important when the mobile user is actually dormant.

The proposal consists of two parts:

Signalling of SDB indication, or other indications, on the GRE link between PDSN and PC.

Identification of data packet suitable for payloads.


Note SDB Marking is only supported for service type Simple IP.


Signaling of SDB Indication

The SDB indication is based on the 3GPP2 Proposal Contribution (Ericsson/SKT) A30-20030818-006, where one of the reserved bits in the GRE header is used to indicate the SDB packets from the PDSN for dormant sessions. The PDSN definition of dormancy is Airlink Stop record A11 Registration request is received from the PCF and A11 Registration success reply is sent by the PDSN.

The PDSN may set the B bit to "1" if the GRE frame contains an IP packet suitable for transmission over the air interface in a Data Burst Message. In the PCF-to-PDSN direction, and on the A8 interface, the B bit is set to "0".

Identification of Data Packets For SDB Indication

SDB indication is required for certain types of data only. Packets destined towards the mobiles that match the policy criteria will be chosen for SDB indication provided the mobile is in dormant mode

The local policy can be considered for an initial phase, if the selection of servers or signaling protocols is limited. For example, if there is only a single SIP server sending out SIP signaling message, a combination of port and source IP address may be used. In addition to this, the PDSN can also be configured with the min and max IP length.

On a Cisco PDSN, IOS MQC can be used to apply classification rules for matching packets that require SDB classification. For example, simple classification criteria can include port number, and source IP address range of the server. A more complex classification criterion can include a custom protocol inspection.

If packets pass the classification criteria and the user is dormant, the PDSN will signal SDB indication to the PCF.

To enable this feature, use the following command:

cdma pdsn compliance ios4.1 sdb

This command enables the PDSN to process an SDB record sent from PCF according to IOS4.1 Standard.

If deep classification is required for certain types of payloads such as RTP, or a custom application, IOS NBAR can be used for inspecting these packets. For a detailed description of how to configure IOS NBAR please refer to the documentation on NBAR.

A sample configuration for the classification function is shown here:

class-map match-all sdb-packets
     match packet length min 100 max 300
     match protocol <protocol>
     match access-group <access-group-number>
ip access-list <access-group-number> permit ip 192.0.2.0 0.0.0.255 any   

(This example of access-list allows matching of a certain protocol from servers whose address range is 192.0.2.0/24)

The protocol and the access-group can be set to match the desired packet stream. The match criteria can also include a custom protocol inspection such as

ip nbar custom media_new 8 hex 0x60 dest udp 3001

The above statement classifies all packets with a UDP destination of port 3001, and contains the value 0x60 at offset 8. The protocol media_new can now be used in the match protocol protocol statement.

policy-map sdb-policy
     class sdb-packets
     set qos-group group-number

The policy map is then applied to the input interface. The group-number represents the classified match criteria. All packets that are set with the specific group-number will be flagged for SDB usage between the PCF and the PDSN. This is done with the following command:

cdma pdsn a11 dormant sdb-indication gre-flags group-number

The B bit (SDB indication) would be set for packets matching the sdb-indication group-number.

SDB Indicator Marking for PPP Control Packets

While data packets can be sent towards the mobile using SDBs as shown above, SDBs can also be used for delivering PPP control packets. This can be particularly helpful for Always-On sessions, where the session is dormant. Basically, with Always On configured, the PDSN sends out LCP echo requests (and waits for LCP echo replies) to keep the session alive. Hence, when such a session goes dormant, a data channel needs to be setup to deliver these LCP echo requests to the MN. The other option is to use SDBs to deliver the LCP echo requests without setting up a data channel.

Configure the following CLI along with the above CLIs to enable this feature:

cdma pdsn a11 dormant sdb-indication match-qos-group group-number ppp-ctrl-pkts

Multiple Service Connections

The PDSN currently maintains one A10 connection and an associated session, and supports multiple flows (one simple IP and multiple Mobile IP flows). In this new implementation, the term "Service connection" indicates an A10 connection as defined in IS-835-D. All A10 service connections for a given MS are associated with a single A10 session. The series of packets that share a specific instance of IETF protocol layers are called "IP flows". Multiple IP flows may use a single service connection. Currently, there is one main service instance only, and all simple IP and mobile IP flows use that single service instance. IP Flows on different flows (SIP/MIP) can be spread across different A10s.

Each A10 connection can support multiple IP flows, as indicated by the RAN in A11 messaging. The TFTs signaled by the MS indicate which applications are mapped to which IP flow.

The mapping of an IP flow to the A10 session is sent by the PCF. Each IP flow is identified using a Flow ID.

PDSN Release 4.0 will support maximum of 25000 sessions with 2 auxiliary A10s and 2 IP flows per direction per auxiliary A10s.

Session Creation—A11 Registration Request

Connection Establishment Call Flow

The PCF sends the initial A11 Registration Request with Service Option 59 for the main service connection. This SR ID is always the main service instance in the A11 Registration Request. This service flow is the default A10 connection, and is used by the Application Flows with ID FFH for both forward and reverse directions. When a MN needs multiple flows, the PCF sends out an A11 Registration Request with non-zero lifetime including Additional Session Information NVSE (which contains details of additional A10 connections to be created). The current implementation supports only SO 64, and not SO 67. Auxiliary connection SO 64 requires PPPoAHDLC.

The RRQ contains the R_QOS_SUBBLOB along with the Additional Session Info (GRE Key info), which provides the mapping of A10 to Flow IDs.

All PPP negotiations happen over the main service connection.

A11 Registration Reply

PDSN sends out a Registration Reply based on the Request received with non-zero lifetime from PCF. On receiving a valid A11 registration request, the PDSN creates the requested A10 connections and acknowledges them to the PCF. If any auxiliary connection is new in the A11 request, then a new A10 connection is created. If the information of any auxiliary connection present on the PDSN is missing in the A11 registration request, then that A10 connection is deleted from the PDSN. If any of the auxiliary connections failed to be created on the PDSN, the PDSN responds with Insufficient Resources.

Each A10 connection is created based on the GRE key in the Additional Session Information NVSE (Application Type 0CH). The application flows defined in the QoS NVSE (Application Type 0DH) (Forward and Reverse) are linked to the corresponding A10 connection based (GRE info NVSE) on SR ID. This Registration Reply also includes the Subscriber QoS policy during authentication (when attributes are downloaded from AAA during authentication), and dormant handoff.

Whenever additional session info contains SO other than 64, it is rejected with 8BH (Registration Denied - service option not supported).

Whenever mapping of Flow to A10 is received but SRID does not exist, it is rejected with 8EH (Registration Denied - nonexistent A10 or IP flow).

Session Refresh

All A11 Re-registrations (A11 Registration request with non-zero lifetime) contain all the A10 connections in the Additional Session NVSE that exist after this re-registration. If there are additional A10 connections in the Additional Session NVSE, they are created. A10 connections that already existed but are absent in the request are released.

During re-registration, it is possible for the mapping of flow IDs to A10 to change. A MN and a PCF might renegotiate the mapping and forward the same to the PDSN. The PDSN accordingly remaps the flow ID to the newly mapped A10.

Session Deletion

In order to release all the connections from the PCF, an A11 Registration Request is sent by the PCF with a lifetime value of zero. Releasing the main service connection releases all of its auxiliary connections as well.

When the PDSN wants to terminate the session, an A11 Registration Update is sent. This occurs when all of the connections need to be brought down. The PDSN cannot initiate a release of a particular connection. There is no change in the packet format of this message. The SRID is always filled with one for HRPD sessions.

A11 Session Update

An A11 Session Update is used to pass on the newly downloaded or updated subscriber QoS Profile to the PCF. The PDSN does not include the QoS Update information as the PDSN does not update the QoS information.

When configured, an A11 Session Update is sent when at least one of the subscriber QoS attributes is downloaded during authentication. During handoff the attributes are sent in a RRP except when the session is dormant. When the session is dormant, a Session-update is sent when the session becomes active.

Configuring Multiple Service Connections

To configure the Multiple Service Connections feature on the PDSN, perform the following tasks:

 
Command
Purpose

Step 1 

router# cdma pdsn multiple service-flows [maximum number]

This new CLI enables the Multiple flow support feature. The maximum number defines the maximum number of auxiliary A10s that can be created between PDSN and PCF. The default number of auxiliary A10s allowed is 7.

Example

Here is a sample configuration:

router#cdma pdsn multiple service-flows ?
        maximum  Maximum limit
        qos      Configure qos parameters
        <cr>

router# cdma pdsn multiple service-flows
router# cdma pdsn multiple service-flows maximum 8

Verifying the Configuration

To verify that the Multiple Service Connections feature is enabled on the PDSN, perform the following tasks:

 
Command
Purpose

Step 1 

router# Show cdma pdsn

In PDSN release 4.0, the show output is enhanced to display the following information:

The Multiple service flow feature is enabled, or not.

Maximum Number of auxiliary A10s allowed.

Number of sessions active with service flows.

Total number of service flows currently active in the system.

Step 2 

router# show cdma pdsn session [{service-flows | detail}]

In PDSN release 4.0, the output is enhanced to display the following information:

New service flow details.

New IP flow details for both forward and reverse directions.

Step 3 

router# Show cdma pdsn statistics

In PDSN release 4.0, new counters are introduced to display the following information:

The number of requests (both new requests and re-registration requests) that contained Additional Session Information NVSE and QoS Information NVSE

New reject reasons for requests containing auxiliary connection details like Unsupported Service Option, Non-existing A10.

The number of missing connections and the number of remapping flows.

Step 4 

router# show cdma pdsn session brief

In PDSN release 4.0, a new column is introduced to display the number of service flows for the session.

Step 5 

router# Show cdma pdsn pcf

In PDSN release 4.0, new counters are introduced to display the number of auxiliary A10s that exist.

Step 6 

router# Show cdma pdsn pcf brief

In PDSN release 4.0, a new column is introduced to display the number of auxiliary A10s currently existing on the PCF.

Examples

Here is an example for Cisco PDSN Release 4.0:

router# show cdma pdsn
PDSN software version 4.0, service is enabled

  A11 registration-update timeout 1 sec, retransmissions 5
  A11 session-update timeout 3 sec, retransmissions 3
  Mobile IP registration timeout 300 sec
  A10 maximum lifetime allowed 65535 sec
  GRE sequencing is on
  Maximum PCFs limit not set
  Maximum sessions limit set to 10 (default 9950 maximum)
  SNMP failure history table size 100
  MSID Authentication is disabled
  Ingress address filtering is disabled
  Sending Agent Adv in case of IPCP Address Negotiation  is enabled
  Allow CI_ADD option during IPCP Phase  is disabled
  Aging of idle users disabled
  Radius Disconnect Capability disabled
  Multiple Service flows enabled
  Maximum number of service-flows per MN allowed is 8
  Call Admission Control enabled
  Police Downstream enabled

  Number of pcfs connected 1,
  Number of pcfs 3GPP2-RP 1,
  Number of sessions connected 1,
  Number of sessions 3GPP2-RP 1,
  Number of sessions Active 1, Dormant 0, 
  Number of sessions using HDLCoGRE 1, using PPPoGRE 0
  Number of sessions using Auxconnections 1, using Policing 1, using DSCP 1
  Number of service flows 1
    Simple IP flows 1, Mobile IP flows 0,

Proxy Mobile IP flows 0, VPDN flows 0

Here is another example with information about service flows and session details:

router#show cdm pds session service-flows

Mobile Station ID IMSI 09884708942
PCF IP Address 2.2.2.4, PCF Session ID 1

  GRE protocol type is 0x8881
  GRE sequence number transmit 17, receive 0
  Using interface Virtual-Access2.1
  Using AHDLC engine on slot 0, channel ID 1
  Service Option EV-DO Flow Discrimination 0 DSCP Included 0
  Flow Count forward 0 reverse 0
  This session has 1 flow
  This session has 1 service flow

  Service Flow PCF IP Address 2.2.2.4 SR ID 0x2 
    Service Option 0x40 Flow Discrimination 0 DSCP Included 0
    Flow Count forward 2 reverse 2
    GRE protocol type is 0x8881, key 2
    GRE sequence number transmit 0, receive 0
    Using AHDLC engine on slot 0, channel ID 0

Here is an example output for the show cdma pdsn statistics command for PDSN Release 4.0:

router# show cdma pdsn statistics
Last clearing of "show cdma pdsn statistics" counters never
RP Interface:
  Reg Request rcvd 1524, accepted 1405, denied 2, discarded 117
  Initial Reg Request rcvd 18, accepted 17, denied 1, discarded 0, AuxRequest 1
  Re-registration requests rcvd 1380, accepted 1374, denied 0, discarded 6
Re-registration requests containing Active-Start 15, Active-Stop 16, updated QoS Blob 5
Re-registration requests containing new connections 10, missing connections 12, remapping 
flows 1 

 Handoff requests rcvd 2, accepted 2, denied 0, discarded 0, AuxRequest 1 
  De-registration rcvd 13, accepted 12, denied 1, discarded 0
  De-registration Reg Request with Active-Stop 9
  Registration Request Errors:
    Unspecified 0, Administratively prohibited 0
    Resource unavailable 0, Authentication failed 0
    Identification mismatch 1, Poorly formed requests 1
    Unknown PDSN 0, Reverse tunnel mandatory 0
    Reverse tunnel unavailable 0, Bad CVSE 0
    Max Service Flows 0, Unsupported SO 0, Non-existent A10 0,
    Bandwidth unavailable 0

  Update sent 52, accepted 9, denied 8, not acked 35
  Initial Update sent 14, retransmissions 38
  Acknowledge received 17, discarded 0
  Update reason lifetime expiry 0, PPP termination 11, other 3
  Registration Update Errors:
    Unspecified 0, Identification mismatch 8
    Authentication failed 0, Administratively prohibited 0
    Poorly formed request 0

  Handoff statistics:
    Inter PCF handoff active 2, dormant 0
    Update sent 5, accepted 2, denied 2, not acked 1
    Initial Update sent 2, retransmissions 3
    Acknowledge received 4, discarded 0
    De-registration accepted 2, denied 0
  Handoff Update Errors:
    Unspecified 0, Identification mismatch 2
    Authentication failed 0, Administratively prohibited 0
    Poorly formed request 0

  RP Session Update statistics:
  Update sent 0, accepted 0, denied 0, not acked 0
  Initial Update sent 0, retransmissions 0
  Acknowledge received 0, discarded 0
  Sent reasons Always On 0, RN-PDIT 0, Subscriber QoS 0
  RP Session Update Errors:
    Unspecified 0, Identification mismatch 0
    Authentication failed 0, Session parameters not updated 0
    Poorly formed request 0

  Service Option:
    Unknown (0) success 1405, failure 2
 

PPP:
  Current Connections 0
  Connection requests 17, success 17, failure 0, aborted 0
  Connection enters stage LCP 17, Auth 6, IPCP 13
  Connection success LCP 17, AUTH 6, IPCP 13
  Failure reason LCP 0, authentication 0, IPCP 0, other 0
  Failure reason lower layer disconnect 0

  A10 release before LCP nego by PDSN 0, by PCF 0

  LCP Stage
    Failure Reasons Options 0, MaxRetry 0, Unknown 0
    LCP Term Req during LCP nego sent 0, rcvd 0
    A10 release during LCP nego by PDSN 0, by PCF 0

  Auth Stage
    CHAP attempt 2, success 2, failure 0, timeout 0
    PAP attempt 4, success 4, failure 0, timeout 0
    MSCHAP attempt 0, success 0, failure 0, timeout 0
    EAP attempt 0, success 0, failure 0
    MSID attempt 0, success 0, failure 0
    AAA timeouts 0, Auth timeouts 0, Auth skipped 11
    LCP Term Req during Auth nego sent 0, rcvd 0
    A10 release during Auth nego by PDSN 0, by PCF 0

  IPCP Stage
    Failure Reasons Options 0, MaxRetry 0, Unknown 0
    Options failure reason MN Rejected IP Address 0
    LCP Term Req during IPCP nego sent 0, rcvd 0
    A10 release during IPCP nego by PDSN 0, by PCF 0

  CCP Stage
    Connection negotiated compression 0
    Compression type Microsoft 0, Stac 0, other 0
    Connections negotiated MRRU 0, IPX 0, IP 13
    Connections negotiated VJ-Compression 0, BAP 0
    PPP bundles 0
    Connections failed to negotiate compression 0

  Renegotiation total 0, by PDSN 0, by Mobile Node 0
  Renegotiation success 0, failure 0, aborted 0
  Renegotiation reason: address mismatch 0, lower layer handoff 0
    GRE key change 0, other 0

  Release total 16, by PDSN 14, by Mobile Node 2
  Release by ingress address filtering 0
  Release reason: administrative 4, LCP termination 2
    Idle timeout 3, echo missed 0
    L2TP tunnel 0, insufficient resources 0
    Session timeout 0, service unavailable 0
    De-Reg from PCF 0, lifetime expiry 0, other 7

  Echo stats
    Request sent 0, resent 0, max retransmit timeout 0
    Response rcvd 0


  Discarded Packets
    Unknown Protocol Errors 424, Bad Packet Length 0

RSVP 
IEs Parsed 0
  TFTs Created Success 0, Failure 0
  TFTs Updated Success 0, Failure 0
TFTs Deleted Sucesss 0, Failure 0

Other Failure 0
    Unknown 0, Unsupported Ie types 0
  Tft Ipv4 Failure Stats
    Tft Unauthorized 0, Unsuccessful Processing 0
    Tft Treatment Unsupported 0, Persistency reached 0
    Packet Filter Add 0, Replace 0
    Packet Filter Precedence Contention 0, Unavailable 0
    Packet Filter Maximum Limit 0, Non-Existent Tft add 0

QoS:
   Total Profile Download Success 10, Failure 10,
   Local Profile selected 4
   	Failure Reason DSCP 1, Flow Profile ID 1, 
   Service Option Profile 1, Others 1
   Total Consolidated Profile 4, DSCP Remarked 0 
   Total Policing installed 4, failure 5, removed 4

slot 0:
  AHDLC Engine Type: CDMA HDLC SW ENGINE
     Engine is ENABLED
    total channels: 20000, available channels: 20000


  Framing input 5306 bytes, 169 paks
  Framing output 7008 bytes, 169 paks
  Framing errors 0, insufficient memory 0, queue overflow 0
        Invalid size 0


  Deframing input 1371683974 bytes, 4005798483 paks
  Defaming output 4948 bytes, 142 paks
  Deframing errors 0, insufficient memory 0, queue overflow 0
        Invalid size 64, CRC errors 117817589


RADIUS DISCONNECT:
  Disconnect Request rcvd 0, accepted 0
  Disconnect Request Errors:
    Unsupported Attribute 0, Missing Attribute 0
    Invalid Request 0, NAS Id Mismatch 0
    Session Cxt Not Found 0, Administratively Prohibited 0

Data Plane

Downstream or Forward Packet Processing

When a packet is received in the forward direction at the PDSN, flow accounting occurs. At this point, the PDSN first identifies the TFT that can be applied based on the destination IP Address. The packet is then run through the packet filters to identify the application flow. The A11 RRQ contains the mapping of the application flows to the service flow. With that mapping, the service flow is identified and the packet is marked with the A10 connection information. If the packet is a PPP control packets, the packet is marked with main A10 connection. When the packet later completes AHDLC encapsulation after PPP encapsulation, the corresponding A10 connection is selected and forwarded to the tunnel.

In the A11 RRQ, more specifically in the QoS Update, the PCF may specify to use flow discrimination. This means that all bearer packets will contain the flow ID that is encoded in the 3GPP2 header extension for GRE.

Upstream or Reverse Packet Processing

When a packet is received in the reverse direction, after the PPP encapsulation is removed, the packet is picked up by the PDSN for flow accounting. The packet is first evaluated for the DSCP and actions are taken accordingly. If the packet can then be forwarded, the packet is passed through the TFT (which has the packet filters to identify the flow ID). If packet has the "IP flow" details in the GRE header, the packet is directly accounted for that flow ID, and not passed through TFT. Once the flow is identified, accounting is performed and then forwarded. If there is no packet filter to identify a flow, the default flow ID FF is assumed.

QoS Signaling

This section discusses Quality of Service Signaling (QoS), and involves the following concepts:

Handling of Traffic Flow Templates

Handling of RSVP messages that carry the TFT message.

Handling of TFT—parsing and installation of packet filters.

Handling of Subscriber QoS Profile

Downloading the subscriber QoS profile, or using the locally configured subscriber QoS profile.

Applying the subscriber QoS profile to the session or flow.

Handling of data traffic

Using the TFT, the IP Flow is identified and accounted.

Policing the data traffic, if requested, based on Maximum Aggregate Bandwidth.

Applying DSCP marking on the packets in both directions based on the profile applied.

Traffic Flow Templates (TFT)

Traffic Flow Templates define the IP Flows. The TFT contains a set of packet filters that define each IP flows. An IP flow can carry multiple application flows. Each application flow is identified using packet filters.

The MN determines the flows and sends the packet filters in a TFT as a RSVP message. The RSVP message contains a 3GPP2 object that defines the TFT. There could be only one 3GPP2 object with multiple TFTs sent in one RSVP Message. In HRPD there is only one persistent TFT per MS IP Address. The TFT describes the flow, the packet filters, and the packet treatments. The MN sends 1 TFT per IP address per flow direction. These packet filters are associated with a precedence level. The packet filters are sorted and associated with the session. The flow IDs (which are the IP flow IDs) in these packet filters are matched with the IP flow IDs mentioned in the A11 RRQ to determine the corresponding A10 connection to use. If there is no mapping, the PDSN forwards the packet through the main service instance (which is the default A10 and has a flow ID FF).

In this case, RSVP messages are accounted as data traffic on the session.

Other Considerations

An HRPD MS only uses Non-Specific TFTs in both the forward and reverse directions.

Each TFT IE contains one or more packet filters that are matched against forward or reverse directions. The PDSN supports 255 packet filters per direction per TFT.

During PPP renegotiation, all of the connection details (like TFTs) are released and reestablished when a fresh request comes for the same.

Packet Filters

Packet filters describe an IP flow for a particular direction. Packet filters contain sub-type PF0 and PF1. PF0 implies the filter is applied on the Outer IP Header and PF1 implies the filter is applied on the extended headers or transport headers. The initial support on PDSN is only for IPv4 addresses/Port/ToS/Protocol. The only protocol supported in the initial phase is IP and GRE. Each packet filter is associated with a precedence level. When a packet (during data traffic) is given to this TFT to identify the ip flow, the packet is passed through these filters in their order of precedence.

TFT Installation

When a fresh TFT needs to be installed, the MS sends a TFT with "Create new TFT" attached. The following TFTs are marked with appropriate actions like "Add packet filter to existing TFT", "Delete existing TFT", "Replace packet filters in existing TFT", or "Delete packet filters from existing TFT".

The PDSN replies affirmatively if the TFT is parsed properly and installed successfully.

The PDSN reports one of the following errors depending on the scenario it encountered:

Table 8 TFT Error Messages 

Packet filter add failure

PDSN could not add the requested packet filter due to any reason.

Packet filter unavailable

MS attempted to replace or delete packet filter(s) that is/are not installed in the PDSN.

Unsuccessful TFT processing

PDSN could not parse the TFT for any reason, e.g., poorly formatted TFT.

Channel not available

MS attempted to installed a non-persistent TFT (P=0) when the corresponding A10 is not established.

Evaluation precedence contention

Contention in the evaluation precedence value detected.

Treatment not Supported

The MS included a flow or channel treatment value that is not supported by the PDSN.

Packet filter replace failure

The packet filter replace request has some unknown error.

Unauthorized TFT

The MS attempted to install TFTs with a non-authorized IP address in the MSIP address field.

Max number of Packet Filters for the TFT has been reached

The MS attempted to install more than 255 packet filters for the TFT in any direction.

Attempted to add Packet Filters to non

The MS attempted to add packet filters to a TFT before creating the TFT.


The PDSN processes the request in order of the IEs that are present in the 3GPP2 OBJECT. If processing of all the IEs is successful, the PDSN returns a ResvConf message containing the MS IP address. If processing of an IE fails, the PDSN stops further processing of the Resv message. The PDSN returns a ResvErr message to the MS including the error code and the index of the IE that failed processing. The TFT IE index starts from 1. If processing of an IE fails, the PDSN stops further processing of the Resv message but retains the result of any actions already performed on earlier IEs in the message.

TFT Update

The MS can update the TFT at any point of time. It might do so when there is any change in the packet filter content, or change of MS IP Address.

Since a TFT is associated with a MS based on its IP Address, when there is a change of MS IP Address, the MS sends RSVP messages to delete the old and create a new TFT for the new IP address.

TFTs for a session will be deleted only when either the MS sends a delete TFT message, the session goes down, or during PPP renegotiation.

Configuring TFTs

To configure the PDSN to include the Traffic Flow Template error extensions, perform the following tasks:

 
Command
Purpose

Step 1 

router# cdma pdsn tft reject include error extension

Configure this CLI to include the error extension in the reject message whenever a TFT is rejected.

Example

Here is an example of the cdma pdsn tft reject include error extension command:

cdma pdsn tft ?
  reject     Configure CDMA PDSN TFT reject
 
cdma pdsn tft reject ?
  include    Configure CDMA PDSN TFT reject include
 
cdma pdsn tft reject include ?
  error      Configure CDMA PDSN TFT reject include error
 
cdma pdsn tft reject include error ?
  extension  Configure CDMA PDSN TFT reject include error extension
 

cdma pdsn tft reject include error extension ?

Verifying the Configuration

To verify that the TFT feature is enabled, and to gather information about those TFTs, perform the following tasks:

 
Command
Purpose

Step 1 

router# show cdma pdsn session {qos|tft|detail}

In PDSN Release 4.0, the show cdma pdsn session command adds extensions that display the following information:

the Subscriber QoS profile

TFTs installed for the session in addition to the existing details

Step 2 

router# show cdma pdsn statistics



router# show cdma pdsn statistics tft

In PDSN Release 4.0, new counters are introduced to display the following information:

Number of TFTs parsed successfully or failed.

New counters to identify the TFT parsing failure reasons.

Number of Subscriber QoS Profile downloaded from AAA or locally installed.

Consolidation of subscriber QoS profile.

Policing installed or uninstalled.

Packets for which the DSCP was remarked based on policy installed.

Step 3 

router#show cdma pdsn redundancy

In PDSN Release 4.0, this command output is enhanced to show the details of the number of TFTs synced to standby.

Example

Here are some configuration examples:

router#show cdma pdsn session tft
Mobile Station ID IMSI 123456789011122
  PCF IP Address 10.1.1.1, PCF Session ID 1
  This session has 1 flow
  This session has 1 Tft
  TFT IP Address 3.1.1.1
  Number of Packet Filters Forward 2, Reverse 1
  Forward Packet Filters
    Packet Filter 1
    Flow Id 10, Precedence 255, PF Type 0
    Source Port 125

    Packet Filter 2
    Flow Id 10, Precedence 255, PF Type 0
    Source Port 125
         
  Reverse Packet Filters
    Packet Filter 1
    Flow Id 10, Precedence 10, PF Type 0
    Source Port 125

Mobile Station ID IMSI 123456789011123
  PCF IP Address 10.1.1.1, PCF Session ID 2
  This session has 1 flow
  This session has 1 Tft

  TFT 
  IP Address 3.1.1.2
  Number of Packet Filters Forward 2, Reverse 3
  Forward Packet Filters
    Packet Filter 1
    Flow Id 2, Precedence 2, PF Type 0
    Source Ip 5.5.5.5 Mask 255.255.255.0

    Packet Filter 2
    Flow Id 5, Precedence 5, PF Type 0
    Source Ip 1.1.1.1 Mask 255.255.255.0

  Reverse Packet Filters
    Packet Filter 1
    Flow Id 10, Precedence 255, PF Type 0
    Source Port 125

    Packet Filter 2
    Flow Id 10, Precedence 255, PF Type 0
    Source Port 125

    Packet Filter 3
    Flow Id 10, Precedence 255, PF Type 0
    Source Port 125

router#show cdma pdsn statistics
Last clearing of "show cdma pdsn statistics" counters never
RP Interface:
  Reg Request rcvd 1524, accepted 1405, denied 2, discarded 117
  Initial Reg Request rcvd 18, accepted 17, denied 1, discarded 0, AuxRequest 1
  Re-registration requests rcvd 1380, accepted 1374, denied 0, discarded 6
Re-registration requests containing Active-Start 15, Active-Stop 16, updated QoS Blob 5
Re-registration requests containing new connections 10, missing connections 12
  Handoff requests rcvd 2, accepted 2, denied 0, discarded 0, remapping flows 1
  De-registration rcvd 13, accepted 12, denied 1, discarded 0
  De-registration Reg Request with Active-Stop 9
  Registration Request Errors:
    Unspecified 0, Administratively prohibited 0
    Resource unavailable 0, Authentication failed 0
    Identification mismatch 1, Poorly formed requests 1
    Unknown PDSN 0, Reverse tunnel mandatory 0
    Reverse tunnel unavailable 0, Bad CVSE 0
    Max Service Flows 0, Unsupported SO 0, Non-existent A10 0,
    Bandwidth unavailable 0
 
  Update sent 52, accepted 9, denied 8, not acked 35
  Initial Update sent 14, retransmissions 38
  Acknowledge received 17, discarded 0
  Update reason lifetime expiry 0, PPP termination 11, other 3
  Registration Update Errors:
    Unspecified 0, Identification mismatch 8
    Authentication failed 0, Administratively prohibited 0
    Poorly formed request 0
 
  Handoff statistics:
    Inter PCF handoff active 2, dormant 0
    Update sent 5, accepted 2, denied 2, not acked 1
    Initial Update sent 2, retransmissions 3
    Acknowledge received 4, discarded 0
    De-registration accepted 2, denied 0
  Handoff Update Errors:
    Unspecified 0, Identification mismatch 2
    Authentication failed 0, Administratively prohibited 0
    Poorly formed request 0
 
  RP Session Update statistics:
  Update sent 0, accepted 0, denied 0, not acked 0
  Initial Update sent 0, retransmissions 0
  Acknowledge received 0, discarded 0
  Sent reasons Always On 0, RN-PDIT 0, Subscriber QoS 0
  RP Session Update Errors:
    Unspecified 0, Identification mismatch 0
    Authentication failed 0, Session parameters not updated 0
    Poorly formed request 0
 
  Service Option:
    Unknown (0) success 1405, failure 2
 
PPP:
  Current Connections 0
  Connection requests 17, success 17, failure 0, aborted 0
  Connection enters stage LCP 17, Auth 6, IPCP 13
  Connection success LCP 17, AUTH 6, IPCP 13
  Failure reason LCP 0, authentication 0, IPCP 0, other 0
  Failure reason lower layer disconnect 0
 
  A10 release before LCP nego by PDSN 0, by PCF 0
 
  LCP Stage
    Failure Reasons Options 0, MaxRetry 0, Unknown 0
    LCP Term Req during LCP nego sent 0, rcvd 0
    A10 release during LCP nego by PDSN 0, by PCF 0
 
  Auth Stage
    CHAP attempt 2, success 2, failure 0, timeout 0
    PAP attempt 4, success 4, failure 0, timeout 0
    MSCHAP attempt 0, success 0, failure 0, timeout 0
    EAP attempt 0, success 0, failure 0
    MSID attempt 0, success 0, failure 0
    AAA timeouts 0, Auth timeouts 0, Auth skipped 11
    LCP Term Req during Auth nego sent 0, rcvd 0
    A10 release during Auth nego by PDSN 0, by PCF 0
 
  IPCP Stage
    Failure Reasons Options 0, MaxRetry 0, Unknown 0
    Options failure reason MN Rejected IP Address 0
    LCP Term Req during IPCP nego sent 0, rcvd 0
    A10 release during IPCP nego by PDSN 0, by PCF 0
 
  CCP Stage
    Connection negotiated compression 0
    Compression type Microsoft 0, Stac 0, other 0
    Connections negotiated MRRU 0, IPX 0, IP 13
    Connections negotiated VJ-Compression 0, BAP 0
    PPP bundles 0
    Connections failed to negotiate compression 0
 
  Renegotiation total 0, by PDSN 0, by Mobile Node 0
  Renegotiation success 0, failure 0, aborted 0
  Renegotiation reason: address mismatch 0, lower layer handoff 0
    GRE key change 0, other 0
          
  Release total 16, by PDSN 14, by Mobile Node 2
  Release by ingress address filtering 0
  Release reason: administrative 4, LCP termination 2
    Idle timeout 3, echo missed 0
    L2TP tunnel 0, insufficient resources 0
    Session timeout 0, service unavailable 0
    De-Reg from PCF 0, lifetime expiry 0, other 7
 
  Echo stats
    Request sent 0, resent 0, max retransmit timeout 0
    Response rcvd 0
 
  Discarded Packets
    Unknown Protocol Errors 424, Bad Packet Length 0
 
RSVP                                           
  TFTs Parsed 0
  TFTs Created Success 0, Failure 0
  TFTs Updated Success 0, Failure 0
  TFTs Deleted Sucesss 0, Failure 0
  TFT Failure Stats
    Tft Unauthorized 0, Unsuccessful Parsing 0
    Tft Treatment Unsupported 0, Persistency reached 0
    Packet Filter Add 0, Replace 0
    Packet Filter Precedence Contention 0, Unavailable 0
    Packet Filter Maximum Limit 0, Non-Existent Tft add 0


router#show cdma pdsn redundancy
CDMA PDSN Redundancy is enabled

CDMA PDSN Session Redundancy system status
  PDSN state = ACTIVE
  PDSN-peer state = STANDBY HOT

CDMA PDSN Session Redundancy Statistics
  Last clearing of cumulative counters never
                Synced to standby        Current
                  since peer up         Connected
  Sessions                0                   0
  SIP Flows               0                   0
  MIP Flows               0                   0
  PMIP Flows              0                   0
  TFT                     0                   0

Subscriber QoS Policy

While establishing a session with PDSN, during authentication Subscriber QoS attributes are downloaded from AAA. The following are the attributes downloaded from AAA as part of Subscriber QoS Profile:

The Allowed Differentiated Services Markings.

The Allowed Number of Persistent TFTs.

The Maximum Authorized Aggregate Bandwidth for Best-Effort Traffic.

The Authorized Flow Profile IDs for each direction.

The Maximum per Flow Priority.

The Service Option Profile.

The Inter-User Priority for best effort traffic.

The Maximum Authorized Aggregate Bandwidth is used for policing and bandwidth allocation on the PDSN.

The first two items in the above list are used by the PDSN for authorizing and applying on the bearer traffic. The remaining five attributes are stored and forwarded to the PCF as part of A11 Registration Reply and A11 Session-Update.

If different profiles are downloaded for a MN with single NAI, the profile in the PDSN is updated.

If there are multiple NAIs per MN, multiple versions of the above attributes will be received. The PDSN consolidates the attributes and forwards them to the PCF. This consolidation process provides the following details:

The total set of all allowed service options

The maximum of the maximum number of service instances

The total set of all allowed Authorized Flow Profile IDs.

The maximum of the Maximum Authorized Aggregate Bandwidth for Best-Effort Traffic.

The maximum of the maximum per Flow priority.

The maximum of the Inter-User priority for best effort traffic.

When the Subscriber QoS Profile is not downloaded from AAA, the locally configured QoS Profile is applied.

Allowed Differentiated Services Marking

The Allowed Differentiated Services Marking attribute consists of three subtypes

A,E,O Bit flags

Max-class

RT Marking

The MS may mark the packet and send the traffic. The PDSN monitors it and checks if the marked value is within the allowed marking. If packets contain DSCP greater than the allowed value, the PDSN may remark those packets if a remark DSCP is configured. If this remark DSCP is not configured, the packet is forwarded using best-effort DSCP.

The PDSN validates the DSCP in the following ways:

If max-class is configured, considering all the defined classes are in the ascending order (AF list, EF and Selector Class, in that order), the PDSN checks if the DSCP in the packet is within the range of Max-class.

If max-class is not present and the A, E, and O bit flags are present, the PDSN checks the DSCP according to the bits set.

If both max-class and bit flags are not present, the PDSN remarks it with default class.

If RT marking is set in the attribute, the packets that are reverse tunneled are also marked with the locally configured value.

Allowed Number of Persistent TFTs

In HRPD, there can be only one persistent TFT per MS IP Address. This attribute is not forwarded to the PCF.

If the number of persistent TFT attributes is not downloaded or configured locally, the TFT is rejected with "Unsuccessful TFT Processing" error.

Maximum Authorized Aggregate Bandwidth

Maximum Authorized Aggregate Bandwidth is used for downstream policing. This value is considered as the guaranteed bandwidth for the mobile for the session. It is forwarded to PCF.

Configuring the Subscriber QoS Profile

To configure the Subscriber QoS Profile feature on the PDSN, perform the following tasks:

 
Command
Purpose

Step 1 

router# cdma pdsn multiple service-flows qos subscriber profile

This CLI enables you to configure the local subscriber qos profile. This profile will be used for a MN when Subscriber QoS profile is not downloaded from AAA

Step 2 

router# cdma pdsn multiple service-flows qos remark-dscp value

This CLI enables you to configure the DSCP remark value used for marking when the data packets from the mobile towards the internet are determined to have a DSCP not within the allowed dscp value for that mobile.

Configuring the cdma pdsn multiple service flows qos subscriber profile takes you to a submode. The following commands are available to configure various parameters in local subscriber qos profile:

 
Command
Purpose

Step 1 

router# cdma pdsn multiple service-flows qos subscriber profile


Bandwidth <number>


inter-user-priority <value>


tft-allowed <value>




link-flow <value>






service-option <value>



flow-priority <value>



flow-profile direction {forward| reverse| bi-direction} flow-id flow-id



dscp {allowed-class {AF|EF|O} | max-class value| reverse-marking value}

Configures the Maximum Aggregate Bandwidth value. Valid Range: 8000-2000000000.

Configures the Inter-user priority parameter. Valid Range: 1-4294967295.

Configures the allowed number of Persistent TFTs parameter. Valid range: 1-255.

Configures the maximum service connection parameter in Service Option profile. Valid range:1-4294967295.

Configures Service option allowed to establish over HRPD. Valid range:1-255. For HRPD, SDB records are not supported

Configures the maximum per Flow Priority parameter. Valid range: 1-65535.

Configures the Authorized Flow Profile IDs for each direction.

Configures the Allowed Differentiated Services Markings parameter. Valid range: 1-63.

Examples

Here are some example configurations:

router(config)#cdma pdsn multiple service-flows qos subscriber profile 
        router(config-qos-profile)#
        Eg:
        cdma pdsn multiple service-flows qos subscriber profile

router# cdma pdsn multiple service-flows qos remark-dscp AF11

router#(config-qos-profile)#bandwidth ?
  <8000-2000000000>  Value
 
router#(config-qos-profile)#bandwidth 9000 ?
  <cr>

Here is an example of the dscp command:

router#(config-qos-profile)#dscp ?
  allowed-class    allowed dscp's classes with which user can mark
packets
  max-class        User may mark packets with a class selector code
point
  reverse-marking  marking level pdsn apply to reverse tunneled packets
 
router#(config-qos-profile)#dscp allowed-class ?
  AF  User can send packets with AF dscp (A bit)
  EF  User can send packets with EF dscp (E bit)
  O  User can mark packets for experiment or local use (O bit)
 
router#(config-qos-profile)#dscp allowed-class AF ?
  <cr>
AF11     AF11
  AF12     AF12
  AF13     AF13
  AF21     AF21
  AF22     AF22
  AF23     AF23
  AF31     AF31
  AF32     AF32
  AF33     AF33
  AF41     AF41
  AF42     AF42
  AF43     AF43
  Default  Selector Class 0
  EF       EF
  class1   Selector Class 1
  class2   Selector Class 2
  class3   Selector Class 3
  class4   Selector Class 4
  class5   Selector Class 5
  class6   Selector Class 6
  class7   Selector Class 7

router(config-qos-profile)#

router(config-qos-profile)#dscp reverse-marking ?
  AF11     AF11
  AF12     AF12
  AF13     AF13
  AF21     AF21
  AF22     AF22
  AF23     AF23
  AF31     AF31
  AF32     AF32
  AF33     AF33
  AF41     AF41
  AF42     AF42
  AF43     AF43
  Default  Selector Class 0
  EF       EF
  class1   Selector Class 1
  class2   Selector Class 2
  class3   Selector Class 3
  class4   Selector Class 4
  class5   Selector Class 5
  class6   Selector Class 6
  class7   Selector Class 7

router(config-qos-profile)#

Here is an example or the flow-priority command:

router(config-qos-profile)#flow-priority ?
  <1-4294967295>  Value

router(config-qos-profile)#flow-priority 100 ?
  <cr>

Here is an example or the flow-profile direction command:

router#(config-qos-profile)#flow-profile ?
  direction  Configure direction for flow of packet

 
router#(config-qos-profile)#flow-profile direction ?
  <1-3>  1-Reverse  2-Forward  3-Bi-direction
 
router#(config-qos-profile)#flow-profile direction 1 ?
  flow-id  defines qos treatment to apply to a packet flow
 
router(config-qos-profile)#flow-profile direction 1 flow-id ?
  <1-65535>  Value
router#(config-qos-profile)#flow-profile direction 1 flow-id 100 ?

Here is an example of the inter-user-priority command:

router#(config-qos-profile)#inter-user-priority ?
  <1-4294967295>  Value
 
router#(config-qos-profile)#inter-user-priority 200 ?
  <cr>

Here is an example of the link-flow command:

router(config-qos-profile)#link-flow ?
  <1-4294967295>  Value

router(config-qos-profile)#link-flow 40 ?
  <cr>

router(config-qos-profile)#

Here is an example of the TFT command:

router(config-qos-profile)#tft-allowed ?
  <1-4294967295>  Value

router(config-qos-profile)#tft-allowed 1 ?
  <cr>

router(config-qos-profile)#tft-allowed 1

Here is an example of the subscriber redundancy rate command:

router(config)# subscriber redundancy rate 500 1

Verifying the Configuration

To verify the Subscriber QoS Profile feature on the PDSN, perform the following tasks:

 
Command
Purpose

Step 1 

router# show cdma pdsn session {qos|tft|detail}

In PDSN Release 4.0, the show cdma pdsn session command adds extensions that display the following information:

the Subscriber QoS profile

TFTs installed for the session in addition to the existing details

Step 2 

router# Show cdma pdsn qos local profile

This command displays the locally configured subscriber qos profile.

Step 3 

router# show cdma pdsn

In PDSN Release 4.0, new counters are introduced to display the number of sessions that have QoS enabled, and policing installed and enabled.

Step 4 

router# show cdma pdsn statistics

In PDSN Release 4.0, new counters are introduced to display the following information:

Number of TFTs parsed successfully or failed.

New counters to identify the TFT parsing failure reasons.

Number of Subscriber QoS Profile downloaded from AAA or locally installed.

Consolidation of subscriber QoS profile.

Policing installed or uninstalled.

Packets for which the DSCP was remarked based on policy installed.

Examples

Here is and example of the show cdma pdsn session tft command:

router# show cdma pdsn session tft
Mobile Station ID IMSI 123456789011122
  PCF IP Address 10.1.1.1, PCF Session ID 1
  This session has 1 flow
  This session has 1 Tft
  TFT IP Address 3.1.1.1
  Number of Packet Filters Forward 2, Reverse 1
  Forward Packet Filters
    Packet Filter 1
    Flow Id 10, Precedence 255, PF Type 0
    Source Port 125

    Packet Filter 2
    Flow Id 10, Precedence 255, PF Type 0
    Source Port 125
         
  Reverse Packet Filters
    Packet Filter 1
    Flow Id 10, Precedence 10, PF Type 0
    Source Port 125

Mobile Station ID IMSI 123456789011123
  PCF IP Address 10.1.1.1, PCF Session ID 2
  This session has 1 flow
  This session has 1 Tft

  TFT IP Address 3.1.1.2
  Number of Packet Filters Forward 2, Reverse 3
  Forward Packet Filters
    Packet Filter 1
    Flow Id 2, Precedence 2, PF Type 0
    Source Ip 5.5.5.5 Mask 255.255.255.0

    Packet Filter 2
    Flow Id 5, Precedence 5, PF Type 0
    Source Ip 1.1.1.1 Mask 255.255.255.0

  Reverse Packet Filters
    Packet Filter 1
    Flow Id 10, Precedence 255, PF Type 0
    Source Port 125

    Packet Filter 2
    Flow Id 10, Precedence 255, PF Type 0
    Source Port 125

    Packet Filter 3
    Flow Id 10, Precedence 255, PF Type 0
    Source Port 125

Here is an example of the show cdma pdsn qos local profile command:

router#show cdma pdsn qos ?
  local       CDMA PDSN local qos information
 
router#show cdma pdsn qos local ?
  profile  CDMA PDSN local qos profile information 

router#show cdma pdsn qos local profile ?
  |  Output modifiers
  <cr>
 
router#show cdma pdsn qos local profile
CDMA PDSN LOCAL QOS PROFILE
  QoS subscriber profile
    Max Aggregate Bandwidth : 8000
    Inter User Priority : 4321
    Maximum Flow Priority : 4
    Number of persistent TFT : 10
    Total link flow : 2
      Service Option : 59
      Service Option : 61
    Flow-profile
      Forward flow-id : 1
      Reverse flow-id : 2
      Bi-direction flow-id : 3
    DSCP
      Allowed-class AF
      Max-selector class 4

Here is a partial example of the show cdma pdsn statistics command that identifies QoS statistics:

router #show cdma pdsn statistics

QoS:
   Total Profile Download Success 10, Failure 10, Local Profile selected 4
   Failure Reason DSCP 1, Bandwidth 1, TFT 1, Flow Profile ID 1, 
   Max per flow 1, IUP 1, Others 4 
   Total Consolidated Profile 4, DSCP Remarked 0 
   Total Policing installed 4, failure 5, removed 4

Other QoS Parameters

The MS sends the QoS parameters for the IP flows in R_QOS_SUB_BLOB to PCF. The PCF, after it grants the QoS, forwards the details to the PDSN in an A11 RRQ. This is just stored and forwarded during Accounting, and contains the mapping the definitions of IP Flows (FlowID) which are used for A10 Connection mapping. This blob also contains an indicator of whether the flow id needs to be included in the bearer packets. If it is set, the PDSN adds a new GRE header, including the flow ID, in all the bearer packets for that flow.

Flow Remapping

Many times, even while the session and connections are up, the MS might decide to remap. It may do so when a new application is started. In such cases, QoS is again renegotiated, and the details are forwarded to the PDSN. The PDSN creates or deletes the A10, and also remaps the flows to the corresponding A10 connections.

Per-flow Accounting

Connection Setup

In HRPD systems, if a single A11-Registration Request message is used to establish multiple A10 connections, an A10 Connection Setup Airlink record is included for each of the A10 connections to be established. No field in the QoS blob is used or processed in the PDSN other than forwarding the same to AAA for accounting.

Airlink Start

An accounting start is generated under the following conditions:

For IP flows with ID FFH, when the main A10 connection is associated with the traffic channel or when new parameters are set.

For all other IP flows, when both of the following become true for that IP flow:

the IP flow is in the active state, and its associated link flow is associated with the traffic channel.

When new parameters are set.


Note For IP flows with ID FFH in HRPD systems, accounting is bidirectional. It applies to both forward and reverse IP flows.


This record does not include Granted QoS Parameters.

Airlink Stop

An accounting stop will be generated under the following conditions:

The main A10 connection is disassociated from the traffic channel, or parameter settings are no longer valid.

For all other IP flows, when the IP flow is in the active state and its associated link flow is associated with the traffic channel, and then one or more of the following occurs:

the traffic channel is released,

the IP flow is deactivated or removed,

its link flow is disassociated with the traffic channel; or

When parameter settings are no longer valid.

For inter-PCF handoff, the source PCF sends an Active-Stop Airlink record for each activated IP flow to the PDSN, and the target PCF send Active-Start Airlink records for each activated IP flow per direction to the PDSN.

During A11 re-registration, if some connections are missing and the flows are deleted, an accounting stop is sent for those connections and flows. Similarly an accounting start is sent for all those newly added flow-ids.

IP flows with received accounting records are identified by the granted QoS that carries the respective IP flow ID and direction. When remapping of IP flows occurs, the flows get mapped from one A10 to another A10. The PDSN sends an accounting stop for the old A10, and an accounting start for the new A10 for that particular IP flow. In this scenario, an accounting Start and Stop is triggered upon receiving an active start and active stop respectively. When an active start and stop are not received and session is torn down, still the pair of accounting stops for the old A10 and the start for new a10 are sent for the IP flow.

When an IP flow receives an active stop with flow status as inactive, it is moved to inactive state. The IP flow becomes active once an active start is received for the same. The PDSN generates a stop accounting stop record when the IP Flow moves from active to inactive state.The IP flow is moved back to active after it receives an active start, and when it changes from inactive to active an accounting start is sent.

Configuring Per-Flow Accounting

To configure the Per-flow Accounting feature on the PDSN, perform the following task:

 
Command
Purpose

Step 1 

router# cdma pdsn attribute send {f16|f17|f18|f19|f20|f22

In PDSN Release 4.0, new options are introduced in the existing CLI. These new attributes are sent in accounting messages.

(F16) Forward PDCH RC
(F17) Forward DCCH Mux Option
(F18) Reverse DCCH Mux Option
(F19) Forward DCCH RC
(F20) Reverse DCCH RC
(F22) Reverse PDCH RC

Example

Here is sample output for PDSN Release 4.0:

cdma pdsn attribute send ?
  a1             Attribute Calling Station ID
  a2             Attribute ESN, Electronic Serial Number
  a3             Attribute MEID, Mobile Equipment Identifier
  c5             Service Reference ID
  esn-optional   Send ESN in Access Req/accounting records only when received
                 from PCF

  f11            IP Technology
  f15            Attribute f15, always-on
  f16            Forward PDCH RC	 ------------------------|
  f17            Forward DCCH MUX	------------------------|
  f18            Reverse DCCH MUX	------------------------|-----> NEW
  f19            Forward DCCH RC		------------------------ |
  f20            Reverse DCCH RC 	------------------------|
  f22            Reverse PDCH RC		------------------------ |
  f5             Attribute Service Option
  g1             Attribute Input Octets
  g17            Last known user activity
  g2             Attribute Output Octets
  is835a         is835a specified attributes (g3 and g8 to g16)

meid-optional Send MEID in Access req/accounting records only when received from PCF

Verifying Per-Flow Accounting

To verify that the Per-flow Accounting feature is configured on the PDSN, perform the following tasks:

 
Command
Purpose

Step 1 

router# Show cdma pdsn accounting [detail]

In PDSN Release 4.0, the output has been enhanced to display the HRPD and IP flow details.

Example

Here is example output:

router#show cdma pdsn accounting detail 
 UDR for session 
 session ID: 1
 Mobile Station ID IMSI 123456789123457

   Mobile Station ID (A1) IMSI 123456789123457
   ESN (A2) 000100020003005
   MEID (A3) 
   Session Continue (C3) ' ' 0
   Serving PCF (D3) 2.2.1.1 Base Station ID (D4) 000000000000
   User Zone (E1) 0000
   Forward Mux Option (F1) 1    Reverse Mux Option (F2) 2    
   Service Option (F5) 59   Forward Traffic Type (F6) 6    
   Reverse Traffix type (F7) 7    Fundamental Frame size (F8) 8    
   Forward Fundamental RC (F9) 9    Reverse Fundamntal RC (F10) 10   
   DCCH Frame Format (F14) 14   Always On (F15) 0 
   Forward PDCH RC (F16) 16   Forward DCCH Mux (F17) 17       <--- new 
   Reverse DCCH Mux (F18) 18   Forward DCCH RC (F19) 19   
   Reverse DCCH RC (F20) 20   Reverse PDCH RC (F22) 22   

   Bad PPP Frame Count (G3) 0 Active Time (G8) 0 
   Number of Active Transitions (G9) 1 
   SDB Octet Count Terminating (G10) 0 
   SDB Octet Count Originating (G11) 0 
   Number of SDBs Terminating (G12) 0 
   Number of SDBs Originating G13 0 
   Number of HDLC Layer Bytes Received (G14) 225 
   In-Bound Mobile IP Signalling Octet Count (G15) 0 
   Out-bound Mobile IP Signalling Octet Count (G16) 0 
   Last User Activity Time (G17) 0 
   IP Quality of Service (I1) 0 
   Airlink Quality of Service (I4) 0
   R-P Session ID (Y2) 1

 UDR for flow 
    Mobile Node IP address 20.2.0.0 
    IP Address (B1) 20.2.0.0,  Network Access Identifier (B2) mwtcp-sip-basic-user1
    Account Session ID (C1) 4248
    Correlation ID (C2) ' ' 240
    Beginning Session (C4) ' ' 0
    MIP Home Agent  (D1) 0.0.0.0
    IP Technology (F11) 01 Compulsory Tunnel indicator (F12) 00 
    Release Indicator (F13) 00
    Data Octet Count Terminating (G1) 0 
    Data Octet Count Originating (G2) 0  Event Time G4:1219295403 
    Rsvp Signaling Inbound  Count (G22) 0 Outbound Count (G23) 0   <-- new
    Rsvp Signaling Packets In (G24) 0 Packets Out (G25) 0
    Packets- in:0 out:0
 

The following are new:


UDR for IPFlow (new: Yes)
   Session ID : 2 Flow ID : 0x01 Direction : Forward
     Account Session ID (C1) 1095 Correlation (C2) 0 
     Service Reference ID (C5) 2 Flow ID (C6) 1
     Serving PCF (D3) 2.2.1.1 
     Forward Mux Option (F1) 1    Reverse Mux Option (F2) 2    
     Service Option (F5) 59   Forward Traffic Type (F6) 6    
     Reverse Traffix type (F7) 7    Fundamental Frame size (F8) 8    
     Forward Fundamental RC (F9) 9    Reverse Fundamntal RC (F10) 10   
     DCCH Frame Format (F14) 14   Forward PDCH RC (F16) 16   
     Forward DCCH Mux (F17) 17   Reverse DCCH Mux (F18) 18   
     Forward DCCH RC (F19) 19   Reverse DCCH RC (F20) 20   
     Reverse PDCH RC (F22) 22   Flow Status (F24) Active 

     Data Octet Count Terminating (G1) 0 
     Data Octet Count Originating (G2) 0  Event Time G4:0 
     Active Time (G8) 0 
     Number of Active Transitions (G9) 1 
     SDB Octet Count Terminating (G10) 0 
     SDB Octet Count Originating (G11) 0 
     Number of SDBs Terminating (G12) 0 
     Number of SDBs Originating G13 0 
     Granted Qos (I5): 
       Flow direction :0 Flow ID :1 
       Flow Profile ID :0 
       Qos Attribute Set ID :1 Traffic Class :0 
       Peak Rate :1 Bucket Size :100 
       Token Rate :100 Maximum Latency :100 
       Max IP Packet Loss Rate :10 
       Packet Size :10 Delay Variance Sensitive :100 
   IP Quality of Service (I1) 0 
   Airlink Quality of Service (I4) 0
   R-P Session ID (Y2) 2

Handoff Scenarios

This section lists various handoff scenarios.

Inter-PCF handoff - Same PDSN (RevA to RevA)

The PDSN, irrespective of PPP Renegotiation or not, will release all of its existing A10 connections with the old PCF and establish the auxiliary connections freshly for the new PCF.

In this case, the TFTs are not cleared. The flow-ids are retained and remapped to the new PCF's A10 connections.

Handoff from 1x to RevA

When a mobile node hands off from a 1x network to a Rev A PCF, the existing flow is considered the main service connection. The auxiliary service flows and the application flows are then freshly created. When a handoff from 1xRTT to EV-DO occurs, the PDSN sends an accounting start upon receiving active start per flow per direction. In this case, there should be a connection setup received for the associated a10 of that IP flow.

Handoff from Rev A to 1x

When a mobile node hands off from a Rev A PCF to a 1x PCF, all the service flows and application flows are deleted except the TFTs. The subscriber QoS profile is retained with the session. The policing and DSCP validations continue if already in place. When there is a handoff from EV-DO to 1xRTT, will be sending one accounting stop per IP flow per direction is sent for those IP flows that are active. A pair of Start-Stops are sent for those IP flows that are inactive, since this is the final stop through which to detach from AAA context.

Call Admission Control

As part of the subscriber QoS profile, bandwidth is downloaded from AAA. The PDSN needs to make that bandwidth available for the mobile station. This helps in case the mobile uses any video services.

There is no specific interface on the PDSN that is considered as egress that defines the maximum available bandwidth. So there is no direct allocation, and the PDSN cannot use generic IOS QoS implementation on allocation failure.

As a solution, a new CLI is introduced which defines the total bandwidth on the box. This bandwidth could be the Gigabit interface on the SAMI card, or the egress interface on the line card. The maximum available bandwidth could be the minimum of the two.

Whenever a session registers with the PDSN, and the PDSN downloads the bandwidth to allocate, it checks the available bandwidth. If the requested bandwidth is available for use, the session is created successfully and the allotted amount is deducted from the available bandwidth. If it runs out of bandwidth, the call is rejected.

Whenever the session is deleted, the bandwidth is returned to the original pool.

Whenever a different bandwidth is downloaded during re-registration, the old one is returned and then the new one is deducted.

BandwidthFactor = (ConsumedBandwidth / Total Bandwidth) * 100

The other factors that can be included are memory, CPU, and the session load.

Session Load:

Currently the load that is calculated and forwarded to the Cluster Controller is the ratio of number of sessions active to the total session capacity of the box.

SessionFactor = (Number of Sessions active / Total session capacity) * 100

Memory:

Memory factor consists of 2 parts—Processor Memory and IO Memory. The RRQ should be accepted only if 10% of memory is available (both processor and IO Memory).

ProcMemoryFactor = (MemoryConsumed/TotalMemory) * 100

IOMemoryFactor = (MemoryConsumed/TotalMemory) * 100

CPU Factor:

The processor could be loaded due to heavy traffic (high packets/sec), or because of high number of requests or heavy data traffic. To consider this parameter, take the current CPU percentage for computation as well.

CPUFactor = (CPU Percentage)

Taking all the four parameters, the new load factor will be the maximum of the four.

If the maximum is memory or CPU, new registration requests are rejected till the value drops below the configured threshold.

If the maximum is because of BandwidthFactor, and if the new request is 1x (not downloading bandwidth), it is allowed. If it is RevA or 1x (downloading bandwidth), the registration proceeds until the bandwidth is downloaded. Then, based on bandwidth availability, the request is either processed or rejected.

If the highest is session count, it proceeds till the maximum is reached.

Controller - Member Calculation

The member now sends the newly calculated load to the controller as the exact load of the system. The controller performs load-balancing with the load value sent by the member. The controller reject calls once any of the load parameters for all the associated members reach the threshold of 100%. CAC is enabled on the member when the BW and CPU thresholds are configured. Multiple flows are enabled in the controller to support PDSN R4.0. The default memory threshold is 90%.

Configuring Call Admission Control on the PDSN

To configure the Call Admission Control feature on the PDSN, perform the following tasks:

 
Command
Purpose

Step 1 

router# cdma pdsn cac maximum [bandwidth number]

cdma pdsn cac maximum [cpu number]


Enables the Call Admission Control feature. Use the bandwidth keyword to control the maximum CAC bandwidth parameters, and the cpu keyword to control the maximum CPU threshold.

Step 2 

router# cdma pdsn cluster controller member reva-support

When the members are PDSN R4.0 based, CAC is done based on many parameters. Use this command to make the Cluster Controller utilize all of the newly introduced parameters to distribute the load.

Examples

Here is an example of the configuration commands:

router# cdma pdsn cac ?
  maximum          Configure Maximum values for CAC Parameters
 
cdma pdsn cac maximum ?
  bandwidth        Configure Maximum Bandwidth
  cpu              Configure CPU Threshold parameters
 
cdma pdsn cac maximum bandwidth ?

<8000-2000000000> Value

cdma pdsn cac maximum cpu ?
<30-90> Value 

Verifying the Configuration

To verify that the CAC feature is enabled, and to gather information regarding the CAC feature, perform the following task:

 
Command
Purpose

Step 1 

router# show cdma pdsn cac

Display the various call admission control parameters and their status.

Examples

Here is an example of the show cdma pdsn cac command:

router# show cdma pdsn cac

Router#sh cdma pdsn cac

Output in Values Output in percentage

Total configured bandwidth 200000000 b 100%

Allocated bandwidth                                 0 b 0%

Available bandwidth                            200000000 b 100%

CPU Threshold                                                                  90%

CPU Current                                                                   0%

Processor Memory Threshold     813609471 90%

Processor Memory Current    73398292 8%

IO Memory Threshold 60397977 90%

IO Memory Current                                 45603376 67%

Sessions allocated                                       0 0%

Max sessions allowed                                  25000 100%

Router#

Resource Management

Resource management defines the mechanism to release packet data session related resources at the network elements like the PDSN and the HA. Resources may be released due to the session handoff or for administrative purposes.

IS-835-C defines two mechanisms for resource management:

Packet of Disconnect (POD)

Mobile IP Resource Revocation

While resource management based on Packet of Disconnect is applicable to Simple IP, Mobile IP and Proxy Mobile IP flows, resource management based on Mobile IP Resource revocation is applicable only to Mobile IP flows.

The Cisco PDSN supports resource management based on both Packet of Disconnect and Mobile IP resource revocation.

Resource Revocation for Mobile IP

Basic Mobile IP resource revocation is an IS-835-C initiative that defines the methods by which a mobility agent (one that provides Mobile IP services to a mobile node) can notify the other mobility agent of the termination of a registration due to administrative reasons or MIP handoff.

When configured on the PDSN/FA, the Mobility Agent Advertisement extension in the Agent advertisement will have the X bit set, thus advertising support for resource revocation on that link. A PDSN configured to support resource revocation in Mobile IPv4 will include a revocation support extension in all MIP RRQ including re-registrations. If the associated MIP RRP from the HA also includes a valid revocation support extension, then the PDSN will assume the associated registration as revocable.

For a registration that is revocable, if the PDSN/FA needs to terminate the session administratively, the PDSN/FA sends a resource revocation message to the HA and releases the resources held for that registration.

If the resource revocation ACK from the HA is not received within a configurable amount of time, the resource revocation message will be retransmitted.

On receipt of a resource revocation message from Home Agent, and a registration (identified by the home address, care-of address, and Home Agent address) is located, the resources held by that registration are freed, and a resource revocation ACK message is sent back to the Home Agent. If no other Mobile IP registrations are active on the PPP session associated with the revoked binding, then the PDSN will release the associated PPP and R-P sessions for the revoked registration.

Restrictions for Registration Revocation

The following restrictions for Registration Revocation on the PDSN apply:

The STC VSA returned from AAA in access-accept message during FA-CHAP and HA-CHAP will be ignored, and local configuration on the PDSN and HA will take precedence.

Revocation extension and messages, even if not protected by FHAE or IPSec, will be accepted and processed by both PDSN and HA. It is recommended that the user takes care of providing the security of the messages by either configuring FA-HA security association or by provisioning IPSec tunnel between the two agents.

MobileIP MIB is not updated with the Registration revocation information.

On the PDSN, all the ip mobile foreign-service commands need to be configured at the global level and not at the interface level.

On the PDSN, for the I-bit support the local policy is to always negotiate I-bit and to always set it to 1 in the Revocation messages. Also the provision to set B-bit to 1 in the agent advertisement message while informing MN of the revoked data flow is not provided.

Resource Revocation and Bind Update cannot be enabled simultaneously. Both are mutually exclusive of each other.

Packet of Disconnect

Radius Disconnect, or Packet of Disconnect (PoD) is a mechanism that allows the RADIUS server to send a Radius Disconnect Message to the PDSN to release Session related resources. Resources may be released due to the session handoff, or for administrative purposes. Some of the resources identified include PPP, RP sessions and Mobile IP bindings. Support for Radius Disconnect on the Cisco PDSN and Home Agent is TIA835C compliant.

The PDSN communicates its Resource management capabilities to the Home AAA in the Access Request message (sent for authentication/authorization procedure) by including a 3GPP2 Vendor Specific Session Termination Capability (STC) VSA. The value communicated in the STC VSA is obtained in the configuration. The PDSN also includes an NAS-Identifier attribute containing its Fully Qualified Domain Name (FQDN) in the Access Request.

The Home AAA server establishes a relationship between the user and the NAS Identifier/ NAS-IP address to detect a inter-PDSN handoff. If the NAS-Identifier/ NAS IP address received in the Access Request is different from the previously stored value (non-zero), an inter-PDSN handoff is detected.

The Disconnect Request contains the NAS-ID and the Username (NAI) attributes. It can optionally contain 3GPP2 Correlation ID Calling station ID (IMSI) and the Framed IP address—some session identification attributes. A Disconnect Reason VSA is included if a inter-PDSN handoff is detected. The session identification attributes supported by the PDSN are 3GPP2 Correlation ID and Calling station ID (IMSI).

If the 3GPP2 Correlation ID and Calling station ID (IMSI) attributes are received in the Disconnect Request, and the PDSN is able to find the session/flow corresponding to them, the PDSN will terminate the associated flow and send a Disconnect ACK message to RADIUS server. If session is not found for the received attributes, the PDSN will reply back with a Disconnect NACK message with error code "session context not found". If the Disconnect request has invalid attributes (for example, an 8 digit IMSI), the PDSN will reply with a Disconnect NACK with error code "Invalid Request".

The PDSN also supports processing Disconnect Requests that only contain the NAI attribute (if configured). In compliance with the standards, the PDSN terminates all sessions corresponding to the Username received.

The Ballot version mentions that a Disconnect Request can be received at the Home Agent (HA,) but details on the action to be taken in such an event is not detailed. Hence the approach followed is to terminate a specific binding if Framed-IP-Address attribute is received along with NAI, or terminate all bindings for the NAI, if only NAI attribute is received in the Disconnect Request.

The following restriction is present for this feature:

All Dormant NVSE are not supported.

The command line interface for this feature will be standard AAA interfaces. The preferred method to configure POD in Release 2.0 and above is to use the aaa server radius dynamic-author command, which leads to a sub-configuration mode that has options to configure clients, security keys, and other variables.

The following NAS global AAA command is used to enable listening for POD packets:

aaa pod server key word, where word is the shared key.

The full syntax for this command is:

aaa pod server [clients ipaddr1 [ipaddr2] [ipaddr3] [ipaddr4]] [port port-number] [auth-type {any | all | session-key}] server-key [encryption-type] string

The following debug command is also available:

debug aaa pod

Restrictions for RADIUS Disconnect

All Dormant NVSE is not supported.

MIB support is not currently planned.

Processing of a RADIUS Disconnect message with only NAI present must be configured for compliance to IS 835-C.

Radius Enhancements

PDSN R3.0 includes the following RADIUS enhancements:

Radius Server Load Balancing

Selection of Radius Server based on realm.

Radius Server Load Balancing

The RADIUS Load-Balancing (RLB) feature shares the load of RADIUS Authentication and Accounting transactions across a set of RADIUS servers. Without RLB, all transactions are sent to the first server considered to be alive in a server group. When this server stops responding and is marked dead, the PDSN fails over to the next one in the group. Using only one server, despite the presence of other usable servers in the group, limits the overall throughput for call setup/teardown.

Radius Server Load Balancing allows the PDSN to distribute the transaction load across multiple servers in a server group. It tracks the slower servers and reduces the transaction load on those servers, and it adapts when a server is marked dead and when it comes back up again.

The transactions are grouped into batches (the size of which is configurable), and each server is assigned a batch to process. The feature then load-balances transactions based on these batches, one batch at a time. When the first transaction is received, the algorithm determines the server with the least outstanding transactions, and this server is assigned the next batch of transactions. Once a batch of transactions has been assigned, the algorithm determines the server with the least outstanding transactions, and this server is assigned the next batch of transactions. Thus, the server with the least outstanding transactions always gets assigned the next batch. This load-balancing scheme can be applied based on a server group. Thus, each server group defined on the IOS platform can have its own load-balancing scheme.

You should exercise care while configuring the batch size. The trade-off in large versus a small batch size is that of throughput versus CPU load. A large batch size results in a lesser amount of computations, and a lower CPU load; however, it may cause a particular server within the server-group to be assigned transactions even though others in the group are idle. For very small batch sizes, the CPU load increases, as it computes outstanding load across servers more often. Lab simulations indicate that a batch size of 25 gives a decent throughput while not adversely affecting the CPU load.

High Latency RADIUS Servers

The algorithm adapts well to servers of varying response times. Servers that are quick have a lower number of transactions outstanding, and are assigned larger number of the incoming transactions. Slower servers get proportionately lower numbers of transactions.

Server Failovers

When a transaction fails over to the next server in the group after a failover, its outstanding count is increased. Thus, failed-over transactions are also load-balanced. When the next batch of transactions is assigned, this server's outstanding count will reflect it's load accurately—both new and failover transactions will be accounted for in the outstanding transaction count.

Dealing with Server Groups

Consider the following two server-groups:

Server-group SG1 with servers S1, S2, S3.

Server-group SG2 with servers S3, S4, S5.

Consider that SG1 is configured to be load-balanced, while SG2 is not. When requests are sent to SG2 these requests are assigned to S3, as it is the first server in the group and its outstanding transaction count will increase. When requests are sent to SG1, these requests are load-balanced across these servers. When sending transactions to S3, the outstanding transaction count for the server will be high because SG2 transactions are assigned directly to it. Thus, it will receive a low proportion of transactions in SG1. This is the preferred behavior, since the goal is to send transactions to servers that are quicker and able to handle more load, where the load is the total transactions a server is handling, not just those of the current server-group.

Preferred Servers

In certain cases, it is desirable to use the same server for all requests for a given session. With RADIUS server load balancing there is no guaranty that this will occur. To avoid such situations a preferred-server indication is introduced in Release 3.0.


Note This indication is a preference or recommendation only.


The preferred server behavior, which is enabled by default, tries to ensure that all the accounting records (Start, Stop, and Interim) for a session are sent to the same RADIUS server. However, authentication and accounting records for the same session may still be sent to different RADIUS servers as determined by the load balancing algorithm.

The following events may cause accounting records for the same session to be sent to different RADIUS servers:

PPP re-negotiation

Handoff

The PDSN will try to use the server if possible, but if not, it will fall back to other servers in the group based on the load-balancing mechanism.

When this indicator is used, costs are not considered in deciding which server to use. However, it might not be possible to always use the preferred server. The server may have been marked dead. Or the server may not be usable since it is not part of the server-group that was used for a previous transaction during the session (for example, the Accounting server-group may be different from the authentication server-group). In this case, the algorithm is free to select an alternate server, based on the load-balancing scheme.

Incoming RADIUS Requests

The RADIUS server load balancing feature is not applicable to incoming RADIUS requests (for example, Packet of Disconnect). POD responses require that the server requesting service be the one that is responded to, thus you should not load-balance these requests across servers.

Subscriber Authorization Based on Domain

Cisco IOS provides a "Subscriber Authorization" mechanism to authorize subscribers based on their realm. You can find details of this feature at the following URL:

http://www.cisco.com/en/US/partner/products/ps6350/products_configuration_guide_chapter09186a0080455cf0.html#wp1056463

IS-835 Prepaid Support

The Cisco PDSN 2.0 software release provides real-time monitoring and rating of data calls for prepaid users. The prepaid billing solution for the PDSN is based on the RADIUS (AAA) server, and takes advantage of the existing flow-based accounting functionality. The prepaid billing feature requires the RADIUS server to interface with a Prepaid Billing Server (PBS) to relay real-time billing information between the PDSN and the PBS. A third-party Prepaid Billing Server controls the real-time rating of data calls and maintains balances in users' accounts. Cisco does not supply the PBS.

The following three types of Prepaid service are available in PDSN Release 2.1:

Volume-based Prepaid data service

Volume-based Prepaid data service with tariff switching

Duration-based Prepaid data service

Prepaid functionality is supported on PDSN for the following type of data sessions:

Simple IP sessions with authentication and authorization performed at AAA.

VPDN sessions with authentication and authorization for the user performed at AAA.

Mobile IP sessions with FA-CHAP performed for the session/NAI at AAA.

Proxy mobile IP sessions with authentication and authorization for the user performed at AAA.

Prepaid service is also available for sessions opened with MSID-based authentication access.


Note Either Volume-based or Duration-based, but not both options in one prepaid flow, are supported on the PDSN. Multiple flows, each supporting either Volume or Duration based prepaid service, are allowed on the PDSN. The PDSN can be configured to support only Volume-based, or only Duration-based, or either type of Prepaid service per flow at any point in time.


Volume-based accounting for prepaid flows other than VPDN will count the bytes present in the PPP payload. For VPDN flows, it will count the bytes present in the PPP packet including the PPP packet header. A session that has multiple flows can have some of the flows with prepaid data service enabled, each either Volume-based or Duration-based, while other flows may not be prepaid enabled.

Tariff-based prepaid service is also supported for volume-based prepaid data service on the PDSN. To support tariff-based prepaid service, the Prepaid Billing Server should have the following capabilities:

Charged by volume—different tariff for different time of day.

The Billing server allocates a different quota (volume-based) for a user that is determined by a tariff for a different time-of-day (this ensures the two charging rates do not overlap).

Restrictions for Prepaid Support in Cisco PDSN Release 2.1

Prepaid for remote address based accounting is not supported.

Online Access Request messages are sent with Service-Type as "outbound" (instead of "Authorize Only"), and user password is included in the message.

There is no Prepaid MIB support in the present release.

Prepaid for the HA is not supported.

Prepaid Billing

When a user performs Simple IP access with AAA authentication, or Mobile IP access with FA-CHAP, the Prepaid capable PDSN sends a RADIUS Access-Request message for Authentication and Authorization. The Prepaid capable PDSN informs the Billing Server of its own Prepaid capabilities by including a PPAC VSA in the RADIUS Access-Request message.

The Home RADIUS performs Authentication and Authorization procedures as usual. If the HAAA identifies that a user is a prepaid user from its user profile, the HAAA interfaces with the Billing Server to retrieve prepaid related information for the user, and passes on the prepaid related information in the Access Request message. The Billing Server performs prepaid authorization for the user. The prepaid authorization procedure at HAAA and Billing Server consists of the following steps:

Checking the PPAC VSA.

Checking the home network policy.

Checking the user's account balance and state.

When the Billing Server successfully authorizes the user as a valid prepaid user, it notifies the HAAA that it supports prepaid service based on volume, or duration, or both, depending on the configuration at the Billing Server and capabilities as indicated by the PDSN. The HAAA encodes the information in a PPAC VSA to the PDSN, and indicates that volume-based or duration-based prepaid (or both) service is supported by the Billing Server.

HAAA sends the authorization response to the Prepaid capable PDSN using RADIUS Access-Accept/Reject messages. The authorization response includes a PPAQ VSA in the same RADIUS Access-Accept message stating an initial quota, quota-id and a threshold value of the quota for the prepaid flow corresponding to the user.

When the PDSN sends on-line Access Request messages to HAAA for prepaid related functionality, it does not set the User-Password (= 2) field in the message, and normal RADIUS message authentication is set and performed with Message Authenticator. Currently, the User-Password is set in online Access Requests to the default value of "cisco".

If the PDSN does not receive the PPAC VSA from the HAAA in the initial RADIUS Access-Accept message, or the message is included but indicates that "Prepaid Accounting not used", the PDSN will release the user's prepaid flow if the RADIUS Access-Accept message includes a PPAQ VSA. The PDSN will send an Access Request to HAAA to return the quota allocated with Update-Reason VSA that indicates Client Service termination.

If the PDSN is capable of supporting prepaid service based on either volume or duration, then the PDSN will enable prepaid service for the flow based on the Billing server-indicated service that applies to the session in PPAC. If the Billing server also indicates that the PDSN can allocate either volume or duration, then the PDSN will enable prepaid service based on the type of quota (volume or duration) present in PPAQ from HAAA. If both types of quota are present in PPAQ, then prepaid flow is not opened on the PDSN.

If the PDSN is capable of supporting prepaid service based on volume, and Billing Server indicates that it will support prepaid service based on duration, then the PDSN will close the prepaid flow. The PDSN will send an Access Request message with Update-Reason VSA indicating "Client Service termination". The same logic applies to the PDSN if it supports prepaid based on duration, and Billing Server returns prepaid service based on volume.

If the PDSN receives an Access-Accept message containing the PPAC VSA indicating prepaid service supported, but the initial quota is not included in the message, the PDSN will close the flow. Since no quota was received in the Access Accept, the PDSN will not send further RADIUS Access Request message to HAAA.

To ignore Billing Server interaction of HAAA for Access Requests sent by the PDSN during mobile IP re-registration for FA-CHAP, the PDSN will include the Session-Continue VSA set to "TRUE" in the on-line Access Request messages.

If multiple flows are present for the session that hosted the Prepaid flow, and a prepaid flow was stopped, and if it was the last flow for the session, then the session will be deleted by the PDSN. If one of mobile IP flows expires and it is not the last flow for the session, then the PDSN will close the flow locally. If the resource revocation mechanism is enabled on PDSN, the relevant resource revocation mechanism will be applied in this case.

If the Simple IP (SIP) flow is closed (for example, a PPP session is torn down or quota for the SIP flow expires), then all the other mobile IP flows, both prepaid and non-prepaid, will also get closed. If SIP flow is closing due to allocated quota expiry, it will send Access Request message with Update-Reason as "Quota Reached". In other cases where the SIP session is closed, the Access Request will be sent with Update-Reason as "Client Service Termination". All other prepaid flows for the PPP session will also send Access Request messages to close the prepaid service and return unused quota. The Update-Reason for all these flows will contain value for "Main SI Released".

When threshold for the quota is reached, the PDSN sends an Access Request to HAAA to retrieve more quota for the flow. In case the values of threshold for the quota and the quota allocated are same, then on quota expiry (when Quota = Threshold), the PDSN will treat this as flow as closed, and send an Access Request with Update-reason as "Quota reached".

When the quota expires for the flow, the PDSN sends an on-line Access Request to the HAAA to indicate that the prepaid flow is released. During this time the PDSN marks the flow as deleted, and stops switching any packets for the flow. On receipt of the Access Accept from the AAA server for this Access Request, the PDSN deletes the prepaid flow for the user and sends an Accounting Stop.

If resource revocation mechanism is enabled at the PDSN, then the PDSN will send a resource revocation to the HA to clear binding at the HA, and the PDSN will clear the visitor info for the flow.

Upon receiving a RADIUS Disconnect Request (POD) or Mobile IP revocation messages, the PDSN will send an on-line RADIUS Access-Request message containing the used quota and the Update-Reason Sub-Type set to "Remote forced disconnect". The PDSN will delete the flow and send resource revocation message to the HA, and will send the existing RADIUS Accounting-Stop.

Volume-based Prepaid Data Service Flow

The metric for accounting volume based Prepaid service is total bytes flowing through the user flow in upstream and downstream direction.


Step 1 The Prepaid capable PDSN determines that Simple IP or Mobile IP setup requires a RADIUS Access-Request message to be sent to the Home RADIUS Server. For SIP sessions, the use has to be authenticated with AAA instead of local authentication. In case of Mobile IP users, FA-CHAP authentication is required.

The PDSN includes its own PPAC VSA to inform the HAAA/Billing Server that it supports Prepaid based on Volume (value = 1 or 3). If resource revocation is enabled on the PDSN, then it will send a SessionTerminationCapability (STC) attribute indicating that it can support resource revocation for Mobile IP sessions.

The Home RADIUS server performs the regular Authentication and Authorization of the Access Request sent by the user. If the user profile indicates the user is a Prepaid subscriber, HAAA interfaces with the Billing Server, and provides the Billing Server with the prepaid info for the user as received in the Access Request message.

Step 2 After the Billing Server receives the user's prepaid information, it checks the capabilities of PDSN (sent in the PPAC VSA). The Billing Server also checks that the user has a valid balance and account status. The Billing Server then indicates to the PDSN that it supports prepaid packet data service based on volume. It also assigns the initial quota for the user, which is typically a fraction of total available quota for the user. The quota allocated for the user is identified by a quota id assigned by Billing Server for the user for the current quota. The Billing Server interfaces with HAAA and provides this information to the HAAA.

The HAAA encapsulates the prepaid information received for the user in a RADIUS Access-Accept message and sends it to the PDSN. The RADIUS message includes:

A PPAQ VSA that contains the following parameters:

Initialized quota for the user flow specified in VolumeQuota parameter

Quota ID for the quota allocated

A threshold value for the quota allocated in VolumeThreshold parameter

A PPAC VSA indicating prepaid service is based on Volume.

After the PDSN receives the Access-Accept message from AAA, it parses the RADIUS packet and retrieves the attributes inside it. The PDSN stores the information present in the packet regarding the quota allocated for the flow and the threshold corresponding to the allocated flow. It also stores the Quota-ID allocated in the user flow present in the message. Once the flow for the user comes up (IP address assigned for Simple IP, or MIP RRP received from the HA and sent to the MS), the PDSN starts metering the user's traffic over the flow against the allocated quota.

Step 3 User data (IP datagrams) that flow through each Prepaid flow is accounted in both upstream and downstream directions. The bytes consumed are checked against the quota allocated for the flow by the Billing Server.

Step 4 Once the Volume Threshold value reaches the allocated quota for the prepaid flow, the PDSN sends an Access-Request Message to AAA to refresh quota for the user. This RADIUS packet contains a PPAQ VSA, which includes following parameters:

Update-Reason Sub-Type that is set to indicate "Threshold reached" (= 3)

Quota ID previously received

Used volume in the VolumeQuota Sub-Type

HAAA authenticates the RADIUS packet and if authentication is successful, forwards the prepaid-related information present in the packet to the Billing Server.

Step 5 The Billing Server updates its database with the amount of quota the user utilizes. Since the user indicates quota renewal, the Billing Server apportions a fraction of prepaid account balance of the user. It also assigns a new Quota ID for the current allocated quota and a corresponding threshold value for the assigned quota. This information is passed on to HAAA.

The HAAA sends the information received from the Billing Server into a RADIUS Access-Accept message to be sent to PDSN. The attributes that are encapsulated into a PPAQ VSA include:

Quota ID

Allocated quota into VolumeQuota parameter

Threshold corresponding to the assigned quota into VolumeThreshold parameter.

After the PDSN receives the Access-Accept message from AAA, it parses the RADIUS packet and retrieves the attributes inside it. The PDSN stores the information present in the packet and updates the quota allocated for the flow and the current threshold value corresponding to the allocated flow. It also stores the new Quota-ID allocated for the current quota.

Step 6 User data (IP datagrams) continues to flow through the Prepaid flow, and is accounted in both upstream and downstream directions. The bytes consumed are checked against the quota allocated for the flow.

Step 7 The PDSN decides to close the prepaid flow based on following criteria:

Access-Request message was sent to renew the quota and corresponding Access-Accept message was not received from AAA after a configurable time value. This time is same as the RADIUS message timeout configured on PDSN.

An Access-Accept was sent to retrieve quota and before Access-Accept can be received, the remaining VolumeQuota is consumed. This is when the VolumeQuota value and the VolumeThreshold values become same.

In this case, PDSN sends an Access-Request message containing the PPAQ VSA that includes:

Update-Reason Sub-Type to indicate 'Quota reached' (= 4)

Amount of quota used by the user in VolumeQuota attribute.

At this time, the PDSN marks the prepaid flow as being marked for deleted, such that it does not switch any packets through it for the prepaid flow. It does not delete the prepaid flow immediately and waits for the response of the Access-Request or timeout of the Access-Request message.

Step 8 The Billing Server does not allocate a new quota when the user indicates "Quota reached" for the prepaid flow. The Billing Server terminates the prepaid flow and indicates the same to the HAAA. The HAAA sends an Access-Accept message to the PDSN acknowledging the termination of the Prepaid packet data session by encapsulating Update Reason Sub-type as "Quota is reached" inside PPAQ VSA.

After the PDSN receives the Access Accept message, it deletes the user flow for the Prepaid session. As part of the usual off-line accounting procedures, the PDSN sends an off-line RADIUS Accounting-Stop message upon successful release of the appropriate resources (normal operation).


Duration-based Prepaid Data Service Flow

The metric for accounting duration-based Prepaid service is session duration in seconds.


Step 1

The Prepaid capable PDSN determines that Simple IP or Mobile IP setup requires a RADIUS Access-Request message to be sent to the Home RADIUS Server. For SIP sessions, user authentication has to be performed with AAA rather than local authentication. In the case of Mobile IP users, FA-CHAP is required for authentication.

The PDSN includes its own PPAC VSA to inform the HAAA/Billing Server that it supports Prepaid based on Duration (value = 2 or 3). If resource revocation is enabled on the PDSN, the PDSN will send a SessionTerminationCapability (STC) attribute indicating that it can support resource revocation for Mobile IP sessions. The Event_Time attribute (G4, value = 55) will be included in the RADIUS Access-Request message.

The Home RADIUS server performs the regular Authentication and Authorization of the Access Request sent by the user. If the user profile indicates the user is a Prepaid subscriber, the HAAA interfaces with the Billing Server and provides the Billing Server with the prepaid related info for the user as received in the Access Request message.

Step 2 After the Billing Server receives the user's prepaid info, it checks the capabilities of the PDSN (sent in the PPAC VSA). The Billing Server also checks that the user has a valid balance and account status. The Billing Server informs the PDSN that it supports prepaid packet data service that is based on Duration. It also assigns the initial quota for the user, which is typically a fraction of total available quota for the user. The quota allocated for the user is identified by a quota id assigned by Billing Server for that user for the current quota. The Billing Server interfaces with the HAAA and provides this info to the HAAA.

The HAAA encapsulates the prepaid information received for the user in a RADIUS Access-Accept message and sends it to the PDSN. The RADIUS message includes:

A PPAQ VSA that contains the following parameters:

Initialized quota for the user flow specified in DurationQuota parameter

Quota ID for the quota allocated

A threshold value for the quota allocated in DurationThreshold parameter

A PPAC VSA that indicates prepaid service is based on Volume.

For duration based Prepaid packet data service, the Event_Time attribute is used for DurationQuota/DurationThreshold allocation by the Billing Server.

After the PDSN receives the Access-Accept message from AAA, it parses the RADIUS packet and retrieves the attributes inside it. The PDSN stores information in the packet regarding the quota allocated for the flow, and threshold corresponding to the allocated flow. It also stores the Quota-ID allocated corresponding to the quota.

Once the flow for the user comes up (for example, an IP address assigned for Simple IP or MIP RRP received from the HA and sent to the MS), the PDSN starts the timer corresponding to the duration threshold value and duration quota value.

Once the timer expires for the threshold value of the allocated quota for the prepaid flow, the PDSN sends an Access-Request Message to AAA to refresh quota for the prepaid flow. This Access Request message contains a PPAQ VSA, which includes following parameters:

Update-Reason Sub-Type that is set to indicate 'Threshold reached' (= 3)

Quota ID previously received

Used duration in the DurationQuota Sub-Type

The HAAA authorizes the RADIUS packet and, if successful, forwards the prepaid-related information in the packet to the Billing Server.

Step 3 The Billing Server updates its database with the amount of quota used by the user. Since the user indicates quota renewal, the Billing Server apportions a fraction of prepaid account balance of the user. It also assigns a new Quota ID for the current allocated quota and a corresponding threshold value for the assigned quota. This information is passed on to the HAAA.

The HAAA sends the information received from the Billing Server into a RADIUS Access-Accept message to be sent to the PDSN. The attributes that are encapsulated into a PPAQ VSA include:

Quota ID

Allocated quota into DurationQuota parameter

Threshold corresponding to the assigned quota into DurationThreshold parameter.

After the PDSN receives the Access-Accept message from the AAA, it parses the RADIUS packet and retrieves the attributes inside it. The PDSN stores the information in the packet, updates it with the quota allocated for the flow and the current threshold value corresponding to the allocated flow. The PDSN restarts the duration quota timer with the new value received in the Accept-Accept message, and starts the threshold timer with the new threshold value received corresponding to the current quota. It also stores the new Quota-ID allocated for the current quota.

Step 4 The PDSN closes the prepaid flow based on following criteria:

An Access-Request message was sent to renew the quota, and the corresponding Access-Accept message was not received from AAA after a configurable time value. This time value is same as the RADIUS message timeout configured on PDSN.

An Access-Accept was sent to retrieve quota before the Access-Accept can be received, and the remaining DurationQuota is consumed and the timer corresponding to it expires. This event is when the DurationQuota value and the DurationThreshold values become the same.

If this event occurs, the PDSN sends an Access-Request message containing the PPAQ VSA that includes:

Update-Reason Sub-Type to indicate `Quota reached' (= 4)

Amount of quota used by the user in DurationQuota attribute.

The PDSN marks the prepaid flow for deletion, and does not switch any packets through it for the prepaid flow. The PDSN does not delete the prepaid flow immediately, and waits for the response of the Access-Request or timeout of the Access-Request message.

Step 5 The Billing Server does not allocate a new quota when the user indicates "Quota reached" for the prepaid flow. The Billing Server terminates the prepaid flow and indicates the same to the HAAA. HAAA sends an Access-Accept message to the PDSN acknowledging the termination of the Prepaid packet data session by encapsulating Update Reason Sub-type as "Quota is reached" inside PPAQ VSA.

When the PDSN receives the Access Accept message, it clears the user flow for the Prepaid session. As part of the usual off-line accounting procedures, the PDSN sends an off-line RADIUS Accounting-Stop message upon successful release of the appropriate resources.


Volume-based Prepaid Data Service with Tariff Switching

The PDSN and Billing Server support tariff switch, volume- based, Prepaid packet data service. The tariff switch trigger is controlled at the Billing Server. To support this capability, a new sub-Type PrepaidTariffSwitch (PTS) VSA attribute is sent by HAAA to PDSN. This attribute contains following key sub-types:

QuotaId: Quota Id is same as present in PPAQ.

VolumeUsedAfterTariffSwitch (VUATS): Volume switched after Tariff Switch

TariffSwitchInterval (TSI): Interval in seconds between the time stamp (G4) of the corresponding on-line RADIUS Access-Request message and the next tariff switch condition

The following sequence describes the functionality of Prepaid data service when Tariff Switching is enabled.


Step 1 The Prepaid capable PDSN determines that Simple IP or Mobile IP setup requires a RADIUS Access-Request message to be sent to the Home RADIUS Server. For SIP sessions, authentication of the user with AAA has to be done instead of local authentication. In case of Mobile IP users, authentication via FA-CHAP is required.

PDSN includes its own PPAC VSA to inform the HAAA/Billing Server that it supports Prepaid based on Volume (value = 1 or 3). If resource revocation is enabled on the PDSN, then it will send a SessionTerminationCapability (STC) attribute indicating that it can support resource revocation for Mobile IP sessions.

The Home RADIUS server performs the regular Authentication and Authorization of the Access Request sent by the user. If the user profile indicates the user is a Prepaid subscriber, HAAA interfaces with the Billing Server and provides the Billing Server with the prepaid related info for the user as received in the Access Request message.

Step 2 After the Billing Server receives the user's prepaid info, it checks the capabilities of the PDSN that were sent in the PPAC VSA. It also checks that the user has a valid balance and account status. The Billing Server notifies the PDSN that it will support prepaid packet data service that is based on Volume. The Billing Server also assigns the initial quota for the user, which is typically fraction of total available quota for the user. The quota allocated for the user is identified by a quota id assigned by Billing Server for the user. The Billing Server interfaces with the HAAA and provides this info to the HAAA.

The Billing Server that supports Tariff Switching indicates the time (in seconds) remaining for the next tariff switch point, and passes the info to the HAAA server. Optionally, it can include the time after tariff switch point that the PDSN will send Access Request to the HAAA if the threshold value for the assigned quota is not reached.

The HAAA encapsulates the prepaid information received for the user from Billing Server in a RADIUS Access-Accept message and sends it to the PDSN. The RADIUS message includes:

A PPAQ VSA that contains the following parameters:

Initialized quota for the user flow specified in VolumeQuota parameter

Quota ID for the quota allocated

A threshold value for the quota allocated in VolumeThreshold parameter

A PTS VSA that contains the following parameters:

QuotaID as in PPAQ VSA attribute

TariffSwitchInterval indicating the time in seconds remaining before which the tariff switch condition will trigger

TimeIntervalafterTariffSwitchUpdate indicating the duration after tariff switch point when PDSN will send an on-line Access Request if threshold point is not reached.

A PPAC VSA indicating prepaid service is based on Volume.

After the PDSN receives the Access-Accept message from AAA, it parses the RADIUS packet and retrieves the attributes inside it. It stores the information present in the packet regarding the quota allocated for the flow and threshold corresponding to the allocated flow. The PDSN also stores the Quota-ID allocated in the user flow present in the message.

Once the flow for the user comes up (the IP address assigned for Simple IP, or MIP RRP received from the HA and sent to the MS), the PDSN starts metering user's traffic over the flow against the allocated quota. It also starts the timer corresponding to the value received in TariffSwitchInterval attribute so that it is aware when the tariff switch condition is hit. The timer is started by the PDSN only if the timestamp of the Access Request + Tariff Switch Interval is more than the timestamp of the Access Accept message.

QuotaId present in the PTS attribute should be equal to the QuotaId present inside PPAQ. If the 2 values are unequal, the prepaid flow is closed by PDSN.

Step 3 User data (IP datagrams) that flows through each Prepaid flow is accounted in both upstream and downstream directions. The bytes consumed are checked against the quota allocated for the flow by the Billing Server.

Step 4 Once the VolumeThreshold value is reached for the allocated quota for the prepaid flow, the PDSN sends an Access-Request Message to AAA to refresh quota for the user. This RADIUS packet contains a PPAQ VSA, which includes following parameters:

Update-Reason Sub-Type that is set to indicate `Threshold reached' (= 3)

Quota ID previously received

Used volume in the VolumeQuota Sub-Type

The HAAA authorizes the RADIUS packet and if authorization is successful, forwards the prepaid-related information present in the packet to the Billing Server.

Step 5 The Billing Server updates its database with the amount of quota used by the user. Since the user indicates quota renewal, the Billing Server apportions a fraction of prepaid account balance of the user. It also assigns a new Quota ID for the current allocated quota and a corresponding threshold value for the assigned quota. This information is passed on to HAAA.

The Billing Server also indicates to the HAAA, the time remaining in seconds for the next Tariff Switch trigger point.

The HAAA sends the information received from the Billing Server into a RADIUS Access-Accept message to be sent to the PDSN. The attributes that are encapsulated into a PPAQ VSA include:

Quota ID

Allocated quota into VolumeQuota parameter

Threshold corresponding to the assigned quota into VolumeThreshold parameter

The Attributes encapsulated inside PTS attribute includes:

QuotaID, same as the PPAQ attribute

TariffSwitchInterval that indicates the time (in seconds) remaining before which the tariff switch condition will trigger.

TimeIntervalafterTariffSwitchUpdate that indicates the duration after tariff switch point when the PDSN will send an on-line Access Request if threshold point is not reached.

After the PDSN receives the Access-Accept message from AAA, it parses the RADIUS packet and retrieves the attributes inside it. It stores the information present in the packet updating with the quota allocated for the flow and the current threshold value corresponding to the allocated flow. It also stores the new Quota-ID allocated for the current quota.

Additionally, the PDSN re-starts the timer indicated in TariffSwitchInterval attribute. This time indicates the time remaining in seconds before the next tariff switch condition will be hit.

Step 6 User data (IP datagrams) continues to flow through the Prepaid flow, and is accounted in both upstream and downstream directions. The bytes consumed are checked against the quota allocated for the flow.

Step 7 The timer for the tariff switch interval expires, and indicates the tariff switch point for the flow is hit. The PDSN continues to count the total number of octets flowing through the session in upstream and downstream direction, and also the number of bytes switched by the PDSN after the tariff switch trigger point. If TimeIntervalafterTariffSwitchUpdate was sent by AAA, then the PDSN will start a timer with this value after the tariff switch point is reached.

Step 8 User data (IP datagrams) that flows through each Prepaid flow continues to be accounted in both upstream and downstream directions until the next threshold point is reached. The PDSN counts the total number of bytes switched till last quota update, and also the total number of bytes switched by PDSN after the Tariff Switch trigger point is hit. The bytes consumed are checked against the quota allocated for the flow.

Step 9 Once the VolumeThreshold value is reached for the quota allocated in VolumeQuota value for the flow or timer corresponding to TimeIntervalafterTariffSwitchUpdate expires, the PDSN sends quota update information in an Access Request Message to AAA and Billing Server. This on-line RADIUS Access-Request message contains following attributes in the PPAQ VSA:

Update-Reason Sub-Type that is set to indicate "Threshold reached" (= 3) if threshold is reached. Otherwise, it is set to indicate "Tariff Switch Update" (=9) if TimeIntervalafterTariffSwitchUpdate expires

The Quota ID previously received

The utilized volume in the VolumeQuota Sub-Type

The PTS attribute contains following subtypes:

Quota ID previously received

VolumeUsedAfterTariffSwitch (VUATS) attribute, that contains the total number of octets being switched by the PDSN after tariff switch trigger point.

The HAAA authorizes the RADIUS packet and, if authorization is successful, forwards the prepaid-related information present in the packet to the Billing Server.

The Billing Server updates its database with the amount of quota utilized by the user. Since the user indicates quota renewal, the Billing Server apportions a fraction of prepaid account balance of the user. It also assigns a new Quota ID for the current allocated quota and a corresponding threshold value for the assigned quota. This information is passed on to the HAAA.

The Billing Server also indicates to the HAAA the time remaining in seconds for the next Tariff Switch trigger point.

The HAAA sends the information received from the Billing Server into a RADIUS Access-Accept message to be sent to PDSN. The attributes that are encapsulated into a PPAQ VSA include:

New Quota ID for the current quota

Allocated quota into VolumeQuota parameter

Threshold corresponding to the assigned quota into VolumeThreshold parameter

The PTS attribute contains following subtypes:

Quota ID previously received

TariffSwitchInterval that indicates the time (in seconds) remaining before which the tariff switch condition will trigger.

Optionally TimeIntervalafterTariffSwitchUpdate that indicates the duration after the tariff switch point when the PDSN will send an on-line Access Request if threshold point is not reached.

After the PDSN receives the Access-Accept message from AAA, it parses the RADIUS packet and retrieves the attributes inside it. The PDSN stores the information present in the packet, and updates it with the quota allocated for the flow and the current threshold value corresponding to the allocated flow. It also stores the new Quota-ID allocated for the current quota.

Additionally, the PDSN re-starts the timer indicated in TariffSwitchInterval attribute. The PDSN starts the timer only if the timestamp of the Access Request + Tariff Switch Interval is more than the timestamp of the Access Accept message. This time indicates the time remaining in seconds before the next tariff switch condition will be hit.


Support for G17 Attribute in Acct-Stop and Interim Records

The G17 attribute is required to bill users based on when the last activity was detected rather than when the user is de-registered. The following scenario gives a brief on how the attribute is used and how AAA needs to identify the last user activity.

G17 is defined as last user activity to indicate the time when the last activity was detected by the user. The G17 attribute is sent in acct-stop and interim accounting update messages, and has the following usage guidelines:

Configure support for the G17 attribute by issuing the cdma pdsn attribute send g17 command

The attribute is not included in acct-start record and included only in accounting stop/interim-update.

The attribute is set to 0 when an airlink start record arrives.

The attribute is set to the current time when airlink active stop arrives.

The attribute is set to 0 once the acct-stop record is sent out.

The G17 attribute is useful under the following conditions:

When the cdma pdsn accounting send start-stop command is not configured.

A session goes dormant. G17 is recorded with the current time. As the above CLI is not configured, there is no accounting stop generated.

The PDSN will continue to send interim update accounting records for this session. These messages will contain G17 with the value recorded with time when airlink-stop was received.

When the mobile finally deregisters (and receives an A11 RRQ with lft = 0, and w/o an airlink STOP), the PDSN sends an accounting stop with the G17 attribute that was recorded earlier when airlink-stop was received. This gives the real value of time when last user activity was detected.

When the cdma pdsn accounting send start-stop command is configured.

The PDSN will generate an accounting stop when an airlink-stop is received from the PCF. This acct-stop will contain the G17 recorded with time when airlink-stop was received.

G17 is reset once the acct-stop is sent out. finally when the session ends, the accounting stop would have G17 as 0.

AAA server needs to use the previous value of G17 to find out the last user activity.

Home Area, Maximum Authorized Aggregate Bandwidth and Inter-user Priority Attributes Downloaded from AAA

The home-area, inter-user priority and maximum authorized aggregate bandwidth attributes are received by the PDSN, and are forwarded to the PCF as part of subscriber QoS profile (NVSE) structure. Local configurations of these attributes are not supported in PDSN 3.5.

The subscriber QoS profile is carried to the PCF in the following messages from the PDSN:

A11 session update when a session is newly created.

A11 Registration reply during inter-PCF handoff.

All of these attributes are synchronized to the standby in session redundancy

Basic Operation

If any home-area, inter-user priority, or maximum authorized aggregate bandwidth attributes are downloaded from AAA, and parsed successfully, they are stored on the PDSN and forwarded to the PCF as part of subscriber QoS profile structure.

The home-area attribute is sent to the PCF only if the cdma pdsn pcf PCF IP address [ending IP address] vendor-id NVSE Vendor id command is configured.

The vendor specific attributes that are added in subscriber QoS profile are based on the configuration.

The subscriber QoS profile is sent to the PCF in either A11 RRP or A11 session update messages.

If the maximum authorized aggregate bandwidth attribute is downloaded then bandwidth policing for the session based on this attribute is applied on the PDSN.

When a user session is created these attributes are sent to PCF through A11 session update message.

In case of inter PCF handoff these attributes are sent in an A11 session update message, or in an A11 RRP message.

The A11 messages with subscriber QoS profile included are sent to the PCF from PDSN only if the cdma pdsn a11 session-update qos command is configured.

Bandwidth policing based on the maximum authorized aggregate bandwidth is applied only if the cdma pdsn a10 police downstream command is configured.

If the AAA attributes received are of invalid length, then the access-accept is dropped and session creation fails on PDSN.

If the attribute values received at the PDSN are not in the given range then the attributes are ignored.

If an unknown attribute is received the attribute is ignored.

If multiple instances of the same attribute are downloaded, the maximum value of the downloaded attribute is taken.

Local configuration of the subscriber QoS profile is not supported in PDSN 3.5.

When new or multiple values of the given attributes as received in access accept, the values on the PDSN are updated as follows:

The home area attribute downloaded for last flow is maintained.

The maximum of the maximum authorized aggregate bandwidth and inter-user priority attributes are maintained.

In case of PPP re-negotiation, the values of the attributes maintained in the session are reset and the values received in the access-accept are applied.

Traffic exceeding or violating the downloaded bandwidth is not accounted for in the session.

Subscriber QoS Profile

Subscriber QoS profile consists of the following attributes that are downloaded from AAA:

Maximum authorized aggregate bandwidth

Home area defined by Lucent.

Inter-user priority

These attributes are stored in the PDSN, and are forwarded to the PCF as part of subscriber QoS profile. The A11 registration reply, or A11 session-update, carries the subscriber QoS profile to PCF.

The subscriber QoS profile, carried in A11 messages to the PCF, is packed as an NVSE with the attributes as RADIUS VSAs.

Bandwidth Policing

During authentication of the mobile with the AAA, the maximum authorized aggregate bandwidth attribute may be downloaded from AAA as part of an access-accept. If this attribute is downloaded, the PDSN creates a policy internally and associates it with the session. The traffic to the mobile is then policed based on the value downloaded. When the session goes down, the policy is also removed.

Session Redundancy

The downloaded attributes are always synced to the standby PDSN using the existing Session Redundancy infrastructure whenever the flow is created, or during handoff.

When the switchover happens, the policing starts over in the newly active box because fresh tokens are allocated in the bucket.

Configuring Subscriber Qos Profile to PCF

To enable the PDSN to send Subscriber QoS profiles to the PCF through session updates, perform the following task:

 
Command
Purpose

Step 1 

router(config)# cdma pdsn a11 session-update qos

Enables you to send the subscriber Qos profile to the PCF through a Session Update. The existing timeout and retransmit a11 session-update configurations apply to this command too.

Configuring Bandwidth Policing

To configure policing of down stream data traffic for the session, perform the following task:

 
Command
Purpose

Step 1 

router(config)#[no] cdma pdsn a10 police downstream

Enables you to police of down stream data traffic for the session. This command is configured based on maximum authorized aggregate bandwidth value downloaded from AAA.

Configuring VSAs in Subscriber QoS Profiles

To configure the sending of vendor specific attributes in Subscriber QoS Profile, perform the following task:

 
Command
Purpose

Step 1 

router(config)# cdma pdsn pcf PCF IP address ending IP address vendor-id NVSE Vendor id

Enables you to send a Subscriber QoS profile through A11 session-update and A11 RRP.

PCF IP Address—Single or starting PCF IP address

Ending PCF IP Address—Ending PCF IP address

NVSE Vendor Id—Radius vendor ID of PCF


Note This configuration is not required for 3gpp or 3gpp2 attributes.


Here is a sample configuration:

cdma pdsn virtual-template 1
cdma pdsn a10 max-lifetime 65535
cdma pdsn a10 ahdlc engine 0 usable-channels 8000
cdma pdsn a10 police downstream
cdma pdsn a11 session-update qos
cdma pdsn pcf 10.1.1.1 10.1.1.50 vendor-id 3729
cdma pdsn timeout mobile-ip-registration 10
cdma pdsn timeout a11-session-update 3
cdma pdsn send-agent-adv
cdma pdsn debug show-conditions
cdma pdsn secure pcf 150.1.4.1 spi 100 key ascii cisco
cdma pdsn secure pcf 150.1.4.10 150.1.4.18 spi 100 key ascii cisco
cdma pdsn secure pcf 150.1.4.25 spi 100 key ascii cisco
cdma pdsn secure pcf 150.1.4.123 spi 100 key ascii cisco
cdma pdsn secure pcf 150.1.4.223 spi 100 key ascii cisco
cdma pdsn secure pcf 150.1.4.224 spi 100 key ascii cisco
cdma pdsn compliance is835a handoff

Verifying the Configuration

To verify that these various attributes are sent, perform the following tasks:

 
Command
Purpose

Step 1 

router# show cdma pdsn

Displays the status and current configuration of the PDSN.

Step 2 

router# show cdma pdsn session

Displays the session information on the PDSN.

Step 3 

router# show cdma pdsn statistics

Displays VPDN, PPP, RP interface, Closed-RP interface and error statistics for the PDSN

Here are some examples:


router# show cdma pdsn
PDSN software version 3.5, service is enabled

  A11 registration-update timeout 1 sec, retransmissions 5
  Mobile IP registration timeout 10 sec
  A10 maximum lifetime allowed 65535 sec
  GRE sequencing is on
  Maximum PCF's limit set to 2000
  Maximum sessions limit not set (default 974 maximum)
  SNMP failure history table size 100
  MSID Authentication is disabled
  Ingress address filtering is disabled
  Sending Agent Adv in case of IPCP Address Negotiation  is enabled
  Allow CI_ADD option during IPCP Phase  is disabled
  Aging of idle users disabled
  Radius Disconnect Capability enabled
  
  Number of pcfs connected 0,
  Number of pcfs 3GPP2-RP 0, 
  Number of sessions connected 0,
  Number of sessions 3GPP2-RP 0, 
  Number of sessions Active 0, Dormant 0, 
  Number of sessions using HDLCoGRE 0, using PPPoGRE 0

router# show cdma pdsn session
Mobile Station ID IMSI 123456789123457
  PCF IP Address 5.1.1.46, PCF Session ID 1
  A10 connection time 119:19:10, registration lifetime 1800 sec
  Number of successful A11 re-registrations 357
  Remaining session lifetime 650 sec
  Always-On not enabled for the user
  Current Access network ID 0005-0101-2E
  Last airlink record received is Unknown, airlink is active
  GRE protocol type is 0x8881
  GRE sequence number transmit 9, receive 7
  Using interface Virtual-Access2.1, status OPN
  Using AHDLC engine on slot 0, channel ID 4381
  Service Option Ev-DO
  Police Downstream CIR(bps) 8000, 
    Normal Burst(bytes) 1500, Excess Burst(bytes) 3000
    Packets Conformed 0 Exceeded 0 Dropped packets 0
  This session has 1 flow
  Session Airlink State Active
  QoS Parameters:
    Max Aggregate Bandwidth: 8000
    Home Area              : 10
    Inter User Priority    : 15
 
  Flow service Simple, NAI NAI gSIP1@xxx.com
    Mobile Node IP address 32.1.35.203
    Packets in 0, bytes in 0
    Packets out 0, bytes out

router# show cdma pdsn statistics
Bandwidth policing:
  Policing installed 0 failure 0 uninstalled 0

Mobile IP Call Processing Per Second Improvements

In previous Cisco PDSN Releases, the Mobile IP CPS rate was approximately 40—comparatively low to that of Simple IP CPS which around 125. Mobile IP CPS was low because some of the Mobile IP configurations are interface specific. When these configurations are applied to the virtual-template interface (which is typical for the PDSN software), it takes considerable time to clone the virtual-access from the Virtual-Template because of the presence of the Mobile IP configuration, and this directly affects the CPS for Mobile IP service. The virtual-access are cloned when the calls are setup. To reduce virtual-access cloning time, PDSN Release 2.1 supports commonly used per-interface configurations in global configuration mode, and supports per-interface for backward compatibility.

Always On Feature

The PDSN supports Always On service to maintain the subscriber's packet data session in the local network. Always On support dictates that the PDSN will not release a subscriber's packet data session due to PPP idle timer expiry unless the PDSN determines the user is no longer reachable.

The Always On service maintains a subscriber's packet data session irrespective of PPP inactivity timer value for the user. At the same time, by making use of a finite PPP inactivity timer value, this feature provides a way to keep a session only as long as the user is reachable. The PDSN uses LCP Echos (as per rfc1661 and IS835B) to determine if the user is reachable.

Always On service is enabled for a user only when the F15 "Always On" attribute is received and set to a value of 1 in the access accept message from the AAA server.

The PDSN supports the ability to configure the Echo-Reply-Timeout timer and Echo-Request-Attempts counter. There is no extra configuration required on the PDSN to enable the Always On feature itself; however, you can disable the feature by configuring the Echo-Request-Attempts to 0. The PPP inactivity timer will be started for a session entering IPCP open state, if is configured or retrieved from AAA, for the user.

For always on users:

1. Upon expiration of the inactivity timer, Echo-Request-Attempts counter is initialized to the configured value.

2. If the Echo-Request-Attempts counter is zero, the PPP session is torn down. If the Echo-Request-Attempts counter is nonzero, an LCP Echo-Request message is sent, the Echo-Request-Attempts counter is decremented, and the Echo-Reply-Timeout timer is started.

3. Upon receipt of corresponding LCP Echo-Reply message, Echo-Reply-Timeout timer is stopped and PPP inactivity timer is restarted.

4. Upon expiration of Echo-Reply-Timeout timer, repeat from number 2 above.

This feature is not supported for VPDN users, and is not applicable to Mobile IP users.

For Always-on users, a value of "1" will be sent for F15 attribute in the accounting start/stop/interim records. For non-always-on users, the F15 attribute will only be sent in the accounting records if configured.

Restrictions for the Always On Feature:

The Always On implementation follows the IS835B standard; the IS835C specific additions are not available in this release of PDSN.

Echo-Reply is the only packet that will stop always-on timer.

Basically it means even if there is upstream/downstream data received, the session will be teared down unless Echo-reply received within configured number of retries and configured time interval.

Always-on feature is not applicable for mobileip users.

Always-on feature is not supported for VPDN users.

Aging of Dormant PPP sessions feature works independent of always-on users. The aging of dormant PPP sessions feature does not care for the always-on property of a session.

PDSN MIB Enhancements

The following new objects are created as part of the PDSN 4.0 software release:

SystemInfo - Global level on the PDSN

PolicingEnabled - Boolean indicating Policing is enabled or not.

SessionsWithAuxiliaryConnectionsTotal - Number of sessions with auxiliary connections.

TotalBandwidth - Total bandwidth of the box as configured through CLI.

AvailableBandwidth - Remaining bandwidth available for new sessions.

ccpCdmaExtAllocatedBandwidth - Specifies the allocated bandwidth.

SessionMaxAuxConnectionsAllowed-Number of Auxiliary connections supported by pdsn per session

SessionServiceFlowsTotal-Number of A10 service flows currently established with the PDSN.

AuxSessionTotal- Number of sessions with auxiliary sessions currently established with the PDSN.

PolicingSessionTotal - Number of sessions with policing enabled currently established with the PDSN.

PDSNIpAddress- An IPv4 address identifying a PDSN. You can only access this object through notification.

DSCPSession-Number of sessions with DSCP enabled currently established with the PDSN.

ccpCdmaExtLoadHighReachedNotifEnabled - Indicates if trap is enabled, or not.

SessionAuxConnectionsEnabled - Boolean indicating PDSN system supports auxiliary a10 connections for the session or not.

Pcf Based Table:

SessionsWithAuxiliaryConnectionsTotal - Number of sessions with auxiliary connections associated with the PCF.

NewAuxConnections - Number of A11 registration messages received per PCF at PDSN to establish new auxiliary a10 connections.

ccpCdmaExtPcfSoRpRegStatsBwUnavailableSess -

ReRegNewAuxConnections - Number of A11 re-registration messages received per PCF at PDSN to establish new auxiliary a10 connections.

RemapFlows - Number of A11 registration/re-registration messages received per PCF at PDSN, indicating a change of a10 connection to flow-id mapping for the session.

CloseAuxConnections -Number of A11 re-registration messages received per PCF at PDSN indicating removal of A10 connections (missing a10 auxiliary connections existing for the session).

SessionUpdSubscriberQos -Number of A11 session update messages per PCF received at PDSN

RegReqMaxServiceFlows - Number of A11s that were rejected per PCF because maximum auxiliary connections per session reached

RegReqUnSupportedSO - Number of A11s that were rejected per PCF because additional session NVSE contained unsupported Service Option

RegReqNonExistA10 - Number of A11s that were rejected per PCF because IP flow mapping contained a mapping to a non-existent A10.

ccpCdmaExtPDSNIpAddrType - access via notify

ccpCdmaExtPDSNIpAddress - access via notify

ccpCdmaExtNotifReason - access via notify

ccpCdmaExtNotifReasonCurrentValue - access via notify

Here is an example of these objects:

Due to CPU Low Reason:
===========================

Received SNMPv2c Trap:
Community: public
From: 9.11.51.83
sysUpTime.0 = 20545
snmpTrapOID.0 = ciscoCdmaExtLoadLowReachedNotif
ccpCdmaExtPDSNIpAddrType.0 = ipv4(1)
ccpCdmaExtPDSNIpAddress.0 = 03 04  53 67   
ccpCdmaExtNotifReason.0 = cputhreshold(2)
ccpCdmaExtNotifReasonCurrentValue.0 = 27

Bandwidth Policies

ccpCdmaExtBandwidthPolicyInstallSuccesses - bandwidth installed to the session.

ccpCdmaExtBandwidthPolicyInstallFailures - bandwidth installed failure to the session.

ccpCdmaExtBandwidthPolicyRemoves - removal of bandwidth installation from the session by clearing the session.

RPErrors

BandwidthUnavailable - Number of A11s that were rejected because Bandwidth was not available

RegReqMaxServiceFlows - Number of A11s that were rejected because maximum auxiliary connections per session reached

RegReqUnSupportedSO - Number of A11s that were rejected because additional session NVSE contained unsupported Service Option

RegReqNonExistA10 - Number of A11s that were rejected because IP flow mapping contained a mapping to a non-existent A10.

RPSessUpdates

SessionUpdSubscriberQos-Number of A11 session update messages sent from PDSN to PCF.

RSVPStats

TFTCreationSuccesses -Number of TFTs created successfully

TFTCreationFailure -Number of TFTs creation failed

TFTPacketFilterAddFailure-Number of packet filters not added to requested TFT.

TFTPacketFilterUnavailable -Number of packet filters not available on requested TFT.

TFTPacketFilterReplace -Number of packet filters replaced on existing TFT.

TFTPacketFilterAddBeforeCreation -Number of packet filters added to persistent TFT.

TFTUnableToParse -Number of TFTs unable to parse on PDSN.

TFTUnauthorized - Number of unauthorized TFTs received on PDSN

TFTPrecedenceContention -Number of TFTs that have contention in the packet filter evaluation precedence value.

TFTTreatmentUnsupported - Number of TFTs that have received MS flows treatment values that are not supported on PDSN

TFTMaxPacketFiltersReached - Number of TFTs that have reached maximum allowed number of packet filters.

QOSStats

QOSSuccess -Number Qos profiles that have been successfully applied on sessions.

QOSFailure -Number Qos profiles failed to be applied on sessions.

QOSDscpRemarked-Number of packets remarked at the PDSN.

RpStats

NewAuxConnections- Number of A11 registration messages received at PDSN to establish new auxiliary a10 connections.

ReRegNewAuxConnections-Number of A11 re-registration messages received at PDSN to establish new auxiliary a10 connections.

RemapFlows- Number of A11 registration/re-registration messages received at PDSN, indicating a change of a10 connection to flow-id mapping for the session.

CloseAuxConnections-Number of A11 re-registration messages received at PDSN indicating removal of A10 connections (missing a10 auxiliary connections existing for the session).

SessionUpdSubscriberQos-Number of A11 session update messages received at PDSN.

CAC

The following NotificationObjects are introduced as part of Call Admission Control

LoadThresholdHighReached-PDSN has reached the maximum load.

LoadThresholdLowReached-PDSN has reached the minimum load.

PPP Counters in Release 3.0

Objects have been added under the following existing MIB subgroups:

cCdmaPppSetupStats

cCdmaPppReNegoStats

cCdmaPppAuthStats

cCdmaPppReleaseStats

cCdmaPppMiscStats

The below table describes the list of PPP counters that have been added in R3.0.

Table 9 PPP Counters in Release 3.0 

CDMA PPP MIB Subgroup
Counter Description

cCdmaPppSetupStats

 

PPP stats - LCP Failure - option issue

Total number of PPP calls failed by LCP option negotiation failure.

PPP stats - IPCP failure option-issue

Total number of PPP calls failed by IPCP option negotiation failure.

PPP stats - Authentication aborted

Total number of PPP calls failed by authentication max-retry.

Session Disc - no remote-ip address:

Total number of sessions released because MN rejects IP address allocated by PDSN.

PPP stats - Lower layer disconnected:

Total number of calls released by RP layer.

PPP stats - TermReq-From-MN-IPCP:

LCP Term-Req received from MS During IPCP

PPP stats - TermReq-From-PDSN-IPCP:

LCP Term-Req Sent from PDSN During IPCP

PPP stats - TermReq-From-PDSN-Auth:

LCP Term-Req Sent from PDSN During Authentication

PPP stats - TermReq-From-MN-Auth:

LCP Term-Req received from MS During Authentication

PPP stats - TermReq-From-PDSN-LCP:

LCP Term-Req Sent from PDSN During LCP

PPP stats - TermReq-From-MN-LCP:

LCP Term-Req received from MS During LCP

PPP stats - A10Release-PCF-preLCP :

A10 Released by PCF before LCP stage

PPP stats - A10Release-PDSN-preLCP :

A10 Release by PDSN before LCP stage

PPP stats - A10Release-PCF-LCP :

A10 Released by PCF During LCP stage without LCP Term-Req

PPP stats - A10Release-PDSN-LCP :

A10 Released by PDSN During LCP stage without LCP Term-Req

PPP stats - A10Release-PCF-Auth:

A10 Released by PCF During Authentication without LCP Term-Req

PPP stats - A10Release-PDSN-Auth

A10 Released by PDSN During Authentication without LCP Term-Req

PPP stats - A10Release-PCF-IPCP :

A10 Released by PCF During IPCP stage without LCP Term-Req

PPP stats - A10Release-PDSN-IPCP :

A10 Released by PDSN During IPCP stage without LCP Term-Req

PPP stats - LCP - success :

PPP connections that finished LCP successfully

PPP stats - auth - success :

PPP connections that finished AUTH successfully

PPP stats - IPCP - success :

PPP connections that finished IPCP successfully

cCdmaPppReNegoStats

 

Session Reneg - Lower layer handoff:

Total number of sessions renegotiated due to PANID/CANID comparison during handoff.

cCdmaPppAuthStats

 

Session Authen- CHAP auth timeout:

MN does not respond for CHAP request.

Session Authen- PAP auth timeout:

PDSN does not receive PAP request from MN.

Session Authen- MSCHAP auth timeout:

MN does not respond for MSCHAP request.

Session Authen- sessions skipped PPP Auth:

Total number of sessions skipped PPP authentication.

cCdmaPppReleaseStats

 

PPP stats - release - pcf deregister:

PPP connections released as PCF sends deregistration

PPP stats - release - lifetime expiry:

PPP connections released due to life timer expiry

cCdmaPppMiscStats

 

Session Data Compress - CCP negotiation failures:

Total number of sessions failed CCP negotiation.

LCP Echo Stats - total LCP Echo Req. sent:

Total transmission of LCP Echo Request.

LCP Echo Stats - LCP Echo Req. resent:

Total retransmission of LCP Echo Request.

LCP Echo Stats - LCP Echo Reply received:

Total received LCP Echo Reply.

LCP Echo Stats - LCP Echo Request timeout:

Total LCP Echo Request timeout.

Receive Errors - unknown protocol errors:

Total packets which protocol value cannot be identified out of packets received at PPP stack.

Receive Errors - bad pkt length:

Total bytes discarded with reasons above.


RP Counters in Release 3.0

The following list identifies new MIB subgroups in Release 3.0:

cCdmaRPRegReqErrors

cCdmaRPRegUpdAckErrors

cCdmaRPSessUpdAckErrors

cCdmaRPRegReplyErrors

cCdmaRPRegUpdErrors

cCdmaRPSessUpdErrors

cCdmaRpSessUpdStats

cCdmaPcfSoRpSessUpdStats

The following list identifies existing MIB subgroups, under which objects are added:

cCdmaTrafficStats

cCdmaPcfSoRpRegStats

cCdmaPcfSoRpUpdStats

cCdmaSystemInfo

cCdmaRpRegStats

Table 6 indicates the additional RP counters supported in Release 3.0:

Table 10 RP Counters Supported in Release 3.0 

CDMA PPP MIB Subgroup
Counter Description

cCdmaSystemInfo

 

sysInfo - PPPoGREsessions

The total number of PPPoGRE sessions currently established with this system.

sysInfo-HDLC-GREsessions

The total number of HDLCoGRE sessions currently established with this system.

sysInfo-totalSessions

The total number of sessions established since system was last restarted.

sysInfo-totalReleases

The total number of sessions released since system was last restarted.

sysInfo-totalMSIDFlow

The total number of flows currently using MSID service.

sysInfo-totalVPDNFlow

The total number of flows currently using VPDN service.

cCdmaRpRegStats

 

RegStats-Reqs

The number of Initial A11 Registration requests received since system was last restarted.

RegStats-Disc

The number of Initial A11 Registration requests silently discarded since system was last restarted.

RegStats-ReregReqs

The number of A11 Re-Registration requests received since system was last restarted.

RegStats-ReregDisc

The number of A11 Re-Registration requests silently discarded since system was last restarted.

RegStats-DeregReqs

The number of A11 De-Registration requests received since system was last restarted.

RegStats-DeregDisc

The number of A11 De-Registration requests silently discarded since system was last restarted.

RegStats-HandoffReqs

The number of A11 Handoff Registration requests received since system was last restarted.

RegStats-HandoffAccepted

Total number of accepted handoff A11 Registration Requests meant for already existing session, since the system was last restarted.

RegStats-HandoffDenied

Total number of denied handoff A11 Registration Requests meant for already existing session, since the system was last restarted.

RegStats-HandoffDisc

The number of handoff A11 Registration requests silently discarded since system was last restarted.

RegStats-ReregAirlinkStart

The number of A11 Re-Registration requests containing Airlink Start since system was last restarted.

RegStats-ReregAirlinkStop

The number of A11 Re-Registration requests containing Airlink Stop since system was last restarted.

RegStats-DeregAirlinkStop

The number of Inter PCF active handoff since system was last restarted.

RegStats-HandoffInterPCFActive

The number of A11 De-Registration requests containing Airlink Stop since system was last restarted.

RegStats-HandoffInterPCFDormant

The number of Inter PCF dormant handoff since system was last restarted.

cCdmaRpSessUpdStats

 

SessUpdStats-TransReqs

Total number of A11 Session Updates transmitted since system was last restarted.

SessUpdStats-AcceptedReqs

Total number of A11 Session Update Acknowledgements received with the Status field set to zero (indicating that the corresponding Registration Update was accepted), since system was last restarted.

SessUpdStats-DeniedReqs

Total number of A11 Session Update Acknowledgements received with the Status field set to non-zero indicating that the corresponding Registration Update was denied, since system was last restarted.

 SessUpdStats-NotAckedReqs

Total number of A11 Session Update Updates sent, for which no corresponding A11 Registration Acknowledgements received, since system was last restarted.

SessUpdStats-TransReqs

Total number of initial A11 Session Updates sent, excluding the re-transmitted A11 Registration Updates, since system was last restarted.

SessUpdStats-RetransReqs

Total number of re-transmitted A11 Session Updates, since system was last restarted.

SessUpdStats-RecAcks

Total number of A11 Session Update Acknowledgements received, since system was last restarted.

SessUpdStats-DiscAcks

Total number of A11 Session Update Acknowledgements discarded, since system was last restarted.

SessUpdStats-AlwaysON

Total number of initial A11 Session Updates sent due to Always On since system was last restarted. Note that this count does not include any retransmissions.

SessUpdStats-RNPDIT

Total number of initial A11 Registration Updates sent due to RNPDIT value downloaded, since system was last restarted. Note that this count does not include any retransmissions.

SessUpdStats-UnSpecFail

The number of session update registrations failed for unspecified reason since system was last restarted.

SessUpdStats-ParamNotUpd

The number of session update registrations failed for session parameters not updated reason since system was last restarted.

SessUpdStats-MNAuthenFail

The number of session update registrations failed due to MN authentication failure since system was last restarted.

SessUpdStats-IdentMismatchFail

The number of session update registrations failed due to registration identity mismatch since system was last restarted.

SessUpdStats-BadReqsFail

The number of session update registrations failed due to poorly formed request since system was last restarted.

cCdmaTrafficStats

 

trafficStats-SDBPaks

Total number of SDB marked data packets sent to PCF from PDSN since system was last restarted.

trafficStats-SDBOctets

Total number of SDB marked data octets sent to PCF from PDSN since system was last restarted.

cCdmaPcfSoRpRegStats

 

PcfSoRegStats-InitRegReqs

The number of Initial A11 Registration requests received since system was last restarted.

PcfSoRegStats-InitRegDisc

The number of Initial A11 Registration requests silently discarded since system was last restarted.

PcfSoRegStats-RegReqs

The number of A11 Re-Registration requests received since system was last restarted.

PcfSoRegStats-ReregDisc

The number of A11 Re-Registration requests silently discarded since system was last restarted.

PcfSoRegStats-DeregReqs

The number of A11 De-Registration requests received since system was last restarted.

PcfSoRegStats-DiscardedReqs

The number of A11 De-Registration requests silently discarded since system was last restarted.

PcfSoRegStats-RcvdReqs

The number of A11 Handoff Registration requests received since system was last restarted.

PcfSoRegStats-AcptdReqs

Total number of accepted handoff A11 Registration Requests meant for already existing session, since the system was last restarted.

PcfSoRegStats-DeniedReqs

Total number of denied handoff A11 Registration Requests meant for already existing session, since the system was last restarted.

PcfSoRegStats-Disc

The number of handoff A11 Registration requests silently discarded since system was last restarted.

PcfSoRegStats-ReregAirlinkStart

The number of A11 Re-Registration requests containing Airlink Start since system was last restarted.

PcfSoRegStats-ReregAirlinkStop

The number of A11 Re-Registration requests containing Airlink Stop since system was last restarted.

PcfSoRegStats-DeregAirlinkStop

The number of A11 De-Registration requests containing Airlink Stop since system was last restarted.

cCdmaPcfSoRpUpdStats

 

PcfSoHandoffUpdStats

The number of update registrations sent as a result of inter pcf handoffs, since system was last restarted.

PcfSoHandoffUpdStats-NotAckedReqs

Total number of A11 Registration Updates (sent as the result of inter PCF handoffs), for which no corresponding A11 Registration Acknowledgements received, since system was last restarted.

PcfSoHandoffUpdStats-RecAcks

Total number of A11 Registration Acknowledgements received for the A11 Registration Updates sent as the result of inter PCF handoffs, since system was last restarted.

PcfSoHandoffUpdStats-AcceptReqs

Total number of A11 Registration Acknowledgements received with the Status field set to zero (indicating that the corresponding Registration Update was accepted), since system was last restarted.

PcfSoHandoffUpdStats-DeniedReqs

Total number of A11 Registration Acknowledgements received with the Status field set to non-zero indicating that the corresponding Registration Update was denied, since system was last restarted.

PcfSoHandoffUpdStats-DiscAcks

Total number of A11 Registration Acknowledgements discarded, since system was last restarted.

PcfSoHandoffUpdStats-TxdReqs

Total number of initial A11 Registration Updates sent as the result of inter PCF handoffs, excluding the re-transmitted A11 Registration Updates, since system was last restarted.

PcfSoHandoffUpdStats-RetxdReqs

Total number of re-transmitted A11 Registration Updates as the initial Registration Update (sent as a result of inter PCF handoffs) was not acked or denied, since system was last restarted.

PcfSoHandoffUpdStats-UnknownFail

The number of update registrations failed for unspecified reason since system was last restarted. The update is sent as a result of inter PCF handoff.

PcfSoHandoffUpdStats-AdminProhibitFail

The number of update registrations failed due to administrative prohibition since system was last restarted. The update is sent as a result of inter PCF handoff.

PcfSoHandoffUpdStats-MNAuthenFail

The number of update registrations failed due to MN authentication failure since system was last restarted. The update is sent as a result of inter PCF handoff.

PcfSoHandoffUpdStats--IdMismatch

The number of registrations failed due to registration identity mismatch since system was last restarted. The update is sent as a result of inter PCF handoff.

PcfSoHandoffUpdStats-BadReqs

The number of update registrations failed due to poorly formed request since system was last restarted. The update is sent as a result of inter- PCF handoff.

cCdmaRPRegReqErrors

 

RegReqErr-PakLen

Invalid Registration request packet length while parsing since system was last restarted.

RegReqErr-Protocol

Invalid Protocol value in the Registration Request Session Specific Extension since system was last restarted.

RegReqErr-Flags

Invalid Flags value in the Registration Request since system was last restarted.

RegReqErr-MHAEKey

Invalid Authentication key in the Registration Request Mobile-Home Authentication extension since system was last restarted.

RegReqErr-SPIMismatch

Mismatch in SPI in the Registration Request Mobile-Home Authentication extension since system was last restarted.

RegReqErr-SPI

Invalid SPI in the Registration Request Mobile-Home Authentication extension since system was last restarted.

RegReqErr-ConnId

Invalid Connection ID in the Registration Request since system was last restarted.

RegReqErr-MNID

Invalid MN ID in the Registration Request since system was last restarted.

RegReqErr-MNIDType

Invalid MN ID type in the Registration Request since system was last restarted.

RegReqErr-MSIDLen

Invalid MSID length in the Registration Request since system was last restarted.

RegReqErr-SSE

Session Specific extension missing in the Registration Request since system was last restarted.

RegReqErr-MHAE

Mobile-Home Authentication extension missing in the Registration Request since system was last restarted.

RegReqErr-Order

Invalid order of the extensions in the Registration Request since system was last restarted.

RegReqErr-VSE

Invalid Vendor specific extensions in the Registration Request since system was last restarted.

RegReqErr-AppType

Invalid Application type in Vendor specific extensions in the Registration Request since system was last restarted.

RegReqErr-DupAppType

Duplicate Application type in Vendor specific extensions in the Registration Request since system was last restarted.

RegReqErr-AppSubType

Invalid Sub Application type in Vendor specific extensions in the Registration Request since system was last restarted.

RegReqErr-VendorId

Invalid Vendor ID in Vendor specific extensions in the Registration Request since system was last restarted.

RegReqErr-CVSE

Duplicate Critical Vendor extension in the Registration Request since system was last restarted.

RegReqErr-UnknownAttr

Unknown Accounting attribute in the Registration Request since system was last restarted.

RegReqErr-LenAttr

Invalid accounting attribute length in the Registration Request since system was last restarted.

RegReqErr-DupAttr

Duplicate accounting attribute received in the Registration Request since system was last restarted.

RegReqErr-AcctRecRetrans

Same accounting sequence number and record type in the Registration Requests airlink record not updated since system was last restarted.

RegReqErr-SeqNum

Invalid sequence number in the airlink accounting record Registration Requests silently discarded since system was last restarted.

RegReqErr-DupGREKey

Duplicate GRE Key received in the Registration Request for different MSID from the same PCF since system was last restarted.

RegReqErr-SameGREKey

Same GRE Key and Airlink setup received in the Registration Request for existing session since system was last restarted.

RegReqErr-GREKeyChangeNoSetup

GRE changed without airlink setup received in the Registration Request for existing session since system was last restarted.

RegReqErr-InitNoSetup

Airlink Setup record not received in the Initial Registration Request since system was last restarted.

RegReqErr-StartBeforeSetup

Airlink Start record received before the Airlink setup in the Registration Request since system was last restarted.

RegReqErr-StartOnClose

Airlink Start record received in the De-Registration Request since system was last restarted.

RegReqErr-StartOnActive

Airlink Start record received in the Registration Request for already active session since system was last restarted.

RegReqErr-StopOnDormant

Airlink Stop record received in the Registration Request for already dormant session since system was last restarted.

RegReqErr-InitStop

Airlink Stop record received in the Initial Registration Request since system was last restarted.

RegReqErr-InitSDB

Airlink SDB received in the Initial Registration Request since system was last restarted.

RegReqErr-airlinkRec

Invalid Accounting Airlink record type in the Registration Request since system was last restarted.

RegReqErr-DeregNoSession

De-Registration Request for non existing session registration request is discarded since system was last restarted.

RegReqErr-ReregInDisc

Re-Registration Request received for the session in the disconnecting or deleting state, therefore the registration request is discarded since system was last restarted.

RegReqErr-Memfail

Registration Request discarded due to memory allocation failure during processing since system was last restarted.

RegReqErr-MaxSessions

Registration request rejected because of maximum limit or configured number of session reached since system was last restarted.

cCdmaRPRegUpdAckErrors

 

RegUpdAckErr-PakLen

Invalid Registration Update Ack packet length while parsing since system was last restarted.

RegUpdAckErr-Protocol

Invalid Protocol value in the Registration Update Ack Session Specific Extension since system was last restarted.

RegUpdAckErr-RUAEKey

Invalid Authentication key in the Registration Update Ack Registration Update Authentication extension since system was last restarted.

RegUpdAckErr-SPI

Invalid SPI in the Registration Update Ack Registration Update Authentication extension since system was last restarted.

RegUpdAckErr-ConnId

Invalid Connection ID in the Registration Update Ack since system was last restarted.

RegUpdAckErr-MNID

Invalid MN ID in the Registration Update Ack since system was last restarted.

RegUpdAckErr-MNIDType

Invalid MN ID type in the Registration Update Ack since system was last restarted.

RegUpdAckErr-MSIDLen

Invalid MSID length in the Registration Update Ack since system was last restarted.

RegUpdAckErr-SSE

Session Specific extension missing in the Registration Update Ack since system was last restarted.

RegUpdAckErr-RUAE

Registration Update Authentication extension missing in the Registration Update Ack since system was last restarted.

RegUpdAckErr-Order

Invalid order of the extensions in the Registration Update Ack since system was last restarted.

RegUpdAckErr-VSE

Invalid Vendor specific extensions in the Registration Update Ack since system was last restarted.

RegUpdAckErr-NoSession

De-Registration Update Ack for non existing session Registration Update Ack is discarded since system was last restarted.

RegUpdAckErr-MemFail

Registration Update Ack discarded due to memory allocation failure during processing since system was last restarted.

cCdmaRPSessUpdAckErrors

 

SessUpdAckErr-PakLen

Invalid Session Update Ack packet length while parsing since system was last restarted.

SessUpdAckErr-Protocol

Invalid Protocol value in the Session Update Ack Session Specific Extension since system was last restarted.

SessUpdAckErr-RUAEKey

Invalid Authentication key in the Session Update Ack Registration Update Authentication extension since system was last restarted.

SessUpdAckErr-SPI

Invalid SPI in the Session Update Ack Session Update Authentication extension since system was last restarted.

SessUpdAckErr-ConnId

Invalid Connection ID in the Session Update Ack since system was last restarted.

SessUpdAckErr-MSID

Invalid MN ID in the Session Update Ack since system was last restarted.

SessUpdAckErr-MSIDType

Invalid MN ID type in the Session Update Ack since system was last restarted.

SessUpdAckErr-MSIDLen

Invalid MSID length in the Session Update Ack since system was last restarted.

SessUpdAckErr-SSE

Session Specific extension missing in the Session Update Ack since system was last restarted.

SessUpdAckErr-RUAE

Session Update Authentication extension missing in the Session Update Ack since system was last restarted.

SessUpdAckErr-Order

Invalid order of the extensions in the Session Update Ack since system was last restarted.

SessUpdAckErr-VSE

Invalid Vendor specific extensions in the Session Update Ack since system was last restarted.

SessUpdAckErr-NoSession

De-Session Update Ack for non existing session Session Update Ack is discarded since system was last restarted.

SessUpdAckErr-MemFail

Session Update Ack discarded due to memory allocation failure during processing since system was last restarted.

cCdmaRPRegReplyErrors

 

RegRplyErr-Internal

Registration reply not sent due to internal error during processing since system was last restarted.

RegRplyErr-MemFail

Registration reply not sent due to memory allocation failure during processing since system was last restarted.

RegRplyErr-NoSecOrParse

Cannot send Reply to PCF because security association not found for the PCF or Parse error of Request since system was last restarted.

cCdmaRPRegUpdErrors

 

RegUpdErr-Internal

Registration update not sent due to internal error during processing since system was last restarted.

RegUpdErr-MemFail

Registration update not sent due to memory allocation failure during processing since system was last restarted.


The following MIB enhancements are included in the Cisco PDSN Release 2.1:

PPP Counter Objects have been added under the following existing MIB subgroups:

cCdmaPppSetupStats

cCdmaPppReNegoStats

cCdmaPppAuthStats

cCdmaPppReleaseStats

cCdmaPppMiscStats

CDMA PDSN System Information

ccpcEnabled OBJECT-TYPE

::= { ccpcSystemInfo 1 }

ccpcSessionTotal OBJECT-TYPE

::= { ccpcSystemInfo 2 }

CDMA PDSN Closed RP Registration Statistics per PCF

The PDSN PCF table maintains reference about the PCF in the RAN currently interacting with the PDSN.

An entry is created when an L2TP tunnel is established with the PCF. An entry is deleted when the tunnel is deleted.

Statistics Objects maintained per PCF include the following:

ccpcPcfIpAddressType OBJECT-TYPE

"Represents the type of the address specified by ccpcPcfIpAddress."

::= { ccpcPcfPerfStatsEntry 1 }

ccpcPcfIpAddress OBJECT-TYPE

"The IP address of the PCF that serves the mobile node."

::= { ccpcPcfPerfStatsEntry 2 }

ccpcPcfRcvdIcrqs OBJECT-TYPE

"Total number of Incoming-Call-Requests received to establish a L2TP session since the L2TP tunnel was established with PCF."

::= { ccpcPcfPerfStatsEntry 3 }

ccpcPcfAcptdIcrqs OBJECT-TYPE

"Total number of Incoming-Call-Requests accepted since the L2TP tunnel was established with PCF."

::= { ccpcPcfPerfStatsEntry 4 }

ccpcPcfDroppedIcrqs OBJECT-TYPE

"Total number of Incoming-Call-Requests denied since the L2TP tunnel was established with PCF."

::= { ccpcPcfPerfStatsEntry 5 }

ccpcPcfSentIcrps OBJECT-TYPE

"Total number of Incoming-Call-Replies sent since the L2TP tunnel was established with PCF."

::= { ccpcPcfPerfStatsEntry 6 }

ccpcPcfRcvdIccns OBJECT-TYPE

"Total number of Incoming-Call-Connected messages received since the L2TP tunnel was established with PCF."

::= { ccpcPcfPerfStatsEntry 7 }

ccpcPcfAcptdIccns OBJECT-TYPE

"Total number of Incoming-Call-Connected messages accepted since the L2TP tunnel was established with PCF."

::= { ccpcPcfPerfStatsEntry 8 }

ccpcPcfDroppedIccns OBJECT-TYPE

"Total number of Incoming-Call-Connected messages accepted since the L2TP tunnel was established with PCF."

::= { ccpcPcfPerfStatsEntry 9 }

ccpcPcfRcvdCdns OBJECT-TYPE

"Total number of Call-Disconnect-Notify messages received to tear down L2TP session since the L2TP tunnel was established with PCF."

::= { ccpcPcfPerfStatsEntry 10 }

ccpcPcfSentCdns OBJECT-TYPE

"Total number of Call-Disconnect-Notify messages sent to PCF to tear down L2TP session since the L2TP tunnel was established with PCF."

::= { ccpcPcfPerfStatsEntry 11 }

ccpcPcfDroppedCdns OBJECT-TYPE

"Total number of Call-Disconnect-Notify messages dropped since the L2TP tunnel was established with PCF."

::= { ccpcPcfPerfStatsEntry 12 }

ccpcPcfRcvdZlbs OBJECT-TYPE

"Total number of Zero-Length-Buffer messages received since the L2TP tunnel was established with PCF."

::= { ccpcPcfPerfStatsEntry 13 }

ccpcPcfSentZlbs OBJECT-TYPE

"Total number of Zero-Length-Buffer messages sent since the L2TP tunnel was established with PCF."

::= { ccpcPcfPerfStatsEntry 14 }

In PDSN Release 2.0 and above, the MIB CISCO-CDMA-PDSN-MIB module is modified to provide the following statistics by PCF plus Service Option:

PCF and Service Option based RP Registration Statistics

PCF and Service Option based RP Update Statistics

PCF and Service Option based PPP Statistics

PCF/Service Option-based RP Statistics

In Release 1.2, the PDSN MIB provided RP registration statistics that offer box level information. These statistics are defined under the group "cCdmaRpRegStats." In Release 2.0 and above, in addition to box level information, the PCF/SO-based RP statistics will also be provided, and the MIB objects pertaining to these statistics is defined under the following group:

cCdmaPcfSoRpRegStats OBJECT IDENTIFIER

::= { cCdmaPerformanceStats 10 }

PCF/Service Option-based RP Update Statistics

The Release 1.2 MIB provides RP update statistics at box level; the MIB objects pertaining to these statistics are defined under the group cCdmaRpUpdStats. In addition to these statistics, the Release 2.0 MIB will provide PCF/SO based RP update statistics. These new MIB objects are defined under the following group.

cCdmaPcfSoRpUpdStats OBJECT IDENTIFIER

::= { cCdmaPerformanceStats 11 }

PCF/Service Option-based PPP Statistics

In Release 1.2, the MIB objected defined under the group "cCdmaPppStats" provides box level information about PPP negotiation between the PDSN and the MN. In Release 2.0, the MIB will provide the following PPP stats based on PCF/SO.

cCdmaPcfSoPppCurrentConns,

cCdmaPcfSoPppConnInitiateReqs,

              cCdmaPcfSoPppConnSuccesses,

cCdmaPcfSoPppConnFails,

cCdmaPcfSoPppConnAborts

These objects are grouped under the following MIB group.

cCdmaPcfSoPppSetupStats OBJECT IDENTIFIER

::= { cCdmaPerformanceStats 12 }

As with previous releases, you can manage the Cisco PDSN with Cisco Works 2000 network management system using SNMP. In addition to the standard 6500 MIBS, the Cisco CDMA PDSN MIB (CISCO_CDMA_PDSN_MIB.my) is part of the PDSN solution. The Cisco PDSN MIB continues to support the following features:

Statistics groups

Handoff statistics: include inter-PCF success and failure, inter-PDSN handoff

Service option based success and failure statistics

Flow type based failure statistics

MSID authentication statistics

Addressing scheme statistics: static or dynamic mobile IP/simple IP

A TRAP threshold group to support different severity levels. Agent generates notifications only if the severity level of the affected service is higher than the configured severity level. The severity level can be configured using the following methods:

The CLI using the cdma pdsn mib trap level 1-4, or by

Using SNMP, set the object cCdmaNotifSeverityLevel.

Cisco Proprietary Prepaid Billing

PDSN Release 2.1 supports Cisco's proprietary prepaid billing features, that provide the following services:

Simple IP-based service metering in real time. See the "Prepaid Simple IP Call Flow" section for more information.

Undifferentiated Mobile IP service in real-time, with support for multiple Mobile IP flows per user. See the"Prepaid Mobile IP Call Flow" section for more information.

Rating based on per-flow data volume, octet or packet count, and call duration.

Figure 6 shows the network reference architecture for prepaid service. The PBS resides in the mobile station's home network and is accessed by the home RADIUS server. A Cisco Access Registrar (AR) with prepaid functionality can be used as the home RADIUS server to provide service to prepaid and non-prepaid users.

Figure 6 PDSN Prepaid Billing Architecture

For roaming users, the local RADIUS server in the visited network forwards AAA requests to the home RADIUS server, using a broker RADIUS server if required. For roaming prepaid users, this requires that the local and broker AAA servers forward the new vendor specific prepaid accounting attributes transparently to the home RADIUS server.

In existing networks, where the home RADIUS server does not support the interface to the Prepaid Billing Server, AR can be placed in front of the home RADIUS server to act as a proxy. In this case AR forwards all authorization and accounting messages to /from the home RADIUS server and communicates with the PBS. This scenario is relevant if an operator already has a RADIUS server.

While this architecture does impose some additional requirements on the RADIUS server, the interface towards the PDSN does not change.

It is possible that an operator may want to use an existing WIN or IN based prepaid billing server. In this situation, the PBS will interface to the external prepaid billing server.

Accounting Records

The PDSN will continue to generate per flow accounting records in the same way as it does for non-prepaid users. However, the last Accounting Stop Request for a flow will contain the new prepaid Vendor Specific Attributes (VSAs) for reporting the final usage.

How Prepaid Works in PDSN

When a prepaid mobile user makes a data service call, the MS establishes a Point-to-Point Protocol (PPP) link with the Cisco PDSN. The Cisco PDSN authenticates the mobile station by communicating with the AAA server. The AAA server verifies that the user is a valid prepaid subscriber, determines what services are available for the user, and tracks usage for billing.

The methods used to assign an IP address and the nature of the connection are similar to those discussed in the "How PDSN Works" section.

The following sections describe the IP addressing and communication levels in the prepaid environment for each respective topic:

Prepaid Simple IP Call Flow

Prepaid Mobile IP Call Flow

Prepaid Simple IP Call Flow

In the following scenario, the prepaid user has sufficient credit and makes a Simple IP data call. The user disconnects at the end of the call.


Step 1 The MS originates a call by sending an origination message. A traffic channel is assigned, and the MS is authenticated using CHAP.

Step 2 The PDSN determines that a Simple IP flow is requested and sends an Access Request to the RADIUS server.

Step 3 The RADIUS Server looks up the user's profile and determines that user has prepaid service. It sends an initial authentication request to the billing server.

Step 4 The billing server checks that the user has sufficient quota to make a call, and returns the result.

Step 5 The RADIUS Server sends an Access Accept message to PDSN indicating that this is a prepaid user.

Step 6 The PDSN completes the PPP connection, and an IP address is assigned to the MS.

Step 7 PDSN sends an Accounting Request (Start) as normal, and sends an Access Request to AR for initial quota authorization. The request contains the Service Id VSA that indicates the call is Simple IP.

Step 8 The RADIUS Server, knowing that this is a prepaid user, sends an initial quota authorization request to the billing server, which returns the quota information to the RADIUS Server. The RADIUS Server includes the quota information in the Access Accept message and sends it to the PDSN.

Step 9 The PDSN saves the received quota information and monitors user data against this. When the quota is used up, the PDSN sends an Access Request to AR indicating the usage and reason "Quota Depleted."

Step 10 The RADIUS Server then sends a re-authorization request to PBS, which updates the user's account, allocates additional quota, and returns the new quota information to the RADIUS Server.

Step 11 The RADIUS Server includes the new quota information in the Access Accept message and sends it to the PDSN. The PDSN updates the new quota information in its tables, and adjusts the usage to allow for quota that was used since the Access Request was sent. The PDSN then continues to monitor the user data. Steps 9 - 11 are repeated as long as the user has sufficient quota.

Step 12 When the user disconnects, the MS initiates release of the call and the traffic channel is released. The PDSN clears the session and sends an Accounting Request Stop record. The record includes the prepaid VSAs to report final usage.

Step 13 The RADIUS Server updates its own records and sends final usage report to PBS. The PBS updates the user's account and replies to the AR. And the AR sends the Accounting Response to PDSN.


Prepaid Mobile IP Call Flow

In the following scenario, the prepaid user makes a Mobile IP data call. The user runs out of quota during the mobile IP data session and the PDSN disconnects the call. The call flow shows a single Mobile IP flow; however, additional flows are established and handled in a similar manner when the MS sends additional Mobile IP Registration Requests.


Step 1 The MS originates a call by sending an Origination message. A traffic channel is assigned, but the MS skips CHAP.

Step 2 The PDSN completes the PPP connection. Since the MS skips IP address assignment during IPCP the PDSN assumes Mobile IP.

Step 3 The PDSN sends an Agent Advertisement with a FA-CHAP challenge, and the MS initiates a Mobile IP Registration Request with FA-CHAP response.

Step 4 The PDSN sends the Access Request with FA-CHAP to the AR. The AR looks up the user's profile and determines that the user has prepaid service. It the sends an authentication request to the billing server.

Step 5 The billing server checks that the user has sufficient quota to make a call and returns an ok. The RADIUS Server sends an Access Accept message to the PDSN that indicates a prepaid user.

Step 6 The PDSN forwards the mobile IP Registration Request to the Home Agent and receives a Registration Reply. The PDSN forwards the reply to the MS.

Step 7 The PDSN sends an Access Request for initial quota authorization. The request contains Service Id VSA that indicates this is a Mobile IP call. The AR, knowing that this is a prepaid user, sends the initial quota authorization request to the PBS. The billing server returns the quota information to the AR, who includes the quota information in the Access Accept message and sends it to the PDSN.

Step 8 The PDSN saves the received quota information and monitors the user data against this. When the quota is used up, the PDSN sends an Access Request to AR indicating the usage and reason "Quota Depleted."

Step 9 The AR sends re-authorization request to the PBS, who updates the user's account, allocates additional quota, and returns the new quota information to the AR.

Step 10 The AR includes the new quota information in the Access Accept message and sends it to the PDSN. The PDSN updates the new quota information in its tables, and adjusts usage to allow for quota used since the Access Request was sent. The PDSN then continues to monitor the user data. Steps 8-10 are repeated as long as the user has sufficient funds.

Step 11 If the PDSN requests an additional quota but the user has run out, the PBS rejects the request with reason "Exceeded Balance," and the AR sends an Access Reject to PDSN.

Step 12 The PDSN deletes the Mobile IP flow, determines that this is the last flow, and requests release of the A10 connection by sending A11-Registration Update to the PCF. The PCF sends an ack message and initiates release of the traffic channel.

Step 13 The PDSN clears the session and sends an Accounting Request Stop record. The record includes the prepaid VSAs to report final usage.

Step 14 The AR updates its own records and sends final usage report to PBS, who updates the user's account and replies to the AR.

Step 15 The AR finally sends the Accounting Response to PDSN.



Note This feature is a variant of the PDSN Release 2.1 software. Refer to the Feature Matrix to see which features are available on a specific image of PDSN 2.0.


3 DES Encryption

The Cisco PDSN include 3DES encryption, which supports IPSec on PDSN. IPSec on the MWAM platform requires you to use a Cisco VPN Acceleration Module.

This feature allows VPDN traffic and Mobile IP traffic (between the PDSN Home Agent) to be encrypted. In this release the PDSN requires you to configure the parameters for each HA before a mobile ip data traffic tunnel is established between the PDSN and the HA.


Note This feature is only available with hardware support.



Note This feature is a variant of the PDSN software. Refer to the Feature Matrix to see which features are available on a specific image of PDSN.


Mobile IP IPSec

The Internet Engineering Task Force (IETF) has developed a framework of open standards called IP Security (IPSec) that provides data confidentiality, data integrity, and data authentication between participating peers. IPSec provides these security services at the IP layer; it uses Internet Key Exchange (IKE) to handle negotiation of protocols and algorithms based on local policy, and to generate the encryption and authentication keys to be used by IPSec. IPSec can be used to protect one or more data flows between a pair of hosts, between a pair of security gateways, or between a security gateway and a host.

IS-835-B specifies three mechanisms for providing IPSec security:

Certificates

Dynamically distributed pre-shared secret

Statically configured pre-shared secret.


Note IS-835-B Statically configured pre-shared secret is not supported in PDSN Release 1.2. Only CLI-configured, statically configured pre-shared-secret of IKE will be implemented and supported.


Hardware IPSec Acceleration Using IPSec Acceleration Module—Static IPSec


Note The Cisco PDSN Release on the Cisco 6500 and 7600 platforms requires the support of the Cisco IPSec Services Module (VPNSM), a blade that runs on the Catalyst 6500 switch and the Cisco 7600 Internet Router. VPNSM does not have any physical WAN or LAN interfaces, and utilizes VLAN selectors for its VPN policy. For more information on Catalyst 6500 Security Modules visit http://wwwin.cisco.com/issg/isbu/products/6000/6500security.shtml. For more information on the Cisco 7600 Internet Router visit http://wwwin.cisco.com/rtg/routers/products/7600/techtools/index.shtml.


IPSec-based security may be applied on tunnels between the PDSN and the HA depending on parameters received from Home AAA server. A single tunnel may be established between each PDSN-HA pair. It is possible for a single tunnel between the PDSN-HA pair to have three types of traffic streams: Control Messages, Data with IP-in-IP encapsulation, and Data with GRE-in-IP encapsulation. All Traffic carried in the tunnel will have the same level of protection provided by IPSec.

IS-835-B defines MobileIP service as described in RFC 2002; the Cisco PDSN provides Mobile IP service and Proxy Mobile IP service.

In Proxy Mobile service, the Mobile-Node is connected to the PDSN/FA through Simple IP, and the PDSN/FA acts as Mobile IP Proxy for the MN to the HA.

Once Security Associations (SAs, or tunnels) are established, they remain active until there is traffic on the tunnel, or the lifetime of the SAs expire.


Note This feature is a variant of the PDSN software. Refer to the Feature Matrix to see which features are available on a specific image of PDSN.


Conditional Debugging Enhancements

In Cisco PDSN Release 4.1, debugs are displayed while parsing the attributes and sending them in an accounting request.

debug aaa authentication

debug aaa authorization

debug radius

debug aaa per-user

debug ppp negotiation

Debugs from Access Accept

SAMI 5/3: Aug  4 10:16:07.859: RADIUS:  Service-Type        [6]   6   Framed                    
[2]
SAMI 5/3: Aug  4 10:16:07.859: RADIUS:  Framed-IP-Pool      [88]  11  "test-pool"
SAMI 5/3: Aug  4 10:16:07.859: RADIUS:  Vendor, 3GPP2       [26]  20  
SAMI 5/3: Aug  4 10:16:07.859: RADIUS:   cdma-dns-server-ip-[117] 14  
SAMI 5/3: Aug  4 10:16:07.859: RADIUS:   01 06 01 02 03 04 02 06 05 06 07 08              
[????????????]
SAMI 5/3: Aug  4 10:16:07.859: RADIUS:  Vendor, Cisco       [26]  27  
SAMI 5/3: Aug  4 10:16:07.859: RADIUS:   Cisco AVpair       [1]   21  
"ip:vrf-id=test-pdsn"
SAMI 5/3: Aug  4 10:16:07.859: RADIUS:  Vendor, Cisco       [26]  34  
SAMI 5/3: Aug  4 10:16:07.859: RADIUS:   Cisco AVpair       [1]   28  
"ip:ip-unnumbered=Loopback0"
SAMI 5/3: Aug  4 10:16:07.859: RADIUS:  Vendor, CNCTC       [26]  17  
SAMI 5/3: Aug  4 10:16:07.859: RADIUS:   cnctc-served-mdn   [100] 11  
SAMI 5/3: Aug  4 10:16:07.859: RADIUS:   74 65 73 74 2D 70 64 73 6E                       
[test-pdsn]

Debugs in IPCP

SAMI 5/3: Aug  4 10:16:07.863: Vi2.1 IPCP: O CONFNAK [REQsent] id 1 len 22
SAMI 5/3: Aug  4 10:16:07.863: Vi2.1 IPCP:    Address 2.1.1.1 (0x030602010101)
SAMI 5/3: Aug  4 10:16:07.863: Vi2.1 IPCP:    PrimaryDNS 1.2.3.4 (0x810601020304)
SAMI 5/3: Aug  4 10:16:07.863: Vi2.1 IPCP:    SecondaryDNS 5.6.7.8 (0x830605060708)
SAMI 5/3: Aug  4 10:16:07.863: Vi2.1 IPCP: I CONFACK [REQsent] id 1 len 10
SAMI 5/3: Aug  4 10:16:07.863: Vi2.1 IPCP:    Address 51.1.1.10 (0x03063301010A)
SAMI 5/3: Aug  4 10:16:07.867: Vi2.1 IPCP: I CONFREQ [ACKrcvd] id 2 len 22
SAMI 5/3: Aug  4 10:16:07.867: Vi2.1 IPCP:    Address 2.1.1.1 (0x030602010101)
SAMI 5/3: Aug  4 10:16:07.867: Vi2.1 IPCP:    PrimaryDNS 1.2.3.4 (0x810601020304)
SAMI 5/3: Aug  4 10:16:07.867: Vi2.1 IPCP:    SecondaryDNS 5.6.7.8 (0x830605060708)
SAMI 5/3: Aug  4 10:16:07.867: Vi2.1 AAA/AUTHOR/IPCP: primary dns server 1.2.3.4
SAMI 5/3: Aug  4 10:16:07.867: Vi2.1 AAA/AUTHOR/IPCP: seconday dns server 5.6.7.8
SAMI 5/3: Aug  4 10:16:07.867: Vi2.1 IPCP: O CONFACK [ACKrcvd] id 2 len 22
SAMI 5/3: Aug  4 10:16:07.867: Vi2.1 IPCP:    Address 2.1.1.1 (0x030602010101)
SAMI 5/3: Aug  4 10:16:07.867: Vi2.1 IPCP:    PrimaryDNS 1.2.3.4 (0x810601020304)
SAMI 5/3: Aug  4 10:16:07.867: Vi2.1 IPCP:    SecondaryDNS 5.6.7.8 (0x830605060708)
SAMI 5/3: Aug  4 10:16:07.867: Vi2.1 IPCP: State is Open
SAMI 5/3: Aug  4 10:16:07.867: AAA/AUTHOR: Processing PerUser AV vrf-id
SAMI 5/3: Aug  4 10:16:07.867: AAA/AUTHOR: Processing PerUser AV ip-unnumbered
SAMI 5/3: Aug  4 10:16:07.867: AAA/BIND(000000DE): Bind i/f  
SAMI 5/3: Aug  4 10:16:07.867: Vi2.1 IPCP: Install route to 2.1.1.1
SAMI 5/3: Aug  4 10:16:07.867: RADIUS/ENCODE(000000DE):Orig. component type = PDSN

Debugs in Accounting Request

SAMI 5/3: Aug  4 10:16:07.867: RADIUS:  Framed-IP-Address   [8]   6   2.1.1.1                   
SAMI 5/3: Aug  4 10:16:07.867: RADIUS:  Vendor, CNCTC       [26]  17  
SAMI 5/3: Aug  4 10:16:07.867: RADIUS:   cnctc-served-mdn   [100] 11  
SAMI 5/3: Aug  4 10:16:07.867: RADIUS:   74 65 73 74 2D 70 64 73 6E   [test-pdsn]

Trace Functionality in Release 3.0

While conditional debugging has been a useful tool to limit the displayed debugs to a particular user, the output can still be a bit misleading if a few users are traced together. Therefore, the following capabilities are added in R3.0:

The PDSN currently supports display of the MNID/username with every line printed from the CDMA debugs. A similar mechanism is also added for a few other subsystems, like MoIP, PPP, and AAA. Some of the commonly used debugs that are enhanced with the trace functionality are:

debug ppp negotiation

debug aaa id

debug aaa accounting

debug aaa authentication

debug aaa authorization

debug ip mobile

debug cdma pdsn a11 events

debug cdma pdsn accounting

debug cdma pdsn service-selection

debug cdma pdsn session events

cdma pdsn redundancy debugs

When the debug conditions match, every line of the debug message is pre-pended with either the username or the IMSI (not both), depending on the condition set.


Note Pre-pending of Username/IMSI is not supported for a11 cluster debugs.



Note Pre-pending of Username/IMSI is not supported for cdma pdsn redundancy debugs.



Note GRE debugs are not pre-pended with IMSI for the first few lines.



Note debug cdma pdsn a11 errors are not printed for matching conditions.



Note debug aaa accounting does not get pre-pended with username.


The above behavior is controlled through the cdma pdsn debug show-condition and ip mobile debug include username commands. If conditional debugging is enabled without these CLI being configured, the username/IMSI will not be displayed in the debugs. However, if the above CLIs are configured without configuring conditional debugging, the username/IMSI is printed along with the debugs.

Enhancements Prior to Release 3.0

PDSN Release 2.1 supports additional conditional debugging for Mobile IP components. Mobile IP conditional debugging is supported based on NAI as well as the MN's home address.

Currently, when multiple conditional debugging is enabled, the debug output does not individually display the condition for which the debugs are printed for all the CDMA related debugs.

Check Condition

A condition is set using the debug condition username command.

Delete Condition

The debugging conditions can be removed using the following commands:

no debug condition username—removes all the conditions based on username

no debug condition username username—removes the condition for the specified username

When a condition is removed using the above CLI, the IOS Conditional Debugging Subsystem, which maintains a list of conditions and the TRUE conditions, resets the flag. When all the conditions are removed, the debugging information will appear without any filter applied.

The PDSN software also utilizes conditional debugging based on the Mobile Subscriber ID (MSID) into the CDMA subsystem by using the existing IOS debug condition of the Cisco CLI. The calling option of the CLI is used to specify the MSID (for example, debug condition calling 00000000011124).

The following debug commands are supported for conditional debugging based on NAI. The NAI is a name like foo@bar.com.

debug ip mobile

debug ip mobile host

debug ip mobile proxy

The following debug commands are not impacted by NAI-based conditional debugging:

debug ip mobile local-area

debug ip mobile router

This release provides conditional debugging support for the following PDSN CLI commands:

debug cdma pdsn accounting

debug cdma pdsn accounting flow

debug cdma pdsn session [errors | events]

debug ip mobile

debug condition username

The a11 debugs additionally support msid-based debugging using the following individual CLI commands:

debug cdma pdsn a11 events mnid

debug cdma pdsn a11 errors mnid

debug cdma pdsn a11 packet mnid

Conditional debugging is an IOS feature, and the following CLI are available across all images.

router# debug condition ?
  application  Application
  called       called number
  calling      calling
  glbp         interface group
  interface    interface
  ip           IP address
  mac-address  MAC address
  match-list   apply the match-list
  standby      interface group
  username     username
  vcid         VC ID

The options calling, username, and ip are used by the CDMA/Mobile IP subsystems.

PDSN#debug condition username ?
  WORD  Username for debug filtering

PDSN#debu condition calling ?
  WORD  Calling number

PDSN#debu condition ip ?
  A.B.C.D  IP address

Refer to the debug commands in the Command Reference for more information about conditional debugging in PDSN Release 2.1.

Electronic Serial Number (ESN) in Billing

The ESN is a unique identifier for a piece of equipment, such as of a mobile device, and is used during the authentication process. The ESN is parameter a2 of the R-P Session Setup airlink record, and parameter A2 in the PDSN Usage Data Record (UDR). Both parameters are introduced in this release.

The PDSN accepts the parameter a2, and puts it as A2 into a User Data Record.

This feature is supported in the Cisco Access Registrar.

Support for Mobile Equipment Identifier (MEID)

The MEID is a new attribute introduced in IS-835D, and will eventually replace the ESN AVP. In the interim period, both attributes are supported on the PDSN.

To include the MEID in Access Request, FA-CHAP, or Mobile IP RRQ, use the cdma pdsn attribute send a3 command.

1xEV-DO Support

The Cisco PDSN supports Evolution-Data Optimized (1xEV-DO). 1xEV-DO offers high performance, high-speed, high-capacity wireless Internet connectivity, and is optimized for packet data services. It can transport packet data traffic at forward peak rates of 2.4 Mbps, which is much higher than the current 1xRTT peak rate of 144 kbps.

PDSN support for 1xEV-DO technology includes the following enhancements:

PDSN recognizes a new Service Option value of 59 (decimal) for 1xEV-DO in Active Start Airlink Record.

The PDSN CLI commands are enhanced to show sessions—show cdma pdsn session—so that packet service options are displayed (1xRTT, 1xEV-DO, or undefined).

Integrated Foreign Agent (FA)

The FA is an essential component to mobility, because it allows a mobile station to remotely access services provided by the station's home network. The Cisco PDSN provides an integrated FA. The FA communicates with any standard HA including the Cisco IOS-based HA.

AAA Support

The Cisco PDSN provides an authentication client that communicates with any standard AAA server, including Cisco Access Registrar, to authenticate the mobile station. It uses the mobile stations' name (NAI) for authentication of the user with the local AAA server.

The Cisco PDSN supports the following AAA services for Simple IP:

Password Authentication Protocol (PAP) and CHAP authentication.

Accounting information.

IP address allocation for the mobile user.


Note The Cisco PDSN supports the assignment of IP addresses and the mapping of MSID to NAI for special configuration users. Typically, this includes MSID-based access users who skip the authentication process during the PPP establishment, and who want just the Simple IP routing service.


The Cisco PDSN supports the following AAA services for VPDN:

PAP and CHAP authentication.

Accounting information.

The Cisco PDSN supports the following AAA services for Proxy Mobile IP:

PAP and CHAP authentication.

Accounting information.

Assignment of IP address (as received from HA, in the Registration Reply message) during the IPCP phase.

The Cisco PDSN supports the following AAA services for Mobile IP:

Optionally skip authentication during PPP upon receiving REJ from the mobile station.

FA Challenge/Response as defined in TIA/EIA/IS-835-B through Mobile IP registration.

FA-HA and FA-mobile station authentications as described under Mobile IP section.

Verification of the FA challenge response in a Mobile IP registration request corresponding to a recent advertisement.

The Cisco PDSN also supports service provisioning using AAA servers and a user service profile. This profile is defined by the user's home network. It is referenced by the NAI. It is typically stored in the AAA server in the user's home network, along with the user authentication information, and is retrieved as part of authorization reply.

Table 11 PDSN 4.0 AAA Attributes

Attribute
Type
Access- Request
Access- Accept
Accounting Messages
Interim
       

Accounting Start

Accounting

Stop

 

Differentiated Services Class Option

26/05

No

Yes

No

No

No

Allowed Differentiated Services Marking

26/73

No

Yes

No

No

No

Maximum Authorized Aggregate Bandwidth for Best-Effort Traffic

26/130

No

Yes

No

No

No

Authorized Flow Profile IDs for the User

26/131

No

Yes

No

No

No

Granted QoS Parameters

26/132

No

No

Yes

Yes

Yes

Maximum Per Flow Priority for the User

26/133

No

Yes

No

No

No

FLOW_ID Parameter

26/144

No

No

No

Yes

No

Flow Status

26/145

No

No

No

Yes

No

RSVP Inbound Octet Count

26/162

No

No

No

Yes

Yes

RSVP Outbound Octet Count

26/163

No

No

No

Yes

Yes

RSVP Inbound Packet Count

26/164

No

No

No

Yes

Yes

RSVP Outbound Packet Count

26/165

No

No

No

Yes

Yes


In PDSN Release 4.0, the following AAA attributes are added:

In the above table the following conditions apply:

No—This attribute MUST NOT be present in packet.

Yes —Zero or one instance of this attribute MAY be present in packet.

Packet Transport for VPDN

The Cisco PDSN supports the transport of VPDN packets. If the operator offers VPDN services, the mobile station can securely access private resources through a public Internet or dedicated links. The VPDN tunnel extends from the PDSN/FA to the home IP network. The home IP network is the IP network associated with the NAI.

Proxy Mobile IP

With Proxy Mobile IP as part of the PPP link initiation, the PDSN registers with a HA on behalf of the mobile station. It obtains an address from the HA and forwards that address to the mobile station as part of IPCP during PPP initialization.

Multiple Mobile IP Flows

The Cisco PDSN allows multiple IP access points from the same mobile station, as long as each IP flow registers individually (each IP flow requires a unique NAI). This enables multiple IP hosts to communicate through the same mobile access device and share a single PPP connection to the operator's network. For accounting purposes, it is important that the PDSN generate separate usage data records (UDRs) for each flow to the AAA server.

Redundancy and Load Balancing

This section provides information about Intelligent PDSN Selection and Load Balancing for the Controller - Member cluster model.

PDSN Cluster Controller / Member Architecture

The PDSN Controller member architecture was designed to support 8 members with redundant Active/Standby controllers. This controller-member mode designates certain nodes as controllers responsible for performing PDSN selection, and for maintaining the global session tables. Each member node maintains information only about the sessions that are terminated on that node. Controllers can be redundant with all session information synchronized between them, and they monitor the state of all nodes to detect the failure of a member or another controller.

When a PDSN cluster operates in the controller-member mode, controllers are dedicated to the PDSN selection function, and do not terminate bearer sessions.

PDSN Release 2.1 supports the following enhancements:

Cluster scalability to support 48 members with bulk-update of session information

Conditional debugging support for MSID under clustering feature

Controller Show command enhancements

Clear command under clustering feature to clear clustering statistics

When a Registration Request (RRQ) arrives from the PCF to the active controller, the controller uses the MSID as an index to look up the session-table. If a session record entry is present, the controller forwards the RRQ to the PDSN that hosts the session for the MSID. If the session entry is not present in the controller session-table, the controller chooses a member based on a configured selection algorithm, and replies to the PCF with an RRP that suggests the member IP address in the message.

When the session comes up, the member sends a Session-Up message from the member for that session (MSID) to the controller. On receipt of this message from the member, the controller creates the Session Record for that MSID in the controller to establish MSID-member association on the controller. On receipt of Session-Down message from member, the controller flushes the Session Record from the controller.

The controller does not create a Session Record for the MSID when it redirects the RRQ, but only on the receipt of a Session-Up message from the member on which the session has come up

To support a large number of members (28~48) per Controller, processing overhead is reduced when members send one bulk-update packet to the controller for every configured periodic update time interval with multiple pairs of Session-Up/Session-Down. The packet contains concatenated multiple MSIDs with one Session-Up/Session-Down flag, thereby saving bytes in the packet. The controller will process these bulk-update packets and send a bulk-update-ack packet to the members.

Conditional Debugging Support Under Clustering Feature

The Cisco PDSN 2.0 Clustering feature adds additional support for the conditional debugging with the following clustering debug command on both controller and member:

Debug cdma pdsn cluster controller message {event | error | packet}


Note PDSNs in controller-member mode and peer-to-peer mode cannot co-exist in the same cluster. They are mutually exclusive.


PDSN Controller-Member Clustering

In Controller-Member clustering, a controller maintains load and session (such as A10 connection) information for each member in the cluster, and performs member selection for load-balancing or inter-PDSN handoff avoidance. The controller identifies the operational state of each member and detects the failure of a member, or the failure of another controller. A member notifies the controller about its load and session information.


Note The new PDSN Controller-Member clustering feature is only available on the -c6is-mz, and -c6ik9s-mz images.


Figure 7 illustrates the Controller-Member architecture on the 6500 or 7600-based MWAM platform. This illustration depicts two PDSN clusters with two primary and two backup controllers, and their corresponding members.

Figure 7 PDSN Controller -Member Architecture for MWAM on the Catalyst 6500

PDSNs that are designated as controllers, perform member PDSN selection and load balancing. The following list describes the major functions of the controllers:

Controllers maintain the load information for all members—they obtain the load information by seeking the cluster members. Alternatively, the members send the load value at configurable intervals inside a session origination or termination message. Controllers synchronize by exchanging information as needed.

The link on which controllers exchange information is an HSRP-based state information exchange (HA redundancy is based on this type of implementation).

The link on which the active controller and members exchange information is a unicast HSRP address for the active controller, but must be configured on the members.

The actual PDSN selection and load-balancing procedures are similar to the R1.1 implementation; however, different record tables are used.

Auto-configuration of a new PDSN controller added to the cluster—The new controller must be configured as such, and must be configured as a member of the HSRP group of routers. As a consequence, the new controller (standby) automatically downloads member and session records from the active controller. The active controller updates the standby as needed, so that records are synchronized.

Auto-configuration of the controllers when a new member is added to the cluster—The new member registers with the active controller, which updates the standby controller.

Redundancy—All controllers in the cluster maintain session and load information for all members. This provides redundancy for availability, and, in case of a controller failure, session and load-balancing information is not lost.

Redundancy

Cluster redundancy is based on the premise that only one PDSN might fail at any given time. Two controllers are configured as an HSRP group: One controller is active, the other standby. Controllers have redundancy and members have load sharing.

Load Sharing

Cluster member loadsharing is an N+1 scheme. If a member fails, the established sessions will be lost, but the overall group capacity allows sessions to be re-established with the other group members. Additionally, redundancy is also enhanced because cluster members no longer have to be network neighbors.

Controllers exchange information over an ethernet link. Controllers and members exchange information over a unicast interface link where members address messages to the HSRP group address of the controllers. The members in a PDSN cluster do not need to be network neighbors; they can be attached anywhere in the IP network.

Adding an additional controller to a cluster is simplified by auto-configuration of the controller in the cluster. This is possible by configuring the additional controller for HSRP. The newly-added controller will automatically synchronize with the active controller. Similarly, when a new member is added to the cluster, auto-configuration for the member occurs in all cluster controllers.

PDSN Cluster Member Selection

Selection of a cluster member by the controller is based on a load factor. Load factor is a computed value by session load and CPU load on a member. The controller attempts to assign sessions to a member that has smallest load factor so that data connections are evenly distributed over members in the cluster as much as possible.

If an A11 Registration Request is received indicating a handoff, a member that is already serving the session is selected by the controller.

Load Balancing

A controller maintains load information for all members in the cluster in order to perform PDSN Cluster Member selection. This load information is transferred from the members to the controller under the following conditions:

at periodic intervals.

when a session is established or dismantled in a member. In this case, the periodic timer is restarted.

requested from the members by the controller.

The session and member records are synchronized between the active and standby controllers as needed. Since both active and standby controller maintain session and load information for all the members of that cluster, failure of a controller does not result in the loss of any session or load information.

Upgrading the Controller PDSN Software from R1.2 to R2.0

To upgrade the PDSN controller to Release 2.0, perform the following tasks:


Step 1 Reload either the Active/Standby controller so that at least one of the controllers is operating to take care new incoming calls.

Step 2 Load Release 2.0 software. Once the controller with Release 2.0 software is operational, ensure both controllers have synchronized session information using the following command:

# show cdma pdsn cluster controller configuration

Step 3 Issue the following command to make use of the scalable bulk-synch mechanism of session information between Controller and member PDSN introduced in Release 2.0 PDSN Software.

config# cdma pdsn cluster controller member periodic-update

Follow the same procedure as above to upgrade the other PDSN controller to Release 2.0.


Upgrading the Member PDSN Software from R1.2 to R2.0 and Above

To upgrade a member PDSN to Release 2.0 or 2.1, perform the following tasks:


Step 1 Separate a member PDSN out of the cluster by configuring the following command on the member PDSN:

config# cdma pdsn cluster member prohibit administratively

The status of the member will be updated to the controller in a subsequent periodic keepalive reply message that the member sends to the controller. The controller, upon reception of this message, does not select this member for any of the new incoming calls.

Step 2 Display the member PDSNs which are prohibited administratively by issuing the following command:

#show cluster controller member prohibited administratively

The calls, which are already connected to the member, will be alive until the mobile node disconnects the call. Alternatively, the calls can be forcibly cleared on the prohibited member using the following command:

#clear cdma pdsn session all

Step 3 When all the calls are brought down, upgrade the software to Release 2.0 and above, or shutdown this member without disrupting the operation of the PDSN cluster. When the member comes online you can configure it to rejoin the cluster by issuing the following command:

config# no cdma pdsn cluster member prohibit administratively

Once the controller is updated with the status the new member PDSN will be selected for new incoming calls.

Step 4 Configure the following command to use the scalable bulk-synch mechanism of session information between Controller and member PDSN:

config# cdma pdsn cluster member periodic-update 300


Scalability

In this release the PDSN uses a new scalability feature that allows PPP sessions to run on virtual-access subinterfaces that can support up to 20000 sessions.


Note When using the virtual-access subinterfaces, not more than 20 percent (or a maximum of 4000) of the sessions should be compression sessions.



Note If you are using the Cisco PDSN with a AAA server, ensure that the attribute "compression=none" is not present in your user profiles. If it is, the Cisco PDSN will use the full virtual- access interface instead of the virtual-access sub-interface.



Note To increase the call setup performance, use the no virtual-template snmp global configuration command. This prevents the virtual-access subinterfaces from being registered with the SNMP functionality of the router, and reduces the amount of memory used.


High Availability

Overview

High availability allows you to minimize the switchover time from the active supervisor engine to the standby supervisor engine if the active supervisor engine fails.

Prior to this feature, fast switchover ensured that a switchover to the standby supervisor engine happened quickly. However, with fast switchover, because the state of the switch features before the switchover was unknown, you had to re-initialize and restart all the switch features when the standby supervisor engine assumed the active role.

High availability removes this limitation; high availability allows the active supervisor engine to communicate with the standby supervisor engine, keeping feature protocol states synchronized. Synchronization between the supervisor engines allows the standby supervisor engine to take over in the event of a failure.

In addition, high availability provides a versioning option that allows you to run different software images on the active and standby supervisor engines.

For high availability, a system database is maintained on the active supervisor engine and updates are sent to the standby supervisor engine for any change of data in the system database. The active supervisor engine communicates and updates the standby supervisor engine when any state changes occur, ensuring that the standby supervisor engine knows the current protocol state of supported features. The standby supervisor engine knows the current protocol states for all modules, ports, and VLANs; the protocols can initialize with this state information and start running immediately.

The active supervisor engine controls the system bus (backplane), sends and receives packets to and from the network, and controls all modules. Protocols run on the active supervisor engine only.

The standby supervisor engine is isolated from the system bus and does not switch packets. But it does receive packets from the switching bus to learn and populate its Layer 2 forwarding table for Layer 2-switched flows. The standby supervisor engine also receives packets from the switching bus to learn and populate the Multilayer Switching (MLS) table for Layer 3-switched flows. The standby supervisor engine does not participate in forwarding any packets and does not communicate with any modules.

If you enable high availability when the standby supervisor engine is running, image version compatibility is checked and if found compatible, the database synchronization starts. High availability compatible features continue from the saved states on the standby supervisor engine after a switchover.

When you disable high availability, the database synchronization is not done and all features must restart on the standby supervisor engine after a switchover.

If you change high availability from enabled to disabled, synchronization from the active supervisor engine is stopped and the standby supervisor engine discards all current synchronization data.

If you change high availability from disabled to enabled, synchronization from the active to standby supervisor engine is started (provided the standby supervisor engine is present and its image version is compatible).

NVRAM synchronization occurs irrespective of high availability being enabled or disabled (provided there are compatible NVRAM versions on the two supervisor engines).

If you do not install a standby supervisor engine during system bootup, the active supervisor engine detects this and the database updates are not queued for synchronization. Similarly, when you reset or remove the standby supervisor engine, the synchronization updates are not queued and any pending updates in the synchronization queue are discarded. When you hot insert or restart a second supervisor engine that becomes the standby supervisor engine, the active supervisor engine downloads the entire system database to the standby supervisor engine. Only after this global synchronization is completed, the active supervisor engine queues and synchronizes the individual updates to the standby supervisor engine.


Note When you hot insert or restart a second supervisor engine, it might take a few minutes for the global synchronization to complete.


For more information about High Availability, including configuration details, and information about power management, refer to the "PDSN Controller-Member Clustering" section on page 106, as well as the documents at the following urls:

Catalyst 6500 Series Software Configuration Guide (6.1.1a), with special attention to the "Configuring Redundancy" chapter at:

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sft_6_1/configgd/index.htm

Catalyst 6000 Family IOS Software Configuration Guide, Release 12.2(9)YO at:

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/122yo/swcg/supcfg.htm

http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/122yo/swcg/pwr_envr.htm

Related Features and Technologies

Mobile IP

PPP (Point-to-Point Protocol)

AAA (Authentication, Authorization, and Accounting)

VPDN (Virtual Private Data Network) using L2TP

RADIUS (Remote Authentication Dial-In User Service)

Related Documents

For additional information about the Cisco PDSN Release 2.1 software, refer to the following documents:

Release Notes for the Cisco PDSN 2.1 Feature in Cisco IOS Release 12.3(11)YF

For more information about:

MWAM hardware and software information, refer to the Cisco Multi-processor WAN Application Module Installation and Configuration Note.

The IP Sec configuration commands included in this document, refer to the "IP Security and Encryption" section in the Cisco IOS Security Configuration Guide.

The AAA configuration commands included in this document, refer to the Cisco IOS Release 12.3 documentation modules Cisco IOS Security Command Reference and Cisco IOS Security Configuration Guide.

The PPP and RADIUS configuration commands included in this document, refer to the Cisco IOS Release 12.3 documentation module Cisco IOS Dial Services Command Reference.

Mobile IP, refer to the Cisco Release 12.3 documentation modules Cisco IOS IP Command Reference and Cisco IOS IP Configuration Guide.

Virtual Private Networks, refer to the Cisco IOS Release 12.3 documentation modules Cisco IOS Dial Services Configuration Guide, Network Services and Cisco IOS Dial Services Command Reference.

Supported Platforms

The Cisco PDSN 4.0 release will be a special release that is developed on Cisco IOS 12.4 for the SAMI card on the Cisco 6500 Catalyst Switch platform and 7600 Internet router platform, and the Cisco NPE-G1 router.

A SAMI card with 2 GB of memory is recommended for PDSN R4.0.. Refer to the following document for more information regarding the respective platforms:

Release Notes for the Cisco PDSN 4.0 Feature in Cisco IOS Release 12.4(15)xx for information about the supported platforms.

Supported Standards, MIBs, and RFCs

Standards

TIA/EIA/IS-835-B, Wireless IP Network Standard

TIA/EIA/IS-2001-B, Interoperability Specification (IOS) for CDMA 2000 Access Network Interfaces (Also known as 3GPP2 TSG-A and as TR45.4)

TIA/EIA/TSB-115, Wireless IP Network Architecture Based on IETF Protocols

MIBs

CISCO_CDMA_PDSN_MIB.my

CISCO_PROCESS_MIB.my

CISCO_MOBILE_IP_MIB.my

CISCO_AHDLC_MIB.my

CISCO_AAA_CLIENT_MIB.my

CISCO_AAA_SERVER_MIB.my

CISCO_VPDN_MGMT_MIB.my

CISCO_VPDN_MGMT_EXT_MIB.my

For descriptions of supported MIBs and how to use MIBs, see the Cisco MIB web site on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.

RFCs

RFC 791, Internet Protocol

RFC 1144, Compressing TCP/IP Headers for Low-speed Serial Links

RFC 1332, The PPP Internet Protocol Control Protocol (IPCP)

RFC 1334, PPP Authentication Protocols

RFC 1661, The Point-to-Point Protocol (PPP)

RFC 1662, PPP in HDLC-like Framing

RFC 1962, The PPP Compression Control Protocol (CCP)

RFC 1974, PPP Stac LZS Compression Protocol

RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP)

RFC 2002, IP Mobility Support

RFC 2003, IP Encapsulation within IP

RFC 2005, Applicability Statement for IP Mobility Support

RFC 2006, The Definitions of Managed Objects for IP Mobility Support using SMIv2

RFC 2118, Microsoft Point-To-Point Compression (MPPC) Protocol

RFC 2344, Reverse Tunneling for Mobile IP

RFC 2401, Security Architecture for the Internet Protocol

RFC 2402, IP Authentication Header

RFC 2406, IP Encapsulating Security Payload (ESP)

RFC 3012, Mobile IPv4 Challenge/Response Extension

Configuration Tasks

This section describes the steps for configuring the Cisco PDSN software on the MWAM platform. Prior to configuring instances of the PDSN on MWAM application cards, you must create a base Catalyst 6500 or 7600 configuration. Refer to the Cisco Multi-processor WAN Application Module Installation and Configuration Note for more information.

System Requirements

This section describes the system requirements for Cisco IOS Release 12.4(15)XR2:

Memory Requirements

Hardware Supported

Software Compatibility

Determining the Software Version

Configuring the PDSN Image

Configuring PDSN Session Redundancy Infrastructure

Memory Requirements

Table 12 shows the memory requirements for the PDSN Software Feature Set that supports the SAMI card on the Cisco7600 Internet router platform. The table also lists the memory requirements for the IP Standard Feature Set (for the Cisco PDSN).

Table 12 Memory Requirements for the  SAMI Blade on the Cisco 7600 Router

Platform
Software
Feature Set
Image Name
Flash
Memory
Required
DRAM
Memory
Required
Runs
From
Cisco 7600 Internet Router

PDSN Software Feature Set

12.4(15)XR- c7svcsami-c6ik9s-mz.124-15.XR

(This is a bundled image)

128MB

2048MB

RAM


Hardware Supported

Cisco IOS Release 12.4(15)XR2 is optimized for the SAMI Card on the Cisco 7600 Internet router platform.

A Hardware-Software Compatibility Matrix is available on CCO for users with CCO login accounts. This matrix allows users to search for supported hardware components by entering a Cisco platform and IOS Release. The Hardware-Software Compatibility Matrix tool is available at the following URL: http://www.cisco.com/cgi-bin/front.x/Support/HWSWmatrix/hwswmatrix.cgi

The Cisco PDSN 4.0 release will be a special release that is developed on Cisco IOS 12.4 for the SAMI card on the Cisco 7600 Internet router platform, and the Cisco NPE-G1 router.

A SAMI card with 2 GB of memory is recommended for PDSN R4.0.

For user migration, one of the processors on the SAMI should act as a standby to an active MWAM processor which hosts the PDSN application. Through systems sync, ensure that the standby SAMI processor gets all session and flow information from the active MWAM processor. For user migration, the correlation will be 5 to 5 from a processor standpoint, since the 6th processor on MWAM blade will not be used for sync. Once the sync is done, perform the switchover and take the active MWAM off line. The SAMI now becomes active, and user sessions are preserved with no loss of data.

The steps to setup up the SAMI and HSRP to make it the standby to MWAM are similar to those related to MWAM redundancy.

A Hardware-Software Compatibility Matrix is available on CCO for users with CCO login accounts. This matrix allows users to search for supported hardware components by entering a Cisco platform and IOS Release. The Hardware-Software Compatibility Matrix tool is available at the following URL:

http://www.cisco.com/cgi-bin/front.x/Support/HWSWmatrix/hwswmatrix.cgi

Software Compatibility

Cisco IOS Release 12.4(15)XR2 is a special release that is developed on Cisco IOS Release 12.4.

Cisco IOS Release 12.4(15)XR2 supports the same features that are in Cisco IOS Release 12.4, with the addition of the Cisco PDSN feature.

Determining the Software Version

To determine the version of Cisco IOS software running on your router, log in to the router and enter the show version EXEC command:

Router#show version
Cisco IOS Software, MWAM Software (MWAM-C6IS-M), Version 12.4(15)XN , RELEASE SOFTWARE
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Tue 11-Dec-07 15:44 by jsomiram

ROM: System Bootstrap, Version 12.2(11)YS2 RELEASE SOFTWARE 

PDSN-S2000-BAL uptime is 4 minutes
System returned to ROM by bus error at PC 0x2033D804, address 0x283 at 06:56:44 PDT Mon 
Dec 3 2007
System restarted at 03:29:24 PDT Tue Dec 11 2007
System image file is "svcmwam-c6is-mz.xn"

Cisco MWAM (MWAM) processor with 997376K/32768K bytes of memory.
SB-1 CPU at 700MHz, Implementation 1025, Rev 0.2

Last reset from power-on
1 Gigabit Ethernet interface
511K bytes of non-volatile configuration memory.

Configuration register is 0x4

Router#

Upgrading to a New Software Release

For information on upgrading to a new software release, see the product bulletin Cisco IOS Software Upgrade Ordering Instructions located at:

http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/957_pp.htm

Configuring the PDSN Image

The Cisco PDSN can provide four classes of user services: Simple IP, Simple IP with VPDN, Mobile IP, and proxy Mobile IP. The following sections describe the configuration tasks for implementing Cisco PDSN. Each category of tasks indicates whether the tasks are optional or required.

R-P Interface Configuration Tasks (Required for all classes of user services)

The following tasks establish the R-P interface, also referred to as the A10/A11 interface.

To configure the R-P interface, complete the following tasks:

Enabling PDSN Services

Creating the CDMA Ix Interface

Creating a Loopback Interface

Creating a Virtual Template Interface and Associating It With the PDSN Application

Enabling R-P Interface Signaling

User Session Configuration Tasks (Optional)

To configure the user session, complete the following task.

Configuring User Session Parameters

Session Redundancy Configuration Tasks

To configure Session Redundancy on the PDSN, complete the following tasks:

Configuring HSRP

Enabling HSRP and Configuring an HSRP Master Group

Configuring Follow Groups

Enabling Inter-Device Redundancy

Configuring the Inter-Device Communication Transport

Using the Loopback Interface For the PDSN-AAA Server Interface

AAA and RADIUS Configuration Tasks (Required for All Scenarios)

To configure the AAA and RADIUS in the PDSN environment, complete the following tasks.

Configuring AAA in the PDSN Environment

Configuring RADIUS in the PDSN Environment

Prepaid Configuration Tasks

Configuring Prepaid in the PDSN Environment

VPDN Configuration Tasks (Required for Simple IP with VPDN Scenario)

To configure the VPDN in the PDSN environment, complete the following task:

Enabling VPDN in a PDSN Environment

Mobile IP Configuration Tasks (Required for Mobile IP)

To configure Mobile IP on the PDSN, complete the following task:

Configuring the Mobile IP FA

Configuring Mobile IP Security Associations

Enabling Network Management

PDSN Selection Configuration Tasks (Optional)

To configure PDSN selection, complete the following tasks:

Configuring PDSN Cluster Controller

Configuring PDSN Cluster Member

Network Management Configuration Tasks (Required for Network Management in Any Scenario)

To configure network management, complete the following task:

Enabling Network Management

Other Configuration Tasks

The following tasks are optional on the PDSN:

Configuring Always On Service

Configuring A11 Session Updates

Configuring SDB Indicator Marking

Configuring SDB Indicator Marking for PPP Control Packets

Configuring PoD on the PDSN

Configuring PoD on the PDSN (RADIUS Disconnect)

Configuring Mobile IP Resource Revocation on the PDSN

Configuring Closed-RP Interfaces

Configuring Short Data Burst Flagging

Configuring PDSN Accounting Events

Configuring CDMA RADIUS Attributes

Tuning, Verification, and Monitoring Tasks (Optional)

To tune, verify, and monitor PDSN elements, complete the following tasks:

Monitoring and Maintaining the PDSN

Enabling PDSN Services

To enable PDSN services, use the following commands in global configuration mode:

Command
Purpose

Router(config)# service cdma pdsn

Enables PDSN services.


Creating the CDMA Ix Interface

To create the CDMA Ix interface, use the following commands in global configuration mode:

Command
Purpose

Router(config)# interface cdma-Ix1

Defines the CDMA virtual interface for the R-P interface.

Router(config-if)# ip address ip-address mask

Assigns an IP address and mask to the CDMA-Ix virtual interface. This IP address will be used by the RAN to communicate with the PDSN.


Creating a Loopback Interface

We recommend that you create a loopback interface and then associate the loopback interface IP address to the virtual template, rather than directly configuring an IP address on the virtual template.

To create a loopback interface, use the following commands in global configuration mode:

Command
Purpose

Router(config)# interface loopback number

Creates a loopback interface. A loopback interface is a virtual interface that is always up.

Router(config-if)# ip address ip-address mask

Assigns an IP address to the loopback interface.


Creating a Virtual Template Interface and Associating It With the PDSN Application

Creating a virtual template interface allows you to establish an interface configuration and apply it dynamically.

To create a virtual template interface that can be configured and applied dynamically, use the following commands in global configuration mode:

Command
Purpose

Router(config) interface virtual-template number

Creates a virtual template interface.

Router(config-if)# ip unnumbered loopback number

Assigns the previously defined loopback IP address to the virtual template interface.

Router(config-if)# ppp authentication chap pap optional

Enables PPP authentication.

Router(config-if)# ppp accounting none

Disables PPP accounting to enable 3GPP2 accounting.

Router(config-if)# ppp accm 0

Specifies the transmit ACCM table value. The value must be specified as 0.

Router(config-if)# ppp timeout idle value

Specifies the PPP idle timeout.

Router(config-if)# exit

Exit interface configuration mode.

Router(config)# cdma pdsn virtual-template virtual-template-num

Associates a virtual template with the PDSN application.


Enabling R-P Interface Signaling

To enable the R-P interface signaling, use the following commands in global configuration mode:

Command
Purpose

Router(config)# cdma pdsn secure pcf lower_addr [upper_addr] spi {spi_val | [inbound in_spi_val outbound out_spi_val]} key {ascii | hex} string

Defines the PCF security association on the PDSN.

Router(config)# cdma pdsn a10 max-lifetime seconds

Specifies the maximum lifetime the PDSN accepts in A11 registration requests from the PCF.

Router(config)# cdma pdsn a10 gre sequencing

Enables inclusion of per-session Generic Routing Encapsulation (GRE) sequence numbers in the outgoing packets on the A10 interface. (This is the default behavior.)

Router(config)# cdma pdsn retransmit a11-update number

Specifies the maximum number of times an A11 Registration Update message will be re-transmitted.

Router(config)# cdma pdsn timeout a11-update seconds

Specifies A11 Registration Update message timeout value.

Router(config)# cdma pdsn maximum pcf number

Specifies the maximum number of packet control functions (PCF) that can be connected to the PDSN at one time.

Configuring User Session Parameters

To configure user session parameters, use the following commands in global configuration mode:

Command
Purpose

Router(config)# cdma pdsn maximum sessions maxsessions

Specifies the maximum number of mobile sessions allowed on a PDSN.

Router(config)# cdma pdsn ingress-address-filtering

Enables ingress address filtering.

Router(config)# cdma pdsn msid-authentication [imsi number] [min number] [irm number] [profile-password password]

Enables provision of Simple IP service using MSID-based authentication.

Router(config)# cdma pdsn timeout mobile-ip-registration timeout

Specifies the number of seconds before which Mobile IP registration should occur for a user who skips PPP authentication.


Configuring PDSN Session Redundancy Infrastructure

The PDSN-SR feature uses the Cisco IOS Check-point Facility (CF) to send stateful data over Stream Control Transmission Protocol (SCTP) to a redundant PDSN. Additionally, in conjunction with Cisco IOS HSRP, the PDSN uses the Cisco IOS Redundancy Facility (RF) to monitor and report transitions on Active and Standby PDSNs.

Before configuring PDSN-SR, you need to configure the inter-device redundancy infrastructure.

Configuring HSRP

The Hot Standby Router Protocol (HSRP) provides high network availability because it routes IP traffic from hosts on networks without relying on the availability of any single router. HSRP is used in a group of routers for selecting an Active router and a Standby router. HSRP monitors both the inside and outside interfaces so that if any interface goes down, the whole device is deemed to be down and the Standby device becomes active and takes over the responsibilities of an Active device.

When configuring HSRP, note that the following recommendation and restrictions apply:

At minimum, HSRP must be enabled and an HSRP a "master" group defined on one interface per PDSN instance. A "follow" group can be configured on all other PDSN interfaces using the standby interface configuration command with the follow keyword option specified. The advantages of using follow groups are:

The follow group feature enables all interfaces on which it is configured to share the HSRP parameters of the master group.

Interfaces that share the same group will follow the state of master interface and will use same priority as master interface. This will ensure that all interfaces are in the same HSRP state. Otherwise there is a possibility of one or more interfaces to assume another role than the master HSRP interface.

This optimizes HSRP group number and minimizes the configuration and maintenance overhead when having large configurations.

It eliminates unnecessary network traffic over all interfaces by eliminating HSRP Hello messages from follow groups, if configured.


Note Do not configure a preemption delay on the Standby PDSN using the standby preempt interface configuration command.


When the standby use-bia command is not used to allow bridge and gateways to learn the virtual MAC address, for optimization purposes, configure the standby mac-refresh command to a value greater than the default (hello messages are sent every 10 seconds) under the main interface (gig0/0). This value is used as the hello message interval.


Note If standby use-bia is configured, then there will be no hello messages sent out of follow group interfaces. It is recommended to use standby use-bia unless explicitly required not to configure.


An ARP multicast packet is sent out when there is a HSRP state change to Active. ARP requests for follow group virtual IP address are responded if HSRP state is Active. Also an ARP multicast is sent on the follow group VLAN when a slave virtual IP address is configured and if the master group is Active.

Use the same group number for each PDSN follow group as is defined for the primary group. Using the same group number for the primary and follow groups facilitates HRSP group setup and maintenance in an environment that contains a large number of PDSN interfaces and HRSP groups.

More information on HSRP configuration and HSRP groups can be found here:

http://www.cisco.com/en/US/partner/tech/tk648/tk362/tk321/tsd_technology_support_sub-protocol_home.html

and

http://www.cisco.com/en/US/partner/tech/tk648/tk362/technologies_configuration_example09186a0080094e90.shtml

Enabling HSRP and Configuring an HSRP Master Group

To enable HSRP on an interface and configure the primary group, use the following commands in interface configuration mode:

Command
Purpose

Router(config-if)# standby [group-number] ip [ip-address [secondary]]


Enables the HSRP on the interface.

Router(config-if)# standby [group-number] priority priority

Sets the Hot Standby priority used in choosing the active router. The priority value range is from 1 to 255, where 1 denotes the lowest priority and 255 denotes the highest priority. Specify that, if the local router has priority over the current active router, the local router should attempt to take its place as the active router.

Router(config-if)# standby [group-number] name name

 

Specifies the name of the standby group.

Router(config-if)# standby use-bia [scope interface]

 

(Optional) Configures HSRP to use the burned-in address of an interface as its virtual MAC address instead of the preassigned MAC address.

Configuring Follow Groups

HSRP follow groups are configured to share the HSRP parameters of the primary group by defining a follow group on the interface using the standby interface configuration command with the follow keyword option specified. Interfaces that share a group track states together and have the same priority.

To configure an interface to follow a primary group, use the following commands in interface configuration mode:

Command
Purpose

Router(config-if)# standby group-number follow group-name


Specifies the number of the follow group and the name of the primary group to follow and share status.

Note It is recommended that the group number specified is the same as the primary group number.

Router(config-if)# standby group-number ip virtual-ip-address


Specifies the group number and virtual IP address of the follow group.

Note The group number specified above should be same as the master group number.

Enabling Inter-Device Redundancy

To enable inter-device redundancy, use the following commands beginning in global configuration mode:

Command
Purpose

Router(config)# redundancy inter-device


Configures redundancy and enters inter-device configuration mode.

To remove all inter-device configuration, use the no form of the command.

Router(config-red-interdevice)# scheme standby standby-group-name

Defines the redundancy scheme that is to be used. Currently, standby is the only supported scheme.

standby-group-name-Must match the standby name specified in the standby name interface configuration command (see the "Configuring HSRP" section). Also, the standby name should be the same on both PDSNs.

Router(config-red-interdevice)# exit

Returns to global configuration mode.


Configuring the Inter-Device Communication Transport

Inter-device redundancy requires a transport for communication between the redundant PDSNs. This transport is configured using Interprocess Communication (IPC) commands.

To configure the inter-device communication transport between the two PDSNs, use the following commands beginning in global configuration mode:

Command
Purpose

Router(config)# ipc zone default

Configures the Inter-device Communication Protocol (IPC) and enters IPC zone configuration mode.

Use this command to initiate the communication link between the Active device and the Standby device.

Router(config-ipczone)# association 1

Configures an association between two devices and enters IPC association configuration mode.

In IPC association configuration mode, you configure the details of the association, such as the transport protocol, local port and local IP addresses, and the remote port and remote IP addresses.

Valid association IDs range from 1 to 255. There is no default value.

Router(config-ipczone)# no shutdown

Restarts a disabled association and its associated transport protocol.

Note Shutdown of the association is required for any changes to the transport protocol parameters.

Router(config-ipczone-assoc)# protocol sctp

Configures Stream Control Transmission Protocol (SCTP) as the transport protocol for this association and enables SCTP protocol configuration mode.

Router(config-ipc-protocol-sctp)# local-port local_port_num

Defines the local SCTP port number to use to communicate with the redundant peer and enables IPC Transport-SCTP local configuration mode.

Valid port numbers range from 1 to 65535. There is no default value.

Note The local port number should be the same as the remote port number on the peer router.

Router(config-ipc-local-sctp)# local ip ip_addr

Defines the local IP address that is used to communicate with the redundant peer. The local IP address must match the remote IP address on the peer router.

Router(config-ipc-local-sctp)# keepalive [period [retries]]

Enables keepalive packets and specifies the number of times that the Cisco IOS software tries to send keepalive packets with a response before bringing down the interface or tunnel protocol for a specific interface.

Valid value for period is an integer value in seconds great than 0. The default is 10. Valid value for retries is an integer value greater than one and less than 355. The default is the previously used value or 5 if there was no value previously specified.

Router(config-ipc-local-sctp)# retransmit-timeout interval

Configures the message retransmission time.

Valid range is 300 to 60000 milliseconds. The minimum default is 1000. The maximum default is 60000.

Router(config-ipc-local-sctp)# path-retransmit number

Configures the maximum number of keep-alive retries before the corresponding destination address is marked inactive.

Valid range is 2 to 10. The default is 5.

Router(config-ipc-local-sctp)# assoc-retransmit number

Defines the maximum number of retransmissions over all destination addresses before an association is declared failed.

Valid range is 2 to 20. The default is 10.

Router(config-ipc-local-sctp)# exit

Exits IPC transport - SCTP local configuration mode.

Router(config-ipc-protocol-sctp)# remote-port port_nun

Defines the remote SCTP port that is used to communicate with the redundant peer and enables IPC Transport-SCTP remote configuration mode.

Valid port numbers range from 1 to 65535. There is no default.

Note The remote port number should be the same as the local port number on the peer device.

Router(config-ipc-remote-sctp)# remote-ip ip_addr

Defines the remote IP address of the redundant peer that is used to communicate with the local device. All remote IP addresses must refer to the same device.

To remove an association configuration, use the no form of the command.

Using the Loopback Interface For the PDSN-AAA Server Interface

To ensure that the AAA server views the active and standby units as a single NAS, the same NAS IP address should be used by both the units. Now, the NAS IP Address can be configured for the PDSN using the ip radius source-interface command. When configured, the IP address of that interface is used as the NAS IP Address.

However, the CLI does not support virtual IP addresses (HSRP). As a result, the only way to ensure that both the units appear as a single NAS is to configure a loopback interface, and use that interface as the source-interface. In short, the CLI would look something like:

ip radius source-interface Loopback1

Configuring Application Tracking to Handle active-active Situation

Command
Purpose

Router(config) # track object-id application pdsn

Defines a tracking object for PDSN application.

Router(config-if) # standby track object-id [decrement priority]

Associates the tracking object defined for PDSN with the HSRP config. HSRP would start tracking the state of this object. The configured decrement priority is used to change HSRP priority based on the state of the tracking object. If the tracking object if "UP", HSRP will have the configured priority. When the tracking object is "DOWN", HSRP decrements its priority by the decrement priority specified in the standby track command.

Configuring AAA in the PDSN Environment

Access control is the way you manage who is allowed access to the network server and the services they are allowed to use. AAA network security services provide the primary framework through which you set up access control on your router or access server. For detailed information about AAA configuration options, refer to the "Configuring Authentication," and "Configuring Accounting" chapters in the Cisco IOS Security Configuration Guide.

To configure AAA in the PDSN environment, use the following commands in global configuration mode:

Command
Purpose

Router(config)# aaa new-model

Enables AAA access control.

Router(config)# aaa authentication ppp default group radius

Enables authentication of PPP users using RADIUS.

Router(config)# aaa authorization configuration default group radius

Enables Network Access Identifier (NAI) construction in the absence of CHAP.

Router(config)# aaa authorization config-commands

Re-establishes the default created when the aaa authorization commands level method1 command was issued.

Router(config)# aaa authorization network if-authenticated default group radius

Restricts network access to a user. Runs authorization for all network-related service requests. Uses the group radius authorization method as the default method for authorization.

Router(config)# aaa accounting update periodic minutes

Enables an interim accounting record to be sent periodically to the accounting server. The recommended period of time is 60 minutes.

Router(config)# aaa accounting network pdsn start-stop group radius

Enables AAA accounting of requested services for billing or security purposes when you use RADIUS.

Configuring RADIUS in the PDSN Environment

RADIUS is a method for defining the exchange of AAA information in the network. In the Cisco implementation, RADIUS clients run on Cisco routers and send authentication requests to a RADIUS server that contains all user authentication and network server access information. For detailed information about RADIUS configuration options, refer to the "Configuring RADIUS" chapter in the Cisco IOS Security Configuration Guide.

To configure RADIUS in the PDSN environment, use the following commands in global configuration mode:

Command
Purpose

Router(config)# radius-server host ip-addr key sharedsecret

Specifies the IP address of the RADIUS server host and specifies the shared secret text string used between the router and the RADIUS server.

Router(config)# radius-server vsa send accounting 3gpp2

Enables the use of vendor-specific attributes (VSA) as defined by RADIUS IETF attribute 26. Limits the set of recognized vendor-specific attributes to only accounting attributes.

Router(config)# radius-server vsa send authentication 3gpp2

Enables the use of vendor-specific attributes (VSA) as defined by RADIUS IETF attribute 26. Limits the set of recognized vendor-specific attributes to only authentication attributes.

Router(config)# radius-server attribute 55 include-in-acct-req

Enables sending G4 (Event Time) Accounting-Start from PDSN.

Configuring Prepaid in the PDSN Environment

For the 1.2 release of the Cisco PDSN software, to configure prepaid, ensure that you include crb-entity-type=1 in the user profile.

In Cisco PDSN release 2.0 and above, to configure IS835C Prepaid, use the following commands in global configuration mode:

Command
Purpose

router (config)# cdma pdsn accounting prepaid ?

duration

  threshold

volume

Prepaid service based on duration.

Configure threshold percentage per quota.

Prepaid service based on volume.

Enabling VPDN in a PDSN Environment

To configure VPDN in the PDSN environment, use the following commands in global configuration mode:

Command
Purpose

Router(config)# vpdn enable

Enables VPDN.

Router(config)# vpdn authen-before-forward

Specifies to authenticate a user locally before tunneling.

For more information about VPDNs, refer to the Cisco IOS Release 12.3 documentation modules Cisco IOS Dial Services Configuration Guide: Network Services and Cisco IOS Dial Services Command Reference.

Configuring the Mobile IP FA

Mobile IP operation (as specified by TR-45.6) requires the ability to authenticate a mobile station through a challenge/response mechanism between the PDSN (acting as an FA) and the mobile station.

To configure the Mobile IP FA, use the following commands in global and interface configuration modes:

Command
Purpose

Router(config)# router mobile

Enables Mobile IP.

This and other Mobile IP commands are used here to enable R-P signaling. They are required regardless of whether you implement Simple IP or Mobile IP.

Router(config)# cdma pdsn send-agent-adv

Enables agent advertisements to be sent over a newly formed PPP session with an unknown user class that negotiates IPCP address options.

Router(config) interface virtual-template number

Creates a virtual template interface.

Router(config-if)# cdma pdsn mobile-advertisement-burst {[number value] | [interval msec]}

Configures the number of FA advertisements to send and the interval between them when a new PPP session is created.

Router(config-if)# ip mobile foreign-service challenge {[timeout value] | [window num]}

Configure the challenge timeout value and the number of valid recently-sent challenge values.

Router(config-if)# ip mobile foreign-service challenge forward-mfce

Enables the FA to send mobile foreign challenge extensions (MFCE) and mobile node-AAA authentication extensions (MNAE) to the HA in registration requests.

Router(config-if)# ip mobile registration-lifetime seconds

Configures the maximum Mobile IP registration lifetime.

Router(config-if)# ip mobile foreign-service [reverse-tunnel [mandatory]]

Enables Mobile IP FA service on this interface.

Router(config-if)# ip mobile foreign-service registration

Sets the R bit in an Agent Advertisement.


To reduce the virtual-access cloning time in order to increase the CPS rate on a standalone PDSN on a Cisco router, use the following per interface configurations in global configuration mode:

Command
Purpose

Router(config)# ip mobile foreign-service


   ip mobile prefix-length


ip mobile registration-lifetime

Enables foreign agent service on an interface if care-of addresses are configured

Appends the prefix-length extension to the advertisement.

Sets the registration lifetime value advertised.

Router(config)# ip mobile foreign-service challenge


   home-access allowed



   limit




   registration-required




   reverse-tunnel


(Optional) Configures the foreign agent challenge parameters.

(Optional) Controls which home agent addresses mobile nodes can be used to register. The access list can be a string or number from 1 to 99.

(Optional) Number of visitors allowed on the interface. The Busy (B) bit will be advertised when the number of registered visitors reaches this limit.

(Optional) Solicits registration from the mobile node even if it uses collocated care-of addresses. The Registration-required (R) bit will be advertised.

(Optional) Enables reverse tunneling on the foreign agent. For releases prior to 12.3T, you cannot use this keyword when you enable foreign agent service on a subinterface.

The CPS on a standalone PDSN on a Cisco Router should improve to 100 CPS from the current number of 40.

Configuring Proxy Mobile IP Attributes Locally

As an alternative to true Mobile IP, which is not supported by all mobile devices, you can configure the Cisco PDSN to provide many of the benefits of Mobile IP through the use of proxy Mobile IP. All proxy Mobile IP attributes can be retrieved from the AAA server. To configure proxy Mobile IP attributes locally, use the following command in global configuration mode:

Command
Purpose

Router(config)# ip mobile proxy-host nai username@realm [flags rrq-flags] [ha homeagent] [homeaddr address] [lifetime value] [local-timezone]

Specifies proxy Mobile IP attributes locally on the PDSN.

Configuring Mobile IP Security Associations

To configure security associations for mobile hosts, FAs, and HAs, use one of the following commands in global configuration mode:

Command
Purpose

Router(config)# ip mobile secure {aaa-download | visitor | home-agent | proxy-host} {lower-address [upper-address] | nai string} {inbound-spi spi-in   outbound-spi spi-out | spi spi} key {hex | ascii} string [replay timestamp [number] algorithm md5 mode prefix-suffix]

Specifies the security associations for IP mobile users.

Router(config)# ip mobile secure proxy-host nai string spi spi key {ascii | hex} string

Specifies the security associations for proxy Mobile IP users.

Configuring PDSN Cluster Controller

To configure the PDSN Cluster Controller attributes locally, use the following commands in global configuration mode.


Note These commands have no effect if the router supports PDSN member functionality from a prior configuration.

Command
Purpose

Router(config)# cdma pdsn secure cluster default spi spi number [key ascii | hex value ]

Configures one common security association for all PDSNs in a cluster.

Router #cdma pdsn cluster controller interface interface name

Enables the controller functionality for PDSN Controller/Member clustering, and specifies which interface to send messages to and from

Router# cdma pdsn cluster controller standby cluster-name

Configures the PDSN to operate as a cluster controller in standby.



Configuring PDSN Cluster Member

To configure the PDSN Cluster Member attributes locally, use the following commands in global configuration mode:


Note These commands have no effect if the router supports PDSN member functionality from a prior configuration.


Command
Purpose

Router(config)# cdma pdsn secure cluster default spi spi_index [key ascii | hex value]

Configures one common security association for all PDSNs in a cluster.

Router(config)# cdma pdsn cluster member controller ipaddr

Configures the PDSN to operate as a cluster member.

Router(config)# cdma pdsn cluster member interface interface name

Configures the PDSN to operate as a cluster member.


Enabling Network Management

To enable SNMP network management for the PDSN, use the following commands in global configuration mode:

Command
Purpose

Router(config)# snmp-server community string [ro | rw]

Specifies the community access string to permit access to the SNMP protocol.

Router(config)# snmp-server enable traps cdma

Enables network management traps for CDMA.

Router(config)# snmp-server host host-addr traps version {1 | 2 | 3 [auth | noauth | priv]}

Specifies the recipient of an SNMP notification operation.

Router(config)# cdma pdsn failure-history entries

Specifies the maximum number of entries that can be maintained in the SNMP session failure table.

Router(config)#no virtual-template snmp

Prevents the virtual-access subinterfaces from being registered with the SNMP functionality of the router and reduces the amount of memory being used, thereby increasing the call setup performance.


Configuring Always On Service

Always On service maintains the subscriber's packet data session in the local network. The PDSN will not initiate release of the subscriber's packet data session due to PPP idle timer expiry, unless the PDSN determines the user is no longer reachable. The Always On feature is enabled by default. To change the default parameters related to this feature, use following command:

Command
Purpose

Router(config)# cdma pdsn a10 always-on keepalive {interval 1-65535 [attempts 0-255] | attempts 0-255}

Configures always-on service parameters on the PDSN.

The keepalive interval is the duration in seconds, for which the PDSN waits for the LCP echo response from peer before sending next LCP echo. The default value is 3seconds. The no form of this command will return to the default value.

attempts is the number of times LCP echo must be sent before declaring an always-on user is not reachable for tearing down the session after the idle timer expires. The default value is 3. Configuring this variable to 0 is similar to ignoring the always-on property for the user.


Configuring A11 Session Updates

A11 Session Update messages are sent from the PDSN to the PCF to add, change, or update session parameters for an A10 connection. To enable the A11 Session Update feature, perform the following tasks:

Command
Purpose

Router(config)# cdma pdsn a11 session-update {[always-on] 1-10 [rn-pdit] 0-9}

Enables the A11 Session update feature on the PDSN, and sends an A11 session update for either the Always On, or RNPDIT (or both) attributes that are downloaded from the AAA during the authentication phase.

The default timeout value is 3 seconds. The default retransmit number is 3.

Router#cdma pdsn retransmit a11-update number

Specifies the maximum number of times an A11 Registration Update message is retransmitted. Possible values are 0 through 9. The default is 5 retransmissions.


Configuring SDB Indicator Marking

This feature supports short data burst applications, such as SIP signaling for PTT applications, and proposes the interaction with the PDSN. SIP is used by PTT applications to signal a PTT call. The message is short and needs to be delivered to the end-user. The Short Data Burst support on the RAN can be used to send these to the end-user, especially when the messages are to be terminated to the mobile. This is especially important when the mobile user is actually dormant. Use the following command to configure SDB Indicator Marking:

Command
Purpose

Router(config)# cdma pdsn a11 dormant sdb-indication gre-flags group-number

The group-number represents the classified match criteria. All packets that are set with the specific group-number will be flagged for SDB usage between the PCF and the PDSN.

The B bit (SDB indication) would be set for packets matching the sdb-indication group-number.


Configuring SDB Indicator Marking for PPP Control Packets

While data packets can be sent towards the mobile using SDBs as shown above, SDBs can also be used for delivering PPP control packets. This can be particularly helpful for Always-On sessions, where the session is dormant. Basically, with Always On configured, the PDSN sends out LCP echo requests (and waits for LCP echo replies) to keep the session alive. Hence, when such a session goes dormant, a data channel needs to be setup to deliver these LCP echo requests to the MN. The other option is to use SDBs to deliver the LCP echo requests without setting up a data channel.

Use the following CLI in conjunction of the above CLI to enable this feature:

Command
Purpose

Router(config)# cdma pdsn a11 dormant sdb-indication match-qos-group group-number ppp-ctrl-pkts

The group-number represents the classified match criteria.


Configuring PoD on the PDSN

To enable the Packet of Disconnect (RADIUS Disconnect) feature on the PDSN, perform the following tasks:

Command
Purpose

Router(config)# cdma pdsn radius disconnect

Enables the RADIUS disconnect feature on the PDSN.

Router(config)# aaa pod server [clients ipaddr1 [ipaddr2] [ipaddr3] [ipaddr4]] [port port-number] [auth-type {any | all | session-key}] server-key [encryption-type] string               

AAA command that enables listening for POD packets.

Router(config)# aaa server radius dynamic-author Router(config-locsvr-radius)#?

RADIUS Application commands:

auth-type   Specify the server authorization type

client      Specify a RADIUS client

default     Set a command to its defaults

exit        Exit from RADIUS application configuration mode

ignore      Override behavior to ignore certain parameters

no          Negate a command or set its defaults

port        Specify port on which local radius server listens

server-key  Encryption key shared with the radius clients

Enters RADIUS application configuration mode, and presents the user with several configuration options.


Configuring Mobile IP Resource Revocation on the PDSN

To enable resource revocation support on PDSN, perform the following task:

Command
Purpose

Router(config)# ip mobile foreign-service revocation [timeout

value] [retransmit value] [timestamp]

timeout value is the time interval in seconds between re-transmission of resource revocation message. The wait time is between 0-100, and the default value is 3 seconds.

retransmit value is the number of maximum re-transmissions of MIPv4 resource revocation messages.

The number of retries for a transaction is 0-100. The default value is 3.

Note All foreign-service configurations should be done globally and not under the virtual-template interface.

Timestamp specifies the unit of timestamp field for revocation. The unit of timestamp value for revocation is in milliseconds.


Configuring Closed-RP Interfaces

To enable the Closed-RP feature on the PDSN, perform the following tasks:

Command
Purpose

Router(config)# cdma pdsn pcf default closed-rp

Enables the Closed-RP feature on the PDSN. All the PCFs connecting to the PDSN will be treated as Closed-RP PCFs. When this command is configured the 3GPP2 (Open) RP interface will be disabled on the PDSN.

Router(config)# cdma pdsn a10 ahdlc trailer

Enables the PDSN such that AHDLC frames are expected to contain the trailer byte. When the no version of the command is configured, each AHDLC frame will be considered a full AHDLC fragment, and the PDSN will start processing the packet.

VPDN Configuration

----------------------

Router(config)#vpdn enable

Router(config)#vpdn authen-before-forward

Router(config)#vpdn ip udp ignore checksum

!

Router(config)#vpdn-group CDMA

Router(config-vpdn)#accept-dialin

Router(config-vpdn-acc-in)#protocol l2tp

Router(config-vpdn)#source-ip CDMA-Ix IP address

Router(config-vpdn)#l2tp tunnel hello value

Router(config-vpdn)#no l2tp tunnel authentication

Router(config-vpdn)#l2tp tunnel timeout no-session never

Enables the virtual private dialup networking on the router and informs the router to look for tunnel definitions in a local database and on a remote authorization server (home gateway).

Configures various Layer 2 Tunneling Protocol (L2TP) tunnel variables.

ip slb serverfarm PDSN-FARM


ip slb vserver PDSN-SLB

virtual 150.150.0.100 udp 1701

serverfarm PDSN-FARM

sticky 65535 group 1 netmask 255.255.254.0

idle 10

inservice

!

Identifies a server farm, and enters server farm configuration mode.

Configures the virtual server.

Sticky forwards requests coming in from each subnet (PCF complex) to the same real server (PDSN instance).


Here is a sample configuration for the Closed-RP feature on the PDSN:

Router#sh run 
Building configuration... 

Current configuration : 3450 bytes 
! 
! Last configuration change at 04:23:40 UTC Tue May 27 2003 
! NVRAM config last updated at 04:24:03 UTC Tue May 27 2003 
! 
version 12.3 
service timestamps debug datetime msec localtime 
service timestamps log datetime msec localtime 
no service password-encryption 
service cdma pdsn 
! 
hostname Router 
! 
boot-start-marker 
boot-end-marker 
! 
! 
aaa new-model 
! 
! 
aaa authentication ppp default group radius 
aaa authorization config-commands 
aaa authorization ipmobile default group radius 
aaa authorization network default group radius 
aaa accounting network pdsn start-stop group radius 
! 
aaa session-id common 
ip subnet-zero 
no ip gratuitous-arps 
ip cef 
no ip domain lookup 
ip dhcp ping packets 0 
! 
! 
vpdn enable 
vpdn authen-before-forward 
vpdn ip udp ignore checksum 
! 
vpdn-group CDMA 
! Default L2TP VPDN group 
 accept-dialin 
  protocol l2tp 
 source-ip 150.150.0.100 
 l2tp tunnel hello 0 
 no l2tp tunnel authentication 
 l2tp tunnel timeout no-session never 
! 
no virtual-template snmp 
! 
! 
! 
interface Loopback0 
 ip address 87.0.0.3 255.0.0.0 
! 
interface CDMA-Ix1 
 ip address 150.150.0.100 255.255.254.0 
 tunnel source 150.150.0.100 
 tunnel key 1 
! 
interface GigabitEthernet0/0 
 no ip address 
! 
interface GigabitEthernet0/0.2 
 encapsulation dot1Q 25 
 ip address 9.15.50.173 255.255.0.0 
! 
interface GigabitEthernet0/0.37 
 encapsulation dot1Q 37 
 ip address 37.0.0.3 255.0.0.0 
! 
interface GigabitEthernet0/0.47 
 encapsulation dot1Q 47 
 ip address 47.0.0.43 255.0.0.0 
! 
interface Virtual-Template1 
 ip unnumbered Loopback0 
 peer default ip address pool pdsn-pool 
 no keepalive 
 ppp accm 0 
 ppp authentication chap pap optional 
 ppp accounting none 
! 
router mobile 
! 
ip local pool mobilenodes 30.0.0.2 30.0.0.255 
ip local pool pdsn-pool 122.3.0.1 122.3.16.1 
ip local pool pdsn-pool 122.4.0.1 122.4.16.1 
ip local pool pdsn-pool 122.5.0.1 122.5.16.1 
ip local pool pdsn-pool 122.1.0.1 122.1.16.1 
ip local pool pdsn-pool 122.2.0.1 122.2.16.1 
ip default-gateway 9.15.0.1 
ip classless 
ip route 7.0.0.1 255.255.255.255 16.1.1.60 
ip route 9.100.0.0 255.255.0.0 9.15.0.1 
ip route 10.76.86.41 255.255.255.255 9.15.0.1 
ip route 10.76.86.62 255.255.255.255 9.15.0.1 
ip route 150.150.2.2 255.255.255.255 47.0.0.2 
ip route 150.150.2.3 255.255.255.255 47.0.0.3 
ip route 150.150.4.2 255.255.255.255 47.0.0.4 
ip route 150.150.4.3 255.255.255.255 47.0.0.5 
ip route 150.150.6.2 255.255.255.255 47.0.0.6 
ip route 150.150.6.3 255.255.255.255 47.0.0.7 
ip route 150.150.8.2 255.255.255.255 47.0.0.8 
ip route 150.150.8.3 255.255.255.255 47.0.0.9 
ip route 150.150.10.2 255.255.255.255 47.0.0.10 
ip route 150.150.10.3 255.255.255.255 47.0.0.11 
no ip http server 
! 
! 
! 
! 
radius-server host 10.76.86.62 auth-port 1645 acct-port 1646 key cisco 
radius-server key cisco 
radius-server vsa send accounting 3gpp2 
cdma pdsn pcf default closed-rp 
cdma pdsn virtual-template 1
no cdma pdsn a10 ahdlc trailer
! 
control-plane 
! 
line con 0 
 exec-timeout 0 0 
 transport preferred all 
 transport output all 
line vty 0 4 
 exec-timeout 0 0 
 transport preferred all 
 transport input all 
 transport output all 
line vty 5 15 
 exec-timeout 0 0 
 transport preferred all 
 transport input all 
 transport output all 

Note You will also have VPDN configuration tasks, Layer 2 Tunneling Protocol (L2TP) tunnel configuration tasks, and Load Balancing configuration tasks to perform. Please refer to the appropriate documentation for more specific information.


For information regarding VPDN configuration details, please refer to the following URL:

http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5207/products_command_reference_chapter09186a00801a7e8f.html#wp1167095

For information regarding Layer 2 Tunneling Protocol (L2TP) tunnel configuration details, please refer to the following URL:

http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5207/products_command_reference_chapter09186a00801a7e90.html

For information regarding IOS Server Load Balancing, please refer to the following URL:

http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5012/products_feature_guide09186a008020b9f3.html#wp3601032

Configuring Short Data Burst Flagging

This feature adds support for short data burst applications such as SIP signaling for PTT applications, and proposes the interaction with PDSN. SIP is used by PTT applications to signal a PTT call. The message is short and needs to be delivered to the end-user. The Short Data Burst support on the RAN can be used to send these over to the end-user, especially when the messages are to be terminated to the mobile.

To configure SDB on the PDSN so that all packets that are set with the specific group-number will be flagged for SDB usage between the PCF and the PDSN, use the following command in global configuration:

Command
Purpose

Router(config)# cdma pdsn a11 dormant sdb-indication gre-flags group-number

Configures SDB so that all packets that are set with the specific group-number will be flagged for SDB usage between the PCF and the PDSN.


Configuring PDSN Accounting Events

To configure attributes of PDSN accounting events, use the following commands in global configuration mode:

Command
Purpose

Router(config)# clock timezone zone hours-offset [minutes-offset]

Sets the time zone for display purposes.

Router(config)# cdma pdsn accounting local-timezone

Sets the local time stamp for PDSN accounting events.

Router(config)# cdma pdsn accounting time-of-day

Sets triggers for accounting information for different times of day.

Router(config)# cdma pdsn accounting send start-stop

Enables the PDSN to send:

An Accounting Stop record when it receives an active stop airlink record (dormant state)

An Accounting Start record when it receives an active start airlink record (active state)


Configuring CDMA RADIUS Attributes

To configure both authentication and accounting requests on the PDSN, perform the following tasks:

Command
Purpose

Router(config)# cdma pdsn attribute send {a1 { fa-chap | mip-rrq} | a2

{auth-req | fa-chap | mip-rrq} | a3 {auth-req | fa-chap | mip-rrq} |

{c5 {acct-reqs} | f15 {acct-reqs} | f16 {acct-reqs} | f5

{fa-chap} | g1 {acct-start} | g2 {acct-start} | g17 | esn-optional |

meid-optional | is835a}

Enables both authentication and accounting requests on the PDSN.


Monitoring and Maintaining the PDSN

To monitor and maintain the PDSN, use the following commands in privileged EXEC mode:

Command
Purpose

Router# clear cdma pdsn cluster controller session records age days

Clears session records of a specified age.

Router# clear cdma pdsn cluster controller session record all

Clears all the session records of the PDSN cluster controller.

Router# clear cdma pdsn cluster controller statistics

Clears PDSN cluster controller statistics.

Router# clear cdma pdsn cluster member statistics

Clears PDSN cluster member statistics.

Router# clear cdma pdsn session {all | pcf ip-addr | msid octet-stream} {send {all-update | termreq}}

Clears the session.

Router# clear cdma pdsn statistics


Clears the RAN-to-PDSN interface (RP) or PPP statistics on the PDSN.

Router# clear ip mobile binding {all [load standby-group-name] | ip-address | nai string ip_address}

Removes mobility bindings.

Router# clear ip mobile visitor [ip-address | nai string ip_address]

Clears visitor information.

Router#clear vpdn tunnel l2tp ?

all All L2TP tunnels

hostname Based on the hostnames

id Based on the tunnel ID

ip Based on IP address

Clears VPDN L2TP Tunnel information for the Closed-PR feature.

Router# show cdma pdsn

Displays the status and current configuration of the PDSN gateway.

Router# show cdma pdsn accounting

Display the accounting information for all sessions and the corresponding flows.

Router# show cdma pdsn accounting detail

Displays detailed accounting information for all sessions and the corresponding flows.

Router# show cdma pdsn accounting session msid

Displays the accounting information for the session identified by the msid.

Router# show cdma pdsn accounting session msid detail

Displays the accounting information (the counter names) for the session identified by the msid.

Router# show cdma pdsn accounting session msid flow

{mn-ip-address IP_address}

Displays the accounting information for a specific flow that is associated with the session identified by the msid.

Router# show cdma pdsn accounting session msid flow user username

Displays accounting information for a flow with username that is associated with the session identified by the msid.

Router# show cdma pdsn ahdlc slot_number channel [channel_id]

Displays Asynchronous High-Level Data Link Control (AHDLC) engine information.

Router# show cdma pdsn cluster controller [configuration | statistics]

Displays configuration and statistics for the PDSN cluster controller.

Router# show cdma pdsn cluster controller config

Displays the IP addresses of the members that are registered with a specific controller.

Router# show cdma pdsn cluster controller member [load | time | ipaddr]

Displays either the load reported by every PDSN cluster member, or the time until (or past) the seek time of the member, or for detailed information related to the member of the specified ip address.

Router# show cdma pdsn cluster controller queueing

Displays statistics associated with controller queueing feature.

Router# show cdma pdsn cluster member queueing

Displays statistics associated with member queueing feature.

Router# show cdma pdsn cluster controller session [count [age days] | oldest [more 1-20 records] | imsi BCDs [more 1-20 records]

Displays session count, or count by age, or one or a few oldest session records, or session records corresponding to the IMSI entered.

Router# show cdma pdsn cluster controller statistics

Displays the IP addresses of the members that are registered with a specific controller.

Router# show cdma pdsn cluster member [configuration | statistics]

Displays configuration and statistics for the PDSN cluster member.

Router# show cdma pdsn flow {mn-ip-address ip_address | msid string | service-type | user string}

Displays flow-based summary of active sessions, and the flows and IP addresses assigned to the mobile numbers in each session.

Router# show cdma pdsn pcf [brief | ip-addr]

Displays the PCF information for those PCFs that have R-P tunnels to this PDSN.

Router# show cdma pdsn pcf secure

Displays security associations for all PCFs configured on this PDSN.

Router# show cdma pdsn resource [slot_number [ahdlc-channel [channel_id]]]

Displays AHDLC resource information.

Router# show cdma pdsn session [brief | dormant | mn-ip-address address | msid msid | user nai]

Displays the session information on the PDSN.

Router# show cdma pdsn statistics [ ahdlc | rp [pcf ip address] | closed-rp [pcf ip address] | error] [ppp [pcf ip address ]]

Displays VPDN, PPP, RP interface, Closed-RP interface, prepaid, RADIUS, and error stati