Qué es DSCP (Differentiated Services Code Point) y cómo funciona

En el día a día de una red moderna se mezclan videollamadas, VoIP, descargas, streaming y tráfico de control. Todo compite por el mismo ancho de banda y, si no se hace nada, los paquetes se trata por igual (por ejemplo, puedes cambiar la prioridad de adaptadores de red). Ahí es donde entra en juego DSCP, un mecanismo que permite decirle a la red qué tráfico es más importante y cómo debe tratarlo en cada salto.

Cuando hablamos de DSCP (Differentiated Services Code Point) nos referimos a unos bits dentro de la cabecera IP que marcan la prioridad y el tratamiento de cada paquete. Es la base de la arquitectura DiffServ definida por la IETF, y es clave para ofrecer Calidad de Servicio (QoS) real en redes con voz, vídeo, servicios en la nube o aplicaciones críticas. Entender bien DSCP es casi obligatorio para cualquiera que administre o diseñe redes hoy en día.

Qué es DSCP y por qué es tan importante

El DSCP (Differentiated Services Code Point) es un campo de 6 bits situado en la cabecera IP (tanto en IPv4 como en IPv6) que indica el nivel de servicio que debe recibir un paquete mientras atraviesa la red. Es decir, le dice a cada router y switch cómo debe clasificar, encolar, priorizar y, en caso necesario, descartar ese paquete.

Este campo DSCP forma parte del antiguo byte de Type of Service (ToS) descrito en los RFC 791 y 1349, que más adelante se renombró a campo DS (Differentiated Services) según el RFC 2474. En el modelo actual, los 6 bits más significativos se usan para DSCP y los 2 bits menos significativos se reservan para otros usos, principalmente ECN (Explicit Congestion Notification), que permite notificar congestión sin tirar paquetes.

El uso de DSCP permite que el tráfico con requisitos estrictos —por ejemplo, VoIP, videoconferencia o streaming interactivo— reciba un trato preferente: menos latencia, menos jitter y menos pérdida de paquetes. Al mismo tiempo, tráfico menos sensible, como correo electrónico, copias de seguridad o descargas masivas, se mantiene en clases de menor prioridad o simplemente en mejor esfuerzo.

DSCP no trabaja solo: es uno de los pilares de la arquitectura DiffServ (RFC 2475). La idea es muy sencilla pero potente: los routers del núcleo no hacen inspección profunda, solo miran el valor DSCP y aplican un PHB (Per-Hop Behavior, comportamiento por salto) que ya está definido. Esto hace que el sistema sea muy escalable incluso en redes grandes.

De ToS y Precedencia IP a DSCP: evolución del campo de servicio

En los orígenes de IP, el encabezado definía un campo de 8 bits llamado Type of Service (ToS), detallado en el RFC 791. Dentro de ese octeto, los 3 primeros bits indicaban la Precedencia IP y los siguientes bits marcaban preferencias de retardo, rendimiento y fiabilidad.

En el modelo original, los valores de Precedencia IP iban desde 000 (Routine) hasta 111 (Network Control), ofreciendo solo ocho niveles de prioridad. El resto de bits permitían indicar si se deseaba bajo retardo, alto rendimiento o alta confiabilidad, pero en la práctica este esquema se utilizó poco y de forma muy inconsistente en Internet.

El RFC 1349 refinó este campo ToS definiendo una estructura con PRECEDENCE, TOS y MBZ (must be zero). Se introdujeron combinaciones como “minimizar retardo”, “maximizar rendimiento” o “minimizar coste”, pero se mantenía la misma limitación clave: solo 3 bits de precedencia, es decir, ocho niveles de prioridad en total.

Con el crecimiento brutal de servicios IP (sobre todo en tiempo real), esa granularidad se quedó corta. Por eso el RFC 2474 redefine el octeto ToS como campo DS y crea el concepto de DSCP: ahora se usan 6 bits para el punto de código de servicios diferenciados, dando lugar a 64 valores distintos (de 0 a 63), más que suficiente para definir muchas clases de tráfico y diferentes comportamientos por salto.

Además, el RFC 2474 introduce el concepto de Class Selector (CS), donde los tres bits más significativos de DSCP corresponden exactamente a la antigua Precedencia IP y los tres bits restantes se ponen a cero (formato xxx000). Así, equipos antiguos que solo entienden Precedencia IP siguen interpretando correctamente la prioridad de esos paquetes.

