Voz : Telefonia IP/Voz sobre IP (VoIP)

Controle de Admissão de Chamada VoIP

29 Agosto 2008 - Tradução Manual
Outras Versões: Versão em PDFpdf | Inglês (20 Julho 2001) | Feedback

Índice

Controle de Admissão de Chamada VoIP
Visão Geral do Controle de Admissão de Chamada
Mecanismos CAC Locais
Mecanismos CAC Baseados em Medida
Mecanismos CAC Baseados em Recurso
Como Aplicar o CAC em Sua Rede

Controle de Admissão de Chamada VoIP


Número da Versão  Data  Notas 

1.1

Julho de 2001

Este documento já foi publicado.

1.2

Ago. 2001

Pequenas mudanças.

O Call Admission Control (CAC) é um conceito aplicável apenas ao tráfego de voz, e não ao tráfego de dados. Se um fluxo de tráfego de dados esgotar uma ligação específica na rede, as decisões de enfileiramento, buffer e cancelamento de pacotes ajudam a resolver o congestionamento. O tráfego extra é simplesmente atrasado até a interface ficar disponível para enviar o tráfego ou, se for cancelado, o protocolo ou usuário final iniciam um tempo limite e solicitam uma retransmissão das informações.

O congestionamento de rede não pode ser resolvido dessa forma quando ocorre tráfego em tempo real – sensível à latência e à perda de pacotes – sem que haja prejuízo da qualidade de serviço (QoS) esperada pelos usuários do tráfego. Para o tráfego sensível a atraso em tempo real, como voz, é melhor negar o acesso à rede em condições de congestionamento do que permitir o tráfego para depois ser cancelado ou atrasado, causando QoS prejudicial intermitente e a insatisfação do cliente.

O CAC é portanto uma decisão determinística e informada, feita antes do estabelecimento de uma chamada de voz, e baseia-se na disponibilidade dos recursos de rede necessários para o fornecimento da QoS adequada para a nova chamada. O objetivo deste documento é fornecer uma visão geral do CAC, descrever os diferentes mecanismos do CAC e discutir o melhor aplicativo do CAC em redes específicas.

O público-alvo deste documento são usuários Cisco nível 3 (com competência), nível 4 (com proficiência) e nível 5 (especialistas). Este documento dirige-se principalmente a administradores de rede e equipes de operação trabalhando para provedores de serviços VoIP. Este documento contém as seguintes seções:

Visão Geral do Controle de Admissão de Chamada

O software Cisco IOS apresenta uma variedade de mecanismos de QoS diferentes do CAC para criar e configurar redes de pacote e fornecer a baixa latência e garantia de entrega necessárias para o tráfego de voz. Esses mecanismos de QoS incluem ferramentas como enfileiramento, vigilância, modelagem de tráfego, marcação de pacote, e fragmentação e intercalação. Esses mecanismos diferem do CAC nas seguintes importantes formas:

  • Eles foram criados para proteger o tráfego de voz do tráfego de dados que disputam os mesmos recursos de rede.
  • Foram criados para lidar com o tráfego já presente na rede.

Os mecanismos do CAC estendem as capacidades do conjunto de ferramentas de QoS para impedir o tráfego de voz de ser negativamente afetado por outro tráfego de voz e para manter o tráfego de voz excessivo fora da rede. A Figura 1 mostra por que o CAC é necessário. Se a ligação de acesso a WAN entre os dois PBXs possui largura de banda para transportar somente duas chamadas VoIP, a admissão de uma terceira chamada prejudicará a qualidade de voz das três chamadas.


Figura 1   Rede VoIP sem CAC


A razão de tal defeito é que os mecanismos de enfileiramento fornecem vigilância, e não CAC, o que significa que se os pacotes que excederem a taxa configurada ou permitida forem recebidos, simplesmente sofrerão uma queda no final da fila. Não há recursos nos mecanismos de enfileiramento para distinguir quais pacotes IP pertencem a qual chamada de voz, assim todos os pacotes que excedem determinada taxa de chegada em um certo período serão eliminados. Dessa forma, todas as três chamadas passarão por perda de pacote, o que é percebido como clipes pelos usuários finais.

Este problema é mais fácil de resolver em mecanismos de transporte de Layer 2 (VoFR e VoATM), mas é especialmente mais intenso no aplicativo predominante e ainda mais atraente nos aplicativos VoIP.

Alternativas de Novo Roteamento de Chamada

A Figura 2 mostra o ponto em que uma decisão do CAC é alcançada pelo gateway de saída no qual recursos de rede insuficientes são disponibilizados para permitir a continuação da chamada.


Figura 2   Rede VoIP com CAC


Depois que a chamada é rejeitada, o gateway original deve encontrar outra forma de lidar com a chamada. Há várias possibilidades, a maioria delas dependendo da configuração do gateway. Na falta de uma configuração específica, o gateway de saída fornecerá uma nova ordem de tom ao chamador. A reordenação de tom é chamada de fast-busy na América do Norte, e é conhecida como sobrefluxo de tom ou equipamento ocupado em outras partes do mundo. Este tom é sempre interceptado por switches PSTN ou PBXs com um aviso como "Todos os circuitos estão ocupados, tente novamente mais tarde."

O gateway de saída pode ser configurado para as seguintes soluções de novos roteamentos:

  • A chamada pode ser roteada novamente por um caminho alternativo de rede de pacotes caso tal caminho já exista, o que exige a configuração de um segundo correspondente de discagem VoIP, de preferência inferior ao escolhido anteriormente.
  • A chamada pode ser roteada novamente por um caminho de rede TDM alternativo caso tal caminho exista, o que exige a configuração de um correspondente de discagem POTS e de uma interface TDM física para o PSTN ou outro PBX.
  • A chamada pode ser retornada ao switch de TDM original para estimular uma das seguintes capacidades de novo roteamento.
    • Se a conexão entre o switch de origem e o gateway de saída for um tronco de sinalização de canal comum (CCS) (por exemplo QSIG, PRI ou BRI), a chamada será rejeitada com um código de causa e o switch de origem desconectará o tronco e retomará a operação da chamada.
    • Se a conexão entre o switch de origem e o gateway de saída for um tronco analógico ou com sinalização associada ao canal (CAS) (por exemplo, E&M, T1 CAS, T1 FGD), a chamada deverá ser grampeada (com um segundo tronco na mesma interface) de volta ao switch.

Mecanismos CAC

Como foram considerados vários aspectos interessantes do CAC nas redes de pacote, várias soluções diferentes foram destacadas. Nenhuma delas resolve todo o problema, mas todas são sempre úteis para tratar de um aspecto específico de CAC. Diferente do que ocorre com as redes baseadas em circuito (que reservam um slot de tempo DS0 em cada perna do caminho que pode ser seguido), determinar se uma rede de pacotes tem os recursos para transportar uma chamada de voz não é tarefa simples. Esta seção aborda as seguintes subseções:

Categorias dos Mecanismos CAC

O restante do documento aborda dez mecanismos de CAC diferentes disponíveis em versões atuais do software Cisco IOS. Eles são agrupados nas três categorias a seguir:

  • Mecanismos CAC Locais—Função de mecanismos CAC locais no gateway de saída. A decisão do CAC é baseada nas informações dos nós, como o estado da LAN de saída ou ligação de WAN. Se a ligação da rede de pacotes local estiver inativa, não há razão para executar uma complexa lógica de decisões com base no estado do restante da rede, pois esta rede estará inatingível. Os mecanismos locais incluem itens de configuração para desabilitar mais que um número fixo de chamadas. Por exemplo, se o projetista da rede já souber que não mais que cinco chamadas podem ser realizadas na ligação da WAN de saída devido a limitações de largura de banda, parece lógico que seja possível configurar o nó local para permitir mais que cinco chamadas.
  • Mecanismos CAC Baseados em Medidas —As técnicas CAC baseadas em medidas observam a rede de pacote mais adiante para medir o estado da rede e determinar se permite uma nova chamada. Medir o estado da rede implica em enviar provas ao endereço IP de destino (normalmente o gateway ou o gatekeeper final) que retornarão ao gateway de saída com algumas informações medidas quanto às condições que a prova encontrou ao atravessar a rede até o destino. Normalmente, as características de perda e atraso são elementos de informação interessantes para voz.
  • Mecanismos CAC Baseados em Recurso — Há dois tipos de mecanismos baseados em recurso: os que calculam os recursos necessários e/ou disponíveis e os que reservam recursos para a chamada. Os recursos de interesse incluem largura de banda da ligação, slots de tempo DSPs e DS0 nos troncos TDM conectados, alimentação da CPU e memória. Muitos desses recursos podem ser restritos em qualquer um ou vários nós que a chamada atravessa para seu destino.

Há duas categorias adicionais de funcionalidade do CAC, mas elas não se relacionam ao design de rede ou a questões de infra-estrutura, portanto não serão abordadas neste documento. Essas duas categorias de CAC - segurança e usuário - se concentram na questão de política sobre se a chamada ou o usuário final têm permissão para usar a rede, como a seguir:

  • Segurança–É um dispositivo ou gateway legítimo na rede? Não há mecanismos de autenticação, incluindo protocolos como o H.235, para cobrir este aspecto do CAC.
  • Usuário–Este usuário final tem autorização para usar a rede? Há métodos de verificação CLID/ANI e PIN, normalmente realizados por meio de resposta de voz interativa (IVR), para verificar a autorização.

CAC Baseado em Medida X Baseado em Recurso

Há pouca sobreposição entre mecanismos CAC locais e os que observam o restante da rede para determinar condições não locais. Portanto, é fácil compreender por que os mecanismos distintos local e "nuvem" são úteis. No entanto, existe uma considerável sobreposição entre as técnicas de medida e as técnicas de reserva de recursos dos dois mecanismos CAC de "nuvem futura". Por essa razão, há controvérsia sobre qual método é o melhor.

A Tabela 1 compara os pontos fortes e fracos dos mecanismos CAC baseados em medida e baseados em recurso. Com essas informações, você poderá determinar o melhor método para sua rede específica.

Tabela 1   Comparação de Recursos do CAC Baseados em Medida e em Reserva de Recurso

Critérios  Técnicas Baseadas em Medida  Técnicas Baseadas em Reserva de Recurso 

Topologia de rede

Independente de topologia.

A prova viaja a um endereço IP de destino. Ela não conhece nós, saltos e disponibilidades de largura de banda de ligações específicas.

Conhecimento da topologia.

A disponibilidade de largura de banda de cada nó e todos as ligações consideradas.

Transparência de backbone

Transparente.

As provas são pacotes de IP e não podem ser enviadas por nenhuma rede, incluindo backbones SP e a Internet.

Para ser realmente o método abrangente que as técnicas de reserva pretendem ser, o recurso deve ser configurado em todas as interfaces do caminho, o que significa que o cliente proprietário do backbone de WAN e todos os nós executam o código que implementa o recurso. Em alguns casos, ser proprietário de todo o backbone não é prático, portanto as topologias híbridas podem ser consideradas—com algum compromisso com a origem abrangente do método.

Atraso após discagem

Apenas a primeira chamada pode apresentar um atraso após discagem. Depois disso, as informações são armazenadas em cache no destino e uma prova periódica é enviada para o destino IP. As chamadas subseqüentes são permitidas ou negadas com base nas últimas informações armazenadas em cache.

Um aumento de atraso após discagem existe para todas as chamadas, enquanto a reserva RSVP (Resource Reservation Protocol) deve ser estabelecida antes da configuração da chamada ser concluída.

Paridade de mercado

Muitos fornecedores têm recursos CAC do tipo ping. Para um cliente familiarizado com essa operação, as técnicas baseadas em medida são uma boa alternativa.

Precisão do CAC

A taxa de amostragem periódica das provas pode admitir chamadas em potencial quando a largura de banda for insuficiente. As técnicas baseadas em medida têm bom desempenho em redes em que as flutuações de tráfego são graduais.

Quando implementada em todos os nós do caminho, o RSVP garante largura de banda para a chamada em todo o caminho, por toda a duração da chamada. Esta é a única técnica que atinge esse nível de precisão.

Protegendo a QoS de voz depois da admissão

A decisão do CAC é baseada nas estatísticas do tráfego da prova, antes da admissão da chamada. Depois da admissão, a qualidade da chamada é determinada pela eficácia de outros mecanismos de QoS da rede.

Antes da admissão da chamada é estabelecida uma reserva por chamada. Portanto, a qualidade da chamada não é afetada por alterações nas condições de tráfego de rede.

Carga adicional do tráfego de rede

Carga adicional periódica de tráfego de prova para um número de destinos IP em cache. Tanto o intervalo quanto o tamanho do cache podem ser controlados pela configuração.

Carga adicional do tráfego de mensagens de RSVP para cada chamada.

Escalabilidade

Enviar provas para milhares de destinos IP específicos pode não ser prático em uma rede extensa. Entretanto, as provas podem ser enviadas para os dispositivos de ponta da WAN, que procura em nome de muitos outros destinos em uma rede de campus de alta largura de banda por trás da ponta. Esse procedimento fornece considerável escalabilidade, pois é muito mais provável que a WAN fique congestionada do que a LAN do campus.

A reserva de fluxo individual é importante nas ligações de pequena largura de banda ao redor da ponta da rede. Entretanto, as reservas individuais por fluxo de chamada podem não fazer sentido em ligações de grande largura de banda no backbone, como um OC-12. As topologias de rede híbridas podem resolver essa necessidade, e futuras ferramentas de RSVP adicionais deste espaço fornecerão mais escalabilidade.

Resumo do Recurso CAC

A Tabela 2 resume os dez mecanismos CAC de voz diferentes que serão abordados detalhadamente neste documento. Também é relacionada a primeira versão do Cisco IOS em que o recurso se tornou disponível.

Tabela 2   Recursos CAC

Tipo  Recurso CAC  Versão do SW 

Local

 

 

 

Limitação Física DS0

SW independente

 

Máximo de conexões no peer de discagem

11.3

 

Largura de Banda de Voz de VoFR

12.0.(4)T

 

Condicionamento de Tronco

12.1.(2)T

 

Local Voice Busyout (LVBO)

12.1.(2)T

Baseado em Medida

 

 

 

Advanced Voice Busyout (AVBO)

12.1.(3)T

 

