Feedback
|
Table Of Contents
Cisco Packet Data Serving Node (PDSN) Release 2.0
PMTU Discovery by Mobile IP Client
Features From Previous Releases
Resource Revocation for Mobile IP
Volume-based Prepaid Data Service Flow
Duration-based Prepaid Data Service Flow
Volume-based Prepaid Data Service with Tariff Switching
Mobile IP Call Processing Per Second (CPS) Improvements
IS-835-B Compliant Static IPSec
Configuring IPSec in Cisco IOS
On-Demand Address Pools (ODAP)
PDSN Cluster Controller / Member Architecture
Upgrading the Controller PDSN Software from R1.2 to R2.0
Upgrading the Member PDSN Software from R1.2 to R2.0
Cisco Proprietary Prepaid Billing
Hardware IPSec Acceleration Using IPSec Acceleration Module—Static IPSec
Conditional Debugging Enhancements
Electronic Serial Number (ESN) in Billing
Features Available From Previous PDSN Releases
PDSN Clustering Peer-to-Peer and Controller / Member Architecture
Intelligent PDSN Selection and Load Balancing (Peer-to-Peer)
Related Features and Technologies
Supported Standards, MIBs, and RFCs
Creating the CDMA Ix Interface
Creating a Virtual Template Interface and Associating It With the PDSN Application
Enabling R-P Interface Signaling
Configuring User Session Parameters
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 IS835-B IPSec for the Cisco PDSN
Configuring Proxy Mobile IP Attributes Locally
Configuring Mobile IP Security Associations
Configuring PDSN Cluster Controller
Configuring PDSN Cluster Member
Configuring Peer-to-Peer PDSN Selection
Configuring On Demand Address Pools
Configuring Mobile IP Resource Revocation on the PDSN
Configuring PDSN Accounting Events
Monitoring and Maintaining the PDSN
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
AAA Authentication and Authorization Profile
AAA Profiles for Various Service Types
Authentication and Authorization RADIUS Attributes
Accounting Services RADIUS Attributes
Cisco Packet Data Serving Node (PDSN) Release 2.0
Feature History
This document describes the Cisco Packet Data Serving Node (PDSN) software for use on the Cisco 7200 Series router, and the Cisco Multi-processor WAN Application Module (MWAM) that resides in the Cisco Catalyst 6500 Switch, and 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:
•
Supported Standards, MIBs, and RFCs
•
Monitoring and Maintaining the PDSN
•
AAA Authentication and Authorization Profile
•
Appendix A, "Command Reference"
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 Cisco 7200 routers, and on MWAM cards on the 6500 routers, and 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. For the Cisco PDSN Release 2.0, you must use a Fast Ethernet (FE) interface as the R-P interface on the 7200 platform, and a Giga Ethernet (GE) interface on the MWAM platform.
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, 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:
•
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.
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 MWAM
The MWAM supports the feature set of PDSN Release 2.0, and functionality remains the same as on the Cisco 7200 platforms. The significant difference between the Cisco PDSN on the Cisco 7200 router and on the MWAM is that a Cisco Catalyst 6500 or Cisco 7600 chassis will support a maximum of 6 application modules. Each application module supports 5 IOS images, each with access to 512 Megabytes of RAM. Up to five of these images 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 20,000 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.
Features
New Features in This Release
This section describes the following key features of the Cisco PDSN Release 2.0:
•
Resource Revocation for Mobile IP
•
Mobile IP Call Processing Per Second (CPS) Improvements
•
IS-835-B Compliant Static IPSec
•
On-Demand Address Pools (ODAP)
•
PDSN Cluster Controller / Member Architecture
•
Conditional Debugging Enhancements
Features From Previous Releases
This section lists features that were introduced prior to Cisco PDSN Release 2.0
•
PDSN Cluster Controller / Member Architecture
•
Cisco Proprietary Prepaid Billing
•
Hardware IPSec Acceleration Using IPSec Acceleration Module—Static IPSec
•
Integrated Foreign Agent (FA)
•
PDSN Clustering Peer-to-Peer and Controller / Member Architecture
Note
The Cisco PDSN software offers several feature options which are available on four different images. Some features are image-specific, and are not available on all images. The "PDSN 2.0 Feature Matrix"in Table 1 lists the available images for PDSN 2.0, and identifies the features available on each image.
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 2.0 delivers the following performance improvements compared to Release 1.2:
•
Significant improvements in Mobile IP call setup rate
Performance metrics for the Cisco PDSN with Release 2.0 software on 7200 Platform are:
•
20000 user sessions per on 7206VXR with NPE-400 with 512MB DRAM and on 7206VXR NPE-G1 with 1G DRAM.
•
Maximum of 200,000 user sessions per PDSN cluster configured according to the controller/member architecture (10 members) without R2.0 clustering enhancement
•
Throughput on the R-P interface for non-fragmented packets of size 64, 512 and 1024 bytes
•
Throughput on the R-P interface for fragmented packets of size 64, 512 and 1024 bytes with 20 byte fragmentation
•
Maximum call setup rate for Simple IP and Mobile IP sessions for a stand alone PDSN
•
Maximum call set up rate for a cluster with 8 members configured in a controller/member cluster for Simple IP and Mobile IP Sessions.
•
Maximum of 3000 L2TP tunnel endpoints with a maximum of 20000 sessions distributed across those tunnels
•
Maximum of 3000 Mobile IP tunnels
•
Maximum of 5000 IPSec tunnels with VAM2 hardware support on 7200 Platforms
•
Throughput with Prepaid enabled
•
Throughput with VJ Header compression enabled.
Performance Metrics on 6500/7600 series platform are as follows. The quoted figures are per image, and each MWAM can support 5 PDSN images.
•
20000 user sessions
•
Maximum call setup rate for Simple IP and Mobile IP sessions for a standalone PDSN
•
Maximum of 200,000 user sessions per PDSN cluster configured according to the controller/member architecture, without R2.0 clustering enhancement. Supported cluster configuration is 10 members and 2 controllers of which one is an active controller and the other a standby.
•
Cluster member architecture with 48 members, with R2.0 clustering enhancement
•
Throughput on the R-P interface for non-fragmented packets of size 64, 512 and 1024 bytes
•
Throughput on the R-P interface for fragmented packets of size 64,512 and 1024 bytes with 20 byte fragmentation
•
Call set up rate for a stand-alone PDSN for Simple IP and Mobile IP Sessions
•
Maximum call set up rate for a cluster with 8 members configured in a controller/member cluster for Simple IP and Mobile IP Sessions.
•
Maximum of 3000 L2TP tunnel endpoints with a maximum of 20000 sessions distributed across those tunnels per image.
•
Maximum of 3000 Mobile IP tunnels per image.
•
Maximum of 8000 IPSec tunnels with VPNSM hardware support (This figure is for the chassis, IPSec resources are not linked with PDSN images on MWAM, it is a separate resource)
•
Maximum call set up rate for a cluster with n members configured in a controller/member cluster for Simple IP and Mobile IP Sessions with Release 2.0 Clustering enhancements.
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 applicabled 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 PDSN all the 'ip mobile foreign-service ...' commands need to be configured at the global level and not at the interface level.
•
On 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 on HA is not supported with Home Agent redundancy.
•
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 restrictions are present for this feature:
•
Enabling and Disabling of Radius Disconnect support is allowed only when there are no sessions on PDSN. This will be removed when tracking the STC per session is implemented.
•
All Dormant NVSE are not supported.
The command line interface for this feature will be standard AAA interfaces.
The NAS global AAA command to enable listening for POD packets is:
•
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
•
RADIUS Disconnect capability configuration is allowed only when there are no sessions on the PDSN.
•
All Dormant NVSE is not supported.
•
MIB support is not currently planned.
•
STC attribute received in an Access-Accept message from AR will not be used to enable or disable the Radius disconnect capability per user.
•
Processing of a RADIUS Disconnect message with only NAI present must be configured for compliance to IS 835-C.
•
RADIUS Disconnect Feature is not redundancy aware.
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.0:
•
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.0
•
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.
Step 3
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 4
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 5
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 6
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 recieves 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.
Mobile IP Call Processing Per Second (CPS) 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.0 supports commonly used per-interface configurations in global configuration mode, and supports per-interface for backward compatibility.
IS-835-B Compliant Static IPSec
An IPSec Security Association is a unidirectional logical connection between two IPSec systems, and is uniquely identified by Security Parameter Index (SPI), IP Destination Address, and the Security Protocol (where the Security Protocol is Authenticate Header (AH) or Encapsulating Security Payload (ESP). The Security Association has two types: Transport and Tunnel.
IPSec based security may be applied on tunnels between the PDSN and HA depending on parameters received from Home AAA server. A single tunnel may be established between each PDSN-HA pair. A single tunnel between a PDSN-HA pair can 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 has the same level of protection provided by IPSec.
The IS835 standard 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 on the MN's behalf to the HA. Once Security-Osculations (tunnels) are established, they remain active until there is traffic (user traffic or user binding) on the tunnel, or the lifetime of the security association expires.
IS-835 B specification describes three mechanisms to provide IP Security: 1) Certificates, 2) Dynamically distributed Pre-Shared secret, and 3) Statically configured Pre-Shared secret.
Once security associations (tunnels) are established, they remain active till there is traffic (user traffic or user bindings) on the tunnel, or until the lifetime of the association expires.
The IS835 standard specifies support for the following IPSec modes:
•
IKE & Public Certificate(X.509)
•
Dynamic pre-shared IKE secret distributed by Home Radius Server.
•
Statically configured IKE pre-shared secret.
Note
IS835B Static IPSec feature is avaibale only on the Cisco 7200 Internet router platform. The Cisco IOS IPSec feature is available on the Cisco 7200 7200 Internet router , Cisco 6500 Catalyst switch, and Cisco 7600 switch platforms. PDSN Release 2.0 only supports Statically configured Pre-Shared secret.
The level of IPsec protection on a tunnel between the PDSN and HA is determined by a "security level" parameter: whether to provide IPSec protection on control messages, data, control message plus data, or no protection. The security level attribute is received from the Home Radius server in an Access-Accept Message by the PDSN. On the HA, this attribute has to be configured for each Foreign Agent because there is no provision to pass security-level from the Home AAA server to the Home Agent.
PDSN Release 2.0 supports the following values:
•
IPSec for Mobile Control and Data traffic
•
No IPSec
Once a Security Association is established, it will be periodically refreshed by the PDSN until the tunnel expires.
If reverse tunneling is supported by the HA (as indicated by the RADIUS server), and IPSec security is authorized for the tunneled data, and a mobile requests reverse tunneling, then the PDSN will provide security on the reverse tunnel.
The HA determines which type of security association (if any) is required with a PDSN. The HA uses the same security policy that is specified in the Home RADIUS server and returned to the PDSN in the 3GPP2 security level attribute. All MN will receive the same security level while accessing the same PDSN.
Configuring IPSec in Cisco IOS
To employ IS835-B IPSec on the PDSN requires that you configure the following commands:
•
[no] ip mobile cdma ipsec—enables or disables the CDMA IPSec feature. This command is only present in crypto images for the Cisco 7200 Series Internet Router, and in non-crypto images for the Cisco MWAM.
•
[no] ip mobile cdma ipsec profile profile-tag—This command is only present in crypto images for the Cisco 7200 Series Internet Router.
•
show ip mobile cdma ipsec—This command shows if the feature is enabled.
•
show ip mobile cdma ipsec profile—This command shows the crypto profile configured.
•
[no] debug ip mobile cdma ipsec—This turns on the debug on this feature.
Here is a sample configuration:
Router(config)#crypto isakmp policy 1authentication pre-shareRouter(config)#crypto isakmp key cisco address 7.0.0.2Router(config)#crypto ipsec transform-set mobile-set1 esp-3desRouter(config)#crypto ipsec profile testprofset transform-set mobile-set1Router(config)#crypto identity pdsntestRouter(config)#ip mobile cdma ipsecRouter(config)# ip mobile cdma ipsec profile testprofRouter(config)#ip mobile foreign-agent reg-wait 30Additionally, to employ Cisco IOS IPSec on the PDSN you must configure "Transform" and "CryptoMap," and apply Cryptomap to the interface.
The Transform set represents a certain combination of security protocols and algorithms. During the IPSec security association negotiation, the peers agree to use a particular transform set for protecting particular data flow. Use the crypto ipsec transform-set mobile-set1 esp-3des command to configure the transforms set.
The Crypto map entries created for IPSec pull together the various parts used to set up IPSec security associations, including the following:
•
Which traffic should be protected by IPSec (per a crypto access list).
•
The granularity of the flow to be protected by a set of security associations.
•
The location IPSec-protected traffic should be sent (remote IPSec peer).
•
The local address used for IPSec traffic (applying Crypto map to interface).
•
The type of IPSec security that should be applied to this traffic (selected from a list of one or more transform sets).
•
Whether security associations are manually established, or established with IKE.
•
The parameters that might be necessary to define an IPSec security association.
Crypto map entries with the same crypto map name (but different map sequence numbers) are grouped into a crypto map set. These Crypto map sets are applied to interface; then all traffic passing through the interface is evaluated against the applied crypto map set.
The policy described in the crypto map entries is used during the negotiation of security association, for IPSec to succeed between two IPSec peers, both peers' crypto map entries must a contain compatible configuration statement.
Only one crypto map set is applied to single interface; Multiple interfaces can share the same crypto map set.
Multiple Crypto map entries can be created for interface; the sequence number of each map-entry is used to rank the map-entries.
Multiple Crypto map entries must be created for a given interface if different data flows are handled by separate IPSec peers. If different IPSec security is required for different types of traffic, create a separate access list for each type of traffic, and create a separate crypto map entry for each access list.
The following configuration example illustrates the minimum requirement to establish Crypto map entries that use IKE.
Router(config)# access-list mobile-example permit ip 10.0.0.0 0.0.0.255Router(config)# crypto ipsec transform-set mobile-set1 esp-3desRouter(config)# crypto map map-mobile-example 10 ipsec-isakmpmatch mobile-exampleset transform-set transform-set mobile-set1set peer 10.0.0.34Router(config)# interface FastEthernet0/1ip address 10.0.0.32crypto map map-mobile-exampleCisco employs two additional mechanisms to define cryptomaps:
•
Dynamic Crypto-maps: these are crypto-maps with fe fields that relate to policy. They are only suitable for applications that do not require initiating IKE, but only respond to IKE.
•
IPSec Profiles: is a mechanism to convert a Crypto Map into a template that can be used to dynamically set up an identical policy.
Router(config)# access-list mobile-example permit ip 10.0.0.0 0.0.0.255Router(config)# crypto ipsec transform-set mobile-set1 esp-3desRouter(config)# crypto map map-mobile-example 10 ipsec-isakmp profile example-profilematch mobile-exampleset transform-set transform-set mobile-set1set peer 10.0.0.34The following example illustrates the minimum Crypto configuration for IS835-based IPSec:
Router(config)# crypto isakmp policy 1hash md5authentication pre-shareRouter(config)# crypto isakmp key <cisco> address <peer ip address7.0.0.10>Router(config)# crypto ipsec transform-set testtrans esp-3desRouter(config)#crypto ipsec profile testprofdescription new cliset transform-set testtransOn-Demand Address Pools (ODAP)
A PDSN Cluster can consist of up to ten MWAM cards, with one Cluster Controller and a Backup Cluster Controller, and 48 PDSN IOS application image instances.
While MWAM cards provide a higher density of PDSNs, they make it necessary to allocate IP addresses from a central source. This simplifies configuration so users will not have to configure a local pool of IP addresses in each PDSN. With on-demand address pools, a DHCP/ODAP server manages a block of addresses for each ODAP client application. The ODAP clients will request subnets from the ODAP Subnet Allocation Server. These pools of subnetted IP addresses can dynamically increase or decrease in size depending on the utilization of the IP addresses. A pool can be divided into subnets of various sizes and the server assigns these subnets to routers running ODAP clients upon request. The PDSN will run the ODAP client and use OSPF to aggregate the routes. The DHCP/ODAP Server can either be an external Cisco AR, or run on a Cisco IOS image.
Note
To use the ODAP feature, you must have Cisco IOS Release 12.2(15)T or later.
In this case, either the PDSN Cluster controller, or the backup cluster controller on one of the MWAM cards, will be configured as the DHCP/ODAP Server. The local IP pools used for PDSN Home Agent applications can also use the DHCP/ODAP Server for a subnet pool. A different name for the mobile IP pools would be used in the configurations.
Pool Sizing Information
The PDSN configuration dictates that either the PDSN Cluster Controller or the PDSN Backup Cluster Controller on one of the MWAM cards is configured as the DHCP Server with the ODAP Subnet Allocation Server. These processors will have more capacity because they provide PDSN Clustering functionality, and do not process the actual PDSN sessions. The ODAP clients reside on each of the PDSN images.
You must decide how large to make the ODAP subnet pools based on the following variables:
•
Number of MWAMs and number of PDSNs per MWAM
•
How many total PDSN sessions will be required
•
Incoming call rates
•
Number of available IP addresses for the ODAP pool.
Use the following information to size the ODAP Subnet Allocation Server pool and to determine how many IP addresses are required for all the PDSN applications.
•
Each PDSN IOS application can support up to 20,000 PDSN sessions.
•
Each MWAM contains:
–
Either a PDSN Cluster Controller or Backup Cluster Controller and up to 4 PDSN IOS images, so each MWAM can support up to 80,000 sessions (4 * 20000).
Note
If a Cluster Controller or Backup Cluster Controller is not configured, then 5 PDSN images can be used allowing up to 100,000 sessions (5 * 20000).
•
A Catalyst 6500 chassis contains up to 6 MWAM cards. The total number of local IP addresses needed in the pool for each chassis:
–
6 MWAMs * 80,000 sessions = 480,000 IP addresses in the PDSN ODAP pool.
In order to configure an ODAP subnet pool for Mobile IP Home Agent applications, determine the number IP addresses needed for each Home Agent. Use the following formula to determine the Mobile IP pool size:
•
Home Agent Subnet IP Pool size = (number of Home Agents x number of sessions)
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 onthe 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, PPP session is torn down. If the Echo-Request-Attempts counter is nonzero, an LCP Echo-Request message will be sent, Echo-Request-Attempts counter is decremented, and 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 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 session's feature works independent of always-on users. The aging of dormant PPP session's feature does not care for the always-on property of a session.
NPE-G1 Platform Support
PDSN Release 2.0 introduces support for the NPE-G1 router platform. The maximum number of sessions supported on the NPE G1 platform is 20,000. A faster processor will provide higher throughput rates compared the VXR NPE-400. The throughput is expected to be 2 times better than the VXR NPE-400 platform.
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.0 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 SessionRecord 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.
For information on redundancy and load balancing in the PDSN Release 2.0, see the "PDSN Clustering Peer-to-Peer and Controller / Member Architecture" section.
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 synched 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
To upgrade a member PDSN to Release 2.0, 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 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 introduced in the PDSN Release 2.0 Software:
config# cdma pdsn cluster member periodic-update 300
PDSN MIB Enhancement
In PDSN Release 2.0, 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, 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 7200 and 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.0 also 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
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.0 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. To accomplish this on the 7200 platform, Cisco supplies an SA-ISA card for hardware provided IPsec. 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.
Figure 7 illustrates the IS-835-B IPSec network topology.
Figure 7 IS-835-B IPSec Network
Hardware IPSec acceleration of 8000 IPSec tunnels per chassis is available through the use of the Cisco VPN Acceleration Module. Refer to the xxxxx for more information.
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
PDSN Release 2.0 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 Applicationcalled called numbercalling callingglbp interface groupinterface interfaceip IP addressmac-address MAC addressmatch-list apply the match-liststandby interface groupusername usernamevcid VC IDThe options calling, username, and ip are used by the CDMA/Mobile IP subsystems.
PDSN#debug condition username ?WORD Username for debug filteringPDSN#debu condition calling ?WORD Calling numberPDSN#debu condition ip ?A.B.C.D IP addressRefer to the Debug Commands section of this document for more information about conditional debugging in PDSN Release 2.0.
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.
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).
Features Available From Previous PDSN Releases
The following features were introduced in previous PDSN software releases, and are still supported in Release 2.0.
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.
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 both the Controller - Member cluster model, and for the Peer-to-Peer cluster model.
PDSN Clustering Peer-to-Peer and Controller / Member Architecture
The PDSN Clustering Peer-to-Peer Architecture (or PDSN Intelligent Selection and Load Balancing feature), functions in a peer-to-peer model. All the PDSNs in the cluster share their load and served MSID, and multicast their load and MSID to all other PDSNs in the cluster. This drains resources because large MSID tables need to be stored on all the PDSNs, and because a large amount of traffic is generated to exchange the information among the cluster members. This results in constraints on the cluster size.
Currently, you can choose between Peer-to-Peer clustering, or 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
It is not possible to configure Peer-to-Peer clustering for PDSN on the MWAM. This feature is only supported on the Cisco 7200 platform.
Note
The new PDSN Controller-Member clustering feature is only available on the -c6is-mz, and -c6ik9s-mz images.
Figure 8 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 8 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.
Intelligent PDSN Selection and Load Balancing (Peer-to-Peer)
The Cisco Intelligent PDSN Selection (Peer-to-Peer) feature allows you to group a number of Cisco PDSNs into clusters that can exchange session information for performance and load-balancing purposes. Each Cisco PDSN in a group maintains a table that contains information for the entire group. Using PDSN clusters, minimizes inter-PDSN handoff, provides intelligent load-balancing, and ensures high availability.
To distribute session information, each PDSN sends a broadcast to the Mobile IP multicast address when a session is created or ended. The IP address of the originating PDSN and the MSID are encoded in the Mobile IP messages. Each PDSN in a group updates its session table upon receiving the broadcast.
When a session request is received from the PCF by the Cisco PDSN, the PDSN checks its own session list for an existing session, and also checks session lists within its PDSN group. If it determines that a session exists with another PDSN, it redirects the PCF to that PDSN. This redirection helps to avoid dropping the IP address and, thereby, avoids dropping any existing communication.
If the session does not exist with any other PDSN, the receiving PDSN uses a load-balancing mechanism to determine the appropriate PDSN to use for session establishment. With load balancing, the receiving PDSN looks for the least utilized PDSN in the entire cluster. If the number of active PPP links on that PDSN is some factor less than the number of PPP links on the receiving PDSN, the request will be forwarded. The factor for determining whether the PPP link is forwarded is calculated as a percentage (number of active PPP links vs. total number of possible PPP links).
Load Balancing
For a new packet data session, one PDSN may direct a connection request to another less "loaded" PDSN within the cluster by proposing the address of that PDSN to the PCF. Such redirection of A10 connection requests is performed among lesser loaded PDSNs in a round-robin manner. In PDSN software releases prior to Release 1.1, the load balancing threshold was implemented in terms of a session count differential. Starting in Release 1.1, the threshold is configured in terms of a load factor—the ratio of number of sessions supported and total session capacity of the PDSN. In future releases, other factors (such as QoS, session throughput considerations, CPU load, memory utilization) might also be considered as parameters used to determine of load factor of a PDSN.
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 Clustering Peer-to-Peer and Controller / Member Architecture" section, 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.0 software, refer to the following documents:
•
Release Notes for the Cisco PDSN 2.0 Feature in Cisco IOS Release 12.3(8)XW
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 for MWAM release is a feature enhancement for the Cisco 7206 router and the Multi-Processor WAN Application Module (MWAM) card that resides on the Cisco Catalyst 6500 switch or Cisco 7600 Internet Router. Refer to the following document for more information regarding the respective platforms:
•
Release Notes for the Cisco PDSN 2.0 Feature in Cisco IOS Release 12.3(8)XW 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 both the 7200 and MWAM platforms. 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.
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. Configuring the R-P interface is required in all 7200 platform configuration scenarios.
To configure the R-P interface, complete the following tasks:
•
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
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 (Available only on C-6 images)
•
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 IS835-B IPSec for the Cisco PDSN
•
Configuring Mobile IP Security Associations
PDSN Selection Configuration Tasks (Optional)
To configure PDSN selection, complete the following tasks:
•
Configuring PDSN Cluster Controller
•
Configuring PDSN Cluster Member
•
Configuring Peer-to-Peer PDSN Selection
Network Management Configuration Tasks (Required for Network Management in Any Scenario)
To configure network management, complete the following task:
Other Configuration Tasks
The following tasks are optional on the PDSN:
•
Configuring Always On Service
•
Configuring On Demand Address Pools
•
Configuring Mobile IP Resource Revocation on the PDSN
Tuning, Verification, and Monitoring Tasks (Optional)
To tune, verify, and monitor PDSN elements, complete the following tasks:
•
Configuring PDSN Accounting Events
•
Monitoring and Maintaining the PDSN
Enabling PDSN Services
To enable PDSN services, use the following commands in global configuration mode:
Creating the CDMA Ix Interface
To create the CDMA Ix interface, use the following commands in global configuration mode:
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:
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:
Enabling R-P Interface Signaling
To enable the R-P interface signaling, use the following commands in global configuration mode:
Configuring User Session Parameters
To configure user session parameters, use the following commands in global configuration mode:
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:
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:
Configuring Prepaid in the PDSN Environment
For the Cisco-specific prepaid solution, there are no configuration commands for prepaid. To configure prepaid, ensure that you include crb-entity-type=1 in the user profile.
Enabling VPDN in a PDSN Environment
To configure VPDN in the PDSN environment, use the following commands in global configuration mode:
Command PurposeRouter(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.2 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:
To reduce the virtual-access cloning time in order to increase the CPS rate on a standalone PDSN on a Cisco 7200 router, use the following per interface configurations in global configuration mode:
The CPS on a standalone PDSN on a Cisco 7200 should improve to 100 CPS from the current number of 40.
Configuring IS835-B IPSec for the Cisco PDSN
To configure IS835-B IPSec for the PDSN, use the following commands in global configuration mode:
Here is an example configuration for the IS835-B based IPSecfeature:
Router(config)#crypto isakmp policy 1authentication pre-shareRouter(config)#crypto isakmp key cisco address 7.0.0.2Router(config)#crypto ipsec transform-set mobile-set1 esp-3desRouter(config)#crypto ipsec profile testprofset transform-set mobile-set1Router(config)#crypto identity pdsntestRouter(config)#ip mobile cdma ipsecRouter(config)# ip mobile cdma ipsec profile testprofRouter(config)#ip mobile foreign-agent reg-wait 30Configuring 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:
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:
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.
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.
Configuring Peer-to-Peer PDSN Selection
A group of Cisco PDSNs can be configured to exchange session information with one another when needed. When a session request is received by the PDSN, it not only checks its own session list for the existence of a session, it also checks the lists of the PDSNs within its group. If a session exists in the group, the Mobile IP registration message for the session is rejected, and an alternate PDSN is recommended. The BSC/PCF can then establish session with the recommended PDSN.
To configure PDSN selection and PDSN load balancing, use the following commands in global configuration mode:
Command PurposeRouter(config)# cdma pdsn selection interface interface_name
Configures the interface be used to send and receive PDSN selection messages.
Router(config)# cdma pdsn selection session-table-size size
Enables the PDSN selection feature and defines the size of the session table.1
Router(config)# cdma pdsn selection load-balancing [threshold val [alternate]]
Enables the load balancing function of PDSN selection. The Alternate option alternately suggests two other PDSNs with the least load.
Router(config)# cdma pdsn selection keepalive value
Specifies the length of time to track a PDSN that is not responding.
Router(config)# cdma pdsn secure cluster default spi
{spi_val | [inbound inspi_val outbound outspi_val]} key {ascii|hex} string
Specifies the default mobility security associations for all PDSNs in a cluster, as well as inbound and outbound spi values.
1 You must issue the cdma pdsn selection session-table-size command before you issue the cdma pdsn selection load-balancing command.
Enabling Network Management
To enable SNMP network management for the PDSN, use the following commands in global configuration mode:
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:
Configuring On Demand Address Pools
To configure the DHCP Server with the ODAP Subnet Allocation Server, perform the following configuration tasks. This configuration can be either on a PDSN Cluster Controller or a Backup Cluster Controller.
The IOS DHCP Server feature is enabled by default in IOS. If it becomes disabled, use the global service dhcp command to re-enable the feature.
For the ip dhcp pool pdsn-pool command, the subnet is 13.0.0.0 and the mask defines the size of the pool. The subnet prefix-length defines the size of the subnet chunks using standard CIDR bit count notation to determine the number of addresses that are configured in each subnet lease. Here is a sample of the show dhcp ip pool command output:
Pool pdsn-pool :Utilization mark (high/low) : 100 / 0Subnet size (first/next) : 0 / 0Total addresses : 524288Leased addresses : 4096Pending event : none1 subnet is currently in the pool :Current index IP address range Leased addresses13.0.48.0 13.0.0.0 - 13.7.255.255 4096In this example, one subnet of 4096 addresses has been leased out. It is leased to PDSN1 in this example.
In the following example, a second PDSN pool is shown for reference, pdsn-pool-2. This shows different values used for the pool size and the subnet chunks. Nothing is presently leased.
Pool pdsn-pool-2 :Utilization mark (high/low) : 100 / 0Subnet size (first/next) : 0 / 0Total addresses : 65536Leased addresses : 0Pending event : none1 subnet is currently in the pool :Current index IP address range Leased addresses14.0.0.0 14.0.0.0 - 14.0.255.255 0OSPF is configured to log adjacency changes for network 10.10.1.0, which is the GigEthernet0/0.101 interface.
Currently, the ODAP Subnet Allocation Server only allows one network command under the ip dhcp pool name-of-pool command. To support disjointed subnets, you must define a pool that is large enough to contain all assigned IP addresses. You cn use the following global configuration command:
ip dhcp excluded-address low-address [high-address]
This command informs the ODAP Subnet Allocation Server to not lease these addresses to the ODAP client. Issuing this command help some configurations with disjointed IP address space, but may not work in other cases, depending on the range of IP addresses.
Configure the following ODAP client and OSPF commands on the PDSN:
Additionally, perform the following configuration details on the PDSN:
interface Loopback1ip address 10.11.2.92 255.255.255.255interface CDMA-Ix1ip address 10.11.1.92 255.255.255.255interface GigabitEthernet0/0.1encapsulation dot1Q 20ip address 10.0.1.1 255.255.0.0interface GigabitEthernet0/0.301encapsulation dot1Q 301ip address 7.0.0.92 255.255.255.0interface Virtual-Template1ip unnumbered Loopback1peer default ip address dhcp-pool pdsn-pool <<< name of ODAP pool to useno keepaliveppp accm 0ppp authentication chap pap optionalppp accounting nonerouter ospf 100log-adjacency-changesredistribute connected subnets route-map MAP <<< advertises CDMA-Ix interfaceredistribute static subnets <<< advertises the ODAP subnetspassive-interface Virtual-Template1 <<< no OSPF updates out herenetwork 10.10.1.0 0.0.0.255 area 0access-list 11 permit 10.11.1.92access-list 12 deny 128.0.0.0 0.0.0.255access-list 12 permit anyroute-map MAP permit 10 <<< only the CDMA-Ix update gets outmatch ip address 11set tag 9route-map DENY-MAP permit 10 <<< blocks 128.x.x.x internal network betweenmatch ip address 12 the PC and sibytes on the MWAM cardset tag 9or
summary-address 128.0.0.0 255.0.0.0 not-advertise <<< also blocks the 128 networkThe ip dhcp ping packets 0 command will disable the ODAP client from sending a ping to determine if an address is available. The ODAP default time is 2 seconds to wait for an ICMP echo reply. This will reduce the address allocation time at the risk of detecting duplicate addresses. The ip address-pool dhcp-pool command enables the ODAP client on the PDSN. The pool for the PDSN to use is called pdsn-pool. The origin command tells that it is DHCP, and gives an initial size for the pool to use and a size to grow by. In this case, both the initial and autogrow are set for a subnet size of 4096. The utilization mark (high/low) command can be used to set a percentage of pool usage before the router will schedule a subnet request for a new subnet, or to free a subnet that is no longer being used. The name of the pool must also be configured on the Virtual-Template1 interface. Here is the output of the show command.
PDSN#show ip dhcp poolPool pdsn-pool :Utilization mark (high/low) : 95 / 5Subnet size (first/next) : 20 / 20 (autogrow)Total addresses : 4094Leased addresses : 0Pending event : none1 subnet is currently in the pool :Current index IP address range Leased addresses13.0.64.1 13.0.64.1 - 13.0.79.254 0The ip dhcp-server 7.0.0.96 command causes DHCP requests to go to this particular DHCP Server. Otherwise Broadcast messages are sent to discover the DHCP Servers.
For OSPF, the redistribute static subnets command is used to aggregate the ODAP subnet routes on the SUP. The redistribute connected subnets route-map MAP command uses an access-list functionality to only allow the CDMA-Ix1 IP address to be known to the SUP. All other "connected subnets" routing updates are not sent out.
Alternatively, the summary-address 128.0.0.0 255.0.0.0 not-advertise command can be used instead of the route-map DENY-MAP permit 10 command to prevent the 128.0.0.0 route from being seen. The route-map is similar to an access-list, so the summary-address command may be preferable and have less impact on processor performance.
There are additional configuration details for the Catalyst 6500 Series Switch, as well as additional commands that will assist you in configuring ODAP on the PDSN. For more information, refer to the following Cisco 12.2 IOS documentation:
•
12.2 IOS Documentation, DHCP Server - On-Demand Address Pool Manager
•
12.2 IOS Documentation, Configuring DHCP (IOS IP configuration guide)
•
12.2 IOS Documentation, DHCP ODAP Server Support
Configuring PoD on the PDSN
To enable Packet of Disconnect on the PDSN, perform the following task:
Configuring Mobile IP Resource Revocation on the PDSN
To enable resource revocation support on PDSN, perform the following task:
Configuring PDSN Accounting Events
To configure attributes of PDSN accounting events, use the following commands in global configuration mode:
Monitoring and Maintaining the PDSN
To monitor and maintain the PDSN, use the following commands in privileged EXEC mode:
Configuration Examples
This section provides the following 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
Cisco PDSN Configuration for Simple IP
Figure 9 and the information that follows is an example of PDSN architecture for Simple IP and its accompanying configuration.
Figure 9 PDSN for Simple IP—A Network Map
service cdma pdsn!hostname PDSN1-7206!aaa new-modelaaa authentication ppp default group radiusaaa authorization config-commandsaaa authorization network default group radiusaaa authorization configuration default group radiusaaa accounting update periodic 60aaa accounting network pdsn start-stop group radius!no ip gratuitous-arps!interface Loopback0ip address 8.8.8.254 255.255.255.255!interface CDMA-Ix1ip address 6.6.6.6 255.0.0.0!interface FastEthernet0/0! Interface for communication with RADIUS server and NMSip address 33.33.33.33 255.255.255.0!!!interface FastEthernet1/0! Interface to PCF - R-Pip address 2.2.2.2 255.255.255.0half-duplexno cdp enable!interface FastEthernet2/0! Interface to external network - Piip address 23.23.23.23 255.255.0.0!!!interface Virtual-Template1ip unnumbered Loopback0peer default ip address pool pdsn-poolppp accm 0ppp authentication chap pap optionalppp accounting noneppp timeout idle 2000!ip local pool pdsn-pool 8.8.8.1 8.8.8.253ip classles!!radius-server host 33.33.33.34 auth-port 1645 acct-port 1646 key ciscoradius-server retransmit 3radius-server vsa send authentication 3gpp2radius-server vsa send accounting 3gpp2cdma pdsn virtual-template 1cdma pdsn maximum sessions 16000cdma pdsn a10 max-lifetime 36000cdma pdsn msid-authenticationcdma pdsn secure pcf 2.2.2.5 spi 100 key ascii cisco!!!endCisco PDSN Configuration for Simple IP with VPDN
The configuration Simple IP with VPDN is identical to the configuration for Simple IP with two additional lines:
vpdn enablevpdn authen-before-forwardCisco PDSN Configuration for Mobile IP
Figure 10 and the information that follows is an example of PDSN architecture for Mobile IP service and its accompanying configuration. The example shows the configuration of PDSN1.
Figure 10 PDSN for Mobile IP—A Network Map
service cdma pdsn!hostname PDSN1-7206!aaa new-modelaaa authentication login default group radiusaaa authentication login CONSOLE noneaaa authentication ppp default group radiusaaa authorization config-commandsaaa authorization network default group radius!interface Loopback0ip address 11.11.11.1 255.255.255.255!interface CDMA-Ix1ip address 5.5.5.5 255.0.0.0!interface FastEthernet0/0description AAA NMS interfaceip address 12.12.12.100 255.0.0.0!interface FastEthernet1/0description R-P interfaceip address 2.2.2.2 255.255.255.0full-duplex!!interface FastEthernet2/0description Pi interfaceip address 3.3.3.2 255.255.255.0full-duplex!interface Virtual-Template1ip unnumbered loopback0no ip route-cacheno keepaliveppp authentication chap pap optionalppp timeout idle 2000!router mobile!ip classlessno ip http serverip mobile foreign-agent care-of FastEthernet2/0ip mobile foreign-service challenge forward-mfce timeout 10 window 10ip mobile foreign-service reverse-tunnelradius-server host 12.12.22.12 auth-port 1645 acct-port 1646 key ascii cisco!radius-server host 12.12.22.12 auth-port 1645 acct-port 1646 key ascii ciscoradius-server retransmit 3radius-server vsa send authentication 3gpp2radius-server vsa send accounting 3gpp2cdma pdsn secure pcf 2.2.2.1 spi 100 key ascii ciscocdma pdsn virtual-template 1cdma pdsn msid-authentication!!endCombined Configuration for Cisco PDSN
The following example illustrates a PDSN configured for all scenarios: Simple IP, Simple IP with VPDN, Mobile IP, Proxy Mobile IP, and peer-to-peer PDSN selection.
service cdma pdsn!hostname PDSN1!aaa new-modelaaa authentication ppp default group radiusaaa authorization config-commandsaaa authorization network default group radiusaaa authorization configuration default group radiusaaa accounting update periodic 60aaa accounting network pdsn start-stop group radius!vpdn enablevpdn authen-before-forwardvirtual-profile aaausername HA password 0 rosebudusername LNS password 0 ciscousername PDSN password 0 ciscono ip gratuitous-arps!interface Loopback0ip address 8.8.8.254 255.255.255.255!interface CDMA-Ix1ip address 6.6.6.6 255.0.0.0!interface FastEthernet0/0! Interface for communication with RADIUS server and NMSip address 33.33.33.33 255.255.255.0!!!interface FastEthernet1/0! Interface to PCF - R-Pip address 2.2.2.2 255.255.255.0!interface FastEthernet2/0! Interface to external network - Piip address 23.23.23.23 255.255.0.0!!!interface Virtual-Template1ip unnumbered Loopback0no keepalivepeer default ip address pool pdsn-poolppp accm 0ppp authentication chap pap optionalppp accounting noneppp timeout idle 2000!router mobile!ip local pool pdsn-pool 8.8.8.1 8.8.8.253ip classlessip mobile foreign-agent care-of FastEthernet2/0ip mobile foreign-service challenge forward-mfce timeout 10 window 10ip mobile foreign-service reverse-tunnelradius-server host 12.12.22.12 auth-port 1645 acct-port 1646 key ascii cisco!!radius-server host 33.33.33.34 auth-port 1645 acct-port 1646 key ciscoradius-server retransmit 3radius-server vsa send authentication 3gpp2radius-server vsa send accounting 3gpp2cdma pdsn virtual-template 1cdma pdsn maximum sessions 16000cdma pdsn a10 max-lifetime 36000cdma pdsn msid-authenticationcdma pdsn secure pcf 2.2.2.5 spi 100 key ascii ciscocdma pdsn secure cluster default spi 100 key ascii ciscocdma pdsn selection interface FastEthernet0/0!!!endPDSN Cluster Configuration
The following configuration illustrates 3 MWAMs in a 6500 configuration:
Verify hardware configuration on Cat6K:cat6500 router#sh moduleMod Ports Card Type----------------------------------------------1 2 Catalyst 6000 supervisor 2 (Active)3 48 SFM-capable 48-port 10/100 Mbps RJ454 2 IPSec VPN Accelerator5 16 SFM-capable 16 port 1000mb GBIC7 3 MWAM Module8 3 MWAM Module (MP)9 3 MWAM ModuleMod MAC addresses Hw Fw Sw Status--- ---------------------------------- ------ ------------ ------------ -------1 0005.7485.8494 to 0005.7485.8495 3.5 6.1(3) 6.2(2.108) Ok3 0001.63d7.2352 to 0001.63d7.2381 4.2 6.3(1) 6.2(2.108) Ok4 0008.7ca8.1386 to 0008.7ca8.1389 0.200 7.2(1) 6.2(2.108) Ok5 0001.63d6.cd92 to 0001.63d6.cda1 4.1 6.3(1) 6.2(2.108) Ok7 0001.0002.0003 to 0001.0002.000a 0.203 7.2(1) 1.0(0.1) Ok8 00e0.b0ff.3a10 to 00e0.b0ff.3a17 0.201 7.2(1) 1.2(0.12) ShutDown9 0002.0002.0003 to 0002.0002.000a 0.203 7.2(1) 1.0(0.1) OkMod Sub-Module Hw Status--- --------------------------- ------- -------1 Policy Feature Card 2 3.2 Ok1 Cat6k MSFC 2 daughterboard 2.2 Okcat6500 router#Controller configuration:cat6500 router#session slot 7 processor 6The default escape character is Ctrl-^, then x.You can also type 'exit' at the remote prompt to end the sessionTrying 127.0.0.76 ... OpenPress RETURN to get started!S76>S76>S76>S76>enS76#sh runS76#sh running-configBuilding configuration...Current configuration : 1489 bytes!! No configuration change since last restart!version 12.2service timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice cdma pdsn!hostname S76!!ip subnet-zeroip cef!!!interface Loopback1no ip address!interface GigabitEthernet0/0no ip address!interface GigabitEthernet0/0.401encapsulation dot1Q 401ip address 10.121.68.76 255.255.255.0standby 1 ip 10.121.68.98standby 1 priority 120standby 1 preemptstandby 1 name 6509-cluster!router mobile!ip classlessip route 10.10.72.1 255.255.255.255 10.121.68.72ip route 10.10.73.1 255.255.255.255 10.121.68.73ip route 10.10.74.1 255.255.255.255 10.121.68.74ip route 10.10.75.1 255.255.255.255 10.121.68.75ip route 10.10.92.1 255.255.255.255 10.121.68.92ip route 10.10.93.1 255.255.255.255 10.121.68.93ip route 10.10.94.1 255.255.255.255 10.121.68.94ip route 10.10.95.1 255.255.255.255 10.121.68.95ip route 128.0.0.0 255.255.255.0 GigabitEthernet0/1no ip http serverip pim bidir-enable!!!cdma pdsn secure pcf 10.121.68.62 10.121.68.66 spi 100 key ascii ciscocdma pdsn secure pcf 10.121.68.82 10.121.68.86 spi 100 key ascii ciscocdma pdsn secure cluster default spi 100 key ascii usercdma pdsn cluster controller interface GigabitEthernet0/0.401cdma pdsn cluster controller standby 6509-clustercdma pdsn cluster controller timeout 10cdma pdsn cluster controller window 3!line con 0line vty 0no loginline vty 1 4loginline vty 5 15login!endS76#cat6500 router#session slot 9 processor 6The default escape character is Ctrl-^, then x.You can also type 'exit' at the remote prompt to end the sessionTrying 127.0.0.96 ... OpenS96>Press RETURN to get started!S96>S96>S96>S96>enS96#sh runS96#sh running-configBuilding configuration...Current configuration : 1182 bytes!! No configuration change since last restart!version 12.2service timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice cdma pdsn!hostname S96!!ip subnet-zeroip cef!!!!interface Loopback1no ip address!interface CDMA-Ix1no ip address!interface GigabitEthernet0/0no ip address!interface GigabitEthernet0/0.401encapsulation dot1Q 401ip address 10.121.68.96 255.255.255.0standby 1 ip 10.121.68.98standby 1 priority 120standby 1 preemptstandby 1 name 6509-cluster!router mobile!ip classlessip route 10.10.72.1 255.255.255.255 10.121.68.72ip route 128.0.0.0 255.255.255.0 GigabitEthernet0/2no ip http serverip pim bidir-enable!!!cdma pdsn secure pcf 10.121.68.62 10.121.68.66 spi 100 key ascii ciscocdma pdsn secure pcf 10.121.68.82 10.121.68.86 spi 100 key ascii ciscocdma pdsn secure cluster default spi 100 key ascii usercdma pdsn cluster controller interface GigabitEthernet0/0.401cdma pdsn cluster controller standby 6509-clustercdma pdsn cluster controller timeout 10cdma pdsn cluster controller window 3!line con 0line vty 0no loginline vty 1 4loginline vty 5 15login!endS96#Verify active controller and standby controllerS76#sh standbyGigabitEthernet0/0.401 - Group 1State is Active2 state changes, last state change 00:27:09Virtual IP address is 10.121.68.98Active virtual MAC address is 0000.0c07.ac01Local virtual MAC address is 0000.0c07.ac01 (default)Hello time 3 sec, hold time 10 secNext hello sent in 2.112 secsPreemption enabled, min delay 0 sec, sync delay 0 secActive router is localStandby router is 10.121.68.96, priority 120 (expires in 9.064 sec)Priority 120 (configured 120)IP redundancy name is "6509-cluster"S76#S96#sh standbyGigabitEthernet0/0.401 - Group 1State is Standby1 state change, last state change 00:26:57Virtual IP address is 10.121.68.98Active virtual MAC address is 0000.0c07.ac01Local virtual MAC address is 0000.0c07.ac01 (default)Hello time 3 sec, hold time 10 secNext hello sent in 2.532 secsPreemption enabled, min delay 0 sec, sync delay 0 secActive router is 10.121.68.76, priority 120 (expires in 9.580 sec)Standby router is localPriority 120 (configured 120)IP redundancy name is "6509-cluster"S96#Members configuration:cat6500 router#session slot 7 processor 3The default escape character is Ctrl-^, then x.You can also type 'exit' at the remote prompt to end the sessionTrying 127.0.0.73 ... OpenS73>Press RETURN to get started!S73>S73>enS73#sh runS73#sh running-configBuilding configuration...Current configuration : 3192 bytes! Last configuration change at 04:10:06 UTC Sun Sep 15 2002!version 12.2service timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice cdma pdsn!hostname S73!aaa new-model!!aaa group server radius CSCO-30server 10.1.1.244 auth-port 1645 acct-port 1646server 10.1.1.200 auth-port 2812 acct-port 2813!aaa authentication ppp default local group radiusaaa authorization network default local group radiusaaa accounting network pdsn start-stop group radiusaaa session-id common!username root nopasswordusername cisco password 0 ciscousername pdsn password 0 ciscoip subnet-zeroip gratuitous-arpsip cef!!!interface Loopback1ip address 10.10.173.1 255.255.255.0!interface CDMA-Ix1ip address 10.10.73.1 255.255.255.0tunnel source 10.10.73.1tunnel key 16404tunnel sequence-datagrams!interface GigabitEthernet0/0no ip address!interface GigabitEthernet0/0.310encapsulation dot1Q 310ip address 10.1.1.73 255.255.255.0!interface GigabitEthernet0/0.401encapsulation dot1Q 401ip address 10.121.68.73 255.255.255.0!interface Virtual-Template1ip unnumbered Loopback1no keepalivepeer default ip address pool pdsn-poolppp accm 0ppp authentication chap pap optionalppp ipcp address uniquecdma pdsn mobile-advertisement-burst interval 500 number 3!router mobile!router ospf 100log-adjacency-changessummary-address 7.3.0.0 255.255.0.0redistribute connected subnets route-map MAP-DENYnetwork 10.10.73.1 0.0.0.0 area 73network 10.10.73.0 0.0.0.255 area 73network 10.10.173.1 0.0.0.0 area 0network 10.121.68.0 0.0.0.255 area 0!ip local pool pdsn-pool 7.3.1.0 7.3.16.255ip local pool pdsn-pool 7.3.17.0 7.3.32.255ip local pool pdsn-pool 7.3.33.0 7.3.48.255ip local pool pdsn-pool 7.3.49.0 7.3.64.255ip local pool pdsn-pool 7.3.65.0 7.3.78.255ip local pool pdsn-pool 7.3.79.0 7.3.79.31ip mobile foreign-agent care-of GigabitEthernet0/0.310ip classlessip route 128.0.0.0 255.255.255.0 GigabitEthernet0/1no ip http serverip pim bidir-enableip mobile foreign-service challenge forward-mfceip mobile foreign-service reverse-tunnelcdma pdsn mobile-advertisement-burst interval 500 number 3!!access-list 9 deny 128.0.0.0 0.0.255.255access-list 9 permit any!route-map MAP-DENY permit 10match ip address 9set tag 9!radius-server host 10.1.1.244 auth-port 1645 acct-port 1646 key fooradius-server host 10.1.1.200 auth-port 2812 acct-port 2813 key fooradius-server retransmit 3radius-server deadtime 1radius-server vsa send accounting 3gpp2radius-server vsa send authentication 3gpp2cdma pdsn accounting local-timezonecdma pdsn virtual-template 1cdma pdsn send-agent-advcdma pdsn secure pcf 10.121.68.62 10.121.68.66 spi 100 key ascii ciscocdma pdsn secure pcf 10.121.68.82 10.121.68.86 spi 100 key ascii ciscocdma pdsn secure cluster default spi 100 key ascii usercdma pdsn cluster member controller 10.121.68.98cdma pdsn cluster member interface GigabitEthernet0/0.401cdma pdsn cluster member timeout 10cdma pdsn cluster member window 2!line con 0line vty 5 15!endShow commands on ControllersPDSN-CONTROLLER#show cdma pdsn cluster controller configurationcluster interface GigabitEthernet0/0.1no R-P signaling proxytimeout to seek member = 10 secondswindow to seek member is 2 timeouts in a row if no reply (afterwards the member is declared offline)default: spi 100, Timestamp +/- 0, key ascii clusteringthis PDSN cluster controller is configuredcontroller redundancy:database in-sync or no need to syncgroup: clusterController maximum number of load units = 1000PDSN-CONTROLLER#show cdma pdsn cluster controller member loadSecs until Seq seeks Member(past) seek no reply IPv4 Addr State Load Sessions-------------------------------------------------------------------6 0 20.6.84.1 ready 0 05 0 20.6.62.1 ready 0 01 0 20.6.64.1 ready 0 0-------------------------------------------------------------------Controller IPv4 Addr 20.3.68.60PDSN-CONTROLLER#show cdma pdsn cluster controller member 20.6.84.1PDSN cluster member 20.6.84.1 state readyregistered with PDSN controller 20.3.68.60reported load 0 percent, will be sought in 7 secondsMember 20.6.84.1 statistics:Controller seek rcvd 1, Member seek reply rcvd 554Member state changed 0 time to readyMember state changed 0 time to Admin prohibitedSession-Up message rcvd 0, Session-Down message received 0Member seek not replied in sequence 0PDSN-CONTROLLER#show cdma pdsn cluster controller statisticsController-Member Interface:Cluster Reg Request rcvd 858, accepted 852, discarded 6Cluster Reg Request sent 1425Cluster Reg Reply rcvd 1427, accepted 1424, discarded 3Cluster Reg message errors:Reg Request rcvd: Authentication failed 0, ID mismatch 6Unrecognized extension 0, Unrecognized application type 0Unrecognized data type 0Reg Reply rcvd: Authentication failed 0, ID mismatch 3Unrecognized extension 0Reg Req not sent: Interface cdma-Ix not configured 0Invalid Reg message type 0Controller seek requests rcvd 852, replies sent 852Member seek requests sent 1425, replies rcvd 1424Member state transition msgs rcvd 0, replies sent 0ready 0, Administratively prohibited 0Total A11 Reg Requests forwarded 0A11 Reg Requests orig forwarded 0, retry forwarded 0Session-Up from member 0, Session-Down from member 0No Acknowledgement from member 0Controller Redundancy Interface:Update rcvd 0 sent 2330 orig sent 2276 fail 18UpdateAck rcvd 2330 sent 0DownloadReq rcvd 0 sent 20 orig sent 19 fail 0DownloadReply rcvd 20 sent 0 orig sent 0 fail 0 drop 0DownloadAck rcvd 0 sent 20 drop 0Errors: Authentication failed 0 ID mismatch 0Ignored due to no redundancy configuration 0S76#sh cdma pdsn cluster controller session ?count Count of session recordsimsi Session record for International Mobile Subscriber Identityoldest Oldest session recordS76#sh cdma pdsn cluster controller session olS76#sh cdma pdsn cluster controller session oldest ?more The oldest and a few more session records to show| Output modifiers<cr>S76#sh cdma pdsn cluster controller session oldestIMSI Member IPv4 Addr Age [days] Anchor changes----------------------------------------------------------------62000015434 10.10.73.1----------------------------------------------------------------S76#sh cdma pdsn cluster controller session imsi 62000015434IMSI Member IPv4 Addr Age [days] Anchor changes----------------------------------------------------------------62000015434 10.10.73.1----------------------------------------------------------------S76#Show commands on member:PDSN-MEMBER#show cdma pdsn cluster member configurationcluster interface GigabitEthernet0/0.1IP address of controller is 20.3.68.60no prohibit administrativelytimeout to resend status or seek controller = 250 sec or less, randomizedresend a msg for 6 timeouts sequentially if no reply, then inform operatordefault: spi 100, Timestamp +/- 0, key ascii clusteringthis PDSN cluster member is configuredPDSN-MEMBER#show cdma pdsn cluster member statisticsController-Member Interface:Cluster Reg Request rcvd 593, accepted 593, discarded 0Cluster Reg Request sent 3Cluster Reg Reply rcvd 1, accepted 1, discarded 0Cluster Reg message errors:Reg Request rcvd: Authentication failed 0, ID mismatch 0Unrecognized extension 0, Unrecognized application type 0Unrecognized data type 0Reg Reply rcvd: Authentication failed 0, ID mismatch 0Unrecognized extension 0Reg Req not sent: Interface cdma-Ix not configured 0Invalid Reg message type 0Controller seek requests rcvd 593, replies sent 593Member seek requests sent 3, replies rcvd 1Member state transition msgs sent 0, replies rcvd 0ready 0, Administratively prohibited 0Session-Up msg sent 0, Session-Down msg sent 0Session-Up msg Ack rcvd 0, Session-Down msg Ack rcvd 0Controller seek not replied in sequence 0Member state not replied in sequence 0Cat6k SUP configurationcat6500 router#sh running-configBuilding configuration...Current configuration : 9838 bytes!! Last configuration change at 00:21:56 UTC Sat Sep 14 2002 by root! NVRAM config last updated at 14:10:00 UTC Fri Sep 13 2002 by root!version 12.2service timestamps debug uptimeservice timestamps log datetime localtimeno service password-encryption!hostname cat6500 router!boot system slot0:c6sp222-jk9sv-mzboot device module 4 cf:3boot device module 5 cf:4boot device module 6 cf:4boot device module 7 cf:4boot device module 8 cf:4boot device module 9 cf:4aaa new-modelaaa authentication login default localaaa authorization exec default localenable secret level 1 5 $1$T17C$7icHsiM4vHj6nIE6medGj.enable secret level 6 5 $1$wB/9$.ML91zZopFpYp12VNxA1p.enable password lab!username u0 privilege 0 password 0 ciscousername root nopasswordusername u1 password 0 ciscousername u6 privilege 6 password 0 ciscousername u8 privilege 8 password 0 ciscousername cisco password 0 ciscousername u2 privilege 2 nopasswordusername u15 privilege 15 nopasswordusername u10 privilege 10 nopasswordusername v1 nopassword user-maxlinks 1!monitor session 1 source interface Fa3/24monitor session 1 destination interface Fa3/12redundancymain-cpuauto-sync standardip subnet-zero!!no ip domain-lookup!mls flow ip destinationmls flow ipx destination!!no spanning-tree vlan 310!!!interface Loopback1ip address 10.10.10.10 255.255.255.0!interface Port-channel1no ip addresssnmp trap link-statusswitchportswitchport access vlan 401!interface GigabitEthernet1/1no ip addresssnmp trap link-statusswitchportswitchport access vlan 309switchport mode access!interface GigabitEthernet1/2no ip addresssnmp trap link-statusswitchportswitchport access vlan 401switchport mode access!interface GigabitEthernet2/1no ip addresssnmp trap link-statusswitchportswitchport access vlan 310switchport mode access!interface GigabitEthernet2/2no ip addressshutdown!interface FastEthernet3/1no ip addresssnmp trap link-statusswitchportswitchport access vlan 222!interface FastEthernet3/2no ip addressshutdown!interface FastEthernet3/3no ip addressshutdown!interface FastEthernet3/4no ip addressshutdown!interface FastEthernet3/5no ip addresssnmp trap link-statusswitchportswitchport access vlan 66switchport mode access!interface FastEthernet3/6no ip addresssnmp trap link-statusswitchportswitchport access vlan 66switchport mode access!interface FastEthernet3/7no ip addresssnmp trap link-statusswitchportswitchport access vlan 66switchport mode access!interface FastEthernet3/8ip address 1.1.1.1 255.255.255.0shutdown!interface FastEthernet3/9no ip addressshutdown!interface FastEthernet3/10no ip addresssnmp trap link-statusswitchportswitchport access vlan 401channel-group 1 mode on!interface FastEthernet3/11no ip addresssnmp trap link-statusswitchportswitchport access vlan 401channel-group 1 mode on!interface FastEthernet3/12no ip addresssnmp trap link-statusswitchportswitchport access vlan 401!interface FastEthernet3/13no ip addresssnmp trap link-statusswitchportswitchport access vlan 401!interface FastEthernet3/14no ip addressshutdown!interface FastEthernet3/15ip address 3.3.3.3 255.255.255.0shutdown!interface FastEthernet3/16no ip addressshutdown!interface FastEthernet3/17no ip addresssnmp trap link-statusswitchportswitchport access vlan 311switchport mode access!interface FastEthernet3/18no ip addressshutdown!interface FastEthernet3/19no ip addressshutdown!interface FastEthernet3/20no ip addressshutdown!interface FastEthernet3/21no ip addresssnmp trap link-statusswitchportswitchport access vlan 401!interface FastEthernet3/22no ip addresssnmp trap link-statusswitchportswitchport access vlan 401!interface FastEthernet3/23no ip addresssnmp trap link-statusswitchportswitchport access vlan 401!interface FastEthernet3/24no ip addresssnmp trap link-statusswitchportswitchport access vlan 401!interface FastEthernet3/25no ip addresssnmp trap link-statusswitchportswitchport access vlan 401!interface FastEthernet3/26no ip addresssnmp trap link-statusswitchportswitchport access vlan 401!interface FastEthernet3/27no ip addressshutdown!interface FastEthernet3/28no ip addressshutdown!interface FastEthernet3/29no ip addressshutdown!interface FastEthernet3/30no ip addresssnmp trap link-statusswitchportswitchport access vlan 310!interface FastEthernet3/31no ip addresssnmp trap link-statusswitchportswitchport access vlan 310!interface FastEthernet3/32no ip addresssnmp trap link-statusswitchportswitchport access vlan 310!interface FastEthernet3/33no ip addresssnmp trap link-statusswitchportswitchport access vlan 310!interface FastEthernet3/34no ip addresssnmp trap link-statusswitchportswitchport access vlan 310!interface FastEthernet3/35no ip addresssnmp trap link-statusswitchportswitchport access vlan 310!interface FastEthernet3/36no ip addresssnmp trap link-statusswitchportswitchport access vlan 310!interface FastEthernet3/37no ip addresssnmp trap link-statusswitchportswitchport access vlan 310!interface FastEthernet3/38no ip addresssnmp trap link-statusswitchportswitchport access vlan 310!interface FastEthernet3/39no ip addresssnmp trap link-statusswitchportswitchport access vlan 310!interface FastEthernet3/40no ip addressshutdownsnmp trap link-statusswitchportswitchport access vlan 333!interface FastEthernet3/41no ip addresssnmp trap link-statusswitchportswitchport access vlan 310!interface FastEthernet3/42no ip addresssnmp trap link-statusswitchportswitchport access vlan 310!interface FastEthernet3/43no ip addresssnmp trap link-statusswitchportswitchport access vlan 310!interface FastEthernet3/44no ip addresssnmp trap link-statusswitchportswitchport access vlan 310!interface FastEthernet3/45no ip addresssnmp trap link-statusswitchportswitchport access vlan 310!interface FastEthernet3/46no ip addresssnmp trap link-statusswitchportswitchport access vlan 310!interface FastEthernet3/47no ip addresssnmp trap link-statusswitchportswitchport access vlan 333!interface FastEthernet3/48no ip addresssnmp trap link-statusswitchportswitchport access vlan 333!interface GigabitEthernet4/1no ip addresssnmp trap link-statusswitchportswitchport trunk encapsulation dot1qswitchport trunk allowed vlan 1,1002-1005switchport mode trunkflowcontrol receive oncdp enable!interface GigabitEthernet4/2no ip addresssnmp trap link-statusswitchportswitchport trunk encapsulation dot1qswitchport trunk allowed vlan 1,1002-1005switchport mode trunkflowcontrol receive oncdp enable!interface GigabitEthernet5/1no ip addressshutdown!interface GigabitEthernet5/2no ip addressshutdown!interface GigabitEthernet5/3no ip addressshutdown!interface GigabitEthernet5/4no ip addressshutdown!interface GigabitEthernet5/5no ip addressshutdown!interface GigabitEthernet5/6no ip addressshutdown!interface GigabitEthernet5/7no ip addressshutdown!interface GigabitEthernet5/8no ip addressshutdown!interface GigabitEthernet5/9no ip addressshutdown!interface GigabitEthernet5/10no ip addressshutdown!interface GigabitEthernet5/11no ip addressshutdown!interface GigabitEthernet5/12no ip addressshutdown!interface GigabitEthernet5/13no ip addressshutdown!interface GigabitEthernet5/14no ip addressshutdown!interface GigabitEthernet5/15no ip addressshutdown!interface GigabitEthernet5/16no ip addressshutdown!interface Vlan1no ip addressshutdown!interface Vlan222ip address 172.19.23.16 255.255.254.0ip nat outside!interface Vlan309no ip address!interface Vlan310ip address 10.1.1.222 255.255.255.0ip nat inside!interface Vlan401ip address 10.121.68.200 255.255.255.0!router ospf 100log-adjacency-changesnetwork 10.10.10.10 0.0.0.0 area 0network 10.121.68.0 0.0.0.255 area 0default-information originate!ip nat inside source list 100 interface Vlan222 overloadip classlessip route 0.0.0.0 0.0.0.0 172.19.26.1ip route 0.0.0.0 0.0.0.0 172.19.22.1ip route 5.5.5.0 255.255.255.0 10.1.1.92ip route 10.10.113.1 255.255.255.255 10.1.1.221ip route 10.10.116.1 255.255.255.255 10.1.1.221ip route 10.10.195.1 255.255.255.255 10.1.1.95no ip http serverip pim bidir-enable!!ip access-list extended VRZ-101permit ip host 10.10.195.1 host 10.10.116.1access-list 100 permit ip 5.0.0.0 0.255.255.255 anyarp 127.0.0.22 0000.2200.0000 ARPAarp 127.0.0.12 0000.2100.0000 ARPA!route-map MAP deny 10match ip address 100!snmp-server community public ROsnmp-server community private RWsnmp-server enable traps casasnmp-server enable traps vtpsnmp-server enable traps hsrpsnmp-server enable traps configsnmp-server enable traps entitysnmp-server enable traps bgpsnmp-server enable traps rsvpsnmp-server enable traps frame-relaysnmp-server enable traps syslogsnmp-server enable traps rtrsnmp-server enable traps dlswsnmp-server enable traps isdn call-informationsnmp-server enable traps isdn layer2snmp-server host 10.1.1.199 public!privilege configure level 8 snmp-server communityprivilege configure level 8 usernameprivilege configure level 8 username u10 privilege 10 nopasswordprivilege exec level 6 show runningprivilege exec level 8 config terminal!line con 0exec-timeout 0 0line vty 0 4exec-timeout 0 0password labtransport input lat pad mop telnet rlogin udptn nasiline vty 5 10exec-timeout 0 0!ntp master 3endPDSN Accounting
The following RADIUS attributes are contained in the UDR sent by PDSN.
The following list identifies the prepaid VSAs that can be included in the RADIUS attributes contained in the Accounting Stop Record:
•
crb-auth-reason
•
crb-duration
•
crb-total-volume
•
crb-uplink-volume
•
crb-downlink-volume
•
crb-total-packets
•
crb-uplink-packets
•
crb-downlink-packets
•
crb-session-id
AAA Authentication and Authorization Profile
This section describes User Profiles to be configured at the AAA server for authentication and authorization of users for various service types (Simple IP, Mobile IP, etc.). It also describes the minimal configuration required for the same.
1.
Client router should be authorized to access Cisco Access Registrar
The client profile contains the ip address of the router and the shared key. The following example illustrates a client profile:
[ //localhost/Radius/Clients/username ]Name = usernameDescription =IPAddress = 9.15.68.7SharedSecret = labType = NASVendor =IncomingScript~ =OutgoingScript~ =UseDNIS = FALSEDeviceName =DevicePassword =2.
A User should have a profile configured at AAA (this is applicable to an NAI as well, in case of MoIP).
A user profile contains username, password, and the base profile where attributes retrieved during authorization can be configured.
The following example illustrates a user profile:
[ //localhost/Radius/UserLists/Default/username ]Name = usernameDescription =Password = <encrypted>AllowNullPassword = FALSEEnabled = TRUEGroup~ =BaseProfile~ = username-sipAuthenticationScript~ =AuthorizationScript~ =UserDefined1 =3.
A Base Profile contains attributes applied for the user during authorization.
The following example illustrates a base profile :
[ //localhost/Radius/Profiles/username-sip ]Name = username-sipDescription =Attributes/4.
cd attributes
[ //localhost/Radius/Profiles/username-sip/Attributes ]cisco-avpair = lcp:cdma-user-class=1AAA Profiles for Various Service Types
The following examples document AAA profiles for various service types such as SIP, MoIP, and others. The mandatory/optional attributes, and the attributes required to be configured for enabling different features, are specified.
Simple IP
cisco-avpair = lcp:cdma-user-class=1
The following attributes are optional and are needed only for specific scenarios :
•
IP address assignment is done through AAA:
Framed-IP-Address = 8.1.0.2
•
Download pool name:
cisco-avpair = ip:addr-pool=pdsn-pool
•
Enable compression:
cisco-avpair = "lcp:interface-config=compress stac"
cisco-avpair = "lcp:interface-config=compress mppc"
cisco-avpair = "lcp:interface-config=compress predictor"
•
Other Optional Parameters
Framed-Protocol = PPP
Framed-Routing = None
Service-Type = Framed
VPDN
cisco-avpair = vpdn:tunnel-type=l2tp
cisco-avpair = vpdn:ip-addresses=5.5.5.1
cisco-avpair = vpdn:l2tp-tunnel-password=cisco
The following configuration is optional at AAA contacted by LNS :
cisco-avpair = ip:addr-pool=pdsn-pool
MSID based Authentication
•
(a) Simple IP case :
cisco-avpair = cdma:cdma-realm=cisco.com
cisco-avpair = lcp:cdma-user-class=1
•
(b) Proxy Mobile IP Case :
cisco-avpair = lcp:cdma-user-class=3
cisco-avpair = cdma:cdma-realm=cisco.com
cisco-avpair = "lcp:spi#0 = spi 100 key ascii cisco"
cisco-avpair = lcp:cdma-ha-ip-addr=5.5.5.1
Proxy Mobile IP
cisco-avpair = lcp:cdma-ha-ip-addr=5.5.5.1
cisco-avpair = "lcp:spi#0 = spi 100 key ascii cisco"
cisco-avpair = lcp:cdma-user-class=3
Mobile IP
•
cisco-avpair = lcp:cdma-user-class=2
The following attributes are optional, and are only needed for specific scenarios:
–
Dynamic Home Agent Assignment :
CDMA-HA-IP-Addr = 6.0.0.2
–
Download Security Association and static IP addresses (at Home Agent):
cisco-avpair = "mobileip:spi#0=spi 100 key ascii cisco"
cisco-avpair = "mobileip:static-ip-addresses=20.0.0.1 20.0.0.2 20.0.0.3 20.0.0.4"
–
Download Static ip pool name (at Home Agent):
cisco-avpair = "mobileip:spi#0=spi 100 key ascii cisco"
cisco-avpair = "mobileip:static-ip-pool=mypool"
Prepaid (Optional)
•
cisco-avpair = "crb-entity-type=1"
Attributes
This section lists several of the various Accounting and Authentication attributes for the Cisco PDSN.
Authentication and Authorization RADIUS Attributes
The PDSN, Home Agent, and the RADIUS server support RADIUS attributes listed in Table 5 and Table 6 for authentication and authorization services.
Accounting Services RADIUS Attributes
The PDSN and the RADIUS server support the RADIUS attributes listed in Table 7 for accounting services. The inclusion of the various attributes in each of the accounting messages is detailed in the table. The inclusion, or not, of attributes in a message is not configurable.
Table 7 Accounting AVPs For Packet Data Services
Name 3GPP2 Type AVP Type Vendor Length Format Description
Reference Specs Attribute Present Instart
stop
interim
User-Name
B2
1
NA
64
string
Network Access Identifier (NAI) of the mobile user.
RFC 2865
Yes
Yes
Yes
NAS-IP- Address
D2
4
NA
4
IP addr
PDSN/FA address
RFC 2865
Yes
Yes
Yes
NAS-Port
NA
5
NA
4
integer
Port number on the PDSN used for com- municating with the RADIUS server
RFC 2865
Yes
Yes
Yes
Service-Type
NA
6
NA
4
integer
Type of service the user is getting.
Supported values:
•
"Outbound" for MSID based user access
•
"Framed" for other type of user access
RFC 2865
Yes
Yes
Yes
Framed- Protocol
NA
7
NA
4
integer
Framing protocol user is using.
Supported values:
•
PPP
RFC 2865
Yes
Yes
Yes
Framed-IP- Address
B1
8
NA
4
IP addr
IP address assigned to the user.
RFC 2865
Yes
Yes
Yes
Calling- Station-Id
A1
31
NA
15
string
MSID identifier of the mobile user.
RFC 2865
Yes
Yes
Yes
Acct-Status- Type
NA
40
NA
4
integer
Accounting record type
Supported Values:
•
1 for Start
•
2 for Stop
•
3 for Interim-Update
•
7 for Accounting-On
•
8 for Accounting-Off
RFC 2866
Yes
Yes
Yes
Acct-Delay- Time
NA
41
NA
4
integer
Number of seconds PDSN has been trying to send this accounting record.
RFC 2866
Yes
Yes
Yes
Acct-Input- Octets
G2
42
NA
4
integer
Total number of octets in IP packets send by the mobile user (verify)
RFC 2866
Yes
Yes
Yes
Acct-Output- Octets
G1
43
NA
4
integer
Total number of octets in IP packets send to the mobile user (verify)
RFC 2866
Yes
Yes
Yes
Acct-Session- Id
C1
44
NA
4
string
A unique accounting ID created by the PDSN that allows stop and start records to be matched in a log file.
RFC 2866
Yes
Yes
Yes
Acct- Authentic
NA
45
NA
4
integer
Method of authenticating the user
Supported values:
•
1 for RADIUS
•
2 for local
•
3 for remote
RFC 2866
Yes
Yes
Yes
Acct-Session Time
NA
46
NA
4
integer
Number of seconds user has received service.
RFC 2866
Yes
Yes
Yes
Acct-Input- Packets
NA
47
NA
4
integer
Number of packets sent from the mobile user (verify).
RFC 2866
Yes
Yes
Yes
Acct-Output- Packets
NA
48
NA
4
integer
Number of packets sent to the mobile user (verify).
RFC 2866
Yes
Yes
Yes
EventTime stamp
G4
55
NA
4
integer
Indicates start of accounting session or stop of accounting session if part of a RADIUS start message or stop message, respectively. It is also used in a RADIUS interim message to indicate the time of the event which triggered the interim message.
RFC 2869
Yes
Yes
Yes
NAS-Port- Type
NA
61
NA
4
integer
Type of physical port on the PDSN.
RFC 2865
Yes
Yes
Yes
Source Ipv6 Prefix
B#
97
NA
4-20
Ipv6-prefix
Carries the IPv6 prefix of the MS. The length includes the reserved byte as well as the prefix length field byte (see RFC 3162, section 2.3).
RFC3162
Yes
Yes
Yes
Ipv6 Interface ID
B4
96
NA
10
string
Interface ID of the mobile flow
RFC 3162
Yes
Yes
Yes
3GPP2-ESN
A2
26/52
3GPP2
15
string
ASCII string of ESN
IS-835-B
Yes
Yes
Yes
3GPP2-HA- IP-Addr
D1 4
26/7
3GPP2
4
ip-addr
IP address of the Home Agent
IS-835-B
Yes
Yes
Yes
3GPP2-PCF- IP-Addr
D3
26/9
3GPP2
4
ip-addr
IP address of the serving PCF
IS-835-B
Yes
Yes
Yes
3GPP2-BSID
D4
26/10
3GPP2
12
string
Base station ID
IS-835-B
Yes
Yes
Yes
3GPP2-User- Zone-ID
E1
26/11
3GPP2
4
integer
Tiered services user zone
IS-835-B
Yes
Yes
Yes
3GPP2- Forward-Mux- Option
F1
26/12
3GPP2
4
integer
Forward direction multiplex option
IS-835-B
Yes
Yes
Yes
3GPP2- Reverse-Mux- Option
F2
26/13
3GPP2
4
integer
Reverse direction multiplex option
IS-835-B
Yes
Yes
Yes
3GPP2- Service- Option
F5
26/16
3GPP2
4
integer
CDMA air interface service option
Supported values:
•
07H,
•
0fH
•
1007H
•
016H
•
017H
•
018H
•
019H, 25 decimal
•
021H, 33 decimal
•
03BH, 59 decimal
IS-835-B
Yes
Yes
Yes
3GPP2- Forward- Traffic-Type
F6
26/17
3GPP2
4
integer
Forward traffic type
Supported values:
•
0 for Primary
•
1 for Secondary
IS-835-B
Yes
Yes
Yes
3GPP2- Reverse- Traffic-Type
F7
26/18
3GPP2
4
integer
Forward traffic type
Supported values:
•
0 for Primary
•
1 for Secondary
IS-835-B
Yes
Yes
Yes
3GPP2- Fundamental- Frame-Size
F8
26/19
3GPP2
4
integer
Fundamental channel Frame Size
Supported values:
•
0 for No Fundamen- tal
•
1 for 5ms frame
•
2 for 20ms frame
IS-835-B
Yes
Yes
Yes
3GPP2- Forward- Fundamental- RC
F9
26/20
3GPP2
4
integer
Forward Fundamental RC
Use is not yet specified in the specs.
IS-835-B
Yes
Yes
Yes
3GPP2- Reverse- Fundamental- RC
F10
26/21
3GPP2
4
integer
Reverse Fundamental RC.
Use is not yet specified in the specs.
IS-835-B
Yes
Yes
Yes
3GPP2-IP- Technology
F11
26/22
3GPP2
4
integer
Specifies Simple IP, Mobile IP, or other technology
Supported values:
•
1 for Simple IP
•
2 for Mobile IP
Other values are configurable, but the defaults are as follows:
•
2 for Proxy Mobile IP
•
1 for VPDN
IS-835-B
Yes
Yes
Yes
3GPP2-Comp- Tunnel-Flag
F12
26/23
3GPP2
4
integer
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.
Supported values:
•
0 for no tunnel
•
1 for non-secure tunnel
•
2 for secure tunnel
IS-835-B
Yes
Yes
Yes
3GPP2- Release- Indicator
F13
26/24
3GPP2
4
integer
Specifies reason for sending a Stop record.
Supported values:
•
0 for unknown
•
1 for PPP/service time-out
•
2 for Handoff
•
3 for PPP termination
•
4 for MIP registration failure
IS-835-B
Yes
Yes
Yes
3GPP2-Bad- PPP-Frame- Count
G3
26/25
3GPP2
4
integer
Number of PPP frames from the mobile station dropped by PDSN due to un-correctable errors.
IS-835-B
Yes
Yes
Yes
3GPP2-Num- Active- Transitions
G9
26/30
3GPP2
4
integer
Number of dormant to active transitions by the user.
IS-835-B
Yes
Yes
Yes
3GPP2-SDB- Octet-Count- Terminating
G10
26/31
3GPP2
4
integer
Total number of octets sent to the user via Short Data Bursts .
IS-835-B
Yes
Yes
Yes
3GPP2-SDB- Octet-Count- Originating
G11
26/32
3GPP2
4
integer
Total number of octets sent by the user via Short Data Bursts.
IS-835-B
Yes
Yes
Yes
3GPP2-Num- SDB- Terminating
G12
26/33
3GPP2
4
integer
Total number of Short Data Burst transactions sent to the user
IS-835-B
Yes
Yes
Yes
3GPP2-Num- SDB- Originating
G13
26/34
3GPP2
4
integer
Total number of Short Data Burst transactions sent by the user.
IS-835-B
Yes
Yes
Yes
3GPP2-IP- QOS
l1
26/36
3GPP2
4
integer
Differentiated Services Code Points associated with the user data
Use is not yet specified in the specs.
IS-835-B
Yes
Yes
Yes
3GPP2- Airlink-QOS
l4
26/39
3GPP2
4
integer
Identifies airlink QoS associated with the user data.
Use is not yet specified in the specs.
IS-835-B
Yes
Yes
Yes
3GPP2-RP- Session-ID
Y2
26/41
3GPP2
4
integer
RP Session ID associated with user session
IS-835-B
Yes
Yes
Yes
3GPP2-Num- Bytes- Received- Total
G14
26/43
3GPP2
4
integer
Count of all bytes received in the reverse direction by the HDLC layer in PDSN.
IS-835-B
Yes
Yes
Yes
3GPP2- Correlation-ID
C2
26/44
3GPP2
8
integer
Identifies all the accounting sessions authorized for this NAI at a PDSN.
IS-835-B
Yes
Yes
Yes
3GPP2- MobileIP- InBound- Signaling- Count
G15
26/46
3GPP2
4
integer
Total number of octets in Registration Requests and Solicitations sent by the mobile.
IS-835-B
Yes
Yes
Yes
3GPP2- MobileIP- OutBound- Signaling- Count
G16
26/47
3GPP2
4
integer
Total number of octets in Registration Replies and advertisements sent to the mobile.
IS-835-B
Yes
Yes
Yes
3GPP2- Session- Continue
C3
26/48
3GPP2
4
integer
Session Continue Indicator to the RADIUS server.
Supported values:
•
0 for End of a Session
•
1 for Session to Continue
IS-835-B
Yes
Yes
Yes
3GPP2-Active- Time
G8
26/49
3GPP2
4
integer
Total active connection time on traffic channel in seconds.
IS-835-B
Yes
Yes
Yes
3GPP2- DCCH- Frame-Format
F14
26/50
3GPP2
4
integer
Frame sizes on DCCH channel
Supported values:
•
0 (no DCCH)
•
1 ( 5 ms and 20 ms)
•
2 (20ms)
•
3 (5 ms)
IS-835-B
Yes
Yes
Yes
3GPP2-Always-On
F15
26/78
3GPP2
4
integer
Always On Service Indication.
Supported values:
•
0 when not enabled
•
1 when enabled
IS-835-B
Yes1
Yes2
Yes3
1 F15 will be sent only when Always On service enabled for the user. However configuration option is provided to send it for all users.
2 F15 will be sent only when Always On service enabled for the user. However configuration option is provided to send it for all users.
3 F15 will be sent only when Always On service enabled for the user. However configuration option is provided to send it for all users.
Prepaid RADIUS Attributes
The following table describes the Prepaid specific attributes:
Glossary
1XRTT—Single Carrier, Radio Transmission Technology
1xEV-DO—Evolution-Data Optimized
3GPP2—3rd Generation Partnership Project 2
A10—3GPP2 TSG-A defined interface for user data
A11—3GPP2 TSG-A defined interface for control messages
AAA —Authentication, Authorization and Accounting
AH— Authentication Header
AHDLC—Asynchronous High-Level Data Link Control
APN— Access Point Name
BG —Border Gateway
BSC —Base Station Controller
BSS— Base Station Subsystem
BTS —Base Transceiver Station
CDMA—Code DivisionMultiple Access
CHAP— Challenge Handshake Authentication Protocol
CN—Corresponding Node
CoA— Care-Of-Address
CRB—Cisco Radius Billing (part of the VSA)
DES—Data Encryption Standard
DNS —Domain Name Server
EAP—Extensible Authentication Protocol
EIA—Electronic Industries Alliance
ESN— Electronic Serial Number
FA— Foreign Agent
FAC —Foreign Agent Challenge (also FA-CHAP)
GRE—Generic Routing Encapsulation
HA —Home Agent
HDLC— High-Level Data Link Control
HSRP —Hot Standby Router Protocol
IMSI—International Mobile Subscriber Identifier
IP —Internet Protocol
IPCP— IP Control Protocol
IS-835B—Specification of the CDMA2000 Wireless Data Architecture
ISP —Internet Service Provider
ITU —International Telecommunications Union
L2TP— Layer 2 Tunneling Protocol
LAC—L2TP Access Controller
LCP— Link Control Protocol
LNS —L2TP Network Server
MAC —Medium Access Control
MIB—Management Information Base
MIN—Mobile Identification Number
MIP— Mobile IP
MS— Mobile Station (= TE + MT)
MSID—Mobile Station Identification
MT —Mobile Termination
MWAM—Multi-processor WAN Application Module
NAI —Network Access Identifier
NAS —Network Access Server
P-MIP— Proxy-Mobile IP
PAP— Password Authentication Protocol
PCF— Packet Control Function
PDSN —Packet Data Serving Node
PPP— Point-to-Point Protocol
PPTP— Point-to-Point Tunneling Protocol
RADIUS—Remote Authentication Dial-in User Service
RAN—Radio Access Network
RP—Radio-PDSN Interface
SIP—Simple IP
SNMP—Simple Network Management Protocol
SPI Value—Security Parameter Index Value
TE —Terminal Equipment
TIA—Telecommunications Industry Association
TID —Tunnel Identifier
UDR—Usage Data Record
UDP—User Datagram Protocol
VPDN —Virtual Packet Data Network
VSA—Vendor Specific Attribute
WAP —Wireless Application Protocol
Feedback









