IETF Seamoby Working Group                           Dirk Trossen
  INTERNET-DRAFT                               Govind Krishnamurthi
draft-ietf-seamoby-cardiscovery-issues-02.txt
  draft-ietf-seamoby-cardiscovery-issues-03.txt      Hemant Chaskar
15 January
  12 June, 2002                                               Nokia
                                                        James Kempf
                                                             DoCoMo
               Issues in candidate access router discovery
                      for seamless IP-level handoffs

  Status of This this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. RFC 2026.
   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 Internet-
   Drafts.
   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or made obsolete 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 ``work in
  progress."
   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.

  Copyright Notice notice

   Copyright (c) The Internet Society (2001). (2002). All rights reserved.

ABSTRACT

  Abstract

   Handoff in IP mobility protocols involves moving a mobile node's
   Layer 3 routing reachability point from one access router to
   another, before or after the mobile node has established a Layer 2
   connection with the radio access point that is covered by the new
   access router. In addition, other context information about the
   mobile node's packet
session IP service may be transferred from the old access
   router to the new one, in order to minimize the service disruption
   during the handoff process. While the exact details of how this is
   accomplished vary depending on the IP mobility and seamless handoff
   protocols, one common thread required for seamless IP-level handoffs is identifying
   discovering the candidate access routers for the mobile node's
   handoff. Discovering the candidate access router involves
   identifying its IP address as well as its capabilities that the
   mobile node might be interested in. At the time of IP-level handoff,
   if a collection of candidates has been is identified, an algorithm is run to
   determine the target access router for the mobile node's handoff.
   This document presents a describes the problem statement describing issues involved in designing a of candidate access router discovery protocol.
   discovery. The document does not discuss the algorithm by which the
   actual target access router is selected, nor how the handoff to the
   target is achieved.

  TABLE OF CONTENTS

                             Table of Content
   1. INTRODUCTION                                           1 INTRODUCTION...................................................3
   1.1. Seamless Handoff Protocols...................................3
   1.2. Choice for Handoff...........................................3
   2. TERMINOLOGY....................................................4
   3. MOTIVATION FOR CAR DISCOVERY                           1

    3. TERMINOLOGY                                            2 DISCOVERY...................................4
   4. APPROACHES TO CANDIDATE ACCESS ROUTER DISCOVERY        3

       4.1 Anticipated CAR Discovery                          3
       4.2 Dynamic CAR Discovery                              4
       4.3 Hybrid CAR Discovery                               5

    5. SPECIFIC ISSUES IN THE CAR DISCOVERY                       5

       5.1 Identifying GAARs                                  5
       5.2 PROBLEM......................................6
   4.1. CAR IP Address Discovery.....................................6
   4.2. Identifying capabilities Capabilities of GAARs                  7

    6. CAR..............................7
   5. SECURITY CONSIDERATIONS                                8 CONSIDERATIONS........................................7
   6. ACKNOWLEDGEMENTS...............................................7
   7. APPLICABILITY OF EXISTING PROTOCOLS                    8 REFERENCES.....................................................7
   8. ACKNOWLEDGEMENTS                                       8

    9. REFERENCES                                             9

    10. AUTHORS' ADDRESS                                     10 ADDRESSES.............................................8

1. INTRODUCTION

   IP mobility protocols enable mobile nodes (MNs) to change the access
   routers (ARs) by which they obtain the Layer 3 connectivity to the
   Internet, while communicating with another node over the Internet.
   An AR providing Internet connectivity to the MN changes when the there
   is a change (usually as a result of movement of the MN causes a change MN) in the radio
   access point (AP) through which the MN communicates with the wired
   network, such that the AR serving the new radio access point AP is in a new subnet.
   There are existing solutions [1, 2] that enable MNs to execute IP-level IP-
   level handoffs between the ARs.

1.1. Seamless Handoff Protocols

   Additionally, work is underway [3, 4, 5, 6, 7], to define protocols
   that would allow seamless, meaning low latency and low packet loss,
   handoffs of MNs between the ARs. These seamless handoff solutions
   assume that the identity (IP address) (wireless) link protocol is capable of delivering a
   Layer 2 identifier for the target new AP or the radio interface of new AR is known
   [8] to the current AR. They do not provide a solution to the
