Quality of service

From Wikipedia, the free encyclopedia

Jump to: navigation, search

It has been suggested that Downstream QoS and talk:Quality of service#Merge
Downstream QoS be merged into this article or section. (Discuss)
This article needs additional citations for verification.
Please help improve this article by adding reliable references. Unsourced material may be challenged
and removed. (August 2007)

In the field of computer networking and other packet-switched telecommunication networks, the
traffic engineering term quality of service (QoS) refers to resource reservation control
mechanisms rather than the achieved service quality. Quality of service is the ability to provide
different priority to different applications, users, or data flows, or to guarantee a certain level of
performance to a data flow. For example, a required bit rate, delay, jitter, packet dropping
probability and/or bit error rate may be guaranteed. Quality of service guarantees are important if
the network capacity is insufficient, especially for real-time streaming multimedia applications
such as voice over IP, online games and IP-TV, since these often require fixed bit rate and are
delay sensitive, and in networks where the capacity is a limited resource, for example in cellular
data communication. In the absence of network congestion, QoS mechanisms are not required.

A network or protocol that supports QoS may agree on a traffic contract with the application
software and reserve capacity in the network nodes, for example during a session establishment
phase. During the session it may monitor the achieved level of performance, for example the data
rate and delay, and dynamically control scheduling priorities in the network nodes. It may release
the reserved capacity during a tear down phase.

A best-effort network or service does not support quality of service. An alternative to complex
QoS control mechanisms is to provide high quality communication over a best-effort network by
over-provisioning the capacity so that it is sufficient for the expected peak traffic load.

In the field of telephony, quality of service was defined in the ITU standard X.902 as "A set of
quality requirements on the collective behavior of one or more objects". Quality of Service
comprises requirements on all the aspects of a connection, such as service response time, loss,
signal-to-noise ratio, cross-talk, echo, interrupts, frequency response, loudness levels, and so on.
A subset of telephony QoS is Grade of Service (GOS) requirements, which comprises aspects of
a connection relating to capacity and coverage of a network, for example guaranteed maximum
blocking probability and outage probability.[1]

QoS is sometimes used as a quality measure, with many alternative definitions, rather than
referring to the ability to reserve resources. Quality of service sometimes refers to the level of
quality of service, i.e. the guaranteed service quality. High QoS is often confused with a high
level of performance or achieved service quality, for example high bit rate, low latency and low
bit error probability. See also Relation to subjective quality measures below.
Contents
[hide]

• 1 Relation to subjective quality measures

• 2 Problems
• 3 Applications requiring QoS
• 4 Obtaining QoS
• 5 QoS mechanisms
• 6 QoS Priority Levels
• 7 QoS problems
• 8 Protocols that provide Quality of Service
• 9 QoS Solutions
• 10 Quality of service procedures
• 11 Quality of service circumvention
• 12 Doubts about quality of service
• 13 See also
• 14 Standards Activity
o 14.1 Open Source QoS Software
• 15 References
• 16 External links

• 17 Notes

[edit] Relation to subjective quality measures

An alternative and disputable definition of QoS, used especially in application layer services
such as telephony and streaming video, is a metric that reflects or predicts the subjectively
experienced quality. Other terms with similar meaning are the Quality of Experience (QoE)
subjective business concept, the "user perceived performance" [2], the "degree of satisfaction of
the user", the "number of happy customers" or the Mean Opinion Score (MOS). In this context,
QoS is the cumulative effect on subscriber satisfaction of all imperfections affecting the service.
This definition includes the application and the human in the assessment, and demands an
appropriate weighting of diverse objective measures.

[edit] Problems
When the Internet was first deployed many years ago, it lacked the ability to provide Quality of
Service guarantees due to limits in router computing power. It therefore ran at default QoS level,
or "best effort". There were four "Type of Service" bits and three "Precedence" bits provided in
each message, but they were ignored. These bits were later re-defined as DiffServ Code Points
(DSCP) and are largely honored in peered links on the modern Internet.

When looking at packet-switched networks, Quality of Service is affected by various factors,

which can be divided into "human" and "technical" factors. Human factors include: stability of
service, availability of service, delays, user information. Technical factors include: reliability,
scalability, effectiveness, maintainability, Grade of Service, etc.[3]

Many things can happen to packets as they travel from origin to destination, resulting in the
following problems as seen from the point of view of the sender and receiver:

Dropped packets
The routers might fail to deliver (drop) some packets if they arrive when their buffers are
already full. Some, none, or all of the packets might be dropped, depending on the state
of the network, and it is impossible to determine what will happen in advance. The
receiving application may ask for this information to be retransmitted, possibly causing
severe delays in the overall transmission.
Delay
It might take a long time for a packet to reach its destination, because it gets held up in
long queues, or takes a less direct route to avoid congestion. In some cases, excessive
delay can render an application such as VoIP or online gaming unusable.
Jitter
Packets from the source will reach the destination with different delays. A packet's delay
varies with its position in the queues of the routers along the path between source and
destination and this position can vary unpredictably. This variation in delay is known as
jitter and can seriously affect the quality of streaming audio and/or video.
Out-of-order delivery
When a collection of related packets is routed through the Internet, different packets may
take different routes, each resulting in a different delay. The result is that the packets
arrive in a different order than they were sent. This problem requires special additional
protocols responsible for rearranging out-of-order packets to an isochronous state once
they reach their destination. This is especially important for video and VoIP streams
where quality is dramatically affected by both latency and lack of isochronicity.
Error
Sometimes packets are misdirected, or combined together, or corrupted, while en route.
The receiver has to detect this and, just as if the packet was dropped, ask the sender to
repeat itself.

[edit] Applications requiring QoS

A defined Quality of Service may be required for certain types of network traffic, for example:

• streaming multimedia may require guaranteed throughput to ensure that a minimum level
of quality is maintained.
• IPTV offered as a service from a service provider such as AT&T's U-verse
• IP telephony or Voice over IP (VOIP) may require strict limits on jitter and delay
• Video Teleconferencing (VTC) requires low jitter and latency
• Alarm signalling (e.g., Burglar alarm)
• dedicated link emulation requires both guaranteed throughput and imposes limits on
maximum delay and jitter
 • a safety-critical application, such as remote surgery may require a guaranteed level of
availability (this is also called hard QoS).
• a remote system administrator may want to prioritize variable, and usually small,
amounts of SSH traffic to ensure a responsive session even over a heavily-laden link.
• online games, such as fast paced real time simulations with multiple players. Lack of QoS
may produce 'lag'.
• Industrial ethernet protocols such as EtherNet/IP which are used for real-time control of
machinery

