[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Mobile IP Working Group                                  Charles Perkins
INTERNET DRAFT                                          Sun Microsystems
20 November 1997                                        David B. Johnson
                                              Carnegie Mellon University



                     Special Tunnels for Mobile IP

                   draft-ietf-mobileip-spectun-00.txt


Status of This Memo

   This document is a submission by the Mobile IP Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the mobile-ip@SmallWorks.COM mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  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
   and 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.''

   To learn the current status of any Internet-Draft, please check
   the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North
   Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim),
   ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).


Abstract

   This document defines actions taken by Mobile IP home agents and
   foreign agents to try to avoid loss of datagrams sent to an incorrect
   care-of address, even if a foreign agent has no binding for the
   mobile node.












Perkins and Johnson             Expires 20 May 1998             [Page i]


Internet Draft             Special Tunnels              20 November 1997


1. Introduction

   The base Mobile IP protocol [3], allows any mobile node to move
   about, changing its point of attachment to the Internet, while
   continuing to be identified by its home IP address.  An important
   part of Mobile IP's operation is the maintenance of bindings (care-of
   address information) associated with the mobile node by the home
   agent.  Route optimization [2] enables other IP nodes (correspondent
   nodes) to maintain bindings.  When bindings indicate care-of
   addresses that are no longer valid, because of either transient or
   longer term effects, a foreign agent at a care-of address can receive
   packets tunneled to a mobile node that is no longer registered
   with that foreign agent, and for which no additional forwarding
   information is available.

   In these circumstances, the base Mobile IP protocol indicates
   that the tunneled datagrams should be dropped.  However, dropping
   such packets often necessitates retransmissions by higher level
   protocols, and such retransmissions cause significant performance
   degradation [1].  With care, it is possible to allow foreign agents
   to return such decapsulated datagrams to the home agent in an attempt
   to retry delivery to a more recent care-of address.  The means for
   doing so are specified in this document.

   Suppose a foreign agent receives a tunneled datagram, but it doesn't
   have a visitor list entry for the mobile node.  Moreover, suppose
   the foreign agent has no binding cache entry for the destination
   mobile node.  To attempt delivery of the datagram in this case, the
   node must encapsulate the datagram as a special tunnel datagram (see
   Section 3), destined to the mobile node.  Using a special tunnel
   allows the home agent to avoid a possible routing loop when a foreign
   agent has forgotten that it is serving the mobile node, perhaps
   because the foreign agent has crashed and lost its visitor list
   state.  The special tunnel allows the home agent to see the address
   of the node that tunneled the datagram, and to avoid tunneling the
   datagram back to the same node.


2. Terminology

   This document uses the following terminology, in addition to that
   used to describe the base Mobile IP protocol:

      Binding cache

         A cache of mobility bindings of mobile nodes, maintained by a
         node for use in tunneling datagrams to those mobile nodes.





Perkins and Johnson             Expires 20 May 1998             [Page 1]


Internet Draft             Special Tunnels              20 November 1997


      Registration Lifetime

         The registration lifetime is the time duration for which a
         binding is valid.  The remaining registration lifetime means
         the amount of time remaining for which a registration lifetime
         is still valid, at some time after the registration was
         approved by the home agent.

      Remaining Registration Lifetime

         The remaining registration lifetime is the amount of time
         remaining for which a registration lifetime is still valid,
         at some time after the registration was approved by the home
         agent.

      Special tunnel

         A method of tunneling a datagram in which the outer destination
         address when encapsulating the datagram is set equal to the
         inner destination address (the original destination address of
         the datagram).  A special tunnel is used in Route Optimization
         for returning a datagram, addressed to a mobile node, to the
         mobile node's home agent without knowing the home agent's
         address.


3. Using Special Tunnels

   Whenever any node receives a tunneled datagram for which it has no
   visitor list entry for the datagram's destination, the node is not
   serving the mobile node as a foreign agent, and thus the care-of
   address used by the tunnel originator is surely incorrect.  Thus,
   the tunneling node has an out-of-date binding cache entry for the
   destination mobile node.  If the node receiving the tunneled datagram
   has a binding cache entry for the destination, it should re-tunnel
   the datagram to the care-of address indicated in its binding cache
   entry.

   If a foreign agent receiving the tunneled datagram has no binding
   cache entry for the destination, it cannot re-tunnel the node to its
   destination.  Instead, the foreign agent should forward the datagram
   to the destination mobile node's home agent, using the special form
   of tunneling, specified here, called a special tunnel.  To tunnel the
   datagram using a special tunnel, the tunneled datagram's destination
   address is set equal to the destination address in the tunneled
   datagram.  Thus, both the inner and outer destination addresses
   are set to the home address of the mobile node.  The tunneled
   datagram will be routed to the mobile node's home network, and then




