ESTUDO DE SOLUÇÕES PARA A GARANTIA DE QoS EM REDES LOCAIS (LAN)

ESTUDO DE SOLUÇÕES PARA A GARANTIA DE QUALIDADE DE
SERVIÇO (QoS) EM REDES LOCAIS (LAN).
Autor: Júlio César Magro magro@cpqd.com.br
Tel.: 0 xx 19 3705 6757
Abstract
The LANs originally had been developed to
allow that desktop PCs (clients) to communicate
and shared features as printer, scanners, hard
drives, applications and, mainly, information.
The LANs had also facilitated to the access the
data base and features you add such as e-mail
and access the Internet. The exponential growth
of the Internet and corporative Intranets /
Extranets produces an additional traffic in LAN.
The optimization is a critical pacing of the
design for optimizations that uses applications
with wide bandwidth and sensible to delay. To
reach its business-oriented objectives, the
organizations wait of its networks the efficient
use of the band, to control delay and jitter, and
support preferential services for essential
applications. Suppliers of network and
organisms of standardization, such as IETF
(Internet Engineering Task Force), offer
innumerable options to reach these expectations.
Beyond the optimization the use of the
bandwidth for the addition features IP multicast
to the network design, it can be determined that
the optimization is also necessary to reach the
requirements of QoS.
Sumário
As LANs foram originalmente desenvolvidas
para permitir que desktop PCs (clientes) se
comunicassem e compartilhassem recursos como
impressoras, scanners, hard drives, aplicações e,
principalmente, informações. As LANs também
facilitaram o acesso a banco de dados e
características adicionais, tais como correio
eletrônico e acesso a Internet.
O crescimento exponencial da Internet e
Intranets / Extranets corporativas produz um
tráfego adicional na LAN.
A otimização é um passo crítico do projeto para
tratar aplicações com banda grande e sensível ao
atraso. Para alcançar seus objetivos de negócios,
as organizações esperam de suas redes o uso
eficiente da banda, para controlar atraso e jitter,
e suportar serviço preferencial para aplicações
essenciais. Fornecedores de rede e organismos
de padronização, tal como IETF (Internet
Engineering Task Force), oferecem inúmeras
opções para atingir essas expectativas.
Além da otimização do uso da banda pela adição
de características do multicast IP ao projeto de
rede, pode-se determinar que a otimização é
também necessária para atingir os requisitos de
QoS.

2
ÍNDICE
ESTUDO DE SOLUÇÕES PARA A
GARANTIA DE QUALIDADE DE SERVIÇO
(QoS) EM REDES LOCAIS (LAN)................. 1
1 INTRODUÇÃO.................................. 2
Objetivo.................................................. 2
Motivação............................................... 2
Organização ........................................... 3
2 VISÃO GERAL.................................. 3
Histórico................................................. 3
Soluções .................................................. 3
3 DESCRIÇÃO DO TRABALHO........ 5
RSVP – Resource Reservation Protocol 6
DiffServ – Priorização............................ 7
MPLS ..................................................... 8
SBM – Subnet Bandwidth Management 9
Arquiteturas de QoS............................ 11
QoS para o Multicast ........................... 12
Endereçamento IP Multicast............ 12
Protocolo de Gerenciamento de
Grupo da Internet............................ 12
1.1.1.1 RSVP para o Multicast....... 13
1.1.1.2 DiffServ para o Multicast ... 13
1.1.1.3 MPLS para o Multicast....... 13
1.1.1.4 SBM para o Multicast......... 14
4 ESTUDO DE CASO......................... 14
Medidas de qualidade de voz.................. 14
1.1.1.5 Mean Opinion Score (MOS)14
1.1.1.6 PSQM/PSQM+ .................. 15
1.1.1.7 PAMS................................ 15
Parâmetros Relevantes ........................... 16
Atraso.................................................... 16
1.1.1.8 Atraso Fixo........................ 16
1.1.1.9 Atraso Variável.................. 17
Variação do atraso (jitter)....................... 17
Perda de pacotes .................................... 18
Codificação de voz................................. 18
Otimização da Rede ............................... 19
Otimização de Algoritmos...................... 19
Voz na LAN .......................................... 19
5 CONCLUSÕES E ESTUDOS
FUTUROS ............................................... 20
6 BIBLIOGRAFIA.............................. 20
7 GLOSSÁRIO ................................... 22
1 INTRODUÇÃO
Objetivo
Muitas empresas investem bastante na
implantação / manutenção de sua rede local.
Muitas vezes a definição das suas reais
necessidades não é bem entendida assim como é
desconhecida a real capacidade de tráfego e
processamento para atender os diversos serviços
que devem ser implantados. Além disso há a
possibilidade de se oferecer serviços em tempo
real, como voz e vídeo, em redes de dados que
originalmente não foram concebidas para esse
fim.
Nesse cenário, a otimização na utilização de
recursos e a garantia da qualidade, passaram a
ter grande importância no planejamento de rede
assim como a gerência dos recursos.
Aumentar a banda é um primeiro passo para
acomodar as aplicações em tempo real, mas isto
ainda não é suficiente para evitar o jitter e o
atraso. Para prover um serviço adequado algum
nível de determinismo, quantitativo ou
qualitativo, nos serviços IP deve ser colocado.
Isso requer a adição de alguma “inteligência” na
rede para distinguir o tráfego com requisitos de
tempo real daquele que pode tolerar atraso, jitter
e perda. É isso que fazem os protocolos de
Qualidade de Serviço (QoS). A QoS não cria
banda, mas gerencia de tal forma que é usada
mais efetivamente para alcançar os requisitos de
faixa larga ou da aplicação. O objetivo da QoS é
prover algum nível de previsibilidade e controle
além do atual serviço IP de melhor esforço.
Este trabalho tem por objetivo mostrar as
diversas soluções para a garantia de qualidade de
serviço em redes locais (LAN), especialmente na
tecnologia Ethernet.
Motivação
Há não muito tempo atrás as Redes Locais eram
assunto para poucos. Hoje é impossível imaginar
qualquer organização sem os recursos que as
redes locais proporcionam, tais como: [IBM 98]
• Correio eletrônico
• Discos em rede
• Impressoras e outros dispositivos
específicos compartilhados
• Acesso a Internet
• Servidores para rodar aplicações
• Software colaborativo (groupware)
• Instalações rápidas de softwares a
partir de um driver de rede

3
• Backups rápidos de dados críticos
em um local central
A medida que as pessoas nas organizações se
sentem mais confortáveis e ajudadas pelas
aplicações da rede, o uso da rede torna-se cada
vez mais freqüente e sofisticado. Como
resultado, o desempenho da rede acaba afetado
pelo aumento do tráfego.
O desempenho atual e futuro da rede pode ser
comprometido devido ao aumento do tráfego na
rede por qualquer dos seguintes motivos:
• Adição de novos usuários
• Introdução de aplicações mais
sofisticadas tais como multimídia, voz e
vídeo
• Uso de aplicações colaborativas
• Uso de aplicações que empregam
muitos gráficos
• Criação de um servidor Web para
Intranet
• Adição de correio eletrônico
• Adição de estações sem discos próprios
(computadores sem disk drive próprio,
que utiliza a rede como disco)
• Uso de aplicações com consumo
intenso de banda, tais como CAD/CAM
ou software de editoração eletrônica
Organização
O trabalho apresenta um breve histórico das
LANs, enfatiza a importância que ganharam com
o advento da Internet/Intranet/Extranet e a
crescente necessidade de mais banda em função
do uso intensivo de aplicativos cada vez mais
sofisticados e a massificação do acesso à
informação o que por si só gera a necessidade de
mais e mais informações num processo
ascendente.
As aplicações de voz são um bom exemplo para
estudo de caso em LANs baseadas em Ethernet
dado que esta tecnologia representa, atualmente,
95% das LANs existentes [Telephony] e tem um
horizonte promissor pela frente (mesmo ao
considerar suas limitações). A recente
padronização do Gigabit Ethernet em pares
metálicos (IEEE 802.3ab/D) [GEth 99] e o
avanço em direção ao 10 Gigabit Ethernet
[DataCom 99, NetWT] sustentam esta visão.
O enfoque do trabalho é o estudo de soluções
para a garantia de qualidade de serviço (QoS)
para as aplicações de voz em LANs baseadas em
Ethernet.
2 VISÃO GERAL
Histórico
As LANs foram originalmente desenvolvidas
para permitir que computadores (PC) se
comunicassem e compartilhassem recursos como
impressoras, scanners, hard drives, aplicações e,
principalmente, informações. As LANs também
facilitaram o acesso a banco de dados e
características adicionais tais como correio
eletrônico e acesso a Internet.
O crescimento exponencial da Internet, Intranet
e Extranet corporativas produz um tráfego
adicional na LAN devido aos seguintes fatores:
• Aumento de usuários da rede
• Uso de interfaces gráficas
• Aumento substancial em número de
transferências de arquivos
• Crescimento das expectativas dos
usuários
A mudança de servidores locais para servidores
baseados em web distribuídos e uma tendência
generalizada em direção consolidação de
servidores altera a antiga regra de rede 80/20.
Segundo a regra 80/20, 80% do tráfego na rede
tipicamente permanece local, enquanto somente
20% sai para a rede backbone em busca de outro
servidor. O retorno aos servidores corporativos
distribuídos para suprir a necessidade de níveis
maiores de controle, suporte e segurança
significa que hoje mais e mais dados deixam o
segmento da rede local (LAN) para alcançar um
servidor distribuído num segmento de LAN
diferente.
As aplicações em servidores continuam a suprir
de forma vital as empresas, tais como fábricas,
distribuidores e bancos. Além disso, os
servidores são freqüentemente requeridos para
suportar aplicações Internet/Intranet/Extranet
que envolvem processamento de transações,
comércio eletrônico, programas gráficos,
software colaborativo (groupware) e voz, por
exemplo. Lembrar ainda que as redes são
requisitadas a disponibilizarem essas aplicações
24 horas por dia, 365 dias por ano.
Soluções
A atual pressão do tráfego pesado na rede
somado ao crescimento antecipado de outras
tecnologias de rede motivam os administradores
de rede a procurarem soluções que possam ser
implementadas eficiente e economicamente e
ainda considerar o crescimento futuro. Os
administradores de rede terão que determinar se
medidas econômicas tal como consolidação de
servidores (ao usar poucos, mas grandes
servidores na rede) e simplificação da estrutura

