Stateful Mediation

Ideally, management mediation follows a simple pattern: The management gateway receives a request message from a manager and translates it into an equivalent request message for the agent. When a response or event message is received, the gateway translates it into an equivalent response or event message that it sends back to the manager. The pattern is very straightforward and clean; management mediation involves not much more than transforming a message that the gateway can forget about after it is sent. What to do with those messages—for example, how to react when things go wrong—is of no interest to the gateway; this is the responsibility of manager and agent. The gateway is merely a conduit, a messenger. It does not care what the messages really mean. After it has done its part—that is, after it has translated the message that it received and passed on the translated message—it does not need to keep a memory (or "state") around about the fact that the translation ever occurred. This is referred to as stateless mediation.

So much for the ideal case. Unfortunately, in real life, things are often less than ideal, and for management gateways, the situation is no different. For management gateways, this means that stateless mediation is subject to certain limitations. Those limitations surface whenever the target interface (the one the gateway exposes to the manager) has capabilities that cannot be translated in a one-to-one manner to the source interface (the one that the agent exposes, that the gateway has to work with). This can occur in the following scenarios:

■ The target interface supports management functions that are not offered by the source interface. For example, the target interface supports an event-subscription service that the manager expects to use but that the underlying agent does not provide.

■ The target interface supports certain options for management functions that the source interface does not support. For example, the target interface might include an option to apply a get operation to all objects in a MIB subtree that meet a certain criteria, whereas the source interface offers no such capability.

■ The target interface exposes management information that is not available in the same form at the source interface. For example, the target interface might provide a managed object with the sum of all packets that were routed over ports on that card, whereas the source interface might provide the same information only for the individual ports.

■ There are even simpler scenarios, such as the target interface requiring the request identifier to be included as part of the matching response message, whereas the source interface might have no notion of request identifiers.

Despite such "semantic mismatches," which are also schematically depicted in Figure 9-16, in most cases, mediation is still possible.

Figure 9-1S Semantic Matches and Mismatches in Management Mediation

Target interface (manager)

covered functionality

covered 1 functionality 1

Source interface (agent)

Source interface (agent)

(a) Semantic match -

mediation straightforward

Target interface

(manager)

covered functionality

covered functionality

(b) Semantic mismatch ■ mediation difficult mismatch

(agent)

(b) Semantic mismatch ■ mediation difficult mismatch

■ In the first example, the management gateway can emulate the event-subscription service by remembering which subscriptions the manager requested and then filtering the events that are received as required. The management gateway needs to understand what the subscription requests entail, intercept those requests, and, instead of translating them into management requests for the agent, provide the needed functionality itself. The agent being managed does not even have to realize that any of this is taking place.

■ In the second example, the management gateway needs the capability to resolve the identifiers of objects that might fall in the requested scope and then break up the request into a series of requests directed at the individual managed objects at the agent, collect the responses from the agent, check for each response if the filter criteria is being met, and then aggregate them into a response message to the manager.

■ In the third example, the management gateway needs to understand how the piece of management information being requested relates to other management information that can be retrieved from the device. In this case, it needs to understand that the requested information constitutes an aggregate of other management information available at the device. As with the second example, the gateway needs to retrieve that information possibly in multiple requests and aggregate the information for the response being sent back to the manager.

■ In the last example, the management gateway needs to retain a memory of the request identifier until the response from the agent is received so that it can include the identifier in the response to the manager.

In each case, the gateway needs to do much more than just translate messages. It might need to do the following:

■ Break a single operation into multiple steps

■ Deal with exceptions and be capable of providing transactional semantics—in other words, know what to do when an operation fails that is one in a series of steps

■ Provide additional management logic, as in the event subscription example

■ Cache management information from the underlying agents, for example, so that it can resolve a management operation's scope

Above all, it needs to retain state—a memory of what subscriptions it needs to serve, of intermediate results that need to be collected and aggregated to prepare a response, or of the identifier of a request that it received earlier. Therefore, this type of mediation is called stateful mediation.

Stateful gateways are much more powerful than stateless gateways. As the examples show, many functions could simply not be offered with gateways that are stateless. In addition, stateless gateways expose the limitations of the interface of the underlying agent, whereas stateful gateways can smooth out those limitations, to a great extent. The price for this added power is, of course, added complexity in the gateway. The heavier the management gateway becomes, the more it will start to resemble a full-fledged management application in its own right.

In the end, there is no magic: a simpler interface is simpler to implement by an agent, and a more powerful interface offloads management applications, but in the end, the work needs to be done somewhere. Hence, if you want to mediate from an agent with a simple interface to a more powerful interface that can be used by a manager (by far the most common scenario), the difference in power must be made up somewhere—and where else if not the management gateway?

Was this article helpful?

0 0

Post a comment