pw gharbaoui imcne07

8/14/2019 Pw Gharbaoui IMCNE07

1/41

Master degree report

Study and implementation of QoS techniques in

IP/MPLS networks

Molka GHARBAOUI

In partial fulfilment of the requirements for the Degree of

International Master on Communication Networks Engineering

Tutors

Barbara MARTINI

Isabella CERUTTI

Anna Lina Ruscelli

Gabriele Cecchetti


2/41

Abstract

IMCNE thesis i

Abstract

In multi-service IP networks, it is a key challenge to provide Quality of Service (QoS) to end-userapplications while effectively using network resources. As nowadays the interest is related to

guarantee QoS for the multi-media services i.e. voice and video traffic which have specific

requirements to be efficiently handled, networks based on only best-effort traffic become

insufficient.

This work presents a study of Quality of Service techniques in IP/MPLS networks on a per-

application basis. The study shows the relevance of an architecture where DiffServ, MPLS and

Traffic Engineering would cooperate to overcome the challenges for QoS-capable IP networks. Infact, the DiffServ architecture has emerged as a solution to guarantee quality of service. In addition

to that, the use of the MultiProtocol Label Switching (MPLS) and Traffic Engineering (TE) givesthe ability on the one hand to efficiently use the network resources and on the other hand to classify

and prioritize traffic.

The study is then followed by a theoretical and experimental activity. The theoretical part includes

an analysis of voice traffic characteristics as the need for Quality of Service techniques is

particularly emphasized while handling multimedia traffic. It is followed by an experimental

activity to demonstrate the results obtained theoretically. For that, a configuration of the studied

techniques is applied to a testbed where voice traffic is injected into the network in addition to best-

effort traffic. The differentiated treatment on a per-application basis is obtained by setting MPLSDiffServ-aware Traffic Engineering capabilities.

Keywords: QoS, MPLS, TE, DiffServ.


3/41

Acknowledgement

IMCNE thesis ii

Acknowledgement

This thesis presents the work done to obtain the degree of International Master on Communications

Networks Engineering (IMCNE). It was realized in the Centre of Excellence for Information andCommunication Engineering (CEIIC) with the goal of studying and implementing Quality of

Service techniques in IP/MPLS networks.

I thank my tutors Mrs Barbara MARTINI, Ms Isabella CERUTTI, Ms Anna Lina Ruscelli and Mr

Gabriele Cecchetti for their availability, precious help and advice.

I thank Valerio MARTINI, the PhD student at the Scuola Superiore SantAnna for his support.

I thank also Claudio Manfroni, tutor of the IMCNE master, for all the help that he presented to me

during all the master duration.


4/41

List of Tables and Figures

IMCNE thesis iii

List of Tables and Figures

Figures

Figure 1.MPLS Label Switching ................................................................................................... 04Figure 2. Basic Resource Reservation Setup Operations of RSVP signalling protocol ................... 08

Figure 3. Redefinition of the ToS field in the IP header................................................................. 09

Figure 4. Per-Class Queuing Node (Edge)..................................................................................... 11

Figure 5. Mapping DSCP to EXP.................................................................................................. 11

Figure 6. DiffServ-Aware MPLS Traffic Engineering (DS-TE)................................ ..................... 12

Figure 7. MAM Constraint Model Example .................................................................................. 14

Figure 8. RDM Constraint Model Example ................................................................................... 15Figure 9. Classifying and Marking ................................................................................................ 17

Figure 10. Policing and Shaping.................................................................................................... 17

Figure 11. Scheduling and Queuing............................................................................................... 18Figure 12. A standard voice packet................................................................................................ 21

Figure 13. The testbed................................................................................................................... 23

Figure14. IP packet configuration ................................................................................................. 24

Figure 15. RTP packet configuration............................................................................................. 25

Figure 16. Traffic capture.............................................................................................................. 26

Figure 17. Packets listing .............................................................................................................. 26

Figure 18. CoS components .......................................................................................................... 27

Figure 19. Access to the router...................................................................................................... 28

Figure 20. Interfaces configuration................................................................................................ 28

Figure 21. Routing protocols configuration ................................................................................... 29Figure 22. Forwarding Classes configuration ................................................................................ 30

Figure 23. Configuration of LSPs.................................................................................................. 31

Figure 24. Configuration of the multi-field classifier ..................................................................... 31

Figure 25. Configuration of a BA classifier ................................................................................... 32

Figure 26. Schedulers configuration.............................................................................................. 33

Figure 27. Marking outgoing packets ............................................................................................ 34

Tables

Table 1. Packetization delay.......................................................................................................... 21

Table 2. LSPs characteristics......................................................................................................... 27


5/41

Contents

IMCNE thesis iv

ContentsIntroduction .................................................................................................................................. 01

Chapter 1: Background.................................................................................................................. 03

I. Network architecture.................................................................................................................. 03

II. MPLS network ......................................................................................................................... 03

II.1. MPLS Terminology ............................................................................................................... 03II.2. MPLS-TE.............................................................................................................................. 04

III. Need for Quality of Service ..................................................................................................... 04

Chapter2: QoS in MPLS networks ................................................................................................ 06

I. Quality of Service ...................................................................................................................... 06

I.1. Why QoS? .............................................................................................................................. 06

I.2. QoS parameters....................................................................................................................... 07

II. QoS in IP networks................................................................................................................... 08

II.1. IntServ with RSVP ................................................................................................................ 08II.2. DiffServ................................................................................................................................. 09

III. QoS in MPLS networks........................................................................................................... 10III.1. MPLS Support of DiffServ ................................................................................................... 10

III.2. Mapping DSCP to the EXP field .......................................................................................... 11

III.3. DiffServ-Aware MPLS Traffic Engineering ......................................................................... 12III.3.1. Definition.......................................................................................................................... 12

III.3.2. Bandwidth Constraint Models ........................................................................................... 13

III.3.3. Deploying the DiffServ-TE solution .................................................................................. 16

IV. QoS operations........................................................................................................................ 16

Chapter 3: Experimental activity ................................................................................................... 20

