5.2 Partitioning the StructuresTables

5.2 Partitioning the Structures/Tables

To begin the design of structures and tables, first determine the type of information. Two common types of information are global and per port information. Global information indicates scalar variables and tables that are global to the protocol or module, independent of the interface it is operating on. Per-port information specifies those scalars and tables that are related to the module or protocol task’s operation on a port.

Each protocol or module can have global and per-port information. For example, if IP and IPX run over an interface, each of these protocols will have their own interface- related information, including information like the number of IP or IPX packets received over an interface. Apart from this, each physical interface can have management information that is related to its own operation, such as the port speed or type of physical connection (such as V.35, RS-422). These are maintained by the device driver, which also has its own global and per-port information.

5.2.1 Control Blocks

To design data structures and tables for protocol and system modules, start off with a root data structure called the Control Block (CB). This data structure is used to store global information about the module and is used as the initial reference point to access the module’s data structures.

Figure 5.1: Physical & Logical Interfaces on a Frame Relay router.

In the case of a protocol, the CB has pointers to the configuration, control, status, and statistics variables for the protocol. These variables themselves can be organized in control blocks (see Figure 5.1). In the figure, we have assumed that the configuration, control, and status variables are available as a single block and that the statistics variables are available as another block. Thus, the Config/Control/Status block (called a Configuration block hereafter) contains Read–Write and Read-Only variables, while the Statistics block contains Read-Only variables.

The CB is the “anchor block” for the protocol from which other information is accessed. The CB can have global information about the protocol itself —this could be in the CB (as shown in Figure 5.1) or accessed via another pointer. The global information specified here includes those parameters that are not configured by an external manager and are to do with the functioning of the protocol within the system. Global information can include housekeeping information (e.g., has the protocol completed initialization, or whether the interfaces to buffer and timer management have succeeded).

A sample of a Protocol Control Block (PCB) and the related Configuration and Statistics Blocks for IP are given in Listing 5.2 (note that only some of the fields are provided).

Listing 5.2: Protocol control block and related blocks for IP.

typedef struct ControlBlock { BOOLEAN  IPInitialized; BOOLEAN  IPBufferInterfaceInitialized; BOOLEAN  IPTimerInterfaceIntialized; IPConfigBlock *pConfig; IPStatsBlock  *pStats; }; typedef struct _IPConfigBlock { BOOLEAN ipForwardingEnabled; UINT2   u2TTLValue; /* to insert in IP packet */ UINT2   icmpMask; /* which ICMP messages to                                        respond to*/ ……… ……… } IPConfigBlock; typedef struct _IPStatsBlock { UINT4        ipInReceives;              UINT4        ipInHdrErrors;              UINT4        ipInAddrErrors;              ………              ………              UINT4        ipOutDiscards;              UINT4        ipOutNoRoutes;              ………              ………              ………              ……… } IPStatsBlock;

It may appear that accessing the configuration and statistics with this pointer-based indirection is inherently inefficient. Protocol tasks have to access the configuration block by first accessing the CB and then obtain the configuration block pointer. If all the information were in the control block itself, the CB would be a much bigger structure. While this may not be a problem by itself, segmentation of the blocks and access via pointers can make it easy to save and restore configuration for the protocol. Also, individual protocol configuration and statistics blocks can reside in different parts of memory using a pointer-based design—allowing for a lot more flexibility in memory partitioning.

Design Decisions

This book does not mean to imply that the suggested approaches are the only or best way to design and implement the communications software subsystem. Like a number of design decisions, the developer should choose the approach based on the application. For example, a system which requires the fastest performance for access of data structures would not be a suitable candidate for pointer- based indirection. On the contrary, a system that requires flexibility (even it means a hit on performance) may benefit from some of the approaches suggested here.

There is no one right answer to this. However, some key considerations include code migration and maintenance, portability, and performance.

Logical Interfaces

Each communication protocol or module can be run on multiple interfaces. These interfaces could be physical ports or logical interfaces. An example of a logical interface is with a protocol like Frame Relay running PVCs over a single serial interface. Each PVC is treated by the higher layer protocol as though it were a point to point circuit to the peer entity (see Figure 5.2). So, the higher layer would consider each PVC termination as a point-to-point physical interface, effectively yielding multiple logical interfaces over a physical interface.

A protocol needs to have an interface-specific configuration to perform such tasks as enabling or disabling the running of a protocol like OSPF. Similarly, statistics information like the number of OSPF packets received on an interface can be part of (logical) interface-specific statistics. The Interface Control Block (ICB) handles this information

5.2.2 Interface Control Blocks

The Interface Control Block (ICB) is similar to the protocol control block. There are two types of ICBs—one for the hardware port and one for the protocol interface. The hardware port ICB, also called the Hardware Interface Control Block (HICB), is a protocol- independent data structure. The HICB represents the configuration, control, and statistics related to the hardware port only. The Protocol Interface Control Block (PICB) represents the parameters for a protocol (configuration, control, status, and statistics) on a specific interface.

Figure 5.2: Logical interface.

Figure 5.3 introduces the HICB and the PICB. There is one HICB per physical port while PICBs number one per logical interface for the protocol. xrefparanum shows a pointer to the PICB list from the Protocol Control Block (PCB). Each PICB has a pointer to its related HICB and is also linked to the next PICB for the same protocol. Note that the figure shows that PICB 3 and PICB 4 are linked to the same hardware port, HICB 4. They could represent two separate PVCs on a single serial port running Frame Relay, as indicated in xrefparanum.

Using two types of ICBs rather than a single HICB provides greater flexibility since:

• More than one protocol may be enabled on a hardware port.

• More than one logical interface may be specified on a physical interface.

Consider an example of a multiprotocol router which forwards both IP and IPX traffic over two Ethernet interfaces and a Frame Relay WAN interface. Assume that the Frame Relay port has three PVCs and that IP and IPX forwarding are enabled on all ports and PVCs.

It is clear that both IP and IPX protocols will have their own PCB and PICBs for each of the interfaces they are enabled on. Since there are 3 PVCs on the Frame Relay port, each protocol has a total of five logical interfaces (two for Ethernet, and one for each of the three PVCs on the Frame Relay interface). Each of the PICBs are linked to the HICB for that port. So, the two Ethernet PICBs are linked to the HICBs for Ethernet, and the three PVCs are linked to the HICB for the Frame Relay port. If we had used a single ICB, we would have had to delineate space related to various protocols in the HICB itself—a less-than-ideal situation.

Figure 5.3: Hardware and protocol interface control blocks.

The use of control blocks permits a degree of modularity and stackability (protocols running “on top” of another protocol over a hardware port) of protocol interfaces. In the examples of protocols like IP and IPX running over a serial port, the Frame Relay port is a physical interface. But, Frame Relay is itself a protocol which runs over a hardware interface. So, the FR protocol with its own PCB and PICBs has a one-to-one mapping with HICBs. This is a simple case of “stacking.” Configuration of interface stacking is provided via the MIB defined in RFC 1573.