problem of selecting the target AR for  or to the MN's handoff. What is
required is a protocol MN, and require that would allow an the current AR or an MN
   be able to translate this Layer 2 identifier to discover
the neighboring ARs whose capabilities meet the requirements IP address of
a MN, thus becoming potential target ARs for handoff. Such ARs are
called "Candidate ARs". This information can be used for selecting
   the target new AR at in order to facilitate  the time of MN's seamless handoff. This draft discusses In addition
   to simply providing the
issues involved in Layer 2 to IP address mapping, the problem of Candidate AR discovery. The draft
does not discuss needs
   some way to determine if the problem Layer 2 identifier is that of selecting the target a
   legitimate AP or AR to which
handoff or whether it is performed, nor the handoff process itself.

To an imposter. Some link layers
   provide motivation Layer 2 security mechanisms for the Candidate AR discovery work, some
illustrative scenarios are given below in which Candidate AR
discovery protocol this purpose.

1.2. Choice for Handoff

   In future mobile networks, there will be useful.

2. MOTIVATION FOR CANDIDATE AR DISCOVERY

This section describes some seamless handoff features that can be
implemented if there are means to identify the Candidate ARs for
the MN's handoff.

Scenario 1: Load balancing

Consider an AR to which an MN is currently attached. This AR is
denoted by AR1. Further, assume that AR1 is heavily loaded. Suppose
there is another AR, denoted by AR2, that is reachable from the
attached cases when MN and is not heavily loaded. If AR2 has the capabilities to
satisfy the MN's requirements, AR1 can initiate a handoff choice
   of the MN
to AR2 performing IP-level handoff to alleviate some of its own load. a different AR. For this, AR1 needs to have
the knowledge of the capabilities of AR2 and the load on AR2. Such an
information sharing can be achieved with the help of Candidate AR
discovery protocol.

Scenario 2: Resource intensive applications

Consider example, an MN running a streaming video application, which might be
an important application for the future mobile networks. These

applications require high bandwidth
   having network interface cards supporting two or more wireless
   access technologies (such as, 3G and possibly other QoS support to
be available at the AR serving the MN. When this MN moves into the
coverage area wireless LAN) and communicating
   over one of them, may wish to switch to a new AR, different access network
   if it is possible feels that the new AR does not
have the capability to support the MN's application. The MN can then
be informed about this fact when it is still connected to the current
AR. Clearly for this, the current AR needs to have information about IP service offered by the capabilities latter better suits
   its requirements. A generalization of the neighboring ARs, and this can be achieved
using the Candidate AR discovery protocol.

Scenario 3: Least-cost phone call

