• Non ci sono risultati.

1.1 - The need for Quality of Service (QoS) 1 - Introduction

N/A
N/A
Protected

Academic year: 2021

Condividi "1.1 - The need for Quality of Service (QoS) 1 - Introduction"

Copied!
10
0
0

Testo completo

(1)

1 - Introduction

1.1 - The need for Quality of Service (QoS)

In the Internet, all the traffic is accepted and treated in the same way with a “best-effort” service. Traffic is processed as quickly possible. The packets to be sent are forwarded as soon as the resources are available, but there is no guarantee for the delivery times or for packet loss. This service is efficient for a large number of applications, but for a lot of other ones it is completely insufficient, especially with the fast transformation of the Internet into a commercial infrastructure. Some new applications need a better “Quality of Service” (QoS). For example, time-sensitive traffic, such as voice and real- time applications, should receive higher guarantees than less time-sensitive traffic such as file transfers or e- mail. These guarantees might include higher priority, dedicated bandwidth, controlled jitter and latency, and improved loss characteristics.

So, one issue is performance assurance, for example during a phone call over Internet, some parts of the network may be so busy that the packets cannot get through. Another issue is service differentiation, because as said before, Internet treats all the traffic with a single level of service that is best-effort, while the needs of different applications may have very different characteristics.

Therefore, QoS is the ability of a network element (e.g. an application, a host, a router) to provide some level of assurance for consistent network data delivery services.

(2)

probably, this solution will not work, no matter how much bandwidth the network can provide, because new applications will be invented to consume them. Hence, optimal utilization and differentiated use of the existing bandwidth becomes a critical issue.

Another question that is to be faced is the increasing request to the Internet Service Providers (ISPs) to be able to sustain Virtual Private Networks (VPNs), which are a new private network alternative made using the public network infrastructure, but with the fundamental difference that these are secure and reliable.

The objective to be reached with a VPN is to connect two or more distant places, using the public network, in such a way that they may appear to the users like one single Intranet. This is a useful thing in many cases, especially in the business world, where, for example, it allows to connect remote offices to the main corporate network, in an economical way, as compared with the cost of dedicated leased lines. Obviously, a VPN needs a treatment that must provide a dedicated service with some kind of quality of service.

QoS has been a problem for the Internet world for a long time: “The Internet has met its enemy and its name is QoS” [Carpenter, 97]. In spite of this famous sentence being old, these words could not be more true today, like they were on the period of that discourse, because with the passing of the time numerous and various technologies have been developed to answer the increasing request for QoS.

1.2 - Technologies for QoS

This section gives just a quick look to the ne twork technologies to provide QoS. A deeper treatment for the Differentiate Service and Multi Protocol Label Switching (with Traffic Engineering) will be made on the next chapter.

(3)

First of all, it should be clear the meaning of the term “flow”: a flow is defined as an IP packet stream from a source to a destination (unicast or multicast) application with an associated Quality of Service (QoS)[RFC 2386].

IP QoS refers to the performance of IP packet flows through one or more networks. The aim is to deliver end-to-end QoS to user traffic, where QoS implies that the network has to be capable to treat some packet flows differently from others.

The Internet Engineering Task Force (IETF) has defined many models and mechanisms to give a certain quality of service to the users on IP-networks, such as Integrated Services (IntServ), Differentiated Services (DiffServ), Multi-Protocol Label Switching (MPLS) and Constraint-based Routing (C R) to automatically obtain Traffic Engineering (TE).

Integrated Services is the oldest technology, not used very much nowadays. It is based on

the use of the Resource Reservation Protocol (RSVP) and provides quantitative gua rantees to the flows. IntServ is the most complex of all QoS technologies. Before any data transmission, the applications must set a path, reserving resources in the routers, through the creation of a soft state that must be periodically refreshed.

However, IntServ provides the highest level of QoS in terms of service guarantees, granularity of resource allocation, and detail of feedback to QoS-enabled applications. It provides two service classes in addition to best-effort service, that are the Guaranteed service, for applications requiring fixed delay bound, and Controlled- load servic e, for applications requiring a reliable and enhanced best-effort service [Xiao, 99] [Peterson, 00].

Differentiated Services, instead, provides qualitative assurances addressing the clear need

for relatively simple and coarse methods of categorizing traffic into different classes, also called class of service (CoS), and applying QoS parameters to those classes [RFC 2474].

(4)

- DSCP) in the IPv4 ToS Octet or the IPv6 Traffic Class Octet is used to this end [RFC 2474].

One of the fundamental principles of this architecture is to leave complexity at the “edges” and keep the network core simple. Service requirements are classified and classification is performed at network ingress points only. After marking the packets, specific forwarding treatments, called Per-Hop Behavior (PHB), are applied on each network element, providing the reque sted service to the flow [Peterson, 00].

Up to now, two main PHBs are defined: Expedited Forwarding (Premium service) which offers guaranteed QoS, no-loss, and constraint-delay [RFC 2598]; Assured Forwarding (Assured Service) with statistic QoS, low loss and low delay [RFC 2597].

