SIONA: A Service and Information Oriented Network Architecture

Transcription

1 SIONA: A Service and Information Oriented Network Architecture Zhongxing Ming, Dan Li, Chunmei Xia, Mingwei Xu Department of Computer Science and Technology Tsinghua University Beijing China {mingzhongxing, lidan, xiachunmei, xmw}@csnet1.cs.tsinghua.edu.cn ABSTRACT The Internet is a great hit in human history. However, it has evolved greatly from its original incarnation. Content distribution is playing a central role in today s Internet, which makes it difficult for the conventional host-to-host communication to meet the enormous demands. In this paper, we present SIONA as a service and information oriented network architecture. The key aspect of SIONA is the name-based paradigm that provides scalable routing, caching and transformation for service and information. SIONA not only provides scalable content distribution, but solves the Internet problems with naturally supporting multicast and provides innovative network layer P2P for massive data distribution as well. SIONA also inherently supports host mobility and multihoming. SIONA is designed to be compatible with IP and can be incrementally deployed in today s Internet. 1. INTRODUCTION The IP network has achieved tremendous success, with billions of people connecting to the Internet every day. However, the demand of people has significantly changed since IP was born. The conventional host-to-host communication model of IP network has become less and less important in people s lives. People now focus on what they want, e.g., a film, much more than where they get it. It is believed that service and information are customers basic demand. Today s Internet focuses on nodes, while future Internet will focus on service and information [9, 5, 20, 4, 14, 6, 15, 19, 7, 3, 8, 16, 17, 18]. Many believe that the traditional address-based network is evolving to an information centric network (ICN). To adapt to this tideway, architecture innovation is required to support highly scalable and efficient content distribution. The information centric network has produced plenty of results in the international Future Internet research activities. Triad [1] proposes to explicitly include a content layer in the routing architecture to provide content routing, caching and content transformation. DONA [2] builds on Triad s name-based routing, but uses flat, self-certifying names. DONA also extends Triad s RH functionality and takes consideration of administrative access policies. [10, 12] discusses content-based routing in multicast and P2P networks. Carzaniga and Hall consider the foundations of content-based network, and present a vision for further research as well as for the practical realization of a contentbased network. NDN (originally called CCN) [5, 16, 17] proposes an entirely new architecture, which builds a universal overlay for content-centric network, in which communication is driven by receiving end. Jacobson et al [21] evaluate the performance of NDN (CCN) by implementing a Voice over IP (VoIP) application in a content based paradigm. In this paper, we propose SIONA, a Service and Information Oriented Network Architecture. Our design is based on the observation that service and information play a central role in today s Internet. Information is viewed as static data, for example, a video file. Service means the activities that are to meet the customer s demand, which can be either the transmission of static data, e.g., FTP, or some computational activities that interact with the customer s input, such as electronic payment via ebay. The key aspect of SIONA is the service and information oriented name-based paradigm. In SIONA, service and information are identified by names. The servers, who provide service or information, register themselves to the network. A receiver achieves what he/she wants by sending request packets to the network, which carry the names of service and information. The request is automatically satisfied by the network and the receiver needn t know where he/she gets the service and information. Assigning each service and information a name will produce a large namespace which is much bigger than today s IP space. Names are not as aggregate as IP, as they are absolutely ISP independent. To provide good scalability, SIONA preserves IP and makes IP be part of SIONA s name structure. Several research results, such as Virtual Aggregation (VA) [24] and LISP [23], are believed to be promising solutions for IP s scalable routing problem. By using IP, we can take advantage of these solutions to achieve good scalability. Preserving IP also provides compatibility and better performance for traditional applications such as Telnet, which allows receivers to connect to a particular destination by explicitly specifying an IP address. We claim that SIONA not only provides scalable content distribution, but also solves the Internet problems by naturally supporting multicast and provides innovative solutions to massive data distribution by implementing a network layer P2P mechanism. Host mobility and multihoming are inherently supported by SIONA. SIONA