Consider the preference expressed by case is when the MN to prioritize handoffs
to an AR with minimal cost has a
   choice of different APs (of possibly different media and access for phone call ('least cost
policy'). Due
   technologies) connected to different ARs, for the real-time nature sake of the service, seamless
handoffs are preferred to minimize
   maintaining Internet connectivity. These different ARs may have
   different capabilities (different service disruption. In addition, providers, different load
   conditions, different wired QoS availability, etc.). The MN requires
   some means of obtaining information about the 'cost capabilities of access' capability information, if available, is
included in these
   ARs so that the target AR selection process as an MN-specific
preference.

Scenario 4: Adaptability to change in best decision about the coverage topology

Consider handoff target can be made.
   Note that there might be scenarios when a situation in which handoff is essential to at
   least one of these ARs (old connection is fading fast) as well as
   those when MN may be temporarily introduced in
hot-spots to cater to the existing traffic demand. In such a case, live without performing a static configuration handoff to any of the neighborhood information in these
   ARs (coverage of new AR is not
feasible as subsumed within that of the operators current AR).
   Further, depending upon the handoff scenario, seamless handoff
   protocols may or may not inform each other of temporary
changes. A protocol is therefore needed be used.

   The two problems are linked in such cases so the sense that an AR
can automatically identify any change in they both involve
   determining the coverage topology and
exchange capability information with about a new AR (IP address and
   capabilities) that is a candidate for the neighboring ARs. This can
be facilitated by next handoff. In this
   document, we discuss the problem of Candidate AR discovery protocol.

3. Access Router (CAR)
   discovery.

2. TERMINOLOGY

   Access Point (AP)

   A radio transceiver by which an MN obtains Layer 2 connectivity
   with the wired network.

   Access Router (AR)

   An IP router residing in an access network and connected to one
  or more APs. An AR offers IP connectivity to MN.

Geographically Adjacent AR (GAAR)

  An AR whose coverage area is such that an MN may move from the
  coverage area of the AR currently serving the MN into the coverage
  area of this AR. In other words, GAARs have APs whose coverage
  areas are geographically adjacent IP router residing in an access network and connected to one or overlap.
   more APs. An AR offers IP connectivity to MN.

   Capability of AR

   A characteristic of the IP service offered by an AR that may be of
   interest to an MN when the AR is being considered as a handoff
   candidate.

   Candidate AR (CAR)

  This is an AR that is a candidate for MN's handoff. CAR is
  necessarily a GAAR of the AR currently serving the MN, and also has
  the capability set required to serve the MN.

Target AR (TAR)

  This is an AR with which the procedures for the MN's IP-level
  handoff are initiated. TAR is usually selected from the set
  of CARs.

TAR Selection Algorithm

  The algorithm that determines a unique TAR for MN's handoff from
  the set of CARs. The exact nature and definition of this algorithm
  is outside the scope of this document.

4. APPROACHES TO CANDIDATE ACCESS ROUTER DISCOVERY

In this section, we describe three approaches to CAR discovery,
namely the Anticipated CAR Discovery (discovery prior to handoff),
Dynamic CAR Discovery (discovery at the time of handoff) and Hybrid
CAR Discovery.

4.1 Anticipated CAR Discovery

In Anticipated CAR Discovery, CAR discovery is performed at some
point prior to the MN performing a handoff. This can be performed in
a number of ways and with various entities participating in the
process. One illustrative method for Anticipated CAR Discovery is
given below.

In this method, an

   An AR currently serving an MN can identify a set of
CARs for the MN's handoff, at some point prior to handoff. This
information is then available at the time of handoff as input to the
TAR Selection Algorithm. Another input to the TAR Selection Algorithm
may be the preferences expressed by the MN prior to the handoff, or
preferences enforced by the administrative control. At the time of
handoff, it may only be required to provide input to the TAR
Selection Algorithm about the reachability of neighboring ARs from
the MN. This reachability information is usually in the form of the
identity of the AP to which the MN can listen to, and the current AR has to resolve this AP identity to the GAAR's IP address.

The advantage a choice of Anticipated CAR Discovery is performing IP-level handoff. This
   means that MN has the handoff can be
executed quickly because much of the information needed right radio interface to connect to an AP that
   is served by this AR, as well as the TAR
Selection Algorithm is collected in advance of handoff.

Anticipated CAR Discovery is depicted in Figure 1.

    -----------------------------------------------------------------
   |                     All routers                                 |
   |                          |  Discovery of ARs whose coverage     |
   |                          |  areas overlap (GAARs) of this AR overlaps
   with that of  |
   |                          v the current AR                      |
   |           Local map of GAARs at current to which MN is currently attached to.

   Target AR                      |
   |                          |                                      |
   |                          |   Capability identification          |
   |                          v                                      |
   |      CARs for MN's handoff identified at current (TAR)

   An AR             |
   |                          |                                      |
    --------------------------|--------------------------------------
                              |
                              |   Predefined preferences of with which the MN
         AR Reachability      |   and administrative preferences procedures for the MN         |
                |             |             |
                v             v             v MN's IP-level handoff are
   initiated. TAR is selected after running a TAR Selection Algorithm executed at
   that takes into account the time capabilities of CARs, preferences of
             handoff to determine unique TAR for MN's handoff

              Figure 1: Anticipated CAR Discovery

4.2 Dynamic CAR Discovery

In Dynamic CAR discovery, CAR discovery is performed at the time the MN is about to undergo handoff. Again, this
   and any local policies.

3. MOTIVATION FOR CAR DISCOVERY

   This section describes some features that can be performed in a
number of ways and implemented with various entities participating in
   the process.
One illustrative method for Dynamic help of CAR Discovery is given below.

According discovery protocol.

   Scenario 1: Load balancing

   Consider an AR to this method, which an MN dynamically obtains information about
the available ARs for handoff, along with their capabilities. is currently attached. This AR is
done after
   denoted by AR1. Further, assume that AR1 is heavily loaded. Suppose
   there is another AR, denoted by AR2, that is reachable from the handoff trigger
   attached MN and is generated. When not heavily loaded. Then, MN may decide to
   undergo handoff to AR2. Such load balancing can be achieved using
   the capability information about AR2 obtained via CAR discovery
   protocol.

   Scenario 2: Resource intensive applications

   Consider an MN detects running a streaming video application, which might be
   an
AR that has capabilities matching its preferences, important application for the MN may notify future mobile networks. These
   applications require high bandwidth and possibly other QoS support
   to be available at the currently serving AR to perform a handoff to serving the MN. When this AR using one or
more of MN moves into
   the seamless handoff protocols. The advantage coverage area of this method a new AR, it is possible that the MN has fine-grained control over the TAR selection.
However, this method generates more radio traffic during new AR does
   not have the CAR
discovery step. This is because capability information is sent to support the MN's application. The MN over the air. Also, can
   then be informed about this fact when it is required that the MN can receive
IP-level capability information from the GAARs and negotiate
requirements with the GAARs, while still being connected to the
   current AR.

Dynamic CAR Discovery is shown in Figure 2.

       --------------------------------------------------------------
      |                                                              |
      |                 GAARs identified at handoff time             |
      |                           |                                  |
      |                           | Capability identification        |
      |                           |                                  |
      |                           v                                  |
      |            CARs Clearly for MN's handoff identified                  |
      |                           |                                  |
       ---------------------------|----------------------------------
                                  |
                                  | TAR selection at this, it is necessary to have the
                                  |    time of handoff
                                  v
                        Unique TAR identity

                  Figure 2: Dynamic CAR Discovery

4.3 Hybrid CAR Discovery

In practice, a hybrid knowledge
   of the Anticipated and Dynamic CAR discovery
approaches may be used. For example, in the hybrid approach, the GAAR
discovery and much capabilities of the capability identification may neighboring  ARs, and this can be performed
prior to handoff, while the remaining capability identification may
happen during
   obtained using the handoff process. But,there are other
alternatives too.

5. SPECIFIC ISSUES IN CAR DISCOVERY

The following sections describe discovery protocol.

   Scenario 3: Least-cost phone call

   Consider the specific issues in preference expressed by the CAR
discovery, may it be done in anticipated, dynamic or hybrid way.

5.1 Identifying GAARs

A basic requirement MN to prioritize handoffs
   to an AR with minimal cost of access for a new phone call (``least cost
   policy"). The ``cost of access" capability of an AR to can be considered as a obtained
   using CAR for MN's
handoff is that the coverage area of discovery protocol.

   Scenario 4: Adaptability to change in the new AR coverage topology

   Consider a situation in which ARs may be "geographically"
adjacent temporarily introduced in
   hot-spots to cater to or overlapping with that of the AR currently serving the
MN. existing traffic demand. In other words, such a new AR must be case,
   a GAAR. Note, the geographical
vicinity static configuration of the coverage areas of two neighborhood information in ARs is not necessarily implied
by their "logical" adjacency. Logical adjacency
   feasible as the operators may not inform each other of two ARs means that
there temporary
   changes. A protocol is just one IP hop between the two ARs, while therefore needed in such cases for the adjacency of MN to
   automatically identify any change in the coverage areas topology and
   identify the capabilities of two ARs implies that the MN neighboring ARs. This can actually move
from the coverage area of one AR to another (GAARs have APs whose
coverage areas are adjacent or overlapping). Conversely, GAARs need
not be logically adjacent, and may even have IP addresses in
different administrative domains.

The MIP fast
   facilitated by the CAR discovery protocol.

   Scenario 5: Inter-technology handoff protocols specified in [3] and [4] or

   Consider the
context transfer framework specified case in [6] require that the current
AR or Foreign Agent (FA) (generically called ARs here for short) have which an MN has a list variety of ARs wireless access
   network media available to which it, and also possibly a wired interface.
   Theoretically, the MN could be handed over. In other words, the
current AR has bring  up each interface and solicit a list
   Router Advertisement on it, but as the number of CARs. There is no reason, interfaces becomes
   larger, such a priori, why
these CARs need to in topologically adjacent subnets. A CAR could
potentially be procedure results in a completely different BGP autonomous system. The
only requirement is that the corresponding APs larger and larger drain on
   power. An alternative would be geographically
adjacent. Fig. 3 illustrates the problem.

    BGP Autonomous                 BGP Autonomous
       System A                      System B

       +----+                         +----+
       | BR |--->  The Internet   <---| BR |
       +----+    (aka Cyberspace)     +----+
       /                                   \
      /                                     \
+----+                                      +----+
| IR |                                      | IR |
+----+                                      +----+
   |                                           |
   |                                           |
+----+                                      +----+
| AR |                                      | AR |
+----+                                      +----+
   |                                           |
   |___________________        ________________|
                |      |       |    |
      ...       |      --     --    |      ...
                |      \/     \/    |
                |                   |
                |_______      ______|
                |       |    |      |
                |      --    --     |      The Physical World
                |      \/    \/     |        (aka Geospace)
                |                   |
                |______      _______|
                       |     |
  --                  --     --
  \/  = AP            \/     \/

          Figure 3: GAAR Discovery Problem

In the figure, if the APs MN could solicit for
   alternative AR choices on an active interface, and use this
   information to choose handoff target.

4. THE CAR DISCOVERY PROBLEM

   There are shown connected two basic problems associated with CAR discovery:

   1) Mapping from a Layer 2 identifier for an AP to ARs in completely
different BGP autonomous systems, but the same problem occurs
if IP address of
   the APs are geographically adjacent and CAR

   2) Identifying the ARs capabilities of CAR

   The two problems are related in subnets that both are topologically distant within an autonomous system. The
