UNIVERSIDADE DE PERNAMBUCO

ESCOLA POLITÉCNICA DE PERNAMBUCO

PROJETO DE FINAL DE CURSO

SERVIÇOS INTEGRADOS E

DIFERENCIADOS PARA REDES DE

BANDA LARGA

por:

DENISON GENUINO VIEIRA

Recife, maio de 2009.

1

UNIVERSIDADE DE PERNAMBUCO

ESCOLA POLITÉCNICA DE PERNAMBUCO

DEPARTAMENTO DE ENGENHARIA ELÉTRICA

SERVIÇOS INTEGRADOS E DIFERENCIADOS PARA REDES

DE BANDA LARGA

por

DENISON GENUINO VIEIRA

Monografia apresentada ao curso de Engenharia Elétrica – modalidade Eletrônica da Universidade de Pernambuco, como parte dos requisitos necessários à obtenção do grau de Engenheiro Eletricista. ORIENTADOR: ANDRÉ RICARDSON GOMES E SILVA, mestre

Recife, Maio de 2009.

© Denison Genuino Vieira, 2009

2

Resumo da Monografia apresentada ao curso de Engenharia Elétrica da Escola Politécnica de

Pernambuco.

SERVIÇOS INTEGRADOS E DIFERENCIADOS PARA REDES

DE BANDA LARGA

Denison Genuino Vieira

Maio/2009

Orientador: André Ricardson Gomes e Silva, Mestre.

Área de Concentração: Sistemas de Telecomunicações.

Palavras-chave: Qualidade de serviço, Serviços integrados, Serviços diferenciados.

Número de Páginas: 52

O presente trabalho aborda um assunto muito atual, a utilização das redes de

computadores de banda larga para aplicações de tempo real, tais como a disponibilização de

vídeo streaming. Para utilização de aplicações deste tipo, no modelo que foi desenvolvido a

Internet, é necessária adequação de alguns parâmetros, pois devido a alta “concorrência” pela

largura de banda disponível para acesso a rede WAN, muitas vezes estas aplicações são

demasiadamente prejudicadas. Estes itens que definem se o serviço disponibilizado é, ou não,

de boa qualidade são denominados os parâmetros de QoS (Qualidade de Serviço). Os recursos

devem ser garantidos para que o serviço seja executado de forma satisfatória, para isso são

utilizados os serviços integrados e dos serviços diferenciados. Os estudos verificam que a

implementação dos serviços integrados apesar de garantir os recursos requeridos pela

aplicação, é inviável para aplicação em grandes redes, como a internet. Devido a esta

limitação, os serviços diferenciados foram implementados nas simulações realizadas. Para que

fossem verificados os efeitos da “disputa” pelo tráfego, foi simulado a disponibilização de um

vídeo streaming e ao mesmo tempo a transferência de uma arquivo sem a implementação de

serviço diferenciado e posteriormente foi realizada a mesma simulação sendo com o serviço

diferenciado implementado e os resultados dos testes foram comparados.

3

Abstract of Dissertation presented to UPE.

SERVICES INTEGRATED AND DIFFERENTIATED FOR NETWORK OF BROAD BAND

Denison Genuino Vieira

May/2009

Supervisor: André Ricardson Gomes e Silva, Msc

Area of Concentration: Systems of telecommunications

Keywords: Quality of service, Integrated services, Differentiated services.

Number of Pages: 52

The present work brings up a very actual subject, the usage of broadband computer

networks for real time applications, such as the availability of video streaming. To use this

kind of application, in the model the internet was developed, the adaptation of some

parameters is required, due to high "competition" over available bandwidth to access WAN

network, these applications are, many times, severely damaged. The items that define if the

available service has or has not a good quality are called QoS parameters (Quality of Service).

To have a satisfactory service execution, the resources should be guaranteed, and for that

happens, the integrated services and the differentiated services are used. Studies confirm that

the integrated services implementation, despite of ensure the required resources for the

application, is impractible in networks, as internet. Because of this limitation, the

differentiated services were implemented in performed simulations. To verify the traffic

“dispute” effects, it was simulated the disponibilization of a video streaming and at the same

time the file transfer without the differentiated service implementation and posteriorly the

same simulation was executed with differentiated service implementation and the tests results

were compared.

4

LISTA DE SIGLAS

ABR - Available Bit Rate

ADSL - Asymmetric Digital Subscriber Line

AF - Assured Forwarding

ATM - Asynchronous Transfer Mode

CAC - Connection Admission Control

CBR - Constant Bit Rate

DSCP - DiffServ Code Point

DSL - Digital Subscriber Line

EF - Expedited Forwarding

FIFO - First In First Out

FTTB - Fiber to the Building

FTTC - Fiber to the Curb

FTTH - Fiber to the Home

FTTN - Fiber to the Node

HDSL - High bit-rate Digital Subscriber Line

HFC - Hybrid Fiber Coax

IDSL - Integrated Service Digital Network Digital Subscriber Line

IEEE - Institute of Electrical and Electronic Engineers

IETF - Internet Engineering Task Force

IP - Internet Protocol

LAN - Local Área Network

MAN - Metropolitan Area Network

PHB - Per Hop Behavior

PQ - Priority Queuing

QoS - Quality of Service

RED - Random Early Detection

RIO - RED for In and Out

RSVP - Resource Reservation Protocol

RTP - Real-time Transfer Protocol

SDSL - Symmetric Digital Subscriber Line

SLA - Service Level Agreement

5

STM - Synchronous Transport Module

STP - Shielded Twisted Pair

TOS - Type of Service

UBR - Unspecified Bit Rate

UPC - Usage Parameter Control

UTP - Unshielded Twisted Pair

VBR - Variable Bit Rate

VDSL - Very high bit-rate Digital Subscriber Line

VoIP - Voice over Internet Protocol

WAN - Wide Area Network

WFQ - Weighted Fairness Queueing

WRED - Weighted Random Early Detection

6

LISTA DE FIGURAS

Figura 2.1 – Arquitetura HFC ................................................................................................. 13 Figura 2.2 – Arquitetura FTTX ............................................................................................... 15 Figura 2.3 – Largura de banda x Distância – ADSL............................................................... 16 Figura 4.1 – Funcionamento do RSVP.................................................................................... 26 Figura 4.2 – Probabilidade de descarte do RED...................................................................... 32 Figura 4.3 – Probabilidade de descarte do RIO....................................................................... 33 Figura 5.1 – Arquitetura da rede de simulação........................................................................ 34 Figura 5.2 – NetMeeting ......................................................................................................... 35 Figura 5.3 – Interoperabilidade entre o campo TOS e o DSCP .............................................. 35 Figura 5.4 – Captura dos pacotes realizada pelo software Wireshark..................................... 36 Figura 5.5 – Log das políticas de envio de pacotes interface serial 0/0/0 do roteador com o envio de imagens sem “concorrência” pela banda passante disponibilizada ........................... 39 Figura 5.6 – Imagem do software Shunra VE desktop após a execução do teste de simulação sem tráfego concorrente............................................................................................................ 40 Figura 5.7 – Banda passante verificada na interface ethernet do microcomputador gerador do vídeo ......................................................................................................................................... 41 Figura 5.8 – Log das políticas de envio de pacotes interface serial 0/0/0 do roteador com o envio de imagens com “concorrência” pela banda passante disponibilizada e sem QoS......... 42 Figura 5.9 – Imagem do software Shunra VE desktop após a execução do teste de simulação com tráfego concorrente e sem priorização do tráfego com DSCP CS3.................................. 43 Figura 5.10 – Maior valor do jitter .......................................................................................... 43 Figura 5.11 – Banda passante verificada na interface ethernet do microcomputador gerador do vídeo com a transferência do arquivo de teste..................................................................... 44 Figura 5.12 – Log das políticas de envio de pacotes interface serial 0/0/0 do roteador com o envio de imagens com “concorrência” pela banda passante disponibilizada e com QoS ........ 47 Figura 5.13 – Imagem do software Shunra VE desktop após a execução do teste de simulação com tráfego concorrente e com priorização do tráfego com DSCP CS3 ................................. 48 Figura 5.14 – Log das políticas de envio de pacotes interface serial 0/0/0 do roteador com o envio de imagens com “concorrência” pela classe class-default.............................................. 49 Figura 5.15 – Banda passante verificada na interface ethernet do microcomputador gerador do vídeo com a transferência do arquivo de teste..................................................................... 49

7

LISTA DE TABELAS

Tabela 2.1 – Transmissão Ethernet.......................................................................................... 17 Tabela 3.1 – Vazão de aplicações multimídia ......................................................................... 20 Tabela 3.2 – Aplicações x Sensibilidade aos parâmetros de QoS........................................... 22 Tabela 5.1 – Descrição dos comandos inseridos no roteador.................................................. 38 Tabela 5.2 – Descrição dos comandos inseridos no roteador.................................................. 46 Tabela 5.3 – Análise dos resultados ........................................................................................ 50

8

SUMÁRIO

1. INTRODUÇÃO .......................................................................................................... 9 1.1. MOTIVAÇÃO ................................................................................................... 10 1.2. OBJETIVOS ......................................................................................................10 1.3. METODOLOGIA .............................................................................................. 10 1.4. ESTRUTURA DO DOCUMENTO.................................................................. 11

2. ESTRUTURA DE REDES DE BANDA LARGA ................................................. 12 2.1. TECNOLOGIAS DE ACESSO........................................................................ 12 2.1.1 PAR TRANÇADO........................................................................................... 12 2.1.2 HFC................................................................................................................... 13 2.1.3 FTTX ................................................................................................................ 14 2.2. TECNOLOGIAS DE TRANSPORTE ............................................................ 15 2.2.1. TECNOLOGIA XDSL ................................................................................... 15 2.2.2. ETHERNET.................................................................................................... 17 2.2.3 ATM.................................................................................................................. 18

3. REQUISITOS DE APLICAÇÕES DE TEMPO REAL ....................................... 20 3.1 PARÂMETROS DE QUALIDADE DE SERVIÇO ........................................ 20 3.1.1 LARGURA DE BANDA ................................................................................. 20 3.1.2 LATÊNCIA ......................................................................................................21 3.1.3 JITTER............................................................................................................. 21 3.1.4 CONFIABILIDADE ........................................................................................ 22

