Jordan Augé

Giovanna Carofiglio

Alberto Compagno

Yoann Desmouceaux

Ralph Droms

Luca Muscariello

Victor Nguyen

Pierre Pfister

Dario Rossi

Mauro Sardara

Wenqin Shao

Éric Vyncke

On Information-Centric routing

à mes amis qui ont pu se libérer pour assister à ma soutenance.

Mal nommer un objet c'est ajouter au malheur de ce monde ALBERT CAMUS, 1944 First and foremost, I would like to express my utmost gratitude to Dr. Giovanna Carofiglio et Prof. Dario Rossi for supervising my thesis during the major part of the last three years. Dario's approach, mixing wide-ranging technical expertise, a thorough knowledge of academia, and an always positive mood has been of the main reasons I was able to conduct my PhD successfully. Giovanna's vision, rigour, and leadership made her essential to the success of my thesis. Her guidance was crucial in defining and focusing the research directions that I explored, but also to considerably increase the technical and writing quality of my scientific production, including this manuscript. She was an amazing mentor during my employment at Cisco, helping me naviguate the company and bootstrap my career. I would also like to warmly thank Ralph Droms, who supervised my during the six first months of my thesis. Our conversations put me on the right path and I learned a lot during them. I must also thank him for taking the time to finish the work we started together after he moved on to other occupations. Finally, I would like to thank Jean-Louis Rougier for guiding me through the last steps of my PhD. His advice was key in the preparation of my manuscript and defense.

I would like to extend my gratitude to my defense committee, and first to the reviewers Prof. George Pavlou and Prof. Lan Wang for taking the time to read and thoroughly comment my thesis manuscript. I would also like to thank the examiners Prof. Thomas Clausen, Dr. Emmanuel Baccelli, Prof. Matthias Wählisch and Prof. Lixia Zhang for participating in my PhD defense and for asking sharp and acute questions which led to very interesting discussions.

Il me faut maintenant remercier mes collègues et amis grâce à qui j'allais toujours au travail de bonne humeur. Merci d'abord à l'ensemble des «jeunes »du PIRL : Aloÿs, Guillaume, Jacques, Mohammed, Nathan, Pierre, Victor, et Yoann. Mentions spéciales à Yoann Desmouceaux, avec lequel nous avons beaucoup collaboré quitte à programmer dans des langages ésotériques et à Jacques Samain avec lequel nous avons partagé beaucoup de moments au sein de l'équipe ICN. J'en profite pour remercier aussi l'ensemble des membres de l'équipe ICN avec lesquels j'ai eu beaucoup de plaisir à travailler, tant pour leurs qualités humaines que pour leurs compétences professionnelles. Merci en particulier à Jordan Augé, pour sa motivation et son ardeur à toute épreuve et pour toutes ces conversations pendant lesquelles j'ai beaucoup appris. Merci enfin à l'ensemble des membres du PIRL, et en particulier Mark Townsley pour sa bienveillance et son intérêt depuis mon recrutement jusqu'à ma soutenance. Mark a rendu ma thèse possible et a toujours été présent lorsque des difficultés se sont présentées.

Merci aussi à l'ensemble de l'équipe de la chaire NewNet@Paris à Télécom,

Introduction

The underlying principles of the Internet have remained rather stable since its inception. TCP and IP, introduced in 1974 by Cerf and Kahn [1], still remain the fundamental protocols upon which communication channels are built. The use and the scale of the Internet, however, has dramatically evolved, moving from kilobytes to petabytes per second, from dozens to billions of connected end-points. Nowadays, networks have in fact invaded most aspects of our society and everyday life. There are but a few examples more representative of that phenomenon than the emergence of the Internet-of-Things (IoT), which promises to help automate and optimize our environment by increasing the number of connected devices by another few orders of magnitude.

The scale of the envisioned IoT deployments and their requirements in terms of bandwidth, latency, flexibility have raised concerns about the suitability of TCP/IP. New architectures have thus been proposed to replace or enhance TCP/IP so as to accommodate these new requirements, chief among them Information-Centric Networking (ICN). This thesis, in line with this approach, investigates the suitability of ICN for the IoT from a networking perspective.

The Internet-of-Things

The past ten years have seen the emergence of the so-called "Internet-of-Things" (IoT). The turn-of-phrase, which originally describes the growing trend of providing Internet connectivity to everyday objects (e.g., kitchen appliances, transportation tools, medical material), has been used to describe many different applications. The connectivity is used to build a network of "smart" objects that cooperate in view of automating specific tasks and systems. Notable examples of IoT subdomains are, among others, building [START_REF] Martocci | Building Automation Routing Requirements in Low-Power and Lossy Networks[END_REF][START_REF] Kastner | Communication systems for building automation and control[END_REF], home [START_REF] Cook | CASAS: A smart home in a box[END_REF][START_REF] Brandt | Home Automation Routing Requirements in Low-Power and Lossy Networks[END_REF][START_REF] Gill | A zigbee-based home automation system[END_REF], or factory [START_REF] Pister | Industrial Routing Requirements in Low-Power and Lossy Networks[END_REF][START_REF] Pellegrini | On the use of wireless networks at low level of factory automation systems[END_REF] automation, intelligent transportation systems (ITS) [START_REF] Hai An | A survey of intelligent transportation systems[END_REF], environmental monitoring [START_REF] Corke | Environmental wireless sensor networks[END_REF], smart cities [START_REF] Cocchia | Smart and digital city: A systematic literature review[END_REF][START_REF] Dohler | Routing Requirements for Urban Low-Power and Lossy networks[END_REF][START_REF] Balcon | Expérimentation: Cisco mesure la fréquentation de la place de la Nation[END_REF], the "smart grid" [START_REF] Fang | Smart grid -the new and improved power grid: A survey[END_REF], etc. This section aims at gaining a principled understanding of the IoT despite that diversity, looking at IoT applications (Section 1.1.1), networks (Section 1.1.2), and finally at the challenges associated with both (Section 1.1.3).

IoT applications

While diverse in form, in scale, and in objectives, IoT applications share common principles. Their goal is, in general, to automate and optimize part of our environment (the home, the city, etc.) As such, they follow the same global patterns of reading data from the environment, processing it to compute a metric, compare that metric against an objective, and apply actions on the environment accordingly.

These common characteristics lead IoT applications to share the same fundamental building blocks. Indeed, they are composed of four main actors: sensors, actuators, applications, and humans. Their respective function, summarized in Figure 1.1 can be described as such:

Humans deploy and manage IoT deployments. They set high-level goals (e.g., keep the building temperature at 20 • C) for automation or expect curated data (e.g., time series of the average level of pollution in a city) from the deployment.

Sensors are the basic data generators in IoT networks. They are typically single-purpose hardware modules deployed in a system, tuned to measure a specific physical phenomenon (e.g., temperature, speed, humidity). For instance, current top-of-the-line cars embed hundreds of sensors [START_REF] Abdelhamid | Vehicle as a mobile sensor[END_REF].

Actuators are modules that perform actions to influence the state of the system, for instance, by controlling the heating system in a specific room or the braking system of a car. They are controlled using the data generated by the sensors as a feedback mechanism.

Applications are used to provide intelligence to the system. They take as input the data measured by the sensors and the human-issued high-level objective and output instructions for the actuators, curated data for the humans, etc.

IoT networks

Another common thread of the various IoT use cases is their network architecture. Indeed, an IoT deployment usually implicates various logical and In particular, four main components can be identified: the IoT network, the access network, the core network, and the data center. The articulation between these components is shown in Figure 1. [START_REF] Martocci | Building Automation Routing Requirements in Low-Power and Lossy Networks[END_REF] The IoT network is where sensors and actuators are deployed. It corresponds to the geographic location of the system controlled or measured by the IoT (e.g., smart building, city, etc.). Sensors and actuators are often low-power nodes, with constrained computing, memory, and energy resources. They are equipped with a network interface, through either wired (Ethernet, Power Line Communications) or wireless (IEEE 802.11, IEEE 802.15.4, LoRa, cellular connections) technologies. IoT networks broadly follow one of two topology classes: star-shaped networks, and mesh networks. In star-shaped networks, all nodes are only connected to a base station, which acts as a relay towards both the inside and the outside of the IoT network. Typically, cellular or IEEE 802.11 networks are star-shaped. In mesh networks, on the other hand, nodes that are in communication range can communicate directly with each other. They form a decentralized network, where information can be transmitted over multiple hops from one sensor to another without going through a centralized base station. Such mesh networks of sensors, usually called Wireless Sensor Networks (WSN), have been widely studied in the literature [START_REF] Yick | Wireless sensor network survey[END_REF].

To link the IoT network with the rest of the Internet, IoT operators usually buy connectivity from an Internet Service Provider (ISP), connecting either the devices directly to the ISP network or via their own Local-Area network (LAN). The ISP network holds a specific place compared to other networks traversed by the IoT traffic: it is the only network operator with which the IoT operator maintains a business relation.

While sensors and actuators are usually only found in the IoT network, applications are ubiquitous in the IoT context. A popular solution is, for instance, to rent compute and storage resources in a Cloud platform. In this case, operators deploy their applications in a virtualized environment, typically hosted in a large data-centers remote from the actual IoT network. Such a solution is often IoT network Applications Ubiquitous Human-facing devices IoT network; Data center network practical for, e.g., collecting long time-series over specific readings or performing hard computations over large sets of data. On the other end of the spectrum, some rudimentary logic can be deployed directly on a sensor or an actuator. In this case, actuators can, for instance, retrieve data directly from sensor boards using horizontal Machine-to-Machine (M2M) communications. This approach is fit for low-latency control loops that require only minimal (if any) data processing. Finally, as a class of compute-intensive low-latency IoT applications started to emerge, e.g., for Augmented/Virtual reality (AR/VR) or for ITS, a new computing platform has emerged: the Fog [START_REF] Bonomi | Fog computing and its role in the internet of things[END_REF]. The Fog is defined as a highly virtualized, often distributed, computing and storage layer that sits at the edge of the network, e.g., in the IoT operator LAN or in the ISP network. Fog deployments are thus ideal for applications that require a low response time or, for instance, geographic awareness.

Finally, ISP and Cloud are connected through the Internet core network, sometimes through multiple transit networks. Obviously, and as represented in Figure 1.2, real-life IoT deployments can consist of multiple IoT networks connected to multiple access networks, with applications deployed in multiple data-center networks. In particular, the location of the actors in an IoT deployment is summarized in Table 1.1.

Challenges

The IoT has raised new challenges for communications networks. This section details some of the most important ones, namely new communication patterns, implementability, mobility handling, scalability, security, and Quality of Service (QoS). For each of these challenges, limitations of IP-based approaches are also presented.

Communication patterns

IoT traffic follows novel patterns, for which current networks have not been designed. A first novelty is the rise of horizontal M2M traffic [START_REF] Höller | From machine-to-machine to the internet of things[END_REF], as opposed to the traditional vertical client-server interactions seen in today's Internet. Indeed, while current Internet connections mainly consist of human-facing terminals (e.g., Web browsers or video players) in edge networks downloading data from data-centers in the cloud, the rise of the IoT has seen autonomous devices sharing information with each other. M2M communications can include, for instance, sensors sharing their data with an actuator or cars sharing traffic information with each other. In fact, between 2016 and 2021, Cisco expects 51 per cent of worldwide connected devices to perform M2M communications [START_REF]Cisco Virtual Networking Index[END_REF].

Furthermore, IoT streams are quite different from the original large pointto-point file transfers for which, e.g., TCP was designed. They often consist in periodic transfers of low-size data blobs in a one-to-many fashion, where multiple applications subscribe to consecutive readings of a sensor [START_REF] Hunkeler | MQTT-s -a publish/subscribe protocol for wireless sensor networks[END_REF][START_REF] Al-Fuqaha | Toward better horizontal integration among IoT services[END_REF]. To scale such communications patterns, multicast support is essential [START_REF] Silva | Why should multicast be used in WSNs[END_REF]. Native network multicast is even more important in constrained networks with multiple devices competing for network access and where thus network utilization should be minimized. In IP, multicast is not natively supported and comes with a large signalling overhead and strong limitations [START_REF] Shang | Challenges in IoT networking via TCP/IP architecture[END_REF].

Implementability

Classical IP stacks are notoriously hard to scale on low-power IoT nodes with constrained capabilities (in terms of battery, compute power, storage capacity, network bandwidth). Not only is the IP stack memory-consuming [START_REF] Baccelli | Information centric networking in the IoT: Experiments with NDN in the wild[END_REF], but its headers are disproportionally large for the low maximum transmission unit (MTU) of low-power networking technologies [START_REF] Montenegro | Transmission of IPv6 packets over IEEE 802.15.4 networks[END_REF]. Thus, a set of adapted protocols has been standardized for low-power networks: 6LoWPAN [START_REF] Montenegro | Transmission of IPv6 packets over IEEE 802.15.4 networks[END_REF] for the network layer with RPL [START_REF] Watteyne | Routing Requirements for Urban Low-Power and Lossy Networks[END_REF] as a routing protocol, DTLS [START_REF] Rescorla | Datagram Transport Layer Security Version 1.2[END_REF] as secure transport, CoAP [START_REF] Shelby | The Constrained Application Protocol (CoAP)[END_REF] for the application layer. These protocols were designed with IP compatibility in mind but are still ill-fitted to the IoT context. For instance, Clausen et al., have argued that RPL is sub-optimal for M2M communications [START_REF] Clausen | A critical evaluation of the IPv6 routing protocol for low power and lossy networks (RPL)[END_REF]. Furthermore, low-power nodes connected over wireless technologies are often disconnected, be it because they sleep to save battery or because of interference over the wireless medium. This is particularly problematic for the connection-based DTLS transport, which cannot handle such connectivity interruptions [START_REF] Shang | Challenges in IoT networking via TCP/IP architecture[END_REF].

Mobility

Mobility is an integral part of many IoT use cases. The smart city or ITS, for instance, involve nodes with high physical mobility. Even in static deployments, low-power nodes connected via wireless media only have intermittent connectivity due to their low duty-cycle or to wireless interference. Handling this mobility is a notably hard challenge in IP, as IP addressing is location-based [START_REF] Cespedes | IP mobility management for vehicular communication networks: challenges and solutions[END_REF].

Scalability

As explained in Section 1.1.1, a key feature the IoT is the deployment of many sensors and actuators in our everyday environment and the introduction of Internet connectivity to previously monolithic appliances. The number of devices connected to the Internet is thus expected to skyrocket, reaching 27.1 billion in 2021 [START_REF]Cisco Virtual Networking Index[END_REF]. These devices will generate and consume data and raise scalability issues in multiple aspects of the network. Beyond the obvious problem of being able to efficiently fit all of this data into the current networking infrastructure, it also brings traditional network protocols under tremendous stress. Routing protocols, for instance, could encounter scalability issues, e.g., from routing tables exploding in size or from control traffic overwhelming the network.

Security

Security is paramount for IoT applications, which present a particularly wide attack surface [START_REF] Hossain | Towards an analysis of security issues, challenges, and open problems in the internet of things[END_REF]. The connection-based security model built on (D)TLS is problematic for IoT environment, as creating and maintaining the channel requires important resources (in terms of network, memory, and compute) on constrained devices [START_REF] Vucinic | OSCAR: Object security architecture for the internet of things[END_REF]. It is also hard to accommodate alongside network multicast and mobility, which as explained earlier are essential features for the IoT. Furthermore, as IoT verticals are often built using, e.g., more powerful relay nodes such as gateways as protocol proxies [START_REF] Hossain | Towards an analysis of security issues, challenges, and open problems in the internet of things[END_REF][START_REF] Zhu | IoT gateway: Bridging wireless sensor networks into internet of things[END_REF], a purely connectionbased approach does not guarantee end-to-end authentication and data integrity between the sensor and the data consumer.

Quality of Service

Finally, the IoT is characterized by the cohabitation of many different QoS requirements. IoT applications can roughly be categorized into three classes, as summarized in Table 1.2: (i) latency-critical, when data must be received within 1-10 ms (typically in M2M interactions [START_REF] Al-Fuqaha | Toward better horizontal integration among IoT services[END_REF]), (ii) latency-sensitive, where the timescale interaction is in the order of 100 ms (e.g., applications with human interaction [START_REF] Miller | Response time in man-computer conversational transactions[END_REF]), and (iii) latency-tolerant, that have no specific delay constraint such as time-series collection for big-data analysis. All of these applications coexist along the IoT vertical and sometimes even rely on the same underlying sensor data.

Information-Centric Networking for the IoT: motivation

To tackle the challenges listed in Section 1.1.3, recent research has put forward a new network architecture called Information-Centric Networking (ICN) [START_REF] Shang | Challenges in IoT networking via TCP/IP architecture[END_REF][START_REF] Baccelli | Information centric networking in the IoT: Experiments with NDN in the wild[END_REF][START_REF] Amadeo | Information-centric networking for the internet of things: challenges and opportunities[END_REF][START_REF] Ravindran | Design Considerations for Applying ICN to IoT[END_REF]. Section 1.2.1 presents the high-level functioning of ICN. Theoretical advantages of ICN for the IoT are then presented in Section 1.2.2.

Information-Centric Networking

ICN is a recent network paradigm introduced by Van Jacobson et al. [START_REF] Jacobson | Networking named content[END_REF]. It is centred on the idea of using identifiers rather than locators as the central network primitive. Indeed, while Pouzin, inventor of the first datagram network, already pointed out in 1973 that topological addresses had limitations [START_REF] Pouzin | Presentation and major design aspects of the CYCLADES computer network[END_REF], current IP networks are still based on host-to-host communications. Conversely, in ICN, the central unifying layer is named data. The network is then in charge

INFORMATION-CENTRIC NETWORKING FOR THE IOT: MOTIVATION9

of locating and retrieving the data associated with a given name rather than forwarding a packet to a given destination address. Indeed, each addressable object in the network is given a name (e.g., /Cisco/ILM/Eiffel/Temp for the temperature in the Eiffel room of the Cisco office in Issy-les-Moulineaux). Names are rather generic and can represent anything: a specific sensor reading, a chunk of a video, a remote procedure call on an actuator, or even an endpoint. In ICN, network addresses thus represent named objects rather than only the host where said objects can be found. The forwarding plane is then in charge of finding a location for the named object. While ICN can be found in many derivations [START_REF] Raychaudhuri | MobilityFirst[END_REF][START_REF] Zhang | Named data networking[END_REF][START_REF]FD.io CICN project[END_REF][START_REF] Dannewitz | Network of information (NetInf) -an information-centric networking architecture[END_REF], in this thesis the term ICN refers to two rather similar realisations of ICN: CCNx [START_REF] Mosko | CCNx Semantics[END_REF][START_REF]CCNx Messages in TLV Format[END_REF] and Named-Data Networking (NDN) [START_REF] Zhang | Named data networking[END_REF]. Both architectures use hierarchical naming conventions (similarly to DNS) and are based on a pull-based communication model with symmetric routing. They rely on two fundamental packet types: Interest and Data packets. Interest packets, which are generated by consumers, contain the name of the piece of content that the consumer wishes to access. It is forwarded over the network based on that name towards the producer of the data until it reaches a point where the corresponding content is available. There, the content is put into a Data packet, also addressed by the content name, which is forwarded back to the consumer using the reverse path of the Interest packet.

ICN routers are based on three data structures: the Forwarding Information Base (FIB), the Pending Interest Table (PIT), and the Content Store (CS). The FIB, similarly to an IP router, maps name prefixes to next hop in the ICN network. It is used to forward Interests towards their destination object, by matching the name in the Interest against the name prefixes in the FIB using Longest-Prefix Match (LPM). The use of hierarchical names and LPM helps the FIB scale, by, for instance, aggregating all the routes towards the Cisco Issyles-Moulineaux office under the /Cisco/ILM name prefix. The PIT is used to record in-flight Interest to perform symmetric routing of the corresponding Data packet. It contains a list of all the names for which the router has received an Interest packet that has not been satisfied yet with a Data packet. Each of the names is stored with the incoming and outgoing interfaces of the corresponding Interest packets. These Interests are grouped by name: all requests for the same named object are aggregated in a single PIT entry. Namely, if a router receives an Interest for a name that is already in the PIT, it does not forward the Interest, but only update the PIT entry to register the current Interest incoming face. Interest aggregation is a fundamental feature of ICN, as the name-based forwarding allows to detect requests for the same name object and achieve native multicast. Upon reception of a Data packet, its name is matched in the PIT against outstanding Interests. The Data packet is then forwarded to all the registered incoming interfaces, thus taking the reverse path of the corresponding Interests. Finally, the CS is used to cache content directly on the forwarding path. Upon receiving an Interest, the router checks whether the requested content is available in its CS and serves it directly from its cache in that case. Upon receiving a Data packet, a cache admission policy (e.g., Least-Recently-Used (LRU) eviction) is used to decide whether to store the corresponding piece of content in the CS or not. The forwarding mechanism for Interest packets is summarized in Figure 1

ICN for the IoT

IoT has been identified as an area where ICN could bring many advantages [START_REF] Ohlman | Information-Centric Networking: Baseline Scenarios[END_REF]. Among others, name-based forwarding, in-network caching and multicast, object-based security, and mobility support are characteristics of ICN that could be beneficial for the IoT.

Name-based forwarding

First of all, forwarding on data-identifiers rather than network locators seems suited to IoT networks. Indeed, enforcing names at the network layer forces applications to share a common semantic. This is highly desirable for sensor data to be shared between multiple applications, especially on single-purpose low-power sensors [START_REF] Al-Fuqaha | Toward better horizontal integration among IoT services[END_REF][START_REF] Shelby | The Constrained Application Protocol (CoAP)[END_REF][START_REF] Ravindran | Design Considerations for Applying ICN to IoT[END_REF]. Inversely, network names allow applications to benefit from in-network service discovery [START_REF] Amadeo | Content-centric wireless networking: A survey[END_REF]. This is extremely important in the IoT context, where applications are not necessarily aware of sensors deployed in the field [START_REF] Cirani | A scalable and self-configuring architecture for service discovery in the internet of things[END_REF]. It means that multiple sensors can provide the same data, the same service, and that content ubiquity is handled directly at the network layer [START_REF] Ravindran | Design Considerations for Applying ICN to IoT[END_REF]. This approach is more integrated than IP-based approaches like CoAP, which require layers of indirection to map services to IP addresses [START_REF] Shelby | The Constrained Application Protocol (CoAP)[END_REF].

In-network caching and multicast

Furthermore, content ubiquity means that caching becomes a native feature in ICN networks [START_REF] Khan | A content-based centrality metric for collaborative caching in information-centric fogs[END_REF]. Caching is a crucial feature for IoT applications. First, it helps increase data availability in WSN. Indeed, on-field low-power sensors might only have intermittent reachability (because, e.g., of low duty-cycles and unreliable wireless connectivity) [START_REF] Hahm | Low-power internet of things with NDN & cooperative caching[END_REF]. Offloading the data produced by these sensors to more powerful and reliable nodes is necessary to ensure continuous data availability. Furthermore, caching is necessary to scale ever-growing IoT deployments. For instance, in WSNs, in-network caching allows for limiting the number of network transmissions and thus saving energy [START_REF] Prabh | Energy-conserving data cache placement in sensor networks[END_REF]. More generally, caches bring data close to its consumer, thus decreasing both download time and network utilisation. This is particularly crucial for low-latency applications (e.g., Augmented/Virtual Reality) [START_REF] Bonomi | Fog computing and its role in the internet of things[END_REF][START_REF] Ravindran | Design Considerations for Applying ICN to IoT[END_REF]. The efficiency of the data retrieval process is further increased thanks to the native multicast provided by the PIT and CS as described in Section 1.2.1.

Object-based security

This approach is furthermore enabled by the object-based security model of ICN, which maintains end-to-end trust between the data producer and the data consumer, even if the data goes through relay nodes [START_REF] Amadeo | Information-centric networking for the internet of things: challenges and opportunities[END_REF]. Indeed, in ICN, security is associated with the data rather than with the channel. In practice, it means that every piece of data is signed and/or encrypted directly by its producer. The security context is thus attached to the object rather than to the host (as it is the case in TLS). This removes the limitations of TLS-based approaches described in Section 1.1.3. Furthermore, ICN security scales with the number of produced objects rather than with the number of connections handled by a machine [START_REF] Vucinic | OSCAR: Object security architecture for the internet of things[END_REF][START_REF] Ravindran | Design Considerations for Applying ICN to IoT[END_REF]. Low-power sensor nodes are freed from the burden of maintaining high-cost TLS connections, thus lowering the energy overhead of securing the data.

Mobility support

Network mobility is a core feature of IoT networks, especially for use cases as ITS or Smart Cities. In IoT networks, mobility is not only associated to moving devices (e.g., connected vehicles or pedestrian-held devices), but also network mobility due to unreliable physical connections (e.g., wireless interferences on an IEEE 802.15.4 channel). The connection-less model of ICN is an obvious candidate to handle that mobility [START_REF] Arshad | Recent advances in information-centric networking based internet of things (ICN-IoT)[END_REF]. Indeed, consumer mobility is naturally handled thanks to symmetric routing: since consumers do not have network addresses, no signalling is required in case of a mobility event. More generally, the simplicity of the ICN stack and its native collaboration with the way applications are designed is expected to reduce signalling and decrease the number of indirection layers [START_REF] Amadeo | Information-centric networking for the internet of things: challenges and opportunities[END_REF].

ICN for the IoT: background

Research on ICN for IoT has focused on many different topics. This section summarizes seminal research contributions in three main areas that are of relevance for this thesis: ICN for the WSN (Section 1.3.1), ICN for the Fog (Section 1.3.2), and ICN for specific IoT applications (Section 1.3.3). For a more general survey on the ICN-IoT literature, the interested reader is referred to Arshad et al. [START_REF] Arshad | Recent advances in information-centric networking based internet of things (ICN-IoT)[END_REF].

ICN for the WSN

Data-centric approaches have a long history in WSN [START_REF] Stojmenović | Data-centric protocols for wireless sensor networks[END_REF]. Of particular note in this context, Directed Diffusion is a data-centric routing protocol where all nodes perform application-aware routing [START_REF] Intanagonwiwat | Directed diffusion: A scalable and robust communication paradigm for sensor networks[END_REF]. In particular, sensors are identified by attribute-value pairs and, similarly to ICN, data retrieval is done through a pull-based model using Interest messages. Interests are either flooded, directed based on geographic location, or forwarded based on routes learned during previous Interest/Data exchanges. Directed Diffusion has been adapted to the ICN context by Amadeo et al. [START_REF] Amadeo | Named data networking: A natural design for data collection in wireless sensor networks[END_REF]. They propose an extended naming scheme that consists of a multi-dimensional attribute-value set (e.g., task type, location, task time). A hybrid approach between multi-dimensional sets and traditional hierarchical names for IoT networks is proposed by Ascigil et al. [START_REF] Ascigil | A keywordbased ICN-IoT platform[END_REF]. Namely, a one-dimensional name is used as a network prefix in combination with a named-function (i.e., some processing to be applied on the retrieved data) and tags to describe the retrieved data. The prefix is used to route the packet towards a specific network location, where the tags are understood in context to find relevant sensors. The function is then used to enable in-network data processing. Similarly, Abidy et al., propose to extend the ICN naming scheme to perform in-network aggregation of several pieces of content [START_REF] Abidy | Named data aggregation in wireless sensor networks[END_REF].

Other authors have looked at adapting in a more straightforward way ICNimplementations to WSNs. Baccelli et al. [START_REF] Baccelli | Information centric networking in the IoT: Experiments with NDN in the wild[END_REF], consider the performance of an out-of-the-box ICN stack (CCN-Lite [START_REF]CCN Lite: Lightweight implementation of the content centric networking protocol[END_REF]) over constrained nodes using the open-source operating system (OS) RIOT-OS [START_REF] Baccelli | RIOT OS: Towards an OS for the internet of things[END_REF]. Using an experimental approach, they show advantages of ICN in terms of implementation complexity (lower memory usage, lower header footprint in the packet) with respect to 6LoWPAN. They propose two naive forwarding strategies for ICN: vanilla flooding and "flood-and-learn", which consists in flooding Interest packets for which there is no FIB entry and learning routes by observing the hop from which the corresponding Data packet comes back. Similarly, Gündogan et al. [START_REF] Gündogan | NDN, CoAP, and MQTT: A comparative measurement study in the IoT[END_REF], compare ICN with current IP-based standards for WSN (CoAP [START_REF] Shelby | The Constrained Application Protocol (CoAP)[END_REF] and MQTT [START_REF] Banks | Mqtt version 3.1.1[END_REF]). They show that ICN yields benefits in terms of implementability (i.e., footprint on the low-power device) and highlight an interesting trade-off: while ICN is more robust and resilient in multi-hop mesh scenarios, IP-based protocols are quicker and have less overhead in star-shaped deployments. Inversely, in [START_REF] Fotiou | CoAP over ICN[END_REF], an implementation of COAP over ICN is proposed for enabling application interoperability in ICN-IoT networks. The authors show, in particular, that the native ICN-multicast allows for significantly decreasing the communication overhead. Shang et al., propose an alternative implementation of the NDN protocol suite over RIOT-OS [START_REF] Shang | The design and implementation of the NDN protocol stack for RIOT-OS[END_REF], complemented by a larger framework to apply ICN for WSN [START_REF] Shang | Named data networking of things (invited paper)[END_REF]. Their architecture includes, among other contributions, a bootstrap protocol to issue meaningful names to sensors connecting to the IoT networks, a publish-subscribe system that respects the pull-model of ICN, and trust model for the data generated by the sensors. Looking specifically at constrained network technologies, Ren et al., present a lightweight CCNx-based protocol for fitting CCNx headers in 802.15.4 MTUs [START_REF] Ren | CCN-WSN -a lightweight, flexible content-centric networking protocol for wireless sensor networks[END_REF]. As the lower memory footprint of ICN stacks opens the opportunity for caching in IoT boards, Hahm et al. [START_REF] Hahm | Low-power internet of things with NDN & cooperative caching[END_REF], study how cooperative caching can increase content-availability for nodes with low duty-cycles. Pfender et al., also look at caching for low-power nodes, focusing on the efficiency of admission and eviction policies for IoT data [START_REF] Pfender | Performance comparison of caching strategies for information-centric IoT[END_REF]. To further optimize the caches, Melvix et al., design a forwarding strategy where ICN forwarders map Interest names to scopes and domains, which describe the expected accuracy on the requested data [START_REF] Lokesh | Energy efficient context based forwarding strategy in named data networking of things[END_REF]. For data that is tolerant to inaccuracies, stale or approximating pieces of content available in the CS can be used instead of forwarding the Interest in order to conserve energy.

Several pieces of work have also addressed the issue of security for ICN-WSN. In [START_REF] Burke | Secure sensing over named data networking[END_REF], the authors propose a global security framework for ICN-WSN that enables both push-and pull-interactions. The framework enforces access control over the ICN namespace and protects against Denial-of-Service (DoS) attacks using either asymmetric or symmetric cryptography. Compagno et al., propose OnboardICNg, a mechanism for secure-network join tailored for lowpower IoT devices [START_REF] Compagno | OnboardICNg: a secure protocol for on-boarding IoT devices in ICN[END_REF]. The evaluation shows improvements in terms of energy consumption and onboarding speed compared to IP-based standards. Similarly, Mick et al., introduce LaSeR, a lightweight scheme for sensor onboarding in the context of Smart Cities [START_REF] Mick | LASeR: Lightweight authentication and secured routing for NDN IoT in smart cities[END_REF]. In particular, LaSeR is integrated into the routing protocol so as to provide both functionalities (routing and authentication) at a lower overhead.

ICN for the Fog

