Internet DRAFT - draft-winterbottom-geopriv-held-lis2lis-bcp

draft-winterbottom-geopriv-held-lis2lis-bcp






Geopriv                                                  J. Winterbottom
Internet-Draft                                                M. Thomson
Intended status: Best Current                         Andrew Corporation
Practice                                                November 9, 2007
Expires: May 12, 2008


                 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.

Copyright Notice

   Copyright (C) The IETF Trust (2007).













Winterbottom & Thomson    Expires May 12, 2008                  [Page 1]

Internet-Draft               LIS to LIS BCP                November 2007


Abstract

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


Table of Contents

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































Winterbottom & Thomson    Expires May 12, 2008                  [Page 2]

Internet-Draft               LIS to LIS BCP                November 2007


1.  Introduction

   The LIS to LIS communication requirements
   [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
   [I-D.ietf-geopriv-http-location-delivery] in conjunction with the
   HELD identity extensions
   [I-D.winterbottom-geopriv-held-identity-extensions] and the HELD
   measurements specification [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.






































Winterbottom & Thomson    Expires May 12, 2008                  [Page 3]

Internet-Draft               LIS to LIS BCP                November 2007


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

   This document uses the term Location Information Server, LIS, is used
   as defined in [I-D.ietf-geopriv-l7-lcp-ps].

   Basic terms from the HELD specification
   [I-D.ietf-geopriv-http-location-delivery] 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].



































Winterbottom & Thomson    Expires May 12, 2008                  [Page 4]

Internet-Draft               LIS to LIS BCP                November 2007


3.  Overview

   The network scenario described in
   [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.




































Winterbottom & Thomson    Expires May 12, 2008                  [Page 5]

Internet-Draft               LIS to LIS BCP                November 2007


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], 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] 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].

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



Winterbottom & Thomson    Expires May 12, 2008                  [Page 6]

Internet-Draft               LIS to LIS BCP                November 2007


   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], may be used.














































Winterbottom & Thomson    Expires May 12, 2008                  [Page 7]

Internet-Draft               LIS to LIS BCP                November 2007


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.


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

       Figure 1: LIS to LIS Location Request with L2TP Measurements

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















Winterbottom & Thomson    Expires May 12, 2008                  [Page 8]

Internet-Draft               LIS to LIS BCP                November 2007


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

              Figure 2: Regional Access Provider LIS Response


















Winterbottom & Thomson    Expires May 12, 2008                  [Page 9]

Internet-Draft               LIS to LIS BCP                November 2007


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.










































Winterbottom & Thomson    Expires May 12, 2008                 [Page 10]

Internet-Draft               LIS to LIS BCP                November 2007


7.  IANA Considerations

   There are no IANA considerations for this document.
















































Winterbottom & Thomson    Expires May 12, 2008                 [Page 11]

Internet-Draft               LIS to LIS BCP                November 2007


8.  References

8.1.  Normative references

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [I-D.ietf-geopriv-http-location-delivery]
              Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
              "HTTP Enabled Location Delivery (HELD)",
              draft-ietf-geopriv-http-location-delivery-02 (work in
              progress), September 2007.

   [I-D.winterbottom-geopriv-lis2lis-req]
              Winterbottom, J. and S. Norreys, "LIS to LIS Protocol
              Requirements", draft-winterbottom-geopriv-lis2lis-req-00
              (work in progress), June 2007.

   [I-D.winterbottom-geopriv-held-identity-extensions]
              Winterbottom, J. and M. Thomson, "HELD Device identity
              Extensions",
              draft-winterbottom-geopriv-held-identity-extensions-03
              (work in progress), October 2007.

   [I-D.thomson-geopriv-held-measurements]
              Thomson, M. and J. Winterbottom, "Using Device-provided
              Location Measurements in HELD",
              draft-thomson-geopriv-held-measurements-00 (work in
              progress), October 2007.

8.2.  Informative references

   [RFC4119]  Peterson, J., "A Presence-based GEOPRIV Location Object
              Format", RFC 4119, December 2005.

   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
              J. Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [I-D.thomson-geopriv-held-beep]
              Thomson, M. and J. Winterbottom, "A BEEP Binding for the
              HELD Protocol", draft-thomson-geopriv-held-beep-00 (work
              in progress), February 2007.

   [I-D.thomson-geopriv-lis-discovery]
              Thomson, M. and J. Winterbottom, "Discovering the Local
              Location Information Server (LIS)",



Winterbottom & Thomson    Expires May 12, 2008                 [Page 12]

Internet-Draft               LIS to LIS BCP                November 2007


              draft-thomson-geopriv-lis-discovery-03 (work in progress),
              September 2007.

   [I-D.ietf-geopriv-l7-lcp-ps]
              Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
              Location Configuration Protocol; Problem Statement and
              Requirements", draft-ietf-geopriv-l7-lcp-ps-05 (work in
              progress), September 2007.











































Winterbottom & Thomson    Expires May 12, 2008                 [Page 13]

Internet-Draft               LIS to LIS BCP                November 2007


Authors' Addresses

   James Winterbottom
   Andrew Corporation
   PO Box U40
   University of Wollongong, NSW  2500
   AU

   Email: james.winterbottom@andrew.com


   Martin Thomson
   Andrew Corporation
   PO Box U40
   University of Wollongong, NSW  2500
   AU

   Email: martin.thomson@andrew.com

































Winterbottom & Thomson    Expires May 12, 2008                 [Page 14]

Internet-Draft               LIS to LIS BCP                November 2007


Full Copyright Statement

   Copyright (C) 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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Winterbottom & Thomson    Expires May 12, 2008                 [Page 15]