Escolar Documentos
Profissional Documentos
Cultura Documentos
SERVIÇOS INTEGRADOS E
DIFERENCIADOS PARA REDES DE
BANDA LARGA
por:
UNIVERSIDADE DE PERNAMBUCO
ESCOLA POLITÉCNICA DE PERNAMBUCO
DEPARTAMENTO DE ENGENHARIA ELÉTRICA
por
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
May/2009
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
LISTA DE FIGURAS
LISTA DE TABELAS
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
1.1. MOTIVAÇÃO
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
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 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
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
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
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
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
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.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
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.
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.
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.
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].
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].
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.
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
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
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].
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.
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.
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
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”.
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
!
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.
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
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
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
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).
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
!
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
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.
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
6. REFERÊNCIAS BIBLIOGRÁFICAS
[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.
[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.
[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.
[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.
[17] LAMMLE, T., CCNA IOS COMMANDS. Indiana: Wiley Publishing, 2008.
[19] Universidade do vale do rio dos sinos Relatório Técnico: RT 05/2003 Controle de
Congestionamento em Redes de Computadores, 2003.