CoLoR: An Information-Centric Internet Architecture

for Innovation

Hongbin Luo, Zhe Chen, Jianbo Cui, Hongke Zhang

School of Electronic and Information Engineering

Beijing Jiaotong University

Beijing 100044, China

Email: {hbluo, 11120069, 12120053, hkzhang}bjtu.edu.cn

Moshe Zukerman

Electronic Engineering Dept.

City University of Hong Kong

Hong Kong SAR, China

Email: m.zu@cityu.edu.hk

Chunming Qiao

Computer Sci. and Eng. Dept.

University at Buffalo, SUNY

Buffalo, NY 14260-2500,USA

Email: qiao@computer.org

Abstract—In this paper, we describe an information-centric Internet architecture called CoLoR that couples service

location and inter-domain routing while decoupling them from forwarding. Preliminary results based on implementation

and analysis show that CoLoR is promising since it satisfies many requirements of the future Internet including being

information-centric, encouraging innovation, and providing efficient support for mobility, multicast, multi-homing, and

middleboxes.

Keywords—future Internet architecture, information-centric network, innovation

I. INTRODUCTION

The Internet has achieved enormous success since its inception. However, despite the rapid increase in the number of users and

applications, it faces many challenges including poor scalability and security. Unfortunately, these architectural deficiencies cannot

be remedied by incremental changes to the current Internet architecture. Therefore in recent years there is an increasing amount of

efforts in developing “clean-slate” redesigns of the Internet architecture, aiming at rectifying one or more of these problems

through non-incremental changes [1–5, and references therein 5]. For example, the authors of [2-4] aimed at designing an

information-centric Internet. The authors of [6,7] argued that a future Internet should be designed for encouraging competition and

innovation. Raychaudhuri et al. [8] aimed at designing an Internet that provides better support for mobility and security.

In this paper, we are also pursuing a “clean slate” Internet architecture, focusing on the following attributes which constitute

the design objectives of the new architecture:

1) Information centric: While the current Internet is host-centric (i.e., packets are sent to a specific host’s IP address), it is being

used overwhelmingly for information retrieval. Accordingly, there is an increasing consensus that the future Internet should be

information-centric. That is, contents should be assigned names that are location-independent and application-independent.

2) Efficient support for mobility: With the rapid increase in the number of mobile devices, the future Internet architecture

should efficiently support mobility.

3) Efficient support for multi-homing: In multi-homing, a host (or network) is simultaneously attached to multiple networks. It

is cumbersome to efficiently support multi-homing in the current Internet because it causes serious routing scalability problem. A

future internet architecture is expected to support multi-homing more efficiently.

4) Encouraging innovation: The future internet architecture should allow each network to use its preferred network architecture

and routing mechanism so that different network technologies can be simultaneously deployed and contest, thus encouraging

innovation.

5) Enhanced security: The current Internet employs a “default-on” model [9] wherein any host is able to send packets to a

remote host, which makes the current Internet vulnerable to distributed denial-of-service attacks. Therefore, the future Internet

should offer receivers the ability to control incoming traffic, especially to refuse unwanted traffic.

6) Enhanced scalability: The future Internet should provide better routing scalability over the current Internet. In particular, the

routing table size should be significantly less than that in the current Internet.

7) Ease of traffic matrix estimation: It is difficult to estimate traffic matrices in the current Internet. However, since traffic

matrices are critical inputs to many aspects of network management such as traffic engineering and network provisioning, the

future Internet should makes it easy to accurately estimate traffic matrices in real time.

8) Deployability: Although we aim at a clean-slate design, the new architecture should be deployable without incurring

significant cost.

While many Internet architectures [1-8,10] have been proposed in the past years, none of them has all the above mentioned

design objectives. In this paper, we propose a future Internet architecture that has all the above attributes. It is based on coupling

service location and inter-domain routing while decoupling them from forwarding. Accordingly we name it CoLoR for short.

CoLoR is created by synthesizing many ideas borrowed from existing work in a cohesive manner. For example, we borrow the idea

of using self-certifying node identifiers from MobilityFirst [8] and AIP [11]. From DONA [2], we borrow the idea of naming data

with self-certifying identifiers to achieve data authenticity and persistency. From FII [6] and Pathlet routing [12], we borrow the

idea of using paths (or path segments) for inter-domain routing. Similarly, we borrow the name-based routing mechanism from

DONA [2], and CCN [4].

In addition to designing CoLoR, we also build a proof-of-concept prototype of CoLoR and present results from experiments

carried on the prototype to demonstrate CoLoR’s feasibility in small scale deployments.

The remainder of the paper is organized as follows. In Section II, we describe the CoLoR architecture. In Section III, we report

our proof-of-concept prototype of CoLoR. In Section IV, we explain how CoLoR satisfies our design objectives. Finally, we

conclude the paper and outline future work in Section V.

II. THE COLOR ARCHITECTURE

We will now describe the design details of the CoLoR architecture. We begin with the network topology, naming, and routing.

We then describe how to register services, how to locate services and determine inter-domain paths for services. Finally, we

