A Link Failure in The Service Provider Network
Let's assume that the network has been operating with no problems when suddenly Link 1 (in Figure) 1 fails. Such a failure could be due to an errant digger cutting a fiber optic cable in two. The result of such a link failure is that our LSP123 has to now find another path, such as R2, R7, R6, & R5. Fortunately, all the traffic can now be moved onto the backup LSP. So, the enterprise end users should see no immediate service interruption. However, notice that the backup LSP has only 8Mbps bandwidth, whereas the main LSP has 10Mbps. So, there is a possibility of congestion on the backup LSP.
One or both of R2 and R3 will pick up the failure of Link 1 with the result that an event message will be sent to the network management system (NMS). So, we've lost the link and the notification message has been passed into the NMS. Let's now take a quick look inside the NMS.
An NMS Under The Hood
A generic NMS consists of numerous interacting applications. One such application handles the thousands of different events that can occur. Let's see what a generic C++-based event handler might look like in Listing 1.
typedef int Event;
const Event No_Event_Support = -1;
class EventHandler {
public:
EventHandler(EventHandler* = 0, Event = No_Event_Support);
virtual bool HasEventSupport();
virtual void SetHandler(EventHandler*, Event);
virtual void HandleEvent();
private:
EventHandler* _successor;
Event _event; };
When is the handler in Listing 1 used? Well, it's used when an entity (such as an LSP) manages a network event, such as the link failure we saw in Figure 1. Each managed entity in our fictitious NMS models a real world entity and is a subclass of EventHandler. This means that each such entity has the ability to handle and (hopefully) respond in a meaningful fashion to events.
Getting back to Listing 1, the constructor for EventHandler initializes (to zero) a linked list of event handlers. This is the key to the event management scheme—the handlers pass the event along until an appropriate handler is found. In this way, the NMS plays a kind of pass-the-parcel game with events. This key design decision has the effect of distributing the event management intelligence among the NMS classes rather than focusing it in one central class.
Often, NMS products don't use this approach—instead, many commercial products use a centralized event handler. The centralized approach requires a big event server that tries to field all incoming events from the network. Event messages are received, parsed and then the event server has to decide what to do. This monolithic approach is unnatural and potentially brittle.
Thanks to the chain of responsibility pattern, I use a devolved model—equipping each managed object to do some specific event handling. So, if object X can't process the event, it passes that event onto object Y, etc. I'll review the design tradeoffs later.
