idnits 2.17.1 draft-ietf-alto-cdni-request-routing-alto-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC8008], [RFC7336]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 343: '...f a FCI 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 20, 2017) is 2465 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 444, but no explicit reference was found in the text == Unused Reference: 'RFC7337' is defined on line 460, but no explicit reference was found in the text == Unused Reference: 'I-D.ma-cdni-capabilities' is defined on line 489, 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 == Outdated reference: A later version (-22) exists of draft-ietf-alto-incr-update-sse-07 Summary: 8 errors (**), 0 flaws (~~), 5 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 21, 2018 Tongji/Yale 6 K. Ma 7 Ericsson 8 J. Peterson 9 Neustar 10 July 20, 2017 12 Content Delivery Network Interconnection (CDNI) Request Routing: CDNI 13 Footprint and Capabilities Advertisement using ALTO 14 draft-ietf-alto-cdni-request-routing-alto-00 16 Abstract 18 The Content Delivery Networks Interconnection (CDNI) WG is defining a 19 set of protocols to inter-connect CDNs, to achieve multiple goals 20 such as extending the reach of a given CDN to areas that are not 21 covered by that particular CDN. One componet that is needed to 22 achieve the goal of CDNI is the CDNI Request Routing Footprint & 23 Capabilities Advertisement interface (FCI) [RFC7336]. [RFC8008] has 24 defined precisely the semantics of FCI and provided guidelines on the 25 FCI protocol, but the exact protocol is explicitly outside the scope 26 of that document. In this document, we define an FCI protocol using 27 the Application Layer Traffic Optimization (ALTO) protocol. 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 January 21, 2018. 46 Copyright Notice 48 Copyright (c) 2017 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. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Semantics of FCI Advertisment . . . . . . . . . . . . . . 4 66 2.2. ALTO Background and Benefits . . . . . . . . . . . . . . 5 67 3. CDNI FCI ALTO Service . . . . . . . . . . . . . . . . . . . . 7 68 3.1. Server Response Encoding . . . . . . . . . . . . . . . . 8 69 3.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 8 70 3.1.2. Meta Information . . . . . . . . . . . . . . . . . . 8 71 3.1.3. Data Information . . . . . . . . . . . . . . . . . . 8 72 3.2. Protocol Errors . . . . . . . . . . . . . . . . . . . . . 8 73 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 74 3.3.1. Basic Example . . . . . . . . . . . . . . . . . . . . 8 75 3.3.2. Incremental FCI Update Example . . . . . . . . . . . 9 76 3.3.3. FCI Using ALTO Network Map Example . . . . . . . . . 9 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 79 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 81 6.2. Informative References . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 Many Network Service Providers (NSPs) are currently considering or 87 have already started to deploy Content Delivery Networks (CDNs) 88 within their networks. As a consequence of this development, there 89 is a need for interconnecting these local CDNs. Content Delivery 90 Networks Interconnection (CDNI) has the goal of standardizing 91 protocols to enable such interconnection of CDNs [RFC6707]. 93 The CDNI problem statement [RFC6707] defines four interfaces to be 94 standardized within the IETF for CDN interconnection: 96 o CDNI Request Routing Interface 98 o CDNI Metadata Interface 100 o CDNI Logging Interface 102 o CDNI Control Interface 104 The main purpose of the CDNI Request Routing Interface is described 105 in [RFC6707] as follows: "The CDNI Request Routing interface enables 106 a Request Routing function in an Upstream CDN to query a Request 107 Routing function in a Downstream CDN to determine if the Downstream 108 CDN is able (and willing) to accept the delegated Content Request. 109 It also allows the Downstream CDN to control what should be returned 110 to the User Agent in the redirection message by the upstream Request 111 Routing function." On a high level, the scope of the CDNI Request 112 Routing Interface therefore contains two main tasks: 114 o determining if the downstream CDN is willing to accept a delegated 115 content request; 117 o redirecting the content request coming from an upstream CDN to the 118 proper entry point or entity in the downstream CDN. 120 Correspondingly, the request routing interface is broadly divided 121 into two functionalities: 123 o CDNI FCI: the advertisement from a dCDN to a uCDN or a query from 124 a uCDN to a dCDN for the uCDN to decide whether to redirect 125 particular user requests to that dCDN; 127 o CDNI RI: the synchronous operation of actually redirecting a user 128 request. 130 This document focuses solely on CDNI FCI, with a goal to specify a 131 new Application Layer Traffic Optimization (ALTO) [RFC7285] service 132 called 'CDNI/FCI Service', to transport and update CDNI FCI JSON 133 objects, which are defined in a separate document in [RFC8008]. 135 Throughout this document, we use the terminology for CDNI defined in 136 [RFC6707] and [RFC8008]. 138 2. Background 140 The design of CDNI FCI transport using ALTO depends on understanding 141 of both FCI semantics and ALTO. Hence, we start with a review of 142 both. 144 2.1. Semantics of FCI Advertisment 146 The CDNI document on "Footprint and Capabilities Semantics" [RFC8008] 147 defines the semantics for the CDNI FCI. It thus provides guidance on 148 what Footprint and Capabilities mean in a CDNI context and how a 149 protocol solution should in principle look like. The definitions in 150 [RFC8008] depend on [RFC8006]. Here we briefly summarize key related 151 points of [RFC8008] and [RFC8006]. For a detailed discussion, the 152 reader is referred to the RFCs. 154 o Footprint and capabilities are tied together and cannot be 155 interpreted independently from each other. In such cases, i.e. 156 where capabilities must be expressed on a per footprint basis, it 157 may be beneficial to combine footprint and capabilities 158 advertisement. [RFC8008] integrates footprint and capabilities 159 with an approach of "capabilities with footprint restrictions". 161 o Given that a large part of Footprint and Capabilities 162 Advertisement will actually happen in contractual agreements, the 163 semantics of CDNI Footprint and Capabilities advertisement refer 164 to answering the following question: what exactly still needs to 165 be advertised by the CDNI FCI? For instance, updates about 166 temporal failures of part of a footprint can be useful information 167 to convey via the CDNI request routing interface. Such 168 information would provide updates on information previously agreed 169 in contracts between the participating CDNs. In other words, the 170 CDNI FCI is a means for a dCDN to provide changes/updates 171 regarding a footprint and/or capabilities it has prior agreed to 172 serve in a contract with a uCDN. Hence, server push and 173 incremental encoding will be necessary techniques. 175 o Multiple types of footprints are defined in [RFC8006]: 177 * List of ISO Country Codes 179 * List of AS numbers 181 * Set of IP-prefixes 183 A 'set of IP-prefixes' must be able to contain full IP addresses, 184 i.e., a /32 for IPv4 and a /128 for IPv6, and also IP prefixes 185 with an arbitrary prefix length. There must also be support for 186 multiple IP address versions, i.e., IPv4 and IPv6, in such a 187 footprint. 189 o For all of these mandatory-to-implement footprint types, 190 footprints can be viewed as constraints for delegating requests to 191 a dCDN: A dCDN footprint advertisement tells the uCDN the 192 limitations for delegating a request to the dCDN. For IP prefixes 193 or ASN(s), the footprint signals to the uCDN that it should 194 consider the dCDN a candidate only if the IP address of the 195 request routing source falls within the prefix set (or ASN, 196 respectively). The CDNI specifications do not define how a given 197 uCDN determines what address ranges are in a particular ASN. 198 Similarly, for country codes a uCDN should only consider the dCDN 199 a candidate if it covers the country of the request routing 200 source. The CDNI specifications do not define how a given uCDN 201 determines the country of the request routing source. Multiple 202 footprint constraints are additive, i.e. the advertisement of 203 different types of footprint narrows the dCDN candidacy 204 cumulatively. 206 o The following capabilities are defined as 'base' capabilities, 207 i.e. ones that are needed in any case and therefore constitute 208 mandatory capabilities to be supported by the CDNI FCI: 210 * Delivery Protocol (e.g., HTTP vs. RTMP) 212 * Acquisition Protocol (for acquiring content from a uCDN) 214 * Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as 215 discussed in [RFC7336]) 217 * Capabilities related to CDNI Logging (e.g., supported logging 218 mechanisms) 220 * Capabilities related to CDNI Metadata (e.g., authorization 221 algorithms or support for proprietary vendor metadata) 223 2.2. ALTO Background and Benefits 225 Application Layer Traffic Optimization (ALTO) [RFC7285] is an 226 approach for guiding the resource provider selection process in 227 distributed applications that can choose among several candidate 228 resources providers to retrieve a given resource. By conveying 229 network layer (topology) information, an ALTO server can provide 230 important information to "guide" the resource provider selection 231 process in distributed applications. Usually, it is assumed that an 232 ALTO server conveys information these applications cannot measure 233 themselves [RFC5693]. 235 Originally, ALTO was motivated by the huge amount of cross-ISP 236 traffic generated by P2P applications [RFC5693]. Recently, however, 237 ALTO is also being considered for improving the request routing in 238 CDNs [I-D.jenkins-alto-cdn-use-cases]. In this context, it has also 239 been proposed to use ALTO for selecting an entry-point in a 240 downstream NSP's network (see section 3.4 "CDN delivering Over-The- 241 Top of a NSP's network" in [I-D.jenkins-alto-cdn-use-cases]). Also, 242 the CDNI problem statement explicitly mentions ALTO as a candidate 243 protocol for "algorithms for selection of CDN or Surrogate by 244 Request-Routing systems" [RFC6707]. 246 The following reasons make ALTO a suitable candidate protocol for 247 downstream CDN selection as part of CDNI request routing and in 248 particular for an FCI protocol: 250 o CDN request routing is done at the application layer. ALTO is a 251 protocol specifically designed to improve application layer 252 traffic (and application layer connections among hosts on the 253 Internet) by providing additional information to applications that 254 these applications could not easily retrieve themselves. For 255 CDNI, this is exactly the case: a uCDN wants to improve 256 application layer CDN request routing by using dedicated 257 information (provided by a dCDN) that the uCDN could not easily 258 obtain otherwise. 260 o The semantics of an ALTO network map are an exact match for the 261 needed information to convey a footprint by a downstream CDN, in 262 particular if such a footprint is being expressed by IP-prefix 263 ranges. 265 o Security: ALTO maps can be signed and hence provide inherent 266 integrity protection (see Section 4) 268 o RESTful-Design: The ALTO protocol has undergone extensive 269 revisions in order to provide a RESTful design regarding the 270 client-server interaction specified by the protocol. A CDNI FCI 271 interface based on ALTO would inherit this RESTful design. 273 o Error-handling: The ALTO protocol has undergone extensive 274 revisions in order to provide sophisticated error-handling, in 275 particular regarding unexpected cases. A CDNI FCI interface based 276 on ALTO would inherit this thought-through and mature error- 277 handling. 279 o Filtered network map: The ALTO Map Filtering Service (see 280 [RFC7285] for details) would allow a uCDN to query only for parts 281 of an ALTO map. 283 o Server-initiated Notifications and Incremental Updates: In case 284 the footprint or the capabilities of a downstream CDN change 285 abruptly (i.e. unexpectedly from the perspective of an upstream 286 CDN), server initiated notifications would enable a dCDN to 287 directly inform an upstream CDN about such changes. Consider the 288 case where - due to failure - part of the footprint of the dCDN is 289 not functioning, i.e. the CDN cannot serve content to such clients 290 with reasonable QoS. Without server-initiated notifications, the 291 uCDN might still use a very recent network and cost map from dCDN, 292 and therefore redirect request to dCDN which it cannot serve. 293 Similarly, the possibility for incremental updates would enable 294 efficient conveyance of the aforementioned (or similar) status 295 changes by the dCDN to the uCDN. The newest design of ALTO 296 supports server pushed incremental updates 297 [I-D.ietf-alto-incr-update-sse]. 299 o Content Availability on Hosts: A dCDN might want to express CDN 300 capabilities in terms of certain content types (e.g. codecs/ 301 formats, or content from certain content providers). The new 302 endpoint property for ALTO would enable a dCDN to make available 303 such information to an upstream CDN. This would enable a uCDN to 304 determine if a given dCDN actually has the capabilities for a 305 given request with respect to the type of content requested. 307 o Resource Availability on Hosts or Links: The capabilities on links 308 (e.g. maximum bandwidth) or caches (e.g. average load) might be 309 useful information for an upstream CDN for optimized downstream 310 CDN selection. For instance, if a uCDN receives a streaming 311 request for content with a certain bitrate, it needs to know if it 312 is likely that a dCDN can fulfill such stringent application-level 313 requirements (i.e. can be expected to have enough consistent 314 bandwidth) before it redirects the request. In general, if ALTO 315 could convey such information via new endpoint properties, it 316 would enable more sophisticated means for downstream CDN selection 317 with ALTO. 319 3. CDNI FCI ALTO Service 321 The ALTO protocol is based on an ALTO Information Service Framework 322 which consists of several services, where all ALTO services are 323 'provided through a common transport protocol, messaging structure 324 and encoding, and transaction model' [RFC7285]. The ALTO protocol 325 specification [RFC7285] defines several such services, e.g. the ALTO 326 map service. 328 This document defines a new ALTO Service called 'CDNI Footprint & 329 Capabilities Advertisement Service' which conveys JSON objects of 330 media type 'application/cdni'. This media type and JSON object 331 format is defined in [RFC8006] and [RFC8008]; this document specifies 332 how to transport such JSON objects via the ALTO protocol with the 333 ALTO 'CDNI Footprint & Capabilities Advertisement Service'. 335 3.1. Server Response Encoding 337 3.1.1. Media Type 339 The media type of the CDNI FCI Map is 'application/cdni'. 341 3.1.2. Meta Information 343 The 'meta' field of a FCI response MUST include 'vtag', which is an 344 ALTO Version Tag of the retrieved FCIMapData according to [RFC7285] 345 (Section 10.3.). It thus contains a 'resource-id' attribute, and a 346 'tag' is an identifier string. 348 3.1.3. Data Information 350 The data component of a CDNI FCI resource is named 'cdni-fcimap' 351 which is a JSON object defined by [RFC8008]. This JSON object is 352 derived from ResponseEntityBase as specified in the ALTO protocol 353 [RFC7285] (Section 8.4.). 355 3.2. Protocol Errors 357 Protocol errors are handled as specified in the ALTO protocol 358 [RFC7285] (Section 8.5.). 360 3.3. Examples 362 3.3.1. Basic Example 364 The following example shows an CDNI FCI response as in [RFC8008], 365 however with meta-information as defined in Section 3.1.2 of this 366 document. 368 GET /fcimap HTTP/1.1 369 Host: alto.example.com 370 Accept: application/cdni,application/alto-error+json 372 HTTP/1.1 200 OK 373 Content-Length: 439 374 Content-Type: application/cdni 375 { 376 "meta" : { 377 "vtag": { 378 "resource-id": "my-default-fcimap", 379 "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785" 380 } 381 }, 382 "cdni-fcimap": { 383 "capabilities": [ 384 { 385 "capability-type": "FCI.DeliveryProtocol", 386 "capability-value": { 387 "delivery-protocols": [ 388 "http/1.1", 389 ] 390 }, 391 "footprints": [ 392 393 ] 394 } 395 ] 396 } 397 } 399 3.3.2. Incremental FCI Update Example 401 3.3.3. FCI Using ALTO Network Map Example 403 4. Security Considerations 405 One important security consideration is the proper authentication of 406 advertisement information provided by a downstream CDN. The ALTO 407 protocol provides a specification for a signature of ALTO information 408 (see 8.2.2. of [RFC7285]. ALTO thus provides a proper means for 409 protecting the integrity of FCI information. 411 More Security Considerations will be discussed in a future version of 412 this document. 414 5. Acknowledgements 416 The authors would like to thank Kevin Ma, Daryl Malas, and Matt 417 Caulfield for their timely reviews and invaluable comments. 419 Jan Seedorf is partially supported by the GreenICN project (GreenICN: 420 Architecture and Applications of Green Information Centric 421 Networking), a research project supported jointly by the European 422 Commission under its 7th Framework Program (contract no. 608518) and 423 the National Institute of Information and Communications Technology 424 (NICT) in Japan (contract no. 167). The views and conclusions 425 contained herein are those of the authors and should not be 426 interpreted as necessarily representing the official policies or 427 endorsements, either expressed or implied, of the GreenICN project, 428 the European Commission, or NICT. 430 6. References 432 6.1. Normative References 434 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 435 Optimization (ALTO) Problem Statement", RFC 5693, 436 DOI 10.17487/RFC5693, October 2009, 437 . 439 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 440 Distribution Network Interconnection (CDNI) Problem 441 Statement", RFC 6707, DOI 10.17487/RFC6707, September 442 2012, . 444 [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, 445 P., Ma, K., and G. Watson, "Use Cases for Content Delivery 446 Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, 447 November 2012, . 449 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 450 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 451 "Application-Layer Traffic Optimization (ALTO) Protocol", 452 RFC 7285, DOI 10.17487/RFC7285, September 2014, 453 . 455 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 456 "Framework for Content Distribution Network 457 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 458 August 2014, . 460 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 461 Network Interconnection (CDNI) Requirements", RFC 7337, 462 DOI 10.17487/RFC7337, August 2014, 463 . 465 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 466 "Content Delivery Network Interconnection (CDNI) 467 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 468 . 470 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 471 R., and K. Ma, "Content Delivery Network Interconnection 472 (CDNI) Request Routing: Footprint and Capabilities 473 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 474 . 476 6.2. Informative References 478 [I-D.ietf-alto-incr-update-sse] 479 Roome, W. and Y. Yang, "ALTO Incremental Updates Using 480 Server-Sent Events (SSE)", draft-ietf-alto-incr-update- 481 sse-07 (work in progress), July 2017. 483 [I-D.jenkins-alto-cdn-use-cases] 484 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 485 S. Previdi, "Use Cases for ALTO within CDNs", draft- 486 jenkins-alto-cdn-use-cases-03 (work in progress), June 487 2012. 489 [I-D.ma-cdni-capabilities] 490 Ma, K. and J. Seedorf, "CDNI Footprint & Capabilities 491 Advertisement Interface", draft-ma-cdni-capabilities-09 492 (work in progress), April 2016. 494 Authors' Addresses 496 Jan Seedorf 497 HFT Stuttgart - Univ. of Applied Sciences 498 Schellingstrasse 24 499 Stuttgart 70174 500 Germany 502 Phone: +49-0711-8926-2801 503 Email: jan.seedorf@hft-stuttgart.de 504 Y.R. Yang 505 Tongji/Yale University 506 51 Prospect Street 507 New Haven, CT 06511 508 United States of America 510 Email: yry@cs.yale.edu 511 URI: http://www.cs.yale.edu/~yry/ 513 Kevin J. Ma 514 Ericsson 515 43 Nagog Park 516 Acton, MA 01720 517 United States of America 519 Phone: +1-978-844-5100 520 Email: kevin.j.ma@ericsson.com 522 Jon Peterson 523 NeuStar 524 1800 Sutter St Suite 570 525 Concord, CA 94520 526 United States of America 528 Email: jon.peterson@neustar.biz