LUO_LAYOUT.

qxp_Layout 1 5/15/14 1:55 PM Page 4

CoLoR: An Information-Centric Internet

Architecture for Innovations
Hongbin Luo, Zhe Chen, Jianbo Cui, Hongke Zhang, Moshe Zukerman, and Chunming Qiao

Abstract
In this article, 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, includ-
ing being information-centric, encouraging innovations, and providing efficient sup-
port for mobility, multicast, multi-homing, and middleboxes.

T he Internet has achieved enormous success since its

inception. However, despite the rapid increase in the
number of users and applications, it faces many chal-
lenges, including poor scalability and security. Unfor-
tunately, these architectural deficiencies cannot be remedied
by incremental changes to the current Internet architecture.
Therefore, in recent years there has been an increasing
amount of effort in developing clean slate redesigns of the
Internet architecture, aimed at rectifying one or more of these
problems through non-incremental changes [15, references
therein]. For example, the authors of [24] aimed at designing
an information-centric Internet. The authors of [6, 7] argued
that a future Internet should be designed to encourage com-
petition and innovations. Raychaudhuri et al. [8] aimed at
designing an Internet that provides better support for mobility
and security.
In this article, we also pursue a clean slate Internet archi-
tecture, focusing on the following attributes, which constitute
the design objectives of the new architecture:
1. Information-centric: While the current Internet is host-cen-
tric (i.e., packets are sent to a specific hosts 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, con-
tents should be assigned names that are location-indepen-
dent 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 net-
works. It is difficult to efficiently support multi-homing in
the current Internet because it causes a serious routing scal-
ability problem. A future Internet architecture is expected
to support multi-homing more efficiently.
Hongbin Luo, Zhe Chen, Jianbo Cui, and Hongke Zhang are with Beijing
Jiaotong University.
Moshe Zukerman is with the City University of Hong Kong.
Chunming Qiao is with the State University of New York at Buffalo.
4. Encouraging innovations: The future Internet architecture
should allow each network to use its preferred network
architecture and routing mechanism so that different net-
work technologies can be simultaneously deployed and con-
tested, thus encouraging innovations.
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 than the current Internet. In par-
ticular, the routing table size should be significantly smaller
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 traf-
fic matrices are critical input to many aspects of network
management such as traffic engineering and network provi-
sioning, the future Internet should make it easy to accurate-
ly estimate traffic matrices in real time.
8. Deployability: Although we aim for a clean slate design, the
new architecture should be deployable without incurring
significant cost.
While many Internet architectures [18,10] have been pro-
posed in the past, none of them has achieved all the above men-
tioned design objectives. In this article, 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 exam-
ple, we borrow the idea of using self-certifying node identifiers
from MobilityFirst [8] and AIP [11]. From DONA [2], we bor-
row 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 experi-
ments carried on the prototype to demonstrate CoLoRs
feasibility in small-scale deployments.

4 0890-8044/14/$25.00 2014 IEEE IEEE Network May/June 2014

LUO_LAYOUT.qxp_Layout 1 5/15/14 1:55 PM Page 5
The remainder of the article is organized as follows. We
first describe the CoLoR architecture. We then report our
proof-of-concept prototype of CoLoR and explain how
CoLoR satisfies our design objectives. Finally, we conclude
the article and outline future work.
The CoLoR Architecture
We now describe the design details of the CoLoR architec-
ture. We begin with the network topology, naming, and rout-
ing. We then describe how to register services, how to locate
services, and how to determine inter-domain paths for ser-
vices. Finally, we describe how data packets are forwarded
and discuss how to cache services in CoLoR.
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 brevi-
ty, we denote a resource manager (RM) associated with a
domain X by RMX. The relationships between RMs of domains
are defined by domain-level relationships: 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 shown later,
an RM in CoLoR needs to choose path identifiers if there are
multiple path identifiers between two domains. On the con-
trary, an 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 configura-
tions, similar to the way in which an end host knows its local
domain name service (DNS) server in the Internet today.
Naming
Unlike the current Internet, which uses only one namespace
(i.e., IP address), CoLoR uses two global namespaces: service
identifiers (SIDs) and node identifiers (NIDs). To be informa-
tion-centric, CoLoR assigns every content a persistent and
unique SID that is application-independent and location-inde-
pendent. 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-certi-
fying 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, 11], NIDs in CoLoR are
flat self-certifying labels, so authenticating a node does not
require an external authority such as ICANN [8], thus improv-
ing 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. In
contrast, NIDs in CoLoR are not used for global routing, but
for authentication.
CoLoR also uses two local namespaces: intra-domain rout-
ing 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, 12], two
domains could negotiate the number of paths between them.
For a given path, its PID is also negotiated between the two
IEEE Network May/June 2014
domains, as long as the PID is unique in both domains.
Unlike [6, 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 antici-
pate 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.
Routing
In the current Internet, both inter-domain and intra-domain
routing rely on IP addresses. As a result, without global coor-
dination, 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 architec-
tures and intra-domain routing mechanisms, such as IPv4 and
IPv6, thus encouraging innovations 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 sup-
ports a method of bootstrapping 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 has
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 exam-
ple, domains D5 and D6 in Fig. 1 negotiate three paths, P1, P2,
and P 3, as indicated by the bold dashed lines in Fig. 1. The
two endpoints of P 1 are R 8 and R 7 located in D 5 and D 6 ,
respectively. For a path that begins at a domain, the RM and
the routers (which connect hosts or other domains) in the
domain maintains the paths endpoint located at the domain
and the domain identifier at which the other endpoint is locat-
ed. For example, the inter-domain routing table of R 6 is
shown in the upper left corner of Fig. 1.
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 informa-
tion 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 informa-
tion of SIDs may be similar to that of DONA [2] or CCN [4].
In this article, we use a mechanism similar to that in DONA.
In particular, a node holding a copy of a content registers the
contents SID to the RM in the same domain if it is autho-
rized to do so. Depending on the local policy, the RM may
also register the content to its parent/peer RMs. Figure 1
illustrates the registration process. When RM 3 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
5
LUO_LAYOUT.qxp_Layout 1 5/15/14 1:55 PM Page 6

PID R D Pref
RM6
P1 R7 D5 60
D6 RM finds at least one entry for the SID, it chooses
P2 R7 D5 30 R7 an entry based on its local policy (e.g., traffic engi-
neering). If the node contained in the entry is in the
P3 R7 D5 10
same domain as the RM, the RM directly forwards
P5 R6 D3 100 R6 the GET message to the node using the routing
P5 mechanism in that domain. If the node is in another
P1 (iii)
R8 domain, the RM chooses a path toward that domain
(3) RM5
R5 (iv) based on its local policy. Afterward, the RM appends
D3 RM3 the PID of the chosen path onto the GET message
(v) P2
R2 P3 and forwards the GET message to the node.
(5) Figure 1 illustrates how a GET message is for-
R10 D5 warded from a client to a node hosting the desired
R4 R9 content represented by an SID, assuming that the
P6 (2)
(ii) content has been registered as described earlier.
RM1 P7 R11 When node C wants the content, it sends a GET
R1 P4
R2 RM2 message to its local RM (i.e., RM 4 ). When RM 4
receives the GET message, it cannot find an entry
(vi) for the SID. Accordingly, it appends path P4 onto the
R12 (i)
D1 D2 GET message and sends the resulting message to its
D4
A (1) B C RM4 parent RM (i.e., RM5). Similarly, RM5 appends path
(4) P1 (or P2 or P3, depending on D5s local policy) onto
the received GET message and sends the resulting
(i) SID1 C (vi) SID1 C P4 P1 P5 P6 message to its parent RM (i.e., RM 6 ). When RM 6
receives the GET message, it finds an entry for the
SID in its registration table. Since RM6 is not in the
(ii) SID1 C P4 (v) SID1 C P4 P1 P5 P6
same domain with RM3, it appends path P5 onto the
received GET message and sends the resulting mes-
(iii) SID1 C P4 P1 (iv) SID1 C P4 P1 P5
sage to RM3. Since RM3 can find two entries for the
SID, it chooses the entry pointing to domain D 1
Figure 1. Illustration of network topology and service registration in based on its local policy, appends path P 6 onto the
CoLoR. received GET message, and sends the GET message
to RM 1 . When RM 1 receives the GET message, it
finds that a local node (i.e., node A) holds the
a registration message to its parent RM (i.e., RM 6 ). When desired content. Accordingly, it sends the GET message to
RM6 receives the registration message, it stores an entry for node A. For clarity, we show the GET messages in each step
the SID in its registration table. When RM3 receives a regis- at the bottom of Fig. 1.
tration message for the SID from RM2, it finds that there is an
entry for the SID, but the registration message comes from Packet Forwarding
RM2 instead of RM1. Thus, it adds an entry for the SID to its Once the source node storing the desired content receives the
registration table. Note that now RM3 does not send a regis- GET message, it knows the SID of the desired content, the
tration message for the SID to RM6, since it has registered the clients NID, and the inter-domain paths to be used to reach
SID already. the client. As a result, the source node encapsulates the pack-
ets of the content with a header that carries the clients NID,
Service Location and Inter-Domain Routing the SID, and the PIDs.
Recall that, for security, the PIDs between two domains are Recall that for every path that begins at a domain, the
not advertised to other domains. Accordingly, a content routers and the RM in the domain maintain the endpoint of
source cannot know the inter-domain paths to a content con- the path located at the domain and the domain identifier at
sumer, so it cannot send data packets to the consumer. To which the other endpoint is located. Accordingly, the source
address this issue, CoLoR determines the inter-domain paths node then sends the packets to the border router associated
during the service location process. In particular, when a with the first PID (or path) by using the routing mechanism of
client wants to obtain a content represented by an SID, it its domain. The packet is then forwarded by the border router
sends out a GET message to its local RM. The GET message to the other end of the first path, assuming that the routers
should contain the SID and the clients NID. If the RM can- along the path are able to forward packets by using PIDs.
not find an entry for the SID, it first chooses a parent RM When the other end of the first path receives the packet, it
based on its local policy and then chooses a PID destined to strips out the PID of the first path, obtains the PID of the
the corresponding parent domain. Note that when domain A second path, and forwards the packet to the border router
has multiple PIDs to domain B, it can choose which PID to toward the client. In this way, the packets of the desired con-
use based on its local policy. However, the best PID for tent are sent to the client.
domain A may not be the best one for domain B, since the We now illustrate packet forwarding in CoLoR using Fig. 2,
path from the ingress node (or the node holding the SID) to by assuming that domains D1 and D3 in Fig. 1 use IP and mul-
the egress node corresponding to the chosen PID in domain B tiprotocol label switching (MPLS) for local routing, respec-
may be congested. Therefore, it is necessary for the two tively. When node A receives the GET message, it first
domains to negotiate with each other in order to ensure the encapsulates the data with a header that contains SID1, the
best performance for both domains. However, how to nego- clients NID (i.e., C), and the PIDs. Since domain D1 uses IP
tiate is beyond the scope of this article. for local routing, node A then encapsulates the packet with an
The RM then appends the PID of the chosen path onto the outer IP header the source and destination addresses of which
GET message and sends it to the chosen parent RM. If the are IP 2 and IP 1 , respectively, as illustrated in Fig. 2a. The

6 IEEE Network May/June 2014

LUO_LAYOUT.qxp_Layout 1 5/15/14 1:55 PM Page 7

P5
R1 (d)
and PID 2 between node R 2 in D 1 and node R 5 in
(b) R5
IP1 D 2 . All nodes are implemented using CLICK to
RM1 (a) D3 (c)
D1 perform their functionalities according to the
RM3
A
designs described earlier. Since we do not use
IP2 P6 R2
R4 routing protocols to disseminate routing informa-
tion, we manually configure routing tables of all
nodes; the IP addresses of each node are shown in
(a) IP1 IP2 P6 P5 P1 P4 C SID1 Data Fig. 3. Similarly, the PID tables of all nodes are
manually configured for simplicity.
(b) P6 P5 P1 P4 C SID1 Data
Experimental Results
We now present the experimental results obtained
(c) MPLS LSP1 P5 P1 P4 C SID1 Data
with the prototype. In our experimentation, we let
every server register 50,000 SIDs with its local RM,
(d) P5 P1 P4 C SID1 Data which then forwards the registration messages to
the other RM. Thus, every RM stores 100,000 SID
Figure 2. Illustration of packet forwarding in CoLoR. entries. To reduce the traffic load of the client, the
content corresponding to every SID is 1024 bytes,
so each GET message is replied to by one data
packet. The client then sends GET messages for
packet will be forwarded to node R 1 by IP routing. R 1 then SIDs randomly chosen from the 100,000 SIDs to RM 1. The
strips out the outer IP header and sends the packet to path intervals between subsequent GET messages follow the expo-
P6, as illustrated in Fig. 2. When node R2 receives the packet, nential distribution the mean of which equals 1 ms, and we
it encapsulates the packet with an outer MPLS header that run the experiment for 1000 s. In addition, for contents pro-
contains the LSP between node R 2 and node R 5 (i.e., label vided by server 2, RM 1 chooses path PID 1 with 70 percent
switching path 1 LSP1), since domain D 3 uses MPLS for probability and path PID 2 with 30 percent probability. We
local routing, as illustrated by Fig. 2c. When R5 receives the find that packets are forwarded as expected, which not only
packet, it strips out the MPLS header and sends the packet to verifies the correctness of the CoLoR design, but also demon-
path P5, as illustrated by Fig. 2. In this way, the packet is ulti- strates CoLoRs feasibility in this small-scale deployment.
mately sent to the client, C. Although the performance from this proof-of-concept imple-
From the above descriptions, one can see that CoLoR cou- mentation of CoLoR is not indicative of the performance in a
ples service location with inter-domain routing, but decouples large-scale deployment, studying the delay for processing
them from forwarding. GET messages at RM1 enables us to gain better insight into
CoLoRs performance.
Content Caching Figure 4 shows the distribution of the delay for processing
Since contents are assigned persistent and unique names, they GET messages at RM1. From this figure, we observe that the
can be cached by routers during the packet forwarding pro- processing delay ranges from 0.35 to 0.65 ms, with its mean
cess. In addition, to make the best usage of cached contents, a and median being 0.529 and 0.426 ms, respectively. Note that
router should register its cached contents to its local RM so RMs use sequential search to look up an SID among 100,000
that the local RM can forward subsequent GET messages for entries. Thus, the processing delay could be significantly
the cached contents to the router. In this way, CoLoR not reduced if modern search algorithms are used. For example,
only improves resource utilization efficiency, but also reduces [2] assumes that an RH is able to process 40,000 GET mes-
the delay for users to obtain contents. In addition,
the caching and service registration primitives
make CoLoR efficient in supporting multicast and
mobility. RM1 RM2
IP5: 1000.4000::1
IP1: 10.0.2.1 IP6: 1000.4000::2
Implementation IP2: 10.0.2.2
IP3: 10.0.5.1
10.0.3.2 2000:1000::1 IP7: 1000.5000::1
2000:1000::2 IP8: 1000.5000::2
To validate the proposed design and also evaluate IP4: 10.0.5.2 10.0.3.1 IP9: 2000.2000::2
IP0: 10.0.4.1
its performance, we built a Linux-based prototype IP10: 10.0.4.2
of CoLoR using CLICK [13], which is an open R2 PID2 R5 2000:2000::1
source software platform. In this section, we first IP0
describe the prototype, followed by evaluation IP2 IP8
D1 D2
IP10 IP9
results from the prototype. IP1 IP7
IP4 IP6
Prototype Design IP3
R3 PID1 R4 IP5 R6
Figure 3 shows the network topology of the proto- R1
type, which consists of two domains and 11 nodes, 10.0.6.2 2000:3000::1
10.0.1.2
including one client, two servers, two RMs, and six
routers. The 11 nodes are placed in two domains, 10.0.1.1 10.0.6.1 2000:3000::2
D 1 and D 2; and each domain has one server, one
RM, and three routers, as shown in Fig. 3. The
Client Server1 Server2
client is placed at D1. D1 and D2 use IPv4 address-
es and IPv6 addresses for local routing, respective-
ly. The two domains are connected by two paths:
PID 1 between node R 3 in D 1 and node R 4 in D 2 , Figure 3. The topology of the prototype.

IEEE Network May/June 2014 7

LUO_LAYOUT.qxp_Layout 1 5/15/14 1:55 PM Page 8
0.14
0.12
0.1
The empirical probability
0.08
0.06
0.04
0.02
0 tised throughout the Internet, it is almost impos-
350 400 450
The delay for processing GET messages at an RM1 (s)
Figure 4. The delay in processing GET messages at RM1.
sages, which implies that the delay for processing a GET mes-
sage will be 25 ms.
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 sec-
tion, we describe how CoLoR satisfies the remaining design
objectives.
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:
Maintain a counter that records the number of bytes (or
packets) between the two border routers
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 accu-
rate measure of the traffic matrix can be obtained. To esti-
mate the traffic matrices of a domain, we only need to let the
routers in the domain:
Estimate the traffic matrix from the router to other routers
in the domain
Report the traffic matrices
Figure 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/s, the traffic from node R 6 to node R 4 is about 350
packets/s, the traffic from node R 2 to node R 1 is about 150
packets/s, and the traffic from node R 6 to node R 5 is about
150 packets/s. Note that these numbers match with the actual
traffic matrices very well. For example, the actual traffic from
node R 6 to node R 5 is 150 packets/s because the number of
GET messages sent to server 2 is 500/s, and 30 percent of the
replying data packets are sent to PID2. Similarly, the actual
traffic from node R 6 to node R 4 is 350 packets because the
number of GET messages sent to server 2 is 500/s, and 70
percent of the replying data packets are being sent to PID1.
8 IEEE Network May/June 2014
Mean = 529 s
Median = 426 s
These results demonstrate the accuracy of CoLoR
in estimating traffic matrices.
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
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 adver-
500 550 600 650
sible 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 differ-
ent, which in turn makes it easy to trace the attacker. In both
cases, we can use DoS defense mechanisms such as TVA to
prevent the victim from being attacked. A more detailed anal-
ysis of CoLoRs security can be found in [15].
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 mes-
sage for the content, and the GET message is routed to a
nearby copy of the desired content, possibly cached at a near-
by 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
first routed to the anchor. When the anchor receives the pack-
ets 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 is located. 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 first
append one PID from domain A to domain B onto the outer
header of the packets. This way, the packets are first sent
from domain B to domain A and then forwarded to the corre-
sponding node.
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. There-
fore, the inter-domain routing tables of other networks are
not affected. Second, it is true that the RM in network A may
LUO_LAYOUT.qxp_Layout 1 5/15/14 1:55 PM Page 9

1000

900
register some SIDs to the RM in network B. How-
ever, this does not affect the scalability of the whole 800
Internet since this does not increase the number of R3R1
SIDs with which tier 1 networks need to deal. 700
In addition, since packet forwarding across

Rate (packets/s)
domains is based on paths, a multi-homed domain 600
R6R4
is able to control its incoming traffic by forwarding
500
GET messages to different providers. For example,
for load balancing, the RM may forward some 400
GET messages to one provider domain, but for-
ward the rest of the GET messages to the other 300
R6R5
provider domain. Furthermore, the per-request
nature of GET messages makes it easy for multi- 200
homed domains/hosts to realize fine-grained traffic
100
engineering over incoming traffic, thus making the
R2R1
best use of multi-homing. We have evaluated the 0
effect of CoLoRs ability to efficiently support traf- 0 100 200 300 400 500 600 700 800 900 1000
fic engineering in our prototype. Figure 6 shows the Time (s)
number of packets on paths PID1 and PID2. From
this figure, we observe that the number of packets Figure 5. The traffic matrices estimated from the prototype.
traversing path PID1 is about 350 packets/s. On the
other hand, the number of packets traversing path
PID 2 is about 150 packets/s. This implies that
CoLoR efficiently supports traffic engineering 500
since, as described before, RM1 chooses path PID1
with 70 percent probability and path PID2 with 30 450
percent probability when it forwards GET messages
400
for contents provided by server 2.
Note also that when a host has two interfaces 350
connecting to two different networks, A and B, the
Rate (packets/s)

host can decide by itself to which network a GET 300

message should be forwarded so as to make the
best usage of multi-homing. However, when the
host has decided to forward a GET message to net-
work A, which has two provider networks, the RM
in network A can decide where to forward the GET
message based on its local policy.
Scalability
The scalability of CoLoR is determined by two 50
aspects: the routing table size and the huge number
0
of SIDs with which a tier 1 autonomous system
(AS) must handle.
1) Routing table size: A router in CoLoR main-
tains two routing tables: an intra-domain routing
Figure 6. The number of packets on paths PID1 and PID2.
table and an inter-domain routing table. Since
domains in CoLoR are free to adopt their pre-
ferred routing mechanisms, we anticipate that the
intra-domain routing table size in a domain is well within the
domains control. For the inter-domain routing table size, a
router in a domain maintains the paths that connect the
domain to the domains parent/customer/peer domains. From
[16], a domain (i.e., AS174) had at most 4060 neighbors as of
August 1, 2013. Therefore, even if two domains have 10 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 August 1, 2013).
2) Dealing with SIDs: In [2], it is shown that resource han-
dlers (RHs) in DONA are capable of processing REGISTER
and FIND messages if DONA is deployed at the scale of the
current Internet. Given the fact that DONA only caches con-
tents on RHs, but CoLoR can 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 an 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]
PID1
250
200
150
100
PID2
0 100 200 300 400 500 600 700 800 900 1000
Time (s)
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.
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 CoLoRs ease of deploya-
bility. Since CoLoR allows each network to use their chosen
network architectures and routing mechanisms, existing net-
works are only required to update their border routers and
build an 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 of deploying CoLoR.
For CoLoR to interoperate with the current Internet, we
considered two cases. In the first case, a single domain

