Telematica_Com_Dados_2_Texto QoS_IP_Itelcon

Prévia do material em texto

1 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Qualidade de Serviço (QoS) em Redes IP 
Princípios Básicos, Parâmetros e Mecanismos 
 
 
 
 
 
 
 
 
 
 
 
 
 
Fonte : Prof. Dr Joberto Martins 
www.itelcon.com.br 
Por: Prof Hugo Santana 
Universidade Santa Cecília - Unisanta 
 
 2 
 
 
 
1. INTRODUÇÃO 3 
2. CENÁRIO E NOVAS APLICAÇÕES EM REDES IP 3 
2.1 "QUALQUER APLICAÇÃO SOBRE REDE DE PACOTE" 3 
2.2 "QUALQUER APLICAÇÃO SOBRE REDES IP" 4 
2.3 DESAFIOS - REDES IP 5 
2.4 NOVAS APLICAÇÕES 5 
3. QUALIDADE DE SERVIÇO (QOS) 6 
3.1 QUALIDADE DE SERVIÇO (QOS) - PRINCÍPIOS 6 
3.2 QOS COMO MECANISMO GERENCIAL 7 
3.3 QOS -PARÂMETROS 7 
3.3.1 QUAIS APLICAÇÕES NECESSITAM DE QOS? 8 
3.3.2 VAZÃO 8 
3.3.3 LATÊNCIA (ATRASO) 9 
3.3.4 JITTER 11 
3.3.5 PERDAS 12 
3.3.6 DISPONIBILIDADE 12 
4. QOS - ALTERNATIVAS TÉCNICAS 13 
4.1 CENÁRIO - IMPLEMENTAÇÃO DA QOS 13 
4.2 QOS EM REDES IP - ALTERNATIVAS TÉCNICAS 14 
4.2.1 INT SERV - INTEGRATED SERVICES ARCHITECTURE E RSVP - RESOURCE RESERVATION 
PROTOCOL 14 
4.2.2 DIFFSERV - DIFFERENTIATED SERVICES FRAMEWORK 16 
4.2.3 MPLS - MULTIPROTOCOL LABEL SWITCHING 18 
4.2.4 SBM - SUBNET BANDWIDTH MANAGEMENT 19 
4.2.5 DIMENSIONAMENTO 21 
5. QOS - MECANISMOS 21 
5.1 PROTOCOLOS DE SINALIZAÇÃO 21 
5.2 PRIORIDADES 22 
5.3 ESCALONAMENTO 22 
5.4 CONTROLE DE FILAS 23 
5.5 CONGESTIONAMENTO 23 
 
 
 
 3 
 
1. Introdução 
 
A Qualidade de Serviço (QoS JI) em redes é um aspecto de implantação e operação importante 
para as redes de pacote como um todo e para as redes IP em particular. Este documento 
discute os parâmetros, os protocolos e os mecanismos envolvidos com a garantia de 
qualidade de serviço com ênfase nas redes de pacotes tipo IP. 
 
2. Cenário e Novas Aplicações em Redes IP 
 
As redes TCP/IP [Com95] ou simplesmente, redes IP, têm uma imensa base instalada com 
milhões de computadores que continua crescendo em praticamente todo o mundo. O forte 
crescimento e a aceitabilidade das redes IP ocorre em função de dois fatores mais 
importantes, a saber: 
 
♦ O crescimento da rede Internet e 
♦ A aceitação cada vez maior pelas empresas da base tecnológica TCP/IP como 
plataforma de suporte às suas aplicações em rede. Isso decorre em parte do 
sucesso da capilaridade da Internet e do seu potencial (Comércio eletrônico, ...). 
 
Em princípio, este cenário não tende a mudar no próximos anos e, assim sendo, teremos cada 
vez mais computadores utilizando o TCP/IP para suas comunicações na Internet e, 
possivelmente, no âmbito das empresas. 
 
Neste contexto o IP é certamente uma alternativa bastante atrativa como plataforma padrão de 
suporte para as aplicações, pois está naturalmente presente em milhões de máquinas. A 
questão importante a verificar então vem a ser se realmente esta é a tendência para as redes 
como um todo (Redes privadas, redes metropolitanas, redes de telecomunicações, redes 
industriais, ..) ou se existem outras tendências a considerar. O fato é que o IP não é a única 
opção tecnológica para o suporte de aplicações em redes. 
 
2.1 "Qualquer Aplicação sobre Rede de Pacote" 
 
Existe um certo consenso de que as tecnologias de comutação (Níveis 2 e 3), algumas vezes 
denominadas genericamente de "comutação de pacotes" (Packet Switching), devem 
prevalecer como opção tecnológica para as redes de computadores e como suporte às 
aplicações como um todo. As opções mais comuns de tecnologias de comutação disponíveis 
para utilização em redes sem maiores restrições de porte, desempenho ou cobertura 
geográfica (LAN - Local Area Networks, MAN - Metropolitan Area Networks ou WAN - Wide 
Area Networks) são as seguintes [Tan96]: 
 
♦ ATM - Asynchronous Transfer Mode (Nível 2) 
♦ Frame Relay (Nível 2) 
♦ IP (Nível 3) 
 
JI - Termos do Jargão Internacional (norte-americano) utilizados no texto visando uma simplificação da 
nomenclatura utilizada. 
 
 
 4 
 
 
Considerando especificamente estas alternativas, o ATM, o Frame Relay e o IP em particular 
podem ser utilizados de formas distintas pelas aplicações, a saber: 
 
♦ A aplicação utiliza efetivamente a tecnologia de comutação (ATM, Frame Relay, 
...) e, no caso, pode eventualmente prescindir do recursos ou mesmo da utilização 
do IP ou 
♦ A comutação no IP é efetivamente a plataforma para as aplicações e, assim 
sendo, ele define as vantagens, desvantagens e limitações da rede. 
 
A primeira situação corresponde à utilização, por exemplo, da tecnologia ATM como um 
backboneJI de rede. Neste backbone, as aplicações utilizam as conexões lógicas de alto 
desempenho do ATM e, eventualmente, podem prescindir ou depender pouco do IP. Exemplos 
específicos neste contexto são as aplicações de voz sobre ATM (VTOA - Voice Transport over 
ATM) [Dan98] e o MPOA (MultiProtocol over ATM) [Dav96]. Este cenário é mais comum em 
redes proprietárias de alto desempenho. Uma idéia semelhante pode ser citada para o Frame 
Relay quando o mesmo é utilizado em redes corporativas MAN e WAN. 
 
Na segunda situação, o IP predomina e é o maior responsável pela comunicação fim-a-fim 
(usuário-a-usuário). Nada impede entretanto que na implementação da comunicação utilize-se 
em trechos da rede o protocolo IP (Nível 3) sobre algumas das tecnologias de rede de nível 2 
citadas. Segue alguns exemplos de alternativas possíveis: 
 
♦ IP over ATM 
♦ IP over Frame Relay 
♦ IP over Ethernet 
♦ IP over Ethernet Switched 
♦ Outras 
 
O importante a considerar nesta discussão é que estas tecnologias são, neste caso, 
meramente mecanismos de transporte de pacotes entre roteadores e, assim sendo, prevalece 
na rede as características do IP. Este é um cenário típico das redes de grande público 
(Internet, intranets, ...) e, também, das redes de acesso. 
 
Assim sendo, as aplicações tendem a executar sobre redes de pacotes e, dependendo do tipo 
da rede, as opções são de execução sobre IP (com dependência do mesmo) ou sobre alguma 
tecnologia de nível 2 de alto desempenho. 
 
2.2 "Qualquer Aplicação sobre Redes IP" 
 
A rede TCP/IP foi desenvolvida tendo como uma de suas premissas básicas o requisito de 
poder ser utilizada com os diversos tipos de meios físicos e tecnologias existentes na época 
de sua criação ("IP sobre Tudo" - Anos 70) de forma a viabilizar a comunicação entre as 
aplicações fim-a-fim em rede. 
 