These types of service are called inelastic, meaning that they require a certain minimum level of
bandwidth and a certain maximum latency to function.

By contrast, elastic applications can take advantage of however much or little bandwidth is
available. Bulk file transfer applications that rely on TCP are generally elastic.

[edit] Obtaining QoS

• Per call
• In call
• In advance: When the expense of mechanisms to provide QoS is justified, network
customers and providers typically enter into a contractual agreement termed a service
level agreement (SLA) which specifies guarantees for the ability of a network/protocol to
give guaranteed performance/throughput/latency bounds based on mutually agreed
measures, usually by prioritizing traffic.
• Reserving resources: Resources are reserved at each step on the network for the call as it
is set up. An example is RSVP, Resource Reservation Protocol.

[edit] QoS mechanisms

An alternative to complex QoS control mechanisms is to provide high quality communication by
generously over-provisioning a network so that capacity is based on peak traffic load estimates.
This approach is simple and economical for networks with predictable and light traffic loads.
The performance is reasonable for many applications. This might include demanding
applications that can compensate for variations in bandwidth and delay with large receive
buffers, which is often possible for example in video streaming.

Commercial VoIP services are often competitive with traditional telephone service in terms of
call quality even though QoS mechanisms are usually not in use on the user's connection to his
ISP and the VoIP provider's connection to a different ISP. Under high load conditions, however,
VoIP quality degrades to cell-phone quality or worse. The mathematics of packet traffic indicate
that a network with QoS can handle four times as many calls with tight jitter requirements as one
without QoS[citation needed]. Yuksel et al. have determined 60% required extra capacity by simulating
IP traffic under conservative assumptions [4].
The amount of over-provisioning in interior links required to replace QoS depends on the
number of users and their traffic demands. As the Internet now services close to a billion users,
there is little possibility that over-provisioning can eliminate the need for QoS when VoIP
becomes more commonplace[citation needed].

For narrowband networks more typical of enterprises and local governments, however, the costs
of bandwidth can be substantial and over provisioning is hard to justify.[citation needed] In these
situations, two distinctly different philosophies were developed to engineer preferential treatment
for packets which require it.

Early work used the "IntServ" philosophy of reserving network resources. In this model,
applications used the Resource reservation protocol (RSVP) to request and reserve resources
through a network. While IntServ mechanisms do work, it was realized that in a broadband
network typical of a larger service provider, Core routers would be required to accept, maintain,
and tear down thousands or possibly tens of thousands of reservations. It was believed that this
approach would not scale with the growth of the Internet, and in any event was antithetical to the
notion of designing networks so that Core routers do little more than simply switch packets at the
highest possible rates.

The second and currently accepted approach is "DiffServ" or differentiated services. In the
DiffServ model, packets are marked according to the type of service they need. In response to
these markings, routers and switches use various queuing strategies to tailor performance to
requirements. (At the IP layer, differentiated services code point (DSCP) markings use the 6 bits
in the IP packet header. At the MAC layer, VLAN IEEE 802.1Q and IEEE 802.1D can be used
to carry essentially the same information)

Routers supporting DiffServ use multiple queues for packets awaiting transmission from
bandwidth constrained (e.g., wide area) interfaces. Router vendors provide different capabilities
for configuring this behavior, to include the number of queues supported, the relative priorities of
queues, and bandwidth reserved for each queue.

In practice, when a packet must be forwarded from an interface with queuing, packets requiring
low jitter (e.g., VoIP or VTC) are given priority over packets in other queues. Typically, some
bandwidth is allocated by default to network control packets (e.g., ICMP and routing protocols),
while best effort traffic might simply be given whatever bandwidth is left over.

Additional bandwidth management mechanisms may be used to further engineer performance, to

include:

• Traffic shaping (rate limiting):

o Token bucket
o Leaky bucket
o TCP rate control - artificially adjusting TCP window size as well as controlling
the rate of ACKs being returned to the sender[citation needed]
• Scheduling algorithms:
o Weighted fair queuing (WFQ)
 o Class based weighted fair queuing
o Weighted round robin (WRR)
o Deficit weighted round robin (DWRR)
o Hierarchical Fair Service Curve (HFSC)
• Congestion avoidance:
o RED, WRED - Lessens the possibility of port queue buffer tail-drops and this
lowers the likelihood of TCP global synchronization
o Policing (marking/dropping the packet in excess of the committed traffic rate and
burst size)
o Explicit congestion notification
o Buffer tuning

As mentioned, while DiffServ is used in many sophisticated enterprise networks, it has not been
widely deployed in the Internet. Internet peering arrangements are already complex, and there
appears to be no enthusiasm among providers for supporting QoS across peering connections, or
agreement about what policies should be supported in order to do so.

One compelling example of the need for QoS on the Internet relates to this issue of congestion
collapse. The Internet relies on congestion avoidance protocols, as built into TCP, to reduce
traffic load under conditions that would otherwise lead to Internet Meltdown. QoS applications
such as VoIP and IPTV, because they require largely constant bitrates and low latency cannot
use TCP, and cannot otherwise reduce their traffic rate to help prevent meltdown either. QoS
contracts limit traffic that can be offered to the Internet and thereby enforce traffic shaping that
can prevent it from becoming overloaded, hence they're an indispensable part of the Internet's
ability to handle a mix of real-time and non-real-time traffic without meltdown.

Asynchronous Transfer Mode (ATM) network protocol has an elaborate framework to plug in
QoS mechanisms of choice. Shorter data units and built-in QoS were some of the unique selling
points of ATM in the telecommunications applications such as video on demand, voice over IP.

[edit] QoS Priority Levels

Priority Level Traffic Type
0 Best Effort
1 Background
2 Standard (Spare)
Excellent Load
3
(Business Critical)
Controlled Load
4
(Streaming Multimedia)
5 Voice and Video
 (Interactive Media and Voice)

[Less than 100ms latency and

jitter]
Layer 3 Network Control
Reserved Traffic
6
[Less than 10ms latency and
jitter]
Layer 2 Network Control
Reserved Traffic

[Lowest latency and jitter]

[edit] QoS problems

• Internet2 QoS Working Group concluded that increasing bandwidth is probably more
practical than implementing QoS.[1][2]

[edit] Protocols that provide Quality of Service

