One document matched: draft-marocco-alto-ws-00.xml

<?xml version="1.0" encoding="US-ASCII"?> <!-- -*- fill-column: 120; -*- -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [

<!ENTITY RFC2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5693 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5693.xml">
<!ENTITY RFC6455 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6455.xml">
<!ENTITY I-D.ietf-alto-protocol SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-alto-protocol.xml">
<!ENTITY I-D.schwan-alto-incr-updates SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.schwan-alto-incr-updates.xml">

]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std" docName="draft-marocco-alto-ws-00" ipr="trust200902">

  <front>

    <title abbrev="WebSocket transport for ALTO">
      WebSocket-based server-to-client notifications for the Application-Layer Traffic Optimization (ALTO) Protocol
    </title>

    <author fullname="Enrico Marocco" initials="E." surname="Marocco">
      <organization>Telecom Italia</organization>
      <address>
        <postal>
          <street>Via Reiss Romoli, 274</street>
          <city>Torino</city>
          <region></region>
          <code>10148</code>
          <country>Italy</country>
        </postal>
        <phone></phone>
        <email>enrico.marocco@telecomitalia.it</email>
      </address>
    </author>

    <author fullname="Jan Seedorf" initials="J." surname="Seedorf">
      <organization abbrev="NEC">
        NEC Laboratories Europe, NEC Europe Ltd.
      </organization>
      <address>
        <postal>
          <street>Kurfuersten-Anlage 36</street>
          <city>Heidelberg</city>
          <region></region>
          <code>69115</code>
          <country>Germany</country>
        </postal>
	<phone>+49 (0) 6221 4342 221</phone>
        <email>jan.seedorf@nw.neclab.eu</email>
	<uri>http://www.nw.neclab.eu</uri>
      </address>
    </author>

    <date month="July" year="2012" />

    <area>Transport</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>alto</keyword>

    <abstract>
      <t>
	The Application-Layer Traffic Optimization (ALTO) protocol is designed to allow entities with knowledge about
	the network infrastructure to export such information to applications that need to choose one or more endpoints
	to connect to among large sets of logically equivalent ones. The base protocol specification adopts a simple
	pull-based model, according to which the client retrieves the information encoded as JSON objects over HTTP
	directly from the server.
      </t>
      <t>
	This document proposes (for discussion) a mechanism for providing server-initiated information update
	notifications through a WebSocket-based ALTO protocol extension that easily integrates in the basic protocol
	model.
      </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>
	The <xref target="I-D.ietf-alto-protocol">Application-Layer Traffic Optimization (ALTO) protocol</xref> is
	designed to allow entities with knowledge about the network infrastructure to export such information to
	applications that need to choose one or more endpoints to connect to among large sets of logically equivalent
	ones. The base protocol specification adopts a simple pull-based model, according to which the client retrieves
	the information encoded as JSON objects over HTTP directly from the server.
      </t>
      <t>
	Such a pull-based model is well suited for use cases where the information does not change frequently, e.g. when
	it represents network and cost maps intended to provide a hint to peer-to-peer applications that have to perform
	initial peer selection (i.e. the primary use case that motivated the specification of the ALTO
	protocol). However, over the years several similar use cases have emerged, but most of them with more stringent
	requirements in terms of information freshness. Those use cases could also simply and effectively be addressed
	by the ALTO protocol, provided it features a mechanism for clients to receive server-initiated information
	update notifications. This document proposes (for discussion) a mechanism for providing such notifications
	through a <xref target="RFC6455">WebSocket-based</xref> extension that easily integrates in the basic ALTO
	protocol model.
      </t>
      <t>
	The WebSocket protocol is only one option such extension could be based on. Many altenatives can of course be
	considered, based on virtually any bi-directional protocol that provides some sort of publish/subscribe
	framework. Among others, XMPP, BGP and SNMP have been proposed and to some extent discussed in different
	contexts as a basis for providing similar features. The strenght points of the WebSocket protocol in this
	context -- and thus the reason why the extension proposed here is based on it -- include:

	<list style="symbols">
	  <t>
	    WebSocket is explicitly intended to provide bi-directionality to HTTP, the transport the ALTO protocol is
	    based on. Main implication of this consists with the fact that both HTTP client and server
	    libraries/frameworks ALTO implementations are likely based on natively support it (or, since the technology
	    is very new, soon will);
	  </t>
	  <t>
	    a resource representing an update notification service related to a particular resource instance made
	    available by an ALTO server can simply be identified by a WebSocket URI and advertized in the Information
	    Resource Directory (IRD) just as any other regular resource;
	  </t>
	  <t>
	    a resource representing an update notification service can be unambiguously defined through a MIME type,
	    just as any other regular resource;
	  </t>
	  <t>
	    reuse of HTTP authentication.
	  </t>
	  <t>
	    [TODO: Is Origin-based security of any use here?]
	  </t>
	</list>
      </t>
      <t>
	The most appropriate way for encoding partial updates of ALTO information is an open issue itself, at the time
	of writing, discussed in <xref target="I-D.schwan-alto-incr-updates"/>.
      </t>

      <section title="Requirements Language">
        <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">RFC
	  2119</xref>.
	</t>
      </section>
    </section>

    <section title="Overview of operations">
      <t>
	When an ALTO client wants to retrieve a particular piece of information made available by an ALTO server and
	then receive notifications about each subsequent change, it achieves that in the following steps:

	<list style="numbers">
	  <t anchor="base-begin">
	    retrieve the IRD of the ALTO service it is going to access;
	  </t>
	  <t>
	    find in the IRD the URI of the resource it is interested in, identifying it through the associated content
	    type (e.g. application/alto-networkmap+json);
	  </t>
	  <t anchor="base-end">
	    retrieve a copy of the resource it is interested in;
	  </t>
	  <t anchor="upd-begin">
	    find in the IRD the WebSocket URI of the update notification service associated to the specific resource
	    just retrieved;
	  </t>
	  <t>
	    establish a WebSocket connection against the URI of the update notification service;
	  </t>
	  <t>
	    indicate the version tag of the retrieved resource to the server;
	  </t>
	  <t anchor="upd-end">
	    process each subsequent updates received on the WebSocket connection in order to keep the local
	    representation of the recource up-to-date.
	  </t>
	</list>
      </t>
      <t>
	Steps <xref format="counter" target="base-begin"/> to <xref format="counter" target="base-end"/> are regular
	ALTO operations, as defined in <xref target="I-D.ietf-alto-protocol"/>. The following section will discuss (and
	at some point hopefully define) the missing pieces of specification needed for performing the remaining steps,
	namely:

	<list style="numbers">
	  <t>
	    a mechanism for identifying the WebSocket URI of the update notification service associated to a particular
	    resource;
	  </t>
	  <t>
	    a mechanism for the client to tell the server the version of the resource stored locally;
	  </t>
	  <t>
	    a mechanism for encoding information updates.
	  </t>
	</list>
      </t>
      <t>
	The mechanism discussed here is intended to allow steps from <xref format="counter" target="upd-begin"/> to
	<xref format="counter" target="upd-end"/> to be executed at an arbitrarily later stage in respect to steps <xref
	format="counter" target="base-begin"/>-<xref format="counter" target="base-end"/> (i.e. the mechanism needs to
	be able to update arbitrarily stale resource representations).
      </t>
    </section>

    <section title="Information Resource Directory (IRD) Extensions">
      <t>
	[NOTE: strawman proposal.]
      </t>
      <t>
	This document specifies the additional optional "updates" property for top-level IRD entries. The new property
	is specifically defined as:

	<list style='hanging'>
	  <t hangText="updates">
	    A WebSocket URI as defined in <xref target="RFC6455"/> at which the ALTO server provides dynamic updates of
	    the corrensponding resource.
	  </t>
	</list>
      </t>      

      <section title="Example">
	<t>
	  The following is an example Information Resource Directory returned by an ALTO Server.  In this example, the
	  ALTO Server provides both a network map and a cost map with corrensponding update notification services.
	</t>
	<figure>
	  <artwork align="left">
	    <![CDATA[
   {
     "resources" : [
       .
       .
       .
       {
         "uri" : "http://alto.example.com/networkmap",
         "media-types" : [ "application/alto-networkmap+json" ],
	 "updates" : "ws://alto.example.com/networkmap"
       }, {
         "uri" : "http://alto.example.com/costmap/num/routingcost",
         "media-types" : [ "application/alto-costmap+json" ],
         "capabilities" : {
           "cost-modes" : [ "numerical" ],
           "cost-types" : [ "routingcost" ]
         },
	 "updates" : "ws://alto.example.com/costmap/num/routingcost"
       }
     ]
   }
	    ]]>
	  </artwork>
	</figure>

      </section>
    </section>

    <section title="Client-to-server Version Indication">
      <t>
	As discussed in <xref target="I-D.schwan-alto-incr-updates"/>, indication of the version of the locally stored
	resource can happen in two ways:
	<list style="symbols">
	  <t>
	    after the WebSocket connection has been established, with an ad-hoc client-to-server signalling message such
	    as:
	    <list style="empty">
	      <t>
		{"reference-tag": "1266506140"}
	      </t>
	    </list>
	    The main drawback of such an approach consists with the added complexity both on the client side and on the
	    server side (e.g. for handling error conditions, race conditions, etc.);
	  </t>
	  <t>
	    in the WebSocket connection initiating GET request, by means of a HTTP header fields such as
	    If-Modified-Since or If-None-Match. The advantage of such an approach consists with the fact that the data
	    on the WebSocket connection flows on the server-to-client direction only, adding no additional complexity to
	    a client already able to process partial updates. The drawback consists with the fact that none of the
	    existing HTTP headers seem to have the exact required semantic.
	  </t>
	</list>
      </t>
    </section>

    <section title="Partial Updates Encoding">
      <t>
	Possible encoding options for partial updates are discussed in <xref target="I-D.schwan-alto-incr-updates"/>,
	for the case of client-initiated transactions. The very same considerations also apply to the case of
	server-initiated notifications. It seems therefore straightforward to assume that the same encoding will be
	adopted here.
      </t>
    </section>

    <section title="Example">
      <t>
	[TODO: Illustrate a full example, from the IRD, the retrievial of the resource and the establishment of the WS
	connection.]
      </t>
    </section>

    <section title="Security Considerations">
      <t>
	[TODO: A lot to be said here.]
      </t>
    </section>

  </middle>

  <back>

    <references title="Normative References">

      &RFC2119;

      &RFC6455;

      &I-D.ietf-alto-protocol;

    </references>

    <references title="Informative References">

      &RFC5693;

      &I-D.schwan-alto-incr-updates;

    </references>

  </back>
</rfc>