2 is designed to be compatible with IP and can be incrementally deployed in today s Internet. The rest of this paper is organized as follows. Section 2 presents SIONA s basic design. Section 3 shows how this design supports such tasks as data caching, multi-source multicast and network layer P2P. Section 4 describes how mobility and multihoming can be improved by SIONA. Section 5 gives the simulation results of our caching mechanism. Section 6 compares our work with CCN/NDN. Finally, section 7 presents our conclusion and future work. 2. SIONA Architecture Communication in SIONA is driven by service and information, which are identified by names. SIONA names are organized by Data Names and Attributes (figure 1). Data names are globally unique, which identify service and information. Attributes describe the properties of the service and information, which can be used to accelerate data delivery (section 4.2 and 4.3 present the detail). Routing and forwarding in SIONA is based on four tables which are maintained by SIONA routers: Registration Table (RT), Request Interface Table (RIT), Data Store (DS) and Forwarding Information Base (FIB). RT is used to keep registration information, which records who has the service and information. RIT is used to remember interfaces of requests which have been forwarded but are still waiting for matching Data. SIONA router provides caching functionality and the DS is used to keep cached data. FIB is used to forward packets based on the existing IP network. While having RT and RIT make SIONA look like CCN/NDN [5, 16, 17], they are actually not the same. Section 6 discusses the connection and differences between SIONA and CCN/NDN. To populate service and information, servers register their services and information to SIONA routers by sending registration packets. SIONA routers keep the registration information in their RTs. To receive service and information, end nodes send out request packets, which carry the service and information s name. SIONA routers remember the interface from which the requests come, and forward the request based on their RTs and FIBs. Once the request reaches a node which has the data, a data packet will be sent, which traces the reverse path created by the request packet back to the end node. When data packets come, SIONA routers forward the packets to all the interfaces which match the name in its RIT and delete the entry of the request. Along the path, SIONA routers cache the data in their DS. Following request which carry the same name will likely pull the data from a nearby cache, which minimizes the delay and bandwidth consumption. Figure 2 illustrates the above logic. In section 2.4, we will explain how routing and forwarding is done in more detail. SIONA inherently supports multicast, especially multisource multicast (section 4.2). The process of forwarding a request packet is the process of establishing a multicast group as well. When a receiving end sends a request to the network, it automatically joins in a group which all the SIONA routers have the same request entry in their RITs. A substantial improvement of SIONA on traditional IP network is that SIONA naturally implements network layer P2P. In SIONA, service and information can be achieved from all possible sources (both servers and SIONA routers) rather than a single server. Figure 1. SIONA name structure The name-based paradigm also enables SIONA to inherently support host mobility and multihoming, which have always been a tender spot of today s Internet. In the following sections we will describe each major element of SIONA architecture. 2.1 Naming Scheme The key aspect of SIONA is the name-based paradigm, which provides identification, routing, caching and transformation for service and information. A SIONA name consists of data name and attributes (Figure 1). Data name is of the form of P (IP) : S (Service) : I (Information). P is the IP address of the service or information. S is a service indicator that specifies a certain kind of service, e.g., HTTP and PayPal. I is the hash of the information data. In the P : S : I structure, P is optional but S and I must be provided. The attributes contain three parts: O (Offset), L (Length) and F (Flag). O indicates the distance from the beginning of the data to the current data block, which is in term of byte. L is the length of the data block. The existence of O and L makes it possible for SIONA routers to achieve distributed information storage and multi-source multicast transmission (section 4.2 and section 4.3 illustrate the detail). F is a flag bit which indicates whether P is set in P : S : I structure. In SIONA, service and information can be achieved from a specified location, but not necessarily to be so. Users can set P to choose a particular source, or leave P unset to get service and information from any source. In the former case, F is set to be 1, while in the latter case, F is set to be Name Resolution SIONA s name based paradigm requires end users know the service and information s name. SIONA does not take the responsibility of providing a universal name resolution system. Names can be got in a similar fashion to today s Internet. For example, before downloading a video, an end user can first use the search engine, e.g. google, to get the name of the video, and then sends request packets to get it.