Em termos práticos, a rede IP foi desenvolvida de forma a ser capaz de comutar sobre meios 
físicos e tecnologias de nível 2 confiáveis, não-confiáveis, de alto desempenho, de baixo 
desempenho, etc. Neste contexto histórico, as decisões arquiteturais tomadas na concepção 
do protocolo IP foram, na sua maioria, no sentido da simplicidade visando atender o cenário 
 
 5 
 
imaginado na época para sua implantação em termos de rede. Este paradigma de concepção 
impõe algumas restrições técnicas ao IP e, por conseqüência, restringe as aplicações 
suportadas às aplicações com poucos requisitos de operação (P. ex.: aplicações de dados 
podem perder pacotes, permitem a existência de atrasos, ...). 
 
O cenário atual das redes IP mudou. Hoje, o cenário de utilização das redes IP exige que 
"qualquer aplicação" possa rodar com qualidade sobre o IP. Ou seja, a situação do IP 
atualmente é no sentido do "Tudo sobre IP" mantendo a premissa básica de projeto do "IP 
sobre Tudo" dos anos 70. 
 
De certa forma o paradigma mudou e a questão que segue vem a ser a identificação das 
eventuais limitações do IP e procedimentos necessários para adequa-lo à nova realidade das 
redes. 
 
Como veremos adiante, a qualidade de serviço em redes IP não é necessariamente resolvida 
com um único protocolo ou algoritmo. Na maioria dos casos e dependendo da necessidade 
da(s) aplicação(ões), um conjunto de novos recursos deve ser utilizado. 
 
2.3 Desafios - Redes IPOs desafios na utilização do IP como plataforma de suporte para aplicações em redes são em 
resumo os seguintes: 
 
♦ O IP, como protocolo, não tem praticamente nenhuma garantia de qualidade de 
serviço e 
♦ A base instalada do IP é muito grande, o que torna a mudança do protocolo uma 
idéias pouco factível. 
 
O primeiro desafio é de caráter técnico e diz respeito ao paradigma inicialmente previsto para 
o protocolo que enfatizava a simplicidade de concepção. Por exemplo, o IP não tem nenhuma 
garantia de vazão constante para uma aplicação em particular. Além disso, uma aplicação não 
pode obter do IP nenhuma garantia de entrega da próprios pacotes que eventualmente são 
descartados ou perdidos sem que nenhum tipo de correção ou ação seja tomada. Não existe 
igualmente nenhuma garantia de tempo de entrega para os pacotes. 
 
O segundo desafio é uma questão de como se adequar ao novo paradigma sem efetivamente 
mudar o protocolo. O IP (Versão 4) deverá em breve mudar para o IP (Versão 6) [Tho96] mas, 
mesmo neste caso, a escolha foi de manter o paradigma de simplicidade inicial do IPv4 para o 
IPv6. O IPv6 ou IPng (New Generation) aborda outras questões de implementação do 
protocolo (Endereçamento, segurança, ...) e não apresenta nenhuma solução completa para 
os desafios citados. 
 
A forma de abordar as "deficiências" do IP consiste então em propor novos protocolos, 
algoritmos e mecanismos que tratem das deficiências tecnológicas intrínsecas ao protocolo e 
permitam o suporte efetivo de qualquer tipo de aplicação sobre redes IP. 
 
2.4 Novas Aplicações 
 
 
 6 
 
Como citado anteriormente, o IP tem uma base instalada muito grande e a tendência é que ele 
suporte as novas aplicações em rede, a saber: 
 
♦ Telefonia e Fax sobre IP (VoIP - Voice over IP) 
♦ Comércio Eletrônico (E_commerce) 
♦ Vídeo sobre IP 
♦ Educação à Distância (EAD) (Distance Learning) 
♦ Vídeo-Conferência 
♦ Aplicações Colaborativas e de Grupo 
♦ Aplicações Multimídia 
♦ Aplicações Tempo Real 
♦ Outras 
 
Genericamente, a maioria das aplicações citadas são aplicações multimídia na medida em que 
envolvem a transferência de múltiplos tipos de mídia (Dados, voz, vídeo, gráficos, ...) com 
requisitos de tempo e sincronização para a sua operação com qualidade. 
 
3. Qualidade de Serviço (QoS) 
 
A qualidade de serviço (QoS) nas redes IP é um aspecto operacional fundamental para o 
desempenho fim-a-fim das novas aplicações (VoIP, multimídia, ...). Assim sendo, é importante 
o entendimento dos seus princípios, parâmetros, mecanismos, algoritmos e protocolos 
desenvolvidos e utilizados para a obtenção de uma QoS. 
 
A obtenção de uma QoS adequada é um requisito de operação da rede e suas componentes 
para viabilizar a operação com qualidade de uma aplicação. 
 
Em seguida discute-se com mais detalhe o que vem a se termo "Qualidade de Serviço". 
3.1 Qualidade de Serviço (QoS) - Princípios 
 
Numa primeira abordagem o termo "Qualidade de Serviço" pode ser entendido da seguinte 
forma: 
Qualidade de Serviço (QoS) é um requisito da(s) aplicação(ões) para a 
qual exige-se que determinados parâmetros (atrasos, vazão, perdas, ...) 
estejam dentro de limites bem definidos (valor mínimo, valor máximo). 
 
A QoS é garantida pela rede, suas componentes e equipamentos utilizados. Do ponto de vista 
dos programas de aplicação, a QoS é tipicamente expressa e solicitada em termos de uma 
"Solicitação de Serviço" ou "Contrato de Serviço". A solicitação de QoSJI da aplicação é 
denominada tipicamente de SLA (Service Level Agreement) [Job99] [Jam98]. 
 
A SLAJI deve definir claramente quais requisitos devem ser garantidos para que a(s) 
aplicação(ões) possam executar com qualidade. Um exemplo típico de SLA para uma 
aplicação de voz sobre IP (VoIP - Voice over IP) com algumas centenas de canais voz 
simultâneos numa rede IP WAN poderia ser: 
 
 7 
 
 
♦ Vazão ≥ 2 Mbps; 
♦ Atraso ≤ 250 mseg 
♦ Disponibilidade ≥ 99,5% 
 
Uma vez que a rede garanta esta SLA, tem-se como resultado que a aplicação VoIP em 
questão poderá executar garantindo a qualidade de voz prevista para os seus usuários se 
comunicando simultaneamente através da rede IP. 
 
Do ponto de vista dos usuários, tem-se normalmente que a qualidade obtida de uma aplicação 
pode ser variável e, a qualquer momento, pode ser alterada ou ajustada (para melhor 
qualidade ou pior qualidade). Por exemplo, pode-se assistir um vídeo com uma qualidade de 
32 fps (Frames per Second) ou 4 fps e, fundamentalmente, isto depende da qualidade de 
vídeo esperada pelo usuário final. Embora este comportamento possa ser dinâmico dos ponto 
de vista dos usuários finais (seres humanos), do ponto de vista das redes as SLAs são 
estáticas e, eventualmente, podem ser alteradas. A alteração numa SLA implica, como 
veremos adiante, normalmente numa nova solicitação de qualidade de serviço à rede em 
questão. 
 
3.2 QoS como Mecanismo Gerencial 
 
Do ponto de vista de um gerente ou administrador de redes, a percepção da qualidade de 
serviço é mais orientada no sentido da utilização de mecanismos, algoritmos e protocolos de 
QoS em benefício de seus clientes e suporte às aplicações. Ou seja, como efetivamente a 
rede e suas componentes podem garantir as inúmeras SLAs definidas para diversos usuários 
e aplicações. 
 
Outras aspectos importantes do ponto de vista gerencial são a escalabilidade e flexibilidade da 
solução implantada. 
 
