Skip to main content

Models for adaptive-streaming-aware CDN Interconnection
draft-brandenburg-cdni-has-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6983.
Authors Ray van Brandenburg , Oskar van Deventer , François Le Faucheur , Kent Leung
Last updated 2012-07-13
RFC stream (None)
Formats
IETF conflict review conflict-review-brandenburg-cdni-has, conflict-review-brandenburg-cdni-has, conflict-review-brandenburg-cdni-has, conflict-review-brandenburg-cdni-has, conflict-review-brandenburg-cdni-has, conflict-review-brandenburg-cdni-has
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 6983 (Informational)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-brandenburg-cdni-has-03
CDNI                                                  R. van Brandenburg
Internet-Draft                                           O. van Deventer
Intended status: Informational                                       TNO
Expires: January 13, 2013                                 F. Le Faucheur
                                                                K. Leung
                                                           Cisco Systems
                                                           July 12, 2012

        Models for adaptive-streaming-aware CDN Interconnection
                     draft-brandenburg-cdni-has-03

Abstract

   This documents presents thoughts on the potential impact of
   supporting HTTP Adaptive Streaming technologies in CDN
   Interconnection scenarios.  Our intent is to spur discussion on how
   the different CDNI interfaces could, and should, deal with content
   delivered using adaptive streaming technologies and to facilitate
   working group decisions.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 13, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

van Brandenburg, et al.  Expires January 13, 2013               [Page 1]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  HTTP Adaptive Streaming aspects relevant to CDNI . . . . . . .  5
     2.1.  Segmentation versus Fragmentation  . . . . . . . . . . . .  5
     2.2.  Addressing chunks  . . . . . . . . . . . . . . . . . . . .  6
       2.2.1.  Relative URLs  . . . . . . . . . . . . . . . . . . . .  8
       2.2.2.  Absolute URLs with Redirection . . . . . . . . . . . .  8
       2.2.3.  Absolute URL without Redirection . . . . . . . . . . .  9
     2.3.  Live vs. VoD . . . . . . . . . . . . . . . . . . . . . . . 10
     2.4.  Stream splicing  . . . . . . . . . . . . . . . . . . . . . 11
   3.  Possible HAS Optimizations . . . . . . . . . . . . . . . . . . 11
     3.1.  File Management and Content Collections  . . . . . . . . . 12
       3.1.1.  General Remarks  . . . . . . . . . . . . . . . . . . . 12
       3.1.2.  Candidate approaches . . . . . . . . . . . . . . . . . 12
         3.1.2.1.  Option 1.1: No HAS awareness . . . . . . . . . . . 12
         3.1.2.2.  Option 1.2: Allow single file storage of
                   fragmented content . . . . . . . . . . . . . . . . 13
         3.1.2.3.  Option 1.3: Access correlation hint  . . . . . . . 14
       3.1.3.  Recommendation . . . . . . . . . . . . . . . . . . . . 14
     3.2.  Content Acquisition of Content Collections . . . . . . . . 15
       3.2.1.  General Remarks  . . . . . . . . . . . . . . . . . . . 15
       3.2.2.  Candidate Approaches . . . . . . . . . . . . . . . . . 15
         3.2.2.1.  Option 2.1: No HAS awareness . . . . . . . . . . . 15
         3.2.2.2.  Option 2.2: Allow single file acquisition of
                   fragmented content . . . . . . . . . . . . . . . . 16
       3.2.3.  Recommendation . . . . . . . . . . . . . . . . . . . . 16
     3.3.  Request Routing of HAS content . . . . . . . . . . . . . . 17
       3.3.1.  General remarks  . . . . . . . . . . . . . . . . . . . 17
       3.3.2.  Candidate approaches . . . . . . . . . . . . . . . . . 17
         3.3.2.1.  Option 3.1: No HAS awareness . . . . . . . . . . . 17
         3.3.2.2.  Option 3.2: Manifest File rewriting by uCDN  . . . 19
         3.3.2.3.  Option 3.3: Two-step Manifest File rewriting . . . 20
       3.3.3.  Recommendation . . . . . . . . . . . . . . . . . . . . 21
     3.4.  Logging  . . . . . . . . . . . . . . . . . . . . . . . . . 22
       3.4.1.  General remarks  . . . . . . . . . . . . . . . . . . . 22
       3.4.2.  Candidate Approaches . . . . . . . . . . . . . . . . . 23
         3.4.2.1.  Option 4.1: "Do-Nothing" Approach  . . . . . . . . 23
         3.4.2.2.  Option 4.2: "CDNI Metadata Content Collection
                   ID" Approach . . . . . . . . . . . . . . . . . . . 25
         3.4.2.3.  Option 4.3: "CDNI Logging Interface

van Brandenburg, et al.  Expires January 13, 2013               [Page 2]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

                   Compression" Approach  . . . . . . . . . . . . . . 26
         3.4.2.4.  Option 4.4: "Full HAS
                   awareness/per-Session-Logs" Approach . . . . . . . 27
       3.4.3.  Recommendation . . . . . . . . . . . . . . . . . . . . 29
     3.5.  URL Signing  . . . . . . . . . . . . . . . . . . . . . . . 30
       3.5.1.  HAS Implications . . . . . . . . . . . . . . . . . . . 31
       3.5.2.  CDNI Considerations  . . . . . . . . . . . . . . . . . 31
       3.5.3.  Option 5.1: Do Nothing . . . . . . . . . . . . . . . . 33
       3.5.4.  Option 5.2.1: Flexible URL Signing by CSP  . . . . . . 33
       3.5.5.  Option 5.2.2: Flexible URL Signing by Upstream CDN . . 35
       3.5.6.  Option 5.3: Authorization Group ID and HTTP Cookie . . 36
       3.5.7.  Option 5.4.1: HAS-awareness with HTTP Cookie in CDN  . 37
       3.5.8.  Option 5.4.2: HAS-awareness with Manifest in CDN . . . 38
       3.5.9.  URL Signing Options Analysis . . . . . . . . . . . . . 39
     3.6.  Content Purge  . . . . . . . . . . . . . . . . . . . . . . 40
       3.6.1.  Option 6.1: No HAS awareness . . . . . . . . . . . . . 40
       3.6.2.  Option 6.2: Purge Identifiers  . . . . . . . . . . . . 40
     3.7.  Other issues . . . . . . . . . . . . . . . . . . . . . . . 41
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 41
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 42
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 42
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 42
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43