• The Type of Service (TOS) field in the IP header (now superseded by Diffserv)
• IP Differentiated services (DiffServ)
• IP Integrated services (IntServ)
• Resource reSerVation Protocol (RSVP)
• Multiprotocol Label Switching (MPLS) provides eight QoS classes
• RSVP-TE
• Frame relay
• X.25
• Some ADSL modems
• Asynchronous Transfer Mode (ATM)
• IEEE 802.1p
• IEEE 802.1Q
• IEEE 802.11e
• IEEE 802.11p
• HomePNA Home networking over coax and phone wires
• The ITU-T G.hn standard provides QoS by means of "Contention-Free Transmission
Opportunities" (CFTXOPs) which are allocated to flows which require QoS and which
have negotiated a "contract" with the network controller. G.hn also supports non-QoS
operation by means of "Contention-based Time Slots".
[edit] QoS Solutions
The research project MUSE defined a QoS concept in Phase I which was further worked out in
another research project PLANETS. The new idea of this solution is to agree on a discrete jitter
value per QoS class which is imposed on network nodes. Including best effort, four QoS classes
were defined, two elastic and two inelastic. The solution has several benefits:

• End-to-end delay and packet loss rate can be predicted

• It is easy to implement with simple scheduler and queue length given in PLANETS
• Nodes can be easily verified for compliance
• End users do notice the difference in quality

The MUSE project finally elaborated its own QoS solution which is primarily based in:

• The usage of traffic classes

• Selective CAC concept
• Appropriate network dimensioning

[edit] Quality of service procedures

Unlike the Internet 2 Abilene Network, the Internet is actually a series of exchange points
interconnecting private networks and not a network in its own right.[5] Hence the Internet's core is
owned and managed by a number of different Network Service Providers, not a single entity. Its
behavior is much more stochastic or unpredictable. Therefore, research continues on QoS
procedures that are deployable in large, diverse networks.

There are two principal approaches to QoS in modern packet-switched networks, a

parameterized system based on an exchange of application requirements with the network, and a
prioritized system where each packet identifies a desired service level to the network. On the
Internet, Integrated services ("IntServ") implements the parameterized approach. In this model,
applications use the Resource Reservation Protocol (RSVP) to request and reserve resources
through a network.

Differentiated services ("DiffServ") implements the prioritized model. DiffServ marks packets
according to the type of service they need. In response to these markings, routers and switches
use various queueing strategies to tailor performance to requirements. (At the IP layer,
differentiated services code point (DSCP) markings use the first 6 bits in the TOS field of the IP
packet header. At the MAC layer, VLAN IEEE 802.1q and IEEE 802.1D can be used to carry
essentially the same information.)

Cisco IOS NetFlow and the Cisco Class Based QoS (CBQoS)Management Information Base
(MIB) can both be leveraged within a Cisco network device to obtain visibility into QoS policies
and their effectiveness on network traffic. [6]

[edit] Quality of service circumvention

Strong cryptography network protocols such as Secure Sockets Layer, I2P, and virtual private
networks obscure the data transferred using them. As all electronic commerce on the Internet
requires the use of such strong cryptography protocols, unilaterally downgrading the
performance of encrypted traffic creates an unacceptable hazard for customers. Yet, encrypted
traffic is otherwise unable to undergo deep packet inspection for QoS.

[edit] Doubts about quality of service

Gary Bachula, Vice President for External Affairs for Internet2, asserts that specific QoS
protocols are unnecessary in the core network as long as the core network links are "over-
provisioned" to the point that network traffic never encounters delay. In "quality of service"
engineering, this formulation is guaranteed by the admission control feature.

The Internet2 project found, in 2001, that the QoS protocols were probably not deployable inside
its Abilene network with equipment available at that time. While newer routers are capable of
following QoS protocols with no loss of performance, equipment available at the time relied on
software to implement QoS. The Internet2 Abilene network group also predicted that "logistical,
financial, and organizational barriers will block the way toward any bandwidth guarantees" by
protocol modifications aimed at QoS.[7][8] In essence they believe that the economics would be
likely to make the network providers deliberately erode the quality of best effort traffic as a way
to push customers to higher priced QoS services.

The Abilene network study was the basis for the testimony of Gary Bachula to the Senate
Commerce Committee's Hearing on Network Neutrality in early 2006. He expressed the opinion
that adding more bandwidth was more effective than any of the various schemes for
accomplishing QoS they examined.[9]

Bachula's testimony has been cited by proponents of a law banning quality of service as proof
that no legitimate purpose is served by such an offering. Of course this argument is dependent on
the assumption that over-provisioning isn't a form of QoS and that it's always possible.
Obviously, cost and other factors affect the ability of carriers to build and maintain permanently
over-provisioned networks.

[edit] See also

• BSSGP
• Best-effort
• Class of Service
• Deep packet inspection (DPI)
• Downstream QoS
• Grade of service (GOS)
• Mean Opinion Score (MOS)
• Mobile QoS
• Network neutrality
• Quality of Experience (QoE)
 • Series of tubes
• Streaming media
• Subjective video quality
• Tiered Internet
• Traffic shaping
• QPPB

[edit] Standards Activity

• Quality of service, or QoS, in the field of telephony, was defined in 1994 in the ITU-T
Recommendation E.800. This definition is very broad, listing 6 primary components:
Support, Operability, Accessibility, Retainability, Integrity and Security.

• In 1998 the ITU published a document discussing QoS in the field of data networking,
ITU-T Recommendation X.641. X.641 offers a means of developing or enhancing
standards related to QoS and provide concepts and terminology that will assist in
maintaining the consistency of related standards.

• The main QoS-related IETF RFCs are Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers (RFC 2474), and Resource ReSerVation Protocol
(RSVP) (RFC 2205); both these are discussed above. The IETF has also published two
RFCs giving background on QoS: RFC 2990: Next Steps for the IP QoS Architecture,
and RFC 3714: IAB Concerns Regarding Congestion Control for Voice Traffic in the
Internet.

[edit] Open Source QoS Software

• Linux Advanced Routing & Traffic Control

• Bandwidth Arbitrator
• Untangle
• Zero Shell
• Mod qos adding QoS to web applications

[edit] References
• "QoS Over Heterogeneous Networks" by Mario Marchese (Wiley, 2007, ISBN 978-0-
470-01752-4)
• "Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice" by John
Evans, Clarence Filsfils (Morgan Kaufmann, 2007, ISBN 0-12-370549-5)
• "Technical, Commercial and Regulatory Challenges of QoS: An Internet Service Model
Perspective" by Xipeng Xiao (Morgan Kaufmann, 2008, ISBN 0-12-373693-5)
• RFC 1633 - Integrated Services in the Internet Architecture: an Overview
• RFC 2475 - An Architecture for Differentiated Services
• RFC 3209 - RSVP-TE: Extensions to RSVP for LSP Tunnels
 • Lelli, F. Maron, G. Orlando, S. Client Side Estimation of a Remote Service Execution.
