Qualidade de serviço de voz sobre IP
Índice
Qualidade de serviço de voz sobre IP
Visão Geral de QoS para VoIP
Largura de Banda Suficiente
Classificação de pacote
Visão Geral da Classificação de Pacotes
Classificação e marcação
Classificação de Pontos de Discagem de Voz e Exemplo de Marcação
Classificação da Taxa de Acesso Comprometida e Exemplo de Marcação
Classificação do Roteamento Baseado em Políticas e Exemplo de Marcação
Classificação da Interface de Comando de Linha QoS Modular e Exemplos de Marcação
Mecanismos de Enfileiramento de QoS
Enfileiramento de latência baixa
Exemplo de Configuração LLQ
Outros Mecanismos de Enfileiramento QoS
Fragmentação e Intercalação
Visão Geral de Fragmentação e Intercalação
Exemplo de Fragmentação e Intercalação de Ligação MLP
Exemplo de Fragmentação e Intercalação FRF.12
Modelagem de tráfego
Visão Geral de Modelagem de Tráfego
Exemplo de Modelagem de Tráfego de Frame Relay
Compressão de Cabeçalho RTP IP
Serviços Diferenciados para VoIP
Visão Geral de DS e de DSCP (RFC 2474, RFC 2475)
Implementação DS para VoIP: Encaminhamento Expedido PHB (RFC 2598)
Exemplo de Configuração de Marcação com Base em Classe DSCP
Protocolo de Reserva de Recursos
Visão Geral do RSVP
Visão Geral de RSVP para CAC
Implementando CAC com Base em RSVP
Configurando Recursos de Gateway Local se o CAC Falhar
Utilizando RSVP com LLQ
Implementando Suporte RSVP para LLQ
VoIP QoS sobre Linhas Alugadas (Utilizando PPP)
Cenário VoIP sobre Linha Alugada (Utilizando PPP)
Solução Recomendada para VoIP sobre Linha Alugada (Utilizando PPP)
VoIP QoS sobre Redes de Frame Relay
VoIP QoS sobre Cenário de Frame Relay
VoIP QoS sobre Solução Recomendada de Frame Relay
VoIP QoS sobre ATM
VoIP QoS sobre Cenário ATM
VoIP QoS sobre Soluções ATM Utilizando ATM PVCs Separados para Dados e Voz
VoIP QoS sobre Soluções ATM Utilizando ATM PVCs Compartilhados para Dados e Voz
Documentação Relacionada
Qualidade de serviço de voz sobre IP
Histórico da Versão
Número da Versão
Data
Notas
1
16/04/01
Esse documento foi criado.
2
15/05/01
Comentários editoriais incorporados.
3
30/06/01
Comentários editoriais adicionais incorporados.
Quality of Service para Voice over IP discute os diversos conceitos e recursos de QoS (Quality of Service) aplicáveis à voz e, em
particular, VoIP (Voice over IP). Esse documento também oferece exemplos de alto nível que mostram como implementar esses
recursos em diversos ambientes de rede.
Quality of Service para Voice over IP possui as seguintes seções:
Visão Geral de QoS para VoIP
Largura de Banda Suficiente
Classificação de pacote
Mecanismos de Enfileiramento de QoS
Fragmentação e Intercalação
Modelagem de tráfego
Compressão de Cabeçalho RTP IP
Serviços Diferenciados para VoIP
Protocolo de Reserva de Recursos
VoIP QoS sobre Linhas Alugadas (Utilizando PPP)
VoIP QoS sobre Redes de Frame Relay
VoIP QoS sobre ATM
Documentação Relacionada
Visão Geral de QoS para VoIP
Para que o VoIP seja um substituto realista dos serviços de telefonia PSTN (Public Switched Telephone Network) padrão, os clientes
precisam receber a mesma qualidade de transmissão de voz que recebem com os serviços de telefonia básica, o que significa
transmissões de voz consistente e com alta qualidade. Como em outras aplicações em tempo real, o VoIP é extremamente sensível à
largura de banda e atraso. Para que as transmissões de VoIP sejam inteligíveis ao receptor, os pacotes de voz não devem ser
descartados, excessivamente retardados ou sofrer atraso variante (também conhecido como variação de sinal). Por exemplo, os
seguintes padrões devem ser atendidos:
O padrão codec G.729 requer perda de pacote bem menor que 1 por cento para evitar erros audíveis. Idealmente, não deverá
haver perda de pacote no VoIP.
A especificação ITU G.114 recomenda menos que 150 milissegundos (ms) de atraso ponta a ponta de uma via para o tráfego
em tempo real de alta qualidade, como o tráfego de voz. (Em chamadas internacionais, o atraso de uma via de até 300 ms é
aceitável, especialmente em transmissão de satélite. Esse atraso de uma via considera o atraso de propagação o tempo exigido
para que o sinal percorra a distância.)
Os buffers de variação de sinal (usados para compensar a variação de atraso) acrescentam mais ao atraso de ponta a ponta, e
normalmente só são eficientes em variações de atraso inferiores a 100 ms. O efeito conhecido como variação de sinal,
portanto, deve ser minimizado.
O VoIP pode garantir transmissão de voz de alta qualidade somente se os pacotes de voz, para ambos os canais de sinalização e
áudio, são priorizados em relação ao tráfego de rede. Para o VoIP ser implementado de modo que os usuários recebam um nível
aceitável de qualidade de voz, o tráfego do VoIP deve ter garantidos determinados requisitos de largura de banda compensadora,
latência e variação de sinal. O QoS garante que os pacotes de voz VoIP recebam o tratamento preferencial que requerem. Em geral, o
QoS fornece um serviço de rede melhor (e mais previsível) fornecendo os seguintes recursos:
Suportando largura de banda dedicada
Aprimorando as características de perda
Impedindo e gerenciando o congestionamento de rede
Modelando o tráfego de rede
Definindo prioridades de tráfego na rede
Quality of Service para Voice over IP discute os diversos conceitos e recursos QoS aplicáveis ao VoIP.
Largura de Banda Suficiente
Antes de considerar a aplicação de quaisquer dos recursos de QoS discutidos neste documento, deve-se fornecer largura de banda de
rede suficiente para suportar tráfego de voz em tempo real. Por exemplo, uma chamada VoIP de 80 kbps G.711 (64 kbps de carga
mais 16 kbps de cabeçalho) será deficiente em uma ligação de 64 kbps porque pelo menos 16 kbps dos pacotes (o que representa 20
por cento) serão descartados. Este exemplo também assume que nenhum outro tráfego está fluindo na ligação. Após a provisão de
largura de banda suficiente para tráfego de voz, é possível executar outras etapas para garantir que os pacotes de voz tenham uma
determinada porcentagem da banda total e tenham prioridade.
Classificação de pacote
A base para fornecer qualquer QoS está na capacidade de um dispositivo de rede em identificar e agrupar pacotes
específicos. Este processo de identificação é chamado de classificação de pacotes. Depois que um pacote é classificado, precisa
ser marcado estabelecendo bits designados no cabeçalho IP. As seguintes seções descrevem classificação e marcação:
Visão Geral da Classificação de Pacotes
Classificação de Pontos de Discagem de Voz e Exemplo de Marcação
Classificação da Taxa de Acesso Comprometida e Exemplo de Marcação
Classificação do Roteamento Baseado em Políticas e Exemplo de Marcação
Classificação da Interface de Comando de Linha QoS Modular e Exemplos de Marcação
Visão Geral da Classificação de Pacotes
Para garantir a largura de banda dos pacotes VoIP, um dispositivo de rede deve ser capaz de identificar pacotes VoIP em todo o
tráfego IP fluindo através dela. Os dispositivos de rede utilizam os endereços IP de origem e destino no cabeçalho IP ou os números
de porta do UDP (User Datagram Protocol) de origem e destino no cabeçalho UDP para identificar os pacotes VoIP. Este processo
de identificação e agrupamento é chamado classificação e é a base para fornecer qualquer QoS.
Além dos métodos de classificação estática envolverem correspondência de informações dos cabeçalhos Camada 3 ou Camada 4, é
possível utilizar um mecanismo tal como o RSVP (Resource Reservation Protocol) para classificação dinâmica. RSVP utiliza pacotes
de sinalização H.245 para determinar qual porta UDP a conversação por voz utilizará. Em seguida, ele configura listas de acesso
dinâmico para identificar tráfego de VoIP e coloca o tráfego em uma fila reservada. RSVP será discutido mais adiante neste
documento.
A classificação de pacote pode fazer utilização intensiva do processador, então deve ocorrer o mais longe, na direção da margem da
rede, possível. Como cada salto ainda precisa determinar o tratamento que um pacote deve receber, será necessário usar um método
de classificação mais simples e mais eficiente no centro de rede. A classificação mais simples é atingida por meio de marcação ou de
configuração do byte de ToS (Tipo de serviço) no cabeçalho de IP.
Os três bits mais significativos do byte ToS são chamados de bits Precedência de IP. A maioria dos aplicativos e fornecedores
suporta atualmente a configuração e o reconhecimento desses três bits. O processo de marcação está evoluindo de tal maneira, que os
seis bits mais significativos do byte ToS, denominados DSCP (Differentiated Services Code Point), podem ser utilizados para definir
classes de DS (differentiated services).. DSCP será discutido mais adiante neste documento.
Depois que todo salto na rede for capaz de classificar e identificar os pacotes VoIP (por meio de informação de endereço de porta ou
por meio do byte ToS), esses saltos podem em seguida fornecer a cada pacote VoIP o QoS requerido. Neste momento, é possível
configurar técnicas especiais para fornecer enfileiramento de prioridade para assegurar que pacotes grandes de dados não interfiram
com a transmissão de dados de voz e reduzir requisitos de largura de banda compactando IP de 40 byte, mais UDP, mais cabeçalho
RTP para 2 a 4 bytes.
Classificação e marcação
A classificação é o processo de identificação da classe ou do grupo ao qual o pacote pertence. Os dispositivos de rede utilizam vários
critérios de correspondência para colocar o tráfego em um determinado número de classes. As correspondências são baseadas nos
seguintes critérios:
Comando de configuração global dial-peer voice voip
Lista de acesso (padrão e estendida)
Protocolo (tal como URLs, protocolos stateful ou protocolo Camada 4)
Porta de entrada
Precedência de IP ou DSCP
Ethernet 802.1p CoS (class of service)
Conforme mencionado, há possibilidade de utilização intensiva do processador se os nós precisarem repetir a classificação com base
na correspondência de lista de acesso. Portanto, os nós devem marcar pacotes assim que identificarem e classificarem os pacotes
VoIP. Se um nó puder estabelecer bits de Precedência de IP ou DSCP no byte ToS do cabeçalho de IP assim que identificar o tráfego
como tráfego de VoIP, então todos os outros nós na rede podem ser classificados com base nestes bits.
Marcação é o processo onde o nó define um dos seguintes:
Três bits de Precedência de IP no byte ToS
Seis bits DSCP no byte ToS de IP
Três bits MPLS EXP (Experimental)
Três bits Ethernet 802.1p CoS
Um bit de CLP (cell loss probability) ATM
Na maioria das redes IP, marcar Precedência de IP ou DSCP deve ser suficiente para identificar o tráfego como tráfego de VoIP.
Classificação de Pontos de Discagem de Voz e Exemplo de Marcação
Com os gateways Cisco VoIP, é possível utilizar normalmente pontos de discagem de voz para classificar os pacotes de voz e marcar
os bits de Precedência de IP. O seguinte exemplo de configuração mostra como marcar os bits de Precedência de IP:
Exemplo de Configuração 1: Classificação e Marcação Utilizando Pontos de Discagem
dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.10.10.2
ip precedence 5
Neste exemplo, qualquer chamada VoIP que corresponda ao comando dial-peer voice 100 voip terá todos os seus pacotes de
carga de voz com Precedência de IP 5 significando que os três bits mais significativos do byte ToS de IP estão configurados para
101.
Classificação da Taxa de Acesso Comprometida e Exemplo de Marcação
CAR (committed access rate) é uma técnica mais antiga que envolve limitação de taxa ou vigilância de tráfego que corresponda a
determinados critérios para um limite superior. A CAR suporta a maioria dos mecanismos de correspondência e permite que bits de
Precedência de IP ou DSCP sejam configurados de maneira diferente dependendo de quais pacotes estão de acordo com ou excedem
uma taxa especificada.
Em geral, a CAR é mais útil para pacotes de dados do que para pacotes de voz. Por exemplo, todo o tráfego de dados chegando em
uma interface Ethernet a menos de 1 Mbps pode ser colocado em Precedência de IP Classe 3 e qualquer tráfego que exceda a taxa de
1 Mbps pode ir para a Classe 1 ou ser descartado. Outros nós na rede podem então tratar o tráfego excedente ou marcado com
Precedência de IP mais baixa que não esteja em conformidade de maneira diferente. Todo o tráfego de voz deve estar em
conformidade com a taxa especificada se fornecida corretamente.
O seguinte exemplo de configuração mostra como utilizar CAR para classificar e marcar pacotes VoIP:
Exemplo de Configuração 2: Classificação e Marcação Utilizando CAR
access-list 100 permit udp any any range 16384 32767
access-list 100 permit tcp any any eq 1720
!
interface Ethernet0/0
ip address 10.10.10.1 255.255.255.0
rate-limit input
access-group 100 1000000 8000 8000 conform-action
set-prec-continue 5 exceed-action set-prec-continue 5
Neste exemplo, qualquer tráfego que corresponda à lista de acesso 100 será configurado com Precedência de IP 5 significando
que os três bits mais significativos do byte ToS de IP estão definidos em 101. A lista de acesso 100 aqui corresponde às portas
UDP comuns usadas pelo VoIP e pelo H.323 sinalizando o tráfego para a porta TCP 1720.
Classificação do Roteamento Baseado em Políticas e Exemplo de Marcação
PBR (policy-based routing) é outro recurso antigo que permite que o tráfego seja roteado com base em porta de origem ou lista de
acesso. Ele também pode ser utilizado para classificar e marcar pacotes. Um exemplo simples de configuração a seguir:
Exemplo de Configuração 3: Classificação e Marcação Utilizando PBR
access-list 100 permit udp any any range 16384 32767
access-list 100 permit tcp any any eq 1720
!
route-map classify_mark
match ip address 100
set ip precedence 5
!
interface Ethernet0/0
ip address 10.10.10.1 255.255.255.0
ip policy route-map classify_mark
Neste exemplo, qualquer tráfego que corresponda à lista de acesso 100 será configurado com Precedência de IP 5 significando
que os três bits mais significativos do byte ToS de IP estão definidos em 101. A lista de acesso 100 aqui corresponde às portas
UDP comuns usadas pelo VoIP e pelo H.323 sinalizando o tráfego para a porta TCP 1720.
Classificação da Interface de Comando de Linha QoS Modular e Exemplos de Marcação
O método de classificação e marcação recomendado é o recurso Modular QoS Command-Line Interface (Mod QoS CLI ou MQC),
um método de configuração com base em molde que separa a classificação da política, permitindo que múltiplos recursos QoS sejam
configurados em conjunto para diversas classes. É possível utilizar um mapa de classes para classificar o tráfego com base em vários
critérios de correspondência e um mapa de política para determinar o que deve acontecer com cada classe. Em seguida, aplica-se a
política ao tráfego de entrada ou saída em uma interface utilizando o comando de configuração de interface service-policy. O
seguinte exemplo de configuração mostra como utilizar o Modular QoS para classificar e marcar pacotes:
Exemplo de Configuração 4: Classificação e Marcação Utilizando MQC
access-list 100 permit udp any any range 16384 32767
access-list 100 permit tcp any any eq 1720
!
class-map voip
match access-group 100
!
policy-map mqc
class voip
set ip precedence 5
<<#various other QoS commands>>
class class-default
set ip precedence 0
<<#various other QoS commands>>
!
interface Ethernet0/0
service-policy input mqc
Neste exemplo, qualquer tráfego que corresponda à lista de acesso 100 será classificado como class voip e definido com
Precedência de IP 5 significando que os três bits mais significativos do byte ToS de IP estão definidos em 101. A lista de acesso
100 aqui corresponde às portas UDP comuns usadas pelo VoIP e pelo H.323 sinalizando o tráfego para a porta TCP 1720. Todos
os outros tráfegos serão definidos com Precedência de IP 0. A política é chamada de mqc e é aplicada em tráfego de entrada na
interface Ethernet 0/0.
Mecanismos de Enfileiramento de QoS
Depois que todo o tráfego for colocado em classes QoS com base em seus requisitos de QoS, é preciso fornecer garantias de largura
de banda e serviço de prioridade por meio de um mecanismo de enfileiramento de saída inteligente. Esta seção descreve os
mecanismos de enfileiramento e inclui as seguintes subseções:
Enfileiramento de latência baixa
Exemplo de Configuração LLQ
Outros Mecanismos de Enfileiramento QoS
Enfileiramento de latência baixa
Uma fila de prioridade é necessária para VoIP. É possível utilizar qualquer mecanismo de enfileiramento que efetivamente dê alta
prioridade ao VoIP, mas o LLQ (low latency queueing) é recomendado porque é flexível e fácil de configurar.
O método de enfileiramento mais flexível que atende aos requisitos de VoIP é o LLQ. O LLQ utiliza o método de configuração
MQC para fornecer prioridade a determinadas classes e para fornecer banda mínima garantida para outras classes. Durante períodos
de congestionamento, a fila de prioridade é monitorada na taxa configurada para que o tráfego de prioridade não monopolize toda a
largura de banda disponível. (Se o tráfego de prioridade monopolizar a banda, ele evita que garantias de banda para outras classes
sejam atendidas.) Se LLQ for fornecido corretamente, o tráfego indo para a fila de prioridade não deve nunca exceder a taxa
configurada.
O LLQ ainda permite que profundidades de filas sejam especificadas para determinar quando o router deve descartar pacotes se
muitos pacotes estiverem esperando em qualquer fila de classes em particular. Há também um class default que é utilizado para
determinar o tratamento de todo o tráfego não classificado por uma classe configurada. O padrão de classe pode ser configurado com
o comando de configuração de interface fair-queue, que significa que a cada fluxo não classificado será dada uma porção
aproximadamente igual da largura de banda restante. A Figura 1 mostra como um LLQ funciona.
Figura 1: Operação do LLQ
Na Figura 1, todo tráfego saindo de uma interface ou subinterface (para Frame Relay e ATM) é primeiramente classificado
utilizando MQC. Há quatro classes: uma de alta prioridade, duas de largura de banda garantida e uma padrão. O tráfego de classe de
prioridade é colocado em uma fila de prioridade e aquela do tráfego de classe de largura de banda garantida é colocado em filas
reservadas. Ao tráfego de classe padrão pode ser dada uma fila reservada ou ele pode ser colocado em uma fila não reservada onde
cada fluxo terá uma porção aproximadamente igual de largura de banda não reservada e disponível. O programador atende as filas de
maneira que o tráfego de fila de prioridade saia primeiro, a menos que exceda uma largura de banda de prioridade configurada e esta
largura de banda seja necessária para uma fila reservada (isto é, há congestionamento). As filas reservadas são atendidas de acordo
com sua largura de banda reservada, que o programador utiliza para calcular um peso. O peso é utilizado para determinar com que
freqüência uma fila reservada é atendida e quantos bytes são atendidos por vez. Os atendimentos do programador são baseados no
algoritmo WFQ (weighted fair queueing), uma discussão que está além do escopo deste documento.
Se a fila de prioridade encher devido à taxa de transmissão do tráfego de prioridade ser superior à largura de banda de prioridade
configurada, os pacotes no final da fila de prioridade serão descartados se nenhuma outra largura de banda não reservada estiver
disponível. Nenhuma das filas reservadas ficará restrita à largura de banda configurada se a largura de banda estiver disponível. Os
pacotes que violam a largura de banda garantida e a prioridade são descartados apenas durante os períodos de congestionamento.
Você deve então fornecer à fila de prioridade largura de banda suficiente para processar o tráfego de VoIP que exige o serviço de
prioridade.
Exemplo de Configuração LLQ
O seguinte exemplo de configuração mostra como configurar um LLQ:
Exemplo de Configuração 5: LLQ
access-list 100 permit udp any any range 16384 32000
access-list 100 permit tcp any any eq 1720
access-list 101 permit tcp any any eq 80
access-list 102 permit tcp any any eq 23
!
class-map voip
match access-group 100
class-map data1
match protocol
class-map data2
match access-group 102
!
policy-map llq
class voip
priority 32
class data1
bandwidth 64
class data2
bandwidth 32
class class-default
fair-queue
!
interface Serial1/0
bandwidth 256
service-policy output llq
Neste exemplo, qualquer tráfego que corresponda à lista de acesso 100 será classificado como class voip (o que significa tráfego
de voz) e receberá alta prioridade de até 32 kbps. A lista de acesso 100 corresponde às portas UDP comuns utilizadas por VoIP e
H.323 sinalizando tráfego para a porta TCP 1720. O comando class data1 corresponde ao tráfego da Web (porta TCP 80 como
visto na lista de acesso 101) e garante 64 kbps; o comando class data2 corresponde ao tráfego Telnet (porta TCP 23 como visto
na lista de acesso 102) e garante 32 kbps. A classe padrão está configurada para proporcionar uma porção igual da largura de
banda restante para fluxos não classificados. A política é chamada de llq e é aplicada em tráfego de saída em interface serial 1/0,
a qual tem uma largura de banda total de 256 kbps.
Observação Por padrão, a largura de banda total garantida e a largura de banda de prioridade para todas as classes
devem ser menores que 75 % da largura de banda da interface. É possível modificar esta porcentagem utilizando o
comando de configuração de interface max-reserved bandwidth.
Outros Mecanismos de Enfileiramento QoS
Vários outros métodos de enfileiramento estão disponíveis. Por exemplo, o Modified Deficit Round Robin (MDRR) é um
mecanismo de enfileiramento disponível no Gigabit Switch Routers (GSRs) da série Cisco 12000 que permite garantias de largura de
banda e serviço de prioridade com base em Precedência de IP, DSCP e classes MPLS EXP. O MDRR suporta uma fila de prioridade,
sete filas reservadas e uma fila múltipla.
Novamente, o VoIP exige prioridade, mas há aplicativos de dados que não podem ficar sem atividade e precisam de garantias de
largura de banda. É possível utilizar qualquer mecanismo de enfileiramento que efetivamente dê alta prioridade ao VoIP, mas nós
recomendamos o LLQ.
A Tabela 1 descreve alguns dos mecanismos de enfileiramento de software.
Tabela 1: Mecanismos de Enfileiramento de Software
Mecanismo de
Enfileiramento de
Software
Descrição
Benefícios
Limitações
FIFO
Os pacotes chegam e saem da fila
exatamente na mesma ordem.
Configuração simples e
operação rápida.
Não é possível garantir serviço de
prioridade ou de largura de banda.
WFQ
Um algoritmo de hashing coloca
Configuração simples.
Não é possível garantir serviço de
fluxos em filas separadas onde pesos
são utilizados para determinar
quantos pacotes são atendidos por
vez. Você estabelece relevância ao
definir valores de precedência do IP e
DSCP.
Padrão em ligações com
menos de 2 Mbps.
prioridade ou de largura de banda.
Custom Queueing
(CQ)
O tráfego é classificado em diversas
filas com limites de enfileiramento
configuráveis. Os limites de fila são
calculados com base no tamanho
médio do pacote, na MTU (maximum
transmission unit) e na porcentagem
de largura de banda a ser alocada. Os
limites de fila (em número de bytes)
são desenfileirados para cada fila,
sendo assim, fornecem a largura de
banda alocada estatisticamente.
Esteve disponível por
alguns anos e permite
alocação de largura de
banda aproximada para
filas diferentes.
Não é possível garantir serviços de
prioridade. As garantias de largura
de banda são aproximadas e há um
número de filas limitado. A
configuração é relativamente
difícil.
Priority Queueing
(PQ)
O tráfego é classificado em filas de
prioridade alta, média, normal e
baixa. O tráfego de alta prioridade é
atendido primeiro, seguido pelo de
média, normal e baixa prioridade.
Esteve disponível por
alguns anos e
proporciona serviço de
prioridade.
O tráfego de alta prioridade pode
deixar as filas de baixa prioridade
sem largura de banda. Não é
possível garantir largura de banda.
Class-Based
WFQ (CBWFQ)
O MQC é utilizado para classificar
tráfego. O tráfego classificado é
colocado em fila de largura de banda
reservada ou em uma fila padrão não
reservada. Um agendador serve as
filas com base nos pesos, portanto as
garantias de largura de banda são
honradas.
Semelhante ao LLQ,
exceto que não há fila
de prioridade.
Configuração simples e
capacidade de oferecer
garantias de largura de
banda.
Não é possível garantir serviços de
prioridade.
Fila de prioridade
WFQ (PQ-WFQ,
também chamado
de Prioridade
RTP de IP)
Um único comando de interface é
usado para fornecer serviço de
prioridade para todos os pacotes de
UDP destinados a números de porta
pares em um intervalo especificado.
Configuração simples,
de um único comando.
Fornece serviço de
prioridade aos pacotes
de RTP.
Todos os outros tráfegos são
tratados com o WFQ. O tráfego
RTCP não tem prioridade.
Nenhuma capacidade garantida de
largura de banda.
LLQ
(previamente
chamado de PQCBWFQ)
O MQC é utilizado para classificar
tráfego. O tráfego classificado é
colocado em uma fila de prioridade,
em filas com largura de banda
reservadas ou em uma fila sem
reserva padrão. Um programador
atende às filas de acordo com os
pesos, de modo que o tráfego de
prioridade seja enviado primeiro (até
um determinado limite vigiado
durante o congestionamento) e as
garantias de largura de banda sejam
atendidas.
Configuração simples.
Capacidade de dar
prioridade às diversas
classes de tráfego e
definir limites
superiores para
utilização prioritária de
largura de banda. É
possível também
configurar classes de
largura de banda
garantida e uma classe
padrão.
Nenhum mecanismo para fornecer
múltiplos níveis de prioridade
ainda o tráfego de prioridade é
enviado por meio da mesma fila de
prioridade. As classes de prioridade
separadas podem ter limites de
largura de banda de prioridade
superior durante congestionamento,
mas o compartilhamento de fila de
prioridade entre aplicativos pode
introduzir o efeito de variação de
sinal.
Fragmentação e Intercalação
Como as transmissões de VoIP são extremamente sensíveis a atraso, os pacotes VoIP devem ser intercalados ou inseridos entre
fragmentos de pacotes de dados. Esta seção descreve fragmentação e intercalação e inclui as seguintes subseções:
Visão Geral de Fragmentação e Intercalação
Exemplo de Fragmentação e Intercalação de Ligação MLP
Exemplo de Fragmentação e Intercalação FRF.12
Visão Geral de Fragmentação e Intercalação
Mesmo se o enfileiramento estiver funcionando em seu melhor e dando prioridade ao tráfego de voz, há momentos em que a fila de
prioridade está vazia e um pacote de outra classe é atendido. Os pacotes de classes de largura de banda garantida devem ser atendidos
de acordo com seu peso configurado. Se um pacote de voz de prioridade chega na fila de saída enquanto estes pacotes estão sendo
atendidos, o pacote VoIP pode esperar uma quantidade de tempo substancial antes de ser enviado. Se consideramos que um pacote
VoIP precisará esperar atrás do pacote de dados e que o pacote de dados pode ter, no máximo, tamanho igual ao MTU (1500 bytes
para serial e 4470 bytes para interfaces seriais de alta velocidade), podemos calcular o tempo de espera com base na velocidade da
ligação.
Por exemplo, para uma velocidade de ligação de 64 kbps e tamanho de MTU de 1500 bytes, temos:
Serialization delay = (1500 bytes * 8 bits/byte) / (64,000 bits/sec) = 187.5 ms
Portanto, um pacote VoIP pode precisar esperar até 187,5 ms antes de poder ser enviado se o atraso ocorrer atrás de um único pacote
de 1500 bytes em uma ligação de 64 kbps. Os pacotes VoIP são normalmente enviados a cada 20 ms. Com um orçamento de atraso
de ponta a ponta de 150 ms e requisitos de variação de sinal estrita, uma lacuna de mais de 180 ms é inaceitável.
É necessário um mecanismo que garanta que o tamanho de uma unidade de transmissão seja menor que 10 ms. Qualquer pacote que
tenha um atraso de serialização maior que 10 ms precisam ser fragmentado em blocos de 10 ms. Um bloco ou fragmento de 10 ms é
o número de bytes que pode ser enviado pela ligação em 10 ms. Você pode calcular o tamanho utilizando a velocidade da ligação:
Fragmentation size = (0.01 seconds * 64,000 bps) / (8 bits/byte) = 80 bytes
São precisos 10 ms para enviar um pacote de 80 bytes ou fragmento em uma ligação de 64 kbps.
Em ligações de baixa velocidade onde o pacote com tamanho de 10 ms é menor que o MTU, a fragmentação é necessária. A
fragmentação simples é insuficiente, entretanto, porque o pacote VoIP deve esperar atrás de todos os fragmentos de um único pacote
grande de dados, o pacote VoIP ainda será atrasado além do limite de atraso de ponta a ponta. O pacote de VoIP deve ser intercalado
com ou inserido entre os fragmentos do pacote de dados. A Figura 2 ilustra fragmentação e intercalação.
Figura 2: Fragmentação e Intercalação de Pacote VoIP
A Tabela 2 exibe os tamanhos de fragmentos recomendados para várias velocidades de ligação com base na regra de 10 ms.
Tabela 2: Velocidade da Ligação e Tamanho da Fragmentação
Velocidade da
Ligação (kbps)
Tamanho da Fragmentação (Bytes)
56
70
64
80
128
160
256
320
512
640
768
960
1024
1280
1536
1920 (Não é exigida fragmentação se o tamanho da fragmentação for maior do que o tamanho do MTU da
ligação. Por exemplo, para uma ligação T1 com um MTU de 1500 bytes, o tamanho do fragmento é de
1920 bytes; portanto, não é exigida fragmentação.)
Observação O tamanho da fragmentação do pacote nunca deve ser menor do que o tamanho do pacote VoIP. Além disso,
você nunca deve fragmentar pacotes VoIP fragmentar pacotes VoIP pode causar inúmeros problemas de configuração e
qualidade de chamada.
Três mecanismos LFI (link fragmentation and interleaving) estão disponíveis. A Tabela 3 lista seus benefícios e limitações.
Tabela 3: Velocidade da Ligação e Tamanho da Fragmentação
Mecanismo LFI
Descrição
Benefícios
Limitações
Fragmentação de
MTU com WFQ
Comando de nível de interface
para alterar o tamanho de MTU
ou o tamanho de MTU de IP.
Utilizado para fragmentar pacotes
grandes de IP em um tamanho
MTU especificado. O LFI usa
WFQ para intercalar pacotes em
tempo real entre os fragmentos.
Configuração simples.
Os fragmentos são reagrupados
apenas através do recebimento de
aplicativos; portanto, a utilização de
redes é ineficiente. Apenas os
pacotes de IP com o bit DF (Don't
Fragment) não definido pode
controlar bem a fragmentação. Uso
altamente intensivo.do processador.
Não recomendado.
Multilink Point-toPoint Protocol
(MLP) Link
Fragmentation and
Interleaving (LFI)
Nos enlaces seriais ponto a ponto,
o MLP deve primeiro ser
configurado e, então, um tamanho
da fragmentação deve ser
definido em milissegundos. O
entrelaçamento também deve ser
habilitado na interface multilink.
Os pacotes são
fragmentados em uma
extremidade do enlace e
remontados na outra. É
possível combinar várias
ligações para atuarem
como uma grande
tubulação virtual.
Disponível apenas nas ligações
configuradas para PPP. Soluções
para PPP por Frame Relay ou para
PPP por ATM também são
suportadas no Cisco IOS Versão
12.1(5)T ou em versões posteriores.
Fragmentação do
Frame Relay
(FRF.12)
Em PVCs de Frame Relay, o
comando de configuração de
interface de modelagem do
tráfego frame-relay deve ser
ativado e o tamanho da
fragmentação definido na classe
de mapa.
Os pacotes são
fragmentados em uma
extremidade do PVC e
remontados na outra.
Disponível somente em PVCs de
Frame Relay com o comando de
configuração de interface de
modelagem do tráfego frame-rela
y habilitado.
Exemplo de Fragmentação e Intercalação de Ligação MLP
O seguinte exemplo de configuração mostra como configurar a fragmentação e a intercalação utilizando o MLP LFI:
Exemplo de Configuração 6: MLP LFI
interface Serial1/0
bandwidth 256
encapsulation ppp
no fair-queue
ppp multilink
multilink-group 1
!
interface Multilink1
ip address 10.1.1.1 255.255.255.252
bandwidth 256
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
multilink-group 1
Nesse exemplo, o MLP LFI está configurado com um tamanho da fragmentação de 10 ms, que é calculado com base na largura
de banda configurada para a interface multilink. A interface serial de 1/0 é colocada em um grupo multilink 1 e, portanto, herda
a configuração multilink na interface multilink 1.
Exemplo de Fragmentação e Intercalação FRF.12
O seguinte exemplo de configuração mostra como configurar a fragmentação e intercalação utilizando o FRF.12:
Exemplo de Configuração 7: Fragmentação de Frame Relay (FRF.12) LFI
interface Serial 0/1
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
!
interface Serial 0/1.64 point-to-point
ip address 10.14.96.2 255.255.255.252
frame-relay interface-dlci 128
class voice
!
map-class frame-relay voice
frame-relay cir 256000
frame-relay fragment 320
Nesse exemplo, a modelagem de tráfego Frame Relay está habilitada em DLCI 128 e FRF.12 está configurada com tamanho da
fragmentação de 320 bytes, que é 10 ms da CIR (committed information rate). O tamanho da fragmentação deve ser 10 ms da
velocidade da porta mais baixa nos pontos finais do PVC; esse exemplo supõe que a CIR e a velocidade da porta mais baixa são
as mesmas: 256 kbps.
Modelagem de tráfego
A modelagem de tráfego é um mecanismo QoS utilizado para enviar o tráfego em intermitências curtas em uma taxa de transmissão
definida. É geralmente mais utilizado em ambientes de Frame Relay onde a taxa de relógio da interface não é a mesma que a largura
de banda garantida ou a CIR. Esta seção descreve modelagem de tráfego e inclui as seguintes subseções:
Visão Geral de Modelagem de Tráfego
Exemplo de Modelagem de Tráfego de Frame Relay
Visão Geral de Modelagem de Tráfego
A modelagem de tráfego de Frame Relay é o aplicativo de modelagem de tráfego mais utilizado em ambientes VoIP. Os cenários de
Frame Relay geralmente têm uma rede de hub e eixos onde a velocidade da ligação do hub é maior do que qualquer velocidade de
ligações remotas. Em alguns casos, a soma das velocidades de ligações remotas é maior do que a velocidade da ligação do hub,
causando excesso de assinaturas. Sem a modelagem de tráfego de Frame Relay, o hub pode tentar enviar em taxas de tráfego maiores
do que os remotos podem receber, fazendo com que a rede de Frame Relay descarte o tráfego arbitrariamente. Entretanto, os remotos
poderiam enviar em uma taxa agregada maior do que o hub pode receber, fazendo novamente com que a rede de Frame Relay
descarte o tráfego arbitrariamente. Quando nos referimos à rede de Frame Relay, significa a rede do SP (service provider) dos
switches de WAN que fornecem a conectividade PVC de ponta a ponta. Porque a rede WAN SP não tem Camada 3 ou inteligência
em nível superior, o tráfego de VoIP pode ser encerrado se os contratos são violados. Portanto, é necessário controlar as taxas de
transmissão dentro da rede de Frame Relay, assim é possível controlar quais pacotes foram descartados e quais pacotes recebem
serviço de prioridade. A Figura 3 mostra um exemplo de uma típica rede de Frame Relay sem modelagem de tráfego.
Figura 3: Rede de Frame Relay
Exemplo de Modelagem de Tráfego de Frame Relay
O seguinte exemplo de configuração mostra como configurar uma modelagem de tráfego de Frame Relay:
Exemplo de Configuração 8: Modelagem de Tráfego de Frame Relay
interface Serial 0/1
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
!
interface Serial 0/1.64 point-to-point
ip address 10.14.96.2 255.255.255.252
frame-relay interface-dlci 128
class voice
!
map-class frame-relay voice
no frame-relay adaptive-shaping
frame-relay cir 256000
frame-relay bc 2560
frame-relay mincir 256000
Neste exemplo, a modelagem de tráfego de Frame Relay está habilitada na interface serial principal 0/1 e DLCI 128 está
colocada em uma classe de modelagem de voz. O mapa de classes de voz configura uma CIR de 256000 bps e uma taxa Bc
(burst committed) de 2560 bits. Essa configuração significa que o router enviará 2560 bits a cada 2560/256.000 segundos (10
ms) e enfileira as intermitências excedentes. A CIR mínima é configurada no mesmo valor da CIR, e a modelagem adaptável é
desabilitada. O valor de Be (excess burst) da Frame Relay não está definido e, portanto, o padrão é 0, evitando qualquer
intermitência maior do que a CIR. Essa é a configuração recomendada para a modelagem de tráfego quando carregando VoIP.
Compressão de Cabeçalho RTP IP
A compressão de cabeçalho de IP RTP reduz o cabeçalho de 40 byte IP+UDP+RTP para 2 a 4 bytes, conseqüentemente reduzindo a
largura de banda necessária por chamada de voz em ligações de ponto a ponto. O cabeçalho é compactado em uma extremidade do
enlace e descompactado na outra extremidade. Outro nome padrão para esta técnica é cRTP, que significa RTP compactado. A
Figura 4 mostra a funcionalidade da compressão do cabeçalho RTP.
Figura 4: Compressão de Cabeçalho RTP
Para configurar a compressão de cabeçalho IP RTP, é necessário configurar o comando ip rtp header-compression sob a interface
serial, ou o comando frame-relay ip rtp header-compression sob a subinterface de Frame Relay. Você também pode definir o
comando de configuração de interface ip rtp compression-connections para definir um número máximo de fluxos que serão
compactados. Porque o processador cRTP pode ser intensivo, é necessário limitar o número de fluxos compactados para evitar a
degradação do desempenho do router. O RTP comprimido é recomendado em ligações de velocidade baixa onde a largura de banda é
pequena e há poucas chamadas de VoIP.
Serviços Diferenciados para VoIP
Os modelos de QoS de arquitetura dos DS (Differentiated Services) fornecem um mecanismo escalável para classificar os pacotes
nos grupos ou classes que possuem requisitos semelhantes de QoS. Esta seção descreve os DS e inclui as seguintes subseções:
Visão Geral de DS e de DSCP (RFC 2474, RFC 2475)
Implementação DS para VoIP: Encaminhamento Expedido PHB (RFC 2598)
Exemplo de Configuração de Marcação com Base em Classe DSCP
Visão Geral de DS e de DSCP (RFC 2474, RFC 2475)
As primeiras redes IP foram baseadas no modelo de empenho máximo de serviço, o que significa que os atrasos, efeito de variação
de sinal, perda de pacotes e alocação de largura de banda eram imprevisíveis. Hoje, um grande número de redes ainda seguem o
modelo de empenho máximo e não suportam aplicativos aprimorados que exigem um tipo de garantia de serviço.
Utilizando o modelo de empenho máximo, os provedores de serviço não têm meios de oferecer SLAs (service level agreements) para
seus clientes, acabam por provisionar muito suas redes para lidar com as horas de tráfego mais ocupadas. Os clientes de nível
empresarial e os usuários finais não têm como fornecer tratamento de prioridade ou largura de banda garantida para VoIP. O tráfego
é tratado em uma base FIFO simples, sem execução do QoS.
A primeira abordagem arquitetônica para fornecer o QoS de ponta a ponta necessário, no qual o aplicativo sinaliza os requisitos de
recursos do QoS (como largura de banda e atraso garantido) para a rede. Em um cenário de VoIP, essa abordagem arquitetônica
significa que tanto o telefone IP ou o gateway de voz precisaram fazer exigências de QoS para todos os nós da rede; assim os
recursos de ponta a ponta seriam alocados. Todos os nós precisaram manter informações sobre o estado da chamada para determinar
quando liberar os recursos de QoS para outras chamadas e aplicativos, e se havia recursos suficientes disponíveis para aceitar
chamadas com garantias de QoS. Este método é chamado de modelo QoS de Serviços Integrados. A implementação mais comum de
Serviços Integrados utiliza o RSVP (Resource Reservation Protocol). O RSVP tem algumas vantagens, como o CAC (Call
Admission Control), onde uma chamada pode ser redirecionada pelo envio de um sinal apropriado para o originador se a rede não
tiver os recursos de QoS disponíveis para suportá-lo. Entretanto, o RSVP também encontra problemas de escalabilidade; o RSVP e
esses problemas são abordados mais adiante neste documento.
A arquitetura DS é o modelo QoS mais implementado e suportado hoje em dia. Ele fornece um mecanismo escalável para classificar
os pacotes em grupos ou classes que possuem requisitos semelhantes de QoS, e então fornecem a esses grupos o tratamento exigido
em cada nó da rede. A escalabilidade é proveniente do fato de que os pacotes são classificados nas bordas da "rede" ou da região de
DS e são marcados adequadamente, o que faz com que os routers centrais da rede possam fornecer o QoS baseado simplesmente na
classe de DS. Os seis bits mais significativos do byte ToS (Type of Service) de IP são utilizados para especificar a classe de DS; o
DSCP (Differentiated Services Code Point) define esses seis bits. Os dois bits restantes do byte ToS de IP não são utilizados
atualmente.
A Figura 5 mostra como o cabeçalho IP define a classe de DS.
Figura 5: Definições de Campo de Serviços Diferenciados
Os Serviços Diferenciados estão descritos e definidos nos seguintes RFCs:
RFC 2474, Definição do Campo de Serviços Diferenciados (Campo DS)
RFC 2475, Uma Arquitetura para Serviços Diferenciados
RFC 2597, Grupo PHB de Encaminhamento Garantido
RFC 2598, PHB de Encaminhamento Expedido
O RFC 2474 propõe um modo de interpretar um campo que sempre foi parte de um pacote IP. Como mencionado anteriormente
neste documento, o campo ToS descreve um byte inteiro (oito bits) de um pacote IP. A precedência se refere aos três bits mais
significativos do byte ToS, que é [123]45678. (Ocasionalmente, o termo ToS é utilizado para se referir aos próximos três bits:
123[456]78; no entanto, nesse documento, para ser consistente com a especificação original de RFC para o cabeçalho IP (RFC 791),
o ToS se refere ao conjunto todo de oito bits.)
Os três primeiros bits do DSCP são utilizados como bits seletores de classe; o bit seletor de classe torna o DSCP compatível com a
Precedência de IP porque a Precedência de IP utiliza os mesmos três bits para determinar a classe. A Tabela 4 mostra os valores do
bit de Precedência de IP mapeados para o DSCP.
Tabela 4: Precedência de IP para Mapeamento de DSCP
Precedência de IP
Valor do Bit de Precedência de IP
Bits DSCP
Classe DSCP
5
101
101000
Encaminhamento expedido
4
100
100000
Encaminhamento Garantido 4
3
011
011000
Encaminhamento Garantido 3
2
010
010000
Encaminhamento Garantido 2
1
001
001000
Encaminhamento Garantido 1
0
000
000000
Melhor Esforço
Os próximos dois bits são utilizados para definir as preferências de queda. Por exemplo, se o tráfego na Classe 4 (os três primeiros
bits são 100) excede uma certa taxa contratada, os pacotes em excesso poderiam ser remarcados e, assim, a preferência de queda será
elevada em vez de ser descartada. Se um congestionamento ocorrer na rede DS, os primeiros pacotes a serem descartados serão os
pacotes de "preferência de queda alta". É semelhante à marcação do bit DE no Frame Relay e à marcação do bit CLP no ATM. Esses
mecanismos permitem à rede da Camada 2 realizar decisões inteligentes de queda para um tráfego em não conformidade durante
períodos de congestionamento. O DS permite uma operação semelhante sobre uma rede IP. O sexto bit deve estar configurado em 0
para indicar aos dispositivos da rede que as classes foram definidas de acordo com o padrão DS.
A arquitetura DS define um conjunto de condicionadores de tráfego que são utilizados para limitar o tráfego em uma região de DS e
colocá-lo em classes de DS adequadas. Metros, marcadores, modeladores e quedas são todos os condicionadores de tráfego. Os
metros são basicamente vigilantes, e uma política baseada em classe (que você configura utilizando o comando police policy-map
configuration sob uma classe no Modular QoS CLI) é uma implementação compatível com DS de um metro. Você pode utilizar a
marcação com base em classe para definir o DSCP e a modelagem baseada em classe como o modelador. WRED (Weighted Random
Early Detect) é um mecanismo de queda que é suportado, mas você não deve solicitar a WRED na classe VoIP. O PHB (per hop
behavior) descreve pelo que uma classe de DS deveria passar em termos de perda, atraso e variação de sinal. Um PHB determina
como a largura de banda é alocada, como o tráfego é restringido e como os pacotes são descartados durante um congestionamento.
Três PHBs são definidos em DS baseado no comportamento de encaminhamento exigido:
Classe de Empenho Máximo—Bits seletores de classe configurados em 000
Encaminhamento Garantido PHB—Bits seletores de classe configurados em 001, 010, 011 ou 100
Encaminhamento Expedido PHB—Bits seletores de classe configurados em 101
O padrão AF (Assured Forwarding) especifica quatro classes de largura de banda garantidas e descreve o tratamento que cada uma
deve receber. Também especifica os níveis de preferência de queda, resultando em um total de 12 classes de AF possíveis, como
mostrado na Tabela 5.
Tabela 5: Classes de Encaminhamento Garantido Possíveis
Níveis da Preferência de Queda
Classe AF1
Classe AF2
Classe AF3
Classe AF4
Precedência de Queda Baixa
001010
010010
011010
100010
Precedência de Queda Média
001100
010100
011100
100100
Precedência de Queda Alta
001110
010110
011110
100110
Você provavelmente utilizará as classes de Encaminhamento Garantido para tráfego de dados, que não exige um tratamento de
prioridade e é, em grande parte, baseado em TCP. O Encaminhamento Expedido possui uma compatibilidade maior com os
requisitos de VoIP QoS.
Implementação DS para VoIP: Encaminhamento Expedido PHB (RFC 2598)
O Encaminhamento Expedido, EF (Expedited Forwarding), é destinado para aplicativos sensíveis a atrasos que exigem uma largura
de banda garantida. Uma marcação de EF garante um serviço de prioridade através da reserva de uma quantidade mínima de largura
de banda que pode ser utilizada para tráfegos de alta prioridade. No EF, a taxa de saída (ou a prioridade da largura de banda
configurada) deve ser maior ou igual à soma das taxas de entrada, assim não há congestionamento para pacotes marcados com EF.
Você implementa o comportamento EF utilizando a fila de prioridade estrita no LLQ (low latency queueing). A largura de banda
constante é garantida pelo tráfego que pertence à classe EF, mas ao mesmo tempo, se há congestionamento, pacotes em não
conformidade que excedem a taxa de prioridade especificada são descartados para garantir que os pacotes em outras filas que
pertencem a classes diferentes não tenham necessidade de largura de banda. O valor DSCP recomendado para EF é 101110 (46). Os
três primeiros bits desse valor de EF correspondem à Precedência de IP 5, que é a definição do comando da configuração do ponto de
discagem ip precedence recomendado para o tráfego de VoIP. Portanto, se os dispositivos IP da rede podem reconhecer a
Precedência de IP ou o DSCP com a finalidade de classificação e marcação, você pode fornecer um QoS de ponta a ponta.
Exemplo de Configuração de Marcação com Base em Classe DSCP
A arquitetura DS especifica como classificar, marcar, vigiar e modelar o tráfego digitando uma região DS e como tratar classes
diferentes em todos os nós na região DS. Na extremidade do DS, todos os pacotes IP estão marcados com o DSCP apropriado, assim
o QoS pode ser fornecido baseado no DSCP interno da região DS. O seguinte exemplo de configuração mostra como configurar a
marcação DSCP na extremidade utilizando a marcação com base em classe:
Exemplo de Configuração 9: Marcação Baseada em Classe de DSCP
access-list 100 permit udp any any range 16384 32000
access-list 100 permit tcp any any eq 1720
access-list 101 permit tcp any any eq 80
!
class-map voip
match access-group 100
class-map webtraffic
match access-group 101
!
policy-map dscp_marking
class voip
set ip dscp 46
#EF Class
class webtraffic
set ip dscp 26
#AF Class
!
interface Ethernet0/0
service-policy input dscp_marking
Nesse exemplo, todo o tráfego que estiver chegando na interface Ethernet 0/0 é inspecionado e classificado com base em
voip e webtraffic mapas de classe. O comando de configuração global de mapa de políticas define o DSCP em voip classe de
tráfego em 46 (101110 para EF) e a classe de tráfego webtraffic em 26 (011010 para AF3).
Todos os enfileiramentos e outros parâmetros de QoS podem agora ser configurados para serem compatíveis como o DSCP no resto
da região DS.
Nas seções restantes desse documento, vamos corresponder o tráfego de Precedência de IP 5 como VoIP e o tráfego de Precedência
de IP 3 como HTTP (tráfego na web), com todos os outros tráfegos indo para a classe padrão. De forma semelhante, o DSCP 46
poderia ser utilizado para VoIP e o DSCP 26 para HTTP. Poderíamos utilizar vários outros mecanismo de marcação e classificação
mas, para manter a consistência e simplicidade, utilizaremos a Precedência de IP.
Protocolo de Reserva de Recursos
O RSVP (Resource Reservation Protocol) é uma implementação da arquitetura de Serviços Integrados para QoS (RFC 2205).
Quando o VoIP foi introduzido, o RSVP foi imediatamente visto como um componente-chave que forneceria controle de admissão e
QoS para fluxos de VoIP. Entretanto, o modo como o RSVP e o H.323 foram integrados anteriormente não forneceu controle de
admissão nem QoS apropriado para fluxos de voz. Vários aprimoramentos foram feitos para tratar essas limitações, e agora o RSVP
pode ser utilizado para implementar o CAC e para sinalizar um QoS desejado que fornecerá boa qualidade de voz de ponta a ponta,
mesmo se houver congestionamento.
Nesta seção, o RSVP é descrito (de maneira geral) focando em um subconjunto particular de plataformas, topologias e protocolos.
Também supomos que você esteja utilizando o H.323 como o protocolo de sessão para uma rede baseada em gateway de VoIP. Esta
seção inclui as seguintes subseções:
Visão Geral do RSVP
Visão Geral de RSVP para CAC
Implementando CAC com Base em RSVP
Configurando Recursos de Gateway Local se o CAC Falhar
Utilizando RSVP com LLQ
Implementando Suporte RSVP para LLQ
Visão Geral do RSVP
A implementação inicial do RSVP para VoIP possui duas limitações. A primeira era que o CAC não poderia ser implementado com
RSVP devido ao processo de reserva não ter sido sincronizado com a sinalização de chamada de voz. Uma chamada seria processada
mesmo se a reserva RSVP houvesse falhado ou não fosse completada. A segunda limitação era que uma reserva RSVP bem sucedida
poderia não oferecer boa qualidade de voz durante os períodos de congestionamento de rede. O RSVP cria um fluxo de fila por
tráfego reservado dentro do sistema WFQ e dependia desse sistema para garantir um atraso limitado. Entretanto, em alguns casos, o
WFQ não era capaz de fornecer um atraso limitado aceitável de voz. O RSVP precisa ser capaz de usar a fila de prioridade no LLQ
para garantir um atraso limitado que não afetaria a qualidade de voz. Além disso, o RSVP não tinha suporte em ATM ou em PVCs
de Frame Relay modelados.
Você deve implementar o RSVP para aprimorar o VoIP QoS apenas onde ele possa ter um impacto positivo na qualidade e na
funcionalidade. Os benefícios da utilização de RSVP são maiores que os custos (gerenciamento, custos indiretos e impacto de
desempenho) apenas quando houver largura de banda limitada e congestionamento de rede freqüente. Alguns ambientes IP possuem
largura de banda suficiente para garantir o QoS apropriado sem a necessidade de implementar CAC em todas as chamadas.
Os quatro mecanismos seguintes foram introduzidos no software Cisco IOS para lidar com CAC baseado em recursos:
PSTN fallback—Esse método depende da investigação da rede para medir o atraso, a variação de sinal e a perda para estimar o
defeito de voz em potencial que uma chamada sofrerá. (O defeito em potencial é chamado de ICPIF (Calculated Planning
Impairment Factor) e é explicado no ITU-T G.113). Com esse mecanismo, é possível definir diversos limiares para que as
chamadas sejam rejeitadas se uma rede IP estiver congestionada.
O CAC é definido em recursos de gateway locais, como CPU, memória e número de chamadas?Com esse método, é possível
configurar os limiares que acionam ações diferentes, como grampear chamada, rejeitar chamada ou tocar uma mensagem.
Gerenciamento de largura de banda por meio de gatekeeper H.323— —Nesse método, é possível configurar um valor máximo
de largura de banda que os gatekeepers alocam para chamadas.
RSVP.
Neste documento, discutimos apenas a utilização de RSVP para CAC.
Visão Geral de RSVP para CAC
O uso do RSVP para VoIP CAC exige a sincronização da sinalização de configuração de chamadas e a sinalização do RSVP. Essa
sincronização garante que o telefone da parte chamada toque apenas depois dos recursos da chamada serem reservados. Essa
sincronização também fornece aos gateways de voz o controle de quais ações devem ser adotadas antes que a configuração de voz
mude para o estágio alerta se a reserva falhar e não puder ser completada dentro de um período predefinido. Uma chamada de voz
acionará duas reservas RSVP porque os mecanismos de controle de reserva e admissão fornecidos pelo RSVP são unidirecionais.
Cada gateway de voz é responsável por iniciar e manter uma reserva em direção a outro gateway de voz. O CAC para uma chamada
VoIP falha se ao menos uma das reservas falhar. A Figura 6 exibe a seqüência de pacotes trocados entre os gateways durante uma
configuração de chamada se o RSVP for usado para reserva de recurso.
Figura 6: Configuração de Chamada com RSVP Ativado
Na Figura 6, um OGW (originating gateway) inicia uma chamada em direção a um TGW (terminating gateway). O gateway de
origem envia uma mensagem H.323 SETUP ao gateway de terminação para iniciar a chamada. Essa mensagem SETUP executa o
QoS que o gateway de origem considera aceitável para a chamada. O gateway de terminação responde com uma mensagem H.323
CALL PROCEEDING. Os gateways de terminação e de origem iniciam uma requisição de reserva enviando uma mensagem RSVP
PATH. Os fluxos de pacote de ambas reservas são independentes, exceto se um deles falhar. O gateway de terminação bloqueia o
processo de configuração de chamada esperando pelos resultados da reserva. O gateway de terminação controla a decisão de
admissão da chamada e precisa ser notificada que as reservas obtiveram sucesso nas duas direções. O gateway de terminação
descobre que a sua reserva obteve sucesso quando ele recebe a mensagem RSVP RESV. O gateway de terminação detecta que a
reserva do gateway de origem obteve sucesso quando ele recebe a mensagem RSVP RESV CONFIRMATION do gateway de
origem. Nesse ponto, o gateway de terminação permite a continuação da configuração da chamada e envia uma mensagem H.323
ALERTING ao gateway de origem quando ele é notificado que a parte chamada está em estado de alerta. Uma desconexão normal é
iniciada quando uma mensagem H.323 RELEASE COMPLETE é enviada após a chamada ser conectada. Neste ponto, os gateways
interrompem as reservas enviando as mensagens RSVP PATH TEAR e RESV TEAR.
Se ao menos uma reserva RSVP falhar, é possível configurar um gateway de voz para executar as seguintes ações:
O gateway de voz pode informar a falha na chamada ao usuário ou switch que enviou a chamada.
A chamada pode ser redirecionada por outro caminho.
A chamada pode ser conectada com QoS de empenho máximo.
Esse último comportamento é possível porque o gateway de terminação sabe qual QoS é aceitável para a chamada de sua própria
configuração e o valor incluído pelo gateway de origem na mensagem H.323 SETUP. Se o gateway de terminação e o gateway de
origem solicitarem um QoS sem empenho máximo e ao menos uma reserva falhar, a chamada será transferida como empenho
máximo apenas se o gateway de origem e o gateway de terminação estiverem dispostos a aceitar o serviço de empenho máximo. A
liberação e o roteamento de chamadas são possíveis se um dos dois gateways de voz não aceitarem o serviço de empenho máximo.
Se você configurar o gateway para rejeitar a chamada e informar a falha, os troncos CAS e as linhas analógicas geram um sinal de
ocupado rápido. Nos troncos CCS PRI, uma mensagem Q.931 DISCONNECT com uma causa "QoS indisponível" (49) será gerada.
A Figura 7 exibe os detalhes de uma chamada que é rejeitada porque a reserva iniciada de um gateway de terminação falhou.
Figura 7: Falha na Chamada RSVP CAC Porque a Reserva do Gateway de Terminação Falhou
Implementando CAC com Base em RSVP
Conforme mencionado anteriormente, você deve implementar o RSVP para aprimorar o VoIP QoS apenas onde ele pode ter um
impacto positivo na qualidade e na funcionalidade. Os benefícios do uso do RSVP são mais importantes que os custos apenas onde a
largura de banda é limitada. Recomendamos o uso do Cisco IOS Versão 12.1(5)T ou mais atual se desejar implementar um CAC
para VoIP utilizando RSVP.
Precisamos completar as três etapas básicas seguintes para configurar o CAC para chamadas VoIP utilizando RSVP:
Habilite a sincronização entre o RSVP e a sinalização de chamadas. (Essa sincronização é habilitada por padrão quando o
Cisco IOS Versão 12.1(5)T ou posterior estiver em execução.
Configure os gateways de voz nos dois lados do ponto de discagem VoIP para solicitar um determinado QoS via RSVP.
Habilite o RSVP e especifique a largura de banda máxima de todos as ligações que são cruzadas por pacotes de voz onde o
congestionamento tem probabilidade de ocorrer.
O exemplo de configuração a seguir mostra como configurar o CAC para VoIP utilizando RSVP:
Exemplo de Configuração 10: Implementando CAC Utilizando RSVP
hostname LongBay
!
isdn switch-type primary-ni
call rsvp-sync
!
controller T1 1/0
framing esf
linecode b8zs
pri-group timeslots 1-24
!
interface Ethernet0/0
ip address 10.0.152.254 255.255.255.0
!
interface Serial0/0
bandwidth 1536
ip address 10.10.1.1 255.255.255.0
encapsulation ppp
ip tcp header-compression iphc-format
ip rtp header-compression iphc-format
ip rsvp bandwidth 1152 24
!
interface Serial1/0:23
no ip address
no logging event link-status
isdn switch-type primary-ni
isdn incoming-voice voice
no cdp enable
!
ip route 0.0.0.0 0.0.0.0 10.10.1.2
!
voice-port 1/0:23
!
dial-peer voice 100 pots
destination-pattern 2......
no digit-strip
direct-inward-dial
port 1/0:23
!
dial-peer voice 300 voip
destination-pattern 3......
session target ipv4:10.77.39.129
req-qos guaranteed-delay
acc-qos guaranteed-delay
!
line con 0
line aux 0
line vty 0 4
!
end
Esse exemplo exibe uma configuração de gateway de voz completa que realça os comandos de configuração de CAC utilizando
RSVP. O gateway de voz pode agir como um gateway de origem e como um gateway de terminação com essa configuração.
Não priorizamos a sinalização de voz nesse exemplo.
A configuração do ponto de discagem padrão solicita e aceita QoS de empenho máximo para chamadas VoIP. Isso significa que o
gateway não inicia uma reserva de RSVP para a chamada porque o IP fornece serviço de empenho máximo por padrão. As outras
duas alternativas são QoS de fila controlada ou atraso garantido. Esses dois serviços exigem sinalização de RSVP; ela é solicitada
usando o comando de configuração de ponto de discagem req-qos. O QoS aceitável controla o quanto o critério CAC deve ser
rígido; você configura os controles QoS aceitáveis utilizando o comando de configuração de ponto de discagem acc-qos.
Recomendamos a configuração do gateway de origem e o gateway de terminação para solicitar e aceitar o atraso garantido.
Algumas vezes pode-se configurar o ponto de discagem implícito que corresponde a um gateway de terminação para solicitar e
aceitar QoS de empenho máximo. Esse ponto de discagem tem efeito quando não há um ponto de discagem explícito correspondente.
Configurando Recursos de Gateway Local se o CAC Falhar
Como mencionado anteriormente, é possível configurar um gateway de voz para executar diferentes ações se o controle de admissão
falhar. A primeira alternativa é fazer com que os gateways sinalizem o usuário ou switch que enviou a chamada com um sinal de
ocupado rápido ou uma causa de desconexão. Se a chamada tiver sido feita ao gateway por um switch de ISDN, você pode ajustar a
causa de desconexão Q.931 para garantir que o switch processe a chamada corretamente. Uma causa "QoS indisponível" (49) é
retornada por padrão quando uma chamada ISDN causa uma falha do CAC devido ao QoS solicitado e aceitável configurado. É
possível modificar essa causa com o comando de configuração de interface isdn network-failure-cause ou com o comando de
configuração de interface isdn disconnect-cause. O atual implementação do comando isdn network-failure-cause substitui o valor
configurado usando o comando isdn disconnect-cause.
O exemplo de configuração a seguir mostra como configurar os recursos de gateway locais se o CAC falhar ao ajustar a causa de
desconexão Q.931:
Exemplo de Configuração 11: Ajustando a Causa de Desconexão O.931
!
interface Serial1/0:23
no ip address
no logging event link-status
isdn switch-type primary-ni
isdn network-failure-cause 42
isdn incoming-voice voice
no cdp enable
!
Nesse exemplo, o router envia uma mensagem Q.931 DISCONNECT com uma causa "Congestionamento do Equipamento de
Comutação" (42) quando uma chamada ISDN causar a falha do CAC no trecho VoIP.
A segunda opção é permitir que o gateway redirecione a chamada por outro caminho. Se um ponto de discagem que corresponde à
chamada for parte de um grupo de busca, outros pontos de discagem do grupo são tentados de acordo com o comando de
configuração de ponto de discagem preference. Isso permite que você implemente tipos diferentes de roteamento de chamada do
gateway que considera QoS nas redes IP.
O exemplo de configuração a seguir mostra como configurar os recursos de gateway locais roteando as chamadas no gateway se o
CAC falhar:
Exemplo de Configuração 12: Re-roteamento de chamadas no Gateway
dial-peer voice 100 pots
destination-pattern 2......
no digit-strip
direct-inward-dial
port 1/0:23
!
dial-peer voice 300 voip
preference 0
destination-pattern 3......
session target ipv4:10.77.39.129
req-qos guaranteed-delay
acc-qos guaranteed-delay
!
dial-peer voice 400 voip
preference 2
destination-pattern 3......
session target ipv4:10.23.45.2
req-qos guaranteed-delay
acc-qos guaranteed-delay
!
dial-peer voice 500 pots
preference 5
destination-pattern 3......
no digit-strip
direct-inward-dial
port 1/1:23
!
Esse exemplo exibe uma implementação de re-roteamento de chamada no gateway. Nas chamadas para números de 7 dígitos
iniciando com o dígito 3, tentar os dois gateways de voz primeiro. As chamadas são roteadas através do PSTN pela porta de voz
1/1:23 se as chamadas de VoIP falharem devido ao CAC ou outro motivo.
A terceira possibilidade, disponível nas versões do Cisco IOS posteriores à 12.1(5)T, é configurar os gateways para continuar a
chamada mesmo se as reservas RSVP falharem. Esta opção, entretanto, não proporciona uma grande melhoria em relação à
funcionalidade da versão anterior do Cisco IOS. O único benefício que proporciona é que, em caso de uma reserva RSVP bem
sucedida, a chamada não prossegue até a reserva estar estabelecida.
Como mencionado anteriormente, uma chamada pode falhar no controle de admissão se pelo menos uma das duas reservas RSVP
necessárias para a chamada falhar. Para cada reserva RSVP, o controle de admissão é realizado em todas as interfaces onde você
habilitou RSVP utilizando o comando de configuração de interface ip rsvp bandwidth. Você pode configurar dois valores com o
comando ip rsvp bandwidth: a largura de banda reservada total máxima e a largura de banda máxima por reserva. A largura de
banda total máxima é limitada por padrão para não mais que 75% da largura de banda total da interface. Você pode modificar este
limite com o comando de configuração de interface max-reserved-bandwidth. As exceções à limitação de largura de banda total
máxima são PVCs de Frame Relay e ATM. Para PVCs de Frame Relay, a largura de banda reservável máxima é a CIR mínima ou,
se não configurada, metade da CIR. Para PVCs ATM, a largura de banda reservável máxima é 75% da taxa mínima de célula de
saída disponível configurada, SCR de saída VBR em tempo próximo ao real ou taxa média VBR em tempo real, o que estiver
configurado. A largura de banda total disponível para reservas de RSVP podem ser mais baixas se você reservou largura de banda
utilizando CBWFQ ou LLQ por meio de MQC. Um gerenciador de largura de banda se certifica de que a interface ou a largura de
banda do PVC não está com excesso de assinantes durante a operação do router.
Observação Esta verificação não é realizada durante a configuração do router.
Você deve configurar a largura de banda máxima por reserva para não menos do que o codec exige mais toda a carga adicional de
protocolo, exceto a a carga adicional de protocolo da Camada 2. A Tabela 6 mostra os menores valores que você pode utilizar para
codecs diferentes. Lembre-se de que estes valores não consideram as economias de largura de banda introduzidas pelo cRTP ou pela
VAD (voice activity detection). O fluxo de voz real pode utilizar menos largura de banda, mas o sistema utilizará o pior caso de
largura de banda.
Tabela 6: Largura de Banda Reservada pelo RSVP por Chamada VoIP
Codec
Largura de Banda Reservada por Chamada VoIP (kbps)
G711alaw
80
G711ulaw
80
G723ar53
22
G723ar63
23
G723r53
22
G723r63
23
G726r16
32
G726r24
40
G726r32
48
G728
32
G729br8
24
G729r8
24
GSMEFR
29
GSMFR
30
Uma consideração a ser feita na implementação de RSVP para VoIP é o impacto de reserva de recurso no atraso após discagem.
Implementar CAC para VoIP com base em RSVP depende de uma confirmação de prompt ou rejeição da reserva requerida. O tempo
gasto para reservar recursos aumenta o atraso após discagem, que deve ser mantido o mais baixo possível na maioria dos casos. Os
pacotes RSVP são transportados dentro de datagramas IP e são não-confiáveis por natureza. Se um pacote RSVP é perdido durante a
configuração de reserva inicial, um cronômetro de atualização do RSVP deve expirar antes que o pacote seja reenviado. Em razão
deste cronômetro de atualização ser definido tipicamente em décimos de segundos, um cenário que pode aumentar um atraso após
discagem é inaceitável para o usuário. O comando de configuração global call rsvp-sync resv-timer permite que você controle a
quantidade de tempo máxima que o gateway de terminação espera pelo resultado dos requerimentos de reserva de RSVP. O valor
padrão deste cronômetro é 10 segundos; você pode definir um valor de 1 a 60 segundos de acordo com sua expectativa de atraso
após discagem.
Utilizando RSVP com LLQ
Os fluxos que requerem um determinado QoS via RSVP podem levar vantagem nas alternativas de enfileiramento disponíveis no
LLQ, que têm dois importantes componentes: uma PQ (priority queue) estrita e um sistema CBWFQ. Implementações anteriores do
RSVP dependiam de WFQ para atender aos requerimentos de QoS para tráfego sensível a atraso. Um fila reservada com peso baixo
foi criada quando a reserva de RSVP foi instalada. Entretanto, WFQ não atendeu aos requerimentos de atraso de tráfego de voz e
chamadas de voz utilizando RSVP não conseguiam aproveitar a PQ disponível por meio de LLQ.
No Cisco IOS Versão 12.1(3)T e em versões posteriores, um perfil de prioridade com base em características do tráfego existe para
que determinados fluxos possam aproveitar a PQ estrita no LLQ. Quando uma requisição de reserva de RSVP é recebida em uma
interface onde WFQ foi habilitada, a TSpec (traffic specification) de fluxo é comparada com o perfil para decidir se aquele fluxo
deve aproveitar a PQ ou se uma fila deve ser reservada no sistema WFQ. A TSpec é a descrição do tráfego transportada em
mensagens RSVP. Esta descrição do tráfego é feita em termos de um token bucket (taxa de token r, mais um bucket de tamanho b) e
alguns parâmetros adicionais (taxa de pico p, unidade mínima vigiada m e tamanho máximo do pacote M). O perfil PQ é definido em
termos de taxa de token, tamanho de bucket e uma taxa de pico para proporção de taxa de token opcional. Reservas de fluxo com
uma TSpec que não exceda aquelas definidas no perfil PQ utilizarão a PQ. Aqueles fluxos com uma TSpec que exceda pelo menos
um parâmetro definido no perfil terá uma fila reservada no sistema WFQ. O perfil de prioridade permite que se classifique fluxos de
prioridade com base em suas características de tráfego—não apenas no protocolo de transporte e na porta. A Figura 8 mostra a
estrutura LLQ para uma interface onde o tráfego é classificado em filas diferentes utilizando vários métodos, incluindo RSVP.
Figura 8: Suporte RSVP para LLQ em Interfaces Ponta a Ponta
Cisco IOS Versão 12.1(5)T introduziu o suporte RSVP para LLQ em PVCs de Frame Relay. Neste caso, cada PVC tem sua própria
estrutura de enfileiramento com uma PQ e um sistema CBWFQ. No nível da interface, uma fila FIFO é configurada a menos que
você tenha habilitado a fragmentação FRF.12. Neste caso, um sistema FIFO dual é configurado com uma fila de alta prioridade e
uma fila de baixa prioridade. A fila de alta prioridade recebe o tráfego PQ de todos os PVCs mais o tráfego de controle da Camada 2.
A fila de baixa prioridade recebe todos os outros tráfegos de todos os PVCs. Lembre-se de que um FRTS (Frame Relay traffic
shaping) é necessária para circuitos de Frame Relay esteja a fragmentação FRF.12 habilitada ou não. O FRTS fornece o mecanismo
de pressão contrária para detectar congestionamento por PVC. O suporte para PVCs ATM está disponível no Cisco IOS Versão
12.2(1)T.
Implementando Suporte RSVP para LLQ
Você habilita suporte RSVP para LLQ por padrão para fluxos de voz em interfaces onde RSVP e WFQ estão habilitados. Não é
necessário configurar explicitamente filas de prioridade para pacotes de voz. Você pode configurar uma fila de prioridade
personalizada utilizando o comando de configuração global ip rsvp pq-profile. Configurar o perfil como ip rsvp pq-profile voicelike restaura o comportamento padrão. O perfil de fila de prioridade utiliza uma taxa de token de 12.288 bytes por segundo
(aproximadamente 98 kbps), um tamanho de bucket de 592 bytes e uma taxa de pico igual a 110% da taxa de token (13.516 bytes por
segundo ou aproximadamente 108 kbps). Estes valores de parâmetro suportam possíveis configurações de codec em gateways de voz
executando o software Cisco IOS. Um gateway de voz da Cisco configurado para reservar recursos via RSVP vai inferir a TSpec
correta exclusivamente pelo codec utilizado no ponto de discagem. Você não pode controlar valores de TSpec utilizando CLI e
nenhum outro recurso de economia de largura de banda (como o VAD) é considerado. Algumas revisões do Microsoft NetMeeting
para Windows 98 e Windows 2000 (que usam RSVP) sinalizam um tamanho de bucket no TSpec que não é compatível com estes
padrões. Este problema afeta o Microsoft NetMeeting em chamadas utilizando codecs que exigem 32 kbps ou mais. Em tais casos, é
necessário criar um perfil personalizado para corresponder aos parâmetros sinalizados pelo Microsoft Windows.
O seguinte exemplo de configuração mostra como configurar o suporte RSVP para LLQ em um circuito Frame Relay que tem dois
PVCs:
Exemplo de configuração 13: Suporte RSVP para LLQ em PVCs de Frame Relay
hostname LongBay
!
isdn switch-type primary-ni
call rsvp-sync
!
interface Serial0/0
bandwidth 1536
no ip address
encapsulation frame-relay
no fair-queue
frame-relay traffic-shaping
!
interface Serial0/0.1 point-to-point
ip address 10.10.1.2 255.255.255.0
frame-relay interface-dlci 16
class VoIPoFR
ip rsvp bandwidth 48 24
!
interface Serial0/0.2 point-to-point
ip address 10.10.2.2 255.255.255.0
frame-relay interface-dlci 17
class VoIPoFRip
rsvp bandwidth 48 24
!
ip rsvp pq-profile voice-like
!
map-class frame-relay VoIPoFR
no frame-relay adaptive-shaping
frame-relay cir 64000
frame-relay bc 640
frame-relay mincir 64000
frame-relay fair-queue
frame-relay fragment 80
!
Neste exemplo, WFQ é habilitado nos PVCs e desabilitado na interface física. Cada PVC tem uma fila de prioridade por tráfego
de voz. A interface física tem a estrutura de fila de FIFO dual. O FRTS é habilitado e seus parâmetros são definidos no mapa de
classe VoIPoFR.
Uma das implicações importantes do suporte RSVP para LLQ é que ele permite que se classifique tráfego de voz com base em suas
características de tráfego em vez de se basear no protocolo de transporte (UDP) e no número da porta (16384 até 32767). A operação
adequada de LLQ depende da suposição que a fila de prioridade é utilizada apenas pela tráfego de bom comportamento (tal como
voz) que tem uma taxa previsível e um tamanho de intermitência bem baixo. A classificação com base no protocolo de transporte e
portas pode permitir que tráfego intermitente ou não-crítico entre na fila de prioridade, o que pode afetar a qualidade das chamadas
de voz existentes e o desempenho do tráfego utilizando o sistema WFQ. Você precisa considerar os efeitos de tráfego intermitente ou
não-crítico quando está definindo um perfil de fila de prioridade personalizado. Você deve entender todas as implicações em outros
tipos de tráfego, principalmente quando o perfil da PQ poderia deixar os fluxos com algum grau de intermitência na fila de
prioridade. O suporte RSVP para LLQ dá prioridade a pacotes de voz, mas não cuida da sinalização de voz. Pode não ser possível
iniciar novas chamadas durante congestionamentos intensos devido à perda de pacotes de sinalização. Nesta situação, você pode
explicitamente reservar alguma quantidade de largura de banda para sinalização de pacotes utilizando MQC. Você também pode
marcar mensagens do RSVP para tratamento especial utilizando o comando de configuração de interface ip rsvp signaling dscp.
No exemplo de configuração seguinte, os pacotes de voz são priorizados utilizando o RSVP e a sinalização tem garantida uma
largura de banda mínima durante períodos de congestionamento por meio do MQC:
Exemplo de Configuração 14: Suporte de RSVP para LLQ + QoS para Sinalização de Tráfego
hostname LongBay
!
class-map h323
match access-group 101
!
policy-map VOIP_SIG
class h323
set ip dscp 34
bandwidth 96
class class-default
fair-queue
!
isdn switch-type primary-ni
call rsvp-sync
!
controller T1 1/0
framing esf
linecode b8zs
pri-group timeslots 1-24
!
interface Ethernet0/0
ip address 10.0.152.254 255.255.255.0
!
interface Serial0/0
bandwidth 1536
ip address 10.10.1.1 255.255.255.0
encapsulation ppp
ip tcp header-compression iphc-format
ip rtp header-compression iphc-format
service-policy output VOIP_SIG
ip rsvp bandwidth 1152 24
!
interface Serial1/0:23
no ip address
no logging event link-status
isdn switch-type primary-ni
isdn incoming-voice voice
no cdp enable
!
access-list 101 permit tcp any eq 1720 any
access-list 101 permit tcp any any eq 1720
!
voice-port 1/0:23
!
dial-peer voice 100 pots
destination-pattern 2......
no digit-strip
direct-inward-dial
port 1/0:23
!
dial-peer voice 300 voip
destination-pattern 3......
session target ipv4:10.77.39.129
req-qos guaranteed-delay
acc-qos guaranteed-delay
!
line con 0
line aux 0
line vty 0 4
Neste exemplo, a lista de acesso 101 corresponde ao H.323 sinalizando tráfego para e da porta TCP 1720. Este tráfego está
colocado na classe h323, com 96 kbps de largura de banda garantida utilizando LLQ. A carga de voz tem prioridade utilizando a
configuração RSVP.
VoIP QoS sobre Linhas Alugadas (Utilizando PPP)
Esta seção descreve como configurar VoIP em uma rede típica onde ligações WAN de baixa velocidade são utilizadas para
transportar tráfego de voz e dados. Inclui as seguintes subseções:
Cenário VoIP sobre Linha Alugada (Utilizando PPP)
Solução Recomendada para VoIP sobre Linha Alugada (Utilizando PPP)
Cenário VoIP sobre Linha Alugada (Utilizando PPP)
Um aplicativo de VoIP típico é para uma grande corporação utilizar sua infraestrutura WAN existente para tráfego de dados com a
finalidade de transportar chamadas de voz entre seu escritório central e suas filiais. A Figura 9 mostra um ambiente de rede VoIP
típico onde ligações WAN de baixa velocidade estão sendo usadas para transportar tráfego de voz e dados.
Figura 9: Ambiente de Rede VoIP Típico
Para ligações WAN de baixa velocidade que não estão bem preparadas para servir tráfego de voz, problemas tais como atraso,
variação de sinal e perda se tornam ainda mais pronunciados. Neste ambiente de rede em particular, os seguintes fatores podem
contribuir para qualidade de voz deficiente:
Pacotes de dados grandes enviados antes de pacotes de voz introduzem longos atrasos.
Pacotes de dados de comprimento variável enviados antes de pacotes de voz tornam os atrasos imprevisíveis, resultando em
efeito variação de sinal.
Largura de banda estreita faz o RTP combinado de 40 bytes, UDP e cabeçalho de IP de um pacote VoIP de 20 bytes
especialmente desperdiçador.
Largura de banda estreita causa sério atraso e perda porque a ligação está freqüentemente congestionada.
Muitas técnicas populares de QoS que atendem o tráfego de dados muito bem, tais como WFQ e RED, são ineficazes para
aplicativos de voz:
Se você aplica WFQ para voz e dados, conforme o número de aplicativos de dados e voz aumentar ao longo da ligação,
o WFQ baseado em fluxo alocará menos e menos largura de banda para cada fluxo. Ao contrário do tráfego de dados
elástico que se adapta a largura de banda disponível, a qualidade da voz se torna inaceitável após muitas quedas e muito
atraso.
RED é especificamente projetada para tráfego TCP. O VoIP fica na parte superior do UDP. Portanto, sempre que
possível, tráfego de voz e de dados devem ser classificados em categorias separadas e a RED deve ser aplicada a dados,
mas não a voz.
Além disso, cada ligação e equipamento no caminho VoIP adiciona atraso à transmissão de pacotes de voz. A possibilidade de perda
de pacotes de voz também aumenta conforme o tráfego de voz é viaja uma distância maior e por mais nós na rede. As conexões de
baixa velocidade WAN geralmente são as ligação mais fracas.
Solução Recomendada para VoIP sobre Linha Alugada (Utilizando PPP)
Em condições normais, o equipamento de rede e as estações finais não podem diferenciar as exigências dos pacotes de voz em tempo
real e o tráfego de dados padrão. Isto poderia resultar em séria degradação do discurso. Para garantir qualidade de voz, você deve
classificar tráfego de dados e de voz em categorias diferentes e priorizar tráfego de voz manipulado através de um backbone de rede
de dados compartilhado. Dar prioridade à manipulação de tráfego de voz minimiza atrasos e quedas sempre que possível,
proporcionando desempenho de transmissão previsível ao tráfego de voz. Para ligações PPP, recomendamos os seguintes recursos
QoS:
Classificação de pacote por meio de MQC
Marcação com base em classe (na extremidade DS)
Manipulação de prioridade por meio de LLQ
CRTP—Necessário apenas em ligações de baixa velocidade com um número baixo de chamadas para otimização da largura de
banda
MP LFI—Necessário apenas em ligações de baixa velocidade (abaixo de 1,2 Mbps) para garantir que o tempo de transmissão
de um fragmento seja menor que 10 ms
O seguinte exemplo de configuração mostra uma configuração completa com todos os recursos de QoS listados:
Exemplo de Configuração 15: QoS para VoIP sobre Ligações WAN PPP
Comandos
Descrição
class-map voip
Crie a classe voip para tráfego de voz que tenha sido marcado com
Precedência de IP 5 utilizando um dos métodos de marcação disponíveis.
match ip precedence 5
!
class-map webtraffic
match ip precedence 3
!
policy-map llq
class voip
priority 64
class webtraffic
bandwidth 64
class class-default
fair-queue
!
interface Serial1/0
bandwidth 256
encapsulation ppp
no fair-queue
ppp multilink
multilink-group 1
!
interface Multilink1
Crie a classe webtraffic para tráfego na web que tenha sido marcado com
Precedência de IP 3 utilizando um dos métodos de marcação disponíveis.
Define o llq do mapa de política QoS: tráfego de classe voip tem
prioridade e é limitado para 64 kbps durante congestionamento; pacotes de
classe webtraffic são garantidos em 64 kbps. Todos os outros tráfegos
compartilham a largura de banda restante.
Anexa a interface serial 1/0 à interface multilink no grupo 1. (Para larguras
de banda acima de 1,2 Mbps, o Multilink PPP LFI e cRTP não são
necessários. Neste caso, o endereço IP e a declaração da política de serviço
passaria por configuração de interface serial.)
Configura o Multilink PPP LFI para ligações menores que 1,2 Mbps.
ip address 10.1.1.1 255.255.255.252
bandwidth 256
!
ip rtp header-compression iphc-format
ip tcp header-compression iphc-format
!
ppp multilink
Configura o cRTP para reduzir os requisitos de largura de banda para cada
chamada de voz.
Habilita um tamanho de fragmentação de 10 ms.
ppp multilink fragment-delay 10
ppp multilink interleave
Habilita intercalação de pacote e fragmentação.
multilink-group 1
Anexa a interface multilink ao grupo 1. Anexa a política QoS llq ao tráfego
de saída na interface multilink.
service-policy output llq
!
Neste exemplo, o Multilink PPP LFI evita que pacotes VoIP sejam atrasados atrás de pacotes de dados grandes, o cRTP reduz os
requerimentos de largura de banda VoIP e LLQ proporciona prioridade ao tráfego de VoIP e garante largura de banda para outra
classe. Você precisa configurar estes recursos em ambas as extremidades da ligação PPP. O Multilink PPP LFI é necessário
apenas para ligações menores que 1,2 Mbps e o cRTP é recomendado apenas para ligações com um número baixo de chamadas
VoIP e se a CPU não estiver com grande volume de utilização.
VoIP QoS sobre Redes de Frame Relay
Esta seção descreve como configurar VoIP em uma rede típica onde as ligações WAN de Frame Relay são usadas para transportar
tráfego de voz. Inclui as seguintes subseções:
VoIP QoS sobre Cenário de Frame Relay
VoIP QoS sobre Solução Recomendada de Frame Relay
VoIP QoS sobre Cenário de Frame Relay
Um aplicativo VoIP típico é para uma grande corporação utilizar sua infraestrutura de tráfego de dados WAN Frame Relay para
transportar chamadas de voz entre seu escritório central e suas filiais. Há duas opções aqui: transportar a voz e os dados em PVCs
separados ou utilizar o mesmo PVC para tráfego de voz e dados. No primeiro cenário, você ainda deve dar prioridade ao tráfego de
voz utilizando uma técnica tal como a PVC Interface Priority Queue (PIPQ). PIPQ permite que você atribua prioridades diferentes
para PVCs—alta, média, normal ou baixa. PIPQ também permite que PVCs sejam enfileirados na interface física principal para que
o tráfego de alta prioridade esteja antes dos tráfegos de prioridade média, normal e baixa. PIPQ, contudo, tem o mesmo problema
que o enfileiramento de prioridade—o tráfego de alta prioridade pode deixar outro tráfego sem largura de banda. Entretanto, se você
usar a modelagem de tráfego de Frame Relay corretamente, você pode minimizar este problema porque cada PVC terá uma taxa de
transmissão definida.
No cenário mais comum, utiliza-se um único PVC para transportar todo o tráfego entre os locais, conforme mostrado na Figura 10.
Figura 10: VoIP QoS sobre Ligações de Frame Relay de Baixa Velocidade
VoIP QoS sobre Solução Recomendada de Frame Relay
Você precisa configurar a modelagem de tráfego de Frame Relay para garantir que incompatibilidades de velocidade nos locais
remoto e na instalação de hub sejam tratadas corretamente. Por exemplo, se a instalação de hub tem uma conexão T1 na rede de
Frame Relay e o local remoto tem uma velocidade de acesso de 128 kbps, o site do hub tem a capacidade de enviar com velocidades
T1 em direção a este único remoto. Os switches de Frame Relay reduzirão o buffer deste tráfego, mas em seguida arbitrariamente
descartarão qualquer coisa acima de 128 kbps. Você precisa decidir o que deve ser descartado e o que deve ser priorizado nos pontos
finais do PVC.
A modelagem de tráfego de Frame Relay permite aos routers enviarem tráfego para a rede de Frame Relay abaixo de uma taxa préconfigurada. Qualquer tráfego acima desta taxa é enfileirado e um algoritmo de enfileiramento tal como o LLQ pode ser utilizado
para tomar decisões inteligentes de acordo com as quais os pacotes devem ser enviados. Se a filas forem preenchidas, os pacotes
simplesmente serão descartados. Contudo, se o VoIP for priorizado e o tráfego VoIP total estiver abaixo da taxa de modelagem do
tráfego, os pacotes VoIP serão atendidos com latência baixa e não serão descartados.
Para ligações de velocidade menores, abaixo de 1,2 Mbps, você precisa configurar a fragmentação de pacote para garantir que o
pacote VoIP não precisará esperar atrás de um pacote grande. A fragmentação de pacotes de dados grandes para 10 ms da velocidade
da ligação pode vincular o período de espera máximo. Você pode utilizar o cRTP para utilização eficaz da largura de banda se o
número de chamadas não for grande demais.
Para fornecer alta qualidade para o VoIP sobre Frame Relay, você precisa configurar os seguintes recursos:
Modelagem de tráfego de Frame Relay:
Defina o comando de configuração de classe de mapa frame-relay cir para a taxa de transmissão máxima (deve ser a
taxa garantida negociada com o provedor do serviço).
Desabilite o comando de configuração de classe de mapa frame-relay adaptive-shaping e configure o valor de
comando mincir para corresponder ao valor de comando cir para melhor qualidade de voz.
Defina o comando de configuração de classe de mapa frame-relay bc para 1/100 da CIR para permitir que a modelagem
de tráfego atenda pacotes pelo menos a cada 10 ms.
FRF.12 LFI—Você precisa de LFI apenas se a a velocidade da porta final remota ou hub for menor que 1,2 Mbps; o tamanho
da fragmentação deve ser 10 ms ou 80 bytes multiplicados pelo número de DS0s (por exemplo, para 4x64k, o tamanho da
fragmentação deve ser 4x80 = 320 bytes)
LLQ em PVC de Frame Relay—o LLQ é aplicado sob a classe de mapa para modelagem de tráfego de Frame Relay.
cRTP—o cRTP é aplicado sob a subinterface de Frame Relay; você deve utilizar cRTP somente se a utilização da CPU estiver
baixa e para um número pequeno de chamadas, dependendo da plataforma.
O seguinte exemplo de configuração mostra como habilitar os recursos QoS descritos na seção anterior:
Exemplo de Configuração 16: QoS para VoIP sobre Ligações WAN de Frame Relay
Comandos
Descrição
class-map voip
Crie a classe voip para tráfego de voz que tenha sido marcado com
Precedência de IP 5 utilizando um dos métodos de marcação
disponíveis.
match ip precedence 5
!
class-map webtraffic
match ip precedence 3
!
policy-map llq
class voip
priority 64
class webtraffic
bandwidth 64
class class-default
fair-queue
!
interface Serial 0/1
no ip address
encapsulation frame-relay
frame-relay traffic shaping
!
interface Serial 0/1.64 point-to-point
ip address 10.14.96.2 255.255.255.252
frame-relay interface-dlci 128
class voice
frame-relay ip rtp header-compression
!
map-class frame-relay voice
no frame-relay adaptive-shaping
Crie a classe webtraffic para tráfego na web que tenha sido marcado
com Precedência de IP 3 utilizando um dos métodos de marcação
disponíveis.
Define o llq do mapa de política QoS: tráfego de classe voip tem
prioridade e é limitado para 64 kbps durante congestionamento; pacotes
de classe webtraffic são garantidos em 64 kbps. Todos os outros tráfegos
compartilham a largura de banda restante.
Configurando a modelagem de tráfego do Frame Relay. Você deve
habilitar a modelagem de tráfego do Frame Relay para manipular
incompatibilidades de velocidade e excesso de assinaturas. (LLQ por
PVC de Frame Relay também requer modelagem de tráfego de Frame
Relay.)
Anexa a classe de modelagem de tráfego voice a este PVC de Frame
Relay.
Configura o cRTP para reduzir os requerimentos de largura de banda de
cada chamada de voz.
Desabilita a modelagem adaptável. Não recomendamos modelagem
adaptável para VoIP.
frame-relay cir 256000
Define a CIR ou a taxa de transmissão superior em 256 kbps.
frame-relay bc 2560
Define a taxa de intermitência comprometida para 1/100 da CIR.
frame-relay mincir 256000
Define a taxa de CIR mínima aceitável. O valor mincir precisa ser maior
que a prioridade total e a largura de banda alocada.
frame-relay fragment 320
Habilita fragmentação FRF.12 com um tamanho de fragmento de
320 bytes.
service-policy output llq!
Anexa a política QoS llq à classe de mapa definida.
Neste exemplo, a modelagem de tráfego de Frame Relay manipula incompatibilidades de velocidade, a fragmentação FRF.12
evita que pacotes VoIP sejam atrasados vindo atrás de pacotes de dados grandes, o cRTP reduz os requerimentos de largura de
banda de VoIP e o LLQ fornece prioridade para tráfego VoIP e garante largura de banda para outra classe. Você precisa
configurar estes recursos em ambas as extrermidades da ligação de Frame Relay. O FRF.12 é necessário apenas para ligações
menores que 1,2 Mbps e o cRTP é recomendado apenas em ligações com um baixo número de chamadas VoIP e se a CPU não
estiver com grande volume de execução.
VoIP QoS sobre ATM
Esta seção descreve como configurar QoS VoIP sobre ATM e inclui as seguintes subseções:
VoIP QoS sobre Cenário ATM
VoIP QoS sobre Soluções ATM Utilizando ATM PVCs Separados para Dados e Voz
VoIP QoS sobre Soluções ATM Utilizando ATM PVCs Compartilhados para Dados e Voz
VoIP QoS sobre Cenário ATM
A tecnologia ATM tem vantagens inerentes na manipulação de tráfego VoIP por causa de suas células com tamanho fixo e pequeno
e seus mecanismos de classe de serviço (CoS). Estas vantagens não garantem, contudo, que o tráfego VoIP irá obter
automaticamente o QoS que precisa da rede ATM que o transporta. O tráfego VoIP não irá obter automaticamente o QoS que precisa
porque as definições de QoS na camada IP, tais como as configurações de Precedência de IP no cabeçalho do pacote, não
correspondem automaticamente às configurações de ATM CoS, isto é, classe de tráfego (CBR (Constant Bit Rate), VBR (Variable
Bit Rate), ABR (Available Bit Rate), UBR (Undefined Bit Rate)) e parâmetros de tráfego tais como SCR (Sustainable Cell Rate),
PCR (Peak Cell Rate) e tamanho de intermitência. Conseqüentemente, depois que os pacotes de dados e voz são identificados e
classificados na camada IP, o operador da rede deve configurar manualmente os VCs (virtual circuits) ATM para garantir QoS para
os pacotes de voz ao longo da rede ATM. Este provisionamento manual é demorado, trabalhoso, suscetível a erros e, acima de tudo,
não tem escalabilidade conforme uma quantidade maior de tráfego de voz é introduzido na rede.
A Figura 11 mostra um exemplo de VoIP QoS configurado para suportar ATM.
Figura 11: VoIP QoS sobre Ligações ATM
Duas soluções estão disponíveis para fornecer QoS para VoIP sobre uma rede ATM: uma utilizando VCs de dados e voz separados e
um utilizando VCs de dados e voz compartilhados.
VoIP QoS sobre Soluções ATM Utilizando ATM PVCs Separados para Dados e Voz
Para tráfego de dados e voz compartilhando o mesmo destino, mas exigindo QoS diferentes, você precisa definir grupos de VCs
ATM para formar pacotes PVC. Em um pacote PVC, todos os PVCs compartilham a mesma origem e destino e cada pacote está
designado para transportar tráfego de IP com um nível ou intervalo de níveis de Precedência de IP. Após configurar os pacotes de
PVC, configure cada PVC com seus parâmetros de ATM QoS específicos. Como tráfego de voz e dados com níveis diferentes de
Precedência de IP chegam na interface ATM do router, o software Cisco IOS o envia ao PVC apropriado, mapeando eficazmente
classes de QoS de IP para ATM CoSs.
As principais vantagens de implementar o VoIP QoS utilizando este método são as seguintes:
Separação automática de tráfego de voz e dados em PVCs diferentes.
Preservação dos serviços diferenciados da rede IP por meio da rede ATM.
O seguinte exemplo de configuração mostra como configurar VoIP sobre ATM utilizando pacotes PVC para separar PVCs de voz e
dados:
Exemplo de Configuração 17: QoS para VoIP sobre ATM com PVCs de Voz e Dados Separados
Comandos
Descrição
ip cef
Habilita a comutação do IP Cisco Express Forwarding (CEF). Você
deve ativar a comutação CEF de IP para essa solução funcionar.
!
interface ATM 2/0/0
Cria um grupo de pacote PVC chamado qosmap.
no ip address
!
interface ATM 2/0/0.1 point-to-point
ip address 10.1.1.2 255.255.255.252
bundle qosmap
protocol ip 10.1.1.1 broadcast
Mapeia o tráfego de Precedência de IP 6 e 7 para um VPI (virtual path
identifier) ou VCI (virtual channel identifier) de 1/100.
pvc-bundle control 1/100
precedence 6-7
pvc-bundle voice 1/101
Mapeia tráfego de Precedência de IP 5 (VoIP) para um VPI ou VCI
de 1/101 com uma SCR de 5 Mbps e alguns recursos de intermitência.
vbr-rt 6000 5000 1000
precedence 5
pvc-bundle web 1/102
Mapeia Tráfego de Precedência 4 para 1/102 com uma SCR de 5
Mbps.
cbr 5000
precedence 4
pvc-bundle data 1/103
Mapeia tráfego de outra precedência para um PVC com um VPI ou
VCI de 1/103.
precedence 0-3
Neste exemplo, quatro classes de tráfego com base na Precedência de IP são mapeadas em quatro PVCs ATM em um pacote. O
PVC de voz tem uma largura de banda garantida de 5 Mbps com alguns recursos de intermitência e o PVC de tráfego da Web
também é garantido em 5 Mbps, mas sem intermitência (CBR). O tráfego de controle e todos os outros fluxos de tráfego não tem
qualquer garantia de taxa de ATM.
VoIP QoS sobre Soluções ATM Utilizando ATM PVCs Compartilhados para Dados e Voz
Caso decida utilizar PVCs separados para voz e dados, deve ajustar a alocação de largura de banda conforme o tráfego aumentar
além da largura de banda configurada no PVC de voz. Este reprovisionamento manual não é necessário quando voz e dados
compartilham o mesmo PVC, desde que a voz sempre receba a prioridade que precisa. Você pode configurar tráfego VoIP para ter
prioridade absoluta sobre tráfego de dados configurando LLQ no PVC ATM.
O seguinte exemplo de configuração mostra como configurar VoIP sobre ATM utilizando o mesmo PVC para tráfego de voz e
dados:
Exemplo de Configuração 18: QoS para VoIP sobre ATM utilizando um PVC de Voz e Dados Compartilhado
Comandos
Descrição
ip cef
Habilita comutação de IP CEF. Você deve ativar a comutação CEF de IP para
essa solução funcionar.
!
class-map voip
match ip precedence 5
Cria classe voip para tráfego de voz que foi marcado com Precedência de IP 5
utilizando um dos métodos de marcação disponíveis.
!
class-map webtraffic
match ip precedence 3
!
policy-map llq
class voip
priority 1000
class webtraffic
bandwidth 1000
class class-default
fair-queue
!
interface ATM2/0/0
Cria classe webtraffic para tráfego da Web que foi marcado com Precedência
de IP 3 utilizando um dos métodos de marcação disponíveis.
Define o mapa de política llq, que define a política QoS: tráfego de classe voip
tem prioridade e é limitado para 1 Mbps durante congestionamento; pacotes de
classe webtraffic tem 1 Mbps garantido. Todos os outros tráfegos
compartilham a largura de banda restante.
Configura parâmetros de modelagem ATM.
no ip address
!
interface ATM2/0/0.1 point-to-point
ip address 10.1.1.2 255.255.255.252
pvc data+voice 1/101
vbr-rt 6000 5000 1000
encapsulation aal5snap!
service-policy output llq
Anexa o mapa de política de llq ao PVC ATM.
!
Neste exemplo, o LLQ é utilizado em um único PVC ATM transportando VoIP e dados. A política LLQ é aplicada em uma
subinterface ATM para um PVC. O tráfego de classe voip tem prioridade até 1 Mbps e a classe webtraffic tem garantia de
1 Mbps, mas não tem tratamento de prioridade. A modelagem de ATM também garante que o PVC tenha uma taxa sustentada de
5 Mbps.
Documentação Relacionada
Guia de Configuração de Soluções para Qualidade de Serviço do Cisco IOS, Versão 12.1
http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_configuration_guide_book09186a008007ff1d.html
Referências a Comandos de Soluções para Qualidade de Serviço do Cisco IOS, Versão 12.1
http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_command_reference_book09186a00800807a7.html
Guia de Configuração de Aplicativos Multiserviço do Cisco IOS, Versão 12.1
http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_configuration_guide_book09186a008008739c.html
Referência de Comando de Aplicativos Multiserviço do Cisco IOS, Versão 12.1
http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_command_reference_book09186a0080087c1a.html
Módulo de recurso COPS para RSVP do Cisco IOS Versão 12.1(1)T
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t1/
copsrsvp.htm
Módulo de recurso Marcação de Pacotes com Base em Classe do Cisco IOS Versão 12.1(2)T
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/cbpmark.htm
Módulo de recurso Modelagem com Base em Classe do Cisco IOS Versão 12.1(2)T
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/
clsbsshp.htm
Módulo de recurso Melhorias na Compatibilidade de Compactação de Cabeçalho do Frame Relay do Cisco IOS Versão
12.1(2)T
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/
dtfrhccc.htm
Módulo de recurso Enfileiramento de Latência Baixa para Frame Relay do Cisco IOS Versão 12.1(2)T
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t2/
dtfrpqfq.htm
Módulo de recurso Configurando Tamanho da Intermitência em Enfileiramento de Latência Baixa do Cisco IOS Versão
12.1(3)T
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/
dtcfgbst.htm
Módulo de recurso Suporte RSVP para Enfileiramento de Latência Baixa do Cisco IOS Versão 12.1(3)T
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/
rsvp_llq.htm
Módulo de recurso Marcação com Base em Classe do Cisco IOS Versão 12.1(5)T
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/
cbpmark2.htm
Módulo de recurso Enfileiramento Considerado Ponderado com Base em Classe Distribuída e Detecção Antecipada Aleatória
Ponderada Distribuída do Cisco IOS Versão 12.1(5)T
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/
dtcbwred.htm
Módulo de recurso Protocolo de Tempo Real Compactado Distribuído do Cisco IOS Versão 12.1(5)T
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/
dtdcrtp.htm
Módulo de recurso Enfileiramento de Latência Baixa Distribuído do Cisco IOS Versão 12.1(5)T
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/
dtllqvip.htm
Módulo de recurso Modelagem de Tráfego Distribuído do Cisco IOS Versão 12.1(5)T
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/
dtdts.htm
Módulo de recurso Implementando DiffServ para Qualidade de Serviço Ponta a Ponta do Cisco IOS Versão 12.1(5)T
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/
dtdfsv.htm
Módulo de recurso Fragmentação de Ligações e Intercalação para Frame Relay e Circuitos Virtuais ATM do Cisco IOS
Versão 12.1 (5)T
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/
dtlfifra.htm
Módulo de recurso Vigilância de Tráfego do Cisco IOS Versão 12.1(5)T
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/
dtpoli.htm
Módulo de recurso Controle de Admissão de Chamada VoIP Utilizando RSVP do Cisco IOS Versão 12.1(5)T
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t5/
dt4trsvp.htm
© 1992-2014 Cisco Systems Inc. Todos os direitos reservados.
Data da Geração do PDF: 3 Setembro 2008
http://www.cisco.com/cisco/web/support/BR/10/107/107770_tech_tk652_tk698_technologies_white_paper09186a00800d6b73.html