In TRIAD, directory services are integrated into the relay agent nodes to match the availability of directory services with that of the basic communication layer. That is, if you can communicate with it, you can name it. Consequently, the TRIAD dependence on directory services does not reduce availability compared to the original Internet architecture. Integrating directory services into the relay agent nodes also means that the naming capacity is automatically upgraded as the communication capacity at a relay agent is upgraded
Each TRIAD relay agent acts as a name server for each realm to which it is directly connected. For names in the same realm as the requester, the TRIAD directory service behaves exactly the same as current DNS for current IPv4 clients making address requests. That is, a DNS request with QTYPE = A simply returns the IPv4 address of the associated local host, as determined by the local name database. In particular, a relay agent can use name lookup to locate other RAs in the same ISP (and thus presumably connected to the same ISP realm.)
For inter-realm lookups, the relay agent also stores routing information, which can be statically configured, obtained through a dynamic routing protocol, or determined on an as-needed basis. In any case, some knowledge of where in the global network a name is located is necessary to generate IRTs for remote destinations. (Like split DNS in NAT, different realms will have different IRTs associated with the same name.) A relay agent which depends on a directory service to supply it with this information is called a resolver relay, while a relay agent which participates in a routing protocol is a routing relay.
The directory lookup relaying is supported by the Directory Relay Protocol (DRP)[4]. A name request for an endpoint in a remote realm is logically relayed along the path that packets are to take, based on local knowledge of which peer is the ``next hop'' towards an authoritative server for the name being requested. After the request reaches an authoritative server, a response is returned along the reverse path through the relay agents, with each one modifying the IRT to finally produce the IRT that the requester will use. (With transparent tokens, it just appends its address at the front of the IRP.) This behavior was illustrated earlier in Fig. 1.
By relaying the name lookup request across the same relay path as the packets are to flow, any necessary forwarding state can be set up in intermediate relay agents to handle the resulting IRT specification. Combining the path for the lookup with the path taken by the data packets ensures that each can be equally trusted or not. Relay agents also provide reverse (i.e., address-to-name) lookup by forwarding a reverse lookup request along the same path as a packet with the same address.
The relay nodes necessarily provide this directory service because addresses are not stable or meaningful between address realms. A node other than a relay node cannot reliably communicate with directory services outside its realm because IRTs relative to one relay agent are not meaningful when sent to a different relay agent.
In a multi-homed realm, such as an enterprise network served by two ISPs, the internal naming and routing selects one of the relay nodes for the name lookup based on local routing information. This mechanism is also expected to detect when a relay agent fails or becomes disconnected, causing traffic to be rerouted through the other relay agent. Because the name is the primary identifier and can be rebound without losing the connection state, the connection can survive this redirection to the other relay agent similar to a connection surviving rerouting in the current Internet. With routing updates significantly damped in the Internet to avoid oscillations, especially at the BGP level, we expect TRIAD name rebinding to provide recovery latency that is comparable to that of the current Internet.