A escalabilidade dos protocolos, algoritmos e mecanismos de QoS é um assunto de pesquisa 
(P&D) e se torna particularmente relevante quando consideramos a possibilidade de estender 
a garantia de QoS através de múltiplos domínios administrativos IP. 
 
A flexibilidade dos mecanismos de controle de QoS é um fator determinante na aceitabilidade 
do mesmos pela comunidade. 
 
3.3 QoS -Parâmetros 
 
Como definido anteriormente, a QoS necessária às aplicações é definida em termos de uma 
SLA. Na especificação das SLAs são definidos os parâmetros de qualidade de serviço e 
alguns dos mais comumente utilizados são: 
 
♦ Vazão (Banda) 
♦ Atraso (Latência) 
♦ JitterJI 
♦ Taxa de Perdas, Taxa de Erros, ... 
♦ Disponibilidade 
 
 8 
 
♦ Outros 
 
Em seguida, discute-se quais aplicações realmente necessitam da garantia de QoS e, em 
seguida, discute-se os parâmetros básicos de especificação da qualidade de serviço indicados 
acima. 
 
3.3.1 Quais Aplicações Necessitam de QoS? 
 
Inicialmente, é necessário considerar que não são todas as aplicações que realmente 
necessitam de garantias fortes e rígidas de qualidade de serviço (QoS) para que seu 
desempenho seja satisfatório. Dentre as novas aplicações identificadas anteriormente, as 
aplicações multimídia são, normalmente, aquelas que têm uma maior exigência de QoS. 
 
No mínimo, as aplicações sempre precisam de vazão (banda) e, assim sendo, este é o 
parâmetro mais básico e certamente mais presente nas especificações de QoS. Este 
parâmetro da qualidade de serviço é normalmente considerado durante a fase de projeto e 
implantação da rede e corresponde a um domínio de conhecimento bem discutido e relatado 
na literatura técnica. 
 
As considerações que seguem tentam identificar as exigências em termos de QoS das 
aplicações multimídia ilustrando algumas situações práticas. 
 
Uma aplicação multimídia offlineJI envolvendo, por exemplo, dados, gráficos e arquivos com 
animação (vídeo, ...) não necessita de sincronização e, assim sendo, não necessita de 
"cuidados especiais" (QoS) da rede. Observe que tem-se dados correspondentes a uma 
animação que, em termos práticos, necessita de uma determinada vazão, eventualmente 
carrega a rede, mas não exige atrasos, sincronização ou tempo de resposta. Este é um caso 
típico onde a necessidade de QoS reduz-se a uma necessidade de vazão, normalmente 
atendida pelo próprio projeto da rede. 
 
Por outrolado, para uma aplicação multimídia de conferência de áudio, garantir apenas a 
vazão não é suficiente. Neste caso específico, os atrasos de comunicação e as perdas de 
pacotes influenciam na interatividade dos usuários e na qualidade da aplicação. Considerando 
números, se esta aplicação gera uma vazão (fluxo de dados) de 64 Kbps, mesmo a utilização 
de uma LP (Linha Privada) em rede WAN de 256 Kbps pode não ser suficiente. Neste caso, os 
atrasos e perdas decorrentes da operação podem prejudicar a qualidade da aplicação. Diz-se 
então que a aplicação exige uma qualidade de serviço da rede. 
 
3.3.2 Vazão 
 
A vazão (banda) é o parâmetro mais básico de QoS e é necessário para a operação adequada 
de qualquer aplicação. 
 
Em termos práticos as aplicações geram vazões que devem ser atendidas pela rede. A tabela 
1 em seguida ilustra a vazão típica de algumas aplicações: 
 
Aplicação Vazão (Típica) 
 
 9 
 
Aplicações Transacionais 1 Kbps a 50 Kbps 
Quadro Branco (Whiteboard) 10 Kbps a 100 Kbps 
Voz 10 Kbps a 120 Kbps 
Aplicações Web (WWW) 10 Kbps a 500 Kbps 
Transferência de Arquivos (Grandes) 10 Kbps a 1 Mbps 
Vídeo (StreamingJI) 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 
Tabela 1 - Vazão Típica de Aplicações em Rede 
 
Como discutido, o atendimento do requisito vazão para a qualidade de serviço é um dos 
aspectos levados em conta no projeto da rede. 
 
3.3.3 Latência (Atraso) 
 
A latência e o atraso são parâmetros importantes para a qualidade de serviço das aplicações. 
Ambos os termos podem ser utilizados na especificação de QoS, embora o termo "latência" 
seja convencionalmente mais utilizado para equipamentos e o termo "atraso" seja mais 
utilizado com as transmissões de dados (P. ex.: atrasos de transmissão, atrasos de 
propagação, ...). 
 
De maneira geral, a latência da rede pode ser entendida como o somatório dos atrasos 
impostos pela rede e equipamentos utilizados na comunicação. Do ponto de vista da 
aplicação, a latência (atrasos) resulta em um tempo de resposta (tempo de entrega da 
informação - pacotes, ...) para a aplicação. 
 
Os principais fatores que influenciam na latência de uma rede são os seguintes: 
 
♦ Atraso de propagação (Propagation Delay); 
♦ Velocidade de transmissão e 
♦ Processamento nos equipamentos. 
 
O atraso de propagação corresponde ao tempo necessário para a propagação do sinal elétrico 
ou propagação do sinal óptico no meio sendo utilizado (fibras ópticas, satélite, coaxial, ...) e é 
um parâmetro imutável onde o gerente de rede não tem nenhuma influência. A tabela 2 em 
seguida ilustra a título de exemplo alguns valores para o atraso de propagação entre cidades 
numa rede WAN utilizando fibras ópticas como meio físico de comunicação. 
 
 
Trecho (Round Trip Delay) Atraso de Propagação 
Miami a São Paulo 100 mseg 
New York a Los Angeles 50 mseg 
Los Angeles a Hong Kong 170 mseg 
 
 10 
 
Tabela 2 - Atrasos de Propagação - Fibras Ópticas - Exemplos 
 
A velocidade de transmissão é um parâmetro controlado pelo gerente visando normalmente a 
adequação da rede à qualidade de serviço solicitada. Em se tratando de redes locais (LANs) 
[Tan96], as velocidades de transmissão são normalmente bastante elevadas, tendendo a ser 
tipicamente superior à 10 Mbps dedicada por usuário (p. ex.: utilizando LAN Switches [Mat97]). 
Além disso, considere-se também que: 
 
♦ Num cenário de redes locais (LANs - redes proprietárias confinadas) tem-se 
apenas custos de investimento e 
♦ Nas LANs não tem-se, pelo menos em termos de equipamentos, custos 
operacionais mensais. 
 
Em se tratando de redes de longa distância (Redes corporativas estaduais e nacionais, redes 
metropolitanas, intranets metropolitanas, ...) as velocidades de transmissão são dependentes 
da escolha de tecnologia de rede WAN (Linhas privadas, frame relay, satélite, ATM ,....). 
Embora exista obviamente a possibilidade de escolha da velocidade adequada para garantia 
da qualidade de serviço, observa-se neste caso restrições e/ ou limitações nas velocidades 
utilizadas, tipicamente devido aos custos mensais envolvidos na operação da rede. Além 
desse fator, observa-se também algumas restrições quanto à disponibilidade tanto da 
tecnologia quanto da velocidade de transmissão desejada. Em termos práticos, trabalha-se em 
WAN tipicamente com vazões da ordem de alguns megabits por segundo (Mbps) para grupos 
de usuários. 
 
O resultado das considerações discutidas é que a garantia de QoS é certamente mais crítica 
em redes MAN e WAN pelo somatório de dois fatores, ambos negativos: 
 
♦ Trabalha-se com velocidades (Vazão) mais baixas e 
♦ A latência (Atrasos) é muito maior quando compara-se com o cenário das redes 
locais. 
 
