geopriv@ietf.org: Re: [Geopriv] [geopriv] #2: Add DHCPv6 option format

#2: Add DHCPv6 option format
--------------------------------+-------------------------------------------
Reporter: rbarnes@bbn.com | Owner: martin.thomson@andrew.com
Type: enhancement | Status: new
Priority: major | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version:
Severity: Active WG Document | Resolution:
Keywords: |
--------------------------------+-------------------------------------------

Comment(by bernard_aboba@hotmail.com):

Here is the current text of Section 2. Comments?

2. DHCP Option Format

This section defines the format for the DHCPv4 and DHCPv6 options.
These options use the same basic format, differing only in the option
code.

2.1. DHCPv6 Option

The DHCPv6 [RFC3315] option format is as follows:

Code: GEOCONF_GEODETIC (8 bits).

OptLen: Option Length (8 bits). This option is fixed size, the
value of this octet will always be 16.

LatUnc: Latitude Uncertainty (6 bits).

Latitude: Latitude (34 bits).

LongUnc: Longitude Uncertainty (6 bits).

Longitude: Longitude (34 bits).

AType: Altitude Type (4 bits).

AltUnc: Altitude Uncertainty (6 bits).

Altitude: Altitude (30 bits).

Datum: Datum (8 bits).

2.2. DHCPv4 Option

The DHCPv4 option format is as follows:

Code: 8 bits. The code for the DHCPv4 option (123).

Length: 8 bits. The length of the DHCPv4 option, in octets.
For versions 0 and 1, the option length is 16.

LatUnc: 6 bits. When the Ver field = 0, this field represents
Latitude resolution. When the Ver field = 1,
this field represents Latitude uncertainty.

Latitude: a 34 bit fixed point value consisting of 9 bits of integer
and 25 bits of fraction. Latitude SHOULD be normalized to
within +/- 90 degrees. Positive numbers are north of the
equator and negative numbers are south of the equator.

LongUnc: 6 bits. When the Ver field = 0, this field represents
Longitude resolution. When the Ver field = 1,
this field represents Longitude uncertainty.

Longitude: a 34 bit fixed point value consisting of 9 bits of integer
and 25 bits of fraction. Longitude SHOULD be normalized
to within +/- 180 degrees. Positive values are East of
the prime meridian and negative (2s complement) numbers
are West of the prime meridian.

AType: Altitude Type (4 bits).

AltUnc: 6 bits. When the Ver field = 0, this field represents
Altitude resolution. When the Ver field = 1,
this field represents Altitude Uncertainty.

Altitude: A 30 bit value defined by the AType field.

Ver: The Ver field is two bits, providing for four potential
versions. This specification defines the behavior of
version 0 (originally specified in [RFC3825]) as well as
version 1. The Ver field is always located at the same
offset from the beginning of the option, regardless of the
version in use.

Res: The Res field which is 3 bits, is reserved. These bits
have been used by [IEEE-802.11y], but are not defined within
this
specification.

Datum: 3 bits. The Map Datum used for the coordinates given in this
Option.

2.2.1. Version Support

2.2.1.1. Client Version Support

Clients implementing this specification MUST support receiving
responses of versions 0 and 1. Since this specification utilizes the
same DHCP option code as [RFC3825], the option format does not
provide a means for the client to indicate the highest version that
it supports to the server.

2.2.1.2. Server Version Selection

A DHCP server that provides location information cannot provide
options with both v0 and v1 formats in the same response. This is not
useful since receiving two copies of the same Option (either in the
same response or a separate response) causes a DHCP client to replace
the information in the old Option with the information in the new
Option.

A server uses configuration to determine which version to send in a
response. For example, where a mixture of v0 and v1 clients are
expected, the server could be configured to send v0 or v1 depending
on configuration (possibly making the choice based on information
such as the client MAC address). Where few v0 clients are expected,
the server could be configured to send only v1 responses.

Servers that opt to send location in v1 format are likely to cause
clients that support only v0 to reject the Option. This results in a
v0-only client not obtaining location information, with no ability to
indicate to the server that v1 was unsupported. Therefore, in
situations where some clients are known to support only v0, by
default the server SHOULD send a v0 response.

2.3. Latitude and Longitude Fields

The Latitude and Longitude values in this format are encoded as 34
bit, twos complement, fixed point values with 9 integer bits and 25
fractional bits. The exact meaning of these values is determined by
the datum; the description in this section applies to the datums
defined in this document.

New datums MUST define the way that the 34 bit values and the
respective 6 bit uncertainties are interpreted. This document uses
the same definition for all datums it specifies.

Latitude values MUST be constrained to the range from -90 to +90
degrees. Positive latitudes are north of the equator; negative
latitude are south of the equator.

Longitude values SHOULD be normalized to the range from -180 to +180
degrees. Values outside this range are normalized by adding or
subtracting 360 until they fall within this range. Positive
longitudes are east of the Prime Meridian (Greenwich); negative
longitudes are west of the Prime Meridian.

When encoding, latitude and longitude values are rounded to the
nearest 34-bit binary representation. This imprecision is considered
acceptable for the purposes to which this form is intended to be
applied and is ignored when decoding.

2.3.1. Latitude and Longitude Uncertainty

The latitude and longitude uncertainty fields are encoded as 6 bit,
unsigned integer values. These values quantify the amount of
uncertainty in each of the latitude and longitude values
respectively. A value of 0 is reserved to indicate that the
uncertainty is unknown; values greater than 34 are reserved.

A point within the region of uncertainty is selected to be the
encoded point; the centroid of the region is often an appropriate
choice. The value for uncertainty is taken as the distance from the
selected point to the furthest extreme of the region of uncertainty
on that axis.

