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

Versions: 00 01 02 03                                                   
INTERNET DRAFT                          K. El Malki, N. A. Fikouras
                                            University of Sheffield
                                                     4th March 1999
Expires September 1999



         Fast Handoff Method for Real-Time Traffic over
                  Scaleable Mobile IP Networks


             <draft-elmalki-mobileip-fast-handoffs-00.txt>




Status of this Memo

     This document is an Internet-Draft and is in full conformance
     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 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."

     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

     This document defines the operations to be performed by
     scaleable Mobile IP [1] networks during handoffs in order to
     support real-time traffic which has delay bounds. This method is
     based on the Regionalized Tunnel Management [2] approach. A
     method is described in this document which defines the operation
     of Mobile Nodes, Foreign Agents and Hierarchical Proxy Foreign
     Agents. This utilises multiple bindings in order to "multicast"
     traffic to potential Mobile Node movement locations in order to
     anticipate movement. This eliminates the service disruption
     period which is currently present during handoffs in Mobile IP
     networks due to registration delay. The information redundancy
     lasts only for very short periods and the waste of bandwidth is
     therefore minimal.


El Malki, Fikouras              Expires September 1999          [Page 1]


INTERNET-DRAFT            Fast Handoff Method              04 March 1998


Table of Contents

     1.0 Introduction
         1.1 Assumptions
         1.2 Acronyms
     2.0 Description of the Fast Handoff Method
         2.1 Overall Method and Architecture
         2.2 Mobile Node (MN) functionality for Fast Handoffs
         2.3 Foreign Agent (FA), Proxy Foreign Agent (PFA) and Top-
             level Proxy Foreign Agent (TPFA) functionality for
             Fast Handoffs
         2.4 Support of "forward" and "backward" MN movement
         2.5 Fast Handoffs applied to multiple BSs having
             common wireless overlap regions.
     3.0 Security Considerations
     4.0 References
     5.0 Author's Address



1. Introduction

     Mobile Nodes (MNs) will vary their point of attachment to the
     Internet frequently. MNs which move in this way suffer a period
     of communication breakdown due to the time needed to update the
     MNs' location information (i.e. registration with the Home
     Agent). During these periods MNs experience a service disruption
     which undermines the quality of real-time services.

     In this document a Fast Handoff method is described. This method
     eliminates the service disruption period due to handoffs by
     anticipating the MN's movement and using multiple bindings to
     direct the MN's traffic to the multiple locations which it may
     move to.

     Although some waste of bandwidth will occur, this is minor since
     it will only last for the very short period in which a MN lies
     in the wireless overlap region of two network access points. We
     identify the movement between two access points as comprising
     both a movement between BSs (Base Stations: layer 2 mobility)
     and a movement between Mobility Agents (MAs). This method does
     not rely on the assumption of single-MA networks, and is
     applicable to multiple-MA networks. Finally, the Fast Handoff
     method may be applied to scenarios in which a Mobile Node enters
     the wireless overlap region of multiple BSs, and not only two as
     considered above.






El Malki, Fikouras              Expires September 1999          [Page 2]


INTERNET-DRAFT            Fast Handoff Method              04 March 1998


1.1 Assumptions

     This method makes use of hierarchical agents and the
     Hierarchical Mobility Agent Extension [2]. It is also assumed
     that a FA will send advertisements containing its address and
     the addresses of all other PFAs in its hierarchical branch of
     the network using the PFA IP address extension [2]. These will
     be advertised in hierarchical order and this order cannot be
     modified.

     This method also assumes an underlying layer 2 protocol which
     allows a mobile node to receive and transmit contemporarily
     from/to multiple Base Stations (BSs) when in their wireless
     overlap region. A particular pattern of MN movement is not
     assumed, hence this method will provide seamless (loss-less)
     service to MNs moving "forward" and "backward" into any number
     of location and overlap regions.

     No limit is assumed regarding the number of MA levels in a
     hierarchy.



