可增量部署的网络体系结构，以支持以数据为中心和以主机为中心的服务资源-CSDN文库

研究论文

50 浏览量 2021-03-19 02:33:55 上传评论收藏 362KB PDF 举报

资源推荐

资源详情

资源评论

he current Internet architecture was designed in the

1970s and is host-centric [1]. While the hosts in the

Internet are generally named by their IP addresses,

the current Internet does not have a mechanism for

directly naming data (files, streams, etc.) and services (pro-

cesses that are remotely invoked by clients). Instead, both are

named in association with domain names. For example, a

photo file, alice.jpg, hosted by Google may have a name

http://www.google.com/img/alice.jpg. Here the domain name

http://www.google.com is mainly used to locate the destination

host and route a packet requesting the photo to the destina-

tion host. In addition, data names are not persistent, which

means that the name of a datum depends on where it is locat-

ed or who manages it. For example, when the above photo is

hosted by Baidu, its name may change to http://www.baidu.

com/figure/alice.jpg.

Along with the rapid development and tremendous success

of the Internet in the past few decades, however, the vast

majority of current Internet usage has changed to data

retrieval and service access (i.e., being data-centric). There-

fore, there is a growing consensus that the Internet should be

designed around the data-centric model [1–6]. In the data-

centric model, if a user is interested in a datum, he/she can

directly obtain it by inputting the persistent name of the

desired data without knowing where the data is located. While

the Domain Name System (DNS) already hides data location

to some extent by mapping domain names to IP addresses, it

is inconvenient for users to obtain data/services in the current

Internet due to non-persistent data names. For example, when

we input a URL in order to obtain a desired datum, we occa-

sionally encounter the HTTP error 404 and cannot obtain the

desired datum, although the datum may still reside on the

same server, but has been moved from one directory to anoth-

er. In light of this, several new data-centric network architec-

tures have been proposed [3–6, references therein].

However, most existing applications, transport layer proto-

cols, end hosts, and routers are host-centric. Therefore, it is

not practical to deploy a pure data-centric architecture

overnight. Indeed, there are billions of end hosts and servers

around the world, and it is impossible to upgrade them all at

once. Also, the Internet has millions of routers, and it would

be extremely expensive to replace them. Evidence of the resis-

tance to radical change is that only a few Internet service

providers have transitioned their networks from IPv4 to IPv6,

although IPv6 has been standardized for more than 10 years.

Hence, it is desirable to design a new network architecture

that is both data-centric and incrementally deployable. In

addition, it is also desirable that the new network architecture

supports mobility and multi-homing efficiently, as discussed

further below.

Mobility —

Since more and more hosts connected to the

Internet are expected to be mobile, the new network architec-

ture must efficiently support mobility, including host mobility

and service mobility. Host mobility allows a device to move

between IP subnets, while continuing to be reachable for

incoming requests and maintaining sessions across different

subnets. By contrast, service mobility allows users to maintain

access to their services while moving or changing devices and

network service providers.

IEEE Network • July/August 2014

Abstract

Most Internet traffic is associated with applications where users are interested in

the data and not in the source where the data resides. On the other hand, the cur-

rent Internet architecture is host-centric rather than data-centric, and it is not practi-

cal to deploy a pure data-centric architecture overnight. This motivates an

incrementally deployable network architecture that can efficiently support both

data-centric and host-centric services. In this article we describe such an architec-

ture called DCNA for the Internet. DCNA is based on the inclusion of a shim layer

between the application layer and the transport layer along with appropriate inter-

faces to connect these layers. In addition to being data-centric and incrementally

deployable, DCNA can also effectively support mobility and multi-homing.

An Incrementally Deployable Network

Architecture to Support Both Data-Centric

and Host-Centric Services

Hongbin Luo, Hongke Zhang, Moshe Zukerman, and Chunming Qiao

Hongbin Luo and Hongke Zhang are with Beijing Jiaotong University,

Beijing, PRC.