4. SERVIÇOS INTEGRADOS E DIFERENCIADOS.............................................. 23 4.1 SERVIÇOS INTEGRADOS.............................................................................. 23 4.1.1 RSVP................................................................................................................. 24 4.1.2 CLASSIFICAÇÃO DOS PACOTES............................................................. 26 4.1.3 AGENDAMENTO DOS PACOTES.............................................................. 26 4.1.4 DESVANTAGENS DO INTSERV................................................................ 27 4.2 SERVIÇOS DIFERENCIADOS....................................................................... 27 4.2.1 ROTEADORES DA REDE DIFFSERV....................................................... 28 4.2.2 PHB – ENCAMINHAMENTO EXPRESSO ................................................ 29 4.2.3 PHB – ENCAMINHAMENTO ASSEGURADO ......................................... 29 4.2.4 CONTROLE DE DESCARTE DOS PACOTES.......................................... 30 4.2.4.1 RED................................................................................................................ 30 4.2.4.2 WRED............................................................................................................ 31 4.2.4.3 RIO (RED FOR IN AND OUT).................................................................. 31 4.2.5 DESVANTAGENS DIFFSERV..................................................................... 32

5. AVALIAÇÃO DA REDE COM DIFERENCIAÇÃO DO TRÁFEGO A TRAVÉS DO DSCP.............................................................................................................................. 33

5.1 TESTE DE ENVIO DE VÍDEO STREAMING SEM NENHUM TR ÁFEGO ADICIONAL NA REDE .......................................................................................... 36 5.2 SIMULAÇÃO DO ENVIO DO VÍDEO STREAMING COM TRÁFE GO ADICIONAL NA REDE SEM DIFERENCIAÇÃO DO TRÁFEGO ................. 41 5.3 SIMULAÇÃO DO ENVIO DO VÍDEO STREAMING COM TRÁFE GO ADICIONAL NA REDE COM PRIORIZAÇÃO DO TRÁFEGO DE VÍD EO. 44 5.4 CONCLUSÃO DAS SIMULAÇÕES REALIZADAS .................................... 50 5.5 SUGESTÕES PARA TRABALHOS FUTUROS............................................ 50

6. REFERÊNCIAS BIBLIOGRÁFICAS ................................................................... 52

9

1. INTRODUÇÃO

As redes de computadores foram projetadas, inicialmente, visando apenas a

transmissão de dados que não exigia parâmetros rígidos de latência, jitter, largura de banda

disponível. Com o passar do tempo, foi verificado que elas poderiam ser utilizadas para outros

fins, tais como tráfego de voz e imagem, que exigem parâmetros bastante rígidos de latência,

jitter, largura de banda e confiabilidade de entrega dos pacotes. O principal protocolo

utilizado para transmissão de dados nas redes de computadores é o Protocolo Internet (IP -

Internet Protocol) e, como outras tecnologias de redes de pacotes, foram construídas para

transportar dados, mas não voz ou vídeo. A principal função do IP é a garantia de integridade

dos pacotes de dados que são entregues o mesmo não garante importantes pré-requisitos para

aplicações de tempo real, como a seqüência correta dos pacotes, a perda, nem mesmo o atraso

máximo permitido.

De acordo com Tanenbaum [12] as principais exigências para aplicações de tempo real

são as seguintes:

- Largura de banda

- Latência

- Jitter (Variação do atraso)

- Confiabilidade

A largura de banda é um parâmetro em que a sua principal região de problema está no

último trecho da rede de acesso entre o usuário final e a concessionária provedora do serviço

de comunicação de dados/voz, e a latência, jitter e confiabilidade, são parâmetros que serão

afetados por todos os componentes da rede.

Depois que foram definidos quais parâmetros deveriam ser analisados para que a

estrutura atual de comunicação de dados pudesse, a força tarefa de engenharia na internet

(IETF - Internet Engineering Task Force) desenvolveu os serviços integrados, que é um

serviço que analisa os parâmetros para aplicações de tempo real e outros serviços prioritários

de forma que os mesmos sejam atendidos de forma satisfatória. Mas devido a sua arquitetura,

os serviços integrados, não eram ideais e não eram passíveis de aplicações em redes muito

grandes, tais como a Internet.

Visando solucionar o problema apresentado pela arquitetura de serviços integrados, o

IETF apresentou os serviços diferenciados, que foram desenvolvidos tendo em vista a sua

aplicação em redes de grandes dimensões.

10

1.1. MOTIVAÇÃO

Com o crescente uso de aplicações de tempo real, tanto em rede de comunicação

corporativa, quanto na Internet, e devido ao aumento do desempenho das redes de

computadores, algumas aplicações de tempo real como videoconferência e telefonia IP

tornaram-se acessível para o usuário comum, de forma que podem ser realizadas reuniões de

trabalho, vídeo-aula da sua própria casa, sem a necessidade de equipamentos caros e restritos

como antes. Porém ao compartilhar a rede com diversas aplicações, algumas aplicações que

são mais sensíveis a atrasos, jitter, e que exigem uma maior largura de banda serão mais

prejudicadas em casos de congestionamentos. As aplicações de tempo real serão as que irão

sofrer os maiores prejuízos nestes casos, e para isso o seu tráfego deve ser diferenciado dos

demais de forma que mesmo com a rede sobrecarregada o usuário obtenha o desempenho

esperado.

1.2. OBJETIVOS

O estudo a ser realizado irá realizar comparações de algumas aplicações de tempo real,

em diferentes estruturas de redes de computadores e com a implantação e não-implantação de

qualidade de serviço (QoS - Quality of Service) para que seja analisada a diferença dos

parâmetros diferenciados solicitados pelas aplicações de tempo real, de forma que um usuário

comum possa ver o estudo e analisar se a estrutura da sua rede atende ou não a determinadas

aplicações de tempo real.

1.3. METODOLOGIA

A metodologia adotada na descrição deste pré-projeto foi baseada em sua maior parte

em pesquisa de artigos científicos, monografias e teses de mestrado disponibilizadas na

Internet, principalmente no capítulo referente a serviços integrados e diferenciados, pois é um

assunto ainda restrito em livros.

Os capítulos referentes a estrutura de redes de banda larga e requisitos de aplicação de

tempo real foram baseados tanto em artigos científicos, monografias e teses de mestrado

disponibilizadas na Internet, quanto em livros, pois se trata de um assunto já bastante

abordado.

11

1.4. ESTRUTURA DO DOCUMENTO

O documento será descrito em quatro capítulos que seguem os tópicos abaixo:

- Capítulo 1 – Introdução – Realiza uma descrição geral de todo o trabalho.

- Capítulo 2 - Estrutura de Redes de Banda Larga – O capítulo apresentará as

principais tecnologias de acesso físico das redes de banda larga e as tecnologias de

transporte das redes de banda larga.

- Capítulo 3 - Requisitos de Aplicações de Tempo Real – O capítulo explicará as

definições dos parâmetros das aplicações de tempo real, e a influência delas nas

aplicações.

- Capítulo 4 - Serviços Integrados e Diferenciados – O capítulo mostrará a estrutura

dos dois serviços analisando as suas aplicações.

- Capítulo 5 – Avaliação da Rede com diferenciação do Tráfego Através do DSCP

– Neste capítulo serão apresentados os testes realizados e os resultados.

12

2. ESTRUTURA DE REDES DE BANDA LARGA

Um fator determinante para o fornecimento de banda larga para usuários finais, é a

arquitetura da chamada última milha. A última milha é o trecho que interliga a central da

concessionária de telecomunicações ao usuário final, e em muitos casos temos um

estreitamento da banda passante, o dificulta, e até muitas vezes impede a execução de serviços

que demandam uma grande largura de banda.

Neste capítulo serão expostas as principais tecnologias de acesso físico e de transporte

das redes de banda larga.

2.1. TECNOLOGIAS DE ACESSO

2.1.1 PAR TRANÇADO

O par trançado é a principal forma de acesso das operadoras aos usuários residenciais

para a entrega de circuitos de voz e Linha digital de Assinante (DSL - Digital Subscriber

Line). Os cabos metálicos de cobre, com proteção dielétrica entre os condutores, são

entrelaçados para diminuir a interferência eletromagnética. Em circuitos de comunicação de

dados a taxa de transferência a ser atingida dependerá diretamente do diâmetro interno do

condutor, pois quanto maior a secção transversal menor será a atenuação e da distância do

cliente ao último equipamento ativo de transmissão da concessionária.

Os cabos de pares trançados também são utilizado em pequenas distâncias, atingindo

velocidades mais altas, como é no caso das redes Rede de Área Local (LAN - Local Área

Network).

Temos dois tipos de cabos de pares trançados utilizados em ambiente LAN, o Par

Trançado sem Blindagem (UTP - Unshielded Twisted Pair) é formado por oito condutores

divididos em quatro pares, e o Par Trançado com Blindagem (STP - Shielded Twisted Pair)

que tem estrutura semelhante com a diferença que no cabo STP em cada par temos uma

blindagem para proteção eletromagnética.

Os cabos STP podem ser utilizados em redes 10Gigabit Ethernet, tecnologia de

interconexão de redes, em distâncias até 100m o que gera uma ótima relação custo-benefício,

pois o cabo tem preço relativamente baixo e fácil instalação.

13

2.1.2 HFC

A arquitetura Híbrida Fibra e Coaxial (HFC - Hybrid Fiber Coax), surgiu da

necessidade do aumento de banda passante e melhora da qualidade dos serviços prestados

pelas empresas que fornecem TV a cabo. Este aumento de banda foi ocorrido devido ao

aumento de números de assinantes do sistema. A tecnologia HFC utiliza a alta taxa de

transmissão da fibra óptica, com o custo baixo do cabo coaxial.

O sistema funciona da seguinte forma:

- O sinal segue do provedor até um local chamado nó óptico através de fibra óptica;

- No local do nó, é instalado um conversor óptico-elétrico;

- Depois o sinal elétrico é levado através de cabo coaxial para atender uma legião de

assinantes;

- Próximo à casa do assinante é derivado um sinal da fibra para atendê-lo.

A Figura 2.1 ilustra a arquitetura HFC.

Figura 2.1 Arquitetura HFC

A estrutura é parecida com a Fibra até a Calçada (FTTC - Fiber to the Curb), sendo

que no HFC um cabo coaxial é utilizado para atender diversos assinantes, o circuito não é

individual, enquanto na arquitetura FTTC sim.

A alta taxa de transmissão alcançada é devido ao fato de boa parte do trajeto ser

utilizado fibra óptica. O HFC também é utilizado para disponibilizar acesso à internet em

altas taxas de transmissão, compatíveis com aplicações multimídia, tais como voz e vídeo.

14

As velocidades atingidas podem ser da ordem de 10 Mbps para downstream e 760

Kbps para upstream. [1]

2.1.3 FTTX

