Overview
CoS is the assignment of traffic flows to different service levels. Service providers can use router-based CoS features to define service levels that provide different delay, jitter (delay variation), and packet loss characteristics to particular applications served by specific traffic flows.
Usually, IP routers forward packets independently and without any control on throughput or delay. This is known as best-effort service. This service is as good as the network equipment and links, and the result is satisfactory for many traditional IP applications emphasizing data delivery, such as e-mail or Web browsing. However, newer IP applications such as real-time video and audio (or voice) require lower delay, jitter, and loss parameters than simple best-effort networks can provide. CoS is intended for networks supporting these types of time-sensitive video and audio applications.
A router cannot compromise best-effort forwarding performance in order to deliver CoS features, because this merely trades one problem for another. When CoS features are enabled, they must allow routers to better process critical packets as well as best-effort traffic flows, even during times of congestion. Network throughput is determined by a combination of available bandwidth and delay. CoS guarantees a minimum bandwidth dedicated to a service class.
The main impact of CoS on network delay is in queueing delays, when packets are normally queued for output in the order of arrival, regardless of service class. Queueing delays increase with network congestion and often result in lost packets when queue buffers overflow. The other two elements of overall network delay, serial transmission delays determined by link speeds and propagation delays determined by media type, are not affected by CoS settings.
Any CoS implementation must work consistently end to end through the network. A standards-based, vendor-neutral CoS implementation satisfies this requirement best. Juniper Networks CoS features interoperate with other vendors' CoS implementations because they are based on IETF DiffServ standards.
DiffServ specifications establish a six-bit field in the IPv4 and IPv6 packet header to indicate the service class that should be applied to the packet. The bit values in the DiffServ field form DiffServ code points (DSCPs) that can be set by the application or a router on the edge of a DiffServ-enabled network.
Table 8 shows the mapping of DiffServ service class meanings (aliases) to DSCPs.
None of the aliases are established by DiffServ specifications. The aliases are well-known only through usage. For example, it is widely accepted that the alias for DSCP 101110 is ef (expedited forwarding). The 21 well-known DSCPs establish 5 DiffServ service classes:
- Best-effort (be)—The router does not apply any special CoS handling to packets with
000000in the DiffServ field, a backward compatibility feature. There is usually a high probability that these packets will be dropped under congested network conditions. - Assured forwarding (af)—The router offers a high level of assurance that the packets are delivered as long as the packet flow from the customer stays within a certain service profile (the service provider defines the values). The router accepts excess traffic, but applies a random early discard (RED) drop profile to decide if the excess packets should be dropped and not forwarded. Three drop probabilities (low, medium, and high) are defined for this service class.
- Expedited forwarding (ef)—The router delivers assured bandwidth, low loss, low delay, and low delay variation (jitter) end-to-end for packets in this service class. Routers accept excess traffic in this class, but in contrast to assured forwarding, out-of-profile expedited-forwarding packets can be forwarded out of sequence or dropped.
- Conversational services (cs)—The router delivers assured (usually low) bandwidth with low delay and jitter for packets in this service class. Packets can be dropped, but never delivered out of sequence. Packetized voice is a good example of a conversational service.
- Network control (nc)—The router delivers packets in this service class with a low priority (these packets are not delay-sensitive). Typically, these packets represent routing protocol hello or keepalive messages and loss of these packets jeopardizes proper network operation, so delay is preferable to discard.
Although CoS methods such as DiffServ specify the position and length of the DSCP in the packet header, the implementation of the router mechanisms to deliver DiffServ internally is vendor-specific. CoS functions in JUNOS software are configured through a series of mechanisms that you can configure individually or in combination to define particular service offerings.
Figure 11 shows the components of the JUNOS CoS features, illustrating the sequence in which they interact.
You can configure one or more of the following JUNOS CoS mechanisms:
- Classifiers—Allow you to associate incoming packets with a forwarding class and packet loss priority (PLP). Two general types of classifiers are supported:
- Behavior aggregate (BA) or code point traffic classifiers allow you to set the forwarding class and PLP based on DSCP.
- Multifield (MF) traffic classifiers allow you to set the forwarding class and PLP based on firewall filter rules. This is usually done at the edge of the network for packets that do not have valid DSCPs in the packet headers.
- Forwarding classes—Allow you to set the scheduling and marking of packets as they transit the router. Known as ordered aggregates in the DiffServ architecture, the forwarding class plus the loss priority determine the router's per-hop behavior (PHB in DiffServ) for CoS.
- Loss priorities—Allow you to set the priority of dropping a packet before it is sent. Loss priority affects the scheduling of a packet without affecting the packet's relative ordering.
- Forwarding policy options—Allow you to associate forwarding classes with next hops. Forwarding policy also allows you to create classification overrides, which assign forwarding classes to sets of prefixes
- Transmission scheduling and rate control—Provide you with a variety of tools to manage traffic flows:
- Schedulers—Allow you to define the priority, bandwidth, delay buffer size, rate control status, and RED drop profiles to be applied to a particular forwarding class for packet transmission.
- Fabric schedulers—For T-series and M320 routing platforms only, fabric schedulers allow you to identify a packet as high or low priority based on its forwarding class, and to associate schedulers with the fabric priorities.
- Policers for traffic classes—Allow you to limit traffic of a certain class to a specified bandwidth and burst size. Packets exceeding the policer limits can be discarded, or can be assigned to a different forwarding class or to a different loss priority, or to both. You define policers with filters that can be associated with input or output interfaces.
- Rewrite markers—Allow you to redefine the DSCP value of outgoing packets. Rewriting or marking outbound packets is useful when the routing platform is at the border of a network and must alter the code points to meet the policies of the targeted peer.
M-series routers have only four queues built into the hardware. T-series and M320 routing platforms can be configured for up to eight queues. If a classifier does not assign a packet to any other queue (for example, for other than well-known DSCPs that have not been added to the classifier), the packet is assigned by default to the class associated with queue 0 (Q0).
Table 9 shows the four forwarding classes and queues that Juniper Networks classifiers assign a packet based on the DSCP values in arriving packet headers.
Each forwarding class has an associated scheduler priority. Only two forwarding classes, best-effort and network-control (Q0 and Q3), are actually referenced in the default scheduler configuration. However, you can manually configure resources for the expedited-forwarding and assured-forwarding classes (Q1 and Q2).
The default scheduler settings are not visible in the output of the show class-of-service command; rather, they are implicit.
Default scheduler
[edit class-of-service]
schedulers {
network-control {
transmit-rate percent 5;
buffer-size percent 5;
priority low;
drop-profile-map loss-priority any protocol any;
drop-profile terminal;
}
best-effort {
transmit-rate percent 95;
buffer-size percent 95;
priority low;
drop-profile-map loss-priority any protocol any;
drop-profile terminal;
}
}
drop-profiles {
terminal {
fill-level 100 drop-probability 100;
}
}
By default, the best-effort forwarding class (Q0) receives 95 percent of the output link bandwidth and buffer space, and the network-control forwarding class (Q3) receives 5 percent of the output link bandwidth and buffer space. The default drop profile provides tail drop, where the buffer fills and then discards all packets until there is space in the buffer again. There are no schedulers for the expedited-forwarding or assured-forwarding classes because by default no resources are assigned to Q1 and Q2.
Table 10 shows the default forwarding class and packet loss priority (PLP) for the well-known DSCPs. It is important to note that although several DSCPs map to the expedited-forwarding and assured-forwarding classes, by default no resources are assigned to these forwarding classes. All of these settings can be changed through configuration.
All af classes other than af1x are mapped to best-effort, since RFC 2597 prohibits a node from aggregating classes. In effect, mapping to best-effort implies that the node does not support that class.
Typically, rewrites of the DSCPs on outgoing packets are done once, when packets enter the DiffServ portion of the network, either because the packets do not arrive from the customer with the proper DSCP bit set or because the service provider wishes to verify the that customer has set the DSCP properly. CoS schemes that accept the DSCP and classify and schedule traffic solely on DSCP value perform behavior aggregate (BA) DiffServ functions and do not usually rewrite the DSCP. DSCP rewrites typically occur in multifield (MF) DiffServ scenarios.
Table 11 shows the router forwarding classes associated with each well-known DSCP code point and the resources assigned to their output queues.
The example in this chapter essentially assigns expedited forwarding to Q1 and a subset of the assured forwarding classes (af1x) to Q2, and distributes resources among all four forwarding classes.
Figure 12 shows the topology of the three routers and links that are used as a case study in this chapter.
In this case study, the service provider has agreed to provide high-priority delivery of packets for two applications between the customer's servers at two sites. The first application generates streams of high-definition audiovisual (television) packet flows and the second generates large quantities of time-sensitive financial information. In all cases, the packet flow is from server to server. The service provider marks the packets appropriately as they enter the network from either site, configures special queues and forwarding classes for this traffic on the three routers, and uses DiffServ for IPv6 for this purpose.
Routers 1 and 3 use MF classifiers on the customer-facing interfaces to detect high-priority packets and rewrite the DSCPs appropriately. Best-effort data and network control packets are not affected. All three routers are configured with consistent schedulers and resources to handle high-priority packets properly.
Table 12 shows the resources assigned to the four forwarding classes in this example.
The table shows how the 95 percent of output link transmission rate and buffer size (queue) resources assigned by default to Q0 (best-effort) are distributed to Q1 (expedited forwarding) and Q2 (assured forwarding). The audiovisual traffic consumes more bandwidth than other applications, but the financial information, although critical, is carried in fewer packets. In keeping with DiffServ specifications, a RED drop profile is applied to the assured forwarding class. The financial data has a strict set of traffic parameters that must be respected.
The three DiffServ assured forwarding classes supported (af11, af12, and af13, with low, medium, and high packet drop probability, respectively) are distinguished by using a low PLP and RED drop profile for af11 and a high PLP and RED for af12 and af13. All of these parameters should be closely monitored initially for performance and adjusted as necessary.