I. Characterization of QoS for voice traffic.................................................................................... 20I.1. Voice traffic characteristics ..................................................................................................... 20

I.2. QoS requirement for voice traffic ............................................................................................ 22

II. Experimental setup ................................................................................................................... 23II.1. Testbed schema ..................................................................................................................... 23

II.2. Software ................................................................................................................................ 23

II.3 Tests....................................................................................................................................... 24

II.4 Router configuration............................................................................................................... 27

Conclusion.................................................................................................................................... 34

References .................................................................................................................................... 35

Glossary........................................................................................................................................ 36


6/41

Introduction

IMCNE thesis

Introduction

The recent evolution of the telecommunications has witnessed the birth and the developmentof many technologies and protocols, to best offer a variety of services in geographically distinct

areas.

Moreover, networks delivering multimedia contents such as video and voice are facing the problem

of how to guarantee the quality of service (QoS) requested by the user in the contract stipulated

with the service provider. QoS must be in conformity with applications requirements which do not

answer any more the criteria of the services carried out by the best effort and then allow having the

appropriate and available resources in order to support these kinds of specific services.

Consequently, the need for a QoS control on a per-application basis was noticed.

IP/MPLS networks are a QoS-enabled technology capable to provide mechanisms for traffic

engineering and bandwidth guarantees. In fact, MPLS provides a connection-oriented environmentwhich, combined with technologies that provide traffic flows with application-specific treatment

can lead to guarantee end-to-end quality of service. In recent years, two kinds of frameworks have

emerged from the IETF standards processes which are IntServ and DiffServ services.

Inserv is a per-flow basis architecture that specifies the elements to guarantee QoS on networks by

making individual reservations on every network element. On the contrary the Diffserv architecture

is a class-based mechanism that operates on the principle of placing each packet into a limited

number of traffic classes.

For various reasons, IntServ never scaled to the level it needed to get to for Internet-size networksand we turned towards DiffServ which, associated to MPLS and Traffic Engineering (TE) came up

with the concept of DiffServ-aware Traffic Engineering (DS-TE) . MPLS inherently does not

support QoS mechanisms but thanks to the connection-oriented approach, the class differentiation

and the resource optimization capabilities given by TE methods, DS-TE allowed network operators

to provide services that require strict QoS performance guarantees.

The primary goal of this project is to study the QoS techniques in IP/MPLS networks for a

differentiated treatment on per-application basis. As a second step, some router configurations doneover an MPLS testbed will be used to evaluate the Quality of Service of voice traffic.

This work is realized in the Centre of Excellence for Information and Communication Engineering

(CEIIC). The centre was established in 2001, thanks to the joint effort that Sant'Anna School for

Advanced Studies decided to undertake in the telecommunications sector in collaboration with

Marconi Communications SpA (now Ericsson). ). These two parties, in partnership with CNIT

(National Inter-University Consortium for Telecommunications) are aiming to address a major

demand for integrating education, basic and applied research in the area of optical networks and

technologies.


7/41

Introduction

IMCNE thesis 2

This report is organized as follows: the first chapter named Background presents a theoretical

overview of the concepts that are tightly related to the developed work. The second chapter named

QoS in MPLS networks is mainly devoted to the deployment of quality of service mechanisms inMPLS networks. The third chapter named Experimental activity and results is dedicated to the

practical aspect of the project which includes a presentation of voice traffic characteristics and

requirements for QoS, routers configuration, tests and obtained results. Finally some conclusionsare drawn.


8/41

Chapter 1: Background

IMCNE thesis 3


This chapter presents the terminology and basic concepts related to the developed work. In

fact, it defines the network architecture, MPLS networks, Quality of Service, and the Traffic

Engineering.

I. Network architecture

Telecommunication networks consist of two principal components transport or core network and

access network. An access network is the part which connects subscribers to their immediate

service provider. In many networks, it is still largely predominated by the copper cable based point-

to-point connections, resulting in a large proportion of passive, inflexible and relatively unreliable

networks that are tailored to traditional services such as the voice, leased lines, and low rate data

transmission. On the other hand, the core network is the central part of the telecom network that

provides various services to customers who are connected by the access network.

As circuit switched networks are getting replaced by packet-switched networks, many service

providers are turning to IP/MPLS technology as a common core for existing and next-generationservices and this is due to its future flexibility, network scalability, and a reduction in the cost of

new service deployment.

II. MPLS network

II.1. MPLS Terminology

MPLS stands for "Multi-Protocol Label Switching". It is a switching technology based on

forwarding the packets according to a short, fixed length identifier termed as a label, instead of

the network-layer address with variable length match. As showed in Figure 1, the labels are

assigned to the packets at the ingress node of an MPLS domain. Inside the MPLS domain, the labels

attached to packets are used to make forwarding decisions. The labels are finally popped out fromthe packets when they leave the MPLS domain at the egress nodes. Routers which support MPLS

are known as "Label Switched Routers", or "LSRs" [1].


9/41


IMCNE thesis 4

Figure 1.MPLS Label Switching

II.2. MPLS-TE

In traditional networks, Traffic Engineering is used to achieve performance objectives such asoptimization of network resources and placement of traffic on particular links. The explicit routing

capabilities of MPLS allow the originator of the LSP to do the path computation, establish the

MPLS forwarding state along the path, and map packets onto that LSP. Once a packet is mapped

onto an LSP, forwarding is done based on the label, and none of the intermediate hops makes any

independent forwarding decisions based on the IP destination address of the packet [4].

MPLS can provide additional benefits for the support of real-time communications. The use of

DiffServ alone does not guarantee adequate bandwidth resources for a specific application. If voice

traffic follows a network path with insufficient resources to meet the performance criteria for jitter

and latency, for example, voice quality will not be adequate. In principle, this problem could be

solved by over-provisioning resources to avoid congestion altogether.

III. Need for Quality of Service

The internet and IP protocol were designed to provide best-effort traffic where all packets are

treated equally. But as applications load is getting higher and network traffic is becoming highly

diverse, just increasing the amount of resources such as available bandwidth to avoid congestion

does not provide proper resource utilization and is not sufficient to meet applications requirements.