Estructura del campo DSCP y relación con la cabecera IP

El octeto de servicio en la cabecera IP, que antes se llamaba ToS, hoy se denomina DS field (Differentiated Services field). Su formato actual, según el RFC 2474, es:

0 1 2 3 4 5 6 7
+—+—+—+—+—+—+—+—+
| DSCP | CU |
+—+—+—+—+—+—+—+—+

Los 6 bits de DSCP permiten codificar hasta 64 puntos de código, y los 2 bits CU (Currently Unused) se utilizan hoy en día principalmente para ECN, que indica explícitamente congestión sin necesidad de descartar el paquete.

Cada valor DSCP está ligado a un Per-Hop Behavior (PHB) que especifica cómo deben tratar los routers ese tráfico: prioridad relativa, asignación de ancho de banda, probabilidad de descarte, etc. Esto se traduce en decisiones muy concretas de puesta en cola, planificación (scheduling) y descarte selectivo en cada interfaz.

Desde el punto de vista práctico, los ingenieros mapean determinados valores DSCP a colas de salida en routers y switches. Por ejemplo, el tráfico con DSCP EF suele ir a una cola de prioridad estricta, mientras que las clases AF y CS se distribuyen entre colas con mecanismos como RED/WRED (Random Early Detection) para controlar la congestión.

Principales clases y valores DSCP: CS, AF, EF y otros

Dentro del abanico de 64 codepoints posibles, la IETF ha estandarizado una serie de valores muy utilizados, documentados en varios RFC (2474, 2597, 3246, entre otros). Los grupos principales son CS, AF, EF, BE y algunas clases especiales como LE.

La familia CS (Class Selector) mantiene compatibilidad con la antigua Precedencia IP. Sus valores típicos son:

• 000000 → CS0: mejor esfuerzo, prioridad base.
• 001000 → CS1
• 010000 → CS2
• 011000 → CS3
• 100000 → CS4
• 101000 → CS5
• 110000 → CS6
• 111000 → CS7

Luego tenemos el grupo AF (Assured Forwarding), definido en el RFC 2597. Su objetivo es proporcionar un ancho de banda “asegurado” con distintas probabilidades de descarte. Cada clase AF se identifica como AFxy, donde x es la clase (1 a 4) y y es la probabilidad de descarte (1 = baja, 3 = alta). Algunos ejemplos:

• AF11 (001010), AF12 (001100), AF13 (001110)
• AF21 (010010), AF22 (010100), AF23 (010110)
• AF31 (011010), AF32 (011100), AF33 (011110)
• AF41 (100010), AF42 (100100), AF43 (100110)

Otro valor muy conocido es EF (Expedited Forwarding), definido en el RFC 3246. Su codepoint estándar es 101110 (DSCP 46). Este PHB está pensado para tráfico que necesita baja latencia, bajo jitter y muy poca pérdida, como VoIP o comunicaciones en tiempo real muy sensibles.

El valor DSCP 0 corresponde a Best Effort (BE), el servicio por defecto sin garantías especiales. Es el tráfico que se envía cuando no se marca nada de forma explícita, y suele ir a colas sin prioridad.

En algunos despliegues se utiliza también una clase de Low Effort (LE), pensada para tráfico de muy baja prioridad (copias de seguridad masivas, tareas en segundo plano, etc.), que puede sacrificarse primero en caso de congestión a cambio de proteger el resto de clases.

Clasificación y marcado de tráfico con DSCP

La primera fase del uso de DSCP es la clasificación de paquetes. Los dispositivos de borde (routers, firewalls, switches de acceso) analizan cada flujo y determinan a qué clase de tráfico pertenece: voz, vídeo, datos interactivos, tráfico de control, mejor esfuerzo, copias de seguridad, etc.

Esta clasificación puede basarse en múltiples criterios: direcciones IP origen/destino, puertos TCP/UDP, protocolos, VLAN, interfaces de entrada o incluso información de capa 7 si se usa inspección más avanzada. Una vez identificada la clase, se marca el paquete con el valor DSCP correspondiente.

Existen dos grandes enfoques de marcado: el marcado estático y el marcado dinámico. En el estático, se asocian valores DSCP fijos a aplicaciones o puertos conocidos (por ejemplo, asignar EF a los puertos RTP de la centralita IP). En el dinámico, se pueden ajustar las marcas en función de la carga de la red o de políticas temporales, elevando o bajando prioridades según el momento del día o el origen del tráfico.