O terceiro fator que contribui para a latência da rede é a contribuição de atraso referente ao 
processamento realizado nos equipamentos. A título de exemplo, numa rede IP os pacotes 
são processados ao longo do percurso entre origem e destino por: 
 
♦ Roteadores (comutação de pacotes) 
♦ LAN Switches (comutação de quadros) 
♦ Servidores de Acesso Remoto (RAS) (comutação de pacotes, ...) 
♦ FirewallsJI (processamento no nível de pacotes ou no nível de aplicação, ...) 
♦ Outros 
 
Considerando que a latência é um parâmetro fim-a-fim, os equipamentos finais (hostsJI) 
também têm sua parcela de contribuição para o atraso. No caso dos hosts, o atraso depende 
de uma série de fatores, a saber: 
 
♦ Capacidade de processamento do processador; 
♦ Disponibilidade de memória; 
♦ Mecanismos de cache; 
 
 11 
 
Tempo
Pacotes no emissor
Pacotes no receptor∆T1 ∆T2 Pacotes fora
de ordem
♦ Processamento nas camadas de nível superior da rede (Programa de aplicação, 
camadas acima da camada IP, ...); 
♦ Etc ... 
 
Em resumo, observe-se que os hosts são também um fator importante para a qualidade de 
serviço e, em determinados casos, podem ser um ponto crítico na garantia de QoS. Esta 
consideração é particularmente válida para equipamentos servidores (Servers) que têm a 
tarefa de atender solicitações simultâneas de clientes em rede. 
 
3.3.4 Jitter 
 
O jitter é um outro parâmetro importante para a qualidade de serviço. No caso, o jitter é 
importante para as aplicações executando em rede cuja operação adequada depende de 
alguma forma da garantia de que as informações (pacotes) devem ser processadas em 
períodos de tempo bem definidos. Este é o caso, por exemplo, de aplicações de voz e fax 
sobre IP (VoIP), aplicações de tempo real, etc... 
 
Do ponto de vista de uma rede de computador, o jitter pode ser entendido como a variação no 
tempo e na seqüência de entrega das informações (p. ex.: pacotes) (Packet-Delay Variation) 
devido à variação na latência (atrasos) da rede. 
 
Conforme discutido no item anterior, a rede e seus equipamentos impõem um atraso à 
informação (p. ex.: pacotes) e este atraso é variável devido a uma série de fatores, a saber: 
 
♦ Tempos de processamento diferentes nos equipamentos intermediários 
(roteadores, switches, ...); 
♦ Tempos de retenção diferentes impostos pelas redes públicas (Frame relay, ATM, 
X.25, IP, ...) e 
♦ Outros fatores ligados à operação da rede. 
 
A figura 3.1 ilustra o efeito do jitter entre a entrega de pacotes na origem e o seu 
processamento no destino. Observe que o jitter causa não somente uma entrega com 
periodicidade variável (Packet-Delay Variation) como também a entrega de pacotes fora de 
ordem. 
 
 
 
 
 
 
 
 
 
Figura 3.1 - Efeito do Jitter para as Aplicações 
 
Em princípio, o problema dos pacotes fora de ordem poderia ser resolvido com o auxílio de um 
protocolo de transporte como o TCP (Transmission Control Protocol) [Ste94] que verifica o 
 
 12sequenciamento da mensagens e faz as devidas correções. Entretanto, na prática tem-se que 
a grande maioria das aplicações multimídia optam por utilizar o UDP (User Datagram Protocol) 
[Ste94] ao invés do TCP pela maior simplicidade e menor overhead deste protocolo. Nestes 
casos, o problema de sequenciamento deve ser resolvido por protocolos de mais alto nível 
normalmente incorporados à aplicação como, por exemplo, o RTP (Real Time Transfer 
Protocol) [Mau98]. 
 
O jitter introduz distorção no processamento da informação na recepção e deve ter 
mecanismos específicos de compensação e controle que dependem da aplicação em questão. 
Genericamente, uma das soluções mais comuns para o problema consiste na utilização de 
buffersJI ( Técnica de "buffering"). 
3.3.5 Perdas 
 
As perdas de pacotes em redes IP ocorrem principalmente em função de fatores tais como: 
 
♦ Descarte de pacotes nos roteadores e switch routersJI (Erros, congestionamento, 
...) e 
♦ Perda de pacotes devido à erros ocorridos na camada 2 (PPP - Point-to-Point 
Protocol, ethernet, frame relay, ATM, ...) durante o transporte dos mesmos. 
 
 
De maneira geral, as perdas de pacotes em redes IP são um problema sério para 
determinadas aplicações como, por exemplo, a voz sobre IP. Neste caso específico, a perda 
de pacotes com trechos de voz digitalizada implica numa perda de qualidade eventualmente 
não aceitável para a aplicação. O que fazer em caso de perdas de pacotes é uma questão 
específica de cada aplicação em particular. 
 
Do ponto de vista da qualidade de serviço da rede (QoS) a preocupação é normalmente no 
sentido de especificar e garantir limites razoáveis (Taxas de Perdas) que permitam uma 
operação adequada da aplicação. 
 
3.3.6 Disponibilidade 
 
A disponibilidade é um aspecto da qualidade de serviço abordada normalmente na fase de 
projeto da rede. 
 
Em termos práticos, a disponibilidade é uma medida da garantia de execução da aplicação ao 
longo do tempo e depende de fatores tais como: 
 
♦ Disponibilidade dos equipamentos utilizados na rede proprietária (Rede do cliente) 
(LAN, MAN ou WAN) e 
♦ Disponibilidade da rede pública, quando a mesma é utilizada (Operadoras de 
telecomunicações, carriersJI, ISPs - Internet Service Providers, ...). 
 
 
As empresas dependem cada vez mais das redes de computadores para a viabilização de 
seus negócios (Comércio eletrônico, home-bankingJI, atendimento onlineJI, transações online, 
...) e, neste sentido, a disponibilidade é um requisito bastante rígido. A título de exemplo, 
 
 13 
 
Protocolos, Algoritmos,
Técnicas, ... 
Rede Pública:
- ATM, FR, ...
LAN Switch Roteador
Firewall Hosts
Pacote IP
Mecanismos de QoS
Atuação - Gerente TI 
requisitos de disponibilidade acima de 99% do tempo são comuns para a QoS de aplicações 
WEB, aplicações cliente/ servidor e aplicações de forte interação com o público, dentre outras. 
 
4. QoS - Alternativas Técnicas 
 
Uma vez identificado os parâmetros relacionados com a qualidade de serviço das aplicações, 
discute-se os protocolos, mecanismos e algoritmos utilizados na implementação efetiva da 
qualidade de serviço. 
 
4.1 Cenário - Implementação da QoS 
 
Numa rede IP a qualidade de serviço consiste num mecanismo fim-a-fim (host de origem a 
host de destino) de garantia de entrega informações (Pacotes, ...). Assim sendo, a 
implementação da garantia de QoS pela rede implica em atuar nos equipamentos envolvidos 
na comunicação fim-a-fim visando o controle dos parâmetros de QoS. 
 
Os parâmetros (atrasos, jitter, ....) que devem ser controlados visando a obtenção da 
qualidade de serviço não são, infelizmente, localizados num único equipamento ou 
componente da rede. A figura 4.1 em seguida ilustra um exemplo de situação onde na 
trajetória fim-a-fim dos pacotes tem-se equipamentos tipo LAN Switch, roteadores, Firewalls, 
utiliza-se uma rede pública de comutação de pacotes e, obviamente, tem-se os próprios hosts 
dos usuários finais. 
 
Os mecanismos de QoS devem portanto atuar nestes equipamentos, camadas de protocolo e 
entidades de forma cooperada. Uma das atribuições dos gerentes de Tecnologia da 
Informação (TI) é justamente a escolha e implementação adequada dos mecanismos de QoS 
discutidos adiante num cenário como o da figura 4.1. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 4.1 - Equipamentos e Componentes de Rede Envolvidos na Qualidade de Serviço 
(QoS) 
 
 
 14 
 
