- 144 - COM VII-R 38-E CCITT\COMVII\RAPP\R038E2.DOC Recommendation X.700 MANAGEMENT FRAMEWORK DEFINITION FOR OPEN SYSTEMS INTERCONNECTION (OSI) FOR CCITT APPLICATIONS1 CONTENTS Page 0. Introduction 146 1. Scope 146 2. References 147 3. Definitions 147 4. Symbols and abbreviations 148 5. Concepts in OSI management 148 6. Model of OSI management 151 7. OSI management specifics 153 Annexes: Annex A - Comments relating to the OSI management framework 156 0. Introduction The basic reference mode of Open Systems Interconnection (OSI), Recommendation X.200 [1], provides a description of the activities necessary for systems to interwork using communication media. This Recommendation provides a description of the framework and structure of OSI management in a way that supplements and clarifies the description of management contained in Recommendation X.200 [1]. The purpose of this Recommendation is to provide a common basis for the coordinated development of management standards. It is also the purpose of this Recommendation to identify areas for developing or improving standards, and to provide a common reference for maintaining consistency of all related standards. It is not the intent of this Recommendation either to serve as an implementation specification, or to be a basis for appraising the conformance of actual implementations, or to provide a sufficient level of detail to define precisely the services and protocols of the management architecture. Rather, this Recommendation provides a conceptual and functional framework which allows independent teams of experts to work productively on the development of management standards. This Recommendation provides an extension to Recommendation X.200 [1] and therefore assumes as a basis the concepts and terminology included therein. The objective of this document is to describe a framework for those management activities pertinent to OSI, and to identify the management services which are supported by OSI management protocols. The description of the management framework given in this Recommendation is developed in stages: - Clause 1 defines the scope of this Recommendation. - Clause 2 lists related OSI standards. - Clause 3 defines terms and abbreviations used in this Recommendation. - Clause 4 provides the description of general concepts relating to management. - Clause 5 defines a model for OSI management. - Clause 6 introduces the areas of OSI management standardization, specifies how each of the component parts of OSI management operate and defines the form of management information exchanges. Management is manifest in a number of ways. Management is related to activities which control or monitor the use of resources. Within open systems the resources can be those which provide data storage or processing capabilities, or they can be those which provide interconnection capabilities. It is only the latter and the communications concerning their management which fall within the scope of OSI management standardization. Human beings are ultimately responsible for managing the OSI environment, although responsibilities may be delegated to automated processes. 1. Scope This Recommendation establishes a framework for coordinating the development of existing and future standards for OSI management, and is provided for reference by those Recommendations. This Recommendation: - defines terminology of and describes concepts for OSI management; - provides a structure for OSI management together with an overview of the objectives of and facilities provided by OSI management; and - describes OSI management activities. This Recommendation does not specify services or protocols for OSI management. It is neither an implementation specification for systems, nor a basis for appraising the conformance of implementations. 2. References [1] CCITT Recommendation - Reference model for open systems interconnection for CCITT applications. Blue Book, Fascicle VIII.4, Recommendation X.200, ITU, Geneva, 1988. [2] CCITT Recommendation - Security architecture for open systems interconnection for CCITT applications. Recommendation X.800, ITU, Geneva, 1991. 3. Definitions 3.1 For the purpose of this Recommendation, the following terms apply: a)(N)-entity; b)(N)-layer; c)(N)-protocol; d)(N)-protocol-data-unit; e)open system; f)systems management. 3.2 For the purpose of this Recommendation, the following terms apply: a)Systems management application-entity An application-entity for the purpose of systems management communication. 3.3 Additional definitions a)OSI management The facilities to control, coordinate and monitor the resources which allow communication to take place in the OSI environment; b)(N)-layer operation The monitoring and control of a single instance of communication; c)Managed object The OSI management view of a resource within the OSI environment that may be managed through the use of OSI management protocol(s); d)Management information base The conceptual repository of management information within an open system. 4. Symbols and abbreviations MIB - Management information base OSI - Open systems interconnection OSIE - OSI environment PDU - Protocol-data-unit SMAE - Systems management application-entity 5. Concepts in OSI management 5.1 Users' requirements of OSI management Recognizing the need for interconnection services which will carry information in a reliable and economic manner, OSI management supports the users' needs for: a)activities which enable managers to plan, organize, supervise, control and account for the use of interconnection services; b)the ability to respond to changing requirements; c)facilities to ensure predictable communications behaviour; d)facilities which provide for information protection and for the authentication of sources of and destinations for transmitted data. The management tools which provide this support may vary in complexity depending upon the users' requirements. Such tools may operate locally or cooperate across a number of open systems. OSI management does not constrain the user interface. 5.2 The OSI management environment The OSI management environment is that subset of the total OSI environment (OSIE), which is concerned with the tools and services needed to monitor, control and coordinate interconnection activities. The OSI management environment includes both the capability for managers to gather information and to exercise control, and the capability to maintain an awareness of and report on the status of resources in the OSIE. The individual open systems within the OSIE may have aspects of management responsibility delegated to them. The responsibility may be manifest in terms of: a)autonomous management of the open system; b)cooperation with other open systems, through the exchange of information, to perform coordinated management activities. This management responsibility is directed at individual resources, each of which may operate with a degree of independence from other resources. This management responsibility may be further extended to co-ordinate and control sets of resources to increase functionality and performance. 5.3 Managed objects, their attributes and operations A managed object is the OSI management view of a resource within the OSIE that is subject to management, such as a layer entity, a connection or an item of physical communications equipment. Thus a managed object is the abstracted view of such a resource that represents its properties as seen by (and for the purposes of) management. A managed object is defined in terms of attributes it possesses, operations that may be performed upon it, notifications that it may issue and its relationships with other managed objects. This is distinct from, but related to, any definitions or specification of the resource represented by the managed object as an element of the OSIE. The set of managed objects within a system, together with their attributes, constitutes that system's management information base (MIB). 5.4 Management relationships between open systems The users' requirements for OSI management may be met either by local operations or by the communication of information between open systems, or by both. OSI management is achieved between open systems through cooperation between one or more components of the management activity taking a managing role and others taking a managed role. The role played by a particular system may be static or may change over time, and may depend upon the particular management communication. OSI management information flow between open systems is defined in terms of operations and notifications. 5.5. OSI management functional areas 5.5.1Introduction OSI management is required for a number of purposes. These requirements are categorized into a number of functional areas: a)fault management (see § 5.5.2); b)accounting management (see § 5.5.3); c)configuration management (see § 5.5.4); d)performance management (see § 5.5.5); e)security management (see § 5.5.6). Specific management functions, within these functional areas, are provided by OSI management mechanisms. Many of the mechanisms are general in the sense that they are used to fulfil requirements in more than one functional area. Similarly, managed objects are general in the sense that they may be common to more than one functional area. Each of these functional areas is described briefly below. The lists of functions are not necessarily exhaustive. 5.5.2Fault management Fault management encompasses fault detection, isolation and the correction of abnormal operation of the OSI environment. Faults cause open systems to fail to meet their operational objectives and they may be persistent or transient. Faults manifest themselves as particular events (e.g. errors) in the operation of an open system. Error detection provides a capability to recognize faults. Fault management includes functions to: a)maintain and examine error logs; b)accept and act upon error detection notifications; c)trace and identify faults; d)carry out sequences of diagnostic tests; e)correct faults. 5.5.3Accounting management Accounting management enables charges to be established for the use of resources in the OSIE, and for costs to be identified for the use of those resources. Accounting management includes functions to: a)inform users of costs incurred or resources consumed; b)enable accounting limits to be set and tariff schedules to be associated with the use of resources; c)enable costs to be combined where multiple resources are invoked to achieve a given communication objective. 5.5.4Configuration management Configuration management identifies, exercises control over, collects data from and provides data to open systems for the purpose of preparing for, initializing, starting, providing for the continuous operation of, and terminating interconnection services. Configuration management includes functions to: a)set the parameters that control the routine operation of the open system; b)associate names with managed objects and sets of managed objects; c)initialize and close down managed objects; d)collect information on demand about the current condition of the open system; e)obtain announcements of significant changes in the condition of the open system; f)change the configuration of the open system. 5.5.5Performance management Performance management enables the behaviour of resources in the OSIE and the effectiveness of communication activities to be evaluated. Performance management includes functions to: a)gather statistical information; b)maintain and examine logs of system state histories; c)determine system performance under natural and artificial conditions; d)alter system modes of operation for the purpose of conducting performance management activities. 5.5.6Security management The purpose of security management is to support the application of security policies by means of functions which include: a)the creation, deletion and control of security services and mechanisms; b)the distribution of security-relevant information; c)the reporting of security-relevant events. Note - Recommendation X.800 [2] provides further information on the placement of OSI management functions within the overall security architecture. 6. Model for OSI management 6.1 Overview OSI management encompasses those activities needed to control, coordinate and monitor the resources which allow communications to take place in the OSI environment. Activities relate to the means by which: a)a real open system obtains information to enable the supervision and control of its communications resources; b)real open systems cooperate to supervise and control the OSI environment. The model of OSI management is defined in terms of: c)the OSI management structure (see § 6.2); d)the supporting functionality required by OSI management (see § 6.3); e)the management information base (see § 6.4); f)the flow of control amongst processes (see § 6.5); and g)the flow of information between entities (see § 6.6). 6.2 OSI management structure Management is effected through a set of management processes. These processes are not necessarily located at one local system but may be distributed in many ways over a number of systems. Where management processes which are not co-resident need to communicate with one another in the OSI environment, they communicate using OSI management protocols. OSI management is accomplished through: a)systems management; b)(N)-layer management; c)(N)-layer operation. Systems management provides mechanisms for the monitoring, control and coordination of managed objects through the use of application-layer systems management protocols. OSI communications concerning systems management functions are realized through a systems management application-entity (SMAE). Systems management may be used to manage any objects within or associated with an open system. (N)-layer management provides mechanisms for the monitoring, control and coordination of managed objects which relate to communications activities within the (N)-layer, through the use of special-purpose management protocols within the (N)-layer. (N)- layer management can affect multiple instances of communication. The (N)-layer may therefore be managed through the use of systems management protocols or through the use of (N)-layer management protocols. (N)-layer operation provides mechanisms for the monitoring and control of a single instance of communication. This Recommendation does not imply any particular relationship among management mechanisms. 6.3 Supporting functionality required by OSI management An open system must have sufficient functionality at all seven layers to support an SMAE before the systems management functionality provided by that SMAE can be accessed by another open system. When the functionality to support any SMAEs does not exist, the greatest OSI management functionality that can be available on such an open system is the set of separate, individual functionalities provided by the layer managements of the (N)-layers within that open system. In order to support (N)-layer management, sufficient communication functionality must exist at layers 1 to (N- 1). When neither systems management nor (N)-layer management can be provided, then the greatest OSI management functionality that can be available is the set of separate individual management functionalities provided by (N)-layer operation. An SMAE can exist on an open system independently of the existence of (N)-layer management entities at any of the layers. 6.4 Management information base A management information base (MIB) is that information within an open system which may be transferred or affected through the use of OSI management protocols. The MIB is the set of managed objects within an open system, however, only the managed objects relating to the OSI environment are subject to standardization. In addition, the logical structure of management information is standardized. This does not imply any form of physical or logical storage for the information and its implementation is a matter of local concern and outside the scope of OSI standards. Management information may be shared between management processes and structured according to the requirements of those processes. The MIB neither restricts the interpretation of management data to a pre-defined set, not to whether the data is stored in a processed or unprocessed form. However both the abstract syntax and the semantics of information which is part of the MIB are defined so that they can be represented in OSI protocol exchanges. 6.5 Flow of management control Management processes, which support OSI management, receive control information: a)from people and/or software acting as administrative agents local to a management process; b)from remote systems through their: - SMAEs; - (N)-layer management entities; - (N)-entities. The management process exert control: c)directly upon managed objects in the same open system; d)upon managed objects in other open systems by protocol exchanges through their: - SMAEs; - (N)-layer management entities; - (N)-entities. The flow of control from administrative agents to local management processes occurs entirely within the local system environment, and as such is outside the scope of OSI management standardization. Such local control may result in OSI management communications. The abstract syntax and semantics of control flow within the OSI environment are defined so that they can be represented in OSI protocol exchanges. 6.6 Flow of management information The OSI management information within a management information base may be provided by, and made available to: a)local administrative agents; b)remote open systems, through: - systems management protocols; - (N)-layer management protocols; - (N)-protocols. Information exchanges may provide monitoring information or may result in the exercise of control. Information exchanges between administrative agents and the MIB occur entirely within the local system and are outside the scope of OSI management standardization. 7. OSI management specifics 7.1 OSI management standardization Areas of OSI management standardization include: a)the services and protocols used to transfer management information between open systems; b)the abstract syntax and semantics of the information transferred in management protocols. These areas of standardization apply to systems management, (N)-layer management and normal (N)-layer operation. The actual specification of the syntax, semantics, services and protocols, and the concepts applicable to managed objects are provided in specific OSI standards. The physical representation of managed objects and their physical storage are local matters and are not subject to standardization. Systems management standards specify the systems management services and protocols, plus the abstract syntax and semantics of the information transferred in such protocols. The (N)-layer management protocols and the management aspects of (N)-protocols are defined by Recommendations specifying those protocols in order to cover layer related aspects of the above management facilities. (N)-layer standards may specify (N)-layer management protocols and their use. This standard does not imply that any systems management protocols or layer management protocols are mandatory, neither does it constrain the use of management information in any (N)-protocol exchanges. 7.2 OSI management operation 7.2.1Systems management Systems management communications provide the normal method for exchanging OSI management information. These communications take place between systems management applications-entities. Systems management protocols are application layer protocols. Any application-process which communicates according to systems management protocol standards does so through an SMAE. The service elements used to support systems management are application service elements. Not all open systems provide the full functionality of the seven layers specified in Recommendation X.200. Where such open systems are not the initial source of, nor the ultimate destination for the transfer of data, they act for such instances of communication as relay open systems. Where such systems are required to act as sources of system management information or are subject to systems management control, information is communicated using systems management protocols. 7.2.2(N)-layer management (N)-layer management supports the monitoring, control and coordination of (N)-layer managed objects. (N)-layer management protocols are supported by protocols of the layers (N-1) and below. They do not provide communication capability offered by the (N+I) and higher layers. (N)-layer management protocols can only convey management information between peer (N)-layer management entities pertinent to the (N)-sub-systems in which these entities reside. (N)-layer management protocols should only be used where special requirements dictate that systems management protocols are inappropriate or when systems management protocols are not available. (N)-layer management protocols provide such functions as: a)communicating parameter values associated with managed objects which relate to the operation of the (N)-layer; b)testing the functionality provided by the (N-1)-layer; c)conveying error information describing faults or diagnostic information related to the operation of the (N)-layer. Each (N)-layer management protocol is independent of other layer management protocols. This Recommendation does not require the development of (N)-layer management protocols for each of the seven layers. 7.2.3(N)-layer operation Management functions may exist within the (N)-protocols in all seven layers of OSI. The management information that is carried within an (N)-protocol must be distinguishable from information which the protocol carries for other purposes. It is the responsibility of the (N)-protocol to provide this distinction. Management information carried by (N)-protocol exists for the purpose of controlling and monitoring a single instance of communication. Examples of management information carried within an (N)-protocol are: a)parameters carried in connection establishment PDUs that apply to the specific instance of communication which is being established; b)parameters carried in particular PDUs which can modify the environment in which this instance of communication operates; c)error information describing faults encountered during the operation of that specific instance of communication; d)parameters carried in connection release PDUs which report information pertaining to that specific instance of communication which is being released. 7.2.4Relationships between systems management, (N)-layer management and (N)-layer operation Whereas the specification of (N)-layer management and (N)- layer operation standards is not the concern of systems management, the semantics of (N)-layer management information and the operations permitted thereon must be consistent with such information and operations defined by systems management. (N)-layer management entities are of different types from those (N)-entities which operate (N)-protocols as defined in Recommendation X.700. (N)-layer management protocols are distinguished from normal (N)-protocols by the use of (N-1)-layer addressing mechanisms or by discrimination mechanisms within the (N)-layer. (N)-layer management entities and (N)-entities operate, independently of each other, upon managed objects which relate to the operation of the (N)-layer. 7.3 The form of management information exchanges Management information exchanges are effected by the use of application layer or (N)-layer services; these may be normal (N)- services, or services provided specifically for management purposes. The information exchanges may be either 2-party or N- party in nature, depending upon the requirements of the initiator of the exchange and the nature of the services available to carry out the exchange. Any party may take the role of initiator in a management exchange; the remaining parties to the exchange take the role of responder. The exchange may be initiated for the purposes of performing management operations of notifications. 7.4 OSI management conformance This Recommendation does not imply any conformance requirements for systems management, (N)-layer management or (N)- layer operation. Annex A (This annex does not form an integral part of this Recommendation) Comments relating to the OSI management framework A.1 Introduction The OSI management framework provides the concepts and an abstract model of OSI management for use by those developing OSI standards. The purpose of this annex is to provide additional explanatory material as an aid to understanding the concepts in the body of this Recommendation and to explain their application. A.2 Abbreviations QOS - Quality of Service A.3 Brief overview of OSI management scope and concepts Three forms of management information exchange are defined within the OSI management architecture for which standards are expected: a)systems management; b)(N)-layer management; c)(N)-layer operation. Systems management is the preferred form of management information exchange and provides mechanisms for the exchange of information relating to the monitoring, control and coordination of communications resources of concern to open systems. The framework uses the term "managed objects" to describe the management view of these resources. Systems management acts upon managed objects in order to manage the resources to which these objects relate. Such managed objects can relate to one or more OSI layers. FIGURE A.1 Systems management information exchange It is perceived that the majority of management information exchanges between open systems will require context negotiation, the establishment of a management session, a reliable end-to-end transport service etc., in exactly the same way as other application layer exchanges. Therefore systems management communication is effected through application layer protocols (see Figure A.1), Systems management services and protocols are being developed collaboratively between CCITT and JTC 1, to provide a common base for all applicable CCITT applications (notably the Telecommunication Management Network and JTC 1 Recommendations/Standards). (N)-layer management is used in special circumstances to carry information relating specifically to the operation of an (N)-layer. An example of layer management is the transport layer network connection management sub-protocol (NCMS). It is important to note that layer management at one layer should not replicate any of the functionality of the layers above it, as this would be at variance with the basic reference model. Figure A.2 shows an example of such an exchange in the transport layer. (N)-layer management exchanges can occur in any layer, although layers 2, 3 and 4 are those where such standards are most likely to occur. Layer management standards are the responsibility of the relevant layer standards group, within CCITT/JTC 1. FIGURE A.2 (N)-layer management exchange (N)-layer operation is the set of facilities which control and manage a single instance of communication. These facilities can be embedded within an existing "normal" (N)-protocol exchange (see Figure A.3), for example the passing of charging information in an X.25 Clear packet, or they may be a special element of protocol, such as an X.25 Reset. Standards for (N)-layer operation are the responsibility of the relevant layer standards group with CCITT/JTC 1. FIGURE A.3 (N)-layer operation A.4 Systems management standards There are requirements for standardized application services and protocols for the exchange of management information covering a number of functions. A set of application layer standards for systems management are being developed to give users a "toolkit" of services and protocols to allow the exchange of management information between open systems. A.5 Management information and the management information base It is important to recognize that the real information being carried in OSI management protocols is in fact information generated by (and defined by) the individual layer standards. Thus the specification and identification of these "real" elements of management information needs to be carried out by the layer standards groups, in liaison with the OSI management Working Group, as part of the standardization activity. A common approach is needed across the layers if a consistent definition is to be produced without omissions or duplications. There is also the problem that not all elements are layer-related. Furthermore, the top-level statements of allocation of functions to the set of OSI management protocols are not complete. This makes it hard for those who have identified particular users needs for management activities (e.g. for access control or QOS) to express them constructively and to direct contributions to the appropriate groups. Consequently, the MIB can be viewed as that information within an open system which can be transferred or affected by the use of OSI management protocols. The MIB can also be visualized as the set of managed objects within an open system, which relate to the OSI environment. In addition, the logical structure of management information must be standardized, however this does not imply any form of physical or logical storage for the information and its implementation is a matter of local concern and outside the scope of OSI standards. Management information may be shared between management processes and structured according to the requirements of those processes. The MIB neither restricts the interpretation of management data to a pre-defined set, nor to whether the data is stored as received or processed. However, both the abstract syntax and the semantics of information which is part of the MIB are defined so that they can be represented in OSI protocol exchanges. Draft Recommendation X.734 INFORMATION TECHNOLOGY - OPEN SYSTEMS INTERCONNECTION - SYSTEMS MANAGEMENT: EVENT REPORT MANAGEMENT FUNCTION Contents 1. Scope 2. Normative references 2.1 Identical CCITT Recommendations | International Standards 2.2 Paired CCITT Recommendations | International Standards equivalent in technical content 2.3 Additional references 3. Definitions 3.1 Basic reference model definitions 3.2 Service convention definitions 3.3 Management framework definitions 3.4 Systems management overview definitions 3.5 Common management information service definitions 3.6 OSI conformance testing definitions 3.7 Additional definitions 4. Abbreviations 5. Conventions 6. Requirements 7. Model for the event report management function 7.1 General 7.2 Event report management mode 8. Generic definitions 8.1 Managed objects 8.2 Imported generic definitions 9. Service definitions 9.1 Introduction 9.2 Initiation of event report forwarding 9.3 Termination of event report forwarding 9.4 Event forwarding discriminator modification, suspension and resumption 9.5 Retrieval of event forwarding discriminator attributes 10. Functional units 11. Protocol 11.1 Elements of procedure 11.2 Abstract syntax 11.3 Negotiation of functional units 12. Relationship with other functions 13. Conformance 13.1 General conformance class requirements 13.2 Dependent conformance class requirements 13.3 Conformance to support managed object definitions Annex A: Example value notation for the discriminator construct Annex B: Event forwarding using local mechanism Annex C: Considerations for system implementation conformance statement INFORMATION TECHNOLOGY - OPEN SYSTEMS INTERCONNECTION - SYSTEMS MANAGEMENT: EVENT REPORT MANAGEMENT FUNCTION 1. Scope This Specification defines a Systems Management Function which may be used by an application process in a centralized or decentralized management environment to interact for the purpose of systems management, as defined by CCITT Rec. X.700 | ISO/IEC 7498-4. This Specification defines the Event Report Management function and consists of services and two functional units. This function is positioned in the application layer of the CCITT Rec.X.200 | ISO/IEC 7498 and is defined according to the model provided by ISO/IEC 9545. The role of systems management functions is described in CCITT Rec. X.701 | ISO/IEC 10040. This Specification - establishes user requirements for the event report management function; - establishes models that relate the services provided by the function to user requirements; - defines the services provided by the function; - specifies the protocol that is necessary in order to provide the services; - defines the relationship between the services and SMI operations and notifications; - defines relationships with other systems management functions; - specifies conformance requirements. This Specification does not - define the nature of any implementation intended to provide the Event Report Management function; - specify the manner in which management is accomplished by the user of the Event Report Management function; - define the nature of any interactions which result in the use of the Event Report Management function; - specify the services necessary for the establishment, normal and abnormal release of a management association; - specify the authorization requirements for the use of the Event Report Management function or for any associated activity; - define the managed objects related to the management of particular protocol machines. 2. Normative references The following CCITT Recommendations and International Standards contain provisions which, through reference in this text, constitute provisions of this Specification. At the time of publication, the editions indicated were valid. All Recommendations and Standards are subject to revision, and parties to agreements based on this Specification are encouraged to investigate the possibility of applying the most recent editions of the Recommendations and Standards listed below. Members of IEC and ISO maintain registers of currently valid International Standards. The CCITT Secretariat maintains a list of the currently valid CCITT Recommendations. 2.1 Identical CCITT Recommendations | International Standards - CCITT Recommendation X.701 [1992] | ISO/IEC 10040 : 1992, Information technology - Open Systems Interconnection - Systems management Overview. - CCITT Recommendation X.721 [1992] | ISO/IEC 10165-2 : 1992, Information technology - Open Systems Interconnection - Structure of Management Information Definition of Management Information. - CCITT Recommendation X.730 [1992] | ISO/IEC 10164-1 : 1992, Information technology - Open Systems Interconnection - Systems Management - Object management function. - CCITT Recommendation X.731 [1992] | ISO/IEC 10164-2 : 1992, Information technology - Open Systems Interconnection - Systems Management - State management function. 2.2 Paired CCITT Recommendations | International Standards equivalent in technical text - CCITT Recommendation, Reference Model of Open Systems Interconnection for CCITT Applications, BLUE Book, Vol VIII.4 Rec.X.200, ITU, Geneva 1989. ISO 7498 : 1984, Information processing systems - Open Systems Interconnection - Basic Reference Model. - CCITT Recommendation, Open Systems Interconnection (OSI) Layer Service Definition Conventions for CCITT Applications, BLUE Book, Vol VIII.4, Rec.X.210, ITU, Geneva 1989. ISO/TR 8509 : 1987, Information processing systems - Open Systems Interconnection - Service Conventions. - CCITT Recommendation , Management Framework Definition for Open Systems Interconnection (OSI) for CCITT Applications, Rec.X.700. ISO/IEC 7498-4 : 1989, Information processing systems - Open Systems Interconnection - Basic Reference Model - Part 4 : Management Framework - CCITT Recommendation, Specification of abstract syntax notation one (ASN.1),BLUE Book, Vol. VIII.4,Rec. X.208, ITU, Geneva 1989. ISO 8824 : 1990, Information technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1). - CCITT Recommendation X.209: Specification of Basic Encoding Rules for abstract syntax notation. ISO 8825 : 1990, Information technology - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). - CCITT Recommendation , Common Management Information Service Definition for CCITT Applications, Rec. X.710,ITU, Geneva 1991. ISO/IEC 9595 : 1991, Information technology - Open Systems Interconnection - Common management information service definition. - CCITT Recommendation , General Concepts of OSI Conformance Testing Methodology and Framework,Rec. X.290,ITU, Geneva 1991. ISO/IEC 9646-1 : 1991, Information technology - OSI conformance testing methodology and framework - Part 1: General concepts. 2.3 Additional references - ISO/IEC 9545, Information technology - Open Systems Interconnection - Application Layer Structure. 3. Definitions For the purposes of this Specification, the following definitions apply. 3.1 Basic reference model definitions This Specification makes use of the following terms defined in CCITT Rec. X.200 | ISO 7498. a)open system; b)systems management. 3.2 Service convention definitions This Specification makes use of the following term defined in CCITT Rec. X.210|ISO/TR 8509. a)primitive. 3.3 Management framework definitions This Specification makes use of the following terms as defined in CCITT Rec. X.700 | ISO/IEC 7498-4. a)management information; b)managed object; c)systems-management-application-entity. 3.4 Systems management overview definitions This Specification makes use of the following terms defined in CCITT Rec. X.701 | ISO/IEC 10040. a)agent role; b)dependent conformance; c)general conformance; d)management support object; e)manager role; f)notification; g)systems management functional unit; h)systems management operation. 3.5 Common management information service definitions This Specification makes use of the following terms defined in CCITT Rec. X. 710 | ISO/IEC 9595 . a)attribute; b)common management information services; c)common management Information service element. 3.6 OSI conformance testing definitions This Specification makes use of the following terms defined in CCITT Rec. X.290 | ISO/IEC 9646-1. a)system conformance statement 3.7 Additional definitions The following terms are defined in this Specification. 3.7.1 discriminator - a management support object that allows a system to select management operations and event reports relating to other managed objects. 3.7.2 discriminator input object - a conceptual object whose attributes are parameters of either an operation or a notification. Discriminator input objects are defined for the purpose of discrimination and instances of discriminator input objects exist only for the duration of discrimination. Discriminator input object attributes can be used for discrimination, if and only if they have an object identifier. Attributes that have no matching rules defined for them can only be checked for presence. 3.7.3 event forwarding discriminator - a discriminator that acts on potential event reports. 3.7.4 event report management function - a function, including the definition of a management support object class, that allows a manager to control the transmission of event reports from managed objects independent of the definition of the managed objects. 3.7.5 potential event report - a type of discriminator input object that is defined for the purpose of event forwarding discrimination. A potential event report consists of all the information required to be forwarded in the event report. The information is derived from the information contained in the notification and information derived from local processing of the notification,if any. 4. Abbreviations a)ASN.1 - Abstract Syntax Notation One b)CMIS - common management information service c)CMISE - common management information service element d)EFD - event forwarding discriminator e)ERF - event reporting function f)Id - Identifier g)MAPDU - management application protocol data unit h)PDU - protocol data unit i)SMAE - systems management application entity j)SMFU - systems management functional unit k)SMI - structure of management information 5. Conventions This Specification defines services for the event report management function following the descriptive conventions defined in CCITT Rec. X.210|ISO/TR 8509. 6. Requirements The requirements to be satisfied are a)the definition of a flexible event report control service which will allow systems to select which event reports are to be sent to particular managing systems; b)the specification of the destinations (eg the identities of managing systems) to which event reports are to be sent; c)the specification of a mechanism to control the forwarding of event reports, for example, by suspending and resuming their forwarding; d)the ability for an external managing system to modify the conditions used in the reporting of events; e)the ability to designate a backup location to which event reports can be sent if the primary location is not available. 7. Model for the event report management function 7.1 General The functional requirements noted above, relating to the behaviour of systems, can be reduced to a basic requirement on the behaviour of a system. This is the ability to specify conditions to be satisfied by a Potential Event Report emitted by a particular managed object in order to be sent to specified destinations. 7.2 Event report management model The event report management model describes the conceptual components that provide for remote event reporting and local processing of potential event reports. The model also describes the control messages, event reporting messages and retrieval messages. The conceptual event pre-processing function receives local notifications and forms the potential event reports. Conceptually these potential event reports are distributed to all Event Forwarding Discriminators that are contained within the local open system. A potential event report is perceived as a discriminator input object for the purposes of discrimination by the Event Forwarding Discriminators only and is not visible from outside the local system. The event forwarding discriminator is used to determine which event reports are to be forwarded to a particular destination during specified time periods. It may also be used to specify the mode (confirmed or non-confirmed) for forwarding events. Each event forwarding discriminator may contain a scheduling capability determining the intervals during which event reports will be selected for forwarding. Each event forwarding discriminator contains a discriminator construct which specifies the characteristics a potential event report must satisfy in order to be forwarded. Event reports that have been selected are forwarded to the destination as soon as possible. The event forwarding discriminator is itself a managed object and can therefore emit notifications. These notifications are processed as potential event reports by all event forwarding discriminators including the one that generated the notification. Figure 1 is a schematic representation of the components involved in generating, processing and reporting events. 7.2.1Event reporting management function Event reporting management allows an Open System to establish and control the discrimination and the forwarding of event reports to other Open Systems. Event reports are generated as a result of the notification that an event has occurred, e.g. a threshold violation or a change in configuration status. The event forwarding management function provides the capability of identifying the destinations to which selected event reports are to be sent. Event reporting management provides the means by which discrimination and forwarding can be initiated, terminated, suspended, or resumed and through which the attributes of the event forwarding discriminator can be read and modified. The event reporting management function provides the capability for setting-up a long term event reporting relationship between two open systems. While the Event Forwarding Discriminator is in the Unlocked state, the reporting open system forwards event reports to the specified destination given that the operational state is enabled and any schedule is not "off-duty". FIGURE 1 Event report management model Event reporting management comprises the following: - Initiation of event forwarding; - Termination of event forwarding; - Suspension of event forwarding; - Resumption of event forwarding; - Modification of event forwarding conditions; - Retrieval of event forwarding conditions. 8. Generic definitions 8.1 Managed Objects This Specification provides generic definitions of managed objects, attributes and packages associated with the discriminator and the event forwarding discriminator. 8.1.1The discriminator The basic superclass is the discriminator object class. The discriminator may be specialized into subclasses to specify management support object classes that allow the control of various system management functions. The discriminator provides for specification of conditions that shall be satisfied prior to allowing the management operation or notification associated with the discriminator input object to proceed. Some of the conditions are common to all subclasses of the discriminator; others are unique to the specific discriminator subclass. The conditions specified by the discriminator are - identification of a scheduling packages that determine when discriminator processing will occur; - the criteria for discrimination; - the administrative and operational state of the discriminator; - those specific to a particular discriminator object subclass. 8.1.1.1 Management of discriminators The discriminator is a managed object that allows a managing system to exercise control over the management operations that may be accepted and the event reports that may be forwarded, by a managed system. Discriminators can, therefore, be created, deleted, read and modified. In addition, the activity of discriminators can be suspended and resumed by means of manipulating their administrative states. When a discriminator is created, the discriminator shall generate an object creation notification. This notification shall be processed by the newly created discriminator. Each discriminator has an operational state and an administrative state. The operational states defined for the discriminator are those defined in CCITT Rec. X.731 | ISO/IEC 10164-2. The administrative state attribute defined for the discriminator is a subset of those defined in CCITT Rec. X.731 | ISO/IEC 10164-2. A change in the operational state shall be reported using the state change notification. This notification shall be processed by the affected discriminator before it enters the disabled state or after it enters the enabled state, as appropriate. The operational states defined for the discriminator are enabled and disabled. For the discriminator, the enabled state is the state in which the discriminator can process discriminator input objects (unless administratively prohibited from doing so or if any schedule is "off-duty"); in the disabled state the discriminator does not process any discriminator input objects. The administrative states defined for the discriminator are locked and unlocked. State changes in the administrative state of the discriminator are the result of intervention by a managing system or local administrative activity. The precise semantics of these states are defined as part of the class definition of subclasses of discriminator. The managing system may lock or unlock the discriminator. Whenever the administrative state of the discriminator changes, the discriminator shall generate a notification. When the state is changed from unlocked to locked and the discriminator is in the enabled state the discriminator shall not change state until a state change notification indicating the state change has been processed by the discriminator. When the discriminator state is changed from locked to unlocked the discriminator shall generate a notification indicating the state change immediately after having entered the Unlocked state. The state change from unlocked to locked is assumed to occur instantaneously and without disrupting the processing of a current potential event report. When the discriminator is deleted, the discriminator shall generate an object deletion notification and process that notification prior to deletion.If the discriminator is in the unlocked and enabled states it shall process the discriminator input object indicating the object deletion prior to its deletion. In addition to manipulating the state of a discriminator, a manager can change the time during which a discriminator will be available and change the conditions under which tests on an discriminator input object can evaluate to TRUE. These changes are defined to occur in such a way so as not to impact a discriminator input object that is currently being processed. The availability status shall be present when a manager can change the time during which the discriminator is available. The availability status attribute value for the discriminator is a subset of those defined in CCITT Rec. X.731 | ISO/IEC 10164-1. If discrimination is available and the scheduling attributes are changed so that the current time is not within the "available" time range, the availability status becomes "off-duty". This notification shall be processed by the affected event forwarding discriminator before it enters the off- duty status. No state change notifications are generated for this attribute. Changes to values of attributes other than administrative state, operational state and, if present, availability status shall be reported using the attribute value change notification. Open systems may be configured with a mechanism for forwarding events when no manageable Event forwarding discriminator is available (Annex B). This mechanism is outside the scope of this standard. 8.1.1.2 Normal operation of discriminators A discriminator contains a discriminator construct that is a filtering mechanism which acts on attributes of discriminator input objects. A discriminator construct is a set of one or more assertions about the presence or values of attributes. If the discriminator construct involves more than one assertion, the assertions are grouped together using logical operators. The discriminator construct can specify tests for equality and inequality conditions of attributes, test for the presence of attributes and the negation of any of these conditions. Multiple conditions may be combined by means of "AND" or "OR" operators. When an attribute for which an attribute value assertion is present in the discriminator construct, is absent in a discriminator input object to be tested, the result of the test on that attribute value assertion shall be evaluated as FALSE. An empty discriminator construct will evaluate to TRUE for any set of discriminator input object attributes. For the discriminator, if the discriminator construct evaluates to TRUE, the discriminator is in the Unlocked and Enabled states, and the availability status, if present, is not "off-duty", then the discriminator input object passes the discriminator and will be processed further (the processing to be performed depends on the precise semantics of the discriminator subclass). If the discriminator is in the Locked or Disabled states or has the "off-duty" availability status (if present), then discriminator input objects will not be processed by that discriminator. If the discriminator is created such that a manager can not change the time when it is available, then the discriminator is assumed to be always available. 8.1.1.3 Discriminator attributes The following mandatory attributes are defined for the discriminator object class. 8.1.1.3.1 Discriminator Id This attribute is used to uniquely identify the instance of a discriminator. 8.1.1.3.2 Discriminator construct This attribute specifies tests on the information that is to be processed by the discriminator. 8.1.1.3.3 Administrative state This attribute represents the administrative state of the discriminator. The following administrative states are defined. a)unlocked - processing of the information by the discriminator is permitted by a managing system; b)locked - processing of the information by the discriminator is prohibited by a managing system. 8.1.1.3.4 Operational state This attribute represents the operational capability of the discriminator to perform its function. The following operational states are defined. a)enabled - the discriminator is operational; b)disabled - the discriminator is inoperable. 8.1.1.4 Discriminator notifications The following mandatory notifications are defined for the discriminator object class a)state change; b)attribute value change; c)object creation; d)object deletion. 8.1.1.5 Scheduling packages To accommodate various levels of complexity in scheduling event reporting activity periods, conditional packages that are related to scheduling are defined for the event forwarding discriminator. Scheduling packages provide discriminators with the ability to automatically switch between their reporting-on and reporting-off conditions. If no scheduling package is present in a discriminator, it is always in reporting-on condition. 8.1.1.5.1 Availability status package This conditional package shall be present if any of the other scheduling related packages are instantiated. This package contains the following attribute. a)Availability status. This attribute reflects the availability status of the managed object. When the resource has been made unavailable in accordance with a predetermined time schedule its value will be "Off Duty". The attribute is read-only. The value on creation is determined by the scheduling parameters specified and the status of the resource. The required value set for this attribute in this package is "Off Duty". No state change notifications are generated for this attribute. 8.1.1.5.2 Duration package The duration package provides the ability to automatically control the time that a managed object starts and stops functioning through the use of the start time and stop time attributes: a)Start time This attribute defines the date and time at which an unlocked and enabled managed object starts functioning. If the value of the Start Time attribute is not specified in the create request, its value defaults to the time of creation of the managed object and thus causing it to function immediately. A change in the Start time attribute results in an attribute value change notification. b)Stop time This attribute defines the date and time at which a managed object stops functioning. If the value of the Stop Time attribute is not specified in the create request, its value defaults to "continuous operation". Continuous operation is represented by a null value for the stop time. A change in the stop time attribute results in an attribute value change notification. 8.1.1.5.3 Daily scheduling package The daily scheduling conditional package provides the capability of scheduling operability of the discriminator with a periodicity of 24 hours. The scheduling attributes and their associated defaults, are defined below. a)Intervals of day This attribute defines the list of time intervals (interval-start and interval-end times of day) for which the discriminators will exhibit the "on-duty" condition. During excluded intervals the discriminator exhibits the off-duty" condition. If not specified in the create request, the value of this component defaults to a single interval encompassing the entire 24 hour period of a day. 8.1.1.5.4 Weekly scheduling package The weekly scheduling conditional package provides the capability of scheduling operability of the discriminator with a periodicity of one week. The scheduling attributes and their associated defaults, are defined below. a)Week mask This structured attribute defines a set of mask components, each specifying a set of time intervals on a 24 hour time-of-day clock, pertaining to selected days of the week. The weekMask attribute defaults to a scheduling criteria of "always on" at discriminator creation. The components of each mask are defined below. - Days of week; This component defines the days of the week on which the discriminator's scheduling mechanism will allow the discriminator to have intervals during which processing of a discriminator may occur. This component, if not present in a create, will default to all seven days of the week. - Intervals of day. This component defines the list of time intervals (interval- start and interval-end times of day) for which the discriminator will exhibit the "on-duty" condition, if the current day is one of the days that is selected within the corresponding daysOfWeek. During excluded intervals the discriminator exhibits the off-duty" condition. If not specified in the create request, the value of this component defaults to a single interval encompassing the entire 24 hour period of a day. 8.1.1.5.5 External scheduler scheduling package The external scheduler scheduling conditional package provides the capability of scheduling event reporting based on a schedule defined in an external scheduler managed object. The discriminators' on-duty" and "off-duty" conditions will be changed in accordance with the scheduling characteristics specified by a scheduler managed object. The scheduling attribute is defined below. a)Scheduler name This attribute specifies the name of the schedular managed object that is related to the discriminators. This relationship implies that the discriminator's "on-duty" and "off-duty" conditions will be scheduled by the external scheduler. This attribute is a read- only attribute. 8.1.2Event forwarding discriminator The event forwarding discriminator allows specification of conditions to be satisfied by potential event reports related to managed objects before the event report is forwarded to a particular destination(s). The event forwarding discriminator is a subclass of the discriminator object class. 8.1.2.1 Event forwarding discriminator attributes In addition to the attributes inherited from the discriminator, the event forwarding discriminator has the following attributes. a)Destination The destination attribute identifies the destination(s) to which the discriminator forwards event reports. The destination may be a single application entity title or multiple application entity titles. 8.1.2.2 Backup destination package This package has two attributes which specify the backup destinations and the active destination. This package is present when it is required to provide a backup for the destination. 8.1.2.2.1 Backup destination list The backup destination list attribute is an ordered list of application entity titles. The application entities identified in the backup destination list are AE Titles designated to be used as event destination if the destination specified by the destination attribute fails. Detection of AE failures and switch-back policy is a local matter. The application entity that appears earlier in the list has priority over those following it in the list. This attribute is not used when the destination attribute has multiple application entity titles. 8.1.2.2.2 Active destination The active destination attribute is specified as a single application entity title. The active destination attribute identifies the Application Entity to which events are currently forwarded by the discriminator. This attribute is read-only and its value is assigned as a result of system operation using the Destination or Backup destination list attributes. 8.1.2.3 Mode package This package has one attribute and is present when it is required if the mode for reporting events is to be specified by the managing system. a)Confirmed mode This attribute has two values: confirmed and non-confirmed. Its value shall only be set at object creation time. If the attribute is not specified in the request, the mode to be used for sending event reports is a local matter. All potential event reports that are forwarded by the event forwarding discriminator with the mode set to confirmed, are sent as confirmed event reports; if the mode is set to non-confirmed, they are sent as non-confirmed reports. 8.1.2.4 Event forwarding discriminator behaviour In addition to the behaviour inherited from the discriminator object class, the event forwarding discriminator exhibits the following behaviour. Tests on the following attributes of a potential event report may be specified by the discriminator construct in the event forwarding discriminator: - Managed object class; - Managed object instance; - Event type; - Event type specific attributes, e.g., for fault related events such attributes as - Severity; - Backed Up Status; - Probable Cause. In order to perform these tests the abstract syntax used must be known to the discriminator. If the discriminator construct for a potential event report evaluates to TRUE and the event forwarding discriminator is in the Unlocked and Enabled state and does not exhibit the "off-duty" availability status then an event report is directed to the specified destination. 8.2 Imported generic definitions The following generic definitions used in this Specification are defined in CCITT Rec. X.731 | ISO/IEC 10164-2 and CCITT Rec. X.730 | ISO/IEC 10164-1. - administrative state; - operational state; - availability status; - state change notification; - object creation notification; - object deletion notification; - attribute value change notification. 9. Service definitions This specification does not define any services. The use of services defined in other functions is described below. 9.1 Introduction The information needs and management control requirements between systems may change with time and changes in the management or communications environment. It is, therefore, necessary to provide a mechanism for administering OSI management services. It is considered that systems should have the capability of modifying the operation of Event forwarding discriminators in other systems. In particular, the operations required, that can be applied to each instance of an event forwarding discriminator, are - creation of a discriminator; - deletion of a discriminator; - modification of discriminator attributes; - suspension of the activity of the discriminator; and - resumption of the discriminators activity. These operations will thus provide a means for a system to initiate/terminate/suspend/resume event reporting for particular managed objects. It is also considered necessary that systems be able to modify and read any of the attributes of a particular event forwarding discriminator. The operational state attribute, active destination attribute, confirmed mode attribute and availability status attribute are read only and cannot be changed by management. 9.2 Initiation of event report forwarding The PT-CREATE service defined in CCITT Rec. X.730 | ISO/IEC 10164-1 is used to allow one open system to request that another open system create an event forwarding discriminator, thereby requesting that new or additional event forwarding controls be imposed. When an event forwarding discriminator is created it generates an object creation notification indicating its administrative, operational states and if present, availability status and confirmed mode. Whether or not this notification will result in the transmission of an event report, depends on the administrative and operational states, availability status and discriminator construct of the discriminators processing the potential event report. The semantics of the discriminator attributes are defined in clause 8. The attributes and defaults for the create operation are specified below. Discriminator construct: this attribute specifies the test conditions which will be used by the event forwarding discriminator in testing potential event reports. If no value is specified for this parameter in the incoming request then an empty discriminator construct will be defined; i.e. a discriminator construct that evaluates to TRUE for all potential event reports. An example of the value notation for the discriminator construct is shown in Annex B. Discriminator Id: If the value is not supplied, the managing system shall assign a value and return it in the response. Destination: this attribute identifies the destination to which event reports that have passed the test conditions will be sent. If no destination is specified in the request, then the discriminator is created with the destination defaulted to the AE Title of the invoker. Administrative state: this attribute specifies the administrative state in which the discriminator is to be created. The discriminator administrative state is a subset of the administrative state defined in CCITT Rec. X.731 | ISO/IEC 10164-2. The discriminator may be created in an Unlocked or a Locked state. If no administrative state is specified, the Unlocked state is assumed. Operational state: this attribute specifies the operational state of the discriminator. The discriminator operational state are those defined for the operational state in CCITT Rec. X.731 | ISO/IEC 10164-2. The discriminator may be in the Enabled or a Disabled state. The operational state shall not be specified as part of the create request, but shall be returned in the response and will reflect the actual state of the created event forwarding discriminator. 9.3 Termination of event report forwarding The PT-DELETE service defined in CCITT Rec. X.730 | ISO/IEC 10164-1 is used to allow one open system to request that another open system delete one or more event forwarding discriminators, thereby requesting that some event forwarding controls be terminated. When an event forwarding discriminator is deleted it generates an object deletion notification. Whether or not this notification will result in the transmission of an event report, depends on the administrative and operational states and discriminator construct of the event forwarding discriminators processing the potential event report. The discriminator shall not be deleted until it has either processed its deletion event report or been prohibited from doing so by being in a locked or disabled state. 9.4 Event forwarding discriminator modification, suspension and resumption The PT-SET service defined in CCITT Rec. X.730 | ISO/IEC 10164-1 is used to allow one open system to request that another open system change the administrative state or other settable attribute of the event forwarding discriminator. When the administrative state is changed to locked, event forwarding will be suspended; when the administrative state is changed to unlocked and the operational state is enabled, event forwarding will be resumed. When the state of an event forwarding discriminator is changed it generates a state change notification indicating its new and old values for the state. Whether or not this notification will result in the transmission of an event report, depends on the administrative and operational states and discriminator construct and if present the availability status of the discriminators processing the potential event report. An event forwarding discriminator shall not enter the locked state until it has either processed the potential event report resulting from its state change or been prohibited from doing so by being in a disabled or off-duty state. When the other non-state attributes of an event forwarding discriminator are changed, it shall generate an attribute change notification indicating the attributes that have changed. Whether or not this notification will result in the transmission of an event report, depends on the administrative and operational states and discriminator construct of the discriminators processing the potential event report. An event forwarding discriminator shall not change the value of its destination attribute until it has either processed the potential event report resulting from the destination change, or been prohibited from doing so by being in a locked, disabled or off-duty state. 9.5 Retrieval of event forwarding discriminator attributes This Specification uses the PT-GET service defined in CCITT Rec. X.730 | ISO/IEC 10164-1 for retrieving the attributes of the event forwarding discriminator. 10. Functional units Two functional units are defined in this Specification for the management of event forwarding discriminators. a)event report management functional unit; b)monitor event report management functional unit. The monitor event report management functional unit requires the support of PT-GET service for instances of the event forwarding discriminator or its subclasses. The event report management functional unit requires the support of PT-GET, PT- SET, PT-CREATE and PT-DELETE, object creation reporting, object deletion reporting, attribute value change reporting and state change reporting services for instances of the event forwarding discriminator and its subclasses. 11. Protocol 11.1 Elements of procedure This specification makes use of the elements of procedure defined for the services described in clause 9 of this Specification. No additional elements of procedure are defined in this Specification. 11.2 Abstract syntax 11.2.1 Objects This Specification references the following support objects whose ASN.1 value notation is specified in CCITT Rec. X.721 | ISO/IEC 10165-2. a)eventForwardingDiscriminator. b)discriminator 11.2.2 Attributes This Specification references the following attributes, associated with the objects specified in 11.2.1, whose abstract syntax is defined in CCITT Rec. X.731 | ISO/IEC 10165-2. a)activeDestination; b)administrativeState; c)availabilityStatus; d)backUpDestinationList; e)confirmedMode; f)destination; g)discriminatorConstruct; h)discriminatorId; i)intervalsOfDay; j)operationalState; k)schedulerName; l)startTime; m)stopTime; n)weekMask. 11.2.3 Notifications This Specification references the following events defined in CCITT Rec. X.730 | ISO/IEC 10164-1. a)attribute value change notification; b)object creation notification; c)object deletion notification; This Specification references the following events defined in CCITT Rec. X.731|ISO/IEC 10164-2. d)state change notification. 11.3 Negotiation of functional units This Specification assigns the following object identifier value {joint-iso-ccitt ms(9) function (2) part5(5) functionalUnitPackage(1)} as a value of the ASN.1 type FunctionalUnitPackageId defined in CCITT Rec. X.701 | ISO/IEC 10040 to use for negotiating the the following functional units. 0 event report management functional unit 1 monitor event report management functional unit where the number identifies the bit positions in the BIT STRING assigned to the functional units, and the names referencing the functional units as defined in clause 10. Within the Systems management application context, the mechanism for negotiating the functional units is described by CCITT Rec. X.701| ISO/IEC 10040. NOTE- The requirement to negotiate functional units is specified by the application context. 12. Relationship with other functions The event report management function uses the services defined in CCITT Rec. X.731 | ISO/IEC 10164-2 for the notification of state changes and the services defined in CCITT Rec. X.730 | ISO/IEC 10164-1 for the creation and deletion of discriminators, the retrieval of discriminator attributes, and the notification of attribute changes and object creations and deletions. The relationship with the log control function in CCITT Rec. X.735 | ISO/IEC 10164-6 is shown in Figure 2 below. FIGURE 2 Relationship between event report and log management models 13. Conformance There are two conformance classes: general conformance class and dependent conformance class. A system claiming to implement the elements of procedure for system management services referenced by this Specification shall comply with the requirements for either the general or the dependent conformance class as defined in the following clauses. The supplier of the implementation shall state the class to which the conformance is claimed. 13.1 General conformance class requirements A system claiming general conformance shall support this function for all managed object classes that import the management information defined by this Specification. NOTE- This is applicable to any subclass of the management support object classes defined in this Specification. 13.1.1 Static conformance The system shall a)support the role of manager or agent or both with respect to the event report management functional unit; b)support the transfer syntax derived from the encoding rules specified in CCITT Rec. X.209 | ISO/IEC 8825 and named {joint-iso-ccitt asn1(1) basicEncoding(1)}, for the purpose of generating and interpreting the MAPDUs, defined by the abstract data types referenced in 11.2.2 and 11.2.3 of this Specification; c)when acting in the agent role, support one or more instances of the event forwarding discriminator managed object class or any of its subclasses. 13.1.2 Dynamic conformance The system shall, in the role(s) for which conformance is claimed a) support the elements of procedure defined in - CCITT Rec.X.730 | ISO/IEC 10164-1 for the PT-GET, PT- CREATE, PT-DELETE, PT-SET, Object creation reporting, Object deletion reporting and Attribute change reporting services; - CCITT Rec.X.731 | ISO/IEC 10164-2 for the State change reporting service. 13.2 Dependent conformance class requirements 13.2.1 Static conformance The system shall a)supply a System Conformance Statement which identifies the standardized use of this Specification; b)support the transfer syntax derived from the encoding rules specified in CCITT Rec. X.209 | ISO/IEC 8825 and named {joint-iso-ccitt asn1(1) basicEncoding(1)}, for the purpose of generating and interpreting the MAPDUs, defined by the abstract data types referenced in 11.2.3 of this Specification, as required by a standardized use of this systems management function; c)when acting in the agent role, support one or more instances of the Event forwarding discriminator managed object class or all subclasses. 13.2.2 Dynamic conformance The system shall support the elements of procedure referenced by this Specification, as required by a standardized use of this system management function. 13.3 Conformance to support managed object definitions The event report forwarding discriminator objects supported by the open system shall comply with the behaviour specified in clause 8 and the syntax specified in CCITT Rec. X.721 | ISO/IEC 10165-2. For minimum conformance to the event report management function an event forwarding discriminator containing the all-pass form of discriminator construct shall be supported. Annex A (This Annex does not form an integral part of this Specification) Example value notation for the discriminator construct This annex presents an example of the value notation for the discriminator construct. The condition to be encoded is given below. (objectClass equal to protocolEntity) and (entityID starts with "123") and ( (severity not Equal to minor) or (badPduCount greater than or equal to 20)) where bold face words are operators and plain type words are variables. The following value notation of the value test-filter represents this condition. test-filter CMISFilter ::= and {item equality {objectClass, Object-Class protocolEntity}, item substrings {initialstring {entityID, PrintableString "123"}}, or { not item equality {severity,Severity minor}, item lessOrEqual {badPduCount, INTEGER 20}}} where objectClass, entityID, severity and badPduCount are value references to AttributeId of type OBJECT IDENTIFIER, protocol entity is a value reference to ObjectClass of type OBJECT IDENTIFIER and minor is a value reference to Severity of type ENUMERATED. Annex B (This Annex does not form an integral part of this Specification) Event forwarding using local mechanism This annex presents a mechanism for forwarding events where no manageable event forwarding discriminator is available. This mechanism is a local issue. The figure below illustrates this mechanism. FIGURE Local event selection mechanism Annex C (This Annex does not form an integral part of this Specification) Considerations for System Implementation Conformance Statement The following is an example of the information the implementor may specify when defining conformance to this systems management function. a)the behavioural options implemented for the event forwarding managed object class; b)the range of all attribute values that can be supported by the event forwarding discriminator; c)the number of each type of event forwarding discriminator that can be supported by the implementation. Number Discriminator Type All-pass and destination configurable Object Class and instance selection and destination configurable Event Type Selection and destination configurable Event Type, Object Class and Instance Selection and destination configurable Arbitrary Selection Criteria _______________________________ 1Recommendation X.700 and ISO/IEC 7498-4: Information technology - Open systems interconnection - Management framework were developed in close collaboration and are technically identical.