Voz : Voice over Frame Relay (VOFR)

Projetando e implantando o Multilink PPP por Frame Relay e ATM

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Tradução Manual (3 Abril 2008) | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

O Multilink PPP sobre o ATM e o Multilink PPP sobre o Frame Relay (MLPoATM e MLPoFR) foram introduzidos no Software Release 12.1(5)T de Cisco IOS�. Esta característica é visada nos clientes com interconexão do Frame Relay/ATM (FR/ATM IW) que distribuem a Voz sobre IP (VoIP) através do media aos links MACILENTOS de baixa velocidade. Antes desta característica, não havia nenhum esquema de fragmentação comum da camada 2 que foi apoiado pelo Cisco IOS no ATM e nos clientes do Frame Relay com FR/ATM IW foi forçado para fazer a fragmentação da camada 3.

Pré-requisitos

Requisitos

Este documento é pretendido para os equipes de rede de comunicação envolvidos no projeto e no desenvolvimento das redes voip que envolvem o MLPoATM e as redes do Frame Relay. A Cisco recomenda que você tenha conhecimento destes tópicos:

  • Frame Relay

  • ATM

  • PPP

  • MLP

  • Interconexão do Frame Relay/ATM

  • Qualidade de voz da configuração do serviço (QoS)

Este documento não é pretendido fornecer o treinamento de tecnologia nestes assuntos. Uma lista de materiais de referência é incluída no final deste documento. Cisco recomenda que você revê e compreende estes documentos antes de ler este documento:

Componentes Utilizados

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

  • Cisco IOS Software Release 12.1(5)T ou Mais Recente para o MLP sobre FR/ATM IW

  • Cisco IOS Software Release 12.2(2)T ou Mais Recente para o protocolo compressed real-time transport (cRTP) sobre o ATM

  • Cisco IOS Software Release 12.0(7)T para o low latency queueing (LLQ) sobre o Frame Relay e o ATM na interface física

  • Cisco IOS Software Release 12.1(2)T para o LLQ sobre o Frame Relay e o ATM por Circuitos Virtuais Permanentes (PVC)

Os Casos Práticos incluídos neste documento são baseados em uma rede de produção que use este a versão de software e hardware:

  • O Cisco IOS Software Release 12.2(5.8)T da corrida dos Cisco 3660 Router do núcleo. A exigência para o cRTP sobre o ATM dita o uso do Cisco IOS Software Release 12.2T. Este problema conhecido é resolvido no Cisco IOS Software Release 12.2(8)T1:

    A identificação de bug Cisco CSCdw44216 (clientes registrados somente) - cRTP causa a alta utilização da CPU quando o link do Class-Based Weighted Fair Queueing (CBWFQ) /LLQ alcança a congestão.

  • Os Cisco 2620 Router do ramo são em processo do melhoramento do Cisco IOS Software Release 12.2(3) a um 2.2(6a). Cisco 2620s igualmente atua como o ramo Gateways H.323. A elevação é provocada por uma edição gateway-relacionada. Até WAN e as características de QoS são referidos, Cisco IOS Software Release 12.2(3) não exibe nenhuns problemas significativos.

Convenções

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 diversos conceitos de projeto relativos ao projeto e ao desenvolvimento do Multilink PPP sobre o Frame Relay e o ATM.

Carga adicional de enlace de dados

Quando você projeta o ATM e as redes do Frame Relay com MLP, você deve compreender as despesas gerais do link de dados. O overhead tem influência sobre o total de largura de banda que cada chamada de VoIP consome. Igualmente ajuda a determinar o tamanho do fragmento da situação ótima MLP. É crítico aperfeiçoar o tamanho do fragmento para caber um número inteiro de células ATM, especialmente na velocidade lenta PVC onde uma quantidade significativa de largura de banda é desperdiçada no preenchimento de célula. 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 fazem.

Esta tabela mostra as despesas gerais do link 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.

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 Frame Relay ATM ATM Frame Relay Frame Relay ATM ATM Frame Relay
                 
