idnits 2.17.1 draft-marocco-alto-ws-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 14, 2014) is 3717 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'EDITORIAL NOTE' is mentioned on line 136, but not defined == Unused Reference: 'RFC5693' is defined on line 301, but no explicit reference was found in the text == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-25 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Marocco 3 Internet-Draft Telecom Italia 4 Intended status: Standards Track J. Seedorf 5 Expires: August 18, 2014 NEC 6 February 14, 2014 8 WebSocket-based server-to-client notifications for the Application-Layer 9 Traffic Optimization (ALTO) Protocol 10 draft-marocco-alto-ws-02 12 Abstract 14 The Application-Layer Traffic Optimization (ALTO) protocol is 15 designed to allow entities with knowledge about the network 16 infrastructure to export such information to applications that need 17 to choose one or more endpoints to connect to among large sets of 18 logically equivalent ones. The base protocol specification adopts a 19 simple pull-based model, according to which the client retrieves the 20 information encoded as JSON objects over HTTP directly from the 21 server. 23 This document proposes (for discussion) a mechanism for providing 24 server-initiated information update notifications through a 25 WebSocket-based ALTO protocol extension that easily integrates in the 26 basic protocol model. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on August 18, 2014. 45 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 64 2. Overview of operations . . . . . . . . . . . . . . . . . . . 4 65 3. Information Resource Directory (IRD) Extensions . . . . . . . 5 66 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Client-to-server Version Indication . . . . . . . . . . . . . 6 68 5. Partial Updates Encoding . . . . . . . . . . . . . . . . . . 6 69 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 71 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 74 9.2. Informative References . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 The Application-Layer Traffic Optimization (ALTO) protocol 80 [I-D.ietf-alto-protocol] is designed to allow entities with knowledge 81 about the network infrastructure to export such information to 82 applications that need to choose one or more endpoints to connect to 83 among large sets of logically equivalent ones. The base protocol 84 specification adopts a simple pull-based model, according to which 85 the client retrieves the information encoded as JSON objects over 86 HTTP directly from the server. 88 Such a pull-based model is well suited for use cases where the 89 information does not change frequently, e.g. when it represents 90 network and cost maps intended to provide a hint to peer-to-peer 91 applications that have to perform initial peer selection (i.e. the 92 primary use case that motivated the specification of the ALTO 93 protocol). However, over the years several similar use cases have 94 emerged, most of them with more stringent requirements in terms of 95 information freshness. Those use cases could also simply and 96 effectively be addressed by the ALTO protocol, provided it features a 97 mechanism for clients to receive server-initiated information update 98 notifications. This document proposes (for discussion) a mechanism 99 for providing such notifications through a WebSocket-based [RFC6455] 100 extension that easily integrates in the basic ALTO protocol model. 102 The WebSocket protocol is only one option such an extension could be 103 based on. Many alternatives can of course be considered, based on 104 virtually any bi-directional protocol that provides some sort of 105 publish/subscribe framework. Among others, XMPP, BGP and SNMP have 106 been proposed and to some extent discussed in different contexts as a 107 basis for providing similar features. The strong points of the 108 WebSocket protocol in this context -- and thus the reason why the 109 extension proposed here is based on it -- include: 111 o WebSocket is explicitly intended to provide bi-directionality to 112 HTTP, the transport the ALTO protocol is based on. The main 113 implication of this fact is that both the HTTP client and server 114 libraries/frameworks that ALTO implementations are based on will 115 natively support it (or, since the technology is very new, soon 116 will); 118 o a resource representing an update notification service related to 119 a particular resource instance made available by an ALTO server 120 can simply be identified by a WebSocket URI and advertized in the 121 Information Resource Directory (IRD) just as any other regular 122 resource; 124 o a resource representing an update notification service can be 125 unambiguously defined through a MIME type, just as any other 126 regular resource; 128 o reuse of HTTP authentication. 130 o [TODO: Is Origin-based security of any use here?] 132 The most appropriate way for encoding partial updates of ALTO 133 information is an open issue itself, at the time of writing, 134 discussed in [I-D.schwan-alto-incr-updates]. 136 [EDITORIAL NOTE] This version of the document is identical with the 137 expired, previous (-01) version. The reason is that the IETF ALTO WG 138 had decided to postpone any discussion of extensions to the base ALTO 139 for several IETF meetings. Now that such discussion regarding ALTO 140 extensions and regarding an updated ALTO charter are finally taking 141 place, the authors of this document decided to re-post it. 143 1.1. Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [RFC2119]. 149 2. Overview of operations 151 When an ALTO client wants to retrieve a particular piece of 152 information made available by an ALTO server and then receive 153 notifications about each subsequent change, it achieves that in the 154 following steps: 156 1. retrieve the IRD of the ALTO service it is going to access; 158 2. find in the IRD the URI of the resource it is interested in, 159 identifying it through the associated content type (e.g. 160 application/alto-networkmap+json); 162 3. retrieve a copy of the resource it is interested in; 164 4. find in the IRD the WebSocket URI of the update notification 165 service associated to the specific resource just retrieved; 167 5. establish a WebSocket connection against the URI of the update 168 notification service; 170 6. indicate the version tag of the retrieved resource to the server; 172 7. process each subsequent updates received on the WebSocket 173 connection in order to keep the local representation of the 174 recource up-to-date. 176 Steps 1 to 3 are regular ALTO operations, as defined in 177 [I-D.ietf-alto-protocol]. The following section will discuss (and at 178 some point hopefully define) the missing pieces of specification 179 needed for performing the remaining steps, namely: 181 1. a mechanism for identifying the WebSocket URI of the update 182 notification service associated to a particular resource; 184 2. a mechanism for the client to tell the server the version of the 185 resource stored locally; 187 3. a mechanism for encoding information updates. 189 The mechanism discussed here is intended to allow steps from 4 to 7 190 to be executed at an arbitrarily later stage in respect to steps 1-3 191 (i.e. the mechanism needs to be able to update arbitrarily stale 192 resource representations). 194 3. Information Resource Directory (IRD) Extensions 196 [NOTE: strawman proposal.] 198 This document specifies the additional optional "updates" property 199 for top-level IRD entries. The new property is specifically defined 200 as: 202 updates A WebSocket URI as defined in [RFC6455] at which the ALTO 203 server provides dynamic updates of the corresponding resource. 205 3.1. Example 207 The following is an example Information Resource Directory returned 208 by an ALTO Server. In this example, the ALTO Server provides both a 209 network map and a cost map with corresponding update notification 210 services. 212 { 213 "resources" : [ 214 . 215 . 216 . 217 { 218 "uri" : "http://alto.example.com/networkmap", 219 "media-types" : [ "application/alto-networkmap+json" ], 220 "updates" : "ws://alto.example.com/networkmap" 221 }, { 222 "uri" : "http://alto.example.com/costmap/num/routingcost", 223 "media-types" : [ "application/alto-costmap+json" ], 224 "capabilities" : { 225 "cost-modes" : [ "numerical" ], 226 "cost-types" : [ "routingcost" ] 227 }, 228 "updates" : "ws://alto.example.com/costmap/num/routingcost" 229 } 230 ] 231 } 233 4. Client-to-server Version Indication 235 As discussed in [I-D.schwan-alto-incr-updates], indication of the 236 version of the locally stored resource can happen in two ways: 238 o after the WebSocket connection has been established, with an ad- 239 hoc client-to-server signalling message such as: 241 {"reference-tag": "1266506140"} 243 The main drawback of such an approach consists with the added 244 complexity both on the client side and on the server side (e.g. 245 for handling error conditions, race conditions, etc.); 247 o in the WebSocket connection initiating GET request, by means of a 248 HTTP header field such as If-Modified-Since or If-None-Match. The 249 advantage of such an approach consists of the fact that the data 250 on the WebSocket connection flows on the server-to-client 251 direction only, adding no additional complexity to a client 252 already able to process partial updates. The drawback is that 253 none of the existing HTTP headers seem to have the exact required 254 semantic. 256 5. Partial Updates Encoding 258 Possible encoding options for partial updates are discussed in 259 [I-D.schwan-alto-incr-updates], for the case of client-initiated 260 transactions. The very same considerations also apply to the case of 261 server-initiated notifications. It seems therefore straightforward 262 to assume that the same encoding will be adopted here. 264 6. Example 266 [TODO: Illustrate a full example, from the IRD, the retrieval of the 267 resource and the establishment of the WS connection.] 269 7. Security Considerations 271 [TODO: A lot to be said here.] 273 8. Conclusion 275 This document discusses an extension to the ALTO protocol to allow 276 for server-initiated information update notifications. Specifically, 277 a WebSocket-based ALTO protocol extension is proposed that easily 278 integrates in the basic protocol model. 280 9. References 282 9.1. Normative References 284 [I-D.ietf-alto-protocol] 285 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- 286 ietf-alto-protocol-25 (work in progress), January 2014. 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, March 1997. 291 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 292 6455, December 2011. 294 9.2. Informative References 296 [I-D.schwan-alto-incr-updates] 297 Schwan, N. and B. Roome, "ALTO Incremental Updates", 298 draft-schwan-alto-incr-updates-02 (work in progress), July 299 2012. 301 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 302 Optimization (ALTO) Problem Statement", RFC 5693, October 303 2009. 305 Authors' Addresses 307 Enrico Marocco 308 Telecom Italia 309 Via Reiss Romoli, 274 310 Torino 10148 311 Italy 313 Email: enrico.marocco@telecomitalia.it 315 Jan Seedorf 316 NEC Laboratories Europe, NEC Europe Ltd. 317 Kurfuersten-Anlage 36 318 Heidelberg 69115 319 Germany 321 Phone: +49 (0) 6221 4342 221 322 Email: jan.seedorf@neclab.eu 323 URI: http://www.neclab.eu