Data Dissemination Using Information-Centric Networking

2y ago
27 Views
2 Downloads
3.76 MB
140 Pages
Last View : 11d ago
Last Download : 9m ago
Upload by : Ciara Libby
Transcription

Data Dissemination using Information-CentricNetworkingbyAli ShariatmadariA thesis submitted in conformity with the requirementsfor the degree of Doctor of PhilosophyGraduate Department of Electrical and Computer EngineeringUniversity of Torontoc Copyright 2016 by Ali Shariatmadari

AbstractData Dissemination using Information-Centric NetworkingAli ShariatmadariDoctor of PhilosophyGraduate Department of Electrical and Computer EngineeringUniversity of Toronto2016Information-Centric Networking (ICN) is a promising paradigm to answerchallenges the current Internet is facing. It is a paradigm that puts contentfirst, and inherently enables content mobility and content security. In thiswork, we use ICN in real world applications. We present an ICN-based datadissemination layer for Smart City platforms. We also present a content-basedpublish/subscribe overlay system based on that data-dissemination layer. Weare using the system to collect and publish data from various sources, including demos with Unmanned Autonomous Vehicles (UAVs) providing livetransportation video.Furthermore, by promoting in-network caching, ICN is a promising paradigmto answer current challenges in the service provider’s domain. This work reports on a cache placement and content routing strategy for service providersto delay the onset of congestion (time-to-exhaustion) to the extent possible inorder to optimize their capital expenditure for their limited capacity planningbudget. We show that even a limited deployment of ICN provides a substantialincrease in the time-to-exhaustion of the network and a decrease in the num-ii

ber of links with high utilization. We also study the effects of homogeneousand heterogeneous caching mechanisms on the performance of an ICN basedcontent-delivery system.iii

to my wife, my mother, and my fatheriv

AcknowledgementsThis work would not have been possible without the help and support ofmany. First and foremost, I wish to offer my sincerest gratitude to my supervisor, Professor Alberto Leon-Garcia, who has supported me by his generousand continuous support, advice, and guidance throughout my study. His insightful suggestions and ideas have been precious for the development of thisthesis. It has been an honor and privilege for me to work with him, and forthat, I am grateful.Besides my advisor, I would like to thank the respectable members of myexamination committee, Prof. Roch Glitho, Prof. Baochun Li, Prof. Ben Liang,and Prof. Shahrokh Valaee, for their constructive comments, feedbacks, andquestions.My sincere thanks also go to Dr. Ali Tizghadam for all the stimulatingdiscussions, suggestions, and ideas. Also, I would like to thank all the membersof the Network Architecture Lab.I wish to give my special gratitude to my wife, Maryam, whose love andsupport made my journey possible. Finally, I thank my parents for theirlove and encouragement, without whom I would never have enjoyed so manyopportunities.v

Contents1 Motivations11.1Challenges of Current Internet . . . . . . . . . . . . . . . . . .21.2Possible Solution: Information-Centric Networking . . . . . . .31.3Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . .41.3.1Data Dissemination using ICN in Smart City Platforms41.3.2Content Delivery in Service Providers . . . . . . . . . .6Thesis organization . . . . . . . . . . . . . . . . . . . . . . . .71.42 Background and Related Works2.12.28Information-Centric Networking . . . . . . . . . . . . . . . . .82.1.1Concepts . . . . . . . . . . . . . . . . . . . . . . . . . .92.1.2A Brief History of ICN . . . . . . . . . . . . . . . . . .122.1.3Named-Data Networking . . . . . . . . . . . . . . . . .132.1.4MobilityFirst . . . . . . . . . . . . . . . . . . . . . . .192.1.5ICN Design Selection . . . . . . . . . . . . . . . . . . .22CVST Platform . . . . . . . . . . . . . . . . . . . . . . . . . .262.2.129Smart Application on Virtual Infrastructure . . . . . .vi