A Fibra até “X” (FTTX - Fiber to the) serve para designar uma série de tipos de

acessos que são baseados na utilização de fibra óptica. O campo da letra “X” servirá para

designar qual o tipo de FTT da rede, que informará até que ponto chegará o sinal óptico.

Temos a estrutura FTTH (Fiber to the Home – Fibra até a Casa), na qual a sua

arquitetura é baseada numa rede em que todo o acesso, desde a central de comutação até a

casa/escritório do cliente, é feito através de fibra óptica. Esta arquitetura está em grande fase

de expansão, principalmente na Ásia, conforme dados da Cisco citados em estuda realizado

pela [2] em 2006. Os padrões de transmissão utilizados em redes FTTH são baseados no

protocolo Modo de Transferência Assíncrono (ATM - Asynchronous Transfer Mode) e

tecnologias da Ethernet. [3]

Também pode ser citada a arquitetura Fibra até o Edifício (FTTB - Fiber to the

Building), na qual o sinal óptico chega até a entrada de um condomínio/edifício, e

internamente o sinal, na maioria dos casos, é distribuído através de cabeamento estruturado

utilizando protocolo Ethernet, com cabos UTP de categoria no mínimo 5 devido às altas

velocidades utilizadas, até o equipamento final. Devido às distâncias internas serem

relativamente pequenas, esta arquitetura apresenta um bom desempenho.

As arquiteturas FTTC e Fibra até o Nó (FTTN - Fiber to the Node) têm estruturas

semelhantes, são redes mistas, e podemos dividi-la em duas partes, no primeiro trecho entre a

concessionária e cliente o acesso é através de fibra óptica, terá um armário de distribuição e

nele será feita a conversão de sinal elétrico para óptico, para que no segundo trecho seja

utilizada malha metálica. As estruturas das arquiteturas FTTX são mostradas na Figura 2.2.

A diferença entre o FTTC e o FTTN é no que diz respeito ao comprimento deste

trecho. No FTTC a distância dos armários de distribuição fica a menos de 1.524m dos

assinantes, e para distâncias maiores a arquitetura é denominada FTTN.

15

Figura 2.2 Arquiteturas FTTX

2.2. TECNOLOGIAS DE TRANSPORTE

2.2.1. TECNOLOGIA XDSL

A sigla xDSL é utilizada de forma genérica para definir uma série de serviços que

utiliza a tecnologia DSL.

Com esta tecnologia temos os serviços:

- Rede Digital de Serviços Integrados Linha Digital do Assinante (IDSL - Integrated

Service Digital Network Digital Subscriber Line);

- Linha Digital do Assinante Simétrica (SDSL - Symmetric Digital Subscriber Line);

- Linha Digital do Assinante com Alta taxa de bit (HDSL -High bit-rate Digital

Subscriber Line);

- Linha Digital do Assinante Assimétrica (ADSL - Asymmetric Digital Subscriber

Line);

- Linha Digital do Assinante com Muito Alta taxa de bit (VDSL - Very high bit-rate

Digital Subscriber Line).

16

A tecnologia ADSL foi uma forma encontrada de utilizar a malha metálica, já

existente, entre o usuário final e a concessionária de telecomunicações, para a transmissão de

dados em altas velocidades. Para utilizar o mesmo meio para serviços distintos, o serviço

determina faixas de freqüências diferenciadas para cada um. Para o canal de voz 0 – 4 KHz,

upstream 16 – 640 KHz e para downstream 1,5 – 6,1 MHz. Desta forma é possível atingir

velocidades de até 8 Mbps para downstream e 640 Kbps para upstream.

Um grande dificultador da tecnologia ADSL é a limitação da velocidade em função da

distância, pois ele decresce com a distância do cliente da central de comutação da

concessionária de telecomunicações conforme a Figura 2.3.

Figura 2.3 Largura de Banda x Distância - ADSL

O que também pode ser verificado no gráfico é que, quanto maior o diâmetro dos

cabos condutores, distância a ser atendida por uma determinada velocidade é maior, isso é

devido à atenuação/Km neste cabo ser menor.

Dentre os serviços XDSL, a ADSL é a mais difundida, devido a suas características

assimétricas de upstream e downstream, a distância atingida e utilizar apenas um par de fios.

Esta tecnologia é a atualmente mais empregada no acesso à banda larga para usuários

residenciais no Brasil [2].

17

2.2.2. ETHERNET

O padrão ethernet, conforme Instituto de Engenheiros Eletricistas e Eletrônicos (IEEE

- Institute of Electrical and Electronic Engineers) 802.3, foi desenvolvido para atender a

demanda crescente para comunicações entres dispositivos de uma mesma LAN. As redes

ethernet de mais baixa velocidade padronizadas pela IEEE e tinham taxa de transmissão de

1Mbps, e em sua evolução apresenta as seguintes características, a cada nova versão, sua

velocidade aumenta num fator 10, e mantêm compatibilidade com os equipamentos da versão

anterior. Sendo que em alguns pontos da rede, onde os equipamentos não foram atualizados

para a versão mais nova, 10 vezes mais rápida, ela continuará a trafegar na velocidade

anterior. Com o passar do tempo às aplicações foram gerando um maior tráfego de pacotes e

consequentemente exigindo maior largura de banda, tanto para as redes locais quanto para os

backbones. Depois da Ethernet veio o padrão Fast Ethernet, com velocidade de 100Mbps, e

posteriormente o Gigabit Ethernet com taxa de 1Gbps, até os atuais 10 Gigabit Ethernet com

taxa de 10Gbps.

Devido ao grande aumento da taxa de transmissão do padrão ethernet, passando a ser o

Gigabit ethernet, e devido a inovações nos meios de transmissão, iniciando pelo cabo coaxial,

passando pelo cabo UTP e chegando até a fibra óptica, as distâncias que podem ser atendidas

pelo ethernet foram se tornando maiores, de forma que o padrão também passou a ser

utilizado em rede de área metropolitana (MAN - Metropolitan Area Network) e rede de longa

distância (WAN - Wide Area Network), de acordo com a possibilidade da distância da rede

conforme a Tabela 2.1.

Tabela 2.1 Transmissão Ethernet

Ethernet 10Base-T Fast Ethernet

100Base-T

Gigabit Ethernet

1000Base-X

Taxa de transmissão 10Mbps 100Mbps 1Gbps

Fibra Multímodo 2 km 412m (half duplex)

2Km (full duplex)

500m

Fibra Monomodo 25 km 20 km 3 km

STP / Coaxial 500m 100m 25m

UTP Cat. 5 100m 100m 100m

18

A interface 10GBase-EW, 10Gbps, pode ter enlaces de até 40 km, sendo também

utilizada para WAN.

O padrão Gigabit ethernet não foi planejado para implementar QoS, para compensar

este problema foram implementados os padrões 802.1q, que permite a criação de LAN Virtual

(VLAN - Virtual LAN), e o 802.1p que permite priorizar determinado tráfego na rede.

As VLAN são fragmentos de uma LAN já existente, e são criadas para que possam ter

regras específicas de encaminhamento de pacotes, como no caso de implantação do padrão

802.1p.

2.2.3 ATM

Antes do ATM, a principal tecnologia utilizada para a transmissão de dados através de

backbones era realizada através de circuitos módulo de transporte síncrono

(STM − Synchronous Transport Module), que é uma tecnologia que utiliza a comutação por

circuitos, neste tipo de comutação os circuitos de comunicação ficam sempre disponíveis para

aquela configuração que foi definida inicialmente, como uma linha de telefone fixo, aquele

circuito sempre está disponível para aquele mesmo assinante esteja ele utilizando ou não, o

que não otimiza a utilização de banda, pois, o sistema não pode alterar a utilização da mesma

de forma dinâmica, e não foi desenvolvida para ser utilizada em comunicações multimídia

utilizadas hoje de forma crescente.

O surgimento da tecnologia ATM, nasceu da necessidade de um padrão para ser

utilizado principalmente em circuitos de backbone, no qual a comutação fosse por pacotes,

neste tipo de comutação, o circuito só será disponibilizado para a transmissão quando for

realmente solicitado, enquanto não é utilizado a banda está disponível para transmissão, por

isso a banda é utilizada de forma otimizada, e se torna uma arquitetura escalável. A

escalabilidade é uma propriedade que a arquitetura tem de pode processar novas atividades e

mantê-las com desempenho satisfatório.

Este modo de transmissão foi desenvolvido com o objetivo de atender a demandas

existentes que não eram atendidas, de forma satisfatória, pelos circuitos com a tecnologia

STM, o qual tinha como principais restrições à falta de escalabilidade, utilização de banda

estática e não era prevista para ser utilizadas em serviços multimídia.

Para atender os requisitos de QoS de diversas aplicações utilizados em grande escala

hoje, os circuitos ATM classificam os fluxos em cinco categorias principais com relação às

suas demandas de QoS [4]:

19

• Taxa de Bit Constante (CBR - Constant Bit Rate);

• Taxa de Bit Variável (VBR - variable bit rate) tempo real;

• Taxa de Bit Variável (VBR - variable bit rate) não tempo real;

• Taxa de Bit Disponível (ABR - available bit rate);

• Taxa de Bit Não específica (UBR - unspecified bit rate).

De acordo com cada categoria citada, os circuitos são configurados de forma dinâmica

dentro da rede ATM, atendendo todos os seus requisitos de QoS, largura de banda, latência,

jitter.

Apesar de ser uma arquitetura considerada escalável, como todo sistema ele apresenta

seus limites, e neste caso os o sistema utiliza três mecanismos para gerenciar o alto tráfego:

- Alocação de Recursos – O sistema realiza um controle rígido dos controles de

armazenamento, buffers, e da banda disponível, de forma que caso os mesmos não

estejam disponíveis, ele recusará novas conexões;

- Controle de Parâmetro de Usuário (UPC - Usage Parameter Control) – Quando o

processo indica este estado, os equipamentos situados nas extremidades da rede ficam

impossibilitados de gerar novos tráfegos até que este parâmetro seja desabilitado;

- Controle de Admissão de Conexão (CAC - Connection Admission Control) – Este

parâmetro indicará quando o sistema poderá aceitar novas conexões, de forma que as

existentes não sejam prejudicadas.

20

3. REQUISITOS DE APLICAÇÕES DE TEMPO REAL

Com o advento das redes de banda larga, tornou-se possível a implementação de

aplicações de tempo real.

As principais aplicações de tempo real em redes de computadores são a tele-medicina,

