Resumen

  • RFC 3175 ocultó la señalización RSVP de extremo a extremo a los routers interiores de una región y reunió muchos flujos en reservas agregadas identificadas por DSCP. Reducía estado, no la obligación de demostrar la admisión individual.
  • El desagregador decidía el mapeo, devolvía DCLASS y cargaba el token bucket del flujo a la capacidad usada. El agregador clasificaba y marcaba paquetes. Cada acto tenía una autoridad y un comprobante distintos.
  • La capacidad se dimensionaba por bloques y podía basarse en predicciones. Además, un Path con RSVP-E2E-IGNORE podía perderse sin una alarma clara. Por eso una reserva grande nunca bastaba como prueba de servicio.

El precio de recordar cada conversación

Una reserva RSVP precisa requería mensajes, cálculo y memoria en todos los routers que la procesaban. Cuando los flujos eran pocos, el modelo era legible. Cuando crecían, el núcleo debía mantener un número de estados dictado por las sesiones de los extremos.

RFC 3175 trasladó esa carga. Si varias reservas compartían entrada y salida, podían viajar por una región dentro de una reserva mayor. El primer router procesador era el agregador; el último, el desagregador. Los equipos intermedios trataban una clase común sin conocer cada promesa que contenía.

La arquitectura no borró el extremo a extremo. Hizo que el núcleo compartido fuera más delgado y que los bordes custodiaran la relación entre petición individual y capacidad común. Ahí reside la diferencia entre comprimir estado y perder evidencia.

Ignorar un mensaje también era una acción de protocolo

El agregador cambiaba el número de protocolo de RSVP a RSVP-E2E-IGNORE, registrado por IANA como 134. Así, un router interior reenviaba el Path sin instalar estado por flujo. Al salir, el desagregador restauraba RSVP y continuaba el procesamiento normal.

El campo expresaba una ignorancia delimitada: estos nodos no deben intervenir; este borde sí. Si la ruta no encontraba un desagregador preparado, el mensaje alterado podía llegar hasta el destino y ser descartado por desconocido. No había necesariamente un fallo ruidoso dentro de la región.

Por tanto, ver que el paquete entró no probaba que saliera convertido. La ausencia de estado central era el objetivo, pero la ausencia de un acuse en el borde era una avería. La topología y el emparejamiento de ambos extremos formaban parte del contrato operativo.

DCLASS transportaba una decisión, no la completaba

Los DSCP identificaban clases cubiertas por reservas agregadas y los PHB definían el tratamiento por salto. La política podía separar Guaranteed Service y Controlled Load, o combinar varias peticiones según criterios del operador.

El desagregador decidía porque era el primero que veía el Resv del receptor y la información del servicio solicitado. Enviaba el DSCP escogido mediante DCLASS. El agregador guardaba la relación, retiraba el objeto del mensaje que seguía hacia el emisor y marcaba el tráfico coincidente.

Ese recorrido evita una autoridad imaginaria del bit. El DSCP no identifica por sí solo al usuario autorizado. DCLASS no demuestra que el clasificador reconociera el flujo correcto. El marcado no demuestra que todos los routers dispusieran de la cola deseada. El PHB no demuestra que el receptor obtuviera la calidad pedida.

La admisión seguía siendo individual

Cuando había capacidad, el desagregador sumaba el token bucket del Resv a su cuenta interna de uso y devolvía la reserva de extremo a extremo. Esa suma era indispensable aunque el núcleo ya sólo conociera el agregado.

Un bloque existente no admitía automáticamente la siguiente petición. Había que localizar la sesión adecuada, contar compromisos previos, aplicar política y verificar margen. Si sólo existía Path agregado había que crear Resv; si faltaba capacidad había que ampliarla o detener la promesa.

Así, el número de estados internos podía dejar de crecer con los flujos, pero la contabilidad de borde no. La escala procedía de concentrar responsabilidad, no de fingir que los miembros eran indistinguibles.

El bloque nunca coincidía exactamente con su contenido

Ajustar la reserva tras cada alta y baja habría devuelto la tormenta de señalización. RFC 3175 aceptó bloques superiores a la suma instantánea y cambios menos frecuentes. Mencionó ciclos horarios y tendencias recientes como entradas posibles para predecir necesidad.

Una ventana fina ahorraba capacidad pero producía más actualizaciones. Una ventana gruesa reducía cambios y aumentaba error, excedente y necesidad de recuperación. Era una política local, no una garantía matemática del estándar.

Por eso la cadena de evidencia debía conservar forecast, bloque configurado, uso contado, decisión de admisión, cola ejecutada y tráfico observado. Mezclarlos permitía vender margen ocioso como servicio ya entregado.

Menos objetos, mayor radio de impacto

La agregación reducía aislamiento. Las ráfagas podían interferirse. El documento citó resultados experimentales favorables para ciertas distribuciones de demora, pero no describió todos los equipos ni cualquier tráfico futuro. Una medición actual necesitaría topología, colas, cargas y metodología propias.

También concentraba el fallo. Perder el agregado dejaba numerosos flujos sin reserva; reservar demasiado podía negar recursos a terceros; clasificar mal concedía prioridad al tráfico equivocado. El objeto era más eficiente porque representaba más consecuencias.

La autenticación de RSVP tampoco resolvía esas consecuencias. Agregador y desagregador funcionaban como vecinos lógicos para la señalización oculta, mientras el agregado mantenía integridad salto a salto. Un digest válido autenticaba el mensaje dentro de ese alcance; no certificaba capacidad, política, marcado ni resultado.

Un registro de IANA no es un contador de despliegues

RFC 4804 llevó el patrón a túneles MPLS TE y DS-TE. RFC 4860 creó agregados genéricos para permitir varios agregados con el mismo origen, destino y PHB, algo que RFC 3175 no expresaba. RFC 5350 revisó las asignaciones Router Alert. IANA mantiene el protocolo 134 y los C-Types agregados.

Esos artefactos prueban que las extensiones fueron especificadas. No prueban que una red concreta las use o que una reserva produzca calidad. La historia de RFC 3175 es la de una economía disciplinada: el centro podía olvidar detalles sólo si los bordes preservaban la posibilidad de reconstruirlos.

Las ideas de Lu Heng sobre código en ejecución, especificación mínima y capas de realidad son una lente posterior y declarada. Ayudan a separar registro, configuración, acto operativo y resultado, sin atribuir esa formulación a los autores del RFC. El mínimo compartido puede ser pequeño; la responsabilidad no.

Fuentes y límites

La evidencia se congeló el 2 de octubre de 2026, zona Asia/Shanghai. Respalda el mecanismo, las asignaciones IANA y la evolución de las especificaciones. No demuestra implantación, adopción, ahorro medido, volumen, rendimiento, incidente, operador ni calidad de servicio entregada.