One document matched: draft-schulzrinne-ecrit-lost-sync-01.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 I-D.ietf-ecrit-lost PUBLIC ''  
    'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-lost.xml'>
  <!ENTITY I-D.ietf-ecrit-mapping-arch PUBLIC ''  
    'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-mapping-arch.xml'>
]>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<rfc ipr="full3978" category="std" docName="draft-schulzrinne-ecrit-lost-sync-01.txt">
<front>
<title abbrev="LoST Sync">Synchronizing Location-to-Service Translation
(LoST) Servers</title>
<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
<organization abbrev="Columbia U.">Columbia University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>450 Computer Science Building</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>US</country>
</postal>
<phone>+1 212 939 7004</phone>
<email>hgs+ecrit@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<date year="2008"/>
<area>RAI</area>
<workgroup>ECRIT</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Location</keyword>
<abstract>
<t>The LoST (Location-to-Service Translation) protocol is used to map
locations to service URLs.  This document defines a set of LoST
extensions that allow LoST servers to synchronize their lists of
mappings.</t>
</abstract>

</front>
<middle>

<section title="Introduction">

<t>The <xref target="I-D.ietf-ecrit-lost">LoST (Location-to-Service
Translation) protocol</xref> maps geographic locations to service URLs. 
As specified in the <xref target="I-D.ietf-ecrit-mapping-arch">LoST
architecture description</xref>, there are a variety of LoST servers
that cooperate to provide a global, scalable and resilient mapping
service.  The LoST protocol specification only describes the protocol
used for individual seeker-originated queries.  This document adds LoST
operations that allow forest guides, resolver clusters and authoritative
servers to synchronize their database of mappings.</t>

<t>In the LoST architecture, servers can peer, i.e., have an on-going
data exchange relationship.  Peering relationships are set up manually,
based on local policies.  A server can peer with any number of other
servers.  Forest guides peer with other forest guides; resolvers peer
with forest guides and other resolvers (in the same cluster);
authoritative mapping servers peer with forest guides and other
authoritative servers, either in the same cluster or above or below them
in the tree.  If the type of LoST role does not matter, we refer to LoST
protocol participants as LoST nodes.</t>

<t>Authoritative mapping servers push coverage regions "up" the tree,
i.e., from child nodes to parent nodes.  The child informs the parent of
the geospatial or civic region that it covers. [TBD: How referenced?]</t>

<t>The coverage regions of different authoritative servers can overlap. 
This should only happen if the authoritative servers are misconfigured
or if there is a political dispute that involves competing claims for
the same region.  A server MUST detect such colliding claims and
implement a policy to resolve the collision, either through an automated
policy mechanism or manual intervention.</t>

<t>This extension defines two new requests, <pushMappingsRequest> and
<getMappingsRequest>, that allow peering servers to exchange
mappings.  These requests are used for all peering relationships and
always contain mapping entries, but naturally the content of the data
exchanged differs.</t>

</section>

<section anchor="terminology" title="Terminology">

<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 RFC 2119 <xref
target="RFC2119"/>.</t>

<t>This document reuses terminology introduced by the <xref 
target="I-D.ietf-ecrit-mapping-arch">mapping architecture
document</xref>.</t>

</section>

<section title="Distributing Mappings via <pushMappingsRequest>">

<t>When a LoST node obtains new information that is of interest to its
peers, it pushes the new mappings to its peers.  This information might
arrive through non-LoST means, such as a manual addition to the local
mappings database, or through another LoST node, via a <pushMappings>
request or a <getMappingsResponse> described later.  Mappings in that
request replace existing mappings with the same 'id' parameter and a
more recent 'created' parameter.  (Enforcing the latter avoids that a
node that wakes up injects outdated information into the system.)</t>

<t>Each peer keeps track of which peer it has exchanged which mapping
elements with.  Mapping elements are identified by the 'source',
'sourceID' and 'version' parameters.  A mapping is considered the same
if these three attributes match.  Nodes never push the same information
to the same peer twice.</t>

<t>Instead of providing the mappings themselves, the LoST client can
include references to mappings that have changed since the last request,
by including <m> entries. The server then requests any out-of-date or
missing mappings by including a subset of that list as <m> elements
in a <getMappingsRequest> request.</t>

