One document matched: draft-winterbottom-geopriv-lis2lis-req-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="rfc2629.xslt" type="text/xsl"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC4119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml'>
<!ENTITY RFC3693 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3693.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.ietf-geopriv-pdif-lo-profile PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-pdif-lo-profile.xml'>
]>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<rfc category="std" ipr="full3978" docName="draft-winterbottom-geopriv-lis2lis-req-01.txt">
<front>
<title abbrev="LIS_2_LIS-Req">LIS to LIS Protocol Requirements</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="S." surname="Norreys" fullname="Steve Norreys">
<organization>British Telecom</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<email>steve.norreys@bt.com</email>
</address>
</author>
<date month="November" year="2007"/>
<area>Application</area>
<workgroup>Geopriv</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document describes requirements for a LIS to LIS protocol and provides examples of where such a protocol is applicable.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>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.
</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) as defined in <xref target="I-D.ietf-geopriv-l7-lcp-ps"/>.
</t>
<t>Broadband Remote Access Server (BRAS). A node in a DSL network responsible for switching data streams between end-points and Internet Service Providers.
</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 Geopriv L7 LCP requirements <xref target="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 <xref target="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.
</t>
<t>
<figure anchor="fig1" title="Multi-Operator Access Network">
<artwork><![CDATA[
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
| | | |
| Regional | | INTERNET Service |
| Access Network Provider | | Provider |
| | | +------------------+ |
| +------------+ | | | Network Access | |
| | Switching |-------------------------->| Server | |
| +------------+ | | +------------------+ |
| ^ | +-----+ | | +-----+ | |
| | | | | | | | | | |
| | +---->| LIS |<========>| LIS |<-----+ |
| | | | | | | | |
| | +-----+ | | +-----+ |
| | ^ | | |
| +--------+ | | | |
| | Access |-------+ | | |
| | Node | | | |
| +----+---+ | | |
| | | | |
| | | | |
+~~~~~~~~~~~~~~~~~~~~~~~~~Access Network~~~~~~~~~~~~~~~~~~~~~~~~~~~+
|
<----------------> Cable Plant
|
+--------+----------+
| |
| Customer Premises |
| |
+-------------------+
]]></artwork>
</figure>
</t>
<t><xref target="fig1"/> 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.
</t>
<t>This document describes the requirements for this information flow.
</t>
</section>
<section title="Assumptions">
<t>This section details the high-level assumptions made in this document.
</t>
<t>
<list style="hanging">
<t hangText="1:"> A strong trust relationship exists between the regional access provider and ISP.
<vspace blankLines="1"/>
</t>
<t hangText="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.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="Requirements">
<t>This section details the requirements that MUST be satisfied by any LIS to LIS protocol
</t>
<t>
<list style="hanging">
<t hangText="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.
<vspace blankLines="1"/>
</t>
<t hangText="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.<vspace blankLines="1"/>
</t>
<t hangText="3:">Location information returned over a LIS to LIS protocol MUST be in PIDF-LO <xref target="RFC4119"/> format, and MUST comply
with <xref target="I-D.ietf-geopriv-pdif-lo-profile"/>
.<vspace blankLines="1"/>
</t>
<t hangText="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.<vspace blankLines="1"/>
</t>
<t hangText="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.<vspace blankLines="1"/>
</t>
<t hangText="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.<vspace blankLines="1"/>
</t>
<t hangText="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.<vspace blankLines="1"/>
</t>
<t hangText="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.<vspace blankLines="1"/>
</t>
<t hangText="9:">The protocol MUST provide support for returning and dealing with error conditions such as “no location found” or “timeout”.
</t>
</list>
</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>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.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>There are no IANA considerations for this document.
</t>
</section>
<section title="Acknowledgements">
<t>Thanks to Guy Caron and Barbara Stark for providing early reviews of this document.
Thanks to Martin Thomson and Cullen Jennings for providing comments.
</t>
</section>
</middle>
<back>
<references title="Normative references">
&RFC2119;
&I-D.ietf-geopriv-l7-lcp-ps;
&RFC4119;
&I-D.ietf-geopriv-pdif-lo-profile;
</references>
<references title="Informative references">
&RFC3693;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:30:25 |