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. Queuing 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 10 shows the mapping of DiffServ service class meanings (aliases) to DSCPs.
Table 10: Default DSCP Mappings
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:
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.
Figure 11: Packet Flow Through CoS-Configurable Components
You can configure one or more of the following JUNOS CoS mechanisms:
Most M-series routers have only four queues built into the hardware. M120, M320, MX-series, and T-series 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 11 shows the four forwarding classes and queues that Juniper Networks classifiers assign a packet based on the DSCP values in arriving packet headers.
Table 11: Default Forwarding Classes
|
Forwarding Class Name |
Queue |
|---|---|
|
best-effort |
queue 0 |
|
expedited-forwarding |
queue 1 |
|
assured-forwarding |
queue 2 |
|
network-control |
queue 3 |
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 12 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.
Table 12: Default Behavior Aggregate Classification
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 13 shows the router forwarding classes associated with each well-known DSCP code point and the resources assigned to their output queues.
Table 13: Classification Forwarding Classes and 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.
Figure 12: Basic IPv6 DiffServ Topology
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 14 shows the resources assigned to the four forwarding classes in this example.
Table 14: Resources Assigned to Queues
|
Queue |
Forwarding Class |
Transmit Rate |
Buffer Size |
Priority |
|---|---|---|---|---|
|
0 |
be (data) |
40% |
40% |
Low |
|
1 |
ef (financial) |
10% |
10% |
High |
|
2 |
af (audiovisual) |
45% |
45% |
High (with RED) |
|
3 |
nc (network control) |
5% |
5% |
Low |
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.
 | Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice. | |