Fallback PSTN

12.1.(3)T

Baseado em Recurso

 

 

  • Cálculo do Recurso

 

 

 

Indicação de Disponibilidade de Recurso

12.0.(5)T (AS5300)
12.1.(3)T (2600/3600)

 

Largura de Banda de Zona do Gatekeeper

11.(3) (zona local)
12.1.(5)T (zona interna)

  • Reserva de Recurso

 

 

 

Protocolo de Reserva de Recursos

12.1.(5)T

Aplicabilidade da Tecnologia de Mecanismos CAC

Considerando os vários recursos disponíveis para solucionar um requisito específico de design, como CAC, é útil eliminar imediatamente os mecanismos que não se aplicam à tecnologia de rede em consideração. A Tabela 3 resume as tecnologias de voz às quais os vários recursos de CAC se aplicam.

Tabela 3   Suporte de Tecnologia de Voz para Recursos do CAC

Recurso  VoIP H.323  VoIP SIP  VoIP MGCP  VoFR  VoATM  CM  Vídeo H.323 

Limitação Física DS0

Sim

Sim

Sim

Sim

Sim

Não

Não

Máximo de Conexões

Sim

Sim

Sim

Sim

Sim

Não

Não

Largura de Banda de Voz

Não

Não

Não

Sim

Não

Não

Não

Condicionamento de Tronco

Sim

Sim

Sim

Sim

Sim

Não

Não

Local Voice Busyout

Sim

Sim

Sim

Sim

Sim

Não

Não

Advanced Voice Busyout

Sim

Sim

Sim

Não

Não

Não

Não

Fallback PSTN

Sim

Sim

Sim

Não

Não

Não

Não

Indicação de Disponibilidade de Recurso

Sim

Não

Não

Não

Não

Não

Não1

Largura de Banda de Zona do Gatekeeper

Sim

Não

Não

Não

Não

Sim

Sim

Protocolo de Reserva de Recursos

Sim

Não

Não

Não

Não

Não

Não

Observe que os recursos de RAI do H.323 se aplicam em conceito a aplicativos de vídeo H.323. Entretanto, ele foi relacionado aqui como Não porque os gateways em consideração no documento são gateways de voz do Cisco IOS, que não vão gerar indicações de RAI para tráfego de vídeo.

Determinação da Largura de Banda de Voz

Para implementar mecanismos CAC com êxito na sua rede de voz, é necessário compreender claramente a quantidade de largura da banda necessária para cada chamada, para que seja possível prover a rede com o número necessário de chamadas e ajustar os mecanismos CAC para rejeitar chamadas que excedam esse número. Apesar das figuras de largura de banda bem publicadas para cada codec, não há uma única resposta para a quantidade de largura de banda necessária para uma chamada. Além do codec usado, vários outros atributos de rede determinam os requisitos exatos de largura de banda.

Embora uma discussão abrangente sobre cálculos de largura de banda estejam fora do escopo deste documento, vale a pena revisar algumas considerações. Na interface física, a largura de banda de voz utilizada por uma única chamada de voz depende dos seguintes fatores:

  • Tecnologia de voz utilizada (VoIP, VoATM e VoFR)
  • Mídia de Layer 2 utilizada (Ethernet, serial/MLP, FR e ATM)
  • Codec usado
  • Técnicas de compactação do cabeçalho (aplicável somente a VoIP)
  • Detecção da atividade de voz (VAD, também conhecida como Supressão do Silêncio)

Para redes ATM, que usam células de extensão fixa, deve-se considerar a sobrecarga de payload de voz (pacote IP para VoIP sobre ATM, ou payload de codec para VoATM) que se ajusta às células de ATM.

A Tabela 4 resume as combinações de VoIP mais comuns dos fatores descritos e a largura de banda resultante da chamada.

Tabela 4   Requisitos de Largura de Banda VoIP

Codec  Largura de Banda Codec (kbps)  Comprimento do Exemplo (ms)  Tamanho do Exemplo (Bytes)  Exemplos por Pacote  Tamanho do Cabeçalho IP (Bytes)  Tecnologia de Layer 2  Tamanho do Cabeçalho de Layer 2 (Bytes)  Largura de Banda Necessária para a Chamada de Voz (kbps) 

G.711

64

10

80

2

40

Ethernet

14

85.6

G.711

64

10

80

2

40

MLP/FR

6

82.4

G.711

64

10

80

2

2 (cRTP)

MLP/FR

6

67.2

G.729

8

10

10

2

40

Ethernet

14

29.6

G.729

8

10

10

2

40

MLP/FR

6

26.4

G.729

8

10

10

2

2 (cRTP)

MLP/FR

6

11.2

A fórmula usada para calcular a largura de banda para outros fatores de combinação é:

Largura de banda de voz = (Payload + L3 + L2) * 8 * pps

Os elementos da fórmula correspondem aos seguintes valores:

  • Payload = Payload em bytes gerados pelo codec
  • L3 = Layer 3 e sobrecarga do cabeçalho da camada superior em bytes (0 para VoFR e VoATM)
  • L2 = Sobrecarga do cabeçalho Link Layer em bytes
  • 8 = Número de bits por byte
  • pps= Taxa de pacotes por segundo gerada pelo codec

As tecnologias de transporte de Layer 2 apresentam as seguintes sobrecargas de cabeçalho:

  • Ethernet: 14 bytes
  • PPP e MLP: 6 bytes
  • FrameRelay: 6 bytes
  • ATM (AAL5): 5 bytes (mais o desperdício do preenchimento da célula)
  • MLP em FrameRelay: 14 bytes
  • MLP em ATM (AAL5): 5 bytes para cada célula ATM + 20 bytes para MLP e encapsulamento AAL5 do pacote IP

Estes são alguns exemplos de cálculos de largura de banda:

  • G.729 / VoIP / MLPPP / no cRTP / no VAD: (20 + 40 + 6) * 8 * 50 = 26,4 kbps
  • G.729 / MLPPP / cRTP / no VAD: (20 + 2 + 6) * 8 * 50 = 11,2 kbps
  • G.729 / VoIPovFR / no cRTP / no VAD: (20 + 40 + 6) * 8 * 50 = 26,4 kbps
  • G.729 / VoFR / no VAD: (20 + 6) * 8 * 50 = 10,4 kbps

Critério de Avaliação do Mecanismo CAC

Conforme cada método de CAC for descrito no restante deste documento, ele será avaliado em comparação aos vários fatores e critérios que ajudarão a determinar qual é o mecanismo CAC melhor e mais apropriado para o design de rede em consideração.

A Tabela 5 descreve os critérios que serão usados para avaliar as diferentes ferramentas CAC.

Tabela 5   Critérios de Avaliação do Recurso CAC

Critérios de Avaliação  Descrição 

VoX compatível

As tecnologias de voz a que o método se aplica. Alguns métodos se aplicam a uma única tecnologia e outros se aplicam em toda a banda.

Entroncamento e telefonia IP

O método é utilizável somente entre gateways de voz conectados ao PSTN ou a um PBX, ou também pode ser usado com pontos finais de telefones IP.

Plataformas e Versões

A plataforma do Cisco IOS em que este recurso está disponível e a versão do software na qual foi apresentado.

Tipos de tronco PBX suportados

Alguns recursos do CAC dependem do tipo de tronco PSTN ou PBX usado na conexão, ou atuam de maneira diferente em troncos CCS e CAS.

Ponta a ponta, local ou nuvem IP

O escopo de visibilidade do recurso CAC. Alguns mecanismos funcionam localmente somente no gateway de origem, outros consideram a nuvem entre os nós de origem e de destino, outros consideram a interface POTS de destino e algumas funcionam de ponta a ponta.

Por chamada, interface ou ponto final

Diferentes mecanismos envolvem diferentes elementos de rede. Vários métodos CAC podem funcionar por chamada, sendo alguns por interface e outros por ponto final ou destino IP.

Consciência da Topologia

Se o mecanismo CAC leva em conta a topologia da rede e, portanto, fornece proteção às ligações e nós da topologia.

Garantias de QoS para a duração de chamada

Se o mecanismo toma uma decisão única antes de permitir a chamada ou se ele também protege a QoS da chamada pela sua duração reservando os recursos exigidos.

Atraso após discagem

Se o mecanismo impõe um atraso pós-discagem adicional porque precisa de mais transferência de mensagens ou processamento durante a configuração da chamada.

Sobrecarga da rede de mensagens

Se o método utiliza transferência de mensagens adicional que precisa ser provida na rede para reunir as informações necessárias para a decisão do CAC.

Mecanismos CAC Locais

Os mecanismos locais são os mecanismos CAC mais simples de entender e implementar. Funcionam no gateway de saída e consideram as condições locais do nó. Eles também tendem a ter baixa sobrecarga, portanto, se qualquer um desses mecanismos fornecer a funcionalidade desejada, há pouca razão para implementar qualquer recurso mais complexo. No entanto, é provável que em uma rede de tamanho razoável a funcionalidade satisfatória de CAC exigirá mais do que a utilização do mecanismo local.

Nesta seção, os cinco mecanismos CAC locais serão abordados:

Limitação Física DS0

A limitação física DS0 não é um recurso específico do software, mas uma metodologia de design baseada nas limitações físicas das interfaces. Embora seja simples, se comparado a alguns dos outros recursos, este recurso é uma peça fundamental para muitas redes de cliente existentes.

Por exemplo, para limitar a cinco o número de chamadas do PBX de origem para o gateway de saída, configure ou habilite cinco slots de tempo no tronco T1 ou E1 entre o switch e o gateway de saída. A Figura 3 ilustra este princípio.


Figura 3   Limitação Física DS0


Por ser local, este método de design de CAC fornece proteção adequada para a ligação egresso da WAN do gateway de saída. Ele possui a mesma limitação dos outros mecanismos locais: não fornece proteção contra a disponibilidade de largura de banda em nenhuma outra ligação da rede. Funciona bem em topologias simples de hub-and-spoke e razoavelmente bem em redes hierárquicas multicamada mais complexas pelo simples fato de o número máximo de chamadas possíveis (pior caso) de qualquer ligação de backbone poder ser precisamente estimado por um cálculo baseado no número conhecido de chamadas que podem vir de cada localização de ponta e os padrões de tráfego em horário de pico de chamadas entre locais.

Embora esse método CAC funcione bem em aplicativos de entroncamento (gateway para gateway), não funciona para a telefonia IP, pois não há interface TDM física para a restrição de slots de tempo. Como mostrado na Figura 4, quando as chamadas são originadas de dispositivos na mídia LAN, a capacidade de largura de banda da mídia física ultrapassa bastante a da interface egressa da WAN. Sem outros recursos de software no ponto de agregação (tipicamente o router da ponta da WAN) para "receber" a chegada de novas chamadas, não há forma física de manter as novas chamadas fora da rede.


Figura 4   Aplicativos de Telefonia IP


Em resumo, a restrição da entrada de DS0s físicos na rede oferece as seguintes vantagens:

  • Não adiciona sobrecarga de largura de banda ou CPU à rede
  • Funciona bem em vários aplicativos de contorno de tarifa
  • Mecanismo CAC predominante implantado nas redes de contorno de tarifa atualmente
  • Protege a largura de banda na ligação egresso da WAN do site local
  • Pode fornecer proteção preditiva no backbone com base em padrões de tráfego em horário de pico

O método físico CAC DS0 tem as seguintes limitações:

  • Não funciona em aplicativos de telefonia IP
  • Limitado a topologias relativamente simples
  • Não reage a falhas de ligação ou alterações nas condições de rede

A Tabela 6 avalia o mecanismo de limitação física DS0 com relação aos critérios de avaliação de CAC descritos anteriormente neste documento.

Tabela 6   Resumo do Mecanismo de Limitação Física DS0

Critérios de Avaliação  Valor 

VoX compatível

Independente da tecnologia VoX usada

Entroncamento/Telefonia IP

Somente aplicações de entroncamento

Plataforma/Versão

Todos os gateways de voz e versões do Cisco IOS

Tipos de Tronco PBX Suportados

Todos

Ponta a ponta/Local/Nuvem IP

Local

Por chamada/ interface/ponto final

Por DS0/tronco (por chamada)

Consciência da Topologia

Nenhum

Garantias de QoS para a duração de chamada

Nenhum

Atraso Pós-discagem

Nenhum

Sobrecarga da Rede de Mensagens

Nenhum

Máximo de Conexões

O mecanismo CAC de máximo de conexões envolve a utilização do comando de configuração do peer de discagem max-conn em um peer de discagem do gateway de saída para restringir o número de conexões (chamadas) concorrentes que podem ficar ativas nesse peer de discagem em um determinado período.

Essa ferramenta é de fácil utilização, mas limitada no escopo dos problemas de design de rede que pode resolver. Como é aplicada por peer de discagem, não é possível limitar o número total de chamadas que o gateway de saída pode manter ativas ao mesmo tempo, a menos que haja um número limitado de peers de discagem e o comando max-conn seja usado em cada um deles.

Não esquecendo essa limitação, o comando max-conn fornece um método CAC viável em pelo menos duas situações, como as seguintes:

  • Para um número relativamente pequeno de peers de discagem que apontam chamadas para uma ligação egresso de WAN, a soma das instruções do peer de discagem específico max-conn fornecerá o número máximo de chamadas que podem ficar simultaneamente ativas na ligação da WAN.
  • Se o objetivo do design for limitar o número máximo de chamadas entre sites (em vez de proteger a largura de banda da ligação egresso da WAN), este recurso será muito útil, desde que os peers de discagem sejam estruturados de maneira que cada site remoto tenha um peer de discagem apontando chamadas para ele.

A Figura 5 mostra um exemplo deste tipo de rede. Há três sites remotos, cada um com os primeiros dígitos reconhecíveis no plano de discagem. Portanto, os peers de discagem de VoIP de saída do site principal (HQ) correspondem aos sites remotos um a um. Os números de chamadas para sites remotos 1, 2 e 3 serão limitadas a 4, 6 e 8, respectivamente. A ligação egresso da WAN não poderá, portanto, ter mais de 18 chamadas ativas ao mesmo tempo. Nessa configuração, seria prudente fornecer à largura de banda desta ligação esse número de chamadas.


Figura 5   Máximo de Conexões Configuradas no Peer de Discagem