tele-educação, vídeo-conferência, voz sobre protocolo internet (VoIP - Voice over Internet

Protocol), tais serviços exigem da rede uma grande banda passante, alta capacidade de

processamento dos roteadores, switches, computadores, e altos requisitos de QoS , de forma

que sejam disponibilizados de forma satisfatória.

3.1 PARÂMETROS DE QUALIDADE DE SERVIÇO

Visando atender as aplicações multimídia, foram analisados os principais parâmetros

que impactam no desempenho das mesmas. Nos próximos itens estes parâmetros serão

definidos.

3.1.1 LARGURA DE BANDA

A largura de banda é a capacidade que um circuito de comunicação tem de enviar os

dados na rede. Esta é expressa em Kilo bit por segundo (Kbps) [12].

Quando uma rede for dimensionada, este parâmetro irá basear-se nos tipos de

aplicações que serão utilizados, devido a cada tipo de serviço necessitar de uma vazão

específica, conforme cita [5] na Tabela 3.1.

Tabela 3.1 Vazão de aplicações multimídia

Aplicação Vazão (Típica)

Aplicações Transacionais 1 kbps a 50 kbps

Voz 10 kbps a 120 kbps

Aplicações Web (WWW) 10 kbps a 500 kbps

Vídeo (Streaming) 100 kbps a 1 Mbps

Aplicação Conferência 500 kbps a 1 Mbps

Vídeo MPEG 1 Mbps a 10 Mbps

Aplicação Imagens Médicas 10 Mbps a 100 Mbps

Aplicação Realidade Virtual 80 Mbps a 150 Mbps

21

3.1.2 LATÊNCIA

Latência é um parâmetro que indica o tempo total que um pacote leva desde sua

origem, transmissor, até o seu destino, receptor. Este atraso pode ser extremamente variável,

pois leva em conta toda a rota, o que significa que quanto maior à distância até o destino,

quase sempre, será maior o tempo de latência.

Segundo [5], os principais fatores que influenciam na latência de uma rede são os

seguintes:

- Atraso de propagação;

- Velocidade de transmissão;

- Processamento nos equipamentos.

O atraso de propagação é um parâmetro que não pode ser alterado, é intrínseco ao

meio, ele dependerá do material que for utilizado como meio de transmissão, fibra óptica,

cabo coaxial, satélite.

A velocidade de transmissão e processamento dos equipamentos são parâmetros que

podem ser mais bem dimensionados. Para alterarmos a velocidade de transmissão, deve ser

dimensionada uma taxa de transmissão do circuito de dados adequada, conforme citado no

item 3.1.1, e em relação ao processamento dos equipamentos, deve ser analisado o

dimensionamento da capacidade de processamento de todos os elementos da rede,

computadores, switches, roteadores, servidores.

3.1.3 JITTER

Jitter é a variação do tempo de latência dos pacotes de um determinado fluxo de dados.

Ele ocorre devido a desempenhos diferentes da rede, ocasionando esta variação da latência,

rotas diferentes utilizadas pelos pacotes, em caso em que se trafegue pela rede pública, e a

variação dos tempos de retenção dos protocolos utilizados por ela.

Em casos de valores muito altos de jitter, a ordem de entrega dos pacotes também

poderá ser alterada, o que em caso de aplicações de tempo real, torna-as inviáveis

tecnicamente. Nas aplicações de tempo real é mais aceitável um valor de latência alto, porém

constante, que um valor alto do jitter. Para resolver o problema de ordenamento dos pacotes,

são utilizados protocolos específicos de aplicações de tempo real, dentre eles o protocolo de

transferência de tempo real (RTP - Real-time Transfer Protocol). Para que as aplicações

possam funcionar adequadamente com pouco jitter, são implantados buffers nos

22

equipamentos, que são áreas na memória que ficam reservadas para armazenar os pacotes

antes de serem enviados para a interface com o usuário final.

3.1.4 CONFIABILIDADE

Outro problema para aplicações de tempo de real é a perda de pacotes. Elas ocorrem

nos roteadores e switches, devido à falha dos equipamentos e congestionamento,

principalmente em casos de rajadas, quando os roteadores tendem a realizar o descarte de

pacotes. As perdas de pacotes são muitas vezes efetuadas pelos próprios protocolos de

transporte, ethernet, ATM, que utilizam deste recurso para evitar ou não prolongar

congestionamentos.

Em VoIP, notamos que ocorreu perda de pacotes nos casos de metalização da voz, e

até silêncio na conversação, e em aplicações de vídeo vemos transições abruptas da imagem,

caracterizando descontinuidade dos pacotes recebidos.

A Tabela 3.2 informa o grau de criticidade de alguns parâmetro de QoS de diversos

tipos de aplicações em redes de computadores.

Pela Tabela 3.2, verificamos que as aplicações de tempo real apresentadas, voz e

vídeo-conferência, são as únicas que são extremamente sensíveis ao parâmetro Jitter, variação

da latência de entrega dos pacotes, pois com esta diferença uma conversa, reunião, não se

torna inteligível.

Tabela 3.2 Aplicações x Sensibilidade aos parâmetros de QoS

Tipo de Tráfego Vazão Perdas Latência Jitter

Voz Muito Baixa Média Alta Alta

Comércio eletrônico Baixa Alta Alta Baixa

Transações Baixa Alta Alta Baixa

Correio Eletrônico Baixa Alta Baixa Baixa

Acesso Remoto (Telnet) Baixa Alta Média Baixa

Navegação web Baixa Média Média Baixa

Navegação web (crítica) Média Alta Alta Baixa

Transferência de Arquivos Alta Média Baixa Baixa

Vídeo-conferência Alta Média Alta Alta

23

4. SERVIÇOS INTEGRADOS E DIFERENCIADOS

Com a definição dos parâmetros de QoS, a próxima questão a ser analisada era como

implementar um serviço que pudesse diferenciar um tráfego que exigia um tratamento

diferenciado, de um que não exigia tal condição.

Para solucionar a questão o IETF apresentou duas propostas para atender a serviços

que exigem diferentes níveis de QoS, os serviços integrados (IntServ) e os serviços

diferenciados (DiffServ) [9].

A arquitetura de serviços integrados utiliza-se de alocação prévia de largura de banda,

capacidade de processamento e memória de todos os roteadores envolvidos no fluxo de dados

que é exigido por aquela determinada aplicação. Para efetuar toda estas reservas de recursos,

esta arquitetura utiliza um protocolo específico o Protocolo de Reserva de Recursos (RSVP -

Resource Reservation Protocol). Pelo fato desta arquitetura reservar recursos de largura de

banda, processamento e memória, ela se torna inviável em grandes redes devido a sua falta de

escalabilidade [8].

Devido aos problemas de escalabilidade verificado na arquitetura InteServ o IETF

apresentou a arquitetura de serviços diferenciados (DiffServ). Diferentemente da estrutura

IntServ, que utiliza um protocolo específico, o RSVP como base de sua estrutura, o DiffServ

se baseia em uma arquitetura já existente, como o campo Tipo de Serviço (TOS - Type of

Service) tem seus 6 bits mais significativos agora chamado de campo DSCP (DiffServ Code

Point) [11], existente em todo pacote da rede IP, é utilizado para determinar a prioridade que

deve ser dada aquele serviço, e outra característica da arquitetura DiffServ é analisar a

quíntupla (IP fonte, IP destino, protocolo, porta de origem, porta de destino), de forma a tratar

os dados a serem transmitidos como um agregado de fluxo e não um fluxo individual, com

isso grande parte dos problemas de escalabilidade, verificados na arquitetura IntServ, podem

ser resolvidos. Deve ser citado que, diferentemente da arquitetura IntServ, nenhum protocolo

realiza reserva prévia de banda para as aplicações prioritárias, com isso o dimensionamento

das velocidades dos circuitos de comunicação deve ser analisado de forma mais criteriosa

pelos administradores da rede.

4.1 SERVIÇOS INTEGRADOS

Na arquitetura IntServ temos quatro componentes essenciais, o escalonador de pacotes

que irá implantar a política de filas dos pacotes a serem transmitidos, o classificador (que

24

classificará os pacotes de acordo com sua porta), protocolo e endereço de destino, o controle

de admissão (que definirá se um novo fluxo de dados poderá ser aceito, isto se as condições

de QoS solicitadas por ele poderão ser implementado na rede), e o protocolo de reserva de

recurso, que irá realizar a reserva dos recursos de capacidade de processamento e memória

dos roteadores envolvidos no trajeto do fluxo de dados e a largura de banda solicitada. Na

teoria qualquer protocolo de reserva de recurso que atenda aos requisitos citados pode ser

implementado, mas na prática é utilizado o RSVP como padrão estabelecido pelo IETF.

O IntServ implementa mais dois tipos de serviços além do melhor esforço, o serviço

garantido e o de carga controlada.

O serviço garantido deve ser implementado para aplicações nas quais a variação do

tempo de chegada dos pacotes, jitter, não é fator preponderante, mas o que é fundamental é o

tempo máximo de entrega destes pacotes, latência, seja o menor possível. Neste tipo de

serviço o protocolo RSVP além de alocar previamente largura de banda também fornece

limites rígidos (matematicamente prováveis) em relação a atrasos de enfileiramento [6].

O serviço de carga controlada administra os pacotes, de forma que cheguem ao destino

com o menor jitter possível, mas o tempo máximo de entrega dos dados, latência, não é

fundamental. O comportamento fim-a-fim oferecido por este serviço é semelhante ao

comportamento visto por aplicações que estão recebendo o serviço de “melhor esforço” em

uma rede apenas “levemente” carregada [6]. O atraso absoluto não é especificado, mas as

flutuações devem ser as menores possíveis, já que os buffers de um roteador de uma rede

pouco carregada estão praticamente vazios [7].

4.1.1 RSVP

Antes que o protocolo de reserva de recurso comece a realizar sua tarefa, existe a

rotina de controle de admissão dos pacotes a serem transmitidos.

O controle na admissão dos pacotes é uma atividade simples, será verificado quais os

requisitos de largura de banda exigido por aquele pacote, se a disponibilidade de banda for

suficiente para atender aquela demanda o pacote é aceito, caso contrário o pacote será

descartado.

Após feita a admissão do pacote, o RSVP irá realizar a reserva dos recursos

necessários para que a transmissão dos dados obedeça aos requisitos de QoS estabelecido

pelos dados e indicará junto com o protocolo de roteamento o melhor trajeto a ser utilizado

por aquele fluxo. O caminho designado pelo protocolo de roteamento não será

25

necessariamente o caminho mais curto, e sim o caminho que poderá exercer o melhor

