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