O recurso de máximo de conexões também pode ser usado no peer de discagem POTS para limitar o número de chamadas que podem ficar ativas em um T1/E1 para um PBX/PSTN, se a intenção for prover todos os slots de tempo nessa conexão, mas limitando o número de chamadas a um número menor que o número físico de slots de tempo.

No exemplo de configuração a seguir, uma chamada VoIP que corresponda ao comando dial-peer voice 800 voip terá todos os seus pacotes de payload de voz definido em IP Precedence 5, o que significa que os três bits mais significativos do byte do tipo de serviço IP (ToS) serão definidos como 101. O primeiro peer de discagem é configurado para receber um máximo de 24 chamadas simultâneas. Qualquer chamada adicional será enviada para o PSTN pelo segundo peer de discagem.

dial-peer voice 800 voip
!Define esse grupo giratório como prioridade um.
preference 1
!Define o número máximo de conexões (controle de admissão ativa).
max-conn 24
 destination-pattern 83123... 
 ip precedence 5 
 session target ipv4:172.17.251.28 
!
dial-peer voice 600 pots
!Define esse grupo giratório como prioridade dois.
preference 2
 destination-pattern 83123...
direct-inward-dial
  port 0:D
!Adiciona o prefixo 99 na frente do número de chamada para alertar o PBX para exceder para o PSTN.
prefix 9983123

Embora este recurso seja útil em várias situações, apresenta as seguintes desvantagens:

  • Mesmo fornecendo alguma proteção para a ligação egresso da WAN do gateway de voz, fornece pouca ou nenhuma proteção a ligações do backbone da rede.
  • Não funciona em aplicações de telefonia IP que não usem peers de discagem.
  • É limitado a topologias simples.
  • Não reage a falhas de ligação ou alterações nas condições de rede.

A Tabela 7 avalia o mecanismo de máximo de conexões com relação aos critérios de avaliação do CAC descritos anteriormente neste documento.

Tabela 7   Resumo do Mecanismo de Máximo de Conexões

Critérios de Avaliação  Valor 

VoX compatível

Todos os VoX que usem peers de discagem

Entroncamento/Telefonia IP

Somente aplicações de entroncamento

Plataforma/Versão

Todos os gateways de voz e versões do Cisco IOS

Tipos de Tronco PBX Suportados

Todos

Ponta a ponta/Local/Nuvem IP

Local

Por chamada/ interface/ponto final

Por peer de discagem

Consciência da Topologia

Nenhum

Garantias de QoS para a duração de chamada

Nenhum

Atraso Pós-discagem

Nenhum

Sobrecarga da Rede de Mensagens

Nenhum

Largura de Banda de Voz

Em configurações VoFR, um comando de configuração de interface frame-relay voice-bandwidth é usado na classe de mapas FrameRelay para definir larguras de banda à parte para chamadas VoFR. Este método de provisionamento de largura de banda opera de uma maneira similar à que os recursos de Prioridade de RTP IP e Low Latency Queueing (LLQ) reservam largura de banda para fluxos de tráfego gerais. Entretanto, o comando frame-relay voice-bandwidth também fornece CAC, o que os recursos gerais de enfileiramento não fazem.

O comando frame-relay voice-bandwidth pode fornecer CAC porque VoFR é uma tecnologia de Layer 2. Observando os cabeçalhos FRF.11 (voz) ou FRF.3,1 (dados), o software Frame Relay é capaz de determinar quais quadros serão de voz e quais serão de dados. O software também sabe quais quadros pertencem a qual chamada de voz, pois campos subseqüentes do cabeçalho transportam Channel Identification (CID) e informações de payload. Como o comando frame-relay voice-bandwidth define largura de banda para voz à parte, ele também pode negar a próxima chamada, caso essa chamada adicional provoque um excesso de largura de banda alocada total.

Esse método CAC só pode ser usado se o VoFR for uma tecnologia viável na sua rede. É importante observar também que o tamanho padrão da largura de banda de voz é 0, de maneira que não sendo especificada nenhuma reserva de largura de banda, nenhuma chamada será permitida na ligação da WAN. Não inclua tráfego de sinalização na largura de banda especificada com esse comando, apenas tráfego de payload de voz.

O exemplo de configuração a seguir fornece CAC para VoFR ao prover 24 kbps, o que é suficiente para duas chamadas G.729 a 10,4 kbps cada.

interface Serial0/0
 encapsulation frame-relay
 no fair-queue
 frame-relay traffic-shaping
!         
interface Serial0/0.1 point-to-point
  frame-relay interface-dlci 16   
  class vofr
!
map-class frame vofr
  frame cir 60000
  frame bc 600
  frame frag 80
  frame fair-queue
!24 kbps é o suficiente para duas chamadas G.729 a 10,4 kbps cada.
  frame-relay voice-bandwidth 24000

A Tabela 9 avalia o mecanismo de largura de banda de voz com relação aos critérios de avaliação do CAC descritos anteriormente neste documento.

Tabela 8   Resumo do Mecanismo de Largura de Banda de Voz

Critérios de Avaliação  Valor 

VoX compatível

VoFR

Entroncamento/Telefonia IP

Somente aplicações de entroncamento

Plataforma/Versão

Router Cisco 2600s, 3600s, 3810 e 7200; Cisco IOS Versão 12.0(4)T

Tipos de Tronco PBX Suportados

Todos

Ponta a ponta/Local/Nuvem IP

Local

Por chamada/ interface/ponto final

Por chamada, por PVC

Consciência da Topologia

Nenhum

Garantias de QoS para a duração de chamada

Nenhum

Atraso Pós-discagem

Nenhum

Sobrecarga da Rede de Mensagens

Nenhum

Condicionamento de Tronco

O condicionamento de tronco fornece mais funcionalidade do que somente o CAC, mas apenas os aspectos de CAC serão discutidos aqui. Ele pode ser usado em redes de tronco de conexão redes (com conexões de voz permanentes através do VoX da rede) para monitorar o estado da conexão VoX e o retorno de ocupado do tronco para o PBX de origem, caso haja falha na conexão VoX.

Este recurso tem escopo limitado, pois se aplica somente às redes de tronco de conexão. No entanto, a maioria dos recursos de CAC se aplicam somente às redes comutadas.

A implementação de CAC em uma configuração de tronco de conexão é um problema um pouco diferente da implementação em redes comutadas, pois as conexões VoX entre os dois gateways são permanentes, como mostrado na Figura 6. A largura de banda é portanto estabelecida e alocada e deve ficar disponível, ou as conexões do tronco de conexões não serão estabelecidas adequadamente.


Figura 6   Condicionamento de Tronco


O único atributo de condicionamento de tronco comparado a outros recursos CAC é sua visibilidade, não apenas na condição de WAN de ponta a ponta, mas também na condição da conexão POTS no lado de terminação da rede. Na Figura 6, se alguma das pernas A, B, C ou D falhar, o gateway de saída saberá e poderá dar o retorno de tronco ocupado para o PBX de origem, a fim de acionar o recurso de novo roteamento na fonte. Essas informações são transportadas como parte das mensagens mantidas em atividade, geradas nas configurações do tronco de conexão.

Você pode ajustar o padrão de bit preciso que será gerado para o PBX de origem. Os bits de ABCD podem ser configurados para especificar indicações de ocupado ou fora de serviço (OOS) que o PBX de origem reconhecerá e sobre as quais atuará.

O condicionamento de tronco, portanto, não é um recurso call-by-call, como os abordados até agora. É um recurso de retorno de ocupado (ou OOS) do tronco PBX. Se a WAN falhar, o tronco para o PBX será retirado de serviço para que nenhuma chamada seja feita por ele antes da recuperação da conectividade da WAN.

A Tabela 9 avalia o mecanismo de condicionamento de tronco em relação aos critérios de avaliação CAC descritos anteriormente neste documento.

Tabela 9   Resumo do Mecanismo de Condicionamento de Tronco

Critérios de Avaliação  Valor 

VoX compatível

VoIP/H.323, VoFR, VoATM (apenas configurações do tronco de conexão)

Entroncamento/Telefonia IP

Somente aplicações de entroncamento

Plataforma/Versão

Routers das séries Cisco 2600 e 3600 e concentradores de multiacesso Cisco MC3810; Cisco IOS Versão 12,1(3)T

Tipos de Tronco PBX Suportados

Analógico e CAS

Ponta a ponta/Local/Nuvem IP

Local

Por chamada/ interface/ponto final

Por interface de telefonia

Consciência da Topologia

Nenhum

Garantias de QoS para a duração de chamada

Nenhum

Atraso Pós-discagem

Nenhum

Sobrecarga da Rede de Mensagens

Nenhum; utiliza manutenções de atividade de tronco de conexão preexistentes

Local Voice Busyout

Vários mecanismos CAC são chamados de recursos de tronco ocupado. Na seção anterior, o primeiro que encontramos foi o condicionamento de tronco. O recurso opera somente em redes de tronco de conexão. Uma funcionalidade similar é necessária para redes comutadas e o LVBO é o primeiro dos dois recursos a conseguir.

O LVBO permite que levar uma conexão de tronco PBX ao gateway anexado totalmente fora de serviço, quando as condições de WAN são consideradas inadequadas para transportar o tráfego de voz. Essa técnica possui as seguintes vantagens:

  • Algumas chamadas não são rejeitadas individualmente e incorrem em um atraso pós-discagem.
  • Evita a necessidade de retorno de chamadas grampeadas rejeitadas para o PBX de origem, usando vários slots de DS0 para uma única chamada.
  • Funciona bem pare redirecionar chamadas rejeitadas com PBXs que não têm a inteligência ou não são configuradas de forma adequada.
  • Soluciona o problema de grampeamento do PBX colocando o retorno de chamada em um terceiro DS0 da mesma linha T1/E1 para o gateway que já tenha rejeitado e grampeado a chamada (uma condição chamada de tromboning). Os tipos de tronco CCS administram esse problema de grampeamento, pois as informações de código de causa podem ser retornadas ao PBX que aciona a lógica de novo roteamento. No entanto, em troncos de CAS em que o PBX não conhece o problema, e a menos que os dígitos sejam manipulados no gateway, o PBX não pode facilmente tomar uma decisão para rotear novamente a chamada para um grupo de tronco diferente.

O LVBO fornece ao gateway de saída a capacidade de monitorar o estado de várias interfaces de rede, tanto LAN quanto WAN, e retornar o tronco como ocupado para o PBX, caso haja falhas em um das ligações monitoradas. Pode monitorar até 32 interfaces; se uma ou todas as interfaces mudarem de estado, o gateway poderá ser configurado como retorno de ocupado para o PBX. Essa chamada é denominada local voice busyout porque apenas as ligações locais podem ser monitoradas. Este recurso não tem visibilidade na rede além da ligação do gateway local.

O LVBO funciona somente no CAS e nos troncos PBX/PSTN analógicos no software atual. Em troncos CCS, a funcionalidade do código de causa pode ser usada para informar ao switch PBX para redirecionar uma chamada rejeitada. O LVBO pode ser habilitado em um desses dois modos:

  • Para forçar portas de voz específicas no estado busyout
  • Para forçar todo um tronco T1/E1 ao estado busyout

A Figura 7 ilustra a operação do recurso LVBO, incluindo um exemplo de configuração. No exemplo, o gateway de saída está monitorando duas interfaces, a interface Ethernet e0/1 e a interface WAN s0/1 em nome da porta de voz 2/0:1, um tronco de CAS T1 para um PBX. Como mostrado na Figura, este recurso só é aplicável se o dispositivo de origem for uma interface PBX/PSTN, embora o dispositivo de destino possa ser qualquer um, incluindo um dispositivo de voz com capacidade IP.


Figura 7   Funcionalidade Local Voice Busyout


O recurso LVBO apresenta as seguintes limitações:

  • Só tem visibilidade local no software atual (Cisco IOS versão 12,2); monitora somente interfaces Ethernet LAN (e não Fast Ethernet)
  • Aplica-se somente a tipos de tronco CAS e analógicos

A Tabela 10 avalia o mecanismo local voice busyout em relação aos critérios de avaliação CAC descritos neste documento anteriormente.

Tabela 10   Resumo do Mecanismo de Condicionamento de Tronco

Critérios de Avaliação  Valor 

VoX compatível

Todos

Entroncamento/Telefonia IP

Entroncamento (chamadas originadas de PBX e concluindo para destinos de telefonia IP)

Plataforma/Versão

Routers das séries Cisco 2600 e 3600 e concentradores de multiacesso MC3810; Cisco IOS versão 12,1(2)T

Tipos de Tronco PBX Suportados

Analógico e CAS

Ponta a ponta/Local/Nuvem IP

Local

Por chamada/ interface/ponto final

Por WAN, LAN e interface de telefonia

Consciência da Topologia

Nenhum

Garantias de QoS para a duração de chamada

Nenhum

Atraso Pós-discagem

Nenhum

Sobrecarga da Rede de Mensagens

Nenhum

Mecanismos CAC Baseados em Medida

Esta seção do documento se concentra nas seguintes técnicas CAC baseadas em medida:

Esses são os dois primeiros tipos de mecanismos CAC que acrescentam visibilidade à própria rede, além de oferecer informações locais no gateway de saída, conforme descrito nas seções anteriores.

Antes de abordarmos os recursos reais dessa categoria, será necessário apresentar algumas informações importantes sobre Service Assurance Agent (SAA), pois essa é a técnica estrutural empregada pelos métodos CAC baseados em medida. As provas do SAA atravessam a rede para um determinado destino IP e medem as características de atraso e perda da rede no caminho percorrido. Esses valores são retornados para o gateway de saída usar ao tomar uma decisão sobre a condição da rede e sua disponibilidade de transportar uma chamada de voz.

Observe os seguintes atributos dos mecanismos de CAC baseados em medida e que são derivados da utilização de provas do SAA:

  • Como a prova do SSA é um pacote IP viajando para um destino IP, todas as técnicas de CAC baseadas em medida se aplicam somente a VoIP (incluindo VoIP sobre Frame Relay e VoIP sobre redes ATM).
  • Conforme as provas são enviadas dentro da rede, uma certa quantidade de tráfego de sobrecarga é produzida a partir da reunião das informações necessárias para CAC.
  • Se uma decisão de CAC para uma chamada precisar aguardar o envio e o retorno de uma prova, haverá um pequeno atraso pós-discagem adicional para a chamada. Que deverá ser insignificante em uma rede projetada adequadamente.

