Qos

Internet QoS: A Big Picture

Xipeng Xiao and Lionel M. Ni

Department of Computer Science
3115 Engineering Building
Michigan State University
East Lansing, MI 48824-1226

{xiaoxipe,ni}@cse.msu.edu

Abstract

In this paper we present a framework for the emerging Internet Quality of Service (QoS). All
the important components of this framework, i.e., Integrated Services, RSVP, Differentiated
Services, Multi-Protocol Label Switching (MPLS) and Constraint Based Routing are cov-
ered. We describe what Integrated Services and Differentiated Services are, how they can
be implemented, and the problems they have. We then describe why MPLS and Constraint
Based Routing have been introduced into this framework, how they differ from and relate to
each other, and where they fit into the Differentiated Services architecture. Two likely
service architectures are presented, and the end-to-end service deliveries in these two archi-
tectures are illustrated. We also compare ATM networks to router networks with Differen-
tiated Services and MPLS. Putting all these together, we give the readers a grasp of the big
picture of the emerging Internet QoS.

Keywords: Internet, QoS, Integrated Services, RSVP, Differentiated Services, MPLS,
Constraint Based Routing, Traffic Engineering

1. Introduction
Today’s Internet only provides Best Effort Service. Traffic is processed as quickly as possible, but there is no
guarantee as to timeliness or actual delivery. With the rapid transformation of the Internet into a commercial
infrastructure, demands for service quality have rapidly developed [1-4].
It is becoming apparent that several service classes will likely be demanded. One service class will pro-
vide predictable Internet services for companies that do business on the Web. Such companies will be will-
ing to pay a certain price to make their services reliable and to give their users a fast feel of their Web sites.
This service class may contain a single service. Or, it may contain Gold Service, Silver Service and Bronze
Service, with decreasing quality. Another service class will provide low delay and low jitter services to ap-
plications such as Internet Telephony and Video Conferencing. Companies will be willing to pay a premium

price to run a high quality videoconference to save travel time and cost. Finally, the Best Effort Service will
remain for those customers who only need connectivity.
Whether mechanisms are even needed to provide QoS is a hotly debated issue. One opinion is that fibers
and Wavelength Division Multiplexing (WDM) will make bandwidth so abundant and cheap that QoS will
be automatically delivered. The other opinion is that no matter how much bandwidth the networks can pro-
vide, new applications will be invented to consume them. Therefore, mechanisms will still be needed to pro-
vide QoS. This argument is beyond the scope of this paper [5]. Here we simply note that, even if bandwidth
will eventually become abundant and cheap, it is not going to happen soon. For now, some simple mecha-
nisms are definitely needed in order to provide QoS on the Internet. Our view is supported by the fact that
all the major router/switch vendors now provide some QoS mechanisms in their high-end products [14-19].
The Internet Engineering Task Force (IETF) has proposed many service models and mechanisms to meet
the demand for QoS. Notably among them are the Integrated Services/RSVP model [4, 8], the Differentiated
Services (DS) model [23, 24], MPLS [34], Traffic Engineering [37] and Constraint Based Routing [44].
The Integrated Services model is characterized by resource reservation. For real-time applications, before
data are transmitted, the applications must first set up paths and reserve resources. RSVP is a signaling pro-
tocol for setting up paths and reserving resources. In Differentiated Services, packets are marked differently
to create several packet classes. Packets in different classes receive different services. MPLS is a forward-
ing scheme. Packets are assigned labels at the ingress of a MPLS-capable domain. Subsequent classification,
forwarding, and services for the packets are based on the labels. Traffic Engineering is the process of ar-
ranging how traffic flows through the network. Constraint Based Routing is to find routes that are subject to
some constraints such as bandwidth or delay requirement.
Although there are many papers on each of Integrated Services, RSVP, Differentiated Services, MPLS,
Traffic Engineering and Constraint Based Routing, to the best of the authors’ knowledge, they are never dis-
cussed together in a single paper. As a result, it is difficult for readers to understand the relationships among
them and to grasp the big picture of the QoS framework.
In this paper, we give an introduction to Integrated Services, RSVP, Differentiated Services, MPLS,
Traffic Engineering and Constraint Based Routing. We describe how they differ from, relate to, and work
with each other to deliver QoS on the Internet. Through this, we intend to present the readers a clear over-
view of Internet QoS.
The organization of the rest of the paper is as follows. In Sections 2-3, we describe Integrated Services,
RSVP and Differentiated Services, their characteristics, mechanisms, and problems. A likely Differentiated
Services architecture and the complete process for delivering end-to-end services in this architecture are also
presented. MPLS and a service architecture based on MPLS are described in Section 4. In Section 5, we de-
scribe Traffic Engineering and Constraint Based Routing. ATM networks and router networks are compared
in Section 6. Finally, we summarize the paper in Section 7.

2

The frequently used terminologies in this paper are defined below.
Flow A stream of packets with the same source IP address, source port number, destina-
tion IP address, destination port number and protocol ID.
Service Level A service contract between a customer and a service provider that specifies the for-
Agreement (SLA) warding service a customer should receive. A customer may be a user organization
or another provider domain (upstream domain).
Traffic Profile A description of the properties of a traffic stream such as rate and burst size.
Differentiated The field in which the Differentiated Services class is encoded. It is the Type of
Services (DS) field Service (TOS) octet in the IPv4 header or the Traffic Class octet in the IPv6 header.
Per-Hop-Behavior The externally observable behavior of a packet at a DS-compliant router
(PHB)
Mechanism A specific algorithm or operation (e.g., queuing discipline) that is implemented in a
router to realize a set of one or more per-hop behaviors.
Admission Control The decision process of whether to accept a request for resources (link bandwidth
plus buffer space)
Classification The process of sorting packets based on the content of packet headers according to
defined rules.
Behavior Aggregate The process of sorting packets based only on the contents of the DS field.
(BA) Classification
Multi-Field (MF) The process of classifying packets based on the content of multiple fields such as
Classification source address, destination address, TOS byte, protocol ID, source port number, and
destination port number.
Marking The process of setting the DS field in a packet
Policing The process of handling out of profile traffic, e.g., discarding excess packets
Shaping The process of delaying packets within traffic stream to cause it to conform to some
defined traffic profile.
Scheduling The process of deciding which packet to send first in a system of multiple queues
Queue Management Controlling the length of packet queues by dropping packets when necessary or ap-
propriate
Traffic Trunk An aggregation of flows with the same service class that can be put into a MPLS
Label Switched Path

2. Integrated Services and RSVP
The Integrated Services model [4] proposes two service classes in addition to Best Effort Service. They are:
1) Guaranteed Service [6] for applications requiring fixed delay bound; and 2) Controlled Load Service [7]
for applications requiring reliable and enhanced best effort service. The philosophy of this model is that
"there is an inescapable requirement for routers to be able to reserve resources in order to provide special
QoS for specific user packet streams, or flows. This in turn requires flow-specific state in the routers" [4].

3

RSVP was invented as a signaling protocol for applications to reserve resources [8]. The signaling proc-
ess is illustrated in Fig. 1. The sender sends a PATH Message to the receiver specifying the characteristics
of the traffic. Every intermediate router along the path forwards the PATH Message to the next hop deter-
mined by the routing protocol. Upon receiving a PATH Message, the receiver responds with a RESV Mes-
sage to request resources for the flow. Every intermediate router along the path can reject or accept the re-
quest of the RESV Message. If the request is rejected, the router will send an error message to the receiver,
and the signaling process will terminate. If the request is accepted, link bandwidth and buffer space are allo-
cated for the flow and the related flow state information will be installed in the router.

(1) PATH (2) PATH (3) PATH

RSVP Cloud

(6) RESV (5) RESV (4) RESV
sender Router Router Receiver

