7.5 Agent-to-Protocol Interface

Even though the protocol task provides routines for management, these routines are only called from the agent(s), as shown in Figure 7.2. These routines access the various data structures that the protocol task implements. There are two related issues to consider here:

• Priority of the agent task(s)

• Data structure access by the low-level routines conflicting with access from the main loop of the protocol task

The agent task is often assumed to be the lowest priority task since management operations are treated as lower priority activities as compared to the main system functions, e.g., switching or routing. This implies that the low-level routine of a protocol task often executes at a priority lower than the protocol task itself. This can be a problem if the same data structures are being accessed. Mutual exclusion via semaphores is one way to address this problem. The semaphores can be used by the low-level routines and the protocol task routines for access to the data structures.

Semaphores would require significant modifications to the protocol code for management access to be “safe.” Another option is to lock the agent task during modifications so that it is not preempted by the protocol task. This ensures that the management task completes its low-level routine access before the protocol task is scheduled, ensuring that the data structures are not corrupted. This can also be realized by raising the priority of the agent task so that is higher than any of the protocol tasks during the time we need to access the read-write variable. After the access is completed, the code can make a system call to return to the original priority of the management agent task.

The ideal solution is to have the management access happen in the main loop of the task. This is similar to the method of using a call to send a message to the task, as in the case of messages and timers, discussed earlier. Lateral access to the data structures is prevented since the management message is processed in the main loop. Since there will be only one thread of execution, there is no need for mutual exclusion.

To implement the management functions in the main loop, we can use the following procedure:

1. Call the low-level routine in the protocol task from the Agent Task

2. Low-level routine sends an event to the protocol task after identifying the type of operation required.

Legacy Systems

While the approach of using a single low-level access mechanism may appear intuitive, it was not always implemented this way. Several systems (some still deployed) had two paths for management— one for SNMP and one for CLI. SNMP support was used only for some of the standard MIBs (like MIB- II), while the “real” configuration was done via the CLI.

Before we blame the developers, we should understand that they often did not have a choice. Some of the standard MIBs at the time (like MIB-II) did not support sub-interfaces like PVCs on an interface. Some of the MIBs also had the problem of not making some variables read–write as required by the network operator. Rather than implementing a proprietary version of the standard MIB, designers simply sidestepped the issue and provided flexible configuration only via the CLI. Often times, designers have to work with constraints along with legacy/history, and their choices may not always be optimal.

In Figure 7.3, the low-level routine is called from the SNMP agent after decoding. Instead of the low-level routine accessing the data structures of the protocol task, the routine constructs a message with the type of operation requested and parameters for the operation and then sends the message to the protocol task queue. This is a local event or internal event on a specific task queue, which enables the task to handle it in its main loop. Once this message is queued, the protocol task is scheduled, since it has a higher priority than the SNMP task and is waiting on events on its queues. The management function is now handled in the protocol task main loop.

Figure 7.3: Management Routines and Internal Events.

The value can be returned to the agent task with another message. For this, the protocol task constructs a message and sends it to the agent task with such information as the name of the calling routine (which initiated the internal event), status of the operation, and any return values. The agent processes this response in its main loop, since it is a message posted to one of its queues and is required for a pending manager query. The return code and values from this message are used to construct a response to the manager (SNMP Manager or CLI) which initiated the request.

7.5.1 Memory Separation Between Agent and Protocol

If the agent task and the protocol tasks are in two separate memory spaces, we have to construct a message from the agent task and queue it to the protocol task. We cannot call the low-level routines of the protocol task from the agent tasks since they are in separate locations. This procedure is no different from other internal events, except that the agent task explicitly constructs the message.

The response from the protocol task to the agent task is the same as before. The protocol task constructs a message in response to the query and queues it to the agent task. The agent dequeues the message and maps it to the pending manager query and sends a response to the manager.

This effectively implies that we use a message-based interface instead of a procedure- based interface. This approach scales very well to multi-board communications systems. The agent and the protocol task may be on two separate boards, which is an extension of the separate memory space idea. Multi-board communications systems and their design are covered in Chapter 8.