O Cisco Service Assurance Agent

O SAA é um recurso de gerenciamento de rede integrado ao software Cisco IOS que fornece um mecanismo para análise de congestionamento de rede. Ele também é a base de vários recursos do Cisco IOS. Não foi implementado com a finalidade de concluir o CAC, nem é parte do conjunto CAC. Mas seus recursos para medir o atraso de rede e as perdas de pacote são úteis como blocos de construção para fundamentar recursos CAC. O recurso SAA é uma extensão do recurso Response Time Reporter (RTR) encontrado nas versões anteriores do software Cisco IOS.

As provas de SAA não oferecem informações de largura de banda, nem configuradas nem disponíveis. Entretanto, se a largura de banda de uma ligação em qualquer local do caminho a ser seguida pela chamada de voz for esgotada, é razoável presumir que o atraso do pacote e os valores de perda retornados pela prova refletirão essa condição, ainda que indiretamente.

Provas SAA versus Pings

As provas do SAA são similares em conceito ao popular mecanismo de conectividade IP ping, porém muito mais sofisticadas. Os pacotes do SAA podem ser criados e personalizados para imitar o tipo de tráfego para os quais estão medindo a rede, nesse caso, um pacote de voz. Um pacote de ping é, por definição, quase um pacote de melhor esforço e mesmo se a precedência do IP for definida, ele não se assemelhará ao pacote de voz em tamanho ou protocolo. Nem os mecanismos de QoS implantados na rede classificarão e ameaçarão um pacote de ping como um pacote de voz. O atraso e a perda sofridos por um ping são, portanto, uma medida muito rudimentar do pior caso do tratamento a que um pacote de voz pode estar sujeito enquanto atravessa a mesma rede. Com a penetração de mecanismos de QoS sofisticados em backbones de rede, um ping se torna inutilizável como indicação prática da capacidade da rede de transportar voz.

Protocolo SAA

O protocolo SAA é um protocolo de cliente/servidor em UDP. O cliente cria e envia a prova, e o dispositivo de destino (com o RTR Responder habilitado) retorna a prova ao remetente. As provas de SAA usadas para CAC saem aleatoriamente em portas selecionadas da extremidade máxima do intervalo de portas de áudio definidas por UDP (16384 a 32767); usam um tamanho de pacote baseado no codec que será utilizado pela chamada. Se desejável, a precedência de IP pode ser definida, e um cabeçalho RTP/UDP/IP completo será usado como o cabeçalho que seria transportado por um pacote real de voz. Por padrão, as provas do SAA utilizam a porta RTCP (o número ímpar de porta RTP), mas também podem ser configuradas para usar a porta de mídia RTP (o número par de porta RTP), se desejado.

O SAA foi introduzido nas plataformas do Cisco IOS Versão 12.0(7)T. As plataformas avançadas do router Cisco tendem a suportá-lo (por exemplo, as séries Cisco 7200 e 7500), e as plataformas com poucos recursos tendem a não suportá-lo (por exemplo, o router Cisco 1750). Quando este documento foi escrito, nem os routers Cisco de acesso a cabo nem os telefones IP suportavam provas do SAA ou respondiam a provas SAA.

Fator de Defeito de Planejamento Calculado

A ITU padroniza Defeito de Transmissão de rede em ITU G.113. Esse padrão define o termo Calculated Planning Impairment Factor (ICPIF), que é um cálculo baseado em exemplos de atraso da rede e de perdas de pacote. O ICPIF produz um único valor que pode ser usado como um medidor de defeito de rede.

A ITU G.113 fornece as seguintes interpretações de valores de ICPIF específicos:

  • 5: Muito bom
  • 10: Bom
  • 20: Adequado
  • 30: Caso limitado
  • 45: Caso limitado excepcional
  • 55: Provável forte reação dos clientes

As informações de perda e atraso da prova do SAA são utilizadas no cálculo de um valor de ICPIF que, então, é usado como um limite para decisões de CAC, com base na interpretação de ITU descrita nos requisitos de uma rede específica de um cliente.

Advanced Voice Busyout

O AVBO é um aprimoramento do LVBO. Embora o LVBO forneça busyout com base em condições locais do gateway de saída, o AVBO acrescenta a capacidade de acionar uma prova do SSA para um ou mais destinos IP configurados. As informações retornadas pela prova – sejam os valores de atraso ou perda explícitos ou o limite de congestionamento de ICPIF – podem ser utilizadas para disparar um busyout da conexão para o PBX.

O AVBO portanto introduz a habilidade de tornar um tronco PBX ocupado – ou portas de voz específicas – com base nas condições atuais da rede IP. Essa capacidade é demonstrada na Figura 8.


Figura 8   Advanced Voice Busyout


O exemplo de configuração a seguir mostra um AVBO em um tronco CAS T1 para um PBX.

controlador T1 2/0
 ds0-group 1 timeslots 1-4 type e&m-immediate-start
!
voice-port 2/0:1
  voice-class busyout 4
!
voice class busyout 4 
 busyout monitor Serial0/1
 busyout monitor Ethernet0/1
 busyout monitor probe 1.6.6.48 codec g729r8 icpif 10

Ao usar o Advanced Voice Busyout, lembre-se das seguintes restrições e limitações:

  • Os resultados de busyout baseados em provas (baseados em medidas) não são absolutos; portanto, há condições em que podem ocorrer um falso positivo.
  • O endereço IP monitorado pelas provas são configurados estatisticamente (como mostrado no exemplo de configuração). É necessário garantir manualmente que esses endereços IP sejam realmente os destinos para os quais as chamadas estão sendo feitas. Não há coordenação automática entre a configuração da prova e os destinos IP reais para os quais os correspondentes de discagem VoIP ou um gatekeeper possam direcionar as chamadas.
  • O nó de destino (o dispositivo que possui o endereço IP para o qual a prova é enviada) deve suportar um respondedor SSA.
  • Este recurso não pode tornar o tronco PBX ocupado com base no estado do tronco de telefonia no nó remoto. Ele monitora apenas a rede IP.
  • Os recursos baseados em prova do SAA não funcionarão bem em redes em que a carga do tráfego flutua drasticamente em um curto período.
  • Como ocorre com o LVBO, este recurso pode ser aplicado somente a troncos CAS e analógicos. Os troncos CCS ainda não são suportados.

A Tabela 11 avalia o mecanismo AVBO com relação aos critérios de avaliação CAC descritos anteriormente neste documento.

Tabela 11   Resumo do Mecanismo AVBO

Critérios de Avaliação  Valor 

VoX compatível

Somente VoIP

Entroncamento/Telefonia IP

Entroncamento (chamadas originadas de PBX e concluindo para destinos de telefonia IP)

Plataforma/Versão

2600s, 3600s, MC3810; Versão 12,1(3)T

Tipos de Tronco PBX Suportados

Analógico e CAS

Ponta a ponta/Local/Nuvem IP

Nuvem IP

Por chamada/ interface/ponto final

Por destino IP

Consciência da Topologia

Nenhum

Garantias de QoS para a duração de chamada

Nenhum

Atraso Pós-discagem

Nenhum

Sobrecarga da Rede de Mensagens

Provas SAA periódicas

Fallback PSTN

O nome fallback PSTN é, de alguma forma, inapropriado, pois uma chamada pode ser redirecionada para qualquer opção de nova rota discutida anteriormente neste documento, e não apenas o PSTN. E mesmo se uma chamada for redirecionada para o PSTN, a redireção pode ser feita pelo gateway de saída ou pelo PBX anexado ao gateway de saída, dependendo da configuração. Por essa razão, esse recurso às vezes é chamado de fallback de VoIP.

Diferente do AVBO, o fallback PSTN é um mecanismo de CAC por chamada: ele não ocupa nenhum tronco nem fornece nenhuma indicação geral ao PBX anexado de que a nuvem IP não pode receber chamadas. A decisão de CAC só é acionada quando ocorre uma tentativa de configuração de chamada.

Como o fallback PSTN é baseado em provas do SSA, ele apresenta as vantagens e desvantagens de uma técnica baseada em medida. Ele é incomumente flexível, pois pode tomar decisões de CAC com base em qualquer tipo de rede IP, incluindo a Internet. Todas as redes IP transportarão o pacote de prova do SSA como outro pacote IP. Portanto, não importa se a rede backbone do cliente compreender uma ou mais rede provedora de serviço (SP), a Internet ou qualquer combinação desses tipos de rede. O único requisito é que o dispositivo de destino (o proprietário do endereço IP ao qual a prova é enviado) seja compatível com a funcionalidade do respondedor do SSA.

Esse dispositivo de destino deve ser parte da rede do cliente no local de destino, com um backbone SP no meio. O fallback PSTN, portanto, não pode ser utilizado diretamente com telefones IP e destinos de aplicativos VoIP baseados em PC, mas pode ser utilizado indiretamente, se tais destinos estiverem atrás de um router Cisco IOS que suporte o respondedor SSA. O dispositivo de destino não precisa suportar o recurso do fallback PSTN (ele é apenas um recurso de gateway de saída), apenas o respondedor da prova do SSA é necessário.

Provas SAA Usadas no Fallback PSTN

Como mostrado na Figura 9, quando ocorre uma tentativa de chamada no gateway de saída, os valores de congestionamento de rede para o destino IP serão usados para permitir ou rejeitar a chamada. Os valores de congestionamento de rede para atraso, perda ou ICPIF são fornecidos ao enviar uma prova do SSA ao destino IP que a chamada está tentando alcançar. Os valores-limite para rejeitar uma chamada são configurados no gateway de saída.


Figura 9   Fallback PSTN


Cache de Destino IP

Diferente do AVBO, o fallback PSTN não exige a configuração estática dos destinos IP. O software mantém um cache de tamanho configurável que rastreia os destinos IP usados mais recentemente nas tentativas de chamada. Se um destino IP de uma nova tentativa de chamada for encontrado no cache, a decisão do CAC para a chamada poderá ser feita imediatamente (Os exemplos 1 e 2 da Figura 10 mostram as situações de "chamada permitida" e "chamada rejeitada", respectivamente). Se a entrada não for exibida no cache, uma nova prova será iniciada e a configuração da chamada será suspensa até a chegada da resposta da prova (Exemplo 3 da Figura 10). Portanto, um atraso pós-discagem será imposto para a primeira chamada para um novo destino IP.


Figura 10   Configuração da chamada do fallback PSTN


Quando um destino IP for inserido no cache, uma prova periódica com um valor de período configurável será enviado para o destino para atualizar as informações no cache. Se não houver mais chamadas para este destino IP, a entrada perderá a validade no cache e o tráfego da prova para esse destino será descontinuado. O fallback PSTN portanto ajusta dinamicamente o tráfego de prova para os destinos IP que estão vendo ativamente atividade de chamada.

Formato da Prova SAA

Cada prova consiste em vários pacotes - um parâmetro configurável do recurso. Os valores de atraso, perda e ICPIF inseridos no cache para o destino de IP serão a média de todas as respostas.

Se a chamada usar os codecs G.729 e G.711, os tamanhos do pacote da prova imitarão os de um pacote de voz para esses codecs. Outros codecs usarão provas como G.711. Nas versões do software Cisco IOS posteriores à Versão 12,.(3)T, outras alternativas de codec também podem ser suportadas com suas próprias provas exatas.

A Precedência IP dos pacotes de prova também podem ser configurada para imitar mais aproximadamente a prioridade de um pacote de voz. Esse parâmetro deve ser igual à precedência IP utilizada para outros pacotes de mídia de voz na rede.

Configuração do Fallback PSTN

A configuração do fallback PSTN se aplica somente a chamadas iniciadas pelo gateway de saída. Ela não tem influência em chamadas recebidas pelo gateway. O nó de destino (sempre o gateway de terminação, mas não necessariamente) deve ser configurado com o recurso Respondedor SAA. Na maioria das redes, os gateways geram chamadas uns para os outros, de forma que cada um deles seja ao mesmo tempo gateway de saída e de terminação. Mas, em algumas redes (como as redes SP), a direção do tráfego é ocasionalmente unilateral, seja de entrada ou saída.

A configuração do fallback PSTN é feita no nível global e portanto se aplica a todas as chamadas tentadas pelo gateway. Não é possível aplicar seletivamente um fallback PSTN somente a chamadas iniciadas por determinadas interfaces de PSTN/PBX.

Para ativar o fallback PSTN, digite os seguintes comandos globais de configuração:

  • Gateway de saída: o comando call fallback
  • Nó de destino: o comando rtr responder

O comando call feedback tem as seguintes palavras-chave com os seguintes valores padrão:

call fallback Command Keyword  Finalidade da Palavra-chave  Valor padrão 

cache-size

Configurar tamanho do cache

128

cache-timeout

Configurar tempo limite do cache

600 s

instantaneous-value-weight

Configurar o peso do valor instantâneo

66

jitter-probe

Configurar parâmetros de prova jitter

 

  • num-packets

Configurar o número de pacotes na prova

15

  • precedence

Configurar a procedência de pacotes na prova

2

  • priority-queue

Enviar as provas pelo PQ de voz

desligado

key-chain

Configurar a cadeia de códigos MD5

nenhum

map

Configurar mapeamento IP

nenhum

probe-timeout

Configurar o tempo limite da prova

30 s

limite

Configurar limite de atraso/perda de ICPIF

 

  • delay n loss m

Configurar limite de atraso

nenhum

  • icpif n

Configurar limite de ICPIF

10

Escalabilidade do Fallback PSTN

Clientes com redes extensas sempre se preocupam com a possibilidade de o fallback PSTN provocar um grande tráfego de provas na rede. Em redes menores, os gateways de terminação podem ser usados como nós de destino da prova. Em outras palavras, os endereços IP mantidos no cache do gateway de saída serão os dos gateways de terminação para os quais o tráfego é enviado.