criterion for an AR to be concerned with
   obtaining IP-level information about a candidate CAR for an MN's handoff is the
geographical adjacency purposes of
   determination of the AP served by it to that target access router for handoff.
   We discuss these two problems in the following subsections.

4.1. CAR IP Address Discovery

   The seamless handoff protocols defined in [3, 4, 5, 6, 7] require a
   certain amount of IP level signaling between a MN's current AR and
   the AP target AR to which the MN is currently attached, will undergo handoff or has undergone
   handoff. For [3] and not the topological adjacency

of [4], the corresponding ARs. Hence, IP signaling is required to rearrange
   routing protocols, such as OSPF
[8] or BGP [9], are not for a Mobile IP handoff when the solutions MN's link moves to GAAR discovery problem.

One approach the
   target AR. For [5], [6], and [7], the signaling is required so that
   the current AR can transfer IP service context to manually configure this geographical neighborhood
at each the target AR. However, such an approach has disadvantages and in many
cases, IP
   service context may not be feasible. For instance, include QoS state, AAA state, etc. Being able to
   quickly set up IP service context on the GAARs may be under
different administrative control, and thus, are not informed about
each other's presence. Even within target AR is important
   because it determines how quickly the same administrative domain, MN will receive the manual configuration approach demands much network planning in