describe how data packets are forwarded and discuss how to cache services in CoLoR.

A. Network Topology

As in the current Internet, CoLoR assumes that a future Internet will continue to be organized around domains that have

domain-level provider/customer/peer relationships. Every domain has a logical resource manager (with possibly many physical

incarnations), which maintains a registration table that stores the reachability information of contents. For brevity, we denote a

resource manager (RM) associated with a domain X by RMX. The relationships between RMs of domains are defined by the domain

level relationships: namely, RMX is the provider, customer, or peer (or, alternatively, parent, child, or peer) of RMY if domain X is

the provider, customer, or peer of domain Y, respectively. Note that, the RM in CoLoR is similar to the resource handler (RH) in

DONA. However, as will be shown later in Section III. E, a RM in CoLoR needs to choose path identifiers if there are multiple

path identifiers between two domains. On the contrary, a RH in DONA does not need to do this.

In addition, we assume that every node in CoLoR “knows” the location of its local RM through some local configurations,

similar to the way in which an end host knows its local domain name service (DNS) server in the Internet today.

B. Naming

Unlike the current Internet that uses only one namespaces (i.e., IP addresses), CoLoR uses two global namespaces: service

identifiers (SIDs) and node identifiers (NIDs). To be information-centric, CoLoR assigns every content a persistent and unique SID

which is application-independent and location-independent. By persistent, we mean that the name for a content remains valid as

long as the underlying content is available. By unique, we mean that two different pieces of content should have different SIDs. As

in DONA [2], CoLoR uses self-certifying SIDs to achieve content authenticity. Meanwhile, NIDs are used to name nodes in the

network. Every node in the network has a unique and persistent NID that is independent of the location of the node. As in [8] and

[11], NIDs in CoLoR are flat, self-certifying labels, so that authenticating a node does not require an external authority such as

ICANN [8], thus improving security and privacy. Note that the current Internet uses hierarchical IP addresses, since its global

routing heavily relies on the aggregability of IP addresses to achieve scalability. By contrast, NIDs in CoLoR are not used for

global routing, but for authentication.

CoLoR also uses two local namespaces: intra-domain routing locators and path identifiers (PIDs). Intra-domain routing

locators are used for routing within a domain. Domains in CoLoR may use different intra-domain routing locators. For example,

Domain A may use IPv6 addresses for local routing, while Domain B may use IPv4 addresses. PIDs are used to name (virtual)

paths between domains. As in [6] and [12], two domains could negotiate the number of paths between them. For a given path, its

PID is also negotiated between the two domains, as long as the PID is unique in both domains. Unlike [6] and [12] where the PID

of the path between two domains is advertised throughout the Internet, the PID of the path between two domains is known only by

the two domains for the purpose of enhancing security. In addition, we anticipate that the PIDs between two domains are randomly

chosen so that it is difficult for attackers to correctly guess them, thus further improving security. While the length of PIDs is 32

bits in our implementation, optimizing this length is nontrivial as it requires trading off efficiency and security. Intuitively, a longer

length leads to higher bandwidth consumption, but makes it harder for attackers to correctly guess the PIDs between two domains.

A B C

D1 D2

D3

D4

D5

D6

RM1

RM2

RM3

RM4

RM5

RM6

(i)

R1

R6

R2

R4

R2

R5

R10R9

R7

R8

R11

R12

(1)

P2P3

P1

P4

P6

P5

P7

P1 D5R7

P2 D5R7

P3 D5R7

P5 D3R6

PID DR

60

30

10

100

pref

(4)

(5)

(3)

(2)

(v)

(iv)

(ii)

(iii)

(vi)

(ii) SID1 C P4

(iii) SID1 C P4 (iv) SID1 C P4 P5P1P1

SID1 C(i)

(v) SID1 C P4 P5P1 P6

(vi) SID1 C P4 P5P1 P6

Fig. 1. Illustration for network topology and service registration in CoLoR.

C. Routing

In the current Internet, both inter-domain routing and intra-domain routing rely on IP addresses. As a result, without global

coordination, it is difficult for domains to deploy novel networking technologies. To overcome this drawback, CoLoR separates

intra-domain routing from inter-domain routing. Domains in CoLoR are free to adopt their preferred network architectures and

intra-domain routing mechanisms, such as IPv4, and IPv6, thus encouraging innovation of network technologies. This may make it

difficult to efficiently support host mobility since a mobile device needs to adapt to different network technologies. However, there

are at least two approaches for dealing with this issue. First, as advocated in [6], we can require that each intra-domain networking

technology supports a method of bootstrap, so that a host can learn about the environment and determine where its local resources

are. Second, we may split every domain into a core and an edge, with border routers connecting the edge and the core. End hosts

are located at the edge and connected to the core through border routers by a common approach. This will have the benefit that

border routers and other routers in the core can use any technology chosen by the domain.

Inter-domain routing in CoLoR relies on paths negotiated by domains. In particular, two domains can negotiate a set of paths,

depending on their local policies. The two endpoints of each path are located at each of the two domains. For example, domains