No entanto, para sites maiores ou sites de campus que podem ter vários gateways de terminação, para sites com telefone IP ou aplicativos baseados em PC como destinos ou para sites que tenham um router de extremidade da WAN separado do gateway de terminação, os endereços IP de destino do tráfego de chamada podem ser mapeados para um conjunto muito menor de destinos de prova que será mantido em cache, como a seguir.

  • Considere um exemplo baseado na Figura 11. Há um grande número de telefones IP no Site 6, cada um com um único endereço IP. Se o Site 2 chamar um telefone IP no Site 6, o cache do Site 1 não precisará conter uma entrada para cada destino de IP separado no Site 6 e enviar uma prova separada para cada endereço IP. Todos os destinos de chamadas IP do Site 6 poderão ser mapeados para o endereço IP do router da extremidade da WAN do Site 6, de maneira que uma única prova do Site 1 ao Site 6 possa investigar informações do CAC para todas as chamadas destinadas ao Site 6. O mesmo princípio se aplica se houver vários gateways de terminação no Site 6. Todos os endereços IP podem ser mapeados para o router da extremidade da WAN, que pode ser ou não um gateway de terminação.

Figura 11   Escalabilidade do Fallback PSTN


Portanto, o tráfego de provas pode ser reduzido substancialmente pelo envio de provas para destinos IP que representem a parte da rede mais provável de estar congestionada (o backbone da WAN e a extremidade da WAN) e pelo não envio de tráfego de provas por um campus ou backbone de LAN de alta velocidade com bem menos probabilidade de estar congestionado. Esse mesmo mecanismo de escalabilidade também fornece um mecanismo para suportar destinos IP não compatíveis com a funcionalidade do respondedor SAA.

Resumo do Fallback PSTN

O fallback PSTN é um mecanismo CAC independente de topologia e amplamente implementável que pode ser usado em qualquer backbone, independentemente de o cliente ser o proprietário do equipamento de backbone ou da tecnologia utilizada no backbone, ou do equipamento utilizado no backbone.

Os atributos do fallback PSTN a seguir devem ser considerados na criação da rede:

  • Como ele é baseado em provas IP, o fallback PSTN se aplica somente a redes VoIP.
  • O fallback PSTN não faz nova rota de chamadas em andamento quando as condições de rede mudam.
  • Um pequeno aumento de atraso pós-discagem será aplicado somente à primeira chamada para um destino que ainda não esteja em cache.
  • Não há interação entre o temporizador da prova do SSA e as configurações do temporizador do H.225. A prova do SSA ocorre antes de a configuração de chamada do H.323 ser enviada ao destino, e o temporizador do H.225 ocorre depois do envio da configuração de chamada do H.323.
  • O fallback PSTN é baseado em medida, portanto não é absoluto. Ele opera bem em tráfego constante com aumento e redução graduais, mas com deficiências em tráfego rapidamente flutuante com aumentos e reduções abruptos.
  • Pode-se tomar uma decisão CAC errada com base em informações desatualizadas decorrentes da natureza periódica das provas.
  • Os destinos proxy das provas podem ser usados pelo mapeamento de endereços IP de destino para um número menor de endereços IP dos nós localizados entre o gateway de saída e os gateways de terminação.
  • As provas não tomam medidas de largura de banda, apenas medidas de atraso e perda.
  • A autenticação em cadeia de código MD5 pode ser configurada para segurança, com o objetivo de garantir que as provas sejam iniciadas somente por fontes confiáveis, o que envolve ataques do tipo "negação de serviço" por fontes não confiáveis que iniciam grandes volumes de provas.

A Tabela 12 avalia o mecanismo fallback PSTN com relação aos critérios de avaliação do CAC descritos anteriormente neste documento.

Tabela 12   Resumo do Mecanismo Fallback PSTN

Critérios de Avaliação  Valor 

VoX compatível

Somente VoIP

Entroncamento/Telefonia IP

Entroncamento (chamadas originadas de PBX e concluindo para destinos de telefonia IP)

Plataforma/Versão

Cisco 2600/3600, MC3810: Versão 12.1.(3)T

AS5300: Versão 12.2.(2)T

Respondedor SAA suporta 7200/7500

Tipos de Tronco PBX Suportados

  • Todos os tipos de sinalização de tronco PBX/PSTN (analógico, digital, CAS e CCS)
  • Para CAS analógico e digital - destino IP alternativo, grampeamento
  • Para CCS digital - rejeição da chamada para PBX ou PSTN para novo roteamento

Ponta a ponta/Local/Nuvem IP

Nuvem IP

Por chamada/ interface/ponto final

Por destino IP ativo/em cache

Consciência da Topologia

Nenhum

Garantias de QoS para a duração de chamada

Nenhum

Atraso Pós-discagem

Apenas para a primeira chamada a iniciar a prova

Sobrecarga da Rede de Mensagens

Provas SAA periódicas

Mecanismos CAC Baseados em Recurso

Esta seção aborda três técnicas de CAC baseadas em recurso:

Como as técnicas de CAC baseadas em medida, essas técnicas adicionam visibilidade à rede, bem como às informações locais do gateway de saída que podem ser utilizadas para CAC, como discutido nas seções anteriores.

Cálculo de Recurso X Reserva de Recurso

Há dois tipos de mecanismos CAC baseados em recurso:

  • Os que monitoram a utilização de certos recursos e calculam um valor que afetará a decisão do CAC
  • Os que reservam recursos para a chamada

Os mecanismos de reserva são os únicos que podem garantir QoS durante uma chamada. Todos os demais mecanismos de CAC (locais, baseados em medida e baseados em cálculos de recurso) simplesmente tomam uma decisão única antes da configuração da chamada com base no conhecimento das condições da rede no momento.

Os recursos a seguir são de interesse de chamadas de voz:

  • Slot de tempo DS0 nos troncos TDM de origem e de terminação
  • Recursos DSP nos gateways de origem e de terminação
  • Utilização de CPU de nós - normalmente os gateways
  • Utilização de memória de nós - normalmente os gateways
  • Disponibilidade de largura de banda em um ou mais ligações no caminho da chamada

No atual software Cisco IOS (Versão 12.2), os métodos CAC de cálculo de recursos abordados nas seções a seguir consideram a disponibilidade de DS0 e DSP do gateway de terminação (RAI), juntamente com largura de banda em um nível alto (gerenciamento de largura de banda de zona de gatekeeper). O único mecanismo de reserva de recursos atual (RSVP) considera somente a disponibilidade de largura de banda.

Indicação de Disponibilidade de Recurso

O RAI é um recurso do H.323v2 que descreve uma mensagem RAS enviada do gateway de terminação ao gatekeeper para oferecer informações sobre a capacidade atual de o gateway receber mais chamadas. O gatekeeper não tem conhecimento dos recursos específicos ou dos tipos de recursos considerados pelo gateway. É uma simples indicação de sim ou não enviada pelo gateway de terminação para controlar se as chamadas de voz subseqüentes são roteadas para o gateway.

Como um mecanismo CAC, o RAI é exclusivo em sua capacidade de oferecer informações na conexão de POTS de terminação. Outros mecanismos abordados neste documento habilitam as decisões do CAC com base em informações locais no gateway de saída e na condição da nuvem IP entre o gateway de saída e os gateways de terminação. Nenhum outro mecanismo de CAC é capaz de perceber a disponibilidade dos recursos para concluir a chamada de POTS no gateway de terminação. Este é o valor que o RAI traz à tabela.

Como ele é uma indicação entre um gateway e um gatekeeper, o RAI se aplica somente a redes de voz H.323 que utilizam design de gatekeeper. O RAI também é exclusivo porque a decisão de CAC é controlada pelo gateway de terminação. Em todos os outros métodos, a decisão do CAC é controlada pelo gateway de saída ou pelo gatekeeper.

Cálculo de Recursos de Gateway

O cálculo para atingir a decisão sim/não executada no gateway. Diferentes plataformas de gateway podem usar diferentes algoritmos. O padrão do H.323 não prescreve o cálculo nem os recursos a incluir no cálculo. Ele simplesmente especifica o formato de mensagem do RAI e o fato de o gatekeeper precisar interromper chamadas de roteamento para um gateway que tenha indicado uma inabilidade de receber outras chamadas até determinado momento, quando o gateway informa ao gatekeeper que ele pode receber chamadas novamente.

Para medir a disponibilidade de recursos para uma chamada dos routers das séries Cisco 2600 e 3600, o algoritmo de cálculo considera cada chamada como uma unidade, de acordo com a seguinte fórmula:

  • Cada DS0 livre é uma unidade
  • Cada DSP de alta complexidade são duas unidades
  • Cada DSP de média complexidade são quatro unidades

O RAI é calculado por plataforma, e não por interface T1/E1 ou por cartão (por módulo de rede, ou especificamente por NMM-HDV, no caso dos routers das séries Cisco 2600 e 3600). Somente DS0s atingíveis por correspondente de discagem VoIP são incluídos no cálculo.

Onde e Como o RAI é Usado nas Redes de Provedores de Serviço

O RAI é um recurso indispensável nas redes SP para fornecer serviços de chamada VoIP, como chamadas de cartão de débito e crédito e serviço de telefonia VoIP à longa distância. A estrutura geral dessas redes é mostrada na Figura 12.


Figura 12   Topologia de Rede VoIP de Provedor de Serviços


Em todo o mundo, há POPs em que racks de gateways (normalmente servidores de acesso Cisco AS5300) se conectam a PSTN com troncos T1/E1 (normalmente troncos PRI). O roteamento de chamada é gerenciado através de vários níveis de gatekeeper, como mostrado na Figura 12. O volume de chamadas é alto, e esses gateways lidam somente com tráfego de voz, e com nenhum tráfego de dados diferente do roteamento IP mínimo e do tráfego de gerenciamento de rede.

Quando um cliente da Costa Oeste entra na rede e disca um número da Costa Leste, o gatekeeper da Costa Leste deve selecionar um gateway da Costa Leste com um tronco PSTN disponível para concluir a chamada. Caso contrário, a ligação do cliente falhará. Se a chamada falhar, o gateway de saída deverá tentar a chamada novamente ou o cliente deverá rediscar a chamada. Em qualquer um dos casos, nada impede de o mesmo gateway de terminação sem capacidade ser selecionado novamente.

As duas situações são ineficientes e fornecem serviço indesejável ao cliente. Portanto, é importante que as chamadas não sejam roteadas pelo gatekeeper para um gatekeeper de terminação que não possa concluir a chamada (não por causa de capacidade IP nesse caso, mas devido à capacidade de tronco PSTN).

Em geral, as chamadas serão balanceadas por carga pelo gatekeeper na zona dos gateways de terminação. Mas os gateways podem ter níveis diferentes de capacidade de T1/E1 e, pelo puro balanceamento de carga, um gateway pode apresentar menos recursos do que outro. Essa é uma situação em que o RAI é fundamental para que o gateway de terminação sobrecarregado possa iniciar uma indicação para o gatekeeper de que está muito ocupado para receber mais chamadas.

Onde e Como o RAI é Utilizado nas Redes Corporativas

O RAI geralmente é menos aplicável em redes corporativas do que em redes SP, pois existe sempre apenas um gateway por local, como mostrado na Figura 13. Isso quase sempre é verdadeiro para o grande número de pequenos sites que se conectam a um número ainda menor de sites grandes na rede corporativa típica. Mesmo nos sites maiores pode haver vários troncos T1/E1 a serem anexados ao PBX, mas raramente há vários gateways.


Figura 13   Topologia de Rede VoIP Corporativa


Se apenas um gateway puder terminar uma chamada para um usuário chamado (onde usuário chamado é um PBX específico na rede), o RAI não fornece muita inteligência de rede que ainda não esteja disponível. Sem gateway alternativo para lidar com o excesso de chamadas, a chamada sempre falhará toda vez que o único gateway de terminação estiver muito ocupado. Além disso, em redes corporativas, a probabilidade de congestionamento é geralmente maior na nuvem IP do que no número de troncos POTS de terminação. Nas redes SP abordadas anteriormente, o congestionamento é mais comum nos troncos POTS de terminação do que na nuvem IP.

Apesar dessas limitações, o RAI ainda pode ser utilizado para redes corporativas, desde que as conexões gateway-PBX nos sites remotos sejam em troncos T1/E1. Se um gateway de terminação estiver muito ocupado, ele acionará uma nova rota de PSTN, em vez de selecionar um gateway alternativo, como na situação da rede do provedor de serviços.

Operação RAI

A discussão sobre onde e como o RAI é utilizado no provedor de serviços e nas redes corporativas mostra claramente que o RAI é mais útil em situações onde vários gateways de terminação podem atingir o mesmo número de telefone de destino (chamado). No entanto, o RAI tem valor em qualquer situação onde se deseja evitar que uma chamada seja novamente roteada para um gateway que não tenha capacidade de POTS para concluir a chamada.

Quando um gatekeeper recebe uma indicação de RAI indisponível de um gateway, ele remove o gateway do seu algoritmo de seleção de gateway para os números de telefone que esse gateway normalmente concluiria. Uma indicação de RAI indisponível recebida posteriormente retornará o gateway para o algoritmo de seleção do gatekeeper.

O RAI é um recurso opcional do H.323. Portanto, ao implementar uma rede é prudente verificar se os gateways e gatekeepers em consideração suportam este recurso. Os gatekeepers Cisco suportam RAI; o suporte do gateway Cisco para RAI será detalhado em uma seção posterior neste documento.

Configuração de RAI

No gateway, o RAI é configurado com limites do ponto mais alto e do mais baixo, como mostrado na Figura 14. Quando a utilização do recurso de acordo com o algoritmo de cálculo fornecido anteriormente ultrapassa o ponto mais alto (configurada como porcentagem), um RAI indisponível é enviado ao gatekeeper. Quando a disponibilidade de recurso falha abaixo do ponto mais baixo, uma indicação de RAI disponível é enviada ao gatekeeper. Para evitar histerese com base na chegada ou na desconexão de uma única chamada, as marcas dos pontos mais alto e mais baixo devem ser configuradas com alguns pontos percentuais à parte.


Figura 14   Configuração do RAI


Para configurar o RAI, utilize o comando de configuração de gateway resource threshold [all] [high %-value] [low %-value] .

Suporte de Plataforma RAI