The first natural use case for the Fog in an ICN network is as a caching layer. In [START_REF] Khan | A content-based centrality metric for collaborative caching in information-centric fogs[END_REF], the authors propose a metric for optimizing content placement in distributed and collaborating Fog caches. Their metric is based on content centrality, i.e., how well connected a cache is to the content it is serving. Hit-rate improvements are shown compared to topology-based (rather than content-based) centrality metrics and to non-collaborative caching systems. Their scheme is extended in [START_REF] Khan | A popularity-aware centrality metric for content placement in information centric networks[END_REF] by considering popularity in the centrality metric. Wang et al. [START_REF] Wang | Fog computing based contentaware taxonomy for caching optimization in information-centric networks[END_REF], propose to use the Fog as a classifying layer to help routers decide which data to cache. They use the Fog as a computing layer that does not suffer from the same limitations as ICN routers to distinguish dynamic data (which should not be cached) from static data (which should be cached). That classification is then encoded as a tag in the Data packet header and used by routers to optimize the content of their CS.

Other authors have looked at how to exploit the Fog to realise one of the promises of ICN: in-network processing. One of the main steps in that direction is Named-Function Networking (NFN), an extension of ICN where packets do not only carry the name of the desired content but also the name of a function to be applied to said content [START_REF] Sifalakis | An information centric network for computing the distribution of computations[END_REF]. Simple data-processing (e.g., lambda functions [START_REF] Fischer | Lambda-calculus schemata[END_REF]) can then be fetched from a function repository to perform opportunistic in-network processing of data. The named functions can, for instance, be implemented as Virtual Machines (VM) [START_REF] Król | NFaaS: : named function as a service[END_REF]. ICN routers equipped with a hypervisor can then launch these VMs on the content stored in a data packet to perform some computation on it. Scherb et al., specifically propose to apply NFN in the IoT by prioritizing Fog nodes to execute functions as on-path routers have only limited computing capacities [START_REF] Scherb | Resolution strategies for networking the IoT at the edge via named functions[END_REF].

Finally, some authors have explored the interaction between ICN and Fog from a network point-of-view. Shang et al., argue that the ICN naming and security model offers the opportunity to break from Cloud-only approaches by deploying applications directly into edge networks [START_REF] Shang | Breaking out of the cloud: Local trust management and rendezvous in named data networking of things[END_REF]. The Cloud is used as a complementary platform that can be used if available but is not necessary for the IoT applications to run, thus protecting the latters from loss of connectivity. Adhatarao et al., suggest using a Fog gateway as a protocol translation node between standard ICN protocols and a lightweight counterpart used to fit the requirements of low-power IoT networks [START_REF] Adhatarao | FOGG: A fog computing based gateway to integrate sensor networks to internet[END_REF]. In [START_REF] Wu | FCSS: Fog computing based content-aware filtering for security services in information centric social networks[END_REF], the Fog is used to perform content-aware filtering for security services in social networks. Specifically, the Fog layer acts as a security middleware between two parties of an ICN-enabled social network to discard illegal content by classifying the exchanged content along labels defined by a regulator. Nguyen et al. [START_REF] Nguyen | ICN-fog: An informationcentric fog-to-fog architecture for data communications[END_REF] suggest ICN as a natural network layer to enable horizontal Fog-to-Fog communications. They use two case studies (video streaming and building energy management) to show the theoretical advantages of ICN in the Fog-to-Fog context such as reduced signalling, latency, and network utilization.

ICN for specific IoT applications

Finally, ICN has been studied as an enabler for specific applications: smart homes and buildings, smart cities, and ITS. This section contains an overview of the literature on applying ICN to these use cases. Note that, while substantial work has also been conducted on smart healthcare [START_REF] Chen | NDNC-BAN: Supporting rich media healthcare services via named data networking in cloud-assisted wireless body area networks[END_REF][START_REF] Zhang | Sharing mHealth data via named data networking[END_REF][START_REF] Saxena | Design and verification of an NDNbased safety-critical application: A case study with smart healthcare[END_REF], it mostly addresses application-layer naming and security, which are not the topic of this thesis. Thus, we do not cover it in this state-of-the-art.

In [START_REF] Amadeo | Information centric networking in IoT scenarios: The case of a smart home[END_REF], an implementation of ICN for smart homes is presented. The authors suggest a flexible naming scheme and propose to support push operations by embedding data into Interest packets called Interest notifications. Similarly, Silva et al., evaluate the efficiency of Interest notifications for smart home lighting, showing a reduction in message-delivery delays compared with an HTTPbased platform [START_REF] Silva | Named data networking based smart home lighting[END_REF]. Shang et al., investigate building automation and management systems [START_REF] Shang | Securing building management systems using named data networking[END_REF]. They propose a namespace to represent both sensor data (based on its location in the building, its type, and a timestamp) and users (based on user-ids and security material). That naming scheme is used to perform access control by mapping the names of the users to the data namespaces that they are allowed to access.

Moving up in scale from smart homes, Piro et al., introduce a platform for ICN-enabled smart cities [START_REF] Piro | Information centric services in smart cities[END_REF]. They propose a service discovery protocol that allows the user to retrieve the security context associated with a specific name and show its application to several smart city use cases. In [START_REF] Yue | DataClouds: Enabling community-based data-centric services over the internet of things[END_REF], Yue et al., introduce DataClouds, a community-based ICN for smart cities. Communities are network overlays comprised of users interested in the same pieces of data. Splitting the ICN network into communities helps to scale the network by disseminating data and routes only to the interested users.

Another crucial part of the Smart City paradigm is the emergence of ITS. There, while ICN has again been identified as a natural solution for the network layer, several challenges are left to overcome [START_REF] Bouk | Named-data-networkingbased ITS for smart cities[END_REF][START_REF] Amadeo | Information-centric networking for connected vehicles: a survey and future perspectives[END_REF]. One particular area of interest in that regard is vehicle-to-vehicle communication (V2V). Yan et al., introduce an architecture that supports typical ITS communications patterns, which involve mobility, push-based communications, and large-scale retrieval of small-sized pieces of data [START_REF] Yan | A novel vehicular information network architecture based on named data networking (NDN)[END_REF]. Their architecture is based on a hierarchical topology, where nodes in the access network are responsible for specific geographic zones. These nodes are then used aggregate Data packets and segregate Interest packets in order to increase the scalability of the network. Their naming strategy is also based on using geographic zones as prefixes. Interest packets are then geographically routed towards the node in the access network that is in charge of the corresponding zone. Similarly, Grassi et al., propose a routing scheme for V2V communications based on geography [START_REF] Grassi | Navigo: Interest forwarding by geolocations in vehicular named data networking[END_REF]. Data is identified by a grid location in the Military Grid Reference System [START_REF] Stott | The UTM grid reference system[END_REF]. ICN forwarders map these grid locations to geographic faces using flood-and-learn techniques.

Thesis contribution

This thesis addresses the problem of routing and forwarding along the IoT vertical. This section summarizes the main contributions. First, the challenges tackled by the thesis are described in Section 1.4.1. Then, the contributions and

Forwarding and routing in the ICN-IoT: challenges

Most of the issues described in Section 1.1.3 resonate in the way forwarding and routing are considered in the IoT: routing protocols must be scalable and responsive enough to manage mobility, forwarding must accommodate the various QoS requirements of IoT applications, the impact of both routing and forwarding on low-power IoT nodes must be considered, etc. On top of that, the use of ICN as the network layer for the IoT brings not only opportunities but new challenges. Two main problems arise: (i) the scalability of the ICN naming scheme in terms of routing structures (FIB) [START_REF] Afanasyev | Scaling NDN routing: Old tale, new design[END_REF] and (ii) the development of forwarding strategies to select the next-hop when content is available in multiple locations [START_REF] Yuan | Scalable NDN forwarding: Concepts, issues and principles[END_REF]. The latter is of such importance to ICN that it has led to the development of a new block in the ICN router architecture: the strategy layer, used to transform the list of faces matched in the FIB into an actual forwarding decision [START_REF] Yi | A case for stateful forwarding plane[END_REF]. As QoS is a predominant problem for the IoT, being able to coordinate forwarding strategies not only across nodes but also with application orchestration is of utmost importance [START_REF] Abraham | Forwarding strategies for applications in named data networking[END_REF].

While often mentioned as an important challenge [START_REF] Shang | Challenges in IoT networking via TCP/IP architecture[END_REF][START_REF] Baccelli | Information centric networking in the IoT: Experiments with NDN in the wild[END_REF][START_REF] Shang | Named data networking of things (invited paper)[END_REF], routing and forwarding for the IoT received little interest in the ICN community. For instance, most of the envisioned routing schemes for WSNs rely on a variant on a flood and learn mechanism, varying from simple name discovery [START_REF] Baccelli | Information centric networking in the IoT: Experiments with NDN in the wild[END_REF][START_REF] Piro | Information centric services in smart cities[END_REF] to discovering groups prefixes based on attributes such as geographic location [START_REF] Amadeo | Named data networking: A natural design for data collection in wireless sensor networks[END_REF][START_REF] Grassi | Navigo: Interest forwarding by geolocations in vehicular named data networking[END_REF] or tags [START_REF] Ascigil | A keywordbased ICN-IoT platform[END_REF]. Similarly, the literature on the ICN-enabled Fog has focused on exploiting the Fog resources to enhance ICN intrinsic capacities (e.g., larger storage space for caching or computing power for protocol translation) but has not considered how ICN routing and forwarding can be used to enhance the functionalities for which the Fog was built in the first place.

Contribution and organization

This thesis is divided into three main chapters, reflecting the respective contributions. In particular, routing and forwarding are considered across the complete lifecycle of IoT data: data retrieval and processing. First, efficient data retrieval from IoT networks is investigated in Chapter 2. In particular, we explore the opportunities for performing geographic routing in the ICN-enabled WSN while keeping the network safe from malevolent attackers. In Chapter 3, ICN is used to bring intelligence to the network and help data processing platforms meet QoS requirements. In particular, we consider the problem of admission control in Fog platforms to enforce service time constraints. Finally, we address the broader problem of unifying network configuration and application orchestration in Chapter 4 by introducing vICN, a framework for ICN network management and virtualization based on recent progress in intent-based networking (IBN). The main contributions of this thesis are then summarized in Chapter 5, where perspectives on further work and research are briefly outlined. The articulation between the different contributions of this thesis is summarized in Figure 1.4.

Secure geographic routing for WSN

In a first step, we investigate the feasibility of using geographic forwarding to solve the routing problem in ICN-based WSNs. First, an architecture to securely perform geographic forwarding in the ICN semantic is introduced, based on four pillars: a naming scheme, a neighbour authentication mechanism, an ICN-based secure beaconing protocol, and a geographic forwarding algorithm. For the authentication mechanism, two protocols with similar security guarantees are considered: OnboardICNg [START_REF] Compagno | OnboardICNg: a secure protocol for on-boarding IoT devices in ICN[END_REF], based on symmetric cryptography, and a new protocol, based on asymmetric cryptography. They are evaluated in terms of memory footprint and completion time. Second, an analytical model is presented to compare the efficiency of geographic forwarding to flood-andlearn approaches in terms of energy consumption, memory footprint, and CPU complexity. This model is completed by a mixture of experiments on standard sensor boards and of simulation to derive general guidelines as to when to use geographic forwarding with respect to flood-and-learn. In particular, it shows that geographic forwarding outperforms flooding-based approaches in terms of memory footprint in most cases and yields significant improvements in terms of energy overhead for dynamic topologies.

Popularity-based forwarding for Fog-Cloud placement

In a second step (and moving up the IoT vertical), we explore how ICN can help Fog platforms enforce service-level agreements (SLA). In particular, we look at how ICN can enhance Fog admission control (AC) by bringing applicationawareness into the AC module. The Fog admission control problem is formalized as a constrained optimization problem using a queueing model. The LRU-AC, an approach based on estimating popularity through a virtual LRU cache, is proposed. Using the constrained optimization framework, the LRU-AC is shown to allow Fog nodes to accept more requests than application-blind approaches while respecting the same latency SLA. An implementation of the LRU-AC on programmable hardware is studied to provide AC at line-rate with minimal latency. This implementation is based on replacing the LRU structure with an Ageing Bloom Filter. The algorithmic validity of the implementation is proven through analytical modelling and verified through simulation. It is shown to perform the LRU-AC with minimal latency overhead (3 µs) and line-rate throughput (16.7 Mpps).

Unified network management and application orchestration for the ICN-enabled IoT

In the last chapter, the challenge of unifying network and application management is explored. This problem is particularly stringent in the ICN-enabled IoT for many reasons, e.g., (i) the scale and diversity of IoT networks requires low-granularity control but also high-level human facing-interfaces; (ii) current ICN implementations and toolchains typically lack the comprehensive control mechanisms and protocols developed for IP; (iii) in ICN, the potential for interactions between the network and applicative layers reinforce the need for unifying network management and application orchestration. We thus introduce virtualized ICN (vICN), an intent-based framework for network virtualization and management developed specifically for ICN. It offers a single, flexible and scalable platform to serve different purposes, ranging from reproducible largescale research experimentation to demonstrations with emulated and/or physical devices and network resources and to real deployments of ICN in existing IP networks. We highlight the flexible, modular, and scalable design of vICN and provide concrete examples to demonstrate its potential. Finally, the possibility of using ICN as a control protocol is explored. In particular, we propose an intent-based alternative to current IP-based network control standards that is able to perform routing and forwarding over orchestration objects. We illustrate benefits in terms of network programmability, reliability, and scalability.

Publications

Geographic routing for information-centric wireless sensor networks

In this first chapter, we focus on the retrieval of data from IoT networks. In particular, the problem of routing and forwarding in a multi-hop wireless sensor network (WSN) using ICN is addressed. Indeed, as noted in the introduction, recent research argues that ICN is a better fit for WSN than the standard IPv6based network stack, For instance, seminal work [START_REF] Baccelli | Information centric networking in the IoT: Experiments with NDN in the wild[END_REF] shows through experiments that a slightly modified ICN stack outperforms the standard IPv6-based stack (i.e., IEEE 802.15.4, 6LoWPAN and RPL) in terms of energy efficiency and memory requirements -which are primary concerns for WSNs.

However, the advantages resulting from the use of ICN architectures in terms of naming, mobility, and security (Section 1.2) do not come without challenges [START_REF] Ravindran | Design Considerations for Applying ICN to IoT[END_REF]. One such challenge is efficient packet delivery with minimal control traffic. Most of the recent pieces of work on ICN for the WSN rely on a flavour of flood-and-learn to discover network paths towards ICN names [START_REF] Baccelli | Information centric networking in the IoT: Experiments with NDN in the wild[END_REF][START_REF] Amadeo | Named data networking: A natural design for data collection in wireless sensor networks[END_REF][START_REF] Ascigil | A keywordbased ICN-IoT platform[END_REF][START_REF] Piro | Information centric services in smart cities[END_REF][START_REF] Grassi | Navigo: Interest forwarding by geolocations in vehicular named data networking[END_REF]. While simple from an implementation perspective, such approaches that use network broadcast can be costly for low-power devices, especially in mobile wireless networks where bandwidth is also a scarce resource [START_REF] Ni | The broadcast storm problem in a mobile ad hoc network[END_REF].

Geographic routing

Geographic routing, where packets are routed towards a physical location instead of a host, has long been pushed as a potential solution for routing in WSNs [START_REF] Chen | A survey of void handling techniques for geographic routing in wireless networks[END_REF]. Indeed, in typical geographic routing implementations, forwarding is performed by selecting the neighbour that is the closest to the packet's destination. Control traffic is thus kept local, as nodes only need to know their neighbours' position to take a forwarding decision. While geographic routing strategies have been thoroughly studied in the literature since the publication of seminal work such as [START_REF] Karp | GPSR: Greedy perimeter stateless routing for wireless networks[END_REF], to date there are no implementations available in state of the art IoT stacks [START_REF] Hahm | Operating systems for low-end devices in the internet of things: A survey[END_REF] and the same holds true for the ICN-WSN context.

CHAPTER 2. GEOGRAPHIC ROUTING

In this chapter, we set ourselves to explore the feasibility and practicality of using geographic routing and forwarding in ICN-enabled WSNs, looking specifically at three aspects:

(i) how can geographic routing and forwarding be realized from a protocol point-of-view while respecting the ICN semantic? (ii) how can the routing protocol be protected from rogue participants aiming at either diverting or denying requests? (iii) how does geographic routing compare to the current flood-and-learn approach in terms of feasibility (memory and CPU footprint of the forwarding algorithm on the constrained devices) and efficiency (energy and network overhead of the routing scheme)? Rather than focusing on a specific WSN deployment, which would result in conclusions of limited scope, we intentionally study the broad issue of geographic as opposed to name-based routing and forwarding, where resource consumption grows respectively with the number of neighbours and entries in the ICN FIB.

Our contributions, matching the aforementioned challenges, can thus be summarized as such:

(i) we propose a protocol implementation of geographic routing in ICN that relies on a naming convention, a beaconing mechanism, and the ICN strategy layer to realize geographic forwarding. In particular, we implement a classic flavour of geographic forwarding, GPSR [START_REF] Karp | GPSR: Greedy perimeter stateless routing for wireless networks[END_REF], in an ICN stack based on RIOT-OS [START_REF] Baccelli | RIOT OS: Towards an OS for the internet of things[END_REF]. (ii) security mechanisms for the protocol in (i) are introduced, in particular, to prevent rogue nodes to join the WSN and to emit beacons. A secure join protocol based on asymmetric cryptography is proposed and compared to a state-of-the-art protocol, OnboardICNg [START_REF] Compagno | OnboardICNg: a secure protocol for on-boarding IoT devices in ICN[END_REF], itself based on symmetric cryptography. The content of this chapter has been the object of three publications. [START_REF] Enguehard | SLICT: Secure localized information centric things[END_REF] covers the protocol implementation of geographic forwarding (i) and offers partial insights into its comparison to name-based approaches (iii), looking at the cost of forwarding a single packet. [START_REF]Poster: On the cost of secure association of information centric things[END_REF] contains the comparison between the two network join protocols (ii). [START_REF] Enguehard | On the cost of geographic forwarding for information-centric things[END_REF] extends the work on comparing geographic and name-based forwarding, looking this time at the complete cost of the routing protocol (i.e., forwarding cost plus control plane cost).

The remainder of this chapter is organized as follows. We start by overviewing WSN deployments, with the purpose of selecting some relevant use cases that we use as reference points in our evaluation (Section 2.2). Next, we introduce the reference ICN architecture, discussing aspects related to naming, security, and forwarding (Section 2.3). We then formally state our problem and outline the methodology, introducing the energy model for ICN-WSN deployments at a high level (Section 2.4). We incrementally add details to the overall picture, refining each of the building blocks (Section 2.5-2.6). The full details of the model are then presented and used to quantitatively and qualitatively contrast geographic and named-based ICN forwarding for the identified use cases (Section 2.7). Finally, we discuss and summarize our main findings (Section 2.8).

Reference WSN deployments

Depending on the use cases and applications, WSN deployments cover a broad spectrum of characteristics in terms of node density, number of nodes, typical topology, traffic patterns, etc. Given that our main aim is to identify under which circumstances, if any, geographic forwarding is more advantageous than classical name-based forwarding, we need to select a number of specific use cases, representative of different application classes. For the purpose of quantitative assessment, we need each use case to precisely report characteristics that are specific to a single deployment. At the same time, provided that the selection is made among carefully defined application classes, we expect that the results for the selected example in any given application class qualitatively applies to other deployments in the same class.

As pointed out in Section 1.1, there are many classes of IoT applications. To better focus our investigation, we consider the IETF Routing Over Low power and Lossy networks (ROLL) working group 1 , which identifies four main use cases: (i) urban sensing [START_REF] Dohler | Routing Requirements for Urban Low-Power and Lossy networks[END_REF], (ii) industrial sensing [START_REF] Pister | Industrial Routing Requirements in Low-Power and Lossy Networks[END_REF], (iii) home automation [START_REF] Brandt | Home Automation Routing Requirements in Low-Power and Lossy Networks[END_REF], and (iv) building automation [START_REF] Martocci | Building Automation Routing Requirements in Low-Power and Lossy Networks[END_REF]. While not considered by the ROLL working group, environmental sensor networks and machine-to-machine deployments are another class of deployments largely covered in the literature [START_REF] Corke | Environmental wireless sensor networks[END_REF][START_REF] Amadeo | Information-centric networking for m2m communications: Design and deployment[END_REF]. Without loss of generality, and to give the reader several reference points, we consider four deployments, whose relevant characteristics we summarize in Table 2.1 with their classes with respect to the aforementioned ROLL categories. For each deployment, we review the reference documentation or available data to determine the number of neighbours for each node, which we use as input data to our model. The deployments, ordered by increasing node degree in Table 2.1, are:

(A) Place de la Nation: as an example of the urban sensing class, we take the Cisco-Paris deployment, which is a joint venture between Cisco, the City of Paris and several start-up companies [START_REF] Balcon | Expérimentation: Cisco mesure la fréquentation de la place de la Nation[END_REF]. [START_REF] Szewczyk | An analysis of a large scale habitat monitoring application[END_REF] is an environmental sensor network consisting of 150 devices. The sensors were used to observe the habitat of seabirds on an island off the coast of Maine and its evolution depending on weather conditions. (C) CASAS: as an example of the home automation class, we select CA-SAS [START_REF] Cook | CASAS: A smart home in a box[END_REF], which is a so-called "smart-home in a box": a ready-to-deploy sensor network that allows any consumer to transform their home in a connected (or "smart") home. It consists of 30 nodes communicating over the IEEE 802.15.4 radio channel, including temperature sensors and infrared motion/light sensors. (D) Sensor Andrews: as an example of the building automation class, we select Sensor Andrew [START_REF] Rowe | Sensor andrew: Large-scale campus-wide sensing and actuation[END_REF], a sensor network deployment at Carnegie Mellon University (CMU). More than 1000 devices spread all over the CMU campus report numerous measurements such as electricity consumption or temperature.

Reference Information-Centric Things (ICN-WSN) Architecture

To realize secure geographic routing, several building blocks must be added to tradition ICN-WSN architectures: (i) a neighbour discovery and association protocol (Section 2.3.1), which ensures that only trusted nodes are authorized to send packets on the network; (ii) a secure beaconing (Section 2.3.2) protocol to handle topology and location changes; (iii) a forwarding scheme (Section 2.3.3), to ensure correct forwarding of Interest packets over the network independently of the forwarding algorithm class (i.e., geographic or name-based). In this section, sample implementations for these are detailed and discussed, highlighting the various trade-offs. Let us note that our study leaves for future work one important feature of ICN: in-network caching. As memory is a scarce resource on IoT platforms, a better understanding of the opportunities for in-network caching in the ICN-WSN would require a thorough study of current ICN-WSN stacks and their memory usage. We provide a first step in that direction with the results of Section 2.7.2.

Secure neighbour discovery

Whereas in the context of fixed ICN networks, security is attached to selfverifiable data objects, the world of ICN-WSN requires additional features. To begin with, given the broadcast nature of the wireless medium, in a hostile environment silent attackers could eavesdrop on sensitive sensor data. Additionally, given the multi-hop nature of WSN communications, talkative attackers could instead swamp network resources, such as battery and wireless medium, by issuing bogus Interest messages. Additional security mechanisms are thus required, such as naming and communication patterns to enforce access control on ICN-based WSNs [START_REF] Burke | Secure sensing over named data networking[END_REF][START_REF] Compagno | OnboardICNg: a secure protocol for on-boarding IoT devices in ICN[END_REF].

This section thus addresses the problem of neighbour discovery and association for ICN-WSN, to ensure that only trusted nodes are authorized to send packets on the wireless network. A novel association protocol based on asymmetric keys is presented and compared to a recently proposed one based on symmetric cryptographic keys [START_REF] Compagno | OnboardICNg: a secure protocol for on-boarding IoT devices in ICN[END_REF]. The evaluation considers both security and network properties of these protocols, as well as important practical aspects such as the forecasted power consumption of the protocol implementation on different WSN technologies.

Association protocols using (a)symmetric cryptography Symmetric Cryptography. Let us first note that, while symmetric cryptography is not natively suited to authentication, it is several orders of magnitude less expensive in terms of CPU cycles than standard asymmetric cryptography [START_REF] Tschofenig | Performance of state-of-the-art cryptographyon ARM-based microprocessors[END_REF], which makes it attractive for low-power environments. Additionally, there is a growing hardware support for symmetric cryptography on recent sensor boards, which implies a shrinking energy footprint of cryptographic operations. This explains why the author of OnboardICNg [START_REF] Compagno | OnboardICNg: a secure protocol for on-boarding IoT devices in ICN[END_REF], an ICN-based neighbour authentication protocol, selected to rely only on symmetric cryptography. To overcome the limitations of symmetric cryptography, OnboardICNg requires nodes to be pre-configured with a secret symmetric key shared with a central authority, which must then be contacted at each authentication exchange and acts as a trusted third party between the nodes in the ICN-WSN. In particular, if d j is a node trying to join the network and d nbr is a neighbour in charge of the authentication, an OnboardICNg exchange yields the following results:

1. Figure 2.1 -ICN-based protocol for authentication using asymmetric cryptography is especially critical for nodes close to the authentication server that are more solicited and whose battery would be quickly depleted. At the same time, while asymmetric cryptography is rather commonly used in association with a public key infrastructure to perform authentication (e.g., in TLS [START_REF] Rescorla | The Transport Layer Security (TLS) Protocol Version 1.2[END_REF]), it requires computationally expensive operations, which may not be a good fit for energyconstrained nodes.

d
Given that the design of an asymmetric cryptography protocol with the same security properties as the symmetric cryptography-based OnboardICNg [START_REF] Compagno | OnboardICNg: a secure protocol for on-boarding IoT devices in ICN[END_REF] is an original contribution of this work, we briefly sketch its inner working in fig. 2.1. In this scheme, each node d i has a pair of asymmetric keys K i , with its corresponding certificate C i signed by a trusted third party (e.g., the authentication server). Signing a message with a key K i is noted as DSA Ki () and RN G() is a random number generation function. To authenticate itself, a node must prove that it owns a key that has been certified by the trusted third party (messages 4 and 6). The nonces r n1 and r n2 protect the protocol against replay attacks by providing a challenge-response authentication. They can also be used to derive a symmetric session key, for instance with the Diffie-Hellman algorithm.

Network vs Energy Footprints

We estimate the footprint using two sensors, the older TelosB (with 16-bit MSP430 CPU) and a new-generation OpenMote (with 32MHz ARM Cortex-M3 CPU). We consider respectively ECC160 for asymmetric cryptography and AES-CCM-128 for symmetric cryptography. Interestingly enough, the Open- On the one hand, we observe that only 6 messages are required in asymmetric cryptography compared to 9 in OnboardICNg -a 30% reduction. Additionally, exchanges in the asymmetric cryptography case are confined to neighbouring devices, whereas in the symmetric cryptography case messages need to reach a sink point (the authorization entity). Hence, not only does asymmetric cryptography requires fewer messages, but these messages have a shorter delay and involve fewer hops in the network. These are all desirable properties that make asymmetric cryptography an interesting alternative to symmetric cryptographybased protocols such as OnboardICNg [START_REF] Compagno | OnboardICNg: a secure protocol for on-boarding IoT devices in ICN[END_REF]. On the other hand, we also gather that cryptographic functions dominate latency overhead for asymmetric cryptography -by about 8x. Similarly, energy-wise the performances are largely favourable to OnboardICNg -up to 41x. It must be noted however that the cost of transmitting messages reduces the performance gap between asymmetric cryptography and symmetric cryptography shown in table 2.2 where ECC-160 requires up to 10 4 more energy.

Given this very large performance gap, it follows that the advantages in terms of the network communication cost are completely offset by the large penalties in terms of latency and energy. This finding leads to an interesting trade-off, depending on the characteristics of the WSN: on the one-end, symmetric cryptography is less energy-and latency-consuming; on the other hand, it requires connectivity to a trusted third party even though the low-power wireless technologies used in WSN are subject to temporary network partitions due to, e.g., interference or duty-cycling. Thus, while symmetric cryptography is better suited for authentication in dynamic WSNs with reliable connectivity (e.g., dense and mobile networks such as smart cities), asymmetric cryptography is better suited to static networks with intermittent disconnections (e.g., environmental sensor networks). As mobility is one of the challenges we set ourselves to solve in this chapter, OnboardICNg [START_REF] Compagno | OnboardICNg: a secure protocol for on-boarding IoT devices in ICN[END_REF] is selected as the reference authentication protocol.

Secure beaconing

Beaconing presents two new challenges. First, unsecure beaconing opens the possibility of wormhole or DoS attacks through exhausting the neighbour database or overloading the central processing unit (CPU). Second, beaconing is essentially a push operation, which contrasts with the ICN pull model.

Security.

In order to prevent these threats, sensors must be able to distinguish between beacons originating from trusted and malicious entities. We thus use the broadcast keys provided by OnboardICNg [START_REF] Compagno | OnboardICNg: a secure protocol for on-boarding IoT devices in ICN[END_REF] to encrypt our beacons and authenticate their origin. All the subsequent messages are encrypted with the node broadcast key and contain a message authentication code (MAC). Using this encryption, ICN-WSN devices are resistant to flooding attacks from nonauthorized nodes. Indeed, only beacons encrypted with the broadcast key of authenticated neighbours are considered, and the corresponding key can only be accessed by trusted nodes. However, the scheme is not resistant to trusted nodes that have been physically tampered with.

Note that if the AES operations have to be performed in software, attackers can send packets with bogus encryption to perform a simple DoS attack against a node's CPU. However, recent platforms such as the OpenMote Section 2.4.1) are equipped with hardware modules that can perform AES computation. Therefore, these systems compute and check MAC at low CPU and energy cost. Push. To accommodate the push nature of beacons with ICN, we must slightly modify the specification of ICN exchanges, similar to the work presented in [START_REF] Tsilopoulos | Supporting diverse traffic types in information centric networks[END_REF]. Specifically, we use persistent Pending Interest Table (PIT) entries (i.e., entries that are not purged after being satisfied once) and unsolicited Data messages (i.e., Data messages that are emitted without a corresponding Interest message). We describe the beaconing protocol with the help of Figure 2.2:

(i) After an OnboardICNg association, each node creates a persistent PIT entry (e.g., with a soft timeout) for /ndb/neigh_id, where neigh_id is the id of the neighbour with whom the exchange was performed.

