idnits 2.17.1 draft-seedorf-cdni-fci-alto-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 date (October 21, 2013) is 3834 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line 616, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-cdni-use-cases' is defined on line 621, but no explicit reference was found in the text == Unused Reference: 'I-D.liu-cdni-cost' is defined on line 653, but no explicit reference was found in the text -- No information found for draft-peterson-CDNI-strawman - is the name correct? == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-20 == Outdated reference: A later version (-17) exists of draft-ietf-cdni-requirements-11 == Outdated reference: A later version (-02) exists of draft-marocco-alto-ws-01 == Outdated reference: A later version (-14) exists of draft-ietf-cdni-framework-06 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CDNI J. Seedorf 3 Internet-Draft NEC 4 Intended status: Informational Y. Yang 5 Expires: April 24, 2014 Yale 6 October 21, 2013 8 CDNI Footprint and Capabilities Advertisement using ALTO 9 draft-seedorf-cdni-fci-alto-00 11 Abstract 13 Network Service Providers (NSPs) are currently considering to deploy 14 Content Delivery Networks (CDNs) within their networks. As a 15 consequence of this development, there is a need for interconnecting 16 these local CDNs. The necessary interfaces for inter-connecting CDNs 17 are currently being defined in the Content Delivery Networks 18 Interconnection (CDNI) WG. This document focuses on the CDNI 19 Footprint & Capabilities Advertisement interface (FCI). 20 Specifically, this document outlines how the solutions currently 21 being defined in the Application Layer Traffic Optimization (ALTO) WG 22 can facilitate Footprint & Capabilities Advertisement in a CDNI 23 context, i.e. how the CDNI FCI can be realised with the ALTO 24 protocol. Concrete examples of how ALTO can be integrated within 25 CDNI request routing and in particular in the process of selecting a 26 downstream CDN are given. The examples in this document are based on 27 the use cases and examples currently being discussed in the CDNI WG. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 24, 2014. 46 Copyright Notice 47 Copyright (c) 2013 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 2. ALTO within CDNI Request Routing . . . . . . . . . . . . . . 3 64 3. Assumptions and High-Level Design Considerations . . . . . . 4 65 3.1. General Assumptions and Consideration . . . . . . . . . . 4 66 3.2. Semantics for Footprint/Capabilities Advertisment . . . . 5 67 4. Selection of a Downstream CDN with ALTO . . . . . . . . . . . 7 68 4.1. Footprint and Capabilities Advertisement using ALTO 69 Network Map and PID Properties . . . . . . . . . . . . . 7 70 4.2. Conveying additional information with ALTO Cost Maps . . 8 71 4.3. Example of Selecting a Downstream CDN based on ALTO Maps 9 72 4.4. Advantages of using ALTO . . . . . . . . . . . . . . . . 10 73 5. Useful ALTO extensions for CDNI Request Routing . . . . . . . 10 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 7. Summary and Outlook . . . . . . . . . . . . . . . . . . . . . 12 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 79 9.2. Informative References . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 Many Network Service Providers (NSPs) are currently considering or 85 have already started to deploy Content Delivery Networks (CDNs) 86 within their networks. As a consequence of this development, there 87 is a need for interconnecting these local CDNs. Content Delivery 88 Networks Interconnection (CDNI) has the goal of standardizing 89 protocols to enable such interconnection of CDNs [RFC6707]. 91 The CDNI problem statement [RFC6707] envisions four interfaces to be 92 standardized within the IETF for CDN interconnection: 94 o CDNI Request Routing Interface 95 o CDNI Metadata Interface 97 o CDNI Logging Interface 99 o CDNI Control Interface 101 This document focuses solely on the CDNI Request Routing Interface, 102 which can be further divided into two interfaces (see [RFC6707] for a 103 detailed description): the CDNI Request Routing Redirection interface 104 (RI), and the CDNI Footprint & Capabilities Advertisement interface 105 (FCI). This document presents how one may use ALTO as a protocol for 106 CDNI Footprint & Capabilities Advertisement. Concrete examples of 107 how the CDNI FCI can be implemented with the ALTO protocol 108 [I-D.ietf-alto-protocol] are given. The examples used in this 109 document are based on the use cases and request routing proposals 110 currently being discussed in the CDNI WG [RFC6770] 111 [I-D.peterson-CDNI-strawman] and in the ALTO WG 112 [I-D.jenkins-alto-cdn-use-cases]. 114 A previous version of this document [I-D.seedorf-alto-for-cdni] 115 contained detailed examples of actual request routing and surrogate 116 selection with ALTO, i.e. how ALTO could be used for implementing the 117 CDNI Request Routing Redirection interface (RI). This version solely 118 focuses on implementing the CDNI Footprint & Capabilities 119 Advertisement interface (FCI) with ALTO, i.e. the selection of a 120 downstream CDN and how ALTO can support such downstream CDN 121 selection. 123 Throughout this document, we use the terminology for CDNI defined in 124 [I-D.ietf-cdni-problem-statement]. 126 2. ALTO within CDNI Request Routing 128 The main purpose of the CDNI Request Routing Interface is described 129 in [RFC6707] as follows: "The CDNI Request Routing interface enables 130 a Request Routing function in an Upstream CDN to query a Request 131 Routing function in a Downstream CDN to determine if the Downstream 132 CDN is able (and willing) to accept the delegated Content Request. 133 It also allows the Downstream CDN to control what should be returned 134 to the User Agent in the redirection message by the upstream Request 135 Routing function." On a high level, the scope of the CDNI Request 136 Routing Interface therefore contains two main tasks: 138 o A) Determining if the downstream CDN is willing to accept a 139 delegated content request 141 o B) Redirecting the content request coming from an upstream CDN to 142 the proper entry point or entity in the downstream CDN 144 More precisely, in [I-D.ietf-cdni-framework] the request routing 145 interface is broadly divided into two functionalities: 147 o 1) the asynchronous advertisement of footprint and capabilities by 148 a dCDN that allows a uCDN to decide whether to redirect particular 149 user requests to that dCDN (the CDNI FCI) 151 o 2) the synchronous operation of actually redirecting a user 152 request (the CDNI RI) 154 Application Layer Traffic Optimization (ALTO) is an approach for 155 guiding the resource provider selection process in distributed 156 applications that can choose among several candidate resources 157 providers to retrieve a given resource. By conveying network layer 158 (topology) information, an ALTO server can provide important 159 information to "guide" the resource provider selection process in 160 distributed applications. Usually, it is assumed that an ALTO server 161 conveys information these applications cannot measure themselves 162 [RFC5693]. 164 Originally, ALTO was motivated by the huge amount of cross-ISP 165 traffic generated by P2P applications [RFC5693]. Recently, however, 166 ALTO is also being considered for improving the request routing in 167 CDNs [I-D.jenkins-alto-cdn-use-cases]. In this context, it has also 168 been proposed to use ALTO for selecting an entry-point in a 169 downstream NSP's network (see section 3.4 "CDN delivering Over-The- 170 Top of a NSP's network" in [I-D.jenkins-alto-cdn-use-cases]). Also, 171 the CDNI problem statement explicitly mentions ALTO as a candidate 172 protocol for "algorithms for selection of CDN or Surrogate by 173 Request-Routing systems" [I-D.ietf-cdni-problem-statement]. Yet, 174 there have not been concrete proposals so far on how to use ALTO in 175 the context of CDN interconnection. This document tries to close 176 this gap by giving some examples on how ALTO could be used within 177 CDNI request routing. 179 3. Assumptions and High-Level Design Considerations 181 In this section we list some assumptions and design issues to be 182 considered when using ALTO for the CDNI Footprint and Capabilities 183 Advertisement interface 185 3.1. General Assumptions and Consideration 187 Below we list some general assumptions and considerations: 189 o As explicitly being out-of-scope for CDNI 190 [I-D.ietf-cdni-problem-statement], the examples used in this 191 document assume that ingestion of content or acquiring content 192 across CDNs is not part of request routing as considered within 193 CDNI standardization work. The focus of using ALTO (as considered 194 in this document) is hence on request routing only, assuming that 195 the content (desired by the end user) is available in the 196 downstream CDN (or can be aquired by the downstream CDN by some 197 means). 199 o Federation Model: "Footprint and Capabilities Advertisement" and 200 in general CDN request routing depends on the federation model 201 among the CDN providers. Designing a suitable solution thus 202 depends on whether a solution is needed for different settings, 203 where CDNs consist of both NSP CDNs (serving individual ASes) and 204 general, traditional CDNs (such as Akamai). We assume that CDNI 205 is not designed for a setting where only NSP CDNs each serve a 206 single AS only. 208 o In this document, we assume that the upstream CDN (uCDN) makes the 209 decision on selecting a downstream CDN, based on information that 210 each downstream CDN has made available to the upstream CDN. 211 Further, we assume that in principle more than one dCDN may be 212 suitable for a given end-user request (i.e. different dCDNs may 213 claim "overlapping" footprints). The uCDN hence potentially has 214 to select among several candidate downstream CDNs for a given end 215 user request. 217 o It is not clear what kind(s) of business, contract, and 218 operational relationships two peering CDNs may form. For the 219 Internet, we see provider-customer and peering as two main 220 relations; providers may use different charging models (e.g., 221 95-percentile, total volume) and may provide different SLAs. 222 Given such unknown characteristics of CDN peering business 223 agreements, we should design the protocol to support as much 224 diverse potential business and operational models as possible. 226 3.2. Semantics for Footprint/Capabilities Advertisment 228 The CDNI document on "Footprint and Capabilities Semantics" 229 [I-D.spp-cdni-rr-foot-cap-semantics] defines the semantics for the 230 CDNI FCI. It thus provides guidance on what Footprint and 231 Capabilities mean in a CDNI context and how a protocol solution 232 should in principle look like. Here we briefly summarize the key 233 points of the semantics of Footprint and Capabilities (for a detailed 234 discussion, the reader is referred to 235 [I-D.spp-cdni-rr-foot-cap-semantics]): 237 o Often, footprint and capabilities are tied together and cannot be 238 interpreted independently from each other. In such cases, i.e. 239 where capabilities must be expressed on a per footprint basis, it 240 may be beneficial to combine footprint and capabilities 241 advertisement. 243 o Given that a large part of Footprint and Capabilities 244 Advertisement will actually happen in contractual agreements, the 245 semantics of CDNI Footprint and Capabilities advertisement refer 246 to answering the following question: what exactly still needs to 247 be advertised by the CDNI FCI? For instance, updates about 248 temporal failures of part of a footprint can be useful information 249 to convey via the CDNI request routing interface. Such 250 information would provide updates on information previously agreed 251 in contracts between the participating CDNs. In other words, the 252 CDNI FCI is a means for a dCDN to provide changes/updates 253 regarding a footprint and/or capabilities it has prior agreed to 254 serve in a contract with a uCDN. 256 o It seems clear that "coverage/reachability" types of footprint 257 must be supported within CDNI. The following such types of 258 footprint are mandatory and must be supported by the CDNI FCI: 260 * List of ISO Country Codes 262 * List of AS numbers 264 * Set of IP-prefixes 266 A 'set of IP-prefixes' must be able to contain full IP addresses, 267 i.e., a /32 for IPv4 and a /128 for IPv6, and also IP prefixes 268 with an arbitrary prefix length. There must also be support for 269 multiple IP address versions, i.e., IPv4 and IPv6, in such a 270 footprint. 272 o For all of these mandatory-to-implement footprint types, 273 footprints can be viewed as constraints for delegating requests to 274 a dCDN: A dCDN footprint advertisement tells the uCDN the 275 limitations for delegating a request to the dCDN. For IP prefixes 276 or ASN(s), the footprint signals to the uCDN that it should 277 consider the dCDN a candidate only if the IP address of the 278 request routing source falls within the prefix set (or ASN, 279 respectively). The CDNI specifications do not define how a given 280 uCDN determines what address ranges are in a particular ASN. 281 Similarly, for country codes a uCDN should only consider the dCDN 282 a candidate if it covers the country of the request routing 283 source. The CDNI specifications do not define how a given uCDN 284 determines the country of the request routing source. Multiple 285 footprint constraints are additive, i.e. the advertisement of 286 different types of footprint narrows the dCDN candidacy 287 cumulatively. 289 o The following capabilities seem useful as 'base' capabilities, 290 i.e. ones that are needed in any case and therefore constitute 291 mandatory capabilities to be supported by the CDNI FCI: 293 * Delivery Protocol (e.g., HTTP vs. RTMP) 295 * Acquisition Protocol (for aquiring content from a uCDN) 297 * Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as 298 discussed in [I-D.ietf-cdni-framework]) 300 * Capabilities related to CDNI Logging (e.g., supported logging 301 mechanisms) 303 * Capabilities related to CDNI Metadata (e.g., authorization 304 algorithms or support for proprietary vendor metadata) 306 4. Selection of a Downstream CDN with ALTO 308 Under the considerations stated in Section 3, ALTO can help the 309 upstream CDN provider to select a proper downstream CDN provider for 310 a given end user request as follows: Each downstream CDN provider 311 hosts an ALTO server which provides ALTO information (i.e. ALTO 312 network maps and ALTO cost maps [I-D.ietf-alto-protocol]) to an ALTO 313 client at the upstream CDN provider. Network maps provided by each 314 of several candidate downstream CDNs can provide information to the 315 upstream CDN provider about each dCDN's "coverage/reachability" as 316 well as capabilities. 318 4.1. Footprint and Capabilities Advertisement using ALTO Network Map 319 and PID Properties 321 Conceptually, the foorprint and capabilities interface of a dCDN is 322 easy to specify: It is a function that given an endhost, returns if 323 the dCDN is willing to serve the endhost, and the capabilities 324 available to that endhost (e.g., "delivery-protocol": 325 ["HTTP","RMTP"], "acquisition-protocol": ["HTTP"], "redirection- 326 mode": ["HTTP-redirect"], "loggin-mechanism": ["TBD"], and "meta- 327 capabilities": [""]). 329 Specifiying the preceding for each endhost can be redundant, and one 330 may use PIDs defined in ALTO. Specifically, an ALTO network map 331 contains a "set of Network Location groupings" 332 [I-D.ietf-alto-protocol]. The groupings are defined in the form of 333 so-called "PIDs". A PID is an identifier to group network location 334 endpoints, e.g. IP-addresses in the form of prefixes (see section 4 335 in [I-D.ietf-alto-protocol] for details). 337 Applying the basic idea of ALTO PIDs to the preceding, abstract 338 mapping specification, by aggregating endhosts with the same 339 capabilities in the same PID, we obtain CDNi FCI using ALTO Network 340 Maps as simply (1) a Network Map which defines a set of PIDs, and (2) 341 a PID Property Map [draft-roome-alto-pid-properties ] that defines 342 the properties of each PID, where the properties define the 343 capabilities. 345 With the preceding Network Map and PID Property Map, the upstream CDN 346 provider can easily match a given end user request with the footprint 347 and capabilities of the downstream CDN providers. Whenever the 348 footprint and/or capabilities of a dCDN change, the ALTO server of 349 the dCDN changes its data, and the uCDN can obtain the update through 350 ALTO incremental updates. Future extensions to ALTO to add 351 notifications can be integrated when they become available. 353 In particular, this document does not define how a dCDN aggregates 354 the endhosts into PIDs, to allow flexibility in (anticipated) 355 updates. 357 In this document, we define the following PID properties, which each 358 must be a JSON array, to convey all mandatory capabilities (see 359 Section 3.2): 361 o delivery-protocol 363 o acquisition-protocol 365 o redirection-mode 367 o loggin-mechanism 369 o meta-capabilities 371 To complement the preceding capabilities mapping, we require that an 372 uCDN has access to ALTO Network Map(s) that can map from an endhost 373 to Country Code and AS Number. Such mapping may or may not be 374 specific to CDNI but can be a general mapping. Specifically, the 375 uCDN should have access to ALTO Network Map(s) with Properties 376 include: 378 o country-code 380 o asn 382 4.2. Conveying additional information with ALTO Cost Maps 383 An ALTO cost map contains costs between defined groupings of a 384 corresponding network map (i.e. costs between PIDs): "An ALTO Cost 385 Map defines Path Costs pairwise amongst sets of source and 386 destination Network Locations" [I-D.ietf-alto-protocol]. This 387 concept enables the provider of a cost map to express (and quantify) 388 preferences of a destination network location with respect to a given 389 source network location. 391 In the context of CDNI, the ALTO cost map concept is an extensive 392 tool to convey additional information about the footprint or 393 capabilties of a downstream CDN. The cost map concept provides a 394 means for a downstream CDN provider to convey numeric values 395 associated with a PID, e.g. in order to convey metrics associated 396 with a footprint or a capability. This may be useful for future, 397 non-mandatory types of footprint or capabilties. 399 One way to use ALTO cost maps would have these maps of the type 400 N-to-m, i.e. 'costs' are expressed for each of N end user source PIDs 401 to m dCDN request router PIDs. Semantically, a source PID in a CDNI 402 ALTO cost map is thus the end user location, whereas a destination 403 PID is a (group of) request router(s) to which the uCDN redirects the 404 end user request. Note that this perspective is driven by the CDNI 405 request routing. An alternative way - seen from the perspective of 406 content retrieval - would be to have a m-to-N cost map where the 407 source is always the dCDN and the destination is the end user (with 408 the semantic "if the source dCDN would deliver content to an end user 409 in the destination PID, the costs would be the following). With 410 explicit destination PIDs reflecting different entries to the same 411 dCDN, the dCDN can convey shortcut or differentiaed quality of 412 services. 414 4.3. Example of Selecting a Downstream CDN based on ALTO Maps 416 In the following, we will outline an example of dCDN selection by a 417 uCDN based on ALTO maps provided by dCDNs. Consider the following 418 example: An upstream CDN (uCDN) has agreed on CDN interconnection 419 with several downstream CDNs (dCDN-a, dCDN-b, and dCDN-c). Each of 420 these downstream CDNs runs an ALTO server to provide aforementioned 421 ALTO information. Whenever the upstream CDN receives a request from 422 an end user and has determined that this request is best served by an 423 interconnected dCDN, the uCDN uses ALTO maps to make a redirection 424 decision. For a given request, assume that only the ALTO network 425 maps provided by dCDN-a and dCDN-c include the endhost. The uCDN 426 first looks up the PIDs of the endhost in the two network maps from 427 the two dCDNs, then search the PID properties to find out the 428 capabilities of each dCDN for the endhost. If only one dCDN supports 429 the required capabilities, then the uCDN chooses the dCDN. 430 Otherwise, if Cost Maps are available to provide additional server 431 selection information (e.g., a Cost Map defining latency), the uCDN 432 picks the dCDN with better cost performance. 434 4.4. Advantages of using ALTO 436 The following reasons make ALTO a suitable candidate protocol for 437 downstream CDN selection as part of CDNI request routing and in 438 particular for a FCI protocol: 440 o CDN request routing is done at the application layer. ALTO is a 441 protocol specifically designed to improve application layer 442 traffic (and application layer connections among hosts on the 443 Internet) by providing additonal information to applications that 444 these applications could not easily retrieve themselves. For 445 CDNI, this is exactly the case: a uCDN wants to improve 446 application layer CDN request routing by using dedicated 447 information (provided by a dCDN) that the uCDN could not easily 448 obtain otherwise. 450 o The semantics of an ALTO network are an exact match for the needed 451 information to convey a footprint by a downstream CDN, in 452 particular if such a footprint is being expressed by IP-prefix 453 ranges. 455 o ALTO cost maps are suitable to express various types of numeric 456 values and can hence be used by an upstream CDN to obtain metrics 457 for capabilities associated with a given dCDN for a given 458 foorprint. Further, an ALTO cost map could also convey relevant 459 network topology information other than simply routing hops or 460 reachability. This facilitiates advanced and more sophisticated 461 selection of a downstream CDN based on various metrics by the 462 upstream CDN and increases flexibility to cover different use 463 cases and business models for CDN interconnection. 465 o Flexible granularity: The concept of the PID and ALTO network/cost 466 maps allows for different degrees of granularity. This enables a 467 dCDN to differentiate the delivery quality for serving an end user 468 request on a fine granularity depending on the end user location 469 (and not only express delivery quality e.g. on an AS-level). It 470 remains at the discretion of each dCDN how fine-granular the ALTO 471 network and cost maps are that it publishes. 473 o ALTO maps can be signed and hence provide inherent integrity 474 protection (see Section 6) 476 5. Useful ALTO extensions for CDNI Request Routing 477 It is envisioned that yet-to-be-defined ALTO extensions will be 478 standardized that make the ALTO protocol more suitable and useful for 479 applications other than the originally considered P2P use case 480 [I-D.marocco-alto-next]. Some of these extensions to the ALTO 481 protocol would be useful for ALTO to be used as a protocol within 482 CDNI request routing, and in particular within the "Footprint and 483 Capabilities Advertisment" part of the CDNI request routing 484 interface. 486 The following proposed extensions to ALTO would be beneficial to 487 facilitate CDNI request routing with ALTO as outlined in Section 4: 489 o Server-initiated Notifications and Incremental Updates: In case 490 the footprint or the capabilities of a downstream CDN change 491 abruptly (i.e. unexpectedly from the perspective of an upstream 492 CDN), server initiated notifications would enable a dCDN to 493 directly inform an upstream CDN about such changes. Consider the 494 case where - due to failure - part of the footprint of the dCDN is 495 not functioning, i.e. the CDN cannot serve content to such clients 496 with reasonable QoS. Without server-initiated notifications, the 497 uCDN might still use a very recent network and cost map from dCDN, 498 and therefore redirect request to dCDN which it cannot serve. 499 Similarly, the possibility for incremental updates would enable 500 efficient conveyance of the aforementioned (or similar) status 501 changes by the dCDN to the uCDN. A proposal for server-initiated 502 ALTO updates can be found in [I-D.marocco-alto-ws]. A discussion 503 of incremental ALTO updates can be found in 504 [I-D.schwan-alto-incr-updates]. 506 o Content Availability on Hosts: A dCDN might want to express CDN 507 capabilties in terms of certain content types (e.g. codecs/ 508 formats, or content from certain content providers). A new 509 endpoint property for ALTO that would be able to express such 510 "content availability" would enable a dCDN to make available such 511 information to an upstream CDN. This would enable a uCDN to 512 determine if a given dCDN actually has the capabilities for a 513 given request with respect to the type of content requested. 515 o Resource Availability on Hosts or Links: The capabilities on links 516 (e.g. maximum bandwidth) or caches (e.g. average load) might be 517 useful information for an upstream CDN for optimized dowmstream 518 CDN selection. For instance, if a uCDN receives a streaming 519 request for content with a certain bitrate, it needs to know if it 520 is likely that a dCDN can fulfill such stringent application-level 521 requirements (i.e. can be expected to have enough consistent 522 bandwidth) before it redirects the request. In general, if ALTO 523 could convey such information via new endpoint properties, it 524 would enable more sophisticated means for downstream CDN selection 525 with ALTO. 527 6. Security Considerations 529 One important security consideration is the proper authentication of 530 advertisement information provided by a downstream CDN. The ALTO 531 protocol provides a specification for a signature of ALTO maps (see 532 8.2.2. of [I-D.ietf-alto-protocol]. ALTO thus provides a proper 533 means for protecting the integrity of footprint advertisment 534 information. 536 More Security Considerations will be discussed in a future version of 537 this document. 539 7. Summary and Outlook 541 This document presented conrete examples of how ALTO can be used 542 within the downstream CDN selection of CDNI Request Routing. 543 Further, the document provides arguments why ALTO is a meaningful 544 protocol in this context. Essentially, ALTO network and cost maps 545 are a means to provide detailed and various types of information to 546 an upstream CDN, in order to facilitate well-considered downstream 547 CDN selection. 549 The intention of this document is to find consensus in the CDNI WG 550 that ALTO is a useful protocol for CDNI request routing, and that 551 ALTO has many benefits for proper selection of a downstream CDN. The 552 overall objective is to form agreement on how ALTO should be used 553 within the CDNI request routing protocol. It is the intention to 554 capture the outcome of such continuing discussions in future versions 555 of this document. 557 8. Acknowledgements 559 Jan Seedorf is partially supported by the CHANGE project (CHANGE: 560 Enabling Innovation in the Internet Architecture through Flexible 561 Flow-Processing Extensions, http://www.change-project.eu/), a 562 research project supported by the European Commission under its 7th 563 Framework Program (contract no. 257422). The views and conclusions 564 contained herein are those of the authors and should not be 565 interpreted as necessarily representing the official policies or 566 endorsements, either expressed or implied, of the CHANGE project or 567 the European Commission. 569 Jan Seedorf has been partially supported by the COAST project 570 (COntent Aware Searching, retrieval and sTreaming, http://www.coast- 571 fp7.eu), a research project supported by the European Commission 572 under its 7th Framework Program (contract no. 248036). The views 573 and conclusions contained herein are those of the authors and should 574 not be interpreted as necessarily representing the official policies 575 or endorsements, either expressed or implied, of the COAST project or 576 the European Commission. 578 9. References 580 9.1. Normative References 582 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 583 Optimization (ALTO) Problem Statement", RFC 5693, October 584 2009. 586 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 587 Distribution Network Interconnection (CDNI) Problem 588 Statement", RFC 6707, September 2012. 590 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 591 K., and G. Watson, "Use Cases for Content Delivery Network 592 Interconnection", RFC 6770, November 2012. 594 9.2. Informative References 596 [I-D.peterson-CDNI-strawman] 597 Peterson, L. and J. Hartman, "Content Distribution Network 598 Interconnection (CDNI) Problem Statement", draft-peterson- 599 CDNI-strawman-01 (work in progress), May 2011. 601 [I-D.ietf-cdni-problem-statement] 602 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 603 Distribution Network Interconnection (CDNI) Problem 604 Statement", draft-ietf-cdni-problem-statement-08 (work in 605 progress), June 2012. 607 [I-D.marocco-alto-next] 608 Marocco, E. and V. Gurbani, "Extending the Application- 609 Layer Traffic Optimization (ALTO) Protocol", draft- 610 marocco-alto-next-00 (work in progress), January 2012. 612 [I-D.ietf-alto-protocol] 613 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- 614 ietf-alto-protocol-20 (work in progress), October 2013. 616 [I-D.ietf-cdni-requirements] 617 Leung, K. and Y. Lee, "Content Distribution Network 618 Interconnection (CDNI) Requirements", draft-ietf-cdni- 619 requirements-11 (work in progress), October 2013. 621 [I-D.ietf-cdni-use-cases] 622 Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma, 623 K., and G. Watson, "Use Cases for Content Delivery Network 624 Interconnection", draft-ietf-cdni-use-cases-10 (work in 625 progress), August 2012. 627 [I-D.marocco-alto-ws] 628 Marocco, E. and J. Seedorf, "WebSocket-based server-to- 629 client notifications for the Application-Layer Traffic 630 Optimization (ALTO) Protocol", draft-marocco-alto-ws-01 631 (work in progress), July 2012. 633 [I-D.schwan-alto-incr-updates] 634 Schwan, N. and B. Roome, "ALTO Incremental Updates", 635 draft-schwan-alto-incr-updates-02 (work in progress), July 636 2012. 638 [I-D.jenkins-alto-cdn-use-cases] 639 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 640 S. Previdi, "Use Cases for ALTO within CDNs", draft- 641 jenkins-alto-cdn-use-cases-03 (work in progress), June 642 2012. 644 [I-D.seedorf-alto-for-cdni] 645 Seedorf, J., "ALTO for CDNi Request Routing", draft- 646 seedorf-alto-for-cdni-00 (work in progress), October 2011. 648 [I-D.ietf-cdni-framework] 649 Peterson, L. and B. Davie, "Framework for CDN 650 Interconnection", draft-ietf-cdni-framework-06 (work in 651 progress), October 2013. 653 [I-D.liu-cdni-cost] 654 Liu, H., "A Cost Perspective on Using Multiple CDNs", 655 draft-liu-cdni-cost-00 (work in progress), October 2011. 657 [I-D.spp-cdni-rr-foot-cap-semantics] 658 Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., 659 and K. Ma, "CDNI Request Routing: Footprint and 660 Capabilities Semantics", draft-spp-cdni-rr-foot-cap- 661 semantics-04 (work in progress), February 2013. 663 Authors' Addresses 665 Jan Seedorf 666 NEC Laboratories Europe, NEC Europe Ltd. 667 Kurfuersten-Anlage 36 668 Heidelberg 69115 669 Germany 671 Phone: +49 (0) 6221 4342 221 672 Email: jan.seedorf@neclab.eu 673 URI: http://www.neclab.eu 675 Y.R. Yang 676 Yale University 677 51 Prospect Street 678 New Haven 06511 679 USA 681 Email: yry@cs.yale.edu 682 URI: http://www.cs.yale.edu/~yry/