To handle this, the use of QoS mechanisms ensures that packets will receive appropriate treatment

as they travel through the network. This helps applications and end users to be in line with theirexpectations and with the commitments contracted by the customer with the network operator.


10/41


IMCNE thesis 5

Indeed, the use of MPLS and MPLS-TE alone is not enough anymore to guarantee the quality of

service in the network. For this reason, those mechanisms which can ensure a differentiated packettreatment according to applications requirements became necessary.


11/41

Chapter 2: QoS in MPLS networks

IMCNE thesis 6

Chapter2: QoS in MPLS networks

The previous chapter presented the concepts that are related to the present work. This

chapter exposes the Quality of Service solutions offered to handle voice traffic. It defines voice

traffic characteristics, QoS requirements and provides a general overview of the needed QoS

operations.

I. Quality of Service

I.1. Why QoS?

Todays networks are a mix of different types of traffic, each with very different requirements.

Applications are expecting that their traffic can be properly supported in the IP network regardless

to their specificities. This need for Quality of Service is especially important in presence of network

congestion where the necessity for an adequate bandwidth to meet the demands of the offered loadcomes from the fact that excess packets in the network cause their delay and loss.

Some solutions were proposed to handle this congestion:

Over-provisioningConsist in adding more bandwidth and over-provision the network to ensure that the need forbandwidth can be satisfied at all times. It looks like an ideal solution but can lead to wastage of

valuable resources.

Separate networksSet up a separate network for each application type (voice, video and data for example) to avoid

sharing resources between traffic types. Like over-provisioning this leads to a poor utilization of

resources and does not solve the problem for example of having more voice traffic than there is

bandwidth for voice network.

Class differentiationThe class differentiation enables network nodes to differentiate among several classes of incomingtraffic and satisfy their own requirements. This permits to recognize the traffic belonging to certain

users and applications such that preferential services may be provided to them. QoS parameters canallow to define the various classes.


12/41


IMCNE thesis 7

I.2. QoS parameters

The service needs of different applications can be represented as a set of parameters, including

bandwidth, delay, jitter, and packet loss [2].

I.2.1. Bandwidth

The first thing needed to guarantee Quality of Service is having an adequate bandwidth. Since it isan expensive resource, its amount should be given after a good understanding of the network

capabilities and requirements.

I.2.2. End-to-end delay

It is the delay needed by a packet to cross the infrastructure from source to destination. Its influence

depends on the type of the traffic carried by the packets. For example, concerning voice which is a

real-time traffic; if there is a too long delay in voice packet delivery, speech will be unrecognizable.This delay comprises four components:

The sampling delay: concerns analogical traffic and consists in the duration of

digitalization at the emission and of conversion at the reception.

The propagation delay: duration of transmission of the digitized data. It is about a few

milliseconds.

The transmission delay: duration spent across the routers, the switches and other

components of the network. The order of magnitude is from several tens of milliseconds to

hundreds of milliseconds.

The jitter's buffers delay: delay introduced at the reception in order to reduce the jitter. The

order of magnitude is of 50 ms.

I.2.3. Jitter

Jitter is the variation of delay between the moment when two packets should have arrived and the

moment of their effective arrival. It is due to the fact that the packets do experience different delaysat the node buffers. It is independent from the transmission delay and is a consequence of

momentary congestions on the network which cannot transport any more the data in a constant wayin time. The value of the jitter goes from a few ms to a few tens of ms.

I.2.4. Packet loss

Packet loss occurs when one or more packets of data travelling across a computer network fail to

reach their destination. It is distinguished as one of the main error types encountered in digital

communications. It can be caused by a number of factors, including signal degradation over the

network medium, oversaturated network links, corrupted packets rejected in-transit, faultynetworking hardware, maligned system drivers or network applications, or normal routing routines.


13/41


IMCNE thesis 8

Lost or dropped packets can result in highly noticeable performance and can affect all network

applications to a certain degree.

II. QoS in IP networks

II.1. IntServ with RSVP

The fundamental idea of Integrated Services (IntServ) architecture is to reserve resources such as

bandwidth and buffers. IntServ develops architecture for resource allocation to meet the

requirements of real-time applications which have a deadline for data to arrive by, after which the

data become less useful. As shown in Figure 2, to receive performance assurance from the network,an application must set up the resources reservation along its path before it can start to transmit

packets by sending and receiving PATH and RESV messages. This is based on the use of the

ReSource reserVation Protocol (RSVP) which is a signalling protocol for applications to reserve

resources [6]. IntServ provides two service classes in addition to best-effort service, that are the

Guaranteed Servicewhich is defined to provide an assured level of bandwidth, a firm end-to-end

delay bound and no queuing loss and is intended for real-time applications such as voice and video;

and a Controlled Load Service, for applications requiring a reliable and enhanced best-effort service

and that could tolerate a limited amount of loss and delay[3].

Figure 2. Basic Resource Reservation Setup Operations of RSVP signalling protocol

The IntServ architecture has satisfied both necessary conditions for the network QoS; however, its

problems are as follows:

The amount of state information increases proportionally with the number of flows whichneeds a huge storage and processing load on the routers.

All routers must have RSVP, admission control, packet classification and packet scheduling.Therefore, the IntServ model was implemented only in a limited number of networks, and naturally

the IETF moved to develop DiffServ as an alternative QoS approach with minimal complexity.


14/41


IMCNE thesis 9

II.2. DiffServDiffServ determines the QoS behaviour of a packet at a particular node in the network. This is

called the per-hop behaviour (PHB) and is expressed in terms of the Forwarding Class that a packet

experiences. The PHB translates to the packet queue used for forwarding, the resources (buffers and

bandwidth) allocated to each queue, the frequency at which a queue is serviced, as well as the dropprobability in case the queue exceeds a certain limit [2].

The four general per-hop behaviour categories are:

Best effort (BE) traffic: receives no special treatment. Expedited forwarding (EF) traffic: encounters minimal delay, low loss, low jitter, and

assured bandwidth end to end. From a practical point of view, this means a queue dedicated

to EF traffic for which the arrival rate of packets is less than the service rate, so delay,

