Stephen Morris is a consultant and IT management specialist at Omey Communications in Ireland. He can be contacted at [email protected].
I often think that a good metric for the degree of technological advancement is the number of networks we use: Internet, landline phone, mobile phone, digital TV, etc. Other networks include: electricity, gas, water, and so on. Each such network has its own infrastructure and management requirements. A key management requirement is that of handling events, i.e., asynchronous messages emitted by elements in the network. Given the growing trend for self-managing software (e.g., database administrators now typically manage up to 20 different databases because the latter provide greater automation), it's important to be able to close the administration loop wherever possible. Network events provide an ever-present opportunity for such self-management.
In this article, I'll look at a method by which the chain of responsibility pattern can be used to facilitate network event management. The language of choice is C++, but the same considerations apply to any other language.
A Typical Network
Figure 1 illustrates a network that I'll use to describe the concept of chain of responsibility. As it's a complex diagram, let's start with the part in the center: the Service Provider Network (SPN). The SPN is where most of the action happens. On the left and right hand edges of the SPN are two IP routers called provider edge routers (PEs). PEs are typically powerful devices that have links to one or more enterprise networks. Enterprise customers use the provider network for data transport, e.g., voice-over-IP, or more traditional data streams.
A simple way to think about Figure 1 is that the SPN is a kind of pipe through which the enterprise data passes. The pipe exists to provide transit bandwidth and geographical reachability. At the bottom center of Figure 1 is a network management system, which is the entity that will contain our chain of responsibility code.
One other item in Figure 1 is the entity LSP123 (and its backup path at the bottom of Figure 1). This is nothing more than a pre-defined path through the network. In the case of Figure 1, LSP123 represents a forwarding path between routers R2, R3, R4, and R5 and this path is employed to carry data traffic from R2 to R5. The backup LSP (between R2, R7, R6, & R5) provides an alternative route for traffic if LSP123 becomes non-operational.
LSP is an acronym for label switched path—a pre-configured path that the network operator can create with specific attributes such as route, bandwidth, etc. The incoming traffic can then be automatically directed into one or other of the LSPs in the network. Clearly, LSPs are important entities—for more on this topic, see [1].
Let's now look briefly at how such a network can generate an event and then we'll introduce some C++ handling code.