2.2.22.32.4Publish/Subscribe Systems . . . . . . . . . . . . . . . .31Content Delivery over Internet . . . . . . . . . . . . . . . . . .342.3.1Content Delivery Networks . . . . . . . . . . . . . . . .372.3.2Content Provider’s Cache . . . . . . . . . . . . . . . .392.3.3Transparent Caching . . . . . . . . . . . . . . . . . . .412.3.4Cache Placement in ICN . . . . . . . . . . . . . . . . .42Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .423 Data Dissemination in CVST3.13.23.33.43.544ICN-Based Data Dissemination Layer . . . . . . . . . . . . . .443.1.1Publisher-Broker Exchange . . . . . . . . . . . . . . . .463.1.2Subscriber-Broker Exchange . . . . . . . . . . . . . . .473.1.3Discussion . . . . . . . . . . . . . . . . . . . . . . . . .49Broker Architecture . . . . . . . . . . . . . . . . . . . . . . . .533.2.1Discussion . . . . . . . . . . . . . . . . . . . . . . . . .58Implementation . . . . . . . . . . . . . . . . . . . . . . . . . .613.3.1Broker Implementation . . . . . . . . . . . . . . . . . .613.3.2Communication Layer . . . . . . . . . . . . . . . . . .62Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . .653.4.1Traffic Flow Sensors . . . . . . . . . . . . . . . . . . .663.4.2Public Transportation . . . . . . . . . . . . . . . . . .693.4.3Drone Vision as a Service . . . . . . . . . . . . . . . .713.4.4Subscription Portal . . . . . . . . . . . . . . . . . . . .76Evaluation and Performance Tests . . . . . . . . . . . . . . . .783.5.179IDD Publication Test . . . . . . . . . . . . . . . . . . .vii

3.63.5.2Scalability of the Matching Engine . . . . . . . . . . .803.5.3IDD and IP Performance Comparison . . . . . . . . . .82Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .844 Content Delivery in Service Providers4.14.24.34.4Problem Definition . . . . . . . . . . . . . . . . . . . . . . . .874.1.1Content Distribution in Service Providers . . . . . . . .874.1.2Time-to-exhaustion . . . . . . . . . . . . . . . . . . . .89Problem Formulation . . . . . . . . . . . . . . . . . . . . . . .924.2.1Demands and Storage Budget . . . . . . . . . . . . . .944.2.2Content Delivery Networks . . . . . . . . . . . . . . . .964.2.3Named-Data Networking . . . . . . . . . . . . . . . . .100Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1024.3.1Time-to-Exhaustion of different topologies . . . . . . .1034.3.2Limited NDN Deployment . . . . . . . . . . . . . . . .1084.3.3I/O Speed Effect . . . . . . . . . . . . . . . . . . . . .1104.3.4Routing Protocol Effect in CDN . . . . . . . . . . . . .1114.3.5Heterogeneous Caching . . . . . . . . . . . . . . . . . .112Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1135 Conclusion5.15.286115Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . .1155.1.1Data Dissemination in CVST . . . . . . . . . . . . . .1165.1.2Time to Exhaustion . . . . . . . . . . . . . . . . . . . .117Future Works . . . . . . . . . . . . . . . . . . . . . . . . . . .117viii

Bibliography119ix

List of Tables2.1Summary of memory technologies [1] . . . . . . . . . . . . . .192.2NDN and MobilityFirst Comparison . . . . . . . . . . . . . . .243.1The APIs exposed by XPUB and XSUB services . . . . . . . .554.1Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . .93x

List of Figures2.1NDN Protocol Stack [2]. . . . . . . . . . . . . . . . . . . . .142.2Structure of NDN Packets . . . . . . . . . . . . . . . . . . . .152.3NDN Forwarding Process . . . . . . . . . . . . . . . . . . . . .162.4The MobilityFirst architecture [3] . . . . . . . . . . . . . . . .202.5Mobile Delivery in MobilityFirst [3] . . . . . . . . . . . . . . .222.6Layered Architecture of CVST Platform [4] . . . . . . . . . . .272.7Multi-tier Cloud for End-to-End Application Platform. . . .302.8SAVI test-bed main components [5] . . . . . . . . . . . . . . .312.9Peak Period Traffic Composition — North America [6] . . . .352.10 Traffic estimation of different types for global and mobile networks 362.11 Internet traffic source distribution in 2013 [7] . . . . . . . . . .402.12 Internet’s architecture is changing [8] . . . . . . . . . . . . . .413.1Application Platform for Smart Transportation . . . . . . . .453.2Publisher-Broker Communication . . . . . . . . . . . . . . . .473.3Subscriber-Broker Communication . . . . . . . . . . . . . . . .483.4High-level architecture of content-based publish/subscribe overIDD in CVST . . . . . . . . . . . . . . . . . . . . . . . . . . .xi54

