INTERNET DRAFT H. Tang draft-tang-islf-req-00.txt J. Ruutu Expires: August 2000 J. Loughney Nokia Research Center February, 2000 Problems and Requirements of Some IP Applications Based on Spatial Location Information 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This Internet draft describes the basic problems that are needed to be solved for some IP applications based on spatial location information. The requirements on the system are also identified from these problems. Tang [Page 1] INTERNET DRAFT August, 2000 Contents 1. Introduction 2 1.1 Scope 2 1.2 Abbreviations 3 2. Problems 3 2.1 Trusted Location Data Exchange Between Two IP Devices 3 2.2 Locate Another IP Device Geographically 3 2.3 Locate IP Devices Geographically for Certain Resources 4 2.4 Publish IP Device Information Geographically 4 2.5 Send a Message to Certain IP Devices in a Geo-Region 4 3. Requirements on the System 4 3.1 Security 4 3.2 Location Request Routing 4 3.3 Location Based Messaging 5 3.4 Location Information Verification 5 3.5 Device Server Association 6 4. Discussion 6 5. Acknowledgements 7 6. Authors' Addresses 7 1. INTRODUCTION 1.1 Scope The current efforts dealing with the spatial location related tasks work with either a physical device on a layer-2 network (e.g., LCS of GSM, LPS of Bluetooth, etc.) or a position based service/application to a user (e.g., the envisioned services in W@P and web community). An open area of study is IP-centric or the networking issues that are related to spatial location and seem neglected so far. Given the nature of the current Internet; the large number of IP domains with possibly different operating policies; mix of layer-2 technologies; large number of applications with different requirements - an application related to spatial location information might not be scalable if its related networking problems are not solved. Another consideration is that the interested location information and associated devices/applications/services are not known to the involved end(s). It is unlikely that a few centralized servers could cope with the potentially highly dynamic and demanding nature of the location data exchange and update within the scope of the Internet, nor or is desirable. A distributed system of autonomously managed servers directly/indirectly connecting each other is thus a natural selection. An end point may thus have to go through the network of the servers in order to reach certain server that provides the actual requested information service. Tang [Page 2] INTERNET DRAFT August, 2000 This draft will consider the problems and their requirements on the system in order to support some IP applications based on spatial location information. It is outside the scope of this document to specify certain solutions for the determined problems. 1.2 Abbreviations DSA - Device Server Association ISLF - IP Spatial Location Forum ISLP - IP Spatial Location Protocol LBM - Location Based Messaging LCS - Location Services LIV - Location Information Verification LRR - Location Request Routing LPS - Local Positioning System WAP - Wireless Application Protocol 2. PROBLEMS There are five basic problems that need to be solved for some IP applications based on spatial location information. The problems are described in this chapter. 2.1 Trusted Location Data Exchange Between Two IP Devices Assume two IP devices want to exchange the actual geo-location information of one or both of the devices. However, one of the device may not trust the other or both of them do not trust each other on the truthfulness of the information if it is directly exchanged between them without certain proving party involved. In addition, one or both devices may not know themselves the geo-information such as the (x,y,z) or other geo-location expressions of their geo-location. If so, they need another trusted party or parties to supply the geo-location information of the device(s) first and then perform the mentioned exchange. 2.2 Locate Another IP Device Geographically Suppose an IP device (A) would like to geographically locate another IP device (B) in a particular geo-region for various reasons. What has been normally known to IP device A is the IP address or the other identifier of IP device B. There may be no further information on IP device B available to IP device A. IP device A will need to ask the help from another trusted party or parties. Tang [Page 3] INTERNET DRAFT August, 2000 2.3 Locate IP Devices Geographically for Certain Resources Assume an IP device want to know certain information (geo-location information, resources for services, etc.) of certain IP device(s) situated in certain geo-region or on the earth, because the IP device is interested in some of their resources for services. 2.4 Publish IP Device Information Geographically Suppose an IP device would like to publish its information (geo- location information, provided service(s), etc.) to a geo-region or the earth via certain IP device(s). Other IP devices in the geo-region or the world can then surely find the published IP device, not by depending on the searching engines but via a query to certain IP device or devices that know the published information directly or indirectly. 2.5 Send a Message to Certain IP Devices in a Geo-Region Assume an IP device would like to send a message to specific available IP devices in certain geo-location(s). However, the IP device does not know the geo-information and any other device-specific information of those IP devices to be targeted. The IP device thus needs a trusted party or parties to supply the information of those devices in order to send the message. Alternatively, the IP device may need a trusted party or parties to deliver the message to those IP devices for it, because the IP device is not allowed to know the information of those IP devices to be targeted. Note: (a) An IP device is a physical or virtual device with IP protocols. (b) A virtual IP device can be referenced via its hosting physical IP device. (c) An IP device can be a physically static or moving IP device. 3. REQUIREMENTS ON THE SYSTEM In order to solve the problems discussed in Chapter 2, there are five identified requirements on the system. While not mentioned directly in the following context, scalability is always a crucial requirement to the system. 3.1 Security Security is a crucial requirement on the system. Security components fall into the following four categories: (a) availability, (b) access, (c) integrity, and (d) confidentiality (privacy). Anonymity can be an alternative to protect the involved party or parties for certain situations, so that the possible high complexity or cost for using a security approach can be avoided. Security/anonymity requirements are usually affected by the use cases. We thus further discuss them with the following crucial requirements. 3.2 Location Request Routing Location request routing (LRR) is identified as a requirement for solving some of the basic problems. Suppose an IP device wants to Tang [Page 4] INTERNET DRAFT August, 2000 acquire the spatial location information of some IP devices that are beyond the knowledge scope of the servers known to the IP device. What can really help the device now is a scalable spatial location request routing approach to make the device really reaching the location servers that actually have the interested spatial location information. In order to forward a location information request from an IP device, an involved server should have a map of some or all other involved servers and server aggregations. The map is learned from the location information exchange among the servers and server aggregations. Here, a server aggregation is a group of servers that look as one server to the outside of the group. Therefore, for the location request routing, there are the following basic requirements further identified: (1) an approach for the location information exchange and update (2) an approach for the location request forwarding, (3) the location data format for exchanging (4) an approach of managing security/anonymity levels and rules required by the involved entities (the IP devices and the involved servers). 3.3 Location Based Messaging Location based messaging (LBM) is required for solving some of the basic problems. Assume an IP device like to send a message to certain available IP devices in certain spatial location(s). However, the IP device does not know the spatial positions and any other device- specific information of the targeted devices. What the IP device can do is (1) find all involved servers of the targeted unknown IP devices through the discussed location request routing (2) send the message through the involved servers or directly, based on the various policies required by the involved servers and the targeted devices. For sending a spatial location based message, an IP device has to find all involved servers of the targeted devices through LRR. The device can thus send the message through the involved location servers or directly. Therefore, LBM has the same further-identified requirements as LRR does. 3.4 Location Information Verification Location information verification (LIV) is necessary for solving some of the basic problems. Suppose an IP device would like to verify the given spatial location information of a targeted IP device. The IP device needs to issue a locating request, via the involved server over IP, to a server on the layer-2 network where the targeted IP device is actually attached. The verification can then be done by comparing the given spatial location information with the information from the layer-2 network. Tang [Page 5] INTERNET DRAFT August, 2000 There are four groups of further-identified requirements here: (1) the requirements of LRR when LRR is involved (2) the interface between an involved IP server and a location server on a layer-2 network (the interface should be able to serve as an interface between an involved IP server and various layer-2 networks) (3) an approach for mapping between the spatial location information from a layer-2 location server and that of an involved IP server (4) an approach to manage security/anonymity levels and rules associated with the interface mentioned above. 3.5 Device Server Association Device server association (DSA) is required for solving some of the basic problems. Assume an IP device has moved out of a spatial scope served by a server. The IP device thus needs to associate to a server in the new scope through contracting. What the device can do is to let it be located by or let the device itself report its spatial location information to the network attached. The network then sends the location information of the IP device to the server of the new scope (Note: the scopes can be overlapping). The IP device can thus contact to or be contacted by the server and then, the association is set up by contracting. In order to achieve the association of an IP device to an involved server, there are five requirement groups further identified: (1) an approach for an IP device to discover an involved server or for an involved server to locate an IP device that inside its geo-scope (2) an approach of contract negotiation between an IP device and an involved server (3) an approach to manage security/anonymity levels and rules associated with the IP device, the server, and their inter-operation (4) the requirements of LRR (5) the requirements of LIV if a layer-2 location server is involved for setting up the association. 4. DISCUSSION While this document considers only the problems that need to be solved and their requirements on the system, there are still some additional observations found in the study. (1) there seems no protocol or protocol combination that is available and can give a whole solution to the basic problems (2) there might be a need to develop an IP Spatial Location Protocol (ISLP) for the solution, while there can be other answers for the basic problems. Tang [Page 6] INTERNET DRAFT August, 2000 5. ACKNOWLEDGEMENTS The authors would like to thank all those people who have actively participated in the discussion of the mailing list at "http://www-nrc.nokia.com/ip-location". The authors are also grateful to all the folks with whom the authors have discussed concerning the location effort and the setup of the mailing list. 6. AUTHORS' ADDRESSES Haitao Tang Nokia Research Center It„merenkatu 11-13 FIN-00180, Helsinki, Finland email: haitao.tang@nokia.com Jussi Ruutu Nokia Research Center It„merenkatu 11-13 FIN-00180, Helsinki, Finland email: jussi.ruutu@nokia.com John Loughney Nokia Research Center It„merenkatu 11-13 FIN-00180, Helsinki, Finland email: john.loughney@nokia.com Please send comments to Haitao Tang, haitao.tang@nokia.com Expires August, 2000 Tang [Page 7]