Smarter NEs

The scalability issues associated with NEs discussed in Chapter 3 require more agent intelligence. This is because NEs are becoming denser, essentially compressing what have been entire networks into firmware. When a device can host millions of virtual connections, the issue of trap generation becomes problematic because a device or high-capacity link failure (such as a fiber cut) can result in a storm of traps. Rather than many NEs generating traps in parallel, one dense device may not generate as many traps. This is a limitation of the processing speed and computational resources allocated to an agent on one of the new high-end devices. However, in time it is likely that the number of traps emitted by the next generation of NEs will probably exceed that of an equivalent set of low-end devices. Trap storms can cause network and NMS congestion (blocking). There is therefore a need for traps to be aggregated, buffered, and possibly even compressed. For this reason, denser NEs require more preprocessing at the agent level before emitting traps to the NMS. In the opposite direction, the provisioning operations initiated by the NMS must increasingly push more complex settings onto the NEs in order to support the increasingly advanced network services.

The need for advanced, real-time services, such as voice- and video-over-IP, on enterprise and SP networks is also resulting in a need for greater NE intelligence. Policies provide an elegant solution to the problem of managing ever-denser NEs. We discuss policies in detail in the next section. For now, they are introduced simply as being objects (rules, conditions, and actions; e.g., if the number of IP packets received at a router interface exceeds 10,000 per second, then increase the bandwidth of an associated virtual circuit) that are pushed onto NEs from an NMS. The NEs then subsequently:

• Follow the installed policy guidelines

• Watch for the indicated conditions

• Execute the required actions

Policies are a little like SNMP notifications in that the NE performs work independently of the NMS. They differ from notifications in that policies can result in quite complex NE computation (such as real-time traffic engineering). In effect, this brings management code much closer to the managed object data (providing a partial solution to one of the big management problems mentioned in Chapter 3).