1

Qualidade de Servio (QoS) em Redes IP

Princpios Bsicos, Parmetros e Mecanismos













Fonte : Prof. Dr Joberto Martins
www.itelcon.com.br
Por: Prof Hugo Santana
Universidade Santa Ceclia - Unisanta


2



1. INTRODUO 3
2. CENRIO E NOVAS APLICAES EM REDES IP 3
2.1 "QUALQUER APLICAO SOBRE REDE DE PACOTE" 3
2.2 "QUALQUER APLICAO SOBRE REDES IP" 4
2.3 DESAFIOS - REDES IP 5
2.4 NOVAS APLICAES 5
3. QUALIDADE DE SERVIO (QOS) 6
3.1 QUALIDADE DE SERVIO (QOS) - PRINCPIOS 6
3.2 QOS COMO MECANISMO GERENCIAL 7
3.3 QOS -PARMETROS 7
3.3.1 QUAIS APLICAES NECESSITAM DE QOS? 8
3.3.2 VAZO 8
3.3.3 LATNCIA (ATRASO) 9
3.3.4 JITTER 11
3.3.5 PERDAS 12
3.3.6 DISPONIBILIDADE 12
4. QOS - ALTERNATIVAS TCNICAS 13
4.1 CENRIO - IMPLEMENTAO DA QOS 13
4.2 QOS EM REDES IP - ALTERNATIVAS TCNICAS 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 SINALIZAO 21
5.2 PRIORIDADES 22
5.3 ESCALONAMENTO 22
5.4 CONTROLE DE FILAS 23
5.5 CONGESTIONAMENTO 23




3

1. Introduo

A Qualidade de Servio (QoS
JI
) em redes um aspecto de implantao e operao importante
para as redes de pacote como um todo e para as redes IP em particular. Este documento
discute os parmetros, os protocolos e os mecanismos envolvidos com a garantia de
qualidade de servio com nfase nas redes de pacotes tipo IP.

2. Cenrio e Novas Aplicaes em Redes IP

As redes TCP/IP [Com95] ou simplesmente, redes IP, tm uma imensa base instalada com
milhes de computadores que continua crescendo em praticamente todo o mundo. O forte
crescimento e a aceitabilidade das redes IP ocorre em funo de dois fatores mais
importantes, a saber:

O crescimento da rede Internet e
A aceitao cada vez maior pelas empresas da base tecnolgica TCP/IP como
plataforma de suporte s suas aplicaes em rede. Isso decorre em parte do
sucesso da capilaridade da Internet e do seu potencial (Comrcio eletrnico, ...).

Em princpio, este cenrio no tende a mudar no prximos anos e, assim sendo, teremos cada
vez mais computadores utilizando o TCP/IP para suas comunicaes na Internet e,
possivelmente, no mbito das empresas.

Neste contexto o IP certamente uma alternativa bastante atrativa como plataforma padro de
suporte para as aplicaes, pois est naturalmente presente em milhes de mquinas. A
questo importante a verificar ento vem a ser se realmente esta a tendncia para as redes
como um todo (Redes privadas, redes metropolitanas, redes de telecomunicaes, redes
industriais, ..) ou se existem outras tendncias a considerar. O fato que o IP no a nica
opo tecnolgica para o suporte de aplicaes em redes.

2.1 "Qualquer Aplicao sobre Rede de Pacote"

Existe um certo consenso de que as tecnologias de comutao (Nveis 2 e 3), algumas vezes
denominadas genericamente de "comutao de pacotes" (Packet Switching), devem
prevalecer como opo tecnolgica para as redes de computadores e como suporte s
aplicaes como um todo. As opes mais comuns de tecnologias de comutao disponveis
para utilizao em redes sem maiores restries de porte, desempenho ou cobertura
geogrfica (LAN - Local Area Networks, MAN - Metropolitan Area Networks ou WAN - Wide
Area Networks) so as seguintes [Tan96]:

ATM - Asynchronous Transfer Mode (Nvel 2)
Frame Relay (Nvel 2)
IP (Nvel 3)

JI
- Termos do Jargo Internacional (norte-americano) utilizados no texto visando uma simplificao 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 aplicaes, a saber:

A aplicao utiliza efetivamente a tecnologia de comutao (ATM, Frame Relay,
...) e, no caso, pode eventualmente prescindir do recursos ou mesmo da utilizao
do IP ou
A comutao no IP efetivamente a plataforma para as aplicaes e, assim
sendo, ele define as vantagens, desvantagens e limitaes da rede.

A primeira situao corresponde utilizao, por exemplo, da tecnologia ATM como um
backbone
JI
de rede. Neste backbone, as aplicaes utilizam as conexes lgicas de alto
desempenho do ATM e, eventualmente, podem prescindir ou depender pouco do IP. Exemplos
especficos neste contexto so as aplicaes de voz sobre ATM (VTOA - Voice Transport over
ATM) [Dan98] e o MPOA (MultiProtocol over ATM) [Dav96]. Este cenrio mais comum em
redes proprietrias de alto desempenho. Uma idia semelhante pode ser citada para o Frame
Relay quando o mesmo utilizado em redes corporativas MAN e WAN.

Na segunda situao, o IP predomina e o maior responsvel pela comunicao fim-a-fim
(usurio-a-usurio). Nada impede entretanto que na implementao da comunicao utilize-se
em trechos da rede o protocolo IP (Nvel 3) sobre algumas das tecnologias de rede de nvel 2
citadas. Segue alguns exemplos de alternativas possveis:

IP over ATM
IP over Frame Relay
IP over Ethernet
IP over Ethernet Switched
Outras

O importante a considerar nesta discusso que estas tecnologias so, neste caso,
meramente mecanismos de transporte de pacotes entre roteadores e, assim sendo, prevalece
na rede as caractersticas do IP. Este um cenrio tpico das redes de grande pblico
(Internet, intranets, ...) e, tambm, das redes de acesso.

Assim sendo, as aplicaes tendem a executar sobre redes de pacotes e, dependendo do tipo
da rede, as opes so de execuo sobre IP (com dependncia do mesmo) ou sobre alguma
tecnologia de nvel 2 de alto desempenho.

