信息中心网络ICN：未来互联网的基础

3星 · 超过75%的资源需积分: 50 149 浏览量更新于2024-07-23 1 收藏 2.3MB PDF 举报

"信息中心网络ICN概述" 信息中心网络（Information-Centric Networking，简称ICN）是一种新兴的网络架构，其设计目标是针对当前互联网在处理信息访问需求时的局限性进行改革。传统的互联网架构基于主机为中心的通信模型，而ICN则转向以信息为中心的模式，重点关注内容本身而非其存储位置。这种转变源自互联网用户行为的变化，现在的用户更关心获取信息，而不关心这些信息存储在何处。 ICN的核心理念在于，网络应当以内容的名字来路由数据，而不是依赖于特定的设备或地址。这种模式可以提供更好的内容分发效率，因为用户可以直接请求感兴趣的信息，而无需知道信息的来源。此外，ICN还旨在增强网络的安全性、可扩展性和移动性，以适应不断增长的数据需求和多样的接入环境。在ICN的研究中，已经出现了多种主流架构，如Named Data Networking (NDN)、Content-Centric Networking (CCN) 和Information-Oriented Networking (ION)。这些架构都强调内容的命名和身份，而不是传统的IP地址。例如，NDN将每个数据块都视为一个具有独特名称的数据包，用户通过名称请求内容，网络则负责找到并返回匹配名称的数据。 ICN架构的关键功能包括： 1. 内容命名：所有数据都被赋予唯一的、可解析的名称，使得内容可以独立于其物理位置被发现和访问。 2. 内容存储与缓存：在网络节点上广泛部署的缓存机制允许内容被存储在网络的边缘，减少延迟并减轻核心网络的负担。 3. 内容路由：基于内容名称的路由机制，使得网络能够根据内容的标识符而非源或目的地址转发数据。 4. 安全性：ICN的架构可以内建安全机制，如数据签名和加密，以确保内容的完整性和隐私。 5. 移动性支持：用户可以在不改变内容访问体验的情况下切换网络连接，因为内容的获取是基于名称，而非特定的网络接口。尽管ICN提供了许多潜在优势，但实现这一架构仍面临诸多挑战，比如命名空间的管理和冲突解决、网络层的缓存策略优化、以及如何平滑地与现有的IP基础设施共存。同时，ICN还需要解决知识产权问题、服务质量保证和用户隐私等问题，才能广泛应用于未来的互联网。信息中心网络ICN是未来网络研究的重要方向，它的出现预示着互联网可能发生的深刻变革，旨在提供更加高效、安全和用户友好的信息服务。随着技术的不断发展和完善，ICN有可能成为构建下一代互联网的基础。

1028 IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 2, SECOND QUARTER 2014

2000

2001

2002

2003

2006

2007

2008

2009

2010

2011

i3 [14]

VRR [16], ROFL [17]

CCN Google Tech Talk [41]

TRIAD [9], Content-based networking [11]

2004

2005

DONA [29]

CCN [42], LIPSIN [53]

ANR Connect [39]

(Jan 2011- Dec 2012)

NDN [36]

(Sep 2010- Aug 2013 )

PSIRP [31]

(Jan 2008-Jun2010 )

OceanStore [15]

PURSUIT [30]

(Sep 2010-Feb 2013)

SAIL [32]

(Aug 2010-Jan 2013)

CONVERGENCE [35]

(Jun 2010-Feb 2013)

COMET [34]

(Jan 2010-Dec 2012)

2012

MobilityFirst [38]

(Sep 2010-Sep 2013)

4WARD [33]

(Jan 2008-Jun 2010)

1999

TRIAD [10]

(Jul 1999-Dec 2002)

Fig. 1. Timeline of ke y ICN milestones. Seminal ICN papers are shown on the left hand side, while ICN-related projects are shown on the right hand side.

ities ( see Figure 1), th e Data Oriented Network Architec-

ture (DONA) [29] from UC Berkeley is one of the ﬁrst

complete ICN architectures, as it radically changes naming

by replacing the hierarchical URLs with ﬂat names. Unlike

URLs which are bound to speciﬁc locations via their DNS

component, the ﬂat names in DONA can be persistent, even

if the information moves. This allows information to be cached

and replicated at the network layer, thus increasing information

availability. Finally, names in DONA allow users to verify

that the received information matches a requested name via

cryptographic techniques. On the other hand, DONA maintains

IP addressing and routing, either globally or locally (see

below), deploying a name resolution mechanism as an overlay

that maps its ﬂat names to the corresponding information.

1) Naming: In DONA each piece of information (or ser-

vice) is associated with a principal. Names consist o f the

cryptographic hash of the principal’s public key P and a

label L uniquely identifying the information with respect to

the principal. Naming granularity is left to the principals,

who are considered to be the owners of the correspond-

ing information. For instance, principals may name either

an entire web site or each individual web page within it.

Names are ﬂat, application-independent, location-independent

