Measurement Layer Interface (MLI)

UMA Measurement Layer Interface (MLI)
Copyright © 1997 The Open Group

UMA Sessions

This Chapter describes:

Session characteristics
UMA messages.

Session Characteristics

The UMA facility is that part of UMA that provides data and session services to the MAP (through the MLI).

A MAP accesses the services of the UMA facility by first establishing a session and then issuing the appropriate MLI calls. A session is a channel of communication over which the MLI sends messages to the UMA facility to set up and control the reporting of data and to receive status and data messages.

Each session has an associated data source, a data destination, and property flags that specify certain fixed characteristics of the session; these constitute the session context. The creation and specification of the session and its context are described in the description of the umaCreate() call.

A session also has certain changeable attributes. These include a session start time, a session end time, a reporting priority, a reporting interval size, and search control attributes. The start time session attribute determines when reporting is to begin. There is an internally maintained session current time that indicates the time of the data interval currently being reported. Nominally, the session current time is initially set to the session start time (subject to constraints imposed by the settings of the certain session search attributes, as will be later described).

MLI Calls

The MLI calls are the means by which a MAP communicates with the UMA facility to establish and access UMA sessions. All MLI calls return a status code indicating the general outcome of the call. Further detail regarding failed calls can be obtained by invoking the umaGetReason() call.

A number of UMA-defined data types are used for specifying UMA objects such as classes, subclasses, message flags, etc. The type definitions, their values and valid operator definitions are incorporated into a MAP by including header file <uma.h> (see C Language Header Files ).

MLI Security

When enhanced security provisions are required beyond what is the operating system default, the MLI and UMA Data Services Layer (DSL) encapsulate the security-related exchanges with other entities. This means that the MLI library does not give the MAP explicit access to security-related keys or tickets. Instead, the MLI library itself acquires an authentication key and sends it to the Data Services Layer (DSL), where it is authenticated. Subsequently issued tickets and encryption/decryption keys are retained by the MLI library for use until expiration. Thus, the MAP proper and its user do not necessarily know that encryption, or what levels of security are in effect. The only visible result of a security interaction between local and remote UMA Data Services Layers (DSLs) is a possible UMR_PERMISSION reason code returned from session establishment, and data solicitation MLI calls if access is denied.

To ensure interoperability between various implementations that support such enchanced security, the Generic Security Service API (GSS-API) is to be used as the default security API by the UMA DSL for session establishment, and, where desired by administrators, for ensuring per-message integrity and confidentiality. These enhanced security services are optional for both implementers and administrators. This means that implementations are possible that do not support enhanced security and that administrators may select their use or non-use when available by means of installation or configuration options. GSS-API potentially supports a variety of underlying security mechanisms. (See reference GSS).

Basics of UMA Messages

Once a session is established, a MAP communicates with the UMA facility by means of MLI calls. These result in the MLI formatting messages that are delivered to the UMA facility. The MLI provides a set of functions and utilities that provide for the creation, sending, receiving and handling of these messages. Information from UMA to the MAP is also communicated (through the MLI) via messages. The MAP accesses these messages with the MLI function umaGetMsg().

Messages divide into two groups: data and control. Both data and control messages contain data items identified by the class and subclass.

All messages consist of a header and one or more segments. In addition, data messages have an extension header between the header and segments. The header provides the basic information necessary to start extracting information from the message, including the time stamp of the message, the duration (if an interval message), and offsets into the message body bgcolor="#FFFFFF" for the segments. Additionally, the class and subclass of a message are indicated.

The message, its header and segments, include ASN.1/BER encoded tags and length descriptors (used for parsing the message). (ASN.1/BER encoding is used in data communication between open systems.) The contents and detailed structure of the segments (body bgcolor="#FFFFFF") depends on the class and subclass.

Data Messages

Data messages contain either interval or event data:

Interval data is that which is specifically scheduled for capture at each expiration of a specified time interval. The data reported for that interval is the increment of the item values over the interval or, if requested, the value of the metric accumulated from a startup through that interval.
Event data consists of notification messages to the MAP indicating that some predefined set of events has occurred. The currently defined events include UMA configuration data, system configuration data, and process-end summaries. Other classes and subclasses for event data may be defined. Delivery of event data to the measurement application may be requested as in-band (that is, in timestamp sequence) or out-of-band (ahead of timestamp sequence).

The type of data is indicated by a flag in the header.

Data segments for both interval and event data can contain the following:

Basic data, which each UMA implementation must supply (segment must be present)
Optional data, which is generally available but not mandatory (segment is optional)
Extension data, which is vendor defined (segment is optional).

Each of the data segments begins with an ASN.1/BER tag-length prefix. The location of each segment is specified in the extension header as an offset from a message global start position.

The UMA configuration data describes which classes, subclasses, and data fields are implemented. The system configuration data describes the hardware and software configuration of the system. It includes system parameters statically defined at boot time and hardware status changes such as disk mounts and unmounts.

The class identifies the major grouping (memory, processor, and so on) and subclass provides a specific grouping within class (virtual memory usage, block I/O counters, and so on). The definitions and grouping of data items by these classes and subclasses are documented in the document, Data Pool Definition (see reference DPD).

A MAP initiates ongoing reporting of data for a class and subclass via a umaStart() call. Depending on the specified destination, data may be directed to the MAP itself, to UMADS, or to a file. A MAP may use the umaRequestConfig() call to request one time event data, that is, UMA or system configuration data.

Because of the flexibility and extensibility of UMA messages, a MAP may need to trace through several fields and data structures in the header and extension header to extract the requested segment.

Control Messages

Control messages include MAP requests to the UMA facility, UMA condition notifications from UMA to a MAP, and, in distributed environments, request and acknowledgement messages between remote and local Data Services Layers.

Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents

Next section

Index