Qualidade de Serviço em VoIP - Parte 2

Adailton J. S. Silva <adailton@rnp.br>

Centro de Engenharia e Operações (CEO)
Rede Nacional de Ensino e Pesquisa (RNP)

Resumo
1. Introdução
2. QoS - Modelo básico
3. Eficiência em conexões
3.1 Compressão RTP
3.2 Fragmentação e interleaving
4. Moldagem e policiamento de tráfego
4.1 Moldagem genérica
4.2 Policiamento
4.3 Moldagem Frame Relay
5. QoS em redes locais
6. Conclusão
7. Sites relacionados
Referências bibliográficas

Resumo

Originalmente, o protocolo IP não previa nenhum mecanismo de qualidade de serviços e, conseqüentemente, nenhuma garantia de alocação de recursos da rede. Com o rápido crescimento da Internet, a tendência atual é a integração de voz (telefonia) e dados numa única infra-estrutura de redes de pacotes, a rede IP. Essa emergente e crecente demanda pelos serviços de telefonia sobre IP, provocou uma corrida dos fabricantes de equipamentos de redes para desenvolver protocolos que garantissem qualidade de serviços fim-a-fim. É sobre essa parafernália de protocolos, técnicas e mecanismos que continuamos falando neste artigo.

Onde paramos? Este artigo, como indica o título, é continuação do artigo Qualidade de Serviço em VoIP - Parte 1 . Para o leitor que ainda não leu a primeira parte do mesmo, fica o convite para que o faça, pois de nada adianta ler este sem o prévio conhecimento do anterior.

^

1. Introdução

Este artigo trata, especificamente, de mecanismos de garantia de qualidade de serviços fim-a-fim para voz sobre IP (VoIP) ou IP Telephony, mas também podem servir para outros tipos de tráfego, como vídeo por exemplo.

Todos os protocolos aqui apresentados já podem ser utilizados em projetos reais, estando todos disponíveis nos principais equipamentos Cisco, plataforma básica para os exemplos utilizados neste e nos próximos artigos. Alguns protocolos também estão presentes em plataformas de outros fabricantes como Motorola, Nortel e Lucent.

Neste artigo, são abordados mecanismos para melhorar a eficiência de conexões (link efficiency), como o CRTP (Compressed Real-time Transport Protocol), LFI (Link Fragmentation and Interleaving), Multilink PPP e FRF (Frame Relay Fragmentation); para moldagem e policiamento de tráfego, com GTS (Generic Traffic Shaping), CAR (Commited Access Rate) e FRTS (Frame Relay Traffic Shaping); e qualidade de serviço em LANs, com o protocolo IEEE 802.1p (Priotrity Queueing).

^

2. QoS - Modelo básico

O modelo básico, apresentado em [1], continua valendo como referência para os exemplos. Como mostra o modelo da Figura 1, o principal objetivo da qualidade de serviços é priorizar o tráfego interativo sensível a retardo, em detrimento ao tráfego referente à transferência de arquivos, que não é sensível a retardo.

Figura 1 - Modelo para QoS

A qualidade de serviço deve ser fim-a-fim, ou seja, considerando o modelo acima, o tráfego tem que ser tratado inicialmente na rede local (LAN) de origem, depois no próprio roteador (controle de descarte de pacotes, por exemplo), em seguida, nas conexões de longa distância (WAN) e roteadores intermediários, no roteador destino, e, finalmente, na rede local destino. Este será o modelo básico utilizado como referência nos itens a seguir.

^

3. Eficiência em conexões

Obter a melhor eficiência nas conexões com voz sobre IP significa, neste caso, fazer um melhor uso da banda com os protocolos associados às aplicações de voz, com uma boa qualidade. Atrav´s de protocolos de compressão de dados, pode-se obter uma maior economia de banda e, com tecnologias para fragmentação e interleaving, obtém-se uma melhor qualidade do sinal de voz. Os protocolos descritos a seguir realizam tais funções.

