Resumen

  • RFC 5127 permite que varias clases de servicio Diffserv compartan un tratamiento de reenvío cuando sus necesidades y perfiles son compatibles.
  • El tratamiento agregado puede conservar múltiples DSCP; no convierte las clases miembro en una sola identidad.
  • La calidad de extremo a extremo requerida por la aplicación debe seguir siendo soportada.
  • El agregado debe diseñarse para la exigencia más estricta de sus miembros, no para un promedio cómodo.
  • La identidad de la clase original debe sobrevivir porque cada dominio puede formar agregados distintos.
  • Mantener el DSCP y clasificar varios valores hacia una cola común es la opción recomendada; una marca local debe restaurarse al salir.
  • Cada clase necesita acondicionamiento, admisión o policing propios antes del control adicional sobre la suma.
  • La agrupación Real-Time presupone una cota predecible y exigible en el borde; la cola no genera esa cota.
  • El mapa de cuatro agregados es un ejemplo y no una arquitectura obligatoria, mínima o máxima.
  • Velocidad, utilización, profundidad de cola, programador, tamaños de paquetes y ráfagas determinan si la mezcla funciona.
  • En MPLS, el Traffic Class y el LSP transportan una codificación local, no una prueba de tratamiento ni de entrega.
  • La evidencia debe separar solicitud de clase, autorización, medición, admisión, instalación, comportamiento observado y resultado de la aplicación.

El supuesto escondido antes de la cola

Una interfaz de operación muestra una cola Real-Time en verde. Dentro aparecen llamadas de voz, señalización, videoconferencia y control interactivo. La cola está configurada con un comportamiento similar a EF. A primera vista, el operador parece haber construido la parte difícil.

RFC 5127 sitúa la parte difícil antes. El tráfico en tiempo real debe entrar bajo un modelo de admisión y quedar limitado por clase. Solo entonces puede suponerse una cota predecible sobre lo que llegará al tratamiento agregado. El programador protege la cola frente a tráfico elástico, pero no decide cuántas sesiones debieron ser admitidas.

Si el control del borde falta o quedó desincronizado, cada flujo puede ser correcto por separado y la suma puede ser imposible. La cola conserva su nombre, el DSCP conserva su valor y todos los paquetes pueden atravesar el clasificador. Ninguna de esas señales prueba que la premisa de carga siga siendo verdadera.

Por eso el registro operativo debe comenzar con la decisión de admisión: qué clase, qué envolvente, qué versión de política, qué medidor, qué duración y qué presupuesto agregado consumió. El contador de la cola llega demasiado tarde para reconstruir ese razonamiento.

Compartir tratamiento no fusiona contratos

El documento define un treatment aggregate como la unión de clases de servicio en un mismo tratamiento de reenvío. Puede contener distintos DSCP. Esto lo separa de un agregado organizado alrededor de un solo código y un solo PHB.

La diferencia evita un error de gobierno. La clase es la interfaz con el requisito de la aplicación; el agregado es una elección interna del segmento. Reducir el número de colas no reduce automáticamente el número de obligaciones.

RFC 5127 ordena que el agregado cumpla el requisito más estricto de sus miembros. Una videollamada con baja tolerancia a la pérdida no puede quedar protegida por la tolerancia media de un conjunto. El operador tampoco puede deducir el presupuesto a partir de la palabra “estricto”. Necesita demanda admitida, utilización, memoria, pesos, algoritmo y comportamiento bajo fallo.

Las clases deberían ser similares también en su forma de tráfico. Paquetes cortos y frecuentes, ráfagas grandes y flujos de tasa sostenida ocupan de modo distinto la misma cola. Una afinidad semántica no demuestra compatibilidad física.

El doble control detecta dos fallos

La RFC recomienda acondicionamiento o admisión por clase y permite policing adicional del agregado. El orden importa porque las capas encuentran fallos diferentes.

Supongamos que señalización usa más de su envolvente mientras la telefonía está casi inactiva. La suma no supera el techo común, así que un medidor agregado declara normalidad. El medidor por clase revela que una asignación se está apropiando del margen de otra.

Ahora supongamos lo contrario: todas las clases respetan su límite, pero sus máximos coinciden durante una conmutación por fallo. Cada recibo individual es válido. La suma rebasa la capacidad compartida. Aquí no existe un infractor individual; falló la hipótesis con la que se construyó el presupuesto agregado.

Los promedios históricos no resuelven por sí solos esa correlación. Un servicio punto a punto puede ser estable, mientras un entorno multipunto cambia sus emisores simultáneamente. La admisión debe conocer la distribución y el escenario, no solo el promedio mensual.

El DSCP debe sobrevivir al atajo

Cada dominio puede agregar de modo distinto. Para que esa libertad funcione, la clase original no debe desaparecer. RFC 5127 recomienda conservar los DSCP y usar clasificadores que envíen varios valores a una cola común.

Un dominio que requiera marcas internas puede reescribirlas, pero debe restaurar la indicación original al salir. La encapsulación es una forma posible de guardar ambos planos. No basta con saber que el túnel existe: hay que comprobar el valor antes, el valor local, la asociación conservada y el valor restaurado.

