[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
Internet Engineering Task Force                               E. Marocco
Internet-Draft                                            Telecom Italia
Intended status: Standards Track                              J. Seedorf
Expires: January 17, 2013                                            NEC
                                                           July 16, 2012


WebSocket-based server-to-client notifications for the Application-Layer
                  Traffic Optimization (ALTO) Protocol
                        draft-marocco-alto-ws-01

Abstract

   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.

   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.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 17, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Marocco & Seedorf       Expires January 17, 2013                [Page 1]


Internet-Draft        WebSocket transport for ALTO             July 2012


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 4
   2.  Overview of operations  . . . . . . . . . . . . . . . . . . . . 4
   3.  Information Resource Directory (IRD) Extensions . . . . . . . . 5
     3.1.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Client-to-server Version Indication . . . . . . . . . . . . . . 6
   5.  Partial Updates Encoding  . . . . . . . . . . . . . . . . . . . 7
   6.  Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   8.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
























Marocco & Seedorf       Expires January 17, 2013                [Page 2]


Internet-Draft        WebSocket transport for ALTO             July 2012


1.  Introduction

   The Application-Layer Traffic Optimization (ALTO) protocol
   [I-D.ietf-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.

   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, 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 WebSocket-based [RFC6455]
   extension that easily integrates in the basic ALTO protocol model.

   The WebSocket protocol is only one option such an extension could be
   based on.  Many alternatives 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 strong points of the
   WebSocket protocol in this context -- and thus the reason why the
   extension proposed here is based on it -- include:

   o  WebSocket is explicitly intended to provide bi-directionality to
      HTTP, the transport the ALTO protocol is based on.  The main
      implication of this fact is that both the HTTP client and server
      libraries/frameworks that ALTO implementations are based on will
      natively support it (or, since the technology is very new, soon
      will);

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





Marocco & Seedorf       Expires January 17, 2013                [Page 3]


Internet-Draft        WebSocket transport for ALTO             July 2012


   o  a resource representing an update notification service can be
      unambiguously defined through a MIME type, just as any other
      regular resource;

   o  reuse of HTTP authentication.

   o  [TODO: Is Origin-based security of any use here?]

   The most appropriate way for encoding partial updates of ALTO
   information is an open issue itself, at the time of writing,
   discussed in [I-D.schwan-alto-incr-updates].

1.1.  Requirements Language

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


2.  Overview of operations

   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:

   1.  retrieve the IRD of the ALTO service it is going to access;

   2.  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);

   3.  retrieve a copy of the resource it is interested in;

   4.  find in the IRD the WebSocket URI of the update notification
       service associated to the specific resource just retrieved;

   5.  establish a WebSocket connection against the URI of the update
       notification service;

   6.  indicate the version tag of the retrieved resource to the server;

   7.  process each subsequent updates received on the WebSocket
       connection in order to keep the local representation of the
       recource up-to-date.

   Steps 1 to 3 are regular ALTO operations, as defined in
   [I-D.ietf-alto-protocol].  The following section will discuss (and at



Marocco & Seedorf       Expires January 17, 2013                [Page 4]


Internet-Draft        WebSocket transport for ALTO             July 2012


   some point hopefully define) the missing pieces of specification
   needed for performing the remaining steps, namely:

   1.  a mechanism for identifying the WebSocket URI of the update
       notification service associated to a particular resource;

   2.  a mechanism for the client to tell the server the version of the
       resource stored locally;

   3.  a mechanism for encoding information updates.

   The mechanism discussed here is intended to allow steps from 4 to 7
   to be executed at an arbitrarily later stage in respect to steps 1-3
   (i.e. the mechanism needs to be able to update arbitrarily stale
   resource representations).


3.  Information Resource Directory (IRD) Extensions

   [NOTE: strawman proposal.]

   This document specifies the additional optional "updates" property
   for top-level IRD entries.  The new property is specifically defined
   as:

   updates  A WebSocket URI as defined in [RFC6455] at which the ALTO
      server provides dynamic updates of the corresponding resource.

3.1.  Example

   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 corresponding update notification
   services.

















Marocco & Seedorf       Expires January 17, 2013                [Page 5]


Internet-Draft        WebSocket transport for ALTO             July 2012


      {
        "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"
          }
        ]
      }



4.  Client-to-server Version Indication

   As discussed in [I-D.schwan-alto-incr-updates], indication of the
   version of the locally stored resource can happen in two ways:

   o  after the WebSocket connection has been established, with an ad-
      hoc client-to-server signalling message such as:

         {"reference-tag": "1266506140"}

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

   o  in the WebSocket connection initiating GET request, by means of a
      HTTP header field such as If-Modified-Since or If-None-Match.  The
      advantage of such an approach consists of 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 is that
      none of the existing HTTP headers seem to have the exact required
      semantic.






Marocco & Seedorf       Expires January 17, 2013                [Page 6]


Internet-Draft        WebSocket transport for ALTO             July 2012


5.  Partial Updates Encoding

   Possible encoding options for partial updates are discussed in
   [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.


6.  Example

   [TODO: Illustrate a full example, from the IRD, the retrieval of the
   resource and the establishment of the WS connection.]


7.  Security Considerations

   [TODO: A lot to be said here.]


8.  Conclusion

   This document discusses an extension to the ALTO protocol to allow
   for server-initiated information update notifications.  Specifically,
   a WebSocket-based ALTO protocol extension is proposed that easily
   integrates in the basic protocol model.


9.  References

9.1.  Normative References

   [I-D.ietf-alto-protocol]
              Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
              draft-ietf-alto-protocol-12 (work in progress), July 2012.

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

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
              RFC 6455, December 2011.

9.2.  Informative References

   [I-D.schwan-alto-incr-updates]
              Schwan, N. and B. Roome, "ALTO Incremental Updates",
              draft-schwan-alto-incr-updates-01 (work in progress),
              March 2012.



Marocco & Seedorf       Expires January 17, 2013                [Page 7]


Internet-Draft        WebSocket transport for ALTO             July 2012


   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement", RFC 5693,
              October 2009.


Authors' Addresses

   Enrico Marocco
   Telecom Italia
   Via Reiss Romoli, 274
   Torino,   10148
   Italy

   Phone:
   Email: enrico.marocco@telecomitalia.it


   Jan Seedorf
   NEC Laboratories Europe, NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg,   69115
   Germany

   Phone: +49 (0) 6221 4342 221
   Email: jan.seedorf@neclab.eu
   URI:   http://www.neclab.eu

























Marocco & Seedorf       Expires January 17, 2013                [Page 8]