Using HELD for Inter-LIS Communication
draft-winterbottom-geopriv-held-lis2lis-bcp-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 May 12, 2008.

Abstract

This document describes how HELD can be used to support LIS to LIS communication.

Table of Contents

1.  Introduction
2.  Terminology
3.  Overview
4.  Detailed Description
5.  Examples
6.  Security Considerations
7.  IANA Considerations
8.  References
    8.1.  Normative references
    8.2.  Informative references
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

The LIS to LIS communication requirements [I‑D.winterbottom‑geopriv‑lis2lis‑req] (Winterbottom, J. and S. Norreys, “LIS to LIS Protocol Requirements,” November 2007.) 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 [I‑D.ietf‑geopriv‑http‑location‑delivery] (Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, “HTTP Enabled Location Delivery (HELD),” August 2009.) in conjunction with the HELD identity extensions [I‑D.winterbottom‑geopriv‑held‑identity‑extensions] (Thomson, M., Tschofenig, H., Barnes, R., and J. Winterbottom, “Use of Target Identity in HTTP-Enabled Location Delivery (HELD),” August 2009.) and the HELD measurements specification [I‑D.thomson‑geopriv‑held‑measurements] (Thomson, M. and J. Winterbottom, “Using Device-provided Location-Related Measurements in Location Configuration Protocols,” October 2009.) can be used to satisfy these requirements. No new schema is introduced by this document, recipes using existing specifications are described.

2.  Terminology

The key conventions and terminology used in this document are defined as follows:

This document reuses the terms Target, as defined in [RFC3693] (Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, “Geopriv Requirements,” February 2004.).

This document uses the term Location Information Server, LIS, is used as defined in [I‑D.ietf‑geopriv‑l7‑lcp‑ps] (Tschofenig, H. and H. Schulzrinne, “GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements,” July 2009.).

Basic terms from the HELD specification [I‑D.ietf‑geopriv‑http‑location‑delivery] (Barnes, M., Winterbottom, J., Thomson, M., and B. Stark, “HTTP Enabled Location Delivery (HELD),” August 2009.) are also reused.

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.  Overview

The network scenario described in [I‑D.winterbottom‑geopriv‑lis2lis‑req] (Winterbottom, J. and S. Norreys, “LIS to LIS Protocol Requirements,” November 2007.) 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.

4.  Detailed Description

In a typical environment using HELD, the Target discovers the LIS using one of the methods described in [I‑D.thomson‑geopriv‑lis‑discovery] (Thomson, M. and J. Winterbottom, “Discovering the Local Location Information Server (LIS),” September 2007.), 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 [RFC4119] (Peterson, J., “A Presence-based GEOPRIV Location Object Format,” December 2005.) in the requested form.

The ISP LIS will, in many cases creates the identity used in the pres 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 [I‑D.winterbottom‑geopriv‑held‑identity‑extensions] (Thomson, M., Tschofenig, H., Barnes, R., and J. Winterbottom, “Use of Target Identity in HTTP-Enabled Location Delivery (HELD),” August 2009.).

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 [I‑D.thomson‑geopriv‑held‑measurements] (Thomson, M. and J. Winterbottom, “Using Device-provided Location-Related Measurements in Location Configuration Protocols,” October 2009.). HELD supports the inclusion of these additional elements without modification.

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.

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.

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.

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 [I‑D.thomson‑geopriv‑held‑beep] (Thomson, M. and J. Winterbottom, “A BEEP Binding for the HELD Protocol,” July 2009.), may be used.

5.  Examples

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 Figure 1 (LIS to LIS Location Request with L2TP Measurements).

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

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 Figure 2 (Regional Access Provider LIS Response). 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.

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

6.  Security Considerations

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.

7.  IANA Considerations

There are no IANA considerations for this document.

8.  References

8.1. Normative references

8.2. Informative references

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2007).

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.