1.2 Acronyms

     MN          Mobile Node
     FA          Foreign Agent
     HA          Home Agent
     PFA         Proxy Foreign Agent
     TPFA        Top-level Proxy Foreign Agent
     MA          Mobility Agent. As such are described FAs, HAs, PFAs
                 and TFAs.
     ISP         Internet Service Provider
     COA         Care-of address
     PM          Prefix Matching
     ECS         Eager Cell Switching
     LCS         Lazy Cell Switching
     NAI         Network Access Identifier



2.0 Description of Fast Handoffs Mechanism

     The Fast Handoff mechanism allows efficient handoffs for MNs. It
     supports Local, Metropolitan and Wide-Area mobility. This method
     is of greatest efficiency using Local and Metropolitan mobility,
     which are the most frequent scenarios for a MN. Security is
     considered in this method.




El Malki, Fikouras              Expires September 1999          [Page 3]


INTERNET-DRAFT            Fast Handoff Method              04 March 1998


2.1 Overall Method and Architecture

             ....................................................
             .                                                  .
             .                GLOBAL INTERNET                   .
             ....................................................
                             /               \
                            /                 \
            +-------------------------+     +-------------------+
            |           ISP           |     |        ISP        |
            |          -----          |     |        -----      |
   Top      +---------|TPFA1|---------+     +-------|TPFA2|-----+
  Level                -----                         -----
                       /    \                          |
                   -----     \                         |
            Local | PFA |     \_______                 |
                   ----- \______      \                |
                 /      \       \      \               |
  Lowest    -----    -----   -----   -----           -----
  Level    | FA1 |  | FA2 | | FA3 | | FA4 |         | FA5 |
            -----    -----   -----   -----           -----
              |        |        |      |               |
              |        ----------      |               |
              |            |           |               |
              BS           BS          BS              BS
              |            |           |               |
              MN ------->  MN  ------> MN  ----------> MN

              1    1ov2    2    2ov3   3      3ov4     4


                Figure 1: Fast Handoff Network Topology


     Key: xovy = overlap area between the BSs in Pos. x and y

     The above diagram illustrates a general network architecture in
     which ISPs connect users through the Internet. Both single-agent
     and multiple-agent subnetworks are considered. In this scenario
     each ISP will host a Top-level MA or a Top-level Proxy Foreign
     Agent (TPFA). The function of a TPFA is to dynamically manage
     regional tunnels. Private networks (i.e. company networks) may
     have their own PFAs if they wish to manage tunnels locally.
     TPFAs and PFAs can provide fast handoffs by establishing
     multiple bindings (registrations) for moving MNs. The lowest
     levels of the MA hierarchy are occupied by FAs which provide
     network access to MNs. Although figure 1 presents only one level
     of FAs, any number of FA levels may exist below a given PFA.
     Furthermore, it is noted that FAs 1, 4 and 5 represent
     subnetworks with a single FA (i.e. single-agent subnetworks)


El Malki, Fikouras              Expires September 1999          [Page 4]


INTERNET-DRAFT            Fast Handoff Method              04 March 1998


     while FAs 2 and 3 exist within the same subnetwork (i.e.
     multiple-agent subnetworks). This configuration is typical of
     private organisations where multiple departments (each having a
     FA) are located within the same division or building floor and
     thus share communication resources. It is assumed in figure 1
     that the MN has a HA connected to a PHA which is located
     anywhere on the Internet (as in [2]), but is not presented for
     simplicity.

     Link layer connectivity is provided by the BSs. Each BS can
     service MNs within its area of coverage. The overlap of multiple
     areas of coverage forms an overlap region. These regions are
     labelled as xovy, identifying the overlap between the two
     positions (i.e. x and y). It is assumed that a wireless
     technology is available at Layer 2 which allows the MN to
     communicate with N BSs when in the overlap region of their
     coverage areas.

     All FAs are required to include in their advertisements the PFA
     IP address extension [2] which will list all PFA's and TPFA's in
     the same hierarchical "branch" in descending order. Thus, in
     figure 1 the TPFA is listed first in FA advertisements. MNs are
     required to cache these lists in order to determine common
     routes as they move.

     Generally the TPFA is the single point of access to the Internet
     for a hierarchy of PFAs. In Figure 1 a scenario is depicted
     where a PFA denotes a local private or public administrative
     domain. The PFA can identify an organisational/residential
     network or it can provide network access to MNs on the street,
     although this can be done by the TPFA as shown in Figure 1.

     The following types of mobility are considered:

     1)Local Mobilty (movements between Pos. 1 to Pos. 2) and
       Metropolitan-Area mobility (movement between Pos. 2 and Pos. 3)
     2)Wide-Area Mobility (movement between Pos. 3 to Pos. 4)



