GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6983

Independent Submission R. van Brandenburg Request for Comments: 6983 O. van Deventer Category: Informational TNO ISSN: 2070-1721 F. Le Faucheur

                                                              K. Leung
                                                         Cisco Systems
                                                             July 2013
              Models for HTTP-Adaptive-Streaming-Aware
        Content Distribution Network Interconnection (CDNI)

Abstract

 This document presents thoughts on the potential impact of supporting
 HTTP Adaptive Streaming (HAS) technologies in Content Distribution
 Network Interconnection (CDNI) scenarios.  The intent is to present
 the authors' analysis of the CDNI-HAS problem space and discuss
 different options put forward by the authors (and by others during
 informal discussions) on how to deal with HAS in the context of CDNI.
 This document has been used as input information during the CDNI
 working group process for making a decision regarding support for
 HAS.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This is a contribution to the RFC Series, independently of any other
 RFC stream.  The RFC Editor has chosen to publish this document at
 its discretion and makes no statement about its value for
 implementation or deployment.  Documents approved for publication by
 the RFC Editor are not a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6983.

van Brandenburg, et al. Informational [Page 1] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

Copyright Notice

 Copyright (c) 2013 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.

Table of Contents

 1. Introduction ....................................................4
    1.1. Terminology ................................................5
 2. HTTP Adaptive Streaming Aspects Relevant to CDNI ................6
    2.1. Segmentation versus Fragmentation ..........................6
    2.2. Addressing Chunks ..........................................7
         2.2.1. Relative URLs .......................................8
         2.2.2. Absolute URLs with Redirection ......................9
         2.2.3. Absolute URLs without Redirection ..................10
    2.3. Live Content versus VoD Content ...........................11
    2.4. Stream Splicing ...........................................12
 3. Possible HAS Optimizations .....................................12
    3.1. File Management and Content Collections ...................13
         3.1.1. General Remarks ....................................13
         3.1.2. Candidate Approaches ...............................13
                3.1.2.1. Option 1.1: Do Nothing ....................13
                3.1.2.2. Option 1.2: Allow Single-File
                         Storage of Fragmented Content .............14
                3.1.2.3. Option 1.3: Access Correlation Hint .......14
         3.1.3. Recommendations ....................................15
    3.2. Content Acquisition of Content Collections ................15
         3.2.1. General Remarks ....................................15
         3.2.2. Candidate Approaches ...............................16
                3.2.2.1. Option 2.1: No HAS Awareness ..............16
                3.2.2.2. Option 2.2: Allow Single-File
                         Acquisition of Fragmented Content .........17
         3.2.3. Recommendations ....................................17

van Brandenburg, et al. Informational [Page 2] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

    3.3. Request Routing of HAS Content ............................17
         3.3.1. General Remarks ....................................17
         3.3.2. Candidate Approaches ...............................18
                3.3.2.1. Option 3.1: No HAS Awareness ..............18
                3.3.2.2. Option 3.2: Manifest File Rewriting
                         by uCDN ...................................20
                3.3.2.3. Option 3.3: Two-Step Manifest File
                         Rewriting .................................21
         3.3.3. Recommendations ....................................22
    3.4. Logging ...................................................23
         3.4.1. General Remarks ....................................23
         3.4.2. Candidate Approaches ...............................24
                3.4.2.1. Option 4.1: Do Nothing ....................24
                3.4.2.2. Option 4.2: CDNI Metadata Content
                         Collection ID .............................26
                3.4.2.3. Option 4.3: CDNI Logging Interface
                         Compression ...............................28
                3.4.2.4. Option 4.4: Full HAS
                         Awareness/Per-Session Logs ................29
         3.4.3. Recommendations ....................................30
    3.5. URL Signing ...............................................32
         3.5.1. HAS Implications ...................................32
         3.5.2. CDNI Considerations ................................33
         3.5.3. Option 5.1: Do Nothing .............................34
         3.5.4. Option 5.2: Flexible URL Signing by CSP ............34
         3.5.5. Option 5.3: Flexible URL Signing by uCDN ...........37
         3.5.6. Option 5.4: Authorization Group ID and HTTP
                Cookie .............................................37
         3.5.7. Option 5.5: HAS Awareness with HTTP Cookie in CDN ..38
         3.5.8. Option 5.6: HAS Awareness with Manifest
                File in CDN ........................................40
         3.5.9. Recommendations ....................................41
    3.6. Content Purge .............................................41
         3.6.1. Option 6.1: No HAS Awareness .......................42
         3.6.2. Option 6.2: Purge Identifiers ......................42
         3.6.3. Recommendations ....................................43
    3.7. Other Issues ..............................................43
 4. Security Considerations ........................................43
 5. Acknowledgements ...............................................44
 6. References .....................................................44
    6.1. Normative References ......................................44
    6.2. Informative References ....................................44

van Brandenburg, et al. Informational [Page 3] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

1. Introduction

 [RFC6707] defines the problem space for Content Distribution Network
 Interconnection (CDNI) and the associated CDNI interfaces.  This
 includes support, through interconnected Content Delivery Networks
 (CDNs), of content delivery to End Users using HTTP progressive
 download and HTTP Adaptive Streaming (HAS).
 HTTP Adaptive Streaming 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
 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 pull-based nature, media servers delivering
 content using HAS often show different characteristics when compared
 with media servers delivering content using traditional streaming
 methods such as the Real-time Transport Protocol / Real Time
 Streaming Protocol (RTP/RTSP), the Real Time Messaging Protocol
 (RTMP), and the Multimedia Messaging Service (MMS).
 This document presents a discussion of the impact of the HAS
 operation on the CDNI interfaces, and what HAS-specific optimizations
 may be required or may be desirable.  The scope of this document is
 to present the authors' analysis of the CDNI-HAS problem space and
 discuss different options put forward by the authors (and by others
 during informal discussions) on how to deal with HAS in the context
 of CDNI.  The document concludes by presenting the authors'
 recommendations on how the CDNI WG should deal with HAS in its
 initial charter, with a focus on 'making it work' instead of
 including 'nice-to-have' optimizations that might delay the
 development of the CDNI WG deliverables identified in its initial
 charter.
 It should be noted that the document is not a WG document but has
 been used as input during the WG process for making its decision
 regarding support for HAS.  We expect the analysis presented in the
 document to be useful in the future if and when the WG recharters and
 wants to reassess the level of HAS optimizations to be supported in
 CDNI scenarios.

van Brandenburg, et al. Informational [Page 4] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

1.1. Terminology

 This document uses the terminology defined in [RFC6707] and
 [CDNI-FRAMEWORK].
 For convenience, the definitions of HAS-related terms are restated
 here:
 Content Item:  A uniquely addressable content element in a CDN.  A
    content item is defined by the fact that it has its own Content
    Metadata associated with it.  An example of a content item is a
    video file/stream, an audio file/stream, or an image file.
 Chunk:  A fixed-length element that is the result of a segmentation
    or fragmentation operation and that is independently addressable.
 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.
 Original Content:  Non-chunked content that is the basis for a
    segmentation or fragmentation operation.  Based on Original
    Content, multiple alternative representations (using different
    encoding methods, supporting different resolutions, and/or
    targeting different 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 representation 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 corresponding to a
    single representation 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 a Media
    Presentation Description (MPD) file, is a file that lists the way
    the content has been chunked (possibly for multiple encodings), as
    well as where the various chunks are located (in the case of
    segments) or how they can be addressed (in the case of fragments).

van Brandenburg, et al. Informational [Page 5] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

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 HTTP Smooth Streaming (HSS),
 and Adobe's HTTP Dynamic Streaming (HDS), as well as various
 standardized solutions such as 3GPP Adaptive HTTP Streaming (AHS) and
 MPEG Dynamic Adaptive Streaming over HTTP (DASH).  While all of these
 technologies share a common set of features, each has its own
 defining elements.  This section looks at some of the common
 characteristics and some of the differences between these
 technologies and how those might be relevant to CDNI.  In particular,
 Section 2.1 describes the various methods to store HAS content, and
 Section 2.2 lists three methods that are used to address HAS content
 in a CDN.  After these generic HAS aspects are discussed, two special
 situations that need to be taken into account when discussing HAS are
 addressed: Section 2.3 discusses the differences between live content
 and Video on Demand (VoD) content, while Section 2.4 discusses the
 scenario where multiple streams are combined in a single Manifest
 File (e.g., for ad insertion purposes).

2.1. Segmentation versus Fragmentation

 All HAS implementations are based on a concept referred to as
 "chunking": the concept of having a server split content up in
 numerous fixed-duration chunks that 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 at chunk boundaries.  Before requesting a
 particular chunk, a client can choose between multiple alternative
 encodings of the same chunk, irrespective of the encoding of the
 chunks it has requested earlier.
 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.
  1. With segmentation – which is, for example, mandatory in all

versions of Apple's HLS prior to version 7 – the chunks, in this

    case also referred to as segments, are stored completely
    independently from each other, with each segment being stored as a
    separate file from a file-system perspective.  This means that
    each segment has its own unique URL with which it can be
    retrieved.

van Brandenburg, et al. Informational [Page 6] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

  1. With fragmentation (or virtual segmentation) – which is, for

example, used in Microsoft's HTTP 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 that allow for storing this type of chunked
    content, fragmented MP4 is most commonly used.  With
    fragmentation, a specific chunk is addressable by suffixing, to
    the common file URL, an identifier uniquely identifying the chunk
    that one is interested in, either by timestamp, by byte range, 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, from both a storage and
 processing perspective.  Segmentation, on the other hand, is regarded
 as being more flexible and easier to cache.  In practice, current HAS
 implementations increasingly support both methods.

2.2. Addressing Chunks

 In order for a client to request chunks, in the form of either
 segments or 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 a Media Presentation Description, or MPD), i.e., 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 or set of
 Manifest Files may also identify the different representations, and
 thus chunk collections, available for the content.
 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 that, at each instant in time, do know at
 which servers each file resides.  The CDNI interfaces designed by 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