(ii) Regularly, each node sends a broadcast unsolicited Data packet (encrypted

REFERENCE INFORMATION-CENTRIC THINGS (ICN-WSN) ARCHITECTURE29

Interest packet

Forwarding module

Extract name (iii) Unsolicited Data packets are forwarded to the beacon processing application, thanks to the persistent PIT entry.

Persistent PIT entries and unsolicited messages have a network utilisation advantage over the traditional ICN Interest/Data exchange. Indeed, the traditional scheme requires four packets per pair of neighbour nodes (two exchanges, one per node), so a total of 4N d where N is the total number of nodes and d the average number of neighbours per node. Instead, with our scheme, each beacon is broadcast to all of the nodes in the neighbourhood, so that only N packets are required.

Deriving from the standards ICN specifications comes at a cost as the pull model is central to many aspects of the ICN architecture. One such example is congestion control [START_REF] Yi | Adaptive forwarding in named data networking[END_REF] where the Interest-to-Data balance is used to perform both receiver-based interest pacing and packet scheduling at intermediate nodes [START_REF] Carofiglio | Optimal multipath congestion control and request forwarding in information-centric networks: Protocol design and experimentation[END_REF]. Another is protecting the network against DoS attacks (specifically reflection and bandwidth depletion attacks as defined in [START_REF] Gasti | DoS and DDoS in named data networking[END_REF]) by ensuring that nodes do not receive Data packets that they have not requested with a corresponding Interest. Both of these issues can, however, be mitigated for the geographic beacons presented in this section:

-beacons are purely link-local and never routed and are thus not subjected to congestion control or packet scheduling (similarly to, e.g., IPv6

Neighbour Discovery [START_REF] Simpson | Neighbor Discovery for IP version 6 (IPv6)[END_REF]); to enforce this property, the implementation of the ICN stack should prevent creating persistent PIT entries that are not associated with an application face; -beacons are also encrypted using the broadcast key distributed during the association protocol presented in Section 2.3.1; thus, only authenticated and trusted nodes are allowed to issue unsolicited data packets.

Forwarding

Our reference ICN-WSN architecture is conceived as a framework to perform name-based and geographic forwarding in the ICN-based WSN and is thus independent of the actual variation of geographic forwarding chosen. We achieve this using the strategy layer introduced in Section 1.4.1 with the workflow summarized in Figure 2.3. In our ICN stack implementation, FIB entries match with faces and strategies. Faces can be either physical neighbours, application or virtual faces (such as the broadcast face). A strategy is a callback on the faces in the FIB, that can, for instance, select a face among the available ones with a specific metric. For instance, one could use a specific prefix (such as /g/) to forward packets through geographic forwarding by linking it to the corresponding strategy in the FIB. Interest packets destined to any other prefix would still be forwarded by name.

While our architecture allows for a variety of forwarding strategies, for quantitative performance evaluation we need to select specific geographic and namebased forwarding strategies that are implemented and executed on real IoT hardware. Routing and forwarding in the WSN world have been the subject of extensive research; we refer the reader to [START_REF] Al-Karaki | Routing techniques in wireless sensor networks: a survey[END_REF] for a taxonomy and survey of algorithms. To guide our selection, we remark that this taxonomy, which categorizes forwarding into flat/hierarchical or location-based strategies, also applies in an ICN-flavoured WSN, where the choice of using flat/hierarchical or location-based naming schemes directly maps the choice of a forwarding strategy as well [START_REF] Amadeo | Multi-source data retrieval in IoT via named data networking[END_REF].

Location-based. To select our candidate location-based strategy, we remark that most geographic forwarding techniques are based on greedy forwarding (i.e., select the neighbour closest to the destination as a next hop) with either a beacon-based [START_REF] Karp | GPSR: Greedy perimeter stateless routing for wireless networks[END_REF][START_REF] Kuhn | Geometric ad-hoc routing: Of theory and practice[END_REF] or beacon-less [START_REF] Heissenbüttel | BLR: beaconless routing algorithm for mobile ad hoc networks[END_REF][START_REF] Sanchez | BOSS: Beacon-less on demand strategy for geographic routing in wireless sensor networks[END_REF] approach. Greedy choices are complemented by recovery techniques to route around sinkholes, as in GPSR [START_REF] Karp | GPSR: Greedy perimeter stateless routing for wireless networks[END_REF] or GOAFR+ [START_REF] Kuhn | Geometric ad-hoc routing: Of theory and practice[END_REF].

The applicability of geographic forwarding to ICN has explored in a limited way, primarily as applied to Vehicle-to-Vehicle (V2V) networks [START_REF] Grassi | Navigo: Interest forwarding by geolocations in vehicular named data networking[END_REF][START_REF] Wang | MobiCCN: Mobility support with greedy routing in content-centric networks[END_REF][START_REF] Pesavento | A naming scheme to represent geographic areas in NDN[END_REF] and are designed to exploit V2V characteristics: highly dynamic, fast moving nodes with no battery/CPU constraints that receive long streams of video/audio data. In [START_REF] Ma | On networking of internet of things: Explorations and challenges[END_REF], the authors propose an ICN-WSN routing scheme based on geographic coordinates. However, their proposal assumes a tree-like topology and does not account for potential sinkholes. We additionally note that, despite the availability of many geographic forwarding algorithms in the literature, there are few implementations; e.g., even the most basic and best-known approaches, such as GPSR [START_REF] Karp | GPSR: Greedy perimeter stateless routing for wireless networks[END_REF], are not available in modern IoT toolboxes [START_REF] Hahm | Operating systems for low-end devices in the internet of things: A survey[END_REF] such as Contiki [START_REF] Dunkels | Contiki -a lightweight and flexible operating system for tiny networked sensors[END_REF] or RIOT [START_REF] Baccelli | RIOT OS: Towards an OS for the internet of things[END_REF]. As a representative of location-based strategies, we implemented GPSR [START_REF] Karp | GPSR: Greedy perimeter stateless routing for wireless networks[END_REF], a classic and well-understood strategy based on a geographic greedy forwarding algorithm. The implementation of GPSR is made available as open-source [START_REF] Enguehard | marceleng/geographic-icthings: Code for the paper: On the cost of geographic forwarding for information centric things[END_REF].

In addition to destination coordinates (that are part of a name under the /g/ prefix), GPSR also requires additional information for the forwarding. Indeed, to avoid local maxima (cases where the current node is closer to the destination than any of its neighbours), GPSR uses a technique called "perimeter routing", which requires the packet to carry the coordinates of the node where it entered the perimeter mode. The ICN-WSN architecture stores this information in a Type Length Value (TLV) field as described in Figure 2.4, where a flag determines whether the GPSR is in greedy or perimeter mode. Given that we expect the reference ICN-WSN architecture to be used in different scenarios (dense deployment in urban buildings as opposed to sparse deployments in large rural areas), it may be desirable to provide the capability to adjust the coordinate resolution to a specific application scenario to avoid overhead. As a result, the architecture also supports the use of different resolutions for geographic coordinates: as Figure 2.4 outlines, 2 bits in the flags, noted as s l , allow to specify from 8 to 64 bits coordinates, in step of 8 bits.

Name-based. The matching between Interest names and output faces in the ICN-WSN FIB is usually done using longest-prefix match. Simple flood-andlearn (F&L) forwarding strategies [START_REF] Baccelli | Information centric networking in the IoT: Experiments with NDN in the wild[END_REF][START_REF] Hail | Caching in named data networking for the wireless internet of things[END_REF] (and variants [START_REF] Anastasiades | Dynamic unicast: Informationcentric multi-hop routing for mobile ad-hoc networks[END_REF][START_REF] Amadeo | Named data networking for IoT: An architectural perspective[END_REF]) are typically used in ICN-WSN to construct FIBs on demand. These are inherently non-scalable and possibly a bad fit for IoT deployments. As such, while we do implement F&L for reference purposes, we do also argue for the need to complementing it with additional techniques to reduce broadcast storms. Particularly, we opt for a Multi-Point Relay (MPR) [START_REF] Qayyum | Multipoint relaying for flooding broadcast messages in mobile wireless networks[END_REF] variant inspired by the Optimized Link State Routing Protocol (OLSR), where at each hop during the message propagation, only a few relays are selected out of those having received the message. However, while implementing naive F&L is simpler than implementing GPSR, implementing a full-blown MPR distributed OSLR-like protocol is not. In particular, F&L and MPR performance will not only differ in the number of messages sent over the network (which we can simulate) but will also differ in the computational complexity (which we should measure from an actual implementation). We can approximate the computational cost of MPR with the computational cost of the simpler F&L strategy to provide a conservative evaluation of the energy efficiency of MPR for comparison with GPSR. Therefore, we prototype only the simpler F&L for the purpose of measuring the computational cost in Section 2.4.3, and simulate an ideal MPR for the purpose of gathering a lower bound of the number of messages transmitted by MPR over a network in Section 2.6.2. In particular, our ideal MPR implementation exploits global knowledge available in simulation to find a minimal set of MPR relays, providing a lower bound on the message complexity. These choices guarantee a conservative evaluation of the potential benefits of geographic GPSR over name-based MPR.

Methodology overview

In this section, we define the lines along which we evaluate the costs of using name-based and geographic forwarding strategies in ICN-WSN deployments. In ). We consider memory and CPU metrics as tied to the feasibility of an ICN-WSN deployment, whereas we use the energy consumption to quantify the cost of ICN-WSN operation. We found that assessing memory and CPU costs is significantly simpler than assessing the overall energy budget, which, therefore, is the main contribution of our investigation. We thus set to solve the following problem: under which conditions (if any) is geographic forwarding more performant in terms of energy, memory, and CPU consumption than flood-based strategies for the ICN-WSN?

A complex system such as a WSN deployment is influenced by numerous factors (that are recapped and summarized further on in Table 2.6). Therefore, we employ a range of methodologies. At each step of our evaluation, we select the most appropriate one to estimate values that have practical relevance for the different variables. This section defines our ICN-WSN experimental model and enumerates the various sources of energy consumption. Sections 2.5 and 2.6 combine measurement from an actual ICN-WSN implementation with stochastic modelling of L2 transmission and simulation of network-wide scenarios to populate the different components of the model, including security, forwarding, data plane traffic, and control plane overhead. The refined model is then quantitatively analysed to provide guidelines on the most favourable ICN-WSN settings for the different WSN deployment classes and scenarios (Section 2.7).

Experimental setup

While our methodology to evaluate the cost of secure geographic forwarding in the reference ICN-WSN architecture is general, the quantitative aspects reported in this chapter are relevant for the hardware and software setup with which we conducted our evaluation. To make them of interest to the largest possible audience, we selected widely used open-source hardware (OpenMote [START_REF] Vilajosana | OpenMote: Opensource prototyping platform for the industrial IoT[END_REF]) and software (RIOT OS [START_REF] Baccelli | RIOT OS: Towards an OS for the internet of things[END_REF]) stacks.

Hardware setup. The OpenMote platform has a 32 MHz ARM Cortex-M3 CPU and is equipped with an IEEE 802.15.4 chipset as well as hardware modules for symmetric and asymmetric cryptography. To evaluate the cost of hardware cryptography and of receiving or transmitting packets through the IEEE The energy consumption figures for this platform are provided in the corresponding datasheet [START_REF]CC2538 Powerful Wireless Microcontroller System-On-Chip for 2.4-GHz IEEE[END_REF], which we summarize along with other characteristics in Table 2.4.

Software setup. Our code runs on top of the RIOT operating system [START_REF] Baccelli | RIOT OS: Towards an OS for the internet of things[END_REF].

We implement a custom ICN stack on top of RIOT that uses standard ICN forwarding (i.e., longest-prefix match in the FIB) as well as GPSR (with perimeter routing as introduced earlier). To accommodate the typically low frame sizes of WSN (e.g., 127 bytes for IEEE 802.15.4 networks), adaptations to the TLV-based format of ICN packets have been proposed. Following the recommendations in [START_REF] Mosko | CCN and NDN TLV encodings in 802[END_REF], we implement 1+0 TLVs (i.e., where the Type and Length field are encoded in one single byte), instead of the 1+1 or 2+2 format described in the CCNx specifications [START_REF] Parc | The CCNx project[END_REF], with which our implementation is otherwise fully compliant.

Memory

Memory is a primary constraint in WSN. For example, an old platform such as the MSP430-based TelosB only offers 10KB of random-access memory (RAM) and 48KB of flash memory. Even recent hardware like the OpenMote includes only 32KB of RAM and 512KB of flash memory. This amount is still tiny considering that recent implementations of an ICN-WSN stack require already between 5KB [START_REF] Baccelli | Information centric networking in the IoT: Experiments with NDN in the wild[END_REF] and 11KB [START_REF] Shang | The design and implementation of the NDN protocol stack for RIOT-OS[END_REF] of RAM. Additionally, optimizing memory consumption is especially interesting in the context of ICN, where caching can be used to accommodate nodes with low duty-cycles [START_REF] Hahm | A named data network approach to energy efficiency in IoT[END_REF].

When considering memory requirements, geographic forwarding has advantages over name-based forwarding. Indeed, under geographic forwarding the size of the state retained by a node to be able to forward any packet is bounded by the node degree, whereas under F&L (and variants) each node needs to retain some state for the name of every other node. In fixed ICN networks, state explosion is alleviated by using prefix aggregation in the FIB. However, this is hardly possible in highly-dynamic and mobile WSNs, and to the best of our knowledge no aggregation scheme has been proposed for ICN applied to WSNs.

Memory requirements can be computed considering that under geographic forwarding, the FIB contains the coordinates (having size s l ) of all its d neighbours, and that the beaconing protocol described in Section 2.3.2 additionally requires nodes to store a persistent PIT entry (having size s pit ) for each of their neighbours. Under classic name-based forwarding, ICN requires having one FIB entry (having size s f ib ) for each of the n s reachable names. As no aggregation scheme is currently available for dynamic WSN topologies, n s is equal to the number of nodes in the WSN. This means that each node has a FIB entry for every other node in the network. To compute the required memory, it must be noted that both FIB and PIT entries also contain a 1-byte pointer to an ICN face and that a FIB entry also contains a 1-byte pointer to a strategy. We can thus express the respective memory requirements as:

M geo = d(s l + s pit ) = d(s l + s n + 1) M f ib = n s × s f ib = n s (s n + 2) (2.1)

Computation

CPU power is another strong constraint on IoT platforms: this holds for both old platforms such as TelosB (16-bit CPU clocked at 8 Mhz), as well as for newer platforms such as the OpenMote (32-bit CPU clocked at 32MHz). An inefficient forwarding algorithm on a slow processor can delay message forwarding, causing congestion in the network.

We remark that the CPU complexity of a forwarding algorithm is also inherently dependent on the underlying hardware: for instance, multiplication on 32-bits integers is much faster on newer 32-bit CPUs than older 16-bit ones. It is thus only possible to evaluate the strength of a forwarding implementation with respect to a specific platform. More specifically, we can evaluate the number of CPU cycles n c (algo) required in a given assembly language for a specific implementation of any given strategy and then compute the corresponding energy E CP U consumed by the CPU given its frequency f CP U and its power drain

E CP U (algo) =P CP U t CP U (algo) =P CP U n c (algo) f CP U (2.2)
To devise an accurate model, we need a method to reliably measure the number of cycles n c (algo). Given that CPU emulators or static code analysis are subject to low accuracy [START_REF] Roussel | Using Cooja for WSN simulations: Some new uses and limits[END_REF], we opt for micro-benchmarking the different pieces of the reference ICN-WSN architecture code with cycle-level accuracy, using a simple yet powerful technique. To accomplish micro-benchmarking, we use a special register of the Cortex-M3 CPU dedicated to counting CPU cycles2 . This register is directly mapped in memory and can be accessed on RIOT through the DWT->CYCCNT variable, without performance penalty. An example of the micro-benchmark code is presented in listing 2.1.

Energy

The energy cost of a specific ICN-WSN implementation comes from three main sources: a computational cost related to the forwarding algorithms, a security cost related to cryptographic operations and message exchanges due to the security protocol, and a network cost related to point-to-point communication, end-to-end transmission, and network maintenance.

During the overall lifetime of an ICN-WSN deployment, network cost can be split into bootstrap, forwarding of Interest/Data packets, and handling of route failures, all of which are clearly dependent on the forwarding strategy employed. Network bootstrap is the cost of setting up the forwarding for the full network to be able to forward packets from any node to any other. Once routes are set up, communication under different forwarding strategies incurs different costs. Indeed, the amount of energy spent for forwarding depends on the computational cost of the forwarding algorithm, on communication costs because of additional state embedded in the Interest packets, and on the different numbers of relays under each algorithm. Finally, handling route failure is an operation common to volatile environments such as WSN deployments, where routes to content can become unavailable due to mobility or poor channel conditions. Reacting to this failure triggers the (re)discovery of a path, a costly operation that must be considered and whose cost depends on the forwarding strategy.

In our evaluation, we assume that network load is uniformly distributed over the ICN-WSN network, i.e., that each node forwards probabilistically the same amount of traffic. This simplifying assumption, necessary for the tractability of the model, is justified by the fact that we consider networks with either user/sensor mobility or machine-to-machine communications, which tend to make the existence of a single hotspot sink less prevalent. Furthermore, we do not aim at precise absolute evaluation of the network energy spending in a specific scenario but at a relative comparison of name-based and geographic forwarding for the ICN-WSN. We can then compute the total network cost by summing the E bootstrap , E f orwarding and E change network-related components as follows:

E total = E bootstrap + N m E f orwarding + N m f c E change = N m E f orwarding + (1 + N m f c )E change (2.3)
where N m is the number of useful ICN queries (i.e., expression of Interest satisfied by a Data packet in a multi-hop fashion) and f c is the number of queries performed between two route changes. Intuitively, f c represents the level of dynamism in the network, which lumps altogether phenomena such as (i) the addition/removal of new names or sensors, (ii) mobility of physical devices, (iii) route failure due to the wireless medium. Arguably, E bootstrap is a one-time cost with vanishing impact over time, so we approximate it with E booststrap ≈ E change , i.e., the control-plane cost of repopulating a FIB. E f orwarding instead represents the energy cost of a single query in the WSN once the FIB is already populated, and as such accumulates the data-plane costs to transmit an Interest over several hops in the network as well as the cost of receiving the corresponding Data packet travelling in the opposite direction. E f orwarding and E change are addressed in Section 2.5 and Section 2.6 respectively. Finally, it must be noted that the number of messages N m is not a design parameter. Rather, we can re-express Equation (2.3) to infer the total number of exchanges N m that are possible, as a function of the network dynamism f c , under different forwarding strategies:

N m = E total -E change E f orwarding + 1 fc E change (2.4)
Without loss of generality, in Section 2.7 we exploit Section 2.4.4 where we equate the total energy budget to the amount of energy available in standard AA batteries, i.e., E total = E AA .

Cost of forwarding a single ICN packet

In this section, we set out to evaluate the energy spent by a node to forward a single ICN packet as the first refinement of our energy model. We then evaluate this model for the OpenMote, using our own experiments and data gathered from the literature. From the point of view of a relay, the packet forwarding process can be divided into 5 steps, namely: (i) frame reception, (ii) frame decryption, (iii) forwarding face selection through the forwarding strategy,

Frame transmission and reception

The transmission and reception cost of an ICN packet is given by the amount of time that the node's antenna has to be powered in transmission (TX) and reception (RX) mode. Since the power consumption P tx (resp. P rx ) of the platform is dependent on the hardware and available from the data sheets provided by the manufacturer, only the transmission time needs to be computed.

At any hop, the transmission time is driven by two factors: the number of retransmissions that are necessary for a successful reception on the wireless medium and the size of the message (which impacts the time taken by each retransmission). Let n tr,s (p c ) be the average number of tries necessary for successful transmission on a channel with collision probability p c and capacity C phy . The transmission cost of a frame of size s f is then given by:

E tx (s f ) = P tx s f C phy n tr,s (p c ) = E b tx s f n tr,s (p c ) (2.5)
The reception cost can be similarly derived. Let M tr be the maximum number of L2 retransmissions of a given frame (after which the frame is dropped). For a given p c , we have that n tr,s (p c ) is, in 6 of [START_REF] Shafagh | Talos: Encrypted query processing for the Internet of Things[END_REF] expectation:

E[n tr,s (p c )] = Mtr k=1 kP (k L2 transmissions needed) = Mtr k=1 kp k-1 c (1 -p c ) = 1 -p Mtr c (M tr + 1) + p Mtr+1 c M tr 1 -p c (2.6)
We stress that p c is not a system parameter but depends in turn on other properties of the ICN-WSN deployment, such as node density and radio range. We come back to p c in Section 2.6.

Data Encryption and Decryption

The cost of cryptography depends on the device's capabilities, such as CPU characteristics, and more importantly on the availability of hardware cryptography components. We present the energy consumption of AES-CCM encryption in the OpenMote platform, considering both software-and hardwareassisted cryptography as a function of the message's size in Figure 2.5.

For the software implementation, we microbenchmark the AES implementation of the crypto module of RIOT with the previously outlined technique. Figure 2.5 provides the measurements as well as an equation derived from the measurements. For the hardware-assisted encryption, we point out that cryptography hardware modules are not yet supported on RIOT: we thus use as a reference the AES-CCM measurement reported in Table 6 of [START_REF] Shafagh | Talos: Encrypted query processing for the Internet of Things[END_REF]. The picture clearly shows the importance of hardware modules for cryptographic operations: the AES-CCM software implementation consumes up to 5 times more energy than its hardware-assisted counterpart. In hardware, AES-CCM has a maximum cost of 10 µJ per packet (since the IEEE 802.15.4 maximum transmission unit (MTU) is 127B).

In the rest of the chapter, we assume that the platform is equipped with a hardware module that is accessible through an API of the software stack (as planned in RIOT). With hardware-assisted encryption, as Figure 2.5 shows, we can assume that costs for encryption/decryption are constant with respect to the frame size. Finally, given that encryption/decryption costs are not the main components of packet transmission, for the sake of simplicity, we assume that encryption and decryption have an equal cost, which we indicate with E AES .

Forwarding algorithm

Deducing the cost of the forwarding algorithm is fairly simple: Equation (2.2) requires a microbenchmark of the forwarding code to accurately measure the number of CPU cycles required to perform either name-based ICN forwarding (i.e., longest-prefix match in the ICN FIB) or GPSR forwarding operations. Note that in this section, we do not yet consider the control traffic, but the name-based FIB would typically be populated using F&L or MPR. These measurements are reported in Figure 2.6, which shows boxplots of the number of CPU cycles as a function of the number of entries in the FIB (for name-based ICN) or the number of neighbours of the node (for GPSR) in the x-axis. Incidentally, the figure shows a linear correlation between CPU consumption and memory occupancy irrespectively of the forwarding algorithm. As expected, geographic forwarding grows more steeply than name-based forwarding (621 cycles per additional neighbour versus 71 cycles per additional FIB entry). Indeed, geographic forwarding requires the node to perform floating point multiplications to compute the distance to the next hops, while name-based forwarding only requires byte comparisons. It must be noted that we could implement geographic forwarding using fixed-point arithmetic or on a more recent CPU with embedded support for floating-point operations. However, while this would narrow the performance gap, geographic forwarding would still be more expensive in CPU cycles than the byte comparisons used by name-based forwarding.

While the gap between geographic and name-based forwarding appears to be important, it is just one component of the overall cost, which we detail in the next section.

Overall cost

We can now express the total cost for a node to relay an ICN packet as:

E relay (algo, s) = E tx (s) + E rx (s) + 2E AES + P CP U n cycles(algo) f CP U (2.7)
It should be noted that since Data packets are forwarded through symmetric routing, they are not concerned by the computation overhead. Considering both the Interest and the Data packet, the forwarding cost per node adds up to:

E relay (algo) = E relay (algo, s i ) + E relay (exact-match, s c ) (2.8)
Finally, we can summarize E f orwarding as the cost of forwarding an Interest packet and its corresponding Data packet over a multi-hop network by considering that on the path we have: (i) T -1 relay nodes that must perform both TX and RX operations, (ii) a source node that only performs TX for the Interest and RX for the Data packet, and (iii) a destination that performs only RX for the Interest and TX for the Data packet. This can be rewritten as T relay nodes performing both TX and RX operations for both packets:

E f orwarding = T (E relay (algo, s i ) + E relay (exact-match, s c ))
(2.9)

In Figure 2.7, we represent the respective costs of each of the different components for the reference use cases in Table 2.1 with the corresponding numbers of FIB entries, neighbours and the size of the name. In particular, we group transmission and reception costs, and present them as L2 IEEE 802.15.4 and L3 ICN components, on which the cryptographic and forwarding costs are stacked. For each reference use case, we gather d and n s from the literature, then compute s n = log 2 (n s ), and finally select a size of s l relevant to the geographic scale of the use case (i.e., depending on the coordinate resolution).

From Figure 2.7, it clearly emerges that RX and TX operations are the predominant factors of energy consumption (even though they are actually underestimated as we do not account for MAC layer signalling nor idle listening [START_REF] De Meulenaer | On the energy cost of communication and cryptography in wireless sensor networks[END_REF]). The communication cost is two orders of magnitude higher than the cost of forwarding (software), even for geographic forwarding with numerous neighbours, and one order of magnitude higher than the cost of cryptography (hardware).

Notice that the cost of software forwarding lumps together energy expenditures related to CPU (selecting the forwarding face) and memory (storing and updating the neighbour table or the FIB), which are clearly negligible w.r.t. the energy spent on cryptographic and network operations. Hence, to summarize:

-the principal overhead in energy consumption when using GPSR is the increased header size included in each Interest packet because of the GPSR TLV,

-the complexity of the forwarding algorithm is clearly negligible and Equation (2.7) becomes:

E relay (algo, s) ≈ E tx (s) + E rx (s) + 2E AES (2.10)

Cost of control traffic

An additional source of energy consumption is the background control information that is needed to discover routes to new names, new neighbours, and to maintain the network connectivity in spite of changes such as node mobility. That cost is intrinsically related to the geographic (Section 2.6.1) or floodingbased (Section 2.6.2) forwarding algorithm employed. In this section, we thus build a model to derive the energy consumption of the network forwarding process (data and control plane). We complete this model with simulation to estimate the spread of flooding for the F&L and MPR algorithms.

Geographic forwarding

For geographic forwarding, control information takes two forms: (i) the beacons to transmit geographic information between neighbours, and (ii) the additional GPSR TLV in the Interest packet to transmit per-packet forwarding state along the path. We now review the cost of both factors, which we summarize in Table 2.7.

Beacons. Beacons are the most obvious source of control overhead in geographic forwarding. As described in section 2.3.2, they are local (i.e., not routed) broadcast messages that do not propagate in the network and only reach the nodes involved in the L2 broadcast.

Let us consider a node whose immediate neighbourhood has changed: this node must broadcast its current position to its new neighbours, and receive the d broadcast messages from its neighbours. Given s b the size of a beacon message, the energy E change required for this update by each node is simply:

E GP SR change = (s b n tr,s E b tx + E AES ) + d(s b n tr,s E b rx + E AES ) (2.11)
Headers. On top of the beacons, additional control information for GPSR is embedded in every Interest packet through the TLV described in Section 2.3.3. As shown in Figure 2.4, this TLV contains both a flag for the forwarding mode (greedy or perimeter) and a set of coordinates. Thus, the size s i,g of an Interest packet for geographic forwarding is:

s i,g = s i + 2 + s l (2.12)
As we have seen in Figure 2.7, we expect the extra control fields in the headers to have a sizeable impact on data traffic, lowering the efficiency of GPSR with respect to name-based forwarding. We can now plug s i,g in Equation (2.9) and using Equation (2.10), we get:

E GP SR f orwarding = T 4E AES + n tr,s (s i,g + s c )(E b rx + E b tx ) (2.13)
At the same time, we expect the benefits of GPSR to come primarily from keeping the amount of FIB state bounded to the number of neighbours and limiting the exchanges at a local level, unlike F&L-based strategies.

Flood and learn

In the case of name-based forwarding, despite similar forwarding operations, the data-plane energy is lower due to the smaller Interest size (s i < s i,g ):

E F &L f orwarding = T 4E AES + n tr,s (s i + s c )(E b rx + E b tx ) (2.14)
However, we need to the estimate the cost of learning routes to objects in an F&L-based ICN-WSN deployment:

E F &L change = N tr (T, d) n tr,s 2E AES + N tr (T, d)(E b rx + E b tx )s i (2.15)
Therefore, we have to determine the number of network-wide transmissions required to update FIB information N tr (T, d), for which we model the propagation of a flooded packet over a wireless multi-hop network. Let us consider a uniform random geographic graph G(N, d) where N is the number of nodes in G and d the average node degree, and let focus on a message m that must be flooded over the WSN with a maximum Time-To-Live (TTL) of T . Denoting with N tr (T, d) the number of times m has been transmitted during its propagation, including L2 retransmissions, we have:

E[N tr (d)] = T -1 t=0 E[n t tr (d)] (2.16)
where n t tr (d) is the number of times the message m is transmitted at the t-th hop (i.e., for a TTL=Tt). Letting V t be the set of nodes that relay message

E[card(V F &L t )]/E[card(V MP R t )] d = 4 d = 10 d = 14
Figure 2.9 -Ratio between average values of card(V t ) for naive F&L and MPR m at hop t, and recalling that n tr,s (m) is the number of transmission attempts until a successful transmission, we have:

n t tr (d) = i∈Vt n tr,s (p c ) (2.17)
and thus:

E[n t tr (d)] = E[card(V t )]E[n tr,s (p c )] (2.18)
To estimate the number of nodes card(V t ) transmitting the message at the t-th hop, we simulate the packet propagation for both F&L and MPR. For this purpose, we have developed multi-threaded programs that we have made available to the community [START_REF] Enguehard | marceleng/geographic-icthings: Code for the paper: On the cost of geographic forwarding for information centric things[END_REF]. The tools generate random graphs with a given density and number of nodes and use a custom version of breadth-first search to compute card(V t ) in the case of naive F&L. In the case of MPR, they compute the set of MPR-neighbours using the greedy algorithm described in [START_REF] Qayyum | Multipoint relaying for flooding broadcast messages in mobile wireless networks[END_REF]. For any given density, we sample a population of 10 5 random graphs on which we evaluate the number of transmissions for naive F&L and MPR from a random source. We run the simulations on a Linux 4.7 server with an Intel Xeon CPU clocked at 2.40GHz: for each density, the simulation takes about 9 hours, where the dominant3 time is represented by the MPR strategy. As simulation time is rather long, we also provide on our GitHub the results of our simulation rounds as well as a Jupyter Notebook to explore them.

Figure 2.8 presents simulation results for the number of messages generated by naive F&L (left) and MPR (right) as a function of Tt ∈ [0, 15] (x-axis) and for different density values d ∈ [START_REF] Cook | CASAS: A smart home in a box[END_REF][START_REF] Abdelhamid | Vehicle as a mobile sensor[END_REF]. To quantify the advantages brought by MPR, Figure 2.9 additionally reports the ratio of the messages generated by F&L over MPR. Interestingly, regardless of the density, MPR roughly halves the number of messages that need to be flooded at each step. To perform a conservative assessment of the benefits of geographic forwarding, we thus only consider MPR as a benchmark.

Finally, plugging in Equation (2.18) the card(V t ) measured in simulations, we can accurately numerically estimate the forwarding cost of flood-based strategies:

E[N tr (d)] = T -1 t=0 E[card(V t )] 1 -p c (d) Mtr (M tr + 1) + p c (d) Mtr+1 M tr 1 -p c (d) (2.19)
where the collision probability p c (d) for IEEE 802.15.4 is given in [START_REF] Pollin | Performance analysis of slotted carrier sense ieee 802.15.4 medium access layer[END_REF] as a function of the average node degree (that is referred to as p netcol in [START_REF] Pollin | Performance analysis of slotted carrier sense ieee 802.15.4 medium access layer[END_REF]).

Results for Equation (2.19) are reported in Figure 2.10.

Guidelines for ICN-WSN operation

Using these results, we can systematically compare MPR and geographic forwarding for both energy (Section 2.7.1) and feasibility (Section 2.7.2) metrics. In particular, we apply the models derived in Section 2.5 and Section 2.6 to the four WSN reference deployments of Section 2.2, considering a network of OpenMote devices. Readers or ICN-WSN operators interested in other network characteristics are referred to our Jupyter Notebook 4 , whose interactive interface can be used to explore more scenarios. For convenience, we summarize the main parameters in the evaluation in Table 2.6, as well as their default scalar or functional values when relevant.

Energy cost

Having modelled the energy budget required to transmit N m exchanges, we can derive the number of Interest/Data exchanges for name-based forwarding (N F &L m ) and geographic forwarding (N GP SR m ) that can be completed with the energy available in one AA battery (E AA = 15 kJ [START_REF] Nisimova | Energy of a 1.5 V battery[END_REF]). For completeness, the message budgets are reported in Equation (2.20) and Equation (2.21).