15th International Symposium on Modeling, Analysis, and Simulation of Computer and
Telecommunication Systems, 2007. MASCOTS '07. Electronic Edition

[edit] External links

Listen to this article (info/dl)

This audio file was created from a revision dated 2008-07-18, and does not reflect subsequent edits to the article. (Audio help)
More spoken articles

• QoS Tutorial
• Quality of Service Networking

Guaranteeing Quality of Service for the Web

using ATM
Werner Almesberger, Eric Gauthier, Jean-Yves Le Boudec, Philippe Oechslin (1),

Communication Networks Lab , Swiss Federal Institute of Technology, Lausanne, Switzerland.

Abstract
When using the Web over the TCP/IP protocol suite of the Internet there is (yet) no possibility to
guarantee bandwidth or delay for a transmission. For multimedia documents, transmission with
guaranteed quality of service (QoS) is very desirable. Also, commercial users and providers are
interested in guaranteeing the quality of the service being paid for. ATM networks which are
being deployed now are one means of solving this problem. They offer high bandwidths and QoS
negotiation at connection establishment. We analyze how the Internet and ATM networks can
interoperate to offer the best of both worlds to Web users while preserving compatibility with
users which can not benefit of ATM connections. We present a solution built on a dual stack (IP
& ATM). Finally we show how this solution can interwork with IP-only users to give them the
benefits of partial ATM connectivity.

• Introduction
• IP over ATM
• Resource reservation schemes for the Internet
• A simple solution: The dual stack approach
 • Interoperability with non-ATM systems
• Conclusions

1. Introduction
1.1 The problem

The problem we want to solve is to guarantee quality of network service to Web users. With the
current implementation of the Internet the delay and throughput experienced when browsing the
Web can vary greatly over time and location. These variations get more important as Web
documents get richer in multimedia information. If an agent wants to display a multimedia
stream while it is downloading it from a server, it will need the guarantee that the stream is
delivered at least as fast as it is displayed. If the same agent wants to first download the
multimedia document before visualizing it, it may still need the guarantee that the document will
be received within a useful amount of time. If large documents are provided by commercial
services, then the users will want the guarantee that they get a quality of service worth their
money. This is also true for time critical documents like stock-exchange data.

Quality of network service is not actually a problem of the Web itself but much more of the
network it is built upon. Therefore solutions are in better usage of available network services or
in the development of new networks and services.

Solutions could be found using new IETF protocols like RSVP and NHRP (see Section 2 and
Section 3). In this paper, however, we make the hypothesis that RSVP and NHRP will not soon
be available and explore solutions using native ATM connections.

1.2 Background

The Internet Protocol (IP) is the network level protocol of the Internet. It follows the
paradigms of connectionless datagram forwarding and best effort service. IP routers forward IP
datagrams to intermediate routers until they eventually reach their destination. If the network is
overloaded packets are dropped. These paradigms make it hard to control the QoS between two
end users on the net. This is a well known problem and one solution for guaranteeing QoS is the
recent RSVP protocol [Zhang].

Asynchronous Transfer Mode (ATM) is the standard for Broadband Integrated Service Digital
Networks (B-ISDN). It is a connection oriented network based on fast packet switching.
Communications between ATM end-systems require that a connection be setup prior to
communication. ATM connections have a high throughput and a low latency since ATM cells
are switched in hardware. In addition, connection setup enables resource reservation. These
features make ATM connections well suited for audio and video transmissions.

1.3 Current and Future Work

One example of real-time multimedia communication within the Web can be found in [Chen].
This paper describes an agent called vosaic which allows to setup teleconferences through the
Web. Interoperation between IP and ATM networks is being worked on at the IETF. The
University of Illinois at Urbana-Champaign is developing IP over ATM using the X-ATM kernel
[Tan], which is a derivative of the X-kernel. At the University of Waterloo a research project has
been proposed with the goal to adapt HTTP to ATM. At the Communication Networks
Laboratory of the Swiss Federal Institute of Technology we are currently implementing IP over
ATM on Linux. We have chosen Linux because it gives us full access to the kernel and because
the results can be distributed freely. This work is part of a new project called Web over ATM
where we explore the interworking between IP and ATM, in regard to the Web as a main
application.

1.4 Structure of this document

In Section 2 we describe how IP currently works over ATM networks and how the standards are
evolving. In Section 3 we explain how the RSVP protocol reserves resources in IP networks.
Section 4 introduces our solution with a dual stack approach while Section 5 discusses
interoperability issues between our solution and non-ATM hosts. Section 6 is the conclusion of
our paper.

2. IP over ATM
The scalable bandwidth, the guaranteed QoS and its ability to integrated many different services
make ATM a big competitor for future LANs, WANs and backbone networks. This has been
recognized by the Internet Engineering Task Force (IETF) which has developed standards on
how to overlay IP networks over ATM networks.

A first standard is the so-called classical IP over ATM defined mainly in RFC1577. In that
scheme IP hosts are grouped in Logical IP Subnets (LIS) which are typically connected to a
default IP router. The ATM network is treated much like a LAN and hosts within a LIS can
connect through an address resolution protocol that maps IP addresses to ATM addresses. If a
packet has to go to another host outside the LIS, it is sent to the default router which forwards it.
The advantage of this solution is that it works in the same manner as existing IP networks, hence
the name. The disadvantage is that packets may be sent through a set of routers and ATM
connections even if a direct ATM connection would be possible.

A better solution under development is the Next Hop Resolution Protocol (NHRP). With this
protocol, address resolution requests are propagated to different servers in the network. The reply
to a request gives the information needed to establish a direct connection to the destination host
or, if the host is not on the ATM network, to the closest router on the edge of the ATM network.
NHRP currently has the status of an Internet draft.

The different schemes for IP over ATM will allow to run the Web transparently over ATM
networks. However they don't provide any way to reserve resources or to guarantee QoS. The
IETF has a solution for resource reservation in IP networks as we will see in the next section.
3. Resource reservation schemes for the Internet
Having identified resource reservation as a key aspect for transmission of real-time multimedia
information the IETF has developed the Resource reSerVation Protocol [Zhang]. In RSVP, a
receiver can request a resource reservation along the path between the source and the receiver.
This reservation is subject to call acceptance control by all intermediate IP routers which support
RSVP. Once a connection is established, the routers schedule the transmission of IP datagrams in
function of the priority of the stream they belong to. RSVP has multicast capabilities. This means
that resource reservations are not only made between two endpoints but within a multicast tree.
RSVP is about to become a IETF standard.

