[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04                                                
IETF Seamoby Working Group                               Dirk Trossen
INTERNET-DRAFT                                   Govind Krishnamurthi
draft-ietf-seamoby-cardiscovery-issues-01.txt          Hemant Chaskar
20 September 2001                                               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.

Trossen, Krishnamurthi, Chaskar, Kempf                       [Page i]

INTERNET-DRAFT  Candidate Access Router Discovery Issues   Sept, 2001


    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


    7. REFERENCES                                             9

    8. AUTHORS' ADDRESS                                      10


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

Trossen, Krishnamurthi, Chaskar, Kempf                      [Page ii]

INTERNET-DRAFT  Candidate Access Router Discovery Issues   Sept, 2001


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 the Candidate AR discovery problem, we now describe some
illustrative scenarios in which the Candidate AR discovery protocol
may 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.

Trossen, Krishnamurthi, Chaskar, Kempf                       [Page 1]

INTERNET-DRAFT  Candidate Access Router Discovery Issues   Sept, 2001

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.

Trossen, Krishnamurthi, Chaskar, Kempf                       [Page 2]

INTERNET-DRAFT  Candidate Access Router Discovery Issues   Sept, 2001

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 approaches to CAR discovery, namely, Anticipated
CAR Discovery and Dynamic CAR Discovery.

4.1 Anticipated CAR Discovery

In this approach, an AR currently serving the MN identifies all 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 TAR Selection Algorithm about the reachability of
neighboring ARs from the MN. This reachability information is usually
in the form of identity of the AP to which the MN can listen to, and

Trossen, Krishnamurthi, Chaskar, Kempf                       [Page 3]

INTERNET-DRAFT  Candidate Access Router Discovery Issues   Sept, 2001

the current AR has to resolve this AP identity to the GAAR's IP

The advantage of this approach 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 Anticipated CAR Discovery problem encompasses the areas outlined
in the box in Figure 1.

  |                     All routers                                 |
  |                          |  Discovery of ARs whose coverage     |
  |                          |  areas overlap (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 this approach, an MN dynamically obtains information about
the available ARs for handoff, along with their capabilities. When
the MN detects an AR that has capabilities which match 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

The advantage of this technique is that the MN has fine-grained
control over the TAR selection. However, this approach generates more
radio traffic during the CAR discovery step. This is because,
capability information is sent to the MN over the air. Also, it is

Trossen, Krishnamurthi, Chaskar, Kempf                       [Page 4]

INTERNET-DRAFT  Candidate Access Router Discovery Issues   Sept, 2001

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.

The Dynamic CAR Discovery problem encompasses the areas outlined
in the box in Figure 2.

  |                                                              |
  |                 GAARs identified by MN                       |
  |                           |                                  |
  |                           | 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 CAR discovery may
be used. In the hybrid approach, the partitioning of capability
information between the two techniques as well as the partitioning of
TAR selection process between the MN and the current AR is possible.


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

Trossen, Krishnamurthi, Chaskar, Kempf                       [Page 5]

INTERNET-DRAFT  Candidate Access Router Discovery Issues   Sept, 2001

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

Trossen, Krishnamurthi, Chaskar, Kempf                       [Page 6]

INTERNET-DRAFT  Candidate Access Router Discovery Issues   Sept, 2001

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, 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
Dynamic CAR Discovery, 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.

Trossen, Krishnamurthi, Chaskar, Kempf                       [Page 7]

INTERNET-DRAFT  Candidate Access Router Discovery Issues   Sept, 2001

In the Anticipated CAR Discovery, capability exchange between ARs
occurs over the Internet. Thus, a protocol is needed that would allow
ARs to exchange capability information. Capability exchange between
ARs should also allow periodic as well as "as needed" 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 ARs to advertise their

5.3 Security considerations

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.

Trossen, Krishnamurthi, Chaskar, Kempf                       [Page 8]

INTERNET-DRAFT  Candidate Access Router Discovery Issues   Sept, 2001


[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.

Trossen, Krishnamurthi, Chaskar, Kempf                       [Page 9]

INTERNET-DRAFT  Candidate Access Router Discovery Issues   Sept, 2001


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
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, CA 94025, USA

Phone:  +1 650 786 5890
Fax:  +1 650 786 6445
E-mail:  james.kempf@eng.sun.com

Trossen, Krishnamurthi, Chaskar, Kempf                      [Page 10]