wdiff rfc6983.original rfc6983.txt

Network Working Group
Independent Submission R. van Brandenburg
Internet-Draft
Request for Comments: 6983 O. van Deventer
Intended status:
Category: Informational TNO
Expires: October 14, 2013
ISSN: 2070-1721 F. Le Faucheur
K. Leung
Cisco Systems
April 12,
July 2013

Models for adaptive-streaming-aware CDN HTTP-Adaptive-Streaming-Aware
Content Distribution Network Interconnection
draft-brandenburg-cdni-has-05 (CDNI)

Abstract

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

Status of This Memo

This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
published for informational purposes.

This is a contribution to the
provisions RFC Series, independently of BCP 78 any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and BCP 79.

Internet-Drafts makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are working documents not a candidate for any level of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list
Standard; see Section 2 of RFC 5741.

Information about the current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 October 14, 2013.
http://www.rfc-editor.org/info/rfc6983.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 ....................................................4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 ................................................5
2. HTTP Adaptive Streaming aspects relevant Aspects Relevant to CDNI . . . . . . 5 ................6
2.1. Segmentation versus Fragmentation . . . . . . . . . . . . 5 ..........................6
2.2. Addressing chunks . . . . . . . . . . . . . . . . . . . . 6 Chunks ..........................................7
2.2.1. Relative URLs . . . . . . . . . . . . . . . . . . . . 7 .......................................8
2.2.2. Absolute URLs with Redirection . . . . . . . . . . . 8 ......................9
2.2.3. Absolute URL URLs without Redirection . . . . . . . . . . 9 ..................10
2.3. Live vs. Content versus VoD . . . . . . . . . . . . . . . . . . . . . . 10 Content ...........................11
2.4. Stream splicing . . . . . . . . . . . . . . . . . . . . . 11 Splicing ...........................................12
3. Possible HAS Optimizations . . . . . . . . . . . . . . . . . 11 .....................................12
3.1. File Management and Content Collections . . . . . . . . . 12 ...................13
3.1.1. General Remarks . . . . . . . . . . . . . . . . . . . 12 ....................................13
3.1.2. Candidate approaches . . . . . . . . . . . . . . . . 12 Approaches ...............................13
3.1.2.1. Option 1.1: No HAS awareness . . . . . . . . . . 12 Do Nothing ....................13
3.1.2.2. Option 1.2: Allow single file storage Single-File
Storage of
fragmented content . . . . . . . . . . . . . . . 13 Fragmented Content .............14
3.1.2.3. Option 1.3: Access correlation hint . . . . . . . 14 Correlation Hint .......14
3.1.3. Recommendation . . . . . . . . . . . . . . . . . . . 14 Recommendations ....................................15
3.2. Content Acquisition of Content Collections . . . . . . . 14 ................15
3.2.1. General Remarks . . . . . . . . . . . . . . . . . . . 14 ....................................15
3.2.2. Candidate Approaches . . . . . . . . . . . . . . . . 15 ...............................16
3.2.2.1. Option 2.1: No HAS awareness . . . . . . . . . . 15 Awareness ..............16
3.2.2.2. Option 2.2: Allow single file acquisition Single-File
Acquisition of
fragmented content . . . . . . . . . . . . . . . 16 Fragmented Content .........17
3.2.3. Recommendation . . . . . . . . . . . . . . . . . . . 16 Recommendations ....................................17
3.3. Request Routing of HAS content . . . . . . . . . . . . . 17 Content ............................17
3.3.1. General remarks . . . . . . . . . . . . . . . . . . . 17 Remarks ....................................17
3.3.2. Candidate approaches . . . . . . . . . . . . . . . . 17 Approaches ...............................18
3.3.2.1. Option 3.1: No HAS awareness . . . . . . . . . . 17 Awareness ..............18
3.3.2.2. Option 3.2: Manifest File rewriting Rewriting
by uCDN . . . 19 ...................................20
3.3.2.3. Option 3.3: Two-step Two-Step Manifest File rewriting . . 20
Rewriting .................................21
3.3.3. Recommendation . . . . . . . . . . . . . . . . . . . 22 Recommendations ....................................22
3.4. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 22 ...................................................23
3.4.1. General remarks . . . . . . . . . . . . . . . . . . . 22 Remarks ....................................23
3.4.2. Candidate Approaches . . . . . . . . . . . . . . . . 23 ...............................24
3.4.2.1. Option 4.1: "Do-Nothing" Approach . . . . . . . . 23 Do Nothing ....................24
3.4.2.2. Option 4.2: "CDNI CDNI Metadata Content
Collection ID"
Approach . . . . . . . . . . . . . . . . . . . . 25 ID .............................26
3.4.2.3. Option 4.3: "CDNI CDNI Logging Interface Compression"
Approach . . . . . . . . . . . . . . . . . . . . 26
Compression ...............................28
3.4.2.4. Option 4.4: "Full Full HAS awareness/per-Session-Logs"
Approach . . . . . . . . . . . . . . . . . . . . 27
Awareness/Per-Session Logs ................29
3.4.3. Recommendation . . . . . . . . . . . . . . . . . . . 28 Recommendations ....................................30
3.5. URL Signing . . . . . . . . . . . . . . . . . . . . . . . 30 ...............................................32
3.5.1. HAS Implications . . . . . . . . . . . . . . . . . . 30 ...................................32
3.5.2. CDNI Considerations . . . . . . . . . . . . . . . . . 31 ................................33
3.5.3. Option 5.1: Do Nothing . . . . . . . . . . . . . . . 32 .............................34
3.5.4. Option 5.2: Flexible URL Signing by CSP . . . . . . . 32 ............34
3.5.5. Option 5.3: Flexible URL Signing by Upstream CDN . . 35 uCDN ...........37
3.5.6. Option 5.4: Authorization Group ID and HTTP
Cookie . . . . . . . . . . . . . . . . . . . . . . . 35 .............................................37
3.5.7. Option 5.5: HAS-awareness HAS Awareness with HTTP Cookie in CDN . . 36 ..38
3.5.8. Option 5.6: HAS-awareness HAS Awareness with Manifest
File in CDN . . . 38 ........................................40
3.5.9. Recommendation . . . . . . . . . . . . . . . . . . . 38 Recommendations ....................................41
3.6. Content Purge . . . . . . . . . . . . . . . . . . . . . . 39 .............................................41
3.6.1. Option 6.1: No HAS awareness . . . . . . . . . . . . 40 Awareness .......................42
3.6.2. Option 6.2: Purge Identifiers . . . . . . . . . . . . 40 ......................42
3.6.3. Recommendation . . . . . . . . . . . . . . . . . . . 41 Recommendations ....................................43
3.7. Other issues . . . . . . . . . . . . . . . . . . . . . . 41 Issues ..............................................43
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
5. Security Considerations . . . . . . . . . . . . . . . . . . . 41
6. ........................................43
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
7. ...............................................44
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.1. .....................................................44
6.1. Normative References . . . . . . . . . . . . . . . . . . 42
7.2. ......................................44
6.2. Informative References . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 ....................................44

1. Introduction

[RFC6707] defines the problem space for CDN Content Distribution Network
Interconnection (CDNI) and the associated CDNI interfaces. This
includes support, through interconnected CDNs, Content Delivery Networks
(CDNs), of content delivery to endusers End Users using HTTP progressive
download and HTTP Adaptive Streaming (HAS).

HTTP Adaptive Streaming is an umbrella term for various HTTP-based
streaming technologies that allow a client to adaptively switch
between multiple bitrates 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,
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 the Real-time Transport Protocol / Real Time
Streaming Protocol (RTP/RTSP), the Real Time Messaging Protocol
(RTMP), and MMS. the Multimedia Messaging Service (MMS).

This document presents a discussion on what of the impact of these
different characteristics is to the HAS
operation on the CDNI interfaces interfaces, and what HAS-
specific HAS-specific optimizations
may be required or may be desirable. The scope of this document is
to present the authors' analysis of the CDNI-HAS problem space and
discuss different options put forward both by the authors (and by others
during informal discussions) on how to deal with HAS in the context
of CDNI. The documents document concludes by presenting the authors'
recommendations on how the CDNI WG should deal with HAS in its
initial charter, with a focus on 'making it work' instead of
including 'nice-to-have' optimizations that might delay the
development of the CDNI WG deliverables identified in its initial
charter.