3 gracefully travels a reverse path to reach the destination and a multicast delivery is inherently implemented. Figure 2. SIONA architecture 2.3 SIONA Packets Three types of packets are defined in SIONA architecture: register packet, request packet and data packet. While these three packets perform different functions, they have two fields in common: Name: Identifier of service and information, including data name and attributes Options: Field that carries additional information, such as the IP address of the node who generates the packet. Register packet is used by servers to register service and information to the network. Register packet can be forwarded among SIONA routers to propagate registration information within the same domain. Some BGP-like routing protocol(s) can be invited to do the inter-domain registration propagation. The details of such protocols are beyond the scope of this paper. Request packet is sent by end users to pull service and information from the SIONA network. A selector field is used to define the properties of the Request packet, for example, priority, preference, etc. A request packet can be decomposed into several sub-requests using length (L) and Offset (O), and forwarded to SIONA network to get service and information from multiple sources in parallel. The decomposing policy is beyond the scope of this paper. Data packet is the reply of the request packet, which carries the required data. A time-to-live (TTL) field in is used data packet to decide how long it will be cached in SIONA routers (section 3.1 shows the detail). 2.4 Routing and Forwarding SIONA is a name-based model that extends IP. The routing and forwarding functionality is performed by Routing and Forwarding Engine (RFE). Figure 3 shows the RFE Constructing Reverse Path Upon receiving a request packet, the router stores the request in its RIT, where each entry contains the name of the request as well as the request s coming interface. Different interfaces with the same request name are stored in the same RIT entry. When data packet arrives, the RFE checks which entry matches the data s name and forwards the data to all the interfaces in that entry. In this way, data Figure 3. Routing and forwarding engine The RIT entries are indexed by S and I, which means P is not included in a RIT entry. Each RIT entry is assigned with a Time to Live (TTL) value, which means how long the entry can be held by the RIT. Longer TTLs can be assigned to the entries which represent popular data. An entry is removed from the RIT if either of the following events happens: Data arrives and is disseminated to all the interfaces listed in that entry. The TTL of that entry expires. Figure 4 shows the process of establishing a reverse path. The idea of RIT learns from CCN/NDN. Figure 4. Constructing a reverse path Packet Transmission with P As is described in section 2.1, In the P : S : I structure, P is optional but S and I must be provided. When P is specified in a request packet, the consumer means that he/she wants to get information or service from a particular source. In such scenarios, the consumer must fill the Options filed (Section 2.4 describes the detail) of the request packet with its own IP address. The request packet is routed based on the FIBs of SIONA routers. The FIB of a SIONA router acts in the same fashion as that of IP routers, which forwards the packet using the longest match paradigm. The request packet travels through the network as it were an IP packet. Upon receiving the request, the server can extract the consumer s address from the Options field and decide whether to set a P in the data packet. If P is specified, the data will only be sent to the consumer who generates the request, which means the SIONA routers won t use the RIT to disseminate the data. Otherwise, each SIONA router will check its RIT to