D5 and D6 in Fig. 1 negotiate three paths P1, P2, and P3, as indicated by the bold dashed lines in Fig. 1. The two endpoints of P1

are R8 and R7 located in D5 and D6, respectively. For a path that begins at a domain, the RM and the routers (that connect hosts or

other domains) in the domain maintains the path’s endpoint located at the domain and the domain identifier at which the other

endpoint are located. For example, the inter-domain routing table of R6 is shown at the upper left corner in Fig. 1.

D. Service Registration

In CoLoR, users send out GET messages to obtain their desired contents, and the network routes the GET messages to the

nearest nodes holding the desired contents. This requires a mechanism to propagate the reachability information of SIDs. To

achieve this, the RMs in CoLoR comprise an overlay to propagate the reachability information of SIDs. The mechanism used to

propagate the reachability information of SIDs may be similar to that of DONA [2], or CCN [4].

In this paper, we use a mechanism similar to that in DONA. In particular, a node holding a copy of a content registers the

content’s SID to the RM in the same domain, if it is authorized to do so. Depending on the local policy, the RM may also register

the content to its parent/peer RMs. Fig. 1 illustrates the registration process. When RM3 receives the registration message for the

SID from RM1, it stores an entry for the SID into its registration table. In addition, it also sends a registration message to its parent

RM (i.e., RM6). When RM6 receives the registration message, it then stores an entry for the SID in its registration table. When RM3

receives a registration message for the SID from RM2, it finds that there is an entry for the SID, but the registration message comes

from RM2 instead of RM1. Thus, it adds an entry for the SID to its registration table. Note that now RM3 does not send a registration

message for the SID to RM6, since it has registered the SID already.

E. Service Location and Inter-Domain Routing

Recall that, for security, the PIDs between two domains are not advertised to other domains. Accordingly, a content source

cannot know the inter-domain paths to a content consumer, so it cannot send data packets to the consumer. To address this issue,

CoLoR determines the inter-domain paths during the service location process. In particular, when a client wants to obtain a content

represented by an SID, it sends out a GET message to its local RM. The GET message should contain the SID and the client’s NID.

If the RM cannot find an entry for the SID, it firstly chooses a parent RM based on its local policy and then chooses a PID destined

to the corresponding parent domain. Note that, when a domain A has multiple PIDs to another domain B, it can choose which PID

to use based on its local policy. However, the best PID for domain A may not be the best one for domain B, since the path from the

ingress node (or the node holding the SID) to the egress node corresponding to the chosen PID in domain B may be congested.

Therefore, it is necessary for the two domains to negotiate with each other in order for the “best” performance for both domains.

However, how to negotiate is out of the scope of this paper.

The RM then appends the PID of the chosen path onto the GET message and sends it to the chosen parent RM. If the RM finds

at least one entry for the SID, it chooses an entry based on its local policy (e.g., traffic engineering). If the node contained in the

entry is in the same domain with the RM, the RM directly forwards the GET message to the node by using the routing mechanism

in that domain. If the node is in another domain, the RM chooses a path towards that domain, based on its local policy. Afterwards,

the RM appends the PID of the chosen path onto the GET message and forwards the GET message to the node.

Fig. 1 illustrates how a GET message is forwarded from a client to a node hosting the desired content represented by an SID,

assuming that the content has been registered as described in Section II. D. When node C wants the content, it sends a GET

message to its local RM (i.e., RM4). When RM4 receives the GET message, it cannot find an entry for the SID. Accordingly, it

appends path P4 onto the GET message and sends the resulting message to its parent RM (i.e., RM5). Similarly, RM5 appends path

P1 (or P2, P3, depending on D5’s local policy) onto the received GET message and sends the resulting message to its parent RM (i.e.,

RM6). When RM6 receives the GET message, it finds an entry for the SID in its registration table. Since RM6 is not in the same

domain with RM3, it appends path P5 onto the received GET message and sends the resulting message to RM3. Since RM3 can find

two entries for the SID, it chooses the entry pointing to domain D1 based on its local policy, appends path P6 onto the received GET

message, and sends the GET message to RM1. When RM1 receives the GET message, it finds that a local node (i.e., node A) holds

the desired content. Accordingly, it sends the GET message to node A. For clarity, we show the GET messages in each step at the

bottom of Fig. 1.

F. Packet Forwarding

Once the source node storing the desired content receives the GET message, it knows the SID of the desired content, the

client’s NID, and the inter-domain paths that will be used to reach the client. As a result, the source node encapsulates the packets

of the content with a header that carries the client’s NID, the SID, and the PIDs.

Recall that, for every path that begins at a domain, the routers and the RM in the domain maintain the endpoint of the path

located at the domain and the domain identifier at which the other endpoint is located. Accordingly, the source node then sends the

packets to the border router associated with the first PID (or path) by using the routing mechanism of its domain. The packet is then

forwarded by the border router to the other end of the first path, assuming that the routers along the path are able to forward packets

by using PIDs. When the other end of the first path receives the packet, it strips out the PID of the first path, obtains the PID of the

