draft-ietf-seamoby-cardiscovery-issues-00.txt   draft-ietf-seamoby-cardiscovery-issues-01.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-00.txt Hemant Chaskar draft-ietf-seamoby-cardiscovery-issues-01.txt Hemant Chaskar
Expires: January 2002 Nokia 20 September 2001 Nokia
James Kempf James Kempf
Sun Microsystems, Inc. Sun Microsystems, Inc.
July 2001
Issues in candidate access router discovery for seamless IP handoffs Issues in candidate access router discovery
for seamless IP-level handoffs
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
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.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 (2001). 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 information from one access router to Layer 3 routing reachability point from one access router to another,
another, before or after the mobile node has established a Layer 2 before or after the mobile node has established a Layer 2 connection
connection with the radio access point that is covered by the new with the radio access point that is covered by the new access router.
access router. In addition, other context information about the In addition, other context information about the mobile node's packet
mobile node's packet session may be transferred from the old access session may be transferred from the old access router to the new one,
router to the new one, in order to minimize the service disruption in order to minimize the service disruption during the handoff
during the handoff process. While the exact details of how this is process. While the exact details of how this is accomplished vary
accomplished vary depending on the IP mobility and seamless handoff depending on the IP mobility and seamless handoff protocols, one
protocols, one common thread required for seamless handoffs is common thread required for seamless handoffs is identifying the
identifying the candidate access routers for the mobile node's candidate access routers for the mobile node's handoff. At the time
handoff. When a collection of candidates has been identified, an of IP-level handoff, if a collection of candidates has been
algorithm is run to determine the target access router, and this identified, an algorithm is run to determine the target access
router becomes the target of handoff at Layer 3. This document router for the mobile node's handoff. This document presents a
presents a problem statement describing issues involved in designing problem statement describing issues involved in designing a candidate
a candidate access router discovery protocol. The document does not access router discovery protocol. The document does not discuss the
discuss the algorithm by which the actual target router is algorithm by which the actual target router is selected, nor how the
identified, nor how the handoff to the target is achieved. handoff to the target is achieved.
TABLE OF CONTENTS TABLE OF CONTENTS
1. INTRODUCTION 1 1. INTRODUCTION 1
2. TERMINOLOGY 1 2. MOTIVATION FOR CAR DISCOVERY 1
3. CANDIDATE ACCESS ROUTER DISCOVERY PROBLEM 2 3. TERMINOLOGY 2
3.1 Anticipated CAR Discovery 2 4. CANDIDATE ACCESS ROUTER DISCOVERY PROBLEM 3
3.2 Dynamic CAR Discovery 3
3.3 Hybrid CAR Discovery 3
4. SPECIFIC ISSUES IN CAR DISCOVERY 3 4.1 Anticipated CAR Discovery 3
4.2 Dynamic CAR Discovery 4
4.3 Hybrid CAR Discovery 5
4.1 Identifying PAARs 3 5. SPECIFIC ISSUES IN CAR DISCOVERY 5
4.2 Identifying capabilities of PAARs 4
4.3 Security considerations 5
5. REFERENCES 5 5.1 Identifying GAARs 5
5.2 Identifying capabilities of GAARs 7
5.3 Security considerations 8
6. AUTHORS' ADDRESS 6 6. APPLICABILITY OF EXISTING PROTOCOLS 8
7. REFERENCES 9
8. AUTHORS' ADDRESS 10
ACKNOWLEDGMENTS ACKNOWLEDGMENTS
Special thanks are due to John Loughney (Nokia) for his input Special thanks are due to John Loughney (Nokia) for his input
during the preparation of this document. during the preparation of this document.
1. INTRODUCTION 1. INTRODUCTION
IP mobility protocols enable mobile nodes (MNs) to change the access IP mobility protocols enable mobile nodes (MNs) to change the access
routers (ARs) by which they access the Internet. An AR providing routers (ARs) by which they obtain the Layer 3 connectivity to
Internet connectivity to the MN changes when movement of the MN the Internet, while communicating with another node over the
causes a change in the radio access point through which the MN Internet. An AR providing Internet connectivity to the MN changes
communicates with the wired network, such that the new radio access when the movement of the MN causes a change in the radio access point
point is in a new subnet. There are existing solutions [1, 2] that through which the MN communicates with the wired network, such that
enable MNs to execute handoffs between the ARs. Additionally, work is the AR serving the new radio access point is in a new subnet. There
underway [3, 4, 5, 6, 7], to define protocols that would allow are existing solutions [1, 2] that enable MNs to execute IP-level
seamless, meaning low latency and low packet loss, handoffs of MNs handoffs between the ARs. Additionally, work is underway [3, 4, 5,
between the ARs. These handoff solutions assume that the identity of 6, 7], to define protocols that would allow seamless, meaning low
the new AR is known to the old AR. They do not provide a solution to latency and low packet loss, handoffs of MNs between the ARs. These
the problem of discovering the target AR for the MN's handoff. What handoff solutions assume that the identity (IP address) of the target
is required is a protocol that would allow an AR or an MN to discover AR is known to the current AR. They do not provide a solution to the
the neighboring ARs for handoff, along with their capabilities. This problem of selecting the target AR for the MN's handoff. What is
information can be used for selecting the actual target AR for the required is a protocol that would allow an AR or an MN to discover
MN's handoff. This draft discusses the issues involved in the problem the neighboring ARs whose capabilities meet the requirements of
of candidate AR discovery. The draft does not discuss the problem of a MN, thus becoming potential target ARs for handoff. Such ARs are
actually selecting the target AR to which handoff is performed, nor called "Candidate ARs". This information can be used for selecting
the actual handoff process itself. 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.
2. TERMINOLOGY To motivate the Candidate AR discovery problem, we now describe some
illustrative scenarios in which the Candidate AR discovery protocol
may be useful.
2. MOTIVATION FOR CANDIDATE AR DISCOVERY
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
preference.
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.
3. TERMINOLOGY
Access Point (AP) Access Point (AP)
A radio transceiver by which an MN obtains Layer 2 connectivity A radio transceiver by which an MN obtains Layer 2 connectivity
with the wired network. with the wired network.
Access Router (AR) Access Router (AR)
An IP router residing in an access network and connected to one An IP router residing in an access network and connected to one
or more APs. An AR offers IP connectivity to MN. or more APs. An AR offers IP connectivity to MN.
Physically Adjacent AR (PAAR) Geographically Adjacent AR (GAAR)
An AR whose coverage area is such that an MN may move from the 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 coverage area of the AR currently serving the MN into the coverage
area of this AR. 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) Candidate AR (CAR)
This is an AR that is a candidate for MN's handoff. CAR is 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 necessarily a GAAR of the AR currently serving the MN, and also has
the capability set required to serve the MN. the capability set required to serve the MN.
Target AR (TAR) Target AR (TAR)
This is an AR with which the procedures for MN's handoff This is an AR with which the procedures for the MN's IP-level handoff
are initiated. are initiated. TAR is usually selected from the set of CARs.
TAR Selection Algorithm TAR Selection Algorithm
The algorithm that determines a unique TAR for MN's handoff from The algorithm that determines a unique TAR for MN's handoff from
the set of CARs. The exact nature and definition of this algorithm the set of CARs. The exact nature and definition of this algorithm
is outside the scope of this document. is outside the scope of this document.
3. CANDIDATE ACCESS ROUTER DISCOVERY PROBLEM 4. CANDIDATE ACCESS ROUTER DISCOVERY PROBLEM
There are two basic approaches to CAR discovery, namely, Anticipated There are two basic approaches to CAR discovery, namely, Anticipated
CAR Discovery and Dynamic CAR Discovery. CAR Discovery and Dynamic CAR Discovery.
3.1 Anticipated CAR Discovery 4.1 Anticipated CAR Discovery
In this approach, an AR currently serving the MN identifies all CARs In this approach, an AR currently serving the MN identifies all CARs
for the MN's handoff, at some point prior to handoff. This for the MN's handoff, at some point prior to handoff. This
information is then immediately available at the time of handoff as information is then immediately available at the time of handoff as
input to the TAR Selection Algorithm. Another input into the TAR input to the TAR Selection Algorithm. Another input to the TAR
Selection Algorithm may be the preferences expressed by the MN prior Selection Algorithm may be the preferences expressed by the MN prior
to the handoff, or preferences enforced by the administrative to the handoff, or preferences enforced by the administrative
control. At the time of handoff, it may only be required to provide control. At the time of handoff, it may only be required to provide
input to TAR Selection Algorithm about the reachability of input to TAR Selection Algorithm about the reachability of
neighboring ARs from the MN. The advantage of this approach is that neighboring ARs from the MN. This reachability information is usually
the handoff can be executed quickly because the AR has already in the form of identity of the AP to which the MN can listen to, and
collected much of the information needed by the TAR Selection
Algorithm. Also, this approach does not generate much radio traffic the current AR has to resolve this AP identity to the GAAR's IP
for performing CAR discovery. address.
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 The Anticipated CAR Discovery problem encompasses the areas outlined
in the box in Figure 1. in the box in Figure 1.
----------------------------------------------------------------- -----------------------------------------------------------------
| All routers | | All routers |
| | | | | Discovery of ARs whose coverage |
| | Physical adjacency discovery | | | areas overlap (GAARs)with that of |
| v | | v the current AR |
| Local map of PAARs at current AR | | Local map of GAARs at current AR |
| | | | | |
| | Capability identification | | | Capability identification |
| v | | v |
| CARs for MN's handoff identified at current AR | | CARs for MN's handoff identified at current AR |
| | | | | |
--------------------------|-------------------------------------- --------------------------|--------------------------------------
| |
| Predefined preferences of the MN | Predefined preferences of the MN
AR Reachability | negotiated at admission time or AR Reachability | and administrative preferences
for the MN | administrative preferences for the MN |
| | | | | |
v v v v v v
TAR Selection Algorithm executed at the time of TAR Selection Algorithm executed at the time of
handoff to determine unique TAR for MN's handoff handoff to determine unique TAR for MN's handoff
Figure 1: The Anticipated CAR Discovery Problem Figure 1: The Anticipated CAR Discovery Problem
3.2 Dynamic CAR Discovery 4.2 Dynamic CAR Discovery
In this approach, an MN dynamically obtains information about In this approach, an MN dynamically obtains information about
the available ARs for handoff, along with their capabilities. When the available ARs for handoff, along with their capabilities. When
the MN detects an AR that has capabilities which match its the MN detects an AR that has capabilities which match its
preferences, the MN may notify the currently serving AR to perform a preferences, the MN may notify the currently serving AR to perform a
handoff to this AR using one or more of the seamless handoff handoff to this AR using one or more of the seamless handoff
protocols. The advantage of this technique is that the MN has protocols.
fine-grained control over the TAR selection. However, this approach
generates more radio traffic during the CAR discovery step. Also, it The advantage of this technique is that the MN has fine-grained
is required that the MN can listen to or, in some cases, even talk to control over the TAR selection. However, this approach generates more
the PAARs for collecting capability information and negotiating radio traffic during the CAR discovery step. This is because,
preferences, while still being connected to the current AR. 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.
The Dynamic CAR Discovery problem encompasses the areas outlined The Dynamic CAR Discovery problem encompasses the areas outlined
in the box in Figure 2. in the box in Figure 2.
-------------------------------------------------------------- --------------------------------------------------------------
| | | |
| PAARs identified by MN | | GAARs identified by MN |
| | | | | |
| | Capability identification by MN | | | Capability identification by MN |
| | | | | |
| v | | v |
| CARs for MN's handoff identified at MN | | CARs for MN's handoff identified at MN |
| | | | | |
---------------------------|---------------------------------- ---------------------------|----------------------------------
| |
| TAR selection by MN at the | TAR selection by MN at the
| time of handoff | time of handoff
v v
Unique TAR identity sent to current AR Unique TAR identity sent to current AR
Figure 2: Dynamic CAR Discovery Problem Figure 2: Dynamic CAR Discovery Problem
3.3 Hybrid CAR Discovery 4.3 Hybrid CAR Discovery
In practice, a hybrid of the above techniques for CAR discovery may In practice, a hybrid of the above techniques for CAR discovery may
be used. In the hybrid approach, the partitioning of capability be used. In the hybrid approach, the partitioning of capability
information between the two techniques as well as the partitioning of information between the two techniques as well as the partitioning of
TAR selection process between the MN and the current AR is possible. TAR selection process between the MN and the current AR is possible.
4. SPECIFIC ISSUES IN CAR DISCOVERY 5. SPECIFIC ISSUES IN CAR DISCOVERY
The following sections describe the specific issues in the CAR The following sections describe the specific issues in the CAR
discovery, may it be done in anticipated, dynamic or hybrid way. discovery, may it be done in anticipated, dynamic or hybrid way.
4.1 Identifying PAARs 5.1 Identifying GAARs
A basic requirement for a new AR to be considered as a CAR for MN's 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 handoff is that the coverage area of the new AR be "geographically"
adjacent" to that of the AR currently serving the MN. In other words, 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
a new AR must be a PAAR. Note, the physical adjacency of the coverage from the coverage area of one AR to another (GAARs have APs whose
areas of two ARs is not necessarily implied by their "logical" coverage areas are adjacent or overlapping). Conversely, GAARs need
adjacency. Logical adjacency of two ARs means that there is just one not be logically adjacent, and may even have IP addresses in
IP hop between the two ARs, while physical adjacency of two ARs different administrative domains.
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 The MIP fast handoff protocols specified in [3] and [4] or the
each AR. However, such an approach has disadvantages and in many context transfer framework specified in [6] require that the current
cases, may not be feasible. For instance, two ARs that are physically AR or Foreign Agent (FA) (generically called ARs here for short) have
adjacent may be under different administrative control, and thus, are a list of ARs to which a MN could be handed over. In other words, the
not informed about each other's presence. Even within the same current AR has a list of CARs. There is no reason, a priori, why
administrative domain, the manual configuration approach demands much these CARs need to in topologically adjacent subnets. A CAR could
network planning in terms of the coverage areas of different ARs. potentially be in a completely different BGP autonomous system. The
Finally, the manual configuration approach is not suitable if the only requirement is that the corresponding APs be geographically
routers can be physically relocated or their coverage area changed, adjacent. Fig. 3 illustrates the problem.
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 BGP Autonomous BGP Autonomous
requires a protocol that allows ARs to exchange physical adjacency System A System B
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: +----+ +----+
| 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, 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 Although not common now, the future generation mobile networks may
consist of ARs that are physically adjacent, but are heterogeneous in consist of ARs that are GAARs of each other, but are heterogeneous in
administrative control, function, capability, link layer technology administrative control, functionality, link layer technology and
and resources. An MN that is attached to a given AR may have specific resources. An MN that is attached to a given AR may have specific
requirements as regards these parameters. For example, the MN may requirements as regards these parameters. For example, the MN may
need some hardware or software support from the access router to run need some hardware or software support from the AR or need some
certain IP-based applications. Support for QoS, security, multicast, application servers topologically close to the AR, to run certain
header compression etc. are some other aspects that need to be IP-based applications. Support for QoS, security, multicast, header
considered when choosing the CAR for MN's handoff. It may also be compression etc. are some other aspects that need to be considered
required to assure some security association or policy agreement when choosing the CAR for MN's handoff. It may also be required to
between the current AR and its physical neighbor in order to allow assure some security association, policy agreement or billing
MN's handoff between them. The various capabilities that need to be contract between the current AR and its GAARs in order to allow
identified in PAAR for smooth handoff are outside the scope of this MN's handoff between them. Finally, the access routers that are GAARs
draft. However, as an illustration, the capabilities to be identified of each other need to exchange information regarding the
may include administrative parameters such as ISP, organization and correspondence between their IP addresses and the identities of the
policy information; cost of access parameters; information about APs (which the MN can listen to) that are connected to them.
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
need for NAT traversal; resource parameters such as load and so on.
In the Anticipated CAR Discovery, capability exchange between ARs In the Anticipated CAR Discovery, capability exchange between ARs
occurs over the Internet. Thus, a protocol is needed that would allow occurs over the Internet. Thus, a protocol is needed that would allow
ARs to exchange capability information. 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 In the Dynamic CAR Discovery approach, the MN is soliciting or
receiving the capabilities of PAARs directly. Some protocol is receiving the capabilities of GAARs directly. Some protocol is
required to allow the MN to solicit, or the ARs to advertise their required to allow the MN to solicit, or the ARs to advertise their
capabilities. capabilities.
4.3 Security considerations 5.3 Security considerations
AR discovery may allow other nodes to learn the following pieces of CAR discovery may allow other nodes to learn the following pieces of
information about an AR: information about an AR:
- Physical location - Physical location
- Capabilities - Capabilities
- State of capabilities. - State of capabilities.
Malicious nodes may use this kind of information to launch attacks of Malicious nodes may use this kind of information to launch attacks of
the DoS-style and/or service hijacking. Therefore, the following the DoS-style and/or service hijacking. Therefore, the following
topics should be covered in any protocol developed for AR discovery: topics should be covered in any protocol developed for CAR discovery:
- Authentication of nodes - Authentication of nodes
- Security associations between nodes - Security associations between nodes
- Message/payload encryption. - Message/payload encryption.
5. REFERENCES 6. APPLICABILITY OF EXISTING PROTOCOLS TO CAR DISCOVERY PROBLEM
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.
7. REFERENCES
[1] IP Mobility Support, C. Perkins (Editor), RFC 2002, October 1996. [1] IP Mobility Support, C. Perkins (Editor), RFC 2002, October 1996.
[2] Mobility Support in IPv6, D. Johnson and C. Perkins, [2] Mobility Support in IPv6, D. Johnson and C. Perkins,
draft-ietf-mobileip-ipv6-13.txt, draft-ietf-mobileip-ipv6-13.txt,
work in progress, November 2000. work in progress, November 2000.
[3] Low Latency Handoffs in Mobile IPv4, MIPv4 Handoffs Design Team, [3] Low Latency Handoffs in Mobile IPv4, MIPv4 Handoffs Design Team,
draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt,
work in progress, February 2001. work in progress, February 2001.
skipping to change at page 6, line 14 skipping to change at page 9, line 35
[6] General requirements for a context transfer framework, H. Sayed [6] General requirements for a context transfer framework, H. Sayed
et. al., draft-ietf-seamoby-ct-reqs-00.txt, et. al., draft-ietf-seamoby-ct-reqs-00.txt,
work in progress, May 2001. work in progress, May 2001.
[7] Buffer Management for Smooth handoffs in Mobile IPv6, [7] Buffer Management for Smooth handoffs in Mobile IPv6,
G. Krishnamurthi, R. Chalmers, and C. Perkins, G. Krishnamurthi, R. Chalmers, and C. Perkins,
draft-krishnamurthi-mobileip-buffer6-01.txt, draft-krishnamurthi-mobileip-buffer6-01.txt,
work in progress, March 2001. work in progress, March 2001.
6. AUTHORS' ADDRESS [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.
8. AUTHORS' ADDRESS
Dirk Trossen Dirk Trossen
Communication Systems Laboratory, Nokia Research Center Communication Systems Laboratory
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, Nokia Research Center Communication Systems Laboratory
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, Nokia Research Center Communication Systems Laboratory
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
Network and Security Research Center, Sun Labs Network and Security Research Center, Sun Labs
Sun Microsystems, Inc. Sun Microsystems, Inc.
 End of changes. 

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