7.8 Saving and Restoring the Configuration

It is important to be able to save the existing configuration for an embedded communications device and to restore it on startup. Protocol configuration is quite complex, but saving the current configuration and restoring it upon startup makes the process easier. Save and restore processes can be either manager or device based.

In a manager-based approach, the SNMP manager uses a get operation to keep a record of the current device configuration. When the system reboots, it requests a configuration restoration from its manager. The manager performs this with multiple set operations, effectively "replaying" the saved configuration.

This approach provides a centralized approach to management in which the device is not required to save and restore configuration by itself. The manager has to ensure that it sets the parameters in the right order-basic parameters first, followed by non-basic parameters.

Device-based save and restore operations are more popular. Here, the manager instructs the device to save the current configuration during system execution. The device can categorize and aggregate the basic and non-basic parameters and store them efficiently, as discussed next.

Theory of Operation

When implementing a protocol, ensure that configuration parameters and the method for saving and restoring them are identified up front. Moreover, only the parameters that can be set (i.e., configuration parameters) need to be saved. Variables/parameters related to status and statistics will not fall in this category.

The simplest approach to the saving/restoring of configuration is to operate on the actual data structures. This implies that we can save current data structures and restore them upon startup.

One issue with the approach of saving and restoring data structures is that basic parameters may have to be grouped and set before the other parameters can be set. Data structures often follow a more integrated design, making it difficult to separate the basic parameters out.

Another problem with data structure restoration is that configuration should cause some effects and side effects. In the case of enabling a protocol, the Enable' operation will be much more than just changing the value of a variable to 'Enabled.' The action can cause PDUs to be sent on multiple interfaces and also effect the starting of various timers. So, it is essential that, when restoring configuration, we mimic the effects of the steps that caused the configuration-effectively recreating the sequence.

Saving the Configuration

The read-write basic and non-basic parameters are aggregated and saved to a temporary location in the RAM, as shown in Figure 7.4. A common method is Type Length Value (TLV) encoding, which specifies the type of the data being saved, the length of the stored value, and the actual value. Prior to storing the file, the binary file is typically compressed. For error detection, a checksum is calculated on the compressed file and appended to the end of the file. The entire chunk of data, as shown in Figure 7.4, is a binary file.

click to expand
Figure 7.4: Saving the configuration

The file can be stored locally or at a remote location. The upload to a remote location is done using upload parameters like the remote host IP address, file name, FTP user name and password, and so on, similar to the boot image. Good design paradigms provide for both local and remote storage options, since it is likely that the configuration file may be too big to fit into local storage.

Note that when a save is initiated, the system manager will be permitted only to display variables and not to modify them. This is to ensure the integrity of the saved configuration.

Restoring the Configuration

Restoration of the configuration happens at boot time. After the image is downloaded and the system started, the configuration file is loaded and decompressed from the local storage or a remote host. The structures will be used to configure the basic and non- basic parameters for individual protocols. Note that the system is not fully initialized until this process is complete. No configuration or management operations are permitted until the system has completed this operation.



Designing Embedded Communications Software
Designing Embedded Communications Software
ISBN: 157820125X
EAN: 2147483647
Year: 2003
Pages: 126
Authors: T. Sridhar

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net