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: - Voice service class: Delivers
low latency for voice services
- Mission-critical
service class: Guarantees latency and delivery for the
transport of mission-critical business applications, such as
SAP
- Transactional service class: Guarantees
delivery and is used for more general applications that are not
that sensitive to delay compared to mission-critical
applications
- Best-effort service class: Used
to support small business, e-mail, and other best-effort
applications
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: - Voice applications:
VoIP
- Mission-critical applications: Oracle, SAP
- Transactional applications: Telnet
- Best-effort
applications: e-mail, web
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: - Endpoint or end
system
- Access layer
- Distribution
layer
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:
- Videoconferencing gateways and systems (Cisco IP/VC
3511 Multipoint Control Unit, 3521 BRI Videoconferencing
Gateway, 3526 PRI Videoconferencing Gateway, and 3540 Enhanced
Media Processor videoconferencing gateways and systems)
- IP conferencing stations (Cisco IP Conference Station 7935
and Unified IP Conference Station 7936)
- Wireless
access points (Cisco Aironet 350, 1100 and 1200 Series Access
Points)
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