ch is a transaction-oriented protocol, based on performing operations on MOs and receiving notifications from MOs. Does this sound familiar? It is, of course, an object-oriented approach to handle the network interfaces between the traffic system and the management system, which today could be supported very well by SM&AML for interface specifica- tion, by platform concepts like CORBA/IDL and by IP networks for communica- tion. TMN defines the OSI stack and X.25 for implementing communication between traffic systems and management systems. However, it seams that today's management systems are abandoning the OSI approach to TMN, e.g. by using the Internet management protocol SNMP (Simple Network Management Protocol, see RFC 1157) instead of CMIP, and the Internet protocol stack instead of the OSI stack. One key issue to be solved for a common management system is how to inter- face the system to a traffic system with a number of different types of logical and physical nodes, that may have proprietary implementations. Figure 3.93 shows the TMN principle. 3.5 Logical Network Structures Network Process operator controller Q-adapter CMIP/SNMP Local TMN manager agent agent/ system OSI or OSI or Resource Traffic IP stack IP stack System Physical nodes in the traffic system Physical nodes in TMN Fig. 3.93 Interfacing TMN to traffic systems Existing traffic systems that are to be interfaced to a TMN system, must describe resources that will be available to TMN management as MOs and store the MO descriptions in the MIB. In addition, they must implement the CMIP or SNMP pro- tocols by an adapting unit in the traffic system. This unit is regarded in TMN as a TMN agent that communicate with a TMN manager in TMN. The traffic system node must also implement the necessary protocols for data transport in TMN (an OSI or an TCP/IP stack). TMN suggests these new functions to be implemented in a common physical node called Q-adapter (since network interfaces between traffic systems and TMN are called Q3 interface). TMN defines a numb