Configuración del Modo de Planificador Ascendente para Cisco uBR CMTS

Introducción

Este documento explica la configuración del modo programador ascendente para Cisco Universal detallada Router (uBR) Series de Cable Modem Termination Systems (CMTS).

Este documento se centra en el personal que trabaja con el diseño y mantenimiento de redes de datos a través de cable de alta velocidad que hacen uso de servicios ascendentes sensibles a la latencia y a la fluctuación, por ejemplo, voz o vídeo a través de IP.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Sistemas de especificación de interfaz de servicio de datos sobre cable (DOCSIS)

• La serie uBR de Cisco CMTS

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Cisco uBR CMTS

• Cisco IOS® Software Release entrena 12.3(13a)BC y 12.3(17a)BC

Nota: Para obtener información sobre los cambios en las versiones posteriores del software Cisco IOS, consulte las notas de la versión correspondientes disponibles en el sitio web Cisco.com.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Antecedentes

En una red DOCSIS (Data-over-Cable Service Interface Specifications), el CMTS controla el tiempo y la velocidad de todas las transmisiones ascendentes que realizan los cablemódems. Muchos tipos diferentes de servicios con diferentes requisitos de latencia, fluctuación y rendimiento se ejecutan simultáneamente en una red DOCSIS moderna ascendente. Por lo tanto, debe entender cómo decide el CMTS cuándo un cablemódem puede realizar transmisiones ascendentes en nombre de estos diferentes tipos de servicios.

Este informe técnico incluye:

• Descripción general de los modos de programación ascendente en DOCSIS, incluidos el mejor esfuerzo, el servicio de concesión no solicitado (UGS) y el servicio de sondeo en tiempo real (RTPS)

• Funcionamiento y configuración del planificador conforme a DOCSIS para Cisco uBR CMTS

• El funcionamiento y la configuración del nuevo planificador de cola de baja latencia para Cisco uBR CMTS

Programación ascendente en DOCSIS

Un CMTS compatible con DOCSIS puede proporcionar diferentes modos de programación ascendente para diferentes flujos de paquetes o aplicaciones a través del concepto de flujo de servicio. Un flujo de servicio representa un flujo de datos ascendente o descendente que un ID de flujo de servicio (SFID) identifica de forma única. Cada flujo de servicio puede tener sus propios parámetros de calidad de servicio (QoS), por ejemplo, rendimiento máximo, rendimiento garantizado mínimo y prioridad. En el caso de los flujos de servicio ascendentes, también puede especificar un modo de programación.

Puede tener más de un flujo de servicio ascendente para cada cablemódem para alojar diferentes tipos de aplicaciones. Por ejemplo, la Web y el correo electrónico pueden utilizar un flujo de servicio, la voz sobre IP (VoIP) puede utilizar otro y los juegos por Internet pueden utilizar otro flujo de servicio. Para poder proporcionar un tipo adecuado de servicio para cada una de estas aplicaciones, las características de estos flujos de servicio deben ser diferentes.

El cablemódem y CMTS pueden dirigir los tipos correctos de tráfico a los flujos de servicio apropiados con el uso de clasificadores. Los clasificadores son filtros especiales, como las listas de acceso, que coinciden con las propiedades del paquete, como los números de puerto UDP y TCP, para determinar el flujo de servicio adecuado para que los paquetes viajen.

En la Figura 1, un cable módem tiene tres flujos de servicio ascendentes. El primer flujo de servicio está reservado para el tráfico de voz. Este flujo de servicio tiene un rendimiento máximo bajo pero también está configurado para proporcionar una garantía de baja latencia. El siguiente flujo de servicio es para el tráfico web y de correo electrónico general. Este flujo de servicio tiene un alto rendimiento. El flujo de servicio final está reservado para el tráfico de igual a igual (P2P). Este flujo de servicio tiene un rendimiento máximo más restrictivo para reducir la velocidad de esta aplicación.

Figura 1: Un cablemódem con tres flujos de servicio ascendentes

Los flujos de servicio se establecen y activan cuando un cablemódem se conecta por primera vez. Aprovisione los detalles de los flujos de servicio en el archivo de configuración DOCSIS que utiliza para configurar el cable módem. Aprovisionar al menos un flujo de servicio para el tráfico ascendente y otro flujo de servicio para el tráfico descendente en un archivo de configuración DOCSIS. Los primeros flujos de servicio ascendente y descendente que se especifican en el archivo de configuración DOCSIS se denominan flujos de servicio primario.

Los flujos de servicio también se pueden crear y activar dinámicamente después de que un cablemódem se conecte. Este escenario generalmente se aplica a un flujo de servicio, que corresponde a los datos que pertenecen a una llamada telefónica VoIP. Este flujo de servicio se crea y se activa cuando comienza una conversación telefónica. El flujo de servicio se desactiva y elimina cuando finaliza la llamada. Si el flujo de servicio existe solamente cuando es necesario, puede ahorrar recursos de ancho de banda ascendente y carga de CPU del sistema y memoria.

Los cablemódems no pueden realizar transmisiones ascendentes en cualquier momento. En su lugar, los módems deben esperar las instrucciones del CMTS antes de que puedan enviar datos, porque sólo un cable módem puede transmitir datos en un canal ascendente a la vez. De lo contrario, las transmisiones pueden desbordarse y dañarse mutuamente. Las instrucciones para cuándo un cablemódem puede hacer una transmisión vienen del CMTS en forma de un mensaje de asignación de ancho de banda MAP. Cisco CMTS transmite un mensaje MAP cada 2 milisegundos para indicar a los cablemódems cuándo pueden realizar una transmisión de cualquier tipo. Cada mensaje MAP contiene información que indica a los módems exactamente cuándo hacer una transmisión, cuánto tiempo puede durar la transmisión y qué tipo de datos pueden transmitir. Por lo tanto, las transmisiones de datos del cablemódem no chocan entre sí y evitan la corrupción de los datos. Esta sección trata sobre algunas de las maneras en las que un CMTS puede determinar cuándo conceder un permiso de cablemódem para hacer una transmisión en el flujo ascendente.

Mejor esfuerzo

La programación con el mejor esfuerzo es adecuada para las aplicaciones clásicas de Internet sin un requisito estricto de latencia o fluctuación. Algunos ejemplos de estos tipos de aplicaciones son el correo electrónico, la navegación web o la transferencia de archivos de igual a igual. La programación con el mejor esfuerzo no es adecuada para aplicaciones que requieren latencia o fluctuación garantizadas, por ejemplo, voz o vídeo sobre IP. Esto se debe a que en condiciones de congestión no se puede hacer tal garantía en el modo de mejor esfuerzo. Los sistemas DOCSIS 1.0 solo permiten este tipo de programación.

Los flujos de servicio de mejor esfuerzo se suelen aprovisionar en el archivo de configuración DOCSIS asociado a un cablemódem. Por lo tanto, los flujos de servicio de mejor esfuerzo generalmente se activan tan pronto como el cable módem se conecta. El flujo de servicio ascendente principal, que es el primer flujo de servicio ascendente que se aprovisiona en el archivo de configuración DOCSIS, debe ser un flujo de servicio estilo de mejor esfuerzo.

Estos son los parámetros más utilizados que definen un flujo de servicio de mejor esfuerzo en el modo DOCSIS 1.1/2.0:

• Velocidad máxima de tráfico sostenido (R)

  La velocidad máxima de tráfico sostenido es la velocidad máxima a la que el tráfico puede funcionar a través de este flujo de servicio. Este valor se expresa en bits por segundo.

• Ráfaga de tráfico máxima (B)

  La ráfaga de tráfico máxima se refiere al tamaño de ráfaga en bytes que se aplica al limitador de velocidad de cubeta con ficha que aplica los límites de rendimiento ascendente. Si no se especifica ningún valor, se aplica el valor predeterminado de 3044, que es el tamaño de dos tramas ethernet completas. Para las velocidades de tráfico sostenidas máximas de gran tamaño, establezca este valor en al menos la velocidad de tráfico sostenida máxima dividida por 64.

• Prioridad de tráfico

  Este parámetro se refiere a la prioridad del tráfico en un flujo de servicio que va desde 0 (el más bajo) hasta 7 (el más alto). En el flujo ascendente, todo el tráfico pendiente para flujos de servicio de alta prioridad se programa para la transmisión antes que el tráfico para flujos de servicio de baja prioridad.

• Tasa reservada mínima

  Este parámetro indica un rendimiento mínimo garantizado en bits por segundo para el flujo de servicio, similar a una velocidad de información comprometida (CIR). Las tarifas mínimas combinadas reservadas para todos los flujos de servicio en un canal no deben exceder el ancho de banda disponible en ese canal. De lo contrario, es imposible garantizar las tasas mínimas reservadas prometidas.

• Ráfaga máxima concatenada

  La ráfaga concatenada máxima es el tamaño en bytes de la transmisión más grande de tramas concatenadas que un módem puede hacer en nombre del flujo de servicio. Como implica este parámetro, un módem puede transmitir varias tramas en una ráfaga de transmisión. Si no se especifica este valor, los cablemódems DOCSIS 1.0 y los módems DOCSIS 1.1 más antiguos asumen que no hay un límite explícito establecido en el tamaño de ráfaga concatenada. Los módems que cumplen con las revisiones más recientes de las especificaciones DOCSIS 1.1 o posteriores utilizan un valor de 1522 bytes.

Cuando un cablemódem tiene datos para transmitir en nombre de un flujo de servicio ascendente de mejor esfuerzo, el módem simplemente no puede reenviar los datos a la red DOCSIS sin demora. El módem debe pasar por un proceso en el que el módem solicita un tiempo de transmisión ascendente exclusivo del CMTS. Este proceso de solicitud asegura que los datos no colisionen con las transmisiones de otro cable módem conectado al mismo canal ascendente.

A veces el CMTS programa ciertos periodos en los que el CMTS permite a los cablemódems transmitir mensajes especiales llamados solicitudes de ancho de banda. La solicitud de ancho de banda es una trama muy pequeña que contiene detalles de la cantidad de datos que el módem desea transmitir, además de un identificador de servicio (SID) que corresponde al flujo de servicio ascendente que necesita transmitir los datos. El CMTS mantiene una tabla interna que coincide con los números SID con los flujos de servicio ascendentes.

El CMTS programa las oportunidades de solicitud de ancho de banda cuando no hay otros eventos programados en el flujo ascendente. En otras palabras, el planificador proporciona oportunidades de solicitud de ancho de banda cuando el planificador ascendente no ha planificado una concesión de mejor esfuerzo, o una concesión UGS o algún otro tipo de concesión para colocarse en un punto determinado. Por lo tanto, cuando un canal ascendente se utiliza intensamente, existen menos oportunidades para que los cablemódems transmitan solicitudes de ancho de banda.

El CMTS siempre se asegura de que se programe regularmente un pequeño número de oportunidades de solicitud de ancho de banda, sin importar cuán congestionado se vuelva el canal ascendente. Varios cablemódems pueden transmitir solicitudes de ancho de banda al mismo tiempo y corromper las transmisiones de los demás. Para reducir el potencial de colisiones que pueden dañar las solicitudes de ancho de banda, se ha implementado un algoritmo de "reenvío y reintento". En las secciones siguientes de este documento se analiza este algoritmo.

Cuando CMTS recibe una solicitud de ancho de banda de un cablemódem, el CMTS realiza estas acciones:

1. El CMTS utiliza el número SID recibido en la solicitud de ancho de banda para examinar el flujo de servicio con el que se asocia la solicitud de ancho de banda.

2. El CMTS luego utiliza el algoritmo de cubeta con ficha. Este algoritmo ayuda al CMTS a verificar si el flujo de servicio excederá la velocidad máxima sostenida prescrita si el CMTS otorga el ancho de banda solicitado. Aquí está el cálculo del algoritmo de cubeta con ficha:

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

   where:

   • Max(T) indica el número máximo de bytes que se pueden transmitir en el flujo de servicio a lo largo del tiempo T.

   • T representa el tiempo en segundos.

   • R indica la velocidad de tráfico sostenida máxima para el flujo de servicio en bits por segundo

   • B es la ráfaga de tráfico máxima para el flujo de servicio en bytes.

3. Cuando el CMTS se asegura de que la solicitud de ancho de banda está dentro de los límites de rendimiento, el CMTS pone en cola los detalles de la solicitud de ancho de banda al programador ascendente. El programador ascendente decide cuándo conceder la solicitud de ancho de banda.

   Cisco uBR CMTS implementa dos algoritmos de programador ascendente, denominados el planificador conforme con DOCSIS y el planificador de cola de latencia baja. Vea la sección Planificador conforme con DOCSIS y la sección Planificador de cola de latencia baja de este documento para obtener más información.

4. El CMTS luego incluye estos detalles en el siguiente mensaje de asignación periódica de ancho de banda MAP:

   • Cuando el cable módem puede transmitir.

   • Durante cuánto tiempo puede transmitir el cable módem.

Algoritmo de retroceso y reintento de solicitud de ancho de banda

El mecanismo de solicitud de ancho de banda emplea un algoritmo simple de "retorno y reintento" para reducir, pero no eliminar totalmente, el potencial de colisiones entre varios cablemódems que transmiten solicitudes de ancho de banda simultáneamente.

Un cablemódem que decide transmitir una solicitud de ancho de banda primero debe esperar a que pase una cantidad aleatoria de oportunidades de solicitud de ancho de banda antes de que el módem realice la transmisión. Este tiempo de espera ayuda a reducir la posibilidad de colisiones que se producen debido a las transmisiones simultáneas de solicitudes de ancho de banda.

Dos parámetros llamados inicio de retroceso de datos y fin de retroceso de datos determinan el período de espera aleatorio. Los cablemódems aprenden estos parámetros como parte del contenido del mensaje del descriptor de canal ascendente periódico (UCD). El CMTS transmite el mensaje UCD en nombre de cada canal ascendente activo cada dos segundos.

Estos parámetros de retroceso se expresan como valores de "potencia de dos". Los módems utilizan estos parámetros como potencias de dos para calcular cuánto tiempo esperar antes de transmitir las solicitudes de ancho de banda. Ambos valores tienen un rango de 0 a 15 y el final de la retroceso de datos debe ser mayor o igual que el inicio de la retroceso de datos.

La primera vez que un cablemódem desea transmitir una solicitud de ancho de banda determinada, el cablemódem primero debe elegir un número aleatorio entre 0 y 2 a la potencia del inicio de la retransmisión de datos menos 1. Por ejemplo, si el inicio de la retroceso de datos se establece en 3, el módem debe elegir un número aleatorio entre 0 y (2³ - 1) = (8 - 1) = 7.

El cablemódem debe esperar a que pase el número aleatorio seleccionado de oportunidades de transmisión de solicitud de ancho de banda antes de que el módem transmita una solicitud de ancho de banda. Por lo tanto, si bien un módem no puede transmitir una solicitud de ancho de banda en la siguiente oportunidad disponible debido a este retraso forzado, la posibilidad de una colisión con la transmisión de otro módem se reduce.

Naturalmente, cuanto mayor sea el valor de inicio de la retransmisión de datos, menor será la posibilidad de colisiones entre solicitudes de ancho de banda. Los valores de inicio de la retroceso de datos mayores también significan que los módems tienen que esperar más para transmitir solicitudes de ancho de banda, por lo que la latencia ascendente aumenta.

El CMTS incluye un reconocimiento en el siguiente mensaje de asignación de ancho de banda transmitido MAP. Este reconocimiento informa al cablemódem que la solicitud de ancho de banda se recibió correctamente. Este reconocimiento puede:

• o bien indique exactamente cuándo el módem puede realizar la transmisión

  O

• solo indique que se ha recibido la solicitud de ancho de banda y que se decidirá un tiempo de transmisión en un mensaje MAP futuro.

Si el CMTS no incluye un reconocimiento de la solicitud de ancho de banda en el siguiente mensaje MAP, el módem puede concluir que la solicitud de ancho de banda no fue recibida. Esta situación puede ocurrir debido a una colisión o ruido ascendente, o porque el flujo de servicio excede la velocidad de rendimiento máxima prescrita si se concede la solicitud.

En cualquier caso, el siguiente paso para el cablemódem es retroceder e intentar transmitir la solicitud de ancho de banda de nuevo. El módem aumenta el rango sobre el cual se elige un valor aleatorio. Para ello, el módem agrega uno al valor de inicio de la retroceso de datos. Por ejemplo, si el valor de inicio de la retransmisión de datos es 3 y el CMTS no recibe una transmisión de solicitud de ancho de banda, el módem espera un valor aleatorio entre 0 y 15 oportunidades de solicitud de ancho de banda antes de la retransmisión. Aquí está el cálculo: 23+1 - 1 = 24 - 1 = 16 - 1 = 15

