idnits 2.17.1 draft-ietf-cdni-request-routing-extensions-04.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 (July 28, 2019) is 1727 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: January 29, 2020 Verizon 6 July 28, 2019 8 CDNI Request Routing Extensions 9 draft-ietf-cdni-request-routing-extensions-04 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 January 29, 2020. 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 Capability Object . . . . . . . . . . . . . . 3 65 2.1. Properties of Redirect Target Capability Object . . . . . 4 66 2.2. DnsTarget . . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.3. HttpTarget . . . . . . . . . . . . . . . . . . . . . . . 6 68 3. Fallback Target Address Metadata . . . . . . . . . . . . . . 8 69 3.1. Properties Fallback Target Address Metadata Object . . . 9 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 4.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 9 72 4.1.1. CDNI FCI RedirectTarget Payload Type . . . . . . . . 10 73 4.1.2. CDNI MI FallbackTarget Payload Type . . . . . . . . . 10 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 5.1. Confidentiality and Privacy . . . . . . . . . . . . . . . 10 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 7.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 This document defines objects needed for Open Caching request 85 routing. For that purpose it extends CDNI metadata [RFC8006] and 86 CDNI Footprint and Capabilities [RFC8008]. For consistency, this 87 document follows the CDNI notation of uCDN (the commercial CDN) and 88 dCDN (the ISP caching layer). 90 This document also registers CDNI Payload Types [RFC7736] for the 91 defined objects: 93 o Redirect Target Capability (for dCDN advertising redirect target 94 address) 96 o Fallback Target Metadata (for uCDN configuring fallback target 97 address) 99 1.1. Terminology 101 This document reuses the terminology defined in [RFC6707], [RFC8006], 102 [RFC8007], and [RFC8008]. 104 Additionally, the following terms are used throughout this document 105 and are defined as follows: 107 o RR - Request Router 109 o CP - Content Provider 111 2. Redirect Target Capability Object 113 Iterative request redirect as defined in section 1.1 of [RFC7336] 114 requries the provisioning of a redirect target address to be used by 115 the uCDN in order to redirect to the dCDN. Redirect target addresses 116 can vary between different footprints, for example, between different 117 regions, and they may also change over time, for example as a result 118 of network problems. Given this variable and dynamic nature of the 119 redirect target, it may not be suitable to advertise it during 120 bootstrap. 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 a third party DNS resolver, making 132 it 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 used globally for all the hosts of the uCDN. 145 When a dCDN is attaching the redirect target to a specific uCDN host 146 or 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 those 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 make 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 the 162 value for 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 2.1. Properties of Redirect Target Capability Object 168 The Redirect Target capability object consists of the following 169 properties: 171 Property: redirecting-hosts 173 Description: One or more uCDN hosts to which this redirect 174 target is attached. A redirecting host SHOULD be a host that 175 was published in a HostMatch object by the uCDN as defined in 176 section 4.1.2 of [RFC8006]. 178 Type: A list of Endpoint objects (see section 4.3.3 of 179 [RFC8006]) 181 Mandatory-to-Specify: No. If not present, or empty, the 182 redirect target applies to all hosts of the redirecting uCDN. 184 Property: dns-target 186 Description: Target address for a DNS A record or CNAME record. 188 Type: DnsTarget object (see Section 2.2) 190 Mandatory-to-Specify: No. but at least one of "dns-target" or 191 "http-target" MUST be present and non-empty. 193 Property: http-target 195 Description: Target URI for a HTTP redirect. 197 Type: HttpTarget object (see Section 2.3) 199 Mandatory-to-Specify: No, but at least one of "dns-target" or 200 "http-target" MUST be present and non-empty. 202 The following is an example of a Redirect Target capability object 203 serialization that advertises a dCDN target address that is attached 204 to a specific list of uCDN "redirecting-hosts". A uCDN host that is 205 included in that list can redirect to the advertised dCDN redirect 206 target. 208 { 209 "capabilities": [ 210 { 211 "capability-type": "FCI.RedirectTarget", 212 "capability-value": { 213 "redirecting-hosts": [ 214 "a.service123.ucdn.example.com", 215 "b.service123.ucdn.example.com" 216 ], 217 "dns-target": { 218 "host": "service123.ucdn.example.dcdn.com" 219 }, 220 "http-target": { 221 "host": "us-east1.dcdn.com", 222 "path-prefix": "/cache/1/", 223 "include-redirecting-host": true 224 } 225 }, 226 "footprints": [ 227 228 ] 229 } 230 ] 231 } 233 2.2. DnsTarget 235 The DnsTarget object gives the target address for the DNS response to 236 delegate from the uCDN to the dCDN. 238 Property: host 240 Description: The host property is a hostname or an IP address, 241 without a port number. 243 Type: Endpoint object as defined in section 4.3.3 of [RFC8006] 244 with the limitation that it SHOULD NOT include a port number 245 and, in case a port number is present, the uCDN MUST ignore it. 247 Mandatory-to-Specify: Yes. 249 The following is an example of DnsTarget object: 251 { 252 "host": "service123.ucdn.example.dcdn.com" 253 } 255 The following is an example of a DNS query for uCDN address 256 "a.service123.ucdn.example.com" and the corresponding CNAME 257 redirection response: 259 Query: 260 a.service123.ucdn.example.com: 261 type A, class IN 263 Response: 264 a.service123.ucdn.example.com: 265 type CNAME, class IN, cname service123.ucdn.example.dcdn.com 267 2.3. HttpTarget 269 The HttpTarget object gives the necessary information to construct 270 the target Location URI for HTTP redirection. 272 Property: host 274 Description: Hostname or IP address and an optional port, i.e., 275 the host and port of the authority component of the URI as 276 described in section 3.2 of [RFC3986]. 278 Type: Endpoint object as defined in section 4.3.3 of [RFC8006]. 280 Mandatory-to-Specify: Yes. 282 Property: path-prefix 284 Description: A path prefix for the HTTP redirect Location 285 header. The original path is appended after this prefix. 287 Type: A prefix of a path-absolute as defined in section 3.3 of 288 [RFC3986]. The prefix MUST end with a trailing slash, to 289 indicate the end of the last path segment in the prefix. 291 Mandatory-to-Specify: No. If this property is absent or empty, 292 the uCDN MUST NOT prepend a path prefix to the original content 293 path, i.e., the original path MUST appear in the location URI 294 right after the authority component. 296 Property: include-redirecting-host 298 Description: A flag indicating whether or not to include the 299 redirecting host as the first path segment after the path- 300 prefix. If set to true and a "path-prefix" is used, the uCDN 301 redirecting host MUST be added as a separate path segment after 302 the path-prefix and before the original URL path. If set to 303 true and there is no path-prefix, the uCDN redirecting host 304 MUST be prepended as the first path segment in the redirect 305 URL. 307 Type: Boolean. 309 Mandatory-to-Specify: No. Default value is False. 311 Example of HttpTarget object with a path-prefix and include- 312 redirecting-host: 314 { 315 "host": "us-east1.dcdn.com", 316 "path-prefix": "/cache/1/", 317 "include-redirecting-host": true 318 } 320 Example of a HTTP request for content at uCDN host 321 "a.service123.ucdn.example.com" and the corresponding HTTP response 322 with Location header used for redirecting the client to the dCDN 323 using the the http-target in the above example: 325 Request: 326 GET /vod/1/movie.mp4 HTTP/1.1 327 Host: a.service123.ucdn.example.com 329 Response: 330 HTTP/1.1 302 Found 331 Location: http://us-east1.dcdn.com/cache/1/ 332 a.service123.ucdn.example.com/vod/1/movie.mp4 334 3. Fallback Target Address Metadata 336 Open Caching requires that the uCDN provide a fallback target server 337 to the dCDN, to be used in cases where the dCDN cannot properly 338 handle the request. To avoid redirect loops, the fallback target 339 server's address at the uCDN MUST be differnet from the original uCDN 340 address from which the client was redirected to the dCDN. The uCDN 341 MUST avoid further redirection when receiving the client request at 342 the fallback target. The fallback target is defined as a generic 343 metadata object (see section 3.2 of [RFC8006]) 345 Use cases 347 o Failover: A dCDN request router receives a request but has no 348 caches to which it can route the request. This can happen in the 349 case of failures or temporary network overload. 351 o No coverage: A dCDN request router receives a request from a 352 client located in an area inside the footprint but not covered by 353 the dCDN caches or outside the dCDN footprint coverage. In such 354 cases, the router may choose to redirect the request back to the 355 uCDN fallback address. 357 o Error: A cache may receive a request that it cannot properly 358 serve, for example, some of the metadata objects for that service 359 were not properly acquired. In this case, the cache may resolve 360 to redirect back to uCDN. 362 The Fallback target metadata object is used to indicate the target 363 address the dCDN should use in order to redirect a client back to the 364 uCDN. Fallback target is represented as endpoint objects as defined 365 in section 4.3.3 of [RFC8006]. 367 The uCDN fallback target address may be used as a DNS A record or 368 CNAME record in case of DNS redirection or a hostname for HTTP 369 redirect. 371 When using HTTP redirect to route a client request back to the uCDN, 372 it is the dCDN's responsibility to use the original URL path as the 373 client would have used for the original uCDN request, stripping, if 374 needed, the dCDN path-prefix and/or the uCDN hostname from the 375 redirect URL that may have been used to request the content from the 376 dCDN. 378 3.1. Properties Fallback Target Address Metadata Object 380 The MI.FallbackTarget Metadata object consists of the following 381 single property: 383 Property: host 385 Description: Target address to which the dCDN can redirect the 386 client. 388 Type: Endpoint object as defined in section 4.3.3 of [RFC8006] 389 with the limitation that in case of DNS delegation it SHOULD 390 NOT include a port number and, in case a port number is 391 present, the dCDN MUST ignore it. 393 Mandatory-to-Specify: Yes. 395 Example of a MI.FallbackTarget Metadata object that designates the 396 host address the dCDN should use as fallback address to redirect back 397 to the uCDN. 399 { 400 "generic-metadata-type": "MI.FallbackTarget", 401 "generic-metadata-value": 402 { 403 "host": "fallback-a.service123.ucdn.example" 404 } 405 } 407 4. IANA Considerations 409 4.1. CDNI Payload Types 411 This document requests the registration of the following CDNI Payload 412 Types under the IANA "CDNI Payload Types" registry defined in 413 [RFC7736]: 415 +--------------------+---------------+ 416 | Payload Type | Specification | 417 +--------------------+---------------+ 418 | FCI.RedirectTarget | RFCthis | 419 | MI.FallbackTarget | RFCthis | 420 +--------------------+---------------+ 422 [RFC Editor: Please replace RFCthis with the published RFC number for 423 this document.] 425 4.1.1. CDNI FCI RedirectTarget Payload Type 427 Purpose: The purpose of this payload type is to distinguish 428 RedirectTarget FCI objects 430 Interface: FCI 432 Encoding: see Section 2.1 434 4.1.2. CDNI MI FallbackTarget Payload Type 436 Purpose: The purpose of this payload type is to distinguish 437 FallbackTarget MI objects (and any associated capability 438 advertisement) 440 Interface: MI/FCI 442 Encoding: see Section 3.1 444 5. Security Considerations 446 This specification is in accordance with the CDNI Metadata Interface 447 and the CDNI Request Routing: Footprint and Capabilities Semantics. 448 As such, it is subject to the security and privacy considerations as 449 defined in Section 8 of [RFC8006] and in Section 7 of [RFC8008] 450 respectively. 452 5.1. Confidentiality and Privacy 454 The redirect Target FCI object potentially exposes information about 455 the internal strcture of the dCDN network. A third party could 456 intercept the FCI transactions and use the information to attack the 457 dCDN. An implemenation of the FCI MUST therefore use strong 458 authentication and encryption and strictly follow the directions for 459 securing the interface as defined for the Metadata Interface in 460 Section 8.3 of [RFC8006]. 462 6. Acknowledgements 464 The authors thank Nir B. Sopher for reality checks against 465 production use cases, his contribution is significant to this 466 document. The authors also thank Ben Niven-Jenkins for his review 467 and feedback and Kevin J. Ma for his guidance throughout the 468 development of this document including his regular reviews. 470 7. References 472 7.1. Normative References 474 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 475 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 476 . 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, 480 DOI 10.17487/RFC2119, March 1997, 481 . 483 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 484 Resource Identifier (URI): Generic Syntax", STD 66, 485 RFC 3986, DOI 10.17487/RFC3986, January 2005, 486 . 488 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 489 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 490 DOI 10.17487/RFC7231, June 2014, 491 . 493 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 494 "Content Delivery Network Interconnection (CDNI) 495 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 496 . 498 [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network 499 Interconnection (CDNI) Control Interface / Triggers", 500 RFC 8007, DOI 10.17487/RFC8007, December 2016, 501 . 503 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 504 R., and K. Ma, "Content Delivery Network Interconnection 505 (CDNI) Request Routing: Footprint and Capabilities 506 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 507 . 509 7.2. Informative References 511 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 512 Distribution Network Interconnection (CDNI) Problem 513 Statement", RFC 6707, DOI 10.17487/RFC6707, September 514 2012, . 516 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 517 "Framework for Content Distribution Network 518 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 519 August 2014, . 521 [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) 522 Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, 523 December 2015, . 525 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 526 Kumari, "Client Subnet in DNS Queries", RFC 7871, 527 DOI 10.17487/RFC7871, May 2016, 528 . 530 Authors' Addresses 532 Ori Finkelman 533 Qwilt 534 6, Ha'harash 535 Hod HaSharon 4524079 536 Israel 538 Email: ori.finkelman.ietf@gmail.com 540 Sanjay Mishra 541 Verizon 542 13100 Columbia Pike 543 Silver Spring, MD 20904 544 USA 546 Email: sanjay.mishra@verizon.com