4
da rede pode ser obtido sem criar gargalos ou
afetar adversamente a eficiência da rede. Tem
também que decidir se suas soluções permitirão,
no futuro, crescimento/evolução para novos
serviços/ aplicações tais como ensino à distância
e vídeo-conferência.
Com essas questões de desempenho de rede em
mente, um administrador de rede deve encontrar
uma solução que realize o seguinte:
• Provisão do mais eficiente ambiente de
rede
• Custos de operação baixos
• Lidar com o crescimento de tráfego que
não pode ser interrompido
(unstoppable)
• Permitir a evolução para tecnologias
como multimídia, ensino a distância e
vídeo-conferência
• Oferecer níveis de Qualidade de
Serviço de acordo com as aplicações.
Certamente esta tarefa não é fácil, mas não é
impossível. Pode-se examinar algumas das
abordagens que uma organização pode
considerar quando estuda estratégias para
melhorar o desempenho e oferecer qualidade na
rede.
Basicamente, existem duas alternativas para
melhorar o desempenho da rede. A primeira
alternativa é aumentar a banda pela introdução
de uma nova tecnologia de LAN (por exemplo,
mudar de Ethernet para Fast Ethernet ou Gigabit
Ethernet).
O segundo método é mudar de um ambiente de
banda compartilhada para tecnologias que
entregam banda dedicada (por exemplo, soluções
que utilizam switches).
Em recente pesquisa realizada pela revista
Network Computer Brasil com 107 leitores foi
perguntado: 1. Por meio de qual equipamento a
sua rede é segmentada atualmente? 39% Switch
nível 2; 29% switch nível 3; 18 % Roteador de
software e 14% Roteador de Hardware (S.O. tipo
Novell); 2. Pretende mudar de tecnologia nos
próximos meses? 56% Não; 33 % Sim e 11%
Não sabe; 3. Caso a resposta anterior tenha sido
positiva, qual tecnologia pretende adotar? 79%
Switch nível 3; 13% Switch nível 2; 5%
Roteador de software e 3% Roteador de
Hardware (S.O. tipo Novell); 4. Qual a razão da
mudança de tecnologia? 44% Facilidade de
gerenciamento; 20% Nenhuma; 18% Melhor
desempenho; 18% Outros [NetwCompBr].
Os switches, sejam eles Ethernet, Token-Ring,
FDDI ou ATM, oferecem muito mais benefícios
às organizações. Esses benefícios incluem o
seguinte:
• Quando comparados aos
roteadores, os switches são rápidos
e baratos
• Requerem pouco overhead de
gerência e produzem baixa latência
• Os switches provêm mais banda
por usuário
• Os switches reduzem
dramaticamente as colisões em
redes Ethernet
• Por prover links de alta velocidade
dedicados, os switches podem
melhorar o throughput do servidor
• Switches full-duplex podem dobrar
a banda
Uma vantagem adicional dos switches é o fato
de que permitem Redes Locais Virtuais
(VLAN). No passado, grupos de interesse
comum dentro da empresa – aqueles geradores
de alto tráfego entre eles – estavam
tradicionalmente colocados juntos num cluster.
Hoje, grupos de interesse comum
constantemente envolvem membros de muitos
lugares diferentes. Para os grupos de usuários de
uma VLAN, baseados em interesses comuns ou
projetos, não importa sua localização física. Os
switches que oferecem suporte a VLAN
reconhecem o tráfego da rede virtual e dá a ele
um tratamento especial ou mais econômico.
Os novos switches incorporam funcionalidades
de roteador que oferecem o melhor de ambos os
dispositivos. Os Switch-Roteadores integrados
permitem que as redes gerenciem o aumento do
tráfego causado pelas novas aplicações Intranet,
consolidação de servidores, multimídia e
tendências emergentes em computação.
Os planejadores de rede atualmente querem a
velocidade e a simplicidade dos switches, e, se
requerido, a capacidade de controle e
gerenciamento dos roteadores.
Os switches-roteadores integrados tem a
vantagem da comutação baseada em hardware
para melhorar o preço/desempenho do
roteamento sem perder o dinamismo, a robustez
e a escalabilidade que tornaram os roteadores
populares. Os produtos integrados permitem que
os usuários que ainda não implantaram ou o
roteamento ou comutação que façam diretamente
a comutação. Se a necessidade aumenta, o
usuário pode adicionar função de roteamento a
configuração existente a um preço muito menor
que era anteriormente possível.
As técnicas de “Rotear uma vez, comutar
muitas” tal como Multiprotocol over ATM
(MPOA) representam outra combinação switch-
roteador que ganha popularidade para requisitos
de backbone. Aqui, a função de roteamento,

5
como usual, determina a rota ótima ao destino.
Entretanto, a informação do roteamento está
armazenada em dispositivos de rede ao longo do
caminho, que elimina a necessidade dos atrasos
dos roteamentos subsequentes. Todos os futuros
pacotes para aquele destino são comutados a
velocidade da camada 2.
Quando se utilizam switches em LANs no
projeto de redes para suportar aplicações
multimídia, é importante lembrar os seguintes
limites de projeto:
• Pacotes multicast são basicamente
equivalentes a pacotes de broadcast;
• Os switches “igualam” (flatten) a rede
e gera pacotes de broadcast (e pacotes
de multicast) a serem distribuídos
(flooded) através da rede;
• LANs Virtuais (VLANs) podem ser
usadas para controlar o tamanho e
escopo do domínio de broadcast e,
portanto, as redes nas quais os pacotes
de multicast são enviados;
• Os roteadores são requeridos para
permitir que VLANs se comuniquem
uma com a outra e controle o
espalhamento dos pacotes multicast;
• VLANs e roteadores são requeridos
para a escalabilidade em redes LAN-
switched;
• Switches que possuem IGMP (Internet
Group Management Protocol) são
adequados para redes que suportam
aplicações multimídia.
3 DESCRIÇÃO DO TRABALHO
Descreve-se a seguir um panorâma dos
protocolos de QoS disponíveis hoje e sob
desenvolvimento para as redes baseadas no
protocolo IP e como cada protocolo opera,
especialmente os de camada 2.
Há mais de uma maneira de caracterizar
Qualidade de Serviço (QoS). Pode-se dizer que a
QoS é a habilidade de um elemento de rede (por
exemplo, uma aplicação, um host ou um
roteador) prover algum nível de garantia para a
entrega consistente de dados na rede.
Os requisitos de qualidade a serem adotados
dependem da aplicação. Aplicações em tempo
real, como voz, têm requisitos mais restritivos.
Por exemplo, os critérios de qualidade de voz
sobre uma rede de dados. Deve-se determinar os
critérios adotados para o (a):
• método de codificação e compressão de
voz,
• atraso e a variação do atraso (jitter) da
rede,
• perda de pacotes,
• disponibilidade do serviço.
Um estudo documentado em [Cov 98] mostra
que os principais fatores que influenciam a
qualidade de voz são: i) a distorção do sinal de
voz provocada pela codificação a baixas taxas e
ii) a perda de pacotes. O atraso prejudica a
dinâmica da conversação.
Outro fator importante é o jitter (variação do
atraso) que provoca descontinuidades na voz.
Os requisitos de disponibilidade dos serviços
dependem da disponibilidade dos equipamentos
de acesso e da redundância da rede e sua
capacidade de re-roteamento no caso de falha de
um roteador. Pode-se exigir também que o
tempo de re-roteamento das chamadas, em curso
no roteador em falha, seja mínimo de modo a ser
quase imperceptível para os usuários
Algumas aplicações são mais exigentes quanto
aos requisitos de QoS que outras, e por essa
razão (entre outras) tem-se dois tipos básicos de
QoS disponíveis:
- Resource Reservation (integrated
services): os recursos da rede são
alocados de acordo com o requisito
de QoS da aplicação e submetido a
política de gerenciamento de
banda.
- Prioritization (differentiated
services): o tráfego da rede é
classificado e recursos da rede
alocados de acordo com os critérios
da política de gerenciamento. Para
habilitar a QoS, os elementos de
rede dão tratamento preferencial
para as classificações identificadas
como as que têm mais requisitos de
demanda.
Esses tipos de QoS podem ser aplicados a
“fluxos” individuais da aplicação ou para fluxos
agregados, daí existirem duas outras formas de
caracterizar os tipos de QoS:
- Por Fluxo: um “fluxo” é definido
como um stream de dado
individual, unidirecional entre duas
aplicações (transmissora e
receptora), unicamente identificado
por um conjunto de 5 parâmetros
(protocolo de transporte, endereço
de origem, número da porta de
origem, endereço de destino, e
número da porta de destino).

6
- Por agregado: um agregado é
simplesmente dois ou mais fluxos.
Tipicamente os fluxos terão algo
em comum (por exemplo, um ou
mais dos 5 parâmetros, um rótulo
ou um número de prioridade, ou
talvez alguma informação de
autenticação).
As aplicações, a topologia da rede e a política
ditam qual tipo de QoS é o mais apropriado para
fluxos individuais ou agregados. Para acomodar
as necessidades para esses diferentes tipos de
QoS, existem diferentes protocolos e algoritmos
de QoS:
- ReSerVation Protocol (RSVP):
provê a sinalização que habilita a
reserva de recursos da rede
(também conhecido como Serviços
Integrados). Embora tipicamente
usado baseado em fluxo, o RSVP é
também usado para reservar
recursos por agregado.
- Differentiated Services (DiffServ):
provê um modo rústico e simples
para categorizar e priorizar o
tráfego agregado da rede (fluxo).
- Multi Protocol Label Switching
(MPLS): provê gerência de banda
para os agregados via controle de
roteamento da rede de acordo com
os rótulos (encapsulados) nos
cabeçalhos dos pacotes.
- Subnet Bandwidth Management
(SBM): habilita a categorização e
priorização na camada 2 (enlace)
em redes compartilhadas e
comutadas IEEE 802.
RSVP – Resource Reservation Protocol
O RSVP é um protocolo de sinalização que
provê mecanismos para reserva e controle para
habilitar os serviços integrados, que pretende
prover algo o mais próximo da emulação de
circuito em redes IP. O RSVP é o mais
complexo de todas as tecnologias de QoS, para
as aplicações (hosts) e para os elementos de rede
(roteadores e swiches). Como conseqüência,
também representa a maior mudança do padrão
de serviço IP “melhor esforço” e provê o nível
mais alto de QoS em termos de garantia de
serviço, granularidade de alocação de recursos e
detalhes de retorno para as aplicações e usuários
de QoS.
A Figura 1 mostra uma visão simplificada de
como o protocolo funciona.
1. A mensagem PATH da origem contém a
especificação de tráfego (TSpec) que perfila o
fluxo de dados a ser enviado;
2. A mensagem PATH segue a rota da dados
“downstream” ao(s) destino(s). Cada roteador
habilitado com RSVP instala o estado PATH e
encaminha a mensagem PATH ao próximo salto
de roteador ao(s) destino(s);
3. O destino não pode fazer a reserva requisitada até
receber a mensagem PATH (para mostrar o
caminho “upstream” ao destino);
4. A mensagem RSVP contém a requisição de
reserva de recursos, que contém a Tspec da
origem, Rspec com o nível de QoS (controlado ou
garantido), e “Filter Spec” (transporte e porta)
para o “Flow-Descriptor”;
5. A mensagem RESV vai no sentido “upstream” ao
seguir a rota de origem provida na mensagem
PATH. Cada roteador habilitado com RSVP faz a
alocação e encaminha a mensagem PATH, ou a
rejeita e retorna um erro de volta ao destino;
6. As mensagens PATH e RESV passam pelos
roteadores não RSVP transparentemente, embora
esses roteadores são os enlaces fracos na cadeia
de reservas de recursos.
Figura 1 - Estabelecimento da reserva de recursos entre
Origem e Destino (fim a fim) [QoSForum]
O RSVP habilita os Serviços Integrados, no qual
existem fundamentalmente dois tipos diferentes:
- Garantido: este surge como o mais
próximo possível para emular um
circuito virtual dedicado. Provê
limites rígidos (matematicamente
prováveis) nos atrasos de fila fim a
fim pela combinação de parâmetros
de vários elementos de rede no
caminho, além de assegurar
disponibilidade de banda de acordo
com os parâmetros de especificação
de tráfego.
- Carga Controlada: isso é
equivalente ao “serviço de melhor
esforço sob condições sem carga”.

