CoLoR: An Information-Centric Internet Architecture for Innovation

Transcription

1 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 , China {hbluo, , , hkzhang}bjtu.edu.cn Moshe Zukerman Electronic Engineering Dept. City University of Hong Kong Hong Kong SAR, China Chunming Qiao Computer Sci. and Eng. Dept. University at Buffalo, SUNY Buffalo, NY ,USA 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.

2 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.

3 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 RM X. The relationships between RMs of domains are defined by the domain level relationships: namely, RM X is the provider, customer, or peer (or, alternatively, parent, child, or peer) of RM Y 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)

4 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. PID P1 P2 P3 R R7 R7 R7 D D5 D5 D5 pref D6 RM6 R7 P5 R6 D3 R2 R1 D3 100 R5 (v) (2) P5 (3) RM3 (5) R4 RM1 P7 R2 R6 (iv) R9 RM2 R8 P3 R10 P4 P1 P2 R11 (iii) RM5 D5 (ii) D1 (vi) R12 A (1) D2 D4 B (4) C (i) RM4 (i) SID1 C (vi) SID1 C P4 P1 P5 (ii) SID1 C P4 (v) SID1 C P4 P1 P5 (iii) SID1 C P4 P1 (iv) SID1 C P4 P1 P5 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

5 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 D 5 and D 6 in Fig. 1 negotiate three paths P 1, P 2, 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 (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 R 6 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 RM 3 receives the registration message for the SID from RM 1, 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., RM 6 ). When RM 6 receives the registration message, it then stores an entry for the SID in its registration table. When RM 3 receives a registration message for the SID from RM 2, it finds that there is an entry for the SID, but the registration message comes from RM 2 instead of RM 1. Thus, it adds an entry for the SID to its registration table. Note that now RM 3 does not send a registration message for the SID to RM 6, 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

6 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., RM 4 ). When RM 4 receives the GET message, it cannot find an entry for the SID. Accordingly, it appends path P 4 onto the GET message and sends the resulting message to its parent RM (i.e., RM 5 ). Similarly, RM 5 appends path P 1 (or P 2, P 3, depending on D 5 s local policy) onto the received GET message and sends the resulting 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 RM 6 is not in the same domain with RM 3, it appends path P 5 onto the received GET message and sends the resulting message to RM 3. Since RM 3 can find two entries for the SID, it chooses the entry pointing to domain D 1 based on its local policy, appends path P 6 onto the 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 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

7 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. R1 (d) P5 RM1 D1 (a) A IP1 IP2 (b) D3 R5 (c) R2 R4 RM3 (a) IP1 IP2 P5 P1 P4 C SID1 data (b) P5 P1 P4 C SID1 data (c) (d) MPLS LSP1 P5 P1 P4 C SID1 data P5 P1 P4 C SID1 data Fig. 2. Illustration for packet forwarding in CoLoR. We now illustrate packet forwarding in CoLoR using Fig. 2, by assuming that domains D 1 and D 3 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 SID 1, the client s NID (i.e., C), and the PIDs. Since domain D 1 uses IP for local routing, node A then encapsulates the packet with an outer IP header whose source and destination addresses are IP 2 and IP 1, respectively, as illustrated in Fig. 2 (a). The packet will be forwarded to node R 1 by IP routing. R 1 then strips out the outer IP header and sends the packet to path P 6, as illustrated in Fig. 3 (b). When node R 2 receives the packet, it encapsulates the packet with an outer MPLS header that contains the LSP between node R 2 and node R 5 (i.e., LSP 1 ), since domain D 3 uses MPLS for local routing, as illustrated by Fig. 2 (c). When R 5 receives the packet, it strips out the MPLS header and sends the packet to path P 5, 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.

8 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 D 1 and D 2, with each domain has one server, one RM, and three routers, as shown in Fig. 3. The client is placed at D 1. D 1 and D 2 use IPv4 addresses and IPv6 addresses for local routing, respectively. The two domains are connected by two paths: PID 1 between node R 3 in D 1 and node R 4 in D 2, and PID 2 between node R 2 in D 1 and node R 5 in D 2. 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. IP1: RM1 IP2: IP3: IP4: IP0: IP10: R2 IP0 D1 IP2 IP10 IP1 IP3 IP4 R3 R RM2 2000:1000::1 2000:1000::2 PID 2 PID 1 R5 2000:2000::1 D2 IP8 IP7 IP9 I R4 IP5 R6 2000:3000::1 2000:3000::2 Client Server1 Server2 IP5: 1000:4000::1 I: 1000:4000::2 IP7: 1000:5000::1 IP8: 1000:5000::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 RM 1. The

