|
|
Classification entails using a traffic descriptor to categorize a packet within a specific group to define that packet and make it accessible for QoS handling on the network. Using packet classification, you can partition network traffic into multiple priority levels or classes of service. When traffic descriptors are used to classify traffic, the source agrees to adhere to the contracted terms and the network promises a quality of service. Traffic policers, such as committed access rate's (CAR's) rate-limiting feature, and traffic shapers, such as Frame Relay Traffic Shaping (FRTS) and Generic Traffic Shaping (GTS), use a packet's traffic descriptor---that is, its classification---to ensure adherence to the contract.
Packet classification is pivotal to policy techniques that select packets traversing a network element or a particular interface for different types of QoS service. For example, you can use classification to mark certain packets for IP Precedence and you can identify others as belonging to a Resource Reservation Protocol (RSVP) flow.
This chapter explains IP Precedence, then it gives a brief description of the kinds of traffic classification provided by the Cisco IOS QoS features. It discusses the following features:
Use of IP Precedence allows you to specify the class of service (CoS) for a packet. You use the three precedence bits in the IPv4 header's type of service (ToS) field for this purpose. Figure 2 shows the ToS field.
By setting precedence levels on incoming traffic and using them in combination with the Cisco IOS QoS queueing features, you can create differentiated service. You can use features such as policy-based routing (PBR) and CAR to set precedence based on extended access list classification. These features afford considerable flexibility for precedence assignment. For example, you can assign precedence based on application or user, or by destination and source subnetwork.
So that each subsequent network element can provide service based on the determined policy, IP Precedence is usually deployed as close to the edge of the network or the administrative domain as possible. You can think of IP Precedence as an edge function that allows core, or backbone, QoS features, such as WRED, to forward traffic based on CoS. IP Precedence can also be set in the host or network client, but this setting can be overridden by policy within the network.
The following QoS features can use the IP Precedence field to determine how traffic is treated:
You use the three IP Precedence bits in the ToS field of the IP header to specify CoS assignment for each packet. You can partition traffic into up to six classes---the remaining two are reserved for internal network use---and then use policy maps and extended ACLs to define network policies in terms of congestion handling and bandwidth allocation for each class.
For historical reasons, each precedence corresponds to a name. These names, which continue to evolve, are defined in the RFC 791 document. Table 3 lists the numbers and their corresponding names, from least to most important.
| Number | Name |
|---|---|
0 | routine |
1 | priority |
2 | immediate |
3 | flash |
4 | flash-override |
5 | critical |
6 | internet |
7 | network |
However, the IP Precedence feature allows you considerable flexibility for precedence assignment. That is, you can define your own classification mechanism. For example, you might want to assign precedence based on application or access router.
By default, the Cisco IOS software leaves the IP Precedence value untouched, preserving the precedence value set in the header, allowing all internal network devices to provide service based on the IP Precedence setting. This policy follows the standard approach stipulating that network traffic should be sorted into various types of service at the basic perimeter of the network and that those types of service should be implemented in the core of the network. Routers in the core of the network can then use the precedence bits, for example, to determine the order of transmission, the likelihood of packet drop, and so on.
However, because traffic coming into your network can have precedence set by outside devices, Cisco recommends you reset the precedence for all traffic entering your network. By controlling IP Precedence settings, you prohibit users who have already set the IP Precedence from acquiring better service for their traffic simply by setting a high precedence for all of their packets.
You can use any of the following features to set the IP precedence in packets:
As mentioned previously, after a packet has been classified, you can use other QoS features such as CAR and WRED to specify and enforce business policies to fit your business model.
PBR gives you a flexible means of routing packets by allowing you to configure a defined policy for traffic flows, lessening reliance on routes derived from routing protocols. To this end, PBR gives you more control over routing by extending and complementing the existing mechanisms provided by routing protocols. PBR allows you to set the IP Precedence. It also allows you to specify a path for certain traffic, such as priority traffic over a high-cost link.
You can set up PBR as a way to route packets based on configured policies. For example, you can implement routing policies to allow or deny paths based on the identity of a particular end system, an application protocol, or the size of packets.
PBR allows you to do the following:
Policies can be based on IP address, port numbers, protocols, or size of packets. For a simple policy, you can use any one of these descriptors; for a complicated policy, you can use all of them.
All packets received on an interface with PBR enabled are passed through enhanced packet filters known as route maps. The route maps used by PBR dictate the policy, determining to where the packets are forwarded.
Route maps are composed of statements. The route map statements can be marked as permit or deny, and they are interpreted in the following way:
You specify PBR on the interface that receives the packet, not on the interface from which the packet is sent.
Some applications or traffic can benefit from QoS-specific routing; for example, you could transfer stock records to a corporate office on a higher-bandwidth, higher-cost link for a short time while transmitting routine application data such as e-mail over a lower-bandwidth, lower-cost link.
Policy Propagation via BGP allows you to classify packets based on the following:
After a packet has been classified using BGP, you can use other QoS features such as CAR and WRED to specify and enforce business policies to fit your business model.
BGP Policy Propagation leverages BGP to distribute QoS policy to remote routers in your network. It allows ingress routers to prioritize incoming traffic.
Policy Propagation via BGP is supported on these platforms:
For the Policy Propagation via BGP feature to work, you must enable BGP and Cisco Express Forwarding (CEF)/Distributed CEF (DCEF) on the router.
Subinterfaces on an ATM interface that has the bgp-policy command enabled must use CEF mode because Distributed CEF is not supported. (Note that DCEF uses the VIP rather than the RSP to perform forwarding functions.)
You can use CAR's classification services to set the IP Precedence for packets entering the network This capability of CAR allows you to partition your network into multiple priority levels or classes of service. Networking devices within your network can then use the adjusted IP Precedence to determine how to treat the traffic. For example, VIP-Distributed WRED uses the IP Precedence to determine the probability of whether a packet will be dropped.
As discussed in the section "About IP Precedence," you can use the three precedence bits in the ToS field of the IP header to define up to six classes of service.
CAR is supported on these routers:
Posted: Thu Jun 3 14:23:39 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.