2.2 Mobile Node (MN) functionality for Fast Handoffs

     The handoff mechanism is described in this section. Below is a
     flowchart specifying the MN operations when performing a Fast
     Handoff. As mentioned previously, TPFAs and PFAs are capable of
     supporting multiple simultaneous bindings for a MN.





El Malki, Fikouras              Expires September 1999          [Page 5]


INTERNET-DRAFT            Fast Handoff Method              04 March 1998


     It is assumed that the MN, upon movement from the Home network
     to a Foreign network, will cache the TPFA/PFA address hierarchy
     from the PFA IP address extension [2] present in FA agent
     advertisements. In the case of FA1 the extension would include
     the Local PFA and TPFA1.

     Some FAs may choose to advertise only Local PFAs. For example,
     an organisation comprising the Local PFA, FA1, FA2 and FA3 may
     not want to advertise the TPFA or any other higher PFAs which
     may exist in between. However this will prevent users from
     performing seamless handoffs between the organisation's network
     and the rest of the Internet. That is, fast and seamless
     handoffs would not be available for movement from position 2 to
     3 or 2 to 4.

     In figure 1 it is assumed that the MN has powered up in position
     1. Having no prior record of a hierarchy it operates as per [2]
     and issues a Registration Request using as COA (Care-of-address)
     the IP address of the TPFA. It is assumed that this Request
     updates the HA's MN location information, that the MN is granted
     network access and that the MN caches the list of PFAs (CURRENT
     PFA list) received in the FA agent advertisement. The MA
     activity in response to the Request is presented in section 2.3.

     It is assumed that MNs keep record of all the FAs from which
     they have received an agent advertisement ("known" Agents) even
     if they belong to different subnetworks. Similarly, the MN keeps
     record of "known" subnetworks. These are subnetworks in which
     "known" Agents lie. Furthermore, MNs are required to keep record
     of all established bindings. Optionally the MN may keep record
     of PFA IP address lists.

     Even though all "known" FAs hold the same status, only one FA is
     the "primary" FA. The binding associated with that FA is always
     updated by requesting a long lifetime and the PFA list
     associated with the "primary" FA is considered as CURRENT.
     Bindings associated with all the FAs, except for the "primary"
     FA, are updated by requesting a short lifetime (3 *
     advertisement rate). In this way the method is able to
     distinguish between the primary traffic flow and auxiliary
     traffic flows. The purpose of auxiliary flows is to anticipate
     MN movement into a new subnetwork. In Figure 1, when the MN
     moves from Position 1 to 1ov2, FA1 will be the "primary" FA
     while FA2 will receive and provide the MN with the auxiliary
     traffic flow.

     "Known" FAs whose lifetime has expired are removed, and so is
     all cached information associated with them (i.e. bindings,
     entries in "known" subnetwork list and PFA IP address lists).
     Using the list of "known" agents and subnetworks, in conjunction


El Malki, Fikouras              Expires September 1999          [Page 6]