4. https://github.com/marceleng/geographic-icthings/blob/master/models/ geographic-icthings.ipynb These equations provide a metric for measuring the efficiency of both protocols: the number of possible Interest/Content exchanges (N m ) for a given battery capacity, depending on the density d, the average number of hops T and the topology change ratio f c . Figure 2.11 shows the ratio between N GP SR m /N M P R m (i.e., the relative message budget of GPSR vs MPR) depending on the network size n nodes (y-axis) and the average node degree d (x-axis). In this figure, the lighter the heatmap, the more efficient geographic forwarding is with respect to MPR. Without loss of generality, we select T = 8 and f c = 60, which corresponds to the case where, if an Interest/context exchange happens every minute, then a route change happens every 1 hour.

N M P R m = E AA - N tr (T ,d) n tr,s 2E AES + N tr (T , d)s i (E b rx + E b tx ) N tr (T ,d) n tr,s 2E AES + N tr (T , d)s i (E b rx + E b tx ) /fc + T 4E AES + n tr,s (s i + sc )(E b rx + E b tx ) (2.20)
Several conclusions can be drawn from Figure 2.11. First, let us note that the ratio takes values N GP SR m /N M P R m ∈ [0.95, 1.05], i.e., the respective performances of name-based and geographic forwarding are close for these (T ,f c ) settings. The inflexion point in the figure is caused by a change in the MPR regime: i.e., at some point, the network becomes big enough so that the flooding stops because of the TTL, rather than because everyone in the network already received the packet. Also, note that in these settings, 3 (out of 4) reference deployments (A, B, D) sit below the N GP SR m = N M P R m contour and would thus (slightly) benefit from using MPR. Finally, it is easy to see that for an average node degree higher than 7 and a deployment size larger than 100 nodes, geographic forwarding performs (slightly) better than MPR. We next turn our attention to dynamic cases where we vary the rate at which the network changes (e.g., due to node churn, mobility, deployment of new nodes, etc.). Specifically, f c represents the number of consecutive data plane exchanges between two changes requiring control plane messages. We let f c ∈ [1, 10 4 ], so that for f c = 1 there is a significant control plane overhead, whereas for f c = 10 4 the network is mostly stable. We report the raw number of Interest/Data messages on an AA battery as a function of f c for the four reference deployments on Figure 2.12. Two main observations hold. First, for networks with frequent changes geographic forwarding is up to twice as efficient as MPR for all considered scenarios. Second, it can be seen that MPR is slightly more efficient than geographic forwarding over relatively stable networks, although the difference is small enough not to have practical relevance. Thus, GPSR seems a good candidate for dynamic scenarios, while both GPSR and MPR can be used in stable topologies at approximately the same cost.

Memory and CPU complexity

Finally, we concisely summarize the CPU and memory footprint of geographic forwarding and F&L-based strategies in Figure 2.13. The contour plots show the relative footprint of GPSR versus F&L ICN, while the heatmap illuminates areas where GPSR is advantageous on both criteria (white), only in memory (grey) or in neither (black). The letters show the respective positions of the use cases described in Table 2.1. The picture shows that GPSR has a lower memory footprint when the number of FIB entries inflates, which is an important factor on memory-constrained nodes in networks where numerous names must be accessible. In particular, three of the use cases (A, B, and D) require less memory and CPU resources using GPSR rather than with name-based forwarding. Furthermore, while CPU consumption is often favourable to F&L ICN, GPSR is faster in sparse but large networks (e.g., n f > 40 and d < 5). Overall, there are no CPU/memory obstacles to implement geographic forwarding in ICN-WSN. Rather, GPSR can provide memory savings with respect to name-based forwarding, an appealing advantage for constrained environments.

Summary

In this chapter, we introduce a generic ICN architecture for WSNs, able of performing secure geographic forwarding. We use this framework to assess the CPU/memory feasibility of geographic forwarding as well as to derive energy models for geographic and name-based forwarding that encompass all networkrelated activities of a WSN. We implement GPSR in a RIOT-based ICN stack and contrast it to naive flooding, as well as to an improved flooding technique using Multi-Point Relay (MPR).

In summary, we find that GPSR-based forwarding is feasible in ICN-WSN. Specifically, GPSR memory requirements are lower than that of flood-based strategies. Additionally, while algorithmic complexity increases when using GPSR over flooding-based strategies, the required CPU resources are a negligible component of the overall energy cost. Indeed, the cost of security (including cryptographic operations and network overhead) is at least one order of magnitude higher than the computation cost of the forwarding algorithm, which can, therefore, be neglected.

In terms of energy consumption, two opposite forces are in play: the increased header size in the case of GPSR translates into higher energy cost per unit packet while GPSR keeps beaconing local, lowering the cost of network-wide updates. As such, while there is a clear incentive in using GPSR for dynamic networks requiring frequent updates, the performance gap in the case of networks with stable topologies and infrequent changes is slightly favourable to flood-based strategies. At the same time, that gap remains small and it should not be a limiting factor for the use of GPSR in ICN-enabled WSNs.

Chapter 3

Enforcing latency-control in the Fog via popularity-aware admission control While sensor networks are not only useful for generating data but can implement primary levels of environment automation, many IoT applications require consequent computing or storage resources and thus cannot be implemented on low-power nodes such as the ones described in Chapter 2. Complementary to the study of routing in WSNs is thus the study of routing and forwarding data extracted from the WSNs towards the corresponding applications. In that regard, as discussed in Section 1.1.2, two complementary platforms have emerged: the Cloud, located in a large data centre designed for scale, and the Fog, located at the edge of the network for latency-constrained applications. In this chapter, we consider the problem of controlling admission to a Fog platform (and offloading the refused traffic to the Cloud) so as to guarantee an average response time. In particular, exploiting the request-awareness provided by ICN, we look at how network-level popularity estimation can be used to realize line-rate, low-latency, efficient admission control for a Fog deployment.

Admission control for QoS in Fog deployments

The emergence of low-latency applications in the IoT has created a need for computing and storage platforms located geographically and topologically close to the access. Introduced as an extension of the Cloud at the network edge for computing and storage purposes [START_REF] Bonomi | Fog computing and its role in the internet of things[END_REF], the Fog is a highly virtualized, potentially distributed, computing and storage platform placed at the edge of the network and capable of processing IoT data under low latency. Since its definition, there has been a growing interest in the research community for Fog computing, encompassing areas such as workload placement [START_REF] Hong | Mobile fog: A programming model for large-scale applications on the internet of things[END_REF], caching [START_REF] Khan | A content-based centrality metric for collaborative caching in information-centric fogs[END_REF][START_REF] Wang | Fog computing based contentaware taxonomy for caching optimization in information-centric networks[END_REF], or application profiling [START_REF] Chen | An empirical study of latency in an emerging class of edge computing applications for wearable cognitive assistance[END_REF]. Accelerated by the advent of 5G, the Fog is expected to play a key role for IoT applications in cases where latency requirements and/or security reasons preclude the use of a Cloud-only approach.

Fog platforms are not intended as a replacement for Cloud processing, rather as a complementary computing and storage platform to use if and whenever beneficial. For instance, with frameworks such as AWS Greengrass [148], IoT providers can use their own devices (e.g., an IoT gateway or a local compute node) to perform some stateless pre-processing of data on its path to the Cloud. In addition, the Fog does not enjoy the same elasticity as the Cloud. Indeed, while Cloud data centers inherently scale thanks to their size and their high number of tenants, Fog nodes have strong physical limits that cannot be infringed. Thus, sudden bursts of requests, e.g., flash crowds, can greatly increase application response time and raise scalability issues for Fog deployments. In such cases, the natural solution is to redirect part of the Fog load to the Cloud [START_REF] Niu | Handling flash deals with soft guarantee in hybrid cloud[END_REF][START_REF] Du | Computation offloading and resource allocation in mixed fog/cloud computing systems with min-max fairness guarantee[END_REF]. However, if done incorrectly, that could actually worsen the response latency. Furthermore, renting compute and storage power in the Cloud is expensive, as opposed to user-owned Fog devices. In this chapter, we thus investigate the following question: how to minimize Cloud costs while offering statistical latency guarantees in case of sudden bursts of requests in a Fog network?

As described in Section 1.1.3, IoT applications can roughly be categorized in three QoS categories: (i) latency-critical, where processed data must be received within 1-10 ms, (ii) latency-sensitive, where the expected response time is of the order of 100 ms [START_REF] Miller | Response time in man-computer conversational transactions[END_REF], and (iii) latency-tolerant, that have no specific delay constraint. Whereas latency-critical applications cannot run in the Cloud (but rather in the device or at Fog level), latency-tolerant applications would naturally be deployed there. Thus, Cloud redirection is most relevant for applications of the latency-sensitive class, where the computing bottleneck in the Fog may force to offload part of request processing to the Cloud. At the same time, the use of faraway Cloud resources not only increases the cost for the operator but may also increase the service latency. There is thus a need for clever Fog admission control (AC) to keep response time bounded.

In this chapter, an approach for Fog admission control is presented that relies on using request popularity to optimize the usage of the Fog platform, and in particular of the caching capacities of the Fog. Specifically, two AC strategies are introduced: the LFU-AC, which exploits perfect knowledge of the request popularity distribution and the LRU-AC, which is based on statistically estimating the most popular requests by using a cache on request identifiers with the Least-Recently-Used (LRU) policy. Using an analytical model, the LFU-AC is shown to provide sizeable benefits over optimized request-agnostic AC strategies. The LRU-AC performance is also shown to be close to the LFU-AC bound.

A system implementation of the LRU-AC strategy on programmable hardware is then proposed, thus allowing for a line-rate, low-latency deployment that does not require provisioning extra computing resources. As implementing an LRU cache in hardware is inconvenient due to the necessity of using linked-list structures [START_REF] Blott | Achieving 10Gbps line-rate key-value stores with FPGAs[END_REF], an implementation of the LRU-AC using Ageing Bloom Filters (ABF) [START_REF] Yoon | Aging bloom filter with two active buffers for dynamic sets[END_REF] in NetFPGA [START_REF] Zilberman | Net-FPGA SUME: Toward 100 gbps as research commodity[END_REF] is proposed. An analytical model of the expected hit-rate of the ABF is built to guarantee its behaviour w.r.t. the LRU-AC. The use of an ABF is shown to reduce memory footprint by up to 4, making the implementation fit within memory sizes available in programmable hardware devices. The implementation relies on hICN [START_REF] Muscariello | Hybrid Information-Centric Networking[END_REF], an ICN protocol that uses the semantic of IP/TCP for backward compatibility. Using the P4 framework [START_REF] Bosshart | P4: Programming protocol-independent packet processors[END_REF], request semantic is then efficiently accessible in hardware at the network layer thanks to hICN's name-based forwarding with fixed-sized names, while relieving the AC from maintaining per-flow state thanks to a connection-less approach. The implementation is shown to support a throughput of 16.7 Mpps (exceeding 10 GbE line-rate) with a packet processing latency of 3 µs. Algorithmic performance of the ABF is evaluated and shown to produce QoS results that are consistent with the LRU-AC model.

This chapter has been the object of two publications. [START_REF] Enguehard | A popularity-based approach for effective cloud offload in fog deployments[END_REF] introduces the LRU-and LFU-AC strategies and provides a preliminary evaluation based on the queueing model. [START_REF] Enguehard | Efficient latency control in Fog deployments via hardware-accelerated popularity estimation[END_REF] describes the system implementations of the LRU-AC using ABFs. Note that, while orthogonal to this work (and thus not reported in this thesis), [START_REF] Desmouceaux | A content-aware data-plane for scalable video delivery[END_REF] also exploits the LRU-AC strategy to optimize cache hit in the context of video delivery networks.

The remainder of this chapter is organized as follows: Section 3.2 states the Fog-AC problem in a principled way; Section 3.3 introduces the analytical model used to derive the performance of AC strategies; relevant popularitybased strategies are presented and partially evaluated in Section 3.4; in Section 3.5, the use of ABF to realize the LRU-AC, selected because it is both practical and effective, is proposed and justified; the LRU-AC hardware implementation is then introduced in Section 3.6 and evaluated in Section 3.7.

Problem description

Reference Fog architecture

The reference IoT architecture assumed in this chapter is a simplification of the larger picture depicted in Section 1.1.2 and consists of three main components: (i) IoT networks, where sensors, actuators, and users are connected; (ii) an access network which connects these IoT networks together and with the Internet; and (iii) a Cloud platform, used for compute and storage. On top of this Cloud platform, a Fog deployment is available in the access network. Both the Fog and the Cloud are equipped with LRU caches. Without loss of generality, we adopt a per-application view and consider a single Fog node with computing and storage capabilities that receives homogeneous requests from a single stateless application (e.g., lambda function). The Fog, either owned by the application developer or rented to its Internet Service Provider (ISP), is deployed for latency-critical applications. However, as Fog platforms are not elastic, the application developer wants to use the residual computing and memory capacities to perform latency-sensitive tasks. That residual capacity is considered to be constant, hence the Fog node cannot handle a high arrival rate for a prolonged period. It redirects part of its load to a Cloud platform, where the operator rents computing and storage resources, while still respecting the latency agreement.

An admission control module is in charge of forwarding incoming requests from the IoT networks to either Fog (accept) or Cloud (refuse). That architecture is summarized in Figure 3.1. We consider Fog applications working in the following way: (i) the application retrieves raw data from one or several sensor nodes (e.g., an image or a temperature from several sensors); (ii) it performs some computation to transform the raw data into processed data (e.g., JSON file indicating detected shapes, or the average of the measured temperatures); (iii) the processed data is retrieved by users or actuators which use it to take decisions. As security is paramount for Fog applications [START_REF] Bonomi | Fog computing and its role in the internet of things[END_REF], both processed and In particular, we consider a pull-based model driven by client requests, of which we illustrate two of the possible paths in Figure 3.1. The user application starts by issuing requests (step 1), which reach the admission control module. For the sake of illustration, only cases where requests are accepted in the Fog are shown. In the Fog node, the request is matched against a cache (step 2) for the availability of processed data. In case of a cache hit (red dots • • •), the processed data is sent back directly to the user. In case of a cache miss (green dashes ), the raw data must be retrieved from the sensor (step 3), before the computation can take place (step 4) and the processed data can then be served back to the user (step 5).

Fog vs Cloud admission control

To devise such strategies where the application runs both in the Cloud and in the Fog, costs for the Fog operator must be considered. In the Cloud, resources are elastic and the capacity can be increased as the incoming load grows [START_REF] Mao | Auto-scaling to minimize cost and meet application deadlines in cloud workflows[END_REF]. Furthermore, the Cloud is assumed to always store the raw data for orthogonal archiving and monitoring purposes; the cost of raw data archival is thus not considered. This comes on top of the cache for processed data, whose size is defined by the amount of storage rented in the Cloud. Moving data to/from the Cloud through the transit network also has a cost. On the other hand, application deployment in the Fog comes at no cost for the Fog operator (since it owns the infrastructure). As Fog nodes have limited storage resources, the Fog cache is only used for processed data. The Fog node also has a finite amount of computing resources, which must be equally shared between all incoming requests. Thus, in case of a high load, the Fog node might have a high completion time or even start dropping requests, which may violate the agreement set up with the Fog application developer.

The need for a proper offloading function φ between the Fog and Cloud resources thus becomes clear: such a function should minimize the cost Π(φ) of renting Cloud resources while respecting the agreed upon latency constraint, which we outline below (and formalize in Section 3.3): min. Π(φ)

s.t. E[T (φ)] ≤ ∆ (3.1)
where T is the stochastic variable describing the system completion time. In particular, Π is a cost per second, in accordance with the pay-as-you-use model for Cloud pricing. We use a statistical latency constraint, which guarantees that the average request completion time is under ∆. The advantage of such formulation is clear considering that it enables us to express the constraint in closed form in a queueing model, which simplifies tractability.

An analytical model

To understand the performance of a given admission control function, a queueing model that describes the systemic behaviour of the IoT architecture is introduced. The variables necessary for the model are summarized in Table 3.1.

Application model and request distribution

Let us consider a single application running on a sliced Fog deployment. This application is described by its latency constraint ∆, its raw data size s r , its processed data size s p , and its amount of service work X. In particular, we assume that s r and s p are constant, while X is a stochastic variable following an exponential distribution.

Let now R be the total number of possible requests, and {r 1 , . . . , r R } these requests. Following previous work, we consider that the request popularity distribution q follows a Zipf distribution [START_REF] Khan | A content-based centrality metric for collaborative caching in information-centric fogs[END_REF][START_REF] Janaszka | On popularity-based load balancing in content networks[END_REF][START_REF] Carofiglio | FOCAL: Forwarding and caching with latency awareness in information-centric networking[END_REF][START_REF] Breslau | Web caching and zipf-like distributions: evidence and implications[END_REF], i.e., for a request r arriving in the system, q(k) = P[r = r k ] = γk -α where α > 0 is the skew parameter and γ a normalization factor. In particular, requests arrivals are user-driven and are thus well modelled by a Poisson process of parameter λ. The arrival processes for each request r k are assumed to be independent and thus follow a Poisson process of parameter λ k = q(k)λ. The use of an independent requests model (IRM) is known to under-estimate of the cache benefits [START_REF] Imbrenda | Analyzing cacheable traffic in isp access networks for micro cdn applications via content-centric networking[END_REF][START_REF] Traverso | Temporal locality in today's content caching: why it matters and how to model it[END_REF], so we expect our results to be conservative.

Queueing model

Whenever relevant, we follow seminal work [START_REF] Niu | Handling flash deals with soft guarantee in hybrid cloud[END_REF][START_REF] Urgaonkar | An analytical model for multi-tier internet services and its applications[END_REF][START_REF] Nabe | Analysis and modeling of world wide web traffic for capacity dimensioning of internet access lines[END_REF][START_REF] Boyer | Heavy tailed m/g/1-PS queues with impatience and admission control in packet networks[END_REF] to select the most appropriate queue to describe each resource. Particularly, an M/M/1-PS queue is selected for the Fog compute [START_REF] Niu | Handling flash deals with soft guarantee in hybrid cloud[END_REF][START_REF] Urgaonkar | An analytical model for multi-tier internet services and its applications[END_REF]: processor-sharing policy models that

Cloud Compute M/M/∞ Compute M/M/1 PS Fog 𝜆 𝜆 f 𝜆 f 𝜆 f,nh 𝜆 f,m 𝜆 c 𝜆 c 𝜆 c,m 𝜆 c,m 𝜆 c 1-Φ Φ h c 1-h c h f 1-h f 𝜆 𝜆 f,m Access ↓ M/M/1-PS Access ↑ M/M/1-PS Transit ↓ M/M/1-PS Cache TLS M/D/∞ TLS M/D/∞ DB M/D/∞ TLS M/D/∞ AC Cache Figure 3.2 -Queueing network
the Fog has a fixed amount of resources that must be shared between all the incoming requests. On the other hand, as the Cloud compute is elastic, it is best represented by an M/M/∞ queue 1 , and we represent Cloud-database access as a constant-time M/D/∞ queue. For network resources, the M/M/1-PS model is used as common in the literature [START_REF] Niu | Handling flash deals with soft guarantee in hybrid cloud[END_REF][START_REF] Nabe | Analysis and modeling of world wide web traffic for capacity dimensioning of internet access lines[END_REF][START_REF] Boyer | Heavy tailed m/g/1-PS queues with impatience and admission control in packet networks[END_REF]. As admission control decisions and cache lookup should be done at line-rate (see Section 3.6), their impact is considered minimal w.r.t. other queues; and since they do not impact the comparison between Cloud and Fog service time anyway, they are neglected in what follows. Finally, the TLS endpoints are modelled as M/D/∞ queues, neglecting the computation time of the TLS handshake. Assuming that TLS is running in version 1.3, only 1 round-trip is necessary to establish the TLS connection, i.e.:

τ f = 2τ a τ c = 2(τ a + τ t ).
The resulting queueing system is depicted in Figure 3.2. One can note that the request transmission time is uniquely taken into account in the TLS queue: since IoT requests have negligible size, their transmission time is indeed dominated by their propagation time.

The AC strategy can be expressed as φ:{1, . . . , R}→[0, 1], a function that to each request associates a probability of being accepted in the Fog. In particular, given a popularity distribution q and an admission control strategy φ, the popularity distribution of requests arriving in the Fog is q f (r) = γ f φ(r)q(r), where γ f is a normalization factor. For computing the hit probability in the Fog cache, the seminal approximation proposed by Che et al. [START_REF] Che | Hierarchical web caching systems: modeling, design and experimental results[END_REF] is used:

h f (r) ≈ 1 -e -q f (r)ts (3.2)
where t s is the unique root of R r=1 (1e -q f (r)t ) = s f . A similar model applies 1. The underlying assumption is that of a perfect autoscaling policy.

λ f = r∈R φ(r)λq(r) Cache -Fog Access up. λ f,m = r∈R φ(r)(1 -h f (r))λq(r) Compute -Fog Cloud TLS -Cloud λ c = r∈R (1 -φ(r))λq(r) Cache -Cloud Transit down. DB λ c,m = r∈R (1 -φ(r))(1 -h c (r))λq(r) Compute -Cloud
for the Cloud cache, replacing the probability function φ by its complement 1φ.

Computing the statistical latency

First, let us point out that since processor-sharing queues are quasi-reversible processes, the exit distribution of an M/G/1-PS queue is a Poisson process (Theorem 3.6 of [START_REF] Kelly | Reversibility and stochastic networks[END_REF]). This is also true for the M/G/∞ queue [START_REF] Newell | The M/G/∞ queue[END_REF], justifying that all the queues have a Markovian input. The expected sojourn time in each of the queues is then easy to compute. In particular, the expected service time for requests with an amount of service work X and Poisson arrival rate λ in an M/G/1-PS of capacity C is given by:

E[T ] = 1 (µ -λ) where µ = C E[X] (3.3)
The arrival rate at each queue can be derived from the offloading strategy φ and the cache hit probabilities h f and h c at the Fog and Cloud caches respectively, obtained using Equation (3.2). Per-queue arrival-rates are reported in Table 3.2. We can thus get the equation for the expected queueing delay as:

E[T ] = r q(r) φ(r)E[T f (r)] + (1 -φ(r))E[Tc(r)] + E[T a,d ] (3.4)
where the expected latency for the service time in the Fog T f (r) is:

E[T f ] = τ f + (1 -h f ) (τ f + E[T a,u ] + E[T comp,f ]) ,
the expected latency for the service time in the Cloud T c (r) is:

E[T c ] = τ c + (1 -h c ) τ d + E[X] p c + E[T transit,d ],
and where T a,u , T a,d , T comp,f , T transit,d respectively represent the time spent in the access upstream, in the access downstream, in the compute in the Fog, and in the transit downstream, and whose expected values can be computed with Equation (3.3), Table 3.1 and Table 3.2.

Computing the cost function

The cost per second consists of a network, a computing, and a storage term. The computing power rented in the Cloud is assumed to be synchronized with the incoming load (i.e., the Cloud spawns a container process at each new request). The cost of running the Cloud increases proportionally to the requested load: p(c, s, n) = c c c + c s s + c n n, where c (resp. s) is the amount of computing (resp. storage) resources rented on the Cloud, and ν is the egress Cloud traffic in bytes per second.

Compute cost

Since the resource consumption in the Cloud is assumed to be elastic, if Q c (t) is the number of customers in the Cloud compute M/M/∞ queue, the instantaneous number of instantiated Cloud computing instances is: c(φ, s c ) t = Q c (t). According to [START_REF] Newell | The M/G/∞ queue[END_REF], the expected value for c(φ, s c ) is thus:

E[c(φ, s c )] = λ c,m (φ, s c ) p c /E[X]

Storage cost

The storage cost depends on the cache size in the Cloud: s(φ, s c ) = s c s p .

Network cost

For each incoming request, s p is transferred downstream as a reply. Given the Cloud arrival rate λ c , the average number of bytes per second on the Cloud downstream link is:

E[ν(φ, s c )] = λ c (φ)s p
Thus, the total cost function reads:

Π(φ, s c ) = c c λ c,m (φ, s c ) p c /E[X] + c s s c s p + c n λ c (φ)s p (3.5)

An example application -Numerical parameters

All upcoming numerical evaluations use the characteristics described in Table 3.3. In particular, we select an application with a medium computing difficulty (10 ms on a 1 GHz processor) and medium processed data size. For the Fog deployment, the application is assigned a slice of a computing platform amounting to a 3 GHz CPU and 1 GB of cache. Finally, to make the evaluation more realistic, the public pricing of the Google Compute infrastructure as of October 2017 is used, the delay target is set to ∆=100 ms.

Popularity-based Fog admission

Optimizing Fog resources

Request processing in the Fog-Cloud system can be decomposed in three modes: requests served (i) from the Fog cache, (ii) from the Fog compute, and To this end, an effective approach is to admit only popular content in the Fog. Indeed, this method increases the hit-rate of the cache policy effectiveness by artificially reinforcing the skewness towards the most popular pieces of content in the cache input distribution. The admission control must then be able to (i) identify the content targeted by each request and (ii) extract popularity patterns. Content identification (i) is an architectural problem, which we discuss in Section 3.6.1. To illustrate the limit of solutions without content awareness, a "blind " admission control is introduced in Section 3.4.2. Extracting popularity patterns (ii) is a similar problem to caching policies: detecting the most popular pieces of content. Thus, using a virtual cache (caching only identifiers rather than content) that follows traditional admission and eviction policies is a natural solution. In this case, a hit in the virtual cache identifies popular requests which should be handled in the Fog, while a miss hints that the request is not popular and should be offloaded to the Cloud. This solution is similar to multi-layered caching systems such as the 2Q-LRU [START_REF] Shasha | 2q: A low overhead high performance buffer management replacement algoritm[END_REF], differing mainly in that the first layer (the identifier cache) is completely independent from the actual cache. Indeed, in 2Q the virtual layer only governs cache insertion (but not cache retrieval), whereas the Fog-AC might refuse requests even though the corresponding answer is available in the Fog cache. In particular, the LFU (Section 3.4.3) and LRU (Section 3.4.4) policies are investigated.

Blind admission control

As a baseline, a request-oblivious admission control strategy, called Blind-AC, is introduced. It blindly load-balances all traffic with i.i.d. probability: with φ B = (φ B , . . . , φ B ). In this particular case, since (φ B , s c ) ∈ [0, 1][0, R], the problem is easy to optimally solve numerically. We next evaluate the respective importance of the two optimization variables using the parameters reported in Table 3.3 for numerical evaluation. In particular, the variation of the costs and constraint functions depending on either φ B or s c are represented in respectively Figure 3.3a and Figure 3.3c.

Figure 3.3a shows the variation of the constraint function (+, left side) and of the compute (•, right side) and network (, right side) costs for a fixed cache size s c = 3.1 • 10 6 . The storage cost is ignored as it is constant (since s c is fixed). The first takeaway is that, as expected from the costs in Table 3.3, the network cost is dominant w.r.t. the compute and memory cost. We also notice that the constraint function diverges towards +∞ when φ B grows close to 0.085, as the Fog compute queue becomes unstable and cannot handle the request rate.

In Figure 3.3c, we next vary the cache size s c for a fixed load-balancing probability φ B = 0.084 (the sweet spot in Figure 3.3a). We show the value of the constraint function (+, left side), and the compute (•, right side) and memory ( , right side) costs. The network cost is now ignored since it is constant when φ is constant. First, we note that varying the cache size has a limited impact on both the cost and the constraint function. Furthermore, in this case, given that the compute is almost one order of magnitude more expensive than the memory and the Cloud popularity distribution is sufficiently skewed, it is interesting to cache highly popular requests.

LFU-AC strategy

Let us first consider a perfect LFU virtual cache, which deterministically identifies the k LF U most popular requests for processing in the Fog. In particular, the admission control function φ can be expressed as:

φ(r) = δ r≤k LF U := 1 if r ≤ k LF U 0 otherwise.
Equation (3.1) then becomes:

min. Π( δ k LF U , s c ) s.t. E[T ( δ k LF U , s c )] ≤ ∆ with δ k LF U = (δ 1≤k LF U , . . . , δ R≤k LF U ).
Again, this problem is two-dimensional and can easily be solved numerically. Figure 3.3b (resp. Figure 3.3d) shows the evolution of the cost and constraint functions while setting s c = 3.0 • 10 6 (resp. k LF U = 1.4 • 10 5 ) for the setup in Table 3.3. At a first glance, Figure 3.3b indicates that a proper choice of k LF U allows decreasing the network cost at levels unreachable with the Blind-AC while respecting the constraint. Furthermore, as in Section 3.4.2, the dominant factor in terms of cost is the number of offloaded requests. Both of these insights point towards LFU as a good strategy for Fog/Cloud admission control. Additionally, Figure 3.3d shows that for small values of s c , the compute cost stays constant. This is due to the popularity distribution at the Cloud cache, which only contains the long tail of the Zipf distribution. Thus, for small cache sizes, the hit probability is low and the cache almost useless.

The LRU-AC strategy

While the LFU-AC is efficient, it is an ideal policy, difficult to realize in practice if the popularity distribution is not known in advance (as deriving the exact popularity distribution is difficult and slow2 ). To derive a practical admission control policy, we argue that the admission control does not need to learn the popularity of each specific request. It only needs to flag whether a request is popular, acting as a low-pass filter. In a second step, the LRU policy is thus considered for the admission control virtual-cache. The functioning of the corresponding admission control module, called the LRU-AC, is summarized in Figure 3.4. Compared to the aforementioned counter solution for the LFU-AC, the LRU-AC has four main advantages: (i) it does not require prior knowledge of the application; (ii) it keeps memory constrained to the size of the filter, instead of the size of the catalogue; (iii) it is flexible w.r. To incorporate LRU-AC in the model, we must compute the load-balancing function φ depending on the filter size k LRU . Since the admission control behaves like an LRU cache, φ(r) = h k LRU (r) where h k LRU (r) is the hit probability for the request r in an LRU cache of size k LRU with input distribution q, which can be derived straightforwardly from Equation (3.2). Integrating this in Equation (3.1) yields a constraint and a cost function that depends only on k LRU and s c : min. Π( h k LRU , s c )

s.t. E[T ( h k LRU , s c )] ≤ ∆ with h k LRU = (h k LRU (1), . . . , h k LRU (R))
. However, the interaction between the LRU meta-cache and Fog LRU cache introduces some correlation effects, as shown by Garetto et al., for the LRU-2Q cache [START_REF] Garetto | A unified approach to the performance analysis of caching systems[END_REF]. Following their example, a discrete time Markov chain is used to model the interdependence between hits in the filter and hits in the Fog cache. Details of the derivation are provided in Appendix A.1. Compared to the LFU-AC, realizing and optimizing the LRU-AC only requires knowing the popularity skewing factor α and the arrival rate λ instead of the actual per-content popularity distribution.

Preliminary evaluation of the admission control strategies

In this section, a first evaluation of the admission control strategies based on the model introduced in Section 3.3 provided. In particular, the Method-ofmoving-asymptotes [START_REF] Svanberg | The method of moving asymptotes -a new method for structural optimization[END_REF] (in its NLopt implementation [START_REF] Johnson | The NLopt nonlinear-optimization package[END_REF]) is used to solve the optimization problem (Equation (3.1)). A Jupyter notebook is available for reproducing the results of this section or to experiment with different parameters [START_REF] Enguehard | marceleng/queueingnetwork-simulator: a simulator for queueing networks[END_REF].

In a first step, we show in Table 3.4 the optimized values for our example application. We first note that using the LRU and LFU-AC allows the Fog to handle more than twice as many requests as with the Blind-AC. This results Figure 3.5 -Cost vs size of Fog cache for Blind-, LFU-and LRU-AC in a decrease in offload cost of more than 70%. Furthermore, it shows that the LRU-AC has similar performances to the LFU-AC, with a 3% relative difference in offload cost w.r.t. the Blind-AC. In Figure 3.5, the influence of the Fog cache size s f on the optimal Cloud cost for the Blind-, LFU-, and LRU-AC strategies is shown. In particular, this figure shows that both the LFU-and LRU-AC strategies are much better at exploiting an increasing cache size that the Blind-AC. Indeed, for the Blind-AC, increasing the Fog cache size only slightly decreases the optimal cost. On the other hand, both the LFU-and the LRU-AC provide an exponential decrease of the cost as the cache size increases, showing the effectiveness of popularitybased admission control. Furthermore, this graph confirms that the LRU-AC is an extremely good approximation of the ideal LFU-AC, and regardless of the Fog cache size.

