IETF Seamoby Working Group                               Dirk Trossen
INTERNET-DRAFT                                   Govind Krishnamurthi
draft-ietf-seamoby-cardiscovery-issues-00.txt          Hemant Chaskar
Expires: January 2002                                           Nokia
                                                          James Kempf
                                               Sun Microsystems, Inc.
                                                            July 2001

 Issues in candidate access router discovery for seamless IP 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 information 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. When a collection of candidates has been identified, an
algorithm is run to determine the target access router, and this
router becomes the target of handoff at Layer 3. 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
identified, nor how the handoff to the target is achieved.

Trossen, Krishnamurthi, Chaskar, Kempf                       [Page i]

INTERNET-DRAFT  Candidate Access Router Discovery Issues   July, 2001


    1. INTRODUCTION                                           1

    2. TERMINOLOGY                                            1


       3.1 Anticipated CAR Discovery                          2
       3.2 Dynamic CAR Discovery                              3
       3.3 Hybrid CAR Discovery                               3

    4. SPECIFIC ISSUES IN CAR DISCOVERY                       3

       4.1 Identifying PAARs                                  3
       4.2 Identifying capabilities of PAARs                  4
       4.3 Security considerations                            5

    5. REFERENCES                                             5

    6. AUTHORS' ADDRESS                                       6


    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   July, 2001


IP mobility protocols enable mobile nodes (MNs) to change the access
routers (ARs) by which they access the Internet. An AR providing
Internet connectivity to the MN changes when movement of the MN
causes a change in the radio access point through which the MN
communicates with the wired network, such that the new radio access
point is in a new subnet. There are existing solutions [1, 2] that
enable MNs to execute 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 of
the new AR is known to the old AR. They do not provide a solution to
the problem of discovering 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 for handoff, along with their capabilities. This
information can be used for selecting the actual target AR for the
MN's handoff. This draft discusses the issues involved in the problem
of candidate AR discovery. The draft does not discuss the problem of
actually selecting the target AR to which handoff is performed, nor
the actual handoff process itself.


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.

Physically Adjacent AR (PAAR)

  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.

Candidate AR (CAR)

  This is an AR that is a candidate for MN's handoff. CAR is
  necessarily a PAAR 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 MN's handoff
  are initiated.

Trossen, Krishnamurthi, Chaskar, Kempf                       [Page 1]

INTERNET-DRAFT  Candidate Access Router Discovery Issues   July, 2001

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.

3.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 into 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. 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.

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

  |                     All routers                                 |
  |                          |                                      |
  |                          |   Physical adjacency discovery       |
  |                          v                                      |
  |           Local map of PAARs at current AR                      |
  |                          |                                      |
  |                          |   Capability identification          |
  |                          v                                      |
  |      CARs for MN's handoff identified at current AR             |
  |                          |                                      |
                             |   Predefined preferences of the MN
        AR Reachability      |   negotiated at admission time or
          for the MN         |   administrative preferences
               |             |             |
               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

Trossen, Krishnamurthi, Chaskar, Kempf                       [Page 2]

INTERNET-DRAFT  Candidate Access Router Discovery Issues   July, 2001

3.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
protocols. 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. Also, it
is required that the MN can listen to or, in some cases, even talk to
the PAARs for collecting capability information and negotiating
preferences, while still being connected to the current AR.

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

  |                                                              |
  |                 PAARs 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

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

4.1 Identifying PAARs

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 "physically
adjacent" to that of the AR currently serving the MN. In other words,

Trossen, Krishnamurthi, Chaskar, Kempf                       [Page 3]

INTERNET-DRAFT  Candidate Access Router Discovery Issues   July, 2001

a new AR must be a PAAR. Note, the physical adjacency 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 physical adjacency of two ARs
implies that the MN can actually move from the coverage area of one
AR to another. Conversely, PAARs need not be logically adjacent, and
may even have IP addresses in different administrative domains.

One approach is to manually configure this physical neighborhood at
each AR. However, such an approach has disadvantages and in many
cases, may not be feasible. For instance, two ARs that are physically
adjacent 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
routers can be physically relocated or their coverage area changed,
thus altering the physical adjacency 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
that would allow an AR to discover physically adjacent ARs around
itself without much administrative intervention.

For the Anticipated CAR Discovery, the process of identifying PAARs
requires a protocol that allows ARs to exchange physical adjacency
information in advance of handoff. In Dynamic CAR Discovery, the MN
automatically serves as the judge of whether an AR is a PAAR. In the
latter case, if the MN can hear a Router Advertisement of the new AR,
then the new AR is PAAR.

4.2 Identifying capabilities of PAARs:

Although not common now, the future generation mobile networks may
consist of ARs that are physically adjacent, but are heterogeneous in
administrative control, function, capability, 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 access router 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 or policy agreement
between the current AR and its physical neighbor in order to allow
MN's handoff between them. The various capabilities that need to be
identified in PAAR for smooth handoff are outside the scope of this
draft. However, as an illustration, the capabilities to be identified
may include administrative parameters such as ISP, organization and
policy information; cost of access parameters; information about
radio interfaces; information about availability of any application
logic such as multicast support, header compression capability,
playout buffer hosting for streaming applications, TCP PEPs and media
transcoding functionality; Internet connectivity parameters such as

Trossen, Krishnamurthi, Chaskar, Kempf                       [Page 4]

INTERNET-DRAFT  Candidate Access Router Discovery Issues   July, 2001

need for NAT traversal; resource parameters such as load and so on.

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.

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

4.3 Security considerations

AR 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 AR discovery:

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


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

Trossen, Krishnamurthi, Chaskar, Kempf                       [Page 5]

INTERNET-DRAFT  Candidate Access Router Discovery Issues   July, 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.


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, CA 94025, USA

Phone:  +1 650 786 5890
Fax:  +1 650 786 6445

Trossen, Krishnamurthi, Chaskar, Kempf                       [Page 6]