Table Of Contents
Cisco Packet Data Serving Node (PDSN) Release 3.0 for Cisco IOS Release 12.4(11)T
Mobile IP Dynamic Home Address Deletes Older Sessions With Different IMSI
PMTU Discovery by Mobile IP Client
Features From Previous Releases
Simple IP Based Service Access
Mobile IP Based Service Access
Session Redundancy Infrastructure
AAA - Authentication and Authorization
Configuring PDSN Session Redundancy
Configuring PDSN Session Redundancy Infrastructure
Protocol Layering and RP Connections
Handoff between Closed-RP and Open-RP
Closed-RP/Open-RP Clustering Architecture
Mobility Management With Closed-RP
IOS-SLB on the Supervisor card
Identification of Data Packets For SDB Indication
SDB Indicator Marking for PPP Control Packets
Resource Revocation for Mobile IP
Subscriber Authorization Based on Domain
Volume-based Prepaid Data Service Flow
Duration-based Prepaid Data Service Flow
Volume-based Prepaid Data Service with Tariff Switching
Support for G17 Attribute in Acct-Stop and Interim Records
Mobile IP Call Processing Per Second Improvements
IS-835-B Compliant Static IPSec
Configuring IPSec in Cisco IOS
On-Demand Address Pools (ODAP)
Cisco Proprietary Prepaid Billing
Hardware IPSec Acceleration Using IPSec Acceleration Module—Static IPSec
Conditional Debugging Enhancements
Enhancements Prior to Release 3.0
Electronic Serial Number (ESN) in Billing
Support for Mobile Equipment Indentifier (MEID)
Features Available From Previous PDSN Releases
PDSN Cluster Controller / Member Architecture
PDSN Controller-Member Clustering
Upgrading the Controller PDSN Software from R1.2 to R2.0
Upgrading the Member PDSN Software from R1.2 to R2.0 and Above
Related Features and Technologies
Supported Standards, MIBs, and RFCs
Determining the Software Version
Upgrading to a New Software Release
Upgrading PDSN Image from YF-based Image to R3.0-based Image
Loading the IOS Image to the MWAM
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 PDSN Session Redundancy Infrastructure
Configuring AAA in the PDSN Environment
Configuring RADIUS in the PDSN Environment
Configuring Prepaid in the PDSN Environment
Enabling VPDN in a PDSN Environment
Configuring 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 A11 Session Updates
Configuring SDB Indicator Marking
Configuring SDB Indicator Marking for PPP Control Packets
Configuring On Demand Address Pools
Configuring Mobile IP Resource Revocation on the PDSN
Configuring Closed-RP Interfaces
Configuring Short Data Burst Flagging
Configuring PDSN Accounting Events
Configuring CDMA RADIUS Attributes
Monitoring and Maintaining the PDSN
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
Closed RP IOS SLB Load Balancing Configuration
Open-Closed RP Configuration Example
Session Redundancy Configuration Examples
Simple IPV6 Configuration Example
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 3.0 for Cisco IOS Release 12.4(11)T
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:
•
Feature Overview, page 3
•
•
•
•
•
•
•
•
•
•
•
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 and above, 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 and above, you can use either an FE or GE interface as the Pi interface.
For "back office" connectivity, such as connections to a AAA server, or to a RADIUS server, the interface is media independent. Any of the interfaces supported on the Cisco 7206 can be used to connect to these types of services; however, Cisco recommends that you use either an FE or GE interface.
How PDSN Works
When a mobile station makes a data service call, it establishes a Point-to-Point Protocol (PPP) link with the Cisco PDSN. The Cisco PDSN authenticates the mobile station by communicating with the AAA server. The AAA server verifies that the user is a valid subscriber, determines available services, and tracks usage for billing.
The method used to assign an IP address and the nature of the connection depends on service type and network configuration. Simple IP operation and Mobile IP operation are referred to as service types. The service type available to a user is determined by the mobile station, and by the type of service that the service provider offers. In the context of PDSN, a mobile station is the end user in both Simple IP and Mobile IP operation.
Once the mobile station is authenticated, it requests an IP address. Simple IP stations communicate the request using the Internet Protocol Control Protocol (IPCP). Mobile IP stations communicate the request using Mobile IP registrations.
The following sections describe the IP addressing and communication levels for each respective topic:
•
•
•
Cisco PDSN Simple IP
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
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.
2.
3.
The PPP client is forwarded through a Layer 2 Tunneling Protocol (L2TP) tunnel over User Datagram Protocol (UDP).
4.
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.
2.
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
3.
4.
5.
6.
7.
Note
Mobile IP Dynamic Home Address Deletes Older Sessions With Different IMSI
The PDSN cannot recognize 1xRTT to EVDO as a handoff due to a change of IMSI. The result is that the "cdma-reason-ind" in the account stop message will not reflect the same.
By default, the PDSN keeps the first call session if the Mobile does a static home address. In this release, the PDSN supports deleting the first call session for dynamic home address cases (for example, 1x-RTT to EVDO handoff where the IMSI changes during the handoff).
The old call scenario is established as follows:
1.
2.
3.
A new CLI is introduced in this release that allows you to delete the old session. When you issue the ip mobile cdma imsi dynamic command, the PDSN releases the old session and allows the new session to come up.
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 /en/US/tech/tk870/tk877/tk880/technologies_tech_note09186a008011a218.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
The communication process occurs in the following order:
1.
2.
3.
4.
5.
6.
PDSN on MWAM
The MWAM supports the feature set of PDSN Release 3.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 3.0:
•
–
•
•
•
•
•
–
–
•
–
Features From Previous Releases
This section lists features that were introduced prior to Cisco PDSN Release 3.0
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Note
P indicates that this feature is only available with a Premium license.
* Requires appropriate hardware support.
Note
PDSN Performance Metrics
Performance metrics for the Cisco PDSN software on 7200 Platform include the following:
•
•
•
•
•
•
•
•
•
The following performance metrics apply to the Cisco 6500 and 7600 series platforms. The quoted figures are per image, and each MWAM supports 5 PDSN images.
•
•
•
•
•
•
•
•
•
•
•
•
Packet Data Service Access
The PDSN supports two types of service accesses. The type of service access for a mobile session is determined by the capabilities of the mobile station:
•
•
Simple IP Based Service Access
The PDSN facilitates a mobile user to access the internet and corporate intranet by using Simple IP based service access. Simple IP mode of access, however, limits user mobility to the coverage area of the serving PDSN. Inter-PDSN handoff causes re-negotiation of PPP between the mobile station and the new PDSN. The old IP address assigned at the previous PDSN can usually not be assigned to the mobile user from the new PDSN, and results in reset and restart of user applications.
Some of the salient features for Simple IP based service access include:
•
•
•
•
•
•
•
•
•
•
•
•
•
User NAI is available during the PPP CHAP/PAP authenticating phase. Domain name information in the NAI determines the domain responsible for user authentication. Based on the type of packet routing model, Simple IP based service access can be categorized as follows.
•
•
•
Simple IP Routed Access
After receiving username and password during PPP LCP negotiations, the PDSN forwards authentication information to the local AAA server via an access request message. This, in turn, may be proxied to the AAA server in the user's home domain, via broker AAA servers, if necessary. On successful authentication, the user is authorized services based on its service profile. User Class/CDMA_IPTECH information, along with other authorization parameters are returned to the PDSN using an access accept message from the home AAA. On successful negotiation of an IP address, Simple IP based services are made available to the mobile user.
Simple IP routed access method is applicable for users that are not configured for VPDN or proxy-Mobile IP services. With PPP terminated at the PDSN, uplink user traffic is routed towards the IP network from the PDSN. The address assigned to the mobile user would be from within the PDSN routable domain. Private addresses may also be used if a NAT is configured. User mobility is limited to the PDSN coverage area. Inter-PCF handoffs do not disrupt service. Inter-PDSN handoffs, however, result in PPP renegotiation at the new PDSN, another IP address being assigned at the new PDSN, and reset and restart of user applications.
Simple IP VPDN Access
After receiving username and password during PPP LCP negotiations, the PDSN forwards authentication information to the local AAA server via an access request message. This, in turn, may be proxied to the AAA server in the user's home domain, via broker AAA servers, if necessary. On successful authentication, the user is authorized services based on user's service profile. If the user is configured for VPDN based access services, User Class information, along with other authorization parameters including tunneling options and tunneling parameters, are returned to the PDSN via an access accept message from the home AAA. The following types of VPDN services are supported at the PDSN:
L2TP - Layer 2 Tunneling Protocol
For L2TP type layer2 tunneling, the PDSN establishes an L2TP tunnel with the tunneling endpoints specified by the tunneling parameters. The L2TP tunnel would be established between the LAC at the PDSN and LNS at the NAS in user's home domain. The PPP connection would be between the mobile station and the LNS in the home network. Despite the PPP connection termination at the LNS, the PDSN monitors the PPP session for inactivity. Status of the PPP connection is also linked with the state of the underlying A10 connection. PPP connection is deleted when the underlying A10 connection is deleted. IPSec encryption methods can also be enabled over the L2TP tunnels for enhanced security.
On successful negotiation of an IP address between the mobile and the LNS, IP-based services are made available to the mobile.
The LNS may be configured to authenticate the mobile user based on the challenge and challenge response information from the PDSN. Additionally, the LNS may also be configured to challenge the user again after the layer2 tunnel has been established. The following authentication options are supported for L2TP:
•
The LAC (PDSN) challenges the mobile user and forwards authentication related information to the LNS as part of tunnel setup parameters. The LNS may be configured to authenticate the user either locally or via the home AAA, based on the authentication related information from the LAC (PDSN). On successful authentication, the mobile and the LNS proceed with the IPCP phase and negotiate an IP address for the user session. Call establishment procedures for this scenario are illustrated in Figure 16.
•
The LAC (PDSN) challenges the mobile and forwards authentication related information to the LNS as part of tunnel setup parameters. The LNS may be configured to authenticate the user either locally or via the home AAA, based on the authentication related information from the LAC (PDSN). On successful authentication, the LNS challenges the mobile again. After successful authentication, the LNS and the mobile proceed with IPCP phase and negotiate the IP address for the user session.
Proxy-Mobile IP Access
After receiving username and password during PPP LCP negotiations, the PDSN forwards authentication information to the local AAA server via an access request message. This, in turn, may be proxied to the AAA server in the user's home domain, using broker AAA servers, if necessary. On successful authentication, the user is authorized services based on its service profile. User Class information, along with other authorization parameters are returned to the PDSN via an access reply from the home AAA.
If the user is configured for proxy-Mobile IP based access, authorization parameters from the home AAA include the Home Agent (HA) address, and the security parameter (SPI) to be used for computing the MN-HA Authentication extension for the mobile station. The Home Agent is allocated from the list of Home Agents configured at the home AAA server. Round robin or hashing algorithms based on user NAI can be used for allocating a Home Agent at the AAA. Other authorization attributes returned from the AAA include MN-AAA authenticating extension as defined in RFC 3012. Based on this information, the PDSN performs proxy-Mobile IP procedures on behalf of the mobile user by sending a Mobile IP Registration Request message to the allocated HA. On successful authentication of the mobile with the AAA, and registration at the Home Agent, the Home Agent assigns a home address for this mobile user This address is returned to the mobile during IPCP IP address negotiation phase.
On successful negotiation of an IP address, proxy-Mobile IP based services are made available to the mobile user. To the mobile, these services are no different from Simple IP services with tunneling being done via the Home Agent. This feature, however, extends the coverage area of the call beyond coverage area of the serving PDSN. If, as a result of a handoff event, another PDSN is allocated to the call, the target PDSN performs Mobile IP registration with the Home Agent thereby ensuring that the same home address is allocated to the mobile.
Mobile IP Based Service Access
The PDSN allows a mobile station with Mobile IP client function, to access the internet and corporate intranet using Mobile IP based service access. With this mode of service access, user mobility is extended beyond the coverage area of currently serving PDSN. Resulting from a handoff, if another PDSN is allocated to the call, the target PDSN performs Mobile IP registration with the Home Agent thereby ensuring that the same home address is allocated to the mobile.
Some of the salient features for Mobile IP services access include:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
A Mobile IP capable mobile client may be configured to skip PAP/CHAP based authentication during the PPP LCP phase. Once the PPP is established, the PDSN sends a burst of Mobile IP Agent Advertisement messages that include the Mobile IP Agent Advertisement Challenge extension specified in RFC 3012. The number and timing of the burst is configurable. The mobile user responds with a Mobile IP Registration Request message that includes the mobile user's NAI and MN-FA Challenge extension in response to the challenge in the Agent Advertisement message. If the mobile user does not respond to the initial burst, advertisements can be solicited.
The Foreign Agent function at the PDSN can be configured to authenticate the mobile user by forwarding an access request message to the local AAA server. The local AAA server would proxy the message to the home AAA server, via broker AAA server(s), if necessary. On successful authentication, the home AAA may assign a Home Agent to the call and return its address in the access reply message. Other authorization parameters in the access-reply message include the SPI and IPSec shared key to be used between the FA and the HA. The PDSN/FA and Home Agent establish a secure IPSec tunnel, if required, and the PDSN/FA forwards the Registration Request message to the Home Agent. The Registration Request message includes the NAI and MN-FA-Challenge Extension also. It may also include MN-AAA Authentication extension.
The Home Agent can be configured to authenticate the mobile again with the home AAA. On successful authentication and registration, the Home Agent responds with a Registration Reply message to the PDSN/FA, which is forwarded to the mobile station. The Registration Reply message contains the home address also (static or dynamically assigned) for the user session.
Potential home addresses are available to the PDSN from the following:
•
•
•
The mobile may be configured to perform PPP PAP/CHAP authentication in addition to performing Foreign Agent Challenge based authentication specified in RFC 3012. In this case the PDSN would support one Simple IP flow, in addition to one or more Mobile IP flows.
For Mobile IP services, the Home Agent would typically be located within an ISP network or within a corporate domain. However, many of the ISPs and/or corporate entities may not be ready to provision Home Agents by the time service providers begin rollout of third-generation packet data services. Access service providers could mitigate this situation by provisioning Home Agents within their own domain, and then forward packets to ISPs or corporate domains via VPDN services.
Binding Update Procedures
When a mobile first registers for packet data services, a PPP session and associated Mobile IP flow(s) are established at the PDSN. In the event of an inter-PDSN handoff, another PPP session is established at the target PDSN, and the mobile registers with the Home Agent via the new PDSN/FA. The Visitor list binding and the PPP session at the previous PDSN are, however, not released until the PPP inactivity timer expires.
Idle/unused PPP sessions at a PDSN consume valuable resources. The Cisco PDSN and Home Agent support Mobile IP Resource Revocation as defined in IS83C and Cisco Proprietary Binding Update and Binding Acknowledge messages for releasing such idle PPP sessions as soon as possible. Mobile IP Resource Revocation is described in Section 16 in greater detail
If Cisco Proprietary binding update feature is used, in the event of an inter-PDSN handoff and Mobile IP registration, the Home Agent updates mobility binding information for the mobile with the Care-of-Address (COA) of the new PDSN/FA. If simultaneous bindings are not enabled, the Home Agent sends a notification in the form of a Binding Update message to the previous PDSN/FA. The previous PDSN/FA acknowledges with Binding Acknowledge, if required, and deletes visitor list entry for the Mobile IP session. The previous PDSN/FA initiates the release of the PPP session when there are no active flows for that mobile station.
The sending of the binding update message is configurable at the Home Agent.
Note
Simple IPv6 Access
The PDSN simple IP service has been enhanced to allow both simple IPv4 and simple IPv6 access. These protocols can be used one at a time, or at the same time. The ipcp and the ipv6cp are equivalent for each protocol.
An IPv6 access uses the same PPP LCP authentication and authorization procedures, as well as the AAA access. When an RP connection is established, the MS sends a PPP Link Control Protocol (LCP) Configuration-Request for a new PPP session to the PDSN. The PPP authentication (CHAP/PAP/none) is one of the parameters negotiated during the LCP phase. After the LCP parameters are negotiated between the MS and the PDSN, an LCP Configure-Acknowledge message is exchanged. Once LCP is up, the PPP authentication is started.
The authentication phase uses CHAP, PAP, or none, depending on the configuration and LCP negotiation. After authentication, the NCPs, ipcp and/or ipv6cp, can be started. A simultaneous IPv4 and IPv6 access from an MS shares the common LCP authentication and authorization as well as the AAA correlation-id parameter.
The ipv6cp protocol negotiates a valid non-zero 64-bit IPv6 interface indentifier for the MS and the PDSN. The PDSN has only one interface-identifier associated with the PPP connection, so it will be unique. Once ipv6cp has been successfully negotiated, the PDSN and MS both generate unique link-local addresses for the IPv6 interface. The link-local addresses are generated by pre-pending the link-local prefix, FE80:/64, to the 64-bit interface-identifier negotiated during the ipv6cp phase (for example, FE80::205:9AFF:FEFA:D806). This gives a 128-bit link-local address.
The PDSN immediately sends an initial unsolicited Router Advertisement (RA) message on the PPP link to the MS. The link-local address of the PDSN is used as the source address and the destination address will be FF02::1, the "all nodes on the local link" IPv6 address. The PDSN includes a globally unique /64 prefix in the RA message sent to the MS. The prefix may be obtained from a local prefix pool or from AAA. The MS will construct a global IPv6 unicast address by prepending the prefix received in the RA to the lower 64-bit interface identifier. You should carefully configure the PDSNs so that the /64 prefix is globally unique for each MS.
After a successful ipv6cp negotiation phase and configuration of the link-local address, the MS transmits a Router Solicitation (RS) message if an RA message has not been received from the PDSN within some specified period of time. The RA is necessary for the MS to construct its 128-bit global unicast address.
In contrast to IPv4, an IPv6 MS will have multiple IPv6 addresses, including:
•
•
•
An IPv6 address is 128-bits for both source and destination addresses. The /64 designation means that 64-bits are used for the prefix (upper 64-bits). This is similar to an IPv4 netmask. A /128 address would mean that the entire address is used. Refer to RFC-3513 for additional IPv6 addressing details and information.
Configuring Simple IPV6
The following commands are used to configure simple IPV6 on the Cisco PDSN, and are listed in the Command Reference:
•
•
•
•
•
•
•
The following configuration commands are required for IPv6:
Global Configuration Commands
•
•
•
Virtual-template interface commands:
•
•
•
•
•
Other commands
•
Please refer to the Cisco IOS IPV6 Command Reference at the following URL for more detailed information regarding these configuration commands:
http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/products_command_reference_book09186a00801d661a.html
Session Redundancy Infrastructure
Note
PDSN session redundancy is focused on preserving user flows on fail-over. Support for the continuity of billing records, internal counters, and MIB variables is secondary. The following conditions need to exist for fail-over to be successful on the PDSN:
•
•
•
Functional Overview
The PDSN Session Redundancy feature provides user session failover capability to minimize the impact of a PDSN failure on the mobile user experience. The PDSN uses a 1:1 redundancy model, with a standby present for every active PDSN. The active PDSN sends state information to the standby PDSN for synchronization on an as-needed basis. When a PDSN failure occurs, the standby PDSN has the necessary state information to provide service to all existing sessions. It then takes over as the active PDSN and services user sessions, thus providing session redundancy. When the previously active PDSN comes back online, it assumes the role of standby for the now active PDSN, and receives state information for all existing sessions from the newly active PDSN.
Under normal operating conditions, the active and standby PDSN pairs are two separate PDSN images that have identical configurations. They share one or more HSRP interfaces, which are used by all external entities to communicate with them. The active PDSN synchronizes session data to the standby PDSN based on events described below.
Session Events
When a new user session needs to be established, the PCF first sets up an A10 connection to the active PDSN, via the HSRP address known to the PCF. The MN then sets up a PPP connection with the active PDSN, via the A10 tunnel. Once the call is in a stable state, i.e., the PPP session is successful, the active PDSN then syncs relevant state information to the standby PDSN. The standby then duplicates the actions of the active PDSN with regards to the A10 connection and the PPP session, and awaits further updates from the active. When any of the other events as listed below occurs, the active PDSN sends state information to the standby.
In order to minimize the loss of accounting data in the event of a failover, a periodic accounting update, with configurable frequency shall run on the active PDSN. Every periodic update for a session shall trigger a sync sent to the standby PDSN, which shall update its accounting data. Only counters and attributes that undergo a change on the active PDSN are synced to the standby periodically. Information since the last accounting synchronization point will be lost. Also, in order to ensure that the latest information is correctly conveyed to the billing system, the standby unit will never send out any accounting records to the AAA server. The records are always sent from the Active Unit.
Session events that lead to a sync are:
•
•
•
•
•
•
•
•
•
IP Address Management and ODAP
IP addresses allocated to the user by the active PDSN are communicated to the standby PDSN, which will honor them. This is true no matter what allocation mechanism is used.
Both the DHCP ODAP subnet allocation server and the ODAP manager supports the PDSN session redundancy functionality. The DHCP ODAP subnet allocation server runs on the PDSN MWAM Cluster Controller. It synchronizes the allocated subnet pool information to the backup DHCP ODAP subnet allocation server located on the Backup MWAM Cluster Controller.
Similarly, the ODAP manager on the PDSN synchronizes the IP subnet pool and allocation information to a backup PDSN image.
If either the DHCP ODAP subnet allocation server or the ODAP manager fails, the backup takes over. This allows existing PDSN sessions to remain, and for new session requests to be properly processed.
Active PDSN Failure
In the event that the standby PDSN detects that the active PDSN has failed (using HSRP), it then takes over as the active PDSN. Since all external entities, including PCFs, AAA servers, and Home Agents are configured to communicate with the PDSN pair only using the HSRP addresses, once the standby PDSN takes over those addresses, they are unable to detect a failure. All stable calls also have their state synced to the standby; therefore the standby is able to start forwarding user traffic once it takes over as active. On the standby all timers (such as A11 lifetime, PPP timers, and Mobile IP lifetime) are started at the time it takes over as active. Accounting data is also synchronized to the extent that the periodic accounting sync timer has been configured on the PDSNs.
Standby PDSN Start-up
When a PDSN comes up when there is an existing active, it takes over the standby role. When the active PDSN learns that a standby PDSN is available, it goes through a process of transferring state data for all existing user sessions to the standby, called a Bulk Sync. Once this process is complete, the standby PDSN is then ready to take over as active in the event of a failure.
Handling Active-Active Scenario
If there is a link failure or a failure in an intermediate node, HSRP packets sent will not reach the peer and the standby node would assume that the active has reloaded and transitioned to active state. This leads to a situation of Active-Active PDSN nodes. The requirement is that, in case one of the PDSNs continues to receive traffic while the other is isolated from the network, it is ensured that the node which received traffic should remain active once the link is restored.
To achieve this, an application tracking object is introduced and HSRP priority is altered based on whether PDSN is processing traffic after the HSRP peer is lost. For details on configuration refer to section 20.4.9. The PDSN will lower its HSPR priority once it detects that the peer PDSN is lost. Afterward, when PDSN processes traffic (either control or data packets), it would raise its priority back to the configured value. This helps to choose the active node after the link is restored between the PDSNs. So the node which received traffic in Active-Active situation remains to be Active after link restoration.
Other Considerations
A Redundancy Framework (RF) MIB is available in order to monitor the active and standby status of the two PDSNs. Other MIB variables and internal counters are not synchronized between the Active and Standby. They start from the values following IOS-Load or Reload on the backup image. The backup image is treated as a new box.
The PDSN redundant pair is treated as a single member by the cluster controller, and is transparent to the PDSN clustering mechanism. The cluster controller is oblivious to a failover from an active PDSN to its redundant standby.
Similarly, a PDSN redundant pair appears as a single PDSN to all external entities, such as the PCF, the HA, and the AAA server.
IPSec security associations for FA-HA connectivity are maintained across fail-over.
Note
Note
In Process Sync Events
The following subsections explain the expected behavior of the PDSN under session redundancy for various sync events in process.
Call Setup
The state of "sessions-in-progress" is not preserved during fail-over. Mechanisms such as R-P connection retry from the PCF will ensure that sessions will be established as required.
It is possible that a fail-over can occur when the PCF has established an R-P session for a user flow, but user flow establishment is not completed. In this case, fail-over will result in the R-P session not being present on the standby. The PCF will timeout the R-P session on the next R-P session lifetime refresh. If the user attempts to establish a new session during this time, a new session will be created.
Call Teardown
There are four scenarios for session termination. These include the following:
•
•
•
•
For each of these cases, session teardown is a multi-step process. For example, a fail-over can occur when a Registration Update message has been sent from the PDSN and the acknowledgement has not been received. In this case, the standby PDSN will already have been told to delete the session. The active PDSN will not wait for an update acknowledgement from the PCF.
If a fail-over occurs after sending the Registration Update to the PCF but before the standby has been told to delete the session, or the request to delete the session is lost, the session will remain established on the standby.
Another case is that the PPP context has been deleted as a result of mobile-initiated termination, and then fail-over occurs prior to the R-P session being terminated.
Similarly, expiry of the PPP Idle timer on the PDSN could also result in deletion of PPP context followed by fail-over prior to R-P session termination.
In these cases, either the Mobile IP Registration Lifetime or the PPP Idle Timeout will expire, and the session is terminated.
Flow Setup
Flows that are in the process of being established are not preserved. You will see this as failure to establish the flow, and you will have to re-establish the flow.
Flow Teardown
This section applies when a session has two or more flows. Currently only a MoIP call supports this case. For an SIP call, only one flow is allowed.
Although a MoIP flow is preserved after switchover, it is possible that registration lifetime expiration will lead to deletion of the flow. If the same user registers again before the lifetime expires, it will be considered as a re-registration since this is an existing visitor. However, the re-registration may or may not succeed, depending on the following conditions:
1.
2.
Dormant-Active Transition
The transition is synchronized between active and standby, and would fall into following scenarios:
1.
2.
However, packets will be switched and counted. The PDSN-related show commands may not show all the right information about the session. The subsequent transition from active to dormant will not cause difficulties as the session remains dormant on the PDSN.
3.
4.
Handoff
Inter-PCF Handoff (Dormant or Active) - Same PDSN
The most significant problem with hand-off is to re-establish the data path between the target PCF and the now-active PDSN for the preserved session, irrespective of whether this is an active or dormant handoff. Again, there is a window between handoff actually being completed and the state being synchronized within which a fail-over can occur.
There are the following scenarios:
1.
2.
3.
Inter-PCF Handoff (Dormant or Active) - Different PDSN
This kind of handoff is indicated to the PDSN by receipt of an A11 Registration Request containing the PANID and CANID. It also includes the Mobility Event Indicator and Accounting Data (R-P Session Setup Air-link Record). From the perspective of High Availability, this looks like a new session establishment on the newly active PDSN and a 'regular' session termination on the old PDSN.
A11 Re-registrations
A11 Re-registration RRQ is received by the active unit. The registration life timer does not start on the standby, but it keeps track of the life timer value so that it can restart the life timer once it becomes active. If the lifetime in the re-registration RRQ is different from the previous RRQ, the new lifetime is synced to the standby. For example, if a previous RRQ carries a lifetime of 300 seconds and now a new RRQ has the value changed to 500 seconds, the new value is synced to the standby. Other significant parameters included in the re-registration RRQ are also synced to the standby.
Now, in the above example, if the failover occurs before syncing the new lifetime to the standby, the standby will start the lifetime for 300 seconds.
PPP Re-negotiation
Upon PPP renegotiation, the PDSN deletes all the flows on the RP session and sends accounting STOP for each flow. Once PPP is up again, the PDSN creates new flow(s) for the session. Therefore, when PPP renegotiation happens on the active, the active unit will send a PPP renegotiation notification to the standby which will then delete all the flows from the RP session on the standby. Once PPP is up again and a new flow is created on the active, the active unit sends each flow's data to the standby. If the failover occurs during PPP re-negotiation, the re-negotiation will fail, and the session may be torn down on the newly active unit.
Other Considerations
Timers
The following timers are normally running when a session is established
•
•
•
•
The following timers may be running, depending on configuration
•
These timers are restarted on the standby when fail-over occurs, and the elapsed time is not synchronized to the standby. The effect will be to extend the timers beyond their original values by a time equal to the time that has already expired. This ensures that the user will not perceive a session failure on fail-over.
Restrictions
The following restrictions exist for the PDSN Session Redundancy Feature:
•
Setting the revocation timestamp to "msec" (ip mobile foreign-service revocation timeout 5 retransmit 4 timestamp msec) for PMIP flows with Session Redundancy is not permitted.
The "msec" option puts the uptime in the timestamp field, and the uptime of the standby router is expected to be lower after switchover when the standby PDSN takes over as active (and when the PMIP flow was closed). Therefore, revocation on HA will be ignored because the identifier value in the revocation message is less than what is expected by HA.
•
Internals
The following sections identify information that is synced to the standby unit:
AHDLC
The control character mapping per used AHDLC channel is preserved. As the default is normally used, only those that are different are synchronized. The AHDLC channel number is not synchronized; an available channel will be selected independently on the standby.
GRE - RP Interface
The GRE Key is synchronized. The flags are synchronized as the sequence flag can be set on a per user basis.
RP Signaling
The contents of the A11 messaging will be treated as described below.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
PPP
All LCP options are synchronized. For IPCP, only the IP address and IPHC parameters are synchronized. DNS server IP address negotiated during IPCP negotiation is not synchronized to the standby unit. All per user attributes downloaded from AAA during authentication/authorization are synchronized to the standby unit.
Compression - Header and Payload
There is no synchronization of compression context for either header or payload compression. Fail-over to a standby PDSN results in the compression context being re-established.
Header compression - First packet for a session after switchover is dropped, and peer retries the packet after acknowledge timeout.
Payload compression - There is no compression history present after switchover on the standby. A CCP reset is automatically generated when decode fails. No special treatment is needed.
IP Address Assignment
When an IP address is dynamically assigned from a pool configured on the PDSN, it is necessary that the standby associates the same address with the session. The IP address will be synchronized as part of PPP state. If the IP address is received from AAA or a static IP address is used that does not come from a local pool, this address will also be associated with the session on the standby. Similarly, the address pool will be synced.
AAA - Authentication and Authorization
Table 2 lists the relevant Authentication and Authorization parameters. This is required on the standby to allow accurate recreation of AAA state.
GPP2 Packet Data Service Attributes
Table 3 lists the 3GPP2 Packet Data Service Attributes
AAA Accounting
GPP2 Accounting Records Fields
Table 4 identifies the GPP2 accounting records fields.
Radius Server Group Support
The IP address of the AAA server chosen will not be synchronized.
Mobile IP Signaling
For Mobile IP service, the parameters to be synchronized, per MIP flow, include the following:
•
•
•
•
•
•
•
•
Mobile IP tunneled traffic
This traffic is carried in either GRE tunnels or IP-in-IP tunnels. The only information that needs to be synchronized is the tunnel endpoint of the peer.
Locally Configured IPSec
For the PDSN on the Cat76xx, IPSec tunnels are terminated on the Macedon VPN Acceleration Module. The role of the PDSN is to retrieve parameters from AAA and, based on those parameters, trigger IPSec tunnel establishment. Synchronization of these parameters is sufficient to preserve IPSec tunnels in the event of PDSN fail-over for intra-chassis configurations. PDSN failover is not coupled with VPN Acceleration Module/SUP failover. Inter chassis configurations and intra-chassis Macedon/SUP failover does not currently support stateful IPSec.
FA-HA IPSec
FA-HA IPSec tunnels will be preserved when PDSN on 7600 fail-over occurs for intra-chassis configurations. They will not be preserved for inter chassis configurations.
AAA Accounting
Periodic Accounting Sync
Accounting information is optionally synchronized between the active and standby images. This synchronization occurs at the configured periodic accounting interval. The counters that are synchronized are g1 and g2, along with the packet counts. Sending an Interim Accounting record will trigger synchronization of the byte and packet counts. Setting the operator-defined periodic accounting interval determines the accuracy of the user-billing record as impacted by PDSN fail-over. It is possible that undercharging could occur; however, overcharging is not possible.
Accounting with VSA Approach
After a switchover takes place, the first interim or stop accounting record (as appropriate) includes a VSA (cdma-rfswact) indicating that a switchover has occurred. The inclusion of this VSA is controllable by issuing the cdma pdsn redundancy accounting send vsa swact command.
Note
Here is a sample accounting debug with vsa:
Sep 13 18:23:10.179: RADIUS: Cisco AVpair [34] 16Sep 13 18:23:10.179: RADIUS: 63 64 6D 61 2D 72 66 73 77 61 63 74 3D 31 [cdma-rfswact=1]System Accounting
In a session redundancy setup, an accounting ON will be sent by the active unit only when the whole setup is brought up (accounting ON will not be sent by the newly active unit after a failover). The standby unit does not send any system accounting events under any scenarios. The events, however, are sent in a standalone mode.
A sys-off is sent if reload is issued on the active unit.
Configuring PDSN Session Redundancy
The following new commands have been introduced for PDSN Session Redundancy:
Enabling PDSN Session Redundancy
The active PDSN shall be able to synchronize the session and flow related data to its standby peer provided the redundancy capability has been enabled. By default this capability is disabled.
The commands syntax is as follows:
[no] cdma pdsn redundancy
When the above CLI is configured, session redundancy is enabled provided the underlying redundancy infrastructure has been configured. The redundancy functionality for PDSN is disabled when the above command with no is executed.
Periodic Accounting Counters Synchronization
The active PDSN by default will not try synchronizing accounting counters periodically. To enable periodic accounting counters synchronization, configure the following command:
[no] cdma pdsn redundancy accounting update-periodic
The no form of the command is used to go to the default behavior. When configured, the byte and packet counts for each flow are synced from the active to the standby unit (only if they undergo a change) at the configured periodic accounting interval (using aaa accounting update periodic xxx). If periodic accounting is not configured, the byte and packet counts will not be synced.
Debug Commands for PDSN-Session Redundancy
In order to facilitate the identification of problem areas of PDSN high availability, the following debug commands are introduced for debugging. All of these debug can be turned off using either undebug all or no debug all, if desired.
[no] debug cdma attribute
[no] debug cdma pdsn redundancy packets
To debug and collect any data pertaining to PDSN-SR, the above command is executed and the details pertaining to redundancy data is sent to the console.
[no] debug cdma pdsn redundancy errors
To debug the PDSN-SR redundancy errors the above command is executed and the details pertaining to A11 data is sent to the console.
[no] debug cdma pdsn redundancy events
To debug events for PDSN session redundancy events, above command is executed and the details pertaining to PDSN (e.g. RP) data is sent to the console.
Display of Redundancy Statistics
When a pair of PDSNs is operating in an active and a standby mode, it is desirable to show or display a variety of information about the sessions and its associated flows that have been synchronized to the standby. The following command shall allow the operator to view the session redundancy data for PDSN.
show cdma pdsn redundancy statistics
On execution the above command displays a number of data items; some of the examples are as follows:
–
–
–
–
–
Note
show cdma pdsn redundancy
On execution of this command, in addition to existing data being displayed, it will also output "pdsn redundancy is enabled," or "redundancy is not enabled," depending on whether the redundancy feature for PDSN has been turned on, or not.
Clearing of PDSN Session Redundancy Statistics
clear cdma pdsn redundancy statistics
On execution of this command, all the data counters associated with the PDSN session redundancy will be actualized to initial value.
Other Debug Commands
In addition to the PDSN-SR debugging commands described above, the following commands associated with high availability are also useful debugging aid:
debug redundancy inter-device
debug ccm
Other Show Commands
In addition to the PDSN-SR show commands described above, the following commands associated with high availability are also useful:
show redundancy inter-device
Configuring PDSN Session Redundancy Infrastructure
The PDSN-SR feature uses the Cisco IOS Check-point Facility (CF) to send stateful data over Stream Control Transmission Protocol (SCTP) to a redundant PDSN. Additionally, in conjunction with Cisco IOS HSRP, the PDSN uses the Cisco IOS Redundancy Facility (RF) to monitor and report transitions on Active and Standby PDSNs.
Before you configure PDSN-SR, you need to configure the inter-device redundancy infrastructure.
Configuring HSRP
The Hot Standby Router Protocol (HSRP) provides high network availability because it routes IP traffic from hosts on networks without relying on the availability of any single router. HSRP is used in a group of routers for selecting an Active router and a Standby router. HSRP monitors both the inside and outside interfaces so that if any interface goes down, the whole device is deemed to be down and the Standby device becomes active and takes over the responsibilities of an Active device.
When configuring HSRP, note that the following recommendation and restrictions apply:
•
–
–
–
–
•
•
Note
•
Use the same group number for each PDSN follow group as is defined for the primary group. Using the same group number for the primary and follow groups facilitates HRSP group setup and maintenance in an environment that contains a large number of PDSN interfaces and HRSP groups.
More information on HSRP configuration and HSRP groups can be found here:
and
Enabling HSRP and Configuring an HSRP Master Group
To enable HSRP on an interface and configure the primary group, use the following commands in interface configuration mode:
Step 1
Enables the HSRP on the interface.
Step 2
Set the Hot Standby priority used in choosing the active router. The priority value range is from 1 to 255, where 1 denotes the lowest priority and 255 denotes the highest priority. Specify that, if the local router has priority over the current active router, the local router should attempt to take its place as the active router.
Step 3
Specifies the name of the standby group.
Step 4
(Optional) Configures HSRP to use the burned-in address of an interface as its virtual MAC address instead of the preassigned MAC address.
Configuring Follow Groups
HSRP follow groups are configured to share the HSRP parameters of the primary group by defining a follow group on the interface using the standby interface configuration command with the follow keyword option specified. Interfaces that share a group track states together and have the same priority.
To configure an interface to follow a primary group, use the following command in interface configuration mode:
Step 1
Specifies the number of the follow group and the name of the primary group to follow and share status.
Note
Step 2
Specifies the group number and virtual IP address of the follow group.
Note
Enabling Inter-Device Redundancy
To enable inter-device redundancy, use the following commands beginning in global configuration mode.
Step 1
Configures redundancy and enters inter-device configuration mode.
To remove all inter-device configuration, use the no form of the command.
Step 2
Defines the redundancy scheme that is to be used. Currently, "standby" is the only supported scheme.
standby-group-name-Must match the standby name specified in the standby name interface configuration command (see the "Configuring HSRP" section). Also, the standby name should be the same on both PDSNs.
Step 3
Returns to global configuration mode.
Configuring the Inter-Device Communication Transport
Inter-device redundancy requires a transport for communication between the redundant PDSNs. This transport is configured using Interprocess Communication (IPC) commands.
To configure the inter-device communication transport between the two PDSNs, use the following commands beginning in global configuration mode:
Step 1
Configures the Inter-device Communication Protocol (IPC) and enters IPC zone configuration mode.
Use this command to initiate the communication link between the Active device and the Standby device.
Step 2
Configures an association between two devices and enters IPC association configuration mode.
In IPC association configuration mode, you configure the details of the association, such as the transport protocol, local port and local IP addresses, and the remote port and remote IP addresses.
Valid association IDs range from 1 to 255. There is no default value.
Step 3
Restarts a disabled association and its associated transport protocol. Note Shutdown of the association is required for any changes to the transport protocol parameters.
Step 4
Configures Stream Control Transmission Protocol (SCTP) as the transport protocol for this association and enables SCTP protocol configuration mode.
Step 5
Defines the local SCTP port number to use to communicate with the redundant peer and enables IPC Transport-SCTP local configuration mode.
Valid port numbers range from 1 to 65535. There is no default value.
Note
Step 6
Defines the local IP address that is used to communicate with the redundant peer. The local IP address must match the remote IP address on the peer router.
Step 7
Enables keepalive packets and specifies the number of times that the Cisco IOS software tries to send keepalive packets with a response before bringing down the interface or tunnel protocol for a specific interface.
Valid value for period is an integer value in seconds great than 0. The default is 10. Valid value for retries is an integer value greater than one and less than 355. The default is the previously used value or 5 if there was no value previously specified.
Step 8
Configures the message retransmission time. Valid range is 300 to 60000 milliseconds. The minimum default is 1000. The maximum default is 60000.
Step 9
Configures the maximum number of keep-alive retries before the corresponding destination address is marked inactive. Valid range is 2 to 10. The default is 5.
Step 10
Defines the maximum number of retransmissions over all destination addresses before an association is declared failed. Valid range is 2 to 20. The default is 10.
Step 11
Exits IPC transport - SCTP local configuration mode.
Step 12
Defines the remote SCTP port that is used to communicate with the redundant peer and enables IPC Transport-SCTP remote configuration mode. Valid port numbers range from 1 to 65535. There is no default.
Note
Step 13
Defines the remote IP address of the redundant peer that is used to communicate with the local device. All remote IP addresses must refer to the same device. To remove an association configuration, use the no form of the command.
Using the Loopback Interface For the PDSN-AAA Server Interface
To ensure that the AAA server views the active and standby units as a single NAS, the same NAS IP address should be used by both the units. Now, the NAS IP Address can be configured for the PDSN using the ip radius source-interface command. When configured, the IP address of that interface is used as the NAS IP Address.
However, the command does not support virtual IP addresses (HSRP). As a result, the only way to ensure that both the units appear as a single NAS is to configure a loopback interface, and use that interface as the source-interface. In short, the CLI would look something like:
ip radius source-interface Loopback1
Configuring Application Tracking to Handle Active-Active Situation
Step 1
Defines a tracking object for PDSN application.
Step 2
Associates the tracking object defined for PDSN with the HSRP config. HSRP would start tracking the state of this object. The configured decrement priority is used to change the HSRP priority based on the state of the tracking object. If the tracking object is "UP", HSRP will have the configured priority. If the tracking object is "DOWN", HSRP decrements its priority by the decrement priority specified in the standby track command.
Note
Protocol Layering and RP Connections
Each mobile station has a single PPP connection with the PDSN, and for each PPP connection there is a corresponding R-P connection between the PDSN and the Base Station/ PCF. R-P connection-related information is maintained for the duration of the PPP connection.
Additionally, the PPP connection and the associated HDLC, LCP, CCP and IPCP state information is also maintained for the duration of the packet data session. One Simple IP flow and several Mobile IP flows can be supported over a single PPP connection.
Open RP Interface Connections
An R-P connection represents the logical tunnel between the PDSN and the Base Station/PCF. It enables bearer data for a PPP connection to be transported between the PDSN and the Base Station/PCF. R-P connection state information is maintained at the PDSN for the duration of the PPP connection. During handoff, the mobile station may connect the PDSN through another Base Station/PCF entity resulting in establishment of another R-P connection between the PDSN and the new Base Station/PCF. This results in the release of the R-P connection between the PDSN and the old Base Station/PCF.
R-P connection state information is maintained at the PDSN even during the dormant phase of the session. When a mobile station transitions to active state, this information allows the PDSN to associate the mobile station with an already available PPP connection. Loss of R-P state information results in the release of the PPP connection by the PDSN. As a result, a mobile station accessing packet data services following the loss of an R-P connection results in the establishment of a new PPP connection, and the reset and restart of user applications. Therefore, the PDSN retains the R-P connection state information to ensure minimal disruption of user applications during transitions between active and dormant session phases.
Note
PPP Connections
A PPP connection represents the link layer connectivity between the mobile station and the PDSN. It includes the HDLC state, negotiated LCP parameters, negotiated IP address and CCP compression state tables, etc. Peer PPP entities may re-negotiate LCP and CCP parameters during an active session without compromising continuity of user sessions; however, user identity, authentication-related information and negotiated IP addresses are retained, thus ensuring that applications established over the SimpleIP flow are unaware that renegotiation has occurred. PPP connection state information is retained at the PDSN during dormant phase of the session to ensure minimal disruption of user applications during transitions between active and dormant session phases.
Application Flows
One Simple IP and several Mobile IP flow instances can be supported over a single PPP connection. For each Simple IP flow, the state information includes the associated IP address, NAI and billing related user data records (UDRs), and other related information. For each Mobile IP flow, the state information includes the Mobile IP visitor list information, NAI and UDRs, and other related information.
Closed-RP/Open-RP Integration
Cisco PDSN Release 3.0 introduces the Closed-RP and Open-RP Integration feature, which includes the following details:
•
•
Handoff between Closed-RP and Open-RP
PDSN instance will be able to handoff the session between the Closed-RP and Open-RP PCF. During the handoff the PDSN will not re-negotiate the PPP for the session. Also in the accounting records for a Closed-RP PCF only the relevant parameters that are supported in the Closed-RP architecture are sent. For the Open-RP PCF all the 3GPP2 supported accounting parameters will be included records to the RADIUS.
Closed-RP/Open-RP Clustering Architecture
The controller module in the Open-RP clustering architecture supports Closed-RP clustering. In the dual mode, the controller module accepts Closed-RP connections from the Closed-RP PCF, and terminates the connection locally. After it successfully terminates the Closed-RP connection, the controller performs L2TP Tunnel switching on the session to one of the members. The following call control and call management capabilities of the Closed RP signaling interface are supported on the controller:
•
•
•
•
•
Closed-RP Tunnel Setup Procedures
The PCF establishes a Closed RP tunnel when it is brought into service, and PDSN IP addresses are statistically configured on it. PCF establishes a tunnel with each PDSN controller for which it has an IP address.
The following L2TP control messages are required to setup the tunnel in a Controller Closed RP Tunnel Setup
Step 1
Step 2
Step 3
Step 4
Closed RP Tunnel Clearing Procedures
Tunnel clearing can be initiated by the PDSN (Controller / Member) or by Closed RP PCF by sending a Stop Control Connection Notification Message, and ZLB is sent to Ack the message. The PDSN can be configured to initiate the Tunnel termination in the following scenarios
•
•
Here is the Controller Closed RP Tunnel Clearing message flow:
Step 1
Step 2
Closed RP Connection Setup Procedures
The following message flow depicts the Controller Closed RP Connection Setup:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
Step 13
Note
Note
Both 3GPP2 RP and Closed RP share a common MSID to the PDSN member table on the PDSN controller. This enables the PDSN controller to select the same PDSN member during the handoff between the RP technologies.
Closed RP Connection Release Procedure
The following message flow depicts the Controller Closed RP Connection Release procedure:
Step 1
Step 2
Closed RP and Open RP Handoff Procedures
The following message flow depicts the Controller Closed RP Handoff Closed to Open RP PCF procedure:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
Step 13
Step 14
Step 15
Step 16
Step 17
Step 18
Step 19
Step 20
Step 21
The following message flow depicts the Controller Closed RP Handoff Open to Close RP PCF procedure:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
Step 13
Step 14
Step 15
Step 16
Step 17
Step 18
Step 19
Step 20
Step 21
The following message flow depicts the Controller Closed RP Handoff Closed to Closed RP PCF procedure:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
Step 13
Step 14
Step 15
Step 16
Step 17
Step 18
Step 19
Step 20
Step 21
Step 22
Step 23
Step 24
Step 25
Performance
In the solution controller that anchors the Closed RP session from the PCF, and does L2TP switching of these sessions to the PDSN member, the following performance measurements were found:
•
•
•
Mobility Management With Closed-RP
An important aspect of packet data services is mobility management. A user should be able to maintain an established service even when roaming within and beyond their service provider's coverage area. For such mobility management, the system supports handoffs that are transparent to user applications.
Handoffs
Handoffs occur as a result of user mobility. A CDMA2000 system supports three types of handoffs:
•
This type of handoff occurs when the mobile moves from one BTS coverage area to another BTS coverage area, generally within a BSC/PCF area. This type of handoff is not visible to the PDSN and is not discussed further.
•
This type of handoff occurs when the mobile moves from the radio coverage area served by one BSC/PCF to a coverage area served by a different BSC/PCF, both connected to the same MSC. In this case, the new PCF can often connect to the same PDSN as the old PCF. However, this is not guaranteed.
When a mobile with an active data session hands off from one PCF to another PCF, the target PCF sends an ICRQ with Session Inquiry AVP to all the PDSNs it is connected with. The PDSN that has the PPP session for the Mobile Node replies with ICRP and terminates the RP session with the Source PCF by sending a CDN with Cause Value 253. If none of the PDSNs, connected with the Target PCF has the PPP session for the Mobile Node, the PCF chooses the least loaded PDSN and proceeds with Call Setup.
•
This type of handoff occurs when the mobile moves from the radio coverage area served by one BSC/PCF to a coverage area served by a different BSC/PCF and the new BSC/PCF is connected to a different MSC than the old BSC/PCF. In this case, the new and old PCFs are typically unable to connect to the same PDSN.
This scenario is possible when the mobile moves to a different radio coverage area and the new BSC/PCF connects to a different MSC than the original BSC/PCF. In this case, it is unlikely that the same PDSN will be used. This results in Inter-PCF and Inter-PDSN handoff.
When the target PCF learns that none of the PDSNs host the packet data session for the MN, the least loaded PDSN is selected and the session is set up using the same steps followed in initial call setup. This scenario is same as the new Closed RP connection setup.
IOS-SLB on the Supervisor card
One aspect of the Closed-RP feature requires that you configure Server Load Balancing on the Cisco Supervisor card. IOS-SLB on the Supervisor card provides loadbalancing for the Closed RP Tunnels between the PCFs and PDSNs. The Loadbalancing unit will direct the Closed RP tunnel to the appropriate PDSN instance. The IOS-SLB unit supports redundancy, so that there is no single point of failure for this system. Figure 6 illustrates this configuration.
Figure 6 Closed-RP Server Load Balancing Configuration
PPPoGRE RP Interface
The PDSN interfaces with the Radio Network/Base Station to provide a transmission path for the user data stream between the packet network and the radio access network. The PDSN interfaces to the Radio Network through the Packet Control Function (PCF) using the PPPoGRE RP interface.
The following list describes the transmission path between the Radio Network and the PDSN:
•
•
The PPPoGRE RP interface is based on 3GPP2 TIA/EIA/IS-835 standard for the control and bearer data transport capabilities. The following list describes the differences between the 3GPP2 standard and PPPoGRE RP Interface from the PDSN perspective:
•
•
•
A11 Session Update
This feature is based on Interoperability Specification (IOS) for cdma2000 Access Network Interfaces (Part 7 (A10 and A11 Interfaces) (3G-IOSv4.3) Version 2.0.1 Date: July 2003) and Interoperability Specification (IOS) for cdma2000 Access Network Interfaces (Part 3 Features (3G-IOSv4.3) Version 2.0.1 Date: July 2003 standard). An A11 Session Update message is sent from the PDSN to the PCF to add, change, or update session parameters for an A10 connection. The following parameters are sent from the PDSN to PCF in an A11 Session Update message in a session parameters NVSE extension with Application Type 08H (Session Parameter). These session parameters NVSE extension will also be sent by the PDSN in the A11 Registration Reply messages.
•
–
–
•
–
–
As per the standard cdma2000® Wireless IP Network Standard TIA-835-C, AUGUST 2003, the PDSN will download the Always On Indicator VSA and RN-PDIT VSA from the Radius server (Visited/Home RADIUS) during the authentication phase. If a user initiates multiple packet data sessions, the PDSN may receive more than one RN PDIT VSA from different home domains. In this case, the largest RN PDIT value received from different home domains is sent from the PDSN to the RN. This update may happen during an ongoing packet data session when the PDSN receives a new RN PDIT value that is greater than the one previously sent to the RN. For Handoff scenario the RN-PDIT and Always-On indicator are sent the PCF in the A11 Registration Reply if the Airlink is not dormant.
SDB Indicator Marking
This feature supports short data burst (SDB) applications, such as SIP signaling for PTT applications, and proposes the interaction with the PDSN. SIP is used by PTT applications to signal a PTT call. The message is short and needs to be delivered to the end-user. The Short Data Burst support on the RAN can be used to send these to the end-user, especially when the messages are to be terminated to the mobile. This is especially important when the mobile user is actually dormant.
The proposal consists of two parts:
•
•
Note
Signaling of SDB Indication
The SDB indication is based on the 3GPP2 Proposal Contribution (Ericsson/SKT) A30-20030818-006, where one of the reserved bits in the GRE header is used to indicate the SDB packets from the PDSN for dormant sessions. The PDSN definition of dormancy is Airlink Stop record A11 Registration request is received from the PCF and A11 Registration success reply is sent by the PDSN.
The PDSN may set the B bit to "1" if the GRE frame contains an IP packet suitable for transmission over the air interface in a Data Burst Message. In the PCF-to-PDSN direction, and on the A8 interface, the B bit is set to "0".
Identification of Data Packets For SDB Indication
SDB indication is required for certain types of data only. Packets destined towards the mobiles that match the policy criteria will be chosen for SDB indication provided the mobile is in dormant mode
The local policy can be considered for an initial phase, if the selection of servers or signaling protocols is limited. For example, if there is only a single SIP server sending out SIP signaling message, a combination of port and source IP address may be used. In addition to this, the PDSN can also be configured with the min and max IP length.
On a Cisco PDSN, IOS MQC can be used to apply classification rules for matching packets that require SDB classification. For example, simple classification criteria can include port number, and source IP address range of the server. A more complex classification criterion can include a custom protocol inspection.
If packets pass the classification criteria and the user is dormant, the PDSN will signal SDB indication to the PCF.
To enable this feature, use the following command:
cdma pdsn compliance ios4.1 sdb
This command enables the PDSN to process an SDB record sent from PCF according to IOS4.1 Standard.
If deep classification is required for certain types of payloads such as RTP, or a custom application, IOS NBAR can be used for inspecting these packets. For a detailed description of how to configure IOS NBAR please refer to the documentation on NBAR.
A sample configuration for the classification function is shown here:
class-map match-all sdb-packetsmatch packet length min 100 max 300match protocol <protocol>match access-group <access-group-number>ip access-list <access-group-number> permit ip 192.0.2.0 0.0.0.255 any(This example of access-list allows matching of a certain protocol from servers whose address range is 192.0.2.0/24)
The protocol and the access-group can be set to match the desired packet stream. The match criteria can also include a custom protocol inspection such as
ip nbar custom media_new 8 hex 0x60 dest udp 3001
The above statement classifies all packets with a UDP destination of port 3001, and contains the value 0x60 at offset 8. The protocol media_new can now be used in the match protocol protocol statement.
policy-map sdb-policyclass sdb-packetsset qos-group group-numberThe policy map is then applied to the input interface. The group-number represents the classified match criteria. All packets that are set with the specific group-number will be flagged for SDB usage between the PCF and the PDSN. This is done with the following command:
cdma pdsn a11 dormant sdb-indication gre-flags group-number
The B bit (SDB indication) would be set for packets matching the sdb-indication group-number.
SDB Indicator Marking for PPP Control Packets
While data packets can be sent towards the mobile using SDBs as shown above, SDBs can also be used for delivering PPP control packets. This can be particularly helpful for Always-On sessions, where the session is dormant. Basically, with Always On configured, the PDSN sends out LCP echo requests (and waits for LCP echo replies) to keep the session alive. Hence, when such a session goes dormant, a data channel needs to be setup to deliver these LCP echo requests to the MN. The other option is to use SDBs to deliver the LCP echo requests without setting up a data channel.
Configure the following CLI in conjunction of the above CLIs to enable this feature:
cdma pdsn a11 dormant sdb-indication match-qos-group group-number ppp-ctrl-pkts
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:
•
•
While resource management based on Packet of Disconnect is applicable to Simple IP, Mobile IP and Proxy Mobile IP flows, resource management based on Mobile IP Resource revocation is applicable only to Mobile IP flows.
The Cisco PDSN supports resource management based on both Packet of Disconnect and Mobile IP resource revocation.
Resource Revocation for Mobile IP
Basic Mobile IP resource revocation is an IS-835-C initiative that defines the methods by which a mobility agent (one that provides Mobile IP services to a mobile node) can notify the other mobility agent of the termination of a registration due to administrative reasons or MIP handoff.
When configured on the PDSN/FA, the Mobility Agent Advertisement extension in the Agent advertisement will have the X bit set, thus advertising support for resource revocation on that link. A PDSN configured to support resource revocation in Mobile IPv4 will include a revocation support extension in all MIP RRQ including re-registrations. If the associated MIP RRP from the HA also includes a valid revocation support extension, then the PDSN will assume the associated registration as revocable.
For a registration that is revocable, if the PDSN/FA needs to terminate the session administratively, the PDSN/FA sends a resource revocation message to the HA and releases the resources held for that registration.
If the resource revocation ACK from the HA is not received within a configurable amount of time, the resource revocation message will be retransmitted.
On receipt of a resource revocation message from Home Agent, and a registration (identified by the home address, care-of address, and Home Agent address) is located, the resources held by that registration are freed, and a resource revocation ACK message is sent back to the Home Agent. If no other Mobile IP registrations are active on the PPP session associated with the revoked binding, then the PDSN will release the associated PPP and R-P sessions for the revoked registration.
Restrictions for Registration Revocation
The following restrictions for Registration Revocation on the PDSN apply:
•
•
•
•
•
•
Packet of Disconnect
Radius Disconnect, or Packet of Disconnect (PoD) is a mechanism that allows the RADIUS server to send a Radius Disconnect Message to the PDSN to release Session related resources. Resources may be released due to the session handoff, or for administrative purposes. Some of the resources identified include PPP, RP sessions and Mobile IP bindings. Support for Radius Disconnect on the Cisco PDSN and Home Agent is TIA835C compliant.
The PDSN communicates its Resource management capabilities to the Home AAA in the Access Request message (sent for authentication/authorization procedure) by including a 3GPP2 Vendor Specific Session Termination Capability (STC) VSA. The value communicated in the STC VSA is obtained in the configuration. The PDSN also includes an NAS-Identifier attribute containing its Fully Qualified Domain Name (FQDN) in the Access Request.
The Home AAA server establishes a relationship between the user and the NAS Identifier/ NAS-IP address to detect a inter-PDSN handoff. If the NAS-Identifier/ NAS IP address received in the Access Request is different from the previously stored value (non-zero), an inter-PDSN handoff is detected.
The Disconnect Request contains the NAS-ID and the Username (NAI) attributes. It can optionally contain 3GPP2 Correlation ID Calling station ID (IMSI) and the Framed IP address—some session identification attributes. A Disconnect Reason VSA is included if a inter-PDSN handoff is detected. The session identification attributes supported by the PDSN are 3GPP2 Correlation ID and Calling station ID (IMSI).
If the 3GPP2 Correlation ID and Calling station ID (IMSI) attributes are received in the Disconnect Request, and the PDSN is able to find the session/flow corresponding to them, the PDSN will terminate the associated flow and send a Disconnect ACK message to RADIUS server. If session is not found for the received attributes, the PDSN will reply back with a Disconnect NACK message with error code "session context not found". If the Disconnect request has invalid attributes (for example, an 8 digit IMSI), the PDSN will reply with a Disconnect NACK with error code "Invalid Request".
The PDSN also supports processing Disconnect Requests that only contain the NAI attribute (if configured). In compliance with the standards, the PDSN terminates all sessions corresponding to the Username received.
The Ballot version mentions that a Disconnect Request can be received at the Home Agent (HA,) but details on the action to be taken in such an event is not detailed. Hence the approach followed is to terminate a specific binding if Framed-IP-Address attribute is received along with NAI, or terminate all bindings for the NAI, if only NAI attribute is received in the Disconnect Request.
The following restriction is present for this feature:
•
The command line interface for this feature will be standard AAA interfaces. The preferred method to configure POD in Release 2.0 and above is to use the aaa server radius dynamic-author command, which leads to a sub-configuration mode that has options to configure clients, security keys, and other variables.
The following NAS global AAA command is used to enable listening for POD packets:
•
The full syntax for this command is:
•
The following debug command is also available:
•
Restrictions for RADIUS Disconnect
•
•
•
Radius Enhancements
PDSN R3.0 includes the following RADIUS enhancements:
•
•
Radius Server Load Balancing
The RADIUS Load-Balancing feature is a mechanism to share the load of RADIUS Authentication and Accounting transactions across a set of RADIUS servers. Currently, all transactions are sent to the first server considered to be alive in a server group. Only when this server stops responding and is marked dead, the PDSN fails over to the next one in the group. This mechanism of using only one server despite the presence of other usable servers in the group limits the overall throughput for call setup/teardown.
Thus, with Radius Server Load Balancing, the PDSN distributes the transaction load across multiple servers in a server group. It tracks the slower servers and reduces the transaction load on those servers and it adapts when a server is marked dead and when it comes back up again.
The transactions are grouped into batches (the size of which is configurable), and each server is assigned a batch to process. The feature then load-balances transactions based on these batches, one batch at a time. When the first transaction is received, the algorithm determines the server with the least outstanding transactions. This server is then assigned the next batch of transactions. Once a batch of transactions has been assigned, we again compute the server with the least outstanding transactions. This server gets assigned the next batch of transactions. Thus the server with the least outstanding transactions always gets assigned the next batch. This load-balancing scheme can be applied based on a server group. Thus, each server group defined on the IOS platform can have its own load-balancing scheme.
Care should be taken while configuring the batch size. The trade-off in large versus a small batch size is that of throughput versus CPU load. A large batch size results in lesser amount of computations hence a lower CPU load. However, it may cause a particular server within the server-group to be assigned transactions even though others in the group are idle. For very small batch sizes, the CPU load increases, as it computes outstanding load across servers more often. Lab simulations indicate that a batch size of 25 gives a decent throughput while not adversely affecting CPU load.
High Latency RADIUS servers
The algorithm adapts well to servers of varying response times. Servers that are quick will have a lower number of transactions outstanding and hence will be assigned larger number of the incoming transactions. Slower servers get proportionately lesser number of transactions.
Server Failovers
When a transaction fails over to the next server in the group after a failover, its outstanding count will be increased. Thus, failed-over transactions are also load-balanced. When the next batch of transactions is being assigned, this server's outstanding count will reflect it's load accurately - both new and failover transactions will be accounted for in the outstanding transaction count.
Dealing with Server Groups
Consider the following two server-groups:
Server-group SG1 with servers S1, S2, S3.
Server-group SG2 with servers S3, S4, S5.
Consider that SG1 is configured to be load-balanced, while SG2 is not. When requests are sent to SG2, these requests will be assigned to S3 as it is the first server in the group and its outstanding transaction count will increase. When requests are sent to SG1, these requests will be load-balanced across these servers. When sending transactions to S3, the outstanding transaction count for the server will be high due to the SG2 transactions being assigned directly to it. Hence it will receive a low proportion of transactions in SG1. This is the preferred behavior, since the goal is to send transactions to servers that are quicker and able to handle more load, where load is the total transactions a server is handling, not just those of the current server-group.
Preferred Servers
In certain cases, it is desirable to use the same server for the authentication and accounting phases of a session. With RADIUS server load balancing, however, there are no guarantees that the stop-record for a session will be sent to the same server as the start-record for that session. To avoid such situations a preferred-server indication is introduced in Release 3.0.
Note
The PDSN will try to use the server if possible, but if not, it will fall back to other servers in the group based on the load-balancing mechanism.
When this indicator is used, costs will not be considered in deciding the server to use. However, it might not be possible to always use the preferred server. The server may have been marked dead. Or the server may not be usable since it isn't part of the server-group that was used for a previous transaction for the session (for example, the Accounting server-group may be different from the authentication server-group). In this case, the algorithm is free to select an alternate server, based on the load-balancing scheme.
Incoming RADIUS requests
The RADIUS server load balancing feature is not applicable to incoming RADIUS requests (e.g. Packet of Disconnect). POD responses require that the server requesting service be the one that is responded too. Hence we shouldn't load-balance these requests across servers.
Subscriber Authorization Based on Domain
Cisco IOS provides a "Subscriber Authorization" mechanism to authorize subscribers based on their realm. You can find details of this feature at the following URL:
http://www.cisco.com/en/US/partner/products/ps6350/products_configuration_guide_chapter09186a0080455cf0.html#wp1056463
IS-835 Prepaid Support
The Cisco PDSN 2.0 software release provides real-time monitoring and rating of data calls for prepaid users. The prepaid billing solution for the PDSN is based on the RADIUS (AAA) server, and takes advantage of the existing flow-based accounting functionality. The prepaid billing feature requires the RADIUS server to interface with a Prepaid Billing Server (PBS) to relay real-time billing information between the PDSN and the PBS. A third-party Prepaid Billing Server controls the real-time rating of data calls and maintains balances in users' accounts. Cisco does not supply the PBS.
The following three types of Prepaid service are available in PDSN Release 2.1:
•
•
•
Prepaid functionality is supported on PDSN for the following type of data sessions:
•
•
•
•
Prepaid service is also available for sessions opened with MSID-based authentication access.
Note
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:
•
•
Restrictions for Prepaid Support in Cisco PDSN Release 2.1
•
•
•
•
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:
•
•
•
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 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
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:
•
–
–
–
•
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
Step 4
–
–
–
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 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:
–
–
–
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
Step 7
•
•
In this case, PDSN sends an Access-Request message containing the PPAQ VSA that includes:
–
–
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
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 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
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:
•
•
•
A PPAC VSA that indicates prepaid service is based on Volume.
For duration based Prepaid packet data service, the Event_Time attribute is used for DurationQuota/DurationThreshold allocation by the Billing Server.
After the PDSN receives the Access-Accept message from AAA, it parses the RADIUS packet and retrieves the attributes inside it. The PDSN stores information in the packet regarding the quota allocated for the flow, and threshold corresponding to the allocated flow. It also stores the Quota-ID allocated corresponding to the quota.
Once the flow for the user comes up (for example, an IP address assigned for Simple IP or MIP RRP received from the HA and sent to the MS), the PDSN starts the timer corresponding to the duration threshold value and duration quota value.
Once the timer expires for the threshold value of the allocated quota for the prepaid flow, the PDSN sends an Access-Request Message to AAA to refresh quota for the prepaid flow. This Access Request message contains a PPAQ VSA, which includes following parameters:
•
•
•
The HAAA authorizes the RADIUS packet and, if successful, forwards the prepaid-related information in the packet to the Billing Server.
Step 3
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:
•
•
•
After the PDSN receives the Access-Accept message from the AAA, it parses the RADIUS packet and retrieves the attributes inside it. The PDSN stores the information in the packet, updates it with the quota allocated for the flow and the current threshold value corresponding to the allocated flow. The PDSN restarts the duration quota timer with the new value received in the Accept-Accept message, and starts the threshold timer with the new threshold value received corresponding to the current quota. It also stores the new Quota-ID allocated for the current quota.
Step 4
•
•
If this event occurs, the PDSN sends an Access-Request message containing the PPAQ VSA that includes:
–
–
The PDSN marks the prepaid flow for deletion, and does not switch any packets through it for the prepaid flow. The PDSN does not delete the prepaid flow immediately, and waits for the response of the Access-Request or timeout of the Access-Request message.
Step 5
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:
•
•
•
The following sequence describes the functionality of Prepaid data service when Tariff Switching is enabled.
Step 1
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
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:
•
–
–
–
•
–
–
–
•
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
Step 4
•
•
•
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 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:
•
•
•
The Attributes encapsulated inside PTS attribute includes:
•
•
•
After the PDSN receives the Access-Accept message from AAA, it parses the RADIUS packet and retrieves the attributes inside it. It stores the information present in the packet updating with the quota allocated for the flow and the current threshold value corresponding to the allocated flow. It also stores the new Quota-ID allocated for the current quota.
Additionally, the PDSN re-starts the timer indicated in TariffSwitchInterval attribute. This time indicates the time remaining in seconds before the next tariff switch condition will be hit.
Step 6
Step 7
Step 8
Step 9
•
•
•
The PTS attribute contains following subtypes:
–
–
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:
•
•
•
The PTS attribute contains following subtypes:
–
–
–
After the PDSN receives the Access-Accept message from AAA, it parses the RADIUS packet and retrieves the attributes inside it. The PDSN stores the information present in the packet, and updates it with the quota allocated for the flow and the current threshold value corresponding to the allocated flow. It also stores the new Quota-ID allocated for the current quota.
Additionally, the PDSN re-starts the timer indicated in TariffSwitchInterval attribute. The PDSN starts the timer only if the timestamp of the Access Request + Tariff Switch Interval is more than the timestamp of the Access Accept message. This time indicates the time remaining in seconds before the next tariff switch condition will be hit.
Support for G17 Attribute in Acct-Stop and Interim Records
The G17 attribute is required to bill users based on when the last activity was detected rather than when the user is de-registered. The following scenario gives a brief on how the attribute is used and how AAA needs to identify the last user activity.
G17 is defined as last user activity to indicate the time when the last activity was detected by the user. The G17 attribute is sent in acct-stop and interim accounting update messages, and has the following usage guidelines:
•
•
•
•
•
The G17 attribute is useful under the following conditions:
•
–
–
–
•
–
–
–
Mobile IP Call Processing Per Second Improvements
In previous Cisco PDSN Releases, the Mobile IP CPS rate was approximately 40—comparatively low to that of Simple IP CPS which around 125. Mobile IP CPS was low because some of the Mobile IP configurations are interface specific. When these configurations are applied to the virtual-template interface (which is typical for the PDSN software), it takes considerable time to clone the virtual-access from the Virtual-Template because of the presence of the Mobile IP configuration, and this directly affects the CPS for Mobile IP service. The virtual-access are cloned when the calls are setup. To reduce virtual-access cloning time, PDSN Release 2.1 supports commonly used per-interface configurations in global configuration mode, and supports per-interface for backward compatibility.
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:
•
•
•
Note
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.1 supports the following values:
•
•
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:
•
•
•
•
•
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:
•
•
•
•
•
•
•
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:
•
•
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
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:
•
•
•
•
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.
•
•
–
Note
•
–
In order to configure an ODAP subnet pool for Mobile IP PDSN applications, determine the number IP addresses needed for each PDSN. Use the following formula to determine the Mobile IP pool size:
•
Always On Feature
The PDSN supports Always On service to maintain the subscriber's packet data session in the local network. Always On support dictates that the PDSN will not release a subscriber's packet data session due to PPP idle timer expiry unless the PDSN determines the user is no longer reachable.
The Always On service maintains a subscriber's packet data session irrespective of PPP inactivity timer value for the user. At the same time, by making use of a finite PPP inactivity timer value, this feature provides a way to keep a session only as long as the user is reachable. The PDSN uses LCP Echos (as per rfc1661 and IS835B) to determine if the user is reachable.
Always On service is enabled for a user only when the F15 "Always On" attribute is received and set to a value of 1 in the access accept message from the AAA server.
The PDSN supports the ability to configure the Echo-Reply-Timeout timer and Echo-Request-Attempts counter. There is no extra configuration required on the PDSN to enable the Always On feature itself; however, you can disable the feature by configuring the Echo-Request-Attempts to 0. The PPP inactivity timer will be started for a session entering IPCP open state, if is configured or retrieved from AAA, for the user.
For always on users:
1.
2.
3.
4.
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:
•
•
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.
•
•
•
NPE-G1 Platform Support
PDSN Release 2.0 and above, 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.
The supported configuration on a Cisco 7206VXR NPE-G1 processor is with 1Gigabyte of DRAM and one PA-2FE-TX FE port adaptor. The Cisco 7206VXR NPE-G1 processor has three 10/100/1000 based Ethernet Ports.
For IPSec support, a service adaptor SA-VAM2 is required.
PDSN MIB Enhancement
The following sub-sections highlight the MIBs that are added in R3.0:
PPP Counters in Release 3.0
Objects have been added under the following existing MIB subgroups:
•
•
•
•
•
The below table describes the list of PPP counters that have been added in R3.0.
RP Counters in Release 3.0
The following list identifies new MIB subgroups in Release 3.0:
•
•
•
•
•
•
•
•
The following list identifies existing MIB subgroups, under which objects are added:
•
•
•
•
•
Table 6 indicates the additional RP counters supported in Release 3.0:
The following MIB enhancements are included in the Cisco PDSN Release 2.1:
PPP Counter Objects have been added under the following existing MIB subgroups:
•
•
•
•
•
In PDSN Release 2.1 a new MIB CISCO-CDMA-PDSN-CRP-MIB is defined to reflect the support of Closed RP interface on PDSN.
The MIB has two groups, SystemInfo and PerPCF Stats. SystemInfo group has the system level info like Total number of Closed RP sessions while the PerPCF stats group details call management statistics per PCF.
CDMA PDSN System Information
ccpcEnabled OBJECT-TYPE
"An indication of whether Closed RP feature is enabled."
::= { ccpcSystemInfo 1 }
ccpcSessionTotal OBJECT-TYPE
"The total number of Closed RP sessions currently established with this system."
::= { ccpcSystemInfo 2 }
CDMA PDSN Closed RP Registration Statistics per PCF
The PDSN PCF table maintains reference about the PCF in the RAN currently interacting with the PDSN.
An entry is created when an L2TP tunnel is established with the PCF. An entry is deleted when the tunnel is deleted.
Statistics Objects maintained per PCF include the following:
ccpcPcfIpAddressType OBJECT-TYPE
"Represents the type of the address specified by ccpcPcfIpAddress."
::= { ccpcPcfPerfStatsEntry 1 }
ccpcPcfIpAddress OBJECT-TYPE
"The IP address of the PCF that serves the mobile node."
::= { ccpcPcfPerfStatsEntry 2 }
ccpcPcfRcvdIcrqs OBJECT-TYPE
"Total number of Incoming-Call-Requests received to establish a L2TP session since the L2TP tunnel was established with PCF."
::= { ccpcPcfPerfStatsEntry 3 }
ccpcPcfAcptdIcrqs OBJECT-TYPE
"Total number of Incoming-Call-Requests accepted since the L2TP tunnel was established with PCF."
::= { ccpcPcfPerfStatsEntry 4 }
ccpcPcfDroppedIcrqs OBJECT-TYPE
"Total number of Incoming-Call-Requests denied since the L2TP tunnel was established with PCF."
::= { ccpcPcfPerfStatsEntry 5 }
ccpcPcfSentIcrps OBJECT-TYPE
"Total number of Incoming-Call-Replies sent since the L2TP tunnel was established with PCF."
::= { ccpcPcfPerfStatsEntry 6 }
ccpcPcfRcvdIccns OBJECT-TYPE
"Total number of Incoming-Call-Connected messages received since the L2TP tunnel was established with PCF."
::= { ccpcPcfPerfStatsEntry 7 }
ccpcPcfAcptdIccns OBJECT-TYPE
"Total number of Incoming-Call-Connected messages accepted since the L2TP tunnel was established with PCF."
::= { ccpcPcfPerfStatsEntry 8 }
ccpcPcfDroppedIccns OBJECT-TYPE
"Total number of Incoming-Call-Connected messages accepted since the L2TP tunnel was established with PCF."
::= { ccpcPcfPerfStatsEntry 9 }
ccpcPcfRcvdCdns OBJECT-TYPE
"Total number of Call-Disconnect-Notify messages received to tear down L2TP session since the L2TP tunnel was established with PCF."
::= { ccpcPcfPerfStatsEntry 10 }
ccpcPcfSentCdns OBJECT-TYPE
"Total number of Call-Disconnect-Notify messages sent to PCF to tear down L2TP session since the L2TP tunnel was established with PCF."
::= { ccpcPcfPerfStatsEntry 11 }
ccpcPcfDroppedCdns OBJECT-TYPE
"Total number of Call-Disconnect-Notify messages dropped since the L2TP tunnel was established with PCF."
::= { ccpcPcfPerfStatsEntry 12 }
ccpcPcfRcvdZlbs OBJECT-TYPE
"Total number of Zero-Length-Buffer messages received since the L2TP tunnel was established with PCF."
::= { ccpcPcfPerfStatsEntry 13 }
ccpcPcfSentZlbs OBJECT-TYPE
"Total number of Zero-Length-Buffer messages sent since the L2TP tunnel was established with PCF."
::= { ccpcPcfPerfStatsEntry 14 }
In PDSN Release 2.0 and above, the MIB CISCO-CDMA-PDSN-MIB module is modified to provide the following statistics by PCF plus Service Option:
•
•
•
PCF/Service Option-based RP Statistics
In Release 1.2, the PDSN MIB provided RP registration statistics that offer box level information. These statistics are defined under the group "cCdmaRpRegStats." In Release 2.0 and above, in addition to box level information, the PCF/SO-based RP statistics will also be provided, and the MIB objects pertaining to these statistics is defined under the following group:
cCdmaPcfSoRpRegStats OBJECT IDENTIFIER
::= { cCdmaPerformanceStats 10 }
PCF/Service Option-based RP Update Statistics
The Release 1.2 MIB provides RP update statistics at box level; the MIB objects pertaining to these statistics are defined under the group cCdmaRpUpdStats. In addition to these statistics, the Release 2.0 MIB will provide PCF/SO based RP update statistics. These new MIB objects are defined under the following group.
cCdmaPcfSoRpUpdStats OBJECT IDENTIFIER
::= { cCdmaPerformanceStats 11 }
PCF/Service Option-based PPP Statistics
In Release 1.2, the MIB objected defined under the group "cCdmaPppStats" provides box level information about PPP negotiation between the PDSN and the MN. In Release 2.0, the MIB will provide the following PPP stats based on PCF/SO.
cCdmaPcfSoPppCurrentConns,
cCdmaPcfSoPppConnInitiateReqs,
cCdmaPcfSoPppConnSuccesses,
cCdmaPcfSoPppConnFails,
cCdmaPcfSoPppConnAborts
These objects are grouped under the following MIB group.
cCdmaPcfSoPppSetupStats OBJECT IDENTIFIER
::= { cCdmaPerformanceStats 12 }
As with previous releases, you can manage the Cisco PDSN with Cisco Works 2000 network management system using SNMP. In addition to the standard 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:
•
–
–
–
–
–
•
–
–
Cisco Proprietary Prepaid Billing
PDSN Release 2.1 supports Cisco's proprietary prepaid billing features, that provide the following services:
•
•
•
Figure 7 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 7 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 on page 5.
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
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
Step 13
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
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
Step 13
Step 14
Step 15
Note
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
Note
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:
•
•
•
Note
Hardware IPSec Acceleration Using IPSec Acceleration Module—Static IPSec
Note
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 8 illustrates the IS-835-B IPSec network topology.
Figure 8 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
Conditional Debugging Enhancements
Trace Functionality in Release 3.0
While conditional debugging has been a useful tool to limit the displayed debugs to a particular user, the output can still be a bit misleading if a few users are traced together. Therefore, the following capabilities are added in R3.0:
•
–
–
–
–
–
–
–
–
–
–
–
•
Note
Note
Note
Note
