[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Geopriv                                                  J. Winterbottom
Internet-Draft                                        Andrew Corporation
Intended status: Standards Track                              S. Norreys
Expires: May 22, 2008                                    British Telecom
                                                       November 19, 2007


                    LIS to LIS Protocol Requirements
             draft-winterbottom-geopriv-lis2lis-req-01.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 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).













Winterbottom & Norreys    Expires May 22, 2008                  [Page 1]


Internet-Draft                LIS_2_LIS-Req                November 2007


Abstract

   This document describes requirements for a LIS to LIS protocol and
   provides examples of where such a protocol is applicable.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     9.1.  Normative references . . . . . . . . . . . . . . . . . . . 13
     9.2.  Informative references . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15






























Winterbottom & Norreys    Expires May 22, 2008                  [Page 2]


Internet-Draft                LIS_2_LIS-Req                November 2007


1.  Introduction

   The architecture of some networks results in more than one operator
   being involved in providing Internet connectivity to an end-point.
   Examples of this type of configuration are prevalent in residential
   broadband access environments where the physical infrastructure is
   owned by one operator, while a third-party ISP provides an IP address
   and layer 3 connectivity to the Internet.  In architectures such as
   these, the Internet connectivity service is dependent on both
   providers.  Similarly, both have information about the connectivity
   of an end-point to the network.  The information that one party
   holds, however, is usually different to the information held by the
   other party, and neither party (on its own) can use the information
   it possesses to yield the physical location of an end-point.
   However, when the connectivity information held by the two parties is
   combined the location of the end-point can be determined.



































Winterbottom & Norreys    Expires May 22, 2008                  [Page 3]


Internet-Draft                LIS_2_LIS-Req                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) as
   defined in [I-D.ietf-geopriv-l7-lcp-ps].

   Broadband Remote Access Server (BRAS).  A node in a DSL network
   responsible for switching data streams between end-points and
   Internet Service Providers.

   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 & Norreys    Expires May 22, 2008                  [Page 4]


Internet-Draft                LIS_2_LIS-Req                November 2007


3.  Overview

   The Geopriv L7 LCP requirements [I-D.ietf-geopriv-l7-lcp-ps] describe
   a range of network topologies in which a Target should be able to
   acquire its location from a LIS using an application layer location
   acquisition protocol.  The scope of [I-D.ietf-geopriv-l7-lcp-ps] is
   such that it does not address specific network topologies that may
   exist inside the access network provider domain.  This document
   provides scope and requirements for LIS to LIS communications where
   the two servers are controlled by different operators each running a
   part of the access network.  While the same principles may be applied
   to inter-LIS communication occurring between a LIS in the customer
   premise network and the access provider network, operation in this
   configuration is not considered in scope for this document.


    +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
    |                            |    |                                |
    |        Regional            |    |        INTERNET Service        |
    |  Access Network Provider   |    |            Provider            |
    |                            |    |          +------------------+  |
    |   +------------+           |    |          |  Network Access  |  |
    |   | Switching  |-------------------------->|      Server      |  |
    |   +------------+           |    |          +------------------+  |
    |         ^   |     +-----+  |    |  +-----+      |                |
    |         |   |     |     |  |    |  |     |      |                |
    |         |   +---->| LIS |<========>| LIS |<-----+                |
    |         |         |     |  |    |  |     |                       |
    |         |         +-----+  |    |  +-----+                       |
    |         |            ^     |    |                                |
    |     +--------+       |     |    |                                |
    |     | Access |-------+     |    |                                |
    |     |  Node  |             |    |                                |
    |     +----+---+             |    |                                |
    |          |                 |    |                                |
    |          |                 |    |                                |
    +~~~~~~~~~~~~~~~~~~~~~~~~~Access Network~~~~~~~~~~~~~~~~~~~~~~~~~~~+
               |
      <----------------> Cable Plant
               |
      +--------+----------+
      |                   |
      | Customer Premises |
      |                   |
      +-------------------+

                  Figure 1: Multi-Operator Access Network




Winterbottom & Norreys    Expires May 22, 2008                  [Page 5]


Internet-Draft                LIS_2_LIS-Req                November 2007


   Figure 1 illustrates a typical multi-operator access network where
   physical and switched connectivity is provided by a Regional Access
   Network Provider, and higher layer routing functions are provided by
   an Internet Service provider (ISP).  It is the ISP that owns the
   relationship with the broadband customer, the end-point, and it is
   the ISP LIS that will be contacted by any end-point to provide
   location.  The ISP will know network parameters such as the IP
   address allocated to the end-point, and the associated NAS and port
   the incoming connection is terminated on; but it often will not know
   any information pertaining to connectivity (physical or logical)
   inside the regional access network.  Conversely in many situations
   the regional access provider will not have access to information such
   as the IP address of the end-point or a means to correlate the IP
   address with other known physical parameters.  The regional access
   provider will have access to information from the switch core, the
   access node, and cable termination records, allowing the regional
   access provider LIS to determine a physical location.  Common
   information between the ISP NAS and the Regional Access Provider's
   switching core, such as circuit identifiers, are required in order to
   ensure correct data transmission through the network, and these can
   be used as Target identifiers from the ISP LIS to the Regional Access
   LIS allowing the physical location of an end-point to be retrieved.

   This document describes the requirements for this information flow.



