El rango más amplio de valores reduce la posibilidad de otra colisión. Si el módem pierde más solicitudes de ancho de banda, el módem continúa incrementando el valor utilizado como la potencia de dos para cada retransmisión hasta que el valor sea igual al extremo de retroceso de datos. La potencia de dos no debe crecer para ser mayor que el valor final de la retroceso de datos.

El módem retransmite una solicitud de ancho de banda hasta 16 veces, después de lo cual el módem descarta la solicitud de ancho de banda. Esta situación se produce sólo en condiciones extremadamente congestionadas.

Puede configurar los valores finales de inicio de retroceso de datos y de retroceso de datos por cable ascendente en un CMTS uBR de Cisco con este comando de interfaz de cable:

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

Cisco recomienda que mantenga los valores predeterminados para los parámetros de inicio de retroceso de datos y fin de retroceso de datos, que son 3 y 5. La naturaleza basada en la contención del sistema de programación de mejor esfuerzo significa que, para los flujos de servicio de mejor esfuerzo, es imposible proporcionar un nivel determinista o garantizado de latencia ascendente o fluctuación. Además, las condiciones congestionadas pueden hacer imposible garantizar un nivel particular de rendimiento para un flujo de servicio de mejor esfuerzo. Sin embargo, puede utilizar propiedades de flujo de servicio como prioridad y velocidad reservada mínima. Con estas propiedades, el flujo de servicio puede alcanzar el nivel de rendimiento deseado en condiciones congestionadas.

Ejemplo del algoritmo de retroceso y reintento

Este ejemplo comprende cuatro cablemódems denominados A, B, C y D, conectados al mismo canal ascendente. En el mismo instante llamado t₀, los módems A, B y C deciden transmitir algunos datos en el flujo ascendente.

Aquí, el inicio de la retroceso de datos se establece en 2 y el extremo de retroceso de datos se establece en 4. El rango de intervalos desde los cuales los módems eligen un intervalo antes de que intenten por primera vez transmitir una solicitud de ancho de banda está entre 0 y 3. Aquí está el cálculo:

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

A continuación se muestra el número de oportunidades de solicitud de ancho de banda que los tres módems eligen para esperar desde el tiempo t₀.

• Módem A: 3

• Módem B: 2

• Módem C: 3

Observe que el módem A y el módem C eligen el mismo número de oportunidades a esperar.

El módem B espera dos oportunidades de solicitud de ancho de banda que aparecen después de t₀. Luego, el módem B transmite la solicitud de ancho de banda que recibe el CMTS. Tanto el módem A como el módem C esperan que pasen 3 oportunidades de solicitud de ancho de banda después de t₀. Los módems A y C luego transmiten solicitudes de ancho de banda al mismo tiempo. Estas dos solicitudes de ancho de banda colisionan y se corrompen. Como resultado, ninguna de las solicitudes alcanza con éxito el CMTS. La figura 2 muestra esta secuencia de eventos.

Figura 2: Ejemplo de solicitud de ancho de banda, parte 1

La barra gris en la parte superior del diagrama representa una serie de oportunidades de solicitud de ancho de banda disponibles para los cablemódems después de la hora t₀. Las flechas coloreadas representan solicitudes de ancho de banda que transmiten los cablemódems. El cuadro de color de la barra gris representa una solicitud de ancho de banda que alcanza el CMTS con éxito.

El siguiente mensaje MAP transmitido desde el CMTS contiene una subvención para el módem B pero no instrucciones para los módems A y C. Esto indica a los módems A y C que necesitan retransmitir sus solicitudes de ancho de banda.

En el segundo intento, el módem A y el módem C necesitan aumentar la potencia de dos para utilizarlos cuando calculan el rango de intervalos a partir de los cuales elegir. Ahora, el módem A y el módem C eligen un número aleatorio de intervalos entre 0 y 7. Aquí está el cálculo:

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

Suponga que el momento en que el módem A y el módem C se dan cuenta de la necesidad de retransmitir es el ₁. También supongamos que otro módem llamado módem D decide transmitir algunos datos ascendentes en el mismo instante, t ₁. El módem D está a punto de realizar una transmisión de solicitud de ancho de banda por primera vez. Por lo tanto, el módem D utiliza el valor original para el inicio de la retroceso de datos y el extremo de retroceso de datos, es decir, entre 0 y 3 [(22 - 1) = (4 - 1) = 3 intervalos].

Los tres módems eligen estas oportunidades aleatorias de solicitud de ancho de banda para esperar desde el tiempo t₁.

• Módem A: 5

• Módem C: 2

• Módem D: 2

Ambos módems C y D esperan dos oportunidades de solicitud de ancho de banda que aparecen después de la hora t₁. Los módems C y D luego transmiten solicitudes de ancho de banda al mismo tiempo. Estas solicitudes de ancho de banda colisionan y, por lo tanto, no llegan al CMTS. El módem A permite pasar cinco oportunidades de solicitud de ancho de banda. Luego, el módem A transmite la solicitud de ancho de banda, que recibe el CMTS. La figura 3 muestra la colisión entre la transmisión de los módems C y D y la recepción exitosa de la transmisión del módem A. La referencia de la hora de inicio para esta figura es t ₁.

Figura 3: Ejemplo de solicitud de ancho de banda, parte 2

El siguiente mensaje MAP transmitido desde el CMTS contiene una concesión para el módem A pero no instrucciones para los módems C y D. Los módems C y D se dan cuenta de la necesidad de retransmitir las solicitudes de ancho de banda. El módem D está a punto de transmitir la solicitud de ancho de banda por segunda vez. Por lo tanto, el módem D utiliza el inicio de retroceso de datos + 1 como la potencia de dos para usar en el cálculo del rango de intervalos a esperar. El módem D elige un intervalo entre 0 y 7. Aquí está el cálculo:

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

El módem C está a punto de transmitir la solicitud de ancho de banda por tercera vez. Por lo tanto, el módem C utiliza el inicio de retransmisión de datos + 2 como la potencia de dos para en el cálculo del rango de intervalos a esperar. El módem C elige un intervalo entre 0 y 15. Aquí está el cálculo:

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

Tenga en cuenta que la potencia de dos aquí es la misma que el valor final de retroceso de datos, que es cuatro. Ésta es la potencia más alta que puede tener dos valores para un módem en este canal ascendente. En el siguiente ciclo de transmisión de solicitud de ancho de banda, los dos módems eligen estas oportunidades de solicitud de ancho de banda para esperar:

• Módem C: 9

• Módem D: 4

El módem D puede transmitir la solicitud de ancho de banda porque el módem D espera a que pasen cuatro oportunidades de solicitud de ancho de banda. Además, el módem C también puede transmitir la solicitud de ancho de banda, porque el módem C ahora difiere la transmisión para las oportunidades de solicitud de nueve ancho de banda.

Desafortunadamente, cuando el módem C realiza una transmisión, una gran ráfaga de ruido de ingreso interfiere con la transmisión y el CMTS no recibe la solicitud de ancho de banda (consulte la Figura 4). Como resultado, una vez más, el módem C no puede ver una concesión en el siguiente mensaje MAP que el CMTS transmite. Esto hace que el módem C intente una cuarta transmisión de la solicitud de ancho de banda.

Figura 4: Ejemplo de solicitud de ancho de banda, parte 3

El módem C ya ha alcanzado el valor final de la retransmisión de datos de 4. El módem C no puede aumentar el rango utilizado para elegir un número aleatorio de intervalos a esperar. Por lo tanto, el módem C utiliza una vez más 4 como la potencia de dos para calcular el rango aleatorio. El módem C todavía utiliza el rango de 0 a 15 intervalos según este cálculo:

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

En el cuarto intento, el módem C puede realizar una transmisión de solicitud de ancho de banda exitosa en ausencia de contención o ruido.

Las retransmisiones de solicitudes de ancho de banda múltiple del módem C en este ejemplo muestran lo que puede ocurrir en un canal ascendente congestionado. Este ejemplo también demuestra los problemas potenciales que conlleva el modo de programación de mejor esfuerzo y por qué la programación de mejor esfuerzo no es adecuada para los servicios que requieren niveles estrictamente controlados de latencia de paquetes y fluctuación.

Prioridad de tráfico

Cuando el CMTS tiene varias solicitudes de ancho de banda pendientes de varios flujos de servicio, CMTS examina la prioridad de tráfico de cada flujo de servicio para decidir cuáles otorgan primero el ancho de banda.

El CMTS otorga tiempo de transmisión a todas las solicitudes pendientes de los flujos de servicio con una prioridad más alta antes de las solicitudes de ancho de banda de los flujos de servicio con una prioridad más baja. En las condiciones de flujo ascendente congestionadas, esto generalmente conduce a un mayor rendimiento para flujos de servicio de alta prioridad en comparación con flujos de servicio de baja prioridad.

Un hecho importante que hay que tener en cuenta es que, si bien es más probable que un flujo de servicio de mejor esfuerzo de alta prioridad reciba rápidamente el ancho de banda, el flujo de servicio sigue estando sujeto a la posibilidad de colisiones de solicitudes de ancho de banda. Por esta razón, mientras que la prioridad de tráfico puede mejorar el rendimiento y las características de latencia de un flujo de servicio, la prioridad de tráfico todavía no es una manera apropiada de proporcionar una garantía de servicio para las aplicaciones que lo requieren.

Tasa reservada mínima

Los flujos de servicio de mejor esfuerzo pueden recibir una tasa reservada mínima que cumplir. El CMTS garantiza que un flujo de servicio con una velocidad reservada mínima especificada reciba ancho de banda en lugar de todos los demás flujos de servicio de mejor esfuerzo, independientemente de la prioridad.

Este método es un intento de proporcionar un tipo de servicio estilo de velocidad de información comprometida (CIR) similar a una red de Frame Relay. El CMTS dispone de mecanismos de control de admisión para garantizar que, en un flujo ascendente determinado, la velocidad mínima reservada combinada de todos los flujos de servicio conectados no pueda exceder el ancho de banda disponible del canal ascendente, o un porcentaje del mismo. Puede activar estos mecanismos con este comando por puerto ascendente:

[no] cable ascendente upstream-port-id control de admisión max-reservation-limit

El parámetro max-reservation-limit tiene un rango de 10 a 1000 por ciento para indicar el nivel de suscripción en comparación con el rendimiento de canal ascendente sin procesar disponible que los servicios de estilo CIR pueden consumir. Si configura un límite máximo de reserva superior a 100, el flujo ascendente puede sobresuscribir los servicios estilo CIR por el límite de porcentaje especificado.

El CMTS no permite establecer nuevos flujos de servicio de velocidad reservada mínima si hacen que el puerto ascendente exceda el porcentaje de límite de reserva máximo configurado del ancho de banda del canal ascendente disponible. Los flujos de servicio de velocidad reservada mínima aún están sujetos a posibles colisiones de solicitudes de ancho de banda. Como tal, los flujos de servicio de velocidad reservada mínima no pueden ofrecer una verdadera garantía de un rendimiento particular, especialmente en condiciones extremadamente congestionadas. En otras palabras, el CMTS sólo puede garantizar que un flujo de servicio de velocidad reservada mínima pueda lograr un rendimiento ascendente garantizado particular si el CMTS puede recibir todas las solicitudes de ancho de banda requeridas del cablemódem. Este requisito se puede lograr si hace que el flujo de servicio sea un flujo de servicio de sondeo en tiempo real (RTPS) en lugar de un flujo de servicio de mejor esfuerzo. Consulte la sección Servicio de sondeo en tiempo real (RTPS) para obtener más información.

Solicitudes Piggback Bandwidth

Cuando un flujo de servicio ascendente de mejor esfuerzo transmite tramas a una velocidad alta, es posible recolectar solicitudes de ancho de banda en tramas de datos ascendentes en lugar de tener transmisión separada de las solicitudes de ancho de banda. Los detalles de la siguiente solicitud de ancho de banda se agregan simplemente al encabezado de un paquete de datos que se transmite en el flujo ascendente al CMTS.

Esto significa que la solicitud de ancho de banda no está sujeta a contención y, por lo tanto, tiene una probabilidad mucho mayor de que la solicitud llegue al CMTS. El concepto de solicitudes de ancho de banda de retorno reduce el tiempo que una trama Ethernet tarda en llegar al equipo de las instalaciones del cliente (CPE) del usuario final, porque el tiempo que la trama tarda en la transmisión ascendente reduce. Esto se debe a que el módem no necesita pasar por el backoff y reintentar el proceso de transmisión de solicitud de ancho de banda, que puede estar sujeto a retrasos.

El respaldo simultáneo de las solicitudes de ancho de banda se produce normalmente en este escenario:

Mientras el cablemódem espera para transmitir una trama, digamos X, en el flujo ascendente, el módem recibe otra trama, digamos Y, de un CPE para transmitir en el flujo ascendente. El cablemódem no puede agregar los bytes de la nueva trama Y a la transmisión, porque eso implica el uso de más tiempo ascendente que el módem concedido. En su lugar, el módem rellena un campo en el encabezado DOCSIS de la trama X para indicar la cantidad de tiempo de transmisión requerida para la trama Y.

El CMTS recibe la trama X y también los detalles de una solicitud de ancho de banda en nombre de Y. Según la disponibilidad, el CMTS otorga al módem más tiempo de transmisión en nombre de Y.

En términos muy conservadores, transcurren hasta 5 milisegundos entre la transmisión de una solicitud de ancho de banda y la recepción de la asignación de ancho de banda, así como el reconocimiento de MAP que asigna tiempo para la transmisión de datos. Esto significa que para que ocurra el piggyback, el cablemódem necesita recibir tramas del CPE dentro de menos de 5 ms entre sí.

Esto es digno de mención porque un códec VoIP típico como G.711 generalmente utiliza un período entre tramas de 10 o 20 ms. Un flujo de VoIP típico que funciona con un flujo de servicio de mejor esfuerzo no puede aprovechar el piggyback.

Concatenación

Cuando un flujo de servicio ascendente de mejor esfuerzo transmite tramas a una velocidad alta, el cablemódem puede unir algunas de las tramas y pedir permiso para transmitir las tramas todas a la vez. Esto se llama concatenación. El cablemódem necesita transmitir solamente una solicitud de ancho de banda en nombre de todas las tramas en un grupo de tramas concatenadas, lo que mejora la eficiencia.

La concatenación tiende a ocurrir en circunstancias similares a la duplicación, excepto que la concatenación requiere que se pongan en cola varias tramas dentro del cablemódem cuando el módem decide transmitir una solicitud de ancho de banda. Esto implica que la concatenación tiende a ocurrir a tasas de trama medias más altas que el piggyback. Además, ambos mecanismos suelen colaborar para mejorar la eficiencia del tráfico de mejor esfuerzo.

El campo Maximum Concatenated Burst (Ráfaga máxima concatenada) que puede configurar para un flujo de servicio limita el tamaño máximo de una trama concatenada que puede transmitir un flujo de servicio. También puede utilizar el comando cable default-phy-burst para limitar el tamaño de una trama concatenada y el tamaño máximo de ráfaga en el perfil de modulación de canal ascendente.

La concatenación se habilita de forma predeterminada en los puertos ascendentes de la serie uBR de CMTS de Cisco. Sin embargo, puede controlar la concatenación por puerto ascendente con el comando de interfaz de cable [no] upstream-port-id concatenation [docsis10].

Si configura el parámetro docsis10, el comando sólo se aplica a los cablemódems que funcionan en el modo DOCSIS 1.0.

Si realiza cambios en este comando, los cablemódems deben volver a registrarse en el CMTS para que los cambios surtan efecto. Los módems en el flujo ascendente afectado se deben restablecer. Un cable módem descubre si se permite la concatenación en el punto en que el módem realiza el registro como parte del proceso de conexión.

Fragmentación

Las tramas grandes tardan mucho tiempo en transmitirse en el flujo ascendente. Este tiempo de transmisión se conoce como el retraso de serialización. Las tramas ascendentes especialmente grandes pueden tardar tanto en transmitir que pueden retrasar inocuamente los paquetes que pertenecen a los servicios sensibles al tiempo, por ejemplo, VoIP. Esto es especialmente cierto para las tramas concatenadas grandes. Por esta razón, se introdujo la fragmentación en DOCSIS 1.1 de modo que las tramas grandes se puedan dividir en tramas más pequeñas para transmitirlas en ráfagas separadas que cada una de ellas tardan menos tiempo en transmitir.