Figure 3.6 then investigates the influence of the popularity distribution skew (represented by the Zipf parameter α). For small α values, the popularity distribution converges towards a uniform distribution, thus diminishing the impact of popularity-based ACs. However, for typical values of α found in the literature (α ∈ [0.5, 1.1]), the LFU-and LRU-AC strategies allow for a largely reduced optimal cost for both Fog cache sizes that we tested. Furthermore, the LFUand LRU-AC strategies with s f = 10 4 are much more efficient than the Blind-AC strategy with s f = 10 5 . This indicates that the strategies also allow for more efficient provisioning of Fog resources. Once again, the performance of the LRU-AC is close to the LFU-AC, varying by at most 6%.

Finally, the impact of the arrival rate on the efficiency of the strategies is shown in Figure 3.7. Interestingly enough, the optimal cost increases linearly w.r.t. the arrival rate for all three cases, with slopes at 2.9•10 -3 $/Hz for the Blind-AC, 8.2•10 -4 $/Hz for the LFU-AC, and 1.0•10 -3 $/Hz for the LRU-AC. This confirms that the LFU-and LRU-AC strategies cope better with increased loads (e.g., flash crowds) than the Blind-AC. This is typically due to the improved hit rate at the Fog cache, which absorbs a large part of the increased arrival rate. Particularly, if the cost of the Blind-AC diverges with respect to the LFU-AC and the LRU-AC for an increasing arrival rate, their ratio stays however constant. The ratio between the absolute costs for the LFU-AC (LRU-AC) over the Blind-AC is of 3.5 (2.9)3 . Thus, when the arrival request rate increases, the relative gain of using the LFU-AC (LRU-AC) over the Blind-AC also increases, which shows the LRU-and LRU-AC to be quite robust to high arrival rates.

This preliminary evaluation shows that the LRU-AC combines tractability, flexibility, and effectiveness. It is thus selected as the default admission policy for the remainder of this chapter.

Ageing Bloom-Filters for an hardware-accelerated LRU-AC

As the admission control strategies were designed to provide predictable completion time under high-load, their implementation should benefit from the same virtues. Thus, implementing the LRU-AC in hardware seems particularly profitable. However, the LRU-AC raises many realization challenges, particularly on hardware-accelerated platforms. The first and obvious one is memory usage. As shown in Section 3.5.4, the total memory footprint of the LRU-AC can overtake the high-speed BRAM (Block RAM [START_REF] Brelet | Using block ram for high performance read/write cams[END_REF]) available in the hardware -notwithstanding the BRAM that needs to be allocated for e.g., packet queues. Furthermore, the access time to an LRU element is not constant (as a hash map provides only amortized constant time for read operations), which renders it undesirable for hardware implementation [START_REF] Blott | Achieving 10Gbps line-rate key-value stores with FPGAs[END_REF]. Thus, in this section, we explore Ageing Bloom Filters (ABF) as an alternative data-structure to implement the LRU-AC. After a brief description of the ABF behavior (Section 3.5.1), a predictive model similar to Che's approximation (Equation (3.2)) for the hit-rate of the ABF is presented (Section 3.5.2). The model is verified by way of simulation (Section 3.5.3) and memory gains compared to standard LRU implementations are evaluated (Section 3.5.4).

Ageing-Bloom filters

A popular and natural structure for storing sets in programmable hardware are Bloom filters [START_REF] Dharmapurikar | Deep packet inspection using parallel bloom filters[END_REF][START_REF] Song | Fast hash table lookup using extended bloom filter: an aid to network processing[END_REF][START_REF] Song | IPv6 lookups using distributed and load balanced Bloom filters for 100Gbps core router line cards[END_REF]. Indeed, they provide a compact and efficient way to store set membership with a controllable error probability as the only trade-off. In particular, Bloom filters have been proposed to store network identifier for high-performance packet forwarding [START_REF] Song | IPv6 lookups using distributed and load balanced Bloom filters for 100Gbps core router line cards[END_REF][START_REF] Yu | BUFFALO: Bloom filter forwarding architecture for large organizations[END_REF]. Thus, using a Bloom filter to store the content of the LRU-AC seems like a promising step towards implementing it in hardware. Realizing the LRU-AC, however, requires the ability to evict old content from the cache, which standard Bloom filters do not support. To replicate this behaviour, Yoon introduced Aging Bloom Filters (ABF) [START_REF] Yoon | Aging bloom filter with two active buffers for dynamic sets[END_REF].

An ABF consists of two parallel Bloom filters: the active Bloom filter A 1 , used to learn the most recent items, and the passive Bloom filter A 2 , which holds older items in memory. It has two parameters: n a , the maximum number of items that each filter holds, and f p , a target false positive rate. The functioning of the ABF is summarized in Algorithm 1. In steady state, the passive filter A 2 holds exactly n a different items. The active filter A 1 holds 0 ≤ cnt < n a items, some redundantly with A 2 . An item is said to be in the ABF if it belongs to either A 1 or A 2 . Insertion is done only in the active filter A 1 until it holds n a unique items. At this point, A 2 is swapped with A 1 , and the active filter is reinitialized. This ensures that the ABF contains at least the last n a different items received, and at most 2n a . However, there are redundancies between A 1 and A 2 , the exact number of objects in the ABF is a stochastic process.

Algorithm 1 The ABF main functions function Init

Filter initialization

A1 ← ∅, A2 ← ∅, cnt ← 0 end function function Check(item)
Checks if an item is in the filter return

(item ∈ A1 ∪ A2) end function function Set(item) Inserts an item in the filter if item / ∈ A1 then A1.insert(item) cnt ← cnt + 1 if cnt = na then A2.flush() swap(A1,A2) cnt ← 0 end if end if end function 0 K 1 K 2 K 3 K 4 Number of draws 0 n a

Number of unique elements

E[A 1 ] E[A 2 ] E[A 1 ∪ A 2 ] f (k) Ñ

Hit-rate approximation for the ABF

To replace the LRU-AC with an ABF, the expected hit-rate of the ABF must be evaluated. Indeed, as shown in Section 3.4.5, the hit-rate distribution is the major factor that explains the performance of the LRU-AC. While for brevity reasons, only the major ideas behind the model derivation are presented here, a complete explanation is provided in Appendix A.

As in Section 3.3, Zipf arrivals under IRM are assumed. Let us consider |A 1 ∪ A 2 | (k) the stochastic process representing the number of unique elements in an ABF after k arrivals. First, as depicted in Figure 3.8, one can observe that the behaviour of an ABF is cyclic (except for the bootstrap, during which A 2 is empty). At a given time, its behaviour only depends on the arrivals which occurred after the second-to-last flush-and-swap operation as the memory of events that occurred before that point has been flushed. Therefore (and since arrivals are memoryless due to the IRM assumption), it suffices to analyse the behaviour of the filter during the second cycle. Let us denote by K 1 (respectively K 2 ) the number of steps necessary to complete the first (respectively second) cycle:

K 1 = min{k ≥ 0 : |A 1 |(k) = n a } K 2 = min{k ≥ K 1 : |A 1 |(k) = n a }
We will thus study the behaviour of the filter in [K 1 , K 2 ).

Approximating K 1 and K 2 For k ≤ K 2 , the probability h k (r) that content r is in the filter after k ≤ K 2 draws from the catalogue is simply the probability that it was selected at least once from the k draws:

h k (r) def = P[r ∈ (A 1 ∪ A 2 )(k)|K 2 ≥ k] = 1 -(1 -q(r)) k
Thus, the expected number f (k) of items in the filter after k draws is:

f (k) def = E[|A 1 ∪ A 2 |(k) |K 2 ≥ k] = E[ R r=1 1 r∈(A1∪A2)(k) |K 2 ≥ k] = R r=1 h k (r) = R r=1 [1 -(1 -q(r)) k ]
It is possible to prove, using Chernoff bounds (see Appendix A.2) that K 1 (the number of steps necessary for there to be n a items in A 1 ) deviates little from k 1 , the number of steps necessary for there to be n a items in average in A 1 , defined as:

k 1 def = f -1 (n a ) (3.6)
Due to the cyclic behaviour of the filter, K 2 is then naturally approximated as

K 2 ≈ 2 k 1 .
It is then possible to efficiently find k 1 by using an approximation for f (k), rather than inverting a sum with R elements. Assuming a Zipf catalogue with a parameter α (i.e., q(r) = r -α H R,α with H R,α = R i=1 i -α ), we have:

f (k) ≈ Ak -Bk log k if α = 1 Ak -Bk 1/α if α ∈ (1/2, 1) ∪ (1, +∞) (3.7)
where:

A =        R 1-α (1 -α)H R,α 1 + 1 + log log R -2γ log R + γ if α > 1 2 , α = 1 if α = 1 B =          -Γ(-1/α) α 2 H 1/α R,α 1 log R + γ if α > 1 2 , α = 1 if α = 1 (3.8)
where Γ(z) is the gamma function and γ ≈ 0.577 the Euler-Mascheroni constant.

The derivation is provided in Appendix A.3.

Approximating the hit rate

As introduced in the previous section, the hit rate h k (r) for content r after k ≤ K 2 draws from the catalogue is:

h k (r) = 1 -(1 -q(r)) k
Thus, the (stochastic) hit rate H(r) for content r when observed at an instant K obs drawn uniformly during the cycle [K 1 , K 2 ) is:

H(r) def = E[1 r∈(A1∪A2)(K obs ) |K 1 , K 2 ] = 1 K 2 -K 1 K1≤k<K2 1 -(1 -q(r)) k
and the corresponding average hit rate h(r) is:

h(r) def = E[H(r)] = E   1 K 2 -K 1 K1≤k<K2 1 -(1 -q(r)) k  
Since (as argued in the previous section) K 1 and K 2 can be approximated by k 1 and 2 k 1 , respectively, we can further provide an approximation h a (r) of h(r) as:

h(r) ≈ 1 k 1 k1≤k<2 k1 1 -(1 -q(r)) k ≈1-e -kq(r) ≈ 1 k 1 2 k1 k1 1 -e -kq(r) dk def = h a (r)
Simple algebra then yields:

h a (r) = 1 -e -q(r)t C (r) (3.9)
where:

t C (r) = k 1 + 1 q(r) log k 1 q(r) 1 -e -k1q(r) ∈ [ k 1 , 3 2 k 1 ]

A Che-like approximation

For large values of r, t C (r) exhibits very little variation: a Taylor expansion shows that t C (r) ≈ 3 2 k 1 -q(r) 24 k 1 2 . For small values of r, t C (r) varies more, but its contribution to h(r) can be neglected as h(r) ≈ 1 in those cases, as argued in [START_REF] Fricker | A versatile and accurate approximation for LRU cache performance[END_REF] (figures depicting this phenomenon are available in Appendix A.4). Therefore, it is possible to make the approximation that t C (r) is a constant t C , yielding:

h a (r) ≈ 1 -e -q(r)t C (3.10)
In that case, by summing over r ∈ {1, . . . , R}, t C can be computed by finding the root of:

R r=1 [1 -e -q(r)t C ] = R r=1 h a (r) def = Ñ (3.11)
where Ñ represents the average number of items in the filter, and can be computed with:

Ñ ≈ 1 k 1 2 k1 k1 f (k)dk (3.12)
using the approximation of f (k) provided in the previous section and straightforward integration. This is similar to the Che approximation (see Equation (3.2)), with the (fixed) size of the LRU cache replaced by the average over time of the "size" (number of distinct items) of the ABF. Functions for computing k 1 and n a depending on k LRU are provided in the Jupyter Notebook associated with this chapter [START_REF] Enguehard | marceleng/queueingnetwork-simulator: a simulator for queueing networks[END_REF]. For instance, k LRU =2.8•10 5 (as in Table 3.4) yields n a =2.0•10 5 .

Model verification for α = 1

To verify the model, a software implementation of the ABF was subjected to a Poisson arrival process with Zipf popularity distribution. In particular, in Figure 3.9, measured values of Ñ are compared to the results obtained using the method described at the end of Section 3.5.2. It shows that the analytical model accurately captures the expected number of unique items in the ABF, with an average relative difference 3%. Then, the accuracy of the approximation proposed in Section 3.5.2 is evaluated in Figure 3.10, which compares the average hit-rate r q(r)h a (r) computed from the approximation of Equation (3.10) with the measured average hit-rate in simulation runs. It shows that the model fits almost perfectly with the experiments, with a relative difference < 0.02% for n a > 10.

ABF -memory usage vs LRU

LRU memory

Let us consider a traditional LRU implementation consisting of a hash map pointing to a doubly-linked list. Each LRU entry has a memory footprint at least equal to the size of 3 pointers (one in the hash map and two in the doublylinked list). The minimal pointer size is log 2 k LRU . To compare the ABF to the LRU and according to Equation (3.11), k LRU = Ñ is used. Thus, the memory used by the LRU is:

m LRU = 3 Ñ log 2 Ñ (3.13)

ABF memory

Let f p be the wished false-positive rate of the ABF. The corresponding falsepositive rate of A 1 and A 2 is f a = 1-1f p [START_REF] Yoon | Aging bloom filter with two active buffers for dynamic sets[END_REF]. The corresponding number of hash-functions is n h =log 2 (1 -1f p ) , and m= 2nan h log 2 . Putting it all together, the memory consumption of the ABF is:

m ABF = 2n a -log 2 (1 -1 -f p ) log 2 (3.14)

Numerical results

For k LRU = 2.8 • 10 5 (as in Table 3.4), the minimal pointer size is 19 bits (since log 2 (k LRU ) ≈ 18.1). The required memory per element adds up to 57 bits. In total, this amounts to m LRU = 16 Mbit. By comparison, the corresponding ABF has for parameter n a = 2.0 • 10 5 . For a false positive rate of f p =1%, Equation (3.14) yields m ABF = 4.6 Mbit, dividing the LRU-AC memory footprint by 4. Furthermore, let us note that while the computation of m ABF is exact, the computation of m LRU is conservative. Indeed, implementing a hash-table requires a significant memory overhead and creates a memory vs operation-latency trade-off.

Hardware-implementation of the LRU-AC

Using hICN as the underlying network layer

To guarantee line-rate performances, the hardware-accelerated admission control must be able to access the request identifier easily. While extracting application-level semantics from packets (deep-packet inspection) is possible in hardware using frameworks such as P4 [START_REF] Bosshart | P4: Programming protocol-independent packet processors[END_REF], it is costly in terms of cycles. Therefore, the performance of the admission control hardware module would benefit from a network framework that exposes application-semantic at a lowlevel, but that also provide a deterministic packet format (through fixed-size headers, fixed field locations, such as IP/TCP).

In that regard, hICN [START_REF] Muscariello | Hybrid Information-Centric Networking[END_REF] is an ideal candidate. hICN is an implementation of ICN [START_REF] Xylomenos | A survey of informationcentric networking research[END_REF] that transparently uses the semantic of IPv6/TCP for backwardcompatibility. In particular, while hICN is a name-based protocol (i.e., forwarding is performed based on named-content identifiers rather than locators), names are encoded using an IPv6 address for a name prefix (64 bits of routable prefix and 64 bits of data identifier) and a 32-bit integer for the name suffix. An Interest (resp. Data) packet then carries the name prefix in the IPv6 destination (resp. source) address field, while the name suffix is placed in the TCP segment number field. As such, hICN holds the desirable characteristics for implementing the LRU-AC in hardware: request semantic accessible in fixed-size fields in fixed locations of the network and transport headers.

compute h[1] compute h[2] query RAM[h[1]] query RAM[h[2]] retrieve RAM[h[1]] retrieve RAM[h[2]] retrieve RAM[h[3]] query RAM[h[3]] query RAM[h[4]] compute h[3] compute h[4] retrieve RAM[h[4]]
write output fetch input AND results cycles

Hardware-implementation of the LRU-AC

To demonstrate implementability of the LRU-AC in hardware, the NetFPGA-SUME [START_REF] Zilberman | Net-FPGA SUME: Toward 100 gbps as research commodity[END_REF], a state-of-the-art academic programmable network cards, was used. To provide a modular and easily-modifiable implementation, the prototype is implemented in P4 [START_REF] Bosshart | P4: Programming protocol-independent packet processors[END_REF], allowing packet parsing to be performed in a high-level language. The P4→NetFPGA framework [START_REF] P4 | P4 → NetFPGA: A low-cost solution for testing P4 programs in hardware[END_REF] is then used to translate that high-level representation into a NetFPGA-SUME implementation.

The prototype comprises two parts: (i) a Bloom filter atom 4 written in Verilog, that implements a single Bloom filter; and (ii) a P4 data-plane, which performs packet parsing, processing, and deparsing, and whose processing part implements an ABF by using two Bloom filters atoms. Using a Bloom filter atom and implementing the ABF logic in P4 rather than directly implementing the ABF as a black-box Verilog module provides greater modularity and expressiveness in the high-level language and simplifies the engineering effort by having to focus on optimizing only a single and simpler low-level module. The Bloom filter atom has been upstreamed to the P4-NetFPGA project 5 .

Bloom filter atom

The Bloom filter atom takes a fixed-length key of size s key in argument, as well as an operand specifying the operation to be performed on that key (read or insert), and returns a single bit specifying whether the key was found in the filter -in case of an insert operation, whether the key was found before insertion. Additionally, a third operand allows resetting the filter (i.e., clearing all its bits). This allows exporting a very simple API:

extern void bloom_filter ( in bit <2 > opcode , in bit < KEY_SIZE > index , out bit <1 > result ) ;
The Bloom filter is parametrized by the number n h of hash functions, and the size s hash of their output -governing the number of addressable objects. Each 4. Atoms are low-level modules that can handle state and perform a simple operation, while interfacing with a higher-level packet processing language [START_REF] Sivaraman | Packet transactions: High-level programming for line-rate switches[END_REF].

5. https://github.com/NetFPGA/P4-NetFPGA-public hash function h i (i ∈ {1, . . . , n h }) is implemented using universal hashing [START_REF] Dietzfelbinger | A reliable randomized algorithm for the closest-pair problem[END_REF]. Indeed, universal hashing relies only on multiplication, XOR and shift operations, and can thus be efficiently implemented on the NetFPGA-SUME (using multiplier blocks).

To optimize throughput and latency, the Bloom filter is implemented with a pipelined approach, as depicted in Figure 3.11. The idea is to use each cycle to query one bit (at the address dictated by one of the n h hash functions), for a total of approximately n h cycles. Since querying the BRAM has a 2cycle latency and hash function computation uses a full cycle, the i-th hash function is computed at cycle i and the corresponding bit is queried at cycle i + 1 for a result retrieved at cycle i + 3. The final result is then output at cycle n h + 4, after ANDing all the intermediary results. In sum, the Bloom filter has a latency of n h + 3 cycles and a throughput of 1 operation every n h + 4 cycles. In terms of spatial complexity, in addition to the LUTs (Look-Up Tables, the fundamental reconfigurable logic blocks in FPGAs) required to implement the logic, the module uses 2 s hash -15 blocks of BRAM (of size 32 Kbit). Table 3.5 reports the resource usage of a single Bloom filter after synthesis, for different values of s key and s hash .

P4 data plane

The P4 data plane leverages the simplicity of having defined an external Bloom filter atom to provide a simple implementation. It comprises four components: (i) a parser, which extracts Ethernet and IPv6 headers and stores the hICN object key, (ii) an action, which implements the ABF logic to determine the egress interface for the packet, (iii) a match-action table, which maps that interface to an Ethernet address, and (iv) a deparser, which reconstructs the output packet. (i), (iii) and (iv) are straightforward to implement in P4. (ii) is implemented through four external atoms: two Bloom filters, a flag that keeps track of the active Bloom filter, and a counter that keeps track of the number of requests since the last swapping event. Predicated-read-add-write registers available from the P4-NetFPGA framework [START_REF] Sivaraman | Packet transactions: High-level programming for line-rate switches[END_REF] are used to implement the counter and the flag. The counter is incremented if its value is smaller than k 1 and reset when it reaches k 1 6 . The flag is swapped when the counter has just 6. k 1 is used as a threshold on the number of steps rather than na on the number of elements in the filter because the reg_ifElseRaw atom can only be accessed once per packet in the P4-NetFPGA workflow. To use na, the counter would have to be read before querying the filters (to decide whether to swap) and updated after the queries have completed (to count the number of active elements). The validity of using k 1 comes from Equation (3.6).

been reset. Depending on the value of the flag and on whether it has just been swapped, suitable (read, write or clear) operations are sent to the two Bloom filters, along with the key extracted from the packet. Finally, the output port is chosen, depending on the OR of the result of the two queries.

Evaluation

In this section, an evaluation of the FPGA-based LRU-AC (named ABF-AC in this section to distinguish it from the LRU-AC implemented with an actual LRU filter) is presented. First, packet-level simulation is used to compare the ABF-AC to the LRU-, LFU-and Blind-AC. Then, the throughput and processing speed of the FPGA implementation is evaluated.

Packet-level simulation

To derive more insights about the packet-level behavior of the schemes introduced in Section 3.4, packet-level simulations of the queueing network introduced in Section 3.3 using actual implementations of each strategy were conducted. The simulator, written in Rust and available in open-source [START_REF] Enguehard | marceleng/queueingnetwork-simulator: a simulator for queueing networks[END_REF], is a general-use queueing simulator designed to allow quick specification and testing of queueing networks. In this section, it is set up with the values presented in Table 3.3 and the admission control modules with the values computed in Table 3.4. The ABF filter is configured with k 1 = 5.2•10 5 (computed through Equation (3.6)) and f p =1%. The interested reader can use the Jupyter notebook provided with the simulator to find the filter parameters tailored to their own scenario and set up the simulator accordingly.

In a first step, the per-packet response time of the LRU-AC is considered. Figure 3.12 shows the cumulated distribution function (CDF) for both the ABFand LRU-AC. For the sake of clarity, the head and the tail of the distribution are represented in resp. Figure 3.12a and Figure 3.12b, while individual CDFs for the Fog and Cloud paths are represented in Figure 3.12c and Figure 3.12d. The only visible difference between the LRU-and the ABF-based implementations is the spread of the distribution, which concerns only 0.1% of requests, thus justifying the validity of the ABF-AC. Of further note is the length of the queue, which goes up to 600s. As shown by Figure 3.12, this is due to the effect of the trimodal nature of the distribution on the problem formulated in Equation (3.1). Indeed, a large percentage of requests are processed with a latency ∆. Thus, the constraint E[T ] ≤ ∆ can tolerate a long tail, which might be a problem for real-life applications (even if 99% of the requests are completed under a minute). For operators with stricter latency constraints, the length of the queue can be reduced by slightly modifying the value of k LRU and k 1 . For instance, artificially reducing the load on the Fog by 5 percentage points by setting k LRU =1.3•10 5 (resp. k 1 =2.3•10 5 ) allows reducing the distribution spread to about 0.3 s and the threshold excess rate (i.e., % of requests with service time ≥ ∆) to 1% for a 16% cost increase for both implementations, as shown in Figure 3. [START_REF] Balcon | Expérimentation: Cisco mesure la fréquentation de la place de la Nation[END_REF].

In a second step, Figure 3.14 shows the request path repartition and the threshold excess rate for the Blind-, LFU-, and both implementations of the LRU-AC. It highlights that the threshold excess rate is of the same magnitude between all schemes, with probabilistic LRU-AC just slightly higher. Further- more, it illustrates again the strong difference between on one side the LFUand LRU-AC, which handle about 70% of the requests in the Fog, and the Blind-LB, which sends more than 90% of the requests in the Cloud. Popularitybased admission control thus seems an appropriate approach to take maximum advantage of edge resources.

Implementation evaluation

The P4 data plane introduced in Section 3.6.2 has been synthesized for the NetFPGA-SUME platform with the P4→NetFPGA framework. The targeted false positive rate is f a = 1%, yielding n h = 8. The maximum number of elements in the ABF is taken to be n a = 9.2•10 4 (corresponding to an equivalent LRU filter size k LRU = 1.3•10 5 , i.e., the conservative settings introduced in Section 3.7.1), yielding m ABF /2 = 2.1•10 6 bits in each filter. Thus, one must take s hash = log 2 m ABF 2

= 21 to be able to address all elements in each filter. Finally, we take a key of s key = 48 bits, allowing to address up to 280•10 12 objects, way above the catalogue size R = 10 7 .

Resource usage on the FPGA board is reported in Table 3.6. As can be seen by comparing these results to those in Table 3.5, most of the logic (LUT) is consumed by the NetFPGA framework (MAC for the network interfaces and packet processing). However, an important part of the BRAM resources is consumed by the Bloom filter modules. In total, the BRAM usage is 47%, confirming that the limits of the platform are reached and that a standard LRU filter (which would consume 4 more memory as shown in Section 3.5.4) could not be implemented.

The performance of the P4 data plane is evaluated by injecting in the FPGA simulator a batch of 4096 packets (directly after the Ethernet interface, so as to outreach the 10 Gbps limit), and measuring the corresponding latency and throughput. Results are reported in Table 3.7, showing that packets can be forwarded over the 10 Gbps line-rate (14.4 Mpps) while providing low latency. The obtained throughput results are consistent with the throughput of the Bloom filter atom (one operation every n h + 4 = 12 cycles at 200 MHz).

Related Work

The importance of locating computing resources topologically close to users has been put forward under diverse forms in the community: Fog computing [START_REF] Bonomi | Fog computing and its role in the internet of things[END_REF], Mobile-Edge-Computing [START_REF] Hu | Mobile edge computing -a key technology towards 5g[END_REF], hybrid Cloud [START_REF] Niu | Handling flash deals with soft guarantee in hybrid cloud[END_REF]. In particular, Niu et al. [START_REF] Niu | Handling flash deals with soft guarantee in hybrid cloud[END_REF] explore a similar problem to ours: the use of a local Cloud infrastructure to handle sudden bursts of traffic. They also use a Markov-chain based model for computing the expected completion time and devise a scheduling algorithm between hybrid and public Cloud using an optimization problem under budget constraints. However, they do not exploit any knowledge of the request popularity, thus falling under the hard limit that we exposed for the Blind-AC. Malawski et al., study costs optimization between a hybrid Cloud and multiple public Clouds with different pricing models under a deadline constraint [START_REF] Malawski | Cost minimization for computational applications on hybrid cloud infrastructures[END_REF]. However, they focus on task optimization, looking at a model closer to scheduling for scientific computing rather than live optimization of user requests. Du et al. [START_REF] Du | Computation offloading and resource allocation in mixed fog/cloud computing systems with min-max fairness guarantee[END_REF] formulate a joint resource allocation and offloading between user devices, Fog networks and Cloud networks, so as to minimize energy consumption and request processing delay.

Using popularity to load-balance content in ICN networks has already been explored. In [START_REF] Janaszka | On popularity-based load balancing in content networks[END_REF], the authors propose to count incoming packets and use exponential smoothing. As argued in Section 3.4.4, this approach is not flexible to popularity changes and requires knowledge of the application. Furthermore, the authors aim at load-balancing packets over homogeneous paths, whereas the Fog/Cloud offload problem is essentially heterogeneous. Similarly, Carofiglio et al. [START_REF] Carofiglio | FOCAL: Forwarding and caching with latency awareness in information-centric networking[END_REF] propose to use a k-LRU filter to learn popularity for load-balancing ICN interests over multiple paths. They then measure per-name latency to optimize the distance to the next object. However, the authors do not specify the settings of the k-LRU filter, and only consider the effect of their load-balancing on the data creation process. Finally, in [START_REF] Wang | Fog computing based contentaware taxonomy for caching optimization in information-centric networks[END_REF], the authors use the ICN-Fog node as a classifier between static and dynamic data, thus preventing upstream caches to store dynamic data. They do not, however, consider the data processing that happens in many Fog applications.

Summary

In this chapter, we introduced methods for guaranteeing response time in Fog deployments based on popularity-aware admission control. Two specific admission control schemes were defined: the oracle-based LFU-AC and the probabilistic LRU-AC. Their effectiveness was demonstrated using an analytical model for various application parameters. An implementation of the LRU-AC on state-of-the-art FPGA hardware using an ABF was then proposed and its soundness was demonstrated through analytical modeling. This implementation is shown to provide admission control at 10 GbE line-rate throughput with a 3 µs latency. It increases the acceptance rate by almost 10 w.r.t. content-blind approaches while maintaining the latency excess rate stable.

Chapter 4

Network and application management in Information-Centric Networks

As illustrated in the previous chapter, one of the big advantages of ICN is the tight integration between applications and the network. In this chapter, we argue that to realize the full potential of such a cross-layer collaboration, most of the network tooling must be rethought accordingly. This is particularly true for the management of both applications and networks, and all-the-more for platforms such as Fog computing, which are highly virtualized [START_REF] Bonomi | Fog computing and its role in the internet of things[END_REF]. Management frameworks should reflect the characteristics of ICN, for instance by intertwining network and application management. We thus attack the network management problem from a general and high-level perspective. In particular, we explore the relation between ICN and Intent-Based Networking (IBN), a network management design where administrators only specify an abstract view of their desired network model instead of detailing the necessary steps to attain it. We explore both sides of the problem: how can IBN be applied to ICN but also how ICN can be used to enhance IBN.

Intent-Based Networking and ICN

Recent years have seen the emergence of network paradigms such as network function virtualization (NFV) or Cloud and Fog computing, an increasing complexity of network security requirements, and a shift in network communication patterns. Human operators are thus struggling to keep up with the complexity and diversity of network devices, services and traffic. In particular, network management has essentially become a multiparty process, where deploying a service involves many actors. This has led to the development of Software-Defined Networking (SDN) [START_REF] Kim | Improving network management with software defined networking[END_REF] and the apparition of feature-rich, centralized network and service orchestrators such as OpenStack [186] or Kubernetes [187], built to present simplified and unified human-facing interfaces. Of particular note is the switch from procedural APIs to intent-based network configuration [START_REF] Lerner | Innovation insight: Intent-based networking systems[END_REF][START_REF] Aranda Gutiérrez | Fighting your way through the jungle of intent[END_REF], where the user specifies an intent in a human-readable and abstract way, e.g., "Deploy a video-conferencing service for my company", instead of the full concrete procedure necessary to achieve it. Intent-based networking is touted as an enabler for complete network automation, where a self-regulating network is able to digest and apply high-level policies without human interaction [190]. In fact, with its stated aim of abstracting the actual configuration in favour of abstract policies [START_REF] Lerner | Innovation insight: Intent-based networking systems[END_REF][START_REF] Aranda Gutiérrez | Fighting your way through the jungle of intent[END_REF], intent-based networking raises many research challenges, e.g., how to use artificial intelligence on telemetry data to verify and optimize policy application [START_REF] Ayoubi | Machine learning for cognitive network management[END_REF].

Progress on IBN has not yet been reflected in ICN. The ICN community has admittedly stated the importance of a pragmatic experimental and applicationdriven research approach since its inception [START_REF] Zhang | Named data networking[END_REF]192]). Multiple tools and testbeds have even been developed for simulation and emulation (CCNx, NDN software and testbed, CCN-lite, MiniCCNx [START_REF] Cabral | Mini-CCNx: Fast prototyping for named data networking[END_REF], MiniNDN). Most of them have however been designed to assist research, specifically on the design and evaluation of specific aspects of the ICN architecture (e.g., caching, forwarding, or routing). They operate in dedicated fully-ICN network environments, trading-off abstraction of network characteristics for scale and offering limited flexibility to modify core ICN features, network topology and settings, or application APIs. To bridge the gap between a promising network architecture and a feasible deployment-ready solution, problems such as network configuration, management, and orchestration must be resolved. On the other hand, ICN offers the opportunity to rethink IBN frameworks, looking not only at how IBN should be applied to ICN but also at how ICN can enhance and empower intent-based network management.

