Internet Research Task Force (IRTF) C. Westphal, Ed.
Request for Comments: 7933 Huawei
Category: Informational S. Lederer
ISSN: 2070-1721 D. Posch
C. Timmerer
Alpen-Adria University Klagenfurt
A. Azgin
W. Liu
Huawei
C. Mueller
BitMovin
A. Detti
University of Rome Tor Vergata
D. Corujo
Instituto de Telecomunicacoes Aveiro
J. Wang
City University of Hong Kong
M. Montpetit
MIT
N. Murray
Athlone Institute of Technology
August 2016
Internet Research Task Force (IRTF) C. Westphal, Ed.
Request for Comments: 7933 Huawei
Category: Informational S. Lederer
ISSN: 2070-1721 D. Posch
C. Timmerer
Alpen-Adria University Klagenfurt
A. Azgin
W. Liu
Huawei
C. Mueller
BitMovin
A. Detti
University of Rome Tor Vergata
D. Corujo
Instituto de Telecomunicacoes Aveiro
J. Wang
City University of Hong Kong
M. Montpetit
MIT
N. Murray
Athlone Institute of Technology
August 2016
Adaptive Video Streaming over Information-Centric Networking (ICN)
基于信息中心网络（ICN）的自适应视频流
Abstract
摘要
This document considers the consequences of moving the underlying network architecture from the current Internet to an Information-Centric Networking (ICN) architecture on video distribution. As most of the traffic in future networks is expected to be video, we consider how to modify the existing video streaming mechanisms. Several important topics related to video distribution over ICN are presented. The wide range of scenarios covered includes the following: evolving Dynamic Adaptive Streaming over HTTP (DASH) to work over ICN and leverage the recent ISO/IEC Moving Picture Experts Group (MPEG) standard, layering encoding over ICN, introducing distinct requirements for video using Peer-to-Peer (P2P) mechanisms, adapting the Peer-to-Peer Streaming Protocol (PPSP) for ICN, creating more stringent requirements over ICN because of delay constraints added by Internet Protocol Television (IPTV), and managing digital rights in ICN. Finally, in addition to considering how existing mechanisms would be impacted by ICN, this document lists some research issues to design ICN-specific video streaming mechanisms.
本文档考虑了将基础网络体系结构从当前的Internet转移到视频分发的以信息为中心的网络（ICN）体系结构的后果。由于未来网络中的大部分流量都是视频，所以我们考虑如何修改现有的视频流机制。提出了几个与ICN上视频分发相关的重要主题。涵盖的范围广泛的场景包括：通过HTTP（DASH）发展动态自适应流，以在ICN上工作，并利用最新的ISO/IEC运动图像专家组（MPEG）标准，在ICN上分层编码，使用对等（P2P）机制引入对视频的不同要求，为ICN采用点对点流协议（PPSP），由于互联网协议电视（IPTV）增加的延迟限制，对ICN提出了更严格的要求，并在ICN中管理数字权利。最后，除了考虑ICN对现有机制的影响外，本文还列出了一些设计ICN特定视频流机制的研究问题。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Information-Centric Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网研究工作组（IRTF）的产品。IRTF发布互联网相关研究和开发活动的结果。这些结果可能不适合部署。本RFC代表了互联网研究任务组（IRTF）以信息为中心的网络研究小组的共识。IRSG批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第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/rfc7933.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7933.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Use Case Scenarios for ICN and Video Streaming . . . . . . . 5
4. Video Download . . . . . . . . . . . . . . . . . . . . . . . 6
5. Video Streaming and ICN . . . . . . . . . . . . . . . . . . . 7
5.1. Introduction to Client-Driven Streaming and DASH . . . . 7
5.2. Layered Encoding . . . . . . . . . . . . . . . . . . . . 8
5.3. Interactions of Video Streaming with ICN . . . . . . . . 8
5.3.1. Interactions of DASH with ICN . . . . . . . . . . . . 8
5.3.2. Interaction of ICN with Layered Encoding . . . . . . 10
5.4. Possible Integration of Video Streaming and ICN
Architecture . . . . . . . . . . . . . . . . . . . . . . 11
5.4.1. DASH over CCN . . . . . . . . . . . . . . . . . . . . 11
5.4.2. Testbed, Open-Source Tools, and Dataset . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Use Case Scenarios for ICN and Video Streaming . . . . . . . 5
4. Video Download . . . . . . . . . . . . . . . . . . . . . . . 6
5. Video Streaming and ICN . . . . . . . . . . . . . . . . . . . 7
5.1. Introduction to Client-Driven Streaming and DASH . . . . 7
5.2. Layered Encoding . . . . . . . . . . . . . . . . . . . . 8
5.3. Interactions of Video Streaming with ICN . . . . . . . . 8
5.3.1. Interactions of DASH with ICN . . . . . . . . . . . . 8
5.3.2. Interaction of ICN with Layered Encoding . . . . . . 10
5.4. Possible Integration of Video Streaming and ICN
Architecture . . . . . . . . . . . . . . . . . . . . . . 11
5.4.1. DASH over CCN . . . . . . . . . . . . . . . . . . . . 11
5.4.2. Testbed, Open-Source Tools, and Dataset . . . . . . . 13
6. P2P Video Distribution and ICN . . . . . . . . . . . . . . . 14
6.1. Introduction to PPSP . . . . . . . . . . . . . . . . . . 14
6.2. PPSP over ICN: Deployment Concepts . . . . . . . . . . . 16
6.2.1. PPSP Short Background . . . . . . . . . . . . . . . . 16
6.2.2. From PPSP Messages to ICN Named-Data . . . . . . . . 16
6.2.3. Support of PPSP Interaction through a Pull-Based ICN
API . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.4. Abstract Layering for PPSP over ICN . . . . . . . . . 18
6.2.5. PPSP Interaction with the ICN Routing Plane . . . . . 19
6.2.6. ICN Deployment for PPSP . . . . . . . . . . . . . . . 19
6.3. Impact of MPEG-DASH Coding Schemes . . . . . . . . . . . 20
7. IPTV and ICN . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. IPTV Challenges . . . . . . . . . . . . . . . . . . . . . 21
7.2. ICN Benefits for IPTV Delivery . . . . . . . . . . . . . 22
8. Digital Rights Management in ICN . . . . . . . . . . . . . . 24
8.1. Broadcast Encryption for DRM in ICN . . . . . . . . . . . 24
8.2. AAA-Based DRM for ICN Networks . . . . . . . . . . . . . 27
8.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 27
8.2.2. Implementation . . . . . . . . . . . . . . . . . . . 28
9. Future Steps for Video in ICN . . . . . . . . . . . . . . . . 28
9.1. Large-Scale Live Events . . . . . . . . . . . . . . . . . 29
9.2. Video Conferencing and Real-Time Communications . . . . . 29
9.3. Store-and-Forward Optimized Rate Adaptation . . . . . . 29
9.4. Heterogeneous Wireless Environment Dynamics . . . . . . 30
9.5. Network Coding for Video Distribution in ICN . . . . . . 32
9.6. Synchronization Issues for Video Distribution in ICN . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . 33
11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . 34
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
6. P2P Video Distribution and ICN . . . . . . . . . . . . . . . 14
6.1. Introduction to PPSP . . . . . . . . . . . . . . . . . . 14
6.2. PPSP over ICN: Deployment Concepts . . . . . . . . . . . 16
6.2.1. PPSP Short Background . . . . . . . . . . . . . . . . 16
6.2.2. From PPSP Messages to ICN Named-Data . . . . . . . . 16
6.2.3. Support of PPSP Interaction through a Pull-Based ICN
API . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.2.4. Abstract Layering for PPSP over ICN . . . . . . . . . 18
6.2.5. PPSP Interaction with the ICN Routing Plane . . . . . 19
6.2.6. ICN Deployment for PPSP . . . . . . . . . . . . . . . 19
6.3. Impact of MPEG-DASH Coding Schemes . . . . . . . . . . . 20
7. IPTV and ICN . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. IPTV Challenges . . . . . . . . . . . . . . . . . . . . . 21
7.2. ICN Benefits for IPTV Delivery . . . . . . . . . . . . . 22
8. Digital Rights Management in ICN . . . . . . . . . . . . . . 24
8.1. Broadcast Encryption for DRM in ICN . . . . . . . . . . . 24
8.2. AAA-Based DRM for ICN Networks . . . . . . . . . . . . . 27
8.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 27
8.2.2. Implementation . . . . . . . . . . . . . . . . . . . 28
9. Future Steps for Video in ICN . . . . . . . . . . . . . . . . 28
9.1. Large-Scale Live Events . . . . . . . . . . . . . . . . . 29
9.2. Video Conferencing and Real-Time Communications . . . . . 29
9.3. Store-and-Forward Optimized Rate Adaptation . . . . . . 29
9.4. Heterogeneous Wireless Environment Dynamics . . . . . . 30
9.5. Network Coding for Video Distribution in ICN . . . . . . 32
9.6. Synchronization Issues for Video Distribution in ICN . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . 33
11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 33
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . 34
12.2. Informative References . . . . . . . . . . . . . . . . . 34
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
The unprecedented growth of video traffic has triggered a rethinking of how content is distributed, both in terms of the underlying Internet architecture and in terms of the streaming mechanisms to deliver video objects.
视频流量的空前增长引发了人们对内容分发方式的重新思考，无论是在底层互联网架构方面，还是在交付视频对象的流机制方面。
In particular, the IRTF ICNRG research group has been chartered to study new architectures centered upon information; the main contributor to Internet traffic (and information dissemination) is video, and this is expected to stay the same in the near future. If ICN is expected to become prominent, it will have to support video streaming efficiently.
特别是，IRTF ICNRG研究小组被特许研究以信息为中心的新体系结构；互联网流量（和信息传播）的主要贡献者是视频，预计在不久的将来将保持不变。如果ICN有望成为主流，它就必须高效地支持视频流。
As such, it is necessary to discuss going in two separate directions:
因此，有必要讨论两个不同的方向：
Can the current video streaming mechanisms be leveraged and adapted to an ICN architecture?
当前的视频流机制能否被利用并适应ICN体系结构？
Can (and should) new, ICN-specific video streaming mechanisms be designed to fully take advantage of the new abstractions exposed by the ICN architecture?
可以（也应该）设计新的、特定于ICN的视频流机制，以充分利用ICN体系结构公开的新抽象吗？
This document focuses on the first question in an attempt to define the use cases for video streaming and some requirements. It also focuses on a few scenarios (namely, Netflix-like video streaming, P2P video sharing, and IPTV) and identifies how the existing protocols can be adapted to an ICN architecture. In doing so, it also identifies the main issues with these protocols in this ICN context.
本文档关注第一个问题，试图定义视频流的用例和一些需求。它还关注一些场景（即Netflix视频流、P2P视频共享和IPTV），并确定现有协议如何适应ICN体系结构。在这样做的过程中，它还确定了ICN上下文中这些协议的主要问题。
In addition to this document, other works have considered specific aspects of dynamic adaptive streaming in ICN [Lederer13b] [Lederer13a] [Grandl13] [Detti12]. This document is informed by these works, as well as others.
除本文件外，其他工作还考虑了ICN[Lederer13b][Lederer13a][Grandl13][Detti12]中动态自适应流的特定方面。本文件由这些作品以及其他作品构成。
In this document, we give a brief overview of the existing solutions for the selected scenarios. We then examine the interactions of such existing mechanisms with the ICN architecture and list some of the interactions any video streaming mechanism will have to consider. Finally, we identify some areas for future research.
在本文档中，我们简要概述了所选场景的现有解决方案。然后，我们检查这样的现有机制与ICN架构的相互作用，并列出一些视频流机制必须考虑的交互。最后，我们确定了未来研究的一些领域。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。
For ICN-specific descriptions, we refer to the other research group documents [RFC7476]. For our purpose, we assume here that "ICN" refers to an architecture where content is retrieved by name and with no binding of content to a specific network location.
关于ICN的具体说明，我们参考其他研究组文件[RFC7476]。出于我们的目的，我们在此假设“ICN”指的是一种体系结构，其中内容按名称检索，并且没有将内容绑定到特定的网络位置。
Both live and on-demand consumption of multimedia content come with timing requirements for the delivery of the content. Additionally, real-time use cases (such as audio-video conferencing [Jacobson09a], game streaming, etc.) come with stricter timing requirements. Long startup delays, buffering periods, poor video quality, etc., should be avoided to achieve a better Quality of Experience (QoE) for the consumer of the content. For a definition of QoE in the context of video distribution, please refer to [LeCallet13]. The working definition is as follows:
多媒体内容的实时消费和按需消费都有交付内容的时间要求。此外，实时用例（如音频视频会议[Jacobson09a]、游戏流等）具有更严格的计时要求。应避免较长的启动延迟、缓冲期、较差的视频质量等，以便为内容消费者提供更好的体验质量（QoE）。有关视频分发中QoE的定义，请参阅[LeCallet13]。工作定义如下：
Quality of Experience (QoE) is the degree of delight or annoyance of the user of an application or service. It results from the fulfillment of his or her expectations with respect to the utility and/or enjoyment of the application or service in the light of the user's personality and current state.
体验质量（QoE）是应用程序或服务的用户的高兴或烦恼程度。它是根据用户的个性和当前状态实现其对应用程序或服务的效用和/或享受的期望的结果。
Of course, these requirements are heavily influenced by routing decisions and caching, which are central parts of ICN and that have to be considered when streaming video in such infrastructures.
当然，这些需求受到路由决策和缓存的严重影响，路由决策和缓存是ICN的核心部分，在此类基础设施中进行视频流传输时必须考虑这些因素。
Due to this range of requirements, we find it useful to narrow the focus to four scenarios (more can be included later):
由于这一需求范围，我们发现将重点缩小到四种场景是很有用的（更多内容可在后面介绍）：
o a video download architecture similar to that of Apple iTunes, where the whole file is being downloaded to the client and can be replayed there multiple times;
o 一种类似于苹果iTunes的视频下载架构，将整个文件下载到客户端，并可在客户端多次重放；
o a video streaming architecture for playing back movies, which is relevant for the naming and caching aspects of ICN as well as the interaction with the rate adaptation mechanism necessary to deliver the best QoE to the end user;
o 用于播放电影的视频流体系结构，其与ICN的命名和缓存方面以及与向最终用户提供最佳QoE所需的速率自适应机制的交互相关；
o a P2P architecture for sharing videos, which introduces more stringent routing requirements in terms of locating copies of the content as the location of the peers evolves and peers join and leave the swarm they use to exchange video chunks (for P2P definitions and taxonomy, please refer to RFC 5694; and
o 一种用于共享视频的P2P体系结构，在定位内容副本方面引入了更严格的路由要求，因为对等点的位置不断变化，对等点加入并离开用于交换视频块的群（有关P2P定义和分类，请参阅RFC 5694；以及
o IPTV, which introduces requirements for multicasting and adds stronger delay constraints.
o IPTV引入了对多播的要求，并增加了更强的延迟限制。
Other scenarios, such as video conferencing and real-time video communications, are not explicitly discussed in this document even though they are in scope. Also, events of mass-media distribution, such as a large crowd at a live event, add new requirements to be included in later versions.
其他场景（如视频会议和实时视频通信）在本文档中没有明确讨论，尽管它们在范围内。此外，大众媒体发布的事件，如现场活动中的大量人群，增加了新的要求，以便在以后的版本中包括。
The current state-of-the-art protocols in an IP context can be modified for the ICN architecture. The remainder of this document is organized as follows: Section 4 discusses video download; Section 5 briefly describes DASH [ISO-DASH] and Layered Encoding (Modification Detection Code (MDC), Scalable Video Coding (SVC)); Section 6 focuses on P2P and PPSP; Section 7 highlights the requirements of IPTV; Section 8 describes the issues of DRM; and Section 9 lists some research issues to be solved for ICN-specific video delivery mechanisms.
IP环境中当前最先进的协议可以针对ICN体系结构进行修改。本文件的其余部分组织如下：第4节讨论视频下载；第5节简要介绍了DASH[ISO-DASH]和分层编码（修改检测码（MDC）、可伸缩视频编码（SVC））；第6节重点介绍P2P和PPSP；第7节强调了IPTV的要求；第8节描述了DRM的问题；第9节列出了ICN特定视频传输机制需要解决的一些研究问题。
Video-conferencing and real-time-video communications will be described in further detail in future works. Mass distribution of content at live, large-scale events (stadiums, concert halls, etc.) for which there is no clearly adopted existing protocol is another topic for further research.
视频会议和实时视频通信将在未来的工作中进一步详细描述。在没有明确采用现有协议的现场大型活动（体育场、音乐厅等）中大规模分发内容是进一步研究的另一个课题。
Video download, namely the fetching of a video file from a server or a cache down to the user's local storage, is a natural application of ICN. It should be supported natively without requiring any specific considerations.
视频下载，即将视频文件从服务器或缓存中提取到用户的本地存储，是ICN的自然应用。应该以本机方式支持它，而无需任何具体考虑。
This is supported now by a host of protocols (say, Secure Copy (SCP), FTP, or over HTTP), which would need to be replaced by new ICN-specific protocols to retrieve content in ICNs.
现在有许多协议（例如，安全拷贝（SCP）、FTP或HTTP协议）支持这一点，这些协议需要被新的ICN特定协议所取代，以检索ICN中的内容。
However, current mechanisms are built atop existing transport protocols. Some ICN proposals (Context-Centric Network (CCN) or Named Data Networking (NDN), for instance) attempt to leverage the work done upon these transport protocols. One proposal is to use the TCP congestion window (and the associated Adaptive Increase, Multiplicative Decrease (AIMD)) to decide how many object requests ("Interests" in CCN/NDN terminology) should be in flight at any point in time.
然而，当前的机制是建立在现有传输协议之上的。一些ICN提案（例如，以上下文为中心的网络（CCN）或命名数据网络（NDN））试图利用在这些传输协议上完成的工作。一种建议是使用TCP拥塞窗口（以及相关的自适应递增、乘法递减（AIMD））来决定在任何时间点应该有多少个对象请求（CCN/NDN术语中的“兴趣”）。
It should be noted that ICN intrinsically supports different transport mechanisms, which could achieve better performance than TCP, as they subsume TCP into a special case. For instance, one could imagine a link-by-link transport coupled with caching. This is enabled by the ICN architecture and would facilitate the point-to-point download of video files.
应该注意的是，ICN本质上支持不同的传输机制，这可以实现比TCP更好的性能，因为它们将TCP包含在特殊情况下。例如，可以想象一个链接一个链接的传输与缓存相结合。这是由ICN体系结构实现的，有助于视频文件的点对点下载。
Media streaming over HTTP and, in a further consequence, streaming over the TCP, has become omnipresent in today's Internet. Content providers such as Netflix, Hulu, and Vudu do not deploy their own streaming equipment: they use the existing Internet infrastructure as it is and simply deploy their own services Over The Top (OTT). This streaming approach works surprisingly well without any particular support from the underlying network due to the use of efficient video compression, Content Delivery Networks (CDNs), and adaptive video players. Earlier video streaming research mostly recommended use of the User Datagram Protocol (UDP) combined with the Real-time Transport Protocol (RTP). It assumed it would not be possible to transfer multimedia data smoothly with TCP, because of its throughput variations and large retransmission delays. This point of view has significantly evolved today. HTTP streaming, and especially its most simple form known as progressive download, has become very popular over the past few years because it has some major benefits compared to RTP streaming. As a consequence of the consistent use of HTTP for this streaming method, the existing Internet infrastructure consisting of proxies, caches, and CDNs could be used. Originally, this architecture was designed to support best-effort delivery of files and not real-time transport of multimedia data. Nevertheless, real-time streaming based on HTTP could also take advantage of this architecture, in comparison to RTP, which could not leverage any of the aforementioned components. Another benefit that results from the use of HTTP is that the media stream could easily pass firewalls or Network Address Translation (NAT) gateways, which was definitely a key for the success of HTTP streaming. However, HTTP streaming is not the holy grail of streaming as it also introduces some drawbacks compared to RTP. Nevertheless, in an ICN-based video streaming architecture these aspects also have to be considered.
HTTP上的媒体流，以及TCP上的流，已经在今天的互联网上无处不在。Netflix、Hulu和Vudu等内容提供商不部署自己的流媒体设备：他们使用现有的互联网基础设施，只需部署自己的OTT服务。由于使用了高效的视频压缩、内容交付网络（CDN）和自适应视频播放器，这种流媒体方法在没有底层网络任何特定支持的情况下工作得出奇地好。早期的视频流研究大多建议使用用户数据报协议（UDP）和实时传输协议（RTP）相结合。它假设，由于TCP的吞吐量变化和较大的重传延迟，不可能使用TCP顺利传输多媒体数据。这一观点在今天有了很大的发展。HTTP流，尤其是其最简单的形式，即渐进式下载，在过去几年中变得非常流行，因为与RTP流相比，它有一些主要的优点。由于此流媒体方法一致使用HTTP，因此可以使用由代理、缓存和CDN组成的现有Internet基础设施。最初，该体系结构旨在支持尽最大努力交付文件，而不是实时传输多媒体数据。然而，与RTP相比，基于HTTP的实时流也可以利用这种体系结构，RTP不能利用上述任何组件。使用HTTP的另一个好处是，媒体流可以轻松通过防火墙或网络地址转换（NAT）网关，这无疑是HTTP流成功的关键。然而，HTTP流并不是流的圣杯，因为与RTP相比，它还引入了一些缺点。然而，在基于ICN的视频流体系结构中，也必须考虑这些方面。
The basic concept of DASH [ISO-DASH] is to use segments of media content, which can be encoded at different resolutions, bit rates, etc., as so-called representations. These segments are served by conventional HTTP web servers and can be addressed via HTTP GET requests from the client. As a consequence, the streaming system is pull-based and the entire streaming logic is located on the client, which makes it scalable and allows for adaptation of the media stream to the client's capabilities.
DASH[ISO-DASH]的基本概念是使用媒体内容的片段，这些片段可以以不同的分辨率、比特率等进行编码，作为所谓的表示。这些段由传统的HTTP web服务器提供服务，并且可以通过来自客户端的HTTP GET请求进行寻址。因此，流系统是基于拉的，并且整个流逻辑位于客户机上，这使得它具有可伸缩性，并允许媒体流适应客户机的能力。
In addition to this, the content can be distributed using conventional CDNs and their HTTP infrastructure, which also scales very well. In order to specify the relationship between the contents' media segments and the associated bit rate, resolution, and
除此之外，还可以使用传统的CDN及其HTTP基础架构分发内容，这些基础架构也具有很好的扩展性。为了指定内容的媒体段与相关比特率、分辨率和
timeline, the Media Presentation Description (MPD) is used, which is an XML document. The MPD refers to the available media segments using HTTP URLs, which can be used by the client for retrieving them.
在时间轴中，使用了媒体呈现描述（MPD），这是一个XML文档。MPD是指使用HTTP URL的可用媒体段，客户端可以使用HTTP URL检索这些媒体段。
Another approach for video streaming consists in using layered encoding. Namely, scalable video coding formats the video stream into different layers: a base layer that can be decoded to provide the lowest bit rate for the specific stream and enhancement layers that can be transmitted separately if network conditions allow. The higher layers offer higher resolutions and enhancement of the video quality, while the layered approach allows for adaptation to the network conditions. This is used in an MPEG-4 scalable profile or H.263+. H264SVC is available but not much deployed. JPEG2000 has a wavelet transform approach for layered encoding but has not been deployed much either. It is not clear if the layered approach is fine-grained enough for rate control.
视频流的另一种方法是使用分层编码。即，可伸缩视频编码将视频流格式化为不同的层：可解码以提供特定流的最低比特率的基本层和可在网络条件允许的情况下单独传输的增强层。更高的层提供更高的分辨率和增强的视频质量，而分层方法允许适应网络条件。这在MPEG-4可伸缩配置文件或H.263+中使用。H264SVC可用，但部署不多。JPEG2000有一种用于分层编码的小波变换方法，但也没有部署太多。目前尚不清楚分层方法是否足够细粒度以实现速率控制。
Video streaming (DASH in particular) has been designed with a goal that is aligned with that of most ICN proposals: it is a client-based mechanism that requests items (in this case, chunks of a video stream) by name.
视频流（特别是DASH）的设计目标与大多数ICN提案的目标一致：它是一种基于客户端的机制，按名称请求项目（在本例中为视频流的块）。
ICN and MPEG-DASH [ISO-DASH] have several elements in common:
ICN和MPEG-DASH[ISO-DASH]有几个共同点：
o the client-initiated pull approach;
o 客户发起的拉式方法；
o the content being dealt with in pieces (or chunks);
o 以片段（或块）形式处理的内容；
o the support of efficient replication and distribution of content pieces within the network;
o 支持在网络内高效复制和分发内容片段；
o the scalable, session-free nature of the exchange between the client and the server at the streaming layer: the client is free to request any chunk from any location; and
o 在流媒体层，客户端和服务器之间的交换具有可伸缩、无会话的性质：客户端可以自由地从任何位置请求任何数据块；和
o the support for potentially multiple source locations.
o 支持潜在的多个源位置。
For the last point, DASH may list multiple source URLs in a manifest, and ICN is agnostic to the location of a copy it is receiving. We do not imply that current video streaming mechanisms attempt to draw the
最后一点，DASH可能在清单中列出多个源URL，ICN不知道它正在接收的副本的位置。我们并不意味着当前的视频流机制试图绘制
content from multiple sources concurrently. This is a potential benefit of ICN but is not considered in the current approaches mentioned in this document.
同时从多个来源获取内容。这是ICN的一个潜在好处，但本文件中提到的当前方法并未考虑到这一点。
As ICN is a promising candidate for the Future Internet (FI) architecture, it is useful to investigate its suitability in combination with multimedia streaming standards like MPEG-DASH. In this context, the purpose of this section is to present the usage of ICN instead of HTTP in MPEG-DASH.
由于ICN是未来互联网（FI）体系结构的一个很有希望的候选者，因此研究其与MPEG-DASH等多媒体流标准结合的适用性非常有用。在这种情况下，本节的目的是介绍在MPEG-DASH中ICN而不是HTTP的使用。
However, there are some issues that arise from using a dynamic rate adaptation mechanism in an ICN architecture (note that some of the issues are related to caching and are not necessarily unique to ICN):
但是，在ICN体系结构中使用动态速率自适应机制会产生一些问题（请注意，有些问题与缓存有关，不一定是ICN独有的）：
o Naming of the data in DASH does not necessarily follow the ICN convention of any of the ICN proposals. Several chunks of the same video stream might currently go by different names that, for instance, do not share a common prefix. There is a need to harmonize the naming of the chunks in DASH with the naming conventions of the ICN. The naming convention of using a filename/time/encoding format could, for instance, be made compatible with the convention of CCN.
o DASH中数据的命名不一定遵循任何ICN提案的ICN约定。同一视频流的多个块当前可能使用不同的名称，例如，不共享公共前缀。有必要将破折号中块的命名与ICN的命名约定相协调。例如，使用文件名/时间/编码格式的命名约定可以与CCN约定兼容。
o While chunks can be retrieved from any server, the rate adaptation mechanism attempts to estimate the available network bandwidth so as to select the proper playback rate and keep its playback buffer at the proper level. Therefore, there is a need to either include some location semantics in the data chunks so as to properly assess the throughput to a specific location or to design a different mechanism to evaluate the available network bandwidth.
o 虽然可以从任何服务器检索块，但速率自适应机制尝试估计可用的网络带宽，以便选择适当的播放速率并将其播放缓冲区保持在适当的级别。因此，需要在数据块中包含一些位置语义，以便正确评估特定位置的吞吐量，或者设计不同的机制来评估可用网络带宽。
o The typical issue of access control and accounting happens in this context, where chunks can be cached in the network outside of the administrative control of the content publisher. It might be a requirement from the owner of the video stream that access to these data chunks needs to be accounted/billed/monitored.
o 访问控制和记帐的典型问题发生在这种情况下，块可以缓存在内容发布者管理控制之外的网络中。视频流所有者可能要求对这些数据块的访问进行记帐/计费/监控。
o Dynamic streaming multiplies the representations of a given video stream, therefore diminishing the effectiveness of caching: namely, to get a hit for a chunk in the cache, it has to be for the same format and encoding values. Alternatively, to get the same hit rate as a stream using a single encoding, the cache size must be scaled up to include all the possible representations.
o 动态流将给定视频流的表示形式成倍增加，因此降低了缓存的有效性：即，要获得缓存中块的命中率，它必须具有相同的格式和编码值。或者，要获得与使用单一编码的流相同的命中率，必须放大缓存大小以包含所有可能的表示。
o Caching introduces oscillatory dynamics as it may modify the estimation of the available bandwidth between the end user and the repository from which it is getting the chunks. For instance, if an edge cache holds a low resolution representation near the user,
o 缓存引入了振荡动力学，因为它可能会修改最终用户和存储库之间可用带宽的估计值，而存储库正是从中获取数据块的。例如，如果边缘缓存在用户附近保留低分辨率表示，
the user getting these low resolution chunks will observe a good performance and will then request higher resolution chunks. If those are hosted on a server with poor performance, then the client would have to switch back to the low representation. This oscillation may be detrimental to the perceived QoE of the user.
获得这些低分辨率块的用户将观察到良好的性能，然后将请求更高分辨率块。如果它们托管在性能较差的服务器上，那么客户端将不得不切换回低表示。这种振荡可能对用户的感知QoE有害。
o The ICN transport mechanism needs to be compatible to some extent with DASH. To take a CCN example, the rate at which interests are issued should be such that the chunks received in return arrive fast enough and with the proper encoding to keep the playback buffer above some threshold.
o ICN传输机制需要在一定程度上与DASH兼容。以CCN为例，利息的发放速率应确保作为回报接收到的块足够快，并且具有适当的编码，以使播放缓冲区保持在某个阈值以上。
o The usage of multiple network interfaces is possible in ICN, enabling a seamless handover between them. For the combination with DASH, an intelligent strategy that should focus on traffic load-balancing between the available links may be necessary. This would increase the effective media throughput of DASH by leveraging the combined available bandwidth of all links; however, it could potentially lead to high variations of the media throughput.
o 在ICN中可以使用多个网络接口，从而实现它们之间的无缝切换。对于与DASH的结合，可能需要一种智能策略，该策略应关注可用链路之间的流量负载平衡。这将通过利用所有链路的组合可用带宽提高DASH的有效媒体吞吐量；然而，它可能导致媒体吞吐量的高度变化。
o DASH does not define how the MPD is retrieved; hence, this is compatible with CCN. However, the current profiles defined within MPEG-DASH require the MPD to contain HTTP URLs (including HTTP and HTTPS URI schemes) to identify segments. To enable a more integrated approach as described in this document, an additional profile for DASH over CCN has to be defined, enabling ICN/CCN-based URIs to identify and request the media segments.
o DASH未定义如何检索MPD；因此，这与CCN兼容。但是，MPEG-DASH中定义的当前配置文件要求MPD包含HTTP URL（包括HTTP和HTTPS URI方案）以标识段。为了实现本文档中所述的更集成的方法，必须定义一个额外的破折号CCN配置文件，使基于ICN/CCN的URI能够识别和请求媒体段。
We describe in Section 5.4 a potential implementation of a dynamic adaptive video stream over ICN, based upon DASH and CCN [Jacobson09b].
我们在第5.4节中描述了基于DASH和CCN的ICN上动态自适应视频流的潜在实现[Jacobson09b]。
Issues of interest to an ICN architecture in the context of layered video streaming include:
分层视频流上下文中ICN体系结构感兴趣的问题包括：
o Caching of the multiple layers. The caching priority should go to the base layer and to defining caching policy in order to decide when to cache enhancement layers;
o 多层缓存。缓存优先级应转到基本层和定义缓存策略，以便决定何时缓存增强层；
o Synchronization of multiple content streams, as the multiple layers may come from different sources in the network (for instance, the base layer might be cached locally while the enhancement layers may be stored in the origin server). Video and audio-video streams must be synchronized, and this includes both intra-layer synchronization (for the layers of the same video or
o 多个内容流的同步，因为多个层可能来自网络中的不同来源（例如，基本层可能在本地缓存，而增强层可能存储在源服务器中）。视频和音频视频流必须同步，这包括层内同步（对于同一视频或视频的层）
audio stream) and inter-stream synchronization (see Section 9 for other synchronization aspects to be included in the "Future Steps for Video in ICN"); and
音频流）和流间同步（参见第9节了解“ICN中视频的未来步骤”中包含的其他同步方面）；和
o Naming of the different layers: when the client requests an object, the request can be satisfied with the base layer alone, aggregated with enhancement layers. Should one request be sufficient to provide different streams? In a CCN architecture, for instance, this would violate a "one Interest, one Data packet" principle and the client would need to specify each layer it would like to receive. In a Pub/Sub architecture, the Rendezvous Point would have to make a decision as to which layers (or which pointer to which layer's location) to return.
o 不同层的命名：当客户机请求一个对象时，可以仅通过基础层（与增强层聚合）来满足请求。一个请求是否足以提供不同的流？例如，在CCN体系结构中，这将违反“一个兴趣，一个数据包”原则，客户端需要指定它想要接收的每一层。在发布/订阅体系结构中，集合点必须决定返回哪个层（或哪个指针指向哪个层的位置）。
DASH is intended to enable adaptive streaming, i.e., each content piece can be provided in different qualities, formats, languages, etc., to cope with the diversity of today's networks and devices. As this is an important requirement for Future Internet proposals like CCN, the combination of those two technologies seems to be obvious. Since those two proposals are located at different protocol layers -- DASH at the application and CCN at the network layer -- they can be combined very efficiently to leverage the advantages of both and potentially eliminate existing disadvantages. As CCN is not based on classical host-to-host connections, it is possible to consume content from different origin nodes as well as over different network links in parallel, which can be seen as an intrinsic error resilience feature with respect to the network. This is a useful feature of CCN for adaptive multimedia streaming within mobile environments since most mobile devices are equipped with multiple network links like 3G and Wi-Fi. CCN offers this functionality out of the box, which is beneficial when used for DASH-based services. In particular, it is possible to enable adaptive video streaming handling both bandwidth and network link changes. That is, CCN handles the network link decision and DASH is implemented on top of CCN to adapt the video stream to the available bandwidth.
DASH旨在实现自适应流式传输，即每个内容片段可以以不同的质量、格式、语言等提供，以应对当今网络和设备的多样性。由于这是像CCN这样的未来互联网提案的一个重要要求，这两种技术的结合似乎是显而易见的。由于这两个方案位于不同的协议层——应用程序层的DASH和网络层的CCN——它们可以非常有效地结合起来，以利用两者的优点，并潜在地消除现有的缺点。由于CCN不是基于传统的主机到主机连接，因此可以并行地使用来自不同源节点以及通过不同网络链路的内容，这可以被视为网络固有的容错功能。这是CCN用于移动环境中自适应多媒体流的一个有用功能，因为大多数移动设备都配备了多个网络链路，如3G和Wi-Fi。CCN提供了这种开箱即用的功能，这在用于基于仪表板的服务时非常有用。特别是，可以启用自适应视频流处理带宽和网络链路变化。也就是说，CCN处理网络链路决策，DASH在CCN之上实现，以使视频流适应可用带宽。
In principle, there are two options to integrate DASH and CCN: a proxy service acting as a broker between HTTP and CCN as proposed in [Detti12], and the DASH client implementing a native CCN interface. The former transforms an HTTP request to a corresponding Interest packet as well as a Data packet back to an HTTP response, including reliable transport as offered by TCP. This may be a good compromise to implement CCN in a managed network and to support legacy devices. Since such a proxy is already described in [Detti12], this document
原则上，集成DASH和CCN有两种选择：代理服务作为HTTP和CCN之间的代理（如[Detti12]中所述），DASH客户端实现本机CCN接口。前者将HTTP请求转换为相应的兴趣包，并将数据包转换回HTTP响应，包括TCP提供的可靠传输。这可能是在受管网络中实现CCN和支持传统设备的一个很好的折衷方案。由于[Detti12]中已经描述了此类代理，因此本文件
focuses on a more integrated approach, aiming at fully exploiting the potential of a CCN DASH client. That is, we describe a native CCN interface within the DASH client, which adopts a CCN naming scheme (CCN URIs) to denote segments in the MPD. In this architecture, only the network access component on the client has to be modified and the segment URIs within MPD have to be updated according to the CCN naming scheme.
重点介绍一种更为集成的方法，旨在充分利用CCN DASH客户端的潜力。也就是说，我们描述了DASH客户端中的本机CCN接口，它采用CCN命名方案（CCN URI）来表示MPD中的段。在此架构中，只需修改客户端上的网络访问组件，并且必须根据CCN命名方案更新MPD中的段URI。
Initially, the DASH client retrieves the MPD containing the CCN URIs of the content representations including the media segments. The naming scheme of the segments may reflect intrinsic features of CCN like versioning and segmentation support. Such segmentation support is already compulsory for multimedia streaming in CCN; thus, it can also be leveraged for DASH-based streaming over CCN. The CCN versioning can be adopted in a further step to signal different representations of the DASH-based content, which enables an implicit adaptation of the requested content to the clients' bandwidth conditions. That is, the Interest packet already provides the desired characteristics of a segment (such as bit rate, resolution, etc.) within the content name (or potentially within parameters defined as extra types in the packet formats). Additionally, if bandwidth conditions of the corresponding interfaces or routing paths allow so, DASH media segments could be aggregated automatically by the CCN nodes, which reduces the amount of Interest packets needed to request the content. However, such approaches need further research, specifically in terms of additional intelligence and processing power needed at the CCN nodes.
最初，DASH客户端检索包含内容表示（包括媒体段）的CCN URI的MPD。段的命名方案可能反映CCN的固有特性，如版本控制和段支持。这种分段支持对于CCN中的多媒体流已经是强制性的；因此，它也可以用于CCN上基于DASH的流式传输。在进一步的步骤中，可以采用CCN版本控制来表示基于DASH的内容的不同表示，这使得所请求的内容能够隐式地适应客户端的带宽条件。也就是说，兴趣分组已经在内容名称内（或者可能在分组格式中定义为额外类型的参数内）提供了段的期望特征（例如比特率、分辨率等）。此外，如果相应接口或路由路径的带宽条件允许，则CCN节点可以自动聚合DASH媒体段，从而减少请求内容所需的感兴趣数据包的数量。然而，此类方法需要进一步研究，特别是在CCN节点所需的额外智能和处理能力方面。
After requesting the MPD, the DASH client will start to request particular segments. Therefore, CCN Interest packets are generated by the CCN access component and forwarded to the available interfaces. Within the CCN, these Interest packets leverage the efficient interest aggregation for, e.g., popular content, as well as the implicit multicast support. Finally, the Interest packets are satisfied by the corresponding Data packets containing the video segment data, which are stored on the origin server or any CCN node, respectively. With an increasing popularity of the content, it will be distributed across the network resulting in lower transmission delays and reduced bandwidth requirements for origin servers and content providers, respectively.
请求MPD后，DASH客户端将开始请求特定的数据段。因此，CCN兴趣分组由CCN接入组件生成并转发到可用接口。在CCN内，这些兴趣包利用例如流行内容的有效兴趣聚合以及隐式多播支持。最后，包含视频片段数据的相应数据包满足感兴趣的数据包，这些数据包分别存储在源服务器或任何CCN节点上。随着内容的日益普及，它将分布在整个网络中，从而分别降低源服务器和内容提供商的传输延迟和带宽要求。
With the extensive usage of in-network caching, new drawbacks are introduced since the streaming logic is located at the client, i.e., clients are not aware of each other and the network infrastructure and cache states. Furthermore, negative effects are introduced when multiple clients compete in a bottleneck and when caching influences this bandwidth competition. As mentioned above, the clients request individual portions of the content based on available bandwidth,
随着网络缓存的广泛使用，由于流逻辑位于客户端，因此引入了新的缺点，即客户端不知道彼此以及网络基础结构和缓存状态。此外，当多个客户端在瓶颈中竞争时，以及当缓存影响这种带宽竞争时，会引入负面影响。如上所述，客户端基于可用带宽请求内容的各个部分，
which is calculated using throughput estimations. This uncontrolled distribution of the content influences the adaptation process of adaptive streaming clients. The impact of this falsified throughput estimation could be tremendous and leads to a wrong adaptation decision that may impact the QoE at the client, as shown in [Mueller12]. In ICN, the client does not have the knowledge from which source the requested content is actually served or how many origin servers of the content are available, as this is transparent and depends on the name-based routing. This introduces the challenge that the adaptation logic of the adaptive streaming client is not aware of the event when the ICN routing decides to switch to a different origin server or content is coming through a different link/interface. As most algorithms implementing the adaption logic use bandwidth measurements and related heuristics, the adaptation decisions are no longer valid when changing origin servers (or links), and these decisions potentially cause playback interruptions and, consequently, stalling. Additionally, ICN supports the usage of multiple interfaces. A seamless handover between these interfaces (and different sources for the content) comes together with changes in performance, e.g., due to switching between fixed and wireless, 3G/4G and Wi-Fi networks, different types of servers (say with/ without Shared Secret Data (SSD) or hardware acceleration), etc.
这是使用吞吐量估计来计算的。这种不受控制的内容分发会影响自适应流式客户端的自适应过程。如[Mueller12]所示，这种伪造的吞吐量估计可能会产生巨大的影响，并导致错误的适应决策，这可能会影响客户端的QoE。在ICN中，客户端不知道请求的内容实际来自哪个来源，也不知道有多少内容的源服务器可用，因为这是透明的，并且取决于基于名称的路由。这带来了一个挑战，即当ICN路由决定切换到不同的源服务器或内容通过不同的链路/接口时，自适应流式客户端的自适应逻辑不知道该事件。由于大多数实现自适应逻辑的算法都使用带宽测量和相关的启发式方法，因此在更改源服务器（或链路）时，自适应决策不再有效，并且这些决策可能会导致播放中断，从而导致暂停。此外，ICN支持使用多个接口。这些接口（以及内容的不同来源）之间的无缝切换伴随着性能的变化，例如，由于在固定和无线、3G/4G和Wi-Fi网络之间切换，以及不同类型的服务器（例如有/没有共享机密数据（SSD）或硬件加速）等。
Considering these characteristics of ICN, adaptation algorithms merely based on bandwidth measurements are not appropriate anymore, as potentially each segment can be transferred from another ICN node or interface, all with different bandwidth conditions. Thus, adaptation algorithms taking into account these intrinsic characteristics of ICN are preferred over algorithms based on mere bandwidth measurements.
考虑到ICN的这些特性，仅仅基于带宽测量的自适应算法不再合适，因为每个段可能都可以从另一个ICN节点或接口传输，所有这些都具有不同的带宽条件。因此，考虑到ICN的这些固有特性的自适应算法优于仅基于带宽测量的算法。
For the evaluations of DASH over CCN, a testbed with open-source tools and datasets is provided in [ITEC-DASH]. In particular, it provides two client-player implementations, (i) a libdash extension for DASH over CCN and (ii) a VLC plugin implementing DASH over CCN. For both implementations, the CCNx implementation has been used as a basis.
[ITEC-DASH]中提供了一个带有开源工具和数据集的测试平台，用于评估破折号CCN。特别是，它提供了两种客户端播放器实现，（i）用于DASH over CCN的libdash扩展和（ii）实现DASH over CCN的VLC插件。对于这两种实现，都以CCNx实现为基础。
The general architecture of libdash is organized in modules so that the library implements a MPD parser and an extensible connection manager. The library provides object-oriented interfaces for these modules to access the MPD and the downloadable segments. These components are extended to support DASH over CCN and are located in a separate development branch of the GitHub project available at <http://www.github.com/bitmovin/libdash>. libdash comes together with a fully featured DASH player with a QT-based front end, demonstrating
libdash的通用体系结构是以模块的形式组织的，因此该库实现了一个MPD解析器和一个可扩展的连接管理器。该库为这些模块提供面向对象的接口，以访问MPD和可下载段。这些组件被扩展以支持DASH over CCN，并位于GitHub项目的一个单独的开发分支中，可在<http://www.github.com/bitmovin/libdash>. libdash附带了一个功能齐全的DASH播放器，该播放器具有基于QT的前端，用于演示
the usage of libdash and providing a scientific evaluation platform. As an alternative, patches for the DASH plugin of the VLC player are provided. These patches can be applied to the latest source code checkout of VLC resulting in a DASH-over-CCN-enabled VLC player.
libdash的使用，提供了一个科学的评价平台。另外，还提供了VLC播放器DASH插件的补丁。这些补丁可以应用于VLC的最新源代码检查，从而生成一个支持CCN的VLC播放器。
Finally, a DASH-over-CCN dataset is provided in the form of a CCNx repository. It includes 15 different quality representation of the well-known Big Buck Bunny Movie, ranging from 100 kbps to 4500 kbps. The content is split into segments of two seconds and is described by an associated MPD using the presented naming scheme in Section 5.1. This repository can be downloaded from [ITEC-DASH] and is also provided by a publicly accessible CCNx node. Associated routing commands for the CCNx namespaces of the content are provided via scripts coming together with the dataset and can be used as a public testbed.
最后，以CCNx存储库的形式提供了一个破折号CCN数据集。它包括15种不同质量的大兔子电影，从100kbps到4500kbps不等。内容分为两秒钟的段，并由相关MPD使用第5.1节中提出的命名方案进行描述。该存储库可从[ITEC-DASH]下载，也可由可公开访问的CCNx节点提供。内容的CCNx名称空间的相关路由命令通过与数据集一起的脚本提供，可以用作公共测试平台。
Peer-to-Peer distribution is another form of distributing content -- and video in particular -- that ICNs need to support. We see now how an existing protocol such as PPSP can be modified to work in an ICN environment.
点对点分发是ICN需要支持的另一种分发内容（特别是视频）的形式。我们现在看到如何修改现有协议（如PPSP）以在ICN环境中工作。
P2P Video Streaming (P2PVS) is a popular approach to redistribute live media over the Internet. The proposed P2PVS solutions can be roughly classified in two classes:
P2P视频流（P2PVS）是一种在互联网上重新分发实时媒体的流行方法。建议的P2PVS解决方案可大致分为两类：
o Push/Tree-based
o 基于推/树的
o Pull/Mesh-based
o 基于拉/网格的
The Push/Tree-based solution creates an overlay network among Peers that has a tree shape [Castro03]. Using a progressive encoding (e.g., Multiple Description Coding or H.264 Scalable Video Coding), multiple trees could be set up to support video rate adaptation. On each tree, an enhancement stream is sent. The higher the number of received streams, the higher the video quality. A peer controls the video rate by either fetching or not fetching the streams delivered over the distribution trees.
基于推送/树的解决方案在具有树形状的对等点之间创建覆盖网络[Castro03]。使用渐进编码（例如，多描述编码或H.264可伸缩视频编码），可以建立多个树以支持视频速率自适应。在每个树上，发送一个增强流。接收到的流的数量越多，视频质量越高。对等方通过获取或不获取通过分发树传送的流来控制视频速率。
The Pull/Mesh-based solution is inspired by the BitTorrent file sharing mechanism. A tracker collects information about the state of the swarm (i.e., the set of participating peers). A peer forms a mesh overlay network with a subset of peers and exchanges data with them. A peer announces what data items it disposes and requests missing data items that are announced by connected peers. In case of
基于拉/网格的解决方案受BitTorrent文件共享机制的启发。跟踪器收集有关群集状态的信息（即，参与的对等点集）。对等体与对等体的子集形成网状覆盖网络，并与它们交换数据。对等方宣布其处理的数据项，并请求连接的对等方宣布的缺失数据项。万一
live streaming, the involved data set includes only a recent window of data items published by the source. Also, in this case, the use of a progressive encoding can be exploited for video rate adaptation.
实时流媒体，所涉及的数据集仅包括源发布的数据项的最新窗口。此外，在这种情况下，可以利用渐进编码的使用来进行视频速率自适应。
Pull/Mesh-based P2PVS solutions are the more promising candidate for the ICN deployment, since most of ICN approach provides a pull-based API [Jacobson09b] [Detti11] [Chai11] [NETINF]. In addition, Pull/Mesh-based P2PVS are more robust than the Push/Tree-based one [Magharei07], and the PPSP working group [IETF-PPSP] is also proposing a Pull/Mesh-based solution.
基于拉/网格的P2PV解决方案是ICN部署的更有希望的候选方案，因为大多数ICN方法都提供了基于拉的API[Jacobson09b][Detti11][Chai11][NETINF]。此外，基于拉/网格的P2PV比基于推/树的P2PV更健壮[Magharei07]，PPSP工作组[IETF-PPSP]也提出了基于拉/网格的解决方案。
+------------------------------------------------+
| |
| +--------------------------------+ |
| | Tracker | |
| +--------------------------------+ |
| | ^ ^ |
|Tracker | | Tracker |Tracker |
|Protocol| | Protocol |Protocol |
| | | | |
| V | | |
| +---------+ Peer +---------+ |
| | Peer |<----------->| Peer | |
| +---------+ Protocol +---------+ |
| | ^ |
| | |Peer |
| | |Protocol |
| V | |
| +---------------+ |
| | Peer | |
| +---------------+ |
| |
+------------------------------------------------+
+------------------------------------------------+
| |
| +--------------------------------+ |
| | Tracker | |
| +--------------------------------+ |
| | ^ ^ |
|Tracker | | Tracker |Tracker |
|Protocol| | Protocol |Protocol |
| | | | |
| V | | |
| +---------+ Peer +---------+ |
| | Peer |<----------->| Peer | |
| +---------+ Protocol +---------+ |
| | ^ |
| | |Peer |
| | |Protocol |
| V | |
| +---------------+ |
| | Peer | |
| +---------------+ |
| |
+------------------------------------------------+
Figure 1: PPSP System Architecture [RFC6972]
图1:PPSP系统架构[RFC6972]
Figure 1 reports the PPSP architecture presented in [RFC6972]. PEERs announce and share video chunks and a TRACKER maintains a list of PEERs participating in a specific audio-video channel or in the distribution of a streaming file. The TRACKER functionality may be centralized in a server or distributed over the PEERs. PPSP standardizes the peer and Tracker Protocols, which can run directly over UDP or TCP.
图1报告了[RFC6972]中介绍的PPSP体系结构。对等点宣布并共享视频块，跟踪器维护参与特定音频视频频道或流文件分发的对等点列表。跟踪器功能可以集中在服务器中，也可以分布在对等机上。PPSP标准化了对等和跟踪器协议，这些协议可以直接在UDP或TCP上运行。
This document discusses some preliminary concepts about the deployment of PPSP on top of an ICN that exposes a pull-based API, meanwhile considering the impact of MPEG-DASH streaming format.
本文档讨论了在ICN上部署PPSP的一些初步概念，该ICN公开了基于pull的API，同时考虑了MPEG-DASH流格式的影响。
The Peer-to-Peer Streaming Peer Protocol (PPSPP) is defined in [Bakker15] and the Peer-to-Peer Streaming Tracker Protocol (PPSP-TP) is defined in [RFC7846].
对等流媒体对等协议（PPSP）在[Bakker15]中定义，对等流媒体跟踪器协议（PPSP-TP）在[RFC7846]中定义。
Some of the operations carried out by the Tracker Protocol are the following: when a peer wishes to join the streaming session, it contacts the tracker (CONNECT message), obtains a PEER_ID and a list of PEER_IDs (and IP addresses) of other peers that are participating to the SWARM and that the tracker has singled out for the requesting peer (this may be a subset of the all peers of the SWARM); in addition to this join operation, a peer may contact the tracker to request to renew the list of participating peers (FIND message), to periodically update its status to the tracker (STAT_REPORT message), and so on.
跟踪器协议执行的一些操作如下：当一个对等方希望加入流式会话时，它会联系跟踪器（连接消息），获取一个对等方ID和其他参与SWARM的对等方的对等方ID（和IP地址）列表，并且跟踪器已经为请求的对等方挑选出来（这可能是群中所有对等方的子集）；除了此加入操作外，对等方还可以联系跟踪器以请求更新参与对等方的列表（查找消息），定期向跟踪器更新其状态（统计报告消息），等等。
Some of the operations carried out by the Peer Protocol include the following: using the list of peers delivered by the tracker, a peer establishes a session with them (HANDSHAKE message); a peer periodically announces to neighboring peers which chunks it has available for download (HAVE message); using these announcements, a peer requests missing chunks from neighboring peers (REQUEST messages), which will be sent back to them (DATA message).
对等协议执行的一些操作包括以下内容：使用跟踪器提供的对等列表，对等方与它们建立会话（握手消息）；对等点定期向相邻对等点宣布其可下载的块（havemessage）；使用这些通知，对等方从相邻对等方请求缺少的块（请求消息），这些块将被发送回它们（数据消息）。
An ICN provides users with data items exposed by names. The bundle name and data item is usually referred as "named-data", "named-content", etc. To transfer PPSP messages through an ICN, the messages should be wrapped as named-data items and receivers should request them by name.
ICN为用户提供按名称公开的数据项。捆绑包名称和数据项通常称为“命名数据”、“命名内容”等。要通过ICN传输PPSP消息，消息应包装为命名数据项，接收方应按名称请求。
A PPSP entity receives messages from peers and/or a tracker. Some operations require gathering the messages generated by another specific host (peer or tracker). For instance, if Peer A wishes to gain information about video chunks available from Peer B, the former shall fetch the PPSP HAVE messages specifically generated by the latter. We refer to these kinds of named-data as "located-named-data" since they should be gathered from a specific location (e.g., Peer B).
PPSP实体从对等方和/或跟踪器接收消息。某些操作需要收集由另一个特定主机（对等或跟踪器）生成的消息。例如，如果对等方A希望从对等方B获得关于可用视频块的信息，则前者应获取PPSP，并具有后者专门生成的消息。我们将这些类型的命名数据称为“定位命名数据”，因为它们应该从特定位置（例如，对等B）收集。
For other PPSP operations, such as fetching a DATA message (i.e., a video chunk), as long as a peer receives the requested content, it doesn't matter which endpoint generated the data. We refer to this information with the generic term "named-data".
对于其他PPSP操作，例如获取数据消息（即视频块），只要对等方接收到请求的内容，由哪个端点生成数据就无关紧要。我们使用通用术语“命名数据”来引用此信息。
The naming scheme differentiates named-data and located-named-data items. In the case of named-data, the naming scheme only includes a content identifier (e.g., the name of the video chunk) without any prefix identifying who provides the content. For instance, a DATA message containing the video chunk "#1" may be named as "ccnx:/swarmID/chunk/chunkID", where swarmID is a unique identifier of the streaming session, "chunk" is a keyword, and chunkID is the chunk identifier (e.g., an integer number).
命名方案区分命名数据和定位的命名数据项。在命名数据的情况下，命名方案仅包括内容标识符（例如，视频块的名称），而没有任何识别提供内容的人的前缀。例如，包含视频区块“#1”的数据消息可以命名为“ccnx:/swarmID/chunk/chunkID”，其中swarmID是流会话的唯一标识符，“chunk”是关键字，chunkID是区块标识符（例如，整数）。
In case of located-named-data, the naming scheme includes a location-prefix, which uniquely identifies the host generating the data item. This prefix may be the PEER_ID in case the host was a peer or a tracker identifier in case the host was the tracker. For instance, a HAVE message generated by a Peer B may be named as "ccnx:/swarmID/peer/PEER_ID/HAVE", where "peer" is a keyword, PEER_ID_B is the identifier of Peer B, and HAVE is a keyword.
对于定位的命名数据，命名方案包括一个位置前缀，它唯一地标识生成数据项的主机。如果主机是对等机，则该前缀可以是对等机ID；如果主机是跟踪器，则该前缀可以是跟踪器标识符。例如，由对等方B生成的HAVE消息可以命名为“ccnx:/swarmID/Peer/Peer\u ID/HAVE”，其中“Peer”是关键字，Peer\u ID\u B是对等方B的标识符，HAVE是关键字。
The PPSP procedures are based both on pull and push interactions. For instance, the distribution of chunks availability can be classified as a push-based operation since a peer sends "unsolicited" information (HAVE message) to neighboring peers. Conversely, the procedure used to receive video chunks can be classified as pull-based since it is supported by a request/response interaction (i.e., REQUEST, DATA messages).
PPSP程序基于拉和推交互。例如，块可用性的分布可以分类为基于推送的操作，因为对等方向相邻对等方发送“未经请求的”信息（HAVE message）。相反，用于接收视频块的过程可以分类为基于拉的过程，因为它由请求/响应交互（即，请求、数据消息）支持。
As we said, we refer to an ICN architecture that provides a pull-based API. Accordingly, the mapping of PPSP pull-based procedure is quite simple. For instance, using the CCN architecture [Jacobson09b], a PPSP DATA message may be carried by a CCN DATA message and a REQUEST message can be transferred by a CCN Interest.
正如我们所说的，我们指的是提供基于拉的API的ICN体系结构。因此，基于PPSP拉动的过程的映射非常简单。例如，使用CCN架构[Jacobson09b]，PPSP数据消息可以由CCN数据消息承载，并且请求消息可以由CCN利益方传送。
Conversely, the support of push-based PPSP operations may be more difficult. We need an adaptation functionality that carries out a push-based operation using the underlying pull-based service primitives. For instance, a possible approach is to use the request/ response (i.e., Interest/Data) four-way handshakes proposed in [Jacobson09a]. Another possibility is that receivers periodically send out request messages of the named-data that neighbors will push and, when available, the sender inserts the pushed data within a response message.
相反，支持基于推送的PPSP操作可能更加困难。我们需要一个自适应功能，它使用底层的基于拉的服务原语执行基于推的操作。例如，一种可能的方法是使用[Jacobson09a]中提出的请求/响应（即兴趣/数据）四向握手。另一种可能性是，接收方定期发送邻居将推送的命名数据的请求消息，并且在可用时，发送方将推送的数据插入到响应消息中。
+-----------------------------------+
| Application |
+-----------------------------------+
| PPSP (TCP/IP) |
+-----------------------------------+
| ICN - PPSP Adaptation Layer (AL) |
+-----------------------------------+
| ICN Architecture |
+-----------------------------------+
+-----------------------------------+
| Application |
+-----------------------------------+
| PPSP (TCP/IP) |
+-----------------------------------+
| ICN - PPSP Adaptation Layer (AL) |
+-----------------------------------+
| ICN Architecture |
+-----------------------------------+
Figure 2: Mediator Approach
图2：中介方法
Figure 2 provides a possible abstract layering for PPSP over ICN. The Adaptation Layer acts as a mediator (proxy) between legacy PPSP entities based on TCP/IP and the ICN architecture. In fact, the role the mediator is to use ICN to transfer PPSP legacy messages.
图2提供了ICN上PPSP的可能抽象分层。自适应层充当基于TCP/IP和ICN体系结构的传统PPSP实体之间的中介（代理）。事实上，调解人的角色是使用ICN传输PPSP遗留消息。
This approach makes it possible to merely reuse TCP/IP P2P applications whose software includes also PPSP functionality. This "all-in-one" development approach may be rather common since the PPSP application interface is not going to be specified. Moreover, if the operating system will provide libraries that expose a PPSP API, these will be initially based on an underlying TCP/IP API. Also, in this case, the mediator approach would make it possible to easily reuse both the PPSP libraries and the Application on top of an ICN.
这种方法使得仅重用软件也包含PPSP功能的TCP/IP P2P应用程序成为可能。这种“一体式”开发方法可能非常常见，因为不会指定PPSP应用程序接口。此外，如果操作系统将提供公开PPSP API的库，则这些库最初将基于底层TCP/IP API。此外，在这种情况下，中介方法将使在ICN上轻松重用PPSP库和应用程序成为可能。
+-----------------------------------+
| Application |
+-----------------------------------+
| ICN-PPSP |
+-----------------------------------+
| ICN Architecture |
+-----------------------------------+
+-----------------------------------+
| Application |
+-----------------------------------+
| ICN-PPSP |
+-----------------------------------+
| ICN Architecture |
+-----------------------------------+
Figure 3: Clean-Slate Approach
图3：干净的方法
Figure 3 sketches a clean-slate layering approach in which the application directly includes or interacts with a PPSP version based on ICN. It's likely such a PPSP_ICN integration could yield a simpler development also because it does not require implementing a TCP/IP to ICN translation as in the Mediator approach. However, the clean-slate approach requires developing the application (in case of embedded PPSP functionality) or the PPSP library from scratch without exploiting what might already exist for TCP/IP.
图3描绘了一种全新的分层方法，其中应用程序直接包括基于ICN的PPSP版本或与之交互。这种PPSP_ICN集成可能会产生更简单的开发，因为它不需要像中介方法那样实现TCP/IP到ICN的转换。但是，干净的方法需要从头开始开发应用程序（在嵌入式PPSP功能的情况下）或PPSP库，而不需要利用TCP/IP可能已经存在的功能。
Overall, the Mediator approach may be considered the first step of a migration path towards ICN-native PPSP applications.
总的来说，中介方法可能被认为是向ICN本机PPSP应用程序迁移的第一步。
Upon the ICN API, a user (peer) requests content and the ICN sends it back. The content is gathered by the ICN from any source, which could be the closest peer that disposes of the named-data item, an in-network cache, etc. Actually, "where" to gather the content is controlled by an underlying ICN routing plane, which sets up the ICN forwarding tables (e.g., CCN FIB [Jacobson09b]).
根据ICN API，用户（对等方）请求内容，ICN将其发回。ICN从任何来源收集内容，该来源可能是处理命名数据项、网络缓存等的最近对等方。实际上，收集内容的“位置”由基础ICN路由平面控制，该平面设置ICN转发表（例如，CCN FIB[Jacobson09b]）。
A cross-layer interaction between the ICN routing plane and the PPSP may be required to support a PPSP session. Indeed, ICN shall forward request messages (e.g., CCN Interest) towards the proper peer that can handle them. Depending on the layering approach, this cross-layer interaction is controlled either by the Adaptation Layer or by the ICN-PPSP. For example, if a Peer A receives a HAVE message indicating that Peer B disposes of the video chunk named "ccnx:/swarmID/chunk/chunkID", then the former should insert in its ICN forwarding table an entry for the prefix "ccnx:/swarmID/chunk/ chunkID" whose next hop locator (e.g., IP address) is the network address of Peer B [Detti13].
可能需要ICN路由平面和PPSP之间的跨层交互来支持PPSP会话。实际上，ICN应将请求消息（例如，CCN兴趣）转发给能够处理它们的适当对等方。根据分层方法，这种跨层交互由适配层或ICN-PPSP控制。例如，如果对等方a接收到HAVE消息，指示对等方B处理名为“ccnx:/swarmID/chunk/chunk ID”的视频区块，则前者应在其ICN转发表中插入前缀“ccnx:/swarmID/chunk/chunk ID”的条目，其下一跳定位器（例如，IP地址）是对等方B的网络地址[Detti13]。
The ICN functionality that supports a PPSP session may be "isolated" or "integrated" with one from a public ICN.
支持PPSP会话的ICN功能可以与公共ICN中的ICN功能“隔离”或“集成”。
In the isolated case, a PPSP session is supported by an instance of an ICN (e.g., deployed on top of an IP) whose functionalities operate only on the limited set of nodes participating to the swarm, i.e., peers and the tracker. This approach resembles the one followed by a current P2P application, which usually forms an overlay network among peers of a P2P application; intermediate public IP routers do not carry out P2P functionalities.
在孤立的情况下，PPSP会话由ICN实例（例如，部署在IP之上）支持，其功能仅在参与swarm的有限节点集上运行，即对等节点和跟踪器。这种方法类似于当前P2P应用程序所采用的方法，通常在P2P应用程序的对等点之间形成覆盖网络；中间公共IP路由器不执行P2P功能。
In the integrated case, the nodes of a public ICN may be involved in the forwarding and in-network caching procedures. In doing so, the swarm may benefit from the presence of in-network caches, thus limiting uplink traffic on peers and inter-domain traffic, too. These are distinctive advantages of using PPSP over a public ICN rather than over TCP/IP. In addition, such advantages aren't likely manifested in the case of isolated deployment.
在集成的情况下，公共ICN的节点可以参与转发和网络缓存过程。这样做，swarm可能会受益于网络内缓存的存在，从而限制对等点上的上行链路流量和域间流量。这些是通过公共ICN而不是TCP/IP使用PPSP的显著优势。此外，这种优势不太可能在孤立部署的情况下体现出来。
However, the possible interaction between the PPSP and the routing layer of a public ICN may be dramatic, both in terms of explosion of the forwarding tables and in terms of security. These issues
然而，PPSP和公共ICN的路由层之间的可能交互在转发表的爆炸性和安全性方面都可能是戏剧性的。这些问题
specifically take place for those ICN architectures for which the name resolution (i.e., name to next hop) occurs en route, like the CCN architecture.
特别是对于那些在路由过程中发生名称解析（即名称到下一跳）的ICN体系结构，如CCN体系结构。
For instance, using the CCN architecture, to fetch a named-data item offered by a Peer A the on-path public ICN entities have to route the request messages towards the Peer A. This implies that the ICN forwarding tables of public ICN nodes may contain many entries, e.g., one entry per video chunk, and these entries are difficult to be aggregated since peers may have available only sparse parts of a big content, whose names have a same prefix (e.g., "ccnx:/swarmID"). Another possibility is to wrap all PPSP messages into a located-named-data. In this case, the forwarding tables should contain "only" the PEER_ID prefixes (e.g., "ccnx:/swarmID/peer/PEER_ID"), thus scaling down the number of entries from number of chunks to number of peers. However, in this case, the ICN mechanisms recognize the same video chunk offered by different peers as different content, thus losing caching and multicasting ICN benefits. In any case, routing entries should be updated either on the basis of the availability of named-data items on peers or on the presence of peers, and these events in a P2P session are rapidly changing and possibly hampering the convergence of the routing plane. Finally, since peers have an impact on the ICN forwarding table of public nodes, this may open obvious security issues.
例如，使用CCN体系结构，为了获取对等方a提供的命名数据项，公共ICN实体必须将请求消息路由到对等方a。这意味着公共ICN节点的ICN转发表可能包含许多条目，例如，每个视频块一个条目，而且这些条目很难聚合，因为对等方可能只有大内容的稀疏部分可用，其名称具有相同的前缀（例如，“ccnx:/swarmID”）。另一种可能是将所有PPSP消息包装到一个已定位的命名数据中。在这种情况下，转发表应“仅”包含对等ID前缀（例如，“ccnx:/swarmID/PEER/PEER\u ID”），从而将条目数从块数减少到对等数。然而，在这种情况下，ICN机制将不同对等方提供的相同视频块识别为不同的内容，从而失去缓存和多播ICN的好处。在任何情况下，路由条目都应该根据对等点上命名数据项的可用性或对等点的存在进行更新，并且P2P会话中的这些事件正在迅速变化，可能会阻碍路由平面的收敛。最后，由于节点对公共节点的ICN转发表有影响，这可能会带来明显的安全问题。
The introduction of video rate adaptation may significantly decrease the effectiveness of P2P cooperation and of in-network caching, depending of the kind of the video coding used by the MPEG-DASH stream.
根据MPEG-DASH流使用的视频编码类型，视频速率自适应的引入可能会显著降低P2P合作和网络缓存的有效性。
In case of an MPEG-DASH streaming with MPEG AVC encoding, the same video chunk is independently encoded at different rates and the encoding output is a different file for each rate. For instance, in case of a video encoded at three different rates, R1, R2, and R3; for each segment S, we have three distinct files: S.R1, S.R2, and S.R3. These files are independent of each other. To fetch a segment coded at R2 kbps, a peer shall request the specific file S.R2. Receiver-driven algorithms, implemented by the video client, usually handle the estimation of the best coding rate.
在使用MPEG AVC编码的MPEG-DASH流的情况下，相同的视频块以不同的速率独立编码，并且对于每个速率，编码输出是不同的文件。例如，对于以三种不同速率编码的视频，R1、R2和R3；对于每个段S，我们有三个不同的文件：S.R1、S.R2和S.R3。这些文件彼此独立。要获取以R2 kbps编码的段，对等方应请求特定文件S.R2。由视频客户端实现的接收机驱动算法通常处理最佳编码率的估计。
The independence among files associated with different encoding rates and the heterogeneity of peer bandwidths may dramatically reduce the interaction among peers, the effectiveness of in-network caching (in case of integrated deployment), and consequently, the ability of PPSP to offload the video server (i.e., a seeder peer). Indeed, a Peer A may select a coding rate (e.g., R1) different from the one selected
与不同编码速率相关的文件之间的独立性和对等带宽的异构性可能会显著降低对等之间的交互、网络内缓存的有效性（在集成部署的情况下），从而降低PPSP卸载视频服务器（即播种机对等）的能力。实际上，对等方a可以选择与所选择的不同的编码速率（例如，R1）
by a Peer B (e.g., R2), and this prevents the former from fetching video chunks from the latter since Peer B only has chunks available that are coded at a rate different from the ones needed by Peer A. To overcome this issue, a common distributed rate selection algorithm could force peers to select the same coding rate [Detti13]; nevertheless, this approach may be not feasible in the case of many peers.
通过对等方B（例如R2），这防止了前者从后者获取视频块，因为对等方B只有以不同于对等方a所需的速率编码的可用块。为了克服这一问题，通用分布式速率选择算法可以强制对等方选择相同的编码速率[Detti13]；然而，这种方法在许多同行的情况下可能不可行。
The use of an SVC encoding (Annex G extension of the H.264/MPEG-4 Advanced Video Coding (AVC) video compression standard) should make rate adaptation possible while neither reducing peer collaborations nor the in-network caching effectiveness. For a single video chunk, an SVC encoder produces different files for the different rates (roughly "layers"), and these files are progressively related to each other. Starting from a base layer that provides the minimum rate encoding, the next rates are encoded as an "enhancement layer" of the previous one. For instance, in case the video is coded with three rates, R1 (base layer), R2 (enhancement layer n.1), and R3 (enhancement layer n.2), then for each DASH segment, we have three files: S.R1, S.R2, and S.R3. The file S.R1 is the segment coded at the minimum rate (base layer). The file S.R2 enhances S.R1, so S.R1 and S.R2 can be combined to obtain a segment coded at rate R2. To get a segment coded at rate R2, a peer shall fetch both S.R1 and S.R2. This progressive dependence among files that encode the same segment at different rates makes peer cooperation possible, also in case peers player have autonomously selected different coding rates. For instance, if Peer A has selected the rate R1, the downloaded files S.R1 are useful also for a Peer B that has selected the rate R2, and vice versa.
使用SVC编码（H.264/MPEG-4高级视频编码（AVC）视频压缩标准的附录G扩展）应使速率自适应成为可能，同时既不会减少对等协作，也不会降低网络缓存的有效性。对于单个视频块，SVC编码器以不同的速率（大致为“层”）生成不同的文件，并且这些文件逐渐相互关联。从提供最小速率编码的基本层开始，下一个速率被编码为上一个速率的“增强层”。例如，如果视频以三种速率编码，R1（基本层）、R2（增强层n.1）和R3（增强层n.2），那么对于每个虚线段，我们有三个文件：S.R1、S.R2和S.R3。文件S.R1是以最小速率编码的段（基本层）。文件S.R2增强了S.R1，因此可以将S.R1和S.R2组合起来，以获得以R2速率编码的段。为了获得以R2速率编码的段，对等方应同时获取S.R1和S.R2。以不同速率编码同一段的文件之间的这种渐进依赖性使得对等方合作成为可能，同样是在对等方玩家自主选择不同编码速率的情况下。例如，如果对等方A选择了速率R1，则下载的文件S.R1也对选择了速率R2的对等方B有用，反之亦然。
IPTV refers to the delivery of quality content broadcast over the Internet and is typically associated with strict quality requirements, i.e., with a perceived latency of less than 500 ms and a packet loss rate that is multiple orders lower than the current loss rates experienced in the most commonly used access networks (see [ATIS-IIF]). We can summarize the major challenges for the delivery of IPTV service as follows.
IPTV指通过互联网广播的高质量内容的交付，通常与严格的质量要求相关，即感知延迟小于500 ms，丢包率比最常用的接入网络中的当前丢包率低多个数量级（见[ATIS-IIF]）。我们可以将IPTV服务交付面临的主要挑战总结如下。
Channel change latency represents a major concern for the IPTV service. Perceived latency during channel change should be less than 500 ms. To achieve this objective over the IP infrastructure, we have multiple choices:
频道更改延迟是IPTV服务的一个主要问题。频道更改期间的感知延迟应小于500毫秒。为了通过IP基础设施实现这一目标，我们有多种选择：
i receive fast unicast streams from a dedicated server (most effective but not resource efficient);
我从专用服务器接收快速单播流（最有效，但不节省资源）；
ii connect to other peers in the network (efficiency depends on peer support, effective and resource efficient, if also supported with a dedicated server); and
ii连接到网络中的其他对等方（效率取决于对等方的支持，有效且资源高效，如果还支持专用服务器）；和
iii connect to multiple multicast sessions at once (effective but not resource efficient and depends on the accuracy of the prediction model used to track user activity).
iii一次连接到多个多播会话（有效但不节省资源，取决于用于跟踪用户活动的预测模型的准确性）。
The second major challenge is the error recovery. Typical IPTV service requirements dictate the mean time between artifacts to be approximately 2 hours (see [ATIS-IIF]). This suggests the perceived loss rate to be less than or equal to 10^-7. Current IP-based solutions rely on the following proactive and reactive recovery techniques: (i) joining the Forward Error Correction (FEC) multicast stream corresponding to the perceived packet loss rate (not efficient, as the recovery strength is chosen based on worst-case loss scenarios); (ii) making unicast recovery requests to dedicated servers (requires active support from the service provider); (iii) probing peers to acquire repair packets (finding matching peers and enabling their cooperation is another challenge).
第二个主要挑战是错误恢复。典型的IPTV服务要求规定工件之间的平均时间约为2小时（见[ATIS-IIF]）。这表明感知损失率小于或等于10^-7。当前基于IP的解决方案依赖于以下主动和被动恢复技术：（i）加入与感知的分组丢失率相对应的前向纠错（FEC）多播流（无效，因为恢复强度是根据最坏情况下的丢失情况选择的）；（ii）向专用服务器发出单播恢复请求（需要服务提供商的积极支持）；（iii）探测对等点以获取修复包（另一个挑战是找到匹配的对等点并实现它们的合作）。
ICN presents significant advantages for the delivery of IPTV traffic. For instance, ICN inherently supports multicast and allows for quick recovery from packet losses (with the help of in-network caching). Similarly, peer support is also provided in the shape of in-network caches that typically act as the middleman between two peers, therefore enabling earlier access to IPTV content.
ICN为IPTV业务的交付提供了显著的优势。例如，ICN固有地支持多播，并允许从数据包丢失中快速恢复（借助于网络内缓存）。类似地，还以通常充当两个对等方之间的中间人的网络内缓存的形式提供对等方支持，因此能够更早地访问IPTV内容。
However, despite these advantages, delivery of IPTV service over ICNs brings forth new challenges. We can list some of these challenges as follows:
然而，尽管有这些优势，IPTV服务在ICN上的交付带来了新的挑战。我们可以将其中一些挑战列举如下：
o Messaging overhead: ICN is a pull-based architecture and relies on a unique balance between requests and responses. A user needs to make a request for each Data packet. In the case of IPTV, with rates up to (and likely to be) above 15 Mbps, we observe significant traffic upstream to bring those streams. As the number of streams increases (including the same session at
o 消息传递开销：ICN是一种基于拉的体系结构，依赖于请求和响应之间的独特平衡。用户需要对每个数据包发出请求。在IPTV的情况下，速率高达（并且很可能超过）15 Mbps，我们观察到大量的流量向上游移动，从而带来这些流。随着流数量的增加（包括同一个会话）
different quality levels and other formats), so does the burden on the routers. Even if the majority of requests are aggregated at the core, routers close to the edge (where we observe the biggest divergence in user requests) will experience a significant increase in overhead to process these requests. The same is true at the user side, as the uplink usage multiplies in the number of sessions a user requests (for instance, to minimize the impact of bandwidth fluctuations).
不同的质量级别和其他格式），路由器的负担也是如此。即使大多数请求都聚集在核心，靠近边缘的路由器（我们观察到用户请求的最大差异）处理这些请求的开销也会显著增加。在用户端也是如此，因为上行链路使用量会增加用户请求的会话数（例如，为了最小化带宽波动的影响）。
o Cache control: As the IPTV content expires at a rapid rate (with a likely expiry threshold of 1 s), we need solutions to effectively flush out such content to also prevent degradation impact on other cached content, with the help of intelligently chosen naming conventions. However, to allow for fast recovery and optimize access time to sessions (from current or new users), the timing of such expirations needs to be adaptive to network load and user demand. However, we also need to support quick access to earlier content, whenever needed; for instance, when the user accesses the rewind feature (note that in-network caches will not be of significant help in such scenarios due to the overhead required to maintain such content).
o 缓存控制：由于IPTV内容的过期速度很快（过期阈值可能为1秒），我们需要解决方案来有效清除此类内容，同时借助智能选择的命名约定，防止对其他缓存内容的降级影响。然而，为了允许快速恢复和优化会话访问时间（来自当前或新用户），此类过期的时间需要适应网络负载和用户需求。但是，我们还需要支持在需要时快速访问早期内容；例如，当用户访问回放功能时（请注意，在这种情况下，由于维护此类内容所需的开销，网络缓存不会有很大帮助）。
o Access accuracy: To receive the up-to-date session data, users need to be aware of such information at the time of their request. Unlike IP multicast, since the users join a session indirectly, session information is critical to minimize buffering delays and reduce the startup latency. Without such information, and without any active cooperation from the intermediate routers, stale data can seriously undermine the efficiency of content delivery. Furthermore, finding a cache does not necessarily equate to joining a session, as the look-ahead latency for the initial content access point may have a shorter lifetime than originally intended. For instance, if the user that has initiated the indirect multicast leaves the session early, the requests from the remaining users need to experience an additional latency of one RTT as they travel towards the content source. If the startup latency is chosen depending on the closeness to the intermediate router, going to the content source in-session can lead to undesired pauses.
o 访问准确性：要接收最新的会话数据，用户需要在请求时知道这些信息。与IP多播不同，由于用户间接加入会话，因此会话信息对于最小化缓冲延迟和减少启动延迟至关重要。如果没有这些信息，并且中间路由器没有任何积极的合作，陈旧的数据可能会严重破坏内容交付的效率。此外，查找缓存并不一定等同于加入会话，因为初始内容接入点的前瞻延迟可能比最初预期的寿命短。例如，如果发起间接多播的用户提前离开会话，则来自剩余用户的请求在向内容源移动时需要经历一个额外的RTT延迟。如果根据与中间路由器的距离选择启动延迟，则在会话中转到内容源可能会导致意外的暂停。
It should be noted that IPTV includes more than just multicast. Many implementations include "trick plays" (fast forward, pause, rewind) that often transform a multicast session into multiple unicast sessions. In this context, ICN is beneficial, as the caching offers an implicit multicast but without tight synchronization constraints in between two different users. One user may rewind and start playing forward again, thus drawing from a nearby cache of the
应该注意的是，IPTV不仅仅包括多播。许多实现包括经常将多播会话转换为多个单播会话的“把戏”（快进、暂停、快退）。在这种情况下，ICN是有益的，因为缓存提供了隐式多播，但在两个不同用户之间没有严格的同步约束。一个用户可以倒带并再次开始向前播放，这样就可以从附近的缓存中进行绘图
content recently viewed by another user (whereas in a strict multicast session, the opportunity of one user lagging off behind would be more difficult to implement).
另一个用户最近查看的内容（而在严格的多播会话中，一个用户落后的机会更难实现）。
This section discusses the need for DRM functionalities for multimedia streaming over ICN. It focuses on two possible approaches: modifying Authentication, Authorization, and Accounting (AAA) to support DRM in ICN and using Broadcast Encryption.
本节讨论ICN上的多媒体流对DRM功能的需求。它关注两种可能的方法：修改身份验证、授权和记帐（AAA）以支持ICN中的DRM和使用广播加密。
It is assumed that ICN will be used heavily for digital content dissemination. It is vital to consider DRM for digital content distribution. In today's Internet, there are two predominant classes of business models for on-demand video streaming. The first model is based on advertising revenues. Non-copyright protected (usually User-Generated Content (UGC)) content is offered by large infrastructure providers like Google (YouTube) at no charge. The infrastructure is financed by spliced advertisements into the content. In this context, DRM considerations may not be required, since producers of UGC may only strive for the maximum possible dissemination. Some producers of UGC are mainly interested in sharing content with their families, friends, colleges, or others and have no intention making a profit. However, the second class of business model requires DRM, because these entities are primarily profit oriented. For example, large on-demand streaming platforms (e.g., Netflix) establish business models based on subscriptions. Consumers may have to pay a monthly fee in order to get access to copyright-protected content like TV series, movies, or music. This model may be ad supported and free to the content consumer, like YouTube Channels or Spotify, but the creator of the content expects some remuneration for his work. From the perspective of the service providers and the copyright owners, only clients that pay the fee (explicitly or implicitly through ad placement) should be able to access and consume the content. Anyway, the challenge is to find an efficient and scalable way of access control to digital content, which is distributed in ICNs.
假定ICN将大量用于数字内容传播。对于数字内容分发，考虑DRM是至关重要的。在当今的互联网上，有两种主要的按需视频流业务模式。第一种模式基于广告收入。非版权保护（通常是用户生成内容（UGC））内容由大型基础设施提供商（如谷歌（YouTube））免费提供。基础设施的资金来源是将广告拼接到内容中。在这种情况下，可能不需要考虑DRM，因为UGC的制作人可能只会争取尽可能多的传播。UGC的一些制作人主要对与家人、朋友、大学或其他人共享内容感兴趣，并不打算盈利。然而，第二类商业模式需要DRM，因为这些实体主要以利润为导向。例如，大型点播流媒体平台（如Netflix）基于订阅建立商业模式。消费者可能需要每月支付费用才能访问受版权保护的内容，如电视剧、电影或音乐。这种模式可能是广告支持的，对内容消费者来说是免费的，比如YouTube频道或Spotify，但内容的创建者希望他的工作能获得一些报酬。从服务提供商和版权所有者的角度来看，只有支付费用（通过广告投放明示或暗示）的客户才能访问和消费内容。无论如何，挑战在于找到一种有效且可扩展的数字内容访问控制方法，该方法分布在ICN中。
This section discusses Broadcast Encryption (BE) as a suitable basis for DRM functionalities in conformance to the ICN communication paradigm (network-inherent caching, considered the advantage of BE, will be highlighted).
本节讨论广播加密（BE）作为符合ICN通信范式的DRM功能的合适基础（网络固有缓存，考虑到BE的优势，将予以强调）。
In ICN, Data packets can be cached inherently in the network, and any network participant can request a copy of these packets. This makes it very difficult to implement an access control for content that is
在ICN中，数据包可以固有地缓存在网络中，任何网络参与者都可以请求这些数据包的副本。这使得实现对以下内容的访问控制非常困难：
distributed via ICN. A naive approach is to encrypt the transmitted data for each consumer with a distinct key. This prohibits everyone other than the intended consumers from decrypting and consuming the data. However, this approach is not suitable for ICN's communication paradigm, since it would reduce the benefits gained from the inherent network caching. Even if multiple consumers request the same content, the requested data for each consumer would differ using this approach. A better, but still insufficient, idea is to use a single key for all consumers. This does not destruct the benefits of ICN's caching ability. The drawback is that if one of the consumers illegally distributes the key, the system is broken; any entity in the network can access the data. Changing the key after such an event is useless since the provider has no possibility to identify the illegal distributor. Therefore, this person cannot be stopped from distributing the new key again. In addition to this issue, other challenges have to be considered. Subscriptions expire after a certain time, and then it has to be ensured that these consumers cannot access the content anymore. For a provider that serves millions of daily consumers (e.g., Netflix), there could be a significant number of expiring subscriptions per day. Publishing a new key every time a subscription expires would require an unsuitable amount of computational power just to re-encrypt the collection of audio-visual content.
通过ICN分发。一种简单的方法是使用不同的密钥为每个使用者加密传输的数据。这禁止除预期使用者以外的任何人解密和使用数据。然而，这种方法不适合ICN的通信模式，因为它会减少从固有的网络缓存中获得的好处。即使多个消费者请求相同的内容，使用这种方法，每个消费者请求的数据也会有所不同。一个更好但仍然不够的想法是为所有消费者使用一个键。这不会破坏ICN缓存能力的好处。缺点是，如果其中一个消费者非法分发密钥，系统就会被破坏；网络中的任何实体都可以访问数据。在此类事件后更改密钥是无用的，因为提供程序无法识别非法分发服务器。因此，无法阻止此人再次分发新密钥。除此之外，还必须考虑其他挑战。订阅在一段时间后过期，然后必须确保这些消费者无法再访问内容。对于每天服务数百万消费者的提供商（如Netflix），每天可能有大量过期订阅。每次订阅过期时发布一个新密钥将需要不合适的计算能力来重新加密视听内容的集合。
A possible approach to solve these challenges is BE [Fiat94] as proposed in [Posch13]. From this point on, this section will focus only on BE as an enabler for DRM functionality in the use case of ICN video streaming. This subsection continues with the explanation of how BE works and shows how BE can be used to implement an access control scheme in the context of content distribution in ICN.
解决这些挑战的一种可能方法是[Posch13]中提出的[Fiat94]。从这一点开始，本节将只关注BE作为ICN视频流使用案例中DRM功能的启用码。本小节继续解释BE的工作原理，并说明如何在ICN中的内容分发上下文中使用BE实现访问控制方案。
BE actually carries a misleading name. One might expect a concrete encryption scheme. However, it belongs to the family of key management schemes. These schemes are responsible for the generation, exchange, storage, and replacement of cryptographic keys. The most interesting characteristics of BE schemes are:
BE实际上有一个误导性的名字。人们可能期望有一个具体的加密方案。然而，它属于密钥管理方案家族。这些方案负责生成、交换、存储和替换加密密钥。BE方案最有趣的特点是：
o BE schemes typically use a global trusted entity called the Licensing Agent (LA), which is responsible for spreading a set of pre-generated secrets among all participants. Each participant gets a distinct subset of secrets assigned from the LA.
o BE方案通常使用称为许可代理（LA）的全局受信任实体，该实体负责在所有参与者之间传播一组预先生成的秘密。每个参与者都从LA获得一个不同的秘密子集。
o The participants can agree on a common session key, which is chosen by the LA. The LA broadcasts an encrypted message that includes the key. Participants with a valid set of secrets can derive the session key from this message.
o 参与者可以就公共会话密钥达成一致，该密钥由LA选择。LA广播包含密钥的加密消息。具有一组有效机密的参与者可以从此消息派生会话密钥。
o The number of participants in the system can change dynamically. Entities may join or leave the communication group at any time. If a new entity joins, the LA passes on a valid set of secrets to that entity. If an entity leaves (or is forced to leave) the LA revokes the entity's subset of keys, which means that it cannot derive the correct session key anymore when the LA distributes a new key.
o 系统中的参与者数量可以动态变化。实体可以随时加入或离开通信组。如果新实体加入，LA将向该实体传递一组有效的机密。如果实体离开（或被迫离开），LA将撤销该实体的密钥子集，这意味着当LA分发新密钥时，它无法再派生正确的会话密钥。
o Traitors (entities that reveal their secrets) can be traced and excluded from ongoing communication. The algorithms and preconditions to identify a traitor vary between concrete BE schemes.
o 叛徒（泄露其秘密的实体）可以被追踪，并被排除在持续通信之外。识别叛徒的算法和前提条件因具体BE方案而异。
This listing already illustrates why BE is suitable to control the access to data that is distributed via an ICN. BE enables the usage of a single session key for confidential data transmission between a dynamically changing subset or network participants. ICN caches can be utilized since the data is encrypted only with a single key known by all legitimate clients. Furthermore, traitors can be identified and removed from the system. The issue of re-encryption still exists because the LA will eventually update the session key when a participant should be excluded. However, this disadvantage can be relaxed in some way if the following points are considered:
这个清单已经说明了为什么BE适合控制对通过ICN分发的数据的访问。BE允许在动态变化的子集或网络参与者之间使用单个会话密钥进行机密数据传输。可以使用ICN缓存，因为数据仅使用所有合法客户端已知的单个密钥进行加密。此外，叛徒可以被识别并从系统中移除。重新加密的问题仍然存在，因为LA最终将在参与者被排除时更新会话密钥。但是，如果考虑到以下几点，可以通过某种方式缓解这一缺点：
o The updates of the session key can be delayed until a set of compromised secrets has been gathered. Note that secrets may become compromised because of two reasons: first, a traitor could have illegally revealed the secret; second, the subscription of an entity expired. Delayed revocation temporarily enables some illegitimate entities to consume content. However, this should not be a severe problem in home entertainment scenarios. Updating the session key in regular (not too short) intervals is a good trade- off. The longer the interval lasts, the less computational resources are required for content re-encryption and the better the cache utilization in the ICN will be. To evict old data from ICN caches that have been encrypted with the prior session key, the publisher could indicate a lifetime for transmitted packets.
o 会话密钥的更新可能会延迟，直到收集到一组泄露的秘密。请注意，机密可能会被泄露，原因有两个：第一，叛徒可能非法泄露机密；第二，实体的订阅已过期。延迟撤销暂时允许某些非法实体使用内容。然而，这在家庭娱乐场景中应该不是一个严重的问题。定期（不要太短）更新会话密钥是一个很好的折衷方案。间隔时间越长，内容重新加密所需的计算资源就越少，ICN中的缓存利用率就越好。为了从ICN缓存中移出使用先前会话密钥加密的旧数据，发布者可以指示传输的数据包的生存期。
o Content should be re-encrypted dynamically at request time. This has the benefit that untapped content is not re-encrypted if the content is not requested during two session key update; therefore, no resources are wasted. Furthermore, if the updates are triggered in non-peak times, the maximum amount of resources needed at one point in time can be lowered effectively since in peak times generally more diverse content is requested.
o 内容应在请求时动态重新加密。这样做的好处是，如果在两个会话密钥更新期间未请求内容，则未开发的内容不会被重新加密；因此，不会浪费任何资源。此外，如果在非高峰时间触发更新，则可以有效地降低在一个时间点所需的最大资源量，因为在高峰时间通常请求更多样化的内容。
o Since the amount of required computational resources may vary strongly from time to time, it would be beneficial for any streaming provider to use cloud-based services to be able to dynamically adapt the required resources to the current needs. In regard to a lack of computation time or bandwidth, the cloud service could be used to scale up to overcome shortages.
o 由于所需的计算资源量可能会随着时间的推移而发生很大变化，因此任何流媒体提供商都可以使用基于云的服务来动态地调整所需的资源以满足当前的需求。考虑到计算时间或带宽的不足，云服务可以用来扩大规模以克服不足。
Figure 4 shows the potential usage of BE in a multimedia delivery framework that builds upon ICN infrastructure and uses the concept of dynamic adaptive streaming, e.g., DASH. BE would be implemented on the top to have an efficient and scalable way of access control to the multimedia content.
图4显示了BE在多媒体交付框架中的潜在用途，该框架建立在ICN基础设施之上，并使用动态自适应流的概念，例如DASH。BE将在顶部实施，以便对多媒体内容进行有效且可扩展的访问控制。
+--------Multimedia Delivery Framework--------+
| |
| Technologies Properties |
| +----------------+ +----------------+ |
| | Broadcast |<--->| Controlled | |
| | Encryption | | Access | |
| +----------------+ +----------------+ |
| |Dynamic Adaptive|<--->| Multimedia | |
| | Streaming | | Adaptation | |
| +----------------+ +----------------+ |
| | ICN |<--->| Cacheable | |
| | Infrastructure | | Data Chunks | |
| +----------------+ +----------------+ |
+---------------------------------------------+
+--------Multimedia Delivery Framework--------+
| |
| Technologies Properties |
| +----------------+ +----------------+ |
| | Broadcast |<--->| Controlled | |
| | Encryption | | Access | |
| +----------------+ +----------------+ |
| |Dynamic Adaptive|<--->| Multimedia | |
| | Streaming | | Adaptation | |
| +----------------+ +----------------+ |
| | ICN |<--->| Cacheable | |
| | Infrastructure | | Data Chunks | |
| +----------------+ +----------------+ |
+---------------------------------------------+
Figure 4: A Potential Multimedia Framework Using BE
图4：使用BE的潜在多媒体框架
Recently, a novel approach to DRM has emerged to link DRM to usual network management operations, hence linking DRM to AAA services. ICN provides the abstraction of an architecture where content is requested by name and could be served from anywhere. In DRM, the content provider (the origin of the content) allows the destination (the end-user account) to use the content. The content provider and content storage/cache are at two different entities in ITU Carrier Code (ICC); for traditional DRM, only source and destination count and not the intermediate storage. The proposed solution allows the provider of the caching to be involved in the DRM policies using well-known AAA mechanisms. It is important to note that this solution is compatible with the proposal of the BE, proposed earlier in this document. The BE proposes a technology, as this solution is more operational.
最近，出现了一种新的DRM方法，将DRM链接到通常的网络管理操作，从而将DRM链接到AAA服务。ICN提供了一个架构的抽象，在这个架构中，内容是按名称请求的，并且可以从任何地方提供服务。在DRM中，内容提供者（内容的来源）允许目的地（最终用户帐户）使用内容。内容提供商和内容存储/缓存位于ITU运营商代码（ICC）中的两个不同实体；对于传统的DRM，只有源和目标计数，而不是中间存储。建议的解决方案允许缓存提供者使用众所周知的AAA机制参与DRM策略。需要注意的是，该解决方案与本文件前面提出的BE提案兼容。BE提出了一种技术，因为这种解决方案更具操作性。
With the proposed AAA-based DRM, when content is requested by name from a specific destination, the request could link back to both the content provider and the caching provider via traditional AAA mechanisms and trigger the appropriate DRM policy independently from where the content is stored. In this approach, the caching, DRM, and AAA remain independent entities but can work together through ICN mechanisms. The proposed solution enables extending the traditional DRM done by the content provider to jointly being done by content provider and network/caching provider.
使用建议的基于AAA的DRM，当从特定目的地按名称请求内容时，该请求可以通过传统的AAA机制链接回内容提供商和缓存提供商，并独立于内容的存储位置触发适当的DRM策略。在这种方法中，缓存、DRM和AAA仍然是独立的实体，但可以通过ICN机制协同工作。提出的解决方案能够将传统的由内容提供商完成的DRM扩展到由内容提供商和网络/缓存提供商共同完成的DRM。
The solution is based on the concept of a "token". The content provider authenticates the end user and issues an encrypted token to authenticate the named-content ID or IDs that the user can access. The token will be shared with the network provider and used as the interface to the AAA protocols. At this point, all content access is under the control of the network provider and the ICN. The controllers and switches can manage the content requests and handle mobility. The content can be accessed from anywhere as long as the token remains valid or the content is available in the network. In such a scheme, the content provider does not need to be contacted every time a named-content is requested. This reduces the load of the content provider network and creates a DRM mechanism that is much more appropriate for the distributed caching and Peer-to-Peer storage characteristic of ICN networks. In particular, the content requested by name can be served from anywhere under the only condition that the storage/cache can verify that the token is valid for content access.
该解决方案基于“令牌”的概念。内容提供商对最终用户进行身份验证，并发出加密令牌以验证用户可以访问的一个或多个命名内容ID。令牌将与网络提供商共享，并用作AAA协议的接口。此时，所有内容访问都在网络提供商和ICN的控制下。控制器和交换机可以管理内容请求并处理移动性。只要令牌保持有效或内容在网络中可用，就可以从任何地方访问内容。在这种方案中，不需要在每次请求指定内容时联系内容提供商。这降低了内容提供商网络的负载，并创建了更适合ICN网络的分布式缓存和对等存储特性的DRM机制。特别是，只有在存储/缓存能够验证令牌对内容访问有效的情况下，才能从任何地方提供名称请求的内容。
The solution is also fully customizable to both content and network provider's needs as the tokens can be issued based on user accounts, location, and hardware (Media Access Control (MAC) address, for example) linking it naturally to legacy authentication mechanisms. In addition, since both content and network providers are involved in DRM policies, pollution attacks and other illegal requests for the content can be more easily detected. The proposed AAA-based DRM is currently under full development.
该解决方案还可以根据内容和网络提供商的需要进行完全定制，因为令牌可以基于用户帐户、位置和硬件（例如，媒体访问控制（MAC）地址）来发行，并自然地将其链接到传统的身份验证机制。此外，由于内容和网络提供商都涉及DRM策略，因此污染攻击和其他对内容的非法请求更容易被检测到。拟议的基于AAA的DRM目前正在全面开发中。
The explosion of online video services, along with their increased consumption by mobile wireless terminals, further exacerbates the challenges of ICN mechanisms that leverage Video Adaptation. The following sections present a series of research items derived from these challenges, further introducing next steps for the subject.
在线视频服务的爆炸式增长，以及移动无线终端消费的增加，进一步加剧了利用视频自适应的ICN机制的挑战。以下各节介绍了从这些挑战中衍生出的一系列研究项目，并进一步介绍了该主题的下一步步骤。
Distributing content, and video in particular, using local communications in large-scale events such as sporting events in a stadium, a concert, or a large demonstration, is an active area of investigation and a potential use case where ICN would provide significant benefits.
在大型活动中使用本地通信来分发内容，尤其是视频，如体育场内的体育赛事、音乐会或大型示威，这是一个积极的调查领域，也是ICN将提供重大好处的潜在用例。
Such use cases involve locating content that is generated on the fly and requires discovery mechanisms in addition to sharing mechanisms. The scalability of the distribution becomes important as well.
此类用例涉及定位动态生成的内容，除了共享机制外，还需要发现机制。分发的可伸缩性也变得很重要。
Current protocols for video conferencing have been designed, and this document takes input from them to identify the key research issues. Real-time communications add timing constraints (both in terms of delay and in terms of synchronization) to the scenario discussed above.
目前的视频会议协议已经设计好，本文档从中获取输入，以确定关键的研究问题。实时通信为上述场景增加了时间限制（延迟和同步方面）。
An Access Router (AR) and a Virtual Router (VR), and immersive multimedia experiences in general, are clearly an area of further investigation, as they involve combining multiple streams of data from multiple users into a coherent whole. This raises issues of multisource, multidestination multimedia streams that ICN may be equipped to deal with in a more natural manner than IP, which is inherently unicast.
接入路由器（AR）和虚拟路由器（VR）以及沉浸式多媒体体验显然是进一步研究的领域，因为它们涉及将来自多个用户的多个数据流组合成一个连贯的整体。这就产生了多源、多目的多媒体流的问题，ICN可能会配备这些流，以便以比IP更自然的方式处理这些流，IP本身就是单播的。
One of the benefits of ICN is to allow the network to insert caching in the middle of the data transfer. This can be used to reduce the overall bandwidth demands over the network by caching content for future reuse, but it provides more opportunities for optimizing video streams.
ICN的好处之一是允许网络在数据传输的中间插入缓存。这可以通过缓存内容以供将来重用来降低网络上的总体带宽需求，但它为优化视频流提供了更多机会。
Consider, for instance, the following scenario: a client is connected via an ICN network to a server. Let's say the client is connected wirelessly to a node that has a caching capability, which is connected through a WAN to the server. Further, assume that the capacity of each of the links (both the wireless and the WAN logical links) varies with time.
例如，考虑以下场景：客户端通过ICN网络连接到服务器。假设客户端无线连接到具有缓存功能的节点，该节点通过WAN连接到服务器。此外，假设每个链路（无线链路和WAN逻辑链路）的容量随时间而变化。
If the rate adaptation is provided in an end-to-end manner, as in current mechanisms like DASH, then the maximal rate that can be supported at the client is that of the minimal bandwidth on each link.
如果速率自适应是以端到端的方式提供的，如在诸如DASH的当前机制中，那么在客户端可以支持的最大速率是每个链路上的最小带宽的速率。
If, for instance, during Time Period 1 the wireless capacity is 1 and the wired capacity is 2 and during Time Period 2 the wireless capacity is 2 (due to some hotspot) and the wired capacity is 1 (due to some congestion in the network), then the best end-to-end rate that can be achieved is 1 during each period.
例如，如果在时间段1期间，无线容量为1，有线容量为2，在时间段2期间，无线容量为2（由于某些热点），有线容量为1（由于网络中的某些拥塞），则在每个时间段内可以实现的最佳端到端速率为1。
However, if the cache is used during Time Period 1 to pre-fetch 2 units of data, then during Time Period 2 there is 1 unit of data at the cache and another unit of data that can be streamed from the server; therefore, the rate that can be achieved is 2 units of data. In this case, the average bandwidth rises from 1 to 1.5 over the two periods.
但是，如果在时间段1期间使用缓存预取2个数据单位，则在时间段2期间，缓存中有1个数据单位，另一个数据单位可以从服务器流式传输；因此，可以实现的速率是2个数据单位。在这种情况下，平均带宽在两个周期内从1增加到1.5。
This straw-man example illustrates a) the benefit of ICN for increasing the throughput of the network and b) the need for the special rate adaptation mechanisms to be designed to take advantage of this gain. End-to-end rate adaptation cannot take advantage of the cache availability. The authors of [Rainer16] showed that buffer-based adaptation mechanisms can be one approach to tackle this challenge. As buffer-based adaptation does not estimate the available bandwidth resources (but solely considers the video buffer fill state), measured bandwidth fluctuations caused by cache hits are not existent. Therefore, they cannot negatively impact the adaptation decisions (e.g., frequent representation switching).
这个稻草人的例子说明了a）ICN对提高网络吞吐量的好处，以及b）需要设计特殊的速率自适应机制来利用这个增益。端到端速率自适应无法利用缓存可用性。[Rainer16]的作者指出，基于缓冲区的适应机制可以是应对这一挑战的一种方法。由于基于缓冲区的自适应不估计可用带宽资源（但仅考虑视频缓冲区填充状态），因此不存在由缓存命中引起的测量带宽波动。因此，它们不会对适应决策产生负面影响（例如，频繁的表征转换）。
With the ever-growing increase in online services being accessed by mobile devices, operators have been deploying different overlapping wireless access networking technologies. In this way, in the same area, user terminals are within range of different cellular, Wi-Fi, or even Worldwide Interoperability for Microwave Access (WiMAX) networks. Moreover, with the advent of the Internet of Things (e.g., surveillance cameras feeding video footage), this list can be further complemented with more-specific short-range technologies, such as Bluetooth or ZigBee.
随着移动设备访问在线服务的不断增加，运营商已经部署了不同的重叠无线接入网络技术。这样，在同一地区，用户终端在不同蜂窝、Wi-Fi甚至全球微波接入互操作性（WiMAX）网络的范围内。此外，随着物联网的出现（例如，监控摄像机提供视频片段），这一列表可以通过更具体的短程技术进一步补充，如蓝牙或ZigBee。
In order to leverage from this plethora of connectivity opportunities, user terminals are coming equipped with different wireless access interfaces, providing them with extended connectivity opportunities. In this way, such devices become able to select the type of access that best suits them according to different criteria, such as available bandwidth, battery consumption, access to different link conditions according to the user profile, or even access to different content. Ultimately, these aspects contribute to the QoE perceived by the end user, which is of utmost importance when it comes to video content.
为了利用这一过多的连接机会，用户终端将配备不同的无线接入接口，为其提供扩展连接机会。这样，这样的设备能够根据不同的标准选择最适合它们的接入类型，例如可用带宽、电池消耗、根据用户简档对不同链路条件的接入，甚至对不同内容的接入。最终，这些方面有助于最终用户感知的QoE，这对于视频内容来说至关重要。
However, the fact that these users are mobile and using wireless technologies also provides a very dynamic setting where the current optimal link conditions at a specific moment might not last or be maintained while the user moves. These aspects have been amply analyzed in recently finished projects such as FP7 MEDIEVAL [MEDIEVAL], where link events reporting on wireless conditions and available alternative connection points were combined with video requirements and traffic optimization mechanisms towards the production of a joint network and mobile terminal mobility management decision. Concretely, in [Fu13], link information about the deterioration of the wireless signal was sent towards a mobility management controller in the network. This input was combined with information about the user profile, as well as of the current video service requirements, and used to trigger the decrease or increase of scalable video layers (adjusting the video to the ongoing link conditions). Incrementally, the video could also be adjusted when a new, better connectivity opportunity presents itself.
然而，这些用户是移动的并且使用无线技术这一事实也提供了一个非常动态的设置，其中在特定时刻的当前最佳链路条件可能不会在用户移动时持续或保持。这些方面已经在最近完成的项目中进行了充分的分析，如FP7中世纪[中世纪]，其中，报告无线条件和可用替代连接点的链路事件与视频需求和流量优化机制相结合，以产生联合网络和移动终端移动性管理决策。具体地，在[Fu13]中，关于无线信号恶化的链路信息被发送到网络中的移动性管理控制器。该输入与有关用户配置文件以及当前视频服务需求的信息相结合，并用于触发可缩放视频层的减少或增加（将视频调整到当前的链接条件）。当新的、更好的连接机会出现时，视频也可以逐步调整。
In this way, regarding Video Adaptation, ICN mechanisms can leverage from their intrinsic multiple source support capability and go beyond the monitoring of the status of the current link, thus exploiting the availability of different connectivity possibilities (e.g., different "interfaces"). Moreover, information obtained from the mobile terminal's point of view of its network link, as well as information from the network itself (i.e., load, policies, and others), can generate scenarios where such information is combined in a joint optimization procedure allowing the content to be forward to users using the best available connectivity option (e.g., exploiting management capabilities supported by ICN intrinsic mechanisms as in [Corujo12]).
这样，关于视频自适应，ICN机制可以利用其固有的多源支持能力，超越对当前链路状态的监控，从而利用不同连接可能性（例如，不同的“接口”）的可用性。此外，从移动终端的网络链路的角度获得的信息，以及从网络本身获得的信息（即，负载、策略等），可以生成这样的场景，其中这些信息组合在一个联合优化过程中，允许使用最佳可用连接选项（例如，利用[Corujo12]中ICN内在机制支持的管理功能）将内容转发给用户。
In fact, ICN base mechanisms can further be exploited in enabling new deployment scenarios such as preparing the network for mass requests from users attending a large multimedia event (i.e., concert, sports), allowing video to be adapted according to content, user and network requirements, and operation capabilities in a dynamic way.
事实上，可以进一步利用基于ICN的机制来实现新的部署场景，例如为来自参加大型多媒体活动（即音乐会、体育）的用户的大规模请求准备网络，允许以动态方式根据内容、用户和网络需求以及操作能力来调整视频。
Enabling such scenarios requires further research, with the main points highlighted as follows:
启用此类场景需要进一步研究，重点如下：
o how to develop a generic video services (and obviously content) interface allowing the definition and mapping of their requirements (and characteristics) into the current capabilities of the network;
o 如何开发通用视频服务（显然是内容）接口，允许定义其需求（和特征）并将其映射到网络的当前功能中；
o how to define a scalable mechanism allowing either the video application at the terminal or some kind of network management entity, to adapt the video content in a dynamic way;
o 如何定义一种可伸缩机制，允许终端的视频应用程序或某种网络管理实体以动态方式适应视频内容；
o how to develop the previous research items using intrinsic ICN mechanisms (i.e., naming and strategy layers);
o 如何使用固有的ICN机制（即命名和策略层）开发先前的研究项目；
o how to leverage intelligent pre-caching of content to prevent stalls and poor quality phases, which lead to a worse QoE for the user: this includes, in particular, the usage in mobile environments, which are characterized by severe bandwidth changes as well as connection outages, as shown in [Crabtree13]; and
o 如何利用内容的智能预缓存来防止暂停和低质量阶段，这会导致用户的QoE更差：这尤其包括移动环境中的使用，其特点是严重的带宽变化和连接中断，如[Crabtree13]所示；和
o how to take advantage of the multipath opportunities over the heterogeneous wireless interfaces.
o 如何利用异构无线接口上的多路径机会。
An interesting research area for combining heterogeneous sources is to use network coding [Montpetit13b]. Network coding allows for asynchronous combining of multiple sources by having each of them send information that is not duplicated by the other but that can be combined to retrieve the video stream.
组合异构源的一个有趣的研究领域是使用网络编码[Montpetit13b]。网络编码允许多个源的异步组合，方法是让每个源发送不被另一个源复制的信息，但可以组合以检索视频流。
However, this creates issues in ICN in terms of defining the proper rate adaptation for the video stream, securing the encoded data, caching the encoded data, timeliness of the encoded data, overhead of the network coding operations both in network resources and in added buffering delay, etc.
然而，这在ICN中在定义视频流的适当速率自适应、保护编码数据、缓存编码数据、编码数据的及时性、网络资源和附加缓冲延迟中的网络编码操作的开销等方面产生了问题。
Network coding has shown promise in reducing buffering events in unicast, multicast, and P2P settings. [Medard12] considers strategies using network coding to enhance QoE for multimedia communications. Network coding can be applied to multiple streams, but also within a single stream as an equivalent of a composable erasure code. Clearly, there is a need for further investigation of network coding in ICN, potentially as a topic of activity in the research group.
网络编码在减少单播、多播和P2P设置中的缓冲事件方面显示出了希望。[Medard12]考虑使用网络编码提高多媒体通信质量的策略。网络编码可以应用于多个流，但也可以作为可组合擦除码的等价物应用于单个流中。显然，有必要进一步研究ICN中的网络编码，这可能是研究小组的一个活动主题。
ICN decouples the fetching of video chunks from their locations. This means an audio chunk may be received from one network element (cache/storage/server), a video chunk may be received from another, while yet another chunk (say, the next one, or another layer from the same video stream) may come from a third element. This introduces disparity in the retrieval times and locations of the different elements of a video stream that need to be played at the same (or almost same) time. Synchronization of such delivery and playback may require specific synchronization tools for video delivery in ICN.
ICN将视频块的获取与其位置分离。这意味着音频块可以从一个网元（缓存/存储/服务器）接收，视频块可以从另一个网元接收，而另一个块（例如，下一个块或来自同一视频流的另一层）可以来自第三个网元。这导致需要在相同（或几乎相同）时间播放的视频流的不同元素的检索时间和位置存在差异。这种传送和回放的同步可能需要用于ICN中视频传送的特定同步工具。
Other aspects involve synchronizing:
其他方面涉及同步：
o within a single stream, for instance, the consecutive chunks of a single stream or the multiple layers of a layered scheme when sources and transport layers may be different.
o 例如，在单个流中，当源和传输层可能不同时，单个流的连续块或分层方案的多层。
o re-ordering the packets of a stream distributed over multiple sources at the video client, or ensuring that multiple chunks coming from multiple sources arrive within an acceptable time window;
o 在视频客户端对分布在多个源上的流的分组重新排序，或确保来自多个源的多个块在可接受的时间窗口内到达；
o multiple streams, such as the audio and video components of a video stream, which can be received from independent sources; and
o 可从独立源接收的多个流，例如视频流的音频和视频分量；和
o multiple streams from multiple sources to multiple destinations, such as mass distribution of live events. For instance, for live video streams or video conferencing, some level of synchronization is required so that people watching the stream view the same events at the same time.
o 从多个源到多个目的地的多个流，例如现场事件的大规模分发。例如，对于实时视频流或视频会议，需要某种程度的同步，以便观看流的人同时观看相同的事件。
Some of these issues were addressed in [Montpetit13a] in the context of social video consumption. Network coding, with traffic engineering, is considered as a potential solution for synchronization issues. Other approaches could be considered that are specific to ICN as well.
[Montpetit13a]在社交视频消费方面解决了其中一些问题。网络编码和流量工程被认为是解决同步问题的一种潜在方法。也可以考虑针对ICN的其他方法。
Traffic engineering in ICN [Su14] [Chanda13] may be required to provide proper synchronization of multiple streams.
可能需要ICN[Su14][Chanda13]中的流量工程来提供多个流的适当同步。
This is informational. There are no specific security considerations outside of those mentioned in the text.
这是信息性的。除了文中提到的安全考虑之外，没有其他具体的安全考虑。
This document proposes adaptive video streaming for ICN, identified potential problems, and presents the combination of CCN with DASH as a solution. As both concepts, DASH and CCN, maintain several elements in common, like, e.g., the content in different versions being dealt with in segments, combination of both technologies seems useful. Thus, adaptive streaming over CCN can leverage advantages such as, e.g., efficient caching and intrinsic multicast support of CCN, routing based on named-data URIs, intrinsic multilink and multisource support, etc.
本文档提出了ICN的自适应视频流，识别了潜在的问题，并将CCN与DASH相结合作为解决方案。由于DASH和CCN这两个概念都有几个共同的元素，例如，不同版本中的内容以分段方式处理，因此这两种技术的组合似乎很有用。因此，CCN上的自适应流可以利用诸如CCN的高效缓存和固有多播支持、基于命名数据URI的路由、固有多链路和多源支持等优点。
In this context, the usage of CCN with DASH in mobile environments comes together with advantages compared to today's solutions, especially for devices equipped with multiple network interfaces. The retrieval of data over multiple links in parallel is a useful feature, specifically for adaptive multimedia streaming since it offers the possibility to dynamically switch between the available links depending on their bandwidth capabilities, which are transparent to the actual DASH client.
在这种情况下，与当今的解决方案相比，在移动环境中使用CCN和DASH具有优势，特别是对于配备多个网络接口的设备。通过多条链路并行检索数据是一项有用的功能，特别是对于自适应多媒体流，因为它提供了根据带宽能力在可用链路之间动态切换的可能性，而带宽能力对实际DASH客户端是透明的。
[Rainer16] Rainer, B., Posch, D., and H. Hellwagner, "Investigating the Performance of Pull-based Dynamic Adaptive Streaming in NDN", IEEE Journal on Selected Areas in Communications (J-SAC): Special Issue on Video Distribution over Future Internet, Volume 34, Number 8, DOI 10.1109/JSAC.2016.2577365, August 2016.
[Rainer16]Rainer，B.，Posch，D.，和H.Hellwagner，“研究NDN中基于拉的动态自适应流媒体的性能”，IEEE通信选定领域杂志（J-SAC）：关于未来互联网视频分发的特刊，第34卷，第8期，DOI 10.1109/JSAC.2016.2577365，2016年8月。
[RFC6972] Zhang, Y. and N. Zong, "Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP)", RFC 6972, DOI 10.17487/RFC6972, July 2013, <http://www.rfc-editor.org/info/rfc6972>.
[RFC6972]Zhang，Y.和N.Zong，“点对点流协议（PPSP）的问题陈述和要求”，RFC 6972，DOI 10.17487/RFC6972，2013年7月<http://www.rfc-editor.org/info/rfc6972>.
[ATIS-IIF] "ATIS: IIF, IPTV Interoperability Forum", 2015, <http://www.atis.org/iif/deliv.asp>.
[ATIS-IIF]“ATIS:IIF，IPTV互操作性论坛”，2015年<http://www.atis.org/iif/deliv.asp>.
[Bakker15] Bakker, A., Petrocco, R., and V. Grishchenko, "Peer-to-Peer Streaming Peer Protocol (PPSPP)", RFC 7574, DOI 10.17487/RFC7574, July 2015, <http://www.rfc-editor.org/info/rfc7574>.
[Bakker15]Bakker，A.，Petrocco，R.，和V.Grishchenko，“对等流媒体对等协议（PPSP）”，RFC 7574，DOI 10.17487/RFC75742015年7月<http://www.rfc-editor.org/info/rfc7574>.
[Castro03] Castro, M., Druschel, P., Kermarrec, A., Nandi, A., and A. Rowstron, "SplitStream: High-Bandwidth Multicast in Cooperative Environments", Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP '03), DOI 10.1145/945445.945474, October 2003.
[Castro03]Castro，M.，Druschel，P.，Kermarrec，A.，Nandi，A.，和A.Rowstron，“分割流：协作环境中的高带宽多播”，第19届ACM操作系统原理研讨会论文集（SOSP'03），DOI 10.1145/945445.945474，2003年10月。
[Chai11] Chai, W., Wang, N., Psaras, I., Pavlou, G., Wang, C., de Blas, G., Ramon-Salguero, F., Liang, L., Spirou, S., Blefari-Melazzi, N., Beben, A., and E. Hadjioannou, "CURLING: Content-Ubiquitous Resolution and Delivery Infrastructure for Next Generation Services", IEEE Communications Magazine, Volume 49, Issue 3, DOI 10.1109/MCOM.2011.5723808, March 2011.
[Chai11]Chai，W.，Wang，N.，Psaras，I.，Pavlou，G.，Wang，C.，de Blas，G.，Ramon Salguero，F.，Liang，L.，Spiro，S.，Blefari Melazzi，N.，Beben，A.，和E.Hadjioannou，“卷曲：下一代服务的内容无处不在的解析和交付基础设施”，《IEEE通信杂志》，第49卷，第3期，DOI 10.1109/MCOM.2011.5723808，2011年3月。
[Chanda13] Chanda, A., Westphal, C., and D. Raychaudhuri, "Content Based Traffic Engineering in Software Defined Information Centric Networks", 2013 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), DOI 10.1109/INFCOMW.2013.6970717, April 2013.
[Chanda13]Chanda，A.，Westphal，C.，和D.Raychaudhuri，“软件定义的信息中心网络中基于内容的流量工程”，2013年IEEE计算机通信研讨会会议（INFOCOM WKSHP），DOI 10.1109/INFCOMW.2013.6970717，2013年4月。
[Corujo12] Corujo, D., Vidal, I., Garcia-Reinoso, J., and R. Aguiar, "A Named Data Networking Flexible Framework for Management Communications", IEEE Communications Magazine, Volume 50, Issue 12, DOI 10.1109/MCOM.2012.6384449, December 2012.
[Corujo12]Corujo，D.，Vidal，I.，Garcia Reinoso，J.，和R.Aguiar，“管理通信的命名数据网络灵活框架”，IEEE通信杂志，第50卷，第12期，DOI 10.1109/MCOM.2012.6384449，2012年12月。
[Crabtree13] Crabtree, B., Stevens, T., Allan, B., Lederer, S., Posch, D., Mueller, C., and C. Timmerer, "Video Adaptation in Limited/Zero Network Coverage", CCNxCon 2013, Palo Alto Research Center (PARC), September 2013.
[Crabtree13]Crabtree，B.，Stevens，T.，Allan，B.，Lederer，S.，Posch，D.，Mueller，C.，和C.Timmer，“有限/零网络覆盖下的视频自适应”，CCNxCon 2013，帕洛阿尔托研究中心（PARC），2013年9月。
[Detti11] Detti, A., Blefari-Melazzi, N., Salsano, S., and M. Pomposini, "CONET: A Content Centric Inter-Networking Architecture", Proceedings of the ACM SIGCOMM Workshop on Information-Centric Networking, DOI 10.1145/2018584.2018598, August 2011.
[Detti11]Detti，A.，Blefari Melazzi，N.，Salsano，S.，和M.Pomposini，“CONET：以内容为中心的互联架构”，ACM SIGCOMM信息中心网络研讨会论文集，DOI 10.1145/2018584.2018598，2011年8月。
[Detti12] Detti, A., Pomposini, M., Blefari-Melazzi, N., Salsano, S., and A. Bragagnini, "Offloading cellular networks with Information-Centric Networking: the case of video streaming", 2013 IEEE 14th International Symposium on A World of Wireless, Mobile and Multimedia Networks (WoWMoM), DOI 10.1109/WoWMoM.2012.6263734, June 2012.
[Detti12]Detti，A.，Pomposini，M.，Blefari Melazzi，N.，Salsano，S.，和A.Bragagnini，“使用以信息为中心的网络卸载蜂窝网络：视频流的案例”，2013年IEEE第十四届无线、移动和多媒体网络世界国际研讨会（WoWMoM），DOI 10.1109/WoWMoM.2012.6263734，2012年6月。
[Detti13] Detti, A., Ricci, B., and N. Blefari-Melazzi, "Peer-To-Peer Live Adaptive Video Streaming for Information Centric Cellular Networks", 2013 IEEE 24th Annual International Symposium on Personal, Indoor, and Mobile Radio Communications (PIMRC), DOI 10.1109/PIMRC.2013.6666771, September 2013.
[Detti13]Detti，A.，Ricci，B.，和N.Blefari Melazzi，“用于以信息为中心的蜂窝网络的点对点实时自适应视频流”，2013年IEEE第24届个人、室内和移动无线电通信国际年会（PIMRC），DOI 10.1109/PIMRC.2013.66667711913年9月。
[Fiat94] Fiat, A. and M. Naor, "Broadcast Encryption", Advances in Cryptology - CRYPTO '93 Proceedings, Lecture Notes in Computer Science, Volume 773, pp. 480-491, 1994.
[Fiat94]Fiat，A.和M.Naor，“广播加密”，密码学进展-加密'93会议录，计算机科学讲稿，第773卷，第480-4911994页。
[Fu13] Fu, B., Kunzmann, G., Wetterwald, M., Corujo, D., and R. Costa, "QoE-aware traffic management for mobile video delivery", 2013 IEEE International Conference on Communications Workshops (ICC), DOI 10.1109/ICCW.2013.6649314, June 2013.
[Fu13]Fu，B.，Kunzmann，G.，Wetterwald，M.，Corujo，D.，和R.Costa，“移动视频传输的QoE感知流量管理”，2013年IEEE国际通信研讨会（ICC），DOI 10.1109/ICCW.2013.6649314，2013年6月。
[Grandl13] Grandl, R., Su, K., and C. Westphal, "On the Interaction of Adaptive Video Streaming with Content-Centric Networks", 2013 IEEE International Conference on Multimedia and Expo (ICME), DOI 10.1109/ICME.2013.6607500, July 2013.
[Grandl13]Grandl，R.，Su，K.，和C.Westphal，“关于自适应视频流与以内容为中心的网络的交互”，2013年IEEE多媒体与博览会国际会议（ICME），DOI 10.1109/ICME.2013.6607500，2013年7月。
[IETF-PPSP] IETF, "Peer to Peer Streaming Protocol (ppsp)", <https://datatracker.ietf.org/wg/ppsp/>.
[IETF-PPSP]IETF，“对等流协议（PPSP）”<https://datatracker.ietf.org/wg/ppsp/>.
[ISO-DASH] ISO, "Information technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats", ISO/IEC 23009-1:2014, May 2014.
[ISO-DASH]ISO，“信息技术——HTTP上的动态自适应流传输（DASH）——第1部分：媒体呈现描述和片段格式”，ISO/IEC 23009-1:2014，2014年5月。
[ITEC-DASH] "ITEC - Dynamic Adaptive Streaming over HTTP", DASH Research at the Institute of Information Technology, Multimedia Communication Group, Alpen-Adria Universitaet Klagenfurt, <http://dash.itec.aau.at>.
[ITEC-DASH]“ITEC-HTTP上的动态自适应流”，克拉根福阿尔卑斯阿德里亚大学多媒体通信集团信息技术研究所的DASH研究<http://dash.itec.aau.at>.
[Jacobson09a] Jacobson, V., Smetters, D., Briggs, N., Plass, M., Stewart, P., Thornton, J., and R. Braynard, "VoCCN: Voice-over Content-Centric Networks", Proceedings of the 2009 Workshop on Re-architecting the Internet, DOI 10.1145/1658978.1658980, December 2009.
[Jacobson09a]Jacobson，V.，Smetters，D.，Briggs，N.，Plass，M.，Stewart，P.，Thornton，J.，和R.Braynard，“VoCCN：以内容为中心的语音网络”，2009年互联网重新架构研讨会论文集，DOI 10.1145/1658978.1658980，2009年12月。
[Jacobson09b] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N., and R. Braynard, "Networking Named Content", Proceedings of the 5th International Conference on Emerging Networking Experiments and Technologies (CoNEXT), DOI 10.1145/1658939.1658941, December 2009.
[Jacobson09b]Jacobson，V.，Smetters，D.，Thornton，J.，Plass，M.，Briggs，N.，和R.Braynard，“网络命名内容”，第五届新兴网络实验和技术国际会议记录，DOI 10.1145/1658939.16589411909年12月。
[LeCallet13] Le Callet, P., Moeller, S., and A. Perkis, "Qualinet White Paper on Definitions of Quality of Experience", European Network on Quality of Experience in Multimedia Systems and Services, COST Action IC 1003, Version 1.2, March 2013.
[LeCallet13]Le Callet，P.，Moeller，S.，和A.Perkis，“关于体验质量定义的Qualinet白皮书”，欧洲多媒体系统和服务体验质量网络，成本行动IC 1003，版本1.2，2013年3月。
[Lederer13a] Lederer, S., Liu, Y., Geurts, J., Point, J., Lederer, S., Mueller, C., Rainer, B., Timmerer, C., and H. Hellwagner, "Dynamic Adaptive Streaming over CCN: A Caching and Overhead Analysis", 2013 IEEE International Conference on Communication (ICC), DOI 10.1109/ICC.2013.6655116, June 2013.
[Lederer13a]Lederer，S.，Liu，Y.，Geurts，J.，Point，J.，Lederer，S.，Mueller，C.，Rainer，B.，Timmer，C.，和H.Hellwagner，“CCN上的动态自适应流：缓存和开销分析”，2013年IEEE国际通信会议（ICC），DOI 10.1109/ICC.2013.6655116，2013年6月。
[Lederer13b] Lederer, S., Mueller, C., Rainer, B., Timmerer, C., and H. Hellwagner, "An Experimental Analysis of Dynamic Adaptive Streaming over HTTP in Content Centric Networks", 2013 IEEE International Conference on Multimedia and Expo (ICME), DOI 10.1109/ICME.2013.6607500, July 2013.
[Lederer13b]Lederer，S.，Mueller，C.，Rainer，B.，Timmer，C.，和H.Hellwagner，“以内容为中心的网络中HTTP动态自适应流的实验分析”，2013年IEEE国际多媒体与博览会（ICME），DOI 10.1109/ICME.2013.6607500，2013年7月。
[Magharei07] Magharei, N., Rejaie, R., and Y. Guo, "Mesh or Multiple-Tree: A Comparative Study of Live P2P Streaming Approaches", IEEE INFOCOM 2007 - 26th IEEE International Conference on Computer Communications, DOI 10.1109/INFCOM.2007.168, May 2007.
[Magharei07]Magharei，N.，Rejaie，R.，和Y.Guo，“网格或多树：实时P2P流媒体方法的比较研究”，IEEE INFOCOM 2007-第26届IEEE国际计算机通信会议，DOI 10.1109/INFCOM.2007.168，2007年5月。
[Medard12] Medard, M., Kim, M., Parandeh-Gheibi, M., Zeng, W., and M. Montpetit, "Quality of Experience for Multimedia Communications: Network Coding Strategies", Laboratory of Electronics, Massachusetts Institute of Technology, March 2012.
[Medard12]Medard，M.，Kim，M.，Paradeh Gheibi，M.，Zeng，W.，和M.Montpetit，“多媒体通信的体验质量：网络编码策略”，麻省理工学院电子实验室，2012年3月。
[MEDIEVAL] "MEDIEVAL: MultiMEDia transport for mobIlE Video AppLications", 2010, <http://www.ict-medieval.eu>.
[中世纪]“中世纪：移动视频应用的多媒体传输”，2010年<http://www.ict-medieval.eu>.
[Montpetit13a] Montpetit, M., Holtzman, H., Chakrabarti, K., and M. Matijasevic, "Social video consumption: Synchronized viewing experiences across devices and networks", 2013 IEEE International Conference on Communications Workshops (ICC), pp. 286-290, DOI 10.1109/ICCW.2013.6649245, 2013.
[Montpetit13a]Montpetit，M.，Holtzman，H.，Chakrabarti，K.，和M.Matijasevic，“社交视频消费：跨设备和网络的同步观看体验”，2013年IEEE国际通信研讨会（ICC），第286-290页，DOI 10.1109/ICCW.2013.6649245，2013年。
[Montpetit13b] Montpetit, M., Westphal, C., and D. Trossen, "Network Coding Meets Information-Centric Networking: An Architectural Case for Information Dispersion Through Native Network Coding", Proceedings of the 1st ACM Workshop on Emerging Name-Oriented Mobile Networking Design-Architecture, Algorithms, and Applications, DOI 10.1145/2248361.2248370, June 2013.
[Montpetit 13b]Montpetit，M.，Westphal，C.，和D.Trossen，“网络编码满足信息中心网络：通过本机网络编码实现信息分散的架构案例”，关于新兴的面向名称的移动网络设计架构、算法和应用的第一届ACM研讨会论文集，内政部10.1145/2248361.22483702013年6月。
[Mueller12] Mueller, C., Lederer, S., and C. Timmerer, "A Proxy Effect Analysis and Fair Adaptation Algorithm for Multiple Competing Dynamic Adaptive Streaming over HTTP Clients", 2012 IEEE Visual Communications and Image Processing (VCIP), DOI 10.1109/VCIP.2012.6410799, November 2012.
[Mueller12]Mueller，C.，Lederer，S.，和C.Timmer，“HTTP客户端上多个竞争动态自适应流的代理效应分析和公平自适应算法”，2012 IEEE视觉通信和图像处理（VCIP），DOI 10.1109/VCIP.2012.6410799，2012年11月。
[NETINF] "NetInf: Network of Information", <http://www.netinf.org>.
[NETINF]“NETINF：信息网络”<http://www.netinf.org>.
[Posch13] Posch, D., Hellwagner, H., and P. Schartner, "On-Demand Video Streaming based on Dynamic Adaptive Encrypted Content Chunks", Proceedings of the 8th International Workshop on Secure Network Protocols (NPSec '13), DOI 10.1109/ICNP.2013.6733673, October 2013.
[Posch13]Posch，D.，Hellwagner，H.，和P.Schartner，“基于动态自适应加密内容块的点播视频流”，第八届安全网络协议国际研讨会论文集（NPSec'13），DOI 10.1109/ICNP.2013.6733673，2013年10月。
[RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G., Tyson, G., Davies, E., Molinaro, A., and S. Eum, "Information-Centric Networking: Baseline Scenarios", RFC 7476, DOI 10.17487/RFC7476, March 2015, <http://www.rfc-editor.org/info/rfc7476>.
[RFC7476]Pentikousis，K.，Ed.，Ohlman，B.，Corujo，D.，Boggia，G.，Tyson，G.，Davies，E.，Molinaro，A.，和S.Eum，“以信息为中心的网络：基线场景”，RFC 7476，DOI 10.17487/RFC7476，2015年3月<http://www.rfc-editor.org/info/rfc7476>.
[RFC7846] Cruz, R., Nunes, M., Xia, J., Huang, R., Ed., Taveira, J., and D. Lingli, "Peer-to-Peer Streaming Tracker Protocol (PPSTP)", RFC 7846, DOI 10.17487/RFC7846, May 2016, <http://www.rfc-editor.org/info/rfc7846>.
[RFC7846]Cruz，R.，Nunes，M.，Xia，J.，Huang，R.，Ed.，Taveira，J.，和D.Lingli，“点对点流跟踪协议（PPSTP）”，RFC 7846，DOI 10.17487/RFC7846，2016年5月<http://www.rfc-editor.org/info/rfc7846>.
[Su14] Su, K. and C. Westphal, "On the Benefit of Information Centric Networks for Traffic Engineering", 2014 IEEE International Conference on Communications (ICC), DOI 10.1109/ICC.2014.6883810, June 2014.
[Su14]Su，K.和C.Westphal，“关于以信息为中心的网络对交通工程的好处”，2014年IEEE国际通信会议（ICC），DOI 10.1109/ICC.2014.6883810，2014年6月。
Acknowledgments
致谢
This work was supported in part by the European Community in the context of the SocialSensor (FP7-ICT-287975) project and partly performed in the Lakeside Labs research cluster at AAU. SocialSensor receives research funding from the European Community's Seventh Framework Programme. The work for this document was also partially performed in the context of the FP7/NICT EU-JAPAN GreenICN project, <http://www.greenicn.org>. Apart from this, the European Commission has no responsibility for the content of this document. The information in this document is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user, thereof, uses the information at its sole risk and liability.
这项工作部分得到了欧洲共同体在SocialSensor（FP7-ICT-287975）项目背景下的支持，部分工作在AAU的湖边实验室研究集群中进行。SocialSensor从欧洲共同体第七个框架计划获得研究资金。本文件的部分工作也是在FP7/NICT欧盟-日本绿色ICN项目的背景下进行的<http://www.greenicn.org>. 除此之外，欧盟委员会对本文件的内容不承担任何责任。本文件中的信息按原样提供，不保证或保证该信息适用于任何特定用途。因此，用户使用信息的风险和责任由其自行承担。
Authors' Addresses
作者地址
Cedric Westphal (editor) Huawei
塞德里克·韦斯特法尔（编辑）华为
Email: Cedric.Westphal@huawei.com
Email: Cedric.Westphal@huawei.com
Stefan Lederer Alpen-Adria University Klagenfurt
克拉根福阿尔彭阿德里亚大学
Email: stefan.lederer@itec.aau.at
Email: stefan.lederer@itec.aau.at
Daniel Posch Alpen-Adria University Klagenfurt
丹尼尔·波什·阿尔彭·阿德里亚大学克拉根福分校
Email: daniel.posch@itec.aau.at
Email: daniel.posch@itec.aau.at
Christian Timmerer Alpen-Adria University Klagenfurt
克拉根福克里斯蒂安·蒂默尔·阿尔彭·阿德里亚大学
Email: christian.timmerer@itec.aau.at
Email: christian.timmerer@itec.aau.at
Aytac Azgin Huawei
Aytac Azgin华为
Email: aytac.azgin@huawei.com
Email: aytac.azgin@huawei.com
Will (Shucheng) Liu Huawei
威尔（舒城）刘华伟
Email: liushucheng@huawei.com
Email: liushucheng@huawei.com
Christopher Mueller BitMovin
克里斯托弗·穆勒·比特莫文
Email: christopher.mueller@bitmovin.net
Email: christopher.mueller@bitmovin.net
Andrea Detti University of Rome Tor Vergata
罗马安德列德蒂大学
Email: andrea.detti@uniroma2.it
Email: andrea.detti@uniroma2.it
Daniel Corujo Instituto de Telecomunicacoes Aveiro
丹尼尔·科鲁乔阿维罗电信研究所
Email: dcorujo@av.it.pt
Email: dcorujo@av.it.pt
Jianping Wang City University of Hong Kong
建平王城香港大学
Email: jianwang@cityu.edu.hk
Email: jianwang@cityu.edu.hk
Marie-Jose Montpetit MIT
麻省理工学院玛丽·何塞·蒙佩蒂
Email: marie@mjmontpetit.com
Email: marie@mjmontpetit.com
Niall Murray Athlone Institute of Technology
尼尔·默里·阿思隆理工学院
Email: nmurray@research.ait.ie
Email: nmurray@research.ait.ie