idnits 2.17.1 draft-seedorf-cdni-request-routing-alto-07.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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 363: '...MapData response MUST include 'vtag', ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2014) is 3585 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6770' is defined on line 517, but no explicit reference was found in the text == Unused Reference: 'I-D.peterson-CDNI-strawman' is defined on line 523, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line 543, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-cdni-use-cases' is defined on line 548, but no explicit reference was found in the text == Unused Reference: 'I-D.liu-cdni-cost' is defined on line 581, but no explicit reference was found in the text == Unused Reference: 'I-D.spp-cdni-rr-foot-cap-semantics' is defined on line 585, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-cdni-metadata' is defined on line 591, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-cdni-logging' is defined on line 596, 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 (-09) exists of draft-ma-cdni-capabilities-05 == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-06 == Outdated reference: A later version (-27) exists of draft-ietf-cdni-logging-11 == Outdated reference: A later version (-20) exists of draft-ietf-cdni-footprint-capabilities-semantics-02 Summary: 2 errors (**), 0 flaws (~~), 13 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: December 29, 2014 Yale 6 J. Peterson 7 Neustar 8 June 27, 2014 10 CDNI Footprint and Capabilities Advertisement using ALTO 11 draft-seedorf-cdni-request-routing-alto-07 13 Abstract 15 Network Service Providers (NSPs) are currently considering to deploy 16 Content Delivery Networks (CDNs) within their networks. As a 17 consequence of this development, there is a need for interconnecting 18 these local CDNs. The necessary interfaces for inter-connecting CDNs 19 are currently being defined in the Content Delivery Networks 20 Interconnection (CDNI) WG. This document focuses on the CDNI 21 Footprint & Capabilities Advertisement interface (FCI). 22 Specifically, this document specifies a new Application Layer Traffic 23 Optimization (ALTO) service to facilitate Footprint & Capabilities 24 Advertisement in a CDNI context. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 29, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. ALTO within CDNI Request Routing . . . . . . . . . . . . . . 3 62 3. Assumptions and High-Level Design Considerations . . . . . . 4 63 3.1. General Assumptions and Considerations . . . . . . . . . 4 64 3.2. Semantics for Footprint/Capabilities Advertisment . . . . 5 65 3.3. Advantages of using ALTO as the CDNI FCI protocol . . . . 7 66 3.4. Selection of a Downstream CDN with ALTO . . . . . . . . . 7 67 4. CDNI FCI ALTO Service . . . . . . . . . . . . . . . . . . . . 8 68 4.1. Server Response Encoding . . . . . . . . . . . . . . . . 8 69 4.1.1. CDNI FCI Map . . . . . . . . . . . . . . . . . . . . 8 70 4.1.2. Meta Information . . . . . . . . . . . . . . . . . . 8 71 4.1.3. Data Information . . . . . . . . . . . . . . . . . . 8 72 4.2. Protocol Errors . . . . . . . . . . . . . . . . . . . . . 8 73 4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 5. Useful ALTO extensions for CDNI Request Routing . . . . . . . 10 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 8.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 specifies a new Application Layer Traffic 106 Optimization (ALTO) [I-D.ietf-alto-protocol] service called 'CDNI 107 Footprint & Capabilities Advertisement Service'. This service is 108 used to transport a CDNI FCI JSON objects, which are defined in a 109 separate document [I-D.ma-cdni-capabilities]. 111 Throughout this document, we use the terminology for CDNI defined in 112 [I-D.ietf-cdni-problem-statement]. 114 2. ALTO within CDNI Request Routing 116 The main purpose of the CDNI Request Routing Interface is described 117 in [RFC6707] as follows: "The CDNI Request Routing interface enables 118 a Request Routing function in an Upstream CDN to query a Request 119 Routing function in a Downstream CDN to determine if the Downstream 120 CDN is able (and willing) to accept the delegated Content Request. 121 It also allows the Downstream CDN to control what should be returned 122 to the User Agent in the redirection message by the upstream Request 123 Routing function." On a high level, the scope of the CDNI Request 124 Routing Interface therefore contains two main tasks: 126 o A) Determining if the downstream CDN is willing to accept a 127 delegated content request 129 o B) Redirecting the content request coming from an upstream CDN to 130 the proper entry point or entity in the downstream CDN 132 More precisely, in [I-D.ietf-cdni-framework] the request routing 133 interface is broadly divided into two functionalities: 135 o 1) the asynchronous advertisement of footprint and capabilities by 136 a dCDN that allows a uCDN to decide whether to redirect particular 137 user requests to that dCDN (the CDNI FCI) 139 o 2) the synchronous operation of actually redirecting a user 140 request (the CDNI RI) 142 Application Layer Traffic Optimization (ALTO) 143 [I-D.ietf-alto-protocol] is an approach for guiding the resource 144 provider selection process in distributed applications that can 145 choose among several candidate resources providers to retrieve a 146 given resource. By conveying network layer (topology) information, 147 an ALTO server can provide important information to "guide" the 148 resource provider selection process in distributed applications. 149 Usually, it is assumed that an ALTO server conveys information these 150 applications cannot measure themselves [RFC5693]. 152 Originally, ALTO was motivated by the huge amount of cross-ISP 153 traffic generated by P2P applications [RFC5693]. Recently, however, 154 ALTO is also being considered for improving the request routing in 155 CDNs [I-D.jenkins-alto-cdn-use-cases]. In this context, it has also 156 been proposed to use ALTO for selecting an entry-point in a 157 downstream NSP's network (see section 3.4 "CDN delivering Over-The- 158 Top of a NSP's network" in [I-D.jenkins-alto-cdn-use-cases]). Also, 159 the CDNI problem statement explicitly mentions ALTO as a candidate 160 protocol for "algorithms for selection of CDN or Surrogate by 161 Request-Routing systems" [I-D.ietf-cdni-problem-statement]. 163 3. Assumptions and High-Level Design Considerations 165 In this section we list some assumptions and design issues to be 166 considered when using ALTO for the CDNI Footprint and Capabilities 167 Advertisement interface. 169 3.1. General Assumptions and Considerations 171 Below we list some general assumptions and considerations: 173 o As explicitly being out-of-scope for CDNI 174 [I-D.ietf-cdni-problem-statement], it is assumed that ingestion of 175 content or acquiring content across CDNs is not part of request 176 routing as considered within CDNI standardization work. The focus 177 of using ALTO (as considered in this document) is hence on request 178 routing only, assuming that the content (desired by the end user) 179 is available in the downstream CDN (or can be aquired by the 180 downstream CDN by some means). 182 o Federation Model: "Footprint and Capabilities Advertisement" and 183 in general CDN request routing depends on the federation model 184 among the CDN providers. Designing a suitable solution thus 185 depends on whether a solution is needed for different settings, 186 where CDNs consist of both NSP CDNs (serving individual ASes) and 187 general, traditional CDNs (such as Akamai). We assume that CDNI 188 is not designed for a setting where only NSP CDNs each serve a 189 single AS only. 191 o In this document, it is assumed that the upstream CDN (uCDN) makes 192 the decision on selecting a downstream CDN, based on information 193 that each downstream CDN has made available to the upstream CDN. 194 Further, we assume that in principle more than one dCDN may be 195 suitable for a given end-user request (i.e. different dCDNs may 196 claim "overlapping" footprints). The uCDN hence potentially has 197 to select among several candidate downstream CDNs for a given end 198 user request. 200 o It is not clear what kind(s) of business, contract, and 201 operational relationships two peering CDNs may form. For the 202 Internet, we see provider-customer and peering as two main 203 relations; providers may use different charging models (e.g., 204 95-percentile, total volume) and may provide different SLAs. 205 Given such unknown characteristics of CDN peering business 206 agreements, we should design the protocol to support as much 207 diverse potential business and operational models as possible. 209 3.2. Semantics for Footprint/Capabilities Advertisment 211 The CDNI document on "Footprint and Capabilities Semantics" 212 [I-D.ietf-cdni-footprint-capabilities-semantics] defines the 213 semantics for the CDNI FCI. It thus provides guidance on what 214 Footprint and Capabilities mean in a CDNI context and how a protocol 215 solution should in principle look like. Here we briefly summarize 216 the key points of the semantics of Footprint and Capabilities (for a 217 detailed discussion, the reader is referred to 218 [I-D.ietf-cdni-footprint-capabilities-semantics]): 220 o Often, footprint and capabilities are tied together and cannot be 221 interpreted independently from each other. In such cases, i.e. 222 where capabilities must be expressed on a per footprint basis, it 223 may be beneficial to combine footprint and capabilities 224 advertisement. 226 o Given that a large part of Footprint and Capabilities 227 Advertisement will actually happen in contractual agreements, the 228 semantics of CDNI Footprint and Capabilities advertisement refer 229 to answering the following question: what exactly still needs to 230 be advertised by the CDNI FCI? For instance, updates about 231 temporal failures of part of a footprint can be useful information 232 to convey via the CDNI request routing interface. Such 233 information would provide updates on information previously agreed 234 in contracts between the participating CDNs. In other words, the 235 CDNI FCI is a means for a dCDN to provide changes/updates 236 regarding a footprint and/or capabilities it has prior agreed to 237 serve in a contract with a uCDN. 239 o It seems clear that "coverage/reachability" types of footprint 240 must be supported within CDNI. The following such types of 241 footprint are mandatory and must be supported by the CDNI FCI: 243 * List of ISO Country Codes 245 * List of AS numbers 247 * Set of IP-prefixes 249 A 'set of IP-prefixes' must be able to contain full IP addresses, 250 i.e., a /32 for IPv4 and a /128 for IPv6, and also IP prefixes 251 with an arbitrary prefix length. There must also be support for 252 multiple IP address versions, i.e., IPv4 and IPv6, in such a 253 footprint. 255 o For all of these mandatory-to-implement footprint types, 256 footprints can be viewed as constraints for delegating requests to 257 a dCDN: A dCDN footprint advertisement tells the uCDN the 258 limitations for delegating a request to the dCDN. For IP prefixes 259 or ASN(s), the footprint signals to the uCDN that it should 260 consider the dCDN a candidate only if the IP address of the 261 request routing source falls within the prefix set (or ASN, 262 respectively). The CDNI specifications do not define how a given 263 uCDN determines what address ranges are in a particular ASN. 264 Similarly, for country codes a uCDN should only consider the dCDN 265 a candidate if it covers the country of the request routing 266 source. The CDNI specifications do not define how a given uCDN 267 determines the country of the request routing source. Multiple 268 footprint constraints are additive, i.e. the advertisement of 269 different types of footprint narrows the dCDN candidacy 270 cumulatively. 272 o The following capabilities seem useful as 'base' capabilities, 273 i.e. ones that are needed in any case and therefore constitute 274 mandatory capabilities to be supported by the CDNI FCI: 276 * Delivery Protocol (e.g., HTTP vs. RTMP) 278 * Acquisition Protocol (for aquiring content from a uCDN) 280 * Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as 281 discussed in [I-D.ietf-cdni-framework]) 283 * Capabilities related to CDNI Logging (e.g., supported logging 284 mechanisms) 286 * Capabilities related to CDNI Metadata (e.g., authorization 287 algorithms or support for proprietary vendor metadata) 289 3.3. Advantages of using ALTO as the CDNI FCI protocol 291 The following reasons make ALTO a suitable candidate protocol for 292 downstream CDN selection as part of CDNI request routing and in 293 particular for an FCI protocol: 295 o CDN request routing is done at the application layer. ALTO is a 296 protocol specifically designed to improve application layer 297 traffic (and application layer connections among hosts on the 298 Internet) by providing additonal information to applications that 299 these applications could not easily retrieve themselves. For 300 CDNI, this is exactly the case: a uCDN wants to improve 301 application layer CDN request routing by using dedicated 302 information (provided by a dCDN) that the uCDN could not easily 303 obtain otherwise. 305 o The semantics of an ALTO network map are an exact match for the 306 needed information to convey a footprint by a downstream CDN, in 307 particular if such a footprint is being expressed by IP-prefix 308 ranges. 310 o Security: ALTO maps can be signed and hence provide inherent 311 integrity protection (see Section 6) 313 o RESTful-Design: The ALTO protocol has undergone extensive 314 revisions in order to provide a RESTful design regarding the 315 client-server interaction specified by the protocol. A CDNI FCI 316 interface based on ALTO would inherit this RESTful design. 318 o Error-handling: The ALTO protocol has undergone extensive 319 revisions in order to provide sophisticated error-handling, 320 inparticular regarding unexpected cases. A CDNI FCI interface 321 based on ALTO would inherit this thought-through and mature error- 322 handling. 324 o Filtered network map: The ALTO Map Filtering Service (see 325 [I-D.ietf-alto-protocol] for details) would allow a uCDN to query 326 only for parts of an ALTO map. 328 3.4. Selection of a Downstream CDN with ALTO 330 Under the considerations stated in Section 3, ALTO can help the 331 upstream CDN provider to select a proper downstream CDN provider for 332 a given end user request as follows: Each downstream CDN provider 333 hosts an ALTO server which provides ALTO services which convey CDNI 334 FCI information to an ALTO client at the upstream CDN provider. 336 4. CDNI FCI ALTO Service 338 The ALTO protocol is based on an ALTO Information Service Framework 339 which consists of several services, where all ALTO services are 340 'provided through a common transport protocol, messaging structure 341 and encoding, and transaction model" [I-D.ietf-alto-protocol]. The 342 ALTO protocol specification [I-D.ietf-alto-protocol] defines several 343 such services, e.g. the ALTO map service. 345 This document defines a new ALTO Service called 'CDNI Footprint & 346 Capabilities Advertisement Service' which conveys JSON objects of 347 media type 'application/alto-fcimap+json'. This media type and JSON 348 object format is defined in [I-D.ma-cdni-capabilities]; this document 349 specifies how to transport such JSON objects via the ALTO protocol 350 with the ALTO 'CDNI Footprint & Capabilities Advertisement Service'. 352 4.1. Server Response Encoding 354 4.1.1. CDNI FCI Map 356 The media type of the CDNI FCI Map is 'application/alto-cdni- 357 fcimap+json'. The HTTP Method, Accept Input Parameters, 358 Capabilities, Uses, and Response of the CDNI FCI Map are specified in 359 [I-D.ma-cdni-capabilities]. 361 4.1.2. Meta Information 363 The 'meta' field of a FCIMapData response MUST include 'vtag', which 364 is an ALTO Version Tag of the retrieved FCIMapData according to 365 [I-D.ietf-alto-protocol] (Section 10.3.). It thus contains a 366 'resource-id' attribute, and a 'tag' is an identifier string. 368 4.1.3. Data Information 370 The data component of a CDNI FCI Map resource is named 'fcimap' which 371 is a JSON object of type FCIMapData. This JSON object of type 372 FCIMapData is derived from ResponseEntityBase as specified in the 373 ALTO protocol [I-D.ietf-alto-protocol] (Section 8.4.) and specified 374 in [I-D.ma-cdni-capabilities]. 376 4.2. Protocol Errors 378 Protocol errors are handled as specified in the ALTO protocol 379 [I-D.ietf-alto-protocol] (Section 8.5.). 381 4.3. Example 383 The following example shows an CDNI FCI Map as in 384 [I-D.ma-cdni-capabilities], however with meta-information as defined 385 in Section 4.1.2 of this document. 387 GET /fcimap HTTP/1.1 388 Host: alto.example.com 389 Accept: application/alto-fcimap+json,application/alto-error+json 391 HTTP/1.1 200 OK 392 Content-Length: 439 393 Content-Type: application/alto-fcimap+json 394 { 395 "meta" : { 396 "vtag": { 397 "resource-id": "my-default-fcimap", 398 "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" 399 } 400 }, 401 "fcimap": [ 402 { "name": "delivery_protocol", 403 "values": [ 404 "HTTP", 405 "RTSP", 406 "MMS" 407 ] 408 }, 409 { "name": "delivery_protocol", 410 "values": [ 411 "RTMP", 412 "HTTPS" 413 ], 414 "footprint": [ 415 { "type": "IPv4CIDR", 416 "values": [ 417 "10.1.0.0/16", 418 "10.10.10.0/24" 419 ] 420 } 421 ] 422 } 423 ] 424 } 426 5. Useful ALTO extensions for CDNI Request Routing 428 It is envisioned that yet-to-be-defined ALTO extensions will be 429 standardized that make the ALTO protocol more suitable and useful for 430 applications other than the originally considered P2P use case 431 [I-D.marocco-alto-next]. Some of these extensions to the ALTO 432 protocol would be useful for ALTO to be used as a protocol within 433 CDNI request routing, and in particular within the "Footprint and 434 Capabilities Advertisment" part of the CDNI request routing 435 interface. 437 The following proposed extensions to ALTO would be beneficial to 438 facilitate CDNI request routing with ALTO as outlined in Section 3.4: 440 o Server-initiated Notifications and Incremental Updates: In case 441 the footprint or the capabilities of a downstream CDN change 442 abruptly (i.e. unexpectedly from the perspective of an upstream 443 CDN), server initiated notifications would enable a dCDN to 444 directly inform an upstream CDN about such changes. Consider the 445 case where - due to failure - part of the footprint of the dCDN is 446 not functioning, i.e. the CDN cannot serve content to such clients 447 with reasonable QoS. Without server-initiated notifications, the 448 uCDN might still use a very recent network and cost map from dCDN, 449 and therefore redirect request to dCDN which it cannot serve. 450 Similarly, the possibility for incremental updates would enable 451 efficient conveyance of the aforementioned (or similar) status 452 changes by the dCDN to the uCDN. A proposal for server-initiated 453 ALTO updates can be found in [I-D.marocco-alto-ws]. A discussion 454 of incremental ALTO updates can be found in 455 [I-D.schwan-alto-incr-updates]. 457 o Content Availability on Hosts: A dCDN might want to express CDN 458 capabilties in terms of certain content types (e.g. codecs/ 459 formats, or content from certain content providers). A new 460 endpoint property for ALTO that would be able to express such 461 "content availability" would enable a dCDN to make available such 462 information to an upstream CDN. This would enable a uCDN to 463 determine if a given dCDN actually has the capabilities for a 464 given request with respect to the type of content requested. 466 o Resource Availability on Hosts or Links: The capabilities on links 467 (e.g. maximum bandwidth) or caches (e.g. average load) might be 468 useful information for an upstream CDN for optimized dowmstream 469 CDN selection. For instance, if a uCDN receives a streaming 470 request for content with a certain bitrate, it needs to know if it 471 is likely that a dCDN can fulfill such stringent application-level 472 requirements (i.e. can be expected to have enough consistent 473 bandwidth) before it redirects the request. In general, if ALTO 474 could convey such information via new endpoint properties, it 475 would enable more sophisticated means for downstream CDN selection 476 with ALTO. 478 6. Security Considerations 480 One important security consideration is the proper authentication of 481 advertisement information provided by a downstream CDN. The ALTO 482 protocol provides a specification for a signature of ALTO information 483 (see 8.2.2. of [I-D.ietf-alto-protocol]. ALTO thus provides a proper 484 means for protecting the integrity of FCI information. 486 More Security Considerations will be discussed in a future version of 487 this document. 489 7. Acknowledgements 491 The authors would like to thank Kevin Ma, Daryl Malas, and Matt 492 Caulfield for their timely reviews and invaluable comments. 494 Jan Seedorf is partially supported by the GreenICN project (GreenICN: 495 Architecture and Applications of Green Information Centric 496 Networking), a research project supported jointly by the European 497 Commission under its 7th Framework Program (contract no. 608518) and 498 the National Institute of Information and Communications Technology 499 (NICT) in Japan (contract no. 167). The views and conclusions 500 contained herein are those of the authors and should not be 501 interpreted as necessarily representing the official policies or 502 endorsements, either expressed or implied, of the GreenICN project, 503 the European Commission, or NICT. 505 8. References 507 8.1. Normative References 509 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 510 Optimization (ALTO) Problem Statement", RFC 5693, October 511 2009. 513 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 514 Distribution Network Interconnection (CDNI) Problem 515 Statement", RFC 6707, September 2012. 517 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 518 K., and G. Watson, "Use Cases for Content Delivery Network 519 Interconnection", RFC 6770, November 2012. 521 8.2. Informative References 523 [I-D.peterson-CDNI-strawman] 524 Peterson, L. and J. Hartman, "Content Distribution Network 525 Interconnection (CDNI) Problem Statement", draft-peterson- 526 CDNI-strawman-01 (work in progress), May 2011. 528 [I-D.ietf-cdni-problem-statement] 529 Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content 530 Distribution Network Interconnection (CDNI) Problem 531 Statement", draft-ietf-cdni-problem-statement-08 (work in 532 progress), June 2012. 534 [I-D.marocco-alto-next] 535 Marocco, E. and V. Gurbani, "Extending the Application- 536 Layer Traffic Optimization (ALTO) Protocol", draft- 537 marocco-alto-next-00 (work in progress), January 2012. 539 [I-D.ietf-alto-protocol] 540 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- 541 ietf-alto-protocol-27 (work in progress), March 2014. 543 [I-D.ietf-cdni-requirements] 544 Leung, K. and Y. Lee, "Content Distribution Network 545 Interconnection (CDNI) Requirements", draft-ietf-cdni- 546 requirements-17 (work in progress), January 2014. 548 [I-D.ietf-cdni-use-cases] 549 Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma, 550 K., and G. Watson, "Use Cases for Content Delivery Network 551 Interconnection", draft-ietf-cdni-use-cases-10 (work in 552 progress), August 2012. 554 [I-D.marocco-alto-ws] 555 Marocco, E. and J. Seedorf, "WebSocket-based server-to- 556 client notifications for the Application-Layer Traffic 557 Optimization (ALTO) Protocol", draft-marocco-alto-ws-02 558 (work in progress), February 2014. 560 [I-D.schwan-alto-incr-updates] 561 Schwan, N. and B. Roome, "ALTO Incremental Updates", 562 draft-schwan-alto-incr-updates-02 (work in progress), July 563 2012. 565 [I-D.jenkins-alto-cdn-use-cases] 566 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 567 S. Previdi, "Use Cases for ALTO within CDNs", draft- 568 jenkins-alto-cdn-use-cases-03 (work in progress), June 569 2012. 571 [I-D.ma-cdni-capabilities] 572 Ma, K. and J. Seedorf, "CDNI Footprint & Capabilities 573 Advertisement Interface", draft-ma-cdni-capabilities-05 574 (work in progress), June 2014. 576 [I-D.ietf-cdni-framework] 577 Peterson, L., Davie, B., and R. Brandenburg, "Framework 578 for CDN Interconnection", draft-ietf-cdni-framework-14 579 (work in progress), June 2014. 581 [I-D.liu-cdni-cost] 582 Liu, H., "A Cost Perspective on Using Multiple CDNs", 583 draft-liu-cdni-cost-00 (work in progress), October 2011. 585 [I-D.spp-cdni-rr-foot-cap-semantics] 586 Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., 587 and K. Ma, "CDNI Request Routing: Footprint and 588 Capabilities Semantics", draft-spp-cdni-rr-foot-cap- 589 semantics-04 (work in progress), February 2013. 591 [I-D.ietf-cdni-metadata] 592 Niven-Jenkins, B., Murray, R., Watson, G., Caulfield, M., 593 Leung, K., and K. Ma, "CDN Interconnect Metadata", draft- 594 ietf-cdni-metadata-06 (work in progress), February 2014. 596 [I-D.ietf-cdni-logging] 597 Faucheur, F., Bertrand, G., Oprescu, I., and R. 598 Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- 599 logging-11 (work in progress), March 2014. 601 [I-D.ietf-cdni-footprint-capabilities-semantics] 602 Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., 603 and K. Ma, "CDNI Request Routing: Footprint and 604 Capabilities Semantics", draft-ietf-cdni-footprint- 605 capabilities-semantics-02 (work in progress), February 606 2014. 608 Authors' Addresses 609 Jan Seedorf 610 NEC Laboratories Europe, NEC Europe Ltd. 611 Kurfuersten-Anlage 36 612 Heidelberg 69115 613 Germany 615 Phone: +49 (0) 6221 4342 221 616 Email: jan.seedorf@neclab.eu 617 URI: http://www.neclab.eu 619 Y.R. Yang 620 Yale University 621 51 Prospect Street 622 New Haven 06511 623 USA 625 Email: yry@cs.yale.edu 626 URI: http://www.cs.yale.edu/~yry/ 628 Jon Peterson 629 NeuStar 630 1800 Sutter St Suite 570 631 Concord CA 94520 632 USA 634 Email: jon.peterson@neustar.biz