IETF Seamoby Working Group                               Dirk Trossen
INTERNET-DRAFT                                   Govind Krishnamurthi
draft-ietf-seamoby-cardiscovery-issues-02.txt          Hemant Chaskar
20 September 2001
15 January 2002                                                 Nokia
                                                          James Kempf
                                               Sun Microsystems, Inc.

           Issues in candidate access router discovery
                  for seamless IP-level handoffs

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
  Internet-Drafts are draft documents valid for a maximum of six
  months  and may be updated, replaced, or made obsolete 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

  The list of current Internet-Drafts can be accessed at
  The  list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

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


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 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 handoffs is identifying the
candidate access routers for the mobile node's handoff. At the time
of IP-level handoff, if a collection of candidates has been
identified, an algorithm is run to determine the target access
router for the mobile node's handoff. This document presents a
problem statement describing issues involved in designing a candidate
access router discovery protocol. The document does not discuss the
algorithm by which the actual target router is selected, nor how the
handoff to the target is achieved.


    1. INTRODUCTION                                           1

    2. MOTIVATION FOR CAR DISCOVERY                           1

    3. TERMINOLOGY                                            2


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

    5. SPECIFIC ISSUES IN CAR DISCOVERY                       5

       5.1 Identifying GAARs                                  5
       5.2 Identifying capabilities of GAARs                  7
       5.3 Security considerations                            8

    6. SECURITY CONSIDERATIONS                                8



    8. ACKNOWLEDGEMENTS                                       8

    9. REFERENCES                                             9


    10. AUTHORS' ADDRESS                                     10


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


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 movement of the MN causes a change in the radio access point
through which the MN communicates with the wired network, such that
the AR serving the new radio access point is in a new subnet. There
are existing solutions [1, 2] that enable MNs to execute IP-level
handoffs between the ARs. 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
handoff solutions assume that the identity (IP address) of the target
AR is known to the current AR. They do not provide a solution to the
problem of selecting the target AR for the MN's handoff. What is
required is a protocol that would allow an AR or an MN to discover
the neighboring ARs whose capabilities meet the requirements 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 AR at the time of MN's handoff. This draft discusses the
issues involved in the problem of Candidate AR discovery. The draft
does not discuss the problem of selecting the target AR to which
handoff is performed, nor the handoff process itself.

To motivate provide motivation for the Candidate AR discovery problem, we now describe work, some
illustrative scenarios are given below in which the Candidate AR
discovery protocol
may will be useful.


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 MN and is not heavily loaded. If AR2 has the capabilities to
satisfy the MN's requirements, AR1 can initiate a handoff of the MN
to AR2 to alleviate some of its own load. 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 an MN running a streaming video application, which might be
an important application for the future mobile networks. These