Uma outra questão importante a perceber-se na implementação dos mecanismos de controle 
da qualidade de serviço é a percepção do momento onde estes mecanismos são necessários. 
Efetivamente, a necessidade de garantir a qualidade de serviço se coloca mais fortemente 
nos períodos de pico de tráfego quando a rede enfrenta uma situação de congestionamento ou 
de carga muito elevada. Neste tipo de situação os mecanismos de QoS buscam soluções para 
decisões do tipo: 
 
♦ Como alocar os escassos recursos (p. ex.: banda) 
♦ Como selecionar o tráfego de pacotes 
♦ Como priorizar os pacotes 
♦ Como descartar pacotes (quais e quando) 
 
4.2 QoS em Redes IP - Alternativas Técnicas 
 
As alternativas técnicas básicas para a qualidade de serviço em redes IP são as seguintes: 
 
♦ IntServ - Integrated Services Architecture com o RSVP (Resource Reservation 
Protocol); 
♦ DiffServ - Differentiated Services Framework; 
♦ MPLS (MultiProtocol Label Switching); 
♦ SBM (Subnet Bandwidth Management); 
♦ Dimensionamento e 
♦ Soluções Proprietárias. 
 
Todas as alternativas citadas, excetuando-se as soluções proprietárias, são iniciativas do IETF 
(Internet Engineering Task Force) [IETF]. O IETF está fortemente empenhado em propor um 
conjunto de soluções para os mecanismos de controle de QoS que garanta a 
interoperabilidade dos mesmos entre diferentes fornecedores. Isto se dá em função da 
importância das redes IP para o suporte de novas aplicações multimídia, tempo real, etc. 
 
Em seguida, resume-se os princípios, os mecanismos específicos e a estratégia destas 
alternativas técnicas. 
 
4.2.1 Int Serv - Integrated Services Architecture e RSVP - Resource 
Reservation Protocol 
 
A alternativa técnica IntServ [IntServCharter] está atualmente sendo definida pelo IETF e 
corresponde a um conjunto de recomendações (RFCs - Request for Comments) visando a 
implantação de uma infra-estrutura robusta para a Internet que possa suportar o transporte de 
áudio, vídeo e dados em tempo real além do tráfego de dados transportado na infra-estrutura 
atual. 
 
O conjunto de recomendações proposto é denominado de "Arquitetura de Serviços Integrados" 
(Integrated Services Architecture) [Brad94] e visa uma garantia de qualidade de serviço (QoS) 
para as aplicações. 
 
A arquitetura IntServ tem um princípio básico de concepção (Princípio arquitetural): 
 
 15 
 
A qualidade de serviço (QoS) na arquitetura IntServ é garantida através de 
mecanismos de reserva de recursos na rede. 
 
Na arquitetura IntServ a aplicação reserva os recursos que vai utilizar antes de iniciar o envio 
de dados (áudio, vídeo, ...) pela rede. 
 
Na definição da arquitetura IntServ dois aspectos operacionais precisam ser definidos: 
 
1. Como as aplicações solicitam sua necessidade de QoS à rede, ou seja, como elas 
fazem suas reservas e 
2. Como os elementos da rede (Roteadores, ...) devem proceder para garantir a 
qualidade de serviço solicitada (Garantir a reserva). 
 
As aplicações solicitam suas necessidades de QoS à rede através do protocolo de sinalização 
RSVP (Resource Reservation Protocol) [Rsvp_2205] onde: 
 
♦ A aplicação cliente identifica sua necessidade de QoS; 
♦ A aplicação cliente solicita à rede a garantia da qualidade de serviço que lhe é 
conveniente (Reserva) através do protocolo RSVP; 
♦ A rede (Equipamentos roteadores e switch routers) aceita eventualmentea 
solicitação e "tenta garantir" a reserva solicitada e 
♦ Uma vez aceita a reserva, os fluxos de dados (streams) correspondentes à 
aplicação são identificados e roteados segundo a reserva feita para os mesmos. 
 
O RSVP é um protocolo de sinalização que atua sobre o tráfego de pacotes (p. ex.: pacotes 
IP) numa rede (Internet, redes privadas, ...). O RSVP é um protocolo eficiente do ponto de 
vista da qualidade de serviço (QoS) na medida em que provê granularidade e controle fino das 
solicitações feitas pelas aplicações. Sua maior desvantagem é a complexidade inerente à sua 
operação nos roteadores que, eventualmente, pode causar dificuldades nos backbonesJI de 
grandes redes. 
 
O RSVP é um protocolo bem aceito pelo mercado e é disponibilizado na grande maioria dos 
ambientes operacionais (Unix, NT, Windows 98, ...) e equipamentos de rede de diversos 
fornecedores. 
 
A maneira como os elementos de rede devem proceder para a garantia da qualidade de 
serviço solicitada é detalhada em várias recomendações (RFCs) relacionadas à arquitetura 
IntServ. Segue comentários sobre algumas recomendações mais importantes: 
 
RFC 2211 - Specification of the Controlled-Load Network Element Service: Define 
como um elemento de rede (Roteador, ...) garante uma solicitação de reserva para um 
serviço de "carga controlada" solicitado por uma aplicação. 
 
RFC 2212 - Specification of Guaranteed Quality of Service: Define como um elemento 
de rede (Roteador, ...) garante uma solicitação de reserva para um serviço tipo 
"garantido" solicitado por uma aplicação. 
 
RFC 2215 - General Characterization Parameters for Integrated Services Network 
Elements: Define o conjunto de parâmetros gerais de caracterização e controle dos 
fluxos com QoS para os elementos da rede (Roteadores, ...). 
 
 16 
 
Classificador de
Pacotes
(Classifier)
Marcador de
Pacotes
(Marker)
Monitor de
Pacotes
(Traffic Meter)
Condicionador de
Pacotes
(Traffic Conditioner)
• Classifica Pacotes
• Marca Pacotes • Monitora fluxos de
 Pacotes
• Processa os Pacotes
 
RFC 2213 - Integrated Services Management Information Base using SMIv2: Define 
aspectos técnicos relativos à base de dados de gerenciamento dos serviços na 
arquitetura IntServ. 
 
Para uma relação completa de recomendações relacionadas com a arquitetura IntServ 
consultar [JSMNet] e [IntServ_Charter]. 
 
4.2.2 DiffServ - Differentiated Services Framework 
 
A alternativa técnica DiffServ [DiffServer_Charter] é uma outra iniciativa do IETF com o 
objetivo de permitir também o transporte de áudio, vídeo, dados em tempo real e dados 
"convencionais" na Internet. 
 
A alternativa DiffServ tem um princípio básico de concepção (Princípio arquitetural): 
 
A qualidade de serviço na solução DiffServ é garantida através de 
mecanismos de priorização de pacotes na rede. 
 
A solução DiffServ não utiliza nenhum tipo de mecanismo de reserva de recursos. Nesta 
solução os pacotes são classificados, marcados e processados segundo o seu rótulo (DSCP - 
Differentiated Service Code Point) [Dscp_2474]. 
 
A idéia básica da solução DiffServ é reduzir o nível de processamento necessário nos 
roteadores para fluxos de dados (streams). Isto é realizado com a definição de poucas 
"Classes de Serviço" numa estrutura comum de rede. 
 
Os inúmeros fluxos de tráfego (Pacotes IP) gerados pelas aplicações são agregados a poucas 
classes de serviço em função da qualidade de serviço (QoS) especificada para o fluxo. Esta 
tarefa é tipicamente realizada nos roteadores de entrada do backbone (Edge routersJI) e, desta 
forma, o processamento nos roteadores intermediários (CoreJI) fica mais simplificado e 
independente dos fluxos individuais das aplicações. 
 