second path, and forwards the packet to the border router towards the client. In this way, the packets of the desired content will be

sent to the client.

A

D1D3RM1

RM3

R1

R4R2

R5

P6

SID1CP4P5 P1P6

P5

dataIP2IP1

IP2

IP1(a)(b)

(c)

(a)

SID1CP4P5 P1P6 data(b)

SID1CP4P5 P1 dataMPLS LSP1(c)

SID1CP4P5 P1 data(d)

(d)

Fig. 2. Illustration for packet forwarding in CoLoR.

We now illustrate packet forwarding in CoLoR using Fig. 2, by assuming that domains D1 and D3 in Fig. 1 use IP and MPLS

for local routing, respectively. When node A receives the GET message, it firstly encapsulates the data with a header that contains

SID1, the client’s NID (i.e., C), and the PIDs. Since domain D1 uses IP for local routing, node A then encapsulates the packet with

an outer IP header whose source and destination addresses are IP2 and IP1, respectively, as illustrated in Fig. 2 (a). The packet will

be forwarded to node R1 by IP routing. R1 then strips out the outer IP header and sends the packet to path P6, as illustrated in Fig. 3

(b). When node R2 receives the packet, it encapsulates the packet with an outer MPLS header that contains the LSP between node

R2 and node R5 (i.e., LSP1), since domain D3 uses MPLS for local routing, as illustrated by Fig. 2 (c). When R5 receives the packet,

it strips out the MPLS header and sends the packet to path P5, as illustrated by Fig. 3 (d). In this way, the packet will ultimately be

sent to the client C.

From the above descriptions, one can see that CoLoR couples service location with inter-domain routing, but decouples them

from forwarding.

G. Content Caching

Since contents are assigned persistent and unique names, they can be cached by routers during the packet forwarding process.

In addition, to make the best usage of cached contents, a router should register its cached contents to its local RM so that the local

RM could forward subsequent GET messages for the cached contents to the router. In this way, CoLoR not only improves resource

utilization efficiency, but also reduces the delay for users to obtain contents. In addition, the caching and service registration

primitives make CoLoR efficient in supporting multicast and mobility.

III. IMPLEMENTATION

To validate the proposed design and also evaluate its performance, we built a Linux-based prototype of CoLoR using CLICK

[13], which is an open-source software platform. In this section, we first describe the prototype, followed by evaluation results from

the prototype.

A. Prototype Design

Fig. 3 shows the network topology of the prototype, which consists of two domains and 11 nodes, including one client, two

servers, two RMs, and six routers. The 11 nodes are placed in two domains, namely D1 and D2, with each domain has one server,

one RM, and three routers, as shown in Fig. 3. The client is placed at D1. D1 and D2 use IPv4 addresses and IPv6 addresses for

local routing, respectively. The two domains are connected by two paths: PID1 between node R3 in D1 and node R4 in D2, and PID2

between node R2 in D1 and node R5 in D2. All nodes are implemented using CLICK to perform their functionalities according to the

designs described in Sec. II. Since we do not use routing protocols to disseminate routing information, we manually configure

routing tables of all nodes, with the IP addresses of each node shown in Fig. 3. Similarly, the PID tables of all nodes are manually

configured for simplicity.

RM1 RM2

Client Server1 Server2

R1

R2

R3 R4

R5

R6

D1 D2

10.0.1.1

IP3

IP2

IP1IP4

10.0.3.1

10.0.3.2

IP2: 10.0.2.2

IP3: 10.0.5.1

IP4: 10.0.5.2

10.0.1.210.0.6.2

10.0.6.1

IP1: 10.0.2.1

IP10

IP0

2000:3000::2

2000:3000::1

2000:1000::1

2000:1000::2

2000:2000::1

IP9

IP5: 1000:4000::1

IP5

IP8

IP7IP6

IP6: 1000:4000::2

IP8: 1000:5000::2

IP7: 1000:5000::1

PID1

PID2

IP0: 10.0.4.1

IP10: 10.0.4.2

IP9: 2000:2000::2

Fig. 3: The topology of the prototype.

B. Experimental Results

We now present the experimental results obtained from the prototype. In our experimentation, we let every server register

50,000 SIDs with its local RM which then forwards the registration messages to the other RM. Thus, every RM stores 100,000 SID

entries. To reduce the traffic load of the client, the content corresponding to every SID is 1026 bytes so that each GET message is

replied by one data packet. The client then sends GET messages for SIDs randomly chosen from the 100,000 SIDs to RM1. The

intervals between subsequent GET messages follow the exponential distribution whose mean equals one millisecond (ms) and we

run the experiment for 1000 seconds. In addition, for contents provided by Server 2, RM1 chooses path PID1 with 70% probability

and path PID2 with 30% probability. We found that packets are forwarded as expected, which not only verifies the correctness of

the CoLoR design, but also demonstrates CoLoR’s feasibility in this small scale deployment. Although the performance from this

proof-of-concept implementation of CoLoR is not indicative of the performance in a large-scale deployment, studying the delay for

processing GET messages at RM1 enables us to gain better insight into CoLoR’s performance.

