draft-ietf-seamoby-cardiscovery-issues-01.txt   draft-ietf-seamoby-cardiscovery-issues-02.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-01.txt Hemant Chaskar draft-ietf-seamoby-cardiscovery-issues-02.txt Hemant Chaskar
20 September 2001 Nokia 15 January 2002 Nokia
James Kempf James Kempf
Sun Microsystems, Inc. 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 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
skipping to change at page 1, line 65 skipping to change at page 1, line 65
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. MOTIVATION FOR CAR DISCOVERY 1 2. MOTIVATION FOR CAR DISCOVERY 1
3. TERMINOLOGY 2 3. TERMINOLOGY 2
4. CANDIDATE ACCESS ROUTER DISCOVERY PROBLEM 3 4. APPROACHES TO CANDIDATE ACCESS ROUTER DISCOVERY 3
4.1 Anticipated CAR Discovery 3 4.1 Anticipated CAR Discovery 3
4.2 Dynamic CAR Discovery 4 4.2 Dynamic CAR Discovery 4
4.3 Hybrid CAR Discovery 5 4.3 Hybrid CAR Discovery 5
5. SPECIFIC ISSUES IN CAR DISCOVERY 5 5. SPECIFIC ISSUES IN CAR DISCOVERY 5
5.1 Identifying GAARs 5 5.1 Identifying GAARs 5
5.2 Identifying capabilities of GAARs 7 5.2 Identifying capabilities of GAARs 7
5.3 Security considerations 8
6. APPLICABILITY OF EXISTING PROTOCOLS 8 6. SECURITY CONSIDERATIONS 8
7. REFERENCES 9 7. APPLICABILITY OF EXISTING PROTOCOLS 8
8. AUTHORS' ADDRESS 10 8. ACKNOWLEDGEMENTS 8
ACKNOWLEDGMENTS 9. REFERENCES 9
Special thanks are due to John Loughney (Nokia) for his input 10. AUTHORS' ADDRESS 10
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 obtain the Layer 3 connectivity to routers (ARs) by which they obtain the Layer 3 connectivity to
the Internet, while communicating with another node over the the Internet, while communicating with another node over the
Internet. An AR providing Internet connectivity to the MN changes Internet. An AR providing Internet connectivity to the MN changes
when the movement of the MN causes a change in the radio access point 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 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 the AR serving the new radio access point is in a new subnet. There
skipping to change at page 1, line 113 skipping to change at page 1, line 111
problem of selecting the target AR for the MN's handoff. What is 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 required is a protocol that would allow an AR or an MN to discover
the neighboring ARs whose capabilities meet the requirements of the neighboring ARs whose capabilities meet the requirements of
a MN, thus becoming potential target ARs for handoff. Such ARs are a MN, thus becoming potential target ARs for handoff. Such ARs are
called "Candidate ARs". This information can be used for selecting called "Candidate ARs". This information can be used for selecting
the target AR at the time of MN's handoff. This draft discusses the 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 issues involved in the problem of Candidate AR discovery. The draft
does not discuss the problem of selecting the target AR to which does not discuss the problem of selecting the target AR to which
handoff is performed, nor the handoff process itself. handoff is performed, nor the handoff process itself.
To motivate the Candidate AR discovery problem, we now describe some To provide motivation for the Candidate AR discovery work, some
illustrative scenarios in which the Candidate AR discovery protocol illustrative scenarios are given below in which Candidate AR
may be useful. discovery protocol will be useful.
2. MOTIVATION FOR CANDIDATE AR DISCOVERY 2. MOTIVATION FOR CANDIDATE AR DISCOVERY
This section describes some seamless handoff features that can be This section describes some seamless handoff features that can be
implemented if there are means to identify the Candidate ARs for implemented if there are means to identify the Candidate ARs for
the MN's handoff. the MN's handoff.
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
skipping to change at page 3, line 26 skipping to change at page 3, line 19
a handoff candidate. 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 GAAR 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 the MN's IP-level handoff This is an AR with which the procedures for the MN's IP-level
are initiated. TAR is usually selected from the set of CARs. handoff 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.
4. CANDIDATE ACCESS ROUTER DISCOVERY PROBLEM 4. APPROACHES TO CANDIDATE ACCESS ROUTER DISCOVERY
There are two basic approaches to CAR discovery, namely, Anticipated In this section, we describe three approaches to CAR discovery,
CAR Discovery and Dynamic 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 4.1 Anticipated CAR Discovery
In this approach, an AR currently serving the MN identifies all CARs In Anticipated CAR Discovery, CAR discovery is performed at some
for the MN's handoff, at some point prior to handoff. This point prior to the MN performing a handoff. This can be performed in
information is then immediately available at the time of handoff as a number of ways and with various entities participating in the
input to the TAR Selection Algorithm. Another input to the TAR process. One illustrative method for Anticipated CAR Discovery is
Selection Algorithm may be the preferences expressed by the MN prior given below.
to the handoff, or preferences enforced by the administrative
control. At the time of handoff, it may only be required to provide
input to TAR Selection Algorithm about the reachability of
neighboring ARs from the MN. This reachability information is usually
in the form of identity of the AP to which the MN can listen to, and
the current AR has to resolve this AP identity to the GAAR's IP In this method, an AR currently serving an MN can identify a set of
address. 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 this approach is that the handoff can be executed The advantage of Anticipated CAR Discovery is that the handoff can be
quickly because the AR has already collected much of the information executed quickly because much of the information needed by the TAR
needed by the TAR Selection Algorithm. Also, this approach does not Selection Algorithm is collected in advance of handoff.
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 Anticipated CAR Discovery is depicted in Figure 1.
in the box in Figure 1.
----------------------------------------------------------------- -----------------------------------------------------------------
| All routers | | All routers |
| | Discovery of ARs whose coverage | | | Discovery of ARs whose coverage |
| | areas overlap (GAARs)with that of | | | areas overlap (GAARs)with that of |
| v the current AR | | v the current AR |
| Local map of GAARs at current AR | | Local map of GAARs at current AR |
| | | | | |
| | Capability identification | | | Capability identification |
| v | | v |
skipping to change at page 4, line 38 skipping to change at page 4, line 32
--------------------------|-------------------------------------- --------------------------|--------------------------------------
| |
| Predefined preferences of the MN | Predefined preferences of the MN
AR Reachability | and administrative preferences AR Reachability | and administrative preferences
for the MN | 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: Anticipated CAR Discovery
4.2 Dynamic CAR Discovery 4.2 Dynamic CAR Discovery
In this approach, an MN dynamically obtains information about In Dynamic CAR discovery, CAR discovery is performed at the time the
the available ARs for handoff, along with their capabilities. When MN is about to undergo handoff. Again, this can be performed in a
the MN detects an AR that has capabilities which match its number of ways and with various entities participating in the process.
preferences, the MN may notify the currently serving AR to perform a One illustrative method for Dynamic CAR Discovery is given below.
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. 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 According to this method, an MN dynamically obtains information about
the GAARs and negotiate requirements with the GAARs, while still the available ARs for handoff, along with their capabilities. This is
being connected to the current AR. 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.
The Dynamic CAR Discovery problem encompasses the areas outlined Dynamic CAR Discovery is shown in Figure 2.
in the box in Figure 2.
-------------------------------------------------------------- --------------------------------------------------------------
| | | |
| GAARs identified by MN | | GAARs identified at handoff time |
| | | | | |
| | Capability identification by MN | | | Capability identification |
| | | | | |
| v | | v |
| CARs for MN's handoff identified at MN | | CARs for MN's handoff identified |
| | | | | |
---------------------------|---------------------------------- ---------------------------|----------------------------------
| |
| TAR selection by MN at the | TAR selection at the
| time of handoff | time of handoff
v v
Unique TAR identity sent to current AR Unique TAR identity
Figure 2: Dynamic CAR Discovery Problem Figure 2: Dynamic CAR Discovery
4.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 Anticipated and Dynamic CAR discovery
be used. In the hybrid approach, the partitioning of capability approaches may be used. For example, in the hybrid approach, the GAAR
information between the two techniques as well as the partitioning of discovery and much of the capability identification may be performed
TAR selection process between the MN and the current AR is possible. 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 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.
5.1 Identifying GAARs 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 "geographically" handoff is that the coverage area of the new AR be "geographically"
skipping to change at page 7, line 29 skipping to change at page 7, line 22
each other's presence. Even within the same administrative domain, each other's presence. Even within the same administrative domain,
the manual configuration approach demands much network planning in the manual configuration approach demands much network planning in
terms of the coverage areas of different ARs. Finally, the manual terms of the coverage areas of different ARs. Finally, the manual
configuration approach is not suitable if the ARs can be physically configuration approach is not suitable if the ARs can be physically
relocated or their coverage area changed, thus altering the relocated or their coverage area changed, thus altering the
geographical scope of their coverage areas. Such a scenario is very geographical scope of their coverage areas. Such a scenario is very
common when ARs are temporarily introduced in hot spots. Clearly, a common when ARs are temporarily introduced in hot spots. Clearly, a
more automatic and dynamic mechanism is needed to discover GAARs more automatic and dynamic mechanism is needed to discover GAARs
without much administrative intervention. without much administrative intervention.
For the Anticipated CAR Discovery, the process of identifying GAARs For the Anticipated CAR Discovery method described in Section 4.1,
requires a protocol that allows ARs to exchange the information about the process of identifying GAARs requires a protocol that allows ARs
the geographical adjacency of their APs, in advance of handoff. In to exchange the information about the geographical adjacency of their
Dynamic CAR Discovery, the MN automatically serves as the judge of 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 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. Router Advertisement of the new AR, then the new AR is GAAR.
5.2 Identifying capabilities of GAARs: 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 GAARs of each other, but are heterogeneous in consist of ARs that are GAARs of each other, but are heterogeneous in
administrative control, functionality, link layer technology and administrative control, functionality, link layer technology 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
skipping to change at page 8, line 5 skipping to change at page 7, line 49
IP-based applications. Support for QoS, security, multicast, header IP-based applications. Support for QoS, security, multicast, header
compression etc. are some other aspects that need to be considered 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 when choosing the CAR for MN's handoff. It may also be required to
assure some security association, policy agreement or billing assure some security association, policy agreement or billing
contract between the current AR and its GAARs in order to allow contract between the current AR and its GAARs in order to allow
MN's handoff between them. Finally, the access routers that are GAARs MN's handoff between them. Finally, the access routers that are GAARs
of each other need to exchange information regarding the of each other need to exchange information regarding the
correspondence between their IP addresses and the identities of the correspondence between their IP addresses and the identities of the
APs (which the MN can listen to) that are connected to them. APs (which the MN can listen to) that are connected to them.
In the Anticipated CAR Discovery, capability exchange between ARs Clearly, a protocol is needed that would enable the functions such as
occurs over the Internet. Thus, a protocol is needed that would allow solicitation and exchange of capability information among MN, ARs and
ARs to exchange capability information. Capability exchange between other network entities.
ARs should also allow periodic as well as "as needed" exchange of
capabilities between GAARs.
In the Dynamic CAR Discovery approach, the MN is soliciting or
receiving the capabilities of GAARs directly. Some protocol is
required to allow the MN to solicit, or the ARs to advertise their
capabilities.
5.3 Security considerations 6. SECURITY CONSIDERATIONS
CAR 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 CAR 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.
6. APPLICABILITY OF EXISTING PROTOCOLS TO CAR DISCOVERY PROBLEM 7. APPLICABILITY OF EXISTING PROTOCOLS TO CAR DISCOVERY PROBLEM
The simplest possible discovery solution is to statically configure The simplest possible discovery solution is to statically configure
the ARs in two geographically adjacent domains with the IP addresses the ARs in two geographically adjacent domains with the IP addresses
of their counterparts in the other domain. This solution is of their counterparts in the other domain. This solution is
impractical, particularly when the geographically adjacent domain impractical, particularly when the geographically adjacent domain
belongs to another administrative entity, such as a different belongs to another administrative entity, such as a different
Wireless ISP (WISP). The neighboring WISP may decide to reconfigure, Wireless ISP (WISP). The neighboring WISP may decide to reconfigure,
add subnets, or remove them, as traffic patterns change. Propagating add subnets, or remove them, as traffic patterns change. Propagating
those changes into static configurations would result in significant those changes into static configurations would result in significant
availability lags. availability lags.
skipping to change at page 9, line 5 skipping to change at page 8, line 44
Another solution is to use a simple directory based discovery Another solution is to use a simple directory based discovery
solution, such as DNS [10], LDAP [11], or SLP [12]. Attribute-based solution, such as DNS [10], LDAP [11], or SLP [12]. Attribute-based
discovery mechanisms such as LDAP and SLP could potentially handle discovery mechanisms such as LDAP and SLP could potentially handle
non-geographic capabilities, such as radio technology, but geographic non-geographic capabilities, such as radio technology, but geographic
information may be difficult to cast into the form of attribute/value information may be difficult to cast into the form of attribute/value
pairs. In addition, information on changes in AR availability needs pairs. In addition, information on changes in AR availability needs
to propagate dynamically between ARs rather than requiring the ARs to to propagate dynamically between ARs rather than requiring the ARs to
explicitly ask for it. Finally, the client-server nature of these explicitly ask for it. Finally, the client-server nature of these
protocols has the associated scalability and robustness concerns. protocols has the associated scalability and robustness concerns.
7. REFERENCES 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. [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 10, line 5 skipping to change at page 10, line 5
[10] Domain Name System Structure and Delegation, J. Postel, RFC 1591, [10] Domain Name System Structure and Delegation, J. Postel, RFC 1591,
March 1994. March 1994.
[11] Lightweight Directory Access Protocol, W. Yeong, T. Howes, and [11] Lightweight Directory Access Protocol, W. Yeong, T. Howes, and
S. Kille, RFC 1777, March 1995. S. Kille, RFC 1777, March 1995.
[12] Service Location Protocol, Version 2, E. Guttman et. al., [12] Service Location Protocol, Version 2, E. Guttman et. al.,
RFC 2608, June 1999. RFC 2608, June 1999.
8. AUTHORS' ADDRESS 10. AUTHORS' ADDRESS
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
skipping to change at page 10, line 38 skipping to change at page 10, line 38
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
Network and Security Research Center, Sun Labs DoCoMo Communication Laboratories, USA
Sun Microsystems, Inc. 181 Metro Drive, Suite 300
15 Network Circle San Jose, CA 95110, USA
Menlo Park, CA 94025, USA
Phone: +1 650 786 5890 Phone: +1 408 451 4711
Fax: +1 650 786 6445 Email: kempf@docomolabs-usa.com
E-mail: james.kempf@eng.sun.com
 End of changes. 

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