4 forward the data to all the interfaces which are listed in the RIT entry whose index is the data s S and I. Conventional routing protocols, such as OSPF and BGP, can be adopted to construct SIONA s FIB Packet Transmission without P When P is not specified, the RT is used to forward the packets based on S and I Upon receiving a request packet of which the service is to get some static information, e.g., a web page, the SIONA router first checks its DS to see if the desired data has already been cached. If so, a data packet will be sent back and the request processing logic is finished. Otherwise, the request packet is passed to RT and decomposed into slices subject to routing and transmission policy. By decomposing request, we can take advantage of SIONA s multi-source multicast and network layer P2P to accelerate the speed of getting data, which will be explained in section 3.2 and 3.3. After being decomposed, the request slices are added into the RIT and the reverse data path is established. Finally, the SIONA router forwards the request slices, which appears as normal request packets from the view of other SIONA routers. If the consumer is requesting a service that requires the consumer s input, for instance an electronic payment, things become more complicated because there is no data before the input is provided. To handle this, the consumer sends a request packet to find the server by specifying S in the name field. With P left to be unset, the consumer means to use any server which provides the desired service. When receiving the request packet, the server sends a data packet to specify the required input. The data packet travels a reverse path to reach the consumer. Upon receiving the server s packet, the consumer replies its input by sending a data packet. When receiving the consumer s data packet, the server can now start to provide its service. Data packet traces a reverse path created by the request packet. DS will be used to cache the data subject to caching policy. RT and RIT will not be involved in data packet delivery Handling Conventional IP Packets SIONA is a compatible architecture that provides backward compatibility to the IP network. When receiving an IP packet, a SIONA router just acts as today s IP router to forward the packet based on its FIB. 2.5 Scalability Issues We claim that the scalability of SIONA s routing system is at least the same as, if not better than, that of today s IP routing system. One may expect that assigning each service and information with a name will produce a huge name space that makes RT even larger than today s routing table. However, in SIONA design this won t happen because RT only stores a limited number of popular names. When there is no matching entry for names, we can still use IP address to lookup the FIB for packet routing. Several solutions, such as Virtual Aggregation (VA) [24] and LISP [23], can be directly used by SIONA to improve its scalability. If the requested data is not registered in RT, and the request message doesn't specify IP address in the data name, SIONA can use some default routes to forward the packet subject to the domain s routing policy, which avoids flooding to the entire network. 3. Naturally Support for Mobility and Multihoming It has been a long struggle to manage mobility in today s IP networks. There are essentially two approaches for maintaining host reachability: routing and indirection (Mobile IP [28]). As the routing-based approach suffers from slow convergence and routing state explosion, indirection methods, such as Mobile IP, are considered to be practical in reality. However, all Mobile IP-based solutions have the common problem of triangular routing, which leads to longer delay and wasting of network resources. In SIONA, mobility is inherently supported. We show how SIONA supports client mobility and server mobility respectively. First, if a client moves, the client achieves seamless handover by keeping on issuing request packets. A new reverse path is automatically established by SIONA routers, which guarantees data packets to reach the client. In contrast, mobile IP needs to first do the handover registration and then encapsulate the packet using a triangular route. In some cases such as the handover of a high-speed train (up to 300 km/h), mobile IP may lead to bad user experience due to the registration burst ( passengers cell phone handoff at almost the same time). SIONA does not have this problem as no handover signaling is needed. Figure 5 illustrates the case. Figure 5. Handover of Mobile IP and SIONA (BS represents base station) Second, if a server moves, it updates the routing tables by sending register packets to the network. When routing tables converge, Request packets can travel a new path to get to the server. Neither of the above cases experiences triangular routing. While server mobility in SIONA does face the problem of slow routing table convergence, actually, it is unlikely to

5 lead to big problems as content servers does not often move in practice. For years, multihoming in IP networks has been beset by the dual role of IP addresses. When IP serves as both host identifiers and host locators, transport layer sessions are difficult to maintain connectivity when the hosts switch between their available addresses. ID/Locator split mechanisms [23, 26, 27] try to solve this problem by decoupling host identifiers and host locators, but they all introduce new indirection, or require some form of rendezvous points to keep reachability. SIONA provides multihoming functionality without path indirection, nor does it need any rendezvous point. In fact, it is trivial to managing multiple interfaces in SIONA s name-based model. Nodes just issue register and request packets using whatever interface they like, and the routing and forwarding mechanism of the network ensures the packets to reach the right destination. 4. SIONA Performance Enhancement 4.1 Caching Policy One of the fundamental characteristics of Information Centric Network is that routers in ICN have the ability of caching data. When data packet comes, the SIONA router caches the data in its Data Store (DS) for potential future use. The DS is just the buffer memory in today s IP router. Upon receiving a request packet, a SIONA router checks its DS to see if there is a data whose name falls under the request s name. If yes, the data will be sent back as a response. A basic observation of today s Internet is that the principle of locality is widely applicable. To provide optimal data delivery, the cached data should be close to receivers as much as possible. To make the best use of limited buffer memory, unnecessary data should be removed from DS as soon as possible. For example, one router need not keep a piece of data if all its downstream routers have had that data cached. While this caching mechanism may not work efficiently if each receiver requests different contents, it will be effective when the demands of receivers have the property of locality. To meet these goals, SIONA implements a TTL (Time to Live) based replacement policy, which follows the following rule: the closer a router is to the receiver, the longer it holds the data. To realize this, each piece of data is associated with a TTL which determines how long the data will be kept in the DS. The TTL of a root router in a multicast group is decided by a base_ttl and the maximum TTL is bounded by max_ttl. A TTL field in SIONA s data packet is used to pass TTL information among SIONA routers. Besides TTL, an upstream router also monitors the downstream routers caching state and immediately deletes the data when all its downstream routers have that data cached. Figure 6 shows the above logic. Figure 6. Coordinate caching algorithm The relative positions of routers (upstream or downstream) are transmission topology dependent. As different multicast groups may have different transmission topologies, one router may have different TTLs for different data. Our caching mechanism ensures that a router keeps data longer when it serves as a leaf router in one multicast group, and holds data shorter if it is a medium router in other multicast groups. To a large extent, this avoids the problem that a data is cached in a router but is never transmitted (for no request for that data will reach that router). Thus, the buffer memory is efficiently used and provides data delivery with better performance. The caching scheme proposed by SIONA can be called coordinate caching, in which one router s caching contents are dependent on other routers. Section 4 evaluates the experimental performance of the coordinate caching. 4.2 Multi-Source Multicast It has been a long struggle to deploy an interdomain multicast protocol in IP network. In SIONA, it is straightforward to establish an interdomain multicast state. The one-to-many paradigm of SIONA architecture supports multicast with extra infrastructure. The Request Interface Tables (RITs) in SIONA routers naturally maintain multicast states, in which multicast groups are identified by request names. It is trivial in SIONA to support multicast with a single source. The source sends packets only once, and the data cached in DS is leveraged to provide multicast distribution. A group of destination computers can simultaneously receive data in a single transmission from SIONA routers that create copies automatically. This is what is called oneto-many communication. However, in an information centric world, there will typically be multiple sources which serve the same information. SIONA implements many-to-many communication that a group of clients can request the same data from multiple servers in parallel. Request packets can

