Cisco Cisco IOS Software Release 12.4(22)XR
37
Cisco Packet Data Serving Node Release 5.1 for Cisco IOS Release 12.4(22)XR1
OL-20782-01
Session Redundancy Infrastructure
•
If the target PCF received the RRP from the active PDSN, but the handoff state is NOT synchronized
to the standby before switchover, the data path between the target PCF and the now-active PDSN
will not be established (the session still points to the old PCF). As a result, the end user will notice
service disruption. The user cannot gracefully de-register as PPP packets for call termination
(TERMREQ) cannot reach the now-active PDSN, and the RRQ (lifetime=0) from the target PCF
arrives on the now-active PDSN but the session does not recognize this as a valid remote tunnel
endpoint. As a result, deregistration is ignored. The session will eventually be deleted on expiry of
the PPP idle timer or registration lifetime. If the user re-registers again, this will be treated as
handoff, because the session's current remote tunnel endpoint (the old PCF) is different from the
target PCF. This time, the data path is established and the user will receive service.
to the standby before switchover, the data path between the target PCF and the now-active PDSN
will not be established (the session still points to the old PCF). As a result, the end user will notice
service disruption. The user cannot gracefully de-register as PPP packets for call termination
(TERMREQ) cannot reach the now-active PDSN, and the RRQ (lifetime=0) from the target PCF
arrives on the now-active PDSN but the session does not recognize this as a valid remote tunnel
endpoint. As a result, deregistration is ignored. The session will eventually be deleted on expiry of
the PPP idle timer or registration lifetime. If the user re-registers again, this will be treated as
handoff, because the session's current remote tunnel endpoint (the old PCF) is different from the
target PCF. This time, the data path is established and the user will receive service.
•
If the target PCF did not receive an RRP from the active PDSN before switchover, and if the PCF
tries again with the now-active PDSN, the handoff is processed the same as of the current date.
tries again with the now-active PDSN, the handoff is processed the same as of the current date.
Inter-PCF Handoff (Dormant or Active) - Different PDSN
This kind of handoff is indicated to the PDSN by receipt of an A11 Registration Request containing the
PANID and CANID. It also includes the Mobility Event Indicator and Accounting Data (R-P Session
Setup Air-link Record). From the perspective of High Availability, this looks like a new session
establishment on the newly active PDSN and a 'regular' session termination on the old PDSN.
PANID and CANID. It also includes the Mobility Event Indicator and Accounting Data (R-P Session
Setup Air-link Record). From the perspective of High Availability, this looks like a new session
establishment on the newly active PDSN and a 'regular' session termination on the old PDSN.
A11 Reregistrations
A11 Reregistration RRQ is received by the active unit. The registration life timer does not start on the
standby, but it keeps track of the life timer value so that it can restart the life timer once it becomes active.
If the lifetime in the reregistration RRQ is different from the previous RRQ, the new lifetime is
synchronized to the standby. For example, if a previous RRQ carries a lifetime of 300 seconds and now
a new RRQ has the value changed to 500 seconds, the new value is synchronized to the standby. Other
significant parameters included in the reregistration RRQ are also synchronized to the standby.
standby, but it keeps track of the life timer value so that it can restart the life timer once it becomes active.
If the lifetime in the reregistration RRQ is different from the previous RRQ, the new lifetime is
synchronized to the standby. For example, if a previous RRQ carries a lifetime of 300 seconds and now
a new RRQ has the value changed to 500 seconds, the new value is synchronized to the standby. Other
significant parameters included in the reregistration RRQ are also synchronized to the standby.
Now, in the above example, if the failover occurs before synchronizing the new lifetime to the standby,
the standby will start the lifetime for 300 seconds.
the standby will start the lifetime for 300 seconds.
PPP Renegotiation
On PPP renegotiation, the PDSN deletes all the flows on the RP session and sends accounting STOP for
each flow. After PPP is up again, the PDSN creates new flow(s) for the session. Therefore, when PPP
renegotiation happens on the active, the active unit will send a PPP renegotiation notification to the
standby which will then delete all the flows from the RP session on the standby. After PPP is up again
and a new flow is created on the active, the active unit sends each flow's data to the standby. If the
failover occurs during PPP renegotiation, the renegotiation will fail, and the session may be torn down
on the newly active unit.
each flow. After PPP is up again, the PDSN creates new flow(s) for the session. Therefore, when PPP
renegotiation happens on the active, the active unit will send a PPP renegotiation notification to the
standby which will then delete all the flows from the RP session on the standby. After PPP is up again
and a new flow is created on the active, the active unit sends each flow's data to the standby. If the
failover occurs during PPP renegotiation, the renegotiation will fail, and the session may be torn down
on the newly active unit.
Other Considerations
Timers
The following timers are normally running when a session is established:
•
R-P Session Lifetime
•
PPP Idle Timeout
•
MIP Registration Lifetime
•
PPP Absolute Session Timeout
The below timer may be running, depending on configuration