Os roteadores de backbone/ core processam os pacotes (Forwarding) segundo basicamente 
as "classes de serviço". Em outras palavras, os roteadores de backbone roteiam "agregados 
de fluxos". 
 
A figura 4.2 adiante ilustra os blocos funcionais principais num equipamento (Roteador, ...) 
utilizando a solução DiffServ. Todas as funções estão normalmente presentes nos roteadores 
de entrada e saída da rede (Edge routers) e, eventualmente, são acionadas nos roteadores 
intermediários (Core routers/ Backbone routers). 
 
 
 
 
 
 
 
 
 
 17 
 
0 1 2 3 4 ` 5 6 7 
NUDSCP
Differentiated Service
Code Point
RFC 2474
NU - Não utilizado
0 1 2 3 4 ` 5 6 7 
ZPrecedence
Campo TOS no 
IPv4 (RFC 791)
RFC 1122
Z - Zero
Type of
Service
RFC 1349
Class Selector
 
 
 
 
Fig. 4.2 - Blocos Funcionais do DiffServ 
 
A figura 4.3 ilustra a marcação dos DSCP para o protocolo IPv4. No IPv4 utiliza-se o campo 
TOS (Type of Service) do IP. No IPv6 utiliza-se o campo "Traffic Class". 
 
Em resumo, a operação de DiffServ é como segue: 
 
Cada pacote recebe um processamento baseado na sua marcação (DSCP). O DiffServ define 
duas classes de serviço que podem também ser entendidas como "comportamentos" (PHB - 
Per-Hop Behavior), na medida em que definem como os equipamentos (Roteadores, ...) se 
comportam com relação aos pacotes (Como os pacotes são processados): 
 
♦ Expedited Forwarding (EF): 
Esta classe de serviço provê o maior nível de qualidade de serviço. A idéia é emular 
uma linha dedicada convencional minimizando os atrasos, probabilidade de perda e 
jitter para os pacotes. EF utiliza mecanismos de traffic shapingJI, buferização 
(buffering) e priorização de filas discutidos adiante. 
 
♦ Assured Forwarding (AF): 
Esta classe de serviço emula um comportamento semelhante a uma rede com pouca 
carga mesmo durante a ocorrência de congestionamento. A latência negociada é 
garantida com um alto grau de probabilidade. O serviço AF define 4 níveis de 
prioridade de tráfego (Ouro, Prata, Bronze e Best EffortJI) (Os níveis de prioridade 
foram inspirados na premiação dos jogos olímpicos). Para cada nível de prioridade 
são definidos 3 preferências de descarte de pacotes (semelhante ao Frame Relay). 
Este serviço usa mecanismos de Traffic Shaping (Token Bucket) e usa o algoritmo 
RED (Randon Early Detection), discutido adiante, durante o congestionamento. 
 
Outros serviços poderão ser definidos no escopo das recomendações DiffServ. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 18 
 
Fig 4.3 - DSCP - Differentiated Service Code Point 
As alternativas IntServ e DiffServ não são concorrentes ou mutualmente exclusivas. Na 
realidade, estas são soluções complementares que podem ser utilizadas conjuntamente. Uma 
alternativa de uso conjunto das duas soluções seria a utilização do DiffServ no backbone de 
roteadores (core), na medida em que é uma solução mais "leve" e o IntServ/ RSVP nas redes 
de acesso, na medida em que provê um bom controle com granularidade dos requisitos de 
QoS das aplicações. 
 
A solução DiffServ ainda está em fase de desenvolvimento e, no momento, é menos presente 
que a solução IntServ/ RSVP nos ambientes operacionais e equipamentos de rede. 
 
Para uma relação completa de recomendações relacionadas com a arquitetura DiffServ 
consultar [JSMNet] e [DiffServ_Charter]. 
 
 
4.2.3 MPLS - MultiProtocol Label Switching 
 
A solução MPLS [Mpls_Charter] tem uma certa relação com a questão da qualidade de serviço 
em redes e, neste sentido, é importante discutir os seus princípios. 
 
Do ponto de vista técnico a solução MPLS tem algumas similaridades com a solução DiffServ, 
a saber: 
 
♦ Os pacotes são marcados com um rótulo (MPLS Label) de 20 bits; 
♦ Os pacotes são marcados pelo MPLS na entrada da rede (MPLS edge routers) e 
♦ Os rótulos são retirados dos pacotes na saída da rede (MPLS edge routers). 
 
No que toca a operação, o MPLS utiliza os seus rótulos basicamente para indicar o próximo 
roteador (Next hop) para onde o pacote deve serencaminhado (Forwarding). Este aspecto 
operacional diferencia-o substancialmente das soluções anteriores na medida em que: 
 
♦ O MPLS é uma solução mais orientada para uma engenharia de tráfego de 
pacotes na rede que para uma garantia efetiva de qualidade de serviço (QoS); 
♦ Um dos ganhos mais importantes com a utilização do MPLS é a simplificação da 
função de roteamento nos roteadores, reduzindo assim o overheadJI nos mesmos 
e as suas latências. 
 
Obviamente, com a redução da latência nos roteadores, melhora-se as condições de operação 
na rede e isso leva a uma melhor qualidade de serviço. Entretanto, o MPLS não provê 
controles específicos quanto à garantia de QoS na rede. 
 
Outros aspectos que diferenciam o MPLS das soluções InteServ e DiffServ são os seguintes: 
 
♦ O MPLS não é controlável pela aplicação. Não existe API (Application 
Programmming Interface) para o MPLS nos hosts; 
♦ O MPLS é residente apenas nos roteadores; 
♦ O MPLS é independente do protocolo de rede (IP, IPX, ...), o que representa uma 
vantagem importante desta solução. 
 
 19 
 
LAN12
IP3
4
Camadas
Superiores
Aplic.
Comunicação entre camadas deve
ser priorizada (Aspecto local dos
hosts)
IP
Como habilitar QoS nas tecnologias
de redes locais (LANs)
IntServ, DiffServ,
RSVP, MPLS, ...
TCP, UDP, ...
 
Para a operação efetiva do MPLS faz-se necessário a distribuição dos rótulos (MPLS Labels) 
entre os roteadores e a gerência dos mesmos. O protocolo LDP (Label Distribution Protocol) 
[LDP_Spec] é um protocolo de sinalização desenvolvido com esta finalidade. 
 
4.2.4 SBM - Subnet Bandwidth Management 
 
A garantia de qualidade de serviço (QoS) é fim-a-fim, ou seja, envolve os equipamentos de 
rede (Roteadores, ...), os hosts de origem e destino e os equipamentos e tecnologias utilizados 
nas suas interconexões (Redes locais, LAN Switches, redes públicas, ...). Desta forma a 
garantia de qualidade de serviço, como numa corrente, tem como seu ponto mais fraco o elo 
mais frágil da cadeia de comunicação fim-a-fim e, neste sentido, todos os elos são 
importantes. 
 
As soluções discutidas anteriormente abordam a garantia de QoS usando mecanismos de 
reserva de recursos e priorização exclusivamente para o tráfego de pacotes no nível 3 (Nível 
de rede) que, certamente, é o elo mais crítico da cadeia. 
 
No que toca a garantia da qualidade de serviço nos hosts e interconexões, tem-se dois 
aspectos básicos a considerar conforme ilustrado na figura 4.4: 
 
♦ A comunicação entre a aplicação e as camadas superiores da rede (Níveis 4, 5 ...) 
deve ser priorizada para as aplicações com requisitos de QoS. Normalmente, este 
é um aspecto local vinculado ao ambiente operacional (Sistema operacional, 
cache, ...) e utiliza recursos específicos do ambiente. O ajuste e definição desta 
"priorização" é uma tarefa normalmente atribuída ao gerente da rede ou do 
sistema em particular. 
♦ Um segundo aspecto da qualidade de serviço nos hosts (origem e destino) e nas 
interconexões dos equipamentos é a garantia de QoS nas tecnologias de nível 2 
(Ethernet, FDDI, outras). Segue uma discussão referente a esta questão em 
particular. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 20 
 
