5.3 Implementation

5.3.1 Allocation and Initialization of Control Blocks

A protocol can be enabled or disabled on an interface. But the protocol first requires some basic interface parameters to be set, such as an IP address, before it can be enabled on the interface. This information is usually in the PICB, which needs to be allocated prior to this operation.

A common scheme is to allocate the PICB when, say, an SNMP manager configures the parameters for the protocol on the interface. For example, when a manager sets the IP address for an Ethernet interface, the protocol software allocates a PICB, links it to the Ethernet interface's HICB, and then sets the IP address in the configuration block for the specific PICB. The allocation is done transparently, and the appropriate fields are created and set in the PICB.

As indicated in Chapter 4, non-basic parameters take on default values if they are not explicitly set during PICB creation. If all basic parameters have been set in the PICB, the protocol can be enabled on the interface; if not, the PICB entry is in a 'not ready' mode. After all basic parameters have been set, the entry (and PICB) creation is complete.

Allocation Schemes-Static versus Dynamic

ICBs need to be allocated every time an interface is created by the external manager. Software makes a call to the memory management subsystem to allocate the PICB and initializes the fields with values specified by the manager and links to the HICB. The PICB is then linked to the list of PICBs in the PCB.

The advantage of this is that we do not need to allocate memory for the PICB before it is needed. The disadvantage is the overhead of allocating memory on a running system. Note that the peak memory requirement is unchanged independent of when we allocate the memory, as discussed next.

Consider a system where the maximum number of protocol interfaces is 10. Assume that each PICB takes 100 bytes. We contend that the system has to allocate space for 100 × 10 bytes for the PICBs independent of when they are allocated-at startup or during runtime. Other applications should plan on a total memory of 1000 bytes for the PICBs, even if the memory for the interfaces has not been allocated.

Allocation Schemes-Arrays versus Linked List

Memory allocation can follow one of two methods, namely:

1. Allocate all the PICBs in an array

2. Allocate memory for PICBs as multiple elements in a free pool list

The array-based allocation is straightforward. Using the numbers above, PICBs are allocated as array elements, each of size 100 for a total of 1000 bytes. A field in each entry indicates whether the element is allocated and provides a next pointer to indicate the next element in the list (see Figure 5.4). Note that all the entries are contiguous.

Figure 5.4: Array-based Allocation for PICBs.

The second type of allocation treats each PICB as a member of a pool. Instead of one large array of 1000 bytes, individual PICBs are allocated using a call such as malloc and linked to each other in a free pool. A free-pool pointer indicates the start of the free pool and lists the number of elements available in the pool. Whenever a PICB needs to be obtained by a protocol and linked to the PCB, it is "allocated" out of this free list and linked to the PCB (see Figure 5.5). The free list is empty once all the PICBs are obtained and linked to the PCB. Whenever an interface is deleted with a management command operation, the PICB is "released" back to the free list.

Figure 5.5: Linked List based Allocation for PICBs.

The alternative to a free list is to allocate all the PICBs and link them up to the PCB as they are allocated. An entry in the PCB can indicate the number of allocated and valid PICBs, so that a traversal of the list is done only for the number of entries specified. This method avoids the need to maintain a separate free pool since it can be mapped implicitly from the PICB list itself.

It is best to allocate all required memory for tables and control blocks at startup to avoid the overhead of dynamic allocation during execution.

Applicability to Other Tables

The methods for allocation and initialization of ICBs can be extended to other types of tables and data structures used in communications software. For example, a neighbor list in OSPF, connection blocks in TCP, are data structures where these schemes can be used. In the case of TCP, a connection block could be allocated whenever a connection is initiated from the local TCP implementation or when the implementation receives a connection request from a peer entity. The connection blocks are then organized for efficient access.