idnits 2.17.1 draft-finkelman-cdni-rr-sva-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 15, 2018) is 2145 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 (~~), 1 warning (==), 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 16, 2018 Verizon 6 May 15, 2018 8 CDNI SVA Request Routing Extensions 9 draft-finkelman-cdni-rr-sva-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). 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 16, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Redirect Target Address Capability Object . . . . . . . . . . 3 62 2.1. DnsTarget . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. HttpTarget . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Fallback Target Address Metadata . . . . . . . . . . . . . . 7 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 4.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 8 67 4.1.1. CDNI FCI RedirectTarget Payload Type . . . . . . . . 8 68 4.1.2. CDNI MI FallbackTarget Payload Type . . . . . . . . . 9 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 71 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 8.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 This document defines objects needed for Open Caching request 80 routing. For that purpose it extends CDNI metadata [RFC8006] and 81 CDNI Footprint and Capabilities [RFC8008]. For consistency, this 82 document follows the CDNI notation of uCDN (the commercial CDN) and 83 dCDN (the ISP caching layer). 85 This document also registers CDNI Payload Types [RFC7736] for the 86 defined objects: 88 o Redirect Target Capability (for dCDN advertising redirect target 89 address) 91 o Fallback Target Metadata (for uCDN configuring fallback target 92 address) 94 1.1. Terminology 96 This document reuses the terminology defined in [RFC6707], [RFC8006], 97 [RFC8007], and [RFC8008]. 99 Additionally, the following terms are used throughout this document 100 and are defined as follows: 102 o SVA - Streaming Video Alliance 104 o OC - SVA Open Caching 106 o RR - Request Router 108 o CP - Content Provider 110 2. Redirect Target Address Capability Object 112 Iterative request redirect as defined in section 1.1 of [RFC7336] 113 requries the provisioning of a redirect target address to be used by 114 the uCDN in order to redirect to the dCDN. The redirect target is 115 defined in this document as part of the Footprint and Capabilities 116 interface. 118 Use cases 120 o Footprint: The dCDN may want to have a different target per 121 footprint. Note that a dCDN may spread across multiple 122 geographies. This makes it easier to route client request to a 123 nearby request router. Though this can be achieved using a single 124 canonical name and Geo DNS, that approach has limitations, for 125 example a client may be using third party DNS resolver, making it 126 impossible for the redirector to detect where the client is 127 located, or Geo DNS granularity may be to rough for the 128 requirement of the application. 130 o Scaling: The dCDN may choose to scale its request routing service 131 by deploying more request routers in new locations and advertise 132 them via an updatable interface like the FCI. 134 The Redirect Target capability object is used to indicate the target 135 address the uCDN should use in order to redirect a client to the 136 dCDN. A target may be attached to a specific uCDN host, or a list of 137 uCDN hosts, or it can be set globally for all the hosts of the uCDN. 139 When dCDN is attaching the redirect target to a specific uCDN host or 140 a list of uCDN hosts, the dCDN MUST advertise them within the 141 Redirect Target Capabilty object as "redirecting-hosts". In that 142 case, the uCDN can redirect to that dCDN address, only if the request 143 is of one of these uCDN hosts. 145 A redirect target for DNS redirection is the FQDN to be used as a 146 CNAME for the uCDN host (see [RFC1034]). 148 A redirect target for HTTP redirection is the hostname to be used as 149 the first path segment in an absolute URI which is used as the 150 Location header of the HTTP rediret response (see section 7.1.2 of 151 [RFC7231]). 153 Property: redirecting-hosts 155 Description: One or more uCDN hosts that this redirect target 156 is attached to. A redirecting host SHOULD be a host that was 157 published in a HostMatch object by the uCDN as defined in 158 section 4.1.2 of [RFC8006]. 160 Type: A list of Endpoint objects (see section 4.3.3 of 161 [RFC8006]) 163 Mandatory-to-Specify: No. If not present, or empty, the 164 redirect target applies to all hosts of the redirecting uCDN. 166 Property: dns-target 168 Description: Target address for DNS CNAME delegation. 170 Type: DnsTarget object (see Section 2.1) 172 Mandatory-to-Specify: No. but at least one of "dns-target" or 173 "http-target" MUST be present and non empty. 175 Property: http-target 177 Description: Target URL for HTTP redirect. 179 Type: HttpTarget object (see Section 2.2) 181 Mandatory-to-Specify: No. but at least one of "dns-target" or 182 "http-target" MUST be present and non empty. 184 Example of Redirect Target Capability object that advertises a dCDN 185 target address which is attached to a specific list of uCDN 186 "redirecting-hosts". A uCDN host that is included in that list can 187 redirect to the advertised dCDN redirect target. 189 { 190 "capabilities": [ 191 { 192 "capability-type": "FCI.RedirectTarget", 193 "capability-value": { 194 "redirecting-hosts": [ 195 "a.service123.ucdn.example.com", 196 "b.service123.ucdn.example.com" 197 ] 198 "dns-target": { 199 "host": "service123.ucdn.example.dcdn.com" 200 } 201 "http-target": { 202 203 } 204 }, 205 "footprints": [ 206 207 ] 208 } 209 ] 210 } 212 2.1. DnsTarget 214 The DnsTarget object is the target address for CNAME delegation from 215 the uCDN to the dCDN. 217 Property: host 219 Description: The host property is a hostname, without a port 220 number. 222 Type: Endpoint object as defined in section 4.3.3 of [RFC8006] 223 with the limitation that it MUST only be a hostname, and it 224 MUST NOT include a port number. 226 Mandatory-to-Specify: Yes. 228 2.2. HttpTarget 230 The HttpTarget object is the target address for http redirection from 231 the uCDN to the dCDN. 233 Property: host 235 Description: Hostname or IP address and optional port, i.e., 236 the host and port as described in section 3.2 of [RFC3986]. 238 Type: Endpoint object as defined in section 4.3.3 of [RFC8006]. 240 Mandatory-to-Specify: Yes. 242 Property: path-prefix 244 Description: A path prefix for the HTTP redirect. The original 245 path is appended after this prefix. 247 Type: A prefix of a path-absolute as defined in section 3.3 of 248 [RFC3986]. The prefix MUST end with trailing slash, to 249 indicate the end of the last path segment in the prefix. 251 Mandatory-to-Specify: No. If this property is absent or empty, 252 the uCDN MUST NOT prepend a path prefix to the original content 253 path. 255 Property: include-redirecting-host 257 Description: A flag indicating weather or not to include the 258 redirecting host as the first path segment after the path- 259 prefix. In case this flag is true and a "path-prefix" is used, 260 the uCDN redirecting host MUST be added as a separate path 261 segment after the path-prefix and before the original URL path. 262 In case this flag is true and there is no path-prefix, the uCDN 263 redirecting host MUST be prepended as the first path segment in 264 the redirect URL. 266 Type: Boolean. 268 Mandatory-to-Specify: No. Default value is False. 270 Example of HttpTarget object with a path-prefix and include- 271 redirecting-host: 273 { 274 "host": "us-east1.dcdn.com", 275 "path-prefix": "/cache/1/", 276 "include-redirecting-host": true 277 } 279 Example of a HTTP request for content at uCDN host 280 "a.service123.ucdn.example.com" and the corresponding HTTP response 281 with Location header used for redirecting the client to the dCDN 282 using the the http-target in the above example: 284 Request: 285 GET /vod/1/movie.mp4 HTTP/1.1 286 Host: a.service123.ucdn.example.com 288 Response: 289 HTTP/1.1 302 Found 290 Location: http://us-east1.dcdn.com/cache/1/ 291 a.service123.ucdn.example.com/vod/1/movie.mp4 293 3. Fallback Target Address Metadata 295 Open Caching requires that the uCDN should provide fallback target 296 server to the dCDN to be used in cases where the dCDN cannot properly 297 handle the request. To avoid redirect loops, the fallback target 298 server's address at the uCDN MUST be differnet than the original 299 address at the uCDN from which the client was redirected to the dCDN. 300 The uCDN MUST avoid further redirection when receiving the client 301 request at the fallback target. The fallback target is defined as a 302 generic metadata object (see section 3.2 of [RFC8006]) 304 Use cases 306 o Failover: A dCDN request router receives a request but has no 307 caches to which it can route the request to. This can happen in 308 the case of failures, or temporary network overload. In these 309 cases, the router may choose to redirect the request back to the 310 uCDN fallback address. 312 o Error: A cache may receive a request that it cannot properly 313 serve, for example, some of the metadata objects for that service 314 were not properly acquired. In this case the cache may resolve to 315 redirect back to uCDN. 317 The Fallback target metadata object is used to indicate the target 318 address the dCDN should use in order to redirect a client back to the 319 uCDN. Fallback target is represented as endpoint objects as defined 320 in section 4.3.3 of [RFC8006]. 322 The uCDN fallback target address may be used as a DNS CNAME in case 323 of DNS redirection mode or a host name for HTTP redirect, in the case 324 of HTTP redirection mode. 326 When using HTTP redirect to route a client request back to the uCDN, 327 it is the dCDN responsibility to use the original URL path as the 328 client would have used for the original uCDN request, stripping, if 329 needed, the dCDN path-prefix and the uCDN host name from the redirect 330 URL which is used for requesting the content from the dCDN. 332 Property: host 334 Description: Target address to which the dCDN can redirect the 335 client. 337 Type: Endpoint object as defined in section 4.3.3 of [RFC8006] 338 with the limitation that in case of DNS delegation, it MUST 339 only be a hostname, and it MUST NOT include a port number. 341 Mandatory-to-Specify: Yes. 343 Example of MI.FallbackTarget Metadata object (which contains two 344 fallback-address objects) that describes which hosts addreses in the 345 uCDN the dCDN should use in order to redirect the client back to a 346 fallback address at the uCDN. 348 { 349 "generic-metadata-type": "MI.FallbackTarget", 350 "generic-metadata-value": 351 { 352 "host": "fallback-a.service123.ucdn.example" 353 } 354 } 356 4. IANA Considerations 358 4.1. CDNI Payload Types 360 This document requests the registration of the following CDNI Payload 361 Types under the IANA CDNI Payload Type registry defined in [RFC7736]: 363 +--------------------+---------------+ 364 | Payload Type | Specification | 365 +--------------------+---------------+ 366 | FCI.RedirectTarget | RFCthis | 367 | MI.FallbackTarget | RFCthis | 368 +--------------------+---------------+ 370 [RFC Editor: Please replace RFCthis with the published RFC number for 371 this document.] 373 4.1.1. CDNI FCI RedirectTarget Payload Type 375 Purpose: The purpose of this payload type is to distinguish 376 RedirectTarget FCI objects 378 Interface: FCI 379 Encoding: see Section 2 381 4.1.2. CDNI MI FallbackTarget Payload Type 383 Purpose: The purpose of this payload type is to distinguish 384 FallbackTarget MI objects (and any associated capability 385 advertisement) 387 Interface: MI/FCI 389 Encoding: see Section 3 391 5. Security Considerations 393 This specification is in accordance with the CDNI Metadata Interface 394 and the CDNI Request Routing: Footprint and Capabilities Semantics. 395 As such, it is subject to the security considerations as defined in 396 [RFC8006] and [RFC8008] respectively. 398 6. Acknowledgements 400 TBD. 402 7. Contributors 404 TBD. 406 8. References 408 8.1. Normative References 410 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 411 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 412 . 414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 415 Requirement Levels", BCP 14, RFC 2119, 416 DOI 10.17487/RFC2119, March 1997, 417 . 419 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 420 Resource Identifier (URI): Generic Syntax", STD 66, 421 RFC 3986, DOI 10.17487/RFC3986, January 2005, 422 . 424 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 425 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 426 DOI 10.17487/RFC7231, June 2014, 427 . 429 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 430 "Content Delivery Network Interconnection (CDNI) 431 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 432 . 434 [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network 435 Interconnection (CDNI) Control Interface / Triggers", 436 RFC 8007, DOI 10.17487/RFC8007, December 2016, 437 . 439 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 440 R., and K. Ma, "Content Delivery Network Interconnection 441 (CDNI) Request Routing: Footprint and Capabilities 442 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 443 . 445 8.2. Informative References 447 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 448 Distribution Network Interconnection (CDNI) Problem 449 Statement", RFC 6707, DOI 10.17487/RFC6707, September 450 2012, . 452 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 453 "Framework for Content Distribution Network 454 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 455 August 2014, . 457 [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) 458 Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, 459 December 2015, . 461 Authors' Addresses 463 Ori Finkelman 464 Qwilt 465 6, Ha'harash 466 Hod HaSharon 4524079 467 Israel 469 Phone: +972-72-2221647 470 Email: orif@qwilt.com 471 Sanjay Mishra 472 Verizon 473 13100 Columbia Pike 474 Silver Spring, MD 20904 475 USA 477 Email: sanjay.mishra@verizon.com