6 be disseminated by SIONA routers to simultaneously get service or information from multiple sources. The explosive growth of cloud computing and virtualization technology promotes services to appear in a distributed manner. Multi-source multicast can help to better satisfy the consumers demands by reaching the nearby server(s) as soon as possible. The multi-source delivery also provides multicast with better stability, load balance and acceleration of data transformation. 4.3 Distributed Storage and Network Layer P2P A SIONA router can disseminate its cached information among other routers. The disseminated data can be a portion of the information, which is identified by Offset (O) and Length (L). The distributed data storage at router level provides SIONA with a new function which is almost impossible in IP network: Network Layer P2P. A request can be split up into arbitrary pieces using O and L, and be forwarded to arbitrary SIONA routers to retrieve the desired information in parallel. Note that the request split is done by SIONA routers rather than the applications. For instance, when a SIOAN receives a video request, it can split the request into three slides with the first request representing the period from the beginning to 40min, the second slide representing the period from 41min to 80min and the last slide representing 81min to the end. It then can forward the slides to three SIONA routers which have the correspondent movie period and receive the video content in parallel. This provides a scalable and efficient solution to content distribution in today s data-explosion world. Note that there is a subtle difference between network layer P2P and multi-source multicast. Multi-source multicast refers to the idea that a group of receivers can fetch data from a single transmission, while network layer P2P enables information to be decomposed and disseminated through the network at router level and one SIONA router can get the information from multiple routers in a distributed manner. 5. Caching Evaluation In this section, we evaluate our caching mechanism by comparing with NDN and Dona. As is described in [5], we choose least-recently-used (LRU) as NDN s caching algorithm. As Dona [2] does not specify a certain caching mechanism, we choose LRU for Dona as well. 5.1 Simulation Setup The simulation topology is shown in figure 7, which is actually a multicast tree with the height of six. Every router is connected by an upstream router and three downstream routers. There is a server which has 10,000 information files. Each leaf router is connected by 1000 clients. Dona differs from SIONA and NDN in the sense that only the resolution handlers (RHs) provide caching functionality. In Figure 7. Simulation Topology our simulation, we choose the odd-level routers as Dona s RHs. In our simulation, each file has the size of 1M and each router has a 1G cache. For SIONA, each router gains its own TTL by doubling the TTL of its upstream routers. We run the simulation by setting base_ttl = 10 seconds and base_ttl = 30 seconds respectively to address the effects of different expiration times. In this simulation, no max_ttl is set. Each link in the network is associated with a latency of 10ms. For every second, each client randomly requests a file from the network. The simulation lasts for 1000 seconds. For each second, we record the mean delay for all clients to get the files and the load of the server. The load of the server is calculated by recording the number of requests which reach the server. Section 5.2 shows the results. 5.2 Results Figure 8 illustrates the mean delay for the network to satisfy the clients requests, with figure 8-a representing the results of base_ttl = 10 and figure 8-b representing base_ttl = 30. The caching algorithms of NDN and DONA are exact the same in both figures. Both figures show that our caching mechanism significantly reduces the latency. For NDN and Dona, the latency quickly drops to around 113ms and 125ms respectively and remains steady as the simulation goes on, while the latency of SIONA keeps below 115 ms after the drop at the beginning and has an average of 110ms. The reason why SIONA has a lower latency is that coordinate caching achieves a better data dissemination among routers, which utilizes the buffer memory more effectively. For the same piece of data, upstream routers have a shorter TTL than downstream routers, thus expire earlier than downstream routers. This provides two advantages. First, when data is removed from the cache of an upstream router, it is still kept by the downstream routers, thus content delivery won t experience a longer path. Second, the removed data leaves room for other contents which leads to optimal buffer utilization. The higher level a router resides in, the more downstream nodes it serves and the faster it refreshes its cache. This provides fairness for all nodes in the network, thus achieving better performance.

