ranslations for a particular hosted network may be handled by a single SCCP element in an MTP L3 node somewhere 3 Node Structures in the SS7 network. This implies that there is no longer a direct MTP L3-switched route between the nodes that are hosted by SCCP. For every invocation, SCCP must analyse where in the MTP L3 network the T-GT handling node for the referred numbering system exist, and then send its messages to that node for address translation. This results in a considerable increase of SCCP complexity, since it turns SCCP into a switching network, and requires extensive changes to the original SCCP protocol, as indicated by the model in Fig. 3.32. Global routes Other Other addrMethod, numbPlan, destGT {destGT, addrMethod,numbPlan}, callingSSN...) MTP L3-switched routes to SCCP nodes T-ROs that handle T-GTs {SI=SCCP, DPC, OPC, SLS,...) T-ROs MTP L3 Signaling links T-ROs(SCCP): numbPlan->REi(SCCP) MTP L2 T-RE(SCCP): REi(SCCP)->DPC Fig. 3.32 Handling centralized T-GT tables in SCCP turns SCCP into a switching network Note that a routing table (T-ROs) is now needed in an SCCP node. Normally a network address is the search key for such a table, but in the SCCP case it is more likely that the identity of a numbering system is used as the key. SCCP supports both CNL and (several forms of) CON services, user-data error handling, segmentation of user data, and, in addition, three methods of address handling. No wonder that SCCP has become one of the most difficult ITU-T stand- ards to understand. SCCP is an excellent example of how one can complicate a net- work architecture by squeezing too much functionality into a single layer. 3.4.5.3 Global Routes in IP networks If we look at IP-based networks instead, several of these pitfalls have been avoided: CON and CNL services are handled by different layers (UDP and TCP respec- tively). Only one mode of global route handling (centralized) is supported. Translation tables are handled by a separate logical network - the domain name system 3.4 Route Type Examples (DNS)