One document matched: draft-winterbottom-geopriv-held-lis2lis-bcp-00.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3693 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3693.xml">
<!ENTITY RFC4119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml">
<!ENTITY RFC2818 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY I-D.ietf-geopriv-http-location-delivery PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-http-location-delivery.xml">
<!ENTITY I-D.ietf-geopriv-l7-lcp-ps PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-l7-lcp-ps.xml">
<!ENTITY I-D.winterbottom-geopriv-held-identity-extensions PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.winterbottom-geopriv-held-identity-extensions.xml">
<!ENTITY I-D.thomson-geopriv-lis-discovery PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-geopriv-lis-discovery.xml">
<!ENTITY I-D.thomson-geopriv-held-beep PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-geopriv-held-beep.xml">
<!ENTITY I-D.thomson-geopriv-held-measurements PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-geopriv-held-measurements.xml">
<!ENTITY I-D.winterbottom-geopriv-lis2lis-req PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.winterbottom-geopriv-lis2lis-req.xml">
]>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<rfc category="bcp" ipr="full3978" docName="draft-winterbottom-geopriv-held-lis2lis-bcp-00.txt">
<front>
<title abbrev="LIS to LIS BCP">Using HELD for Inter-LIS Communication</title>
<author initials="J." surname="Winterbottom" fullname="James Winterbottom">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>University of Wollongong</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<email>james.winterbottom@andrew.com</email>
</address>
</author>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>PO Box U40</street>
<city>University of Wollongong</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<email>martin.thomson@andrew.com</email>
</address>
</author>
<date month="November" year="2007"/>
<area>Application</area>
<workgroup>Geopriv</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document describes how HELD can be used to support LIS to LIS communication.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The LIS to LIS communication requirements <xref target="I-D.winterbottom-geopriv-lis2lis-req"/> describe the need in some network
environements for one LIS to consult another LIS in order to determine the location of a Device. This document describes how
HELD <xref target="I-D.ietf-geopriv-http-location-delivery"/> in conjunction with the HELD identity extensions
<xref target="I-D.winterbottom-geopriv-held-identity-extensions"/> and the HELD measurements specification <xref target="I-D.thomson-geopriv-held-measurements"/>
can be used to satisfy these requirements. No new schema is
introduced by this document, recipes using existing specifications are described.
</t>
</section>
<section anchor="terminology" title="Terminology">
<t>The key conventions and terminology used in this document are defined as follows:
</t>
<t>This document reuses the terms Target, as defined in <xref target="RFC3693"/>.
</t>
<t> This document uses the term Location Information Server, LIS, is used as defined in <xref target="I-D.ietf-geopriv-l7-lcp-ps"/>.
</t>
<t>Basic terms from the HELD specification <xref target="I-D.ietf-geopriv-http-location-delivery"/> are also reused.
</t>
<t>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 <xref target="RFC2119"/>.
</t>
</section>
<section title="Overview">
<t>The network scenario described in <xref target="I-D.winterbottom-geopriv-lis2lis-req"/> shows that in some environments the LIS publically
associated with a Device cannot, on its own, determine the location of the Device. HELD provides a specification allowing a
Device to obtain location information from a Location Information Server (LIS). This specification extends HELD by chaining a location request
from the publically accessible LIS to a LIS controlled by a regional access provider. The publically accessible LIS can also add
measured and identity parameters relating to the Device in the HELD locationRequest made to the access provider LIS.
Resuing HELD in this manner reduces the number of protocols that need to be supported on a LIS, it simplfies development,
reduces complexity, and improves interoperability.
</t>
</section>
<section title="Detailed Description">
<t>In a typical environment using HELD, the Target discovers the LIS using one of the methods described in
<xref target="I-D.thomson-geopriv-lis-discovery"/>, and makes a request for location information. The ISP LIS receives the location request from the Target, adds additional information,
and then sends the location request on to the regional access provider LIS. The regional access provider LIS uses the extra information provided in the ISP LIS
to determine the location of the Device and provide the PIDF-LO <xref target="RFC4119"/> in the requested form.
</t>
<t>The ISP LIS will, in many cases creates the identity used in the <spanx style="verb">pres</spanx> field of the PIDF-LO. This value needs to be conveyed from
the ISP LIS to the regional access provider LIS. HELD can convey this value using a URI identity extension as described in <xref target="I-D.winterbottom-geopriv-held-identity-extensions"/>.
</t>
<t>The ISP LIS may need to provide Device network attachment information, in the form of measurements, to the regional access provider LIS to aid it in determing the Device's location.
A comprehensive set of measurements and how they are used is provided in <xref target="I-D.thomson-geopriv-held-measurements"/>.
HELD supports the inclusion of these additional elements without modification.
</t>
<t>The ISP LIS should not send a request for a location URI to the regional access provider LIS. This is because the regional access provider LIS is, in most cases, invisible
to entities other than the ISP LIS. A location URI contains the hostname of the LIS that will service a location request, which is the ISP LIS and not the
regional access provider LIS. Consequently only the ISP LIS should create location URIs for the Device. A regional access provider LIS receiving a request for a
location URI from an ISP LIS should respond with a "cannotProvideLiType" error.
</t>
<t>The ISP LIS should pass all elements included in the Device's location request to the regional access provider LIS, with the exception of a request for a location URI
which was described in the previous paragraph. This behaviour ensures that any new options made available to the LIS through HELD can be supported
without necessarily requiring changes to the ISP LIS.
</t>
<t>The ISP LIS should provide usage in any returned location object that match the user's desired settings, or in the absence of these, the default settings
for <retransmission-allowed> and <retension-expiry> as applied by the ISP LIS.
</t>
<t>Basic HELD is provided with an HTTP binding, which is suitable for the application of a Device requesting its own location. Where a nailed up connection
between two entities and continual transaction streaming is required, HTTP may be less appropriate. In this configuration an alternative transport,
such as BEEP <xref target="I-D.thomson-geopriv-held-beep"/>, may be used.
</t>
</section>
<section title="Examples">
<t>In this example a DSL service is provided with an L2TP tunnel forming the link between the BRAS in the regional access provider's network, and the NAS in the ISP.
The Device has requested a civic location. The resulting location request sent from the ISP LIS to the regional access provider LIS is shown in <xref target="ex1"/>.
</t>
<t>
<figure anchor="ex1" title="LIS to LIS Location Request with L2TP Measurements">
<artwork><![CDATA[
<locationRequest
xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="8">
<locationType>civic</locationType>
<heldDevice xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
<uri type="presentity">pres:3sijsskcknckj@ls.example.com</uri>
</heldDevice>
<measurements xmlns="urn:ietf:params:xml:ns:geopriv:held:lm">
<dsl>
<l2tp>
<src>192.0.2.10</src>
<dest>192.0.2.61</dest>
<session>528</session>
</l2tp>
</dsl>
</measurements>
</locationRequest>
]]></artwork>
</figure>
</t>
<t>The regional access provider LIS would use the L2TP tunnel information to establish the location of the Device.
It would then create a PIDF-LO using the URI specified as a <heldDevice> as the presentity value. The resulting location response
from the access provider LIS to the ISP LIS may look something similar to <xref target="ex2"/>. On receiving this response the
ISP LIS will need to add the usage rules specified by the Device or use local defaults if no Device instructions are available.
</t>
<t>
<figure anchor="ex2" title="Regional Access Provider LIS Response">
<artwork><![CDATA[
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:3sijsskcknckj@ls.example.com">
<tuple id="3b650sf789nd">
<status>
<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10">
<location-info>
<ca:civicAddress
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xml:lang="en-au">
<ca:country>AU</ca:country>
<ca:A1>NSW</ca:A1>
<ca:A3>Wollongong</ca:A3>
<ca:A4>Gwynneville</ca:A4>
<ca:STS>Northfield Avenue</ca:STS>
<ca:LMK>University of Wollongong</ca:LMK>
<ca:FLR>2</ca:FLR>
<ca:NAM>Andrew Corporation</ca:NAM>
<ca:PC>2500</ca:PC>
<ca:BLD>39</ca:BLD>
<ca:SEAT>WS-183</ca:SEAT>
<ca:POBOX>U40</ca:POBOX>
</ca:civicAddress>
</location-info>
</usage-rules>
</geopriv>
</status>
<timestamp>2007-10-31T03:42:28+00:00</timestamp>
</tuple>
</presence>
</locationResponse>
]]></artwork>
</figure>
</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>A strong trust relationship needs to exist between the ISP and the regional access provider in order for
this type of access network to operate successfully. Since this document describes the exchange of Device
location information between two trusted parties it does not mandate the use of any specific crypto techniques
but recommends the use of TLS with client-side and server-side certificates for authentication.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>There are no IANA considerations for this document.
</t>
</section>
</middle>
<back>
<references title="Normative references">
&RFC2119;
&RFC2818;
&I-D.ietf-geopriv-http-location-delivery;
&I-D.winterbottom-geopriv-lis2lis-req;
&I-D.winterbottom-geopriv-held-identity-extensions;
&I-D.thomson-geopriv-held-measurements;
</references>
<references title="Informative references">
&RFC4119;
&RFC3693;
&I-D.thomson-geopriv-held-beep;
&I-D.thomson-geopriv-lis-discovery;
&I-D.ietf-geopriv-l7-lcp-ps;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:43:30 |