idnits 2.17.1 draft-seedorf-cdni-request-routing-alto-09.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 362: '...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 (July 2, 2017) is 2489 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6770' is defined on line 518, 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 ** Downref: Normative reference to an Informational RFC: RFC 5693 ** Downref: Normative reference to an Informational RFC: RFC 6707 ** Downref: Normative reference to an Informational RFC: RFC 6770 ** Downref: Normative reference to an Informational RFC: RFC 7336 ** Downref: Normative reference to an Informational RFC: RFC 7337 Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CDNI J. Seedorf 3 Internet-Draft HFT Stuttgart - Univ. of Applied Sciences 4 Intended status: Standards Track Y. Yang 5 Expires: January 3, 2018 Tongji/Yale 6 J. Peterson 7 Neustar 8 July 2, 2017 10 Content Delivery Network Interconnection (CDNI) Request Routing: CDNI 11 Footprint and Capabilities Advertisement using ALTO 12 draft-seedorf-cdni-request-routing-alto-09 14 Abstract 16 Network Service Providers (NSPs) are currently considering to deploy 17 Content Delivery Networks (CDNs) within their networks. As a 18 consequence of this development, there is a need for interconnecting 19 these local CDNs. The necessary interfaces for inter-connecting CDNs 20 are currently being defined in the Content Delivery Networks 21 Interconnection (CDNI) WG. This document focuses on the CDNI 22 Footprint & Capabilities Advertisement interface (FCI). 23 Specifically, this document specifies a new Application Layer Traffic 24 Optimization (ALTO) service to facilitate Footprint & Capabilities 25 Advertisement in a CDNI context. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 3, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. ALTO within CDNI Request Routing . . . . . . . . . . . . . . 3 63 3. Assumptions and High-Level Design Considerations . . . . . . 4 64 3.1. General Assumptions and Considerations . . . . . . . . . 4 65 3.2. Semantics for Footprint/Capabilities Advertisment . . . . 5 66 3.3. Advantages of using ALTO as the CDNI FCI protocol . . . . 7 67 3.4. Selection of a Downstream CDN with ALTO . . . . . . . . . 7 68 4. CDNI FCI ALTO Service . . . . . . . . . . . . . . . . . . . . 8 69 4.1. Server Response Encoding . . . . . . . . . . . . . . . . 8 70 4.1.1. CDNI FCI Map . . . . . . . . . . . . . . . . . . . . 8 71 4.1.2. Meta Information . . . . . . . . . . . . . . . . . . 8 72 4.1.3. Data Information . . . . . . . . . . . . . . . . . . 8 73 4.2. Protocol Errors . . . . . . . . . . . . . . . . . . . . . 8 74 4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 5. Useful ALTO extensions for CDNI Request Routing . . . . . . . 10 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 8.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 Many Network Service Providers (NSPs) are currently considering or 86 have already started to deploy Content Delivery Networks (CDNs) 87 within their networks. As a consequence of this development, there 88 is a need for interconnecting these local CDNs. Content Delivery 89 Networks Interconnection (CDNI) has the goal of standardizing 90 protocols to enable such interconnection of CDNs [RFC6707]. 92 The CDNI problem statement [RFC6707] envisions four interfaces to be 93 standardized within the IETF for CDN interconnection: 95 o CDNI Request Routing Interface 96 o CDNI Metadata Interface 98 o CDNI Logging Interface 100 o CDNI Control Interface 102 This document focuses solely on the CDNI Request Routing Interface, 103 which can be further divided into two interfaces (see [RFC6707] for a 104 detailed description): the CDNI Request Routing Redirection interface 105 (RI), and the CDNI Footprint & Capabilities Advertisement interface 106 (FCI). This document specifies a new Application Layer Traffic 107 Optimization (ALTO) [RFC7285] service called 'CDNI Footprint & 108 Capabilities Advertisement Service'. This service is used to 109 transport CDNI FCI JSON objects, which are defined in a separate 110 document in [RFC8008]. 112 Throughout this document, we use the terminology for CDNI defined in 113 [RFC6707]. 115 2. ALTO within CDNI Request Routing 117 The main purpose of the CDNI Request Routing Interface is described 118 in [RFC6707] as follows: "The CDNI Request Routing interface enables 119 a Request Routing function in an Upstream CDN to query a Request 120 Routing function in a Downstream CDN to determine if the Downstream 121 CDN is able (and willing) to accept the delegated Content Request. 122 It also allows the Downstream CDN to control what should be returned 123 to the User Agent in the redirection message by the upstream Request 124 Routing function." On a high level, the scope of the CDNI Request 125 Routing Interface therefore contains two main tasks: 127 o A) Determining if the downstream CDN is willing to accept a 128 delegated content request 130 o B) Redirecting the content request coming from an upstream CDN to 131 the proper entry point or entity in the downstream CDN 133 More precisely, in [RFC7336] the request routing interface is broadly 134 divided into two functionalities: 136 o 1) the asynchronous advertisement of footprint and capabilities by 137 a dCDN that allows a uCDN to decide whether to redirect particular 138 user requests to that dCDN (the CDNI FCI) 140 o 2) the synchronous operation of actually redirecting a user 141 request (the CDNI RI) 143 Application Layer Traffic Optimization (ALTO) [RFC7285] is an 144 approach for guiding the resource provider selection process in 145 distributed applications that can choose among several candidate 146 resources providers to retrieve a given resource. By conveying 147 network layer (topology) information, an ALTO server can provide 148 important information to "guide" the resource provider selection 149 process in distributed applications. Usually, it is assumed that an 150 ALTO server conveys information these applications cannot measure 151 themselves [RFC5693]. 153 Originally, ALTO was motivated by the huge amount of cross-ISP 154 traffic generated by P2P applications [RFC5693]. Recently, however, 155 ALTO is also being considered for improving the request routing in 156 CDNs [I-D.jenkins-alto-cdn-use-cases]. In this context, it has also 157 been proposed to use ALTO for selecting an entry-point in a 158 downstream NSP's network (see section 3.4 "CDN delivering Over-The- 159 Top of a NSP's network" in [I-D.jenkins-alto-cdn-use-cases]). Also, 160 the CDNI problem statement explicitly mentions ALTO as a candidate 161 protocol for "algorithms for selection of CDN or Surrogate by 162 Request-Routing systems" [RFC6707]. 164 3. Assumptions and High-Level Design Considerations 166 In this section we list some assumptions and design issues to be 167 considered when using ALTO for the CDNI Footprint and Capabilities 168 Advertisement interface. 170 3.1. General Assumptions and Considerations 172 Below we list some general assumptions and considerations: 174 o As explicitly being out-of-scope for CDNI [RFC6707], it is assumed 175 that ingestion of content or acquiring content across CDNs is not 176 part of request routing as considered within CDNI standardization 177 work. The focus of using ALTO (as considered in this document) is 178 hence on request routing only, assuming that the content (desired 179 by the end user) is available in the downstream CDN (or can be 180 aquired by the 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" [RFC8008] 212 defines the semantics for the CDNI FCI. It thus provides guidance on 213 what Footprint and Capabilities mean in a CDNI context and how a 214 protocol solution should in principle look like. Here we briefly 215 summarize the key points of the semantics of Footprint and 216 Capabilities (for a detailed discussion, the reader is referred to 217 [RFC8008]): 219 o Often, footprint and capabilities are tied together and cannot be 220 interpreted independently from each other. In such cases, i.e. 221 where capabilities must be expressed on a per footprint basis, it 222 may be beneficial to combine footprint and capabilities 223 advertisement. 225 o Given that a large part of Footprint and Capabilities 226 Advertisement will actually happen in contractual agreements, the 227 semantics of CDNI Footprint and Capabilities advertisement refer 228 to answering the following question: what exactly still needs to 229 be advertised by the CDNI FCI? For instance, updates about 230 temporal failures of part of a footprint can be useful information 231 to convey via the CDNI request routing interface. Such 232 information would provide updates on information previously agreed 233 in contracts between the participating CDNs. In other words, the 234 CDNI FCI is a means for a dCDN to provide changes/updates 235 regarding a footprint and/or capabilities it has prior agreed to 236 serve in a contract with a uCDN. 238 o It seems clear that "coverage/reachability" types of footprint 239 must be supported within CDNI. The following such types of 240 footprint are mandatory and must be supported by the CDNI FCI: 242 * List of ISO Country Codes 244 * List of AS numbers 246 * Set of IP-prefixes 248 A 'set of IP-prefixes' must be able to contain full IP addresses, 249 i.e., a /32 for IPv4 and a /128 for IPv6, and also IP prefixes 250 with an arbitrary prefix length. There must also be support for 251 multiple IP address versions, i.e., IPv4 and IPv6, in such a 252 footprint. 254 o For all of these mandatory-to-implement footprint types, 255 footprints can be viewed as constraints for delegating requests to 256 a dCDN: A dCDN footprint advertisement tells the uCDN the 257 limitations for delegating a request to the dCDN. For IP prefixes 258 or ASN(s), the footprint signals to the uCDN that it should 259 consider the dCDN a candidate only if the IP address of the 260 request routing source falls within the prefix set (or ASN, 261 respectively). The CDNI specifications do not define how a given 262 uCDN determines what address ranges are in a particular ASN. 263 Similarly, for country codes a uCDN should only consider the dCDN 264 a candidate if it covers the country of the request routing 265 source. The CDNI specifications do not define how a given uCDN 266 determines the country of the request routing source. Multiple 267 footprint constraints are additive, i.e. the advertisement of 268 different types of footprint narrows the dCDN candidacy 269 cumulatively. 271 o The following capabilities seem useful as 'base' capabilities, 272 i.e. ones that are needed in any case and therefore constitute 273 mandatory capabilities to be supported by the CDNI FCI: 275 * Delivery Protocol (e.g., HTTP vs. RTMP) 277 * Acquisition Protocol (for aquiring content from a uCDN) 279 * Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as 280 discussed in [RFC7336]) 282 * Capabilities related to CDNI Logging (e.g., supported logging 283 mechanisms) 285 * Capabilities related to CDNI Metadata (e.g., authorization 286 algorithms or support for proprietary vendor metadata) 288 3.3. Advantages of using ALTO as the CDNI FCI protocol 290 The following reasons make ALTO a suitable candidate protocol for 291 downstream CDN selection as part of CDNI request routing and in 292 particular for an FCI protocol: 294 o CDN request routing is done at the application layer. ALTO is a 295 protocol specifically designed to improve application layer 296 traffic (and application layer connections among hosts on the 297 Internet) by providing additonal information to applications that 298 these applications could not easily retrieve themselves. For 299 CDNI, this is exactly the case: a uCDN wants to improve 300 application layer CDN request routing by using dedicated 301 information (provided by a dCDN) that the uCDN could not easily 302 obtain otherwise. 304 o The semantics of an ALTO network map are an exact match for the 305 needed information to convey a footprint by a downstream CDN, in 306 particular if such a footprint is being expressed by IP-prefix 307 ranges. 309 o Security: ALTO maps can be signed and hence provide inherent 310 integrity protection (see Section 6) 312 o RESTful-Design: The ALTO protocol has undergone extensive 313 revisions in order to provide a RESTful design regarding the 314 client-server interaction specified by the protocol. A CDNI FCI 315 interface based on ALTO would inherit this RESTful design. 317 o Error-handling: The ALTO protocol has undergone extensive 318 revisions in order to provide sophisticated error-handling, 319 inparticular regarding unexpected cases. A CDNI FCI interface 320 based on ALTO would inherit this thought-through and mature error- 321 handling. 323 o Filtered network map: The ALTO Map Filtering Service (see 324 [RFC7285] for details) would allow a uCDN to query only for parts 325 of an ALTO map. 327 3.4. Selection of a Downstream CDN with ALTO 329 Under the considerations stated in Section 3, ALTO can help the 330 upstream CDN provider to select a proper downstream CDN provider for 331 a given end user request as follows: Each downstream CDN provider 332 hosts an ALTO server which provides ALTO services which convey CDNI 333 FCI information to an ALTO client at the upstream CDN provider. 335 4. CDNI FCI ALTO Service 337 The ALTO protocol is based on an ALTO Information Service Framework 338 which consists of several services, where all ALTO services are 339 'provided through a common transport protocol, messaging structure 340 and encoding, and transaction model' [RFC7285]. The ALTO protocol 341 specification [RFC7285] defines several such services, e.g. the ALTO 342 map service. 344 This document defines a new ALTO Service called 'CDNI Footprint & 345 Capabilities Advertisement Service' which conveys JSON objects of 346 media type 'application/alto-fcimap+json'. This media type and JSON 347 object format is defined in [RFC8008]; this document specifies how to 348 transport such JSON objects via the ALTO protocol with the ALTO 'CDNI 349 Footprint & Capabilities Advertisement Service'. 351 4.1. Server Response Encoding 353 4.1.1. CDNI FCI Map 355 The media type of the CDNI FCI Map is 'application/alto-cdni- 356 fcimap+json'. The HTTP Method, Accept Input Parameters, 357 Capabilities, Uses, and Response of the CDNI FCI Map are specified in 358 [I-D.ma-cdni-capabilities]. 360 4.1.2. Meta Information 362 The 'meta' field of a FCIMapData response MUST include 'vtag', which 363 is an ALTO Version Tag of the retrieved FCIMapData according to 364 [RFC7285] (Section 10.3.). It thus contains a 'resource-id' 365 attribute, and a 'tag' is an identifier string. 367 4.1.3. Data Information 369 The data component of a CDNI FCI Map resource is named 'fcimap' which 370 is a JSON object of type FCIMapData. This JSON object of type 371 FCIMapData is derived from ResponseEntityBase as specified in the 372 ALTO protocol [RFC7285] (Section 8.4.) and specified in 373 [I-D.ma-cdni-capabilities]. 375 4.2. Protocol Errors 377 Protocol errors are handled as specified in the ALTO protocol 378 [RFC7285] (Section 8.5.). 380 4.3. Example 382 The following example shows an CDNI FCI Map as in 383 [I-D.ma-cdni-capabilities], however with meta-information as defined 384 in Section 4.1.2 of this document. 386 GET /fcimap HTTP/1.1 387 Host: alto.example.com 388 Accept: application/alto-fcimap+json,application/alto-error+json 390 HTTP/1.1 200 OK 391 Content-Length: 439 392 Content-Type: application/alto-fcimap+json 393 { 394 "meta" : { 395 "vtag": { 396 "resource-id": "my-default-fcimap", 397 "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" 398 } 399 }, 400 "fcimap": [ 401 { "name": "delivery_protocol", 402 "values": [ 403 "HTTP", 404 "RTSP", 405 "MMS" 406 ] 407 }, 408 { "name": "delivery_protocol", 409 "values": [ 410 "RTMP", 411 "HTTPS" 412 ], 413 "footprint": [ 414 { "type": "IPv4CIDR", 415 "values": [ 416 "10.1.0.0/16", 417 "10.10.10.0/24" 418 ] 419 } 420 ] 421 } 422 ] 423 } 425 5. Useful ALTO extensions for CDNI Request Routing 427 It is envisioned that yet-to-be-defined ALTO extensions will be 428 standardized that make the ALTO protocol more suitable and useful for 429 applications other than the originally considered P2P use case 430 [I-D.marocco-alto-next]. Some of these extensions to the ALTO 431 protocol would be useful for ALTO to be used as a protocol within 432 CDNI request routing, and in particular within the "Footprint and 433 Capabilities Advertisment" part of the CDNI request routing 434 interface. 436 The following proposed extensions to ALTO would be beneficial to 437 facilitate CDNI request routing with ALTO as outlined in Section 3.4: 439 o Server-initiated Notifications and Incremental Updates: In case 440 the footprint or the capabilities of a downstream CDN change 441 abruptly (i.e. unexpectedly from the perspective of an upstream 442 CDN), server initiated notifications would enable a dCDN to 443 directly inform an upstream CDN about such changes. Consider the 444 case where - due to failure - part of the footprint of the dCDN is 445 not functioning, i.e. the CDN cannot serve content to such clients 446 with reasonable QoS. Without server-initiated notifications, the 447 uCDN might still use a very recent network and cost map from dCDN, 448 and therefore redirect request to dCDN which it cannot serve. 449 Similarly, the possibility for incremental updates would enable 450 efficient conveyance of the aforementioned (or similar) status 451 changes by the dCDN to the uCDN. A proposal for server-initiated 452 ALTO updates can be found in [I-D.marocco-alto-ws]. A discussion 453 of incremental ALTO updates can be found in 454 [I-D.schwan-alto-incr-updates]. 456 o Content Availability on Hosts: A dCDN might want to express CDN 457 capabilties in terms of certain content types (e.g. codecs/ 458 formats, or content from certain content providers). A new 459 endpoint property for ALTO that would be able to express such 460 "content availability" would enable a dCDN to make available such 461 information to an upstream CDN. This would enable a uCDN to 462 determine if a given dCDN actually has the capabilities for a 463 given request with respect to the type of content requested. 465 o Resource Availability on Hosts or Links: The capabilities on links 466 (e.g. maximum bandwidth) or caches (e.g. average load) might be 467 useful information for an upstream CDN for optimized dowmstream 468 CDN selection. For instance, if a uCDN receives a streaming 469 request for content with a certain bitrate, it needs to know if it 470 is likely that a dCDN can fulfill such stringent application-level 471 requirements (i.e. can be expected to have enough consistent 472 bandwidth) before it redirects the request. In general, if ALTO 473 could convey such information via new endpoint properties, it 474 would enable more sophisticated means for downstream CDN selection 475 with ALTO. 477 6. Security Considerations 479 One important security consideration is the proper authentication of 480 advertisement information provided by a downstream CDN. The ALTO 481 protocol provides a specification for a signature of ALTO information 482 (see 8.2.2. of [RFC7285]. ALTO thus provides a proper means for 483 protecting the integrity of FCI information. 485 More Security Considerations will be discussed in a future version of 486 this document. 488 7. Acknowledgements 490 The authors would like to thank Kevin Ma, Daryl Malas, and Matt 491 Caulfield for their timely reviews and invaluable comments. 493 Jan Seedorf is partially supported by the GreenICN project (GreenICN: 494 Architecture and Applications of Green Information Centric 495 Networking), a research project supported jointly by the European 496 Commission under its 7th Framework Program (contract no. 608518) and 497 the National Institute of Information and Communications Technology 498 (NICT) in Japan (contract no. 167). The views and conclusions 499 contained herein are those of the authors and should not be 500 interpreted as necessarily representing the official policies or 501 endorsements, either expressed or implied, of the GreenICN project, 502 the European Commission, or NICT. 504 8. References 506 8.1. Normative References 508 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 509 Optimization (ALTO) Problem Statement", RFC 5693, 510 DOI 10.17487/RFC5693, October 2009, 511 . 513 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 514 Distribution Network Interconnection (CDNI) Problem 515 Statement", RFC 6707, DOI 10.17487/RFC6707, September 516 2012, . 518 [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, 519 P., Ma, K., and G. Watson, "Use Cases for Content Delivery 520 Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, 521 November 2012, . 523 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 524 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 525 "Application-Layer Traffic Optimization (ALTO) Protocol", 526 RFC 7285, DOI 10.17487/RFC7285, September 2014, 527 . 529 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 530 "Framework for Content Distribution Network 531 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 532 August 2014, . 534 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 535 Network Interconnection (CDNI) Requirements", RFC 7337, 536 DOI 10.17487/RFC7337, August 2014, 537 . 539 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 540 R., and K. Ma, "Content Delivery Network Interconnection 541 (CDNI) Request Routing: Footprint and Capabilities 542 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 543 . 545 8.2. Informative References 547 [I-D.marocco-alto-next] 548 Marocco, E. and V. Gurbani, "Extending the Application- 549 Layer Traffic Optimization (ALTO) Protocol", draft- 550 marocco-alto-next-00 (work in progress), January 2012. 552 [I-D.marocco-alto-ws] 553 Marocco, E. and J. Seedorf, "WebSocket-based server-to- 554 client notifications for the Application-Layer Traffic 555 Optimization (ALTO) Protocol", draft-marocco-alto-ws-02 556 (work in progress), February 2014. 558 [I-D.schwan-alto-incr-updates] 559 Schwan, N. and B. Roome, "ALTO Incremental Updates", 560 draft-schwan-alto-incr-updates-02 (work in progress), July 561 2012. 563 [I-D.jenkins-alto-cdn-use-cases] 564 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 565 S. Previdi, "Use Cases for ALTO within CDNs", draft- 566 jenkins-alto-cdn-use-cases-03 (work in progress), June 567 2012. 569 [I-D.ma-cdni-capabilities] 570 Ma, K. and J. Seedorf, "CDNI Footprint & Capabilities 571 Advertisement Interface", draft-ma-cdni-capabilities-09 572 (work in progress), April 2016. 574 Authors' Addresses 576 Jan Seedorf 577 HFT Stuttgart - Univ. of Applied Sciences 578 Schellingstrasse 24 579 Stuttgart 70174 580 Germany 582 Phone: +49-0711-8926-2801 583 Email: jan.seedorf@hft-stuttgart.de 585 Y.R. Yang 586 Tongji/Yale University 587 51 Prospect Street 588 New Haven, CT 06511 589 United States of America 591 Email: yry@cs.yale.edu 592 URI: http://www.cs.yale.edu/~yry/ 594 Jon Peterson 595 NeuStar 596 1800 Sutter St Suite 570 597 Concord, CA 94520 598 United States of America 600 Email: jon.peterson@neustar.biz