Traffic Engineering is a solution to install and check the flows of traffic inside the

network, taking full advantage of all the potentialities offered by the available resources and avoiding uneven network utilization. In fact, it happens often in Internet that the shortest path is the only one chosen to forward the packets, leaving many other paths unused, with a consequent uneven use of the network’s potentialities. Therefore, the objective of Internet traffic engineering is to facilitate the transport of IP traffic through a given network in the most efficient, reliable, and expeditious manner possible [Xiao, 99] [Awduche, 99].

Constrained-Based Routing (name used in opposition of the destination-based routing) is

an important instrument to make the traffic engineering process automatic. The process of establishing a determined route is based not only on the network’s topology, but also on the use of particular metrics, as for example bandwidth, delay, monetary cost, and jitter. The routing algorithm chooses a path able to optimize one or more of these metrics. Generally, a metric based on the hop count and on the bandwidth is used.

(5)

Thus, evidently, every router involved in CR has to compute its routing table more frequently than in the case of destination-based routing, just because the parameters used for the metrics may change even without topology changes [Xiao, 99].

Multi Protocol Label Switching (MPLS) has been developed to accelerate routing of

aggregated traffic destined towards a common point by using Label Switched Paths (LSPs). Packet’s classification is performed at network ingress points, the intermediate routers do not have to make routing decisions and they simply forward the traffic based on the interface and the va lue of the label. This implies a smaller quantity of work, less complexity, and an increased speed of the routers. Routers in an MPLS domain behave as a sort of layer 3 Switches [RFC 3031] [Awduche, 99] [Davie, 00].

The MPLS packet classification is done by inserting between the layer 2 and layer 3 headers a fixed length header (called “shim” header) that is composed by a 20-bit label, a 3-bit Class of Service (CoS) field, a 1-bit label stack indicator, and an 8-bit Time to Live (TTL) field [RFC 3032].

MPLS supports both DiffServ and Traffic Engineering, the first by using both the label and the CoS field, the second by providing an efficient tunneling mechanism and supporting the explicit routing through a certain path. So, the strategical importance of the MPLS protocol is due, not only to its capacity to provide a faster packet classification and forwarding, but also because it is involved in what is probably the best answer to the request of QoS [RFC 3031] [RFC 3270] [Awduche, 99] [Davie, 00].

Asynchrono us Transfer Mode (ATM) is a network technology able to provide QoS and

traffic engineering. Thanks to the simplicity and speed of the switching operations, to the small fixed dimensions of the traffic unit (the cell), and its capacity to support Virtual

(6)

reached by a joint use of MPLS (that may be used also over an ATM network) together with DiffServ, avoiding some ATM disadvantages [Peterson, 00].

1.3 - Possible options

The option selected for this work is the study of the DiffServ model together with MPLS and its Traffic Engineering. Why this choice?

The IntServ model is considered a little obsolete and inadequate, as it requires reservation for specific micro- flows in each router in a path, and this leads to significant scalability problems. So, the worse problem of the IntServ model is just its complexity, as the size of the state information increases proportionally with the number of flows, placing a huge storage and processing overhead on the routers. Consequently, this architecture is not good for the Internet core [Xiao, 99].

For these reasons, we have decided to direct us towards the DiffServ model that divides traffic into a small number of classes and allocates resources on a per-class basis. The combination of packet marking and well-defined PHBs results in a scalable QoS solution for any given number of flows, and thus any application. Therefore in DiffServ, signaling for QoS can be eliminated, the size of the state required to be kept at each network element is drastically reduced, and there is no soft state on the path’s routers (and with this, no need of refreshing it), resulting in a coarse- grained, scalable QoS solution.

Concerning the possibility to use Traffic Engineering, the choice of a full Constrained-Based Routing used alone entails a great computational load to the routers, because the routing tables are more complex, larger, and must be calculated more often. However CR may be used together with an MPLS architecture (they are not mutually exclusive), helped by its characteristics to compute easily the best path [Xiao, 99].

(7)

There are ma ny reasons for the use of MPLS. First of all, it provides Traffic Engineering capabilities without a large amount of computational load. While in the “pure” IP world forwarding and control are joined, MPLS separates the functionalities of forwarding from those of control: the forwarding is done based on the value of the label assigned in the set-up phase of the LSP, while control messages (signaling, routing) make reference to IP addresses. Not only MPLS separates, but also extends, the functionalities of control in virtue of the presence of LSPs, the functionalities of control are wider: explicit routing, reservation, protection [RFC 3031] [RFC 3270] [Awduche, 99] [Davie, 00].

Another important characteristic of MPLS is that it gives a very good support to the tunneling, and this is fundame ntal to build Virtual Private Networks (VPNs).

