Cisco Cisco Packet Data Gateway (PDG) Documentation Roadmaps

 

transparent to the GGSN service that operates in the same system. The Mobile IP protocol requires a publicly 
addressable FA service; however, this is a problem when the mobile subscriber is located behind a NAT firewall. In this 
case, the NAT firewall has no way of maintaining state to associate the public NATed address with the private address 
assigned to the user by local DHCP server. Mobile IP NAT Traversal solves this problem by establishing a UDP/IP 
tunnel between the subscriber access device and Home Agent. The NAT firewall uses the UDP port address to build 
state for the subscriber session. During this Mobile IP transaction, the HA establishes a mobility binding record for the 
subscriber session. 

When the subscriber roams to a 3GPP cellular access network, it uses the IP address from normal PDP IP context 
establishment as its new Mobile IP Care of Address to refresh the mobility binding record at the Home Agent. For 
reduced latency between access hand-offs, it is also possible to utilize a permanent 'always-on' PDP IP context with the 
IP address maintained in the MIP session persistence client. In this scenario, the mobile access device only needs to re-
establish the dormant RAB wireless connection with the 3GPP access network prior to transmitting a new Mobile IP 
registration. 

The system also enables network-provisioned VPNs for Session Persistence applications by permitting use of 
overlapping address pools on the HA and using various tunneling protocols including IPSEC, Layer 2 Tunneling 
Protocol (L2TP) and Ethernet IEEE 802.1Q VLANs for separation of subscriber traffic. This application may be further 
augmented by additional features such as 800 RADIUS Server Groups to permit use of enterprise controlled AAA 
servers and custom dictionaries. 

 

The Session Recovery feature provides seamless failover and reconstruction of subscriber session information in the 
event of a hardware or software fault within the system preventing a fully connected user session from being 
disconnected. 

Session recovery is performed by mirroring key software processes (e.g. session manager and AAA manager) within the 
system. These mirrored processes remain in an idle state (in standby-mode), wherein they perform no processing, until 
they may be needed in the case of a software failure (e.g. a session manager task aborts). The system spawns new 
instances of ―standby mode‖ session and AAA managers for each active Control Processor (CP) being used. 

Additionally, other key system-level software tasks, such as VPN manager, are performed on a physically separate 
packet processing card to ensure that a double software fault (e.g. session manager and VPN manager fails at same time 
on same card) cannot occur. The packet processing card used to host the VPN manager process is in active mode and is 
reserved by the operating system for this sole use when session recovery is enabled. 

The additional hardware resources required for session recovery include a standby System Processor Card (SPC) and a 
standby packet processing card. 

There are two modes for Session Recovery. 

 

 

Task recovery mode: Wherein one or more session manager failures occur and are recovered without the need 

to use resources on a standby packet processing card. In this mode, recovery is performed by using the 
mirrored ―standby-mode‖ session manager task(s) running on active packet processing cards. The ―standby-
mode‖ task is renamed, made active, and is then populated using information from other tasks such as AAA 
manager. 

 

Full packet processing card recovery mode: Used when a packet processing card hardware failure occurs, or 

when a packet processing card migration failure happens. In this mode, the standby packet processing card is 
made active and the ―standby-mode‖ session manager and AAA manager tasks on the newly activated packet 
processing card perform session recovery.