desempenho sobre a aplicação solicitada.

O funcionamento do RSVP é feito da seguinte forma:

- O transmissor após verificar os requisitos de QoS exigidos pela aplicação irá definir,

junto com o protocolo de roteamento, o trajeto a ser seguido pelos pacotes;

- Após a verificação e determinação do trajeto, o RSVP envia uma mensagem, PATH,

para o próximo roteador contendo informações da rota a ser seguida e os requisitos de

QoS, largura de banda, latência e jitter, solicitados por aquele fluxo;

- Esta mensagem é passada para cada roteador até que o receptor a receba;

- Quando recebida pelo receptor, ele analisa os requisitos exigido pelo fluxo, e define

os parâmetros necessários para que ele possa ser atendido de forma satisfatória.

- Verificado que é possível a alocação dos recursos necessários, o receptor envia uma

mensagem de resposta, RESV, que irá percorrer o trajeto inverso da mensagem PATH,

com destino ao transmissor.

-Ao receberem a mensagem RESV, é que os roteadores reservam os recursos, largura

de banda, buffer, solicitados para o fluxo de dados.

- Quando o roteador mais próximo do transmissor receber a mensagem RESV é que se

inicia a transmissão dos pacotes.

Temos ainda a possibilidade de não ser possível à transmissão dos dados com o QoS

solicitado, neste caso o RSVP envia uma das mensagem de erro abaixo:

- Path-erro messages – enviada quando no envio de uma PATH ele não consegue

chegar ao destino. Esta mensagem é enviada ao transmissor;

- Reservation-request error messages – enviada para o receptor quando ocorre uma das

seguintes falhas, caminho ambíguo, largura de banda indisponível, problema na

admissão, serviço não suportável;

A Figura 4.1 mostra o funcionamento do RSVP.

Figura 4.1 Funcionamento do RSVP

26

Note que apesar da transmissora ter indicado os recursos necessários, quem solicita a

reserva na prática é a receptora, pois é ela quem vai avaliar a capacidade da rede entre as duas

máquinas [8].

4.1.2 CLASSIFICAÇÃO DOS PACOTES

A classificação dos pacotes será realizada levando-se em conta o endereço de destino,

a porta que ele utilizará e o protocolo, desta forma os pacotes serão marcados para que a

reserva de banda para transmissão possa ser reservada, e seja esta marcação também

determinará a prioridade no envio deles. Terminada a classificação os dados são enviados

para a fila de envio, de forma que sejam efetivamente transmitidos.

4.1.3 AGENDAMENTO DOS PACOTES

O último procedimento antes do envio dos pacotes é o gerenciamento da fila que será

formada no roteador.

O procedimento de gerenciamento de fila mais simples é o primeiro a entrar primeiro a

sair (FIFO - First In First Out), como a própria sigla cita, este sistema não define nenhuma

critério de prioridade no envio dos pacotes, eles serão enviados de acordo com a ordem de

chegada ao roteador, mesmo que eles estejam marcados com alguma prioridade [11].

Também temos a Fila de Prioridade (PQ - Priority Queuing), neste tipo de

gerenciamento de fila os pacotes são marcados com quatro níveis de prioridade, baixa,

normal, média e alta. Os dados que não receberem nenhum tipo de marcação serão

automaticamente definidos com prioridade normal. Na fila de prioridade, um pacote marcado

com prioridade acima de outro tem acesso a banda para o envio de forma indiscriminada, de

forma que numa situação em que tenha alguma aplicação que esteja enviado muitos pacotes

pela rede, esta pode ocupar toda a banda de transmissão, ocorrendo que aplicações de mais

baixa prioridade vão ter um tempo de latência muito elevado, este é um grande problema do

PQ.

Podemos citar o Fila Justa com Pesos (WFQ - Weighted Fairness Queueing), um

sistema de gerenciamento organiza diversas filas de acordo com um peso que foi atribuído

aquele pacote, o peso dado depende da classificação recebida por aquele pacote, este sistema

procura fazer com que todas as filas “andem” de acordo com o seu peso. As filas com maior

peso, maior prioridade, andarão mais rápida e as com menor peso, mais devagar, mas sempre

27

trafegarão. Este sistema tem um grande diferencial em relação ao PQ porque ele procura

distribuir a largura de banda disponível de forma justa, para que todas as aplicações

funcionem de forma satisfatória [10].

4.1.4 DESVANTAGENS DO INTSERV

Os principais problemas da arquitetura IntServ são os seguintes:

- Em todo fluxo de informação deverá ocorrer o controle realizado pelo protocolo de

reserva de recurso, isto para que o envio dos dados seja realizado no desempenho solicitado, e

com isso já ocorre uma sobre carga no número de informações enviadas na rede e no

processamento dos roteadores.

- Todos os equipamentos da rede, transmissores, roteadores e receptores, devem ter

implementado o protocolo de reserva de recurso, o controle de admissão, o classificador e o

sistema de gerenciamento de filas.

- A exigência de banda para transmissão, memória e processamento dos roteadores

cresce de forma proporcional com a quantidade de fluxos a serem enviados, isso faz com que

a arquitetura IntServ não seja escalável e consequentemente inviável para aplicação numa

rede do tamanho da internet.

4.2 SERVIÇOS DIFERENCIADOS

Devido à falta de escalabilidade encontrada pela arquitetura IntServ, o IETF

desenvolveu a arquitetura de serviços diferenciados, DiffServ.

O DiffServ apresenta uma arquitetura totalmente diferente da IntServ:

- Primeiramente não necessita de um protocolo específico para realizar a alocação

prévia de recursos da rede, largura de banda e processamento dos roteadores;

-A sua estrutura se baseia numa já existente e padrão adotado pela internet, o

protocolo IP.

No cabeçalho do pacote IP, temos um campo chamado DSCP, os 3 primeiros bits

deste campo formarão o IP Preferencial (IP Precedence), quanto maior o valor deste campo,

com maior prioridade ele será tratado, os 4 bits posteriores darão informações a respeito da

latência, vazão e a confiabilidade que a informação será entregue. Através da análise do

campo DSCP e da quíntupla (IP fonte, IP destino, protocolo, porta de origem, porta de

destino) o DiffServ tratará os pacotes a serem enviados, que contêm a mesma quíntupla e

28

DSCP, como um fluxo único, e não cada pacote de forma individualizada, como ocorre na

arquitetura IntServ, com isso é reduzida à solicitação de processamento dos roteadores

tornando a arquitetura escalável [10].

Esse conceito não assegura que as restrições de qualidade de serviço dos fluxos sejam

absolutamente garantidas, como feito nos protocolos de reserva fim-a-fim propostos na

arquitetura de Serviços Integrados, porém, permite que garantias de qualidade de serviço

sejam implementadas em redes com grande quantidade de nós [9].

Para minimizar a falta de garantia citada por [9], a arquitetura implementa uma acordo

de nível de serviço (SLA - Service Level Agreemen), que é uma negociação entre um roteador

de uma extremidade de um domínio DiffServ, com outro roteador de outra extremidade de

outro domínio DiffServ, desta forma eles informam um ao outro, os requisitos de QoS

solicitado por aquele fluxo de informação.

4.2.1 ROTEADORES DA REDE DIFFSERV

Os roteadores exercem papel fundamental no desempenho de uma rede de

computadores, e numa rede DiffServ eles são divididos em dois tipos, roteadores de borda, e

roteadores de núcleo.

Os roteadores de núcleo são todos os roteadores que estão dentro de uma mesma rede

DiffServ, e só tem conexões com contato com roteadores de borda e de núcleo do seu mesmo

domínio DiffServ. Eles só exercem a função de gerenciamento das filas.

Os roteadores de borda são todos os roteadores que se comunicam que estão dentro de

uma mesma rede DiffServ, e eles tem conexões com roteadores de núcleo da sua rede e com

roteadores de borda de outros domínios DiffServ. Os roteadores de borda terão uma

quantidade de atribuições bem maior do que os de núcleo, eles são responsáveis classificação,

marcação e policiamento do contrato de SLA estabelecidos entre os diferentes domínios

DiffServ [6].

Um dos grandes fatores que possibilita a arquitetura DiffServ ser escalável é o fato dos

roteadores terem serviços diferenciados em virtude de sua localização na rede.

O tratamento dado pelos roteadores aos pacotes recebidos são definidos pelo

comportamento por nó (PHB - Per Hop Behavior), que será definido de acordo com o campo

DSCP do cabeçalho do pacote IP. Temos dois tipos de PHB utilizados hoje em redes

DiffServ, o Encaminhamento Expresso e o Encaminhamento assegurado.

29

4.2.2 PHB – ENCAMINHAMENTO EXPRESSO

No comportamento por nó encaminhamento expresso, os pacotes marcados com este

tipo de encaminhamento terão seu envio totalmente assegurado, seus parâmetros de QoS, tais

como latência, jitter, largura de banda e descarte de pacotes, atendidos. Este tipo de

encaminhamento é ideal para aplicações de tempo real, como vídeo-conferência e VoIP. Uma

falha deste tipo de encaminhamento, é que caso os pacotes com marcação Encaminhamento

Expresso (EF - Expedited Forwarding) estejam em grande quantidade, eles podem ocupar

toda a banda de transmissão disponível, impossibilitando outras aplicações menos prioritárias

tenham acesso ao circuito. Uma forma de minimizar o problema de ocupação da banda por

parte das aplicações EF é a utilização de um procedimento de fila, tais como PQ e WFQ,

neste caso os pacotes que precisam de um QoS alto devem ser marcados com um peso bem

maior que as demais aplicações, de forma que elas tenham um acesso aos recursos da rede

bem maior, mas ao mesmo tempo não deixe as aplicações restantes sem possibilidade de

transmissão [11].

Neste caso também deve ser verificado os SLA acordados pelos roteadores de borda,

pois caso os EF solicitados pelos pacotes sejam maior que os contratados, os que forem

chegando posteriormente serão descartados a fim de evitar congestionamento nos roteadores

de borda para que os usuários restantes não sejam prejudicados [6].

4.2.3 PHB – ENCAMINHAMENTO ASSEGURADO

O PHB-EF não permite que os pacotes sejam marcados com níveis diferenciados de

importância de envio, para que isso seja possível é necessário implantar um gerenciador de

filas. No encaminhamento assegurado (AF - Assured Forwarding), os dados podem ser

marcados com 4 níveis diferentes de preferência de descarte. Em cada nível de descarte são

reservados recursos da rede para ele, largura de banda, buffer e processamento, ao receber o

