Quality of Service
(QoS) is a concept generally existing in occasions where service supply-demand
relations exist. QoS measures the ability to meet the service needs of
customers. Generally, the evaluation is not to give precise grading. The
purpose of the evaluation is to analyze the conditions where the services are
good and the conditions where the services still need to be improved, so that
specific improvements can be implemented.
In Internet, QoS measures the ability of
the network to deliver packets. The evaluation on QoS can be based on different
aspects because the network provides diversified services. Generally speaking,
QoS is the evaluation on the service ability to support the critical indexes
such as delay, delay jitter and packet loss rate in packet delivery.
In traditional IP networks, packets are
treated equally. That is, the FIFO (first in first out) policy is adopted for
packet processing. Network resources required for packet forwarding is
determined by the order in which packets arrive. All the packets share the
resources of the network. Network resources available to the packets completely
depend on the time they arrive. This service policy is known as Best-effort,
which delivers the packets to their destination with the best effort, with no
assurance and guarantee for delivery delay, jitter, packet loss ratio,
reliability, and so on.
The traditional Best-Effort service policy
is only suitable for applications insensitive to bandwidth and delay, such as
WWW, FTP and E-mail.
With the fast development of computer
networks, more and more networks are connected into Internet. Internet extends
very quickly in scale, coverage and the number of users. More and more users
use the Internet as a platform for data transmission and develop various
applications on it.
Besides traditional applications such as
WWW, FTP, and E-mail, Internet users also try to develop new services on
Internet, such as tele-education, tele-medicine, video phones, video
conferencing, and video on demand (VOD). Enterprise users also hope to connect
their branch offices in different locations through the VPN technology to
develop some transaction applications, such as to access to the database of the
company or to manage remote switches through Telnet.
The new services have one thing in common: they
all have special requirements for delivery performances such as bandwidth,
delay, and delay jitter. For example, video conferencing and VOD require the
guarantee of high bandwidth, low delay and low delay jitter. Some key services
such as the transaction handling and the Telnet do not necessarily require high
bandwidth but they are highly dependent on low delay and need to be processed
preferentially in case of congestion.
The emergence of new services brings
forward higher requirements for the service capability of the IP network. In
the delivery process, users hope to get better services, such as dedicated
bandwidth for users, reduced packet loss rate, management and avoidance of
network congestion, control of network traffic, provision of packet priority,
and so on, instead of just having packets delivered to the destination. To meet
these requirements, the network service capability need to be further improved.
QoS issues that traditional networks face
are mainly caused by congestion. Congestion means reduced service rate and
extra delay introduced because of relatively insufficient resource provisioned.
Congestion is very common in a complicated
environment of packet switching on Internet. The diagram below gives two
examples:

Figure 1-1 Traffic congestion
1)
Packets enter a switch over a high-speed link
and are forwarded out over a low-speed link.
2)
Packets enter a switch through multiple
interfaces of the same rate at the same time and are forwarded out on an
interface of the same rate.
If the outbound traffic exceeds the line
rate, the traffic encounters the bottleneck of resources and congestion occurs.
Besides bandwidth bottleneck, any
insufficiency of resources for packet forwarding, such as insufficiency of
assignable processor time, buffer size, and memory resources can cause
congestion. In addition, congestion will also occur if the traffic that arrives
within a certain period of time is improperly controlled and the traffic goes
beyond the assignable network resources.
Congestion may cause a series of negative
influences:
l
Congestion increases delay and delay jitter in
packet delivery.
l
Excessively high delay will cause retransmission
of packets.
l
Congestion decreases the effective throughput of
the network and the utilization of the network resources.
l
Aggravated congestion will consume a large
amount of network resources (especially memory resources), and unreasonable
resource assignment will even lead to system resource deadlock and cause the
system breakdown.
It is obvious that congestion is the root
of service performance declination because congestion makes traffic unable to
get resources timely. However, congestion is common in a complicated
environment where packet switching and multi-user services coexist. Therefore,
congestion must be treated carefully.
Increasing network bandwidth is a direct
way to solve the problem of resource insufficiency, but it cannot solve all the
problems that cause network congestion.
A more effective way to solve network
congestion problems is to enhance the function of the network layer in traffic
control and resource assignment, to provide differentiated services for
different requirements, and to assign and utilize resources correctly. In the
process of resource assignment and traffic control, the direct or indirect
factors that may cause network congestion must be properly controlled so as to
reduce the probability of congestion. When congestion occurs, the resource
assignment should be balanced according to the features and requirements of all
the services to minimize the influence of congestion on QoS.
Traffic classification, traffic policing
(TP), traffic shaping (TS), congestion management, and congestion avoidance are
the foundation for providing differentiated services. Their main functions are
as follows:
l
Traffic classification: Identifies packets
according to certain match rules. Traffic classification is the prerequisite of
providing differentiated services.
l
TP: Monitors and controls the specifications of
specific traffic entering the device. When the traffic exceeds the threshold,
restrictive or punitive measures can be taken to protect the business interests
and network resources of the operator from being damaged.
l
Congestion management: Congestion management is
necessary for solving resource competition. Congestion management is generally
to cache packets in the queues and arrange the forwarding sequence of the
packets based on a certain scheduling algorithm.
l
Congestion avoidance: Excessive congestion will
impair the network resources. Congestion avoidance is to supervise the network
resource usage. When it is found that congestion is likely to become worse, the
congestion avoidance mechanism will drop packets and regulate traffic to solve
the overload of the network.
l
TS: TS is a traffic control measure to regulate
the output rate of the traffic actively. TS regulates the traffic to match the
network resources that can be provided by the downstream devices so as to avoid
unnecessary packet loss and congestion.
Among the traffic management techniques,
traffic classification is the basis because it identifies packets according to
certain match rules, which is the prerequisite of providing differentiated
services. TP, TS, congestion management, and congestion avoidance control
network traffic and assigned resources from different approaches, and are the
concrete ways of providing differentiated services.
When configuring traffic classification,
TP, and LR, go to these section for information you are interested in:
l
Traffic Classification
Overview
l
TP and LR Overview
l
Traffic Evaluation and
Token Bucket
l
LR Configuration
l
Displaying and
Maintaining LR
Traffic
classification is to identify packets conforming to certain characters
according to certain rules. It is the basis and prerequisite for proving differentiated
services.
A traffic classification rule can use the
precedence bits in the type of service (ToS) field of the IP packet header to
identify traffic with different precedence characteristics. A traffic
classification rule can also classify traffic according to the traffic
classification policy set by the network administrator, such as the combination
of source addresses, destination addresses, MAC addresses, IP protocol or the
port numbers of the applications. Traffic classification is generally based on
the information in the packet header and rarely based on the content of the
packet. The classification result is unlimited in range. They can be a small
range specified by a quintuplet (source address, source port number, protocol
number, destination address, and destination port number), or all the packets
to a certain network segment.
Generally, the precedence of bits in the
ToS field of the packet header is set when packets are classified on the
network border. Thus, IP precedence can be used directly as the classification
criterion inside the network. Queue techniques can also process packets
differently according to IP precedence. The downstream network can either
accept the classification results of the upstream network or re-classify the
packets according to its own criterion.
The purpose of traffic classification is to
provide differentiated services, so traffic classification is significant only
when it is associated with a certain traffic control or resource assignment
action. The specific traffic control action to be adopted depends on the phase
and the current load status. For example, when the packets enter the network,
TP is performed on the packets according to CIR; before the packets flow out of
the node, TS is performed on the packets; when congestion occurs, queue
scheduling is performed on the packets; when congestion get worse, congestion
avoidance is performed on the packets.
The following describes several types of
precedence:
1)
IP precedence, ToS precedence, and DSCP precedence

