idnits 2.17.1 draft-marocco-alto-next-00.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 (January 20, 2012) is 4451 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5693' is defined on line 382, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-dulinski-alto-inter-problem-statement-01 == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-10 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: Informational V. Gurbani 5 Expires: July 23, 2012 Bell Laboratories, 6 Alcatel-Lucent 7 January 20, 2012 9 Extending the Application-Layer Traffic Optimization (ALTO) Protocol 10 draft-marocco-alto-next-00 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 primary use case for the ALTO 19 protocol was peer-to-peer applications for file sharing, video 20 streaming and realtime communications, usually running on end-user 21 devices. However, a number of other applications executing in more 22 controlled environments may also benefit from the information that 23 can be exported through the ALTO protocol. The use cases that have 24 received significant attention include Content Delivery Networks 25 (CDNs), distributed applications running in large datacenters, as 26 well as systems made of inter-communicating ALTO servers. 28 To apply ALTO to these new use cases, this document aims to foster a 29 discussion to determine if, and how, the ALTO protocol could be 30 extended to provide a simple yet useful view of a computational 31 environment that goes beyond the static (or near static) network 32 topology and cost map information. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 23, 2012. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 69 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.1. Content Delivery Networks (CDNs) . . . . . . . . . . . . . 5 71 2.2. Virtualized Applications in Datacenters . . . . . . . . . 6 72 2.3. ALTO Server-to-server Communications . . . . . . . . . . . 6 73 3. New Protocol Features . . . . . . . . . . . . . . . . . . . . 6 74 3.1. Server-initiated Notifications . . . . . . . . . . . . . . 7 75 3.2. ALTO Information Extensions . . . . . . . . . . . . . . . 8 76 3.2.1. Bandwidth Availability Between Hosts . . . . . . . . . 9 77 3.2.2. Resource Availability on Hosts . . . . . . . . . . . . 9 78 3.2.3. Content Availability on Hosts . . . . . . . . . . . . 9 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 5.1. Normative References . . . . . . . . . . . . . . . . . . . 10 82 5.2. Informative References . . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 The Application-Layer Traffic Optimization (ALTO) protocol is 88 designed to allow entities with knowledge about the network 89 infrastructure to export such information to applications that need 90 to choose one or more endpoints to connect to among large sets of 91 logically equivalent ones. The primary use case for the ALTO 92 protocol was peer-to-peer applications for file sharing, video 93 streaming and realtime communications, usually running on end-user 94 devices. However, a number of other applications executing in more 95 controlled environments may also benefit from the information that 96 can be exported through the ALTO protocol. The use cases that have 97 received significant attention include Content Delivery Networks 98 (CDNs), distributed applications running in large datacenters, as 99 well as systems made of inter-communicating ALTO servers. 101 Such applications require information about the underlying 102 infrastructure that goes beyond network topology and associated 103 costs. We believe that the ALTO protocol can be easily extended to 104 provide this information. 106 The basic idea is to use the ALTO protocol to present a simplified 107 view of a computational environment, aggregating with some level of 108 abstraction and approximation information that at a fine-grained 109 level may be conveyed by protocols like OSPF, ISIS, BGP, SNMP, ECN, 110 and ConEx. 112 To provide such kind of information the ALTO protocol need to be 113 extended on several axes: 115 o a means for providing incremental updates to optimize for 116 frequently changing information; 118 o a means for providing integrity protection for the information 119 provided by an ALTO server, in order to enable information 120 redistribution; 122 o a server-initiated notification mechanism, for promptly informing 123 applications of status changes; 125 o different types of information, not only related to network costs, 126 such as: 128 * network link load; 130 * server load; 131 * availability of resources such as storage memory, content and 132 installed applications. 134 Detail-level and timescale of the additional information that can be 135 provided are an open topic of discussion. If on the one hand 136 applications may not take any advantage of too coarse-grained 137 infromation, on the other hand ALTO protocol extensions cannot 138 satisfy all the requirements of the mechanisms that today make full 139 use of such low level information and therefore must not be intended 140 in any way as a replacement for them. The goal of this document is 141 to frame the discussion of what could be reasonable compromises for 142 exporting information of the underlying network and computational 143 infrastructure to applications that need to make best use of it. 145 1.1. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 2. Use Cases 153 2.1. Content Delivery Networks (CDNs) 155 CDNs consist of systems of caching servers that cooperate in the 156 distribution of frequently requested content. When a client wants to 157 access some content, the request is directed by the CDN routing logic 158 to the most appropriate caching server. The criteria for selecting 159 the most appropriate server can be arbitrary complex and depend of 160 information such as: 162 o network distance betwen the querying client and the caching 163 server; 165 o load of the caching server, e.g. in terms of number of concurrent 166 requests or available serving capacity measured over a recent 167 timeframe; 169 o content availability; 171 o storage capacity availablity, for deciding whether to replicate 172 some content on servers that do not have it yet. 174 2.2. Virtualized Applications in Datacenters 176 Applications running on virtual servers in large datacenters require 177 dynamic allocation of resources such as computation power, storage 178 capacity and network bandwidth. Datacenter management logic allocate 179 the resources of physycal servers to such applications based on 180 information such as: 182 o resource availability on the physycal servers; 184 o application code and configurations availability on the physycal 185 servers; 187 o network connectivity quality (i.e. delay and expected throughput) 188 between the physycal servers the virtual server is already running 189 on, and the new physycal servers the additional resources may be 190 allocated from. 192 2.3. ALTO Server-to-server Communications 194 ALTO servers can improve the guidance they provide by aggregating 195 information distributed by other servers (see 196 [I-D.medved-alto-svr-apis] and 197 [I-D.dulinski-alto-inter-problem-statement]). In such scenarios, for 198 the model to be effective, at any point in time all servers need to 199 have a fresh version of the information distributed by the servers 200 they are communicating with, regardless of the type of information 201 distributed. However, the frequency of changes increases with the 202 number of communicating servers, and the faster the information 203 changes, the less the pull-based approach of the base ALTO protocol 204 [I-D.ietf-alto-protocol] is suitable for maintaining an updated 205 representation of the environment status. 207 3. New Protocol Features 209 This section discusses some extensions to the ALTO protocol that can 210 be used to cover the use cases described in Section 2. Such 211 extensions include: 213 o incremental updates for the network and cost maps defined in the 214 base ALTO protocol [I-D.ietf-alto-protocol], for the CDN, 215 datacenter and server-to-server use cases, to enable efficient 216 transmission of status changes; 218 o integrity protection, for the server-to-server use case, to enable 219 servers assert the authenticity of data re-distributed by other 220 servers; 222 o a mechanism for server-initiated notifications, for the CDN, 223 datacenters and server-to-server use cases, to enable a fast 224 propagation of the status changes; 226 o new types of information for the ALTO protocol, for the CDN and 227 datacenters use cases, to provide a representation of the 228 computational environment that goes beyond the network topology. 230 Incremental updates and integrity protection are easily defined on 231 the basis of existing (ongoing) work, namely [I-D.pbryan-json-patch] 232 and [I-D.jones-json-web-signature]. The remainder of this section 233 discusses the other, perhaps more controversial extensions. 235 3.1. Server-initiated Notifications 237 The base ALTO protocol [I-D.ietf-alto-protocol] defines a JSON-based 238 syntax to be conveyed statelessly over HTTP. Such a lightweight 239 approach has several advantages and is considered most appropriate 240 for the use case of peer-to-peer applications, where the information 241 is likely to be retrieved and consumed by huge numbers of clients. 242 However, in more controlled environment, the same information, with 243 the same or an equivalent syntax, can also be conveyed by different 244 protocols, such as XMPP, SIP, or by any protocol with publish/ 245 subscribe capabilities that would allow servers to send updates to 246 subscribed clients. 248 As an example, if an ALTO service provider wanted to make cost 249 maps available also through XMPP (assuming some kind of 250 specification for ALTO-over-XMPP exists), it could simply 251 advertize the proper URI in the information resource directory 252 along with the basic HTTP one: 254 { 255 "resources" : [ 256 { 257 "uri" : "http://alto.example.com/serverinfo", 258 "media-types" : [ "application/alto-serverinfo+json" ] 259 }, { 260 "uri" : "http://alto.example.com/networkmap", 261 "media-types" : [ "application/alto-networkmap+json" ] 262 }, { 263 "uri" : "http://alto.example.com/costmap/num/routingcost", 264 "media-types" : [ "application/alto-costmap+json" ], 265 "additional-uris" : [ "xmpp:routingcost@alto.example.com" ], 266 "capabilities" : { 267 "cost-modes" : [ "numerical" ], 268 "cost-types" : [ "routingcost" ] 269 } 270 }, { 271 "uri" : "http://alto.example.com/costmap/num/hopcount", 272 "media-types" : [ "application/alto-costmap+json" ], 273 "additional-uris" : [ "xmpp:hopcount@alto.example.com" ], 274 "capabilities" : { 275 "cost-modes" : [ "numerical" ], 276 "cost-types" : [ "hopcount" ] 277 } 278 }, 279 . 280 . 281 . 282 ] 283 } 285 3.2. ALTO Information Extensions 287 The base ALTO protocol [I-D.ietf-alto-protocol] has been designed to 288 be easily extended, in terms of both endpoint properties and path 289 cost types. The reminder of this section discusses the types of 290 information that are required by the use cases described in Section 2 291 and that would allow an ALTO servers to expose an abstract 292 representation of a computational environment beyond the simple 293 network topology. 295 3.2.1. Bandwidth Availability Between Hosts 297 Bandwidth availability is a kind of information that changes 298 instantaneously and strictly depends on applications behavior. For 299 such (and other) reasons, conveying it for congestion control other 300 than in-band within the data flows may result useless at best, if not 301 the cause of detrimental feedback loops. 303 However, some notion of link bandwidth availability averaged over a 304 reasonabe timeframe may be effectively used by CDN or datacenter 305 applications to select well-connected pairs or groups of hosts that 306 have to perform bandwidth-demanding tasks. 308 Information about bandwidth availability can be defined for encoding 309 in the ALTO protocol as a new path cost type. 311 3.2.2. Resource Availability on Hosts 313 Information about storage and computational capacity availability 314 averaged over a reasonable timeframe may be effectively used by CDN 315 and datacenter applications as one of the criteria for selecting 316 hosts for serving content or performing tasks. 318 Information about resource availability can be defined for encoding 319 in the ALTO protocol as a new endpoint property. 321 3.2.3. Content Availability on Hosts 323 Information about content availability can be expressed as lists of 324 URIs (e.g. for identifying stored files in CDN caching servers), URNs 325 or other kinds of identifiers (e.g. for identifying installed 326 applications on physycal servers in a datacenter). 328 Information about content availability can be defined for encoding in 329 the ALTO protocol as a new endpoint property. 331 4. Security Considerations 333 The information types discussed in this document are likely to be 334 privacy critical in many environment and therefore must be protected, 335 restricting or controlling access to the servers that export them. 337 Server initiated notification requires more resources than the 338 stateless retrivial model adopted by the base ALTO protocol 339 [I-D.ietf-alto-protocol] and is more thus more vulnerable to denial 340 of service attacks. 342 Access control mechanisms, including HTTP's, may be valid options for 343 addressing the security issues related to both privacy critical 344 information types and resource-consuming server notifications. 346 5. References 348 5.1. Normative References 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, March 1997. 353 5.2. Informative References 355 [I-D.dulinski-alto-inter-problem-statement] 356 Dulinski, Z., Wydrych, P., and R. Stankiewicz, "Inter-ALTO 357 Communication Problem Statement", 358 draft-dulinski-alto-inter-problem-statement-01 (work in 359 progress), July 2011. 361 [I-D.ietf-alto-protocol] 362 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 363 draft-ietf-alto-protocol-10 (work in progress), 364 October 2011. 366 [I-D.jones-json-web-signature] 367 Jones, M., Balfanz, D., Bradley, J., Goland, Y., Panzer, 368 J., Sakimura, N., and P. Tarjan, "JSON Web Signature 369 (JWS)", draft-jones-json-web-signature-04 (work in 370 progress), December 2011. 372 [I-D.medved-alto-svr-apis] 373 Medved, J., Ward, D., Peterson, J., Woundy, R., and D. 374 McDysan, "ALTO Network-Server and Server-Server APIs", 375 draft-medved-alto-svr-apis-00 (work in progress), 376 March 2011. 378 [I-D.pbryan-json-patch] 379 Bryan, P., "JSON Patch", draft-pbryan-json-patch-04 (work 380 in progress), December 2011. 382 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 383 Optimization (ALTO) Problem Statement", RFC 5693, 384 October 2009. 386 Authors' Addresses 388 Enrico Marocco 389 Telecom Italia 390 Via Reiss Romoli, 274 391 Torino, 10148 392 Italy 394 Phone: 395 Email: enrico.marocco@telecomitalia.it 397 Vijay K. Gurbani 398 Bell Laboratories, Alcatel-Lucent 400 Email: vkg@bell-labs.com