Cisco Mobile Wireless Home Agent Release 5.1 for Cisco IOS Release 12.4(22)YD1

Terminating IP Registrations

This chapter discusses how the Cisco Mobile Wireless Home Agent terminates IP registrations and how to configure the Home Agent to perform this function.

This chapter includes the following sections:

•Mobile IPv4 Registration Revocation

•I-bit Support

•Configuring MIPv4 Registration Revocation

•Mobile IPv4 Resource Revocation Restrictions

•Simultaneous Bindings

•Radius Disconnect

•Configuring RADIUS Disconnect Client

•Restrictions for RADIUS Disconnect

•Support for Binding Synch and Deletion

•Selective FA Revocation

Mobile IPv4 Registration Revocation

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.

This feature is similar to the Cisco MobileIP Bind Update feature. When a mobile changes its point of attachment (FA), or needs to terminate the session administratively, the HA sends a registration revocation message to the old FA. The old FA tears down the session and sends a registration revocation acknowledgement message to the HA. Additionally, if the PDSN/FA needs to terminate the session administratively, the FA sends a registration revocation message to the HA. The HA deletes the binding for the mobile, and sends a registration revocation acknowledgement to FA.

An HA configured to support registration revocation in Mobile IPv4 includes a revocation support extension in all MIP RRP for the associated MIP RRQ from the PDSN that contained a valid registration revocation extension. A registration for which the HA received a revocation support extension, and responded with a subsequent revocation support extension, is considered revocable by the HA.

The following sample call flow illustrates Mobile IP Resource Revocation (Registration phase):

Step 1 The MS originates a call and PPP session is up.

Step 2 The PDSN/FA has been configured to advertise MIPv4 registration revocation support. The PDSN/FA sends advertisement with MIPv4 Registration revocation support bit "X" set.

Step 3 The PDSN/FA receives MIP RRQ from MN, includes STC attribute set to 2 in access-request during FA-CHAP. While forwarding the RRQ to the HA, the revocation support extension is appended after the MHAE. The I-bit in the revocation support extension will be set to 1 indicating that the MS would get an explicit notification on revocation of the binding whenever necessary.

Step 4 The HA, upon receiving the MIP RRQ containing a revocation extension, will send back the MIP RRP including a revocation support extension and setting the I-bit equal to the value received in the MIP RRQ. In case of HA-CHAP (MN-AAA authentication), the STC attribute, with a value of 2, will be included in the access-request sent to AAA.

Step 5 The PDSN receives the MIP RRP containing a revocation support extension, and the data flow is considered to be revocable.

The following sample call flow illustrates Mobile IP Resource Revocation (HA initiated):

Step 1 Mobile starts a mobile IP data session with PDSN/FA (1).

Step 2 PDSN/FA (1) appends a registration revocation support extension to the mobile registration request and forwards it to the HA.

Step 3 In response, the HA appends the registration revocation support extension to a registration reply, and send it to PDSN/FA (1).

Step 4 PDSN-to-PDSN handoff occurs, and the Mobile re-starts a mobile IP data session with PDSN/FA (2).

Step 5 PDSN/FA(2) sends a registration request to the HA.

Step 6 The HA sends a registration response to PDSN/FA (2).

Step 7 The HA sends a Mobile IP resource revocation message to the PDSN/FA (1).

Step 8 PDSN/FA (1) sends a Mobile IP resource revocation acknowledgement to the HA, and terminates the mobile IP data session for the mobile.

The following sample call flow illustrates a Mobile IP Resource Revocation (FA initiated revocation):

Step 1 The Mobile starts a mobile IP data session with the PDSN/FA.

Step 2 The PDSN/FA appends the registration revocation support extension to the mobile registration request, and forwards it to the HA.

Step 3 In response, the HA appends the registration revocation support extension to a registration reply, and sends it to the PDSN/FA.

Step 4 Some event occurs in the PDSN/FA, and the PDSN/FA decides to close the session.

Step 5 The PDSN/FA sends a Mobile IP resource revocation message to the HA.

Step 6 The HA sends a Mobile IP resource revocation acknowledgement to the HA. The HA clears the binding and the PDSN/FA clears the session.

I-bit Support