La fragmentación permite que las tramas pequeñas sensibles al tiempo se entrelazen entre los fragmentos de las tramas grandes en lugar de tener que esperar a la transmisión de toda la trama grande. La transmisión de una trama como fragmentos múltiples es ligeramente menos eficiente que la transmisión de una trama en una ráfaga debido al conjunto adicional de encabezados DOCSIS que necesitan acompañar cada fragmento. Sin embargo, la flexibilidad que la fragmentación añade al canal ascendente justifica la sobrecarga adicional.

Los cablemódems que funcionan en el modo DOCSIS 1.0 no pueden realizar la fragmentación.

La fragmentación se habilita de forma predeterminada en los puertos ascendentes de la serie Cisco uBR de CMTS. Sin embargo, puede habilitar o inhabilitar la fragmentación por puerto ascendente con el comando [no] cable upstream upstream-port-id fragmentation cable interface.

No es necesario restablecer los cablemódems para que el comando tenga efecto. Cisco recomienda que siempre tenga activada la fragmentación. La fragmentación ocurre normalmente cuando el CMTS cree que una trama de datos grande puede interferir con la transmisión de tramas sensibles al tiempo pequeño o ciertos eventos de administración periódicos de DOCSIS.

Puede obligar a los cablemódems DOCSIS 1.1/2.0 a fragmentar todas las tramas grandes con el comando de interfaz de cable [no] upstream-port-id fragment-force [threshold number-of-fragments].

De forma predeterminada, esta función está desactivada. Si no especifica valores para el umbral y el número de fragmentos en la configuración, el umbral se establece en 2000 bytes y el número de fragmentos se establece en 3. El comando fragment-force compara el número de bytes que un flujo de servicio solicita para la transmisión con el parámetro de umbral especificado. Si el tamaño de la solicitud es mayor que el umbral, el CMTS otorga el ancho de banda al flujo de servicio en "número de fragmentos" de partes de tamaño similar.

Por ejemplo, supongamos que para un fragmento de fuerza ascendente determinado se habilita con un valor de 2000 bytes para el umbral y 3 para el número de fragmentos. Luego, supongamos que llega una solicitud para transmitir una ráfaga de 3000 bytes. Como 3000 bytes es mayor que el umbral de 2000 bytes, la concesión debe fragmentarse. Como el número de fragmentos se establece en 3, el tiempo de transmisión es tres concesiones de tamaño igual de 1000 bytes cada una.

Asegúrese de que los tamaños de los fragmentos individuales no excedan la capacidad del tipo de tarjeta de línea de cable en uso. Para las tarjetas de línea MC5x20S, el fragmento individual más grande no debe superar los 2000 bytes y para otras tarjetas de línea, incluidos MC28U, MC5x20U y MC5x20H, el fragmento individual más grande no debe exceder los 4000 bytes.

Servicio de subvenciones no solicitado (UGS)

El servicio de concesión no solicitada (UGS) proporciona subvenciones periódicas para un flujo de servicio ascendente sin necesidad de un cable módem para transmitir solicitudes de ancho de banda. Este tipo de servicio es adecuado para aplicaciones que generan tramas de tamaño fijo a intervalos regulares y son intolerantes con la pérdida de paquetes. La voz sobre IP es el ejemplo clásico.

Compare el sistema de programación UGS con una ranura de tiempo en un sistema de multiplexación por división de tiempo (TDM) como un circuito T1 o E1. UGS proporciona un rendimiento y latencia garantizados, que a su vez proporciona un flujo continuo de intervalos periódicos fijos para transmitir sin la necesidad de que el cliente solicite o compita periódicamente por el ancho de banda. Este sistema es perfecto para VoIP porque el tráfico de voz se transmite generalmente como un flujo continuo de datos periódicos de tamaño fijo.

UGS se concibió debido a la falta de garantías de latencia, fluctuación y rendimiento en el modo de programación de mejor esfuerzo. El modo de programación de mejor esfuerzo no proporciona la garantía de que una trama determinada puede transmitirse en un momento determinado, y en un sistema congestionado no hay ninguna garantía de que una trama determinada pueda transmitirse en absoluto.

Tenga en cuenta que, aunque los flujos de servicio de estilo UGS son el tipo de flujo de servicio más adecuado para transmitir tráfico VoIP al portador, no se consideran adecuados para aplicaciones de Internet clásicas como la Web, el correo electrónico o P2P. Esto se debe a que las aplicaciones clásicas de Internet no generan datos a intervalos periódicos fijos y, de hecho, pueden pasar periodos significativos de tiempo sin transmitir datos. Si se utiliza un flujo de servicio UGS para transmitir el tráfico de Internet clásico, el flujo de servicio puede pasar desapercibido durante periodos significativos cuando la aplicación detiene brevemente las transmisiones. Esto conduce a subvenciones UGS no utilizadas que representan un desperdicio de recursos de ancho de banda ascendente que no es deseable.

Los flujos de servicio UGS generalmente se establecen dinámicamente cuando se requieren en lugar de aprovisionarse en el archivo de configuración DOCSIS. Un cablemódem con puertos VoIP integrados normalmente puede pedirle al CMTS que cree un flujo de servicio UGS adecuado cuando el módem detecta que hay una llamada telefónica VoIP en curso.

Cisco recomienda que no configure un flujo de servicio UGS en un archivo de configuración DOCSIS porque esta configuración mantiene activo el flujo de servicio UGS mientras el cablemódem esté en línea independientemente de si algún servicio lo utiliza o no. Esta configuración desperdicia el ancho de banda ascendente porque un flujo de servicio UGS constantemente reserva tiempo de transmisión ascendente en nombre del cablemódem. Es mucho mejor permitir que el flujo de servicio UGS se cree y elimine dinámicamente para que UGS esté activo cuando sea necesario.

Estos son los parámetros más utilizados que definen un flujo de servicio UGS:

• Tamaño de concesión no solicitado (G): el tamaño de cada concesión periódica en bytes.

• Intervalo de concesión nominal (I): el intervalo en microsegundos entre las subvenciones.

• Fluctuación Grant tolerada (J): variación permitida en microsegundos de subvenciones exactamente periódicas. En otras palabras, este es el margen de acción que el CMTS tiene cuando intenta programar una subvención UGS a tiempo.

Cuando un flujo de servicio UGS está activo, cada (I) milisegundos, el CMTS ofrece una oportunidad para que el flujo de servicio se transmita en bytes de tamaño de concesión no solicitado (G). Aunque idealmente el CMTS ofrece la subvención exactamente cada (I) milisegundos, puede llegar tarde hasta (J) milisegundos.

La figura 5 muestra una línea de tiempo que muestra cómo se pueden asignar las subvenciones UGS con un tamaño de concesión determinado, intervalo de concesión y fluctuación tolerada.

Figura 5: Línea de tiempo que muestra las concesiones de UGS periódicas

Los bloques con patrones verdes representan el tiempo en el que el CMTS dedica tiempo de transmisión ascendente a un flujo de servicio UGS.

Servicio de sondeo en tiempo real (RTPS)

El servicio de sondeo en tiempo real (RTPS) proporciona oportunidades periódicas de solicitud de ancho de banda no basadas en contención, de modo que un flujo de servicio tiene tiempo dedicado para transmitir solicitudes de ancho de banda. Sólo se permite que el flujo de servicio RTPS utilice esta oportunidad de solicitud de ancho de banda unicast. Otros cablemódems no pueden causar una colisión de solicitud de ancho de banda.

El RTPS es adecuado para aplicaciones que generan tramas de longitud variable en forma semirperiódica y requieren un rendimiento mínimo garantizado para funcionar de manera eficaz. La videotelefonía sobre IP o los juegos en línea multijugador son ejemplos típicos.

RTPS también se utiliza para el tráfico de señalización VoIP. Aunque el tráfico de señalización VoIP no necesita transmitirse con una latencia o fluctuación extremadamente bajas, VoIP sí que tiene una alta probabilidad de alcanzar el CMTS en un tiempo razonable. Si utiliza RTPS en lugar de programar con el mejor esfuerzo, puede estar seguro de que la señalización de voz no se retrasa significativamente o se pierde debido a las repetidas colisiones de solicitudes de ancho de banda.

Un flujo de servicio RTPS normalmente posee estos atributos:

• Intervalo de sondeo nominal: el intervalo en microsegundos entre las oportunidades de solicitud de ancho de banda de unidifusión.

• Fluctuación tolerada de las encuestas: la variación permitida en microsegundos de las encuestas periódicas exactas. Dicho de otra manera, este es el margen de acción que el CMTS tiene al intentar programar a tiempo una oportunidad de solicitud de ancho de banda unicast de RTPS.

La figura 6 muestra una línea de tiempo que muestra cómo se asignan las encuestas de RTPS con un intervalo de sondeo nominal determinado y una fluctuación de sondeo tolerada.

Figura 6: Línea de tiempo que muestra el sondeo periódico de RTPS

Los pequeños bloques con patrones verdes representan el tiempo en el que el CMTS ofrece un flujo de servicio RTPS y una oportunidad de solicitud de ancho de banda unicast.

Cuando el CMTS recibe una solicitud de ancho de banda en nombre de un flujo de servicio RTPS, el CMTS procesa la solicitud de ancho de banda de la misma manera que una solicitud de un flujo de servicio de "mejor esfuerzo". Esto significa que, además de los parámetros anteriores, las propiedades como la velocidad de tráfico sostenida máxima y la prioridad de tráfico deben incluirse en una definición de flujo de servicio RTPS. Un flujo de servicio RTPS normalmente también contiene una velocidad de tráfico reservado mínima para asegurarse de que el tráfico asociado con el flujo de servicio pueda recibir una garantía de ancho de banda comprometida.

Servicio de concesión no solicitado con detección de actividad (UGS-AD)

El servicio de concesión no solicitado con detección de actividad (UGS-AS) asigna tiempo de transmisión de estilo UGS a un flujo de servicio solamente cuando UGS-AS realmente necesita transmitir paquetes. Cuando el CMTS detecta que el cablemódem no ha transmitido tramas durante un período determinado, CMTS ofrece oportunidades de solicitud de ancho de banda estilo RTPS en lugar de concesiones de estilo UGS. Si el CMTS detecta posteriormente que el flujo de servicio realiza solicitudes de ancho de banda, el CMTS devuelve el flujo de servicio a ofrecer concesiones de estilo UGS y deja de ofrecer oportunidades de solicitud de ancho de banda estilo RTPS.

UGS-AD se utiliza normalmente en una situación en la que se transmitía el tráfico VoIP que utilizaba la detección de actividad de voz (VAD). La detección de actividad de voz hace que el punto final de VoIP detenga la transmisión de tramas VoIP si UGS-AD detecta una pausa en la voz del usuario. Aunque este comportamiento puede ahorrar ancho de banda, puede causar problemas con la calidad de voz, especialmente si el mecanismo de detección de actividad VAD o UGS-AD se activa ligeramente después de que la parte final comience a hablar. Esto puede dar lugar a un sonido que salta o a un clic cuando un usuario reanuda el habla después del silencio. Por esta razón, UGS-AD no se implementa ampliamente.

Ejecute el comando de configuración CMTS global cable service flow inactivity-threshold threshold-in-seconds para establecer el período después del cual el CMTS conmuta un flujo de servicio UGS-AD inactivo del modo UGS al modo RTPS.

El valor predeterminado para el parámetro threshold-in-seconds es 10 segundos. Los flujos de servicio UGS-AD generalmente poseen los atributos de un flujo de servicio UGS y el intervalo de sondeo nominal y el atributo de fluctuación de sondeo tolerado asociado con los flujos de servicio RTPS.

Servicio de sondeo en tiempo no real (nRTPS)

El modo de programación del servicio de sondeo en tiempo no real (nRTPS) es esencialmente el mismo que el RTPS, excepto que el nRTPS generalmente se asocia con servicios no interactivos como las transferencias de archivos. El componente en tiempo no real puede implicar que el intervalo de sondeo nominal para las oportunidades de solicitud de ancho de banda de unidifusión no es exactamente normal o puede ocurrir a una velocidad inferior a uno por segundo.

Algunos operadores de red de cable pueden optar por utilizar nRTPS en lugar de flujos de servicio RTPS para transmitir tráfico de señalización de voz.

Programación de algoritmos

Antes de una discusión sobre los detalles del planificador que cumple con DOCSIS y el planificador de cola de latencia baja, debe comprender las ventajas y desventajas que debe realizar para determinar las características de un planificador ascendente. Aunque la discusión de los algoritmos del programador se centra principalmente en el modo de programación UGS, la discusión también se aplica a los servicios estilo RTPS.

Cuando decide programar flujos de servicio UGS, no hay muchas opciones flexibles. No puede hacer que el programador cambie el tamaño de la concesión o el intervalo de concesión de los flujos de servicio UGS, porque tal cambio hace que las llamadas VoIP fallen por completo. Sin embargo, si cambia la fluctuación, las llamadas funcionan, aunque posiblemente con una latencia mayor en la llamada. Además, la modificación del número máximo de llamadas permitidas en un flujo ascendente no afecta a la calidad de las llamadas individuales. Por lo tanto, tenga en cuenta estos dos factores principales cuando programe grandes cantidades de flujos de servicios UGS:

• Fluctuación

• Capacidad de flujo de servicio UGS por flujo ascendente

Fluctuación

Se especifica una fluctuación de concesión tolerada como uno de los atributos de un flujo de servicio UGS o RTPS. Sin embargo, el soporte simultáneo de algunos flujos de servicio con fluctuación muy baja tolerada y otros con grandes cantidades de fluctuación puede ser ineficiente. En general, debe elegir de forma uniforme el tipo de fluctuación que experimentan los flujos de servicios en un flujo ascendente.

Si se requieren niveles bajos de fluctuación, el programador debe ser inflexible y rígido cuando programa las subvenciones. Como consecuencia, el planificador debe imponer restricciones al número de flujos de servicio UGS soportados en un flujo ascendente.

Los niveles de fluctuación no siempre necesitan ser extremadamente bajos para VoIP de consumo normal porque la tecnología de búfer de fluctuación es capaz de compensar los altos niveles de fluctuación. Las memorias intermedias de fluctuación VoIP adaptativas modernas pueden compensar más de 150 ms de fluctuación. Sin embargo, una red VoIP agrega la cantidad de almacenamiento en búfer que ocurre a la latencia de los paquetes. Los altos niveles de latencia pueden contribuir a una experiencia VoIP más pobre.

Capacidad de flujo de servicio UGS por flujo ascendente

Los atributos de la capa física como el ancho del canal, el esquema de modulación y la resistencia de corrección de errores determinan la capacidad física de un flujo ascendente. Sin embargo, el número de flujos de servicio UGS simultáneos que puede soportar el flujo ascendente también depende del algoritmo del programador.

Si no se necesitan niveles de fluctuación extremadamente bajos, puede relajar la rigidez del planificador y atender a un mayor número de flujos de servicio UGS que el flujo ascendente puede soportar simultáneamente. Puede lograr una mayor eficiencia del tráfico no de voz en el flujo ascendente si relaja los requisitos de fluctuación.

Nota: Diferentes algoritmos de programación pueden permitir que un canal ascendente determinado admita varios números de flujos de servicio UGS y RTPS. Sin embargo, estos servicios no pueden utilizar el 100% de la capacidad ascendente en un sistema DOCSIS. Esto se debe a que el canal ascendente debe dedicar una parte al tráfico de administración de DOCSIS, como los mensajes de mantenimiento iniciales que utilizan los cablemódems para hacer contacto inicial con el CMTS, y el tráfico keepalive de mantenimiento de la estación utilizado para garantizar que los cablemódems puedan mantener la conectividad con el CMTS.

Planificador conforme a DOCSIS

El planificador compatible con DOCSIS es el sistema predeterminado para programar servicios ascendentes en un CMTS uBR de Cisco. Este planificador se diseñó para minimizar la fluctuación que experimentan los flujos de servicio UGS y RTPS. Sin embargo, este programador todavía le permite mantener cierto grado de flexibilidad para optimizar el número de llamadas UGS simultáneas por flujo ascendente.

El planificador compatible con DOCSIS asigna previamente tiempo de flujo ascendente con antelación para los flujos de servicio UGS. Antes de que se programen otras asignaciones de ancho de banda, el CMTS reserva tiempo en el futuro para las subvenciones que pertenecen a flujos de servicio UGS activos para asegurarse de que ninguno de los otros tipos de flujos de servicio o tráfico desplace las subvenciones UGS y cause fluctuaciones significativas.

Si el CMTS recibe solicitudes de ancho de banda en nombre de flujos de servicio de estilo de mejor esfuerzo, el CMTS debe programar el tiempo de transmisión para los flujos de servicio de mejor esfuerzo alrededor de las subvenciones UGS preasignadas, de modo que no afecte a la programación oportuna de cada subvención UGS.

Configuración

