7.4 Management Subsystem Architecture

This section details the architecture of the management subsystem in a communications device. SNMP is used to illustrate the architecture and access mechanisms. The principles are also applicable to other types of management, including HTTP, CLI, CORBA, TL1, and so on.

7.4.1 Using SNMP

Chapter 5 discussed how to map MIB-based tables to the implementation. This discussion continues with the example of the IPStatsBlock originally specified in Chapter 5 and detailed again in Listing 7.1.

SNMP provides the ability to get an individual element of a table or individual variable using the Get PDU function. This PDU is verified and translated by the SNMP agent on the device, after which it calls routines provided by the protocol tasks to get the value of the specific variable. These routines are termed the low-level routines since they operate at the lowest level in the calling sequence to perform the required function.

So, if the IPStatsBlock is implemented inside the IP task, the task needs to provide a low-level access routine for each member of the IPStatsBlock structure. A Get routine for the number of received packets would look like:

IP_Mgmt_Get_ipInReceives ( )

Listing 7.1: Statistics block.

typedef struct {              UINT4        ipInReceives;              UINT4        ipInHdrErrors;              UINT4        ipInAddrErrors;              ………              ………              UINT4        ipOutDiscards;              UINT4        ipOutNoRoutes;              ………              ………              ………              ………        } IPStatsBlock;

For clarity, we simply reuse the MIB variable ipInReceives in the function prototype of the low-level routine-a common practice. Since this management variable is not defined on a per-interface basis, there are no parameters to be specified in the Get routine.

The IP task implements the low-level routines for each of the variables in the IPStatsBlock. The mapping between the MIB variable and the low-level routine to be called is done by the agent through a table.

The second type of routine is a Set routine used for read-write variables. This routine takes at least one parameter, the value for the variable. In cases in which the variables are specified in a table, the routine also requires the indices for the table.

A third type of routine commonly used in the management subsystem is a Test routine. This is invoked before the Set operation by the SNMP agent to determine if the Set command will be successful. It is a good place to validate the parameters.

Consider enabling and disabling a protocol using a variable called IPStatus. Valid values for IPStatus are 1 (enable) and 2 (disable). If a manager requests a PDU to set the value to 3, the Test routine indicates an error, and the PDU returns an error to the manager.

Instead of requiring a routine per variable, we could use a single routine with a switch statement for accessing the appropriate variable. The following example illustrates a switch statement using the fields of the IPStatsBlock (Listing 7.2).

Listing 7.2: A Test routine with a switch statement.

IP_Mgmt_Stats_GetRoutine (Variable)  {       ---------       ---------       switch (Variable) {           ----            ---             case IP_INHDR_RECEIVES:                  Access Variable and return value;            case IP_INHDR_RECEIVES:                  Access Variable and return value;             ----             ---             default:                ------                ------     } /* end switch */   }

Note that this does not really reduce complexity, since the same logic is needed to access the variable. On the other hand, using a single function can lead to function bloat, always an issue with code maintainability. The recommendation is to use a function for each variable. Also, note that a function prototype with the variable name at the end (like IP_Mgmt_Get_ipInReceives above) increases the readability of the code.

7.4.2 Using the CLI

The scenario discussed earlier with SNMP is valid for other agent tasks as well. The back end of the agent invokes the same low-level routines, similar to the SNMP agent. The low-level routines are invoked, sometimes in a repetitive manner. Consider the case of a CLI for a router in which the user requests that all the IP statistics be displayed, as follows:

CLI> show ip stats

The CLI agent will parse this command and interpret that it needs to make multiple calls to the IP task to obtain all statistics variables in the IPStatsBlock. It will make multiple calls to the IP task low-level routines-one for each of the variables-and construct a response for the CLI user, as shown in Figure 7.2.

The CLI statistics structure is populated by multiple calls to the protocol (IP) task, after which a display routine is called to display the statistics to the user. The parameters that are to be displayed by the above command can vary depending upon the CLI implementation. For example, the variables to be displayed need not have a one-to-one correspondence with MIB variables. In that case, the variables accessed by the low-level functions need not all belong to the same protocol data structure or MIB table.

Figure 7.2: The CLI agent.

The front end of the agent task is where aggregation of the response from the protocol task takes place. However, access to the protocol task is through a single low-level routine, as shown in Figure 7.2.