Figure 2-1
DS field and ToS field
The ToS field in an IP header contains
eight bits, which are described as follows:
l
The first three bits indicate IP precedence in
the range of 0 to 7.
l
Bit 3 to bit 6 indicate ToS precedence in the
range of 0 to 15.
l
RFC2474 re-defines the ToS field in the IP
packet header, which is called the DS field. The first six (bit 0 to bit 5)
bits of the DS field indicate DSCP precedence in the range of 0 to 63. The last
two bits (bit 6 and bit 7) are reserved bits.
Table 2-1 Description on IP Precedence
|
IP Precedence (decimal)
|
IP Precedence (binary)
|
Description
|
|
0
|
000
|
Routine
|
|
1
|
001
|
priority
|
|
2
|
010
|
immediate
|
|
3
|
011
|
flash
|
|
4
|
100
|
flash-override
|
|
5
|
101
|
critical
|
|
6
|
110
|
internet
|
|
7
|
111
|
network
|
In a network providing differentiated
services, traffics are grouped into the following four classes, and packets are
processed according to their DSCP values.
l
Expedited Forwarding (EF) class: In this class,
packets can be forwarded regardless of link share of other traffic. The class
is suitable for preferential services with low delay, low packet loss ratio,
low jitter, and assured bandwidth (such as virtual leased line);
l
Assured forwarding (AF) class: This class is
further divided into four subclasses (AF1/2/3/4) and a subclass is further
divided into three drop priorities, so the AF service level can be segmented.
The QoS rank of the AF class is lower than that of the EF class;
l
Class selector (CS) class: This class comes from
the IP ToS field and includes eight subclasses;
l
Best Effort (BE) class: This class is a special
class without any assurance in the CS class. The AF class can be degraded to
the BE class if it exceeds the limit. Current IP network traffic belongs to
this class by default.
Table 2-2 Description on DSCP precedence values
|
DSCP value (decimal)
|
DSCP value (binary)
|
Description
|
|
46
|
101110
|
ef
|
|
10
|
001010
|
af11
|
|
12
|
001100
|
af12
|
|
14
|
001110
|
af13
|
|
18
|
010010
|
af21
|
|
20
|
010100
|
af22
|
|
22
|
010110
|
af23
|
|
26
|
011010
|
af31
|
|
28
|
011100
|
af32
|
|
30
|
011110
|
af33
|
|
34
|
100010
|
af41
|
|
36
|
100100
|
af42
|
|
38
|
100110
|
af43
|
|
8
|
001000
|
cs1
|
|
16
|
010000
|
cs2
|
|
24
|
011000
|
cs3
|
|
32
|
100000
|
cs4
|
|
40
|
101000
|
cs5
|
|
48
|
110000
|
cs6
|
|
56
|
111000
|
cs7
|
|
0
|
000000
|
be (default)
|
2)
802.1p precedence
802.1p precedence lies in Layer 2 packet headers
and is applicable to occasions where the Layer 3 packet header does not need
analysis but QoS must be assured at Layer 2.

Figure 2-2
An Ethernet frame with an 802.1Q tag header
As shown in the figure above, the 4-byte
802.1Q tag header contains a 2-byte Tag Protocol Identifier (TPID) whose value
is 8100 and a 2-byte Tag Control Information (TCI). TPID is a new class defined
by IEEE to indicate a packet with an 802.1Q tag. Figure 2-3 describes the detailed contents
of an 802.1Q tag header.