Using RSVP a certain QoS can be guaranteed since resources are reserved at each intermediate
hop. However, the datagrams still travel hop by hop. In an ATM environment it would be much
more efficient to establish direct connections.

4. A simple solution: The dual stack approach

4.1 Why do we need a solution?

Coming back to our original problem it seems that a solution is going to emerge all by itself.
Once the routers of the Internet will implement RSVP, Web agents and servers will be able to
use this protocol to guarantee the QoS for the delivery of Web documents. If by that time NHRP
is implemented in ATM parts of the Internet (LANs, WANs, backbones) then it will even be
possible to bypass intermediate routers and to have direct connections between servers and
agents. The drawbacks of this solution are complexity and penetration time. The solution is
complex because two new protocols need to be implemented on all the routers of the network.
Time considerations are even more important: Although RSVP is about to become a standard, it
only provides for reservation of resources. It does not, however, give an exact definition of what
resources are nor how they can be monitored and policed. NHRP on its side is still a draft and
different issues need to be resolved before it can be proposed as a standard. Thus a complete
solution using RSVP and NHRP is not yet operational.

We make the hypothesis that we are in a network were RSVP and NHRP are not yet available
(which may be true for quite some time). Thus we will explore a solution which does not make
use of these protocols.

4.2 The dual stack solution

When an agent on ATM contacts a server on ATM, the agent can provide its ATM address to the
server. It would then clearly be inefficient to ask an intermediate layer of IP routers to route
documents from the server to the agent if the server can connect directly to the agent. Our
solution to the problem thus simply consists of opening a direct ATM connection between the
server and the agent whenever a document has to be transmitted with guaranteed QoS. Two
informations are needed for this: a) the server must know at which ATM address the agent can
be reached directly, if at all, and b) the server must know whether a document is QoS-sensitive
and what QoS must be requested. The first information can be included in the header of HTTP
requests while the second information can be put in the header of HTML documents. To be able
to open a connection with guaranteed QoS, the server software must also be able to interact
directly with an ATM protocol stack. The server thus uses both a TCP/IP and an ATM protocol
stack, hence the name of our solution.

This little modification allows a tremendous gain in guaranteed quality delivery without
compromising the interoperability with non-ATM servers or agents. The QoS guarantee enables
information providers to deliver high-quality documents, like video on demand or real-time
transmissions of live events which can be charged on a quality basis. A 5Mbit data stream could
be charged higher than a 1Mbit stream, with the guarantee that the user really gets what he pays
for (WYPIWYG).

Availability of a dual stack

As of today, Web servers or agents connected to ATM networks typically use classical IP over
ATM. To implement IP over ATM, their host must implement all the functionalities needed to
make pure ATM connections. Vendors of ATM Network Interface Cards (NICs) usually also
provide a pure ATM API beside the standard IP API. This provides a way of establishing pure
ATM connections between servers and agents running on ATM networks. Furthermore, a
standard ATM API is currently being defined by the ATM Forum [ATM95].

4.3 Implementation of our solution

Adding information

As we saw above, two kinds of information are needed for our solution. One has to be given by
the client and the other one in the documents.

Agent: The fact that an agent is able to use a dual stack is clearly related to the agent and not to
the data that will be transmitted. Therefore, we propose to add this information in the
'UserAgent:' field of HTTP requests. This fields allows extra information besides the product
name and version. An agent capable of receiving documents over a direct ATM connection can
indicate it by putting the keyword ATM in this field. If it wants the server to open an ATM
connection it adds the public and private ATM addresses of the agent to the ATM keyword.
(Public and private ATM networks do not use the same addressing scheme and interoperation is
only possible if the public ATM address of a gateway to the private ATM network of the
destination is given.) The version number is be 1.0. The public address is given in ascii decimal
digits and the private address in ascii hex digits. The keyword ATM and the two addresses are
separated by ascii dots. When no address is given the ATM keyword appears without addresses.

example (with address):

UserAgent: MyAgent/1.0 ATM.PublicAddress.PrivateAddress/1.0

example (without address):

UserAgent: MyAgent/1.0 ATM/1.0
Server: When the server responds to a dual-stack agent it adds an ATM field in the header of the
response to indicate its address. The format of the address is the same as for the agent:
ATM:PublicAddress.PrivateAddress

Document: The server must recognize QoS sensitive documents and know the QoS
requirements of these documents. We propose to add this information into the header of HTML
documents. This can be done using <meta> elements. The name of the elements is "ATM-QoS-
XXX" where XXX is the abbreviation for a traffic or QoS parameter according to the User
Network Interface (UNI) specification of the ATM forum [UNI3.1]. The content field contains
the value of the parameter in digital ascii representation.

example (sustainable cell rate = 2000 cells per second):

<meta HTTP-EQUIV="ATM-QoS-SCR" content="2000">

The HTTP request and response

The only particularity of HTTP requests made by a dual stack agent will be the ATM address in
the user agent field. Thus it interoperates seamlessly with standard servers. If the agent makes a
request to a dual stack server, the server recognizes the ATM keyword and watches document
headers for QoS specifications. If the agent requests a document which has no QoS
specifications then the server delivers it in the standard fashion. If the agent requests a document
with QoS specifications and indicates its ATM address, the server will set up an ATM
connection (see below). If the agent does not indicate its ATM address then the server only sends
the HTTP headers over the TCP/IP network, as if the agent had used the HEAD method rather
than the GET method. The actual content of the document is sent over an ATM connection.
From the header fields the agent can know what the QoS specification are and how long the
document is.

Data transport

In section 4.2 we have assumed that some ATM API would be available on the hosts to establish
direct ATM connections. Establishing a connection, however, is only half of the job. Once a
connection is established, some protocol has to be used to transport the data over the connection.
We have chosen UDP and TCP for pragmatic reasons. They are the standard protocols used on
the Internet and are thus thus already be available on the hosts. An ideal scheme would be that
the agent and the server negotiate the best transport protocol among a set of protocols available
to them, depending on the type of data to transmit. This negotiation is however out of the scope
of this paper.