During the registration revocation phase, the I (Inform) bit notifies the mobile node (MN) of the revoked data service in cases where the mobile node has more than one MobileIP flow. If, during the registration phase, this bit is set to 1 by a mobility agent in the revocation support extension in the RRQ/RRP, it indicates that the agent supports the use of the "I" bit in revocation messages.

In the current implementation, if MobileIP RRQ is received with I bit set in the revocation support extension, then the HA also sets the I-bit to 1, and the I-bit can be used during the revocation phase. When the HA initiates revocation (and if the I bit was negotiated), it sets the I bit to 1 in the Revocation message if a binding is administratively released, and sets it to 0 if a inter- PDSN handoff is detected by the HA. When revocation is initiated by the PDSN, and the revocation message has I-bit set to 1, then the HA also sets the I-bit to 1 in the revocation ACK message.

Configuring MIPv4 Registration Revocation

To enable MIPv4 Registration Revocation feature on HA, perform the following tasks in global configuration mode:

The following example illustrates the ip mobile home-agent revocation command:

Router(config)# ip mobile home-agent revoc timeout ?

  <1-100>  Wait time (default 3 secs)

Router(config)# ip mobile home-agent revoc retransmit ?

  <0-100>  Number of retries for a transaction (default 3)

Mobile IPv4 Resource Revocation Restrictions

The following list identifies the restrictions for Mobile IPv4 Resource Revocation feature for the current release:

•The STC attribute received in access-accept during HA-CHAP (MN-AAA authentication) is ignored, and the feature configuration on the Home Agent will take precedence.

•The Revocation message, Revocation ACK message, and Revocation support extension (not protected by either FHAE or IPSec) will not be discarded, but will be processed. We recommend that you configure an FA-HA security association on the Home Agent, or that an IPSec tunnel exists between the FA and the HA.

•Resource Revocation and Bind Update cannot be enabled simultaneously. Both are mutually exclusive of each other.

•The Home Agent MIB is not updated with the Registration revocation information.

Simultaneous Bindings

The Home Agent does not support simultaneous bindings for the following reason:

•When multiple flows are established for the same NAI, a different IP address is assigned to each flow. Therefore, simultaneous binding is not required because its function is to maintain more than one flow to the same IP address.

Radius Disconnect

Radius Disconnect (or Packet of Disconnect (PoD)) is a mechanism that allows the RADIUS server to send a Radius Disconnect Message to the HA to release resources. Resources may be released for administrative purposes, and are mainly Mobile IP bindings on the HA.

Support for Radius Disconnect on the Cisco Home Agent conforms with RFC 3576. The HA communicates its resource management capabilities to the Home AAA server in an Access Request message that is 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 from configuration. The HA includes a NAS-Identifier attribute that contains its Fully Qualified Domain Name (FQDN) in the Access Request when the radius-server attribute 32 include-in-access-req format command is configured.

The following events occur when a Disconnect Request is received on the HA:

Step 1 Find the user session corresponding to the username (NAI).

Step 2 If the Framed-IP-Address attribute is received in the Disconnect Request, terminate the binding with corresponding to the address.

Step 3 If Framed-IP-Address is not received in the Disconnect Request, terminate all bindings for the user (NAI).

Configuring RADIUS Disconnect Client

Perform the following tasks to configure RADIUS disconnect for clients and the associated keys:

Restrictions for RADIUS Disconnect

The following list includes restrictions for the RADIUS Disconnect feature:

•MIB is not updated with Radius Disconnect information.

•Mobile IP conditional debugging is not supported.

Support for Binding Synch and Deletion

In the current implementation of Home Agent redundancy, bindings that are deleted on the active HA in active-standby mode (or on any peer in a peer to peer mode), due to receipt of a revocation message or a RADIUS disconnect message, are synched to the standby HA, or the peer HA. Also, the additional extensions and attributes for Revocation and Radius Disconnect are relayed to the standby. Registration Revocation and Radius Disconnect (using the clear ip mobile binding command) are supported with HA redundancy. The following list identifies the benefits of this support:

Active-Standby Mode of HA Redundancy:

•Bindings on the active HA that are deleted by trigger (for example, receipt of a Revocation message, or a Radius Disconnect message) will be synched to the Standby HA.