O servidor de acesso Cisco AS5300 suporta RAI desde o Cisco IOS Versão 12.0(5)T; os routers das séries Cisco 2600 e 3600 suportam RAI somente para conexões T1/E1, e não para troncos analógicos, desde a versão 12.1.3T. Os demais gateways do Cisco IOS ainda não suportam RAI, como na Versão 12.1(5)T ou 12.2. O cálculo de RAI inclui DSPs e DS0s, e pode não ser o mesmo em todas as plataformas. No software atual, a CPU e a memória ainda não são incluídas na indicação de disponibilidade do RAI.

A Tabela 13 avalia o mecanismo RAI com relação aos critérios de avaliação CAC descritos anteriormente neste documento.

Tabela 13   Resumo do Mecanismo RAI

Critérios de Avaliação  Valor 

VoX compatível

Somente VoIP

Entroncamento/Telefonia IP

  • Troncamento
  • Potencialmente telefonia IP, mas CM ainda não suporta RAI

Plataforma/Versão

  • Servidor de acesso Cisco AS5300: Cisco IOS Versão 12.0(5)T
  • Routers das séries Cisco 2600 e 3600 T1/E1: Cisco IOS Versão 12.1(3)T

Tipos de Tronco PBX Suportados

Todos

Ponta a ponta/Local/Nuvem IP

Local no gateway de terminação (recursos DSP e DS0; algoritmo dependente de plataforma)

Por chamada/ interface/ponto final

Por gateway

Consciência da Topologia

Nenhum

Garantias de QoS para a duração de chamada

Nenhum

Atraso Pós-discagem

Nenhum

Sobrecarga da Rede de Mensagens

Alternância RAI ocasional entre gateway e gatekeeper

Largura de Banda de Zona do Gatekeeper

Outro mecanismo CAC específico às redes de gatekeeper do H.323 é a capacidade de o gatekeeper impor limitações de largura de banda nas zonas. Níveis diferentes do software Cisco IOS fornecem capacidades específicas dentro deste recurso. No Cisco IOS Versões 12.1(5)T e 12.2, o gatekeeper é capaz de limitar a largura de banda das chamadas em sua zona local e a largura de banda usada entre a própria zona e outra zona remota na rede.

Operação da Largura de Banda de Zona do Gatekeeper

Conversão de endereço e gerenciamento de zona são duas funções fundamentais de um gatekeeper H.323. O recurso de largura de banda de zona permite que o gatekeeper controle essencialmente o número de chamadas simultâneas que podem ficar ativas. Para compreender como este recurso opera, suponha que uma chamada de voz tenha 64 kbps de largura de banda. A maneira que o limite do número de chamadas do gatekeeper converte para a largura de banda real utilizada por essas chamadas será abordada em outra seção.

Topologia de Zona Única

A Figura 15 mostra uma rede de gatekeeper de zona única com dois gateways que demonstram o CAC do gatekeeper em sua forma mais simples. Se a largura de banda de WAN da ligação entre os dois gateways puder carregar mais de duas chamadas, o gatekeeper deverá ser configurado para negar a terceira chamada. Supondo que todas as chamadas tenham 64 kbps, o gatekeeper será configurado com uma limitação de largura de banda de zona de 128 kbps para alcançar o CAC nessa topologia simples.


Figura 15   Topologia de Zona Única Simples


No entanto, a maioria das redes não é tão simples quanto a mostrada na Figura 15. A Figura 16 mostra uma topologia complexa, mas ainda é configurada como uma rede de zona única. Nessa topologia, cada perna da nuvem de WAN tem provisionamento de largura de banda separado e, portanto, recursos separados sobre a quantidade de chamadas de voz que pode ser transportada nessa perna. Os números nas pernas de WAN da Figura 16 mostram o número máximo de chamadas que podem ser transportadas nessa perna.


Figura 16   Topologia de Zona Única Complexa


Considere que a largura de banda de zona do gatekeeper ainda é definida com um máximo de 128 kbps, permitindo portanto duas chamadas simultâneas. Este é o comportamento desejado da rede, caso as duas chamadas envolvam o Site 1: o gatekeeper protegerá a largura de banda da ligação da WAN do Site 1 para o ponto de agregação da WAN, impedindo mais de duas chamadas nessa ligação. Mas se as duas chamadas estiverem dentro do site principal, não há razão para permitir somente duas, pois haverá largura de banda suficiente no backbone do campus.

Topologia de Várias Zonas

Para reduzir o problema da zona única de redução da rede às menores capacidades de ligação de WAN em qualquer local, é possível criar a rede com várias zonas de gatekeeper. Um bom ponto de partida é criar uma zona por site, como mostrado na Figura 17.


Figura 17   Topologia Corporativa Simples de Várias Zonas


O gatekeeper do Site 1 limita a dois (128 kbps) o número de chamadas ativas no Site 1 (independentemente da origem ou terminação dessas chamadas). Como existe apenas um gateway no Site 1, não há necessidade de configurar um limite para o tráfego de chamadas dentro da zona. Todo o tráfego interior da zona é limitado a duas chamadas para proteger a ligação WAN de se conectar ao Site 1.

No Site 2 há um único gateway, portanto não há necessidade de limitar o tráfego de chamadas dentro da zona. Há limites separados entre as zonas nos seguintes cenários:

  • Chamadas entre o Site 2 e o site Principal (aqui o fator limitador é o máximo de quatro chamadas no Site 2 de conexão da ligação WAN)
  • Chamadas entre o Site 2 e o Site 1 (aqui, o fator limitador é o máximo de duas chamadas no Site 1 de conexão da ligação WAN).

O site principal tem uma configuração similar, porém as chamadas são ilimitadas dentro do site, não porque haja um único gateway, mas porque há uma ampla largura de banda entre os gateways do site.

Na topologia de rede da Figura 17, o CAC do gatekeeper fornece granularidade suficiente para proteger o tráfego de voz nas ligações de acesso WAN de baixa velocidade. Mas considere outra topologia de rede na qual haja vários gateways por zona, cada gateway (os sites remotos) com uma ligação WAN separada para o ponto de agregação. Tal topologia de rede é mostrada na Figura 18.


Figura 18   Topologia Corporativa Complexa de Várias Zonas


Entre os três gateways do Site 1, a ligação WAN com acesso mais baixo pode transportar um máximo de duas chamadas simultâneas. Como a limitação de largura de banda é configurada por zona e não por gateway, não há recurso no CAC do gatekeeper para limitar as chamadas para gateways específicos dentro da zona. A melhor alternativa, portanto, é configurar a rede para a ligação de denominador comum mais baixo: para os Sites remotos 1 e 2, o denominador comum mais baixo é uma largura de banda de 128 kbps ou duas chamadas.

Essa configuração garantirá qualidade de voz adequada sempre, mas é também um desperdício dos gateways que poderiam concluir mais chamadas sem esgotar a largura de banda da WAN. Nessa configuração de rede, o CAC será ativado muito cedo e desviará certas chamadas para o PSTN quando, na realidade, poderiam ser transportadas pela WAN. Logo, neste tipo de topologia, o CAC do gatekeeper não é suficiente para proteger a qualidade de voz na ligação WAN e ainda otimizar a utilização da largura de banda das ligações WAN.

A última configuração a considerar é uma rede de provedor de serviços em que os gateways nos POPs são conectados via Fast Ethernet para o router da extremidade da WAN, mostrado na Figura 19.


Figura 19   Topologia do Provedor de Serviços com Vários Gateways por Zona


Nessa rede, o CAC do gatekeeper é novamente insuficiente, mesmo havendo vários gateways por zona, pois as conexões para gateways específicos dentro da zona não são as ligações que precisam de proteção. A largura de banda que precisa de proteção é a ligação de acesso a WAN que vai para o backbone que agrega o tráfego de chamada de todos os gateways. Portanto, uma limitação de largura de banda para a zona limitará o número de chamadas na ligação. Presume-se que a ligação do backbone OC-12 tenha sido submetido a excesso de engenharia e não exija proteção.

Em resumo, uma rede de gatekeeper com várias zonas oferece os seguintes atributos de CAC:

  • A largura de banda WAN em cada site de conexão pode ser protegida, desde que os sites também sejam uma zona. (Para pequenos sites remotos de uma rede corporativa, isso sempre se converte em uma zona por gateway, o que pode não ser um design prático.)
  • A largura de banda de um site pode ser protegida se necessário, mas isso freqüentemente tem pouco valor, pois há apenas um gateway no site (pequenos escritórios remotos, ou um ponto de entrada de CPE para um provedor de serviços de rede gerenciado) ou porque existe uma LAN de alta velocidade entre os gateways (sites grandes e POPs do provedor de serviços).
  • O CAC do gatekeeper é um método bem adequado para limitar o número de chamadas entre sites.
  • O CAC do gatekeeper não pode proteger a largura de banda de segmentos de WAN que não estejam diretamente associados às zonas. Por exemplo, a ligação de backbone marcado com 20 chamadas na topologia corporativa simples mostrada na Figura 17 não pode ser protegido por um CAC de gatekeeper, a menos que seja seguida a abordagem de denominador comum mais baixo. Portanto, a largura de banda desta ligação é excessivamente provida com o número máximo de chamadas sempre que possível.
Dicas de Design Zona-por-Gateway

Como o design zona-por-gateway oferece a melhor granularidade de CAC de gatekeeper, vale a pena explorar tal zona um pouco mais. Nas redes corporativas isso sempre faz sentido de acordo com os seguintes pontos de vista:

  • Considerações geográficas.
  • O CAC a proteger a ligação de acesso a WAN em um site contendo um único gateway.
  • Os planos de discagem sempre coincidem com sites, portanto um prefixo de zona converte facilmente ao gateway que serve este site, caso o gateway seja equivalente a uma zona.

Um gatekeeper é um conceito lógico, e não físico. Portanto, cada gatekeeper não significa uma caixa separada na rede. Ele simplesmente significa uma instrução de "zona local" na configuração.

Quando as imagens combinadas do software do gatekeeper e do gateway estiverem disponíveis, (como a do Cisco IOS Versão 12.1(5)T e Versão 12.2), cada gateway - especificamente em sites remotos pequenos - também pode ser seu próprio gatekeeper, desde que a CPU da plataforma seja suficiente para todas essas funções. (Provavelmente servirá também como o router da extremidade da WAN.)

No entanto, um design zona-por-gateway se opõe ao aspecto de escalabilidade que os gatekeepers trazem para as redes H.323 e negam amplamente o aspecto "plano de discagem centralizado" das redes de gatekeeper, a menos que o plano de discagem seja implementado inteiramente em um nível separado usando gatekeepers de diretório. Portanto, considere cuidadosamente as vantagens e limitações de tal design.

Gatekeeper em Redes do Call Manager

De todos os mecanismos de CAC discutidos neste documento, a largura de banda de zona do gatekeeper é o único método aplicável às redes do Call Manager distribuídas em vários sites. Neste cenário, o Call Manager atua como um gateway VoIP para o gatekeeper do H.323, como mostrado na Figura 20.


Figura 20   Gatekeeper em uma Topologia do Call Manager


Cálculo de Largura de Banda da Zona

O gatekeeper não possui conhecimento de topologia de rede e não sabe o quanto de largura de banda está disponível para as chamadas. O gatekeeper também não sabe o quanto da largura de banda configurada nas ligações está sendo usado no momento por outro tráfego. O gatekeeper considera um valor fixo de largura de banda, estatisticamente configurado no gatekeeper, como mostrado nos exemplos anteriores de rede, e, em seguida, subtrai um certo valor de largura de banda de cada chamada configurada. A largura de banda é retornada ao pool quando uma chamada é desconectada. Se uma requisição de uma nova chamada fizer com que a largura de banda remanescente fique menor que zero, a chamada será negada. Portanto, o gatekeeper não faz reserva de largura de banda de nenhum tipo. Simplesmente faz um cálculo estático para decidir se uma nova chamada deve ser permitida.

É responsabilidade dos gateways informar ao gatekeeper a quantidade de largura de banda necessária para uma chamada. Portanto, gateways de vídeo podem solicitar uma largura de banda diferente para cada configuração de chamada. Uma sessão de vídeo pode exigir 256 kbps, outra, 384 kbps. Os gateways de voz devem considerar os recursos de codec, encapsulamento de Layer 2 e compressão (como cRTP) ao requisitar a largura de banda do gatekeeper. Algumas vezes, esses recursos não são conhecidos no momento da configuração da chamada e, nesse caso, uma requisição de alteração de largura da banda pode ser emitida para o gatekeeper após a configuração da chamada para ajustar a quantidade de largura da banda usada pela chamada. No momento, a Cisco ainda não implementou essa funcionalidade.

Os exemplos anteriores supuseram uma largura de banda fixa de 64 kbps por chamada, que é como os gateways Cisco H.323 são implementados no software atual. O codec e outros recursos de determinação de largura de banda, como cRTP, não são considerados atualmente quando a largura de banda de uma chamada é considerada pelo cálculo de largura de banda de zona do gatekeeper. Isso mudará em versões futuras do software mas, até lá, a implementação deste recurso exigirá um cálculo matemático manual de quantas chamadas devem ser permitidas com base em n vezes 64 kbps por chamada e o total de largura de banda de WAN disponível.

Entretanto, a largura de banda da zona do gatekeeper permanece uma ciência inexata, pois o gateway pode não ter total conhecimento da largura de banda necessária por chamada. As tecnologias de Layer 2 utilizadas nas pernas da WAN ou do backbone da rede e os recursos nó a nó como cRTP podem ser usados mais amplamente na rede do que o gateway conhece. Aqui estão alguns exemplos:

  • O gateway pode estar anexado a um segmento de Ethernet em uma rede de campus em que cRTP não se aplica e onde os cabeçalhos de Layer 2 são maiores do que seriam para Frame Relay ou MLP nas pernas da WAN.
  • Um codec diferente pode ser usado na rede do campus a partir de segmentos da WAN, impulsionando a funcionalidade de transcodificação do codec na extremidade da WAN.
  • No backbone da rede, pode-se usar o ATM como tecnologia de transporte e o preenchimento da célula deve ser considerado para cálculos de largura de banda.
  • O cRTP pode ser usado no router da extremidade da WAN.

Nem o gateway nem o gatekeeper conhecem as informações de topologia de rede descritas, a menos que o gateway seja também um router da extremidade da WAN, caso em que o router de gateway/extremidade tem um pouco mais de visibilidade. Mas ainda assim o router provavelmente não verá um backbone de ATM e, portanto, não será responsável por ele.

