PDF of this tutorialAfter defining the Ethernet-based services that customers require, service providers should further refine them through SLAs. SLAs enable providers to customize the service to align the customer's application requirements and business objectives with the service offering. The better the customization of the service, the higher the value of the service to the customer-and the higher the revenue potential for the provider.
Service providers should think about SLA attributes because they will strongly influence how the network is deployed. For example, an SLA that emphasizes service availability will require redundant network equipment, protocols that support redundancy, and the appropriate network topology. Attributes like delay, jitter, data delivery rate, or sequence preservation also require special attention when it comes to deployment. SLAs need to be supported by the appropriate QoS mechanisms and protocol capabilities.
Service providers can define Ethernet SLAs using two basic approaches-bandwidth profiles and services classes.
Bandwidth Profiles
Bandwidth profiles are specified similarly to the well-known SLA model for Frame Relay. They offer a committed information rate (CIR) and a peak information rate (PIR). The CIR is the rate that is always available to the customer, and the PIR defines the maximum rate at which a customer can send traffic. A bandwidth profile can also specify a maximum burst size (MBS), which is the maximum amount of traffic that the customer can send contiguously that exceeds the CIR.
The bandwidth profile approach is easy for customers to understand, but has some shortcomings. It does not allow for highly customized services, because all the customer traffic, no matter what the application, is treated the same. And if the model is implemented using a Layer-1-only infrastructure, such as SONET/SDH without any packet multiplexing capabilities as the ingress, the service provider must provision for the higher PIR, instead of the baseline level CIR, to accommodate the highest possible levels of traffic. To use traffic pipes most efficiently, service providers need to consider ways to provide packet processing capabilities at the edge of the network, so that they can police, shape, and buffer traffic. These capabilities require a service classes approach to SLAs.
Service Classes
The service classes approach acknowledges that different applications have different transport requirements. It lets providers offer application- or service-specific intelligent transport, rather than a simple traffic pipe. Customers receive a bandwidth contract that is similar to a CIR, but which focuses on service classes instead of simply bandwidth. Some examples of service classes include voice traffic, latency-optimized traffic, or throughput-optimized traffic. Each of these service classes has certain attributes, and it is up to the customer to tie specific applications to SLAs.
The service classes approach is similar to trends seen in Frame Relay networks. Many Frame Relay SLA offerings initially used a simple CIR/PIR model for all traffic. Service providers then enhanced the model to deploy services that are aware of different service classes (as specified by the Differentiated Services Code Point [DSCP]) for IP traffic. For example, a provider could deploy four different service classes, each with its own CIR/PIR, using a single data-link connection identifier (DLCI).
Service-class SLAs provide several advantages to customers and service providers. They let customers receive more specific SLAs, so they can optimize their use of the network and provide the best support to their applications and business requirements. Service classes also enable service providers to offer a higher-quality service and to more accurately engineer the network for traffic.
Because the service classes approach provides more detail about traffic, service providers can handle various types of traffic differently in the core, and manage the network more accurately and predictably. For example, a provider could use one route for high-priority, low-latency traffic, and another route for less critical traffic. To be able to implement service classes, however, the service providers need to deploy intelligent equipment at the network edge.
