network management principles and practice mani subramanian 2nd edition appendix a

Appendix A. OSI Network and System Management

In Chapter 3 we introduced OSI management, which uses the CommonManagement Information Protocol (CMIP). Then we discussed itsapplication to the Telecommunications Management Network (TMN) inChapter 10. We will cover the basic principles of OSI network andsystem management here. We will describe the management of networkresources, including both network elements and the network thatconnects them. In conjunction with TMN, OSI also addressesmanagement layers above the networknamely, service and businessmanagement. You may need to review the basic foundations of OSI inChapter 3 to follow the material in this appendix.

In contrast to the SNMP management standard, which was intentionallykept simple in concept and implementation, the OSI managementstandard was developed to be broad and flexible and is based on object-oriented technology. Hence, it turned out to be complex, difficult tounderstand, and expensive to implement, which is why it has beensparsely deployed. However, the recent availability of object-orientedtechnology tools and hardware resources, combined with the need fortelecommunication management using TMN, have eliminated itsimplementation impediments.

We will present the complex subject of OSI management by using asimple, easy-to-follow approach. We will compare OSI management toSNMP management wherever appropriate, which will also help youbetter understand the former.

Network Management: Principles and Practice > Review of Information ... file:///D:/TC Engg/8th Semester/TMN/Book Network Management Princ...

1 of 1 23-Sep-15 8:14 PM

Section A.1. OSI Management Standards

Two standards bodies, the International Standards Organization (ISO)and the International Telecommunications Union (ITU), jointly workedon developing standards for network management. Thus, in Table A.1listing of the various standards documents, two numbers are associatedwith each entryan ISO designation and an ITU designation (X-series).

Table A.1. OSI Systems Management Standards Guide

ISO ITU TOPIC

7498-4 X.700 OSI Basic Reference Model Part 4:Management Framework

10040 X.701 Systems Management Overview

9595 X.710 Common Management Information ServiceDefinition

9596-1

9596-2 X.711 Common Management InformationProtocol

10165-1 X.720 SMI: Management Information Model

10165-2 X.721 SMI: Definition of ManagementInformation

10165-4 X.722 SMI: Guidelines for the Definition ofManaged Objects

10165-5 X.723 SMI: Generic Management Information

10165-6 X.724 SMI: Requirements and Guidelines for ICSProforma associated with ManagementInformation

10165-7 X.725 SMI: General Relationship Model

10165-9 X.727 SMI: System Management ProtocolMachine Managed Objects

10164-110164-17

X.730-X.751 Systems Management (specifications forvarious functions and attributes)


1 of 2 23-Sep-15 8:14 PM

Only a partial list is given in Table A.1; for a more complete list see[Raman, 1998]. The X.700 series covers the general managementframework and a systems management overview. The X.710 seriescovers the communication protocol and service. The Structure ofManagement Information (SMI) is specified in the X.720 series. Anextensive series of documents ranging from X.730 to X.751 addressesnumerous application functions.


2 of 2 23-Sep-15 8:14 PM

Section A.2. System Overview

The OSI management system concept is similar to that of SNMPmanagement. After introducing the general concept in Chapter 3, wediscussed SNMP management in Chapter 4. Figure A.1 shows the OSImanagement model, defined in ISO 10040/X.701. The managing systemconsists of an entity playing the manager role and applications thatperform the various functions. The managed system comprises theagent role function and managed objects. The managing systemperforms various operations, such as get and set, which we covered indiscussing SNMP management, on a managed system and receivesresponses. Notification is similar to the trap in SNMP, but it has abroader role in OSI management. The role of the agent is to performthe operations on managed objects and receive notifications from them.This function is similar to SNMP agent operations on network elements.The communication protocol between the managing system and themanaged system is the CMIP, similar to SNMP in SNMP management.

Figure A.1. OSI Management Model

[View full size image]