van Brandenburg, et al.  Expires January 13, 2013               [Page 3]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

1.  Introduction

   HTTP Adaptive Streaming (HAS) is an umbrella term for various HTTP-
   based streaming technologies that allow a client to adaptively switch
   between multiple bitrates depending on current network conditions.  A
   defining aspect of HAS is that, since it is based on HTTP, it is a
   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 RTP/RTSP, RTMP and MMS.  This document presents a
   discussion on what the impact of these different characteristics is
   to the CDNI interfaces and what HAS-specific optimizations may be
   required or may be desirable.  The scope of this document in its
   current form is explicitly not to propose any specific solution, but
   merely to present the available options so that the WG can make an
   informed decision on which way to go.

1.1.  Terminology

   This document uses the terminology defined in
   [I-D.ietf-cdni-problem-statement].

   In addition, the following terms are used throughout this document:

   Content Item: A uniquely addressable content element in a CDN.  A
   content item is defined by the fact that it has its own Content
   Metadata associated with it.  It is the object of a request routing
   operation in a CDN.  An example of a Content Item is a video file/
   stream, an audio file/stream or an image file.

   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: Not-chunked content that is the basis for a
   segmentation of 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.

van Brandenburg, et al.  Expires January 13, 2013               [Page 4]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   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 Media
   Presentation Description (MPD) file, is a file that list the way the
   content has been chunked (possibly for multiple encodings) and where
   the various chunks are located (in the case of segments) or how they
   can be addressed (in the case of fragments).

2.  HTTP Adaptive Streaming aspects relevant to CDNI

   In the last couple of years, a wide variety of HAS-like protocols
   have emerged.  Among them are proprietary solutions such as Apple's
   HTTP Live Streaming (HLS), Microsoft's Smooth Streaming (HSS) and
   Adobe's HTTP Dynamic Streaming (HDS), and 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 chapter will look 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 will describe the
   various methods to store HAS content and Section 2.2 will list three
   methods that are used to address HAS content in a CDN.  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 and VoD content,
   while Section 2.4 discusses the scenario where multiple streams are
   combined in a single manifest files (e.g. for ad insertion purposes).

2.1.  Segmentation versus Fragmentation

   All HAS implementations are based around a concept referred to as
   chunking: the concept of having a server split content up in numerous
   fixed duration chunks, which are independently decodable.  By
   sequentially requesting and receiving chunks, a client can recreate
   and play out the content.  An advantage of this mechanism is that it
   allows a client to seamlessly switch between different encodings of
   the same Original Content at chunk boundaries.  Before requesting a
   particular chunk, a client can choose between multiple alternative

van Brandenburg, et al.  Expires January 13, 2013               [Page 5]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   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.

   -  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 independent 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.

   -  With fragmentation (or virtual segmentation), which is for example
      used in Microsoft's Smooth Streaming, all chunks, or fragments,
      belonging to the same Chunk Collection are stored together, as
      part of a single file.  While there are a number of container
      formats which allow for storing this type chunked content,
      Fragmented MP4 is most commonly used.  With fragmentation, a
      specific chunk is addressable by subfixing the common file URL
      with an identifier uniquely identifying the chunk one is
      interested in, either by timestamp, by byterange, or in some other
      way.

   While one can argue about the merits of each of these two different
   methods of handling chunks, both have their advantages and drawbacks
   in a CDN environment.  For example, fragmentation is often regarded
   as a method that introduces less overhead, both from a storage and
   processing perspective.  Segmentation on the other hand, is regarded
   as being more flexible and easier to cache.  In practice, current HAS
   implementations increasingly support both methods.

2.2.  Addressing chunks

   In order for a client to request chunks, either in the form of
   segments or in the form of fragments, it needs to know how the
   content has been chunked and where to find the chunks.  For this
   purpose, most HAS protocols use a concept that is often referred to
   as a Manifest File (also known as Media Presentation Description, or
   MPD); 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 encodings,
   and thus Chunk Collections, the content is available in.

   In general, a HAS client will first request and receive a Manifest

van Brandenburg, et al.  Expires January 13, 2013               [Page 6]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   File, and then, after parsing the information in the Manifest File,
   proceed with sequentially requesting the chunks listed in the
   Manifest File.  Each HAS implementation has its own Manifest File
   format and even within a particular format there are different
   methods available to specify the location of a chunk.

   Of course managing the location of files is a core aspect of every
   CDN, and each CDN will have its own method of doing so.  Some CDNs
   may be purely cache-based, with no higher-level knowledge of where
   each file resides at each instant in time.  Other CDNs may have
   dedicated management nodes which, at each instant in time, do know at
   which servers each file resides.  The CDNI interfaces designed in the
   CDNI WG will probably need to be agnostic to these kinds of CDN-
   internal architecture decisions.  In the case of HAS there is a
   strict relationship between the location of the content in the CDN
   (in this case chunks) and the content itself (the locations specified
   in the Manifest File).  It is therefore useful to have an
   understanding of the different methods in use in CDNs today for
   specifying chunk locations in Manifest Files.  The different methods
   for doing so are described in sections 2.2.1 to 2.2.3.

   Although these sections are especially relevant for segmented
   content, due to its inherent distributed nature, the discussed
   methods are also applicable to fragmented content.  Furthermore, it
   should be noted that the methods detailed below for specifying
   locations of content items in Manifest Files do not only relate to
   temporally segmented content (e.g. segments and fragments), but are
   also relevant in situations where content is made available in
   multiple 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 apply that are used for specifying chunk locations.

   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 are handled by the CDN, there are
   scenarios imaginable in which the manifest file is delivered by e.g.
   the Content Provider, and the manifest is therefore not visible to
   the CDN.

van Brandenburg, et al.  Expires January 13, 2013               [Page 7]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

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 where the Manifest File has
   been acquired from.  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 a manifest 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.

   For example, in the case 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 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

   The downside of using relative URLs is that it forces a CDN 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 directly).

   In the context of Manifest Files, there are two types of absolute