Figure 1. RSVP signaling

Recently, RSVP has been modified and extended in several ways to reserve resources for aggregation of
flows, to set up Explicit Routes (ERs) with QoS requirement, and to do some other signaling tasks [11, 31,
38]. This is a hotly debated issue in the IETF and is beyond the scope of this paper.
Integrated Services is implemented by four components: the signaling protocol (e.g. RSVP), the admis-
sion control routine, the classifier and the packet scheduler. Applications requiring Guaranteed Service or
Controlled-Load Service must set up the paths and reserve resources before transmitting their data. The ad-
mission control routines will decide whether a request for resources can be granted. When a router receives
a packet, the classifier will perform a Multi-Field (MF) classification and put the packet in a specific queue
based on the classification result. The packet scheduler will then schedule the packet accordingly to meet its
QoS requirements.
The Integrated Services/RSVP architecture is influenced by the work of Ferrari et al. [9, 10]. It represents
a fundamental change to the current Internet architecture, which is founded on the concept that all flow-
related state information should be in the end systems [12].
The problems with the Integrated Services architecture are: 1) the amount of state information increases
proportionally with the number of flows. This places a huge storage and processing overhead on the routers.
Therefore, this architecture does not scale well in the Internet core; 2) the requirement on routers is high. All
routers must implement RSVP, admission control, MF classification and packet scheduling; 3) ubiquitous
deployment is required for Guaranteed Service. Incremental deployment of Controlled-Load Service is pos-

4

sible by deploying Controlled-Load Service and RSVP functionality at the bottleneck nodes of a domain and
tunneling the RSVP messages over other part of the domain.

3. Differentiated Services
Because of the difficulty in implementing and deploying Integrated Services and RSVP, Differentiated
Services (DS) is introduced.

3.1 Introduction to Differentiated Services
IPv4 header contains a TOS byte. Its meaning is previously defined in [13]. Applications can set three bits in
the TOS byte to indicate the need for low delay or high throughput or low loss rate service. However,
choices are limited. Differentiated Services defines the layout of the TOS byte (termed DS field) and a base
set of packet forwarding treatments (termed Per-Hop Behaviors, or PHBs) [28]. By marking the DS fields of
packets differently, and handling packets based on their DS fields, several differentiated service classes can
be created. Therefore, Differentiated Services is essentially a relative-priority scheme.
In order for a customer to receive Differentiated Services from its Internet Service Provider (ISP), it must
have a Service Level Agreement (SLA) with its ISP. A SLA basically specifies the service classes supported
and the amount of traffic allowed in each class. A SLA can be static or dynamic. Static SLAs are negotiated
on a regular, e.g. monthly and yearly, basis. Customers with Dynamic SLAs must use a signaling protocol,
e.g. RSVP, to request for services on demand.
Customers can mark DS fields of individual packets to indicate the desired service or have them marked
by the leaf router based on MF classification.
At the ingress of the ISP networks, packets are classified, policed and possibly shaped. The classifica-
tion, policing and shaping rules used at the ingress routers are derived from the SLAs. The amount of buff-
ering space needed for these operations is also derived from the SLAs. When a packet enters one domain
from another domain, its DS field may be re-marked, as determined by the SLA between the two domains.
Using the classification, policing, shaping and scheduling mechanisms, many services can be provided,
for example, 1) Premium Service for applications requiring low delay and low jitter service; 2) Assured
Service for applications requiring better reliability than Best Effort Service; and 3) Olympic Service, which
provides three tiers of services: Gold, Silver and Bronze, with decreasing quality [25, 29]. Note that the Dif-
ferentiated Services only defines DS fields and PHBs. It is the ISPs’ responsibility to decide what services to
provide.
Differentiated Services is significantly different from Integrated Services. First, there are only a limited
number of service classes indicated by the DS field. Since service is allocated in the granularity of a class,
the amount of state information is proportional to the number of classes rather than the number of flows.
Differentiated Services is therefore more scalable. Second, sophisticated classification, marking, policing

5

and shaping operations are only needed at boundary of the networks. ISP core routers need only to imple-
ment Behavior Aggregate (BA) classification. Therefore, it is easier to implement and deploy Differentiated
Services.
There is another reason why the second feature is desirable for ISPs. ISP networks usually consists of
boundary routers connected to customers and core routers/switches interconnecting the boundary routers.
Core routers must forward packets very fast and therefore must be simple. Boundary routers need not for-
ward packets very fast because customer links are relatively slow. Therefore, they can spend more time on
sophisticated classification, policing and shaping [3]. Boundary routers at the Network Access Points
(NAPs) are exceptions. They must forward packets very fast and do sophisticated classification, policing and
shaping. Therefore, they must be well equipped.
In the Differentiated Services model, incremental deployment is possible for Assured Service. DS-
incapable routers simply ignore the DS fields of the packets and give the Assured Service packets Best Ef-
fort Service. Since Assured Service packets are less likely to be dropped by DS-capable routers, the overall
performance of Assured Service traffic will be better than the Best Effort traffic.

3.2 An End-to-End Service Architecture
In this section, a service architecture for Differentiated Services is presented. This architecture provides As-
sured Service, Premium Service in addition to Best Effort Service. It is mainly based on the architecture
proposed in [25]. Other possible service architectures also exist [30].

3.2.1 Assured Service
Assured Service is intended for customers that need reliable services from their service providers, even in
time of network congestion. Customers will have SLAs with their ISPs. The SLAs will specify the amount
of bandwidth allocated for the customers. Customers are responsible for deciding how their applications
share that amount of bandwidth. One possible service allocation process is described in the Section 3.2.3.
SLAs for Assured Service are usually static, meaning that the customers can start data transmission when-
ever they want without signaling their ISPs.
Assured Service can be implemented as follows. First, classification and policing are done at the ingress
routers of the ISP networks. If the Assured Service traffic does not exceed the bit-rate specified by the SLA,
they are considered as in profile. Otherwise, the excess packets are considered as out of profile. Second, all
packets, in and out, are put into an Assured Queue (AQ) to avoid out of order delivery. Third, the queue is
managed by a queue management scheme called RED with In and Out, or RIO [27].
RED (Random Early Detection) [32] is a queue management scheme that drops packets randomly. This
will trigger the TCP flow control mechanisms at different end hosts to reduce send rates at different time. By
doing so, RED can prevent the queue at the routers from overflowing, and therefore avoid the tail-drop be-

6

havior (dropping all subsequent packets when a queue overflows). Tail-drop triggers multiple TCP flows to
decrease and later increase their rates simultaneously. It causes network utilization to oscillate and can hurt
performance significantly. RED has been proved to be useful and has been widely deployed.
RIO is a more advanced RED scheme. It basically maintains two RED algorithms, one for in packets and
one for out packets. There are two thresholds for each queue. When the queue size is below the first thresh-
old, no packets are dropped. When the queue size is between the two thresholds, only out packets are ran-
domly dropped. When the queue size exceeds the second threshold, indicating possible network congestion,
both in and out packets are randomly dropped, but out packets are dropped more aggressively. In addition to
breaking the TCP flow-control synchronization, RIO prevents, to some extent, greedy flows from hurting the
performance of other flows by dropping the out packets more aggressively.
Because in packets have low loss rate even in the cases of congestion, the customers will perceive a pre-
dictable service from the network if they keep traffic conformant. When there is no congestion, out packets
will also be delivered. The networks are thus better utilized.
Best Effort traffic can be treated differently from Assured Service out traffic or they can be treated iden-
tically. In this paper, we assume that they are treated identically. Therefore, conceptually, we can consider
that there is an A-bit in the DS field. The A-bits of Assured Service in packets are set to 1 while the A-bits of
Assured Service out packets and Best Effort packets are reset to 0. For the rest of this paper, we do not dis-
tinguish them.

