idnits 2.17.1 draft-seedorf-cdni-request-routing-alto-08.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 367: '...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 (March 5, 2015) is 3337 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6770' is defined on line 521, but no explicit reference was found in the text == Unused Reference: 'RFC7337' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'I-D.peterson-CDNI-strawman' is defined on line 540, but no explicit reference was found in the text == Unused Reference: 'I-D.liu-cdni-cost' is defined on line 572, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-cdni-metadata' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-cdni-logging' is defined on line 581, 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-06 == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-09 == Outdated reference: A later version (-27) exists of draft-ietf-cdni-logging-15 == Outdated reference: A later version (-20) exists of draft-ietf-cdni-footprint-capabilities-semantics-05 Summary: 2 errors (**), 0 flaws (~~), 11 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: September 6, 2015 Yale 6 J. Peterson 7 Neustar 8 March 5, 2015 10 CDNI Footprint and Capabilities Advertisement using ALTO 11 draft-seedorf-cdni-request-routing-alto-08 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 September 6, 2015. 43 Copyright Notice 45 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . 9 73 4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 5. Useful ALTO extensions for CDNI Request Routing . . . . . . . 10 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 79 8.2. Informative References . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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) [RFC7285] service called 'CDNI Footprint & 107 Capabilities Advertisement Service'. This service is used to 108 transport CDNI FCI JSON objects, which are defined in a separate 109 document [I-D.ma-cdni-capabilities]. An abstraction for managing 110 individual CDNI capabilities in an opaque manner is defined as 111 'FCIBase' object in [I-D.ietf-cdni-footprint-capabilities-semantics]. 113 Throughout this document, we use the terminology for CDNI defined in 114 [RFC6707]. 116 2. ALTO within CDNI Request Routing 118 The main purpose of the CDNI Request Routing Interface is described 119 in [RFC6707] as follows: "The CDNI Request Routing interface enables 120 a Request Routing function in an Upstream CDN to query a Request 121 Routing function in a Downstream CDN to determine if the Downstream 122 CDN is able (and willing) to accept the delegated Content Request. 123 It also allows the Downstream CDN to control what should be returned 124 to the User Agent in the redirection message by the upstream Request 125 Routing function." On a high level, the scope of the CDNI Request 126 Routing Interface therefore contains two main tasks: 128 o A) Determining if the downstream CDN is willing to accept a 129 delegated content request 131 o B) Redirecting the content request coming from an upstream CDN to 132 the proper entry point or entity in the downstream CDN 134 More precisely, in [RFC7336] the request routing interface is broadly 135 divided into two functionalities: 137 o 1) the asynchronous advertisement of footprint and capabilities by 138 a dCDN that allows a uCDN to decide whether to redirect particular 139 user requests to that dCDN (the CDNI FCI) 141 o 2) the synchronous operation of actually redirecting a user 142 request (the CDNI RI) 144 Application Layer Traffic Optimization (ALTO) [RFC7285] is an 145 approach for guiding the resource provider selection process in 146 distributed applications that can choose among several candidate 147 resources providers to retrieve a given resource. By conveying 148 network layer (topology) information, an ALTO server can provide 149 important information to "guide" the resource provider selection 150 process in distributed applications. Usually, it is assumed that an 151 ALTO server conveys information these applications cannot measure 152 themselves [RFC5693]. 154 Originally, ALTO was motivated by the huge amount of cross-ISP 155 traffic generated by P2P applications [RFC5693]. Recently, however, 156 ALTO is also being considered for improving the request routing in 157 CDNs [I-D.jenkins-alto-cdn-use-cases]. In this context, it has also 158 been proposed to use ALTO for selecting an entry-point in a 159 downstream NSP's network (see section 3.4 "CDN delivering Over-The- 160 Top of a NSP's network" in [I-D.jenkins-alto-cdn-use-cases]). Also, 161 the CDNI problem statement explicitly mentions ALTO as a candidate 162 protocol for "algorithms for selection of CDN or Surrogate by 163 Request-Routing systems" [RFC6707]. 165 3. Assumptions and High-Level Design Considerations 167 In this section we list some assumptions and design issues to be 168 considered when using ALTO for the CDNI Footprint and Capabilities 169 Advertisement interface. 171 3.1. General Assumptions and Considerations 173 Below we list some general assumptions and considerations: 175 o As explicitly being out-of-scope for CDNI [RFC6707], it is assumed 176 that ingestion of content or acquiring content across CDNs is not 177 part of request routing as considered within CDNI standardization 178 work. The focus of using ALTO (as considered in this document) is 179 hence on request routing only, assuming that the content (desired 180 by the end user) is available in the downstream CDN (or can be 181 aquired by the downstream CDN by some means). 183 o Federation Model: "Footprint and Capabilities Advertisement" and 184 in general CDN request routing depends on the federation model 185 among the CDN providers. Designing a suitable solution thus 186 depends on whether a solution is needed for different settings, 187 where CDNs consist of both NSP CDNs (serving individual ASes) and 188 general, traditional CDNs (such as Akamai). We assume that CDNI 189 is not designed for a setting where only NSP CDNs each serve a 190 single AS only. 192 o In this document, it is assumed that the upstream CDN (uCDN) makes 193 the decision on selecting a downstream CDN, based on information 194 that each downstream CDN has made available to the upstream CDN. 195 Further, we assume that in principle more than one dCDN may be 196 suitable for a given end-user request (i.e. different dCDNs may 197 claim "overlapping" footprints). The uCDN hence potentially has 198 to select among several candidate downstream CDNs for a given end 199 user request. 201 o It is not clear what kind(s) of business, contract, and 202 operational relationships two peering CDNs may form. For the 203 Internet, we see provider-customer and peering as two main 204 relations; providers may use different charging models (e.g., 205 95-percentile, total volume) and may provide different SLAs. 206 Given such unknown characteristics of CDN peering business 207 agreements, we should design the protocol to support as much 208 diverse potential business and operational models as possible. 210 3.2. Semantics for Footprint/Capabilities Advertisment 212 The CDNI document on "Footprint and Capabilities Semantics" 213 [I-D.ietf-cdni-footprint-capabilities-semantics] defines the 214 semantics for the CDNI FCI. It thus provides guidance on what 215 Footprint and Capabilities mean in a CDNI context and how a protocol 216 solution should in principle look like. Here we briefly summarize 217 the key points of the semantics of Footprint and Capabilities (for a 218 detailed discussion, the reader is referred to 219 [I-D.ietf-cdni-footprint-capabilities-semantics]): 221 o Often, footprint and capabilities are tied together and cannot be 222 interpreted independently from each other. In such cases, i.e. 223 where capabilities must be expressed on a per footprint basis, it 224 may be beneficial to combine footprint and capabilities 225 advertisement. 227 o Given that a large part of Footprint and Capabilities 228 Advertisement will actually happen in contractual agreements, the 229 semantics of CDNI Footprint and Capabilities advertisement refer 230 to answering the following question: what exactly still needs to 231 be advertised by the CDNI FCI? For instance, updates about 232 temporal failures of part of a footprint can be useful information 233 to convey via the CDNI request routing interface. Such 234 information would provide updates on information previously agreed 235 in contracts between the participating CDNs. In other words, the 236 CDNI FCI is a means for a dCDN to provide changes/updates 237 regarding a footprint and/or capabilities it has prior agreed to 238 serve in a contract with a uCDN. 240 o It seems clear that "coverage/reachability" types of footprint 241 must be supported within CDNI. The following such types of 242 footprint are mandatory and must be supported by the CDNI FCI: 244 * List of ISO Country Codes 246 * List of AS numbers 248 * Set of IP-prefixes 250 A 'set of IP-prefixes' must be able to contain full IP addresses, 251 i.e., a /32 for IPv4 and a /128 for IPv6, and also IP prefixes 252 with an arbitrary prefix length. There must also be support for 253 multiple IP address versions, i.e., IPv4 and IPv6, in such a 254 footprint. 256 o For all of these mandatory-to-implement footprint types, 257 footprints can be viewed as constraints for delegating requests to 258 a dCDN: A dCDN footprint advertisement tells the uCDN the 259 limitations for delegating a request to the dCDN. For IP prefixes 260 or ASN(s), the footprint signals to the uCDN that it should 261 consider the dCDN a candidate only if the IP address of the 262 request routing source falls within the prefix set (or ASN, 263 respectively). The CDNI specifications do not define how a given 264 uCDN determines what address ranges are in a particular ASN. 265 Similarly, for country codes a uCDN should only consider the dCDN 266 a candidate if it covers the country of the request routing 267 source. The CDNI specifications do not define how a given uCDN 268 determines the country of the request routing source. Multiple 269 footprint constraints are additive, i.e. the advertisement of 270 different types of footprint narrows the dCDN candidacy 271 cumulatively. 273 o The following capabilities seem useful as 'base' capabilities, 274 i.e. ones that are needed in any case and therefore constitute 275 mandatory capabilities to be supported by the CDNI FCI: 277 * Delivery Protocol (e.g., HTTP vs. RTMP) 279 * Acquisition Protocol (for aquiring content from a uCDN) 281 * Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as 282 discussed in [RFC7336]) 284 * Capabilities related to CDNI Logging (e.g., supported logging 285 mechanisms) 287 * Capabilities related to CDNI Metadata (e.g., authorization 288 algorithms or support for proprietary vendor metadata) 290 3.3. Advantages of using ALTO as the CDNI FCI protocol 292 The following reasons make ALTO a suitable candidate protocol for 293 downstream CDN selection as part of CDNI request routing and in 294 particular for an FCI protocol: 296 o CDN request routing is done at the application layer. ALTO is a 297 protocol specifically designed to improve application layer 298 traffic (and application layer connections among hosts on the 299 Internet) by providing additonal information to applications that 300 these applications could not easily retrieve themselves. For 301 CDNI, this is exactly the case: a uCDN wants to improve 302 application layer CDN request routing by using dedicated 303 information (provided by a dCDN) that the uCDN could not easily 304 obtain otherwise. 306 o The semantics of an ALTO network map are an exact match for the 307 needed information to convey a footprint by a downstream CDN, in 308 particular if such a footprint is being expressed by IP-prefix 309 ranges. 311 o Security: ALTO maps can be signed and hence provide inherent 312 integrity protection (see Section 6) 314 o RESTful-Design: The ALTO protocol has undergone extensive 315 revisions in order to provide a RESTful design regarding the 316 client-server interaction specified by the protocol. A CDNI FCI 317 interface based on ALTO would inherit this RESTful design. 319 o Error-handling: The ALTO protocol has undergone extensive 320 revisions in order to provide sophisticated error-handling, 321 inparticular regarding unexpected cases. A CDNI FCI interface 322 based on ALTO would inherit this thought-through and mature error- 323 handling. 325 o Filtered network map: The ALTO Map Filtering Service (see 326 [RFC7285] for details) would allow a uCDN to query only for parts 327 of an ALTO map. 329 3.4. Selection of a Downstream CDN with ALTO 331 Under the considerations stated in Section 3, ALTO can help the 332 upstream CDN provider to select a proper downstream CDN provider for 333 a given end user request as follows: Each downstream CDN provider 334 hosts an ALTO server which provides ALTO services which convey CDNI 335 FCI information to an ALTO client at the upstream CDN provider. 337 4. CDNI FCI ALTO Service 339 The ALTO protocol is based on an ALTO Information Service Framework 340 which consists of several services, where all ALTO services are 341 'provided through a common transport protocol, messaging structure 342 and encoding, and transaction model' [RFC7285]. The ALTO protocol 343 specification [RFC7285] defines several such services, e.g. the ALTO 344 map service. 346 This document defines a new ALTO Service called 'CDNI Footprint & 347 Capabilities Advertisement Service' which conveys JSON objects of 348 media type 'application/alto-fcimap+json'. This media type and JSON 349 object format is defined in [I-D.ma-cdni-capabilities]; this document 350 specifies how to transport such JSON objects via the ALTO protocol 351 with the ALTO 'CDNI Footprint & Capabilities Advertisement Service'. 352 An abstraction for managing individual CDNI capabilities in an opaque 353 manner is defined as 'FCIBase' object in 354 [I-D.ietf-cdni-footprint-capabilities-semantics]. 356 4.1. Server Response Encoding 358 4.1.1. CDNI FCI Map 360 The media type of the CDNI FCI Map is 'application/alto-cdni- 361 fcimap+json'. The HTTP Method, Accept Input Parameters, 362 Capabilities, Uses, and Response of the CDNI FCI Map are specified in 363 [I-D.ma-cdni-capabilities]. 365 4.1.2. Meta Information 367 The 'meta' field of a FCIMapData response MUST include 'vtag', which 368 is an ALTO Version Tag of the retrieved FCIMapData according to 369 [RFC7285] (Section 10.3.). It thus contains a 'resource-id' 370 attribute, and a 'tag' is an identifier string. 372 4.1.3. Data Information 374 The data component of a CDNI FCI Map resource is named 'fcimap' which 375 is a JSON object of type FCIMapData. This JSON object of type 376 FCIMapData is derived from ResponseEntityBase as specified in the 377 ALTO protocol [RFC7285] (Section 8.4.) and specified in 378 [I-D.ma-cdni-capabilities]. 380 4.2. Protocol Errors 382 Protocol errors are handled as specified in the ALTO protocol 383 [RFC7285] (Section 8.5.). 385 4.3. Example 387 The following example shows an CDNI FCI Map as in 388 [I-D.ma-cdni-capabilities], however with meta-information as defined 389 in Section 4.1.2 of this document. 391 GET /fcimap HTTP/1.1 392 Host: alto.example.com 393 Accept: application/alto-fcimap+json,application/alto-error+json 395 HTTP/1.1 200 OK 396 Content-Length: 439 397 Content-Type: application/alto-fcimap+json 398 { 399 "meta" : { 400 "vtag": { 401 "resource-id": "my-default-fcimap", 402 "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" 403 } 404 }, 405 "fcimap": [ 406 { "name": "delivery_protocol", 407 "values": [ 408 "HTTP", 409 "RTSP", 410 "MMS" 411 ] 412 }, 413 { "name": "delivery_protocol", 414 "values": [ 415 "RTMP", 416 "HTTPS" 417 ], 418 "footprint": [ 419 { "type": "IPv4CIDR", 420 "values": [ 421 "10.1.0.0/16", 422 "10.10.10.0/24" 423 ] 424 } 425 ] 426 } 427 ] 428 } 430 5. Useful ALTO extensions for CDNI Request Routing 432 It is envisioned that yet-to-be-defined ALTO extensions will be 433 standardized that make the ALTO protocol more suitable and useful for 434 applications other than the originally considered P2P use case 435 [I-D.marocco-alto-next]. Some of these extensions to the ALTO 436 protocol would be useful for ALTO to be used as a protocol within 437 CDNI request routing, and in particular within the "Footprint and 438 Capabilities Advertisment" part of the CDNI request routing 439 interface. 441 The following proposed extensions to ALTO would be beneficial to 442 facilitate CDNI request routing with ALTO as outlined in Section 3.4: 444 o Server-initiated Notifications and Incremental Updates: In case 445 the footprint or the capabilities of a downstream CDN change 446 abruptly (i.e. unexpectedly from the perspective of an upstream 447 CDN), server initiated notifications would enable a dCDN to 448 directly inform an upstream CDN about such changes. Consider the 449 case where - due to failure - part of the footprint of the dCDN is 450 not functioning, i.e. the CDN cannot serve content to such clients 451 with reasonable QoS. Without server-initiated notifications, the 452 uCDN might still use a very recent network and cost map from dCDN, 453 and therefore redirect request to dCDN which it cannot serve. 454 Similarly, the possibility for incremental updates would enable 455 efficient conveyance of the aforementioned (or similar) status 456 changes by the dCDN to the uCDN. A proposal for server-initiated 457 ALTO updates can be found in [I-D.marocco-alto-ws]. A discussion 458 of incremental ALTO updates can be found in 459 [I-D.schwan-alto-incr-updates]. 461 o Content Availability on Hosts: A dCDN might want to express CDN 462 capabilties in terms of certain content types (e.g. codecs/ 463 formats, or content from certain content providers). A new 464 endpoint property for ALTO that would be able to express such 465 "content availability" would enable a dCDN to make available such 466 information to an upstream CDN. This would enable a uCDN to 467 determine if a given dCDN actually has the capabilities for a 468 given request with respect to the type of content requested. 470 o Resource Availability on Hosts or Links: The capabilities on links 471 (e.g. maximum bandwidth) or caches (e.g. average load) might be 472 useful information for an upstream CDN for optimized dowmstream 473 CDN selection. For instance, if a uCDN receives a streaming 474 request for content with a certain bitrate, it needs to know if it 475 is likely that a dCDN can fulfill such stringent application-level 476 requirements (i.e. can be expected to have enough consistent 477 bandwidth) before it redirects the request. In general, if ALTO 478 could convey such information via new endpoint properties, it 479 would enable more sophisticated means for downstream CDN selection 480 with ALTO. 482 6. Security Considerations 484 One important security consideration is the proper authentication of 485 advertisement information provided by a downstream CDN. The ALTO 486 protocol provides a specification for a signature of ALTO information 487 (see 8.2.2. of [RFC7285]. ALTO thus provides a proper means for 488 protecting the integrity of FCI information. 490 More Security Considerations will be discussed in a future version of 491 this document. 493 7. Acknowledgements 495 The authors would like to thank Kevin Ma, Daryl Malas, and Matt 496 Caulfield for their timely reviews and invaluable comments. 498 Jan Seedorf is partially supported by the GreenICN project (GreenICN: 499 Architecture and Applications of Green Information Centric 500 Networking), a research project supported jointly by the European 501 Commission under its 7th Framework Program (contract no. 608518) and 502 the National Institute of Information and Communications Technology 503 (NICT) in Japan (contract no. 167). The views and conclusions 504 contained herein are those of the authors and should not be 505 interpreted as necessarily representing the official policies or 506 endorsements, either expressed or implied, of the GreenICN project, 507 the European Commission, or NICT. 509 8. References 511 8.1. Normative References 513 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 514 Optimization (ALTO) Problem Statement", RFC 5693, October 515 2009. 517 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 518 Distribution Network Interconnection (CDNI) Problem 519 Statement", RFC 6707, September 2012. 521 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 522 K., and G. Watson, "Use Cases for Content Delivery Network 523 Interconnection", RFC 6770, November 2012. 525 [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., 526 Roome, W., Shalunov, S., and R. Woundy, "Application-Layer 527 Traffic Optimization (ALTO) Protocol", RFC 7285, September 528 2014. 530 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, 531 "Framework for Content Distribution Network 532 Interconnection (CDNI)", RFC 7336, August 2014. 534 [RFC7337] Leung, K. and Y. Lee, "Content Distribution Network 535 Interconnection (CDNI) Requirements", RFC 7337, August 536 2014. 538 8.2. Informative References 540 [I-D.peterson-CDNI-strawman] 541 Peterson, L. and J. Hartman, "Content Distribution Network 542 Interconnection (CDNI) Problem Statement", draft-peterson- 543 CDNI-strawman-01 (work in progress), May 2011. 545 [I-D.marocco-alto-next] 546 Marocco, E. and V. Gurbani, "Extending the Application- 547 Layer Traffic Optimization (ALTO) Protocol", draft- 548 marocco-alto-next-00 (work in progress), January 2012. 550 [I-D.marocco-alto-ws] 551 Marocco, E. and J. Seedorf, "WebSocket-based server-to- 552 client notifications for the Application-Layer Traffic 553 Optimization (ALTO) Protocol", draft-marocco-alto-ws-02 554 (work in progress), February 2014. 556 [I-D.schwan-alto-incr-updates] 557 Schwan, N. and B. Roome, "ALTO Incremental Updates", 558 draft-schwan-alto-incr-updates-02 (work in progress), July 559 2012. 561 [I-D.jenkins-alto-cdn-use-cases] 562 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 563 S. Previdi, "Use Cases for ALTO within CDNs", draft- 564 jenkins-alto-cdn-use-cases-03 (work in progress), June 565 2012. 567 [I-D.ma-cdni-capabilities] 568 Ma, K. and J. Seedorf, "CDNI Footprint & Capabilities 569 Advertisement Interface", draft-ma-cdni-capabilities-06 570 (work in progress), June 2014. 572 [I-D.liu-cdni-cost] 573 Liu, H., "A Cost Perspective on Using Multiple CDNs", 574 draft-liu-cdni-cost-00 (work in progress), October 2011. 576 [I-D.ietf-cdni-metadata] 577 Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 578 "CDN Interconnection Metadata", draft-ietf-cdni- 579 metadata-09 (work in progress), March 2015. 581 [I-D.ietf-cdni-logging] 582 Faucheur, F., Bertrand, G., Oprescu, I., and R. 583 Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- 584 logging-15 (work in progress), February 2015. 586 [I-D.ietf-cdni-footprint-capabilities-semantics] 587 Seedorf, J., Peterson, J., Previdi, S., Brandenburg, R., 588 and K. Ma, "CDNI Request Routing: Footprint and 589 Capabilities Semantics", draft-ietf-cdni-footprint- 590 capabilities-semantics-05 (work in progress), March 2015. 592 Authors' Addresses 594 Jan Seedorf 595 NEC Laboratories Europe, NEC Europe Ltd. 596 Kurfuersten-Anlage 36 597 Heidelberg 69115 598 Germany 600 Phone: +49 (0) 6221 4342 221 601 Email: jan.seedorf@neclab.eu 602 URI: http://www.neclab.eu 604 Y.R. Yang 605 Yale University 606 51 Prospect Street 607 New Haven 06511 608 USA 610 Email: yry@cs.yale.edu 611 URI: http://www.cs.yale.edu/~yry/ 613 Jon Peterson 614 NeuStar 615 1800 Sutter St Suite 570 616 Concord CA 94520 617 USA 619 Email: jon.peterson@neustar.biz