Chapter 3 reviews the implementation issues of Differentiated Services. Various
suitable building blocks are recalled and simulation feasibility is checked. Several
contributes are added to the simulator to improve network modelling capabilities,
service model design and performance parameter collection.
In Chapter 4, three different scenarios are depicted. The first scenario is an attempt
to understand how the simulator properly models a real IP network DiffServ
enabled. The second scenario provides a test bed for algorithmic droppers targeted
for AF group and for TCP-based traffic, moreover the best WRED parameter
setting structure is evaluated. The third scenario aims to verify the flexibility of
building complete service models and to provide a wide set of performance
parameters.
6
1. TRAFFIC MANAGEMENT BEFORE DIFFSERV
To understand the current need for services differentiation and the related issues, it
is useful to retrace the evolution of the QoS model since the Internet was born. The
basic principles which inspired the design of the TCP/IP protocol suite were that
[1]:
1. Each distinct network needs to stand on its own and no
internal changes can be required to any such network to
connect it to the Internet.
2. Communications should be on a best effort basis. If a
packet did not make it to the final destination, it should
shortly be retransmitted from the source.
3. Black boxes should be used to connect the networks; these
have been later called gateways and routers. There should
be no information retained by the gateways about the
individual flows of packets passing through them, thereby
keeping them simple and avoiding complicated adaptation
and recovery from various failure modes.
4. There should be no global control at the operations level
These fundamental design principles and the idea of an open-architecture
networking determined the success of the current Internet.
Since 1972, when the first email was sent, an increasing number of services has
moved to IP networks. This has determined not only a traffic increment, but mostly
a fragmentation of the network services needed to support these new applications.
The Best Effort Service, subject to unpredictable delays and data loss, does not fulfil
these needs anymore. A new model capable of delivering differentiated QoS
requirements is needed.
7
A possible definition of ideal QoS provision is the activity to give guarantee that every flow
is protected from all external effects in a way that the quality always satisfies the predefined
requirements [2]. The DiffServ model represents an important step toward this goal.
1.1 A broad view network model
The End-to-End QoS provision challenge involves the whole Internet in different
ways. For instance, a required service from the end-user to the service provider
generates a set of requirements inside the network. The worthy analysis presented in
[2] helps us to better understand what the customer requirements set off.
In this analysis, the author considers the technological QoS provisioning issues in a
wider Business Model. Now follows a brief presentation:
The basic entities of this model are:
• Service Provider: refers to both activities of customer relations and
operation & management of the network.
• End-User: refers to any person who is using the Internet for any purpose;
since a person has a variety of emotions that influence the use of the
service, it is important to consider choices not only based on technical
facts.
• Mechanism: refers to any piece of equipment or software that allows
different politics of packet treatment.
• Network: refers to the basic entity managed by the service provider and
used to transmit information from one end-user to another.
• Application: refers to both user applications and protocols that are not
directly controllable by the service provider.
• Vendors: refers to companies that supply network components to service
providers and end-users.
8
Figure 1.1 A broad view network model
It is worthy to analyse also the basic relationships among these entities. As displayed
in Figure 1.1, customer service is used to describe the relationship between end user
and service provider. Starting from the Service-Level Agreement (SLA) as the
formal part that describes the type of service to be provided, this relationship passes
through non technical aspects to finally reach customer satisfaction.
Network service is used to describe the relationship between applications and network
characterized by parameters that enable the network to provide the applications of
the needed resources. Then traffic handling is used to describe the relationship
between network and mechanisms and represents all the elaborations a packet
receives. With appropriate mechanisms (e.g. classification, marking, metering,
shaping, dropping) it is possible to utilize the same network resources to better fulfil
the low level services. Finally, network operation & management is the relationship
between network, mechanism and service provision. It covers issues, such as
building reasonable services based on available mechanisms, making traffic
measurements for network-planning purposes and solving fault situations.
9
1.2 The Internet Service Provision before DiffServ
A brief description of the previous service models and a comparison among them
will lead us to the foundations of the emerging DiffServ Model. The basic design
principles and the implementation issues will be focused. The purpose is to
understand the historical reasons for this new service model.
1.2.1 The Best Effort Model
The basic QoS model of the Internet is called Best Effort because the network tries
to transmit as many packets as possible and as soon as possible, but does not give
any guarantees. That means that the packets are subject to data loss, data duplication
or out-of-order delivery. The TCP protocol solves these problems by assigning a
sequence number to all data transmitted in the network and requiring a positive
acknowledgment from the receiver.
Another key function of the TCP protocol is that no traffic-control action is taken
until congestion is observed (the opposite approach is congestion avoidance).
Receivers bind packet loss to congested network and control senders by returning a
window size indicating a range of acceptable sequence numbers.
A further limitation of the Best Effort Model is that packets are delivered with
unpredictable delays. This means that it cannot properly support real-time
applications, except in case of low load levels and almost empty buffers. Even under
these conditions, it is not possible to provide loss-free service or different levels of
loss ratios because of the intrinsic traffic-control mechanism. This lack of versatility
raised the need for a new QoS model.
10
1.2.2 Integrated Service Model
The need for a new Internet service model able to support Integrated Services
(transport of audio, video, real-time, and classical data traffic within a single network
infrastructure) led to the birth of the IntServ WG at the end of 1993. The WG
focused on the definition of a minimal set of global requirements to change the
Internet into a robust integrated-service communications infrastructure.
The basic issues were:
• defining the services to be provided
• defining the interfaces between applications and network services, routers
and subnetworks
• developing router validation requirements which can ensure that the proper
service is provided
The desired QoS is provided by resource reservation along the path, therefore
signalling and state maintaining at each hop is needed. The resource ReSerVation
Protocol used for signalling is RSVP [4]. Its major features include the use of “soft
state” in the routers, receiver-controlled reservation requests and the use of IP
multicast for data distribution.
The signalling and reservation of the desired QoS are needed for each flow in the
network. A flow is defined as an individual, unidirectional data stream between two
applications, and is uniquely identified by the 5-tuple (Source IP address, Source
Port, Destination IP Address, Destination Port and the Transport Protocol).
Two types of services have been implemented:
1. Guaranteed Service [5]: traffic parameters (TSpec) using a token bucket and
service-level parameters (RSpec) describe this strict Guaranteed Service that
provides for firm bounds on end-to-end delay and assured bandwidth for
traffic that conforms to the reserved specifications
11
2. Controlled Load Service [6]: traffic parameters (TSpec) using a token bucket
describe this service for those applications that work well on unloaded nets,
but which degrade quickly under overloaded conditions. The separation
between pure Best Effort flows and Controlled Load flows is achieved by
priorization
The drawbacks of this model are:
1. the reservations in each device along the path are “soft”, which means that
they need to be refreshed periodically; if refresh packets are lost there is a
risk of reservation time out
2. the need for signalling and maintaining the state of each flow in each router
is a strong limitation to scalability
An effort to solve these problems can be found in [7], an RFC document from the
RSVP Working Group. Further efforts [8] are currently made inside the MPLS WG,
where the ReSerVation Protocol has been involved to support signalling for the
raising MPLS Model.
1.2.3 IP over ATM
ATM is the telecommunications transport technique selected for the efficient
transfer of information across the network in the Broadband Integrated-Services
Digital Network Model (B-ISDN). Efficient means that ATM should be able to
fulfill the quality of service requirements of all supported connections over a
network with a limited amount of resources. The B-ISDN model is an attempt to
set up a single unified, worldwide high-speed network. It is conceived to support all
types of existing and new emerging applications (data, voice, video and multimedia
traffic in general).
12
The basic key concepts of ATM technology are:
• Connection-oriented
• Bandwidth reservation as a congestion avoidance mechanism
• Fixed-size packets called cells to enable high performances
• Wide service categories definition
Despite the wide standardization effort within the International
Telecommunications Union and ATM Forum (since 1991), the B-ISDN Model has
not widely succeeded. In fact, there are only a few real demonstrations of customer
service based on end-to-end ATM connections.
The main historical reasons are:
• the initial lack of cost-effective interfaces for copper
• the initial lack of compatibility among network devices even if coming from
the same vendors
• the fact that customer equipment is usually connected to a LAN and the
impossibility of mapping application QoS requirements on the Ethernet
level; (the IEEE 802.1D solved this problem, but now all efforts are
concentrated on IP networks; therefore efforts are concentrated on mapping
IP QoS requirements over IEEE 802.1D [9])
Conversely, ATM is widely used in the Internet backbone mainly as a primary
intermediate layer between optical transmission and IP packet forwarding. Thus,
nowadays it is regarded as one of the several technologies of the network layer for
the Internet Architecture to deliver IP packets.
13
1.3 Comparison among these models
An interesting comparison comes from [2]. The author defines four attributes used
to compare the service models:
1. Fairness. This is the key attribute of the relationship between the end-user
and the service provider. Essentially, it is related to whether customers feel
the market is fair, i.e. customers want to be sure that everyone pays the same
price for the same product
2. Versatility. How the model is able to satisfy the different needs of customers
3. Robustness. This is related to the way the network is capable of managing
the undesirable behavior of some end-users
4. Cost Efficiency. It is related to the ability of the model to meet the previous
attributes at the lowest price
In the following table, the core part of the analysis is summarized. Refer to [2] for a
complete description.
Table 1.1 QoS schemes - comparison at a glance
Model Fairness Versatility Robustness Cost Efficiency
Best Effort
Poor due to lack of
robustness
Impossible to
manage delays
and packet-loss
ratios
Weak because
TCP-based traffic
management runs
in customers
equipment
Good for adaptive
applications;
Poor for real-time
applications
IntServ
It is difficult to build an
understanding and
consistent customer
service
Good
Good
Limited on
scalability
IP over ATM
Seems to be difficult to
build fair services from
the end-user point of
view
Very good
Very good;
needs attention in
managing statistical
multiplexing
Difficult in
managing the
network due to the
complex QoS model
14
2. THE DIFFSERV MODEL
The B-ISDN brought about the idea of services differentiation. For the reasons
explained above, IP networks were more successful than ATM networks. Inside the
INTSERV WG, an attempt to provide services differentiation was made. The
limitation of this model (scalability, flexibility in building customer services) raised
the need for a new, and in a way, complementary model.
This is evident from the first paragraph of the first official document related to
DiffServ Model [10]:
“Differentiated services enhancements to the Internet protocol are intended to enable scalable
service discrimination in the Internet without the need for per-flow state and signalling at every
hop. A variety o services may be built from a small, well-defined set of building blocks
which are deployed in network nodes.”
f
Hence, scalability and flexibility on building customer service are the main targets of
this QoS model. The next paragraphs focus on the design principles, the DiffServ
architecture, the building blocks of DiffServ network and a conceptual model for a
DiffServ router.
2.1 Design principles
The IESG approved the DiffServ Working Group [3] on 26 February 1998 and
since that date, lots of efforts have been made to built a framework for
Differentiated Services. The most recent overview of this framework can be found
in [11]:
15
“The differentiated services framework enables quality-of-service provisioning within a network
domain by applying rules at the edges to create traffic aggregates and coupling each of these with a
specific forwarding path treatment in the domain through use of a codepoint in the IP header”
The framework tries to accomplish a list of requirements presented in [12] and
summarized as follows [2]:
• Versatility: a wide variety of end-to-end services should be possible to realize;
network services should be independent of applications, and they should be
directly applicable with current applications and with current network
services
• Simplicity: the overall system or parts of it should not depend on signalling for
individual flows; only a small set of forwarding behaviours should be
necessary
• Cost efficiency: information about individual flows or customers should not be
used in core nodes. Only states of aggregate streams should be used in core
nodes
A basic design choice was to decouple the fairly well-understood behaviour in the
forwarding path from the more complex and still emerging background policy and
allocation component that configures parameters used in the forwarding path. This
aims to speed the deployment of the model in the network. Moreover, it enhances
the flexibility in building new services because once the network interior is stable, it
is possible to provide new services by the available set of forwarding behaviours and
applying traffic conditioning policies at the edge.
Another design choice was to base the architecture on forwarding behaviours and
therefore to decouple it from the control plane. This principle deals with the original
design of the Internet where the decision was made to separate the forwarding and
routing components. Even if it can lead to a non-complete network utilization (i.e. if
multiple parallel or alternate paths are available, it is not possible to balance the
16
traffic load on the various links, routers and switches in the network), it provides the
simplicity required to speed the deployment of the architecture. A solution to this
drawback is currently discussed inside the MPLS WG and is named Diff-Serv-aware
MPLS Traffic Engineering [13].
It is important to remark that the DiffServ architecture provides asymmetric service
differentiation since it is related to only one direction of traffic flow [12].
2.2 Differentiated Services framework
The atomic entity defined by the framework to provide service differentiation is the
DiffServ domain, a contiguous portion of the Internet over which a consistent set of differentiated
services policies are administered in a coordinated fashion [10] (issues related to inter-domain
QoS provisioning are currently discussed in the DiffServ WG). The next figure
shows a possible scenario:
Figure 2.1 DiffServ Domain
Packets arriving at the boundary of a DS domain experience classification and traffic
conditioning. The purpose is to impose restrictions on the composition of the
resultant aggregates. Each packet is marked with a codepoint, and each codepoint
identifies a particular aggregate. Aggregates receive differentiated treatment inside
17
the DS domain. In particular, the externally observable forwarding treatment an
aggregate stream receives in an interior node is called per-hop behaviour or PHB
(multiple codepoints can map to the same PHB). In more concrete terms, PHB
refers to the packet scheduling, queueing, policing or shaping behaviour of an
interior node and it is a basic block to build services. The other ones are traffic
conditioners and they are typically deployed in DS boundary nodes.
Generalization of the concepts of aggregate (or behaviour aggregate) and per-hop
behaviour have been introduced in [11] to meet inter-domain issues. The first one is
traffic aggregate and refers to packets which are mapped to the same PHB everywhere
within a DS domain. The second one is per-domain behaviour or PDB and describes
the edge-to-edge behaviour across a DS domain experienced from a traffic
aggregate. This level of abstraction makes it easier to compose cross-domain
services as well as making it possible to hide the details of a network’s internals
while exposing information sufficient to enable QoS.
A particular PHB (or list of PHB’s) and traffic conditioning requirements are
associated with each PDB. This requires understanding what happens to a PHB
under aggregation. Different streams of traffic that belong to the same traffic
aggregate merge and split as they traverse the network. The PDB should describe
the invariant behaviour of these network activities.
2.2.1 Differentiated Services field definition
When a packet enters a DS domain, it experiences classification and traffic
conditioning actions and it is assigned a value called Differentiated Services
CodePoint (DSCP). Each DS node must use the DSCP to select the PHB which is
to be experienced by each packet it forwards.
18
The Differentiated Services Field is made of the six most significant bits of the
former IPv4 ToS octet or the former IPv6 Traffic Class octet [14] and it encodes
the DSCP.
Figure 2.2 IPv4 and IPv6 headers
The two least significant bits of the IPv4 TOS octet and of the IPv6 Traffic Class
octet are not presently used by DiffServ. An experimental use for an explicit
congestion notification scheme is described in [15]. DS-compliant nodes must select
PHB’s by matching against the entire 6-bit DS field.
2.2.1.1 Backwards compatibility issues for the IPv4 ToS field
The structure of the DS field described above is incompatible with the previous
definition of the IPv4 ToS octet. In the first definition [16], two ToS sub-fields were
meaningful, the 3-bit Precedence field and the 3-bit DTR (Data, Throughput and
Reliability). The former was intended to allow different levels of importance for a
datagram, while the latter was defined for a primitive services differentiation. In the
[17] and then [18], the DTR field became a 4-bit field called TOS.
Figure 2.3 The original IPv4 ToS octet
19
Ricevi informazioni sui nostri servizi, sulle offerte e non perdere news e consigli su università e lavoro.