Winterbottom & Norreys    Expires May 22, 2008                  [Page 6]


Internet-Draft                LIS_2_LIS-Req                November 2007


4.  Assumptions

   This section details the high-level assumptions made in this
   document.

   1: A strong trust relationship exists between the regional access
      provider and ISP.


   2: Targets only deal directly with the ISP LIS, and may be totally
      unaware of any regional access provider LIS.  A regional access
      LIS will only ever receive location requests from an ISP LIS.







































Winterbottom & Norreys    Expires May 22, 2008                  [Page 7]


Internet-Draft                LIS_2_LIS-Req                November 2007


5.  Requirements

   This section details the requirements that MUST be satisfied by any
   LIS to LIS protocol

   1: Connections (physical and logical) from the ISP LIS to the
      regional access LIS require both ends to authenticate as part of
      connection establishment.  The security of the data conveyed
      between the two servers MUST be ensured for both privacy and
      integrity.


   2: The data used to identify a Target to the ISP MUST be able to be
      passed to, and be recognizable by the regional access LIS using
      the LIS to LIS protocol.  The data used to identify a Target to
      the ISP MUST be consistent with the traffic aggregation method
      supported by the Regional Access Network Provider.


   3: Location information returned over a LIS to LIS protocol MUST be
      in PIDF-LO [RFC4119] format, and MUST comply with
      [I-D.ietf-geopriv-pdif-lo-profile] .


   4: The type of location information requested by the end-point MUST
      be relayed to the regional access LIS by the ISP LIS using the LIS
      to LIS protocol.


   5: The method used by the regional access LIS to determine the
      location of the Target MUST be provided to the ISP LIS along with
      the determined location.


   6: Any usage-rule preferences provided by the Target to the ISP LIS
      MUST be included in any location returned to the Target or
      Location Recipient.


   7: Additional information provided by the Target to the ISP in a
      location request that cannot be processed directly by the ISP LIS
      MUST be forwarded to regional access LIS using the LIS to LIS
      protocol.  The intention of this requirement is to support future
      LCP functions that require additional information from the Target.







Winterbottom & Norreys    Expires May 22, 2008                  [Page 8]


Internet-Draft                LIS_2_LIS-Req                November 2007


   8: The presentity in the PIDF-LO returned by the regional access LIS
      MUST have been provided by the ISP LIS.  The ISP LIS may create
      the presentity, or it may have received a presentity from the
      Target.


   9: The protocol MUST provide support for returning and dealing with
      error conditions such as "no location found" or "timeout".











































Winterbottom & Norreys    Expires May 22, 2008                  [Page 9]


Internet-Draft                LIS_2_LIS-Req                November 2007


6.  Security Considerations

   LIS to LIS communications are necessary in some network architectures
   and care must be taken to ensure that they are secure both from a
   privacy perspective and from an integrity perspective.  This can be
   achieved in the most part with existing protocol suites, such as TLS,
   using certificates or pre-shared keys.  Another factor that must be
   protected against is the ability of a legitimate ISP LIS asking for
   the location of an end-point associated with a different ISP.
   Operators of regional access servers will need to ensure that this
   operational requirement is met.








































Winterbottom & Norreys    Expires May 22, 2008                 [Page 10]


Internet-Draft                LIS_2_LIS-Req                November 2007


7.  IANA Considerations

   There are no IANA considerations for this document.
















































Winterbottom & Norreys    Expires May 22, 2008                 [Page 11]


Internet-Draft                LIS_2_LIS-Req                November 2007


8.  Acknowledgements

   Thanks to Guy Caron and Barbara Stark for providing early reviews of
   this document.  Thanks to Martin Thomson and Cullen Jennings for
   providing comments.














































Winterbottom & Norreys    Expires May 22, 2008                 [Page 12]


Internet-Draft                LIS_2_LIS-Req                November 2007


9.  References

9.1.  Normative references

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

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

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

   [I-D.ietf-geopriv-pdif-lo-profile]
              Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
              PIDF-LO Usage Clarification, Considerations and
              Recommendations", draft-ietf-geopriv-pdif-lo-profile-10
              (work in progress), October 2007.

9.2.  Informative references

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

























Winterbottom & Norreys    Expires May 22, 2008                 [Page 13]


Internet-Draft                LIS_2_LIS-Req                November 2007


Authors' Addresses

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

   Email: james.winterbottom@andrew.com


   Steve Norreys
   British Telecom
   UK

   Email: steve.norreys@bt.com



































Winterbottom & Norreys    Expires May 22, 2008                 [Page 14]


Internet-Draft                LIS_2_LIS-Req                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 & Norreys    Expires May 22, 2008                 [Page 15]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/