terms same level
   of IP service on the coverage areas of different ARs. Finally, target AR as it received on the manual
configuration approach is not suitable if old. In order
   for the ARs can be physically
relocated or their coverage area changed, thus altering IP level signaling to occur, the
geographical scope current AR requires the IP
   address of their coverage areas. Such a scenario is very
common when ARs are temporarily introduced in hot spots. Clearly, the target AR.

   Typically, the seamless handoff protocols assume that the MN knows a
more automatic and dynamic mechanism is needed
   Layer 2 identifier for the wireless AP or AR to discover GAARs
without much administrative intervention.

For which it may undergo
   a handoff. The Layer 2 identifier might be obtained when the Anticipated CAR Discovery method described in Section 4.1, MN has
   Layer 2 beacon contact with the AP. It is now the process task of identifying GAARs requires a the CAR
   discovery protocol that allows ARs is to exchange enable mapping from the information about Layer 2 identifier
   to the geographical adjacency of their
APs, in advance IP address of handoff. In the Dynamic CAR Discovery method
described in Section 4.2, the MN automatically that serves as this AP.

   This problem is not dissimilar to reverse address resolution [9] or
   to the judge use of DHCP [10] to obtain the address of
whether an AR is a GAAR. host based on its
   MAC address. In the latter current case, if however, the MN can hear reverse address
   translation is occuring across subnets for ARs rather than between a
