idnits 2.17.1 draft-ietf-cdni-request-routing-extensions-03.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 (May 21, 2019) is 1802 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: November 22, 2019 Verizon 6 May 21, 2019 8 CDNI Request Routing Extensions 9 draft-ietf-cdni-request-routing-extensions-03 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 November 22, 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 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. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 8.2. Informative References . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 This document defines objects needed for Open Caching request 86 routing. For that purpose it extends CDNI metadata [RFC8006] and 87 CDNI Footprint and Capabilities [RFC8008]. For consistency, this 88 document follows the CDNI notation of uCDN (the commercial CDN) and 89 dCDN (the ISP caching layer). 91 This document also registers CDNI Payload Types [RFC7736] for the 92 defined objects: 94 o Redirect Target Capability (for dCDN advertising redirect target 95 address) 97 o Fallback Target Metadata (for uCDN configuring fallback target 98 address) 100 1.1. Terminology 102 This document reuses the terminology defined in [RFC6707], [RFC8006], 103 [RFC8007], and [RFC8008]. 105 Additionally, the following terms are used throughout this document 106 and are defined as follows: 108 o RR - Request Router 110 o CP - Content Provider 112 2. Redirect Target Capability Object 114 Iterative request redirect as defined in section 1.1 of [RFC7336] 115 requries the provisioning of a redirect target address to be used by 116 the uCDN in order to redirect to the dCDN. Redirect target addresses 117 can vary between different footprints, for example, between different 118 regions, and they may also change over time, for example as a result 119 of network problems. Given this variable and dynamic nature of the 120 redirect target, it may not be suitable to advertise it during 121 bootstrap. A more dynamic and footprint oriented interface is 122 required. Therefore, we have chosen to use the CDNI Footprint and 123 Capabilities interface for redirect target advertisement. 125 Use cases 127 o Footprint: The dCDN may want to have a different target per 128 footprint. Note that a dCDN may spread across multiple 129 geographies. This makes it easier to route client requests to a 130 nearby request router. Though this can be achieved using a single 131 canonical name and Geo DNS, that approach has limitations; for 132 example a client may be using a third party DNS resolver, making 133 it impossible for the redirector to detect where the client is 134 located, or Geo DNS granularity may be too rough for the 135 requirement of the application. 137 o Scaling: The dCDN may choose to scale its request routing service 138 by deploying more request routers in new locations and advertise 139 them via an updatable interface like the FCI. 141 The Redirect Target capability object is used to indicate the target 142 address the uCDN should use in order to redirect a client to the 143 dCDN. A target may be attached to a specific uCDN host, a list of 144 uCDN hosts, or used globally for all the hosts of the uCDN. 146 When a dCDN is attaching the redirect target to a specific uCDN host 147 or a list of uCDN hosts, the dCDN MUST advertise the hosts within the 148 Redirect Target capability object as "redirecting-hosts". In that 149 case, the uCDN can redirect to that dCDN address, only if the request 150 was directed to one of those uCDN hosts. 152 A redirect target for DNS redirection is an IP address used as an A 153 record response or a FQDN used as an alias in a CNAME record response 154 (see [RFC1034]) of the uCDN DNS router. Note that DNS routers make 155 routing decisions based on either the DNS resolver's IP address or 156 the client IP address when EDNS0 client-subnet is used (see 157 [RFC7871]). The dCDN may choose to advertise redirect targets and 158 footprints to cover both cases. A uCDN DNS router implemenation 159 SHOULD prefer routing based on client IP address when it is 160 available. 162 A redirect target for HTTP redirection is the URI to be used as the 163 value for the Location header of a HTTP redirect 3xx response, 164 typically a 302 (Found) (see section 7.1.2 of [RFC7231] and section 165 6.4 of [RFC7231]). 167 2.1. Properties of Redirect Target Capability Object 169 The Redirect Target capability object consists of the following 170 properties: 172 Property: redirecting-hosts 174 Description: One or more uCDN hosts to which this redirect 175 target is attached. A redirecting host SHOULD be a host that 176 was published in a HostMatch object by the uCDN as defined in 177 section 4.1.2 of [RFC8006]. 179 Type: A list of Endpoint objects (see section 4.3.3 of 180 [RFC8006]) 182 Mandatory-to-Specify: No. If not present, or empty, the 183 redirect target applies to all hosts of the redirecting uCDN. 185 Property: dns-target 187 Description: Target address for a DNS A record or CNAME record. 189 Type: DnsTarget object (see Section 2.2) 191 Mandatory-to-Specify: No. but at least one of "dns-target" or 192 "http-target" MUST be present and non empty. 194 Property: http-target 196 Description: Target URI for a HTTP redirect. 198 Type: HttpTarget object (see Section 2.3) 200 Mandatory-to-Specify: No, but at least one of "dns-target" or 201 "http-target" MUST be present and non empty. 203 The following is an example of a Redirect Target capability object 204 serialization that advertises a dCDN target address that is attached 205 to a specific list of uCDN "redirecting-hosts". A uCDN host that is 206 included in that list can redirect to the advertised dCDN redirect 207 target. 209 { 210 "capabilities": [ 211 { 212 "capability-type": "FCI.RedirectTarget", 213 "capability-value": { 214 "redirecting-hosts": [ 215 "a.service123.ucdn.example.com", 216 "b.service123.ucdn.example.com" 217 ], 218 "dns-target": { 219 "host": "service123.ucdn.example.dcdn.com" 220 }, 221 "http-target": { 222 "host": "us-east1.dcdn.com", 223 "path-prefix": "/cache/1/", 224 "include-redirecting-host": true 225 } 226 }, 227 "footprints": [ 228 229 ] 230 } 231 ] 232 } 234 2.2. DnsTarget 236 The DnsTarget object gives the target address for the DNS response to 237 delegate from the uCDN to the dCDN. 239 Property: host 241 Description: The host property is a hostname or an IP address, 242 without a port number. 244 Type: Endpoint object as defined in section 4.3.3 of [RFC8006] 245 with the limitation that it SHOULD NOT include a port number 246 and, in case a port number is present, the uCDN MUST ignore it. 248 Mandatory-to-Specify: Yes. 250 The following is an example of DnsTarget object: 252 { 253 "host": "service123.ucdn.example.dcdn.com" 254 } 256 The following is an example of a DNS query for uCDN address 257 "a.service123.ucdn.example.com" and the corresponding CNAME 258 redirection response: 260 Query: 261 a.service123.ucdn.example.com: 262 type A, class IN 264 Response: 265 a.service123.ucdn.example.com: 266 type CNAME, class IN, cname service123.ucdn.example.dcdn.com 268 2.3. HttpTarget 270 The HttpTarget object gives the necessary information to construct 271 the target Location URI for HTTP redirection. 273 Property: host 275 Description: Hostname or IP address and an optional port, i.e., 276 the host and port of the authority component of the URI as 277 described in section 3.2 of [RFC3986]. 279 Type: Endpoint object as defined in section 4.3.3 of [RFC8006]. 281 Mandatory-to-Specify: Yes. 283 Property: path-prefix 285 Description: A path prefix for the HTTP redirect Location 286 header. The original path is appended after this prefix. 288 Type: A prefix of a path-absolute as defined in section 3.3 of 289 [RFC3986]. The prefix MUST end with a trailing slash, to 290 indicate the end of the last path segment in the prefix. 292 Mandatory-to-Specify: No. If this property is absent or empty, 293 the uCDN MUST NOT prepend a path prefix to the original content 294 path, i.e., the original path MUST appear in the location URI 295 right after the authority component. 297 Property: include-redirecting-host 299 Description: A flag indicating whether or not to include the 300 redirecting host as the first path segment after the path- 301 prefix. If set to true and a "path-prefix" is used, the uCDN 302 redirecting host MUST be added as a separate path segment after 303 the path-prefix and before the original URL path. If set to 304 true and there is no path-prefix, the uCDN redirecting host 305 MUST be prepended as the first path segment in the redirect 306 URL. 308 Type: Boolean. 310 Mandatory-to-Specify: No. Default value is False. 312 Example of HttpTarget object with a path-prefix and include- 313 redirecting-host: 315 { 316 "host": "us-east1.dcdn.com", 317 "path-prefix": "/cache/1/", 318 "include-redirecting-host": true 319 } 321 Example of a HTTP request for content at uCDN host 322 "a.service123.ucdn.example.com" and the corresponding HTTP response 323 with Location header used for redirecting the client to the dCDN 324 using the the http-target in the above example: 326 Request: 327 GET /vod/1/movie.mp4 HTTP/1.1 328 Host: a.service123.ucdn.example.com 330 Response: 331 HTTP/1.1 302 Found 332 Location: http://us-east1.dcdn.com/cache/1/ 333 a.service123.ucdn.example.com/vod/1/movie.mp4 335 3. Fallback Target Address Metadata 337 Open Caching requires that the uCDN provide a fallback target server 338 to the dCDN, to be used in cases where the dCDN cannot properly 339 handle the request. To avoid redirect loops, the fallback target 340 server's address at the uCDN MUST be differnet from the original uCDN 341 address from which the client was redirected to the dCDN. The uCDN 342 MUST avoid further redirection when receiving the client request at 343 the fallback target. The fallback target is defined as a generic 344 metadata object (see section 3.2 of [RFC8006]) 346 Use cases 348 o Failover: A dCDN request router receives a request but has no 349 caches to which it can route the request. This can happen in the 350 case of failures or temporary network overload. 352 o No coverage: A dCDN request router receives a request from a 353 client located in an area inside the footprint but not covered by 354 the dCDN caches or outside the dCDN footprint coverage. In such 355 cases, the router may choose to redirect the request back to the 356 uCDN fallback address. 358 o Error: A cache may receive a request that it cannot properly 359 serve, for example, some of the metadata objects for that service 360 were not properly acquired. In this case, the cache may resolve 361 to redirect back to uCDN. 363 The Fallback target metadata object is used to indicate the target 364 address the dCDN should use in order to redirect a client back to the 365 uCDN. Fallback target is represented as endpoint objects as defined 366 in section 4.3.3 of [RFC8006]. 368 The uCDN fallback target address may be used as a DNS A record or 369 CNAME record in case of DNS redirection or a hostname for HTTP 370 redirect. 372 When using HTTP redirect to route a client request back to the uCDN, 373 it is the dCDN's responsibility to use the original URL path as the 374 client would have used for the original uCDN request, stripping, if 375 needed, the dCDN path-prefix and/or the uCDN hostname from the 376 redirect URL that may have been used to request the content from the 377 dCDN. 379 3.1. Properties Fallback Target Address Metadata Object 381 The MI.FallbackTarget Metadata object consists of the following 382 single property: 384 Property: host 386 Description: Target address to which the dCDN can redirect the 387 client. 389 Type: Endpoint object as defined in section 4.3.3 of [RFC8006] 390 with the limitation that in case of DNS delegation it SHOULD 391 NOT include a port number and, in case a port number is 392 present, the dCDN MUST ignore it. 394 Mandatory-to-Specify: Yes. 396 Example of a MI.FallbackTarget Metadata object that designates the 397 host address the dCDN should use as fallback address to redirect back 398 to the uCDN. 400 { 401 "generic-metadata-type": "MI.FallbackTarget", 402 "generic-metadata-value": 403 { 404 "host": "fallback-a.service123.ucdn.example" 405 } 406 } 408 4. IANA Considerations 410 4.1. CDNI Payload Types 412 This document requests the registration of the following CDNI Payload 413 Types under the IANA "CDNI Payload Types" registry defined in 414 [RFC7736]: 416 +--------------------+---------------+ 417 | Payload Type | Specification | 418 +--------------------+---------------+ 419 | FCI.RedirectTarget | RFCthis | 420 | MI.FallbackTarget | RFCthis | 421 +--------------------+---------------+ 423 [RFC Editor: Please replace RFCthis with the published RFC number for 424 this document.] 426 4.1.1. CDNI FCI RedirectTarget Payload Type 428 Purpose: The purpose of this payload type is to distinguish 429 RedirectTarget FCI objects 431 Interface: FCI 433 Encoding: see Section 2.1 435 4.1.2. CDNI MI FallbackTarget Payload Type 437 Purpose: The purpose of this payload type is to distinguish 438 FallbackTarget MI objects (and any associated capability 439 advertisement) 441 Interface: MI/FCI 443 Encoding: see Section 3.1 445 5. Security Considerations 447 This specification is in accordance with the CDNI Metadata Interface 448 and the CDNI Request Routing: Footprint and Capabilities Semantics. 449 As such, it is subject to the security and privacy considerations as 450 defined in Section 8 of [RFC8006] and in Section 7 of [RFC8008] 451 respectively. 453 5.1. Confidentiality and Privacy 455 The redirect Target FCI object potentially exposes information about 456 the internal strcture of the dCDN network. A third party could 457 intercept the FCI transactions and use the information to attack the 458 dCDN. An implemenation of the FCI MUST therefore use strong 459 authentication and encryption and strictly follow the directions for 460 securing the interface as defined for the Metadata Interface in 461 Section 8.3 of [RFC8006]. 463 6. Acknowledgements 465 TBD. 467 7. Contributors 469 TBD. 471 8. References 473 8.1. Normative References 475 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 476 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 477 . 479 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 480 Requirement Levels", BCP 14, RFC 2119, 481 DOI 10.17487/RFC2119, March 1997, 482 . 484 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 485 Resource Identifier (URI): Generic Syntax", STD 66, 486 RFC 3986, DOI 10.17487/RFC3986, January 2005, 487 . 489 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 490 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 491 DOI 10.17487/RFC7231, June 2014, 492 . 494 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 495 "Content Delivery Network Interconnection (CDNI) 496 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 497 . 499 [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network 500 Interconnection (CDNI) Control Interface / Triggers", 501 RFC 8007, DOI 10.17487/RFC8007, December 2016, 502 . 504 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 505 R., and K. Ma, "Content Delivery Network Interconnection 506 (CDNI) Request Routing: Footprint and Capabilities 507 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 508 . 510 8.2. Informative References 512 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 513 Distribution Network Interconnection (CDNI) Problem 514 Statement", RFC 6707, DOI 10.17487/RFC6707, September 515 2012, . 517 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 518 "Framework for Content Distribution Network 519 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 520 August 2014, . 522 [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) 523 Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, 524 December 2015, . 526 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 527 Kumari, "Client Subnet in DNS Queries", RFC 7871, 528 DOI 10.17487/RFC7871, May 2016, 529 . 531 Authors' Addresses 533 Ori Finkelman 534 Qwilt 535 6, Ha'harash 536 Hod HaSharon 4524079 537 Israel 539 Phone: +972-72-2221647 540 Email: ori.finkelman.ietf@gmail.com 542 Sanjay Mishra 543 Verizon 544 13100 Columbia Pike 545 Silver Spring, MD 20904 546 USA 548 Email: sanjay.mishra@verizon.com