<t>To delete a mapping, the content of the mapping is left empty.  The
node can delete the mapping from its internal mapping database, but has
to remember which peers it has distributed this update to. The mapping
is identified only by the 'sourceId' and 'source' parameters; the other
parameters are ignored if present. In other words, the delete operation
affects all versions of a mapping.</t>

<t>The response to <pushMappingsRequest> is
<pushMappingsResponse>.  It only contains <errors> elements if
there is an error condition.  Only the ....  errors are defined
(TBD).</t>

<t>If the set of nodes that are synchronizing their data does not form a
tree, it is possible that the same information arrives through several
other nodes.  This is unavoidable, but generally only imposes a modest
overhead.  (It would be possible to create a spanning tree in the same
fashion as IP multicast, but the complexity does not seem warranted,
giving the relatively low volume of data.)</t>

<t>An example is shown in <xref target="pushMappings"/>. In the example,
the last mapping, with source lost:nj.us.example and mapping ID
'englewood', is being  removed.</t>

<t><figure anchor="pushMappings"
  title="Example pushMappingsRequest and pushMappingsResponse">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<pushMappingsRequest xmlns="urn:ietf:params:xml:ns:lost1:sync">
<mappings>
  <mapping sourceId="lost:leonia.nj.us.example"
    version="1" lastUpdated="2006-11-26T01:00:00Z"
    timeToLive="2007-12-26T01:00:00Z">
    <displayName xml:lang="en">
      Leonia Police Department
    </displayName>
    <service>urn:service:sos.police</service>
    <serviceBoundary
      profile="urn:ietf:params:lost:location-profile:basic-civic">
      <civicAddress
        xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
        <country>US</country>
        <A1>NJ</A1>
        <A3>Leonia</A3>
        <PC>07605</PC>
      </civicAddress>
    </serviceBoundary>
    <uri>sip:police@leonianj.example.org</uri>
    <serviceNumber>911</serviceNumber>
  </mapping>

  <mapping
    expires="2007-01-01T01:44:33Z"
    lastUpdated="2006-11-01T01:00:00Z"
    source="lost:authoritative.example"
    sourceId="abc123" version="1">
    <displayName xml:lang="en">
      New York City Police Department
    </displayName>
    <service>urn:service:sos.police</service>
    <serviceBoundary profile="geodetic-2d">
      <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
        <p2:exterior>
          <p2:LinearRing>
            <p2:pos>37.775 -122.4194</p2:pos>
            <p2:pos>37.555 -122.4194</p2:pos>
            <p2:pos>37.555 -122.4264</p2:pos>
            <p2:pos>37.775 -122.4264</p2:pos>
            <p2:pos>37.775 -122.4194</p2:pos>
          </p2:LinearRing>
        </p2:exterior>
      </p2:Polygon>
    </serviceBoundary>
    <uri>sip:nypd@example.com</uri>
    <uri>xmpp:nypd@example.com</uri>
    <serviceNumber>911</serviceNumber>
  </mapping>

  <mapping source="lost:nj.us.example" sourceId="englewood"/>

</mappings>
</pushMappingsRequest>

<?xml version="1.0" encoding="UTF-8"?>
<pushMappingsResponse xmlns="urn:ietf:params:xml:ns:lost1:sync" />
</pushMappingsResponse>

]]></artwork>
</figure>
</t>

</section>

<section title="Synchronizing Mapping Stores via <getMappingsRequest>
and <getMappingsResponse>">

<t>Get list of mappings identified by <m> elements. The server may
not be able to return all such mappings, but the client can easily tell
which mappings were unavailable since it can compare the mapping
identifiers to those returned in the mapping elements.</t>

<t>Errors TBD.</t>

</section>

<section title="Synchronizing Mapping Stores via <syncMappingsRequest>
and <syncMappingsResponse>">

<t>While the <pushMappingsRequest> request allows new mappings to
propagate, it does not allow a newly-arriving node to acquire all
mappings maintained by another node.  Therefore, we introduce <syncMappingsRequest> and
<syncMappingsResponse> to synchronize two mapping stores.  A
LoST node wanting to synchronize its mapping store with another node
issues a <getMappingsRequest>, containing an enumeration of the
current mapping sources, source identifiers and versions in <m>
elements.  The recipient of
the request compares that list to its own list of mappings.  It then
returns an unordered set of mappings that are more recent than the ones
identified in the <getMappingsRequest>.  It also returns any mappings
that it knows about that are not contained in the list at all.  Thus, a
querier can get the complete listing of mappings by omitting 'm'
elements altogether.</t>