3.2.2 Premium Service
Premium Service provides low-delay and low-jitter service for customers that generate fixed peak bit-rate
traffic. Each customer will have a SLA with its ISP. The SLA specifies a desired peak bit-rate for a specific
flow or an aggregation of flows. The customer is responsible for not exceeding the peak rate. Otherwise,
excess traffic will be dropped. The ISP guarantees that the contracted bandwidth will be available when traf-
fic is sent. Premium Service is suitable for Internet Telephony, Video Conferencing, or for creating virtual
lease lines for Virtual Private Networks (VPNs) [39].
Because Premium Service is more expensive than Assured Service, it is desirable for ISPs to support both
static SLAs and dynamic SLAs. Dynamic SLAs allow customers to request for Premium Service on demand
without subscribing to it. Admission control is needed for dynamic SLAs.
Premium Service can be implemented as follows. At the customer side, some entity will decide which
application flow can use Premium Service. The leaf routers directly connected to the senders will do MF
classifications and shape the traffic. Conceptually, we can consider that there is a P-bit in the DS field. If the
P-bit of a packet is set, this packet belongs to the premium class. Otherwise, the packet belongs to the As-
sured Service class or Best Effort class. After the shaping, the P-bits of all packets are set for the flow that is
allowed to use Premium Service. The exit routers of the customer domain may need to reshape the traffic to
make sure that the traffic does not exceed the peak rate specified by the SLA. At the provider side, the in-

7

gress routers will police the traffic. Excess traffic is dropped. All packets with the P-bit set enter a Pre-
mium Queue (PQ). Packets in the PQ will be sent before packets in the AQ.
First, by admission control, the amount of premium traffic can be limited to a small percentage, say 10%,
of the bandwidth of input links. Second, excess packets are dropped at the ingress routers of the networks.
Non-conformant flows cannot impact the performance of conformant flows. Third, premium packets are
forwarded before packets of other classes, they can potentially use 100% of the bandwidth of the output
links. Since most links are full-duplex, the bandwidth of the input links equals to the bandwidth of the output
links. Therefore, if premium traffic is distributed evenly among the links, these three factors should guaran-
tee that the service rate of the PQ is much higher than the arrival rate. Therefore, arriving premium packets
should find the PQ empty or very short most of the time. The delay or jitter experienced by premium packets
should be very low. However, Premium Service provides no quantified guarantee on the delay or jitter
bound.

BR3

CR2 CR3
BR2

OC3
OC12
BR1
CR1 CR4 CR5

Figure 2. Uneven distribution of premium traffic in an ISP. The shaded area is the core of the ISP

However, uneven distribution of premium traffic may cause a problem for Premium Service. In ISP net-
works, aggregation of traffic from the boundary routers to a core router, e.g. CR1 in Fig. 2, is inevitable. But
this is not a problem because the output link is much faster than the input links. However, aggregation of
premium traffic in the core at CR4 may invalidate the assumption that the arrival rate of premium traffic is
far below the service rate. Differentiated Services alone cannot solve this problem. Traffic Engineer-
ing/Constraint Based Routing must be used to avoid such congestion caused by uneven traffic distribution.
By limiting the total amount of bandwidth requested by Premium traffic, the network administrators can
guarantee that premium traffic will not starve the Assured and Best Effort traffic. Another scheme is to use
Weight Fair Queuing (WFQ) [22] between the PQ and the AQ.

3.2.3 Service Allocation in Customer Domains
Given a SLA, a customer domain should decide how its hosts share the services specified by the SLA. This
process is called Service Allocation.

8

There are basically two choices. 1) Each host makes its own decision as to which service to use. 2) A re-
source controller called Bandwidth Broker (BB) [25] makes decision for all hosts. A BB can be a host, a
router or a software process on an exit router. It is configured with the organizational policies and it man-
ages the resources of a domain. A domain may also have backup BBs. Since all hosts must cooperate to
share a limited amount of resources specified by the SLA, it is technically better to have a BB to allocate
resources.
At the initial deployment stage, hosts need no DS mechanism. They simply send their packets unmarked.
The exit routers marked them before sending them out to the ISPs. The packets are treated as Best Effort
traffic inside the customer domain. In later deployment stages, hosts may have some signaling or marking
mechanisms. Before a host starts sending packets, it may decide the service class for the packets by itself or
it may consult a BB for a service class. The host may mark the packets by itself or may send the packets un-
marked. If the host sends the packets unmarked, the BB must use some protocols, e.g., RSVP or LDAP
(Light-weight Directory Access Protocol) [33], to set the classification, marking and shaping rules at the leaf
router directly connected to the sender so that the leaf router knows how to mark the sender’s packets.
If the SLA between a customer and its ISP is dynamic, the BB in the customer domain must also use
some signaling protocol to request resources on demand from its ISP. From now on, we assume that RSVP
is used as the signaling protocol.

3.2.4 Resource Allocations in ISP Domains
Given the SLAs, ISPs must decide how to configure their boundary routers so that they know how to handle
the incoming traffic. This process is called Resource Allocation.
For static SLAs, boundary routers can be manually configured with the classification, policing and
shaping rules. Resources are therefore statically allocated for each customer. Unused resources can be
shared by other customers.
For a dynamic SLA, resource allocation is closely related to the signaling process. The BB in the cus-
tomer domain uses RSVP to request for resources from its ISP. At the ISP side, the admission control deci-
sions can be made in a distributed manner by the boundary routers or by a Bandwidth Broker. If boundary
routers are directly involved in the signaling process, they are configured with the corresponding classifica-
tion, policing and shaping rules when they grant a request. If a BB is involved rather than the boundary
routers, then the BB must configure the boundary routers when it grants a request. Such procedures will be
detailed in the Section 3.2.5.
In both cases, the ISP core routers must be shielded from the requests to avoid the scalability problem.

3.2.5 Examples of End-to-End Service Delivery
Example 1: Delivery of Assured Service with a static SLA

9

In Fig. 3, host S in Corporate Network 1 (CN1) wants to use Assured Service to send data to host D in Cor-
porate Network 2 (CN2). CN1 has a static SLA with ISP1. The service delivery process is described below.
The numbers inside the circles are the step numbers in the service delivery process.

CN1-BB
1 2

5 6 7 8
4 9
3

Host S LR1 ER1 BR1 Core Router BR2 ER2 Host D

CN1 CN2
ISP1

Figure 3. The delivery process of Assured Service with a static SLA

1. Host S sends a RSVP message to the local Bandwidth Broker CN1-BB, requesting for Assured Service
for its traffic.
2. If CN1-BB grants the request, it will configure leaf router LR1 so that LR1 can set the A-bits of the
packets of this flow. CN1-BB will then reply to host S. Otherwise, an error message is sent to Host S.
3. Host S sends packets to leaf router LR1.
4. If LR1 is configured to mark the traffic, it will set the A-bits of the packets.
5. Every router from LR1 (exclusive) to ER1 (inclusive) does a BA classification. Packets with the A-bit
set are considered as in while packets with the A-bit reset are considered as out. All packets enter the
AQ. RIO is applied on the AQ.
6. BR1 polices the traffic. All out traffic remains out. If the in traffic exceeds its bit-rate, the excess pack-
ets’ A-bits will be reset. All packets enter the AQ. RIO is applied on the queue.
7. All routers between boundary router BR1 and BR2 (inclusive) perform BA classifications and apply
RIO on their AQs.
8. ER2 performs the same operations as BR1.
9. The packets are eventually delivered to host D.
Note that:

If there are multiple ISPs between CN1 and CN2, then Steps 6-7 will be repeated multiple times,
once per ISP.
¡