7
Daí ser “melhor que o melhor
esforço”, mas não pode prover
serviço com limite estrito que o
serviço garantido proporciona.
Como mencionado anteriormente, o RSVP
simplesmente transporta as requisições de QoS e
provê técnicas para os roteadores manterem as
informações sobre o estado das reservas dos
recursos. Para o RSVP ser efetivo, necessita do
suporte de protocolos adicionais que entendem
os serviços reais e políticas referentes aos
serviços. Um desses protocolos é o Common
Open Police Service (COPS) protocol.
O COPS define um modelo simples cliente /
servidor para suportar controle de política com
protocolos de sinalização QoS tal como o RSVP.
A especificação do COPS descreve um
protocolo básico de interrogação e resposta entre
um servidor de política e seus clientes, que
podem ser roteadores RSVP.
A especificação COPS chama um servidor de
política um ponto de decisão de política, ou
PDP. Chama um cliente Ponto de Reforço de
Política, ou PEP. O protocolo deixa um PEP
enviar requisições, atualizar, e deletar um PDP
remoto, e deixa o PDP retornar decisões ao PEP.
Nesse sentido, os roteadores baseados em RSVP
podem trocar informações com servidores
centralizados que armazenam as políticas de
QoS da rede, e aprendem como manipular
corretamente fluxos para os quais os recursos
foram reservados.
DiffServ – Priorização
Os serviços diferenciados provêm um método
simples e rústico de classificar os serviços de
várias aplicações. Embora outros sejam
possíveis, há atualmente dois padrões por
comportamento (PHB – per hop behaviors)
definidos que efetivamente representam dois
níveis de serviço (classes de tráfego):
- Expedited Forwarding (EF): tem um único
código (codepoint) (valor DiffServ). O EF
minimiza o delay e o jitter e provê o mais alto
nível de qualidade de serviço agregado.
Qualquer tráfego que exceda o perfil de tráfego
(que é definido pela política local) é descartado.
- Assured Forwarding (AF): tem quatro classes
e três precedências para cada classe (portanto, no
total doze códigos (codepoints). O excesso no
tráfego AF não é entregue com alta
probabilidade como no tráfego “dentro do
perfil”, o que significa que pode ser rebaixado
na prioridade, mas não necessariamente
descartado.
A Figura 2 ilustra os principais blocos funcionais
num equipamento, por exemplo, roteador. Os
PHBs são aplicados para condicionar o tráfego
no ponto de entrada da rede de acordo com o
critério da política pré-determinada. O tráfego
pode ser marcado neste ponto, e roteado de
acordo com a marca, e então desmarcado na
saída da rede. Tipicamente os roteadores de
borda – nos pontos de entrada e saída –aplicam
as funções, mas os roteadores intermediários
também podem aplicar.
1. Há dois tipos de classificador: - Agregado de
comportamento (BA): usa somente o valor de
DSCP; - Campo Múltiplo (MF): usa outra
informação do cabeçalho (como endereço de
origem, protocolo, ou número da porta, etc.). Para
BA, o DSCP é essencialmente um índice na
tabela PHB. A política dita como o PHB é
configurado para cada DSCP;
2. Marcas são usadas para: - adicionar DSCP
quando não existe; - adicionar DSCP conforme
mapeado da reserva RSVP; - mudar do mapa do
DSCP para o TOS IP, ou o contrário; - mudar o
DSCP como dita a política local;
3. A medição simplesmente acumula as estatísticas,
mais comum em uma MIB SNMP. Uma MIB
DiffServ não está ainda definida, e há algumas
questões sobre o que a granularidade proverá (isto
é, métricas para todo PHB?);
4. O condicionamento essencialmente envolve a
aplicação do PHB. Os comportamentos podem
incluir marcas ou medidas, mas também seleção e
tratamento de fila, política (modelagem de tráfego
pela adição de atraso ou descarte de pacotes no
sentido de acomodar ao perfil de tráfego descrito
no SLA com o destino ou a origem (depende se é
um ponto de saída ou entrada). Pode também
autenticar o tráfego pelo controle de admissão.
Figura2 – Arquitetura para Serviços Diferenciados
[QoSForum]
O DiffServ assume a existência de um acordo
em nível de serviço (SLA) entre as redes que
compartilham uma borda. O SLA estabelece o
critério da política, e define o perfil de tráfego. É
esperado que o tráfego será policiado e
formatado (de modo a suavizar o tráfego em
rajadas) nos pontos de saída de acordo com o
SLA, e qualquer tráfego “fora do perfil” (isto é,
acima dos limites superiores da banda
estabelecida no SLA) num ponto de entrada não
tem garantia (ou pode incorrer custos extras, de
acordo com o SLA). O critério da política usada
pode incluir o período do dia, endereços de

8
origem e destino, transporte, e/ou números de
porta (isto é, IDs de aplicação). Basicamente,
qualquer contexto ou conteúdo de tráfego (inclui
cabeçalhos e dados) pode ser usado para aplicar
a política.
Fig. 3 – Os Pontos de Código dos Serviços Diferenciados -
Differentiated Services Code Points (DSCP) redefinem o
byte Tipo de Serviço (TOS) do IPv4. Os bits de precedência
IP são preservados nos pontos de código do seletor de classe
& PHBs, mas os valores do TOS não são [QoSForum].
Quando aplicado, o mecanismo de protocolo que
o serviço usa são padrões de bit no “byte DS”,
que para o IPv4 é o octeto do Tipo de Serviço
(TOS) e para o IPv6 é o octeto Classe de
Tráfego. Como ilustrado na Figura 3, embora o
campo DS use o byte TOS, como descrito na
RFC 791, não preserva os valores originais dos
bits do TOS do IPv4 como definido na RFC
1349. Os bits da precedência IP (0-2) são
preservados, entretanto. E embora seja possível
assinalar qualquer PHB aos pontos de código
(codepoints) nessa faixa, os PHBs defaults
(requeridos) são equivalentes as descrições do
serviço Precedência IP, como descito em
detalhes na RFC 1812.
A simplicidade do DiffServ para priorizar o
tráfego mascara sua flexibilidade e
potencialidade. Quando o DiffServ usa os
parâmetros do RSVP ou tipos de aplicação
específica para identificar e classificar o tráfego
de taxa de bit constante (CBR), será possível
estabelecer fluxos agregados bem definidos que
podem ser direcionados para agregados fixos.
Com resultado, pode-se compartilhar os recursos
eficientemente e até prover garantia de serviço.
Descreve-se esse tipo de uso adiante ao se
descrever as possíveis arquiteturas de QoS.
As opções IntServ e DiffServ não são
excludentes ou concorrentes. São soluções
complementares e podem ser usadas em
conjunto. Um exemplo de uso conjunto é a
utilização do DiffServ no backbone de
roteadores (core), pois é uma solução mais leve,
e o IntServ/RSVP nas redes de acesso, uma vez
que provê um bom controle com granularidade
dos requisitos de QoS das aplicações.
MPLS
O Multi-Protocol Label Switching (MPLS) é
similar ao DiffServ em alguns aspectos, a
medida que também marca o tráfego nos limites
de ingresso na rede, e desmarcar nos pontos de
saída. Mas diferentemente do DiffServ, que usa
a marcação para determinar a prioridade dentro
de um roteador, as marcas do MPLS (rótulos de
20 bits) são primariamente projetadospara
determinar o próximo hop do roteador. O MPLS
não é controlado pela aplicação (não existe APIs
MPLS), nem faz isso ter uma componente de
protocolo no host terminal. Diferentemente de
qualquer dos outros protocolos de QoS descritos
neste documento, o MPLS reside somente nos
roteadores. E o MPLS é independente do
protocolo (isto é “multi-protocolo”), tal que pode
ser usado com protocolos de rede outro que o IP
(como o IPX, ATM, PPP ou Frame Relay) ou
bem como, diretamente sobre a camada de
enlace.
O MPLS é mais um protocolo de “engenharia de
tráfego” que um protocolo de QoS, em si. O
roteamento MPLS é usado para estabelecer
“agregados de banda fixa” análogo aos circuitos
virtuais ATM ou Frame Relay. A diferença é
argumentável pois o resultado final é uma
melhoria no serviço e uma diversidade de
serviços aumentada com mais flexibilidade,
baseada em política controle de gerência de rede,
tudo que os outros protocolos de QoS também
provêem.
O MPLS simplifica o processo de roteamento
(ao diminuir o overhead para aumentar o
desempenho) enquanto também aumenta a
flexibilidade com uma camada de
encaminhamento local (sem endereçamento fim
a fim). Aqui está uma seqüência do processo
usado pelos roteadores com MPLS chamados
Roteadores de Comutação de Rótulo (LSR):
- No primeiro salto do roteador na rede MPLS, o
roteador faz uma decisão de encaminhamento
baseada no endereço de destino (ou qualquer
outra informação no cabeçalho, como
determinado pela política local) então determina
a valor do rótulo apropriado – que identifica a
Classe de Equivalência de Encaminhamento
(FEC) – anexa o rótulo ao pacote e o encaminha
para o próximo salto.
- No próximo salto, o roteador usa o valor do
rótulo como um índice na tabela que especifica o

9
próximo salto e um novo rótulo. O LSR anexa o
novo rótulo, e então encaminha o pacote para o
próximo salto.
O roteador tomado por um pacote rotulado
MPLS é chamado de Caminho Comutado do
Rótulo (LSP). A idéia atrás do MPLS é que ao
usar um rótulo para determinar o próximo salto,
os roteadores têm menos trabalho para fazer e
podem agir mais como simples comutadores. O
rótulo representa a rota e ao usar a política para
assinalar o rótulo, os gerentes de rede têm mais
controle para maior precisão na engenharia de
tráfego.
1. 20 bits: valor do rótulo usado pelo LSR para encontrar o
próximo hop, operação de desempenho, ou encapsulamento
na camada de enlace;
2. 3 bits: reservado para uso experimental (classe de serviço);
3. 1 bit: flag de fim da pilha de rótulos;
4. 8 bits: TTL decrementado a cada LSR.
Figura 4 – Pilha de entrada do rótulo MPLS usado para
“encapsular” o cabeçalho IP [QoSForum]
SBM – Subnet Bandwidth
Management
As garantias de QoS são somente tão boas
quanto seu link mais fraco. A “cadeia” de QoS é
fim a fim entre a origem e o destino, o que
significa que todo o roteador ao longo da rota
deve suportar a tecnologia de QoS em uso, como
descrito previamente nos protocolos de QoS. A
“cadeia” de QoS de cima para baixo é também
uma consideração importante, em dois aspectos:
- Os hosts de origem e destino devem habilitar
a QoS de tal forma que as aplicações possam
habilitá-la explicitamente ou o sistema possa
habilitá-la implicitamente no lugar das
aplicações. Cada camada do modelo OSI da
aplicação para baixo deve também suportar a
QoS para garantir que as requisições na origem e
no destino de alta prioridade recebam tratamento
de alta prioridade do sistema da rede do host.
- Local Area Network (LAN) deve habilitar a
QoS tal que os quadros de alta prioridade
recebam tratamento de alta prioridade a medida
que atravessam a rede (por exemplo, host a host,
host a roteador e roteador a roteador). As LANs
são de Camada 2 do modelo OSI, a camada de
enlace, ao passo que as tecnologias de QoS
descritas anteriormente são de Camada 3
(DiffServ) e superiores (RSVP & MPLS). O
MPLS pode ser entendido como de Camada 2 ½.
Algumas tecnologias de camada 2 tem sempre a
QoS habilitada, tal como o Asynchronous
Transfer Mode (ATM). Entretanto, outras
tecnologias mais comuns de LAN tal com o
Ethernet não foram originalmente projetadas
para serem capazes de prover QoS. Tanto como
broadcast compartilhado ou mesmo em sua
forma comutada, o Ethernet provê um serviço
análogo ao padrão do “melhor esforço” do
serviço IP, em que atrasos variáveis podem
afetar aplicações em tempo real. Entretanto o
IEEE tem ajustado o Ethernet e outras
tecnologias de Camada 2 para permitir que a
QoS seja suportada pelo provimento de
mecanismos de protocolo para diferenciação de
tráfego.
Os padrões IEEE 802.1p, 802.1Q e 802.1D
definem como os comutadores Ethernet podem
classificar os quadros no sentido de despachar a
entrega de tráfego crítico quanto ao tempo.
A especificação IEEE 802.1p foca no suporte de
QoS para LANs. O padrão 802.1p é um
suplemento do IEEE 802.1D, “Standard for
Local Area Network MAC (Media Access
Control) Bridges”. Especifica os mecanismos
nas bridges para expedir a entrega de um tráfego
de tempo crítico e para limitar a extensão do
tráfego multicast de banda alta em uma LAN
com bridges. (O termo bridge engloba switches
de camada 2 bem como as tradicionais bridges.)
O padrão IEEE 802.1p adiciona o suporte para
prioridade nas LANs que não suportam métodos
de prioridade MAC. Por exemplo, Ethernet,
diferente do Token Ring e FDDI, não tem
suporte inerente para níveis de prioridade para
quadros.
O IEEE 802.1p provê um método de sinalização
de QoS dentro da banda para classificar o tráfego
baseado na informação do quadro MAC.
Também especifica um mecanismo de protocolo
opcional em bridges para suportar estações
finais ao registrar dinamicamente para quadro de
tempo crítico – ao entregar ou filtrar serviços.
Protocolos opcionais entre bridges para carregar
informações de registro em uma LAN com
bridges são também suportados.
O grupo de trabalho dos Serviços Integrados do
IETF sobre Camadas de Enlace específicas
(ISSLL) definiu um mapeamento entre os
protocolos e serviços de camadas superiores de
QoS com as tecnologias de Camada 2, como o
Ethernet. Dentre outras coisas, isso resultou num
desenvolvimento no “Gerente de banda de sub-
rede” (SBM) para LANs 802 compartilhada ou
comutada tal como o Ethernet (também FDDI,
Token Ring, etc). O SBM é um protocolo de
sinalização que permite a comunicação e

10
coordenação entre os nós da rede e os
comutadores e habilita o mapeamento para os
protocolos de QoS de camadas mais altas.
O requisito fundamental na estrutura do SBM é
que todo o tráfego deve passar através de pelo
menos um switch habilitado em SBM. Como
mostrado na Figura 3, exceto a aplicação
habilitada em QoS e a Camada 2 (por exemplo,
Ethernet), os componentes primários (lógicos)
do sistema SBM são:
- Alocador de Banda (BA): mantém o estado
sobre a alocação dos recursos na sub-rede e
desempenha o controle de admissão de acordo
com os recursos disponíveis e outros critérios da
política definida pelo adminstrador.
- Módulo Requisitor (RM): Reside em toda
estação e não em qualquer comutador. O RM
mapeia entre os níveis de prioridade de Camada
2 e os parâmetros dos protocolos de QoS de
camadas superiores de acordo com a política
definida pelo admistrador. Por exemplo, se
usado com o RSVP poderia mapear baseado no
tipo de QoS (garantido ou carga controlada) ou
valores específicos de Tspec, Rspec ou Filter-
spec.
Como ilustrado na Figura 5, a localização do BA
determina o tipo de arquitetura SBM em uso:
Centralizada ou Distribuída. Se há somente um
ou mais que um BA por segmento de rede,
somente um é “SBM designado” (DSBM) (Note
que pode haver mais que um segmento por sub-
rede). O DSBM pode ser estatisticamente
configurado ou “eleito” dentre os outros BAs.
Figura 5 – Formas da arquitetura SBM: (a) Alocador de
Banda centralizado ou (b) distribuído [QoSForum]
O protocolo SBM provê um mecanismo de
sinalização RM a BA ou BA a BA para iniciar as
reservas, interrogar um BA sobre a
disponibilidade de recursos e mudar ou deletar
as reservas. O protocolo SBM é também usado
entre a aplicação com QoS habilitado (ou seu
agente terceiro) e o RM, mas isso envolve o uso
de uma API ao invés de um protocolo, tal que
isso simplesmente compartilha as primitivas
funcionais. Embora o protocolo SBM seja
projetado para ser independente do protocolo de
QoS, é projetado para trabalhar com outros
protocolos de QoS tal como o ST-II, por
exemplo, as especificações usam o RSVP em
seus exemplos, como se queira. Aqui está um
simples sumário do procedimento de controle de
admissão do protocolo SBM:
0. O DSBM inicia: pega os limites do recurso
(estatisticamente configurado)
1. O Cliente DSBM (qualquer host ou roteador
capacitado em RSVP) procura o DSBM no
segmento anexo a cada interface (feito por
monitoramento do “AllSBMAddress”, o
endereço IP multicast reservado 224.0.0.17)
2. Quando envia uma mensagem PATH, um
cliente DSBM o envia para o
“DSBMLogicalAddress” (endereço IP
multicast reservado, 224.0.0.16) ao invés do
endereço RSVP de destino
3. Ao receber uma mensagem PATH, um
DSBM estabelece o estado PATH no
comutador, armazena os endereços das
camadas 2 e 3 (L2/L3) do qual veio, e o
coloca nos próprios endereços L2/L3 na
mensagem. O DSBM então encaminha a
mensagem PATH ao próximo hop (que
pode ser outro DSBM no próximo segmento
de rede).
4. Quando envia uma mensagem RSVP RESV,
um host o envia para o primeiro hop (como
sempre), que seria o DSBM(s) nesse caso
(tomado da mensagem PATH).
5. O DSBM avalia a requisição e se tem
recursos suficientes disponíveis, encaminha
ao próximo hop (caso contrário retorna um
erro).
Essa seqüência se assemelha muito ao
procedimento RSVP em um roteador, entretanto
foram omitidos alguns detalhes significativos
por questão de simplificação. Não será tratado
em mais detalhes aqui, mas se quer mencionar o
objeto TCLASS o qual ou um transmissor ou
qualquer DSBM pode adicionar a uma
mensagem RSVP PATH ou RESV. Contém uma
configuração de prioridade 802.1p preferida e
permite prevalecer uma configuração default,
embora qualquer DSBM possa mudar o valor
depois de recebê-lo. Os roteadores devem salvar
o TCLASS no estado PATH ou RESV, e
removê-lo da mensagem para evitar encaminhá-
lo nas interfaces de saída, mas então devem
colocar de volta nas mensagens de entrada.

11
O IEEE 802.1p usa um valor e 3 bits (part de um
cabeçalho 802.1Q) no qual pode representar um
valor de prioridade com 8 níveis. São mutáveis e
os limites especificados são somente objetivos,
mas os mapeamentos do serviço ao valor default
definidos no mapeamento SBM são:
0 Prioridade 0: Default, assumido o
serviço de melhor esforço
1 Prioridade 1: Reservado. “menos que” o
serviço de melhor esforço
2 Prioridade 2-3: Reservado
3 Prioridade 4: Sensível ao atraso, sem
limite
4 Prioridade 5: Sensível ao atraso, limite
de 100 ms
5 Prioridade 6: Sensível ao atraso, limite
de 10 ms
6 Prioridade 7: Controle da rede
Da mesma forma que o DiffServ, a simplicidade
dos valores da priorização esconde a
complexidade que é possível. Como descrito a
seguir na seção de arquiteturas de QoS, a
flexibilidade que o mapeamento provê permite
uma grande variedade de possibilidades capaz de
suportar uma grande faixa de garantias de QoS e
granularidade.
Arquiteturas de QoS
Com exceção do mapeamento RSVP ilustra-se o
SBM 802, os exemplos usados nas descrições
dos protocolos de QoS mencionados (RSVP,
DiffServ e MPLS), todos mostrados para cada
protocolo usado independentemente do fim a fim
entre origem e destino. No uso do mundo real,
não é provável que esses protocolos de QoS
serão utilizados independentemente, e de fato
são projetados para uso com outras tecnologias
de QoS para prover QoS de cima para baixo e
fim a fim entre origens e destinos.
Fig. 6 – “Fim a fim” e “de cima para baixo” no mundo real
significa heterogeneidade, e inclui tecnologias de QoS, que
foram feitas para complementar uma a outra, fim a fim
[QoSForum].
A maioria das especificações para “ligar” esses
pedaços de QoS juntos não são padronizados
ainda, mas trabalho está bem encaminhado para
definir as várias arquiteturas que são possíveis –
e necessárias – para prover a QoS fim a fim
global. Nessa sessão descreve-se um número
dessas arquiteturas, mostra as questões e
descreve como endereçá-los. A Figura 6 provê
uma visão geral de como os pedaços se
encaixam, e a Figura 7 provê outra visão mais
detalhada. Referencia-se ambas as ilustrações
como descreve-se como os vários protocolos
trabalham juntos para prover a QoS fim a fim e
de cima para baixo.
1. “O Procurador de Banda” (BB) de cada domínio
interage com outros BBs para comunicar os SLAs
para habilitar a QoS fim a fim;
2. Ponto de saída na borda de rede para enviar pode
mapear a reserva RSVP para o ponto de código
do DiffServ equivalente no byte DS do cabeçalho
IP;
3. Ponto de entrada pode mapear o ponto de código
DiffServ ou RSVP para uma rota específica “que
marca” com o cabeçalho MPLS;
4. O MPLS pode usar o RSVP para prover banda em
seu “túnel”;
5. Ponto de saída remove o prefixo do MPLS;
6. Ponto de entrada na recepção da borda da rede
suporta a reserva original RSVP (o “núcleo” da
rede encaminhou o tráfego RSVP
transparentemente).
Figura 7 – Possíveis utilizações das tecnologias de QoS
[QoSForum]
A Figura 7 mostra uma fotografia completa de
como as tecnologias de QoS podem trabalhar
juntas para prover a QoS fim a fim. Fora o
Procurador de Banda (bandwidth broker, BB) –
que é um novo conceito – isso representa um
modelo sob desenvolvimento dentro da
comunidade do IETF.

12
QoS para o Multicast
O Multicast IP é um requisito, não uma opção,
se a Internet caminha para uma escala ainda
maior. É uma evolução natural que a QoS
suporte “broadcasts” de áudio e vídeo de “um
para muitos” sobre a Internet, tal que o suporte
para o multicast sempre é um requisito no
projeto de protocolos de QoS. Embora
permissões sempre sejam feitas nos projetos
iniciais dos protocolos de QoS, o suporte pleno
de QoS para multicast ainda não está
padronizado ou totalmente compreendido.
Para alcançar seus objetivos de negócios, as
organizações esperam de suas redes o uso
eficiente da banda, para controlar atraso e jitter,
e suportar serviço preferencial para as aplicações
essenciais. Os fornecedores de rede e
organismos de padronização, tal como o IETF,
oferecem inúmeras opções para atingir essas
expectativas.
Uma das principais razões de técnicas de
otimização em redes é o aumento da utilização
de aplicações de usuários múltiplos com banda
larga e multimídia. Tais aplicações como ensino
à distância, vídeo-conferência e computação
colaborativa tem a necessidade de enviar dados
para múltiplos usuários, sem usar quantidades
excessivas de banda ou causar problemas de
desempenho nos demais sistemas.
O IETF tem desenvolvido muitos padrões de
multicast IP que otimiza a transmissão da
multimídia e outros tipos de tráfego na rede. Os
padrões identificam técnicas de endereçamento
multicast que evitam o tráfego extra causado por
muitos unicast ponto-a-ponto ou dados de
tráfego broadcast. Também especificam como
roteadores aprendem quais segmentos de rede
deveriam receber fluxos de dados muticast, e
como os roteadores roteiam o tráfego multicast.
Uma alternativa para múltiplos fluxos de dados
ponto-a-ponto é enviar um único fluxo de dados
e usar um endereço de destino broadcast. A
desvantagem óbvia com essa técnica é que o
fluxo de dados chega a todos os dispositivos,
inclusive os dispositivos para os quais a
aplicação não está instalada para lidar com o
fluxo de dados. Essa abordagem tem um efeito
negativo no desempenho para todo dispositivo
que recebe os dados, que inclui workstations,
bridges, switches e roteadores.
Com as tecnologias de multicast IP, por outro
lado, um único trem de dados é enviado somente
para aquelas estações que requisitaram o trem de
dados, desta forma otimiza o uso da banda e
reduz os problemas de desempenho nas estações
terminais e nos dispositivos de rede.
Empresas de negócios, universidades e outras
organizações usam tecnologias de multicast IP
para muitas aplicações de disseminação de
informações, que inclui aulas de treinamento on-
line, encontros virtuais e newscasts eletrônicos.
Além disso, as tecnologias de multicast IP são
usadas em aplicações de simulação
computacional.
Este tipo de aplicação deve suportar
endereçamento multicast e membro de grupo
multicast dinâmico, os quais são discutidos nas
próximas sessões.
Endereçamento IP Multicast
O multicast IP transmite os dados IP para um
grupo de hosts que são identificados por um
único endereço IP de classe D. Em notação
decimal separada por ponto, a faixa de endereços
de grupo de host vai de 224.0.0.0 a
239.255.255.255. As estações da rede
reconhecem o endereço como um endereço
classe D porque os primeiros 4 bits devem ser
1110 em binário.
Um grupo multicast é também identificado por
um endereço de multicast de camada MAC. Ao
usar um endereço multicast de camada MAC
otimiza o desempenho da rede por permitir aos
cartões de interface de rede (NICs) que não são
parte de um grupo ignorar os dados que não são
pertinentes.
A Internet Assigned Numbers Authority (IANA)
tem um bloco de endereços de camada MAC que
são usados para endereços multicast de grupo. A
faixa de endereços para Ethernet é
01:00:5E:00:00:00 - 01:00:5E:7F:FF:FF.
Quando uma estação envia um quadro a um
grupo IP que é identificado por um endereço
classe D, a estação insere 23 bits de baixa ordem
de um endereço classe D em 23 bits de baixa
ordem de endereço de destino de camada MAC.
Os 9 bits do topo do endereço da classe D não
são usados. Os 25 bits do topo do endereço
MAC são 01:00:5E seguido por um zero, ou em
binário: 00000001 00000000 01011110 0.
Protocolo de Gerenciamento de Grupo da
Internet
Além de definir endereços de grupos, o IETF
também tem o Internet Group Management
Protocol (IGMP), que permite a um host formar
um grupo e informar os roteadores da
necessidade para receber um trem de dados
específico. Os hosts IP usam IGMP para relatar a

13
seus membros do grupo multicast os roteadores
multicast vizinhos diretos.
Quando um usuário (ou um processo) inicia uma
aplicação que requer um host para unir a um
grupo de multicast, o host transmite uma
mensagem “membership report” para informar
aos roteadores do segmento que o tráfego para o
grupo deveria ser multicast ao segmento do host.
Embora seja possível que o roteador já esteja a
enviar dados para o grupo no segmento do host,
a especificação afirma que o host deveria enviar
uma mensagem “membership-report” no caso de
ser o primeiro membro do grupo no segmento da
rede.
Além disso para permitir aos hosts formarem
grupos, o IGMP especifica que o roteador
multicast envie uma interrogação IGMP a todas
as interfaces a intervalos regulares para ver se
algum host pertence ao grupo. Um host responde
ao enviar uma mensagem IGMP membership-
report para cada grupo do qual é ainda um
membro (baseado nas aplicações que rodam no
host).
Para diminuir a utilização de banda os hosts
fixam um temporizador aleatório antes de
responder as interrogações. Se o host vê outro
host responder para um grupo ao qual o host
pertence, então o host cancela sua resposta. O
roteador não necessita conhecer quantos ou quais
hosts específicos no segmento pertencem a um
grupo. Somente necessita reconhecer que um
grupo tem pelo menos um membro no segmento,
tal que envia tráfego para aquele segmento ao
usar os endereços multicast IP e MAC para o
grupo.
A RFC 2236 define uma nova versão de IGMP –
IGMPv2. A principal característica do IGMPv2
é a habilidade para um roteador mais
rapidamente aprender que o último host deixou o
grupo, o que é importante para grupos multicast
de banda larga e subredes com membros do
grupo altamente voláteis. Quando seleciona os
roteadores como parte da fase do projeto físico
de um processo de projeto de rede top-down,
deveria estar certo que roteadores suportam
IGMPv2 (ou suportarão num futuro breve).
Além de adicionar suporte para o IGMPv2, os
fornecedores trabalham em suplementos para o
IGMP para suportar multicasting IP num
ambiente comutado (switched). Por default, um
switch de camada 2 inunda com quadros
multicast todas as portas. Um método para
prevenir a “inundação” de multicasts
desnecessários é permitir ao gerente de rede
configurar filtros. Um método mais sofisticado é
permitir um switch entender IGMP ou uma
variante disso.
Há muitas questões envolvidas com o suporte do
multicast e a seguir descreve-se um sumário do
estado atual do suporte de QoS para o multicast
para cada protocolo de QoS.
1.1.1.1 RSVP para o Multicast
Como mencionado anteriormente, o projeto
inicial para o RSVP e Serviços Integrados levou
em consideração o suporte ao Multicast IP ao
fazer reservas baseadas nos receptores. Um
aspecto do multicast que torna isso um desafio
na implementação é que os receptores que
comportam um grupo multicast podem variar
muito em suas capacidades com relação a banda
de downstream disponível aos mesmos. Essa
heterogeneidade dos receptores provavelmente
tem uma grande variedade de requisitos de
reserva específicos para o caminho que seus
dados seguirão no downstream. Por isso é
essencial que cada receptor tenha permissão para
especificar uma reserva diferente de acordo com
suas necessidades.
Outro aspecto relevante do projeto dos Serviços
Integrados para o multicast em receptores gerais
e heterogêneos especificamente é a habilidade de
colocar especificações de filtro. Por permitir
isso, dados hierárquicos podem ser possíveis.
Fluxos de dados codificados hierarquicamente
são projetados tal que quando menos banda
estiver disponível, os receptores podem ainda
pegar um sinal útil, embora com pouca
fidelidade. As especificações de filtro poderiam
reservar banda para uma parte do fluxo para um
receptor com pouca banda ser capaz de receber.
O grande desafio que o RSVP apresenta e que
ainda não está totalmente entendido lida com
ordenar e fundir reservas. Como ainda não há
padrões publicados, mas há pelo menos uma
referência simulada e um exame de alguns
problemas possíveis com fusões de reservas
multicast.
1.1.1.2 DiffServ para o Multicast
A relativa simplicidade dos Serviços
Diferenciados o torna mais adequado (mais fácil
e mais escalável) para o suporte multicast, mas
há ainda desafios envolvidos. Especificamente,
estimar o tráfego é um desafio devido a natureza
dinâmica dos membros do grupo e ao fato que
embora uma árvore de distribuição multicast
possa ter um único ponto de entrada,
freqüentemente terá múltiplos pontos de saída
(que podem mudar à medida que os membros
mudam). Trabalhos ainda são realizados nesta
área.
1.1.1.3 MPLS para o Multicast
O suporte MPLS para o multicast é um assunto
de intenso esforço de desenvolvimento, mas

14
ainda não surgiram padrões. Há um número
relevante de versões preliminares na área de
suporte ao multicast IP em redes MPLS e
engenharia de tráfego multicast.
1.1.1.4 SBM para o Multicast
O SBM tem um suporte explícito para o
multicast, e como visto anteriormente, o SBM
utiliza o Multicast IP como parte dos protocolos.
Não há questões com o suporte do multicast do
SBM ao assumir o suporte ao IGMP nos
comutadores com SBM, tal que o tráfego
multicast é somente encaminhado aos segmentos
onde os membros do grupo residem.
4 ESTUDO DE CASO
Considere-se uma rede local com tecnologia
Ethernet e TCP/IP. Deseja-se utilizar tal rede
para a aplicação do serviço de voz.
As principais medidas utilizadas para a avaliação
da qualidade de voz são descritas a seguir.
Medidas de qualidade de voz
As medidas mais comuns para se avaliar a
qualidade de voz são:
- MOS (Mean Opinion Score)
- PSQM+ (Perceptual Speech
Quality Measurament Enhanced)
- PAMS (Perceptual Analysis
Measurement System)
1.1.1.5 Mean Opinion Score (MOS)
A qualidade de voz é geralmente caracterizada
por pontuações subjetivas (Mean Opinion Score
- MOS), geradas em testes controlados. Como as
pontuações MOS são subjetivas, os resultados
para um sistema em teste são sempre
comparados com uma referência bem
estabelecida. Muitos fatores contribuem para a
pontuação MOS da qualidade de voz fim-a-fim e
irão requerer otimização individual, a fim de se
obter a melhor pontuação MOS para o sistema
como um todo.
O método recomendado para testes do tipo
“somente ouvir” é o ACR: Absolute Category
Rating. As recomendações P.800 [P800] e P.830
[P830] do ITU-T fornecem os guias para
avaliação dos codecs de voz.
Vários tipos de escalas de 5 pontos são usados
nos testes ACR. A escala mostrada a seguir é
usada freqüentemente para aplicações do ITU-T,
e também recomendada para testes em sistemas.
Pontuação
(MOS)
Qualidade do
Entendimento
da Voz
Nível de
Distorção
5 Excelente Imperceptível
4 Boa Apenas
perceptível, não
perturba
3 Razoável Perceptível,
perturba um
pouco
2 Pobre Perturba, mas
não impeditivo
1 Ruim Perturba muito,
impeditivo
Tabela 1 – Escala da Qualidade do Entendimento
(MOS)
Esforço exigido Nota
Nenhum esforço 5
Necessidade de atenção 4
Esforço moderado 3
Esforço considerável 2
Nenhum entendimento 1
Tabela 2 - Escala de esforço para o entendimento (MOS-LE)
Preferência de Intensidade Sonora Nota
Muito mais alto que o nível ótimo 5
Mais alto que o nível ótimo 4
Nível ótimo 3
Mais baixo que o nível ótimo 2
Muito mais baixo que o nível ótimo 1
Tabela 3 - Escala de Preferência de Intensidade Sonora
(MOS-LP)
O teste de qualidade Mean Opinion Score
(MOS) é utilizado para avaliar a qualidade dos
diferentes codecs. Nesta escala, um índice de 4.0
é considerado de ótima qualidade, igual à
qualidade da voz ouvida em uma linha telefônica
convencional.
Os índices MOS, taxa de bits e atraso para os
codecs VoIP padrão são mostrados na tabela 4.
Codec Taxa de
bits
(Kbps)
MOS Atraso (ms)
G.711 PCM 64,0 4,3 0,125
G.721 ADPCM 32,0 4,2 0,125
G.726 Multi-
rate ADPCM
16-40 2.0 – 4.3 0,125
G.723MP-MLQ
ACELP
5,3; 6,3 3,7; 3,8 70
G.728 LD-
CELP
16,0 4,1 2
G.729 CS-
ACELP
8,0 4,0 20
G.729A CS-
ACELP
8,0 3,4 20
GSM RPE-LPC 13,0 3,9 30
Tabela 4 – valores MOS dos Codecs
De acordo com a tabela, os ganhos de
compressão ou redução da largura de banda
obtida por compressão são tipicamente da ordem
de 8:1 (G.729), exclui o empacotamento dos
cabeçalhos. Redução adicional de 40-60% da

15
largura de banda é obtida por meio da detecção
da atividade de voz (VAD), uma técnica de
omissão de transmissão de pacotes durante os
períodos de silêncio.
A desvantagem do MOS é que é uma medida
subjetiva e demora-se para chegar aos valores
finais, pois depedende de avaliadores que
atribuem valores de 1 (ruim) a 5 (bom) para as
frases que estão em avaliação.
Já o PSQM+ é uma medida objetiva e os
instrumentos em poucos segundos atribuem as
notas de 0 (excelente) a 6,5 (ruim).
O PAMS segue a mesma escala de valores do
MOS.
1.1.1.6 PSQM/PSQM+
O PSQM (Perceptual Speech Quality
Measurement) é para estimar uma MOS que usa
medidas quantitativas (objetivas) (desenvolvida
na Holanda pela KPN Research).
O PSQM é baseado nas recomendações do ITU-
T P.861 (1998), Medida da qualidade objetiva de
codecs de voz na banda de telefonia (300-3400
Hz) e P.50, Vozes Artificiais, que define um
método para estimar a qualidade subjetiva dos
CODECs. A recomendação P.861 define um
método objetivo para estimar a qualidade
subjetiva dos CODECs.
Essencialmente o algoritmo PSQM mede a
distorção de um sinal de voz quando
transmitidos por vários CODECs e meios de
transmissão.
O método é baseado em pesquisas da percepção
psico-acústico do ser humano com o objetivo de
imitar a percepção humana do aparelho
telefônico numa situação de vida real. Assim a
medida de distorção pode ser correlacionada
com a percepção humana.
A recomendação P.50 define um conjunto de
vozes artificiais (femininas e masculinas) para
uso no teste. Possui os fonemas com as
características necessárias tais como: espectro de
longa duração, espectro de curta duração,
distribuição instantânea de amplitude e estrutura
de ondas da voz.
O teste PSQM se correlaciona com o MOS, mas
este último é necessário para servir de parâmetro
porque sob certas condições, os resultados do
PSQM se aproximam do MOS.
Os valores resultantes do PSQM indicam o grau
de degradação da qualidade de voz causada por
todo o sistema de comunicação que está em
teste. Varia de 0 a 6.5, onde 0 (zero) significa
nenhuma degradação, enquanto 6.5 indica alta
degradação. Na avaliação do MOS, os valores
são inversamente proporcionais: 5 significa
excelente qualidade e 1, a pior qualidade.
O teste PSQM é adequado para situações onde a
distorção digital é a causa dominante da
degradação da qualidade da voz. Essas
distorções incluem compressão de voz, ruído de
quantização (quantization (digitisation) noise),
erros de transcodificação de codecs (codec
transcoding errors), perda de pacotes, erros de
bits em rajadas (random or bursty bit errors),
etc.
A medida de qualidade de voz via PSQM+ é o
PSQM aprimorado para considerar os efeitos da
rede, tais como distorções severas e interrupções
no tempo presentes nas redes de pacote.
1.1.1.7 PAMS
Iniciou-se em 1992 na BT um projeto para
prover uma ferramenta de engenharia para
predizer a qualidade de voz em uma conexão
cujo produto era o PAMS (Perceptual Analysis
Measurement System).
O resultado das medidas se refere a opiniões
subjetivas da qualidade percebida por usuários
reais coletadas durante anos, baseadas nas
escalas do ITU (Qualidade do Entendimento e
Esforço para o entendimento).
O trabalho está agora maduro e licenças são
distribuídas desde 1998 para outros fabricantes
de equipamentos de testes e monitoração de rede
[BT].
O PAMS é um algoritmo (software) que avalia a
qualidade da voz que foi transmitida através da
rede telefônica fixa ou móvel. É o resultado de
um programa de pesquisa de oito anos nos
laboratórios da BT em Ipswich – transformado
agora na Psytechnics – o PAMS transformou-se
uma ferramenta essencial e é usada em uma
grande gama de aplicações [PSY].
O PAMS é um modelo objetivo projetado para
predizer os resultados de testes subjetivos.
Trabalha com a comparação de uma gravação
degradada da voz com a voz original que entrou
na rede. Os sinais são alinhados e equalizados, e
então transformados para levar em consideração
as propriedades chaves do sistema da audição
humana, tais como máscara e volume. A
diferença entre os sinais é mostrada na forma de
superfície do erro, uma medida dos erros
audíveis que foram introduzidos. Após aplicar

16
algumas novas técnicas da interpretação, é
traçado em duas escalas de qualidade:
• YLQ - uma predição da qualidade de
entendimento
• YLE - uma predição do esforço de
entendimento
Há diversas diferenças chaves entre PAMS e
modelos objetivos anteriores de avaliação da
qualidade de voz.
Atraso variável: O PAMS foi o primeiro modelo
objetivo a levar em consideração o atraso
variando no tempo que é uma característica da
voz sobre o IP e outras transmissões baseadas
em pacote. A versão 2, incorpora a habilidade de
identificar o tipo mais comum de mudança de
atraso - em períodos silenciosos - está disponível
comercialmente desde dezembro 1998. A versão
3, em dezembro 1999, adicionou a
potencialidade para identificar mudanças do
atraso durante a fala, mesmo que estas sejam
muito menos comuns. Um perfil total do atraso e
dos pontos de mudança do atraso é retornado
pelo PAMS.
Filtro em interfaces analógicas: O PAMS foi
projetado para uso em redes reais. As interfaces
híbridas e outras analógicas introduzem
filtragem que faz com que os modelos objetivos
anteriores como o P.861 forneçam predições não
confiáveis da qualidade. Para lidar com isso, o
PAMS é capaz de identificar automaticamente
uma ampla faixa de tipos de filtro. A função de
transferência do sistema é retornada ao usuário
para o diagnóstico.
Robustez: O método usado para projetar o
PAMS garante que sempre haverá uma relação
de um para um entre a quantidade de distorção e
a escala de qualidade. Outros métodos tais como
a regressão linear ou redes neurais não podem
garantir isto. Foi feito então alguma nova
matemática para usar o conhecimento adquirido
tal que se qualquer coisa piorar, a qualidade deve
cair. Este processo torna o modelo mais exato
em predizer a qualidade para as condições da
rede que não fizeram parte de seus dados de
treinamento, e dá uma confiança maior de que
continuará a desempenhar com confiabilidade
quando usado em campo.
Parâmetros Relevantes
Os parâmetros que mais afetam a qualidade de
voz em uma rede são:
- Atraso;
- Variação do atraso (jitter);
- Perda de pacotes;
- Codificação de voz
A seguir descreve-se brevemente cada um desses
parâmetros.
Atraso
A latência ou 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 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, etc).
De uma forma 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 (atraso) resulta em um tempo de
resposta (tempo de entrega da informação -
pacotes, ...) para a aplicação.
O atraso é o maior desafio da qualidade de
serviço para voz em redes de pacotes e
corresponde ao tempo necessário para transmitir
os pacotes de dados da origem ao destino.
O atraso que ocorre nas redes IP é conseqüência
do compartilhamento da largura de banda e do
processamento nos roteadores e terminais. As
aplicações de dados, para as quais as redes de
pacotes foram desenvolvidas, são mais tolerantes
ao atraso que as redes de voz, onde se considera
que o máximo atraso tolerável, em um sentido de
transmissão, é de 250 ms.
O atraso pode ser classificado como fixo e
variável. O atraso fixo corresponde ao atraso
fim-a-fim para qualquer pacote de voz,
independentemente de pontos de
congestionamento na rede. Atraso variável é
incremental, causado por congestionamentos na
rede ou nos gateways.
1.1.1.8 Atraso Fixo
Pode ocorrer, para as aplicações de VoIP, nas
seguintes áreas:
- compressão (codificação)
- processamento nas pontas
- transmissão de dados internos
- transmissão na rede
- buffer (configurável)
- descompressão (decodificação)
Em aplicações de VoIP, os sinais de voz
analógicos são transmitidos em uma rede de

17
dados, e devem primeiramente serem
digitalizados e, em seguida, comprimidos.
Os atrasos de compressão são estimados na
ordem de 20 a 45 ms, e depende do algoritmo de
compressão utilizado. Ao chegar no destino, a
descompressão é estimada na ordem de 10 ms.
Os atrasos de processamento nos gateways ou
roteadores são de cerca de 10ms em cada ponta
(origem e destino).
Atrasos de transmissão são altamente
dependentes da velocidade do enlace, e quase
desprezíveis (0,25 ms) em cada ponta em enlaces
T1/E1 e da ordem de 7 ms em cada ponta, para
enlaces de 56 kbps.
O atraso na rede é função da capacidade e do
projeto de uma rede em particular. Para uma
rede IP de boa qualidade, o atraso deve ser da
ordem de 50 a 250 ms.
A tabela 5 a seguir mostra o atraso fixo em VoIP
Processamento Típico (ms)
Compressão 20-45
Inter-Proces. (Origem) 10
Transmissão (Origem) 0,25-7
Transm. na rede (um
sentido)
10-200
Transmissão (Destino) 0,25-7
Inter-Proces. (Destino) 10
Controle do Buffer
(Variável)
10-80
Descompressão 20-45
Total dos Atrasos Fixos
(sem Buffer)
91 ~ 403
Tabela 5 – Atraso fixo em VoIP
1.1.1.9 Atraso Variável
O atraso variável muda, em tempo real, em
função do congestionamento do tráfego na rede.
Corresponde essencialmente, à soma dos atrasos
na fila e na transmissão, em cada comutador ou
roteador intermediário na rede. A fila tem um
impacto significativo no atraso se a voz estiver
em competição com outras aplicações,
especialmente em redes IP onde as tecnologias
para priorização e controle de congestionamento
ainda não estão amadurecidas. O controle de
buffer também incrementa o atraso total na rede.
As redes IP podem ser projetadas para minimizar
o atraso ao acrescentar largura de banda e
reduzir as aplicações que competem entre si. O
IP foi originalmente projetado como um
protocolo para rede local com pouca ênfase na
eficiência de banda. Os cabeçalhos dos pacotes
IP são necessários para direcionar a transmissão
da voz sobre a rede IP. Os cabeçalhos têm,
tipicamente, entre 24-28 bytes cada. Devido ao
tamanho dos cabeçalhos dos pacotes IP a
transmissão de voz sobre as redes IP demanda
um nível significativo de largura de banda.
Como resultado, a transmissão de voz na rede IP
é mais susceptível a congestionamento e atraso.
Aumentar a largura de banda da rede depreciará
as vantagens econômicas da telefonia IP.
A especificação de requisitos de
dimensionamento para uma rede VoIP do
European Telecommunication Standardization
Institute (ETSI), TR 101 329 v2.1.1 (1999-06) –
“Telecommunications and Internet Protocol
Harmonization over Networks (TIPHON);
General Aspects of Quality of Service (QoS)”
[EQOS] tem por escopo, o estabelecimento de
requisitos mínimos de QoS para uma rede de
pacotes com serviços em tempo real, como o de
voz.
A tabela 6 a seguir mostra os requisitos de atraso
para um dos cenários considerados (em um
sentido).
Classe de QoS Requisitos de Atraso para Redes
Ótima  150 ms
Alta  250 ms
Média  350 ms
Baixa  450 ms
Tabela 6 – Requisitos de atraso para rede TIPHON (chamada
originada na RTPC, destinada a RTPC, cursada via rede IP)
A relação entre o atraso (em um sentido) e o
MOS é mostrada a seguir [NTRU]:
Atraso (ms) Esforço em VoIP MOS
 50 Ótima qualidade 4,5
150 Boa qualidade 4,0
250 Qualidade quase boa 3,8
500 Qualidade razoável 2,37
2000 Inaceitável  2
Tabela 7 - Relação entre atraso e MOS
Variação do atraso (jitter)
O jitter é um outro parâmetro importante para a
qualidade de serviço. No caso, o jitter é
importante para as aplicações 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...

18
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.
A tabela 6 relaciona os níveis de degradação da
rede baseada no jitter e usa valores do ETSI
TIPHON [NTRU].
Categoria de
Degradação da
Rede
Pico de jitter
(ms) MOS
Perfeita 0 4,5
Boa 75 4,0
Média 125 3,5
Pobre 225 3,0
Tabela 8 – Níveis de degradação da rede baseada no jitter
O método mais comum de remover jitter é a
coleta dos pacotes, e mantê-los até que os
pacotes atrasados cheguem e possam ser
executados na seqüência correta. É conhecido
como buffer de jitter e cria atraso adicional.
Na maioria das transmissões de VoIP, um
carimbo de tempo é incorporado nos pacotes,
que é utilizado no destino, para recompor os
pacotes na seqüência correta.
Duas medidas de controle podem ser usadas para
minimizar o atraso criado pelo buffer de jitter:
• medir a variação do nível dos pacotes
no buffer de jitter durante um período
de tempo e aumentar o tamanho do
buffer incrementalmente para adaptá-lo
ao jitter calculado. Este método
trabalha melhor em redes IP com
desempenho de jitter consistente.
• Contar o número de pacotes que
chegam atrasados e criar uma relação
desses pacotes com o número de
pacotes que são processados com
sucesso. Esta relação é então usada para
ajustar o buffer de jitter e obter uma
relação de pacotes com atraso permitido
dentro de um valor pré-determinado.
Este método trabalha melhor em redes
com intervalos entre chegadas de
pacotes altamente variável (por
exemplo, redes IP).
As duas medidas de controle são baseadas na
possibilidade de testar e medir precisamente o
nível de jitter na rede. O buffer de jitter aumenta
significativamente o atraso em até 100 ms em
algumas redes IP.
Controlar o buffer de jitter tem o objetivo
explícito de minimizar o atraso causado pelo
buffer de jitter e, ao mesmo tempo, minimizar o
impacto do jitter na transmissão.
Perda de pacotes
As perdas de pacotes em redes IP ocorrem
principalmente em função de fatores tais como:
 Descarte de pacotes nos roteadores
e switch routers (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.
As perdas de pacotes são um problema para, por
exemplo, a voz sobre IP. Neste caso específico, a
perda de pacotes com a voz digitalizada implica
numa perda de qualidade eventualmente não
aceitável para a aplicação.
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.
A maioria dos protocolos de aplicação de dados,
tais como o TCP, automaticamente retransmite
os pacotes perdidos. Devido a sua característica
de tempo real, as aplicações de VoIP utilizam os
protocolos UDP e RTP, que não efetuam a
retransmissão dos pacotes perdidos.
A tabela 9 relaciona a perda de pacote e o MOS
e usa valores do ETSI TIPHON [NTRU].
Porcentagem de
Perda
Qualidade de Voz MOS
3% Boa 4,2
15% Média 3,8
25% Pobre 3,0
Tabela 9 – Relação da Perda de pacote e MOS
A tabela 10 relaciona os níveis de degradação da
rede do acordo com o TIPHON do ETSI
[EQOS].
Categoria de
Degradação da Rede
Perda de
Pacote (1)
Pico de
Jitter (2)
Perfeita 0 0 ms
Boa 3% 75 ms
Média 15% 125 ms
Pobre 25% 225 ms
(1): assume-se que a distribuição de perda de pacotes é
gaussiana
(2): assume-se que a distribuição de jitter é gaussiana (com
desvio padrão de metade do pico)
Tabela 10 – Níveis de degradação da rede
Codificação de voz

19
Os codificadores de voz (codecs) têm uma
grande influência na qualidade de voz, pois
quando reduzem a taxa de 64 kbit/s
convencional para outras menores há o ganho na
banda, mas por outro lado degrada a qualidade
de voz.
Geralmente os codecs utilizam 20ms de amostra
de voz para gerar os pacotes.
Após isso ainda se acrescentam os cabeçalhos
para montar o quadro.
O codec é um dispositivo hardware que converte
sinais analógicos de voz em sinal digital (e
geralmente o comprime), e converte depois, de
volta, o sinal em voz. Afeta a inteligibilidade da
voz e diferentes tipos de codificadores fornecem
diferentes QoS para a VoIP. Os mais utilizados
em telefonia IP são:
- ITU G.711: este codec primeiramente
codifica fluxos de voz não comprimida a 64
kbps. A qualidade de voz é equivalente à da
RTPC, que requerer toda a largura de banda
de um canal de voz tradicional da rede de
circuitos.
- ITU G.723.1: é executado a 6,4 ou 5,3 kbps
e é um codificador padrão de áudio que
opera a baixas taxas e mantem alta
qualidade de percepção. Opera
prioritariamente em vídeo-telefonia.
Entretanto, a alta complexidade
computacional da codificação de áudio
limita o desempenho da maioria dos
sistemas de vídeo-telefonia.
- ITU G.729A: este algoritmo é executado a 8
kbps com um atraso total de 35ms. Fornece
desempenho próximo ao da RTPC e é ideal
para aplicações que requerem alta qualidade
de codificação de voz, com atraso mínimo.
- MS-GSM: este codec é da Microsoft e é
executado a 13 kbps, deriva do padrão ITU
GSM.
Otimização da Rede
A otimização da rede pode minimizar os atrasos
de transporte e perdas de pacotes em uma rede
IP.
O atraso ocorre como resultado da propagação
do sinal e do número de roteadores a serem
percorridos. O atraso é acrescido de
aproximadamente 10 ms, toda vez que o pacote
atravessa um roteador.
Órgãos de padronização, como o IETF,
trabalham em tecnologias de entrega em tempo
real na Internet, como Resource Reservation
Protocol (RSVP) e Differenciated Services (Diff-
Serv), que permitem reserva de largura de banda
e atribuição de prioridades a diferentes fluxos de
dados. Mas antes que essas tecnologias possam
ser largamente implementadas, os roteadores
precisam de melhorias e algumas questões
operacionais, como por exemplo a tarifação
baseada em QoS, precisam ser resolvidas.
Otimização de Algoritmos
Novas tecnologias são desenvolvidas para
minimizar os atrasos. Entre as muitas pesquisas
realizadas, destacam-se a procura por melhores
codecs e compressão do cabeçalho RTP.
O algoritmo G.729a é executado a 8 kbps, com
um atraso total de 35 ms. Fornece uma qualidade
boa, é ideal para aplicações que requerem alta
qualidade de codificação de voz com atraso
pequeno.
A recomendação do ITU-T H.323 (Sistemas de
Comunicação Multimídia Baseado em Pacotes) é
um dos padrões para VoIP, inclui o algoritmo de
transmissão e compressão do cabeçalho RTP.
Novos padrões, tais como MGCP (Media
Gateway Control Protocol), SIP (Session
Initiation Protocol), H.248/MEGACO (Gateway
Control Protocol/Media Gateway Control) são
implementados para assegurar melhor
processamento da chamada.
Voz na LAN
Isso não somente implica na transmissão de voz
e dados sobre uma rede de transporte local
comum, mas uma mudança radical no modo
como as organizações implantam, operam e
mantém seus sistemas telefônicos. Enquanto
existem muitas variações de voz sobre LAN,
uma das alternativas mais discutidas é usar a
combinação de telefones Ethernet com
servidores de chamada baseados em LAN, como
uma alternativa ao PBX tradicional. Essas
soluções são tipicamente referenciadas como
PBXs LAN ou PBXs IP.
Os PBXs LAN são somente um subconjunto de
uma visão geral de rede convergente. Nesse
ambiente a funcionalidade do controle da
chamada normalmente provida por um PBX é ao
invés disso provido por um servidor de chamada
na LAN. O servidor de chamada é
freqüentemente um servidor Unix ou Windows
NT/2000 que roda num hardware de servidor
padrão PC. O servidor de chamada pode também
operar com um gateway para chamadas que
trafegam entre o ambiente LAN privado e uma
rede telefônica pública comutada (RTPC). Um
ambiente típico de Voz em LAN é mostrado na
Fig. 8 a seguir.

20
Figura 8 – Modelo de convergência numa empresa
A depender do fornecedor, uma empresa pode
acabar com uma planta de fiação totalmente
separada para sua rede telefônica. A Figura 9
mostra as diversas implementações possíveis.
Figura 9 – Possíveis implementações
a) Telefones Ethernet com duas portas
Usa o telefone com duas portas Ethernet
que age como um hub de duas portas
através do qual o PC acessa a LAN.
Esse método é projetado para usar uma
única porta LAN existente tanto para o
computador quanto para o telefone
baseado em IP.
b) Conectividade da LAN separada para
PCs e Telefones Ethernet
Mantém a infra-estrutura tradicional
separada para a rede telefônica e rede
de dados. Alguns fornecedores realizam
cabeamento independente para PCs e
telefones Ethernet.
c) Telefone ligado a rede via PC
Uma placa de som no computador da
rede equipada com processador de sinal
digital, liga-se a um telefone ou a um
microfone e alto falante.
Alternativamente, um telefone pode
ligar-se a um PC via barramento USB
ou RS232.
d) Hub de voz para dispositivos legados de
POTS
Caminha para um ambiente baseado em
IP não significa jogar fora os
equipamentos legados analógicos ou
POTS (Serviço Telefônico
Convencional) tal como telefones
analógicos para emergência ou em áreas
fora do escritório como depósito.
Outros itens como modems, fax,
dispositivos de anúncios gravados para
call centers, etc podem também
necessitar manter a conectividade. Um
dispositivo como um hub de voz legado
ou analógico é necessário em qualquer
solução de PBX LAN.
5 CONCLUSÕES E ESTUDOS
FUTUROS
O presente trabalho procurou mostrar um
panorâma das soluções para a garantia de
qualidade de serviço em redes locais.
Como nessas redes o mercado é
predominantemente Ethernet, tem-se muita
expectativa de que esta tecnologia que já atingiu
a taxa de 10 Gbit/s possa também oferecer
qualidade de serviço. Muitos esforços são
empenhados para tal e em diversas frentes.
Como estudo futuro pode-se avaliar a influência
dos diversos parâmetros envolvidos no serviço
de voz em uma rede local em um ambiente
controlado de laboratório.
O Laboratório IP (LIP) do CPqD possui
aplicativos como o Cloud que simula condições
de rede, MRTG/STG que mede a banda
consumida, Sniffer Basic que monitora os
pacotes e roteadores/gateways que trabalham
com o protocolo H.323 para unir as redes de
circuito e pacote.
Tal ambiente pode ser utilizado para avaliar as
soluções de camada 2 mostradas ao visar a
qualidade de voz.
6 BIBLIOGRAFIA
1. [IBM 98] The 30-minute Networking
Handbook, Improving your LAN performance,
1998.
2. [Souza 99] J.M. Souza, R. Vilela, M.
Fernandez, Planejamento e Administração de
Redes Locais, Relatório Técnico, Fundação
CPqD, jan 99.