Moshe Zukerman is with the City University of Hong Kong, Hong Kong

SAR, PRC.

Chunming Qiao is with the State University of New York at Buffalo, NY,

USA.

LUO_LAYOUT.qxp_Layout 1 7/17/14 2:17 PM Page 58

Multi-Homing —

This enables users to access different net-

works and provides them with several benefits, such as cost-

effective network selection, reliability, and ubiquitous

connectivity. While many devices in the current Internet have

two or more network interfaces that are assigned different IP

addresses in the current Internet architecture, it is difficult to

move an ongoing session from one interface to another if the

former fails. Thus, the new network architecture must support

it efficiently.

In this article we describe a data-centric network architec-

ture (DCNA) that can efficiently support both data-centric

and host-centric services. The basic ideas of the proposed

architecture are:

• Insert a shim layer between the application layer and the

transport layer of the current Internet architecture.

• Use appropriate interfaces to efficiently connect these layers.

We build a proof-of-concept implementation of DCNA in a

Linux environment and demonstrate how DCNA satisfies the

above design goals.

The remainder of this article is organized as follows. The

following section briefly discusses related work. We then

describe the proposed architecture in detail. Following that,

we present the implementation of a proof-of-concept proto-

type of DCNA and the evaluation results obtained from the

prototype in order to show that the design goals are met.

Finally, we conclude the article.

Related Work

To support data-centric services, several data-centric network

architectures have been proposed in recent years: content-

centric networking (CCN) [3], network of information (Net-

Inf) [4], data-oriented network architecture (DONA) [5], and

publish-subscribe Internet routing paradigm (PSIRP) [6].

CCN tries to bring about a fundamental shift from the

host-centric model to the data-centric model. In CCN

each content file/object is split into multiple chunks, and

each of them is assigned a unique name that follows a

hierarchical structure inspired by the web’s Uniform

Resource Identifiers (URIs). Nodes with content that may

be of interest to others announce content names, or the

prefixes of the names, as with IP routing announcement.

A content consumer who is interested in particular con-

tent sends out an Interest packet that contains the name

of the requested chunk. When a content router receives

an Interest packet, it directly returns the requested chunk

to the consumer if it locally caches the requested chunk.

Otherwise, it adds the Interest into its Pending Interest

Table (PIT) and sends out the Interest packet toward

potential data sources using longest prefix match. The PIT

of a content router records Interests forwarded toward

content sources and the interfaces from which the Inter-

ests come. When a content router receives a Data packet,

it forwards the Data packet based on the PIT. In addition,

it caches the Data packet in order to satisfy subsequent

Interest packets [3].

DONA also assigns a unique and persistent name for every

datum/service. While content names in CCN are hierarchical,

data names in DONA are flat and self-certifying [5]. In addi-

tion, nodes that are authorized to serve a datum register it to

a hierarchical resolution infrastructure composed of resolu-

tion nodes. A node interested in the data sends FIND packets

to the resolution infrastructure, which routes FIND packets by

the name of the data and tries to find the data closest to the

requesting node. Once the desired data is found, it is sent to

the requesting node using standard IP routing and forwarding.

However, DONA binds transport protocols to data names

instead of IP addresses [5], which make it impossible to sup-

port a host-centric model.

NetInf uses information objects (IOs) to name data. Similar

to DONA, a node that wants to provide a datum registers the

IO of the datum and the node’s IP address into a name reso-

lution service (NRS). Since multiple nodes may want to pro-

vide the same datum, an IO may correspond to multiple IP

addresses. When a node wants to obtain a datum, it sends a

request containing the IO of the desired datum to the NRS,

which then returns the IP address(es) for the desired datum

to the requesting node. The IP addresses are then used to

retrieve a copy of the datum from the “best” available

source(s) [4]. However, NetInf does not address the problem

of how the end-host stack should be enhanced to support such

a data-centric model.

In PSIRP, sources publish data in a publish/subscribe-based

