Sei sulla pagina 1di 55

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 ATRAVÉ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ÁFEGO
ADICIONAL NA REDE SEM DIFERENCIAÇÃO DO TRÁFEGO ................. 41
5.3 SIMULAÇÃO DO ENVIO DO VÍDEO STREAMING COM TRÁFEGO
ADICIONAL NA REDE COM PRIORIZAÇÃO DO TRÁFEGO DE VÍDEO. 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 Gigabit Ethernet
100Base-T 1000Base-X
Taxa de transmissão 10Mbps 100Mbps 1Gbps
Fibra Multímodo 2 km 412m (half duplex) 500m
2Km (full duplex)
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ÁFEGO


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ÁFEGO


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

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


Simulação sem Simulação com
Parâmetro Limite aceitável Melhora em
diferenciação do priorização do
percentual
tráfego tráfego
Média de 680 Média de 53
Latência 150 mseg mseg, chegando a mseg, chegando 92,20% menor
1.317mseg a 74 mseg
Jitter 30 mseg 200 mseg 31 mseg 84,5% menor
Perda de
5% 12,96% 1,56% 87,96% menor
pacote

É 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.

Potrebbero piacerti anche