IETF Seamoby Working Group Govind Krishnamurthi,
INTERNET-DRAFT Editor
29 January 2002 Nokia Research Center
Requirements for CAR Discovery Protocols
draft-krishnamurthi-seamoby-car-requirements-00.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or 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
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
Copyright (c) The Internet Society (2001). All rights reserved.
ABSTRACT
The pre-requisite for IP based seamless mobility protocols is the
knowledge of the access router (AR) to which a mobile node can be
handed over to. Further, a handoff can be optimized if the capabilities
of the AR being considered for handoff are known. The protocol which
discovers ARs for potential handoff along with their capabilities is
called the CAR discovery protocol. In this draft we list the
requirements which are to be met by CAR discovery protocols.
Krishnamurthi, Editor [Page i]
INTERNET-DRAFT Requirements for CAR Discovery Protocols Jan, 2002
TABLE OF CONTENTS
1. INTRODUCTION 2
2. TERMINOLOGY 2
3.. REQUIREMENTS FOR CAR DISCOVERY PROTOCOLS
3.1 MAPPING AP IDENTIFIERS TO IP
ADDRESSES OF ARs 3
3.2 SUPPORT FOR INTER-TECHNOLOGY HANDOFFS 3
3.3 SUPPORT FOR HANDOFFS FROM PRIVATE AND SITE-LOCAL
ARs 3
3.4 CAPABILITY DISCOVERY 4
3.5 FORMAT OF CAPABILITIES 4
3.6 SCOPE OF CAR DISCOVERY 4
3.7 INTRODUCTION OF DEDICATED NETWORK ELEMENTS FOR
CAR DISCOVERY 4
3.8 INVOLVEMENT OF NON-GAARs IN CAR DISCOVERY 4
3.9 DEPENDENCE ON A PARTICULAR MOBILITY MANAGEMENT
PROTOCOL 4
3.10 EFFECT OF CHANGES IN NETWORK TOPOLOGY 4
4. ACKNOWLEDGEMENTS 5
5. REFERENCES 5
6. AUTHORS' ADDRESS 5
Krishnamurthi, Editor [Page 1]
INTERNET-DRAFT Requirements for CAR Discovery Protocols Jan, 2002
1. INTRODUCTION
CAR discovery protocols perform the function of identifying the
candidate access routers along with their capabilities for a mobile
node's (MN) handoff. CAR discovery can be used by seamless handoff
protocols [1,2,3,4] to decide the access router to which the mobile
node will be handed over to. The problem statement for CAR discovery
is discussed in [5]. In this draft, we present the requirements that
any protocol for CAR discovery needs to meet.
2. TERMINOLOGY
In this draft, we use the same terminology as described in [5].
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 the AR with which the procedures for the MN's IP-level handoff
are initiated. TAR is usually selected from the set of CARs.
Krishnamurthi, Editor [Page 2]
INTERNET-DRAFT Requirements for CAR Discovery Protocols Jan, 2002
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.
3.REQUIREMENTS FOR CAR DISCOVERY PROTOCOLS
In this section, we list the set of requirements that must be met
by CAR discovery protocols.
3.1 MAPPING AP IDENTIFIERS TO IP ADDRESSES OF ARs
This is one of the fundamental functions of CAR discovery. Once an AP
identifier is forwarded as an input to the CAR discovery protocol it
MUST map the identifier to the IP address of the AR which the AP is
connected to. This is motivated by the fact that, for example, an MN may
only be able to receive the link layer identifier of an AP connected to
potential target ARs. This has to be mapped to the IP address of the AR
the AP is connected to. The exact identifiers that are advertised for
different link layer technologies can be obtained from the appropriate
standards.
3.2. SUPPORT FOR INTER-TECHNOLOGY HANDOFFS
Though not common now, it is possible that in the future, MNs may have
interfaces belonging to different technologies thus facilitating the
possibility of inter-technology handoffs. An example for this, among
others, is a handoff from an 802.11 based LAN to a 3G based cellular
network. The CAR discovery protocol therefore MUST be able to map link
layer identifiers of different technologies.
3.3. SUPPORT FOR HANDOFFS FROM PRIVATE AND SITE-LOCAL ARs
Support for handoffs between IPv4 and IPv6 is critical in the design of
protocols dealing with mobility. This is in particular true for inter-
technology handovers. Once IPv4 networks come into the picture we have
to deal with the possibility of private address spaces. Even in the
case of IPv6 networks, we have the possibility of private spaces. For
example, the policy of a particular domain may be not to expose the
globally routable IPv6 addresses of its ARs for security reasons. To
support such scenarios, CAR discovery protocols MUST be able to identify
GAARs and their capabilities when moving in and out of private and site-
local address spaces. This is contingent on whether the operator of the
network permits such handoffs.
Krishnamurthi, Editor [Page 3]
INTERNET-DRAFT Requirements for CAR Discovery Protocols Jan, 2002
3.4. CAPABILITY DISCOVERY
The other fundamental function of CAR discovery protocols is that of
identifying the capabilities of GAARs. The protocol MUST provide
functionality to allow ARs to discover their GAAR's capabilities. These
capabilities MUST be communicated in a secure fashion.
3.5 FORMAT OF CAPABILITIES
This is a requirement for inter-operability between GAARs. For
successful communication of these capabilities between GAARs the
capabilities MUST be described in a standard format which is TBD.
3.6 SCOPE OF CAR DISCOVERY
The Internet is formed by several Administrative Domains (ADs) clustered
together. As explained in [5], GAARs could belong to different ADs
separated by large distances in terms of IP hops.Therefore, CAR
discovery protocols SHOULD have an Intra-domain as well as Inter-domain
scope.
3.7.INTRODUCTION OF DEDICATED NETWORK ELEMENTS FOR CAR DISCOVERY
The protocol MUST NOT introduce network elements dedicated to CAR
discovery.
3.8. INVOLVEMENT OF NON-GAARs IN CAR DISCOVERY
Handoffs might happen very frequently. If the CAR discovery process
introduced additional load on ARs which are not GAARs, this will impede
their performance. Therefore a CAR discovery protocol SHOULD minimize
the involvement of non-GAARs.
3.9. DEPENDENCE ON A MOBILITY MANAGEMENT PROTOCOL
CAR discovery MUST NOT depend on a particular mobility management
protocol. In other words, it MUST NOT utilize a feature which is unique
to a particular mobility management protocol. The output of CAR
discovery, however, MUST be usable by mobility management protocols. CAR
discovery MUST NOT deteriorate the performance of the underlying
mobility management protocol.
3.10 EFFECT OF CHANGES IN NETWORK TOPOLOGY
Networks topology can change for several reasons, for example, network
renumbering or physically changing the location of an AR. A CAR
discovery protocol MUST be adaptive to changes in physical topology as
well as logical topology.
Krishnamurthi, Editor [Page 4]
INTERNET-DRAFT Requirements for CAR Discovery Protocols Jan, 2002
4. ACKNOWLEDGEMENTS
The contributions of Dirk Trossen (Nokia), Hemant Chaskar (Nokia),
James Kempf (DoCoMo Labs), Hesham Soliman (Ericsson) and Phil Neumiller
(Mesh Networks) were valuable in preparation of this document.
5. REFERENCES
[1] MIPv4 Handoffs Design Team,Low Latency Handoffs in Mobile IPv4,
draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt,
work in progress, February 2001.
[2] MIPv6 handoff Design Team,Fast handoffs for Mobile IPv6,
draft-ietf-mobileip-fast-mipv6-01.txt,
work in progress, April 2001.
[3] O. H. Levkowetz et. al.,Problem Description: Reasons For Performing
Context Transfers Between Nodes in an IP Access Network, draft-ietf-
seamoby-context-transfer-problem-stat-01.doc, work in progress, May
2001.
[4] H. Sayed et. al., General requirements for a context transfer
framework, draft-ietf-seamoby-ct-reqs-00.txt, work in progress, May
2001.
[5] D. Trossen, G. Krishnamurthi, H. Chaskar, J. Kempf, Issues in
candidate access router discover for seamless IP-level handoffs,
draft-ietf-seamoby-car-discovery-02.txt,work-in-progress, January
2002.
6. EDITOR'S ADDRESS
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
Krishnamurthi, Editor [Page 5]