^

3.1 Compressão RTP

O protocolo CRTP (Compressed Real-time Transport Protocol) comprime o cabeçalho do pacote RTP ¹ , que transporta o tráfego de voz. A Figura 2 mostra formação de um pacote RTP. O campo de dados (payload) de um pacote IP de voz é composto pelo pacote RTP, que transporta o sinal de voz propriamente dito, encapsulado num pacote UDP.

Figura 2 - Encapsulamento de pacote VoIP

O tamanho do cabeçalho RTP é de 12 bytes, o do UDP de 8 bytes e do IP de 20 bytes, totalizando 40 bytes. Considerando o payload IP de 20 bytes, só de cabeçalho teríamos 66,66% da banda da conexão.

Aí é que entra o protocolo CRTP, que, na maior parte do tempo, consegue uma compressão de cabeçalho de 40 para 2 bytes, ou para 4 se considerarmos o checksum UDP. Essa compressão corresponde a uma redução de até 95% na sobrecarga (overhead) referente aos cabeçalhos.

A operação CRTP é simples, como apresenta a Figura 3. O tráfego total destinado a uma determinada interface é classificado, e o que for RTP é separado para compressão. O tráfego RTP é, então, processado num compressor e colocado novamente na fila para ser trasmitido.

Figura 3 - Compressão de cabeçalho RTP

Nos gateways VoIP Cisco, essa compressão é habilitada na interface serial, como mostrado no exemplo abaixo:

interface serial2/1

ip rtp header-compression

encapsulation ppp

ip rtp compression-connections 25

A compressão CRTP é bastante útil em conexões de baixa velocidade (64 Kbps, p. ex.), mas também possui desvantagens. Se for habilitada compressão RTP, o roteador só funcionará em process switch em vez de fast switch, o que, combinado com a sobrecarga da execução CRTP, pode causar queda de desempenho do mesmo. Portanto, o uso do CRTP não é sugerido em enlaces de alta velocidade, uma vez que a relação custo versus benefício pode não compensar.

¹  - O protocolo RTP (Real-time Transport Protocol) será apresentado no próximo artigo sobre Telefonia IP.

^

3.2 Fragmentação e interleaving

No modelo apresentado na Figura 1, considere a existência de uma sessão FTP entre os dois pontos. Se, no momento da chegada de um pacote de voz, o roteador estiver processando um grande pacote FTP, o sinal de voz para o receptor chegará com pausas e, subjetivamente, soará como soluços. Se as pausas forem demoradas, o sinal pode até perder a inteligibilidade. Isso acontece, principalmente, em conexões com grande MTU (Maximum Transmission Unit). Essa situação é bastante inadequada para tráfego sensível a retardo.

Figura 4 - Fragmentação e interleaving

As técnicas de fragmentação e interleaving, ou LFI (Link Fragmentation and Interleaving), amenizam esse problema (ver Figura 4). A fragmentação consiste em quebrar, ou fragmentar, grandes datagramas ("jumbogramas") em partes menores. Já as técnicas de interleaving intercalam os pacotes menores, incluindos os de voz, entre os "pedaços" do "jumbograma" para posterior transmissão. Essas técnicas são bastantes úteis em enlaces de baixa velocidade, reduzindo o atraso e a variação deste, o chamdo jitter. Há duas implementações que são apresentadas a seguir: MPPP (Multilink PPP) e FRF.12 (Frame Relay Fragmentation 12) do Frame Relay Forum.

Multilink PPP

A ativação LFI requer a configuração do MPPP com interleaving e encapsulamento PPP, permitindo que grandes pacotes sejam fragmentados para satisfazer os requisitos de retardo do tráfego de voz. Os pacotes menores, que não são encapsulados no multilink, são transmitidos entre os fragmentos dos pacotes maiores. Ao se ativar a funcionalidade para interleaving, uma fila especial é alocada para o tráfego sensível a retardo, provendo uma certa priorização.