OSI management differs from SNMP management in the way themanaged object is defined. In OSI the managed object is objectoriented, in contrast to the scalar representation of the managed objectin SNMP. We observed the difference between the two perspectives inChapter 3 (Figure 3.9). A managed object representation in OSI isshown in Figure A.2. As OSI is object oriented, the resources arerepresented as managed object classes. The internal characteristicsof a managed object are hidden from the external view, and arespecified as attributes at the object boundary. The inner behavior of


1 of 4 23-Sep-15 8:14 PM

the managed object caused by external operations is reflected aschanges in attributes and is sent out as notifications. The operationssent out by the management system as requests requiring responsesare part of operations and generate responses by the managed system.

Figure A.2. OSI Managed Object

The OSI management system architecture is shown in Figure A.3. Itconsists of seven messages representing seven services, calledCommon Management Information Service Elements (CMISEs).The communication protocol used by CMISE is the CommonManagement Information Protocol (CMIP).

Figure A.3. OSI Management System Architecture


2 of 4 23-Sep-15 8:14 PM

All but one, M-EVENT-REPORT, are generated by the manager and arerepresented as solid lines in the OSI manager application layer. They areshown as dashed lines in the OSI agent application layer. The M-EVENT-REPORT is shown as a solid line in the agent layer and as a dashed linein the manager layer. All messages are represented by double arrows inboth the manager and the agent layers because messages may elicit orrequire either response(s) or confirmation. Notice that this approach isdifferent from that of SNMP management, in which all messages areunidirectional.

Messages are generated by application processes and are transferred tothe presentation layer via an application entity sublayer in theapplication layer (more about this later). The other upper layers of theOSI Reference Model consist of presentation and session layers asdescribed in ITU Recommendations X.216 and X.226 for the former andX.215 and X.225 for the latter.

The lower layers of the model may be either connection oriented orconnectionless. Numerous choices in the set of lower-layer protocols areavailable. Figure A.3 shows an example of a set based on X.25 [ITURecommendation X.25 Protocol, October 1996]. Various profilescan be implemented, including the Internet profile [Raman, 1998].


3 of 4 23-Sep-15 8:14 PM

The M-GET service comprises request and response messages. Theyare equivalent to get-request and get-response messages in SNMP. Theget-next-request could also be included in that the OSI get service is fora management object class and thus includes SNMP multiple scalarmanaged objects. The M-GET requires a confirmation (response) fromthe agent. The M-SET service enables setting up attribute values in themanaged object and may or may not require confirmation. TheM-ACTION service is used to perform operations in the managedobject, and confirmation is optional. An M-GET Request message maybe canceled by using the M-CANCEL-GET message, which requiresconfirmation from the agent. The M-EVENT-REPORT is akin to the trapmessage in SNMP, but it has a much broader effect than the few genericalarms in SNMP.

The M-CREATE and M-DELETE services are used to create and deleteobject classes, for which there is no equivalent in SNMP. A close analogyin SNMP for these services is creation and deletion of conceptual rowsfor tabular objects. Both these OSI messages require confirmation fromthe agent.


4 of 4 23-Sep-15 8:14 PM

Section A.3. Organization Model

We explained the OSI organization model in Chapter 3. It comprisesthe manager system, the agent system, and managed objects. A systemcan perform the dual role of a manager and an agent, switching fromone role to the other dynamically. This approach is significantly differentfrom that of SNMP management, in which the two functions can coexistbut are distinct processes.

In the OSI management specifications, managed objects are assigned togroups called domains. Such grouping can be done either on anorganizational basis or on an administrative basis. When anorganizational domain is formed, it consists of a set of managed objectsbased on functional criteria, such as fault and performancemanagement. The organizational domain may also recognizeorganizational considerations such as common policies and procedures.

Administrative authority is the basis for an administrative grouping. Itdetermines the creation of and interaction between domains. Anadministrative grouping may comprise organizational domains.


1 of 1 23-Sep-15 8:14 PM

Section A.4. Information Model