jittand loss due to congestion is unlikely. Voice and video streams can be mapped to EF:

they have constant rates and require minimal delay and loss.

Assured forwarding (AF) traffic: offers finer Class of Service (CoS) granularity. A queuenumber and a drop profile can define each PHB. The AF PHBs are applicable for traffic that

requires rate assurance but not bounds on delay or jitter.

Network control (NC) traffic: carries routing protocol exchanges. These packets cannottolerate loss, but can accept delay.

DiffServ provides differential forwarding treatment to the traffic, thus enforcing QoS for different

traffic flows. It is a scalable solution that does not require per-flow signalling or maintenance of the

state parameters in the core. However, it cannot guarantee QoS if the path followed by the traffic

does not have adequate resources to meet the QoS requirements.

The DiffServ model is based on redefining the meaning of the 8-bit ToS field in the IP header. The

Figure 3 shows the redefinition of the original ToS which is split into the 6-bit DiffServ Code Point(DSCP) value and the 2-bit Explicit Congestion Notification (ECN) part.

Figure 3. Redefinition of the ToS field in the IP header


15/41


16/41


17/41


IMCNE thesis 12

problem to map the DSCP in IP packet header. The mapping is straightforward: a particular DSCP

is equivalent to a particular EXP combination and maps to a particular PHB (scheduling and droppriority).

L-LSP (Label-only-inferred LSPs): It is to use the label field itself as the information carrier about

different PHBs. L-LSPs can carry packets from a single PHB, or from several PHBs that have the

same scheduling regimen but differ in their drop priorities. The packets belonging to a common

PHB scheduling class must travel on the same LSP.

III.3. DiffServ-Aware MPLS Traffic Engineering

III.3.1. Definition

MPLS-TE (Traffic Engineering based on MPLS) and DiffServ (Differentiated Services) can be

deployed concurrently. Thus, DiffServ provide packets with a preferential treatment using differentcode-points in their header to enable performing routing with class-based constraint and MPLS

networks are configured to offer different QoSs to different paths through the network. This

combination of MPLS and DiffServ is called DS-TE (DiffServ aware MPLS Traffic Engineering)

[1].

DS-TE mechanisms must decide how to distribute the resources differently to each class. The link

capacity can be divided to be used by each traffic class with appropriate rate which can be achieved

by Bandwidth Constraint models (BC models).

Figure 6. DiffServ-Aware MPLS Traffic Engineering (DS-TE)

The Figure 6 shows an example of DS-TE mechanism based on MPLS LSPs. When a traffic

demand arrives at an ingress router, it is classified and marked according to its DSCP (DiffServCode Point) in the packet header. Thus, the ingress calls an appropriate routing algorithm to find the


18/41


IMCNE thesis 13

best path for the current demand. For example, it gives the shortest path for an LSP request which

requires low-delay, and the longer and big-capacity path for best effort traffic. By using differentpaths according to traffic class, DS-TE can give different Quality of Service to the users and it can

use efficiently its network resources.

The basic DiffServ Aware TE requirement is to be able to make separate bandwidth reservations for

different classes of traffic and give different forwarding behaviour based on the class. This implies

keeping track of how much bandwidth is available for each type of traffic at any given time on all

routers throughout the network.

III.3.2. Bandwidth Constraint Models

Bandwidth Constraint (BC) models describe how to allocate the bandwidth to the individual Class

Types (CTs). The concept of a Class Type was introduced as the set of traffic trunks crossing a link,which is governed by a specific set of bandwidth constraints. CT is used for the purposes of link

bandwidth allocation; constraint based routing, and admission control. The IETF requires support ofup to eight CTs referred to as CT0 through CT7 [1].

In the context of DS-TE, there are mandatory requirements for any practical BC model. The first is

concerning bandwidth utilization: the bandwidth needs to be efficiently shared by multiple CTs

under the normal as well as the overload conditions. The second is associated with bandwidth

isolation: a CT cannot hog the bandwidth of other CTs under the overload condition.

In fact, the set of bandwidth constraints (BC) defines the rules that a node uses to allocatebandwidth to different CTs. Each link in the DS-TE network has a set of BCs that applies to the

CTs in use. This set may contain up to eight BCs. When a node using DS-TE admits a new TE LSP

on a link, that node uses the BC rules to update the amount of unreserved bandwidth for each TE-Class.

Next, three proposed model for the support of BC are presented.

III.3.2.1. The Maximum Allocation Model (MAM)

The MAM defines a one-to-one relationship between BCs and Class-Types. It offers limited

bandwidth sharing between CTs. A CT cannot make use of the bandwidth left unused by another

CT. From a practical point of view, the link bandwidth is simply divided among the different CTs

[1].

The Figure 7 shows an example of a set of BCs using MAM. This DS-TE configuration uses three

CTs with their corresponding BCs. In this case, BC0 limits CT0 bandwidth to 15 percent of the

maximum reservable bandwidth. BC1 limits CT1 to 50 percent, and BC2 limits CT2 to 10 percent.

The sum of BCs on this link is less than its maximum reservable bandwidth. Each CT will always

receive its bandwidth share without the need for preemption.


19/41


IMCNE thesis 14

Figure 7. MAM Constraint Model Example

The MAM has a number of advantages:

It guarantees the bandwidth isolation across multiple CTs, thus, no priorities need tobe configured between LSPs carrying traffic from different CTs.

It ensures the bandwidth efficiency and the protection against QoS degradation of thepremium CT.

It does not require much revision of the current protocols.The problem with MAM is that because it is not possible to share unused bandwidth between CTs,

bandwidth may be wasted instead of being used for carrying other CTs.

III.3.2.2. The Russian Dolls Model (RDM)

The RDM improves bandwidth efficiency over the MAM model by allowing CTs to share

bandwidth. It defines a cumulative set of constraints that group CTs. Subsequent lower BCs define

the total bandwidth allocation for the CTs at equal or higher levels. BC0 always defines themaximum bandwidth allocation across all CTs and is equal to the maximum reservable bandwidth

of the link.The recursive definition of BCs improves bandwidth sharing between CTs. A particular CT can