21
3. [Cov 98] P.Coverdale, Voice over IP voice
quality, ITU, SG15, Delayed Contribution
D.041, Feb 98.
4. [Men 98] D.A.Menascé, V.A.F.Almeida,
“Capacity Planning for Web Performance”,
Prentice Hall, 1998.
5. [Cisco] Designing Internetworks for
Multimedia, Cisco, Technical Document.
(www.cisco.com/univercd/cc/td/doc/cisintwk/
idg4/nd2013.htm)
6. [Fluck 95] F.Fluckiger, Understanding
Networked Multimedia, Prentice Hall, 1995.
7. [Geth 99] Gigabit Ethernet Alliance News,
28/jun/1999, (www.gigabit-
ethernet.org/news/releases/062999.html)
8. [Data Com 99] Data Communications,
Networking News, 05/11/1999, IEEE Drafting
10-GbitEthernetStandard
(www.data.com/story/TWB19991105S0008)
9. [NetWT] Network World Today, 09/fev/2000
www2.idg.com.au/nwwdb.nsf/nwtoday/57D27E
712FA828C14A25687F007AF99D?OpenDocu
ment
10. [JSMNet set/99] Qualidade de Serviço (QoS)
em Redes IP – Princípios Básicos, Parâmetros e
Mecanismos, JSMNet Networking Reviews –
vol.1 – no. 1, set/99
(www.jsmnet.com/Downloads/ReviewsJSMNet
1_1.zip).
11. [CiscoPress] Optimizing Your Network
Design
www.cisco.com/cpress/cc/td/cpress/design/topdo
wn/td0512.htm
12. [GigabitEth] Gigabit Ethernet Overview –
May 1999 (www.gigabit-
ethernet.org/technology/whitepapers/gige_0698/
technology.html)
13.[NetwCompBr] Network Computer Brasil –
junho 2000, Switches ou Roteadores? e Switch,
o motor das LANs.
14.[Telephony] Global Telephony – 28/08/2000,
Gig-E breaks free.
(www.internettelephony.com/asp/ItemDisplay.as
p?ItemID=10752&AreaID=1).
15. [QoSForum] QoS protocol & architectures,
white paper, www.qosforum.com
16. [EQOS] ETSI TR 101 329 v2.1.1 (1999-
06): “Telecommunications and Internet Protocol
Harmonization over Networks (TIPHON);
General Aspects of Quality of Service (QoS)”
17. [NTRU] NeTrue Communications (1999):
“IP Telephony QoS Solutions (white paper)”,
http://www.netrue.com/Products-Strategy/QoS-
Description/qos-description.html
18. [BT] Perceptual Analysis Measurement
System, British Telecommunications plc, 2000,
white paper,
www.bt.com/innovation/exhibition/pams/whitep
aper.htm
19. IP Telephony – The Integration of Robust
VoIP Services, Bill Douskalis, Prentice Hall
PTR, 2000.
20. Voice Rules: The Practical Challenges of
Voice on the LAN, White Paper, April 1999,
Mitel,
www.mitel.com/products/ipera_2000/white_pap
ers.cfm?p_id=24
21. [P800] ITU-T Recommendation P.800
(1996): “Methods for subjective determination
of transmission quality”.
22. [P830] ITU-T Recommendation P.830
(1996): “Subjective performance assessment of
telephone-band and wideband digital codecs”.
23. [PSY] PAMS – objective speech quality
assessment, Psytechnics, 2000,
http://www.psytechnics.com/f_intrusive.html