El programador compatible con DOCSIS es el único algoritmo del programador ascendente disponible para Cisco IOS Software Releases 12.3(9a)BCx y anteriores. Por lo tanto, este programador no requiere comandos de configuración para la activación.

Para las versiones 12.3(13a)BC y posteriores del software del IOS de Cisco, el planificador compatible con DOCSIS es uno de dos algoritmos de programador alternativos, pero se configura como el programador predeterminado. Puede habilitar el planificador compatible con DOCSIS para uno, todos o algunos de estos tipos de programación:

• UGS

• RTPS

• NRTPS

Puede habilitar explícitamente el planificador compatible con DOCSIS para cada uno de estos tipos de programación con el tipo de programación cable ascendente de puerto ascendente [nrtps | rtps | ugs] mode docsis cable interface.

El uso del planificador compatible con DOCSIS forma parte de la configuración predeterminada. Por lo tanto, sólo debe ejecutar este comando si cambia de nuevo del algoritmo del programador de cola de latencia baja no predeterminado. Vea la sección Planificador de cola de latencia baja para obtener más información.

Control de admisión

Una gran ventaja del planificador que cumple con DOCSIS es que este programador asegura que los flujos de servicio UGS no sobresuscriban el flujo ascendente. Si se debe establecer un nuevo flujo de servicio de UGS y el planificador descubre que no es posible realizar una programación previa de concesiones porque no queda espacio, el CMTS rechaza el nuevo flujo de servicio de UGS. Si se permite que los flujos de servicio UGS que transmiten tráfico VoIP sobresuscriban un canal ascendente, la calidad de todas las llamadas VoIP se degrada gravemente.

Para demostrar cómo el planificador compatible con DOCSIS asegura que los flujos de servicio UGS nunca sobresuscriban el flujo ascendente, consulte las cifras de esta sección. Las figuras 7, 8 y 9 muestran líneas de tiempo de asignación de ancho de banda.

En todas estas cifras, las secciones con patrones en color muestran el momento en que los cablemódems reciben subvenciones en nombre de sus flujos de servicio UGS. No pueden producirse otras transmisiones ascendentes de otros cablemódems durante ese tiempo. La parte gris de la línea de tiempo es todavía ancho de banda sin asignar. Los cablemódems utilizan este tiempo para transmitir solicitudes de ancho de banda. CMTS puede utilizar más adelante esta hora para programar otros tipos de servicios.

Figura 7: Programación previa del planificador conforme con DOCSIS Tres flujos de servicios UGS

Agregue dos flujos de servicio UGS más del mismo tamaño de concesión e intervalo de concesión. Aún así, el planificador no tiene problemas para preprogramarlos.

Figura 8: Programación previa del planificador conforme con DOCSIS Cinco flujos de servicios UGS

Si sigue adelante y agrega dos flujos de servicio UGS más, completará todo el ancho de banda ascendente disponible.

Figura 9: Los flujos de servicios de UGS consumen todo el ancho de banda ascendente disponible

Claramente, el planificador no puede admitir ningún flujo de servicio UGS adicional aquí. Por lo tanto, si otro flujo de servicio UGS intenta activarse, el planificador compatible con DOCSIS se da cuenta de que no hay espacio para más concesiones y evita el establecimiento de ese flujo de servicio.

Nota: Es imposible llenar completamente un flujo ascendente con flujos de servicio UGS como se ve en esta serie de cifras. El planificador debe admitir otros tipos importantes de tráfico, por ejemplo, señales de mantenimiento de la estación y tráfico de datos de mejor esfuerzo. Además, la garantía para evitar la suscripción excesiva con el planificador compatible con DOCSIS sólo se aplica si todos los modos de programación de flujo de servicio, a saber, UGS, RTPS y nRTPS, utilizan el planificador compatible con DOCSIS.

Aunque la configuración explícita del control de admisión no es necesaria cuando utiliza el planificador compatible con DOCSIS, Cisco recomienda asegurarse de que la utilización del canal ascendente no aumente a niveles que puedan afectar negativamente al tráfico de mejor esfuerzo. Cisco también recomienda que la utilización total del canal ascendente no supere el 75% durante cantidades significativas de tiempo. Este es el nivel de utilización ascendente en el que los servicios de mejor esfuerzo empiezan a experimentar una latencia mucho mayor y un rendimiento más lento. Los servicios UGS siguen funcionando, independientemente de la utilización ascendente.

Si desea limitar la cantidad de tráfico admitido en un flujo ascendente determinado, configure el control de admisión para UGS, RTPS, NRTPS, UGS-AD o flujos de servicio de mejor esfuerzo con el global, por interfaz de cable o por comando ascendente. El parámetro más importante es el campo de porcentaje de umbral exclusivo.

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]

Estos son los parámetros:

• [upstream <upstream-number>]: Especifique este parámetro si desea aplicar el comando a un flujo ascendente determinado en lugar de a una interfaz de cable o globalmente.

• <UGS|AD-UGS|RTPS|NRTPS|BE>: Este parámetro especifica el modo de programación de los flujos de servicio a los que desea aplicar el control de admisión.

• <small-threshold-percent>: Este parámetro indica el porcentaje de utilización ascendente por el tipo de programación configurado en el que se envía una alarma menor a una estación de administración de red.

• <major-threshold-percent>: Este parámetro especifica el porcentaje de utilización ascendente por el tipo de programación configurado en el que se envía una alarma principal a una estación de administración de red. Este valor debe ser mayor que el valor establecido para el parámetro <threshold-percent>.

• <only-threshold-percent>: Este parámetro representa el porcentaje de utilización ascendente reservado exclusivamente para el tipo de programación especificado. Si no especifica el valor para <non-excl-threshold-percent>, este valor representa el límite máximo de utilización para este tipo de flujo de servicio. Este valor debe ser mayor que el valor <major-threshold-percent>.

• <non-excl-threshold-percent>: Este parámetro representa el porcentaje de utilización ascendente por encima del <only-threshold-percent> que puede utilizar este tipo de programación, siempre y cuando otro tipo de programación no lo utilice ya.

Por ejemplo, suponga que desea limitar los flujos de servicio UGS al 60% del ancho de banda ascendente total disponible. También supongamos que las estaciones de administración de red han recibido notificaciones de que si el porcentaje de utilización ascendente debido a los flujos de servicio UGS aumentó más del 40%, se debe enviar una alarma menor y más del 50%, se debe enviar una alarma importante. Ejecutar este comando:

cable admision-control us-bandwidth schedutype Us 40 major 50 exclusivo 60

Programación del mejor tráfico de esfuerzo mediante fragmentación

El planificador compatible con DOCSIS simplemente programa el tráfico de mejor esfuerzo en las subvenciones UGS o RTPS preasignadas. Las cifras de esta sección demuestran este comportamiento.

Figura 10: Mejor esfuerzo concedido hasta la programación

La figura 10 muestra que el flujo ascendente tiene tres flujos de servicio UGS con el mismo tamaño de concesión e intervalo de concesión preprogramado. El flujo ascendente recibe solicitudes de ancho de banda en nombre de tres flujos de servicio independientes, A, B y C. El flujo de servicio A solicita una cantidad media de tiempo de transmisión, el flujo de servicio B solicita una pequeña cantidad de tiempo de transmisión y el flujo de servicio C solicita una gran cantidad de tiempo de transmisión.

Accord da la misma prioridad a cada uno de los flujos de servicios de mejor esfuerzo. Además, supongamos que el CMTS recibe las solicitudes de ancho de banda para cada una de estas concesiones en el orden A luego B y luego C. El CMTS primero asigna el tiempo de transmisión para las subvenciones en el mismo orden. La figura 11 muestra cómo el planificador compatible con DOCSIS asigna esas concesiones.

Figura 11: Mejores concesiones de esfuerzo programadas en torno a concesiones de flujo de servicios UGS fijos

El planificador puede reducir las subvenciones para A y B en la brecha entre los dos primeros bloques de subvenciones UGS. Sin embargo, la subvención para C es mayor que cualquier diferencia disponible. Por lo tanto, el planificador compatible con DOCSIS fragmenta la subvención para C alrededor del tercer bloque de subvenciones UGS en dos subvenciones más pequeñas llamadas C1 y C2. La fragmentación evita retrasos en las subvenciones de UGS y garantiza que estas subvenciones no estén sujetas a fluctuaciones que provoque el tráfico de mejor esfuerzo.

La fragmentación aumenta ligeramente la sobrecarga del protocolo DOCSIS asociada a la transmisión de datos. Para cada fragmento adicional transmitido, también se debe transmitir un conjunto adicional de encabezados DOCSIS. Sin embargo, sin la fragmentación, el planificador no puede intercalar eficientemente las concesiones de mejor esfuerzo entre las subvenciones UGS fijas. La fragmentación no puede ocurrir para cablemódems que funcionan en el modo DOCSIS 1.0.

Prioridad

El planificador compatible con DOCSIS coloca las subvenciones que están a la espera de la asignación en colas en función de la prioridad del flujo de servicio al que pertenece la concesión. Hay ocho prioridades DOCSIS con cero como la más baja y siete como la más alta. Cada una de estas prioridades tiene una cola asociada.

El planificador compatible con DOCSIS utiliza un mecanismo de colocación en cola de prioridad estricta para determinar cuándo se asignan a las concesiones de prioridad diferente el tiempo de transmisión. En otras palabras, todas las subvenciones almacenadas en colas de alta prioridad deben atenderse antes de concederlas en colas de menor prioridad.

Por ejemplo, supongamos que el planificador que cumple con la normativa DOCSIS recibe cinco concesiones en un período breve en el orden A, B, C, D, E y F. El planificador coloca en cola cada una de las concesiones en la cola que corresponde a la prioridad del flujo de servicio de la concesión.

Figura 12: Subvenciones con diferentes prioridades

El planificador compatible con DOCSIS programa las concesiones de mejor esfuerzo en torno a las subvenciones UGS programadas previamente que aparecen como bloques con patrones en la Figura 12. La primera acción que realiza el planificador compatible con DOCSIS es verificar la cola de prioridad más alta. En este caso, la cola de prioridad 7 tiene las subvenciones listas para programarse. El planificador continúa y asigna tiempo de transmisión para las subvenciones B y E. Observe que la subvención E necesita fragmentación para que la subvención no interfiera con el momento de las subvenciones UGS preasignadas.

Figura 13: Programación de concesiones de prioridad 7

El planificador se asegura de que todas las concesiones de prioridad 7 reciban tiempo de transmisión. A continuación, el programador verifica la cola de prioridad 6. En este caso, la cola de prioridad 6 está vacía, por lo que el programador pasa a la cola de prioridad 5 que contiene la concesión C.

Figura 14: Programación de concesiones de prioridad 5

A continuación, el programador procede de forma similar a través de las colas de menor prioridad hasta que todas las colas estén vacías. Si hay un gran número de subvenciones para programar, las nuevas solicitudes de ancho de banda pueden alcanzar el CMTS antes de que el planificador compatible con DOCSIS finalice la asignación del tiempo de transmisión a todas las subvenciones pendientes. Suponga que el CMTS recibe una solicitud de ancho de banda G de prioridad 6 en este punto del ejemplo.

Figura 15: Una concesión de prioridad 6 está en cola

Aunque las concesiones A, F y D esperan más que la concesión G recién puesta en cola, el planificador compatible con DOCSIS debe asignar el tiempo de transmisión a G porque G tiene la prioridad más alta. Esto significa que las siguientes asignaciones de ancho de banda del planificador compatible con DOCSIS serán G, A y luego D (consulte la Figura 16).

Figura 16: Programación de concesiones de prioridad 6 y prioridad 2

La siguiente subvención que se programará será F, si asume que ninguna subvención de prioridad más alta ingresará al sistema de colocación en cola en el tiempo medio.

El planificador compatible con DOCSIS tiene dos colas más que no se han mencionado en los ejemplos. La primera cola es la cola utilizada para programar el tráfico keepalive de mantenimiento periódico de la estación para mantener los cablemódems en línea. Esta cola se utiliza para programar oportunidades para que los cablemódems envíen el tráfico keepalive periódico de CMTS. Cuando el planificador compatible con DOCSIS está activo, esta cola se atiende primero antes que todas las demás colas. La segunda es una cola para las subvenciones asignadas a los flujos de servicio con una tasa reservada mínima (CIR) especificada. El planificador trata esta cola CIR como una cola de prioridad 8 para asegurarse de que los flujos de servicio con una velocidad comprometida reciban el rendimiento mínimo requerido.

Donaciones DOCSIS 1.0 no fragmentables

A partir de los ejemplos de la sección anterior, las subvenciones a veces deben fragmentarse en varias partes para garantizar que no se induzca la fluctuación en las subvenciones UGS preasignadas. Esto puede ser un problema para los cablemódems que operan en el modo DOCSIS 1.0 en segmentos ascendentes con una cantidad significativa de tráfico UGS, porque un cablemódem DOCSIS 1.0 puede solicitar la transmisión de una trama demasiado grande para encajar en la siguiente oportunidad de transmisión disponible.

Este es otro ejemplo, que supone que el planificador recibe nuevas concesiones A y B en ese orden. También supongamos que ambas concesiones tienen la misma prioridad pero que la concesión B es para un cablemódem que funciona en el modo DOCSIS 1.0.

Figura 17: Donaciones pendientes de DOCSIS 1.1 y DOCSIS 1.0

El programador intenta asignar tiempo para conceder primero A. A continuación, el planificador intenta asignar la siguiente oportunidad de transmisión disponible para conceder B. Sin embargo, no hay margen para que la subvención B permanezca desfragmentada entre A y el siguiente bloque de subvenciones UGS (véase la figura 18).

Figura 18: Subvención B de DOCSIS 1.0 aplazada

Por esta razón, la subvención B se retrasa hasta después del segundo bloque de subvenciones UGS cuando hay margen para que la subvención B encaje. Observe que ahora hay espacio sin utilizar antes de que el segundo bloque de subvenciones UGS. Los cablemódems utilizan este tiempo para transmitir solicitudes de ancho de banda al CMTS, pero esto representa un uso ineficiente del ancho de banda.

Vuelva a visitar este ejemplo y agregue dos flujos de servicio UGS adicionales al programador. Si bien la subvención A puede fragmentarse, no hay oportunidad de programar la subvención B no fragmentable porque la subvención B es demasiado grande para que encaje entre bloques de subvenciones UGS. Esta situación hace que el cablemódem asociado con la subvención B no pueda transmitir tramas grandes en el flujo ascendente.

Figura 19: No se puede programar la concesión B de DOCSIS 1.0

Puede permitir que el planificador simplemente elimine o que retrase ligeramente un bloque de subvenciones UGS para dejar espacio para la subvención B, pero esta acción causa fluctuación en el flujo del servicio UGS. Por el momento, si asume que desea minimizar la fluctuación, esta es una solución inaceptable.

Para superar este problema con concesiones DOCSIS 1.0 grandes y no fragmentables, el planificador compatible con DOCSIS programa periódicamente bloques de tiempo ascendente tan grandes como la trama más grande que un cablemódem DOCSIS 1.0 puede transmitir. El planificador lo hace antes de que se programen los flujos de servicio UGS. Esta vez es típicamente el equivalente de unos 2000 bytes de transmisión ascendente, y se denomina "Bloque no fragmentable" o "Bloque libre de UGS".

El planificador que cumple con DOCSIS no coloca ninguna concesión de estilo UGS o RTPS en los tiempos asignados al tráfico no fragmentable para asegurarse de que siempre haya una oportunidad de programar grandes concesiones DOCSIS 1.0. En este sistema, la reserva de tiempo para el tráfico DOCSIS 1.0 no fragmentable reduce el número de flujos de servicio UGS que el flujo ascendente puede soportar simultáneamente.

La figura 20 muestra el bloque no fragmentable en azul y cuatro flujos de servicio UGS con el mismo tamaño de concesión e intervalo de concesión. No puede agregar otro flujo de servicio UGS del mismo tamaño de concesión ni el mismo intervalo de concesión a esta fuente ascendente porque no se permite programar las subvenciones UGS en la región azul de bloque no fragmentable.

Figura 20: El bloque no fragmentable: No se pueden admitir más concesiones de UGS

Aunque el bloque no fragmentable se programa con menos frecuencia que el período de las subvenciones de UGS, este bloque tiende a causar un espacio de ancho de banda no asignado tan grande como él mismo entre todos los bloques de subvenciones de UGS. Esto ofrece una amplia oportunidad para programar grandes donaciones no fragmentables.

Vuelva al ejemplo de la concesión A y DOCSIS 1.0 Grant B, puede ver que con el bloque no fragmentable implementado, el planificador compatible con DOCSIS ahora puede programar correctamente la concesión B después del primer bloque de concesiones UGS.

