• No results found

Information-Centric Networking

2.2 Future Internet Research

2.2.2 Information-Centric Networking

Information-Centric Networking (ICN) [110, 10] is an emerging clean-slate architectural paradigm for the Future Internet, which has been acquiring a significant relevance in the research community by both the academia and industry. In ICN, users are interested in what the content is instead of where it comes from [112]. As such, ICN places the content itself as the central networking element of its architecture, moving away from the host-oriented and end-to-end principles of the current Internet. This change is mainly motivated by the increasing interest in consuming information independently of its location, rather than in communicating with specific hosts.

An advantage of the ICN paradigm is that it leverages native support for scalable and efficient content dissemination. It locates and routes content based on its name, decoupling it from its location. In doing so, ICN focuses in securing the content, making it trustworthy by itself, instead of securing the path as in the current host- centric approach. The validity of content can be verified directly, and not by checking which host provided the content.

By leveraging these two properties, ICN enables in-network caching. Any entity in the network can maintain a copy of contents, acting as a cache. Requests for a given content can be satisfied not only by the original information source, but also by any entity holding a cached copy of the content in the path between the requester and original information source. Since ICN focuses on securing the content itself instead of the communication channel, it can be retrieved by untrustworthy entities and through untrustworthy connections.

ICN also leverages multicast communications for retrieving content, since by naming information at the network-layer, it allows the aggregation of requests for the same content. Finally, since communication in ICN is mostly receiver-driven, mobility appears as an intrinsic functionality. When a consumer moves to a new location, it re-issues requests that have not been satisfied yet. However, mobility of the content

1 OpenDayLight - https://www.opendaylight.org/ 2 NOX - https://github.com/noxrepo/nox 3 POX - https://github.com/noxrepo/pox 4 Floodlight - http://www.projectfloodlight.org/ 5 Ryu - https://osrg.github.io/ryu/ 6 Trema - https://trema.github.io/trema/

source is not so straight-forward, imposing a new set of challenges [101], due to the change of the location of contents.

Over the years, several instantiations of the ICN paradigm have been proposed, such as Named Data Networking (NDN) [113], Content Centric Networking (CCN) [59], Network of Information (NETINF) [32], Publish Subscribe Internet Technology (PURSUIT) [98] and Entity Title Architecture (ETArch) [33]. Although sharing the same core functionalities of this novel paradigm, each instantiation differ from the others on how such functionalities are implemented.

Despite the benefits that the ICN paradigm can bring, its deployment requires a larger investment and agreements among different stakeholders, when compared with incremental solutions over the current Internet architecture. Its success will then depend on its capability to provide clear superior solutions to well-known problems in the current IP network architecture, as well as its capability to be incrementally deployed along with the current Internet architecture.

The interest of the research community in ICN led to the creation of a Information- Centric Networking Research Group (ICNRG)7 discussion group by the Internet Research Task Force (IRTF).

In the following subsections, the operation of the NDN, PURSUIT and ETArch instantiations are detailed, due to its relevance on the work performed in this thesis.

2.2.2.1 Named Data Networking

Named Data Networking (NDN) [113] is an instantiation of the ICN paradigm that can be categorized as an Interest-based ICN solution. Interest-based ICNs propose a communication model driven by consumers, operating in a request/response communication paradigm, where information is polled using two different messages: (i) Interest messages, which are used to request desired content; and (ii) Data messages, which are used to carry the data itself.

Instead of carrying source and destination addresses as in the current IP architecture, both the Interest and Data messages contain a name used to identify the content being addressed. The names in NDN are hierarchically structured and human-readable (e.g., “/atnog.av.it.pt/content/video.mpg”), although in special cases flat names can also be accommodated in the NDN design. Also, NDN introduces the notion of a “face”, which consists on a generalization of a network interface and may represent a physical network interface, an overlay communication channel or an inter-process communication channel with the applications.

7

2.2. Future Internet Research 19 An NDN-enabled node is composed by three main modules: (i) Content Store (CS), which consists on a cache for contents; (ii) Pending Interest Table (PIT), which maintains track of yet unsatisfied Interest packets; (iii) Forwarding Information Base (FIB), which contains a set of forwarding rules for Interest packets. The basic operation of NDN is depicted in Figure 2.3.

Figure 2.3: Example of the basic operation of NDN

Consumers issue Interest messages addressing the desired content through its name (message 1 in Figure 2.3). Upon reception by an NDN router node, the node verifies if it contains a cached copy of the content in the CS. If a cached copy exists, the node itself can reply to the Interest messages with a Data message, even if it is not the producer of the content. Otherwise, if the content is not cached in the CS, the node checks if a pending request for the same content exists in the PIT. If so, the incoming face of the Interest message is added to the PIT entry and the Interest message discarded. Otherwise, if no entry exists in the PIT, the node creates the PIT entry (i.e., association between the content name and incoming face of the Interest message) and forwards the Interest message based on the information contained in the FIB (messages 2 to 4 in Figure 2.3).