Una restauración defectuosa no siempre corta el tráfico. Puede degradarlo silenciosamente en el dominio siguiente. La aplicación observa más demora; el equipo de origen ve su DSCP correcto antes del túnel; el equipo receptor ve otro valor. Sin un registro de custodia, el punto de ruptura queda sin dueño.

La marca tampoco autentica el derecho al servicio. Un paquete puede presentar un código preferente sin pertenecer a una clase autorizada. El clasificador de ingreso y el contrato siguen siendo recibos independientes.

Cuatro agregados, muchas arquitecturas válidas

Network Control, Real-Time, Assured Elastic y Elastic forman el ejemplo central de RFC 5127. El texto rechaza convertirlo en un mínimo o máximo. Un dominio puede admitir menos o más tratamientos y puede no soportar todas las clases.

Network Control protege tráfico necesario para la supervivencia de la red, pero el control del cliente no es idéntico al control interno del proveedor. Real-Time depende de admisión. Assured Elastic conserva precedencias de descarte. Elastic puede favorecer Default/CS0 frente a CS1.

La figura de cuatro filas es útil para pensar; es peligrosa como casilla de conformidad. Contar cuatro colas no dice cuánto recurso tiene cada una, qué clases están presentes, cómo se aplican los límites ni qué sucede con una clase no soportada.

Una arquitectura más simple puede ser mejor si existe capacidad sobrada y medición. Una arquitectura con más colas puede ser peor si sus clasificadores, pesos o límites no reflejan el tráfico. La RFC deja la decisión local porque la topología y la economía local importan.

La ingeniería aparece en la mezcla

La seguridad de la agregación depende de velocidad de enlace, ocupación, profundidad de cola, comportamiento del scheduler, tamaños de paquetes y tasas. La regla de que enlaces más rápidos admiten más agregación incluye una condición: la utilización debe permanecer dentro de lo diseñado.

Durante una avería, el tráfico puede ser redirigido a un enlace que cumplía en régimen normal. La protección de ruta funciona y, aun así, el margen desaparece. La continuidad del encaminamiento no prueba continuidad de cada objetivo de servicio.

Una cola profunda reduce pérdidas de ráfaga pero aumenta la espera. Para tráfico en tiempo real, una entrega tardía puede carecer de valor. Una cola corta controla la espera a costa de pérdida visible. El scheduler decide qué precio paga cada mezcla.

Las pruebas deben cubrir carga normal, ráfagas correlacionadas, fallo de enlace, cambio de política y nueva composición de miembros. Medir solo en vacío valida el laboratorio, no el contrato operativo.

La frontera entre proveedores no transmite la arquitectura

RFC 5127 recomienda basar la relación interproveedor en clases de servicio. El proveedor A puede usar cuatro agregados y el B seis. Lo que cruza es la identidad de clase y el acuerdo, no el derecho a imponer una cola interna.

El receptor debe declarar qué clases reconoce, cómo las admite, cómo trata lo no soportado y qué medición ofrece. El emisor debe conservar su marca y su decisión de ingreso. Solo juntos pueden reconstruir la cadena.

Una misma marca observada en ambos bordes demuestra continuidad limitada del campo. No demuestra que los nodos intermedios tuvieran recursos, que el Traffic Class MPLS se mapeara correctamente o que la aplicación recibiera la experiencia esperada.

Esta separación permite competencia sin perder interoperabilidad. Un proveedor puede cambiar su implementación mientras respeta la interfaz y los resultados. El cliente puede exigir medidas en lugar de nombres comerciales.

MPLS codifica, pero no certifica

El apéndice usa E-LSP y el antiguo campo EXP para representar agregados. RFC 5462 renombró el campo como Traffic Class. Cada dominio mantiene control sobre su asignación.

En E-LSP, los bits ayudan a inferir el PHB Scheduling Class y la precedencia de descarte. En L-LSP, cada camino transporta una sola clase de scheduling. Ninguno de los dos modelos convierte el label o los bits en prueba de que la tabla está instalada o el scheduler actuó.

La cadena de evidencia es más larga: clasificación IP, mapeo a MPLS, selección de LSP, entrada instalada, cola, descarte o transmisión observada, restauración del significado y medida de extremo a extremo.

La posible inanición de CS1 en el ejemplo Elastic ilustra el límite. La política puede querer que el tráfico de baja prioridad ceda ante congestión. Aun así, “baja prioridad” no define cuántos paquetes sobrevivirán ni cuándo debe recuperarse.

Alcance de la evidencia

RFC Editor y Datatracker prueban que RFC 5127 es un documento Informational publicado en 2008. IANA prueba asignaciones. Los RFC relacionados definen arquitectura, PHB, marcadores, MPLS y extensiones posteriores.

No hay en el paquete un inventario de proveedores actuales, una configuración nombrada, una captura de tráfico, una avería o una medición de SLA. El artículo no atribuye cumplimiento ni fallo a un producto. Analiza el mecanismo y las pruebas necesarias para gobernarlo.

Fuentes