Figura 21: Programación de concesiones con el uso del bloque no fragmentable

Aunque la concesión B de DOCSIS 1.0 se ha programado correctamente, todavía hay una pequeña diferencia de espacio sin utilizar entre la subvención A y el primer bloque de subvenciones UGS. Esta brecha representa un uso subóptimo del ancho de banda y demuestra por qué debe utilizar cablemódems de modo DOCSIS 1.1 cuando implementa servicios UGS.

Cable default-phy-burst

De forma predeterminada en un CMTS uBR de Cisco, la ráfaga más grande que puede transmitir un cablemódem es de 2000 bytes. Este valor para el mayor tamaño de ráfaga ascendente se utiliza para calcular el tamaño del bloque no fragmentable como lo utiliza el planificador compatible con DOCSIS.

Puede cambiar el tamaño de ráfaga más grande con el comando cable default-phy-burst max-bytes-allowed-in-burst por interfaz de cable.

El parámetro <max-bytes-allowed-in-burst> tiene un rango de 0 a 4096 bytes y un valor predeterminado de 2000 bytes. Hay algunas restricciones importantes sobre cómo debe establecer este valor si desea cambiar el valor del valor predeterminado.

Para las interfaces de cable en la tarjeta de línea MC5x20S, no configure este parámetro por encima del valor predeterminado de 2000 bytes. Para todos los demás tipos de tarjetas de línea, incluidas las tarjetas de línea MC28U, MC5x20U y MC5x20H, puede establecer este parámetro hasta 4000 bytes.

No establezca el parámetro <max-bytes-allowed-in-burst> inferior al tamaño de la trama Ethernet única más grande que un cablemódem puede necesitar transmitir incluyendo la sobrecarga DOCSIS o 802.1q. Esto significa que este valor no debe ser inferior a aproximadamente 1540 bytes.

Si configura <max-bytes-allowed-in-burst> al valor especial de 0, el CMTS no utiliza este parámetro para restringir el tamaño de una ráfaga ascendente. Debe configurar otras variables para restringir el tamaño de ráfaga ascendente a un límite razonable, como la configuración de ráfaga concatenada máxima en el archivo de configuración DOCSIS, o el comando cable upstream fragment-force.

Cuando modifica cable default-phy-burst para cambiar el tamaño máximo de ráfaga ascendente, el tamaño del bloque libre de UGS también se modifica en consecuencia. La figura 22 muestra que si se reduce el parámetro cable default-phy-burst, se reduce el tamaño del bloque libre de UGS y, en consecuencia, el planificador compatible con DOCSIS puede permitir más llamadas UGS en un flujo ascendente. En este ejemplo, reduzca el cable default-phy-burst del valor predeterminado de 2000 a un valor inferior de 1600 para permitir que un flujo de servicio UGS más se active.

Figura 22: La reducción de la ráfaga de phy predeterminada reduce el tamaño de bloque no fragmentable

La reducción del tamaño máximo permitido de ráfaga con el comando cable default-phy-burst puede disminuir ligeramente la eficiencia del flujo ascendente para el tráfico de mejor esfuerzo, porque este comando reduce el número de tramas que se pueden concatenar dentro de una ráfaga. Esta reducción también puede conducir a mayores niveles de fragmentación cuando el flujo ascendente tiene un mayor número de flujos de servicio UGS activos.

La reducción de los tamaños de ráfaga concatenada puede afectar a la velocidad de carga de datos en un flujo de servicio de mejor esfuerzo. Esto se debe a que la transmisión de varias tramas a la vez es más rápida que la transmisión de una solicitud de ancho de banda para cada trama. La reducción de los niveles de concatenación también puede afectar potencialmente a la velocidad de las descargas debido a la disminución de la capacidad del cablemódem para concatenar grandes cantidades de paquetes TCP ACK que viajan en la dirección ascendente.

A veces, el tamaño máximo de ráfaga configurado en el IUC "largo" del perfil de modulación de cable aplicado a un flujo ascendente puede determinar el mayor tamaño de ráfaga ascendente. Esto puede ocurrir si el tamaño máximo de ráfaga en el perfil de modulación es menor que el valor del cable default-phy-burst en bytes. Este es un escenario poco común. Sin embargo, si aumenta el parámetro cable default-phy-burst del valor predeterminado de 2000 bytes, verifique el tamaño máximo de ráfaga en la configuración del IUC "long" para asegurarse de que no limite las ráfagas.

La otra limitación al tamaño de ráfaga ascendente es que se puede transmitir un máximo de 255 miniperíodos en una ráfaga. Esto puede convertirse en un factor si el tamaño del minislot se establece en el mínimo de 8 bytes. Un minislot es la unidad más pequeña de transmisión ascendente en una red DOCSIS y normalmente equivale a 8 o 16 bytes.

Fluctuación de ranura no fragmentable

Otra forma de ajustar el planificador conforme a DOCSIS para permitir un mayor número de flujos UGS simultáneos en un flujo ascendente es permitir que el planificador permita que grandes ráfagas de tráfico de mejor esfuerzo no fragmentable introduzcan pequeñas cantidades de fluctuación en los flujos de servicio UGS. Puede hacerlo con el comando de interfaz de cable upstream-number unfrag-slot-jitter limit val.

En este comando, <val> se especifica en microsegundos y tiene un valor predeterminado de cero, lo que significa que el comportamiento predeterminado para el planificador compatible con DOCSIS es no permitir que las subvenciones no fragmentables causen fluctuación para los flujos de servicio UGS y RTPS. Cuando se especifica una fluctuación de ranura positiva no fragmentable, el programador compatible con DOCSIS puede retrasar las subvenciones de UGS hasta <val> microsegundos desde el momento en que la concesión de UGS debe programarse idealmente y, por lo tanto, causar fluctuación.

Esto tiene el mismo efecto que la reducción del tamaño del bloque no fragmentable en una longitud equivalente al número de microsegundos especificado. Por ejemplo, si mantiene el valor predeterminado para la ráfaga de phy predeterminada (2000 bytes) y especifica un valor de 1000 microsegundos para la fluctuación de ranura no fragmentable, el bloque no fragmentable se reduce (consulte la Figura 23).

Figura 23: La fluctuación de ranura no fragmentable de cero reduce el tamaño de bloque no fragmentable

Nota: El número de bytes al que corresponde la hora de 1000 microsegundos depende de la velocidad con la que se configure el canal ascendente para funcionar a través de la configuración del esquema de modulación y ancho de canal.

Nota: Con una fluctuación de ranura no fragmentable de cero, el planificador compatible con DOCSIS puede aumentar el número de concesiones de UGS que admite un flujo ascendente de manera similar a tener una ráfaga rápida predeterminada reducida.

Nota: Vuelva al ejemplo con una concesión DOCSIS 1.1 grande A seguida de una concesión B grande y no fragmentable DOCSIS 1.0 para programar en un flujo ascendente. La fluctuación de ranura no fragmentable se establece en 1000 microsegundos. El planificador compatible con DOCSIS se comporta como se muestra en las figuras de esta sección.

Nota: Primero, el planificador asigna tiempo de transmisión para la concesión A. Para ello, el planificador fragmenta la subvención en subvenciones A₁ y A ₂ de modo que las subvenciones encajen antes y después del primer bloque de subvenciones UGS. Para programar la concesión B, el programador debe decidir si el programador puede ajustar el bloque no fragmentable en el espacio libre después de conceder A₂ sin demora al siguiente bloque de concesiones UGS en más de la fluctuación de ranura no fragmentable configurada de 1000 microsegundos. Estas cifras muestran que si el planificador coloca la concesión B junto a la concesión A₂, el siguiente bloque de tráfico UGS se retrasa, o se remueve, en más de 1500 microsegundos. Por lo tanto, el planificador no puede colocar la subvención B directamente después de la concesión A ₂.

Figura 24: la Subvención B no se puede programar junto a la Subvención A2.

El siguiente paso para el planificador compatible con DOCSIS es ver si la siguiente brecha disponible puede admitir la subvención B. La figura 25 muestra que si el planificador coloca el otorgamiento B después del segundo bloque de concesiones de UGS, el tercer bloque no se retrasa más de 1000 microsegundos por la fluctuación de ranura no fragmentable configurada.

Figura 25: Otorgamiento B programado después del segundo bloque de concesiones de UGS

Con el conocimiento de que la inserción de la subvención B en este punto no causa fluctuación inaceptable en las subvenciones UGS, el planificador compatible con DOCSIS inserta la subvención B y retrasa ligeramente el siguiente bloque de subvenciones UGS.

Figura 26: Se ha programado la concesión B no fragmentable y las subvenciones UGS se han retrasado

Resultado del comando show

Puede utilizar el comando show interface cable interface-number mac-scheduler upstream-number para medir el estado actual del planificador que cumple con DOCSIS. A continuación se muestra un ejemplo del resultado de este comando tal como se ve en un Cisco uBR7200VXR con una tarjeta de línea 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 sección explica cada línea del resultado de este comando. Tenga en cuenta que esta sección del documento supone que ya está familiarizado con los conceptos generales de programación ascendente de DOCSIS.

• Programador MAC DOCSIS 1.1 para Cable3/0/U0

  La primera línea del resultado del comando indica el puerto ascendente al que pertenecen los datos.

• Queue[Encuestas de Rng] 0/128, 0 descartes, max 1

  Esta línea muestra el estado de la cola que alimenta keepalives de mantenimiento de la estación o las oportunidades de medición en el planificador compatible con DOCSIS. 0/128 indica que actualmente hay cero de un máximo de 128 oportunidades de medición pendientes en la cola.

  El contador de caídas indica el número de veces que una oportunidad de medición de distancias no se pudo poner en cola porque esta cola ya estaba llena (es decir, 128 oportunidades de medición de distancias pendientes). Las caídas aquí probablemente ocurrirían solamente en un flujo ascendente con un número extremadamente grande de cablemódems en línea y si hubiera un gran número de flujos de servicio UGS o RTPS activos. Esta cola se atiende con la prioridad más alta cuando se ejecuta el planificador de quejas DOCSIS. Por lo tanto, las caídas en esta cola son altamente improbables pero muy probablemente indican una sobresuscripción grave del canal ascendente.

  El contador máximo indica el número máximo de elementos presentes y en esta cola desde la última ejecución del comando show interface cable mac-scheduler. Lo ideal sería que se mantuviera lo más cerca posible de cero.

• Cola [concesiones CIR] 0/64, 0 caídas, máx. 0

  Esta línea muestra el estado de la cola que administra las subvenciones para los flujos de servicio con una velocidad de tráfico reservado mínima especificada. En otras palabras, estos servicios de cola conceden para flujos de servicio de velocidad de información comprometida (CIR). 0/64 indica que actualmente hay cero de un máximo de 64 subvenciones pendientes en la cola.

  El contador de caídas indica el número de veces que no se pudo poner en cola una subvención CIR porque esta cola ya estaba llena (es decir, 64 concesiones en cola). Las caídas pueden acumularse aquí si los flujos de servicio de UGS, RTPS y estilo CIR sobresuscriben el flujo ascendente, y pueden indicar la necesidad de un control de admisión más estricto.

  El contador máximo indica el número máximo de concesiones en esta cola desde la última ejecución del comando show interface cable mac-scheduler. Esta cola tiene la segunda prioridad más alta, por lo que el planificador compatible con DOCSIS asigna tiempo a los elementos de esta cola antes de que el programador atienda las colas de mejor esfuerzo.

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

  Las ocho entradas siguientes muestran el estado de las colas que administran las subvenciones para los flujos de servicio de prioridad 7 a 0. Los campos de estas entradas tienen el mismo significado que los campos de la entrada de cola CIR. La primera cola que se atenderá en este grupo es la cola BE (7) y la última que se atenderá es la cola BE (0).

  Las caídas pueden ocurrir en estas colas si un nivel de prioridad más alto del tráfico consume todo el ancho de banda ascendente o si se produce una sobresuscripción del flujo ascendente con UGS, RTPS y flujos de servicio estilo CIR. Esto puede indicar la necesidad de reevaluar las prioridades de DOCSIS para flujos de servicio de gran volumen o la necesidad de un control de admisión más estricto en el flujo ascendente.

• Ranuras Req 36356057

  Esta línea indica el número de oportunidades de solicitud de ancho de banda que se han anunciado desde que se ha activado el flujo ascendente. Este número debe aumentar continuamente.

• Ranuras de datos/solicitudes 185165

  Aunque el nombre sugiere que este campo muestra el número de solicitudes u oportunidades de datos anunciadas en el flujo ascendente, este campo muestra realmente el número de periodos que el CMTS anuncia para facilitar la funcionalidad de administración avanzada del espectro. Se espera que este contador aumente para los flujos ascendentes en las tarjetas de línea estilo MC28U y MC520.

  Las oportunidades de solicitud/datos son las mismas que las oportunidades de solicitud de ancho de banda, excepto que los cablemódems también pueden transmitir pequeñas ráfagas de datos en estos períodos. Los CMTS de la serie uBR de Cisco no programan actualmente oportunidades reales de datos/solicitudes.

• Ranuras Mtn Init 514263

  Esta línea representa el número de oportunidades de mantenimiento iniciales que se han anunciado desde que se activó el flujo ascendente. Este número debe ir en constante aumento. Los cablemódems que realizan los primeros intentos de establecer la conectividad con el CMTS utilizan oportunidades de mantenimiento iniciales.

• Ranuras Stn Mtn 314793

  Esta línea indica el número de keepalive de mantenimiento de estación o de oportunidades de medición ofrecidas en el flujo ascendente. Si hay cablemódems en línea en el flujo ascendente, este número debe estar en constante aumento.

• Ranuras de concesión cortas 12256, ranuras de concesión largas 4691

  Esta línea indica el número de concesiones de datos ofrecidas en la fase ascendente. Si hay cablemódems que transmiten datos ascendentes, estos números deben estar continuamente en aumento.

• Ranuras ATDMA de concesión corta 0, ranuras ATDMA de concesión larga 0, ranuras de concesión ATDMA UGS 0

  Esta línea representa el número de concesiones de datos ofrecidas en el modo de acceso múltiple por división de tiempo avanzada (ATDMA) en el flujo ascendente. Si hay cablemódems que funcionan en el modo DOCSIS 2.0 y transmiten datos ascendentes, estos números deben estar continuamente en alza. Tenga en cuenta que ATDMA contabiliza por separado el tráfico UGS.

• Ranuras Awacs 277629

  Esta línea muestra el número de períodos dedicados a la administración avanzada del espectro. Para que ocurra la administración avanzada del espectro, el CMTS necesita programar periódicamente horas en las que cada cablemódem debe realizar una transmisión breve para que la función de análisis del espectro interno pueda evaluar la calidad de la señal de cada módem.

• Recuento de fragmentación 41

  Esta línea muestra el número total de fragmentos que el puerto ascendente está programado para recibir. Por ejemplo, una trama fragmentada en tres partes haría que este contador aumentara en tres.

• Prueba de fragmentación desactivada

  Esta línea indica que el comando test cable fragmentation no ha sido invocado. No utilice este comando en una red de producción.

• Uso del canal ascendente Avg: 26%

  Esta línea muestra la utilización actual del canal ascendente por las transmisiones de datos ascendentes. Esto abarca las transmisiones realizadas a través de subvenciones ATDMA short, ATDMA short, ATDMA long y ATDMA UGS. El valor se calcula cada segundo como promedio móvil. Cisco recomienda que este valor no supere el 75% de forma ampliada durante los tiempos de uso máximo. De lo contrario, los usuarios finales pueden empezar a notar problemas de rendimiento con tráfico de mejor esfuerzo.

• Ranura de contención de porcentaje medio: 73%

  Esta línea muestra el porcentaje de tiempo ascendente dedicado a las solicitudes de ancho de banda. Esto equivale a la cantidad de tiempo libre en el flujo ascendente y, por lo tanto, se reduce a medida que aumenta el porcentaje de utilización del canal ascendente promedio.

• Ranuras de medida de distancia inicial de porcentaje medio: 2%

  Esta línea indica el porcentaje de tiempo ascendente dedicado a las oportunidades de medición inicial que utilizan los cablemódems cuando intentan establecer la conectividad inicial con el CMTS. Este valor siempre debe seguir siendo un porcentaje bajo de la utilización total.

• Avg percent minislots lost on late Maps: 0%

  Esta línea indica el porcentaje de tiempo ascendente que no se programó porque el CMTS no pudo transmitir un mensaje MAP de asignación de ancho de banda a los cablemódems a tiempo. Este parámetro siempre debe estar cerca de cero, pero puede comenzar a mostrar valores más grandes en sistemas que tienen una carga de CPU extremadamente alta.

