tem, but in itself does not change anything in the traffic plane. DELETE an MO instance. A DELETE operation must be of class REQUEST. This type of operation decreases the range of management from the MS, but in itself does not change anything in the traffic plane. Report EVENTs that happen in the traffic system, particularly alarming events. In AMLs we define such reports as operations of the operation class REPORT. Such reports will normally inform about spontaneous state changes in the traffic system, which have already happen. None of these operations can be used for creating state changes (i.e., affect any real resource) in the traffic system. If we want to do that, we must use specific operations on an MO instance. In AMLs we call such operations modifier opera- tions. These are specified for the corresponding MO class. For example, a switch- ing element may be defined by an MO. The OSF can create a new path through that switch by inserting the information elements of a connectRequest(inlet, outlet) event as parameters in an invokeOrder in its SAGM, also including the actual object identifier and possibly an invocation identifier. Thus, since the AMLn definition of 5.3 The Management Plane Control Point (mpCP) invokes allows object identifiers to be transported in agent layers, there is no need for a generic operation for modifier operations in an mpCP. However, one may have to define other parameters than just the object identifier for a modifier operation, e.g., information for access control that is confined to the particular MO class, MO instance, or MO operation. That might be a reason for defining a separate ACTION operation in mpCPs. Such an operation will take over the meta-primitive role of the AMLn invokes, as operations on MOs are concerned, since the information elements of MO events will be carried as parameters of ACTION primitives. Instead the AMLn invokes will carry the information elements of an ACTION event. Thus, we get a structure of meta-primitives on two levels, as exemplified in Fig. 5