2.2 "Qualquer Aplicao sobre Redes IP"

A rede TCP/IP foi desenvolvida tendo como uma de suas premissas bsicas o requisito de
poder ser utilizada com os diversos tipos de meios fsicos e tecnologias existentes na poca
de sua criao ("IP sobre Tudo" - Anos 70) de forma a viabilizar a comunicao entre as
aplicaes fim-a-fim em rede.

Em termos prticos, a rede IP foi desenvolvida de forma a ser capaz de comutar sobre meios
fsicos e tecnologias de nvel 2 confiveis, no-confiveis, de alto desempenho, de baixo
desempenho, etc. Neste contexto histrico, as decises arquiteturais tomadas na concepo
do protocolo IP foram, na sua maioria, no sentido da simplicidade visando atender o cenrio


5

imaginado na poca para sua implantao em termos de rede. Este paradigma de concepo
impe algumas restries tcnicas ao IP e, por conseqncia, restringe as aplicaes
suportadas s aplicaes com poucos requisitos de operao (P. ex.: aplicaes de dados
podem perder pacotes, permitem a existncia de atrasos, ...).

O cenrio atual das redes IP mudou. Hoje, o cenrio de utilizao das redes IP exige que
"qualquer aplicao" possa rodar com qualidade sobre o IP. Ou seja, a situao do IP
atualmente no sentido do "Tudo sobre IP" mantendo a premissa bsica de projeto do "IP
sobre Tudo" dos anos 70.

De certa forma o paradigma mudou e a questo que segue vem a ser a identificao das
eventuais limitaes do IP e procedimentos necessrios para adequa-lo nova realidade das
redes.

Como veremos adiante, a qualidade de servio em redes IP no necessariamente resolvida
com um nico protocolo ou algoritmo. Na maioria dos casos e dependendo da necessidade
da(s) aplicao(es), um conjunto de novos recursos deve ser utilizado.

2.3 Desafios - Redes IP

Os desafios na utilizao do IP como plataforma de suporte para aplicaes em redes so em
resumo os seguintes:

O IP, como protocolo, no tem praticamente nenhuma garantia de qualidade de
servio e
A base instalada do IP muito grande, o que torna a mudana do protocolo uma
idias pouco factvel.

O primeiro desafio de carter tcnico e diz respeito ao paradigma inicialmente previsto para
o protocolo que enfatizava a simplicidade de concepo. Por exemplo, o IP no tem nenhuma
garantia de vazo constante para uma aplicao em particular. Alm disso, uma aplicao no
pode obter do IP nenhuma garantia de entrega da prprios pacotes que eventualmente so
descartados ou perdidos sem que nenhum tipo de correo ou ao seja tomada. No existe
igualmente nenhuma garantia de tempo de entrega para os pacotes.