van Brandenburg, et al.  Expires January 13, 2013               [Page 8]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   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 which will redirect the client to a
   surrogate (Absolute URL with Redirection) or point directly to a
   surrogate hosting the requested content (Absolute URL 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
   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 includes some arguments
   identifying the requested segment.

   The advantage of using Absolute URLs with Redirection is that it
   allows for maximum flexibility (since chunks can be distributed
   across surrogates and CDN 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 adds 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 URL without Redirection

   In the case of the Absolute URL 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 URLs without Redirection is the following:

van Brandenburg, et al.  Expires January 13, 2013               [Page 9]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

      http://surrogate.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), as
   well as the server that is expected to deliver the segment (in this
   case surrogate.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
   Absolute URLs without Redirection 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 vs. VoD

   Though the formats and addresses of manifest and chunk files do not
   typically differ significantly between live and Video-on-Demand (VoD)
   content, the time at which the manifests 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:

   -  With live content, chunk files are made available in real-time.
      This limits the applicability of bundling for content acquisition
      purposes.  Prepositioning may still be employed, however, any
      significant latency in the prepositioning may diminish the value
      of prepositioning if a client requests the chunk prior to
      prepositioning, or if the prepositioning request is serviced after
      the chunk playout time has passed.

   -  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 manifest-based optimization schemes 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.

   -  Since live manifest files are updated as each new chunk becomes
      available, the cacheability of manifest files is limited.  Though
      timestamping and reasonable TTLs can improve delivery performance,
      timely replication and delivery of updated manifest files is
      critical to ensuring uninterrupted playback.

van Brandenburg, et al.  Expires January 13, 2013              [Page 10]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   -  Manifest files are typically updated after the corresponding chunk
      is available for delivery, to prevent premature requests for
      chunks which are not yet available.  HAS optimization approaches
      which employ dynamic manifest generation must be synchronized with
      chunk creation to prevent playback errors.

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 which contain Absolute URLs with
   redirection may contain chunk or nested manifest URLs which 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 (e.g., comments or custom
   tags) for performing stream splicing.  This often occurs outside the
   scope of the interconnected CDNs.  HAS optimization schemes which
   employ dynamic manifest generation or rewriting must be cognizant of
   chunk URLs, nested manifest URLs, and other metadata which 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 content
   providers.

3.  Possible HAS Optimizations

   In the previous chapter, some of the unique properties of HAS have
   been discussed.  Furthermore, some of the CDN-specific design
   decisions with regards to addressing chunks have been detailed.  In
   this chapter, the impact of supporting HAS in CDN Interconnection
   scenarios will be 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 in way that 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 chapter will

van Brandenburg, et al.  Expires January 13, 2013              [Page 11]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   briefly describe each of the following problem areas together with a
   number of different options for dealing with them.  Section 3.1 will
   discuss the problem of how to deal with file management of groups of
   files, or Content Collections.  Section 3.2 will deal with a related
   topic: how to do content acquisition of Content Collections between
   the uCDN and 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 number of possible
   optimizations for the logging of HAS content, while Section 3.5
   discusses the options regarding URL signing.  Section 3.6 finally,
   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
   (segment, 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, which
   are stored independently from each other.  An advantage of this
   approach is that 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.

   This section will 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: No HAS awareness

   This first 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 explicitely made aware of the relationship

van Brandenburg, et al.  Expires January 13, 2013              [Page 12]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   between chunks and it 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 to store fragmented content as a single file (see
   Section 2.1).  The one exception to this rule is the situation where
   the content is fragmented and the Manifest Files on the uCDN contains
   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 CDN Interfaces:

   o  None

   Advantages/Drawbacks:

   +  No HAS awareness necessary in CDNs, no changes to CDNI Interfaces
      necessary

   -  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 merge the different chunks
   together and place them in the same container (e.g. fragmented MP4).
   The downside of this is that in order to do so, the dCDN needs to be
   fully HAS aware.

   Effect on CDN 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:

van Brandenburg, et al.  Expires January 13, 2013              [Page 13]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   +  Allows dCDN to store fragmented content as a single file, reducing
      file management overhead

   -  Complex operation, requiring 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 a '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
   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 CDN Interfaces:

   o  CDNI Metadata Interface: Add field for indicating Access
      Correlation Hint

   Advantages/Drawbacks:

   +  Allows dCDN to perform file management optimization

   +  Does not require any HAS awareness

   +  Very small impact on CDNI Interfaces

   -  Expected benefit compared with Option 1.1 is small

3.1.3.  Recommendation

   Based on the listed pros and cons, the authors recommend the WG to go
   for Option 1.1, the 'Do Nothing'-approach.  The likely benefits from
   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
   options would require significant CDNI extensions that would impact
   the WG's milestones.  The authors therefore don't recommend to
   include it in the current work but mark it as a possible candidate
   for rechartering once the initial CDNI solution is completed.

van Brandenburg, et al.  Expires January 13, 2013              [Page 14]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

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 has been discussed.  This section will discuss
   a related topic, which is 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 pro-
   actively places content items on the nodes on which it expects
   traffic for 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 giving 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 first option assumes no HAS awareness in both the involved CDNs
   and the CDNI Interfaces.  Just as with Option 1.1 discussed in the
   previous section 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 in cases with fragmented content where the uCDN uses
   Manifest Files which 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.

van Brandenburg, et al.  Expires January 13, 2013              [Page 15]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   Effect on CDN Interfaces:

   o  None

   Advantages/Drawbacks:

   +  Per-chunk content acquisition allows for high level of flexibility
      between dCDN and uCDN

   -  Per-chunk content acquisition creates more transaction overhead
      between dCDN and uCDN

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) in cases
   where fragmented content can be acquired as a single file without any
   HAS awareness and that is when fragmented content is used and where a
   Manifest File includes byte range request.  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 single file and
   individual chunks to serve).

   Effect on CDN 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

   -  Requires full HAS awareness on part of dCDN

   -  Requires significant CDNI Metadata Interface extensions

3.2.3.  Recommendation

   Based on the listed pros and cons, the authors recommend the WG to 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 which would

van Brandenburg, et al.  Expires January 13, 2013              [Page 16]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   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 will be
   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
   Manifest File were described: Relative URLs, Absolute URLs without
   Redirection and Absolute URLs with 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 Content Provider.  Some Content Providers 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 Content Provider, a CDN may either host the Manifest
   Files as they were created by the Content Provider, or modify the
   Manifest File to adapt it to its particular architecture (e.g. by
   changing relative URLs to Absolute URLs which point to the CDN
   Request Routing function).

3.3.2.  Candidate approaches

3.3.2.1.  Option 3.1: No HAS awareness

   This first 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 have 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 Collections 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 Content
   Provider 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 Content Provider 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.

van Brandenburg, et al.  Expires January 13, 2013              [Page 17]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   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 that chunk 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 it does not
   have the necessary information to redirect the client directly to a
   surrogate in the dCDN).

   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 result in 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 function might
   have to perform database lookups and query each other.  While with
   DNS this overhead might be reduced by using DNS' 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 require a
   HAS aware CDN, they also cannot be used in this case.  The reason for
   this is that with Absolute URLs without Redirection, 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 CDN Interfaces:

   o  None

   Advantages/Drawbacks:

van Brandenburg, et al.  Expires January 13, 2013              [Page 18]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   +  Supports Absolute URLs with Redirection

   +  Supports Relative URLs

   +  Does not require HAS awareness and/or changes to the CDNI
      Interfaces

   -  Not possible to use Absolute URLs without Redirection

   -  Creates significant signaling overhead in case Absolute URLs with
      Redirection are used (inter-CDN request redirection for each
      chunk)

3.3.2.2.  Option 3.2: Manifest File rewriting by uCDN

   While Option 3.1 does allow for 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.

   The main advantage of this solution is that it does not direcly have
   an impact on the CDNI Interfaces and is therefore relatively
   transparent to these interfaces.  It is a function that a uCDN can
   perform independently by using the information that it receives from
   the dCDN as part of the regular CDNI Request Routing Interface
   communication.

   More specifically, in order for the uCDN to rewrite the manifest
   file, it only needs the location of the dCDN request routing function
   (or even better: the location of the dCDN surrogate).  Obtaining this
   information is part of a the regular CDNI Request Routing Interface
   and can be done in of of two ways.  The first way would be to have
   the uCDN 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 comes in at the uCDN request routing
   function.  The uCDN would then modify the manifest file and deliver
   the manifest file to the client.  A second way to do it would be for

van Brandenburg, et al.  Expires January 13, 2013              [Page 19]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   the modification of the manifest file to only happen once, when the
   first client for that particular Content Collection (and redirected
   to that particular dCDN) sends a Manifest File request.  The
   advantage of the first method is that it maximizes effiency and
   flexibility by allowing the dCDN to 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).  The advantage of the second method is that the uCDN
   only has to modify the Manifest File once.

   It should be noted that there are a number of things to take into
   account when changing a manifest file (see for example Section 2.3
   and Section 2.4 on live HAS content and ad insertion).  Furthermore,
   some Content Providers might have issues with a CDN changing manifest
   files.  However, in this option the manifest manipulation is only
   being performed by the uCDN, which can be expected to be aware of
   these limitations if it wants to perform manifest manipulation since
   it is in its own best interest that it's customer's content gets
   delivered in the proper way.  Should the Content Provider want to
   limit manifest manipulation, it can simply arrange this with the uCDN
   bilaterally.

   Effect on CDN Interfaces:

   o  None

   Advantages/Drawbacks:

   +  Possible to significantly decrease signalling overhead when using
      Absolute URLs.

   +  (Optional) Possible to have uCDN rewrite the manifest with
      locations of surrogates in dCDN (turning Absolute URLs with
      Redirection in Absolute URLs without Redirection)

   +  No changes to CDNI Interfaces

   +  Does not require HAS awareness in dCDN

   -  Requires high level of HAS awareness in uCDN (for modifying
      manifest files)