9 The empirical probability 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, RM 1 chooses path PID 1 with 70% probability and path PID 2 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 RM 1 enables us to gain better insight into CoLoR s performance mean = 529 s median = 426 s The delay for processing GET messages at a RM1 (microseconds) Fig. 4: The delay for processing GET messages at RM 1. Fig. 4 shows the distribution of the delay for processing GET messages at RM 1. From this figure, we observe that the processing delay ranges from 0.35 to 0.65 ms, with its mean and median being and 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

10 rate (pk/s) 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 R 3 - R R 6 - R R 6 - R R - R time (s) Fig. 5: The traffic matrices estimated from the prototype. Fig. 5 shows the estimated traffic matrices from node R 3 to node R 1, from node R 2 to node R 1, from node R 6 to node R 5, and from node R 6 to node R 4 in our prototype. From Fig. 5, we observe that the traffic from node R 3 to R 1 is about 850 packets per second, the traffic from node R 6 to node R 4 is about 350 packets per second, the traffic from node R 2 to node R 1 is about 150 packets per second, and the traffic from node R 6 to node R 5 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 R 6 to node R 5 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 PID 2. 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 per second and 70% of the replying data packets are being sent to PID 1. 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

11 (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.

12 rate (pk/s) 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 PID 1 and path PID 2. From this figure, we observe that the number of packets traversing path PID 1 is about 350 packets per second. On the other hand, the number of packets traversing path PID 2 is about 150 packets per second. This implies that CoLoR efficiently supports traffic engineering since, as described before, RM 1 chooses path PID 1 with 70% probability and path PID 2 with 30% probability when it forwards GET messages for contents provided by Server PID PID time (s) Fig. 6: The number of packets on paths PID 1 and PID 2. 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.

13 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, 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 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 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 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.

14 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 renegotiate 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 , , in part by the Ph.D. Programs Foundation of the Ministry of Education of China under Grant No , in part by NCET under Grant No. NCET , 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. 9 th 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.

15 [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 [7] J. Chuang, Loci of competition for future Internet architecture, IEEE Communications Magazine, vol. 49, no. 7, July 2011, pp [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 [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 [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 [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 [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. [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

16 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 In , he was with the Telstra Research Laboratories and during , 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.

17 PID P1 P2 P3 R R7 R7 R7 D D5 D5 D5 pref D6 RM6 R7 P5 R6 D3 R2 R1 D3 100 R5 (v) (2) P5 (3) RM3 (5) R4 RM1 P7 R2 R6 (iv) R9 RM2 R8 P3 R10 P4 P1 P2 R11 (iii) RM5 D5 (ii) D1 (vi) R12 A (1) D2 D4 B (4) C (i) RM4 (i) SID1 C (vi) SID1 C P4 P1 P5 (ii) SID1 C P4 (v) SID1 C P4 P1 P5 (iii) SID1 C P4 P1 (iv) SID1 C P4 P1 P5 Fig. 1. Illustration for network topology and service registration in CoLoR.

18 R1 (d) P5 RM1 D1 (a) A IP1 IP2 (b) D3 R5 (c) R2 R4 RM3 (a) IP1 IP2 P5 P1 P4 C SID1 data (b) P5 P1 P4 C SID1 data (c) (d) MPLS LSP1 P5 P1 P4 C SID1 data P5 P1 P4 C SID1 data Fig. 2. Illustration for packet forwarding in CoLoR.

19 IP1: IP5: 1000:4000::1 RM1 RM2 IP2: I: 1000:4000::2 IP3: IP7: 1000:5000::1 IP4: :1000::1 IP8: 1000:5000:: :1000::2 IP0: IP9: 2000:2000::2 IP10: PID R2 2 R5 2000:2000::1 IP0 D1 IP2 IP10 D2 IP8 IP9 IP1 IP7 IP3 IP4 I R3 PID 1 R4 IP5 R6 R :3000:: :3000::2 Client Server1 Server2 Fig. 3: The topology of the prototype.

20 The empirical probability mean = 529 s median = 426 s The delay for processing GET messages at a RM1 (microseconds) Fig. 4: The delay for processing GET messages at RM 1.

21 rate (pk/s) R 3 - R R 6 - R R 6 - R R - R time (s) Fig. 5: The traffic matrices estimated from the prototype.

22 rate (pk/s) PID PID time (s) Fig. 6: The number of packets on paths PID 1 and PID 2.