350 400 450 500 550 600 6500

0.02

0.04

0.06

0.08

0.1

0.12

0.14

The delay for processing GET messages at a RM1 (microseconds)

Th

e e

mp

iric

al p

rob

ab

ility

mean = 529 s

median = 426 s

Fig. 4: The delay for processing GET messages at RM1.

Fig. 4 shows the distribution of the delay for processing GET messages at RM1. From this figure, we observe that the processing

delay ranges from 0.35 to 0.65 ms, with its mean and median being 0.529 and 0.426 ms, respectively. Note that RMs use sequential

search to lookup an SID among 100,000 entries. Thus the processing delay could be significantly reduced if modern search

algorithms are used. For example, [2] assumes that a RH is able to process 40,000 GET messages, which implies that the delay for

processing a GET message will be 25 microseconds ( s ).

IV. OTHER FEATURES OF COLOR

From the above descriptions, it is clear that CoLoR is an information-centric Internet architecture and naturally encourages

innovations of network technologies. In this section, we describe how CoLoR satisfies the remaining design objectives.

A. Traffic Matrices Estimation

CoLoR makes it easy to accurately estimate traffic matrices in real time. Indeed, when an ingress border router receives a data

packet, it knows the egress border router by querying the inter-domain routing table. Accordingly, to estimate the traffic from the

ingress border router to the egress border router, the ingress border router only needs to 1) maintain a counter that records the

number of bytes (or packets) between the two border routers, and 2) count the number of bytes of the packet (or the packet) when

forwarding a packet. Note that these tasks can be done in real time and an accurate measure of the traffic matrix can be obtained.

To estimate the traffic matrices of a domain, we only need to let the routers in the domain 1) estimate the traffic matrix from the

router to other routers in the domain and 2) report the traffic matrices.

0 100 200 300 400 500 600 700 800 900 10000

100

200

300

400

500

600

700

800

900

1000

time (s)

rate

(p

k/s

)

R3 - R

1

R6 - R

4

R6 - R

5

R2 - R

1

Fig. 5: The traffic matrices estimated from the prototype.

Fig. 5 shows the estimated traffic matrices from node R3 to node R1, from node R2 to node R1, from node R6 to node R5, and

from node R6 to node R4 in our prototype. From Fig. 5, we observe that the traffic from node R3 to R1 is about 850 packets per

second, the traffic from node R6 to node R4 is about 350 packets per second, the traffic from node R2 to node R1 is about 150

packets per second, and the traffic from node R6 to node R5 is about 150 packets per second. Note that these numbers match with

the actual traffic matrices very well. For example, the actual traffic from node R6 to node R5 is 150 packets per second because the

number of GET messages sent to Server 2 is 500 per second and 30% of the replying data packets are sent to PID2. Similarly, the

actual traffic from node R6 to node R4 is 350 packets because the number of GET messages sent to Server 2 is 500 per second and

70% of the replying data packets are being sent to PID1. These results demonstrate the accuracy of CoLoR in estimating traffic

matrices.

B. Security

Security is achieved in CoLoR as follows. First, the use of self-certifying NIDs makes it efficient and effective to authenticate

the identity of a node without relying on an external authority. Second, the inter-domain PIDs are determined during the service

location process. This in turn makes it convenient to deploy mechanisms such as TVA [14] to defend against denial-of-service

(DoS) attacks, even if an attacker knows the PIDs toward the victim. Third, packet forwarding in CoLoR is intrinsically based on

loose source routing. However, since the PIDs are not advertised throughout the Internet, it is almost impossible for an attacker to

correctly guess the PIDs between two domains. Therefore, a malicious node can know the PIDs toward a victim only in one of the

following two cases. In one case, the GET message from the victim is forwarded to the malicious node. In the other case, the

malicious node is compromised by an attacker and learns the PIDs toward the victim from the attacker. In this case, however, the

malicious node must be in the same domain with the attacker since the PIDs from different domains to the victim are different,

which in turn makes it easy to trace the attacker. In both cases, we can use DoS defending mechanisms such as TVA to prevent the

victim from being attacked. A more detailed analysis on CoLoR’s security can be found in [15].

C. Mobility

Mobility in CoLoR follows naturally from its registration and the GET primitives. A mobile node holding a content can

unregister from a previous location and register with its new location. Once the necessary registration state is installed at the new

location, subsequent GET messages for the content will be routed to the new location. On the other hand, a mobile node requesting

a content could re-send a GET message for the content and the GET message will be routed to a nearby copy of the desired content,

possibly cached at a nearby router, due to the caching mechanism discussed above. In addition, the mobility within a domain could

be addressed by the mobility management approach of the domain.

For ongoing communications, when a consumer host roams from domain A to a neighboring domain B, domain A may

maintain a mobility anchor and the packets to the host are firstly routed to the anchor. When the anchor receives the packets

destined to the host, it then appends the PID between domain A and domain B, and forwards the packets to domain B in which the

host locates. On the other hand, when a source host roams from domain A to a neighboring domain B, the host is able to know the