3.5Design of the Broker: Abstraction of the complexity of differentsystem components . . . . . . . . . . . . . . . . . . . . . . . .3.656Sequence Diagram of the Content-Based Publish/Subscribe System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .573.7Scalability of the Broker with Micro-service design . . . . . . .593.8Apache Avro schema used in XPUB-Matcher communication .633.9Avro schema used in Matcher-XSUB communication . . . . . .633.10 Sample data gathered from traffic sensors . . . . . . . . . . . .653.11 Schema of the traffic sensor data. . . . . . . . . . . . . . . .653.12 Sample subscription for traffic sensor data . . . . . . . . . . .663.13 A match all query . . . . . . . . . . . . . . . . . . . . . . . . .663.14 Data of traffic sensors on the CVST portal . . . . . . . . . . .673.15 Sample data gathered from public transit vehicles . . . . . . .683.16 Schema of for Toronto Public Transit Data . . . . . . . . . . .693.17 A sample geo distance query for public transportation data . .703.18 Publishing Drone Data . . . . . . . . . . . . . . . . . . . . . .713.19 Sample Drone Data . . . . . . . . . . . . . . . . . . . . . . . .723.20 Video playback of a drone flight on CVST portal . . . . . . .733.21 Subscription Portal: Public Transportation Query . . . . . . .743.22 Subscription Portal: Public Transportation Data . . . . . . . .753.23 Subscription Portal: Traffic Sensor Query . . . . . . . . . . . .763.24 Subscription Portal: Traffic Sensor Data . . . . . . . . . . . .773.25 FIB table . . . . . . . . . . . . . . . . . . . . . . . . . . . . .78xii

3.26 Interests and Data packets log during XPUB and publisher communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . .783.27 Scalability of the Matching Engine - Experiment Setup . . . .793.28 Scalability of the Matching Engine, one minute rolling average803.29 Scalability of the Matching Engine, five minutes rolling average813.30 Data usage: IDD vs IP — Experiment Setup . . . . . . . . . .823.31 Data usage: IDD vs IP — Results . . . . . . . . . . . . . . . .834.1Network of a Service Provider . . . . . . . . . . . . . . . . . .874.2Content distribution in Service Providers . . . . . . . . . . . .884.3Flows between sources and destinations pass through multiplelinks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4.490Time-to-exhaustion. Traffic is increasing monthly until networkis congested. . . . . . . . . . . . . . . . . . . . . . . . . . . . .914.5Feasibility model for CDN . . . . . . . . . . . . . . . . . . . .994.6Feasibility model for NDN . . . . . . . . . . . . . . . . . . . .1024.7Rocketfuel network . . . . . . . . . . . . . . . . . . . . . . . .1034.8DGM network . . . . . . . . . . . . . . . . . . . . . . . . . . .1044.9Tree network . . . . . . . . . . . . . . . . . . . . . . . . . . .1054.10 Time-to-exhaustion in Rocketfuel network . . . . . . . . . . .1064.11 Time-to-exhaustion in DGM network . . . . . . . . . . . . . .1074.12 Time-to-exhaustion in Tree network . . . . . . . . . . . . . . .1084.13 Changes in TTE of Rocketfuel topology with number of caches 1094.14 Link utilization of NDN vs CDN . . . . . . . . . . . . . . . . .1104.15 Changes in TTE of Rocketfuel topology with I/O limit . . . .111xiii

4.16 Changes in TTE of Rocketfuel topology with Routing algorithm 1124.17 Heterogeneous vs Homogeneous caching storage in NDN . . .xiv113

