Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
A Multithreaded Problem
Multithreaded problems abound in the field of network management. This isn’t surprising when you consider the importance of remote entity configuration in network management. One easily understood example of such a configuration concerns the problem of device software upload/download.
If you’ve read some of my previous articles, you might remember Figure 1, which depicts a simplified service provider network. Each of the devices in the upper part of Figure 1 plays a role in the services offered by the overall network. What does this mean? Well, basically the network in totality offers services such as voice over IP (Internet telephony) and data transport (email, file services, web access, and so on). The various packet streams associated with the network services are illustrated in the upper-left side of Figure 1.
)
Figure 1 A managed network.
The network fulfils the service portfolio by transporting the packets arriving at its boundaries (for example, the routers R1, R2, R5, and so forth). Different packets (or packet streams) arriving at the network edges may be provided with higher levels of service than are provided to other packets (or packet streams). Packets pushed across the entity LSP123 in Figure 1 may receive intentionally different service levels; for example, packet X may be transported across LSP123 more quickly than packet Y.
All of the magic of modern networking ultimately is achieved by way of the software and configuration data on the devices inside the network. (If you want to read more about the technologies in Figure 1 and the associated network management techniques, see my book Network Management, MIBs and MPLS: Principles, Design and Implementation.)
Our problem concerns software upload—updating the software (or firmware) on the devices in Figure 1. In many such networks, the issue of software upload is handled by the network management system (NMS) illustrated schematically in Figure 1. Typically, the NMS has a GUI representation of each device in the network, and it’s the possible to interact with the underlying device by using some type of GUI menu.
An easy way to think about this mechanism is to imagine Client 1 in Figure 1 viewing a GUI map of the network. The user of Client 1 decides to view the firmware version on one of the network devices (such as router R1). On seeing the firmware version, the user decides to upgrade the device to a more recent firmware revision. That’s our use case for the device firmware upload.