PID(s) from domain A to domain B. Accordingly, when host A sends out a packet, it should firstly append one PID from domain A

to domain B onto the outer header of the packets. This way, the packets are firstly sent from domain B to domain A, and then

forwarded to the correspondent node.

D. Multi-homing

CoLoR supports multi-homing efficiently without affecting the scalability of the Internet. First, when a network A adds a

connection to another network B, the PIDs between the two networks are not advertised throughout the Internet. Therefore, the

inter-domain routing tables of other networks will not be affected. Second, it is true that the RM in network A may register some

SIDs to the RM in network B. However, this does not affect the scalability of the whole Internet since this does not increase the

number of SIDs that tier-1 networks need to deal with.

In addition, since packet forwarding across domains is based on paths, a multi-homed domain is able to control its incoming

traffic by forwarding GET messages to different providers. For example, for load balancing, the RM may forward some GET

messages to one provider domain, but forward the rest GET messages to the other provider domain. Further, the per-request nature

of GET messages makes it easy for multi-homed domains/hosts to realize fine-grained traffic engineering over incoming traffic,

thus making the best use of multi-homing. We have evaluated the effect of CoLoR’s capability in efficient support of traffic

engineering in our prototype. Fig. 6 shows the number of packets on path PID1 and path PID2. From this figure, we observe that the

number of packets traversing path PID1 is about 350 packets per second. On the other hand, the number of packets traversing path

PID2 is about 150 packets per second. This implies that CoLoR efficiently supports traffic engineering since, as described before,

RM1 chooses path PID1 with 70% probability and path PID2 with 30% probability when it forwards GET messages for contents

provided by Server 2.

0 100 200 300 400 500 600 700 800 900 10000

50

100

150

200

250

300

350

400

450

500

time (s)

rate

(p

k/s

)

PID2

PID1

Fig. 6: The number of packets on paths PID1 and PID2.

Note also that when a host has two interfaces connecting to two different networks A and B, the host can decide by itself to

which network a GET message should be forwarded so as to make the best usage of multi-homing. But when the host has decided

to forward a GET message to network A which has two provider networks, the RM in network A can decide where to forward the

GET message based on its local policy.

E. Scalability

The scalability of CoLoR is determined by two aspects: the routing table size and the huge number of SIDs that a tier-1

autonomous system (AS) needs to deal with.

1) Routing table size: A router in CoLoR maintains two routing tables: an intra-domain routing table and an inter-domain

routing table. Since domains in CoLoR are free to adopt their preferred routing mechanisms, we anticipate that the intra-domain

routing table size in a domain is well within the domain’s control. For the inter-domain routing table size, a router in a domain

maintains the paths that connect the domain to the domain’s parent/customer/peer domains. From [16], a domain (i.e., AS174) at

most has 4,060 neighbors as of Aug. 1, 2013. Therefore, even if two domains have ten PIDs, the inter-domain routing table size is

at most 40,600, which is significantly less than the current global routing table size (more than 480,000 as of Aug. 1, 2013).

2) Dealing with SIDs: In [2], it is shown that resource handlers (RHs) in DONA are capable of processing REGISTER

messages and FIND messages if DONA is deployed at the scale of the current Internet. Given the fact that DONA only caches

contents on RHs but CoLoR could cache contents on all nodes within a domain, we anticipate that a domain in CoLoR will cache

more contents than DONA, thus reducing the number of messages that a RM needs to process. Accordingly, the processing

overhead of RMs in CoLoR should be less than that of RHs in DONA. Furthermore, the authors in [17] pointed out that it is

possible to design a distributed hash table based name resolution system for 1016

flat SIDs, with an average resolution delay

below 100 ms. Therefore, CoLoR is feasible at the scale of the current Internet.

F. Deployment

We note that CoLoR may not be incrementally deployable as end hosts need to be updated in order to send registration and

GET messages. Nevertheless, the above analysis and implementation results demonstrate CoLoR’s ease of deployability. Since

CoLoR allows each network to use their chosen network architectures and routing mechanisms, existing networks are only required

to update their border routers and build a RM in order to accommodate CoLoR. Since the number of border routers in a network is

relatively small, most routers are not required to be updated, thus significantly reducing the cost in deploying CoLoR.

For CoLoR to interoperate with the current Internet, we considered two cases. In the first case, a single domain employs the

CoLoR architecture. In this case, we employ a proxy at the border of the domain and assign the domain a unique domain name, say

www.CoLoR.com. We then let the proxy register contents in the domain to the current Internet. Specifically, given a piece of

content with a name SID, we assign it a URL www.CoLoR.com/SID. In this way, the nodes in the current Internet can obtain the

content hosted in the domain. Similarly, when the nodes in the domain want to obtain the contents in the current Internet, we let the

nodes send the requests to the proxy that then obtains the contents from the current Internet. In the second case, several isolated

domains employ CoLoR. In this case, each of the domains can interoperate with the current Internet as stated above. On the other

hand, these domains can communicate with each other by using IP tunnels between border routers and each IP tunnel is viewed as a

virtual path represented by a PID in CoLoR.