benefit from bandwidth left unused by higher CTs. A DS-TE network using RDM can rely on TE

LSP preemption to guarantee that each CT gets a fair share of the bandwidth [1].

The Figure 8 shows an example of a set of BCs using RDM. This DS-TE implementation uses three

CTs with their corresponding BCs. In this case, BC2 limits CT2 to 30 percent of the maximum

reservable bandwidth. BC1 limits CT2+CT1 to 70 percent. BC0 limits CT2+CT1+CT0 to 100

percent of the maximum reservable bandwidth, as is always the case with RDM. CT0 can use up to100 percent of the bandwidth in the absence of CT2 and CT1 TE LSPs. Similarly, CT1 can use up

to 70 percent of the bandwidth in the absence of TE LSPs of the other two CTs. CT2 will always belimited to 30 percent when no CT0 or CT1 TE LSPs exist.


20/41


IMCNE thesis 15

Figure 8. RDM Constraint Model Example

The advantage of RDM relative to MAM is that it provides efficient bandwidth usage through

sharing. It is a good match to the way many network operators manage QoS in the data plane, e.g.,

voice in Low Latency Queuing (LLQ), business data in a high weight Class-Based Weighted FairQueuing (CBWFQ) class, and best effort getting whatever is left. RDM provides for good isolation

between classes, and efficient use of bandwidth. It can also simultaneously provide the bandwidthefficiency and the protection against QoS degradation of all CTs, whether preemption is enabled or

not. Besides, similar to the MAM, the RDM does not require much revision of the current

protocols.

The disadvantage of RDM relative to MAM is that there is no isolation between the different CTs,

and preemption must be used to ensure that each CT is guaranteed its share of bandwidth no matter

the level of contention by other CTs.

III.3.2.3. The Maximum Allocation with Reservation Model (MAR)

The MAR model can be regarded as an extension of the MAM. Like the MAM, each CT has a

corresponding bandwidth constraint in the MAR model. However, unlike the MAM, the CTs are

allowed to exceed their constraints, provided that no congestion or overload occurs. A new

parameter, denoted byRBT, was introduced into MAR to characterize the Threshold of BandwidthReservation [5].

The bandwidth allocation control for each CT is based on estimated bandwidth needs, bandwidth

use, and status of links. The Label Edge Router (LER) makes needed bandwidth allocation changes,and uses (for example, to determine if link bandwidth can be allocated to a CT). Bandwidth

allocated to individual CTs is protected as needed, but otherwise it is shared. Under normal, non-

congested network conditions, all CTs/services fully share all available bandwidth. When

congestion occurs for a particular CTc, bandwidth reservation prohibits traffic from other CTs from

seizing the allocated capacity for CTc .


21/41


IMCNE thesis 16

The IETF does not mandate usage of the same BC model on all links in the network. However, it is

easier to configure, maintain, and operate a network where the same bandwidth constraint model isused.

III.3.3. Deploying the DiffServ-TE solution

To summarize the previous sections, MPLS DiffServ-aware TE makes MPLS-TE aware of Quality

of Service, by combining the functionalities of both DiffServ and Traffic Engineering. This solution

handles the problems of providing guaranteed QoS by enabling the reservation of bandwidth on a

per-class basis. To ensure this, the following steps are required:

- Partition the link bandwidth among the different CTs

-Configure the LSPs with the desired CT and bandwidth reservation

-Choose a BC model that ensures the needed requirements

-Setup the queue and scheduling policies

-Map the EXP-to-PHB throughout the DiffServ domain if the DiffServ treatment is

determined from the EXP bit.

IV. QoS operations

QoS management architecture of voice traffic can be partitioned into two planes: data plane andcontrol plane. Mechanisms in data plane include packet classification, shaping, policing, buffer

management, and scheduling. They implement the actions the network needs to take on user

packets, in order to enforce different class services.

Mechanisms in control plane consist of resource provisioning, traffic engineering, admissioncontrol, resource reservation and connection management [9].

IV.1. Classification, Shaping and Policing

When a packet is received, a packet classifier determines which flow or class it belongs to,

effectively partitioning network traffic into different levels. Figure 9 shows that all packets

belonging to the same flow/class obey a predefined rule and are processed in a similar manner. Forexample, for voice traffic applications, the basic criteria of classification could be IP address,

TCP/UDP port, protocol, input port, IP precedence, DiffServ code points (DSCP), or Ethernet

802.1p class of service (CoS).


22/41


IMCNE thesis 17

Figure 9. Classifying and Marking

After classification, the packet is passed on to a traffic conditioner, which may contain meter,

marker, shaper, and dropper. A meter is to decide whether the packet is in a traffic profile. This

information may be used by other elements to trigger a particular action.In-profile packets are put in different service queues for further processing. A shaper or a dropper

delays or drops out-of-profile packets in a packet stream in order to bring the stream into

compliance with its traffic profile. The function of a dropper is known as traffic policing. A marker

marks the certain field in the packet, such as DS field, to label the packet type for differential

treatment later. After the traffic conditioner, a buffer is used to store packets that wait fortransmission.

Figure 10. Policing and Shaping

Policersallow limiting traffic of a certain class to a specified bandwidth and bursting size. Packetsexceeding the policer limits can be discarded, or can be assigned to a different forwarding class, a

different loss priority, or both. But traditionally, packets are dropped only when the queue is full.

IV.2. Scheduling

An individual router interface has multiple queues assigned to store packets. The router decides

which queue to service based on a particular method of scheduling. This process often involves a

determination of which type of packet should be transmitted before another. As shown in Figure 11,a scheduler defines the queuing parameters of the FC (Forwarding Class), specifically its


23/41


IMCNE thesis 18

transmission rate, buffer size, and priority. It is where the queuing specifics and buffer depth are

configured.

IV.2.1. Transmission rate

A transmission rate is assigned to each FC proportionally to the bandwidth credit the queue has. It

can be specified as either exact or remainder. If exact is specified, the FC cannot exceed the

configured transmission rate. If it is specified as remainder, the FC is allowed to use unallocated