7 It s not surprising that Dona has a longer delay than NDN and SIONA because only parts of the routers (RHs) in Dona provide caching function. It can be seen from the pictures that the performance of SIONA s TTL-based caching algorithm can be affected by different expiration times. The 10s-base_TTL and 30sbase_TTL give similar mean delays but different curve shapes. It is worth noticing that the performance of the caching mechanism, while fairly good is not very stable. The curves jump and fall several times for both base_ttl=10 and base_ttl=30. We believe that the concussion of the SIONA curve is due to the data expires at the same rate (with the same base_ttl). It seems that longer expiration time tends to have less shakes than shorter ones, as the data expires slower with longer expiration time. An evidence is that 30s base_ttl achieves smoother performance than 10s base_ttl. However, theoretical analysis and extensive experiment/simulation are required to investigate the quantitative affects of different expiration times. The delay for DONA and NDN remains almost constant during the evaluation. This is because the behavior of LRU algorithm remains constant (no sudden expiration) and the distribution of coming requests didn t change during the simulation. (a) base_ttl = 10 (b) base_ttl = 30 Figure 8. Request Delay under different base_ttls Figure 9 Server Load (The x-axis represents the duration of the simulation) Figure 9 shows the load of servers of a 500-second simulation using the same topology. The points are highly scattered but evenly distributed. In general, SIONA has the lightest load of the three, while Dona has the heaviest. These results are correspondent with the cache curves, as lower delay means more requests are satisfied by routers, thus produces less access to the server. 6. Discussion SIONA is built on name-based content routing paradigm as is advocated in CCN/NDN [5, 16, 17]. We differ from CCN/NDN in several ways: SIONA closely keeps the ties to IP. CCN/NDN builds a universal overlay that CCN/NDN can run over anything and anything can run over NDN, including IP. In contrast, SIONA is more like a complementary function of today s IP network. In SIOAN, IP is explicitly included in the name structure. When P is specified, SIONA provides the same packet transmission behavior as IP networks. When P is not specified, SIONA performs pure name-based paradigm to route packets. Together with multi-source multicast and network layer P2P, the name-based paradigm can immensely benefit information delivery, such as audios and videos. SIONA differs from DONA in the way that is a tree based architecture, while SIONA is not. SIONA also has different name resolution scheme and routing mechanism. SIONA gives particular focus on services except for information. SIONA also supports multi-source multicast and network layer P2P, which is different from CCN/NDN and DONA. 7. Conclusion Information Centric Network (ICN) is an exciting area in future Internet research activities. SIONA is a promising candidate for ICN. It addresses the key problems of scalable content distribution by defining a name-based paradigm that directly supports effective content routing, caching and transformation. SIONA inherently supports host mobility and multihoming. It further supports multisource multicast and network layer P2P, which provides efficient solution to massive data distribution. SIONA is a