pacote o roteador analisará os seguintes aspectos, em qual nível de AF ele deverá ser alocado,

qual a situação dos recursos da rede naquele momento para a faixa de AF dele, e caso os

recursos da sua faixa estejam esgotados, qual a preferência de descarte dele. Este último item

é quem definirá qual pacote deverá ser descartado em caso de congestionamento.

O serviço de Encaminhamento Assegurado não oferece garantias explícitas de retardo

e variação do retardo, mas oferece garantia de banda passante, mesmo na ocorrência de

30

congestionamentos. É o serviço adequado às aplicações que exigem banda sem restrições

temporais como, por exemplo, transferência de arquivos e navegação web [10].

Em casos de rajadas de tráfegos o PHB-AF permite a geração de filas de curta

duração, e as administra realizando o descarte dos pacotes. Para otimizar o processo das filas,

o AF utiliza algoritmos de gerenciamento ativo de filas.

4.2.4 CONTROLE DE DESCARTE DOS PACOTES

Para que o gerenciamento das filas que serão criadas no encaminhamento assegurado

tenham um desempenho satisfatório, deve ser implantando um gerenciamento ativo de filas,

pois conforme dito o PHB-AF admite filas curtas para que seja possível a administração de

alguns tráfegos em rajada.

4.2.4.1 RED

O RED (Random Early Detection) é o mais simples mecanismo de gerenciamento

ativo de filas. Este mecanismo recebe os pacotes a serem enviados e os armazena no buffer

para o envio, estes pacotes irão começar a gerar uma fila denominada avg (comprimento

médio da fila), a partir de certo tamanho da fila ela atingirá um tamanho, chamado lim_min,

desde então com a chegada de novos pacotes receberão a marcação de uma probabilidade p,

esta probabilidade será utilizada para análise de um possível descarte, os pacotes recebidos

antes de a fila atingir do valor lim_min não receberão nenhuma marcação. A probabilidade p

aumenta de forma linear, conforme o gráfico da figura 4.1, e quanto maior o valor de p, maior

a probabilidade de descarte do pacote. Com o aumento da fila, ela atingirá um valor lim_max,

a partir deste valor todos os pacotes que forem recebidos pelo roteador receberão um valor de

p = 1 (100%), de forma que todos os pacotes que forem recebidos pelo roteador a partir

daquele momento serão descartados.

Conforme cita Henrique Marques [11]:

“Na curva de probabilidades de descarte do esquema RED são observados três fases

distintas: a primeira compreende os instantes que o tamanho médio da fila variam entre 0 e

lim_min. Esta é a fase de Operação Normal do algoritmo, nesta fase nenhum pacote é

descartado; o segundo compreende os instantes em que o tamanho médio da fila varia entre os

lim_min e lim_max, e neste caso ocorre o descarte de pacotes com a conseqüente entrada em

inicio lento da conexão se o protocolo utilizado para transporte dos pacotes for o TCP.

31

Chama-se esta fase de Prevenção ao Congestionamento; a terceira fase compreende os

instantes em que o tamanho médio da fila é maior que o lim_max, desta vez todos os pacotes

serão descartados e por esta razão esta fase denomina-se Controle de Congestionamento”. A

Figura 4.2 mostra o gráfico da probabilidade de descarte deste algoritmo.

Figura 4.2 Probabilidade de descarte RED

4.2.4.2 WRED

O WRED (Weighted Random Early Detection) tem estrutura semelhante ao RED, com

o diferencial que ele analisa cada fluxo recebido como uma fila única, de forma que ele

analisa diversas filas em paralelo, e cada fila tem seus próprios parâmetros de avg, lim_min e

lim_max. Este tipo de mecanismo de gerenciamento de filas é melhor que o RED para ser

implementado em PHB-AF, pois o encaminhamento assegurado marca os fluxos com níveis

diferenciados de preferência de descarte dos pacotes, podendo cada uma das quatro classes ter

uma fila específica para ele [11].

4.2.4.3 RIO (RED FOR IN AND OUT)

O RIO é um sistema intermediário entre o RED e o WRED, ele estabelece duas filas

RED, uma IN para os pacotes que terão prioridade no fluxo de dados, e outra OUT para os

que não terão prioridade [6].

As filas serão tratados da seguinte forma:

IN – Ela receberá os pacotes denominados como IN e estes entrarão na fila

normalmente, até que a fila chegue ao valor min_IN. A partir deste ponto, os pacotes serão

32

marcados com a probabilidade de descarte, que será crescente e linear, como a RED, até que o

valor da fila chegue a max_IN e a probabilidade desta fila seja 1, e todos os pacotes que

chegarem a partir deste ponto serão descartados. Nesta fila serão contabilizados apenas os

pacotes com marcação IN.

OUT – Ela receberá todos os pacotes que chegam ao roteador, os IN e OUT, e

funcionará de forma semelhante a fila IN. Quando a fila chegar ao valor min_OUT, a partir

daquele ponto todos os pacotes serão marcados com a probabilidade de descarte crescente, até

que a fila atinja o valor max_OUT, a partir deste ponto a probabilidade de descarte será 1

(100%), e desde então todos os demais pacotes recebidos serão descartados.

Os valores de min_IN, min_OUT, max_IN e max_OUT serão determinados pelo

administrador da rede de acordo com as necessidades de QoS das aplicações utilizadas. A

Figura 4.3 demonstra os gráficos das probabilidades de descarte deste algoritmo.

Figura 4.3 Probabilidade de descarte RIO

4.2.5 DESVANTAGENS DIFFSERV

A Arquitetura DiffServ apresenta os seguintes problemas:

- Não oferece garantias tão rígidas para todos os recursos necessários como a

arquitetura IntServ;

- As aplicações que tem níveis de prioridade menor não tem desempenho assegurado;

33

5. AVALIAÇÃO DA REDE COM DIFERENCIAÇÃO DO TRÁFEGO

ATRAVÉS DO DSCP

Para que possa ser verificada a diferença do desempenho numa rede congestionada de

uma aplicação com, e sem, a diferenciação de prioridade serão realizadas as seguintes

simulações:

1º) Teste da aplicação, a ser priorizada, numa rede sem tráfego algum, para que

possam ser verificados os parâmetros exigidos pela mesma.

2º) Simulação de uma rede com tráfego intenso e sem nenhuma priorização do envio

dos pacotes.

3º) Simulação de uma rede com tráfego intenso e com priorização do envio dos

pacotes de vídeo.

Será avaliada a utilização de uma rede ponto-a-ponto, Figura 5.1, para a

disponibilização de um vídeo streaming.

Arquitetura da rede:

Extremidade 1 – Gerador do Vídeo

Microcomputador com processador Intel Dual Core (E2180 2GHz) – 512MB de

memória RAM – Interface Ethernet 100Mbps

Webcam Creative modelo NX Ultra – Resolução 640x480 (1,2Mpixel) – 30fps

Switch Cisco Catalyst 2960

Roteador Cisco 1841

Modem DATACOM – Configurado com velocidade de 320Kbps

Extremidade 2 – Receptor do Vídeo

Microcomputador com processador Intel Pentium 4 (2.66GHz) – 768MB de memória

RAM – Interface Ethernet 100Mbps

Switch Cisco Catalyst 2960

Roteador Cisco 1841

Modem DATACOM – Configurado com velocidade de 320Kbps

A instalação dos modens foi para limitar a velocidade da conexão, e de forma que a

simulação fique mais próxima do real, pois a arquitetura montada fica muito próxima a de

34

uma rede ponto-a-ponto provida por uma concessionária de telecomunicações. Será avaliada a

banda utilizada para o envio da imagem, perda de pacotes, o jitter e a latência dos pacotes

para chegar ao destino sem a implementação de QoS nos roteadores. Um terceiro

microcomputador enviará um pacote de dados para a estação receptora do vídeo para que

ocorra a “concorrência” pela banda passante disponibilizada e consequentemente os

problemas oriundos de tal “concorrência”.

Figura 5.1 Arquitetura da rede de simulação

Será utilizado o aplicativo NetMeeting (Figura 5.2) para a captura e envio das

imagens. O programa foi escolhido por estar incluso no sistema operacional Windows, e por

sua operação simples.

35

Figura 5.2 NetMeeting

O software que será utilizado para calcular o jitter e a latência será o Shunra VE

Desktop [13]. Ele gera pacotes com o comprimento, intervalo de envio e valor do campo TOS

definidos pelo usuário. Como existe a interoperabilidade entre o campo TOS e o DSCP,

conforme cita [14] (Figura 5.3) os primeiros dados do vídeo que será gerado devem ser

coletados são:

- Tamanho do Pacote

- Valor do campo TOS

- Intervalo de envio dos pacotes

Figura 5.3 Interoperabilidade entre o campo TOS e o DSCP

36

5.1 TESTE DE ENVIO DE VÍDEO STREAMING SEM NENHUM TR ÁFEGO

ADICIONAL NA REDE

Nesta primeira simulação, foi gerado um vídeo com origem em um computador e

enviado ao computador que estava ligado à outra extremidade do circuito na simulação de

uma rede WAN (Figura 5.1).

Esse teste foi realizado para verificar que largura de banda deve ser disponibilizada

para que a aplicação tenha um desempenho satisfatório.

Para realizar a coleta dos dados que serão utilizados foi necessário um programa

analisador de protocolos de rede, foi utilizado o Wireshark [15] devido a sua facilidade de

configuração e grande quantidade de informações.

Os parâmetros verificados no Wireshark (Figura 5.4) foram:

- Tamanho do pacote: 982 bytes (pelo tamanho não ser constante, será considerando

um comprimento médio de 1000bytes).

- Valor do campo TOS: O software não identifica diretamente o campo TOS, e sim o

DSCP, mas como existe a interoperabilidade entre eles [14], para o valor do DSCP 011000

temos para o TOS 01100000. Como o software Shunra VE Desktop [13] solicita o valor na

base 10 convertemos para 96.

- Intervalo de envio dos pacotes: Valor aproximado de 28 pacotes por segundo,

verificado através do software Wireshark.

Figura 5.4 Captura dos pacotes realizada pelo software Wireshark

37

No primeiro momento foi enviado o vídeo para a estação receptora sem a

“concorrência” de outros pacotes e não verificamos nenhuma perda de qualidade na imagem

transmitida. O roteador também foi acessado para verificar se algum pacote foi descartado

(Figura 5.5).

Para que o roteador mostre quantos pacotes foram perdidos e quais os tipos de pacotes

deve ser criada uma classe de pacotes (class-map). Essa classe deve ser vinculada a uma

