The CiscoWorks Service Management Solution (SMS) is a suite of applications used to manage network-wide service level agreements (SLAs). The key application within this suite is the CiscoWorks Service Level Manager (SLM), which allows an administrator to define SLAs thresholds, and then monitor collected data to be sure that service levels are in fact being met.
In the remainder of this section I’ll explain the key components of an SLA, the network management capabilities that much be included in order to effectively monitor SLAs, and provide an overview of how CiscoWorks Service Level Manager implements the monitoring of SLAs.
As the name suggests, a service level agreement (SLA) is effectively a contract between two parties – in this case, a company (the client) and a service provider such as an ISP. In most cases, contracts for service will be valued at anywhere from a few thousand to many hundreds of thousands of dollars per year. As such, the exact expectations as to what the customer is getting for their money needs to be clearly defined. While a home user might be willing to accept occasional service disruptions or network performance issues, these same issues can have a profound financial impact on larger businesses.
As a contract, an SLA will almost always define very specific and quantifiable data about the service that a client should expect to receive. For example, an SLA might state that a WAN connection between two offices should provide a ping response time of less than 100 ms at least 99% of the time. If this requirement was agreed upon and not met, then typically the service provider would be assessed a financial penalty under the contract. In some cases providers use very standardized SLAs that apply to all clients. In many others, SLAs become sticking points that require very detailed negotiations between the parties. Regardless, it is important to remember that an SLA defines explicit performance metrics that the service provider is agreeing to provide to the client.
While an SLA defines the key metrics associated with an agreement between the client and service provider, a method is still needed for both to test and be certain that the metrics defined are actually being met. This is where applications like CiscoWorks Service Level Manager come into play. This application allows you to define what are known as service level contracts (SLCs) meant to be consistent with the language used and metrics defined in the actual contract. Each SLC is typically made up of many individual SLAs that define thresholds and the endpoints in the communication process. Each SLA covers one specific performance metric only. For example, one SLA might be defined to measure FTP performance between two devices, and another to measure HTTP performance between the same two devices. It’s easy to see how a single SLC could be made up of many different SLAs. Returning to the previous example, an SLA might state that the ICMP response time of a WAN connection between two distinct devices (known as the source device and target device) must be less than 100 ms 99% of the time. Notice that this time, the definition of where the 100 ms comes into play is clearly defined, and is not subject to interpretation.
It is very important to be clear about the main network management capabilities that must exist in order to effectively determine whether service level agreement performance metrics are being met. These include:
- Ensuring conformance. The primary goal of a network management solution that monitors SLAs is to ensure that the actual performance of a network conforms to the specific requirements agreed upon by both parties.
- Isolating and identifying problem areas. Outline of ensuring conformance, the network management system should be capable of isolating and identifying any specific problems areas that exist with respect to the defined SLAs. For example, a network management solution should be able to accurately identify devices or connections that are not meeting the criteria outlined in an SLA.
- Reporting. The network management solution should also be capable of providing detailed reporting capabilities for analysis purposes.
CiscoWorks Service Level Manager (SLM) uses a distributed architecture made up of the components listed below.
- SLM Server. The server-based component is ultimately responsible for defining, monitoring, and documenting service between a customer and a service provider.
- Service Level Contract (SLC). The contract between the client and the service provider defined in the SLM server software. An SLC is made up of at least one SLA, but can contain an unlimited number of SLAs (1500 different SLA metrics are supported). There is no hard limit as to the number of SLCs the application can support.
- Service Level Agreements (SLAs). A specific metric that defines a traffic type, threshold value, and endpoints between which services will be monitored for conformance. In SLM Server, each SLA measures performance for a specific metric between a pair of devices. When SLAs are created, sampling intervals can also be defined to reduce resource utilization associated with the data collection process.
- Collection Managers (CMs). Software agents designed to collect and aggregate the data used by the SLM server. Many CMs can be installed on a network in a distributed manner, helping to reduce potential bottlenecks that might result from a single collection point.