van Brandenburg, et al. Informational [Page 7] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 (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 relate only to temporally
 segmented content (e.g., segments and fragments) but are also
 relevant in situations where content is made available in multiple
 representations (e.g., in different qualities, encoding methods,
 resolutions, and/or bitrates).  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 separate Manifest Files
 describing the details of each specific bitrate.  For specifying the
 locations of the other Manifest Files, the same methods that are used
 for specifying chunk locations also apply.
 One final note relates to the delivery of the Manifest Files
 themselves.  While in most situations the delivery of both the
 Manifest File and the chunks is handled by the CDN, there are
 scenarios imaginable in which the Manifest File is delivered by, for
 example, the Content Service Provider (CSP), and the Manifest File is
 therefore not visible to the CDN.

2.2.1. Relative URLs

 One method for specifying chunk locations in a Manifest File is
 through the use of relative URLs.  A relative URL is a URL that does
 not include the HOST part of a URL but only includes (part of) the
 PATH part of a URL.  In practice, a relative URL is used by the
 client as being relative to the location from which the Manifest File
 has been acquired.  In these cases, a relative URL 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 where a Manifest File with relative URLs is used, all chunks
 will be delivered by the same Surrogate that delivered the Manifest
 File.  A relative URL will therefore not include a hostname.

van Brandenburg, et al. Informational [Page 8] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 For example, in the case where a Manifest File has been requested
 (and received) from:
    http://surrogate.server.cdn.example.com/content_1/manifest.xml
 a relative URL pointing to a specific segment referenced in the
 Manifest File might be:
    segments/segment1_1.ts
 which means that the client should take the location of the Manifest
 File and append the relative URL.  In this case, the segment would
 then be requested from http://surrogate.server.cdn.example.com/
 content_1/segments/segment1_1.ts.
 One drawback of using relative URLs is that it forces a CDN relying
 on HTTP-based request routing to deliver all segments belonging to a
 given content item with the same Surrogate that delivered the
 Manifest File for that content item, which results in limited
 flexibility.  Another drawback is that relative URLs do not allow for
 fallback URLs; should the Surrogate that delivered the Manifest File
 break down, the client is no longer able to request chunks.  The
 advantage of relative URLs is that it is very easy to transfer
 content between different Surrogates and even CDNs.

2.2.2. Absolute URLs with Redirection

 Another method for specifying locations of chunks (or other Manifest
 Files) in a Manifest File is through the use of an absolute URL.  An
 absolute URL contains a fully formed URL (i.e., the client does not
 have to calculate the URL as in the case of the relative URL but can
 use the URL from the Manifest File directly).
 In the context of Manifest Files, there are two types of absolute
 URLs imaginable: absolute URLs with redirection and absolute URLs
 without redirection.  The two methods differ in whether the URL
 points to a request routing node that will redirect the client to a
 Surrogate (absolute URLs with redirection) or point directly to a
 Surrogate hosting the requested content (absolute URLs without
 redirection).
 In the case of absolute URLs with redirection, a request for a chunk
 is handled by the Request Routing system of a CDN just as if it were
 a standalone (non-HAS) content request, which might include looking
 up the Surrogate (and/or CDN) best suited for delivering the
 requested chunk to the particular user and sending an HTTP redirect

van Brandenburg, et al. Informational [Page 9] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 to the user with the URL pointing to the requested chunk on the
 specified Surrogate (and/or CDN), or a DNS response pointing to the
 specific Surrogate.
 An example of an absolute URL with redirection might look as follows:
    http://requestrouting.cdn.example.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 some arguments identifying
 the requested segment.
 The advantage of using absolute URLs with redirection is that they
 allow for maximum flexibility (since chunks can be distributed across
 Surrogates and CDNs in any imaginable way) without having to modify
 the Manifest File every time one or more chunks are moved (as is the
 case when absolute URLs without redirection are used).  The downside
 of this method is that it can add significant load to a CDN Request
 Routing system, since it has to perform a redirect every time a
 client requests a new chunk.

2.2.3. Absolute URLs without Redirection

 In the case of absolute URLs without redirection, the URL points
 directly to the specific chunk on the actual Surrogate that will
 deliver the requested chunk to the client.  In other words, there
 will be no HTTP redirection operation taking place between the client
 requesting the chunk and the chunk being delivered to the client by
 the Surrogate.
 An example of an absolute URL without redirection is the following:
    http://surrogate1.cdn.example.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) and
 the server that is expected to deliver the segment (in this case
 surrogate1.cdn.example.com).  With this, the client has enough
 information to directly request the specific segment from the
 specified Surrogate.
 The advantage of using absolute URLs without redirection is that it
 allows more flexibility compared to using relative URLs (since
 segments do not necessarily have to be delivered by the same server)
 while not requiring per-segment redirection (which would add
 significant load to the node doing the redirection).  The drawback of

van Brandenburg, et al. Informational [Page 10] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 this method is that it requires a modification of the Manifest File
 every time content is moved to a different location (either within a
 CDN or across CDNs).

2.3. Live Content versus VoD Content

 Though the formats and addresses of Manifest Files and chunk files do
 not typically differ significantly between live and Video-on-Demand
 (VoD) content, the time at which the Manifest Files and chunk files
 become available does differ significantly.  For live content, chunk
 files and their corresponding Manifest Files are created and
 delivered in real time.  This poses a number of potential issues for
 HAS optimization:
  1. With live content, chunk files are made available in real time.

This limits the applicability of bundling for content acquisition

    purposes.  Pre-positioning may still be employed; however, any
    significant latency in the pre-positioning may diminish the value
    of pre-positioning if a client requests the chunk prior to
    pre-positioning or if the pre-positioning request is serviced
    after the chunk playout time has passed.
  1. In the case of live content, Manifest Files must be updated for

each chunk and therefore must be retrieved by the client prior to

    each chunk request.  Any optimization schemes based on Manifest
    Files must therefore be prepared to optimize on a per-segment
    request basis.  Manifest Files may also be polled multiple times
    prior to the actual availability of the next chunk.
  1. Since live Manifest Files are updated as new chunks become

available, the cacheability of Manifest Files is limited. Though

    timestamping and reasonable Time-to-Live (TTL) settings can
    improve delivery performance, timely replication and delivery of
    updated Manifest Files are critical to ensuring uninterrupted
    playback.
  1. Manifest Files are typically updated after the corresponding chunk

is available for delivery, to prevent premature requests for

    chunks that are not yet available.  HAS optimization approaches
    that employ dynamic Manifest File generation must be synchronized
    with chunk creation to prevent playback errors.

van Brandenburg, et al. Informational [Page 11] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

2.4. Stream Splicing

 Stream splicing is used to create media mashups, combining content
 from multiple sources.  A common example in which content resides
 outside the CDNs is with advertisement insertion, for both VoD and
 live streams.  Manifest Files that contain absolute URLs with
 redirection may contain chunk or nested Manifest File URLs that point
 to content not delivered via any of the interconnected CDNs.
 Furthermore, client and downstream proxy devices may depend on
 non-URL information provided in the Manifest File (e.g., comments or
 custom tags) for performing stream splicing.  This often occurs
 outside the scope of the interconnected CDNs.  HAS optimization
 schemes that employ dynamic Manifest File generation or rewriting
 must be cognizant of chunk URLs, nested Manifest File URLs, and other
 metadata that should not be modified or removed.  Improper
 modification of these URLs or other metadata may cause playback
 interruptions and in the case of unplayed advertisements may result
 in loss of revenue for CSPs.

3. Possible HAS Optimizations

 In the previous section, some of the unique properties of HAS were
 discussed.  Furthermore, some of the CDN-specific design decisions
 with regards to addressing chunks have been detailed.  In this
 section, the impact of supporting HAS in CDNI scenarios is discussed.
 There are a number of topics, or problem areas, that are of
 particular interest when considering the combination of HAS and CDNI.
 For each of these problem areas, it holds that there are a number of
 different ways in which the CDNI interfaces can deal with them.  In
 general, it can be said that each problem area can either be solved
 in a way that minimizes the amount of HAS-specific changes to the
 CDNI interfaces or maximizes the flexibility and efficiency with
 which the CDNI interfaces can deliver HAS content.  The goal for the
 CDNI WG should probably be to try to find the middle ground between
 these two extremes and try to come up with solutions that optimize
 the balance between efficiency and additional complexity.
 In order to allow the WG to make this decision, this section briefly
 describes each of the following problem areas, together with a number
 of different options for dealing with them.  Section 3.1 discusses
 the problem of how to deal with file management of groups of files,
 or content collections.  Section 3.2 deals with a related topic: how
 to do content acquisition of content collections between the Upstream
 CDN (uCDN) and Downstream CDN (dCDN).  After that, Section 3.3
 describes the various options for the request routing of HAS content,
 particularly related to Manifest Files.  Section 3.4 talks about a

van Brandenburg, et al. Informational [Page 12] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 number of possible optimizations for the logging of HAS content,
 while Section 3.5 discusses the options regarding URL signing.
 Finally, Section 3.6 describes different scenarios for dealing with
 the removal of HAS content from CDNs.

3.1. File Management and Content Collections

3.1.1. General Remarks

 One of the unique properties of HAS content is that it does not
 consist of a single file or stream but of multiple interrelated files
 (segments, fragments, and/or Manifest Files).  In this document, this
 group of files is also referred to as a content collection.  Another
 important aspect is the difference between segments and fragments
 (see Section 2.1).
 Irrespective of whether segments or fragments are used, different
 CDNs might handle content collections differently from a file
 management perspective.  For example, some CDNs might handle all
 files belonging to a content collection as individual files that are
 stored independently from each other.  An advantage of this approach
 is that it makes it easy to cache individual chunks.  Other CDNs
 might store all fragments belonging to a content collection in a
 bundle, as if they were a single file (e.g., by using a fragmented
 MP4 container).  The advantage of this approach is that it reduces
 file management overhead.
 The following subsections look at the various ways with which the
 CDNI interfaces might deal with these differences in handling content
 collections from a file management perspective.  The different
 options can be distinguished based on the level of HAS awareness they
 require on the part of the different CDNs and the CDNI interfaces.

3.1.2. Candidate Approaches

3.1.2.1. Option 1.1: Do Nothing

 This option assumes no HAS awareness in both the involved CDNs and
 the CDNI interfaces.  This means that the uCDN uses individual files,
 and the dCDN is not explicitly made aware of the relationship between
 chunks and doesn't know which files are part of the same content
 collection.  In practice, this scenario would mean that the file
 management method used by the uCDN is simply imposed on the dCDN as
 well.
 This scenario also means that it is not possible for the dCDN to use
 any form of file bundling, such as the single-file mechanism, which
 can be used to store fragmented content as a single file (see

van Brandenburg, et al. Informational [Page 13] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 Section 2.1).  The one exception to this rule is the situation where
 the content is fragmented and the Manifest Files on the uCDN contain
 byte range requests, in which case the dCDN might be able to acquire
 fragmented content as a single file (see Section 3.2.2.2).
 Effect on CDNI interfaces:
 o  None
 Advantages/Drawbacks:
 +  No HAS awareness necessary in CDNs; no changes to CDNI interfaces
    necessary
  1. The dCDN is forced to store chunks as individual files

3.1.2.2. Option 1.2: Allow Single-File Storage of Fragmented Content

 In some cases, the dCDN might prefer to store fragmented content as a
 single file on its Surrogates to reduce file management overhead.  In
 order to do so, it needs to be able to either acquire the content as
 a single file (see Section 3.2.2.2) or to merge the different chunks
 together and place them in the same container (e.g., fragmented MP4).
 The downside of this method is that in order to do so, the dCDN needs
 to be fully HAS aware.
 Effect on CDNI interfaces:
 o  CDNI Metadata interface: Add fields for indicating the particular
    type of HAS (e.g., MPEG DASH or HLS) that is used and whether
    segments or fragments are used
 o  CDNI Metadata interface: Add field for indicating the name and
    type of the Manifest File(s)
 Advantages/Drawbacks:
 +  Allows the dCDN to store fragmented content as a single file,
    reducing file management overhead
  1. Complex operation, requiring the dCDN to be fully HAS aware

3.1.2.3. Option 1.3: Access Correlation Hint

 An intermediary approach between the two extremes detailed in the
 previous two sections is one that uses an 'Access Correlation Hint'.
 This hint, which is added to the CDNI Metadata of all chunks of a
 particular content collection, indicates that those files are likely

van Brandenburg, et al. Informational [Page 14] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 to be requested in a short time window from each other.  This
 information can help a dCDN to implement local file storage
 optimizations for VoD items (e.g., by bundling all files with the
 same Access Correlation Hint value in a single bundle/file), thereby
 reducing the number of files it has to manage while not requiring any
 HAS awareness.
 Effect on CDNI interfaces:
 o  CDNI Metadata interface: Add field for indicating Access
    Correlation Hint
 Advantages/Drawbacks:
 +  Allows the dCDN to perform file management optimization
 +  Does not require any HAS awareness
 +  Very small impact on CDNI interfaces
  1. Expected benefit compared with Option 1.1 is small

3.1.3. Recommendations

 Based on the listed pros and cons, the authors recommend that the WG
 go for Option 1.1 (do nothing).  The likely benefits of going for
 Option 1.3 are not believed to be significant enough to warrant
 changing the CDNI Metadata interface.  Although Option 1.2 would
 bring definite benefits for HAS-aware dCDNs, going for this option
 would require significant CDNI extensions that would impact the WG's
 milestones.  The authors therefore don't recommend including it in
 the current work but mark it as a possible candidate for rechartering
 once the initial CDNI solution is completed.

3.2. Content Acquisition of Content Collections

3.2.1. General Remarks

 In the previous section, the relationship between file management and
 HAS in a CDNI scenario was discussed.  This section discusses a
 related topic: content acquisition between two CDNs.
 With regards to content acquisition, it is important to note the
 difference between CDNs that do dynamic acquisition of content and
 CDNs that perform content pre-positioning.  In the case of dynamic
 acquisition, a CDN only requests a particular content item when a
 cache miss occurs.  In the case of pre-positioning, a CDN proactively
 places content items on the nodes on which it expects traffic for

van Brandenburg, et al. Informational [Page 15] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 that particular content item.  For each of these types of CDNs, there
 might be a benefit in being HAS aware.  For example, in the case of
 dynamic acquisition, being HAS aware means that after a cache miss
 for a given chunk occurs, that node might not only acquire the
 requested chunk but might also acquire some related chunks that are
 expected to be requested in the near future.  In the case of
 pre-positioning, similar benefits can be had.

3.2.2. Candidate Approaches

3.2.2.1. Option 2.1: No HAS Awareness

 This option assumes no HAS awareness in both the involved CDNs and
 the CDNI interfaces.  Just as with Option 1.1, discussed earlier with
 regards to file management, having no HAS awareness means that the
 dCDN is not aware of the relationship between chunks.  In the case of
 content acquisition, this means that each and every file belonging to
 a content collection will have to be individually acquired from the
 uCDN by the dCDN.  The exception to the rule is cases with fragmented
 content where the uCDN uses Manifest Files that contain byte range
 requests.  In this case, the dCDN can simply omit the byte range
 identifier and acquire the complete file.
 The advantage of this approach is that it is highly flexible.  If a
 client only requests a small portion of the chunks belonging to a
 particular content collection, the dCDN only has to acquire those
 chunks from the uCDN, saving both bandwidth and storage capacity.
 The downside of acquiring content on a per-chunk basis is that it
 creates more transaction overhead between the dCDN and uCDN, compared
 to a method in which entire content collections can be acquired as
 part of one transaction.
 Effect on CDNI interfaces:
 o  None
 Advantages/Drawbacks:
 +  Per-chunk content acquisition allows for a high level of
    flexibility between the dCDN and uCDN
  1. Per-chunk content acquisition creates more transaction overhead

between the dCDN and uCDN

van Brandenburg, et al. Informational [Page 16] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

3.2.2.2. Option 2.2: Allow Single-File Acquisition of Fragmented

        Content
 As discussed in Section 3.2.2.1, there is one (fairly rare) case
 where fragmented content can be acquired as a single file without any
 HAS awareness, and that is when fragmented content is used and where
 the Manifest File specifies byte range requests.  This section
 discusses how to perform single-file acquisition in the other (very
 common) cases.  To do so, the dCDN would have to have full HAS
 awareness (at least to the extent of being able to map between a
 single file and individual chunks to serve).
 Effect on CDNI interfaces:
 o  CDNI Metadata interface: Add fields for indicating the particular
    type of HAS (e.g., MPEG DASH or HLS) that is used and whether
    segments or fragments are used
 o  CDNI Metadata interface: Add field for indicating the name and
    type of the Manifest File(s)
 Advantages/Drawbacks:
 +  Allows for more efficient content acquisition in all HAS-specific
    supported forms
  1. Requires full HAS awareness on the part of the dCDN
  1. Requires significant CDNI Metadata interface extensions

3.2.3. Recommendations

 Based on the listed pros and cons, the authors recommend that the WG
 go for Option 2.1, since it is sufficient to 'make HAS work'.  While
 Option 2.2 would bring benefits to the acquisition of large content
 collections, it would require significant CDNI extensions that would
 impact the WG's milestones.  Option 2.2 might be a candidate to
 include in possible rechartering once the initial CDNI solution is
 completed.

3.3. Request Routing of HAS Content

3.3.1. General Remarks

 In this section, the effect HAS content has on request routing is
 identified.  Of particular interest in this case are the different
 types of Manifest Files that might be used.  In Section 2.2, three
 different methods for identifying and addressing chunks from within a

van Brandenburg, et al. Informational [Page 17] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 Manifest File were described: relative URLs, absolute URLs with
 redirection, and absolute URLs without redirection.  Of course, not
 every current CDN will use and/or support all three methods.  Some
 CDNs may only use one of the three methods, while others may support
 two or all three.
 An important factor in deciding which chunk-addressing method is used
 is the CSP.  Some CSPs may have a strong preference for a particular
 method and deliver the Manifest Files to the CDN in a particular way.
 Depending on the CDN and the agreement it has with the CSP, a CDN may
 either host the Manifest Files as they were created by the CSP or
 modify the Manifest File to adapt it to its particular architecture
 (e.g., by changing relative URLs to absolute URLs that point to the
 CDN Request Routing function).

3.3.2. Candidate Approaches

3.3.2.1. Option 3.1: No HAS Awareness

 This option assumes no HAS awareness in both the involved CDNs and
 the CDNI interfaces.  This scenario also assumes that neither the
 dCDN nor the uCDN has the ability to actively manipulate Manifest
 Files.  As was also discussed with regards to file management and
 content acquisition, having no HAS awareness means that each file
 constituting a content collection is handled on an individual basis,
 with the dCDN unaware of any relationship between files.
 The only chunk-addressing method that works without question in this
 case is absolute URLs with redirection.  In other words, the CSP that
 ingested the content into the uCDN created a Manifest File with each
 chunk location pointing to the Request Routing function of the uCDN.
 Alternatively, the CSP may have ingested the Manifest File containing
 relative URLs, and the uCDN ingestion function has translated these
 to absolute URLs pointing to the Request Routing function.
 In this "absolute URL with redirection" case, the uCDN can simply
 have the Manifest File be delivered by the dCDN as if it were a
 regular file.  Once the client parses the Manifest File, it will
 request any subsequent chunks from the uCDN Request Routing function.
 That function can then decide to outsource the delivery of those
 chunks to the dCDN.  Depending on whether HTTP-based (recursive or
 iterative) or DNS-based request routing is used, the uCDN Request
 Routing function will then either directly or indirectly redirect the
 client to the Request Routing function of the dCDN (assuming that it
 does not have the necessary information to redirect the client
 directly to a Surrogate in the dCDN).

van Brandenburg, et al. Informational [Page 18] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 The drawback of this method is that it creates a large amount of
 request routing overhead for both the uCDN and dCDN.  For each chunk,
 the full inter-CDN Request Routing process is invoked (which can
 result in two HTTP redirections in the case of iterative redirection,
 or one HTTP redirection plus one CDNI Request Routing Redirection
 interface request/response).  Even in the case where DNS-based
 redirection is used, there might be significant overhead involved,
 since both the dCDN and uCDN Request Routing functions might have to
 perform database lookups and query each other.  While with DNS this
 overhead might be reduced by using DNS's inherent caching mechanism,
 this will have significant impact on the accuracy of the redirect.
 With no HAS awareness, relative URLs might or might not work,
 depending on the type of relative URL that is used.  When a uCDN
 delegates the delivery of a Manifest File containing relative URLs to
 a dCDN, the client goes directly to the dCDN Surrogate from which it
 has received the Manifest File for every subsequent chunk.  As long
 as the relative URL is not path-absolute (see [RFC3986]), this
 approach will work fine.
 Since using absolute URLs without redirection inherently requires a
 HAS-aware CDN, absolute URLs without redirection cannot be used in
 this case because the URLs in the Manifest File will point directly
 to a Surrogate in the uCDN.  Since this scenario assumes no HAS
 awareness on the part of the dCDN or uCDN, it is impossible for
 either of these CDNs to rewrite the Manifest File and thus allow the
 client to either go to a Surrogate in the dCDN or to a Request
 Routing function.
 Effect on CDNI interfaces:
 o  None
 Advantages/Drawbacks:
 +  Supports absolute URLs with redirection
 +  Supports relative URLs
 +  Does not require HAS awareness and/or changes to the CDNI
    interfaces
  1. Not possible to use absolute URLs without redirection
  1. Creates significant signaling overhead in cases where absolute

URLs with redirection are used (inter-CDN request redirection for

    each chunk)

van Brandenburg, et al. Informational [Page 19] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

3.3.2.2. Option 3.2: Manifest File Rewriting by uCDN

 While Option 3.1 does allow absolute URLs with redirection to be
 used, it does so in a way that creates a high level of request
 routing overhead for both the dCDN and the uCDN.  This option
 presents a solution to significantly reduce this overhead.
 In this scenario, the uCDN is able to rewrite the Manifest File (or
 generate a new one) to be able to remove itself from the request
 routing chain for chunks being referenced in the Manifest File.  As
 described in Section 3.3.2.1, in the case of no HAS awareness, the
 client will go to the uCDN Request Routing function for each chunk
 request.  This Request Routing function can then redirect the client
 to the dCDN Request Routing function.  By rewriting the Manifest File
 (or generating a new one), the uCDN is able to remove this first step
 and have the Manifest File point directly to the dCDN Request Routing
 function.
 A key advantage of this solution is that it does not directly have an
 impact on the CDNI interfaces and is therefore transparent to these
 interfaces.  It is a CDN-internal function that a uCDN can perform
 autonomously by using information configured for regular CDNI
 operation or received from the dCDN as part of the regular
 communication using the CDNI Request Routing Redirection interface.
 More specifically, in order for the uCDN to rewrite the Manifest
 File, the minimum information needed is the location of the dCDN
 Request Routing function (or, alternatively, the location of the dCDN
 delivering Surrogate).  This information can be available from
 configuration or can be derived from the regular CDNI Request Routing
 Redirection interface.  For example, the uCDN may ask the dCDN for
 the location of its request routing node (through the CDNI Request
 Routing Redirection interface) every time a request for a Manifest
 File is received and processed by the uCDN Request Routing function.
 The uCDN would then modify the Manifest File and deliver the Manifest
 File to the client.  One advantage of this method is that it
 maximizes efficiency and flexibility by allowing the dCDN to
 optionally respond with the locations of its Surrogates instead of
 the location of its Request Routing function (and effectively turning
 the URLs into absolute URLs without redirection).  There are many
 variations on this approach, such as where the modification of the
 Manifest File is only performed once (or once per period of time) by
 the uCDN Request Routing function, when the first client for that
 particular content collection (and redirected to that particular
 dCDN) sends a Manifest File request.  The advantage of such a
 variation is that the uCDN only has to modify the Manifest File once

van Brandenburg, et al. Informational [Page 20] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 (or once per time period).  The drawback of this variation is that
 the dCDN is no longer in a position to influence the request routing
 decision across individual content requests.
 It should be noted that there are a number of things to take into
 account when changing a Manifest File (see, for example, Sections 2.3
 and 2.4 on live HAS content and ad insertion).  Furthermore, some
 CSPs might have issues with a CDN changing Manifest Files.  However,
 in this option the Manifest File manipulation is only being performed
 by the uCDN, which can be expected to be aware of these limitations
 if it wants to perform Manifest File manipulation, since it is in its
 own best interest that its customer's content gets delivered in the
 proper way and since there is a direct commercial and technical
 relationship between the uCDN (the Authoritative CDN in this
 scenario) and its customer (the CSP).  Should the CSP want to limit
 Manifest File manipulation, it can simply arrange this with the uCDN
 bilaterally.
 Effect on CDNI interfaces:
 o  None
 Advantages/Drawbacks:
 +  Possible to significantly decrease signaling overhead when using
    absolute URLs
 +  (Optional) Possible to have the uCDN rewrite the Manifest File
    with locations of Surrogates in the dCDN (turning absolute URLs
    with redirection into absolute URLs without redirection)
 +  No changes to CDNI interfaces
 +  Does not require HAS awareness in the dCDN
  1. Requires a high level of HAS awareness in the uCDN (for modifying

Manifest Files)

3.3.2.3. Option 3.3: Two-Step Manifest File Rewriting

 One of the possibilities with Option 3.2 is allowing the dCDN to
 provide the locations of a specific Surrogate to the uCDN, so that
 the uCDN can fit the Manifest File with absolute URLs without
 redirection and the client can request chunks directly from a dCDN
 Surrogate.  However, some dCDNs might not be willing to provide this
 information to the uCDN.  In that case, they can only provide the
 uCDN with the location of their Request Routing function, thereby
 preventing the use of absolute URLs without redirection.

van Brandenburg, et al. Informational [Page 21] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 One method for solving this limitation is allowing two-step Manifest
 File manipulation.  In the first step, the uCDN would perform its own
 modification and place the locations of the dCDN Request Routing
 function in the Manifest File.  Then, once a request for the Manifest
 File comes in at the dCDN Request Routing function, it would perform
 a second modification in which it replaces the URLs in the Manifest
 Files with the URLs of its Surrogates.  This way, the dCDN can still
 profit from having limited request routing traffic while not having
 to share sensitive Surrogate information with the uCDN.
 The downside of this approach is that it not only assumes HAS
 awareness in the dCDN but also requires some HAS-specific additions
 to the CDNI Metadata interface.  In order for the dCDN to be able to
 change the Manifest File, it has to have some information about the
 structure of the content.  Specifically, it needs to have information
 about which chunks make up the content collection.
 Effect on CDNI interfaces (apart from those already listed under
 Option 3.2):
 o  CDNI Metadata interface: Add necessary fields for conveying HAS-
    specific information (e.g., the files that make up the content
    collection) to the dCDN
 o  CDNI Metadata interface: Allow dCDN to modify Manifest File
 Advantages/Drawbacks (apart from those already listed under
 Option 3.2):
 +  Allows the dCDN to use absolute URLs without redirection, without
    having to convey sensitive information to the uCDN
  1. Requires a high level of HAS awareness in the dCDN (for modifying

Manifest Files)

  1. Requires adding HAS-specific and Manifest File manipulation-

specific information to the CDNI Metadata interface

3.3.3. Recommendations

 Based on the listed pros and cons, the authors recommend going for
 Option 3.1, with Option 3.2 as an optional feature that may be
 supported as a CDN-internal behavior by a uCDN.  While Option 3.1
 allows for HAS content to be delivered using the CDNI interfaces, it
 does so with some limitations regarding supported Manifest Files and,
 in some cases, with a large amount of signaling overhead.  Option 3.2
 can solve most of these limitations and presents a significant
 reduction in request routing overhead.  Since Option 3.2 does not

van Brandenburg, et al. Informational [Page 22] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 require any changes to the CDNI interfaces but only changes the way
 the uCDN uses the existing interfaces, supporting it is not expected
 to result in a significant delay of the WG's milestones.  The authors
 recommend that the WG not include Option 3.3, since it raises some
 questions of potential brittleness and including it would result in a
 significant delay of the WG's milestones.

3.4. Logging

3.4.1. General Remarks

 As stated in [RFC6707], the CDNI Logging interface enables details of
 logs or events to be exchanged between interconnected CDNs.
 As discussed in [CDNI-LOGGING], the CDNI logging information can be
 used for multiple purposes, including maintenance/debugging by a
 uCDN, accounting (e.g., for billing or settlement purposes),
 reporting and management of end-user experience (e.g., to the CSP),
 analytics (e.g., by the CSP), and control of content distribution
 policy enforcement (e.g., by the CSP).
 The key consideration for HAS with respect to logging is the
 potential increase of the number of log records by two to three
 orders of magnitude, as compared to regular HTTP delivery of a video,
 since by default log records would typically be generated on a
 per-chunk-delivery basis instead of a per-content-item-delivery
 basis.  This impacts the scale of every processing step in the
 logging process (see [CDNI-LOGGING]), including:
 a.  Logging information generation and storing on CDN elements
     (Surrogate, Request Routers, ...)
 b.  Logging information aggregation within a CDN
 c.  Logging information manipulation (including information
     protection, filtering, update, and rectification)
 d.  (Where needed) CDNI reformatting of logging information (e.g.,
     reformatting from a CDN-specific format to the CDNI Logging
     interface format for export by the dCDN to the uCDN)
 e.  Logging exchange via the CDNI Logging interface

van Brandenburg, et al. Informational [Page 23] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 f.  (Where needed) Logging re-reformatting (e.g., reformatting from
     the CDNI Logging interface format into a log-consuming
     application)
 g.  Logging consumption/processing (e.g., feed logs into uCDN
     accounting application, feed logs into uCDN reporting system to
     provide per-CSP views, feed logs into debugging tools)
 Note that there may be multiple instances of steps [f] and [g]
 running in parallel.
 While the CDNI Logging interface is only used to perform step [e], we
 note that its format directly affects steps [d] and [f] and that its
 format also indirectly affects the other steps (for example, if the
 CDNI Logging interface requires per-chunk log records, steps [a],
 [b], and [d] cannot operate on a per-HAS-session basis, and they also
 need to operate on a per-chunk basis).
 This section discusses the main candidate approaches identified for
 CDNI in terms of dealing with HAS with respect to logging.

3.4.2. Candidate Approaches

3.4.2.1. Option 4.1: Do Nothing

 In this approach, nothing is done specifically for HAS, so each
 HAS-chunk delivery is considered, for CDNI logging, as a standalone
 content delivery.  In particular, a separate log record for each
 HAS-chunk delivery is included in the CDNI Logging interface in
 step [e] (as defined in Section 3.4.1).  This approach requires that
 steps [a], [b], [c], [d], and [f] also be performed on a per-chunk
 basis.  This approach allows step [g] to be performed either on a
 per-chunk basis (assuming that step [f] maintains per-chunk records)
 or in a more "summarized" manner, such as on a per-HAS-session basis
 (assuming that step [f] summarizes per-chunk records into per-HAS-
 session records).
 Effect on CDNI interfaces:
 o  None
 Advantages/Drawbacks:
 +  No information loss (i.e., all details of each individual chunk
    delivery are preserved).  While this full level of detail may not
    be needed for some log-consuming applications (e.g., billing),
    this full level of detail is likely valuable (and possibly
    required) for some log-consuming applications (e.g., debugging)

van Brandenburg, et al. Informational [Page 24] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 +  Easier integration (at least in the short term) into existing
    logging tools, since those tools are all capable of handling
    per-chunk records
 +  No extension needed on CDNI interfaces
  1. High volume of logging information to be handled (storing and

processing) at every step of the logging process, from steps [a]

    to [g] (while summarization in step [f] is conceivable, it may be
    difficult to achieve in practice without any hints for correlation
    in the log records)
 An interesting question is whether a dCDN could use the CDNI Logging
 interface specified for the "do nothing" approach to report
 summarized "per-session" log information in the case where the dCDN
 performs such summarization.  The high-level idea would be that when
 a dCDN performs HAS log summarization, for its own purposes anyway,
 this dCDN could include in the CDNI Logging interface one or more log
 entries for a HAS session (instead of one entry per HAS chunk) that
 summarize the deliveries of many/all HAS chunks for a session.
 However, the authors feel that when considering the details of this
 idea, it is not achievable without explicit agreement between the
 uCDN and dCDN about how to perform/interpret such summarization.  For
 example, when a HAS session switches between representations, the
 uCDN and dCDN would have to agree on things such as:
 o  whether the session will be represented by a single log entry
    (which therefore cannot convey the distribution across
    representations), or multiple log entries, such as one entry per
    contiguous period at a given representation (which therefore would
    be generally very difficult to correlate back into a single
    session)
 o  what the single URI included in the log entry would correspond to
    (for example, the Manifest File, top-level playlist, or next-level
    playlist, ...)
 The authors feel that since explicit agreement is needed between the
 uCDN and dCDN on how to perform/interpret the summarization, this
 method can only work if it is specified as part of the CDNI Logging
 interface, in which case it would effectively boil down to Option 4.4
 (full HAS awareness / per-session logs) as defined below.

van Brandenburg, et al. Informational [Page 25] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 We note that support by CDNI of a mechanism (independent of HAS)
 allowing the customization of the fields to be reported in log
 entries by the dCDN to the uCDN would mitigate concerns related to
 the scaling of HAS logging, because it ensures that only the
 necessary subset of fields is actually stored, reported, and
 processed.

3.4.2.2. Option 4.2: CDNI Metadata Content Collection ID

 In this approach, a "Content Collection IDentifier (CCID)" field is
 distributed through the CDNI Metadata interface, and the same CCID
 value is associated through the CDNI Metadata interface with every
 chunk of the same content collection.  The CCID value needs to be
 such that it allows, in combination with the content URI, unique
 identification of a content collection.  When the CCID is
 distributed, and CCID logging is requested from the dCDN, the dCDN
 Surrogates are to store the CCID value in the corresponding log
 entries.  The objective of this field is to facilitate optional
 summarization of per-chunk records at step [f] into something along
 the lines of per-HAS-session logs, at least for the log-consuming
 applications that do not require per-chunk detailed information (for
 example, billing).
 We note that if the dCDN happens to have sufficient HAS awareness to
 be able to generate a "Session IDentifier (Session-ID)", optionally
 including such a Session-ID (in addition to the CCID) in the
 per-chunk log record would further facilitate optional summarization
 at step [f].  The Session-ID value to be included in a log record by
 the delivering CDN is such that
 o  different per-chunk log records with the same Session-ID value
    must correspond to the same user session (i.e., delivery of the
    same content to the same End User at a given point in time).
 o  log records for different chunks of the same user session (i.e.,
    delivery of the same content to the same End User at a given point
    in time) should be provided with the same Session-ID value.  While
    undesirable, there may be situations where the delivering CDN uses
    more than one Session-ID value for different per-chunk log records
    of a given session -- for example, in scenarios of fail-over or
    load balancing across multiple Surrogates and where the delivering
    CDN does not implement mechanisms to synchronize Session-IDs
    across Surrogates.

van Brandenburg, et al. Informational [Page 26] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 Effect on CDNI interfaces:
 o  CDNI Metadata interface: One additional metadata field (CCID) in
    the CDNI Metadata interface.  We note that a similar content
    collection ID is discussed for the handling of other aspects of
    HAS and observe that further thought is needed to determine
    whether such a CCID should be shared for multiple purposes or
    should be independent.
 o  CDNI Logging interface: Two additional fields (CCID and
    Session-ID) in CDNI logging records.
 Advantages/Drawbacks:
 +  No information loss (i.e., all details of each individual chunk
    delivery are preserved).  While this full level of detail may not
    be needed for some log-consuming applications (e.g., billing),
    this full level of detail is likely valuable (and possibly
    required) for some log-consuming applications (e.g., debugging)
 +  Easier integration (at least in the short term) into existing
    logging tools, since those tools are all capable of handling
    per-chunk records
 +  Very minor extension to CDNI interfaces needed
 +  Facilitated summarization of records related to a HAS session in
    step [f] and therefore ability to operate on a lower volume of
    logging information in step [g] by log-consuming applications that
    do not need per-chunk record details (e.g., billing) or that need
    per-session information (e.g., analytics)
  1. High volume of logging information to be handled (storing and

processing) at every step of the logging process, from steps [a]

    to [f]

van Brandenburg, et al. Informational [Page 27] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

3.4.2.3. Option 4.3: CDNI Logging Interface Compression

 In this approach, a lossless compression technique is applied to the
 sets of logging records (e.g., logging files) for transfer on the
 CDNI Logging interface.  The objective of this approach is to reduce
 the volume of information to be stored and transferred in step [e].
 Effect on CDNI interfaces:
 o  One compression mechanism to be included in the CDNI Logging
    interface
 Advantages/Drawbacks:
 +  No information loss (i.e., all details of each individual chunk
    delivery are preserved).  While this full level of detail may not
    be needed for some log-consuming applications (e.g., billing),
    this full level of detail is likely valuable (and possibly
    required) for some log-consuming applications (e.g., debugging)
 +  Easier integration (at least in the short term) into existing
    logging tools, since those tools are all capable of handling
    per-chunk records
 +  Small extension to CDNI interfaces needed
 +  Reduced volume of logging information in step [e]
 +  Compression likely to also be applicable to logs for non-HAS
    content
  1. High volume of logging information to be handled (storing and

processing) at every step of the logging process, from steps [a]

    to [g], except step [e].

van Brandenburg, et al. Informational [Page 28] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

3.4.2.4. Option 4.4: Full HAS Awareness/Per-Session Logs

 In this approach, HAS awareness is assumed across the CDNs
 interconnected via CDNI, and the necessary information to describe
 the HAS relationship across all chunks of the same content collection
 is distributed through the CDNI Metadata interface.  In this
 approach, the dCDN leverages the HAS information distributed through
 the CDNI Metadata and their HAS awareness, to do one of the
 following:
 o  directly generate summarized logging information at logging
    information generation time (which has the benefit of operating on
    a lower volume of logging information as early as possible in the
    successive steps of the logging process), or
 o  (if per-chunk logs are generated) accurately correlate and
    summarize per-chunk logs into per-session logs for exchange over
    the CDNI Logging interface
 Effect on CDNI interfaces:
 o  CDNI Metadata interface: Significant extension to convey HAS
    relationship across chunks of a content collection.  Note that
    this extension requires specific support for every HAS protocol to
    be supported over the CDNI mesh
 o  CDNI Logging interface: Extension to specify summarized per-
    session logs
 Advantages/Drawbacks:
 +  Lower volume of logging information to be handled (storing and
    processing) at every step of the logging process, from steps [a]
    to [g]
 +  Accurate generation of summarized logs because of HAS awareness in
    the dCDN (for example, where the Surrogate is also serving the
    Manifest File(s) for a content collection, the Surrogate may be
    able to extract definitive information about the relationship
    between all chunks)
  1. Very significant extensions to CDNI interfaces needed, including

specific support for available HAS protocols

  1. Very significant additional requirement for HAS awareness on the

dCDN and for this HAS awareness to be consistent with the defined

    CDNI logging summarization

van Brandenburg, et al. Informational [Page 29] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

  1. Some information loss (i.e., all details of each individual chunk

delivery are not preserved). The actual information loss depends

    on the summarization approach selected (typically, the lower the
    information loss, the lower the summarization gain), so the right
    "sweet spot" would have to be selected.  While a full level of
    detail may not be needed for some log-consuming applications
    (e.g., billing), such a full level of detail is likely valuable
    (and possibly required) for some log-consuming applications (e.g.,
    debugging)
  1. Less easy integration (at least in the short term) into existing

logging tools, since those tools are all capable of handling

    per-chunk records but may not be capable of handling CDNI
    summarized records
  1. Challenges in defining behavior (and achieving summarization gain)

in the presence of load balancing of a given HAS session across

    multiple Surrogates (in the same dCDN or a different dCDN)

3.4.3. Recommendations

 Because of its benefits (in particular simplicity, universal support
 by CDNs, and support by all log-consuming applications), the authors
 recommend that per-chunk logging as described in Section 3.4.2.1
 (Option 4.1) be supported by the CDNI Logging interface as a "High
 Priority" (as defined in [CDNI-REQUIREMENTS]) and be a mandatory
 capability of CDNs implementing CDNI.
 Because of its very low complexity and its benefits in facilitating
 some useful scenarios (e.g., per-session analytics), we recommend
 that the CCID mechanisms and Session-ID mechanism as described in
 Section 3.4.2.2 (Option 4.2) be supported by the CDNI Metadata
 interface and the CDNI Logging interface as a "Medium Priority" (as
 defined in [CDNI-REQUIREMENTS]) and be an optional capability of CDNs
 implementing CDNI.
 The authors also recommend that
 (i)   the ability of the uCDN to request inclusion of the CCID and
       Session-ID fields (in log entries provided by the dCDN) be
       supported by the relevant CDNI interfaces
 (ii)  the ability of the dCDN to include the CCID and Session-ID
       fields in CDNI log entries (when the dCDN is capable of doing
       so) be indicated in the CDNI Logging interface (in line with
       the "customizable" log format expected to be defined
       independently of HAS)

van Brandenburg, et al. Informational [Page 30] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 (iii) items (i) and (ii) be supported as a "Medium Priority" (as
       defined in [CDNI-REQUIREMENTS]) and be an optional capability
       of CDNs implementing CDNI
 When performing dCDN selection, a uCDN may want to take into account
 whether a given dCDN is capable of reporting the CCID and Session-ID.
 Thus, the authors recommend that the ability of a dCDN to advertise
 its support of the optional CCID and Session-ID capability be
 supported by the CDNI Footprint & Capabilities Advertisement
 interface as a "Medium Priority" (as defined in [CDNI-REQUIREMENTS]).
 The authors also recommend that a generic mechanism (independent of
 HAS) be supported that allows the customization of the fields to be
 reported in logs by CDNs over the CDNI Logging interface -- because
 of the reduction of the logging information volume exchanged across
 CDNs that it allows by removing information that is not of interest
 to the other CDN.
 Because the following can be achieved with very little complexity and
 can provide some clear storage/communication compression benefits,
 the authors recommend that, in line with the concept of Option 4.3,
 some existing very common compression techniques (e.g., gzip) be
 supported by the CDNI Logging interface as a "Medium Priority" (as
 defined in [CDNI-REQUIREMENTS]) and be an optional capability of CDNs
 implementing CDNI.
 Because of its complexity, the time it would take to understand the
 trade-offs of candidate summarization approaches, and the time it
 would take to specify the corresponding support in the CDNI Logging
 interface, the authors recommend that the log summarization discussed
 in Section 3.4.2.4 (Option 4.4) not be supported by the CDNI Logging
 interface at this stage but that it be kept as a candidate topic of
 great interest for a rechartering of the CDNI WG once the first set
 of deliverables is produced.  At that time, we suggest investigating
 the notion of complementing a "push style" CDNI Logging interface
 that would support summarization via an on-demand "pull type"
 interface that would in turn allow a uCDN to request the subset of
 the detailed logging information that it may need but that is lost in
 the summarized pushed information.
 The authors note that while a CDN only needs to adhere to the CDNI
 Logging interface on its external interfaces and can perform logging
 in a different format within the CDN, any possible CDNI logging
 approach effectively places some constraints on the dCDN logging
 format.  For example, to support the "do nothing" approach, a CDN
 needs to perform and retain per-chunk logs.  As another example, to
 support the "full HAS awareness/per-session logs" approach, the dCDN
 cannot use a logging format that summarizes data in a way that is

van Brandenburg, et al. Informational [Page 31] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 incompatible with the summarization specified for CDNI logging (e.g.,
 summarizes data into a smaller set of information than what is
 specified for CDNI logging).  However, the authors feel that such
 constraints are (i) inevitable, (ii) outweighed by the benefits of a
 standardized logging interface, and (iii) acceptable because, in the
 case of incompatible summarization, most or all CDNs are capable of
 reverting to per-chunk logging as per the "do nothing" approach that
 we recommend as the base mandatory approach.

3.5. URL Signing

 URL signing is an authorization method for content delivery.  This is
 based on embedding the HTTP URL with information that can be
 validated to ensure that the request has legitimate access to the
 content.  There are two parts: 1) parameters that convey
 authorization restrictions (e.g., source IP address and time period)
 and/or a protected URL portion, and 2) a message digest that confirms
 the integrity of the URL and authenticates the entity that creates
 the URL.  The authorization parameters can be anything agreed upon
 between the entity that creates the URL and the entity that validates
 the URL.  A key is used to generate the message digest (i.e., sign
 the URL) and validate the message digest.  The two functions may or
 may not use the same key.
 There are two types of keys used for URL signing: asymmetric keys and
 symmetric keys.  Asymmetric keys always have a key pair made up of a
 public key and private key.  The private key and public key are used
 for signing and validating the URL, respectively.  A symmetric key is
 the same key that is used for both functions.  Regardless of the type
 of key, the entity that validates the URL has to obtain the key.
 Distribution of the symmetric key requires security to prevent others
 from taking it.  A public key can be distributed freely, while a
 private key is kept by the URL signer.  The method for key
 distribution is out of scope for this document.
 URL signing operates in the following way.  A signed URL is provided
 by the content owner (i.e., URL signer) to the user during website
 navigation.  When the user selects the URL, the HTTP request is sent
 to the CDN, which validates that URL before delivering the content.