Es una buena práctica que el marcado DSCP se haga lo más cerca posible del origen, a menudo en el equipo del usuario, en el switch de acceso o en el firewall perimetral. A partir de ahí, todos los dispositivos del camino deben respetar y mantener esas marcas, salvo que haya motivos muy claros para reescribirlas.

Un problema común en redes que pasan por operadores es que el carrier borra o sobrescribe los valores DSCP. Si eso ocurre, se pierde la QoS extremo a extremo. Por eso es esencial conocer la política de marcado del proveedor y, si es necesario, saber si puedes sustituir el router del ISP o renegociar o adaptar las marcas a las clases que el operador sí transporta.

Calidad de Servicio (QoS) y Per-Hop Behavior (PHB)

La QoS (Quality of Service) busca garantizar parámetros medibles como ancho de banda mínimo, retardo máximo, jitter controlado y pérdida de paquetes acotada para determinados flujos. DSCP es uno de los mecanismos principales para implantar QoS de forma escalable.

En la arquitectura DiffServ, en lugar de definir circuitos por flujo, se trabaja por clases agregadas de tráfico. Cada clase está asociada a un PHB, que describe el tratamiento que recibirá el paquete en cada salto de la red: prioridad relativa de la cola, límites de ancho de banda, políticas de descarte, etc.

Entre los PHB más conocidos están EF (para tráfico muy sensible a retardo), AF (varias clases con diferentes probabilidades de descarte) y BE (best effort). Al combinar DSCP con colas de prioridad y mecanismos de scheduling, los administradores pueden garantizar que los servicios críticos se mantengan estables incluso en situaciones de congestión.

La gracia de este diseño es que los routers del núcleo solo necesitan mirar el campo DSCP y aplicar el PHB correspondiente, sin inspeccionar puertos ni flujo completo. Eso reduce la carga de procesamiento y hace que la solución sea muy eficiente en grandes backbones.

En paralelo al tratamiento de cola, se pueden usar mecanismos de policing y shaping. El policing limita la tasa de una clase y, si se supera, puede bajar la marca DSCP o descartar paquetes. El shaping, por su parte, suaviza ráfagas almacenando paquetes temporalmente, lo que ayuda a que las colas se comporten de forma más predecible.

Implementación de DSCP en routers y redes empresariales

La implementación real de DSCP se hace principalmente en routers, firewalls y switches gestionables. En el caso de equipos de fabricantes como Cisco, Juniper, etc., se definen clases de tráfico, políticas de QoS y mapeos de DSCP a colas mediante la CLI o interfaces web avanzadas.

El proceso típico pasa por varios pasos: primero se definen las clases (por ejemplo, VoIP, vídeo, datos críticos, mejor esfuerzo), luego se asignan valores DSCP concretos a cada clase (EF, AF4x, AF3x, CS0, etc.) y por último se vinculan esos valores a colas y prioridades en cada interfaz de salida.

También es muy habitual usar ACLs (Access Control Lists) o reglas de clasificación para identificar el tráfico que debe ser marcado o reclasificado. Por ejemplo, se puede capturar todo el tráfico con destino a un servidor de telefonía y aplicar un marcado EF, o detectar flujos de vídeo corporativo y asignarles AF41.

En redes empresariales amplias, resulta casi imprescindible centralizar la política de DSCP: definir un esquema de clases común para toda la organización y documentar qué valores se usan para cada servicio. Esto evita el caos de que cada equipo marque de una manera distinta, lo que provocaría resultados impredecibles.

Una red bien diseñada con DSCP permite que, aunque haya picos de tráfico o congestión puntual, las llamadas de voz, las videoconferencias y las aplicaciones críticas sigan funcionando con calidad aceptable, sacrificando si es necesario tráfico menos prioritario como copias de seguridad nocturnas o descargas puntuales.

Compatibilidad con equipos heredados y uso de Class Selector

Muchas redes todavía arrastran equipos antiguos que solo entienden el campo de Precedencia IP y no implementan completamente DiffServ. Para no romper nada, DSCP fue diseñado con una fuerte preocupación por la compatibilidad hacia atrás.

Los valores Class Selector (CS) se han definido precisamente para esto. Al utilizar codepoints de la forma xxx000, los tres bits más significativos coinciden con los antiguos bits de precedencia, de modo que los dispositivos legacy siguen interpretando correctamente la prioridad del tráfico, aunque ignoren el resto de capacidades de DiffServ.

