®
White Paper
Implementing Quality of Service with Altera PLDs
Introduction
Internet protocol (IP) networks have long provided adequate services for traditional Internet applications, such as
e-mail, web browsing, and file transferring. These IP networks are based on a simplistic architecture where IP packets
are sent into a network cloud and each network device routes the packet one step closer to its destination. However,
traditional IP networks cannot guarantee that a packet will not be delayed or dropped, even if the packet is very
important. Delaying or dropping of packets does not significantly affect traditional Internet applications, but with the
convergence of voice, data, and video networks, IP networks need to evolve. Emerging Internet applications, such as
real-time voice and video streaming, cannot operate effectively in traditional IP networks with congestion. To accommodate these emerging applications that place stringent requirements on networks, quality of service (QoS) functions
are required.
This white paper describes QoS fundamentals, QoS functions, and how to implement QoS with Altera® PLDs.
QoS Fundamentals
QoS functions provides consistent and predictable data delivery service. The goal of QoS functions is to provide end
applications with the ability to determine how the application’s packet should be handled. For example, QoS functions can support an application that requires a dedicated amount of bandwidth and a limited delay. QoS functions can
also provide prioritization of certain network traffic.
QoS Solutions
Emerging Internet applications demand additional bandwidth in the Internet's core. However, adding bandwidth is not
a long-term solution to the growing congestion in network backbones. Most network traffic needs to be classified
and/or given assurances of performance during transmission. When bandwidth is added to Internet service providers’
(ISPs) networks, traffic rapidly increases until capacity is reached. By itself, adding bandwidth to a network is a
costly, short-term solution. By implementing QoS functions in a network, revenue generating traffic receives efficient
and reliable service.
When packets are sent into a traditional IP network, a routing algorithm known as “best-effort routing” moves a
packet to its destination. Best-effort routing looks at a packet’s destination address and determines the next hop.
Best-effort routing is performed at each node until the packet reaches its destination. However, best-effort routing
cannot guarantee when the packet will arrive and how much bandwidth the source application will be given. The simplicity of best-effort routing allows IP networks to be flexible and scalable. However, IP does not provide many other
functions or services. Network users want reliable, efficient, and predictable behavior from their networks.
Example of QoS Solution: VoIP
A prime example of where QoS is required is in voice over Internet protocol (VoIP) applications. Traditional phone
networks use circuit switching to transmit voice information. In a circuit-switched network, dedicated bandwidth is
given to users regardless if information is being conveyed (i.e., silence). The use of packet-switched networks to convey voice information is attractive because only the required information is sent (silence does not use bandwidth).
However, during congestion, a voice packet can experience delay, jitter, or may be dropped. Congestion results in
degradation of voice quality. If a QoS-enabled network is used, voice traffic will flow through a network without
interference from other low-priority applications. For example, if QoS is not implemented, a large file download
could cause the transmission of a real-time voice conversation to be jittery and delayed.
M-WP-EXCQOS-01
March 2001, ver. 1.0
1
Altera Corporation
Implementing Quality of Service with Altera PLDs
QoS Functions
There are two types of QoS functions, priority-based QoS and reservation-based QoS.
Priority-based QoS (e.g., differentiated services) allows network traffic to be classified by using packet header information or other criteria set by a network administrator. This classification allows congestion-sensitive traffic to be prioritized and given a proportional amount of resources.
With reservation-based QoS (e.g., resource reservation protocol), network elements (such as applications and routers)
reserve resources over a network from source to destination. As a result, specific applications receive the required
amount of bandwidth and a limited amount of delay on their traffic.
DiffServ
To provide differentiated services (DiffServ) in a network, traffic must be divided into a small number of classes.
Resources are allocated on a per-class basis within each router. For example, a simple DiffServ network may have
three classes of packets: low-, medium- and high-priority packets. High-priority packets receive an assurance of low
delay and high bandwidth. Medium-priority receive a lesser level of assurance for delay and bandwidth. Low-priority
packets receive no assurances and simply receive best-effort routing.
Packet classification is based on the value of the DiffServ field in the IP header. Figure 1 describes a DiffServ field
that is six bits long and is divided into two different sub-values: class and drop precedence.
Figure 1. DiffServ Field in IP Header
0
1
2
Precedence
TOS (2)
Version IHL (1)
Identification
Flags
Total Length
Fragment Offset
Source Address
3
4
5
Class
Version
Class
Payload Length
Flow Label
Next Header
Hop Limit
Source Address
Destination Address
Options
IPv4 Header
Padding
Destination Address
IPv6 Header
Notes
(1) TOS: Type of service.
(2) IHL: IP header length.
DiffServ Elements
A DiffServ system has four types of data-path elements: traffic classifiers, meters, action elements, and queuing elements. Action elements have four sub-elements: markers, absolute droppers, multiplexers, and counters. Queuing elements have three sub-elements: algorithmic droppers, schedulers, and queues. Figure 2 depicts the relationship
between the elements. Combinations of these elements into higher-level blocks are known as traffic-conditioning
blocks (TCBs). TCBs are controlled by a DiffServ configuration and management tools.
2
Altera Corporation
Implementing Quality of Service with Altera PLDs
Figure 2. High-Level Overview of DiffServ Elements
Action
Elements
Classifier
Packet In
Queues
Queueing
Meters
Algorithmic Dropper
Excalibur
Embedded
Processor
Discard
Packet Out
Embedded System Block
Scheduler
Programmable Logic Solution
Excalibur Embedded Processor
Solution
Expedited Forwarding Queue
Assured Forwarding Queue
This section describes the following DiffServ elements:
■
■
■
■
■
■
Classifier
Meter
Action
Algorithmic Dropper
Scheduler
Queues
Classifier
The classifier element separates a stream of incoming packets into aggregates. The most common type of classifier is
the behavior aggregate classifier. The behavior aggregate classifier uses the DiffServ field in the IP packet header to
determine how the packet should be directed.
Figure 3 is a block diagram of a behavior aggregate classifier from the QuartusTM II development tool; it depicts how
a basic behavior aggregate classifier can be implemented. The behavior aggregate classifier receives a packet pointer
along with its class. A packet pointer is a pointer (address location) to a packet stored in memory. Using the class
value, the packet pointer is classified into one of four classes. This classifier divides traffic into four priority-based
traffic flows.
3
Altera Corporation
Implementing Quality of Service with Altera PLDs
Figure 3. Block Diagram of a Behavior Aggregate Classifier
Pointer2Packet[31..0]
DEMUX32
PRIORITYGROUPER
PriorityGroups[11..0]
Class[2..0]
add[31..0]
sel[1..0]
PriorityGroups[11..0] FIFOSelect[1..0]
Class[2..0]
inst
f1[31..0]
f2[31..0]
f3[31..0]
f4[31..0]
FIFO1data[31..0]
FIFO2data[31..0]
FIFO3data[31..0]
FIFO4data[31..0]
inst6
write
clock
FIFOfull1
FIFOfull2
FIFOfull3
FIFOfull4
FIFOWRCT
write
FIFO1wrreq
FIFO2wrreq
clock
FIFOFull1
FIFO3wrreq
FIFOFull2
FIFO4wrreq
FIFOFull3
All_FIFOs_Full
FIFOFull4
FIFOFullout
FIFOSelect[1..0]
FIFO1wrreq
FIFO2wrreq
FIFO3wrreq
FIFO4wrreq
All_FIFOs_Full
FIFOFullout
inst1
When a packet is ready to be classified and queued, write, Class[2..0], and Pointer2Packet[31..0]
are passed into the system. The PRIORITYGROUPER module reads the value of Class[2..0] and outputs the
corresponding priority group number the packet falls into. DEMUX32 is a 32-bit demultiplexer that directs the
pointer through to the appropriate output according to the selection determined by the FIFOSelect[1..0] value
coming from the PRIORITYGROUPER. At the same time, the write signal is being asserted, which triggers the
FIFOWRCT module to read FIFOSelect[1..0] from the PRIORITYGROUPER and assert a write signal to
the corresponding first-in first-out (FIFO) that will accept the pointer.
Table 1 lists the modules of the classifier and a description of the modules’ inputs and outputs.
Table 1. Modules and the Modules’ Inputs and Outputs
Modules
PRIORITYGROUPER
DEMUX32
FIFOWRCT
Input
Output
Class[2..0] - (Input) class field from the DiffServ
field corresponding to the packet currently being
input.
PriorityGroups[11..0] - (Input) 12-bit value
divided into 4 sections (3 bits each that defines how
DiffServ field bit patterns are categorized into priority
groups).
Add[31..0] - (Input) 32-bit address (pointer) of
where a particular packet is located in memory.
sel[1..0] - (Internal Node) indicates to DEMUX32
and FIFOWRCT which FIFO to output to.
write - (Input) indicates that a packet pointer is
entering and it should be written.
FIFOSelect[1..0] - (Internal Node) indicates to
DEMUX32 and FIFOWRCT which FIFO to output to.
FIFOndata[31..0] - (Output) passes a pointer to
a packet to the nth FIFO.
FIFOnwrreq - (Output) instructs the nth FIFO to
accept FIFOndata[31..0] currently being sent to
it.
FIFOfulln - (Input) indicates that the nth FIFO is All_FIFOs_full - (Output) outputs a signal back
full. Input from FIFO.
to the module inputting the packet indicating that all
FIFOs are full.
FIFOSelect[1..0] - (Internal Node) indicates to FIFOfull - (Output) outputs a signal back to the
DEMUX32 and FIFOWRCT which FIFO to output to. module inputting the packet indicating that the targeted FIFO is full.
To implement expedited forwarding (EF), the PRIORITYGROUPER module could filter out the EF marked packets
and route them to FIFO1data[31..0]. An additional FIFO could be added to continue support for four classes of packets. To fulfill the expedited forwarding requirements, the required functions should be inline with EF functions that
line downstream from fifo1data[31..0].
4
Altera Corporation
Implementing Quality of Service with Altera PLDs
If a classifier requires the use of IP packet header information other than the DiffServ field, a content addressable
memory (CAM)-RAM technique can be used as a look-up mechanism. Figure 4 depicts an example of how a CAM
and RAM combination can be used to determine priority using the source IP address. Using a CAM and RAM combination, provides a simple, efficient, and high-performance solution that allows a packet’s priority to be quickly and
efficiently determined. Designers can take advantage of the pre-defined, high-performance CAM and RAM megafunctions (library modules) available in Quartus II.
Figure 4. Using CAM and RAM Combination To Implement Priority Look-Up in APEX Devices
RAM
CAM
IP Address
Address
192.25.27.28
09
Address
Classification
09
High
Address
IP Address
192.25.22.xxx
0A
0A
Low
192.1.5.119
0B
0B
Med
...
...
...
...
Class
For more information on APEXTM CAM and other applications related to APEX CAM, see Application Note 119
(Implementing High-Speed Search Applications with APEX CAM).
Meter
A meter measures a traffic stream selected by a classifier against a traffic profile in the traffic control specification
(TCS) or also known as traffic control agreement (TCA). In general, a meter outputs information that indicates
whether a traffic stream meets the specifications described in the TCS. Normally, this information leads to an action
function that aids in conditioning the traffic stream to meet the TCS.
Since a meter is already measuring conforming and nonconforming traffic, a meter can also be used for collecting
data for management functions, such as billing applications.
Action
Classifiers and meters perform their functions and influence what type of action will be applied to a traffic stream.
Actions can be arranged to apply the desired effect on a traffic stream.
Table 2 describes the four types of action elements. Actions elements are easily implemented in logic, which provides
speed and efficiency.
Table 2. Description of Action Elements
Action Elements
Marker
Absolute Dropper
Multiplexor
Counter
Description
Sets the DiffServ codepoint (DSCP) value in the IP header. The DSCP value represents the packet’s priority.
Drops packets
Merges many traffic streams into one stream
Accounts for the number and size of packets passing through the counter. The statistics that result may
be used later for customer billing, service verification, or network engineering purposes. Counters can
be used to count packets about to be dropped by an absolute dropper or to count packets arriving at or
departing from some other functional element
5
Altera Corporation
Implementing Quality of Service with Altera PLDs
Algorithmic Dropper
Network congestion ultimately results in packets being dropped. An algorithmic dropper is a function that determines
when packets should be dropped. Packet-dropping could be triggered by many things, including a queue exceeding its
threshold or a buffer pool depth falling below a threshold.
Examples of dropping algorithms include weighted random early detection (WRED) and drop-on-threshold. Figure 5
shows how a WRED example works in a given class. In Figure 5, packets of high, medium, and low precedence (as
defined by their DSCP values) are classified into buckets. When traffic increases and approaches congestion, low-precedence packets can be randomly dropped. If packets are being dropped in the network, transmission control protocol
(TCP) inherently throttles back transmission at the source. When using WRED and TCP and when traffic starts to
approach levels where a WRED-enabled router thinks congestion may occur, low-precedence packets are dropped. At
the source, TCP detects the dropping of packets and slows down the rate in which packets leave until packets are no
longer being dropped. TCP provides a traffic-smoothing function by trying to smooth out high peaks in network traffic. At the same time, critical applications get the required bandwidth. If needed, random dropping can also occur
with higher-precedence packets.
Figure 5. WRED Example
High
Precedence
Medium
Precedence
Low
Precedence
Random dropping of lowprecedence packets
during congestion
Algorithmic droppers can be implemented in a variety of ways. For an efficient algorithmic dropper implementation
that meets performance requirements, embedded processors provide the optimal platform.
Scheduler
A scheduler is an element that gates the departure of each packet based on its scheduling algorithm. Schedulers interact with queues to control the output of packets. To smooth out varying rates of traffic, use regulated temporal
dequeuing controls or “leaky buckets.” Scheduling algorithms, such as weighted fair queuing (WFQ) and weighted
round-robin (WRR), and “leaky buckets” are algorithms that provide traffic smoothing and resource allocation across
multiple queues.
In WFQ, each queue is assigned a weight based on the priority of its corresponding traffic stream. The weight for
each class should be configurable by the network administrator. The queue with a given weight gets to transmit data
at the corresponding rate relative to other weights placed on other queues. The particular queue is guaranteed that
rate. If the particular queue does not need to transmit at the assigned rate, the available bandwidth will be transferred
to the highest weighted queue that requires the bandwidth.
6
Altera Corporation
Implementing Quality of Service with Altera PLDs
Altera’s ExcaliburTM embedded processor solutions offer an optimal platform to implement scheduling algorithms. To
access buffered packets in external memory, the ARM®-based and MIPSTM-based processor solutions offer external
SDRAM (PC133) and double data rate (DDR-PC266) interfaces up to 512 Mbits and 256 Mbits, respectively.
Queues
Buffering is an important detail when accommodating rapid change in the rate of receiving packets. Storing packets
in memory and using pointers as a reference is an efficient method of queuing packets. The size of a FIFO is system-dependent. When deciding the size of the FIFO, consider the following design factors: average rate of receiving
packets for each class and the peak rate of receiving packets for each class.
Packet-pointer buffering can be accomplished with Altera’s LPM_FIFO megafunction. Instantiating five LPM_FIFO
functions would provide adequate support for four priority levels and an expedited forwarding queue. Figure 6 shows
an LPM_FIFO diagram from the Quartus II development tool. The function is parameterizable and includes options
to control the size of the FIFO, how it should function, and the required ports.
Figure 6. LPM_FIFO block from Altera’s Quartus II Development Tool
lpmfifo
data[31..0]
wrreq
rdreq
clock
q[31..0]
full
almost_full
empty
usedw[6..0]
sclr
almost full at 102
32 bits x 128 words
inst
RSVP
Resource reservation protocol (RSVP) is a signaling protocol that enables integrated services on the Internet. Integrated services provide dedicated resources over a network to an application, thus allowing end-to-end QoS. RSVP is
a protocol used by a network to set up and use integrated services. There are two fundamental integrated services:
guaranteed and controlled load. Guaranteed load provides firm bounds on various parameters such as bandwidth and
delay. Controlled load is used to provide better-than-best-effort service under loaded conditions. Controlled load is
useful for applications where performance degrades significantly in overloaded situations.
Recently, RSVP has been adopted to perform label distribution in multiprotocol label switching (MPLS) networks.
For more information, see AN 132 (Implementing Multiprotocol Label Switching with Altera PLDs).
RSVP Elements
This section provides a brief description of RSVP. For more information on RSVP, see the IETG RSVP working
group web page, available at http://www.ietf.org/html.charters/rsvp-charter.html.
Figure 7 shows a diagram of RSVP signaling in a network.
7
Altera Corporation
Implementing Quality of Service with Altera PLDs
Figure 7. Flow of RSVP Signaling through a Network
2. A PATH message is sent containing the tspec
message to each RSVP-enabled router that is along
a route to the destination. Each router maintains a
path-state that has the previous router address
stored (i.e., the route the PATH message came
from). Maintaining the path-state is required to retain
the path that needs to be taken back to the source.
4. Each RSVP router along the upstream path
receives and authenticates the RESV message. The
RSVP router then allocates the required resources.
If there is an authorization failure or a lack of
resources, the router returns an error message back
to the destination. When the router closest to the
source receives the RESV message, it will send a
confirmation message to the source.
1. Application requests resources
from the network. The application
defines bounds on bandwidth,
delay, and jitter for a flow of data
and puts this information into a
traffic
specification
(tspec)
message.
Sender
Receiver
End-to-End Integrated Services
PATH Message
RESV Message
Switching Router
3. The receiver accepts the PATH message and
sends out a RESV message upstream, which
contains the original tspec, request specification
(rspec), and filter specfication (fspec). The rspec
indicates whether to use controlled load or
guaranteed load. The fspec designates the packets
being reserved to a particular reservation (by using
the transport protocol and port number). Together,
the fspec and rspec form the flow descriptor. The
flow descriptor is used to identify each reservation.
Implementing QoS in Altera PLDs
Many QoS functions can only be effectively implemented across a platform that combines hardware and software. By
combining programmable logic and RISC processors, Altera’s Excalibur embedded processor solutions can implement QoS functions. Altera devices have the following features that are useful for QoS functions.
■
■
■
■
■
CAM for various lookup functions
Parameterizable FIFO buffers for queueing
LVDS interface for performance of up to 840 Mbps per channel
RISC processor options, including the MIPS-based, ARM-based, and NiosTM-based embedded processor solutions
DDR interface to external SDRAM
For QoS system designers, products are distinguished by value-added services. The system platform must be flexible
when implementing new value-added functions because the functions must address an ISP’s long-term requirements.
Excalibur embedded processor solutions offer a combination of programmable logic and embedded processors that
provide the required flexibility for implementing QoS systems. Altera devices are capable of remote field upgrades, a
key feature that is only possible with PLDs. Upgrades to ASIC solutions are nearly impossible due to their high,
non-recurring engineering (NRE) costs and long turnaround times.
To effectively implement a QoS system, designers will need to implement a combination of logic and processor-based
functions. Having separate chips implement these functions can cause problems, such as performance degradation,
8
Altera Corporation
Implementing Quality of Service with Altera PLDs
more board space is consumed, and an increase in design time. On the other hand, a single-chip ASIC solution will
render the implementation inflexible, increase time-to-market, and will quickly become obsolete. Altera’s Excalibur
embedded processor solutions offer an easy solution to these problems. The configurable Nios-based RISC processor
solution can be instantiated multiple times into programmable logic, providing a multiprocessor platform in a single
device. The ARM-based and MIPS-based processors are processor cores that are embedded in a device surrounded by
programmable logic.
Implementing DiffServ in Altera PLDs
The building blocks of a DiffServ system depend on the designer’s requirements. Simple functions, such as classifiers, meters, actions, and queues, can be implemented in logic. Processing-intense functions, such as algorithmic droppers and scheduling algorithms, require the use of software. Even with these varying requirements, Altera's Excalibur
embedded processor solutions provide a complete solution to implement all of these functions. Table 3 describes how
the QoS functions are implemented in Altera PLDs.
Table 3. Implementation of QoS Functions in Altera PLDs
QoS Function
Classifiers
Actions
Meters
Schedulers and Droppers
Queues
Implementation in Altera PLDs
Prioritization can be implemented in logic. CAM-RAM technique for additional prioritization support
Simple functions that can be instantiated in logic
Simple functions that can be instantiated in logic with an interface to embedded software for administration purposes
Both are processing-intense functions that are easily implemented in a high-performance software/hardware platform
Parameterizable LPM_FIFO instances in logic
Implementing RSVP in Altera PLDs
To implement RSVP, use a software/hardware solution. Altera's Excalibur embedded processor solutions offer an
optimal platform to implement these functions, in which a 32-bit ARM-based or MIPS-based processor is embedded
in a device with Altera programmable logic. With the ARM-based and MIPS-based processor solutions, there is a
direct interface to the programmable logic on the device. In addition to the ARM-based and MIPS-based processor
solutions, Altera also offers the Nios embedded processor solutions, a RISC processor core. One main advantage of
Nios embedded processor solutions is that they allow for multiprocessor capability on a single device since they can
be instantiated many times within a PLD.
Conclusion
QoS functions are implemented in network equipment to give service providers more flexibility and provide valueadded services to their customers. However, to stay flexible without compromising performance, router manufacturers must offer value-added services and an ability to update equipment with newer algorithms. In addition, router
manufacturers must consider time-to-market and the QoS functions’ platform. The Altera portfolio of intellectual
property functions, high-density PLDs with advanced features, and Excalibur embedded processor solutions offer the
most complete solution for QoS systems.
References
Internet Engineering Task Force. DiffServ Working Group References. Available from http://www.ietf.org/
html.charters/diffserv-charter.html. October 2000.
Leon-Garcia, Alberto, and Widjaja, Indra. Communication Networks: Fundamental Concepts and Key Architectures.
2000.
QoS Forum. Available from http://www.qosforum.com/. October 2000.
9
Altera Corporation
®
101 Innovation Drive
San Jose, CA 95134
(408) 544-7000
http://www.altera.com
Implementing Quality of Service with Altera PLDs
Copyright  2001 Altera Corporation Altera, APEX, ARM, Excalibur, MIPS, Nios, and Quartus II are trademarks and/or service marks of
Altera Corporation in the United States and other countries. Altera acknowledges the trademarks of other organizations for their respective
products or services mentioned in this document. Altera products are protected under numerous U.S. and foreign patents and pending
applications, maskwork rights, and copyrights. Altera warrants performance of its semiconductor products to current specifications in
accordance with Altera’s standard warranty, but reserves the right to make changes to any products and services at any time without notice.
Altera assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except
as expressly agreed to in writing by Altera Corporation. Altera customers are advised to obtain the latest version of device specifications before
relying on any published information and before placing orders for products or services. All rights reserved.
10