and globally unique. For immutable data the label can be

the cryptographic hash of the information object itself, thus

allowing any purveyor (e.g., a CDN) to offer such data. Clients

interested in an information object are assumed to learn its

name through some trusted external mechanisms (e.g., a search

engine). Unlike structured DNS names, ﬂat names in DONA

do not embed a ﬁxed administrative structure, thus they are

easy to map to any private namespace of human-readable

names.

2) Name Resolution and Data Routing: Name resolution

in DONA is provided b y specialized servers called Resolution

Handlers (RHs). There is at least one logical RH at each

AS. RHs are interconnected, forming a hierarchical name

resolution service on top of the existing inter-domain routing

relations, as shown in Figure 2, so as to allow name resolution

and data routing to respect the established routing policies be-

tween AS’s. In order to make an information object available,

the publisher (principal) sends a R

EGISTER message with the

object’s name to its local RH, who stores a pointer to the

XYLOMENOS et al.: A SURVE Y OF INFORMATION-CENTRIC NETWORKING RESEARCH 1029

AS 1

Tier-1 AS

AS 2

AS 3

Publisher

Subscriber

(

)

(

)

(

)

(

)

Find Message

Client-Provider Link

Peering Link

Data

(8-11)

(1-3)

(4-7)

(

)

(2)

(

)

(

)

(

)

(

)

Router

(

)

Fig. 2. The DONA architecture. RH stands for Resolution Handler.

principal (arrow 1). The RH then propagates this registration

to the RHs in its parent and peering domains, following

the established routing policies (arrows 2-3), causing each

intermediate RH to store a mapping between the object’s name

and the address of the RH that forwarded the registration. As a

result, registrations are replicated in RHs all the way up to the

tier-1 providers and, since all tier-1 providers are peers with

each other, RHs located at tier-1 providers are aware of all

registrations in the entire network. Publishers can also issue

wildcard R

EGISTER messages to notify the RH hierarchy that

they can provide all possible data items for a speciﬁc principal.

In order to locate an item, a subscriber sends a F

IND

message to its local RH, which also propagates this message

to its parent according to its routing policies, until a match-

ing registration entry is found (arrows 4-5). At that point,

requests follow the pointers created by the registrations in

order to eventually reach the publisher (arrows 6-7). Since

tier-1 providers are aware of all objects in the network, this

process is guaranteed to succeed if the requested name exists.

Subscribers can also issue wildcard F

IND messages to ask for

immutable data with a speciﬁc label, regardless of its purveyor.

Data routing can be either decoupled or coupled with name

resolution. In the decoupled option, when a F

IND message

reaches an appropriate publisher, the d ata can be directly sent

to the subscriber using regular IP routing and forwarding. The

actual data transmission will follow the established routing

policies for trafﬁc between the publisher’s and the subscriber’s

AS’s. This requires global IP addresses, which are nearly

exhausted, so DONA also offers a coupled option which relies

on domain-local IP addresses only. In the coupled option

the F

IND messages g ather path-labels as they move from

RH to RH, indicating the sequence of AS’s crossed by the

request. When the request reaches the publisher, these path-

labels are simply used in the reverse or der to retrace the

path towards the subscriber (arrows 8-11). While the coupled

option obviates the need for global IP addresses and large BGP

routing tables, since all pa th-labels have a local meaning, it

enforces symmetric routing (at least, at the AS level) between

requests and responses, which is not necessarily the case with

regular BGP routing.

DONA can also support multicast channels, by allowing

IND messages to be cached in RHs for a speciﬁed period

of time and sending information updates in response to these

messages until they expire. When additional F

IND messages

for the same information are received by the RH, they are

merged into a single entry with multiple pa th-labels for the

responses, thus creating a multicast distribution tree. Note that

this can only work with the coupled option, as it requires data

to follow the reverse AS path taken by the F

IND messages.

3) Caching: DONA supports on-path caching via the RH

infrastructure. A RH that decides to cache a requested data

object can replace the source IP address of an incoming

IND request with its own IP address, before forwarding the

message to the next RH. As a result, any response will surely

traverse the current RH, thus the data returned will be cached

there. If path-labels are used, the data always return via the

intermediate RHs, who can then decide whether to cache the

information or not. If a subsequent F

IND message requesting

the same object reaches a caching RH, the RH can directly

return the data to the subscriber. Information may also be

replicated off-path, provided that each purveyor registers the

information through its local RH. A RH receiving multiple

剩余25页未读，继续阅读

中二病也要撸啊撸

粉丝: 0
资源: 1

信息中心网络ICN：未来互联网的基础

命名数据网络

车联网相关知识介绍.pdf

中心网络ICN

比较论述ICN信息中心网络和传统IP网络的区别和功能特点。

信息中心网络消费者、生产者概念

icn6211配置工具

chip one icn6202

icn6202电路图

icn6211调试白屏

rk平台调试icn6211

最新资源