If CN1 does not have any SLA with ISP1, then it can only send traffic as Best Effort. No matter how
the routers in CN1 mark the DS fields of their packets, the A-bits will be reset at BR1.
Example 2: Delivery of Premium Service with a dynamic SLA

10

In Fig. 4, host S in Corporate Network 1 (CN1) wants to use Premium Service to send data to host D in Cor-
porate Network 2 (CN2). CN1 has a dynamic SLA with ISP1.

2
3 4
6 6
CN1-BB ISP1-BB CN2-BB
1 7 7
5
12 13 14 15
8,9 16
11
10
Host S LR1 ER1 BR1 Core Router BR2 ER2 Host D

CN1 CN2
ISP1

Figure 4. The delivery process of Premium Service with a dynamic SLA

Phase 1: signaling
1. Host S sends a RSVP PATH Message to the local Bandwidth Broker CN1-BB
2. CN1-BB makes an admission control decision.
¢

If the request is denied, an error message is sent back to host S. The signaling process ends.
3. The request is accepted by CN1-BB. CN1-BB sends the PATH Message to ISP1-BB.
4. ISP1-BB makes an admission control decision.
£

If the request is denied, an error message is sent back to CN1-BB. Sender S will be notified.
¤

If the request is accepted, ISP1-BB sends the PATH Message to CN2-BB.
¥

If the request is denied, an error message is sent back to ISP1-BB. Sender S will be notified.
¦

If the request is accepted, CN2-BB will use LDAP or RSVP to set the classification and policing
rules on router ER2. CN2-BB will then send an RSVP RESV Message to ISP1-BB.
6. When ISP1-BB receives the RESV Message, it will configure the classification and policing rules on
router BR1, and the policing and reshaping rules on router BR2. It will then send the RESV Message to
CN1-BB.
7. When CN1-BB receives the RESV Message, it will set the classification and shaping rules on router
LR1, so that if the traffic of the admitted flow is non-conformant, LR1 will shape it. CN1-BB will also
set the policing and reshaping rules on router ER1. CN1-BB will then send the RESV Message to host S.
8. When host S receives the RESV Message, it can start transmitting data.
Note that:
§

This signaling process is significantly different from the signaling process in Integrated Serv-
ices/RSVP. First, it is the sender who requests for resources, not the receiver. Second, a request can
be rejected when the BB receives the PATH Message from the sender. In Integrated Services/RSVP,

11

a request is rejected only when a router receives the RESV Message from the receiver. Third, a BB
can aggregate multiple requests and make a single request to the next BB. Fourth, each domain be-
haves like a single node, represented by the BB. ISP core routers are not involved in this process.
¨

The state information installed by the BB on the boundary routers is soft state. It must be regularly
refreshed, or it will time out.
©

If there are multiple ISPs between CN1 and CN 2, repeat Step 4 and Step 6 once for each ISP.

If the SLA between CN1 and ISP1 is static, simply skip Steps 3-6 in the signaling process.
Phase 2: Data Transmission:
9. Host S sends packets to leaf router LR1.
10. Leaf router LR1 performs a MF classification. If the traffic in non-conformant, LR1 will shape it. LR1
will also set the P-bits of the packets. All packets enter the PQ.
11. Each intermediate router between leaf router LR1 and ER1 performs a BA classification, puts the pack-
ets into the PQ, and sends them out.
12. ER1 performs a BA classification and reshapes the traffic to make sure that the negotiated peak rate is
not exceeded. Reshaping is done for the aggregation of all flows heading toward BR1, not for each indi-
vidual flow.
13. BR1 classifies and polices the premium traffic. Excess premium packets are dropped.
14. Intermediate routers between leaf router BR1 and BR2 (inclusive) perform BA classifications. BR2 also
reshapes the premium traffic.
15. ER2 classifies and polices the premium traffic. Excess premium packets are dropped.
16. The premium packets are delivered to host D.

3.3 Requirements on Routers
The requirements on routers to support Premium Service and Assured Service are summarized below.
1. The leaf routers in customer domains need to implement MF classifications, marking, and shaping.
2. The ISP ingress routers need to implement policing and re-marking.
3. The ISP egress routers need optionally to implement re-shaping
4. All routers need to implement BA classification and two queues with strict priority.
5. If dynamic SLAs are supported, each customer domain will need a BB to request for service on be-
half of the domain and to allocate services inside the domain. Signaling and admission control
mechanisms are needed in both customer domains and ISP domains.
If Assured Service is to be replaced by Olympic Service, then the Assured Queue must be replaced by
three queues: a Gold Queue, a Silver Queue, and a Bronze Queue. WFQ can be used to schedule these
queues. The rate parameters of these queues can be manually configured based on experiences.

12

4. MPLS
The motivation for MPLS is to use a fixed length label to decide packet handling. MPLS is also a useful tool
for Traffic Engineering [36, 37].

4.1 Introduction to MPLS
MPLS is a forwarding scheme. It evolved from Cisco’s Tag Switching. In the OSI seven-layer model, it is
between Layer 2 (L2, link layer) and Layer 3 (L3, network layer).
Each MPLS packet has a header. The header contains a 20-bit label, a 3-bit Class of Service (COS) field,
an 1-bit label stack indicator and an 8-bit TTL field. The MPLS header is encapsulated between the link
layer header and the network layer header. A MPLS capable router, termed Label Switched Router (LSR),
examines only the label in forwarding the packet. The network protocol can be IP or others. This is why it is
called Multi-Protocol Label Switching.
MPLS needs a protocol to distribute labels to set up Label Switched Paths (LSPs). Whether a generic La-
bel Distribution Protocol (LDP) [35] should be created or RSVP should be extended [38] for this purpose is
another hotly debated issue. MPLS labels can also be piggy-backed by routing protocols. A LSP is similar to
an ATM Virtual Circuit (VC) and is uni-directional from the sender to the receiver. MPLS LSRs use the
protocol to negotiate the semantics of each label, i.e., how to handle a packet with a particular label from the
peer. LSP setup can be control driven, i.e., triggered by control traffic such as routing updates. Or, it can be
data driven, i.e., triggered by the request of a flow or a Traffic Trunk. In MPLS, a traffic trunk is an aggre-
gation of flows with the same service class that can be put into a LSP. The LSP between two routers can be
the same as the L3 hop-by-hop route, or the sender LSR can specify an Explicit Route (ER) for the LSP. The
ability to set up ERs is one of the most useful features of MPLS. A forwarding table indexed by labels is
constructed as the result of label distribution. Each forwarding table entry specifies how to process packets
carrying the indexing label.
Packets are classified and routed at the ingress LSRs of a MPLS-capable domain. MPLS headers are then
inserted. When a LSR receives a labeled packet, it will use the label as the index to look up the forwarding
table. This is faster than the process of parsing the routing table in search of the longest match done in IP
routing [40, 41]. The packet is processed as specified by the forwarding table entry. The incoming label is
replaced by the outgoing label and the packet is switched to the next LSR. This label-switching process is
similar to ATM’s VCI/VPI processing. Inside a MPLS domain, packet forwarding, classification and QoS
service are determined by the labels and the COS fields. This makes core LSRs simple. Before a packet
leaves a MPLS domain, its MPLS label is removed.
MPLS LSPs can be used as tunnels. After LSPs are set up, a packet’s path can be completely determined
by the label assigned by the ingress LSR. There is no need to enumerate every intermediate router of the

13

tunnel. Compared to other tunneling mechanisms, MPLS is unique in that it can control the complete path of
a packet without explicitly specifying the intermediate routers.
In short, MPLS is strategically significant because:
1. it provides faster packet classification and forwarding,
2. it provides an efficient tunneling mechanism.
These features, particularly the second one, make MPLS useful for Traffic Engineering [36, 37].