bandwidth (the queue can borrow bandwidth from the others).

IV.2.2. Buffer size

It defines the amount of memory allocated to the outbound transmission queue. This parameter isparticularly useful for real-time traffic where it is desirable to forcibly eliminate the delivery of stale

packets.

IV.2.3. Priority

A Forwarding Class associated with a queue has a priority of low, high, or strict high associated

with it. The scheduler examines queues in a round robin fashion. If two queues or more have a

packet to send and have enough bandwidth credit, then the queues with high priority are serviced

first.

Scheduling policy is primarily to control queuing delay and bandwidth sharing. The aggregate

bandwidth of a link can be shared among multiple entities.

Figure 11. Scheduling and Queuing

IV.3. Queuing

After a packet is sent to the outgoing interface on a router, it is queued for transmission on the

physical media. The amount of time a packet is queued on the router is determined by the

availability of the outgoing physical media as well as the amount of traffic using the interface.

Queuing generally is used to give voice priority over data traffic.


24/41


IMCNE thesis 19

Queuing delay can be reduced by introduction of advanced queuing features such as:

FCFS: First Come First Serve

WFQ: Weighted Fair Queuing: WFQ applies priority (or weights) to identified traffic toclassify traffic into conversations and determine how much bandwidth each conversation is

allowed relative to other conversations. WFQ classifies traffic into different flows based on

such characteristics as source and destination address, protocol, and port and socket of the

session.

CBWFQ: Class-Based WFQ: CBWFQ extends the standard WFQ functionality to providesupport for user-defined traffic classes. It allows specifying the exact amount of bandwidth

to be allocated for a specific class of traffic. Taking into account available bandwidth on the

interface, we can configure up to 64 classes and control distribution among them.


25/41

Chapter 3: Experimental activity

IMCNE thesis 20


I.Characterization of QoS for voice trafficThe previous chapters gave an overview of Quality of Service techniques in IP/MPLS

networks. This chapter presents a special case which is how to use those mechanisms to handle

voice traffic. The first part presents voice traffic characteristics and its QoS requirements. The

second describes the testbed set-up needed for configuring QoS parameters as well as the software

implemented for generating and capturing the traffic. The last part deals with the tests we carriedout and the obtained results.

I.1. Voice traffic characteristics

Voice traffic imposes stringent QoS requirement. Thus, the support of voice traffic in MPLS

networks is challenging. Indeed, traditional data transmission does not support any loss under

penalties for the interpretation and the use of these data by the receiving equipment, but it supports

on the other hand an important delay in term of routing time. In fact, the expected behaviour of

voice is exactly opposite: 1% or 2% of data loss of voice are not too much awkward for the qualityof the service, but on the other hand 100 ms as a frequent variation on the time of transit is

catastrophic and makes the service unusable for the voice calls [8].

Voice data is carried by the Real-time Transport Protocol (RTP) [2] which defines a standardized

packet format for delivering audio and video over the Internet. RTP does not have a standardTransmission Control Protocol (TCP) or User Datagram Protocol (UDP) [2] port on which it

communicates but as voice data is very time-sensitive, in this case it relies on UDP to take benefit

from its lower latency providing both sequencing information so that packets are delivered in the

correct order, and timing information so that issues such as network delay can be accounted and

compensated for.

Before sending voice traffic, the data has to be compressed according to a given audio file format

by means of a codec (coder-decoder) to reduce the storage space and the bandwidth required for thetransmission of the audio file. Many voice codecs are used in IP telephony with different bit rates

and complexities. The standard payload of a voice packet contains a sample of 20 ms of voice

which is usually in the vicinity of 20 bytes (with the G.729 codec and can reach 40-60 bytes withG.726 and 160-byte payload for G.711) [8].


26/41


IMCNE thesis 21

Figure 12. A standard voice packet

The Figure 12 shows that the combined headers of RTP, UDP, and IP of a standard voice packetadd up to a total of 40 bytes, meaning that overhead accounts for approximately 66% of the size

of a packet with a 20-byte voice payload. When MPLS labels are added, the voice packet header

changes to voice/RTP/UDP/IP/MPLS-labels, and becomes 44 bytes.

The Table 1 below summarizes the packetization delay according to some codecs. It shows that IP

and MPLS headers are constant regardless to the codec used (respectively of 40 and 44 bytes) and

that the MPLS packets transmit rate is always higher than IP packets transmit rate [8].

Codec CodecBandwidth

(kbps)

Payload

Size

(Bytes)

Packetization

Delay (ms)

IP

Header

Size

(Bytes)

MPLS

Header

Size

(Bytes)

Transmit

Rate

(pps)

IP

packets

Transmit

rate

(kbps)

MPLS

packets

Transmit

rate

(kbps)

PCM,G.71164 160 20 40 44 50 80 81.6

ADPCM G.72632 80 20 40 44 50 48 49.6

CS-ACELP, G.7298 20 20 40 44 50 24 25.6

MP-MLQ, G.723.16.3 24 24 40 44 32.8125 21.334 22.667

MP-ACELP,G.723.15.3 20 30 40 44 33.125 16 17.067

Table 1. Packetization delay


27/41


IMCNE thesis 22

Notes:

Voice packets per second (pps) = codec bit rate / voice payload size

IP packet size = IP Header + payloadMPLS packet size = MPLS Header + payload

Transmit Rate (bps) = Packet size (bits) / Packetization delay (sec)

I.2. QoS requirement for voice traffic

QoS is a major issue for voice traffic transmission which consists in how to guarantee that packet

traffic for voice will not be delayed or dropped due to interferences with other lower priority

traffics.

To avoid this degradation of the traffic, some parameters have to be considered:

LatencyLatency is the delay needed for packet delivery. Large delays are burdensome and can cause bad

echoes. ITU-T G.114 recommends a maximum of a 150 ms one-way latency. Since this includes the

entire voice path, part of which may be on the public Internet, the network should have transit

latencies of considerably less than 150 ms.

JitterJitter consists in the variations in delay of packet delivery. Jitter causes strange sound effects, but