One way of running TCP over a pure ATM connection would be to use TUNIC (TCP over non-
existent IP Connection) [Cole]. As TUNIC is not standardized this solution would require the
development of a non-standard implementation. Rather than to reimplement TCP we therefore
propose another solution which reuses the TCP of the hosts by making a slight modification to its
IP layer. This solution allows to use the same socket interface for data going over the TCP/IP
network and over the ATM network. It hinges on ARP (address resolution protocol) tables of the
IP layer The address resolution protocol maps IP addresses to LLC addresses on the network to
which a host is attached. To avoid to make ARP lookups for every packet sent out, address
mappings are kept in an ARP table. When IP is run over ATM then the ARP table maps IP
addresses to VCI/VPI pairs. Our solution requires that entries in this table can be set and locked
by the server or client application. It also requires the possibility to add QoS parameters and
socket identifiers in ARP table entries.

The exact procedure for the establishment of an ATM connection is as follows: When the agent
requests a document it puts the ATM keyword in its userAgent field without indicating its
address. If the requested document has QoS indication the server will only deliver the header of
the document as if the HEAD method had been used. Having received the header of the
document, with the ATM-QoS-XXX fields, the Agent can chose to download the document over
ATM or IP. To request the document over ATM it repeats the same request but adds its ATM
address to the userAgent field. To request the document over IP it makes the same request
without the ATM keyword. Figure 1 illustrates the requests and responses.
Figure 1. Establishment of ATM connections between a dual-stack agent and dual-stack server.

1. The agent requests a document with its userAgent field set to 'ATM'. 2. The server notices the
QoS specifications in the document and only sends the header of the document to the Agent. 3.
The agent puts the server's IP and ATM addresses, the QoS parameters and the identifier of the
socket used to make the request into the ARP table of IP. 4. The agent sends the same requests
but adds its ATM address to the userAgent field. When IP wants to transmit this request it finds
the IP address of the server in its ARP talbe. If the data is coming from the socket corresponding
to the socket identifier in the table entry, it establishes an ATM connection to the server, using
the QoS parameters from the table entry. The ATM connection is established to the IP access
point of the server and the VCI, VPI pair is introduced into the ARP table. Any further IP
packets for the server will be sent through this ATM connection. 5. The second request is
received by the server as if it came over the IP network. Seeing the ATM address in the request,
the server adds an entry in the ARP table with the IP and ATM addresses of the Agent, the
socket identifier of the server socket and the requested QoS parameters. 6. The server then sends
the document to the agent and IP, using the new ARP table entry, opens an ATM connection to
the agent. The document is then be delivered over pure ATM with the requested QoS.

5. Interoperability with non-ATM systems

There are no fundamental interworking problems of our dual stack approach with non-ATM
hosts. Dual stack agents or servers can use their IP stack to communicate with non-ATM users.
However, if most of the connection between two hosts is based on an ATM network and the IP
based portion is small and controllable (eg. a Customer Premises Network, CPN), then the usage
of an HTTP proxy can give the advantages of the partial ATM connection to the IP based host.

A proxy HTTP server is an intermediate host which forwards HTTP requests from agents to
servers. One use of HTTP proxies is to have a centralized point for caching of HTML pages.
Another use are firewalls where direct connections between a CPN and the Internet are avoided.
In our case an IP based agent would connect to a dual stack HTTP proxy over a fast IP network.
The proxy would then receive QoS sensitive documents over ATM and forward them to the
agent over the TCP/IP network.

The fact that proxy HTTP servers are at the application level may induce a limitation in
performance. More efficient solutions could be found by developing ATM-IP gateways at the
router level. This would require more general solutions than just Web oriented ones and is not in
the scope of this paper.

6. Conclusions
We have given a simple solution to add QoS guarantees to the delivery of Web documents
between hosts connected by ATM. The solution requires little modification of HTTP servers and
clients, they basically need to know how to use an ATM API and to recognize each other. As
TUNIC is not yet available our solution requires a simple modification to the TCP/IP code of the
server and agent hosts. Our solution allows to distribute Web documents with a guaranteed QoS.
This is important for real-time multimedia documents as well as for commercial providers
offering WYPIWYG services for ATM connected users. We have also shown how non-ATM
users will be able to benefit from partial ATM connectivity by using an ATM proxy.

• Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification

• Z. Chen, S. M. Tan and R. H. Campbell, Vosaic: Real Time Video and Audio in the
World Wide Web. Submitted to Fourth International World Wide Web Conference.
• The ATM Forum, SAA API Ad-hoc Work Group. Native ATM Services: Semantic
Description, ATM Forum contribution 95-0008R3, 1995
• See-Mong Tan, Roy H. Campbell, The x-ATM Toolkit
• Adapting HTTP to ATM Research project at University of Waterloo
• ATM for Linux, LRC, Swiss Federal Institute of Technology in Lausanne
• "ATM User Network Interface Specification Version 3.0", ATM Forum Specification,
September 1994.
 • "IP over ATM: A Framework Document", R. Cole, D. Shur, C. Villamizar, 06/27/1995.
(65284 bytes)

(1) Contact author: Philippe Oechslin ([email protected])

Differentiated services
From Wikipedia, the free encyclopedia

Jump to: navigation, search

This article is on differentiated services within communication networks. For a related
concept used as a design pattern for business applications (including smart services and
context-aware services) see Differentiated service (design pattern).

Differentiated Services or DiffServ is a computer networking architecture that specifies a

simple, scalable and coarse-grained mechanism for classifying, managing network traffic and
providing Quality of Service (QoS) guarantees on modern IP networks. DiffServ can, for
example, be used to provide low-latency, guaranteed service (GS) to critical network traffic such
as voice or video while providing simple best-effort traffic guarantees to non-critical services
such as web traffic or file transfers.

Contents
[hide]

• 1 Background
• 2 Traffic Management Mechanisms
• 3 DiffServ Domain
• 4 Classification and Marking
• 5 Per-Hop Behavior
o 5.1 Default PHB
o 5.2 Expedited Forwarding (EF) PHB - DCSP=(46 OR 101110)
o 5.3 Assured Forwarding (AF) PHB
o 5.4 Class Selector PHB
• 6 Advantages of DiffServ
• 7 Disadvantages of DiffServ
o 7.1 End-to-end and peering problems
o 7.2 DiffServ vs. More Capacity
o 7.3 Effects of dropped packets
o 7.4 DiffServ as rationing
• 8 Bandwidth Broker
• 9 DiffServ RFCs
• 10 References
• 11 See also

• 12 External links
 [edit] Background
Since modern data networks carry many different types of services, including voice, video,
streaming music, web pages and email, many of the proposed QoS mechanisms that allowed
these services to co-exist were both complex and failed to scale to meet the demands of the
public Internet. In 1998, the IETF published RFC 2475 (An Architecture for Differentiated
Services). Today, DiffServ has largely supplanted other Layer 3 QoS mechanisms (such as
IntServ) as the primary protocol routers use to provide different levels of service.

