and traffic, the service class is a key component of a successful QoS implementation. There are many methods in which service classes can be used to implement an administrative policy. The first step is to identify the traffic in the network and the QoS requirements for each traffic type. Then, traffic can be grouped into a set of service classes for differentiated QoS treatment in the network. One popular model for the application of QoS service classes is the customer model, a term typically used by service providers when referring to customer traffic. Although many variations exist, Figure shows a customer model defining these service classes: Figure lists guidelines for defining QoS service classes for QoS implementations. One key element of defining QoS service classes is to understand the basic quality needs of network applications. It is essential that applications be given QoS treatment in line with their needs. For example, improperly specifying voice traffic into a service class with guaranteed bandwidth but without a guaranteed low latency (delay) would not meet the needs of the voice traffic. While it is important to fully understand network application requirements, it is equally important not to overprovision or overdesign the administrative policy. An administrative policy should be proactive in nature and require as few service classes as necessary. One good rule is to limit the number of service classes to no more than four or five. A typical network has these application types: The QoS requirements of these applications can be met with a few well-designed service classes. The more service classes implemented in support of an administrative QoS policy, the more complex the QoS implementation will be. This complexity also extends to support and troubleshooting. It is also important that the highest-priority classes be reserved for a select few applications. Marking 90 percent of network traffic as high priority will render most administrative QoS policies useless. Example: Application Service Classes
Although there are several sources of information to use as guidelines for determining a QoS policy, none of them can determine exactly what is proper for a specific network. Each network presents unique challenges and administrative policies. To implement QoS properly, measurable goals must be declared, and then a plan for achieving these goals must be formulated and implemented. QoS must be implemented consistently across the entire network. Whether the data is crossing slow WAN links or Gigabit Ethernet, being switched by a Layer 2 switch or routed in a Layer 3 device, the policies must be consistently implemented to satisfy the policy requirements. In this example, a QoS policy is deployed and several classes are defined for the traffic flows. As shown in the table in Figure , the traffic flows can be classified by using the IP precedence, PHB, or DSCP according to the importance of the traffic flow. For example, the voice bearer service can be classified with an IP precedence of 5, PHB EF, or a DSCP of 46. Depending on the QoS design of the network, the classification values are mapped into the MPLS EXP bits, for example. If data travels over even a small portion of a network where different policies (or no policies) are applied, the entire QoS policy is destroyed. The “Cisco Best Practices for Marking the Traffic with Layer 2 and Layer 3 Markers” table in Figure represents Cisco best practices for marking the traffic with Layer 2 and Layer 3 markers.
Content 4.1 Introducing Classification and Marking 4.1.11 Trust Boundaries A trust boundary is the point within the network where markings such as CoS or DSCP begin to be accepted. Previously set markings are overridden as required at the trust boundary. Figure shows the hierarchical structure of a network. The location of the trust boundary depends upon the capabilities of the devices connected to the access edge of the LAN. The trust boundary must be implemented at one of three locations in a network as shown: Trusted endpoints have the capabilities and intelligence to mark application traffic to the appropriate CoS and/or DSCP values. Trusted endpoints also have the ability to re-mark traffic that may have been previously marked by an untrusted device. Examples of trusted endpoints are these: If an endpoint is trusted, then the trust boundary should be at the endpoint. When trusted endpoints are connected to a switch port, all that is typically required is enabling the mls qos trust dscp interface command. If the endpoint is not trusted and the switch in the wiring closet has QoS intelligence, then the trust boundary should be at the access layer—within the switch in the wiring closet. If the endpoint is not trusted and the switch in the wiring closet does not have QoS intelligence, then the trust boundary should be at the distribution layer—within the switch or router that is aggregating traffic from the access layer. The concept of trusting or not trusting forms the basis for the trust boundary. Ideally, classification should be done as close to the network edge as possible. Trust Boundaries: IP Phones and PCs
Figure illustrates the challenge of selecting an appropriate place to mark a trust boundary. Classification should take place at the network edge, typically in the wiring closet or within trusted endpoints (such as servers, trusted hosts, video endpoints, or IP telephony devices). Trusting end users and their PCs is generally not recommended because newer operating systems like Windows XP/Vista and Linux make it relatively easy to set CoS or DSCP markings on PC network interface cards (NICs). Improperly set QoS markings can affect the service levels of users within the enterprise. One of the main business advantages of IP telephony is the simplicity and related cost savings of adding, moving, or changing a user. To move, a user simply picks up the IP phone, plugs it in at his or her new location, and carries on business as usual. If the infrastructure supports inline power, it is literally a matter of unplugging a single RJ-45 cable and plugging it in at the new location. IP phones are trusted devices, while PCs are not. This can be a problem when provisioning trust in a mobile environment. For example, port A is configured to trust the endpoint connected to it, which initially is an IP phone. Port B is configured not to trust the endpoint connected to it, which initially is a PC. Because of a move, these endpoints get plugged into the opposite ports. This change breaks the VoIP quality of calls made from the IP phone (now plugged into untrusted port B) and opens the network to unintentional or deliberate abuse of provisioned QoS by the PC (now plugged into the trusted port A). Cisco switches with QoS intelligence use