It should be noted that the document is not a WG document, document but has
been used as input information during the WG process for making its decision
regarding support for HAS. We expect the analysis presented in the
document will also to be useful in the future if and when the WG
re-charters recharters and
wants to re-assess reassess the level of HAS optimizations to be supported in
CDNI scenarios.

1.1. Terminology

This document uses the terminology defined in [RFC6707] and
[I-D.ietf-cdni-framework].
[CDNI-FRAMEWORK].

For convenience, the definition definitions of HAS-related terms are restated
here:

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

Chunk: a fixed length 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. chunk collection.

Segment: A specific form of chunk (see Section 2.1). A segment is
stored as a single file from a file system file-system perspective.

Original Content: Non-chunked content that is the basis for a
segmentation of or fragmentation operation. Based on Original
Content, multiple alternative representations (using different
encoding methods, supporting different resolutions resolutions, and/or
targeting different bitrates) may be derived, each of which may be
fragmented or segmented.

Chunk Collection: The set of all chunks that are the result of a
single segmentation or fragmentation operation being performed on
a single representation of the Original Content. A Chunk Collection chunk
collection is described in a Manifest File.

Content Collection: The set of all Chunk Collections chunk collections that are
derived from the same Original Content. A Content Collection content collection may
consist of multiple Chunk Collections, chunk collections, each corresponding to a
single representation of the Original Content. A Content Collection content
collection may be described by one or more Manifest Files.

Manifest File: A Manifest File, also referred to as a Media
Presentation Description (MPD) file, is a file that list lists the way
the content has been chunked (possibly for multiple encodings) and encodings), as
well as where the various chunks are located (in the case of
segments) or how they can be addressed (in the case of fragments).

2. HTTP Adaptive Streaming aspects relevant Aspects Relevant to CDNI

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

2.1. Segmentation versus Fragmentation

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

While every HAS implementation uses some form of chunking, not all
implementations store the resulting chunks in the same way. In
general, there are two distinct methods of performing chunking and
storing the results: segmentation and fragmentation.

- With segmentation, segmentation -- which is is, for example example, mandatory in all
versions of Apple's HLS prior to version 7, 7 -- the chunks, in this
case also referred to as segments, are stored completely independent
independently from each other, with each segment being stored as a
separate file from a file system file-system perspective. This means that
each segment has its own unique URL with which it can be
retrieved.

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

While one can argue about the merits of each of these two different
methods of handling chunks, both have their advantages and drawbacks
in a CDN environment. For example, fragmentation is often regarded
as a method that introduces less overhead, both from both a storage and
processing perspective. Segmentation 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 Chunks

In order for a client to request chunks, either in the form of either
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 a Media Presentation Description, or
MPD); i.e. 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, File or set of
Manifest Files, Files may also identify the different representations, and
thus Chunk Collections, chunk collections, available for a the content.

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

Of course 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, that, at each instant in time, do know at
which servers each file resides. The CDNI interfaces designed in by the
CDNI WG will probably need to be agnostic to these kinds of CDN-
internal architecture decisions. In the case of HAS 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 Sections 2.2.1 to 2.2.3.

Although these sections are especially relevant for segmented
content, 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 only to temporally
segmented content (e.g. (e.g., segments and fragments), fragments) but are also
relevant in situations where content is made available in multiple
representations (e.g., in different qualities, encoding methods, resolutions
resolutions, and/or bitrates). In this case 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. locations also apply.

One final note relates to the delivery of the Manifest Files
themselves. While in most situations the delivery of both the
Manifest File and the chunks are is handled by the CDN, there are
scenarios imaginable in which the Manifest File is delivered by e.g. by, for
example, the Content Provider, Service Provider (CSP), and the Manifest File is
therefore not visible to the CDN.

2.2.1. Relative URLs

One method for specifying chunk locations in a Manifest File is
through the use of relative URLs. A relative URL is a URL that does
not include the HOST part of a URL but only includes (part of) the
PATH part of a URL. In practice, a relative URL is used by the
client as being relative to the location where from which the Manifest File
has been acquired from. acquired. In these cases cases, a relative URL will take the form
of a string that has to be appended to the location of the Manifest
File to get the location of a specific chunk. This means that in the
case where a Manifest File with relative URLs is used, all chunks
will be delivered by the same surrogate Surrogate that delivered the Manifest
File. A relative URL will therefore not include a hostname.

For example, in the case where a Manifest File has been requested
(and received) from:

http://surrogate.server.cdn.example.com/content_1/manifest.xml

a relative URL pointing to a specific segment referenced in the
Manifest File might be:

segments/segment1_1.ts

Which

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
content_1/segments/segment1_1.ts.

One drawback of using relative URLs is that it forces a CDN relying
on HTTP-based request routing to deliver all segments belonging to a
given content item with the same
surrogate Surrogate that delivered the
Manifest File for that content item, which results in limited
flexibility. Another drawback is that
Relative relative URLs do not allow for
fallback URLs; should the surrogate 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 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. (i.e., the client does not
have to calculate the URL as in the case of the relative URL but can
use the URL from the Manifest File directly).

In the context of Manifest Files, there are two types of absolute
URLs imaginable: Absolute absolute URLs with Redirection redirection and Absolute absolute URLs
without Redirection. redirection. The two methods differ in whether the URL
points to a request routing node which that will redirect the client to a
surrogate (Absolute URL
Surrogate (absolute URLs with Redirection) redirection) or point directly to a
surrogate
Surrogate hosting the requested content (Absolute URL (absolute URLs without
Redirection).
redirection).

In the case of Absolute absolute URLs with Redirection, redirection, a request for a chunk
is handled by the request routing Request Routing system of a CDN just as if it were
a standalone (non-HAS) content request, which might include looking
up the surrogate 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 Surrogate (and/or CDN), or a DNS response pointing to the
specific surrogate. Surrogate.

An example of an Absolute absolute URL with Redirection 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 Request Routing function and includes some arguments identifying
the requested segment.

The advantage of using Absolute absolute URLs with Redirection redirection is that it
allows they
allow for maximum flexibility (since chunks can be distributed across surrogates
Surrogates and CDN CDNs in any imaginable way) without having to modify
the Manifest File every time one or more chunks are moved (as is the
case when Absolute absolute URLs without Redirection redirection are used). The downside
of this method is that it can adds add significant load to a CDN
request routing Request
Routing system, since it has to perform a redirect every time a
client requests a new chunk.

2.2.3. Absolute URL URLs without Redirection

In the case of the Absolute URL absolute URLs without Redirection, redirection, the URL points
directly to the specific chunk on the actual surrogate 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. Surrogate.

An example of an Absolute URLs absolute URL without Redirection redirection is the following:

http://surrogate.cdn.example.com/content_1/segments/segment1_1.ts

http://surrogate1.cdn.example.com/content_1/segments/segment1_1.ts

As can be seen from this example URL, the URL includes both the
identifier of the requested segment (in this case segment1_1.ts), as
well as segment1_1.ts) and
the server that is expected to deliver the segment (in this case surrogate.cdn.example.com).
surrogate1.cdn.example.com). With this, the client has enough
information to directly request the specific segment from the
specified surrogate. Surrogate.

The advantage of using Absolute absolute URLs without Redirection redirection is that it
allows more flexibility compared to using Relative 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
this method is that it requires a modification of the Manifest File
every time content is moved to a different location (either within a
CDN or across CDNs).

2.3. Live vs. Content versus VoD Content

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

- With live content, chunk files are made available in real-time. real time.
This limits the applicability of bundling for content acquisition
purposes. Prepositioning Pre-positioning may still be employed, employed; however, any
significant latency in the prepositioning pre-positioning may diminish the value
of prepositioning pre-positioning if a client requests the chunk prior to
prepositioning,
pre-positioning or if the prepositioning pre-positioning 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-File based optimization schemes based on Manifest
Files must therefore be prepared to optimize on a per-segment
request basis. Manifest Files may also be polled multiple times
prior to the actual availability of the next chunk.

- Since live Manifest Files are updated as each new chunk becomes chunks become
available, the cacheability of Manifest Files is limited. Though
timestamping and reasonable TTLs Time-to-Live (TTL) settings can
improve delivery performance, timely replication and delivery of
updated Manifest Files is are critical to ensuring uninterrupted
playback.

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

2.4. Stream splicing 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 that contain Absolute absolute URLs with
redirection may contain chunk or nested Manifest File URLs which that point
to content not delivered via any of the interconnected CDNs.