[edit] Traffic Management Mechanisms

DiffServ is a coarse-grained, class-based mechanism for traffic management. In contrast,
IntServ is a fine-grained, flow-based mechanism.

DiffServ operates on the principle of traffic classification, where each data packet is placed into
a limited number of traffic classes, rather than differentiating network traffic based on the
requirements of an individual flow. Each router on the network is configured to differentiate
traffic based on its class. Each traffic class can be managed differently, ensuring preferential
treatment for higher-priority traffic on the network.

The DiffServ model does not incorporate premade judgements of what types of traffic should be
given priority treatment; that is left up to the network operator. DiffServ simply provides a
framework to allow classification and differentiated treatment. DiffServ does recommend a
standardized set of traffic classes (discussed below) to make interoperability between different
networks and different vendors' equipment simpler.

DiffServ relies on a mechanism to classify and mark packets as belonging to a specific class.
DiffServ-aware routers implement Per-Hop Behaviors (PHBs), which define the packet
forwarding properties associated with a class of traffic. Different PHBs may be defined to offer,
for example, low-loss, low-latency forwarding properties or best-effort forwarding properties.
All the traffic flowing through a router that belongs to the same class is referred to as a Behavior
Aggregate (BA).

[edit] DiffServ Domain

A group of routers that implement common, administratively defined DiffServ policies are
referred to as a DiffServ Domain.

[edit] Classification and Marking

Network traffic entering a DiffServ domain is subjected to classification and conditioning.
Traffic may be classified by many different parameters, such as source address, destination
address or traffic type and assigned to a specific traffic class. Traffic classifiers may honor any
DiffServ markings in received packets or may elect to ignore or override those markings.
Because network operators want tight control over volumes and type of traffic in a given class, it
is very rare that the network honors markings at the ingress to the DiffServ domain. Traffic in
each class may be further conditioned by subjecting the traffic to rate limiters, traffic policers or
shapers.

[edit] Per-Hop Behavior

The Per-Hop Behavior (PHB) is indicated by encoding a 6-bit value—called the Differentiated
Services Code Point (DSCP)—into the 8-bit Differentiated Services (DS) field of the IP packet
header. The DS field is the same as the TOS field, and ECN occupies the upper 2 bits.

In theory, a network could have up to 64 (i.e. 26) different traffic classes using different
markings in the DSCP. The DiffServ RFCs recommend, but do not require, certain encodings.
This gives a network operator great flexibility in defining traffic classes. In practice, however,
most networks use the following commonly-defined Per-Hop Behaviors:

• Default PHB—which is typically best-effort traffic

• Expedited Forwarding (EF) PHB—dedicated to low-loss, low-latency traffic
• Assured Forwarding (AF) PHB— which gives assurance of delivery under conditions
• Class Selector PHBs—which are defined to maintain backward compatibility with the IP
Precedence field.

[edit] Default PHB

A default PHB is the only required behavior. Essentially, any traffic that does not meet the
requirements of any of the other defined classes is placed in the default PHB. Typically, the
default PHB has best-effort forwarding characteristics. The recommended DSCP for the default
PHB is '000000' (in binary).

[edit] Expedited Forwarding (EF) PHB - DCSP=(46 OR 101110)

The IETF defines Expedited Forwarding behavior in RFC 3246. The EF PHB has the
characteristics of low delay, low loss and low jitter. These characteristics are suitable for voice,
video and other realtime services. EF traffic is often given strict priority queuing above all other
traffic classes. Because an overload of EF traffic will cause queuing delays and affect the jitter
and delay tolerances within the class, EF traffic is often strictly controlled through admission
control, policing and other mechanisms. Typical networks will limit EF traffic to no more than
30%—and often much less—of the capacity of a link.

[edit] Assured Forwarding (AF) PHB

The IETF defines the Assured Forwarding behavior in RFC 2597. Assured forwarding allows the
operator to provide assurance of delivery as long as the traffic does not exceed some subscribed
rate. Traffic that exceeds the subscription rate faces a higher probability of being dropped if
congestion occurs.
The AF behavior group defines four separate AF classes. Within each class, packets are given a
drop precedence (high, medium or low). The combination of classes and drop precedence yields
twelve separate DSCP encodings from AF11 through AF43 (see table)

Assured Forwarding (AF) Behavior Group

Class 1 Class 2 Class 3 Class 4

Low Drop AF11 AF21 AF31 AF41

Med Drop AF12 AF22 AF32 AF42

High Drop AF13 AF23 AF33 AF43

Some measure of priority and proportional fairness is defined between traffic in different classes.
Should congestion occur between classes, the traffic in the higher class is given priority. Rather
than using strict priority queueing, more balanced queue servicing algorithms such as fair
queueing or weighted fair queuing are likely to be used. If congestion occurs within a class, the
packets with the higher drop precedence are discarded first. To prevent issues associated with tail
drop, the random early detection (RED) or weighted random early detection (WRED) algorithms
are often used to drop packets.

Usually, traffic policing is required to encode drop precedence. Typically, all traffic assigned to a
class is initially given a low drop precedence. As the traffic rate exceeds subscription thresholds,
the policer will increase the drop precedence of packets that exceed the threshold.

[edit] Class Selector PHB

Prior to DiffServ, IP networks could use the Precedence field in the Type of Service (TOS) byte
of the IP header to mark priority traffic. The TOS byte and IP precedence was not widely used.
The IETF agreed to reuse the TOS byte as the DS field for DiffServ networks. In order to
maintain backward compatibility with network devices that still use the Precedence field,
DiffServ defines the Class Selector PHB.

The Class Selector codepoints are of the form 'xxx000'. The first three bits are the IP precedence
bits. Each IP precedence value can be mapped into a DiffServ class. If a packet is received from
a non-DiffServ aware router that used IP precedence markings, the DiffServ router can still
understand the encoding as a Class Selector codepoint.
[edit] Advantages of DiffServ
One advantage of DiffServ is that all the policing and classifying is done at the boundaries
between DiffServ clouds. This means that in the core of the Internet, routers can get on with
doing the job of routing, and not care about the complexities of collecting payment or enforcing
agreements.That is, DiffServ requires no advance setup, no reservation, and no time-consuming
end-to-end negotiation for each flow, as with integrated services. This leads DS to be relatively
easy to implement.

[edit] Disadvantages of DiffServ

This section does not cite any references or sources. Please help improve this article
by adding citations to reliable sources. Unsourced material may be challenged and
removed. (February 2009)

