ployed. Similarly, they will determine where failures consistently occur and why, helping an IIC make decisions about replacing faulty equipment or identifying incompatibilities among different network technologies. Chapter 2 - A Detailed Look at OSS Because NMSs track a network's health, a great emphasis has been placed on real-time capabilities. The key is, if and when a failure occurs, the IIC should know about it, have someone fixing it and notify affected customers before they call to complain (or change providers, which is becoming easier as we'll see in chapter four). With companies increasingly dependent on voice and data services, network failures are simply intolerable. Though somewhat reliable, new switch technologies, which are generally dependent upon software, are not as rock solid and fool proof as older-technology circuit switches, which have been refined continuously for many years. As a result, a premium is placed on performance statistics, which are tied directly to SLAs. Customers often want to know in real time how well the network performs. "How many packets are dropped and re-transmitted? How much end-to-end delay do we experience? How many calls have been dropped, if any? Are we receiving the QoS guarantees for which we've contracted?" If an IIC doesn't meet its SLA requirements, the customer must be notified and recompensed. It's therefore the job of the real time NMS to provide performance statistics and let the IIC know when it's near SLA failure. Therefore, the NMS or performance manager (though related, these can be separate, applications), is often integrated with a SLA management system that stores the contractual data. A well-integrated back office will detect failure before it occurs and tell the network to reprioritize certain customers' traffic to make sure SLAs are met, avoiding both costly penalties and upset customers. MSPs and ASPs have added further dimensions to performance monitoring. Because they offer application services, they must monitor application servers and even 