XBF: Scaling up Bloom-filter-based Source Routing

Abstract

A well known drawback of IP-multicast is that it requires per-group state to be stored in the routers. Bloom-filter based source-routed multicast remedies this problem by moving the state from the routers to the packets. However, a fixed sized Bloom-filter can only store a limited number of items before the false positive ratio grows too high implying scalability issues. Several proposals have tried to address these scalability issues in Bloom-filter forwarding. These proposals, however, unnecessarily increase the forwarding complexity.In this paper, we present Extensible-Bloom-filter (XBF), a new framing and forwarding solution which effectively circumvents the aforementioned drawbacks. XBF partitions a network into sub-networks that reflect the network topology and traffic patterns, and uses a separate fixed-length Bloomfilter in each of these. We formulate this partition assignment problem into a balanced edge partitioning problem, and evaluate it with simulations on realistic topologies. Our results show that XBF scales to very large networks with minimal overhead and completely eliminate the false-positives that have plagued the traditional Bloom-filter-based forwarding protocols. It furthermore integrates with SDN environments, making it highly suitable for deployments in off-the-shelf SDN-based networks.

Reliable data delivery in ICN-IoT environments

“…As an alternative to namebased flooding, location-based solutions that exploit the geographic coordinates of nodes are also investigated, primarily in the context of vehicular networks [26] and recently in IoT systems [27]. To improve the scalability of forwarding tables, solutions based on bloom filters are proposed in [28,29,30]. There exists also a class of routing protocols for ICN-IoT environments specifically designed for push-based traffic, such as that produced in case of alarms or status changes.…”

“…If p receives a second Interest packet for the same content i of which the corresponding Data message is still missing, it adds the incoming "face" to the corresponding PIT entry (line 6). If the number of received Interests for the same content exceeds a certain retransmission threshold (i.e., ReTX threshold at line 7), p retransmits the first received Interest towards the node with the highest utility for that content (line [23][24][25][26][27][28][29][30][31][32][33][34]. It is important to observe that if the selected forwarder is not currently in proximity of node p (i.e., the forwarder is not a neighbour of node p), the retransmission is delayed till the next contact.…”

“…As before, if multiple Interest packets for the same content arrive at one node, the node forwards only the first Interest to the node with the highest utility it knows (line 11-21), storing all the other "faces" in the corresponding PIT entry (line 6). However, if a retransmission event is triggered (line 7), the node retransmits the first Interest packet it has received to the second best forwarder, i.e., to the node with the second highest utility it knows (line [23][24][25][26][27][28][29][30][31][32][33][34]. In this way, a second path is explored, hopefully increasing the probability of finding the content.…”

“…Specifically, compared to MobCCN basic, MobCCN R1 and MobCCN R2 increase the delivery rate by a few percentage points only. On the contrary, the delivery gain obtained with MobCCN A and MobCCN AH is higher, in the order of [12][13][14][15][16][17][18][19][20][21][22][23][24][25][26][27][28][29][30] percentage points. Further observations can be then derived for each retransmission scheme.…”