Figura 4.4 - QoS nos Hosts 
 
A garantia de qualidade de serviço com as tecnologias de nível 2 se coloca nas seguintes 
situações práticas: 
 
♦ Comunicação host - roteador; 
♦ Comunicação roteador - host e 
♦ Comunicação roteador - roteador em redes locais (LANs). 
 
Neste caso, a questão que deve ser resolvida é a seguinte: 
 
Como garantir que quadros (Frames) com pacotes prioritários (vinculados a um fluxo com 
QoS) possam ser priorizados entre si ? 
 
Este problema pode ser abordado em determinados tipos de redes como segue: 
 
♦ Nas implementações do ethernet usando LAN Switches, os padrões IEEE 802.1p 
e 802.1Q definem mecanismos de priorização de quadros; 
♦ A tecnologia ATM tem embutida na sua concepção e definição inúmeros recursos 
para a garantia de qualidade de serviço das células e, assim sendo, pode 
facilmente priorizar células com pacotes prioritários; 
♦ Outras tecnologias como o FDDI (Fiber Distributed Data Interface) possuem bits 
de prioridade que podem ser utilizados também para priorizar quadros com 
pacotes vinculados a fluxos com QoS. 
 
A questão mais global que segue é como definir e, eventualmente, padronizar o mapeamento 
da qualidade de serviço das aplicações com os diferentes mecanismos existentes nas 
tecnologias de rede de nível 2. 
 
Neste contexto o IETF está trabalhando na iniciativa ISSLL (Integrated Services over Specific 
Link Layers) [ISSLL_Charter]. 
 
O objetivo da iniciativa ISSLL é o mapeamento dos protocolos e serviços de QoS de nível 
superior (N ≥ 3) nos mecanismos dos protocolos de nível 2 como, por exemplo, o ethernet. Um 
dos resultados desta iniciativa é o desenvolvimento do SBM (Subnet Bandwidth Management) 
[SBM_Draft] para tecnologias de nível 2 compartilhadas (P. ex.: ethernet em hubs) e 
comutadas (P. ex.: ethernet em LAN Switches). 
 
O ISSLL define aspectos como: 
 
♦ Estrutura de operação e comunicação SBM; 
♦ Mapeamento da QoS (Nível superior <--------> Nível 2) e 
♦ Protocolo de sinalização. 
 
Para uma relação completa de recomendações relacionadas com a solução SBM consultar 
[JSMNet] e [ISSLL_Charter]. 
 
 
 21 
 
4.2.5 Dimensionamento 
 
A alternativa denominada "dimensionamento" é o que pode chamar-se de uma alternativa 
trivial. A idéia é bastante simples. No caso, a rede e seus recursos são dimensionados na fase 
de projeto de forma a não termos congestionamento. Por exemplo, faz-se um super-
dimensionamento da banda utilizada o que resulta na ausência de congestionamento ou de 
períodos de escassez de recursos durante a operação da rede. 
 
Esta solução apresenta duas dificuldades principais. A primeira corresponde ao custo 
associado na implementação do super-dimensionamento. Em particular para as redes WAN 
esta normalmente é uma alternativa proibitiva. A segunda dificuldade é a identificação dos 
pontos de ocorrência de congestionamento dada a multiplicidade e diversidade de 
equipamentos utilizados e a própria complexidade das redes. 
 
De maneira geral, esta não é uma solução muito prática e realista embora seja factível. 
 
5. QoS - Mecanismos 
 
As alternativas técnicas discutidas são implementadas através da utilização de diversos tipos 
de mecanismos, a saber: 
 
♦ Protocolos de sinalização 
♦ Algoritmos de prioridade 
♦ Algoritmos de escalonamento 
♦ Algoritmos de controle de filas 
♦ Algoritmos de congestionamento 
 
Em seguida, discutimos a funcionalidade e aplicabilidade de cada um destes mecanismos e 
identificamos implementações dos mesmos que são utilizadas em roteadores, hosts e outros 
equipamentos visando a garantia de qualidade de serviço. 
 
5.1 Protocolos de Sinalização 
 
A finalidade de um protocolo de sinalização (Signalling Protocol) [Wu98] no contexto da 
qualidade de serviço em redes IP pode ser entendida como segue: 
 
♦ O protocolo de sinalização é utilizado pelas aplicações (hosts) para informar ou 
solicitação à rede sua necessidade de qualidade de serviço (QoS); 
♦ Além disso, os protocolos de sinalização permitem também que os equipamentos 
de rede (Roteadores, ...) possam trocar informações no sentido de cooperarem 
visando a garantia da qualidade de serviço aceita pela rede. 
 
Segue exemplos de protocolos de sinalização no contexto da qualidade de serviço: 
 
♦ RSVP - Resource Reservation Protocol: utilizado na iniciativa IntServ do IETF 
♦ LDP - Label Distribution Protocol: utilizado na alternativa MPLS para a distribuição 
de rótulos entre os equipamentos roteadores. 
 
 22 
 
 
5.2 Prioridades 
 
Os algoritmos de prioridade (Priority Algorithms) são um outro mecanismoutilizado pelos 
equipamentos de rede para a garantia da qualidade de serviço. Neste contexto, a prioridade 
pode ser entendida como um mecanismo que provê diferentes tempos de espera para o 
processamento da informação (P. ex.: pacotes e/ ou quadros). 
 
Estes algoritmos são tipicamente implementados em roteadores mas algumas tecnologias de 
rede de nível 2 também suportam a utilização deste mecanismos. 
 
Segue alguns exemplos de algoritmos utilizados: 
 
♦ IP Precedence: 
IP Precedence é definido na RFC 1122 e é uma solução de priorização de pacotes 
prevista no IPv4 no campo TOS (Type of Service) do cabeçalho dos pacotes IP. 
 
♦ Priority Queuing: 
Algoritmo utilizado por alguns fornecedores utilizado para priorização de pacotes IP 
nas filas de saída de roteadores. 
 
Dentre as tecnologias de rede de nível 2 mais difundidas que suportam mecanismos de 
priorização eventualmente úteis na implantação de garantias de qualidade de serviço, 
podemos citar: 
 
♦ ATM (Asynchronous Transfer Mode); 
♦ Ethernet em LAN Switches (Padrões IEEE 802.1p e IEEE 802.1Q); 
♦ FDDI (Fiber Distributed Data Interface); 
♦ Token Ring e 
♦ 100VG-AnyLAN 
 
5.3 Escalonamento 
 
No contexto da qualidade de serviço discutida, o mecanismo de escalonamento tipicamente 
presente em equipamentos roteadores procura garantir que fluxos (streams) diferentes de 
pacotes obtêm os recursos que lhes foram alocados (banda e processamento). No caso, a 
banda e o processamento disponíveis são distribuídos de forma justa (Fairness) entre os 
fluxos ativos existentes no equipamento em questão. 
 
Alguns dos mecanismos de escalonamento utilizados são os seguintes: 
 
♦ WRR - Weighted Round Robin 
♦ GPS - Generalized Processor Sharing 
♦ CBQ - Class Based Queuing 
♦ WFQ - Weighted Fair Queuing 
 
 
 23 
 
5.4 Controle de Filas 
 
Um outro aspecto que deve ser controlado numa fila diz respeito aos mecanismos de descarte 
de pacotes. A política de descarte de pacotes é necessária na ocorrência de um 
congestionamento e visa igualmente a garantia de eqüidade (Fairness) quanto à distribuição 
da banda e do processamento. Estes mecanismos normalmente não fazem nenhuma tentativa 
de evitar proativamente a ocorrência do congestionamento e podem ser parte integrante dos 
algoritmos de escalonamento de filas. 
 