Chapter 1MotivationsCurrent Internet is a product of four decades of evolution. Today, the rapidgrowth of contents and the number of connected devices is changing the architecture of the Internet. The Internet was designed for different circumstances,at a time when the primary concern was sharing resources. There were fewand expensive computers and their accessories, with few connections betweenthem. Therefore, host-to-host communication model became the central principle of the design of the Internet. In this design, each machine must havean IP address and follow the TCP/IP protocol to be able to communicate toother machines in the network. Although TCP/IP has been doing the jobwell, today’s network is not all about end-to-end communication between twohosts. Let us go over some challenges that the Internet is facing.1

Chapter 1. Motivations1.12Challenges of Current InternetA variety of things are expected to get connected to the Internet, billions ofthem. These things operate over multiple domains such as transportation, energy, weather, construction, health, agriculture, etc. This phenomenon, knownas the Internet of Things (IoT), is changing the architecture of the Internet.These devices are highly heterogeneous and have hardware constraints. Theyhave lower power consumption, CPU, and memory usage in order of magnitudes. They usually have multiple interfaces over different communicationprotocols and lack or have a limited number of configuration options. TCP/IPis an end-to-end communication protocol and expects the application layer toprovide such services. Therefore, in a constrained environment of IoT devices,using TCP/IP as a communication layer will be very challenging.The Internet traffic is also rapidly growing due to Over-The-Top (OTT)and Video-on-Demand (VoD) services such as Netflix and YouTube. Videotraffic is now consuming most of the bandwidth on the Internet. A moredetailed analysis shows that Netflix (31.6%) and YouTube (18.7%) combined,account for over 50% of downstream traffic in fixed access [6]. This growth isanother force that is changing the architecture of the Internet. The contentproviders are exploiting the economies of scale and using Content DeliveryNetworks (CDN) to transfer this everyday increasing traffic, which exacerbatesthe change. CDNs were introduced to overcome the limitations of traditionalWeb caching systems by deploying several caches throughout the globe andpopulating these caches with the popular content during the off-peak traffichours. Some content providers are very keen to work with service providers

Chapter 1. Motivations3(SP) to provide these caches. For example, Netflix OpenConnect program israpidly expanding its coverage by offering to install and maintain the caches inthe SP’s network. But using TCP/IP for content delivery is quite inefficient.A Gigabyte of content, like a TV Show, can generate a petabyte1 of transientdata. Contents, such as live video streams, are transferred over the Internetmultiple time, which puts enormous pressure on the infrastructure.1.2Possible Solution: Information-Centric NetworkingNew networking paradigms such as Information-Centric Networking (ICN)provide solutions to these problems. ICN is a clean-slate network architecturefor future Internet. It has named-data at the core of the networking, andnames are decoupled from content location, applications, storage or media oftransport. Decoupling data name and its location gives ICN native supportfor mobility since the users only need to know the name of the content andnot where the content is located. It also supports data security and privacyrequirements by enabling digital signature and encryption. This solution is notonly agnostic about the source of the content but also gives us the capabilityof in-network caching for all contents. In-network caching will help to placepopular content near the consumer to lower the latency, will result in a betterutilization of the infrastructure and will increase the throughput.An IoT platform is a substrate that offers data collection from a diverse11 PB 10005 bytes 1015 bytes 1000 terabytes

Chapter 1. Motivations4set of sensors operating in different domains. The substrate should be able totransfer various types of data generated by these sources and decouple datacollection and delivery. Not only, the substrate must provide data validationand integrity, but also must guarantee secure communication. Data sourcesmust be able to respond to pull-based and push-based data requests. At thesame time, the platform should provide support for middle-wares and valueadded services such as data processing and aggregation. Such requirementsmake ICN a potential alternative networking solution for an IoT platform.Also, built-in support for in-network caching and multicasting in ICN improves the utilization of underlying infrastructure by removing redundant flowsof the same content and helps the providers to control the extensive cost of lastmile technologies. Furthermore, detecting popular contents and storing themin caches near the edge of the network will decrease the latency, and movingaway from host-to-host communication model and employing a strategy layerwill improve content delivery in the mobile environment.1.3ContributionsThis thesis makes the following contributions.1.3.1Data Dissemination using ICN in Smart City PlatformsThe urban population of the world is growing. By 2050, 2.5 billion people willbe added to world’s urban population [9]. This growth poses major difficulties

