Manual

Cisco Packet Data Serving Node (PDSN) Release 2.0

Resource Management

12.3(11)T

• Always-on feature is not applicable for mobileip users.

• Always-on feature is not supported for VPDN users.

• Aging of Dormant PPP session's feature works independent of always-on users. The aging of

dormant PPP session’s feature does not care for the always-on property of a session.

NPE-G1 Platform Support

PDSN Release 2.0 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.

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.0 supports the following enhancements:

• Cluster scalability to support 48 members with bulk-update of session information

• Conditional debugging support for MSID under clustering feature

• Controller Show command enhancements

• Clear command under clustering feature to clear clustering statistics

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.