idnits 2.17.1 draft-brandenburg-cdni-has-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 22, 2012) is 4351 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-cdni-use-cases' is defined on line 1384, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-cdni-problem-statement-03 == Outdated reference: A later version (-10) exists of draft-ietf-cdni-use-cases-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CDNI R. van Brandenburg 3 Internet-Draft O. van Deventer 4 Intended status: Informational TNO 5 Expires: November 23, 2012 F. Le Faucheur 6 K. Leung 7 Cisco Systems 8 May 22, 2012 10 Models for adaptive-streaming-aware CDN Interconnection 11 draft-brandenburg-cdni-has-01 13 Abstract 15 This documents presents thoughts on the potential impact of 16 supporting HTTP Adaptive Streaming technologies in CDN 17 Interconnection scenarios. Our intent is to spur discussion on how 18 the different CDNI interfaces could, and should, deal with content 19 delivered using adaptive streaming technologies and to facilitate 20 working group decisions. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 23, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. HTTP Adaptive Streaming aspects relevant to CDNI . . . . . . . 5 59 2.1. Segmentation versus Fragmentation . . . . . . . . . . . . 5 60 2.2. Addressing chunks . . . . . . . . . . . . . . . . . . . . 6 61 2.2.1. Relative URLs . . . . . . . . . . . . . . . . . . . . 7 62 2.2.2. Absolute URLs with Redirection . . . . . . . . . . . . 8 63 2.2.3. Absolute URL without Redirection . . . . . . . . . . . 9 64 3. Possible HAS Optimizations . . . . . . . . . . . . . . . . . . 10 65 3.1. File Management and Content Collections . . . . . . . . . 10 66 3.1.1. Option 1.1: No HAS awareness . . . . . . . . . . . . . 11 67 3.1.2. Option 1.2: Allow single file storage of 68 fragmented content . . . . . . . . . . . . . . . . . . 11 69 3.2. Content Acquisition of Content Collections . . . . . . . . 12 70 3.2.1. Option 2.1: No HAS awareness . . . . . . . . . . . . . 12 71 3.2.2. Option 2.2: Allow single file acquisition of 72 fragmented content . . . . . . . . . . . . . . . . . . 13 73 3.3. Request Routing of HAS content . . . . . . . . . . . . . . 13 74 3.3.1. Option 3.1: No HAS awareness . . . . . . . . . . . . . 14 75 3.3.2. Option 3.2: Manifest File rewriting by uCDN . . . . . 16 76 3.3.3. Option 3.3: Two-step Manifest File rewriting . . . . . 17 77 3.4. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 3.4.1. HAS Considerations for CDNI Logging . . . . . . . . . 18 79 3.4.2. Candidate Approaches . . . . . . . . . . . . . . . . . 19 80 3.4.2.1. Option 4.1: "Do-Nothing" Approach . . . . . . . . 19 81 3.4.2.2. Option 4.2: "CDNI Metadata Content Collection 82 ID" Approach . . . . . . . . . . . . . . . . . . . 20 83 3.4.2.3. Option 4.3: "CDNI Metadata Content Collection 84 ID With dCDN Summarization" Approach . . . . . . . 21 85 3.4.2.4. Option 4.4: "CDNI Logging Interface 86 Compression" Approach . . . . . . . . . . . . . . 22 87 3.4.2.5. Option 4.5: "Full HAS awareness" Approach . . . . 23 88 3.5. URL Signing . . . . . . . . . . . . . . . . . . . . . . . 24 89 3.5.1. URL Signing in CDNI . . . . . . . . . . . . . . . . . 25 90 3.5.2. Option 5.1: No HAS awareness . . . . . . . . . . . . . 26 91 3.5.3. Option 5.2: HAS-awareness with Authorization Token . . 27 92 3.5.4. Option 5.3: HAS-awareness with Session Based 93 Encryption . . . . . . . . . . . . . . . . . . . . . . 28 94 3.6. Content Purge . . . . . . . . . . . . . . . . . . . . . . 28 95 3.6.1. Option 6.1: No HAS awareness . . . . . . . . . . . . . 29 96 3.6.2. Option 6.2: Purge Identifiers . . . . . . . . . . . . 29 97 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 98 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30 99 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 100 6.1. Normative References . . . . . . . . . . . . . . . . . . . 30 101 6.2. Informative References . . . . . . . . . . . . . . . . . . 31 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 104 1. Introduction 106 HTTP Adaptive Streaming (HAS) is an umbrella term for various HTTP- 107 based streaming technologies that allow a client to adaptively switch 108 between multiple bitrates depending on current network conditions. A 109 defining aspect of HAS is that, since it is based on HTTP, it is a 110 pull-based mechanism, with a client actively requesting content 111 segments, instead of the content being pushed to the client by a 112 server. Due to this pull-based nature, media servers delivering 113 content using HAS often show different characteristics when compared 114 with media servers delivering content using traditional streaming 115 methods such as RTP/RTSP, RTMP and MMS. This document presents a 116 discussion on what the impact of these different characteristics is 117 to the CDNI interfaces and what HAS-specific optimizations may be 118 required or may be desirable. The scope of this document in its 119 current form is explicitly not to propose any specific solution, but 120 merely to present the available options so that the WG can make an 121 informed decision on which way to go. 123 1.1. Terminology 125 This document uses the terminology defined in 126 [I-D.ietf-cdni-problem-statement]. 128 In addition, the following terms are used throughout this document: 130 Content Item: A uniquely addressable content element in a CDN. A 131 content item is defined by the fact that it has its own Content 132 Metadata associated with it. It is the object of a request routing 133 operation in a CDN. An example of a Content Item is a video file/ 134 stream, an audio file/stream or an image file. 136 Chunk: a fixed length element that is the result of a segmentation or 137 fragmentation operation and that is independently addressable. 139 Fragment: A specific form of chunk (see Section 2.1). A fragment is 140 stored as part of a larger file that includes all chunks that are 141 part of the Chunk Collection. 143 Segment: A specific form of chunk (see Section 2.1). A segment is 144 stored as a single file from a file system perspective. 146 Original Content: Not-chunked content that is the basis for a 147 segmentation of fragmentation operation. Based on Original Content, 148 multiple alternative representations (using different encoding 149 methods, supporting different resolutions and/or targeting different 150 bitrates) may be derived, each of which may be fragmented or 151 segmented. 153 Chunk Collection: The set of all chunks that are the result of a 154 single segmentation or fragmentation operation being performed on a 155 single representation of the Original Content. A Chunk Collection is 156 described in a Manifest File. 158 Content Collection: The set of all Chunk Collections that are derived 159 from the same Original Content. A Content Collection may consist of 160 multiple Chunk Collections, each corresponding to a single 161 representation of the Original Content. A Content Collection may be 162 described by one or more Manifest Files. 164 Manifest File: A Manifest File, also referred to as Media 165 Presentation Description (MPD) file, is a file that list the way the 166 content has been chunked (possibly for multiple encodings) and where 167 the various chunks are located (in the case of segments) or how they 168 can be addressed (in the case of fragments). 170 2. HTTP Adaptive Streaming aspects relevant to CDNI 172 In the last couple of years, a wide variety of HAS-like protocols 173 have emerged. Among them are proprietary solutions such as Apple's 174 HTTP Live Streaming (HLS), Microsoft's Smooth Streaming (HSS) and 175 Adobe's HTTP Dynamic Streaming (HDS), and various standardized 176 solutions such as 3GPP Adaptive HTTP Streaming (AHS) and MPEG Dynamic 177 Adaptive Streaming over HTTP (DASH). While all of these technologies 178 share a common set of features, each has its own defining elements. 179 This chapter will look at some of the common characteristics and some 180 of the differences between these technologies and how those might be 181 relevant to CDNI. In particular, Section 2.1 will describe the 182 various methods to store HAS content and Section 2.2 will list three 183 methods that are used to address HAS content in a CDN. 185 2.1. Segmentation versus Fragmentation 187 All HAS implementations are based around a concept referred to as 188 chunking: the concept of having a server split content up in numerous 189 fixed duration chunks, which are independently decodable. By 190 sequentially requesting and receiving chunks, a client can recreate 191 and play out the content. An advantage of this mechanism is that it 192 allows a client to seamlessly switch between different encodings of 193 the same Original Content at chunk boundaries. Before requesting a 194 particular chunk, a client can choose between multiple alternative 195 encodings of the same chunk, irrespective of the encoding of the 196 chunks it has requested earlier. 198 While every HAS implementation uses some form of chunking, not all 199 implementations store the resulting chunks in the same way. In 200 general, there are two distinct methods of performing chunking and 201 storing the results: segmentation and fragmentation. 203 - With segmentation, which is for example mandatory in all versions 204 of Apple's HLS prior to version 7, the chunks, in this case also 205 referred to as segments, are stored completely independent from 206 each other, with each segment being stored as a separate file from 207 a file system perspective. This means that each segment has its 208 own unique URL with which it can be retrieved. 210 - With fragmentation (or virtual segmentation), which is for example 211 used in Microsoft's Smooth Streaming, all chunks, or fragments, 212 belonging to the same Chunk Collection are stored together, as 213 part of a single file. While there are a number of container 214 formats which allow for storing this type chunked content, 215 Fragmented MP4 is most commonly used. With fragmentation, a 216 specific chunk is addressable by subfixing the common file URL 217 with an identifier uniquely identifying the chunk one is 218 interested in, either by timestamp, by byterange, or in some other 219 way. 221 While one can argue about the merits of each of these two different 222 methods of handling chunks, both have their advantages and drawbacks 223 in a CDN environment. For example, fragmentation is often regarded 224 as a method that introduces less overhead, both from a storage and 225 processing perspective. Segmentation on the other hand, is regarded 226 as being more flexible and easier to cache. In practice, current HAS 227 implementations increasingly support both methods. 229 2.2. Addressing chunks 231 In order for a client to request chunks, either in the form of 232 segments or in the form of fragments, it needs to know how the 233 content has been chunked and where to find the chunks. For this 234 purpose, most HAS protocols use a concept that is often referred to 235 as a Manifest File (also known as Media Presentation Description, or 236 MPD); i.e. a file that lists the way the content has been chunked and 237 where the various chunks are located (in the case of segments) or how 238 they can be addressed (in the case of fragments). A Manifest File, 239 or set of Manifest Files, may also identify the different encodings, 240 and thus Chunk Collections, the content is available in. 242 In general, a HAS client will first request and receive a Manifest 243 File, and then, after parsing the information in the Manifest File, 244 proceed with sequentially requesting the chunks listed in the 245 Manifest File. Each HAS implementation has its own Manifest File 246 format and even within a particular format there are different 247 methods available to specify the location of a chunk. 249 Of course managing the location of files is a core aspect of every 250 CDN, and each CDN will have its own method of doing so. Some CDNs 251 may be purely cache-based, with no higher-level knowledge of where 252 each file resides at each instant in time. Other CDNs may have 253 dedicated management nodes which, at each instant in time, do know at 254 which servers each file resides. The CDNI interfaces designed in the 255 CDNI WG will probably need to be agnostic to these kinds of CDN- 256 internal architecture decisions. In the case of HAS there is a 257 strict relationship between the location of the content in the CDN 258 (in this case chunks) and the content itself (the locations specified 259 in the Manifest File). It is therefore useful to have an 260 understanding of the different methods in use in CDNs today for 261 specifying chunk locations in Manifest Files. The different methods 262 for doing so are described in sections 2.2.1 to 2.2.3. 264 Although these sections are especially relevant for segmented 265 content, due to its inherent distributed nature, the discussed 266 methods are also applicable to fragmented content. Furthermore, it 267 should be noted that the methods detailed below for specifying 268 locations of content items in Manifest Files do not only relate to 269 temporally segmented content (e.g. segments and fragments), but are 270 also relevant in situations where content is made available in 271 multiple representations (e.g., in different qualities, encoding 272 methods, resolutions and/or bitrates). In this case the content 273 consists of multiple chunk collections, which may be described by 274 either a single Manifest File or multiple interrelated manifest 275 files. In the latter case, there may be a high-level Manifest File 276 describing the various available bitrates, with URLs pointing to 277 separate Manifest Files describing the details of each specific 278 bitrate. For specifying the locations of the other Manifest Files, 279 the same methods apply that are used for specifying chunk locations. 281 2.2.1. Relative URLs 283 One method for specifying chunk locations in a Manifest File is 284 through the use of relative URLs. A relative URL is a URL that does 285 not include the HOST part of a URL but only includes (part of) the 286 PATH part of a URL. In practice, a relative URL is used by the 287 client as being relative to the location where the Manifest File has 288 been acquired from. In these cases a relative URL will take the form 289 of a string that has to be appended to the location of the Manifest 290 File to get the location of a specific chunk. This means that in the 291 case a manifest with relative URLs is used, all chunks will be 292 delivered by the same surrogate that delivered the Manifest File. A 293 relative URL will therefore not include a hostname. 295 For example, in the case a Manifest File has been requested (and 296 received) from: 298 http://surrogate.server.cdn.example.com/content_1/manifest.xml 300 , a relative URL pointing to a specific segment referenced in the 301 manifest might be: 303 segments/segment1_1.ts 305 Which means that the client should take the location of the manifest 306 file and append the relative URL. In this case, the segment would 307 then be requested from http://surrogate.server.cdn.example.com/ 308 content_1/segments/segment1_1.ts 310 The downside of using relative URLs is that it forces a CDN to 311 deliver all segments belonging to a given content item with the same 312 surrogate that delivered the Manifest File for that content item. 313 The advantage of relative URLs is that it is very easy to transfer 314 content between different surrogates and even CDNs. 316 2.2.2. Absolute URLs with Redirection 318 Another method for specifying locations of chunks (or other manifest 319 files) in a Manifest File is through the use of an absolute URL. An 320 absolute URL contains a fully formed URL (i.e. the client does not 321 have to calculate the URL as in the case of the relative URL but can 322 use the URL from the manifest directly). 324 In the context of Manifest Files, there are two types of absolute 325 URLs imaginable: Absolute URLs with Redirection and Absolute URLs 326 without Redirection. The two methods differ in whether the URL 327 points to a request routing node which will redirect the client to a 328 surrogate (Absolute URL with Redirection) or point directly to a 329 surrogate hosting the requested content (Absolute URL without 330 Redirection). 332 In the case of Absolute URLs with Redirection, a request for a chunk 333 is handled by the request routing system of a CDN just as if it were 334 a standalone (non-HAS) content request, which might include looking 335 up the surrogate (and/or CDN) best suited for delivering the 336 requested chunk to the particular user and sending an HTTP redirect 337 to the user with the URL pointing to the requested chunk on the 338 specified surrogate (and/or CDN), or a DNS response pointing to the 339 specific surrogate. 341 An example of an Absolute URL with Redirection might look as follows: 343 http://requestrouting.cdn.example.com/ 344 content_request?content=content_1&segment=segment1_1.ts 346 As can be seen from this example URL, the URL includes a pointer to a 347 general CDN request routing function and includes some arguments 348 identifying the requested segment. 350 The advantage of using Absolute URLs with Redirection is that it 351 allows for maximum flexibility (since chunks can be distributed 352 across surrogates and CDN in any imaginable way) without having to 353 modify the Manifest File every time one or more chunks are moved (as 354 is the case when Absolute URLs without Redirection are used). The 355 downside of this method is that it can adds significant load to a CDN 356 request routing system, since it has to perform a redirect every time 357 a client requests a new chunk. 359 2.2.3. Absolute URL without Redirection 361 In the case of the Absolute URL without Redirection, the URL points 362 directly to the specific chunk on the actual surrogate that will 363 deliver the requested chunk to the client. In other words, there 364 will be no HTTP redirection operation taking place between the client 365 requesting the chunk and the chunk being delivered to the client by 366 the surrogate. 368 An example of an Absolute URLs without Redirection is the following: 370 http://surrogate.cdn.example.com/content_1/segments/segment1_1.ts 372 As can be seen from this example URL, the URL includes both the 373 identifier of the requested segment (in this case segment1_1.ts), as 374 well as the server that is expected to deliver the segment (in this 375 case surrogate.cdn.example.com). With this, the client has enough 376 information to directly request the specific segment from the 377 specified surrogate. 379 The advantage of using Absolute URLs without Redirection is that it 380 allows more flexibility compared to using Relative URLs (since 381 segments do not necessarily have to be delivered by the same server) 382 while not requiring per-segment redirection (which would add 383 significant load to the node doing the redirection). The drawback of 384 Absolute URLs without Redirection is that it requires a modification 385 of the Manifest File every time content is moved to a different 386 location (either within a CDN or across CDNs). 388 3. Possible HAS Optimizations 390 In the previous chapter, some of the unique properties of HAS have 391 been discussed. Furthermore, some of the CDN-specific design 392 decisions with regards to addressing chunks have been detailed. In 393 this chapter, the impact of supporting HAS in CDN Interconnection 394 scenarios will be discussed. 396 There are a number of topics, or problem areas, that are of 397 particular interest when considering the combination of HAS and CDNI. 398 For each of these problem areas it holds that there are a number of 399 different ways in which the CDNI Interfaces can deal with them. In 400 general it can be said that each problem area can either be solved in 401 a way that minimizes the amount of HAS-specific changes to the CDNI 402 Interfaces or in way that maximizes the flexibility and efficiency 403 with which the CDNI Interfaces can deliver HAS content. The goal for 404 the CDNI WG should probably be to try to find the middle ground 405 between these two extremes and try to come up with solutions that 406 optimize the balance between efficiency and additional complexity. 408 In order to allow the WG to make this decision, this chapter will 409 briefly describe each of the following problem areas together with a 410 number of different options for dealing with them. Section 3.1 will 411 discuss the problem of how to deal with file management of groups of 412 files, or Content Collections. Section 3.2 will deal with a related 413 topic: how to do content acquisition of Content Collections between 414 the uCDN and dCDN. After that, Section 3.3 describes the various 415 options for the request routing of HAS content, particularly related 416 to Manifest Files. Section 3.4 talks about a number of possible 417 optimizations for the logging of HAS content, while Section 3.5 418 discusses the options regarding URL signing. Section 3.6 finally, 419 describes different scenarios for dealing with the removal of HAS 420 content from CDNs. 422 3.1. File Management and Content Collections 424 One of the unique properties of HAS content is that it does not 425 consist of a single file or stream but of multiple interrelated files 426 (segment, fragments and/or Manifest Files). In this document this 427 group of files is also referred to as a Content Collection. Another 428 important aspect is the difference between segments and fragments 429 (see Section 2.1). 431 Irrespective of whether segments or fragments are used, different 432 CDNs might handle Content Collections differently from a file 433 management perspective. For example, some CDNs might handle all 434 files belonging to a Content Collection as individual files, which 435 are stored independently from each other. An advantage of this 436 approach is that makes it easy to cache individual chunks. Other 437 CDNs might store all fragments belonging to a Content Collection in a 438 bundle, as if they were a single file (e.g. by using a fragmented MP4 439 container). The advantage of this approach is that it reduces file 440 management overhead. 442 This section will look at the various ways with which the CDNI 443 interfaces might deal with these differences in handling Content 444 Collections from a file management perspective. The different 445 options can be distinguished based on the level of HAS-awareness they 446 require on the part of the different CDNs and the CDNI interfaces. 448 3.1.1. Option 1.1: No HAS awareness 450 This first option assumes no HAS awareness in both the involved CDNs 451 and the CDNI Interfaces. This means that the uCDN uses individual 452 files and the dCDN is not explicitely made aware of the relationship 453 between chunks and it doesn't know which files are part of the same 454 Content Collection. In practice this scenario would mean that the 455 file management method used by the uCDN is simply imposed on the dCDN 456 as well. 458 This scenario also means that it is not possible for the dCDN to use 459 any form of file bundling, such as the single-file mechanism which 460 can be to store fragmented content as a single file (see 461 Section 2.1). The one exception to this rule is the situation where 462 the content is fragmented and the Manifest Files on the uCDN contains 463 byte range requests, in which case the dCDN might be able to acquire 464 fragmented content as a single file (see Section 3.2.2). 466 Effect on CDN Interfaces: 468 o None 470 Advantages/Drawbacks: 472 + No HAS awareness necessary in CDNs, no changes to CDNI Interfaces 473 necessary 475 - The dCDN is forced to store chunks as individual files. 477 3.1.2. Option 1.2: Allow single file storage of fragmented content 479 In some cases, the dCDN might prefer to store fragmented content as a 480 single file on its surrogates to reduce file management overhead. In 481 order to do so, it needs to be able to either acquire the content as 482 a single file (see Section 3.2.2), or merge the different chunks 483 together and place them in the same container (e.g. fragmented MP4). 485 The downside of this is that in order to do so, the dCDN needs to be 486 fully HAS aware. 488 Effect on CDN Interfaces: 490 o CDNI Metadata Interface: Add fields for indicating the particular 491 type of HAS (e.g. MPEG DASH or HLS) that is used and whether 492 segments or fragments are used 494 o CDNI Metadata Interface: Add field for indicating the name and 495 type of the manifest file(s) 497 Advantages/Drawbacks: 499 + Allows dCDN to store fragmented content as a single file, reducing 500 file management overhead 502 - Complex operation, requiring dCDN to be fully HAS aware 504 3.2. Content Acquisition of Content Collections 506 In the previous section the relationship between file management and 507 HAS in a CDNI scenario has been discussed. This section will discuss 508 a related topic, which is content acquisition between two CDNs. 510 3.2.1. Option 2.1: No HAS awareness 512 This first option assumes no HAS awareness in both the involved CDNs 513 and the CDNI Interfaces. Just as with Option 1.1 discussed in the 514 previous section with regards to file management, having no HAS 515 awareness means that the dCDN is not aware of the relationship 516 between chunks. In the case of content acquisition, this means that 517 each and every file belonging to a Content Collection will have to be 518 individually acquired from the uCDN by the dCDN. The exception to 519 the rule is in cases with fragmented content where the uCDN uses 520 Manifest Files which contain byte range requests. In this case the 521 dCDN can simply omit the byte range identifier and acquire the 522 complete file. 524 The advantage of this approach is that it is highly flexible. If a 525 client only requests a small portion of the chunks belonging to a 526 particular Content Collection, the dCDN only has to acquire those 527 chunks from the uCDN, saving both bandwidth and storage capacity. 529 The downside of acquiring content on a per-chunk basis is that it 530 creates more transaction overhead between the dCDN and uCDN compared 531 to a method in which entire Content Collections can be acquired as 532 part of one transaction. 534 Effect on CDN Interfaces: 536 o None 538 Advantages/Drawbacks: 540 + Per-chunk content acquisition allows for high level of flexibility 541 between dCDN and uCDN 543 - Per-chunk content acquisition creates more transaction overhead 544 between dCDN and uCDN 546 3.2.2. Option 2.2: Allow single file acquisition of fragmented content 548 As discussed in Section 3.2.1, there is one (fairly rare) in cases 549 where fragmented content can be acquired as a single file without any 550 HAS awareness and that is when fragmented content is used and where a 551 Manifest File includes byte range request. This section discusses 552 how to perform single file acquisition in the other (very common) 553 cases. To do so, the dCDN would have to have full-HAS awareness (at 554 least to the extent of being able to map between single file and 555 individual chunks to serve). 557 Effect on CDN Interfaces: 559 o CDNI Metadata Interface: Add fields for indicating the particular 560 type of HAS (e.g. MPEG DASH or HLS) that is used and whether 561 segments or fragments are used 563 o CDNI Metadata Interface: Add field for indicating the name and 564 type of the manifest file(s) 566 Advantages/Drawbacks: 568 + Allows for more efficient content acquisition in all HAS-specific 569 supported forms 571 - Requires full HAS awareness on part of dCDN 573 - Requires significant CDNI Metadata Interface extensions 575 3.3. Request Routing of HAS content 577 In this section the effect HAS content has on request routing will be 578 identified. Of particular interest in this case are the different 579 types of Manifest Files that might be used. In Section 2.2, three 580 different methods for identifying and addressing chunks from within a 581 Manifest File were described: Relative URLs, Absolute URLs without 582 Redirection and Absolute URLs with Redirection. Of course not every 583 current CDN will use and/or support all three methods. Some CDNs may 584 only use one of the three methods, while others may support two or 585 all three. 587 An important factor in deciding which chunk addressing method is used 588 is the Content Provider. Some Content Providers may have a strong 589 preference for a particular method and deliver the Manifest Files to 590 the CDN in a particular way. Depending on the CDN and the agreement 591 it has with the Content Provider, a CDN may either host the Manifest 592 Files as they were created by the Content Provider, or modify the 593 Manifest File to adapt it to its particular architecture (e.g. by 594 changing relative URLs to Absolute URLs which point to the CDN 595 Request Routing function). 597 3.3.1. Option 3.1: No HAS awareness 599 This first option assumes no HAS awareness in both the involved CDNs 600 and the CDNI Interfaces. This scenario also assumes that neither the 601 dCDN nor the uCDN have the ability to actively manipulate Manifest 602 Files. As was also discussed with regards to file management and 603 content acquisition, having no HAS awareness means that each file 604 constituting a Content Collections is handled on an individual basis, 605 with the dCDN unaware of any relationship between files. 607 The only chunk addressing method that works without question in this 608 case is Absolute URLs with Redirection. In other words, the Content 609 Provider that ingested the content into the uCDN created a Manifest 610 File with each chunk location pointing to the Request Routing 611 function of the uCDN. Alternatively, the Content Provider may have 612 ingested the Manifest File containing relative URLs and the uCDN 613 ingestion function has translated these to Absolute URLs pointing to 614 the Request Routing function. 616 In this Absolute URL with Redirection case, the uCDN can simply have 617 the Manifest File be delivered by the dCDN as if it were a regular 618 file. Once the client parses the Manifest File, it will request any 619 subsequent chunks from the uCDN Request Routing function. That 620 function can then decide to outsource the delivery of that chunk to 621 the dCDN. In that case it will probably redirect the client to the 622 Request Routing function of the dCDN (assuming it does not have the 623 necessary information to redirect the client directly to a surrogate 624 in the dCDN). The drawback of this method is that it creates a large 625 amount of request routing overhead for both the uCDN and dCDN. For 626 each chunk the full inter-CDN Request Routing process is invoked 627 (which can result in two redirections in the case of iterative 628 redirection, or result in one redirection plus one CDNI Request 629 Routing/Redirection Interface request/response). 631 With no HAS awareness, Relative URLs might or might not work 632 depending on the HAS client implementation that is used. When a uCDN 633 delegates the delivery of a Manifest File containing Relative URLs to 634 a dCDN, the client goes directly to the dCDN surrogate from which it 635 has received the Manifest File for every subsequent chunk. The 636 question here is whether the HAS client uses the IP address or the 637 hostname in its chunk request to the dCDN surrogate. In case it uses 638 the exact same hostname with which it requested the manifest file 639 (and which is the result of a request routing operation) than 640 everything works properly (because the dCDN can easily associate the 641 CDNI metadata for the corresponding chuck and therefor serve the 642 corresponding request). However, in situations where the client uses 643 the IP address of the surrogate or does a reverse DNS look-up, the 644 dCDN surrogate may not be able to associate CDNI metadata with the 645 chucnk request and therefore may not be able to serve it. One 646 exception to this is in the scenario where the PATH or QUERY part of 647 the chunk request URL is enough to uniquely identify the particular 648 chunk, in which case the dCDN Surrigate can associate CDNI metadata 649 and serve the request 651 Since using Absolute URLs without Redirection inherently require a 652 HAS aware CDN, they also cannot be used in this case. The reason for 653 this is that with Absolute URLs without Redirection, the URLs in the 654 Manifest File will point directly to a surrogate in the uCDN. Since 655 this scenario assumes no HAS awareness on the part of the dCDN or 656 uCDN, it is impossible for either of these CDNs to rewrite the 657 Manifest File and thus allow the client to either go to a surrogate 658 in the dCDN or to a request routing function. 660 Effect on CDN Interfaces: 662 o None 664 Advantages/Drawbacks: 666 + Supports Absolute URLs with Redirection 668 + Does not require HAS awareness and/or changes to the CDNI 669 Interfaces 671 - Not possible to use Absolute URLs without Redirection 673 - Support for Relative URLs suffers from some brittleness. Makes 674 assumptions on client-side implementation of the HAS client or on 675 structure of PATH or QUERY 677 - Creates significant signaling overhead in case Absolute URLs with 678 Redirection are used (inter-CDN request redirection for each 679 chunk) 681 3.3.2. Option 3.2: Manifest File rewriting by uCDN 683 While Option 3.1 does allow for Absolute URLs with Redirection to be 684 used, it does so in a way that creates a high-level of request 685 routing overhead for both the dCDN and the uCDN. This option 686 presents a solution to significantly reduce this overhead. 688 In this scenario, the uCDN is able to modify the Manifest File to be 689 able to remove itself from the request routing chain for chunks being 690 referenced in the Manifest File. As described in Section 3.3.1, in 691 the case of no HAS awareness the client will go to the uCDN request 692 routing function for each chunk request. This request routing 693 function can then redirect the client to the dCDN request routing 694 function. By rewriting the Manifest File, the uCDN is able to remove 695 this first step, and have the Manifest File point directly to the 696 dCDN request routing function. 698 In order for the uCDN to be able to do this, it needs the location of 699 the dCDN request routing function (or even better: the location of 700 the dCDN surrogate). The simplest way to obtain this information is 701 to use the CDNI Request Routing Interface in one of two ways. The 702 first way would be to have the uCDN ask the dCDN for the location of 703 its request routing node (through the CDNI Request Routing/ 704 Redirection Interface) every time a request for a Manifest File comes 705 in at the uCDN request routing node. The uCDN would then modify the 706 manifest file and deliver the manifest file to the client. A second 707 way to do it would be for the modification of the manifest file to 708 only happen once, when the first client for that particular Content 709 Collection (and redirected to that particular dCDN) sends a Manifest 710 File request. The advantage of the first method is that it maximizes 711 effiency and flexibility by allowing the dCDN to respond with the 712 locations of its surrogates instead of the location of its request 713 routing function (and effectively turning the URLs into Absolute URLs 714 without Redirection). The advantage of the second method is that the 715 uCDN only has to modify the Manifest File once. 717 Effect on CDN Interfaces: 719 o CDNI Request Routing Interface: Allow uCDN to query dCDN for the 720 location of its request routing function (is this covered by the 721 existing RR interface?) 723 o uCDN: Allow for modification of manifest file 724 Advantages/Drawbacks: 726 + Possible to significantly decrease signalling overhead when using 727 Absolute URLs. 729 + (Optional) Possible to have uCDN modify manifest with locations of 730 surrogates in dCDN (turning Absolute URLs with Redirection in 731 Absolute URLs without Redirection) 733 + Minimal changes to CDNI Interfaces (no HAS awareness) 735 + Does not require HAS awareness in dCDN 737 - Requires high level of HAS awareness in uCDN (for modifying 738 manifest files) 740 3.3.3. Option 3.3: Two-step Manifest File rewriting 742 One of the possibilities with Option 3.3 is allowing the dCDN to 743 provide the locations of a specific surrogate to the uCDN, so that 744 the uCDN can fit the Manifest File with Absolute URLs without 745 Redirection and the client can request chunks directly from a dCDN 746 surrogate. However, some dCDNs might not be willing to provide this 747 sensitive information to the uCDN. In that case they can only 748 provide the uCDN with the location of their request routing function 749 and thereby not be able to use Absolute URLs without Redirection. 751 One method for solving this limitation is allowing two-step Manifest 752 File manipulation. In the first step the uCDN would perform its own 753 modification, and place the locations of the dCDN request routing 754 function in the Manifest File. Then, once a request for the Manifest 755 File comes in at the dCDN request routing function, it would perform 756 a second modification in which it replaces the URLs in the Manifest 757 Files with the URLs of its surrogates. This way the dCDN can still 758 profit from having minimal request routing traffic, while not having 759 to share sensitive surrogate information with the uCDN. 761 The downside of this approach is that it not only assumes HAS 762 awareness in the dCDN but that it also requires some HAS-specific 763 additions to the CDNI Metadata Interface. In order for the dCDN to 764 be able to change the Manifest File, it has to have some information 765 about the structure of the content. Specifically, it needs to have 766 information about which chunks make up the Content Collection. 768 Effect on CDN Interfaces (apart from those listed under Option 3.3): 770 o CDNI Metadata Interface: Add necessary fields for conveying HAS 771 specific information (e.g. the files that make up the Content 772 Collection) to the dCDN. 774 o dCDN: Allow for modification of manifest file 776 Advantages/Drawbacks (apart from those listed under Option 3.3): 778 + Allows dCDN to use Absolute URLs without Redirection without 779 having to convey sensitive information to the uCDN 781 - Requires high level of HAS awareness in dCDN (for modifying 782 manifest files) 784 - Requires adding HAS-specific information to the CDNI Metadata 785 Interface 787 3.4. Logging 789 3.4.1. HAS Considerations for CDNI Logging 791 As stated in [I-D.ietf-cdni-problem-statement], "the CDNI Logging 792 interface enables details of logs or events to be exchanged between 793 interconnected CDNs". 795 As discussed in [I-D.draft-bertrand-cdni-logging], the CDNI logging 796 information can be used fort multiple purposes including maintenance/ 797 debugging by uCDN, accounting (e.g. in view of billing or 798 settlement), reporting and management of end-user experience (e.g. to 799 the CSP), analytics (e.g. by the CSP) and control of content 800 distribution policy enforcement (e.g. by the CSP). 802 The key consideration for HAS with respect to logging is the 803 potential increase of the number of Log records by two to three 804 orders of magnitude, as compared to regular HTTP delivery of a video, 805 since log records would typically be generated on a per-chunk- 806 delivery basis instead of per-content-item-delivery basis. This 807 impacts the scale of every processing step in the Logging Process 808 (see Section 8 of [I-D.draft-bertrand-cdni-logging]), including: 810 a. Logging Generation and Storing of logs on CDN elements 811 (Surrogate, Request Routers,..) 813 b. Logging Aggregation within a CDN 815 c. Logging Manipulation (including Logging Protection, Logging 816 Filtering , Logging Update and Rectification) 818 d. (Where needed) Logging CDNI Reformatting (e.g. reformatting from 819 CDN-specific format to the CDNI Logging Interface format for 820 export by dCDN to uCDN) 822 e. Logging exchange via CDNI Logging Interface 824 f. (Where needed) Logging Re-Reformatting (e.g. reformatting from 825 CDNI Logging Interface format into log-consuming specific 826 application) 828 g. Logging consumption/processing (e.g. feed logs into uCDN 829 accounting application, feed logs into uCDN reporting system to 830 provide per CSP views, feed logs into debugging tool to debug) 832 Note that there may be multiple instances of step [f] and [g] running 833 in parallel. 835 While the CDNI Logging Interface is only used to perform step [e], we 836 note that its format directly affects step [d] and [f] and that its 837 format also indirectly affects the other steps (for example if the 838 CDNI Logging Interface requires per-chunk log records, step [a], [b] 839 and [d] cannot operate on a per-HAS-session basis and also need to 840 operate on a per-chunk basis). 842 3.4.2. Candidate Approaches 844 The following sub-sections discusses the main candidate approaches 845 identified so far for CDNI in terms of dealing with HAS with respect 846 to Logging. 848 3.4.2.1. Option 4.1: "Do-Nothing" Approach 850 In this approach, each HAS-chunk delivery is considered, for CDNI 851 Logging, as a standalone content delivery. In particular, a separate 852 log record for each HAS-chunk delivery is included in the CDNI 853 Logging Interface in step [e]. This approach requires that step [a], 854 [b] , [c], [d] and [e] be performed on per-chunk basis. This 855 approach allows [g] to be performed either on a per-chunk basis 856 (assuming step [e] maintains per-chunk records) or on a more 857 "summarized" manner such as per-HAS-Session basis assuming step [e] 858 summarizes per-chunk records into per-HAS-session records). 860 Effect on CDN Interfaces: 862 o None 864 Effect on uCDN and dCDN: 866 o None 868 Advantages/Drawbacks: 870 + No information loss (i.e. all details of each individual chunk 871 delivery are preserved). While this full level of detail may not 872 be needed for some Log consuming applications (e.g. billing), this 873 full level of detail is likely valuable (possibly required) for 874 some Log consuming applications (e.g. debugging) 876 + Easier integration (at least in the short term) into existing 877 Logging tools since those are all capable of handling per-chunk 878 records 880 + No extension needed on CDNI interfaces 882 - High volume of logging information to be handled (storing & 883 processing) at every step of the Logging process from [a] to [g] 884 (while summarization in step [f] is conceivable, it may be 885 difficult to achieve in practice without any hints for correlation 886 in the log records). While the high volume of logging information 887 is a potential concern, we are seeking expert input on whether it 888 is a real practical issue, and if yes, then in what timeframe/ 889 assumptions. 891 3.4.2.2. Option 4.2: "CDNI Metadata Content Collection ID" Approach 893 In this approach, a "Content Collection ID" (CCID) field is 894 distributed through the CDNI Metadata Interface and the same CCID 895 value is associated with every chunk of the same Content Collection. 896 The objective of this field is to facilitate summarization of per- 897 chunk records at step [f] into something along the lines of per-HAS- 898 session logs, at least for the Log Consuming application that do not 899 require per-chunk detailed information (for example billing). 901 [Editor's Note: would there be value in adding a little more info in 902 the metadata such as which HAS-scheme is used?] 904 Effect on CDN Interfaces: 906 o One additional metadata field (CCID) in CDNI Metadata Interface 908 Effect on uCDN and dCDN: 910 o None 912 Advantages/Drawbacks: 914 + No information loss (i.e. all details of each individual chunk 915 delivery are preserved). While this full level of detail may not 916 be needed for some Log consuming applications (e.g. billing), this 917 full level of detail is likely valuable (possibly required) for 918 some Log consuming applications (e.g. debugging) 920 + Easier integration (at least in the short term) into existing 921 Logging tools since those are all capable of handling per-chunk 922 records 924 + Very minor extension to CDNI interfaces needed 926 + Facilitated summarization of records related to a HAS session in 927 step [f] and therefore ability to operate on lower volume of 928 logging information in step [g] by log consuming applications that 929 do not need per-chunk record details (e.g. billing) 931 - High volume of logging information to be handled (storing & 932 processing) at every step of the Logging process from [a] to [f]. 933 While the high volume of logging information is a potential 934 concern, we are seeking input on whether it is a real practical 935 issue, and if yes in what timeframe/assumptions 937 3.4.2.3. Option 4.3: "CDNI Metadata Content Collection ID With dCDN 938 Summarization" Approach 940 In this approach, a "Content Collection ID" (CCID) field is 941 distributed through the CDNI Metadata Interface and the same CCID 942 value is associated with every chunk of the same Content Collection. 943 In this approach, a summarization of per-chunk records is performed 944 at step [d] (or in earlier steps) taking advantage of the CCID, so 945 that a reduced volume of logging information is to be handled in 946 steps [e] to [g] of the logging process (and is optionally also 947 possible in steps [a] to [c]). The objective of this approach is to 948 reduce the volume of logging information early in the Logging process 950 Regarding the summarization performed at step [d] (or in earlier 951 steps), there is a continuum in terms of trade-off between level of 952 summarization of per-chunk records and information loss. For 953 example, it appears possible to perform a summarization that results 954 is significant gains with limited information loss, perhaps using 955 summarized logs along the lines of the Event-Based Logging format 956 discussed in section 3.2.2 of 957 [I-D.draft-lefaucheur-cdni-logging-delivery]. Alternatively, it may 958 be possible to perform a summarization that results in very 959 significant gains with significant information loss, perhaps using 960 summarized logs along the lines of the Summary-Based Logging format 961 discussed in section 3.2.3 of 963 [I-D.draft-lefaucheur-cdni-logging-delivery]. 965 Effect on CDN Interfaces: 967 o One additional metadata field (CCID) in CDNI Metadata Interface 969 o Summarized logging information in CDNI Logging Information 971 Effect on uCDN and dCDN: 973 o None 975 Advantages/Drawbacks: 977 + Lower volume of logging information to be handled (storing & 978 processing) at every step of the Logging process from [e] to [g], 979 and optionally from [a] to [d] also 981 + Small extensions to CDNI interfaces needed 983 - Some information loss (i.e. all details of each individual chunk 984 delivery are not preserved). The actual information loss depends 985 on the summarization approach selected (typically the lower the 986 information loss, the lower the summarization gain) so the right 987 sweet-spot would had ego be selected. While full level of detail 988 may not be needed for some Log consuming applications (e.g. 989 billing), the full level of detail is likely valuable (possibly 990 required) for some Log consuming applications (e.g. debugging) 992 - Less easy integration (at least in the short term) into existing 993 Logging tools since those are all capable of handling per-chunk 994 records and may not be capable of handling CDNI summarized records 996 3.4.2.4. Option 4.4: "CDNI Logging Interface Compression" Approach 998 In this approach, a loss-less compression technique is applied to the 999 sets of Logging records (e.g. Logging files) for transfer on the 1000 IETF CDNI Logging Interface. The objective of this approach is to 1001 reduce the volume of information to be stored and transferred in step 1002 [e]. 1004 Effect on CDN Interfaces: 1006 o One additional compression mechanism to be included in the CDNI 1007 Logging Interface 1009 Effect on uCDN and dCDN: 1011 o None 1013 Advantages/Drawbacks: 1015 + No information loss (i.e. all details of each individual chunk 1016 delivery are preserved). While this full level of detail may not 1017 be needed for some Log consuming applications (e.g. billing), this 1018 full level of detail is likely valuable (possibly required) for 1019 some Log consuming applications (e.g. debugging) 1021 + Easier integration (at least in the short term) into existing 1022 Logging tools since those are all capable of handling per-chunk 1023 records 1025 + Small extension to CDNI interfaces needed 1027 + Reduced volume of logging information in step [e] 1029 - High volume of logging information to be handled (storing & 1030 processing) at every step of the Logging process from [a] to [g], 1031 except [e]. While the high volume of logging information is a 1032 potential concern, we are seeking expert input on whether it is a 1033 real practical issue, and if yes, then in what timeframe/ 1034 assumptions 1036 Input is sought on expected compression gains achievable in practice 1037 over sets of logs containing per-chunk records. 1039 3.4.2.5. Option 4.5: "Full HAS awareness" Approach 1041 In this approach, HAS-awareness is assumed across the CDNs 1042 interconnected via CDNI and the necessary information to describe the 1043 HAS relationship across all chunks of the same Content Collection is 1044 distributed through the CDNI Metadata Interface. In this approach, 1045 the dCDN Surrogates leverage the HAS information distributed through 1046 the CDNI metadata and their HAS-awareness to generate summarized 1047 logging information in the very first place. The objective of that 1048 approach is to operate on lower volume of logging information right 1049 from the very first step of the Logging process. 1051 The summarized HAS logs generated by the Surrogates in this approach 1052 are similar to those discussed in the section " "CDNI Metadata 1053 Content Collection ID With dCDN Summarization" Approach" and the same 1054 trade-offs between information loss and summarization gain apply. 1056 Effect on CDN Interfaces: 1058 o One significant extension of the CDNI Metadata Interface to convey 1059 HAS relationship across chunks of a Content Collection. Note that 1060 this extension requires specific support for every HAS-protocol to 1061 be supported over the CDNI mesh 1063 Effect on uCDN and dCDN: 1065 o Full HAS-awareness by dCDN Surrogates 1067 Advantages/Drawbacks: 1069 + Lower volume of logging information to be handled (storing & 1070 processing) at every step of the Logging process from [a] to [g] 1072 + Accurate generation of summarized logs because of HAS awareness on 1073 Surrogate 1075 - Very significant extensions to CDNI interfaces needed including 1076 per HAS-protocol specific support 1078 - Very significant additional requirement for HAS awareness on dCDN 1080 - Some information loss (i.e. all details of each individual chunk 1081 delivery are not preserved). The actual information loss depends 1082 on the summarization approach selected (typically the lower the 1083 information loss, the lower the summarization gain) so the right 1084 sweet-spot would had ego be selected. While full level of detail 1085 may not be needed for some Log consuming applications (e.g. 1086 billing), the full level of detail is likely valuable (possibly 1087 required) for some Log consuming applications (e.g. debugging) 1089 - Less easy integration (at least in the short term) into existing 1090 Logging tools since those are all capable of handling per-chunk 1091 records and may not be capable of handling CDNI summarized records 1093 Input is sought on expected compression gains achievable in practice 1094 over sets of logs containing per-chunk records. 1096 3.5. URL Signing 1098 URL Signing is an authorization method for content delivery. This is 1099 based on embedding the HTTP URL with information that can be 1100 validated to ensure the request has legitimate access to the content. 1101 There are two parts: 1) parameters that convey authorization 1102 restrictions (e.g. source IP address and time period) and/or 1103 protected URL portion, and 2) authenticator value that confirms the 1104 integrity of the URL and authenticates the URL creator. The 1105 authorization parameters can be anything agreed upon between the 1106 entity that creates the URL and the entity that validates the URL. A 1107 key is used to generate the authenticator (i.e. sign the URL) and 1108 validate the authenticator. This may or may not be the same key. 1110 There are two types of keys: asymmetric keys and symmetric key. 1111 Asymmetric keys always have a key pair made up of a public key and 1112 private key. The private key and public key are used for signing and 1113 validating the URL, respectively. A symmetric key is the same key 1114 that is used for both functions. Regardless of the type of key, the 1115 entity that validates the URL has obtain the key. Distribution for 1116 the symmetric key requires security to prevent others from taking it. 1117 Public key can be distributed freely while private key is kept by the 1118 URL signer. 1120 URL Signing operates in the following way. A signed URL is provided 1121 by the content owner (i.e. URL signer) to the user during website 1122 navigation. When the user selects the URL, the HTTP request is sent 1123 to the delivery node which validates that the URL before delivering 1124 the content. 1126 3.5.1. URL Signing in CDNI 1128 For CDNI, URL Signing is based on the Upstream CDN and Downstream CDN 1129 as entities that sign and validate the URL, respectively. HTTP-based 1130 request routing changes the URL. Thus, each redirection requires the 1131 URL to be re-signed. The alternative is protection of only the 1132 invariant portion of the URL to avoid re-signing by the transit CDN. 1133 DNS-based request routing maintains the same URL. In essence, there 1134 are three cases: 1) The URL is validated, rewritten, and re-signed at 1135 each request routing hop, 2) The URL is changed but only the 1136 invariant portion of URL is validated, and 3) The URL remains the 1137 same and validated by the delivery CDN surrogate. 1139 The Downstream CDN needs to obtain the key for validating the URL. 1140 When asymmetric keys are used, the public key can be retrieved from 1141 the authorization parameters embedded in the URL. The Downstream CDN 1142 can validate the URL with the public key, regardless of the 1143 relationship with the URL signer (i.e. Downstream CDN has or does 1144 not have a direct relationship with the Upstream CDN that signed the 1145 URL). When symmetric key is used, the Downstream CDN needs to obtain 1146 the key in a secure method that is out of scope. For cascaded CDNs, 1147 a common key is distributed for validation of unaltered URL to 1148 support DNS-based request routing. Alternatively, a shared key is 1149 distributed between adjacent CDNs to support rewritten URL that is 1150 used in HTTP-based request routing. 1152 URL Signing requires support in most of the CDNI Interfaces. The 1153 CDNI Metadata interface should specify the content that is subject to 1154 URL signing and provide information to perform the function. The 1155 Downstream CDN should inform the Upstream CDN that it supports URL 1156 Signing in the asynchronous capabilities information advertisement as 1157 part of the Request Routing interface. This allows the CDN selection 1158 function in request routing to choose the Downstream CDN with URL 1159 signing capability when the CDNI metadata of the content requires 1160 this authorization method. The Logging interface provides 1161 information on the authorization method (e.g. URL Signing) and 1162 related authorization parameters used for content delivery. URL 1163 Signing has no impact on the Control interface. 1165 3.5.2. Option 5.1: No HAS awareness 1167 For HTTP Adaptive Streaming, the Manifest File contains the Relative 1168 Locator, Absolute Locator without Redirection, or Absolute Locator 1169 with Redirection for specifying the chunk location. The 1170 Authoritative CDN performs URL signing for the Manifest File and 1171 chunks. The delivery CDN surrogate has to obtain the key to validate 1172 the URL. Although the Manifest file and chunk are treated the same 1173 by the CDN that is not HAS aware, there are some implications for URL 1174 Signing based on the method used to reference the chunk location in 1175 the Manifest file. 1177 For Absolute URL without Redirection, the Authoritative CDN signs the 1178 chunk URL which is associated with the delivery CDN surrogate. Since 1179 the entire URL is set and does not change during request routing 1180 (i.e. DNS-based redirection only and no HTTP-based redirection), 1181 there are no issues for signing and validating the URL. 1183 For Relative URL, the Authoritative CDN does not know the URL that 1184 will be ultimately used by a Downstream CDN to deliver the chunk. 1185 This uncertainty makes it impossible to accurately sign the URL in 1186 the Manifest File. URL Basically, URL Signing using this reference 1187 method, "as is" for entire URL protection, is not supported. 1188 However, instead of signing the entire URL, the Authoritative CDN 1189 signs the Relative URL (i.e. invariant portion of the URL) and 1190 conveys the protected portion in the authorization parameters 1191 embedded in the chunk URL. This approach works the same way as 1192 Absolute URL, except the HOST part and (part of) the PATH part of the 1193 URL are not signed and validated. The tradeoff is flexibility vs 1194 security. The advantage is that the content can be authorized to be 1195 delivered from any host with arbitrary directory path. The drawback 1196 is lack of protection for the entire URL. One aspect may outweigh 1197 the other depending on the needs of the Authoritative CDN. 1199 For Absolute URL with Redirection, the Authoritative CDN signs the 1200 chunk URL with the intent that the targeted Request Routing function 1201 will validate and redirect the URL with a new URL signature. This 1202 method is same as the Absolute URL without Redirection from URL 1203 Signing perspective because the signed URL is the same URL that is 1204 validated. Only difference is that the request routing function 1205 needs to redirect the request with a new URL which may be signed or 1206 not. 1208 Effect on CDN Interfaces: 1210 o oURL Signing is enabled on the CDNI Request Routing (i.e. 1211 Capabilities advertisement), Metadata, and Logging interfaces 1213 Advantages/Drawbacks: 1215 + No HAS awareness necessary in CDNs, no changes to CDNI interface 1216 necessary 1218 - URL Signing for every chunk may be considered as processing 1219 overhead 1221 3.5.3. Option 5.2: HAS-awareness with Authorization Token 1223 Up to this point, the Manifest File and chunks are treated as normal 1224 file in the HTTP delivery. There are no specific changes needed for 1225 the CDN to support HAS. However, if CDN is aware of HAS, then the 1226 Manifest File and chunk can be treated differently and appropriately. 1228 URL Signing is fundamentally about authorizing access to a Content 1229 Item or its specific Content Collections (representations) for a 1230 specific user during a time period with possibly some other criteria. 1231 A chunk is an instance of the sets of chunks referenced by the 1232 Manifest File for the Content Item or its specific Content 1233 Collections. This relationship means that once the Downstream CDN 1234 has authorized the Manifest File, it can assume that the associated 1235 chunks are implicitly authorized. The new function for the CDN is to 1236 link the Manifest File with the chunks for the HTTP session. This 1237 can be accomplished by using authorization token or session based 1238 encryption. This section covers the former and next section covers 1239 the latter. 1241 After validating the URL and detecting that the requested content is 1242 a Manifest File, the delivery CDN surrogate creates a state and sets 1243 a HTTP cookie with authorization token for the HTTP session. When a 1244 request for a chunk arrives, the surrogate confirms that the HTTP 1245 cookie value contains the correct authorization token. If so, the 1246 chunk is delivered due to transitive authorization property. 1248 Effect on CDN Interfaces: 1250 o URL Signing is enabled on the CDNI Request Routing (i.e. 1251 Capabilities advertisement), Metadata, and Logging interfaces 1253 Advantages/Drawbacks: 1255 + Not necessary to validate every chunk URL 1257 + Less exposure to attacks on the URL Signing keys 1259 - Surrogate needs to maintain state for the authorization token 1261 3.5.4. Option 5.3: HAS-awareness with Session Based Encryption 1263 After validating the URL and detecting that the requested content is 1264 a Manifest File, the delivery CDN surrogate manipulates the Manifest 1265 File by adding a reference to the key server for protection of 1266 specific chunks before it delivers the content. Also, the surrogate 1267 sets a HTTP cookie for the HTTP session. When a request for a chunk 1268 arrives, the surrogate identifies that the HTTP cookie value is for 1269 the same session. If so, the chunk is encrypted with the symmetric 1270 key obtained from the key server and then is delivered to the user. 1272 Effect on CDN Interfaces: 1274 o URL Signing is enabled on the CDNI Request Routing (i.e. 1275 Capabilities advertisement), Metadata, and Logging interfaces 1277 Advantages/Drawbacks: 1279 + Not necessary to validate every chunk URL 1281 + Less exposure to attacks on the URL Signing keys 1283 + Confidentiality for the chunk 1285 - Surrogate needs to change the Manifest File 1287 - Surrogate needs to maintain state for the HTTP session 1289 - Key server is required to distribute key to surrogate and user 1291 - Encryption and decryption processing 1293 3.6. Content Purge 1295 At some point in time, a uCDN might want to remove content from a 1296 dCDN. With regular content, this process can be relatively 1297 straightforward; a uCDN will typically send the request for content 1298 removal to the dCDN including a reference to the content which it 1299 wants to remove (e.g. in the form of a URL). Due to the fact that 1300 HAS content consists of large groups of files however, things might 1301 be more complex. Section 3.1 describes a number of different 1302 scenarios for doing file management on these groups of files, while 1303 Section 3.2 list the options for performing Content Acquisition on 1304 these Content Collections. This section will present the options for 1305 requesting a Content Purge for the removal of a Content Collection 1306 from a dCDN. 1308 3.6.1. Option 6.1: No HAS awareness 1310 The most straightforward way to signal content purge requests is to 1311 just send a single purge request for every file that makes up the 1312 Content Collection. While this method is very simple and does not 1313 require HAS awareness, it obviously creates a large signalling 1314 overhead between the uCDN and dCDN. 1316 Effect on CDN Interfaces: 1318 o None 1320 Advantages/Drawbacks (apart from those listed under Option 3.3): 1322 + Does not require changes to the CDNI Interfaces or HAS awareness 1324 - Requires individual purge request for every file making up a 1325 Content Collection which creates large signalling overhead 1327 3.6.2. Option 6.2: Purge Identifiers 1329 There exists a potentially more efficient method for performing 1330 content removal of large numbers of files simultaneously. By 1331 including purge identifiers in the metadata of a particular file, it 1332 is possible to virtually group together different files making up a 1333 Content Collection. A purge identifier can take the form of a random 1334 number which is communicated as part of the CDNI Metadata Interface 1335 and which is the same for all files making up a particular Content 1336 Item. If a uCDN wants to request the dCDN to remove a Content 1337 Collection, it can send a purge request containing this purge 1338 identifier. The dCDN can then remove all files that contain the 1339 shared identifier. 1341 The advantage of this method is that it is relatively simple to use 1342 by both the dCDN and uCDN and requiring only limited additions to the 1343 CDNI Metadata Interface and CDNI Control Interface. 1345 [Editor's Note: Could the Purge Identifier introduced in this section 1346 be related to the Content Collection Identifier introduced in 1347 Section 3.4.2.2? Chould they be the same identifier?] 1349 Effect on CDN Interfaces: 1351 o CDNI Metadata Interface: Add metadata field for indicating Purge 1352 Identifier 1354 o CDNI Control Interface: Add functionality to be able to send 1355 content purge requests containing Purge Identifiers 1357 Advantages/Drawbacks: 1359 + Allows for efficient purging of content from a dCDN 1361 + Does not require HAS awareness on part of dCDN 1363 4. IANA Considerations 1365 This document makes no request of IANA. 1367 Note to RFC Editor: this section may be removed on publication as an 1368 RFC. 1370 5. Security Considerations 1372 TBD. 1374 6. References 1376 6.1. Normative References 1378 [I-D.ietf-cdni-problem-statement] 1379 Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1380 Distribution Network Interconnection (CDNI) Problem 1381 Statement, draft-ietf-cdni-problem-statement-03", 1382 January 2012. 1384 [I-D.ietf-cdni-use-cases] 1385 Bertrand, G., Ed., Stephan, E., Watson, G., Burbridge, T., 1386 Eardley, P., and K. Ma, "Use Cases for Content Delivery 1387 Network Interconnection, draft-ietf-cdni-use-cases-03", 1388 January 2012. 1390 6.2. Informative References 1392 [I-D.draft-bertrand-cdni-logging] 1393 Bertrand, G., Ed. and E. Stephan, "CDNI Logging 1394 Interface". 1396 [I-D.draft-lefaucheur-cdni-logging-delivery] 1397 Le Faucheur, F., Viveganandhan, M., and K. Leung, "CDNI 1398 Logging Formats for HTTP and HTTP Adaptive Streaming 1399 Deliveries". 1401 Authors' Addresses 1403 Ray van Brandenburg 1404 TNO 1405 Brassersplein 2 1406 Delft 2612CT 1407 the Netherlands 1409 Phone: +31-88-866-7000 1410 Email: ray.vanbrandenburg@tno.nl 1412 Oskar van Deventer 1413 TNO 1414 Brassersplein 2 1415 Delft 2612CT 1416 the Netherlands 1418 Phone: +31-88-866-7000 1419 Email: oskar.vandeventer@tno.nl 1421 Francois Le Faucheur 1422 Cisco Systems 1423 Greenside, 400 Avenue de Roumanille 1424 Sophia Antipolis 06410 1425 France 1427 Phone: +33 4 97 23 26 19 1428 Email: flefauch@cisco.com 1429 Kent Leung 1430 Cisco Systems 1431 170 West Tasman Drive 1432 San Jose, CA 95134 1433 USA 1435 Phone: +1 408-526-5030 1436 Email: kleung@cisco.com