[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET DRAFT                                          Rajesh Bhalla
Category: Individual submission                         Kent Leung
Title: draft-subbarao-mobileip-resource-00.txt          Alpesh Patel
Expires September 2001                                  Madhavi Subbarao
Mobile IP Working Group                                    Cisco Systems



                  Releasing Resources in Mobile IP
                  draft-subbarao-mobileip-resource-00.txt

Status of this Memo

This document is an Internet Draft and is in full compliance with
all provisions of Section 10 of RFC2026.

Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its Areas, and its Working Groups.  Note that
other groups may also distribute working documents as Internet
Drafts.

Internet Drafts are draft documents valid for a maximum of six
months.  Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time.  It is inappropriate to use Internet
Drafts as reference material or to cite them other than as "work in
progress".

The list of current Internet Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.


Abstract

Currently, in Mobile IP when an MN moves from one FA to another
FA/CoA, relevant resources at the previous FA are consumed until
its visitor entry for the MN expires.  The Resource Release Message
and Resource Management Extension described in this draft will
facilitate the release of these valuable resources at the previous FA
as the MN moves to a new location.  The HA notifies the previous FA of
any changes in the CoA for an MN, thereby allowing the FA to release
its resources.  Similary, when used in the opposite direction,
valuable resources at an HA can be released for an MN if there is
early termination on the FA side. Use of the Resource Release Messages
and Resource Management Extension will lead to increased network
efficiency and system capacity.


1. Introduction

Currently, in Mobile IP when a Mobile Node (MN) moves from one Foreign
Agent (FA) to another FA/Care-of-Address (CoA), relevant resources at
the previous FA are consumed until its visitor entry for the MN
expires.  Similary, if there is early termination of an MN on the FA
side relevant resources at the HA remained consumed until the mobility
binding for the MN expires.  This leads to inefficient use of network
resources which directly affects the efficiency of a Mobile IP network
deployment.

For example, consider a cdma2000 network deployment using Mobile IP.
The Wireless IP Network Standard (IS-835) defines FA/Packet Data
Servicing Node (PDSN) procedures for managing the PPP session for a
MN, i.e., when the Radio Network opens an R-P session for an MN, the
FA/PDSN initiates establishment of a PPP session [1]. As an MN moves
from one foreign domain serviced by an FA/PDSN (source PDSN) to
another PDSN (target PDSN) during an inter-PDSN handoff, a Mobile IP
registration is sent to the Home Agent (HA) and a new PPP session is
established at the target PDSN.  The PPP session at the source PDSN
remains exhausted until the PPP inactivity timer expires. Maintaining
these PPP sessions consumes valuable resources at the source PDSN that
could otherwise be used to support additional MNs.   Thus, it is
desirable and more efficient to release the idle PPP session at the
source PDSN as soon as possible. The Mobile IP infrastructure should
allow for intelligent signaling which would trigger release of the
resources at the PDSN/FA.

A possible solution is to utilize the Previous Foreign Agent
Notification extension offered by Route Optimization in Mobile IP
[2]. This extension triggers the new FA to send a Binding Update (BU)
to the previous FA to inform it that the MN has moved.  As a result,
if the previous FA supports resource management, it releases the
resources that it was using for the MN. The Previous Foreign Agent
Notification extension, however, must be initiated by the MN, i.e.,
the MN must include the extension in a Registration Request (RRQ) to
the new FA to instruct the new FA to send a BU to the previous FA.
Although this is possible, it may not be a practical or viable
solution since it requires modification to all mobile devices to
include the Previous Foreign Agent Notification extension.  Moreover,
the BU is sent by the new FA regardless of the resource management
capabilities of the previous FA. If the previous FA cannot support
resource management or understand the messaging, extra signaling and
processing has unnecessarily occurred.  Note that this solution is
dependent on Route Optimization [2] being employed in the network and
does not support releasing resources at the HA.

Although intended for a different purpose, a Registration Revocation
message as specified in [6] can be sent by the HA to the previous FA
upon an MN's movement to a new FA/Care-of-Address (CoA).  The result
of this message is that resources at the previous FA will be
released. Similary, an HA can be informed of termination of an MN on
the FA side and thus, release its resources.  Currently, the
functionality in [6] is subject to denial-of-service attacks since the
Registration Revocation beacon, i.e., agent advertisement with
sequence number reset, is not authenticated and can be spoofed
(communication to the MN). The Registration Revocation message is also
sent to the previous FA or HA regardless of their resource management
capabilities.

This draft proposes a Mobile IP Resource Management Extension that
may be appended to an RRQ by an FA that supports resource management,
and appended to a Registration Reply (RPY) by an HA that supports
resource management. When an HA receives an authenticated RRQ from an
MN with a Resource Management Extension, it records the capability of
the FA.   The HA then uses the Resource Release Message defined in
this draft to notify the FA regarding a change in the CoA for the MN .
As a result, the FA deletes the visitor entry for the MN and releases
the resources being used to support the MN.

Similarly, when an FA receives an authenticated RPY from an HA with a
Resource Management Extension, it records the capability of the HA.
The FA uses the Resource Release Message to notify the HA if there is
early termination of an MN on the FA side. The HA then deletes the
mobility binding for the MN and releases relevant resources for the MN.

Acknowledgement signaling may be used to ensure earnest effort to
release resources.


2. Mobile IP Resource Management Extension

The Mobile IP Resource Management extension MAY be attached to an
RRQ by an FA or an RPY by an HA.  It is based on the Short Extension
Format given in [3] and is defined as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length   |    Subtype     |A|   Reserved  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Mobile Node Home Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Type
                Skippable (TBD)

        Length
                Length (in bytes).  Does NOT include Type and Length.

        Subtype
                1   (Resource Management Extension)

        'A' Bit
                When this bit is set, the mobility agent is specifying
                that it will send an Acknowledgement in receipt of a
                Resource Release Message.  If an Acknowledgement is
                not received, the Resource Release Message should be
                retransmitted.  This will ensure an earnest attempt to
                release resources.

        Reserved
                Reserved for future use.  MUST be set to 0 on sending,
                MUST be ignored on receiving.

        Mobile Node Home Address
                The home IP address of the Mobile Node to which the
                extension refers.

The Mobile IP Resource Management Extension MUST be protected by a
FA-HA Authentication Extension (FHAE) as defined in [4].


3.  Resource Release Message

The Resource Release Message is used between mobility agents to notify
one another that resources for an MN or group of MNs may be released.

IP layer fields of the message:

Source Address:
        IP address of the mobility agent initiating the
        message.  If the HA is initiating the message,
        the address is the IP address of the HA.  If the FA is
        initiating the message, the address is the IP address of the FA.

Destination Address:
        IP address of the target mobility agent for the message.  If
        the HA is initiating the message, the destination address is
        the IP address of the FA.  If the FA is initiating the
        message, the destination address is the IP address of the HA.


UDP fields of the message:

Source Port             434
Destination Port        434


Mobile IP fields of the message:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Subtype     |A|         Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Mobile Node Home Address                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       HA/FA Address                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Identification                          +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Type     TBD

      Subtype
                1 Enable release of resources

      'A' bit
                This bit MUST be set if the target mobility agent
                set the 'A' bit in its Resource Management Extension.

      Reserved
                Reserved for future use.  MUST be set to 0 on sending
                and ignored on receiving.

      Mobile Node Home Address
                The Home IP address of the MN whose resources
                should be released.  MAY be set to zero to denote a
                group of MNs (see Sections 6 and 7).

      HA/FA Address
                The IP address of the mobility agent initiating the
                message.

      Identification
                A 64-bit number used for protecting against replay
                attacks as defined in [4].  Used in a similar manner as
                described in [4].

The Mobile IP Resource Release Message MUST be protected by the FHAE.


4.  Resource Release Acknowledgement Message

The Resource Release Acknowledgement Message is sent by a mobility agent
that set the 'A' bit in its Resource Management Extension upon the
receipt of a Resource Release Message.


IP layer fields of the message:

Source Address:
        IP address of the mobility agent initiating the acknowledgement
        message.  If the HA is initiating the message,
        the address is the IP address of the HA.  If the FA is
        initiating the message, the address is the IP address of the FA.

Destination Address:
        IP address of the target mobility agent for the
        acknowledgement message.  If the HA is initiating the message,
        the destination address is the IP address of the FA.  If the
        FA is initiating the message, the destination address is the
        IP address of the HA.


UDP fields of the message:

Source Port             434
Destination Port        434


Mobile IP fields of the message:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |            Reserved           |    Status     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Mobile Node Home Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type       TBD


      Reserved
                Reserved for future use.  MUST be set to 0 on sending
                and ignored on receiving.

      Status
                If the Resource Release Message was received without
                error, this field is set to zero.  However, if there
                is an error in reception, the field is nonzero with
                the following allowable codes defined in [4]:

                      128 reason unspecified
                      129 administratively prohibited
                      130 insufficient resources
                      131 sending node failed authentication
                      133 identification mismatch
                      TBD poorly formed Resource Release Message (see
                          Section 8)

      Mobile Node Home Address
                 Copied from the Resource Release Message being
                 acknowledged.

      Identification
                 Copied from the Resource Release Message being
                 acknowledged.

The Resource Release Acknowledgement Message MUST be protected by the
FHAE as defined in [4].


5. Mobile Node Considerations

There are no modifications in behavior required by the MN.


6.  Foreign Agent Considerations

If an FA is capable of resource management, understands the Resource
Release Message, and shares a security association with the HA, it
SHOULD append the Mobile IP Resource Management Extension to an RRQ
received from an MN.  The FA MAY set the 'A' bit in the extension to
indicate that it will acknowledge the received Resource Release
Messages.  The FA MUST protect this extension with an FHAE.  By
appending this extension, the FA informs the HA that it is capable of
managing network resources and should be notified of a change in this
MN's CoA.

Upon receipt of a Resource Release Message from an HA, the FA MUST
check for proper authentication and identification of the message as
defined in [4].  If the FHAE or Identification is not valid, the FA
MUST silently discard the message.  If the Resource Release Message is
properly authenticated and the MN home address and HA address in the
message match an entry in its visitor table, the FA SHOULD delete the
visitor entry and release relevant resources for the MN.  (For
example, see [5] for resource releasing behavior of a PDSN in a
cdma2000 network.)   If the MN address field in the message is set to
zero, the FA SHOULD delete all entries in its visitor table that match
the HA address field in the message, i.e., all MNs that are serviced
by the HA specified in the Resource Release Message. Furthermore, the
FA SHOULD release all relevant resources for the MNs. If the 'A' bit
is set in the Resource Release Message (which means that it was set in
the Resource Management Extension sent by the FA), the FA MUST send a
Resource Release Acknowledgement Message back to the HA.

If the FA is releasing resources of MN(s) as a result of a received
Resource Release Message from the HA, the FA MUST NOT send a Resource
Release Messsage back to the HA.

If the FA receives an authenticated RPY with a Resource Management
Extension appended, the FA MUST ensure that the FHAE is valid.  If the
FA-HA authentication fails, the HA must proceed as outlined in [4] and
reject the RPY.  If the HA does not support the Resource Management
Extension, it should simply ignore the extension.

After authenticating the FHAE, the FA should record the capability of
the HA, e.g., set a Resource Management Flag and an Acknowledgement
Flag (if necessary) in the visitor entry information for the MN.  If
there is an early termination on the FA side for the MN, the FA SHOULD
send a Resource Release Message to the HA.  The FA should set the MN
address field to the home IP address of the MN, the HA/FA address to
its own IP address, and the Identification field and 'A' bit
appropriately. The FA MUST include the FHAE.

If the FA wishes to notify the HA that all MNs serviced by the FA
should be released, the FA sends the Resource Release Message with the
MN address set to zero, HA/FA address set to its own IP address,
and Identification field and 'A' bit set appropriately.  The FA MUST
include the FHAE.

Upon sending a Resource Release Message with the 'A' bit set, if the
FA does not receive an Resource Release Acknowledgement Message from
the HA, it SHOULD retransmit the message.


7.  Home Agent Considerations

If an HA shares a security association with an FA, understands the
Resource Release Message, and supports resource management, the HA
SHOULD append the Resource Management Extension to an RPY.  The HA MAY
set the 'A' bit in the extension to indicate that it will acknowledge
the received Resource Release Message. The HA must protect the
extension with the FHAE.  By including this extension, the HA informs
the FA that it wishes to be notified of termination of the visitor
entry for the MN.

Upon receipt of a Resource Release Message from an FA, the HA MUST
check for proper authentication and identification of the message as
defined in [4].  If the FHAE or Identification is not valid, the HA
MUST silently discard the message.  If the Resource Release Message is
properly authenticated and the MN home address and FA address in the
message match an entry in its mobility binding table, the HA SHOULD
delete the mobility binding and release relevant resources for the
MN. If the MN address field in the message is set to zero, the HA
SHOULD delete all mobility bindings with CoA matching the FA address
field in the message, i.e., all MNs that are serviced by the FA
specified in the Resource Release Message. Furthermore, the HA SHOULD
release all relevant resources for the MNs. If the 'A' bit is set in
the Resource Release Message (which means that it was set in the
Resource Management Extension sent by the HA), the HA MUST send a
Resource Release Acknowledgement Message back to the FA.

If the HA is releasing resources for MN(s) as a result of a received
Resource Release Message from the FA, the HA MUST NOT send a Resource
Release Messsage back to the FA.

If an HA receives an RRQ from an MN with a valid MN-HA Authentication
Extension and a Resource Management Extension, it MUST ensure that the
FHAE is valid.  If the FA-HA authentication fails, the HA must proceed
as outlined in [4] and reject the RRQ.  If the HA does not support the
Resource Management Extension, it should simply ignore the extension.

After authenticating the FHAE, the HA should record the capability of
the FA, e.g., set a Resource Management Flag and Acknowledgement Flag
(if necessary) in the mobility binding information for the MN.   When
the HA receives an RRQ from the MN via a new FA (or different CoA) or
a deregistration, and if the HA is aware that the previous FA supports
resource management, e.g., a Resource Management Flag in the mobility
binding is set, the HA SHOULD send a Resource Release Message to the
previous FA notifying the FA of the change in CoA. The HA sets the MN
address field in the message to the home address of the MN, the HA/FA
address field to its own IP address, the 'A' bit appropriately, and
the Identification field similar to that specified in [4].  The HA
MUST include the FHAE.

If the HA wishes to notify an FA that supports resource management
that all MNs serviced by the HA should be released, the HA sends the
Resource Release Message with the MN address set to zero, HA/FA
address set to its own IP address, and Identification field and 'A'
bit set appropriately.   The HA MUST include the FHAE.

Upon sending a Resource Release Message with the 'A' bit set, if the
HA does not receive an Resource Release Acknowledgement Message from
the FA, it SHOULD retransmit the message.


8.  Error Code

The error code "poorly formed Resource Release Message" was introduced in
Section 4 and may be returned in a Resource Release Acknowledgement Message.
This error code conveys that the Resource Release Message was not
properly formed and could not be parsed by the receiving mobility agent.


9. IANA Considerations

The Mobile IP Resource Management Extension defined in Section 2 is a
Mobile IP registration extension as defined in RFC 2002 [4].  IANA should
assign a Type value consistent with this number space.  The Mobile IP
Resource Release Message defined in Section 3 and Resource Release
Acknowledgement Message defined in Section 4 should be assigned Type
values consistent with the number space defined in [4]. The Code value
in Section 8 is an error code as defined in RFC 2002 [4].  IANA should
assign a value to the code consistent with this number space.


10. Security Considerations

Mobile IP registration messages are authenticated, and the
authentication verified by the recipient.  The Mobile IP Resource
Management Extension, Resource Release Message, and Resource Release
Acknowledgement Message are protected by the FHAE [4].


Appendix A:

If Route Optimization [2] is used in the network, Binding Updates
can be used for signaling between the HA and FA to notify the FA to
release its resources.  In order to support BU signaling from an FA to
an HA, the Route Optimization draft [2] needs to be modified to allow
for a BU to be sent from an FA to an HA, and for the HA to be able to
process a BU.  Note, however, that the generic feature of releasing a
group of MNs (MN address of zero in the Resource Release Message) can
not be achieved with Binding Updates.


11. References

[1] TIA/EIA/IS-835, Wireless IP Network Standard, June 2000.

[2] C. Perkins and D. Johnson, Route Optimization in Mobile IP,
Internet Draft, Internet Engineering Task Force,
draft-ietf-mobileip-optim-10.txt, Work in progress, November 2000.

[3] M. Khalil, et. al., Mobile IP Extensions Rationalization (MIER),
Internet Draft, Internet Engineering Task Force,
draft-ietf-mobileip-mier-05.txt, Work in progress, May 2000.

[4] C. Perkins,  IP Mobility Support for IPv4, revised,  Internet
Draft, Internet Engineering Task Force,
draft-ietf-mobileip-rfc2002-bis-01.txt, Work in progress, January 2000.

[5] Rajesh Bhalla, "PPP Resource Management at the
PDSN". 3Gpp2-P00-20010115-011, Cisco Systems, January 2001.

[6] S. Glass, Registration Revocation for Mobile IP, Internet Draft,
Internet Engineering Task Force. draft-glass-mobileip-reg-revok-00.txt,
Work in progress, July 2000.


Author's Addresses

   Questions about this memo can be directed to:

         Rajesh Bhalla
         Cisco Systems, Inc.
         170 West Tasman Drive
         San Jose, CA 95134
         USA
         email: rabhalla@cisco.com
         phone: +1 408 853 9265
         fax:   +1 408

         Kent Leung
         Cisco Systems, Inc.
         170 West Tasman Drive
         San Jose, CA 95134
         USA
         email: kleung@cisco.com
         phone: +1 408 526 5030
         fax:   +1 408 526 4952

         Alpesh Patel
         Cisco Systems, Inc.
         170 West Tasman Drive
         San Jose, CA 95134
         USA
         email: alpesh@cisco.com
         phone: +1 408 853 9580
         fax:   +1 408 526 4952

         Madhavi Subbarao
         Cisco Systems, Inc.
         7025 Kit Creek Road
         Research Triangle Park, NC 27709
         USA
         email: msubbara@cisco.com
         phone: +1 919 392 8387



Expires September 2001