Chapter 1. Motivations5for cities to meet objectives such as the quality of life and the socio-economicdevelopment of their citizens. The vision of a Smart City is a response tothese challenges. One of the major obstacles in the path to Smart Cities isthe current heterogeneous technologies use in cities and their lack of interoperability. Therefore, a unified platform for Internet of Things can becomethe building blocks of the Smart City concept, both at the infrastructure andservice level [10].A Smart City Platforms requires collecting data from a heterogeneous setof data sources in various domains, mobile and fixed. Also, the platform shallanonymize, cleanse and check the integrity of the collected data. It shall sendthe received data, in various formats, to interested parties and shall guarantee asecure data transfer. The platform shall provide different methods for accessingthe data streams, which include content as well as event notifications. Forexample, a customer shall be able to pull the data, and another one mayregister to receive notifications from the system upon the availability of thedata. The streams have diverse requirements for provenance, privacy andsecurity. And last but not least, the platform shall be scalable to cope withthe daily increase of the number of data sources and data sinks.We present a platform to gather data streams from a wide range of datasources including road cameras, loop detectors, planned and emergency roadclosures, fixed and mobile traffic sensors, drones, social media networks, publictransit vehicles, etc. This platform makes the data available to a broad rangeof customers using a novel data dissemination layer. We based the design ofthe data-dissemination layer on Information-Centric Networking, which inher-

Chapter 1. Motivations6ently enables content mobility, caching, and security. Here we will focus on theNamed Data Networking (NDN) implementation of ICN. NDN does not inherently support event notifications. Therefore, we enhanced NDN to add thepush notification capability. We present a Naming design for our system thatensures we can use the inherent features of NDN, such as in-network caching,scalability and mobility [11].We implemented an ICN-aware content-based publish/subscribe systemusing the data-dissemination layer. In this system, data sources are publishersthat send their data updates to a network of brokers. A user can express itsinterest in the data updates through a set of subscription queries and subscribeto the notification of the availability of the content that matched the queries.The broker registers the subscriptions queries and matches the newly publisheddata against them and then notifies the subscribers.1.3.2Content Delivery in Service ProvidersExponential traffic growth due to the increasing popularity of Over-The-TopVideo services has put service providers under much pressure. By promotingin- network caching, Information-Centric Networking is a promising paradigmto answer current challenges in the service provider’s domain. In this work, wereport on a cache placement and content routing strategy for service providersto delay the onset of congestion of their network. We aim to optimize thecapital expenditure of their limited capacity planning budget. We show thateven a limited deployment of ICN provides a substantial increase of the onsetof congestion of the network and a decrease in the number of links with high

Chapter 1. Motivations7utilization [12].1.4Thesis organizationThe rest of this document is organized as follows. First, we provide in Chapter 2 a review of the general knowledge required for proper understanding ofthis thesis, including Information-Centric Networking and Content Deliveryin the Internet. Then, Chapter 3 focuses on the design and implementationof the data dissemination layer. Chapter 4 focuses on how Service Providersmay delay the congestion of their network by using Information-Centric Networking. Each chapter provides evaluation results for the proposed methods.The thesis concludes with Chapter 5, which summarizes the contributions andprovides an outlook on future works.

Chapter 2Background and Related WorksIn this chapter, we will review the concept of Information-Centric Networking in Section 2.1. We go over Naming, Name-based Routing and In-NetworkCaching, and then we review different implementations of ICN paradigm. Wereview CVST, a platform for Smart city applications in Section 2.2. In Section 2.3 we survey current technologies used for content delivery over the Internet, such as Content Delivery Networks.2.1Information-Centric NetworkingInformation-Centric Networking (ICN) [2, 3, 13] is a clean slate networkingparadigm that tries to solve current networking problems by replacing thehost-to-host communication model. ICN puts the data at the focus centerof the network and then designs the facilities necessary for transferring thatdata. Using ICN, users express their interest for content and then the networkis responsible for providing that content for them. In ICN, it does not matter8