The OSI information model is based on the abstraction of information onthe managed object as seen across the boundary of the managed objectby a manager system. (See Figures 3.9(b) and A.2 on the perspectiveof a managed object.) The schema representing the managed object isused by the manager system and the management agent system tocommunicate with each other as in SNMP management. Again, the OSImanagement information model is object oriented and in that regarddiffers from the SNMP management information model, which is scalarbased. The information model deals with the SMI, managed objects andobject classes, and management information trees.

The definition of managed objects, syntax based on ASN.1, and thenaming convention in the OSI SMI are similar in many ways to theSNMP SMI that we covered in Section 4.7.2. However, because of OSISMIs object-oriented approach, they differ in content from those in theSNMP SMI.

The concept of managed objects in OSI SMI refers to a group of objectshaving similar properties, defined as a managed object class. We canloosely compare this type of grouping to grouping of managed objects inthe SNMP model. However, a managed object class is more than a groupof SNMP-managed objects. It is a collection of objects whose attributesand behavior are similar, and it supports a common set of operationsand notifications.

A managed object class can be created from other managed objectclasses, called packages, as shown in Figure A.4. It comprises onemandatory package and multiple conditional packages. A managedclass in this structure has the properties associated with the mandatorypackage and may include properties of conditional packages. Forexample, a transport class object class would include an OSI transportclass 4, applicable to both connection-oriented and connectionlesscases, but would include a transport class 0 or 2, only if it is connectionoriented. We will address the method of defining the properties of anobject class and a package in Section A.4.2.


1 of 10 23-Sep-15 8:13 PM

Figure A.4. Structure of a Managed Object Class

Managed object classes are obtained by using an inheritance tree, as wewill show in Section A.4.3. There are three types of trees in OSImanagement. Besides the inheritance tree, there is a naming tree and aregistration tree, which we will discuss in Section A.4.4. We will coverthe template for specifying managed objects in Section A.4.5.

A managed object class is a group of managed objects withcommon attributes and behavior, can be subjected to similar operations,and emit a set of similar notifications, as previously shown in FigureA.1. The properties of a managed object are defined by a templatespecifying these characteristics. A managed object is an instance of amanaged object class with defined values in the template. For example,a hub can be defined as a managed object class, with each hub havingdifferent attribute values (e.g., manufacturer, serial number, number ofports, etc.) as an instance of the hub-managed object class. As shownin Figure A.5, the hub is a managed object class having commonattributes and two specific hubs as two instances of it. Each instancehas different values for hub ID, vendor name, model number, and serialnumber. They are 10-Mbps Ethernet hubs (ifType=6) with 12 ports.

Figure A.5. Example of a Managed Object Class and Instances


2 of 10 23-Sep-15 8:13 PM

Let us now look at the properties (or characteristics) associated with themanaged object, which we covered briefly in Chapter 3. The propertiesof a managed object and object class are interdependent, as we willdemonstrate shortly.

Attributes and Attribute Group. Attributes of a managed objectinclude the data types and values associated with it. As discussed inChapter 3, the basic data types could be either simple or constructed.Unlike SNMP, OSI permits the use of a wider range of ASN.1 data types.For example, multiple values can be associated with attributes by usinga SET OF construct.

The value associated with an attribute could be either single- ormultiple-valued and is specified according to the syntax rule. The syntaxis specified in the ASN.1 language described in Chapter 3.

Attributes have access rules (e.g., read, write, and readwrite), whichare accomplished with operations. Attributes can also be created,deleted, or changed with operations.

Attributes can be grouped to form an attribute group. Because eachattribute value may have different syntax requirements, the attributegroup does not follow the syntactical rule.

Behavior. Behavior describes the internal actions of a managedobject. It is the glue that holds the properties of a managed object


3 of 10 23-Sep-15 8:13 PM

together. Behavior definitions can be specified with attributes andoperations and can include notifications. A change in the value of anattribute can generate notification. For example, in an environment withmultiple managers performing different functions, such as configurationand performance on a managed system, a change in the configurationmade by operations in a configuration management system may affectperformance. Hence, the performance management system needs to besent notifications. Another example is a package, in which two attributesmay be related in a constrained manner. In such a situation, anoperation on one attribute would cause the behavior to affect the otherattribute. We can picture the scenario where the set command is usedto administratively turn off an interface, which would behaviorally affectthe get command that is gathering data on that interface.

