idnits 2.17.1 draft-seedorf-cdni-request-routing-alto-06.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.) ** There is 1 instance of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3723 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line 710, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-cdni-use-cases' is defined on line 715, but no explicit reference was found in the text == Unused Reference: 'I-D.liu-cdni-cost' is defined on line 747, 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-25 == Outdated reference: A later version (-14) exists of draft-ietf-cdni-framework-09 Summary: 2 errors (**), 0 flaws (~~), 6 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: August 18, 2014 Yale 6 February 14, 2014 8 CDNI Footprint and Capabilities Advertisement using ALTO 9 draft-seedorf-cdni-request-routing-alto-06 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 August 18, 2014. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. ALTO within CDNI Request Routing . . . . . . . . . . . . . . 3 65 3. Assumptions and High-Level Design Considerations . . . . . . 4 66 3.1. General Assumptions and Consideration . . . . . . . . . . 5 67 3.2. Semantics for Footprint/Capabilities Advertisment . . . . 5 68 4. Selection of a Downstream CDN with ALTO . . . . . . . . . . . 7 69 4.1. Footprint and Capabilities Advertisement using ALTO 70 Network Map and PID Properties . . . . . . . . . . . . . 7 71 4.2. Conveying additional information with ALTO Cost Maps . . 9 72 4.3. Example of Selecting a Downstream CDN based on ALTO Maps 9 73 4.4. Advantages of using ALTO as the CDNI FCI protocol . . . . 10 74 5. Concrete Examples with ALTO Maps . . . . . . . . . . . . . . 11 75 5.1. Example ALTO Network Map . . . . . . . . . . . . . . . . 11 76 5.2. Example ALTO PID Property . . . . . . . . . . . . . . . . 12 77 6. Useful ALTO extensions for CDNI Request Routing . . . . . . . 13 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 8. Summary and Outlook . . . . . . . . . . . . . . . . . . . . . 14 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 83 10.2. Informative References . . . . . . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 86 1. Introduction 88 Many Network Service Providers (NSPs) are currently considering or 89 have already started to deploy Content Delivery Networks (CDNs) 90 within their networks. As a consequence of this development, there 91 is a need for interconnecting these local CDNs. Content Delivery 92 Networks Interconnection (CDNI) has the goal of standardizing 93 protocols to enable such interconnection of CDNs [RFC6707]. 95 The CDNI problem statement [RFC6707] envisions four interfaces to be 96 standardized within the IETF for CDN interconnection: 98 o CDNI Request Routing Interface 100 o CDNI Metadata Interface 102 o CDNI Logging Interface 104 o CDNI Control Interface 106 This document focuses solely on the CDNI Request Routing Interface, 107 which can be further divided into two interfaces (see [RFC6707] for a 108 detailed description): the CDNI Request Routing Redirection interface 109 (RI), and the CDNI Footprint & Capabilities Advertisement interface 110 (FCI). This document presents how one may use ALTO as a protocol for 111 CDNI Footprint & Capabilities Advertisement. Concrete examples of 112 how the CDNI FCI can be implemented with the ALTO protocol 113 [I-D.ietf-alto-protocol] are given. The examples used in this 114 document are based on the use cases and request routing proposals 115 currently being discussed in the CDNI WG [RFC6770] 116 [I-D.peterson-CDNI-strawman] and in the ALTO WG 117 [I-D.jenkins-alto-cdn-use-cases]. 119 A previous version of this document [I-D.seedorf-alto-for-cdni] 120 contained detailed examples of actual request routing and surrogate 121 selection with ALTO, i.e. how ALTO could be used for implementing the 122 CDNI Request Routing Redirection interface (RI). This version solely 123 focuses on implementing the CDNI Footprint & Capabilities 124 Advertisement interface (FCI) with ALTO, i.e. the selection of a 125 downstream CDN and how ALTO can support such downstream CDN 126 selection. 128 Throughout this document, we use the terminology for CDNI defined in 129 [I-D.ietf-cdni-problem-statement]. 131 2. ALTO within CDNI Request Routing 133 The main purpose of the CDNI Request Routing Interface is described 134 in [RFC6707] as follows: "The CDNI Request Routing interface enables 135 a Request Routing function in an Upstream CDN to query a Request 136 Routing function in a Downstream CDN to determine if the Downstream 137 CDN is able (and willing) to accept the delegated Content Request. 138 It also allows the Downstream CDN to control what should be returned 139 to the User Agent in the redirection message by the upstream Request 140 Routing function." On a high level, the scope of the CDNI Request 141 Routing Interface therefore contains two main tasks: 143 o A) Determining if the downstream CDN is willing to accept a 144 delegated content request 146 o B) Redirecting the content request coming from an upstream CDN to 147 the proper entry point or entity in the downstream CDN 149 More precisely, in [I-D.ietf-cdni-framework] the request routing 150 interface is broadly divided into two functionalities: 152 o 1) the asynchronous advertisement of footprint and capabilities by 153 a dCDN that allows a uCDN to decide whether to redirect particular 154 user requests to that dCDN (the CDNI FCI) 156 o 2) the synchronous operation of actually redirecting a user 157 request (the CDNI RI) 159 Application Layer Traffic Optimization (ALTO) is an approach for 160 guiding the resource provider selection process in distributed 161 applications that can choose among several candidate resources 162 providers to retrieve a given resource. By conveying network layer 163 (topology) information, an ALTO server can provide important 164 information to "guide" the resource provider selection process in 165 distributed applications. Usually, it is assumed that an ALTO server 166 conveys information these applications cannot measure themselves 167 [RFC5693]. 169 Originally, ALTO was motivated by the huge amount of cross-ISP 170 traffic generated by P2P applications [RFC5693]. Recently, however, 171 ALTO is also being considered for improving the request routing in 172 CDNs [I-D.jenkins-alto-cdn-use-cases]. In this context, it has also 173 been proposed to use ALTO for selecting an entry-point in a 174 downstream NSP's network (see section 3.4 "CDN delivering Over-The- 175 Top of a NSP's network" in [I-D.jenkins-alto-cdn-use-cases]). Also, 176 the CDNI problem statement explicitly mentions ALTO as a candidate 177 protocol for "algorithms for selection of CDN or Surrogate by 178 Request-Routing systems" [I-D.ietf-cdni-problem-statement]. Yet, 179 there have not been concrete proposals so far on how to use ALTO in 180 the context of CDN interconnection. This document tries to close 181 this gap by giving some examples on how ALTO could be used within 182 CDNI request routing. 184 3. Assumptions and High-Level Design Considerations 186 In this section we list some assumptions and design issues to be 187 considered when using ALTO for the CDNI Footprint and Capabilities 188 Advertisement interface 190 3.1. General Assumptions and Consideration 192 Below we list some general assumptions and considerations: 194 o As explicitly being out-of-scope for CDNI 195 [I-D.ietf-cdni-problem-statement], the examples used in this 196 document assume that ingestion of content or acquiring content 197 across CDNs is not part of request routing as considered within 198 CDNI standardization work. The focus of using ALTO (as considered 199 in this document) is hence on request routing only, assuming that 200 the content (desired by the end user) is available in the 201 downstream CDN (or can be aquired by the downstream CDN by some 202 means). 204 o Federation Model: "Footprint and Capabilities Advertisement" and 205 in general CDN request routing depends on the federation model 206 among the CDN providers. Designing a suitable solution thus 207 depends on whether a solution is needed for different settings, 208 where CDNs consist of both NSP CDNs (serving individual ASes) and 209 general, traditional CDNs (such as Akamai). We assume that CDNI 210 is not designed for a setting where only NSP CDNs each serve a 211 single AS only. 213 o In this document, we assume that the upstream CDN (uCDN) makes the 214 decision on selecting a downstream CDN, based on information that 215 each downstream CDN has made available to the upstream CDN. 216 Further, we assume that in principle more than one dCDN may be 217 suitable for a given end-user request (i.e. different dCDNs may 218 claim "overlapping" footprints). The uCDN hence potentially has 219 to select among several candidate downstream CDNs for a given end 220 user request. 222 o It is not clear what kind(s) of business, contract, and 223 operational relationships two peering CDNs may form. For the 224 Internet, we see provider-customer and peering as two main 225 relations; providers may use different charging models (e.g., 226 95-percentile, total volume) and may provide different SLAs. 227 Given such unknown characteristics of CDN peering business 228 agreements, we should design the protocol to support as much 229 diverse potential business and operational models as possible. 231 3.2. Semantics for Footprint/Capabilities Advertisment 233 The CDNI document on "Footprint and Capabilities Semantics" 234 [I-D.spp-cdni-rr-foot-cap-semantics] defines the semantics for the 235 CDNI FCI. It thus provides guidance on what Footprint and 236 Capabilities mean in a CDNI context and how a protocol solution 237 should in principle look like. Here we briefly summarize the key 238 points of the semantics of Footprint and Capabilities (for a detailed 239 discussion, the reader is referred to 240 [I-D.spp-cdni-rr-foot-cap-semantics]): 242 o Often, footprint and capabilities are tied together and cannot be 243 interpreted independently from each other. In such cases, i.e. 244 where capabilities must be expressed on a per footprint basis, it 245 may be beneficial to combine footprint and capabilities 246 advertisement. 248 o Given that a large part of Footprint and Capabilities 249 Advertisement will actually happen in contractual agreements, the 250 semantics of CDNI Footprint and Capabilities advertisement refer 251 to answering the following question: what exactly still needs to 252 be advertised by the CDNI FCI? For instance, updates about 253 temporal failures of part of a footprint can be useful information 254 to convey via the CDNI request routing interface. Such 255 information would provide updates on information previously agreed 256 in contracts between the participating CDNs. In other words, the 257 CDNI FCI is a means for a dCDN to provide changes/updates 258 regarding a footprint and/or capabilities it has prior agreed to 259 serve in a contract with a uCDN. 261 o It seems clear that "coverage/reachability" types of footprint 262 must be supported within CDNI. The following such types of 263 footprint are mandatory and must be supported by the CDNI FCI: 265 * List of ISO Country Codes 267 * List of AS numbers 269 * Set of IP-prefixes 271 A 'set of IP-prefixes' must be able to contain full IP addresses, 272 i.e., a /32 for IPv4 and a /128 for IPv6, and also IP prefixes 273 with an arbitrary prefix length. There must also be support for 274 multiple IP address versions, i.e., IPv4 and IPv6, in such a 275 footprint. 277 o For all of these mandatory-to-implement footprint types, 278 footprints can be viewed as constraints for delegating requests to 279 a dCDN: A dCDN footprint advertisement tells the uCDN the 280 limitations for delegating a request to the dCDN. For IP prefixes 281 or ASN(s), the footprint signals to the uCDN that it should 282 consider the dCDN a candidate only if the IP address of the 283 request routing source falls within the prefix set (or ASN, 284 respectively). The CDNI specifications do not define how a given 285 uCDN determines what address ranges are in a particular ASN. 287 Similarly, for country codes a uCDN should only consider the dCDN 288 a candidate if it covers the country of the request routing 289 source. The CDNI specifications do not define how a given uCDN 290 determines the country of the request routing source. Multiple 291 footprint constraints are additive, i.e. the advertisement of 292 different types of footprint narrows the dCDN candidacy 293 cumulatively. 295 o The following capabilities seem useful as 'base' capabilities, 296 i.e. ones that are needed in any case and therefore constitute 297 mandatory capabilities to be supported by the CDNI FCI: 299 * Delivery Protocol (e.g., HTTP vs. RTMP) 301 * Acquisition Protocol (for aquiring content from a uCDN) 303 * Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as 304 discussed in [I-D.ietf-cdni-framework]) 306 * Capabilities related to CDNI Logging (e.g., supported logging 307 mechanisms) 309 * Capabilities related to CDNI Metadata (e.g., authorization 310 algorithms or support for proprietary vendor metadata) 312 4. Selection of a Downstream CDN with ALTO 314 Under the considerations stated in Section 3, ALTO can help the 315 upstream CDN provider to select a proper downstream CDN provider for 316 a given end user request as follows: Each downstream CDN provider 317 hosts an ALTO server which provides ALTO information (i.e. ALTO 318 network maps and potentially additonally ALTO cost maps 319 [I-D.ietf-alto-protocol]) to an ALTO client at the upstream CDN 320 provider. Network maps provided by each of several candidate 321 downstream CDNs can provide information to the upstream CDN provider 322 about each dCDN's "coverage/reachability" as well as capabilities. 324 4.1. Footprint and Capabilities Advertisement using ALTO Network Map 325 and PID Properties 327 Conceptually, the footprint and capabilities interface of a dCDN is 328 easy to specify: It is a function that given an endhost, returns if 329 the dCDN is willing to serve the endhost, and the capabilities 330 available to that endhost (e.g., "delivery-protocol": 331 ["HTTP","RMTP"], "acquisition-protocol": ["HTTP"], "redirection- 332 mode": ["HTTP-redirect"], "loggin-mechanism": ["TBD"], and "meta- 333 capabilities": [""]). 335 Specifiying the preceding for each endhost can be redundant, and one 336 may use PIDs defined in ALTO. Specifically, an ALTO network map 337 contains a "set of Network Location groupings" 338 [I-D.ietf-alto-protocol]. The groupings are defined in the form of 339 so-called "PIDs". A PID is an identifier to group network location 340 endpoints, e.g. IP-addresses in the form of prefixes (see section 4 341 in [I-D.ietf-alto-protocol] for details). 343 Applying the basic idea of ALTO PIDs to the preceding, abstract 344 mapping specification, by aggregating endhosts with the same 345 capabilities in the same PID, we obtain CDNi FCI using ALTO Network 346 Maps as simply (1) a Network Map which defines a set of PIDs, and (2) 347 a PID Property Map [draft-roome-alto-pid-properties] that defines the 348 properties of each PID, where the properties define the capabilities. 350 With the preceding Network Map and PID Property Map, the upstream CDN 351 provider can easily match a given end user request with the footprint 352 and capabilities of the downstream CDN providers. Whenever the 353 footprint and/or capabilities of a dCDN change, the ALTO server of 354 the dCDN changes its data, and the uCDN can obtain the update through 355 ALTO incremental updates. Future extensions to ALTO to add 356 notifications can be integrated when they become available. 358 In particular, this document does not define how a dCDN aggregates 359 the endhosts into PIDs, to allow flexibility in (anticipated) 360 updates. 362 In this document, we define the following PID properties, which each 363 must be a JSON array, to convey all mandatory capabilities (see 364 Section 3.2): 366 o delivery-protocol 368 o acquisition-protocol 370 o redirection-mode 372 o logging-mechanism 374 o meta-capabilities 376 To complement the preceding capabilities mapping, we require that an 377 uCDN has access to ALTO Network Map(s) that can map from an endhost 378 to Country Code and AS Number. Such mapping may or may not be 379 specific to CDNI but can be a general mapping. Specifically, the 380 uCDN should have access to ALTO Network Map(s) which Properties 381 include: 383 o country-code 385 o asn 387 4.2. Conveying additional information with ALTO Cost Maps 389 An ALTO cost map contains costs between defined groupings of a 390 corresponding network map (i.e. costs between PIDs): "An ALTO Cost 391 Map defines Path Costs pairwise amongst sets of source and 392 destination Network Locations" [I-D.ietf-alto-protocol]. This 393 concept enables the provider of a cost map to express (and quantify) 394 preferences of a destination network location with respect to a given 395 source network location. 397 In the context of CDNI, the ALTO cost map concept is an extensive 398 tool to convey additional information about the footprint or 399 capabilties of a downstream CDN. The cost map concept provides a 400 means for a downstream CDN provider to convey numeric values 401 associated with a PID, e.g. in order to convey metrics associated 402 with a footprint or a capability. This may be useful for future, 403 non-mandatory types of footprint or capabilties. 405 One way to use ALTO cost maps would have these maps of the type 406 N-to-m, i.e. 'costs' are expressed for each of N end user source PIDs 407 to m dCDN request router PIDs. Semantically, a source PID in a CDNI 408 ALTO cost map is thus the end user location, whereas a destination 409 PID is a (group of) request router(s) to which the uCDN redirects the 410 end user request. Note that this perspective is driven by the CDNI 411 request routing. An alternative way - seen from the perspective of 412 content retrieval - would be to have a m-to-N cost map where the 413 source is always the dCDN and the destination is the end user (with 414 the semantic "if the source dCDN would deliver content to an end user 415 in the destination PID, the costs would be the following). With 416 explicit destination PIDs reflecting different entries to the same 417 dCDN, the dCDN can convey shortcut or differentiated quality of 418 services. 420 4.3. Example of Selecting a Downstream CDN based on ALTO Maps 422 In the following, we will outline an example of dCDN selection by a 423 uCDN based on ALTO maps provided by dCDNs. Consider the following 424 example: An upstream CDN (uCDN) has agreed on CDN interconnection 425 with several downstream CDNs (dCDN-a, dCDN-b, and dCDN-c). Each of 426 these downstream CDNs runs an ALTO server to provide aforementioned 427 ALTO information. Whenever the upstream CDN receives a request from 428 an end user and has determined that this request is best served by an 429 interconnected dCDN, the uCDN uses ALTO maps to make a redirection 430 decision. For a given request, assume that only the ALTO network 431 maps provided by dCDN-a and dCDN-c include the endhost. The uCDN 432 first looks up the PIDs of the endhost in the two network maps from 433 the two dCDNs, and then searches the PID properties to find out the 434 capabilities of each dCDN for the endhost. If only one dCDN supports 435 the required capabilities, then the uCDN chooses the dCDN. 436 Otherwise, the UCDN uses additional server selection information 437 (i.e. information obtained outside the CDNI FCI interface such as 438 business agreements) at its own discretion in order to pick a dCDN 439 among the ones that provide the necessary capabilities for the given 440 end host request. 442 4.4. Advantages of using ALTO as the CDNI FCI protocol 444 The following reasons make ALTO a suitable candidate protocol for 445 downstream CDN selection as part of CDNI request routing and in 446 particular for an FCI protocol: 448 o CDN request routing is done at the application layer. ALTO is a 449 protocol specifically designed to improve application layer 450 traffic (and application layer connections among hosts on the 451 Internet) by providing additonal information to applications that 452 these applications could not easily retrieve themselves. For 453 CDNI, this is exactly the case: a uCDN wants to improve 454 application layer CDN request routing by using dedicated 455 information (provided by a dCDN) that the uCDN could not easily 456 obtain otherwise. 458 o The semantics of an ALTO network map are an exact match for the 459 needed information to convey a footprint by a downstream CDN, in 460 particular if such a footprint is being expressed by IP-prefix 461 ranges. 463 o The PID concept allows for clean separation between footprint and 464 capabilities: The PID gives a name to a footprint and a dCDN can 465 then easily change separately either a) the Properties for a given 466 footprint, or b) the Composition of a given footprint. 468 o Flexible granularity: The concept of the PID and ALTO network/cost 469 maps allows for different degrees of granularity. This enables a 470 dCDN to differentiate the delivery quality for serving an end user 471 request on a fine granularity depending on the end user location 472 (and not only express delivery quality e.g. on an AS-level). It 473 remains at the discretion of each dCDN how fine-granular the ALTO 474 network and cost maps are that it publishes. 476 o Security: ALTO maps can be signed and hence provide inherent 477 integrity protection (see Section 7) 479 o RESTful-Design: The ALTO protocol has undergone extensive 480 revisions in order to provide a RESTful design regarding the 481 client-server interaction specified by the protocol. A CDNI FCI 482 interface based on ALTO would inherit this RESTful design. 484 o Error-handling: The ALTO protocol has undergone extensive 485 revisions in order to provide sophisticated error-handling, 486 inparticular regarding unexpected cases. A CDNI FCI interface 487 based on ALTO would inherit this thought-through and mature error- 488 handling. 490 o Endpoint Property Service: The ALTO Endpoint Property Service (see 491 [I-D.ietf-alto-protocol] for details) would allow an upstream CDN 492 to query capabilities for an individual endpoint (without querying 493 the whole map). 495 o Filtered network map: The ALTO Map Filtering Service (see 496 [I-D.ietf-alto-protocol] for details) would allow a uCDN to query 497 only for parts of an ALTO map. 499 5. Concrete Examples with ALTO Maps 501 The following examples show concrete ALTO maps and how CDNI FCI would 502 be facilitated with these as described in the previous Section. 504 5.1. Example ALTO Network Map 506 The following network map would convey to a uCDN that the given dCDN 507 (which would provide the map) has three footprints called ''south- 508 france'', ''germany'', and ''rest'', and provide the corresponding 509 IPv4 address ranges for these footprints. The entry ''cdni-fruit'' : 510 [''orange''] in the ''south-france'' footprint is an example of how 511 new endpoint types (e.g. proprietary ones that are defined outside 512 the CDNI FCI among certain CDNs) could be used in an ALTO network 513 map. 515 GET /networkmap/eu HTTP/1.1 516 Host: cdni.example.com 517 Accept: application/alto-networkmap+json,application/alto-error+json 519 HTTP/1.1 200 OK 520 Content-Length: TBA 521 Content-Type: application/alto-networkmap+json 523 { 524 "meta" : { 525 "vtag": [ 526 {"resource-id": "my-eu-netmap", 527 "tag": "1266506139" 528 } 529 ] 530 }, 531 "network-map" : { 532 "south-france" : { 533 "ipv4" : [ "192.0.2.0/24", "198.51.100.0/25" ], "cdni-fruit" : ["orange"] 534 }, 535 "germany" : { 536 "ipv4" : [ "192.0.3.0/24"] 537 }, 538 "rest" : { "ipv4": [0.0.0.0/0], "ipv6"; [::/0] } 539 } 540 } 542 5.2. Example ALTO PID Property 544 The following PID properties would correspond to the footprints from 545 the network map shown in the previous subsection and convey to the 546 uCDN that the capabilities for all endpoints in the footprint 547 ''south-france'' are ["HTTP"], and that the capabilities for all 548 endpoints in the footprint ''germany'' are ["HTTP", "HTTPS"]. 550 HTTP/1.1 200 OK 551 Content-Length: TBA 552 Content-Type: application/alto-pidprop+json 554 { 555 "meta" : { 556 "dependent-vtags" : [ 557 {"resource-id": "my-eu-netmap", 558 "tag": "1266506139" 559 } 560 ] 561 }, 562 "properties": { 563 "pid:south-france" : { "delivery-protocol": ["HTTP"], ... }, 564 "pid:germany" : { "delivery-protocol": ["HTTP", "HTTPS"], ... }, 565 "pid:rest" : {} 566 } 567 } 569 6. Useful ALTO extensions for CDNI Request Routing 571 It is envisioned that yet-to-be-defined ALTO extensions will be 572 standardized that make the ALTO protocol more suitable and useful for 573 applications other than the originally considered P2P use case 574 [I-D.marocco-alto-next]. Some of these extensions to the ALTO 575 protocol would be useful for ALTO to be used as a protocol within 576 CDNI request routing, and in particular within the "Footprint and 577 Capabilities Advertisment" part of the CDNI request routing 578 interface. 580 The following proposed extensions to ALTO would be beneficial to 581 facilitate CDNI request routing with ALTO as outlined in Section 4: 583 o Server-initiated Notifications and Incremental Updates: In case 584 the footprint or the capabilities of a downstream CDN change 585 abruptly (i.e. unexpectedly from the perspective of an upstream 586 CDN), server initiated notifications would enable a dCDN to 587 directly inform an upstream CDN about such changes. Consider the 588 case where - due to failure - part of the footprint of the dCDN is 589 not functioning, i.e. the CDN cannot serve content to such clients 590 with reasonable QoS. Without server-initiated notifications, the 591 uCDN might still use a very recent network and cost map from dCDN, 592 and therefore redirect request to dCDN which it cannot serve. 593 Similarly, the possibility for incremental updates would enable 594 efficient conveyance of the aforementioned (or similar) status 595 changes by the dCDN to the uCDN. A proposal for server-initiated 596 ALTO updates can be found in [I-D.marocco-alto-ws]. A discussion 597 of incremental ALTO updates can be found in 598 [I-D.schwan-alto-incr-updates]. 600 o Content Availability on Hosts: A dCDN might want to express CDN 601 capabilties in terms of certain content types (e.g. codecs/ 602 formats, or content from certain content providers). A new 603 endpoint property for ALTO that would be able to express such 604 "content availability" would enable a dCDN to make available such 605 information to an upstream CDN. This would enable a uCDN to 606 determine if a given dCDN actually has the capabilities for a 607 given request with respect to the type of content requested. 609 o Resource Availability on Hosts or Links: The capabilities on links 610 (e.g. maximum bandwidth) or caches (e.g. average load) might be 611 useful information for an upstream CDN for optimized dowmstream 612 CDN selection. For instance, if a uCDN receives a streaming 613 request for content with a certain bitrate, it needs to know if it 614 is likely that a dCDN can fulfill such stringent application-level 615 requirements (i.e. can be expected to have enough consistent 616 bandwidth) before it redirects the request. In general, if ALTO 617 could convey such information via new endpoint properties, it 618 would enable more sophisticated means for downstream CDN selection 619 with ALTO. 621 7. Security Considerations 623 One important security consideration is the proper authentication of 624 advertisement information provided by a downstream CDN. The ALTO 625 protocol provides a specification for a signature of ALTO maps (see 626 8.2.2. of [I-D.ietf-alto-protocol]. ALTO thus provides a proper 627 means for protecting the integrity of footprint advertisment 628 information. 630 More Security Considerations will be discussed in a future version of 631 this document. 633 8. Summary and Outlook 635 This document presented conrete examples of how ALTO can be used 636 within the downstream CDN selection of CDNI Request Routing. 637 Further, the document provides arguments why ALTO is a meaningful 638 protocol in this context. Essentially, ALTO network and cost maps 639 are a means to provide detailed and various types of information to 640 an upstream CDN, in order to facilitate well-considered downstream 641 CDN selection. 643 The intention of this document is to find consensus in the CDNI WG 644 that ALTO is a useful protocol for CDNI request routing, and that 645 ALTO has many benefits for proper selection of a downstream CDN. The 646 overall objective is to form agreement on how ALTO should be used 647 within the CDNI request routing protocol. It is the intention to 648 capture the outcome of such continuing discussions in future versions 649 of this document. 651 9. Acknowledgements 653 Jan Seedorf is partially supported by the CHANGE project (CHANGE: 654 Enabling Innovation in the Internet Architecture through Flexible 655 Flow-Processing Extensions, http://www.change-project.eu/), a 656 research project supported by the European Commission under its 7th 657 Framework Program (contract no. 257422). The views and conclusions 658 contained herein are those of the authors and should not be 659 interpreted as necessarily representing the official policies or 660 endorsements, either expressed or implied, of the CHANGE project or 661 the European Commission. 663 Jan Seedorf has been partially supported by the COAST project 664 (COntent Aware Searching, retrieval and sTreaming, http://www.coast- 665 fp7.eu), a research project supported by the European Commission 666 under its 7th Framework Program (contract no. 248036). The views 667 and conclusions contained herein are those of the authors and should 668 not be interpreted as necessarily representing the official policies 669 or endorsements, either expressed or implied, of the COAST project or 670 the European Commission. 672 10. References 674 10.1. Normative References 676 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 677 Optimization (ALTO) Problem Statement", RFC 5693, October 678 2009. 680 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 681 Distribution Network Interconnection (CDNI) Problem 682 Statement", RFC 6707, September 2012. 684 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 685 K., and G. Watson, "Use Cases for Content Delivery Network 686 Interconnection", RFC 6770, November 2012. 688 10.2. Informative References 690 [I-D.peterson-CDNI-strawman] 691 Peterson, L. and J. Hartman, "Content Distribution Network 692 Interconnection (CDNI) Problem Statement", draft-peterson- 693 CDNI-strawman-01 (work in progress), May 2011. 695 [I-D.ietf-cdni-problem-statement] 696 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 697 Distribution Network Interconnection (CDNI) Problem 698 Statement", draft-ietf-cdni-problem-statement-08 (work in 699 progress), June 2012. 701 [I-D.marocco-alto-next] 702 Marocco, E. and V. Gurbani, "Extending the Application- 703 Layer Traffic Optimization (ALTO) Protocol", draft- 704 marocco-alto-next-00 (work in progress), January 2012. 706 [I-D.ietf-alto-protocol] 707 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- 708 ietf-alto-protocol-25 (work in progress), January 2014. 710 [I-D.ietf-cdni-requirements] 711 Leung, K. and Y. Lee, "Content Distribution Network 712 Interconnection (CDNI) Requirements", draft-ietf-cdni- 713 requirements-17 (work in progress), January 2014. 715 [I-D.ietf-cdni-use-cases] 716 Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma, 717 K., and G. Watson, "Use Cases for Content Delivery Network 718 Interconnection", draft-ietf-cdni-use-cases-10 (work in 719 progress), August 2012. 721 [I-D.marocco-alto-ws] 722 Marocco, E. and J. Seedorf, "WebSocket-based server-to- 723 client notifications for the Application-Layer Traffic 724 Optimization (ALTO) Protocol", draft-marocco-alto-ws-02 725 (work in progress), February 2014. 727 [I-D.schwan-alto-incr-updates] 728 Schwan, N. and B. Roome, "ALTO Incremental Updates", 729 draft-schwan-alto-incr-updates-02 (work in progress), July 730 2012. 732 [I-D.jenkins-alto-cdn-use-cases] 733 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 734 S. Previdi, "Use Cases for ALTO within CDNs", draft- 735 jenkins-alto-cdn-use-cases-03 (work in progress), June 736 2012. 738 [I-D.seedorf-alto-for-cdni] 739 Seedorf, J., "ALTO for CDNi Request Routing", draft- 740 seedorf-alto-for-cdni-00 (work in progress), October 2011. 742 [I-D.ietf-cdni-framework] 743 Peterson, L., Davie, B., and R. Brandenburg, "Framework 744 for CDN Interconnection", draft-ietf-cdni-framework-09 745 (work in progress), January 2014. 747 [I-D.liu-cdni-cost] 748 Liu, H., "A Cost Perspective on Using Multiple CDNs", 749 draft-liu-cdni-cost-00 (work in progress), October 2011. 751 [I-D.spp-cdni-rr-foot-cap-semantics] 752 Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., 753 and K. Ma, "CDNI Request Routing: Footprint and 754 Capabilities Semantics", draft-spp-cdni-rr-foot-cap- 755 semantics-04 (work in progress), February 2013. 757 Authors' Addresses 759 Jan Seedorf 760 NEC Laboratories Europe, NEC Europe Ltd. 761 Kurfuersten-Anlage 36 762 Heidelberg 69115 763 Germany 765 Phone: +49 (0) 6221 4342 221 766 Email: jan.seedorf@neclab.eu 767 URI: http://www.neclab.eu 769 Y.R. Yang 770 Yale University 771 51 Prospect Street 772 New Haven 06511 773 USA 775 Email: yry@cs.yale.edu 776 URI: http://www.cs.yale.edu/~yry/