can be handled to some degree with "jitter buffers" included in most VoIP endpoint devices (e.g.

VoIP phones). Jitter buffers (also known as playout buffers) are used to change asynchronous

packet arrivals into a synchronous stream by turning variable network delays into constant delays at

the destination end systems. The role of the jitter buffer is to trade off between delay and theprobability of interrupted playout because of late packets.

Packet lossThe voice transmission is based on RTP protocol. The real-time constraints of the transmission

delay make the retransmission of the lost packets useless: even retransmitted, a RTP datagram

would arrive too much late to be useful to the reconstitution process of the voice. These data lossesmay due to the congestions on the network, which involve rejections of packets throughout the

network, or to an excessive jitter which will cause rejections of packets in the jitter's buffers of thereceiver.

A regular but weak data loss is less awkward than the peaks of loss which are spaced but high.

Indeed, human listening can be accustomed to an average but constant quality and on the other hand

will not support sudden degradations of QoS.


28/41


IMCNE thesis 23

II. Experimental setup

II.1. Testbed schema

Figure 13. The testbed

The experimental setup for this work is presented in the Figure 13 and consists in two physical M10

Juniper routers, used as edge routers. On this two physical routers are configured two virtual routers

used as core routers. The two M10 routers are connected by three unidirectional Label Switched

Paths: voice, network control and best-effort LSPs. Each LSP is used to transport one category oftraffic. On each router (edge and core routers), queuing and scheduling mechanisms areimplemented to handle voice and best-effort packets.

II.2. Software

To generate voice traffic, the software packETH was used. PackETH is a Linux GUI packet

generator tool for Ethernet. It allows to create and send any possible packet or sequence of packets

on the Ethernet. In our case, RTP packets are generated to simulate the voice traffic (the payload of

voice packets can be configured with different options to send waves of any frequency and with

different codecs). In addition to voice traffic, best-effort traffic is generated by a router test toemphasize the differentiation in treatment between the two kinds of traffic.


29/41


30/41


IMCNE thesis 25

Figure 15. RTP packet configuration

After elaborating the sample, the number of packets needed is set and the sending is now possible.

As the links used have a capacity of 100M and that while configuring the schedulers in the several

nodes of the network the transmit-rate of voice traffic was set at 90 percent, 3 tests will be carriedout: sending 50M, 90M and 100M of traffic.

In order to analyse the traffic sent, the software wireshark is used. Wireshark allows, as showed in

Figure 16 to capture the incoming traffic on a specified interface.


31/41


IMCNE thesis 26

Figure 16. Traffic capture

Figure 17 indicates how incoming traffic is organized by wireshark. Each received packet is listed

according to its reception time, source address, and protocol. In the study, only RTP packets will be

taken into consideration.

Figure 17. Packets listing


32/41


IMCNE thesis 27

In order to create congestion in the network and not to send only voice traffic, best-effort traffic is

also sent at the same time on the network using a Router Test.

II.4 Router configuration

Classification allows to divide traffic into classes and offer various levels of throughput and packetloss. It is a way of managing traffic in a network by grouping similar types of traffic (for example,

e-mail, streaming video, voice, large document file transfer) together and treating each type as aclass with its own level of service priority. In our case we will have 2 CoS: Voice and Data.

The CoS components are summarized in the following figure:

Figure 18. CoS components

On the routing platform, 3 Forwarding Classes (FC) will be configured for transmitting packets

(expedited-forwarding, best-effort and network control), define which packets are placed into each

output queue and schedule the transmission service level for each queue.

To configure the voice traffic, the following steps are needed:

Classification of the packet: associate incoming packets with a forwarding class andloss priority and, based on the associated forwarding class, assign packets to outputqueues.

For that we will use Behavior aggregate (BA) or code point traffic classifiers which determine the

forwarding class and the loss priority of each packet. BA classifiers allow to set the forwardingclass and loss priority of a packet based on DiffServ code point (DSCP) bits.

Configure a scheduler for each FC: the expedited-forwarding class has a strict highpriority queue

Mark the packetsII.3.1. Pre-configuration

Before starting to configure the routers, we need to access to them in the configuration mode usingthe appropriate login and password (Figure 19).


33/41


IMCNE thesis 28

Figure 19. Access to the router

II.3.2. Configuration of the network interfaces

The network testbed is composed of a set of interfaces, each one having an interface name

represented by a physical part, a channel part (optional) and a logical part. The physical part whichcorresponds to a single physical connector has the following format: type-fpc/pic/port (with: type:

identifies the network device, fpc: number of FPC card, pic: number of PIC on which the physical

interface is located, port: a specific port on a PIC). The Figure 20 shows the configuration of some

interfaces of the testbed.

Figure 20. Interfaces configuration

II.3.3. Routing protocols configuration

To automatically forward MPLS traffic, the Open Shortest Path First (OSPF) need to be configured

to advertise the forwarding adjacency to the other routers in the network and add the forwarding

adjacency to the traffic engineering database (TED). OSPF is the only supported interior gatewayprotocol (IGP). The following figure describes the configuration of MPLS and OSPF protocols.


34/41


IMCNE thesis 29

Figure 21. Routing protocols configuration

II.3.4. Forwrding classes

The Forwarding Class (FC) plus the loss priority define the per-hop behaviour which specifies the

policy and priority applied to a packet when traversing a hop (such as a router) in a DiffServ

network. Four categories of forwarding classes are supported: best effort, expedited forwarding,

assured forwarding, and network control. To configure FCs we have to define them and then to

assign them to the outgoing queues.

Figure 22. Forwarding Classes configuration


35/41


IMCNE thesis 30

II.3.5. Label Switched Path configuration

Three Label Switched Paths are configured in the network each, as described in the Table 2 below,is associated to a Forwarding Class. As we will not take into consideration the assured-forwarding

class, only the other three are described.

Class-Name LSP

Network Control toPap-NC

Expedited Forwarding (voice) toPap-voice

Best Effort toPap-BE

Table 2. LSPs characteristics

Figure 23 shows how each LSP is associated, in the outgoing interface of the ingress edge router, toa Forwarding-Class by giving the address of the destination edge router.