3.5.1. HAS Implications

 The authorization lifetime for URL signing is affected by HAS.  The
 expiration time in the authorization parameters of URL signing limits
 the period that the content referenced by the URL can be accessed.
 This works for URLs that directly access the media content, but for
 HAS content the Manifest File contains another layer of URLs that
 reference the chunks.  The chunk URL that is embedded in the content

van Brandenburg, et al. Informational [Page 32] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 may be requested some undetermined amount of time later.  The time
 period between access to the Manifest File and chunk retrieval may
 vary significantly.  The type of content (i.e., live or VoD) impacts
 this time variance as well.  This property of HAS content needs to be
 addressed for URL signing.

3.5.2. CDNI Considerations

 For CDNI, the two types of request routing are DNS-based and HTTP-
 based.  The use of symmetric vs. asymmetric keys for URL signing has
 implications for the trust model between the CSP and CDNs and for the
 key distribution method that can be used.
 DNS-based request routing does not change the URL.  In the case of a
 symmetric key, the CSP and the Authoritative CDN have a business
 relationship that allows them to share a key (or multiple keys) for
 URL signing.  When the user requests content from the Authoritative
 CDN, the URL is signed by the CSP.  The Authoritative CDN (as a uCDN)
 redirects the request to a dCDN via DNS.  There may be more than one
 level of redirection to reach the delivering CDN.  The user would
 obtain the IP address from DNS and send the HTTP request to the
 delivering CDN, which needs to validate the URL.  This requires that
 the key be distributed from the Authoritative CDN to the delivering
 CDN.  This may be problematic when the key is exposed to a delivering
 CDN that does not have a relationship with the CSP.  The combination
 of DNS-based request routing and symmetric key function is a generic
 issue for URL signing and not specific to HAS content.  In the case
 of asymmetric keys, the CSP signs the URL with its private key.  The
 delivering CDN validates the URL with the associated public key.
 HTTP-based request routing changes the URL during the redirection
 procedure.  In the case of a symmetric key, the CSP signs the
 original URL with the same key used by the Authoritative CDN to
 validate the URL.  The Authoritative CDN (as a uCDN) redirects the
 request to the dCDN.  The new URL is signed by the uCDN with the same
 key used by the dCDN to validate that URL.  The key used by the uCDN
 to validate the original URL is expected to be different than the key
 used to sign the new URL.  In the case of asymmetric keys, the CSP
 signs the original URL with its private key.  The Authoritative CDN
 validates that URL with the CSP's public key.  The Authoritative CDN
 redirects the request to the dCDN.  The new URL is signed by the uCDN
 with its private key.  The dCDN validates that URL with the uCDN's
 public key.  There may be more than one level of redirection to reach
 the delivering CDN.  The URL signing operation described previously
 applies at each level between the uCDN and dCDN for both symmetric
 keys and asymmetric keys.