Router Advertisement of
   host and a server. Another added twist is that the actual L2
   identifier may be for the new wireless AP and not for  the new AR, then
   whereas the current AR requires the new AR is GAAR.

5.2 IP address. Any solution
   to this problem must provide for dynamic autoconfiguration of
   reverse address resolution, so that ARs and APs that are added and
   removed can be quickly discovered without requiring much, if any,
   human intervention.

4.2. Identifying capabilities Capabilities of GAARs: CAR

   Although not common now, the future generation mobile networks may
   consist of ARs that are GAARs of each other, offer coverage in the same geographical area but
   are heterogeneous in
administrative control, functionality, link layer technology and
resources. An MN that capabilities. The basic functionality shared by
   all IP routers is attached to a given AR may have specific
requirements as regards these parameters. For example, the MN may
need some hardware or software support from the AR or need some
application servers topologically close to the AR, to run certain
IP-based applications. Support for QoS, security, multicast, header
compression etc. are some other aspects that need to be considered
when choosing the CAR for MN's handoff. It may also be required to
assure some security association, policy agreement or billing
contract between the current AR and its GAARs in order to allow
MN's handoff between them. Finally, the access routers of packet forwarding. In that respect, all
   ARs are GAARs
of each other need similar. However, heterogeneity may arise among different
   ARs due to exchange information regarding the
correspondence between their IP addresses factors such as additional functions performed by ARs
   (seamless handoff support, security functions, wireless performance
   enhancing functions, etc.), administrative and the identities business aspects of the
APs (which the MN can listen to) that are connected
   providing service to them.

Clearly, a protocol MN (service provider, cost of access, etc.),
   availability of certain type of resources with AR (QoS availability)
   etc. A solution is needed that would enable will allow the functions such as
solicitation and exchange MN to learn the
   capabilities of capability information among MN, ARs and
other network entities.

6. CARs that it might be interested in. CAR discovery
   protocol enables this.

5. SECURITY CONSIDERATIONS

   CAR discovery may allow other nodes to learn the following pieces of information about an AR:

- Physical location
- Capabilities
- State of
   AR, including its IP address and capabilities. Malicious nodes may
   use this kind of information to launch DoS attacks of
the DoS-style and/or service
   hijacking. Therefore, the following topics should be covered in any protocol
   solution developed for CAR discovery:

   - Authentication of nodes
   - Security associations between nodes
   - Message/payload encryption.

7. APPLICABILITY OF EXISTING PROTOCOLS TO CAR DISCOVERY PROBLEM

The simplest possible discovery solution is to statically configure
the ARs in two geographically adjacent domains with the IP addresses
of their counterparts in the other domain. This solution is
impractical, particularly when the geographically adjacent domain
belongs to another administrative entity, such as a different
Wireless ISP (WISP). The neighboring WISP may decide to reconfigure,
add subnets, or remove them, as traffic patterns change. Propagating
those changes into static configurations would result in significant
availability lags.

Another solution is to use a simple directory based discovery
solution, such as DNS [10], LDAP [11], or SLP [12]. Attribute-based
discovery mechanisms such as LDAP and SLP could potentially handle
non-geographic capabilities, such as radio technology, but geographic
information may be difficult to cast into the form of attribute/value
pairs. In addition, information on changes in AR availability needs
to propagate dynamically between ARs rather than requiring the ARs to
explicitly ask for it. Finally, the client-server nature of these
protocols has the associated scalability and robustness concerns.

8. ACKNOWLEDGMENTS

