idnits 2.17.1 draft-ietf-cdni-request-routing-extensions-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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2018) is 2018 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) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Finkelman 3 Internet-Draft Qwilt 4 Intended status: Standards Track S. Mishra 5 Expires: April 20, 2019 Verizon 6 October 17, 2018 8 CDNI Request Routing Extensions 9 draft-ietf-cdni-request-routing-extensions-00 11 Abstract 13 The Open Caching working group of the Streaming Video Alliance is 14 focused on the delegation of video delivery requests from commercial 15 CDNs to a caching layer at the ISP. In that aspect, Open Caching is 16 a specific use case of CDNI, where the commercial CDN is the upstream 17 CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN). 18 The extensions specified in this document to the CDNI Metadata and 19 FCI interfaces are derived from requirements raised by Open Caching 20 but are applicable to CDNI use cases in general. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 20, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Redirect Target Address Capability Object . . . . . . . . . . 3 65 2.1. DnsTarget . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2.2. HttpTarget . . . . . . . . . . . . . . . . . . . . . . . 6 67 3. Fallback Target Address Metadata . . . . . . . . . . . . . . 7 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 4.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 9 70 4.1.1. CDNI FCI RedirectTarget Payload Type . . . . . . . . 9 71 4.1.2. CDNI MI FallbackTarget Payload Type . . . . . . . . . 9 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 8.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 This document defines objects needed for Open Caching request 83 routing. For that purpose it extends CDNI metadata [RFC8006] and 84 CDNI Footprint and Capabilities [RFC8008]. For consistency, this 85 document follows the CDNI notation of uCDN (the commercial CDN) and 86 dCDN (the ISP caching layer). 88 This document also registers CDNI Payload Types [RFC7736] for the 89 defined objects: 91 o Redirect Target Capability (for dCDN advertising redirect target 92 address) 94 o Fallback Target Metadata (for uCDN configuring fallback target 95 address) 97 1.1. Terminology 99 This document reuses the terminology defined in [RFC6707], [RFC8006], 100 [RFC8007], and [RFC8008]. 102 Additionally, the following terms are used throughout this document 103 and are defined as follows: 105 o RR - Request Router 107 o CP - Content Provider 109 2. Redirect Target Address Capability Object 111 Iterative request redirect as defined in section 1.1 of [RFC7336] 112 requries the provisioning of a redirect target address to be used by 113 the uCDN in order to redirect to the dCDN. Redirect target addresses 114 can vary between different footprints, for example between different 115 regions, and they may also change over time, for example due to 116 scaling issues a dCDN may need to split different regions over 117 multiple targets, or due to network problems the dCDN may have to 118 change the target address. Due to this variable and dynamic nature 119 of the redirect target, it may not be suitable to advertise it during 120 bootstrap, and a more dynamic, and footprint oriented interface is 121 required. Therefore, we have chosen to use the CDNI Footprint and 122 Capabilities interface for redirect target advertisement. 124 Use cases 126 o Footprint: The dCDN may want to have a different target per 127 footprint. Note that a dCDN may spread across multiple 128 geographies. This makes it easier to route client requests to a 129 nearby request router. Though this can be achieved using a single 130 canonical name and Geo DNS, that approach has limitations; for 131 example a client may be using third party DNS resolver, making it 132 impossible for the redirector to detect where the client is 133 located, or Geo DNS granularity may be too rough for the 134 requirement of the application. 136 o Scaling: The dCDN may choose to scale its request routing service 137 by deploying more request routers in new locations and advertise 138 them via an updatable interface like the FCI. 140 The Redirect Target capability object is used to indicate the target 141 address the uCDN should use in order to redirect a client to the 142 dCDN. A target may be attached to a specific uCDN host, a list of 143 uCDN hosts, or it can be set globally for all the hosts of the uCDN. 145 When dCDN is attaching the redirect target to a specific uCDN host or 146 a list of uCDN hosts, the dCDN MUST advertise the hosts within the 147 Redirect Target Capability object as "redirecting-hosts". In that 148 case, the uCDN can redirect to that dCDN address, only if the request 149 is of one of these uCDN hosts. 151 A redirect target for DNS redirection is the FQDN to be used as a 152 CNAME for the uCDN host (see [RFC1034]). 154 A redirect target for HTTP redirection is the hostname to be used as 155 the first path segment in an absolute URI which is used as the 156 Location header of the HTTP rediret response (see section 7.1.2 of 157 [RFC7231]). 159 Property: redirecting-hosts 161 Description: One or more uCDN hosts to which this redirect 162 target is attached. A redirecting host SHOULD be a host that 163 was published in a HostMatch object by the uCDN as defined in 164 section 4.1.2 of [RFC8006]. 166 Type: A list of Endpoint objects (see section 4.3.3 of 167 [RFC8006]) 169 Mandatory-to-Specify: No. If not present, or empty, the 170 redirect target applies to all hosts of the redirecting uCDN. 172 Property: dns-target 174 Description: Target address for DNS CNAME delegation. 176 Type: DnsTarget object (see Section 2.1) 178 Mandatory-to-Specify: No. but at least one of "dns-target" or 179 "http-target" MUST be present and non empty. 181 Property: http-target 183 Description: Target URL for HTTP redirect. 185 Type: HttpTarget object (see Section 2.2) 187 Mandatory-to-Specify: No. but at least one of "dns-target" or 188 "http-target" MUST be present and non empty. 190 Example of Redirect Target Capability object that advertises a dCDN 191 target address that is attached to a specific list of uCDN 192 "redirecting-hosts". A uCDN host that is included in that list can 193 redirect to the advertised dCDN redirect target. 195 { 196 "capabilities": [ 197 { 198 "capability-type": "FCI.RedirectTarget", 199 "capability-value": { 200 "redirecting-hosts": [ 201 "a.service123.ucdn.example.com", 202 "b.service123.ucdn.example.com" 203 ] 204 "dns-target": { 205 "host": "service123.ucdn.example.dcdn.com" 206 } 207 "http-target": { 208 209 } 210 }, 211 "footprints": [ 212 213 ] 214 } 215 ] 216 } 218 2.1. DnsTarget 220 The DnsTarget object is the target address for CNAME delegation from 221 the uCDN to the dCDN. 223 Property: host 225 Description: The host property is a hostname, without a port 226 number. 228 Type: Endpoint object as defined in section 4.3.3 of [RFC8006] 229 with the limitation that it MUST only be a hostname, and it 230 MUST NOT include a port number. 232 Mandatory-to-Specify: Yes. 234 Example of DnsTarget object: 236 { 237 "host": "service123.ucdn.example.dcdn.com" 238 } 240 Example of a DNS query for uCDN address 241 "a.service123.ucdn.example.com" and the corresponding CNAME 242 redirection response: 244 Query: 245 a.service123.ucdn.example.com: 246 type A, class IN 248 Response: 249 a.service123.ucdn.example.com: 250 type CNAME, class IN, cname service123.ucdn.example.dcdn.com 252 2.2. HttpTarget 254 The HttpTarget object is the target address for http redirection from 255 the uCDN to the dCDN. 257 Property: host 259 Description: Hostname or IP address and optional port, i.e., 260 the host and port as described in section 3.2 of [RFC3986]. 262 Type: Endpoint object as defined in section 4.3.3 of [RFC8006]. 264 Mandatory-to-Specify: Yes. 266 Property: path-prefix 268 Description: A path prefix for the HTTP redirect. The original 269 path is appended after this prefix. 271 Type: A prefix of a path-absolute as defined in section 3.3 of 272 [RFC3986]. The prefix MUST end with a trailing slash, to 273 indicate the end of the last path segment in the prefix. 275 Mandatory-to-Specify: No. If this property is absent or empty, 276 the uCDN MUST NOT prepend a path prefix to the original content 277 path. 279 Property: include-redirecting-host 281 Description: A flag indicating whether or not to include the 282 redirecting host as the first path segment after the path- 283 prefix. In case this flag is true and a "path-prefix" is used, 284 the uCDN redirecting host MUST be added as a separate path 285 segment after the path-prefix and before the original URL path. 286 In case this flag is true and there is no path-prefix, the uCDN 287 redirecting host MUST be perpended as the first path segment in 288 the redirect URL. 290 Type: Boolean. 292 Mandatory-to-Specify: No. Default value is False. 294 Example of HttpTarget object with a path-prefix and include- 295 redirecting-host: 297 { 298 "host": "us-east1.dcdn.com", 299 "path-prefix": "/cache/1/", 300 "include-redirecting-host": true 301 } 303 Example of a HTTP request for content at uCDN host 304 "a.service123.ucdn.example.com" and the corresponding HTTP response 305 with Location header used for redirecting the client to the dCDN 306 using the the http-target in the above example: 308 Request: 309 GET /vod/1/movie.mp4 HTTP/1.1 310 Host: a.service123.ucdn.example.com 312 Response: 313 HTTP/1.1 302 Found 314 Location: http://us-east1.dcdn.com/cache/1/ 315 a.service123.ucdn.example.com/vod/1/movie.mp4 317 3. Fallback Target Address Metadata 319 Open Caching requires that the uCDN should provide fallback target 320 server to the dCDN to be used in cases where the dCDN cannot properly 321 handle the request. To avoid redirect loops, the fallback target 322 server's address at the uCDN MUST be differnet than the original 323 address at the uCDN from which the client was redirected to the dCDN. 324 The uCDN MUST avoid further redirection when receiving the client 325 request at the fallback target. The fallback target is defined as a 326 generic metadata object (see section 3.2 of [RFC8006]) 328 Use cases 330 o Failover: A dCDN request router receives a request but has no 331 caches to which it can route the request. This can happen in the 332 case of failures or temporary network overload. In these cases, 333 the router may choose to redirect the request back to the uCDN 334 fallback address. 336 o Error: A cache may receive a request that it cannot properly 337 serve, for example, some of the metadata objects for that service 338 were not properly acquired. In this case, the cache may resolve 339 to redirect back to uCDN. 341 The Fallback target metadata object is used to indicate the target 342 address the dCDN should use in order to redirect a client back to the 343 uCDN. Fallback target is represented as endpoint objects as defined 344 in section 4.3.3 of [RFC8006]. 346 The uCDN fallback target address may be used as a DNS CNAME in case 347 of DNS redirection mode or a host name for HTTP redirect. 349 When using HTTP redirect to route a client request back to the uCDN, 350 it is the dCDN's responsibility to use the original URL path as the 351 client would have used for the original uCDN request, stripping, if 352 needed, the dCDN path-prefix and the uCDN host name from the redirect 353 URL that may have been used to request the content from the dCDN. 355 Property: host 357 Description: Target address to which the dCDN can redirect the 358 client. 360 Type: Endpoint object as defined in section 4.3.3 of [RFC8006] 361 with the limitation that in case of DNS delegation, it MUST 362 only be a hostname, and it MUST NOT include a port number. 364 Mandatory-to-Specify: Yes. 366 Example of a MI.FallbackTarget Metadata object that designates the 367 host address the dCDN should use as fallback address to redirect back 368 to the uCDN. 370 { 371 "generic-metadata-type": "MI.FallbackTarget", 372 "generic-metadata-value": 373 { 374 "host": "fallback-a.service123.ucdn.example" 375 } 376 } 378 4. IANA Considerations 380 4.1. CDNI Payload Types 382 This document requests the registration of the following CDNI Payload 383 Types under the IANA CDNI Payload Type registry defined in [RFC7736]: 385 +--------------------+---------------+ 386 | Payload Type | Specification | 387 +--------------------+---------------+ 388 | FCI.RedirectTarget | RFCthis | 389 | MI.FallbackTarget | RFCthis | 390 +--------------------+---------------+ 392 [RFC Editor: Please replace RFCthis with the published RFC number for 393 this document.] 395 4.1.1. CDNI FCI RedirectTarget Payload Type 397 Purpose: The purpose of this payload type is to distinguish 398 RedirectTarget FCI objects 400 Interface: FCI 402 Encoding: see Section 2 404 4.1.2. CDNI MI FallbackTarget Payload Type 406 Purpose: The purpose of this payload type is to distinguish 407 FallbackTarget MI objects (and any associated capability 408 advertisement) 410 Interface: MI/FCI 412 Encoding: see Section 3 414 5. Security Considerations 416 This specification is in accordance with the CDNI Metadata Interface 417 and the CDNI Request Routing: Footprint and Capabilities Semantics. 418 As such, it is subject to the security considerations as defined in 419 [RFC8006] and [RFC8008] respectively. 421 6. Acknowledgements 423 TBD. 425 7. Contributors 427 TBD. 429 8. References 431 8.1. Normative References 433 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 434 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 435 . 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, 439 DOI 10.17487/RFC2119, March 1997, 440 . 442 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 443 Resource Identifier (URI): Generic Syntax", STD 66, 444 RFC 3986, DOI 10.17487/RFC3986, January 2005, 445 . 447 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 448 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 449 DOI 10.17487/RFC7231, June 2014, 450 . 452 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 453 "Content Delivery Network Interconnection (CDNI) 454 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 455 . 457 [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network 458 Interconnection (CDNI) Control Interface / Triggers", 459 RFC 8007, DOI 10.17487/RFC8007, December 2016, 460 . 462 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 463 R., and K. Ma, "Content Delivery Network Interconnection 464 (CDNI) Request Routing: Footprint and Capabilities 465 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 466 . 468 8.2. Informative References 470 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 471 Distribution Network Interconnection (CDNI) Problem 472 Statement", RFC 6707, DOI 10.17487/RFC6707, September 473 2012, . 475 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 476 "Framework for Content Distribution Network 477 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 478 August 2014, . 480 [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) 481 Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, 482 December 2015, . 484 Authors' Addresses 486 Ori Finkelman 487 Qwilt 488 6, Ha'harash 489 Hod HaSharon 4524079 490 Israel 492 Phone: +972-72-2221647 493 Email: orif@qwilt.com 495 Sanjay Mishra 496 Verizon 497 13100 Columbia Pike 498 Silver Spring, MD 20904 499 USA 501 Email: sanjay.mishra@verizon.com