MibBrowser, can configured to receive traps on one or more ports. Ports are set to listen for traps by parameters being entered in a configuration file. By default, FMS is configured to lis- ten at port 162, with the entry <TRAP_PORT> PPORT trapport="162"/> </TRAP_PORT> Multiple Ports can be specified using the comma separator. For example, to listen for traps at ports 8001, 8002, 8003, 8004, the entry will be <TRAP_PORT> trapport '8001, 8002, 8003,8004"/> </TRAP_PORT> We address FMS in much more detail in Chapter 12. 4 Network Management Using SNMP Trap ports can be configured at runtime, as part of the trap parser's dynamic configuration. The existence of traps is often relevant to other management applications that are relying on the base fault management product. For example, a trap stating that a switch is running at 80% of capacity is valuable information to a service provisioning application, because service for new users should be activated at alter- native switches if any are available. A trap stating that power has failed at a multi- plexer is relevant to service level agreement (SLA) management applications as customers may be affected by the fault who are entitled to service credits as a result. These are called vertical dependencies between products, based on APIs, that were discussed in the Introduction. So, when traps are received by FMS, it may be necessary that other applications are made aware of those traps. The trap observer mechanism makes this possible. The specific application that must be notified should register with the Event Manager module of FMS as a trap observer. Once an application is registered, a notification will be sent to it whenever a trap is received. An application registers as a trap observer by implementing the TrapObserver API and, in particular, by using the register method. Notification is executed by invoking a method in the observer application, the implementation class of TrapObserver. Notification made in SNMP PDU format contains trap PDU informa- tion. To de-regist