The Data message follows the reverse path taken by the corresponding Interest message (messages 5 to 8 in Figure 2.3). Upon reception of the Data message, an NDN router node lookups on its PIT to obtain the faces from which it received the Interest messages for that content. If no entry is found in the PIT, the Data message is discarded. Otherwise, the Data message is sent according to the state information stored in the PIT entry (i.e., via the faces through which it received the Interest messages). The Interests messages are considered as satisfied (i.e., Data consumes Interests), and the corresponding PIT entry removed. According to the caching policies configured in the node, content objects can be cached in the CS.

In the example presented in Figure 2.3, a second consumer (i.e., consumer B) issues an Interest message addressing the same content (messages 9 and 10 in Figure 2.3).

In this case, the reply with the desired content is sent by an NDN router in the path between the consumer and the producer (messages 11 and 12 in Figure 2.3), since it has previously cached the content during the request for the same content by consumer A. 2.2.2.2 Publish Subscribe Internet Technology

Publish Subscribe Internet Technology (PURSUIT) [98], a follow-up of the Publish- Subscribe Internet Routing Paradigm (PSIRP) project [43, 42], presents an ICN architecture on which publish/subscribe primitives play a central role in its operation. Instead of establishing connections between specific nodes as in the current IP architecture, in PURSUIT information is published and interested consumers subscribe to it.

Content is named in PURSUIT by a unique pair of identifiers, namely the scope and the rendezvous identifiers. The scope may represent a physical or a logical structure, grouping related information objects, and consists on a (sequence of) fixed length scope ID(s), while the rendezvous identifier uniquely identifies the content within the respective scope, consisting of a single fixed-length rendezvous ID.

The basic operation of PURSUIT is depicted in Figure 2.4, where a consumer requests access to a given content object previously published by its producer.

Figure 2.4: Example of the basic operation of PURSUIT

Content producers (also known as publishers) advertise content availability towards the Rendezvous Node using a PUBLISH INFO message (message 1 in Figure 2.4). Consumers (also known as subscribers) interested in a given content send a SUBSCRIBE INFO message towards the Rendezvous Node (message 2 in Figure 2.4).

2.2. Future Internet Research 21 The Rendezvous Node is responsible for matching publication and subscriptions for a given content, requesting the Topology Node to calculate a forwarding identifier corresponding to a path between the publisher and the subscriber(s). The forwarding identifier consists on a LIPSIN identifier [61]. This identifier is sent to the publisher via a START PUBLISH message (message 3 in Figure 2.4) which triggers the publisher to send the content to interested subscriber(s) via PUBLISHED DATA message (messages 4 to 7 in Figure 2.4).

Additionally, the extensions proposed in [96, 97] allow the subscriber and the publisher to communicate in a request/response approach using the publish/subscribe primitives. The operation of PURSUIT using these extensions is depicted in Figure 2.5.

Figure 2.5: Example of the basic operation of PURSUIT extensions proposed in [96, 97] In this case, whenever the consumer subscribes (message 2 in Figure 2.5) its interest on a previously published content (message 1 in Figure 2.5), the Topology Manager calculates both the forwarding and reverse direction identifiers between the subscriber and the publisher. Both forwarding identifiers are then delivered to the subscriber (message 3 in Figure 2.5). The subscriber uses the reverse direction identifier to forward Chunk Requests messages encapsulated in PUBLISHED DATA messages towards the publisher (messages 4 to 7 in Figure 2.5). The forwarding direction identifier, that can be used by the publisher to reply to the request using a Chunk Response message, is included in the message encapsulated in a PUBLISHED DATA message, sent directly to the subscriber (messages 8 to 11 in Figure 2.5).

2.2.2.3 Entity Title Architecture

The Entity Title Architecture (ETArch) [33] is a clean-slate network architecture that shares the vision of the information-oriented paradigm, where users request information by attaching to the correspondent Workspace, triggering the network to dynamically configure itself to provide users with the desired content.

ETArch employs a new naming and addressing scheme based on a topology- independent designation, referred as Title. A Title is used to uniquely identify an Entity, but an Entity can still be identified by multiple Titles. An Entity has communication requirements and capabilities and it can assume multiple representations, including contents, services, applications, hosts, among others. For Entities to be able to exchange information with one another, they have to be attached to the same communication channel, called Workspace. Workspaces represent the path where data is transported to all entities attached to such communication channel and, therefore, they gather multiple communication entities, so that whenever a message is sent to a given Workspace it will be received by every entity attached to that Workspace. A key component of this architecture is the Domain Title Service (DTS), which consists on a distributed system that deals with all control aspects of the network. The DTS is composed by Domain Title Service Agents (DTSAs) responsible for maintaining information about Entities registered in the domain and the Workspaces that they are subscribed to, with the purpose of configuring the underlying network devices to implement the Workspaces, allowing data to reach every subscribed entity. As such, whenever a new Entity attaches to a given Workspace, the DTSA configures the forwarding tables of the underlying equipment with the purpose of extending the Workspace towards the new Entity. Likewise, whenever an Entity detaches from a given Workspace, the DTSA is responsible for removing the forwarding rules from the underlying equipment. For allowing the communication between the DTSA and the communication endpoints for registering and attachment procedures, the ETArch defines the Entity Title Control Protocol (ETCP).

