Capítulo 33:
Calidad del servicio
En las redes actuales, los usuarios esperan que el
contenido esté disponible de inmediato. Pero si el tráfico excede el ancho de
banda de los enlaces entre el origen del contenido y el usuario, ¿cómo pueden
los administradores de redes garantizar una experiencia de calidad? El diseño
de la red puede incluir herramientas de calidad de servicio (QoS) para
garantizar que ciertos tipos de tráfico, como voz y video, tengan prioridad
respecto al tráfico sin plazos, como el correo electrónico y la navegación web.
En este capítulo se
describe la calidad de la transmisión de red, las características del tráfico,
los algoritmos de puesta en cola, los modelos de QoS y las técnicas de
implementación de QoS.
Priorización del tráfico
La calidad de servicio (QoS) es un requisito cada vez más
importante para las redes hoy en día. Las nuevas aplicaciones disponibles para
los usuarios, como las transmisiones de voz y de video en vivo, aumentan las
expectativas de calidad de envíos.
La congestión se produce cuando se agregan varias líneas de
comunicación en un mismo dispositivo, como un router, y luego muchos de esos
datos se colocan en menos interfaces salientes 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 de lo que se puede
transportar en la red, los dispositivos colocan los paquetes en cola en la
memoria hasta que haya recursos 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 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 experimenta algún
tipo de congestión.
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 fuertes para los mecanismos de
QoS. La Figura 1 muestra tres ejemplos típicos 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. Una demora variable lleva una cantidad indeterminada de tiempo y
se ve afectada por factores como la cantidad de tráfico procesada.
Las causas de demora se resumen en la tabla de la figura 2.
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
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.
Pérdida de
paquetes
Sin mecanismos de 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.
Por ejemplo, cuando un router recibe un flujo de audio digital
del protocolo de transmisión en tiempo real (RTP) del protocolo de tiempo real
para voz sobre IP (VoIP), debe compensar las fluctuaciones que se encuentren.
El mecanismo que administra esta función es el búfer de demora de reproducción.
El búfer de demora de reproducción debe almacenar estos paquetes en búfer y
reproducirlos en una transmisión constante, como se muestra en la
figura 1. Los paquetes digitales luego se convierten nuevamente en una
transmisión de audio analógica.
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.
En el caso de pérdidas pequeñas de un paquete, el procesador de
señales digitales (DSP) extrapola la información faltante del audio para que el
usuario pueda escucharlo sin problemas. Sin embargo, cuando las fluctuaciones
exceden lo que puede hacer el DSP para compensar los paquetes faltantes, se
escuchan los problemas de audio.
La pérdida de paquetes es una causa común de los problemas de
calidad de voz en una red IP. En una red diseñada correctamente, la pérdida de
paquetes debe estar cerca de cero. Los códecs de voz utilizados por DSP pueden
tolerar cierto grado de pérdida de paquetes sin un efecto radical en la calidad
de voz. Los ingenieros de redes utilizan mecanismos de QoS para clasificar
paquetes de voz para que la pérdida de paquetes sea igual a cero. Se garantiza
el ancho de banda para las llamadas de voz dando prioridad al tráfico de voz
sobre el tráfico que no es sensible al tiempo.
Tendencias en el
tráfico de red
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 virtuales (VNI) de
Cisco, el tráfico de video representó un 67 % del tráfico total
en 2014. Para 2019, representará el 80% de todo el tráfico. Además, el tráfico
de video móvil aumentará más del 600%, de 113 672 TB a 768 334 TB.
Los tipos de demandas de voz, video y tráfico de datos en la red
son muy diferentes.
Voz
El tráfico de voz es predecible y uniforme, como se muestra en la
figura. Sin embargo, la voz es muy sensible a las demoras y los paquetes
descartados; no hay motivo para retransmitir la voz si se pierden paquetes. Por
ende, los paquetes de voz deben recibir una prioridad más alta que otros tipos
de tráfico. Por lo tanto, debe recibir una prioridad más alta. 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.
Video
Sin QoS y una cantidad significativa de capacidad de ancho de
banda adicional, la calidad de video normalmente disminuye. 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 los datos por paquete, como se muestra en la Figura 1. Observe
cómo los paquetes de voz llegan cada 20 ms y son de 200 bytes predecibles cada
uno. En cambio, la cantidad y el tamaño de los paquetes de video varían cada 33
ms según el contenido del video. Por ejemplo, si la transmisión de video se compone
de contenido que no cambia mucho de un cuadro a otro, los paquetes de video
serán pequeños, y se necesitarán menos para mantener una experiencia de usuario
aceptable. No obstante, si la transmisión de video consta de contenido que
cambia rápidamente, como la secuencia de acción de una pelicula, entonces los
paquetes de video serán más grandes y se necesitará mayor cantidad por cada
intervalo de 33 ms para ofrecer una experiencia aceptable al usuario.
En la Tabla 2, se resumen las características del tráfico de
video. Los puertos UDP, como 554 utilizados para el protocolo de transmisión en
tiempo real (RSTP), deben tener prioridad sobre otro tráfico de red menos
sensible al tiempo. Al igual que la voz, el video puede tolerar cierta cantidad
de latencia, fluctuación, y pérdida sin ningún efecto notable. 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.
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 ser muy expansivas
y consumir una gran porción 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. En la Tabla 1, se resumen las características del
tráfico de datos.
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. Los dos factores
principales acerca del flujo del tráfico de datos por los que un administrador
de red debe preguntar son los siguientes:
·
¿Los datos provienen de una aplicación interactiva?
·
¿Los datos son críticos?
La figura 2 compara estos dos factores.
Encolamiento:
Descripción general
La política de 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)
·
CBWFQ (mecanismo de cola de espera
equitativo y ponderado basado en clases)
·
Mecanismo de cola de baja latencia
(LLQ)
Mecanismo de cola
primero en entrar, primero en salir
En su forma más simple, la puesta en cola FIFO, también conocida
como asignación por orden de llegada (FCFS), implica el almacenamiento en búfer
y el reenvío de paquetes 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 el tráfico sea
más importante o sensible al tiempo según la clasificación de prioridad,
observe 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 se produce una congestión en el router o en la
interfaz del switch. Cuando no hay otras estrategias de cola configuradas,
todas las interfaces, excepto las interfaces seriales en E1 (2048 mbps) y
debajo utilizan 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.
Mecanismo de cola
de espera equitativa ponderada (WFQ)
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. WQF aplica
prioridades o ponderaciones para identificar el tráfico y clasificarlo en
conversaciones o flujos, como se muestra en la figura.
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. El ToS se describirá
más adelante en el capítulo.
Los flujos de tráfico de bajo ancho de banda, que conforman el
mayor parte del tráfico, reciben servicio preferencial, lo que permite que
todas sus cargas ofrecidas se envíen oportunamente. Los flujos de tráfico de
gran volumen comparten la capacidad restante proporcionalmente entre sí.
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.
Si bien la WFQ se adapta automáticamente a las condiciones de
tráfico de red cambiantes, no ofrece el grado de control de precisión sobre la
asignación de ancho de banda que ofrece el CBWFQ.
CBWFQ (mecanismo
de cola de espera equitativa ponderada basada en clases)
El CBWFQ extiende la funcionalidad estándar de la cola
equitativa ponderada (WFQ) para admitir las clases de tráfico definidas por el
usuario. Para el CBWFQ, se definen las clases de tráfico en base a los
criterios de concordancia, incluidos los protocolos, las listas de control de
acceso (ACL) y las 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.
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.
Mecanismo de cola
de baja latencia (LLQ)
La función de LLQ proporciona la cola de prioridad estricta (PQ)
a CBWFQ. La asignación de cola de prioridad estricta permite que los datos
susceptibles a la demora, como la voz, se envíen antes que los paquetes de 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.
Con la LLQ, los datos susceptibles a la demora se envían
primero, antes de que se procesen los paquetes de otras colas. La LLQ permite
que los datos susceptibles a la demora, como la voz, se envíen primero (antes
que los paquetes de otras colas), con lo que se otorga un tratamiento
preferencial a los datos susceptibles a la demora con respecto a otros tipos de
tráfico. Aunque es posible poner varios tipos de tráfico en tiempo real en cola
de prioridad estricta, Cisco recomienda redirigir solo el tráfico de voz a la
cola de prioridad.
Selección de un
modelo adecuado de política de QoS
¿Cómo se puede implementar QoS en una red? Los tres
modelos de implementación de QoS son:
·
Modelo de mejor esfuerzo (calidad en
el servicio)
·
Servicios integrados (IntServ)
·
Servicios diferenciados (DiffServ)
La tabla de la
figura resume estos tres modelos. QoS se implementa realmente en una red que
utiliza IntServ o DiffServ. IntServ ofrece la máxima garantía de QoS, pero
consume muchos recursos, por lo que su escalabilidad es limitada. En cambio,
DiffServ consume menos recursos y es más escalable. En algunas ocasiones, los
dos se emplean juntos para la implementación de QoS en redes.
Modelo de mejor
esfuerzo
El diseño básico de Internet ofrece la entrega de paquetes
mediante el modelo de mejor esfuerzo y no brinda ninguna garantía. Este enfoque
aún predomina en Internet actualmente y sigue siendo adecuado en la mayoría de
los casos. El modelo de mejor esfuerzo trata a todos los paquetes de red de la
misma manera, por eso un mensaje de voz de emergencia se trata de la misma
manera que una foto digital adjuntada 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 de la figura incluye las ventajas y desventajas del
modelo de mejor esfuerzo.
Servicios
integrados
Las necesidades de aplicaciones en tiempo real, como video
remoto, conferencias multimedia, visualización y realidad virtual, motivaron el
desarrollo del modelo de arquitectura IntServ en 1994 (RFC 1633, 2211 y 2212).
IntServ es un modelo de servicio múltiple que puede acomodar múltiples
requisitos de Calidad de Servicio (QoS).
IntServ proporciona una manera de entregar la QoS completa que
las aplicaciones en tiempo real requieren al administrar explícitamente los
recursos de red para proporcionar QoS a las transmisiones de paquetes
específicas de usuario, 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. Esta práctica es similar a un concepto conocido como
“hard QoS”. 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 1 es una simple ilustración del modelo de IntServ.
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 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 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 de la figura 2 incluye las ventajas y desventajas
del modelo IntServ.
Servicios
diferenciados
El modelo de Calidad de Servicio (QoS) de servicios
diferenciados (DiffServ) especifica un mecanismo simple y escalable para
clasificar y administrar el tráfico de red y proporcionar las garantías de QoS
en redes IP modernas. Por ejemplo, DiffServ puede proporcionar servicio
garantizado de baja latencia al tráfico de red crítico, como voz o video, al
mismo tiempo que proporciona garantías del mejor tráfico a servicios no
críticos como tráfico web o 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 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 "hard QoS" (QoS fuerte) en los que los hosts terminales
señalan sus necesidades de QoS a la red, DiffServ no utiliza la 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 QoS diferentes.
La Figura 1 es una simple ilustración del modelo 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 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 2 incluye las ventajas y desventajas del modelo
DiffServ.
Nota: Las redes modernas usan 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.
Evitar 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.
·
Garantizar el suficiente ancho de
banda y aumentar el espacio en búfer para acomodar las ráfagas de tráfico de
flujos frágil. Existen varios mecanismos disponibles en el software de calidad
de servicio (QoS) de Cisco IOS que pueden garantizar el ancho de banda y
proporcionar el reenvío prioritario a las aplicaciones sensibles a las caídas.
Algunos ejemplos son WFQ, CBWFQ y LLQ.
·
Evitar la congestión el descartar
paquetes de prioridad más baja antes de que se produzca la congestión. QoS de
Cisco IOS proporciona mecanismos de espera que comienzan a descartar paquetes
de prioridad más baja antes de que se produzca la congestión. Un ejemplo es la
Detección Temprana Aleatoria Ponderada (WRED).
Herramientas de
QoS
Hay tres categorías de herramientas de QoS, como se
describe en la tabla de la figura 1:
·
Herramientas de clasificación y
marcación
·
Herramientas para evitar la
congestión
·
Herramientas de administración de
congestión
Consulte la Figura
2 para comprender la secuencia de cómo se utilizan estas herramientas cuando se
aplica QoS a los flujos de paquetes.
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
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 QoS, como la
organización de la cola y el modelado, generalmente se realizan al egreso.
Clasificación y
marcación
Antes de que a un paquete se le pueda aplicar una
política de 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 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 función de clasificación y detección
del software Cisco IOS que opera con las funciones 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 QoS disponible para los switches que no tienen
"reconocimiento de IP".
·
El marcado de Capa 3 llevará la
información de QoS de extremo a extremo.
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 1, estos dos campos se
insertan en la trama de Ethernet a continuación del campo de dirección MAC de
origen.
El estándar 802.1Q también incluye el esquema de priorización de
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). Los 3 bits implican que una trama de Ethernet de capa 2 se
puede marcar con uno de ocho niveles de prioridad (valores 0 a 7), como se
muestra en la figura 2.
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 1, IPv4 e IPv6 admiten un campo de 8 bits para marcado, el campo de
tipo de servicio (ToS) para IPv4 y el campo de clase de tráfico para IPv6.
Estos campos se
utilizan para transportar la marcación de paquete asignada por las herramientas
de la clasificación de QoS. Luego, los dispositivos receptores remiten al campo
para reenviar los paquetes según la política QoS asignada correspondiente.
La figura 2
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 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 campo nuevo, como se muestra en la figura 2, 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.
Los 64 valores de
DSCP se organizan en tres categorías:
·
Mejor esfuerzo (BE): 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 QoS.
·
Reenvío acelerado
(EF): RFC 3246 define EF como valor
decimal 46 de DSCP (binario 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 AF para usar los 5
bits más significativos de DSCP a fin de indicar las colas y las preferencias
de descarte. Como se muestra en la figura 3, los primeros 3 bits más
significativos se usan 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. La fórmula de AFxy muestra cómo se calculan los valores de AF. 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).
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). Como se muestra en la figura 4,
estos 3 bits se asocian directamente a los 3 bits del campo de CoS y del campo
de IPP para mantener la compatibilidad con 802.1p y RFC 791.
La tabla de la
figura 5 muestra cómo los valores de CoS se asocian a los selectores de
clase y al valor de 6 bits de DSCP correspondiente. Esta misma tabla se puede
usar para asociar los valores de IPP a los selectores de clase.
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.
·
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.
·
Los terminales seguros pueden hacer
que el tráfico se marque en el switch de la capa 2.
·
El tráfico también puede marcarse en
los switches/routers de la capa 3.
Generalmente, es
necesario volver a marcar el tráfico. Por ejemplo, la remarcación de los
valores de CoS a valores de prioridad IP o DSCP.
Prevención de
congestión
La administración de congestión incluye los métodos de espera y
de programación, donde el tráfico excesivo se almacena en búfer o se pone en
cola (y a veces se descarta) mientras espera ser enviado en una interfaz de
egreso. 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.
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.
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 del modelado de tráfico es una tasa uniforme de salida de
paquetes, como se muestra en la figura 1.
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.