# Reliable Application Layer Routing Using Decentralized Identifiers
## 5 Implementation and Evaluation
### Routing State Storage and Computational Overhead  
Each edge node maintains a routing table that maps a \(Resource_{URL}\) to either an edge node identifier or to an IP address: in the former case, the IoT device that has advertised the corresponding \(Resource_{URL}\) is attached to another edge node, whereas in the latter case, the  
\begin{table}
\begin{tabular}{l l} \hline \hline
**Parameter** & **Value** \\ \hline Number of buildings & 100 \\ Number of edge nodes & 100 \\ \(Resource_{URL}\) per building & 50 \\ Interval between content advertisements & 10 s \\ Interval between DID document advertisements & 1 min \\ \hline \hline \end{tabular}
\end{table}
Table 1: Evaluation scenario parameters.  
Figure 3: Evaluation topology. The links between the SDN switches and the controller are not shown for clarity reasons.  
device that has advertised the \(Resource_{URL}\) is attached to the local node. In order to decrease the storage overhead, entries that share the same prefix and have the same destination edge node are aggregated. For example, the entries [\"smart-city:iot/building-1/lights\", \"edge-10\"] and [\"smart-city:iot/building-1/power\", \"edge-10\"] will be aggregated to [\"smart-city:iot/building-1/\", \"edge-10\"]. Using this approach, each edge node in the considered evaluation scenario maintains 149 entries: 99 entries that correspond to the smart buildings attached to other edge nodes, and an additional 50 entries for the URLs of the smart building attached to that edge node. These entries are due to the ICN functionality of our system. In addition, the edge router should maintain routing entries used for locating DID documents. In particular, each building is associated with a different _did:domain_ DID, and hence, each router should maintain another 100 records. This state is due to the ICN registry functionality of our system.  
In a system built using the solution defined in [36] a routing entry per digital certificate should be used. Therefore, such a system requires the same routing entries as in our solution. However, in addition to the routing entries, the solution of [36] requires each router to be configured with rules that map prefixes to digital certificate identifiers. Since in the considered use case there are 100 buildings and each building uses its own key to sign advertisements, each router should be configured with 100 additional rules. It should be highlighted that in addition to the extra routing state, the solution defined in [36] creates additional administrative overhead since every time a digital certificate changes (which means its identifier also changes), the corresponding rules in the routers must be updated.  
Routing in our system is implemented using _longest prefix match_ at the edge routers and Bloom-filter-based forwarding in the core network. Using a solution such as the one proposed in [38], an ordinary PC can perform a few millions lookups per second in a routing table that contains 3,000,000 entries. Similarly, the solution presented in [6], which is used in the core of our architecture for implementing Bloom-filter-based forwarding, requires switches from SDN to perform just an OR operation per outgoing link.