Operations. Operations perform actions on attributes and are alsocalled attribute-oriented operations. The attribute-orientedoperations are get, set, replace, add, and remove. We will describe thecommands and service entities associated with them when we considerthe CMIP service element in Section A.5. The get operation is a readfunction. The set operation is used to set a value of attributes. Thereplace operation replaces an attribute in a package with anyappropriate value or with a default value. The add and removeoperations perform an addition or removal of a member to or from a set(e.g., addition of a member to a group).

Three object-oriented operations are used to perform an operationon an objectaction, create, or delete. The action operation executes avalid process on the object. Typically, when more than just setting orreplacing an attribute value is involved, the action operation is used. Itcould be as complex as running a process that invokes the behavior,changes the attributes of a managed class, and invokes multipleresponses and notifications. SNMP management has no equivalentfunctions.

Notifications. Notifications are similar to traps in SNMP management.They are events generated by the management agent without acommand from the management system. However, it is broader inscope than the trap and is generated either by an external or by aninternal stimulant. As mentioned under object-oriented operations,notifications may be generated as a side effect. Alarms are alsogenerated and transmitted by managed objects via notifications. Datagenerated by notifications may also be logged for later utilization andnot sent out.


4 of 10 23-Sep-15 8:13 PM

We defined a managed object class as a group of managed objects withcommon properties. Another way of looking at it is that a managedobject is an instantiation of a managed object class, as previouslyshown in Figure A.5.

We can add attributes to a managed object class and derive a new class,called a subclass, which is similar to deriving a data subtype from a datatype. The subclass is derived from a superclass and inherits theproperties of the superclass. All the attributes of a superclass aremaintained by a subclass, and more are added to restrict the class ofobject instances in the subclass.

The three categories of inheritancesingle inheritance, multipleinheritance (polymorphic), and allomorphicare shown in FigureA.6, which represents a network containing routers and hubs. At the topof the managed objects is the ultimate superclass, top. Hub issuperclass of the switched and (regular) hubs. The 10-Mbps regular(non-switched) hub-managed object subclass is derived by singleinheritance from the hub superclass. Likewise, the switched 10-Mbpsand 100-Mbps hub subclasses are derived by single inheritance from theswitched hub superclass. A switched multirate hub that has both100-Mbps and 10-Mbps port speeds has polymorphic inheritance fromits superclasses at the 100-Mbps and 10-Mbps switched hubs. The10-Mbps uni-LAN hub is the class of hubs that can be configured only asa single LAN. In other words, it behaves as a regular hub and hence isallomorphic with the 10-Mbps regular hub-managed object class.

Figure A.6. Example of Inheritance


5 of 10 23-Sep-15 8:13 PM

Getting lost in OSI terminology and definitions of the varioushierarchical structuresliterally losing the forest for the treesis all tooeasy. So far we have talked about the development of managed objectclasses, which is done by using the inheritance tree. The objectinstances have to be uniquely identified, which is done by using thenaming tree. Once a managed object class has been developed andinstances have been given names, they have to be registered with acentral authority, which is done by using the registration tree, so thatthey can be universally used.

The Inheritance Tree. The inheritance tree defines the relationshipbetween subclasses and superclasses. Because the properties of asubclass are derived from a superclass, a subclass may be considered asubset or specialization of the superclass. We have discussed threecategories of inheritance. Single inheritance derives its properties from asingle superclass. Multiple inheritance of a subclass derives itsproperties from more than one superclass. Care must be taken indeveloping multiple inheritances so that no conflict exists between theproperties of the superclasses being used to derive the subclass. Thethird category is a special case, called allomorphism, in which a subclassderived from multiple superclasses takes on the properties of one of thesuperclasses. It may be considered as a pointer to a superclass.


