Projetando e implantando o Multilink PPP por Frame Relay e ATM

Introduction

Multilink PPP sobre ATM e Multilink PPP sobre Frame Relay (MLPoATM e MLPoFR) foi introduzido no Cisco IOS® Software Release 12.1(5)T. Esse recurso é direcionado a clientes com entrelaçamento Frame Relay/ATM (FR/ATM IW) que implantam Voz sobre IP (VoIP) em links de WAN de velocidade média a baixa. Antes desse recurso, não havia um esquema comum de fragmentação de Camada 2 suportado pelo Cisco IOS em clientes ATM e Frame Relay com FR/ATM IW foram forçados a fazer fragmentação de Camada 3.

Prerequisites

Requirements

Este documento destina-se ao pessoal de rede envolvido no projeto e na implantação de redes VoIP que envolvem redes MLPoATM e Frame Relay. A Cisco recomenda que você tenha conhecimento destes tópicos:

• Frame Relay

• ATM

• PPP

• MLP

• Interfuncionamento Frame Relay/ATM

• Configuração de Qualidade de Serviço (QoS - Voice Quality of Service)

Este documento não se destina a fornecer treinamento em tecnologia sobre esses assuntos. Uma lista de materiais de referência é incluída no final deste documento. A Cisco recomenda que você analise e compreenda esses documentos antes de ler este documento:

• VoIP por Frame Relay com qualidade de serviço (fragmentação, modelagem de tráfego, prioridade LLQ/IP RTP)

• VoIP QoS para Frame Relay para Entrelaçamento de ATM com LLQ, PPP LFI e cRTP

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• Software Cisco IOS versão 12.1(5)T ou posterior para MLP sobre FR/ATM IW

• Software Cisco IOS versão 12.2(2)T ou posterior para Compressed Real Time Transport Protocol (cRTP) sobre ATM

• Software Cisco IOS versão 12.0(7)T para LLQ (Low Latency Queueing) sobre Frame Relay e ATM na interface física

• Software Cisco IOS versão 12.1(2)T para LLQ sobre Frame Relay e ATM por circuito virtual permanente (PVC)

O estudo de caso incluído neste documento é baseado em uma rede de produção que usa estas versões de software e hardware:

• Os roteadores Cisco 3660 principais executam o Cisco IOS Software Release 12.2(5.8)T. O requisito para cRTP sobre ATM determina o uso do Cisco IOS Software Release 12.2T. Esse problema conhecido é resolvido no Cisco IOS Software Release 12.2(8)T1:

  ID de bug da Cisco CSCdw44216 (somente clientes registrados) - o cRTP causa alta CPU quando o enlace CBWFQ/LLQ (Class-Based Weighted Fair Queueing) alcança congestionamento.

• Os roteadores Cisco 2620 da filial estão em processo de atualização do Cisco IOS Software Release 12.2(3) para um 2.2(6a). Os Cisco 2620s também atuam como gateways H.323 da filial. A atualização é acionada por um problema relacionado ao gateway. No que diz respeito aos recursos de WAN e QoS, o Cisco IOS Software Release 12.2(3) não apresenta nenhum problema significativo.

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Projeto

Esta seção discute vários conceitos de projeto relacionados ao projeto e à implantação do PPP Multilink sobre Frame Relay e ATM.

Carga adicional de enlace de dados

Ao projetar redes ATM e Frame Relay com MLP, você deve entender a sobrecarga do enlace de dados. O overhead tem influência sobre o total de largura de banda que cada chamada de VoIP consome. Também ajuda a determinar o tamanho de fragmento MLP ideal. É fundamental otimizar o tamanho do fragmento para se ajustar a um número integral de células ATM, especialmente em PVCs de velocidade lenta, onde uma quantidade significativa de largura de banda é desperdiçada no enchimento de células. A sobrecarga de link de dados no MLP por Frame Relay e em PVCs ATM depende destes fatores:

• O modo de operação do dispositivo FRF.8 IW (transparente ou translacional).

• Direção do tráfego (ATM para Frame Relay ou Frame Relay para ATM).

• O trecho PVC. O overhead é diferente nos segmentos de ATM e de Frame Relay do PVC.

• O tipo de tráfego. Os pacotes de dados têm um cabeçalho MLP; Os pacotes VoIP não.

Esta tabela mostra a sobrecarga de enlace de dados para um pacote de dados. Ela detalha o número de bytes nos vários cabeçalhos de Frame Relay, ATM, LLC, PPP e MLP de todas as permutações do modo de operação FRF.8, direção de tráfego e trecho PVC.

1 DSAP/SSAP ^{—Ponto de Acesso de Serviço de Destino/Ponto de Acesso de Serviço de Origem.}

² NLPID ^{— Identificação do protocolo de camada de rede.}

O PVC de tradução é o mais fácil de compreender, já que a sobrecarga é a mesma em ambas as direções. Isso ocorre porque o dispositivo FRF.8 é convertido entre os formatos MLPoATM e MLPoFR. Como resultado, o formato do quadro é MLPoFR no trecho do Frame Relay em ambas as direções. O formato no segmento ATM é MLPoATM em ambas as direções.

O PVC transparente está ligeiramente mais conturbado porque a carga adicional é diferente nos dois sentidos. Essa complexidade ocorre porque o roteador Frame Relay envia pacotes no formato MLPoFR. Esse formato é transportado pelo dispositivo IW para o lado ATM. Da mesma forma, o roteador ATM envia pacotes no formato MLPoATM. Esse formato é transportado pelo dispositivo IW para o lado do Frame Relay. Portanto, o resultado são formatos de quadro diferentes nas duas direções de cada trecho.

Em comparação, a sobrecarga em um PVC de Frame Relay de ponta a ponta que usa FRF.12 é de 11 bytes. Portanto, em um enlace de Frame Relay de ponta a ponta, o FRF.12 é uma escolha mais eficiente para a fragmentação e intercalação de enlace (LFI) do que o MLP. Em circuitos virtuais ATM de ponta a ponta, o MLP é a única opção, já que não existe fragmentação baseada em padrões disponível. No entanto, VCs ATM de ponta a ponta são de velocidade média a alta. Portanto, LFI não é obrigatório. A exceção a esta regra é VCs ATM de velocidade lenta sobre DSL (Digital Subscriber Line).

O ID do PPP está presente somente no primeiro fragmento MLP. Sendo assim, a sobrecarga no primeiro fragmento é sempre dois bytes a mais que nos fragmentos subseqüentes.

A tabela aqui mostra a sobrecarga de enlace de dados para um pacote VoIP. Ela detalha o número de bytes nos vários cabeçalhos de Frame Relay, ATM, LLC e PPP para todas as permutações do modo de operação FRF.8, da direção de tráfego e da derivação de PVC. A principal diferença entre um dado e um pacote VoIP é que os pacotes VoIP são enviados como pacotes PPP e não como pacotes MLP. Todos os outros aspectos são idênticos ao cenário de dados.

Em comparação, a sobrecarga de enlace de dados para um pacote VoIP em um PVC de Frame Relay de ponta a ponta é mostrada na coluna da extrema direita.

Requisitos de largura de banda VoIP

Quando você provisiona largura de banda para VoIP, a sobrecarga do enlace de dados deve ser incluída nos cálculos da largura de banda. Esta tabela mostra os requisitos de largura de banda por chamada para os vários tipos de VoIP. Baseia-se nas características do PVC. Os cálculos nesta tabela pressupõem um cenário de melhor caso para cRTP (por exemplo, sem checksum UDP e sem erros de transmissão). Os cabeçalhos são então consistentemente compactados de 40 bytes para 2 bytes.

Como a carga adicional varia em trechos diferentes do PVC, é necessário projetar para a pior das hipóteses. Por exemplo, considere G.729 com amostragem de 20 milissegundos (msec) e cRTP em um PVC transparente. Os requisitos de largura de banda para este cenário no segmento de Frame Relay é de 12,4 Kbps em uma direção e de 13,2 Kbps na outra. O provisionamento precisa ser feito com a suposição de 13,2 Kbps por chamada.

Em comparação, o requisito de largura de banda de VoIP em um PVC de Frame Relay de ponta a ponta também é mostrado na coluna mais à direita da tabela acima. A sobrecarga adicional de PPP comparada ao encapsulamento nativo de Frame Relay resulta em um consumo extra de largura de banda entre 0.5 Kbps e 0.8 Kbps por chamada. Portanto, o encapsulamento de Frame Relay com FRF.12 faz mais sentido do que o MLP em um VC de Frame Relay de ponta a ponta.

Observação: o cRTP sobre ATM requer o Cisco IOS Software Release 12.2(2)T ou posterior.

Otimizar o tamanho da fragmentação

O motivo para usar MLP em um PVC Frame Relay/ATM é permitir que pacotes de dados grandes sejam fragmentados em blocos menores. Em seguida, o roteador acelera os pacotes VoIP, intercalando-os entre os fragmentos de dados. No Cisco IOS, o tamanho da fragmentação não é configurado diretamente. Em vez disso, o atraso desejado é configurado com a ajuda do comando ppp multilink fragment-delay. O Cisco IOS usa esta fórmula para calcular o tamanho de fragmento apropriado:

fragment size = delay x bandwidth/8

Quando você faz MLP através de ATM, o tamanho do fragmento precisa ser otimizado para que ele se ajuste a um número integral de células. Se essa otimização não for feita, a largura de banda necessária pode quase dobrar devido ao preenchimento. Por exemplo, se cada fragmento tiver 49 bytes de comprimento, duas células ATM serão necessárias para transportar cada fragmento. Portanto, 106 bytes são usados para transportar um payload de apenas 49 bytes.

O Cisco IOS otimiza automaticamente o tamanho do fragmento para usar um número integral de células ATM quando executa MLPoATM e MLPoFR. O Cisco IOS arredonda automaticamente o tamanho calculado do fragmento para o próximo número integral de células ATM. Nenhum comando CLI novo foi adicionado. O Cisco IOS executa essa otimização nas extremidades do Frame Relay e ATM de um PVC MLPoFR/ATM. É possível que um PVC MLP possa ser um Frame Relay de ponta a ponta. Nesse caso, não é necessário otimizá-lo para ATM. No entanto, o Cisco IOS otimiza esse cenário para ATM, já que não tem como detectar se a extremidade remota é ATM ou Frame Relay.

Observação: devido ao arredondamento, o atraso que os resultados podem ser um pouco mais altos do que o configurado. Esse erro de arredondamento é mais significativo em PVCs de baixa velocidade.

Você também pode configurar a otimização manualmente. Como o tamanho do fragmento não pode ser especificado diretamente no Cisco IOS, calcule o tamanho ideal do fragmento e converta-o em um atraso. Quando você calcula o tamanho do fragmento, ajuste para a sobrecarga do enlace de dados, pois o código MLP pressupõe que cada enlace é High-Level Data Link Control (HDLC) e tem 2 bytes de sobrecarga de enlace de dados. Além da sobrecarga de link de dados HDLC, o código MLP inclui em seus cálculos os 8 bytes que compõem o ID MLP, o número de Seqüência MLP e o ID PPP conforme descrito na primeira tabela acima.

Use este procedimento para calcular o atraso a ser configurado no Cisco IOS:

1. Calcule o tamanho do fragmento teórico com base no retardo desejado e na largura de banda do PVC:

   fragment = bandwidth * delay / 8

2. Certifique-se de que o fragmento é um múltiplo de 48 bytes, de modo que ele se encaixe em um número inteiro de células ATM.

   A fórmula para calcular o tamanho do fragmento alinhado pela célula é:

   fragment_aligned = (int(fragment/48)+1)*48

3. Ajuste o overhead do enlace de dados que não foi considerado pelo MLP.

   Como visto anteriormente, essa sobrecarga difere com base nas características do PVC. Considere o lado ATM do PVC, pois este é o lado para o qual você otimiza. Esta tabela mostra o número de bytes da sobrecarga de enlace de dados no lado ATM.

   Modo FRF.8	Transparente		Tradução
   Direção de tráfego	Frame relay para ATM	ATM para frame relay	Frame relay para ATM	ATM para frame relay
   Frame Relay ou trecho ATM de PVC	ATM	ATM	ATM	ATM
   LLC DSAP/SSAP (0xfefe)	0	2	2	2
   Controle LLC (0x03)	1	1	1	1
   NLPID (0xcf for PPP)	1	1	1	1
   AAL5	8	8	8	8
   Sem overhead de MLP (bytes)	10	12	12	12

   Para chegar ao tamanho do fragmento no qual o MLP baseia seus cálculos, subtraia a sobrecarga do enlace de dados do tamanho de fragmento alinhado pela célula desejada. Adicione 2 bytes novamente para compensar o encapsulamento HDLC que o MLP sempre presume.

   A fórmula para calcular o tamanho do fragmento que o código MLP destina é:

   fragment_mlp = fragment_aligned - datalink_overhead + 2

4. Converta o tamanho do fragmento que resulta no atraso correspondente com esta fórmula:

   delay = fragment_mlp/bandwidth x 8bits/byte

5. Na maioria dos casos, o atraso calculado não é um número integral de milissegundos. Como o Cisco IOS aceita apenas um valor inteiro, você deve arredondar para baixo. Portanto, o valor de atraso que você configura no Cisco IOS com a ajuda do comando ppp multilink fragment-delay é:

   fragment_delay = int(fragment_mlp/bandwidth x 8bits/byte)

6. Para compensar o erro de arredondamento acima, desvie a largura de banda usada pelo MLP para converter de atraso em fragmento. A largura de banda dividida que você configura no Cisco IOS com a ajuda do comando bandwidth é:

   bandwidth = fragment_mlp/fragment_delay * 8

Esta tabela mostra os valores ideais de ppp multilink fragment-delay e bandwidth para as velocidades de PVC mais comuns. Um atraso de destino de 10 msec é pressuposto. Para simplificar a tabela, os cálculos não diferenciam entre PVC transparente e de tradução, nem entre direções de tráfego. A diferença máxima na sobrecarga de enlace de dados é de apenas 2 bytes. Portanto, a penalidade para projetar para o pior caso de 12 bytes é pequena. Também é mostrado na tabela o atraso "real" encontrado devido ao fato de você aumentar o tamanho do fragmento para que os fragmentos se encaixem em um número integral de células.

Molde de tráfego e considerações de vigilância

É dada especial atenção à modelagem e à vigilância de tráfego em um ambiente de Frame Relay/ATM IW. Os problemas de direção entre o Frame Relay e o ATM são diferentes dos problemas de direção entre o ATM e o Frame Relay. Portanto, cada tópico é descrito separadamente.

O principal problema na direção do Frame Relay para ATM é a possível expansão no consumo de largura de banda quando se vai de quadro para célula. Por exemplo, um quadro de 49 bytes no lado do Frame Relay consome duas células, ou 106 bytes, no lado ATM. Por conseguinte, não se pode assumir que a taxa de células sustentável (SCR) seja igual à taxa de informação consolidada (CIR). O pior cenário ocorre quando cada quadro do Frame Relay contém 1 byte de payload. Cada um desses bytes consome uma célula completa de 53 bytes no lado ATM. Como exemplo desse conceito, esse cenário extremo e irrealista determina um SCR 53 vezes maior que o CIR. Dois exemplos mais realistas:

• Um pacote VoIP G.729 tem 60 bytes de comprimento ou 69 bytes (quando a sobrecarga de MLP e Frame Relay está incluída). No segmento ATM, ele consome duas células ou 106 bytes. Portanto, se todo o tráfego transportado for VoIP, um mapeamento apropriado será SCR = 106/69 = 1,5 x CIR.

• Um pacote Telnet que transporta um único pressionamento de tecla contém 40 bytes de cabeçalho TCP/IP e 1 byte de dados. No lado do Frame Relay, isso totaliza 56 bytes, incluindo a sobrecarga. No entanto, no lado ATM, esse pacote se expande para duas células. Neste caso, SCR = 106/56 = 1,9 x CIR.

O Apêndice A do padrão ATM Forum, BISDN Inter-Carrier Interface (B-ICI) Specification Version 2.0, descreve dois métodos de mapeamento entre SCR e CIR. Embora ambos forneçam uma forma científica de derivar o SCR do CIR, nenhum deles é mais exato do que os dados aos quais são aplicados. Um dos números exigidos pelas fórmulas é o tamanho típico do quadro, um número difícil de determinar em uma rede real. Além disso, um número que pode ser alterado à medida que novos aplicativos são implementados em uma rede ATM/Frame Relay existente. A melhor recomendação para solucionar este problema é trabalhar rigorosamente com seu portador, já que a política de vigilância será de importância decisiva. Com a assistência da transportadora, esta abordagem à prova de falhas é possível:

• Frame Relay para direção ATM - No sentido Frame Relay para ATM, a portadora precisa policiar o tráfego de entrada somente no ponto de entrada do Frame Relay. Por exemplo, no switch Frame Relay conectado ao dispositivo de equipamento nas instalações do cliente (CPE) conectado ao Frame Relay, a operadora policia o tráfego de acordo com a CIR contratada. Esta política de policiamento está ilustrada na figura aqui. Nenhuma vigilância adicional deve ocorrer quando o tráfego é permitido na rede no ponto de entrada. A implicação dessa política de vigilância é que os dados recebidos no lado do Frame Relay podem se expandir e consumir a largura de banda necessária para permitir taxa de célula, carga adicional de AAL e preenchimento, a fim de transportá-los no trecho ATM da rede. Na maioria dos casos, a largura de banda ATM necessária é menos do dobro da largura de banda do Frame Relay usada.

  

• ATM para Frame Relay Direction - Na direção ATM para Frame Relay, ocorre o oposto. A utilização de largura de banda é reduzida quando vai do ATM para o quadro como uma taxa de célula, carga adicional AAL, e quando o preenchimento é removido. No entanto, como a taxa de transmissão potencial do lado ATM é muito mais alta do que a do enlace Frame Relay, configurar a modelagem de tráfego corretamente no roteador ATM é essencial para a integridade da voz. Se a modelagem for muito solta, o roteador ATM alimentará dados a uma taxa mais rápida que a velocidade física do link Frame Relay na outra extremidade. Como resultado, os pacotes começam a enfileirar no switch FRF.8. Em algum momento, os pacotes começam a cair . e como as redes ATM/Frame Relay não fazem distinção entre voz e dados, os pacotes VoIP também são descartados.

  Ao mesmo tempo, se a modelagem estiver muito restritiva, o throughput sofrerá. Devido à taxa de célula ATM, overhead de AAl e preenchimento são removidos pelo dispositivo FRF.8. Ele não consome largura de banda no link do Frame Relay. Portanto, você pode fazer uma assinatura excessiva do lado ATM do PVC. A quantidade de preenchimento e overhead de AAL varia de acordo com o tamanho médio dos quadros e de quão agressiva é a fragmentação. Como você não pode qualificar corretamente essa sobrecarga, é melhor não tentar otimizá-la. Por outro lado, o imposto sobre as células é completamente determinístico. É de 5 bytes para cada payload de 48 bytes. Você pode otimizar o imposto de célula definindo o destino de modelagem no roteador ATM como 53/48 x SCR. A vigilância no lado da portadora deve ser definida para permitir essa pequena sobreassinatura.

Dicas e advertências

• O MLPoATM/Frame Relay atualmente só é testado e suportado com uma política de serviço vinculada a modelo virtual ou a interfaces do discador. Omitir a política de serviço pode fazer com que o recurso não funcione. Um exemplo disso está documentado na ID de bug da Cisco CSCdu19313 (somente para clientes registrados) .

• MLPoATM/Frame Relay faz a clonagem de duas interfaces de acesso virtual para cada PVC. Um deles representa o link PPP. O outro representa o pacote MLP. O comando show ppp multilink é usado para indicar qual é qual. Não há suporte para vários links PPPoFR por pacote. Colocar dois circuitos PPPOFR em um único tráfego de pacote não terá balanceamento de carga bem nos circuitos, já que o driver PPPOFR não fornece a sinalização de controle de fluxo que os drivers seriais reais fazem. O balanceamento de carga MLPPP sobre ATM ou Frame Relay pode mostrar claramente menos eficácia do que o mesmo balanceamento de carga sobre a interface física.

• Cada PVC é associado a quatro interfaces diferentes, a saber: a interface física, a subinterface e duas interfaces de acesso virtual. Somente a interface de acesso virtual MLP tem enfileiramento sofisticado habilitado. As outras três interfaces devem ter enfileiramento FIFO (first in, first out, primeiro a entrar, primeiro a sair).

• Quando você aplica um comando service-policy a um modelo virtual, o Cisco IOS exibe esta mensagem de aviso normal:

  cr7200(config)#interface virtual-template 1
  cr7200(config-if)#service-policy output Gromit
  Class Based Weighted Fair Queueing (CBWFQ) not supported on interface Virtual-Access1
  Note CBWFQ supported on MLP bundle interface only.
  

  Essas mensagens são normais. A primeira mensagem informa que uma política de serviço não é suportada na interface de acesso virtual PPP. A segunda mensagem confirma que a política de serviço entrou em vigor na interface de acesso virtual do pacote MLP. Este fato é verificado com a ajuda dos comandos show interfaces virtual-access , show queue e show policy-map interface para verificar o mecanismo de enfileiramento.

• A autenticação PPP não é estritamente necessária, pois um PVC é como uma linha alugada. No entanto, a autenticação PPP é útil, pois o comando show ppp multilink é usado para determinar o nome do roteador na outra extremidade do PVC.

• A modelagem de tráfego do Frame Relay deve ser habilitada para PVCs MLPoFR no roteador Frame Relay.

• O Cisco IOS Software Release 12.2 inicialmente suportava um máximo de 25 modelos virtuais por roteador. Essa limitação pode afetar a escala de um roteador de distribuição ATM se cada PVC for necessário para ter um endereço IP exclusivo. A solução para as versões afetadas é usar IP não numerado ou interfaces de discador em vez de modelos virtuais. No Cisco IOS Software Release 12.2(8)T, o suporte é aumentado para 200 modelos virtuais.

• Alguns provedores de serviço ainda não suportam a conversão do PPP em seus dispositivos FRF.8. Sempre que essa limitação estiver estabelecida, os provedores devem configurar seus PVCs para o modo transparente.

• A maioria dos exemplos na documentação da Cisco IOS mostram configurações que incluem um Frame Relay ou subinterface ATM. Esta subinterface não tem nenhum propósito. O modelo virtual deve apenas ser anexado à interface física. O resultado é uma configuração mais compacta e gerenciável. Isso é especialmente importante se houver um grande número de PVCs.

• Use o comando show ppp multilink como uma forma infalível de determinar se há algum descarte de célula/quadro no lado da portadora. A única perda de fragmento aceitável é aquela causada por erros de verificação de redundância cíclica (CRC).

• Embora o MLPoATM/Frame Relay tenha sido introduzido no Cisco IOS Software Release 12.1(5)T, bugs nesta e nas versões subsequentes exigem que você tenha cuidado ao selecionar a versão do Cisco IOS Software. A Cisco recomenda usar a versão de manutenção mais recente do mainstream do Cisco IOS 12.2. No entanto, outros requisitos de recursos de VoIP podem ditar o uso de uma versão diferente do Cisco IOS Software, como 12.2(2)XT, se o Survivable Remote Site Telephony (SRST) for necessário. Esta tabela lista alguns dos problemas conhecidos. Quando você seleciona o Cisco IOS, cada ID de bug da Cisco deve ser avaliada em relação ao IOS escolhido.

Casos Práticos

Introduction

Esta seção descreve uma das primeiras implantações de cliente do recurso MLPoATM/Frame Relay. O cliente é citado pelo nome fictício XYZ Ltd. Em 2001, a XYZ Ltd substituiu seus PBXs por uma solução de telefonia IP. Como parte desse projeto, uma nova rede IP foi criada. e o entrelaçamento Frame Relay/ATM foi escolhido para a WAN. A operadora que fornece o serviço de WAN usa switches Newbridge para fornecer os serviços ATM e Frame Relay.

Visão geral da rede

A rede XYZ Ltd é uma rede de hub e spoke que conecta 26 filiais com dois locais centrais. Cada site principal é atendido por uma ATM E3 conectada a um roteador Cisco 3660. Dezoito dos vinte e seis ramos são de tamanho médio. Eles têm PVCs duplos de Frame Relay que se conectam aos 3660s nos dois locais centrais através de IW ATM/Frame Relay. Os oito ramos restantes são muito pequenos. Eles se conectam de volta à filial de médio porte mais próxima através de um único PVC do Frame Relay. Todos os roteadores das filiais são Cisco 2620. Um PVC ATM de ponta a ponta conecta os dois roteadores 3660 nos dois locais de hub. Esta figura ilustra a topologia.

Esta tabela mostra as velocidades de acesso do Frame Relay e a CIR. A CIR varia de 32 kbps a 256 kbps. A tabela também mostra o número máximo de chamadas simultâneas de VoIP transportadas por cada PVC.

A modelagem de tráfego de Frame Relay é desempenhada pelos roteadores de filial. A intermitência além de CIR é permitida. A modelagem de tráfego do Cisco IOS é definida para modelar para a velocidade de acesso, com um mínimo igual à CIR. Se as BECNs (Backward Explicit Congestion Notification, notificações de congestionamento explícito retroativo) forem recebidas da portadora, o roteador se acelerará de volta para mincir. Essa abordagem é contra as recomendações da Cisco ao fazer VoIP sobre Frame Relay. A voz já está com problemas quando o roteador respondeu às notificações de congestionamento. Entretanto, nesse caso, a portadora acredita que sua rede está mais que o suficiente provida para nunca descartar nenhuma estrutura ou célula e, portanto, BECNs nunca devem ser vistos.

A modelagem de tráfego ATM é definida para modelar na velocidade de acesso de quadro na extremidade remota, mais taxa de célula. Por exemplo, se a velocidade de acesso for 512 Kbps, o SCR será definido como 512x53/48 = 565 Kbps. Essa taxa de modelagem é usada para maximizar o throughput. Isso é seguro porque a taxa de célula é removida no ponto de IW. A vigilância no lado da portadora está configurada generosamente para que o menor excesso de assinatura seja permitido.

O cRTP é utilizado do outro lado do WAN. O ponto de conexão no que diz respeito à CPU é o roteador de distribuição Cisco 3660 no local central 1. Adicionando os números na tabela acima, determina-se que o número máximo teórico de chamadas VoIP que atravessam esse roteador é de 102 chamadas. Os números de desempenho deste gráfico indicam que a carga da CPU do Cisco 3660 para 100 sessões cRTP (que são comutadas rapidamente) é de aproximadamente 50%.

Gabaritos virtuais são usados com links de WAN com numeração IP. Um modelo virtual é necessário por PVC, o que é possível, pois o número total de PVCs terminados em cada Cisco 3660 é menor que vinte e cinco.

Configurações

Este documento utiliza as seguintes configurações:

• Roteador ATM central

• Roteador de Frame Relay de filial

!--- Note: This section shows the parts of a core Cisco 3660 router !--- configuration that is relevant to MLPoATM.

        
class-map match-all Voice_Stream
  match access-group 100
class-map match-all Voice_Control
  match access-group 101

policy-map toortr01
  class Voice_Stream
    priority 175
  class Voice_Control
   bandwidth 18
   random-detect

interface loopback0
 ip address 10.16.0.105 255.255.255.252

interface ATM2/0
 description To Carrier E3 ATM Service
 no ip address

interface ATM2/0.15 point-to-point
 pvc toortr01 0/58 
  vbr-nrt 406 406
  tx-ring-limit 8
  protocol ppp Virtual-Template15

interface Virtual-Template15
 bandwidth 320
 ip unnumbered loopback0
 ip tcp header-compression iphc-format
 service-policy output toortr01
 ppp multilink
 ppp multilink fragment-delay 14
 ppp multilink interleave
 ip rtp header-compression iphc-format


!--- Note: Do not configure !--- IP addresses directly on any configuration source, !--- such as a virtual template, whenever the possibility !--- exists that this information is cloned to multiple !--- active interfaces. The exception to this rule is the !--- rare case where the intent is to define multiple parallel !--- IP routes and have IP do load balancing between them. !--- If an IP address is present on the configuration source, !--- this IP address is copied to all the cloned interfaces. !--- IP installs a route to each of these interfaces.
 

!--- Note: This section shows the parts of a branch Cisco 2600 router !--- configurations that is relevant to MLPoFR.


class-map match-all Voice_Stream
  match access-group 100
class-map match-all Voice_Control
  match access-group 101

policy-map dhartr21
  class Voice_Stream
    priority 240
  class Voice_Control
   bandwidth 18
   random-detect

interface loopback0
 ip address 10.16.0.106 255.255.255.252

interface Serial0/0
 description To Carrier Frame Relay Service
 encapsulation frame-relay IETF
 frame-relay traffic-shaping

interface Serial0/0.1 point-to-point
 frame-relay interface-dlci 38 ppp Virtual-Template1
  class dhartr21

interface Virtual-Template1
 bandwidth 320
 ip unnumbered loopback0
 max-reserved-bandwidth 85
 service-policy output dhartr21
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave

map-class frame-relay dhartr21
 frame-relay adaptive-shaping becn
 frame-relay cir 320000
 frame-relay bc 3200
 frame-relay mincir 320000

Informações Relacionadas

• VoIP por Frame Relay com qualidade de serviço (fragmentação, modelagem de tráfego, prioridade LLQ/IP RTP)
• VoIP QoS para Frame Relay para Entrelaçamento de ATM com LLQ, PPP LFI e cRTP
• Configurando a fragmentação e interfaceamento de link para Frame Relay e circuitos virtuais ATM
• PPP sobre AAL5, RFC 2364, julho de 1998
• PPP no Frame Relay, RFC1973, junho de 1996
• O PPP Multilink Protocol (MP), RFC 1717, novembro de 1994
• Compactação de cabeçalhos IP/UDP/RTP para links seriais de baixa velocidade, RFC 2508, fevereiro de 1999
• Acordo de Implementação de Interfuncionamento de Serviço de Frame Relay / ATM PVC FRF.8.2
• Acordo de Implementação de Fragmentação Frame Relay FRF.12
• Suporte à Tecnologia de Voz
• Suporte aos produtos de Voz e Comunicação por IP
• Troubleshooting da Telefonia IP Cisco
• Suporte Técnico e Documentação - Cisco Systems