Figure 23. Configuration of LSPs

II.3.6. The classification of packets

The multifield classifier sets the Forwarding Class of incoming packets which are then assigned to

an outbound transmission queue. The scheduler receives the forwarding class settings, and queues

the outgoing packet based on those settings.

The Figure 24 shows how the classifier is applied to the traffic generator interface (using its IPaddress) so that the packets can be filtered according to their source address.


36/41


IMCNE thesis 31

Figure 24. Configuration of the multi-field classifier

The multi-field classifier is only configured in the edge router. For the core routers, we use

Behavior aggregate (BA) or code point traffic classifiers which determine each packets forwardingclass and loss priority. As showed in Figure 25 BA classifiers allow to set the forwarding class and

loss priority of a packet based on DiffServ code point (DSCP) bits.

Figure 25. Configuration of a BA classifier

II.3.7. Scheduler configuration

Juniper routers support Weighted Round Robin (WRR) scheduling in order to achieve service

differentiation. Each queue is assigned a certain weight indicating the amount of guaranteed

capacity. WRR will serve the different queues according to these weights. The high priority packetsare served before any low priority packets.

As showed in the figure below, for each queue the following parameters are set:


37/41


IMCNE thesis 32

'transmit-rate percent x' assigns x% of the port capacity to the queue: determines the actualtraffic bandwidth.

'buffer size percent x' assigns x% of the total buffer to the queue: large queues may increaselatency during congestion whether smaller queues may be more appropriate for delaysensitive traffic.

'queue priority' may take three values: low, high or strict-high: determines the order in whichan output interface transmits traffic from the queues. JUNOS supports low, high, and Strict-

high priority.

Figure 26. Schedulers configuration

After setting the parameters, each scheduler has to be associated to a queue (a Forwarding Class).This mapping is configured and then binded to the related interfaces.

II.3.8. Mark outgoing packets

The marking of packets with a DSCP value is the last QoS action performed before the transmissionof the packet. Juniper M-series routers can only mark packets at the output interface. Indeed, there

are no markers at the input interface.


38/41


IMCNE thesis 33

Figure 27. Marking outgoing packets


39/41

Conclusion

IMCNE thesis 34

Conclusion

The growth of multimedia applications over wide area networks has increased research interest in

Quality of Service. Just increasing the amount of resources such as available bandwidth to avoid

congestion is not enough to provide proper resource utilization and the setup of QoS parameters

become necessary.

Traffic Engineering is concerned with the performance optimization of operational networks. Its

main objective is to reduce congestion hot spots and improve resource utilization through carefully

managing the traffic distribution inside a network. MPLS associated with the DiffServ architecture

allow the implementation of evolved TE mechanisms by providing the possibility of establishing

source routed paths that are carrying traffic on a per-class basis

This work is dedicated to the study of those mechanisms and their configuration. After an overviewof the different QoS mechanisms supported in MPLS network, and as a case of study, the report

considered the set-up of LSPs carrying voice traffic and the configuration of Quality of Serviceparameters allowing to handle this kind of specific traffic in case of adding other kinds of traffic

(mainly best effort) in the network.

Regarding the adopted methodology, the need for Quality of Service in IP/MPLS networks was firstdemonstrated and the concepts necessary to establish QoS in the network such as DiffServ-aware

Traffic Engineering, Bandwidth Constraint models and QoS operations were then studied. As a

second step, those mechanisms were configured over a testbed and voice traffic was taken as an

example. This configuration was implemented in order to offer a treatment that goes moreadequately with voice traffic requirements.

There are still many works remaining in the progress of end-to-end QoS management for multi-

service in IP networks. Those configurations can in fact be extended and refined to carry out all

kinds of traffic, add more restrictions on QoS parameters and extend the configurations to a large

network, composed of several and heterogeneous domains.


40/41

References

IMCNE thesis 35

References

[1] I.Minei, J.Lucek, "MPLS-Enabled Applications. Emerging Developments and New

Technologies ", John Wiley & Sons, Ltd, 2005.

[2] W.Stallings, "High-Speed Networks and Internets: Performance and Quality of Service ",

Prentice-Hall, Inc, 2002.

[3] Paul P.White. "RSVP and Integrated Services in the Internet ", IEEE CommunicationsMagazine, 1997.

[4] J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, "Requirements for Traffic Engineering Over

MPLS", RFC 2702, September 1999

[5] J. Ash, "Max Allocation with Reservation Bandwidth Constraints", RFC 4126, June 2005

[6]R.Braden, L.Zhang, S.Berson, S.Herzog, "Resource ReSerVation Protocol (RSVP)", RFC 2205,

September 1997

[7] S.Capshaw, "Applying JUNOS Class-of-service Features ", Juniper Networks, Inc, 2002.

[8] "Traffic Analysis for Voice over IP", CISCO document, 2001

[9] B.Enders, "Quality of Service for Voice over IP ", Chesapeake NetCraftsmen, 2003.

[10] http://packeth.sourceforge.net/

[11] http://www.wireshark.org/


41/41

Glossary

Glossary

AF: Assured Forwarding

BC: Bandwidth Constraint

BE: Best Effort

CoS: Class of Service

CT: Class TypeDSCP: DiffServ Code Point

EF: Expedited Forwarding

EXP bit: Multiprotcol Label Switching Experimental bit

FC: Forwarding Class

IETF: Internet Engineering Task Force

IP: Internet Protocol

ITU-T: International Telecommunication Union - Telecommunication Standardization Bureau

LSP: Label Switched PathLSR: Label Switched Router

MAM: Maximum Allocation ModelMAR: Maximum Allocation with Reservation Model

MPLS: Multi Protocol Label Switching

NC: Network Control

PDA: Personal Digital AssistantPHB: per-hop behaviour

QoS: Quality of Service

RAT: Robust Audio Tool

RDM: Russian Dolls ModelRSVP: ReSource reserVation Protocol

RTP: Real-time Transport ProtocolTCP: Transmission Control Protocol

TE: Traffic Engineering

VoIP: Voice over IP

UDP: User Datagram Protocol

pw gharbaoui imcne07

Documents