Configuração da Largura de Banda da Zona

Como ocorre com o Cisco IOS Versão 12.1(5)T e Versão 12.2, as limitações de largura de banda de zona a seguir podem ser configuradas no gatekeeper:

  • A largura de banda máxima para todo o tráfego H.323 entre a zona local e uma zona remota especificada. (Se desejado, essa configuração pode ser repetida individualmente em cada zona remota.)
  • A largura de banda máxima permitida para uma sessão única na zona local (normalmente utilizada para aplicações de vídeo e não para voz).
  • A largura de banda máxima para todo o tráfego H.323 permitida coletivamente a todas as zonas remotas.

Para configurar a largura de banda da zona do gatekeeper, use os seguintes comandos:

  • bandwidth {interzone | total | session} {default | zone zone-name} max-bandwidth
  • bandwidth remote max-bandwidth

Resumo da Largura de Banda de Zona do Gatekeeper

O CAC do gatekeeper funciona bem em designs de rede onde o objetivo é limitar o número de chamadas entre os sites. Isso pode ser necessário devido a limitações de largura de banda ou política de negócios. Se as limitações de largura de banda estiverem nas pernas da WAN, poderão ser feitos cálculos manuais para converter o de número máximo de chamadas a ser permitido entre os sites em um exemplo de largura de banda que fará com que o gatekeeper negue chamadas que excedam esse número.

O controle de largura de banda da zona do gatekeeper é parte fundamental dos designs de rede de vídeo do H.323. Aqui, a largura de banda é mais que um problema, pois o vídeo usa muito mais largura de banda por sessão do que a voz. Além disso, sessões diferentes de vídeo podem solicitar quantidades diferentes de largura de banda para transmissões de vídeo, tornando o método de cálculo manual utilizado para voz quase inutilizável.

Um outro fator a lembrar no design de CAC de gatekeeper é que os gatekeepers redundantes complicam um pouco os problemas. Por exemplo, se o HSRP for usado nos gatekeepers para redundância, não haverá bases de dados compartilhadas entre os gatekeepers. Se o gatekeeper principal falhar, o secundário poderá assumir, mas ele não terá conhecimento do quanto de largura de banda está sendo usado ou quantas chamadas estão ativas no momento. Até essas informações convergirem para refletirem a realidade, o gatekeeper secundário permitirá muitas chamadas na rede. Se os gatekeepers alternativos forem usados como método de redundância, esse problema pode ser revertido.

Uma grande vantagem do CAC de gatekeeper é que ele é o único método CAC que pode incorporar redes mistas de gateways do Cisco IOS e Call Managers com telefones IP.

A Tabela 14 avalia o mecanismo de largura de banda da zona do gatekeeper em relação aos critérios de avaliação CAC descritos anteriormente neste documento.

Tabela 14   Resumo do Mecanismo de Largura de Banda da Zona do Gatekeeper

Critérios de Avaliação  Valor 

VoX compatível

Apenas VoIP/H.323

Entroncamento/Telefonia IP

  • Entroncamento e telefonia IP
  • Algumas advertências caso os gateways do Call Manager e do Cisco IOS forem usados na mesma zona

Plataforma/Versão

  • Gateways do Cisco IOS desde a Versão 11.3
  • O CM sofreu recentes alterações no registro do E.164 e na largura de banda solicitada por chamada.

Tipos de Tronco PBX Suportados

Todos

Ponta a ponta/Local/Nuvem IP

Ponta a ponta entre o gateway de saída e o gateway de terminação, embora sem conhecer a topologia de rede (disponibilidade de largura de banda) no meio

Por chamada/ interface/ponto final

Por chamada

Consciência da Topologia

Nenhum

Garantias de QoS para a duração de chamada

Nenhum

Atraso Pós-discagem

Nenhum

Sobrecarga da Rede de Mensagens

Parte da transferência de mensagens RAS do gatekeeper

Protocolo de Reserva de Recursos

O RSVP é o único mecanismo CAC que faz uma reserva de largura de banda e não toma uma decisão de admissão de chamada com base em uma "adivinhação" antes da configuração da chamada. Isso fornece ao RSVP a vantagem exclusiva de não apenas fornecer CAC para voz, mas também garantir a QoS em condições de alteração de rede enquanto durar a chamada.

Implementação do Recurso RSVP

O RSVP é sincronizado com a máquina de estado H.323 no Cisco IOS Versão 12.1(5)T, portanto está disponível na Versão 12.2. Vários componentes deste recurso apareceram em versões mais recentes do software, mas apenas depois da 12.1(5)T todos os elementos do CAC ficaram disponíveis. A seguir, um breve resumo de suporte de RSVP:

  • O RSVP é sincronizado com H.323 Standard Connect: Versão 12.1(1)T
  • Suporte RSVP para LLQ: Versão 12.1(3)T
  • RSVP sincroniza com H.323 FastConnect: Versão 12.1(5)T
  • Suporte RSVP para FR PVCs: Versão 12.1(5)T

Suporte RSVP para PVCs ATM e com os telefones IP que estão sendo planejados para versões futuras do software.

Reserva RSVP para uma Chamada de Voz

A Figura 21 mostra um fluxo de chamada das mensagens de configuração do H.323 e as mensagens de reserva do RSVP.


Figura 21   Configuração de chamada do RSVP para chamada de voz do H.323


A configuração do H.323 é suspensa antes do telefone de destino que, acionado pela mensagem de alerta H.225, começa a tocar. A reserva do RSVP é feita nas duas direções pois uma chamada de voz requer um caminho de discurso de duas vias e, portanto, largura de banda nas duas direções. O gateway de terminação finalmente toma a decisão de CAC com base no êxito das reservas. Nesse momento, a máquina de estado H.323 continua com um Alerta/Conexão do H.225 (a chamada tem permissão e prossegue) ou com Rejeição/Liberação do H.225 (a chamada é negada). A reserva do RSVP ocorre quando o telefone de destino começa a tocar e o chamador ouve chamar.

O RSVP tem as seguintes diferenças de outros métodos de CAC abordados neste documento:

  • Capacidade de manter QoS durante a chamada.
  • Consciência da topologia. Em tese, a reserva do RSVP é instalada em todas as interfaces que a chamada percorrerá na rede (discutiremos exceções em outras seções), portanto garantirá largura de banda em todos os segmentos sem precisar saber a largura de banda real disponível em uma interface, nem o caminho para onde os protocolos de roteamento direcionarão os pacotes. (O RSVP portanto se ajusta automaticamente às alterações de configuração da rede, e não são necessários cálculos manuais para manter os aspectos diferentes da configuração sincronizados.)

RSVP é uma reserva de ponta a ponta por chamada e só tem visibilidade para essa chamada. Desconhece quantas chamadas estão ativas em um site ou na interface, nem a origem ou o destino de nenhuma chamada. Portanto, não há como configurar níveis agregados de CAC com RSVP, como o CAC site a site que se pode fazer com o controle de largura de banda de zona do gatekeeper.

Classificação de Pacotes de Voz em LLQ

LLQ é um dos importantes mecanismos de QoS para garantia de qualidade para voz, pois prioriza pacotes de voz sobre pacotes de dados na interface egressa do router. Para esse trabalho, os pacotes de voz devem ser classificados de modo que sejam colocados na parte da fila de prioridades (PQ) do LLQ. Tradicionalmente, isso é obtido com uma classificação da Access Control List (ACL), onde as portas TCP (sinalização) e UDP (mídia) correspondem a pacotes de voz afunilados nas filas apropriadas.

Como recurso geral do Cisco IOS, o RSVP tem seu próprio conjunto de filas reservadas dentro do enfileiramento por peso baixo (WFQ) para tráfego com reservas de RSVP. Embora essas filas tenham peso baixo, são separadas da PQ. Os pacotes de filas reservadas não têm prioridade sobre pacotes de outras filas, a não ser em função de seu peso. Há muito tempo sabe-se que esse tratamento (uma fila de baixo peso dentro do WFQ) é insuficiente para qualidade de voz em uma interface congestionada com vários fluxos de tráfego diferentes. Portanto, quando o RSVP é configurado para uma chamada, os pacotes de voz precisam ser classificados na PQ. Nesse caso, os pacotes de fluxo de dados do RSVP não devem ser classificados na PQ.

O RSVP utiliza um perfil para determinar se um fluxo de pacotes é um fluxo de voz. O perfil considera tamanhos do pacote, taxas de chegada e outros parâmetros, e um fluxo de pacote em conformidade com os parâmetros é considerado um fluxo de voz. Se não estiver em conformidade, ele não é considerado um fluxo de voz, podendo ser de dados e vídeo. O perfil interno é ativado para que o tráfego de voz originário de um gateway do Cisco IOS caia dentro dos parâmetros, sendo então considerado um fluxo de voz, sem a necessidade de configuração extra. Para aplicativos de terceiros, como o NetMeeting, pode ser necessário ativar o perfil para absorver esse tipo de tráfego. A Figura 22 mostra como isso é obtido.


Figura 22   Critérios de Classificação de Pacote RSVP


O RSVP é o primeiro classificador de interface egressa a examinar um pacote que chega. Se o RSVP considerar o pacote um fluxo de voz, os pacotes serão colocados na parte PQ do LLQ. Se o fluxo não corresponder ao perfil de voz, mas for um fluxo reservado de RSVP, ele será colocado nas filas de reserva normais do RSVP. Se o fluxo não for nem de voz nem um fluxo de dados do RSVP, os demais classificadores de interface egressa (como ACLs e instruções "correspondentes" de um mapa de classificação) tentarão classificar o pacote para o enfileiramento.

É importante notar que o RSVP só classificará tráfego de voz do portador, e não tráfego de sinalização. Um dos outros mecanismos de classificação, como ACLs ou DSCPs, ainda devem ser usados para classificar o tráfego de sinalização de voz, caso seja desejado um tratamento melhor que o de empenho máximo. Se a decisão for deixada somente para o RSVP, o tráfego de sinalização será considerado o de empenho máximo, como mostrado na Figura 22.

Alocação de Largura de Banda com RSVP e LLQ

O tráfego de voz do RSVP pode ser misturado com o tráfego de "classe prioritária" (dentro do mapa de políticas) na PQ, mas a configuração é mais simples, caso um único mecanismo de classificação de voz seja usado. Portanto, recomendamos que seja usado um ou outro para voz, e não os dois. Configure o RSVP para priorizar o tráfego de voz, ou configure os mapas de política com largura de banda de prioridade e classifique o tráfego de voz com ACLs no LLQ. Os dois podem ser usados juntos, mas não compartilham alocações de largura de banda, o que levará a uma utilização ineficiente da largura de banda da interface.

Conforme a largura de banda é definida na configuração para interfaces egressas, todas as larguras de banda e classes de prioridade serão larguras de banda alocadas no momento da configuração. Nenhuma largura de banda é alocada para o RSVP no momento da configuração. É solicitada a largura de banda quando o fluxo de tráfego for iniciado - quando uma chamada de voz for iniciada. O RSVP obtém largura de banda alocada do pool deixado depois de os outros recursos terem alocado suas larguras de banda.

Largura de Banda por Codec

Tanto o LLQ quanto o RSVP consultam o pacote IP de Layer 3. Os encapsulamentos de Layer 2 (FR, MLPPP, etc.) são adicionados depois do enfileiramento, logo a largura de banda alocada pelo LLQ e pelo RSVP para um chamada é baseada na largura de banda de Layer 3 dos pacotes. Esse número será ligeiramente diferente da largura de banda real usada na interface, quando os cabeçalhos de Layer 2 e os trailers tiverem sido incorporados. A largura de banda RSVP reservada para uma chamada também exclui cRTP e VAD. A Tabela 15 resume a largura de banda que o RSVP alocará para chamadas usando diferentes codecs do gateway do Cisco IOS.

Tabela 15   Reservas de Largura de Banda do RSVP para Codecs de Voz

Codec  Largura de Banda Reservada por Chamada no LLQ 

G.711 (Lei-A e Lei-M)

80 kbps

G.723.1 e G.723.1A (5,3 kbps)

22 kbps

G.723.1 e G.723.1A (6,3 kbps)

23 kbps

G.726 (16 kbps)

32 kbps

G.726 (24 kbps)

40 kbps

G.726 (32 kbps)

48 kbps

G.728

32 kbps

G.729 (todas as versões)

24 kbps

Configuração de RSVP

Realize as etapas a seguir em um gateway para originar ou concluir tráfego de voz usando RSVP:

  • Ative o recurso de sincronização entre o RSVP e o H.323. Este é um comando global e é ativado por padrão quando o Cisco IOS Versão 12.1(5)T ou posterior é carregado.
  • Configure o RSVP nos lados de origem e terminação dos peers de discagem VoIP. Configure a QoS solicitada (req-qos) e a QoS aceitável (acc-qos), o comando guaranteed-delay para o RSVP agir como um mecanismo CAC. (Outras combinações de parâmetros podem levar a uma reserva, mas não ao CAC.)
  • Habilite o RSVP e especifique a largura de banda máxima das interfaces que a chamada pode atravessar.

O exemplo de configuração a seguir habilita o RSVP:

!Comando global habilitando RSVP como CAC, ativado por padrão.
call rsvp-sync
controller T1 1/0
 ds0-group 0 timeslots 1-24
!
!Perfil de classificação RSVP; o padrão é "ok" para todo o tráfego de voz do gateway do Cisco IOS.
ip rsvp pq-profile voice-like
!
voice-port 1/0:0
!         
dial-peer voice 100 pots
 destination-pattern 2......
port 1/0:0
!         
dial-peer voice 300 voip
 destination-pattern 3......
session target ipv4:10.10.2.2
!Configura RSVP CAC para chamadas de voz usando o peer de discagem.
req-qos guaranteed-delay
 acc-qos guaranteed-delay

O exemplo de configuração a seguir habilita o RSVP em uma interface PPP:

interface Serial0/1
 largura de banda 1536
 endereço ip 10.10.1.1 255.255.255.0
 encapsulamento ppp
!Habilita o WFQ como método básico de enfileiramento. Resultados no LLQ com RSVP.
fair-queue 64 256 36
!Habilita o RSVP na interface.
ip rsvp bandwidth 1152 24

