Name Prex Trie (NPT) based

The Name Prex Trie (NPT) is a data-structure inspired by the binary trie for IP prex lookup, which capitalizes the hierarchical structure of names and the component-level granularity of the longest prex matching in NDN. The design of a PIT based on an NPT data-structure was rst proposed in [86] as further renement of an encoding technique for Name Prex Trie previously proposed in [87].

The main idea of NPT is to represent NDN names through trees like the one in Fig. 2.2a. Ev- ery edge represents a component and every node represents a lookup state. The reader could be wondering about the rationale to use a data-structure giving visibility of the full name structure when only an exact match is required to lookup the PIT. Indeed, NPTs have been proposed as solution to implement a single index for the three main functional blocks of the NDN data-plane, i.e., CS, PIT and FIB. In fact, Fig. 2.2a shows that a non-empty lookup state may correspond to either a FIB entry or a CS one or a PIT one. The advantage is a reduction of the memory space to store a single index rather than three. The downside is the additional complexity of the data-structure required to support dierent kinds of read/write operations.

An NPT can be represented with a name character trie (NCT) [88]. Nevertheless, character tries require a lot of memory to store states and transitions. Besides, they have an O(mn) computation for the LPM lookup in average (where m and n are the average number respectively of children per node and name length). Compression techniques can be applied at the name-component level to reduce the space needed to store the prex trie. Encoding rather than hashing techniques are preferred for compression by existing literature since the latter ones aect the correctness of routing because of collisions. Thus, for example, the prex trie in Fig. 2.2a could be encoded in a new trie showed in Fig. 2.2b, called Encoded Name Prex Trie (ENPT), where codes are assigned to name components. The representation with codes is already more compact than the one storing the characters. However, it can be further improved as detailed in [86, 87] where a Name Component Encoding (NCE) is proposed. Improvements of an NCE relate to the code allocation mechanism which aims to reduce the total number of codes, to the trie representation which is implemented by means of State Transition Arrays (STAs), to the algorithm to perform components' code lookup and to the management of the STAs for the insertion/removal/update operations.

In terms of complexity analysis, the NCE reduces the memory space to store an NPT and speeds up the lookup in the average case compared to the NCT. Experiments reported by [87] compare the two data-structures on three data sets built using domain information from the D-MOZ, ALEXA and Blacklist public websites. For the biggest data set composed of around 3 million

2.2. Data structure 0 1 2 4 3 7 5 6 8 nd n.n_et Ccn.o rg docs Spec. pdf Lib.h_tml Tutorial.mpg docs ccnx1.0 .doc FIB entry PIT entry CS entry

(a) Name Prex Trie

0 1 2 4 3 7 5 6 8 <n_dn .ne_t,2 > <ccn x.org, 1> <docs,1> <Spec .pdf,1> <Lib_.htm l,3> <Tutorial.mpg,2> <docs, 1> <cc nx1.0.doc,1 >

Component 1 Component 2 Component 3

(b) Encoded Name Prex Trie

Figure 2.2  Examples of the Name Prex Trie (NPT) in Fig. 2.2a and of the Encoded Name Prex Trie (ENPT) in Fig. 2.2b.

names, the average name length in bits is reduced by 75% after encoding the names with NCE. The complete NCE representation through STAs saves around 20% over the NCT one. NCE memory requirements also grow more slowly compared to the NCT one. Thus, NCE turns to be more memory ecient on both small and large data-sets. In a followup work [86], a mapping method to infer size and access frequency required by a PIT on a 20Gbps link is proposed. The trace translation suggests some requirements in terms of number of entries and lookup/inser- tion/deletion frequencies which are all met by the NCE.

Despite the high compression rate and the lookup performance, the NPT has not been leveraged in any complete design of an NDN router yet. In fact, related work features either Bloom Filter based or Hash-based PIT designs whose characteristics are illustrated in the rest of this section.

0 00 00000000000000000000000000000000000000 Interest name insertion

I₁ = ndn.net/videos/talk1.mpg h₁(I₁)

 BF of size m, initially all 0s

0 10 00010000000101000100000100001000010010 After inserting I₁in the BF

h₂(I₁) h₃(I₁)

Interest name check I₂ = ndn.net/pictures/demo.png   Negative check,  item not in the set h₃(I₂) h₂(I₂) h₁(I₂) 0 10 000100000001010001000001000010000100101 1 1 1 1 _{1 1 1 1}

Figure 2.3  An example of bloom lter used to record pending Interests. The lter is initially all set to 0. At every Interest reception, the Interest name is hashed k times, with each hash producing several bit locations in the lter which are set to 1. To check if an Interest/Data is in the lter, its name is hashed k times and the corresponding bits in the lter are checked. If at least one corresponding bit in the lter is not set, then the lter does not hold this Interest/Data.