Moreover, MPLS may operate in a wide range of layer-2 backbones (like Frame Relay and ATM) and layer-3 protocols (like IPv4, IPv6, or the Novel protocol IPx) [Davie, 00]. MPLS offers also IP QoS services by aggregating the traffic and giving a good support to the DiffServ within its header [RFC 3270].

As shown in figure 1.1, MPLS has been developed by the IETF to support all the main QoS solutions developed by the IETF before standardizing the MPLS architecture.

Integrated Service Constrained-based

Routing Differentiated Service

L'Internet Engineering Task Force (IETF)

(8)

1.4 - Objectives of the work

The objectives of the work are to compare the QoS obtained by users in a DiffServ network in the following three scenarios:

- Regular routing of each packet,

- MPLS Traffic Engineering (MPLS-TE) of the path followed by the traffic in each DiffServ class.

- MPLS Traffic Engineering (MPLS-TE) with dynamic bandwidth assignments to the traffic classes.

Then we will evaluate QoS gains that can be obtained by traffic engineering with MPLS. The QoS gains can be measured by:

- The number of connections admitted by the Connection Admission Control. For example a border router in a network, with the use of MPLS-TE, may be able to admit a significant number of connections more than the not-MPLS-TE case. - Better end-to-end delays. That is very important for the time-sensitive applications. - Better end-to-end jitter. Useful in the case of voice or video streaming.

- Less packet loss. This is a fundamental characteristic to evaluate QoS gains, because it involves all the Internet applications, from the simplest to the most complicated. Thus, improving the packet loss will result in a general improvement of the performance of the entire network.

The effect on QoS of the following techniques will be evaluated: - Connection Admission Control policies.

- Bandwidth sharing policies. - Path selection policies.

In conclusion, this work should give an introduction to research and knowledge about the improvements int roduced by Traffic Engineering in a DiffServ network.

(9)

1.5 - Use of NS2 for simulations

A simulator is a tool used for studying the dynamics of systems. In this case the system is a packet network. Even if modelling and simulating Internet is not easy, because of its great heterogeneity and rapid changes, by focusing our attention on some part of the network, like a highly redundant backbone in the network core of an Internet Service Provider (ISP), may lead to a good approximation of what really can happen in that part of the network. A simulator is the most promising tool to be used in all the cases where we must test a new kind of approach to a problem like a new technology or a change in something on the network’s architecture. To be more accurate, more than one simulation has to be made, varying appropriately the parameters involved [Floyd, 01].

We have used NS2 in this work, a discrete event simulator for networks. NS2 is free and open-source. This means that everybody can modify the program by inserting new characteristics or by fixing some bugs (that still are found today) [Manual]. The Information Science Institute makes the whole package available in their site www.isi.edu

[isi]. We have used version 2.1b8 all- in-one for Linux.

NS2 is written in C++, while it uses the programming language OTcl, that is an Object-oriented version of Tcl (Tool Command Language), to describe all the necessary operations to define a simulation.

A packet network can be thought as a set of objects with different nature and different characteristics (routers, bridges, gateways, connections among the different nodes, applications, etc.) that interact and cooperate to offer some services to the consumers. We can associate to every real component a virtual object that can mirror its characteristics. Therefore, OTcl provides the interface used by users to describe the model

(10)

their interconnections, the applications that produce traffic, the instants in which they activate and they stop, etc.

The program simulates the operation of the network described in the file with the configuration of the simulation (an OTcl script) and it produces a set of files with the results useful for our stud y. According to what is specified in the input script, NS2 can produce as output different kinds of trace files that may be provided as input to programs like Nam (the Network Animator), or may be used (as text files) to do an accurate analysis of the parameters in the simulation we want to do. The trace files contain information concerning the topology of the network (nodes and connections), the simulation events, and the packets that have moved in the network [Garroppo, 03] [Manual].

Riferimenti

Documenti correlati

Use of all other works requires consent of the right holder (author or publisher) if not exempted from copyright protection by the

The effects of such actions can be measured and expressed by resilience indicators (central box) that have the purpose of interpreting the effects in seven resilience dimensions,

Progetto della bretella di collegamento tra la SP26 e la SR439 in località Carraia,.

Infatti, nel suo studio sul ciclo di Baal, egli afferma che la rinascita del dio coincide ancora una volta con il nuovo anno, mentre la sua morte, così come quella di Aqhat,

Moreover, previous studies provided evidence that PARylated protein levels, the major products of PARP activity, are significantly increased in lung homogenates of WT mice treated

Anche se la storia atlantica rifiuta una visione unidirezionale – dall’Europa verso occidente – della diffusione delle idee preferendo una visione circolare dei transfert

Con l’immissione della figura della perequazione urbanistica nel sistema giuridico si introduce un elemento che modifica il risultato interpretativo del principio di uguaglianza:

Single tree crowns delineation using multireturn ALS data in an Alpine forest Kaja Kandare 1,3 , Michele Dalponte 2 , Jonathan Cheung-Wai Chan 1,4 , Hans Ole Ørka 3 ,