Service level agreement

This topic points out some of the important aspects of a service level agreement (SLA) that might affect your quality of service (QoS) implementation. QoS is a network solution. To receive network priority outside your private network, you might need to have an SLA with your Internet service provider (ISP).

When is an SLA required

You only need an SLA if your policies require priority outside your private network. If you are using outbound policies to control traffic leaving your system, then no service guarantee is required. For example, on the system, you can create a policy that gives one application higher priority than another application. Your system recognizes this priority, but anything outside the system might not recognize the priority. If you have a private network and configure your routers to recognize codepoint markings (used to give outbound policies a service level), then the routers will give priority through your private network. However, if the traffic leaves your private network, there are no guarantees. Without an SLA, you do not control how network hardware handles traffic. Outside your private network, you need an SLA to guarantee the priority for a class of service or resource reservation.

Why is an SLA required

Your policies and reservations are only as good as the weakest link. This means that QoS policies enable applications to receive priority through the network. However, if one node anywhere between the client and the server is unable to perform any of the traffic-handling characteristics discussed in the differentiated service or integrated service topics, your policies will not be handled as you intended. If your SLA does not allow you enough resources, even the best policies will not help your network's congestion problem.

This also involves agreements across ISPs. Across domains, every ISP must agree to support QoS requests. Interoperability might cause some challenges.

Make sure that you understand the service level that you are actually receiving. Traffic conditioning agreements specifically address how traffic is handled, what is dropped, marked, shaped, or retransmitted. The key reasons to provide QoS involve controlling latency, jitter, bandwidth, packet loss, availability, and throughput. Your service agreements must be able to give your policies what they request. Verify that you are receiving the amount of service you need. If not, you might waste your resources. For example, if you ask to reserve 500 kbps for IP telephony but your application only needs 20 kbps, you might pay extra without receiving any notice from your ISP.