<t>The querier can limit the scope of the mappings returned by adding
'source', 'sourceId', and 'version' attributes to
<getMappingsRequest>. If the 'source' attribute is specified, only
mappings with that particular source attribute are considered.
Similarly, the 'sourceId' attribute restricts mappings to those matching
the attribute. If 'version' is specified, 'sourceId' needs to be
specified as well. If 'sourceId' is provided, the 'source' attribute also needs to be
included. In other words, a querier cannot ask for all version 17
mappings regardless of source, for example. 'm' elements that do not
match the <getMappingsRequest> attributes are silently ignored.</t>

<t>Errors TBD.</t>

<t>An example request and response is shown in <xref target="getMappings"/></t>

<t><figure anchor="getMappings"
  title="Example getMappingsRequest and getMappingsResponse">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<getMappingsRequest xmlns="urn:ietf:params:xml:ns:lost1:sync"
  sourceId="lost:authoritative.example">
  <m sourceId="lost:authoritative.example"
    sourceId="abc123" version="1" />
  <get sourceId="lost:munich.example.de"
    sourceId="xx" version="2" />
</getMappingsRequest>

<?xml version="1.0" encoding="UTF-8"?>
<getMappingsResponse xmlns="urn:ietf:params:xml:ns:lost1:sync"
  xmlns:p2="http://www.opengis.net/gml">
  <mappings>
    <mapping
     expires="2007-01-26T01:44:33Z"
     lastUpdated="2006-11-26T01:00:00Z"
     source="lost:authoritative.example"
      sourceId="abc123" version="2">
      <displayName xml:lang="en">
        New York City Police Department
      </displayName>
      <service>urn:service:sos.police</service>
      <serviceBoundary profile="geodetic-2d">
        <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
          <p2:exterior>
            <p2:LinearRing>
              <p2:pos>37.775 -122.4194</p2:pos>
              <p2:pos>37.555 -122.4194</p2:pos>
              <p2:pos>37.555 -122.4264</p2:pos>
              <p2:pos>37.775 -122.4264</p2:pos>
              <p2:pos>37.775 -122.4194</p2:pos>
            </p2:LinearRing>
          </p2:exterior>
        </p2:Polygon>
      </serviceBoundary>
      <uri>sip:nypd@ny.example.com</uri>
      <uri>xmpp:nypd@example.com</uri>
      <serviceNumber>911</serviceNumber>
    </mapping>
  </mappings>
</getMappingsResponse>
]]></artwork>
</figure>
</t>

</section>

<section title="Security Considerations">

<t>The LoST security considerations are discussed in <xref
target="I-D.ietf-ecrit-lost"/>.  The operations described in this
document involve mutually-trusting LoST nodes.  These nodes need to
authenticate each other, using mechanisms such as HTTP Digest, HTTP
Basic over TLS or TLS client and server certificates.  Nodes
implementing LoST MUST implement HTTP Basic authentication over TLS and
MAY implement other authentication mechanisms.</t>

</section>

<section title="IANA Considerations">

<section title="LoST Synchronization Namespace Registration">
<t>
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:ns:lost1:sync</t>

<t hangText="Registrant Contact:">IETF ECRIT Working Group, Henning
Schulzrinne (hgs@cs.columbia.edu).</t>

<t hangText="XML:">
<figure>
<artwork><![CDATA[
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
  "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="content-type"
        content="text/html;charset=iso-8859-1"/>
  <title>LoST Synchronization Namespace</title>
</head>
<body>
  <h1>Namespace for LoST server synchronization</h1>
  <h2>urn:ietf:params:xml:ns:lost1:sync</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
    [NOTE TO IANA/RFC-EDITOR:
     Please replace XXXX with the RFC number of this
    specification.]</a>.</p>
</body>
</html>
END
]]></artwork>
</figure>
</t>
</list>
</t>
</section>


</section>

<section title="Acknowledgments">
<t>Andrew Newton provided helpful input.</t>
</section>

<section title="RelaxNG">

<t>TBD</t>

</section>
</middle>
<back>

<references title="Normative References">
&rfc2119;
&I-D.ietf-ecrit-lost;
</references>

<references title="Informative References">
&I-D.ietf-ecrit-mapping-arch;
</references>

</back>
</rfc>