Specifying a Circular Uncertainty Area Using DHCP
draft-tschofenig-geopriv-dhcp-circle-01.txt

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

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.

This Internet-Draft will expire on September 8, 2009.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document specifies how a circular area representing the location of device can be returned using DHCP. The document also shows how the data returned from DHCP can be encoded into GML for using in a PIDF-LO in an unambiguous or contentious manner.

This document is a contribution to the ongoing discussion on RFC 3825; it represents one possible solution to address the discussed issues.

Table of Contents

1.  Introduction
2.  Terminology
3.  Details and Rationale
    3.1.  DHCPv4 Option for a Circular Location
    3.2.  DHCPv6 Option for a LIS Address
4.  Expressing the Circle in GML
5.  Security Considerations
6.  IANA Considerations
7.  Acknowledgements
8.  Normative References
§  Authors' Addresses

1.  Introduction

Location provided by GPS device and like generally provide location information as a point with a degree of uncertainty. This uncertainty is more often than not expressed as an offset in metres from the central point, with the resulting location being a circle when expressed in 2 dimensions, and a sphere when expressed in 3 dimensions. This memo presupposes that locations have been measured, for example using a GPS, ahead of time and have subsequently been stored in a wiremap database. Associations between end-devices and location can be done using DHCP option 82 or other methods where appropriate.

This document omits an altitude representation based on the envisioned usage scenario.

2.  Terminology

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

3.  Details and Rationale

The intent of this specification is to provide a location to an end-device so that it can easily represent it as circle in GML in accordance with PIDF-LO Profile [I‑D.ietf‑geopriv‑pdif‑lo‑profile] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations,” November 2008.). PIDF-LO Profile relies on geoshape [geoshape] (Thomson, M. and C. Reed, “GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF),” April 2007.) requires all coordinates to be specified using WGS-84, consequently the coordinates used in this memo are specified using WGS-84.

GML [gml] (Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, “Geographic information - Geography Markup Language (GML),” April 2004.) uses the ISO 19107 [ISO‑19107] (ISO, “Geographic information - Spatial Schema,” 5 2003.) definition of a point, and quotes this as being "0-dimensional geometric primitive, representing a position. NOTE The boundary of a point is the empty set." At some point however, it becomes necessary to express the coordinates that make up the location in bits and bytes. Since the intent is to use GML as the final representation, the encoding standards and limitations expressed by GML are used.

GML is an XML language [xml] (W3C, “XML Schema Part 2: Datatypes Second Edition,” October 2004.) for expressing location information, and XML defines mappings between its primative types and standard binary encodings. The GML point is made up of XML (xsd) doubles, and an XML double is expressed as an IEEE 754-1985 [IEEE‑754‑1985] (IEEE, “754-1985 IEEE Standard for Binary Floating-Point Arithmetic,” January 2003.) double-precision floating point number. This means that a latitude or longitude in GML is expressed as a 64 bit binary number, but in accordance with the previous definition is interpretted as being zero dimensional, without area.

The binary encodings provided in this memo express latitude and longitude values as 64 bit binary floating-point numbers, as defined in [IEEE‑754‑1985] (IEEE, “754-1985 IEEE Standard for Binary Floating-Point Arithmetic,” January 2003.). A radius is defined as a positive offset to this in metres, and is expressed as an unsigned 16 bit integer. This allows a circle with a radius in the order of 65.5km to be expressed without difficulty, and for a point with no specified uncertainty to be provided where the radius is set to zero.

3.1.  DHCPv4 Option for a Circular Location

This section defines a DHCP for IPv4 (DHCPv4) option for the point with radius of uncertainty.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  LOC-CIRCLE   |    Length     |         Latitude              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Latitude continued                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Latitude Continued       |         Longitude             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Longitude continued                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Longitude Continued      |           Radius              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LOC-CIRCLE:

The IANA assigned option number (TBD).

Length:

The length of this option octets (18).

Latitude:

8 octets representing the the latitude of the central point of a circle, expressed as an [IEEE‑754‑1985] (IEEE, “754-1985 IEEE Standard for Binary Floating-Point Arithmetic,” January 2003.) double.

Longitude:

8 octets representing the the longitude of the central point of a circle, expressed as an [IEEE‑754‑1985] (IEEE, “754-1985 IEEE Standard for Binary Floating-Point Arithmetic,” January 2003.) double.

Radius:

a 16 bit unsigned integer expressing the radius of the circle in metres.

3.2.  DHCPv6 Option for a LIS Address

This section defines a DHCP for IPv6 (DHCPv6) option for the point with radius of uncertainty. The DHCPv6 option for this parameter is similarly formatted to the DHCPv4 option.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         LOC-CIRCLE            |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Latitude                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Latitude continued                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Longitude                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Longitude continued                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Radius            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

LOC-CIRCLE:

The IANA assigned option number (TBD).

Length:

The length of this option in octets (18).

Latitude:

8 octets representing the the latitude of the central point of a circle, expressed as an [IEEE‑754‑1985] (IEEE, “754-1985 IEEE Standard for Binary Floating-Point Arithmetic,” January 2003.) double.

Longitude:

8 octets representing the the longitude of the central point of a circle, expressed as an [IEEE‑754‑1985] (IEEE, “754-1985 IEEE Standard for Binary Floating-Point Arithmetic,” January 2003.) double.

Radius:

a 16 bit unsigned integer expressing the radius of the circle in metres.

4.  Expressing the Circle in GML

PIDF-LO Profile [I‑D.ietf‑geopriv‑pdif‑lo‑profile] (Winterbottom, J., Thomson, M., and H. Tschofenig, “GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations,” November 2008.) describes how a circle is expressed in GML and included in a PIDF-LO [RFC4119] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.). The latitude and longitude components of this encoding form the central point of the circle.

       _d^^^^^^^^^b_
    .d''           ``b.
  .p'             /   `q.
 .d'    Radius-> /     `b.
.d'             /       `b.
::             /         ::
::           C           ::
::           ^           ::
`p.          |          .q'
 `p.      Centre      .q'
  `b.                .d'
    `q..          ..p'
      ^q.........p^

The XML for the resulting circle is shown in Figure 2 (Resulting XML and PIDF-LO) (assuming the centre is represented as 42.5463 -73.2512) and the radius is 5 meters.

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
 xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
 xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
 xmlns:gs="http://www.opengis.net/pidflo/1.0"
 xmlns:gml="http://www.opengis.net/gml"
   entity="pres:circle@example.com">
  <tuple id="sg89ab1">
    <status>
      <gp:geopriv>
        <gp:location-info>
          <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
               <gml:pos>
                  42.5463 -73.2512
               </gml:pos>
               <gml:radius uom="urn:ogc:def:uom:EPSG::9001">
                  5
               </gml:radius>
          </gs:Circle>
        </gp:location-info>
        <usage-rules/>
        <method>DHCP</method>
      </gp:geopriv>
    </status>
  </tuple>
</presence>

5.  Security Considerations

The security issues for this document are the same as for RFC 3825 [RFC3825] (Polk, J., Schnizlein, J., and M. Linsner, “Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information,” July 2004.).

6.  IANA Considerations

There are no specific IANA considerations for this document.

7.  Acknowledgements

The authors contribute this document to the ongoing discussion in the GEOPRIV working group. Still, the authors believe that it would be necessary to investigate the intended deployment use cases more in order to evaluate what additional location shapes are likely to be used and whether there is interest in using DHCP (or lower layer protocols developed by the IEEE or TIA) for conveying location information or whether there is more interest to use these protocols purely to discover a LIS and allow more flexibility with regard to the supported location shapes.

8. Normative References

Authors' Addresses