8 compatible model and can be incrementally deployed in today s Internet. We hypothesize that SIONA is on the way of evolution. We will keep improving SIONA s design and take measurements using implementation, simulations and theoretical analysis to identify problems in the design and evaluate performance at different scales. 8. REFERENCES [1] M. Gritter and D. R. Cheriton. TRIAD: A New Next- Generation Internet Architecture. July [2] T. Koponen, M. Chawla, B. Chun, A. Ermolinskiy, K. H. Kim, S. Shenker and I. Stoica. A data-oriented (and beyond) network architecture. In SIGCOMM, [3] B. Ahlgren, M. D Ambrosio, M. Marchisio, I. Marsh, C. Dannewitz, B. Ohlman, K. Pentikousis, O. Strandberg, R. Rembarz, and V. Vercellone. Design considerations for a network of information. In ReArch, [4] H. Balakrishnan, K. Lakshminarayanan, S. Ratnasamy, S. Shenker, I. Stoica, and M. Walfish. A Layered Naming Architecture for the Internet. In SIGCOMM, [5] Lixia Zhang et al. Named Data Networking (NDN) Project. PARC Technical Report NDN-0001, October [6] M. Caesar, T. Condie, J. Kannan, K. Lakshminarayanan, I. Stoica, and S. Shenker. ROFL: Routing on Flat Labels. In SIGCOMM, [7] C. Dannewitz, K. Pentikousis, R. Rembarz, E. Renault, O. Strandberg, and J. Ubillos. Scenarios and research issues for a network of information. In Proc. 4th Int. Mobile Multimedia Communications Conf., July [8] C. Esteve, F. L. Verdi, and M. F. Magalhaes. Towards a new generation of information-oriented internetworking architectures. In CONEXT, [9] M. Gritter and D. R. Cheriton. An architecture for content routing support in the internet. In Usenix Symposium on Internet Technologies and Systems (USITS), [10] G. Banavar, T. D. Chandra, B. Mukherjee,J. Nagarajarao, R. E. Strom, and D. C. Sturman. An efficient multicast protocol for content-based publishsubscribe systems. In The 19th IEEE International Conference on Distributed Computing Systems (ICDCS 99), pages , Austin, Texas, May [11] A. C. Snoeren, K. Conley, and D. K. Gifford. Meshbased content routing using XML. In Proceedings of the Eighteenth ACM Symposium on Operating Systems Principles (SOSP 01), pages ACM Press, Oct [12] P. Triantafillou and I. Aekaterinidis. Content-based publish-subscribe over structured P2P networks. In Third International Workshop on Distributed Event- Based Systems (DEBS 2004), pages , Edinburgh, Scotland, UK, May [13] Antonio Carzaniga, Cyrus P. Hall, Content-Based Communication: a Research Agenda, SEM 06, November 10, 2006, Portland, Oregon, USA. [14] IETF. RFC 4347 Datagram Transport Layer Security. [15] V. Jacobson. A New Way to Look at Networking, August docid= &ei=iux3sajyazpiqq LwjIS7BQ&q=tech+talks+van+ jacobson. [16] V. Jacobson. Making the Case for Content-Centric Networking: An Interview with Van Jacobson. ACM Queue, January [17] V. Jacobson. Special Plenary Invited Short Course: (CCN) Content-Centric Networking. In Future Internet Summer School, August [18] V. Jacobson, D. K. Smetters, J. D. Thornton, M. Plass, N. Briggs, and R. Braynard. Networking Named Content. In CoNext, [19] B. Ohlman et al. First NetInf architecture description, April php?s=file_download&id=39. [20] M. Walfish, H. Balakrishnan, and S. Shenker. Untangling the Web from DNS. In NSDI, [21] V. Jacobson, D. K. Smetters, N. H. Briggs M. F. Plass, P. Stewart, J. D. Thornton, R. L. Braynard. VoCCN: Voice-over Content-Centric Networks. In ReArch 09, December 1, [22] D. Peleg and E. Upfal. A trade-off between space and efficiency for routing tables. Journal of the ACM, 36(3): , July [23] D. Farinacci, V. Fuller, D. Meyer, D. Lewis. Locator/ID Separation Protocol (LISP), draft-ietf-lisp- 10.txt (work in progress), March [24] P. Francis, H. Ballani, T. Cao. Virtual Aggregation: A Configuration-only approach to Reducing FIB Size. Cornell University, a-wp.pdf [25] D. Meyer, L. Zhang, and K. Fall. Report from the IAB Workshop on Routing and Addressing. Internet Draft, IETF, Dec [26] R. Moskowitz, P. Nikander. Host Identity Protocol (HIP) Architecture, RFC 4423, May, [27] J. Laganier, L. Eggert. Host identity Protocol (HIP) Rendezvous Extension, RFC April [28] B. Ahlgren, C. Dannewitz, C. Imbrenda, D. Kutscher, B. Ohlman. A Survey of Information-Centric Networking, Feb.2011.