4.2 A Service Architecture based on MPLS
MPLS can be used together with Differentiated Services to provide QoS. In such an architecture, LSPs are
first configured between each ingress-egress pair. For LSP(LSR1 LSR2) and LSP(LSR2 LSR1), their
intermediate LSRs need not be reciprocal. It is likely that for each ingress-egress pair, a separate LSP is cre-
ated for each traffic class. In this case, a total number of C*N*(N-1)/2 LSPs are needed, where C is the num-
ber of traffic classes and N is the number of boundary routers. In order to reduce the number of LSPs, the
LSPs from all ingress routers to a single egress router can be merged into a Sink Tree. The total number of
Sink Trees needed is C*N. It is also possible to use a single Sink Tree to transmit packets of different traffic
classes, and use the COS bits to differentiate packet classes. In this case, the number of Sink Trees is re-
duced to N. In this architecture, as the number of transiting flows increases, the number of flows in each
LSP or Sink Tree also increases. But the number of LSPs or Sink Trees need not increase. This architecture
is therefore scalable.
The operations of the routers are basically the same in this architecture as in the DS field-based archi-
tecture described in Section 3.2. There are three differences in the processing of a packet. 1) At the ingress
of the ISP network, in addition to all the processing described in the DS field-based architecture, a MPLS
header is inserted into the packet. 2) Core routers process the packet based on its label and COS field rather
than its DS field. 3) At the egress, unless inter-domain LSPs are configured, the MPLS header is removed.
Note that with such schemes, MPLS effect is confined within the ISPs that use MPLS. Whether a par-
ticular ISP’s architecture is DS field-based or MPLS-based is transparent to other ISPs. Therefore, the DS
field based architecture and the MPLS based architecture can easily inter-operate.
Each customer domain still needs a BB to allocate services, and to request for resources on behalf of the
customer domain when the SLA is dynamic. But since LSPs are configured within the ISPs, resource re-
quests can be easily hidden from the core routers by tunneling them from the ingress routers to the egress
routers. Therefore, BBs may not be needed in the MPLS-based ISP networks. Admission control is made in
a distributed fashion by the ingress routers and egress routers.
Without BBs in the ISP networks, the signaling process for dynamic SLAs is slightly different from the
one described in Section 3.2. It is depicted in Fig. 5 and is described below. The data transmission process
remains the same except for the three differences noted above.

14

2

CN1-BB 3 CN2-BB
BR3
9 9
1 6
4 Sink 5
10 Tree

8 Core 7
Host S LR1 ER1 BR1 Router
BR2 ER2 Host D

CN1 CN2
ISP1

Figure 5. The signaling process of dynamic Premium Service in a MPLS-based architecture

1. Host S sends a RSVP PATH Message to its local domain Bandwidth Broker CN1-BB

If the request is denied, an error message is sent back to host S. The signaling process ends.
3. The request is accepted by CN1-BB. CN1-BB sends the PATH Message to BR1.
4. BR1 decides if there is enough resources to send the traffic to egress router BR2

If no, the request is denied. An error message is sent back to CN1-BB. Sender S will be notified.

If yes, ISP1-BB sends the PATH Message through a LSP to BR2.
5. BR2 sends the PATH Message to CN2-BB
6. CN2-BB decides if its domain can support the traffic,

If no, the request is denied. An error message is sent back to BR2. Sender S will be notified.

If yes, the request is accepted. CN2-BB will use LDAP or RSVP to set the classification and polic-
ing rules on router ER2. CN2-BB will then send an RSVP RESV Message to BR2.
7. BR2 configures the reshaping rules for the traffic. It then sends the RESV Message through a LSP to
BR1.
8. BR1 configures the classification and policing rules for the traffic. It then sends the RESV Message to
CN1-BB.
9. When CN1-BB receives the RESV Message, it will set the classification and shaping rules on router
LR1, so that if the traffic of the admitted flow is non-conformant, LR1 can shape it. CN1-BB will also
set the reshaping rules on router ER1. CN1-BB will then pass the RESV Message to host S.
10. Sender S starts transmitting data.
If there are multiple ISPs between CN1 and CN2, repeat Steps 4-5 and Steps 7-8 once per ISP.

5. Traffic Engineering and Constraint Based Routing
QoS schemes such as Integrated Services/RSVP and Differentiated Services essentially provide differenti-
ated degradation of performance for different traffic when traffic load is heavy. When the load is light, Inte-

15

grated Services/RSVP, Differentiated Services and Best Effort Service make little difference. Then, why not
avoid congestion at the first place? This is the motivation for Traffic Engineering.

5.1 Traffic Engineering
Network congestion can be caused by lack of network resources or by uneven distribution of traffic. In the
first case, all routers and links are overloaded and the only solution is to provide more resources by upgrad-
ing the infrastructure. In the second case, some parts of the network are overloaded while other parts are
lightly loaded. Uneven traffic distribution can be caused by the current Dynamic Routing protocols such as
RIP, OSPF and IS-IS, because they always select the shortest paths to forward packets. As a result, routers
and links along the shortest path between two nodes may become congested while routers and links along a
longer path are idle. The Equal-Cost Multi-Path (ECMP) option of OSPF [42], and recently of IS-IS [43], is
useful in distributing load to several shortest paths. But, if there is only one shortest path, ECMP does not
help. For simple networks, it may be possible for network administrators to manually configure the cost of
the links, so that traffic can be evenly distributed. For complex ISP networks, this is almost impossible.
Traffic Engineering is the process of arranging how traffic flows through the network so that congestion
caused by uneven network utilization can be avoided. Constraint Based Routing is an important tool for
making the Traffic Engineering process automatic.
Avoiding congestion and providing graceful degradation of performance in the case of congestion are
complementary. Traffic Engineering therefore complements Differentiated Services.

5.2 Constraint Based Routing
In a sentence, Constraint Based Routing is used to compute routes that are subject to multiple constraints.
Constraint Based Routing evolves from QoS Routing. Given the QoS request of a flow or an aggregation
of flows, QoS Routing returns the route that is most likely to be able to meet the QoS requirements. Con-
straint Based Routing extends QoS Routing by considering other constraints of the network such as policy.
The goals of Constraint Based Routing are:
1. to select routes that can meet certain QoS requirement;
2. to increase the utilization of the network.
While determining a route, Constraint Based Routing considers not only topology of the network, but
also the requirement of the flow, the resource availability of the links, and possibly other policies specified
by the network administrators. Therefore, Constraint Based Routing may find a longer and lightly-loaded
path better than the heavily-loaded shortest path. Network traffic is thus distributed more evenly.
In order to do Constraint Based Routing, routers need to distribute new link state information and to
compute routes based on such information.

16

5.2.1 Distribution of Link State Information
A router needs topology information and resource availability information in order to compute QoS routes.
Here, resource availability information means link available bandwidth [48]. Buffer space is assumed to be
sufficient and is not explicitly considered [48].
One approach to distribute bandwidth information is to extend the link state advertisements of protocols
such as OSPF and IS-IS [48, 49]. Because link residual bandwidth is frequently changing, a tradeoff must be
made between the need for accurate information and the need to avoid frequent flooding of link state adver-
tisements.
To reduce the frequency of link state advertisements, one possible way is to distribute them only when
there are topology changes, or significant bandwidth changes, e.g., more than 50% or more than 10 Mbps
[51]. A hold-down timer should always be used to limit the frequency of such advertisements. A recom-
mended timer value is 30 seconds [46]. An approach to limit the flooding scope of such advertisements is
described in [52].