V. SUMMARY AND FUTURE WORK

In this paper, we have presented CoLoR, an information-centric Internet architecture that satisfies many attractive features of

the future Internet, such as being information-centric, efficient support for mobility, traffic engineering, multi-homing, enhanced

security, and encouraging innovation. We have implemented CoLoR in a prototype and verified its feasibility.

While we have showed that CoLoR is promising and feasible, there are still many open questions. For example, one open

problem is how should the RM in a domain coordinate nodes in the domain in order to cache as many contents as possible. Another

question is, in the case where many provider/peer RMs could provide a desired content, how should a RM forward a GET message

for the desired content. In addition, since the RM in a domain processes registration/GET messages, an important question is how

to secure the RM and make it robust. Furthermore, how should two neighbor domains negotiate paths? Should two domains re-

negotiate paths to prevent attackers from collecting the paths between neighboring domains? If so, how to re-negotiate, and when?

Similarly, the hop-by-hop inter-domain path selection in CoLoR means that the routing path will follow the resolution tree, which

may cause path stretch. So, it is also interesting to investigate how large is the path stretch and how to avoid/reduce the path stretch.

These and other issues need to be addressed as future work.

Acknowledgements

We thank the anonymous reviewers for their invaluable comments that improve the paper. This work was supported in part by

the “973 Program” of China under Grant No. 2013CB329100, in part by NSFC under Grant Nos. 61271200, 61232017, in part by

the Ph.D. Programs Foundation of the Ministry of Education of China under Grant No. 20130009110014, in part by “NCET” under

Grant No. NCET-12-0767, and in part by the Fundamental Research Funds for the Central Universities under Grant No.

2014JBM011.

REFERENCES

[1] H. Balakrishnan, K. Lakshminarayanan, S. Ratnasamy, S. Shenker, I. Stoica, M. Walfish, “A layered naming architecture for the Internet,” In Proc.

SIGCOMM’04, Aug. 2004, Portland, Oregon, USA.

[2] T. Koponen, M. Chawla, B. – G. Chun, A. Ermolinskiy, K. H. Kim, S. Shenker, I. Stoica, “A data-oriented (and beyond) network architecture,” In Proc.

SIGCOMM’07, Aug. 2007, Kyoto, Japan.

[3] E. Nordstrom, D. Shue, P. Gopalan, R. Kiefer, M. Arye, S. Y. Ko, J. Rexford, M. J. Freedman, “Serval: an end-host stack for service-centric networking,”

in Proc. 9th USENIX Symposium on Networked System Design and Implementation (NSDI’12), April 2012, San Jose, CA, USA.

[4] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, R. L. Braynard, “Networking named content,” In Proc. ACM CoNEXT’09, Dec.

2009, Rome, Italy.

[5] G. Xylomenos, C. N. Ververidis, V. A. Siris, N. Fotiou, C. Tsilopoulos, X. Vasilakos, K. V. Katsaros, and G. Polyzos, “A survery of information-centric

networking research,” IEEE Communications Surveys and Turorials, to appear.

[6] T. Koponen, S. Shenker, H. Balakrishnan, N. Feamster, I. Ganichev, A. Ghodsi, P. B. Godfrey, N. McKeown, G. Parulkar, B. Raghavan, J. Rexford, S.

Arianfar, and D. Kuptsov, “Architecting for innovation,” ACM SIGCOMM CCR, vol. 41, no. 3, July 2011, pp. 24 – 26.

[7] J. Chuang, “Loci of competition for future Internet architecture,” IEEE Communications Magazine, vol. 49, no. 7, July 2011, pp. 38 – 43.

[8] D. Raychaudhuri, K. Nagaraja, A. Venkataramani, “MobilityFirst: a robust and trustworthy mobility-centric architecture for the future Internet,” ACM

Mobile Computing and Communications Review, vol. 16, no. 3, July 2012, pp. 2 – 13.

[9] H. Ballani, Y. Chawathe, S. Ratnasamy, T. Toscoe, and S, Shenker, “Off by default!” In Proc. ACM HotNets’05, Nov. 2005, College Park, Maryland, USA.

[10] H. Luo, H. Zhang, M. Zukerman, C. Qiao, “An incrementally deplyable network architecture to support both data-centric and host-centric services,” IEEE

Network Magazine, to appear in Nov. 2013.

[11] D. G. Andersen, H. Balakrishnan, N. Feamster, T. Koponen, D. Moon, and S. Shenker, “Accountable Internet protocol (AIP),” In Proc. SIGCOMM’08, Aug.

2008, Seattle, Washington, USA.

[12] P. B. Godfrey, I. Ganichev, S.Shenker, and I. Stoica, “Pathlet Routing,” In Proc. SIGCOMM’09, Aug. 2009, Barcelona, Spain.

[13] E. Kohler, R. Morris, B. Chen, J. Jannotti, and M. F. Kaashoek, “The Click modular router,” ACM Trans. Computer Systems, vol. 18, no. 3, Aug. 2000, pp.

263 – 297.