Segue alguns exemplos de algoritmos lidando com o controle de filas: 
 
♦ SFQ - Stochastic Fair Queuing 
♦ CFQ - Class-Based Fair Queuing 
♦ WFQ - Weighted Fair Queuing 
 
Como no caso anterior, estes mecanismos são utilizados tipicamente em equipamentos 
roteadores. 
 
5.5 Congestionamento 
 
Os mecanismos de controle de congestionamento são também importantes para a 
implantação da qualidade de serviço numa rede IP. A idéia básica destes mecanismos é a 
inibição dos fluxos de pacotes durante o período de congestionamento de forma que os 
geradores de fluxos de pacotes IP reduzam a sua carga sobre a rede. Com menos pacotes 
sendo entregues à rede tem-se uma tendência de redução no nível de congestionamento. 
Neste sentido, estes mecanismos podem ser entendidos como mecanismos de controle de 
fluxo de pacotes. 
 
Segue alguns exemplos de algoritmos lidando com o congestionamento de filas de pacotes IP: 
 
♦ RED - Random Early Detection 
♦ WRED - Weighted Random Early Detection 
♦ ECN - Explicit Congestion Notification 
 
 
Bibliografia 
 
[Com95] Douglas E. Comer, "Internetworking with TCP/IP - Principles, Protocols and 
Architecture", Vol. 1, Prentice-Hall, 1995. 
 
[Dscp_2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Differentiated Services 
Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, 1998. 
 
[Dan98] Daniel Minoli and Emma Minoli, "Delivering Voice over Frame Relay and ATM", 
Wiley Computer Publishing, 1998. 
 
[Dav96] David Ginsburg, "ATM Solutions for Enterprise Internetworking", Addison-
Wesley, 1996. 
 
 24 
 
 
[DiffServ_2474] K. Nichols, S. Blake, F. Baker, D. Black, “Definition of the Differentiated Services 
Field (DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, December 1998 
 
[DiffServ_2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, “An Architecture 
for Differentiated Services”, RFC 2475, December 1998 
 
[DiffServ_2597] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, “Assured Forwarding PHB 
Group”,RFC 2597, June 1999 
 
[DiffServ_2598] V. Jacobson, K. Nichols, K. Poduri, “An Expedited Forwarding PHB”, RFC 2598, 
June 1999 
 
[DiffServ_Charter] "IETF Differentiated Services Working Group". Em 
http://www.ietf.org/html.charters/diffser-charter.html e 
http://www.ietf.org/ids.by.wg.diffserv.html 
 
[IntServ_2211] J. Wroclawski, "Specification of the Controlled-Load Network Element Service", 
RFC 2211, September 1997 
 
[IntServ_2212] S. Shenker, C. Partridge, R. Guerin, "Specification of Guaranteed Quality of 
Service", RFC 2212, Sept 1997 
 
[IntServ_2215] S. Shenker, J. Wroclawski, “General Characterization Parameters for Integrated 
Service Network Elements”, RFC 2215, September 1997 
 
[IntServ_2216] S. Shenker, J. Wroclawski, "Network Element Service Specification Template", 
RFC 2216, Sept 1997 
 
[IntServ_Charter] "IETF Integrated Services Working Group". Em 
http://www.ietf.org/html.charters/intserv-charter.html e 
http://www.ietf.org/ids.by.wg/intserv.html 
 
[ISSLL_Charter] "Integrated Services over Specific Link Layers", Em 
http://www.ietf.org/html.charters/issll-charter.html 
 
[Jam98] James D. McCabe, Practical Computer Network Analysis and Design, Morgan 
Kaufmann Series in Networking, 1998. 
 
[Job99] Joberto Martins, "Redes Corporativas MultiServiço - Caracterização das 
Aplicações e Parâmetros Básicos de Operação", Em 
http://www.jsmnet.com/slides/AnaliseRequisitos/index.htm 
 
[JSMNet] "JSMNet - Estado da Arte e P&D em Redes de Computadores". 
Em http://www.jsmnet.com 
 
[LDP_Spec] B. Thomas, N. Feldman, P. Doolan, L. Andersson, A. Fredette, “LDP 
Specification”, June 1999, 
<draft-ietf-mpls-ldp-05.txt>, Work in Progress. 
 
 
 25 
 
[Mat97] Mathias Hein and David Griffiths, "Switching Technology in the Local Network - 
From LAN to Switched LAN to Virtual LAN", Thomson Computer Press, 1997. 
 
[Mau97] Thomas A. Maufer, "Deploying IP Multicast in the Enterprise", Prentice-Hall, 
1997. 
 
[Mpls_Charter] IETF “Multiprotocol Label Switching” Working Group. Em 
http://www.ietf.org/html.charters/mpls-charter.html e 
http://www.ietf.org/ids.by.wg/mpls.html 
 
[Rsvp_2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, “Resource ReSerVation 
Protocol (RSVP) – Version 1 Functional Specification”, RFC 2205, September 
1997 
 
[SBM_Draft] R. Yavatkar, D. Hoffman, Y. Bernet, F. Baker, “SBM (Subnet Bandwidth 
Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style 
networks”, May 1999, 
<draft-ietf-issll-is802-sbm-08.txt>, Work in Progress. 
 
[Ste94] W. Richard Stevens, "TCP/IP Illustrated - The Protocols", Vol. 1, Addison-
Wesley, 1994. 
 
[Tan96] Andrew Tanembaum, "Computer Networks", 3rd edition, Prentice-Hall, 1996. 
 
[Tho96] Stephen A. Thomas, "IPng and the TCP/IP Protocols - Implementing the Next 
Generation Internet", Wiley Computer Publishing, 1996. 
 
[Wu98] Chwan-Hwa Wu and J. David Irwin, "Emerging Multimedia Computer 
Communication Technologies", Prentice-Hall, 1998. 
 
Joberto obteve seu Doctorat em Informática pela Université Pierre et Marie Curie - França, em 1986, desenvolveu trabalhos em 
Pós-Doutorado junto ao ICSI da Universidade de Berkeley (USA) em 1995, obteve o Masters Degree em Engenharia Eletrônica 
pelo Philips International Institute for Technological Studies (PII), Eindhoven, Holanda, em 1979 e graduou-se em Engenharia 
Eletrônica pela UFPb em 1977. 
 
Atualmente, tem atuado como consultor e diretor da ITELCON/ITC em Projetosde Interconexão de Redes, Redes Corporativas, 
Redes TCP/IP e Redes de Alta Velocidade. Em termos das atividades de consultoria, a atuação tem sido em projetos de grande 
porte para grandes empresas e instituições nacionais como a Petrobras, CPQD, CVRD, FDTE-USP, Albras, Ferbasa, 
USIMINAS, CST e o Governo do Estado de São Paulo, dentre outras. 
 
Além de suas atividades profissionais em consultoria e treinamento profissional especializado atua como Professor Titular do 
Departamento de Informática da UFPB, é professor e assessor da Universidade de Salvador (UNIFACS), é membro da 
Comissão de Especialistas em Informática e consultor do MEC, atua como pesquisador e professor orientando e lecionando 
disciplinas, é pesquisador do CNPq e é autor de diversos trabalhos em revistas, periódicos e congressos nacionais e 
internacionais. 
 
No que toca suas atividades anteriores já atuou como Diretor do ITEEL (Instituto de Tecnologia Eletro-Eletrônica), ministrou 
cursos como Professor Visitante no Pós-Graduação da área de Redes e Comunicação de Dados na Université Paris VI e no 
Institut National des Télécommunications (INT) na França, e em congressos e empresas nacionais, coordenou e desenvolveu 
pesquisas através do programa de projetos temáticos do CNPq (PROTEM), orientou 12 teses de mestrado e dezenas de 
trabalhos de pós-garduação. 
 
Informações detalhadas sobre as atividades acima citadas podem ser encontradas em www.jsmnet.com