Texto QoS_IP_Itelcon - Universidade Santa Cecília

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
1
1. INTRODUÇÃO
3
2. CENÁRIO E NOVAS APLICAÇÕES EM REDES IP
3
2.1 "QUALQUER APLICAÇÃO SOBRE REDE DE PACOTE"
2.2 "QUALQUER APLICAÇÃO SOBRE REDES IP"
2.3 DESAFIOS - REDES IP
2.4 NOVAS APLICAÇÕES
3
4
5
5
3. QUALIDADE DE SERVIÇO (QOS)
6
3.1 QUALIDADE DE SERVIÇO (QOS) - PRINCÍPIOS
3.2 QOS COMO MECANISMO GERENCIAL
3.3 QOS -PARÂMETROS
3.3.1 QUAIS APLICAÇÕES NECESSITAM DE QOS?
3.3.2 VAZÃO
3.3.3 LATÊNCIA (ATRASO)
3.3.4 JITTER
3.3.5 PERDAS
3.3.6 DISPONIBILIDADE
6
7
7
8
8
9
11
12
12
4. QOS - ALTERNATIVAS TÉCNICAS
13
4.1 CENÁRIO - IMPLEMENTAÇÃO DA QOS
4.2 QOS EM REDES IP - ALTERNATIVAS TÉCNICAS
4.2.1 INT SERV - INTEGRATED SERVICES ARCHITECTURE E RSVP - RESOURCE RESERVATION
PROTOCOL
4.2.2 DIFFSERV - DIFFERENTIATED SERVICES FRAMEWORK
4.2.3 MPLS - MULTIPROTOCOL LABEL SWITCHING
4.2.4 SBM - SUBNET BANDWIDTH MANAGEMENT
4.2.5 DIMENSIONAMENTO
13
14
14
16
18
19
21
5. QOS - MECANISMOS
21
5.1 PROTOCOLOS DE SINALIZAÇÃO
5.2 PRIORIDADES
5.3 ESCALONAMENTO
5.4 CONTROLE DE FILAS
5.5 CONGESTIONAMENTO
21
22
22
23
23
2
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)
- Termos do Jargão Internacional (norte-americano) utilizados no texto visando uma simplificação da
nomenclatura utilizada.
JI
3
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
4
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 IP
Os 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
5
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:
6
♦ 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:
♦
♦
♦
♦
♦
7
Vazão (Banda)
Atraso (Latência)
JitterJI
Taxa de Perdas, Taxa de Erros, ...
Disponibilidade
♦ 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 outro lado, 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
8
Vazão (Típica)
Aplicações Transacionais
Quadro Branco (Whiteboard)
Voz
Aplicações Web (WWW)
Transferência de Arquivos (Grandes)
Vídeo (StreamingJI)
Aplicação Conferência
Vídeo MPEG
Aplicação Imagens Médicas
Aplicação Realidade Virtual
1 Kbps a 50 Kbps
10 Kbps a 100 Kbps
10 Kbps a 120 Kbps
10 Kbps a 500 Kbps
10 Kbps a 1 Mbps
100 Kbps a 1 Mbps
500 Kbps a 1 Mbps
1 Mbps a 10 Mbps
10 Mbps a 100 Mbps
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.
9
Trecho (Round Trip Delay)
Atraso de Propagação
Miami a São Paulo
New York a Los Angeles
Los Angeles a Hong Kong
100 mseg
50 mseg
170 mseg
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;
10
♦ 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.
Tempo
Pacotes no emissor
∆T1
∆T2
Pacotes fora
de ordem
Pacotes no receptor
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
11
sequenciamento 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,
12
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.
Pacote IP
Firewall
LAN Switch
Roteador
Hosts
Rede Pública:
- ATM, FR, ...
Mecanismos de QoS
Atuação - Gerente TI
Protocolos, Algoritmos,
Técnicas, ...
Figura 4.1 - Equipamentos e Componentes de Rede Envolvidos na Qualidade de Serviço
(QoS)
13
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):
14
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 eventualmente a
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, ...).
15
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).
Classificador de
Pacotes
(Classifier)
Condicionador de
Pacotes
(Traffic Conditioner)
Marcador de
Pacotes
(Marker)
Monitor de
Pacotes
(Traffic Meter)
• Classifica Pacotes
• Processa os Pacotes
16
• Marca Pacotes
• Monitora fluxos de
Pacotes
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.
0
1
2
3
4 ` 5
6
DSCP
7
NU
Differentiated Service
Code Point
NU - Não utilizado
Class Selector
RFC 2474
0
1
2
Precedence
3
4 ` 5
6
Type of
Service
7
Z
Campo TOS no
IPv4 (RFC 791)
Z - Zero
RFC 1122
17
RFC 1349
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 ser encaminhado (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.
18
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.
Aplic.
Camadas
Superiores
4
TCP, UDP, ...
3
IP
1
2
19
LAN
Comunicação entre camadas deve
ser priorizada (Aspecto local dos
hosts)
IP
IntServ, DiffServ,
RSVP, MPLS, ...
Como habilitar QoS nas tecnologias
de redes locais (LANs)
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].
20
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 superdimensionamento 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.
21
5.2 Prioridades
Os algoritmos de prioridade (Priority Algorithms) são um outro mecanismo utilizado 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:
♦
♦
♦
♦
22
WRR - Weighted Round Robin
GPS - Generalized Processor Sharing
CBQ - Class Based Queuing
WFQ - Weighted Fair Queuing
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", AddisonWesley, 1996.
23
[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.
24
[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, AddisonWesley, 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 Projetos de 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
25