Voz : Qualidade de voz

Qualidade de serviço de voz sobre IP

3 Setembro 2008 - Tradução Manual
Outras Versões: Versão em PDFpdf | Inglês (13 Abril 2001) | Feedback

Índice

Qualidade de serviço de voz sobre IP
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

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

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

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

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 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.

Configuração simples. Padrão em ligações com menos de 2 Mbps.

Não é possível garantir serviço de 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 PQ-CBWFQ)

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

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-to-Point 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-relay 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

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)

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

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 voice-like 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)

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

 match ip precedence 5
!

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.

class-map webtraffic

 match ip precedence 3
!

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.

policy-map llq

 class voip
  priority 64
 class webtraffic
  bandwidth 64
 class class-default
  fair-queue
!

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.

interface Serial1/0

 bandwidth 256
 encapsulation ppp
 no fair-queue
 ppp multilink
 multilink-group 1
!

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.)

interface Multilink1

 ip address 10.1.1.1 255.255.255.252
 bandwidth 256
!

Configura o Multilink PPP LFI para ligações menores que 1,2 Mbps.

ip rtp header-compression iphc-format

ip tcp header-compression iphc-format
!

Configura o cRTP para reduzir os requisitos de largura de banda para cada chamada de voz.

ppp multilink

 ppp multilink fragment-delay 10

Habilita um tamanho de fragmentação de 10 ms.

 ppp multilink interleave

Habilita intercalação de pacote e fragmentação.

 multilink-group 1

 service-policy output llq
!

Anexa a interface multilink ao grupo 1. Anexa a política QoS llq ao tráfego de saída na interface multilink.

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

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

 match ip precedence 5
!

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.

class-map webtraffic

 match ip precedence 3
!

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.

policy-map llq

 class voip
  priority 64
 class webtraffic
  bandwidth 64
 class class-default
  fair-queue
!

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.

interface Serial 0/1

 no ip address
 encapsulation frame-relay
 frame-relay traffic shaping
!

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.)

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

Anexa a classe de modelagem de tráfego voice a este PVC de Frame Relay.

  frame-relay ip rtp header-compression

!

Configura o cRTP para reduzir os requerimentos de largura de banda de cada chamada de voz.

map-class frame-relay voice

 no frame-relay adaptive-shaping

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

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

 no ip address
!
interface ATM 2/0/0.1 point-to-point
 ip address 10.1.1.2 255.255.255.252
 bundle qosmap

Cria um grupo de pacote PVC chamado qosmap.

protocol ip 10.1.1.1 broadcast

 pvc-bundle control 1/100
 precedence 6-7

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 voice 1/101

 vbr-rt 6000 5000 1000
 precedence 5

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.

pvc-bundle web 1/102

 cbr 5000
 precedence 4

Mapeia Tráfego de Precedência 4 para 1/102 com uma SCR de 5 Mbps.

pvc-bundle data 1/103

 precedence 0-3

Mapeia tráfego de outra precedência para um PVC com um VPI ou VCI de 1/103.

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
!

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.

policy-map llq

 class voip
  priority 1000
 class webtraffic
  bandwidth 1000
 class class-default
  fair-queue
!

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.

interface ATM2/0/0

 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!

Configura parâmetros de modelagem ATM.

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