A IETF publicou a Internet draft MCML (Multiclass Extensions to Multilink PPP), que provê quase todas as funcionalidades LFI. Nos roteadores Cisco, o MPPP é ativado através de um template de interface virtual. Assim, um exemplo de configuração seria:

interface virtual-template 1

ppp multilink

encapsulated ppp

ppp multlink interleave

ppp multilink fragment-delay 20

ip rtp reserve 16384 100

A configuração acima ativa o multilink com atraso máximo de 20 ms entre os fragmentos e reserva uma fila especial para priorização de tráfego, através do comando ip rtp reserve 16384 100, onde "16384" é o número da porta e "100" indica a faixa de portas (até 16484) para os quadros UDP a serem priorizados.

Em geral, o MPPP é utilizado em conjunto com WFQ [1] e precedência IP ou RSVP, para assegurar qualidade de serviço na transmissão do pacote. Entretanto, o seu uso não é recomendado em conexões maiores que 2 Mbps.

Especificação FRF.12

O padrão FRF.12, também conhecido como FRF.11 Annex C, provê funcinalidades para fragmentação fim-a-fim e interleaving de frames num mesmo PVC (Permanent Virtual Circuit). Sua utilização é recomendada, não nos PVCs que trafegam voz, e sim nos PVCs de dados que compartilham a mesma conexão física dos de voz.

Em voz sobre IP, os pacotes não devem ser fragmentados, mas podem ser intercalados entre os fragmentos. É importante também que o tráfego de voz sobre IP não exceda a CIR (Committed Information Rate) do PVC Frame Relay, o que pode degradar a qualidade do sinal. Para isso, pode-se utilizar o FRTS (Frame Relay Traffic Shaping). O trecho a seguir apresenta a configuração de uma interface com as condições citadas.

!

interface Serial2/0.1 point-to-point

ip unnumbered Ethernet0/0

no ip directed-broadcast

frame-relay ip rtp header-compression

frame-relay interface-dlci 100 class fr-class-voip

! [...]

map-class frame-relay fr-class-voip

frame-relay cir 64000

frame-relay bc 1000

frame-relay be 0

frame-relay mincir 64000

no frame-relay adaptive-shaping

frame-relay fair-queue

frame-relay fragment 160

frame-relay ip rtp priority 16384 16383 48

!

Quando a fragmentação é utilizada com tráfego FRF.11, que é a implementação do Frame Relay Forum para VoFR - Voz sobre Frame Relay, os dados são transmitidos no formato FRF.11 Annex C. Nesse caso, independente do tamanho, todos os pacotes de dados irão conter cabeçalho de fragmentação. Esse tipo de fragmentação não é recomendada para uso com voz sobre IP.

^

4. Moldagem e policiamento de tráfego

4.1 Moldagem genérica

Generic Traffic Shaping, ou GTS como chamada, provê mecanismos para controle de tráfego utilizando filtros conhecidos como token bucket ² , limitando o tráfego de saída de uma interface a uma determinada taxa. Como mostra a Figura 5, o tráfego classificado vai para um um buffer limitador, sendo liberado sob regras pré-definidas de acordo uma política de controle de tráfego, que pode ser configurada pelo administrador ou derivada da interface.

Figura 5 - Generic Traffic Shaping

Moldagem ou conformidade de tráfego pode ser útil em vários casos. Por exemplo, para limitar o tráfego de rajada de forma a não prejudicar o tráfego prioritário, reduzindo assim a latência; ou, em situações de congestionamento, para limitar um determinado tipo de tráfego não sensível a retardo, como transferência de arquivos, eliminando possíveis gargalos.

A moldagem GTS aplica-se apenas em interfaces de saída, com o uso de listas de acesso para classificar e selecionar o tráfego. Funciona com qualquer tecnologia de enlace (nível 2) como Frame Relay, ATM (Asyncronous Transfer Mode), SMDS (Switched Multimegabit Data Service) e Ethernet.