6. ACKNOWLEDGEMENTS

   Special thanks are due to John Loughney (Nokia) and Hesham Soliman
   (Ericsson) for his their input during the preparation of this document.

9.
   Steve Deering's thoughts about how to involve the mobile node in CAR
   discovery were instrumental in achieving more focus to the problem
   statement.

7. REFERENCES

[1] IP

   1. ``IP Mobility Support, Support", C. Perkins (Editor), RFC 2002, October
     1996.

[2] Mobility

   2. ``Mobility Support in IPv6, IPv6", D. Johnson and Johnson, C. Perkins,
    draft-ietf-mobileip-ipv6-13.txt, and Jari
     Arkko, draft-ietf-mobileip-ipv6-17.txt, work in progress, November 2000.

[3] Low May
     2002.

   3. ``Low Latency Handoffs in Mobile IPv4, IPv4", MIPv4 Handoffs Design
     Team, draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, work in
     progress, February 2001.

[4] Fast

   4. ``Fast handoffs for Mobile IPv6, IPv6", MIPv6 handoff Design Team,
     draft-ietf-mobileip-fast-mipv6-01.txt, work in progress, April
     2001.

[5] Problem

   5. ``Problem Description: Reasons For Performing Context Transfers
     Between Nodes in an IP Access Network, Network", O. H. Levkowetz Levkowetz, et. al.,
     draft-ietf-seamoby-context-transfer-problem-stat-01.doc, work in
     progress, May 2001.

[6] General

   6. ``General requirements for a context transfer framework, framework", H. Sayed
     Sayed, et. al., draft-ietf-seamoby-ct-reqs-00.txt, work in
     progress, May 2001.

[7] Buffer

   7. ``Buffer Management for Smooth handoffs in Mobile IPv6, IPv6", G.
     Krishnamurthi, R. Chalmers, and C. Perkins,
    draft-krishnamurthi-mobileip-buffer6-01.txt, draft-krishnamurthi-
     mobileip-buffer6-01.txt, work in progress, March 2001.

[8] Open Shortest Path First protocol, Version 2, J. Moy, RFC 2328,
    April 1998.

[9] A Border Gateway Protocol 4 (BGP-4), edited by Y. Rekhter and
    T. LI, RFC 1771, March 1995.

[10] Domain Name System Structure and Delegation,

   8. ``Supporting Optimized Handover for IP Mobility - Requirements
     for Underlying Systems", J. Postel, RFC 1591,
    March 1994.

[11] Lightweight Directory Access Protocol, W. Yeong, T. Howes, and
     S. Kille, RFC 1777, March 1995.

[12] Service Location Protocol, Version 2, E. Guttman Kempf, et. al., draft-manyfolks-l2-
     mobilereq-02.txt, work in progress, November 2001.

   9. ``A Reverse Address Resolution Protocol", R. Finlayson, et. al.
     RFC 2608, 903, June 1999. 1984

   10. ``Dynamic Host Configuration Protocol", R. Droms, RFC 1531,
     October 1993.

8. AUTHORS' ADDRESS ADDRSSES

   Dirk Trossen

   Communication Systems Laboratory
   Nokia Research Center
   5 Wayside Road
   Burlington, MA 01803, USA
   Phone:  +1 781 993 3605
   Fax:  +1 781 993 1907
   E-mail:  dirk.trossen@nokia.com

   Govind Krishnamurthi

   Communication Systems Laboratory
   Nokia Research Center
   5 Wayside Road
   Burlington, MA 01803, USA
   Phone:  +1 781 993 3627
   Fax:  +1 781 993 1907
   E-mail:  govind.krishnamurthi@nokia.com

   Hemant Chaskar

   Communication Systems Laboratory
   Nokia Research Center
   5 Wayside Road
   Burlington, MA 01803, USA
   Phone:  +1 781 993 3785
   Fax:  +1 781 993 1907
   E-mail:  hemant.chaskar@nokia.com

   James Kempf

   DoCoMo Communication Laboratories, USA
   181 Metro Drive, Suite 300
   San Jose, CA 95110, USA
   Phone: +1 408 451 4711
   Email: kempf@docomolabs-usa.com