5.2.2 Route Computation
The routing table computation algorithms in Constraint Based Routing and the complexity of such algo-
rithms depend on the metrics chosen for the routes.
Common route metrics in Constraint Based Routing are monetary cost, hop-count, bandwidth, reliability,
delay, and jitter. Routing algorithms select routes that optimize one or more of these metrics.
Metrics can be divided into three classes. Let d(i,j) be a metric for link (i,j). For any path P = (i, j, k, …,
l, m), metric d is:

additive if d(P) = d(i,j) + d(j,k) + … + d(l,m)

multiplicative if d(P) = d(i,j) * d(j,k) * … * d(l,m)
concave if d(P) = min{d(i,j), d(j,k), …, d(l,m)}
According to this definition, metrics delay, jitter, cost and hop-count are additive, reliability (1-loss rate)
is multiplicative, and bandwidth is concave.
A well-known theorem in Constraint Based Routing is that, computing optimal routes subject to con-
straints of two or more additive and/or multiplicative metrics is NP-complete [50]. That is, algorithms that
use two or more of delay, jitter, hop-count, loss-probability as metrics and optimize them simultaneously are
NP-complete. The computationally feasible combinations of metrics are bandwidth and one of those metrics.
However, the proof of NP-Completeness in [50] is based on the assumptions that 1) all the metrics are
independent; and 2) the delay and jitter of a link are known a priori. Although such assumptions may be
true in circuit-switched networks, metrics bandwidth, delay and jitter are not independent in packet net-
works. As a result, polynomial algorithms for computing routes with hop-count, delay, and jitter constraints
exist [46]. The complexity of such algorithms is O(N*E*e), where N is the hop-count, E is the number of
links of the network, and e ≤ E is the number of distinct bandwidth values among all links. Nevertheless, the

17

theorem can tell us qualitatively the complexity of a routing algorithm: a complex algorithm in circuit-
switched networks is still complex in packet networks, although it may not be NP-Complete.
Fortunately, algorithms for finding routes with bandwidth and hop-count constraints are much simpler
[48]. Bellman-Ford’s (BF) Algorithm or Dijkstra’s Algorithm can be used. For example, to find the shortest
path between two nodes with bandwidth greater than 1 Mbps, all the links with residual bandwidth less than
1 Mbps can be pruned first. BF Algorithm or Dijkstra’s Algorithm can then be used to compute the shortest
path in the pruned network. The complexity of such algorithms is O(N*E).
Bandwidth and hop-count are more useful constraints than delay and jitter, because:
1. Although applications may care about delay and jitter bounds, few applications cannot tolerate occa-
sional violation of such constraints. Therefore, there is no obvious need for routing flows with delay
and jitter constraints. Besides, since delay and jitter parameters of a flow can be determined by the
allocated bandwidth and the hop-count of the route [20, 21], delay and jitter constraints can be
mapped to bandwidth and hop-count constraints, if needed.
2. Many real-time applications will require a certain amount of bandwidth. The bandwidth metric is
therefore useful. The hop-count metric of a route is important because the more hops a flow travers-
es, the more resources it consumes. For example, a 1-Mbps flow that traverses two hops consumes
twice as many resources as one that traverses a single hop.
In Constraint Based Routing, routes can be computed on demand or can be pre-computed for each traffic
class. On-demand computations are triggered by the receipt of the QoS request of a flow. In either case, a
router will have to compute its routing table more frequently with Constraint Based Routing than with Dy-
namic Routing. This is because, even without topology changes, routing table computation can still be trig-
gered by significant bandwidth changes. Besides, Constraint Based Routing algorithms are at least as com-
plex as Dynamic Routing algorithms. Therefore, the computation load of routers with Constraint Based
Routing can be very high.
Common approaches to reduce the computation overhead of Constraint Based Routing include:
1. using a large-valued timer to reduce the computation frequency.
2. choosing bandwidth and hop-count as constraints
3. using administrative policy to prune unsuitable links before computing the routing table.
For example, if a flow has delay requirement, high propagation delay links such as satellite links are
pruned before the routing table computation.

5.3 Constraint Based Routing: Pros and Cons
The Pros of Constraint Based Routing are: 1) meeting the need of QoS requirements of flows better; and 2)
improved network utilization.

18

The Cons of Constraint Based Routing are: 1) increased communication and computation overhead; 2)
increased routing table size; 3) longer paths may consume more resources; and 4) potential routing instabil-
ity.
Of the cons, 1) has been addressed in Section 5.2. The rest is addressed in this section.
In Constraint Based Routing, an essential issue is routing granularity. Routing can be destination based,
source-destination based, class based, traffic trunk based or flow based. Routing with finer granularity is
more flexible, and thus more efficient in terms of resource utilization and more stable. But the computation
overhead and storage overhead are also higher.

5.3.1 Routing Table Structure and Size
Routing table structure and size depend directly on routing granularity and route metrics. Logically, we can
view the routing table as a two-dimension array. The number of rows is determined by routing granularity
and the number of columns is determined by route metrics. For example, in destination based routing with
bandwidth and hop-count as route metrics, the routing table can be organized as a K × H array, where K is
the number of destinations, and H is the maximum number of hops allowed for any route. The (k, h)-th entry
of the array contains one or more h-hop routes for destination k. Each route also has an available bandwidth
associated with it [48].
Obviously, the size of a Constraint Based Routing table can be far larger than the size of a normal routing
table for the same network. This introduces significant storage overhead. It may also slow down the routing
table lookup.
Approaches to reduce the routing table size in Constraint Based Routing include: 1) using coarse routing
granularity; 2) using hop quantization, i.e., dividing all hop-count values into a few classes to reduce the
number of columns in the routing table [51]; and 3) keeping the routing table only for Best Effort Traffic,
and compute the routes for flows with QoS requests on demand [45]. The third scheme basically trades
computation time for smaller storage requirement.

5.3.2 Tradeoff between Resource Conservation and Load Balancing
A Constraint Based Routing scheme can choose one of the followings as the route for a destination.
1. The widest-shortest path, i.e., a path with minimum hop-count and, if there are multiple such paths,
the one with largest available bandwidth;
2. The shortest-widest path, i.e., a path with largest available bandwidth and, if there are multiple such
paths, the one with the minimum hop-count;
3. The shortest-distance path. The distance of a k-hop path P is defined as
k
1
dist ( P) = ∑ , where ri is the bandwidth of link i.
i =1 ri

19

Using paths other than the shortest paths consume more resources. This is not efficient when the load of
the network is heavy. A tradeoff must be made between resource conservation and load balancing. The first
approach above is basically the same as today’s Dynamic Routing. It emphasizes preserving network re-
sources by choosing the shortest paths. The second approach emphasizes load balancing by choosing the
widest paths. The third approach makes a tradeoff between the two extremes. It favors shortest paths when
network load is heavy and favors widest paths when network load is mediate. Simulations showed that the
third approach consistently outperforms the other two approaches for Best Effort traffic, regardless of net-
work topology and traffic pattern [46].

5.3.3 Stability
Because Constraint Based Routing algorithms re-compute routing tables more frequently than Dynamic
Routing algorithms do, they can introduce instability.
The stability of the networks with Constraint Based Routing depends heavily on the routing granularity.
If routing is done with coarse granularity, e.g., based solely on destination address, when the original route
between two nodes becomes congested, all the traffic to that destination is shifted from the original route to
an alternate route. This may cause congestion in the alternate route. Traffic may have to be shifted again
[52].
High computation overhead of Constraint Based Routing may also hurt stability of the network. When a
router is busy computing the routing table, it is slow in reacting to new topology changes.
To improve stability, the timer value for periodic routing table re-computation should be carefully chosen
[45]. Constraint Based Routing at the granularity of traffic trunk provides a good tradeoff between stability
and computation overhead [37]. Reducing the computation complexity of the routers also helps to improve
stability.
In summary, Constraint Based Routing must be deployed with caution. Otherwise, the cost of instability
and increased complexity may outweigh the gain.
Constraint Based Routing is similar to the Dynamic/Adaptive Routing in telephone networks and ATM
networks [53, 54, 55, 56]. Many lessons can be learned from those works. Since Constraint Based Routing is
a super-set of today’s Dynamic Routing, it is possible that in the future, Constraint Based Routing may re-
place Dynamic Routing, especially in the intra-domain case. An emerging intra-domain Constraint Based
Routing protocol is QOSPF [48].