Algumas vezes, fui questionado sobre como limitar o tráfego FTP numa conexão serial que, em determinados intervalos, estava causando congestionamento e travando o tráfego Web. O primeiro passo é assegurar que a versão do sistema operacional IOS possua a funcionalidade para moldagem de tráfego (comando traffic-shape). Aí vai a dica, considerando como exemplo uma conexão serial de 512 Kbps e o limite para o tráfego FTP de 128 Kbps (bit-rate), 8 K de burst-size e zero de excess-burst-size:

interface serial 3/1

traffic-shape group 101 128000 8000 0

!

access-list 101 permit tcp any eq ftp any

² - token bucket é um definição formal para taxa de transferência. Possui três componentes: um tamanho de rajada em bits (burst size), também chamado de committed burst (Bc) que espefica o quanto pode ser enviado num determinado intervalo de tempo; uma taxa média (mean rate) em bps, também chamada de CIR (Committed Information Rate), que espefica o quanto de dados, na média, pode ser enviado por unidade de tempo; e um intervalo de tempo (Tc) em segundos, intervalo de medida que especifica o tempo por rajada.

^

4.2 Policiamento

O CAR (Committed Access Rate) é o método para policiamento e controle de tráfego IP que realiza, basicamente, duas funções para qualidade de serviço:

• Gerenciamento de banda com limitação de taxa de acesso (policing) - permite controlar a taxa máxima de transmisão ou recepção de dados de uma determinada interface. O tráfego conformante é transmitido ou recebido, enquanto os pacotes que excedem os limites pré-definidos, ou são descartados, ou são reclassificados com outra prioridade para retransmissão;
• Classificação de pacotes através de precedência IP ou de grupos de QoS (um rótulo interno do roteador utilizado para definição de classes - permite particionar a rede em múltiplas classes de serviços ou níveis de priorização.

Para isso, utilizando também o mecanismo token bucket, o CAR examina o tráfego recebido na interface ou parte do tráfego selecionado pelos critérios das listas de acesso, compara a taxa de tráfego com a do token bucket e, de acordo com o resultado, toma uma ou várias ações. Ou seja, pode transmitir o pacote, descartá-lo ou reclassificá-lo com outro nível de prioridade, etc.

Figura 6 - Commited Access Rate com token bucket

Os tokens são inseridos no balde na mesma taxa CIR. A profundidade do balde é o tamanho da rajada (burst size). Se houver tokens suficientes quando o tráfego chega ao balde, então o tráfego é dito estar em conformidade e a quantidade correspondente de tokens é removida. Se não houver tokens suficientes, então o tráfego é dito excessivo.

Os critérios de seleção de tráfego podem ser baseados em todo tráfego IP, em precedência IP, em listas de acesso (padrão ou estendida), em endereço MAC ou, ainda, em grupos de QoS. O endereço MAC e a precedência IP podem ser definidos através de listas de acesso rate-limit.

Com o CAR, pode-se limitar o tráfego por aplicação (Web, FTP, etc), por interface (p. ex., uma conexão serial a 2 Mbps, mas com acesso limitado em 512 Kbps), por endereço MAC (p. ex., controle de tráfego em PTT - Pontos de Troca de Tráfego), ou pode-se classificar ou reclassificar todo o tráfego de entrada num backbone a partir dos roteadores de borda, para tratamento diferenciado em termos de qualidade de serviços. A Tabela 1 abaixo apresenta as diferenças entre CAR e GTS:

Tabela 1 - Comparação entre CAR e GTS

O exemplo a seguir considera uma conexão serial T3 (45 Mbps); limita o tráfego Web (lista 101) em 20 Mbps, transmitindo o tráfego conformante com precedência IP em 5 e o tráfego excessivo com precedência 0; limita o tráfego FTP (lista 102) em 10 Mbps, transmitindo o tráfego conformante com precedência IP em 5 e descartando o tráfego excessivo;

interface Hssi0/0/0

description Conexão 45Mbps para o roteador 3

rate-limit output access-group 101 20000000 24000 32000 conform-action set- prec-transmit 5 exceed-action set-prec-transmit 0

rate-limit output access-group 102 10000000 24000 32000 conform-action set-prec-transmit 5 exceed-action drop

rate-limit output 8000000 16000 24000 conform-action set-prec-transmit 5 exceed-action drop

ip address 10.1.1.10 255.255.255.0

!

access-list 101 permit tcp any any eq www

access-list 102 permit tcp any any eq ftp

e limita todo o tráfego restante em 8 Mbps, transmitindo a parte que está em conformidade com precedência 5 e descantando todo o tráfego excessivo, sendo o normal_burst de 16.000 bytes e o extended_burst de 24.000 bytes. Há uma recomendação para cálculo desses parâmetros:

normal_burst = R * (1byte/8bits) * 1,5 segundos; onde R é a taxa configurada;

extended_burst = 2 * normal_burst.

^

4.3 Moldagem Frame Relay

Para controle e moldagem de tráfego em redes Frame Relay, utiliza-se o FRTS (Frame Relay Traffic Shaping), que oferece parâmetros úteis, como o CIR (Committed Information Rate), EIR (Excess Information Rate), FECN (Forward Explicit Congestion Notification), BECN (Backward Explicit Congestion Notification) e DE (Discard Eligible).

Com FRTS pode-se, por exemplo, limitar no CIR ou no EIR à taxa de pico do tráfego de saída em cada VC (Virtual Circuit), procedimento denominado rate enforcement. Pode-se obter uma maior granularidade no controle de tráfego, aplicando-se técnicas de enfileiramento como PQ (Priority Queueing) ou CQ (Custom Queueing) [1] em cada VC ou no nível de subinterface.

Combinando-se CQ e enfileiramento por VC com rate enforcement, pode-se habilitar o VC a acomodar vários tipos de tráfego como IP, SNA e IPX, cada um com sua própria banda garantida.

^

5. QoS em redes locais

De acordo com o modelo básico apresentado no item 1, fala-se sempre em qualidade de serviços fim-a-fim, significando o caminho completo da origem ao destino do pacote, mas as tecnologias de QoS são mais comuns para redes de longa distância como Frame Relay, ATM, PPP, HDLC, etc. E, na rede local, o que fazer para que uma aplicação de voz sobre IP, como um telefone IP por exemplo, possa ter tratamento diferenciado da rede local até a rede de longa distância e daí chegar à rede remota com a qualidade que a aplicaçao requer? A resposta está numa especificação de protocolo do IEEE denominada IEEE 802.1p priority queueing.

O 802.1p utiliza um procedimento similar ao de precedência IP [1] quando define 8 níveis de prioridade de usuários (classes de tráfego), através de um rótulo (user_priority) de 3 bits que é transmitido no frame Ethernet.

Considerando, ainda, o exemplo do telefone IP, a precedência IP setada pelo telefone é mapeada no nível de prioridade 802.1p correspondente, e o frame Ethernet segue para o switch. Se o switch for compatível com 802.1p, ele classificará os frames Ethernet priorizando os de maior classe. Esse procedimento se repete até o frame chegar ao roteador que realiza o procedimento inverso, classificando os frames Ethernet e mapeando o nível de priodade 802.1p na precedência IP correspondente. Na rede de longa distância, o pacote, já com a precedência definida, terá o tratamento de acordo com as técnicas de QoS já apresentadas. Se o switch não for compatível com 802.1p, ele simplesmente irá ignorar os rótulos e todos os frames serão transmitidos sem nenhum tratamento especial.

^

6. Conclusão

Há outros mecanismos para controle de tráfego, inibição de congestionamento e técnicas de enfileiramento para qualidade de serviços, mas a maioria é similar ou derivada das tecnologias apresentadas nesses dois artigos. Completamos, então, a apresentação dos principais métodos para obtenção de qualidade de serviços em redes IP. Nos próximos artigos, serão abordados temas específicos sobre Telefonia IP. O compromisso continua valendo. Até lá!

^

7. Sites relacionados

[IETF] Internet Engineering Task Force: http://www.ietf.org

[FRF] Frame Relay Forum: http://www.frforum.org

[CISCO] Cisco Connection Online: http://www.cisco.com/pcgi-bin/ibld/all.pl?i=support&c=2&m=GUEST (Technical Documents)

[DIFFSERV] Differentiated Services Working Group Charter: http://www.ietf.org/html.charters/diffserv-charter.htm

[INTSERV] Integrated Services Working Group Charter: http://www.ietf.org/html.charters/intserv-charter.html

[RSVP] Resource Reservation Setup Protocol Working Group Charter: http://www.ietf.org/html.charters/rsvp-charter.html

[ISSLL] Integrated Services over Specific Link Layers Working Group Charter: http://www.ietf.org/html.charters/issll-charter.html

[DIFFSINT] Differential Service in the Internet: http://diffserv.lcs.mit.edu

[IETF/RNP] Mirror Oficial IETF no Brasil: http://www.ietf.rnp.br e ftp://ftp.ietf.rnp.br

^

Referências bibliográficas

[1] Adailton Silva, Qualidade de Serviço em VoIP - Parte 1, Vol. 3, Nº. 3, RNP NewsGeneration, maio de 2000.

[2] Adailton Silva, Tecnologias de Alta Velocidade, VoIP e Internet2 - IComNet Tecnologia da Informação - Março/2000.

[3] Cisco Policing and Shaping Overview , http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/qos_c/qcpart4/qcpolts.htm

[4] Cisco - Committed Access Rate White Paper , http://www.cisco.com/warp/public/cc/pd/iosw/tech/carat_wp.htm

[5] Cisco Quality of Service (QoS) Networking http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/qos.htm

[6] Cisco Systems, Voice over IP White Paper, V1.0, Cisco Systems, 1999.

[7] Cisco Systems, Quality of Service for Voice over IP Solution Guide, V1.0, Cisco Systems, 1998.

[8] An Architecture for Differentiated Services http://www.ietf.org/rfc/rfc2475.txt ou ftp://ftp.ietf.rnp.br/rfc/rfc2475.txt

[9] Integrated Services in the Internet Architecture: an Overview http://www.ietf.org/rfc/rfc1633.txt ou ftp://ftp.ietf.rnp.br/rfc/rfc1633.txt

[10] Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers http://www.ietf.org/rfc/rfc2474.txt ou ftp://ftp.ietf.rnp.br/rfc/rfc2474.txt

[11] Resource reSerVation Protocol (RSVP) - Version 1 Functional Specification http://www.ietf.org/rfc/rfc2205.txt ou ftp://ftp.ietf.rnp.br/rfc/rfc2205.txt

[12] Integrated Service Mappings on IEEE 802 Networks http://www.ietf.org/internet-drafts/draft-ietf-issll-is802-svc-mapping-04.txt

[13] Cisco Connection Online IOS Quality of Service http://www.cisco.com/warp/customer/732/Tech/quality.shtml

[14] Cisco Systems, Cisco IOS Quality of Service Solution White Paper, 1998.

[15] Paul Ferguson, Evaluating Quality of Service: Surveying New QoS Technologies, Re-Engineering The Internet - Cisco Systems, 1998.

[16] Paul Ferguson, Quality of Service in the Internet: Fact, Fiction, or Compromise? http://www.employees.org/~ferguson/inet_qos.htm

[17] Oliver Hersent, David Gurle e Jean-Pierre petit, IP Telephony Packet-based multimedia communications systems, Pearson Education Limited, 2000.

^

NewsGeneration, um serviço oferecido pela RNP – Rede Nacional de Ensino e Pesquisa
Copyright © RNP, 1997 – 2004