idnits 2.17.00 (12 Aug 2021) /tmp/idnits58115/draft-finkelman-cdni-rr-sva-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 : ---------------------------------------------------------------------------- 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 (February 12, 2018) is 1558 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) ** Downref: Normative reference to an Informational RFC: RFC 6707 ** Downref: Normative reference to an Informational RFC: RFC 7336 Summary: 2 errors (**), 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: August 16, 2018 Verizon 6 February 12, 2018 8 CDNI SVA Request Routing Extensions 9 draft-finkelman-cdni-rr-sva-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). 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 August 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 . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Redirect Targets Capability Object . . . . . . . . . . . . . 3 62 2.1. Redirect Target Address . . . . . . . . . . . . . . . . . 4 63 3. uCDN fallback metadata . . . . . . . . . . . . . . . . . . . 5 64 3.1. Fallback Address . . . . . . . . . . . . . . . . . . . . 6 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 4.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 7 67 4.1.1. CDNI FCI RedirectTargets Payload Type . . . . . . . . 7 68 4.1.2. CDNI MI Fallback Payload Type . . . . . . . . . . . . 7 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 8.2. Informative References . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 The CDNI metadata interface is described in [RFC8006]. 87 The CDNI footprint and capability interface is described in 88 [RFC8008]. 90 1.1. Terminology 92 This document reuses the terminology defined in [RFC6707], [RFC8006], 93 [RFC8007], and [RFC8008]. 95 Additionally, the following terms are used throughout this document 96 and are defined as follows: 98 o SVA - Streaming Video Alliance. 100 o OC - SVA Open Caching. 102 o RR - Request Router. 104 o CP - Content Provider (video). 106 2. Redirect Targets Capability Object 108 Open Caching uses iterative request redirect as defined in [RFC7336]. 109 In order for the uCDN to redirect to the dCDN it requires redirect 110 target addresses. The redirect targets are defined as part of the 111 Footprint and Capabilities interface. 113 Use cases 115 * Footprint: The dCDN may want to have different targets per 116 footprint. Note that a dCDN may spread across multiple 117 geographies. This makes it easier to route client request to a 118 nearby request router. Though this can be achieved using a 119 single canonical name and geo DNS, that approach has 120 limitations, for example a client may be using third party DNS 121 resolver, making it impossible for the redirector to detect 122 where the client is located. 124 * Scaling: The dCDN may choose to scale its request routing 125 service by deploying more request routers in new locations and 126 advertise them via an updatable interface like the FCI. 128 The Redirect Target capability object is used to indicate the 129 target addresses the uCDN should use in order to redirect a client 130 to the uCDN. Targets are represented as endpoint objects as 131 defined in [RFC8006]. 133 Property: target-addresses 135 Description: Target addresses to which the uCDN can redirect 136 the client, listed in order of priority. 138 Type: Array of target-address objects (see Section 2.1) 140 Mandatory-to-Specify: No. The dCDN can advertise the redirect 141 targets to the uCDN statically, or by some other means 143 Example of Redirect Target Capability object (which contains two 144 target-address objects) that describes which target addreses in the 145 dCDN the uCDN should use in order to redirect the client to the dCDN. 147 { 148 "capabilities": [ 149 { 150 "capability-type": "FCI.RedirectTargetes", 151 "capability-value": { 152 "target-addresses": [ 153 "endpoints": [ 154 "a.service123.dcdn.example.com", 155 "b.service123.dcdn.example.com" 156 ], 157 "endpoints": ["c.service123.dcdn.example.com"] 158 ] 159 }, 160 "footprints": [ 161 162 ] 163 } 164 ] 165 } 167 2.1. Redirect Target Address 169 A target-address object describes the address to be used by the uCDN 170 when redirecting a client to the dCDN. 172 Endpoints within a target-address object MUST be treated as 173 equivalent/equal. A dCDN can specify an array of target-addresses, 174 ordered by preference, within a RedirectTargets capability object. 175 Then, for each target-address object ranked by preference, a dCDN can 176 specify an array of endpoints that are equivalent (e.g., a pool of 177 servers that are not behind a load balancer). 179 Property: endpoints 181 Description: Endpoint addresses to which the uCDN can redirect 182 the client. If multiple endpoints are specified, they are all 183 equal, i.e., the list is not ordered by preference. 185 Type: Array of Endpoint objects (see section 4.3.3 of 186 [RFC8006]). 188 Mandatory-to-Specify: Yes. 190 Example of Target Address object (which contains two endpoint 191 objects) that descibes which endpoint addreses in the dCDN the uCDN 192 should use in order to to redirect the client to the dCDN. 194 "endpoints": [ 195 "a.service123.dcdn.example.com", 196 "b.service123.dcdn.example.com" 197 ] 199 3. uCDN fallback metadata 201 Open Caching requires that the uCDN should provide fallback servers 202 to the dCDN to be used in cases where the dCDN cannot properly handle 203 the request. To avoid redirect loops, the fallback servers' 204 addresses at the uCDN MUST be differnet than the original address at 205 the uCDN from which the client was redirected to the dCDN. The uCDN 206 MUST avoid further redirection when receiving the client request at 207 the fallback server address. The fallback server is defined as a 208 generic metadata object (see section 3.2 of [RFC8006]) 210 Use cases 212 * Failover: A dCDN request router receives a request but has no 213 caches to which it can route the request to. This can happen 214 in the case of failures, or temporary network overload. In 215 these cases, the router may choose to redirect the request back 216 to the uCDN fallback address. 218 * Error: A cache may receive a request that it cannot properly 219 serve, for example, some of the metadata objects for that 220 service were not properly acquired. In this case the cache may 221 resolve to redirect back to uCDN. 223 The Fallback metadata object is used to indicate the server 224 addresses the dCDN should use in order to redirect a client back 225 to the uCDN. Fallbacks addresses are represented as endpoint 226 objects as defined in [RFC8006]. 228 Property: fallback-addresses 230 Description: Fallback Addresses to which the uCDN can redirect 231 the client, listed in order of priority. 233 Type: Array of fallback-address objects (see Section 3.1) 235 Mandatory-to-Specify: No. The dCDN can advertise the redirect 236 addresses to the uCDN statically, or by some other means 238 Example of MI.Fallback Metadata object (which contains two fallback- 239 address objects) that describes which hosts addreses in the uCDN the 240 dCDN should use in order to redirect the client back to a fallback 241 address at the uCDN. 243 { 244 "generic-metadata-type": "MI.Fallback", 245 "generic-metadata-value": 246 { 247 "fallback-addresses": [ 248 { 249 "endpoints": [ 250 "fallback-a.service123.ucdn.example", 251 "fallback-b.service123.ucdn.example" 252 ], 253 "protocol": "http/1.1" 254 }, 255 { 256 "endpoints": ["fallback-c.service123.example"], 257 "protocol": "http/1.1" 258 } 259 ] 260 } 261 } 263 3.1. Fallback Address 265 A fallback-address object describes the address to be used by the 266 dCDN when redirecting a client back to the dCDN due to failure, 267 error, or other conditions in the dCDN. 269 Endpoints within a fallback-address object MUST be treated as 270 equivalent/equal. A uCDN can specify an array of fallback-addresses, 271 ordered by preference, within a Fallback metadata object. Then, for 272 each fallback-address object ranked by preference, a uCDN can specify 273 an array of endpoints that are equivalent (e.g., a pool of servers 274 that are not behind a load balancer). 276 Property: endpoints 278 Description: Endpoint addresses to which the dCDN can redirect 279 the client. If multiple endpoints are specified, they are all 280 equal, i.e., the list is not ordered by preference.. 282 Type: Array of Endpoint objects (see section 4.3.3 of 283 [RFC8006]) 285 Mandatory-to-Specify: Yes. 287 Property: protocol 289 Description: Network protocol to use when redirecting to this 290 fallback server. 292 Type: Protocol (see section 4.3.2 of [RFC8006]) 294 Mandatory-to-Specify: Yes. 296 Example of Fallback Address object (which contains two endpoint 297 objects) that descibes which endpoint addreses in the uCDN the dCDN 298 should use in order to to redirect the client to the uCDN. 300 { 301 "endpoints": [ 302 "fallback-a.service123.ucdn.example", 303 "fallback-b.service123.ucdn.example" 304 ], 305 "protocol": "http/1.1" 306 } 308 4. IANA Considerations 310 4.1. CDNI Payload Types 312 This document requests the registration of the following CDNI Payload 313 Types under the IANA CDNI Payload Type registry [RFC7736]: 315 +----------------------+---------------+ 316 | Payload Type | Specification | 317 +----------------------+---------------+ 318 | FCI.RedirectTargetes | RFCthis | 319 | MI.Fallback | RFCthis | 320 +----------------------+---------------+ 322 [RFC Editor: Please replace RFCthis with the published RFC number for 323 this document.] 325 4.1.1. CDNI FCI RedirectTargets Payload Type 327 Purpose: The purpose of this payload type is to distinguish 328 RedirectTargets FCI objects 330 Interface: FCI 332 Encoding: see Section 2 334 4.1.2. CDNI MI Fallback Payload Type 336 Purpose: The purpose of this payload type is to distinguish Fallback 337 MI objects (and any associated capability advertisement) 339 Interface: MI/FCI 340 Encoding: see Section 3 342 5. Security Considerations 344 This specification is in accordance with the CDNI Metadata Interface 345 and the CDNI Request Routing: Footprint and Capabilities Semantics. 346 As such, it is subject to the security considerations as defined in 347 [RFC8006] and [RFC8008] respectively. 349 6. Acknowledgements 351 TBD. 353 7. Contributors 355 TBD. 357 8. References 359 8.1. Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, 363 DOI 10.17487/RFC2119, March 1997, 364 . 366 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 367 Distribution Network Interconnection (CDNI) Problem 368 Statement", RFC 6707, DOI 10.17487/RFC6707, September 369 2012, . 371 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 372 "Framework for Content Distribution Network 373 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 374 August 2014, . 376 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 377 "Content Delivery Network Interconnection (CDNI) 378 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 379 . 381 [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network 382 Interconnection (CDNI) Control Interface / Triggers", 383 RFC 8007, DOI 10.17487/RFC8007, December 2016, 384 . 386 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 387 R., and K. Ma, "Content Delivery Network Interconnection 388 (CDNI) Request Routing: Footprint and Capabilities 389 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 390 . 392 8.2. Informative References 394 [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) 395 Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, 396 December 2015, . 398 Authors' Addresses 400 Ori Finkelman 401 Qwilt 402 6, Ha'harash 403 Hod HaSharon 4524079 404 Israel 406 Phone: +972-72-2221647 407 Email: orif@qwilt.com 409 Sanjay Mishra 410 Verizon 411 13100 Columbia Pike 412 Silver Spring, MD 20904 413 USA 415 Email: sanjay.mishra@verizon.com