Chapter 2. Background and Related Works9where the content is stored, and the roles of identifier and locator of the contentare decoupled. In the current architecture, IP plays both of these roles.ICN assigns a name to the data itself, not the content container that storesthat data. Once content is created it has a name that cannot be changed, whichis similar to the way version controlling systems work in software programming.Content routers then use this name to route and forward data requests to theauthorized sources. Since the routing is based on the name instead of thehost address, network efficiency can be improved by using in-network caching.Therefore, if a router has already cached the data, it can answer the datarequest itself. Otherwise, the request, based on its name, is forwarded tothe next hop for processing. This decoupling also provides better support foruser’s mobility. Most of the ICN designs also include an inherent protectionand authentication of data itself, in contrast with encrypting the connectionbetween the two parties in the current layout.2.1.1ConceptsIn this section, we will review the concepts and terminologies that are commonbetween ICN designs.NamingAs discussed earlier, one of the problems of current Internet architecture isthat IP addresses are playing the role of both locator and identifier of theinformation. HTTP URLs are translated to IP addresses using DNS and theIP addresses are mapped to the location of the content server. Therefore, the

Chapter 2. Background and Related Works10location of the data is attached to its name. Any change in the location of thedata will result in changing its name, and there is no consistent way to keeptrack of identical copies of data in different places. To solve this problem, ICNdecouples content from its location. This decoupling shifts the paradigm fromcurrent host-to-host communication to a hop-to-hop communication model between network entities. When a consumer requests data, the network providesthat data from any authorized source. One of the first benefits of this model isthat only the receiver can retrieve the information, and no data can be receivedunless the receiver requests it. This one way requesting, is different from thecurrent architecture that anyone can send data to any IP address in the network. ICN designs put Naming at the core of the networking model, whichmakes it the most important part of designing of an ICN model. A namingmodel answers three questions [14]: validity: The ability to check no one has tampered the content, usuallyby having a verifiable digital signature. provenance: The ability to bind the data with the content publisher,usually using its public key. relevance: The ability to map the content to the original request.Name-based RoutingIn ICN, after the receiver sends a request, the network will find the authorizedsource for the data and will retrieve the content. It follows that all ICNdesigns should do named-base routing. Also, naming data creates the ability

Chapter 2. Background and Related Works11to aggregate all the requests for that data and intrinsically provides multicastforwarding capability.In-Network CachingBy decoupling information and its location, named data can be stored anywhere in the network, i.e. in-network caching. In-network caching is accomplished without any overlay and is an intrinsic part of ICN networks. Innetwork caching is an improvement over the way routers’ storage is used today,which is only for buffering packets. In ICN when a router receives an interestfor content, if it has it in the cache, it can provide it immediately.SecurityIn TCP/IP, security is achieved by encrypting the transmission channel plusauthenticating the end points of communication. In this model, there is no wayto provide the authenticity of the data itself, and we have to trust the containerof the data. Moreover, TCP/IP is designed to forward any traffic towardsthe destination, which results in an imbalance of power between senders andreceivers. This imbalance creates the ability, for attackers and spammers,to launch Distributed Denial of Service (DDoS) attacks. However, in ICN,content can be protected against alteration or eavesdropping and only genuinecopies of the data can exist in the network. Also, ICN architecture is receiverdriven which prevents DDoS attacks.

Chapter 2. Background and Related Works12MobilityTCP/IP was designed with the fixed and immobile hosts in mind, but today,we are facing with a sharp increase in the number of connected mobile devices.The network that the host is attached to determine the IP address of the host.Therefore, the IP address of a mobile device will change if it moves to othernetworks. This change of address will result in a distributed connection ofevery TCP/IP active session on the device. Some workarounds using differentoverlay solutions may be used to remedy this problem. These solutions comewith many inefficiencies since the problem is in the TCP/IP design. Moreover,IP networks must forward traffic on spanning trees to avoid loops and cannotmake full use of multiple connections of a particular host. ICN will tackle bothof these problems. ICN can take full advantage of multiple connections that adevice has and efficiently manages the communication using all of them. Thereason is, in ICN, there is no end-to-end connection, and every device is onlytalking to its next hop.2.1.2A Brief History of ICNThe introduction of the idea of separating names and locators goes backto TRIAD project [15]. However, the Data Oriented Network Architecture(DONA) [13] is one of the first complete ICN designs. DONA uses a flatname architecture that replaces current hierarchical names (URLs) by usingthe notion of self-certifying names.A self-certifying name is a tuple of the cryptographic hash of the publickey of the content publisher, P, and a unique label, L, as an identifier of the