INTERNET-DRAFT            Fast Handoff Method              04 March 1998


     with PM (Prefix Matching) and the NAI (Network Access
     Identifier), can help detect MN movement into new subnetworks.

     Since a MN may maintain simultaneous bindings with MAs, this
     method assumes a hybrid LCS-ECS movement detection method with
     PM or NAI support. That is, MNs are Eager to request
     simultaneous bindings when movement is detected by PM or NAI
     domain comparison, but are Lazy to abandon established bindings.
     This behaviour has been integrated in the flowchart presented
     below.

     The following flowchart illustrates the Fast Handoffs procedure
     for MNs when moving between FAs:



      .-----------> .-> Has the lifetime of a "known" FA expired ? .NO
      |             |                |                             |
      |             |                |YES                          |
      |             |                |                             |
      |             |     Remove FA from the "known" FAs list.     |
      |             |       De-cache associated PFA list.          |
      |             |       Delete all associated bindings.        |
      |             |      (MN is Lazy to abandon bindings)        |
      |             |                |                             |
      |             |                |                             |
      |             |                |                             |
      |             |  Has the "primary" FA expired ? ------------>|
      |             |                |                          NO |
      |             |                |YES                          |
      |             |                |                             |
      |             |  Use FA with longest outstanding lifetime    |
      |             |         as "primary" FA.                     |
     /|\           /|\    Get a new CURRENT PFA IP address         |
      |             |             extension list.                  |
      |             |                |                             |
      |             |                |                             |
      |             |                |                             |
      |             |   Received any successful Registration <-----.
      |             |             Replies ? ---------------------->.
      |             |                |                  NO         |
      |             |                |YES                          |
      |             |                |                             |
      |             |     Cache associated binding and             |
      |             |     optionally PFA IP address list.          |
      |             |       Add FA to "known" FAs list.            |
      |             | Add FA's subnet to "known" subnetworks list. |
      |             |                |                             |
      |             |                |                             |
      |             |                |                             |


El Malki, Fikouras              Expires September 1999          [Page 7]


INTERNET-DRAFT            Fast Handoff Method              04 March 1998


      |             |      Are there any bindings about  <---------.
      |             |             to timeout ?         ----------->.
      |             |                |                       NO    |
     /|\           /|\               |YES                          |
      |             |                |                             |
      |             |     Update bindings by sending a             |
      |             |     Registration Request with the            |
      |             |    IP address of the corresponding PFA       |
      |             |          or TPFA as the COA.                 |
      |             |      Do not set the S bit ON.                |
      |             |                |                             |
      |             |                |                             |
      |             |<-- Received new FA Advertisements ?  <-------.
      |             | NO      (not a "known" FA)
      |             |                |
      |             |                |YES
      |             |                |
      |             |    Does PM or NAI comparison indicate
      |             .<---- discovery of a new subnet ?
      |               NO             |
      |                              |YES
      |                              |
      |                   Movement has been detected.
      |                 Cache PFA IP address extension
      |                     list (NEW PFA list).
     /|\                             |
      |                              |
      |                 Find Common PFA by comparing
      |                  CURRENT and NEW PFA lists.
      |                              |
      |                              |
      |                    Is there a Common PFA ?
      |                       /                \
      |                 YES  /                  \ NO
      |                     /                    \
      |    Send a Registration Request       Send a Registration Request
      |    using the Common PFA as COA       using the TPFA as COA. Set the
      |    Set the S bit ON to request a     S bit ON to request a simultaneous
      |    simultaneous binding. Use a       binding. Use a short lifetime
      |    short lifetime (i.e.              (i.e. 3 * advertisement rate).
      |    3 * advertisement rate).          The MN is Eager in establishing
      |    The MN is Eager in establishing   new bindings.
      |    new bindings.
      |                    |                      |
      |                    |                      |
      |                    |                      |
      |                   \|/                    \|/
      .<------------------------------------------.




El Malki, Fikouras              Expires September 1999          [Page 8]


INTERNET-DRAFT            Fast Handoff Method              04 March 1998



     When the MN moves into the overlapping region of multiple
     subnetworks, it will receive agent advertisements containing the
     PFA IP address extension lists. The MN will therefore be in the
     position to determine if there is a Common PFA which could
     potentially send traffic for the MN to both its old and new
     location. If PM or NAI indicate movement into a new subnetwork
     then the MN will send a Registration Request.

     If there is a Common PFA the MN sends a Registration Request
     with the Common PFA as COA (N.B. the TPFA could be the Common
     PFA). Otherwise, if there is no Common PFA, the MN will use the
     TPFA as the COA. The S bit is set ON only when a Common PFA is
     found, such that the Common PFA maintains simultaneous bindings
     with the MN. In this case the Common PFA will "multicast"
     traffic to both MN's registered locations.

     When the "primary" FA changes, a new Registration Request is
     issued without setting the S bit. This causes the Common
     PFA/TPFA to replace the simultaneous bindings held previously
     with a single binding for the MN's current location.