van Brandenburg, et al. Informational [Page 33] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 URL signing requires support in most of the CDNI interfaces.  The
 CDNI Metadata interface should specify the content that is subject to
 URL signing and provide information to perform the function.  The
 dCDN should inform the uCDN that it supports URL signing in the
 asynchronous capabilities information advertisement as part of the
 Request Routing interface.  This allows the CDN selection function in
 request routing to choose the dCDN with URL signing capability when
 the CDNI Metadata of the content requires this authorization method.
 The logging interface provides information on the authorization
 method (e.g., URL signing) and related authorization parameters used
 for content delivery.  Having the information in the URL is not
 sufficient to know that the Surrogate enforced the authorization.
 URL signing has no impact on the control interface.

3.5.3. Option 5.1: Do Nothing

 This approach means that the CSP can only perform URL signing for the
 top-level Manifest File.  The top-level Manifest File contains chunk
 URLs or lower-level Manifest File URLs, which are not modified (i.e.,
 no URL signing for the embedded URLs).  In essence, the lower-level
 Manifest Files and chunks are delivered without content access
 authorization.
 Effect on CDNI interfaces:
 o  None
 Advantages/Drawbacks:
 +  Top-level Manifest File access is protected
 +  The uCDN and dCDN do not need to be aware of HAS content
  1. Lower-level Manifest Files and chunks are not protected, making

