How Session Recovery Works
This section provides an overview of how this feature is implemented and the recovery process.
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 (for example, session manager and AAA manager) within the system. These mirrored processes remain in an idle state (standby-mode) wherein they perform no processing, until they may be needed in the event of a software failure (for example, a session manager task aborts).
-
Additional software or hardware failures occur during the session recovery operation. For example, an AAA manager fails while the state information it contained was being used to populate the newly activated session manager task.
-
A lack of hardware resources (packet processing card memory and control processors) to support session recovery.
Important |
After a session recovery operation, some statistics, such as those collected and maintained on a per manager basis (AAA Manager, Session Manager, etc.) are in general not recovered, only accounting and billing related information is checkpointed and recovered. |
-
Any session needing L2TP LAC support (excluding regenerated PPP on top of an HA or GGSN session)
-
ASR 5500 only – Closed RP PDSN services supporting simple IP, Mobile IP, and Proxy Mobile IP
-
ASR 5500 only – eHRPD service (evolved High Rate Packet Data)
-
ASR 5500 only – ePDG service (evolved Packet Data Gateway)
-
GGSN services for IPv4 and PPP PDP contexts
-
HA services supporting Mobile IP and/or Proxy Mobile IP session types with or without per-user Layer 3 tunnels
-
ASR 5500 only – HNB-GW: HNB Session over IuH
-
ASR 5500 only – HNB-GW: HNB-CN Session over IuPS and IuCS
-
ASR 5500 only – HNB-GW: SeGW Session IPSec Tunnel
-
ASR 5500 only – HSGW services for IPv4
-
IPCF (Intelligent Policy Control Function)
-
ASR 5500 only – IPSG-only systems (IP Services Gateway)
-
LNS session types (L2TP Network Server)
-
MME (Mobility Management Entity)
-
ASR 5500 only – NEMO (Network Mobility )
-
P-GW services for IPv4
-
ASR 5500 only – PDIF (Packet Data Interworking Function)
-
PDSN services supporting simple IP, Mobile IP, and Proxy Mobile IP
-
S-GW (Serving Gateway)
-
SaMOG (S2a Mobility over GTP) Gateway (CGW and MRME)
-
ASR 5500 only – SAE-GW (System Architecture Evolution Gateway)
-
ASR 5500 only – SGSN services (3G and 2.5G services) for IPv4 and PPP PDP contexts
-
Destination-based accounting recovery
-
GGSN network initiated connections
-
GGSN session using more than 1 service instance
-
MIP/L2TP with IPSec integration
-
MIP session with multiple concurrent bindings
-
Mobile IP sessions with L2TP
-
Multiple MIP sessions
Important |
Always refer to the Administration Guides for individual products for other possible session recovery and Interchassis Session Recovery (ICSR) support limitations. |
-
Data and control state information required to maintain correct call behavior.
-
A minimal set of subscriber data statistics; required to ensure that accounting information is maintained.
-
A best-effort attempt to recover various timer values such as call duration, absolute time, and others.
-
The idle time timer is reset to zero and the re-registration timer is reset to its maximum value for HA sessions to provide a more conservative approach to session recovery.
Important |
Any partially connected calls (for example, a session where HA authentication was pending but has not yet been acknowledged by the AAA server) are not recovered when a failure occurs. |
Note |
Failure of critical tasks will result in restarting StarOS. Kernel failures, hypervisor failures or hardware failures will result in the VM restarting or going offline. The use of ICSR between two VPC-DIs or two VPC-SIs is the recommended solution for these types of failure. |