• Sched Table Rsv-state: Subvenciones 0, Solicitudes 0

  Esta línea muestra el número de flujos de servicio de estilo UGS (concesiones) o flujos de servicio de estilo RTPS (consultas) que tienen concesiones preasignadas para ellos en el planificador compatible con DOCSIS, pero que aún no están activados. Esto ocurre cuando se mueve un cablemódem con flujos de servicio UGS o RTPS existentes de un flujo ascendente a otro a través del balanceo de carga. Tenga en cuenta que esta cifra solo se aplica a las subvenciones que utilizan el planificador conforme a DOCSIS y no al planificador LLQ.

• Sched Table Adm-State: Subvenciones 6, Requiere 0, Hasta El 27%

  Esta línea indica el número de flujos de servicio de estilo UGS (concesiones) o flujos de servicio de estilo RTPS (consultas) que tienen concesiones preasignadas para ellos en el planificador compatible con DOCSIS para este flujo ascendente. Util es la utilización estimada del ancho de banda ascendente total disponible por estos flujos de servicio. Tenga en cuenta que esta cifra solo se aplica a las subvenciones que utilizan el planificador conforme a DOCSIS y no al planificador LLQ.

• <Tipo de planificación> : x SID, nivel de reserva en bps y

  Esta línea indica el número de flujos de servicio o SID <Schedule-type> presentes en el flujo ascendente y la cantidad de ancho de banda en bits por segundo que estos flujos de servicio han reservado. Para el mejor esfuerzo y los flujos de servicio estilo RTPS, el ancho de banda se reserva solamente si el flujo de servicio tiene configurada una velocidad reservada mínima.

Ventajas y desventajas de DOCSIS Compliant Scheduler

El objetivo del planificador compatible con DOCSIS es minimizar la fluctuación para los flujos de servicio estilo UGS y RTPS y también acomodar las ráfagas DOCSIS 1.0 no fragmentables. La disyuntiva que hace el planificador conforme con DOCSIS para alcanzar estos objetivos es que el número máximo de flujos de servicio UGS soportados por flujo ascendente es inferior al máximo teórico que un flujo ascendente de DOCSIS puede soportar físicamente, y que el tráfico de mejor esfuerzo puede estar sujeto a un grado de fragmentación.

Mientras que el planificador compatible con DOCSIS admite un número ligeramente inferior al máximo teórico de flujos de servicio UGS simultáneos en un flujo ascendente, y mientras que algunas otras implementaciones de programación pueden soportar más flujos de servicio UGS por flujo ascendente, debe centrarse en la compensación.

Por ejemplo, ningún planificador puede soportar flujos de servicio UGS sin fluctuación que consumen cerca del 100% de ancho de banda de un canal ascendente y que, simultáneamente, soportan grandes tramas concatenadas no fragmentables de módems DOCSIS 1.0. En cuanto al diseño del planificador conforme con DOCSIS, hay dos puntos importantes que comprender.

• El 75% es la utilización ascendente máxima deseable.

  Cisco ha observado que cuando un flujo ascendente se ejecuta de forma uniforme con una utilización superior al 75%, incluida la utilización debido a los flujos de servicios de UGS, el rendimiento del tráfico de mejor esfuerzo comienza a verse notablemente afectado. Esto significa que si las señalizaciones UGS y VoIP consumen más del 75% del flujo ascendente, cualquier tráfico IP normal transmitido por flujos de servicio de mejor esfuerzo comienza a sufrir una latencia añadida que causa tiempos de respuesta y rendimiento notablemente más bajos. Esta degradación del rendimiento a niveles de utilización más altos es una propiedad que comparten la mayoría de los sistemas de red de acceso múltiple modernos, por ejemplo, redes LAN Ethernet o inalámbricas.

• Cuando se utiliza el ancho de canal ascendente típicamente implementado de 3,2 MHz, el programador compatible con DOCSIS permite que los flujos de servicio UGS utilicen hasta un 75% del canal ascendente. Estos flujos de servicio transmiten llamadas VoIP G.711.

Estos dos puntos ofrecen una perspectiva de las consideraciones de diseño que se tuvieron en cuenta cuando se creó el planificador compatible con DOCSIS. El planificador compatible con DOCSIS se diseñó de modo que para los flujos de servicio típicos de UGS (G.711) y con el ancho de canal más implementado de 3,2 MHz, los límites de llamada por flujo ascendente comienzan a aplicarse en torno a la marca de utilización del 75%. Esto significa que el planificador minimiza correctamente la fluctuación y también permite un número razonable de flujos de servicio UGS en el flujo ascendente.

En otras palabras, el planificador compatible con DOCSIS se diseñó para funcionar correctamente en las redes DOCSIS de producción, y no para permitir que los flujos de servicio UGS utilicen hasta un porcentaje irreales alto del ancho de banda ascendente. Este escenario puede ocurrir en un escenario de prueba de laboratorio inventariado.

Puede ajustar el programador compatible con DOCSIS para admitir un mayor número de llamadas UGS por flujo ascendente, aunque en detrimento de la fluctuación de UGS y la eficiencia del tráfico de mejor esfuerzo. Para ello, debe reducir el parámetro cable default-phy-burst al valor mínimo recomendado de 1540 bytes. Si necesita más densidad de llamada, configure el cable ascendente unfrag-slot-jitter en un valor como 2000 microsegundos. Sin embargo, Cisco no recomienda estos parámetros generalmente para una red de producción.

Otra ventaja del planificador que cumple con DOCSIS es que no existe un requisito obligatorio de que los operadores CMTS configuren explícitamente el control de admisión para los flujos de servicio de estilo UGS y RTPS. Esto se debe a que el método de planificación previa a la asignación elimina la posibilidad de una suscripción excesiva accidental. Aunque este es el caso, Cisco todavía sugiere que los operadores se aseguren de que la utilización ascendente total no exceda el 75% durante periodos prolongados durante horas punta. Por lo tanto, Cisco recomienda la configuración del control de admisión como práctica recomendada.

Una desventaja del planificador que cumple con DOCSIS es que la posición fija de las subvenciones UGS puede requerir la fragmentación de las subvenciones de mejor esfuerzo cuando la utilización de UGS es alta. En general, la fragmentación no causa problemas notables de rendimiento, pero sí produce un ligero aumento de la latencia para el tráfico de mejor esfuerzo y un aumento de la sobrecarga de protocolo presente en el canal ascendente.

Otra desventaja es que cuando los cablemódems DOCSIS 1.0 quieren realizar transmisiones ascendentes no fragmentables, puede haber un retraso antes de que aparezca una brecha apropiada entre bloques de concesiones UGS programadas previamente. Esto también puede conducir a una mayor latencia del tráfico ascendente DOCSIS 1.0 y a un uso menos que óptimo del tiempo de transmisión ascendente disponible.

Por último, el planificador compatible con DOCSIS está diseñado para funcionar mejor en entornos en los que todos los flujos de servicios UGS comparten el mismo tamaño de concesión y el mismo intervalo de concesión. Es decir, donde todas las llamadas VoIP comparten el mismo códec, como la empaquetación G.711 de 10 ms o 20 ms, como ocurriría en un sistema típico basado en Packetcable 1.0. Cuando existen intervalos de concesión y tamaños dispares, la capacidad del planificador compatible con DOCSIS para admitir un gran número de flujos de servicio UGS se reduce en un flujo ascendente. Además, se puede producir una cantidad muy pequeña de fluctuación (menos de 2 ms) para algunas subvenciones a medida que el planificador intenta intercalar los flujos de servicio UGS con diferentes períodos y tamaños.

A medida que las redes PacketCable MultiMedia (PCMM) se hacen más prevalentes, puede volverse más común que una variedad de códecs VoIP con varios intervalos de empaquetado funcionen simultáneamente. Este tipo de entorno puede prestarse al Planificador de cola de latencia baja.

Planificador de cola de latencia baja

El planificador de cola de latencia baja (LLQ) se introdujo en la versión 12.3(13a)BC del software del IOS de Cisco. LLQ es el método alternativo para programar servicios ascendentes en un CMTS uBR de Cisco. Este planificador se diseñó para maximizar el número de flujos de servicio estilo UGS y RTPS que un flujo ascendente puede soportar simultáneamente y también mejorar la eficiencia del tráfico de mejor esfuerzo en presencia de flujos de servicio UGS. El intercambio es que el planificador LLQ no hace ninguna garantía con respecto a la fluctuación de los flujos de servicio UGS y RTPS.

Como se describe en la sección DOCSIS Compliant Scheduler, el planificador compatible con DOCSIS asigna previamente el tiempo de transmisión para los flujos de servicio estilo UGS y RTPS. Esto es similar al modo en que un sistema de multiplexación por división de tiempo (TDM) antiguo asigna ancho de banda a un servicio para garantizar determinados niveles de latencia y fluctuación.

En las redes modernas basadas en paquetes, la colocación en cola de baja latencia es el método que utilizan los routers para asegurarse de que los paquetes asociados con servicios de alta prioridad, por ejemplo, voz y vídeo, puedan entregarse en una red antes que otros paquetes de menor prioridad. Este es también el método que utilizan los routers modernos para garantizar que la latencia y la fluctuación se minimizan para el tráfico importante.

El uso de la palabra "garantía" para el sistema basado en TDM y "minimizado" para el sistema basado en LLQ en relación con la fluctuación y la latencia. Si bien es deseable una garantía de cero latencia y fluctuación, la ventaja es que un sistema de este tipo suele ser inflexible, difícil de reconfigurar y, por lo general, incapaz de adaptarse fácilmente a los cambios en las condiciones de la red.

Un sistema que minimiza la latencia y la fluctuación, en lugar de ofrecer una garantía estricta, puede proporcionar flexibilidad para optimizarse continuamente frente a los cambios en las condiciones de la red. El planificador de cola de latencia baja se comporta de una manera similar al sistema LLQ basado en el router de paquete. En lugar de un sistema de asignación preprogramado para las subvenciones UGS, este sistema programa las subvenciones "lo antes posible" en el momento en que deben programarse.

El enfoque que otorga las subvenciones a los flujos de servicios UGS debe asignarse lo antes posible, pero no necesariamente con una periodicidad perfecta, este sistema intercambia estrictas garantías de fluctuación para aumentar la capacidad de UGS y reducir la fragmentación de datos de mejor esfuerzo.

Configuración

Para las versiones 12.3(13a)BC y posteriores del software del IOS de Cisco, el planificador LLQ es uno de los dos algoritmos del programador alternativo. Puede habilitar LLQ para uno, todos o algunos de estos modos de programación:

• UGS

• RTPS

• NRTPS

El planificador LLQ no está habilitado de forma predeterminada. Debe activar explícitamente el planificador LLQ para los tipos de programación ascendente requeridos. Utilice el tipo de programación cable upstream upstream-port [nrtps | rtps | ugs] mode llq cable interface.

En general, puede habilitar el planificador LLQ para todos los modos de programación enumerados si éste es el modo de programación deseado. Este es un ejemplo de una situación en la que desea habilitar la programación LLQ para un solo tipo de modo de programación pero conservar el planificador compatible con DOCSIS para otros:

Los flujos de servicio RTPS no tienen un requisito estricto para la fluctuación, pero los flujos de servicio UGS sí. En este caso, puede habilitar el planificador LLQ para los flujos de servicio RTPS y conservar el planificador compatible con DOCSIS para UGS.

Operación del Programador LLQ

El planificador LLQ funciona de la misma manera que la función de colocación en cola de prioridad del planificador compatible con DOCSIS con la adición de una cola de latencia baja especial (LLQ), que tiene prioridad sobre todas las demás colas.

El planificador LLQ inicia un temporizador en nombre de todos los flujos de servicio de estilo UGS (y RTPS) activos. El temporizador se configura para que se apague una vez cada "intervalo de concesión". Siempre que caduque el temporizador, una concesión de UGS se pone en cola en la cola LLQ. Dado que esta subvención se coloca en la cola LLQ que tiene prioridad máxima, la subvención se programa en el siguiente momento posible en el que haya espacio libre.

Los diagramas de esta sección muestran un ejemplo de un sistema con tres flujos de servicio UGS activos con el mismo intervalo de concesión. La figura 27 muestra los temporizadores de los flujos de servicio UGS a la izquierda, etiquetados como UGS-1 a UGS-3. La flecha amarilla se desplaza en el sentido de las agujas del reloj. Cuando la flecha amarilla apunta hacia el punto rojo, se agrega una subvención UGS a la cola LLQ. También puede ver las ocho colas de prioridad conocidas de 0 a 7 y una cola LLQ nueva que toma prioridad sobre todas ellas. Finalmente, a la derecha, está la línea de tiempo de asignación de ancho de banda que describe cómo se programan las subvenciones en el flujo ascendente. Para mayor claridad, la línea de tiempo de asignación de ancho de banda incluye un puntero de "hora actual". Este puntero avanza a lo largo de la línea de tiempo a medida que avanza el ejemplo.

Figura 27: Sistema de colocación en cola de baja latencia

El primer evento que ocurre es que caduca el temporizador UGS-1 en la parte superior izquierda. Una subvención correspondiente se coloca en cola en la cola LLQ. Al mismo tiempo, se pone en cola una subvención de mejor esfuerzo denominada A con prioridad 2.

Figura 28: La subvención para UGS-1 y la concesión de prioridad 2 A están en cola

El planificador LLQ ahora asigna el tiempo de transmisión a las concesiones pendientes en el orden de prioridad. La primera concesión para recibir la hora de transmisión es la subvención para UGS-1 que espera en la cola LLQ. A continuación se concede la A.

Figura 29: se asigna tiempo de transmisión a UGS-1 y a Grant A

El siguiente evento que ocurrirá es que el temporizador UGS-2 vence y hace que una concesión para el flujo de servicio UGS-2 se ponga en cola en la cola LLQ. Al mismo tiempo, se pone en cola la prioridad 0 del subsidio B y la prioridad 6 del subsidio C.

Figura 30: El temporizador UGS-2 vence. Las subvenciones B y C están en cola

El planificador LLQ asigna una vez más el tiempo de transmisión en el orden de prioridad de concesión, lo que significa que primero el planificador asigna tiempo a la subvención para UGS-2, después para la concesión C y, finalmente, para la subvención B.

Figura 31: Las subvenciones UGS-2, C y B se asignan al tiempo de transmisión

Suponga que no se concede el mejor esfuerzo para introducir el programador durante un tiempo. Los temporizadores UGS caducan unas cuantas veces más. Ahora puede ver el tipo de período con el que el planificador asigna subvenciones a los flujos de servicio de UGS. Parecen estar separadas equitativamente. Suponga que cuando las subvenciones aparecen de esta manera en relación con las demás en el plazo de asignación de ancho de banda, no experimentan ninguna fluctuación significativa.

Figura 32: UGS-1, UGS-2 y UGS-3 reciben varias subvenciones. El otorgamiento D está en cola

La figura 32 indica la posición ideal para la próxima subvención UGS-2. Si UGS-2 puede hacer que la subvención se coloque en este lugar, UGS-2 no experimentará ninguna fluctuación para la subvención. Observe que todavía hay tiempo para que la próxima subvención UGS-2 se ponga en cola en la cola LLQ.

En la figura 32 también se indica que una concesión D de prioridad 0 muy grande acaba de entrar en la cola de prioridad 0. La siguiente acción que realiza el planificador LLQ es programar la hora de transmisión para la concesión D.

La figura 33 muestra este escenario. Avanza el reloj un poco hasta el punto en que se pone en cola la próxima subvención para UGS-2.

Figura 33: La Subvención D Recibe Tiempo De Transmisión. La subvención para UGS-2 está en cola

La subvención D parece programarse en el momento en que la próxima subvención UGS-2 debe programarse para cero fluctuación. Ahora la pregunta es por qué el planificador LLQ permite que se programe la concesión D en ese momento y no retrasa la concesión D hasta después de la concesión para UGS-2 o por qué D no se fragmenta. La respuesta es que el planificador LLQ no preasigna el tiempo de transmisión para los flujos de servicio UGS. Por lo tanto, el planificador LLQ no sabe de antemano dónde se colocarán las subvenciones UGS en la línea de tiempo de asignación de ancho de banda. El planificador LLQ no conoce las concesiones de UGS hasta que están en cola en la cola LLQ. En este ejemplo, para cuando la subvención para UGS-2 entre en la cola, la subvención D ya está programada.

El planificador LLQ programa la subvención para UGS-2 en la siguiente oportunidad disponible, pero esta subvención se retrasa ligeramente desde la posición ideal, lo que por definición significa que esta subvención en particular experimenta cierta fluctuación.

Figura 34: La subvención para UGS-2 se demora y experimenta fluctuación