this approach unqualified for content access authorization

3.5.4. Option 5.2: Flexible URL Signing by CSP

 In addition to URL signing for the top-level Manifest File, the CSP
 performs flexible URL signing for the lower-level Manifest Files and
 chunks.  For each HAS session, the top-level Manifest File contains
 signed chunk URLs or signed lower-level Manifest File URLs for the
 specific session.  The lower-level Manifest File contains session-
 based signed chunk URLs.  The CSP generates the Manifest Files
 dynamically for the session.  The chunk (segment/fragment) is
 delivered with content access authorization using flexible URL
 signing, which protects the invariant portion of the URL.  A
 "segment" URL (e.g., HLS) is individually signed for the invariant

van Brandenburg, et al. Informational [Page 34] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 URL portion (relative URL) or the entire URL (absolute URL without
 redirection) in the Manifest File.  A "fragment" URL (e.g., HTTP
 Smooth Streaming) is signed for the invariant portion of the template
 URL in the Manifest File.  More details are provided later in this
 section.  The URL signing expiration time for the chunk needs to be
 long enough to play the video.  There are implications related to
 signing the URLs in the Manifest File.  For live content, the
 Manifest Files are requested at a high frequency.  For VoD content,
 the Manifest File may be quite large.  URL signing can add more
 computational load and delivery latency in high-volume cases.
 For HAS content, the Manifest File contains the relative URL,
 absolute URL without redirection, or absolute URL with redirection
 for specifying the chunk location.  Signing the chunk URL requires
 that the CSP know the portion of the URL that remains when the
 content is requested from the delivering CDN Surrogate.
 For absolute URLs without redirection, the CSP knows that the chunk
 URL is explicitly linked with the delivering CDN Surrogate and can
 sign the URL based on that information.  Since the entire URL is set
 and does not change, the Surrogate can validate the URL.  The CSP and
 the delivering CDN are expected to have a business relationship in
 this case, and so either symmetric keys or asymmetric keys can be
 used for URL signing.
 For relative URLs, the URL of the Manifest File provides the root
 location.  The method of request routing affects the URL used to
 ultimately request the chunk from the delivering CDN Surrogate.  For
 DNS, the original URL does not change.  This allows the CSP to sign
 the chunk URL based on the Manifest File URL and the relative URL.
 For HTTP, the URL changes during redirection.  In this case, the CSP
 does not know the redirected URL that will be used to request the
 Manifest File.  This uncertainty makes it impossible to accurately
 sign the chunk URLs in the Manifest File.  Basically, URL signing
 using this reference method "as is" for protection of the entire URL
 is not supported.  However, instead of signing the entire URL, the
 CSP signs the relative URL (i.e., the invariant portion of the URL)
 and conveys the protected portion in the authorization parameters
 embedded in the chunk URL.  This approach works in the same way as
 absolute URLs without redirection, except that the HOST part and
 (part of) the PATH part of the URL are not signed and validated.  The
 security level should remain the same, as content access
 authorization ensures that the user that requested the content has
 the proper credentials.  This scheme does not seem to compromise the
 authorization model, since the resource is still protected by the
 authorization parameters and message digest.  Further evaluation of
 security might be helpful.

