Aki Yokote Internet Draft Alper Yegin Document: draft-yokote-mobileip-api-00.txt Muhammad Tariq Expires: August 2002 Carl Williams Atsushi Takeshita February 2002 Mobile IP API 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 obsoleted 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. Abstract The Mobile IP API is an interface between the mobility management and the application layer. Using Mobile IP API, the applications can extract the mobility information that is already maintained by the mobility management module. API simply provides awareness of mobility for applications. This document describes application scenarios followed by requirements for Mobile IP API. Application scenarios are example applications that can take advantage of the mobility information. The requirements are intended to define the scope of a Mobile IP API and guide the design of API implementation. Expires August 2002 [Page 1] Internet Draft Mobile IP API February 2002 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1.0 Introduction..................................................2 2.0 Key Words.....................................................3 3.0 Usage Scenarios...............................................4 3.1 E-mail access scenario........................................4 3.2 Local service discovery.......................................5 3.3 Location based content delivery...............................5 4.0 Requirements..................................................6 4.1 Location awareness............................................6 4.2 Movement awareness............................................6 4.3 Use of API....................................................6 4.4 Scope of Mobile IP API........................................7 5.0 Security Considerations.......................................7 5.1 Location Privacy..............................................7 6.0 References....................................................7 7.0 Author's Addresses............................................7 8.0 Full Copyright Statement......................................8 1.0 Introduction The Mobile IP API is an interface between mobility management and application layer. See figure-1.0. MM in this figure indicates Mobility Management. +--------------+ | Application | |-/ \+---------| | |A|| | | |P|| TCP/UDP | | |I|| | |-\ /+---------| | MM | IP | |----+---------| | MAC | |--------------| | PHY | +--------------+ Figure-1.0 The basic functionality of the Mobile IP API is to simply enable applications to get mobility information about the host they are running on or other hosts they are communicating with. Using Mobile IP, mobility management (module) already has the mobility information. There is no need to generate any extra signaling Expires August 2002 [Page 2] Internet Draft Mobile IP API February 2002 between the MN and the CN, or change the functionality of current Mobile IP [3] [5] functions for the host to obtain mobility information. API at this stage can be called Basic Mobile IP API. Basic API deals with "reading mobility information". In addition, advanced Mobile IP API would be considered at a later stage. In order to meet the demands of sophisticated applications, advanced Mobile IP API would enable them to "control mobility". The advanced API would be discussed in a future revision of this document. Mobile IP has been designed to provide network layer mobility in a transparent manner and with use of Mobile IP it is understood that there is no need to let the application layer know about underlying mobility of mobile terminals. However, it does not mean that the application layer should not know about mobility of mobile terminal. It can be advantageous to pass mobility information from IP layer to applications. A mobility aware application can exploit such information in many different ways, and some of these are discussed in usage scenarios. Mobility information can be rephrased as awareness of MN's location and movement. Location awareness is about querying the current location of a mobile node, either home or away from home. Movement awareness is about getting notification of a mobile node's movement. Both location and movement awareness would happen on both mobile node and its correspondent nodes. A location of Mobile node refers to location in IP topology, not a geographic location. Mapping IP topological location to geographical location is outside the scope of this API. Mobile IP API does not generate any extra signaling between the MN and CN. The API only relies on receipt of Binding Update on the CN to provide information to the applications running on the CN. 2.0 Key Words The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Expires August 2002 [Page 3] Internet Draft Mobile IP API February 2002 3.0 Usage Scenarios This section describes the example application scenarios for basic Mobile IP API. The following scenarios apply to one of four classes of usage. (a) MN queries the its own location; (b) MN gets notification of its own movement, and new location; (c) CN queries the MN's location; and (d) CN gets notification of MN's movement, and new location Section 3.1 explains Email access service scenario which can apply to usage (a). Section 3.2 explains local service discovery scenario which can apply to usage (b). And section 3.3 explains news delivery service scenario which can apply to usage (d). 3.1 E-mail access scenario This section describes the E-mail access scenario. This is the case that the MN queries the its own location. +--------------+ +--------------+ | POP server | | MN | +--------------+ +--------------+ | MM-Layer Appl | | | | |Queries | | |location(1)| | |<----------| | |---------->| | Request choice of download option (2) | |<-------------------------------------------| | | | Message download without attachments (3) | |------------------------------------------->| | | Figure-3.1 When a user is roaming in a visited network, may need to pay a fee with higher rate than rate in home network. That makes user to avoid downloading large size of e-mail attachment files at visited network if those files are not needed right away. The user can get all files when gets back home. The E-mail access application on MN gets mobility information (MN's location) from mobility management, and then application initiates request which includes choice of download according to the detection of location. The mail server responds differently to different request. The messages will be downloaded with or without attachments from the server. For example, in the figure-3.1 below, API on MN queries MN's location to MM-layer (1), and the application initiates request downloading messages Expires August 2002 [Page 4] Internet Draft Mobile IP API February 2002 without attached files in this case (2). POP [4](mail) server responds and messages are downloaded without attachments. 3.2 Local service discovery This section describes the local service discovery scenario. This is the case that the MN gets notification of its own movement, and new location. The user would like to use the nearest printer. Usually when the user requests to access printer at visited area, need to access SLP [2] first and, learn the location of local printer. However, it is desirable the location of printer will be found automatically whenever MN moved to new area. For example, in the figure-3.2 below, when MN gets new CoA (1), application gets mobility information from mobility management (2), and then the application can initiate SLP lookup (3) and finds the nearest printer for MN in advance (4). Now, whenever user requests printing job at visited area (5), the application is already aware the address of local printer. +-------+ +-----+ +--------------+ |Printer| | SLP | | MN | +-------+ +-----+ +--------------+ | | MM-Layer Appl | | New CoA(1) | | | | --------->| (2) | | | |------->| | | SLP lookup (3)| | | |<------------------------------| | | Location of nearest printer(4)| | |------------------------------>| | | +--------+ | | |Refresh | | | |Cache of| | | |local | | | |printer | | | +--------+ | Printing job request (5) | |<-----------------------------------------| | | Figure 3.2 3.3 Location based content delivery This section describes the location based content delivery scenario. This is the case that a CN gets notification of MN's movement, and new location. The CN works as news contents server. The CN keeps track of MN's movement by receiving a binding update from MN. In the figure-3.3 Expires August 2002 [Page 5] Internet Draft Mobile IP API February 2002 below, every time CN gets a binding update form MN (1), application gets mobility information from mobility management on CN (2). Now, the application initiates to map the MN's IP address to geographic location (3), and the CN releases local news or advertisements to MN based on the geographic location (4). To do so, CN which acts as a news server, need to learn movement of MN and location. +--------------+ +--------------+ | CN | | MN | +--------------+ +--------------+ Appl MM-Layer MM-Layer Appl | | New CoA | | | | --------->| | | | Binding Update(1) | | | (2) |<--------------------------| | |<-----| | | +--------------+ | | | |Map new addr | | | | |to geographic | | | | |location (3) | | | | +--------------+ | | | | Send local news, ads (4) | |------------------------------------------>| | | Figure 3.3 4.0 Requirements This section describes the requirements of Mobile IP API. Identifying following requirements that will render to the API becomes essential in designing a widely accepted solution. 4.1 Location awareness Mobile IP API must enable applications to learn MN's location (i.e., whether the MN is at home, or it is away from home and has a CoA). These applications might be running on the MN itself, or a CN that this MN is corresponding with. 4.2 Movement awareness Mobile IP API must enable applications to get notified when MN changes location. These applications might be running on the MN itself, or a CN that this MN is corresponding with. 4.3 Use of API Basic Mobile IP API should be read-only function to avoid affects the operation of any other application on the device or same machine. Expires August 2002 [Page 6] Internet Draft Mobile IP API February 2002 4.4 Scope of Mobile IP API Basic Mobile IP API must be designed specific to Mobile IP, and not to generate new signaling or change functions of Mobile IP protocols. [3] [5] It should work for both Mobile IPv4 and Mobile IPv6. 5.0 Security Considerations 5.1 Location Privacy As previously stated, Mobile IP API does not generate extra signaling between the MN and the CN. For providing information to the applications running on the CN, the API only relies on receipt of Binding Updates on the CN. If the MN does not send a Binding Update for any reason including location privacy, this API will not provide any information to the applications running on the CN. As such, this API does not reveal any information other than what MN is willing to provide. 6.0 References [1] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location Protocol, Version 2". RFC 2608, June 1999. [3] D. Johnson and C. Perkins. Mobility Support in IPv6. draft- ietf-mobileip-ipv6-15.txt, April 2001. [4] J. Myers, M. Rose. "Post Office Protocol - Version 3". RFC 1939, May 1996. [5] C. Perkins, editor. IP Mobility Support. RFC 2002, October 1996. 7.0 Author's Addresses Aki Yokote DoCoMo Communications Laboratories USA, Inc. 181 Metro Drive, Suite 300 San Jose, CA 95110 Phone: +1 - 408-573-1050 (main) Fax: +1 - 408-573-1090 E-mail: yokote@docomolabs-usa.com Expires August 2002 [Page 7] Internet Draft Mobile IP API February 2002 Alper Yegin DoCoMo Communications Laboratories USA, Inc. E-mail: alper@docomolabs-usa.com Muhammad Mukarram Bin Tariq DoCoMo Communications Laboratories USA, Inc. E-mail: tariq@docomolabs-usa.com Carl Williams DoCoMo Communications Laboratories USA, Inc. E-mail: carlw@docomolabs-usa.com Atsushi Takeshita DoCoMo Communications Laboratories USA, Inc. E-mail: takeshita@docomolabs-usa.com 8.0 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires August 2002 [Page 8]