Furthermore, client and downstream proxy devices may depend on non-
URL
non-URL information provided in the Manifest File (e.g., comments or
custom tags) for performing stream splicing. This often occurs
outside the scope of the interconnected CDNs. HAS optimization
schemes which that employ dynamic Manifest File generation or rewriting
must be cognizant of chunk URLs, nested Manifest File URLs, and other
metadata which that should not be modified or removed. Improper
modification of these URLs or other metadata may cause playback
interruptions,
interruptions and in the case of unplayed advertisements, advertisements may result
in loss of revenue for content providers. CSPs.

3. Possible HAS Optimizations

In the previous chapter, section, some of the unique properties of HAS have
been were
discussed. Furthermore, some of the CDN-specific design decisions
with regards to addressing chunks have been detailed. In this chapter,
section, the impact of supporting HAS in CDN Interconnection CDNI scenarios will be is discussed.

There are a number of topics, or problem areas, that are of
particular interest when considering the combination of HAS and CDNI.
For each of these problem areas areas, it holds that there are a number of
different ways in which the CDNI Interfaces interfaces can deal with them. In
general
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 interfaces or in way that maximizes the flexibility and efficiency with
which the CDNI Interfaces 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 section briefly describe
describes each of the following problem areas areas, together with a number
of different options for dealing with them. Section 3.1 will
discuss discusses
the problem of how to deal with file management of groups of files,
or Content Collections. content collections. Section 3.2 will deal deals with a related topic: how
to do content acquisition of Content Collections content collections between the uCDN Upstream
CDN (uCDN) and dCDN. Downstream CDN (dCDN). After that, Section 3.3
describes the various options for the request routing of HAS content,
particularly related to Manifest Files. Section 3.4 talks about a
number of possible optimizations for the logging of HAS content,
while Section 3.5 discusses the options regarding URL signing.
Finally, 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
(segments, fragments, and/or Manifest Files). In this document document, this
group of files is also referred to as a Content Collection. 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 content collections differently from a file
management perspective. For example, some CDNs might handle all
files belonging to a Content Collection content collection as individual files, which files that are
stored independently from each other. An advantage of this approach
is that it makes it easy to cache individual chunks. Other CDNs
might store all fragments belonging to a Content Collection content collection in a
bundle, as if they were a single file (e.g. (e.g., by using a fragmented
MP4 container). The advantage of this approach is that it reduces
file management overhead.

This section will

The following subsections look at the various ways with which the
CDNI interfaces might deal with these differences in handling Content
Collections content
collections from a file management perspective. The different
options can be distinguished based on the level of HAS-awareness HAS awareness they
require on the part of the different CDNs and the CDNI interfaces.

3.1.2. Candidate approaches Approaches

3.1.2.1. Option 1.1: No HAS awareness Do Nothing

This first option assumes no HAS awareness in both the involved CDNs and
the CDNI Interfaces. interfaces. This means that the uCDN uses individual
files files,
and the dCDN is not explicitly made aware of the relationship between
chunks and it doesn't know which files are part of the same
Content Collection. content
collection. In practice 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 mechanism, which
can be used 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 contain
byte range requests, in which case the dCDN might be able to acquire
fragmented content as a single file (see Section 3.2.2.2).

Effect on CDNI interfaces:

o None

Advantages/Drawbacks:

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

- The dCDN is forced to store chunks as individual files. files

3.1.2.2. Option 1.2: Allow single file storage Single-File Storage of fragmented content Fragmented Content

In some cases, the dCDN might prefer to store fragmented content as a
single file on its surrogates 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), 3.2.2.2) or to merge the different chunks
together and place them in the same container (e.g. (e.g., fragmented MP4).
The downside of this method is that in order to do so, the dCDN needs
to be fully HAS aware.

Effect on CDNI interfaces:

o CDNI Metadata Interface: interface: Add fields for indicating the particular
type of HAS (e.g. (e.g., MPEG DASH or HLS) that is used and whether
segments or fragments are used

o CDNI Metadata Interface: interface: Add field for indicating the name and
type of the Manifest File(s)

Advantages/Drawbacks:

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

- Complex operation, requiring the dCDN to be fully HAS aware

3.1.2.3. Option 1.3: Access correlation hint Correlation Hint

An intermediary approach between the two extremes detailed in the
previous two sections is one that uses a an 'Access Correlation Hint'.
This hint, which is added to the CDNI Metadata of all chunks of a
particular Content Collection, 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. (e.g., by bundling all files with the
same Access Correlation Hint value in a single bundle/file), thereby
reducing the number of files it has to manage while not requiring any
HAS awareness.

Effect on CDNI interfaces:

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

Advantages/Drawbacks:

+ Allows the dCDN to perform file management optimization

+ Does not require any HAS awareness

+ Very small impact on CDNI Interfaces interfaces

- Expected benefit compared with Option 1.1 is small

3.1.3. Recommendation Recommendations

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

3.2. Content Acquisition of Content Collections

3.2.1. General Remarks

In the previous section section, the relationship between file management and
HAS in a CDNI scenario has been was discussed. This section will discuss discusses a
related topic, which is topic: content acquisition between two CDNs.

With regards to content acquisition, it is important to note the
difference between CDNs that do Dynamic Acquisition dynamic acquisition of content and
CDNs that perform Content Pre-positioning. content pre-positioning. In the case of dynamic
acquisition, a CDN only requests a particular content item when a
cache-miss
cache miss occurs. In the case of pre-positioning, a CDN pro-
actively proactively
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 given chunk occurs, that node might not only acquire the
requested chunk, 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 Awareness

This first option assumes no HAS awareness in both the involved CDNs and
the CDNI Interfaces. interfaces. Just as with Option 1.1 1.1, discussed in the
previous section earlier with
regards to file management, having no HAS awareness means that the
dCDN is not aware of the relationship between chunks. In the case of
content acquisition, this means that each and every file belonging to
a Content Collection 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 that contain byte range
requests. In this case 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, 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 uCDN, compared
to a method in which entire Content Collections content collections can be acquired as
part of one transaction.

Effect on CDNI interfaces:

o None

Advantages/Drawbacks:

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

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

3.2.2.2. Option 2.2: Allow single file acquisition Single-File Acquisition of fragmented
content Fragmented
Content

As discussed in Section 3.2.2.1, there is one (fairly rare) case
where fragmented content can be acquired as a single file without any
HAS awareness awareness, and that is when fragmented content is used and where
the Manifest File specifies byte range request. requests. This section
discusses how to perform single file single-file acquisition in the other (very
common) cases. To do so, the dCDN would have to have full-HAS full HAS
awareness (at least to the extent of being able to map between a
single file and individual chunks to serve).

Effect on CDNI interfaces:

o CDNI Metadata Interface: interface: Add fields for indicating the particular
type of HAS (e.g. (e.g., MPEG DASH or HLS) that is used and whether
segments or fragments are used

o CDNI Metadata Interface: 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 the part of the dCDN

- Requires significant CDNI Metadata Interface interface extensions

3.2.3. Recommendation Recommendations

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

3.3. Request Routing of HAS content Content

3.3.1. General remarks Remarks

In this section section, the effect HAS content has on request routing will be is
identified. Of particular interest in this case are the different
types of Manifest Files that might be used. In Section 2.2, three
different methods for identifying and addressing chunks from within a
Manifest File were described: Relative relative URLs, Absolute absolute URLs without
Redirection with
redirection, and Absolute absolute URLs with Redirection. without redirection. Of course 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 chunk-addressing method is used
is the Content Provider. CSP. Some Content Providers CSPs may have a strong preference for a particular
method and deliver the Manifest Files to the CDN in a particular way.
Depending on the CDN and the agreement it has with the Content Provider, CSP, a CDN may
either host the Manifest Files as they were created by the Content Provider, CSP or
modify the Manifest File to adapt it to its particular architecture (e.g.
(e.g., by changing relative URLs to Absolute absolute URLs which that point to the
CDN Request Routing function).

3.3.2. Candidate approaches Approaches

3.3.2.1. Option 3.1: No HAS awareness Awareness

This first option assumes no HAS awareness in both the involved CDNs and
the CDNI Interfaces. interfaces. This scenario also assumes that neither the
dCDN nor the uCDN have has the ability to actively manipulate Manifest
Files. As was also discussed with regards to file management and
content acquisition, having no HAS awareness means that each file
constituting a Content Collections content collection is handled on an individual basis,
with the dCDN unaware of any relationship between files.

The only chunk addressing chunk-addressing method that works without question in this
case is Absolute absolute URLs with Redirection. redirection. In other words, the Content
Provider CSP that
ingested the content into the uCDN created a Manifest File with each
chunk location pointing to the Request Routing function of the uCDN.
Alternatively, the Content Provider CSP may have ingested the Manifest File containing
relative URLs URLs, and the uCDN ingestion function has translated these
to Absolute absolute URLs pointing to the Request Routing function.

In this Absolute "absolute URL with Redirection 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 those
chunks to the dCDN. Depending on whether HTTP-based (recursive or
iterative) or DNS-based request routing is used, the uCDN Request
Routing function will then either directly or indirectly redirect the
client to the Request Routing function of the dCDN (assuming that it
does not have the necessary information to redirect the client
directly to a
surrogate 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 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/ Routing Redirection Interface
interface request/response). Even in the case where DNS-
based DNS-based
redirection is used, there might be significant overhead
involved involved,
since both the dCDN and uCDN Request Routing function functions might have to
perform database lookups and query each other. While with DNS this
overhead might be reduced by using DNS' DNS's inherent caching mechanism,
this will have significant impact on the accuracy of the redirect.

With no HAS awareness, Relative relative URLs might or might not work work,
depending on the type of Relative relative URL that is used. When a uCDN
delegates the delivery of a Manifest File containing Relative relative URLs to
a dCDN, the client goes directly to the dCDN surrogate Surrogate from which it
has received the Manifest File for every subsequent chunk. As long
as the Relative relative URL is not path-absolute (see [RFC3986]), this
approach will work fine.

Since using Absolute absolute URLs without Redirection redirection inherently require requires a
HAS aware
HAS-aware CDN, they also absolute URLs without redirection cannot be used in
this case. The reason for
this is that with Absolute URLs without Redirection, case because the URLs in the Manifest File will point directly
to a surrogate 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 Surrogate in the dCDN or to a request routing Request
Routing function.

Effect on CDNI interfaces:

o None

Advantages/Drawbacks:

+ Supports Absolute absolute URLs with Redirection redirection

+ Supports Relative relative URLs

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

- Not possible to use Absolute absolute URLs without Redirection redirection

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

3.3.2.2. Option 3.2: Manifest File rewriting Rewriting by uCDN

While Option 3.1 does allow for Absolute absolute URLs with Redirection redirection to be
used, it does so in a way that creates a high-level 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 awareness, the
client will go to the uCDN request routing Request Routing function for each chunk
request. This request routing Request Routing function can then redirect the client
to the dCDN request routing Request Routing function. By rewriting the Manifest File
(or generating a new one), the uCDN is able to remove this first
step, step
and have the Manifest File point directly to the dCDN request
routing Request Routing
function.

A key advantage of this solution is that it does not directly have an
impact on the CDNI Interfaces interfaces and is therefore transparent to these
interfaces. It is a CDN-internal function that a uCDN can perform
autonomously by using information configured for regular CDNI
operation or that is received from the dCDN as part of the regular
communication using the CDNI Request Routing/Redirection Interface. Routing Redirection interface.

More specifically, in order for the uCDN to rewrite the Manifest
File, the minimum information needed is the location of the dCDN
request routing
Request Routing function (or alternatively (or, alternatively, the location of the dCDN
delivering surrogate). Surrogate). This information can be available from
configuration or can be derived from the regular CDNI Request Routing
/Redirection Interface.
Redirection interface. For example, the uCDN may ask the dCDN for
the location of its request routing node (through the CDNI Request
Routing/Redirection Interface)
Routing Redirection interface) every time a request for a Manifest
File is received and processed by the uCDN request routing Request Routing function.
The uCDN would then modify the Manifest File and deliver the Manifest
File to the client. One advantage of this method is that it
maximizes efficiency and flexibility by allowing the dCDN to
optionally respond with the locations of its surrogates Surrogates instead of
the location of its request routing Request Routing function (and effectively turning
the URLs into Absolute absolute URLs without Redirection). redirection). There are many
variations around on this approach, such as where the modification of the
Manifest File in is only performed once (or once per period of time) by
the uCDN request routing Request Routing function, when the first client for that
particular Content Collection content collection (and redirected to that particular
dCDN) sends a Manifest File request. The advantage of such a
variation is that the uCDN only has to modify the Manifest File once
(or once per time period). The drawback of this variation is that
the dCDN is no longer in a position to influence the request routing
decision across individual content requests.

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

Effect on CDNI interfaces:

o None

Advantages/Drawbacks:

+ Possible to significantly decrease signaling overhead when using
Absolute URLs.
absolute URLs

+ (Optional) Possible to have the uCDN rewrite the Manifest File
with locations of surrogates Surrogates in the dCDN (turning Absolute absolute URLs
with
Redirection in Absolute redirection into absolute URLs without Redirection) redirection)

+ No changes to CDNI Interfaces interfaces

+ Does not require HAS awareness in the dCDN

- Requires a high level of HAS awareness in the uCDN (for modifying
Manifest Files)

3.3.2.3. Option 3.3: Two-step Two-Step Manifest File rewriting Rewriting

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

One method for solving this limitation is allowing two-step Manifest
File manipulation. In the first step step, the uCDN would perform its own
modification,
modification and place the locations of the dCDN request routing Request Routing
function in the Manifest File. Then, once a request for the Manifest
File comes in at the dCDN request routing 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. Surrogates. This way way, the dCDN can still
profit from having limited request routing traffic, traffic while not having
to share sensitive surrogate Surrogate information with the uCDN.

The downside of this approach is that it not only assumes HAS
awareness in the dCDN but it also requires some HAS-specific additions
to the CDNI Metadata Interface. 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. content collection.

Effect on CDNI interfaces (apart from those already listed under
Option 3.2):

o CDNI Metadata Interface: interface: Add necessary fields for conveying HAS HAS-
specific information (e.g. (e.g., the files that make up the Content
Collection) content
collection) to the dCDN. dCDN

o CDNI Metadata Interface: interface: Allow dCDN to modify Manifest File

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

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

- Requires a high level of HAS awareness in the dCDN (for modifying
Manifest Files)

- Requires adding HAS-specific and Manifest File manipulation manipulation-
specific information to the CDNI Metadata Interface interface

3.3.3. Recommendation Recommendations

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

As stated in [RFC6707], "the the CDNI Logging interface enables details of
logs or events to be exchanged between interconnected CDNs". CDNs.

As discussed in [I-D.draft-bertrand-cdni-logging], [CDNI-LOGGING], the CDNI logging information can be
used for multiple purposes purposes, including maintenance/
debugging maintenance/debugging by a
uCDN, accounting (e.g. in view of (e.g., for billing or
settlement), settlement purposes),
reporting and management of end-user experience (e.g. (e.g., to the CSP),
analytics (e.g. (e.g., by the CSP) CSP), and control of content distribution
policy enforcement (e.g. (e.g., by the CSP).

The key consideration for HAS with respect to logging is the
potential increase of the number of Log log records by two to three
orders of magnitude, as compared to regular HTTP delivery of a video,
since,
since by default, default log records would typically be generated on a per-
chunk-delivery
per-chunk-delivery basis instead of a per-content-item-delivery
basis. This impacts the scale of every processing step in the Logging
Process
logging process (see [I-D.draft-bertrand-cdni-logging]), [CDNI-LOGGING]), including:

a. Logging information generation and storing on CDN elements
(Surrogate, Request Routers, ...)

b. Logging information aggregation within a CDN

c. Logging information manipulation (including information
protection, filtering, update update, and rectification)

d. (Where needed) Logging information CDNI reformatting (e.g. of logging information (e.g.,
reformatting from a CDN-specific format to the CDNI Logging
Interface
interface format for export by the dCDN to the uCDN)

e. Logging exchange via the CDNI Logging Interface interface
f. (Where needed) Logging re-reformatting (e.g. (e.g., reformatting from
the CDNI Logging Interface interface format into a log-consuming specific
application)

g. Logging consumption/processing (e.g. (e.g., feed logs into uCDN
accounting application, feed logs into uCDN reporting system to
provide per CSP per-CSP views, feed logs into debugging tools)

Note that there may be multiple instances of step steps [f] and [g]
running in parallel.

While the CDNI Logging Interface interface is only used to perform step [e], we
note that its format directly affects step steps [d] and [f] and that its
format also indirectly affects the other steps (for example example, if the
CDNI Logging Interface interface requires per-chunk log records, step steps [a], [b]
[b], and [d] cannot operate on a per-HAS-session basis basis, and they also
need to operate on a per-chunk basis).

This section discusses the main candidate approaches identified for
CDNI in terms of dealing with HAS with respect to Logging. logging.

3.4.2. Candidate Approaches

3.4.2.1. Option 4.1: "Do-Nothing" Approach Do Nothing

In this approach approach, nothing is done specifically for HAS HAS, so that each
HAS-chunk delivery is considered, for CDNI Logging, logging, as a standalone
content delivery. In particular, a separate log record for each HAS-
chunk
HAS-chunk delivery is included in the CDNI Logging Interface interface in
step [e] (as defined in Section 3.4.1). This approach requires that step
steps [a], [b], [c], [d] [d], and [e] [f] also be performed on a per-chunk
basis. This approach allows step [g] to be performed either on a
per-chunk basis (assuming that step [f] maintains per-chunk records)
or on in a more "summarized" manner manner, such as per-HAS-Session on a per-HAS-session basis
(assuming that step [f] summarizes per-chunk records into per-HAS-session per-HAS-
session records).

Effect on CDNI interfaces:

o None

Advantages/Drawbacks:

+ No information loss (i.e. (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 log-consuming applications (e.g. (e.g., billing),
this full level of detail is likely valuable (possibly (and possibly
required) for some Log consuming log-consuming applications (e.g. (e.g., debugging)
+ Easier integration (at least in the short term) into existing
Logging tools
logging tools, since those tools are all capable of handling
per-chunk records

+ No extension needed on CDNI interfaces

- High volume of logging information to be handled (storing & and
processing) at every step of the Logging process logging process, from steps [a]
to [g] (while summarization in step [f] is conceivable, it may be
difficult to achieve in practice without any hints for correlation
in the log records). records)

An interesting question is whether a dCDN could use the CDNI Logging
interface specified for the "Do-Nothing" "do nothing" approach to report
summarized "per-session" log information in the case where the dCDN
performs such summarization. The high level high-level idea would be that, that when
a dCDN performs HAS log summarization summarization, for its own purposes anyways, anyway,
this dCDN could include, include in the CDNI Logging interface, interface one (or a
few) or more log entry
entries for a HAS session (instead of one entry per HAS-chunk) HAS chunk) that summarizes
summarize the deliveries of many/all HAS-chunk HAS chunks for a session.
However, the authors feel that, that when considering the details of this, this
idea, it is not achievable without explicit agreement between the
uCDN and dCDN about how to perform/interpret such summarization. For
example, when a HAS session switches between representations, the
uCDN and dCDN would have to agree on things such as:

o whether the session will be represented by a single log entry
(which therefore cannot convey the distribution across
representations)
representations), or multiple log entries 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 would correspond to? to
(for example, the Manifest/top-level-playlist/next-level-playlist,... Manifest File, top-level playlist, or next-level
playlist, ...)

The authors feel that since explicit agreement is needed between the
uCDN and dCDN on how to perform/interpret the summarization, then, to this
method can only work if it is specified as part of the CDNI Logging interface and
then
interface, in which case it would effectively boils boil down to Option 4.4 defined below ("Full
(full HAS
awareness/per-Session-Logs" Approach). awareness / per-session logs) as defined below.

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

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

In this approach, a "Content Collection IDentifier (CCID)" field is
distributed through the CDNI Metadata Interface interface, and the same CCID
value is associated through the CDNI Metadata interface with every
chunk of the same Content Collection. content collection. The CCID value needs to be
such that it allows, in combination with the content URI, to uniquely
identify unique
identification of a Content Collection. content collection. When the CCID is
distributed, and CCID logging is requested from the dCDN, the dCDN
Surrogates are to store the CCID value in the corresponding log
entries. The objective of this field is to facilitate optional
summarization of per-chunk records at step [f] into something along
the lines of per-HAS-session logs, at least for the Log consuming log-consuming
applications that do not require per-chunk detailed information (for example
example, billing).

We note that, that if the downstream CDN dCDN happens to have sufficient HAS awareness to
be able to generate a "Session IDentifier (Session-ID)", optionally
including such a Session-ID (in addition to the CCID) in the
per-chunk log record would further facilitate optional summarization
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 (i.e., delivery of the
same content to the same enduser End User at a given point in time).

o log records for different chunks of the same user session (i.e (i.e.,
delivery of the same content to the same enduser End User at a given point
in time) should be provided with the same session-ID Session-ID value. While
undesirable, there may be situations where the delivering CDN uses
more than one session-ID Session-ID value for different per-chunk log records
of a given session, session -- for example example, in scenarios of fail-over or load-
load balancing across multiple Surrogates and where the delivering
CDN does not implement mechanisms to synchronize session-IDs Session-IDs
across Surrogates.

Effect on CDNI interfaces:

o CDNI Metadata interface: One additional metadata field (CCID) in
the CDNI Metadata Interface. interface. We note that a similar Content
Collection content
collection ID is discussed for the handling of other aspects of
HAS and observe that further thought is needed to determine
whether such a CCID should be shared for multiple purposes or
should be independent.

o CDNI Logging interface: Two additional fields (CCID and Session-
ID)
Session-ID) in CDNI Logging logging records.

Advantages/Drawbacks:

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

+ Very minor extension to CDNI interfaces needed

+ Facilitated summarization of records related to a HAS session in
step [f] and therefore ability to operate on a lower volume of
logging information in step [g] by log consuming log-consuming applications that
do not need per-chunk record details (e.g. (e.g., billing) or that need
per-session information (e.g. (e.g., analytics)

- High volume of logging information to be handled (storing & and
processing) at every step of the Logging process logging process, from steps [a]
to [f]. [f]

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

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

Effect on CDNI interfaces:

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

Advantages/Drawbacks:

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

+ Small extension to CDNI interfaces needed

+ Reduced volume of logging information in step [e]

+ Compression likely to be also be applicable to logs for non-HAS
content

- High volume of logging information to be handled (storing & and
processing) at every step of the Logging process logging process, from steps [a]
to [g], except step [e].

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

In this approach, HAS-awareness HAS awareness is assumed across the CDNs
interconnected via CDNI CDNI, and the necessary information to describe
the HAS relationship across all chunks of the same Content Collection content collection
is distributed through the CDNI Metadata Interface. interface. In this
approach, the dCDN Surrogates leverage leverages the HAS information distributed through
the CDNI metadata Metadata and their HAS-awareness HAS awareness, to do one of the
following:

o directly generate summarized logging information in the very first place (or alternatively, if
per-chunk-logs are generated, to accurately correlate and summarize
per-chunk-logs into per-session logs) for exchange over at logging
information generation time (which has the CDNI
Logging interface. The objective benefit of that approach is to operate operating on
a lower volume of logging information as early as possible in the
successive steps of the logging process), or

o (if per-chunk logs are generated) accurately correlate and
summarize per-chunk logs into per-session logs for exchange over
the CDNI Logging process. interface

Effect on CDNI interfaces:

o CDNI Metadata Interface: significant interface: Significant extension to convey HAS
relationship across chunks of a Content Collection. content collection. Note that
this extension requires specific support for every HAS-protocol HAS protocol to
be supported over the CDNI mesh

o CDNI Logging Interface: extension interface: Extension to specify summarized per-
session logs

Advantages/Drawbacks:

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

+ Accurate generation of summarized logs because of HAS awareness in
the dCDN (for example, where the Surrogate is also serving the
Manifest File(s) for a content collection, the Surrogate may be
able to extract definitive information about the relationship
between all chunks)

- Very significant extensions to CDNI interfaces needed needed, including
per HAS-protocol
specific support for available HAS protocols

- Very significant additional requirement for HAS awareness on the
dCDN and for this HAS-awareness HAS awareness to be consistent with the defined
CDNI
Logging logging summarization
- Some information loss (i.e. (i.e., all details of each individual chunk
delivery are not preserved). The actual information loss depends
on the summarization approach selected (typically (typically, the lower the
information loss, the lower the summarization gain) gain), so the right
sweet-spot
"sweet spot" would have to be selected. While a full level of
detail may not be needed for some Log consuming log-consuming applications (e.g.
(e.g., billing), the such a full level of detail is likely valuable (possibly
(and possibly required) for some Log consuming log-consuming applications (e.g. (e.g.,
debugging)

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

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

3.4.3. Recommendation Recommendations

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

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

The authors also recommend that: that

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

(ii) the ability for of the dCDN to include the CCID field and Session-
ID Session-ID
fields in CDNI log entries (when the dCDN is capable of doing
so) and
indicate so inside be indicated in the CDNI Logging interface (in line with
the "customizable" log format expected to be defined
independently of
HAS), HAS)
(iii) items (i) and (ii) be supported as a "Medium Priority" (as
defined in
[I-D.draft-ietf-cdni-requirements]) [CDNI-REQUIREMENTS]) and be an optional capability
of CDNs implementing CDNI. CDNI

When performing dCDN selection, an a uCDN may want to take into account
whether a given dCDN is capable of reporting the CCID and Session-ID.
Thus, the authors recommend that the ability for of a dCDN to advertise
its support of the optional CCID and Session-ID capability be
supported by the CDNI request Routing /Footprint and Footprint & Capabilities
Advertisment Interface Advertisement
interface as a "Medium Priority" (as defined in
[I-D.draft-ietf-cdni-requirements]). [CDNI-REQUIREMENTS]).

The authors also recommend that a generic mechanism (independent of
HAS) be supported allowing that allows the customization of the fields to be
reported in logs by CDNs over the CDNI Logging Interface interface -- because
of the reduction of the logging information volume exchanged across
CDNs that it allows by removing the information that is not of interest
to the other CDN.

Because it the following can be achieved with very little complexity and it
provides
can provide some clear storage/communication compression benefits,
the authors recommend that, in line with the concept of Option 4.3,
some existing very common compression techniques (e.g. (e.g., gzip) be
supported by the CDNI Logging interface as a "Medium Priority" (as
defined in
[I-D.draft-ietf-cdni-requirements]) [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 approaches, and the time it
would take to specify the corresponding support in the CDNI Logging
interface, the authors recommend that the log summarization discussed
in option 4.4 Section 3.4.2.4 (Option 4.4) not be supported by the CDNI Logging
interface at this stage and but that it be kept as a candidate topic of
great interest for a rechartering of the CDNI WG once the first set
of deliverables is produced. When doing so, At that time, we suggest to investigate investigating
the notion of complementing the "push-style" a "push style" CDNI logging Logging interface supporting
that would support summarization by via an on-demand pull-type of "pull type"
interface allowing an that would in turn allow a uCDN to request the subset of
the detailed logging information that it may need but that is lost in
the summarized pushed information.

The authors note that while a CDN only needs to adhere to the CDNI
Logging interface on its external interfaces and can perform logging
in a different format within the CDN, any possible CDNI Logging logging
approach effectively places some constraints on the dCDN logging
format. For example, to support the "Do-Nothing" Approach, "do nothing" approach, a CDN
need
needs to perform and retain per chunk per-chunk logs. As another example, to
support the "Full "full HAS awareness/per-Session-Logs" Approach, awareness/per-session logs" approach, the dCDN
cannot operate on use a logging format that summarize "more than" or "in an
incompatible summarizes data in a way with" that is
incompatible with the summarization specified for CDNI Logging. logging (e.g.,
summarizes data into a smaller set of information than what is
specified for CDNI logging). However, the authors feel that such
constraints are (i) inevitable, (ii) outweighed by the benefits of a
standardized logging interface interface, and (iii) acceptable because because, in the
case of incompatible summarization, all/ most or all CDNs are capable of
reverting to per-chunk logging as per the
Do-Nothing Approach "do nothing" approach that
we recommend as the base mandatory approach.

3.5. URL Signing

URL Signing signing is an authorization method for content delivery. This is
based on embedding the HTTP URL with information that can be
validated to ensure that the request has legitimate access to the
content. There are two parts: 1) parameters that convey
authorization restrictions (e.g. (e.g., source IP address and time period)
and/or a protected URL portion, and 2) a message digest that confirms
the integrity of the URL and authenticates the URL creator. entity that creates
the URL. The authorization parameters can be anything agreed upon
between the entity that creates the URL and the entity that validates
the URL. A key is used to generate the message digest (i.e. (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: signing: asymmetric keys and
symmetric key. keys. Asymmetric keys always have a key pair made up of a
public key and private key. The private key and public key are used
for signing and validating the URL, respectively. A symmetric key is
the same key that is used for both functions. Regardless of the type
of key, the entity that validates the URL has to obtain the key.
Distribution for of the symmetric key requires security to prevent others
from taking it. Public A public key can be distributed freely freely, while a
private key is kept by the URL signer. The method for key
distribution is out of scope. scope for this document.

URL Signing signing operates in the following way. A signed URL is provided
by the content owner (i.e. (i.e., URL signer) to the user during website
navigation. When the user selects the URL, the HTTP request is sent
to the CDN CDN, which validates that URL before delivering the content.

3.5.1. HAS Implications

The authorization lifetime for URL Signing signing is affected by HAS. The
expiration time in the authorization parameters of URL Signing signing limits
the period that the content referenced by the URL can be accessed.
This works for URL URLs that directly access the media content. But content, but for
HAS content, content the Manifest File contains another layer of URL URLs that
reference the chunks. The chunk URL that is embedded in the content
may be requested at an indeterminate some undetermined amount of time later. The time
period between access to the Manifest File and chunk retrieval may
vary significantly. The type of content (i.e. Live (i.e., live or VoD) impacts
the
this time variance as well. This property of HAS content has this property that needs to be
addressed for URL Signing. 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 keys for URL Signing signing has
implications on for the trust model between the CSP and CDNs and for the
key distribution method that can be used.

DNS-based request routing does not change the URL. In the case of a
symmetric key, the CSP and the Authoritative CDN have a business
relationship that allows them to share a key (or multiple keys) for
URL Signing. signing. When the user request a requests content from the Authoritative
CDN, the URL is signed by the CSP. The Authoritative CDN (as a
Upstream CDN) uCDN)
redirects the request to a Downstream CDN dCDN via DNS. There may be more than one
level of redirection to reach the
Delivering delivering CDN. The user would
obtain the IP address from DNS and send the HTTP request to the Delivering
delivering CDN, which needs to validate the URL. This requires that
the key to be distributed from the Authoritative CDN to the Delivering delivering
CDN. This may be problematic when the key is exposed to the Delivering a delivering
CDN that does not have a relationship with the CSP. The combination
of DNS-based request routing and symmetric key function is a generic
issue for URL Signing signing and not specific to HAS content. In the case
of asymmetric keys, the CSP signs the URL with its private key. The Delivering
delivering CDN validates the URL with the associated public key.

HTTP

HTTP-based request routing changes the URL during the redirection
procedure. In the case of a symmetric key, the CSP signs the
original URL with the same key used by the Authoritative CDN to
validate the URL. The Authoritative CDN (as a Upstream CDN) uCDN) redirects the
request to the
Downstream CDN. dCDN. The new URL is signed by the Upstream CDN uCDN with the same
key used by the Downstream CDN dCDN to validate that URL. The key used by the Upstream CDN uCDN
to validate the original URL is expect expected to be different than the key
used to sign the new URL. In the case of asymmetric keys, the CSP
signs the original URL with its private key. The Authoritative CDN
validates that URL with the CSP's public key. The Authoritative CDN
redirects the request to the Downstream CDN. dCDN. The new URL is signed by the Upstream CDN uCDN
with its private key. The
Downstream CDN dCDN validates that URL with the Upstream CDN's uCDN's
public key. There may be more than one level of redirection to reach
the
Delivering delivering CDN. The URL Signing signing operation described previously
applies at each level between the Upstream CDN uCDN and Downstream CDN dCDN for both the symmetric key
keys and asymmetric keys cases. keys.

URL Signing signing requires support in most of the CDNI Interfaces. 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
dCDN should inform the Upstream CDN uCDN that it supports URL
Signing 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 dCDN with URL signing capability when
the CDNI metadata Metadata of the content requires this authorization method.
The Logging logging interface provides information on the authorization
method (e.g. (e.g., URL Signing) signing) and related authorization parameters used
for content delivery. Having the information in the URL is not
sufficient to know that the
surrogate Surrogate enforced the authorization.
URL Signing signing has no impact on the Control control interface.

3.5.3. Option 5.1: Do Nothing

"Do Nothing"

This approach means that the CSP can only perform URL Signing signing for the top level
top-level Manifest File. The top level top-level Manifest File contains chunk
URLs or lower level lower-level Manifest File URLs, which are not modified
(i.e. (i.e.,
no URL Signing signing for the embedded URLs). In essence, the lower
level lower-level
Manifest Files and chunks are delivered without content access
authorization.

Effect on CDNI interfaces:

o None

Advantages/Drawbacks:

+ Top level Top-level Manifest File access is protected

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

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

3.5.4. Option 5.2: Flexible URL Signing by CSP

In addition to URL Signing signing for the top level top-level Manifest File, the CSP
performs flexible URL Signing signing for the lower level lower-level Manifest Files and
chunks. For each HAS session, the top level top-level Manifest File contains
signed chunk URLs or signed lower level lower-level Manifest File URLs for the
specific session. The lower level lower-level Manifest File contains session-
based signed chunk URLs. The CSP generates the Manifest Files
dynamically for the session. The chunk (segment/fragment) is
delivered with content access authorization using flexible URL
Signing
signing, which protects the invariant portion of the URL. Segment A
"segment" URL
(e.g. (e.g., HLS) is individually signed for the invariant
URL portion
(Relative (relative URL) or the entire URL (Absolute (absolute URL without Redirection)
redirection) in the Manifest File. Fragment A "fragment" URL (e.g. (e.g., HTTP
Smooth Streaming) is signed for the invariant portion of the template
URL in the Manifest File. More details are provided later in this
section. The URL
Signing signing expiration time for the chunk needs to be
long enough to play the video. There are implications of related to
signing the URLs in the Manifest File. For Live live content, the
Manifest Files are requested at a high frequency. For VoD content,
the Manifest File may be quite large. URL Signing signing can add more
computational load and delivery latency in high volume high-volume cases.

For HAS content, the Manifest File contains the Relative Locator,
Absolute Locator relative URL,
absolute URL without Redirection, redirection, or Absolute Locator absolute URL with
Redirection redirection
for specifying the chunk location. Signing the chunk URL requires
that the CSP to know the portion of the URL that remains when the
content is requested from the Delivery delivering CDN surrogate. Surrogate.

For Absolute URL absolute URLs without Redirection, redirection, the CSP knows that the chunk
URL which is explicitly linked with the delivery delivering CDN surrogate Surrogate and can
sign the URL based on that information. Since the entire URL is set
and does not change, the surrogate Surrogate can validate the URL. The CSP and
the Delivery delivering CDN are expected to have a business relationship in
this case. So case, and so either symmetric key keys or asymmetric keys can be
used for URL Signing. signing.

For Relative URL, relative URLs, the URL of the Manifest File provides the root
location. The method of request routing affects the URL used to
ultimately request the chunk from the Delivery delivering CDN surrogate. Surrogate. For
DNS, the original URL does not change. This allows the CSP to sign
the chunk URL based on the Manifest File URL and the Relative relative URL.
For HTTP, the URL changes during redirection. In this case, the CSP
does not know the redirected URL that will be used to request the
Manifest File. This uncertainty makes it impossible to accurately
sign the chunk URLs in the Manifest File. Basically, URL Signing signing
using this reference method, method "as is" for protection of the entire URL protection,
is not supported. However, instead of signing the entire URL, the
CSP signs the Relative relative URL (i.e. (i.e., the invariant portion of the URL)
and conveys the protected portion in the authorization parameters
embedded in the chunk URL. This approach works in the same way as Absolute URL
absolute URLs without
Redirection, redirection, except that the HOST part and
(part of) the PATH part of the URL are not signed and validated. The
security level should remain the same same, as content access
authorization ensures that the user that requested the content has
the proper credentials. This scheme does not seem to compromise the
authorization model model, since the resource is still protected by the
authorization parameters and message digest.
Perhaps, further Further evaluation on of
security would might be helpful.

For Absolute URL absolute URLs with Redirection, redirection, the method of request routing
affects the URL used to ultimately request the chunk from the
Delivery
delivering CDN surrogate. Surrogate. This case has the same conditions as those
indicated above for the
Relative relative URL. The difference is that the URL
is for the chunk instead of the Manifest File. For DNS, the chunk
URL does not change and can be signed by the CSP. For HTTP, the URL
used to deliver the chunk is unknown to the CSP. In this case, the
CSP cannot sign the URL URL, and this method of reference for the chunk
is not supported.

Effect on CDNI interfaces:

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

Advantages/Drawbacks:

+ The Manifest File and chunks are protected

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

+ DNS-based request routing with asymmetric keys and HTTP-based
request routing for Relative URL relative URLs and Absolute URL absolute URLs without
Redirection works
redirection work

- The 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 keys may be problematic
due to the need for transitive trust between the CSP and Delivery
delivering CDN

- HTTP-based request routing for Absolute URL absolute URLs with Redirection redirection does
not work work, because the URL used Delivery by the delivering CDN surrogate Surrogate is
unknown to the CSP

3.5.5. Option 5.3: Flexible URL Signing by Upstream CDN uCDN

This is similar to the previous section, with the exception that the
Upstream CDN
uCDN performs flexible URL signing for the lower level lower-level Manifest Files
and chunks. URL Signing signing for the top level top-level Manifest File is still
provided by the CSP.

Effect on CDNI interfaces:

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

Advantages/Drawbacks:

+ The Manifest File and chunks are protected

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

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

+ DNS-based request routing with asymmetric keys and HTTP-based
request routing for Relative URL relative URLs and Absolute URL absolute URLs without
Redirection works
redirection work

- Upstream CDN The uCDN 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

- The Manifest File needs to be distributed through the uCDN

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

3.5.6. Option 5.4: Authorization Group ID and HTTP Cookie

Based on the Authorization Group ID metadata, the CDN validates the
URL
Signing signing or validates the HTTP cookie for request of content in
the group. The CSP performs URL Signing signing for the top level top-level Manifest
File. The top level top-level Manifest File contains lower level lower-level Manifest File
URLs or chunk URLs. The lower level lower-level Manifest Files and chunks are
delivered with content access authorization using an HTTP cookie that
contains session state associated with authorization of the top level top-level
Manifest File. The Group ID Metadata metadata is used to associate the
related content (i.e. (i.e., Manifest Files and chunks). It also specifies
content (e.g. (e.g., regexp method) that needs to be validated by either
URL Signing signing or an HTTP cookie. Note that the creator of the metadata
is
HAS-aware. Duration HAS aware. The duration of the chunk access may be included in
the URL
Signing signing of the top level top-level Manifest File and set in the cookie.
Alternatively, the access control duration could be provided by the
CDNI Metadata interface.

Effect on CDNI interfaces:

o CDNI Metadata Interface - interface: Authorization Group ID metadata
identifies the content that is subject to validation of URL
Signing
signing or validation of an HTTP cookie associated with the URL
Signing
signing

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

Advantages/Drawbacks:

+ The Manifest File and chunks are protected

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

+ The CSP does not need to change the Manifest Files

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

- Requires the use of an HTTP cookie cookie, which may not be acceptable in
some environments (e.g. (e.g., where some targeted User-Agents User Agents do not
support HTTP Cookie) cookies)

- The Manifest File has to be delivered by surrogate the Surrogate

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

The CDN is aware of HAS content and uses URL Signing signing and HTTP cookie cookies
for content access authorization. URL Signing signing is fundamentally about
authorizing access to a Content Item content item or its specific Content
Collections content
collections (representations) for a specific user during a time
period with
period, possibly also using some other criteria. A chunk is an
instance of the sets of chunks referenced by the Manifest File for
the Content
Item content item or its specific Content Collections. content collections. This
relationship means that once the Downstream CDN dCDN has authorized the Manifest
File, it can assume that the associated chunks are implicitly
authorized. The new function for the CDN is to link the Manifest
File with the chunks for the HTTP session. This can be accomplished
by using an HTTP cookie for the HAS session.

After validating the URL and detecting that the requested content is
a top level top-level Manifest File, the delivery delivering CDN surrogate Surrogate sets a an HTTP
cookie with a signed session token for the HTTP session. When a
request for a lower level lower-level Manifest File or chunk arrives, the
surrogate
Surrogate confirms that the HTTP cookie value contains the correct
session token. If so, the lower level lower-level Manifest File or chunk is
delivered due to in accordance with the transitive authorization property. Duration mechanism.
The duration of the chunk access may be included in the URL Signing signing
of the top level top-level Manifest File and set in the cookie. The details of
the operation are left to be determined later.

Effect on CDNI interfaces:

o CDNI Metadata Interface - interface: New metadata identifies the content that
is subject to validation of URL Signing signing and information in the
cookie for the type of HAS content

o Request Routing interface - Downstream CDN interface: The dCDN should inform the
Upstream CDN uCDN that it
supports URL Signing 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 dCDN when the CDNI metadata Metadata identifies the content

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

Advantages/Drawbacks:

+ The Manifest File and chunks are protected

+ The CSP does not need to change the Manifest Files

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

- Requires CDNI Interfaces extensions to CDNI interfaces

- Requires the use of an HTTP cookie cookie, which may not be acceptable in
some environments (e.g. (e.g., where some targeted User-Agents User Agents do not
support HTTP Cookie) cookies)

- The Manifest File has to be delivered by surrogate the Surrogate

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

The CDN is aware of HAS content and uses URL Signing signing for content
access authorization of Manifest File Files and chunk. chunks. The CDN generates
or rewrites the Manifest Files and learns about the chunks based on
the Manifest File. The embedded URLs in the Manifest File are signed
by the CDN.
Duration The duration of the chunk access may be included in the
URL Signing. 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 live and VoD content mentioned in
Section 3.5.4 apply.

Effect on CDNI interfaces:

o CDNI Metadata Interface - interface: New metadata identifies the content that
is subject to validation of URL Signing signing and information in the
cookie for the type of HAS content

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

Advantages/Drawbacks:

+ The Manifest File and chunks are protected

+ The CSP does not need to change the Manifest Files

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

- Requires CDNI Interfaces extensions to CDNI interfaces

- Requires the CDN to generate or rewrite the Manifest File

- The Manifest File has to be delivered by surrogate the Surrogate

3.5.9. Recommendation Recommendations

The authors consider that Option 5.1 (Do Nothing) is not suitable (do nothing) unsuitable for access
control of HAS content.

Where the HTTP Cookie cookie mechanism is supported by the targeted User- User
Agents and the security requirements can be addressed through the
proper use of HTTP Cookies, cookies, the authors recommend use of using Option 5.4
(Authorization Group ID with and HTTP Cookie) cookie) and therefore that
Option 5.4 be supported by the CDNI solution. This method does not
require manifest file Manifest File manipulation, as Manifest File manipulation which may
be a significant deployment obstacle. obstacle to deployment. Otherwise, the authors
recommend that Option 5.2 (Flexible (flexible URL
Signing signing by the CSP) or
Option 5.3 (Flexible URI Signing (flexible URL signing by the
Upstream CDN) uCDN) be used and therefore
that flexible URI URL signing be supported by the CDNI solution. Option
Options 5.2 and Option 5.3 protect all the content, does do not require Downstream CDN to that the
dCDN be aware of HAS, does do not impact CDNI interfaces, supports support all
different types of devices, and
supports support the common cases of request
routing for HAS content (i.e. (i.e., DNS-based request routing with
asymmetric keys and HTTP-based request routing for Relative URL).

HAS-awareness in CDN (Option relative URLs).

Options 5.5 and Option 5.6) 5.6 (HAS awareness in CDNs using HTTP cookies or
Manifest Files) have some advantages that should be considered for
future support (e.g. (e.g., a CDN that is aware of HAS content can manage
the content more efficiently at in a broader
context. context). Content
distribution, storage, delivery, deletion, access authorization, etc.
can all benefit.). benefit. Including HAS-awareness HAS awareness as part of the current CDNI
charter, however, would almost certainly delay the CDNI WG's
milestones, and the authors therefore do not recommend it right now.

3.6. Content Purge

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

3.6.1. Option 6.1: No HAS awareness 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.
content collection. While this method is very simple and does not
require HAS awareness, it obviously creates a signaling overhead
between the uCDN and dCDN dCDN, since a reference is to be provided for
each content chunk to be purged.

Effect on CDNI interfaces:

o None

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

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

- Requires individual purge request for every file making up a
Content Collection
content collection (or, alternatively, requires the ability to
convey references to all the chunks making up a Content Collection content collection
inside a purge request) request), which creates signaling overhead

3.6.2. Option 6.2: Purge Identifiers

There exists a potentially more efficient method for performing
content removal of large numbers of files simultaneously. By
including a "Purge IDentifier (Purge-ID)" in the metadata of a
particular file, it is possible to virtually group together different
files making up a Content Collection. content collection. A Purge-ID can take the form
of an arbitrary number or string which that is communicated as part of the
CDNI Metadata Interface interface, and which that is the same for all files making up
a particular Content Item, and content item but different across different Content
Items. content
items. If a uCDN wants to request that the dCDN to remove a Content
Collection, content
collection, it can send a purge request containing this Purge-ID.
The dCDN can then remove all files that share the corresponding
Purge-ID.

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

The Purge-ID is similar to the Content Collection ID CCID discussed in Section 3.4.2.2 for
handling HAS Logging logging, and we note that further thought is needed to
determine whether the CCID and Purge-ID should be collapsed into a
single element or remain separate elements.

Effect on CDNI interfaces:

o CDNI Metadata Interface: interface: Add metadata field for indicating Purge-
ID
Purge-ID

o CDNI Control Interface: interface: Add functionality to convey a Purge-ID in
purge requests

Advantages/Drawbacks:

+ Allows for efficient purging of content from a dCDN

+ Does not require HAS awareness on the part of a dCDN

3.6.3. Recommendation Recommendations

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

3.7. Other issues Issues

This section includes some HAS-specific issues that came up during
the discussion of this draft document and which that 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
either a CDN or by the CSP, CSP and thereby being be invisible to the CDN
delivering the chunks. Obviously, the decision on of whether the CDN
or CSP delivers the Manifest File is made between the uCDN and
CSP, and the dCDN has no choice in the matter. However, some
dCDNs might only want to offer their services in the cases where
they have access to the Manifest File (e.g. (e.g., because their
internal architecture is based around on the knowledge inside the
Manifest File). For these cases, it might be useful to include a
field in the CDNI Capability Advertisement to allow dCDNs to
advertise the fact that they require access to the Manifest File.

4. IANA Considerations

This document makes no request of IANA.

5. Security Considerations

This document does not discuss security issues around related to HTTP or HAS
delivery. Those
delivery, as these topics are expected to be discussed in the CDNI WG
documents
documents, including [I-D.ietf-cdni-framework].

6. [CDNI-FRAMEWORK].

5. Acknowledgements

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

6. References

7.1.

6.1. Normative References

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

7.2.

6.2. Informative References

[I-D.draft-bertrand-cdni-logging]

[CDNI-FRAMEWORK]
Peterson, L., Ed., and B. Davie, "Framework for CDN
Interconnection", Work in Progress, February 2013.

[CDNI-LOGGING]
Bertrand, G., Ed. and E. Ed., Stephan, E., Peterkofsky, R., Le
Faucheur, F., and P. Grochocki, "CDNI Logging Interface", .

[I-D.draft-ietf-cdni-requirements]
Work in Progress, October 2012.

[CDNI-REQUIREMENTS]

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

[I-D.ietf-cdni-framework]
Peterson, L. and B. Davie, "Framework for CDN
Interconnection", draft-ietf-cdni-framework-03 (work Requirements", Work in
progress), February
Progress, July 2013.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax, RFC3986", Syntax", STD 66,
RFC 3986, January 2005.

Authors' Addresses

Ray van Brandenburg
TNO
Brassersplein 2
Delft 2612CT
the Netherlands

Phone: +31-88-866-7000
Email:
EMail: ray.vanbrandenburg@tno.nl

Oskar van Deventer
TNO
Brassersplein 2
Delft 2612CT
the Netherlands

Phone: +31-88-866-7000
Email:
EMail: oskar.vandeventer@tno.nl

Francois Le Faucheur
Cisco Systems
Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410
E.Space Park - Batiment D
6254 Allee des Ormes - BP 1200
06254 Mougins cedex
France

Phone: +33 4 97 23 26 19
Email:
EMail: flefauch@cisco.com

Kent Leung
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA

Phone: +1 408-526-5030
Email:
EMail: kleung@cisco.com