van Brandenburg, et al. Informational [Page 35] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 For absolute URLs with redirection, the method of request routing
 affects the URL used to ultimately request the chunk from the
 delivering CDN Surrogate.  This case has the same conditions as those
 indicated above for the relative URL.  The difference is that the URL
 is for the chunk instead of the Manifest File.  For DNS, the chunk
 URL does not change and can be signed by the CSP.  For HTTP, the URL
 used to deliver the chunk is unknown to the CSP.  In this case, the
 CSP cannot sign the URL, and this method of reference for the chunk
 is not supported.
 Effect on CDNI interfaces:
 o  Requires the ability to exclude the variant portion of the URL in
    the signing process.  (NOTE: Is this issue specific to URL signing
    support for HAS content and not CDNI?)
 Advantages/Drawbacks:
 +  The Manifest File and chunks are protected
 +  The uCDN and dCDN do not need to be aware of HAS content
 +  DNS-based request routing with asymmetric keys and HTTP-based
    request routing for relative URLs and absolute URLs without
    redirection work
  1. The CSP has to generate Manifest Files with session-based signed

URLs and becomes involved in content access authorization for

    every HAS session
  1. Manifest Files are not cacheable
  1. DNS-based request routing with symmetric keys may be problematic

due to the need for transitive trust between the CSP and

    delivering CDN
  1. HTTP-based request routing for absolute URLs with redirection does