Chapter 2. Background and Related Works13data that is published under that name. L can be a cryptographic hash ofthe content, which makes the label unique and the data immutable. Entitiesthat are interested in that data will learn its name from a trusted externalsource, such as a search engine for names. The name is self-certifying becauseanyone who has access to the public key of the publisher can verify the relationship between the data, the content publisher and the label. The nameresolution and routing is done using servers called Resolution Handlers (RHs).DONA uses source routing by querying these RH servers, which returns a setof network links that a request must traverse to reach its destination. DONAis compatible with current Internet architecture, but the requests take a longpath to be able to reach their destination, which causes unnecessary delays.Moreover, source routing information creates overhead in the packet header.In addition to DONA, there are many other proposed architectures forICN, such as PURSUIT [16–18], SAIL [19], COMET [20] and CONVERGENCE [21], but here we review Named Data Networking [2] and MobilityFirst [3].2.1.3Named-Data NetworkingNamed-Data Networking (NDN) [2] is a fully-fledged ICN architecture, whichinitially introduced in a Google Talk [22] by Van Jacobson and developedas Content-Centric Networking in PARC [23]. Then, NDN [24] started asan NSF-funded Future Internet Architecture project that began in 2010, incollaboration between 12

Information-Centric Networking (ICN) [2,3,13] is a clean slate networking paradigm that tries to solve current networking problems by replacing the host-to-host communication model. ICN puts the data at the focus center of the network and then designs the facilities necessary for transferring that

Related Documents:

Data dissemination - Wikipedia Data dissemination is the distribution or transmitting of statistical, or other, data to end users. There are many ways organisations can release data to the public IMF Standards for Data Dissemination Data dissemination standards enhance the availability of timely and comprehensive statistics, which contribu

Pro:Centric Direct interactive features are available with IP connectivity. Easy Code Editing with HCAP API Customized UI & Interactive Service Pro:Centric Smart TV API SI Application IP Pro:Centric (Middleware Platform) Pro:Centric Hotel Management Solution The WU960H is the latest in the line of Pro:Centric TVs that provide a unique and .

This information asymmetry often leads to a suboptimal system operation. Information-centric Networking (ICN) postulates a fundamental paradigm shift away from a host-centric model towards an information-centric one. ICN focuses on information item discovery and transmission and not on the connection of end-points that exchange data.

Networking of Information An information-centric approach to the network of the future . Focuses on Dissemination of Information objects Information -centric abstraction Today's Internet Communication Model Focuses on Conversations between Hosts Host -centric abstraction 2010-03-04 FP7 4WARD Project -www.4ward-project.eu Slide 2 Evolution .

Documenting your plan and tracking progress Document your plan in a way that works for you Tools available online – AHRQ Dissemination Planning Tool – Knowledge Translation Planning Template – CalSWEC Dissemination Planning Tool (modified from AHRQ) AHRQ Dissemination . Planning Tool. Knowledge Transition Planning Template

data center network topologies can be generally classified into four categories: switch-centric, server-centric, hybrid network architectures and direct network interconnection. The switch-centric topology is the most typical data cen-ter architecture, which places the interconnection and routing intelligence on switches.

Network-Centric Warfare Concept Network-centric operations were considered so essential to DOD transformation before 9/11 that the U.S. Congress, in Public Law 106-398, required the Department of Defense to report on the implementa-tion of the concept. 11 The object of network-centric operations is to take advantage of advances in IT so

the network-centric doctrine of operations (von Lubitz and Wickramasinghe, 2006a). The process-centric approach incorporates the two other major models (people- and tech-centric) and also allows a significant degree of automation in data/information extraction, manipulation, and organization. Human participation is, however, necessary for the