applications require high bandwidth and possibly other QoS support to
be available at the AR serving the MN. When this MN moves into the
coverage area of a new AR, it is possible 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
the capabilities 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 the MN to prioritize handoffs
to an AR with minimal cost of access for phone call ('least cost
policy'). Due to the real-time nature of the service, seamless
handoffs are preferred to minimize service disruption. In addition,
the 'cost of access' capability information, if available, is
included in the target AR selection process as an MN-specific

Scenario 4: Adaptability to change in the coverage topology

Consider a situation in which ARs may be temporarily introduced in
hot-spots to cater to the existing traffic demand. In such a case,
a static configuration of the neighborhood information in ARs is not
feasible as the operators may not inform each other of temporary
changes. A protocol is therefore needed in such cases so that an AR
can automatically identify any change in the coverage topology and
exchange capability information with the neighboring ARs. This can
be facilitated by the Candidate AR discovery protocol.


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 or overlap.

Capability of AR

  A characteristic of the 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.


There are two basic

In this section, we describe three approaches to CAR discovery, namely,
namely the Anticipated CAR Discovery and (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 approach, method, an AR currently serving the an MN identifies all can identify a set of
CARs for the MN's handoff, at some point prior to handoff. This
information is then immediately 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 of this approach Anticipated CAR Discovery is that the handoff can be
executed quickly because the AR has already collected much of the information needed by the TAR
Selection Algorithm. Also, this approach does not
generate much radio traffic for performing CAR discovery as the
capability exchange happens over the wired network.

The Algorithm is collected in advance of handoff.

Anticipated CAR Discovery problem encompasses the areas outlined
in the box is depicted in Figure 1.

   |                     All routers                                 |
   |                          |  Discovery of ARs whose coverage     |
   |                          |  areas overlap (GAARs)with (GAARs) with that of  |
   |                          v  the current AR                      |
   |           Local map of GAARs at current AR                      |
   |                          |                                      |
   |                          |   Capability identification          |
   |                          v                                      |
   |      CARs for MN's handoff identified at current AR             |
   |                          |                                      |
                              |   Predefined preferences of the MN
         AR Reachability      |   and administrative preferences
           for the MN         |
                |             |             |
                v             v             v
             TAR Selection Algorithm executed at the time of
             handoff to determine unique TAR for MN's handoff

              Figure 1: The Anticipated CAR Discovery Problem

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 approach, can be performed in a
number of ways and with various entities participating in the process.
One illustrative method for Dynamic CAR Discovery is given below.

According to this method, an MN dynamically obtains information about
the available ARs for handoff, along with their capabilities. This is
done after the handoff trigger is generated. When the MN detects an
AR that has capabilities which match matching its preferences, the MN may notify
the currently serving AR to perform a handoff to this AR using one or
more of the seamless handoff protocols. The advantage of this technique method
is that the MN has fine-grained control over the TAR selection.
However, this approach method generates more radio traffic during the CAR
discovery step. This is because, because capability information is sent to the
MN over the air. Also, 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 problem encompasses the areas outlined
in the box is shown in Figure 2.

      |                                                              |
      |                 GAARs identified by MN at handoff time             |
      |                           |                                  |
      |                           | Capability identification by MN        |
      |                           |                                  |
      |                           v                                  |
      |            CARs for MN's handoff identified at MN                  |
      |                           |                                  |
                                  | TAR selection by MN at the
                                  |    time of handoff
                        Unique TAR identity sent to current AR

                  Figure 2: Dynamic CAR Discovery Problem

4.3 Hybrid CAR Discovery

In practice, a hybrid of the above techniques for Anticipated and Dynamic CAR discovery
approaches may be used. In For example, in the hybrid approach, the partitioning GAAR
discovery and much of capability
information between the two techniques as well as the partitioning of
TAR selection process between capability identification may be performed
prior to handoff, while the MN and remaining capability identification may
happen during the current AR is possible. handoff process. But,there are other
alternatives too.


The following sections describe the specific issues in the CAR
discovery, may it be done in anticipated, dynamic or hybrid way.

5.1 Identifying GAARs

A basic requirement for a new AR to be considered as a CAR for MN's
handoff is that the coverage area of the new AR be "geographically"
adjacent to or overlapping with that of the AR currently serving the
MN. In other words, a new AR must be a GAAR. Note, the geographical
vicinity of the coverage areas of two ARs is not necessarily implied
by their "logical" adjacency. Logical adjacency of two ARs means that
there is just one IP hop between the two ARs, while the adjacency of
the coverage areas of two ARs implies that the MN 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 handoff protocols specified in [3] and [4] or the
context transfer framework specified in [6] require that the current
AR or Foreign Agent (FA) (generically called ARs here for short) have
a list of ARs to which a MN could be handed over. In other words, the
current AR has a list of CARs. There is no reason, a priori, why
these CARs need to in topologically adjacent subnets. A CAR could
potentially be in a completely different BGP autonomous system. The
only requirement is that the corresponding APs 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, the APs are shown connected to ARs in completely
different BGP autonomous systems, but the same problem occurs
if the APs are geographically adjacent and the ARs are in subnets
that are topologically distant within an autonomous system. The
criterion for an AR to be a candidate for an MN's handoff is the
geographical adjacency of the AP served by it to that of the AP to
which the MN is currently attached, and not the topological adjacency

of the corresponding ARs. Hence, IP routing protocols, such as OSPF
[8] or BGP [9], are not the solutions to GAAR discovery problem.

One approach is to manually configure this geographical neighborhood
at each AR. However, such an approach has disadvantages and in many
cases, may not be feasible. For instance, the GAARs may be under
different administrative control, and thus, are not informed about
each other's presence. Even within the same administrative domain,
the manual configuration approach demands much network planning in
terms of the coverage areas of different ARs. Finally, the manual
configuration approach is not suitable if the ARs can be physically
relocated or their coverage area changed, thus altering the
geographical scope of their coverage areas. Such a scenario is very
common when ARs are temporarily introduced in hot spots. Clearly, a
more automatic and dynamic mechanism is needed to discover GAARs
without much administrative intervention.

For the Anticipated CAR Discovery, Discovery method described in Section 4.1,
the process of identifying GAARs requires a protocol that allows ARs
to exchange the information about the geographical adjacency of their
APs, in advance of handoff. In the Dynamic CAR Discovery, Discovery method
described in Section 4.2, the MN automatically serves as the judge of
whether an AR is a GAAR. In the latter case, if the MN can hear a
Router Advertisement of the new AR, then the new AR is GAAR.

5.2 Identifying capabilities of GAARs:

Although not common now, the future generation mobile networks may
consist of ARs that are GAARs of each other, but are heterogeneous in
administrative control, functionality, link layer technology and
resources. An MN that 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 that are GAARs
of each other need to exchange information regarding the
correspondence between their IP addresses and the identities of the
APs (which the MN can listen to) that are connected to them.

In the Anticipated CAR Discovery, capability exchange between ARs
occurs over the Internet. Thus,

Clearly, a protocol is needed that would allow
ARs to exchange capability information. Capability exchange between
ARs should also allow periodic as well enable the functions such as "as needed"
solicitation and exchange of
capabilities between GAARs.

In the Dynamic CAR Discovery approach, the MN is soliciting or
receiving the capabilities of GAARs directly. Some protocol is
required to allow the MN to solicit, or the capability information among MN, ARs to advertise their

5.3 Security considerations and
other network entities.


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

- Physical location
- Capabilities
- State of capabilities.

Malicious nodes may use this kind of information to launch attacks of
the DoS-style and/or service hijacking. Therefore, the following
topics should be covered in any protocol developed for CAR discovery:

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



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.



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


[1] IP Mobility Support, C. Perkins (Editor), RFC 2002, October 1996.

[2] Mobility Support in IPv6, D. Johnson and C. Perkins,
    work in progress, November 2000.

[3] Low Latency Handoffs in Mobile IPv4, MIPv4 Handoffs Design Team,
    work in progress, February 2001.

[4] Fast handoffs for Mobile IPv6, MIPv6 handoff Design Team,
    work in progress, April 2001.

[5] Problem Description: Reasons For Performing Context Transfers
    Between Nodes in an IP Access Network, O. H. Levkowetz et. al.,
    work in progress, May 2001.

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

[7] Buffer Management for Smooth handoffs in Mobile IPv6,
    G. Krishnamurthi, R. Chalmers, and C. Perkins,
    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, 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 et. al.,
     RFC 2608, June 1999.



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

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

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

James Kempf
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park,
DoCoMo Communication Laboratories, USA
181 Metro Drive, Suite 300
San Jose, CA 94025, 95110, USA

Phone: +1 650 786 5890
Fax:  +1 650 786 6445
E-mail: 408 451 4711