With the increased use of the IP based networks, including the Internet, there
has been a large focus on providing necessary network resources to certain
applications. That is, it has become better understood that some applications are
more “important” than others, thereby demanding preferential treatment
throughout an internetwork. Additionally, applications have different demands,
such as real-time requirements of low latency and high bandwidth.
Why QoS?
In the Internet and intranets of today, bandwidth is an important subject. More
and more people are using the Internet for private and business purposes. The
amount of data that is being transmitted through the Internet is increasing
exponentially.
Multimedia applications, such as IP telephony and videoconferencing systems, need a lot more bandwidth than the applications that were used in the early years of the Internet. While traditional Internet applications, such as WWW, FTP, or Telnet, cannot tolerate packet loss but are less sensitive to variable delays, most real-time applications show just the opposite behavior, meaning they can compensate for a reasonable amount of packet loss but are usually very critical toward high variable delays.
This means that without any bandwidth control, the quality of these real-time
streams depends on the bandwidth that is currently available. Low or unstable
bandwidth causes bad quality in real-time transmissions by leading to, for
example, dropouts and hangs. Even the quality of a transmission using the
Real-Time Protocol (RTP) depends on the utilization of the underlying IP delivery
service.
Therefore, certain concepts are necessary to guarantee a specific quality of
service (QoS) for real-time applications on the Internet. A QoS can be described
as a set of parameters that describe the quality (for example, bandwidth, buffer
usage, priority, and CPU usage) of a specific stream of data. The basic IP
protocol stack provides only one QoS, which is called best-effort. Packets are
transmitted from point to point without any guarantee for a special bandwidth or
minimum time delay. With the best-effort traffic model, Internet requests are
handled with the first come, first serve strategy. This means that all requests
have the same priority and are handled one after the other. There is no possibility
to make bandwidth reservations for specific connections or to raise the priority for
special requests. Therefore, new strategies were developed to provide
predictable services for the Internet.
Today, there are two main rudiments to bring QoS to the Internet and IP-based
internetworks: Integrated Services and Differentiated Services.
Integrated Services
Integrated Services bring enhancements to the IP network model to support
real-time transmissions and guaranteed bandwidth for specific flows. In this
case, we define a flow as a distinguishable stream of related datagrams from a
unique sender to a unique receiver that results from a single user activity and
requires the same QoS.
For example, a flow might consist of one video stream between a given host pair.
To establish the video connection in both directions, two flows are necessary.
Each application that initiates data flows can specify which QoSs are required for
this flow. If the videoconferencing tool needs a minimum bandwidth of 128 kbps
and a minimum packet delay of 100 ms to assure a continuous video display,
such a QoS can be reserved for this connection.
Differentiated Services
Differentiated Services mechanisms do not use per-flow signaling, and as a
result, do not consume per-flow state within the routing infrastructure. Different
service levels can be allocated to different groups of users, which means that all
traffic is distributed into groups or classes with different QoS parameters. This
reduces the amount of maintenance required in comparison to Integrated
Services.
Integrated Services
The Integrated Services (IS) model was defined by an IETF working group to be
the keystone of the planned IS Internet. This Internet architecture model includes
the currently used best-effort service and the new real-time service that provides
functions to reserve bandwidth on the Internet and internetworks. IS was
developed to optimize network and resource utilization for new applications, such
as real-time multimedia, which requires QoS guarantees. Because of routing
delays and congestion losses, real-time applications do not work very well on the
current best-effort Internet. Video conferencing, video broadcast, and audio
conferencing software need guaranteed bandwidth to provide video and audio of
acceptable quality. Integrated Services makes it possible to divide the Internet
traffic into the standard best-effort traffic for traditional uses and application data flows with guaranteed QoS.
To support the Integrated Services model, an Internet router must be able to
provide an appropriate QoS for each flow, in accordance with the service model.
The router function that provides different qualities of service is called traffic
control. It consists of the following components:
Packet scheduler
The packet scheduler manages the forwarding of different packet streams in hosts and routers, based on their service class, using queue management and various
scheduling algorithms. The packet scheduler must ensure that the packet delivery corresponds to the QoS parameter for each flow. A scheduler can also police or
shape the traffic to conform to a certain level of service. The packet scheduler must be implemented at the point where packets are queued. This is typically the output driver level of an operating system and corresponds to the
link layer protocol.
Packet classifier
The packet classifier identifies packets of an IP flow in hosts and routers that will receive a certain level of service. To realize effective traffic control, each incoming packet is mapped by the classifier into a specific class. All
packets that are classified in the same class get the same treatment from the packet scheduler. The choice of a class is based on the source and destination IP address
and port number in the existing packet header or an additional classification number, which must be added to each packet. A class can correspond to a broad category of flows.
For example, all video flows from a video conference with
several participants can belong to one service class. But it
is also possible that only one flow belongs to a specific
service class.
Admission control
The admission control contains the decision algorithm that a router uses to determine if there are enough routing resources to accept the requested QoS for a new flow. If there are not enough free routing resources, accepting a
new flow would impact earlier guarantees and the new flow must be rejected. If the new flow is accepted, the reservation instance in the router assigns the packet
classifier and the packet scheduler to reserve the requested QoS for this flow. Admission control is invoked at each router along a reservation path to make a local
accept/reject decision at the time a host requests a real-time service. The admission control algorithm must be consistent with the service model.
Admission control is sometimes confused with policy control, which is a packet-by-packet function, processed by the packet scheduler. It ensures that a host does not
violate its promised traffic characteristics. Nevertheless, to ensure that QoS guarantees are honored, the admission control will be concerned with enforcing
administrative policies on resource reservations. Some policies will be used to check the user authentication for a requested reservation. Unauthorized reservation requests can be rejected. As a result, admission control can play
an important role in accounting costs for Internet resources in the future.
Differentiated Services
The Differentiated Services (DS) concept is currently under development at the
IETF DS working group. The DS specifications are defined in some IETF Internet
drafts. There is no RFC available yet. This section gives an overview of the
basics and ideas to provide service differentiation in the Internet. Because the
concept is still under development, some of the specifications mentioned in this
book might be changed in the final definition of differentiated services.
The goal of DS development is to provide differentiated classes of service for
Internet traffic to support various types of applications and meet specific
business requirements. DS offers predictable performance (delay, throughput,
packet loss, and so on) for a given load at a given time. The difference between
Integrated Services and Differentiated Services is that DS provides scalable service
discrimination in the Internet without the need for per-flow state and signaling at
every hop. It is not necessary to perform a unique QoS reservation for each flow.
With DS, the Internet traffic is split into different classes with different QoS
requirements.
A central component of DS is the service level agreement (SLA). An SLA is a
service contract between a client and a service provider that specifies the details
of the traffic classifying and the corresponding forwarding service a client should
receive. A client can be a user organization or another DS domain. The service
provider must assure that the traffic of a client, with whom it has an SLA, gets the
contracted QoS. Therefore, the service provider's network administration must
set up the appropriate service policies and measure the network performance to
guarantee the agreed traffic performance.
To distinguish the data packets from different clients in DS-capable network
devices, the IP packets are modified in a specific field. A small bit-pattern, called
the DS field, in each IP packet is used to mark the packets that receive a
particular forwarding treatment at each network node. The DS field uses the
space of the former TOS octet in the IPv4 IP header and the traffic class octet in
the IPv6 header. All network traffic inside of a domain receives a service that
depends on the traffic class that is specified in the DS field.
To provide SLA conform services, the following mechanisms must be combined
in a network:
Setting bits in the DS field (TOS octet) at network edges and administrative
boundaries.
Using those bits to determine how packets are treated by the routers inside
the network.
Conditioning the marked packets at network boundaries in accordance with
the QoS requirements of each service.
The currently defined DS architecture only provides service differentiation in one
direction and is therefore asymmetric. Development of a complementary
symmetric architecture is a topic of current research. The following section
describes the DS architecture in more detail.
Differentiated Services architecture
Unlike Integrated Services, QoS guarantees made with Differentiated Services
are static and stay long-term in routers. This means that applications using DS
do not need to set up QoS reservations for specific data packets. All traffic that
passes DS-capable networks can receive a specific QoS. The data packets must
be marked with the DS field that is interpreted by the routers in the network.
Per-hop behavior (PHB)
The DS field uses six bits to determine the Differentiated Services Code Point
(DSCP). This code point will be used by each node in the net to select the PHB.
A two-bit currently unused (CU) field is reserved. The value of the CU bits are
ignored by Differentiated Services-compliant nodes when PHP is used for
received packets.
Each DS-capable network device must have information about how packets with
different DS field should be handled. In the DS specifications, this information is
called the per-hop behavior (PHB). It is a description of the forwarding treatment
a packet receives at a given network node. The DSCP value in the DS field is
used to select the PHB a packet experiences at each node. To provide
predictable services, per-hop behaviors need to be available in all routers in a
Differentiated Services-capable network. The PHB can be described as a set of
parameters inside of a router that can be used to control how packets are
scheduled onto an output interface. This can be a number of separate queues
with priorities that can be set, parameters for queue lengths, or drop algorithms
and drop preference weights for packets.
DS requires routers that support queue scheduling and management to prioritize
outbound packets and control the queue depth to minimize congestion in the
network. The traditional FIFO queuing in common Internet routers provides no
service differentiation and can lead to network performance problems. The
packet treatment inside of a router depends on the router's capabilities and its
particular configuration, and it is selected by the DS field in the IP packet. For
example, if a IP packet reaches a router with eight different queues that all have
different priorities, the DS field can be used to select which queue is liable for therouting of this packet. The scale reaches from zero, for lowest priority, to seven
for highest priority.
Another example is a router that has a single queue with multiple drop priorities
for data packets. It uses the DS field to select the drop preference for the packets
in the queue. A value of zero means “it is most likely to drop this packet,” and
seven means “it is least likely to drop this packet.” Another possible constellation
is four queues with two levels of drop preference in each.
To make sure that the per-hop behaviors in each router are functionally
equivalent, certain common PHBs must be defined in future DS specifications to
avoid having the same DS field value causing different forwarding behaviors in
different routers of one DS domain. This means that in future DS specifications,
some unique PHB values must be defined that represent specific service
classes. All routers in one DS domain must know which service a packet with a
specific PHB should receive. The DiffServ Working Group will propose PHBs that
should be used to provide differentiated services. Some of these proposed PHBs
will be standardized; others might have widespread use, and still others might
remain experimental.
Queue 7 (Highest Priority)
Queue 5
Queue 6
Queue 4
Queue 3
Queue 2
Queue 1
Queue 0 (Lowest Priority)
PHBs will be defined in groups. A PHB group is a a set of one or more PHBs that
can only be specified and implemented simultaneously because of queue
servicing or queue management policies that apply to all PHBs in one group. A
default PHB must be available in all DS-compliant nodes. It represents the
standard best-effort forwarding behavior available in existing routers. When no
other agreements are in place, it is assumed that packets belong to this service
level.
The IETF working group recommends that you use the DSCP value
000000 in the DS field to define the default PHB.
Another PHB that is proposed for standardization is the Expedited Forwarding
(EF) PHB. It is a high priority behavior that is typically used for network control
traffic, such as routing updates. The value 101100 in the DSCP field of the DS
field is recommended for the EF PHB.
Organization of the DSCP
There are some IANA considerations concerning the DSCP. The codepoint
space for the DSCP distinguishes between 64 codepoint values. The proposal is
to divide the space into tree pools. Pool1 can be used for standard actions. The
other pools can be used for experimental local usage, where one of the two pools
is provided for experimental local use in the near future.
The proposal is to divide the space into three pools.
Differentiated Services domains
The setup of QoS guarantees is not made for specific end-to-end connections
but for well-defined Differentiated Services domains. The IETF working group
defines a Differentiated Services domain as a contiguous portion of the Internet
over which a consistent set of Differentiated Services policies are administered in
a coordinated fashion. It can represent different administrative domains or
autonomous systems, different trust regions, and different network technologies,
such as cell or frame-based techniques, hosts, and routers. A DS domain
consists of boundary components that are used to connect different DS domains
to each other and interior components that are only used inside of the domains.
Pool Codepoint space Assignment
1 xxxxx0 Standard action
2 xxxx11 Experimental/local use
3 xxxx01 Future experimental /local use
DS domain
A DS domain normally consists of one or more networks under the same
administration. This can be, for example, a corporate intranet or an Internet
service provider (ISP). The administrator of the DS domain is responsible for
ensuring that adequate resources are provisioned and reserved to support the
SLAs offered by the domain. Network administrators must use appropriate
measurement techniques to monitor if the network resources in a DS domain are
sufficient to satisfy all authorized QoS requests.
DS boundary nodes
All data packets that travel from one DS domain to another must pass a
boundary node, which can be a router, a host, or a firewall. A DS boundary node
that handles traffic leaving a DS domain is called an egress node and a boundary
node that handles traffic entering a DS domain is called an ingress node.
Normally, DS boundary nodes act both as an ingress node and an egress node,
depending on the traffic direction. The ingress node must make sure that the
packets entering a domain receive the same QoS as in the domain the packets
traveled before. A DS egress node performs conditioning functions on traffic that
is forwarded to a directly connected peering domain. The traffic conditioning is
done inside of a boundary node by a traffic conditioner. It classifies, marks, and
possibly conditions packets that enter or leave the DS domain. A traffic
conditioner consists of the following components:
Classifier A classifier selects packets based on their packet header
and forwards the packets that match the classifier rules
for further processing. The DS model specifies two types
of packet classifiers:
• Multi-field (MF) classifiers, which can classify on the
DS field as well as on any other IP header field, for
example, the IP address and the port number, like
an RSVP classifier
• Behavior Aggregate (BA) classifiers, which only
classify on the bits in the DS field
Meter Traffic meters measure if the forwarding of the packets
that are selected by the classifier corresponds to the
traffic profile that describes the QoS for the SLA between
client and service provider. A meter passes state
information to other conditioning functions to trigger a
particular action for each packet, which either does or
does not comply with the requested QoS requirements.
Marker DS markers set the DS field of the incoming IP packets to
a particular bit pattern. The PHB is set in the first 6 bits of
the DS field so that the marked packets are forwarded
inside of the DS domain according to the SLA between
service provider and client.
Shaper/dropper Packet shapers and droppers cause conformance to
some configured traffic properties, for example, a token
bucket filter, They use different methods to bring the stream
into compliance with a traffic profile. Shapers delay some
or all of the packets. A shaper usually has a finite-size
buffer, and packets can be discarded if there is not
sufficient buffer space to hold the delayed packets.
Droppers discard some or all of the packets. This process
is know as policing the stream. A dropper can be
implemented as a special case of a shaper by setting the
shaper buffer size to zero packets.
The traffic conditioner is mainly used in DS boundary components, but it can also
be implemented in an interior component. Figure 8-16 shows the cooperation of
the traffic conditioner components.
DS traffic conditioner
The traffic conditioner in a boundary component makes sure that packets that
transit the domain are correctly marked to select a PHB from one of the PHB
groups supported within the domain. This is necessary because different DS
domains can have different groups of PHBs, which means that the same entry in
the DS field can be interpreted variably in different domains.
For example, in the first domain a packet traverses, all routers have four queues
with different queue priorities (0-3). Packets with a PHB value of three are routed
with the highest priority. But in the next domain the packet travels through, all
routers have eight different queues and all packets with the PHB value of seven
are routed with the highest priority. The packet that was forwarded in the first
domain with high priority has only medium priority in the second domain. This
might violate the SLA contract between the client and the service provider.
Therefore, the traffic conditioner in the boundary router that connects the two
domains must assure that the PHB value is remarked from three to seven if the
packet travels from the first to the second domain.
Remarking data packets
If a data packet travels through multiple domains, the DS field can be remarked
at every boundary component to guarantee the QoS that was contracted in the
SLA. The SLA contains the details of the Traffic Conditioning Agreement (TCA)
that specifies classifier rules and temporal properties of a traffic stream. The TCA
contains information about how the metering, marking, discarding, and shaping
of packets must be done in the traffic conditioner to fulfill the SLA. The TCA
information must be available in all boundary components of a DS network to
guarantee that packets passing through different DS domains receive the same
service in each domain.
DS interior components
The interior components of a DS domain select the forwarding behavior for
packets based on their DS field. The interior component is usually a router that
contains a traffic prioritization algorithm. Because the value of the DS field
normally does not change inside of a DS domain, all interior routers must use the
same traffic forwarding policies to comply with the QoS agreement. Data packets
with different PHB values in the DS field receive different QoSs according to the
QoS definitions for this PHB. Because all interior routers in a domain use the
same policy functions for incoming traffic, the traffic conditioning inside of an
interior node is done only by a packet classifier. It selects packets based on their
PHB value or other IP header fields and forwards the packets to the queue
management and scheduling instance of the node.
DS interior component
Traffic classifying and prioritized routing is done in every interior component of a
DS domain. After a data packet has crossed a domain, it reaches the boundary
router of the next domain and possibly gets remarked to cross this domain with
the requested QoS.
Source domains
The IETF DS working group defines a source domain as the domain that
contains one or more nodes that originate the traffic that receives a particular
service. Traffic sources and intermediate nodes within a source domain can
perform traffic classification and conditioning functions. The traffic that is sent
from a source domain can be marked by the traffic sources directly or by
intermediate nodes before leaving the source domain.
In this context, it is important to understand that the first PHB marking of the data
packets is not done by the sending application itself. Applications do not notice
the availability of Differentiated Services in a network. Therefore, applications
using DS networks must not be rewritten to support DS. This is an important
difference from Integrated Services, where most applications support the RSVP
protocol directly when some code changes are necessary.
The first PHB marking of packets that are sent from an application is done in the
source host or the first router the packet passes. The packets are identified with
their IP address and source port. For example, a client has an SLA with a service
provider that guarantees a higher priority for the packets sent by an audio
application. The audio application sends the data packets through a specific port
and can be recognized in multi-field classifiers. This classifier type recognizes
the IP address and port number of a packet and can distinguish the packets from
different applications. If the host contains a traffic conditioner with an MF
classifier, the IP packet can be marked with the appropriate PHB value and
consequently receives the QoSs that are requested by the client. If the host does
not contain a traffic conditioner, the initial marking of the packets is done by the
Interior Router
RFCs:
The following RFCs provide detailed information about the connection protocols
and architectures presented throughout this chapter:
RFC 1349 – Type of Service in the Internet Protocol Suite (July 1992)
RFC 1633 – Integrated Services in the Internet Architecture: An Overview
(June 1994)
RFC 4495 – A Resource Reservation Protocol (RSVP) Extension for the
Reduction of Bandwidth of a Reservation Flow (May 2006)
RFC 2206 – RSVP Management Information Base Using SMIv2
(September 1997)
RFC 2207 – RSVP Extensions for IPSEC Data Flows (September 1997)
RFC 2208 – Resource Reservation Protocol (RSVP) – Version 1 Applicability
Statement (September 1997)
RFC 2209 – Resource Reservation Protocol (RSVP) – Version 1 Message
Processing Rules (September 1997)
RFC 2210 – The Use of RSVP with IETF Integrated Services
(September 1997)
RFC 2211 – Specification of the Controlled Load Network Element Service
(September 1997)