not work, because the URL used by the delivering CDN Surrogate is

    unknown to the CSP

van Brandenburg, et al. Informational [Page 36] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

3.5.5. Option 5.3: Flexible URL Signing by uCDN

 This is similar to the previous section, with the exception that the
 uCDN performs flexible URL signing for the lower-level Manifest Files
 and chunks.  URL signing for the top-level Manifest File is still
 provided by the CSP.
 Effect on CDNI interfaces:
 o  Requires the ability to exclude the variant portion of the URL in
    the signing process.  (NOTE: Is this issue specific to URL signing
    support for HAS content and not CDNI?)
 Advantages/Drawbacks:
 +  The Manifest File and chunks are protected
 +  The CSP does not need to be involved in content access
    authorization for every HAS session
 +  The dCDN does not need to be aware of HAS content
 +  DNS-based request routing with asymmetric keys and HTTP-based
    request routing for relative URLs and absolute URLs without
    redirection work
  1. The uCDN has to generate Manifest Files with session-based signed

URLs and becomes involved in content access authorization for

    every HAS session
  1. Manifest Files are not cacheable
  1. The Manifest File needs to be distributed through the uCDN
  1. DNS-based request routing with symmetric keys may be problematic

due to the need for transitive trust between the uCDN and

    non-adjacent delivering CDN
  1. HTTP-based request routing for absolute URLs with redirection does

not work, because the URL used by the delivering CDN Surrogate is

    unknown to the uCDN

3.5.6. Option 5.4: Authorization Group ID and HTTP Cookie

 Based on the Authorization Group ID metadata, the CDN validates the
 URL signing or validates the HTTP cookie for request of content in
 the group.  The CSP performs URL signing for the top-level Manifest
 File.  The top-level Manifest File contains lower-level Manifest File

van Brandenburg, et al. Informational [Page 37] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 URLs or chunk URLs.  The lower-level Manifest Files and chunks are
 delivered with content access authorization using an HTTP cookie that
 contains session state associated with authorization of the top-level
 Manifest File.  The Group ID metadata is used to associate the
 related content (i.e., Manifest Files and chunks).  It also specifies
 content (e.g., regexp method) that needs to be validated by either
 URL signing or an HTTP cookie.  Note that the creator of the metadata
 is HAS aware.  The duration of the chunk access may be included in
 the URL signing of the top-level Manifest File and set in the cookie.
 Alternatively, the access control duration could be provided by the
 CDNI Metadata interface.
 Effect on CDNI interfaces:
 o  CDNI Metadata interface: Authorization Group ID metadata
    identifies the content that is subject to validation of URL
    signing or validation of an HTTP cookie associated with the URL
    signing
 o  CDNI Logging interface: Report the authorization method used to
    validate the request for content delivery
 Advantages/Drawbacks:
 +  The Manifest File and chunks are protected
 +  The CDN does not need to be aware of HAS content
 +  The CSP does not need to change the Manifest Files
  1. Authorization Group ID metadata is required (i.e., CDNI Metadata

interface enhancement)

  1. Requires the use of an HTTP cookie, which may not be acceptable in

some environments (e.g., where some targeted User Agents do not

    support HTTP cookies)
  1. The Manifest File has to be delivered by the Surrogate

3.5.7. Option 5.5: HAS Awareness with HTTP Cookie in CDN

 The CDN is aware of HAS content and uses URL signing and HTTP cookies
 for content access authorization.  URL signing is fundamentally about
 authorizing access to a content item or its specific content
 collections (representations) for a specific user during a time
 period, possibly also using some other criteria.  A chunk is an
 instance of the sets of chunks referenced by the Manifest File for
 the content item or its specific content collections.  This

van Brandenburg, et al. Informational [Page 38] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 relationship means that once the dCDN has authorized the Manifest
 File, it can assume that the associated chunks are implicitly
 authorized.  The new function for the CDN is to link the Manifest
 File with the chunks for the HTTP session.  This can be accomplished
 by using an HTTP cookie for the HAS session.
 After validating the URL and detecting that the requested content is
 a top-level Manifest File, the delivering CDN Surrogate sets an HTTP
 cookie with a signed session token for the HTTP session.  When a
 request for a lower-level Manifest File or chunk arrives, the
 Surrogate confirms that the HTTP cookie value contains the correct
 session token.  If so, the lower-level Manifest File or chunk is
 delivered in accordance with the transitive authorization mechanism.
 The duration of the chunk access may be included in the URL signing
 of the top-level Manifest File and set in the cookie.  The details of
 the operation are left to be determined later.
 Effect on CDNI interfaces:
 o  CDNI Metadata interface: New metadata identifies the content that
    is subject to validation of URL signing and information in the
    cookie for the type of HAS content
 o  Request Routing interface: The dCDN should inform the uCDN that it
    supports URL signing for known HAS content types in the
    asynchronous capabilities information advertisement.  This allows
    the CDN selection function in request routing to choose the
    appropriate dCDN when the CDNI Metadata identifies the content
 o  CDNI Logging interface: Report the authorization method used to
    validate the request for content delivery
 Advantages/Drawbacks:
 +  The Manifest File and chunks are protected
 +  The CSP does not need to change the Manifest Files
  1. Requires full HAS awareness on the part of the uCDN and dCDN
  1. Requires extensions to CDNI interfaces
  1. Requires the use of an HTTP cookie, which may not be acceptable in