rendezvous system and receivers subscribe to data that have

been published [6]. The publications and subscriptions are

then matched by the rendezvous system. However, PSIRP

identifies links instead of nodes and uses a routing and for-

warding scheme totally different from the Internet today,

which makes it very hard to be incrementally deployed.

We note that to support host mobility and multi-homing,

some network layer protocols such as locator/identifier sepa-

ration protocol (LISP) [7] and host identity protocol (HIP) [8]

have been proposed. However, they cannot support service

mobility and data-centric services. We also note that service

mobility can be realized by the Session Initiation Protocol

(SIP) [9]. However, the SIP-based approaches generally

employ a user agent while we aim at realizing service mobility

without agents.

The Proposed Architecture

As described in the first section, we aim at designing a new

network architecture that is both data-centric and incremen-

tally deployable. Thus the end hosts implementing the new

network architecture have to be compatible with the existing

hosts in order to be incrementally deployable. From the per-

spective of the new and existing end hosts, it is desirable that

we only need to make minimum changes to the host stack.

There are a few design choices for the Internet to move

toward data-centric while being incrementally deployable.

One possible choice is for every application in the application

layer to be data-centric. For example, peer-to-peer (P2P)

applications are data-centric since a user does not need to

know where a desired data/service is located. Instead, P2P

applications would search, using certain application-specific

techniques, the end hosts that provide the desired data/ser-

vice. However, as envisioned in today’s Internet, the majority

of applications are host-centric. For example, in the HTTP

application we input a URL, and then the HTTP application

resolves an IP address based on the domain name in the

URL. After that it sends requests to the resolved IP address

in order to obtain the desired data/service. In this process the

HTTP application sends commands/requests to a given

domain name (contained in the URL). That is, it cares

“where” the desired data comes from. On the other hand, in

the data-centric model we want applications to simply request

the name of the desired data without having to care about

where the desired data comes from. If we want these applica-

tions to be data-centric, we have to revise them application-

by-application, which is not efficient. Notice that these

revisions are specially tailored to existing applications. If a

new application emerges, the work is repeated. It is more effi-

cient to design a novel architecture that applies to all applica-

tions (existing and future) instead of to specific ones.

IEEE Network • July/August 2014

LUO_LAYOUT.qxp_Layout 1 7/17/14 2:17 PM Page 59

剩余7页未读，继续阅读

评论收藏

内容反馈

weixin_38560039

粉丝: 3
资源: 888

可增量部署的网络体系结构，以支持以数据为中心和以主机为中心的服务

增量部署工具

计算机网络体系结构

数据库的体系结构

计算机体系结构

基于堆叠的三层架构数据中心网络部署

HC1309156 VMWare集群基础.pptx

Sybase IQ 16.0中文版本 SAP Sybase IQ简介

33政府政府网站群灾备系统建设技术方案.pdf

存储入门学习资料

sybase系统管理员培训PPT课件.pptx

集群好书《高性能Linux服务器构建实战》 试读章节下载

2017最新老男孩MySQL高级专业DBA实战课程全套【清晰不加密】，看完教程月入40万没毛病

Oracle数据库规划设计和运行维护方案.docx

构建最高可用Oracle数据库系统 Oracle 11gR2 RAC管理、维护与性能优化

bind9中文说明

Solaris用户命令中英文对照参考.doc

基于CORDIC的反正弦和反余弦计算的FPGA实现

BA无标度网络中的SIR模型

使用3DCNN和卷积LSTM进行手势识别学习时空特征

基于三次贝塞尔曲线的类汽车曲率连续路径平滑

基于机器学习的设备剩余寿命预测方法综述

基于维纳过程的退化模型，具有递归过滤算法，可用于估计剩余使用寿命

基于FPGA的奇异值和特征值分解的快速实现。

基于BP神经网络的人口预测

磁悬浮系统自适应模糊PID控制器的设计

最新资源

集群好书《高性能Linux服务器构建实战》试读章节下载