Location Services @ IETF72


An experiment in GEOPRIV and ECRIT technologies,

 in a network that's almost real

Once upon a time, the IETF started working groups to deal with geolocation and privacy (GEOPRIV) and with emergency calling (ECRIT).  Many years later, people started to implement the specifications produced by these working groups, and then prototype them.  This is the story of a test of GEOPRIV and ECRIT technologies done at the 72nd IETF, using the IETF network as the IP bearer and the source of location.

The GEOPRIV/ECRIT experiment at IETF 72 consists of a location information server and a set of location-based applications.  The LIS draws on the IETF network management infrastructure for location information, and distributes this information to clients over the GEOPRIV HELD protocol.


The Location Information Server

The LIS is running a customized version of the open-source HELD LIS, based on PHP and PostgreSQL. The main client interface to the LIS is via the HELD protocol: When the LIS receives a HELD request, it retrieves the location of the requestor (identified by its IP address) and returns it in a HELD response. The location returned is determined in two steps:

  1. Use a proprietary interface to the NetDisco network management system to determine the MAC address of the access point currently serving the requestor. This uses a custom application that uses SNMP to retrieve information from the wireless controller MIB.
  2. The LIS contains a database that includes the civic address of each access point in the IETF meeting network.  This database is populated manually. The demonstration page provides an interface that allows users to choose a room if the LIS is unable to find them. Only civic addresses are provided.

Support from the IETF network

The IETF network required two changes in order to allow the LIS to operate: A proprietary location query interface, and support for LIS discovery.

The location query interface (used in step 1 above) is an extension to the NetDisco network management system.  The requestor submits a request for an HTTP URI including an IP address, and NetDisco returns the MAC address of the AP to which the host with that IP address is connected.  This function is essentially another interface to an existing table of IP-to-MAC pairings that was already stored in NetDisco.

The IETF network supports all three discovery options from draft-ietf-geopriv-lis-discovery.  

  1. The HELD-specific DHCP (v4) option (which carries a LIS URI), is provided to hosts on request (i.e., in response to a DISCOVER).  Because IANA has not registered an option number for this option, it is provided with the private option number 224.  
  2. The DHCP server also provides a domain name for hosts, and a "LIS:HELD" NAPTR record has been added.  (However, the NAPTR record contains a typo that has been propagated from the draft, so it’s not overly useful)
  3. Reverse DNS queries for IP addresses on the IETF network correctly resolve to domain names that can be used for discovery.

Location By Reference

The LIS supports for location by reference based on the simple definition in HELD, as well as the more sophisticated contexts draft. At this stage, both held: URIs and pres: URIs are provided, but the held: URI is the only one that works.

No authentication is required for dereferencing URIs, even for the context-based references, so you can pass references around to your friends. This is known as the authorization by possession model. More information on that can be found in the HELD dereference draft.

You can get Firefox (version 3 only) to dereference for you by registering a protocol handler for HELD.

The Applications

Several groups of developers have created location-based applications that can be used by hosts that get their location from the LIS:

  • LIS Demonstration Page: Turns a browser into a HELD client using AJAX, and plots the client's location on a map.  (Martin Thomson, Andrew Co, and Richard Barnes, BBN)
  • GeoJabber: Retrieves location from a HELD LIS and posts it as presence for a Jabber account (as a text string). (Richard Barnes, BBN)
  • Zap! Emergency Calling Client & Krakow LoST Server: Uses LIS-provided location to route emergency calls in the ECRIT emergency calling framework. (Karl Heinz Wolf, NIC.AT, and a team from ITI Krakow)
  • University LoST Web Application: A Tomcat servlet that uses the HELD Identity Extensions to retrieve client location, then uses LoST to provide information on nearby services. (Milind Nimesh & Andrea Forte, Columbia University)
  • Command-line HELD client: A basic program to retreive location from the LIS.  Works on linux, in particular, on the Nokia N810 Internet tablet.  (Mayutan Arumaithurai, University of Göttingen)

LIS Demonstration Page

The LIS includes an AJAX application that displays the current position of the requestor of the page and give them an opportunity to update access point locations based on where they are.  JavaScript code in the demonstration page directs the client's browser to send a HELD query to the LIS (asking for civic location).  This request returns the user's location as a PIDF-LO, and makes it available as a JavaScript DOM object.  The browser pulls civic address information from this structure and plots it on a map of the IETF venue.

Also, since the LIS is manually provisioned (by users providing AP locations), the demo page offers users an interface for users to specify their location when location information is missing or incorrect. 

GeoJabber

GeoJabber is a simple Java application that posts the location of its host machine as the presence of a Jabber/XMPP account.  After logging into Jabber, it periodically sends a HELD query to the LIS, re-formats the location information from the PIDF-LO into a text string, and posts that text string as the status of the logged-in Jabber/XMPP account.  You can download GeoJabber here (note: this version will only work within the IETF72 network; the LIS URI is hard-wired).

Zap! Emergency Calling Client

Zap, the Mozilla SIP Client, with emergency call enhancement, participated as emergency calling client and as a simple PSAP in this experiment. Zap was able to configure location with the IETF meeting LIS and utilized a LoST Server to get available emergency services. The PSAP SIP URI just pointed to another computer running the Zap client and acting as a call taker. The emergency call was successfully initiated by dealing 112 (as configured by LoST) and caller location was automatically conveyed to the “PSAP”.  The following screenshots show the experimental emergency call:

Emergency Service Status of Zap: on the bottom the PIDF-LO document as generated by the IETF meeting LIS is shown and above all available emergency services are listed (in this case just 112 for the police service). 

Dialing 112 connects to the PSAP of the experimental setup and location information is conveyed automatically.

Zap alerts an incoming emergency call and shows Caller Location.

More information on Zap’s emergency call extension is available at http://ecrit.labs.nic.at

Columbia LoST Web Application

A group within the Internet Real Time lab at Columbia University have created a client and server for the Location-to-Service Translation (LoST) protocol.  In order to demonstrate their LoST implementation, they have created a Tomcat servlet that presents a web front-end to the LoST service.  To get location for an input to LoST, the web application uses the HELD Identity Extensions to retrieve location from the LIS on behalf of the user:

  <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
    <deviceIdentity xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
      <uri>ip:IPv4+164.100.52.200</uri>
    </deviceIdentity>
  </locationRequest>

Because the IP address of the Tomcat server has been added to a whitelist on the LIS, the LIS knows that the server is authorized to receive the user's location.  Once the servlet has the user's location, it presents the user a web form, and makes a LoST query with the user's location, as directed by this form.  This query is actually uses a set of extensions to LoST defined in draft-forte-ecrit-lost-extensions.  These extensions allow for queries that ask for the N nearest service providers, or providers up to D distance away.

N810 C HELD Client

We have developed a C-based HELD client and LoST client, and have ported it on the N810. This work is done to compliment the other existing implementations for ECRIT. In the near future, we plan to use this implementation along with a SIP client on the N810, to make emergency calls and extend it to finding Location based services using the LoST server. We also plan to release the implementation as open source soon enough. 

References