5.4 The Position of Constraint Based Routing in the QoS Framework
In this section, we describe the relationships between Constraint Based Routing and other components in the
QoS framework.

20

5.4.1 Relationship between Constraint Based Routing and Differentiated Services
Constraint Based Routing is to select the optimal routes for flows so that their QoS requirements are most
likely to be met. It is not to replace Differentiated Services, but to help Differentiated Services to be better
delivered. Fig. 2 shows an example in point.

5.4.2 Relationship between Constraint Based Routing and RSVP
RSVP and Constraint Based Routing are independent but complementary. For a router with Dynamic Rout-
ing, when a RSVP PATH Message is received, it will be forwarded to the next hop determined by the Dy-
namic Routing protocol. The QoS requirement of the flow and the load of the networks is not considered in
selecting the next hop. However, with a router running Constraint Based Routing, such information are con-
sidered. The next hop of the RSVP messages determined by Constraint Based Routing therefore may be dif-
ferent. In either case, the actual reservation of resources for the flow is done by RSVP. In short, Constraint
Based Routing determines the path for RSVP messages but does not reserve resources. RSVP reserves re-
sources but depends on Constraint Based Routing or Dynamic Routing to determine the path.

5.4.3 Relationship between Constraint Based Routing and MPLS
Given that MPLS is a forwarding scheme and Constraint Based Routing is a routing scheme, MPLS and
Constraint Based Routing are, in theory, mutually independent. Constraint Based Routing determines the
route between two nodes based on resource information and topology information. It is useful with or with-
out MPLS. Given the routes, MPLS uses its label distribution protocol to set up the LSPs. It does not care
whether the routes are determined by Constraint Based Routing or by Dynamic Routing.
However, when MPLS and Constraint Based Routing are used together, they make each other more use-
ful. MPLS makes it possible to do Constraint Based Routing at the traffic trunk granularity without intro-
ducing MF classification to the core routers. MPLS’s per-LSP statistics provide Constraint Based Routing
with precise information about the amount of traffic between every ingress-egress pair. Given such informa-
tion, Constraint Based Routing can better compute the routes for setting up LSPs. In combination, MPLS
and Constraint Based Routing provide powerful tools for Traffic Engineering.
Note that when Constraint Based Routing is done at the granularity of traffic trunk, multiple LSPs may
be set up between an ingress-egress pair. The number of Sink Trees needed for a network of N egress routers
may become k*N, where k is a small constant.

6. Comparison of ATM Networks to Router Networks
QoS and some sort of Traffic Engineering have long been provided by ATM networks. So why introducing
Differentiated Services and MPLS into the router networks? To answer this question, we give a brief com-
parison between ATM networks and router networks.

21

In an ATM network, QoS can be provided by allocating a certain amount of bandwidth for a specific VC.
Traffic Engineering is usually done by computing the routes off-line and then downloading the configuration
statically into the ATM switches on an hourly or daily basis. Per-PVC (Permanent Virtual Circuit) traffic
statistics of the current configuration provide accurate traffic information for computing the routes for the
next configuration.
The advantages of ATM networks over router networks without Differentiated Services or MPLS are:
1. ATM networks are currently faster in data forwarding.
2. Per-PVC traffic statistics are available.
3. QoS and some sort of Traffic Engineering are provided.
The disadvantages of ATM networks are:
1. ATM cell header overhead is large.
2. Routers must be used at the boundary of the network. With both switches and routers present in the
network, two sets of configurations are required: one for routers and the other for switches.
With Differentiated Services and MPLS, router networks can also provide QoS and Traffic Engineering.
This can be done without a big header overhead and two sets of configurations. Router networks with Dif-
ferentiated Services and MPLS therefore provide some advantages over ATM networks [57]. But this is
more or less from the perspective of router vendors.

7. Summary
The big picture of the emerging Internet QoS can be summarized as follows:
1. Customers negotiate SLAs with ISPs. The SLAs specify what services the customers will receive.
SLAs can be static or dynamic. For static SLAs, customers can transmit data at any time. For dy-
namic SLAs, customers must use a signaling protocol such as RSVP to request for services on de-
mand before transmitting data. The Bandwidth Brokers in the customer domains decide how applica-
tions share the services specified by the SLAs. The DS fields of packets are marked accordingly to
indicate the desired services.
2. The ingress routers of ISPs are configured with classification, policing and re-marking rules. The
egress routers of ISP networks are configured with re-shaping rules. Such rules may be configured
manually by network administrators or dynamically by some protocol such as LDAP or RSVP. ISPs
must implement admission control in order to support dynamic SLAs. Classification, marking, po-
licing and shaping/reshaping are only done at the boundary routers. Core routers are shielded from
the signaling process. They need only implement two queues with strict priority. They process pack-
ets based solely on their DS fields.
3. With MPLS, LSPs are set up between each ingress-egress pair. At the ISP ingress routers, labels and
COS fields are determined from the classification and routing results. MPLS headers are then in-

22

serted into the packets. Core routers process packets based on their labels and COS fields only. La-
bels are removed before packets leave a MPLS domain.
4. Constraint Based Routing can be used to compute the routes subject to QoS and policy constraints.
The goal is to meet the QoS requirements of traffic and to improve utilization of the networks.
5. MPLS and Constraint Based Routing can be used together to control the path of traffic so as to avoid
congestion and improve the utility of the networks.
6. The positions of Integrated Services/RSVP, Differentiated Service, MPLS and Constraint Based
Routing in the Internet network model are depicted below.
Application Layer
Transport Layer Integrated Service/RSVP, Differentiated Services

Network Layer Constraint Based Routing

MPLS
Link Layer

Acknowledgement
The authors sincerely thank the anonymous reviewers for their insightful comments.