some environments (e.g., where some targeted User Agents do not

    support HTTP cookies)
  1. The Manifest File has to be delivered by the Surrogate

van Brandenburg, et al. Informational [Page 39] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

3.5.8. Option 5.6: HAS Awareness with Manifest File in CDN

 The CDN is aware of HAS content and uses URL signing for content
 access authorization of Manifest Files and chunks.  The CDN generates
 or rewrites the Manifest Files and learns about the chunks based on
 the Manifest File.  The embedded URLs in the Manifest File are signed
 by the CDN.  The duration of the chunk access may be included in the
 URL signing.  The details of the operation are left to be determined
 later.  Since this approach is based on signing the URLs in the
 Manifest File, the implications for live and VoD content mentioned in
 Section 3.5.4 apply.
 Effect on CDNI interfaces:
 o  CDNI Metadata interface: New metadata identifies the content that
    is subject to validation of URL signing and information in the
    cookie for the type of HAS content
 o  Request Routing interface: The dCDN should inform the uCDN that it
    supports URL signing for known HAS content types in the
    asynchronous capabilities information advertisement.  This allows
    the CDN selection function in request routing to choose the
    appropriate dCDN when the CDNI Metadata identifies the content
 o  CDNI Logging interface: Report the authorization method used to
    validate the request for content delivery
 Advantages/Drawbacks:
 +  The Manifest File and chunks are protected
 +  The CSP does not need to change the Manifest Files
  1. Requires full HAS awareness on the part of the uCDN and dCDN
  1. Requires extensions to CDNI interfaces
  1. Requires the CDN to generate or rewrite the Manifest File
  1. The Manifest File has to be delivered by the Surrogate

van Brandenburg, et al. Informational [Page 40] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

3.5.9. Recommendations

 The authors consider Option 5.1 (do nothing) unsuitable for access
 control of HAS content.
 Where the HTTP cookie mechanism is supported by the targeted User
 Agents and the security requirements can be addressed through the
 proper use of HTTP cookies, the authors recommend using Option 5.4
 (Authorization Group ID and HTTP cookie) and therefore that
 Option 5.4 be supported by the CDNI solution.  This method does not
 require Manifest File manipulation, as Manifest File manipulation may
 be a significant obstacle to deployment.  Otherwise, the authors
 recommend that Option 5.2 (flexible URL signing by the CSP) or
 Option 5.3 (flexible URL signing by the uCDN) be used and therefore
 that flexible URL signing be supported by the CDNI solution.
 Options 5.2 and 5.3 protect all the content, do not require that the
 dCDN be aware of HAS, do not impact CDNI interfaces, support all
 different types of devices, and support the common cases of request
 routing for HAS content (i.e., DNS-based request routing with
 asymmetric keys and HTTP-based request routing for relative URLs).
 Options 5.5 and 5.6 (HAS awareness in CDNs using HTTP cookies or
 Manifest Files) have some advantages that should be considered for
 future support (e.g., a CDN that is aware of HAS content can manage
 the content more efficiently in a broader context).  Content
 distribution, storage, delivery, deletion, access authorization, etc.
 can all benefit.  Including HAS awareness as part of the current CDNI
 charter, however, would almost certainly delay the CDNI WG's
 milestones, and the authors therefore do not recommend it right now.

3.6. Content Purge

 At some point in time, a uCDN might want to remove content from a
 dCDN.  With regular content, this process can be relatively
 straightforward; a uCDN will typically send the request for content
 removal to the dCDN, including a reference to the content that it
 wants to remove (e.g., in the form of a URL).  However, due to the
 fact that HAS content consists of large groups of files, things might
 be more complex.  Section 3.1 described a number of different
 scenarios for doing file management on these groups of files, while
 Section 3.2 listed the options for performing content acquisition on
 these content collections.  This section presents the options for
 requesting a content purge for the removal of a content collection
 from a dCDN.

van Brandenburg, et al. Informational [Page 41] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

3.6.1. Option 6.1: No HAS Awareness

 The most straightforward way to signal content purge requests is to
 just send a single purge request for every file that makes up the
 content collection.  While this method is very simple and does not
 require HAS awareness, it obviously creates signaling overhead
 between the uCDN and dCDN, since a reference is to be provided for
 each content chunk to be purged.
 Effect on CDNI interfaces:
 o  None
 Advantages/Drawbacks (apart from those already listed under
 Option 3.3):
 +  Does not require changes to the CDNI interfaces or HAS awareness
  1. Requires individual purge request for every file making up a

content collection (or, alternatively, requires the ability to

    convey references to all the chunks making up a content collection
    inside a purge request), which creates signaling overhead

3.6.2. Option 6.2: Purge Identifiers

 There exists a potentially more efficient method for performing
 content removal of large numbers of files simultaneously.  By
 including a "Purge IDentifier (Purge-ID)" in the metadata of a
 particular file, it is possible to virtually group together different
 files making up a content collection.  A Purge-ID can take the form
 of an arbitrary number or string that is communicated as part of the
 CDNI Metadata interface, and that is the same for all files making up
 a particular content item but different across different content
 items.  If a uCDN wants to request that the dCDN remove a content
 collection, it can send a purge request containing this Purge-ID.
 The dCDN can then remove all files that share the corresponding
 Purge-ID.
 The advantage of this method is that it is relatively simple to use
 by both the dCDN and uCDN and requires only limited additions to the
 CDNI Metadata interface and CDNI Control interface.
 The Purge-ID is similar to the CCID discussed in Section 3.4.2.2 for
 handling HAS logging, and we note that further thought is needed to
 determine whether the CCID and Purge-ID should be collapsed into a
 single element or remain separate elements.

van Brandenburg, et al. Informational [Page 42] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

 Effect on CDNI interfaces:
 o  CDNI Metadata interface: Add metadata field for indicating
    Purge-ID
 o  CDNI Control interface: Add functionality to convey a Purge-ID in
    purge requests
 Advantages/Drawbacks:
 +  Allows for efficient purging of content from a dCDN
 +  Does not require HAS awareness on the part of a dCDN

3.6.3. Recommendations

 Based on the listed pros and cons, the authors recommend that the WG
 have mandatory support for Option 1.1 (do nothing).  In addition,
 because of its very low complexity and its benefit in facilitating
 low-overhead purge of large numbers of content items simultaneously,
 the authors recommend that Purge-IDs (Option 6.2; see Section 3.6.2)
 be supported as an optional feature by the CDNI Metadata interface
 and the CDNI Control interface.

3.7. Other Issues

 This section includes some HAS-specific issues that came up during
 the discussion of this document and that do not fall under any of the
 categories discussed in the previous sections.
  1. As described in Section 2.2, a Manifest File might be delivered by

either a CDN or the CSP and thereby be invisible to the CDN

    delivering the chunks.  Obviously, the decision of whether the CDN
    or CSP delivers the Manifest File is made between the uCDN and
    CSP, and the dCDN has no choice in the matter.  However, some
    dCDNs might only want to offer their services in the cases where
    they have access to the Manifest File (e.g., because their
    internal architecture is based on the knowledge inside the
    Manifest File).  For these cases, it might be useful to include a
    field in the CDNI Capability Advertisement to allow dCDNs to
    advertise the fact that they require access to the Manifest File.

4. Security Considerations

 This document does not discuss security issues related to HTTP or HAS
 delivery, as these topics are expected to be discussed in the CDNI WG
 documents, including [CDNI-FRAMEWORK].

van Brandenburg, et al. Informational [Page 43] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

5. Acknowledgements

 The authors would like to thank Kevin Ma, Stef van der Ziel, Bhaskar
 Bhupalam, Mahesh Viveganandhan, Larry Peterson, Ben Niven-Jenkins,
 and Matt Caulfield for their valuable contributions to this document.

6. References

6.1. Normative References

 [RFC6707]  Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
            Distribution Network Interconnection (CDNI) Problem
            Statement", RFC 6707, September 2012.

6.2. Informative References

 [CDNI-FRAMEWORK]
            Peterson, L., Ed., and B. Davie, "Framework for CDN
            Interconnection", Work in Progress, February 2013.
 [CDNI-LOGGING]
            Bertrand, G., Ed., Stephan, E., Peterkofsky, R., Le
            Faucheur, F., and P. Grochocki, "CDNI Logging Interface",
            Work in Progress, October 2012.
 [CDNI-REQUIREMENTS]
            Leung, K., Ed., and Y. Lee, Ed., "Content Distribution
            Network Interconnection (CDNI) Requirements", Work in
            Progress, July 2013.
 [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
            Resource Identifier (URI): Generic Syntax", STD 66,
            RFC 3986, January 2005.

van Brandenburg, et al. Informational [Page 44] RFC 6983 HTTP Adaptive Streaming and CDNI July 2013

Authors' Addresses

 Ray van Brandenburg
 TNO
 Brassersplein 2
 Delft  2612CT
 the Netherlands
 Phone: +31-88-866-7000
 EMail: ray.vanbrandenburg@tno.nl
 Oskar van Deventer
 TNO
 Brassersplein 2
 Delft  2612CT
 the Netherlands
 Phone: +31-88-866-7000
 EMail: oskar.vandeventer@tno.nl
 Francois Le Faucheur
 Cisco Systems
 E.Space Park - Batiment D
 6254 Allee des Ormes - BP 1200
 06254 Mougins cedex
 France
 Phone: +33 4 97 23 26 19
 EMail: flefauch@cisco.com
 Kent Leung
 Cisco Systems
 170 West Tasman Drive
 San Jose, CA  95134
 USA
 Phone: +1 408-526-5030
 EMail: kleung@cisco.com

van Brandenburg, et al. Informational [Page 45]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6983.txt · Last modified: 2013/07/24 16:32 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki