CCNA 3 Versión 7: Módulo 9 – Conceptos de QoS

Última actualización: enero 30, 2022

9.0. Introducción

9.0.1. ¿Por qué debería tomar este módulo?

¡Bienvenido a los Conceptos de QoS!

Imagina conducir en una carretera muy congestionada y tienes prisa por conocer a un amigo para cenar. Oyes la sirena y ves las luces de una ambulancia detrás de ti. Tienes que salir de la carretera para dejar pasar a la ambulancia. La ambulancia que llega al hospital tiene prioridad sobre que usted llegue al restaurante a tiempo.

Al igual que la ambulancia que toma prioridad en el tráfico en la carretera, algunas formas de tráfico de red necesitan prioridad sobre otras. ¿Por qué? ¡Empieza con este módulo para averiguarlo!

9.0.2. ¿Qué aprenderé en este módulo?

Título del módulo: Conceptos de QoS

Objetivos del módulo: Explique la forma en que los dispositivos de red implementan QoS.

Título del tema	Objetivo del tema
Calidad de las transmisiones de red	Explique cómo las características de transmisión de red afectan la calidad.
Características de tráfico	Describa los requisitos de red mínimos para voz, video y tráfico de datos.
Algoritmo de formación de colas	Describa los algoritmos de formación de colas utilizados por los dispositivos de red.
Modelos de QoS	Describa los diferentes modelos de QoS.
Técnicas de implementación de QoS	Explique cómo QoS utiliza mecanismos para garantizar la calidad de transmisión.

9.1. Calidad de las transmisiones de red

9.1.1. Tutorial en video: El propósito de la QoS

Haga clic en Reproducir para ver una breve explicación del propósito de la QoS.

9.1.2. Priorización del tráfico

En el video anterior, aprendiste sobre el propósito de Calidad de Servicio (QoS). QoS es un requisito cada vez mayor de las redes hoy en día. Las nuevas aplicaciones, como las transmisiones de voz y video en vivo, crean mayores expectativas de entrega de calidad entre los usuarios.

La congestión ocurre cuando se agregan varias líneas de comunicación en un solo dispositivo, como un enrutador, y luego gran parte de esos datos se colocan en unas pocas interfaces de salida o en una interfaz más lenta. La congestión también puede producirse cuando los paquetes de datos grandes impiden que paquetes más pequeños se transmitan a tiempo.

Cuando el volumen de tráfico es mayor que el que se puede transportar a través de la red, los dispositivos ponen en cola (retienen) los paquetes en la memoria hasta que los recursos estén disponibles para transmitirlos. Los paquetes en cola causan retrasos, dado que los nuevos paquetes no se pueden transmitir hasta que no se hayan procesado los anteriores. Si sigue aumentando la cantidad de paquetes que se pondrán en cola, la memoria del dispositivo se llenará y los paquetes se descartarán. Una técnica de la QoS que puede ayudarlo con este problema es la clasificación de datos en varias colas, como se muestra en la figura.

Nota: Un dispositivo implementa QoS solo cuando está experimentando algún tipo de congestión.

Uso de las comunicaciones de colas a prioridades

9.1.3. Ancho de banda, congestión, retraso y fluctuación

El ancho de banda de la red es la medida de la cantidad de bits que se pueden transmitir en un segundo, es decir, bits por segundo (bps). Por ejemplo, un dispositivo de red puede tener la capacidad de funcionar a 10 gigabits por segundo (Gbps).

La congestión de la red produce demoras. Una interfaz experimenta congestión cuando tiene más tráfico del que puede gestionar. Los puntos de congestión de la red son candidatos ideales para los mecanismos de QoS. La figura muestra tres ejemplos de puntos de congestión típicos.

Ejemplos de puntos de congestión

La demora o la latencia se refiere al tiempo que demora un paquete en viajar de origen a destino. Dos tipos de demoras son las fijas y las variables. Una demora fija es la cantidad determinada de tiempo que lleva un proceso específico, como el tiempo que lleva colocar un bit en los medios de transmisión. Un retraso variable lleva una cantidad de tiempo no especificada y se ve afectado por factores como la cantidad de tráfico que se procesa.

Las fuentes de retraso se resumen en la tabla.

Sources of Delay

Demora	Descripción
Demora de código	La cantidad fija de tiempo que lleva comprimir datos en la fuente antes transmitiendo al primer dispositivo de interconexión, generalmente un conmutador.
Demora de paquetización	El tiempo fijo que lleva encapsular un paquete con todo lo necesario información del encabezado
Demora de asignación de cola	La cantidad variable de tiempo que una trama o paquete espera para transmitirse el enlace.
Demora de serialización	La cantidad fija de tiempo que lleva transmitir una trama al cable.
Demora de propagación	La cantidad variable de tiempo que tarda el fotograma en viajar entre origen y destino.
Demora de eliminación de fluctuación	La cantidad fija de tiempo que lleva almacenar un flujo de paquetes en el búfer y luego enviarlos a intervalos espaciados uniformemente.

La fluctuación es la variación en la demora de los paquetes recibidos. En el extremo emisor, los paquetes se envían de manera permanente con los paquetes de espacio uniforme por separado. Debido a la congestión de la red, las colas inadecuadas o los errores de configuración, el retraso entre cada paquete puede variar en lugar de permanecer constante. Es necesario controlar y minimizar tanto la demora como las fluctuaciones para admitir el tráfico en tiempo real e interactivo.

9.1.4. Pérdida de paquetes

Sin ningún mecanismo de QoS, los paquetes se procesan en el orden en que se reciben. Cuando ocurre una congestión, los dispositivos de red como enrutadores y conmutadores pueden descartar paquetes. Esto significa que los paquetes urgentes, como el video y la voz en tiempo real, se descartarán con la misma frecuencia que los datos que no son urgentes, como el correo electrónico y la navegación web.

Cuando un enrutador recibe una transmisión de audio digital del Protocolo en tiempo real (RTP) para Voz sobre IP (VoIP), debe compensar el jitter que se encuentra. El mecanismo que maneja esta función es el búfer de retardo de reproducción. El búfer de retardo de reproducción debe almacenar estos paquetes y luego reproducirlos en un flujo constante, como se muestra en la figura. Los paquetes digitales se convierten de nuevo en una transmisión de audio analógica.

El búfer de retardo de reproducción compensa la fluctuación

Si las fluctuaciones son tan grandes que hacen que los paquetes se reciban fuera del alcance de este búfer, se descartan los paquetes que están fuera del rango, y se escuchan interrupciones en el audio, como se muestra en la Figura 2.

Paquete descartado debido a fluctuación excesiva

Para pérdidas tan pequeñas como un paquete, el procesador de señal digital (DSP) interpola lo que cree que debería ser el audio y ningún problema es audible para el usuario. Sin embargo, cuando el jitter excede lo que el DSP puede hacer para compensar los paquetes faltantes, se escuchan problemas de audio.

La pérdida de paquetes es una causa muy común de problemas de calidad de voz en una red IP. En una red diseñada adecuadamente, la pérdida de paquetes debe ser cercana a cero. The voice codecs used by the DSP can tolerate some degree of packet loss without a dramatic effect on voice quality. Los ingenieros de red utilizan mecanismos de QoS para clasificar los paquetes de voz para la pérdida de paquetes cero. El ancho de banda está garantizado para las llamadas de voz al dar prioridad al tráfico de voz sobre el tráfico que no es sensible a los retrasos.

9.2. Características de tráfico

9.2.1. Tutorial en video: Características del tráfico

Haga clic en Reproducir para ver una descripción general de cómo se puede usar la QoS para tratar los paquetes de distintas maneras según las características del tráfico.

9.2.2. Tendencias en el tráfico de red

En un tema anterior, aprendió acerca de la calidad de la transmisión de red. En este tema aprenderá acerca de las características del tráfico (voz, vídeo y datos). A principios de la década del 2000, los tipos de tráfico IP predominantes eran voz y datos. El tráfico de voz tiene una necesidad de ancho de banda predecible y tiempos de llegada de paquete conocidos. El tráfico de datos no es en tiempo real, y tiene una necesidad impredecible de ancho de banda. El tráfico de datos puede tener estallidos temporalmente, como cuando se descarga un archivo grande. Este estallido puede consumir todo el ancho de banda de un enlace.

Más recientemente, el tráfico de video se ha vuelto cada vez más importante para las comunicaciones y las operaciones empresariales. Según el Índice de redes visuales de Cisco (VNI), el tráfico de video representó el 70% de todo el tráfico en 2017. Para 2022, el video representará el 82% de todo el tráfico. Además, el tráfico de vídeo móvil alcanzará 60,9 exabytes por mes para 2022, en comparación con 6,8 exabytes por mes en 2017.El tipo de demandas que el tráfico de voz, vídeo y datos coloca en la red son muy diferentes.

9.2.3. Voz

El tráfico de voz es predecible y uniforme, como se muestra en la figura. Sin embargo, la voz es muy sensible a los retrasos y a los paquetes descartados. No tiene sentido retransmitir la voz si se pierden paquetes; por lo tanto, los paquetes de voz deben recibir una prioridad más alta que otros tipos de tráfico. Por ejemplo, los productos de Cisco utilizan el rango de puerto de 16384 a 32767 de RTP para priorizar el tráfico de voz. La voz puede tolerar una cierta cantidad de latencia, fluctuación y pérdida sin efectos aparentes. La latencia no debe superar los 150 milisegundos (ms). Las fluctuaciones no deben superar los 30 ms y la pérdida de paquetes de voz no debe ser superior al 1%. El tráfico de voz requiere al menos 30 Kbps de ancho de banda. La tabla ofrece un resumen de las características y requisitos del tráfico de voz.

Características del tráfico de voz	Requerimientos de sentido único
Fluida Favorable Sensible a las caídas Sensible al retraso Prioridad UDP	Latencia ≤ 150 ms Fluctuación ≤ 30 ms Pérdida ≤ 1% de ancho de banda (30 – 128 Kbps)

9.2.4. Video

Sin QoS y una cantidad significativa de capacidad de ancho de banda adicional, la calidad de video normalmente determinada. La imagen se muestra borrosa, dentada o en la cámara lenta. El audio de la fuente puede perder la sincronización con el video.

El tráfico de video tiende a ser imprevisible, inconsistente y a transmitirse por ráfagas, en comparación con el tráfico de voz. En comparación con la transmisión de voz, el video es menos resistente a pérdidas y tiene un mayor volumen de datos por paquete. Observe en la figura cómo los paquetes de voz llegan cada 20 ms y son 200 bytes predecibles cada uno.

Por el contrario, la cantidad y el tamaño de los paquetes de video varían cada 33 ms según el contenido del video, como se muestra en la figura. Por ejemplo, si la transmisión de video consiste en contenido que no cambia mucho de cuadro a cuadro, entonces los paquetes de video serán pequeños, y se requieren menos para mantener una experiencia de usuario aceptable. Sin embargo, si el vapor de video consiste en contenido que está cambiando rápidamente, como una secuencia de acción en una película, entonces los paquetes de video serán más grandes. Se requieren más por el intervalo de tiempo de 33 ms para mantener una experiencia de usuario aceptable.

Los puertos UDP, como el 554, se utilizan para el Protocolo de transmisión en tiempo real (RSTP) y se les debe dar prioridad sobre otro tráfico de red menos sensible al retraso. Similar a la voz, el video puede tolerar una cierta cantidad de latencia, fluctuación y pérdida sin efectos notables. La latencia no debe ser superior a 400 milisegundos (ms). Las fluctuaciones no deben ser de más de 50 ms, y la pérdida de paquetes de video no debe ser superior al 1%. El tráfico de video requiere al menos 384 Kbps de ancho de banda. La tabla ofrece un resumen de las características y requisitos del tráfico de vídeo.