First, we present vICN (virtualized ICN), a flexible intent-based framework for ICN network configuration, management, and control that is able to satisfy a number of important deployment and experimentation use cases: (i) conducting large-scale and fine-controlled experiments over generic testbeds; (ii) instantiating reliable ICN network with real applications in proofs of concept; (iii) deploying large networks within networks for trial and test development. Clearly, requirements are different: research experimentation needs fine-grained control and monitoring of the network as well as reproducibility of the experiments. Prototypes for demonstration require a high level of programmability and flexibility to combine emulated and real network components or traffic sources. More than in previous cases, reliability and resource isolation is a critical property for deployments in ISP networks.

The operations required for the deployment of an ICN network include installing/configuring/monitoring a new network stack in forwarding nodes or the socket API used by applications at the end-points. If loading a cloud microservice from an application store into general purpose hardware is easy to realize, a network stack has different requirements: ultra-reliability, high-speed and predictability, to cite a few. vICN shares the same high-level goals as SDN/NFV architectures, but with additional ICN-specific capabilities not typically required by IP services. Overall, we identify three main challenges that vICN addresses and that differentiate it w.r.t. state of the art: Programmability: i.e., the need to expose a simple and unified intent-based API, intuitive enough to facilitate bootstrap, expressive enough to accommodate both resource configuration and monitoring, and flexible enough to allow the user to decide about the level of control granularity. Exist-ing software like OpenStack, which is built as a collection of independent components, each one following different design patterns, does not offer such a satisfactory level of programmability.

Scalability: vICN aims at combining high-speed packet processing, network slicing and virtualization, and highly parallel and latency minimal task scheduling. Current systems are based on a layered architecture that prevents fine-grained optimization, thus limiting scalability on the long term.

Reliability: a fundamental property of vICN lies in its ability to maintain the state of deployment, recover from failures and perform automatic troubleshooting. This requires the overall software to be able to accommodate programmable function monitoring and debugging. In existing designs, each component has independent implementations to achieve that.

In a last step, and looking ahead to future research directions, we turn the tables and investigate how an ICN-like approach can benefit IBN. In particular, we argue that many limitations of current orchestrators come from the necessity to perform an early and centralized binding from the user's request to a set of device configurations, requiring full knowledge and preventing any further actors to participate in the resolution of the intent. We thus propose to push the intent deeper into the network fabric rather than limiting it to the edge, which means both transporting and processing it in-between network elements or orchestrators. Inspired by ICN, we introduce an Intent-Centric network management protocol, used to route intent in a distributed fashion rather than pushing configuration from a centralized node. We propose a router architecture as well as tentative ideas for forwarding algorithms. We show how carrying intent over the management plane could simplify orchestration systems, providing scalability, reliability, and flexibility by offloading many of their central functions.

The work presented in this chapter has been the object of three publications. [START_REF] Sardara | Virtualized ICN (vICN): towards a unified network virtualization framework for ICN experimentation[END_REF][START_REF] Augé | Simple and efficient ICN network virtualization with vICN[END_REF] cover the design and implementation of vICN. [START_REF] Augé | A network protocol for distributed orchestration using intent-based forwarding[END_REF] focuses on making the case for an Intent-Centric network management protocol. Furthermore, the vICN orchestrator has been released as open-source as part of the Linux Foundation Fast-Datapath (FD.io) project [START_REF]Virtualized ICN[END_REF].

The remainder of the chapter is organized as follows: Section 4.2 summarizes the state of the art, before introducing the vICN architecture in Section 4.3 and its implementation in Section 4.4; Section 4.5 provides concrete examples of vICN in action; Section 4.6 looks at future research directions, in particular how ICN-like approaches can be applied to create truly autonomous networks; Section 4.7 concludes this chapter.

Related work

Salsano et al. [START_REF] Salsano | Information centric networking over SDN and OpenFlow: Architectural aspects and experiments on the OFELIA testbed[END_REF] propose to introduce network virtualization for ICN networks through the use of OpenFlow. In [START_REF] Ravindran | 5g-ICN: Delivering ICN services over 5g using network slicing[END_REF], the authors address a similar issue and propose an architecture to perform network slicing. However, [START_REF] Salsano | Information centric networking over SDN and OpenFlow: Architectural aspects and experiments on the OFELIA testbed[END_REF] does not consider any network slicing technology while [START_REF] Ravindran | 5g-ICN: Delivering ICN services over 5g using network slicing[END_REF] misses the aspects of network management and control. Mininet [197] makes a step in that direction and sits closer to our objectives as it enables the creation of virtual networks based on containers and virtual switches. Application performance can be tested in emulated network conditions by setting parameters such as link delay and capacity, node CPU share, etc. However, it does not propose any slicing mechanism and lacks support for wireless or any control on applications or workload.

Interesting tools have also emerged from the testbed community. Emulab [START_REF] Hibler | Large-scale virtualization in the Emulab network testbed[END_REF] is a network experimentation framework joining emulation facilities with physical testbeds, but it lacks support for wireless topologies and offers no control over the network resources. NEPI [START_REF] Lacage | NEPI: using independent simulators, emulators, and testbeds for easy experimentation[END_REF] is maybe one of the most polyvalent tools. It hides all the complexity under a uniform programming interface. NEPI, however, lacks some control granularity and specializes in the management of resources provided by testbeds, assuming tasks such as slicing are already performed.

The Cloud computing community has made important efforts to facilitate the use of data center resources. Cloud Operating Systems have been proposed, such as OpenStack [186], designed to manage and monitor large-scale deployments, providing access to network, computing, and storage resources through a set of homogeneous APIs and sub-projects. Available tools are generally oriented towards applications being deployed in a global pool of resources. Containerspecific tools such as Kubernetes [187] present some interesting aspects in that they expose a unique consistent API for simplicity, with however limited control over granularity for our purpose. Automation is ensured by third-party tools layered on top of these standard APIs, like Chef [START_REF]OpenStack Chef[END_REF], which are intrinsically limited by their procedural language design, where the user must make every step of the deployment explicit, manually adapt to the current state, and handle errors. Other tools (e.g., Puppet [201]) use a descriptive language, where the user only needs to describe his/her needs and leave the rest to the tool. Despite the integration effort in Cloud computing, the silos around functionalities and the proliferation of APIs appear limiting for our purpose. The system does not enable simple setup and control for users, nor to build applications on top.

The now joint SDN and NFV communities are maybe the closest to our needs, at least from an architectural point of view. In [START_REF] Institute | Network functions virtualisation (NFV); management and orchestration[END_REF] for instance, the authors describe a set of design principles for the Management and Orchestration (MANO) of virtualized network functions (VNF). Their approach is based on a modular architecture, clearly identifying the fundamental function such as user and VNF description, orchestration, etc. They also point the need to ensure reliable management by considering the lifecycle of the resource they manage. OpenDayLight is a promising candidate framework for building NFV capabilities, as it relies on a model-driven abstraction layer that fits with our requirements. However, this aspect is mainly used from a software engineering point of view rather than to offer programmability of the resource (called "microservice"). Moreover, the orchestration is layered on top of other modules that behave as silos.

The vICN framework

The high-level architecture of vICN, presented in Figure 4.1 reminds of NFV proposals such as MANO. Our contribution is in the design of a resource model able to carry intent and on its use as the underlying end-to-end unifying language. Resources are specified according to different degrees of detail: e.g., the infrastructure is described precisely to form a Resource database that serves as a base for deployment. On the other hand, user specifications might be general or abstract and only mention Resources of interest for the user. The role of the Resource processor is to turn an abstract and incomplete description into a set of Resources mapped on the infrastructure leading to a consistent deployment. Once Resources are selected, the orchestrator translates them into a set of actions to be performed, based on the current state of the deployment and on constraints due to task synchronization or sequentiality. The resulting actions are processed by a scheduler. It outputs an execution plan and dispatches parallel tasks to a worker pool with the objective of minimizing the deployment time.

To summarize, vICN is based on two main abstractions: (i) Resources, which are external units of information exposed to users, developers and infrastructure providers; (ii) Tasks, which are internal units of information defined by developers to translate Resource requests into changes in the network deployment state.

Resource model

Most of the current intent-based frameworks are built on an intent-model, such as NEMO [START_REF] Hares | Intent-Based Nemo Overview[END_REF] or PGA [204]. As depicted in Figure 4.2, the role of the Intent module is to translate the intent-model into the configuration model used by the underlying orchestrator, e.g., YANG [START_REF] Bjorklund | The YANG 1.1 Data Modeling Language[END_REF]. It is the configuration model which is used, e.g., starting from the orchestrator module in Figure 4.1. In vICN, a unique Resource model is used globally from the user interface to the scheduling module.

This model, specifically constructed to hold intent rather than configuration, is built using an object-relational model [START_REF] Date | Foundation for object/relational databases: the third manifesto[END_REF]. It defines a base object as a set of typed attributes and methods, where types refer to standard integers, strings, etc., or to newly defined object themselves. The query language built on top of it (in the spirit of SQL or SPARQL) is used to create, destroy and manipulate those objects, either for Resource setup or to retrieve monitoring information. This model thus benefits from the power and expressiveness of the relational algebra [START_REF] Paredaens | On the expressive power of the relational algebra[END_REF] and of some key concepts of Object-Oriented Programming, namely composition and inheritance. It serves as an integrated interface based on both human-and machine-readable semantics.

Resources

Resources in vICN are logical representations of physical and/or remote elements whose state has to be kept synchronized. The state of a Resource can be affected by user queries, by events involving Resources, or through monitoring queries issued to the remote Resource. For instance, a routing component might recompute routes when notified about a change in the set of nodes, interfaces or links. The corresponding information flow is shown in Figure 4.3.

Such an approach is similar to the IETF standard YANG [START_REF] Bjorklund | The YANG 1.1 Data Modeling Language[END_REF], a humanand machine-readable data model to convey configuration inspired by Object-Oriented programming. However (and importantly), our model differs from YANG, adding three key features to move from holding configuration to modelling intent: Abstraction: Like [START_REF] Kuryla | Extending YANG with Language Abstractions[END_REF], we extend YANG with abstract objects by proposing standard models for abstract services (e.g., DNS server, node, or relational database) and resource inheritance. This brings two advantages: it unifies both configuration and intent models, simplifying the translation process, and enable late resource specialization (e.g., from node to Linux Container or Xen VM) in subsequent orchestrators or even at end-devices. Foreign models: As such, YANG models only describe per-device configuration, which prevents, for instance, device-to-device cooperation to offload part of the scheduling from the orchestrator. The vICN model, in contrary, has the notion of abstract foreign objects. For instance, a DNS server can be made aware of the existence of a new node for which it must record a domain name and retrieve the assigned IP address directly from the device on which the node is deployed instead of relying on the orchestrator. Scheduling information: Foreign requirements are not enough on their own to enable efficient device-to-device cooperation. Indeed, it still presents a flat temporal model while certain services are ordered (some services require others to be completed before them, e.g., a domain-name registration comes after IP address assignment). We thus enrich YANG groupings to distinguish parallel and sequential groupings.

Resource state

The state of a Resource is tracked, for reliability and consistency, by a Finite State Machine (FSM) presented in the left part of Figure 4.4. The FSM models the possible states of a Resource (rectangles, raising events) and the pending operations, or tasks, being executed (round shapes). The transitions are dictated by user actions or internal events and follow the typical lifecycle of an object: INITIALIZE is called when the shadow Resource and its object are being created for internal setup; CREATE and DELETE are the respective constructor and destructor: they can create or destroy the remote Resource and eventually set some attributes; GET retrieves the current state of a Resource, as well as the state of some of its attributes; UPDATE proceeds to attribute update and, in fact, runs parallel instances of an attribute-FSM, as shown on the right-hand side of the figure.

Resource mapper

For each transition between states, a developer can associate commands to be executed thanks to Resource mappers. These commands are handled by vICN through the task abstraction, which also inherits from the base object. They are specialized to cope with multiple southbound interfaces such as NET- [START_REF] Brown | The architecture of open source applications (SQLAlchemy)[END_REF]).

New tasks can be created through inheritance or composition, using algebraic operators to inform about their parallel or sequential execution. Resource objects are equipped with similar operators so that inheritance and composition produce a similar composition of tasks. Both resources and tasks define an algebra that the scheduler is able to use to perform calculations and optimize the execution plan. A subset of Resources defined in vICN is represented in

Resource processor

The resource processor plays the central role of adapting the user requests to the platform policies and the available Resources. For instance, an abstract Resource Node can be implemented either as an LXCContainer or a VM. This choice (specialization step) can be either explicitly dictated by user preferences or inferred by the tool itself depending on the context. As another example, when deploying an ICN forwarder on a node that runs ndnping, vICN might prefer an NDN forwarder instance, and do the same for all nodes of the same experiment.

The Resource processor is also in charge of mapping the Resources to de-Figure 4.5 -vICN partial Resource Hierarchy ploy onto available physical servers, by verifying all the constraints/policies required by the user, the developer, or by the infrastructure provider. Such an assignment can be assimilated to an (NP-Hard) Constraint-Satisfaction Problem (CSP) [START_REF] Mackworth | The logic of constraint satisfaction[END_REF] as the system has to accommodate several Resources in a finite capacity system in terms of networking, compute and memory. Both user-specified attributes and optional infrastructure provider policies are taken into account in the CSP as additional constraints. The output is a mapping from specification to implementation, which is also used to expose back monitoring to the user in a consistent way.

Orchestrator and Scheduler

The role of the orchestrator is to maintain one FSM per Resource, and ensure they reach the state requested by the user. Its outcome is a task dependency graph, which is shared with the scheduler. Task dependencies are derived from Resource dependencies, from the structure of the FSM, as well as from inheritance and composition constraints related to both the Resources and the mappers. The scheduler ensures the scalability of the deployment by scheduling the parallel execution of tasks over a pool of worker threads. Given the dependency graph presented before, this corresponds to a classical DAG scheduling problem, which has been studied in the community [START_REF] Sinnen | Task scheduling for parallel systems[END_REF]. Figure 4.6 presents a toyscenario underlining the need for optimizing the scheduling algorithm. In that small example, a greedy selection of the task with the higher distance to the destination is a sufficient heuristic to get an optimal solution and save one execution round. We remark that user interactions can cause the graph of tasks to evolve in time and require a recomputation. Heuristics [START_REF] Sakellariou | A hybrid heuristic for DAG scheduling on heterogeneous systems[END_REF] might then be preferred to optimal solutions because of their faster execution time, while providing satisfactory performance.

Because of its centralized architecture, the performance of vICN is also impacted by the network transmission time 1 . We alleviate this issue by enabling task batching when two consecutive tasks target the same node interface. The algebraic structure of tasks also makes it possible to reorganize the graph structure to better optimize execution or to increase the ability to batch tasks.

Implementation

The flexibility of vICN lies in its modular architecture organized around its Resource model. Various Resources can be developed to cover a wide range of underlying infrastructure and bring missing functionalities such as slicing or topology management. We here describe the current release and its set of base Resources covering the whole ICN stack. They build on and reuse available technologies, selected with scalability and reliability in mind.

vICN codebase

A first version of vICN has been open-sourced within the Community ICN (CICN) project [START_REF]FD.io CICN project[END_REF], as part of the Linux Foundation's Fast Data I/O effort. The code, written in Python, is released under the Apache v2.0 license. This release implements all the building blocks described in Figure 4.1 and is mature enough to launch complex ICN deployments. Alongside, we distribute a prepackaged container image containing the full CICN suite (including forwarders, the ICN stack, and useful applications), so that a full ICN network can be bootstrapped in tens of seconds or minutes. This suite includes a high-speed forwarder based on the VPP framework [START_REF]Vector Packet Processing -Fast Data I/O[END_REF], which already handles almost 1Mpps per thread in its first release.

Slicing

In addition to bare-metal deployments, vICN is able to slice nodes and network links offered by the infrastructure through a set of technologies described here. This is crucial for proper experiment isolation, and to realize separate control and management planes.

Virtual nodes can be implemented either as containers or as virtual machines. We chose containers as the core technology (via the use of Linux Containers [215]) because they are more lightweight and efficient (thanks to zero-copy mechanisms, the ZFS filesystem and simplified access to the physical resources). Increased security concerns and limitations such as sharing the same kernel are not limiting since most ICN functions are implemented in userland.

The network is shared at layer 2 via OpenVSwitch [START_REF]Open vSwitch[END_REF], which provides advanced functionalities, such as VLAN and OpenFlow rules, required by our wireless emulators and to bridge real external devices to the virtual environment. vICN fully isolates the deployment's network from the outside world by creating 1. network round-trip-time and, for instance with TLS, session establishment time a single and isolated bridge per deployment, using iptables as a NAT to provide external connectivity. On top of that, we reduce the load of the bridge and isolate control traffic from the data plane. Indeed, we directly link connected containers, through pairs of Virtual Ethernet interfaces (veth), thus bypassing the bridge. Connected containers that are spawned across different servers in a cluster are transparently connected through a GRE tunnel.

Finally, vICN has to arbitrate for shared resources on the physical host, be it names for interfaces (with constraints such as the 16-character limit on Linux) or containers, VLAN IDs, and even MAC or IP addresses depending on the required level of network isolation. It is important to do such "naming" properly not only for correctness, but also to simplify debugging and troubleshooting. vICN further enforces consistent names that uniquely identify a Resource, which allows for faster detection and recovery when the tool restarts or has to redeploy the same experiment.

IP and ICN topologies

Using the mechanisms described previously, it is possible to build a layer-2 graph on top of which vICN can set up IP and ICN connectivity. For IP networking, a centralized IP Allocation Resource is in charge of allocating IP prefixes and addresses to the different network segments of the graph. Global IP connectivity is then ensured by computing the routes to be installed on the nodes. vICN provides a generic routing module implementing various algorithms (such as Dijkstra or Maximum-Flow) taking as an input a graph (layer-2) and a set of prefix origins (allocated IP addresses). It outputs a set of routes, encoded as vICN Resources. Route setup is then driven by a Routing Table Resource, from which the Linux and VPP routing tables inherit.

The process is similar for ICN, except that we first build (IP or Ethernet) faces based on a configurable heuristic (e.g., L2 adjacency). We can then reuse the same routing module by feeding it with the face graph, and the set of prefix origins found in attributes of content producer Resources. The corresponding Routing Table is, in this case, implemented by the ICN forwarder. We remark that the use of multipath routing schemes (e.g., Maximum Flow) makes more sense in this context. The process results in a deployment accommodating IP and ICN coexistence, enabling performance comparison of both architectures at the same time.

Link emulation

A feature that is missing from most tools is the ability to measure the performance of applications running on top of virtual networks with specific bandwidth or propagation delay. vICN offers Resource attributes for the Linux Traffic Control layer (tc) in order to shape link bandwidth and emulate constrained networks.

A complementary aspect is the ability to use emulated radio Resources as an alternative to real hardware in a transparent fashion. Two types of radio channel are currently supported, WiFi and LTE, both based on real-time simulation features of the NS-3 simulator. The vICN radio channel Resource is implemented as a drop-in replacement of a regular radio link Resource. It connects stations and access point (or UEs and Base Station) through a configurable radio channel and hides the internal wiring from the user. The emulation then takes care of all relevant wireless features such as beaconing, radio frequency interference, channel contention, rate adaptation and mobility. Real-time emulation scales by using multiple instances orchestrated by an overarching mobility management Resource in vICN, communicating in real time with the different emulators. This process can collect relevant information from the simulation, and expose it to the internal model and thus monitoring.

Monitoring capabilities

Monitoring is natively implemented as part of vICN as a transversal functionality, building on the object model introduced in Section 4.3. The language offered by vICN allows querying any object attribute, including annotations made by the Resource processor and orchestrator about the host or the deployment state of the Resource. This is the same interface that is used by the orchestrator to query the current state of a remote Resource, to communicate with the emulators, or for the user to interact with vICN in order to change an attribute or create a new Resource at runtime. Its syntax closely matches the SQL syntax. More precisely a query object contains the following elements: the object name, a query type (create, get, etc.), a set of filters and attributes, eventually completed by attribute values to be set.

For periodic measurements such as link utilization, vICN provides a daemon that can be installed on the nodes and that exposes information via a similar interface. Communication between the components is ensured using the IP underlay setup by vICN.

Examples

We now illustrate some characteristics of vICN using a particular use case: mobile video delivery. This section is not meant to be exhaustive, but to illustrate how the design of vICN helped us solve practical challenges, and to emphasize general properties of the design that are relevant to other use-cases.

Use case description

The recent years have seen drastic changes in the video consumption patterns that put much pressure on delivery networks: the shifts in video quality (up to 4K), from broadcast to on-demand and from fixed to wireless and mobile networks. Our objective was to show that ICN addresses these challenges, using mechanisms like caching or multihoming over heterogeneous networks. physical link between DPDK-enabled network cards (the core). We use a prepackaged container image containing all the necessary software to reduce the bootstrap time.

Scalability

The simplification offered by vICN is illustrated by the following numbers: during the deployment, vICN created about 800 Resources compared to the 104 declared in the topology file, a reduction in complexity of 85-90%; more than 1500 bash commands were executed, either directly on physical machines, or on LXC containers. This even underestimates the number of Bash commands an operator would type to deploy an equivalent topology, as some are batched for efficiency reasons (e.g., we insert all IP routes for a given node in a single command). on a Cisco UCS-C with 72 cores clocked at 2.1 GHz. We first note that multithreading provides a sevenfold reduction in bootstrap time and that the topology can be deployed in about two minutes. The observed gains are due to the I/Ointensive nature of tasks, which spend most of their lifetime waiting for return values. This reduction is specific to our implementation and our simplistic scheduling heuristic. The shape of the curve remains nonetheless interesting, with a performance bound appearing. This is due to the underlying task graph, whose breadth intrinsically limits the number of tasks that can be run in parallel.

Programmability

One advantage of our Resource model (see Section 4.3.2) is the use of inheritance. It allows the user to choose his level of granularity depending on their needs and expertise. In particular, the user can remain oblivious to the underlying technology used to deploy Resources. We used that feature to scale the demonstration on a cluster of servers connected through a switch instead of a single powerful server. In that configuration, linking containers on different hosts requires to connect them to virtual bridges on their respective hosts, and to link these bridges through an L2-tunnel. The two deployments, shown in Figure 4.9, require different Resources and tasks. However, they can be realized with the same vICN specifications, thanks to the Link abstract Resource. Here, vICN completely abstracts the implementation complexity and enables painless switching from one deployment to the other.

The deployment of containers running VPP is another example of vICN's ability to shield a user from implementation and configuration details thanks to its Resource model. Indeed, VPP uses Direct Memory Access (DMA) to read and write in contiguous memory areas named hugepages. Both the host and the containers have to be configured to allocate and share enough of these hugepages. On top of starting and setting up the application on the container, VPP thus requires to execute commands on the physical node and to change the container's configuration before its creation. In vICN, simply linking VPP to a container is enough to perform the bootstrap. The tool is then able to change the other Resources (e.g., use a VPP-enabled container instead of the standard one) and to run all the necessary commands.

The flexibility of the framework also allowed us to switch Resources in many situations. During our tests, we replaced real tablets by emulated nodes to generate test workloads. During the demonstrations, we could also seamlessly use a real LTE mobile core instead of an emulated one. It only required to change one Resource in the specification and did not affect the rest of the scenario.

Monitoring and Reliability

We conclude by highlighting how the Resource model enables monitoring and debugging. As described in Section 4.4.5, vICN exposes a query language based on its underlying model for monitoring. This language can be used to collect information about network status at different time scales: link utilization, radio status, cache status etc. vICN thus integrates all information about the deployment in a consistent and query-able representation, building on the model introduced in Section 4.3. In the same way vICN provides an API to navigate through structured logs that may assist the whole process of software development.

An Intent-Centric network management protocol

Current intent-based frameworks (such as OpenStack Heat [217] or the Open-Networking Foundation Boulder project [218]) act as centralized humaninterfaces to translate intent into orchestration actions (e.g., configuration files or command-line instructions), which are then offloaded to other modules of the orchestrator. Compared to these, vICN already takes a step further by using a unified intent-based model (Section 4.3.2) for intent specification, resolution, and scheduling but remains nonetheless a single centralized framework. While such centralized approaches represent the first step towards intent-based networking, they suffer from stark limitations. Mainly, they keep orchestration centralized, which results not only in scalability issues (OpenStack, for instance, has over 9M lines of code and running a controller requires at least 3 physical machines with 12 CPU and 64GB of RAM [START_REF] Kofman | OpenStack hardware requirements and capacity planning: Servers, CPU and RAM[END_REF]) but also restricts the possibilities offered by intent-based networking in terms of network automation and innovation.

We argue that many limitations of current orchestrators come from the necessity to perform an early and centralized binding from the user's request to a set of device configurations, requiring full knowledge and preventing any further actors to participate in the resolution of the intent. We thus propose to push the intent deeper into the network fabric rather than limiting it to the edge, which means both transporting and processing it in-between network elements or orchestrators. In that regard, the recently established consensus around network management protocols such as NETCONF [START_REF] Enns | Network Configuration Protocol (NETCONF)[END_REF] and YANG [START_REF] Bjorklund | The YANG 1.1 Data Modeling Language[END_REF] is of particular interest.

Intent-based network model

As described in Section 4.3.2, the YANG data model is not too dissimilar to the vICN intent model. In particular, it is extensible and allows decoupling the model structure from its semantic aspects. However, despite sharing some similarities with object-oriented programming or relational databases, YANG does not include all of their features and thus lacks some expressiveness for encoding user intent or exposing relations and constraints within or in-between resources. The use of YANG as the central communication model thus forces intent to be entirely resolved in the origin orchestrator and largely limits the possibility of doing multi-party inference. Furthermore, it forces the orchestrator to keep a complete, fine-grained, and up-to-date database of all the objects present in the network to perform inference (e.g., in the vICN Resource processor -Section 4.3.3). This raises scalability, consistency, and concurrency issues, as multiple modules might modify the same resources synchronously.

To enable distributed intent resolution, a natural solution is thus to extend the reach of the vICN intent model from the orchestrator to the network. Note that, as noted in Section 4.3.2, small tweaks to YANG would effectively realize such a model:

-Abstraction: a proposal for extending YANG to support abstract object was introduced in [START_REF] Kuryla | Extending YANG with Language Abstractions[END_REF], using the extends keyword to provide resource inheritance. -Foreign models: Foreign objects could be defined in YANG model by using a foreign key, which would make the end-device aware that the object is implemented elsewhere. Foreign objects can then naturally be referenced using identityref or leafref. -Scheduling information: To provide scheduling information, YANG groupings can be completed with similarly defined sequences. In this case, grouping now indicates that both models can be applied in parallel whereas sequence indicates that they must be applied sequentially.

Model-based routing and forwarding

In a second step, we propose to depart from the traditional star deployment where all resources are reachable from a single orchestrator, to a more distributed approach where resources attached to different orchestrators advertise their capabilities throughout the network and allow users' intents to be routed back to those able to best satisfy the request. This essentially means building a routing and forwarding plane, similar to ICN in that forwarding is done based on an abstract resource rather than a physical network location. Like ICN, our proposal uses location-independent identifiers but these are multidimensional structures representative of the intent itself rather than one-dimensional names. Each orchestrator now becomes a router and is, in addition, able to split (composition) or transform the incoming request (specialization, attribute binding), which gets fully resolved upon reaching end devices of interest. This approach replaces the point-to-point transport of NETCONF by a multipoint-to-multipoint network propagation. An example of such propagation is provided in Figure 4.10.

The design of our intent router closely follows the structure of an ICN router as presented in Section 1.2.1, where the three main data structures have been adapted to our new addressing scheme: the Forwarding Information Base (FIB), used to match incoming intent requests to network locations, the Pending Intent Table (PIT), that keeps state to symmetrically route answers back to the origin of the corresponding intent, and a Content Store (CS) that can be used to cache answers.

The FIB is the main component of our router. It maps received resource advertisements to their ingress interface and uses this information to forward an intent to one or several next hops able to further satisfy it. This happens after an eventual local intent-resolution where the intent can be (partially) bound, specialized, or decomposed into multiple sub-intents using the network model. To perform the matching process over multi-dimensional intent objects, we developed a preliminary solution based on maximal subset matching algorithm [START_REF] Alon | Fast algorithms for maximum subset matching and all-pairs shortest paths in graphs with a (not so) small vertex cover[END_REF].

Like ICN, we store incoming requests into the PIT along with their ingress interface and associated outgoing sub-requests. The PIT thus collects all the necessary information to send the corresponding answers back up to their origin, thereby implementing symmetric routing. It serves as a distributed scheduling module, keeping track of requests in progress and allowing hop-by-hop reconciliation of concurrent messages. The PIT is thus crucial to ensure the synchronization and consistency of the execution in a multipoint-to-multipoint concurrent environment. Furthermore, the PIT contributes to the scalability of the system by aggregating redundant requests and execute them only once.

The CS caches responses flowing back through the router, and stores the current state of a network model deployment for improved performance. It can be used to access such information with lower RTT and network overhead. It also brings resiliency as the network can still at least partially operate during disconnection periods.

Summary and future work

In this chapter, we introduce vICN (virtualized ICN), an intent-based unified framework for ICN network configuration, management, and control to complement existing tools, especially for large scale and operational networks deployment. vICN is an object-oriented programming framework rooted in recent advances in SDN/NFV research that provides higher flexibility than existing virtualization solutions. It is specifically tailored to ICN, but its modular design allows for extensions to other technologies. While most of the current software is developed in silos, with significant limitations in terms of optim-ization, vICN offers the capability to optimize each component of the virtual network to provide carrier-grade service guarantees in terms of programmability, scalability, and reliability. Finally, we present opportunities for further optimization and decentralization of the management process by introducing an intent-centric network management protocol based on the data model that is central to vICN.

There are still many research issues to investigate to achieve intent-based networking. The first and obvious one is the evaluation of the scalability of our system in terms of computing overhead. Indeed, the forwarding algorithms mentioned in Section 4.6.2 are more complex than traditional name-based forwarding in ICN. We have explored preliminary ideas, using work on multi-dimensional forwarding in ICN through maximal subset matching [START_REF] Rogora | High-throughput subset matching on commodity gpu-based systems[END_REF]. Our first implementation suggests that it is a viable approach but we leave its description (and -especially -its evaluation) to future work.

The second issue is routing. Indeed, creating a scalable forwarding plane for intent requires to be able to fill up the routers FIB with the corresponding object models. As such, exploring seminal work for routing database queries [START_REF] Kumar | Efficient and scalable query routing for unstructured peer-to-peer networks[END_REF][START_REF] Huebsch | Querying the internet with PIER[END_REF] might give insight into realizing the object-based routing plane. Another approach would be to divide the properties of an object between "locator " properties for inter-domain routing and "identifier " for intra-domain inference and scheduling. Both approaches should be explored and evaluated in terms of deployment simplicity, expressiveness and scalability.

Finally, another stringent issue of our approach is security. Indeed, in NET-CONF the security model resides on securing the point-to-point communication channel (e.g., with SSH or TLS). Our approach currently does not include such a security model. In fact, we need to explore how to authenticate each of the modules that performed inference on the original intent. This is a difficult task that requires a thorough investigation, as a failure to find a scalable and tractable security model would prove fatal for any orchestration protocol.

Chapter 5

Conclusion