Figure 2-3 802.1Q tag headers
In the figure above, the 3-bit priority
field in TCI is 802.1p precedence in the range of 0 to 7. In the figure above, the
priority field (three bits in length) in TCI is 802.1p precedence (also known
as CoS precedence), which ranges from 0 to 7.
Table 2-3 Description on 802.1p precedence
|
802.1p precedence (decimal)
|
802.1p precedence (binary)
|
Description
|
|
0
|
000
|
best-effort
|
|
1
|
001
|
background
|
|
2
|
010
|
spare
|
|
3
|
011
|
excellent-effort
|
|
4
|
100
|
controlled-load
|
|
5
|
101
|
video
|
|
6
|
110
|
voice
|
|
7
|
111
|
network-management
|
The precedence is called 802.1p precedence
because the related applications of this precedence are defined in detail in
the 802.1p specifications.
If the traffic from users is not limited, a
large amount of continuous burst packets will result in worse network
congestion. The traffic of users must be limited in order to make better use of
the limited network resources and provide better service for more users. For
example, if a traffic flow obtains only the resources committed to it within a
certain period of time, network congestion due to excessive burst traffic can
be avoided.
TP is traffic control policies for limiting
traffic and resource usage by supervising the traffic. The prerequisite for TP
is to determine whether or not the traffic exceeds the set threshold. Traffic
control policies are adopted only when the traffic exceeds the set threshold.
Generally, token bucket is used for evaluating traffic.
A token bucket can be considered as a
container with a certain capacity to hold tokens. The system puts tokens into the
bucket at a pre-set rate. When the token bucket is full, the extra tokens will
overflow and the number of tokens in the bucket stops increasing.