O segundo desafio uma questo de como se adequar ao novo paradigma sem efetivamente
mudar o protocolo. O IP (Verso 4) dever em breve mudar para o IP (Verso 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 questes de implementao do
protocolo (Endereamento, segurana, ...) e no apresenta nenhuma soluo completa para
os desafios citados.

A forma de abordar as "deficincias" do IP consiste ento em propor novos protocolos,
algoritmos e mecanismos que tratem das deficincias tecnolgicas intrnsecas ao protocolo e
permitam o suporte efetivo de qualquer tipo de aplicao sobre redes IP.

2.4 Novas Aplicaes



6

Como citado anteriormente, o IP tem uma base instalada muito grande e a tendncia que ele
suporte as novas aplicaes em rede, a saber:

Telefonia e Fax sobre IP (VoIP - Voice over IP)
Comrcio Eletrnico (E_commerce)
Vdeo sobre IP
Educao Distncia (EAD) (Distance Learning)
Vdeo-Conferncia
Aplicaes Colaborativas e de Grupo
Aplicaes Multimdia
Aplicaes Tempo Real
Outras

Genericamente, a maioria das aplicaes citadas so aplicaes multimdia na medida em que
envolvem a transferncia de mltiplos tipos de mdia (Dados, voz, vdeo, grficos, ...) com
requisitos de tempo e sincronizao para a sua operao com qualidade.

3. Qualidade de Servio (QoS)

A qualidade de servio (QoS) nas redes IP um aspecto operacional fundamental para o
desempenho fim-a-fim das novas aplicaes (VoIP, multimdia, ...). Assim sendo, importante
o entendimento dos seus princpios, parmetros, mecanismos, algoritmos e protocolos
desenvolvidos e utilizados para a obteno de uma QoS.

A obteno de uma QoS adequada um requisito de operao da rede e suas componentes
para viabilizar a operao com qualidade de uma aplicao.

Em seguida discute-se com mais detalhe o que vem a se termo "Qualidade de Servio".
3.1 Qualidade de Servio (QoS) - Princpios

Numa primeira abordagem o termo "Qualidade de Servio" pode ser entendido da seguinte
forma:
Qualidade de Servio (QoS) um requisito da(s) aplicao(es) para a
qual exige-se que determinados parmetros (atrasos, vazo, perdas, ...)
estejam dentro de limites bem definidos (valor mnimo, valor mximo).

A QoS garantida pela rede, suas componentes e equipamentos utilizados. Do ponto de vista
dos programas de aplicao, a QoS tipicamente expressa e solicitada em termos de uma
"Solicitao de Servio" ou "Contrato de Servio". A solicitao de QoS
JI
da aplicao
denominada tipicamente de SLA (Service Level Agreement) [Job99] [Jam98].

A SLA
JI
deve definir claramente quais requisitos devem ser garantidos para que a(s)
aplicao(es) possam executar com qualidade. Um exemplo tpico de SLA para uma
aplicao de voz sobre IP (VoIP - Voice over IP) com algumas centenas de canais voz
simultneos numa rede IP WAN poderia ser:


7


Vazo 2 Mbps;
Atraso 250 mseg
Disponibilidade 99,5%

Uma vez que a rede garanta esta SLA, tem-se como resultado que a aplicao VoIP em
questo poder executar garantindo a qualidade de voz prevista para os seus usurios se
comunicando simultaneamente atravs da rede IP.

Do ponto de vista dos usurios, tem-se normalmente que a qualidade obtida de uma aplicao
pode ser varivel e, a qualquer momento, pode ser alterada ou ajustada (para melhor
qualidade ou pior qualidade). Por exemplo, pode-se assistir um vdeo com uma qualidade de
32 fps (Frames per Second) ou 4 fps e, fundamentalmente, isto depende da qualidade de
vdeo esperada pelo usurio final. Embora este comportamento possa ser dinmico dos ponto
de vista dos usurios finais (seres humanos), do ponto de vista das redes as SLAs so
estticas e, eventualmente, podem ser alteradas. A alterao numa SLA implica, como
veremos adiante, normalmente numa nova solicitao de qualidade de servio rede em
questo.

3.2 QoS como Mecanismo Gerencial

Do ponto de vista de um gerente ou administrador de redes, a percepo da qualidade de
servio mais orientada no sentido da utilizao de mecanismos, algoritmos e protocolos de
QoS em benefcio de seus clientes e suporte s aplicaes. Ou seja, como efetivamente a
rede e suas componentes podem garantir as inmeras SLAs definidas para diversos usurios
e aplicaes.

Outras aspectos importantes do ponto de vista gerencial so a escalabilidade e flexibilidade da
soluo 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 atravs de mltiplos domnios administrativos IP.

A flexibilidade dos mecanismos de controle de QoS um fator determinante na aceitabilidade
do mesmos pela comunidade.

3.3 QoS -Parmetros

Como definido anteriormente, a QoS necessria s aplicaes definida em termos de uma
SLA. Na especificao das SLAs so definidos os parmetros de qualidade de servio e
alguns dos mais comumente utilizados so:

Vazo (Banda)
Atraso (Latncia)
Jitter
JI

Taxa de Perdas, Taxa de Erros, ...
Disponibilidade


8

Outros

Em seguida, discute-se quais aplicaes realmente necessitam da garantia de QoS e, em
seguida, discute-se os parmetros bsicos de especificao da qualidade de servio indicados
acima.

3.3.1 Quais Aplicaes Necessitam de QoS?

Inicialmente, necessrio considerar que no so todas as aplicaes que realmente
necessitam de garantias fortes e rgidas de qualidade de servio (QoS) para que seu
desempenho seja satisfatrio. Dentre as novas aplicaes identificadas anteriormente, as
aplicaes multimdia so, normalmente, aquelas que tm uma maior exigncia de QoS.

No mnimo, as aplicaes sempre precisam de vazo (banda) e, assim sendo, este o
parmetro mais bsico e certamente mais presente nas especificaes de QoS. Este
parmetro da qualidade de servio normalmente considerado durante a fase de projeto e
implantao da rede e corresponde a um domnio de conhecimento bem discutido e relatado
na literatura tcnica.

As consideraes que seguem tentam identificar as exigncias em termos de QoS das
aplicaes multimdia ilustrando algumas situaes prticas.

Uma aplicao multimdia offline
JI
envolvendo, por exemplo, dados, grficos e arquivos com
animao (vdeo, ...) no necessita de sincronizao e, assim sendo, no necessita de
"cuidados especiais" (QoS) da rede. Observe que tem-se dados correspondentes a uma
animao que, em termos prticos, necessita de uma determinada vazo, eventualmente
carrega a rede, mas no exige atrasos, sincronizao ou tempo de resposta. Este um caso
tpico onde a necessidade de QoS reduz-se a uma necessidade de vazo, normalmente
atendida pelo prprio projeto da rede.

Por outro lado, para uma aplicao multimdia de conferncia de udio, garantir apenas a
vazo no suficiente. Neste caso especfico, os atrasos de comunicao e as perdas de
pacotes influenciam na interatividade dos usurios e na qualidade da aplicao. Considerando
nmeros, se esta aplicao gera uma vazo (fluxo de dados) de 64 Kbps, mesmo a utilizao
de uma LP (Linha Privada) em rede WAN de 256 Kbps pode no ser suficiente. Neste caso, os
atrasos e perdas decorrentes da operao podem prejudicar a qualidade da aplicao. Diz-se
ento que a aplicao exige uma qualidade de servio da rede.

3.3.2 Vazo

A vazo (banda) o parmetro mais bsico de QoS e necessrio para a operao adequada
de qualquer aplicao.

Em termos prticos as aplicaes geram vazes que devem ser atendidas pela rede. A tabela
1 em seguida ilustra a vazo tpica de algumas aplicaes:

Aplicao Vazo (Tpica)


9

Aplicaes Transacionais 1 Kbps a 50 Kbps
Quadro Branco (Whiteboard) 10 Kbps a 100 Kbps
Voz 10 Kbps a 120 Kbps
Aplicaes Web (WWW) 10 Kbps a 500 Kbps
Transferncia de Arquivos (Grandes) 10 Kbps a 1 Mbps
Vdeo (Streaming
JI
) 100 Kbps a 1 Mbps
Aplicao Conferncia 500 Kbps a 1 Mbps
Vdeo MPEG 1 Mbps a 10 Mbps
Aplicao Imagens Mdicas 10 Mbps a 100 Mbps
Aplicao Realidade Virtual 80 Mbps a 150 Mbps
Tabela 1 - Vazo Tpica de Aplicaes em Rede

Como discutido, o atendimento do requisito vazo para a qualidade de servio um dos
aspectos levados em conta no projeto da rede.

3.3.3 Latncia (Atraso)

A latncia e o atraso so parmetros importantes para a qualidade de servio das aplicaes.
Ambos os termos podem ser utilizados na especificao de QoS, embora o termo "latncia"
seja convencionalmente mais utilizado para equipamentos e o termo "atraso" seja mais
utilizado com as transmisses de dados (P. ex.: atrasos de transmisso, atrasos de
propagao, ...).

De maneira geral, a latncia da rede pode ser entendida como o somatrio dos atrasos
impostos pela rede e equipamentos utilizados na comunicao. Do ponto de vista da
aplicao, a latncia (atrasos) resulta em um tempo de resposta (tempo de entrega da
informao - pacotes, ...) para a aplicao.

Os principais fatores que influenciam na latncia de uma rede so os seguintes:

Atraso de propagao (Propagation Delay);
Velocidade de transmisso e
Processamento nos equipamentos.

O atraso de propagao corresponde ao tempo necessrio para a propagao do sinal eltrico
ou propagao do sinal ptico no meio sendo utilizado (fibras pticas, satlite, coaxial, ...) e
um parmetro imutvel onde o gerente de rede no tem nenhuma influncia. A tabela 2 em
seguida ilustra a ttulo de exemplo alguns valores para o atraso de propagao entre cidades
numa rede WAN utilizando fibras pticas como meio fsico de comunicao.


Trecho (Round Trip Delay) Atraso de Propagao
Miami a So Paulo 100 mseg
New York a Los Angeles 50 mseg
Los Angeles a Hong Kong 170 mseg


10

Tabela 2 - Atrasos de Propagao - Fibras pticas - Exemplos

A velocidade de transmisso um parmetro controlado pelo gerente visando normalmente a
adequao da rede qualidade de servio solicitada. Em se tratando de redes locais (LANs)
[Tan96], as velocidades de transmisso so normalmente bastante elevadas, tendendo a ser
tipicamente superior 10 Mbps dedicada por usurio (p. ex.: utilizando LAN Switches [Mat97]).
Alm disso, considere-se tambm que:

Num cenrio de redes locais (LANs - redes proprietrias confinadas) tem-se
apenas custos de investimento e
Nas LANs no tem-se, pelo menos em termos de equipamentos, custos
operacionais mensais.

Em se tratando de redes de longa distncia (Redes corporativas estaduais e nacionais, redes
metropolitanas, intranets metropolitanas, ...) as velocidades de transmisso so dependentes
da escolha de tecnologia de rede WAN (Linhas privadas, frame relay, satlite, ATM ,....).
Embora exista obviamente a possibilidade de escolha da velocidade adequada para garantia
da qualidade de servio, observa-se neste caso restries e/ ou limitaes nas velocidades
utilizadas, tipicamente devido aos custos mensais envolvidos na operao da rede. Alm
desse fator, observa-se tambm algumas restries quanto disponibilidade tanto da
tecnologia quanto da velocidade de transmisso desejada. Em termos prticos, trabalha-se em
WAN tipicamente com vazes da ordem de alguns megabits por segundo (Mbps) para grupos
de usurios.

O resultado das consideraes discutidas que a garantia de QoS certamente mais crtica
em redes MAN e WAN pelo somatrio de dois fatores, ambos negativos:

Trabalha-se com velocidades (Vazo) mais baixas e
A latncia (Atrasos) muito maior quando compara-se com o cenrio das redes
locais.

O terceiro fator que contribui para a latncia da rede a contribuio de atraso referente ao
processamento realizado nos equipamentos. A ttulo de exemplo, numa rede IP os pacotes
so processados ao longo do percurso entre origem e destino por:

Roteadores (comutao de pacotes)
LAN Switches (comutao de quadros)
Servidores de Acesso Remoto (RAS) (comutao de pacotes, ...)
Firewalls
JI
(processamento no nvel de pacotes ou no nvel de aplicao, ...)
Outros

Considerando que a latncia um parmetro fim-a-fim, os equipamentos finais (hosts
JI
)
tambm tm sua parcela de contribuio para o atraso. No caso dos hosts, o atraso depende
de uma srie de fatores, a saber:

Capacidade de processamento do processador;
Disponibilidade de memria;
Mecanismos de cache;


11

Tempo
Pacotes no emissor
Pacotes no receptor
T1
T2
Pacotes fora
de ordem
Processamento nas camadas de nvel superior da rede (Programa de aplicao,
camadas acima da camada IP, ...);
Etc ...

Em resumo, observe-se que os hosts so tambm um fator importante para a qualidade de
servio e, em determinados casos, podem ser um ponto crtico na garantia de QoS. Esta
considerao particularmente vlida para equipamentos servidores (Servers) que tm a
tarefa de atender solicitaes simultneas de clientes em rede.

3.3.4 Jitter

O jitter um outro parmetro importante para a qualidade de servio. No caso, o jitter
importante para as aplicaes executando em rede cuja operao adequada depende de
alguma forma da garantia de que as informaes (pacotes) devem ser processadas em
perodos de tempo bem definidos. Este o caso, por exemplo, de aplicaes de voz e fax
sobre IP (VoIP), aplicaes de tempo real, etc...

Do ponto de vista de uma rede de computador, o jitter pode ser entendido como a variao no
tempo e na seqncia de entrega das informaes (p. ex.: pacotes) (Packet-Delay Variation)
devido variao na latncia (atrasos) da rede.

Conforme discutido no item anterior, a rede e seus equipamentos impem um atraso
informao (p. ex.: pacotes) e este atraso varivel devido a uma srie de fatores, a saber:

Tempos de processamento diferentes nos equipamentos intermedirios
(roteadores, switches, ...);
Tempos de reteno diferentes impostos pelas redes pblicas (Frame relay, ATM,
X.25, IP, ...) e
Outros fatores ligados operao 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 no somente uma entrega com
periodicidade varivel (Packet-Delay Variation) como tambm a entrega de pacotes fora de
ordem.









Figura 3.1 - Efeito do Jitter para as Aplicaes

Em princpio, o problema dos pacotes fora de ordem poderia ser resolvido com o auxlio de um
protocolo de transporte como o TCP (Transmission Control Protocol) [Ste94] que verifica o


12

sequenciamento da mensagens e faz as devidas correes. Entretanto, na prtica tem-se que
a grande maioria das aplicaes multimdia optam por utilizar o UDP (User Datagram Protocol)
[Ste94] ao invs do TCP pela maior simplicidade e menor overhead deste protocolo. Nestes
casos, o problema de sequenciamento deve ser resolvido por protocolos de mais alto nvel
normalmente incorporados aplicao como, por exemplo, o RTP (Real Time Transfer
Protocol) [Mau98].

O jitter introduz distoro no processamento da informao na recepo e deve ter
mecanismos especficos de compensao e controle que dependem da aplicao em questo.
Genericamente, uma das solues mais comuns para o problema consiste na utilizao de
buffers
JI
( Tcnica de "buffering").
3.3.5 Perdas

As perdas de pacotes em redes IP ocorrem principalmente em funo de fatores tais como:

Descarte de pacotes nos roteadores e switch routers
JI
(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 so um problema srio para
determinadas aplicaes como, por exemplo, a voz sobre IP. Neste caso especfico, a perda
de pacotes com trechos de voz digitalizada implica numa perda de qualidade eventualmente
no aceitvel para a aplicao. O que fazer em caso de perdas de pacotes uma questo
especfica de cada aplicao em particular.

Do ponto de vista da qualidade de servio da rede (QoS) a preocupao normalmente no
sentido de especificar e garantir limites razoveis (Taxas de Perdas) que permitam uma
operao adequada da aplicao.

3.3.6 Disponibilidade

A disponibilidade um aspecto da qualidade de servio abordada normalmente na fase de
projeto da rede.

Em termos prticos, a disponibilidade uma medida da garantia de execuo da aplicao ao
longo do tempo e depende de fatores tais como:

Disponibilidade dos equipamentos utilizados na rede proprietria (Rede do cliente)
(LAN, MAN ou WAN) e
Disponibilidade da rede pblica, quando a mesma utilizada (Operadoras de
telecomunicaes, carriers
JI
, ISPs - Internet Service Providers, ...).


As empresas dependem cada vez mais das redes de computadores para a viabilizao de
seus negcios (Comrcio eletrnico, home-banking
JI
, atendimento online
JI
, transaes online,
...) e, neste sentido, a disponibilidade um requisito bastante rgido. A ttulo de exemplo,


13

Protocolos, Algoritmos,
Tcnicas, ...
Rede Pblica:
- ATM, FR, ...
LAN Switch
Roteador
Firewall Hosts
Pacote IP
Mecanismos de QoS
Atuao - Gerente TI
requisitos de disponibilidade acima de 99% do tempo so comuns para a QoS de aplicaes
WEB, aplicaes cliente/ servidor e aplicaes de forte interao com o pblico, dentre outras.

4. QoS - Alternativas Tcnicas

Uma vez identificado os parmetros relacionados com a qualidade de servio das aplicaes,
discute-se os protocolos, mecanismos e algoritmos utilizados na implementao efetiva da
qualidade de servio.

4.1 Cenrio - Implementao da QoS

Numa rede IP a qualidade de servio consiste num mecanismo fim-a-fim (host de origem a
host de destino) de garantia de entrega informaes (Pacotes, ...). Assim sendo, a
implementao da garantia de QoS pela rede implica em atuar nos equipamentos envolvidos
na comunicao fim-a-fim visando o controle dos parmetros de QoS.

Os parmetros (atrasos, jitter, ....) que devem ser controlados visando a obteno da
qualidade de servio no so, infelizmente, localizados num nico equipamento ou
componente da rede. A figura 4.1 em seguida ilustra um exemplo de situao onde na
trajetria fim-a-fim dos pacotes tem-se equipamentos tipo LAN Switch, roteadores, Firewalls,
utiliza-se uma rede pblica de comutao de pacotes e, obviamente, tem-se os prprios hosts
dos usurios finais.

Os mecanismos de QoS devem portanto atuar nestes equipamentos, camadas de protocolo e
entidades de forma cooperada. Uma das atribuies dos gerentes de Tecnologia da
Informao (TI) justamente a escolha e implementao adequada dos mecanismos de QoS
discutidos adiante num cenrio como o da figura 4.1.















Figura 4.1 - Equipamentos e Componentes de Rede Envolvidos na Qualidade de Servio
(QoS)



14

Uma outra questo importante a perceber-se na implementao dos mecanismos de controle
da qualidade de servio a percepo do momento onde estes mecanismos so necessrios.
Efetivamente, a necessidade de garantir a qualidade de servio se coloca mais fortemente
nos perodos de pico de trfego quando a rede enfrenta uma situao de congestionamento ou
de carga muito elevada. Neste tipo de situao os mecanismos de QoS buscam solues para
decises do tipo:

Como alocar os escassos recursos (p. ex.: banda)
Como selecionar o trfego de pacotes
Como priorizar os pacotes
Como descartar pacotes (quais e quando)

4.2 QoS em Redes IP - Alternativas Tcnicas

As alternativas tcnicas bsicas para a qualidade de servio em redes IP so 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
Solues Proprietrias.

Todas as alternativas citadas, excetuando-se as solues proprietrias, so iniciativas do IETF
(Internet Engineering Task Force) [IETF]. O IETF est fortemente empenhado em propor um
conjunto de solues para os mecanismos de controle de QoS que garanta a
interoperabilidade dos mesmos entre diferentes fornecedores. Isto se d em funo da
importncia das redes IP para o suporte de novas aplicaes multimdia, tempo real, etc.

Em seguida, resume-se os princpios, os mecanismos especficos e a estratgia destas
alternativas tcnicas.

4.2.1 Int Serv - Integrated Services Architecture e RSVP - Resource
Reservation Protocol

A alternativa tcnica IntServ [IntServCharter] est atualmente sendo definida pelo IETF e
corresponde a um conjunto de recomendaes (RFCs - Request for Comments) visando a
implantao de uma infra-estrutura robusta para a Internet que possa suportar o transporte de
udio, vdeo e dados em tempo real alm do trfego de dados transportado na infra-estrutura
atual.

O conjunto de recomendaes proposto denominado de "Arquitetura de Servios Integrados"
(Integrated Services Architecture) [Brad94] e visa uma garantia de qualidade de servio (QoS)
para as aplicaes.

A arquitetura IntServ tem um princpio bsico de concepo (Princpio arquitetural):


15

A qualidade de servio (QoS) na arquitetura IntServ garantida atravs de
mecanismos de reserva de recursos na rede.

Na arquitetura IntServ a aplicao reserva os recursos que vai utilizar antes de iniciar o envio
de dados (udio, vdeo, ...) pela rede.

Na definio da arquitetura IntServ dois aspectos operacionais precisam ser definidos:

1. Como as aplicaes 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 servio solicitada (Garantir a reserva).

As aplicaes solicitam suas necessidades de QoS rede atravs do protocolo de sinalizao
RSVP (Resource Reservation Protocol) [Rsvp_2205] onde:

A aplicao cliente identifica sua necessidade de QoS;
A aplicao cliente solicita rede a garantia da qualidade de servio que lhe
conveniente (Reserva) atravs do protocolo RSVP;
A rede (Equipamentos roteadores e switch routers) aceita eventualmente a
solicitao e "tenta garantir" a reserva solicitada e
Uma vez aceita a reserva, os fluxos de dados (streams) correspondentes
aplicao so identificados e roteados segundo a reserva feita para os mesmos.

O RSVP um protocolo de sinalizao que atua sobre o trfego de pacotes (p. ex.: pacotes
IP) numa rede (Internet, redes privadas, ...). O RSVP um protocolo eficiente do ponto de
vista da qualidade de servio (QoS) na medida em que prov granularidade e controle fino das
solicitaes feitas pelas aplicaes. Sua maior desvantagem a complexidade inerente sua
operao nos roteadores que, eventualmente, pode causar dificuldades nos backbones
JI
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
servio solicitada detalhada em vrias recomendaes (RFCs) relacionadas arquitetura
IntServ. Segue comentrios sobre algumas recomendaes mais importantes:

RFC 2211 - Specification of the Controlled-Load Network Element Service: Define
como um elemento de rede (Roteador, ...) garante uma solicitao de reserva para um
servio de "carga controlada" solicitado por uma aplicao.

RFC 2212 - Specification of Guaranteed Quality of Service: Define como um elemento
de rede (Roteador, ...) garante uma solicitao de reserva para um servio tipo
"garantido" solicitado por uma aplicao.

RFC 2215 - General Characterization Parameters for Integrated Services Network
Elements: Define o conjunto de parmetros gerais de caracterizao 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 tcnicos relativos base de dados de gerenciamento dos servios na
arquitetura IntServ.

Para uma relao completa de recomendaes relacionadas com a arquitetura IntServ
consultar [JSMNet] e [IntServ_Charter].

4.2.2 DiffServ - Differentiated Services Framework

A alternativa tcnica DiffServ [DiffServer_Charter] uma outra iniciativa do IETF com o
objetivo de permitir tambm o transporte de udio, vdeo, dados em tempo real e dados
"convencionais" na Internet.

A alternativa DiffServ tem um princpio bsico de concepo (Princpio arquitetural):

A qualidade de servio na soluo DiffServ garantida atravs de
mecanismos de priorizao de pacotes na rede.

A soluo DiffServ no utiliza nenhum tipo de mecanismo de reserva de recursos. Nesta
soluo os pacotes so classificados, marcados e processados segundo o seu rtulo (DSCP -
Differentiated Service Code Point) [Dscp_2474].

A idia bsica da soluo DiffServ reduzir o nvel de processamento necessrio nos
roteadores para fluxos de dados (streams). Isto realizado com a definio de poucas
"Classes de Servio" numa estrutura comum de rede.

Os inmeros fluxos de trfego (Pacotes IP) gerados pelas aplicaes so agregados a poucas
classes de servio em funo da qualidade de servio (QoS) especificada para o fluxo. Esta
tarefa tipicamente realizada nos roteadores de entrada do backbone (Edge routers
JI
) e, desta
forma, o processamento nos roteadores intermedirios (Core
JI
) fica mais simplificado e
independente dos fluxos individuais das aplicaes.

Os roteadores de backbone/ core processam os pacotes (Forwarding) segundo basicamente
as "classes de servio". 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 soluo DiffServ. Todas as funes esto normalmente presentes nos roteadores
de entrada e sada da rede (Edge routers) e, eventualmente, so acionadas nos roteadores
intermedirios (Core routers/ Backbone routers).










17

0 1 2 3 4 ` 5 6 7
NU DSCP
Differentiated Service
Code Point
RFC 2474
NU - No utilizado
0 1 2 3 4 ` 5 6 7
Z Precedence
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 marcao 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 operao de DiffServ como segue:

Cada pacote recebe um processamento baseado na sua marcao (DSCP). O DiffServ define
duas classes de servio que podem tambm ser entendidas como "comportamentos" (PHB -
Per-Hop Behavior), na medida em que definem como os equipamentos (Roteadores, ...) se
comportam com relao aos pacotes (Como os pacotes so processados):

Expedited Forwarding (EF):
Esta classe de servio prov o maior nvel de qualidade de servio. A idia emular
uma linha dedicada convencional minimizando os atrasos, probabilidade de perda e
jitter para os pacotes. EF utiliza mecanismos de traffic shaping
JI
, buferizao
(buffering) e priorizao de filas discutidos adiante.

Assured Forwarding (AF):
Esta classe de servio emula um comportamento semelhante a uma rede com pouca
carga mesmo durante a ocorrncia de congestionamento. A latncia negociada
garantida com um alto grau de probabilidade. O servio AF define 4 nveis de
prioridade de trfego (Ouro, Prata, Bronze e Best Effort
JI
) (Os nveis de prioridade
foram inspirados na premiao dos jogos olmpicos). Para cada nvel de prioridade
so definidos 3 preferncias de descarte de pacotes (semelhante ao Frame Relay).
Este servio usa mecanismos de Traffic Shaping (Token Bucket) e usa o algoritmo
RED (Randon Early Detection), discutido adiante, durante o congestionamento.

Outros servios podero ser definidos no escopo das recomendaes DiffServ.















18

Fig 4.3 - DSCP - Differentiated Service Code Point
As alternativas IntServ e DiffServ no so concorrentes ou mutualmente exclusivas. Na
realidade, estas so solues complementares que podem ser utilizadas conjuntamente. Uma
alternativa de uso conjunto das duas solues seria a utilizao do DiffServ no backbone de
roteadores (core), na medida em que uma soluo 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 aplicaes.

A soluo DiffServ ainda est em fase de desenvolvimento e, no momento, menos presente
que a soluo IntServ/ RSVP nos ambientes operacionais e equipamentos de rede.

Para uma relao completa de recomendaes relacionadas com a arquitetura DiffServ
consultar [JSMNet] e [DiffServ_Charter].


4.2.3 MPLS - MultiProtocol Label Switching

A soluo MPLS [Mpls_Charter] tem uma certa relao com a questo da qualidade de servio
em redes e, neste sentido, importante discutir os seus princpios.

Do ponto de vista tcnico a soluo MPLS tem algumas similaridades com a soluo DiffServ,
a saber:

Os pacotes so marcados com um rtulo (MPLS Label) de 20 bits;
Os pacotes so marcados pelo MPLS na entrada da rede (MPLS edge routers) e
Os rtulos so retirados dos pacotes na sada da rede (MPLS edge routers).

No que toca a operao, o MPLS utiliza os seus rtulos basicamente para indicar o prximo
roteador (Next hop) para onde o pacote deve ser encaminhado (Forwarding). Este aspecto
operacional diferencia-o substancialmente das solues anteriores na medida em que:

O MPLS uma soluo mais orientada para uma engenharia de trfego de
pacotes na rede que para uma garantia efetiva de qualidade de servio (QoS);
Um dos ganhos mais importantes com a utilizao do MPLS a simplificao da
funo de roteamento nos roteadores, reduzindo assim o overhead
JI
nos mesmos
e as suas latncias.

Obviamente, com a reduo da latncia nos roteadores, melhora-se as condies de operao
na rede e isso leva a uma melhor qualidade de servio. Entretanto, o MPLS no prov
controles especficos quanto garantia de QoS na rede.

Outros aspectos que diferenciam o MPLS das solues InteServ e DiffServ so os seguintes:

O MPLS no controlvel pela aplicao. No 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 soluo.


19

LAN
1
2
IP
3
4
Camadas
Superiores
Aplic.
Comunicao 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 operao efetiva do MPLS faz-se necessrio a distribuio dos rtulos (MPLS Labels)
entre os roteadores e a gerncia dos mesmos. O protocolo LDP (Label Distribution Protocol)
[LDP_Spec] um protocolo de sinalizao desenvolvido com esta finalidade.

4.2.4 SBM - Subnet Bandwidth Management

A garantia de qualidade de servio (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 interconexes (Redes locais, LAN Switches, redes pblicas, ...). Desta forma a
garantia de qualidade de servio, como numa corrente, tem como seu ponto mais fraco o elo
mais frgil da cadeia de comunicao fim-a-fim e, neste sentido, todos os elos so
importantes.

As solues discutidas anteriormente abordam a garantia de QoS usando mecanismos de
reserva de recursos e priorizao exclusivamente para o trfego de pacotes no nvel 3 (Nvel
de rede) que, certamente, o elo mais crtico da cadeia.

No que toca a garantia da qualidade de servio nos hosts e interconexes, tem-se dois
aspectos bsicos a considerar conforme ilustrado na figura 4.4:

A comunicao entre a aplicao e as camadas superiores da rede (Nveis 4, 5 ...)
deve ser priorizada para as aplicaes com requisitos de QoS. Normalmente, este
um aspecto local vinculado ao ambiente operacional (Sistema operacional,
cache, ...) e utiliza recursos especficos do ambiente. O ajuste e definio desta
"priorizao" uma tarefa normalmente atribuda ao gerente da rede ou do
sistema em particular.
Um segundo aspecto da qualidade de servio nos hosts (origem e destino) e nas
interconexes dos equipamentos a garantia de QoS nas tecnologias de nvel 2
(Ethernet, FDDI, outras). Segue uma discusso referente a esta questo em
particular.



















20

Figura 4.4 - QoS nos Hosts

A garantia de qualidade de servio com as tecnologias de nvel 2 se coloca nas seguintes
situaes prticas:

Comunicao host - roteador;
Comunicao roteador - host e
Comunicao roteador - roteador em redes locais (LANs).

Neste caso, a questo que deve ser resolvida a seguinte:

Como garantir que quadros (Frames) com pacotes prioritrios (vinculados a um fluxo com
QoS) possam ser priorizados entre si ?

Este problema pode ser abordado em determinados tipos de redes como segue:

Nas implementaes do ethernet usando LAN Switches, os padres IEEE 802.1p
e 802.1Q definem mecanismos de priorizao de quadros;
A tecnologia ATM tem embutida na sua concepo e definio inmeros recursos
para a garantia de qualidade de servio das clulas e, assim sendo, pode
facilmente priorizar clulas com pacotes prioritrios;
Outras tecnologias como o FDDI (Fiber Distributed Data Interface) possuem bits
de prioridade que podem ser utilizados tambm para priorizar quadros com
pacotes vinculados a fluxos com QoS.

A questo mais global que segue como definir e, eventualmente, padronizar o mapeamento
da qualidade de servio das aplicaes com os diferentes mecanismos existentes nas
tecnologias de rede de nvel 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 servios de QoS de nvel
superior (N 3) nos mecanismos dos protocolos de nvel 2 como, por exemplo, o ethernet. Um
dos resultados desta iniciativa o desenvolvimento do SBM (Subnet Bandwidth Management)
[SBM_Draft] para tecnologias de nvel 2 compartilhadas (P. ex.: ethernet em hubs) e
comutadas (P. ex.: ethernet em LAN Switches).

O ISSLL define aspectos como:

Estrutura de operao e comunicao SBM;
Mapeamento da QoS (Nvel superior <--------> Nvel 2) e
Protocolo de sinalizao.

Para uma relao completa de recomendaes relacionadas com a soluo 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 idia bastante simples. No caso, a rede e seus recursos so dimensionados na fase
de projeto de forma a no termos congestionamento. Por exemplo, faz-se um super-
dimensionamento da banda utilizada o que resulta na ausncia de congestionamento ou de
perodos de escassez de recursos durante a operao da rede.

Esta soluo apresenta duas dificuldades principais. A primeira corresponde ao custo
associado na implementao do super-dimensionamento. Em particular para as redes WAN
esta normalmente uma alternativa proibitiva. A segunda dificuldade a identificao dos
pontos de ocorrncia de congestionamento dada a multiplicidade e diversidade de
equipamentos utilizados e a prpria complexidade das redes.

De maneira geral, esta no uma soluo muito prtica e realista embora seja factvel.

5. QoS - Mecanismos

As alternativas tcnicas discutidas so implementadas atravs da utilizao de diversos tipos
de mecanismos, a saber:

Protocolos de sinalizao
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 implementaes dos mesmos que so utilizadas em roteadores, hosts e outros
equipamentos visando a garantia de qualidade de servio.

5.1 Protocolos de Sinalizao

A finalidade de um protocolo de sinalizao (Signalling Protocol) [Wu98] no contexto da
qualidade de servio em redes IP pode ser entendida como segue:

O protocolo de sinalizao utilizado pelas aplicaes (hosts) para informar ou
solicitao rede sua necessidade de qualidade de servio (QoS);
Alm disso, os protocolos de sinalizao permitem tambm que os equipamentos
de rede (Roteadores, ...) possam trocar informaes no sentido de cooperarem
visando a garantia da qualidade de servio aceita pela rede.

Segue exemplos de protocolos de sinalizao no contexto da qualidade de servio:

RSVP - Resource Reservation Protocol: utilizado na iniciativa IntServ do IETF
LDP - Label Distribution Protocol: utilizado na alternativa MPLS para a distribuio
de rtulos entre os equipamentos roteadores.


22


5.2 Prioridades

Os algoritmos de prioridade (Priority Algorithms) so um outro mecanismo utilizado pelos
equipamentos de rede para a garantia da qualidade de servio. Neste contexto, a prioridade
pode ser entendida como um mecanismo que prov diferentes tempos de espera para o
processamento da informao (P. ex.: pacotes e/ ou quadros).

Estes algoritmos so tipicamente implementados em roteadores mas algumas tecnologias de
rede de nvel 2 tambm suportam a utilizao deste mecanismos.

Segue alguns exemplos de algoritmos utilizados:

IP Precedence:
IP Precedence definido na RFC 1122 e uma soluo de priorizao de pacotes
prevista no IPv4 no campo TOS (Type of Service) do cabealho dos pacotes IP.

Priority Queuing:
Algoritmo utilizado por alguns fornecedores utilizado para priorizao de pacotes IP
nas filas de sada de roteadores.

Dentre as tecnologias de rede de nvel 2 mais difundidas que suportam mecanismos de
priorizao eventualmente teis na implantao de garantias de qualidade de servio,
podemos citar:

ATM (Asynchronous Transfer Mode);
Ethernet em LAN Switches (Padres 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 servio discutida, o mecanismo de escalonamento tipicamente
presente em equipamentos roteadores procura garantir que fluxos (streams) diferentes de
pacotes obtm os recursos que lhes foram alocados (banda e processamento). No caso, a
banda e o processamento disponveis so distribudos de forma justa (Fairness) entre os
fluxos ativos existentes no equipamento em questo.

Alguns dos mecanismos de escalonamento utilizados so 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 poltica de descarte de pacotes necessria na ocorrncia de um
congestionamento e visa igualmente a garantia de eqidade (Fairness) quanto distribuio
da banda e do processamento. Estes mecanismos normalmente no fazem nenhuma tentativa
de evitar proativamente a ocorrncia 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 so utilizados tipicamente em equipamentos
roteadores.

5.5 Congestionamento

Os mecanismos de controle de congestionamento so tambm importantes para a
implantao da qualidade de servio numa rede IP. A idia bsica destes mecanismos a
inibio dos fluxos de pacotes durante o perodo 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 tendncia de reduo no nvel 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 MultiServio - Caracterizao das
Aplicaes e Parmetros Bsicos de Operao", 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 Informtica pela Universit Pierre et Marie Curie - Frana, em 1986, desenvolveu trabalhos em
Ps-Doutorado junto ao ICSI da Universidade de Berkeley (USA) em 1995, obteve o Masters Degree em Engenharia Eletrnica
pelo Philips International Institute for Technological Studies (PII), Eindhoven, Holanda, em 1979 e graduou-se em Engenharia
Eletrnica pela UFPb em 1977.

Atualmente, tem atuado como consultor e diretor da ITELCON/ITC em Projetos de Interconexo de Redes, Redes Corporativas,
Redes TCP/IP e Redes de Alta Velocidade. Em termos das atividades de consultoria, a atuao tem sido em projetos de grande
porte para grandes empresas e instituies nacionais como a Petrobras, CPQD, CVRD, FDTE-USP, Albras, Ferbasa,
USIMINAS, CST e o Governo do Estado de So Paulo, dentre outras.

Alm de suas atividades profissionais em consultoria e treinamento profissional especializado atua como Professor Titular do
Departamento de Informtica da UFPB, professor e assessor da Universidade de Salvador (UNIFACS), membro da
Comisso de Especialistas em Informtica e consultor do MEC, atua como pesquisador e professor orientando e lecionando
disciplinas, pesquisador do CNPq e autor de diversos trabalhos em revistas, peridicos e congressos nacionais e
internacionais.

No que toca suas atividades anteriores j atuou como Diretor do ITEEL (Instituto de Tecnologia Eletro-Eletrnica), ministrou
cursos como Professor Visitante no Ps-Graduao da rea de Redes e Comunicao de Dados na Universit Paris VI e no
Institut National des Tlcommunications (INT) na Frana, e em congressos e empresas nacionais, coordenou e desenvolveu
pesquisas atravs do programa de projetos temticos do CNPq (PROTEM), orientou 12 teses de mestrado e dezenas de
trabalhos de ps-garduao.

Informaes detalhadas sobre as atividades acima citadas podem ser encontradas em www.jsmnet.com