CDNI R. van Brandenburg Internet-Draft O. van Deventer Intended status: Informational TNO Expires: August 27, 2012 February 24, 2012 Models for adaptive-streaming-aware CDN Interconnection draft-brandenburg-cdni-has-00 Abstract This documents presents thougths on the potential impact of supporting HTTP Adaptive Streaming technologies in CDN Interconnection scenarios. Our intent is to spur discussion on how the different CDNI interfaces should deal with content delivered using adaptive streaming technologies. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 27, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. van Brandenburg & van Deventer Expires August 27, 2012 [Page 1] Internet-Draft HTTP Adaptive streaming and CDNI February 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. HTTP Adaptive Streaming aspects relevant to CDNI . . . . . . . 4 2.1. Segmentation versus Fragmentation . . . . . . . . . . . . 4 2.2. Addressing chunks . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Full Locator . . . . . . . . . . . . . . . . . . . . . 6 2.2.2. Relative Locator . . . . . . . . . . . . . . . . . . . 7 2.2.3. Chunk Request Routing . . . . . . . . . . . . . . . . 7 3. Impact of HAS on CDNI . . . . . . . . . . . . . . . . . . . . 8 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. On the definition of a Content Item in CDNI . . . . . 8 3.1.2. General CDNI-HAS Requirements . . . . . . . . . . . . 10 3.2. Impact on Request Routing Interface . . . . . . . . . . . 10 3.2.1. Dealing with manifest files . . . . . . . . . . . . . 10 3.2.2. HAS Request Routing . . . . . . . . . . . . . . . . . 11 3.2.3. Dividing content over multiple nodes . . . . . . . . . 12 3.2.4. HAS Requirements for the CDNI Request Routing Interface . . . . . . . . . . . . . . . . . . . . . . 12 3.3. Impact on Metadata Interface . . . . . . . . . . . . . . . 12 3.3.1. HAS-specific Metadata . . . . . . . . . . . . . . . . 12 3.3.2. HAS Requirements for the CDNI Metadata Interface . . . 13 3.4. Impact on Logging Interface . . . . . . . . . . . . . . . 13 3.4.1. Log processing . . . . . . . . . . . . . . . . . . . . 13 3.4.2. HAS Requirements for the CDNI Logging Interface . . . 14 3.5. Impact on Control Interface . . . . . . . . . . . . . . . 14 3.5.1. HAS Requirements for the CDNI Control Interface . . . 14 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 6.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 van Brandenburg & van Deventer Expires August 27, 2012 [Page 2] Internet-Draft HTTP Adaptive streaming and CDNI February 2012 1. Introduction HTTP Adaptive Streaming (HAS) is an umbrella term for various HTTP- based streaming technologies that allow a client to adaptively switch between multiple bitrates depending on current network conditions. A defining aspect of HAS is that, since it is based on HTTP, it is a session-less pull-based mechanism, with a client actively requesting content segments, instead of the content being pushed to the client by a server. Due to this session-less nature, media servers delivering content using HAS often show different characteristics when compared with media servers delivering content using traditional streaming methods such as RTP/RTSP, RTMP and MMS. This document presents a discussion on what the impact of these different characteristics is to the CDNI interfaces. The scope of this document is explicitely not to define solutions, but merely to identify different methods of handling HAS in a CDN and the potential problems when using HAS in a CDNI context. The issues identified in this document may be used as input for defining HAS-specific requirements for the CDNI interfaces. 1.1. Terminology This document uses the terminology defined in [I-D.ietf-cdni-problem-statement]. In addition, the following terms are used throughout this document: Content Item: A uniquely adressable content element in a CDN. A content item is defined by the fact that it has its own Content Metadata associated with it. It is the object of a request routing operation in a CDN. An example of a Content Item is a video file/ stream, an audio file/stream or an image file. For a discussion on what may constitute a Content Item with regards to HAS, see section 3.1.1. Chunk: A fixed length element that is the result of a segmentation or fragmentation operation being performed on a single encoding of the Original Content. A chunk is independently, and uniquely, addressable. Depending on the way a Chunk is stored, it may also be referred to as a Segment or Fragment. Fragment: A specific form of chunk (see section 2.1). A fragment is stored as part of a larger file that includes all chunks that are part of the Chunk Collection. Segment: A specific form of chunk (see section 2.1). A segment is stored as a single file from a file system perspective. van Brandenburg & van Deventer Expires August 27, 2012 [Page 3] Internet-Draft HTTP Adaptive streaming and CDNI February 2012 Original Content: Unchunked content that is the basis for a segmentation of fragmentation operation. Based on Original Content, multiple alternative encodings, resolutions or bitrates may be derived, each of which may be fragmented or segmented. Chunk Collection: The set of all chunks that are the result of a single segmentation or fragmentation operation being performed on a single encoding of the Original Content. A Chunk Collection is described in a manifest file. Content Collection: The set of all Chunk Collections that are derived from the same Original Content. A Content Collection may consist of multiple Chunk Collections, each being a single encoding, or variant, of the Original Content. A Content Collection may be described by one or more manifest files. Manifest File: A manifest file, also referred to as Media Presentation Description (MPD) file, is a file that list the way the content has been chunked and where the various chunks are located (in the case of segments) or how they can be addressed (in the case of fragments). 2. HTTP Adaptive Streaming aspects relevant to CDNI In the last couple of years, a wide variety of HAS-like protocols have emerged. Among them are proprietary solutions such as Apple's HTTP Live Streaming (HLS), Microsoft's Smooth Streaming (MSS) and Adobe's HTTP Dynamic Streaming (HDS), and various standardized solutions such as 3GPP AHS (AHS) and MPEG DASH (DASH). While all of these technologies share a common set of features, each has its own defining elements. This chapter will look at some of the differences between these technologies and how these differences might be relevant to CDNI. In particular, section 2.1 will describe the various methods to store HAS content and section 2.2 will list three methods that are used to address HAS content in a CDN. 2.1. Segmentation versus Fragmentation All HAS implementations are based around a concept referred to as chunking: the concept of having a server split content up in numerous fixed length chunks, which are independently decodable. By sequentially requesting and receiving chunks, a client can recreate and play out the content. An advantage of this mechanism is that it allows a client to seamlessly switch between different encodings of the same Original Content. Before requesting a particular chunk, a client can choose between mulitple alternatives of the same chunk, irrespective of the encoding of the chuncks it has requested earlier. van Brandenburg & van Deventer Expires August 27, 2012 [Page 4] Internet-Draft HTTP Adaptive streaming and CDNI February 2012 NOTE: The set of all chunks belonging to a single encoding, and thus the result of a single chunking operation, will from now on be referred to as a Chunk Collection. The set of all encodings of the same Original Content will be referred to as a Content Collection. A Content Collection can therefore consist of multiple Chunk Collections. While every HAS implementation uses some form of chunking, not all implementations store the resulting chunks in the same way. In general, there are two distinct methods of performing chunking and storing the results: segmentation and fragmentation. - With segmentation, which is for example mandatory in all versions of HLS prior to version 7, the chunks, in this case also referred to as segments, are stored completely independent from each other, with each segment being stored as a seperate file from a file system perspective. This means that each segment has its own unique URL with which it can be retrieved. - With fragmentation (or virtual segmentation), which is for example used in Microsoft's Smooth Streaming, all chunks, or fragments, belonging to the same Chunk Collection are stored together, as part of a single file. While there are a number of container formats which allow for storing this type chunked content, Fragmented MP4 is most commonly used. With fragmentation, a specific chunk is adressable by subfixing the common file URL with an identifier uniquely identifying the chunk one is interested in, either by timestamp, by byterange, or in some other way. While one can argue about the merits of each of these two different methods of handling chunks, both have their advantages and drawbacks in a CDN environment. For example, fragmentation is often regarded as a method that introduces less overhead, both from a storage and processing perspective. Segmentation on the other hand, is regarded as being more flexible and efficient with regards to caching. In practice, current HAS implementations increasingly support both methods. 2.2. Addressing chunks In order for a client to request chunks, either in the form of segments or in the form of fragments, it needs to know how the content has been chunked and where to find the chunks. For this purpose, most HAS protocols use a concept that is often referred to as a manifest file (also known as Media Presentation Description, or MPD): a file that lists the way the content has been chunked and where the various chunks are located (in the case of segments) or how they can be addressed (in the case of fragments). A manifest file, van Brandenburg & van Deventer Expires August 27, 2012 [Page 5] Internet-Draft HTTP Adaptive streaming and CDNI February 2012 or set of manifest files, may also identify the different encodings, and thus Chunk Collections, the content is available in. In general, a HAS client will first request and receive a manifest file, and then, after parsing the information in the manifest file, proceed with sequentially requesting the chunks listed in the manifest file. Each HAS implementation has its own manifest file format and even within a particular format there are different methods available to specify the location of a chunk. Of course managing the location of files is a core aspect of every CDN, and each CDN will have its own method of doing so. Some CDNs may be purely cache-based, with no higher-level knowledge of where each file resides at each instant in time. Other CDNs may have dedicated management nodes which, at each instant in time, do know at which servers each file resides. The CDNI interfaces designed in the CDNI WG will probably need to be agnostic to these kinds of CDN- internal architecture decisions. In the case of HAS there is a strict relationship between the location of the content in the CDN (in this case chunks) and the content itself (the locations specified in the manifest file). It is therefore useful to have an understanding of the different methods in use in CDNs today for specifying chunk locations in manifest files. The different methods for doing so are described in sections 2.2.1 to 2.2.3. Although these sections are especially relevant for segmented content, due to its inherent distributed nature, the discussed methods are also applicable to fragmented content. Furthermore, it should be noted that the methods detailed below for specifying locations of content items in manifest files do not only relate to temporally segmented content (e.g. segments and fragments), but are also relevant in situations where content is made available in multiple qualities, encodings, or variants. In this case the content consists of multiple chunk collections, which may be described by either a single manifest file or multiple interrelated manifest files. In the latter case, there may be a high-level manifest file describing the various available bitrates, with URLs pointing to seperate manifest files describing the details of each specific bitrate. For specifying the locations of the other manifest files, the same methods apply that are used for specifying chunk locations. 2.2.1. Full Locator One method for specifying locations of chunks (or other manifest files) in a manifest file is through the use of a Full Locator. A Full Locator takes the form of an URL and is defined by the fact that it directly points to the specific chunk on the actual the server that is expected to deliver the requested chunk to the client. van Brandenburg & van Deventer Expires August 27, 2012 [Page 6] Internet-Draft HTTP Adaptive streaming and CDNI February 2012 An example of a Full Locator is the following: http://deliverynode.server.cdn.com/content_1/segments/ segment1_1.ts As can be seen from this example URL, the URL includes both the identifier of the requested segment (in this case segment1_1.ts), as well as the server that is expected to deliver the segment (in this case deliverynode.server.cdn.com). With this, the client has enough information to directly request the specific segment from the specified delivery node. 2.2.2. Relative Locator Another method for specifying chunk locations in a manifest file is through the use of Relative Locator. A Relative Locator is a pointer that is relative to the location where the manifest file has been acquired from. In most cases a Relative Locator will take the form of a string that has to be appended to the location of the manifest file to get the location of a specific chunk. This means that in the case a manifest with a Relative Locator is used, all chunks will be delivered by the same delivery node that delivered the manifest file. A Relative Locator will therefore not include a hostname. For example, in the case a manifest file has been requested (and received) from http://deliverynode.server.cdn.com/content_1/manifest.xml, a Relative Locator pointing to a specific segment referenced in the manifest might be: segments/segment1_1.ts Which means that the client should take the location of the manifest file and append the Relative Locator. In this case, the segment would then be requested from http://deliverynode.server.cdn.com/content_1/segments/segment1_1.ts 2.2.3. Chunk Request Routing A final method for specifying chunk locations in a manifest file is through the use of request routing. In this case, chunks are handled by the request routing system of a CDN just as if they were 'normal' content items. A chunk request comes in at a central request routing node and is handled just as if it were a regular content request, which might include looking up the delivery node best suited for delivering the requested chunk to the particular user and sending an HTTP redirect to the user with the URL pointing to the requested chunk on the specified delivery node. van Brandenburg & van Deventer Expires August 27, 2012 [Page 7] Internet-Draft HTTP Adaptive streaming and CDNI February 2012 An example of an URL pointing to a redirection mechanism might look as follows: http://requestrouting.cdn.com/ content_request?content=content_1&segment=segment1_1.ts As can be seen from this example URL, the URL includes a pointer to a general CDN request routing function and includes some arguments identifying the requested segment. 3. Impact of HAS on CDNI In the previous chapter, some of the unique properties of HAS have been discussed. Furthermore, some of the CDN-specific design decision with regards to addressing chunks have been detailed. In this chapter, the impact of supporting HAS in CDNI will be discussed. The scope of this chapter is explicitely not to define solutions, but merely to identify potential problems and issues that need to be agreed on. For this purpose, each subsection will pose a number of open questions that will need to be answered by the CDNI WG. At a later stage, the answers to these questions may be used to solicit HAS-related requirements for the CDNI Interfaces. The chapter is divided into three subsections. The first subsection, 3.1, will discuss the impact supporting HAS has on the general CDNI architecture, use cases and requirements. The other four subsections, 3.2 to 3.5, will discuss the impact of HAS on each of the four CDNI Interfaces. 3.1. General This section will discuss the impact supporting HTTP Adaptive Streaming has on the general CDNI architecture, use cases and requirements. 3.1.1. On the definition of a Content Item in CDNI [I-D.ietf-cdni-problem-statement] defines content as Content: Any form of digital data. One important form of content with additional constraints on distribution and delivery is continuous media (i.e. where there is a timing relationship between source and sink). This very broad definition of content is useful for generalizing the CDNI interfaces in a way that allows them to be agnostic to the type of content that is delivered. However, what a Content Item in a CDN van Brandenburg & van Deventer Expires August 27, 2012 [Page 8] Internet-Draft HTTP Adaptive streaming and CDNI February 2012 constitutes may become relevant in the context of HAS if one considers a Content Item to be the element with which Content Metadata is associated, and the element that is the object of a CDN(I) request routing operation. An example of a Content Item in the general sense is a video file or stream, such as a TV show or movie, or an audio file, such as an MP3. In a simple case, a single MP3 is a single Content Item. In a more complex case, a particular piece of content is made available in multiple resolutions, languages or qualities. A video item, for example, might be made available in three different resolutions. In these cases, it depends on the datamodel of a particular CDN (or a particular Content Provider) how it defines a Content Item. In some CDNs, all three video files might be seen as seperate Content Items, each with their own set of Content Metadata. In other CDNs, the three alternative encodings of the same content are seen as a single Content Item, with a single set of Content Metadata describing that the content consists of three different versions. The CDNI Interfaces defined in the CDNI WG are affected by these kinds differences in the ways different CDNs work and might need to be agnostic to these kinds of CDN-internal (or even Content Provider- related) decisions. For content delivered using HAS, there is an even wider variety in the way different CDNs might interpret the definition of a Content Item. For example, CDNs using the Relative Locator method (see section 2.2.2) in their manifest files, might define all chunks that are part of the same Content Collection, and therefore referenced in the same (set of) manifest file(s), as a single Content Item for the purposes of Content Metadata and request routing. Other CDNs might define all chunks related to a single encoding of a particular video item, and thus part of the same Chunk Collection, as a single Content Item, thereby having multiple inter-related Content Items which are part of the same 'parent' Content Item. Yet another group of CDNs, especially those using the Chunk Request Routing method (see Section 2.2.3), might define every individual chunk as a seperate Content Item, with a seperate set of metadata describing each chunk. In order for the CDNI WG to realise a standardized method of dealing with metadata, logging and request routing, it will be important to first have a common understanding of the term Content Item, and what it constitutes, especially with regard to HAS. One option would be to not impose a specific model, but allow the CDNI interfaces to support all the different definitions of Content Item (i.e. from considering each chunk to be a Content Item to considering all chunks originating from the same Original Content, and thus part of the same Content Collection, to be a single content item). van Brandenburg & van Deventer Expires August 27, 2012 [Page 9] Internet-Draft HTTP Adaptive streaming and CDNI February 2012 o Should the CDNI Interfaces be agnostic to the definition of a Content Item in a particular CDN? And if this is not the case, then o What constitutes a Content Item for the purposes of associating metadata and request routing? o How does the definition of a Content Item relate to Chunks, Chunk Collections and Content Collection? If the WG decides to not impose a specific definition of what constitutes a Content Item, it is for further study whether it is required for all parties involved in the delivery of a single video item, CSP, uCDN and dCDN, to use the same definition. For example, is it possible for the uCDN to define a complete Content Collection as a single Content Item, but for the dCDN which delivers the actual content to see each chunk as a seperate Content Item and handle the metadata accordingly? o Is it necessary for all CDNs involved in the delivery of a single video item to use the same definition of a Content Item (e.g. can the uCDN define a Content Collection as a Content Item and the dCDN define a chunk as a Content Item)? 3.1.2. General CDNI-HAS Requirements This section is a placeholder for HAS-specific CDNI requirements that are not related to a specific CDNI interface. 3.2. Impact on Request Routing Interface This section will discuss the impact supporting HTTP Adaptive Streaming has on the CDNI Request Routing Interface. 3.2.1. Dealing with manifest files In section 2.2, three different methods for identifying and addressing chunks from within a manifest file were described: Full Locators, Relative Locators and Chunk Request Routing. Of course not every current CDN will use and/or support all three methods. Some CDNs may only support one of the three methods, while others may support two or all three. The question is whether all CDNs involved in the delivery of a single video item need to support the same method. Is it for example possible for a dCDN to use Chunck Request Routing while the uCDN uses Full Locators? This question boils down to the more fundamental van Brandenburg & van Deventer Expires August 27, 2012 [Page 10] Internet-Draft HTTP Adaptive streaming and CDNI February 2012 question of who manages manifest file. Should a dCDN be allowed to change a manifest file? Or even create a new one? o Should the CDNI Interfaces be agnostic to the way chunks are identified in the manifest file and requested by the client? o Should it be possible for a uCDN and dCDN to use two different methods of addressing chunks in manifest files? And, related to this o Should a dCDN be able to adapt a manifest file (i.e. is a manifest file part of the content, and therefore by definition not adaptable, or is it part of the delivery method) ? If the CDNI WG decides that the anwer to these questions is negative, this will probably mean that the only supported method for Chunk Adressing is using Relative Locators. For both Full Locators as well as Chunk Request Routing, it is necessary for the delivering CDN to change the URLs specified in the manifest file. 3.2.2. HAS Request Routing One of the essential questions relating to HAS and request routing is whether CDNI request routing is handled on a per chunk level, a per Content Collection level, or somewhere in between. This question is tightly related to the definition of a Content Item, discussed in section 3.1.1. If a Content Item is the object of request routing, then it depends on the definition of a Content Item what type of content element is being request routed. o Should the CDNI Interfaces specify what element of a HAS stream is being request routed (i.e. should the CDNI interfaces support per- chunk request routing) ? While having a seperate request routing operation for every chunk will probably not be very efficient, only allowing for entire Content Collections to be request routed is very limiting. For example, it might be efficient for a dCDN targeted at mobile devices to only host (and thus be able to deliver) the lower resolution encodings of a given video item. In this case it probably wouldn't make sense to force the mobile CDN to host all resolutions (including the very high ones with multi-channel audio) that are hosted by the uCDN since there will be no clients accessing the high resolution content through the mobile CDN. van Brandenburg & van Deventer Expires August 27, 2012 [Page 11] Internet-Draft HTTP Adaptive streaming and CDNI February 2012 o Should it be possible for a dCDN to host (and deliver) only a subset of all the chunks, or chunk collections, of a given Content Collection? 3.2.3. Dividing content over multiple nodes An aspect that is related to the issues discussed in sections 3.2.1 and 3.2.2, is that of dividing content over multiple delivery nodes. In non-cache-based CDNs, where the location of content on delivery nodes is managed by a centralized process and where content is often pre-positioned, different Chunk Collections belonging to the same Content Collection, or even different chunks belonging to the same Chunk Collection, may be distributed over different delivery nodes. For example, the most popular resolutions of a particular Content Collection may be hosted on more delivery nodes than the less popular resolutions. In order to allow for this kind of internal CDN optimization it is necessary that the dCDN is able adapt the manifest file. o Should it be possible for a dCDN to distribute the chunks, or Chunk Collections, constituting a given Content Collection over its delivery nodes? 3.2.4. HAS Requirements for the CDNI Request Routing Interface This section is a placeholder for HAS-specific requirements for the CDNI Request Routing interface. 3.3. Impact on Metadata Interface This section will discuss the impact supporting HTTP Adaptive Streaming has on the CDNI Metadata Interface. 3.3.1. HAS-specific Metadata In section 3.1.1, the impact of HAS on the definition of a Content Item, and what constitutes a Content Item was discussed. More specifically, it was discussed how different CDNs might see chunks or chunk collections as Content Items or as parts of Content Items. This question also has an effect on the way the CDNI Metadata Interface. If one defines a Content Item as the CDN element with which Content Metadata is associated, this raises the question how Content Metadata is associated with HAS content. For example, is there specific metadata element associated with each chunk, with each chunk collection, with each content collection, or is there a specific form of metadata for HAS content? van Brandenburg & van Deventer Expires August 27, 2012 [Page 12] Internet-Draft HTTP Adaptive streaming and CDNI February 2012 o Is Content Metadata associated with Content Collections, Chunk Collections or chunks? o Is it necessary to extend the CDNI Metadata model with HAS- specific extensions? 3.3.2. HAS Requirements for the CDNI Metadata Interface This section is a placeholder for HAS-specific requirements for the CDNI Metadata interface. 3.4. Impact on Logging Interface This section will discuss the impact supporting HTTP Adaptive Streaming has on the CDNI Logging Interface. 3.4.1. Log processing One aspect of using HAS in a CDN context that has been getting a lot of attention is logging. In contrast to other streaming solutions which are either session-based (e.g. RTP) or using a single file (e.g. Progressive Download), the chunked nature of HAS means that regular logging methods that simply log each content request will generate extremely large log files with a seperate entry for each chunk being accessed. Apart from the large file size of these log files, a further problem is that due to the distributed nature of these log entries it can be difficult to trace them back to a specific number of clients or users, which makes reporting difficult. For this reason, some CDNs use dedicated log processing software which accumulates, processes and aggregates log files. This log processing software is a further element where different CDNs might have different approaches. For example, some CDNs might do the log processing at a low-level, such as real-time in the delivery nodes. Other CDNs might process the log files in batches at a centralized location, such as once every hour or every day. For the CDNI Logging interface, it will be necessary to realise a common understanding on what type of logging information is passed between the uCDn and the dCDN in the case a HAS-like protocol is used for delivery. Ideally, this interface is agnostic to the CDN- internal method of log processing. However, this might not be possible. For example, it can be argued that for transparency reasons, it is necessary for the dCDN to communicate the raw log files back to the uCDN. On the other hand, this creates a very large overhead in the inter-CDN communication, with log files for popular content possibly exceeding the file size of the content itself. Another method would be to require the dCDN to aggregate the log van Brandenburg & van Deventer Expires August 27, 2012 [Page 13] Internet-Draft HTTP Adaptive streaming and CDNI February 2012 files before reporting back to the uCDN, however this would require the dCDN to have specific log processing software. o Should the CDNI Logging Interface define a specific log-file format to be used for HAS content? 3.4.2. HAS Requirements for the CDNI Logging Interface This section is a placeholder for HAS-specific requirements for the CDNI Logging interface. 3.5. Impact on Control Interface This section will discuss the impact supporting HTTP Adaptive Streaming has on the CDNI Control Interface. NOTE: At this point the impact of HAS on the CDNI Control Interface has not yet been determined. 3.5.1. HAS Requirements for the CDNI Control Interface This section is a placeholder for HAS-specific requirements for the CDNI Control interface. 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations TBD. 6. References 6.1. Normative References [I-D.ietf-cdni-problem-statement] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement, draft-ietf-cdni-problem-statement-03", January 2012. van Brandenburg & van Deventer Expires August 27, 2012 [Page 14] Internet-Draft HTTP Adaptive streaming and CDNI February 2012 [I-D.ietf-cdni-use-cases] Bertrand, G., Ed., Stephan, E., Watson, G., Burbridge, T., Eardley, P., and K. Ma, "Use Cases for Content Delivery Network Interconnection, draft-ietf-cdni-use-cases-03", January 2012. 6.2. Informative References [Anchor] "". Authors' Addresses Ray van Brandenburg TNO Brassersplein 2 Delft 2612CT the Netherlands Phone: +31-88-866-7000 Email: ray.vanbrandenburg@tno.nl M. Oskar van Deventer TNO Brassersplein 2 Delft 2612CT the Netherlands Phone: +31-88-866-7000 Email: oskar.vandeventer@tno.nl van Brandenburg & van Deventer Expires August 27, 2012 [Page 15]