•Bindings that are deleted due to commands that unconfigure (for example, ip mobile host, etc.), will not be synched.

•Bindings that are deleted on the standby HA will not be synched to the active in case of active-standby mode.

•Additional extensions (Revocation Support Extension) and attributes (STC attribute) for Revocation and Radius Disconnect will be relayed to the standby HA.

Peer-to-Peer Mode of HA Redundancy:

•Bindings that are deleted on any of the peers by trigger (for instance, a receipt of Revocation message or a Radius Disconnect message), will be synched to the other peer.

•Bindings that are deleted due to commands that unconfigure (for example, ip mobile host, etc.) will not be synched.

•Additional extensions (Revocation Support Extension) and attributes (STC attribute) for Revocation and Radius Disconnect will be relayed to the peer HA.

Binding Synch

The following call flow shows the sequences and message exchange among various network entities used to bring up the Mobile IP flow and synch the information to the standby Home Agent.

1. The MS originates a call and a PPP session is up.

2. The PDSN receives a MIP RRQ from the MN and authenticates the MN by FA-CHAP. The STC VSA with the appropriate value (2 or 3) is included in the Access-request message to the AAA. After successful authentication, the PDSN forwards the RRQ to the HA and includes the revocation support extension after the MHAE.

3. The HA, upon receiving the MIP RRQ containing a revocation extension, includes a revocation support extension in the MIP RRP sent back to PDSN. During HA-CHAP to authenticate the MS, the STC VSA with appropriate value (2 or 3) is included in the Access-request message sent to the AAA. The binding at the HA is now considered revocable.

4. The PDSN receives the MIP RRP containing a revocation extension. The binding at the PDSN is revocable as the MIP RRP contained a revocation extension

5. Since the Home Agent is configured in redundant mode, a Bind Update message is sent to the standby with the additional information (revocation support extension and STC NVSE).

6. The standby Home Agent regenerates the binding using the information received in the Bind Update message, and sends back a Bind Update Ack message with code "accept" on successful creation of a binding on the standby.

Binding Deletion

As part of this support, two new messages —"Bind Delete Request" and "Bind Delete Ack"—are introduced that are exchanged between the redundant HAs when a binding is deleted. The following sample call flow illustrates when a binding gets deleted on the active Home Agent due to receipt of Revocation message, and the deletion of binding is synched to the standby Home Agent.

1. The MS originates a call, a PPP session is up and a Mobile IP flow is setup on the active Home Agent with Registration revocation capability enabled and negotiated. The same is synched to the standby Home Agent.

2. When a user issues administrative clear command, the PDSN sends a Revocation message to the active Home Agent, deletes the visitor entry, and associated resources are cleared.

3. The active HA, upon receiving the MIP Revocation message, identifies the binding to be deleted. On identifying the binding, a Bind Delete Request message is sent out to the standby HA.

4. After a Bind Delete Request is sent out, the active HA cleans up the resources associated with the binding for the Revocation message that arrived, and sends back a MIP Revocation Ack message to the PDSN.

5. The standby HA, on receipt of Bind Delete Request message, identifies the binding to be deleted, and sends back a Bind Delete Ack message with code as "accept".

6. If a Bind Delete Ack message is not received within a configured time on the active HA, then a Bind Delete Request message is retransmitted. This process is repeated for the max retransmit count.

During binding synch, the extensions (Revocation Support Extension) and attributes for Revocation and Radius Disconnect (STC attribute) are synched from active HA to the standby. In scenarios when the active HA goes down and the standby becomes active, the now active HA is capable of deleting bindings on receipt of a RADIUS Disconnect message. For revocation, the bindings on the now active HA are revocable, and the HA can now send and receive revocation messages.

Selective FA Revocation

In a 3GPP2 environment, when a subscriber roams between their service provider's network and another partner service provider's network, the PDSN gateway sends a Resource Revocation message to the Home Agent to remove the subscriber. This causes timing problems, so Selective FA Revocation selectively ignores these "remove subscriber" requests. Revocation is done on a Foreign Agent basis. Thus, a given HA will statically configure a list of Foreign Agents from which to ignore the "remove subscriber" messages.

Here is a detailed call-flow for Selective FA Revocation:

1. A dual 1x/DO handset registers with RF and establishes a data call on DO. Unlike a voice call, the RF network does not register this data call with the VLR, as it has no knowledge of EVDO networks (as per standards).

2. The handset goes dormant (35 seconds on Samsung, 30 seconds on RIM, 40 seconds on Sierra).

3. The handset does a physical transition from a DO coverage area to a 1x coverage area. As part of this transition, the handset informs the 1x RF via the MTX that it has an active Data Session, but has no data to send, as it's dormant (DRS bit is set to 0). A new session is established to the PDSN through the MTX PCF.

4. Based on the events in Step 3, the 1x PCF queries the VLR for this active Data Session mentioned by the Handset, and because of Step 1, cannot find such session.

5. As part of the events in Step 3, the PCF now sends the PDSN (through the OpenRP interface) a message with the Mobility Event Indicator (MEI) set to 0. To the PDSN, this event, as part of a call-setup is for a brand new session, does the following check

–if MEI=0 and IMSI is a new IMSI not currently assigned to an existing session, proceed and establish the new session.

–if MEI=0 and IMSI is currently assigned to a session, consider this session old, and tear down the session.

6. Since MEI=0 and IMSI is currently assigned to a session (as this is a Hybrid PDSN, handling both DO and 1X sessions at the same time), the PDSN will send a PPP TermReq to the handset and send a Resource Revocation to the Home Agent.

7. The Mobile Node, which was dormant, does not see the TermReq. The MTX RF will buffer the message for a while.

8. The Mobile Node becomes active and has data to send. It still acts as if it has a valid Mobile IP session, receives the TermReq (buffered), and Acks the message, followed by an immediate RF setup/RRQ. The RRQ contains previously assigned values such as assigned IP address for the Handset, IP address of the HA and so on.

9. The PDSN regards this as a new session (MEI=0 and IMSI is a not currently assigned to a session) and sends the RRQ to the HA.

10. The HA now sees a RRQ with no existing binding (as it was revoked in step (6)), and with parameters in the RRQ and considers it a static-assigned MN.

11. The HA sends a Code-139 (administrative prohibited) back to the MN.

With Selectable FA Revocation, the Hybrid PDSN/FA will go through the above conditions and send the revocation to the Home Agent. However, in this case the HA ignores the revocation, but sends a RR response to the PDSN.

As a result, the MN and Home Agent still have a binding state but the PDSN/FA no longer has a PPP session/visitor table entry. Eventually, the mobile goes active and has Data Ready to Send, where the 1x RF channel DRS=1 is included. In this scenario, the VLR is not queried and the OpenRP message to the PDSN has MEI set to 1. Regardless of the MEI value, the PDSN will initiate PPP, and send a RRQ with the previously assigned home address. In this case HA will accept the Re-registration.

Configuring Selective FA Revocation

Perform the following tasks to configure Selective FA Revocation:

Here is an example of the ip mobile home-agent revocation ignore command:

You can ignore revocation from the FA by specifying the standard access-list number or standard access-list name.

Configuring access-list name to ignore the requests from COA 5.1.1.4

Router(config)#ip access-list standard ?

  <1-99>       Standard IP access-list number

  <1300-1999>  Standard IP access-list number (expanded range)

  WORD         Access-list name

Router(config)#ip access-list standard fa_acl1

Router(config-std-nacl)#permit 5.1.1.4

Configuring access-list number to ignore the requests from COA 5.1.1.5

Router(config)#ip access-list standard ?

  <1-99>       Standard IP access-list number

  <1300-1999>  Standard IP access-list number (expanded range)

  WORD         Access-list name

Router(config)#ip access-list standard 1

Router(config-std-nacl)#permit 5.1.1.5

Configuring access-list name to selectively ignore requests from FA 5.1.1.4 . This is to associate the above created acl with the ip mobile home-agent revocation ignore command.

Router((config)#ip mobile home-agent revocation ignore ?      

  <1-99>  fa Access-list number

  WORD    fa Access-list name

Router(config)#ip mobile home-agent revocation ignore fa_acl1

Configuring the access-list number to selectively ignore requests from FA 5.1.1.5

Router(config)#ip mobile home-agent revocation ignore 1

Note ip mobile home-agent revocation ignore currently does not support using 1300-1999 (Standard IP access-list number (expanded range).