Native Push and Pull Communication API

In the previous section we argued that on-demand content delivery (pull) and publish/subscribe event notification communication (push) primitives are differ- ent. In fact, even if it would be possible to implement publish/subscribe event notification over a pull architecture, that may be problematic in practice. How- ever, here we argue that the two communication modes are not that different, and more specifically that they have some fundamental common elements. In this thesis we exploit this commonality to implement a forwarding table that is able to support both on-demand content delivery traffic and publish/subscribe event notifications.

First of all we need to analyze in detail all the steps of the communication process in both push and pull flows. In Figure 2.3 we represent the packets exchanged between the producer and the consumer in a pull communication flow. As a first action, the producer sends a register packet to the network,

23 2.1 Communication Primitives: Push vs Pull producer consumer register(prefix) forwarding tables hinterest:namei hdata:contenti

Figure 2.3. On-demand content delivery (pull) packets exchange

specifying the prefix or the name of what the producer wants to publish. With this action, the producer communicates to the network that it can produce the content related to the prefix specified in the register packet. This information is disseminated and processed through some routing protocol, so that each router would use that information to update is own forwarding table. At this point a consumer can request some content with an interest packet with a specific name. The network forwards the interest packet toward the producer using the information stored in the forwarding table of each router in the network. When the interest reaches the producer, or a router with the required content in its cache, a data packet is sent back to the consumer.

producer consumer subscription (content-descriptor ) forwarding tables hnotification: content-descriptor + datai

Figure 2.4. Publish/subscribe event notification (push) packets exchange

Figure 2.4 describes the phases of push communication. This time, the con- sumer performs the first action, communicating to the network that it wants to receive some kind of information. Thus the consumer sends a subscription packet, describing the content that the consumer intends to receive. Like the register message in pull mode, a subscription is disseminated and processed in

24 2.1 Communication Primitives: Push vs Pull

the network through a routing protocol, possibly resulting in routers updating their forwarding tables. When a producer has an event to notify, the producer simply sends a notification packet. The notification is forwarded as a multicast packet using the information on the forwarding tables of each router so as to reach all interested consumers.

In both push and pull communication there are essentially three phases, sum- marized in Table 2.1:

1. A node generates routing information that feeds into the forwarding ta- bles.

2. Routers forward packets according to their forwarding tables.

3. The forwarding process delivers information to the right users.

In the pull communication model, it is the producer that generates the rout- ing information, whereas in push communication it is the consumers. However, in both cases the register/subscription packets are disseminated and processed by each router, according to some routing protocol, to create or update state in the router’s forwarding table. This suggests that register and subscription pack- ets are semantically identical. And indeed their semantics can be shown to be identical, which is why in our architecture we use a single packet that can serve both as a subscription for a consumer (in push) or as a register packet for a producer (in pull).

Pull Push

(1) Routing Information Generated by producer Generated by consumer

Used to update FIB Used to update FIB

(2) Matching FIB FIB

(3) Information Delivery Anycast Multicast

Requires Reply One-Way

Table 2.1. Three phases in the communication process: pull vs push

In the matching phase, in both cases, the routers match packets, notifications or interests, against the same forwarding table, and they forward these packets using the same rules. For this reason we use a single forwarding table. The only difference in forwarding between push and pull is the fan out of notifications and interests, respectively, which plays a crucial role in the third phase.

25 2.1 Communication Primitives: Push vs Pull

In the third and last phase, the two communication flows differ significantly. As described in Table 2.1, in the case of pull communication, interests are any- cast packets, meaning that it is important that an interest reaches at least one producer (and preferably only one of them). Conversely, a notification is a mul- ticast packet that must reach all interested consumers. This difference is es- sential and it is the reason why our forwarding table supports different fan-out levels. We will discuss this feature later, but briefly this means that a header in the packet, which differs in interests and notifications, tells the router to limit the forwarding to one or more, or possibly an unlimited number of final desti- nations.

The other main difference in the third phase is that notification packets (push mode) are one-way messages, while interests (pull communication) require a reply packet that must return data back to the consumer.

In summary, we consider notifications and interests as semantically different packets, and in our architecture we consistently use two different packets.

Node A Node B register(descriptors) forwarding tables hnotification: content-descriptor +datai hrequest: content-descriptori hreply:datai

Figure 2.5. Unified content-based network layer

Figure 2.5 illustrates the architecture we propose. We use only one packet, called register, to define and transmit routing state. This distributes the state in the network and creates or updates forwarding tables. We then use the forward- ing tables to route both request and notification packets. Requests are equivalent to an interest in CCN terms. However, we prefer the term request to avoid confusion between immediate interests (requests) and long-term interests (sub- scriptions). The forwarding algorithm is the same for interests and notifications, the only difference is in the fan-out of the two packets. Then, for each request, the network answers to the user with a reply packet that carries the required