The following figure shows a two-dimensional figure that is projected
to each axis. In the figure, "X" marks the point that is selected;
the ranges marked with "U" is the uncertainty.

___ ___________
^ | / |
| | / |
| | / |
U | / |
| | ( |
V | | |
--X | X |
| | `---------.
| | |
| | |
| | |
- `-------------------------'

|---------X---------------|
|<------U------>|

Uncertainty applies to each axis independently.

The amount of uncertainty can be determined from the encoding by
taking 2 to the power of 8, less the encoded value. As is shown in
the following formula, where "x" is the encoded integer value:

uncertainty = 2 ^ ( 8 - x )

The result of this formula is expressed in degrees of latitude or
longitude. The uncertainty is added to the base latitude or
longitude value to determine the maximum value in the uncertainty
range; similarly, the uncertainty is subtracted from the base value
to determine the minimum value. Note that because lines of longitude
converge at the poles, the actual distance represented by this
uncertainty changes with the distance from the equator.

If the maximum or minimum latitude values derived from applying
uncertainty are outside the range of -90 to +90, these values are
trimmed to within this range. If the maximum or minimum longitude
values derived from applying uncertainty are outside the range of
-180 to +180, then these values are normalized to this range by
adding or subtracting 360 as necessary.

The encoded value is determined by subtracting the next highest whole
integer value for the base 2 logarithm of uncertainty from 8. As is
shown by the following formula, where uncertainty is the midpoint of
the known range less the lower bound of that range:

x = 8 - ceil( log2( uncertainty ) )

Note that the result of encoding this value increases the range of
uncertainty to the next available power of two; subsequent repeated
encodings and decodings do not change the value. Only increasing
uncertainty means that the associated confidence does not have to
decrease.

2.4. Altitude

The altitude is expressed as a 30 bit, fixed point, twos complement
integer with 22 integer bits and 8 fractional bits. How the altitude
value is interpreted depends on the type of altitude and the selected
datum.

New altitude types and datums MUST define the way that the 30 bit
value and the associated 6 bit uncertainty are interpreted.

Three altitude types are defined in this document: unknown (0),
meters (1) and floors (2). Additional altitude types MUST be defined
in a Standards Track RFC.

2.4.1. No Known Altitude (AT = 0)

In some cases, the altitude of the location might not be known. An
altitude type of 0 indicates that the altitude is not known. In this
case, the altitude and altitude uncertainty fields can contain any
value and are ignored.

2.4.2. Altitude in Meters (AT = 1)

If the altitude type has a value of 1, the altitude is measured in
meters. The altitude is measured in relation to the zero set by the
vertical datum.

2.4.3. Altitude in Floors (AT = 2)

A value of 2 for altitude type indicates that the altitude value is
measured in floors. This value is relevant only in relation to a
building; the value is relative to the ground level of the building.
In this definition, numbering starts at ground level, which is floor
0 regardless of local convention.

Non-integer values can be used to represent intermediate or sub-
floors, such as mezzanine levels. For instance, a mezzanine between
floors 4 and 5 could be represented as 4.1.

2.4.4. Altitude Uncertainty

Altitude uncertainty uses the same form of expression as latitude and
longitude uncertainty. Like latitude and longitude, a value of 0 is
reserved to indicate that uncertainty is not known; values above 30
are also reserved. Altitude uncertainty only applies to altitude
type 1.

The amount of altitude uncertainty can be determined by the following
formula, where x is the encoded integer value:

uncertainty = 2 ^ ( 21 - x )

This value uses the same units as the associated altitude.

Similarly, a value for the encoded integer value can be derived by
the following formula:

x = 21 - ceil( log2( x ) )

2.5. Datum

The datum field determines how coordinates are organized and related
to the real world. Three datums are defined in this document, based
on the definitions in [OGP.Geodesy]:

1: WGS84 (Latitude, Longitude, Altitude):
The World Geodesic System 1984 [WGS84] coordinate reference
system.

This datum is identified by the European Petroleum Survey Group
(EPSG)/International Association of Oil & Gas Producers (OGP) with
the code 4979, or by the URN "urn:ogc:def:crs:EPSG::4979".
Without altitude, this datum is identified by the EPSG/OGP code
4326 and the URN "urn:ogc:def:crs:EPSG::4326".

2: NAD83 (Latitude, Longitude) + NAVD88:
This datum uses a combination of the North American Datum 1983
(NAD83) for horizontal (latitude and longitude) values, plus the
North American Vertical Datum of 1988 (NAVD88) vertical datum.

This datum is used for referencing location on land (not near
tidal water) within North America.

NAD83 is identified by the EPSG/OGP code of 4269, or the URN
"urn:ogc:def:crs:EPSG::4269". NAVD88 is identified by the EPSG/
OGP code of 5703, or the URN "urn:ogc:def:crs:EPSG::5703".

3: NAD83 (Latitude, Longitude) + MLLW:
This datum uses a combination of the North American Datum 1983
(NAD83) for horizontal (latitude and longitude) values, plus the
Mean Lower Low Water (MLLW) vertical datum.

This datum is used for referencing location on or near tidal water
within North America.

NAD83 is identified by the EPSG/OGP code of 4269, or the URN
"urn:ogc:def:crs:EPSG::4269". MLLW does not have a specific code
or URN.

All hosts MUST support the WGS84 datum (Datum 1).

New datum codes can be registered in the IANA registry (Section 5) by
a Standards Track RFC.

--
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/2#comment:7>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

geopriv@ietf.org

Friday, September 11, 2009

Re: [Geopriv] [geopriv] #2: Add DHCPv6 option format

Followers

Blog Archive

Contributors