Configuração do modo do Agendador de Upstream para o Cisco uBR CMTS

Introduction

Este documento discute a configuração do modo do agendador de upstream para a série Cisco Universal Broadband Router (uBR) de CMTS (Cable Modem Termination Systems).

Este documento concentra-se no pessoal que trabalha com o projeto e a manutenção de redes de dados sobre cabo de alta velocidade que utilizam serviços upstream sensíveis a instabilidade e latência, por exemplo, voz ou vídeo sobre IP.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Sistemas Data over Cable Service Interface Specification (DOCSIS)

• A série Cisco uBR de CMTS

Componentes Utilizados

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

• Cisco uBR CMTS

• Software Cisco IOS® versões trechos 12.3(13a)BC e 12.3(17a)BC

Observação: para obter informações sobre alterações em versões posteriores do Cisco IOS Software, consulte as notas de versão apropriadas disponíveis no site Cisco.com.

Conventions

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

Informações de Apoio

Em uma rede Data-over-Cable Service Interface Specifications (DOCSIS), o CMTS controla a temporização e a taxa de todas as transmissões upstream feitas pelos modems a cabo. Muitos tipos diferentes de serviços com diferentes requisitos de latência, instabilidade e throughput são executados simultaneamente em uma rede DOCSIS moderna upstream. Portanto, você deve entender como o CMTS decide quando um modem a cabo pode fazer transmissões upstream em nome desses diferentes tipos de serviços.

Este white paper inclui:

• Uma visão geral dos modos de agendamento upstream no DOCSIS, incluindo melhor esforço, Unsolicited Grant Service (UGS) e Real Time Polling Service (RTPS)

• A operação e a configuração do agendador compatível com DOCSIS para o Cisco uBR CMTS

• A operação e a configuração do novo programador de enfileiramento de baixa latência para o Cisco uBR CMTS

Agendamento de upstream no DOCSIS

Um CMTS compatível com DOCSIS pode fornecer diferentes modos de programação upstream para diferentes fluxos de pacotes ou aplicativos através do conceito de um fluxo de serviço. Um fluxo de serviço representa um fluxo de dados upstream ou downstream, que um ID de fluxo de serviço (SFID) identifica de forma exclusiva. Cada fluxo de serviço pode ter seus próprios parâmetros de qualidade de serviço (QoS), por exemplo, throughput máximo, throughput mínimo garantido e prioridade. No caso de fluxos de serviço upstream, você também pode especificar um modo de programação.

Você pode ter mais de um fluxo de serviço upstream para cada modem a cabo para acomodar diferentes tipos de aplicativos. Por exemplo, a Web e o e-mail podem usar um fluxo de serviço, voz sobre IP (VoIP) podem usar outro, e os jogos da Internet podem usar outro fluxo de serviço. Para poder fornecer um tipo adequado de serviço para cada um desses aplicativos, as características desses fluxos de serviço devem ser diferentes.

O modem a cabo e o CMTS são capazes de direcionar os tipos corretos de tráfego para os fluxos de serviço apropriados com o uso de classificadores. Classificadores são filtros especiais, como listas de acesso, que correspondem a propriedades de pacotes, como números de porta UDP e TCP, para determinar o fluxo de serviço apropriado pelo qual os pacotes trafegam.

Na Figura 1, um modem a cabo tem três fluxos de serviço upstream. O primeiro fluxo de serviço é reservado para tráfego de voz. Esse fluxo de serviço tem um throughput máximo baixo, mas também é configurado para fornecer uma garantia de baixa latência. O próximo fluxo de serviço é para tráfego geral de e-mail e Web. Esse fluxo de serviço tem um alto throughput. O fluxo de serviço final é reservado para tráfego peer to peer (P2P). Esse fluxo de serviço tem um throughput máximo mais restritivo para reduzir a velocidade desse aplicativo.

Figura 1: Um modem a cabo com três fluxos de serviço upstream

Os fluxos de serviço são estabelecidos e ativados quando um modem a cabo é colocado on-line pela primeira vez. Provisione os detalhes dos fluxos de serviço no arquivo de configuração DOCSIS que você usa para configurar o modem a cabo. Provisione pelo menos um fluxo de serviço para o tráfego upstream e outro fluxo de serviço para o tráfego downstream em um arquivo de configuração DOCSIS. Os primeiros fluxos de serviço upstream e downstream que você especificar no arquivo de configuração DOCSIS são chamados de fluxos de serviço primário.

Os fluxos de serviço também podem ser criados e ativados dinamicamente após um modem a cabo ficar on-line. Esse cenário geralmente se aplica a um fluxo de serviço, que corresponde a dados que pertencem a uma chamada de telefone VoIP. Esse fluxo de serviço é criado e ativado quando uma conversação telefônica é iniciada. O fluxo de serviço é então desativado e excluído quando a chamada é encerrada. Se o fluxo de serviço existir apenas quando necessário, você poderá salvar os recursos de largura de banda de upstream e a carga e memória da CPU do sistema.

Os modems a cabo não podem fazer transmissões upstream a qualquer momento. Em vez disso, os modems devem aguardar as instruções do CMTS antes de poderem enviar dados, pois apenas um modem a cabo pode transmitir dados em um canal upstream de cada vez. Caso contrário, as transmissões podem se sobrepor e corromper. As instruções para quando um modem a cabo pode fazer uma transmissão vêm do CMTS na forma de uma mensagem MAP de alocação de largura de banda. O Cisco CMTS transmite uma mensagem MAP a cada 2 milissegundos para informar aos cable modems quando eles podem fazer uma transmissão de qualquer tipo. Cada mensagem MAP contém informações que instruem os modems exatamente quando fazer uma transmissão, quanto tempo a transmissão pode durar e que tipo de dados eles podem transmitir. Assim, as transmissões de dados de modem a cabo não colidem entre si e evitam a corrupção de dados. Esta seção discute algumas das maneiras em que um CMTS pode determinar quando conceder permissão a um modem a cabo para fazer uma transmissão no upstream.

O melhor esforço

O agendamento de melhor esforço é adequado para aplicativos clássicos de Internet sem requisitos rigorosos de latência ou jitter. Exemplos desses tipos de aplicativos incluem e-mail, navegação na Web ou transferência de arquivos ponto-a-ponto. O agendamento de melhor esforço não é adequado para aplicativos que exigem latência ou jitter garantidos, por exemplo, voz ou vídeo sobre IP. Isso porque em condições congestionadas essa garantia não pode ser feita no modo de melhor esforço. Os sistemas DOCSIS 1.0 permitem apenas esse tipo de agendamento.

Os fluxos de serviço de melhor esforço são normalmente provisionados no arquivo de configuração DOCSIS associado a um modem a cabo. Portanto, os fluxos de serviço de melhor esforço estão geralmente ativos assim que o modem a cabo fica on-line. O fluxo de serviço upstream primário, que é o primeiro fluxo de serviço upstream a ser provisionado no arquivo de configuração DOCSIS, deve ser um fluxo de serviço de estilo de melhor esforço.

Aqui estão os parâmetros mais comumente usados que definem um fluxo de serviço de melhor esforço no modo DOCSIS 1.1/2.0:

• Taxa máxima de tráfego sustentado (R)

  A taxa máxima de tráfego sustentado é a taxa máxima na qual o tráfego pode operar nesse fluxo de serviço. Esse valor é expresso em bits por segundo.

• Intermitência máxima de tráfego (B)

  O burst de tráfego máximo refere-se ao tamanho de burst em bytes que se aplica ao limitador de taxa de bucket de token que aplica os limites de throughput de upstream. Se nenhum valor for especificado, o valor padrão de 3044 se aplica, que é o tamanho de dois quadros ethernet completos. Para grandes taxas de tráfego sustentado, defina esse valor como pelo menos a taxa de tráfego sustentado máxima dividida por 64.

• Prioridade de tráfego

  Esse parâmetro se refere à prioridade do tráfego em um fluxo de serviço que varia de 0 (o mais baixo) a 7 (o mais alto). No upstream, todo o tráfego pendente para fluxos de serviço de alta prioridade é programado para transmissão antes do tráfego para fluxos de serviço de baixa prioridade.

• Taxa mínima reservada

  Esse parâmetro indica um throughput garantido mínimo em bits por segundo para o fluxo de serviço, semelhante a uma taxa de informação comprometida (CIR). As taxas reservadas mínimas combinadas para todos os fluxos de serviço em um canal não devem exceder a largura de banda disponível nesse canal. Caso contrário, é impossível garantir as taxas mínimas reservadas prometidas.

• Intermitência máxima concatenada

  O burst concatenado máximo é o tamanho em bytes da maior transmissão de quadros concatenados que um modem pode fazer em nome do fluxo de serviço. Como esse parâmetro implica, um modem pode transmitir vários quadros em uma intermitência de transmissão. Se esse valor não for especificado, os modems a cabo DOCSIS 1.0 e os modems DOCSIS 1.1 mais antigos presumem que não há limite explícito definido no tamanho de intermitência concatenada. Os modems compatíveis com revisões mais recentes das especificações DOCSIS 1.1 ou mais recentes usam um valor de 1522 bytes.

Quando um modem a cabo tem dados para transmitir em nome de um fluxo de serviço de melhor esforço upstream, o modem não pode simplesmente encaminhar os dados para a rede DOCSIS sem retardo. O modem deve passar por um processo em que o modem solicita tempo de transmissão upstream exclusivo do CMTS. Esse processo de solicitação garante que os dados não colidam com as transmissões de outro modem a cabo conectado ao mesmo canal upstream.

Às vezes, o CMTS agenda certos períodos em que o CMTS permite que os modems a cabo transmitam mensagens especiais chamadas solicitações de largura de banda. A solicitação de largura de banda é um quadro muito pequeno que contém detalhes da quantidade de dados que o modem deseja transmitir, mais um identificador de serviço (SID) que corresponde ao fluxo de serviço upstream que precisa transmitir os dados. O CMTS mantém uma tabela interna que corresponde números SID aos fluxos de serviço upstream.

O CMTS agenda oportunidades de solicitação de largura de banda quando nenhum outro evento é agendado no upstream. Em outras palavras, o agendador fornece oportunidades de solicitação de largura de banda quando o agendador de upstream não planejou uma concessão de melhor esforço, ou uma concessão UGS ou algum outro tipo de concessão a ser colocado em um ponto específico. Portanto, quando um canal upstream é utilizado com grande frequência, há menos oportunidades para que os modems a cabo transmitam solicitações de largura de banda.

O CMTS sempre garante que um pequeno número de oportunidades de requisição de largura de banda sejam programadas regularmente, independentemente do quanto o canal upstream se torne congestionado. Vários modems a cabo podem transmitir solicitações de largura de banda ao mesmo tempo e corromper as transmissões uns dos outros. Para reduzir o potencial de colisões que podem corromper solicitações de largura de banda, um algoritmo "backoff and retry" está estabelecido. As seções subsequentes deste documento discutem este algoritmo.

Quando o CMTS recebe uma solicitação de largura de banda de um modem a cabo, o CMTS executa estas ações:

1. O CMTS usa o número SID recebido na solicitação de largura de banda para examinar o fluxo de serviço ao qual a solicitação de largura de banda está associada.

2. O CMTS usa o algoritmo token bucket. Esse algoritmo ajuda o CMTS a verificar se o fluxo de serviço excederá a taxa sustentada máxima prescrita se o CMTS conceder a largura de banda solicitada. Aqui está a computação do algoritmo token bucket:

   Máx. (T) = T * (R / 8) + B

   where:

   • Max(T) indica o número máximo de bytes que podem ser transmitidos no fluxo de serviço ao longo do tempo T.

   • T representa o tempo em segundos.

   • R indica a taxa de tráfego sustentado máxima para o fluxo de serviço em bits por segundo

   • B é a intermitência máxima de tráfego para o fluxo de serviço em bytes.

3. Quando o CMTS verifica que a solicitação de largura de banda está dentro dos limites de throughput, o CMTS enfileira os detalhes da solicitação de largura de banda para o agendador upstream. O agendador de upstream decide quando conceder a solicitação de largura de banda.

   O Cisco uBR CMTS implementa dois algoritmos do programador de upstream, chamados de programador compatível com DOCSIS e programador de enfileiramento de baixa latência. Consulte a seção DOCSIS Compliant Scheduler e a seção Low Latency Queueing Scheduler deste documento para obter mais informações.

4. O CMTS inclui esses detalhes na próxima mensagem de MAP de alocação periódica de largura de banda:

   • Quando o modem a cabo é capaz de transmitir.

   • Por quanto tempo o modem a cabo pode transmitir.

Solicitação de largura de banda com recuo e algoritmo de nova tentativa

O mecanismo de solicitação de largura de banda emprega um algoritmo simples de "backoff and retry" para reduzir, mas não eliminar totalmente, o potencial de colisões entre vários modems a cabo que transmitem solicitações de largura de banda simultaneamente.

Um modem a cabo que decide transmitir uma solicitação de largura de banda deve primeiro esperar que um número aleatório de oportunidades de requisição de largura de banda passe antes que o modem faça a transmissão. Esse tempo de espera ajuda a reduzir a possibilidade de colisões que ocorrem devido a transmissões simultâneas de solicitações de largura de banda.

Dois parâmetros chamados de início de recuo de dados e a extremidade de recuo de dados determinam o período de espera aleatório. Os modems a cabo aprendem esses parâmetros como parte do conteúdo da mensagem descritor de canal upstream periódico (UCD). O CMTS transmite a mensagem UCD em nome de cada canal upstream ativo a cada dois segundos.

Esses parâmetros de recuo são expressos como valores de "potência de dois". Os modems usam esses parâmetros como potências de dois para calcular quanto tempo esperar antes de transmitir solicitações de largura de banda. Ambos os valores têm um intervalo de 0 a 15 e a extremidade de backoff de dados deve ser maior ou igual à inicialização de backoff de dados.

Na primeira vez que um modem a cabo deseja transmitir uma solicitação de largura de banda específica, o modem a cabo deve primeiro escolher um número aleatório entre 0 e 2 para a potência do início da backoff dos dados menos 1. Por exemplo, se o início do recuo de dados estiver definido como 3, o modem deve escolher um número aleatório entre 0 e (2³ - 1) = (8 - 1) = 7.

O modem a cabo deve esperar que o número aleatório selecionado de oportunidades de transmissão de requisição de largura de banda passe antes que o modem transmita uma solicitação de largura de banda. Assim, enquanto um modem não pode transmitir uma solicitação de largura de banda na próxima oportunidade disponível devido a esse atraso forçado, a possibilidade de uma colisão com a transmissão de outro modem reduz.

Naturalmente quanto maior o valor inicial do recuo de dados, menor é a possibilidade de colisões entre a solicitação de largura de banda. Valores maiores de início de backoff de dados também significam que os modems podem ter que esperar mais para transmitir solicitações de largura de banda e, portanto, a latência de upstream aumenta.

O CMTS inclui uma confirmação na próxima mensagem de MAP de alocação de largura de banda transmitida. Essa confirmação informa ao modem a cabo que a solicitação de largura de banda foi recebida com êxito. Esta confirmação pode:

• indique exatamente quando o modem pode fazer a transmissão

  OU

• indica apenas que a solicitação de largura de banda foi recebida e que um tempo para transmissão será decidido em uma futura mensagem MAP.

Se o CMTS não incluir uma confirmação da solicitação de largura de banda na próxima mensagem do MAP, o modem poderá concluir que a solicitação de largura de banda não foi recebida. Essa situação pode ocorrer devido a uma colisão ou ruído upstream, ou porque o fluxo de serviço excede a taxa máxima de throughput prescrita se a solicitação for concedida.

Em ambos os casos, a próxima etapa do modem a cabo é fazer o backoff e tentar transmitir a solicitação de largura de banda novamente. O modem aumenta o intervalo sobre o qual um valor aleatório é escolhido. Para fazer isso, o modem adiciona um ao valor inicial de backoff dos dados. Por exemplo, se o valor inicial do recuo de dados for 3 e o CMTS não receber uma transmissão de solicitação de largura de banda, o modem espera um valor aleatório entre 0 e 15 oportunidades de solicitação de largura de banda antes da retransmissão. Aqui está o cálculo: 23+1 - 1 = 24 - 1 = 16 - 1 = 15

O maior intervalo de valores reduz a chance de outra colisão. Se o modem perder mais solicitações de largura de banda, o modem continua a incrementar o valor usado como a potência de dois para cada retransmissão até que o valor seja igual à extremidade de backoff de dados. A potência de dois não deve crescer para ser maior do que o valor final do recuo de dados.

O modem retransmite uma solicitação de largura de banda até 16 vezes, após a qual o modem descarta a solicitação de largura de banda. Essa situação ocorre apenas em condições extremamente congestionadas.

Você pode configurar os valores de início de backoff de dados e de fim de backoff de dados por cabo upstream em um Cisco uBR CMTS com este comando de interface de cabo:

cable upstream upstream-port-id data-backoff data-backoff-start data-backoff-end

A Cisco recomenda que você mantenha os valores padrão para os parâmetros data-backoff-start e data-backoff-end, que são 3 e 5. A natureza baseada em contenção do sistema de agendamento de melhor esforço significa que, para fluxos de serviço de melhor esforço, é impossível fornecer um nível determinístico ou garantido de latência ou jitter upstream. Além disso, condições congestionadas podem tornar impossível garantir um nível específico de throughput para um fluxo de serviço de melhor esforço. No entanto, você pode usar propriedades de fluxo de serviço como prioridade e taxa mínima reservada. Com essas propriedades, o fluxo de serviço pode alcançar o nível desejado de throughput em condições congestionadas.

Exemplo do algoritmo de recuo e tentativa

Este exemplo inclui quatro cable modems denominados A, B, C e D, conectados ao mesmo canal upstream. No mesmo momento chamado t₀, os modems A, B e C decidem transmitir alguns dados no upstream.

Aqui, o início do backoff dos dados é definido como 2 e o backoff dos dados é definido como 4. O intervalo de intervalos a partir dos quais os modems escolhem um intervalo antes de tentarem transmitir uma solicitação de largura de banda pela primeira vez está entre 0 e 3. Aqui está o cálculo:

(22 - 1) = (4 - 1) = 3 intervalos.

Aqui está o número de oportunidades de solicitação de largura de banda que os três modems escolhem para esperar do tempo t₀.

• Modem A: 3

• Modem B: 2

• Modem C: 3

Observe que o modem A e o modem C escolhem o mesmo número de oportunidades de espera.

O modem B espera duas oportunidades de solicitação de largura de banda que apareçam após t₀. O modem B, então, transmite a solicitação de largura de banda, que o CMTS recebe. O modem A e o modem C esperam 3 oportunidades de solicitação de largura de banda passarem depois de t₀. Os modems A e C transmitem as solicitações de largura de banda ao mesmo tempo. Essas duas solicitações de largura de banda colidem e se tornam corrompidas. Como resultado, nenhuma solicitação alcança o CMTS com êxito. A Figura 2 mostra esta sequência de eventos.

Figura 2: Exemplo de solicitação de largura de banda parte 1

A barra cinza na parte superior do diagrama representa uma série de oportunidades de solicitação de largura de banda disponíveis para os modems a cabo após o tempo t₀. As setas coloridas representam as solicitações de largura de banda que os modems a cabo transmitem. A caixa colorida na barra cinza representa uma solicitação de largura de banda que chega ao CMTS com êxito.

A próxima mensagem MAP transmitida pelo CMTS contém uma concessão para o modem B, mas não contém instruções para os modems A e C. Isso indica aos modems A e C que eles precisam retransmitir suas solicitações de largura de banda.

Na segunda tentativa, o modem A e o modem C precisam aumentar a potência de dois para usar quando calcularem o intervalo de intervalos a partir dos quais escolher. Agora, o modem A e o modem C escolhem um número aleatório de intervalos entre 0 e 7. Aqui está a computação:

(22+1 -1) = (23 - 1) = (8 - 1) = 7 intervalos.

Suponha que o tempo em que o modem A e o modem C percebem que a necessidade de retransmitir é t₁. Suponha também que outro modem chamado modem D decida transmitir alguns dados upstream no mesmo momento, t₁. O modem D está prestes a fazer uma transmissão de solicitação de largura de banda pela primeira vez. Portanto, o modem D usa o valor original para início de recuo de dados e fim de recuo de dados, nomeadamente entre 0 e 3 [(22 - 1) = (4 - 1) = 3 intervalos].

Os três modems escolhem esse número aleatório de oportunidades de solicitação de largura de banda para esperar do tempo t₁.

• Modem A: 5

• Modem C: 2

• Modem D: 2

Ambos os modems C e D esperam por duas oportunidades de solicitação de largura de banda que apareçam após o tempo t₁. Os modems C e D transmitem as solicitações de largura de banda ao mesmo tempo. Essas solicitações de largura de banda colidem e, portanto, não alcançam o CMTS. O modem A permite que cinco oportunidades de solicitação de largura de banda passem. Em seguida, o modem A transmite a solicitação de largura de banda, que o CMTS recebe. A Figura 3 mostra a colisão entre a transmissão dos modems C e D e o recebimento bem-sucedido da transmissão do modem A. A referência de hora de início para esta figura é t₁.

Figura 3: Exemplo de solicitação de largura de banda parte 2

A próxima mensagem MAP transmitida pelo CMTS contém uma concessão para o modem A, mas não contém instruções para os modems C e D. Os modems C e D percebem a necessidade de retransmitir as solicitações de largura de banda. O modem D está prestes a transmitir a solicitação de largura de banda pela segunda vez. Portanto, o modem D usa data backoff start + 1 como a potência de dois para usar no cálculo do intervalo de intervalos a aguardar. O modem D escolhe um intervalo entre 0 e 7. Aqui está o cálculo:

(22+1 - 1) = (23 - 1) = (8 - 1) = 7 intervalos.

O modem C está prestes a transmitir a solicitação de largura de banda pela terceira vez. Portanto, o modem C usa data backoff start + 2 como a potência de dois a no cálculo do intervalo de intervalos a aguardar. O modem C escolhe um intervalo entre 0 e 15. Aqui está o cálculo:

(22+2 - 1) = (24 - 1) = (16 - 1) = 15 intervalos.

Observe que a potência de dois aqui é a mesma do valor final de backoff dos dados, que é quatro. Essa é a potência mais alta que a de dois valores pode ser para um modem nesse canal upstream. No próximo ciclo de transmissão de requisição de largura de banda, os dois modems escolhem o número de oportunidades de requisição de largura de banda a aguardar:

• Modem C: 9

• Modem D: 4

O modem D é capaz de transmitir a solicitação de largura de banda porque o modem D espera quatro oportunidades de solicitação de largura de banda. Além disso, o modem C também pode transmitir a solicitação de largura de banda, porque o modem C agora adia a transmissão para nove oportunidades de solicitação de largura de banda.

Infelizmente, quando o modem C faz uma transmissão, uma grande intermitência de ruído de ingresso interfere na transmissão e o CMTS falha ao receber a solicitação de largura de banda (consulte a Figura 4). Como resultado, mais uma vez, o modem C não vê uma concessão na próxima mensagem MAP que o CMTS transmite. Isso faz com que o modem C tente uma quarta transmissão da solicitação de largura de banda.

Figura 4 - Exemplo de solicitação de largura de banda - Parte 3

O modem C já atingiu o valor final de recuo de dados de 4. O modem C não pode aumentar o intervalo usado para escolher um número aleatório de intervalos a aguardar. Portanto, o modem C novamente usa 4 como a potência de dois para calcular o intervalo aleatório. O modem C ainda usa o intervalo de 0 a 15 intervalos de acordo com este cálculo:

(24 - 1) = (16 - 1) = 15 intervalos.

Na quarta tentativa, o modem C pode fazer uma transmissão bem-sucedida de solicitação de largura de banda na ausência de contenção ou ruído.

As múltiplas retransmissões de requisição de largura de banda do modem C neste exemplo demonstram o que pode acontecer em um canal upstream congestionado. Este exemplo também demonstra os possíveis problemas envolvidos com o modo de programação de melhor esforço e por que a programação de melhor esforço não é adequada para serviços que exigem níveis estritamente controlados de latência e jitter de pacote.

Prioridade de tráfego

Quando o CMTS tem várias solicitações de largura de banda pendentes de vários fluxos de serviço, o CMTS examina a prioridade de tráfego de cada fluxo de serviço para decidir quais conceder a largura de banda primeiro.

O CMTS concede tempo de transmissão a todas as solicitações pendentes de fluxos de serviço com uma prioridade mais alta antes das solicitações de largura de banda de fluxos de serviço com uma prioridade mais baixa. Em condições de upstream congestionadas, isso geralmente leva a um throughput mais alto para fluxos de serviço de alta prioridade em comparação a fluxos de serviço de baixa prioridade.

Um fato importante a ser observado é que, embora um fluxo de serviço de melhor esforço de alta prioridade tenha maior probabilidade de receber largura de banda rapidamente, o fluxo de serviço ainda está sujeito à possibilidade de colisões de requisição de largura de banda. Por esse motivo, enquanto a prioridade de tráfego pode aprimorar as características de throughput e latência de um fluxo de serviço, a prioridade de tráfego ainda não é uma maneira adequada de fornecer uma garantia de serviço para aplicativos que exigem uma.

Taxa mínima reservada

Os fluxos de serviço de melhor esforço podem receber uma taxa reservada mínima a ser cumprida. O CMTS garante que um fluxo de serviço com uma taxa reservada mínima especificada receba largura de banda de preferência a todos os outros fluxos de serviço de melhor esforço, independentemente da prioridade.

Este método é uma tentativa de fornecer um tipo de serviço de estilo CIR (taxa de informação comprometida) análogo a uma rede frame-relay. O CMTS tem mecanismos de controle de admissão para garantir que, em um determinado upstream, a taxa reservada mínima combinada de todos os fluxos de serviço conectados não possa exceder a largura de banda disponível do canal upstream, ou uma porcentagem do canal. Você pode ativar esses mecanismos com este comando por porta upstream:

[no] cable upstream upstream-port-id Admission-Control max-reserve-limit

O parâmetro max-reserve-limit tem um intervalo de 10 a 1000 por cento para indicar o nível de assinatura em comparação ao throughput de canal upstream bruto disponível que os serviços de estilo CIR podem consumir. Se você configurar um limite máximo de reserva superior a 100, o upstream poderá assinar em excesso os serviços de estilo CIR pelo limite percentual especificado.

O CMTS não permite que novos fluxos de serviço de taxa reservada mínima sejam estabelecidos se fizerem com que a porta upstream exceda a porcentagem de limite máximo de reserva configurada da largura de banda do canal upstream disponível. Os fluxos de serviço de taxa reservada mínima ainda estão sujeitos a possíveis colisões de solicitações de largura de banda. Como tal, os fluxos de serviço de taxa reservada mínima não podem fornecer uma verdadeira garantia de um throughput específico, especialmente em condições extremamente congestionadas. Em outras palavras, o CMTS só pode garantir que um fluxo de serviço de taxa reservada mínima seja capaz de alcançar um determinado throughput upstream garantido se o CMTS for capaz de receber todas as solicitações de largura de banda exigidas do modem a cabo. Esse requisito pode ser alcançado se você fizer do fluxo de serviço um fluxo de serviço RTPS (Real Time Polling Service, serviço de pesquisa em tempo real) em vez de um fluxo de serviço de melhor esforço. Consulte a seção RTPS (Real Time Polling Service) para obter mais informações.

Solicitações de largura de banda de retorno

Quando um fluxo de serviço de melhor esforço upstream transmite quadros em uma taxa alta, é possível colocar as solicitações de largura de banda de giro em quadros de dados upstream em vez de ter transmissão separada das solicitações de largura de banda. Os detalhes da próxima solicitação de largura de banda são simplesmente adicionados ao cabeçalho de um pacote de dados sendo transmitido no upstream para o CMTS.

Isso significa que a solicitação de largura de banda não está sujeita a contenção e, portanto, tem uma chance muito maior de que a solicitação chegue ao CMTS. O conceito de solicitações de largura de banda de piggyback reduz o tempo que um quadro Ethernet leva para alcançar o equipamento nas instalações do cliente (CPE) do usuário final, porque o tempo que o quadro leva na transmissão de upstream reduz. Isso ocorre porque o modem não precisa passar pelo processo de backoff e repetir a solicitação de largura de banda, que pode estar sujeita a atrasos.

O backup de pedidos de largura de banda normalmente ocorre neste cenário:

Enquanto o modem a cabo espera para transmitir um quadro, digamos X, no upstream, o modem recebe outro quadro, digamos Y, de um CPE para transmitir no upstream. O modem a cabo não pode adicionar os bytes do novo quadro Y à transmissão, porque isso envolve o uso de mais tempo de upstream do que o modem é concedido. Em vez disso, o modem preenche um campo no cabeçalho DOCSIS do quadro X para indicar a quantidade de tempo de transmissão necessária para o quadro Y.

O CMTS recebe o quadro X e também os detalhes de uma solicitação de largura de banda em nome de Y. Com base na disponibilidade, o CMTS concede ao modem mais tempo de transmissão em nome de Y.

Em termos muito conservadores, decorreram até 5 milissegundos entre a transmissão de uma solicitação de largura de banda e o recebimento da alocação de largura de banda, bem como a confirmação MAP que atribui tempo para a transmissão de dados. Isso significa que para que ocorra piggybacking, o modem a cabo precisa receber quadros do CPE em menos de 5 ms um do outro.

Isso é notável porque um codec VoIP típico como G.711 geralmente usa um período entre quadros de 10 ou 20 ms. Um fluxo VoIP típico que opera em um fluxo de serviço de melhor esforço não pode tirar vantagem do piggybacking.

Concatenação

Quando um fluxo de serviço upstream de melhor esforço transmite quadros a uma taxa alta, o modem a cabo pode unir alguns dos quadros e pedir permissão para transmitir todos os quadros de uma só vez. Isso é chamado concatenação. O modem a cabo precisa transmitir apenas uma solicitação de largura de banda em nome de todos os quadros em um grupo de quadros concatenados, o que melhora a eficiência.

A concatenação tende a ocorrer em circunstâncias semelhantes ao piggybacking, exceto que a concatenação exige que vários quadros sejam enfileirados dentro do modem a cabo quando o modem decide transmitir uma solicitação de largura de banda. Isso implica que a concatenação tende a ocorrer em taxas de quadros médias mais altas do que o piggybacking. Além disso, ambos os mecanismos geralmente trabalham juntos para melhorar a eficiência do tráfego de melhor esforço.

O campo Intermitência máxima concatenada que você pode configurar para um fluxo de serviço limita o tamanho máximo de um quadro concatenado que um fluxo de serviço pode transmitir. Você também pode usar o comando cable default-phy-burst para limitar o tamanho de um quadro concatenado e o tamanho máximo de intermitência no perfil de modulação de canal upstream.

A concatenação é habilitada por padrão nas portas upstream da série Cisco uBR de CMTS. No entanto, você pode controlar a concatenação em uma base por porta upstream com o comando cable interface [no] cable upstream upstream-port-id concatenation [docsis10].

Se você configurar o parâmetro docsis10, o comando só se aplica aos modems a cabo que operam no modo DOCSIS 1.0.

Se você fizer alterações nesse comando, os modems a cabo devem se registrar novamente no CMTS para que as alterações tenham efeito. Os modems no upstream afetado devem ser redefinidos. Um modem a cabo aprende se a concatenação é permitida no ponto em que o modem executa o registro como parte do processo de entrada on-line.

Fragmentação

Quadros grandes levam muito tempo para transmitir no upstream. Esse tempo de transmissão é conhecido como atraso de serialização. Especialmente grandes quadros upstream podem levar tanto tempo para transmitir que podem atrasar inofensivamente os pacotes que pertencem a serviços sensíveis ao tempo, por exemplo, VoIP. Isso é especialmente verdadeiro para quadros grandes concatenados. Por esse motivo, a fragmentação foi introduzida no DOCSIS 1.1 para que quadros grandes possam ser divididos em quadros menores para transmissão em bursts separados que levam menos tempo para transmitir.

A fragmentação permite que quadros pequenos e sensíveis ao tempo sejam intercalados entre os fragmentos de quadros grandes, em vez de ter que esperar pela transmissão de todo o quadro grande. A transmissão de um quadro como vários fragmentos é um pouco menos eficiente do que a transmissão de um quadro em um pico devido ao conjunto extra de cabeçalhos DOCSIS que precisam acompanhar cada fragmento. No entanto, a flexibilidade que a fragmentação acrescenta ao canal upstream justifica a sobrecarga extra.

Os modems a cabo que operam no modo DOCSIS 1.0 não podem executar fragmentação.

A fragmentação é habilitada por padrão nas portas upstream da série Cisco uBR de CMTS. No entanto, você pode ativar ou desativar a fragmentação em uma base por porta upstream com o comando de interface do cabo [no] cable upstream upstream-port-id fragmentation.

Você não precisa redefinir modems a cabo para que o comando tenha efeito. A Cisco recomenda que você sempre tenha a fragmentação ativada. A fragmentação normalmente ocorre quando o CMTS acredita que um grande quadro de dados pode interferir na transmissão de pequenos quadros sensíveis ao tempo ou certos eventos de gerenciamento de DOCSIS periódicos.

Você pode forçar os modems a cabo DOCSIS 1.1/2.0 a fragmentar todos os quadros grandes com o comando de interface a cabo [no] cable upstream port-id fragment-force [threshold number-of-fragments] cable.

Por padrão, este recurso está desabilitado. Se você não especificar valores para limiar e número de fragmentos na configuração, o limite será definido como 2.000 bytes e o número de fragmentos será definido como 3. O comando fragment-force compara o número de bytes que um fluxo de serviço solicita para transmissão com o parâmetro de limite especificado. Se o tamanho da solicitação for maior que o limite, o CMTS concederá a largura de banda para o fluxo de serviço em peças com o mesmo tamanho de "número de fragmentos".

Por exemplo, suponha que para um fragmento de upstream específico a força esteja habilitada com um valor de 2.000 bytes para limiar e 3 para o número de fragmentos. Em seguida, suponha que uma solicitação para transmitir um burst de 3.000 bytes chegue. Como 3000 bytes é maior que o limite de 2000 bytes, a concessão deve ser fragmentada. Como o número de fragmentos é definido como 3, o tempo de transmissão é de três concessões de tamanho igual de 1.000 bytes cada.

Assegure-se de que os tamanhos de fragmentos individuais não excedam a capacidade do tipo de placa de linha de cabo em uso. Para placas de linha MC5x20S, o maior fragmento individual não deve exceder 2.000 bytes, e para outras placas de linha, incluindo MC28U, MC5x20U e MC5x20H, o maior fragmento individual não deve exceder 4.000 bytes.

Serviço de concessão não solicitado (UGS)

O Unsolicited Grant Service (UGS) fornece concessões periódicas para um fluxo de serviço upstream sem a necessidade de um modem a cabo transmitir solicitações de largura de banda. Esse tipo de serviço é adequado para aplicativos que geram quadros de tamanho fixo em intervalos regulares e são intolerantes à perda de pacotes. Voz sobre IP é o exemplo clássico.

Compare o sistema de agendamento UGS a um slot de tempo em um sistema de multiplexação por divisão de tempo (TDM), como um circuito T1 ou E1. O UGS fornece um throughput e uma latência garantidos, que por sua vez fornecem um fluxo contínuo de intervalos periódicos fixos para transmitir sem a necessidade de o cliente solicitar ou disputar periodicamente a largura de banda. Esse sistema é perfeito para VoIP porque o tráfego de voz é geralmente transmitido como um fluxo contínuo de dados periódicos de tamanho fixo.

O UGS foi concebido devido à falta de garantias para latência, instabilidade e throughput no modo de programação de melhor esforço. O modo de programação de melhor esforço não fornece a garantia de que um quadro específico pode ser transmitido em um momento específico, e em um sistema congestionado não há nenhuma garantia de que um quadro específico possa ser transmitido.

Observe que, embora os fluxos de serviço de estilo UGS sejam o tipo mais apropriado de fluxo de serviço para transmitir o tráfego do portador VoIP, eles não são considerados apropriados para aplicativos clássicos de Internet, como Web, e-mail ou P2P. Isso ocorre porque os aplicativos clássicos de Internet não geram dados em intervalos periódicos fixos e podem, de fato, passar um tempo significativo sem transmitir dados. Se um fluxo de serviço UGS for usado para transmitir o tráfego clássico da Internet, o fluxo de serviço poderá ficar sem uso por períodos significativos quando o aplicativo parar brevemente as transmissões. Isso leva a concessões de UGS não utilizadas que representam um desperdício de recursos de largura de banda de upstream que não é desejável.

Geralmente, os fluxos de serviço UGS são estabelecidos dinamicamente quando são necessários, em vez de serem provisionados no arquivo de configuração DOCSIS. Um modem a cabo com portas VoIP integradas geralmente pode pedir ao CMTS para criar um fluxo de serviço UGS apropriado quando o modem detecta que uma chamada de telefone VoIP está em andamento.

A Cisco recomenda que você não configure um fluxo de serviço UGS em um arquivo de configuração DOCSIS, pois essa configuração mantém o fluxo de serviço UGS ativo enquanto o modem a cabo estiver on-line, seja ou não usado por qualquer serviço. Essa configuração desperdiça a largura de banda de upstream porque um fluxo de serviço UGS reserva constantemente o tempo de transmissão de upstream em nome do modem a cabo. É muito melhor permitir que o fluxo de serviço UGS seja criado e excluído dinamicamente para que o UGS esteja ativo quando necessário.

Aqui estão os parâmetros mais comumente usados que definem um fluxo de serviço UGS:

• Tamanho de concessão não solicitado (G) — O tamanho de cada concessão periódica em bytes.

• Intervalo de concessão nominal (I) — O intervalo em microssegundos entre as concessões.

• Tolerated Grant Jitter (J) — A variação permitida em microssegundos de concessões periódicas exatas. Em outras palavras, essa é a margem que o CMTS tem quando o CMTS tenta agendar uma concessão de UGS a tempo.

Quando um fluxo de serviço UGS está ativo, a cada (I) milissegundos, o CMTS oferece uma chance para o fluxo de serviço transmitir em bytes de tamanho de concessão não solicitado (G). Embora idealmente o CMTS ofereça a concessão exatamente a cada (I) milissegundos, pode ser tarde em até (J) milissegundos.

A Figura 5 mostra um cronograma que demonstra como as concessões de UGS podem ser alocadas com um determinado tamanho de concessão, intervalo de concessão e jitter tolerado.

Figura 5 - Linha do tempo que mostra concessões de UGS periódicas

Os blocos com padrão verde representam o tempo em que o CMTS dedica o tempo de transmissão upstream a um fluxo de serviço UGS.

RTPS (Real Time Polling Service, serviço de pesquisa em tempo real)

O Real Time Polling Service (RTPS) oferece oportunidades periódicas de solicitação de largura de banda não baseada em contenção para que um fluxo de serviço tenha tempo dedicado para transmitir solicitações de largura de banda. Somente o fluxo de serviço RTPS tem permissão para usar essa oportunidade de solicitação de largura de banda unicast. Outros modems a cabo não podem causar uma colisão de solicitação de largura de banda.

O RTPS é adequado para aplicativos que geram quadros de comprimento variável em uma base semiperiódica e exigem um throughput mínimo garantido para funcionar com eficiência. Videotelefonia sobre IP ou jogos on-line com vários jogadores são exemplos típicos.

O RTPS também é usado para tráfego de sinalização VoIP. Embora o tráfego de sinalização de VoIP não precise ser transmitido com uma latência ou jitter extremamente baixa, o VoIP precisa ter uma alta probabilidade de alcançar o CMTS em um período de tempo razoável. Se você usar RTPS em vez do agendamento de melhor esforço, poderá ter certeza de que a sinalização de voz não está significativamente atrasada ou descartada devido a colisões repetidas de solicitações de largura de banda.

Um fluxo de serviço RTPS normalmente possui estes atributos:

• Intervalo de sondagem nominal —O intervalo em microssegundos entre as oportunidades de solicitação de largura de banda unicast.

• Tolerated Poll Jitter —A variação permitida em microssegundos a partir de votações periódicas exatas. Em outras palavras, essa é a margem que o CMTS tem ao tentar agendar uma oportunidade de solicitação de largura de banda unicast RTPS em tempo hábil.

A Figura 6 mostra uma linha do tempo que demonstra como as pesquisas RTPS são alocadas com um determinado intervalo de sondagem nominal e variação de poll tolerada.

Figura 6 - Linha do tempo que mostra a pesquisa periódica de RTPS

Os pequenos blocos padronizados verdes representam o tempo em que o CMTS oferece um fluxo de serviço RTPS, uma oportunidade de solicitação de largura de banda unicast.

Quando o CMTS recebe uma solicitação de largura de banda em nome de um fluxo de serviço RTPS, o CMTS processa a solicitação de largura de banda da mesma forma que uma solicitação de um fluxo de serviço de "melhor esforço". Isso significa que, além dos parâmetros acima, propriedades como taxa de tráfego sustentado máxima e prioridade de tráfego devem ser incluídas em uma definição de fluxo de serviço RTPS. Geralmente, um fluxo de serviço RTPS também contém uma taxa de tráfego reservada mínima para garantir que o tráfego associado ao fluxo de serviço possa receber uma garantia de largura de banda comprometida.

Serviço de concessão não solicitado com detecção de atividade (UGS-AD)

O serviço de concessão não solicitado com detecção de atividade (UGS-AS) atribui tempo de transmissão de estilo UGS a um fluxo de serviço somente quando o UGS-AS realmente precisa transmitir pacotes. Quando o CMTS detecta que o modem a cabo não transmitiu quadros por um determinado período, o CMTS oferece oportunidades de solicitação de largura de banda de estilo RTPS em vez de concessões de estilo UGS. Se o CMTS detectar posteriormente que o fluxo de serviço faz solicitações de largura de banda, o CMTS reverte o fluxo de serviço para oferecer concessões de estilo UGS e para de oferecer oportunidades de solicitação de largura de banda de estilo RTPS.

O UGS-AD é normalmente usado em uma situação em que o tráfego VoIP que usou a detecção de atividade de voz (VAD) estava sendo transmitido. A detecção de atividade de voz faz com que o ponto final do VoIP pare a transmissão de quadros VoIP se o UGS-AD detectar uma pausa na fala do usuário. Embora esse comportamento possa salvar a largura de banda, ele pode causar problemas com a qualidade de voz, especialmente se o mecanismo de detecção de atividade VAD ou UGS-AD for ativado um pouco depois que o interlocutor final começar a falar. Isso pode levar a um som de pop-up ou de clique quando um usuário continuar falando após o silêncio. Por isso, o UGS-AD não é amplamente implantado.

Emita o comando de configuração do CMTS global cable service flow inactivity-threshold threshold-in-seconds para definir o período após o qual o CMTS alterna um fluxo de serviço UGS-AD inativo do modo UGS para o modo RTPS.

O valor padrão do parâmetro threshold-in-seconds é 10 segundos. Os fluxos de serviço UGS-AD geralmente possuem os atributos de um fluxo de serviço UGS e o intervalo nominal de polling e o atributo tolerado de jitter de poll associado aos fluxos de serviço RTPS.

Serviço de pesquisa em tempo não real (nRTPS)

O modo de agendamento nRTPS (non real time polling service) é essencialmente o mesmo que RTPS, exceto que o nRTPS é geralmente associado a serviços não interativos, como transferências de arquivos. O componente em tempo não real pode implicar que o intervalo de sondagem nominal para oportunidades de solicitação de largura de banda unicast não é exatamente regular ou pode ocorrer a uma taxa menor que uma por segundo.

Alguns operadores de rede a cabo podem optar por usar nRTPS em vez de fluxos de serviço RTPS para transportar tráfego de sinalização de voz.

Algoritmos de Agendamento

Antes de uma discussão sobre as especificações do agendador compatível com DOCSIS e do agendador de enfileiramento de baixa latência, você deve entender as compensações que precisa fazer para determinar as características de um agendador de upstream. Embora a discussão sobre os algoritmos do agendador se centre principalmente no modo de agendamento UGS, a discussão também se aplica aos serviços de estilo RTPS.

Quando você decide como programar fluxos de serviço UGS, não há muitas opções flexíveis. Não é possível fazer com que o agendador altere o tamanho da concessão ou o intervalo de concessão dos fluxos de serviço UGS, porque essa alteração faz com que as chamadas VoIP falhem completamente. No entanto, se você alterar o jitter, as chamadas funcionam, embora possivelmente com maior latência na chamada. Além disso, a modificação do número máximo de chamadas permitidas em um upstream não afeta a qualidade de chamadas individuais. Portanto, considere estes dois fatores principais ao programar um grande número de fluxos de serviço UGS:

• Tremulação

• Capacidade de fluxo de serviço UGS por upstream

Tremulação

Um jitter de concessão tolerado é especificado como um dos atributos de um fluxo de serviço UGS ou RTPS. No entanto, o suporte simultâneo de alguns fluxos de serviço com tremulação tolerada muito baixa e outros com grandes quantidades de tremulação podem ser ineficientes. Em geral, você deve fazer uma escolha uniforme quanto ao tipo de tremulação que o serviço flui em uma experiência de upstream.

Se forem necessários níveis baixos de tremulação, o agendador precisará ser inflexível e rígido quando programar concessões. Como consequência, o agendador precisa colocar restrições no número de fluxos de serviço UGS suportados em um upstream.

Os níveis de variação de sinal nem sempre precisam ser extremamente baixos para VoIP normal do consumidor, pois a tecnologia de buffer de variação de sinal é capaz de compensar altos níveis de variação de sinal. Buffers de jitter VoIP adaptáveis modernos podem compensar mais de 150 ms de jitter. No entanto, uma rede VoIP adiciona a quantidade de buffering que ocorre à latência de pacotes. Altos níveis de latência podem contribuir para uma experiência de VoIP mais pobre.

Capacidade de fluxo de serviço UGS por upstream

Os atributos da camada física, como a largura do canal, o esquema de modulação e a intensidade da correção de erros determinam a capacidade física de um upstream. No entanto, o número de fluxos de serviço UGS simultâneos que o upstream pode suportar também depende do algoritmo do agendador.

Se níveis de jitter extremamente baixos não forem necessários, você pode relaxar a rigidez do agendador e atender a um número maior de fluxos de serviço UGS que o upstream pode suportar simultaneamente. Você pode alcançar maior eficiência do tráfego de não voz no upstream se relaxar os requisitos de instabilidade.

Observação: diferentes algoritmos de agendamento podem permitir que um canal upstream específico suporte vários números de fluxos de serviço UGS e RTPS. No entanto, esses serviços não podem utilizar 100% da capacidade upstream em um sistema DOCSIS. Isso porque o canal upstream deve dedicar uma parte ao tráfego de gerenciamento DOCSIS, como as mensagens de manutenção inicial que os modems a cabo usam para fazer o contato inicial com o CMTS, e o tráfego de manutenção de estação keepalive usado para garantir que os modems a cabo possam manter a conectividade com o CMTS.

O Agendador Compatível com DOCSIS

O agendador compatível com DOCSIS é o sistema padrão para agendar serviços upstream em um Cisco uBR CMTS. Este agendador foi projetado para minimizar o jitter que os fluxos de serviço UGS e RTPS experimentam. No entanto, esse agendador ainda permite manter algum grau de flexibilidade para otimizar o número de chamadas UGS simultâneas por upstream.

O agendador compatível com DOCSIS pré-aloca o tempo de upstream com antecedência para os fluxos de serviço UGS. Antes que qualquer outra alocação de largura de banda seja programada, o CMTS reserva tempo no futuro para as concessões que pertencem aos fluxos de serviço UGS ativos para garantir que nenhum dos outros tipos de fluxos de serviço ou tráfego desloque as concessões de UGS e provoque um jitter significativo.

Se o CMTS receber solicitações de largura de banda em nome dos fluxos de serviço de estilo de melhor esforço, o CMTS deverá programar o tempo de transmissão para os fluxos de serviço de melhor esforço em torno das concessões de UGS pré-alocadas, de forma a não afetar o agendamento em tempo hábil de cada concessão de UGS.

Configuração

O agendador em conformidade com DOCSIS é o único algoritmo de agendador upstream disponível para Cisco IOS Software Releases 12.3(9a)BCx e anteriores. Portanto, este agendador não requer nenhum comando de configuração para ativação.

Para o Cisco IOS Software Releases 12.3(13a)BC e posteriores, o agendador em conformidade com o DOCSIS é um dos dois algoritmos de agendador alternativos, mas é definido como o agendador padrão. Você pode habilitar o agendador compatível com DOCSIS para um, todos ou alguns destes tipos de agendamento:

• UGS

• RTPS

• NRTPS

Você pode habilitar explicitamente o agendador compatível com DOCSIS para cada um desses tipos de agendamento com o tipo de agendamento cable upstream de porta upstream [nrtps] | rtps | ugs] mode docsis cable interface.

O uso do agendador compatível com DOCSIS faz parte da configuração padrão. Portanto, você precisa executar esse comando somente se alterar de volta do algoritmo do programador de enfileiramento de baixa latência não padrão. Consulte a seção Agendador de enfileiramento de baixa latência para obter mais informações.

Controle de admissão

Uma grande vantagem do agendador compatível com DOCSIS é que esse agendador garante que os fluxos de serviço UGS não assinem o upstream. Se um novo fluxo de serviço UGS tiver que ser estabelecido e o agendador descobrir que uma pré-programação de concessões não é possível porque não há espaço, o CMTS rejeita o novo fluxo de serviço UGS. Se os fluxos de serviço UGS que transportam tráfego VoIP tiverem permissão para assinar um canal upstream em excesso, a qualidade de todas as chamadas VoIP se tornará severamente degradada.

Para demonstrar como o agendador compatível com DOCSIS garante que os fluxos de serviço UGS nunca substituam o upstream, consulte as figuras nesta seção. As Figuras 7, 8 e 9 mostram as linhas do tempo de alocação de largura de banda.

Em todos esses números, as seções padronizadas em cores mostram o tempo em que os modems a cabo recebem bolsas em nome de seus fluxos de serviço UGS. Nenhuma outra transmissão de upstream de outros modems a cabo pode ocorrer durante esse período. A parte cinza da linha de tempo ainda não foi alocada. Os modems a cabo usam esse tempo para transmitir solicitações de largura de banda. O CMTS pode posteriormente usar esse tempo para agendar outros tipos de serviços.

Figura 7: Programador compatível com DOCSIS pré-agenda três fluxos de serviço UGS

Adicione mais dois fluxos de serviço UGS do mesmo tamanho de concessão e intervalo de concessão. Ainda assim, o agendador não tem problemas para pré-agendá-los.

Figura 8: Programador compatível com DOCSIS pré-agenda cinco fluxos de serviço UGS

Se você adicionar mais dois fluxos de serviço UGS, preencha toda a largura de banda upstream disponível.

Figura 9: Fluxos de serviço UGS consomem toda a largura de banda upstream disponível

Claramente, o agendador não pode admitir mais nenhum fluxo de serviço UGS aqui. Portanto, se outro fluxo de serviço UGS tentar se tornar ativo, o agendador compatível com DOCSIS perceberá que não há espaço para concessões adicionais e impedirá o estabelecimento desse fluxo de serviço.

Observação: é impossível preencher completamente um upstream com fluxos de serviço UGS conforme visto nesta série de figuras. O agendador precisa acomodar outros tipos importantes de tráfego, por exemplo, manutenção de estação e tráfego de dados de melhor esforço. Além disso, a garantia para evitar excesso de assinaturas com o agendador compatível com DOCSIS só se aplica se todos os modos de programação de fluxo de serviço, como UGS, RTPS e nRTPS, usarem o agendador compatível com DOCSIS.

Embora a configuração explícita de controle de admissão não seja necessária quando você usa o agendador compatível com DOCSIS, a Cisco recomenda que você assegure que a utilização do canal upstream não aumente para níveis que possam afetar negativamente o tráfego de melhor esforço. A Cisco também recomenda que a utilização total do canal upstream não exceda 75% para quantidades significativas de tempo. Esse é o nível de utilização de upstream em que os serviços de melhor esforço começam a experimentar latência muito maior e throughput mais lento. Os serviços UGS ainda funcionam, independentemente da utilização de upstream.

Se você quiser limitar a quantidade de tráfego admitido em um upstream específico, configure o controle de admissão para UGS, RTPS, NRTPS, UGS-AD ou fluxos de serviço de melhor esforço com o global, por interface de cabo ou por comando upstream. O parâmetro mais importante é o campo unique-threshold-percent.

cable [upstream upstream-number] admission-control us-bandwidth
scheduling-type UGS|AD-UGS|RTPS|NRTPS|BE minor minor-threshold-percent 
major major-threshold-percent exclusive exclusive-threshold-percent
[non-exclusive non-excl-threshold-percent]

Aqui estão os parâmetros:

• [upstream <upstream-number>]: Especifique esse parâmetro se quiser aplicar o comando a um upstream específico em vez de uma interface de cabo ou globalmente.

• <UGS|AD-UGS|RTPS|NRTPS|BE>: Esse parâmetro especifica o modo de agendamento dos fluxos de serviço aos quais você deseja aplicar o controle de admissão.

• <minor-threshold-percent>: Esse parâmetro indica a porcentagem de utilização de upstream pelo tipo de programação configurado em que um alarme secundário é enviado a uma estação de gerenciamento de rede.

• <major-threshold-percent>: Esse parâmetro especifica a porcentagem de utilização de upstream pelo tipo de programação configurado em que um alarme principal é enviado a uma estação de gerenciamento de rede. Esse valor deve ser superior ao valor definido para o parâmetro <minor-threshold-percent>.

• <unique-threshold-percent>: Este parâmetro representa a porcentagem de utilização de upstream exclusivamente reservada para o tipo de programação especificado. Se você não especificar o valor para <non-excl-threshold-percent>, esse valor representará o limite máximo de utilização para esse tipo de fluxo de serviço. Esse valor deve ser maior que o valor <major-threshold-percent>.

• <sem limiar de percentagem>: Esse parâmetro representa a porcentagem de utilização de upstream acima do <unique-threshold-percent> que esse tipo de agendamento pode usar, desde que outro tipo de agendamento ainda não o utilize.

Por exemplo, suponha que você queira limitar os fluxos de serviço UGS a 60% da largura de banda upstream total disponível. Suponha também que você tenha notificado as estações de gerenciamento de rede de que se a porcentagem de utilização de upstream devido aos fluxos de serviço UGS aumentarem mais de 40%, um alarme secundário deve ser enviado e mais de 50%, um alarme principal deve ser enviado. Emita este comando:

cable Admission-Control us-bandwidth Scheduling-type UGS minor 40 major 50 exclusivo 60

Agendando o tráfego de melhor esforço usando fragmentação

O agendador em conformidade com o DOCSIS simplesmente agenda o tráfego de melhor esforço em relação às concessões UGS ou RTPS pré-alocadas. As figuras nesta seção demonstram esse comportamento.

Figura 10 - Concessões de melhor esforço com programação pendente

A Figura 10 mostra que o upstream tem três fluxos de serviço UGS com o mesmo tamanho de concessão e intervalo de concessão pré-agendados. O upstream recebe solicitações de largura de banda em nome de três fluxos de serviço separados, A, B e C. O fluxo de serviço A solicita uma quantidade média de tempo de transmissão, o fluxo de serviço B solicita uma pequena quantidade de tempo de transmissão e o fluxo de serviço C solicita uma grande quantidade de tempo de transmissão.

Atribua a mesma prioridade a cada um dos fluxos de serviço de melhor esforço. Além disso, suponha que o CMTS receba as solicitações de largura de banda para cada uma dessas concessões na ordem A, B e C. O CMTS primeiro aloca o tempo de transmissão para as concessões na mesma ordem. A Figura 11 mostra como o agendador compatível com DOCSIS aloca essas concessões.

Figura 11 - Concessões de melhor esforço programadas em torno de concessões de fluxo de serviço UGS fixo

O agendador pode apertar as concessões de A e B juntas na lacuna entre os dois primeiros blocos de bolsas UGS. No entanto, a subvenção para C é maior do que qualquer lacuna disponível. Portanto, o agendador em conformidade com o DOCSIS fragmenta a concessão para C em torno do terceiro bloco de concessões UGS em duas concessões menores chamadas C1 e C2. A fragmentação evita atrasos para concessões de UGS e garante que essas concessões não estejam sujeitas ao jitter que o tráfego de melhor esforço causa.

A fragmentação aumenta ligeiramente a sobrecarga do protocolo DOCSIS associada à transmissão de dados. Para cada fragmento extra transmitido, um conjunto extra de cabeçalhos DOCSIS também deve ser transmitido. No entanto, sem fragmentação, o agendador não pode intercalar eficientemente as concessões de melhor esforço entre as concessões UGS fixas. A fragmentação não pode ocorrer para modems a cabo que operam no modo DOCSIS 1.0.

Prioridade

O agendador em conformidade com o DOCSIS coloca concessões que estão aguardando alocação em uma fila com base na prioridade do fluxo de serviço ao qual a concessão pertence. Há oito prioridades de DOCSIS com zero como a mais baixa e sete como a mais alta. Cada uma dessas prioridades tem uma fila associada.

O agendador em conformidade com DOCSIS usa um mecanismo de enfileiramento de prioridade estrita para determinar quando as concessões de prioridade diferente são alocadas no tempo de transmissão. Em outras palavras, todas as concessões armazenadas em filas de alta prioridade devem ser atendidas antes das concessões em filas de prioridade mais baixa.

Por exemplo, suponha que o agendador compatível com DOCSIS receba cinco concessões em um curto período na ordem A, B, C, D, E e F. O agendador enfileira cada uma das concessões na fila que corresponde à prioridade do fluxo de serviço da concessão.

Figura 12: Concessão de prioridades diferentes

O agendador em conformidade com DOCSIS agenda concessões de melhor esforço em torno das concessões de UGS pré-programadas que aparecem como blocos padronizados na Figura 12. A primeira ação que o agendador compatível com DOCSIS toma é verificar a fila de prioridade mais alta. Nesse caso, a fila de prioridade 7 tem concessões prontas para agendamento. O agendador vai adiante e aloca tempo de transmissão para as concessões B e E. Observe que a concessão E precisa de fragmentação para que a concessão não interfira no tempo das concessões de UGS pré-alocadas.

Figura 13 - Agendando concessões de prioridade 7

O agendador garante que todas as concessões de prioridade 7 recebam tempo de transmissão. Em seguida, o agendador verifica a fila de prioridade 6. Nesse caso, a fila de prioridade 6 está vazia, de modo que o agendador passe para a fila de prioridade 5 que contém a concessão C.

Figura 14 - Atribuições de prioridade 5 de agendamento

Em seguida, o agendador prossegue de forma semelhante através das filas de prioridade mais baixa até que todas as filas estejam vazias. Se houver um grande número de concessões a serem agendadas, novas solicitações de largura de banda poderão acessar o CMTS antes que o agendador em conformidade com o DOCSIS conclua a alocação de tempo de transmissão para todas as concessões pendentes. Suponha que o CMTS receba uma solicitação de largura de banda G de prioridade 6 neste ponto do exemplo.

Figura 15 - Uma concessão de prioridade 6 está na fila

Embora conceda A, F e D uma espera maior que a concessão G enfileirada recentemente, o agendador compatível com DOCSIS deve, em seguida, alocar o tempo de transmissão para G porque G tem a prioridade mais alta. Isso significa que as próximas alocações de largura de banda do agendador compatível com DOCSIS serão G, A e D (consulte a Figura 16).

Figura 16 - Agendando concessões de prioridade 6 e prioridade 2

A próxima concessão a ser agendada é F, se você assumir que nenhuma concessão de prioridade mais alta entra no sistema de enfileiramento no tempo médio.

O agendador em conformidade com DOCSIS tem mais duas filas que não foram mencionadas nos exemplos. A primeira fila é a fila usada para programar o tráfego de manutenção de manutenção periódica da estação para manter os modems a cabo on-line. Essa fila é usada para agendar oportunidades para que os modems a cabo enviem o tráfego de keepalive periódico CMTS. Quando o agendador em conformidade com DOCSIS está ativo, essa fila é atendida primeiro antes de todas as outras filas. O segundo é uma fila para concessões alocadas para fluxos de serviço com uma taxa reservada mínima (CIR) especificada. O agendador trata essa fila CIR como uma fila de prioridade 8 para garantir que os fluxos de serviço com uma taxa comprometida recebam o throughput mínimo necessário.

Bolsas de DOCSIS 1.0 não fragmentáveis

A partir dos exemplos na seção anterior, as concessões às vezes precisam ser fragmentadas em várias partes para garantir que o jitter não seja induzido em concessões UGS pré-alocadas. Isso pode ser um problema para modems a cabo que operam no modo DOCSIS 1.0 em segmentos upstream com uma quantidade significativa de tráfego UGS, porque um modem a cabo DOCSIS 1.0 pode pedir para transmitir um quadro que é muito grande para caber na próxima oportunidade de transmissão disponível.

Aqui está outro exemplo, que pressupõe que o agendador receba novas concessões A e B nessa ordem. Suponha também que ambas as concessões têm a mesma prioridade, mas que a concessão B é para um modem a cabo que opera no modo DOCSIS 1.0.

Figura 17 - Subvenções pendentes de DOCSIS 1.1 e DOCSIS 1.0

O agendador tenta alocar o tempo da concessão A primeiro. Em seguida, o agendador tenta alocar a próxima oportunidade de transmissão disponível para conceder B. No entanto, não há espaço para a concessão B permanecer desfragmentada entre A e o próximo bloco de concessões de UGS (veja Figura 18).

Figura 18 - Subvenção B do DOCSIS 1.0 diferida

Por esse motivo, a subvenção B é atrasada até que o segundo bloco de bolsas UGS tenha espaço para a concessão B. Observe que agora há espaço não utilizado antes do segundo bloco de concessões de UGS. Os modems a cabo usam esse tempo para transmitir solicitações de largura de banda ao CMTS, mas isso representa um uso ineficiente da largura de banda.

Revise este exemplo e adicione dois fluxos de serviço UGS extras ao agendador. Embora a concessão A possa ser fragmentada, não há oportunidade para a concessão B não fragmentável ser agendada porque a concessão B é muito grande para caber entre blocos de concessões de UGS. Essa situação deixa o modem a cabo associado à concessão B incapaz de transmitir grandes quadros no upstream.

Figura 19 - A concessão B do DOCSIS 1.0 não pode ser agendada

Você pode permitir que o agendador simplesmente empurre para fora ou atrase um pouco um bloco de concessões de UGS para dar espaço para a concessão B, mas essa ação causa instabilidade no fluxo de serviço de UGS. Por enquanto, se você supõe que deseja minimizar o jitter, esta é uma solução inaceitável.

Para superar esse problema com grandes concessões de DOCSIS 1.0 não fragmentáveis, o agendador compatível com DOCSIS pré-agenda periodicamente blocos de tempo upstream tão grandes quanto o maior quadro que um modem a cabo DOCSIS 1.0 pode transmitir. O agendador faz isso antes que quaisquer fluxos de serviço UGS sejam agendados. Normalmente, esse tempo é equivalente a cerca de 2.000 bytes de transmissão upstream e é chamado de "Bloco não fragmentável" ou "Bloco livre UGS".

O agendador em conformidade com o DOCSIS não coloca nenhuma concessão de estilo UGS ou RTPS nos horários alocados para tráfego não fragmentável de forma a garantir que sempre haja uma oportunidade para grandes concessões DOCSIS 1.0 serem agendadas. Neste sistema, a reserva de tempo para tráfego DOCSIS 1.0 não fragmentável reduz o número de fluxos de serviço UGS que o upstream pode suportar simultaneamente.

A Figura 20 mostra o bloco desfragmentável em azul e quatro fluxos de serviço UGS com o mesmo tamanho de concessão e intervalo de concessão. Não é possível adicionar outro fluxo de serviço UGS do mesmo tamanho de concessão e intervalo de concessão a este upstream porque não é permitido que as concessões UGS sejam agendadas na região azul de bloco não fragmentável.

Figura 20 - O bloco desfragmentável: Não é possível aceitar mais concessões de UGS

Embora o bloco desfragmentável seja programado com menos frequência do que o período de concessão do UGS, esse bloco tende a causar um espaço de largura de banda não alocada tão grande quanto ele mesmo entre todos os blocos de concessão do UGS. Isso oferece ampla oportunidade para que grandes concessões não fragmentáveis sejam agendadas.

Retorne ao exemplo de concessão A e DOCSIS 1.0 Grant B, você pode ver que com o bloco não fragmentável no lugar, o agendador compatível com DOCSIS agora pode agendar com êxito a concessão B após o primeiro bloco de concessões UGS.

Figura 21: Agendando concessões com o uso do bloco não fragmentável

Embora a concessão B do DOCSIS 1.0 tenha sido programada com êxito, ainda há uma pequena lacuna de espaço não utilizado entre a concessão A e o primeiro bloco de concessões UGS. Essa lacuna representa um uso inadequado da largura de banda e demonstra por que você deve usar modems a cabo do modo DOCSIS 1.1 ao implantar serviços UGS.

Cabo padrão-phy-burst

Por padrão em um Cisco uBR CMTS, a maior intermitência que um modem a cabo pode transmitir é de 2.000 bytes. Esse valor para o maior tamanho de intermitência de upstream é usado para calcular o tamanho do bloco não fragmentável como o agendador compatível com DOCSIS usa.

Você pode alterar o maior tamanho de intermitência com o comando cable default-phy-burst max-bytes-allowed-in-burst por interface de cabo.

O parâmetro <max-bytes-allowed-in-burst> tem um intervalo de 0 a 4.096 bytes e um valor padrão de 2.000 bytes. Há algumas restrições importantes sobre como você deve definir esse valor se quiser alterar o valor do valor padrão.

Para interfaces de cabo na placa de linha MC5x20S, não defina este parâmetro acima do padrão de 2000 bytes. Para todos os outros tipos de placa de linha, incluindo as placas de linha MC28U, MC5x20U e MC5x20H, você pode definir esse parâmetro com 4.000 bytes.

Não defina o parâmetro <max-bytes-allowed-in-burst> abaixo do tamanho do maior quadro Ethernet único que um modem a cabo pode precisar transmitir, incluindo DOCSIS ou overhead 802.1q. Isso significa que esse valor não deve ser inferior a aproximadamente 1540 bytes.

Se você definir <max-bytes-allowed-in-burst> para o valor especial de 0, o CMTS não usará esse parâmetro para restringir o tamanho de uma intermitência de upstream. Você precisa configurar outras variáveis para restringir o tamanho da intermitência de upstream a um limite razoável, como a configuração máxima de intermitência concatenada no arquivo de configuração DOCSIS ou o comando cable upstream fragment-force.

Quando você modifica o cabo default-phy-burst para alterar o tamanho máximo do burst de upstream, o tamanho do bloco livre UGS também é modificado de acordo. A Figura 22 mostra que se você reduzir a configuração cable default-phy-burst, o tamanho do bloco livre UGS será reduzido e, consequentemente, o agendador compatível com DOCSIS pode permitir mais chamadas UGS em um upstream. Neste exemplo, reduza o cabo default-phy-burst da configuração padrão de 2000 para uma configuração inferior de 1600 para permitir que mais um fluxo de serviço UGS fique ativo.

Figura 22: A intermitência padrão reduzida diminui o tamanho do bloco desfragmentável

A redução do tamanho máximo de intermitência permitido com o comando cable default-phy-burst pode diminuir ligeiramente a eficiência do upstream para o tráfego de melhor esforço, porque este comando reduz o número de quadros que podem ser concatenados dentro de uma intermitência. Essa redução também pode levar a níveis maiores de fragmentação quando o upstream tem um número maior de fluxos de serviço UGS ativos.

Tamanhos reduzidos de burst concatenado podem afetar a velocidade de upload de dados em um fluxo de serviço de melhor esforço. Isso ocorre porque a transmissão de vários quadros ao mesmo tempo é mais rápida do que a transmissão de uma solicitação de largura de banda para cada quadro. Níveis de concatenação reduzidos também podem potencialmente afetar a velocidade dos downloads devido à diminuição da capacidade do modem a cabo de concatenar grandes números de pacotes TCP ACK que trafegam na direção upstream.

Às vezes, o tamanho máximo de intermitência configurado no IUC "longo" do perfil de modulação de cabo aplicado a um upstream pode determinar o maior tamanho de intermitência de upstream. Isso pode ocorrer se o tamanho máximo de intermitência no perfil de modulação for menor que o valor do cabo default-phy-burst em bytes. Este é um cenário raro. No entanto, se você aumentar o parâmetro cable default-phy-burst do padrão de 2000 bytes, verifique o tamanho máximo de intermitência na configuração do IUC "longo" para garantir que ele não limite as intermitências.

A outra limitação para o tamanho da intermitência de upstream é que um máximo de 255 minisslots podem ser transmitidos em uma intermitência. Isso pode se tornar um fator se o tamanho do minislot for definido para o mínimo de 8 bytes. Um minislot é a menor unidade de transmissão upstream em uma rede DOCSIS e geralmente equivale a 8 ou 16 bytes.

Instabilidade de slot não fragmentável

Outra maneira de ajustar o agendador compatível com DOCSIS para permitir um número maior de fluxos UGS simultâneos em um upstream é permitir que o agendador permita grandes rajadas de tráfego de melhor esforço não fragmentável introduzam pequenas quantidades de jitter para os fluxos de serviço UGS. Você pode fazer isso com o comando de interface de cabo upstream upstream-number unfrag-slot-jitter limit val.

Neste comando, <val> é especificado em microssegundos e tem um valor padrão zero, o que significa que o comportamento padrão do agendador compatível com DOCSIS é não permitir concessões não fragmentáveis para causar instabilidade para fluxos de serviço UGS e RTPS. Quando uma tremulação de slot não fragmentável positiva é especificada, o agendador compatível com DOCSIS pode atrasar as concessões de UGS em até <val> microssegundos a partir de quando a concessão de UGS deve ser idealmente agendada e, portanto, causar instabilidade.

Isto tem o mesmo efeito que a redução do tamanho do bloco desfragmentável por um comprimento equivalente ao número de microssegundos especificado. Por exemplo, se você manter o valor padrão para o default-phy-burst (2000 bytes) e se especificar um valor de 1000 microssegundos para o instabilidade de slot não fragmentável, o bloco não fragmentável será reduzido (consulte a Figura 23).

Figura 23: O tremulador de slot não-zero desfragmentável diminui o tamanho do bloco desfragmentável

Observação: o número de bytes aos quais o tempo de 1000 microssegundos corresponde depende da velocidade com que o canal upstream está configurado para operar através das configurações de largura de canal e esquema de modulação.

Observação: com um instabilidade de slot não-zero não-fragmentável, o agendador compatível com DOCSIS pode aumentar o número de concessões de UGS que um upstream suporta de forma semelhante a ter um burst padrão reduzido.

Observação: retorne ao exemplo com uma grande concessão de DOCSIS 1.1 A seguida de uma grande concessão B de DOCSIS 1.0 não fragmentável para agendar em um upstream. Você define o jitter de slot não fragmentável como 1000 microssegundos. O agendador compatível com DOCSIS se comporta conforme mostrado nas figuras desta seção.

Observação: primeiro, o agendador aloca o tempo de transmissão para a concessão A. Para isso, o agendador fragmenta a bolsa em concessões A₁ e A₂ para que as concessões se enquadrem antes e depois do primeiro bloco de bolsas da UGS. Para agendar a concessão B, o agendador deve decidir se o agendador pode ajustar o bloco não fragmentável no espaço livre após a concessão A₂ sem um atraso no próximo bloco de concessões UGS em mais do que o instabilidade de slot não fragmentável configurado de 1000 microssegundos. Esses números mostram que se o agendador colocar a concessão B ao lado da concessão A₂, o próximo bloco de tráfego UGS será atrasado, ou empurrado para trás, em mais de 1500 microssegundos. Portanto, o agendador não pode colocar a concessão B diretamente após a concessão A₂.

Figura 24 - A concessão B não pode ser agendada ao lado da concessão A2.

A próxima etapa do agendador compatível com DOCSIS é verificar se a próxima lacuna disponível pode acomodar a concessão B. A Figura 25 mostra que se o agendador colocar a concessão B após o segundo bloco de concessões de UGS, o terceiro bloco não será atrasado por mais do que a tremulação de slot não fragmentável configurada de 1000 microssegundos.

Figura 25 - Concessão B agendada após o segundo bloco de concessões de UGS

Com o conhecimento de que a inserção da concessão B neste ponto não causa instabilidade inaceitável para concessões UGS, o programador compatível com DOCSIS insere a concessão B e atrasa ligeiramente o bloco a seguir de concessões UGS.

Figura 26: A concessão B não fragmentável está programada e as concessões de UGS estão atrasadas

saída do comando show

Você pode usar o comando show interface cable interface-number mac-Scheduler upstream-number para medir o status atual do agendador compatível com DOCSIS. Aqui está um exemplo da saída desse comando conforme visto em um Cisco uBR7200VXR com uma placa de linha MC28U.

uBR7200VXR# show interface cable 3/0 mac-scheduler 0
     DOCSIS 1.1 MAC scheduler for Cable3/0/U0
     Queue[Rng Polls] 0/128, 0 drops, max 1
     Queue[CIR Grants] 0/64, 0 drops, max 0
     Queue[BE(7) Grants] 1/64, 0 drops, max 2
     Queue[BE(6) Grants] 0/64, 0 drops, max 0
     Queue[BE(5) Grants] 0/64, 0 drops, max 0
     Queue[BE(4) Grants] 0/64, 0 drops, max 0
     Queue[BE(3) Grants] 0/64, 0 drops, max 0
     Queue[BE(2) Grants] 0/64, 0 drops, max 0
     Queue[BE(1) Grants] 0/64, 0 drops, max 0
     Queue[BE(0) Grants] 1/64, 0 drops, max 1
     Req Slots 36356057, Req/Data Slots 185165
     Init Mtn Slots 514263, Stn Mtn Slots 314793
     Short Grant Slots 12256, Long Grant Slots 4691
     ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0
     ATDMA UGS Grant Slots 0
     Awacs Slots 277629
     Fragmentation count 41
     Fragmentation test disabled
     Avg upstream channel utilization : 26%
     Avg percent contention slots : 73%
     Avg percent initial ranging slots : 2%
     Avg percent minislots lost on late MAPs : 0%
     Sched Table Rsv-state: Grants 0, Reqpolls 0
     Sched Table Adm-State: Grants 6, Reqpolls 0, Util 27%
     UGS    : 6 SIDs, Reservation-level in bps 556800
     UGS-AD : 0 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 35 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 0 SIDs, Reservation-level in bps 0

Esta seção explica cada linha da saída desse comando. Observe que esta seção do documento pressupõe que você já está bastante familiarizado com os conceitos gerais de programação de upstream do DOCSIS.

• Agendador de MAC DOCSIS 1.1 para Cable3/0/U0

  A primeira linha da saída do comando indica a porta upstream à qual os dados pertencem.

• Fila[sondagens em anel] 0/128, 0 quedas, máx. 1

  Esta linha mostra o estado da fila que alimenta keepalives de manutenção da estação ou oportunidades de intervalo no agendador compatível com DOCSIS. 0/128 indica que atualmente há zero em um máximo de 128 oportunidades de intervalo pendentes na fila.

  O contador de quedas indica o número de vezes que uma oportunidade de intervalo não pôde ser enfileirada porque essa fila já estava cheia (ou seja, 128 oportunidades de intervalo pendentes). As quedas aqui ocorreriam somente em um upstream com um número extremamente grande de modems a cabo on-line e se houvesse um grande número de fluxos de serviço UGS ou RTPS ativos. Essa fila é atendida com a prioridade mais alta quando o agendador de reclamações DOCSIS é executado. Portanto, quedas nessa fila são altamente improváveis, mas provavelmente indicam uma sobreassinatura grave do canal upstream.

  O contador máx indica o número máximo de elementos presentes e nesta fila desde que o comando show interface cable mac-scheduler foi executado pela última vez. Idealmente, esta situação deve manter-se o mais próximo possível de zero.

• Queue[CIR Grants] 0/64, 0 drops, max 0

  Esta linha mostra o estado da fila que gerencia concessões para fluxos de serviço com uma taxa de tráfego reservada mínima especificada. Em outras palavras, esses serviços de fila concedem para fluxos de serviço de taxa de informação comprometida (CIR). 0/64 indica que atualmente não há um máximo de 64 concessões pendentes na fila.

  O contador de quedas indica o número de vezes que uma concessão CIR não pôde ser enfileirada porque essa fila já estava cheia (ou seja, 64 concessões na fila). As quedas podem acumular-se aqui se os fluxos de serviço do estilo UGS, RTPS e CIR sobregravarem o upstream e puderem indicar a necessidade de um controle de admissão mais rigoroso.

  O contador máx indica o número máximo de concessões nesta fila desde que o comando show interface cable mac-scheduler foi executado pela última vez. Essa fila tem a segunda prioridade mais alta, de modo que o agendador compatível com DOCSIS aloca tempo para elementos dessa fila antes que o agendador atenda às filas de melhor esforço.

• Fila[BE(w) Grants] x/64, y drops, max z

  As próximas oito entradas mostram o estado das filas que gerenciam as concessões para os fluxos de serviço de prioridade 7 a 0. Os campos nessas entradas têm o mesmo significado dos campos na entrada da fila CIR. A primeira fila a ser atendida neste grupo é a fila BE (7) e a última a ser atendida é a fila BE (0).

  Podem ocorrer quedas nessas filas se um nível de prioridade mais alto de tráfego consumir toda a largura de banda de upstream ou se ocorrer excesso de assinatura do upstream com fluxos de serviço de estilo UGS, RTPS e CIR. Isso pode indicar a necessidade de reavaliar as prioridades do DOCSIS para fluxos de serviço de alto volume ou a necessidade de um controle de admissão mais rigoroso no upstream.

• Slots Req 36356057

  Essa linha indica o número de oportunidades de solicitação de largura de banda anunciadas desde que o upstream foi ativado. Esse número deve estar sempre aumentando.

• Slots de Req/Dados 185165

  Embora o nome sugira que esse campo mostre o número de solicitações ou oportunidades de dados anunciadas no upstream, esse campo realmente mostra o número de períodos anunciados pelo CMTS para facilitar a funcionalidade avançada de gerenciamento de espectro. Espera-se que este contador seja incrementado para fluxos ascendentes em placas de linha de estilo MC28U e MC520.

  As oportunidades de solicitação/dados são iguais às oportunidades de solicitação de largura de banda, exceto que os modems a cabo também podem transmitir pequenas rajadas de dados nesses períodos. Os CMTSs da série Cisco uBR não programam atualmente oportunidades reais de solicitação/dados.

• Inicializar Slots Mtn 514263

  Esta linha representa o número de oportunidades de manutenção iniciais que foram anunciadas desde que o upstream foi ativado. Esse número deve estar sempre aumentando. Os modems a cabo que fazem tentativas iniciais de estabelecer conectividade com o CMTS usam oportunidades de manutenção iniciais.

• Slots Stn Mtn 314793

  Esta linha indica o número de manutenção de estação keepalive ou oportunidades de intervalo oferecidas no upstream. Se houver modems a cabo on-line no upstream, esse número deve estar sempre em ascensão.

• Slots de concessão curta 12256, slots de concessão longa 4691

  Esta linha indica o número de concessões de dados oferecidas no upstream. Se houver modems a cabo que transmitem dados upstream, esses números devem estar continuamente em ascensão.

• Slots 0 de concessão curta ATDMA, Slots 0 de concessão longa ATDMA, Slots 0 de concessão de UGS ATDMA

  Esta linha representa o número de concessões de dados oferecidas no modo avançado de acesso múltiplo por divisão de tempo (ATDMA) no upstream. Se houver modems a cabo que operam no modo DOCSIS 2.0 e eles transmitem dados de upstream, esses números devem estar continuamente em ascensão. Observe que o ATDMA contabiliza separadamente o tráfego UGS.

• Slots Awacs 277629

  Esta linha mostra o número de períodos dedicados ao gerenciamento avançado de espectro. Para que o gerenciamento avançado do espectro ocorra, o CMTS precisa programar periodicamente os horários em que cada modem a cabo deve fazer uma breve transmissão para que a função de análise interna do espectro possa avaliar a qualidade do sinal de cada modem.

• Contagem de fragmentação 41

  Esta linha mostra o número total de fragmentos que a porta upstream está programada para receber. Por exemplo, um quadro que foi fragmentado em três partes faria com que esse contador aumentasse em três.

• Teste de fragmentação desabilitado

  Esta linha indica que o comando test cable fragmentation não foi invocado. Não use esse comando em uma rede de produção.

• Utilização média de canal de upstream: 26%

  Esta linha mostra a utilização atual do canal upstream por transmissões de dados upstream. Isto inclui transmissões feitas através de curtas, longas, curtas de ATDMA, longas de ATDMA e subvenções ATDMA UGS. O valor é calculado a cada segundo como uma média deslocável. A Cisco recomenda que esse valor não exceda 75% em uma base estendida durante os horários de pico de uso. Caso contrário, os usuários finais podem começar a notar problemas de desempenho com tráfego de melhor esforço.

• Percentagem média de conflito de slot: 73%

  Esta linha mostra a porcentagem de tempo de upstream dedicada a solicitações de largura de banda. Isso equivale à quantidade de tempo livre no upstream e, portanto, reduz conforme a porcentagem média de utilização de canal upstream aumenta.

• Porcentagem média de enfileiramento de slots: 2%

  Essa linha indica a porcentagem de tempo upstream dedicada às oportunidades de alcance inicial que os modems a cabo usam quando tentam estabelecer a conectividade inicial com o CMTS. Esse valor deve sempre permanecer uma porcentagem baixa da utilização total.

• Porcentagem média de minislots perdidos nas MAPs atrasadas: 0%

  Essa linha indica o percentual de tempo de upstream que não foi agendado porque o CMTS não conseguiu transmitir uma mensagem MAP de alocação de largura de banda para modems a cabo no tempo. Esse parâmetro deve estar sempre próximo de zero, mas pode começar a mostrar valores maiores em sistemas com uma carga de CPU extremamente alta.

• Rsv-state da tabela agendada: Subvenções 0, Reqpolls 0

  Esta linha mostra o número de fluxos de serviço de estilo UGS (Grant) ou fluxos de serviço de estilo RTPS (Reqpolls) que possuem concessões pré-alocadas para eles no agendador compatível com DOCSIS, mas ainda não ativadas. Isso ocorre quando você move um modem a cabo com fluxos de serviço UGS ou RTPS existentes de um upstream para outro através do balanceamento de carga. Observe que esta figura se aplica somente a concessões que usam o agendador compatível com DOCSIS, e não o agendador LLQ.

• Estado Adm da Tabela Esquecida: Subvenções 6, Reqpolls 0, Util 27%

  Esta linha indica o número de fluxos de serviço de estilo UGS (Grants) ou fluxos de serviço de estilo RTPS (Reqpolls) que possuem concessões pré-alocadas para eles no agendador compatível DOCSIS para esse upstream. Util é a utilização estimada da largura de banda upstream total disponível por esses fluxos de serviço. Observe que esta figura se aplica somente a concessões que usam o agendador compatível com DOCSIS, e não o agendador LLQ.

• <Tipo de agendamento>: x SIDs, nível de reserva em bps por

  Essa linha indica o número de fluxos de serviço ou SIDs <Scheduling-type> presentes no upstream e a quantidade de largura de banda em bits por segundo que esses fluxos de serviço reservaram. Para fluxos de serviço de melhor esforço e estilo RTPS, a largura de banda é reservada somente se o fluxo de serviço tiver uma taxa reservada mínima configurada.

Vantagens e Desvantagens do DOCSIS Compliant Scheduler

O objetivo do agendador em conformidade com DOCSIS é minimizar o jitter para fluxos de serviço de estilo UGS e RTPS e também acomodar rajadas DOCSIS 1.0 não fragmentáveis. A contrapartida que o agendador compatível com DOCSIS faz para atingir essas metas é que o número máximo de fluxos de serviço UGS suportados por upstream é menor que o máximo teórico que um upstream DOCSIS pode suportar fisicamente e que o tráfego de melhor esforço pode estar sujeito a um grau de fragmentação.

Embora o agendador compatível com DOCSIS suporte um pouco menos do que o número máximo teórico de fluxos de serviço UGS simultâneos em um upstream, e enquanto algumas outras implementações de agendamento podem suportar mais fluxos de serviço UGS por upstream, você deve se concentrar na troca.

Por exemplo, nenhum programador pode suportar fluxos de serviço UGS sem jitterless que consomem cerca de 100% de largura de banda de um canal upstream e, simultaneamente, suportar grandes quadros concatenados não fragmentáveis de modems DOCSIS 1.0. No que diz respeito ao projeto do agendador compatível com DOCSIS, há dois pontos importantes para entender.

• 75% é a utilização máxima de upstream desejável.

  A Cisco descobriu que, quando um upstream é executado consistentemente com uma utilização superior a 75%, incluindo a utilização devido aos fluxos de serviço UGS, o desempenho do tráfego de melhor esforço começa a ser visivelmente afetado. Isso significa que se a sinalização UGS e VoIP consumirem mais de 75% do upstream, qualquer tráfego IP normal transmitido pelos fluxos de serviço de melhor esforço começará a sofrer de latência adicional que causa throughput e tempos de resposta consideravelmente menores. Essa degradação do desempenho em níveis de utilização mais altos é uma propriedade que a maioria dos sistemas de rede multiacesso modernos compartilha, por exemplo, LANs Ethernet ou Wireless.

• Quando a largura do canal upstream normalmente implantado de 3,2 MHz é usada, o programador compatível com DOCSIS permite que os fluxos de serviço UGS utilizem até cerca de 75% do canal upstream. Esses fluxos de serviço transmitem chamadas VoIP G.711.

Esses dois pontos dão uma ideia das considerações do projeto que foram levadas em conta quando o agendador em conformidade com DOCSIS foi criado. O agendador compatível com DOCSIS foi projetado de modo que para fluxos de serviço UGS típicos (G.711) e com a largura de canal mais comumente implantada de 3,2 MHz, a chamada por limite de upstream comece a se aplicar em torno da marca de utilização de 75%. Isso significa que o agendador minimiza o jitter com êxito e também permite um número razoável de fluxos de serviço UGS no upstream.

Em outras palavras, o agendador compatível com DOCSIS foi projetado para operar corretamente em redes DOCSIS de produção, e não para permitir que os fluxos de serviço UGS usem uma porcentagem de largura de banda de upstream inrealisticamente alta. Esse cenário pode ocorrer em um cenário de teste de laboratório controlado.

Você pode ajustar o agendador em conformidade com DOCSIS para acomodar um número maior de chamadas UGS por upstream, embora em detrimento do jitter UGS e da eficiência do tráfego de melhor esforço. Para isso, você deve reduzir o parâmetro cable default-phy-burst para a configuração mínima recomendada de 1540 bytes. Se você precisar de mais densidade de chamada, defina o cable upstream unfrag-slot-jitter para um valor como 2000 microssegundos. No entanto, a Cisco não recomenda essas configurações geralmente para uma rede de produção.

Outra vantagem do agendador compatível com DOCSIS é que não há requisito obrigatório de que os operadores CMTS configurem explicitamente o controle de admissão para fluxos de serviço de estilo UGS e RTPS. Isso porque o método de programação de pré-alocação elimina a possibilidade de excesso de assinaturas acidentais. Embora esse seja o caso, a Cisco ainda sugere que os operadores assegurem que a utilização de upstream total não exceda 75% para períodos estendidos durante o horário de pico. Portanto, a Cisco recomenda a configuração do controle de admissão como uma prática recomendada.

Uma desvantagem do programador compatível com DOCSIS é que a posição fixa das concessões de UGS pode exigir a fragmentação das concessões de melhor esforço quando a utilização de UGS é alta. Em geral, a fragmentação não causa problemas de desempenho notáveis, mas leva a um ligeiro aumento na latência para tráfego de melhor esforço e um aumento na sobrecarga do protocolo presente no canal upstream.

Outra desvantagem é que, quando os modems a cabo DOCSIS 1.0 desejam fazer grandes transmissões upstream não fragmentáveis, pode haver um atraso antes que apareça uma lacuna apropriada entre blocos de concessões UGS pré-programadas. Isso também pode levar a um aumento da latência para o tráfego de upstream DOCSIS 1.0 e a um uso inferior ao ideal do tempo de transmissão de upstream disponível.

Por fim, o agendador em conformidade com DOCSIS é projetado para funcionar melhor em ambientes onde todos os fluxos de serviço UGS compartilham o mesmo tamanho de concessão e intervalo de concessão. Ou seja, onde todas as chamadas VoIP compartilham o mesmo codec, como o pacote G.711 de 10ms ou 20ms, como ocorreria em um sistema típico baseado em Packetcable 1.0. Quando intervalos e tamanhos de concessão diferentes estão presentes, a capacidade do agendador compatível com DOCSIS para suportar um alto número de fluxos de serviço UGS diminui em um upstream. Além disso, uma quantidade muito pequena de tremulação (menos de 2 ms) pode ocorrer para algumas concessões quando o agendador tenta intercalar fluxos de serviço UGS com períodos e tamanhos diferentes.

À medida que as redes PacketCable MultiMedia (PCMM) se tornam mais predominantes, elas podem se tornar mais comuns para uma variedade de codecs VoIP com vários intervalos de empacotamento para serem operados simultaneamente. Esse tipo de ambiente pode se emprestar ao Agendador de enfileiramento de baixa latência.

O Agendador de Enfileiramento de Baixa Latência

O programador de LLQ (Low Latency Queueing, enfileiramento de baixa latência) foi introduzido no Cisco IOS Software Release 12.3(13a)BC. O LLQ é o método alternativo para programar serviços upstream em um Cisco uBR CMTS. Este agendador foi projetado para maximizar o número de fluxos de serviço do estilo UGS e RTPS que um upstream pode suportar simultaneamente e também melhorar a eficiência do tráfego de melhor esforço na presença de fluxos de serviço UGS. A troca é que o programador LLQ não faz nenhuma garantia em relação ao jitter para os fluxos de serviço UGS e RTPS.

Como a seção DOCSIS Compliant Scheduler discute, o agendador em conformidade com DOCSIS pré-aloca o tempo de transmissão com antecedência para fluxos de serviço de estilo UGS e RTPS. Isso é semelhante à maneira como um sistema legado de multiplexação por divisão de tempo (TDM) aloca largura de banda a um serviço para garantir certos níveis de latência e jitter.

Em redes modernas baseadas em pacotes, o enfileiramento de baixa latência é o método usado pelos roteadores para garantir que os pacotes associados a serviços de alta prioridade, por exemplo voz e vídeo, possam ser entregues em uma rede antes de outros pacotes de menor prioridade. Esse também é o método que os roteadores modernos usam para garantir que a latência e o jitter sejam minimizados para tráfego importante.

O uso da palavra "garantia" para o sistema baseado em TDM e "minimizado" para o sistema baseado em LLQ em relação ao jitter e à latência. Embora uma garantia de latência zero e jitter seja desejável, a compensação é que esse sistema é geralmente inflexível, difícil de reconfigurar e geralmente incapaz de se adaptar facilmente às alterações nas condições da rede.

Um sistema que minimiza a latência e o jitter, em vez de fornecer uma garantia rigorosa, é capaz de fornecer flexibilidade para se otimizar continuamente diante das mudanças nas condições da rede. O programador de enfileiramento de baixa latência se comporta de maneira semelhante ao sistema de LLQ baseado em roteador de pacote. Em vez de um sistema pré-programado de alocação de bolsas UGS, esse sistema agenda as concessões "o mais rápido possível" no ponto em que elas precisam ser programadas.

A abordagem que concede os fluxos de serviço UGS deve ser alocada o mais rápido possível, mas não necessariamente com uma periodicidade perfeita, esse sistema troca garantias de tremulação rigorosas para aumentar a capacidade UGS e reduzir a fragmentação de dados de melhor esforço.

Configuração

Para o Cisco IOS Software Releases 12.3(13a)BC e posteriores, o programador LLQ é um dos dois algoritmos alternativos do programador. Você pode habilitar o LLQ para um, todos ou alguns destes modos de agendamento:

• UGS

• RTPS

• NRTPS

O agendador LLQ não está ativado por padrão. Você deve ativar explicitamente o agendador LLQ para os tipos de agendamento upstream necessários. Use o tipo de agendamento upstream de porta upstream de cabo [nrtps] | rtps | ugs] mode llq cable interface.

Em geral, você pode habilitar o programador LLQ para todos os modos de agendamento listados se este for o modo de agendamento desejado. Aqui está um exemplo de uma situação em que você deseja habilitar o agendamento LLQ para apenas um tipo de modo de agendamento, mas mantém o agendador em conformidade com DOCSIS para outros:

Os fluxos de serviço de RTPS não têm requisitos rigorosos de instabilidade, mas os fluxos de serviço de UGS têm. Nesse caso, você pode habilitar o programador LLQ para fluxos de serviço RTPS e manter o programador compatível com DOCSIS para UGS.

Operação do Agendador LLQ

O agendador LLQ funciona da mesma forma que a função de enfileiramento de prioridade do agendador compatível com DOCSIS com a adição de uma fila especial de baixa latência (LLQ), que tem precedência sobre todas as outras filas.

O agendador LLQ inicia um temporizador em nome de todos os fluxos de serviço de estilo UGS (e RTPS) ativos. O temporizador é definido para desligar uma vez a cada "intervalo de concessão". Sempre que o temporizador expira, uma concessão de UGS é enfileirada na fila de LLQ. Como essa concessão é colocada na fila LLQ que tem prioridade máxima, a concessão é agendada no próximo momento possível, onde houver espaço livre.

Os diagramas nesta seção mostram um exemplo de um sistema com três fluxos de serviço UGS ativos com o mesmo intervalo de concessão. A Figura 27 mostra os temporizadores dos fluxos de serviço UGS à esquerda, rotulados como UGS-1 a UGS-3. A seta amarela viaja no sentido horário. Quando a seta amarela aponta para cima em direção ao ponto vermelho, uma concessão UGS é adicionada à fila LLQ. Você também pode ver as oito filas de prioridade familiares de 0 a 7 e uma nova fila de LLQ que tem prioridade sobre todas elas. Finalmente, à direita, está a linha do tempo de alocação de largura de banda que descreve como as concessões são agendadas no upstream. Para maior clareza, a linha do tempo de alocação de largura de banda inclui um ponteiro de "hora atual". Este ponteiro avança pela linha do tempo à medida que o exemplo prossegue.

Figura 27 - O sistema de enfileiramento de baixa latência

O primeiro evento que ocorre é que o temporizador UGS-1 na parte superior esquerda expira. Uma concessão correspondente está na fila de LLQ. Ao mesmo tempo, uma concessão de melhor esforço chamada A com prioridade 2 é enfileirada.

Figura 28 - A concessão para UGS-1 e a concessão de prioridade 2 A estão na fila

O agendador LLQ agora aloca tempo de transmissão para as concessões pendentes na ordem de prioridade. A primeira concessão para receber tempo de transmissão é a concessão para UGS-1 que espera na fila LLQ. A concessão A segue.

Figura 29 - Conceder UGS-1 e Conceder A estão alocados para o tempo de transmissão

O próximo evento a ocorrer é que o temporizador UGS-2 expira e faz com que uma concessão para o fluxo de serviço UGS-2 seja enfileirado na fila LLQ. Ao mesmo tempo, uma concessão de prioridade 0 B é enfileirada e a concessão C de prioridade 6 é enfileirada.

Figura 30 - O temporizador UGS-2 expira. As concessões B e C estão na fila

O programador LLQ novamente aloca tempo de transmissão na ordem de prioridade de concessão, o que significa que primeiro o programador aloca tempo para a concessão para UGS-2, depois para a concessão C e, finalmente, para a concessão B.

Figura 31: Conceitos de UGS-2, C e B são Tempo de Transmissão Alocado

Suponha que nenhuma concessão de melhor esforço insira o agendador por um tempo. Os temporizadores UGS expiram algumas vezes mais. Agora você pode ver o tipo de período com o qual o agendador atribui concessões aos fluxos de serviço UGS. Eles parecem estar uniformemente espaçados. Suponha que quando as concessões aparecem dessa forma em relação umas às outras na linha do tempo de alocação de largura de banda, elas não experimentam nenhum jitter significativo.

Figura 32 - UGS-1, UGS-2 e UGS-3 recebem várias concessões. A concessão D está na fila

A Figura 32 indica a posição ideal para a próxima concessão do UGS-2. Se o UGS-2 puder colocar a concessão nesse local, o UGS-2 não experimentará nenhum jitter para a concessão. Observe que ainda há tempo para a próxima concessão de UGS-2 ser enfileirada na fila de LLQ.

A Figura 32 também indica que uma concessão D de prioridade muito grande 0 acabou de entrar na fila de prioridade 0. A próxima ação do programador LLQ é agendar o tempo de transmissão para a concessão D.

A Figura 33 exibe esse cenário. Encaminhe o relógio um pouco até o ponto em que a próxima concessão para UGS-2 é enfileirada.

Figura 33 - Grant D Recebe O Tempo De Transmissão. A concessão para UGS-2 está na fila

A concessão D parece estar agendada no momento em que a próxima concessão UGS-2 deve ser agendada para jitter zero. Agora, a pergunta é por que o agendador LLQ permite que a concessão D seja agendada nesse ponto e não atrasa a concessão D até que a concessão para UGS-2 ou por que D não seja fragmentado. A resposta é que o agendador LLQ não pré-aloca o tempo de transmissão para os fluxos de serviço UGS. Portanto, o agendador LLQ não sabe antecipadamente onde as concessões de UGS serão colocadas na linha de tempo de alocação de largura de banda. O agendador LLQ não sabe sobre concessões de UGS até que eles sejam enfileirados na fila de LLQ. Neste exemplo, quando a concessão para UGS-2 entra na fila, a concessão D já está agendada.

O agendador LLQ agenda a concessão para UGS-2 na próxima oportunidade disponível, mas essa concessão é ligeiramente atrasada em relação à posição ideal, o que, por definição, significa que essa concessão em particular experimenta alguma instabilidade.

Figura 34: A concessão para UGS-2 está atrasada e o jitter de experiências

Embora o agendador em conformidade com DOCSIS possa ter evitado esse jitter, o agendador LLQ evita um atraso ou fragmentação da concessão D à custa de apenas uma pequena quantidade de jitter. Um buffer de jitter em um endpoint VoIP pode facilmente compensar esse jitter.

A outra situação em que o jitter pode ocorrer é quando o temporizador LLQ para vários fluxos de serviço expira ao mesmo tempo e os UGS concedem espera atrás de outras concessões UGS enfileiradas na fila LLQ. O agendador LLQ foi projetado para minimizar a possibilidade dessa ocorrência. O agendador espalha automaticamente os tempos de expiração dos temporizadores de fluxo de serviço.

De acordo com o agendador compatível com DOCSIS, o agendador LLQ tem mais duas filas que os exemplos não mencionam. Aqui estão as filas:

1. A primeira fila é usada para programar o tráfego de manutenção de manutenção de estação periódica para manter os modems a cabo on-line. Essa fila é atendida logo após a fila de LLQ.

2. O segundo é uma fila para concessões alocadas para fluxos de serviço com uma taxa reservada mínima (fluxos de serviço CIR). Essa fila CIR é tratada como uma fila de "prioridade 8" para garantir que os fluxos de serviço com uma taxa comprometida recebam o throughput mínimo necessário.

Controle de admissão

Ao contrário do agendador em conformidade com DOCSIS, o agendador LLQ não usa um sistema de pré-agendamento que interrompe a sobreassinatura acidental de um upstream com fluxos de serviço UGS e RTPS. É por isso que você deve configurar explicitamente o controle de admissão upstream em qualquer upstream que use o agendador LLQ. Essa configuração garante que a largura de banda upstream total dos fluxos de serviço UGS não exceda os limites corretos.

A Cisco geralmente sugere que você não permite que a utilização de um canal upstream exceda 75% em períodos estendidos durante períodos de pico de uso. Por exemplo, se o tráfego UGS consumir mais de 75% da largura de banda de upstream, os dados de melhor esforço começam a sofrer de problemas excessivos de latência e desempenho de throughput.

Naturalmente, se um operador de CMTS pode aceitar as consequências negativas para o tráfego de melhor esforço, você pode permitir que os fluxos de serviço de UGS consumam um valor superior a 75% da largura de banda de upstream disponível. No entanto, você também deve considerar o impacto no tráfego de gerenciamento da Camada 2 no canal upstream. Você deve permitir o tempo para mensagens de manutenção inicial e de estação (keepalives de cable modem). Se você não levar isso em conta, e o tráfego UGS consumir cerca de 100% da largura de banda, os modems a cabo não poderão ficar on-line ou podem ficar off-line.

Aqui está um exemplo de configuração para controle de admissão. Este exemplo restringe os fluxos de serviço UGS em um upstream específico para 50% da largura de banda disponível do upstream. Essa forma do comando também transmite interceptações SNMP para qualquer estação de gerenciamento de rede configurada quando os limiares secundários e principais de 30% e 40% de utilização são atingidos. O comando é:

cable upstream número upstream controle de admissão us tipo de programação de largura de banda UGS menor 30 principais 40 exclusivos 50

Consulte a seção Admission Control na seção DOCSIS Compliant Scheduler deste documento para saber como configurar o controle de admissão.

saída do comando show

Emita o comando show interface cable interface-number mac-Scheduler upstream-number para medir o status atual do programador LLQ.

Aqui está um exemplo da saída desse comando. As partes da saída do comando que são diferentes de quando o agendador compatível com DOCSIS está operacional estão em texto em negrito:

uBR7200VXR# show interface cable 5/0 mac-scheduler 0
     DOCSIS 1.1 MAC scheduler for Cable5/0/U0
     Queue[Rng Polls] 0/128, 0 drops, max 1
     Queue[CIR Grants] 0/64, 0 drops, max 2
     Queue[BE(7) Grants] 0/64, 0 drops, max 0
     Queue[BE(6) Grants] 0/64, 0 drops, max 0
     Queue[BE(5) Grants] 0/64, 0 drops, max 0
     Queue[BE(4) Grants] 0/64, 0 drops, max 0
     Queue[BE(3) Grants] 0/64, 0 drops, max 2
     Queue[BE(2) Grants] 0/64, 0 drops, max 0
     Queue[BE(1) Grants] 0/64, 0 drops, max 0
     Queue[BE(0) Grants] 0/64, 0 drops, max 5
     Queue[LLQ Grants] 0/64, 0 drops, max 3
     Req Slots 165488850, Req/Data Slots 871206
     Init Mtn Slots 1727283, Stn Mtn Slots 1478295
     Short Grant Slots 105668683, Long Grant Slots 52721
     ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0
     ATDMA UGS Grant Slots 0
     Awacs Slots 1303668
     Fragmentation count 11215
     Fragmentation test disabled
     Avg upstream channel utilization : 6%
     Avg percent contention slots : 91%
     Avg percent initial ranging slots : 3%
     Avg percent minislots lost on late MAPs : 0%
     Sched Table Rsv-state: Grants 0, Reqpolls 0
     Sched Table Adm-State: Grants 0, Reqpolls 0, Util 1%
     UGS    : 3 SIDs, Reservation-level in bps 278400
     UGS-AD : 0 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 14 SIDs, Reservation-level in bps 0
     r4k ticks in 1ms 600000
     Total scheduling events 5009
     No search was needed 5009
     Previous entry free 0
     Next entry free 0
     Could not schedule 0
     Recovery failed 0
Curr time 1341 entry 61
Entry 188, Bin 13
    SID: 416 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 188, skew from ref 0, priority 10
    position 188, bin 13
Entry 188, Bin 14
    SID: 414 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 188, skew from ref 0, priority 10
    position 188, bin 14
Entry 192, Bin 12
    SID: 415 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 192, skew from ref 0, priority 10
    position 192, bin 12

Para obter uma explicação das linhas de texto simples nesta saída, consulte a seção Saída do Comando Show para o DOCSIS Compliant Scheduler.

Aqui estão as descrições das linhas em negrito da saída do comando show:

• Fila[concessões LLQ] 0/64, 0 quedas, máx. 3

  Esta linha mostra o estado da fila LLQ, que gerencia concessões para tipos de fluxo de serviço especificados no tipo de agendamento de upstream de cabo [nrtps] | rtps comando | ugs] mode llq. 0/64 indica que atualmente não há um máximo de 64 concessões pendentes na fila.

  O contador de quedas indica o número de vezes que o agendador não pôde enfileirar uma concessão de UGS ou pesquisa RTPS porque essa fila já estava cheia (em outras palavras, quando 64 concessões estão na fila). Se ocorrerem quedas nesta fila, a explicação mais provável é que o upstream está com excesso de assinaturas com fluxos de serviço UGS ou RTPS e você deve aplicar controle de admissão mais rigoroso.

  O contador máx indica o número máximo de concessões nesta fila desde que o comando show interface cable mac-scheduler foi executado pela última vez. Quando presente, essa fila tem a prioridade mais alta de todas as filas listadas.

• pulsos r4k em 1ms 600000

  Este campo representa uma variável de temporização interna que o programador LLQ usa para garantir que as concessões sejam colocadas na fila LLQ com alta precisão.

• Total de eventos de agendamento 5009

  Esta linha indica o número de vezes que o programador LLQ tenta colocar uma concessão em fila desde a última vez que o comando show interface cable mac-scheduler foi executado para esse upstream. Este contador é redefinido sempre que o comando show é executado.

• Nenhuma pesquisa foi necessária 5009

  Depois que o programador LLQ enfileirar uma concessão, o programador LLQ tenta redefinir o temporizador de fluxo de serviço para se preparar para a próxima vez que uma concessão for enfileirada. Se não houver problemas com uma redefinição do temporizador, esse contador será incrementado. O ideal é que este contador tenha o mesmo valor do contador de eventos de agendamento total.

• Entrada anterior livre 0, Próxima entrada livre 0

  Nenhum desses contadores aumenta em versões atuais do Cisco IOS Software. Esses contadores sempre permanecem em zero.

• Não foi possível agendar 0, a recuperação falhou 0

  Esta linha indica o número de vezes que o agendador LLQ não conseguiu organizar para que o temporizador de concessão de um fluxo de serviço fosse definido corretamente. Isso só deve ocorrer se o agendador LLQ tratar um número extremamente grande de concessões com intervalos de concessão muito baixos. É altamente improvável que esses contadores sejam incrementados em uma rede de produção. Um incremento desses contadores pode indicar que os fluxos de serviço UGS e RTPS consomem mais largura de banda do que a fisicamente disponível no upstream. Neste cenário, você precisa implementar os comandos de controle de admissão apropriados.

• Tempo atual 1341 entrada 61

  Esta linha mostra temporizadores internos para o agendador LLQ medidos em milissegundos. Quando a "entrada" listada aqui é igual ao campo "Entrada" listado nas estatísticas de fluxo por serviço, uma concessão é enfileirada na fila LLQ.

Essas estatísticas são repetidas para cada fluxo de serviço que o programador LLQ manipula. Neste exemplo, há três fluxos de serviço desse tipo.

• Entrada 188, Compartimento 13

  Quando o valor "Entry" é igual ao campo "entry" no item anterior, o temporizador para esse fluxo de serviço expira e uma concessão é inserida na fila LLQ. Esse campo é redefinido sempre que o fluxo de serviço tem uma concessão na fila.

• SID: 416

  O SID (Service Identifier, identificador de serviço) para o fluxo de serviço cujo agendador de LLQ é concedido.

• IUC: 5

  O código de uso do intervalo anunciado em uma mensagem MAP para concessões que pertencem a esse fluxo de serviço. Isso é quase sempre 5 para "Dados curtos", 6 para "Dados longos" ou 11 para "UGS PHY avançado" quando um fluxo de serviço de estilo UGS está em uso. Para o fluxo de serviço do estilo RTPS, esse valor é sempre 1 para "Solicitação".

• tamanho_ms: 17 tamanho_byte: 232

  O tamanho da concessão em minislots, seguido do tamanho da concessão em bytes. Um minislot é a menor unidade de transmissão upstream em uma rede DOCSIS e geralmente equivale a 8 ou 16 bytes.

• Frag: N

  Indica se a concessão é fragmentável. No momento, esse valor é sempre definido como N.

• Inválido: 20

  O intervalo de concessão ou sondagem em milissegundos.

• tipo 8

  8 indica que esse fluxo de serviço é UGS, 10 indica RTPS e 11 indica NRTPS.

• tempo perfeito ref 188

  O momento ideal para que esta concessão tenha sido agendada. Normalmente, é o mesmo que "Entry" (Entrada) na parte superior. Caso contrário, há uma indicação de um upstream fortemente congestionado que precisa de um controle de admissão mais rigoroso.

• inclinação de ref 0

  A diferença entre quando essa concessão foi agendada e quando a concessão, idealmente, deve ter sido agendada. Esta é a diferença entre "Entry" e "Perfect Time ref". Portanto, esse valor normalmente deve ser zero.

• prioridade 10

  Nas versões atuais do Cisco IOS Software, esse valor é sempre definido como 10, mas pode variar no futuro.

• posição 188, bin 13

  Esses campos devem ser iguais a "Entrada, Compartimento" no topo da lista.

Vantagens e Desvantagens do Agendador LLQ

O objetivo do programador LLQ é aumentar a capacidade de UGS e RTPS para canais upstream e aumentar a eficiência do tráfego de melhor esforço. A contrapartida que o agendador LLQ faz para atingir essas metas é que esse agendador não oferece explicitamente garantias para instabilidade de fluxo de serviço UGS e RTPS. Em vez disso, o agendador LLQ agenda concessões de UGS e pesquisas RTPS o mais próximo possível do horário ideal, com vista a minimizar a tremulação.

O agendador LLQ também é capaz de lidar melhor com vários fluxos de serviço UGS com intervalos de concessão e tamanhos de concessão diferentes do agendador compatível com DOCSIS. Esse recurso pode ser útil em um ambiente PCMM onde diferentes tipos de chamadas VoIP e possivelmente outros aplicativos são servidos simultaneamente em um canal upstream.

O programador LLQ agenda o tráfego de melhor esforço com mais eficiência porque o programador LLQ reduz a probabilidade de fragmentação de concessões. Quando intermitências DOCSIS 1.0 não fragmentáveis são programadas, o programador LLQ não cria lacunas de largura de banda não utilizada em frente a concessões UGS ou pesquisas RTPS como o programador compatível DOCSIS às vezes. Isso leva a um melhor uso do tempo de upstream disponível.

Embora o jitter UGS seja geralmente maior quando você usa o programador LLQ do que quando você usa o programador compatível com DOCSIS, em redes típicas baseadas em DOCSIS ou em PacketCable, os níveis de jitter do programador LLQ estão bem dentro da capacidade da tecnologia de buffer de jitter de ponto de extremidade VoIP. Isso significa que não há nenhum impacto perceptível na qualidade da chamada VoIP quando você usa o agendador LLQ em uma rede VoIP projetada corretamente.

Você pode limitar o jitter que surge de grandes rajadas de upstream. Para isso, assegure-se de manter o parâmetro cable default-phy-burst no valor padrão de 2000 bytes ou menos. Se um sistema usar um canal upstream particularmente lento, por exemplo, com uma largura de canal de 800 kHz ou menor, você poderá obter reduções adicionais no jitter se forçar grandes rajadas a serem fragmentadas em menores com o comando cable upstream fragment-force.

Quando o agendador LLQ estiver em uso, você deverá configurar o controle de admissão de cabo para evitar a possibilidade de excesso de assinatura do canal upstream. Fluxos de serviço UGS mais ativos do que o upstream pode lidar fisicamente, leva a uma qualidade de voz ruim em todos os fluxos de serviço UGS no upstream. Em casos extremos, isso também significa que os modems a cabo ficam off-line e que os novos modems a cabo não podem ficar on-line. A Cisco recomenda que os operadores CMTS configurem o controle de admissão de modo que a utilização de upstream total em qualquer porta de upstream não esteja acima de 75% para períodos de tempo estendidos.

Conclusões

A série Cisco uBR de produtos DOCSIS CMTS oferece dois algoritmos alternativos de programação de upstream e, portanto, é capaz de atender a uma variedade de condições de rede.

O agendador compatível com DOCSIS, que é otimizado para baixa tremulação, é mais adequado para sistemas de voz Packetcable 1.x típicos com um codec VoIP uniforme instalado e onde os níveis padrão de utilização de canal upstream pelos fluxos de serviço UGS são desejados.

O programador de enfileiramento de baixa latência foi projetado para suportar níveis mais altos que o normal de utilização de upstream pelos fluxos de serviço UGS, maior eficiência de tráfego de melhor esforço e sistemas que usam fluxos de serviço UGS e RTPS com uma variedade de intervalos de concessão e tamanhos de concessão.

Apêndice A: Minislots

Um minislot é a menor unidade de transmissão no upstream do DOCSIS. Quando um modem a cabo transmite uma solicitação de largura de banda ao CMTS para solicitar tempo de transmissão upstream, o modem pergunta em unidades de minislots em vez de em bytes ou milissegundos. Além disso, quando uma mensagem MAP de alocação de largura de banda informa aos modems sobre quando eles podem transmitir e por quanto tempo, a mensagem contém as informações em unidades de minislots.

O número máximo de minisslots que um modem pode solicitar para transmitir em uma intermitência é 255. O tamanho do minislot é especificado em unidades chamadas pulsos DOCSIS. Um pulso DOCSIS é o equivalente a 6,25 microssegundos no tempo.

Para definir o tamanho do minislot em pulsos para uma porta upstream, emita o cabo upstream <upstream-number> minislot-size [1 | 2 | 4 | 8 | 16 | 32 | 64 | 128] comando cable interface.

Apenas determinados tamanhos de minislot são permitidos com larguras de canal upstream específicas. Esta tabela mostra tamanhos de minislot válidos versus larguras de canal de upstream DOCSIS e também mostra o comprimento em símbolos de esquema de modulação de um minislot com configurações válidas.

Observação: uma marca X significa uma combinação inválida.

	Largura do canal	200 kHz	400 kHz	800 kHz	1.6 MHz	3.2 MHz	6.4 MHz
Tamanho do Minislot em pulsos
1		X	X	X	X	X	32
2		X	X	X	X	32	64
4		X	X	X	32	64	128
8		X	X	32	64	128	256
16		X	32	64	128	256	X
32		32	64	128	256	X	X
64		64	128	256	X	X	X
128		128	256	X	X	X	X

Para calcular o número de bytes transmitidos por minislot, multiplique os símbolos por minislot pelo número de bits por símbolo para o esquema de modulação configurado. Esquemas de modulação diferentes transmitem números diferentes de bits por símbolo, conforme mostrado nesta tabela:

Esquemas de modulação de TDMA DOCSIS 1.1	Bits por símbolo
QPSK	2
16-QAM	4

Esquemas de modulação de ATDMA DOCSIS 2.0	Bits por símbolo
8-QAM	3
32-QAM	5
64-QAM	6

Por exemplo, com uma largura de canal de 1,6 MHz e um tamanho de minislot de 4 pulsos, você pode usar a primeira tabela para chegar a uma figura de 32 símbolos por minislot. Use a segunda tabela para converter essa figura em bytes, pois um símbolo QPSK contém 2 bits. Um minislot neste exemplo é equivalente a 32 símbolos por minislot * 2 bits por símbolo = 64 bits por minislot = 8 bytes por minislot.

Lembre-se de que o número máximo de minisslots que um modem a cabo pode solicitar para transmitir é 255. Portanto, neste exemplo upstream, o maior burst em bytes que um modem pode fazer é 255 minislots * 8 bytes por minislot = 2040 bytes.

Observe que essa figura em bytes é a correção de erros pós-encaminhamento e a figura de sobrecarga da camada física. A correção de erros e outra sobrecarga da camada PHY DOCSIS acrescentam cerca de 10 a 20 por cento ao comprimento de um quadro Ethernet à medida que ele passa pelo canal upstream. Para obter a figura precisa, use o perfil de modulação aplicado à porta upstream.

Essa discussão é significativa porque uma seção anterior deste documento afirma que um dos limites no tamanho máximo de intermitência de um modem a cabo é o valor configurado no comando cable default-phy-burst. Se o comando cable default-phy-burst estiver definido como 4000 bytes no contexto deste exemplo, o fator limitante ou o tamanho da intermitência é o limite de 255 minislot (2040 bytes menos sobrecarga) em vez do valor de cable default-phy-burst.

Você pode observar expressões diferentes do tamanho do minislot para um upstream com o comando show controller cable interface-number upstream upstream-number. Aqui está um exemplo:

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group 1, Last Frequency Hop Data Error: NO(0)
  MC28U CNR measurement : better than 40 dB
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 3100
  Ranging Backoff Start 3, Ranging Backoff End 6
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff Start 3, Tx Backoff End 5
  Modulation Profile Group 41
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 8
  Minislot Size in Symbols = 64
  Bandwidth Requests = 0x338C
  Piggyback Requests = 0x66D
  Invalid BW Requests= 0xD9
  Minislots Requested= 0x756C2
  Minislots Granted  = 0x4E09
  Minislot Size in Bytes = 16
  Map Advance (Dynamic) : 2482 usecs
  UCD Count = 8353

A Cisco recomenda que você defina o tamanho do minislot de modo que um minislot seja equivalente a 16 bytes ou o valor mais próximo permitido. Um tamanho de minislot de 16 bytes dá aos modems a cabo a capacidade de gerar uma intermitência pós-FEC de até 255 * 16 = 4096 bytes.

Apêndice B: Avanço do MAP

O CMTS gera periodicamente uma mensagem especial chamada MAP de alocação de largura de banda que informa aos modems a cabo um tempo preciso quando os modems podem fazer transmissões no canal upstream. Os sinais elétricos que transmitem a mensagem MAP levam um tempo finito para se propagarem fisicamente através da rede de coaxial de fibra híbrida (HFC) do CMTS para todos os modems a cabo conectados. Como resultado, a mensagem MAP precisa ser transmitida cedo o suficiente para que os modems recebam a mensagem e possam fazer suas transmissões upstream para que cheguem ao CMTS no momento designado.

O tempo de avanço do MAP ou o tempo de antecipação do MAP representa a diferença entre o tempo em que o CMTS gera a mensagem MAP e o tempo em que a primeira transmissão solicitada pelo MAP precisa ser recebida pelo CMTS. Esse tempo representa uma combinação desses atrasos presentes em um sistema DOCSIS:

• O tempo que o CMTS leva para construir a mensagem MAP no software e para a mensagem ser enfileirada e processada pelo circuito de transmissão de downstream. O valor desse componente é específico de diferentes plataformas e arquiteturas e é geralmente um valor fixo.

• A latência que a função de intercalação downstream adiciona, que é usada para correção de erros de encaminhamento para proteger contra ruído de impulso. Para alterar esse valor, altere os parâmetros do interleaver de downstream.

• O tempo que os sinais elétricos levam para trafegar pela rede HFC do CMTS para o modem a cabo e, em seguida, para voltar. O DOCSIS especifica um tempo máximo de ida e volta entre o CMTS e o modem a cabo de 800 microssegundos. Esse valor varia dependendo do comprimento físico da planta do cabo. O esquema de modulação a jusante e o esquema de modulação e largura de canal a montante também influenciam este valor.

• O tempo para o modem a cabo processar uma mensagem MAP recebida e preparar a transmissão upstream. Ele não deve ter mais de 200 microssegundos além de qualquer retardo do intercalador de upstream de acordo com as diretrizes na especificação DOCSIS. Na realidade, esse tempo pode chegar a 300 microssegundos ou a 100 microssegundos, dependendo da marca, do modelo e da revisão do firmware do modem a cabo.

Figura 35 - Componentes no tempo de avanço do MAP

O tempo de avanço do mapa pode afetar significativamente a latência das transmissões upstream porque esse valor representa o atraso mínimo entre o tempo em que o CMTS sabe que um modem a cabo deseja fazer uma transmissão e o tempo em que o modem tem permissão para fazer essa transmissão. Por esse motivo, minimize o tempo de avanço do mapa para reduzir a latência de upstream.

Observe que em um upstream congestionado, outros fatores também influenciam a latência de upstream. Por exemplo, atrasos que o algoritmo de solicitação de largura de banda de recuo e repetição causa e o enfileiramento de concessões pendentes atrás um do outro.

A Figura 36 mostra a relação entre um MAP gerado pelo CMTS e o recebimento de dados correspondente no upstream.

Figura 36 - Relação entre geração de MAP e recebimento de dados upstream

Profundidade do Interleaver

O primeiro fator no tempo de avanço do mapa que pode variar é o intercalador de downstream como usado para proteção de ruído de impulso. Esta tabela mostra a latência adicionada às transmissões de downstream para várias configurações de aumento de toque de intercalação e intervalo:

Observação: quanto maior o tamanho da torneira, mais poderosa a correção de erros, mas também maior é a latência induzida.

I (Número de toques)	J (incremento)	Latência 64-QAM	Latência 256-QAM
8	16	220 µsec	150 µsec
16	8	480 µsec	330 µseg
32	4	980 µsec	680 µseg
64	2	2000 µsec	1400 µsec
128	1	4000 µsec	2800 µsec
12 (EuroDOCSIS)	17 (EuroDOCSIS)	430 µseg	320 µseg

Você pode definir os parâmetros do interleaver com a profundidade de intercalação de downstream do cabo [8] | 16 | 32 | 64 | 128] comando cable interface configuration

Nota: O valor para I (número de toques) é especificado e um valor fixo correspondente para J (incremento), conforme visto na tabela, aplica-se automaticamente. Além disso, para o modo EuroDOCSIS (anexo A), os parâmetros do interleaver são fixados em I = 12 e J = 17. O valor padrão para I é 32, o que dá um valor padrão para J de 4.

Tempo de ida e volta

O segundo fator que contribui para mapear o tempo de avanço que pode variar é o tempo de ida e volta entre o CMTS e os modems a cabo. A distância física entre o CMTS e os modems a cabo e o atraso de processamento inerente aos modems a cabo influenciam esse valor.

A especificação DOCSIS determina que o tempo máximo permitido de propagação unidirecional entre o CMTS e o modem a cabo mais distante no sistema não seja superior a 800 microssegundos. Isso implica um tempo de ida e volta, excluindo o atraso de processamento do modem a cabo, de aproximadamente 1600 microssegundos.

A velocidade da luz no vácuo é de aproximadamente 186.000 milhas por segundo (300.000 quilômetros por segundo) e a velocidade de propagação da fibra é tipicamente citada como 0,67. Portanto, a distância unidirecional máxima permitida entre um CMTS e um modem a cabo é aproximadamente:

	Distance = Velocity * Time

       		 = (186,000 miles/sec * 0.67) * 800 microseconds

       		 = 100 miles or 161 kilometers.

De acordo com a especificação DOCSIS, o atraso de processamento do modem a cabo não deve exceder 200 microssegundos mais qualquer atraso de intercalação upstream. No entanto, em casos raros, algumas marcas mais antigas de cable modem podem levar até 300 microssegundos para processar uma mensagem MAP. Os tipos mais novos de modems a cabo com CPUs mais potentes podem levar até 100 microssegundos para processar uma mensagem MAP.

Suponha que os modems a cabo sejam, em média, compatíveis com a especificação DOCSIS. Portanto, o tempo máximo de ida e volta deve ser de 1600 + 200 = 1800 microssegundos.

A maioria dos sistemas de cabos é muito menor que 100 milhas. Portanto, não é ideal para um CMTS sempre supor que o tempo de ida e volta entre o CMTS e o modem a cabo mais distante é o valor máximo de 1800 microssegundos.

Para obter uma estimativa aproximada do maior tempo de ida e volta esperado, adicione a distância de fibra entre o CMTS e o modem a cabo e multiplique-se por 16 microssegundos por milha (10 microssegundos por km). Em seguida, adicione a distância de qualquer coaxial e multiplique esse valor por 12,4 microssegundos por milha (7,6 microssegundos por km). Em seguida, adicione o atraso de processamento de 200 microssegundos.

Por exemplo, um segmento HFC com um total de 20 milhas de fibra e um quilômetro de coaxial entre o CMTS e o modem a cabo mais distante pode esperar um atraso de ida e volta elétrico de:

20 miles * 16 microseconds/mile + 1 mile * 12.4 microseconds/mile + 200 microseconds
 
= 320 microseconds + 12.4 microseconds + 200 microseconds

= 532.4 microseconds

Esta figura não leva em conta atrasos extras devido às características dos canais upstream e downstream e variações nos tempos de processamento do modem. Portanto, esse valor não é apropriado para ser usado ao calcular o tempo de avanço do MAP.

Uma maneira mais precisa de determinar o tempo de ida e volta em um sistema é observar o "Deslocamento de tempo" para modems a cabo, conforme visto na saída do comando show cable modem.Como parte do processo de variação que os modems a cabo usam para manter a comunicação com o CMTS, o CMTS calcula o tempo de ida e volta para cada modem a cabo. Esse tempo de ida e volta aparece como o "Deslocamento de tempo" na saída do comando show cable modem em unidades de 1/10,24MHz = 97,7 nanossegundos chamados de deslocamento de temporização ou de intervalo de unidades. Para converter o deslocamento de temporização de um modem em microssegundos, multiplique o valor por 25/256 ou divida o valor por 10.

Aqui está um exemplo em que os deslocamentos de temporização de vários modems na saída do comando show cable modem são convertidos em um valor de microssegundo:

Nota: o valor de microssegundo aparece em itálico.

uBR7200VXR# show cable modem
MAC Address    IP Address   I/F       MAC         Prim RxPwr Timing  Num BPI
                                      State       Sid  (dB)  Offset  CPE Enb
00aa.bb99.0859 4.24.64.28   C5/1/U0   online(pt)  16   0.00  2027     0   Y  (198μs)
00aa.bb99.7459 4.24.64.11   C5/1/U0   online(pt)  17   1.00  3528     0   Y  (345μs)
00aa.bbf3.7258 4.24.64.31   C5/1/U0   online(pt)  18   0.00  2531     0   Y  (247μs)
00aa.bbf3.5658 4.24.64.39   C5/1/U0   online(pt)  19   0.00  6030     0   Y  (589μs)

Nesse caso, o modem mais distante eletricamente é o último modem com um deslocamento de temporização de 6030. Isso equivale a um tempo de ida e volta de 6030 * 25/256 = 589 microssegundos.

Avanço do MAP estático

Em um sistema onde você sabe que o comprimento da rede HFC é significativamente menor que 100 milhas, você pode configurar o CMTS para usar um tempo máximo de ida e volta menor que o padrão de 1800 microssegundos quando você calcula o tempo de avanço do MAP.

Para forçar o CMTS a usar um valor personalizado para o tempo de ida e volta no cálculo de avanço do MAP, emita o comando de interface de cabo cable map-Advance static max-round-trip-time.

O intervalo para o tempo máximo de ida e volta é de 100 a 2.000 microssegundos. Se nenhum valor for especificado para o tempo máximo de ida e volta, o padrão de 1800 microssegundos se aplica.

Observação: você pode substituir a palavra-chave estática pela palavra-chave dinâmica. Veja a próxima seção.

Certifique-se de que o tempo de ida e volta especificado seja realmente maior que o maior CMTS para o tempo de ida e volta do modem a cabo no canal downstream. Se um modem a cabo tiver um tempo de ida e volta maior do que o especificado em max-round-trip-time, o modem pode achar difícil ficar on-line. Isso ocorre porque esse modem não tem tempo suficiente para responder a uma mensagem MAP e, portanto, não consegue se comunicar com o CMTS.

Se o deslocamento de tempo de um modem a cabo, convertido em microssegundos, exceder o tempo máximo de ida e volta especificado, o modem é marcado com o sinalizador de deslocamento de temporização incorreto. Este flag de deslocamento aparece como um ponto de exclamação (!) próximo ao deslocamento de temporização do modem a cabo na saída do comando show cable modem. Essa situação pode ocorrer se o parâmetro max-round-trip-time estiver configurado muito baixo ou se o modem a cabo sofrer de um problema em que seu deslocamento de temporização é instável e aumenta constantemente com o tempo.

Aqui está um exemplo:

uBR7200VXR# show cable modem
MAC Address    IP Address   I/F      MAC         Prim RxPwr  Timing  Num BPI
                                     State       Sid  (dB)   Offset  CPE Enb
00aa.bb99.0859 4.24.64.28   C5/1/U0  online(pt)  16   0.00  2027     0   Y  (198μs)
00aa.bb99.7459 4.24.64.11   C5/1/U0  online(pt)  17   1.00  3528     0   Y  (345μs)
00aa.bbf3.7258 4.24.64.31   C5/1/U0  online(pt)  18   0.00  2531     0   Y  (247μs)
00aa.bbf3.5658 4.24.64.39   C5/1/U0  online(pt)  19   0.00  !5120    0   Y  (500μs)

Neste exemplo, o comando cable map-Advance static 500 é especificado. No entanto, um dos modems a cabo conectados à interface do cabo tem um deslocamento de temporização superior a 500 microssegundos (equivalente a 500 * 256/25 = 5120 unidades de deslocamento de temporização).

Observe que o deslocamento de temporização do último modem a cabo é marcado com o indicador de deslocamento de temporização inválido, um "!". Isso também é fixo ao valor máximo permitido de 5120 unidades, mesmo que o deslocamento de temporização real possa ser muito maior. Esse modem a cabo pode ficar off-line e sofrer um desempenho ruim.

A flag de deslocamento de temporização ruim permanece definida para o modem a cabo mesmo que o deslocamento de temporização caia abaixo do tempo máximo de ida e volta. A única maneira de limpar o sinalizador é remover temporariamente o modem da lista de show cable modem. Para isso, você pode usar o comando clear cable modem mac-address delete. Como alternativa, você pode redefinir a interface do cabo ou a porta upstream.

Para observar a operação do algoritmo de avanço de mapa estático por upstream, emita o comando show controller cable interface-number upstream upstream-number. Aqui está um exemplo:

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group is overridden
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 2037
  Ranging Backoff automatic (Start 0, End 3)
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff automatic (Start 0, End 3)
  Modulation Profile Group 43
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 16
  Minislot Size in Symbols = 128
  Bandwidth Requests = 0x6ECEA
  Piggyback Requests = 0xDE79
  Invalid BW Requests= 0x63D
  Minislots Requested= 0x8DEE0E
  Minislots Granted  = 0x7CE03
  Minislot Size in Bytes = 32
  Map Advance (Static) : 3480 usecs
  UCD Count = 289392

O campo Avanço do mapa (estático) mostra um tempo de avanço do mapa de 3480 microssegundos. Se você alterar as características do intercalador de downstream ou o parâmetro max-round-trip-time, a alteração será refletida no valor do avanço do mapa estático.

Avanço de MAP dinâmico

O uso do cálculo do avanço do MAP estático para otimizar os tempos de avanço do MAP exige que o operador do CMTS determine manualmente o maior tempo de ida e volta em um segmento de cabo. Se alguma característica do canal downstream ou upstream mudar, ou se alguma condição da fábrica mudar, o tempo máximo de ida e volta pode mudar significativamente. Pode ser difícil atualizar continuamente a configuração para acomodar a alteração nas condições do sistema.

O algoritmo avançado MAP dinâmico resolve esse problema. O algoritmo de avanço do MAP dinâmico verifica periodicamente a lista de show cable modem para procurar o modem com o maior desvio de temporização inicial e, em seguida, usa automaticamente esse valor para calcular o tempo de avanço do MAP. Assim, o CMTS sempre usa o menor tempo possível de avanço de mapa.

O deslocamento de temporização de intervalo inicial para um modem a cabo é o deslocamento de temporização que o modem relata no ponto em que o modem entra on-line. Na maioria dos casos, isso é próximo ao deslocamento de temporização em andamento, como visto na saída do comando show cable modem. No entanto, alguns tipos de modems a cabo têm um problema em que o deslocamento de temporização oscila para cima ao longo do tempo para valores muito grandes. Isso pode distorcer o cálculo do tempo de avanço do mapa. Portanto, somente o deslocamento de temporização de variação inicial, que é atualizado somente se um modem estiver on-line, é usado. Para visualizar o deslocamento de temporização de intervalo inicial e o deslocamento de temporização contínuo de um modem a cabo, emita o comando show cable modem verbose. Aqui está um exemplo:

uBR7200VXR# show cable modem 00aa.bbf3.7858 verbose
MAC Address                         : 00aa.bbf3.7858
IP Address                          : 4.24.64.18
Prim Sid                            : 48
Interface                           : C5/1/U0
Upstream Power                      : 39.06 dBmV (SNR = 36.12 dB)
Downstream Power                    : 14.01 dBmV (SNR = 35.04 dB)
Timing Offset                       : 2566
Initial Timing Offset               : 2560
Received Power                      :  0.00 dBmV
MAC Version                         : DOC1.1
QoS Provisioned Mode                : DOC1.1
Enable DOCSIS2.0 Mode               : Y
Phy Operating Mode                  : tdma
Capabilities                        : {Frag=Y, Concat=Y, PHS=Y, Priv=BPI+}
Sid/Said Limit                      : {Max US Sids=16, Max DS Saids=15}
Optional Filtering Support          : {802.1P=N, 802.1Q=N}
Transmit Equalizer Support          : {Taps/Symbol= 1, Num of Taps= 8}
Number of CPE IPs                   : 0(Max CPE IPs = 16)
CFG Max-CPE                         : 32
Flaps                               : 4(Mar 13 21:13:50)
Errors                              : 0 CRCs, 0 HCSes
Stn Mtn Failures                    : 0 aborts, 1 exhausted
Total US Flows                      : 1(1 active)
Total DS Flows                      : 1(1 active)
Total US Data                       : 321 packets, 40199 bytes
Total US Throughput                 : 129 bits/sec, 0 packets/sec
Total DS Data                       : 28 packets, 2516 bytes
Total DS Throughput                 : 0 bits/sec, 0 packets/sec
Active Classifiers                  : 0 (Max = NO LIMIT)
DSA/DSX messages                    : permit all
Total Time Online                   : 1h00m

Neste exemplo, o deslocamento de tempo em curso (2566) é ligeiramente superior ao deslocamento de tempo de intervalo inicial (2560). Esses valores podem diferir ligeiramente. No entanto, se os valores forem diferentes em mais de algumas centenas de unidades, pode haver um problema com o controle de deslocamento de temporização do modem a cabo.

Para ativar o cálculo de avanço do mapa dinâmico, emita o comando de interface de cabo cable map-Advance dynamic Safety-fator max-round-trip-time.

O parâmetro do fator de segurança varia de 100 a 2000 microssegundos. Este parâmetro é adicionado ao tempo de avanço do MAP para fornecer uma pequena salvaguarda para levar em conta quaisquer atrasos imprevistos na propagação do sinal. O valor padrão é 1000 microssegundos. No entanto, para sistemas de cabos estáveis que não sofram alterações significativas na planta de cabos ou nas características de canais upstream ou downstream, use um valor mais baixo, como 500 microssegundos.

O parâmetro max-round-trip-time varia de 100 a 2000 microssegundos. Esse parâmetro é usado como um limite superior para os deslocamentos de tempo dos modems a cabo conectados ao segmento do cabo. O valor padrão é 1800 microssegundos. Se o deslocamento de tempo de um modem a cabo, convertido em microssegundos, exceder o tempo máximo de ida e volta especificado, ele aparecerá marcado com o sinalizador de deslocamento de temporização incorreto.

Defina o parâmetro max-round-trip time como um valor não padrão quando você souber que o comprimento do sistema de cabos é significativamente menor que 100 milhas e se você souber qual deve ser o deslocamento de tempo normal máximo para modems a cabo conectados ao segmento.

Observe a operação do algoritmo de avanço do mapa dinâmico por upstream com o comando show controller cable interface-number upstream upstream-number. Aqui está um exemplo:

uBR7200VXR# show controller cable 5/0 upstream 0
 Cable5/0 Upstream 0 is up
  Frequency 20.600 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
  This upstream is mapped to physical port 0
  Spectrum Group 1, Last Frequency Hop Data Error: NO(0)
  MC28U CNR measurement : better than 40 dB
  US phy MER(SNR)_estimate for good packets - 36.1280 dB
  Nominal Input Power Level 0 dBmV, Tx Timing Offset 3100
  Ranging Backoff Start 3, Ranging Backoff End 6
  Ranging Insertion Interval automatic (60 ms)
  US throttling off
  Tx Backoff Start 3, Tx Backoff End 5
  Modulation Profile Group 41
  Concatenation is enabled
  Fragmentation is enabled
  part_id=0x3138, rev_id=0x03, rev2_id=0x00
  nb_agc_thr=0x0000, nb_agc_nom=0x0000
  Range Load Reg Size=0x58
  Request Load Reg Size=0x0E
  Minislot Size in number of Timebase Ticks is = 8
  Minislot Size in Symbols = 64
  Bandwidth Requests = 0x338C
  Piggyback Requests = 0x66D
  Invalid BW Requests= 0xD9
  Minislots Requested= 0x756C2
  Minislots Granted  = 0x4E09
  Minislot Size in Bytes = 16
  Map Advance (Dynamic) : 2482 usecs
  UCD Count = 8353

O valor do deslocamento de temporização Tx mostra o maior deslocamento de temporização para todos os modems a cabo conectados ao upstream em unidades de deslocamento de temporização. Use este valor para calcular o tempo de avanço do MAP. O campo Avanço do mapa (Dinâmico) mostra o tempo de avanço do mapa resultante. Esse valor pode variar se o deslocamento de temporização de transmissão for alterado, se o valor de segurança for modificado ou se as características do intercalador de downstream forem alteradas.

O algoritmo de avanço do MAP dinâmico depende se os modems a cabo reportam corretamente seu deslocamento de temporização de intervalo inicial ao CMTS. Infelizmente, algumas marcas e modelos de modems a cabo relatam os deslocamentos de temporização de intervalo inicial como valores significativamente inferiores ao valor real. Você pode observá-lo quando os modems mostrarem os deslocamentos de temporização próximos de zero ou mesmo negativos.

Mensagens de erro semelhantes a %UBR7200-4-BADTXOFFSET: Deslocamento de temporização ruim -2 detectado para modem a cabo 00ff.0bad.caf3 pode aparecer nesses modems a cabo. Esses tipos de modems a cabo não relatam seus deslocamentos de temporização de forma compatível com DOCSIS, o algoritmo de avanço de mapa dinâmico não pode calcular corretamente um tempo de avanço de mapa garantido para dar a cada modem a cabo tempo para receber e responder a mensagens MAP.

Se tais modems a cabo estiverem presentes em um segmento de cabo, desative o algoritmo de avanço do MAP dinâmico e reverta para o algoritmo de avanço do MAP estático. Consulte Por que alguns modems a cabo exibem um deslocamento de tempo negativo? para obter mais informações.

Informações Relacionadas

• Suporte Técnico e Documentação - Cisco Systems

Histórico de revisões