política (policy-map). Posteriormente a política deve ser associada a uma das interfaces do

roteador e informada se será na entrada (input) ou na saída (output) da mesma. Nessa

situação, ela será associada a interface de saída para priorizar a interligação entre as duas

redes, no sentido da rede geradora do vídeo para a rede receptora, pois é a maior limitação da

arquitetura montada (a taxa de transferência entre os modens foi configurada para 320Kbps).

Como não foi criada nenhuma classe e política para diferenciar o tráfego, todos os

pacotes transmitidos irão sair pela classe class-default, classe padrão dos roteadores Cisco.

Primeiro deve ser criada uma classe com este mesmo nome e posteriormente associá-lo a uma

política de forma que possamos visualizar os pacotes.

Seguem os comandos que devem ser realizados no roteador Cisco, no modo de

configuração, para que seja possível a visualização do quantitativo de pacotes perdidos e o

modo de perda [16] [17] [18].

! policy-map politicavideo class class-default fair-queue random-detect dscp-based ! interface Serial0/0/0 service-policy output politicavideo !

Random drop e Tail drop são as formas de descarte de pacotes do roteador, colunas

presentes na Figura 5.5. A política de descarte do Tail trop funciona da forma que todo pacote

que chegue ao roteador depois que a fila atingir o valor presente na coluna Maximim thresh

será descartado. Esse algoritmo apresenta uma grande desvantagem nos casos de

congestionamentos extensos, pois todos os pacotes que chegarem ao roteador neste momento

será descartado. Para aplicações de tempo real, como a disponibilização de um vídeo

streaming, a perda de pacote deste modo é extremamente prejudicial para a aplicação, pois

gera uma descontinuidade muito grande no serviço, porque a perda dos pacotes será

38

sequencial. Outra política utilizada para o descarte dos pacotes é a presente na coluna Random

drop da Figura 5.5. Nessa política de perda assim que uma fila chegar ao seu valor máximo,

Maximim thresh, o roteador descartará um pacote de forma aleatória e não necessariamente o

último que chegou. Dessa forma os bytes são perdidos de forma aleatória e não contínua. Para

aplicações este procedimento de descarte é mais aceitável para aplicações de tempo real, pois

os pacotes não são perdidos de forma sequencial. Porém esse tipo de descarte exige muito do

processamento do roteador e principalmente num momento que ele encontrasse com uma alta

carga de trabalho para administrar o congestionamento [19]. Na Figura 5.5 temos a coluna

Transmitted pkts/bytes, que mostra respectivamente a quantidade de pacotes transmitidos e a

quantidade de bytes também transmitidos. A coluna dscp mostra o valor do campo dscp do

respectivo pacote. A coluna Mark prob mostra a probabilidade de descarte que será vinculada

a cada pacote a partir do momento que a fila de envio de pacotes atingir o valor Minimum

thresh.

A descrição de cada comando segue na Tabela 5.1

Tabela 5.1 Descrição dos comandos inseridos no roteador

Comando Descrição

policy-map politicavideo Cria uma política de marcação de pacotes chamada politicavideo

class class-default Associa os pacotes da classe class-default a política politicavideo

fair-queue Habilita a WFQ (Fila Justa com Pesos) na classe class-default. Este é o gerenciamento de fila original padrão dos atuais roteadores Cisco.

random-detect dscp-based Habilita a detecção do pacotes enviados pelo DSCP, e possibilita a criação de filas baseadas em WRED.

interface Serial0/0/0 Acessa a serial 0/0/0

service-policy output politicavideo Associa a politica politicavideo a interface de saída do roteador.

Com o comando show policy-map interface s0/0/0 verificamos os parâmetros de envio

e perda de pacotes na interface do roteador (Figura 5.5).

39

Figura 5.5 Log das políticas de envio de pacotes interface serial 0/0/0 do roteador com o

envio de imagens sem “concorrência” pela banda passante disponibilizada

Analisando os dados da Figura 5.5, é verificado que os dados enviados com o DSCP

CS3 (011000) foram transmitidos de forma integral, sem perdas.

Na Figura 5.6 temos a imagem do software Shunra VE Desktop com os valores

verificados pelo softawe Wireshark e realizando a simulação durante 3 minutos do envio dos

pacotes.

Com a análise da simulação realizada pelo Shunra VE desktop (Figura 5.6) chegamos

as seguintes conclusões:

- Latência: mínima 28ms, média 28ms, máxima 49ms

- Perda de pacote: 0%

- Jitter máximo: 21ms (diferença entre a latência máxima e mínima)

40

Figura 5.6 Imagem do software Shunra VE desktop após a execução do teste de simulação

sem tráfego concorrente

Foi utilizado o software PRTG Network Monitor (Figura 5.7) [20] para avaliar a

largura de banda utilizada pela aplicação de vídeo streaming.

No gráfico da Figura 5.7 é verificado que o vídeo streaming chegou a gerar uma taxa

de transferência 322Kbit/s. Essa taxa de transferência é verificada na placa de rede do

computador e não no roteador.

41

Figura 5.7 Banda passante verificada na interface ethernet do microcomputador

gerador do vídeo

5.2 SIMULAÇÃO DO ENVIO DO VÍDEO STREAMING COM TRÁFE GO

ADICIONAL NA REDE SEM DIFERENCIAÇÃO DO TRÁFEGO

Foram realizados os mesmo testes, sendo que com a rede congestionada. Com mais de

uma aplicação “concorrendo” pela mesma largura de banda disponibilizada. Neste caso

teremos os pacotes de vídeo, pacotes com marcação DSCP igual a (011000) CS3, e os pacotes

da transferência do arquivo, sem marcação DSCP, utilizando o mesmo circuito de dados.

Antes do início dos novos testes reiniciamos os valores dos contadores do roteador

com o comando clear counters, no final da transferência do arquivo de 3,41MB (este arquivo

será o padrão utilizado nos testes) verificamos a quantidade pacotes perdidos.

Analisando os dados obtidos no roteador (Figura 5.8) verificamos que dos 15.143

pacotes enviados 1.908 não foram recebidos, o que significa uma perda de 12,6% dos pacotes,

segundo [14] o percentual de perda de pacote deve ser menor que 5% para aplicações de

vídeo streaming.

42

Figura 5.8 Log das políticas de envio de pacotes interface serial 0/0/0 do roteador com o

envio de imagens com “concorrência” pela banda passante disponibilizada e sem QoS

Durante a visualização do vídeo em diversos momentos a recepção da imagem foi

interrompida, devido à alta perda de pacotes, o vídeo em diversos momentos ficou

imperceptível. Outro ponto analisado foi o alto descarte de pacote por Tail drop, de forma

sequencial, e como citado é extremamente prejudicial para aplicações de tempo real.

O Shunra VE desktop foi utilizado para medir a latência, o jitter, e a perda de pacote

no envio dos pacotes simulados, o arquivo transferido para aumentar o tráfego foi o mesmo

do teste anterior.

Analisando os dados disponibilizados na Figura 5.9 verificamos que:

- Perda de Pacote: 12,96%

- Latência: Média de 680ms, chegando a pico de 1.317ms

- Jitter: Em alguns momentos chegou a mais de 200ms, (Figura 5.10) quando segundo

[14] não deve passar de 150ms.

43

Figura 5.9 Imagem do software Shunra VE desktop após a execução do teste de simulação

com tráfego concorrente e sem priorização do tráfego com DSCP CS3

Figura 5.10 Maior valor do jitter

44

Para ser verificado a banda passante necessária para suportar os dois serviços, o vídeo

streaming e a transferência do arquivo, foram enviados os dois fluxos a partir do computador,

pois o software PRTG Network Monitor verifica os dados disponibilizados pela placa ethernet

do computador.

É verificado na Figura 5.11 que o tráfego necessário para a transmissão do vídeo

streaming e para a transferência do arquivo chegou a 452Kbit/s, a interface entre o

computador e switch, e entre o switch e roteador são ambas de 100Mbit/s, mais que suficiente

para o tráfego gerado, porém a interface utilizada para a transmissão entre os modens é de

320Kbit/s. Este tráfego maior que o suportável para a rede de acesso será armazenada do

buffer do roteador em forma de filas, e estas serão dispostas e terão comprimento de acordo

com a política de saída do roteador, no caso do equipamento em questão todas as filas tem um

comprimento máximo de 40 pacotes (Figura 5.8). Quando estas filas atingirem seu valor

máximo os pacotes serão descartados [19], conforme verificado no log do roteador (Figura

5.8).

Figura 5.11 Banda passante verificada na interface ethernet do microcomputador gerador do

vídeo com a transferência do arquivo de teste

5.3 SIMULAÇÃO DO ENVIO DO VÍDEO STREAMING COM TRÁFE GO

ADICIONAL NA REDE COM PRIORIZAÇÃO DO TRÁFEGO DE VÍD EO

Para que o tráfego de vídeo streaming tenha perda de pacotes aceitável, mesmo

ocorrendo “concorrência” pela banda passante disponível, é necessário que o envio dos

pacotes de vídeo tenha prioridade sobre o envio dos demais pacotes que tentem ser

45

transmitidos. Para isso será gerada uma classe (class-map) e uma política (policy-map) isso

garantirá que o envio dos pacotes de vídeo tenham prioridade acima dos outros pacotes.

Primeiro deve ser criada uma classe e esta ser associada a uma política. Nesta política

deve ser descriminado todo o recurso necessário para que o vídeo seja executado de forma

satisfatória.

Seguem os comando que devem ser digitados no modo de configuração do roteador

para que o envio dos pacotes com valor do campo DSCP tenham seu envio priorizado.

! ip cef ! class-map match-any classevideo match dscp cs3 ! ! policy-map politicavideo class classevideo bandwidth 300 random-detect dscp-based random-detect dscp 24 50 140 ! interface Serial0/0/0 max-reserved-bandwidth 95 service-policy output politicavideo !

Após a nova configuração do roteador o teste da transferência do arquivo durante a

transmissão do vídeo foi realizada novamente para que fosse analisado o desempenho da

transmissão com a nova configuração realizada no roteador, para que ocorresse a priorização

dos pacotes de imagem que tivessem o campo DSCP com valor CS3. Temos na Figura 5.12 o

resultado da perda de pacotes que trafegam na roteador através das políticas de saídas da

serial 0/0/0.

A descrição de cada comando segue na Tabela 5.2

46

Tabela 5.2 Descrição dos comandos inseridos no roteador

Comando Descrição

ip cef Habilita o protocolo Cisco encaminhamento expresso .

class-map match-any classevideo Cria uma classe chamada classevideo

