Reúna estatísticas sobre sessões MPLS

Importância de medir a perda e o atraso de pacotes

O aumento de aplicativos que consomem largura de banda, como IPTV e vídeo móvel, juntamente com a pressão para minimizar o custo por bit e maximizar o valor por bit, está forçando as operadoras a fazer a transição de suas redes de transporte de tecnologias baseadas em circuito para tecnologias baseadas em pacotes. O MPLS é uma tecnologia de transporte de pacotes amplamente bem sucedida e orientada por conexão que é ideal para redes de transporte baseadas em pacotes.

Com o surgimento de novos aplicativos em redes de dados, é cada vez mais importante que os provedores de serviços prevejam com precisão o impacto das implantações de novos aplicativos. Entender e modelar o desempenho da rede na rede é especialmente relevante para a implantação de aplicativos de novo mundo para garantir implementações bem-sucedidas. Nas redes de pacotes, a perda e o atraso de pacotes são duas das medidas mais fundamentais de desempenho. Seu papel é ainda mais central quando se trata de medições de ponta a ponta.

O tráfego que pertence à maioria dos aplicativos de usuário de ponta a ponta é sensível à perda (transferência de arquivos), sensível a atrasos (aplicativos de voz ou vídeo) ou ambos (aplicativos interativos de computação). Os acordos de nível de serviço (SLAs) dos provedores de serviços dependem da capacidade de medir e monitorar essas métricas de desempenho da rede, pois os SLAs são diretamente ou indiretamente dependentes da perda e atrasam as experiências de tráfego do cliente na rede do provedor de serviços.

Para garantir a conformidade com o SLA, os provedores de serviços precisam de ferramentas para medir e monitorar as métricas de desempenho para perda de pacotes, atraso de uma via e atraso de duas vias, além de métricas relacionadas, como variação de atraso e transferência de canal. Esse recurso de medição oferece aos provedores de serviços uma maior visibilidade das características de desempenho de suas redes, facilitando assim o planejamento, a solução de problemas e a avaliação do desempenho da rede.

Definição de perda de pacotes, atraso e transferência

Nas redes de pacotes, a perda e o atraso de pacotes são duas das medidas mais fundamentais de desempenho.

• Loss— A perda de pacotes é a falha de um ou mais pacotes transmitidos para chegar ao seu destino. A perda de pacotes refere-se aos pacotes de dados que são descartados pela rede para gerenciar o congestionamento.

  Os aplicativos de dados são muito tolerantes à perda de pacotes, pois geralmente não são sensíveis ao tempo e podem retransmitir os pacotes que foram descartados. No entanto, em ambientes de videoconferência e comunicações de áudio puro, como VoIP, a perda de pacotes pode criar jitter.

• Delay— O atraso no pacote (também chamado de latência) é o tempo necessário para que um pacote de dados chegue de um ponto designado para outro, dependendo da velocidade do meio de transmissão, como fio de cobre, fibra óptica ou ondas de rádio, e os atrasos na transmissão por dispositivos ao longo do caminho, como roteadores e modems.

  Uma baixa latência indica uma alta eficiência de rede.

• Throughput— O atraso no pacote mede o tempo entre o início de uma ação e sua conclusão, enquanto a taxa de transferência é o número total de ações que ocorrem em um determinado período de tempo.

Mecanismos de medição de perda e atraso de pacotes

Atraso e perda de pacotes são duas medidas fundamentais de desempenho da rede. O Junos OS fornece um mecanismo sob demanda para medir a perda de pacotes e o atraso em relação aos caminhos de comutada por rótulos (LSPs) mpls bidirecionais associados.

O mecanismo de medição de atraso sob demanda e perda de pacotes é iniciado usando os seguintes comandos CLI:

• monitor mpls loss rsvp— Realiza uma medição de perda sob demanda para LSPs UHP bidirecionais associados.

• monitor mpls delay rsvp— Realiza uma medição de atraso sob demanda para LSPs UHP bidirecionais associados.

• monitor mpls loss-delay rsvp— Realiza uma medição combinada de perda e atraso sob demanda para LSPs UHP bidirecionais associados.

Para iniciar o mecanismo de medição de atraso e perda de pacotes, os parâmetros desejados para medição, como o tipo de medição e o nome LSP, precisam ser inseridos. Ao receber os parâmetros, um resumo dos dados de monitoramento de desempenho é exibido e o mecanismo é encerrado.

Métricas de perda e atraso de pacotes

As métricas de desempenho a seguir são medidas usando os mecanismos de perda de pacotes sob demanda e atraso:

• Medição de perda (pacote e octeto)

• Medição de taxa de transferência (pacote e octeto)

• Atraso no canal de duas vias

• Atraso na viagem de ida e volta

• Variação de atraso entre pacotes (IPDV)

O monitor mpls loss rsvp comando executa a medição de perda e taxa de transferência, e o monitor mpls delay rsvp comando executa o atraso de canal de duas vias, atraso de ida e volta e medições de IPDV. O monitor mpls loss-delay rsvp comando executa uma medição combinada de perda e atraso e mede todas as métricas de desempenho acima mencionadas simultaneamente.

Conceitos de medição de perda e atraso de pacotes

Os conceitos a seguir ajudam a entender melhor a funcionalidade de perda e atraso de pacotes:

• Querier— Um querier é o roteador de borda de provedor de entrada (PE), que origina a mensagem de consulta para medição de perda ou atraso.

• Responder— Um respondente é o roteador PE de saída, que recebe e responde às mensagens de consulta de um querier.

• Associated bidirectional LSP— Um LSP bidirecional associado consiste em dois LSPs unidirecionais que estão vinculados (ou associados uns aos outros) por meio da configuração em ambos os pontos finais do LSP.

  A medição de perda e atraso sob demanda só pode ser realizada em LSPs UHP bidirecionais associados.

• Generic associated channel (G-Ach)— As mensagens de monitoramento de desempenho para a perda sob demanda e o fluxo de medição de atraso sobre o MPLS G-Ach. Esse tipo de canal oferece suporte apenas a respostas na banda e não oferece suporte para modos fora de banda ou sem resposta.

• Measurement point (MP)— MP é o local em que uma condição é descrita para a medição.

  O MP para perda de pacotes no lado de transmissão é entre a malha de comutação e a interface de transmissão. O valor do contador está carimbado na mensagem de medição de perda no hardware antes de ser enfileirado para transmissão.

  O MP para perda de pacotes no lado de recebimento está entre a interface de recebimento e a malha de comutação. O MP é distribuído no lado de recebimento. Além disso, quando a interface de transmissão é uma interface agregada, o MP também é distribuído.

• Query rate— A taxa de consulta é o intervalo entre duas consultas enviadas para medição de perda e atraso.

  Como as mensagens de medição de perda e atraso se originam do Mecanismo de Roteamento, uma alta taxa de consulta para vários canais coloca um pesado fardo no Mecanismo de Roteamento. O intervalo mínimo de consulta suportado é de 1 segundo.

  A taxa de consulta deve ser alta para contadores de 32 bits, porque os contadores podem terminar rapidamente quando a taxa de tráfego de dados é muito alta. A taxa de consulta pode ser baixa quando contadores de 64 bits estão em uso em todos os quatro locais de ponto de medição envolvidos na medição da perda. O Junos OS oferece suporte a apenas contadores de 64 bits.

• Traffic class— Por padrão, a medição da perda é suportada para todo o canal. O Junos OS também oferece suporte à medição de perda de pacotes em escopo de classe de tráfego, onde contadores que mantêm as estatísticas de tráfego de dados por classe de tráfego precisam ser criados.

  Os contadores de classe de tráfego não são criados por padrão. Para configurar a medição de perda em escopo de classe de tráfego, inclua a traffic-class-statistics declaração no nível de [edit protocols mpls statistics] hierarquia.

  Quando traffic-class-statistics está configurado, os pacotes de controle que fluem sobre o G-Ach não são contados nos contadores de transmissão e recebimento.

  Nota:

  A habilitação e desativação das estatísticas da classe de tráfego resulta na redefinição de todos os contadores (contador agregado e contadores por classe) para os LSPs.

• Loss measurement mode— O Junos OS oferece suporte ao modo direto de medição de perda sob demanda e não oferece suporte para o modo inferido.

  A medição de perda direta requer que as estatísticas de tráfego de dados sejam mantidas na entrada e saída de dois LSPs unidirecionais do LSP bidirecional associado. Quando um roteador da Série MX está usando apenas MPCs e MICs, contadores para manter as estatísticas de tráfego de dados são criados por padrão na entrada de todos os tipos de LSPs e saídas de LSPs UHP.

  No entanto, a medição do modo direto de perda não é totalmente precisa devido aos seguintes motivos:

  • Natureza de encaminhamento paralelo do hardware.

  • Presença de multicaminho de custo igual (ECMP) na rede, como interfaces Ethernet agregadas, o que pode resultar na reordenação de pacotes de dados em relação às mensagens de medição de perda.

  • Os pacotes de controle que não fluem sobre G-Ach não são contados na entrada do LSP, mas são contados na saída do LSP.

  • A reordenação de tráfego de dados em relação à mensagem de medição de perda quando um Diffserv é implementado na rede MPLS e o escopo de medição de perda é o canal completo e não a classe de tráfego escopo.

    Para superar essa limitação, execute a medição de perda em escopo de classe de tráfego quando um Diffserv for implementado.

  Nota:

  A medição de perda de modo direto é vulnerável à interrupção quando a interface de entrada ou saída associada às alterações de LSP.

• Loss measurement synchronization— As condições de sincronização especificadas na seção 2.9.8 do RFC 6374 não se mantêm verdadeiras no sentido absoluto. No entanto, como os contadores de medição de perda são carimbados no hardware, os erros introduzidos devido a não satisfazer as condições de sincronização são relativamente pequenos. Esses erros precisam ser quantificados.

  Quando a interface de transmissão ou recebimento do LSP é uma interface agregada, mais erros são introduzidos em comparação com quando as interfaces são interfaces não agregadas. De qualquer forma, os contadores de medição de perda estão carimbados no hardware, e o erro precisa ser quantificado.

• Delay measurement accuracy— Quando as interfaces de transmissão e recebimento residem em diferentes mecanismos de encaminhamento de pacotes, o relógio deve ser sincronizado nestes Mecanismos de encaminhamento de pacotes para medições de atraso de duas vias. Essa condição vale para a plataforma na qual o recurso de medição de atraso sob demanda é implementado.

  Quando existem interfaces agregadas ou ECMP, o atraso é medido para apenas um dos caminhos potenciais.

  Quando uma mensagem combinada de perda e atraso é usada para cálculo de atraso, a precisão do atraso é menor em comparação com quando a mensagem de medição de atraso é usada em alguns casos, como quando a interface de transmissão ou recebimento é uma interface agregada.

  A medição de atraso é sempre realizada em cada classe de tráfego, e a precisão da medição precisa ser quantificada após o teste.

• Timestamp format— O Junos OS oferece suporte apenas ao formato IEEE 1588 Precision Time Protocol (PTP) [IEEE1588] para registrar mensagens de medição de atraso. O formato de tempo de rede (NTP) não é suportado.

• Operations, administration, and maintenance (OAM)— Para indicar que todas as mensagens OAM para LSPs MPLS fluem sobre o MPLS G-Ach, e para permitir que as mensagens de monitoramento de desempenho do MPLS sejam transmitidas pelo MPLS G-Ach, a oam mpls-tp-mode declaração deve ser incluída no [edit protocols mpls label-switched-path lsp-name] nível hierárquica.

Funcionalidade de medição de perda e atraso de pacotes

Figura 1 ilustra os métodos básicos usados para a medição bidirecional de perda e atraso de pacotes. Existe um canal bidirecional entre os dois roteadores, o Roteador A e o Roteador B. Os pontos de referência temporal — T1, T2, T3 e T4 — estão associados a uma operação de medição que ocorre no Roteador A. A operação consiste no envio de uma mensagem de consulta ao roteador B e ao roteador B, enviando uma resposta de volta. Cada ponto de referência indica o ponto de tempo em que a consulta ou a mensagem de resposta são transmitidas ou recebidas pelo canal.

Figura 1: Medição bidirecional básica

In Figura 1, o roteador A pode organizar para medir a perda de pacotes no canal nas direções de encaminhamento e reversão, enviando mensagens de consulta de medição de perda para o roteador B. Cada uma das mensagens de encaminhamento e reversão contém a contagem de pacotes transmitidos antes do tempo T1 pelo canal para o roteador B (A_TxP).

Quando a mensagem chega ao Roteador B, dois valores são anexadas à mensagem e a mensagem é refletida de volta ao Roteador A. Os dois valores são a contagem de pacotes recebidos antes do tempo T2 pelo canal do Roteador A (B_RxP) e a contagem de pacotes transmitidos antes do tempo T3 pelo canal para o Roteador A (B_TxP).

Quando a resposta chega ao Roteador A, um quarto valor é anexada à mensagem – a contagem de pacotes recebidos antes do tempo T4 pelo canal do Roteador B (A_RxP).

Esses quatro valores contrários — (A_TxP), (B_RxP), (B_TxP) e (A_RxP) — permitem que o Roteador A compute as estatísticas de perda desejadas. Como a contagem de transmissões no Roteador A e a contagem de recebimento no Roteador B (e vice-versa) podem não ser sincronizadas no momento da primeira mensagem e, para limitar os efeitos do contra-envoltório, a perda é computada na forma de um delta entre as mensagens.

A perda de transmissão (A_TxLoss[n-1,n]) e a perda de recebimento (A_RxLoss[n-1,n]) no intervalo de medição marcado pelas mensagens LM[n-1] e LM[n] são computadas pelo roteador A da seguinte forma:

1. A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])

2. A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])

A aritmética é modulo do tamanho do balcão.

Para medir no Roteador A o atraso no canal para o roteador B, uma mensagem de consulta de medição de atraso é enviada do Roteador A ao Roteador B contendo um data e hora em que é transmitido. Em Figura 1, o temporizador é registrado em T1.

Quando a mensagem chega ao Roteador B, um ponto de tempo é adicionado, registrando o instantâneo em que é recebido (T2). A mensagem agora pode ser refletida do Roteador B ao Roteador A, com o Roteador B adicionando seu tempo de transmissão (T3) e roteador A adicionando seu tempo de recebimento (T4).

Esses quatro tempos — T1, T2, T3 e T4 — permitem que o Roteador A compute o atraso de ida em cada direção, bem como o atraso de duas vias para o canal. Os cálculos de atraso de ida exigem que os relógios dos roteadores A e B sejam sincronizados.

Neste ponto, o Roteador A pode calcular o atraso de canal de duas vias e o atraso de ida e volta associados ao canal da seguinte forma:

1. Atraso de canal de duas vias = (T4 - T1) - (T3 - T2)

2. Atraso na viagem de ida e volta = T4 - T1

Recursos de perda e atraso de pacotes

Supported Features of Packet Loss and Delay

O Junos OS oferece suporte aos seguintes recursos com medição de perda e atraso sob demanda:

• Monitoramento de desempenho para LSPs UHP de MPLS bidirecional associados apenas

• Medição da perda

• Medição da taxa de transferência

• Medição de atraso de duas vias (atraso no canal e atraso na viagem de ida e volta)

• Variação de atraso entre pacotes (IPDV)

• Medição de perda de modo direto

• Ethernet agregada e interfaces SONET agregadas

• Suporte para multichassis

• Compatível com 64 bits

Unsupported Features of Packet Loss and Delay

O Junos OS não oferece suporte à seguinte funcionalidade de medição de perda sob demanda e atraso:

• Medição de perda e atraso para pseudowires (seção 2.9.1 do RFC 6374)

• Medição unidirecional (seção 2.6 do RFC 6374)

• Medição Dyadic (seção 2.7 de RFC 6374)

• Medição de perda e atraso no modo loopback (seção 2.8 do RFC 6374)

• Medição de perda e atraso para um nó intermediário de um endpoint LSP (seção 2.9.5 do RFC 6374)

• Pós-processamento externo (seção 2.9.7 da RFC 6374)

• Medição de perda de modo inferido (seção 2.9.8 de RFC 6374)

• Modo pró-ativo

• Sistemas lógicos

• SNMP