Internet Research Task Force (IRTF) D. Kutscher, Ed.
Request for Comments: 7927 NEC
Category: Informational S. Eum
ISSN: 2070-1721 Osaka University
K. Pentikousis
Travelping
I. Psaras
UCL
D. Corujo
Universidade de Aveiro
D. Saucez
INRIA
T. Schmidt
HAW Hamburg
M. Waehlisch
FU Berlin
July 2016
Internet Research Task Force (IRTF) D. Kutscher, Ed.
Request for Comments: 7927 NEC
Category: Informational S. Eum
ISSN: 2070-1721 Osaka University
K. Pentikousis
Travelping
I. Psaras
UCL
D. Corujo
Universidade de Aveiro
D. Saucez
INRIA
T. Schmidt
HAW Hamburg
M. Waehlisch
FU Berlin
July 2016
Information-Centric Networking (ICN) Research Challenges
以信息为中心的网络（ICN）研究挑战
Abstract
摘要
This memo describes research challenges for Information-Centric Networking (ICN), an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling or enhancing a number of desirable features, such as security, user mobility, multicast, and in-network caching. Mechanisms for realizing these benefits is the subject of ongoing research in the IRTF and elsewhere. This document describes current research challenges in ICN, including naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management.
本备忘录描述了以信息为中心的网络（ICN）的研究挑战，ICN是一种通过引入唯一命名的数据作为核心互联网原则来发展互联网基础设施以直接支持信息分发的方法。数据变得独立于位置、应用程序、存储和运输工具，实现或增强了许多理想的功能，如安全性、用户移动性、多播和网络缓存。实现这些好处的机制是IRTF和其他地方正在进行的研究主题。本文档描述了ICN当前的研究挑战，包括命名、安全性、路由、系统可扩展性、移动性管理、无线网络、传输服务、网络缓存和网络管理。
This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).
本文件是IRTF信息中心网络研究小组（ICNRG）的产品。
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/rfc7927.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7927.
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. Problems with Host-Centric Communications .......................4
3. ICN Terminology and Concepts ....................................6
3.1. Terminology ................................................6
3.2. Concepts ...................................................6
4. ICN Research Challenges .........................................8
4.1. Naming, Data Integrity, and Data Origin Authentication .....8
4.2. Security ..................................................10
4.2.1. Data Integrity and Origin Authentication ...........10
4.2.2. Binding NDOs to Real-World Identities ..............11
4.2.3. Access Control and Authorization ...................12
4.2.4. Encryption .........................................13
4.2.5. Traffic Aggregation and Filtering ..................13
4.2.6. State Overloading ..................................13
4.2.7. Delivering Data Objects from Replicas ..............14
4.2.8. Cryptographic Robustness ...........................14
4.2.9. Routing and Forwarding Information Bases ...........15
4.3. Routing and Resolution System Scalability .................15
4.3.1. Route-By-Name Routing ..............................15
4.3.2. Lookup-By-Name Routing .............................16
4.3.3. Hybrid Routing .....................................17
4.4. Mobility Management .......................................18
4.5. Wireless Networking .......................................20
4.6. Rate and Congestion Control ...............................22
4.7. In-Network Caching ........................................24
4.7.1. Cache Placement ....................................24
4.7.2. Content Placement: Content-to-Cache Distribution ...25
4.7.3. Request-to-Cache Routing ...........................26
4.7.4. Staleness Detection of Cached NDOs .................26
4.7.5. Cache Sharing by Multiple Applications .............27
4.8. Network Management ........................................27
4.9. ICN Applications ..........................................29
4.9.1. Web Applications ...................................30
4.9.2. Video Streaming and Download .......................30
4.9.3. Internet of Things .................................31
5. Security Considerations ........................................32
6. Informative References .........................................32
Acknowledgments ...................................................37
Authors' Addresses ................................................37
1. Introduction ....................................................4
2. Problems with Host-Centric Communications .......................4
3. ICN Terminology and Concepts ....................................6
3.1. Terminology ................................................6
3.2. Concepts ...................................................6
4. ICN Research Challenges .........................................8
4.1. Naming, Data Integrity, and Data Origin Authentication .....8
4.2. Security ..................................................10
4.2.1. Data Integrity and Origin Authentication ...........10
4.2.2. Binding NDOs to Real-World Identities ..............11
4.2.3. Access Control and Authorization ...................12
4.2.4. Encryption .........................................13
4.2.5. Traffic Aggregation and Filtering ..................13
4.2.6. State Overloading ..................................13
4.2.7. Delivering Data Objects from Replicas ..............14
4.2.8. Cryptographic Robustness ...........................14
4.2.9. Routing and Forwarding Information Bases ...........15
4.3. Routing and Resolution System Scalability .................15
4.3.1. Route-By-Name Routing ..............................15
4.3.2. Lookup-By-Name Routing .............................16
4.3.3. Hybrid Routing .....................................17
4.4. Mobility Management .......................................18
4.5. Wireless Networking .......................................20
4.6. Rate and Congestion Control ...............................22
4.7. In-Network Caching ........................................24
4.7.1. Cache Placement ....................................24
4.7.2. Content Placement: Content-to-Cache Distribution ...25
4.7.3. Request-to-Cache Routing ...........................26
4.7.4. Staleness Detection of Cached NDOs .................26
4.7.5. Cache Sharing by Multiple Applications .............27
4.8. Network Management ........................................27
4.9. ICN Applications ..........................................29
4.9.1. Web Applications ...................................30
4.9.2. Video Streaming and Download .......................30
4.9.3. Internet of Things .................................31
5. Security Considerations ........................................32
6. Informative References .........................................32
Acknowledgments ...................................................37
Authors' Addresses ................................................37
Information-Centric Networking (ICN) is an approach to evolve the Internet infrastructure to directly support accessing Named Data Objects (NDOs) as a first-order network service. Data objects become independent of location, application, storage, and means of transportation, allowing for inexpensive and ubiquitous in-network caching and replication. The expected benefits are improved efficiency and security, better scalability with respect to information/bandwidth demand, and better robustness in challenging communication scenarios.
以信息为中心的网络（ICN）是一种发展互联网基础设施的方法，以直接支持访问命名数据对象（NDO）作为一级网络服务。数据对象变得独立于位置、应用程序、存储和运输方式，从而实现了廉价且无处不在的网络缓存和复制。预期的好处是提高了效率和安全性，在信息/带宽需求方面具有更好的可扩展性，以及在具有挑战性的通信场景中具有更好的鲁棒性。
ICN concepts can be deployed by retooling the protocol stack: name-based data access can be implemented on top of the existing IP infrastructure, e.g., by allowing for named data structures, ubiquitous caching, and corresponding transport services, or it can be seen as a packet-level internetworking technology that would cause fundamental changes to Internet routing and forwarding. In summary, ICN can evolve the Internet architecture towards a network model based on named data with different properties and different services.
ICN概念可以通过重组协议栈来部署：基于名称的数据访问可以在现有IP基础设施之上实现，例如，通过允许命名数据结构、无处不在的缓存和相应的传输服务，或者，它可以被视为一种数据包级的互联技术，将对互联网路由和转发造成根本性的改变。综上所述，ICN可以将Internet体系结构演变为基于具有不同属性和不同服务的命名数据的网络模型。
This document presents the ICN research challenges that need to be addressed in order to achieve these goals. These research challenges are seen from a technical perspective, although business relationships between Internet players will also influence developments in this area. We leave business challenges for a separate document, however. The objective of this memo is to document the technical challenges and corresponding current approaches and to expose requirements that should be addressed by future research work.
本文件介绍了为实现这些目标需要解决的ICN研究挑战。这些研究挑战是从技术角度来看的，尽管互联网参与者之间的商业关系也将影响这一领域的发展。然而，我们将业务挑战留给单独的文档。本备忘录的目的是记录技术挑战和相应的当前方法，并揭示未来研究工作应解决的需求。
This document has been reviewed, commented on, and discussed extensively for nearly two years by the vast majority of ICNRG members, which certainly exceeds 100 individuals. It is the consensus of ICNRG that the research challenges described in this document should be published in the IRTF stream of the RFC series. This document does not constitute a standard.
近两年来，绝大多数ICNRG成员（当然超过100人）对该文件进行了审查、评论和广泛讨论。ICNRG一致认为，本文件中描述的研究挑战应在RFC系列的IRTF流中公布。本文件不构成标准。
The best current practice to manage the above-mentioned growth in terms of data volume and number of devices is to increase infrastructure investment, employ application-layer overlays that cache content such as Content Distribution Networks (CDNs) and Peer-to-Peer (P2P) applications, provide location-independent access to data, and optimize its delivery. In principle, such platforms
管理上述数据量和设备数量增长的最佳当前做法是增加基础设施投资，采用缓存内容的应用层覆盖，如内容分发网络（CDN）和对等（P2P）应用程序，提供独立于位置的数据访问，并优化其交付。原则上，这些平台
provide a service model of accessing named data objects (NDOs) (e.g., replicated web resources in data centers) instead of a host-to-host packet delivery service model.
提供访问命名数据对象（NDO）的服务模型（例如，数据中心中的复制web资源），而不是主机到主机的数据包交付服务模型。
However, since this functionality resides in overlays only, the full potential of content distribution platforms cannot be leveraged as the network is not aware of data requests and data transmissions. This has the following impact:
但是，由于此功能仅存在于覆盖中，因此无法充分利用内容分发平台的潜力，因为网络不知道数据请求和数据传输。这有以下影响：
o Data traffic typically follows sub-optimal paths as it is effectively routed, depending on the overlay topology instead of the Internet-layer topology.
o 数据流量在有效路由时通常遵循次优路径，这取决于覆盖拓扑而不是Internet层拓扑。
o Network capabilities, such as multicast and broadcast, are largely underutilized or not employed at all. As a result, request and delivery for the same object have to be made multiple times.
o 网络功能，如多播和广播，在很大程度上没有得到充分利用或根本没有得到利用。因此，同一对象的请求和交付必须进行多次。
o Overlays typically require significant infrastructure support, e.g., authentication portals, content storage, and applications servers, making it often impossible to establish local, direct communication.
o 覆盖通常需要重要的基础架构支持，例如身份验证门户、内容存储和应用程序服务器，因此通常无法建立本地直接通信。
o The forwarding layer cannot cooperate with transport-layer functions, so sometimes useful functionality such as local retransmission and local rate control have to be implemented with TCP proxies or other intermediaries.
o 转发层不能与传输层功能协作，因此有时必须使用TCP代理或其他中介来实现有用的功能，如本地重传和本地速率控制。
o Provenance validation uses host authentication today. As such, even if there are locally cached copies available, it is normally not easily possible to validate their authenticity.
o 起源验证现在使用主机身份验证。因此，即使存在可用的本地缓存副本，通常也不容易验证其真实性。
o Many applications follow their own approach to caching, replication, transport, and authenticity validation (if at all), although they all share similar models for accessing named data objects in the network.
o 许多应用程序都遵循自己的方法进行缓存、复制、传输和真实性验证（如果有的话），尽管它们在访问网络中的命名数据对象时都使用类似的模型。
Host-centric communication systems restrict applications to data transfer between end-hosts only. Naming data directly provides a powerful "hook" for applications to exploit and natively support multi-party communication, e.g., multi-source/multi-destination communication and a ubiquitous information ecosystem that is not restricted to end-host addresses.
以主机为中心的通信系统将应用程序限制为仅在终端主机之间进行数据传输。命名数据直接为应用程序提供了一个强大的“钩子”，以利用和本机支持多方通信，例如，多源/多目的地通信和不限于终端主机地址的无处不在的信息生态系统。
Information-Centric Networking (ICN): A concept for communicating in a network that provides accessing named data objects as a first order service. See Section 3.2 for details.
以信息为中心的网络（ICN）：在提供访问命名数据对象作为一级服务的网络中进行通信的概念。详见第3.2节。
Named Data Object (NDO): Addressable data unit in an information-centric network that can represent a collection of bytes or a piece of information. In ICN, each data object has a name bound to it, and there are typically mechanisms to secure (and validate) this binding. Different ICN approaches have different concepts for how to map NDOs to individual units of transport, e.g., chunks and segments. Sometimes smaller units may be represented by NDOs themselves. Within the context of this document, an NDO is any named data object that can be requested from the network, and we do not consider sub-units below the NDO level. In this document, we often use the terms "NDO" and "data object" interchangeably.
命名数据对象（NDO）：以信息为中心的网络中的可寻址数据单元，可表示字节集合或信息片段。在ICN中，每个数据对象都有一个绑定到它的名称，并且通常有一些机制来保护（和验证）这个绑定。不同的ICN方法对于如何将NDO映射到单个传输单元（例如块和段）有不同的概念。有时较小的单位可能由NDO本身表示。在本文档的上下文中，NDO是可以从网络请求的任何命名的数据对象，并且我们不考虑低于NDO级别的子单元。在本文档中，我们经常交替使用术语“NDO”和“数据对象”。
Requestor: Entity in an ICN network that is sending a request for a named data object to the network.
请求者：ICN网络中向网络发送命名数据对象请求的实体。
Publisher: Entity in an ICN network that publishes an NDO to the network, so that corresponding requests can reach the publisher. The publisher does not need to be identical to the actual creator, for example, a publisher could provide the service of hosting NDOs on behalf of the actual creators/owners.
发布者：ICN网络中的实体，将NDO发布到网络，以便相应的请求可以到达发布者。发布者不需要与实际创建者完全相同，例如，发布者可以代表实际创建者/所有者提供托管NDO的服务。
Fundamentally, ICN provides access to named data as a first-order network service, i.e., the network is able to serve requests to named data natively. That means network nodes can receive requests for named data and act as necessary, for example, by forwarding the request to a suitable next hop. Consequently, the network processes requests for named data objects (and corresponding responses) natively. Every network node on a path is enabled to perform forwarding decisions, cache objects, etc. This enables the network to forward such requests on optimal paths, employing the best transmission technologies at every node, e.g., broadcast/multicast transmission in wireless networks to avoid duplicate transmission of both requests and responses.
基本上，ICN作为一阶网络服务提供对命名数据的访问，即网络能够以本机方式为对命名数据的请求提供服务。这意味着网络节点可以接收命名数据的请求，并根据需要采取行动，例如，将请求转发到合适的下一跳。因此，网络以本机方式处理对命名数据对象的请求（以及相应的响应）。路径上的每个网络节点能够执行转发决策、缓存对象等。这使得网络能够在最佳路径上转发此类请求，在每个节点处采用最佳传输技术，例如，无线网络中的广播/多播传输，以避免请求和响应的重复传输。
In ICN, there is a set of common concepts and node requirements beyond this basic service model. Naming data objects is a key concept. In general, ICN names represent neither network nodes nor interfaces -- they represent NDOs independently of their location.
在ICN中，除了这个基本服务模型之外，还有一组通用概念和节点需求。命名数据对象是一个关键概念。通常，ICN名称既不表示网络节点也不表示接口——它们表示独立于其位置的NDO。
Names do play a key role in forwarding decisions and are used for matching requests to responses: in order to provide better support for accessing copies of NDOs regardless of their location, it is important to be able to validate that a response actually delivers the bits that correspond to an original request for named data.
名称在转发决策中起着关键作用，并用于将请求与响应进行匹配：为了更好地支持访问NDO副本（无论其位置如何），必须能够验证响应是否实际传递了与命名数据的原始请求相对应的位。
Name-content binding validation is a fundamental security service in ICN, and this is often achieved by establishing a verifiable binding between the object name and the actual object or an identity that has created the object. ICN can support other security services, such as provenance validation and encryption, depending on the details of naming schemes, object models, and assumptions on infrastructure support. Security services such as name-content binding validation are available to any node, i.e., not just the actual requestors. This is an important feature for enabling ingress gateways to check object authenticity to prevent denial-of-service attacks.
名称内容绑定验证是ICN中的一项基本安全服务，通常通过在对象名称和实际对象或创建对象的标识之间建立可验证的绑定来实现。ICN可以支持其他安全服务，如来源验证和加密，具体取决于命名方案、对象模型和基础设施支持假设的详细信息。任何节点都可以使用名称内容绑定验证等安全服务，而不仅仅是实际的请求者。这是使入口网关能够检查对象真实性以防止拒绝服务攻击的一项重要功能。
Based on these fundamental properties, it is possible to leverage network storage ubiquitously: every ICN node can cache data objects and respond to requests for such objects -- it is not required to validate the authenticity of the node itself since name-content bindings can be validated. Ubiquitous in-network storage can be used for different purposes: it can enable sharing, i.e., the same object copy can be delivered to multiple users/nodes as in today's proxy caches and CDNs. It can also be used to make communication more robust (and perform better) by enabling the network to answer requests from local caches (instead of from origin servers). In case of disruption (message not delivered), a node can resend the request, and it could be answered by an on-path cache, i.e., on the other side of the disrupted link. The network itself would be able to send local retransmissions, which enables shorter round-trip times and the offloading of origin servers and other parts of the network.
基于这些基本属性，可以无处不在地利用网络存储：每个ICN节点都可以缓存数据对象并响应对此类对象的请求——不需要验证节点本身的真实性，因为可以验证名称内容绑定。无处不在的网络存储可以用于不同的目的：它可以实现共享，即，同一个对象副本可以像今天的代理缓存和CDN一样交付给多个用户/节点。它还可以通过使网络能够响应来自本地缓存（而不是来自源服务器）的请求，从而使通信更加健壮（并且性能更好）。在中断（消息未传递）的情况下，节点可以重新发送请求，并且可以由路径缓存（即，在中断链路的另一侧）响应请求。网络本身将能够发送本地重传，从而缩短往返时间并卸载源服务器和网络的其他部分。
ICN potentially retrieves segments of NDOs from multiple data sources, so only a requestor can determine the completion of a retrieval process, i.e., the retrieval of NDOs or individual segments is typically controlled by a requestor. For this reason, ICN transport protocols are typically based on a receiver-driven mechanism: requestors can control message sending rates by regulating the request sending rate (assuming that every response message has to be triggered by a request message). Retransmission would be achieved by resending requests, e.g., after a timeout. Because objects can be replicated, object transmission and transport sessions would not necessarily have end-to-end semantics: requests can be answered by caches, and a node can select one or multiple next-hop destinations for a particular request depending on configuration, observed performance, or other criteria.
ICN可能从多个数据源检索NDO段，因此只有请求者才能确定检索过程的完成情况，即NDO或单个段的检索通常由请求者控制。因此，ICN传输协议通常基于接收器驱动的机制：请求者可以通过调节请求发送速率来控制消息发送速率（假设每个响应消息都必须由请求消息触发）。重新传输将通过重新发送请求来实现，例如，在超时之后。由于对象可以复制，对象传输和传输会话不一定具有端到端语义：请求可以由缓存响应，节点可以根据配置、观察到的性能或其他标准为特定请求选择一个或多个下一跳目的地。
This receiver-driven communication model potentially enables new interconnection and business models: a request for named data can be linked to an interest of a requestor (or requesting network) in data from another peer, which could suggest modeling peering agreements and charging accordingly.
这种接收器驱动的通信模型可能实现新的互连和业务模型：对命名数据的请求可以链接到请求者（或请求网络）对来自另一个对等方的数据的兴趣，这可能建议对对等协议进行建模并相应收费。
Naming data objects is as important for ICN as naming hosts is for today's Internet. Fundamentally, ICN requires unique names for individual NDOs, since names are used for identifying objects independently of their location or container. In addition, since NDOs can be cached anywhere, the origin cannot be trusted anymore, hence the importance of establishing a verifiable binding between the object and its name (name-data binding validation) so that a requestor can be sure that the received bits do correspond to the NDO originally requested (data integrity). Data origin authentication is a different security service that can be related to naming, i.e., verifying that an NDO has indeed been published by a publisher (that could be identified by a name prefix).
命名数据对象对ICN的重要性与命名主机对当今互联网的重要性一样。基本上，ICN要求单个NDO具有唯一的名称，因为名称用于独立于对象的位置或容器来标识对象。此外，由于NDO可以缓存在任何地方，因此无法再信任源，因此必须在对象与其名称之间建立可验证的绑定（名称数据绑定验证），以便请求者可以确保接收的位确实对应于最初请求的NDO（数据完整性）。数据源身份验证是一种与命名相关的不同安全服务，即验证NDO是否确实已由发布者发布（可通过名称前缀识别）。
The above functions are fundamentally required for the information-centric network to work reliably; otherwise, neither network elements nor requestors can trust object authenticity. Lack of this trust enables several attacks, including DoS attacks, by injecting spoofed content into the network. There are different ways to use names and cryptography to achieve the desired functions [ICNNAMING] [ICNSURVEY], and there are different ways to manage namespaces correspondingly.
上述功能是以信息为中心的网络可靠工作的基本要求；否则，网络元素和请求者都不能信任对象真实性。由于缺乏这种信任，通过向网络中注入伪造内容，可能会引发多种攻击，包括DoS攻击。有不同的方法使用名称和密码来实现所需的功能[ICNNAMING][ICNSURVEY]，也有不同的方法来相应地管理名称空间。
Two types of naming schemes have been proposed in the ICN literature: hierarchical and flat namespaces. For example, a hierarchical scheme may have a structure similar to current URIs, where the hierarchy is rooted in a publisher prefix. Such hierarchy enables aggregation of routing information, improving scalability of the routing system. In some cases, names are human readable, which makes it possible for users to manually type in names, reuse, and, to some extent, map the name to the user intent.
ICN文献中提出了两种类型的命名方案：分层名称空间和平面名称空间。例如，层次结构方案可能具有类似于当前URI的结构，其中层次结构以发布者前缀为根。这种层次结构能够聚合路由信息，提高路由系统的可伸缩性。在某些情况下，名称是人类可读的，这使得用户可以手动键入名称、重用，并在某种程度上将名称映射到用户意图。
The second general class of naming schemes enables verifying the object's name-data integrity without requiring a Public Key Infrastructure (PKI) or other third party to first establish trust in the key. This is achieved, e.g., by binding the hash of the NDO content to the object's name. For instance, this can be done by directly embedding the hash of the content in the name. Another option is an indirect binding, which embeds the public key of the
第二类通用命名方案允许验证对象的名称数据完整性，而无需公钥基础设施（PKI）或其他第三方首先建立对密钥的信任。这是通过例如将NDO内容的哈希绑定到对象的名称来实现的。例如，这可以通过在名称中直接嵌入内容的哈希来实现。另一个选项是间接绑定，它嵌入
publisher in the name and signs the hash of the content with the corresponding private key. The resulting names are typically non-hierarchical, or flat, although the publisher field could be employed to create a structure that could facilitate route aggregation.
publisher输入名称，并使用相应的私钥对内容的哈希进行签名。生成的名称通常是非层次化的，或者是扁平的，尽管可以使用publisher字段来创建一个有助于路由聚合的结构。
There are several design trade-offs for ICN naming that affect routing and security. Hash-based names are not human readable nor hierarchical. They can, however, provide some structure for aggregation, for instance, a name part corresponding to a publisher. In hash-based names with indirect binding, the key of the publisher is bound to the name of NDO, so when a user receives, e.g., the triplet, namely (data, key, signature), the receiving entity can verify that the NDO has been generated by the possessor of the private/public key pair and that the NDO has not been changed in transit (data integrity). This can be done by cryptographically hashing the received key and the name of the NDO, and comparing it with the received hashed key. Then, the key can be used to verify the signature.
ICN命名有几个影响路由和安全性的设计权衡。基于散列的名称既不是人类可读的，也不是层次化的。但是，它们可以为聚合提供一些结构，例如，与发布服务器相对应的名称部分。在具有间接绑定的基于散列的名称中，发布者的密钥被绑定到NDO的名称，因此当用户接收到例如三元组，即（数据、密钥、签名）时，接收实体可以验证NDO是由私钥/公钥对的所有者生成的，并且NDO在传输过程中没有被更改（数据完整性）. 这可以通过对接收到的密钥和NDO的名称进行加密散列，并将其与接收到的散列密钥进行比较来实现。然后，可以使用密钥验证签名。
Data origin authentication can be achieved by validating signatures based on public key cryptography about an NDO's name and content. In order to ascertain data integrity and origin authenticity with such an approach, a PKI-like system is required that would allow linking the corresponding public key to a trust chain.
数据源身份验证可以通过基于NDO名称和内容的公钥加密验证签名来实现。为了用这种方法确定数据完整性和来源真实性，需要一个类似PKI的系统，允许将相应的公钥链接到信任链。
Research challenges specific to naming include:
与命名相关的研究挑战包括：
o Naming static data objects can be performed by using content hashes as part of object names, so that publishers can calculate the hash over existing data objects and requestors, and any ICN node can validate the name-content binding by recalculating the hash and comparing it to the name (component). [RFC6920] specifies a concrete naming format for this.
o 可以使用内容哈希作为对象名称的一部分来命名静态数据对象，这样发布者就可以计算现有数据对象和请求者的哈希，任何ICN节点都可以通过重新计算哈希并将其与名称（组件）进行比较来验证名称内容绑定。[RFC6920]为此指定具体的命名格式。
o Naming dynamic objects refers to use cases where the name has to be generated before the object is created. For example, this could be the case for live streaming, when a publisher wants to make the stream available by registering stream chunk names in the network. One approach to this can be hash-based names with indirect binding as described above.
o 命名动态对象是指在创建对象之前必须生成名称的用例。例如，当发布者希望通过在网络中注册流块名称使流可用时，直播流可能就是这种情况。实现这一点的一种方法可以是如上所述的具有间接绑定的基于散列的名称。
o Requestor privacy protection can be a challenge in ICN as a direct consequence of the accessing-named-data-objects paradigm: if the network can "see" requests and responses, it can also log request history for network segments or individual users, which can be undesirable, especially since names are typically expected to be
o 请求者隐私保护在ICN中可能是一个挑战，这是访问命名数据对象范例的直接结果：如果网络可以“看到”请求和响应，它还可以记录网段或单个用户的请求历史，这可能是不可取的，特别是因为通常预期名称是
long-lived. That is, even if the name itself does not reveal much information, the assumption is that the name can be used to retrieve the corresponding data objects in the future.
长寿命。也就是说，即使名称本身没有显示太多信息，也可以假设该名称将来可以用于检索相应的数据对象。
o Updating and versioning NDOs can be challenging because it can contradict fundamental ICN assumptions: if an NDO can be replicated and stored in in-network storage for later retrieval, names have to be long-lived and the name-content binding must not change; updating an object (i.e., changing the content without generating a new name) is not possible. Versioning is one possible solution but requires a naming scheme that supports it (and a way for requestors to learn about newer and older versions).
o 更新和版本化NDO可能具有挑战性，因为它可能与ICN的基本假设相矛盾：如果可以复制NDO并将其存储在网络存储中以供以后检索，则名称必须是长期存在的，并且名称内容绑定不得更改；无法更新对象（即，在不生成新名称的情况下更改内容）。版本控制是一种可能的解决方案，但需要一个支持它的命名方案（以及一种让请求者了解新版本和旧版本的方法）。
o Managing accessibility can also be a challenge. In ICN, the general assumption is to enable ubiquitous access to NDOs, but there can be relevant use cases where access to objects should be restricted, for example, to a specific user group. There are different approaches for this, such as object encryption (requiring key distribution and related mechanisms) or the concept of scopes, e.g., based on names that can only be used/resolved under some constraints.
o 管理可访问性也是一项挑战。在ICN中，一般假设是支持对NDO的无处不在的访问，但是可能存在相关的用例，在这些用例中，对对象的访问应该被限制，例如，特定的用户组。为此有不同的方法，例如对象加密（需要密钥分发和相关机制）或作用域的概念，例如，基于只能在某些约束条件下使用/解析的名称。
Security is an active research field in ICN. This section provides an overview of important security features and corresponding challenges that are related to shifting to information-centric communications. Some challenges are well understood, and there are (sometimes multiple different) approaches to address them, whereas other challenges are active research and engineering topics.
安全性是ICN中一个活跃的研究领域。本节概述了与转向以信息为中心的通信相关的重要安全功能和相应的挑战。有些挑战是众所周知的，有（有时有多种不同的）方法来解决它们，而其他挑战是积极的研究和工程主题。
As mentioned in Section 4.1, data integrity verification is an important ICN feature, since NDOs are retrieved not only from an original copy holder but also from any caching point. Hence, the communication channel endpoints to retrieve NDOs are not trustable anymore, and solutions widely used today such as Transport Layer Security (TLS) [RFC5246] cannot be used as a general solution. Since data objects can be maliciously modified, ICN should provide receivers with a security mechanism to verify the integrity of the data object, and there are different ways to achieve this.
如第4.1节所述，数据完整性验证是ICN的一项重要功能，因为NDO不仅可以从原始副本持有者检索，还可以从任何缓存点检索。因此，检索NDO的通信信道端点不再是可信任的，今天广泛使用的解决方案，如传输层安全性（TLS）[RFC5246]不能用作通用解决方案。由于数据对象可能被恶意修改，ICN应该为接收者提供一种安全机制来验证数据对象的完整性，有不同的方法来实现这一点。
An efficient approach for static NDOs is providing a name-content-binding by hashing an NDO and using the hash as a part of the object's name. [RFC6920] provides a mechanism and a format for representing a digest algorithm and the actual digest in a name (amongst other information).
静态NDO的一种有效方法是通过散列NDO并使用散列作为对象名称的一部分来提供名称内容绑定。[RFC6920]提供了一种机制和格式，用于表示摘要算法和名称中的实际摘要（以及其他信息）。
For dynamic objects where it is desirable to refer to an NDO by name before the object has been created, public key cryptography is often applied, i.e., every NDO would be authenticated by means of a signature performed by the data object publisher so that any data object consumer can verify the validity of the data object based on the signature. However, in order to verify the signature of an object, the consumer must know the public key of the entity that signed the object.
对于希望在创建对象之前按名称引用NDO的动态对象，通常应用公钥加密，即，每个NDO将通过数据对象发布者执行的签名进行身份验证，以便任何数据对象使用者都可以基于签名验证数据对象的有效性。但是，为了验证对象的签名，使用者必须知道对该对象进行签名的实体的公钥。
Data origin authentication, i.e., verifying that an NDO has indeed been published by a publisher, requires a secure binding of an NDO name to a publisher identity -- this is also typically implemented using public key cryptography, i.e., by requiring a receiver to verify digital signatures that are part of received messages.
数据源身份验证，即验证NDO是否确实已由发布者发布，需要NDO名称与发布者身份的安全绑定——这通常也使用公钥加密实现，即要求接收方验证作为接收消息一部分的数字签名。
One research challenge is then to support a mechanism to distribute the publisher's public keys to the consumers of data objects. There are two main approaches to achieve this: one is based on an external third-party authority such as hierarchical Public Key Infrastructure (PKI) (see [RFC5280] for a description of hierarchical PKI), and the other is to adapt a hash-based scheme with indirect binding. The former, as the name implies, depends on an external third party authority to distribute the public key of the publisher for the consumers. In a hash-based scheme with indirect binding, the public key (or a hash of it) would be used as part of the name -- which is sufficient to validate the data integrity.
一个研究挑战是支持一种机制，将发布者的公钥分发给数据对象的消费者。有两种主要方法可以实现这一点：一种是基于外部第三方机构，如分级公钥基础设施（PKI）（有关分级PKI的描述，请参见[RFC5280]），另一种是采用间接绑定的基于哈希的方案。顾名思义，前者依赖外部第三方机构为消费者分发发布者的公钥。在具有间接绑定的基于散列的方案中，公钥（或其散列）将用作名称的一部分——这足以验证数据完整性。
In cases where information about the origin of a data object is not available by other means, the object itself would have to incorporate the necessary information to determine the object publisher, for example, with a certificate, that can be validated through the PKI. Once the certificate is authenticated, its public key can be used to authenticate the signed data object itself.
在数据对象的来源信息无法通过其他方式获得的情况下，对象本身必须包含确定对象发布者所需的信息，例如，可以通过PKI验证的证书。一旦证书通过身份验证，它的公钥就可以用来验证已签名的数据对象本身。
In addition to validating NDO authenticity, it is still important to bind real-world identities, e.g., a publisher identity, to objects, so that a requestor can verify that a received object was actually published by a certain source.
除了验证NDO的真实性外，将真实世界的身份（例如发布者身份）绑定到对象也很重要，这样请求者就可以验证接收到的对象是否确实由某个源发布。
With hash-based names, real-world identity bindings are not intrinsically established: the name provides the hash of the NDO or of the public key that was used to sign the NDO. There needs to be another binding to a real-world identity if that feature is requested.
对于基于散列的名称，真实世界的身份绑定不是本质上建立的：名称提供NDO或用于签署NDO的公钥的散列。如果请求该特性，则需要另一个与真实身份的绑定。
If the object name directly provides the publisher name and if that name is protected by a certificate that links to a PKI-like trust chain, the object name itself can provide an intrinsic binding to a real-world identity.
如果对象名称直接提供发布者名称，并且该名称受链接到类似PKI的信任链的证书保护，则对象名称本身可以提供与真实身份的内在绑定。
Binding between NDOs and real-world identities is essential, but there is no universal way to achieve it as it is all intrinsic to a particular ICN approach.
NDO和真实世界身份之间的绑定是必不可少的，但没有通用的方法来实现它，因为它是特定ICN方法的固有特性。
Access control and authorization is a challenge in ICN, because of the lack of user-to-server authentication in the fundamental communication model based on named data.
访问控制和授权在ICN中是一个挑战，因为在基于命名数据的基本通信模型中缺乏用户到服务器的身份验证。
All ICN entities are capable of delivering NDOs on demand due to their in-network caching function. In such an environment, traditional access control schemes based on Access Control List (ACL) are ill-suited since widely distributed ICN entities have to maintain an identical control policy over NDOs for each consumer, which is prohibited due to computational overhead and privacy issues. There are two complementary approaches to address the issues:
由于具有网络内缓存功能，所有ICN实体都能够按需交付NDO。在这样的环境中，基于访问控制列表（ACL）的传统访问控制方案不适合，因为广泛分布的ICN实体必须为每个消费者维护对NDO的相同控制策略，这是由于计算开销和隐私问题而被禁止的。有两种互补的方法来解决这些问题：
1. Separated approach: access control service from a third party that is independent from ICN entities. Due to the clear separation, ICN entities are free from computational overhead to determine the accessibility of NDOs by consumers; also, consumers can secure their privacy through the independent authorization entity [ACCESS-CTL-DEL]. Relevant challenges to this approach include reducing the authorization delay (when communicating to the access control provider) and currency and consistency of access control information (when access control lists are distributed).
1. 分离方法：独立于ICN实体的第三方提供的访问控制服务。由于清晰的分离，ICN实体不需要计算开销来确定消费者对NDO的可访问性；此外，消费者可以通过独立授权实体[ACCESS-CTL-DEL]保护其隐私。这种方法的相关挑战包括减少授权延迟（与访问控制提供商通信时）以及访问控制信息的通用性和一致性（分发访问控制列表时）。
2. Integrated approach: access control service from ICN entities. This mechanism is often based on content encryption and key distribution [ENCRYPTION-AC]. As mentioned previously, this approach suffers from prohibitive overhead for ICN entities due to the process of key verification. While key distribution is challenging per se, this approach is beneficial in a way that NDOs can be retrieved without the help of an external access control provider. Challenges to this approach include:
2. 综合方法：ICN实体的访问控制服务。这种机制通常基于内容加密和密钥分发[encryption-AC]。如前所述，由于密钥验证过程，这种方法对ICN实体的开销过高。虽然密钥分发本身具有挑战性，但这种方法在无需外部访问控制提供商帮助即可检索NDO方面是有益的。这种方法面临的挑战包括：
1. applying an access control mechanism for dynamic NDOs in in-network caches in a timely manner;
1. 及时为网络缓存中的动态NDO应用访问控制机制；
2. providing consumers with the different levels of accessibility to individual NDOs in a scalable manner; and
2. 以可扩展的方式为消费者提供对各个NDO的不同级别的可访问性；和
3. managing key revocation and similar PKI management functions.
3. 管理密钥撤销和类似的PKI管理功能。
In ICN, NDOs can be encrypted to implement access control (only consumers in possession of corresponding decryption keys can access the content) or privacy (same approach). Distributing and managing the corresponding keys as well as providing usable interfaces to applications and human users are challenges and the subject of ongoing work.
在ICN中，可以对NDO进行加密以实现访问控制（只有拥有相应解密密钥的消费者才能访问内容）或隐私（相同的方法）。分发和管理相应的密钥以及为应用程序和人类用户提供可用的接口是一项挑战，也是正在进行的工作的主题。
In principle, the challenges are similar to those of broadcast/media distribution, and similar approaches (combing symmetric with public key cryptography) are being investigated [NDN-CTL-SHARING].
原则上，这些挑战与广播/媒体分发的挑战相似，类似的方法（将对称密码与公钥密码结合起来）正在研究中[NDN-CTL-SHARING]。
One request message to retrieve a data object can actually aggregate requests coming from several consumers. This aggregation of requests reduces the overall traffic but makes per-requestor filtering harder. The challenge in this case is to provide a mechanism that allows request aggregation and per-requestor filtering. A possible solution is to indicate the set of requestors in the aggregated request such that the response can indicate the subset of requestors allowed to access the data object. However, this solution requires collaboration from other nodes in the network and is not suitable for caching. Another possible solution is to encrypt data objects and ensure that only authorized consumers can decrypt them. This solution does not preclude caching and does not require collaboration from the network. However, it implies a mechanism to generate group keys (e.g., different private keys can be used to decrypt the same encrypted data object) [CHAUM].
一条检索数据对象的请求消息实际上可以聚合来自多个使用者的请求。这种请求聚合减少了总体通信量，但使每个请求者的过滤更加困难。这种情况下的挑战是提供一种允许请求聚合和每个请求者过滤的机制。一种可能的解决方案是指示聚合请求中的请求者集合，以便响应可以指示允许访问数据对象的请求者子集。但是，此解决方案需要网络中其他节点的协作，不适合缓存。另一种可能的解决方案是加密数据对象，并确保只有经过授权的使用者才能解密它们。此解决方案不排除缓存，也不需要网络协作。然而，它意味着一种生成组密钥的机制（例如，不同的私钥可用于解密相同的加密数据对象）[CHAUM]。
ICN solutions that implement state on intermediate routers for request routing or forwarding (e.g., Content-Centric Networking (CCN) [CCN]) are subject to denial-of-service attacks from overloading or superseding the internal state of a router (e.g., "interest flooding" [BACKSCATTER]). Additionally, stateful forwarding can enable attack vectors such as resource exhaustion or complexity attacks to the routing infrastructure. The challenge is then to provision routers
在中间路由器上实现状态以进行请求路由或转发（例如，以内容为中心的网络（CCN）[CCN]）的ICN解决方案会受到来自过载或替代路由器内部状态的拒绝服务攻击（例如，“兴趣溢出”[反向散射]）。此外，有状态转发可使攻击向量（如资源耗尽或对路由基础设施的复杂性攻击）成为可能。接下来的挑战是提供路由器
and construct internal state in a way that alleviates sensibility to such attacks. The problem becomes even harder if the protocol does not provide information about the origin of messages. Without origin, it is a particular challenge to distinguish between regular (intense) use and misuse of the infrastructure.
并以减轻对此类攻击的敏感性的方式构建内部状态。如果协议不提供有关消息来源的信息，问题就更加严重。如果没有来源，区分基础设施的常规（密集）使用和滥用是一个特别的挑战。
A common capability of ICN solutions is data replication and in-network storage. Delivering replicated data objects from caches decouples content consumption from data sources, which leads to a loss of control on (1) content access and (2) content dissemination. In a widely distributed, decentralized environment like the Internet, this raises several challenges.
ICN解决方案的一个常见功能是数据复制和网络存储。从缓存交付复制的数据对象将内容消耗与数据源分离，从而导致（1）内容访问和（2）内容分发失去控制。在像互联网这样分布广泛、分散的环境中，这带来了几个挑战。
One group of challenges is related to content management. Without access control, a content provider loses the means to count and survey content consumption, to limit access scopes, to control or know about the number of copies of its data in the network, or to withdraw earlier publications reliably. Any non-cooperative or desynchronized data cache may hinder an effective content management policy.
一组挑战与内容管理有关。如果没有访问控制，内容提供商将无法统计和调查内容消费、限制访问范围、控制或了解其在网络中的数据拷贝数，或可靠地收回早期出版物。任何不合作或不同步的数据缓存都可能妨碍有效的内容管理策略。
Another group of challenges arises from potential traffic amplifications in the decoupled environment. ICN solutions that attempt to retrieve content from several replicas in parallel, or decorrelated network routing states, but also distributed attackers may simultaneously initiate the transmission of content from multiple replicas towards the same destination (e.g., "initiated overloads" or "blockades" [BACKSCATTER]). Methods for mitigating such threats need rigorous forwarding checks that require alignment with caching procedures (e.g., on-path or off-path).
另一组挑战来自解耦环境中潜在的流量放大。ICN解决方案试图从多个副本中并行检索内容，或从不相关的网络路由状态中检索内容，但分布式攻击者也可能同时发起从多个副本向同一目的地传输内容（例如，“发起过载”或“封锁”[反向散射]）。缓解此类威胁的方法需要严格的转发检查，需要与缓存过程（例如，路径上或路径外）保持一致。
Content producers sign their content to ensure the integrity of data and to allow for data object authentication. This is a fundamental requirement in ICN due to distributed caching. Publishers, who massively sign content, which is long-lived, offer time and data to an attacker for comprising cryptographic credentials. Signing a large amount of data eases common attacks that try to breach the key of the publisher. Based on this observation, the following research challenges emerge:
内容生产者对其内容进行签名，以确保数据的完整性并允许数据对象身份验证。由于分布式缓存，这是ICN中的一个基本要求。发布者对长期存在的内容进行大量签名，为攻击者提供时间和数据，以构成加密凭据。对大量数据进行签名可以减轻试图破坏发布者密钥的常见攻击。根据这一观察，出现了以下研究挑战：
o To which extent does the content publication model conflict with the cryptographic limitations?
o 内容发布模型与加密限制的冲突程度如何？
o How can we achieve transparent re-signing without introducing additional cryptographic weaknesses or key management overhead?
o 我们如何在不引入额外加密弱点或密钥管理开销的情况下实现透明的重新签名？
In general, ICN implementations should be designed considering the guidelines provided by [RFC7696], especially regarding cryptographic algorithm agility, for example, [RFC6920] specifies a naming scheme for hash-based names that was designed to support algorithm agility.
通常，ICN实现的设计应考虑[RFC7696]提供的指南，尤其是关于加密算法敏捷性的指南，例如，[RFC6920]为基于哈希的名称指定了一个命名方案，该方案旨在支持算法敏捷性。
In information-centric networks, one attack vector is to increase the size of routing and forwarding information bases at ICN nodes, i.e., attacking routing scalability in networks that rely on routing by name. This is an intrinsic ICN security issue: possible mitigation approaches include combining routing information authenticity validation with filtering (e.g., maximum de-aggregation level whenever applicable, blacklists, etc.,).
在以信息为中心的网络中，一个攻击向量是增加在ICN节点上路由和转发信息的大小，即，攻击依赖于按名称路由的网络中的路由可扩展性。这是一个固有的ICN安全问题：可能的缓解方法包括将路由信息真实性验证与过滤相结合（例如，适用时的最大反聚合级别、黑名单等）。
ICN routing is a process that finds an NDO based on its name initially provided by a requestor. ICN routing may comprise three steps: (1) name resolution, (2) discovery, and (3) delivery. The name resolution step translates the name of the requested NDO into its locator. The discovery step routes the request to the data object based on its name or locator. The last step (delivery) routes the data object back to the requestor. Depending on how these steps are combined, ICN routing schemes can be categorized as Route-By-Name Routing (RBNR), Lookup-By-Name Routing (LBNR), and Hybrid Routing (HR) as discussed in the following subsections.
ICN路由是根据请求者最初提供的名称查找NDO的过程。ICN路由可包括三个步骤：（1）名称解析，（2）发现和（3）交付。名称解析步骤将请求的NDO的名称转换为其定位器。发现步骤根据数据对象的名称或定位器将请求路由到数据对象。最后一步（传递）将数据对象路由回请求者。根据这些步骤的组合方式，ICN路由方案可分为按名称路由（RBNR）、按名称查找路由（LBNR）和混合路由（HR），如下小节所述。
RBNR omits the first name resolution step as the name of the NDO is directly used to route the request to the data object. Therefore, routing information for each data object has to be maintained in the routing table. Since the number of data objects is very large (estimated as 10^11 back in 2007 [DONA], but this may be significantly larger than that, e.g., 10^15 to 10^22), the size of routing tables becomes a concern, as it can be proportional to the number of data objects unless an aggregation mechanism is introduced. On the other hand, RBNR reduces overall latency and simplifies the routing process due to the omission of the resolution process. For the delivery step, RBNR needs another identifier (ID) of either host or location to forward the requested data object back to the
RBNR省略了第一个名称解析步骤，因为NDO的名称直接用于将请求路由到数据对象。因此，必须在路由表中维护每个数据对象的路由信息。由于数据对象的数量非常大（2007年估计为10^11[DONA]，但这可能远远大于10^15到10^22），因此路由表的大小成为一个问题，因为除非引入聚合机制，否则它可能与数据对象的数量成比例。另一方面，由于省略了解析过程，RBNR减少了总体延迟并简化了路由过程。对于交付步骤，RBNR需要主机或位置的另一个标识符（ID）将请求的数据对象转发回服务器
requestor. Otherwise, an additional routing mechanism has to be introduced, such as breadcrumbs routing [BREADCRUMBS], in which each request leaves behind a trail of breadcrumbs along its forwarding path, and then the response is forwarded back to the requestor consuming the trail.
请求者。否则，必须引入额外的路由机制，例如breadcrumbs routing[breadcrumbs]，其中每个请求沿其转发路径留下一条breadcrumbs路径，然后将响应转发回使用该路径的请求者。
Challenges specific to RBNR include:
RBNR面临的具体挑战包括：
o How can we aggregate the names of data objects to reduce the number of routing entries?
o 我们如何聚合数据对象的名称以减少路由条目的数量？
o How does a user learn the name that is designed for aggregation by the provider? For example, although we name our contribution as "ICN research challenges", the IRTF (provider) may want to change the name to "/IETF/IRTF/ICN/Research challenges" for aggregation. In this case, how does a user learn the name "/IETF/IRTF/ICN/ Research challenges" to retrieve the contribution initially named "ICN research challenges" without any resolution process?
o 用户如何学习提供者为聚合而设计的名称？例如，尽管我们将我们的贡献命名为“ICN研究挑战”，但IRTF（提供商）可能希望将名称更改为“/IETF/IRTF/ICN/research challenges”以进行聚合。在这种情况下，用户如何学习名称“/IETF/IRTF/ICN/Research challenges”来检索最初命名为“ICN Research challenges”的贡献，而无需任何解析过程？
o Without introducing the name aggregation scheme, can we still achieve scalable routing by taking advantage of topological structure and distributed copies? For example, would employing compact routing [COMPACT], random walk [RANDOM], or greedy routing [GREEDY] work at the Internet scale?
o 在不引入名称聚合方案的情况下，我们能否利用拓扑结构和分布式副本实现可伸缩路由？例如，采用紧凑路由[compact]、随机游走[random]或贪婪路由[Grandy]在互联网规模上有效吗？
o How can we incorporate copies of a data object in in-network caches in this routing scheme?
o 在这种路由方案中，我们如何将数据对象的副本合并到网络缓存中？
o Breadcrumbs routing implies a symmetric path for ICN request and response delivery. Some network configurations and link types prohibit symmetric path forwarding, so it would be challenging to interconnect such networks to an infrastructure based on breadcrumbs routing. For example, certain forwarding strategies in Delay-Tolerant Networking (DTN) [RFC4838] are employing opportunistic forwarding where responses cannot be assumed to travel the same path as requests.
o 面包屑路由意味着ICN请求和响应传递的对称路径。某些网络配置和链路类型禁止对称路径转发，因此将此类网络互连到基于面包屑路由的基础设施将是一项挑战。例如，延迟容忍网络（DTN）[RFC4838]中的某些转发策略采用机会主义转发，其中不能假设响应与请求的路径相同。
LBNR uses the first name resolution step to translate the name of the requesting data object into its locator. Then, the second discovery step is carried out based on the locator. Since IP addresses could be used as locators, the discovery step can depend on the current IP infrastructure. The delivery step can be implemented similarly to IP routing. The locator of the requestor is included in the request message, and then the requested data object is delivered to the requestor based on the locator. An instantiation of LBNR is [MDHT].
LBNR使用第一个名称解析步骤将请求数据对象的名称转换为其定位器。然后，基于定位器执行第二发现步骤。由于IP地址可以用作定位器，因此发现步骤可能取决于当前的IP基础设施。交付步骤可以类似于IP路由来实现。请求者的定位器包括在请求消息中，然后基于定位器将请求的数据对象传递给请求者。LBNR的一个实例是[MDHT]。
Challenges specific to LBNR include:
LBNR面临的具体挑战包括：
o How can we build a scalable resolution system that provides:
o 我们如何构建可扩展的解决方案系统，以提供：
* Fast lookup: Mapping the name of a data object to its locators (copies as well).
* 快速查找：将数据对象的名称映射到其定位器（以及副本）。
* Fast update: The location of a data object is expected to change frequently. Also, multiple data objects may change their locations at the same time, e.g., data objects in a laptop.
* 快速更新：数据对象的位置预计会经常更改。此外，多个数据对象可能会同时更改其位置，例如笔记本电脑中的数据对象。
o How can we incorporate copies of a data object in in-network caches in this routing scheme?
o 在这种路由方案中，我们如何将数据对象的副本合并到网络缓存中？
HR combines RBNR and LBNR to benefit from their advantages. Within a single administrative domain, e.g., an ISP, where scalability issues can be addressed with network planning, RBNR can be adopted to reduce overall latency by omitting the resolution process. On the other hand, LBNR can be used to route between domains that have their own prefix (locator).
人力资源部将RBNR和LBNR结合在一起，从各自的优势中获益。在单个管理域（例如ISP）内，可通过网络规划解决可扩展性问题，可采用RBNR通过省略解决过程来减少总体延迟。另一方面，LBNR可用于在具有自己前缀（定位器）的域之间进行路由。
For instance, a request message initially includes the name of the NDO for the operation of RBNR and is forwarded to a cached copy of the NDO or the original server. When the request message fails to find a routing entry in the router, a name resolution step kicks in to translate the name into its locator before forwarding the request message based on the retrieved locator.
例如，请求消息最初包括用于RBNR操作的NDO的名称，并被转发到NDO的缓存副本或原始服务器。当请求消息在路由器中找不到路由条目时，将启动名称解析步骤，在根据检索到的定位器转发请求消息之前，将名称转换为其定位器。
Challenges specific to HR are:
人力资源面临的具体挑战包括：
o How can we design a scalable mapping system that, given the name of the NDO, should return a destination domain locator so that a user request can be encapsulated and forwarded to the domain?
o 我们如何设计一个可伸缩的映射系统，在给定NDO名称的情况下，该系统应该返回一个目标域定位器，以便可以封装用户请求并将其转发到域？
o How can the mapping information be secured to prevent a malicious router from hijacking the request message by chaining its locator?
o 如何保护映射信息以防止恶意路由器通过链接其定位器劫持请求消息？
o How can the bind between the name and the content of the NDO be maintained for the verification of its origin and integrity when the name changes due to the retrieved locator?
o 当名称因检索到的定位器而更改时，如何维护NDO名称和内容之间的绑定以验证其来源和完整性？
Mobility management has been an active field in host-centric communications for more than two decades. In IETF in particular, starting with [RFC2002], a multitude of enhancements to IP have been standardized aiming to "allow transparent routing of IP datagrams to mobile nodes in the Internet" [RFC5944]. In a nutshell, mobility management for IP networks is locator-oriented and relies on the concept of a mobility anchor as a foundation for providing always-on connectivity to mobile nodes (see [MMIN]). Other standards organizations, such as 3GPP, have followed similar anchor-based approaches. Traffic to and from the mobile node must flow through the mobility anchor, typically using a set of tunnels, enabling the mobile node to remain reachable while changing its point of attachment to the network.
二十多年来，移动性管理一直是以主机为中心的通信领域的一个活跃领域。特别是在IETF中，从[RFC2002]开始，对IP的大量增强已经标准化，旨在“允许IP数据报到Internet中的移动节点的透明路由”[RFC5944]。简而言之，IP网络的移动性管理是面向定位的，并且依赖于移动锚的概念作为提供始终连接到移动节点的基础（参见[MMI]）。其他标准组织，如3GPP，也采用了类似的基于锚的方法。进出移动节点的业务必须流经移动锚，通常使用一组隧道，使得移动节点在改变其与网络的连接点时保持可到达。
Needless to say, an IP network that supports node mobility is more complex than one that does not, as specialized network entities must be introduced in the network architecture. This is reflected in the control plane as well, which carries mobility-related signaling messages, establishes and tears down tunnels, and so on. While mobile connectivity was an afterthought in IP, in ICN, this is considered a primary deployment environment. Most, if not all, ICN proposals consider mobility from the very beginning, although at varying levels of architectural and protocol detail. That said, no solution has so far come forward with a definite answer on how to handle mobility in ICN using native primitives. In fact, we observe that mobility appears to be addressed on an ICN proposal-specific basis. That is, there is no single paradigm solution, akin to tunneling through a mobility anchor in host-centric networking, that can be applied across different ICN proposals. For instance, although widely deployed mobile network architectures typically come with their own network entities and associated protocols, they follow the same line of design with respect to managing mobility. This design thinking, which calls for incorporating mobility anchors, permeates in the ICN literature too.
不用说，支持节点移动性的IP网络比不支持节点移动性的IP网络更复杂，因为必须在网络体系结构中引入专门的网络实体。这也反映在控制平面上，控制平面承载与移动性相关的信令消息，建立并拆除隧道，等等。虽然移动连接在IP中是事后才想到的，但在ICN中，这被视为主要部署环境。大多数，如果不是全部，ICN建议从一开始就考虑移动性，虽然在不同层次的架构和协议细节。也就是说，到目前为止，还没有一个解决方案能够给出关于如何使用本机原语处理ICN中的移动性的明确答案。事实上，我们观察到，流动性似乎是在ICN提案的特定基础上解决的。也就是说，没有单一的范例解决方案可以应用于不同的ICN方案，类似于通过以主机为中心的网络中的移动性锚进行隧道传输。例如，尽管广泛部署的移动网络体系结构通常具有自己的网络实体和相关协议，但它们在管理移动性方面遵循相同的设计路线。这种设计思想也渗透在ICN文献中，要求整合移动性锚。
However, employing mobility anchors and tunneling is probably not the best way forward in ICN research for mobile networking. Fundamentally, this approach is anything but information-centric and location-independent. In addition, as argued in [SEEN], current mobility management schemes anchor information retrieval not only at a specific network gateway (e.g., home agent in Mobile IP) but also at a specific correspondent node due to the end-to-end nature of host-centric communication. However, once a change in the point of attachment occurs, information retrieval from the original "correspondent node" may no longer be optimal. This was shown in [MANI], for example, where a simple mechanism that triggers the
然而，在移动网络的ICN研究中，使用移动锚和隧道可能不是最好的方法。从根本上说，这种方法绝不是以信息为中心和位置无关的。此外，如[SEEN]所述，当前的移动性管理方案不仅在特定的网络网关（例如，移动IP中的归属代理）上锚定信息检索，而且由于以主机为中心的通信的端到端性质，也在特定的对应节点上锚定信息检索。然而，一旦连接点发生变化，从原始“对应节点”检索信息可能不再是最优的。例如，在[MANI]中显示了这一点，其中一个简单的机制触发
discovery of new retrieval providers for the same data object, following a change in the point of attachment, clearly outperforms a tunnel-based approach like Mobile IP in terms of object download times. The challenge here is how to capitalize on location information while facilitating the use of ICN primitives, which natively support multicast and anycast.
在连接点发生变化后，为同一数据对象发现新的检索提供者，在对象下载时间方面明显优于基于隧道的方法，如移动IP。这里的挑战是如何利用位置信息，同时促进ICN原语的使用，ICN原语本机支持多播和选播。
ICN naming and name resolution, as well as the security features that come along, should natively support mobility. For example, CCN [CCN] does not have the restriction of spanning tree routing, so it is able to take advantage of multiple interfaces or adapt to the changes produced by rapid mobility (i.e., there is no need to bind a layer 3 address with a layer 2 address). In fact, client mobility can be simplified by allowing requests for new content to normally flow from different interfaces or through newly connected points of attachment to the network. However, when the node moving is the (only) content source, it appears that more complex network support might be necessary, including forwarding updates and cache rebuilding. A case in point is a conversation network service, such as a voice or video call between two parties. The requirements in this case are more stringent when support for seamless mobility is required, especially when compared to content dissemination that is amenable to buffering. Another parameter that needs to be paid attention to is the impact of using different wireless access interfaces based on different technologies, where the performance and link conditions can vary widely depending of numerous factors.
ICN命名和名称解析，以及随之而来的安全特性，应该在本机上支持移动性。例如，CCN[CCN]没有生成树路由的限制，因此它能够利用多个接口或适应快速移动产生的变化（即，不需要将第3层地址与第2层地址绑定）。事实上，通过允许对新内容的请求通常从不同的接口或通过新连接到网络的连接点流动，可以简化客户端的移动性。但是，当移动的节点是（唯一）内容源时，似乎需要更复杂的网络支持，包括转发更新和缓存重建。这方面的一个例子是对话网络服务，例如双方之间的语音或视频通话。当需要支持无缝移动时，这种情况下的要求更为严格，特别是与易于缓冲的内容传播相比。另一个需要注意的参数是基于不同技术使用不同无线接入接口的影响，其中性能和链路条件可能因多种因素而大不相同。
In host-centric networking, mobility management mechanisms ensure optimal handovers and (ideally) seamless transition from one point of attachment to another. In ICN, however, the traditional meaning of "point of attachment" no longer applies as communication is not restrained by location-based access to data objects. Therefore, a "seamless transition" in ICN ensures that content reception continues without any perceptible change from the point of view of the ICN application receiving that content. Moreover, this transition needs to be executed in parallel with ICN content identification and delivery mechanisms, enabling scenarios such as preparation of the content delivery process at the target connectivity point prior to the handover (to reduce link switch disturbances). Finally, these mobility aspects can also be tightly coupled with network management aspects, in respect to policy enforcement, link control, and other parameters necessary for establishing the node's link to the network.
在以主机为中心的网络中，移动性管理机制确保最佳切换和（理想情况下）从一个连接点到另一个连接点的无缝过渡。然而，在ICN中，“连接点”的传统含义不再适用，因为通信不受基于位置的数据对象访问的限制。因此，ICN中的“无缝转换”确保从接收该内容的ICN应用程序的角度来看，内容接收继续而没有任何可感知的变化。此外，此转换需要与ICN内容识别和交付机制并行执行，以实现诸如在切换之前在目标连接点准备内容交付过程（以减少链路切换干扰）之类的场景。最后，在策略实施、链路控制和建立节点到网络的链路所需的其他参数方面，这些移动性方面还可以与网络管理方面紧密耦合。
In summary, the following research challenges for ICN mobility management can be derived:
综上所述，ICN移动性管理面临以下研究挑战：
o How can mobility management take full advantage of native ICN primitives?
o 移动性管理如何充分利用本机ICN原语？
o How do we avoid the need for mobility anchors in a network that by design supports multicast, anycast, and location-independent information retrieval?
o 我们如何避免在设计上支持多播、选播和位置无关信息检索的网络中需要移动锚？
o How can content retrieval mechanisms interface with specific link operations, such as identifying which links are available for certain content?
o 内容检索机制如何与特定链接操作交互，例如识别哪些链接可用于某些内容？
o How can mobility be offered as a service that is only activated when the specific user/content/conditions require it?
o 如何将移动性作为仅在特定用户/内容/条件需要时激活的服务提供？
o How can mobility management be coordinated between the node and the network for optimization and policing procedures?
o 如何在节点和网络之间协调移动性管理，以优化和监控程序？
o How do we ensure that managing mobility does not introduce scalability issues in ICN?
o 我们如何确保管理移动性不会在ICN中引入可伸缩性问题？
o How will the name resolution process be affected by rapid topological changes when the content source itself is mobile?
o 当内容源本身是移动的时，名称解析过程将如何受到快速拓扑变化的影响？
Today, all layer 2 (L2) wireless network radio access technologies are developed with a clear assumption in mind: the waist of the protocol stack is IP, and it will be so for the foreseeable future. By fixing the protocol stack waist, engineers can answer a large set of questions, including how to handle conversational traffic (e.g., voice calls) vs. web traffic, how to support multicast, and so on, in a rather straightforward manner. Broadcast, on the other hand, which is inherent in wireless communication, is not fully taken advantage of. On the contrary, researchers are often more concerned about introducing mechanisms that ensure that "broadcast storms" do not take down a network. The question of how can broadcast better serve ICN needs has yet to be thoroughly investigated.
今天，所有第2层（L2）无线网络无线接入技术的开发都有一个明确的假设：协议栈的腰部是IP，在可预见的未来也是如此。通过修复协议栈，工程师可以以一种相当简单的方式回答大量问题，包括如何处理会话通信（例如语音呼叫）与web通信，如何支持多播等。另一方面，无线通信固有的广播并没有得到充分利用。相反，研究人员通常更关心引入确保“广播风暴”不会摧毁网络的机制。广播如何更好地满足ICN需求的问题尚未得到彻底调查。
Wireless networking is often intertwined with mobility, but this is not always the case. In fact, empirical measurements often indicate that many users tend to connect (and remain connected) to a single Wi-Fi access point for considerable amounts of time. A case in point, which is frequently cited in different variations in the ICN literature, is access to a document repository during a meeting. For instance, in a typical IETF working group meeting, a scribe takes notes, which are uploaded to a centralized repository (see Figure 1). Subsequently, each meeting participant obtains a copy of the document on their own devices for local use, annotation, and sharing with colleagues that are not present at the meeting. Note that in this example, there is no node mobility and that it is not important
无线网络通常与移动性交织在一起，但情况并非总是如此。事实上，经验测量通常表明，许多用户倾向于在相当长的时间内连接（并保持连接）到单个Wi-Fi接入点。ICN文献的不同版本中经常引用的一个例子是在会议期间访问文档存储库。例如，在典型的IETF工作组会议上，抄写员记录笔记，并将笔记上传到集中存储库（见图1）。随后，每位会议参与者在自己的设备上获得一份文档副本，供本地使用、注释，并与未出席会议的同事共享。注意，在这个示例中，没有节点移动性，这并不重要
whether the document with the notes is uploaded in one go at the end of the session or in a streaming-like fashion as is typical today with online (cloud-based) document processing.
无论是在会话结束时一次性上传带有注释的文档，还是像今天在线（基于云的）文档处理一样以流式方式上传。
+---------------------+
| Document Repository |
+---------------------+
||
(Internet)
||
+--------------+
| Access Point |
+--------------+
/ | \
/ | \
/ | \
Scribe Participant 1 ... Participant N
+---------------------+
| Document Repository |
+---------------------+
||
(Internet)
||
+--------------+
| Access Point |
+--------------+
/ | \
/ | \
/ | \
Scribe Participant 1 ... Participant N
Figure 1: Document Sharing During a Meeting
图1：会议期间的文档共享
In this scenario, we observe that the same data object bits (corresponding to the meeting notes) need to traverse the wireless medium at least N+1 times, where N is the number of meeting participants obtaining a copy of the notes. In effect, a broadcast medium is shoehorned into N+1 virtual unicast channels. One could argue that wireless local connectivity is inexpensive, but this is not the critical factor in this example. The actual information exchange wastes N times the available network capacity, no matter what the spectral efficiency (or the economics) underlying the wireless technology is. This waste is a direct result of extending the remote access paradigm from wired to wireless communication, irrespective of the special characteristics of the latter.
在该场景中，我们观察到相同的数据对象位（对应于会议记录）需要至少穿越无线媒体N+1次，其中N是获得会议记录副本的会议参与者的数量。实际上，广播媒体被塞进N+1个虚拟单播频道。有人可能会说无线本地连接是便宜的，但这不是本例中的关键因素。无论无线技术的频谱效率（或经济性）如何，实际的信息交换浪费了可用网络容量的N倍。这种浪费是将远程访问模式从有线通信扩展到无线通信的直接结果，而不管无线通信的特殊特性如何。
It goes without saying that an ICN approach that does not take into consideration the wireless nature of an interface will waste the same amount of resources as a host-centric paradigm. In-network caching at the wireless access point could reduce the amount of data carried over the backhaul link, but, if there is no change in the use of the wireless medium, the NDO will still be carried over the wireless ether N+1 times. Intelligent caching strategies, replica placement cooperation, and so on simply cannot alleviate this. On the other hand, promiscuous interface operation and opportunistic caching would maximize wireless network capacity utilization in this example.
不用说，不考虑接口无线特性的ICN方法将浪费与以主机为中心模式相同的资源量。无线接入点处的In-network高速缓存可以减少通过回程链路携带的数据量，但是，如果无线介质的使用没有改变，则NDO仍将通过无线以太网携带N+1次。智能缓存策略、副本放置协作等都无法缓解这一问题。另一方面，在本例中，混杂的接口操作和机会主义缓存将最大限度地提高无线网络容量利用率。
Arguably, if one designs a future wireless access technology with an information-centric "layer 3" in mind, many of the design choices that are obvious in an all-IP architecture may no longer be valid.
可以说，如果设计未来的无线接入技术时考虑到以信息为中心的“第3层”，那么在全IP架构中显而易见的许多设计选择可能不再有效。
Although this is clearly outside the scope of this document, a few research challenges that the wider community may be interested in include:
尽管这显然超出了本文件的范围，但更广泛的社区可能感兴趣的一些研究挑战包括：
o Can we use wireless resources more frugally with the information-centric paradigm than what is possible today in all-IP wireless networks?
o 在以信息为中心的模式下，我们能否比现在在所有IP无线网络中更节约地使用无线资源？
o In the context of wireless access, how can we leverage the broadcast nature of the medium in an information-centric network?
o 在无线接入的背景下，我们如何在以信息为中心的网络中利用媒体的广播特性？
o Would a wireless-oriented ICN protocol stack deliver significant performance gains? How different would it be from a wired-oriented ICN protocol stack?
o 面向无线的ICN协议栈会带来显著的性能提升吗？它与有线定向ICN协议栈有多大区别？
o Is it possible that by changing the network paradigm to ICN we can, in practice, increase the spectral efficiency (bits/s/Hz) of a wireless network beyond what would be possible with today's host-centric approaches? What would be the impact of doing so with respect to energy consumption?
o 通过将网络模式更改为ICN，我们是否可以在实践中提高无线网络的频谱效率（比特/秒/赫兹），使其超越当今以主机为中心的方法？这样做对能源消耗有什么影响？
o Can promiscuous wireless interface operation coupled with opportunistic caching increase ICN performance, and if so, by how much?
o 杂乱无章的无线接口操作加上机会主义缓存能否提高ICN性能，如果是，能提高多少？
o How can a conversational service be supported at least as efficiently as today's state-of-the-art wireless networks deliver?
o 如何至少像当今最先进的无线网络所提供的那样有效地支持会话服务？
o What are the benefits of combining ICN with network coding in wireless networks?
o 在无线网络中将ICN与网络编码相结合有什么好处？
o How can Multiple-Input Multiple-Output (MIMO) and Coordinated Multipoint Transmission (CoMP) be natively combined with ICN primitives in future cellular networks?
o 在未来的蜂窝网络中，多输入多输出（MIMO）和协调多点传输（CoMP）如何与ICN原语在本地结合？
ICN's receiver-driven communication model as described above creates new opportunities for transport protocol design, as it does not rely solely on end-to-end communication from a sender to a requestor. A requested data object can be accessible in multiple different network locations. A node can thus decide how to utilize multiple sources, e.g., by sending parallel requests for the same NDO or by switching sources (or next hops) in a suitable schedule for a series of requests.
如上所述，ICN的接收器驱动通信模型为传输协议设计创造了新的机会，因为它不完全依赖从发送方到请求方的端到端通信。可以在多个不同的网络位置访问请求的数据对象。因此，节点可以决定如何利用多个源，例如，通过为相同的NDO发送并行请求，或者通过为一系列请求以合适的时间表切换源（或下一跳）。
In this model, the requestor would control the data rate by regulating its request sending rate and next by performing source/ next-hop selections. Specific challenges depend on the specific ICN approach, but general challenges for receiver-driven transport protocols (or mechanisms, since dedicated protocols might not be required) include flow and congestion control, fairness, network utilization, stability (of data rates under stable conditions), etc. [HRICP] and [CONTUG] describe request rate control protocols and corresponding design challenges.
在该模型中，请求者将通过调节其请求发送速率来控制数据速率，并通过执行源/下一跳选择来控制下一跳。具体挑战取决于具体的ICN方法，但接收器驱动传输协议（或机制，因为可能不需要专用协议）的一般挑战包括流量和拥塞控制、公平性、网络利用率、稳定性（稳定条件下的数据速率）等[HRICP]和[CONTUG]描述请求速率控制协议和相应的设计挑战。
As mentioned above, the ICN communication paradigm does not depend strictly on end-to-end flows, as contents might be received from in-network caches. The traditional concept of a flow is then somewhat not valid as sub-flows, or flowlets, might be formed on the fly, when fractions of an NDO are transmitted from in-network caches. For a transport-layer protocol, this is challenging, as any measurement related to this flow as traditionally done by transport protocols such as TCP, can often prove misleading. For example, false Round-Trip Time (RTT) measurements will lead to largely variable average and smoothed RTT values, which in turn will trigger false timeout expirations.
如上所述，ICN通信范式并不严格依赖于端到端流，因为内容可能从网络缓存中接收。因此，流的传统概念在某种程度上是无效的，因为当NDO的一部分从网络缓存中传输时，可能会动态形成子流或小流。对于传输层协议来说，这是一个挑战，因为传统上由传输协议（如TCP）进行的与此流相关的任何测量都可能被证明具有误导性。例如，错误的往返时间（RTT）测量将导致很大程度上可变的平均和平滑RTT值，这反过来将触发错误的超时过期。
Furthermore, out-of-order delivery is expected to be common in a scenario where parts of a data object are retrieved from in-network caches rather than from the origin server. Several techniques for dealing with out-of-order delivery have been proposed in the past for TCP, some of which could potentially be modified and reused in the context of ICN. Further research is needed in this direction though to choose the right technique and adjust it according to the requirements of the ICN architecture and transport protocol in use.
此外，在从网络缓存中而不是从源服务器检索数据对象的部分的情况下，无序交付预计是常见的。过去已经针对TCP提出了几种处理无序交付的技术，其中一些技术可能会在ICN环境中被修改和重用。尽管需要根据ICN体系结构和使用的传输协议的要求选择合适的技术并对其进行调整，但在这方面还需要进一步的研究。
ICN offers routers the possibility to aggregate requests and can use several paths, meaning that there is no such thing as a (dedicated) end-to-end communication path, e.g., a router that receives two requests for the same content at the same time only sends one request to its neighbor. The aggregation of requests has a general impact on transport protocol design and offers new options for employing per-node forwarding strategies and for rethinking in-network resource sharing [RESOURCE-POOL].
ICN为路由器提供了聚合请求的可能性，并且可以使用多条路径，这意味着不存在（专用）端到端通信路径，例如，路由器在同一时间接收相同内容的两个请求，只向其邻居发送一个请求。请求的聚合对传输协议设计有着普遍的影响，并为采用每节点转发策略和重新思考网络资源共享[resource-POOL]提供了新的选择。
Achieving fairness for requestors can be one challenge as it is not possible to identify the number of requestors behind one particular request. A second problem related to request aggregation is the management of request retransmissions. Generally, it is assumed that a router will not transmit a request if it transmitted an identical request recently, and because there is no information about the requestor, the router cannot distinguish the initial request from a
实现请求者的公平性可能是一个挑战，因为不可能确定一个特定请求背后的请求者数量。与请求聚合相关的第二个问题是请求重传的管理。通常，假设路由器在最近发送了相同的请求时不会发送请求，并且由于没有关于请求者的信息，路由器无法区分初始请求和请求
client from a retransmission from the same client. In such a situation, routers can adapt their timers to use the best of the communication paths.
来自同一客户端的重新传输的客户端。在这种情况下，路由器可以调整其计时器以使用最佳通信路径。
Explicitly named data objects allow for caching at virtually any network element, including routers, proxy caches, and end-user devices. Therefore, in-network caching can improve network performance by fetching content from nodes that are geographically placed closer to the end user. Several issues that need further investigation have been identified with respect to in-network caching. In this section, we list important challenges that relate to the properties of the new ubiquitous caching system.
显式命名的数据对象允许在几乎任何网络元素上进行缓存，包括路由器、代理缓存和最终用户设备。因此，网络内缓存可以通过从地理位置更靠近最终用户的节点获取内容来提高网络性能。在网络缓存方面，已经确定了几个需要进一步研究的问题。在本节中，我们列出了与新的无处不在的缓存系统的属性相关的重要挑战。
The declining cost of fast memory gives the opportunity to deploy caches in network routers and to take advantage of cached NDOs. We identify two approaches to in-network caching, namely, on-path and off-path caching. Both approaches have to consider the issue of cache location. Off-path caching is similar to traditional proxy-caching or CDN server placement. Retrieval of contents from off-path caches requires redirection of requests and, therefore, is closely related to the Request-to-Cache Routing problem discussed below. Off-path caches have to be placed in strategic points within a network in order to reduce the redirection delays and the number of detour hops to retrieve cached contents. Previous research on proxy-caching and CDN deployment is helpful in this case.
快速内存成本的下降为在网络路由器中部署缓存和利用缓存的NDO提供了机会。我们确定了两种实现网络内缓存的方法，即路径上缓存和路径外缓存。这两种方法都必须考虑缓存位置的问题。非路径缓存类似于传统的代理缓存或CDN服务器放置。从非路径缓存检索内容需要重定向请求，因此与下面讨论的请求到缓存路由问题密切相关。非路径缓存必须放置在网络中的战略点上，以减少重定向延迟和检索缓存内容的迂回跳数。以前关于代理缓存和CDN部署的研究在这种情况下很有帮助。
On the other hand, on-path caching requires less network intervention and fits more neatly in ICN. However, on-path caching requires line-speed operation, which places more constraints on the design and operation of in-network caching elements. Furthermore, the gain of such a system of on-path in-network caches relies on opportunistic cache hits and has therefore been considered of limited benefit, given the huge amount of contents hosted in the Internet. For this reason, network operators might initially consider only a limited number of network elements to be upgraded to in-network caching elements. The decision on which nodes should be equipped with caches is an open issue and might be based, among others, on topological criteria or traffic characteristics. These challenges relate to both the Content Placement problem and the Request-to-Cache Routing problem discussed below.
另一方面，路径缓存需要更少的网络干预，更适合ICN。但是，路径缓存需要线速操作，这对网络缓存元素的设计和操作造成了更多限制。此外，这种网络缓存路径上的系统的收益依赖于机会主义缓存命中，因此，考虑到互联网上承载的大量内容，其收益被认为是有限的。出于这个原因，网络运营商可能最初只考虑将有限数量的网络元素升级到网络缓存元素中。关于哪些节点应该配备缓存的决定是一个公开的问题，除其他外，可能基于拓扑标准或流量特征。这些挑战涉及内容放置问题和下面讨论的请求缓存路由问题。
In most cases, however, the driver for the implementation, deployment, and operation of in-network caches will be its cost. Operating caches at line speed inevitably requires faster memory,
然而，在大多数情况下，网络内缓存的实现、部署和操作的驱动因素是其成本。以线路速度运行缓存不可避免地需要更快的内存，
which increases the implementation cost. Based on the capital to be invested, ISPs will need to make strategic decisions on the cache placement, which can be driven by several factors, such as avoidance of inter-domain/expensive links, centrality of nodes, size of domain and the corresponding spatial locality of users, and traffic patterns in a specific part of the network (e.g., university vs. business vs. fashion district of a city).
这增加了实施成本。基于投资的资本，ISP将需要对缓存位置做出战略决策，这可能由多个因素驱动，例如避免域间/昂贵的链接、节点的中心性、域的大小和用户的相应空间位置，以及网络特定部分的流量模式（例如，大学vs.商业vs.城市时尚区）。
Given a number of on-path or off-path in-network caching elements, content-to-cache distribution will affect both the dynamics of the system, in terms of request redirections (mainly in case of off-path caches) and the gain of the system in terms of cache hits. A straightforward approach to content placement is on-path placement of contents as they travel from source to destination. This approach reduces the computation and communication overhead of placing content within the network but, on the other hand, might reduce the chances of hitting cached contents. This relates to the Request-to-Cache Routing problem discussed next.
给定网络缓存元素中的许多路径上或路径外元素，缓存内容分发将影响系统的动态，包括请求重定向（主要是在路径外缓存的情况下）和系统在缓存命中率方面的增益。一种简单的内容放置方法是在内容从源到目标的过程中沿路径放置内容。这种方法减少了在网络中放置内容的计算和通信开销，但另一方面，可能会减少命中缓存内容的机会。这与下面讨论的请求到缓存路由问题有关。
Furthermore, the number of replicas held in the system brings up resource management issues in terms of cache allocation. For example, continuously replicating data objects in all network elements results in redundant copies of the same objects. The issue of redundant replication has been investigated in the past for hierarchical web caches. However, in hierarchical web-caching, overlay systems coordination between the data and the control plane can guarantee increased performance in terms of cache hits. Line-speed, on-path, in-network caching poses different requirements; therefore, new techniques need to be investigated. In this direction, reducing the redundancy of cached copies is a study item. However, the issue of coordinated content placement in on-path caches remains open.
此外，系统中保存的副本数量会带来缓存分配方面的资源管理问题。例如，在所有网元中连续复制数据对象会导致相同对象的冗余副本。对于分层web缓存，过去已经研究过冗余复制问题。但是，在分层web缓存中，数据和控制平面之间的覆盖系统协调可以保证在缓存命中率方面提高性能。线路速度、路径、网络缓存提出了不同的要求；因此，需要研究新技术。在这个方向上，减少缓存副本的冗余是一个研究项目。但是，在路径缓存中协调内容放置的问题仍然存在。
The Content-to-Cache Allocation problem relates also to the characteristics of the content to be cached. Popular content might need to be placed where it is going to be requested next. Furthermore, issues of "expected content popularity" or temporal locality need to be taken into account in designing in-network caching algorithms in order for some contents to be given priority (e.g., popular content vs. one-timers). The criteria as to which contents should be given priority in in-network content caches relates also to the business relationships between content providers and network operators. Business model issues will drive some of these decisions on content-to-cache distribution, but such issues are outside the scope of this note and are not discussed here further.
内容到缓存的分配问题还与要缓存的内容的特征有关。流行内容可能需要放在下一步需要的地方。此外，在设计网络缓存算法时，需要考虑“预期内容流行度”或时间局部性的问题，以便优先考虑某些内容（例如，流行内容与一次性内容）。网络内容缓存中应优先考虑哪些内容的标准还涉及内容提供商和网络运营商之间的业务关系。业务模型问题将推动其中一些关于内容到缓存分发的决策，但这些问题超出了本说明的范围，在此不再进一步讨论。
In order to take advantage of cached contents, requests have to be forwarded to the nodes that cache the corresponding contents. This challenge relates to name-based routing, discussed earlier. Requests should ideally follow the path to the cached NDO. However, instructions as to which content is cached where cannot be broadcast throughout the network. Therefore, the knowledge of an NDO location at the time of the request either might not exist or might not be accurate (i.e., contents might have been removed by the time a request is redirected to a specific node).
为了利用缓存的内容，必须将请求转发到缓存相应内容的节点。这个挑战与前面讨论的基于名称的路由有关。理想情况下，请求应该沿着缓存NDO的路径进行。但是，关于哪些内容缓存在哪里的指令不能在整个网络中广播。因此，在请求时对NDO位置的了解可能不存在或可能不准确（即，在请求重定向到特定节点时内容可能已被删除）。
Coordination between the data and the control planes to update information of cached contents has been considered, but in this case, scalability issues arise. We therefore have two options. We either have to rely on opportunistic caching, where requests are forwarded to a server and in case the NDO is found on the path, then the content is fetched from this node instead of the origin server, or we employ cache-aware routing techniques. Cache-aware routing can involve either both the control and the data plane or only one of them. Furthermore, cache-aware routing can be done in a domain-wide scale or can involve more than one individual Autonomous System (AS). In the latter case, business relationships between ASes might need to be exploited in order to build a scalable model.
已经考虑了数据和控制平面之间的协调以更新缓存内容的信息，但是在这种情况下，会出现可伸缩性问题。因此，我们有两个选择。我们要么依赖机会缓存，将请求转发到服务器，如果在路径上找到NDO，则从该节点而不是源服务器获取内容，要么采用缓存感知路由技术。缓存感知路由可以同时涉及控件和数据平面，也可以只涉及其中一个。此外，缓存感知路由可以在域范围内完成，也可以涉及多个单独的自治系统（AS）。在后一种情况下，可能需要利用ASE之间的业务关系来构建可伸缩模型。
Due to the largely distributed copies of NDOs in in-network caches, ICN should be able to provide a staleness verification algorithm that provides synchronization of NDOs located at their providers and in-network caching points. Two types of approaches can be considered for this problem, namely direct and indirect approaches.
由于网络缓存中的NDO副本分布广泛，ICN应该能够提供一种过时验证算法，该算法可以同步位于其提供者和网络缓存点中的NDO。对于这个问题，可以考虑两种方法，即直接方法和间接方法。
In the direct approach, each cache looks up certain information in the NDO's name, e.g., the timestamp, that directly indicates its staleness. This approach is applicable to some NDOs that come from machine-to-machine and Internet of Things scenarios, whose base operation relies on obtaining the latest version of that NDO (i.e., a soil sensor in a farm providing different continuous parameters that are sent to a display or greenhouse regulation system) [FRESHNESS].
在直接方法中，每个缓存在NDO的名称中查找某些信息，例如，时间戳，这些信息直接指示其过时性。该方法适用于一些来自机器对机器和物联网场景的NDO，其基本操作依赖于获取该NDO的最新版本（即，农场中的土壤传感器，提供不同的连续参数，发送至显示器或温室调节系统）[新鲜度]。
In the indirect approach, each cache consults the publisher of the cached NDO about its staleness before serving it. This approach assumes that the NDO includes the publisher information, which can be used to reach the publisher. It is suitable for the NDO whose expiration time is difficult to be set in advance, e.g., a web page
在间接方法中，每个缓存在提供服务之前都会向缓存的NDO的发布者咨询其过时性。这种方法假设NDO包含发布者信息，这些信息可用于访问发布者。它适用于到期时间难以预先设置的NDO，例如网页
that contains the main text (which stays the same ever after) and the interactive sections such as comments or ads (which are updated irregularly).
包含主文本（此后保持不变）和交互部分，如评论或广告（不定期更新）。
It is often argued that ignoring stale NDOs in caches and simply providing new names for updated NDOs might be sufficient rather than using a staleness verification algorithm to manage them. However, notifying the new names of updated NDOs to users is not a trivial task. Unless the update is informed to all users at the same time, some users would use the old name although they intended to retrieve the updated NDO.
人们经常认为，忽略缓存中的过时NDO并简单地为更新的NDO提供新名称可能就足够了，而不是使用过时验证算法来管理它们。但是，向用户通知更新的NDO的新名称并不是一项简单的任务。除非同时通知所有用户更新，否则一些用户将使用旧名称，尽管他们打算检索更新的NDO。
One research challenge is how to design consistency and coherence models for caching NDOs along with their revision handling and updating protocols in a scalable manner.
一个研究挑战是如何以可伸缩的方式设计缓存NDO的一致性和一致性模型以及它们的修订处理和更新协议。
When ICN is deployed as a general, application-independent network and cache infrastructure, multiple consumers and producers (representing different applications) would communicate over the same infrastructure. With universal naming schemes or sufficiently unique hash-based identifiers, different application could also share identical NDOs in a transparent way.
当ICN部署为通用的、独立于应用程序的网络和缓存基础设施时，多个使用者和生产者（代表不同的应用程序）将通过同一基础设施进行通信。使用通用命名方案或充分唯一的基于散列的标识符，不同的应用程序也可以以透明的方式共享相同的NDO。
Depending on the naming, data integrity, and data origin authentication approaches, there may be technical and business challenges to share caches across different applications, for example, content protection, avoiding cache poisoning, ensuring performance isolation, etc. As ICN research matures, these challenges should be addressed more specifically in a dedicated document.
根据命名、数据完整性和数据源身份验证方法，在不同应用程序之间共享缓存可能存在技术和业务挑战，例如，内容保护、避免缓存中毒、确保性能隔离等。随着ICN研究的成熟，应在一份专门文件中更具体地解决这些挑战。
Managing networks has been a core craft in the IP-based host-centric paradigm ever since the technology was introduced in production networks. However, at the onset of IP, management was considered primarily as an add-on. Essential tools that are used daily by networkers, such as ping and traceroute, did not become widely available until more than a decade or so after IP was first introduced. Management protocols, such as SNMP, also became available much later than the original introduction of IP, and many still consider them insufficient despite the years of experience we have running host-centric networks. Today, when new networks are deployed, network management is considered a key aspect for any operator, a major challenge that is directly reflected in higher operational cost if not done well. If we want ICN to be deployed in
自该技术引入生产网络以来，管理网络一直是基于IP的以主机为中心的范例中的核心技术。然而，在IP开始时，管理主要被视为一种附加功能。网络工作者每天使用的基本工具，如ping和traceroute，直到IP首次引入十多年后才被广泛使用。管理协议，如SNMP，也比IP引入的时间晚得多，尽管我们已经运行了以主机为中心的网络，但许多人仍然认为它们不够。今天，当部署新网络时，网络管理被认为是任何运营商的一个关键方面，这是一个重大挑战，如果做得不好，直接反映在更高的运营成本上。如果我们希望ICN部署在
infrastructure networks, development of management tools and mechanisms must go hand in hand with the rest of the architecture design.
基础设施网络、管理工具和机制的开发必须与架构设计的其余部分齐头并进。
Although defining an FCAPS (Fault, Configuration, Accounting, Performance, and Security) [ISOIEC-7498-4] management model for ICN is clearly outside the scope of this document, there is a need for creating basic tools early on while ICN is still in the design and experimentation phases that can evolve over time and help network operations centers (NOCs) to define policies, validate that they are indeed used in practice, be notified early on about failures, and determine and resolve configuration problems. Authentication, Authorization, and Accounting (AAA) as well as performance management, from a NOC perspective, will also need to be considered. Given the expectations for a large number of nodes and unprecedented traffic volumes, automating tasks or even better employing self-management mechanisms are preferred. The main challenge here is that all tools we have at our disposal today are node-centric, are end-to-end oriented, or assume a packet-stream communication environment. Rethinking reachability and operational availability, for example, can yield significant insights into how information-centric networks will be managed in the future.
尽管为ICN定义FCAPS（故障、配置、计费、性能和安全）[ISOIEC-7498-4]管理模型显然不在本文件的范围内，但在ICN仍处于设计和实验阶段时，需要尽早创建基本工具，这些阶段可以随时间发展，并帮助网络运营中心（NOC）定义策略，验证它们是否确实在实践中使用，在出现故障时尽早得到通知，并确定和解决配置问题。身份验证、授权和记帐（AAA）从国家奥委会的角度来看，还需要考虑性能管理。考虑到对大量节点和前所未有的通信量的期望，自动化任务或更好地使用自我管理机制是首选。这里的主要挑战是，我们现在拥有的所有工具都是节点中心例如，重新思考可达性和操作可用性可以对未来如何管理以信息为中心的网络产生重要的见解。
With respect to network management, we see three different aspects. First, any operator needs to manage all resources available in the network, which can range from node connectivity to network bandwidth availability to in-network storage to multi-access support. In ICN, users will also bring into the network significant resources in terms of network coverage extension, storage, and processing capabilities. Delay Tolerant Networking (DTN) characteristics should also be considered to the degree that this is possible (e.g., content dissemination through data mules). Second, given that nodes and links are not at the center of an information-centric network, network management should capitalize on native ICN mechanisms. For example, in-network storage and name resolution can be used for monitoring, while native publish/subscribe functionality can be used for triggering notifications. Finally, management is also at the core of network-controlling capabilities by allowing operating actions to be mediated and decided, triggering and activating networking procedures in an optimized way. For example, monitoring aspects can be conjugated with different management actions in a coordinated way, allowing network operations to flow in a concerted manner.
关于网络管理，我们看到三个不同的方面。首先，任何运营商都需要管理网络中的所有可用资源，包括节点连接、网络带宽可用性、网络内存储和多址支持。在ICN中，用户还将在网络覆盖范围扩展、存储和处理能力方面为网络带来大量资源。还应将容错网络（DTN）特性考虑到可能的程度（例如，通过数据MULE进行内容传播）。其次，鉴于节点和链路不在以信息为中心的网络的中心，网络管理应利用本机ICN机制。例如，网络存储和名称解析可用于监视，而本机发布/订阅功能可用于触发通知。最后，管理也是网络控制能力的核心，它允许对操作行为进行调解和决定，以优化的方式触发和激活网络程序。例如，监控方面可以以协调的方式与不同的管理行动结合，从而允许网络操作以协调的方式流动。
However, the considerations on leveraging intrinsic ICN mechanisms and capabilities to support management operations go beyond a simple mapping exercise. In fact, it not only raises a series of challenges on its own, but also opens up new possibilities for both ICN and
然而，利用内部ICN机制和功能来支持管理操作的考虑因素超出了简单的映射练习。事实上，它不仅本身提出了一系列挑战，而且为ICN和ICN开辟了新的可能性
"network management" as a concept. For instance, naming mechanisms are central to ICN-intrinsic operations, which are used to identify and reach content under different aspects (e.g., hierarchically structured vs. "flattish" names). In this way, ICN is decoupled from host-centric aspects on which traditional network management schemes rely. As such, questions are raised that can directly be translated into challenges for network management capability, such as, for example, how to address a node or a network segment in an ICN naming paradigm, how to identify which node is connected "where", how to be aware of the node capabilities (i.e., high or low-powered machine-to-machine (M2M) node), and if there is a host-centric protocol running where the management process can also leverage.
“网络管理”作为一个概念。例如，命名机制是ICN内部操作的核心，用于识别和访问不同方面的内容（例如，层次结构与“扁平化”名称）。通过这种方式，ICN与传统网络管理方案所依赖的以主机为中心的方面解耦。因此，提出的问题可直接转化为网络管理能力的挑战，例如，如何在ICN命名范式中寻址节点或网段，如何识别哪个节点连接在“何处”，如何了解节点能力（即，高功率或低功率机器对机器（M2M））节点），并且如果有一个以主机为中心的协议正在运行，管理过程也可以利用该协议。
But, on the other hand, these same inherent ICN characteristics also allow us to look into network management through a new perspective. By centering its operations around NDOs, one can conceive new management operations addressing, for example, per-content management or access control, as well as analyzing performance per NDO instead of per link or node. Moreover, such considerations can also be used to manage operational aspects of ICN mechanisms themselves. For example, [NDN-MGMT] reutilizes inherent content-centric capabilities of CCN to manage optimal link connectivity for nodes, in concert with a network optimization process. Conversely, how these content-centric aspects can otherwise influence and impact management in other areas (e.g., security and resilience) is also important, as exemplified in [CCN-ACCESS], where access control mechanisms are integrated into a prototype of the [PURSUIT] architecture.
但是，另一方面，这些相同的固有ICN特性也允许我们从一个新的角度来研究网络管理。通过将其操作集中于NDO，可以设想新的管理操作，例如，针对每个内容管理或访问控制，以及分析每个NDO而不是每个链接或节点的性能。此外，这些考虑也可用于管理ICN机制本身的运作方面。例如，[NDN-MGMT]结合网络优化过程，重新利用CCN固有的以内容为中心的功能来管理节点的最佳链路连接。相反，这些以内容为中心的方面如何以其他方式影响和影响其他领域的管理（例如，安全性和恢复力）也很重要，如[CCN-ACCESS]所示，在[CCN-ACCESS]中，访问控制机制被集成到[PURSUIT]体系结构的原型中。
The set of core research challenges for ICN management includes:
ICN管理的一系列核心研究挑战包括：
o Management and control of NDO reception at the requestor
o 请求方NDO接收的管理和控制
o Coordination of management information exchange and control between ICN nodes and ICN network control points
o 协调ICN节点和ICN网络控制点之间的管理信息交换和控制
o Identification of management and controlling actions and items through information naming
o 通过信息命名识别管理和控制措施和项目
o Relationship between NDOs and host entities identification, i.e., how to identify a particular link, interface, or flow that needs to be managed
o NDO和主机实体标识之间的关系，即如何标识需要管理的特定链路、接口或流
ICN can be applied to different application domains and is expected to provide benefits for application developers by providing a more suitable interface for application developers (in addition to the
ICN可应用于不同的应用领域，并有望通过为应用程序开发人员提供更合适的接口（除了
other ICN benefits described above). [RFC7476] provides an overview of relevant application domains at large. This section discusses opportunities and challenges for selected application types.
上述其他ICN好处）。[RFC7476]概括介绍了相关的应用程序域。本节讨论选定应用程序类型的机遇和挑战。
Intuitively, the ICN request/response communication style seems to be directly mappable to web communication over HTTP. NDO names could be the equivalent of URIs in today's web, proprietary and transparent caching could be obsoleted by ICN in-network caching, and developers could directly use an ICN request/response API to build applications.
直观地说，ICN请求/响应通信风格似乎可以直接映射到HTTP上的web通信。NDO名称可能相当于当今web中的URI，专有和透明缓存可能会被网络缓存中的ICN淘汰，开发人员可以直接使用ICN请求/响应API构建应用程序。
Research efforts such as [ICN2014-WEB-NDN] have analyzed real-world web applications and ways to implement them in ICN. The most significant insight is that REST-style (Representational State Transfer) web communication relies heavily on transmitting user/ application context information in HTTP GET requests, which would have to be mapped to corresponding ICN messages. The challenge in ICN would be how to exactly achieve that mapping. This could be done to some degree by extending name formats or by extending message structure to include cookies and similar context information. The design decisions would need to consider overhead in routers (for example, if larger GET/Interest messages would have to be stored in corresponding tables on routers).
像[ICN2014-WEB-NDN]这样的研究工作分析了现实世界中的WEB应用程序以及在ICN中实现它们的方法。最重要的洞察是REST风格（代表性状态转移）web通信严重依赖于在HTTP GET请求中传输用户/应用程序上下文信息，这些信息必须映射到相应的ICN消息。ICN面临的挑战是如何准确地实现这种映射。在某种程度上，这可以通过扩展名称格式或扩展消息结构来实现，以包括cookie和类似的上下文信息。设计决策需要考虑路由器中的开销（例如，如果较大的GET /兴趣消息必须存储在路由器上的相应表中）。
Other challenges include the ability to return different results based on requestor-specific processing in the presence of immutable objects (and name-object bindings) in ICN and the ability for efficient bidirectional communication, which would require some mechanism to name and reach requestor applications.
其他挑战包括在ICN中存在不可变对象（和名称对象绑定）的情况下，基于特定于请求者的处理返回不同结果的能力，以及高效双向通信的能力，这需要某种机制来命名和访问请求者应用程序。
One of ICN's prime application areas is video streaming and download where accessing named data, object-level security, and in-network storage can fulfill requirements for both video streaming and download. The applicability and benefits of ICN to video has been demonstrated by several prototype developments [ICN2014-AHLGREN-VIDEO-DEMO].
ICN的主要应用领域之一是视频流和下载，其中访问命名数据、对象级安全和网络存储可以满足视频流和下载的要求。ICN对视频的适用性和好处已通过几个原型开发得到证明[ICN2014-AHLGREN-video-DEMO]。
[VIDEO-STREAMING] discusses the opportunities and challenges of implementing today's video services such as DASH-based (Dynamic Adaptive Streaming over HTTP) streaming and download over ICN, considering performance requirements, relationship to peer-to-peer live streaming, IPTV, and Digital Rights Management (DRM).
[VIDEO-STREAMING]从性能要求、与点对点实时流媒体、IPTV和数字版权管理（DRM）的关系等方面讨论了实施基于DASH（HTTP上的动态自适应流媒体）的流媒体和ICN上的下载等当今视频服务的机遇和挑战。
In addition to just porting today's video application from a host-centric paradigm to ICN, there are also promising opportunities to leverage the ICN network services for redesigning and thus significantly enhancing video access and distribution [ICNRG-2015-01-WESTPHAL]. For example, ICN store and forward could be leveraged for rate adaptation to achieve maximum throughput and optimal Quality of Experience (QoE) in scenarios with varying link properties, if capacity information is fed back to rate selection algorithms at senders. Other optimizations such as more aggressive prefetching could be performed in the network by leveraging visibility of chunk NDO names and NDO metadata in the network. Moreover, multi-source rate adaptation in combination with network coding could enable better QoE, for example, in multi-interface/ access scenarios where multiple paths from client to upstream caches exist [RFC7476].
除了将当今的视频应用程序从以主机为中心的模式移植到ICN之外，还存在利用ICN网络服务进行重新设计从而显著增强视频访问和分发的良好机会[ICNRG-2015-01-WESTPHAL]。例如，如果将容量信息反馈给发送方的速率选择算法，则可以利用ICN存储转发进行速率自适应，以在具有不同链路属性的场景中实现最大吞吐量和最佳体验质量（QoE）。通过利用网络中块NDO名称和NDO元数据的可见性，可以在网络中执行其他优化，例如更积极的预取。此外，多源速率自适应结合网络编码可以实现更好的QoE，例如，在存在从客户端到上游缓存的多条路径的多接口/接入场景中[RFC7476]。
The essence of ICN lies in the name-based routing that enables users to retrieve NDOs by the names regardless of their locations. By definition, ICN is well suited for IoT applications, where users consume data generated from IoTs without maintaining secure connections to them. The basic request/response style APIs of ICN enable developers to build IoT applications in a simple and fast manner.
ICN的本质在于基于名称的路由，使用户能够通过名称检索NDO，而不管其位置如何。根据定义，ICN非常适合于物联网应用，在物联网应用中，用户使用从物联网生成的数据，而无需维护与物联网的安全连接。ICN的基本请求/响应风格API使开发人员能够以简单快速的方式构建物联网应用程序。
Ongoing efforts such as [ICN-FOR-IOT], [ICN-ARCH], and [ICN2014-NDNWILD] have addressed the requirements and challenges of ICN for IoT. For instance, many IoT applications depend on a PUSH model where data transmission is initiated by the publisher, so they can support various real-time applications (emergency alarm, etc.). However, ICN does not support the PUSH model in a native manner due to its inherent receiver-driven data transmission mechanism. The challenge would be how to efficiently support the PUSH model in ICN, so it provides publish/subscribe-style APIs for IoT application developers. This could be done by introducing other types of identifiers such as a device identifier or by extending the current request/response communication style, which may result in heavy overhead in ICN routers.
[ICN-FOR-IOT]、[ICN-ARCH]和[ICN2014-NDNWILD]等正在进行的工作已经解决了ICN对IOT的要求和挑战。例如，许多物联网应用依赖于发布者发起数据传输的推送模式，因此它们可以支持各种实时应用（紧急报警等）。然而，ICN由于其固有的接收器驱动的数据传输机制，不以本机方式支持推送模型。挑战在于如何有效地支持ICN中的推送模型，从而为物联网应用程序开发人员提供发布/订阅风格的API。这可以通过引入其他类型的标识符（例如设备标识符）或通过扩展当前的请求/响应通信样式来实现，这可能导致ICN路由器中的大量开销。
Moreover, key characteristics of the ICN underlying operation also impact important aspects of IoT, such as the caching in content storage of network forwarding entities. This allows the simplification of ICN-based IoT application development. Since the network is able to act on named content, generic names provide a way to address content independently of the underlying device (and access) technology, and bandwidth consumption is optimized due to the availability of cached content. However, these aspects raise
此外，ICN底层操作的关键特征也影响物联网的重要方面，例如网络转发实体的内容存储缓存。这允许简化基于ICN的物联网应用程序开发。由于网络能够对命名内容进行操作，通用名称提供了一种独立于底层设备（和访问）技术的内容寻址方式，并且由于缓存内容的可用性，带宽消耗得到了优化。然而，这些方面引起了关注
challenges themselves concerning the freshness of the information received from the cache in contrast to the last value generated by a sensor, as well as pushing content to specific nodes (e.g., for controlling them), which requires individual addressing for identification. In addition, due to the heterogeneous nature of IoT nodes, their processing capabilities might not be able to handle the necessary content signing verification procedures.
与传感器生成的最后一个值相比，从缓存接收到的信息是否新鲜，以及将内容推送到特定节点（例如，为了控制它们），这需要单独寻址以进行标识。此外，由于物联网节点的异构性，其处理能力可能无法处理必要的内容签名验证过程。
This document does not impact the security of the Internet. Security questions related to ICN are discussed in Section 4.2.
本文档不会影响Internet的安全性。第4.2节讨论了与ICN相关的安全问题。
[ACCESS-CTL-DEL] Fotiou, N., Marias, G., and G. Polyzos, "Access control enforcement delegation for information-centric networking architectures", Proceedings of the second edition of the ICN workshop on Information-centric networking (ICN '12) Helsinki, Finland, DOI 10.1145/2342488.2342507, 2012.
[ACCESS-CTL-DEL]Fotiou，N.，Marias，G.，和G.Polyzos，“信息中心网络体系结构的访问控制执行代表团”，ICN信息中心网络研讨会（ICN'12）第二版会议记录，芬兰赫尔辛基，DOI 10.1145/2342488.23425072012年。
[BACKSCATTER] Waehlisch, M., Schmidt, TC., and M. Vahlenkamp, "Backscatter from the Data Plane - Threats to Stability and Security in Information-Centric Network Infrastructure", Computer Networks Vol 57, No. 16, pp. 3192-3206, DOI 10.1016/j.comnet.2013.07.009, November 2013.
[反向散射]Waehlisch，M.，Schmidt，TC.，和M.Vahlenkamp，“数据平面的反向散射-对以信息为中心的网络基础设施的稳定性和安全性的威胁”，计算机网络第57卷，第16期，第3192-3206页，DOI 10.1016/j.comnet.2013.07.009，2013年11月。
[BREADCRUMBS] Rosensweig, E. and J. Kurose, "Breadcrumbs: Efficient, Best-Effort Content Location in Cache Networks", In Proceedings of the IEEE INFOCOM 2009, DOI 10.1109/INFCOM.2009.5062201, April 2009.
[面包屑]Rosensweig，E.和J.Kurose，“面包屑：缓存网络中高效、尽力而为的内容定位”，载于IEEE INFOCOM 2009年会议记录，DOI 10.1109/INFCOM.2009.5062201，2009年4月。
[CCN] Jacobson, V., Smetters, D., Thornton, J., Plass, M., Briggs, N., and R. Braynard, "Networking Named Content", CoNEXT 2009, DOI 10.1145/1658939.1658941, December 2009.
[CCN]Jacobson，V.，Smetters，D.，Thornton，J.，Plass，M.，Briggs，N.，和R.Braynard，“网络命名内容”，CoNEXT 2009，DOI 10.1145/1658939.16589411909年12月。
[CCN-ACCESS] Fotiou, N., Marias, G., and G. Polyzos, "Access control enforcement delegation for information-centric networking architectures", In Proceedings of the second edition of the ICN workshop on Information-centric networking (ICN '12), ACM, New York, NY, USA, 85-90, DOI 10.1145/2342488.2342507, 2012.
[CCN-ACCESS]Fotiou，N.，Marias，G.，和G.Polyzos，“信息中心网络体系结构的访问控制执行代表团”，载于ICN信息中心网络研讨会（ICN'12）第二版会议记录，ACM，纽约，纽约，美国，85-90，DOI 10.1145/2342488.23425072012年。
[CHAUM] Chaum, D. and E. van Heijst, "Group signatures", In Proceedings of EUROCRYPT, DOI 10.1007/3-540-46416-6_22, 1991.
[CHAUM]CHAUM，D.和E.van Heijst，“群签名”，载于《欧洲密码会议录》，DOI 10.1007/3-540-46416-622，1991年。
[COMPACT] Cowen, L., "Compact routing with minimum stretch", In Journal of Algorithms, vol. 38, pp. 170-183, DOI 10.1006/jagm.2000.1134, 2001.
[COMPACT]Cowen，L.，“最小拉伸的紧凑布线”，载于《算法杂志》，第38卷，第170-183页，DOI 10.1006/jagm.2000.11342001。
[CONTUG] Arianfar, S., Nikander, P., Eggert, L., Ott, J., and W. Wong, "ConTug: A Receiver-Driven Transport Protocol for Content-Centric Networks", Technical Report Aalto University Comnet, 2011.
[CONTUG]Arianfar，S.，Nikander，P.，Eggert，L.，Ott，J.，和W.Wong，“CONTUG：内容中心网络的接收器驱动传输协议”，Aalto大学通信网技术报告，2011年。
[DONA] Koponen, T., Ermolinskiy, A., Chawla, M., Kim, K., gon Chun, B., and S. Shenker, "A Data-Oriented (and Beyond) Network Architecture", In Proceedings of SIGCOMM 2007, DOI 10.1145/1282427.1282402, August 2007.
[DONA]Koponen，T.，Ermolinskiy，A.，Chawla，M.，Kim，K.，gon Chun，B.，和S.Shenker，“面向数据（和超越数据的）网络架构”，载于SIGCOMM 2007年会议录，DOI 10.1145/1282427.12824022007年8月。
[ENCRYPTION-AC] Kurihara, J., Uzun, E., and C. Wood, "An Encryption-Based Access Control Framework for Content-Centric Networking", IFIP Networking 2015, Toulouse, France, DOI 10.1109/IFIPNetworking.2015.7145300, September 2015.
[ENCRYPTION-AC]Kurihara，J.，Uzun，E.，和C.Wood，“基于加密的内容中心网络访问控制框架”，IFIP Networking 2015，法国图卢兹，DOI 10.1109/IFIPNetworking.2015.71453002015年9月。
[FRESHNESS] Quevedo, J., Corujo, D., and R. Aguiar, "Consumer Driven Information Freshness Approach for Content Centric Networking", IEEE INFOCOM Workshop on Name-Oriented Mobility Toronto, Canada, DOI 10.1109/INFCOMW.2014.6849279, May 2014.
[FRESHNESS]Quevedo，J.，Corujo，D.，和R.Aguiar，“以内容为中心的网络中消费者驱动的信息新鲜度方法”，IEEE信息通信研讨会，加拿大多伦多，DOI 10.1109/INFCOMW.2014.6849279，2014年5月。
[GREEDY] Papadopoulos, F., Krioukov, D., Boguna, M., and A. Vahdat, "Greedy forwarding in dynamic scale-free networks embedded in hyperbolic metric spaces", In Proceedings of the IEEE INFOCOM, San Diego, USA, DOI 10.1109/INFCOM.2010.5462131, 2010.
[贪婪]Papadopoulos，F.，Krioukov，D.，Boguna，M.，和A.Vahdat，“嵌入双曲度量空间的动态无标度网络中的贪婪转发”，发表于IEEE INFOCOM会议记录，美国圣地亚哥，DOI 10.1109/INFCOM.2010.5462131，2010年。
[HRICP] Carofiglio, G., Gallo, M., and L. Muscariello, "Joint hop-by-hop and receiver-driven interest control protocol for content-centric networks", In Proceedings of ACM SIGCOMM ICN 2012, DOI 10.1145/2342488.2342497, 2012.
[HRICP]Carofiglio，G.，Gallo，M.，和L.Muscariello，“内容中心网络的逐跳和接收器驱动的联合兴趣控制协议”，ACM SIGCOMM ICN 2012年会议记录，DOI 10.1145/2342488.2342497，2012年。
[ICN-ARCH] Zhang, Y., Raychadhuri, D., Grieco, L., Baccelli, E., Burke, J., Ravindran, R., Ed., and G. Wang, "ICN based Architecture for IoT - Requirements and Challenges", Work in Progress, draft-zhang-iot-icn-challenges-02, August 2015.
[ICN-ARCH]Zhang，Y.，Raychadhuri，D.，Grieco，L.，Baccelli，E.，Burke，J.，Ravindran，R.，Ed.，和G.Wang，“基于ICN的物联网架构-需求和挑战”，正在进行中的工作，草稿-Zhang-IoT-ICN-Challenges-022015年8月。
[ICN-FOR-IOT] Lindgren, A., Ben Abdesslem, F., Ahlgren, B., Schelen, O., and A. Malik, "Applicability and Tradeoffs of Information-Centric Networking for Efficient IoT", Work in Progress, draft-lindgren-icnrg-efficientiot-03, July 2015.
[ICN-FOR-IOT]Lindgren，A.，Ben Abdesslem，F.，Ahlgren，B.，Schelen，O.，和A.Malik，“以信息为中心的网络对高效物联网的适用性和权衡”，正在进行中的工作，草案-Lindgren-icnrg-efficientiot-032015年7月。
[ICN2014-AHLGREN-VIDEO-DEMO] Ahlgren, B., Jonasson, A., and B. Ohlman, "Demo Overview: HTTP Live Streaming over NetInf Transport", ACM SIGCOMM Information-Centric Networking Conference Paris, France, DOI 10.1145/2660129.2660136, September 2014.
[ICN2014-AHLGREN-VIDEO-DEMO]AHLGREN，B.，Jonasson，A.和B.Ohlman，“演示概述：通过NetInf传输的HTTP实时流”，ACM SIGCOMM信息中心网络会议巴黎，法国，DOI 10.1145/2660129.2660136，2014年9月。
[ICN2014-NDNWILD] Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and M. Waehlisch, "Information Centric Networking in the IoT: Experiments with NDN in the Wild", ACM SIGCOMM Information-Centric Networking Conference Paris, France, DOI 10.1145/2660129.2660144, September 2014.
[ICN2014-NDNWILD]Baccelli，E.，Mehlis，C.，Hahm，O.，Schmidt，T.，和M.Waehlisch，“物联网中的以信息为中心的网络：NDN在野外的实验”，法国巴黎ACM SIGCOMM以信息为中心的网络会议，DOI 10.1145/2660129.2660144，2014年9月。
[ICN2014-WEB-NDN] Moiseenko, I., Stapp, M., and D. Oran, "Communication Patterns for Web Interaction in Named Data Networking", ACM SIGCOMM Information-Centric Networking Conference Paris, France, DOI 10.1145/2660129.2660152, September 2014.
[ICN2014-WEB-NDN]Moiseenko，I.，Stapp，M.和D.Oran，“命名数据网络中网络交互的通信模式”，ACM SIGCOMM信息中心网络会议，巴黎，法国，DOI 10.1145/2660129.2660152，2014年9月。
[ICNNAMING] Ghodsi, A., Koponen, T., Rajahalme, J., Sarolahti, P., and S. Shenker, "Naming in Content-Oriented Architectures", In Proceedings ACM SIGCOMM Workshop on Information-Centric Networking (ICN), DOI 10.1145/2018584.2018586, 2011.
[ICNNAMING]Ghodsi，A.，Koponen，T.，Rajahalme，J.，Sarolahti，P.，和S.Shenker，“以内容为导向的体系结构中的命名”，摘自《ACM SIGCOMM信息中心网络（ICN）研讨会论文集》，DOI 10.1145/2018584.20185862011年。
[ICNRG-2015-01-WESTPHAL] Westphal, C., "Video over ICN", IRTF ICNRG Meeting Cambridge, Massachusetts, USA, January 2015, <http://www.ietf.org/proceedings/interim/2015/01/13/icnrg/ slides/slides-interim-2015-icnrg-1-0.pptx>.
[ICNRG-2015-01-WESTPHAL]威斯特法尔，C.，“ICN上的视频”，IRTF ICNRG会议，美国马萨诸塞州剑桥，2015年1月<http://www.ietf.org/proceedings/interim/2015/01/13/icnrg/ 幻灯片/幻灯片-临时-2015-icnrg-1-0.pptx>。
[ICNSURVEY] Ahlgren, B., Dannewitz, C., Imbrenda, C., Kutscher, D., and B. Ohlman, "A Survey of Information-Centric Networking", In Communications Magazine, IEEE, vol. 50, no. 7, pp. 26-36, DOI 10.1109/MCOM.2012.6231276, 2012.
[ICNSURVEY]Ahlgren，B.，Dannewitz，C.，Imbrenda，C.，Kutscher，D.，和B.Ohlman，“以信息为中心的网络调查”，载于《通信杂志》，IEEE，第50卷，第7期，第26-36页，DOI 10.1109/MCOM.2012.6231276，2012年。
[ISOIEC-7498-4] ISO, "Information Processing Systems -- Open Systems Interconnection -- Basic Reference Model -- Part 4: Management Framework", November 1989, <http://standards.iso.org/ittf/PubliclyAvailableStandards/ s014258_ISO_IEC_7498-4_1989(E).zip>.
[ISOIEC-7498-4]ISO，“信息处理系统——开放系统互连——基本参考模型——第4部分：管理框架”，1989年11月<http://standards.iso.org/ittf/PubliclyAvailableStandards/ s014258_ISO_IEC_7498-4_1989（E）.zip>。
[MANI] Pentikousis, K. and T. Rautio, "A multiaccess Network of Information", WoWMoM 2010 IEEE, DOI 10.1109/WOWMOM.2010.5534922, June 2010.
[MANI]Pentikousis，K.和T.Rautio，“信息的多址网络”，WoWMoM 2010 IEEE，DOI 10.1109/WoWMoM.2010.5534922，2010年6月。
[MDHT] D'Ambrosio, M., Dannewitz, C., Karl, H., and V. Vercellone, "MDHT: A hierarchical name resolution service for information-centric networks", ACM SIGCOMM workshop on Information-centric networking Toronto, Canada, DOI 10.1145/2018584.2018587, August 2011.
[MDHT]D'Ambrosio，M.，Dannewitz，C.，Karl，H.，和V.Vercellone，“MDHT：信息中心网络的分层名称解析服务”，加拿大多伦多ACM SIGCOMM信息中心网络研讨会，DOI 10.1145/2018584.2018587，2011年8月。
[MMIN] Pentikousis, K. and P. Bertin, "Mobility management in infrastructure networks", Internet Computing, IEEE vol. 17, no. 5, pp. 74-79, DOI 10.1109/MIC.2013.98, October 2013.
[MMIN]Pentikousis，K.和P.Bertin，“基础设施网络中的移动性管理”，互联网计算，IEEE第17卷，第5期，第74-79页，DOI 10.1109/MIC.2013.982013年10月。
[NDN-CTL-SHARING] Yu, Y., "Controlled Sharing of Sensitive Content", IRTF ICNRG Meeting San Francisco, USA, October 2015, <https://www.ietf.org/proceedings/interim/2015/10/03/ icnrg/slides/slides-interim-2015-icnrg-4-8.pdf>.
[NDN-CTL共享]俞，Y.，“控制共享敏感内容”，IRTF ICNRG会议，旧金山，美国，2015年10月，<https://www.ietf.org/proceedings/interim/2015/10/03/ icnrg/slides/slides-middial-2015-icnrg-4-8.pdf>。
[NDN-MGMT] Corujo, D., Aguiar, R., Vidal, I., and J. Garcia-Reinoso, "A named data networking flexible framework for management communications", Communications Magazine, IEEE vol. 50, no. 12, pp. 36-43, DOI 10.1109/MCOM.2012.6384449, December 2012.
[NDN-MGMT]Corujo，D.，Aguiar，R.，Vidal，I.，和J.Garcia Reinoso，“管理通信的命名数据网络灵活框架”，通信杂志，IEEE第50卷，第12期，第36-43页，DOI 10.1109/MCOM.2012.6384449，2012年12月。
[PURSUIT] Fotiou et al., N., "Developing Information Networking Further: From PSIRP to PURSUIT", In Proceedings of Proc. BROADNETS. ICST, DOI 10.1007/978-3-642-30376-0_1, 2010.
[PURSUIT]Fotiou等人，N.，“进一步发展信息网络：从PSIRP到PURSUIT”，摘自Proc会议录。宽网。ICST，内政部10.1007/978-3-642-30376-02010。
[RANDOM] Gkantsidis, C., Mihail, M., and A. Saberi, "Random walks in peer-to-peer networks: algorithms and evaluation", In Perform. Eval., vol. 63, pp. 241-263, DOI 10.1016/j.peva.2005.01.002, 2006.
[RANDOM]Gkantsidis，C.，Mihail，M.，和A.Saberi，“点对点网络中的随机游动：算法和评估”，执行。《评估》，第63卷，第241-263页，DOI 10.1016/j.peva.2005.01.002，2006年。
[RESOURCE-POOL] Psaras, I., Saino, L., and G. Pavlou, "Revisiting Resource Pooling: The case of In-Network Resource Sharing", ACM HotNets Los Angeles, USA, DOI 10.1145/2670518.2673875, October 2014.
[RESOURCE-POOL]Psaras，I.，Saino，L.，和G.Pavlou，“重新审视资源池：网络内资源共享的案例”，美国洛杉矶ACM HotNets，DOI 10.1145/2670518.2673875，2014年10月。
[RFC2002] Perkins, C., Ed., "IP Mobility Support", RFC 2002, DOI 10.17487/RFC2002, October 1996, <http://www.rfc-editor.org/info/rfc2002>.
[RFC2002]Perkins，C.，Ed.，“IP移动支持”，RFC 2002，DOI 10.17487/RFC2002，1996年10月<http://www.rfc-editor.org/info/rfc2002>.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007, <http://www.rfc-editor.org/info/rfc4838>.
[RFC4838]Cerf，V.，Burleigh，S.，Hooke，A.，Torgerson，L.，Durst，R.，Scott，K.，Fall，K.，和H.Weiss，“延迟容忍网络架构”，RFC 4838，DOI 10.17487/RFC4838，2007年4月<http://www.rfc-editor.org/info/rfc4838>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC5944] Perkins, C., Ed., "IP Mobility Support for IPv4, Revised", RFC 5944, DOI 10.17487/RFC5944, November 2010, <http://www.rfc-editor.org/info/rfc5944>.
[RFC5944]Perkins，C.，Ed.，“IPv4的IP移动性支持，修订版”，RFC 5944，DOI 10.17487/RFC59442010年11月<http://www.rfc-editor.org/info/rfc5944>.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, <http://www.rfc-editor.org/info/rfc6920>.
[RFC6920]Farrell，S.，Kutscher，D.，Dannewitz，C.，Ohlman，B.，Keranen，A.，和P.Hallam Baker，“用哈希命名事物”，RFC 6920，DOI 10.17487/RFC692012013年4月<http://www.rfc-editor.org/info/rfc6920>.
[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>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms", BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, <http://www.rfc-editor.org/info/rfc7696>.
[RFC7696]Housley，R.，“加密算法敏捷性和选择强制算法的指南”，BCP 201，RFC 7696，DOI 10.17487/RFC7696，2015年11月<http://www.rfc-editor.org/info/rfc7696>.
[SEEN] Pentikousis, K., "In search of energy-efficient mobile networking", Communications Magazine, IEEE vol. 48 no. 1, pp. 95-103, DOI 10.1109/MCOM.2010.5394036, January 2010.
[见]Pentikousis，K.，“寻找节能移动网络”，《通信杂志》，IEEE第48卷第1期，第95-103页，DOI 10.1109/MCOM.2010.5394036，2010年1月。
[VIDEO-STREAMING] Westphal, C., Ed., Lederer, S., Posch, D., Timmerer, C., Azgin, A., Liu, S., Mueller, C., Detti, A., Corujo, D., Wang, J., Montpetit, M., Murray, N., Azgin, A., and S. Liu, "Adaptive Video Streaming over ICN", Work in Progress, draft-irtf-icnrg-videostreaming-08, April 2016.
[视频流媒体]威斯特伐尔，C.，Ed.，莱德勒，S.，波什，D.，蒂默尔，C.，阿兹金，A.，刘，S.，穆勒，C.，德蒂，A.，科鲁乔，D.，王，J.，蒙佩蒂特，M.，穆雷，N.，阿兹金，A.，和S.刘，“ICN上的自适应视频流媒体”，正在进行的工作，草稿-irtf-icnrg-videostreaming-08，2016年4月。
Acknowledgments
致谢
The authors would like to thank Georgios Karagiannis for providing suggestions on QoS research challenges, Dimitri Papadimitriou for feedback on the routing section, and Joerg Ott and Stephen Farrell for reviewing the whole document.
作者要感谢Georgios Karagiannis就QoS研究挑战提供建议，Dimitri Papadimitriou就路由部分提供反馈，Joerg Ott和Stephen Farrell审查了整个文档。
Authors' Addresses
作者地址
Dirk Kutscher (editor) NEC Kurfuersten-Anlage 36 Heidelberg Germany
德克·库彻（编辑）NEC Kurfuersten Anlage 36德国海德堡
Email: kutscher@neclab.eu
Email: kutscher@neclab.eu
Suyong Eum Osaka University, School of Information Science and Technology 1-5 Yamadaoka, Suita Osaka 565-0871 Japan
日本大阪Suyong Eum大阪大学信息科学与技术学院山道1-5号，大阪Suita 565-0871
Phone: +81-6-6879-4571
Email: suyong@ist.osaka-u.ac.jp
Phone: +81-6-6879-4571
Email: suyong@ist.osaka-u.ac.jp
Kostas Pentikousis Travelping Koernerstr. 7-10 Berlin 10785 Germany
Kostas Pentikousis Travelping Koernestr。7-10柏林10785德国
Email: k.pentikousis@travelping.com
Email: k.pentikousis@travelping.com
Ioannis Psaras University College London, Dept. of E.E. Eng. Torrington Place London WC1E 7JE United Kingdom
伦敦Ioannis Psaras大学学院，英国伦敦WC1E 7JE托灵顿广场E.E.工程系
Email: i.psaras@ucl.ac.uk
Email: i.psaras@ucl.ac.uk
Daniel Corujo Universidade de Aveiro Instituto de Telecomunicacoes, Campus Universitario de Santiago Aveiro P-3810-193 Portugal
Daniel Corujo大学圣地亚哥阿维罗大学校园电信学院P-3810-193葡萄牙
Email: dcorujo@av.it.pt
Email: dcorujo@av.it.pt
Damien Saucez INRIA 2004 route des Lucioles - BP 93 Sophia Antipolis 06902 Cedex France
Damien Saucez INRIA 2004 Lucioles路线-英国石油公司93 Sophia Antipolis 06902法国Cedex
Email: damien.saucez@inria.fr
Email: damien.saucez@inria.fr
Thomas C. Schmidt HAW Hamburg Berliner Tor 7 Hamburg 20099 Germany
Thomas C.Schmidt HAW Hamburg Berliner Tor 7汉堡20099德国
Email: t.schmidt@haw-hamburg.de
Email: t.schmidt@haw-hamburg.de
Matthias Waehlisch FU Berlin Takustr. 9 Berlin 14195 Germany
马蒂亚斯·韦利希（Matthias Waehlisch）在柏林担任秘书长。9柏林14195德国
Email: waehlisch@ieee.org
Email: waehlisch@ieee.org