[edit] End-to-end and peering problems

One disadvantage is that the details of how individual routers deal with the type of service field
is somewhat arbitrary, and it is difficult to predict end-to-end behaviour. This is complicated
further if a packet crosses two or more DiffServ clouds before reaching its destination.

From a commercial viewpoint, this is a major flaw, as it means that it is impossible to sell
different classes of end-to-end connectivity to end users, as one provider's Gold packet may be
another's Bronze. Internet operators could fix this, by enforcing standardised policies across
networks, but are not keen on adding new levels of complexity to their already complex peering
agreements. One of the reasons for this is set out below.

Diffserv operation only works if the boundary hosts honour the policy agreed upon. However,
this assumption is naive[citation needed] as human beings rarely agree. A host can always tag its own
traffic with a higher precedence, even though the traffic doesn't qualify to be handled with that
importance. This in fact has already been exploited: Microsoft Windows 2000 always tags its
traffic with IP precedence 5[citation needed], making the traffic classing useless. On the other hand, the
network is usually quite within its rights to traffic shape and otherwise ration the amount of
network traffic ingress with any particular precedence[citation needed], and so where this is enforced,
overall network traffic flow provided to a host could be reduced by such a tactic.

[edit] DiffServ vs. More Capacity

The neutrality of this section is disputed. Please see the discussion on the talk page.
Please do not remove this message until the dispute is resolved. (July 2009)

Some people believe that the problem addressed by DiffServ should not exist, and instead the
capacity of Internet links should be chosen large enough to prevent packet loss altogether.
The logic is as follows. Since DiffServ is simply a mechanism for deciding to deliver or route at
the expense of others in a situation where there is not enough network capacity, consider that
when DiffServ is working by dropping packets selectively, traffic on the link in question must
already be very close to saturation. Any further increase in traffic will result in Bronze services
being taken out altogether. This will happen on a regular basis if the average traffic on a link is
near the limit at which DiffServ becomes needed.

For a few years after the tech wreck of 2001, there was a glut of fibre capacity in most parts of
the telecoms market, with it being far easier and cheaper to add more capacity than to employ
elaborate DiffServ policies as a way of increasing customer satisfaction. This is what is generally
done in the core of the Internet, which is generally fast and dumb with "fat pipes" connecting its
routers.

However, this logic is flawed in many respects:

First, the problem of Bronze traffic being starved can be avoided if the network is provisioned to
provide a minimum Bronze bandwidth, by limiting the maximum amount of higher priority
traffic admitted.

Simple over-provisioning is an inefficient solution, since Internet traffic is highly bursty. If the
network is dimensioned to carry all traffic at such times, then it will cost an order of magnitude
more than a network dimensioned to carry typical traffic, with traffic management used to
prevent collapse during such peaks.

It is not even possible to dimension for "peak load". In particular, when sending a large file, the
TCP protocol continues to request more bandwidth as the loss rate decreases, and so it is simply
not possible to dimension links to avoid end-to-end loss altogether: increasing the capacity of
one link eventually causes loss to occur on a different link.

Finally, with wireless links such as EV-DO, where the air-interface bandwidth is several orders
of magnitude less than the backhaul, QoS is being used to efficiently deliver VoIP packets where
it would not otherwise be achievable.

[edit] Effects of dropped packets

Dropping packets wastes the resources that have already been expended in carrying these packets
so far through the network. In many cases, this traffic will be re-transmitted, causing further
bandwidth consumption at the congestion point and elsewhere in the network.[citation needed] To
minimize this waste, packets must be discarded as close to the edge of the network as possible,
while Diffserv is often implemented throughout a network (edge and core).[citation needed]

Thus, dropping packets amounts to betting that congestion will have resolved by the time the
packets are re-sent, or that (if the dropped packets are TCP datagrams) TCP will throttle back
transmission rates at the sources to reduce congestion in the network. The TCP congestion
avoidance algorithms are subject to a phenomenon called TCP global synchronization unless
special approaches (such as Random early detection) are taken when dropping TCP packets. In
Global Synchronization, all TCP streams tend to build up their transmission rates together, reach
the peak throughput of the network, and all crash together to a lower rate as packets are dropped,
only to repeat the process.

Delays caused by re-scheduling packets due to Diffserv can cause packets to drop by the IPsec
anti-replay mechanism.[citation needed]

[edit] DiffServ as rationing

Hence, DiffServ is for most ISPs mainly a way of rationing customer network utilisation to allow
greater overbooking of their capacity. A good example of this is the use of DiffServ tools to
suppress or control peer-to-peer traffic, because of its ability to saturate customer links
indefinitely, disrupting the ISP's business model which relies on 1%-10% link utilization for
most online customers.

[edit] Bandwidth Broker

RFC 2638 from IETF defines the entity of the Bandwidth Broker in the framework of DiffServ.
According to RFC 2638, a Bandwidth Broker is an agent that has some knowledge of an
organization's priorities and policies and allocates bandwidth with respect to those policies. In
order to achieve an end-to-end allocation of resources across separate domains, the Bandwidth
Broker managing a domain will have to communicate with its adjacent peers, which allows end-
to-end services to be constructed out of purely bilateral agreements. Bandwidth Brokers can be
configured with organizational policies, keep track of the current allocation of marked traffic,
and interpret new requests to mark traffic in light of the policies and current allocation.
Bandwidth Brokers only need to establish relationships of limited trust with their peers in
adjacent domains, unlike schemes that require the setting of flow specifications in routers
throughout an end-to-end path. In practical technical terms, the Bandwidth Broker architecture
makes it possible to keep state on an administrative domain basis, rather than at every router and
the DiffServ architecture makes it possible to confine per flow state to just the leaf routers.

[edit] DiffServ RFCs

• RFC 2474—Definition of the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers
• RFC 2475—An Architecture for Differentiated Services
• RFC 2597—Assured Forwarding PHB Group
• RFC 3140—Per Hop Behavior Identification Codes (Obsoletes RFC 2836)
• RFC 3246—An Expedited Forwarding PHB (Obsoletes RFC 2598)
• RFC 3260—New Terminology and Clarifications for Diffserv
• RFC 4594—Configuration Guidelines for DiffServ Service Classes

[edit] References
 • "Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice" by John
Evans, Clarence Filsfils (Morgan Kaufmann, 2007, ISBN 0-12-370549-5)
• "Differentiated Services for the Internet", by Kalevi Kilkki, Macmillan Technical
Publishing, Indianapolis, IN, USA, June 1999, is available in pdf-format at [1]

[edit] See also