Perkins and Johnson             Expires 20 May 1998             [Page 2]


Internet Draft             Special Tunnels              20 November 1997


   intercepted by the mobile node's home agent in the same way as other
   datagrams addressed to the mobile node.


3.1. Home Agent Handling of Special Tunnels

   The home agent should then tunnel the datagram to the current care-of
   address for the mobile node.  However, the home agent may not tunnel
   the datagram to the current care-of address if the special tunnel
   of the datagram originated at that care-of address, as indicated
   by the outer source address of the special tunnel.  The use of the
   special tunnel format allows the home agent to identify the node
   that tunneled the datagram to it (as well as the original sender of
   the datagram).  If the home agent believes that the current care-of
   address for the mobile node is the same as the source of the special
   tunnel, then the home agent SHOULD discard the datagram.  When that
   happens, the foreign agent serving the mobile node appears to have
   lost its entry for the mobile node in its visitor list.  For example,
   the foreign agent may have crashed and rebooted.

   Otherwise, after tunneling the datagram to the current care-of
   address for the mobile node, the home agent should notify the source
   of the special tunnel of the mobile node's current binding, by
   sending it a Binding Update message.  The home agent should also send
   a Binding Update message [2] to the sender of the original datagram
   (the inner source address of the tunneled datagram), if it shares a
   mobility security association with this node.


3.2. Foreign Agents and Special Tunnels

   When a foreign agent is the endpoint of a tunneled datagram, it
   examines its visitor list for an entry for the destination mobile
   node, as in the base Mobile IP protocol.  If no visitor list entry
   is found, the foreign agent examines its binding cache for a cache
   entry for the destination mobile node.  If one is found, the foreign
   agent re-tunnels the new care-of address indicated in the binding
   cache entry.  In this case, the foreign agent also may infer that the
   sender of the datagram has an out-of-date binding cache entry for
   this mobile node, since it otherwise would have tunneled the datagram
   directly to the correct new care-of address itself.  The foreign
   agent should then send a Binding Warning message to the mobile node's
   home agent.  The foreign agent probably learned the address of the
   home agent in the Registration Reply message for the mobile node, or
   a later Binding Update message from which the binding cache entry
   was created.  If the home agent is not known, the mobile node's home
   address MAY be used.





Perkins and Johnson             Expires 20 May 1998             [Page 3]


Internet Draft             Special Tunnels              20 November 1997


   If a foreign agent receives a tunneled datagram for a mobile node
   for which it has no visitor list entry or binding cache entry, the
   foreign agent should forward the datagram to the mobile node's
   home agent by sending it as a special tunnel.  The home agent will
   intercept the special tunnel datagram addressed to the mobile node
   in the same way as any datagram for the mobile node while it is away
   from home.


References

   [1] Ramon Caceres and Liviu Iftode.  Improving the Performance of
       Reliable Transport Protocols in Mobile Computing Environments.
       IEEE Journal on Selected Areas in Communications, 13(5):850--857,
       June 1995.

   [2] Charles E. Perkins and David B. Johnson.  Route Optimization in
       Mobile-IP.  draft-ietf-mobileip-optim-06.txt, July 1997.  (work
       in progress).

   [3] C. Perkins, Editor.  IP Mobility Support.  RFC 2002, October
       1996.






























Perkins and Johnson             Expires 20 May 1998             [Page 4]


Internet Draft             Special Tunnels              20 November 1997


Chairs' Addresses

   The working group can be contacted via the current chairs:

       Jim Solomon                         Erik Nordmark
       Motorola, Inc.                      Sun Microsystems, Inc.
       1301 E. Algonquin Road              901 San Antonio Road
       Schaumburg, IL 60196                Palo Alto, California 94303
       USA                                 USA

       Phone:  +1-847-576-2753             Phone:  +1 650 786-5166
       Fax:                                Fax:  +1 650 786-5896
       E-mail:  solomon@comm.mot.com       E-mail:  nordmark@sun.com



Authors' Addresses

   Questions about this document can also be directed to the authors:

       Charles E. Perkins                  David B. Johnson
       Technology Development Group        Computer Science Department
       Mail Stop MPK15-214
       Room 2682
       Sun Microsystems, Inc.              Carnegie Mellon University
       901 San Antonio Road                5000 Forbes Avenue
       Palo Alto, California 94303         Pittsburgh, PA 15213-3891
       USA                                 USA
       Phone:  +1-650-786-6464             Phone:  +1-412-268-7399
       Fax:  +1-650-786-6445               Fax:  +1-412-268-5576
       E-mail:  charles.perkins@Sun.COM    E-mail:  dbj@cs.cmu.edu





















Perkins and Johnson             Expires 20 May 1998             [Page 5]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/