idnits 2.17.1 draft-ietf-cdni-request-routing-extensions-01.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 (February 3, 2019) is 1902 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: August 7, 2019 Verizon 6 February 3, 2019 8 CDNI Request Routing Extensions 9 draft-ietf-cdni-request-routing-extensions-01 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 August 7, 2019. 45 Copyright Notice 47 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . 10 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 77 8.2. Informative References . . . . . . . . . . . . . . . . . 11 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 was directed to one of these uCDN hosts. 151 A redirect target for DNS redirection is an IP address used as an A 152 record response or a FQDN used as an alias in a CNAME record response 153 (see [RFC1034]) of the uCDN DNS router. Note that DNS routers take 154 routing decisions based on either the DNS resolver's IP address or 155 the client IP address when EDNS0 client-subnet is used (see 156 [RFC7871]). The dCDN may choose to advertise redirect targets and 157 footprints to cover both cases. A uCDN DNS router implemenation 158 SHOULD prefer routing based on client IP address when it is 159 available. 161 A redirect target for HTTP redirection is the URI to be used as a 162 value of the Location header of a HTTP redirect 3xx response, 163 typically a 302 (Found) (see section 7.1.2 of [RFC7231] and section 164 6.4 of [RFC7231]). 166 Property: redirecting-hosts 168 Description: One or more uCDN hosts to which this redirect 169 target is attached. A redirecting host SHOULD be a host that 170 was published in a HostMatch object by the uCDN as defined in 171 section 4.1.2 of [RFC8006]. 173 Type: A list of Endpoint objects (see section 4.3.3 of 174 [RFC8006]) 176 Mandatory-to-Specify: No. If not present, or empty, the 177 redirect target applies to all hosts of the redirecting uCDN. 179 Property: dns-target 181 Description: Target address for DNS A record or CNAME record. 183 Type: DnsTarget object (see Section 2.1) 185 Mandatory-to-Specify: No. but at least one of "dns-target" or 186 "http-target" MUST be present and non empty. 188 Property: http-target 189 Description: Target URI for HTTP redirect. 191 Type: HttpTarget object (see Section 2.2) 193 Mandatory-to-Specify: No. but at least one of "dns-target" or 194 "http-target" MUST be present and non empty. 196 Example of Redirect Target Capability object that advertises a dCDN 197 target address that is attached to a specific list of uCDN 198 "redirecting-hosts". A uCDN host that is included in that list can 199 redirect to the advertised dCDN redirect target. 201 { 202 "capabilities": [ 203 { 204 "capability-type": "FCI.RedirectTarget", 205 "capability-value": { 206 "redirecting-hosts": [ 207 "a.service123.ucdn.example.com", 208 "b.service123.ucdn.example.com" 209 ] 210 "dns-target": { 211 "host": "service123.ucdn.example.dcdn.com" 212 } 213 "http-target": { 214 215 } 216 }, 217 "footprints": [ 218 219 ] 220 } 221 ] 222 } 224 2.1. DnsTarget 226 The DnsTarget object gives the instructions to construct the target 227 address for the DNS response for delegation from the uCDN to the 228 dCDN. 230 Property: host 232 Description: The host property is a hostname or an IP address, 233 without a port number. 235 Type: Endpoint object as defined in section 4.3.3 of [RFC8006] 236 with the limitation that it MUST NOT include a port number. 238 Mandatory-to-Specify: Yes. 240 Example of DnsTarget object: 242 { 243 "host": "service123.ucdn.example.dcdn.com" 244 } 246 Example of a DNS query for uCDN address 247 "a.service123.ucdn.example.com" and the corresponding CNAME 248 redirection response: 250 Query: 251 a.service123.ucdn.example.com: 252 type A, class IN 254 Response: 255 a.service123.ucdn.example.com: 256 type CNAME, class IN, cname service123.ucdn.example.dcdn.com 258 2.2. HttpTarget 260 The HttpTarget object gives the instructions to construct the target 261 Location URI for http redirection from the uCDN to the dCDN. 263 Property: host 265 Description: Hostname or IP address and an optional port, i.e., 266 the host and port of the authority component of the URI as 267 described in section 3.2 of [RFC3986]. 269 Type: Endpoint object as defined in section 4.3.3 of [RFC8006]. 271 Mandatory-to-Specify: Yes. 273 Property: path-prefix 275 Description: A path prefix for the HTTP redirect Location 276 header. The original path is appended after this prefix. 278 Type: A prefix of a path-absolute as defined in section 3.3 of 279 [RFC3986]. The prefix MUST end with a trailing slash, to 280 indicate the end of the last path segment in the prefix. 282 Mandatory-to-Specify: No. If this property is absent or empty, 283 the uCDN MUST NOT prepend a path prefix to the original content 284 path, i.e. the original path MUST appear in the location URI 285 right after the authority component. 287 Property: include-redirecting-host 289 Description: A flag indicating whether or not to include the 290 redirecting host as the first path segment after the path- 291 prefix. In case this flag is true and a "path-prefix" is used, 292 the uCDN redirecting host MUST be added as a separate path 293 segment after the path-prefix and before the original URL path. 294 In case this flag is true and there is no path-prefix, the uCDN 295 redirecting host MUST be prepended as the first path segment in 296 the redirect URL. 298 Type: Boolean. 300 Mandatory-to-Specify: No. Default value is False. 302 Example of HttpTarget object with a path-prefix and include- 303 redirecting-host: 305 { 306 "host": "us-east1.dcdn.com", 307 "path-prefix": "/cache/1/", 308 "include-redirecting-host": true 309 } 311 Example of a HTTP request for content at uCDN host 312 "a.service123.ucdn.example.com" and the corresponding HTTP response 313 with Location header used for redirecting the client to the dCDN 314 using the the http-target in the above example: 316 Request: 317 GET /vod/1/movie.mp4 HTTP/1.1 318 Host: a.service123.ucdn.example.com 320 Response: 321 HTTP/1.1 302 Found 322 Location: http://us-east1.dcdn.com/cache/1/ 323 a.service123.ucdn.example.com/vod/1/movie.mp4 325 3. Fallback Target Address Metadata 327 Open Caching requires that the uCDN should provide fallback target 328 server to the dCDN to be used in cases where the dCDN cannot properly 329 handle the request. To avoid redirect loops, the fallback target 330 server's address at the uCDN MUST be differnet than the original 331 address at the uCDN from which the client was redirected to the dCDN. 332 The uCDN MUST avoid further redirection when receiving the client 333 request at the fallback target. The fallback target is defined as a 334 generic metadata object (see section 3.2 of [RFC8006]) 335 Use cases 337 o Failover: A dCDN request router receives a request but has no 338 caches to which it can route the request. This can happen in the 339 case of failures or temporary network overload. 341 o No coverage: A dCDN request router receives a request from a 342 client located in an area inside the footprint but not covered by 343 the dCDN caches, or a client located outside the dCDN footprint 344 coverage. In such cases, the router may choose to redirect the 345 request back to the uCDN fallback address. 347 o Error: A cache may receive a request that it cannot properly 348 serve, for example, some of the metadata objects for that service 349 were not properly acquired. In this case, the cache may resolve 350 to redirect back to uCDN. 352 The Fallback target metadata object is used to indicate the target 353 address the dCDN should use in order to redirect a client back to the 354 uCDN. Fallback target is represented as endpoint objects as defined 355 in section 4.3.3 of [RFC8006]. 357 The uCDN fallback target address may be used as a DNS A record or 358 CNAME record in case of DNS redirection mode or a host name for HTTP 359 redirect. 361 When using HTTP redirect to route a client request back to the uCDN, 362 it is the dCDN's responsibility to use the original URL path as the 363 client would have used for the original uCDN request, stripping, if 364 needed, the dCDN path-prefix and the uCDN host name from the redirect 365 URL that may have been used to request the content from the dCDN. 367 Property: host 369 Description: Target address to which the dCDN can redirect the 370 client. 372 Type: Endpoint object as defined in section 4.3.3 of [RFC8006] 373 with the limitation that in case of DNS delegation, it MUST NOT 374 include a port number. 376 Mandatory-to-Specify: Yes. 378 Example of a MI.FallbackTarget Metadata object that designates the 379 host address the dCDN should use as fallback address to redirect back 380 to the uCDN. 382 { 383 "generic-metadata-type": "MI.FallbackTarget", 384 "generic-metadata-value": 385 { 386 "host": "fallback-a.service123.ucdn.example" 387 } 388 } 390 4. IANA Considerations 392 4.1. CDNI Payload Types 394 This document requests the registration of the following CDNI Payload 395 Types under the IANA CDNI Payload Type registry defined in [RFC7736]: 397 +--------------------+---------------+ 398 | Payload Type | Specification | 399 +--------------------+---------------+ 400 | FCI.RedirectTarget | RFCthis | 401 | MI.FallbackTarget | RFCthis | 402 +--------------------+---------------+ 404 [RFC Editor: Please replace RFCthis with the published RFC number for 405 this document.] 407 4.1.1. CDNI FCI RedirectTarget Payload Type 409 Purpose: The purpose of this payload type is to distinguish 410 RedirectTarget FCI objects 412 Interface: FCI 414 Encoding: see Section 2 416 4.1.2. CDNI MI FallbackTarget Payload Type 418 Purpose: The purpose of this payload type is to distinguish 419 FallbackTarget MI objects (and any associated capability 420 advertisement) 422 Interface: MI/FCI 424 Encoding: see Section 3 426 5. Security Considerations 428 This specification is in accordance with the CDNI Metadata Interface 429 and the CDNI Request Routing: Footprint and Capabilities Semantics. 430 As such, it is subject to the security considerations as defined in 431 [RFC8006] and [RFC8008] respectively. 433 6. Acknowledgements 435 TBD. 437 7. Contributors 439 TBD. 441 8. References 443 8.1. Normative References 445 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 446 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 447 . 449 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 450 Requirement Levels", BCP 14, RFC 2119, 451 DOI 10.17487/RFC2119, March 1997, 452 . 454 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 455 Resource Identifier (URI): Generic Syntax", STD 66, 456 RFC 3986, DOI 10.17487/RFC3986, January 2005, 457 . 459 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 460 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 461 DOI 10.17487/RFC7231, June 2014, 462 . 464 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 465 "Content Delivery Network Interconnection (CDNI) 466 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 467 . 469 [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network 470 Interconnection (CDNI) Control Interface / Triggers", 471 RFC 8007, DOI 10.17487/RFC8007, December 2016, 472 . 474 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 475 R., and K. Ma, "Content Delivery Network Interconnection 476 (CDNI) Request Routing: Footprint and Capabilities 477 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 478 . 480 8.2. Informative References 482 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 483 Distribution Network Interconnection (CDNI) Problem 484 Statement", RFC 6707, DOI 10.17487/RFC6707, September 485 2012, . 487 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 488 "Framework for Content Distribution Network 489 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 490 August 2014, . 492 [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) 493 Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, 494 December 2015, . 496 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 497 Kumari, "Client Subnet in DNS Queries", RFC 7871, 498 DOI 10.17487/RFC7871, May 2016, 499 . 501 Authors' Addresses 503 Ori Finkelman 504 Qwilt 505 6, Ha'harash 506 Hod HaSharon 4524079 507 Israel 509 Phone: +972-72-2221647 510 Email: orif@qwilt.com 512 Sanjay Mishra 513 Verizon 514 13100 Columbia Pike 515 Silver Spring, MD 20904 516 USA 518 Email: sanjay.mishra@verizon.com