At the inter-realm level, routing relays use name-based routing because addresses are not a meaningful way to identify endpoints in the wide area, and to ensure the availability of those names. (Intra-realm routing can use existing routing protocols, and intra-realm reliability of name service is ensured by duplicate servers as now, or possibly by router-integrated directory services.) Routing information is distributed among relay nodes and maintained locally with next hops and destinations specified in terms of names and name suffixes. With this step, the name directory and the routing table logically become a single entity, reducing the overall complexity of the directory and relay agent software. Note that a conventional routing table is a simple directory: It is queried with an IP address to determine the forwarding information. With TRIAD, the equivalent directory in a relay node is queried using the DNS name.
The Name-Based Routing Protocol (NBRP) [2] performs routing by name with a structure similar to BGP. Just as BGP distributes address prefix reachability information among autonomous systems, NBRP distributes name suffix reachability among address realms. NBRP updates are authenticated by cryptographically signing ``delegations'' of part of the namespace to a relay agent's peers, in a manner similar to Secure BGP [16].
The key challenge with a name-based routing is maintaining the routing database efficiently even in the presence of names that do not match the routing hierarchy. Two mechanisms in NBRP reduce routing table size to a feasible level. The redirection mechanism explained above for mobility handles hosts whose names do not match network topology. (For example, all hosts with Harvard names not in the same address realm as the authoritative server for Harvard.EDU would have redirect records at that server.)
The other important component of NBRP is support for combining collections of name suffixes into routing aggregates, so that routing updates typically update a small number of aggregates rather than many individual entries. All names in a routing aggregate may be treated identically in routing calculations, thus reducing load at relay agents. Typically, we expect an ISP relay node to group all of the names from its customers into a small number of aggregates. Aggregate membership should be relatively long-lived, so that relay nodes can amortize the cost of learning the aggregate membership over many routing updates.
Another issue is keeping the number of neighbors small so that the routing overhead is acceptable. This can be accomplished by adding additional nodes on the interior of a realm which perform only route updates and name lookups, but not relaying. Current BGP speakers could be upgraded to perform as NBRP speakers as well, without necessarily acting as routing relays. As a degenerate example of the same idea, a typical ISP customer's relay agent may simply cache name and route information maintained by a relay agent (or its surrogate) located in the ISP's domain, eliminating the need for peering among ISP customers and reducing memory requirements for customer relay nodes.