Aunque el planificador compatible con DOCSIS podría haber evitado esta fluctuación, el planificador LLQ evita un retraso o fragmentación de la concesión D a expensas de sólo una pequeña cantidad de fluctuación. Un búfer de fluctuación en un extremo VoIP puede compensar fácilmente esta fluctuación.

La otra situación en la que se puede producir fluctuación es cuando el temporizador LLQ para varios flujos de servicio caduca al mismo tiempo y UGS otorga la espera detrás de otras subvenciones UGS en cola dentro de la cola LLQ. El planificador LLQ se ha diseñado para minimizar la posibilidad de que esto ocurra. El programador extiende automáticamente los tiempos de vencimiento de los temporizadores de flujo de servicio.

Según el planificador compatible con DOCSIS, el planificador LLQ tiene dos colas más que los ejemplos no mencionan. Estas son las colas:

1. La primera cola se utiliza para programar el tráfico keepalive de mantenimiento periódico de la estación para mantener los cablemódems en línea. Esta cola se atiende justo después de la cola LLQ.

2. La segunda es una cola para las subvenciones asignadas a flujos de servicio con una tasa reservada mínima (flujos de servicio CIR). Esta cola CIR se trata como una cola de "prioridad 8" para asegurarse de que los flujos de servicio con una velocidad comprometida reciban el rendimiento mínimo requerido.

Control de admisión

A diferencia del planificador compatible con DOCSIS, el planificador LLQ no utiliza un sistema de preprogramación que detiene la sobresuscripción accidental de un flujo ascendente con flujos de servicio UGS y RTPS. Esta es la razón por la que debe configurar explícitamente el control de admisión ascendente en cualquier flujo ascendente que utilice el planificador LLQ. Esta configuración garantiza que el ancho de banda ascendente total de los flujos de servicio UGS no exceda los límites normales.

Cisco sugiere en general que no permite que la utilización de un canal ascendente supere el 75% durante períodos prolongados durante períodos de uso máximo. Por ejemplo, si el tráfico UGS consume más del 75% del ancho de banda ascendente, los datos de mejor esfuerzo comienzan a sufrir problemas de latencia excesiva y rendimiento.

Naturalmente, si un operador CMTS puede aceptar las consecuencias negativas para el tráfico de mejor esfuerzo, puede permitir que los flujos de servicio UGS consuman un 75% del ancho de banda ascendente disponible. Sin embargo, también debe considerar el impacto en el tráfico de administración de la Capa 2 en el canal ascendente. Debe permitir tiempo para la mensajería de mantenimiento inicial y de la estación (señales de mantenimiento del cable módem). Si no tiene esto en cuenta y el tráfico UGS consume cerca del 100% del ancho de banda, los cablemódems no pueden conectarse o pueden desconectarse.

Aquí hay un ejemplo de configuración para el control de admisión. Este ejemplo restringe los flujos de servicio UGS en un flujo ascendente determinado al 50% del ancho de banda disponible del flujo ascendente. Esta forma del comando también transmite las trampas SNMP a cualquier estación de administración de red configurada cuando se alcanzan los umbrales menor y mayor del 30% y el 40% de utilización. El comando es el siguiente:

cable upstream upstream-number admisión-control us-bandwidth schedu-type UGS small 30 major 40 exclusiva 50

Vea la sección Control de Admisión en la sección DOCSIS Compliant Scheduler de este documento para ver cómo configurar el control de admisión.

Resultado del comando show

Ejecute el comando show interface cable interface-number mac-scheduler upstream-number para medir el estado actual del planificador LLQ.

Este es un ejemplo del resultado de este comando. Las partes del resultado del comando que son diferentes de cuando el planificador compatible con DOCSIS está operativo están en negrita:

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 obtener una explicación de las líneas de texto sin formato en este resultado, vea la sección Salida del Comando Show para el Planificador conforme a DOCSIS.

Estas son las descripciones de las líneas en negrita del resultado del comando show:

• Queue[LLQ Grants] 0/64, 0 descartes, max 3

  Esta línea muestra el estado de la cola LLQ, que administra las concesiones para los tipos de flujo de servicio especificados en el tipo de programación ascendente del cable [nrtps | rtps | ugs] mode llq. 0/64 indica que actualmente hay cero de un máximo de 64 subvenciones pendientes en la cola.

  El contador de caídas indica el número de veces que el programador no pudo poner en cola una subvención UGS o una encuesta RTPS porque esta cola ya estaba llena (es decir, cuando hay 64 concesiones en cola). Si se producen caídas en esta cola, la explicación más probable es que el flujo ascendente está sobresuscrito con flujos de servicio UGS o RTPS y debe aplicar un control de admisión más estricto.

  El contador máximo indica el número máximo de concesiones que están en esta cola desde que se ejecutó por última vez el comando show interface cable mac-scheduler. Cuando está presente, esta cola tiene la prioridad más alta de todas las colas enumeradas.

• r4k ticks en 1ms 600000

  Este campo representa una variable de temporización interna que utiliza el planificador LLQ para asegurarse de que las subvenciones se colocan en la cola LLQ con alta precisión.

• Total de eventos de programación 5009

  Esta línea indica el número de veces que el planificador LLQ intenta poner en cola una subvención desde la última vez que se ejecutó el comando show interface cable mac-scheduler para este flujo ascendente. Este contador se reinicia cada vez que se ejecuta el comando show.

• No se necesita ninguna búsqueda 5009

  Después de que el planificador LLQ pone en cola una concesión, el planificador LLQ intenta restablecer el temporizador de flujo de servicio para prepararse para la próxima vez que se pone en cola una concesión. Si no hay problemas con un reinicio del temporizador, este contador aumenta. Lo ideal es que este contador tenga el mismo valor que el contador Total de eventos de programación.

• Entrada anterior libre 0, entrada siguiente libre 0

  Ninguno de estos contadores aumenta en las versiones actuales del software del IOS de Cisco. Estos contadores siempre permanecen en cero.

• No se pudo programar 0, la recuperación falló 0

  Esta línea indica el número de veces que el planificador LLQ no pudo organizar que el temporizador de concesión de un flujo de servicio se configurara correctamente. Esto sólo debe ocurrir si el planificador LLQ gestiona un número extremadamente grande de concesiones con intervalos de concesión muy bajos. Es muy poco probable que estos contadores aumenten en una red de producción. Un incremento de estos contadores puede indicar que los flujos de servicio de UGS y RTPS consumen más ancho de banda que el disponible físicamente en el flujo ascendente. En esta situación, debe implementar los comandos de control de admisión adecuados.

• Hora actual 1341 entrada 61

  Esta línea muestra temporizadores internos para el planificador LLQ medidos en milisegundos. Cuando la "entrada" enumerada aquí es igual al campo "Entrada" enumerado en las estadísticas de flujo por servicio, una subvención se coloca en cola en la cola LLQ.

Estas estadísticas se repiten para cada flujo de servicio que maneja el planificador LLQ. En este ejemplo hay tres flujos de servicio de este tipo.

• Entrada 188, Bin 13

  Cuando el valor "Entry" es igual al campo "entry" en el elemento anterior, el temporizador para este flujo de servicio caduca y una concesión entra en la cola LLQ. Este campo se restablece cada vez que el flujo de servicio tiene una concesión en cola.

• SID: 416

  El identificador de servicio (SID) para el flujo de servicio que concede las programaciones del planificador LLQ.

• IUC: 5

  El código de uso del intervalo anunciado en un mensaje MAP para las subvenciones que pertenecen a este flujo de servicio. Esto es casi siempre 5 para "datos cortos", 6 para "datos largos" o 11 para "UGS PHY avanzados" cuando un flujo de servicio estilo UGS está en uso. Para el flujo de servicio estilo RTPS, este valor es siempre 1 para "Request".

• size_ms: 17 size_byte: 232

  El tamaño de la subvención en miniperíodos, seguido del tamaño de la subvención en bytes. Un minislot es la unidad más pequeña de transmisión ascendente en una red DOCSIS y normalmente equivale a 8 o 16 bytes.

• Frag: N

  Indica si la concesión es fragmentable. Actualmente, este valor siempre se establece en N.

• Inval: 20

  El intervalo de concesión o sondeo en milisegundos.

• tipo 8

  8 indica que este flujo de servicio es UGS, 10 indica RTPS y 11 indica NRTPS.

• tiempo perfecto ref 188

  El momento ideal en el que se debe haber programado esta subvención. Normalmente, esto es lo mismo que "Entry" (Entrada) en la parte superior. Si no, hay una indicación de una corriente ascendente fuertemente congestionada que necesita un control de admisión más estricto.

• desviación de ref 0

  La diferencia entre cuándo se ha programado esta subvención y cuándo se debe haber programado la subvención. Esta es la diferencia entre "Entry" y "perfectos time ref". Por lo tanto, este valor normalmente debe ser cero.

• prioridad 10

  En las versiones actuales de Cisco IOS Software, este valor siempre se establece en 10, pero puede variar en el futuro.

• posición 188, bin 13

  Estos campos deben ser los mismos que "Entry, Bin" en la parte superior de esta lista.

Ventajas y Desventajas de LLQ Scheduler

El objetivo del planificador LLQ es aumentar la capacidad de UGS y RTPS para los canales ascendentes, y aumentar la eficiencia del tráfico de mejor esfuerzo. La disyuntiva que el planificador LLQ realiza para alcanzar estos objetivos es que este programador no proporciona explícitamente garantías para la fluctuación del flujo de servicio UGS y RTPS. Más bien, el planificador LLQ programa las subvenciones UGS y las encuestas RTPS lo más cerca posible del tiempo ideal con el fin de minimizar la fluctuación.

El planificador LLQ también puede manejar mejor los flujos de servicio UGS con diferentes intervalos de concesión y tamaños de concesión que el planificador compatible con DOCSIS. Esta función puede ser útil en un entorno PCMM donde diferentes tipos de llamadas VoIP y posiblemente otras aplicaciones se atienden simultáneamente en un canal ascendente.

El planificador LLQ programa el tráfico de mejor esfuerzo de manera más eficiente porque el planificador LLQ reduce la probabilidad de fragmentación de las subvenciones. Cuando se programan ráfagas de DOCSIS 1.0 no fragmentables, el planificador LLQ no crea brechas de ancho de banda sin usar frente a concesiones de UGS o sondeos de RTPS como el planificador compatible con DOCSIS a veces. Esto se traduce en un mejor uso del tiempo de flujo ascendente disponible.

Aunque la fluctuación de UGS generalmente es mayor cuando se utiliza el planificador LLQ que cuando se utiliza el planificador compatible con DOCSIS, en las redes típicas basadas en DOCSIS o PacketCable, los niveles de fluctuación del programador LLQ están bien dentro de la capacidad de la tecnología de búfer de fluctuación de punto final VoIP. Esto significa que no hay un impacto notable en la calidad de la llamada VoIP cuando se utiliza el planificador LLQ en una red VoIP diseñada correctamente.

Puede limitar la fluctuación que surge de las grandes ráfagas ascendentes. Para esto, asegúrese de mantener el parámetro cable default-phy-burst en el valor predeterminado de 2000 bytes o menos. Si un sistema utiliza un canal ascendente particularmente lento, digamos con un ancho de canal de 800 kHz o menor, puede lograr reducciones adicionales en la fluctuación si fuerza que las ráfagas grandes se fragmenten en otras más pequeñas con el comando cable upstream fragment-force.

Cuando el planificador LLQ está en uso, debe configurar el control de admisión de cable para evitar la posibilidad de sobresuscripción del canal ascendente. Flujos de servicio UGS más activos de los que puede gestionar físicamente el flujo ascendente, lo que se traduce en una calidad de voz deficiente en todos los flujos de servicio UGS en el flujo ascendente. En casos extremos, esto también significa que los cablemódems se desconectan y que los nuevos cablemódems no pueden conectarse. Cisco recomienda que los operadores CMTS configuren el control de admisión de modo que el uso ascendente total en cualquier puerto ascendente no sea superior al 75% durante periodos prolongados.

Conclusiones

La serie uBR de productos DOCSIS CMTS de Cisco proporciona dos algoritmos de programación ascendentes alternativos, por lo que es capaz de satisfacer una variedad de condiciones de red.

El planificador compatible con DOCSIS, que está optimizado para fluctuaciones bajas, es más adecuado para sistemas de voz Packetcable 1.x típicos con un códec VoIP uniforme en su lugar y donde se desean niveles estándar de utilización del canal ascendente por los flujos de servicio UGS.

El planificador de cola de latencia baja está diseñado para admitir niveles de utilización ascendente superiores a lo normal por los flujos de servicio UGS, mayor eficiencia del tráfico de mejor esfuerzo y sistemas que utilizan flujos de servicio UGS y RTPS con una variedad de intervalos de concesión y tamaños de concesión.

Apéndice A: Minislots

Un minislot es la unidad de transmisión más pequeña en el flujo ascendente DOCSIS. Cuando un cablemódem transmite una solicitud de ancho de banda al CMTS para pedir tiempo de transmisión ascendente, el módem pregunta en unidades de miniperíodos en lugar de en bytes o milisegundos. Además, cuando un mensaje MAP de asignación de ancho de banda informa a los módems de cuándo pueden transmitir y durante cuánto tiempo, el mensaje contiene la información en unidades de miniperíodos.

El número máximo de miniperíodos que un módem puede solicitar transmitir en una ráfaga es 255. El tamaño del minislot se especifica en las unidades denominadas ticks DOCSIS. Una marca DOCSIS equivale a 6,25 microsegundos en tiempo.

Para configurar el tamaño del minislot en ticks para un puerto ascendente, ejecute el comando cable upstream <upstream-number> minislot-size [1 | 2 | 4 | 8 | 16 | 32 | 64 | 128] comando cable interface.

Sólo se permiten algunos tamaños de miniperíodos con anchos de canal ascendente específicos. Esta tabla muestra los tamaños de miniperíodos válidos en comparación con los anchos de canal ascendente DOCSIS, y también muestra la longitud en los símbolos de esquema de modulación de un minislot con configuraciones válidas.

Nota: Una marca X significa una combinación no válida.

	Ancho del canal	200 kHz	400 kHz	800 kHz	1.6 MHz	3.2 MHz	6.4 MHz
Tamaño de miniranura en garrapatas
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 el número de bytes transmitidos por minislot, multiplique los símbolos por minislot por el número de bits por símbolo para el esquema de modulación configurado. Diferentes esquemas de modulación transmiten diferentes números de bits por símbolo como se muestra en esta tabla:

Esquemas de modulación TDMA DOCSIS 1.1	Bits por símbolo
QPSK	2
16-QAM	4

Esquemas de modulación de ATDMA DOCSIS 2.0	Bits por símbolo
8-QAM	3
32-QAM	5
64-QAM	6

Por ejemplo, con un ancho de canal de 1,6 MHz y un tamaño de miniperíodos de 4 ticks, puede utilizar la primera tabla para llegar a una cifra de 32 símbolos por minislot. Utilice la segunda tabla para convertir esta figura en bytes, porque un símbolo QPSK contiene 2 bits. Un minislot en este ejemplo es equivalente a 32 símbolos por minislot * 2 bits por símbolo = 64 bits por minislot = 8 bytes por minislot.

Recuerde que el número máximo de miniperíodos que un cablemódem puede solicitar transmitir es 255. Por lo tanto, en este ejemplo ascendente la ráfaga más grande en bytes que puede hacer un módem es de 255 miniperíodos * 8 bytes por miniperíodo = 2040 bytes.

Tenga en cuenta que esta figura en bytes es la corrección de error posterior al reenvío y la figura posterior a la sobrecarga de capa física. La corrección de errores y otras sobrecargas de la capa PHY de DOCSIS añaden de 10 a 20 por ciento a la longitud de una trama Ethernet a medida que pasa a través del canal ascendente. Para obtener la figura precisa, utilice el perfil de modulación aplicado al puerto ascendente.

Esta discusión es significativa porque una sección anterior de este documento establece que uno de los límites en el tamaño máximo de ráfaga de un cablemódem es el valor configurado en el comando cable default-phy-burst. Si el comando cable default-phy-burst se configura en 4000 bytes en el contexto de este ejemplo, el factor limitante o el tamaño de ráfaga es el límite de 255 miniperíodos (2040 bytes menos sobrecarga) en lugar del valor cable default-phy-burst.

Puede observar diferentes expresiones del tamaño del minislot para un flujo ascendente con el comando show controller cable interface-number upstream upstream-number . Aquí tiene un ejemplo:

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

Cisco recomienda que establezca el tamaño del miniperíodo de modo que un miniperíodo sea equivalente a 16 bytes o el valor más cercano permitido. Un tamaño de minislot de 16 bytes ofrece a los cablemódems la capacidad de generar una ráfaga posterior a FEC de hasta 255 * 16 = 4096 bytes.

Apéndice B: Avance de MAP

El CMTS genera periódicamente un mensaje especial llamado MAP de asignación de ancho de banda que informa a los cablemódems de un tiempo preciso en el que los módems pueden realizar transmisiones en el canal ascendente. Las señales eléctricas que transmiten el mensaje MAP tardan una cantidad finita de tiempo en propagarse físicamente a través de la red híbrida de fibra coaxial (HFC) desde el CMTS a todos los cablemódems conectados. Como resultado, el mensaje MAP debe ser transmitido lo suficientemente temprano como para que los módems reciban el mensaje y puedan realizar sus transmisiones ascendentes para que lleguen al CMTS en el momento designado.

El tiempo de avance del MAP o el tiempo de anticipación del MAP representa la diferencia entre el momento en que el CMTS genera el mensaje MAP y el momento en que el CMTS necesita recibir la primera transmisión ordenada por el MAP. Esta vez representa una combinación de estos retrasos presentes en un sistema DOCSIS:

• El tiempo que el CMTS tarda en construir el mensaje MAP en el software y para que el mensaje sea puesto en cola y procesado por el circuito de transmisión descendente. El valor de este componente es específico de diferentes plataformas y arquitecturas y, por lo general, es un valor fijo.

• La latencia que agrega la función de entrelazado descendente, que se utiliza con fines de corrección de errores de reenvío para protegerse contra el ruido de impulso. Para cambiar este valor, cambie los parámetros de intercalador descendente.

• Tiempo que tardan las señales eléctricas en viajar a través de la red HFC desde el CMTS al cable módem y, a continuación, volver de nuevo. DOCSIS especifica un tiempo de viaje unidireccional máximo entre el CMTS y el cablemódem de 800 microsegundos. Este valor varía según la longitud física de la planta de cable. El esquema de modulación descendente y el esquema de modulación y ancho del canal ascendente también influyen en este valor.

• Tiempo para que el cablemódem procese un mensaje MAP recibido y pueda prepararse para la transmisión ascendente. No debe ser superior a 200 microsegundos más cualquier demora de interleaver ascendente según las pautas de la especificación DOCSIS. En realidad, este tiempo puede ser de hasta 300 microsegundos o de hasta 100 microsegundos dependiendo de la marca, el modelo y la revisión del firmware del cable módem.

Figura 35: Componentes del tiempo de avance del MAP

El tiempo de avance del mapa puede afectar significativamente a la latencia de las transmisiones ascendentes porque este valor representa el retraso mínimo entre el momento en que el CMTS sabe que un cablemódem quiere hacer una transmisión y el momento en que se le permite al módem hacer esa transmisión. Por esta razón, minimice el tiempo de avance del mapa para reducir la latencia ascendente.

Tenga en cuenta que, en un flujo ascendente congestionado, otros factores también influyen en la latencia ascendente. Por ejemplo, retrasa el retraso que provoca el algoritmo de solicitud de ancho de banda de reintento y la colocación en cola de las subvenciones pendientes entre sí.

La figura 36 muestra la relación entre un MAP que genera el CMTS y la recepción de datos correspondiente en el flujo ascendente.

Figura 36: Relación entre la generación de MAP y la recepción de datos ascendentes

Profundidad del entrelazador

El primer factor en el tiempo de avance del mapa que puede variar es el interleaver de flujo descendente como se utiliza para la protección del ruido de impulso. Esta tabla muestra la latencia agregada a las transmisiones descendentes para varias configuraciones de incremento de pulsación y entrelazado del entrelazador:

Nota: Cuanto mayor sea el tamaño de la pulsación, mayor será la corrección de errores, pero también mayor será la latencia inducida.

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

Puede establecer los parámetros de intercalador con la profundidad de intercalación descendente del cable [8 | 16 | 32 | 64 | 128] comando de configuración de la interfaz de cable

Nota: Se especifica el valor para I (número de pulsaciones) y se aplica automáticamente un valor fijo correspondiente para J (incremento) como se ve en la tabla. Además, para el modo EuroDOCSIS (Anexo A), los parámetros del entrelazador se fijan en I = 12 y J = 17. El valor predeterminado para I es 32, que da un valor predeterminado para J de 4.

Tiempo de viaje de ida y vuelta

El segundo factor que contribuye a mapear el tiempo de avance que puede variar es el tiempo de ida y vuelta eléctrica entre el CMTS y los cablemódems. La distancia física entre el CMTS y los cablemódems y la demora de procesamiento inherente a los cablemódems influyen en este valor.

La especificación DOCSIS exige que el tiempo máximo permitido de propagación unidireccional entre el CMTS y el cable módem más lejano del sistema no supere los 800 microsegundos. Esto implica un tiempo de ida y vuelta de aproximadamente 1600 microsegundos, sin incluir el retraso del procesamiento del cablemódem.

La velocidad de la luz en un vacío es de aproximadamente 186.000 millas por segundo (300.000 kilómetros por segundo) y la velocidad de propagación de la fibra se suele citar como 0,67. Por lo tanto, la distancia máxima permitida de una dirección entre un CMTS y un cablemódem es aproximadamente:

	Distance = Velocity * Time

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

       		 = 100 miles or 161 kilometers.

De acuerdo con la especificación DOCSIS, la demora de procesamiento del cablemódem no debe exceder de 200 microsegundos más cualquier demora de entrelazado ascendente. Sin embargo, en casos excepcionales, algunas marcas antiguas de cable módem pueden tardar hasta 300 microsegundos en procesar un mensaje MAP. Los nuevos tipos de cablemódems con CPU más potentes pueden tardar hasta 100 microsegundos en procesar un mensaje MAP.

Suponga que los cablemódems cumplen, en promedio, con la especificación DOCSIS. Por lo tanto, el tiempo máximo de ida y vuelta debe ser 1600 + 200 = 1800 microsegundos.

La mayoría de los sistemas de cable son mucho más cortos que 100 millas. Por lo tanto, no es óptimo que un CMTS siempre asuma que el tiempo de ida y vuelta eléctrica entre el CMTS y el cable módem más lejano es el valor máximo de 1800 microsegundos.

Para una estimación aproximada del mayor tiempo de ida y vuelta eléctrico esperado, añada la distancia de fibra entre el CMTS y el cablemodem y multiplique por 16 microsegundos por milla (10 microsegundos por km). A continuación, sume la distancia de cualquier coaxial y multiplique ese valor en 12,4 microsegundos por milla (7,6 microsegundos por km). A continuación, agregue la demora de procesamiento de 200 microsegundos.

Por ejemplo, un segmento HFC con un total de 20 millas de fibra y una milla de coaxial entre el CMTS y el cable módem más lejano podría esperar una demora de ida y vuelta eléctrica 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 cifra no tiene en cuenta los retrasos adicionales debido a las características del canal ascendente y descendente y a las variaciones en los tiempos de procesamiento del módem. Por lo tanto, este valor no es apropiado para usar cuando calcule el tiempo de avance de MAP.

Una manera más precisa de determinar el tiempo de ida y vuelta en un sistema es observar el "desplazamiento de tiempo" para los cablemódems como se ve en la salida del comando show cable modem.Como parte del proceso de medición que los cablemódems utilizan para mantener la comunicación con el CMTS, el CMTS calcula el tiempo de ida y vuelta para cada cablemódem. Este tiempo de viaje de ida y vuelta aparece como el "desplazamiento de tiempo" en el resultado del comando show cable modem en unidades de 1/10.24MHz = 97.7 nanosegundos llamados unidades de desplazamiento de temporización o de desplazamiento de rango. Para convertir el desplazamiento de tiempo de un módem a microsegundos, multiplique el valor por 25/256 o divida el valor aproximadamente por 10.

A continuación se muestra un ejemplo en el que las compensaciones de temporización de varios módems en la salida del comando show cable modem se convierten en un valor de microsegundo:

Nota: El valor de microsegundos aparece en cursiva.

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)

En este caso, el módem más alejado de forma electrónica es el último módem con un desplazamiento de tiempo de 6030. Esto equivale a un tiempo de ida y vuelta de 6030 * 25/256 = 589 microsegundos.

Avance de MAP estático

En un sistema en el que se sabe que la longitud de la red HFC es significativamente menor a 100 millas, se puede configurar el CMTS para que utilice un tiempo máximo de ida y vuelta que sea inferior a los 1800 microsegundos estándar cuando se calcula el tiempo de avance del MAP.

Para obligar al CMTS a utilizar un valor personalizado para el tiempo de ida y vuelta en el cálculo avanzado de MAP, ejecute el comando de interfaz de cable cable map-advance static max-round-trip-time.

El rango para el tiempo máximo de ida y vuelta es de 100 a 2000 microsegundos. Si no se especifica ningún valor para max-round-trip-time, se aplica el valor predeterminado de 1800 microsegundos.

Nota: Puede reemplazar la palabra clave static por la palabra clave dynamic. Consulte la siguiente sección.

Asegúrese de que el tiempo de ida y vuelta especificado sea realmente mayor que el tiempo de ida y vuelta del CMTS al cablemódem más grande en el canal descendente. Si un cablemódem tiene un tiempo de viaje de ida y vuelta mayor que el especificado en max-round-trip-time, al módem le resulta difícil permanecer en línea. Esto se debe a que dicho módem no tiene tiempo suficiente para responder a un mensaje MAP y, por lo tanto, no puede comunicarse con el CMTS.

Si el desplazamiento de tiempo de un cablemódem, convertido en microsegundos, excede el tiempo máximo de ida y vuelta especificado, el módem se marca con el indicador de desplazamiento de tiempo incorrecto. Este indicador de desplazamiento aparece como un signo de exclamación (!) junto al desplazamiento de la sincronización del cablemódem en el resultado del comando show cable modem. Esta situación puede ocurrir si el parámetro max-round-trip-time está configurado demasiado bajo o si el cablemódem sufre de un problema donde su desplazamiento de temporización es inestable y aumenta constantemente con el tiempo.

Aquí tiene un ejemplo:

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)

En este ejemplo, se especifica el comando cable map-advance static 500. Sin embargo, uno de los cablemódems conectados a la interfaz de cable tiene un desplazamiento de temporización de más de 500 microsegundos (equivalente a 500 * 256/25 = 5120 unidades de desplazamiento de temporización).

Tenga en cuenta que el desplazamiento de tiempo del último cable módem está marcado con el indicador de desplazamiento de tiempo incorrecto, un "!". Esto también se fija al valor máximo permitido de 5120 unidades, aunque el ajuste de tiempo real puede ser mucho mayor. Este cable módem puede desconectarse y sufrir un rendimiento deficiente.

El indicador de desplazamiento de temporización incorrecta permanece configurado para el cablemódem incluso si el desplazamiento de la sincronización cae por debajo del tiempo de viaje de ida y vuelta máximo. La única manera de borrar el indicador es quitar el módem temporalmente de la lista show cable modem. Para esto, puede utilizar el comando clear cable modem mac-address delete. Alternativamente, puede restablecer la interfaz de cable o el puerto ascendente.

Para observar el funcionamiento del algoritmo de avance del mapa estático por flujo ascendente, ejecute el comando show controller cable interface-number upstream upstream-number. Aquí tiene un ejemplo:

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

El campo Map Advance (Static) muestra un tiempo de avance del mapa de 3480 microsegundos. Si cambia las características del entrelazador descendente o el parámetro max-round-trip-time, el cambio se refleja en el valor de avance del mapa estático.

Avance de MAP dinámico

El uso del cálculo de avance de MAP estático para optimizar los tiempos de avance de MAP requiere que el operador CMTS determine manualmente el mayor tiempo de viaje de ida y vuelta en un segmento de cable. Si cambian las características de los canales descendentes o ascendentes, o si cambian las condiciones de las plantas, el tiempo máximo de ida y vuelta puede cambiar significativamente. Puede ser difícil actualizar continuamente la configuración para adaptarse al cambio en las condiciones del sistema.

El algoritmo de avance de MAP dinámico resuelve este problema. El algoritmo de avance de MAP dinámico escanea periódicamente la lista de show cable modem para buscar el módem con el mayor desplazamiento de la temporización de medición inicial, y luego usa automáticamente ese valor para calcular el tiempo de avance de MAP. Por lo tanto, el CMTS siempre utiliza el menor tiempo de avance posible del mapa.

El desplazamiento de la temporización de medición inicial para un cablemódem es el desplazamiento de la sincronización que el módem informa en el punto en el que el módem se conecta. En la mayoría de los casos, esto se acerca al desplazamiento de temporización en marcha, como se ve en la salida del comando show cable modem. Sin embargo, algunos tipos de cablemódems tienen un problema en el que el desplazamiento de temporización se incrementa con el tiempo a valores muy grandes. Esto puede sesgar el cálculo del tiempo de avance del mapa. Por lo tanto, sólo se utiliza el desplazamiento de temporización de medición inicial, que se actualiza sólo si un módem se conecta. Para ver el desplazamiento de temporización de medición inicial y el desplazamiento de temporización continuo para un cablemódem, ejecute el comando show cable modem verbose. Aquí tiene un ejemplo:

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

En este ejemplo, el desplazamiento de tiempo en curso (2566) es ligeramente superior al desplazamiento de temporización de medición inicial (2560). Estos valores pueden variar ligeramente. Sin embargo, si los valores difieren en más de unos cientos de unidades, puede haber un problema con el control de desplazamiento de la sincronización del cable módem.

Para activar el cálculo de avance del mapa dinámico, ejecute el comando de la interfaz de cable cable map-advance dynamic security-factor max-round-trip-time.

El parámetro del factor de seguridad varía entre 100 y 2000 microsegundos. Este parámetro se agrega al tiempo de avance del MAP para proporcionar una pequeña salvaguardia para tener en cuenta cualquier retraso adicional no anticipado en la propagación de la señal. El valor predeterminado es 1000 microsegundos. Sin embargo, para sistemas de cable estables que no experimenten cambios significativos en la planta de cable o en las características de los canales ascendente o descendente, utilice un valor inferior como 500 microsegundos.

El parámetro max-round-trip-time varía de 100 a 2000 microsegundos. Este parámetro se utiliza como límite superior para las compensaciones de tiempo de los cablemódems conectados al segmento de cable. El valor predeterminado es 1800 microsegundos. Si el desplazamiento de tiempo de un cablemódem, convertido en microsegundos, excede el tiempo máximo de ida y vuelta especificado, aparece marcado con el indicador de desplazamiento de tiempo incorrecto.

Establezca el parámetro max-round-trip time en un valor no predeterminado cuando sepa que la longitud del sistema de cable es significativamente menor a 100 millas, y si sabe cuál debe ser el desplazamiento de tiempo normal máximo para los cablemódems conectados al segmento.

Observe el funcionamiento del algoritmo de avance de mapa dinámico por flujo ascendente con el comando show controller cable interface-number upstream upstream-number. Aquí tiene un ejemplo:

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

El valor Tx Timing Offset muestra el mayor desplazamiento de temporización para todos los cablemódems conectados a la corriente ascendente en unidades de desplazamiento de temporización. Utilice este valor para calcular el tiempo de avance del MAP. El campo Map Advance (Dynamic) muestra el tiempo de avance del mapa resultante. Este valor puede variar si cambia el desplazamiento de temporización Tx, si se modifica el valor de seguridad o si se modifican las características del entrelazador descendente.

El algoritmo de avance de MAP dinámico depende de si los cablemódems informan su desplazamiento de temporización de medición inicial al CMTS correctamente. Desafortunadamente, algunas marcas y modelos de cablemódems informan de los desplazamientos de temporización de medición iniciales como valores significativamente menores que el valor verdadero. Puede observar esto cuando los módems muestran compensaciones de temporización cercanas a cero o incluso valores negativos.

Mensajes de error similares a %UBR7200-4-BADTXOFFSET: El desplazamiento de temporización incorrecto -2 detectado para el cablemódem 00ff.0bad.caf3 puede aparecer en tales cablemódems. Estos tipos de cablemódems no informan sus compensaciones de temporización de una manera compatible con DOCSIS, el algoritmo de avance de mapa dinámico no puede calcular correctamente un tiempo de avance de mapa que se garantiza que cada cablemódem tenga tiempo para recibir y responder a los mensajes MAP.

Si tales cablemódems están presentes en un segmento de cable, inhabilite el algoritmo de avance de MAP dinámico y vuelva al algoritmo de avance de MAP estático. Consulte ¿Por qué algunos cablemódems muestran un desplazamiento temporal negativo? para más información.

Información Relacionada

• Soporte Técnico y Documentación - Cisco Systems

Historial de revisiones