 T-RE: n22-GT T-GT/ DNS-P PON,IPA Cache Routes to other PON,IPA DNS servers destPON(n22) destIPA(n22) Fig. 3.34 The scenario for retrieving an REdef from DNS. IPA=IP address; PON=port number The layer element in n21 wants to send a message to n22. Its T-RE shows that the route to n22 is a global route, which is why n21 has to contact the resolver. The resolver (n31) will first look into its cache memory to see if the wanted translation is stored there (as a result of previous request from n21). If not, it uses its own T-RE table to contact the nearest DNS node (n32 here), that may have the translation. n32 may be able to provide socket information for n22. If not, n32 contacts other DNS nodes, using its own T-RE, to get the answer. When the answer is finally delivered to n21, n31 stores the GT-REdef transla- tion for n22 in its cache memory for future use. Next time n21 asks for the same domain name, n31 may use this information (if not too old) instead of asking a remote DNS node. In some IP-based networks, e.g., the Internet, there is no central authority that guarantees that the information stored in DNS is correct, i.e., that it accurately reflects the configuration of applications in the network. Application nodes, such as n21, may be reallocated in the hosting network nw1 or vanish from the network. A discipline must therefore be used by resolvers to check regularly against DNS servers that the information stored in its cache is still valid. The DNS logical network has a hierarchical structure of nodes that store GT-REdef translations, according to a hierarchical domain-name structure (see the logical-network structure in Fig. 3.35). 3.4 Route Type Examples Hosted networks that rely on DNS nw1,nw3 Inw1,nw3 Cache Cache Cache hosts Resolvers Fig. 3.35 The logical-network structure of an IP based network. All routes of nw2 through nw4 rely on nw1 This exercise is an example where three logical networks (nw2, nw3 and nw4) may be related by relations other than routes. In this case, nw3 resolver nodes offer acce