Por ejemplo, un paquete marcado con CS3 (011000) se verá como precedencia 3, que en las definiciones clásicas se correspondía con “Flash”. Esto permite que el tráfico de control de red, multicast crítico o determinados servicios de gestión sigan teniendo prioridad en infraestructuras mixtas.

La coexistencia de DSCP con MPLS también es habitual: en muchos diseños, las marcas DSCP en el borde se mapean a bits de EXP en la etiqueta MPLS para conservar la prioridad dentro del backbone del operador. Aunque ese detalle de MPLS no se explique en profundidad aquí, es un ejemplo más de cómo DSCP sirve como lenguaje común de prioridades entre dominios.

Solución de problemas y validación de marcado DSCP

Cuando la QoS “no va fina”, casi siempre toca revisar si el marcado DSCP se está aplicando y respetando correctamente. Para ello es muy útil capturar tráfico con herramientas como Wireshark y comprobar qué valores DSCP aparecen realmente en los paquetes en distintos puntos de la red.

Un fallo típico es que un router intermedio resetea el campo DSCP a 0 por configuración por defecto o por política mal aplicada, matando la QoS a partir de ese salto. Otro problema común es la inconsistencia de clases: por ejemplo, que en un firewall se marque VoIP como EF y en otro router se reclasifique a AF11, generando tratamientos contradictorios.

En entornos de laboratorio o pruebas, es bastante frecuente usar comandos extendidos de ping con ToS/DSCP en routers (como en Cisco) para generar paquetes con un codepoint concreto y verificar qué colas usan y cómo se comportan bajo carga. Esto ayuda a validar el diseño de colas y políticas de policer/shaper.

La monitorización continua de colas y clases de QoS en routers y switches es otra herramienta clave. Revisar métricas de drops por clase, ocupación de cola, retardos y uso de ancho de banda permite detectar rápidamente si alguna clase está infradimensionada o si el marcado no se corresponde con la realidad del tráfico.

Si se detectan problemas, suele ser necesario ajustar ACLs de clasificación, mapear correctamente DSCP a colas y revisar que todos los dispositivos compartan el mismo “diccionario” de clases. Un pequeño desajuste en un solo salto puede echar por tierra toda la QoS extremo a extremo.

DSCP en redes modernas, SD-WAN, 5G e IoT

Las redes actuales ya no son solo un LAN y un par de routers saliendo a Internet. Entre cloud, SD-WAN, 5G, WiFi avanzado e IoT, el escenario se ha vuelto bastante más complejo, y DSCP sigue siendo una pieza central para mantener la calidad de los servicios.

En soluciones SD-WAN, por ejemplo, es muy habitual utilizar los valores DSCP para decidir por qué enlace sale cada tipo de tráfico o qué prioridad tiene en túneles cifrados. El SD-WAN puede recalcular rutas en tiempo real según retardos, pérdida y jitter, pero se apoya en las marcas DSCP para saber qué flujos no se pueden permitir degradación.

En entornos 5G y edge computing, la promesa de latencias ultrabajas exige una priorización cuidadosa de los flujos críticos: control industrial, vehículos conectados, realidad aumentada, etc. DSCP es un mecanismo cómodo para indicar qué tráfico necesita un trato casi “VIP” en toda la cadena de red.

Con el auge del Internet de las Cosas (IoT), se genera un volumen enorme de datos, gran parte de ellos no críticos. DSCP permite diferenciar entre, por ejemplo, alarmas de seguridad o señales de control en tiempo real (que se marcan con alta prioridad) y tráfico de telemetría masiva o logs que pueden ir perfectamente en mejor esfuerzo o incluso en clases de bajo esfuerzo.

De cara al futuro, la IETF sigue trabajando en nuevos PHB y recomendaciones de uso de los codepoints DSCP, y no es descartable que veamos una integración todavía más estrecha con mecanismos de automatización y machine learning que ajusten dinámicamente las marcas en función del comportamiento real de la red.

DSCP se mantiene como el estándar de facto para marcar prioridades de tráfico IP gracias a su sencillez, compatibilidad y flexibilidad. Bien diseñado y aplicado con cabeza, permite que redes muy complejas gestionen de forma “injusta pero controlada” el tráfico, dando siempre preferencia a lo que realmente importa sin tener que sobredimensionar la infraestructura de forma desproporcionada.