Características del tráfico de video	Requerimientos de sentido único
Con ráfagas Voraz Sensible a las caídas Sensible al retraso Prioridad UDP	Latencia ≤ 200-400 ms Jitter ≤ 30-50 ms Pérdida ≤ 0,1-1% Ancho de banda (384 Kbps -> 20 Mbps

9.2.5. Datos

La mayoría de las aplicaciones utilizan TCP o UDP. A diferencia de UDP, TCP realiza la recuperación de errores. Aplicaciones de datos que no tienen tolerancia a la pérdida de datos, como el correo electrónico y las páginas web, el uso de TCP para asegurarse de que, si los paquetes se pierden en tránsito, se envíen nuevamente. El tráfico de datos puede ser fluido o puede tener estallidos. El tráfico de control de red generalmente es elegante y predecible. Cuando hay un cambio de topología, el tráfico de control de red puede tener estallidos durante unos segundos. Pero la capacidad de las redes actuales permite administrar fácilmente el aumento del tráfico de control de red mientras la red converge.

Sin embargo, algunas aplicaciones TCP pueden consumir una gran parte de la capacidad de la red. El FTP ocupará tanto ancho de banda como pueda obtener cuando usted descargue un archivo grande, como una película o un juego. La tabla resume las características del tráfico de datos.

Características del tráfico de datos
Fluido o con ráfagas Benigno/voraz Insensible a las caídas Insensible al retraso Retransmisiones de TCP

Aunque el tráfico de datos es relativamente insensible a las caídas y demoras en comparación con la voz y el video, un administrador de red igualmente debe tener en cuenta la calidad de la experiencia del usuario, a veces denominada «calidad de la experiencia» o QoE. Hay dos factores principales que un administrador de red debe preguntar sobre el flujo del tráfico de datos:

• ¿Los datos provienen de una aplicación interactiva?
• ¿Los datos son críticos?

La tabla compara estos dos factores.

Factors to Consider for Data Delay

Factor	De uso crítico	No misión crítica
Interactivo	Priorice la demora más baja de todo el tráfico de datos y luche por un 1 a 2 segundos de tiempo de respuesta.	Las aplicaciones podrían beneficiarse con una demora más baja.
No interactivo	El retraso puede variar mucho, siempre que el ancho de banda mínimo necesario sea suministrado	Obtiene cualquier ancho de banda restante después de todos los datos de voz, video y otros se satisfacen las necesidades de la aplicación.

9.3. Algoritmo de formación de colas

9.3.1. Tutorial en video: Algoritmos de la QoS

Haga clic en Reproducir para obtener una descripción general de los diferentes tipos de algoritmos de colas QoS.

9.3.2. Encolamiento: Descripción general

El tema anterior cubría las características del tráfico. En este tema se explicarán los algoritmos de cola utilizados para implementar QoS. La política de la QoS implementada por el administrador de la red se activa cuando se produce una congestión en el enlace. La puesta en cola es una herramienta administrativa para la congestión que puede almacenar en búfer, priorizar, y, si corresponde, reordenar los paquetes antes de que estos se transmitan al destino.

Se encuentran disponibles varios algoritmos de puesta en cola. A los fines de este curso, nos concentraremos en lo siguiente:

• Primero en entrar, primero en salir (FIFO)
• Mecanismo de cola equitativo ponderado (WFQ)
• Mecanismo de cola de espera equitativo y ponderado basado en clases (CBWFQ)
• Mecanismo de cola de baja latencia (LLQ)

9.3.3. Primero en la entrada

En su forma más simple, las colas Primero en entrar, primero en salir (FIFO), también conocidas como colas por orden de llegada, almacenamientos intermedios y paquetes de reenvío en el orden de llegada.

FIFO no tiene concepto de prioridad ni clases de tráfico, por lo que no toma decisiones sobre la prioridad de los paquetes. Hay una sola cola, y todos los paquetes se tratan por igual. Los paquetes se envían a la interfaz en el orden en que llegaron, como se muestra en la figura. Aunque parte del tráfico puede ser más importante o sensible al tiempo según la clasificación de prioridad, tenga en cuenta que el tráfico se envía en el orden en que se recibe.

Cuando se utiliza FIFO, el tráfico importante o sensible al tiempo se puede descartar cuando hay congestión en la interfaz del enrutador o conmutador. Cuando no se configuran otras estrategias de colas, todas las interfaces, excepto las interfaces seriales en E1 (2.048 Mbps) e inferiores, usan FIFO de manera predeterminada. (Las interfaces seriales en E1 y debajo utilizan WFQ por defecto).

FIFO, que es el método más rápido de espera, es eficaz para enlaces grandes que tienen poco retraso y congestión mínima. Si su enlace tiene una congestión muy pequeña, la cola FIFO puede ser la única cola que necesite usar.

Ejemplo de cola FIFO

9.3.4. Colas justas ponderadas (WFQ)

Weighted Fair Queuing (WFQ) es un método de programación automatizado que proporciona una asignación justa de ancho de banda a todo el tráfico de red. WFQ no permite configurar las opciones de clasificación. WQF aplica prioridades o ponderaciones para identificar el tráfico y clasificarlo en conversaciones o flujos, como se muestra en la figura.

Ejemplo de cola de espera equitativa y ponderada

El WFQ luego determina la cantidad de ancho de banda que se le permite a cada flujo en relación con otros flujos. El algoritmo basado en el flujo utilizado por la WFQ planifica simultáneamente el tráfico interactivo al frente de una cola para reducir el tiempo de respuesta. Luego, comparte equitativamente el ancho de banda restante entre flujos de ancho de banda altos. El WFQ le permite dar prioridad al tráfico de bajo volumen e interactivo, como las sesiones Telnet y de voz, sobre el tráfico de gran volumen, como las sesiones de FTP. Cuando se producen simultáneamente los flujos de las transferencias de archivo múltiples, se asigna un ancho de banda similar a las transferencias.

La WFQ clasifica el tráfico en distintos flujos basados en el encabezado de manejo de paquetes, lo que incluye características como las direcciones IP de origen y de destino, las direcciones MAC, los números de puerto, el protocolo y el valor del tipo de servicio (ToS). El valor ToS en el encabezado IP puede utilizarse para clasificar el tráfico.

Los flujos de tráfico de bajo ancho de banda, que comprenden la mayoría del tráfico, reciben un servicio preferencial que permite que todas sus cargas ofrecidas se envíen de manera oportuna. Los flujos de tráfico de alto volumen comparten la capacidad restante proporcionalmente entre ellos.

Limitaciones

La WFQ no se utiliza con los túneles y el cifrado porque estas funciones modifican la información de contenido de paquete requerida por la WFQ para la clasificación.

Aunque WFQ se adapta automáticamente a las condiciones cambiantes del tráfico de red, no ofrece el grado de control preciso sobre la asignación de ancho de banda que ofrece CBWFQ.

9.3.5. Mecanismo de cola de espera equitativo y ponderado basado en clases (CBWFQ)

La ponderación equitativa ponderada basada en clases (CBWFQ) amplía la funcionalidad estándar WFQ para proporcionar soporte para las clases de tráfico definidas por el usuario. Con CBWFQ, usted define clases de tráfico basadas en criterios de coincidencia que incluyen protocolos, listas de control de acceso (ACL) e interfaces de entrada. Los paquetes que cumplen los criterios de coincidencia para una clase constituyen el tráfico para esa clase. Se reserva una cola FIFO para cada clase y el tráfico de cada clase se dirige a la cola de dicha clase, como se muestra en la figura.

Cuando se ha definido una clase según sus criterios de coincidencia, puede asignarle características. Para cuantificar una clase, le asigna el ancho de banda, el peso, y el límite de paquete máximo. El ancho de banda asignado a una clase es el ancho de banda garantizado que se entrega a la clase durante la congestión.

Para caracterizar una clase, también especifica el límite de cola para esa clase, que es la cantidad máxima de paquetes que se pueden acumular en la cola de esa clase. Los paquetes que pertenecen a una clase están sujetos al ancho de banda y a los límites de cola que caracterizan a la clase.

Ejemplo de CBWFQ

Una vez que una cola haya alcanzado su límite de cola configurado, el agregado de más paquetes a la clase hace que surtan efecto el descarte de cola o el descarte de paquetes, según cómo esté configurada la política de clase. El descarte de extremo final implica que el router descarte todos los paquetes que lleguen en el extremo final de una cola que ya agotó por completo sus recursos de almacenamiento de paquetes. Esta es la respuesta de espera predeterminada para la congestión. El descarte de extremo final trata a todo el tráfico de la misma manera y no diferencia entre clases de servicios.

9.3.6. Mecanismo de cola de baja latencia (LLQ)

La función de cola de baja latencia (LLQ) trae cola de prioridad estricta (PQ) a CBWFQ. La estricta PQ permite que los paquetes sensibles al retraso, como la voz, se envíen antes que los paquetes en otras colas. LLQ proporciona una puesta en cola de prioridad estricta para CBWFQ, lo que reduce las fluctuaciones en las conversaciones de voz, como se muestra en la figura.

Sin la LLQ, CBWFQ proporciona el WFQ según las clases definidas sin una cola de prioridad estricta disponible para el tráfico en tiempo real. El peso para un paquete que pertenece a una clase específica se deriva del ancho de banda que le asignó a la clase al configurarla. Por lo tanto, el ancho de banda asignado a los paquetes de una clase determina el orden en que se envían los paquetes. Se realiza el servicio de todos los paquetes en base suficiente al peso; ninguna clase de paquetes puede otorgar la prioridad estricta. Este esquema presenta problemas para el tráfico de voz, que en gran medida no admite retrasos, especialmente variaciones en el retraso. Para el tráfico de voz, las variaciones en la demora introducen irregularidades en la transmisión que se manifiestan como fluctuaciones en la conversación escuchada.

LLQ permite que los paquetes sensibles al retraso, como la voz, se envíen primero (antes que los paquetes en otras colas), dando a los paquetes sensibles al retraso un tratamiento preferencial sobre otro tráfico. Aunque es posible clasificar varios tipos de tráfico en tiempo real a la cola de prioridad estricta, Cisco recomienda que solo el tráfico de voz se dirija a la cola de prioridad.

Ejemplo de LLQ

9.4. Modelos de QoS

9.4.1. Tutorial en video: Modelos de la QoS

Haga clic en Reproducir para ver una breve explicación del propósito de la QoS.

9.4.2. Selección de un modelo adecuado de política de la QoS

¿Cómo se puede implementar QoS en una red? Hay tres modelos para implementar QoS:

• Modelo de mejor esfuerzo
• Servicios integrados (IntServ)
• Servicios diferenciados (DiffServ)

La tabla resume estos tres modelos. QoS se implementa en una red utilizando IntServ o DiffServ. Si bien IntServ ofrece la mayor garantía de QoS, requiere muchos recursos y, por lo tanto, no es fácilmente escalable. En cambio, DiffServ consume menos recursos y es más escalable. En algunas ocasiones, los dos se emplean juntos para la implementación de la QoS en redes.

Models for Implementing QoS

Modelo	Descripción
Modelo de mejor esfuerzo	– Esto no es realmente una implementación ya que QoS no está configurado explícitamente. – Use esto cuando no se requiera QoS.
Servicios integrados (IntServ)	– IntServ proporciona paquetes QoS a IP muy altos con entrega garantizada. – Definir un proceso de señalización para las aplicaciones señaladas a la red que requirió QoS especial por un período y que debe reservarse el ancho de banda. – IntServ puede limitar severamente la escalabilidad de una red.
Servicios diferenciados (DiffServ)	– DiffServ proporciona alta escalabilidad y flexibilidad en la implementación de QoS. – Los dispositivos de red reconocen las clases de tráfico y proporcionan diferentes niveles de QoS a diferentes clases de tráfico.

9.4.3. Servicio mínimo

El diseño básico de Internet es la entrega de paquetes de mejor esfuerzo y no ofrece garantías. Este enfoque sigue siendo predominante en Internet hoy y sigue siendo apropiado para la mayoría de los propósitos. El modelo de mejor esfuerzo trata todos los paquetes de red de la misma manera, por lo que un mensaje de voz de emergencia se trata de la misma manera que se trata una fotografía digital adjunta a un correo electrónico. Sin QoS, la red no puede conocer la diferencia entre paquetes y, como resultado, no puede tratar a los paquetes de manera preferencial.

El modelo de mejor esfuerzo es un concepto similar al de enviar una carta por correo postal estándar. Su carta se trata exactamente de la misma manera que las otras cartas. Con el modelo de mejor esfuerzo, la carta podría no llegar y, a menos que haya llegado a un acuerdo de notificación con el destinatario de la carta, tal vez nunca se entere de que la carta no llegó.

La tabla enumera los beneficios y las desventajas del modelo de mejor esfuerzo.

Benefits and Drawbacks of Best-Effort Model

Beneficios	Desventajas
Este modelo es el más escalable.	No hay garantías de entrega.
La escalabilidad solo está limitada por el ancho de banda disponible, en cuyo caso todos los el tráfico se ve igualmente afectado.	Los paquetes llegarán siempre que puedan y en el orden que sea posible, si llegar a todos.
No se requieren mecanismos de QoS especiales.	Ningún paquete tiene trato preferencial.
Es el modelo más fácil y rápido de implementar.	Los datos críticos se tratan del mismo modo que el correo electrónico informal.

9.4.4. Servicios integrados

El modelo de arquitectura IntServ (RFC 1633, 2211 y 2212) se desarrolló en 1994 para satisfacer las necesidades de aplicaciones en tiempo real, como video remoto, conferencias multimedia, aplicaciones de visualización de datos y realidad virtual. IntServ es un modelo de servicios múltiples que puede acomodar muchos requisitos de QoS.

IntServ ofrece la QoS de extremo a extremo que necesita las aplicaciones en tiempo real. IntServ administra explícitamente los recursos de red para proporcionar QoS a flujos o flujos individuales, a veces denominados microflujos. Utiliza reserva de recursos y mecanismos de control de admisión como módulos de construcción para establecer y mantener QoS. Esto es similar a un concepto conocido como «QoS dura». Hard QoS garantiza las características de tráfico, como el ancho de banda, la demora y las velocidades de pérdida de paquetes, de extremo a extremo. Hard QoS asegura niveles de servicios predecibles y garantizados para las aplicaciones críticas.

La figura muestra una ilustración simple del modelo IntServ.

Ejemplo de IntServ simple

IntServ utiliza un enfoque orientado a la conexión heredado del diseño de una red de telefonía. Cada comunicación individual debe especificar explícitamente su descriptor de tráfico y los recursos solicitados a la red. El router perimetral realiza el control de admisión para garantizar que los recursos disponibles son suficientes en la red. El estándar de IntServ asume que los routers a lo largo de una ruta configuran y mantienen el estado de cada comunicación individual.

En el modelo de IntServ, la aplicación solicita a un tipo específico de servicio a la red antes de enviar datos. La aplicación informa a la red su perfil de tráfico y solicita a un tipo particular de servicio que puede abarcar requisitos de ancho de banda y retraso. IntServ utiliza el Protocolo de reserva de recursos (RSVP) para señalar las necesidades de la QoS del tráfico de una aplicación junto con los dispositivos en la ruta de extremo a extremo a través de la red. Si los dispositivos de red a lo largo de la ruta pueden reservar el ancho de banda necesario, la aplicación de origen puede comenzar a transmitir. Si reserva solicitada falla a lo largo de la ruta, la aplicación de origen no envía ningún dato.

El router perimetral realiza un control de admisión basado en información de la aplicación y en los recursos de red disponibles. La red cumple con los requisitos de la QoS de la aplicación siempre que el tráfico esté dentro de las especificaciones del perfil. La red cumple su compromiso al mantener el estado por flujo y llevar a cabo luego la clasificación de paquetes, de políticas, y espera inteligente basada en ese estado.

La tabla enumera los beneficios y las desventajas del modelo IntServ.

Benefits and Drawbacks of IntServ Model

Beneficios	Desventajas
– Control explícito de admisión de recursos de extremo a extremo – Control de admisión de políticas por solicitud – Señalización de números de puerto dinámicos	– Uso intensivo de recursos debido al requisito de arquitectura con estado para señalización continua. – Enfoque basado en el flujo no escalable a implementaciones grandes como el Internet.

9.4.5. Servicios diferenciados

El modelo de QoS de servicios diferenciados (DiffServ) especifica un mecanismo simple y escalable para clasificar y gestionar el tráfico de red. Por ejemplo, DiffServ puede proporcionar un servicio garantizado de baja latencia para el tráfico de red crítico, como voz o video, al tiempo que ofrece garantías de tráfico de mejor esfuerzo para servicios no críticos como el tráfico web o las transferencias de archivos.

El diseño de DiffServ supera las limitaciones de los modelos de mejor esfuerzo e IntServ. El modelo DiffServ se describe en RFC 2474, 2597, 2598, 3246, 4594. DiffServ puede proporcionar una Calidad de Servicio «casi garantizada» sin perder rentabilidad ni escalabilidad.

El modelo DiffServ es un concepto similar al de enviar un paquete mediante un servicio de entrega. Usted solicita (y paga) un nivel de servicio cuando envía un paquete. En la red de paquetes, se reconoce el nivel de servicio por el que usted pagó y se le brinda a su paquete servicio normal o preferencial, según lo que usted solicitó.

DiffServ no es una estrategia de la QoS de extremo a extremo porque no puede otorgar garantías de extremo a extremo. Sin embargo, el modelo DiffServ es un enfoque más escalable para implementar QoS. A diferencia de IntServ y QoS duro, en el que los hosts finales señalan sus necesidades de QoS a la red, DiffServ no utiliza señalización. En su lugar, DiffServ usa un enfoque de “soft QoS” (QoS suave). Funciona en el modelo que proporciona QoS, donde los elementos de red se configuran para mantener varias clases de tráfico cada uno con requisitos de la QoS diferentes.

La figura muestra una ilustración simple del modelo DiffServ.

Ejemplo simple de DiffServ

Mientras el host envía tráfico a un router, el router clasifica los flujos en agregados (clases) y proporciona la política QoS apropiada para las clases. DiffServ impone y aplica los mecanismos de la QoS en base a saltos, aplicando uniformemente el significado global a cada clase de tráfico para proporcionar flexibilidad y escalabilidad. Por ejemplo, DiffServ podría configurarse para agrupar todos los flujos de TCP como clase única y asignar el ancho de banda para dicha clase, en vez de para los flujos individuales, como lo haría IntServ. Además de clasificar el tráfico, DiffServ minimiza los requisitos de mantenimiento de señales y estados en cada nodo de red.

Específicamente, DiffServ divide el tráfico de red en clases según los requisitos de la empresa. Se puede asignar a un nivel diferente de servicio a cada una de las clases. A medida que los paquetes atraviesan una red, cada uno de los dispositivos de red identifica la clase de paquete y brinda servicios al paquete según esa clase. Con DiffServ, es posible elegir muchos niveles de servicio. Por ejemplo, al tráfico de voz desde teléfonos IP se le otorga generalmente un trato preferencial sobre el resto del tráfico de aplicaciones, al correo electrónico se le da generalmente el servicio de mejor esfuerzo, y al tráfico no empresarial se le puede asignar muy poco servicio o bloquearlo por completo.

La figura enumera los beneficios y las desventajas del modelo DiffServ.

Nota: Las redes modernas utilizan principalmente el modelo DiffServ. Sin embargo, debido a los volúmenes crecientes de tráfico sensible a demoras y fluctuaciones, en ocasiones IntServ y RSVP se implementan juntos.

Benefits and Drawbacks of DiffServ Model

Beneficios	Desventajas
– Gran escalabilidad – Proporciona distintos niveles de calidad	– Sin garantía absoluta de la calidad del servicio – Requiere un conjunto de mecanismos complejos para trabajar en conjunto en la red

9.5. Técnicas de implementación de QoS

9.5.1. Tutorial en video: Técnicas de implementación de la QoS

Haga clic en Reproducir para ver una descripción general de la clasificación, la marcación, los límites de confianza, la prevención de congestión, el modelado y la vigilancia.

9.5.2. Evitar la pérdida de paquetes

Ahora que ha aprendido acerca de las características del tráfico, los algoritmos de cola y los modelos de QoS, es hora de aprender acerca de las técnicas de implementación de QoS.

Comencemos con la pérdida de paquetes. La pérdida de paquetes es generalmente el resultado de la congestión en una interfaz. La mayoría de las aplicaciones que utilizan el TCP experimentan una disminución de velocidad debido a que el TCP se ajusta automáticamente a la congestión en la red. Los segmentos caídos del TCP hacen que las sesiones del TCP reduzcan su tamaño de ventana. Algunas aplicaciones no utilizan TCP y no pueden manejar las caídas (flujos frágiles).

Los enfoques siguientes pueden prevenir los descartes en las aplicaciones sensibles:

• Aumenta la capacidad de enlace para facilitar o evitar la congestión.
• Garantiza el suficiente ancho de banda y aumenta el espacio en búfer para acomodar las ráfagas de tráfico de flujos frágiles. WFQ, CBWFQ y LLQ pueden garantizar ancho de banda y proporcionar reenvío priorizado a aplicaciones sensibles a caídas.
• Los paquetes de baja prioridad de descartan antes de que se presente la congestión. Cisco IOS QoS proporciona mecanismos de colas, como la detección temprana aleatoria ponderada (WRED), que comienzan a descartar paquetes de menor prioridad antes de que ocurra la congestión.

9.5.3. Herramientas de la QoS

Hay tres categorías de herramientas de QoS, como se describe en la tabla:

• Herramientas de clasificación y marcación
• Herramientas para evitar la congestión
• Herramientas de administración de congestión

Tools for Implementing QoS

Herramientas de QoS	Descripción
Herramientas de clasificación y marcación	– Las sesiones, o flujos, se analizan para determinar qué clase de tráfico a los que pertenecen. – Cuando se determina la clase de tráfico, se marcan los paquetes.
Herramientas para evitar la congestión	– Las clases de tráfico son porciones asignadas de recursos de red, como definido por la directiva QoS. – La política de QoS también identifica cómo parte del tráfico puede ser selectivamente caído, retrasado o remarcado para evitar la congestión. – La herramienta principal de prevención de congestión es WRED y se utiliza para regular el tráfico de datos TCP de manera eficiente con el ancho de banda antes se producen caídas de cola causadas por desbordamientos de cola.
Herramientas de administración de congestión	– Cuando el tráfico excede los recursos de red disponibles, el tráfico se pone en cola esperar la disponibilidad de recursos. – Las herramientas comunes de administración de congestión basadas en Cisco IOS incluyen CBWFQ y AlgoritmosLLQ.

Consulte la figura para ayudar a comprender la secuencia de cómo se utilizan estas herramientas cuando QoS se aplica a los flujos de paquetes.

Secuencia de QoS

Como se muestra en la ilustración, se clasifican los paquetes de ingreso (cuadros grises) y se marca su encabezado IP respectivo (cuadros de color). Para evitar la congestión, luego se asignan recursos a los paquetes en base a las políticas definidas. Los paquetes son luego puestos en la cola y reenviados a la interfaz de egreso según la política definida de modelado y regulación de tráfico de la QoS.

Nota: La clasificación y la marcación se pueden aplicar en el ingreso o en el egreso, mientras que las otras acciones de la QoS, como la organización de la cola y el modelado, generalmente se realizan al egreso.

9.5.4. Clasificación y marcación

Antes de que a un paquete se le pueda aplicar una política de la QoS, el mismo tiene que ser clasificado. La clasificación y la marcación nos permiten identificar o “marcar” los tipos de paquetes. La clasificación determina la clase de tráfico al cual los paquetes o tramas pertenecen. Solo pueden aplicarse las políticas al tráfico después del marcado.

Cómo se clasifica un paquete depende de la implementación de la QoS. Los métodos de clasificación de flujos de tráfico en la capa 2 y 3 incluyen el uso de interfaces, ACL y mapas de clase. El tráfico también se puede clasificar en las capas 4 a 7 mediante el uso del Reconocimiento de aplicaciones basado en la red (NBAR).

Nota: NBAR es una característica de clasificación y descubrimiento de protocolo del software Cisco IOS que funciona con características de QoS. NBAR excede el ámbito de este curso.

La marcación significa que estamos agregando un valor al encabezado de paquetes. Los dispositivos que reciben el paquete se basan en este campo para ver si coincide con una política definida. La marcación debe realizarse tan cerca de la fuente como sea posible. Esto determina el límite de confianza.

La forma en la que se marca el tráfico generalmente depende de la tecnología. La tabla de la figura describe algunos de los campos de marcado que se usan en diversas tecnologías. La decisión de marcar el tráfico de las capas 2 o 3 (o ambos) no es despreciable y debe tomarse tras considerar los siguientes puntos:

• Se puede marcar la Capa 2 de las tramas para el tráfico no IP.
• El marcado en la capa 2 de las tramas es la única opción de la QoS disponible para los switches que no tienen «reconocimiento de IP».
• El marcado de Capa 3 llevará la información de la QoS de extremo a extremo.

Traffic Marking for QoS

Herramientas de la QoS	Capa	Campo de marcación	Ancho en bits
Ethernet (802.1Q, 802.1p)	2	Clase de servicio (CoS)	3
802.11 (Wi-Fi)	2	Identificador de tráfico (TID) de Wi-Fi	3
MPLS	2	Experimental (EXP)	3
IPv4 e IPv6	3	Precedencia de IP (IPP)	3
IPv4 e IPv6	3	Punto de código de servicios diferenciados (DSCP)	6

9.5.5. Marcación en la capa 2

802.1Q es el estándar IEEE que admite etiquetado VLAN en la capa 2 de las redes Ethernet. Cuando se implementa 802.1Q, se agregan dos campos a la trama de Ethernet. Como se muestra en la figura, estos dos campos se insertan en la trama de Ethernet después del campo de la dirección MAC de origen.

Valores de clase de servicio Ethernet (CoS)

El estándar 802.1Q también incluye el esquema de priorización de la QoS conocido como IEEE 802.1p. El estándar 802.1p usa los tres primeros bits del campo de información de control de etiqueta (TCI). Conocido como campo de prioridad (PRI), este campo de 3 bits identifica las marcas de clase de servicio (CoS). Tres bits significa que una trama Ethernet de capa 2 se puede marcar con uno de los ocho niveles de prioridad (valores 0-7) como se muestra en la figura.

Ethernet Class of Service (CoS) Values

Valor de CoS	Valor binario de CoS	Descripción
0	000	Datos de mejor esfuerzo
1	001	Datos de prioridad media
2	010	Datos de alta prioridad
3	011	Señalización de llamadas
4	100	Videoconferencia
5	101	Portador de voz (tráfico de voz)
6	110	Reservado
7	111	Reservado

9.5.6. Marcación en la capa 3

IPv4 e IPv6 especifican un campo de 8 bits en sus encabezados de paquetes para marcar los paquetes. Como se muestra en la figura, tanto IPv4 como IPv6 admiten un campo de 8 bits para marcar: el campo Tipo de servicio (ToS) para IPv4 y el campo Clase de tráfico para IPv6.

Encabezados de paquetes IPv4 e IPv6

9.5.7. Tipo de servicio y campo de clase de tráfico

El tipo de servicio (IPv4) y la clase de tráfico (IPv6) llevan el marcado de paquetes según lo asignado por las herramientas de clasificación de QoS. Luego se hace referencia al campo mediante dispositivos receptores que reenvían los paquetes en función de la política de QoS asignada apropiada.

La figura muestra el contenido del campo de 8 bits. En RFC 791, el estándar original de IP especificaba el campo de preferencia de IP (IPP) que se utilizará para las marcaciones de la QoS. Sin embargo, en la práctica, estos tres bits no proporcionaban suficiente granularidad para implementar QoS.

RFC 2474 reemplaza RFC 791 y redefine el campo de ToS al cambiar el nombre y ampliar el campo de IPP. El nuevo campo, como se muestra en la figura, tiene 6 bits asignados para QoS. Conocido como campo de punto de código de servicios diferenciados (DSCP), estos seis bits ofrecen un máximo de 64 clases de servicio posibles. Los dos bits restantes de notificación de congestión extendida (ECN) de IP pueden usarse en los routers con reconocimiento de ECN para marcar paquetes en vez de descartarlos. La marcación de ECN informa a los routers corriente abajo que hay congestión en el flujo de paquetes.

9.5.8. Valores DSCP

Los 64 valores de DSCP se organizan en tres categorías:

• Best-Effort (BE) – este es el valor predeterminado para todos los paquetes IP. El valor de DSCP es 0. El comportamiento por salto es enrutamiento normal. Cuando un router experimenta congestión, estos paquetes se descartan. No se implementa plan de la QoS.
• Reenvío acelerado (EF) – RFC 3246 defines EF as the DSCP decimal value 46 (binary 101110). Los primeros 3 bits (101) se asocian directamente al valor 5 de CoS de capa 2 que se utiliza para el tráfico de voz. En la capa 3, Cisco recomienda que EF solo se use para marcar paquetes de voz.
• Reenvío asegurado (AF) – RFC 2597 define el AF para usar los 5 bits DSCP más significativos para indicar las colas y la preferencia de descarte. La definición de AF se ilustra en la figura.

Valores de envío seguro

La AFxy fórmula se especifica de la siguiente manera:

• Los primeros 3 bits más significativos se utilizan para designar la clase. La clase 4 es la mejor cola y la clase 1 es la peor.
• El 4.° y 5.° bit más significativos se usan para indicar la preferencia de descarte.
• El 6.° bit más significativo se establece en cero.

Por ejemplo, AF32 pertenece a la clase 3 (binario 011) y tiene una preferencia media de descarte (binario 10). El valor de DSCP completo es 28 porque se incluye el 6.° bit en 0 (binario 011100).

9.5.9. Bits selectores de clase

Como los primeros 3 bits más significativos del campo DSCP indican la clase, estos bits también se denominan bits de selector de clase (CS). Estos 3 bits se asignan directamente a los 3 bits del campo CoS y el campo IPP para mantener la compatibilidad con 802.1p y RFC 791, como se muestra en la figura.

Capa 2 CoS y Capa 3 ToS

La tabla en la figura muestra cómo los valores de CoS se correlacionan con los selectores de clase y el valor DSCP correspondiente de 6 bits. Esta misma tabla se puede usar para asociar los valores de IPP a los selectores de clase.

Asignación de CoS a los selectores de clase en DSCP

9.5.10. Límites de confianza

¿Dónde deberían producirse las marcaciones? El tráfico se debe clasificar y marcar lo más cerca su origen como sea técnicamente y administrativamente posible. Esto define el límite de confianza, como se muestra en la figura.

1. Los terminales confiables tienen las capacidades y la inteligencia para marcar el tráfico de aplicaciones con las CoS de capa 2 apropiadas y/o los valores de DSCP de la Capa 3. Algunos ejemplos de terminales de confianza incluyen teléfonos IP, puntos de acceso inalámbrico, gateways y sistemas de videoconferencia, estaciones de conferencia IP y más.
2. Los terminales seguros pueden hacer que el tráfico se marque en el switch de la capa 2.
3. El tráfico también puede marcarse en los switches/routers de la capa 3.

Por lo general, es necesario volver a marcar el tráfico, por ejemplo, volver a marcar los valores de CoS en los valores de precedente IP o DSCP.

Varios límites de confianza

9.5.11. Prevención de congestión

La gestión de la congestión incluye métodos de colas y programación en los que el tráfico excesivo se almacena o se pone en cola (y a veces se cae) mientras espera que se envíe una interfaz de salida. Las herramientas para evitar la congestión son más simples. Las cargas de tráfico de la red, en un esfuerzo por anticipar y evitar la congestión en los cuellos de botella de la red común y de internetwork antes de que la congestión se convierta en un problema. Estas herramientas pueden supervisar la profundidad promedio de la cola, como se detalla en la figura. Cuando la cola está por debajo del umbral mínimo, no hay descartes. A medida que la cola alcanza el umbral máximo, se descarta un pequeño porcentaje de paquetes. Cuando se supera el umbral máximo, se descartan todos los paquetes.

Mecanismos de prevención de congestión

Algunas técnicas de prevención de congestionamiento proporcionan un trato preferencial para determinar qué paquetes se descartan. Por ejemplo, QoS de IOS de Cisco incluye detección temprana aleatoria ponderada (WRED) como posible solución de prevención de congestión. El algoritmo WRED permite evitar la congestión en las interfaces de red al brindar administración del búfer y permitir que el tráfico TCP disminuya antes de que se agoten los buffers. El uso de WRED ayuda a evitar las eliminaciones de cola y maximiza el uso de la red y el rendimiento de las aplicaciones basadas en TCP. No se evita la congestión para el tráfico basado en el protocolo de datagrama de usuario (UDP), como el tráfico de voz. En el caso del tráfico basado en UDP, los métodos como la puesta en cola y las técnicas de compresión ayudan a reducir, e incluso a prevenir, la pérdida de paquetes UDP.

9.5.12. Modelado y regulación

Las políticas de modelado y de vigilancia del son dos mecanismos proporcionados por el software Cisco IOS QoS para evitar la congestión.

El modelado del tráfico conserva los paquetes en exceso en una cola y luego programa el exceso para la transmisión posterior en incrementos de tiempo. El resultado de la conformación del tráfico es una tasa de salida de paquetes suavizada, como se muestra en la figura.

Ejemplo de modelado (shaping) del tráfico

El modelado implica la existencia de una cola y de memoria suficiente para almacenar en búfer los paquetes retardados, mientras que la vigilancia no hace esto.

Asegúrese de tener memoria suficiente cuando active el modelado. Además, la formación requiere una función de programación para la transmisión posterior de cualquier paquete con retardo. Esta función de programación le permite organizar la cola de modelado en distintas colas. Entre las funciones de programación son CBWFQ y LLQ.

El modelado es un concepto saliente; los paquetes que salen de una interfaz se almacenan en cola y pueden modelarse. Por el contrario, la vigilancia se aplica al tráfico entrante de la interfaz. Cuando la velocidad del tráfico alcanza el la velocidad máxima, se descarta el tráfico excesivo (o comentado).

Los proveedores de servicios suelen implementar la vigilancia para aplicar una tasa de información de clientes (CIR) por contrato. Sin embargo, el proveedor de servicios también puede permitir el estallido por CIR si la red del proveedor de servicios no tiene congestión en la actualidad.

Ejemplo de regulación (policing) del tráfico

9.5.13. Pautas de directivas deQoS

La directiva QoS debe tener en cuenta la ruta completa desde el origen hasta el destino. Si un dispositivo de la ruta de acceso está utilizando una directiva diferente a la deseada, entonces toda la directiva de QoS se ve afectada. Por ejemplo, el tartamudeo en la reproducción de vídeo podría ser el resultado de un conmutador en la ruta que no tiene el valor CoS establecido adecuadamente.

Algunas pautas que ayudan a garantizar la mejor experiencia para los usuarios finales incluyen las siguientes:

• Habilite la puesta en cola en todos los dispositivos de la ruta entre el origen y el destino.
• Clasifique y marque el tráfico lo más cerca posible de la fuente.
• Forma y policía los flujos de tráfico lo más cerca posible de sus fuentes.

9.6. Práctica del módulo y cuestionario

9.6.1. ¿Qué aprenderé en este módulo?

Calidad de transmisión de red

Las transmisiones de voz y vídeo en directo crean mayores expectativas de calidad entre los usuarios y crean una necesidad de calidad de servicio (QoS). La congestión ocurre cuando se agregan varias líneas de comunicación en un solo dispositivo, como un enrutador, y luego gran parte de esos datos se colocan en unas pocas interfaces de salida o en una interfaz más lenta. La congestión también puede producirse cuando los paquetes de datos grandes impiden que paquetes más pequeños se transmiten al tiempo. Sin mecanismos de la QoS en el lugar, los paquetes se procesan en el orden en el que se reciben. Cuando hay congestión, los dispositivos de red como routers y switches pueden descartar paquetes. Esto significa que los paquetes sensibles al tiempo, como el video y la voz en tiempo real y voz, se descartarán con la misma frecuencia que los datos que no sean urgentes, como el correo electrónico y la exploración web. Cuando el volumen de tráfico es mayor que el que se puede transportar a través de la red, los dispositivos ponen en cola (retienen) los paquetes en la memoria hasta que los recursos estén disponibles para transmitirlos. Los paquetes en cola causan retrasos, dado que los nuevos paquetes no se pueden transmitir hasta que no se hayan procesado los anteriores. Una técnica de QoS que puede ayudar con este problema es clasificar los datos en múltiples colas. Los puntos de congestión de red son candidatos ideales para los mecanismos de QoS a fin de mitigar el retraso y la latencia. Dos tipos de demoras son las fijas y las variables. Las fuentes de demora son demora de código, demora de empaquetado, demora de espera, demora de serialización, demora de propagación y demora de jitter. La fluctuación es la variación en la demora de los paquetes recibidos. Debido a la congestión de red, los errores de puesta en cola o los errores de configuración, la demora entre cada paquete puede variar en vez de permanecer constante. Es necesario controlar y minimizar tanto la demora como las fluctuaciones para admitir el tráfico en tiempo real e interactivo.

Características del tráfico

El tráfico de voz y video son dos de las principales razones de QoS. El tráfico de voz es suave y benigno, pero es sensible a caídas y retrasos. La voz puede tolerar una cierta cantidad de latencia, fluctuación y pérdida sin efectos aparentes. La latencia no debe superar los 150 milisegundos (ms). Las fluctuaciones no deben superar los 30 ms y la pérdida de paquetes de voz no debe ser superior al 1%. El tráfico de voz requiere al menos 30 Kbps de ancho de banda. El tráfico de vídeo es más exigente que el tráfico de voz debido al tamaño de los paquetes que envía a través de la red. El tráfico de video es explosivo, codicioso, sensible a la caída y sensible al retraso. Sin QoS y una cantidad significativa de ancho de banda adicional, la calidad de video generalmente se degrada. Los puertos UDP, como el 554, se utilizan para el Protocolo de transmisión en tiempo real (RSTP) y se les debe dar prioridad sobre otro tráfico de red menos sensible al retraso. Similar a la voz, el video puede tolerar una cierta cantidad de latencia, fluctuación y pérdida sin efectos notables. La latencia no debe ser superior a 400 milisegundos (ms). Las fluctuaciones no deben ser de más de 50 ms, y la pérdida de paquetes de video no debe ser superior al 1%. El tráfico de video requiere al menos 384 Kbps de ancho de banda. El tráfico de datos no es tan exigente como el tráfico de voz y vídeo. Los paquetes de datos a menudo utilizan aplicaciones TCP que pueden retransmitir datos y, por lo tanto, no son sensibles a caídas y retrasos. Aunque el tráfico de datos es relativamente insensible a las caídas y los retrasos en comparación con la voz y el video, un administrador de red aún debe considerar la calidad de la experiencia del usuario, a veces denominada Calidad de la experiencia (QoE). Los dos factores principales que un administrador de red necesita preguntar sobre el flujo del tráfico de datos son si los datos provienen de una aplicación interactiva y si los datos son de misión crítica.

Algoritmos de cola

La política de la QoS implementada por el administrador de la red se activa cuando se produce una congestión en el enlace. La puesta en cola es una herramienta administrativa para la congestión que puede almacenar en búfer, priorizar, y, si corresponde, reordenar los paquetes antes de que estos se transmitan al destino. Este curso se centra en los siguientes algoritmos de colas: Primero en entrar, Primero en salir (FIFO), Cola justa ponderada (WFQ), Cola justa y ponderada basada en clases (CBWFQ) y Cola de baja latencia (LLQ). FIFO pone en cola buffers y reenvía paquetes en el orden de su llegada. FIFO no tiene concepto de prioridad ni clases de tráfico, por lo que no toma decisiones sobre la prioridad de los paquetes. Cuando se utiliza FIFO, el tráfico importante o sensible al tiempo se puede descartar cuando hay congestión en la interfaz del enrutador o conmutador. La WFQ es un método de programación automatizada que proporciona la asignación del ancho de banda justo a todo el tráfico de red. El WFQ aplica la prioridad o los pesos para identificar el tráfico y clasificarlo en conversaciones o flujos. La WFQ clasifica el tráfico en distintos flujos basados en el encabezado de manejo de paquetes, lo que incluye características como las direcciones IP de origen y de destino, las direcciones MAC, los números de puerto, el protocolo y el valor del tipo de servicio (ToS). El valor ToS en el encabezado IP puede utilizarse para clasificar el tráfico. El CBWFQ extiende la funcionalidad estándar de la cola equitativa ponderada (WFQ) para admitir las clases de tráfico definidas por el usuario. Con CBWFQ, usted define clases de tráfico basadas en criterios de coincidencia que incluyen protocolos, listas de control de acceso (ACL) e interfaces de entrada. La característica LLQ trae cola de prioridad estricta (PQ) a CBWFQ. La estricta PQ permite que los paquetes sensibles al retraso, como la voz, se envíen antes que los paquetes en otras colas, lo que reduce la fluctuación en las conversaciones de voz.

Modelos de QoS

La estricta PQ permite que los paquetes sensibles al retraso, como la voz, se envíen antes que los paquetes en otras colas, lo que reduce la fluctuación en las conversaciones de voz. El modelo Best-effort es el más escalable, pero no garantiza la entrega y no da ningún tratamiento preferencial de paquetes. El modelo de arquitectura IntServ se desarrolló para satisfacer las necesidades de aplicaciones en tiempo real, como video remoto, conferencias multimedia, aplicaciones de visualización de datos y realidad virtual. IntServ es un modelo de servicios múltiples que puede acomodar muchos requisitos de QoS. IntServ administra explícitamente los recursos de red para proporcionar QoS a flujos o flujos individuales, a veces denominados microflujos. Utiliza reserva de recursos y mecanismos de control de admisión como módulos de construcción para establecer y mantener QoS. El modelo DiffServ QoS especifica un mecanismo simple y escalable para clasificar y administrar el tráfico de red. El diseño de DiffServ supera las limitaciones de los modelos de mejor esfuerzo e IntServ. El modelo DiffServ puede proporcionar una QoS «casi garantizada», sin dejar de ser rentable y escalable. DiffServ divide el tráfico de red en clases según los requisitos de la empresa. Se puede asignar a un nivel diferente de servicio a cada una de las clases. A medida que los paquetes atraviesan una red, cada uno de los dispositivos de red identifica la clase de paquete y brinda servicios al paquete según esa clase. Con DiffServ, es posible elegir muchos niveles de servicio.

Técnicas de implementación de QoS

Hay tres categorías de herramientas de QoS: herramientas de clasificación y marcado, herramientas para evitar la congestión y herramientas de gestión de la congestión. Antes de que a un paquete se le pueda aplicar una política de la QoS, el mismo tiene que ser clasificado. La clasificación y la marcación nos permiten identificar o “marcar” los tipos de paquetes. La clasificación determina la clase de tráfico al cual los paquetes o tramas pertenecen. Los métodos de clasificación de flujos de tráfico en la capa 2 y 3 incluyen el uso de interfaces, ACL y mapas de clase. El tráfico también se puede clasificar en las capas 4 a 7 mediante el uso del Reconocimiento de aplicaciones basado en la red (NBAR). El tipo de servicio (IPv4) y la clase de tráfico (IPv6) llevan el marcado de paquetes según lo asignado por las herramientas de clasificación de QoS. Luego se hace referencia al campo mediante dispositivos receptores que reenvían los paquetes en función de la política de QoS asignada apropiada. Estos campos tienen 6 bits asignados para QoS. Conocido como campo de punto de código de servicios diferenciados (DSCP), estos seis bits ofrecen un máximo de 64 clases de servicio posibles. Luego se hace referencia al campo mediante dispositivos receptores que reenvían los paquetes en función de la política de QoS asignada apropiada. Los 64 valores DSCP están organizados en tres categorías: Mejor esfuerzo (BE), Reenvío acelerado (EF) y Reenvío asegurado (AF). Como los primeros 3 bits más significativos del campo DSCP indican la clase, estos bits también se denominan bits de selector de clase (CS). El tráfico se debe clasificar y marcar lo más cerca su origen como sea técnicamente y administrativamente posible. Esto define el límite de confianza. La gestión de la congestión incluye métodos de colas y programación en los que el tráfico excesivo se almacena o se pone en cola (y a veces se cae) mientras espera que se envíe una interfaz de salida. Las herramientas para evitar la congestión ayudan a monitorear las cargas de tráfico de la red en un esfuerzo por anticipar y evitar la congestión en la red común y los cuellos de botella entre redes antes de que la congestión se convierta en un problema. Cisco IOS QoS incluye detección temprana aleatoria ponderada (WRED) como una posible solución para evitar la congestión. El algoritmo WRED permite evitar la congestión en las interfaces de red al brindar administración del búfer y permitir que el tráfico TCP disminuya antes de que se agoten los buffers. Las políticas de modelado y de vigilancia del son dos mecanismos proporcionados por el software Cisco IOS QoS para evitar la congestión.