draft-ietf-seamoby-cardiscovery-issues-02.txt   draft-ietf-seamoby-cardiscovery-issues-03.txt 
IETF Seamoby Working Group Dirk Trossen IETF Seamoby Working Group Dirk Trossen
INTERNET-DRAFT Govind Krishnamurthi INTERNET-DRAFT Govind Krishnamurthi
draft-ietf-seamoby-cardiscovery-issues-02.txt Hemant Chaskar draft-ietf-seamoby-cardiscovery-issues-03.txt Hemant Chaskar
15 January 2002 Nokia 12 June, 2002 Nokia
James Kempf James Kempf
DoCoMo DoCoMo
Issues in candidate access router discovery Issues in candidate access router discovery
for seamless IP-level handoffs for seamless IP-level handoffs
Status of This Memo Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or made obsolete by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as ``work in
progress." progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright notice
Copyright (c) The Internet Society (2001). All rights reserved. Copyright (c) The Internet Society (2002). All rights reserved.
ABSTRACT Abstract
Handoff in IP mobility protocols involves moving a mobile node's Handoff in IP mobility protocols involves moving a mobile node's
Layer 3 routing reachability point from one access router to another, Layer 3 routing reachability point from one access router to
before or after the mobile node has established a Layer 2 connection another, before or after the mobile node has established a Layer 2
with the radio access point that is covered by the new access router. connection with the radio access point that is covered by the new
In addition, other context information about the mobile node's packet access router. In addition, other context information about the
session may be transferred from the old access router to the new one, mobile node's IP service may be transferred from the old access
in order to minimize the service disruption during the handoff router to the new one, in order to minimize the service disruption
process. While the exact details of how this is accomplished vary during the handoff process. While the exact details of how this is
depending on the IP mobility and seamless handoff protocols, one accomplished vary depending on the IP mobility and seamless handoff
common thread required for seamless handoffs is identifying the protocols, one common thread required for IP-level handoffs is
candidate access routers for the mobile node's handoff. At the time discovering the candidate access routers for the mobile node's
of IP-level handoff, if a collection of candidates has been handoff. Discovering the candidate access router involves
identified, an algorithm is run to determine the target access identifying its IP address as well as its capabilities that the
router for the mobile node's handoff. This document presents a mobile node might be interested in. At the time of IP-level handoff,
problem statement describing issues involved in designing a candidate if a collection of candidates is identified, an algorithm is run to
access router discovery protocol. The document does not discuss the determine the target access router for the mobile node's handoff.
algorithm by which the actual target router is selected, nor how the This document describes the problem of candidate access router
handoff to the target is achieved. 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...................................................3
1.1. Seamless Handoff Protocols...................................3
1.2. Choice for Handoff...........................................3
2. TERMINOLOGY....................................................4
3. MOTIVATION FOR CAR DISCOVERY...................................4
4. THE CAR DISCOVERY PROBLEM......................................6
4.1. CAR IP Address Discovery.....................................6
4.2. Identifying Capabilities of CAR..............................7
5. SECURITY CONSIDERATIONS........................................7
6. ACKNOWLEDGEMENTS...............................................7
7. REFERENCES.....................................................7
8. AUTHORS' ADDRESSES.............................................8
1. INTRODUCTION 1 1. INTRODUCTION
2. MOTIVATION FOR CAR DISCOVERY 1 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 there
is a change (usually as a result of movement of the MN) in the
access point (AP) through which the MN communicates with the wired
network, such that the AR serving the new AP is in a new subnet.
There are existing solutions [1, 2] that enable MNs to execute IP-
level handoffs between the ARs.
3. TERMINOLOGY 2 1.1. Seamless Handoff Protocols
4. APPROACHES TO CANDIDATE ACCESS ROUTER DISCOVERY 3 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 (wireless) link protocol is capable of delivering a
Layer 2 identifier for the new AP or the radio interface of new AR
[8] to the current AR or to the MN, and require that the current AR
be able to translate this Layer 2 identifier to the IP address of
the new AR in order to facilitate the seamless handoff. In addition
to simply providing the Layer 2 to IP address mapping, the AR needs
some way to determine if the Layer 2 identifier is that of a
legitimate AP or AR or whether it is an imposter. Some link layers
provide Layer 2 security mechanisms for this purpose.
4.1 Anticipated CAR Discovery 3 1.2. Choice for Handoff
4.2 Dynamic CAR Discovery 4
4.3 Hybrid CAR Discovery 5
5. SPECIFIC ISSUES IN CAR DISCOVERY 5 In future mobile networks, there will be cases when MN has a choice
of performing IP-level handoff to a different AR. For example, an MN
having network interface cards supporting two or more wireless
access technologies (such as, 3G and wireless LAN) and communicating
over one of them, may wish to switch to a different access network
if it feels that the IP service offered by the latter better suits
its requirements. A generalization of this case is when the MN has a
choice of different APs (of possibly different media and access
technologies) connected to different ARs, for the sake of
maintaining Internet connectivity. These different ARs may have
different capabilities (different service providers, different load
conditions, different wired QoS availability, etc.). The MN requires
some means of obtaining information about the capabilities of these
ARs so that the best decision about the handoff target can be made.
Note that there might be scenarios when a handoff is essential to at
least one of these ARs (old connection is fading fast) as well as
those when MN may live without performing a handoff to any of these
ARs (coverage of new AR is subsumed within that of the current AR).
Further, depending upon the handoff scenario, seamless handoff
protocols may or may not be used.
5.1 Identifying GAARs 5 The two problems are linked in the sense that they both involve
5.2 Identifying capabilities of GAARs 7 determining the information about a new AR (IP address and
capabilities) that is a candidate for the next handoff. In this
document, we discuss the problem of Candidate Access Router (CAR)
discovery.
6. SECURITY CONSIDERATIONS 8 2. TERMINOLOGY
7. APPLICABILITY OF EXISTING PROTOCOLS 8 Access Point (AP)
8. ACKNOWLEDGEMENTS 8 A radio transceiver by which an MN obtains Layer 2 connectivity
with the wired network.
9. REFERENCES 9 Access Router (AR)
10. AUTHORS' ADDRESS 10 An IP router residing in an access network and connected to one or
more APs. An AR offers IP connectivity to MN.
1. INTRODUCTION Capability of AR
IP mobility protocols enable mobile nodes (MNs) to change the access A characteristic of the IP service offered by an AR that may be of
routers (ARs) by which they obtain the Layer 3 connectivity to interest to an MN when the AR is being considered as a handoff
the Internet, while communicating with another node over the candidate.
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 provide motivation for the Candidate AR discovery work, some Candidate AR (CAR)
illustrative scenarios are given below in which Candidate AR
discovery protocol will be useful.
2. MOTIVATION FOR CANDIDATE AR DISCOVERY An AR to which MN has a choice of performing IP-level handoff. This
means that MN has the right radio interface to connect to an AP that
is served by this AR, as well as the coverage of this AR overlaps
with that of the AR to which MN is currently attached to.
This section describes some seamless handoff features that can be Target AR (TAR)
implemented if there are means to identify the Candidate ARs for
the MN's handoff. An AR with which the procedures for the MN's IP-level handoff are
initiated. TAR is selected after running a TAR Selection Algorithm
that takes into account the capabilities of CARs, preferences of MN
and any local policies.
3. MOTIVATION FOR CAR DISCOVERY
This section describes some features that can be implemented with
the help of CAR discovery protocol.
Scenario 1: Load balancing Scenario 1: Load balancing
Consider an AR to which an MN is currently attached. This AR is Consider an AR to which an MN is currently attached. This AR is
denoted by AR1. Further, assume that AR1 is heavily loaded. Suppose denoted by AR1. Further, assume that AR1 is heavily loaded. Suppose
there is another AR, denoted by AR2, that is reachable from the 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 attached MN and is not heavily loaded. Then, MN may decide to
satisfy the MN's requirements, AR1 can initiate a handoff of the MN undergo handoff to AR2. Such load balancing can be achieved using
to AR2 to alleviate some of its own load. For this, AR1 needs to have the capability information about AR2 obtained via CAR discovery
the knowledge of the capabilities of AR2 and the load on AR2. Such an protocol.
information sharing can be achieved with the help of Candidate AR
discovery protocol.
Scenario 2: Resource intensive applications Scenario 2: Resource intensive applications
Consider an MN running a streaming video application, which might be Consider an MN running a streaming video application, which might be
an important application for the future mobile networks. These an important application for the future mobile networks. These
applications require high bandwidth and possibly other QoS support
applications require high bandwidth and possibly other QoS support to to be available at the AR serving the MN. When this MN moves into
be available at the AR serving the MN. When this MN moves into the the coverage area of a new AR, it is possible that the new AR does
coverage area of a new AR, it is possible that the new AR does not not have the capability to support the MN's application. The MN can
have the capability to support the MN's application. The MN can then then be informed about this fact when it is still connected to the
be informed about this fact when it is still connected to the current current AR. Clearly for this, it is necessary to have the knowledge
AR. Clearly for this, the current AR needs to have information about of the capabilities of the neighboring ARs, and this can be
the capabilities of the neighboring ARs, and this can be achieved obtained using the CAR discovery protocol.
using the Candidate AR discovery protocol.
Scenario 3: Least-cost phone call Scenario 3: Least-cost phone call
Consider the preference expressed by the MN to prioritize handoffs Consider the preference expressed by the MN to prioritize handoffs
to an AR with minimal cost of access for phone call ('least cost to an AR with minimal cost of access for phone call (``least cost
policy'). Due to the real-time nature of the service, seamless policy"). The ``cost of access" capability of an AR can be obtained
handoffs are preferred to minimize service disruption. In addition, using CAR discovery protocol.
the 'cost of access' capability information, if available, is
included in the target AR selection process as an MN-specific
preference.
Scenario 4: Adaptability to change in the coverage topology Scenario 4: Adaptability to change in the coverage topology
Consider a situation in which ARs may be temporarily introduced in Consider a situation in which ARs may be temporarily introduced in
hot-spots to cater to the existing traffic demand. In such a case, hot-spots to cater to the existing traffic demand. In such a case,
a static configuration of the neighborhood information in ARs is not a static configuration of the neighborhood information in ARs is not
feasible as the operators may not inform each other of temporary feasible as the operators may not inform each other of temporary
changes. A protocol is therefore needed in such cases so that an AR changes. A protocol is therefore needed in such cases for the MN to
can automatically identify any change in the coverage topology and automatically identify any change in the coverage topology and
exchange capability information with the neighboring ARs. This can identify the capabilities of the neighboring ARs. This can be
be facilitated by the Candidate AR discovery protocol. facilitated by the CAR discovery protocol.
3. 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 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.
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 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 of Anticipated CAR Discovery is that the handoff can be
executed quickly because much of the information needed by 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) 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: 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 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 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 method
is that the MN has fine-grained control over the TAR selection.
However, this method 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 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 for MN's handoff identified |
| | |
---------------------------|----------------------------------
|
| TAR selection at the
| time of handoff
v
Unique TAR identity
Figure 2: Dynamic CAR Discovery
4.3 Hybrid CAR Discovery
In practice, a hybrid of the Anticipated and Dynamic CAR discovery
approaches may be used. For example, in the hybrid approach, the GAAR
discovery and much of the capability identification may be performed
prior to handoff, while the remaining capability identification may
happen during the handoff process. But,there are other
alternatives too.
5. SPECIFIC ISSUES IN CAR DISCOVERY
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 Scenario 5: Inter-technology handoff
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 Consider the case in which an MN has a variety of wireless access
System A System B network media available to it, and also possibly a wired interface.
Theoretically, the MN could bring up each interface and solicit a
Router Advertisement on it, but as the number of interfaces becomes
larger, such a procedure results in a larger and larger drain on
power. An alternative would be if the MN could solicit for
alternative AR choices on an active interface, and use this
information to choose handoff target.
+----+ +----+ 4. THE CAR DISCOVERY PROBLEM
| BR |---> The Internet <---| BR |
+----+ (aka Cyberspace) +----+
/ \
/ \
+----+ +----+
| IR | | IR |
+----+ +----+
| |
| |
+----+ +----+
| AR | | AR |
+----+ +----+
| |
|___________________ ________________|
| | | |
... | -- -- | ...
| \/ \/ |
| |
|_______ ______|
| | | |
| -- -- | The Physical World
| \/ \/ | (aka Geospace)
| |
|______ _______|
| |
-- -- --
\/ = AP \/ \/
Figure 3: GAAR Discovery Problem There are two basic problems associated with CAR discovery:
In the figure, the APs are shown connected to ARs in completely 1) Mapping from a Layer 2 identifier for an AP to the IP address of
different BGP autonomous systems, but the same problem occurs the CAR
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 2) Identifying the capabilities of CAR
[8] or BGP [9], are not the solutions to GAAR discovery problem.
One approach is to manually configure this geographical neighborhood The two problems are related in that both are concerned with
at each AR. However, such an approach has disadvantages and in many obtaining IP-level information about a CAR for the purposes of
cases, may not be feasible. For instance, the GAARs may be under determination of the target access router for handoff.
different administrative control, and thus, are not informed about We discuss these two problems in the following subsections.
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 method described in Section 4.1, 4.1. CAR IP Address 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 the Dynamic CAR 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: 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 target AR to which the MN will undergo handoff or has undergone
handoff. For [3] and [4], the signaling is required to rearrange
routing for a Mobile IP handoff when the MN's link moves to the
target AR. For [5], [6], and [7], the signaling is required so that
the current AR can transfer IP service context to the target AR. IP
service context may include QoS state, AAA state, etc. Being able to
quickly set up IP service context on the target AR is important
because it determines how quickly the MN will receive the same level
of IP service on the target AR as it received on the old. In order
for the IP level signaling to occur, the current AR requires the IP
address of the target AR.
Although not common now, the future generation mobile networks may Typically, the seamless handoff protocols assume that the MN knows a
consist of ARs that are GAARs of each other, but are heterogeneous in Layer 2 identifier for the wireless AP or AR to which it may undergo
administrative control, functionality, link layer technology and a handoff. The Layer 2 identifier might be obtained when the MN has
resources. An MN that is attached to a given AR may have specific Layer 2 beacon contact with the AP. It is now the task of the CAR
requirements as regards these parameters. For example, the MN may discovery protocol is to enable mapping from the Layer 2 identifier
need some hardware or software support from the AR or need some to the IP address of the CAR that serves this AP.
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.
Clearly, a protocol is needed that would enable the functions such as This problem is not dissimilar to reverse address resolution [9] or
solicitation and exchange of capability information among MN, ARs and to the use of DHCP [10] to obtain the address of a host based on its
other network entities. MAC address. In the current case, however, the reverse address
translation is occuring across subnets for ARs rather than between a
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,
whereas the current AR requires the new AR 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.
6. SECURITY CONSIDERATIONS 4.2. Identifying Capabilities of CAR
CAR discovery may allow other nodes to learn the following pieces of Although not common now, future generation mobile networks may
information about an AR: consist of ARs that offer coverage in the same geographical area but
are heterogeneous in capabilities. The basic functionality shared by
all IP routers is that of packet forwarding. In that respect, all
ARs are similar. However, heterogeneity may arise among different
ARs due to factors such as additional functions performed by ARs
(seamless handoff support, security functions, wireless performance
enhancing functions, etc.), administrative and business aspects of
providing service to MN (service provider, cost of access, etc.),
availability of certain type of resources with AR (QoS availability)
etc. A solution is needed that will allow the MN to learn the
capabilities of CARs that it might be interested in. CAR discovery
protocol enables this.
- Physical location 5. SECURITY CONSIDERATIONS
- Capabilities
- State of capabilities.
Malicious nodes may use this kind of information to launch attacks of CAR discovery may allow other nodes to learn information about an
the DoS-style and/or service hijacking. Therefore, the following AR, including its IP address and capabilities. Malicious nodes may
topics should be covered in any protocol developed for CAR discovery: use this kind of information to launch DoS attacks and/or service
hijacking. Therefore, the following topics should be covered in any
solution developed for CAR discovery:
- Authentication of nodes - Authentication of nodes
- Security associations between nodes - Security associations between nodes
- Message/payload encryption. - Message/payload encryption.
7. APPLICABILITY OF EXISTING PROTOCOLS TO CAR DISCOVERY PROBLEM 6. ACKNOWLEDGEMENTS
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
Special thanks are due to John Loughney (Nokia) for his input
during the preparation of this document.
9. REFERENCES
[1] IP Mobility Support, C. Perkins (Editor), RFC 2002, October 1996. Special thanks are due to John Loughney (Nokia) and Hesham Soliman
(Ericsson) for their input during the preparation of this document.
Steve Deering's thoughts about how to involve the mobile node in CAR
discovery were instrumental in achieving more focus to the problem
statement.
[2] Mobility Support in IPv6, D. Johnson and C. Perkins, 7. REFERENCES
draft-ietf-mobileip-ipv6-13.txt,
work in progress, November 2000.
[3] Low Latency Handoffs in Mobile IPv4, MIPv4 Handoffs Design Team, 1. ``IP Mobility Support", C. Perkins (Editor), RFC 2002, October
draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, 1996.
work in progress, February 2001.
[4] Fast handoffs for Mobile IPv6, MIPv6 handoff Design Team, 2. ``Mobility Support in IPv6", D. Johnson, C. Perkins, and Jari
draft-ietf-mobileip-fast-mipv6-01.txt, Arkko, draft-ietf-mobileip-ipv6-17.txt, work in progress, May
work in progress, April 2001. 2002.
[5] Problem Description: Reasons For Performing Context Transfers 3. ``Low Latency Handoffs in Mobile IPv4", MIPv4 Handoffs Design
Between Nodes in an IP Access Network, O. H. Levkowetz et. al., Team, draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, work in
draft-ietf-seamoby-context-transfer-problem-stat-01.doc, progress, February 2001.
work in progress, May 2001.
[6] General requirements for a context transfer framework, H. Sayed 4. ``Fast handoffs for Mobile IPv6", MIPv6 handoff Design Team,
et. al., draft-ietf-seamoby-ct-reqs-00.txt, draft-ietf-mobileip-fast-mipv6-01.txt, work in progress, April
work in progress, May 2001. 2001.
[7] Buffer Management for Smooth handoffs in Mobile IPv6, 5. ``Problem Description: Reasons For Performing Context Transfers
G. Krishnamurthi, R. Chalmers, and C. Perkins, Between Nodes in an IP Access Network", O. H. Levkowetz, et. al.,
draft-krishnamurthi-mobileip-buffer6-01.txt, draft-ietf-seamoby-context-transfer-problem-stat-01.doc, work in
work in progress, March 2001. progress, May 2001.
[8] Open Shortest Path First protocol, Version 2, J. Moy, RFC 2328, 6. ``General requirements for a context transfer framework", H.
April 1998. Sayed, et. al., draft-ietf-seamoby-ct-reqs-00.txt, work in
progress, May 2001.
[9] A Border Gateway Protocol 4 (BGP-4), edited by Y. Rekhter and 7. ``Buffer Management for Smooth handoffs in Mobile IPv6", G.
T. LI, RFC 1771, March 1995. Krishnamurthi, R. Chalmers, and C. Perkins, draft-krishnamurthi-
mobileip-buffer6-01.txt, work in progress, March 2001.
[10] Domain Name System Structure and Delegation, J. Postel, RFC 1591, 8. ``Supporting Optimized Handover for IP Mobility - Requirements
March 1994. for Underlying Systems", J. Kempf, et. al., draft-manyfolks-l2-
mobilereq-02.txt, work in progress, November 2001.
[11] Lightweight Directory Access Protocol, W. Yeong, T. Howes, and 9. ``A Reverse Address Resolution Protocol", R. Finlayson, et. al.
S. Kille, RFC 1777, March 1995. RFC 903, June 1984
[12] Service Location Protocol, Version 2, E. Guttman et. al., 10. ``Dynamic Host Configuration Protocol", R. Droms, RFC 1531,
RFC 2608, June 1999. October 1993.
10. AUTHORS' ADDRESS 8. AUTHORS' ADDRSSES
Dirk Trossen Dirk Trossen
Communication Systems Laboratory Communication Systems Laboratory
Nokia Research Center Nokia Research Center
5 Wayside Road 5 Wayside Road
Burlington, MA 01803, USA Burlington, MA 01803, USA
Phone: +1 781 993 3605 Phone: +1 781 993 3605
Fax: +1 781 993 1907 Fax: +1 781 993 1907
E-mail: dirk.trossen@nokia.com E-mail: dirk.trossen@nokia.com
Govind Krishnamurthi Govind Krishnamurthi
Communication Systems Laboratory Communication Systems Laboratory
Nokia Research Center Nokia Research Center
5 Wayside Road 5 Wayside Road
Burlington, MA 01803, USA Burlington, MA 01803, USA
Phone: +1 781 993 3627 Phone: +1 781 993 3627
Fax: +1 781 993 1907 Fax: +1 781 993 1907
E-mail: govind.krishnamurthi@nokia.com E-mail: govind.krishnamurthi@nokia.com
Hemant Chaskar Hemant Chaskar
Communication Systems Laboratory Communication Systems Laboratory
Nokia Research Center Nokia Research Center
5 Wayside Road 5 Wayside Road
Burlington, MA 01803, USA Burlington, MA 01803, USA
Phone: +1 781 993 3785 Phone: +1 781 993 3785
Fax: +1 781 993 1907 Fax: +1 781 993 1907
E-mail: hemant.chaskar@nokia.com E-mail: hemant.chaskar@nokia.com
James Kempf James Kempf
DoCoMo Communication Laboratories, USA DoCoMo Communication Laboratories, USA
181 Metro Drive, Suite 300 181 Metro Drive, Suite 300
San Jose, CA 95110, USA San Jose, CA 95110, USA
Phone: +1 408 451 4711 Phone: +1 408 451 4711
Email: kempf@docomolabs-usa.com Email: kempf@docomolabs-usa.com
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/