In this paper, we consider NDN  as one of the most prominent Information-Centric Networking (ICN) architectures. In NDN, FIB population is the prerequisite phase for routing Interest messages. At network setup, i.e., at the begining of network operation, the FIBs are empty. The adopted routing protocol is responsible for FIB population. One method of FIB population is to use content advertisements. Such a technique is BFR , which is a routing protocol for NDN that uses BF-based content advertisements for FIB population. In BFR, servers compactly represent the provided file names using Bloom Filters (BFs) and push them to the network using Content Advertisement (CA) messages. Clients and routers store the content advertisement BFs to populate the FIBs so that they can route the Interest messages they receive. However, by increasing the size of content universe (the number of available content objects in the network), there is a linear growth in the communication overhead required for propagating all the CA messages, and the memory space that clients and routers need to store all the CA messages.
To overcome BFR shortcomings, in this paper, we propose a new routing protocol called pull-based Bloom Filter-based Routing. In pull-based BFR, servers only advertise the demanded file names. Thus, pull-based BFR needs significantly less bandwidth for content advertisements than push-based BFR (original BFR). Further, in pull-based BFR, clients and routers do not need to store the content advertisements for the entire content universe in contrast to push-based BFR. Therefore, clients and routers need significantly less memory resources to store content advertisements using pull-based BFR than push-based BFR. Pull-based BFR is a fully-distributed, content oriented, and topology oblivious protocol, like push-based BFR.
We compare the performance of pull-based and push-based BFR protocols. The comparison shows that pull-based BFR outperforms push-based BFR in terms of content advertisement overhead, average round-trip delay, memory resources needed for storing content advertisements at clients and routers, and the impact of false positive reports of BFs on routing. For the sake of completeness, we also compare the performance of the proposed pull-based BFR with a Flooding-assisted Routing (FaR) protocol. The results make clear that pull-based BFR outperforms FaR in terms of average round-trip delay.
Ii Push-based Bloom Filter-based Routing
Bloom Filters (BFs) are used to compactly represent sets and find applications in IP networking, e.g., finding Longest Prefix Match, probabilistic routing algorithms, summary cache exchange, and matching IP addresses . BFs have been used in NDN for similar purposes with IP systems [1, 5, 6, 7, 8]
. A BF is a bit vector initialized to zero. The bit values of a BF are set with the help of a number of hash functions. In particular, to insert an element into a BF, one has to give the element as an input to the hash functions. The output values of the hash functions specify the indices of the bits to be set in the bit vector. To check whether a BF contains an element, all the bits specified by the hashes of the element have to be set. When BFs are used, it is impossible to have a false negative report, i.e., to falsely report that the BF does not contain an element, but a false positive report may happen, i.e., to falsely report that the BF contains an element, with the probability. If is the inserted element count of the BF, is the bit vector’s size, and is the number of hash functions, the trade-offs between , , , and are given as in :
There are two advantages of using a BF for representing a set than using a regular array: 1) compressed representation of the set, and 2) less complex element search. The complexity of searching an element in a BF is , whereas the complexity of searching an element in a regular array is with .
Push-based BFR  operates in two phases: 1) representation and advertisement of content objects using BFs, 2) FIB population and content retrieval. Let us describe the first phase using Fig. 1. In this figure, when server produces some files, it then inserts the produced file names as well as their available name prefixes into a BF. To advertise these file names, server needs to broadcast a message that encapsulates the resulting BF. For this purpose, push-based BFR uses a new Interest message type called CA message, which has the name prefix . CA messages contain the required information to retrieve BFs, a nonce value, and a lifetime. Note that servers do not broadcast CA messages to demand any content objects, but they only broadcast these messages to inform other nodes about the content objects they possess. Similar to Interest messages, NDN Forwarding Daemon (NFD) is used for loop detection as well as for duplicate detection and discard of CA messages. When a router or a client receives a CA message, it stores this message in the PIT and updates the ID of the face over which the CA message has been received in the in-record field of the PIT entry. For example in Fig. 1, router receives the CA message of server over faces and . The corresponding structure of the PIT entry is presented in Fig. (a)a, where the in-record for name is stored at router . The information stored in the in-record field is useful for FIB population later. To describe FIB population and routing processes, in Fig. 1 we assume that client receives and stores the CA message of server at time instant . Further, we assume that client issues Interest to demand a segment of file name , after time instant . To populate the FIB for name and to route Interest , client retrieves the BF of the CA message of server from the BF information stored in the CA message and checks name against the BF. If name exists in the BF of server ’s CA message, client checks the in-record information to know the face(s) over which server ’s CA message has been received. In Fig. 1, for client , there is only one face, thus it forwards Interest towards router , but as Fig. (a)a shows, router has received server ’s CA message over two faces, i.e., faces and . Thus, this router considers both faces and as the next hop faces for name prefix and populates the FIB for this name prefix as Fig. (b)b shows. Push-based BFR uses the multicast forwarding strategy, because it is a multi-path routing protocol.
Note that core routers’ processors have several cores. Thus, a core router can chack names against multiple BFs in parallel, thus this does not create any performance issues.
Iii Pull-based Bloom Filter-based Routing
The rationale behind designing a pull-based BFR method is to advertise only the demanded content objects. When servers only advertise the demanded content objects, it is expected that: 1) significant amount of bandwidth will be saved, and 2) other network nodes (clients and routers) will need significantly less memory space to store content advertisement information. The adoptation of this content advertisement strategy can resolve scalability issues of push-based BFR, as in push-based BFR servers advertise all the file names of the content universe. The main difficulty arising from advertising only the demanded content objects is that servers do not know a priori which content objects will be demanded. To overcome this problem, in pull-based BFR, we follow a BF-based strategy to inform the servers about the demanded file names, which we will explain in the next sub-section.
Iii-a Pull-based BFR’s Operation
Content advertisement in pull-based BFR is performed in two consecutive phases: 1) clients and routers use a BF-based strategy to inform the servers about the demanded file names, and 2) servers proceed with the advertisement of these names using CA messages. Upon reception of CA messages, clients and routers store the content advertisement information and populate the FIBs for pending Interests to route them. To summarize, pull-based BFR’s operation is done in three stages: 1) pulling content advertisements, 2) content advertisement, and 3) FIB population and content retrieval.
Let us explain our BF-based method of informing servers about the demanded file names with the help of Fig. 3. In Fig. 3, we assume that client issues Interest to retrieve a segment of file name under the following conditions: 1) there is no FIB entry for or a name prefix of it, and 2) there is no stored content advertisement BF that contains or a name prefix of it. Thus, client avoids forwarding Interest and keeps it as pending. Nevertheless, client informs the servers that file name is demanded to pull the content advertisement information for it. For this purpose, client creates a BF, which contains file name as well as all its name prefixes and creates a Content Advertisement Request (CAR) message of type Interest called with name that encapsulates the BF. Then, client broadcasts to inform the servers about the demanded file names and to pull the needed content advertisements. When a router receives a CAR message, it waits for an aggregation threshold time to receive other CAR messages issued by other clients. Assume that client issues Interest to demand a segment of file name for which no FIB entry and no content advertisement information is available. Thus, client broadcasts a CAR message called with name carrying a BF that contains file name as well as all its name prefixes. If router receives the CAR messages of clients and , within a time interval , it forwards and over faces and , respectively. At the same time, router forwards the aggregation of and over face . To aggregate and , router makes a union of their BFs and puts the resulting BF into a new CAR message with name . Then router forwards this message over face . Therefore, as a rule of thumb, a router forwards over face the union of BF(s) that have been received over other faces and have not been sent over face before. When router forwards message over face , router updates the out-records of both messages and by adding face to record that both these messages have been forwarded over face . Further, router will not use message in future aggregations, because the third name component specifies that this message is created by router itself and has not been received from other nodes. Routers , , and follow the same forwarding process for CAR messages. Nodes make use of a sequence number counter for calculating the sequence numbers of CAR messages.
To permit BF union operations, we assume that all nodes create the BFs of the CAR messages with the same size, and that they generate the hash functions using a universal seed, i.e., all nodes use the same set of hash functions for BFs. In (1), if we assign a constant value to and we specify the value of , we will derive the maximum optimal value for
, which estimates the maximum number of requested file names that can be inserted into the BF. It is not a problem that all nodes use a universal seed to generate the hash functions for the BFs of all CAR messages, as all nodes can use a well-known word, e.g.,NDN as the universal seed to generate hash functions.
When servers and receive a CAR message, they check all the produced file names against the BF of the received CAR message111We assume that servers have multi-core processors and can check multiple names against multiple BFs in parallel. Thus, this does not create a performance issue.. The file names that exist in the BF of the CAR message are the demanded file names that should be advertised. Thus, both servers and first create a list of these file names called toBeAdvertisedList and then a BF called toBeAdvertisedBF with size equal to that of the received CAR message’s BF. When a server notes that a produced file name exists in the BF of the CAR message, it inserts the file name into the BF toBeAdvertisedBF. Then, the server creates a CA message, from type Interest with name prefix carrying the toBeAdvertisedBF. The server broadcasts the CA message to the network to advertise the demanded content object and not to demand any content objects. In our example, if router receives the CA messages of servers and , namely, and , which have the names and , respectively, within a time interval , Router forwards and over faces and , respectively. Router aggregates and unioning their BFs and places the resulting BF into an aggregated message, which has the name and forwards this message over face .
When clients and receive the CA message, they can populate their FIBs for name prefixes and , which allows them to route Interests and . When routers receive Interests and from the clients, they also populate the FIBs using the stored CA messages and continue routing the Interests until the demanded content objects are retrieved.
Iii-B Bloom Filter Aggregation
If a router makes a union of the BFs and , which are not subset or equal to each other, i.e., , the number of s in the bit vector of the resulting BF will be greater than the number of s in each of and . Thus, if routers do not stop unioning BFs that are not subset or equal to each other, at some point all the bits of the bit vector of the resulting BF will be set to . Such a BF does not function properly because it falsely claims that it contains all the existing names. Therefore, routers should stop unioning the BFs of both CAR and CA messages according to the maximum capacity of BFs. As we explained before, we consider a constant size as well as a probability of false positive error for the BFs of CAR messages. Then, using (1), we calculate , which is the maximum capacity of the BF. Assume that router wants to aggregate and , which have inserted element counts and , respectively. First, router checks if and are identical. For this purpose, router makes an of the bit vectors of and . If all the bits of the resulting bit vector are zero, and are identical. In such a case, there is no need to make a union of them. The second check is to examine whether the following proposition is true . For this purpose, router calculates . If the resulting bit vector is identical with the bit vector of , it means that . In this case, again router does not need to calculate the union of and . If , then router makes a union of and . In this case, if and , theoretically we have . However, practically it is not possible to calculate , precisely. Therefore, router sets , which is a conservative upper bound. If , router will aggregate and . Otherwise, router avoids aggregating these BFs.
Iii-C The Impact of False Positive Errors on Pull-based BFR’s Operation
The impact of false positive errors on the operation of pull-based BFR should be considered in two cases: 1) if servers check the produced file names against the CAR messages BFs, 2) if clients or routers check the pending Interest names against the CA messages BFs. Consider in Fig. 3 that server receives a CAR message carrying a BF, which contains names and . If server checks the file name against the received BF and the BF gives a false positive report, server will insert name into the BF of the CA message and advertises this message. Therefore, the CA message advertises the file name , which has not been demanded. This is not a problem because it is guaranteed that no false negative errors happen using BFs, and, therefore, servers advertise the produced file names that are demanded anyways. Let us again examine Fig. 3 to discuss the impact of false positive reports from the BFs of CA messages, when clients or routers check the Interest names against these BFs for FIB population and routing purposes. In Fig. 3, we assume that router checks the name for Interest against the BF of CA message issued by server . If the BF gives a false positive report, router will forward the Interest over face . Consequently, Interest will be routed towards a wrong server, i.e., server . When server receives Interest , it sends back a “No Data” Nack message  to inform router that server does not store the Data that Interest requests. When router receives the Nack message, it will remove from the FIB the incorrect next hop information corresponding to name . Further, if Interest is not satisfied yet, router will send a CAR message containing to receive the correct routing information.
Iv Performance Evaluation
In this section, we compare the peformance of pull-based BFR, push-based BFR, and flooding-assisted routing protocols implemented in ndnSIM.
Iv-a Flooding-assisted Routing
Flooding-assisted Routing (FaR) is a protocol that does not use content advertisements for routing. Thus, clients and routers are not aware of the content objects that each server provides as well as the route to reach them. Hence, at the first phase of routing, clients and routers flood the Interests. Rightafter, when clients and routers receive Data packets, they populate the FIBs for the name prefix of the Data packet. Let us explain flooding-assisted routing with the help of Fig. 1. In Fig. 1, we assume that client issues an Interest to demand a content object with name provided by server . However, client does not have any information about the provider of content object . Thus, client floods Interest and waits for the Data packet with name . Since server provides the Data packet with name , Router only receives this Data packet over face . Therefore, router populates the FIB for name and considers face as the only next hop face for name in the FIB.
Iv-B Simulation Settings
To compare the performance of the protocols under comparison, we use the GEANT topology [12, 1]. The topology is built by randomly placing servers and clients in the GEANT topology, which connects routers. Thus, the resulting topology consists nodes. We assume that the content popularity follows Zipf-Mandelbrot distribution. Equation (2
) shows the probability distribution function for Zipf-Mandelbrot distribution, whereis the cardinality of the content universe and is the Zipf’s power parameter. We consider the values of in the interval. We use a URL dataset extracted from real HTTP request traces . We assume that the content universe has file names, and that each is divided into segments. Therefore, there are unique segments. For the BFs of CAR and CA messages, we set Bytes and . Recall, that is the BF’s bit vector size and represents the false positive probability. Hence, using (1), the maximum value of will be .
We consider three metrics for assessing the performance of all protocols: 1) content advertisement overhead, 2) average round-trip delay, and 3) storage space requirements for storing routing information. We also compare pull-based and push-based BFR in terms of the impact of false positive reports of BFs on routing.
Iv-C1 Content Advertisement Overhead
For pull-based BFR, Fig. (a)a shows the content advertisement overhead, i.e., the total communication overhead required for forwarding CAR and CA messages in terms of forwarding rate of routing messages, which is defined as . Higher forwarding rate of routing messages results in more frequent forwarding of CAR and CA messages, i.e., less aggregation of CAR and CA messages. We set the values in the interval measured in milliseconds. This results in forwarding rate of routing messages in the interval in terms of kilohertz. From Fig. (a)a, we observe that for pull-based BFR, the content advertisement overhead increases by increasing the forwarding rate of routing messages, for all values.
For push-based BFR, the total communication overhead needed for content advertisements depends on the content universe size, because servers advertise all the file names they produce. However, in pull-based BFR, servers do not advertise the file names that are not demanded. The number of popular files is controlled by the value of (higher means less content objects are requested). We observe from Fig. (a)a that for pull-based BFR, the communication overhead needed for content advertisements significantly decreases with higher values. This is due to the fact that when the value of increases, less content objects are popular and thus are demanded. Therefore, clients propagate smaller number of CAR messages, because they require less CA information. For push-based BFR, Fig. (b)b shows the required communication overhead for propagating content advertisements in terms of content advertisement refresh rate (), i.e., the frequency that servers refresh CA messages. From Fig. (b)b, we observe that for push-based BFR, the communication overhead required for propagating content advertisements increases by increasing . When we compare Figs. (a)a and (b)b, we observe that pull-based BFR requires significantly less communication overhead for propagating content advertisements compared to push-based BFR. For example, in Fig. (b)b, push-based BFR requires the least communication overhead for propagating content advertisements if , however, even in this case, push-based BFR requires significantly more communication overhead for propagating content advertisements compared to pull-based BFR except when and is in the interval. Note that when pull-based BFR is used and , nodes perform very little aggregation, which is not of our interest. Therefore, in the rest of results, for pull-based BFR, we use and for push-based BFR, we use . For push-based BFR, we use as the lifetime of CA messages. For pull-based BFR, we set the lifetime of CAR and CA messages to and , respectively.
Iv-C2 Average Round-trip Delay
From Figs. (c)c and (a)a, we present the results in terms of average round-trip delay, i.e., the average delay that a client experiences from the time it issues an Interest to the time it retrieves the demanded Data packet. We measure this delay for all the studied protocols in two scenarios: 1) when links have full capacity, and 2) when links have only of the original capacity. When users can make use of the full network capacity, Fig. (c)c shows that if is in the interval, push-based BFR performs slightly better than pull-based BFR, because the cardinality of the set of popular content objects is bigger for smaller values of . Thus, pulling content advertisement and CAR aggregation at routers have more impact on the average round-trip delay for pull-based BFR. Nevertheless, when is in the interval, pull-based BFR and push-based BFR perform very close to each other, because much less content objects are popular. Thus, clients need to pull much less CA information and each demanded content object will be cached close to the client that demanded it after its first retrieval. Therefore, in this case, the delay caused by pulling content advertisements and aggregating CARs and CAs has less impact on the overall average round-trip delay. When the links of the GEANT topology  have of their capacities and is in the interval, FaR performs close to pull-based BFR. However, when is in the interval, pull-based BFR outperforms FaR. We observe from Fig. (a)a that by reducing link capacity, push-based BFR and FaR protocols are more affected, while we observe the smallest impact of limited link capacity on the performance of pull-based BFR. The reason is that pull-based BFR aggregates CAR and CA messages and, therefore, it has much less number of transmissions than push-based BFR and FaR.
Iv-C3 Storage Space Requirements for Storing Routing Information
Routing information for push-based BFR consists of CA messages, while for pull-based BFR, routing information includes both CA and CAR messages. Fig. (b)b compares pull-based and push-based BFR in terms of average storage space a node requires to store routing information per second. For push-based BFR, we observe from Fig. (b)b that the storage space requirements for storing routing information significantly increases with the size of Content Universe (CU). As explained before, the reason is that using push-based BFR, clients and routers require to store the routing information for the entire CU. However, using pull-based BFR, the nodes only store the routing information for the demanded file names. Therefore, from Fig. (b)b we observe that the storage space requirements for pull-based BFR slightly grows when we increase CU size from to . Fig. (b)b also shows that the storage space requirements for pull-based BFR is controlled by the value of , meaning that for higher values, pull-based BFR has less storage space requirements, while the storage space requirements for push-based BFR only depends on the CU size. Fig. (b)b shows that for both and , pull-based BFR requires significantly less storage space for storing routing information compared to push-based BFR. Nevertheless, we observe from Fig. (b)b that when the CU size grows from to , pull-based BFR outperforms push-based BFR more significantly. Fig. (c)c compares pull-based and push-based BFR in terms of the average storage space that a node needs to store routing information for one file name per second. We observe from Fig. (c)c that pull-based BFR outperforms push-based BFR for both and . If the CU size grows from to , Fig. (c)c shows that pull-based BFR outperforms push-based BFR more significantly.
Iv-C4 Impact of False Positive Reports on Routing
We analyze the impact of false positive reports on the performance of pull-based and push-based BFR. Fig. 6 compares these protocols in terms of the impact of false positive reports on routing. Using (1), we conducted experiments with and three different rates for from set to observe the impact of false positive reports on the operation of our considered routing protocols. Fig. 6 shows the percentage of Interest messages that have reached wrong servers due to false positive reports from the BFs of CA messages at routers and clients. From Fig. 6, we understand that the higher the value of is, the higher the percentage of incorrect routings is, for both pull-based and push-based BFR. The reason is that when we increase the value of for BFs, the probability that a false positive error occurs in practice is higher. Fig. 6 shows that the highest percentage of incorrect routing corresponds to . However, even in this case, only of Interest messages have been routed towards wrong server(s). In practice, one will not use because it results in high risk of false positive reports. Fig. 6 makes clear that false positive reports have less impact on the operation of pull-based BFR compared to push-based BFR. This is because push-based BFR stores CA messages for the entire content universe. Hence, push-based BFR stores more CA messages compared to pull-based BFR, thus more number of BFs have to be checked. Further, from Fig. 6, we observe that with higher values, false positive reports have a smaller impact on the performance of both pull-based and push-based BFR. This is due to the fact that if the value of is higher, smaller number of names are popular and, therefore, smaller number of names are checked against BFs, which results in less number of false positive reports.
V Related Works
In the recent years, many routing protocols have been proposed for NDN [14, 15, 1, 16, 17, 18]. Wang et al. propose OSPFN , which is an extension to Open Shortest Path First (OSPF), as a routing protocol for NDN. OSPFN makes use of OSPF’s Opaque LSAs  for advertising name prefixes in the routing messages. OSPFN considers the best next hop for each name prefix. However, it allows to consider alternative next hops as well. OSPFN has the following shortcomings: 1) it requires IP addresses to identify routers, 2) it requires to use “GRE” tunnels, and 3) it is a single-path routing protocol. In , Mahmudul Hoque et al. propose NLSR as a link state routing protocol for NDN, which uses LSA messages to exchange information about the available name prefixes as well as the topology of the network. NLSR proposes a hierarchical trust model to verify the LSA messages in a single domain. Lehman et al. provide a description of NLSR features and its current design in . Push-based BFR  is an intra-domain routing protocol for NDN, which operates based on BF-based content advertisements. COBRA  is a routing protocol, which has two operation phases namely learning phase and BF-based routing. In the learning phase, COBRA floods all the Interests. Rightafter, when Data packets are received, COBRA updates the route traces in Stable Bloom Filters (SBFs). If route traces for an Interest’s name prefix is stored in SBFs, COBRA avoids flooding the Interest and routes the Interest according to the route trace information. The work in  provides a comparative performance analysis of BFR and COBRA, where the advantages of BFR become more clear.
In this paper, we proposed pull-based BFR as a new routing protocol for NDN. Pull-based BFR has a number of advantages compared to push-based BFR: 1) significantly less communication overhead for propagating content advertisements, 2) BF-based aggregation mechanism for CAR and CA messages, 3) better average round-trip delay when is in the interval, 4) less storage space requirements for clients and routers to store content advertisements, and 5) more robustness to false positive reports from BFs. Similarly to push-based BFR, pull-based BFR is fully distributed, topology agnostic, content oriented, and does not need any IP-based routing protocol as a fall-back or primary routing mechanism. For future work, we aim to further study scalability issues of pull-based and push-based BFR.
-  A. Marandi, T. Braun, K. Salamatian, and N. Thomos, “BFR: A Bloom Filter-based Routing Approach for Information-Centric Networks,” in Proc. of the 16th International IFIP Networking Conference, Jun. 2017, pp. 1–9.
-  L. Zhang, A. Afanasyev, J. Burke, V. Jacobson, kc claffy, P. Crowley, C. Papadopoulos, L. Wang, and B. Zhang, “Named Data Networking,” Computer Communication Review, vol. 44, no. 3, pp. 66–73, Jul. 2014.
-  B. Ahlgren, C. Dannewitz, C. Imbrenda, D. Kutscher, and B. Ohlman, “A Survey of Information-Centric Networking,” IEEE Communications Magazine, vol. 50, no. 7, pp. 26–36, Jul. 2012.
-  A. Z. Broder and M. Mitzenmacher, “Network Applications of Bloom Filters: A Survey,” Internet Mathematics, vol. 1, no. 4, pp. 485–509, Jan. 2003.
-  A. Marandi, T. Braun, K. Salamatian, and N. Thomos, “A Comparative Analysis of Bloom Filter-based Routing Protocols for Information-Centric Networks,” in Proc. of the 23th IEEE Symposium on Computers and Communications, Jun. 2018, pp. 1–7.
-  Z. Li, K. Liu, Y. Zhao, and Y. Ma, “MaPIT: An Enhanced Pending Interest Table for NDN With Mapping Bloom Filter,” IEEE Communications Letters, vol. 18, no. 11, pp. 1915–1918, Nov. 2014.
-  J. H. Mun and H. Lim, “Cache Sharing Using Bloom Filters in Named Data Networking,” J. Network and Computer Applications, vol. 90, pp. 74–82, Jul. 2017.
-  C. Muñoz, L. Wang, E. Solana, and J. Crowcroft, “I(FIB)F: Iterated Bloom Filters for Routing in Named Data Networks,” in 2017 International Conference on Networked Systems, NetSys 2017, Göttingen, Germany, March 13-16, 2017, Mar. 2017, pp. 1–8.
-  B. H. Bloom, “Space/time Trade-offs in Hash Coding with Allowable Errors,” Communications of the ACM, vol. 13, no. 7, pp. 422–426, Jul. 1970.
-  C. Yi, A. Afanasyev, I. Moiseenko, L. Wang, B. Zhang, and L. Zhang, “A Case for Stateful Forwarding Plane,” Computer Communications, vol. 36, no. 7, pp. 779–791, Apr. 2013.
-  S. Mastorakis, A. Afanasyev, I. Moiseenko, and L. Zhang, “ndnSIM 2.0: A New Version of the NDN Simulator for NS-3,” Tech. Rep., Jan. 2015.
-  “The GEANT Network, 2012,” http://www.topology-zoo.org/dataset.html, Jul. 2016, accessed: 2016-07-25.
-  M. E. Crovella and A. Bestavros, “Self-Similarity in World Wide Web Traffic: Evidence and Possible Causes,” IEEE/ACM Transactions on Networking (TON), vol. 5, no. 6, pp. 835–846, Dec. 1997.
-  L. Wang, A. K. M. Mahmudul Hoque, C. Yi, A. Alyyan, and B. Zhang, “OSPFN: An OSPF Based Routing Protocol for Named Data Networking,” Technical Report NDN-0003, pp. 1–15, Jul. 2012.
-  A. K. M. Hoque, S. O. Amin, A. Alyyan, B. Zhang, L. Zhang, and L. Wang, “NLSR: Named-data Link State Routing Protocol,” in Proc. of the 3rd ACM SIGCOMM workshop on Information-centric networking, Aug. 2013, pp. 15–20.
-  M. Tortelli, L. A. Grieco, G. Boggia, and K. Pentikousisy, “COBRA: Lean Intra-domain Routing in NDN,” in Proc. of the IEEE 11th Consumer Communications and Networking Conference (CCNC), Jan. 2014, pp. 839–844.
-  C. Yi, J. Abraham, A. Afanasyev, L. Wang, B. Zhang, and L. Zhang, “On The Role of Routing in Named Data Networking,” in Proc. of the 1st international conference on Information-Centric Networking, Sep. 2014, pp. 27–36.
-  L. Wang, V. Lehman, A. K. M. M. Hoque, B. Zhang, Y. Yu, and L. Zhang, “A Secure Link State Routing Protocol for NDN,” IEEE Access, vol. 6, pp. 10 470–10 482, Jan. 2018.
-  L. Berger, I. Bryskin, A. Zinin, and R. Coltun, “The OSPF Opaque LSA Option,” RFC, vol. 5250, pp. 1–17, Jul. 2008.