References:
1. R. Comerford, State of the Internet: Roundtable 4.0, IEEE Spectrum, Oct. 1998
2. D. Ferrari and L. Delgrossi, Charging For QoS, IEEE/IFIP IWQOS ’98 keynote paper, Napa, Califor-
nia, May 1998
3. P. Ferguson and G. Huston, “Quality of Service”, John Wiley Sons, 1998
4. Braden, R., Clark, D. and Shenker, S., Integrated Services in the Internet Architecture: an Overview,
Internet RFC 1633, Jun. 1994
5. R. Jain, Myths about Congestion Management in High Speed Networks, Internetworking: Research
and Experience, Volume 3, 1992, pp. 101-113.
6. S. Shenker, C. Partridge and R. Guerin, Specification of Guaranteed Quality of Service, RFC 2212,
Sept. 1997
7. J. Wroclawski, Specification of the Controlled-Load Network Element Service, RFC 2211, Sept. 1997
8. R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin, Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification, RFC 2205, Sept. 1997
9. D. Ferrari, D. Verma, A Scheme for Real-Time Channel Establishment in Wide-Area Networks, IEEE
JSAC, vol. 8, no. 3, April 1990, pp. 368-379.
10. A. Banerjea and B. Mah, The Real-Time Channel Administration Protocol, Proceedings of the 2nd
International Workshop on Network and Operating System Support for Digital Audio and Video
(NOSSDAV'91), Springer-Verlag, Heidelberg, Germany, pp. 160-170.

23

11. R. Guerin, S. Blake and S. Herzog, Aggregating RSVP-based QoS Requests, Internet draft draft-
guerin-aggreg-RSVP-00.txt, Nov. 1997
12. D. Clark, The Design Philosophy of the DARPA Internet Protocol, ACM SIGCOMM ’88, Aug. 1988
13. J. Postel, Service Mappings, RFC 795, Sept. 1981.
14. Cisco’s 12000 Series, http://www.cisco.com/warp/public/733/12000/
15. Ascend’s GRF routers, http://www.ascend.com/300.html
16. Bay Networks’ Accelar Routing Switches, http://business5.baynetworks.com/MainBody.asp
17. 3Com’s switches, http://www.3com.com/products/switches.html
18. Juniper’s M40 Series, http://www.juniper.net/products/default.htm
19. Lucent’s PacketStar 6400 Series, http://www.lucent.com:80/dns/products/ps6400.html
20. A. Parekh, A Generialized Processor Sharing Approach to Flow Control in Integrated Services Net-
works, Ph.D. thesis, MIT, Feb. 1992
21. C. Partridge, Gigabit Networking, Addison-Wesley, 1994
22. H. Zhang, Service Disciplines For Guaranteed Performance Service in Packet-Switching Networks,
Proceedings of the IEEE, 83(10), Oct. 1995
23. S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, An Architecture for Differentiated
Services, RFC 2475, Dec. 1998.
24. Y.Bernet et al., A Framework for Differentiated Services, Internet draft draft-ietf-diffserv-
framework-00.txt, May 1998
25. K. Nichols, V. Jacobson and L. Zhang, A Two-bit Differentiated Services Architecture for the Inter-
net, Internet Draft, draft-nichols-diff-svc-arch-00.txt, Nov. 1997.
26. K. Nichols et al., Differentiated Services Operational Model and Definitions, Internet draft draft-
nichols-dsopdef-00.txt, Feb. 1998
27. D. Clark and J. Wroclawski, An Approach to Service Allocation in the Internet, Internet draft draft-
clark-different-svc-alloc-00.txt, Jul. 1997
28. K. Nichols, S. Blake, F. Baker and D. Black, Definition of the Differentiated Services Field (DS Field)
in the IPv4 and IPv6 Headers, RFC 2474, Dec. 1998.
29. J. Heinanen, F. Baker, W. Weiss and J. Wroclawski, Assured Forwarding PHB Group, Internet draft
draft-ietf-diffserv-af-03.txt, Nov. 1998
30. Y.Bernet et al., A Framework for use of RSVP with Diff-serv Networks, Internet draft draft-ietf-
diffserv-rsvp-00.txt, Jun. 1998
31. T. Li and Y. Rekhter, Provider Architecture for Differentiated Services and Traffic Engineering
(PASTE), RFC 2430, Oct. 1998
32. B. Braden et al., Recommendation on Queue Management and Congestion Avoidance in the Internet,
RFC 2309, Apr. 1998
33. W. Yeong, T. Howes, and S. Kille, Lightweight Directory Access Protocol, RFC 1777, Mar. 1995.
34. E. Rosen, A. Viswanathan and R.Callon, Multiprotocol Label Switching Architecture, Internet draft
draft-ietf-mpls-arch-01.txt, Mar. 1998
35. L. Andersson, P. Doolan, N. Feldman, A. Fredette and R. Thomas, Label Distribution Protocol, Inter-
net draft draft-ietf-mpls-ldp-02.txt, Nov. 1998

24

36. P. Vaananen and R. Ravikanth, Framework for Traffic Management in MPLS Networks, Internet draft
draft-vaananen-mpls-tm-framework-00.txt, Mar. 1998
37. D. Awduche, J. Malcolm, J. Agogbua, M. O’Dell and J. McMaus, Requirements for Traffic Engineer-
ing over MPLS, Internet draft draft-ietf-mpls-traffic-eng.00.txt, Oct. 1998
38. D. Awduche, D. Gan, T. Li, G. Swallow and V. Srinivasan, Extension to RSVP for Traffic Engineer-
ing, Internet draft draft-swallow-mpls-RSVP-trafeng-00.txt, Aug. 1998
39. T. Li, CPE based VPNs using MPLS, Internet draft draft-li-MPLS-vpn-00.txt, Oct. 1998
40. M. Waldvoge, G. Varghese, J. Turner and B. Plattner, Scalable High Speed IP Routing Lookups,
ACM SIGCOMM ’97, Cannes, France, Sept. 1997. http://www.acm.org/sigcomm/sigcomm97
41. S. Nilsson and G. Karlsson, Fast Address Lookup for Internet Routers, ACM SIGCOMM ’97, Cannes,
France, Sept. 1997. http://www.acm.org/sigcomm/sigcomm97
42. J. Moy, “OSPF Version 2”, RFC 2178, Apr. 1998
43. C. Villamizar and T. Li, IS-IS Optimized Multipath (IS-IS OMP), Internet draft draft-villamizar-isis-
omp-00.txt, Oct. 1998
44. E. Crawley, R. Nair, B. Jajagopalan and H. Sandick, A Framework for QoS-based Routing in the Inter-
net, RFC 2386, Aug. 1998
45. G. Apostolopoulos, R. Guerin, S. Kamat and S. Tripathi, Quality of Service Based Routing: A Per-
formance Perspective, ACM SIGCOMM '98, pp. 17-28, Vancouver, Canada, Aug. 1998.
46. Q. Ma, QoS Routing in the Integrated Services networks, Ph.D. thesis, CMU-CS-98-138, Jan. 1998
47. Z. Wang, Routing and Congestion Control in Datagram Networks, Ph.D. thesis, Dept. of Computer
Sci., University College London, Jan. 1992
48. R. Guerin, S. Kamat, A. Orda, T. Przygienda, and D. Williams, QoS Routing Mechanisms and OSPF
extensions, Internet draft draft-guerin-QoS-routing-ospf-03.txt, Jan. 1998
49. Z. Zhang, C. Sanchez, B. Salkewicz, and E. Crawley, QoS Extensions to OSPF, Internet draft draft-
zhang-qps-ospf-01, Sept. 1997
50. Z. Wang and J. Crowcroft, Quality of Service Routing for Supporting Multimedia Applications, IEEE
JSAC, Sept. 1996
51. A. Orda, Routing with End-to-End QoS Guarantees in Broadband Networks, Technical Report, Tech-
nion, I.I.T., Isreal
52. Y. Goto, M. Ohta and K. Araki, Path QoS Collection for Stable Hop-by-hop QoS Routing, Proceed-
ings of INET '97, Kuala Lumpur, Malaysia, Jun. 1997.
53. F. Kelly, “Notes on Effective Bandwidths”, in Stochastic Networks: Theory and Applications (Edi-
tors: F. Kelly, S. Zachary and I.B. Ziedins), pp. 141-168, Oxford University Press, 1996.
54. F. Kelly, Modelling Communication Networks, Present and Future, Philosophical Transactions of the
Royal Society A354, pp. 437-463, 1996.
55. G. R. Ash, J. S. Chen, A. E. Frey and B. D. Huang, RealTime Network Routing in a Dynamic Class-of-
Service Network, Proceedings of ITC 13, Copenhagen, Jun. 1991.
56. ATM Forum PNNI subworking group, Private Network-Network Interface Spec. v1.0 (PNNI 1.0), af-
pnni-0055.00, Mar. 1996.
57. Juniper Whitepaper, Optimizing Routing Software for Reliable Internet Growth,
http://www.juniper.net/leadingedge/whitepapers/optimizing-routing-sw.fm.html

25

Qos

More Related Content

What's hot (19)

Similar to Qos (20)

More from guestd90cb0 (16)

Qos