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

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 August 21, 2008.

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
§  Intellectual Property and Copyright Statements

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 RFC3825 [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

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.