22
7 GLOSSÁRIO
ANSI American National Standards Institute
API Application Programming Interface
ATM Asynchronous Transfer Mode
B-ISDN Broadband-Integrated Services Digital
CBR Constant Bit Rate
CPE Customer Premises Equipment
CO Central Office
EGP External Gateway Protocol
ETSI European Telecommunication Standards
Institute
GII Global Information Infrastructure
HDLC High-level DataLink Control
IEEE Institute of Electrical And Electronics
Engineers
IETF Internet Engineering Task Force
IGP Internal Gateway Protocol
IP Internet Protocol
ISP Internet Service Provider
ITU – T International Telecommunication Union
Telecommunication Stardadization
Sector of ITU
ISDN Integrated Service Digital Network
LAN Local Area Network
MPEG Moving Picture Experts Group;
LCP Link Control Protocol
LDP Label Distribution Protocol
MAC Media Access Control
MPLS Multi Protocol Label Switching
MPEG Multimedia Picture Expert Group
NIC Network Interface Card
OAM Operation, Administration& Maintenance
OSPF Open Shortest Path First
OSI Open Standard Interface
PPP Point-to-Point Protocol
POTS Plain Old Telephone Service
PVC Permanent Virtual Circuit
QoS Quality of Service
RDSI Rede Digital de Serviços Integrados
RIP Routing Information Protocol
RTPC Rede de Telefonia Pública Comutada
SLA Service Level Agreement
SDH Synchronous Digital Hierarchy
SOHO Small Office Home Office;
SONET Synchronous Optical NETwork
SVC Switched Virtual Circuit
TDM Time Division Multiplexing
UNI User Network Interface
VLAN Virtual LAN
VPN Virtual Private Network
LARC USP, 1999 - Monografia de conclusão de curso
de especialização em Redes de Computadores.

ESTUDO DE SOLUÇÕES PARA A GARANTIA DE QoS EM REDES LOCAIS (LAN)

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a ESTUDO DE SOLUÇÕES PARA A GARANTIA DE QoS EM REDES LOCAIS (LAN)

Semelhante a ESTUDO DE SOLUÇÕES PARA A GARANTIA DE QoS EM REDES LOCAIS (LAN) (20)

Mais de Júlio César Magro

Mais de Júlio César Magro (11)

ESTUDO DE SOLUÇÕES PARA A GARANTIA DE QoS EM REDES LOCAIS (LAN)