Figure 2-4 Evaluate traffic with a token bucket
The evaluation for the traffic
specification is based on whether the number of tokens in the bucket can meet
the need of packet forwarding. If the number of tokens in the bucket is enough
to forward the packets, the traffic is conforming to the specification;
otherwise, the traffic is nonconforming or excess.
When the token bucket evaluates the
traffic, its parameter configurations include:
l
Average rate: The rate at which tokens are put
into the bucket, namely, the permitted average rate of the traffic. It is
generally set to committed information rate (CIR).
l
Burst size: The capacity of the token bucket,
namely, the maximum traffic size that is permitted in each burst. It is
generally set to committed burst size (CBS). The set burst size must be greater
than the maximum packet length.
An evaluation is performed on the arrival
of each packet. In each evaluation, if the bucket has enough tokens for use,
the traffic is controlled within the specification and a number of tokens
equivalent to the packet forwarding authority must be taken out; otherwise,
this means too many tokens have been used — the traffic is in excess of
the specification.
You can set two token buckets in order to
evaluate more complicated conditions and implement more flexible regulation
policies. For example, TP uses four parameters:
l
CIR
l
CBS
l
Peak information rate (PIR)
l
Excess burst size (EBS)
Two token buckets are used in this
evaluation. Their rates of putting tokens into the buckets are CIR and PIR
respectively, and their sizes are CBS and EBS respectively (the two buckets are
called C bucket and E bucket respectively for short), representing different
permitted burst levels. In each evaluation, you can implement different
regulation policies in different conditions, including “enough tokens in
C bucket”, “insufficient tokens in C bucket but enough tokens in E
bucket” and “insufficient tokens in both C bucket and E
bucket”.
The typical application of TP is to
supervise the specification of certain traffic into the network and limit it
within a reasonable range, or to "discipline" the extra traffic. In
this way, the network resources and the interests of the operators are
protected. For example, you can limit HTTP packets to be within 50% of the
network bandwidth. If the traffic of a certain connection is excess, TP can
choose to drop the packets or to reset the priority of the packets.
TP is widely used in policing the traffic
into the network of internet service providers (ISPs). TP can classify the
policed traffic and perform pre-defined policing actions based on different
evaluation results. These actions include:
l
Forwarding conforming packets or non-conforming
packets.
l
Dropping conforming or non-conforming packets.
l
Marking a conforming packet with a new 802.1p
precedence value and forwarding the packet.
l
Marking a conforming packet with a new IP
precedence value and forwarding the packet.
l
Marking a conforming packet or a non-conforming
packet with a new DSCP precedence value and forwarding the packet.
Port rate limiting refers to limiting the
total rate of inbound or outbound packets on a port.
Port rate limiting can be implemented
through token buckets. That is, if you perform port rate limiting configuration
for a port, the token bucket determines the way to process the packets to be
sent by this port or packets reaching the port. Packets can be sent or received
if there are enough tokens in the token bucket; otherwise, they will be
dropped.
Compared to TP, port rate limiting applies
to all the packets passing a port. It is a simpler solution if you want to
limit the rate of all the packets passing a port.
Follow these steps to configure LR:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Enter interface view or port group view
|
Enter port view
|
interface interface-type interface-number
|
Enter either view.
For Ethernet interface view, the
following configuration takes effect only on the current interface. For entering
port group view, the following configuration takes effect on all the ports.
|
|
Enter port group view
|
port-group { manual port-group-name | aggregation agg-id
}
|
|
Configure LR
|
qos lr outbound cir committed-information-rate [ cbs
committed-burst-size ]
|
Required
|
Limit the outbound rate of GigabitEthernet
1/0/1 to 640 kbps.
# Enter system view
<Sysname> system-view
# Enter interface view
[Sysname] interface GigabitEthernet
1/0/1
# Configure LR parameter and limit the
outbound rate to 640 kbps
[Sysname-GigabitEthernet1/0/1] qos lr
outbound cir 640
|
To do…
|
Use the command…
|
Remarks
|
|
Display the LR configuration of an
interface
|
display qos
lr interface [ interface-type interface-number ]
|
Available in any view
|
When configuring QoS policy, go to these
sections for information that you are interested in:
l
Overview
l
Configuring
QoS Policy
l
Displaying
and Maintaining QoS Policy
QoS policy includes the following three
elements: class, traffic behavior and policy. You can bind the specified class
to the specified traffic behavior through QoS policies to facilitate the QoS
configuration.
I. Class
Class is used for identifying traffic.
The elements of a class include the class
name and classification rules.
You can use commands to define a series of
rules to classify packets. Additionally, you can use commands to define the
relationship among classification rules: “and” and “or”.
l
and: The devices
considers a packet to be of a specific class when the packet matches all the
specified classification rules.
l
or: The device
considers a packet be of a specific class when the packet matches one of the
specified classification rules.
II. Traffic behavior
Traffic behavior is used to define all the
QoS actions performed on packets.
The elements of a QoS behavior include
traffic behavior name and actions defined in traffic behavior.
You can use commands to define multiple
actions in a traffic behavior.
III. Policy
Policy is used to bind the specified class
to the specified traffic behavior.
The elements of a policy include the policy
name and the name of the classification-to-behavior binding.
The procedure for configuring QoS policy is
as follows:
1)
Define a class and define a group of traffic
classification rules in class view.
2)
Define a traffic behavior and define a group of
QoS actions in traffic behavior view.
3)
Define a policy and specify a traffic behavior
corresponding to the class in policy view.
4)
Apply the QoS policy in Ethernet port view/port
group view.
l
The name and the rules of the class to which the
policy is to be bound to are determined.
l
The traffic behavior name and actions in the traffic
behavior in the policy are determined.
l
The policy name is determined.
l
Apply the QoS policy in Ethernet port view/port
group view.
To define a class, you need to create a
class and then define rules in the corresponding class view.
I. Configuration procedure
Follow these steps
to define a class:
|
To do…
|
Use the command…
|
Remarks
|
|
Enter system view
|
system-view
|
—
|
|
Create a class and enter the
corresponding class view
|
traffic classifier classifier-name [ operator { and | or
} ]
|
Required
By default, the and keyword is
specified. That is, the relation between the rules in the class view is logic
AND. This operation leads you to class view.
|
|
Define a rule used to match packets
|
if-match match-criteria
|
Required
|
match-criteria: Matching rules to be defined for a class. Table 3-1 describes
the available forms of this argument.
Table 3-1 The
form of the match-criteria argument
|
Form
|
Description
|
|
acl access-list-number
|
Specifies an ACL to match packets. The access-list-number
argument is in the range 2000 to 4999.
In a class configured with the
operator and, the logical relationship between rules defined in the
referenced IPv4 ACL is or.
|