ICN is a promising solution for the IoT. Its salient features such as namebased forwarding, native multicast, or object-based security are natural solutions to many of the challenges that the IoT has raised for networks. However, to transform that envisioned fit into actual ICN-IoT deployments, concrete solutions for the network layer in the ICN-enabled IoT must be developed. Indeed, while much of the literature has addressed how ICN can benefit IoT applications, there lacks consistent work on routing and forwarding frameworks for ICN in the IoT context.

In this thesis, three conjoined problems were tackled: (i) how to perform efficiently routing and forwarding in ICN-IoT networks, (ii) how to use ICN forwarding to help IoT applications reach QoS targets, and (iii) how to deploy, manage, and orchestrate edge IoT networks and applications at scale. Overall, these three contributions pave the way for the ICN-enabled IoT. Indeed, they address (i) the problem of setting up a routing plane in WSNs and of (iii) managing the applications and forwarding plane in the edge. Finally, (ii) shows that clever forwarding strategies can help the deployed IoT applications reach their QoS target.

Geographic routing for the ICN-enabled WSN

In a first step, geographic routing and forwarding are evaluated as a solution for ICN-enabled WSNs. A secure geographic routing framework is proposed, composed of a neighbour authentication protocol, a beaconing protocol, a naming strategy, and a forwarding strategy. For the neighbour authentication protocol, two alternatives are evaluated with similar security features but based respectively on symmetric and asymmetric cryptography, showing that while asymmetric cryptography allows for reducing the number of messages and keeping the transmission local, it has a higher energy cost because of its computational complexity. An analytical model is used to compare geographic routing to an enhanced version of the "flood-and-learn" approaches of the literature in terms of implementability (i.e., CPU and memory footprint on the IoT device) and energy efficiency (i.e., energy overhead caused by the routing protocol). To provide a realistic evaluation, the model is parameterized with data issued from simulation, from previous work, and from experience on a standard IoT sensor 95 platform. Geographic routing is shown to require less memory than flood-andlearn while also providing large energy savings in cases where the topology is dynamic.

Popularity-based latency control for Fog applications

In a second step, we look at how clever forwarding can help IoT applications fulfil their QoS requirements. In particular, a popularity-based approach for controlling admission in a limited capacity Fog platform is proposed. Called the LRU-AC, it relies on an LRU meta-cache to estimate the popularity of a request and accept the popular ones in the Fog platform. Using an analytical queueing model, the LRU-AC is shown to provide a good balance between efficiency and practicality compared to either request-blind or oracle-based approaches. An implementation of the LRU-AC on FPGA-hardware using Ageing Bloom filters (ABF) is proposed so as to realize the LRU-AC with minimal latency overhead and maximal throughput. The validity of the implementation is justified using an analytical model and verified via simulation. The ABF-AC is shown to achieve high throughput, low latency overhead, and to multiply the Fog admission-rate by 10 compared to request-blind admission control in the tested scenario.

Intent-based management of ICN

Finally, a solution for the conjoint deployment, configuration, and management of IoT networks and applications is proposed. Virtualized ICN (vICN), an intent-based unifying framework for network configuration, management, and application orchestration is introduced. It exploits recent progress in Intent-Based Networking to define a new intent-based resource model used to unify network management and application orchestration. Through concrete examples, the programmability, scalability, and reliability of vICN are illustrated. Looking forward, we show how the vICN resource model can actually be used to decentralize intent-based frameworks. In combination with an Intent-Centric protocol, inspired from ICN to perform routing based on intent objects, it sets the foundations for truly developing intent-based networks (instead of intentbased orchestrators) able to automate themselves using intent as the unifying language.

Future research directions

The work in this thesis relies often on analytical model and simulation, especially in Chapter 2 and Chapter 3. Such an approach offers the advantages of generality, flexibility, and allows to derive insights that are not bound to a given scenario or implementation (which was a goal of this thesis). It should, however, be completed with a system approach, that uses deployment on actual physical hardware to test, e.g., the implementability and scalability of the solutions. It is with that in mind that code-source has been released to implement most of the schemes proposed in this thesis. Our GPSR module [START_REF] Enguehard | marceleng/geographic-icthings: Code for the paper: On the cost of geographic forwarding for information centric things[END_REF] could, for instance, be integrated into a standard ICN-WSN stack (e.g., CCN-Lite [START_REF]CCN Lite: Lightweight implementation of the content centric networking protocol[END_REF] over RIOT-OS [START_REF] Baccelli | RIOT OS: Towards an OS for the internet of things[END_REF]) and deployed over a public IoT test-bed such as the FIT IoT-LAB [START_REF] Adjih | FIT IoT-LAB: A large scale open experimental IoT testbed[END_REF] to verify, e.g., the energy consumption predicted by the model or to compare the GPSR algorithm with other approaches, such as hyperbolic geographic routing [START_REF] Zeng | Resilient routing for sensor networks using hyperbolic embedding of universal covering space[END_REF][START_REF] Lehman | An experimental investigation of hyperbolic routing with a smart forwarding plane in NDN[END_REF].

However, rather than testing each contribution individually on specialized test-beds, vICN can be used to connect them and test their scalability and interoperability. In particular, one could imagine the following deployment:

-a virtualized WSN created thanks to (i) containerized RIOT -a virtualized edge network virtualized with vICN, e.g., using a topology from [START_REF] Knight | The internet topology zoo[END_REF] and assigning realistic computing and storage capacities to each node;

-an IoT application running on these nodes and in a Cloud platform, using data retrieved from the virtualized WSN and deployed via vICN;

-realistic traffic models for either endogenous or exogenous requests.

Deploying such a testbed would allow assessing benefits of our mechanisms in realistic settings across the full IoT vertical, but also to evaluate the opportunities to further development, optimization and integration of the proposed solutions.

For instance, in a submitted patent application 1 , a solution is discussed to automate the parameterization of the LRU-AC, which currently depends on the request arrival rate and the popularity distribution. Our proposal exploits a PIcontroller to control the response time of the Fog node via the filter-size k LRU . Another research direction would be to extend the Fog admission control to clusters of servers, as the Fog is usually considered as highly distributed [START_REF] Bonomi | Fog computing and its role in the internet of things[END_REF][START_REF] Khan | A content-based centrality metric for collaborative caching in information-centric fogs[END_REF]. While independent LRU-AC modules could be deployed independently in front of each Fog node, this might result in an under-optimized utilisation of the global storage and computing resources. On the other hand, enforcing collaboration between caches can be difficult because, e.g., of the time scale of the feedback loop versus the request arrival rate, or because of the difficulty of reaching distributed consensus. A candidate solution should thus not only have strong mathematical guarantees in terms of resource utilization but also be flexible and adaptive enough to fit the IoT context. The LRU-AC, combined, for instance, with a clever request-aware load-balancing technique, could be the foundation for such a distributed QoS control framework.

Similarly, let us consider κ 2 such that:

1 - f ( k 1 ) f ( k 1 + κ 2 ) 2 f ( k 1 + κ 2 ) 2 ≥ log R (A.5)
We then take γ = 1 -f ( k1) f ( k1+κ1)

and k = k 1 + κ 2 in Equation (A.2) to obtain (recalling that f ( k 1 ) = n a ):

P[K 1 ≥ k 1 + κ 2 ] ≤ 1 R (A.6)
Taking κ = max{κ 1 , κ 2 } and combining Equation (A.4) and Equation (A.6) gives, using the union bound P[A ∪ B] ≤ P[A] + P[B]:

P |K 1 -k 1 | ≥ κ ≤ 2 R as desired. For practical purposes, if κ 1 k 1 , it is possible to use a Taylor approxima- tion of f : f ( k 1 -κ 1 ) = f ( k 1 ) -κ 1 f ( k 1 ) + O(κ 2
1 ) The left-hand-side of Equation (A.3) then becomes:

κ 2 1 f ( k 1 ) 2 3f ( k 1 ) + O(κ 3 1 )
Thus in practice, Equation (A.3) can be fulfilled by taking:

κ 1 ≈ √ 3n a log R f ( k 1 )
Similarly, Equation (A.5) can be fulfilled by taking:

κ 2 ≈ √ 2n a log R f ( k 1 ) which justifies taking κ = max{κ 1 , κ 2 } ≈ √ 3na log R f ( k1)
.

A.3 Proof of Equation (3.7)

As R 1, q(i)

1 and thus (1 -q(i)) k = (1 -(kq(i))/k) k ≈ exp(-kq(i)). Thus: f (k) ≈ R i=1 [1 -exp(-kq(i))] = R i=1 1 -exp(- k iH R,α )
and finally:

f (k) ≈ R 1 1 -exp(- k xH R,α ) dx
Computing the derivative f of this approximation yields:

f (k) = R 1 1 xH R,α exp(- k xH R,α
)dx

We will now distinguish between two cases, depending on whether α = 1.

A.3.1 The case α = 1

We have, in this case:

f (k) = 1 H R,1 E 1 ( k RH R,1 ) -E 1 ( k H R,1 )
where

E 1 (x) = +∞ -x e -t
t dt is the exponential integral function. As E 1 (x) ≈ 0 for x

1 and E 1 (x) ≈log xγ for x 1 (where γ ≈ 0.577 is the Euler-Mascheroni constant), if we assume 1 H R,1 k RH R,1 , we obtain:

f (k) ≈ 1 H R,1 -γ -log( k RH R,1 ) = log(RH R,1 ) -γ H R,1 - log k H R,1 Using H R,1 ≈ log R + γ yields: f (k) ≈ 1 + log log R -2γ log R + γ - log k log R + γ
Straightforward integration leads to:

f (k) ≈ 1 + 1 + log log R -2γ log R + γ A k - 1 log R + γ B k log k
which is an approximation of the form f (k) ≈ Ak -Bk log k with A, B > 0.

A.3.2 The case α = 1

We have, in this case:

f (k) = 1 kα 2 xα exp(- k x α H R,α ) -xE 1+1/α ( k x α H R,α ) R x=1 where E n (x) = +∞ 1 e -xt
t n dt is the generalized exponential integral function. Again, we use E 1+1/α (x) ≈ 0 and exp(-x) ≈ 0 for x 1. Thus: Furthermore, E 1+β (x) ≈ 1 β +x β Γ(-β)+ 1 1-β x for x 1 and 0 < β < 2, where Γ is the gamma function defined by Γ(z) = ∞ 0 x z-1 e -x dx. Using β = α -1 ∈ [0, 2] (since we assume α > 1/2) gives:

f (k) ≈ R kα exp(- k R α H R,α ) - 1 α E 1+1/α ( k R α H R,α ) 1. H R,1 k RH R,1 is a reasonable assumption. H R,1 ≈ log R + γ
f (k) ≈ R kα 1 - k R α H R,α -1 - 1 α Γ(- 1 α ) k R α H R,α 1/α - 1 α -1 k R α H R,α = -Γ(-1 α ) α 2 H 1/α R,α k 1/α-1 + R 1-α (1 -α)H R,α
Integrating that equation yields:

f (k) ≈ - Γ(-1 α ) αH 1/α R,α B k 1/α + m 1-α (1 -α)H R,α A k (A.7)
which is of the general form f (k) ≈ Ak -Bk 1/α . Equation (A.7) can then be further approximated by using the following approximation for H R,α : It can be seen that the relative error is smaller than 1%, and for objects that belong to the tail of the catalogue -thus having a little impact when computing the hit rate over the whole catalogue. un client émet un paquet appelé "Intérêt" qui est acheminé jusqu'à un endroit où la donnée est stockée. Un paquet dit "Donnée" est utilisé pour transporter la donnée jusqu'au client en utilisant le chemin inverse de l'Intérêt correspondant. Le passage d'une approche centrée sur la localité à une approche centrée sur le contenu apporte de nombreux avantages théoriques, décrits dans [START_REF] Shang | Named data networking of things (invited paper)[END_REF] : l'unification de la gestion des couches applicatives et réseaux, la possibilité de découvrir des services dans le réseau, ou le support natif de la diffusion multipoint et du cache au niveau réseau, etc.

H R,α ≈ R 1-α -1 1-α ∀α < 1 ζ(α) - 1 (α-1)R α-1 ∀α > 1 where ζ(s) = ∞ i=1 i -
Néanmoins, si beaucoup d'études se sont penchées sur ces avantages et sur l'application d'ICN à des cas d'usage spécifique, il manque dans la littérature une étude systématique d'une question fondamentale : comment gérer l'acheminement des paquets dans un réseau ICN utilisé pour l'IoT ? En effet, les réseaux ICN-IoT posent des défis bien particuliers à l'acheminement de paquets en termes de passage à l'échelle, de flexibilité face à des réseaux très dynamiques ou des applications à forte contrainte de latence, ou de sélection du meilleur chemin quand un objet est disponible à plusieurs endroits du réseau. Les travaux de cette thèse se penchent sur cette question, en regardant l'acheminement de paquets à travers l'ensemble de l'architecture IoT. En particulier, les contributions présentées ici se répartissent en trois grandes parties. D'abord, la possibilité d'utiliser un acheminement géographique et sécurisé dans les réseaux de capteurs sans fil est évaluée. Ensuite, des stratégies d'acheminement sont proposées avec pour objectif de contrôler le temps de réponse d'une application déployée sur une plateforme de type Fog. Enfin, une architecture logicielle et réseau pour gérer conjointement réseaux et déploiement d'applications virtualisées à partir d'intentions abstraites est présentée.

B.2 Acheminement géographique dans les réseaux de capteurs sans-fil

Dans un premier temps, le problème de l'acheminement dans les réseaux de capteurs sans-fil est étudié. En effet, de précédents travaux ont montré des avantages d'ICN par rapport aux protocoles standards basés sur IPv6 [START_REF] Baccelli | Information centric networking in the IoT: Experiments with NDN in the wild[END_REF] en termes d'utilisation mémoire et de consommation énergétique sur les capteurs, ce qui est crucial pour des capteurs à faible puissance. Néanmoins, ces avantages ne viennent pas sans de nombreux défis, et en particulier le problème d'acheminer les paquets efficacement avec le moins de trafic de contrôle possible.

Pour répondre à ces défis, cette thèse contient une étude de la possibilité d'utiliser de l'acheminement géographique [START_REF] Chen | A survey of void handling techniques for geographic routing in wireless networks[END_REF]. L'acheminement géographique consiste à assigner à chaque paquet une destination géographique (par exemple, avec des coordonnées de géolocalisation) qui sera utilisé ensuite dans chaque noeud relais pour choisir le prochain saut. La plupart de ce type d'algorithme est fondée sur deux modes de relais : la sélection gloutonne (lequel de mes voisins est le plus proche de la destination du paquet) et une technique d'évitement des puits (situation dans laquelle le noeud relais est le plus proche de la destination du paquet dans son voisinage). Une revue des techniques d'évitement de puits est présentée dans [START_REF] Chen | A survey of void handling techniques for geographic routing in wireless networks[END_REF].

B.2. ACHEMINEMENT GÉOGRAPHIQUE DANS LES RÉSEAUX DE CAPTEURS SANS-FIL125

B.2.1 L'architecture SLICT

Afin de mettre en oeuvre l'acheminement géographique dans un réseau centré contenu de capteurs sans fil, l'architecture SLICT (pour objets localisées, sécurisées et centrés contenu) est introduite. Cette architecture repose sur quatre piliers : un protocole d'association sécurisée, un protocole de balisage sécurisé, un algorithme d'acheminement géographique, et une pile ICN implémentée dans le système d'exploitation RIOT.

Association sécurisée entre capteurs