IEEE Network May/June 2014 9

LUO_LAYOUT.qxp_Layout 1 5/15/14 1:55 PM Page 10
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, which then obtains the con-
tents 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.
Summary and Future Work
In this article, we have presented CoLoR, an information-cen-
tric Internet architecture that satisfies many attractive features
of the future Internet, such as being information-centric, effi-
cient support for mobility, traffic engineering, multi-homing,
enhanced security, and innovation encouragement. We have
implemented CoLoR in a prototype and verified its feasibility.
While we have shown that CoLoR is promising and feasi-
ble, 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 an RM forward a GET message for the desired con-
tent. In addition, since the RM in a domain processes regis-
tration/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 should they be re-
negotiated, and when? Similarly, the hop-by-hop inter-domain
path selection in CoLoR means that the routing path will fol-
low the resolution tree, which may cause path stretch. Hence,
it is also interesting to investigate how large the path stretch is
and how to avoid/reduce the path stretch. These and other
issues need to be addressed as future work.
Acknowledgments
We thank the anonymous reviewers for their invaluable com-
ments that have improved the article. This work was support-
ed in part by the 973 Program of China under Grant No.
2013CB329100, in part by NSFC under Grant Nos. 61271200,
and 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 et al., A Layered Naming Architecture for the Internet,
Proc. SIGCOMM 04, Aug. 2004, Portland, OR.
[2] T. Koponen et al., A Data-Oriented (and Beyond) Network Architecture,
Proc. SIGCOMM 07, Aug. 2007, Kyoto, Japan.
[3] E. Nordstrom et al., Serval: An End-Host Stack for Service-Centric Net-
working, Proc. 9th USENIX Symp. Networked System Design and Imple-
mentation, Apr. 2012, San Jose, CA.
[4] V. Jacobson et al., Networking Named Content, Proc. ACM CoNEXT
09, Dec. 2009, Rome, Italy.
[5] G. Xylomenos et al. , A Survery of Information-Centric Networking
Research, to appear, IEEE Commun. Surveys and Turorials.
10
[6] T. Koponen et al., Architecting for Innovation, ACM SIGCOMM CCR,
vol. 41, no. 3, July 2011, pp. 2426.
[7] J. Chuang, Loci of Competition for Future Internet Architecture, IEEE
Commun. Mag., vol. 49, no. 7, July 2011, pp. 3843.
[8] D. Raychaudhuri, K. Nagaraja, and A. Venkataramani, MobilityFirst: A
Robust And Trustworthy Mobility-Centric Architecture for the Future Inter-
net, ACM Mobile Computing and Commun. Rev. , vol. 16, no. 3, July
2012, pp. 213.
[9] H. Ballani et al., Off by Default!, Proc. ACM HotNets05, Nov. 2005,
College Park, MD.
[10] H. Luo et al., An Incrementally Deployable Network Architecture to Support
Both Data-Centric and Host-Centric Services, IEEE Network, Nov. 2013.
[11] D. G. Andersen et al., Accountable Internet Protocol (AIP), Proc. SIG-
COMM 08, Aug. 2008, Seattle, WA.
[12] P. B. Godfrey et al. , Pathlet Routing, Proc. SIGCOMM 09 , Aug.
2009, Barcelona, Spain.
[13] E. Kohler et al., The Click Modular Router, ACM Trans. Computer Sys-
tems, vol. 18, no. 3, Aug. 2000, pp. 26397.
[14] X. Yang, D. Wetherall, and T. Anderson, TVA: A DoS-Limiting Network Archi-
tecture, IEEE/ACM Trans. Net., vol. 16, no. 6, Dec. 2008, pp. 126780.
[15] Z. Chen et al., Security Analysis of a Future Internet Architecture, Proc.
8th Wksp. Secure Network Protocolsa, Oct. 2013, Gottingen, Germany.
[16] BGP Peer Report, http://bgp.he.net/report/peers.
[17] C. Dannewitz, M. DAmbrosio, and V. Vercellone, Hierarchical DHT-
Based Name Resolution for information-Centric Networks, Computer
Commun., vol. 36, no. 7, Apr. 2013, pp. 73649.
Biographies
HONGBIN LUO [SM06, M07] (hbluo@bjtu.edu.cn) 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 has been a
Technical Program Committee member of many conferences.
ZHE CHEN (11120069@bjtu.edu.cn) is a Ph.D. student at the School of Elec-
tronic and Information Engineering, Beijing Jiaotong University. His research
interests are in the areas of information-centric networking and software
defined networking.
JIANBO CUI (12120053@bjtu.edu.cn) is a Masters student at the School of
Electronic and Information Engineering, Beijing Jiaotong University. His
research interests are in the areas of routing and software defined net-
working.
HONGKE ZHANG (hkzhang@bjtu.edu.cn) is a professor of the School of Elec-
tronic and Information Engineering, Beijing Jiaotong University. He has pub-
lished 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 is Chief Scientist of a National Basic Research Pro-
gram of China.
MOSHE ZUKERMAN [M87, S91, F07] (m.zu@cityu.edu.hk) received his Ph.D.
from the University of California, Los Angeles, in 1985. In 19861997, he
was with Telstra Research Laboratories and during 19972008 with the Uni-
versity of Melbourne, Australia. Since 2008, he has been with the City Univer-
sity 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.
CHUNMING QIAO [f09] (qiao@computer.org) is a professor with the State Uni-
versity of New York, Buffalo, where he directs the Laboratory for Advanced
Network Design, Analysis, and Research, which conducts cutting-edge
research work on optical networks, wireless and mobile networks, survivable
networks, and TCP/IP technologies. He has published more than 80 and 120
papers in leading technical journals and conference proceedings, respectively.
His pioneering research on optical Internet, in particular the optical burst
switching paradigm, is internationally acclaimed. In addition, his work on inte-
grated cellular and ad hoc relaying systems, started in 1999, is recognized
as the harbinger for todays push toward the convergence between heteroge-
neous wireless technologies, and has been featured in BusinessWeek and
Wireless Europe, as well as on the websites of New Scientists and CBC. He
has given several keynotes, tutorials, and invited talks on the above research
topics. He has chaired and co-chaired a dozen international conferences and
workshops. He has been an editor of IEEE Transactions on Networking and a
Guest Editor for several IEEE Journal on Selected Areas in Communications
issues, as well as Chair of the IEEE Technical Committee on High Speed Net-
works. Currently, he is on the editorial boards of several journals and maga-
zines, including IEEE Transactions on Parallel and Distributed Systems, and
chairs the IEEE Subcommittee on Integrated Fiber and Wireless Technologies
(FiWi), which he founded.
IEEE Network May/June 2014