Internet Engineering Task Force E. Marocco
Internet-Draft Telecom Italia
Intended status: Standards Track J. Seedorf
Expires: December 31, 2012 NEC
July 2012

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

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 December 31, 2012.

Copyright Notice

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

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

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

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:

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 [base-begin] to [base-end] are regular ALTO operations, as defined in [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:

  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 [upd-begin] to [upd-end] to be executed at an arbitrarily later stage in respect to steps [base-begin]-[base-end] (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 corrensponding 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 corrensponding update notification services.

	    
   {
     "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:

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 retrievial of the resource and the establishment of the WS connection.]

7. Security Considerations

[TODO: A lot to be said here.]

8. References

8.1. Normative References

[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.
[I-D.ietf-alto-protocol] Alimi, R, Penno, R and Y Yang, "ALTO Protocol", Internet-Draft draft-ietf-alto-protocol-11, March 2012.

8.2. Informative References

[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009.
[I-D.schwan-alto-incr-updates] Schwan, N and B Roome, "ALTO Incremental Updates", Internet-Draft draft-schwan-alto-incr-updates-01, March 2012.

Authors' Addresses

Enrico Marocco Telecom Italia Via Reiss Romoli, 274 Torino, 10148 Italy 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@nw.neclab.eu URI: http://www.nw.neclab.eu