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
<draft-tang-islf-req-00.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 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 <draft-tang-islf-req-00.txt> [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 <draft-tang-islf-req-00.txt> [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 <draft-tang-islf-req-00.txt> [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 <draft-tang-islf-req-00.txt> [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 <draft-tang-islf-req-00.txt> [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 <draft-tang-islf-req-00.txt> [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 <draft-tang-islf-req-00.txt> [Page 7]