Le but d'un protocole d'association sécurisé entre capteurs est d'assurer que l'ensemble des appareils qui participent au réseau sans-fil à plusieurs sauts sont des noeuds de confiance. Pour ce faire, une approche dite "réseau de confiance" est utilisée : chaque paire de capteurs en ligne de mire l'un de l'autre (i.e., physiquement capables de communiquer) effectue un protocole d'authentification mutuelle. Ainsi, Compagno et al., ont proposé OnboardICNg, un protocole d'association qui repose sur de la cryptographie symétrique. Dans cette thèse, un protocole similaire est proposé, fondée lui sur de la cryptographie asymétrique (plus adaptée à l'authentification mais plus coûteuse pour des capteurs à énergie limitée). La comparaison de ce protocole à OnboardICNg met en lumière un compromis intéressant. D'un côté, l'utilisation de la cryptographie asymétrique permet d'échanger moins de message et d'avoir un échange local aux deux noeuds s'authentifiant alors que la cryptographie symétrique nécessite de se connecter à une tierce partie qui sert d'ancre mutuelle de confiance. De l'autre côté, malgré l'apparition récente de modules physiques pour faire de la cryptographie asymétrique à moindre coût, OnboardICNg est beaucoup moins coûteux en termes d'énergie et de latence.

Balisage sécurisé

Le balisage permet aux noeuds d'informer régulièrement leurs voisins de leur position actuelle. C'est un mécanisme essentiel pour pouvoir réaliser l'acheminement géographique. Néammoins, les réseaux ICN sont fondés sur une approche par tirage alors que le balisage est une opération de poussée de données. Pour résoudre ce conflit, SLICT utilise des entrées persistantes dans la PIT, crée à la suite du protocole d'association sécurisée. Afin de garantir la sécurité de ce balisage, les balises sont encryptées avec une clé créée pendant le processus d'association.

Algorithme d'acheminement géographique

SLICT utilise le protocole GPSR [START_REF] Karp | GPSR: Greedy perimeter stateless routing for wireless networks[END_REF] pour acheminer les paquets géographiquement. Ce protocole a deux principaux modes de fonctionnements : le routage glouton, où chaque noeud choisit son voisin le plus proche de la destination comme prochain relais d'un paquet, et le routage dit de périmètre, utilisé pour sortir des puits. Si le lecteur est renvoyé à [START_REF] Karp | GPSR: Greedy perimeter stateless routing for wireless networks[END_REF] pour plus d'information sur GPSR, il est important de noter que le routage de périmètre nécessite de transporter de l'état à l'intérieur de chaque paquet, encodé sous la forme d'un champ Type-Longueur-Valeur (TLV).

Résultats principaux

Le modèle permet de montrer deux résultats principaux. D'abord, en termes de faisabilité, l'acheminement géographique offre des avantages en termes d'utilisation mémoire pour les topologies denses et/ou larges. Ceci est dû à la localité de la stratégie d'acheminement, qui ne demande que de connaître des informations locales (i.e., la position des voisins) plutôt que des informations globales (un prochain saut pour chaque nom supporté sur le réseau IoT). De plus, l'acheminement géographique offre des avantages pour les réseaux très dynamique grâce à son trafic de contrôle local moins couteux que l'inondation -même optimisée avec MPR -du réseau de capteurs sans-fil. Pour les réseaux plus stables, l'état additionnel dans le paquet nécessaire pour GPSR rend l'acheminement géographique marginalement plus couteux en énergie que MPR.

B.3 Contrôle d'admission pour applications à temps de réponse contraint

Dans un second temps, le problème du contrôle d'admission dans des plateformes de type Fog est traité. En effet, pour être utiles, les données produites par les capteurs doivent pouvoir être traitées en temps limité. Dans ce but, le Fog a été inventé [START_REF] Bonomi | Fog computing and its role in the internet of things[END_REF]. Il s'agit d'une plateforme de calcul et de stockage distribué se situant au bord du réseau, proche dans l'endroit où les données IoT sont produites et consommées afin de réduire la latence. Néanmoins, et en comparaison avec le Cloud, le Fog manque d'élasticité. Il est donc important de contrôler la charge du Fog pour garantir le temps de réponse de l'application. En particulier, cette section contient une proposition de contrôle d'admission de requêtes dans un noeud de type Fog, conçue pour optimiser l'utilisation des ressources sous contrainte de temps de réponse.

B.3.1 Contrôle d'admission dans le Fog et modélisation

La situation considérée est la suivante : un utilisateur envoie une requête pour une certaine donnée IoT. Pour produire cette donnée, il est nécessaire de récupérer une ou plusieurs mesures brutes de capteurs et d'effectuer des calculs sur ces mesures brutes. Comme souvent dans les interactions hommes-machine, l'utilisateur attend une réponse dans une latence de l'ordre de 100 ms [START_REF] Miller | Response time in man-computer conversational transactions[END_REF]. Deux solutions de calcul et de stockage sont disponibles : le Fog, qui fournit une capacité de calcul et de cache fixe mais sans frais, et le Cloud, qui fournit une capacité de calcul et de cache infinie mais avec un coût qui croit en fonction de leur utilisation. Afin de répartir les requêtes entre Fog et Cloud, une stratégie de contrôle d'admission est déployée devant le Fog. Pour chaque requête, la stratégie décide ou bien d'accepter la requête dans le Fog, ou bien de la rediriger vers le Cloud. La problématique à résoudre est donc la suivante : comment trouver une stratégie qui minimise les coûts de Cloud tout en gardant le temps de réponse moyen sous une limite donnée ?

Pour répondre à cette problématique, un modèle mathématique est proposé, fondée sur un réseau de file d'attentes. Chaque file du modèle est choisie à partir d'exemples pertinents dans la littérature. En particulier, le réseau est représenté par une file M/G/1-PS, représentant le partage du réseau entre les différents flux [START_REF] Niu | Handling flash deals with soft guarantee in hybrid cloud[END_REF][START_REF] Nabe | Analysis and modeling of world wide web traffic for capacity dimensioning of internet access lines[END_REF][START_REF] Boyer | Heavy tailed m/g/1-PS queues with impatience and admission control in packet networks[END_REF]. Pour les plateformes de calcul, le Fog est représenté par une file M/G/1-PS, qui représente sa capacité finie [START_REF] Niu | Handling flash deals with soft guarantee in hybrid cloud[END_REF][START_REF] Urgaonkar | An analytical model for multi-tier internet services and its applications[END_REF], tandis que l'élasticité parfaite du Cloud est représentée par une file M/G/∞. Enfin, la stratégie de contrôle d'admission est représentée par une fonction φ : r → [0, 1] qui à une requête pour une donnée r associe une probabilité d'être accepté dans le Fog. Le modèle de file d'attente peut ainsi être utilisé pour calculer le temps de réponse moyen et le coût associé à chaque stratégie.

B.3.2 La stratégie LRU-AC

Il y a trois chemins possibles pour une requête dans le système Fog-Cloud : le Cloud, le cache du Fog, ou le système de calcul du Fog. Comme le système de calcul du Fog a une capacité fixe, l'unique solution pour augmenter la capacité globale de Fog est d'augmenter le taux de succès du cache. Pour ce faire, une stratégie de contrôle d'admission pour le Fog est de sélectionner uniquement les requêtes pour des données populaires, qui auront une probabilité plus élevée d'être dans le cache.

Pour faire cette sélection, il faut donc être capable de (i) identifier la donnée cible pour chaque requête et (ii) d'en extraire des prédictions de popularités. La solution présentée dans cette thèse, appelée le LRU-AC, remplit ces deux conditions, avec l'avantage supplémentaire d'avoir une implémentation performante en termes de débit et de latence car elle peut être réalisée sur du matériel de type FPGA [START_REF] Zilberman | Net-FPGA SUME: Toward 100 gbps as research commodity[END_REF].

Identification des données cibles

Pour identifier les données cibles, le LRU-AC repose sur une architecture ICN spécifique, appelée hICN (pour Hybride-ICN) [START_REF] Muscariello | Hybrid Information-Centric Networking[END_REF]. hICN est une architecture ICN construite dans IPv6/TCP, c'est à dire que les champs des en-têtes IP et TCP sont utilisé pour fournir une sémantique ICN. En particulier, les données sont nommées en utilisant (pour un Intérêt) l'adresse IPv6 de destination sous la forme d'une location (préfixe de 64 bits) et d'un identifiant (suffixe de 64 bits). Cette architecture est particulièrement intéressante pour le cas d'usage du contrôle d'admission en FPGA, car elle permet d'accéder à une sémantique applicative dans l'en-tête réseau grâce à des champs qui ont une position et une taille constante. En particulier, cela permet de réutiliser tous les outils développés pour IP comme la plateforme P4 [START_REF] Bosshart | P4: Programming protocol-independent packet processors[END_REF].

Prédiction de popularité

Pour prédire la popularité des requêtes, le LRU-AC utilise un filtre LRU, i.e., un méta-cache sur les identifiants des données avec la politique d'éviction dite de l'objet utilisé le moins récemment (LRU). En effet, la présence (resp. absence) d'un identifiant dans un tel cache indique qu'il s'agit probablement d'une donnée populaire à accepter dans le Fog (resp. impopulaire à rediriger dans le Cloud). En particulier, le comportement d'un tel cache peut être prédit en fonction de la distribution de popularité des requêtes grâce à l'approximation de Che [START_REF] Che | Hierarchical web caching systems: modeling, design and experimental results[END_REF], ce qui permet d'intégrer cette stratégie dans le modèle de file d'attente présenté plus haut.

B.4. ORCHESTRATION D'APPLICATIONS ET GESTION DE RÉSEAUX CENTRÉS CONTENUS129

Pour implémenter le filtre LRU en FPGA, le LRU-AC utilise des filtres de Bloom vieillissant (ABF) [START_REF] Yoon | Aging bloom filter with two active buffers for dynamic sets[END_REF]. Grâce à un modèle mathématique, il est montré qu'il est possible de paramétrer un ABF pour avoir un comportement identique à un filtre LRU. Une implémentation du LRU-AC est donc proposée en FPGA, ce qui permet d'obtenir un module de contrôle d'admission avec un débit de ligne de 16 Mpps et un temps de traitement d'une requête de moins de 3 µs.

B.3.3 Principaux résultats

Pour analyser les performances du LRU-AC, deux méthodes sont employées. Tout d'abord, le modèle mathématique est soumis à un processus d'optimisation pour comparer les performances moyennes du LRU-AC par rapport à une stratégie omnisciente et une stratégie naïve. Ensuite, pour comprendre le comportement plus précis du LRU-AC, une campagne de simulation est menée. En particulier, l'évaluation montre que le LRU-AC fonctionne quasiment aussi bien qu'une stratégie omnisciente (avec connaissance parfaite de la distribution de popularité). De plus, l'étude des distributions de temps de réponse simulé du système valide le choix d'implémenter le filtre LRU avec un ABF et montre un taux de dépassement de la limite de seulement 5%.

B.4 Orchestration d'applications et gestion de réseaux centrés contenus

Enfin, la problématique de l'orchestration et de la gestion de réseaux IoT-ICN est abordée. Ceci est particulièrement important dans l'Internet des Objets centrés contenu, entre autres à cause de l'échelle et de la diversité des réseaux IoT, du manque d'outils existant dans le monde d'ICN, ou du fort potentiel d'interaction entre application et réseaux ICN qui requiert une unification de la gestion des réseaux et de l'orchestration des applications.

B.4.1 Orchestration fondée sur l'intention

La diversification grandissante des utilisations et des technologies réseaux a rendu la gestion de réseau trop complexe pour l'être humain. Pour répondre à ce défi, de nouveaux paradigmes de gestion sont apparus, en particulier les réseaux définis par logiciel (SDN) [START_REF] Kim | Improving network management with software defined networking[END_REF] avec leurs orchestrateurs centralisés et riches en fonctionnalités. En particulier, des interfaces fondées sur l'intention ont été développées [190]. Dans une plateforme intentionnelle, le gestionnaire de réseau spécifie des objectifs abstraits au lieu de spécifier la procédure nécessaire pour atteindre ces objectifs. La plateforme est ensuite capable de configurer et de réguler le déploiement réseau de manière à atteindre ces objectifs.

B.4.2 La plateforme vICN

Dans cette optique, la plateforme vICN est introduite dans cette section. Il s'agit d'une suite logicielle d'orchestration et de gestion de réseau ICN à partir de l'intention.

En particulier, vICN utilise un modèle d'intention qui permet à l'utilisateur de spécifier son intention avec une granularité sur-mesure, de l'intention abstraite à la configuration détaillée. Ce modèle d'intention est central au fonctionnement de vICN. Il est fondé sur un modèle relationnel objet [START_REF] Date | Foundation for object/relational databases: the third manifesto[END_REF]. Ce modèle a pour principal composant les objets, définis comme un ensemble d'attributs typés et de méthodes. Les attributs typés sont ou bien de type standard (chaîne de caractère, entier, etc.) ou des références à d'autres objets. Ces objets bénéficient ainsi de l'ensemble des avantages de la programmation orienté objet (héritage, abstraction, composition). De plus, le modèle est augmenté par la définition de relations entre les objets, par exemple de dépendance. La combinaison de l'héritage et des relations entre objets est l'élément principal qui permet de transformer une intention abstraite en plan de configuration fonctionnelle.

Pour garantir la mise en place de la configuration et l'état du système, chaque objet instancié dans le modèle est associé à un automate, qui garde en mémoire l'état dans lequel se trouve la ressource déployée. Les transitions entre états dudit automate correspondent à des actions sur le réseau -par exemple la création d'un conteneur Linux qui fait passer de l'état d'initialisation à l'état de création. Chacun des attributs de l'objet est aussi muni de son propre automate. L'utilisation d'automates permet de fournir des garanties en termes d'exécution d'un modèle. En particulier, les actions sur le réseau sont effectuées par de multiples fils d'exécution. La répartition des tâches entre fils d'exécution est faite par un ordonnanceur qui utilise le modèle pour apprendre l'ordre entre les différentes tâches à effectuer.

L'ensemble de ces mécanismes a été implémenté et est distribué sous licence libre dans le cadre du projet FD.io de la Linux Foundation [START_REF]Virtualized ICN[END_REF]. Le code source, écrit en Python, contient une libraire fournie de ressources qui permettent de déployer des réseaux virtualisés complexes. En particulier, vICN a montré de bonnes performances sur un déploiement d'environ 50 noeuds virtualisés représentant un réseau de distribution de vidéo. To confirm that hypothesis, the fundamental issue of routing and forwarding in the ICN-IoT must be addressed. This thesis investigates this topic across the IoT architecture. First, a scheme to securely forward ICN interests packets based on geographic coordinates is proposed for low-power wireless sensor networks (WSN). Its efficiency is compared to an optimized flooding-based scheme similar to current ICN-WSN approaches in terms of deployability and scalability using an analytical model. Realistic data for the model is derived from a mixture of simulation, literature study, and experiments on state-of-the-art sensor boards. Geographic forwarding is shown to halve the memory footprint of the ICN stack on reference deployments and to yield significant energy savings, especially for dynamic topologies. Second, ICN is used to enhance admission control (AC) to fixed-capacity Edge-computing platforms to guarantee request-completion time for latency-constrained applications. The LRU-AC, a requestaware AC strategy based on online learning of the request popularity distribution through a Least-Recently-Used (LRU) filter, is proposed. Using a queueing model, the LRU-AC is shown to decrease the number of requests that must be offloaded to the Cloud. An implementation of the LRU-AC on FPGA hardware is then proposed, using Ageing Bloom Filters (ABF) to provide a compact memory representation. The validity of using ABFs for the LRU-AC is proven through analytical modelling. The implementation provides high throughput and low latency.

iii 1 Introduction 1 . 1

 11 The Internet-of-Things . . . . . . . . . . . . . . . . . . . . . . . . 1.1.1 IoT applications . . . . . . . . . . . . . . . . . . . . . . . 1.1.2 IoT networks . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.3 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Information-Centric Networking for the IoT: motivation . . . . . 1.2.1 Information-Centric Networking . . . . . . . . . . . . . . 1.2.2 ICN for the IoT . . . . . . . . . . . . . . . . . . . . . . . 1.3 ICN for the IoT: background . . . . . . . . . . . . . . . . . . . . 1.3.1 ICN for the WSN . . . . . . . . . . . . . . . . . . . . . . . 1.3.2 ICN for the Fog . . . . . . . . . . . . . . . . . . . . . . . . 1.3.3 ICN for specific IoT applications . . . . . . . . . . . . . . 1.4 Thesis contribution . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 Forwarding and routing in the ICN-IoT: challenges . . . . 1.4.2 Contribution and organization . . . . . . . . . . . . . . . 1.5 Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1 . 1 -

 11 Figure 1.1 -Typical functioning of an IoT deployment

Figure 1 . 2 -

 12 Figure 1.2 -Examples of IoT deployments

Figure 1 . 4 -

 14 Figure 1.4 -Articulation between the contributions presented in the thesis

Figure 2 . 2 -

 22 Figure 2.2 -Synoptic of the ICN-WSN beaconing protocol

Figure 2 . 3 -

 23 Figure 2.3 -Coexistence of forwarding strategies in the reference ICN-WSN stack

Figure 2 . 4 -

 24 Figure 2.4 -The TLV field used by GPSR for keeping in-flight state (with s l =16).

Listing 2 . 1 -

 21 Benchmarking code uint32_t do_iteration () { // Initializes structures and counter do_initialize (); DWT -> CYCCNT = 0; // Performs the micro -benchmark perform_bench (); // returns the number of used CPU cycles return DWT -> CYCNT ; } P CP U from data-sheets:

E

  -size of the encrypted message (byte) -energy (µJ) AES-CCM software: E=5.55⌈s msg /16⌉+7.92 AES-CCM hardware

Figure 2 . 5 -

 25 Figure 2.5 -Energy cost of AES-CCM based on size of message. Software encryption measurement are gathered as described in Section 2.4.3. Measurement for hardware encryption are provided in Table6of[START_REF] Shafagh | Talos: Encrypted query processing for the Internet of Things[END_REF]

4

 4 Number of CPU cyclesName-based: n c = 70.87n f + 201.83 GPSR: n c = 621.14d + 577.[START_REF] Montenegro | Transmission of IPv6 packets over IEEE 802.15.4 networks[END_REF]

Figure 2 . 6 -

 26 Figure 2.6 -Cycles per forwarding decision on the OpenMote based on number of neighbours/FIB entries. Boxplots report cycle-level accurate measurements with the method in Section 2.4.3, lines reports linear fitting of the data.

Figure 2 . 7 -

 27 Figure 2.7 -Energy cost of the forwarding modules

Figure 2 . 8 -

 28 Figure 2.8 -Average value of card(V t )

Figure 2 . 10 -

 210 Figure 2.10 -Expected number of transmitted messages E[N tr (T, d)]

Figure 2 . 11 -

 211 Figure 2.11 -Relative message budget N GP SR m N M P R m

  -(s b n tr,s E b tx + E AES ) + d(s b n tr,s E b rx + E AES ) (s b n tr,s E b tx + E AES ) + d(s b n tr,s E b rx + E AES ) /fc + T 4E AES + n tr,s (s i,g + sc )(E b rx + E b tx ) (2.21)

Figure 2 . 12 -

 212 Figure 2.12 -Expected message budget for GPSR and MPR for the reference deployments as a function of network dynamism

Figure 2 . 13 -

 213 Figure 2.13 -Contours of the relative memory and CPU footprints of GPSR and F&L ICN. The heatmap shows areas where GPSR outperforms F&L ICN for both criteria (white), for memory utilisation (grey) or for neither (black)

Figure 3 . 1 -

 31 Figure 3.1 -Reference IoT, Fog and Cloud architecture

  Blind-AC vs φ, sc = 3.1 • 10 6 LFU-AC vs sc, kLF U = 1.4 • 10 5

Figure 3 . 3 -

 33 Figure 3.3 -Constraint value (left) and cost (right) of the system vs φ and s c for the Blind-and LFU-AC at fixed cache size

3. 5 .

 5 AGEING BLOOM-FILTERS FOR AN HARDWARE-ACCELERATED LRU-AC63

Figure 3 . 6 -Figure 3 . 7 -

 3637 Figure 3.6 -Cost vs Zipf parameter α for the Blind-, LFU-and LRU-AC

Figure 3 . 8 -

 38 Figure 3.8 -Number of distinct elements in the active filter A 1 (••), in the passive filter A 2 (--) and in the full filter A 1 ∪ A 2 (-), as well as the function f (k) (-) used to compute them and the stochastic average Ñ of |A 1 ∪ A 2 |.

Figure 3 . 9 -

 39 Figure 3.9 -Simulation and model results for Ñ vs n a (R=10 7 and α=1). Each simulation point consists of the average value on 10 8 arrivals.

Figure 3 . 10 -

 310 Figure 3.10 -Simulation and model results for the expected hit-rate of the ABF depending on n a (R=10 7 and α=1). Each simulation point consists of the average value measured over 10 8 arrivals

Figure 3 . 11 -

 311 Figure 3.11 -Bloom filter pipeline illustration with n h = 4: latency is 7 cycles, throughput is one operation per 8 cycles.

Figure 3 . 12 -Figure 3 . 13 -Figure 3 . 14 -

 312313314 Figure 3.12 -Cumulative distribution functions of the measured request response time for the LRU-and ABF-AC

Figure 4 . 1 -

 41 Figure 4.1 -vICN functional architecture

Figure 4 . 2 -Figure 4 . 3 -

 4243 Figure 4.2 -Functioning of current intent-based frameworks

Figure 4 . 4 -

 44 Figure 4.4 -vICN Finite State Machine

Figure 4 . 5 ,

 45 showing, in particular, the four base abstractions of Node, Interface, Channel and Application from which most Resources inherit, similarly to the model defined in[210].

Figure 4 . 6 -

 46 Figure 4.6 -Toy scenario -vICN scheduler

Figure 4 .

 4 [START_REF] Pister | Industrial Routing Requirements in Low-Power and Lossy Networks[END_REF] represents an example of such a video delivery network. It consists of four parts: a heterogeneous WiFi/LTE access network with multihomed video clients; a backhaul network aggregating the resulting traffic with workload from emulated clients; a core network composed of two nodes; and producers serving 4K video. All nodes have a fully-featured ICN-stack. The core nodes use a VPP-based high-speed forwarder, the others a socket-based one. Overall, the deployment consists of 22 LXC containers, 3 real devices connected to the virtual network, 22 emulated links (including WiFi and LTE channels), and one

Figure 4

 4 Figure 4.7 -Mobile World Congress topology

Figure 4 . 8 -

 48 Figure 4.8 -vICN bootstrap time vs number of worker threads

Figure 4 .

 4 8 then shows the time taken by vICN to deploy the topology as a function of the number of dedicated threads. We deployed this topology

Figure 4 . 9 -

 49 Figure 4.9 -Alternative vICN topology deployments on single server and a cluster.

Figure 4 . 10 -

 410 Figure 4.10 -Example of request forwarding

  s is the Riemann zeta function. A.4 Numerical evaluation of t C (r) As an example, Figure A.2 depicts t C (r) and h(r) for a catalogue of R = 10 7 objects distributed according to a Zipf distribution with α = 1. It can indeed be visualized that the regions where t C (r) varies slowly and h(r) is close to one are mutually exclusive. The validity of Che approximation is quantified in Figure A.3, which depicts the exact value h(r) from Equation (3.9) versus its Che approximation from Equation (3.10) (where t C is found by solving Equation (3.11)), for the same parameters as in Figure A.2.

Figure A. 2 -Figure A. 3 -

 23 Figure A.2 -Che's approximation illustration: h(r) and t C (r) for a Zipf catalogue with α = 1 and R = 10 7 . In the region where t C (r) evolves steeply (r ≤ 5000), we have h(r) ≈ 1 and thus the precise value of t C (r) has little impact.

Titre:

  Routage centr é-contenu pour l'Internet des Objets Mots cl és : R éseaux-Centr és contenus, Internet des objets, routage R ésum é : Les r éseaux centr és contenus (ICN) sont consid ér és comme une solution aux nouveaux d éfis et modes de communication li és à l' émergence de l'Internet des Objets (IoT). Pour confirmer cette hypoth èse, la probl ématique fondamentale du routage sur les r éseaux ICN-IoT doit être abord ée. Cette th èse traite de ce sujet à travers l'architecture IoT. Premi èrement, une m éthode s écuris ée est introduite pour acheminer des paquets ICN à partir de coordonn ées g éographiques dans un r éseau sans-fil de capteurs à faible puissance. Elle est compar ée à une inondation optimis ée du r éseau inspir ée des approches existant dans la litt érature. En particulier, leur faisabilit é et passage à l' échelle sont évalu és via un mod èle math ématique. Le mod èle est param étr é gr âce à des donn ées r éalistes issues de simulation, de la litt érature, et d'exp ériences sur des capteurs. Il est montr é que le routage g éographique permet de diviser la m émoire n écessaire sur les capteurs par deux et de r éduire consid érablement le co ût énerg étique du routage, en particulier pour des topologies dynamiques. Ensuite, ICN est utilis é pour contr ôler l'admission à une plate-forme de calcul de type Fog afin de garantir le temps de r éponse. La strat égie de contr ôle d'admission propos ée, le LRU-AC, utilise l'algorithme Least-Recently-Used (LRU) pour apprendre en direct la distribution de popularit é des requ êtes. Son efficacit é est d émontr ée gr âce à un mod èle fond é sur un r éseau de files d'attente. Une impl émentation du LRU-AC est propos é, utilisant des filtres de Bloom pour satisfaire aux contraintes des cartes FPGA. Son bienfond é est prouv é par un mod èle math ématique et son efficacit é en termes de latence et d ébit d émontr ée. Enfin, on pr ésente vICN, un outil pour la gestion et la virtualisation de r éseaux ICN-IoT. Il s'agit d'une plate-forme qui unifie la configuration et la gestion des r éseaux et des applications en exploitant les progr ès des techniques d'isolation et de virtualisation. vICN est flexible, passe à l' échelle, et peut remplir diff érents buts : exp ériences à grande échelle reproductibles pour la recherche, d émonstrations m élangeant machines émul ées et physiques, et d éploiements r éels des technologies ICN dans les r éseaux IP existants. Title : On Information-Centric Routing and Forwarding in the Internet of Things Keywords : Information-Centric Networking, Internet of Things, Forwarding Abstract : As the Internet of Things (IoT) has brought upon new communication patterns and challenges, Information-Centric Networking (ICN) has been touted as a potential solution.

  Finally, the management and virtualization of ICN-IoT networks are considered. vICN (virtualized ICN), a unified intent-based framework for network configuration and management that uses recent progress in resource isolation and virtualization techniques is introduced. It offers a single, flexible and scalable platform to serve different purposes, ranging from reproducible large-scale research experimentation to demonstrations with emulated and/or physical devices and network resources and to real deployments of ICN in existing IP networks. Universit é Paris-Saclay Espace Technologique / Immeuble Discovery Route de l'Orme aux Merisiers RD 128 / 91190 Saint-Aubin, France

  Reference WSN deployments . . . . . . . . . . . . . . . . . . . . 2.3 Reference Information-Centric Things (ICN-WSN) Architecture . 2.3.1 Secure neighbour discovery . . . . . . . . . . . . . . . . . 2.3.2 Secure beaconing . . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Methodology overview . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Experimental setup . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.3 Computation . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.4 Energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Cost of forwarding a single ICN packet . . . . . . . . . . . . . . . 2.5.1 Frame transmission and reception . . . . . . . . . . . . .

2 Geographic routing 2.1 Geographic routing . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 2.5.2 Data Encryption and Decryption . . . . . . . . . . . . . . vii Chapter 1

Table 1 .

 1 1 -Location of IoT building blocks

	Device type	Location
	Sensor	IoT network
	Actuator

Table 1 .

 1 2 -Classification of IoT applications by QoS requirements

	Application class QoS requirement Example use case
	Latency-critical	1-10 ms	Factory automation
	Latency-sensitive	100-500 ms	Building automation
	Latency-tolerant	None	Environmental monitoring

  .3.

	Content	no	Name in	no	LPM in	faces Forward Interest
	in CS?		PIT?		the FIB	on selected faces
	yes		yes
	Reply with		Aggregate
	Data packet		Interest
	Figure 1.3 -Flowchart of ICN Interest forwarding

Table 2 .

 2

		1 -Reference WSN deployments
	Deployment	Deployment class	No. of	Node	Ref.
	name		Nodes	degree
	A Place de la Na-	Urban sensor network	97	3.8	[13]
	tion
	B Great Duck Is-	Environmental sensor	150	4.6	[110]
	land	network
	C CASAS	Home automation	30	8	[4]
	D Sensor Andrew Building automation	1000	15	[111]

  j proves to d nbr that it shares a symmetric key with the central authority; 2. symmetrically, d nbr proves to d j that it shares a symmetric key with the central authority; 3. d nbr generates a secret symmetric key for d j and d nbr to encrypt their unicast layer-2 traffic; 4. d nbr and d j use the aforementioned key to exchange broadcast keys (the broadcast key is a symmetric key propagated by one node to its direct physical neighbour to enable encrypted L2 broadcasts).

		d 1	Interest	d 2
			name: /my_AMI/hello
		1
			Content name: /my_AMI/hello	r n1 ← RNG()
		2	payload: r n1 , DSA K1 ()
			Interest
		3	name: /my_AMI/auth/r n1
	r n2 ← RNG()	4	Content name: /my_AMI/auth/r n1 payload: r n2 , C 2 , DSA K2 ()
			Interest
		5	name: /my_AMI/auth/r n2
			Content
			name: /my_AMI/auth/r n2 Payload: C 1 , DSA K1 ()
		6
	Asymmetric Cryptography. We further design an ICN-based protocol that
	uses asymmetric cryptography, such as Elliptic Curve Cryptography (ECC).
	Compared to symmetric cryptography-based OnboardICNg, where every au-
	thentication session requires contact with an authentication server, asymmetric
	cryptography allows nodes to authenticate each other without any third party.
	Local exchanges imply spatial reuse of the wireless medium and reduce the en-
	ergy footprint due to relaying traffic towardsthe authentication server. This

Table 2 .

 2 2 -Cost of encrypting (AES-128) or signing (ECC) 128b on the TelosB and OpenMote

	TelosB	OpenMote
	ECC160 sw AES128 hw	ECC192 sw	AES128 hw
	15 mJ [116] 14.3 µJ [117] 11.4 mJ [118] 0.9 µJ [118]

Table 2 .

 2 3 -asymmetric cryptography vs symmetric cryptography-based authentication protocols

	Board Crypto Messages (#) Energy (mJ) Latency (s)
	TelosB AES hw	9	4.3 -6.4	1.4
		ECC sw	6	53.3 -57.3	10.9
	Open	AES hw	9	0.54 -0.89	0.13
	Mote	ECC hw	6	22.5 -28.7	0.95

Mote supports both AES and ECC in hardware. We collect energy costs of cryptographic operations in table 2.2, which we use for the performance evaluation. We then contrast (i) number of messages, (ii) energy cost and (iii) latency for both schemes in table 2.3.

Table 2 .

 2 4 -Characteristics of the OpenMote

	Architecture	ARM Cortex-M3 (32 bits)
	MCU	Texas Instrument CC2538 (32 MHz)
	RAM (ROM)	32 kB (512 kB)
	Encryption HW	AES & ECC
	Encryption cost [118] 19.7 µJ (SW, AES-CCM, 128bits)
		8.7 µJ (HW, AES-CCM, 128bits)
	Consumption [138]	39 mW (CPU at 32 MHz, no RX/TX)
		60 mW (CPU idle, RX at -50 dBm)
		72 mW (CPU idle, TX at 0 dBm)

particular, we detail the experimental setup (Section 2.4.1) and focus our attention on the most relevant implementation criteria: namely, (i) memory footprint (Section 2.4.2), (ii) CPU overhead (Section 2.4.3), and (iii) energy consumption (Section 2.4.4

Table 2 .

 2 5 -Size of Interest (I), Geo-interest (GI), and Data (D) ICN frames

	Packet Type

n + s l Geo-Interest 79B + s n + s c Data 802.15.4 interface, we rely on measurements performed by Shafagh et al. [118].

Table 2 .

 2 5 details the different fields of IEEE 802.15.4 ICN Interest, geographic-Interest and Data frames and reports the total frame size (as a function of the name or location size). As shown by this table, the geographic-Interest packet format differs from the ICN Interest only by the presence of the GPSR TLV that is used on top of the name and name-components TLVs to perform the routing.

Table 2 .

 2 6 -Summary of variables used in the evaluation

	Parameter	Symbol	Default value
	No. of neighbours	d	15
	No. of ICN names	n s	2000
	No. of FIB entries	n f	15
	Size of a location info	s l	8 B
	Size of a name	s n	log 2 (n s )
	Size of the content	s c	32 B
	Energy cost of AES encryption	E AES	10 µJ
	No. of tries / transmission	n tr,s	eq. (2.6)
	L2 drop probability	p c	[144]
	No. of times a packet is forwarded dur-	N tr (T, D)	eq. (2.19)
	ing flood (including L2 retries)
	Energy cost of transmission/bit Energy cost of reception/bit	E b tx E b rx	1.163 µJ 0.96 µJ
	Max number of hops of a packet on the	T	8
	WSN
	Size of an ICN Interest packet	s i	56B + s n
	Size of a geographic ICN packet	s i,g	58B+s n +s l
	No. of Interest/Content exchanges be-	f c	free parameter
	fore a route change
	Energy content of an AA battery	E AA	15 390 J
	Budget of Interest/Data exchanges dur-	N
	ing the lifetime

m eq. (2.21) and eq. (2.20) (iv) frame encryption, and (v) frame transmission. We summarize the various variables used in the mode in Table

2

.6.

Table 2 .

 2 7 -Additional bytes sent in the reference ICN-WSN architecture

	Beacons (per node) Interest packet (per packet & hop)
	58 + s id + s l	2 + s l

Table 3 .

 3 1 -Variables used in the model

	Application specific		unit
	Number of possible requests	R	-
	Cumulated arrival rate	λ	req/s
	Amount of service work	X	CPU cycles
	Raw data size	s r	B
	Processed data size	s p	B
	Application latency constraint	∆	s
	Request popularity distribution	q(r)	-
	Optimization variables
	Load-balancing function	φ(r)	-
	Cloud cache size	s c	Objects
	Total request serving time	T (φ, s c )	s
	Cost function	Π(φ, s c )	$/s
	Fog characteristics
	Fog compute capacity	p f	Hz
	Fog cache size	s f	Objects
	Access network capacity	κ a	B/s
	Access network propagation time	τ a	s
	TLS establishment delay	τ f	s
	Cloud characteristics
	Cloud compute capacity	p c	Hz
	DB query delay	τ d	s
	Transit network capacity	κ t	B/s
	Transit network propagation time	τ t	s
	TLS establishment delay	τ c	s
	Cloud pricing
	Compute price	c c	$/s
	Network price	c n	$/s
	Storage price	c s	$/B
	Miscellaneous
	Cache hit probability	hf c (r, sf c )	-

Table 3 .

 3

			2 -Arrival rate per queue in network
	AC	AC module Access down.	λ
		TLS -Fog
	Fog

Table 3 .

 3

		3 -An example application
	Deployment	Application
	3 GHz s f 10 5 (1 GB) p f κ a 10 Gbit/s	R λ E[X] 10 7 CPU cycles 10 7 10 kHz
	τ a	2 ms	s r	1 MB
	p c	2 GHz	s p	10 kB
	τ d	1 ms	α	1
	κ t	1 Gbit/s	∆	100 ms
	τ t	20 ms
		Cloud pricing
	c n		$0.08 per GB
	c s	$0.004446 per GB and hour
	c c	$0.033174 per vCPU and hour

(iii) from the Cloud (disregarding the Cloud cache vs the Cloud compute tradeoff). An effective AC strategy should then maximize the proportion of traffic handled by the Fog. Since the Fog compute has a fixed capacity, increasing the amount of traffic handled by the Fog can only be done by increasing the cache hit-rate. The AC policy should then aim at maximizing the global Fog cache hit-rate (as defined by h f = r φ(r)h r (r, φ)) while keeping the Fog-Compute arrival rate λ f,m bounded.

  t. changes in the popularity

			Move that
	yes		entry to the top of the	Accept in Fog
			filter
	Is the
	identifier
	in the filter?		no
	no	Insert an entry at the top of the filter	Is the filter full?	Forward request to Cloud
			yes	Remove the
				bottom entry
				in the filter
		Figure 3.4 -Functionning of the LRU-AC
	distribution; (iv) it requires minimal effort for integration in ICN forwarders as
	the LRU structure is already used for caches.

Table 3 .

 3

			4 -Optimal costs and parameters per AC
	Method		E[φ]		s c		Π
	Blind LFU LRU	0.084 0.75 (k LF U = 1.4 • 10 5 ) 3.0 • 10 6 7.6 $/h 3.1 • 10 6 27 $/h 0.71 (k LRU = 2.8 • 10 5 ) 2.9 • 10 6 8.6 $/h
		1e-5% 1e-4% 1e-3% 0.01%	0.1%	1%	10%
	Optimal cost ($/h)	5 10 15 20 25	Blind-AC LFU-AC LRU-AC
		10 0	10 1	10 2	10 3	10 4	10 5	10 6
			Fog cache size s f (nb of objects)

Table 3 .

 3 5 -Resource usage of a Bloom filter atom

	s hash s key	Logic (LUTs) Registers BRAM Multipliers
	20	24	185	134	33	2
	21	24	246	152	65	2
	22	24	357	186	129	2
	20	48	281	178	33	4
	21	48	317	196	65	4
	22	48	431	230	129	4

Table 3 .

 3

	6 -Dataplane resource usage
		LUTs	BRAM Power (W)
	2 Bloom filters	715	130	0.089
	P4	103424	564	8.550
	Total	104139	694	8.639
	Available resources	433200	1470	-
	Resource consumption	24.0 % 47.2 %	-

Table 3 .

 3

		7 -Dataplane performance
	Latency (µs) Throughput (Mpps)
	2.62	16.7

  -OS nodes built in the native mode (which allows building RIOT stacks as Linux processes); (ii) virtualized IEEE 802.15.4 links thanks to the lr-wpan module of ns-3 [210] integrated into vICN similarly to IEEE 802.11 or LTE;

  is usually smaller than 20. On the other hand, RH R,1

R na. As shown by eq. (3.7), k stays in the same order of magnitude as na and thus k RH R,1 .

The CYCCNT register, see http://infocenter.arm.com/help/index.jsp?topic=/com.arm. doc.ddi0337e/ch11s05s01.html

While Python is enough for F&L, we had to rewrite the tool in C for speed efficiency in the case of MPR. Both tools are available in the GitHub page

This requires either offline analysis of the popularity distribution, or to keep counters of incoming requests. Both solutions are not flexible to popularity changes and are difficult to implement efficiently.

The relative cost gain of the LFU-AC (LRU-AC) over the Blind-AC (Π Blind-AC -Π LRU -AC )/Π Blind-AC is deceptive here as it asymptotically grows to 100%

Acknowledgements

ACKNOWLEDGEMENTS qui rendirent les moments passés au laboratoire toujours plus agréables et amicales. Je dois évidemment beaucoup à l'ensemble de mes co-auteurs, dont

Appendix A

Appendix of Chapter 3

A.1 Computing the Fog hit rate for the LRU-AC As explained in Sec. IV.D of [START_REF] Garetto | A unified approach to the performance analysis of caching systems[END_REF], our method to compute the cache hit rate in the Fog assumes independence between the arrivals at the filter and at the Fog cache. To remove that assumption, we can consider the Discrete Time Markov Chain (DTMC) presented in Fig. 4 of [START_REF] Garetto | A unified approach to the performance analysis of caching systems[END_REF] (and summarized in Figure A.1). It represents the presence of a given piece of content in the filter and in the cache at the time of arrival of a request for said content. In particular, an unwritten assumption of the model in [START_REF] Garetto | A unified approach to the performance analysis of caching systems[END_REF] is that the characteristic time t 1 of the filter is smaller than the characteristic time t 2 of the cache (t 1 < t 2 ). Thus, q a = 1e -t1q(n) is the probability that the inter-arrival time is smaller than t 1 ; q b = e -t2q(n) is the probability that the inter-arrival time is bigger than t 2 ; q c = 1 -(q a + q b ) is the probability that the inter-arrival time is bigger than t 1 but smaller than t 2 .

We can now predict the Fog hit rate using the balance equations for the given chain. Note that compared to [START_REF] Garetto | A unified approach to the performance analysis of caching systems[END_REF], the hit probability is only derived from the probability p (1,1) of being in the state (1, 1) (when the content is in both the filter and the cache), whereas for the LRU-2Q case the state (0, 1) (where the content is only available in the cache) also leads to a hit. In particular, the Fog hit probability for content r reads:

Furthermore, t 2 can be computed by resolving the following equation:

For i ∈ {1, . . . , R}, let Y k i the random variable whose value is 1 if content i has been drawn from the catalogue after k steps and 0 otherwise. Y k i is a Bernoulli variable with parameter 1 -(1q(i)) k , and by definition,

Figure A.1 -Discrete Time Markov Chain for the filter-cache interaction in the Fog (Fig. 4 of [START_REF] Garetto | A unified approach to the performance analysis of caching systems[END_REF]). Each state correspond to content presence in the filter (first coordinate) and the Fog cache (second coordinate). R i=1 Y k i (as long as A 1 has not been reset). Let K 1 be the random variable giving the time necessary to fill the filter:

. We want to show that K 1 is close to k 1 , with high probability. More precisely, let > 0, we want to find κ such that:

According to Chernoff bounds [START_REF] Mitzenmacher | Probability and computing: Randomized algorithms and probabilistic analysis[END_REF], we know that

with high probability. Precisely, for γ ∈ (0, 1]:

Let κ 1 be such that:

, we obtain:

Résumé étendu en Français

B.1 Introduction

Les dix dernières années ont vu l'émergence, sous le nom d'"Internet des Objets" (IoT) de multiples applications : villes intelligentes [START_REF] Cocchia | Smart and digital city: A systematic literature review[END_REF][START_REF] Dohler | Routing Requirements for Urban Low-Power and Lossy networks[END_REF][START_REF] Balcon | Expérimentation: Cisco mesure la fréquentation de la place de la Nation[END_REF], voitures [START_REF] Hai An | A survey of intelligent transportation systems[END_REF] et bâtiments [START_REF] Martocci | Building Automation Routing Requirements in Low-Power and Lossy Networks[END_REF][START_REF] Kastner | Communication systems for building automation and control[END_REF][START_REF] Cook | CASAS: A smart home in a box[END_REF] connectés, etc. Ces domaines, malgré leur multiplicité, sont des expressions de la même tendance qui consiste à munir des objets du quotidien d'une connexion internet. Les applications IoT présentent des défis considérables pour les réseaux de communications en termes de capacité, de flexibilité, ou de qualité de service. Pour répondre à ces défis, de nouvelles architectures réseau ont été mises en avant telles que les réseaux centrés contenu (ICN). Cette thèse s'inscrit dans cette lignée en enquêtant sur l'acheminement de paquets dans l'Internet des Objets centré contenu.

Les applications IoT sont fondés sur le même fondamental principe : d'automatiser ou d'optimiser une partie de notre environnement en y déployant des machines, capables non seulement de mesurer certaines variables environnementales (les capteurs) mais aussi d'agir dessus (les actuateurs). Ces machines sont dotées d'une connectivité sans-fil (par exemple le standard IEEE 802.15.4) et forment ainsi un réseau -l'Internet des Objets. Les applications IoT peuvent ensuite utiliser cette connectivité pour effectuer une boucle de contrôle qui prend en entrée les mesures des capteurs et sort des instructions pour les actuateurs. Ce fonctionnement général peut être utilisé pour représenter des boucles d'une complexité variable, du réglage d'un radiateur connecté à partir d'un thermomètre au contrôle des systèmes de direction d'un véhicule à partir de données produites par des centaines de capteurs embarqués.

Les particularités de l'Internet des Objets posent des défis particuliers aux réseaux, en particulier en termes de passage à l'échelle, de flexibilité mais aussi d'adaptation à des modes de communications différents [START_REF] Shang | Challenges in IoT networking via TCP/IP architecture[END_REF]. Pour cette raison, des architectures et protocoles réseaux alternatifs ont été proposées pour l'IoT, et en particulier les réseaux centrés contenus (ICN) [START_REF] Zhang | Named data networking[END_REF]. ICN est un paradigme réseau nouveau qui repose sur l'utilisation de noms porteurs de sens comme couche centrale du réseau. Ces noms sont des identifiants, qui décrivent l'objet (la donnée ou le service par exemple) accédé sur le réseau, se distinguant ainsi des traditionnelles adresses IP qui indiquent la location dudit objet. Ils sont utilisés avec un modèle de transmission par tirage : pour récupérer une donnée, 123 Pile ICN dans le système d'exploitation RIOT L'ensemble de ces modules a été codé dans une pile ICN dans le système d'exploitation RIOT [START_REF] Baccelli | RIOT OS: Towards an OS for the internet of things[END_REF]. En particulier, pour permettre la cohabitation entre diverses stratégies d'acheminement, le préfixe /g/ est utilisé pour tout routage géographique. Ce préfixe est associé dans la FIB ICN à une entrée virtuelle qui représentent tous les voisins capables de faire du routage géographique. Le prochain saut est choisi parmi ces voisins en utilisant GPSR dans la couche de stratégie d'acheminement.

B.2.2 Évaluation de l'acheminement géographique

Pour évaluer une stratégie d'acheminement, deux critères principaux sont utilisés : la faisabilité (en termes de mémoire et de calcul sur les capteurs) et l'efficacité (en termes de coût énergétique de l'apprentissage des chemins). Ces coûts sont calculés à l'aide d'un modèle mathématique. En particulier, le modèle est construit pour deux stratégies principales : l'acheminement géographique (telle qu'introduit dans SLICT), et l'acheminement de type "inonde-etapprends", correspondant à la référence dans la littérature sur ICN-IoT.

Inonde-et-apprends

L'approche dite "Inonde-et-apprends" (I&A) est l'approche la plus fréquemment trouvée dans la littérature ICN-IoT [START_REF] Baccelli | Information centric networking in the IoT: Experiments with NDN in the wild[END_REF][START_REF] Hail | Caching in named data networking for the wireless internet of things[END_REF][START_REF] Anastasiades | Dynamic unicast: Informationcentric multi-hop routing for mobile ad-hoc networks[END_REF][START_REF] Amadeo | Named data networking for IoT: An architectural perspective[END_REF]. Elle repose sur l'inondation du réseau pour des Intérêt ICN pour lesquels aucune route n'existe. La route est apprise grâce à la réponse au dit Intérêt : le voisin qui transmet le paquet Donnée correspondant (i.e., portant le même nom ICN) est enregistré comme prochain saut pour ce nom.

Pour compenser la naïveté de l'approche inonde-et-apprends, une version optimisée du processus d'inondation est aussi considérée. Elle utilise l'algorithme MPR (multi-point relais) [START_REF] Qayyum | Multipoint relaying for flooding broadcast messages in mobile wireless networks[END_REF] qui permet d'optimiser l'inondation en ne choisissant qu'un sous-ensemble des voisins pour propager les Intérêts pour lesquels aucune route n'est établie.

Modèle mathématique

Un modèle mathématique est proposé pour représenter la performance des trois stratégies considérées : GPSR, I&A, et MPR. Ce modèle dépend de trois variables principales : le taille du réseau (le nombre de noms ICN à supporter), la densité du réseau (le nombre moyen de voisins de chaque capteur), et son dynamisme (la fréquence avec laquelle une route pour un nom donné change). Il est construit en deux parties : la première modélise le coût de relai d'un Intérêt pour un noeud donné en fonction de la stratégie d'acheminement, et la deuxième regarde le coût global d'acheminement en étudiant comment les Intérêts se propagent dans le réseau sans-fil. En particulier, pour les stratégies I&Aet MPR, une campagne de simulation est menée pour mieux représenter le coût énergétique du processus d'inondation.