6 of 10 23-Sep-15 8:13 PM

The Naming Tree. The naming tree is used in the naming of amanaged object, which is a specific instance of a managed object class,to give it a unique identification. This procedure is very similar to theOBJECT IDENTIFIER and DESCRIPTOR, using MIB, in SNMPmanagement.

Names are uniquely specified in terms of a superior or contextobject. Objects named in terms of another object are calledsubordinate objects and are contained in a superior object. Becausea subordinate object is contained in a superior object, the naming tree isalso called a containment tree.

An example of contained managed objects is shown in Figure A.7. Thetop level of the naming tree is the root. Here, system is the superiorobject and log, alarmRecord, and eventforwardingDiscriminator areobjects subordinate to it. Both log and alarmRecord are subordinatedobjects under the context name system.

Figure A.7. Example of Contained Managed Objects (X.720)

A managed object is identified by a name in the naming tree by eitherits absolute position in the naming tree with a global name, such asOSI or with respect to the context object either with a relativedistinguished name or a local distinguished name. Table A.2illustrates the naming convention for the example shown in Figure A.7.The local context name system is used here for illustration. Figure A.7and Table A.2 present the name attribute of the managed object andthe value of the type of that attribute. Thus, the local distinguished


7 of 10 23-Sep-15 8:13 PM

name for alarmRecord is the sequence of attributes starting with thecontext name system and is {logId = SMK, recordId = 5}, and therelative distinguished name is recordId = 5. The implication is that therelative distinguished name reflects the system context name. Noticethat the local distinguished name is a sequence of names and hence isbounded by braces, { }.

Table A.2. Relative DistinguishedNames Example

RelativeDistinguishedName

Local DistinguishedName

systemId =BDC

{ }

logId = SMK {logId = SMK}

recordId = 5 {logId = SMK,recordId = 5}

A subordinate object under a superior object in a naming tree does notimply that the managed object represented by the subordinate object iscontained in the superior object class. The inheritance relationshipbetween superclass and subclass is distinct from the name-bindingrelationship in the naming tree.

Registration Tree. The registration tree is used for officiallyregistering the managed object classes (from the inheritance tree),names of the managed objects (used in the naming tree), attributedefinitions, attribute groups, action types, notifications, and packages.The OSI management tree shown in Figure 3.8 has been extended topartially include the registration tree, as shown in Figure A.8. Themanaged classes, attributes, actions, notifications, and packagesdeveloped in the X.700/ISO 10165 series fall under the arc (node) smi,structure of management information. It is under the managementstandard ms node. The node smase (system management applicationservice entity) and cmip are the other two nodes under ms.

Figure A.8. OSI Registration Tree


8 of 10 23-Sep-15 8:13 PM

The technique used to specify managed objects in OSI managementuses templates and is referred to as Guidelines for Definition ofManaged Objects (GDMO). GDMO can be viewed as a set of formswith a list of properties that can be filled with values. See the OSI10165-4/ITU X.722 standard and Raman [1998] for a detaileddiscussion of GDMO.

An example of a managed object class using a template for a managedclass extracted from X.722 is shown in Figure A.9. The mnemonicname of the managed object class is lamp. The MANAGED OBJECTCLASS is the keyword that defines the managed object class.

Figure A.9. Example of the OSI Managed Object ClassTemplate


9 of 10 23-Sep-15 8:13 PM

The DERIVED CLASS identifies the source document and the relationshipto either a superclass or subclass. In the example, lamp is derived fromtop. It may not always be present, but at least the alternate managedobject class in the hierarchy should contain it. Thus, to trace thehierarchy of the managed object class, you may have to trace through asequence of templates. This procedure is similar to naming of childrendown the generations in some parts of the world, as in Tamil Nadu,India, where the author was born. The last name of the child(Subramanian in the case of the author) is the given name and the firstname is the fathers given name. Thus, to trace a name you have totrace through each generation of the family hierarchy.