O exemplo de configuração a seguir habilita o RSVP em uma interface Frame Relay:

interface Serial0/0
 largura de banda 1536
 encapsulation frame-relay
 no fair-queue
 frame-relay traffic-shaping
!         
interface Serial0/0.2 point-to-point
 endereço ip 10.10.2.2 255.255.255.0
 frame-relay interface-dlci 17   
  classe VoIPoFR
!Habilita o RSVP na subinterface.
ip rsvp bandwidth 64 24
map-class frame-relay VoIPoFR
 no frame-relay adaptive-shaping
 frame-relay cir 128000
 frame-relay bc 1280
 frame-relay mincir 128000
!Habilita o WFQ como método básico de enfileiramento. Resultados no LLQ com RSVP.
frame-relay fair-queue
 frame-relay fragment 160

Escalabilidade de RSVP

Há sempre uma preocupação sobre a escalabilidade do RSVP em termos do grande número de reservas de fluxo específicas que podem ser necessárias em ligações de backbone de alta velocidade em que muitas chamadas de voz tenham sido agregadas. Na realidade, pode não fazer sentido o gerenciamento de fluxo individual em ligações de rede de backbone do OC-12, por exemplo. Por isso, no código do Cisco IOS Versão 12.1(5)T e versões posteriores, se o RSVP não for configurado em qualquer interface ou plataforma, as mensagens do RSVP serão passadas de forma transparente. Nenhuma reserva será feita ou gerenciada, mas o caminho e os pacotes do RSVP não serão eliminados.

Esse procedimento possibilita a criação de topologias híbridas, em que o RSVP é usado ao redor de extremidades da rede para proteger do esgotamento ligações de acesso WAN mais lentos, enquanto as ligações de backbone da WAN e do campus de alta velocidade não usam RSVP. É claro que essa topologia compromete a verdadeira reserva de ponta a ponta e a promessa de garantia de QoS do RSVP, mas pode ser um comprometimento administrável. As ligações de backbone podem receber uma medida de proteção de uma engenharia mais rigorosa ou de um dos mecanismos CAC discutidos anteriormente, enquanto as ligações de contenção mais alta (normalmente a extremidade da WAN) podem usar o RSVP.

A Figura 23 mostra uma rede hipotética configurada para DiffServ no backbone e no campus, mas usa as reservas do RSVP nas ligações da extremidade da WAN.


Figura 23   Topologia de Rede Híbrida DiffServ/RSVP


Resumo de CAC do RSVP

Lembre-se dos seguintes fatores quanto ao uso do RSVP como mecanismo CAC:

  • No software Cisco IOS atual, as chamadas do H.323 são iniciadas por padrão usando o FastConnect, quando o RSVP é configurado.
  • Os pacotes RSVP (PATH e RESV) viajam como tráfego de esforço máximo.
  • O WFQ deve ser habilitado em uma interface/PVC como base para LLQ.

O RSVP somente será um verdadeiro mecanismo CAC de ponta a ponta se configurado em todas as interfaces atravessadas por uma chamada.

Devido à capacidade exclusiva de servir como mecanismo CAC de ponta a ponta e para garantir a QoS ao longo de toda a chamada, o RVSP gera alguns "custos" na rede, como a seguir:

  • Sinalização (transferência de mensagens e processamento)
  • Estado por fluxo (memória)
  • Atrasos pós-discagem
  • O RSVP não fornece redirecionamento de chamada depois da configuração da chamada se houver falha em uma ligação da rede
  • O RSVP ainda não suporta os telefones Cisco IP

A Tabela 16 avalia os mecanismos RSVP com relação aos critérios de avaliação CAC descritos anteriormente neste documento.

Tabela 16   Resumo do Mecanismo RSVP

Critérios de Avaliação  Valor 

VoX compatível

Apenas VoIP/H.323

Entroncamento/Telefonia IP

Somente entroncamento atual

Plataforma/Versão

Gateways do Cisco IOS na Versão 12.1(5)T e 12.2

Tipos de Tronco PBX Suportados

Todos

Ponta a ponta/Local/Nuvem IP

  • Ponta a ponta entre gateway de saída e gatekeeper de terminação (desde que todos os nós intermediários sejam configurados para RSVP)
  • Pode ser usado em extremidades da WAN com backbone DiffServ

Por chamada/ interface/ponto final

Por chamada

Consciência da Topologia

Sim

Garantias de QoS para a duração de chamada

Sim

Atraso Pós-discagem

Sim

Sobrecarga da Rede de Mensagens

PATH/RESV e manutenções periódicas de atividade

Como Aplicar o CAC em Sua Rede

Embora ocorra alguma sobreposição entre a funcionalidade fornecida pelos diferentes mecanismos CAC, também há vários deles que resolvem aspectos diferentes do problema de CAC e, portanto, poderiam ser usados em conjunto em um design de rede. As perguntas a seguir são freqüentes:

  • Pode-se usar dois métodos de CAC juntos no mesmo gateway, ao mesmo tempo e para as mesmas chamadas?
  • (Se a pergunta para a questão anterior for sim) Em que seqüência é tomada a decisão de CAC?

A Figura 24 resume o seqüenciamento dos recursos CAC que podem ficar ativos em um gateway de saída, com base no Cisco IOS Versão 12.1(5)T e12.2. Conforme os recursos e as versões do software mudam e os defeitos são corrigidos, essas informações podem ser alteradas sem aviso. Como mostra o fluxograma, os únicos recursos mutuamente exclusivos são o RSVP e o fallback PSTN.


Figura 24   Seqüência de utilização do recurso CAC em um gateway de saída


As seções a seguir descrevem como você pode implantar os mecanismos CAC:

Quando e Quais mecanismos CAC Usar

Com uma ampla variedade de mecanismos CAC disponíveis, a pergunta imediata do projetista é "Quando devo usar qual recurso CAC?" Conforme observado durante as discussões dos recursos específicos e através de comparações e resumos mostrados no texto, os vários recursos têm atuações diferentes e resolvem diferentes aspectos dos problemas de CAC. Alguns desses aspectos podem ser critérios de design mais importantes para sua rede do que outros. Portanto, não há uma receita para quando usar qual mecanismo. Assim como ocorre com outros recursos de software, você deve tomar a decisão enquanto considera suas metas de design de rede.

Esta seção tentará fornecer uma orientação com relação aos critérios de design que podem existir para a sua rede e, caso existam, quanto aos recursos que possam se ajustar à solução. Os critérios de seleção de recurso que devem ser usados primeiro são os "Critérios de Avaliação" do final de cada seção de recurso descrita previamente. Por exemplo, se uma rede VoIP baseada em SIP estiver sendo criada, não há razão para considerar um recurso CAC H.323. Desde que você tenha chegado a esse nível de verificação, use as sugestões dessa seção para resumir as opções de recursos.

CAC em Redes Com Tronco de Conexão

Diferente de redes comutadas, em que cada chamada é configurada individualmente na rede de pacote depois da discagem de um usuário, as redes do "tronco de conexão" consistem em conexões dedicadas na rede de pacote. O PBX pode perceber que cada chamada é feita individualmente, mas a rede de pacote tem um tronco permanente no lugar (uma ligação ponto a ponto, similar em conceito a uma linha alugada) que está sempre presente, sempre pronto e sempre termina em um destino fixo e predeterminado. Essas configurações de rede de pacote dedicada são normalmente usadas quando há alguma sinalização entre os PBXs que precisam passar de forma transparente e inalterada pela rede de pacote. Os gateways não podem interpretar a sinalização; eles simplesmente colocam a sinalização em um túnel através da rede de pacote.

Há duas aplicações principais para este tipo de rede, como a seguir:

  • Redes em que a sinalização como flash-hook e Message Waiting Indications (MWI) devem ser passadas pela rede de pacotes para que um PBX seja ativado para telefones Off Premise Extension (OPX), ou seja, telefones separados pela rede de pacotes do PBX do qual criam seus recursos.
  • Redes em que a sinalização proprietária é utilizada entre PBXs para habilitar recursos de rede de PBX privados. (Exemplos incluem Lucent DCS, Siemens CorNet e NEC CCIS.)

As configurações do tronco de conexão do gateway do Cisco IOS usam as mesmas ferramentas básicas (como peers de discagem) que as redes comutadas para configurar conexões. A diferença é que essas "chamadas" são configuradas apenas uma vez, quando o gateway é inicializado ou quando a configuração é inserida, e permanecem no lugar indefinidamente. Se houver uma falha em uma ligaçãoda rede e a chamada cair, o router restabelecerá a chamada na primeira oportunidade. Se houver uma chamada real ativa (com pessoas falando) nessa conexão, isso ficará transparente para os gateways. Por isso, os mecanismos de CAC padrão, na maioria dos casos, não são aplicáveis. As configurações do tronco de conexão não avançarão apropriadamente se não houver largura de banda suficiente para a conexão. Portanto, depois que a conexão for feita, deve haver largura de banda suficiente disponível para as chamadas.

Os mecanismos CAC call-by-call a seguir se aplicam somente a redes comutadas e não devem ser usados com configurações de tronco de conexão:

No entanto, as configurações de tronco de conexão podem se beneficiar de recursos do CAC PBX busyout. Quando a rede apresentar algum defeito e a conexão permanente falhar ou as interfaces usadas falharem, certamente será útil ocupar o tronco para PBX. Esses recursos são os seguintes:

Em tese, o RSVP pode ser usado para garantir (reservar) largura de banda para as chamadas dedicadas, visando proteger a qualidade de voz das condições de rede de flutuação. Entretanto, como as redes do tronco de conexão são conexões ponto a ponto fixas, o número de chamadas ativas em qualquer segmento de rede (da perspectiva do router) será fixado e designado de forma relativamente fácil pela engenharia manual da largura de banda e pela utilização de configurações de LLQ padrão para assegurar a largura de banda. Considere cuidadosamente se o RSVP será útil nessa situação.

Áreas de Redes a Proteger

Os métodos de CAC são mais úteis e necessários em redes comutadas quando for sempre possível prever exatamente quantas chamadas podem querer usar uma perna de rede específica em um determinado momento. Métodos estatísticos para engenharia de redes de voz existem há décadas. No entanto, não há mecanismo que informe exatamente quem vai chamar quem na rede e em que momento. A menos que a topologia da rede seja muito simples, em algum momento a largura de banda pode ser sobrecarregada por muitas chamadas. No PSTN, essa condição resulta na reordenação do tom ou em uma mensagem de interrupção indicando que "todos os circuitos estão ocupados."

Considerando métodos de CAC para acionar uma condição de "todos os circuitos estão ocupados" semelhante a quando uma rede de pacotes estiver muito congestionada para transportar uma chamada, considere também os objetivos do desenho de rede. Todos os aspectos de CAC mostrados na Figura 25 existem em todas as redes, mas alguns atributos serão sempre mais importantes para um cliente específico do que para outros. Os aspectos da rede que podem precisar de proteção com recursos do CAC foram divididos em quatro áreas (A, B, C e D), como mostrado na Figura 25.


Figura 25   Divisão de Áreas da Rede


A área A é a conexão do POTS de origem. Se for importante evitar que o PBX de origem tente colocar uma chamada na rede de pacote quando a rede for incapaz de concluir a chamada, os recursos de CAC busyout devem ser considerados. Isso pode ser importante se o grampeamento for um método de recuperação de chamada rejeitada inaceitável ou se o sistema PBX/Key não puder escolher outra rota para uma chamada grampeada ou rejeitada.

A Área B é o lado de terminação do POTS da conexão. Se for provável que, devido a padrões de tráfego específicos, o lado da terminação do POTS seja a parte da rede mais suscetível a sobrecarga, o RAI do gatekeeper deverá ser usado. Em redes corporativas isso raramente tem importância, mas em redes de provedores de serviços esta é uma seção extremamente importante da rede a ser protegida.

A área C é a parte do backbone de IP da rede. Esta é a área mais típica que os clientes corporativos querem proteger suas chamadas na rede de pacote (incluindo redes de serviços gerenciadas por provedores de serviços), pois essa infra-estrutura não é dedicada a voz, mas compartilhada por vários tipos de tráfego. Os recursos de CAC que protegem a "nuvem" de rede são os seguintes:

Esses métodos de CAC são todos baseados em IP, o que significa que mais métodos CAC estão disponíveis para redes VoIP do que para redes VoFR e VoATM. A VoIP também precisa de mais CAC, porque as tecnologias de Layer 2, como Frame Relay e ATM não podem proteger intrinsecamente contra perdas de pacote VoIP, como podem para tráfego de VoFR e VoATM.

A área D é uma seção lógica da rede entre os sites. Independentemente dos sites de conexão da infra-estrutura real, você pode não querer limitar o tráfego em um site ou limitar esse tráfego com base em critérios muito diferentes das limitações de tráfego entre os sites. Por exemplo, se o local do site principal puder lidar com 24 chamadas ativas de uma vez, certifique-se que as 24 chamadas não possam ser usadas por outro site a qualquer momento, mas que uma determinada quantidade de capacidade esteja disponível em sites remotos diferentes, de modo que os sites com tráfego baixo não fiquem bloqueados pelos de tráfego alto.

Os recursos CAC que seriam usados nessa situação são os seguintes:

Considerações da Topologia de Rede

Em um nível bem geral, há duas topologias de rede a considerar, como a seguir:

  • Hub and spoke
  • Rede hierárquica de multicamada com camadas de distribuição

Essas duas topologias são mostradas conceitualmente na Figura 26.


Figura 26   Topologias de Rede Corporativa


É mais fácil manter a rede hub and spoke. Nesse caso, a maioria dos recursos CAC pode ser útil, pois apenas os spokes da rede precisam de proteção. Não há backbone invisível, e as ligações de spoke podem ser as mesmas ligações conectadas aos gateways em sites remotos. Quase todos os recursos seguintes de CAC podem ser usados para surtir um bom efeito neste tipo de rede:

A rede hierárquica de multicamada é mais representativa de redes maiores, em que sites remotos se agregam em uma ou mais camadas de pontos intermediários antes de uma rede principal que se conecta aos sites de agregação de camada superior. Muitos recursos de CAC protegerão a ligação WAN na camada inferior da rede, mas poucos deles têm visibilidade na agregação e nas pernas principais da rede. Os recursos com visibilidade na rede são os seguintes: