Independent Submission R. van Brandenburg
Request for Comments: 6983 O. van Deventer
Category: Informational TNO
ISSN: 2070-1721 F. Le Faucheur
K. Leung
Cisco Systems
July 2013
Independent Submission R. van Brandenburg
Request for Comments: 6983 O. van Deventer
Category: Informational TNO
ISSN: 2070-1721 F. Le Faucheur
K. Leung
Cisco Systems
July 2013
Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI)
HTTP自适应流感知内容分发网络互连（CDNI）模型
Abstract
摘要
This document presents thoughts on the potential impact of supporting HTTP Adaptive Streaming (HAS) technologies in Content Distribution Network Interconnection (CDNI) scenarios. The intent is to present the authors' analysis of the CDNI-HAS problem space and discuss different options put forward by the authors (and by others during informal discussions) on how to deal with HAS in the context of CDNI. This document has been used as input information during the CDNI working group process for making a decision regarding support for HAS.
本文档介绍了在内容分发网络互连（CDNI）场景中支持HTTP自适应流（HAS）技术的潜在影响。目的是展示作者对CDNI-HAS问题空间的分析，并讨论作者（以及其他人在非正式讨论中）就如何在CDNI背景下处理HAS提出的不同选择。本文件已在CDNI工作组过程中用作输入信息，以做出有关支持has的决策。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6983.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6983.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Terminology ................................................5
2. HTTP Adaptive Streaming Aspects Relevant to CDNI ................6
2.1. Segmentation versus Fragmentation ..........................6
2.2. Addressing Chunks ..........................................7
2.2.1. Relative URLs .......................................8
2.2.2. Absolute URLs with Redirection ......................9
2.2.3. Absolute URLs without Redirection ..................10
2.3. Live Content versus VoD Content ...........................11
2.4. Stream Splicing ...........................................12
3. Possible HAS Optimizations .....................................12
3.1. File Management and Content Collections ...................13
3.1.1. General Remarks ....................................13
3.1.2. Candidate Approaches ...............................13
3.1.2.1. Option 1.1: Do Nothing ....................13
3.1.2.2. Option 1.2: Allow Single-File
Storage of Fragmented Content .............14
3.1.2.3. Option 1.3: Access Correlation Hint .......14
3.1.3. Recommendations ....................................15
3.2. Content Acquisition of Content Collections ................15
3.2.1. General Remarks ....................................15
3.2.2. Candidate Approaches ...............................16
3.2.2.1. Option 2.1: No HAS Awareness ..............16
3.2.2.2. Option 2.2: Allow Single-File
Acquisition of Fragmented Content .........17
3.2.3. Recommendations ....................................17
1. Introduction ....................................................4
1.1. Terminology ................................................5
2. HTTP Adaptive Streaming Aspects Relevant to CDNI ................6
2.1. Segmentation versus Fragmentation ..........................6
2.2. Addressing Chunks ..........................................7
2.2.1. Relative URLs .......................................8
2.2.2. Absolute URLs with Redirection ......................9
2.2.3. Absolute URLs without Redirection ..................10
2.3. Live Content versus VoD Content ...........................11
2.4. Stream Splicing ...........................................12
3. Possible HAS Optimizations .....................................12
3.1. File Management and Content Collections ...................13
3.1.1. General Remarks ....................................13
3.1.2. Candidate Approaches ...............................13
3.1.2.1. Option 1.1: Do Nothing ....................13
3.1.2.2. Option 1.2: Allow Single-File
Storage of Fragmented Content .............14
3.1.2.3. Option 1.3: Access Correlation Hint .......14
3.1.3. Recommendations ....................................15
3.2. Content Acquisition of Content Collections ................15
3.2.1. General Remarks ....................................15
3.2.2. Candidate Approaches ...............................16
3.2.2.1. Option 2.1: No HAS Awareness ..............16
3.2.2.2. Option 2.2: Allow Single-File
Acquisition of Fragmented Content .........17
3.2.3. Recommendations ....................................17
3.3. Request Routing of HAS Content ............................17
3.3.1. General Remarks ....................................17
3.3.2. Candidate Approaches ...............................18
3.3.2.1. Option 3.1: No HAS Awareness ..............18
3.3.2.2. Option 3.2: Manifest File Rewriting
by uCDN ...................................20
3.3.2.3. Option 3.3: Two-Step Manifest File
Rewriting .................................21
3.3.3. Recommendations ....................................22
3.4. Logging ...................................................23
3.4.1. General Remarks ....................................23
3.4.2. Candidate Approaches ...............................24
3.4.2.1. Option 4.1: Do Nothing ....................24
3.4.2.2. Option 4.2: CDNI Metadata Content
Collection ID .............................26
3.4.2.3. Option 4.3: CDNI Logging Interface
Compression ...............................28
3.4.2.4. Option 4.4: Full HAS
Awareness/Per-Session Logs ................29
3.4.3. Recommendations ....................................30
3.5. URL Signing ...............................................32
3.5.1. HAS Implications ...................................32
3.5.2. CDNI Considerations ................................33
3.5.3. Option 5.1: Do Nothing .............................34
3.5.4. Option 5.2: Flexible URL Signing by CSP ............34
3.5.5. Option 5.3: Flexible URL Signing by uCDN ...........37
3.5.6. Option 5.4: Authorization Group ID and HTTP
Cookie .............................................37
3.5.7. Option 5.5: HAS Awareness with HTTP Cookie in CDN ..38
3.5.8. Option 5.6: HAS Awareness with Manifest
File in CDN ........................................40
3.5.9. Recommendations ....................................41
3.6. Content Purge .............................................41
3.6.1. Option 6.1: No HAS Awareness .......................42
3.6.2. Option 6.2: Purge Identifiers ......................42
3.6.3. Recommendations ....................................43
3.7. Other Issues ..............................................43
4. Security Considerations ........................................43
5. Acknowledgements ...............................................44
6. References .....................................................44
6.1. Normative References ......................................44
6.2. Informative References ....................................44
3.3. Request Routing of HAS Content ............................17
3.3.1. General Remarks ....................................17
3.3.2. Candidate Approaches ...............................18
3.3.2.1. Option 3.1: No HAS Awareness ..............18
3.3.2.2. Option 3.2: Manifest File Rewriting
by uCDN ...................................20
3.3.2.3. Option 3.3: Two-Step Manifest File
Rewriting .................................21
3.3.3. Recommendations ....................................22
3.4. Logging ...................................................23
3.4.1. General Remarks ....................................23
3.4.2. Candidate Approaches ...............................24
3.4.2.1. Option 4.1: Do Nothing ....................24
3.4.2.2. Option 4.2: CDNI Metadata Content
Collection ID .............................26
3.4.2.3. Option 4.3: CDNI Logging Interface
Compression ...............................28
3.4.2.4. Option 4.4: Full HAS
Awareness/Per-Session Logs ................29
3.4.3. Recommendations ....................................30
3.5. URL Signing ...............................................32
3.5.1. HAS Implications ...................................32
3.5.2. CDNI Considerations ................................33
3.5.3. Option 5.1: Do Nothing .............................34
3.5.4. Option 5.2: Flexible URL Signing by CSP ............34
3.5.5. Option 5.3: Flexible URL Signing by uCDN ...........37
3.5.6. Option 5.4: Authorization Group ID and HTTP
Cookie .............................................37
3.5.7. Option 5.5: HAS Awareness with HTTP Cookie in CDN ..38
3.5.8. Option 5.6: HAS Awareness with Manifest
File in CDN ........................................40
3.5.9. Recommendations ....................................41
3.6. Content Purge .............................................41
3.6.1. Option 6.1: No HAS Awareness .......................42
3.6.2. Option 6.2: Purge Identifiers ......................42
3.6.3. Recommendations ....................................43
3.7. Other Issues ..............................................43
4. Security Considerations ........................................43
5. Acknowledgements ...............................................44
6. References .....................................................44
6.1. Normative References ......................................44
6.2. Informative References ....................................44
[RFC6707] defines the problem space for Content Distribution Network Interconnection (CDNI) and the associated CDNI interfaces. This includes support, through interconnected Content Delivery Networks (CDNs), of content delivery to End Users using HTTP progressive download and HTTP Adaptive Streaming (HAS).
[RFC6707]定义了内容分发网络互连（CDNI）和相关CDNI接口的问题空间。这包括通过互联内容交付网络（CDN）支持使用HTTP渐进下载和HTTP自适应流（HAS）向最终用户交付内容。
HTTP Adaptive Streaming is an umbrella term for various HTTP-based streaming technologies that allow a client to adaptively switch between multiple bitrates, depending on current network conditions. A defining aspect of HAS is that, since it is based on HTTP, it is a pull-based mechanism, with a client actively requesting content segments instead of the content being pushed to the client by a server. Due to this pull-based nature, media servers delivering content using HAS often show different characteristics when compared with media servers delivering content using traditional streaming methods such as the Real-time Transport Protocol / Real Time Streaming Protocol (RTP/RTSP), the Real Time Messaging Protocol (RTMP), and the Multimedia Messaging Service (MMS).
HTTP自适应流是各种基于HTTP的流技术的总称，允许客户端根据当前网络条件在多个比特率之间自适应切换。HAS的一个定义方面是，由于它基于HTTP，它是一种基于拉的机制，客户端主动请求内容段，而不是由服务器将内容推送到客户端。由于这种基于拉的性质，与使用传统流式传输方法（如实时传输协议/实时流式传输协议（RTP/RTSP）、实时消息协议（RTMP）等）传输内容的媒体服务器相比，使用，以及彩信服务（MMS）。
This document presents a discussion of the impact of the HAS operation on the CDNI interfaces, and what HAS-specific optimizations may be required or may be desirable. The scope of this document is to present the authors' analysis of the CDNI-HAS problem space and discuss different options put forward by the authors (and by others during informal discussions) on how to deal with HAS in the context of CDNI. The document concludes by presenting the authors' recommendations on how the CDNI WG should deal with HAS in its initial charter, with a focus on 'making it work' instead of including 'nice-to-have' optimizations that might delay the development of the CDNI WG deliverables identified in its initial charter.
本文档讨论了HAS操作对CDNI接口的影响，以及可能需要或需要的具体优化。本文件的范围是介绍作者对CDNI-HAS问题空间的分析，并讨论作者（以及其他人在非正式讨论中）就如何在CDNI背景下处理HAS提出的不同选择。该文件最后提出了作者关于CDNI工作组在其初始章程中应如何处理HAS的建议，重点是“使其工作”，而不是包括可能延迟其初始章程中确定的CDNI工作组可交付成果开发的“很好”优化。
It should be noted that the document is not a WG document but has been used as input during the WG process for making its decision regarding support for HAS. We expect the analysis presented in the document to be useful in the future if and when the WG recharters and wants to reassess the level of HAS optimizations to be supported in CDNI scenarios.
应注意的是，该文件不是工作组文件，但在工作组就支持has作出决定的过程中，已被用作输入。我们希望，如果工作组重新评估并希望重新评估CDNI场景中支持的HAS优化水平，那么文档中提供的分析在将来会很有用。
This document uses the terminology defined in [RFC6707] and [CDNI-FRAMEWORK].
本文件使用[RFC6707]和[CDNI-FRAMEWORK]中定义的术语。
For convenience, the definitions of HAS-related terms are restated here:
为方便起见，HAS相关术语的定义在此重述：
Content Item: A uniquely addressable content element in a CDN. A content item is defined by the fact that it has its own Content Metadata associated with it. An example of a content item is a video file/stream, an audio file/stream, or an image file.
内容项：CDN中唯一可寻址的内容元素。内容项的定义是，它有自己的与之关联的内容元数据。内容项的示例是视频文件/流、音频文件/流或图像文件。
Chunk: A fixed-length element that is the result of a segmentation or fragmentation operation and that is independently addressable.
块：一个固定长度的元素，是分段或分段操作的结果，并且可以独立寻址。
Fragment: A specific form of chunk (see Section 2.1). A fragment is stored as part of a larger file that includes all chunks that are part of the chunk collection.
片段：块的一种特定形式（见第2.1节）。片段作为较大文件的一部分存储，该文件包括作为块集合一部分的所有块。
Segment: A specific form of chunk (see Section 2.1). A segment is stored as a single file from a file-system perspective.
段：块的一种特定形式（见第2.1节）。从文件系统的角度来看，段存储为单个文件。
Original Content: Non-chunked content that is the basis for a segmentation or fragmentation operation. Based on Original Content, multiple alternative representations (using different encoding methods, supporting different resolutions, and/or targeting different bitrates) may be derived, each of which may be fragmented or segmented.
原始内容：作为分段或分段操作基础的非分块内容。基于原始内容，可以导出多个备选表示（使用不同的编码方法、支持不同的分辨率和/或针对不同的比特率），其中每个表示可以是分段的或分段的。
Chunk Collection: The set of all chunks that are the result of a single segmentation or fragmentation operation being performed on a single representation of the Original Content. A chunk collection is described in a Manifest File.
Chunk Collection（块集合）：对原始内容的单个表示执行单个分段或分段操作后产生的所有块的集合。块集合在清单文件中描述。
Content Collection: The set of all chunk collections that are derived from the same Original Content. A content collection may consist of multiple chunk collections, each corresponding to a single representation of the Original Content. A content collection may be described by one or more Manifest Files.
内容集合：从同一原始内容派生的所有区块集合的集合。内容集合可以由多个区块集合组成，每个区块集合对应于原始内容的单个表示。内容集合可以由一个或多个清单文件描述。
Manifest File: A Manifest File, also referred to as a Media Presentation Description (MPD) file, is a file that lists the way the content has been chunked (possibly for multiple encodings), as well as where the various chunks are located (in the case of segments) or how they can be addressed (in the case of fragments).
清单文件：清单文件，也称为媒体演示文稿描述（MPD）文件，是一个列出内容分块方式（可能用于多种编码）以及各种分块的位置（对于片段）或寻址方式（对于片段）的文件。
In the last couple of years, a wide variety of HAS-like protocols have emerged. Among them are proprietary solutions such as Apple's HTTP Live Streaming (HLS), Microsoft's HTTP Smooth Streaming (HSS), and Adobe's HTTP Dynamic Streaming (HDS), as well as various standardized solutions such as 3GPP Adaptive HTTP Streaming (AHS) and MPEG Dynamic Adaptive Streaming over HTTP (DASH). While all of these technologies share a common set of features, each has its own defining elements. This section looks at some of the common characteristics and some of the differences between these technologies and how those might be relevant to CDNI. In particular, Section 2.1 describes the various methods to store HAS content, and Section 2.2 lists three methods that are used to address HAS content in a CDN. After these generic HAS aspects are discussed, two special situations that need to be taken into account when discussing HAS are addressed: Section 2.3 discusses the differences between live content and Video on Demand (VoD) content, while Section 2.4 discusses the scenario where multiple streams are combined in a single Manifest File (e.g., for ad insertion purposes).
在过去几年中，出现了各种各样的类似HAS的协议。其中包括专有解决方案，如苹果的HTTP实时流（HLS）、微软的HTTP平滑流（HSS）和Adobe的HTTP动态流（HDS），以及各种标准化解决方案，如3GPP自适应HTTP流（AHS）和MPEG动态自适应HTTP流（DASH）。虽然所有这些技术都有一组共同的特性，但每种技术都有自己的定义元素。本节将介绍这些技术之间的一些共同特征和差异，以及这些技术与CDNI的关系。特别是，第2.1节描述了存储HAS内容的各种方法，第2.2节列出了用于在CDN中寻址HAS内容的三种方法。在讨论了这些通用的HAS方面之后，讨论了在讨论HAS时需要考虑的两种特殊情况：第2.3节讨论了直播内容和视频点播（VoD）内容之间的差异，而第2.4节讨论了在单个清单文件中组合多个流的场景（例如，用于广告插入目的）。
All HAS implementations are based on a concept referred to as "chunking": the concept of having a server split content up in numerous fixed-duration chunks that are independently decodable. By sequentially requesting and receiving chunks, a client can recreate and play out the content. An advantage of this mechanism is that it allows a client to seamlessly switch between different encodings of the same Original Content at chunk boundaries. Before requesting a particular chunk, a client can choose between multiple alternative encodings of the same chunk, irrespective of the encoding of the chunks it has requested earlier.
所有HAS实现都基于一个称为“分块”的概念：让服务器将内容分割为多个固定持续时间的独立可解码的分块。通过顺序请求和接收块，客户机可以重新创建和播放内容。这种机制的一个优点是，它允许客户端在块边界处无缝地在相同原始内容的不同编码之间切换。在请求特定块之前，客户机可以在同一块的多个备选编码之间进行选择，而不考虑其先前请求的块的编码。
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.
虽然每个HAS实现都使用某种形式的分块，但并非所有实现都以相同的方式存储生成的分块。一般来说，有两种不同的方法来执行分块和存储结果：分段和分段。
- With segmentation -- which is, for example, mandatory in all versions of Apple's HLS prior to version 7 -- the chunks, in this case also referred to as segments, are stored completely independently from each other, with each segment being stored as a separate file from a file-system perspective. This means that each segment has its own unique URL with which it can be retrieved.
- 对于分段（例如，在版本7之前的所有苹果HLS版本中都是强制性的），块（在本例中也称为段）彼此完全独立地存储，每个段从文件系统的角度存储为单独的文件。这意味着每个段都有自己的唯一URL，可以使用该URL进行检索。
- With fragmentation (or virtual segmentation) -- which is, for example, used in Microsoft's HTTP Smooth Streaming -- all chunks, or fragments, belonging to the same chunk collection are stored together as part of a single file. While there are a number of container formats that allow for storing this type of chunked content, fragmented MP4 is most commonly used. With fragmentation, a specific chunk is addressable by suffixing, to the common file URL, an identifier uniquely identifying the chunk that one is interested in, either by timestamp, by byte range, or in some other way.
- 对于碎片（或虚拟分段）——例如，在Microsoft的HTTP平滑流中使用的碎片（或虚拟分段）——属于同一块集合的所有块或片段都作为单个文件的一部分存储在一起。虽然有许多容器格式允许存储这种类型的分块内容，但碎片化MP4是最常用的。对于碎片，可以通过在公共文件URL后面加上唯一标识感兴趣的区块的标识符（通过时间戳、字节范围或其他方式）来寻址特定区块。
While one can argue about the merits of each of these two different methods of handling chunks, both have their advantages and drawbacks in a CDN environment. For example, fragmentation is often regarded as a method that introduces less overhead, from both a storage and processing perspective. Segmentation, on the other hand, is regarded as being more flexible and easier to cache. In practice, current HAS implementations increasingly support both methods.
虽然人们可以争论这两种不同的块处理方法各自的优点，但在CDN环境中，这两种方法都有各自的优点和缺点。例如，从存储和处理的角度来看，碎片化通常被认为是一种引入较少开销的方法。另一方面，分段被认为更灵活，更容易缓存。实际上，当前的实现越来越支持这两种方法。
In order for a client to request chunks, in the form of either segments or fragments, it needs to know how the content has been chunked and where to find the chunks. For this purpose, most HAS protocols use a concept that is often referred to as a Manifest File (also known as a Media Presentation Description, or MPD), i.e., a file that lists the way the content has been chunked and where the various chunks are located (in the case of segments) or how they can be addressed (in the case of fragments). A Manifest File or set of Manifest Files may also identify the different representations, and thus chunk collections, available for the content.
为了让客户机以段或片段的形式请求块，它需要知道内容是如何分块的，以及在哪里找到块。为此，大多数HAS协议使用一个通常被称为清单文件（也称为媒体呈现描述，或MPD）的概念，即，一个列出内容分块方式和各种分块的位置（在段的情况下）或如何寻址（在片段的情况下）的文件。清单文件或清单文件集还可以标识内容可用的不同表示形式，从而标识块集合。
In general, a HAS client will first request and receive a Manifest File, and then, after parsing the information in the Manifest File, proceed with sequentially requesting the chunks listed in the Manifest File. Each HAS implementation has its own Manifest File format, and even within a particular format there are different methods available to specify the location of a chunk.
通常，HAS客户端将首先请求并接收清单文件，然后在解析清单文件中的信息后，继续顺序请求清单文件中列出的块。每个HAS实现都有自己的清单文件格式，即使在特定格式中，也有不同的方法可用于指定块的位置。
Of course, managing the location of files is a core aspect of every CDN, and each CDN will have its own method of doing so. Some CDNs may be purely cache-based, with no higher-level knowledge of where each file resides at each instant in time. Other CDNs may have dedicated management nodes that, at each instant in time, do know at which servers each file resides. The CDNI interfaces designed by the CDNI WG will probably need to be agnostic to these kinds of CDN-internal architecture decisions. In the case of HAS, there is a strict relationship between the location of the content in the CDN
当然，管理文件的位置是每个CDN的核心方面，每个CDN都有自己的方法。有些CDN可能纯粹基于缓存，不知道每个文件在每个时刻驻留在何处。其他CDN可能具有专用的管理节点，这些节点在每个时刻都知道每个文件驻留在哪个服务器上。CDNI工作组设计的CDNI接口可能需要对这些类型的CDN内部架构决策不可知。在HAS的情况下，内容在CDN中的位置之间存在严格的关系
(in this case chunks) and the content itself (the locations specified in the Manifest File). It is therefore useful to have an understanding of the different methods in use in CDNs today for specifying chunk locations in Manifest Files. The different methods for doing so are described in Sections 2.2.1 to 2.2.3.
（在本例中为块）和内容本身（在清单文件中指定的位置）。因此，了解目前CDN中用于在清单文件中指定块位置的不同方法是非常有用的。第2.2.1节至第2.2.3节介绍了不同的方法。
Although these sections are especially relevant for segmented content due to its inherent distributed nature, the discussed methods are also applicable to fragmented content. Furthermore, it should be noted that the methods detailed below for specifying locations of content items in Manifest Files do not relate only to temporally segmented content (e.g., segments and fragments) but are also relevant in situations where content is made available in multiple representations (e.g., in different qualities, encoding methods, resolutions, and/or bitrates). In this case, the content consists of multiple chunk collections, which may be described by either a single Manifest File or multiple interrelated Manifest Files. In the latter case, there may be a high-level Manifest File describing the various available bitrates, with URLs pointing to separate Manifest Files describing the details of each specific bitrate. For specifying the locations of the other Manifest Files, the same methods that are used for specifying chunk locations also apply.
尽管这些部分由于其固有的分布式性质而与分段内容特别相关，但所讨论的方法也适用于分段内容。此外，应注意，下文详述的用于指定清单文件中内容项位置的方法不仅与时间分段的内容（例如，分段和片段）相关，而且在内容以多种表示形式提供的情况下也相关（例如，不同的质量、编码方法、分辨率和/或比特率）。在这种情况下，内容由多个区块集合组成，这些区块集合可以由单个清单文件或多个相互关联的清单文件描述。在后一种情况下，可能有一个高级清单文件描述各种可用比特率，URL指向描述每个规范细节的单独清单文件对于指定其他清单文件的位置，用于指定区块位置的相同方法也适用。
One final note relates to the delivery of the Manifest Files themselves. While in most situations the delivery of both the Manifest File and the chunks is handled by the CDN, there are scenarios imaginable in which the Manifest File is delivered by, for example, the Content Service Provider (CSP), and the Manifest File is therefore not visible to the CDN.
最后一个注意事项涉及清单文件本身的交付。虽然在大多数情况下，清单文件和区块的交付都由CDN处理，但也有一些场景是可以想象的，其中清单文件由内容服务提供商（CSP）交付，因此清单文件对CDN不可见。
One method for specifying chunk locations in a Manifest File is through the use of relative URLs. A relative URL is a URL that does not include the HOST part of a URL but only includes (part of) the PATH part of a URL. In practice, a relative URL is used by the client as being relative to the location from which the Manifest File has been acquired. In these cases, a relative URL will take the form of a string that has to be appended to the location of the Manifest File to get the location of a specific chunk. This means that in the case where a Manifest File with relative URLs is used, all chunks will be delivered by the same Surrogate that delivered the Manifest File. A relative URL will therefore not include a hostname.
在清单文件中指定区块位置的一种方法是使用相对URL。相对URL是不包括URL的主机部分，但仅包括URL的路径部分的URL。实际上，客户端使用相对URL作为获取清单文件的位置的相对URL。在这些情况下，相对URL将采用字符串的形式，该字符串必须附加到清单文件的位置以获取特定块的位置。这意味着，在使用具有相对URL的清单文件的情况下，所有区块将由交付清单文件的同一代理交付。因此，相对URL将不包括主机名。
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
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:
指向清单文件中引用的特定段的相对URL可能是：
segments/segment1_1.ts
分段/分段1_1.ts
which means that the client should take the location of the Manifest File and append the relative URL. In this case, the segment would then be requested from http://surrogate.server.cdn.example.com/ content_1/segments/segment1_1.ts.
这意味着客户端应该获取清单文件的位置并附加相对URL。在这种情况下，然后将从http://surrogate.server.cdn.example.com/ 内容1/片段/片段1.ts。
One drawback of using relative URLs is that it forces a CDN relying on HTTP-based request routing to deliver all segments belonging to a given content item with the same Surrogate that delivered the Manifest File for that content item, which results in limited flexibility. Another drawback is that relative URLs do not allow for fallback URLs; should the Surrogate that delivered the Manifest File break down, the client is no longer able to request chunks. The advantage of relative URLs is that it is very easy to transfer content between different Surrogates and even CDNs.
使用相对URL的一个缺点是，它强制依赖于基于HTTP的请求路由的CDN使用交付该内容项清单文件的相同代理交付属于给定内容项的所有段，这导致灵活性有限。另一个缺点是相对URL不允许回退URL；如果交付清单文件的代理出现故障，客户端将无法再请求块。相对URL的优点是，在不同的代理甚至CDN之间传输内容非常容易。
Another method for specifying locations of chunks (or other Manifest Files) in a Manifest File is through the use of an absolute URL. An absolute URL contains a fully formed URL (i.e., the client does not have to calculate the URL as in the case of the relative URL but can use the URL from the Manifest File directly).
在清单文件中指定块（或其他清单文件）位置的另一种方法是使用绝对URL。绝对URL包含完整格式的URL（即，客户端不必像相对URL那样计算URL，但可以直接使用清单文件中的URL）。
In the context of Manifest Files, there are two types of absolute URLs imaginable: absolute URLs with redirection and absolute URLs without redirection. The two methods differ in whether the URL points to a request routing node that will redirect the client to a Surrogate (absolute URLs with redirection) or point directly to a Surrogate hosting the requested content (absolute URLs without redirection).
在清单文件的上下文中，可以想象有两种类型的绝对URL：带重定向的绝对URL和不带重定向的绝对URL。这两种方法的不同之处在于，URL是指向将客户端重定向到代理的请求路由节点（带重定向的绝对URL），还是直接指向承载请求内容的代理（不带重定向的绝对URL）。
In the case of absolute URLs with redirection, a request for a chunk is handled by the Request Routing system of a CDN just as if it were a standalone (non-HAS) content request, which might include looking up the Surrogate (and/or CDN) best suited for delivering the requested chunk to the particular user and sending an HTTP redirect
在带有重定向的绝对URL的情况下，CDN的请求路由系统处理区块请求，就像处理独立（非HAS）内容请求一样，这可能包括查找最适合将请求的区块交付给特定用户的代理项（和/或CDN）和发送HTTP重定向
to the user with the URL pointing to the requested chunk on the specified Surrogate (and/or CDN), or a DNS response pointing to the specific Surrogate.
URL指向指定代理项（和/或CDN）上请求的区块，或DNS响应指向特定代理项的用户。
An example of an absolute URL with redirection might look as follows:
带有重定向的绝对URL示例如下所示：
http://requestrouting.cdn.example.com/
content_request?content=content_1&segment=segment1_1.ts
http://requestrouting.cdn.example.com/
content_request?content=content_1&segment=segment1_1.ts
As can be seen from this example URL, the URL includes a pointer to a general CDN Request Routing function and some arguments identifying the requested segment.
从这个示例URL可以看出，URL包括一个指向通用CDN请求路由函数的指针和一些标识请求段的参数。
The advantage of using absolute URLs with redirection is that they allow for maximum flexibility (since chunks can be distributed across Surrogates and CDNs in any imaginable way) without having to modify the Manifest File every time one or more chunks are moved (as is the case when absolute URLs without redirection are used). The downside of this method is that it can add significant load to a CDN Request Routing system, since it has to perform a redirect every time a client requests a new chunk.
使用带重定向的绝对URL的优点是，它们允许最大的灵活性（因为块可以以任何可以想象的方式分布在代理和CDN中），而无需在每次移动一个或多个块时修改清单文件（如使用不带重定向的绝对URL时）。这种方法的缺点是，它会给CDN请求路由系统增加很大的负载，因为每次客户端请求新块时，它都必须执行重定向。
In the case of absolute URLs without redirection, the URL points directly to the specific chunk on the actual Surrogate that will deliver the requested chunk to the client. In other words, there will be no HTTP redirection operation taking place between the client requesting the chunk and the chunk being delivered to the client by the Surrogate.
对于没有重定向的绝对URL，URL直接指向实际代理上的特定区块，该区块将向客户端交付请求的区块。换句话说，在请求区块的客户端和代理交付给客户端的区块之间不会发生HTTP重定向操作。
An example of an absolute URL without redirection is the following:
无重定向的绝对URL示例如下：
http://surrogate1.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) and the server that is expected to deliver the segment (in this case surrogate1.cdn.example.com). With this, the client has enough information to directly request the specific segment from the specified Surrogate.
从这个示例URL可以看出，URL既包括请求段的标识符（在本例中为segment1_1.ts），也包括预期交付该段的服务器（在本例中为代理1.cdn.example.com）。这样，客户机就有足够的信息直接从指定的代理请求特定的段。
The advantage of using absolute URLs without redirection is that it allows more flexibility compared to using relative URLs (since segments do not necessarily have to be delivered by the same server) while not requiring per-segment redirection (which would add significant load to the node doing the redirection). The drawback of
在不重定向的情况下使用绝对URL的优点是，与使用相对URL相比，它允许更大的灵活性（因为段不一定必须由同一服务器交付），同时不需要每段重定向（这将为执行重定向的节点增加大量负载）。缺点
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).
这种方法是，每次内容移动到不同的位置（在CDN内或跨CDN）时，都需要修改清单文件。
Though the formats and addresses of Manifest Files and chunk files do not typically differ significantly between live and Video-on-Demand (VoD) content, the time at which the Manifest Files and chunk files become available does differ significantly. For live content, chunk files and their corresponding Manifest Files are created and delivered in real time. This poses a number of potential issues for HAS optimization:
虽然清单文件和区块文件的格式和地址在直播和视频点播（VoD）内容之间通常没有显著差异，但清单文件和区块文件可用的时间确实存在显著差异。对于实时内容，实时创建并交付区块文件及其相应的清单文件。这给HAS优化带来了许多潜在问题：
- With live content, chunk files are made available in real time. This limits the applicability of bundling for content acquisition purposes. Pre-positioning may still be employed; however, any significant latency in the pre-positioning may diminish the value of pre-positioning if a client requests the chunk prior to pre-positioning or if the pre-positioning request is serviced after the chunk playout time has passed.
- 通过实时内容，区块文件可以实时使用。这限制了为获取内容而捆绑的适用性。仍然可以使用预定位；然而，如果客户端在预定位之前请求区块，或者如果在区块播放时间过去之后服务预定位请求，则预定位中的任何显著延迟都可能减小预定位的值。
- In the case of live content, Manifest Files must be updated for each chunk and therefore must be retrieved by the client prior to each chunk request. Any optimization schemes based on Manifest Files must therefore be prepared to optimize on a per-segment request basis. Manifest Files may also be polled multiple times prior to the actual availability of the next chunk.
- 对于实时内容，必须为每个区块更新清单文件，因此客户机必须在每个区块请求之前检索清单文件。因此，任何基于清单文件的优化方案都必须准备好按段请求进行优化。在下一个区块实际可用之前，清单文件也可能被轮询多次。
- Since live Manifest Files are updated as new chunks become available, the cacheability of Manifest Files is limited. Though timestamping and reasonable Time-to-Live (TTL) settings can improve delivery performance, timely replication and delivery of updated Manifest Files are critical to ensuring uninterrupted playback.
- 由于实时清单文件会随着新区块的可用而更新，因此清单文件的可缓存性受到限制。虽然时间戳和合理生存时间（TTL）设置可以提高交付性能，但及时复制和交付更新的清单文件对于确保不间断播放至关重要。
- Manifest Files are typically updated after the corresponding chunk is available for delivery, to prevent premature requests for chunks that are not yet available. HAS optimization approaches that employ dynamic Manifest File generation must be synchronized with chunk creation to prevent playback errors.
- 清单文件通常在相应的区块可供交付后更新，以防止对尚未可用的区块的过早请求。采用动态清单文件生成的HAS优化方法必须与区块创建同步，以防止播放错误。
Stream splicing is used to create media mashups, combining content from multiple sources. A common example in which content resides outside the CDNs is with advertisement insertion, for both VoD and live streams. Manifest Files that contain absolute URLs with redirection may contain chunk or nested Manifest File URLs that point to content not delivered via any of the interconnected CDNs.
流拼接用于创建媒体mashup，组合来自多个源的内容。内容驻留在CDN之外的一个常见示例是视频点播和直播流的广告插入。包含带重定向的绝对URL的清单文件可能包含块或嵌套清单文件URL，这些URL指向未通过任何互连CDN交付的内容。
Furthermore, client and downstream proxy devices may depend on non-URL information provided in the Manifest File (e.g., comments or custom tags) for performing stream splicing. This often occurs outside the scope of the interconnected CDNs. HAS optimization schemes that employ dynamic Manifest File generation or rewriting must be cognizant of chunk URLs, nested Manifest File URLs, and other metadata that should not be modified or removed. Improper modification of these URLs or other metadata may cause playback interruptions and in the case of unplayed advertisements may result in loss of revenue for CSPs.
此外，客户端和下游代理设备可依赖于清单文件中提供的非URL信息（例如，注释或自定义标记）来执行流拼接。这通常发生在互连CDN的范围之外。采用动态清单文件生成或重写的HAS优化方案必须了解区块URL、嵌套清单文件URL和其他不应修改或删除的元数据。对这些URL或其他元数据的不当修改可能会导致播放中断，在未播放广告的情况下，可能会导致CSP收入损失。
In the previous section, some of the unique properties of HAS were discussed. Furthermore, some of the CDN-specific design decisions with regards to addressing chunks have been detailed. In this section, the impact of supporting HAS in CDNI scenarios is discussed.
在上一节中，讨论了HAS的一些独特特性。此外，关于寻址块的一些特定于CDN的设计决策已经详细说明。在本节中，将讨论在CDNI场景中支持HAS的影响。
There are a number of topics, or problem areas, that are of particular interest when considering the combination of HAS and CDNI. For each of these problem areas, it holds that there are a number of different ways in which the CDNI interfaces can deal with them. In general, it can be said that each problem area can either be solved in a way that minimizes the amount of HAS-specific changes to the CDNI interfaces or maximizes the flexibility and efficiency with which the CDNI interfaces can deliver HAS content. The goal for the CDNI WG should probably be to try to find the middle ground between these two extremes and try to come up with solutions that optimize the balance between efficiency and additional complexity.
在考虑HAS和CDNI的结合时，有许多主题或问题领域特别令人感兴趣。对于这些问题中的每一个领域，CDNI接口都有许多不同的方法来处理它们。一般来说，可以说，每个问题区域都可以以最小化对CDNI接口的HAS特定更改的方式来解决，或者以最大化CDNI接口交付HAS内容的灵活性和效率的方式来解决。CDNI工作组的目标可能是试图在这两个极端之间找到折中点，并尝试提出优化效率和额外复杂性之间平衡的解决方案。
In order to allow the WG to make this decision, this section briefly describes each of the following problem areas, together with a number of different options for dealing with them. Section 3.1 discusses the problem of how to deal with file management of groups of files, or content collections. Section 3.2 deals with a related topic: how to do content acquisition of content collections between the Upstream CDN (uCDN) and Downstream CDN (dCDN). After that, Section 3.3 describes the various options for the request routing of HAS content, particularly related to Manifest Files. Section 3.4 talks about a
为了让工作组做出这一决定，本节简要介绍了以下每个问题领域，以及处理这些问题的一些不同选择。第3.1节讨论了如何处理文件组或内容集合的文件管理问题。第3.2节涉及一个相关主题：如何在上游CDN（uCDN）和下游CDN（dCDN）之间对内容集合进行内容获取。之后，第3.3节描述了HAS内容请求路由的各种选项，特别是与清单文件相关的选项。第3.4节讨论了
number of possible optimizations for the logging of HAS content, while Section 3.5 discusses the options regarding URL signing. Finally, Section 3.6 describes different scenarios for dealing with the removal of HAS content from CDNs.
HAS内容日志记录的可能优化数量，而第3.5节讨论了有关URL签名的选项。最后，第3.6节描述了处理从CDN中删除HAS内容的不同场景。
One of the unique properties of HAS content is that it does not consist of a single file or stream but of multiple interrelated files (segments, fragments, and/or Manifest Files). In this document, this group of files is also referred to as a content collection. Another important aspect is the difference between segments and fragments (see Section 2.1).
HAS内容的一个独特属性是它不是由单个文件或流组成，而是由多个相互关联的文件（段、片段和/或清单文件）组成。在本文档中，这组文件也称为内容集合。另一个重要方面是片段和片段之间的差异（见第2.1节）。
Irrespective of whether segments or fragments are used, different CDNs might handle content collections differently from a file management perspective. For example, some CDNs might handle all files belonging to a content collection as individual files that are stored independently from each other. An advantage of this approach is that it makes it easy to cache individual chunks. Other CDNs might store all fragments belonging to a content collection in a bundle, as if they were a single file (e.g., by using a fragmented MP4 container). The advantage of this approach is that it reduces file management overhead.
无论使用的是段还是片段，从文件管理的角度来看，不同的CDN可能会以不同的方式处理内容集合。例如，某些CDN可能将属于内容集合的所有文件作为独立存储的单个文件进行处理。这种方法的一个优点是可以很容易地缓存单个块。其他CDN可能将属于内容集合的所有片段存储在一个捆绑包中，就像它们是一个文件一样（例如，通过使用片段化MP4容器）。这种方法的优点是减少了文件管理开销。
The following subsections look at the various ways with which the CDNI interfaces might deal with these differences in handling content collections from a file management perspective. The different options can be distinguished based on the level of HAS awareness they require on the part of the different CDNs and the CDNI interfaces.
以下小节将从文件管理的角度介绍CDNI接口在处理内容集合时处理这些差异的各种方式。可以根据不同CDN和CDNI接口所需的HAS意识水平来区分不同的选项。
This option assumes no HAS awareness in both the involved CDNs and the CDNI interfaces. This means that the uCDN uses individual files, and the dCDN is not explicitly made aware of the relationship between chunks and doesn't know which files are part of the same content collection. In practice, this scenario would mean that the file management method used by the uCDN is simply imposed on the dCDN as well.
此选项假定在涉及的CDN和CDNI接口中都没有感知。这意味着uCDN使用单个文件，dCDN没有明确地知道块之间的关系，也不知道哪些文件是同一内容集合的一部分。在实践中，这种情况意味着uCDN使用的文件管理方法也被简单地强加在dCDN上。
This scenario also means that it is not possible for the dCDN to use any form of file bundling, such as the single-file mechanism, which can be used to store fragmented content as a single file (see
这种情况还意味着dCDN不可能使用任何形式的文件绑定，如单文件机制，该机制可用于将碎片内容存储为单个文件（请参阅
Section 2.1). The one exception to this rule is the situation where the content is fragmented and the Manifest Files on the uCDN contain byte range requests, in which case the dCDN might be able to acquire fragmented content as a single file (see Section 3.2.2.2).
第2.1节）。此规则的一个例外情况是，内容是分段的，uCDN上的清单文件包含字节范围请求，在这种情况下，dCDN可能能够作为单个文件获取分段内容（请参见第3.2.2.2节）。
Effect on CDNI interfaces:
对CDNI界面的影响：
o None
o 没有一个
Advantages/Drawbacks:
优点/缺点：
+ No HAS awareness necessary in CDNs; no changes to CDNI interfaces necessary
+ 在CDN中没有必要的意识；无需更改CDNI接口
- The dCDN is forced to store chunks as individual files
- dCDN被迫将块存储为单个文件
In some cases, the dCDN might prefer to store fragmented content as a single file on its Surrogates to reduce file management overhead. In order to do so, it needs to be able to either acquire the content as a single file (see Section 3.2.2.2) or to merge the different chunks together and place them in the same container (e.g., fragmented MP4). The downside of this method is that in order to do so, the dCDN needs to be fully HAS aware.
在某些情况下，dCDN可能更愿意将碎片内容作为单个文件存储在其代理上，以减少文件管理开销。为此，它需要能够以单个文件的形式获取内容（参见第3.2.2.2节），或者将不同的块合并在一起，并将它们放在同一个容器中（例如，碎片化MP4）。这种方法的缺点是，为了做到这一点，dCDN需要完全了解。
Effect on CDNI interfaces:
对CDNI界面的影响：
o CDNI Metadata interface: Add fields for indicating the particular type of HAS (e.g., MPEG DASH or HLS) that is used and whether segments or fragments are used
o CDNI元数据接口：添加字段，用于指示所使用的特定类型的HA（例如，MPEG DASH或HLS），以及是否使用段或片段
o CDNI Metadata interface: Add field for indicating the name and type of the Manifest File(s)
o CDNI元数据接口：添加字段，用于指示清单文件的名称和类型
Advantages/Drawbacks:
优点/缺点：
+ Allows the dCDN to store fragmented content as a single file, reducing file management overhead
+ 允许dCDN将碎片内容存储为单个文件，从而减少文件管理开销
- Complex operation, requiring the dCDN to be fully HAS aware
- 复杂的操作，要求dCDN完全了解
An intermediary approach between the two extremes detailed in the previous two sections is one that uses an 'Access Correlation Hint'. This hint, which is added to the CDNI Metadata of all chunks of a particular content collection, indicates that those files are likely
前两节中详细介绍的两个极端之间的中间方法是使用“访问关联提示”的方法。此提示添加到特定内容集合的所有块的CDNI元数据中，表示这些文件可能
to be requested in a short time window from each other. This information can help a dCDN to implement local file storage optimizations for VoD items (e.g., by bundling all files with the same Access Correlation Hint value in a single bundle/file), thereby reducing the number of files it has to manage while not requiring any HAS awareness.
在短时间内相互请求。此信息可帮助dCDN为VoD项目实施本地文件存储优化（例如，通过将具有相同访问相关性提示值的所有文件捆绑到单个捆绑包/文件中），从而减少其必须管理的文件数量，同时不需要任何has感知。
Effect on CDNI interfaces:
对CDNI界面的影响：
o CDNI Metadata interface: Add field for indicating Access Correlation Hint
o CDNI元数据接口：添加用于指示访问关联提示的字段
Advantages/Drawbacks:
优点/缺点：
+ Allows the dCDN to perform file management optimization
+ 允许dCDN执行文件管理优化
+ Does not require any HAS awareness
+ 不需要任何有意识的人
+ Very small impact on CDNI interfaces
+ 对CDNI界面的影响很小
- Expected benefit compared with Option 1.1 is small
- 与方案1.1相比，预期收益较小
Based on the listed pros and cons, the authors recommend that the WG go for Option 1.1 (do nothing). The likely benefits of going for Option 1.3 are not believed to be significant enough to warrant changing the CDNI Metadata interface. Although Option 1.2 would bring definite benefits for HAS-aware dCDNs, going for this option would require significant CDNI extensions that would impact the WG's milestones. The authors therefore don't recommend including it in the current work but mark it as a possible candidate for rechartering once the initial CDNI solution is completed.
根据列出的利弊，作者建议工作组选择选项1.1（什么都不做）。选择选项1.3可能带来的好处不足以保证更改CDNI元数据接口。尽管选项1.2将为HAS aware DCDN带来明确的好处，但采用该选项将需要对CDNI进行重大扩展，这将影响工作组的里程碑。因此，作者不建议将其包括在当前的工作中，但将其标记为一旦初始CDNI溶液完成再刻蚀的可能候选者。
In the previous section, the relationship between file management and HAS in a CDNI scenario was discussed. This section discusses a related topic: content acquisition between two CDNs.
在上一节中，讨论了CDNI场景中文件管理和HAS之间的关系。本节讨论一个相关主题：两个CDN之间的内容获取。
With regards to content acquisition, it is important to note the difference between CDNs that do dynamic acquisition of content and CDNs that perform content pre-positioning. In the case of dynamic acquisition, a CDN only requests a particular content item when a cache miss occurs. In the case of pre-positioning, a CDN proactively places content items on the nodes on which it expects traffic for
关于内容获取，重要的是要注意动态获取内容的CDN和执行内容预定位的CDN之间的区别。在动态采集的情况下，CDN仅在缓存未命中时请求特定的内容项。在预定位的情况下，CDN主动将内容项放置在其期望流量的节点上
that particular content item. For each of these types of CDNs, there might be a benefit in being HAS aware. For example, in the case of dynamic acquisition, being HAS aware means that after a cache miss for a given chunk occurs, that node might not only acquire the requested chunk but might also acquire some related chunks that are expected to be requested in the near future. In the case of pre-positioning, similar benefits can be had.
特定的内容项。对于这些类型的CDN中的每一种，了解它们可能有好处。例如，在动态获取的情况下，感知意味着在给定块的缓存未命中发生后，该节点可能不仅获取请求的块，而且还可能获取预期在不久的将来被请求的一些相关块。在预定位的情况下，可以获得类似的好处。
This option assumes no HAS awareness in both the involved CDNs and the CDNI interfaces. Just as with Option 1.1, discussed earlier with regards to file management, having no HAS awareness means that the dCDN is not aware of the relationship between chunks. In the case of content acquisition, this means that each and every file belonging to a content collection will have to be individually acquired from the uCDN by the dCDN. The exception to the rule is cases with fragmented content where the uCDN uses Manifest Files that contain byte range requests. In this case, the dCDN can simply omit the byte range identifier and acquire the complete file.
此选项假定在涉及的CDN和CDNI接口中都没有感知。正如前面讨论的关于文件管理的选项1.1一样，没有HAS感知意味着dCDN不知道块之间的关系。在内容获取的情况下，这意味着dCDN必须从uCDN中单独获取属于内容集合的每个文件。该规则的例外情况是，在零碎内容的情况下，uCDN使用包含字节范围请求的清单文件。在这种情况下，dCDN可以简单地省略字节范围标识符并获取完整的文件。
The advantage of this approach is that it is highly flexible. If a client only requests a small portion of the chunks belonging to a particular content collection, the dCDN only has to acquire those chunks from the uCDN, saving both bandwidth and storage capacity.
这种方法的优点是非常灵活。如果客户端只请求属于特定内容集合的一小部分块，则dCDN只需从uCDN获取这些块，从而节省带宽和存储容量。
The downside of acquiring content on a per-chunk basis is that it creates more transaction overhead between the dCDN and uCDN, compared to a method in which entire content collections can be acquired as part of one transaction.
以块为单位获取内容的缺点是，与可以作为一个事务的一部分获取整个内容集合的方法相比，它在dCDN和uCDN之间创建了更多的事务开销。
Effect on CDNI interfaces:
对CDNI界面的影响：
o None
o 没有一个
Advantages/Drawbacks:
优点/缺点：
+ Per-chunk content acquisition allows for a high level of flexibility between the dCDN and uCDN
+ 每块内容获取允许dCDN和uCDN之间具有高度的灵活性
- Per-chunk content acquisition creates more transaction overhead between the dCDN and uCDN
- 每区块内容获取会在dCDN和uCDN之间产生更多事务开销
3.2.2.2. Option 2.2: Allow Single-File Acquisition of Fragmented Content
3.2.2.2. 选项2.2：允许对碎片内容进行单文件采集
As discussed in Section 3.2.2.1, there is one (fairly rare) case where fragmented content can be acquired as a single file without any HAS awareness, and that is when fragmented content is used and where the Manifest File specifies byte range requests. This section discusses how to perform single-file acquisition in the other (very common) cases. To do so, the dCDN would have to have full HAS awareness (at least to the extent of being able to map between a single file and individual chunks to serve).
如第3.2.2.1节所述，有一种（相当罕见的）情况，即碎片内容可以作为单个文件获取，而没有任何HAS意识，即使用碎片内容时，清单文件指定字节范围请求。本节讨论如何在其他（非常常见）情况下执行单文件采集。要做到这一点，dCDN必须具有完全的HAS意识（至少能够在单个文件和要服务的单个块之间进行映射）。
Effect on CDNI interfaces:
对CDNI界面的影响：
o CDNI Metadata interface: Add fields for indicating the particular type of HAS (e.g., MPEG DASH or HLS) that is used and whether segments or fragments are used
o CDNI元数据接口：添加字段，用于指示所使用的特定类型的HA（例如，MPEG DASH或HLS），以及是否使用段或片段
o CDNI Metadata interface: Add field for indicating the name and type of the Manifest File(s)
o CDNI元数据接口：添加字段，用于指示清单文件的名称和类型
Advantages/Drawbacks:
优点/缺点：
+ Allows for more efficient content acquisition in all HAS-specific supported forms
+ 允许以所有特定支持的形式更高效地获取内容
- Requires full HAS awareness on the part of the dCDN
- 要求dCDN部分具有完全意识
- Requires significant CDNI Metadata interface extensions
- 需要重要的CDNI元数据接口扩展
Based on the listed pros and cons, the authors recommend that the WG go for Option 2.1, since it is sufficient to 'make HAS work'. While Option 2.2 would bring benefits to the acquisition of large content collections, it would require significant CDNI extensions that would impact the WG's milestones. Option 2.2 might be a candidate to include in possible rechartering once the initial CDNI solution is completed.
基于所列的优点和缺点，作者建议工作组选择选项2.1，因为它足以“使其发挥作用”。虽然选项2.2将为大型内容收藏的收购带来好处，但它需要对CDNI进行重大扩展，这将影响工作组的里程碑。一旦初始镉镍溶液完成，备选方案2.2可能包括在可能的再研磨中。
In this section, the effect HAS content has on request routing is identified. Of particular interest in this case are the different types of Manifest Files that might be used. In Section 2.2, three different methods for identifying and addressing chunks from within a
在本节中，将确定内容对请求路由的影响。在这种情况下，可能使用的不同类型的清单文件尤为重要。在第2.2节中，介绍了三种不同的方法，用于识别和寻址
Manifest File were described: relative URLs, absolute URLs with redirection, and absolute URLs without redirection. Of course, not every current CDN will use and/or support all three methods. Some CDNs may only use one of the three methods, while others may support two or all three.
描述了清单文件：相对URL、带重定向的绝对URL和不带重定向的绝对URL。当然，并非所有当前CDN都将使用和/或支持这三种方法。一些CDN可能只使用三种方法中的一种，而其他CDN可能支持两种或全部三种方法。
An important factor in deciding which chunk-addressing method is used is the CSP. Some CSPs may have a strong preference for a particular method and deliver the Manifest Files to the CDN in a particular way. Depending on the CDN and the agreement it has with the CSP, a CDN may either host the Manifest Files as they were created by the CSP or modify the Manifest File to adapt it to its particular architecture (e.g., by changing relative URLs to absolute URLs that point to the CDN Request Routing function).
决定使用哪种块寻址方法的一个重要因素是CSP。一些CSP可能对特定方法有强烈偏好，并以特定方式将清单文件交付给CDN。根据CDN及其与CSP的协议，CDN可以在CSP创建清单文件时托管清单文件，或者修改清单文件以使其适应其特定体系结构（例如，通过将相对URL更改为指向CDN请求路由功能的绝对URL）。
This option assumes no HAS awareness in both the involved CDNs and the CDNI interfaces. This scenario also assumes that neither the dCDN nor the uCDN has the ability to actively manipulate Manifest Files. As was also discussed with regards to file management and content acquisition, having no HAS awareness means that each file constituting a content collection is handled on an individual basis, with the dCDN unaware of any relationship between files.
此选项假定在涉及的CDN和CDNI接口中都没有感知。此场景还假设dCDN和uCDN都不能主动操作清单文件。正如在文件管理和内容获取方面所讨论的，没有HAS意识意味着构成内容集合的每个文件都是单独处理的，dCDN不知道文件之间的任何关系。
The only chunk-addressing method that works without question in this case is absolute URLs with redirection. In other words, the CSP that ingested the content into the uCDN created a Manifest File with each chunk location pointing to the Request Routing function of the uCDN. Alternatively, the CSP may have ingested the Manifest File containing relative URLs, and the uCDN ingestion function has translated these to absolute URLs pointing to the Request Routing function.
在这种情况下，唯一毫无疑问有效的块寻址方法是带有重定向的绝对URL。换句话说，将内容摄取到uCDN中的CSP创建了一个清单文件，其中每个区块位置都指向uCDN的请求路由功能。或者，CSP可能已经摄取了包含相对URL的清单文件，而uCDN摄取函数已经将这些URL转换为指向请求路由函数的绝对URL。
In this "absolute URL with redirection" case, the uCDN can simply have the Manifest File be delivered by the dCDN as if it were a regular file. Once the client parses the Manifest File, it will request any subsequent chunks from the uCDN Request Routing function. That function can then decide to outsource the delivery of those chunks to the dCDN. Depending on whether HTTP-based (recursive or iterative) or DNS-based request routing is used, the uCDN Request Routing function will then either directly or indirectly redirect the client to the Request Routing function of the dCDN (assuming that it does not have the necessary information to redirect the client directly to a Surrogate in the dCDN).
在这种“带重定向的绝对URL”的情况下，uCDN可以简单地将清单文件作为常规文件由dCDN交付。一旦客户端解析清单文件，它将从uCDN请求路由函数请求任何后续块。然后，该函数可以决定将这些块的交付外包给dCDN。根据使用的是基于HTTP（递归或迭代）还是基于DNS的请求路由，uCDN请求路由功能随后将直接或间接地将客户端重定向到dCDN的请求路由功能（假设它没有必要的信息将客户端直接重定向到dCDN中的代理）.
The drawback of this method is that it creates a large amount of request routing overhead for both the uCDN and dCDN. For each chunk, the full inter-CDN Request Routing process is invoked (which can result in two HTTP redirections in the case of iterative redirection, or one HTTP redirection plus one CDNI Request Routing Redirection interface request/response). Even in the case where DNS-based redirection is used, there might be significant overhead involved, since both the dCDN and uCDN Request Routing functions might have to perform database lookups and query each other. While with DNS this overhead might be reduced by using DNS's inherent caching mechanism, this will have significant impact on the accuracy of the redirect.
这种方法的缺点是，它为uCDN和dCDN创建了大量的请求路由开销。对于每个区块，调用完整的CDN间请求路由过程（在迭代重定向的情况下，这可能导致两个HTTP重定向，或者一个HTTP重定向加上一个CDNI请求路由重定向接口请求/响应）。即使在使用基于DNS的重定向的情况下，也可能会涉及大量开销，因为dCDN和uCDN请求路由功能可能都必须执行数据库查找和相互查询。虽然使用DNS时，通过使用DNS固有的缓存机制可以减少此开销，但这将对重定向的准确性产生重大影响。
With no HAS awareness, relative URLs might or might not work, depending on the type of relative URL that is used. When a uCDN delegates the delivery of a Manifest File containing relative URLs to a dCDN, the client goes directly to the dCDN Surrogate from which it has received the Manifest File for every subsequent chunk. As long as the relative URL is not path-absolute (see [RFC3986]), this approach will work fine.
在没有HAS感知的情况下，相对URL可能工作，也可能不工作，这取决于所使用的相对URL的类型。当uCDN将包含相对URL的清单文件的传递委托给dCDN时，客户机将直接转到dCDN代理，从该代理接收每个后续区块的清单文件。只要相对URL不是绝对路径（请参见[RFC3986]），这种方法就可以正常工作。
Since using absolute URLs without redirection inherently requires a HAS-aware CDN, absolute URLs without redirection cannot be used in this case because the URLs in the Manifest File will point directly to a Surrogate in the uCDN. Since this scenario assumes no HAS awareness on the part of the dCDN or uCDN, it is impossible for either of these CDNs to rewrite the Manifest File and thus allow the client to either go to a Surrogate in the dCDN or to a Request Routing function.
由于使用不带重定向的绝对URL本质上需要具有感知能力的CDN，因此在这种情况下不能使用不带重定向的绝对URL，因为清单文件中的URL将直接指向uCDN中的代理。由于此场景假定dCDN或uCDN没有感知，因此这些CDN都不可能重写清单文件，从而允许客户端转到dCDN中的代理或请求路由函数。
Effect on CDNI interfaces:
对CDNI界面的影响：
o None
o 没有一个
Advantages/Drawbacks:
优点/缺点：
+ Supports absolute URLs with redirection
+ 支持带重定向的绝对URL
+ Supports relative URLs
+ 支持相对URL
+ Does not require HAS awareness and/or changes to the CDNI interfaces
+ 不需要对CDNI接口进行感知和/或更改
- Not possible to use absolute URLs without redirection
- 没有重定向就无法使用绝对URL
- Creates significant signaling overhead in cases where absolute URLs with redirection are used (inter-CDN request redirection for each chunk)
- 在使用带重定向的绝对URL的情况下（每个区块的CDN间请求重定向），会产生显著的信令开销
While Option 3.1 does allow absolute URLs with redirection to be used, it does so in a way that creates a high level of request routing overhead for both the dCDN and the uCDN. This option presents a solution to significantly reduce this overhead.
虽然选项3.1确实允许使用带有重定向的绝对URL，但它这样做的方式为dCDN和uCDN创建了高水平的请求路由开销。此选项提供了一种解决方案，可显著减少此开销。
In this scenario, the uCDN is able to rewrite the Manifest File (or generate a new one) to be able to remove itself from the request routing chain for chunks being referenced in the Manifest File. As described in Section 3.3.2.1, in the case of no HAS awareness, the client will go to the uCDN Request Routing function for each chunk request. This Request Routing function can then redirect the client to the dCDN Request Routing function. By rewriting the Manifest File (or generating a new one), the uCDN is able to remove this first step and have the Manifest File point directly to the dCDN Request Routing function.
在这种情况下，uCDN能够重写清单文件（或生成一个新的清单文件），以便能够将自身从清单文件中引用的区块的请求路由链中移除。如第3.3.2.1节所述，在无HAS感知的情况下，客户端将针对每个区块请求转到uCDN请求路由功能。然后，此请求路由功能可以将客户端重定向到dCDN请求路由功能。通过重写清单文件（或生成新的清单文件），uCDN能够删除第一步，并使清单文件直接指向dCDN请求路由函数。
A key advantage of this solution is that it does not directly have an impact on the CDNI interfaces and is therefore transparent to these interfaces. It is a CDN-internal function that a uCDN can perform autonomously by using information configured for regular CDNI operation or received from the dCDN as part of the regular communication using the CDNI Request Routing Redirection interface.
该解决方案的一个关键优势是，它不会直接影响CDNI接口，因此对这些接口是透明的。这是一个CDN内部功能，uCDN可以通过使用为常规CDNI操作配置的信息或作为使用CDNI请求路由重定向接口的常规通信的一部分从dCDN接收的信息自主执行。
More specifically, in order for the uCDN to rewrite the Manifest File, the minimum information needed is the location of the dCDN Request Routing function (or, alternatively, the location of the dCDN delivering Surrogate). This information can be available from configuration or can be derived from the regular CDNI Request Routing Redirection interface. For example, the uCDN may ask the dCDN for the location of its request routing node (through the CDNI Request Routing Redirection interface) every time a request for a Manifest File is received and processed by the uCDN Request Routing function. The uCDN would then modify the Manifest File and deliver the Manifest File to the client. One advantage of this method is that it maximizes efficiency and flexibility by allowing the dCDN to optionally respond with the locations of its Surrogates instead of the location of its Request Routing function (and effectively turning the URLs into absolute URLs without redirection). There are many variations on this approach, such as where the modification of the Manifest File is only performed once (or once per period of time) by the uCDN Request Routing function, when the first client for that particular content collection (and redirected to that particular dCDN) sends a Manifest File request. The advantage of such a variation is that the uCDN only has to modify the Manifest File once
更具体地说，为了让uCDN重写清单文件，所需的最低信息是dCDN请求路由函数的位置（或者，dCDN传递代理的位置）。此信息可以从配置中获得，也可以从常规CDNI请求路由重定向接口中获得。例如，每当uCDN请求路由功能接收和处理清单文件请求时，uCDN可能会（通过CDNI请求路由重定向接口）向dCDN询问其请求路由节点的位置。然后，uCDN将修改清单文件并将清单文件交付给客户端。此方法的一个优点是，它通过允许dCDN选择性地使用其代理的位置而不是其请求路由功能的位置进行响应（并有效地将URL转换为绝对URL而无需重定向），从而最大限度地提高了效率和灵活性。这种方法有许多变体，例如，当特定内容集合（并重定向到特定dCDN）的第一个客户端发送清单文件请求时，uCDN请求路由功能只执行一次（或每段时间执行一次）清单文件修改。这种变体的优点是uCDN只需修改清单文件一次
(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.
（或每个时间段一次）。这种变化的缺点是dCDN不再能够影响单个内容请求的请求路由决策。
It should be noted that there are a number of things to take into account when changing a Manifest File (see, for example, Sections 2.3 and 2.4 on live HAS content and ad insertion). Furthermore, some CSPs might have issues with a CDN changing Manifest Files. However, in this option the Manifest File manipulation is only being performed by the uCDN, which can be expected to be aware of these limitations if it wants to perform Manifest File manipulation, since it is in its own best interest that its customer's content gets delivered in the proper way and since there is a direct commercial and technical relationship between the uCDN (the Authoritative CDN in this scenario) and its customer (the CSP). Should the CSP want to limit Manifest File manipulation, it can simply arrange this with the uCDN bilaterally.
应该注意的是，在更改清单文件时，有许多事情需要考虑（例如，请参阅关于live HAS内容和广告插入的第2.3节和第2.4节）。此外，一些CSP可能会遇到CDN更改清单文件的问题。但是，在此选项中，清单文件操纵仅由uCDN执行，如果uCDN希望执行清单文件操纵，则可以预期uCDN会意识到这些限制，因为以适当的方式交付其客户的内容符合其自身的最佳利益，而且uCDN（本场景中的权威CDN）与其客户（CSP）之间存在直接的商业和技术关系。如果CSP想要限制清单文件操作，它可以简单地与uCDN双边安排。
Effect on CDNI interfaces:
对CDNI界面的影响：
o None
o 没有一个
Advantages/Drawbacks:
优点/缺点：
+ Possible to significantly decrease signaling overhead when using absolute URLs
+ 使用绝对URL时，可以显著减少信令开销
+ (Optional) Possible to have the uCDN rewrite the Manifest File with locations of Surrogates in the dCDN (turning absolute URLs with redirection into absolute URLs without redirection)
+ （可选）可以让uCDN使用dCDN中的代理位置重写清单文件（将带重定向的绝对URL转换为不带重定向的绝对URL）
+ No changes to CDNI interfaces
+ CDNI接口无变化
+ Does not require HAS awareness in the dCDN
+ 不需要在dCDN中具有感知
- Requires a high level of HAS awareness in the uCDN (for modifying Manifest Files)
- 在uCDN中需要高级别的HAS感知（用于修改清单文件）
One of the possibilities with Option 3.2 is allowing the dCDN to provide the locations of a specific Surrogate to the uCDN, so that the uCDN can fit the Manifest File with absolute URLs without redirection and the client can request chunks directly from a dCDN Surrogate. However, some dCDNs might not be willing to provide this information to the uCDN. In that case, they can only provide the uCDN with the location of their Request Routing function, thereby preventing the use of absolute URLs without redirection.
选项3.2的一个可能性是允许dCDN向uCDN提供特定代理的位置，以便uCDN可以使用绝对URL来适应清单文件，而无需重定向，并且客户端可以直接从dCDN代理请求块。但是，某些DCDN可能不愿意向uCDN提供此信息。在这种情况下，它们只能向uCDN提供其请求路由功能的位置，从而防止在不重定向的情况下使用绝对URL。
One method for solving this limitation is allowing two-step Manifest File manipulation. In the first step, the uCDN would perform its own modification and place the locations of the dCDN Request Routing function in the Manifest File. Then, once a request for the Manifest File comes in at the dCDN Request Routing function, it would perform a second modification in which it replaces the URLs in the Manifest Files with the URLs of its Surrogates. This way, the dCDN can still profit from having limited request routing traffic while not having to share sensitive Surrogate information with the uCDN.
解决此限制的一种方法是允许两步清单文件操作。在第一步中，uCDN将执行自己的修改，并将dCDN请求路由函数的位置放置在清单文件中。然后，一旦在dCDN请求路由函数中收到对清单文件的请求，它将执行第二次修改，将清单文件中的URL替换为其代理的URL。这样，dCDN仍然可以从有限的请求路由流量中获益，而不必与uCDN共享敏感的代理信息。
The downside of this approach is that it not only assumes HAS awareness in the dCDN but also requires some HAS-specific additions to the CDNI Metadata interface. In order for the dCDN to be able to change the Manifest File, it has to have some information about the structure of the content. Specifically, it needs to have information about which chunks make up the content collection.
这种方法的缺点是，它不仅假定在dCDN中具有感知能力，而且还要求对CDNI元数据接口添加一些特定的HAS。为了使dCDN能够更改清单文件，它必须具有有关内容结构的一些信息。具体来说，它需要有关于组成内容集合的块的信息。
Effect on CDNI interfaces (apart from those already listed under Option 3.2):
对CDNI接口的影响（选项3.2中已列出的除外）：
o CDNI Metadata interface: Add necessary fields for conveying HAS-specific information (e.g., the files that make up the content collection) to the dCDN
o CDNI元数据接口：添加必要的字段，以便将特定信息（例如，组成内容集合的文件）传输到dCDN
o CDNI Metadata interface: Allow dCDN to modify Manifest File
o CDNI元数据接口：允许dCDN修改清单文件
Advantages/Drawbacks (apart from those already listed under Option 3.2):
优点/缺点（选项3.2中已列出的除外）：
+ Allows the dCDN to use absolute URLs without redirection, without having to convey sensitive information to the uCDN
+ 允许dCDN在不重定向的情况下使用绝对URL，而不必向uCDN传递敏感信息
- Requires a high level of HAS awareness in the dCDN (for modifying Manifest Files)
- 在dCDN中需要高级别的HAS感知（用于修改清单文件）
- Requires adding HAS-specific and Manifest File manipulation-specific information to the CDNI Metadata interface
- 需要向CDNI元数据接口添加特定于HAS和Manifest文件操作的信息
Based on the listed pros and cons, the authors recommend going for Option 3.1, with Option 3.2 as an optional feature that may be supported as a CDN-internal behavior by a uCDN. While Option 3.1 allows for HAS content to be delivered using the CDNI interfaces, it does so with some limitations regarding supported Manifest Files and, in some cases, with a large amount of signaling overhead. Option 3.2 can solve most of these limitations and presents a significant reduction in request routing overhead. Since Option 3.2 does not
基于列出的优点和缺点，作者建议选择选项3.1，选项3.2作为可选功能，uCDN可能支持作为CDN内部行为。虽然选项3.1允许使用CDNI接口交付HAS内容，但在支持的清单文件方面存在一些限制，在某些情况下，还存在大量的信令开销。选项3.2可以解决大多数这些限制，并显著降低请求路由开销。因为选项3.2没有
require any changes to the CDNI interfaces but only changes the way the uCDN uses the existing interfaces, supporting it is not expected to result in a significant delay of the WG's milestones. The authors recommend that the WG not include Option 3.3, since it raises some questions of potential brittleness and including it would result in a significant delay of the WG's milestones.
要求对CDNI接口进行任何更改，但仅更改uCDN使用现有接口的方式，支持该更改不会导致工作组里程碑的重大延迟。作者建议工作组不包括选项3.3，因为它提出了一些潜在脆性的问题，包括它将导致工作组里程碑的重大延误。
As stated in [RFC6707], the CDNI Logging interface enables details of logs or events to be exchanged between interconnected CDNs.
如[RFC6707]中所述，CDNI日志接口支持在互连CDN之间交换日志或事件的详细信息。
As discussed in [CDNI-LOGGING], the CDNI logging information can be used for multiple purposes, including maintenance/debugging by a uCDN, accounting (e.g., for billing or settlement purposes), reporting and management of end-user experience (e.g., to the CSP), analytics (e.g., by the CSP), and control of content distribution policy enforcement (e.g., by the CSP).
如[CDNI-LOGGING]中所述，CDNI日志信息可用于多种目的，包括uCDN的维护/调试、记帐（例如，用于计费或结算）、最终用户体验的报告和管理（例如，向CSP）、分析（例如，由CSP）以及内容分发策略实施的控制（例如，由顾客服务提供商提供）。
The key consideration for HAS with respect to logging is the potential increase of the number of log records by two to three orders of magnitude, as compared to regular HTTP delivery of a video, since by default log records would typically be generated on a per-chunk-delivery basis instead of a per-content-item-delivery basis. This impacts the scale of every processing step in the logging process (see [CDNI-LOGGING]), including:
HAS在日志记录方面的关键考虑是，与视频的常规HTTP交付相比，日志记录的数量可能会增加两到三个数量级，因为默认情况下，日志记录通常是基于每个块交付而不是基于每个内容项交付生成的。这会影响记录过程中每个处理步骤的规模（参见[CDNI-logging]），包括：
a. Logging information generation and storing on CDN elements (Surrogate, Request Routers, ...)
a. 在CDN元素（代理、请求路由器等）上生成和存储日志信息
b. Logging information aggregation within a CDN
b. 在CDN中记录信息聚合
c. Logging information manipulation (including information protection, filtering, update, and rectification)
c. 日志信息操作（包括信息保护、过滤、更新和纠正）
d. (Where needed) CDNI reformatting of logging information (e.g., reformatting from a CDN-specific format to the CDNI Logging interface format for export by the dCDN to the uCDN)
d. （如需要）日志信息的CDNI重新格式化（例如，从CDN特定格式重新格式化为CDNI日志接口格式，以便dCDN导出到uCDN）
e. Logging exchange via the CDNI Logging interface
e. 通过CDNI日志接口记录交换
f. (Where needed) Logging re-reformatting (e.g., reformatting from the CDNI Logging interface format into a log-consuming application)
f. （如果需要）日志重新格式化（例如，从CDNI日志接口格式重新格式化为日志使用应用程序）
g. Logging consumption/processing (e.g., feed logs into uCDN accounting application, feed logs into uCDN reporting system to provide per-CSP views, feed logs into debugging tools)
g. 记录消耗/处理（例如，将日志馈送至uCDN会计应用程序，将日志馈送至uCDN报告系统以提供每个CSP视图，将日志馈送至调试工具）
Note that there may be multiple instances of steps [f] and [g] running in parallel.
注意，可能有多个步骤[f]和[g]并行运行。
While the CDNI Logging interface is only used to perform step [e], we note that its format directly affects steps [d] and [f] and that its format also indirectly affects the other steps (for example, if the CDNI Logging interface requires per-chunk log records, steps [a], [b], and [d] cannot operate on a per-HAS-session basis, and they also need to operate on a per-chunk basis).
虽然CDNI日志记录接口仅用于执行步骤[e]，但我们注意到其格式直接影响步骤[d]和[f]，其格式也间接影响其他步骤（例如，如果CDNI日志记录接口需要每区块日志记录，则步骤[a]、[b]和[d]不能基于每个会话进行操作，它们还需要基于每个区块进行操作）。
This section discusses the main candidate approaches identified for CDNI in terms of dealing with HAS with respect to logging.
本节讨论了CDNI在处理与日志相关的HAS方面确定的主要候选方法。
In this approach, nothing is done specifically for HAS, so each HAS-chunk delivery is considered, for CDNI logging, as a standalone content delivery. In particular, a separate log record for each HAS-chunk delivery is included in the CDNI Logging interface in step [e] (as defined in Section 3.4.1). This approach requires that steps [a], [b], [c], [d], and [f] also be performed on a per-chunk basis. This approach allows step [g] to be performed either on a per-chunk basis (assuming that step [f] maintains per-chunk records) or in a more "summarized" manner, such as on a per-HAS-session basis (assuming that step [f] summarizes per-chunk records into per-HAS-session records).
在这种方法中，没有专门为HAS做任何事情，因此对于CDNI日志记录，每个HAS区块交付都被视为独立的内容交付。具体而言，步骤[e]（如第3.4.1节所定义）中的CDNI日志记录界面中包含每个HAS区块交付的单独日志记录。这种方法要求步骤[a]、[b]、[c]、[d]和[f]也按块执行。这种方法允许在每个区块的基础上执行步骤[g]（假设步骤[f]维护每个区块的记录），或者以更“概括”的方式执行，例如在每个HAS会话的基础上（假设步骤[f]将每个区块的记录汇总为每个HAS会话记录）。
Effect on CDNI interfaces:
对CDNI界面的影响：
o None
o 没有一个
Advantages/Drawbacks:
优点/缺点：
+ No information loss (i.e., all details of each individual chunk delivery are preserved). While this full level of detail may not be needed for some log-consuming applications (e.g., billing), this full level of detail is likely valuable (and possibly required) for some log-consuming applications (e.g., debugging)
+ 无信息丢失（即，保留每个块传递的所有细节）。虽然某些日志消耗应用程序（例如，计费）可能不需要此完整级别的详细信息，但对于某些日志消耗应用程序（例如，调试），此完整级别的详细信息可能很有价值（并且可能是必需的）
+ Easier integration (at least in the short term) into existing logging tools, since those tools are all capable of handling per-chunk records
+ 更容易集成（至少在短期内）到现有的日志工具中，因为这些工具都能够处理每个区块的记录
+ No extension needed on CDNI interfaces
+ CDNI接口不需要扩展
- High volume of logging information to be handled (storing and processing) at every step of the logging process, from steps [a] to [g] (while summarization in step [f] is conceivable, it may be difficult to achieve in practice without any hints for correlation in the log records)
- 在从步骤[a]到[g]的记录过程的每个步骤中，要处理（存储和处理）大量的记录信息（虽然步骤[f]中的摘要是可以想象的，但在实践中，如果日志记录中没有任何相关提示，可能很难实现）
An interesting question is whether a dCDN could use the CDNI Logging interface specified for the "do nothing" approach to report summarized "per-session" log information in the case where the dCDN performs such summarization. The high-level idea would be that when a dCDN performs HAS log summarization, for its own purposes anyway, this dCDN could include in the CDNI Logging interface one or more log entries for a HAS session (instead of one entry per HAS chunk) that summarize the deliveries of many/all HAS chunks for a session. However, the authors feel that when considering the details of this idea, it is not achievable without explicit agreement between the uCDN and dCDN about how to perform/interpret such summarization. For example, when a HAS session switches between representations, the uCDN and dCDN would have to agree on things such as:
一个有趣的问题是，dCDN是否可以使用为“不做任何事情”方法指定的CDNI日志接口，在dCDN执行此类摘要的情况下报告摘要的“每个会话”日志信息。高级思想是，当dCDN执行HAS日志摘要时，无论如何出于自身的目的，该dCDN可以在CDNI日志接口中包含HAS会话的一个或多个日志条目（而不是每个HAS块一个条目），该日志条目汇总会话的多个/所有HAS块的交付。然而，作者认为，在考虑这一想法的细节时，如果uCDN和dCDN之间没有关于如何执行/解释此类总结的明确协议，就无法实现这一目标。例如，当会话在表示之间切换时，uCDN和dCDN必须在以下事项上达成一致：
o whether the session will be represented by a single log entry (which therefore cannot convey the distribution across representations), or multiple log entries, such as one entry per contiguous period at a given representation (which therefore would be generally very difficult to correlate back into a single session)
o 会话是由单个日志条目表示（因此无法在表示中传递分布），还是由多个日志条目表示，例如在给定表示中每个连续周期一个条目（因此通常很难关联回单个会话）
o what the single URI included in the log entry would correspond to (for example, the Manifest File, top-level playlist, or next-level playlist, ...)
o 日志条目中包含的单个URI对应的内容（例如，清单文件、顶级播放列表或下一级播放列表等）
The authors feel that since explicit agreement is needed between the uCDN and dCDN on how to perform/interpret the summarization, this method can only work if it is specified as part of the CDNI Logging interface, in which case it would effectively boil down to Option 4.4 (full HAS awareness / per-session logs) as defined below.
作者认为，由于uCDN和dCDN之间需要就如何执行/解释摘要达成明确协议，因此只有将此方法指定为CDNI日志接口的一部分时，此方法才能起作用，在这种情况下，它将有效地归结为选项4.4（完整的HAS感知/每会话日志），定义如下。
We note that support by CDNI of a mechanism (independent of HAS) allowing the customization of the fields to be reported in log entries by the dCDN to the uCDN would mitigate concerns related to the scaling of HAS logging, because it ensures that only the necessary subset of fields is actually stored, reported, and processed.
我们注意到，CDNI支持一种机制（独立于HAS），允许dCDN向uCDN自定义日志条目中报告的字段，这将缓解与HAS日志缩放相关的问题，因为它确保只有必要的字段子集被实际存储、报告和处理。
In this approach, a "Content Collection IDentifier (CCID)" field is distributed through the CDNI Metadata interface, and the same CCID value is associated through the CDNI Metadata interface with every chunk of the same content collection. The CCID value needs to be such that it allows, in combination with the content URI, unique identification of a content collection. When the CCID is distributed, and CCID logging is requested from the dCDN, the dCDN Surrogates are to store the CCID value in the corresponding log entries. The objective of this field is to facilitate optional summarization of per-chunk records at step [f] into something along the lines of per-HAS-session logs, at least for the log-consuming applications that do not require per-chunk detailed information (for example, billing).
在这种方法中，“内容集合标识符（CCID）”字段通过CDNI元数据接口分发，相同的CCID值通过CDNI元数据接口与相同内容集合的每个块相关联。CCID值需要能够与内容URI一起允许内容集合的唯一标识。当分发CCID并且从dCDN请求CCID日志记录时，dCDN代理将在相应的日志条目中存储CCID值。该字段的目标是促进在步骤[f]中将每区块记录选择性地汇总为每HAS会话日志，至少对于不需要每区块详细信息（例如计费）的日志消耗应用程序是如此。
We note that if the dCDN happens to have sufficient HAS awareness to be able to generate a "Session IDentifier (Session-ID)", optionally including such a Session-ID (in addition to the CCID) in the per-chunk log record would further facilitate optional summarization at step [f]. The Session-ID value to be included in a log record by the delivering CDN is such that
我们注意到，如果dCDN碰巧具有足够的HAS意识，能够生成“会话标识符（会话ID）”，则在每区块日志记录中可选地包括这样的会话ID（除了CCID之外），将进一步促进步骤[f]中的可选摘要。交付CDN要包含在日志记录中的会话ID值如下
o different per-chunk log records with the same Session-ID value must correspond to the same user session (i.e., delivery of the same content to the same End User at a given point in time).
o 具有相同会话ID值的不同逐块日志记录必须对应于相同的用户会话（即，在给定时间点将相同内容交付给相同的最终用户）。
o log records for different chunks of the same user session (i.e., delivery of the same content to the same End User at a given point in time) should be provided with the same Session-ID value. While undesirable, there may be situations where the delivering CDN uses more than one Session-ID value for different per-chunk log records of a given session -- for example, in scenarios of fail-over or load balancing across multiple Surrogates and where the delivering CDN does not implement mechanisms to synchronize Session-IDs across Surrogates.
o 同一用户会话的不同区块的日志记录（即，在给定时间点向同一最终用户交付相同内容）应具有相同的会话ID值。虽然不需要，但可能存在交付CDN对给定会话的不同每区块日志记录使用多个会话ID值的情况——例如，在跨多个代理进行故障转移或负载平衡的场景中，并且交付CDN未实现跨代理同步会话ID的机制。
Effect on CDNI interfaces:
对CDNI界面的影响：
o CDNI Metadata interface: One additional metadata field (CCID) in the CDNI Metadata interface. We note that a similar content collection ID is discussed for the handling of other aspects of HAS and observe that further thought is needed to determine whether such a CCID should be shared for multiple purposes or should be independent.
o CDNI元数据接口：CDNI元数据接口中的一个附加元数据字段（CCID）。我们注意到，为了处理HAS的其他方面，讨论了类似的内容集合ID，并注意到需要进一步考虑以确定此类CCID是否应为多个目的共享或独立。
o CDNI Logging interface: Two additional fields (CCID and Session-ID) in CDNI logging records.
o CDNI日志接口：CDNI日志记录中的两个附加字段（CCID和会话ID）。
Advantages/Drawbacks:
优点/缺点：
+ No information loss (i.e., all details of each individual chunk delivery are preserved). While this full level of detail may not be needed for some log-consuming applications (e.g., billing), this full level of detail is likely valuable (and possibly required) for some log-consuming applications (e.g., debugging)
+ 无信息丢失（即，保留每个块传递的所有细节）。虽然某些日志消耗应用程序（例如，计费）可能不需要此完整级别的详细信息，但对于某些日志消耗应用程序（例如，调试），此完整级别的详细信息可能很有价值（并且可能是必需的）
+ Easier integration (at least in the short term) into existing logging tools, since those tools are all capable of handling per-chunk records
+ 更容易集成（至少在短期内）到现有的日志工具中，因为这些工具都能够处理每个区块的记录
+ Very minor extension to CDNI interfaces needed
+ 需要对CDNI接口进行非常小的扩展
+ Facilitated summarization of records related to a HAS session in step [f] and therefore ability to operate on a lower volume of logging information in step [g] by log-consuming applications that do not need per-chunk record details (e.g., billing) or that need per-session information (e.g., analytics)
+ 方便地汇总步骤[f]中与HAS会话相关的记录，因此能够通过不需要每个区块记录详细信息（例如计费）或需要每个会话信息（例如分析）的日志消耗应用程序在步骤[g]中操作较低数量的日志信息
- High volume of logging information to be handled (storing and processing) at every step of the logging process, from steps [a] to [f]
- 在记录过程的每个步骤（从步骤[a]到[f]）都要处理（存储和处理）大量记录信息
In this approach, a lossless compression technique is applied to the sets of logging records (e.g., logging files) for transfer on the CDNI Logging interface. The objective of this approach is to reduce the volume of information to be stored and transferred in step [e].
在这种方法中，无损压缩技术应用于日志记录集（例如，日志文件），以便在CDNI日志接口上传输。该方法的目标是减少步骤[e]中要存储和传输的信息量。
Effect on CDNI interfaces:
对CDNI界面的影响：
o One compression mechanism to be included in the CDNI Logging interface
o CDNI日志接口中包含一个压缩机制
Advantages/Drawbacks:
优点/缺点：
+ No information loss (i.e., all details of each individual chunk delivery are preserved). While this full level of detail may not be needed for some log-consuming applications (e.g., billing), this full level of detail is likely valuable (and possibly required) for some log-consuming applications (e.g., debugging)
+ 无信息丢失（即，保留每个块传递的所有细节）。虽然某些日志消耗应用程序（例如，计费）可能不需要此完整级别的详细信息，但对于某些日志消耗应用程序（例如，调试），此完整级别的详细信息可能很有价值（并且可能是必需的）
+ Easier integration (at least in the short term) into existing logging tools, since those tools are all capable of handling per-chunk records
+ 更容易集成（至少在短期内）到现有的日志工具中，因为这些工具都能够处理每个区块的记录
+ Small extension to CDNI interfaces needed
+ 需要对CDNI接口进行小型扩展
+ Reduced volume of logging information in step [e]
+ 步骤[e]中日志记录信息量减少
+ Compression likely to also be applicable to logs for non-HAS content
+ 压缩可能也适用于非HAS内容的日志
- High volume of logging information to be handled (storing and processing) at every step of the logging process, from steps [a] to [g], except step [e].
- 在记录过程的每个步骤（从步骤[a]到[g]）（步骤[e]除外）要处理（存储和处理）的大量记录信息。
In this approach, HAS awareness is assumed across the CDNs interconnected via CDNI, and the necessary information to describe the HAS relationship across all chunks of the same content collection is distributed through the CDNI Metadata interface. In this approach, the dCDN leverages the HAS information distributed through the CDNI Metadata and their HAS awareness, to do one of the following:
在这种方法中，假设通过CDNI互连的CDN中存在HAS感知，并且描述同一内容集合中所有区块之间HAS关系的必要信息通过CDNI元数据接口分发。在这种方法中，dCDN利用通过CDNI元数据分发的HAS信息及其HAS感知来执行以下操作之一：
o directly generate summarized logging information at logging information generation time (which has the benefit of operating on a lower volume of logging information as early as possible in the successive steps of the logging process), or
o 在记录信息生成时直接生成汇总记录信息（这有助于在记录过程的后续步骤中尽早使用较低数量的记录信息），或
o (if per-chunk logs are generated) accurately correlate and summarize per-chunk logs into per-session logs for exchange over the CDNI Logging interface
o （如果生成了每个区块日志）通过CDNI日志接口将每个区块日志准确关联并汇总到每个会话日志中，以便进行交换
Effect on CDNI interfaces:
对CDNI界面的影响：
o CDNI Metadata interface: Significant extension to convey HAS relationship across chunks of a content collection. Note that this extension requires specific support for every HAS protocol to be supported over the CDNI mesh
o CDNI元数据接口：传递跨内容集合块关系的重要扩展。请注意，此扩展需要对CDNI网格上支持的每个HAS协议提供特定支持
o CDNI Logging interface: Extension to specify summarized per-session logs
o CDNI日志记录接口：用于指定每个会话日志摘要的扩展
Advantages/Drawbacks:
优点/缺点：
+ Lower volume of logging information to be handled (storing and processing) at every step of the logging process, from steps [a] to [g]
+ 在记录过程的每个步骤（从步骤[a]到[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)
+ 准确生成摘要日志，因为dCDN中有感知（例如，如果代理还为内容集合的清单文件提供服务，则代理可能能够提取有关所有块之间关系的确定信息）
- Very significant extensions to CDNI interfaces needed, including specific support for available HAS protocols
- 需要对CDNI接口进行非常重要的扩展，包括对可用HAS协议的特定支持
- Very significant additional requirement for HAS awareness on the dCDN and for this HAS awareness to be consistent with the defined CDNI logging summarization
- 对dCDN的HAS意识以及与定义的CDNI日志摘要一致的HAS意识提出了非常重要的额外要求
- Some information loss (i.e., all details of each individual chunk delivery are not preserved). The actual information loss depends on the summarization approach selected (typically, the lower the information loss, the lower the summarization gain), so the right "sweet spot" would have to be selected. While a full level of detail may not be needed for some log-consuming applications (e.g., billing), such a full level of detail is likely valuable (and possibly required) for some log-consuming applications (e.g., debugging)
- 一些信息丢失（即，每个块传递的所有细节都不保留）。实际的信息损失取决于选择的摘要方法（通常，信息损失越低，摘要增益越低），因此必须选择正确的“最佳点”。虽然对于某些日志消耗应用程序（例如，计费）可能不需要完整级别的详细信息，但对于某些日志消耗应用程序（例如，调试），这种完整级别的详细信息可能很有价值（并且可能是必需的）
- Less easy integration (at least in the short term) into existing logging tools, since those tools are all capable of handling per-chunk records but may not be capable of handling CDNI summarized records
- 不太容易集成到现有的测井工具中（至少在短期内），因为这些工具都能够处理每个区块的记录，但可能无法处理CDNI汇总记录
- Challenges in defining behavior (and achieving summarization gain) in the presence of load balancing of a given HAS session across multiple Surrogates (in the same dCDN or a different dCDN)
- 在多个代理（在同一个dCDN或不同的dCDN中）之间存在给定HAS会话的负载平衡时，定义行为（并实现摘要增益）面临的挑战
Because of its benefits (in particular simplicity, universal support by CDNs, and support by all log-consuming applications), the authors recommend that per-chunk logging as described in Section 3.4.2.1 (Option 4.1) be supported by the CDNI Logging interface as a "High Priority" (as defined in [CDNI-REQUIREMENTS]) and be a mandatory capability of CDNs implementing CDNI.
由于其优点（特别是简单性、CDN的通用支持以及所有日志消耗应用程序的支持），作者建议CDNI日志接口将第3.4.2.1节（选项4.1）中所述的每区块日志记录作为“高优先级”（定义见[CDNI-REQUIREMENTS]）予以支持并成为CDN实施CDNI的强制性能力。
Because of its very low complexity and its benefits in facilitating some useful scenarios (e.g., per-session analytics), we recommend that the CCID mechanisms and Session-ID mechanism as described in Section 3.4.2.2 (Option 4.2) be supported by the CDNI Metadata interface and the CDNI Logging interface as a "Medium Priority" (as defined in [CDNI-REQUIREMENTS]) and be an optional capability of CDNs implementing CDNI.
由于其非常低的复杂性及其在促进某些有用场景（例如，每会话分析）方面的优势，我们建议CDNI元数据接口和CDNI日志接口支持第3.4.2.2节（选项4.2）中描述的CCID机制和会话ID机制，作为“中等优先级”（如中所定义）[CDNI-REQUIREMENTS]），并且是实现CDNI的CDN的可选功能。
The authors also recommend that
作者还建议
(i) the ability of the uCDN to request inclusion of the CCID and Session-ID fields (in log entries provided by the dCDN) be supported by the relevant CDNI interfaces
(i) 相关CDNI接口支持uCDN请求包含CCID和会话ID字段（在dCDN提供的日志条目中）的能力
(ii) the ability of the dCDN to include the CCID and Session-ID fields in CDNI log entries (when the dCDN is capable of doing so) be indicated in the CDNI Logging interface (in line with the "customizable" log format expected to be defined independently of HAS)
（ii）在CDNI日志接口中指示dCDN在CDNI日志条目中包括CCID和会话ID字段的能力（当dCDN能够这样做时）（与预期独立于HAS定义的“可定制”日志格式一致）
(iii) items (i) and (ii) be supported as a "Medium Priority" (as defined in [CDNI-REQUIREMENTS]) and be an optional capability of CDNs implementing CDNI
（iii）第（i）项和第（ii）项应作为“中等优先级”（定义见[CDNI-REQUIREMENTS]）予以支持，并作为CDN实施CDNI的可选能力
When performing dCDN selection, a uCDN may want to take into account whether a given dCDN is capable of reporting the CCID and Session-ID. Thus, the authors recommend that the ability of a dCDN to advertise its support of the optional CCID and Session-ID capability be supported by the CDNI Footprint & Capabilities Advertisement interface as a "Medium Priority" (as defined in [CDNI-REQUIREMENTS]).
在执行dCDN选择时，uCDN可能需要考虑给定dCDN是否能够报告CCID和会话ID。因此，作者建议，CDNI Footprint&Capabilities播发接口作为一个应用程序支持dCDN播发其对可选CCID和会话ID功能的支持“中等优先级”（定义见[CDNI-要求]）。
The authors also recommend that a generic mechanism (independent of HAS) be supported that allows the customization of the fields to be reported in logs by CDNs over the CDNI Logging interface -- because of the reduction of the logging information volume exchanged across CDNs that it allows by removing information that is not of interest to the other CDN.
作者还建议采用一种通用机制（独立于HAS）支持通过CDNI日志接口自定义CDN在日志中报告的字段，这是因为通过删除其他CDN不感兴趣的信息，可以减少CDN之间交换的日志信息量。
Because the following can be achieved with very little complexity and can provide some clear storage/communication compression benefits, the authors recommend that, in line with the concept of Option 4.3, some existing very common compression techniques (e.g., gzip) be supported by the CDNI Logging interface as a "Medium Priority" (as defined in [CDNI-REQUIREMENTS]) and be an optional capability of CDNs implementing CDNI.
由于以下内容只需很少的复杂性即可实现，并且可以提供一些明确的存储/通信压缩优势，因此作者建议，根据选项4.3的概念，CDNI日志接口支持一些现有的非常常见的压缩技术（如gzip），作为“中等优先级”（如中所定义）[CDNI-REQUIREMENTS]），并且是实现CDNI的CDN的可选功能。
Because of its complexity, the time it would take to understand the trade-offs of candidate summarization approaches, and the time it would take to specify the corresponding support in the CDNI Logging interface, the authors recommend that the log summarization discussed in Section 3.4.2.4 (Option 4.4) not be supported by the CDNI Logging interface at this stage but that it be kept as a candidate topic of great interest for a rechartering of the CDNI WG once the first set of deliverables is produced. At that time, we suggest investigating the notion of complementing a "push style" CDNI Logging interface that would support summarization via an on-demand "pull type" interface that would in turn allow a uCDN to request the subset of the detailed logging information that it may need but that is lost in the summarized pushed information.
由于其复杂性、理解候选摘要方法的权衡所需的时间以及在CDNI日志界面中指定相应支持所需的时间，作者建议在第3.4.2.4节（选项4.4）中讨论日志摘要在这一阶段，CDNI日志接口不支持此功能，但在第一组可交付成果生成后，它将作为CDNI工作组重新编制的一个重要候选主题。当时，我们建议研究补充“推式”CDNI日志接口的概念，该接口将通过一个按需“拉式”接口支持汇总，该接口反过来允许uCDN请求其可能需要但在汇总的推式信息中丢失的详细日志信息的子集。
The authors note that while a CDN only needs to adhere to the CDNI Logging interface on its external interfaces and can perform logging in a different format within the CDN, any possible CDNI logging approach effectively places some constraints on the dCDN logging format. For example, to support the "do nothing" approach, a CDN needs to perform and retain per-chunk logs. As another example, to support the "full HAS awareness/per-session logs" approach, the dCDN cannot use a logging format that summarizes data in a way that is
作者注意到，虽然CDN只需要在其外部接口上遵循CDNI日志接口，并且可以在CDN内以不同的格式执行日志记录，但任何可能的CDNI日志记录方法都会对dCDN日志记录格式施加一些约束。例如，为了支持“不做任何事情”的方法，CDN需要执行并保留每个区块的日志。另一个例子是，为了支持“完整的感知/每会话日志”方法，dCDN不能使用一种日志格式，该格式以一种
incompatible with the summarization specified for CDNI logging (e.g., summarizes data into a smaller set of information than what is specified for CDNI logging). However, the authors feel that such constraints are (i) inevitable, (ii) outweighed by the benefits of a standardized logging interface, and (iii) acceptable because, in the case of incompatible summarization, most or all CDNs are capable of reverting to per-chunk logging as per the "do nothing" approach that we recommend as the base mandatory approach.
与为CDNI日志记录指定的汇总不兼容（例如，将数据汇总成比为CDNI日志记录指定的信息集更小的信息集）。然而，作者认为这些限制是（i）不可避免的，（ii）被标准化日志接口的好处所压倒，以及（iii）可以接受的，因为在不兼容摘要的情况下，大多数或所有CDN能够按照“不做任何事情”恢复到每区块日志记录我们建议作为基本强制方法的方法。
URL signing is an authorization method for content delivery. This is based on embedding the HTTP URL with information that can be validated to ensure that the request has legitimate access to the content. There are two parts: 1) parameters that convey authorization restrictions (e.g., source IP address and time period) and/or a protected URL portion, and 2) a message digest that confirms the integrity of the URL and authenticates the entity that creates the URL. The authorization parameters can be anything agreed upon between the entity that creates the URL and the entity that validates the URL. A key is used to generate the message digest (i.e., sign the URL) and validate the message digest. The two functions may or may not use the same key.
URL签名是内容交付的一种授权方法。这是基于在HTTP URL中嵌入可以验证的信息，以确保请求具有对内容的合法访问权。有两个部分：1）传递授权限制（例如，源IP地址和时间段）和/或受保护URL部分的参数，以及2）确认URL完整性并验证创建URL的实体的消息摘要。授权参数可以是创建URL的实体和验证URL的实体之间商定的任何内容。密钥用于生成消息摘要（即，对URL签名）并验证消息摘要。这两个功能可能使用同一个键，也可能不使用同一个键。
There are two types of keys used for URL signing: asymmetric keys and symmetric keys. Asymmetric keys always have a key pair made up of a public key and private key. The private key and public key are used for signing and validating the URL, respectively. A symmetric key is the same key that is used for both functions. Regardless of the type of key, the entity that validates the URL has to obtain the key. Distribution of the symmetric key requires security to prevent others from taking it. A public key can be distributed freely, while a private key is kept by the URL signer. The method for key distribution is out of scope for this document.
URL签名使用两种类型的密钥：非对称密钥和对称密钥。非对称密钥总是有一个由公钥和私钥组成的密钥对。私钥和公钥分别用于对URL进行签名和验证。对称密钥是用于两个函数的同一密钥。无论密钥的类型如何，验证URL的实体都必须获取密钥。对称密钥的分发需要安全性，以防止其他人使用它。公钥可以自由分发，而私钥由URL签名者保存。密钥分发方法超出了本文档的范围。
URL signing operates in the following way. A signed URL is provided by the content owner (i.e., URL signer) to the user during website navigation. When the user selects the URL, the HTTP request is sent to the CDN, which validates that URL before delivering the content.
URL签名的操作方式如下。内容所有者（即URL签名者）在网站导航期间向用户提供签名URL。当用户选择URL时，HTTP请求被发送到CDN，CDN在交付内容之前验证该URL。
The authorization lifetime for URL signing is affected by HAS. The expiration time in the authorization parameters of URL signing limits the period that the content referenced by the URL can be accessed. This works for URLs that directly access the media content, but for HAS content the Manifest File contains another layer of URLs that reference the chunks. The chunk URL that is embedded in the content
URL签名的授权生存期受HAS影响。URL签名的授权参数中的过期时间限制了URL引用的内容可以访问的时间。这适用于直接访问媒体内容的URL，但对于内容，清单文件包含引用块的另一层URL。嵌入到内容中的区块URL
may be requested some undetermined amount of time later. The time period between access to the Manifest File and chunk retrieval may vary significantly. The type of content (i.e., live or VoD) impacts this time variance as well. This property of HAS content needs to be addressed for URL signing.
可能会在以后的一段时间内被请求。访问清单文件和区块检索之间的时间段可能会有很大的不同。内容的类型（即直播或视频点播）也会影响这种时间差异。此属性的内容需要为URL签名寻址。
For CDNI, the two types of request routing are DNS-based and HTTP-based. The use of symmetric vs. asymmetric keys for URL signing has implications for the trust model between the CSP and CDNs and for the key distribution method that can be used.
对于CDNI，两种类型的请求路由是基于DNS的和基于HTTP的。URL签名使用对称密钥与非对称密钥对CSP和CDN之间的信任模型以及可使用的密钥分发方法有影响。
DNS-based request routing does not change the URL. In the case of a symmetric key, the CSP and the Authoritative CDN have a business relationship that allows them to share a key (or multiple keys) for URL signing. When the user requests content from the Authoritative CDN, the URL is signed by the CSP. The Authoritative CDN (as a uCDN) redirects the request to a dCDN via DNS. There may be more than one level of redirection to reach the delivering CDN. The user would obtain the IP address from DNS and send the HTTP request to the delivering CDN, which needs to validate the URL. This requires that the key be distributed from the Authoritative CDN to the delivering CDN. This may be problematic when the key is exposed to a delivering CDN that does not have a relationship with the CSP. The combination of DNS-based request routing and symmetric key function is a generic issue for URL signing and not specific to HAS content. In the case of asymmetric keys, the CSP signs the URL with its private key. The delivering CDN validates the URL with the associated public key.
基于DNS的请求路由不会更改URL。在对称密钥的情况下，CSP和权威CDN具有业务关系，允许它们为URL签名共享一个密钥（或多个密钥）。当用户从权威CDN请求内容时，URL由CSP签名。权威CDN（作为uCDN）通过DNS将请求重定向到dCDN。可能存在多个级别的重定向以到达交付CDN。用户将从DNS获得IP地址，并将HTTP请求发送到交付CDN，后者需要验证URL。这要求密钥从权威CDN分发到交付CDN。当密钥暴露于与CSP没有关系的交付CDN时，这可能会有问题。基于DNS的请求路由和对称密钥功能的组合是URL签名的一般问题，而不是特定于HAS内容。对于非对称密钥，CSP使用其私钥对URL进行签名。交付CDN使用关联的公钥验证URL。
HTTP-based request routing changes the URL during the redirection procedure. In the case of a symmetric key, the CSP signs the original URL with the same key used by the Authoritative CDN to validate the URL. The Authoritative CDN (as a uCDN) redirects the request to the dCDN. The new URL is signed by the uCDN with the same key used by the dCDN to validate that URL. The key used by the uCDN to validate the original URL is expected to be different than the key used to sign the new URL. In the case of asymmetric keys, the CSP signs the original URL with its private key. The Authoritative CDN validates that URL with the CSP's public key. The Authoritative CDN redirects the request to the dCDN. The new URL is signed by the uCDN with its private key. The dCDN validates that URL with the uCDN's public key. There may be more than one level of redirection to reach the delivering CDN. The URL signing operation described previously applies at each level between the uCDN and dCDN for both symmetric keys and asymmetric keys.
基于HTTP的请求路由在重定向过程中更改URL。在对称密钥的情况下，CSP使用权威CDN用于验证URL的相同密钥对原始URL进行签名。权威CDN（作为uCDN）将请求重定向到dCDN。新URL由uCDN使用dCDN用于验证该URL的相同密钥进行签名。uCDN用于验证原始URL的密钥应与用于签名新URL的密钥不同。对于非对称密钥，CSP使用其私钥对原始URL进行签名。权威CDN使用CSP的公钥验证该URL。权威CDN将请求重定向到dCDN。新URL由uCDN使用其私钥进行签名。dCDN使用uCDN的公钥验证该URL。可能存在多个级别的重定向以到达交付CDN。前面描述的URL签名操作适用于对称密钥和非对称密钥的uCDN和dCDN之间的每个级别。
URL signing requires support in most of the CDNI interfaces. The CDNI Metadata interface should specify the content that is subject to URL signing and provide information to perform the function. The dCDN should inform the uCDN that it supports URL signing in the asynchronous capabilities information advertisement as part of the Request Routing interface. This allows the CDN selection function in request routing to choose the dCDN with URL signing capability when the CDNI Metadata of the content requires this authorization method. The logging interface provides information on the authorization method (e.g., URL signing) and related authorization parameters used for content delivery. Having the information in the URL is not sufficient to know that the Surrogate enforced the authorization. URL signing has no impact on the control interface.
URL签名需要在大多数CDNI接口中提供支持。CDNI元数据接口应指定受URL签名约束的内容，并提供执行该功能的信息。dCDN应该通知uCDN，它支持异步功能信息公告中的URL签名，作为请求路由接口的一部分。这允许请求路由中的CDN选择功能在内容的CDNI元数据需要此授权方法时选择具有URL签名功能的dCDN。日志界面提供有关授权方法（例如URL签名）和用于内容交付的相关授权参数的信息。在URL中包含信息不足以知道代理实施了授权。URL签名对控件接口没有影响。
This approach means that the CSP can only perform URL signing for the top-level Manifest File. The top-level Manifest File contains chunk URLs or lower-level Manifest File URLs, which are not modified (i.e., no URL signing for the embedded URLs). In essence, the lower-level Manifest Files and chunks are delivered without content access authorization.
这种方法意味着CSP只能对顶级清单文件执行URL签名。顶级清单文件包含未修改的区块URL或较低级别清单文件URL（即，嵌入URL没有URL签名）。本质上，较低级别的清单文件和区块是在没有内容访问授权的情况下交付的。
Effect on CDNI interfaces:
对CDNI界面的影响：
o None
o 没有一个
Advantages/Drawbacks:
优点/缺点：
+ Top-level Manifest File access is protected
+ 顶级清单文件访问受保护
+ The uCDN and dCDN do not need to be aware of HAS content
+ uCDN和dCDN不需要知道HAS内容
- Lower-level Manifest Files and chunks are not protected, making this approach unqualified for content access authorization
- 较低级别的清单文件和区块不受保护，因此这种方法不符合内容访问授权的要求
In addition to URL signing for the top-level Manifest File, the CSP performs flexible URL signing for the lower-level Manifest Files and chunks. For each HAS session, the top-level Manifest File contains signed chunk URLs or signed lower-level Manifest File URLs for the specific session. The lower-level Manifest File contains session-based signed chunk URLs. The CSP generates the Manifest Files dynamically for the session. The chunk (segment/fragment) is delivered with content access authorization using flexible URL signing, which protects the invariant portion of the URL. A "segment" URL (e.g., HLS) is individually signed for the invariant
除了对顶级清单文件进行URL签名外，CSP还对较低级别清单文件和区块执行灵活的URL签名。对于每个HAS会话，顶级清单文件包含特定会话的已签名区块URL或已签名较低级别清单文件URL。较低级别的清单文件包含基于会话的签名区块URL。CSP为会话动态生成清单文件。区块（段/片段）通过使用灵活的URL签名提供内容访问授权，从而保护URL的不变部分。一个“段”URL（例如HLS）为不变量单独签名
URL portion (relative URL) or the entire URL (absolute URL without redirection) in the Manifest File. A "fragment" URL (e.g., HTTP Smooth Streaming) is signed for the invariant portion of the template URL in the Manifest File. More details are provided later in this section. The URL signing expiration time for the chunk needs to be long enough to play the video. There are implications related to signing the URLs in the Manifest File. For live content, the Manifest Files are requested at a high frequency. For VoD content, the Manifest File may be quite large. URL signing can add more computational load and delivery latency in high-volume cases.
清单文件中的URL部分（相对URL）或整个URL（无重定向的绝对URL）。为清单文件中模板URL的不变部分签名“片段”URL（例如HTTP平滑流）。本节后面将提供更多详细信息。区块的URL签名过期时间需要足够长才能播放视频。对清单文件中的URL进行签名会产生一些影响。对于实时内容，清单文件的请求频率很高。对于VoD内容，清单文件可能相当大。URL签名可以在大容量情况下增加更多计算负载和传递延迟。
For HAS content, the Manifest File contains the relative URL, absolute URL without redirection, or absolute URL with redirection for specifying the chunk location. Signing the chunk URL requires that the CSP know the portion of the URL that remains when the content is requested from the delivering CDN Surrogate.
对于HAS内容，清单文件包含相对URL、不带重定向的绝对URL或带重定向的绝对URL以指定区块位置。对区块URL进行签名要求CSP知道当从交付CDN代理请求内容时URL的剩余部分。
For absolute URLs without redirection, the CSP knows that the chunk URL is explicitly linked with the delivering CDN Surrogate and can sign the URL based on that information. Since the entire URL is set and does not change, the Surrogate can validate the URL. The CSP and the delivering CDN are expected to have a business relationship in this case, and so either symmetric keys or asymmetric keys can be used for URL signing.
对于没有重定向的绝对URL，CSP知道区块URL与交付CDN代理显式链接，并且可以基于该信息对URL进行签名。由于整个URL已设置且未更改，代理可以验证URL。在这种情况下，CSP和交付CDN应该具有业务关系，因此可以使用对称密钥或非对称密钥进行URL签名。
For relative URLs, the URL of the Manifest File provides the root location. The method of request routing affects the URL used to ultimately request the chunk from the delivering CDN Surrogate. For DNS, the original URL does not change. This allows the CSP to sign the chunk URL based on the Manifest File URL and the relative URL. For HTTP, the URL changes during redirection. In this case, the CSP does not know the redirected URL that will be used to request the Manifest File. This uncertainty makes it impossible to accurately sign the chunk URLs in the Manifest File. Basically, URL signing using this reference method "as is" for protection of the entire URL is not supported. However, instead of signing the entire URL, the CSP signs the relative URL (i.e., the invariant portion of the URL) and conveys the protected portion in the authorization parameters embedded in the chunk URL. This approach works in the same way as absolute URLs without redirection, except that the HOST part and (part of) the PATH part of the URL are not signed and validated. The security level should remain the same, as content access authorization ensures that the user that requested the content has the proper credentials. This scheme does not seem to compromise the authorization model, since the resource is still protected by the authorization parameters and message digest. Further evaluation of security might be helpful.
对于相对URL，清单文件的URL提供根位置。请求路由的方法会影响用于最终从交付CDN代理请求区块的URL。对于DNS，原始URL不会更改。这允许CSP基于清单文件URL和相对URL对区块URL进行签名。对于HTTP，URL在重定向期间更改。在这种情况下，CSP不知道将用于请求清单文件的重定向URL。这种不确定性使得无法准确地对清单文件中的区块URL进行签名。基本上，不支持使用此引用方法“按原样”进行URL签名以保护整个URL。然而，CSP不是对整个URL进行签名，而是对相对URL（即URL的不变部分）进行签名，并在区块URL中嵌入的授权参数中传递受保护的部分。这种方法的工作方式与绝对URL相同，无需重定向，只是URL的主机部分和（部分）路径部分没有签名和验证。安全级别应保持不变，因为内容访问授权可确保请求内容的用户具有正确的凭据。由于资源仍然受到授权参数和消息摘要的保护，因此此方案似乎不会损害授权模型。进一步评估安全性可能会有所帮助。
For absolute URLs with redirection, the method of request routing affects the URL used to ultimately request the chunk from the delivering CDN Surrogate. This case has the same conditions as those indicated above for the relative URL. The difference is that the URL is for the chunk instead of the Manifest File. For DNS, the chunk URL does not change and can be signed by the CSP. For HTTP, the URL used to deliver the chunk is unknown to the CSP. In this case, the CSP cannot sign the URL, and this method of reference for the chunk is not supported.
对于具有重定向的绝对URL，请求路由方法会影响用于最终从交付CDN代理请求区块的URL。本例的条件与上述相对URL的条件相同。不同之处在于URL是针对区块的，而不是清单文件。对于DNS，区块URL不会更改，可以由CSP签名。对于HTTP，CSP不知道用于传递区块的URL。在这种情况下，CSP无法对URL进行签名，并且不支持区块的这种引用方法。
Effect on CDNI interfaces:
对CDNI界面的影响：
o Requires the ability to exclude the variant portion of the URL in the signing process. (NOTE: Is this issue specific to URL signing support for HAS content and not CDNI?)
o 需要能够在签名过程中排除URL的变体部分。（注意：此问题是否特定于对HAS内容而非CDNI的URL签名支持？）
Advantages/Drawbacks:
优点/缺点：
+ The Manifest File and chunks are protected
+ 清单文件和区块受到保护
+ The uCDN and dCDN do not need to be aware of HAS content
+ uCDN和dCDN不需要知道HAS内容
+ DNS-based request routing with asymmetric keys and HTTP-based request routing for relative URLs and absolute URLs without redirection work
+ 具有非对称密钥的基于DNS的请求路由和用于相对URL和绝对URL的基于HTTP的请求路由，无需重定向工作
- The CSP has to generate Manifest Files with session-based signed URLs and becomes involved in content access authorization for every HAS session
- CSP必须使用基于会话的签名URL生成清单文件，并参与每个has会话的内容访问授权
- Manifest Files are not cacheable
- 清单文件不可缓存
- DNS-based request routing with symmetric keys may be problematic due to the need for transitive trust between the CSP and delivering CDN
- 由于CSP和CDN之间需要传递信任，因此基于DNS的对称密钥请求路由可能存在问题
- HTTP-based request routing for absolute URLs with redirection does not work, because the URL used by the delivering CDN Surrogate is unknown to the CSP
- 带重定向的绝对URL的基于HTTP的请求路由不起作用，因为CSP不知道交付CDN代理所使用的URL
This is similar to the previous section, with the exception that the uCDN performs flexible URL signing for the lower-level Manifest Files and chunks. URL signing for the top-level Manifest File is still provided by the CSP.
这与上一节类似，只是uCDN对较低级别的清单文件和块执行灵活的URL签名。顶级清单文件的URL签名仍然由CSP提供。
Effect on CDNI interfaces:
对CDNI界面的影响：
o Requires the ability to exclude the variant portion of the URL in the signing process. (NOTE: Is this issue specific to URL signing support for HAS content and not CDNI?)
o 需要能够在签名过程中排除URL的变体部分。（注意：此问题是否特定于对HAS内容而非CDNI的URL签名支持？）
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
+ CSP不需要参与每个HAS会话的内容访问授权
+ The dCDN does not need to be aware of HAS content
+ dCDN不需要知道HAS内容
+ DNS-based request routing with asymmetric keys and HTTP-based request routing for relative URLs and absolute URLs without redirection work
+ 具有非对称密钥的基于DNS的请求路由和用于相对URL和绝对URL的基于HTTP的请求路由，无需重定向工作
- The uCDN has to generate Manifest Files with session-based signed URLs and becomes involved in content access authorization for every HAS session
- uCDN必须使用基于会话的签名URL生成清单文件，并参与每个has会话的内容访问授权
- Manifest Files are not cacheable
- 清单文件不可缓存
- The Manifest File needs to be distributed through the uCDN
- 清单文件需要通过uCDN分发
- DNS-based request routing with symmetric keys may be problematic due to the need for transitive trust between the uCDN and non-adjacent delivering CDN
- 由于uCDN和非相邻CDN之间需要传递信任，因此基于DNS的对称密钥请求路由可能存在问题
- HTTP-based request routing for absolute URLs with redirection does not work, because the URL used by the delivering CDN Surrogate is unknown to the uCDN
- 带重定向的绝对URL的基于HTTP的请求路由无效，因为uCDN不知道传递CDN代理所使用的URL
Based on the Authorization Group ID metadata, the CDN validates the URL signing or validates the HTTP cookie for request of content in the group. The CSP performs URL signing for the top-level Manifest File. The top-level Manifest File contains lower-level Manifest File
基于授权组ID元数据，CDN验证URL签名或HTTP cookie以请求组中的内容。CSP对顶级清单文件执行URL签名。顶级清单文件包含较低级别的清单文件
URLs or chunk URLs. The lower-level Manifest Files and chunks are delivered with content access authorization using an HTTP cookie that contains session state associated with authorization of the top-level Manifest File. The Group ID metadata is used to associate the related content (i.e., Manifest Files and chunks). It also specifies content (e.g., regexp method) that needs to be validated by either URL signing or an HTTP cookie. Note that the creator of the metadata is HAS aware. The duration of the chunk access may be included in the URL signing of the top-level Manifest File and set in the cookie. Alternatively, the access control duration could be provided by the CDNI Metadata interface.
URL或区块URL。较低级别的清单文件和区块通过使用HTTP cookie的内容访问授权交付，HTTP cookie包含与顶级清单文件授权相关联的会话状态。组ID元数据用于关联相关内容（即清单文件和块）。它还指定需要通过URL签名或HTTP cookie验证的内容（例如，regexp方法）。请注意，元数据的创建者已经知道。区块访问的持续时间可以包括在顶级清单文件的URL签名中，并在cookie中设置。或者，访问控制持续时间可以由CDNI元数据接口提供。
Effect on CDNI interfaces:
对CDNI界面的影响：
o CDNI Metadata interface: Authorization Group ID metadata identifies the content that is subject to validation of URL signing or validation of an HTTP cookie associated with the URL signing
o CDNI元数据接口：授权组ID元数据标识受URL签名验证或与URL签名关联的HTTP cookie验证的内容
o CDNI Logging interface: Report the authorization method used to validate the request for content delivery
o CDNI日志接口：报告用于验证内容交付请求的授权方法
Advantages/Drawbacks:
优点/缺点：
+ The Manifest File and chunks are protected
+ 清单文件和区块受到保护
+ The CDN does not need to be aware of HAS content
+ CDN不需要知道HAS内容
+ The CSP does not need to change the Manifest Files
+ CSP不需要更改清单文件
- Authorization Group ID metadata is required (i.e., CDNI Metadata interface enhancement)
- 需要授权组ID元数据（即CDNI元数据接口增强）
- Requires the use of an HTTP cookie, which may not be acceptable in some environments (e.g., where some targeted User Agents do not support HTTP cookies)
- 需要使用HTTP cookie，这在某些环境中可能是不可接受的（例如，某些目标用户代理不支持HTTP cookie）
- The Manifest File has to be delivered by the Surrogate
- 清单文件必须由代理提交
The CDN is aware of HAS content and uses URL signing and HTTP cookies for content access authorization. URL signing is fundamentally about authorizing access to a content item or its specific content collections (representations) for a specific user during a time period, possibly also using some other criteria. A chunk is an instance of the sets of chunks referenced by the Manifest File for the content item or its specific content collections. This
CDN知道HAS内容，并使用URL签名和HTTP Cookie进行内容访问授权。URL签名基本上是授权特定用户在一段时间内访问内容项或其特定内容集合（表示），也可能使用其他一些标准。区块是清单文件为内容项或其特定内容集合引用的区块集的实例。这
relationship means that once the dCDN has authorized the Manifest File, it can assume that the associated chunks are implicitly authorized. The new function for the CDN is to link the Manifest File with the chunks for the HTTP session. This can be accomplished by using an HTTP cookie for the HAS session.
关系意味着一旦dCDN对清单文件进行了授权，它就可以假定关联的块是隐式授权的。CDN的新功能是将清单文件与HTTP会话的区块链接起来。这可以通过为HAS会话使用HTTP cookie来实现。
After validating the URL and detecting that the requested content is a top-level Manifest File, the delivering CDN Surrogate sets an HTTP cookie with a signed session token for the HTTP session. When a request for a lower-level Manifest File or chunk arrives, the Surrogate confirms that the HTTP cookie value contains the correct session token. If so, the lower-level Manifest File or chunk is delivered in accordance with the transitive authorization mechanism. The duration of the chunk access may be included in the URL signing of the top-level Manifest File and set in the cookie. The details of the operation are left to be determined later.
验证URL并检测到请求的内容是顶级清单文件后，交付CDN代理为HTTP会话设置一个带有签名会话令牌的HTTP cookie。当对较低级别清单文件或区块的请求到达时，代理项确认HTTP cookie值包含正确的会话令牌。如果是这样，则根据可传递授权机制交付较低级别的清单文件或区块。区块访问的持续时间可以包括在顶级清单文件的URL签名中，并在cookie中设置。操作的细节将留待以后确定。
Effect on CDNI interfaces:
对CDNI界面的影响：
o CDNI Metadata interface: New metadata identifies the content that is subject to validation of URL signing and information in the cookie for the type of HAS content
o CDNI元数据接口：新元数据标识要验证URL签名的内容以及cookie中HAS内容类型的信息
o Request Routing interface: The dCDN should inform the uCDN that it supports URL signing for known HAS content types in the asynchronous capabilities information advertisement. This allows the CDN selection function in request routing to choose the appropriate dCDN when the CDNI Metadata identifies the content
o 请求路由接口：dCDN应通知uCDN，它支持异步功能信息播发中已知HAS内容类型的URL签名。这允许请求路由中的CDN选择功能在CDNI元数据标识内容时选择适当的dCDN
o CDNI Logging interface: Report the authorization method used to validate the request for content delivery
o CDNI日志接口：报告用于验证内容交付请求的授权方法
Advantages/Drawbacks:
优点/缺点：
+ The Manifest File and chunks are protected
+ 清单文件和区块受到保护
+ The CSP does not need to change the Manifest Files
+ CSP不需要更改清单文件
- Requires full HAS awareness on the part of the uCDN and dCDN
- 要求uCDN和dCDN部分具有完全感知
- Requires extensions to CDNI interfaces
- 需要对CDNI接口进行扩展
- Requires the use of an HTTP cookie, which may not be acceptable in some environments (e.g., where some targeted User Agents do not support HTTP cookies)
- 需要使用HTTP cookie，这在某些环境中可能是不可接受的（例如，某些目标用户代理不支持HTTP cookie）
- The Manifest File has to be delivered by the Surrogate
- 清单文件必须由代理提交
The CDN is aware of HAS content and uses URL signing for content access authorization of Manifest Files and chunks. The CDN generates or rewrites the Manifest Files and learns about the chunks based on the Manifest File. The embedded URLs in the Manifest File are signed by the CDN. The duration of the chunk access may be included in the URL signing. The details of the operation are left to be determined later. Since this approach is based on signing the URLs in the Manifest File, the implications for live and VoD content mentioned in Section 3.5.4 apply.
CDN知道HAS内容，并使用URL签名对清单文件和区块进行内容访问授权。CDN生成或重写清单文件，并基于清单文件了解区块。清单文件中嵌入的URL由CDN签名。区块访问的持续时间可以包括在URL签名中。操作的细节将留待以后确定。由于此方法基于对清单文件中的URL进行签名，因此第3.5.4节中提到的直播和VoD内容的含义适用。
Effect on CDNI interfaces:
对CDNI界面的影响：
o CDNI Metadata interface: New metadata identifies the content that is subject to validation of URL signing and information in the cookie for the type of HAS content
o CDNI元数据接口：新元数据标识要验证URL签名的内容以及cookie中HAS内容类型的信息
o Request Routing interface: The dCDN should inform the uCDN that it supports URL signing for known HAS content types in the asynchronous capabilities information advertisement. This allows the CDN selection function in request routing to choose the appropriate dCDN when the CDNI Metadata identifies the content
o 请求路由接口：dCDN应通知uCDN，它支持异步功能信息播发中已知HAS内容类型的URL签名。这允许请求路由中的CDN选择功能在CDNI元数据标识内容时选择适当的dCDN
o CDNI Logging interface: Report the authorization method used to validate the request for content delivery
o CDNI日志接口：报告用于验证内容交付请求的授权方法
Advantages/Drawbacks:
优点/缺点：
+ The Manifest File and chunks are protected
+ 清单文件和区块受到保护
+ The CSP does not need to change the Manifest Files
+ CSP不需要更改清单文件
- Requires full HAS awareness on the part of the uCDN and dCDN
- 要求uCDN和dCDN部分具有完全感知
- Requires extensions to CDNI interfaces
- 需要对CDNI接口进行扩展
- Requires the CDN to generate or rewrite the Manifest File
- 要求CDN生成或重写清单文件
- The Manifest File has to be delivered by the Surrogate
- 清单文件必须由代理提交
The authors consider Option 5.1 (do nothing) unsuitable for access control of HAS content.
作者认为选项5.1（无所事事）不适合访问控制的内容。
Where the HTTP cookie mechanism is supported by the targeted User Agents and the security requirements can be addressed through the proper use of HTTP cookies, the authors recommend using Option 5.4 (Authorization Group ID and HTTP cookie) and therefore that Option 5.4 be supported by the CDNI solution. This method does not require Manifest File manipulation, as Manifest File manipulation may be a significant obstacle to deployment. Otherwise, the authors recommend that Option 5.2 (flexible URL signing by the CSP) or Option 5.3 (flexible URL signing by the uCDN) be used and therefore that flexible URL signing be supported by the CDNI solution. Options 5.2 and 5.3 protect all the content, do not require that the dCDN be aware of HAS, do not impact CDNI interfaces, support all different types of devices, and support the common cases of request routing for HAS content (i.e., DNS-based request routing with asymmetric keys and HTTP-based request routing for relative URLs).
如果目标用户代理支持HTTP cookie机制，并且可以通过正确使用HTTP cookie来满足安全要求，作者建议使用选项5.4（授权组ID和HTTP cookie），因此CDNI解决方案支持选项5.4。此方法不需要操纵清单文件，因为清单文件操纵可能是部署的重大障碍。否则，作者建议使用选项5.2（CSP的灵活URL签名）或选项5.3（uCDN的灵活URL签名），因此CDNI解决方案支持灵活URL签名。选项5.2和5.3保护所有内容，不要求dCDN了解HAS，不影响CDNI接口，支持所有不同类型的设备，并支持HAS内容请求路由的常见情况（即，基于DNS的非对称密钥请求路由和基于HTTP的相对URL请求路由）。
Options 5.5 and 5.6 (HAS awareness in CDNs using HTTP cookies or Manifest Files) have some advantages that should be considered for future support (e.g., a CDN that is aware of HAS content can manage the content more efficiently in a broader context). Content distribution, storage, delivery, deletion, access authorization, etc. can all benefit. Including HAS awareness as part of the current CDNI charter, however, would almost certainly delay the CDNI WG's milestones, and the authors therefore do not recommend it right now.
选项5.5和5.6（在使用HTTP cookies或清单文件的CDN中具有感知能力）具有一些优点，应在未来支持中加以考虑（例如，感知HAS内容的CDN可以在更广泛的上下文中更有效地管理内容）。内容分发、存储、交付、删除、访问授权等都可以从中受益。然而，将HAS意识作为当前CDNI章程的一部分几乎肯定会推迟CDNI工作组的里程碑，因此作者现在不建议这样做。
At some point in time, a uCDN might want to remove content from a dCDN. With regular content, this process can be relatively straightforward; a uCDN will typically send the request for content removal to the dCDN, including a reference to the content that it wants to remove (e.g., in the form of a URL). However, due to the fact that HAS content consists of large groups of files, things might be more complex. Section 3.1 described a number of different scenarios for doing file management on these groups of files, while Section 3.2 listed the options for performing content acquisition on these content collections. This section presents the options for requesting a content purge for the removal of a content collection from a dCDN.
在某个时间点，uCDN可能希望从dCDN中删除内容。对于常规内容，这个过程可以相对简单；uCDN通常会将内容删除请求发送给dCDN，包括对其想要删除的内容的引用（例如，以URL的形式）。但是，由于HAS内容由大量文件组成，因此情况可能更复杂。第3.1节描述了对这些文件组执行文件管理的许多不同场景，而第3.2节列出了对这些内容集合执行内容获取的选项。本节介绍用于请求内容清除以从dCDN中删除内容集合的选项。
The most straightforward way to signal content purge requests is to just send a single purge request for every file that makes up the content collection. While this method is very simple and does not require HAS awareness, it obviously creates signaling overhead between the uCDN and dCDN, since a reference is to be provided for each content chunk to be purged.
发出内容清除请求信号的最直接的方法是只为构成内容集合的每个文件发送一个清除请求。虽然这种方法非常简单，并且不需要HAS感知，但它显然会在uCDN和dCDN之间产生信令开销，因为要清除的每个内容块都要提供一个引用。
Effect on CDNI interfaces:
对CDNI界面的影响：
o None
o 没有一个
Advantages/Drawbacks (apart from those already listed under Option 3.3):
优点/缺点（选项3.3中已列出的除外）：
+ Does not require changes to the CDNI interfaces or HAS awareness
+ 不需要更改CDNI接口或具有感知
- Requires individual purge request for every file making up a content collection (or, alternatively, requires the ability to convey references to all the chunks making up a content collection inside a purge request), which creates signaling overhead
- 对于构成内容集合的每个文件，需要单独的清除请求（或者，需要能够在清除请求中传递对构成内容集合的所有块的引用），这会产生信令开销
There exists a potentially more efficient method for performing content removal of large numbers of files simultaneously. By including a "Purge IDentifier (Purge-ID)" in the metadata of a particular file, it is possible to virtually group together different files making up a content collection. A Purge-ID can take the form of an arbitrary number or string that is communicated as part of the CDNI Metadata interface, and that is the same for all files making up a particular content item but different across different content items. If a uCDN wants to request that the dCDN remove a content collection, it can send a purge request containing this Purge-ID. The dCDN can then remove all files that share the corresponding Purge-ID.
有一种可能更有效的方法可以同时执行大量文件的内容删除。通过在特定文件的元数据中包含“清除标识符（清除ID）”，可以将构成内容集合的不同文件虚拟地组合在一起。清除ID可以采用任意数字或字符串的形式，作为CDNI元数据接口的一部分进行通信，这对于构成特定内容项的所有文件都是相同的，但在不同的内容项之间是不同的。如果uCDN希望请求dCDN删除内容集合，则可以发送包含此purge-ID的清除请求。然后，dCDN可以删除共享相应purge-ID的所有文件。
The advantage of this method is that it is relatively simple to use by both the dCDN and uCDN and requires only limited additions to the CDNI Metadata interface and CDNI Control interface.
此方法的优点是dCDN和uCDN都使用它相对简单，并且只需要对CDNI元数据接口和CDNI控制接口进行有限的添加。
The Purge-ID is similar to the CCID discussed in Section 3.4.2.2 for handling HAS logging, and we note that further thought is needed to determine whether the CCID and Purge-ID should be collapsed into a single element or remain separate elements.
清除ID类似于第3.4.2.2节中讨论的CCID，用于处理HAS日志记录，我们注意到需要进一步考虑以确定CCID和清除ID是否应折叠为单个元素或保持为单独的元素。
Effect on CDNI interfaces:
对CDNI界面的影响：
o CDNI Metadata interface: Add metadata field for indicating Purge-ID
o CDNI元数据接口：添加用于指示清除ID的元数据字段
o CDNI Control interface: Add functionality to convey a Purge-ID in purge requests
o CDNI控制接口：添加功能以在清除请求中传递清除ID
Advantages/Drawbacks:
优点/缺点：
+ Allows for efficient purging of content from a dCDN
+ 允许从dCDN中高效清除内容
+ Does not require HAS awareness on the part of a dCDN
+ 不要求dCDN有意识
Based on the listed pros and cons, the authors recommend that the WG have mandatory support for Option 1.1 (do nothing). In addition, because of its very low complexity and its benefit in facilitating low-overhead purge of large numbers of content items simultaneously, the authors recommend that Purge-IDs (Option 6.2; see Section 3.6.2) be supported as an optional feature by the CDNI Metadata interface and the CDNI Control interface.
根据列出的利弊，作者建议工作组对选项1.1（不做任何事情）提供强制性支持。此外，由于其复杂性非常低，且有利于同时对大量内容项进行低开销清除，作者建议CDNI元数据接口和CDNI控制接口支持清除ID（选项6.2；参见第3.6.2节）作为可选功能。
This section includes some HAS-specific issues that came up during the discussion of this document and that do not fall under any of the categories discussed in the previous sections.
本节包括本文件讨论过程中出现的一些特定问题，这些问题不属于前几节讨论的任何类别。
- As described in Section 2.2, a Manifest File might be delivered by either a CDN or the CSP and thereby be invisible to the CDN delivering the chunks. Obviously, the decision of whether the CDN or CSP delivers the Manifest File is made between the uCDN and CSP, and the dCDN has no choice in the matter. However, some dCDNs might only want to offer their services in the cases where they have access to the Manifest File (e.g., because their internal architecture is based on the knowledge inside the Manifest File). For these cases, it might be useful to include a field in the CDNI Capability Advertisement to allow dCDNs to advertise the fact that they require access to the Manifest File.
- 如第2.2节所述，清单文件可能由CDN或CSP交付，因此对交付区块的CDN不可见。显然，CDN还是CSP交付清单文件的决定是在uCDN和CSP之间做出的，dCDN在这方面没有选择。但是，某些DCDN可能只希望在其有权访问清单文件的情况下提供服务（例如，因为其内部体系结构基于清单文件中的知识）。对于这些情况，在CDNI功能公告中包含一个字段可能会很有用，以允许dCDNs公告它们需要访问清单文件的事实。
This document does not discuss security issues related to HTTP or HAS delivery, as these topics are expected to be discussed in the CDNI WG documents, including [CDNI-FRAMEWORK].
本文档不讨论与HTTP或HAS交付相关的安全问题，因为这些主题预计将在CDNI工作组文档中讨论，包括[CDNI-FRAMEWORK]。
The authors would like to thank Kevin Ma, Stef van der Ziel, Bhaskar Bhupalam, Mahesh Viveganandhan, Larry Peterson, Ben Niven-Jenkins, and Matt Caulfield for their valuable contributions to this document.
作者要感谢Kevin Ma、Stef van der Ziel、Bhaskar Bhupalam、Mahesh Viveganandhan、Larry Peterson、Ben Niven Jenkins和Matt Caulfield对本文件的宝贵贡献。
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, September 2012.
[RFC6707]Niven Jenkins，B.，Le Faucheur，F.，和N.Bitar，“内容分发网络互连（CDNI）问题声明”，RFC 67072012年9月。
[CDNI-FRAMEWORK] Peterson, L., Ed., and B. Davie, "Framework for CDN Interconnection", Work in Progress, February 2013.
[CDNI-FRAMEWORK]Peterson，L.，Ed.，和B.Davie，“CDN互连框架”，正在进行的工作，2013年2月。
[CDNI-LOGGING] Bertrand, G., Ed., Stephan, E., Peterkofsky, R., Le Faucheur, F., and P. Grochocki, "CDNI Logging Interface", Work in Progress, October 2012.
[CDNI-LOGGING]Bertrand，G.，Ed.，Stephan，E.，Peterkofsky，R.，Le Faucheur，F.，和P.Grochocki，“CDNI日志接口”，正在进行的工作，2012年10月。
[CDNI-REQUIREMENTS]
[CDNI-1要求]
Leung, K., Ed., and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", Work in Progress, July 2013.
Leung，K.，Ed.，和Y.Lee，Ed.，“内容分发网络互连（CDNI）要求”，正在进行的工作，2013年7月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
Authors' Addresses
作者地址
Ray van Brandenburg TNO Brassersplein 2 Delft 2612CT the Netherlands
雷范勃兰登堡TNO Brasserspein 2代尔夫特2612荷兰
Phone: +31-88-866-7000
EMail: ray.vanbrandenburg@tno.nl
Phone: +31-88-866-7000
EMail: ray.vanbrandenburg@tno.nl
Oskar van Deventer TNO Brassersplein 2 Delft 2612CT the Netherlands
Oskar van Deventer TNO Brasserspein 2 Delft 2612荷兰
Phone: +31-88-866-7000
EMail: oskar.vandeventer@tno.nl
Phone: +31-88-866-7000
EMail: oskar.vandeventer@tno.nl
Francois Le Faucheur Cisco Systems E.Space Park - Batiment D 6254 Allee des Ormes - BP 1200 06254 Mougins cedex France
Francois Le Faucheur Cisco Systems E.太空公园-巴蒂门特D 6254 Allee des Ormes-英国石油公司1200 06254 Mougins cedex France
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Kent Leung Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
Kent Leung Cisco Systems美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
Phone: +1 408-526-5030
EMail: kleung@cisco.com
Phone: +1 408-526-5030
EMail: kleung@cisco.com