The construct CHARACTERIZED BY identifies the mandatory packagesand properties. In this example, the lampPackage is the mandatorypackage, and the properties associated with it are part of its templatedefinition.

The CONDITIONAL PACKAGES define the optional packages included inthe managed object class. The intensityPackage is a conditional packageand is present only if the defined condition onresourceSupportsIntensity is satisfied.

The REGISTERED AS construct defines the official registered name ofthe managed object class. Here, lamp is defined in the registration treeunder gdmoPlusExamplesModule.


10 of 10 23-Sep-15 8:13 PM

Section A.5. Communication Model

We presented the high-level representation of the OSI communicationarchitecture in Section A.2 and Figure A.3. The manager and agentapplication processes use seven messages to communicate with eachother. The application process interfaces with the application entitysublayer that is above the presentation layer. The communicationprotocol used for intersystem communication is the CommonManagement Information Protocol (CMIP). The communication modeldeals with the application entity layer and the intersystem messageprotocol.

A management application, the System Management Application Process(SMAP) communicates with another management application byinvoking System Management Application Entity (SMAE), as shown inFigure A.10. The SMAE comprises several service entity modules. TheSystem Management Application Service Entity module (SMASE)services the five management applications: configuration, fault,performance, security, and accounting.

Figure A.10. OSI Network Communications Model


1 of 5 23-Sep-15 8:13 PM

The CMISE handles the communications function for SMASE, using theCMIP. The Association Control Service Element (ACSE) sets up andcoordinates the activities of setting up and releasing an association withthe application. Once the association has been set up, the data movefrom the CMISE to the remote system via the Remote Operation ServiceElement (ROSE). ROSE issues requests to a remote system and receivesresponses in an asynchronous mode. In other words, a request may beissued and followed by other requests and the responses correlated withthe corresponding requests.

Figure A.11 shows the interoperability of two applications in tworemote systems for the OSI network communication model shown inFigure A.10. Communication between SMASE entities exchangemanagement application protocol data units (MA PDU). CMIP PDUs areexchanged between CMISE entities.


2 of 5 23-Sep-15 8:13 PM

Figure A.11. OSI Interoperability Communication Model

Common Management Information Service Elements. Weintroduced the seven services (or messages) offered by CMISE inSection A.2. The CMISE model consists of two submodels. In the first,the manager sends a command to an agent and may expect one ormore responses from the agent, which is called operations. The secondsubmodel is concerned with an unsolicited message from an agent,which may expect confirmation from the manager, and is callednotifications.

The commands M-GET, M-SET, M-ACTION, M-CREATE, M-DELETE, andM-CANCEL-GET are operations. The event M-EVENT-REPORT belongs tonotifications. The M in all the operation and notification commandnames stands for management. The get, create, delete, and cancel-getoperations expect confirmations or responses, called confirmed services.A response may be multiple. For example, the GET command associatedwith a multiple management object class (called scope) could invokemultiple responses.

The operations set and action, as well as the notifications event-report,


3 of 5 23-Sep-15 8:13 PM

may or may not require responses or acknowledgements. They can beeither confirmed or unconfirmed services. The requirement forconfirmation depends on the type of operations or notifications, and thedata format should specify it. The CMISE services and CMIP operationvalues are listed in Table A.3, along with a brief description of eachservice.

Table A.3. CMISE Services and CMIP Operation Values

Service Operation ValueConfirmed/Unconfirmed

Description

M-EVENT-REPORT

0/1 Send notifications toanother open system

Multipleresponses

2 Not a CMISE service,but used with scope

M-GET 3 Retrieve attributes andvalues from managedobjects

M-SET 4/5 Set or modify attributes

M-ACTION 6/7 Initiate action in amanaged object

M-CREATE 8 Request an opensystem to create amanaged object

M-DELETE 9 Request an opensystem to deletemanaged objects

M-CANCEL-GET 10 Command to cancel apreviously sent M-GETservice

