 - not by TCP and UDP. A domain name is the equivalence to a global title. Figure 3.33 depicts the GT problem and how DNS solves it. GT not supported: T-RE: n22 {destPON,destIPA T-RE table maintenance destPON destIPA GT supported: T-GT/ DNS-P DNS-P Cache Routes to other DNS servers Resolver DNS server Fig. 3.33 Introducing DNS in IP-based networks. CP=DNS access control point; DNS=domain- name system; DNS-P=DNS protocol for access and T-GT/T-RE maintenance Every layer element has some (explicit or implicit) means of translating an implied logical node name of its own network to an REdef that defines address parameters of a hosting node. Application logical networks in IP-based networks can be relieved from such translations and maintenance by allocating GT-REdef translations for all application networks in a logical network of its own, the DNS network (a GT-REdef translation is an entry in a combined T-GT and T-RE table). This is an example of vertical partitioning of functionality, i.e., a function (GT-REdef translation) that may be needed by a great number of logical networks is extracted and allocated in a common logical network. Application networks access the common network over a DNS-defined access control point (CP). Logi- cally, such a control point exists in every switching node, e.g., in n11 in this model. Note, however, that this control point is not standardized. The element that provides this control point is called resolver. Although the resolver is normally just a library procedure that is compiled into a software reali- zation of an application-layer element, it is logically a part of the DNS logical net- work. The resolver does not handle translation tables, but a DNS access protocol 3 Node Structures that is used for retrieving GT REdef translations from remote DNS servers. The DNS protocol is also used for maintaining GT-REdef translations. Figure 3.34 shows the scenario for retrieving a GT-REdef translation from the DNS network. Cache: Not in cache T-RE: in32->{destPON,destIPA} n22-> {PON,IPA}