Geopriv WG James Polk
Internet-Draft Allan Thomson
Expires: September 4, 2009 Marc Linsner
Intended Status: Standards Track (PS) Cisco Systems
March 4, 2009
Dynamic Host Configuration Protocol (DHCP) Location
Shapes Option for Geopriv for IPv4 and IPv6
draft-polk-geopriv-dhc-geoelement-shape-option-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. This document may contain
material from IETF Documents or IETF Contributions published or made
publicly available before November 10, 2008. The person(s)
controlling the copyright in some of this material may not have
granted the IETF Trust the right to allow modifications of such
material outside the IETF Standards Process. Without obtaining an
adequate license from the person(s) controlling the copyright in
such materials, this document may not be modified outside the IETF
Standards Process, and derivative works of it may not be created
outside the IETF Standards Process, except to format it for
publication as an RFC or to translate it into languages other than
English.
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 4, 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
Polk, et al. Expires September 4, 2009 [Page 1]
Internet-Draft DHCP Geoelement Shapes Option March 2009
rights and restrictions with respect to this document.
Legal
This documents and the information contained therein 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 THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Abstract
This document defines the Dynamic Host Configuration Protocol (DHCP)
Option for downloading a location shape to a client, from a server.
This is commonly called Location Configuration Information (LCI).
Servers that provide this information to a client are doing so by
communicating via a Location Configuration Protocol, or LCP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Format of the DHCP Geoelement Shapes Option . . . . . . . . .
2.1 DHC Option for Shapes Option in IPv4 . . . . . . . . . .
2.2 DHC Option for Shapes Option in IPv6 . . . . . . . . . .
3. Geo-element Format for both IPv4 and IPv6 . . . . . . . . . .
3.1 The Geoelement Shape for a 2D/3D Point . . . . . . . . .
3.2 The Geoelement Shape for a 2D/3D Circle . . . . . . . . .
3.3 The Geoelement Shape for a 2D/3D Polygon . . . . . . . .
3.4 Additional Optional Geotypes . . . . . . . . . . . . . .
4. Versioning this Option . . . . . . . . . . . . . . . . . . .
5. Recommendations for Converting this Option into a PIDF-LO . .
6. Security considerations . . . . . . . . . . . . . . . . . . .
7. IANA considerations . . . . . . . . . . . . . . . . . . . . .
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .
9. References . . . . . . . . . . . . . . . . . . . . . . . . .
9.1. Normative References . . . . . . . . . . . . . . . . .
9.2. Informative References . . . . . . . . . . . . . . . .
Authors' Addresses . . . . . . . . . . . . . . . . . . . . .
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 RFC 2119 [1].
Polk, et al. Expires September 4, 2009 [Page 2]
Internet-Draft DHCP Geoelement Shapes Option March 2009
1. Introduction
This document defines the Dynamic Host Configuration Protocol (DHCP)
Option [RFC2131] for downloading a location shape to a client, from
a server. This is commonly called Location Configuration
Information (LCI). Servers that provide this information to a
client are doing so by communicating via a Location Configuration
Protocol, or LCP.
The DHCP server is assumed to have determined the location from the
Circuit-ID Relay Agent Information Option (RAIO) defined (as SubOpt
1) in [RFC3046]. In order to translate the circuit (switch port
identifier) into a location, the DHCP server is assumed to have
access to a service that maps the from circuit-ID to the location at
which the circuit connected to that port terminates in the building,
for example, the location of the wall jack.
Further, the local administrator can have the knowledge that a
certain attachment point, for example, is connected to an IEEE
802.11 Access Point (AP). Understanding this about the attachment
point allows certain location characteristics to be gleaned from
this knowledge, such as, by itself, a wireless client can be within
100 meters of the location of the AP, therefore a precise location
may not be possible, but informing the client it is within a 100
meter circle of a given point would be more appropriate.
Another example would be if the local administrator has the ability
to triangulate the location of the client, and lay this information
onto a building map or grid, the local administrator can inform the
client that it is in a particular room, instead of giving the client
the exact coordinates for where it is at this time. This room would
most likely best be presented in the form of a polygon (i.e., many
sided and enclosed 2D or 3D container).
This document creates 3 different location shapes, as follows,
o a single point - articulated by X and Y coordinates;
o a circle - which takes the point X and Y coordinates and extends
a radius out from that spot;
o a polygon - which is a number of x/y coordinate points - greater
than 2 - that make up what OpenGIS defines as a Linear Ring
Ring [OpenGIS].
The use of the term "point" has been changed in GML from the version
3.0 specification to the 3.1 specification [OpenGIS]. A point
(GML3.0) became a "position" (GML3.1). For the remainder of this
document, we do not distinguish between the two terms. A reader of
this document needs to consider these two terms interchangeable
here.
Polk, et al. Expires September 4, 2009 [Page 3]
Internet-Draft DHCP Geoelement Shapes Option March 2009
In both GML3.0 and GML3.1 (and more recently GML3.2) - a point or
position is contained within the feature.xsd schema, which relates
directly to what the Presence Information Data Format - Location
Object (PIDF-LO), defined in RFC 4119 [RFC4119], mandates support
of, but that is all RFC 4119 requires support of as far as GML
schemas are concerned.
A circle is not defined within the feature.xsd schema, but rather
the geometryPrimitives.xsd schema in GML 3.1.1. If this Option were
used by implementers to place location information in a PIDF-LO,
additional support for the geometryPrimitives.xsd schema in GML
3.1.1 is necessary. Section 6 of this document is dedicated to give
guidance to implementers for just such a conversion from this DHCP
Option to a PIDF-LO.
A polygon is also not defined within the feature.xsd schema, and is
also defined in the geometryPrimitives.xsd schema in GML 3.1.1.
Therefore, just as converting a circle from this Option into a
PIDF-LO requires the geometryPrimitives.xsd schema, so too does a
polygon representation in a PIDF-LO.
Additional location shapes can be defined by extending this
Specification, and can require the geometryPrimitives.xsd schema be
implemented, or another GML schema.
This Option has limited applicability to certain environments, such
as cellular networks.
One shape defined in this document overlaps with [RFC3825], which
includes a mechanism for transporting a geo point. In support of
backward compatibility, this document leaves [RFC3825] alone.
Implementers will have the choice to use this new option or continue
to support [RFC3825]. By leaving [RFC3825] alone, implementations
based on [RFC3825] will not be affected by this new option.
2. Format of the DHCP Geoelement Shapes Option
2.1 Overall Format of Shapes Option in IPv4
This section defines this DHCP Option for use in IPv4. The first 4
bytes of this Option has the same format, regardless of the shape
contained in the Option. The fields that follow are where the
Option deviates based on the type of location shape being expressed
(i.e., a point, a circle or a polygon). Figure 1, below, shows the
first 4 bytes of each shape for IPv4. Each field is defined below
Figure 1 for any shape of this Option. The 4-bit shape field in
this Option will be detailed in section 3, describing each of the 3
shapes introduced by this document.
Polk, et al. Expires September 4, 2009 [Page 4]
Internet-Draft DHCP Geoelement Shapes Option March 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code XXX | Length=XX | Ver | Shape | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. Geoelements... ...
. (see section 3 for details) ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. IPv4 Fields for this Geo-element Option
Code XXX: The code for this DHCPv4 option (IANA assigned).
Length=XX: The length of this option, counted in bytes - not
counting the Code and Length bytes. This is a variable
length Option, therefore the length value will change
based on the shape within the Option.
Ver: (4 bits) The version of this Option. This will specify
version 1.
Shape: (4 bits) The Format of this location.
This value determines how the rest of the Option is
processed (i.e. what are the expected fields based on the
rules for each shape)
Initially defined in this document are shapes for a
point, a circle and a polygon. This is an extensible
field for additional shapes.
Reserved: (8 bits) reserved for future use.
Geoelements: see section 3 for details
The above defined v4 fields are all enumerated.
[Editor's Note: we're open to including a 4-bit "what" field
(in the manner in which it is used in RFC 4776);
but want to get feedback from the WG on this
prior to including it.]
2.2 Overall Format of Shapes Option in IPv6
The LCI format for IPv6 is as follows:
Polk, et al. Expires September 4, 2009 [Page 5]
Internet-Draft DHCP Geoelement Shapes Option March 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Shape | Reserved | .
+-------------------------------+ .
. Geo-elements... .
. (see section 3 for details) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. IPv6 fields of this Geo-element Option
option-code: The code for this DHCPv6 option (IANA assigned).
option-len: The length of this option, counted in bytes - not
counting the Code and Length bytes. This is a variable
length Option, therefore the length value will change
based on the shape within the Option.
Ver: See above (Section 2.1). This will specify version 1.
Shape: See above (Section 2.1).
Reserved: See above (Section 2.1).
Geoelements: see below (Section 3 for details).
The above defined v6 fields are all enumerated.
[Editor's Note: we're open to including a 4-bit "what" field
(in the manner in which it is used in RFC 4776);
but want to get feedback from the WG on this
prior to including it.]
3. Geo-element Format for both IPv4 and IPv6
The Geo-elements, in both DHCPv4 and DHCPv6, have the following
format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Geotype | Geolength | Geovalue ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Geo-element Format for both IPv4 and IPv6
Geotype: A one-byte identifier of the data location value.
Polk, et al. Expires September 4, 2009 [Page 6]
Internet-Draft DHCP Geoelement Shapes Option March 2009
Geolength: The length, in bytes, of the Geovalue, not including
the Geolength field itself, up to a maximum of 255
bytes.
Geovalue: The location shape value, as described in detail
below. The Geovalue is always in UTP-8.
The Geotypes this document defines (and IANA registers) for a point
are:
Geotype=1 X-coordinate - this necessitates there be a
Latitude Geovalue present.
Geotype=2 Y-coordinate - this necessitates there be a
Longitude Geovalue present.
Geotype=3 Z-coordinate - this necessitates there be an
Altitude Geovalue present.
Geotype=4 Unit of Measurement Altitude (UofMA) - this
necessitates there be an Altitude unit of measurement
Geovalue present.
The first byte of the Geovalue for Geotypes =1 and =2 MUST be a
plus '+' or minus '-' sign byte, indicating:
For Geotype=1 - whether the latitude is positive (above the
equator) or negative (below the equator).
For Geotype=2 - whether the longitude is positive (East of the
prime meridian of the datum used) or negative
(West of the prime meridian of the datum used).
This document defines (and IANA registers) 2 Altitude units of
measurement (Geotype=4).
Geotype=4, Geovalue=1 - meters above or below the datum 0 plane.
Geotype=4, Geovalue=2 - building floor.
When Geotype=4 (UofMA) has a Geovalue=2 (building floor), the
Geovalue for Geotype=3 (Z-coordinate) is alpha characters, meaning
there is no need to include a plus '+' or minus '-' sign byte (more
on this below table 2).
When Geotype=4 (UofMA) has a Geovalue=1 (meters), first byte of the
Geovalue=3 MUST be a plus '+' or minus '-' sign byte, indicating:
For Geotype=3 - whether the altitude Geovalue is positive (above
datum 0) or negative (below datum 0).
Polk, et al. Expires September 4, 2009 [Page 7]
Internet-Draft DHCP Geoelement Shapes Option March 2009
+---------+----------------------------------+---------+
| Geotype | Geoelement | PIDF-LO |
+---------+----------------------------------+---------+
| 1 | X-Coordinate (Latitude) | Sec 5.1 |
| | | |
| 2 | Y-Coordinate (Longitude) | Sec 5.1 |
| | | |
| 3 | Z-Coordinate (Altitude) | Sec 5.1 |
| | | |
| 4 | Unit of Measurement Altitude * | Sec 5.2 |
+---------+----------------------------------+---------+
Table 1. Geotypes for a Basic 3D Point
* For Geotype=4 (Unit of Measurement Altitude), the following table
applies:
+---------+--------------------------------------------------------+
| Geotype | Geovalue | Description |
+---------+--------------------------------------------------------+
| 4 | 1 | meters above or below the datum 0 plane |
| | | |
| 4 | 2 | building floor |
+---------+--------------------------------------------------------+
Table 2. Unit of Measurement for the Altitude value
The Unit of Measurement Altitude (UofMA) field in this Option will
define what is considered the 3-Dimensional 0 (zero) altitude. For
example, it could be the ground, Mean-lowest-Low-tide or
Mean-Tide level at a given X/Y coordinate.
The 'floor', Geovalue=2, SHOULD match the locally significant
description for identifying floors in a multi-floor building.
Values for this option would include '1' or '2' and could include
'basement' or 'mezzanine' or any other floor identifier determined
by local administration.
For example, for a Geotype=4 (UofMA), the Geovalue in Geotype=3
(Z-Coordinate) would be 'basement' or 'mezzanine', either spelled
out.
For any point, there MUST be a Geotype=1 (X-coordinate) and
Geotype=2 (Y-coordinate) present. Geotype=3 (Z-coordinate) and
Geotype=4 (UofMA) MUST be implemented to comply with this
specification, but are OPTIONAL to use for any given communication.
That said, if there is an altitude provide (Geotype=3), there MUST
be a (Geotype=4) present as well.
If the DHCP Option size becomes an issue (i.e., longer than 255
Polk, et al. Expires September 4, 2009 [Page 8]
Internet-Draft DHCP Geoelement Shapes Option March 2009
bytes), it is allowed to use the long Options capability created in
RFC 3396 [RFC3396] to solve for this.
New Geotypes and Geovalues MUST be defined in an RFC, following
expert review.
3.1 The Geoelement Shape for a 2D/3D Point
The elements defined in Section 3 define how to communicate a
point (shape=1). These additional rules need to be followed for a
point:
o There MUST NOT be more than one Geotype=3 (Z-coordinate) or
more than one Geotype=4 (UofMA) within this Option when
shape=1.
o These are the Geotypes that MUST be present for a 2D point within
this Option:
o Geotype=1 (X-Coordinate (Latitude))
o Geotype=2 (Y-Coordinate (Longitude))
o These are the Geotypes that MUST NOT be present for a 2D point
within this Option:
o Geotype=3 (Z-Coordinate (Altitude))
o Geotype=4 (Unit of Measurement Altitude)
o Geotype=5 (Radius)
o Geotype=6 (# of Points)
o Geotype=7 (Centerpoint X-Coordinate (Lat))
o Geotype=8 (Centerpoint Y-Coordinate (Long))
o Geotype=9 (Centerpoint Z-Coordinate (Alt))
o Geotype=10 (Centerpoint Unit of Measurement Altitude)
All other Geotypes are OPTIONAL, but MAY change in future
extension(s) to this document.
o These are the Geotypes that MUST be present for a 3D point within
this Option:
o Geotype=1 (X-Coordinate (Latitude))
o Geotype=2 (Y-Coordinate (Longitude))
o Geotype=3 (Z-Coordinate (Altitude))
o Geotype=4 (Unit of Measurement Altitude)
o These are the Geotypes that MUST NOT be present for a 3D point
within this Option:
o Geotype=5 (Radius)
o Geotype=6 (# of Points)
o Geotype=7 (Centerpoint X-Coordinate (Lat))
Polk, et al. Expires September 4, 2009 [Page 9]
Internet-Draft DHCP Geoelement Shapes Option March 2009
o Geotype=8 (Centerpoint Y-Coordinate (Long))
o Geotype=9 (Centerpoint Z-Coordinate (Alt))
o Geotype=10 (Centerpoint Unit of Measurement Altitude)
Geotypes=11 (Datum) and =12 (Valid-for) are OPTIONAL, but MAY change
in future extension(s) to this document.
3.2 The Geoelement Shape for a 2D/3D Circle
The elements defined in section 3.1 define how to communicate a
point (shape=1). The additional element needed to communicate a
circle (shape=2) is a radius Geotype. The a unit of measurement of
for the radius (UofMR) is always meters, therefore, there does not
need to be a separate value for this - having only one to choose
from.
Geotype=5 Radius - the straight line from the point at the
center of the circle, extending out a given distance
(this is the Geovalue of the Radius Geotype).
+---------+----------------------------------+---------+
| Geotype | Geoelement | PIDF-LO |
+---------+----------------------------------+---------+
| 5 | Radius | Sec 5.3 |
+---------+----------------------------------+---------+
Table 3. Required Radius Geoelement Information
When the Option communicates a circle (shape=2), the following
Geotype MUST be present in the Option:
Geotype=1 (the X-coordinate representing the center of the
circle)
Geotype=2 (the Y-coordinate representing the center of the
circle)
Geotype=5 (the Radius value from the center X/Y point of the
circle)
An altitude (Geotypes 3 & 4) coordinate is OPTIONAL, but both
Geotypes MUST appear in the Option if either appears for shape=2 (a
circle).
Geotypes=7 through =10, which detail a Centerpoint (see Section 3.3
below) MUST NOT appear in a shape=2 (circle) Option. There is
already an implicit centerpoint of the circle, and that is the one
X/Y point in the Option.
The following additional rules need to be followed for a circle:
o There MUST NOT be more than one Geotype=3 (Z-coordinate) or
Polk, et al. Expires September 4, 2009 [Page 10]
Internet-Draft DHCP Geoelement Shapes Option March 2009
more than one Geotype=4 (UofMA) within this Option when
shape=2.
o These are the Geotypes that MUST be present for a 2D circle
within this Option:
o Geotype=1 (X-Coordinate (Latitude))
o Geotype=2 (Y-Coordinate (Longitude))
o Geotype=5 (Radius)
o These are the Geotypes that MUST NOT be present for a 2D circle
within this Option:
o Geotype=3 (Z-Coordinate (Altitude))
o Geotype=4 (Unit of Measurement Altitude)
o Geotype=6 (# of Points)
o Geotype=7 (Centerpoint X-Coordinate (Lat))
o Geotype=8 (Centerpoint Y-Coordinate (Long))
o Geotype=9 (Centerpoint Z-Coordinate (Alt))
o Geotype=10 (Centerpoint Unit of Measurement Altitude)
All other Geotypes are OPTIONAL, but MAY change in future
extension(s) to this document.
o These are the Geotypes that MUST be present for a 3D circle
within this Option:
o Geotype=1 (X-Coordinate (Latitude))
o Geotype=2 (Y-Coordinate (Longitude))
o Geotype=3 (Z-Coordinate (Altitude))
o Geotype=4 (Unit of Measurement Altitude)
o Geotype=5 (Radius)
o These are the Geotypes that MUST NOT be present for a 3D circle
within this Option:
o Geotype=6 (# of Points)
o Geotype=7 (Centerpoint X-Coordinate (Lat))
o Geotype=8 (Centerpoint Y-Coordinate (Long))
o Geotype=9 (Centerpoint Z-Coordinate (Alt))
o Geotype=10 (Centerpoint Unit of Measurement Altitude)
Geotypes=11 (Datum) and =12 (Valid-for) are OPTIONAL, but MAY change
in future extension(s) to this document.
3.3 The Geoelement Shape for a 2D/3D Polygon
The elements defined in this section define how to communicate a
polygon (shape=3). A polygon is a series of X/Y coordinate points,
or X/Y/Z coordinate groupings. There MUST be at least 4 points to
shape a polygon (which would result in a triangle), to be consistent
Polk, et al. Expires September 4, 2009 [Page 11]
Internet-Draft DHCP Geoelement Shapes Option March 2009
with the GML 3.1 specification [OpenGIS]. A minimum of 4 Points
make up a polygon in GML because the first and last point in a
polygon are the same, i.e., the first point is repeated to indicate
the representation has completed (or circled). There can be more
points included in the polygon.
There is one additional Geo-element that MUST be present in shape=3
(polygon) of this Option, and that is an indication of the number of
points in the polygon. Geotypes=1 and =2 create an X/Y
point.
Geotype=6 # of Points - each point, in 2D, is a point of X and
Y coordinates.
If a 3rd dimension exists for a point, Geotype=3 (the Z-coordinate)
is added to Geotype=1 and =2.
+---------+----------------------------------+---------+
| Geotype | Geoelement | PIDF-LO |
+---------+----------------------------------+---------+
| 6 | # of Points | N/A |
+---------+----------------------------------+---------+
Table 4. Required Number of Points within "this" Polygon
For shape=3 (polygon), the Geotype=6 MUST be the first element in
the Option -- as this will indicate how many points
(respectively) there are in the Option; thus giving the remaining
length of the Option from a number of Geo-elements point of view.
When this Option indicates it contains a polygon (shape=3),
coordinate points or 3D combinations (X, Y and Z coordinates
describing a 3D point) MUST have a specific order or grouping of
Geotype elements. The order is this:
For 2D points, this Option MUST have this point order:
Geotype=6, Geotype=1, Geotype=2, Geotype=1, Geotype=2, Geotype=1,
Geotype=2, etc...
for however many coordinate points are in the polygon. In other
words, the "# of Points" indicator is indicated first, followed by
at least 3 sets of points:
(# of Points), (x/y), (x/y), (x/y) (more if there are more 2D
points in the polygon)
For 3D Points, this Option MUST have this point order:
Geotype=6, Geotype=1, Geotype=2, Geotype=3, Geotype=4,
Geotype=1, Geotype=2, etc ...
Polk, et al. Expires September 4, 2009 [Page 12]
Internet-Draft DHCP Geoelement Shapes Option March 2009
for however many coordinate points are in the polygon. In other
words, the "# of Points" is indicated first, followed by at least 3
sets of points:
(# of Points), (x/y/z), (x/y/z), (x/y/z) (more if there are
more 3D points in the polygon)
This Option does not repeat the first and last points as GML
mandates for a Linear Ring representation of a polygon in XML. That
function is part of the conversion from this Option to a PIDF-LO,
which is described in section 5 of this document. Thus, is not part
of DHCP operation/communication.
Any polygon can contain an OPTIONAL Centerpoint Geo-element, which
is identified by the following Geotypes:
Geotype=7 Polygon Centerpoint X-Coordinate - server calculated
center point X-Coordinate within a supplied polygon.
Geotype=8 Polygon Centerpoint Y-Coordinate - server calculated
center point X-Coordinate within a supplied polygon.
Geotype=9 Polygon Centerpoint Z-Coordinate - server calculated
center point X-Coordinate within a supplied polygon.
Geotype=10 Polygon Centerpoint Unit of Measurement Altitude -
this is the same as the (UofMA) for Geotype=4 (from
section 3.1).
The DHCP server, or an application on another server, calculates
this point (in 2D or 3D), and provides this via this Option to the
client. The client does not perform this calculation or formatting
of this centerpoint information other than to pass it on whenever it
wants. The Location Recipient MUST NOT assume the Location Target is
at the centerpoint. This information can be used by applications -
making it valuable in some situations.
Geotypes=7 through =10 MUST NOT appear in a shape=2 (circle) Option.
There is already an implicit centerpoint of the circle, and that is
the one X/Y(/Z) point provided to the client in the Option.
+---------+----------------------------------+---------+
| Geotype | Geoelement | PIDF-LO |
+---------+----------------------------------+---------+
| | | |
| 7 | Centerpoint X-Coordinate (Lat) | Sec 5.5 |
| | | |
| 8 | Centerpoint Y-Coordinate (Long) | Sec 5.5 |
| | | |
| 9 | Centerpoint Z-Coordinate (Alt) | Sec 5.5 |
| | | |
Polk, et al. Expires September 4, 2009 [Page 13]
Internet-Draft DHCP Geoelement Shapes Option March 2009
| 10 | Centerpoint Unit of Measurement | Sec 5.6 |
| | Altitude | |
+---------+----------------------------------+---------+
Table 5. Centerpoint Geotypes
If there is a centerpoint contained in the Option (of a polygon), it
has its own order of Geotypes, which is as follows:
Geotype=7, Geotype=8, Geotype=9, Geotype=10
There are no additional Geotypes involved with centerpoint. So this
looks like the following:
center-x, center-y (and optionally) center-z, center-UofMA
This order above MUST NOT be altered, and MUST be the last 2D or 3D
point of (shape=3) polygon Geo-elements. It is its own separate
point.
There MUST NOT be more than 1 altitude Geotype within this Option,
unless each coordinate point in the polygon is a 3D point. In other
words, if there is an altitude (Geotype=3) -- the rule is every
point is in 3D, or only one of them is in 3D. If none of points are
in 3D, then the centerpoint can have the only altitude (Geotype=3).
If one of the polygon points is in 3D, the centerpoint MUST NOT have
an altitude (Geotype=3).
It is RECOMMENDED that if there is a centerpoint within this Option,
the centerpoint is the one point that includes the altitude for the
Option.
[EDITOR'S NOTE: do we want to allow both 2D & 3D points in the
same polygon? Right now, the answer is "not
allowed" - because this would make everything
much more complicated.]
The following additional rules need to be followed for a polygon:
o There MUST NOT be more than one Geotype=3 (Z-coordinate) or
more than one Geotype=4 (UofMA) within this Option when
shape=3.
o If the Centerpoint does not include altitude (Geotype=3), or if
there is no Centerpoint, and one point of a polygon is defined as
3D - it is REQUIRED (with one exception) the remaining points are
defined as 2D, it is assumed the remaining points are at the same
altitude as the point that has the altitude (Geotype=3) for that
Option.
The exception to the above rule is when all points include altitude
Polk, et al. Expires September 4, 2009 [Page 14]
Internet-Draft DHCP Geoelement Shapes Option March 2009
(Geotype=3). In other words, it is an 'only one has it (altitude),
or they all have it' rule.
o These are the Geotypes that MUST be present for a 2D polygon
within this Option:
o Geotype=1 (X-Coordinate (Latitude))
o Geotype=2 (Y-Coordinate (Longitude))
o Geotype=6 (# of Points)
The shape=3 (polygon) Option MUST contain at least 3 points to be a
Polygon in this Option (conversion from this Option to a PIDF-LO is
done by the client, and is described in section 5 of this document).
See earlier in this section for the order rules around more than
one Geotype=1 and =2 (and the centerpoint, if present).
o These are the Geotypes that are OPTIONAL for a 2D polygon
within this Option:
o Geotype=7 (Centerpoint X-Coordinate (Lat))
o Geotype=8 (Centerpoint Y-Coordinate (Long))
o These are the Geotypes that MUST NOT be present for a 2D polygon
within this Option:
o Geotype=3 (Z-Coordinate (Altitude))
o Geotype=4 (Unit of Measurement Altitude)
o Geotype=5 (Radius)
o Geotype=9 (Centerpoint Z-Coordinate (Alt))
o Geotype=10 (Centerpoint Unit of Measurement Altitude)
All other Geotypes are OPTIONAL, but MAY change in future
extension(s) to this document.
o These are the Geotypes that MUST be present for a 3D polygon
within this Option:
o Geotype=1 (X-Coordinate (Latitude))
o Geotype=2 (Y-Coordinate (Longitude))
o Geotype=6 (# of Points)
plus either of these two sets:
o Geotype=3 (Z-Coordinate (Altitude))
o Geotype=4 (Unit of Measurement Altitude)
or
o Geotype=9 (Centerpoint Z-Coordinate (Alt))
o Geotype=10 (Centerpoint Unit of Measurement Altitude)
Each UofMA Geotype (=4 and =10) MUST be the same Geovalue,
Polk, et al. Expires September 4, 2009 [Page 15]
Internet-Draft DHCP Geoelement Shapes Option March 2009
regardless of how many altitudes are in the Option for shape=3
(polygon).
Geotype=9 and =10 MUST NOT be present without the corresponding
Geotypes=7 and =8.
To reduce complexity, it is RECOMMENDED that all altitudes - when
all points are in 3D - be the same value (i.e., parallel to the
ground).
The shape=3 (polygon) Option MUST contain at least 3 points to be a
polygon. See earlier in this section for the order rules around
more than one Geotype=1, =2 and =3 point set.
o These are the Geotypes that are OPTIONAL for a 2D polygon
within this Option:
o Geotype=3 (Z-Coordinate (Altitude))
o Geotype=4 (Unit of Measurement Altitude)
o Geotype=7 (Centerpoint X-Coordinate (Lat))
o Geotype=8 (Centerpoint Y-Coordinate (Long))
o Geotype=9 (Centerpoint Z-Coordinate (Alt))
o Geotype=10 (Centerpoint Unit of Measurement Altitude)
o This Geotype MUST NOT be present for a 3D polygon within this
Option:
o Geotype=5 (Radius)
Geotypes=11 (Datum) and =12 (Valid-for) are OPTIONAL in either a 2D
or 3D polygon, but MAY change in future extension(s) to this
document.
3.4 Additional Optional Geotypes
The following Geotypes are OPTIONAL:
Geotype=11 Datum - the base line of reference from which
measurements are taken out from (here both horizontally
and vertically).
When not present, WGS84 2D or 3D (EPSG 4326 and 4979 respectively)
MUST be assumed. This Geotype indicates another Datum is assigned
to all coordinate Geotypes in Option (meaning each X-coordinate,
Y-coordinate, Z-coordinate, including Centerpoint coordinates). The
WGS84 datum can be made explicit, but including this Geotype=11,
Geovalue=1; two other datum combinations are included here.
This document establishes the following alternate (to WGS84) datums:
Polk, et al. Expires September 4, 2009 [Page 16]
Internet-Draft DHCP Geoelement Shapes Option March 2009
Datum = 1 denotes WGS84 (EPSG4326) for 2D, and (EPSG4979) for 3D
(depending on whether an altitude Geotype is present).
Datum = 2 denotes the horizontal datum NAD83 as defined by the EPSG
as their CRS Code 4269; North American Vertical Datum of
1988 (NAVD88) is the associated vertical datum for NAD83
Datum = 3 denotes the vertical datum NAD83 as defined by the EPSG as
their CRS Code 4269; Mean Lower Low Water (MLLW) is the
associated vertical datum for NAD83
Each of the above is IANA registered.
Geotype=12 Valid-for - measured in seconds the location within this
Option is to be considered good, before needing a
refresh, which maps to PIDF.
If Valid-for is not present, the Geoelement shape Option is valid
until the whole Option lease has expired.
This timer MUST start when the Option is received by the Client.
+---------+----------------------------------+---------+
| Geotype | Geoelement | PIDF-LO |
+---------+----------------------------------+---------+
| | | |
| 11 | Datum | Sec 5.7 |
| | | |
| 12 | Valid-for | Sec 5.8 |
+---------+----------------------------------+---------+
Table 6. List of Additional non-grouped Geotypes
Geotypes 14 - 255 are reserved.
NOTE: the authors are open to including both the Confidence and/or
Uncertainty Geotypes if the WG can reasonably provide valid
use-cases, as well as industry accepted definitions.
Currently, the US Federal Communications Commission (FCC), as
one source, is ambiguous about either of these fields,
including lacking a good definition for either.
4. Versioning this Option
It is RECOMMENDED that new shapes (until this Option exceeds 16) not
necessitate a new version of this Option. A new version SHOULD only
be necessary if one of the shapes requires a change in the format of
the fields within the Option. If one or more shapes need altering,
the remaining shapes SHOULD carry forward into the new version of
this Option. This ensures backwards compatibility with as large an
Polk, et al. Expires September 4, 2009 [Page 17]
Internet-Draft DHCP Geoelement Shapes Option March 2009
installed base as possible.
5. Recommendations for Converting this Option into a PIDF-LO
The following table is how this DHCP Geoelement shapes Option maps
into a PIDF-LO. Currently, not every Geoelement maps properly into
the PIDF-LO. Those mappings are for another effort.
5.1 X-, Y- and Z-Coordinate placement in the PIDF-LO
The following 2D XML element is where the X-, Y-coordinates go into
the PIDF-LO:
<gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>32 -86</gml:pos>
</gml:Point>
</gp:location-info>
The following 3D XML element is where the X-, Y-, Z-coordinates go
into the PIDF-LO:
<gp:location-info>
<gml:Point srsName="urn:ogc:def:crs:EPSG::4979">
<gml:pos>32 -86 10</gml:pos>
</gml:Point>
</gp:location-info>
5.2 Unit of Measurement Altitude (UofMA) in the PIDF-LO
GML expects altitude (Geotype=3) to be in meters only. This is not
possible today because the need express altitude in floors. This
results in the following ways of expressing the Z-coordinate
(altitude):
- if Z-coordinate (Geotype=3) is given in floors (Geotype=4,
Geovalue=3), the client determines that the PIDF-LO needs place
the altitude value into the <cl:FLR> element.
- if Z-coordinate (Geotype=3) is given in meters (Geotype=4,
Geovalue=1), the client has two options:
Choice#1 - placing the altitude value into the same <gml:pos>
element that Lat and Long go;
Choice#2 - shown this way
Polk, et al. Expires September 4, 2009 [Page 18]
Internet-Draft DHCP Geoelement Shapes Option March 2009
</gp:location-info>
<gs:height uom="urn:ogc:def:uom:EPSG::9001">
15
</gs:height>
</gp:location-info>
[Editor's Note: if this solution is chosen, then one of the two
Choices above for altitude placement needs to be
mandatory to implement, with the other being
optional.]
5.3 A Circle expressed within the PIDF-LO
The Shape=2 part of this DHCP Option is shown at the beginning of
the XML as <gml: Circle ...>. The schema for a circle is defined in
[GeoShape].
The following is where Geotype=5 fits into the PIDF-LO, as described
in the GML3.1 specification here [OpenGIS]:
<gml:Circle srsName="urn:ogc:def:crs:EPSG::4326"
xmlns:gml="http://www.opengis.net/gml">
<gp:location-info>
<gs:Circle srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>32.51 -86.51</gml:pos>
<gs:radius uom="urn:ogc:def:uom:EPSG::9001">
33
</gs:radius>
</gs:Circle>
</gp:location-info>
5.4 A Polygon placement within a PIDF-LO
The Shape=3 part of this DHCP Option is shown at the beginning of
the XML as <gml: polygon ...>. As stated earlier, a polygon has to
have at least 4 linear ring points within it. Also stated earlier,
if there is a 3rd dimension, there can only be one altitude value,
or every point has to have the same altitude value. This is to
reduce complexity.
The XML for a circle is defined in [GeoShape].
Polk, et al. Expires September 4, 2009 [Page 19]
Internet-Draft DHCP Geoelement Shapes Option March 2009
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326"
xmlns:gml="http://www.opengis.net/gml">
<gp:location-info>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:posList>
<gml:pos>32.51 -86.51</gml:pos> <!--A-->
<gml:pos>32.56 -86.56</gml:pos> <!--B-->
<gml:pos>32.56 -86.61</gml:pos> <!--C-->
<gml:pos>32.51 -86.66</gml:pos> <!--D-->
<gml:pos>32.46 -86.61</gml:pos> <!--E-->
<gml:pos>32.46 -86.56</gml:pos> <!--F-->
<gml:pos>32.51 -86.51</gml:pos> <!--A-->
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gp:location-info>
5.5 Centerpoint X-, Y- and Z-Coordinate placement in the PIDF-LO
TBD
GML does not specify XML for a centerpoint of a polygon.
5.6 Centerpoint Unit of Measurement Altitude (CUofMA) placement in the
PIDF-LO
TBD
GML does not specify XML for a centerpoint of a polygon.
5.7 Datum placement in the PIDF-LO
At issue here is that GML specifically assumes WGS84 2D or 3D to be
the datum, therefore a datum element is not present for the PIDF-LO.
For points, circles and polygons using the WGS84 datum, each
accomplishes this identification with the use of
srsName="urn:ogc:def:crs:EPSG::4326" for 2D representations, and
srsName="urn:ogc:def:crs:EPSG::4979" for 3D representations.
Unfortunately, WGS84 is a goal for many (all?) systems; one in which
some have not achieved yet. Some systems believe it might be
decades before they are converted over to the WGS84 datum.
Polk, et al. Expires September 4, 2009 [Page 20]
Internet-Draft DHCP Geoelement Shapes Option March 2009
For a 2D or 3D non-WGS84 datum, this is the XML schema from
[OpenGIS]:
<element name="GeographicCRS" type="gml:GeographicCRSType"
substitutionGroup="gml:_CoordinateReferenceSystem"/>
<complexType name="GeographicCRSType">
<complexContent>
<extension base="gml:AbstractCoordinateReferenceSystemType">
<sequence>
<element ref="gml:usesEllipsoidalCS"/>
<element ref="gml:usesGeodeticDatum"/>
</sequence>
</extension>
</complexContent>
</complexType>
For 1D Vertical only coordinate reference system utilized for
heights and depths, where WGS84 2D is used horizontally, the
following schema from [OpenGIS] is this:
<element name="VerticalCRS" type="gml:VerticalCRSType"
substitutionGroup="gml:_CoordinateReferenceSystem"/>
<complexType name="VerticalCRSType">
<complexContent>
<extension base="gml:AbstractCoordinateReferenceSystemType">
<sequence>
<element ref="gml:usesVerticalCS"/>
<element ref="gml:usesVerticalDatum"/>
</sequence>
</extension>
</complexContent>
</complexType>
5.8 Valid-for placement in the PIDF-LO
TBD
(this is likely part of the PIDF specification)
6. Security considerations
There are no additional security considerations in addition to those
contained within RFC 4776.
7. IANA considerations
This IANA registers the following fields introduced by this Option.
Polk, et al. Expires September 4, 2009 [Page 21]
Internet-Draft DHCP Geoelement Shapes Option March 2009
7.1 The IPv4 Option number for this Option
This document IANA registers this IPv4 Option number XXX (to be
assigned by IANA once this document becomes an RFC).
7.2 The IPv6 Option-Code for this Option
This document IANA registers this IPv6 Option-Code XXX (to be
assigned by IANA once this document becomes an RFC).
7.3 The Version number for this Option
This document IANA registers the version number 1 of this Option.
7.4 The Shape Designation for this Option
This document IANA registers the following shapes for this Option
+---------+--------------------------------------------------+
| Shape | Description |
+---------+--------------------------------------------------+
| 1 | a 2D or 3D point |
| | |
| 2 | a 2D or 3D circle |
| | |
| 3 | a 2D or 3D polygon, optionally with a centerpoint|
| | |
+---------+--------------------------------------------------+
Additions, modifications or deletions to the above table require
expert review, followed by a published RFC.
7.5 The Geotypes for this Option
This document IANA registers the following Geotypes for use with
this Option:
+---------+--------------------------------------------+-----------+
| Geotype | Geoelement | Reference |
+---------+--------------------------------------------+-----------+
| 1 | X-Coordinate (Latitude) | RFC XXXX* |
| | | |
| 2 | Y-Coordinate (Longitude) | RFC XXXX* |
| | | |
| 3 | Z-Coordinate (Altitude) | RFC XXXX* |
| | | |
| 4 | Unit of Measurement Altitude ** | RFC XXXX* |
Polk, et al. Expires September 4, 2009 [Page 22]
Internet-Draft DHCP Geoelement Shapes Option March 2009
| | | |
| 5 | Radius | RFC XXXX* |
| | | |
| 6 | # of Points | RFC XXXX* |
| | | |
| 7 | Centerpoint X-Coordinate (Lat) | RFC XXXX* |
| | | |
| 8 | Centerpoint Y-Coordinate (Long) | RFC XXXX* |
| | | |
| 9 | Centerpoint Z-Coordinate (Alt) | RFC XXXX* |
| | | |
| 10 | Centerpoint Unit of Measurement | RFC XXXX* |
| | Altitude ** | |
| | | |
| 11 | Datum | RFC XXXX* |
| | | |
| 12 | Valid-for | RFC XXXX* |
+---------+--------------------------------------------+-----------+
* RFC-Editor -- where "RFC XXXX" appears, please replace this string
with the RFC number assigned to this document, if and when it is
published as an RFC.
** Both Units of Measurement for Altitude are IANA registered in
section 6.2.
Geotypes 14 - 255 are reserved for future assignment.
Additions, modifications or deletions to the above table require
expert review, followed by a published RFC.
7.6 The Unit of Measurement for Altitude
This document IANA registers the following Unit of Measurement for
Altitude. For Geotype=4 (UofMA) and Geotype=10 (Centerpoint UofMA),
the following IANA registrations are necessary, and identical for
either Geotype:
+---------+----------+---------------------------------------------+
| Geotype | Geovalue | Description |
+---------+----------+---------------------------------------------+
| 4 | 1 | meters above or below the datum 0 plane |
| | | |
| 4 | 2 | floors - defined by local administration |
| | | |
+---------+----------+---------------------------------------------+
Additions, modifications or deletions to the above table require
expert review, followed by a published RFC.
Polk, et al. Expires September 4, 2009 [Page 23]
Internet-Draft DHCP Geoelement Shapes Option March 2009
7.7 Datums Registered by this Document
This document IANA registers the following Datums to be used by the
Geotype=11 (Datum). If no Geotype=11 is present in this Option, it
the default datum will be either EPSG-4326 for 2D, and EPSG-4979 for
3D.
Datum = 1 denotes WGS84 (EPSG4326) for 2D, and (EPSG4979) for 3D
(depending on whether an altitude Geotype is present).
Datum = 2 denotes the horizontal datum NAD83 as defined by the EPSG
as their CRS Code 4269; North American Vertical Datum of
1988 (NAVD88) is the associated vertical datum for NAD83
Datum = 3 denotes the vertical datum NAD83 as defined by the EPSG as
their CRS Code 4269; Mean Lower Low Water (MLLW) is the
associated vertical datum for NAD83
8. Acknowledgments
Your name here...
9. References
9.1 Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[OpenGIS] - http://www.opengeospatial.org/standards/gml
[RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005
[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
Configuration Protocol Option for Coordinate-based Location
Configuration Information", RFC 3825, July 2004
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[GeoShape] Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
Application Schema for use by the Internet Engineering
Task Force (IETF)", Candidate OpenGIS Implementation
Polk, et al. Expires September 4, 2009 [Page 24]
Internet-Draft DHCP Geoelement Shapes Option March 2009
Specification 06-142, Version: 0.0.9, December 2006.
9.2 Informative References
There are no Informational references at this time
Authors' Addresses
James Polk
3913 Treemont Circle
Colleyville, Texas, USA
+1.817.271.3552
mailto: jmpolk@cisco.com
Allan Thomson
Cisco Systems, Inc.
San Jose, California, USA
Email: althomso@cisco.com
Marc Linsner
Cisco Systems, Inc.
Marco Island, Florida, USA
Email: mlinsner@cisco.com
Polk, et al. Expires September 4, 2009 [Page 25]