Common Management Information Protocol. The CMIP is thecommunication interface with the CMISE. It generates a PDU for amessage. The PDU format generated by CMIP is a modification of thegeneric ROSE PDU format, and is shown in Figure A.12. The invoke IDfield is the PDU identifier and is used in correlating the response. Theoperation value is determined by the appropriate operation/notificationfrom Table A.3. For example, the get operation will have an operationvalue of 3. The next two fields in the CMIP PDU are the managed objectclass and the managed object instance. The term base object is used in


4 of 5 23-Sep-15 8:13 PM

connection with retrieval of multiple objects associated with the scopeclause in which multiple objects could be retrieved using the getcommand by specifying a base object. The information field is a groupof fields describing operation-specific data.

Figure A.12. CMIP PDU


5 of 5 23-Sep-15 8:13 PM

Section A.6. Application Functions Management

OSI management had paid specific attention to the development ofmanagement applications (functional model), which motivateddevelopment of the rest of the OSI management models. Applicationfunctions management can be compartmentalized, as shown in FigureA.13, as management application functional areas, systemmanagement functions (SMFs), and CMISEs, which we discussed inSection A.5. Management application functions invoke SMFs, which inturn utilize the common management information services to executeapplications.

Figure A.13. Functions Management Model

[View full size image]


1 of 2 23-Sep-15 8:12 PM

The five system application functional areas are configuration, fault,performance, security, and accounting. They are represented as cloudsin Figure A.13 because the functional areas overlap. For example,packet loss in a network could be classified under both fault andperformance management. They may even use common managementfunctions. Hence, OSI specifications for SMFs are for primitive servicefunctions.

The SMFs are abstract specifications, more like requirements of thefunctions needed to implement the applications. They are shown underSMFs in Figure A.13. The purpose of most of the functions can beinferred from the title. The object management function, statemanagement function, and attributes for representing relationships areconcerned with the configuration of managed objects. The managementknowledge function exchanges information between systems.

The event report management function, log control function, alarmreporting function, test management function, and confidence anddiagnostic test categories are oriented toward fault administration andnotifications. The summarization function could be used for faultmanagement, as in trouble ticket administration, or for performancemanagement, as with statistics. This function preprocesses andcompresses the data prior to transmission.

The SMFs related to security management applications are the securityalarm reporting function, security audit trail function, and objects andattributes for access control. The account metering function andworkload monitoring function are oriented toward accountingmanagement. The scheduling function is a general SMF used to scheduleoperations.

The third compartment in Figure A.13 identifies the commonmanagement service elements invoked by the SMFs to perform thetasks. They are the seven CMISE services: M-EVENT-REPORT, M-GET,M-SET, M-ACTION, M-CREATE, M-DELETE, and M-CANCEL-GET.


2 of 2 23-Sep-15 8:12 PM

Summary

In this appendix we presented an overview of OSI management. Wediscussed the complexity and flexibility of object-oriented OSImanagement and compared it, where appropriate, to the simpler scalar-oriented SNMP/Internet management. OSI management is based on theCommon Management Information Protocol/Common ManagementInformation Service Elements (CMIP/CMISE). We identified the serviceelements of a common management information service and explainedhow they are used.

Our discussion of the information model dealt with managed objectclasses and instances. They are derived by using the inheritance tree inthe OSI management information model. The naming tree is used toname managed objects, and the registration tree registers the names ofmanaged object classes.

The OSI communication model dealt with the CMISE and CMIP. Welooked at the lower- and upper-layer profiles used in OSI managementand the role of the Association Control Service Element (ACSE) inestablishing and releasing application associations across systems. TheRemote Operations Service Element (ROSE) performs the exchange ofdata after the ACSE has established the associations.

The five management application functional areas of configuration, fault,performance, security, and accounting utilize the system managementfunctions, which in turn invoke the common management informationservices to execute tasks.


1 of 1 23-Sep-15 8:12 PM

OSIOSI.A.1OSI.A.2OSI.A.3OSI.A.4OSI.A.5OSI.A.6OSI.A.Summary

network management principles and practice mani subramanian 2nd edition appendix a

Documents