The operation of ETArch, on which a centralized entity configures the behavior of the forwarding plane, relies on SDN concepts, which are implemented in ETArch by the OpenFlow protocol. DTSAs act as OpenFlow controllers capable of (re)configuring the forwarding tables of the underlying network (i.e., OpenFlow switches) in order to implement the Workspaces. In other words, the DTSA is responsible for configuring the path between all Entities attached to the same Workspace. The basic operation of ETArch is depicted in Figure 2.6.

A producer of new content willing to provide it to other entities starts by registering itself in the DTSA (message 1 in Figure 2.6), after which requests the creation

2.2. Future Internet Research 23

Figure 2.6: Example of the basic operation of ETArch

of an Workspace by issuing an WORKSPACE CREATE message (message 2 in Figure 2.6). The OpenFlow switch, by receiving this request, encapsulates it in an OFPT PACKET IN message to be sent to the DTSA (message 3 in Figure 2.6). The DTSA creates the corresponding Workspace, implementing it in the underlying network using OFPT FLOW MOD messages (message 4 in Figure 2.6). At this point, the producer can start publishing contents to the Workspace but, since no other entities are attached to the Workspace, messages are not propagated further than the first OpenFlow switch (message 5 in Figure 2.6). In turn, a consumer desiring to access the contents published by the producer starts by registering itself in the DTSA (message 6 in Figure 2.6), after which requests the attachment to an Workspace by issuing an WORKSPACE ATTACH message (message 7 in Figure 2.6). As for the creation of the Workspace, this message is encapsulated in an OFPT PACKET IN message by the OpenFlow switch and sent to the DTSA (message 8 in Figure 2.6). The DTSA computes and installs in underlying OpenFlow switches the forwarding rules required to extend the Workspace towards the consumer (message 9 in Figure 2.6). After configuring the extension of the Workspace, new messages published by the producer are forwarded towards the consumers (message 10 in Figure 2.6).

2.2.2.4 Brief comparison of IP and selected ICN architectures

The main differences between IP, NDN, PURSUIT and ETArch architectures, which have the potential to hinder their interoperation, are presented in Table 2.1.

While the IP network architecture is host-oriented and thus network layer addresses represent the endpoint holding the resources to be accessed, NDN, PURSUIT and ETArch are based on a data-oriented paradigm, enabling addresses to represent

Table 2.1: Comparison between IP, NDN, PURSUIT and ETArch architectures

Design Orienta-

tion

Communication

Paradigm Network Addresses Network Protocol

IP orientedHost- Push (i) Fixed length

(ii) Hierarchical identifier Single IP message

NDN orientedData- (Request/Response)Pull

(i) Variable length (ii) Hierarchical identi- fier

(iii) (Optional)

Human-readable identifier

Interest and Data messages

PURSUIT orientedData- (Publish/Subscribe)Pull

(i) Variable length: composed by a (se- quence of) scope(s)

ID(s) and a single

rendezvous IDs (ii) Flat identifier

(Un)Subscribe and Publish messages

ETArch orientedData- (Publish/Subscribe)Pull (i) Fixed length(ii) Flat identifier

Entity (un)registration and Workspace

create/delete, attach/detach and

publish messages

anything (e.g., a data chunk, a content or even an endpoint). The IP addresses are hierarchical and encoded as a sequence of 4 bytes for IPv4 or 16 bytes for IPv6. Although NDN addresses are also hierarchical, they can have variable lengths. In turn, PURSUIT addresses are flat and composed by two parts: the scope and the rendezvous. The scope part, consisting of a (sequence of) fixed length scope ID(s), is followed by the rendezvous part, consisting of a single fixed-length rendezvous ID. Finally, ETArch addresses have fixed length and consists in flat identifiers.

In terms of operation, the IP protocol is composed by a single message that can be sent and routed in the network independently of any other message previously sent. The NDN protocol, operating on a request/response paradigm, is composed by two types of messages which are intrinsically related (i.e., Data messages are forwarded through the reverse path taken by Interest message). The PURSUIT protocol, which operates based on a publish/subscribe paradigm, has specific messages for handling the (un)subscriptions and publication of data, forwarded based on in-packet bloom filters. ETArch, that also operates based on a publish/subscribe paradigm, defines messages for entity (un)registration as well as for enabling entities to create or attach to workspaces (i.e., subscription) in order to become capable of receiving any message sent towards a given workspace (i.e., publish).