IETF Seamoby Working Group Dirk Trossen INTERNET-DRAFT Govind Krishnamurthi draft-ietf-seamoby-cardiscovery-issues-01.txt Hemant Chaskar 20 September 2001 Nokia James Kempf Sun Microsystems, Inc. Issues in candidate access router discovery for seamless IP-level handoffs Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (c) The Internet Society (2001). All rights reserved. ABSTRACT Handoff in IP mobility protocols involves moving a mobile node's Layer 3 routing reachability point from one access router to another, before or after the mobile node has established a Layer 2 connection with the radio access point that is covered by the new access router. In addition, other context information about the mobile node's packet session may be transferred from the old access router to the new one, in order to minimize the service disruption during the handoff process. While the exact details of how this is accomplished vary depending on the IP mobility and seamless handoff protocols, one common thread required for seamless handoffs is identifying the candidate access routers for the mobile node's handoff. At the time of IP-level handoff, if a collection of candidates has been identified, an algorithm is run to determine the target access router for the mobile node's handoff. This document presents a problem statement describing issues involved in designing a candidate access router discovery protocol. The document does not discuss the algorithm by which the actual target router is selected, nor how the handoff to the target is achieved. Trossen, Krishnamurthi, Chaskar, Kempf [Page i]
INTERNET-DRAFT Candidate Access Router Discovery Issues Sept, 2001 TABLE OF CONTENTS 1. INTRODUCTION 1 2. MOTIVATION FOR CAR DISCOVERY 1 3. TERMINOLOGY 2 4. CANDIDATE ACCESS ROUTER DISCOVERY PROBLEM 3 4.1 Anticipated CAR Discovery 3 4.2 Dynamic CAR Discovery 4 4.3 Hybrid CAR Discovery 5 5. SPECIFIC ISSUES IN CAR DISCOVERY 5 5.1 Identifying GAARs 5 5.2 Identifying capabilities of GAARs 7 5.3 Security considerations 8 6. APPLICABILITY OF EXISTING PROTOCOLS 8 7. REFERENCES 9 8. AUTHORS' ADDRESS 10 ACKNOWLEDGMENTS Special thanks are due to John Loughney (Nokia) for his input during the preparation of this document. Trossen, Krishnamurthi, Chaskar, Kempf [Page ii]
INTERNET-DRAFT Candidate Access Router Discovery Issues Sept, 2001 1. INTRODUCTION 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 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 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. Trossen, Krishnamurthi, Chaskar, Kempf [Page 1]
INTERNET-DRAFT Candidate Access Router Discovery Issues Sept, 2001 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) 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. Trossen, Krishnamurthi, Chaskar, Kempf [Page 2]
INTERNET-DRAFT Candidate Access Router Discovery Issues Sept, 2001 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. CANDIDATE ACCESS ROUTER DISCOVERY PROBLEM There are two basic approaches to CAR discovery, namely, Anticipated CAR Discovery and Dynamic CAR Discovery. 4.1 Anticipated CAR Discovery In this approach, an AR currently serving the MN identifies all CARs for the MN's handoff, at some point prior to handoff. This information is then immediately available at the time of handoff as input to the TAR Selection Algorithm. Another input 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 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 Trossen, Krishnamurthi, Chaskar, Kempf [Page 3]
INTERNET-DRAFT Candidate Access Router Discovery Issues Sept, 2001 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 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 in the box 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: The Anticipated CAR Discovery Problem 4.2 Dynamic CAR Discovery In this approach, an MN dynamically obtains information about the available ARs for handoff, along with their capabilities. When the MN detects an AR that has capabilities which match its preferences, the MN may notify the currently serving AR to perform a handoff to this AR using one or more of the seamless handoff protocols. The advantage of this technique is that the MN has fine-grained control over the TAR selection. However, this approach generates more radio traffic during the CAR discovery step. This is because, capability information is sent to the MN over the air. Also, it is Trossen, Krishnamurthi, Chaskar, Kempf [Page 4]
INTERNET-DRAFT Candidate Access Router Discovery Issues Sept, 2001 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 in the box in Figure 2. -------------------------------------------------------------- | | | GAARs identified by MN | | | | | | Capability identification by MN | | | | | v | | CARs for MN's handoff identified at MN | | | | ---------------------------|---------------------------------- | | TAR selection by MN at the | time of handoff v Unique TAR identity sent to current AR Figure 2: Dynamic CAR Discovery Problem 4.3 Hybrid CAR Discovery In practice, a hybrid of the above techniques for CAR discovery may be used. In the hybrid approach, the partitioning of capability information between the two techniques as well as the partitioning of TAR selection process between the MN and the current AR is possible. 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 Trossen, Krishnamurthi, Chaskar, Kempf [Page 5]
INTERNET-DRAFT Candidate Access Router Discovery Issues Sept, 2001 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 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 System A System B +----+ +----+ | BR |---> The Internet <---| BR | +----+ (aka Cyberspace) +----+ / \ / \ +----+ +----+ | IR | | IR | +----+ +----+ | | | | +----+ +----+ | AR | | AR | +----+ +----+ | | |___________________ ________________| | | | | ... | -- -- | ... | \/ \/ | | | |_______ ______| | | | | | -- -- | The Physical World | \/ \/ | (aka Geospace) | | |______ _______| | | -- -- -- \/ = AP \/ \/ Figure 3: GAAR Discovery Problem Trossen, Krishnamurthi, Chaskar, Kempf [Page 6]
INTERNET-DRAFT Candidate Access Router Discovery Issues Sept, 2001 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 consist of ARs that are GAARs of each other, but are heterogeneous in administrative control, functionality, link layer technology and resources. An MN that is attached to a given AR may have specific requirements as regards these parameters. For example, the MN may need some hardware or software support from the AR or need some 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. Trossen, Krishnamurthi, Chaskar, Kempf [Page 7]
INTERNET-DRAFT Candidate Access Router Discovery Issues Sept, 2001 In the Anticipated CAR Discovery, capability exchange between ARs occurs over the Internet. Thus, a protocol is needed that would allow ARs to exchange capability information. 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 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 CAR discovery may allow other nodes to learn the following pieces of information about an AR: - Physical location - Capabilities - State of capabilities. Malicious nodes may use this kind of information to launch attacks of the DoS-style and/or service hijacking. Therefore, the following topics should be covered in any protocol developed for CAR discovery: - Authentication of nodes - Security associations between nodes - Message/payload encryption. 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. Trossen, Krishnamurthi, Chaskar, Kempf [Page 8]
INTERNET-DRAFT Candidate Access Router Discovery Issues Sept, 2001 7. REFERENCES [1] IP Mobility Support, C. Perkins (Editor), RFC 2002, October 1996. [2] Mobility Support in IPv6, D. Johnson and C. Perkins, draft-ietf-mobileip-ipv6-13.txt, work in progress, November 2000. [3] Low Latency Handoffs in Mobile IPv4, MIPv4 Handoffs Design Team, draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, work in progress, February 2001. [4] Fast handoffs for Mobile IPv6, MIPv6 handoff Design Team, draft-ietf-mobileip-fast-mipv6-01.txt, work in progress, April 2001. [5] Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network, O. H. Levkowetz et. al., draft-ietf-seamoby-context-transfer-problem-stat-01.doc, work in progress, May 2001. [6] General requirements for a context transfer framework, H. Sayed et. al., draft-ietf-seamoby-ct-reqs-00.txt, work in progress, May 2001. [7] Buffer Management for Smooth handoffs in Mobile IPv6, G. Krishnamurthi, R. Chalmers, and C. Perkins, draft-krishnamurthi-mobileip-buffer6-01.txt, work in progress, March 2001. [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. Trossen, Krishnamurthi, Chaskar, Kempf [Page 9]
INTERNET-DRAFT Candidate Access Router Discovery Issues Sept, 2001 8. AUTHORS' ADDRESS Dirk Trossen Communication Systems Laboratory Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA Phone: +1 781 993 3605 Fax: +1 781 993 1907 E-mail: dirk.trossen@nokia.com Govind Krishnamurthi Communication Systems Laboratory Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA Phone: +1 781 993 3627 Fax: +1 781 993 1907 E-mail: govind.krishnamurthi@nokia.com Hemant Chaskar Communication Systems Laboratory Nokia Research Center 5 Wayside Road Burlington, MA 01803, USA Phone: +1 781 993 3785 Fax: +1 781 993 1907 E-mail: hemant.chaskar@nokia.com James Kempf Network and Security Research Center, Sun Labs Sun Microsystems, Inc. 15 Network Circle Menlo Park, CA 94025, USA Phone: +1 650 786 5890 Fax: +1 650 786 6445 E-mail: james.kempf@eng.sun.com Trossen, Krishnamurthi, Chaskar, Kempf [Page 10]