2.3  Foreign Agent (FA), Proxy Foreign Agent (PFA) and Top-level
     Proxy Foreign Agent (TPFA) functionality for Fast Handoffs

     Upon receipt of a Registration Request, the FA will add the
     Hierarchical Mobility Extension. The FA will add its own address
     to this extension. The FA is aware of the next higher PFA which
     it already includes in its advertisements. It will therefore
     send the packet to the next higher PFA. Intermediate FA levels
     act as simple routers and relay the Request.

     Each PFA will check whether its address corresponds to the COA.
     If they do not correspond then the PFA adds its address to the
     hierarchical agent extension list (hence forming the PFA IP
     address extension list) and sends the Request onto the next
     higher PFA which is known and included in all MA advertisements.

     However, if the PFA's address corresponds to the Request's COA
     then the PFA will authenticate the MN and terminate the Request.
     If the Request has the S-bit set then the PFA will add a
     simultaneous binding for the MN using the next lower level PFA
     (or FA) as destination. If the S bit is not set then it will
     replace the old binding it had for the MN with a new one using
     the next lower level PFA (or FA) as destination.





El Malki, Fikouras              Expires September 1999          [Page 9]


INTERNET-DRAFT            Fast Handoff Method              04 March 1998


     If the Request reaches the TPFA, and the TPFA is not the COA,
     then the TPFA relays the registration to the PHA. However, if
     the TPFA is the COA then it acts as a regular PFA.

     Registration Requests that are accepted produce a Registration
     Reply. All Registration Replies contain the PFA IP address
     extension list (Hierarchical Mobility Agent extension). This is
     the same extension received in the Request, but inverted. It is
     always relayed to the next lower level PFA. Its address is known
     since it is present at the top of the PFA IP address list of the
     Registration Reply.

     Upon receiving a Registration Reply the PFAs will check if their
     address is contained in the PFA IP address extension list. If so
     the PFA will add a binding for the MN using the next PFA (or FA)
     address in the list as destination. It will then send the Reply
     to the next lower PFA (or FA) by using the next PFA IP address
     in the list.

     In this way every TPFA/PFA in the hierarchy branch will create a
     binding for the MN with a PFA below in the hierarchy. The
     advantage of this approach is that when the MN traffic flow has
     to change part of its route as a result of MN movement then this
     will affect only certain TPFA/PFAs and not every MA in the
     branch. The disadvantage of this approach is that every TPFA/PFA
     is the tunnel endpoint for a MA above itself in the hierarchy
     but also a tunnel startpoint for a MA below in the hierarchy. As
     the process of detunneling and tunneling can prove very
     demanding it is proposed that MAs will in this case avoid
     detunneling. Instead it is preferred that the MA only change the
     appropriate fields in the outer (encapsulation) header of
     incoming encapsulated traffic. "Multicasting" can occur by
     cloning that same encapsulated traffic.

     The TPFA or PFA will authenticate the MN upon receiving its
     Registration Request. If the Request cannot be authenticated
     then the TPFA or PFA will issue a Registration Reply with a code
     of 67 (MN failed authentication). (see 3.0)



2.4 Support of "forward" and "backward" MN movement

     This method does not assume that the MN will only move "forward"
     to a new network. The MN may move into the overlap region of
     networks and then move back to its original position. Consider
     the following MN movement:

     Pos.1 --> Pos. 1ov2 --> Pos.1



El Malki, Fikouras              Expires September 1999          [Page 10]