3.3.2.3.  Option 3.3: Two-step Manifest File rewriting

   One of the possibilities with Option 3.3 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

van Brandenburg, et al.  Expires January 13, 2013              [Page 20]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   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 and thereby not
   be able to use Absolute URLs without Redirection.

   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 minimal 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 that it 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 CDN Interfaces (apart from those listed under Option 3.3):

   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  dCDN: Allow for modification of manifest file

   Advantages/Drawbacks (apart from those listed under Option 3.3):

   +  Allows dCDN to use Absolute URLs without Redirection without
      having to convey sensitive information to the uCDN

   -  Requires high level of HAS awareness in dCDN (for modifying
      manifest files)

   -  Requires adding HAS-specific information to the CDNI Metadata
      Interface

3.3.3.  Recommendation

   Based on the listed pros and cons, the authors recommend to go for
   Option 3.1, with Option 3.2 as an optional feature for uCDN that
   support this.  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 with large signalling

van Brandenburg, et al.  Expires January 13, 2013              [Page 21]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   overhead.  Option 3.2 can solve most of these limitations and
   presents a significant reduction of the request routing overhead.
   Since Option 3.2 does not 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 the WG to 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 [I-D.ietf-cdni-problem-statement], "the CDNI Logging
   interface enables details of logs or events to be exchanged between
   interconnected CDNs".

   As discussed in [I-D.draft-bertrand-cdni-logging], the CDNI logging
   information can be used for multiple purposes including maintenance/
   debugging by uCDN, accounting (e.g. in view of billing or
   settlement), 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 per-content-item-delivery basis.
   This impacts the scale of every processing step in the Logging
   Process (see Section 8 of [I-D.draft-bertrand-cdni-logging]),
   including:

   a.  Logging Generation and Storing of logs on CDN elements
       (Surrogate, Request Routers,..)

   b.  Logging Aggregation within a CDN

   c.  Logging Manipulation (including Logging Protection, Logging
       Filtering , Logging Update and Rectification)

   d.  (Where needed) Logging CDNI Reformatting (e.g. reformatting from
       CDN-specific format to the CDNI Logging Interface format for
       export by dCDN to uCDN)

   e.  Logging exchange via CDNI Logging Interface

van Brandenburg, et al.  Expires January 13, 2013              [Page 22]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   f.  (Where needed) Logging Re-Reformatting (e.g. reformatting from
       CDNI Logging Interface format into log-consuming specific
       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 tool to debug)

   Note that there may be multiple instances of step [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 step [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, step [a], [b]
   and [d] cannot operate on a per-HAS-session basis and also need to
   operate on a per-chunk basis).

3.4.2.  Candidate Approaches

   The following sub-sections discusses the main candidate approaches
   identified so far for CDNI in terms of dealing with HAS with respect
   to Logging.

3.4.2.1.  Option 4.1: "Do-Nothing" Approach

   In this approach nothing is done specifically for HAS so that 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].
   This approach requires that step [a], [b], [c], [d] and [e] also be
   performed on a per-chunk basis.  This approach allows [g] to be
   performed either on a per-chunk basis (assuming step [f] maintains
   per-chunk records) or on a more "summarized" manner such as per-HAS-
   Session basis (assuming step [f] summarizes per-chunk records into
   per-HAS-session records).

   Effect on CDN Interfaces:

   o  None

   Effect on uCDN and dCDN:

   o  None

   Advantages/Drawbacks:

van Brandenburg, et al.  Expires January 13, 2013              [Page 23]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   +  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 (possibly required) for
      some Log consuming applications (e.g. debugging)

   +  Easier integration (at least in the short term) into existing
      Logging tools since those are all capable of handling per-chunk
      records

   +  No extension needed on CDNI interfaces

   -  High volume of logging information to be handled (storing &
      processing) at every step of the Logging process from [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).  While the high volume of logging information
      is a potential concern, we are seeking expert input on whether it
      is a real practical issue, and if yes, then in what timeframe/
      assumptions.

   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 anyways,
   this dCDN could include, in the CDNI Logging interface, one (or a
   few) log entry for a HAS session (instead of one entry per HAS-chunk)
   that summarizes the deliveries of many/all HAS-chunk for a session.
   However, the authors feel that, when considering the details of this,
   this 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 would the single URI included in the log entry correspond to?
      the manifest/top-level-playlist/next-level-playlist,...

   The authors feel that if explicit agreement is needed between uCDN
   and dCDN on how to perform/interpret the summarization is required,
   then this should be specified as part of the CDNI Logging interface

van Brandenburg, et al.  Expires January 13, 2013              [Page 24]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   and then effectively boils down to Option 4.5 defined below ("Full
   HAS awareness" and "per-Session-Logs" Approach).

   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 have a minor mitigation effect
   on the HAS logging scaling concerns because it ensures that only the
   necessary subset of fields are actually stored, reported and
   processed.

3.4.2.2.  Option 4.2: "CDNI Metadata Content Collection ID" Approach

   In this approach, a "Content Collection ID" (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, to uniquely
   identify a Content Collection.  When 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 downstream CDN happens to have sufficient HAS
   awareness to be able to generate a session identifier (Session-ID),
   optionally including such Session-ID (in addition to the CCID) in the
   per-chunk log record would further facilitate optional summarization
   performed 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 same
      content to same enduser at a given point in time).

   o  log records for different chunks of the same user session (.i.e
      delivery of same content to same enduser 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 mechanism to synchronize session-IDs across
      Surrogates.

   Effect on CDN Interfaces:

van Brandenburg, et al.  Expires January 13, 2013              [Page 25]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   o  CDNI Metadata interface: One additional metadata field (CCID) in
      CDNI Metadata Interface.  We note that a similar Content
      Collection ID is discussed for handling of other aspects of HAS
      and observe that further thought is needed to determine whether
      such 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.

   Effect on uCDN and dCDN:

   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 (possibly required) for
      some Log consuming applications (e.g. debugging)

   +  Easier integration (at least in the short term) into existing
      Logging tools since those 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 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)

   -  High volume of logging information to be handled (storing &
      processing) at every step of the Logging process from [a] to [f].
      While the high volume of logging information is a potential
      concern, we are seeking input on whether it is a real practical
      issue, and if yes in what timeframe/assumptions

3.4.2.3.  Option 4.3: "CDNI Logging Interface Compression" Approach

   In this approach, a loss-less compression technique is applied to the
   sets of Logging records (e.g.  Logging files) for transfer on the
   IETF CDNI Logging Interface.  The objective of this approach is to
   reduce the volume of information to be stored and transferred in step
   [e].

van Brandenburg, et al.  Expires January 13, 2013              [Page 26]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   Effect on CDN Interfaces:

   o  One additional compression mechanism to be included in the CDNI
      Logging Interface

   Effect on uCDN and dCDN:

   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 (possibly required) for
      some Log consuming applications (e.g. debugging)

   +  Easier integration (at least in the short term) into existing
      Logging tools since those 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 be also applicable to logs for non-HAS
      content

   -  High volume of logging information to be handled (storing &
      processing) at every step of the Logging process from [a] to [g],
      except [e].  While the high volume of logging information is a
      potential concern, we are seeking expert input on whether it is a
      real practical issue, and if yes, then in what timeframe/
      assumptions

   Input is sought on expected compression gains achievable in practice
   over sets of logs containing per-chunk records.

3.4.2.4.  Option 4.4: "Full HAS awareness/per-Session-Logs" Approach

   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 Surrogates leverage the HAS information distributed through
   the CDNI metadata and their HAS-awareness to generate summarized
   logging information in the very first place.  The objective of that
   approach is to operate on lower volume of logging information right

van Brandenburg, et al.  Expires January 13, 2013              [Page 27]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   from the very first step of the Logging process.

   The summarized HAS logs generated by the Surrogates in this approach
   are similar to those discussed in the section " "CDNI Metadata
   Content Collection ID With dCDN Summarization" Approach" and the same
   trade-offs between information loss and summarization gain apply.

   Effect on CDN Interfaces:

   o  One significant extension of the CDNI Metadata Interface 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

   Effect on uCDN and dCDN:

   o  Full HAS-awareness by dCDN Surrogates

   Advantages/Drawbacks:

   +  Lower volume of logging information to be handled (storing &
      processing) at every step of the Logging process from [a] to [g]

   +  Accurate generation of summarized logs because of HAS awareness on
      Surrogate (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)

   -  Very significant extensions to CDNI interfaces needed including
      per HAS-protocol specific support

   -  Very significant additional requirement for HAS awareness on dCDN
      and for this HAS-awareness to be consistent with the defined CDNI
      Logging summarization

   -  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 had ego be selected.  While full level of detail
      may not be needed for some Log consuming applications (e.g.
      billing), the full level of detail is likely valuable (possibly
      required) for some Log consuming applications (e.g. debugging)

van Brandenburg, et al.  Expires January 13, 2013              [Page 28]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   -  Less easy integration (at least in the short term) into existing
      Logging tools since those are all capable of handling per-chunk
      records and may not be capable of handling CDNI summarized records

   -  Challenges in defining behavior (and achieving summarization gain)
      in the presence of load-balancing of a given HAS-session across
      multiple Surrogates (in same or different dCDN)

   Input is sought on expected compression gains achievable in practice
   over sets of logs containing per-chunk records.

3.4.3.  Recommendation

   Because of its benefits (in particular simplicity, universal support
   by CDNs and support by all log-consuming applications), we recommend
   that the per-chunk logging of Option 4.1 be supported by the CDNI
   Logging interface as a "High Priority" (as defined in
   [I-D.draft-ietf-cdni-requirements]) and be a mandatory capability of
   CDNs implementing CDNI.

   Because of its very low complexity and its benefit in facilitating
   some useful scenarios (e.g. per-session analytics), we recommend that
   the CCID mechanisms and Session-ID mechanism of Option 4.2 be
   supported by the CDNI Metadata interface and the CDNI Logging
   interface as a "Medium Priority" (as defined in
   [I-D.draft-ietf-cdni-requirements]) and be an optional capability of
   CDNs implementing CDNI.

   We recommend that:

   (i)  the ability for the uCDN to request that the CCID and Session-ID
      field be included in log entries provided by the dCDN be supported
      by the relevant CDNI interfaces (tentatively the CDNI Metadata
      interface) and

   (ii)  the ability for the dCDN to include the CCID field and
      SEssion-ID in CDNI log entries (when the dCDN is capable of doing
      so) and indicate so inside the CDNI Logging interface (in line
      with the "customizable" log format expected to be defined
      independently of HAS),

   be supported as a "Medium Priority" (as defined in
   [I-D.draft-ietf-cdni-requirements]) and be an optional capability of
   CDNs implementing CDNI.

   When performing dCDN selection, an uCDN may want to take into account
   whether a given dCDN is capable of reporting the CCID and session-ID.
   Thus, we recommend that the ability for a dCDN to advertise its

van Brandenburg, et al.  Expires January 13, 2013              [Page 29]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   support of the optional CCID and SessionID capability be supported by
   the CDNI request Routing /Footprint and Capabilities Advertisment
   Interface as a "Medium Priority" (as defined in
   [I-D.draft-ietf-cdni-requirements]).

   Because it can be achieved with very little complexity and it
   provides some clear storage/communication compression benefits, we
   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
   [I-D.draft-ietf-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, we recommend that the log summarization discussed in
   option 4.4 not be supported by the CDNI Logging interface at this
   stage and be kept as candidate topic of great interest for a
   rechartering of the CDNI WG once the first set of deliverables is
   produced.  When doing so, we suggest to investigate the notion of
   complementing the "push-style" CDNI logging interface supporting
   summarization by an on-demand pull-type of interface allowing an uCDN
   to request the subset of the detailed logging information that it may
   need but is lost in the summarized pushed information.

   We 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 need to perform
   and retain per chunk logs.  As another example, to support the "Full
   HAS awareness/per-Session-Logs" Approach, the dCDN cannot operate on
   logging format that summarize "more than" or "in an incompatible way
   with" the summarization specified for CDNI Logging.  However, the
   authors feel such constraints are (i) inevitable, (ii) outweighed by
   the benefits of a standardized logging interface and (iii) acceptable
   because in case of incompatibel summarization, all/most CDNs are
   capable of reverting to per-chunk logging as per the Do-Nothing
   Approach that we recommend be used as the base minimum 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 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

van Brandenburg, et al.  Expires January 13, 2013              [Page 30]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   protected URL portion, and 2) message digest that confirms the
   integrity of the URL and authenticates the URL creator.  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 key.  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 for the symmetric key requires security to prevent
   others from taking it.  Public key can be distributed freely while
   private key is kept by the URL signer.  The method for key
   distribution is out of scope.

   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 URL that directly access the media content.  But for
   HAS content, the manifest file contains another layer of URL that
   reference the chunks.  The chunk URL that's embedded in the content
   may be requested at an indeterminate amount of time later.  The time
   period between access to the manifest and chunk retrieval may vary
   significantly.  The type of content (i.e.  Live or VoD) impacts the
   time variance as well.  HAS content has this property that 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 key for URL Signing has
   implications on the trust model between CSP and CDNs and the key
   distribution method that can be used.

   DNS-based request routing does not change the URL.  In the case of
   symmetric key, the CSP and the Authoritative CDN have a business
   relationship that allows them to share a key (or multiple keys) for

van Brandenburg, et al.  Expires January 13, 2013              [Page 31]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   URL Signing.  When the user request a content from the Authoritative
   CDN, the URL is signed by the CSP.  The Authorititative CDN (as a
   Upstream CDN) redirects the request to a Downstream CDN 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 the key to be distributed from Authoritative
   CDN to the Delivering CDN.  This may be problematic when the key is
   exposed to the Delivering CDN that does not have 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, CSP signs URL with its
   private key.  The Delivering CDN validates the URL with the
   associated public key.

   HTTP request routing changes the URL during redirection procedure.
   In the case of symmetric key, CSP signs the original URL with the
   same key used by the Authoritative CDN to validate the URL.  The
   Authoritative CDN (as a Upstream CDN) redirects the request to the
   Downstream CDN.  The new URL is signed by the Upstream CDN with the
   same key used by the Downstream CDN to validate that URL.  The key
   used by the Upstream CDN to validate the original URL is expect to be
   different than the key used to sign the new URL.  In the case of
   asymmetric keys, CSP signs the original URL with its private key.
   Authoritative CDN validates that URL with the CSP's public key.  The
   Authoritative CDN redirects the request to the Downstream CDN.  The
   new URL is signed by the Upstream CDN with its private key.  The
   Downstream CDN validates that URL with the Upstream CDN'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 Upstream CDN and Downstream CDN for
   both the symmetric key and asymmetric keys cases.

   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
   Downstream CDN should inform the Upstream CDN 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 Downstream CDN 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.

van Brandenburg, et al.  Expires January 13, 2013              [Page 32]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

3.5.3.  Option 5.1: Do Nothing

   "Do Nothing" approach means that 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 CDN Interfaces:

   o  None

   Advantages/Drawbacks:

   +  Top level manifest file access is protected

   +  Upstream CDN and Downstream CDN do not need to be aware of HAS
      content

   -  Lower level manifest files and chunks are not protected, making
      this approach unqualified for content access authorization

3.5.4.  Option 5.2.1: Flexible URL Signing by CSP

   In addition to URL Signing for the top level manifest file, 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.  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.  Segment URL
   (e.g.  HLS) is individually signed for the invariant URL portion
   (Relative URL) or the entire URL (Absolute URL without Redirection)
   in the manifest file.  Fragment URL (e.g.  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 of 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 Locator,
   Absolute Locator without Redirection, or Absolute Locator with

van Brandenburg, et al.  Expires January 13, 2013              [Page 33]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   Redirection for specifying the chunk location.  Signing the chunk URL
   requires CSP to know the portion of the URL that remains when the
   content is requested from the Delivery CDN surrogate.

   For Absolute URL without Redirection, the CSP knows that the chunk
   URL which is explicitly linked with the delivery 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 Delivery CDN are expected to have a business relationship in
   this case.  So either symmetric key or asymmetric keys can be used
   for URL Signing.

   For Relative URL, 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 Delivery CDN surrogate.  For
   DNS, the original URL does not change.  This allows 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, 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 entire URL protection, is not
   supported.  However, instead of signing the entire URL, the CSP signs
   the Relative URL (i.e. invariant portion of the URL) and conveys the
   protected portion in the authorization parameters embedded in the
   chunk URL.  This approach works the same way as Absolute URL without
   Redirection, except 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 credentials.  This scheme does not seem
   to compromise the authorization model since the resource is still
   protected by the authorization parameters and message digest.
   Perhaps, further evaluation on security would be helpful.

   For Absolute URL with Redirection, the method of request routing
   affects the URL used to ultimately request the chunk from the
   Delivery CDN surrogate.  This case has the same conditions as 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, CSP cannot sign the URL
   and this method of reference for the chunk is not supported.

   Effect on CDN Interfaces:

   o  Requires the ability to exclude the variant portion of URL in the
      signing process (NOTE: Issue is specific to URL Signing support
      for HAS content and not CDNI?)

van Brandenburg, et al.  Expires January 13, 2013              [Page 34]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   Advantages/Drawbacks:

   +  Manifest file and chunks are protected

   +  Upstream CDN and Downstream CDN do not need to be aware of HAS
      content

   +  DNS-based request routing with asymmetric keys and HTTP-based
      request routing for Relative URL and Absolute URL without
      Redirection works

   -  CSP has to generate manifest files with session-based signed URLs
      and becomes involved in content access authorization for every HAS
      session

   -  Manifest files are not cacheable

   -  DNS-based request routing with symmetric key may be problematic
      due to need for transitive trust between CSP and Delivery CDN

   -  HTTP-based request routing for Absolute URL with Redirection does
      not work because the URL used Delivery CDN surrogate is unknown to
      the CSP

3.5.5.  Option 5.2.2: Flexible URL Signing by Upstream CDN

   This is similar to the previous section, with the exception that the
   Upstream CDN performs flexible URL for the lower level manifest files
   and chunks.  URL Signing for the top level manifest file is still
   provided by the CSP.

   Effect on CDN Interfaces:

   o  Requires the ability to exclude the variant portion of URL in the
      signing process (NOTE: Issue is specific to URL Signing support
      for HAS content and not CDNI?)

   Advantages/Drawbacks:

   +  Manifest file and chunks are protected

   +  CSP does not need to be involved in content access authorization
      for every HAS session

   +  Downstream CDN does not need to be aware of HAS content

van Brandenburg, et al.  Expires January 13, 2013              [Page 35]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   +  DNS-based request routing with asymmetric keys and HTTP-based
      request routing for Relative URL and Absolute URL without
      Redirection works

   -  Upstream CDN has to generate manifest files with session-based
      signed URLs and becomes involved in content access authorization
      for every HAS session

   -  Manifest files are not cacheable

   -  Manifest file needs to be distributed through the uCDN

   -  DNS-based request routing with symmetric key may be problematic
      due to need for transitive trust between uCDN and non-adjacent
      Delivery CDN

   -  HTTP-based request routing for Absolute URL with Redirection does
      not work because the URL used Delivery CDN surrogate is unknown to
      the uCDN

3.5.6.  Option 5.3: Authorization Group ID and HTTP Cookie

   Based on the Authorization Group ID metadata, CDN validates the URL
   Signing or validates the HTTP cookie for request of content in the
   group.  CSP performs URL Signing for the top level manifest file.
   The top level manifest file contains lower level manifest file URLs
   or chunk URLs.  The lower level manifest files and chunks are
   delivered with content access authorization using 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 HTTP cookie.  Note that the creator of the metadata is
   HAS-aware.  Duration of the chunk access may be included in the URL
   Signing of the top level manifest file and set in the cookie.
   Duration may be provided by the CDNI Metadata interface instead.

   Effect on CDN Interfaces:

   o  CDNI Metadata Interface - Authorization Group ID metadata
      identifies the content that is subject to validation of URL
      Signing or validation of 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:

van Brandenburg, et al.  Expires January 13, 2013              [Page 36]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   +  Manifest file and chunks are protected

   +  CDN does not need to be aware of HAS content

   +  CSP does not need to change the manifest files

   -  Authorization Group ID metadata is required (i.e.  CDNI Metadata
      Interface enhancement)

   -  Requires the use of HTTP cookie which may be considered to be not
      desirable or even feasible

   -  Manifest file has to be delivered by surrogate

3.5.7.  Option 5.4.1: HAS-awareness with HTTP Cookie in CDN

   CDN is aware of HAS content and uses URL Signing and HTTP cookie 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 with possibly 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 relationship means
   that once the Downstream CDN 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 delivery CDN surrogate sets a 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 due to transitive authorization property.  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 CDN 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 - Downstream CDN should inform the
      Upstream CDN that it supports URL Signing for known HAS content

van Brandenburg, et al.  Expires January 13, 2013              [Page 37]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

      types in the asynchronous capabilities information advertisement.
      This allows the CDN selection function in request routing to
      choose the appropriate Downstream CDN 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:

   +  Manifest file and chunks are protected

   +  CSP does not need to change the manifest files

   -  Requires full HAS awareness on part of Upstream CDN and Downstream
      CDN

   -  Requires CDNI Interfaces extensions

   -  Requires the use of HTTP cookie which may be considered to be not
      desirable or even feasible

   -  Manifest file has to be delivered by surrogate

3.5.8.  Option 5.4.2: HAS-awareness with Manifest in CDN

   CDN is aware of HAS content and uses URL Signing for content access
   authorization of manifest file and chunk.  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.
   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 CDN 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 - Downstream CDN should inform the
      Upstream CDN 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 Downstream CDN when the CDNI metadata
      identifies the content

van Brandenburg, et al.  Expires January 13, 2013              [Page 38]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   o  CDNI Logging Interface - Report the authorization method used to
      validate the request for content delivery

   Advantages/Drawbacks:

   +  Manifest file and chunks are protected

   +  CSP does not need to change the manifest files

   -  Requires full HAS awareness on part of Upstream CDN and Downstream
      CDN

   -  Requires CDNI Interfaces extensions

   -  Requires CDN to generate or rewrite the manifest file

   -  Manifest file has to be delivered by surrogate

3.5.9.  URL Signing Options Analysis

   Summary:

   "Do nothing" (#1) approach requires no change to CSP or CDN but is
   not acceptable because of the lack of protection for the content.
   "Flexible URL Signing" (#2) approach requires flexible URL Signing
   support in CDN and depends on CSP (#2A) or Upstream CDN (#2B) to be
   involved in every HAS session.  "Authorization Group ID and HTTP
   Cookie" (#3) approach requires new CDNI metadata to associate the URL
   Signing with HTTP cookie to validate a request for content in the
   logical group.  "HAS-awareness in CDN" (#4) requires CDN to be aware
   of HAS content and to support HAS with the use of HTTP cookie (#4A)
   or manifest manipulation (#4B).

   Recommendations:

   Flexible URL Signing by CSP (#2A) or Upstream CDN (#2B) is
   recommended because the approach protects all the content, does not
   require Downstream CDN to be aware of HAS, does not impact CDNI
   interfaces, supports all different types of devices, and supports 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 URL).  The requirement for Upstream CDN to manipulate
   the manifest file is not considered to be a significant obstacle for
   deployment as long as the Downstream CDN remains unaware of HAS.

   (FUTURE) HAS-awareness in CDN (#4) has some advantages that should be
   considered for future support (e.g.  CDN that is aware of HAS content
   can manage the content more efficiently at a broader context.

van Brandenburg, et al.  Expires January 13, 2013              [Page 39]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   Content distribution, storage, delivery, deletion, access
   authorization, etc. can all benefit.)

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 which it
   wants to remove (e.g. in the form of a URL).  Due to the fact that
   HAS content consists of large groups of files however, things might
   be more complex.  Section 3.1 describes a number of different
   scenarios for doing file management on these groups of files, while
   Section 3.2 list the options for performing Content Acquisition on
   these Content Collections.  This section will present the options for
   requesting a Content Purge for the removal of a Content Collection
   from a dCDN.

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 a large signalling
   overhead between the uCDN and dCDN.

   Effect on CDN Interfaces:

   o  None

   Advantages/Drawbacks (apart from those listed under Option 3.3):

   +  Does not require changes to the CDNI Interfaces or HAS awareness

   -  Requires individual purge request for every file making up a
      Content Collection which creates large signalling 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 purge identifiers in the metadata of a particular file, it
   is possible to virtually group together different files making up a
   Content Collection.  A purge identifier can take the form of a random
   number which is communicated as part of the CDNI Metadata Interface
   and which is the same for all files making up a particular Content
   Item.  If a uCDN wants to request the dCDN to remove a Content
   Collection, it can send a purge request containing this purge

van Brandenburg, et al.  Expires January 13, 2013              [Page 40]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   identifier.  The dCDN can then remove all files that contain the
   shared identifier.

   The advantage of this method is that it is relatively simple to use
   by both the dCDN and uCDN and requiring only limited additions to the
   CDNI Metadata Interface and CDNI Control Interface.

   [Editor's Note: Could the Purge Identifier introduced in this section
   be related to the Content Collection Identifier introduced in
   Section 3.4.2.2?  Chould they be the same identifier?]

   Effect on CDN Interfaces:

   o  CDNI Metadata Interface: Add metadata field for indicating Purge
      Identifier

   o  CDNI Control Interface: Add functionality to be able to send
      content purge requests containing Purge Identifiers

   Advantages/Drawbacks:

   +  Allows for efficient purging of content from a dCDN

   +  Does not require HAS awareness on part of dCDN

3.7.  Other issues

   This section includes some HAS-specific issues that came up during
   the discussion of this draft and which do not fall under any of the
   categories discussed in the previous sections.

   -  As described in Section 2.2, a manifest file might either be
      delivered by a CDN or by the CSP, thereby being invisible to the
      CDN delivering the chunks.  Obviously, the decision on whether the
      CDN or CSP delivers the manifest 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 around 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.  IANA Considerations

   This document makes no request of IANA.

van Brandenburg, et al.  Expires January 13, 2013              [Page 41]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

5.  Security Considerations

   TBD.

6.  Acknowledgements

   The authors would like to thank Kevin J. Ma, Stef van der Ziel, and
   Bhaskar Bhupalam for their valuable contributions to this draft.

7.  References

7.1.  Normative References

   [I-D.ietf-cdni-problem-statement]
              Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement, draft-ietf-cdni-problem-statement-03",
              January 2012.

   [I-D.ietf-cdni-use-cases]
              Bertrand, G., Ed., Stephan, E., Watson, G., Burbridge, T.,
              Eardley, P., and K. Ma, "Use Cases for Content Delivery
              Network Interconnection, draft-ietf-cdni-use-cases-03",
              January 2012.

7.2.  Informative References

   [I-D.draft-bertrand-cdni-logging]
              Bertrand, G., Ed. and E. Stephan, "CDNI Logging
              Interface".

   [I-D.draft-ietf-cdni-requirements]
              Leung, K. and Y. Lee, "Content Distribution Network
              Interconnection (CDNI) Requirements,
              draft-ietf-cdni-requirements-03", June 2012.

   [I-D.draft-lefaucheur-cdni-logging-delivery]
              Le Faucheur, F., Viveganandhan, M., and K. Leung, "CDNI
              Logging Formats for HTTP and HTTP Adaptive Streaming
              Deliveries".

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform

van Brandenburg, et al.  Expires January 13, 2013              [Page 42]
Internet-Draft      HTTP Adaptive streaming and CDNI           July 2012

              Resource Identifier (URI): Generic Syntax, RFC3986",
              January 2005.

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
   Greenside, 400 Avenue de Roumanille
   Sophia Antipolis  06410
   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.  Expires January 13, 2013              [Page 43]