match dscp cs3 Cria a regra que todo pacote que tenha o valor do campo DSCP igual a CS3 fará parte da classe classevideo

policy-map politicavideo Cria uma política de marcação de pacotes chamada politicavideo

class classevideo Associa os pacotes da classe classevideo a política politicavideo

bandwidth 300 Reserva uma banda passante de 300Kbit/s para esta classe

random-detect dscp-based

Habilita a detecção do pacotes enviados pelo DSCP, e possibilita a criação de filas baseadas em WRED.

random-detect dscp 24 50 140 Cria novos limites para a fila dos pacotes com DSCP 24 (CS3), limite inferior 50 e limite superior 140

interface Serial0/0/0 Acessa a serial 0/0/0

max-reserved-bandwidth 95 Novo limite de reserva de banda da interface passa ser de até 95%, o padrão é 75% para que as outras aplicações possam ter acesso ao circuito.

service-policy output politicavideo Associa a política politicavideo a interface de saída do roteador.

A perda de pacotes mostrada na Figura 5.12, que mostra os pacotes da classevideo, foi

de 1,56%, dentro do limite citado por [14], que informa que a perda deve ser menor que 5%, e

bem abaixo da perda do teste anterior, que foi de 12,6%. Outro aspecto observado é que todos

os pacotes perdidos foram descartados de forma aleatória, e não sequencial como muitos

foram descartados na simulação realizada sem a configuração de serviços diferenciados, o que

é muito importante para as aplicações de tempo real, nas quais a continuidade dos pacotes é

um fator preponderante.

47

Figura 5.12 Log das políticas de envio de pacotes interface serial 0/0/0 do roteador com o

envio de imagens com “concorrência” pela banda passante disponibilizada e com QoS

Foi utilizado o software Shunra VE Desktop para que fosse calculado o Jitter, e a

latência dos circuitos em uma nova simulação. A configuração do software foi a mesma

utilizada no teste anterior. No teste realizado pelo software Shunra VE Desktop, os pacotes

são gerados pelo Shunra e não pela aplicação, por isso que os resultados de perda de pacote

apresentam uma pequena diferença.

Analisando os dados disponibilizados verificamos que:

- Perda de Pacote: 0%

- Latência: Mínima de 43ms, média de 53ms, chegando a pico de 74ms

- Jitter: Em alguns momentos chegou a 31ms, dentro do limite indicado por [14] que

não deve passar de 150ms.

48

Figura 5.13 Imagem do software Shunra VE desktop após a execução do teste de simulação

com tráfego concorrente e com priorização do tráfego com DSCP CS3

As perdas de pacotes mostradas na Figura 5.13, são referente aos pacotes enviados

para a transferência do arquivo de teste, pacotes que não tem prioridade alguma. No teste

anterior não havia ocorrido nenhuma perda de pacote deste tipo, pois não existia uma grande

diferenciação do tratamento dos pacotes, apenas a diferenciação padrão dos atuais roteadores

Cisco. Com a diferenciação de todo tráfego que chegue ao roteador com marcação DSCP

CS3, e a reserva de banda de até 300Kbit/s quando necessário, apenas 20Kbp/s está

disponível para as aplicações restantes, trata-se de uma valor muito baixo, mas para efeito de

teste a intenção foi esta. A perda de pacote foi de 3,35% do total de pacotes CS5, que apesar

de terem valores atribuídos no campo DSCP foram descartados, pois o valor do campo era

diferente do qual havia sido configurado para diferenciação. Levando em conta o total de

pacotes da classe class-default a perda foi de 1,80%.

49

Figura 5.14 Log das políticas de envio de pacotes interface serial 0/0/0 do roteador com o

envio de imagens com “concorrência” pela classe class-default

Utilizamos o software PRTG Network Monitor para verificarmos transmissão dos

dados pela interface ethernet do computador.

Durante a simulação o tráfego atingiu o pico de 363Kbit/s e foi bem estável como

mostra a Figura 5.15.

Figura 5.15 Banda passante verificada na interface ethernet do microcomputador gerador do

vídeo com a transferência do arquivo de teste

50

5.4 CONCLUSÃO DAS SIMULAÇÕES REALIZADAS

Comparando os resultados obtidos nas duas situações, na primeira em que o vídeo foi

enviado em concorrência com outros pacotes e sem a priorização do tráfego, e na segunda

situação na qual os pacotes com marcação DSCP igual a CS3 (011000) tiveram prioridade na

interface de saída do roteador ligado a WAN é verificado que a implementação de serviço

diferenciado no roteador para priorizar o tráfego do vídeo streaming melhora

significantemente o desempenho da aplicação em todos os parâmetros analisados. Os

resultados utilizados na análise final foram os que mais se aproximaram dá média, após serem

realizadas 7 (sete) simulações.

Tabela 5.3 Análise dos resultados

Parâmetro Limite aceitável Simulação sem

diferenciação do tráfego

Simulação com priorização do

tráfego

Melhora em percentual

Latência 150 mseg Média de 680

mseg, chegando a 1.317mseg

Média de 53 mseg, chegando

a 74 mseg 92,20% menor

Jitter 30 mseg 200 mseg 31 mseg 84,5% menor

Perda de

pacote 5% 12,96% 1,56% 87,96% menor

É verificado que a utilização dos parâmetros disponíveis no campo DSCP para

diferenciar o tráfego, aliado a configurações no roteador que priorizem um determinado

tráfego faça com que aplicações que têm parâmetros rígidos qualidade de serviço tenham seu

desempenho satisfatório.

O teste foi para priorizar apenas um tráfego, RED, mas pode ser implementado para

priorizar diversos tráfegos, WRED, de acordo com a necessidade de cada aplicação.

5.5 SUGESTÕES PARA TRABALHOS FUTUROS

Como sugestão para trabalhos futuros é indicado estudar alguns itens tais como:

- O impacto da utilização de critérios de descarte de pacotes, RED, WRED, RIO, no

processador do roteador;

- O impacto das formas de descarte Random drop e Tail trop no processador do

roteador;

51

- Realizar as simulações em redes mais extensas;

- Realizar simulações priorizando mais de um tipo de tráfego;

- Comparar os parâmetros de QoS utilizando IntServ e posteriormente DiffServ numa

pequena rede, onde seja viável a instalação de IntServ.

52

6. REFERÊNCIAS BIBLIOGRÁFICAS

[1] Filho, R. Evolução das tecnologias e protocolos para comunicação multimídia.

Dissertação de Mestrado defendida e aprovada em 19 de fevereiro de 2004, na Universidade

de Brasília. Disponível em http://www.ene.unb.br/antenas/Arquivos/roqueMestrado.pdf

Acessado em 10/09/2008.

[2] Cisco. Empresa do ramo de ativos de rede de computadores. Disponível em

http://www.cisco.com/web/BR/barometro/barometro.html?sid=166767_1 Acessado em

01/09/2008.

[3] Lage, C., Oliveira, M. Estudo de uma rede de acesso via fibra óptica. Disponível em

www.ene.unb.br/antenas/Arquivos/claraluiza.pdf Acessado em 12/09/2008.

[4] Dastis, R. Um estudo dos mecanismos de controle de tráfego e congestionamento nas

diferentes categorias de serviço do ATM. Disponível em

www.inf.ufrgs.br/pos/SemanaAcademica/Semana98/dastis.html Acessado em 12/09/2008.

[5] Silva, D. Análise de qualidade de serviço em rede corporativa. Dissertação de

Mestrado defendida e aprovada em dezembro de 2004, na Universidade de Campinas.

Disponível em http://libdigi.unicamp.br/document/?code=vtls000359191 Acessado em

12/09/2008.

[6] Nascimento, K. Marcação de tráfego em redes DiffServ. Dissertação de Mestrado

defendida e aprovada em setembro de 2004, na PUC - Rio. Disponível em

http://www.maxwell.lambda.ele.puc-rio.br/cgi-

bin/db2www/PRG_0651.D2W/SHOW?Mat=&Sys=&Nr=&Fun=&CdLinPrg=pt&Cont=5751

:pt Acessado em 20/09/2008.

53

[7] HERSENT, O., Telefonia IP. São Paulo: Addison Wesley, 2002.

[8] Fernandez, N., Voz sobre IP: Uma visão geral. Disponível em

http://www.ravel.ufrj.br/arquivosPublicacoes/nelson_voip.pdf Acessado em 20/09/2008.

[9] Falcão, H. Trafficanalyser: Uma ferramenta de análise de tráfego para rede IP.

Disponível em www.iadis.net/dl/final_uploads/200405C013.pdf Acessado em 28/09/2008.

[10] Fernandez, M. Provisionamento de recursos em arquitetura DiffServ para melhoria

da qualidade de serviço. Dissertação de Doutorado defendida e aprovada em outubro de

2002. Disponível em www.larces.uece.br/~marcial/publicacoes/Fernandez02_DSc.pdf

Acessado em 11/10/2008.

[11] Marques, H. RERB – Uma proposta de disciplina de filas para descarte de pacotes.

Dissertação de Mestrado defendida e aprovada em 2005 na Universidade Estadual do Ceará.

Disponível em http://mpcomp.pgcomp.uece.br/admin/arquivos/HenriqueMarques2005.pdf

Acessado em 11/10/2008.

[12] Tanenbaum, Andrew S. Redes de computadores. Rio de Janeiro: Campus, 1997.

[13] Shunra Software. Empresa que desenvolve softwares. Disponível em www.shunra.com

Acessado em 03/04/2009.

[14] Santana, S. Proposta de referência para projetos de qualidade de serviço (QoS) em redes

corporativas. Dissertação de Mestrado defendida e aprovada em maio de 2006 na

Universidade Salvador. Disponível em

http://tede.unifacs.br/tde_busca/arquivo.php?codArquivo=73 Acessado em 01/04/2009.

[15] Software livre desenvolvido por usuários. Disponível em www.wireshark.org Acessado

em 15/04/2009.

54

[16] Cisco. Empresa do ramo de ativos de rede de computadores www.cisco.com

Acessado em 12/04/2009.

[17] LAMMLE, T., CCNA IOS COMMANDS . Indiana: Wiley Publishing, 2008.

[18] Flannagan, M. Administering Cisco QoS for IP Networks. Rockland: Syngress

Publishing, 2001.

[19] Universidade do vale do rio dos sinos Relatório Técnico: RT 05/2003 Controle de

Congestionamento em Redes de Computadores, 2003.

[20] Paessler. Empresa que desenvolve softwares. http://www.paessler.com/ Acessado em

13/04/2009.