Frame Flag (0x7e) 1 0 0 1 1 0 0 1
Cabeçalho do Frame Relay 2 0 0 2 2 0 0 2
LLC DSAP/SSAP1 (0xfefe) 0 0 2 2 0 2 2 0
Controle LLC (0x03) 1 1 1 1 1 1 1 1
NLPID2 (0xcf para o PPP) 1 1 1 1 1 1 1 1
ID de protocolo MLP (0x003d) 2 2 2 2 2 2 2 2
Número da seqüência MLP 4 4 4 4 4 4 4 4
Protocolo PPP ID (primeiro fragmento somente) 2 2 2 2 2 2 2 2
Payload (Camada 3+) 0 0 0 0 0 0 0 0
Camada de Adaptação ATM (AAL)5 0 8 8 0 0 8 8 0
Seqüência de verificação de estrutura (FCS) 2 0 0 2 2 0 0 2
Carga adicional total (bytes) 15 18 20 17 15 20 20 15

1DSAP/SSAP — Ponto de acesso do serviço de destino/ponto de acesso de serviço de origem.

2NLPID — Network Layer Protocol Identification.

O PVC translational é o mais fácil de compreender porque as despesas gerais são as mesmas nos ambos sentidos. Isto é porque o dispositivo FRF.8 traduz entre os formatos MLPoATM e MLPoFR. Em consequência, o formato de frame é MLPoFR no trecho do Frame Relay nos ambos sentidos. O formato no trecho de ATM é MLPoATM nos ambos sentidos.

O PVC transparente está ligeiramente mais conturbado porque a carga adicional é diferente nos dois sentidos. Esta complexidade elevara porque o Frame Relay Router envia pacotes no formato MLPoFR. Este formato é levado transversalmente pelo dispositivo IW no lado ATM. Similarmente, o ATM Router envia pacotes no formato MLPoATM. Este formato é levado transversalmente pelo dispositivo IW no lado do Frame Relay. Portanto, o resultado são formatos de quadro diferentes nas duas direções de cada trecho.

Em comparação, as despesas gerais em um Frame Relay de ponta a ponta PVC que use o FRF.12 são 11 bytes. Consequentemente, em um link de Frame Relay de ponta a ponta, o FRF.12 é uma escolha dos mais eficiente para o Link Fragmentation and Interleaving (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. Contudo, o ATM fim-a-fim VC é médio à alta velocidade. Consequentemente, o LFI não é exigido. A exceção a esta regra é a velocidade lenta ATM VC sobre o digital subscriber line (DSL).

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

A tabela aqui mostra as despesas gerais do link 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. O principal diferença entre uns dados e um pacote voip é que os pacotes voip estão enviados como pacotes PPP e não como pacotes de MLP. Todos aspectos restantes são idênticos à encenação dos dados.

Modo FRF.8 Transparente Tradução Frame Relay para Frame Relay
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 Frame Relay ATM ATM Frame Relay Frame Relay ATM ATM Frame Relay  
                   
Frame Flag (0x7e) 1 0 0 1 1 0 0 1 1
Cabeçalho do Frame Relay 2 0 0 2 2 0 0 2 2
LLC DSAP/SSAP (0xfefe) 0 0 2 2 0 2 2 0 0
Controle LLC (0x03) 1 1 1 1 1 1 1 1 1
NLPID (0xcf for PPP) 1 1 1 1 1 1 1 1 1
ID de PPP 2 2 2 2 2 2 2 2 0
Payload (IP+protocolo de datagrama de usuário (UDP)+RTP+voz) 0 0 0 0 0 0 0 0 0
AAL5 0 8 8 0 0 8 8 0 0
FCS 2 0 0 2 2 0 0 2 2
Carga adicional total (bytes) 9 12 14 11 9 14 14 9 7

Em comparação, o link de dados aéreo para um pacote voip em um Frame Relay de ponta a ponta PVC é mostrado na coluna do extrema direita.

Requisitos de largura de banda VoIP

Quando você provision a largura de banda para VoIP, as despesas gerais do link de dados devem ser incluídas nos cálculos de largura de banda. Esta tabela mostra por exigências da largura de banda de chamada para os vários sabores de VoIP. É baseada nas características do PVC. Os cálculos nesta tabela supõem uma encenação do melhor-caso para o cRTP (por exemplo, nenhum checksum de UDP e nenhum erro de transmissão.) Os encabeçamentos são comprimidos então consistentemente 40 bytes a 2 bytes.

Modo FRF.8 Transparente Tradução Frame Relay para Frame Relay
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 Frame Relay ATM ATM Frame Relay Frame Relay ATM ATM Frame Relay  
                   
G.729 - 20 Senhora amostras - nenhum cRTP 27.6 42.4 42.4 28.4 27.6 42.4 42.4 27.6 26.8
G.729 - 20 Senhora amostras - cRTP 12.4 21.2 21.2 13.2 12.4 21.2 21.2 12.4 11.6
G.729 - 30 Senhora amostras - nenhum cRTP 20.9 28.0 28.0 21.4 20.9 28.0 28.0 20.9 20.3
G.729 - 30 Senhora amostras - cRTP 10.8 14.0 14.0 11.4 10.8 14.0 14.0 10.8 10.3
G.711 - 20 Senhora amostras - nenhum cRTP 83.6 106.0 106.0 84.4 83.6 106.0 106.0 83.6 82.8
G.711 - 20 Senhora amostras - cRTP 68.4 84.8 84.8 69.2 68.4 84.8 84.8 68.4 67.6
G.711 - 30 Senhora amostras - nenhum cRTP 76.3 97.9 97.9 76.8 76.3 97.9 97.9 76.3 75.8
G.711 - 30 Senhora amostras - cRTP 66.3 84.0 84.0 66.8 66.3 84.0 84.0 66.3 65.7

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 amostra e cRTP de 20 milissegundos (milissegundo) através de 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 abastecimento precisa de ser feito com o pressuposto de 13.2 kbps pelo atendimento.

Em comparação, o requisito de largura de banda voip em um Frame Relay de ponta a ponta PVC é mostrado igualmente na coluna do extrema 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. Consequentemente, o Encapsulamento frame relay com FRF.12 faz mais sentido do que o MLP em um Frame Relay de ponta a ponta VC.

Nota: o cRTP sobre o ATM exige o Cisco IOS Software Release 12.2(2)T ou Mais Recente.

Aperfeiçoe o tamanho de fragmentação

A razão usar o MLP em um Frame Relay/ATM PVC é permitir grandes pacotes de dados ser fragmentado em pedaços menores. O roteador expede então pacotes voip intercalando os entre os fragmentos de dados. No Cisco IOS, o tamanho de fragmentação não é configurado diretamente. Em lugar de, o retardo desejado é configurado com a ajuda do comando ppp multilink fragment-delay. O Cisco IOS usa então esta fórmula para calcular o tamanho do fragmento apropriado:

fragment size = delay x bandwidth/8

Quando você faz o MLP através do ATM, o tamanho do fragmento precisa de ser aperfeiçoado de modo que caiba em um número inteiro de pilhas. Se esta otimização não é feita, a largura de banda exigida pode quase dobrar devido a acolchoar. Por exemplo, se cada fragmento é 49 bytes por muito tempo, duas células ATM são exigidas levar cada fragmento. Consequentemente, 106 bytes são usados para levar um payload de somente 49 bytes.

O Cisco IOS aperfeiçoa automaticamente o tamanho do fragmento para usar um número inteiro de células ATM quando executa o MLPoATM e o MLPoFR. O Cisco IOS arredonda automaticamente acima o tamanho do fragmento calculado ao número inteiro seguinte de células ATM. Nenhum comando CLI novo é adicionado. O Cisco IOS executa esta otimização no Frame Relay e em fins ATM de um MLPoFR/ATM PVC. É possível que um MLP PVC pode ser Frame Relay de ponta a ponta. Neste caso, aperfeiçoá-lo para o ATM não é exigido. Contudo, o Cisco IOS aperfeiçoa esta encenação para o ATM desde que não tem nenhuma maneira de detectar se a extremidade remota é ATM ou Frame Relay.

Nota: Devido ao arredondamento, o atraso que resulta pode ser levemente mais alto do que aquele configurado. Este erro redondo é mais significativo em PVC de baixa velocidade.

Você pode igualmente configurar a otimização manualmente. Desde que o tamanho do fragmento não pode ser especificado diretamente no Cisco IOS, calcular o tamanho do fragmento ótimo e o converter em um atraso. Quando você calcula o tamanho do fragmento, ajuste para as despesas gerais do link de dados, como o código MLP supõe que cada link é High-Level Data Link Control (HDLC) e tem 2 bytes de despesas gerais do link de dados. Além do que a carga adicional de link de dados HDLC, o código MLP inclui em seus cálculos que os 8 bytes compuseram do ID de MLP, no número de sequência MLP, e no ID de PPP de acordo com a primeira tabela acima.

Use este procedimento a fim 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 de células é:

    fragment_aligned = (int(fragment/48)+1)*48
  3. Ajuste o overhead do enlace de dados que não foi considerado pelo MLP.

    Como considerado mais cedo, estas despesas gerais diferem baseado nas características PVC. Considere o lado ATM do PVC porque este é o lado para que você aperfeiçoa. Esta tabela mostra o número de bytes de despesas gerais do link 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 no tamanho do fragmento em que o MLP baseia seus cálculos, subtraia as despesas gerais do link de dados do tamanho do fragmento alinhado de células desejado. Adicionar para trás 2 bytes a fim compensar o encapsulamento de HDLC que o MLP supõe sempre.

    A fórmula para calcular o tamanho do fragmento que os alvos do código MLP são:

    fragment_mlp = fragment_aligned - datalink_overhead + 2
  4. Converta o tamanho do fragmento que resultados 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 inteiro de milissegundos. Como o Cisco IOS aceita apenas um valor inteiro, você deve arredondar para baixo. Consequentemente, 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. A fim compensar o erro redondo acima, falsifique a largura de banda usada pelo MLP para converter do atraso para fragmentar. A largura de banda falsificada que você configura no Cisco IOS com a ajuda do comando bandwidth é:

    bandwidth = fragment_mlp/fragment_delay * 8

Esta tabela mostra os valores ótimo do ppp multilink fragment-delay e a largura de banda para as velocidades as mais comuns PVC. Um atraso de destino de 10 msec é pressuposto. A fim simplificar a tabela, os cálculos não se diferenciam entre o PVC transparente e translational, ou 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. Igualmente é mostrado na tabela o atraso “real” que é encontrado devido ao fato de que você aumenta o tamanho do fragmento de modo que os fragmentos cabidos em um número inteiro de pilhas.

Velocidade do PVC Tamanho do fragmento retardo de fragmentação do multilink ppp Largura de banda Real Delay
(Kbps) (cells) (ms) (Kbps) (ms)
56 2 12 57 13.7
64 2 10 68 12.0
128 4 11 132 12.0
192 6 11 202 12.0
256 7 10 260 10.5
320 9 10 337 10.8
384 11 10 414 11.0
448 12 10 452 10.3
512 14 10 529 10.5
576 16 10 606 10.7
640 17 10 644 10.2
704 19 10 721 10.4
768 21 10 798 10.5

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

A consideração especial é dada ao modelagem de tráfego e ao policiamento em um ambiente do 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. Consequentemente, cada assunto é descrito separadamente.

A questão principal no Frame Relay à direção de ATM é a expansão potencial no consumo de largura de banda ao ir do quadro à pilha. Por exemplo, um frame de bytes 49 no lado do Frame Relay consome duas pilhas, ou 106 bytes, no lado ATM. Consequentemente, não se pode supor que a taxa de célula sustentável (SCR) iguala a taxa de informação comprometida (CIR). O cenário do pior caso ocorre quando cada quadro do Frame Relay contém 1 byte de payload. Cada um destes bytes consome uma célula de byte 53 completa no lado ATM. Como exemplo deste conceito, esta encenação extrema e fantasiosa dita um SCR que seja 53 vezes o CIR. Dois mais exemplos realistas são:

  • Um pacote voip de G.729 é 60 bytes por muito tempo, ou 69 bytes (quando o MLP e as despesas gerais do Frame Relay são incluídos). No trecho de ATM, consome duas pilhas ou 106 bytes. Consequentemente, se todo o tráfego levado é VoIP, a seguir um mapeamento apropriado é SCR = 106/69 = 1.5 x CIR.

  • Um pacote de Telnet que leve uma única introdução por teclado contém 40 bytes do cabeçalho TCP/IP e do 1 byte de dados. No lado do Frame Relay, isso totaliza 56 bytes, incluindo a sobrecarga. Contudo, no lado ATM este pacote expande a duas pilhas. Neste caso, SCR = 106/56 = 1.9 x CIR.

O apêndice A do padrão de foro ATM, a versão de especificação inter 2.0 da interface de portadora BISDN (B-ICI), descreve dois métodos do mapeamento entre o SCR e o CIR. Quando ambos fornecerem uma maneira científica derivar o SCR do CIR, nenhum um é any more exato do que os dados a que são aplicados. Um dos números exigidos pelas fórmulas é o tamanho do frame típico, um número que seja duro de determinar em uma rede real. Também, um número que possa potencialmente mudar enquanto os aplicativos novos são desenrolados em uma rede de Frame Relay existente do ATM/Frame. 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 ajuda do portador, esta aproximação à prova de falhas é possível:

  • Frame Relay à direção de ATM - No Frame Relay à direção de ATM, o portador precisa de policiar o tráfego de entrada no ponto do Frame Relay Ingress somente. Por exemplo, no Frame Relay Switch conectado ao dispositivo anexado Frame Relay do Customer Premises Equipment (CPE), o portador policia o tráfego de acordo com o CIR contratante. Esta política de vigilância é ilustrada na figura aqui. Nenhum policiamento mais adicional deve acontecer uma vez que o tráfego é permitido na rede no ponto de ingresso. 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 de ATM exigida é menos de duas vezes a largura de banda do Frame Relay usada.

    http://www.cisco.com/c/dam/en/us/support/docs/voice/voice-over-frame-relay-vofr/25084-ingress-policing.gif

  • Sentido do ATM para Frame Relay - No sentido do ATM para Frame Relay, o oposto é experiente. 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. Contudo, porque o potencial transmite a taxa do lado ATM é muito mais alta do que aquela do Link do Frame Relay, estabelecendo o modelagem de tráfego corretamente no ATM Router é crítica para a integridade da Voz. Se dar forma está demasiado fraco, a seguir o ATM Router alimenta dados em uma taxa mais rapidamente do que a velocidade física do Link do Frame Relay no extremo oposto. Em consequência, os pacotes começam enfileirar-se acima no interruptor FRF.8. Em algum momento, os pacotes começam deixar cair. e desde que as redes de Frame Relay do ATM/Frame não distinguem entre a Voz e os dados, os pacotes voip são deixados cair igualmente.

    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. Não consome a largura de banda no Link do Frame Relay. Consequentemente, você pode oversubscribe o lado ATM do PVC levemente. 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. Porque você não pode exatamente qualificar estas despesas gerais, você é uma tentativa mais em melhor situação aperfeiçoar para ela. Por outro lado, a taxa de célula é completamente determinística. É os bytes 5 para cada 48 bytes de payload. Você pode aperfeiçoar para a taxa de célula ajustando o alvo dando forma no ATM Router a 53/48 de x SCR. O policiamento no lado de portadora deve ser ajustado para permitir esta pequena oversubscription.

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 serviço-política pode fazer com que a característica não trabalhe. Um exemplo deste é documentado na identificação de bug Cisco CSCdu19313 (clientes registrados somente).

  • MLPoATM/Frame Relay faz a clonagem de duas interfaces de acesso virtual para cada PVC. Um destes representa o link de PPP. O outro representa o conjunto MLP. O comando show ppp multilink é usado dizer qual é qual. Os links múltiplos de PPPoFR pelo pacote não são apoiados. Pôr dois circuitos PPPOFR em um tráfego do pacote não será carga equilibrada bem através dos circuitos, desde que o direcionador PPPOFR não fornece a sinalização do controle de fluxo que os direcionadores de série reais fazem. O Balanceamento de carga MLPPP sobre o ATM ou o Frame Relay pôde mostrar visivelmente 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 o fancy queuing permitido. Outras três relações devem ter primeiramente dentro, primeiramente para fora (FIFO) enfileirar-se.

  • Quando você aplica um comando service-policy a um virtual-molde, o Cisco IOS indica este mensagem de advertência 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 recomenda que uma serviço-política não está apoiada na interface de acesso virtual PPP. A segunda mensagem confirma que a serviço-política tomou o efeito na interface de acesso virtual do conjunto MLP. Este fato é verificado com a ajuda do acesso virtual das relações da mostra, da fila da mostra e dos comandos show policy-map interface verificar o mecanismo de filas.

  • A autenticação de PPP não é exigida restritamente desde que um PVC é como uma linha alugada. Contudo, a autenticação de PPP é acessível porque o comando show ppp multilink é usado então determinar o nome do roteador no outro extremo do PVC.

  • O Formatação de tráfego frame relay deve ser permitido para MLPoFR PVC no Frame Relay Router.

  • O Cisco IOS Software Release 12.2 apoiou inicialmente um máximo de twenty-five moldes virtuais pelo roteador. Esta limitação pode impactar a escala de um roteador de distribuição ATM se cada PVC é exigido para ter um endereço IP exclusivo. A ação alternativa para versões afetadas é usar o IP unnumbered ou usar interfaces do discador em vez dos moldes virtuais. No Cisco IOS Software Release 12.2(8)T, o apoio é aumentado a 200 moldes virtuais.

  • Alguns provedores de serviço ainda não suportam a conversão do PPP em seus dispositivos FRF.8. Sempre que esta limitação é no lugar, os fornecedores devem configurar seus PVC 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 secundário-relação não serve nenhuma finalidade. O molde virtual deve apenas ser anexado à interface física. O resultado é um mais compacto e configuração gerenciável. Isto é especialmente importante se há um grande número PVC.

  • Use o comando show ppp multilink como uma maneira à prova de idiotas de determinar se há alguma gota da pilha/quadro no lado de 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 seja introduzido no Cisco IOS Software Release 12.1(5)T, os erros no este e as versões subsequente ditam esse cuidado sejam tomados quando você seleciona o Cisco IOS Software Release. Cisco recomenda usar a versão de manutenção a mais atrasada do grosso da população do Cisco IOS 12.2. Contudo, outros requisitos de recurso de VoIP podem ditar o uso de um Cisco IOS Software Release diferente, tal como 12.2(2)XT se o Survivable Remote Site Telephony (SRST) é exigido. Esta tabela alista alguns dos problemas conhecidos. Quando você seleciona o Cisco IOS, cada identificação de bug Cisco deve ser avaliada contra os IO escolhidos.

ID de bug da Cisco Descrição
CSCdt09293 (clientes registrados somente) LFI- interruptor rápido em 7200 chamadas de voz da maneira das causas uma.
CSCdt25586 (clientes registrados somente) Flapping ou Circuito Virtual Comutado(SVC) do acesso PPPoA não rasgado para baixo no idle timeout.
CSCdt29661 (clientes registrados somente) MLP- a parada programada da interface ATM durante o interruptor rápido causa um crash o roteador.
CSCdt53065 (clientes registrados somente) Melhoria de desempenho no código do atm_lfi para a característica ATM LFI.
CSCdt59038 (clientes registrados somente) MLPoATM: Sibilo com grande falha dos pacotes no PA-A3.
CSCdu18344 (clientes registrados somente) A taxa de transferência MLPoATM/PVC do Frame Relay é menos do que a metade do SCR/CIR.
CSCdu19297 (clientes registrados somente) O MLPoATM PVC sem política de serviços gera erros.
CSCdu41056 (clientes registrados somente) MLPoATM: Rotina do vc_soutput do direcionador que obtém chamada duas vezes.
CSCdu44491 (clientes registrados somente) VirtualAccess opõe incorreto no MLPoFR.
CSCdu51306 (clientes registrados somente) Keepalives quebrado em PPPoX.
CSCdu57004 (clientes registrados somente) O CEF não trabalha com MLP.
CSCdu84437 (clientes registrados somente) A aplicação do controle de fluxo entre o MLP e o TX-anel ajustou direcionadores.
CSCdv03443 (clientes registrados somente) Comprometa o reparo para u76585 no Software Release 12.2 de Cisco IOS� - os pacotes de MLP recebidos são processo comutado.
CSCdv10629 (clientes registrados somente) MLPoATM: Os pacotes de voz não são enfileirados no LLQ.
CSCdv20977 (clientes registrados somente) Os pacotes de MLP recebidos estão obtendo o processo comutado.
CSCdw44216 (clientes registrados somente) o cRTP causa a alta utilização da CPU quando o link CBWFQ/LLQ alcança a congestão.
CSCdy70337 (clientes registrados somente) Quando uns conjuntos MLP com política de serviços de QoS estiverem no uso.
CSCdx71203 (clientes registrados somente) Um conjunto MLP pôde ocasionalmente ter alguns links inativos.

Casos Práticos

Introdução

Esta seção descreve uma das primeiras implantações de cliente do recurso MLPoATM/Frame Relay. O cliente é referido XYZ Ltd do nome fictício. Em 2001, XYZ Ltd substituiu seus PBX com uma solução de telefonia do IP. Como parte deste projeto, uma rede IP nova foi construída. e a interconexão do Frame Relay/ATM foi escolhida para WAN. O portador que proporciona o serviço MACILENTO usa o Switches de Newbridge para entregar o ATM e os serviços do Frame Relay.

Visão geral da rede

A rede XYZ Ltd é uma rede de hub and spoke que conecte vinte e seis ramos com as duas sites central. 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. Têm os PVC do Frame Relay duplos que conectam de volta ao 3660s nas duas sites central através do relé IW do ATM/Frame. Os oito ramos permanecendo são muito pequenos. Conectam de volta ao ramo de tamanho médio o mais próximo através de um Frame Relay único PVC. Todo o Roteadores secundários é Cisco 2620. Um ATM fim-a-fim PVC conecta os dois 3660 Router nas duas instalações de hub. Esta figura ilustra a topologia.

http://www.cisco.com/c/dam/en/us/support/docs/voice/voice-over-frame-relay-vofr/25084-network.gif

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

Local Site remoto Alcance (kbps) CIR (kbps) Número de Chamadas
Filial 1 Núcleo 1 320 192 6
Ramo 2 Ramo 22 128 64 2.0
Ramo 3 Núcleo 1 576 256 8.0
Ramo 4 Ramo 16 64 32 2.0
Ramo 5 Núcleo 1 128 64 2.0
Ramo 6 Ramo 3 64 32 2.0
Ramo 7 Núcleo 1 512 256 8.0
Ramo 8 Núcleo 1 512 256 8.0
Ramo 9 Ramo 13 128 256 2.0
Ramo 10 Núcleo 1 256 128 4,0
Ramo 11 Núcleo 2 128 96 2.0
Ramo 12 Núcleo 1 128 64 2.0
Ramo 13 Núcleo 1 768 256 12.0
Ramo 14 Núcleo 1 192 96 4,0
Ramo 15 Núcleo 1 192 96 4,0
Ramo 16 Núcleo 1 448 192 8.0
Ramo 17 Ramo 13 128 64 2.0
Ramo 18 Núcleo 1 128 96 2.0
Ramo 19 Ramo 16 128 64 2.0
Ramo 20 Núcleo 1 64 32 2.0
Núcleo 2 Núcleo 1 34000 256 12.0
Ramo 21 Ramo 13 128 64 2.0
Ramo 22 Núcleo 1 384 192 6.0
Ramo 23 Núcleo 1 512 256 8.0
Ramo 24 Núcleo 1 192 96 2.0
Ramo 25 Núcleo 1 128 96 4,0
Ramo 26 Filial 1 64 32 2.0

A modelagem de tráfego de Frame Relay é desempenhada pelos roteadores de filial. A intermitência além de CIR é permitida. O Cisco IOS Traffic Shaping é ajustado para dar forma à velocidade de acesso, com o mincir igual ao CIR. Se as notificações de congestionamento explícitas inversa (BECN) são recebidas do portador, então o roteador estrangula de volta ao mincir. Esta aproximação está contra recomendações da Cisco ao fazer o VOIP sobre o Frame Relay. A Voz está já no problema antes que o roteador responder à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 é 512 kbps, a seguir o SCR é ajustado a 512x53/48 = 565 kbps. Esta taxa moldada é usada para maximizar a taxa de transferência. Isto é seguro porque a taxa de célula é descascada no ponto 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 ativo tanto quanto o CPU é o roteador de distribuição do Cisco 3660 na site central 1. Adicionando os números na tabela acima, determina-se que a teórica máxima de número de chamadas VoIP que atravessam este roteador é 102 atendimentos. Os números de desempenho deste gráfico indicam que a carga de CPU do Cisco 3660 para 100 sessões cRTP (que são comutadas rapidamente) é aproximadamente por cento dos 50 pés.

http://www.cisco.com/c/dam/en/us/support/docs/voice/voice-over-frame-relay-vofr/25084-3660-performance.gif

Gabaritos virtuais são usados com links de WAN com numeração IP. Um molde virtual é exigido pelo PVC que é possível desde que o número total de PVC que terminam em cada Cisco 3660 é menos de twenty-five.

Configurações

Este documento utiliza as seguintes configurações:

Roteador ATM central

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

Roteador de Frame Relay de filial

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

Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Informações Relacionadas


Document ID: 25084