ough the invokes in this SAG are not those of the AMLn-SAG, they are well defined by a request-reply semantics, defined as part of the CORBA standard. GIOP is designed for working over connection-oriented services (CON). In order to adapt to different strata, adaptation layers that offer a CORBA standardized CON layer interface to GIOP are defined. The layer for running CORBA on an IP network is the IIOP ("Internet inter-ORB protocol"). IIOP runs on TCP/UDP port number 535. As already mentioned, the OMAP framework for management implies that an OMAP management system may exist without being connected to a TMN manage- ment system. This is because an OMAP system is designed for running on TACP, i.e., (similar to SNMP) relying on the very connectivity stratum that it manages. In case OMAP activities are to be initiated from a TMN management system, special OMAP-MOs must exist in some network elements where the OMAP and the TMN management planes meet. In such cases, the OMAP management function will rely on an SS7 connectivity stratum and on a TMN connectivity stratum (i.e., OSI, SNMP or CORBA). 5.3.4 The mpCP Protocol and Spontaneous Events The AMLn and CORBA approach to mpCP suggests that the management layer between a traffic system and its management system can be described in three parts: 1. Specification of all MOs that are used in the interface between AFs and OSFs. 2. A number of general MO-handling operations (such as the CREATE, DELETE, and may be ACTION operation we discussed in Sect. 5.3.1). 3. An agent layer that defines a suitable set of invoke operations that support the abstract protocol. In any mpCP specification, bullets (2) and (3) should be described as parts of the management layer specification, while operations on MOs (bullet (1)) should be described separately. Looking at CMIS/CMIP, SNMP, OMAP, and CORBA, we may expect that (except for OMAP) they support similar but not identical general MO-handling operations, since they have been developed by different standardization bodies at different poi