Table Of Contents
Cisco Packet Data Serving Node (PDSN) Release 2.1
PMTU Discovery by Mobile IP Client
Features From Previous Releases
Protocol Layering and RP Connections
Closed RP Interface Connections
Closed RP Tunnel Setup Procedures
Closed RP Tunnel Clearing Procedures
Closed RP Connection Setup Procedures
Closed RP Connection Release Procedures
Mobility Management With Closed-RP
IOS-SLB on the Supervisor card
Identification of Data Packets For SDB Indication
Resource Revocation for Mobile IP
Volume-based Prepaid Data Service Flow
Duration-based Prepaid Data Service Flow
Volume-based Prepaid Data Service with Tariff Switching
Mobile IP Call Processing Per Second Improvements
IS-835-B Compliant Static IPSec
Configuring IPSec in Cisco IOS
On-Demand Address Pools (ODAP)
PDSN Cluster Controller / Member Architecture
Upgrading the Controller PDSN Software from R1.2 to R2.0
Upgrading the Member PDSN Software from R1.2 to R2.0 and Above
Cisco Proprietary Prepaid Billing
Hardware IPSec Acceleration Using IPSec Acceleration Module—Static IPSec
Conditional Debugging Enhancements
Electronic Serial Number (ESN) in Billing
Features Available From Previous PDSN Releases
PDSN Clustering Peer-to-Peer and Controller / Member Architecture
Intelligent PDSN Selection and Load Balancing (Peer-to-Peer)
Related Features and Technologies
Supported Standards, MIBs, and RFCs
Creating the CDMA Ix Interface
Creating a Virtual Template Interface and Associating It With the PDSN Application
Enabling R-P Interface Signaling
Configuring User Session Parameters
Configuring AAA in the PDSN Environment
Configuring RADIUS in the PDSN Environment
Configuring Prepaid in the PDSN Environment
Enabling VPDN in a PDSN Environment
Configuring IS835-B IPSec for the Cisco PDSN
Configuring Proxy Mobile IP Attributes Locally
Configuring Mobile IP Security Associations
Configuring PDSN Cluster Controller
Configuring PDSN Cluster Member
Configuring Peer-to-Peer PDSN Selection
Configuring A11 Session Updates
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
AAA Authentication and Authorization Profile
AAA Profiles for Various Service Types
Authentication and Authorization RADIUS Attributes
Accounting Services RADIUS Attributes
Mandatory AVPs in Connection Setup/Release Messages
Q.931 Cause Codes Used in Call Disconnect Notify Message
Cisco Packet Data Serving Node (PDSN) Release 2.1
Feature History
12.2(8)BY
This feature was introduced on the Cisco 7200 Series Router.
12.2(8)ZB
This feature was introduced on the Cisco Catalyst 6500 Switch.
12.2(8)ZB1
This feature was introduced on the Cisco 7600 Internet Router.
12.2(8)ZB5
Four new CLI commands were added.
12.2(8)ZB6
Two CLI commands were added or modified.
12.2(8)ZB7
Six CLI commands were added or modified.
12.2(8)ZB8
One new CLI command was added.
12.3(4)T
This feature was integrated into Cisco IOS Release 12.3(4)T.
12.3(8)XW
Release 2.0 of the Cisco Packet Data Serving Node (PDSN) software.
12.3(11)YF
Release 2.1 of the Cisco Packet Data Serving Node (PDSN) software. Four new features were added, including the Closed-RP Interface.
12.3(11)YF1
A restriction for Registration Revocation was removed.
New commands were added, including:
•
debug cdma pdsn radius disconnect nai
•
Existing commands were modified, including:
•
•
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
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
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 2.1, and functionality remains the same as on the Cisco 7200 platforms. The significant difference between the Cisco PDSN on the Cisco 7200 router and on the MWAM is that a Cisco Catalyst 6500 or Cisco 7600 chassis will support a maximum of 6 application modules. Each application module supports 5 IOS images, each with access to 512 Megabytes of RAM. Up to five of these images can function as a PDSN.
Additionally, instances of the cluster controller functionality will be configured as required. One active and one standby controller are required for a cluster of 48 PDSN instances or less. Each PDSN image supports 20,000 sessions. For every 10 PDSNs configured in the chassis, one active and one standby controller is required. Internal to the chassis, the PDSN images are configured on the same VLAN in order to support the Controller-Member architecture (although the architecture itself does not require this). Load balancing external to the chassis is determined by the physical proximity of the chassis and the network architecture. It is possible that you require both a VLAN approach, and a more traditional routed approach.
Features
New Features in This Release
This section describes the following key features of the Cisco PDSN Release 2.1:
•
Features From Previous Releases
This section lists features that were introduced prior to Cisco PDSN Release 2.1
•
•
•
•
•
•
•
•
•
•
•
Note
P indicates that this feature is only available with a Premium license.
* Requires appropriate hardware support.
Note
PDSN Performance Metrics
Cisco PDSN Release 2.1 delivers the following performance improvements compared to Release 1.2:
•
Performance metrics for the Cisco PDSN with Release 2.1 software on 7200 Platform are:
•
•
•
•
•
•
•
•
•
Performance Metrics on the Cisco 6500 and 7600 series platform are as follows. The quoted figures are per image, and each MWAM can support 5 PDSN images.
•
•
•
•
•
•
•
•
•
•
•
•
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.
Closed RP Interface Connections
The Closed RP Interface is an L2TP standard-based interface that establishes an L2TP Tunnel between the PCF and PDSN to carry signaling information and user traffic for Packet Data Services. The Closed R-P connection state information is maintained at the PDSN for the duration of the PPP connection. During handoff, the mobile station may connect to the PDSN through another Base Station/PCF entity (thereby establishing another R-P connection between the PDSN and the new Base Station/PCF). In this scenario, the R-P connection between the PDSN and the old Base Station/PCF is released. In the Closed RP interface, the PDSN has no knowledge of dormancy.
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, sser 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.
The Closed 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 using the Packet Control Function (PCF) through the Closed RP interface. This section describes the Closed RP interface in detail.
For the transmission path between the Radio Network and the PDSN, the following conditions are present:
•
•
The Closed RP interface is based on L2TP standard, but supports only Connection/Call Management aspects of that standard. The Closed RP interface definition extends the Call Management messages with some additional AVPs to provide bearer connection to Mobile Stations. The new AVPs include the following:
•
•
•
•
•
Supported call control and call management capabilities of the Closed RP signaling interface include the following:
•
•
•
•
•
Closed RP Tunnel Setup Procedures
The PCF initiates the establishment of a Closed RP tunnel when it is brought into service and PDSN IP addresses are statistically configured on it. The PCF establishes a tunnel with each PDSN for which it has an IP address.
The following L2TP control messages are required to set up the tunnel:
•
•
•
•
Closed RP Tunnel Clearing Procedures
Tunnel clearing can be initiated by the PDSN or PCF by sending a Stop Control Connection Notification Message and ZLB is sent to acknowledge the message.
The PDSN can be configured to initiate tunnel termination in the following scenarios:
•
•
Closed RP Connection Setup Procedures
When a mobile user initiates a packet data call by sending an IS-2000 origination message, normal voice service authentication procedures are followed for the subscriber, and a traffic channel is established with the mobile. After connection of Packet Data Service Option, RLP synchronization between the Mobile and the BS proceeds. The BS/PCF initiates a Closed RP connection setup by sending an ICRQ message to the PDSN. If the request is acceptable, the PDSN returns an ICRP message with an accept indication. The information elements carried in the setup messages are listed in Table 9.
Closed RP Connection Release Procedures
An active packet data session may be released by either the PDSN or PCF by sending a Call-Disconnect-Notify message with Session ID. The information elements carried in the disconnect messages are listed inTable 10.
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/PCFand 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. This section describes the Closed 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 shall 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 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.
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.
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 applicabled only to Mobile IP flows.
The Cisco PDSN supports resource management based on both Packet of Disconnect and Mobile IP resource revocation.
Resource Revocation for Mobile IP
Basic Mobile IP resource revocation is an IS-835-C initiative that defines the methods by which a mobility agent (one that provides Mobile IP services to a mobile node) can notify the other mobility agent of the termination of a registration due to administrative reasons or MIP handoff.
When configured on the PDSN/FA, the Mobility Agent Advertisement extension in the Agent advertisement will have the X bit set, thus advertising support for resource revocation on that link. A PDSN configured to support resource revocation in Mobile IPv4 will include a revocation support extension in all MIP RRQ including re-registrations. If the associated MIP RRP from the HA also includes a valid revocation support extension, then the PDSN will assume the associated registration as revocable.
For a registration that is revocable, if the PDSN/FA needs to terminate the session administratively, the PDSN/FA sends a resource revocation message to the HA and releases the resources held for that registration.
If the resource revocation ACK from the HA is not received within a configurable amount of time, the resource revocation message will be retransmitted.
On receipt of a resource revocation message from Home Agent, and a registration (identified by the home address, care-of address, and Home Agent address) is located, the resources held by that registration are freed, and a resource revocation ACK message is sent back to the Home Agent. If no other Mobile IP registrations are active on the PPP session associated with the revoked binding, then the PDSN will release the associated PPP and R-P sessions for the revoked registration.
Restrictions for Registration Revocation
The following restrictions for Registration Revocation on the PDSN apply:
•
•
•
•
•
•
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 prefered 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
•
•
•
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 Prepaid capable PDSN determines that Simple IP or Mobile IP setup requires a RADIUS Access-Request message to be sent to the Home RADIUS Server. For SIP sessions, user authentication has to be performed with AAA rather than local authentication. In the case of Mobile IP users, FA-CHAP is required for authentication.
The PDSN includes its own PPAC VSA to inform the HAAA/Billing Server that it supports Prepaid based on Duration (value = 2 or 3). If resource revocation is enabled on the PDSN, the PDSN will send a SessionTerminationCapability (STC) attribute indicating that it can support resource revocation for Mobile IP sessions. The Event_Time attribute (G4, value = 55) will be included in the RADIUS Access-Request message.
The Home RADIUS server performs the regular Authentication and Authorization of the Access Request sent by the user. If the user profile indicates the user is a Prepaid subscriber, the HAAA interfaces with the Billing Server and provides the Billing Server with the prepaid related info for the user as received in the Access Request message.
Step 2
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.
Step 3
•
•
•
The HAAA authorizes the RADIUS packet and, if successful, forwards the prepaid-related information in the packet to the Billing Server.
Step 4
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 5
•
•
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 6
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 recieves the Access-Accept message from AAA, it parses the RADIUS packet and retrieves the attributes inside it. It stores the information present in the packet updating with the quota allocated for the flow and the current threshold value corresponding to the allocated flow. It also stores the new Quota-ID allocated for the current quota.
Additionally, the PDSN re-starts the timer indicated in TariffSwitchInterval attribute. This time indicates the time remaining in seconds before the next tariff switch condition will be hit.
Step 6
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.
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 onthe PDSN to enable the Always On feature itself; however, you can disable the feature by configuring the Echo-Request-Attempts to 0. The PPP inactivity timer will be started for a session entering IPCP open state, if is configured or retrieved from AAA, for the user.
For always on users:
1.
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 Cluster Controller / Member Architecture
The PDSN Controller member architecture was designed to support 8 members with redundant Active/Standby controllers. This controller-member mode designates certain nodes as controllers responsible for performing PDSN selection, and for maintaining the global session tables. Each member node maintains information only about the sessions that are terminated on that node. Controllers can be redundant with all session information synchronized between them, and they monitor the state of all nodes to detect the failure of a member or another controller.
When a PDSN cluster operates in the controller-member mode, controllers are dedicated to the PDSN selection function, and do not terminate bearer sessions.
PDSN Release 2.1 supports the following enhancements:
•
•
•
•
When a Registration Request (RRQ) arrives from the PCF to the active controller, the controller uses the MSID as an index to look up the session-table. If a session record entry is present, the controller forwards the RRQ to the PDSN that hosts the session for the MSID. If the session entry is not present in the controller session-table, the controller chooses a member based on a configured selection algorithm, and replies to the PCF with an RRP that suggests the member IP address in the message.
When the session comes up, the member sends a Session-Up message from the member for that session (MSID) to the controller. On receipt of this message from the member, the controller creates the Session Record for that MSID in the controller to establish MSID-member association on the controller. On receipt of Session-Down message from member, the controller flushes the SessionRecord from the controller.
The controller does not create a Session Record for the MSID when it redirects the RRQ, but only on the receipt of a Session-Up message from the member on which the session has come up
To support a large number of members (28~48) per Controller, processing overhead is reduced when members send one bulk-update packet to the controller for every configured periodic update time interval with multiple pairs of Session-Up/Session-Down. The packet contains concatenated multiple MSIDs with one Session-Up/Session-Down flag, thereby saving bytes in the packet. The controller will process these bulk-update packets and send a bulk-update-ack packet to the members.
Conditional Debugging Support Under Clustering Feature
The Cisco PDSN 2.0 Clustering feature adds additional support for the conditional debugging with the following clustering debug command on both controller and member:
•
Note
For information on redundancy and load balancing in the PDSN Release 2.1, see the "PDSN Clustering Peer-to-Peer and Controller / Member Architecture" section.
Upgrading the Controller PDSN Software from R1.2 to R2.0
To upgrade the PDSN controller to Release 2.0, perform the following tasks:
Step 1
Step 2
# show cdma pdsn cluster controller configuration
Step 3
config# cdma pdsn cluster controller member periodic-update
Follow the same procedure as above to upgrade the other PDSN controller to Release 2.0.
Upgrading the Member PDSN Software from R1.2 to R2.0 and Above
To upgrade a member PDSN to Release 2.0 or 2.1, perform the following tasks:
Step 1
config# cdma pdsn cluster member prohibit administratively
The status of the member will be updated to the controller in a subsequent periodic keepalive reply message that the member sends to the controller. The controller, upon reception of this message, does not select this member for any of the new incoming calls.
Step 2
#show cluster controller member prohibited administratively
The calls, which are already connected to the member, will be alive until the mobile node disconnects the call. Alternatively, the calls can be forcibly cleared on the prohibited member using the following command:
#clear cdma pdsn session all
Step 3
config# no cdma pdsn cluster member prohibit administratively
Once the controller is updated with the status the new member PDSN will be selected for new incoming calls.
Step 4
config# cdma pdsn cluster member periodic-update 300
PDSN MIB Enhancement
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.
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
PDSN Release 2.1 supports additional conditional debugging for Mobile IP components. Mobile IP conditional debugging is supported based on NAI as well as the MN's home address.
Currently, when multiple conditional debugging is enabled, the debug output does not individually display the condition for which the debugs are printed for all the CDMA related debugs.
Check Condition
A condition is set using the debug condition username command.
Delete Condition
The debugging conditions can be removed using the following commands:
•
•
When a condition is removed using the above CLI, the IOS Conditional Debugging Subsystem, which maintains a list of conditions and the TRUE conditions, resets the flag. When all the conditions are removed, the debugging information will appear without any filter applied.
The PDSN software also utilizes conditional debugging based on the Mobile Subscriber ID (MSID) into the CDMA subsystem by using the existing IOS debug condition of the Cisco CLI. The calling option of the CLI is used to specify the MSID (for example, debug condition calling 00000000011124).
The following debug commands are supported for conditional debugging based on NAI. The NAI is a name like foo@bar.com.
•
•
•
The following debug commands are not impacted by NAI-based conditional debugging:
•
•
This release provides conditional debugging support for the following PDSN CLI commands:
•
•
•
•
•
The a11 debugs additionally support msid-based debugging using the following individual CLI commands:
•
•
•
Conditional debugging is an IOS feature, and the following CLI are available across all images.
router# debug condition ?application Applicationcalled called numbercalling callingglbp interface groupinterface interfaceip IP addressmac-address MAC addressmatch-list apply the match-liststandby interface groupusername usernamevcid VC IDThe options calling, username, and ip are used by the CDMA/Mobile IP subsystems.
PDSN#debug condition username ?WORD Username for debug filteringPDSN#debu condition calling ?WORD Calling numberPDSN#debu condition ip ?A.B.C.D IP addressRefer to the debug commands in the Command Reference for more information about conditional debugging in PDSN Release 2.1.
Electronic Serial Number (ESN) in Billing
The ESN is a unique identifier for a piece of equipment, such as of a mobile device, and is used during the authentication process. The ESN is parameter a2 of the R-P Session Setup airlink record, and parameter A2 in the PDSN Usage Data Record (UDR). Both parameters are introduced in this release.
The PDSN accepts the parameter a2, and puts it as A2 into a User Data Record.
This feature is supported in the Cisco Access Registrar.
1xEV-DO Support
The Cisco PDSN supports Evolution-Data Optimized (1xEV-DO). 1xEV-DO offers high performance, high-speed, high-capacity wireless Internet connectivity, and is optimized for packet data services. It can transport packet data traffic at forward peak rates of 2.4 Mbps, which is much higher than the current 1xRTT peak rate of 144 kbps.
PDSN support for 1xEV-DO technology includes the following enhancements:
•
•
Features Available From Previous PDSN Releases
The following features were introduced in previous PDSN software releases, and are still supported in Release 2.0.
Integrated Foreign Agent (FA)
The FA is an essential component to mobility, because it allows a mobile station to remotely access services provided by the station's home network. The Cisco PDSN provides an integrated FA. The FA communicates with any standard HA including the Cisco IOS-based HA.
AAA Support
The Cisco PDSN provides an authentication client that communicates with any standard AAA server, including Cisco Access Registrar, to authenticate the mobile station. It uses the mobile stations' name (NAI) for authentication of the user with the local AAA server.
•
–
–
–
Note
•
–
–
•
–
–
–
•
–
–
–
–
The Cisco PDSN also supports service provisioning using AAA servers and a user service profile. This profile is defined by the user's home network. It is referenced by the NAI. It is typically stored in the AAA server in the user's home network, along with the user authentication information, and is retrieved as part of authorization reply.
Packet Transport for VPDN
The Cisco PDSN supports the transport of VPDN packets. If the operator offers VPDN services, the mobile station can securely access private resources through a public Internet or dedicated links. The VPDN tunnel extends from the PDSN/FA to the home IP network. The home IP network is the IP network associated with the NAI.
Proxy Mobile IP
With Proxy Mobile IP as part of the PPP link initiation, the PDSN registers with a HA on behalf of the mobile station. It obtains an address from the HA and forwards that address to the mobile station as part of IPCP during PPP initialization.
Multiple Mobile IP Flows
The Cisco PDSN allows multiple IP access points from the same mobile station, as long as each IP flow registers individually (each IP flow requires a unique NAI). This enables multiple IP hosts to communicate through the same mobile access device and share a single PPP connection to the operator's network. For accounting purposes, it is important that the PDSN generate separate usage data records (UDRs) for each flow to the AAA server.
Redundancy and Load Balancing
This section provides information about Intelligent PDSN Selection and Load Balancing for both the Controller - Member cluster model, and for the Peer-to-Peer cluster model.
PDSN Clustering Peer-to-Peer and Controller / Member Architecture
The PDSN Clustering Peer-to-Peer Architecture (or PDSN Intelligent Selection and Load Balancing feature), functions in a peer-to-peer model. All the PDSNs in the cluster share their load and served MSID, and multicast their load and MSID to all other PDSNs in the cluster. This drains resources because large MSID tables need to be stored on all the PDSNs, and because a large amount of traffic is generated to exchange the information among the cluster members. This results in constraints on the cluster size.
Currently, you can choose between Peer-to-Peer clustering, or Controller-Member clustering. In Controller-Member clustering, a controller maintains load and session (such as A10 connection) information for each member in the cluster, and performs member selection for load-balancing or inter-PDSN handoff avoidance. The controller identifies the operational state of each member and detects the failure of a member, or the failure of another controller. A member notifies the controller about its load and session information.
Note
Note
Figure 9 illustrates the Controller-Member architecture on the 6500 or 7600-based MWAM platform. This illustration depicts two PDSN clusters with two primary and two backup controllers, and their corresponding members.
Figure 9 PDSN Controller -Member Architecture
for MWAM on the Catalyst 6500
PDSNs that are designated as controllers, perform member PDSN selection and load balancing. The following list describes the major functions of the controllers:
•
•
•
•
•
•
•
Redundancy
Cluster redundancy is based on the premise that only one PDSN might fail at any given time. Two controllers are configured as an HSRP group: One controller is active, the other standby. Controllers have redundancy and members have load sharing.
Load Sharing
Cluster member loadsharing is an N+1 scheme. If a member fails, the established sessions will be lost, but the overall group capacity allows sessions to be re-established with the other group members. Additionally, redundancy is also enhanced because cluster members no longer have to be network neighbors.
Controllers exchange information over an ethernet link. Controllers and members exchange information over a unicast interface link where members address messages to the HSRP group address of the controllers. The members in a PDSN cluster do not need to be network neighbors; they can be attached anywhere in the IP network.
Adding an additional controller to a cluster is simplified by auto-configuration of the controller in the cluster. This is possible by configuring the additional controller for HSRP. The newly-added controller will automatically synchronize with the active controller. Similarly, when a new member is added to the cluster, auto-configuration for the member occurs in all cluster controllers.
PDSN Cluster Member Selection
Selection of a cluster member by the controller is based on a load factor. Load factor is a computed value by session load and CPU load on a member. The controller attempts to assign sessions to a member that has smallest load factor so that data connections are evenly distributed over members in the cluster as much as possible.
If an A11 Registration Request is received indicating a handoff, a member that is already serving the session is selected by the controller.
Load Balancing
A controller maintains load information for all members in the cluster in order to perform PDSN Cluster Member selection. This load information is transferred from the members to the controller under the following conditions:
•
•
•
The session and member records are synchronized between the active and standby controllers as needed. Since both active and standby controller maintain session and load information for all the members of that cluster, failure of a controller does not result in the loss of any session or load information.
Intelligent PDSN Selection and Load Balancing (Peer-to-Peer)
The Cisco Intelligent PDSN Selection (Peer-to-Peer) feature allows you to group a number of Cisco PDSNs into clusters that can exchange session information for performance and load-balancing purposes. Each Cisco PDSN in a group maintains a table that contains information for the entire group. Using PDSN clusters, minimizes inter-PDSN handoff, provides intelligent load-balancing, and ensures high availability.
To distribute session information, each PDSN sends a broadcast to the Mobile IP multicast address when a session is created or ended. The IP address of the originating PDSN and the MSID are encoded in the Mobile IP messages. Each PDSN in a group updates its session table upon receiving the broadcast.
When a session request is received from the PCF by the Cisco PDSN, the PDSN checks its own session list for an existing session, and also checks session lists within its PDSN group. If it determines that a session exists with another PDSN, it redirects the PCF to that PDSN. This redirection helps to avoid dropping the IP address and, thereby, avoids dropping any existing communication.
If the session does not exist with any other PDSN, the receiving PDSN uses a load-balancing mechanism to determine the appropriate PDSN to use for session establishment. With load balancing, the receiving PDSN looks for the least utilized PDSN in the entire cluster. If the number of active PPP links on that PDSN is some factor less than the number of PPP links on the receiving PDSN, the request will be forwarded. The factor for determining whether the PPP link is forwarded is calculated as a percentage (number of active PPP links vs. total number of possible PPP links).
Load Balancing
For a new packet data session, one PDSN may direct a connection request to another less "loaded" PDSN within the cluster by proposing the address of that PDSN to the PCF. Such redirection of A10 connection requests is performed among lesser loaded PDSNs in a round-robin manner. In PDSN software releases prior to Release 1.1, the load balancing threshold was implemented in terms of a session count differential. Starting in Release 1.1, the threshold is configured in terms of a load factor—the ratio of number of sessions supported and total session capacity of the PDSN. In future releases, other factors (such as QoS, session throughput considerations, CPU load, memory utilization) might also be considered as parameters used to determine of load factor of a PDSN.
Scalability
In this release the PDSN uses a new scalability feature that allows PPP sessions to run on virtual-access subinterfaces that can support up to 20000 sessions.
Note
Note
Note
High Availability
Overview
High availability allows you to minimize the switchover time from the active supervisor engine to the standby supervisor engine if the active supervisor engine fails.
Prior to this feature, fast switchover ensured that a switchover to the standby supervisor engine happened quickly. However, with fast switchover, because the state of the switch features before the switchover was unknown, you had to re-initialize and restart all the switch features when the standby supervisor engine assumed the active role.
High availability removes this limitation; high availability allows the active supervisor engine to communicate with the standby supervisor engine, keeping feature protocol states synchronized. Synchronization between the supervisor engines allows the standby supervisor engine to take over in the event of a failure.
In addition, high availability provides a versioning option that allows you to run different software images on the active and standby supervisor engines.
For high availability, a system database is maintained on the active supervisor engine and updates are sent to the standby supervisor engine for any change of data in the system database. The active supervisor engine communicates and updates the standby supervisor engine when any state changes occur, ensuring that the standby supervisor engine knows the current protocol state of supported features. The standby supervisor engine knows the current protocol states for all modules, ports, and VLANs; the protocols can initialize with this state information and start running immediately.
The active supervisor engine controls the system bus (backplane), sends and receives packets to and from the network, and controls all modules. Protocols run on the active supervisor engine only.
The standby supervisor engine is isolated from the system bus and does not switch packets. But it does receive packets from the switching bus to learn and populate its Layer 2 forwarding table for Layer 2-switched flows. The standby supervisor engine also receives packets from the switching bus to learn and populate the Multilayer Switching (MLS) table for Layer 3-switched flows. The standby supervisor engine does not participate in forwarding any packets and does not communicate with any modules.
If you enable high availability when the standby supervisor engine is running, image version compatibility is checked and if found compatible, the database synchronization starts. High availability compatible features continue from the saved states on the standby supervisor engine after a switchover.
When you disable high availability, the database synchronization is not done and all features must restart on the standby supervisor engine after a switchover.
If you change high availability from enabled to disabled, synchronization from the active supervisor engine is stopped and the standby supervisor engine discards all current synchronization data.
If you change high availability from disabled to enabled, synchronization from the active to standby supervisor engine is started (provided the standby supervisor engine is present and its image version is compatible).
NVRAM synchronization occurs irrespective of high availability being enabled or disabled (provided there are compatible NVRAM versions on the two supervisor engines).
If you do not install a standby supervisor engine during system bootup, the active supervisor engine detects this and the database updates are not queued for synchronization. Similarly, when you reset or remove the standby supervisor engine, the synchronization updates are not queued and any pending updates in the synchronization queue are discarded. When you hot insert or restart a second supervisor engine that becomes the standby supervisor engine, the active supervisor engine downloads the entire system database to the standby supervisor engine. Only after this global synchronization is completed, the active supervisor engine queues and synchronizes the individual updates to the standby supervisor engine.
Note
For more information about High Availability, including configuration details, and information about power management, refer to the "PDSN Clustering Peer-to-Peer and Controller / Member Architecture" section, as well as the documents at the following urls:
•
–
•
–
–
Related Features and Technologies
•
•
•
•
•
Related Documents
For additional information about the Cisco PDSN Release 2.1 software, refer to the following documents:
•
For more information about:
•
•
•
•
•
•
Supported Platforms
The Cisco PDSN for MWAM release is a feature enhancement for the Cisco 7206 router and the Multi-Processor WAN Application Module (MWAM) card that resides on the Cisco Catalyst 6500 switch or Cisco 7600 Internet Router. Refer to the following document for more information regarding the respective platforms:
•
Supported Standards, MIBs, and RFCs
Standards
•
•
•
MIBs
•
•
•
•
•
•
•
•
For descriptions of supported MIBs and how to use MIBs, see the Cisco MIB web site on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
RFCs
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Configuration Tasks
This section describes the steps for configuring the Cisco PDSN software on both the 7200 and MWAM platforms. Prior to configuring instances of the PDSN on MWAM application cards, you must create a base Catalyst 6500 or 7600 configuration. Refer to the Cisco Multi-processor WAN Application Module Installation and Configuration Note for more information.
Configuring the PDSN Image
The Cisco PDSN can provide four classes of user services: Simple IP, Simple IP with VPDN, Mobile IP, and proxy Mobile IP. The following sections describe the configuration tasks for implementing Cisco PDSN. Each category of tasks indicates whether the tasks are optional or required.
R-P Interface Configuration Tasks (Required for all classes of user services)
The following tasks establish the R-P interface, also referred to as the A10/A11 interface. Configuring the R-P interface is required in all 7200 platform configuration scenarios.
To configure the R-P interface, complete the following tasks:
•
•
•
•
User Session Configuration Tasks (Optional)
To configure the user session, complete the following task.
•
AAA and RADIUS Configuration Tasks (Required for All Scenarios)
To configure the AAA and RADIUS in the PDSN environment, complete the following tasks.
•
•
Prepaid Configuration Tasks (Available only on C-6 images)
•
VPDN Configuration Tasks (Required for Simple IP with VPDN Scenario)
To configure the VPDN in the PDSN environment, complete the following task:
•
Mobile IP Configuration Tasks (Required for Mobile IP)
To configure Mobile IP on the PDSN, complete the following task:
•
•
PDSN Selection Configuration Tasks (Optional)
To configure PDSN selection, complete the following tasks:
•
•
•
Network Management Configuration Tasks (Required for Network Management in Any Scenario)
To configure network management, complete the following task:
Other Configuration Tasks
The following tasks are optional on the PDSN:
•
•
•
•
•
•
•
Tuning, Verification, and Monitoring Tasks (Optional)
To tune, verify, and monitor PDSN elements, complete the following tasks:
•
Enabling PDSN Services
To enable PDSN services, use the following commands in global configuration mode:
Creating the CDMA Ix Interface
To create the CDMA Ix interface, use the following commands in global configuration mode:
Creating a Loopback Interface
We recommend that you create a loopback interface and then associate the loopback interface IP address to the virtual template, rather than directly configuring an IP address on the virtual template.
To create a loopback interface, use the following commands in global configuration mode:
Creating a Virtual Template Interface and Associating It With the PDSN Application
Creating a virtual template interface allows you to establish an interface configuration and apply it dynamically.
To create a virtual template interface that can be configured and applied dynamically, use the following commands in global configuration mode:
Enabling R-P Interface Signaling
To enable the R-P interface signaling, use the following commands in global configuration mode:
Configuring User Session Parameters
To configure user session parameters, use the following commands in global configuration mode:
Configuring AAA in the PDSN Environment
Access control is the way you manage who is allowed access to the network server and the services they are allowed to use. AAA network security services provide the primary framework through which you set up access control on your router or access server. For detailed information about AAA configuration options, refer to the "Configuring Authentication," and "Configuring Accounting" chapters in the Cisco IOS Security Configuration Guide.
To configure AAA in the PDSN environment, use the following commands in global configuration mode:
Configuring RADIUS in the PDSN Environment
RADIUS is a method for defining the exchange of AAA information in the network. In the Cisco implementation, RADIUS clients run on Cisco routers and send authentication requests to a RADIUS server that contains all user authentication and network server access information. For detailed information about RADIUS configuration options, refer to the "Configuring RADIUS" chapter in the Cisco IOS Security Configuration Guide.
To configure RADIUS in the PDSN environment, use the following commands in global configuration mode:
Configuring Prepaid in the PDSN Environment
For the Cisco-specific prepaid solution, there are no configuration commands for prepaid. To configure prepaid, ensure that you include crb-entity-type=1 in the user profile.
Enabling VPDN in a PDSN Environment
To configure VPDN in the PDSN environment, use the following commands in global configuration mode:
Router(config)# vpdn enable
Enables VPDN.
Router(config)# vpdn authen-before-forward
Specifies to authenticate a user locally before tunneling.
For more information about VPDNs, refer to the Cisco IOS Release 12.3 documentation modules Cisco IOS Dial Services Configuration Guide: Network Services and Cisco IOS Dial Services Command Reference.
Configuring the Mobile IP FA
Mobile IP operation (as specified by TR-45.6) requires the ability to authenticate a mobile station through a challenge/response mechanism between the PDSN (acting as an FA) and the mobile station.
To configure the Mobile IP FA, use the following commands in global and interface configuration modes:
To reduce the virtual-access cloning time in order to increase the CPS rate on a standalone PDSN on a Cisco 7200 router, use the following per interface configurations in global configuration mode:
The CPS on a standalone PDSN on a Cisco 7200 Internet Router should improve to 100 CPS from the current number of 40.
Configuring IS835-B IPSec for the Cisco PDSN
To configure IS835-B IPSec for the PDSN, use the following commands in global configuration mode:
Here is an example configuration for the IS835-B based IPSecfeature:
Router(config)#crypto isakmp policy 1authentication pre-shareRouter(config)#crypto isakmp key cisco address 7.0.0.2Router(config)#crypto ipsec transform-set mobile-set1 esp-3desRouter(config)#crypto ipsec profile testprofset transform-set mobile-set1Router(config)#crypto identity pdsntestRouter(config)#ip mobile cdma ipsecRouter(config)# ip mobile cdma ipsec profile testprofRouter(config)#ip mobile foreign-agent reg-wait 30Configuring Proxy Mobile IP Attributes Locally
As an alternative to true Mobile IP, which is not supported by all mobile devices, you can configure the Cisco PDSN to provide many of the benefits of Mobile IP through the use of proxy Mobile IP. All proxy Mobile IP attributes can be retrieved from the AAA server. To configure proxy Mobile IP attributes locally, use the following command in global configuration mode:
Configuring Mobile IP Security Associations
To configure security associations for mobile hosts, FAs, and HAs, use one of the following commands in global configuration mode:
Configuring PDSN Cluster Controller
To configure the PDSN Cluster Controller attributes locally, use the following commands in global configuration mode.
Note
Configuring PDSN Cluster Member
To configure the PDSN Cluster Member attributes locally, use the following commands in global configuration mode:
Note
Configuring Peer-to-Peer PDSN Selection
A group of Cisco PDSNs can be configured to exchange session information with one another when needed. When a session request is received by the PDSN, it not only checks its own session list for the existence of a session, it also checks the lists of the PDSNs within its group. If a session exists in the group, the Mobile IP registration message for the session is rejected, and an alternate PDSN is recommended. The BSC/PCF can then establish session with the recommended PDSN.
To configure PDSN selection and PDSN load balancing, use the following commands in global configuration mode:
Router(config)# cdma pdsn selection interface interface_name
Configures the interface be used to send and receive PDSN selection messages.
Router(config)# cdma pdsn selection session-table-size size
Enables the PDSN selection feature and defines the size of the session table.1
Router(config)# cdma pdsn selection load-balancing [threshold val [alternate]]
Enables the load balancing function of PDSN selection. The Alternate option alternately suggests two other PDSNs with the least load.
Router(config)# cdma pdsn selection keepalive value
Specifies the length of time to track a PDSN that is not responding.
Router(config)# cdma pdsn secure cluster default spi
{spi_val | [inbound inspi_val outbound outspi_val]} key {ascii|hex} string
Specifies the default mobility security associations for all PDSNs in a cluster, as well as inbound and outbound spi values.
1 You must issue the cdma pdsn selection session-table-size command before you issue the cdma pdsn selection load-balancing command.
Enabling Network Management
To enable SNMP network management for the PDSN, use the following commands in global configuration mode:
Configuring Always On Service
Always On service maintains the subscriber's packet data session in the local network. The PDSN will not initiate release of the subscriber's packet data session due to PPP idle timer expiry, unless the PDSN determines the user is no longer reachable. The Always On feature is enabled by default. To change the default parameters related to this feature, use following command:
Configuring A11 Session Updates
A11 Session Update messages are sent from the PDSN to the PCF to add, change, or update session parameters for an A10 connection. To enable the A11 Session Update feature, perform the following tasks:
Configuring On Demand Address Pools
To configure the DHCP Server with the ODAP Subnet Allocation Server, perform the following configuration tasks. This configuration can be either on a PDSN Cluster Controller or a Backup Cluster Controller.
The IOS DHCP Server feature is enabled by default in IOS. If it becomes disabled, use the global service dhcp command to re-enable the feature.
For the ip dhcp pool pdsn-pool command, the subnet is 13.0.0.0 and the mask defines the size of the pool. The subnet prefix-length defines the size of the subnet chunks using standard CIDR bit count notation to determine the number of addresses that are configured in each subnet lease. Here is a sample of the show dhcp ip pool command output:
Pool pdsn-pool :Utilization mark (high/low) : 100 / 0Subnet size (first/next) : 0 / 0Total addresses : 524288Leased addresses : 4096Pending event : none1 subnet is currently in the pool :Current index IP address range Leased addresses13.0.48.0 13.0.0.0 - 13.7.255.255 4096In this example, one subnet of 4096 addresses has been leased out. It is leased to PDSN1 in this example.
In the following example, a second PDSN pool is shown for reference, pdsn-pool-2. This shows different values used for the pool size and the subnet chunks. Nothing is presently leased.
Pool pdsn-pool-2 :Utilization mark (high/low) : 100 / 0Subnet size (first/next) : 0 / 0Total addresses : 65536Leased addresses : 0Pending event : none1 subnet is currently in the pool :Current index IP address range Leased addresses14.0.0.0 14.0.0.0 - 14.0.255.255 0OSPF is configured to log adjacency changes for network 10.10.1.0, which is the GigEthernet 0/0.101 interface.
Currently, the ODAP Subnet Allocation Server only allows one network command under the ip dhcp pool name-of-pool command. To support disjointed subnets, you must define a pool that is large enough to contain all assigned IP addresses. You cn use the following global configuration command:
ip dhcp excluded-address low-address [high-address]
This command informs the ODAP Subnet Allocation Server to not lease these addresses to the ODAP client. Issuing this command help some configurations with disjointed IP address space, but may not work in other cases, depending on the range of IP addresses.
Configure the following ODAP client and OSPF commands on the PDSN:
Additionally, perform the following configuration details on the PDSN:
interface Loopback1ip address 10.11.2.92 255.255.255.255interface CDMA-Ix1ip address 10.11.1.92 255.255.255.255interface GigabitEthernet0/0.1encapsulation dot1Q 20ip address 10.0.1.1 255.255.0.0interface GigabitEthernet0/0.301encapsulation dot1Q 301ip address 7.0.0.92 255.255.255.0interface Virtual-Template1ip unnumbered Loopback1peer default ip address dhcp-pool pdsn-pool <<name of ODAP pool to useno keepaliveppp accm 0ppp authentication chap pap optionalppp accounting nonerouter ospf 100log-adjacency-changesredistribute connected subnets route-map MAP <<advertises CDMA-Ix interfaceredistribute static subnets <<advertises the ODAP subnetspassive-interface Virtual-Template1 <<no OSPF updates out herenetwork 10.10.1.0 0.0.0.255 area 0access-list 11 permit 10.11.1.92access-list 12 deny 128.0.0.0 0.0.0.255access-list 12 permit anyroute-map MAP permit 10 <<only the CDMA-Ix update gets outmatch ip address 11set tag 9route-map DENY-MAP permit 10 <<blocks 128.x.x.x internal network betweenmatch ip address 12 <<the PC and sibytes on the MWAM cardset tag 9or
summary-address 128.0.0.0 255.0.0.0 not-advertise <<also blocks the 128 networkThe ip dhcp ping packets 0 command will disable the ODAP client from sending a ping to determine if an address is available. The ODAP default time is 2 seconds to wait for an ICMP echo reply. This will reduce the address allocation time at the risk of detecting duplicate addresses. The ip address-pool dhcp-pool command enables the ODAP client on the PDSN. The pool for the PDSN to use is called pdsn-pool. The origin command tells that it is DHCP, and gives an initial size for the pool to use and a size to grow by. In this case, both the initial and autogrow are set for a subnet size of 4096. The utilization mark (high/low) command can be used to set a percentage of pool usage before the router will schedule a subnet request for a new subnet, or to free a subnet that is no longer being used. The name of the pool must also be configured on the Virtual-Template1 interface. Here is the output of the show command.
PDSN#show ip dhcp poolPool pdsn-pool :Utilization mark (high/low) : 95 / 5Subnet size (first/next) : 20 / 20 (autogrow)Total addresses : 4094Leased addresses : 0Pending event : none1 subnet is currently in the pool :Current index IP address range Leased addresses13.0.64.1 13.0.64.1 - 13.0.79.254 0The ip dhcp-server 7.0.0.96 command causes DHCP requests to go to this particular DHCP Server. Otherwise Broadcast messages are sent to discover the DHCP Servers.
For OSPF, the redistribute static subnets command is used to aggregate the ODAP subnet routes on the SUP. The redistribute connected subnets route-map MAP command uses an access-list functionality to only allow the CDMA-Ix1 IP address to be known to the SUP. All other "connected subnets" routing updates are not sent out.
Alternatively, the summary-address 128.0.0.0 255.0.0.0 not-advertise command can be used instead of the route-map DENY-MAP permit 10 command to prevent the 128.0.0.0 route from being seen. The route-map is similar to an access-list, so the summary-address command may be preferable and have less impact on processor performance.
There are additional configuration details for the Catalyst 6500 Series Switch, as well as additional commands that will assist you in configuring ODAP on the PDSN. For more information, refer to the following Cisco 12.3 IOS documentation:
•
•
•
Configuring PoD on the PDSN
To enable the Packet of Disconnect (RADIUS Disconnect) feature on the PDSN, perform the following task:
Configuring Mobile IP Resource Revocation on the PDSN
To enable resource revocation support on PDSN, perform the following task:
Configuring Closed-RP Interfaces
To enable the Closed-RP feature on the PDSN, perform the following tasks:
Here is a sample configuration for the Closed-RP feature on the PDSN:
Router#sh runBuilding configuration...Current configuration : 3450 bytes!! Last configuration change at 04:23:40 UTC Tue May 27 2003! NVRAM config last updated at 04:24:03 UTC Tue May 27 2003!version 12.3service timestamps debug datetime msec localtimeservice timestamps log datetime msec localtimeno service password-encryptionservice cdma pdsn!hostname Router!boot-start-markerboot-end-marker!!aaa new-model!!aaa authentication ppp default group radiusaaa authorization config-commandsaaa authorization ipmobile default group radiusaaa authorization network default group radiusaaa accounting network pdsn start-stop group radius!aaa session-id commonip subnet-zerono ip gratuitous-arpsip cefno ip domain lookupip dhcp ping packets 0!!vpdn enablevpdn authen-before-forwardvpdn ip udp ignore checksum!vpdn-group CDMA! Default L2TP VPDN groupaccept-dialinprotocol l2tpsource-ip 150.150.0.100l2tp tunnel hello 0no l2tp tunnel authenticationl2tp tunnel timeout no-session never!no virtual-template snmp!!!interface Loopback0ip address 87.0.0.3 255.0.0.0!interface CDMA-Ix1ip address 150.150.0.100 255.255.254.0tunnel source 150.150.0.100tunnel key 1!interface GigabitEthernet0/0no ip address!interface GigabitEthernet0/0.2encapsulation dot1Q 25ip address 9.15.50.173 255.255.0.0!interface GigabitEthernet0/0.37encapsulation dot1Q 37ip address 37.0.0.3 255.0.0.0!interface GigabitEthernet0/0.47encapsulation dot1Q 47ip address 47.0.0.43 255.0.0.0!interface Virtual-Template1ip unnumbered Loopback0peer default ip address pool pdsn-poolno keepaliveppp accm 0ppp authentication chap pap optionalppp accounting none!router mobile!ip local pool mobilenodes 30.0.0.2 30.0.0.255ip local pool pdsn-pool 122.3.0.1 122.3.16.1ip local pool pdsn-pool 122.4.0.1 122.4.16.1ip local pool pdsn-pool 122.5.0.1 122.5.16.1ip local pool pdsn-pool 122.1.0.1 122.1.16.1ip local pool pdsn-pool 122.2.0.1 122.2.16.1ip default-gateway 9.15.0.1ip classlessip route 7.0.0.1 255.255.255.255 16.1.1.60ip route 9.100.0.0 255.255.0.0 9.15.0.1ip route 10.76.86.41 255.255.255.255 9.15.0.1ip route 10.76.86.62 255.255.255.255 9.15.0.1ip route 150.150.2.2 255.255.255.255 47.0.0.2ip route 150.150.2.3 255.255.255.255 47.0.0.3ip route 150.150.4.2 255.255.255.255 47.0.0.4ip route 150.150.4.3 255.255.255.255 47.0.0.5ip route 150.150.6.2 255.255.255.255 47.0.0.6ip route 150.150.6.3 255.255.255.255 47.0.0.7ip route 150.150.8.2 255.255.255.255 47.0.0.8ip route 150.150.8.3 255.255.255.255 47.0.0.9ip route 150.150.10.2 255.255.255.255 47.0.0.10ip route 150.150.10.3 255.255.255.255 47.0.0.11no ip http server!!!!radius-server host 10.76.86.62 auth-port 1645 acct-port 1646 key ciscoradius-server key ciscoradius-server vsa send accounting 3gpp2cdma pdsn pcf default closed-rpcdma pdsn virtual-template 1no cdma pdsn a10 ahdlc trailer!control-plane!line con 0exec-timeout 0 0transport preferred alltransport output allline vty 0 4exec-timeout 0 0transport preferred alltransport input alltransport output allline vty 5 15exec-timeout 0 0transport preferred alltransport input alltransport output all
Note
For information regarding VPDN configuration details, please refer to the following URL:
http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5207/products_command_reference_chapter09186a00801a7e8f.html#wp1167095
For information regarding Layer 2 Tunneling Protocol (L2TP) tunnel configuration details, please refer to the following URL:
http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5207/products_command_reference_chapter09186a00801a7e90.html
For information regarding IOS Server Load Balancing, please refer to the following URL:
http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5012/products_feature_guide09186a008020b9f3.html#wp3601032
Configuring Short Data Burst Flagging
This feature adds support for short data burst applications such as SIP signaling for PTT applications, and proposes the interaction with PDSN. SIP is used by PTT applications to signal a PTT call. The message is short and needs to be delivered to the end-user. The Short Data Burst support on the RAN can be used to send these over to the end-user, especially when the messages are to be terminated to the mobile.
To configure SDB on the PDSN so that all packets that are set with the specific group-number will be flagged for SDB usage between the PCF and the PDSN, use the following command in global configuration:
Configuring PDSN Accounting Events
To configure attributes of PDSN accounting events, use the following commands in global configuration mode:
Configuring CDMA RADIUS Attributes
To configure both authentication and accounting requests on the PDSN, perform the following tasks:
Monitoring and Maintaining the PDSN
To monitor and maintain the PDSN, use the following commands in privileged EXEC mode:
Configuration Examples
This section provides the following configuration examples:
•
•
•
•
•
Cisco PDSN Configuration for Simple IP
Figure 10 and the information that follows is an example of PDSN architecture for Simple IP and its accompanying configuration.
Figure 10 PDSN for Simple IP—A Network Map
service cdma pdsn!hostname PDSN1-7206!aaa new-modelaaa authentication ppp default group radiusaaa authorization config-commandsaaa authorization network default group radiusaaa authorization configuration default group radiusaaa accounting update periodic 60aaa accounting network pdsn start-stop group radius!no ip gratuitous-arps!interface Loopback0ip address 8.8.8.254 255.255.255.255!interface CDMA-Ix1ip address 6.6.6.6 255.0.0.0!interface FastEthernet0/0! Interface for communication with RADIUS server and NMSip address 33.33.33.33 255.255.255.0!!!interface FastEthernet1/0! Interface to PCF - R-Pip address 2.2.2.2 255.255.255.0half-duplexno cdp enable!interface FastEthernet2/0! Interface to external network - Piip address 23.23.23.23 255.255.0.0!!!interface Virtual-Template1ip unnumbered Loopback0peer default ip address pool pdsn-poolppp accm 0ppp authentication chap pap optionalppp accounting noneppp timeout idle 2000!ip local pool pdsn-pool 8.8.8.1 8.8.8.253ip classles!!radius-server host 33.33.33.34 auth-port 1645 acct-port 1646 key ciscoradius-server retransmit 3radius-server vsa send authentication 3gpp2radius-server vsa send accounting 3gpp2cdma pdsn virtual-template 1cdma pdsn maximum sessions 16000cdma pdsn a10 max-lifetime 36000cdma pdsn msid-authenticationcdma pdsn secure pcf 2.2.2.5 spi 100 key ascii cisco!!!endCisco PDSN Configuration for Simple IP with VPDN
The configuration Simple IP with VPDN is identical to the configuration for Simple IP with two additional lines:
vpdn enablevpdn authen-before-forwardCisco PDSN Configuration for Mobile IP
Figure 11 and the information that follows is an example of PDSN architecture for Mobile IP service and its accompanying configuration. The example shows the configuration of PDSN1.
Figure 11 PDSN for Mobile IP—A Network Map
service cdma pdsn!hostname PDSN1-7206!aaa new-modelaaa authentication login default group radiusaaa authentication login CONSOLE noneaaa authentication ppp default group radiusaaa authorization config-commandsaaa authorization network default group radius!interface Loopback0ip address 11.11.11.1 255.255.255.255!interface CDMA-Ix1ip address 5.5.5.5 255.0.0.0!interface FastEthernet0/0description AAA NMS interfaceip address 12.12.12.100 255.0.0.0!interface FastEthernet1/0description R-P interfaceip address 2.2.2.2 255.255.255.0full-duplex!!interface FastEthernet2/0description Pi interfaceip address 3.3.3.2 255.255.255.0full-duplex!interface Virtual-Template1ip unnumbered loopback0no ip route-cacheno keepaliveppp authentication chap pap optionalppp timeout idle 2000!router mobile!ip classlessno ip http serverip mobile foreign-agent care-of FastEthernet2/0ip mobile foreign-service challenge forward-mfce timeout 10 window 10ip mobile foreign-service reverse-tunnelradius-server host 12.12.22.12 auth-port 1645 acct-port 1646 key ascii cisco!radius-server host 12.12.22.12 auth-port 1645 acct-port 1646 key ascii ciscoradius-server retransmit 3radius-server vsa send authentication 3gpp2radius-server vsa send accounting 3gpp2cdma pdsn secure pcf 2.2.2.1 spi 100 key ascii ciscocdma pdsn virtual-template 1cdma pdsn msid-authentication!!endCombined Configuration for Cisco PDSN
The following example illustrates a PDSN configured for all scenarios: Simple IP, Simple IP with VPDN, Mobile IP, Proxy Mobile IP, and peer-to-peer PDSN selection.
service cdma pdsn!hostname PDSN1!aaa new-modelaaa authentication ppp default group radiusaaa authorization config-commandsaaa authorization network default group radiusaaa authorization configuration default group radiusaaa accounting update periodic 60aaa accounting network pdsn start-stop group radius!vpdn enablevpdn authen-before-forwardvirtual-profile aaausername HA password 0 rosebudusername LNS password 0 ciscousername PDSN password 0 ciscono ip gratuitous-arps!interface Loopback0ip address 8.8.8.254 255.255.255.255!interface CDMA-Ix1ip address 6.6.6.6 255.0.0.0!interface FastEthernet0/0! Interface for communication with RADIUS server and NMSip address 33.33.33.33 255.255.255.0!!!interface FastEthernet1/0! Interface to PCF - R-Pip address 2.2.2.2 255.255.255.0!interface FastEthernet2/0! Interface to external network - Piip address 23.23.23.23 255.255.0.0!!!interface Virtual-Template1ip unnumbered Loopback0no keepalivepeer default ip address pool pdsn-poolppp accm 0ppp authentication chap pap optionalppp accounting noneppp timeout idle 2000!router mobile!ip local pool pdsn-pool 8.8.8.1 8.8.8.253ip classlessip mobile foreign-agent care-of FastEthernet2/0ip mobile foreign-service challenge forward-mfce timeout 10 window 10ip mobile foreign-service reverse-tunnelradius-server host 12.12.22.12 auth-port 1645 acct-port 1646 key ascii cisco!!radius-server host 33.33.33.34 auth-port 1645 acct-port 1646 key ciscoradius-server retransmit 3radius-server vsa send authentication 3gpp2radius-server vsa send accounting 3gpp2cdma pdsn virtual-template 1cdma pdsn maximum sessions 16000cdma pdsn a10 max-lifetime 36000cdma pdsn msid-authenticationcdma pdsn secure pcf 2.2.2.5 spi 100 key ascii ciscocdma pdsn secure cluster default spi 100 key ascii ciscocdma pdsn selection interface FastEthernet0/0!!!endPDSN Cluster Configuration
The following configuration illustrates 3 MWAMs in a 6500 configuration:
Verify hardware configuration on Cat6K:cat6500 router#sh moduleMod Ports Card Type----------------------------------------------1 2 Catalyst 6000 supervisor 2 (Active)3 48 SFM-capable 48-port 10/100 Mbps RJ454 2 IPSec VPN Accelerator5 16 SFM-capable 16 port 1000mb GBIC7 3 MWAM Module8 3 MWAM Module (MP)9 3 MWAM ModuleMod MAC addresses Hw Fw Sw Status--- ---------------------------------- ------ ------------ ------------ -------1 0005.7485.8494 to 0005.7485.8495 3.5 6.1(3) 6.2(2.108) Ok3 0001.63d7.2352 to 0001.63d7.2381 4.2 6.3(1) 6.2(2.108) Ok4 0008.7ca8.1386 to 0008.7ca8.1389 0.200 7.2(1) 6.2(2.108) Ok5 0001.63d6.cd92 to 0001.63d6.cda1 4.1 6.3(1) 6.2(2.108) Ok7 0001.0002.0003 to 0001.0002.000a 0.203 7.2(1) 1.0(0.1) Ok8 00e0.b0ff.3a10 to 00e0.b0ff.3a17 0.201 7.2(1) 1.2(0.12) ShutDown9 0002.0002.0003 to 0002.0002.000a 0.203 7.2(1) 1.0(0.1) OkMod Sub-Module Hw Status--- --------------------------- ------- -------1 Policy Feature Card 2 3.2 Ok1 Cat6k MSFC 2 daughterboard 2.2 Okcat6500 router#Controller configuration:cat6500 router#session slot 7 processor 6The default escape character is Ctrl-^, then x.You can also type 'exit' at the remote prompt to end the sessionTrying 127.0.0.76 ... OpenPress RETURN to get started!S76>S76>S76>S76>enS76#sh runS76#sh running-configBuilding configuration...Current configuration : 1489 bytes!! No configuration change since last restart!version 12.2service timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice cdma pdsn!hostname S76!!ip subnet-zeroip cef!!!interface Loopback1no ip address!interface GigabitEthernet0/0no ip address!interface GigabitEthernet0/0.401encapsulation dot1Q 401ip address 10.121.68.76 255.255.255.0standby 1 ip 10.121.68.98standby 1 priority 120standby 1 preemptstandby 1 name 6509-cluster!router mobile!ip classlessip route 10.10.72.1 255.255.255.255 10.121.68.72ip route 10.10.73.1 255.255.255.255 10.121.68.73ip route 10.10.74.1 255.255.255.255 10.121.68.74ip route 10.10.75.1 255.255.255.255 10.121.68.75ip route 10.10.92.1 255.255.255.255 10.121.68.92ip route 10.10.93.1 255.255.255.255 10.121.68.93ip route 10.10.94.1 255.255.255.255 10.121.68.94ip route 10.10.95.1 255.255.255.255 10.121.68.95ip route 128.0.0.0 255.255.255.0 GigabitEthernet0/1no ip http serverip pim bidir-enable!!!cdma pdsn secure pcf 10.121.68.62 10.121.68.66 spi 100 key ascii ciscocdma pdsn secure pcf 10.121.68.82 10.121.68.86 spi 100 key ascii ciscocdma pdsn secure cluster default spi 100 key ascii usercdma pdsn cluster controller interface GigabitEthernet0/0.401cdma pdsn cluster controller standby 6509-clustercdma pdsn cluster controller timeout 10cdma pdsn cluster controller window 3!line con 0line vty 0no loginline vty 1 4loginline vty 5 15login!endS76#cat6500 router#session slot 9 processor 6The default escape character is Ctrl-^, then x.You can also type 'exit' at the remote prompt to end the sessionTrying 127.0.0.96 ... OpenS96>Press RETURN to get started!S96>S96>S96>S96>enS96#sh runS96#sh running-configBuilding configuration...Current configuration : 1182 bytes!! No configuration change since last restart!version 12.2service timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice cdma pdsn!hostname S96!!ip subnet-zeroip cef!!!!interface Loopback1no ip address!interface CDMA-Ix1no ip address!interface GigabitEthernet0/0no ip address!interface GigabitEthernet0/0.401encapsulation dot1Q 401ip address 10.121.68.96 255.255.255.0standby 1 ip 10.121.68.98standby 1 priority 120standby 1 preemptstandby 1 name 6509-cluster!router mobile!ip classlessip route 10.10.72.1 255.255.255.255 10.121.68.72ip route 128.0.0.0 255.255.255.0 GigabitEthernet0/2no ip http serverip pim bidir-enable!!!cdma pdsn secure pcf 10.121.68.62 10.121.68.66 spi 100 key ascii ciscocdma pdsn secure pcf 10.121.68.82 10.121.68.86 spi 100 key ascii ciscocdma pdsn secure cluster default spi 100 key ascii usercdma pdsn cluster controller interface GigabitEthernet0/0.401cdma pdsn cluster controller standby 6509-clustercdma pdsn cluster controller timeout 10cdma pdsn cluster controller window 3!line con 0line vty 0no loginline vty 1 4loginline vty 5 15login!endS96#Verify active controller and standby controllerS76#sh standbyGigabitEthernet0/0.401 - Group 1State is Active2 state changes, last state change 00:27:09Virtual IP address is 10.121.68.98Active virtual MAC address is 0000.0c07.ac01Local virtual MAC address is 0000.0c07.ac01 (default)Hello time 3 sec, hold time 10 secNext hello sent in 2.112 secsPreemption enabled, min delay 0 sec, sync delay 0 secActive router is localStandby router is 10.121.68.96, priority 120 (expires in 9.064 sec)Priority 120 (configured 120)IP redundancy name is "6509-cluster"S76#S96#sh standbyGigabitEthernet0/0.401 - Group 1State is Standby1 state change, last state change 00:26:57Virtual IP address is 10.121.68.98Active virtual MAC address is 0000.0c07.ac01Local virtual MAC address is 0000.0c07.ac01 (default)Hello time 3 sec, hold time 10 secNext hello sent in 2.532 secsPreemption enabled, min delay 0 sec, sync delay 0 secActive router is 10.121.68.76, priority 120 (expires in 9.580 sec)Standby router is localPriority 120 (configured 120)IP redundancy name is "6509-cluster"S96#Members configuration:cat6500 router#session slot 7 processor 3The default escape character is Ctrl-^, then x.You can also type 'exit' at the remote prompt to end the sessionTrying 127.0.0.73 ... OpenS73>Press RETURN to get started!S73>S73>enS73#sh runS73#sh running-configBuilding configuration...Current configuration : 3192 bytes! Last configuration change at 04:10:06 UTC Sun Sep 15 2002!version 12.2service timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice cdma pdsn!hostname S73!aaa new-model!!aaa group server radius CSCO-30server 10.1.1.244 auth-port 1645 acct-port 1646server 10.1.1.200 auth-port 2812 acct-port 2813!aaa authentication ppp default local group radiusaaa authorization network default local group radiusaaa accounting network pdsn start-stop group radiusaaa session-id common!username root nopasswordusername cisco password 0 ciscousername pdsn password 0 ciscoip subnet-zeroip gratuitous-arpsip cef!!!interface Loopback1ip address 10.10.173.1 255.255.255.0!interface CDMA-Ix1ip address 10.10.73.1 255.255.255.0tunnel source 10.10.73.1tunnel key 16404tunnel sequence-datagrams!interface GigabitEthernet0/0<no ip address
Guest