INTERNET-DRAFT            Fast Handoff Method              04 March 1998


     When the MN moves to Pos. 1ov2, the Fast Handoff method will
     cause the Local PFA to "multicast" traffic for the MN to both
     FA1 and FA2. This is done by establishing a new auxiliary route
     (simultaneous binding) between the Local PFA and FA2. This has a
     short lifetime and will be renewed as long as the MN stays in
     Pos. 1ov2. However, when the MN moves back to Pos. 1 the
     lifetime of the binding between the Local PFA and FA2 will
     elapse and the "multicasting" will stop.

     The Fast Handoff method is therefore independent of particular
     MN movement patterns.



2.5 Fast Handoffs applied to multiple subnetworks having a wireless
    overlap region.

     Let us consider a situation in which the MN lies in the overlap
     region of multiple subnetworks. Moreover, let us assume that at
     least one of the subnetworks consists of multiple advertising
     MAs. Depending on the protocol that communicates PFA IP
     addresses to all the MAs in the hierarchy and determines its
     structure, it is possible that even MAs in the same subnet might
     advertise different PFA IP address extension lists.

     Normal ECS [3] operation would force the MN to request a binding
     for every newly discovered MA. In the case presented this might
     cause traffic "multicasting" at multiple PFAs in the hierarchy.
     For this reason the presented method requires a "known"
     subnetworks list and the use of PM [3] or NAI to distinguish
     between advertisements coming in from known and unknown
     subnetworks. Unknown subnetworks are only the ones for which a
     MN should request a new binding.

     In the described method this functionality is provided by
     keeping a list of "known" FAs and subnetworks and using either
     PM or NAI (tenth step in the flowchart). Thus, as the MN enters
     a new multiple-agent subnetwork it will only request an
     additional binding for the first encountered MA.



3.0 Security Considerations

     It is assumed that there is a secure association between the
     PFAs (including the TPFA) and all the FAs in its hierarchy, in
     order to prevent intruders from impersonating as PFAs. Moreover,
     a secure association between the TPFA and the HA or PHA as in
     [2] is assumed.



El Malki, Fikouras              Expires September 1999          [Page 11]


INTERNET-DRAFT            Fast Handoff Method              04 March 1998


     Potentially a MN can be authenticated by multiple PFAs/TPFA in a
     hierarchy. A Registration Request that is positively
     authenticated will result in a positive Registration Reply. As
     the Reply is being relayed through all the PFAs in the hierarchy
     new bindings are created and the MN authentication is recorded
     for future reference. This means that in the future, when a PFA
     receives a Registration Request with its IP address as COA it
     may authenticate it and issue a Reply. Otherwise, if the Request
     cannot be authenticated, a Reply with code 67 (MN failed
     authentication) is issued.

     On receipt of a positive Registration Reply, the FA which hosts
     the MN may grant it with network access. If this Reply is not
     received or is negative the FA will block network access to the
     MN (this case is considered by RFC 2002).

     It is assumed that encryption will exist on the wireless medium
     at the link-layer. This will stop intruders from intercepting
     data on the wireless segments.



4.0 References

[1] C. Perkins, Editor, "IP Mobility Support", RFC 2002, October
    1996.
[2] P. R. Calhoun, G. Montenegro, C.E. Perkins, "Mobile IP
    Regionalized Tunnel Management", Internet draft (work in progress),
    draft-ietf-mobileip-reg-tunnel-00.txt, November 1998.
[3] C.E. Perkins, "Mobile IP", Addison-Wesley, ISBN 0-201-63469-4,
    1998.



5.0 Author's Address

     Any query may be directed to:

     Karim El Malki                         Nicholas A. Fikouras
     Dept. of Computer Science              Dept. of Computer Science
     The University of Sheffield            The University of Sheffield
     211 Portobello Street                  211 Portobello Street
     Sheffield S1 4DP, U.K.                 Sheffield S1 4DP, U.K.

     Phone:  +44-114-2221935                Phone:  +44-114-2221873
     Fax:  +44-114-2221810                  Fax:  +44-114-2221810
     E-Mail:  karim@dcs.shef.ac.uk          E-Mail:  nick@dcs.shef.ac.uk





El Malki, Fikouras              Expires September 1999          [Page 12]