[14] X. Yang, D. Wetherall, T. Anderson, “TVA: a DoS-limiting network architecture,” IEEE/ACM Transactions on Networking, vol. 16, no. 6, Dec. 2008, pp.

1267 – 1280.

[15] Z. Chen, H. Luo, J. Cui, M. Jin, “Security analysis of a future Internet architecture,” in Proc. 8th Workshop on Secure Network Protocols (NPSec’13), Oct.

2013, Gottingen, Germany.

[16] BGP Peer Report. http://bgp.he.net/report/peers.

[17] C. Dannewitz, M. D’Ambrosio, V. Vercellone, “Hierarchical DHT-based name resolution for information-centric networks,” Computer Communications,

vol. 36, no. 7, April 2013, pp. 736 – 749.

Biographies

Hongbin Luo (SM06 – M07) is a professor at the School of Electronic and Information Engineering, Beijing Jiaotong University. He has authored more than 50 peer-reviewed papers in leading journals (such as IEEE/ACM Transactions on Networking) and conference proceedings. His research interests are in the areas of routing, Internet architecture, and optical networking. He is an editor of IEEE Communications Letters and a technical program committee member of many conferences.

Zhe Chen is a Ph. D. student at the School of Electronic and Information Engineering, Beijing Jiaotong University. His research interests are in the areas of information centric networking and software defined networking.

Jianbo Cui is a master student at the School of Electronic and Information Engineering, Beijing Jiaotong University. His research interests are in the areas of routing and software defined networking.

Hongke Zhang is a professor of the School of Electronic and Information Engineering, Beijing Jiaotong University. He has published more than 100 research papers in the areas of communications, computer networks and information theory. He is the author of eight books written in Chinese and the Chief Scientist of a National Basic Research Program of China.

Moshe Zukerman (M87 – S91 – F07) received his Ph.D. from the University of California, Los Angeles, in 1985. In 1986 - 1997, he was with the Telstra Research Laboratories and during 1997 - 2008, with The University of Melbourne, Australia. Since 2008, he is with City University of Hong Kong. He has also served on various journal editorial boards and conference technical program committees. His research interests include: performance analysis of telecommunications networks, network design and traffic engineering.

A B C

D1 D2

D3

D4

D5

D6

RM1

RM2

RM3

RM4

RM5

RM6

(i)

R1

R6

R2

R4

R2

R5

R10R9

R7

R8

R11

R12

(1)

P2P3

P1

P4

P6

P5

P7

P1 D5R7

P2 D5R7

P3 D5R7

P5 D3R6

PID DR

60

30

10

100

pref

(4)

(5)

(3)

(2)

(v)

(iv)

(ii)

(iii)

(vi)

(ii) SID1 C P4

(iii) SID1 C P4 (iv) SID1 C P4 P5P1P1

SID1 C(i)

(v) SID1 C P4 P5P1 P6

(vi) SID1 C P4 P5P1 P6

Fig. 1. Illustration for network topology and service registration in CoLoR.

A

D1D3RM1

RM3

R1

R4R2

R5

P6

SID1CP4P5 P1P6

P5

dataIP2IP1

IP2

IP1(a)(b)

(c)

(a)

SID1CP4P5 P1P6 data(b)

SID1CP4P5 P1 dataMPLS LSP1(c)

SID1CP4P5 P1 data(d)

(d)

Fig. 2. Illustration for packet forwarding in CoLoR.

RM1 RM2

Client Server1 Server2

R1

R2

R3 R4

R5

R6

D1 D2

10.0.1.1

IP3

IP2

IP1IP4

10.0.3.1

10.0.3.2

IP2: 10.0.2.2

IP3: 10.0.5.1

IP4: 10.0.5.2

10.0.1.210.0.6.2

10.0.6.1

IP1: 10.0.2.1

IP10

IP0

2000:3000::2

2000:3000::1

2000:1000::1

2000:1000::2

2000:2000::1

IP9

IP5: 1000:4000::1

IP5

IP8

IP7IP6

IP6: 1000:4000::2

IP8: 1000:5000::2

IP7: 1000:5000::1

PID1

PID2

IP0: 10.0.4.1

IP10: 10.0.4.2

IP9: 2000:2000::2

Fig. 3: The topology of the prototype.

350 400 450 500 550 600 6500

0.02

0.04

0.06

0.08

0.1

0.12

0.14

The delay for processing GET messages at a RM1 (microseconds)

Th

e e

mp

iric

al p

rob

ab

ility

mean = 529 s

median = 426 s

Fig. 4: The delay for processing GET messages at RM1.

0 100 200 300 400 500 600 700 800 900 10000

100

200

300

400

500

600

700

800

900

1000

time (s)

rate

(p

k/s

)

R3 - R

1

R6 - R

4

R6 - R

5

R2 - R

1

Fig. 5: The traffic matrices estimated from the prototype.

0 100 200 300 400 500 600 700 800 900 10000

50

100

150

200

250

300

350

400

450

500

time (s)

rate

(p

k/s

)

PID2

PID1

Fig. 6: The number of packets on paths PID1 and PID2.