.6 for the mentioned connectRequest(inlet,outlet primitive. ACTIONrequest(...) Switch MO connectRequest(inlet,outlet) Switching resource invokeOrd(...) Mappings: connectRequest(inlet,outle ACTIONrequest(objld,accContr,invld,{connect,request, ,outlet}}) invokeOrd(action, request, parameters) In CMIS/CMIP: ACTIONrequest(object class, object instance, access control, invoke identifier, action type, mode, action information, ...) Fig. 5.6 Defining an ACTION operation as part of an mpCP A possible drawback with this method may be the extra steps of packing and unpacking that has to be done by AF and OSF. Note that the AMLn invoke will carry the information elements of the ACTION event, using neither the object iden- tifier nor the invocation identifier parameter. CMIS/CMIP is an example of an mpCP that is defined in this way (see Fig. 5.6). The creators of this standard obviously had problems with the terminology (since they did not use the concept of a meta-primitive): the operation ACTION was called "service," the operations of MOs were called "action type," their primitive types "mode" and their parameters "action information." The primitive types of an ACTION are the OSI request, indication, response and confirmation, since the CMIS/CMIP places the AF-OSF actor layer as an OSI layer on top of ROSE and ACSE. CMIS/CMIP, SNMP, CORBA/GIOP, and OMAP are all methods that can be, and are, used as abstract protocols for mpCP. They are far from equivalent, how- 5 Management and Traffic Systems ever. Sometimes several of them are used in managing the same traffic plane, which, besides the costs and inconvenience for an operator, may require complex management gateway functions for translating management information between management systems. Differences between methods can be identified in three areas: 1. The view on MOs and how they are specified (see Sect. 5.3.2). 2. The method used for providing connectivity for the mpCP, modeled as the SAGM in AMLn, and whatever supports this agent layer (see Sect. 5.3.3). 3. The opera