Resumen

  • El antiguo TOS de IPv4 expresaba precedencia y preferencias sin garantizar recursos. DiffServ convirtió seis bits en un selector de comportamiento por salto y concentró la clasificación, medición y vigilancia en los límites administrativos.
  • AF y EF solo producen un servicio cuando existen colas, capacidad, perfiles y acuerdos compatibles. La red receptora puede conservar, traducir, rebajar o rechazar una marca externa.

El mismo número, dos redes distintas

Un paquete de audio sale de una oficina con el DSCP asociado a Expedited Forwarding. El primer router lo coloca en una cola atendida a una tasa configurada. Al cruzar hacia el proveedor, el número no cambia, pero sí cambia la autoridad. El nuevo router no encuentra en esos seis bits el contrato del cliente, la tasa permitida ni la prueba de que alguien pagó por el trato preferente.

La puerta de entrada debe reconstruir el contexto con sus propios clasificadores y reglas. Puede medir el flujo, mantener la marca, sustituirla, enviarla a Best Effort o descartar el exceso. DiffServ no consideró esa autonomía una anomalía: la hizo parte de su arquitectura.

El paquete transporta una afirmación compacta. No transporta el dominio que le dio validez.

TOS nació como orientación, no como reserva

En septiembre de 1981, RFC 791 asignó un octeto de IPv4 al Type of Service. Tres bits indicaban precedencia; otros expresaban preferencia por menos demora, más rendimiento o mayor fiabilidad. La abstracción permitía que una aplicación describiera lo que valoraba sin conocer la tecnología de cada red atravesada.

Sin embargo, la precedencia Network Control estaba pensada para el interior de una red. Su uso y su control quedaban a cargo de esa red. Si la distinción era valiosa, el operador tenía que restringir quién podía invocarla. Escribir un valor nunca fue equivalente a acreditar un derecho.

RFC 1349, publicado en 1992, reconoció el problema con mayor claridad. TOS era estrictamente orientativo y no servía para solicitar garantías. Muchas redes no tenían una ruta alternativa que ofrecer, y el campo tampoco permitía pedir una cantidad concreta de ancho de banda. Una preferencia podía guiar; no podía crear el recurso que faltaba.

Seis bits para el núcleo, decisiones ricas en el borde

La alternativa de mantener estado por flujo y por cliente en todos los routers del núcleo no escalaba con facilidad. En diciembre de 1998, RFC 2474 y RFC 2475 definieron Differentiated Services alrededor de agregados.

Los seis bits superiores del antiguo TOS de IPv4 y de Traffic Class en IPv6 formaron el campo DS. El valor DSCP selecciona en cada nodo un Per-Hop Behavior. Los dos bits inferiores terminaron asignados a ECN y no amplían la semántica de DiffServ.

El código y el comportamiento son objetos diferentes. Varios DSCP pueden seleccionar un mismo PHB; algunos valores pueden tener significado puramente local. El PHB describe un resultado observable en un nodo para un agregado: cómo se agenda la cola, cuánto búfer recibe o con qué regla se descarta. No describe por sí solo un producto de extremo a extremo.

La arquitectura trasladó al límite las operaciones costosas. Allí se puede clasificar usando varios campos, medir contra un perfil, marcar, volver a marcar, suavizar ráfagas o eliminar tráfico fuera de contrato. El interior recibe agregados ya condicionados y evita guardar un expediente por usuario.

Un dominio es también una frontera de confianza

RFC 2475 llamó DS domain al conjunto continuo de nodos que comparte política de provisión y definiciones de PHB. La continuidad administrativa es esencial: dentro del dominio, un código aceptado debe llevar a un trato suficientemente coherente. En la entrada, el operador decide cuáles marcas externas pasan a formar parte de ese contexto.

Por eso el campo pudo ser pequeño. La identidad del cliente, su perfil, los precios, los límites y la responsabilidad no se comprimieron. Permanecieron en bases de datos, clasificadores, configuraciones y acuerdos controlados por quienes aportaban la infraestructura.

La coordinación se hizo más ligera, no más soberana.

Assured Forwarding no fijó cuánta seguridad ofrecer

RFC 2597 organizó Assured Forwarding en cuatro clases y tres precedencias de descarte por clase. Durante congestión, dentro de la misma clase, una precedencia de descarte mayor implica más probabilidad de pérdida. La pertenencia a un mismo microflujo impide que esas diferencias reordenen los paquetes.

Los nombres AF parecen formar una escala universal, pero el RFC no asigna una proporción de ancho de banda o memoria a cada clase. La seguridad real depende de los recursos configurados, de la carga presente y del perfil aplicado en el borde. Un nodo conforme a DiffServ tampoco está obligado a implementar AF.

El ingreso puede moldear el flujo, cambiar su precedencia de descarte, moverlo de clase o eliminarlo. El código común ofrece una gramática. El operador sigue escribiendo la economía de esa gramática en sus colas.

Expedited Forwarding no salió del nodo

En 2002, RFC 3246 sustituyó la primera definición de EF. Un nodo que declara implementarlo debe atender ese agregado al menos a una tasa configurada y permitir que se caractericen demora y variación bajo condiciones acotadas.

La precisión viene acompañada de un límite: EF define un solo nodo. El comportamiento de una colección queda fuera, y ningún nodo tiene que implementar EF para ser compatible con DiffServ. Una ruta de baja latencia requiere capacidad y control de llegada en cada paso. Un router no puede prestar la cola del siguiente.

La etiqueta «expedited» nombra una propiedad verificable donde existe; no convierte una sucesión de administradores en una sola parte obligada.

Los acuerdos viven fuera del paquete

La arquitectura habló de SLA y Traffic Conditioning Agreement para unir perfiles y tratamiento. RFC 3260 aclaró después que un acuerdo abarca precio, disponibilidad y otras materias comerciales ajenas a DiffServ, y reservó SLS y TCS para los parámetros técnicos más estrechos.

Esa separación explica lo que una norma abierta sí podía hacer: definir el campo y el comportamiento de un nodo conforme. No podía comprar capacidad, aceptar clientes ni imponer las condiciones de interconexión entre dos empresas.

Una entrada puede cambiar o descartar un DSCP inaceptable. Si no existe acuerdo de servicio mejorado con el dominio de origen, puede restablecerlo a Default. Tras ese control, un valor sin mapa conocido debería recibir normalmente el comportamiento predeterminado, no privilegio por accidente.

Una marca sin firma se somete a vigilancia

El DSCP no autentica al emisor. Un sistema final puede marcar su propio tráfico y un atacante puede modificar una cabecera exterior no protegida. Los RFC describen el robo de servicio: cuando tráfico falso agota la reserva destinada a otros, el abuso se convierte en denegación de servicio.

La defensa comienza en el borde. El ingreso verifica que el código sea apropiado para el flujo y la política; el núcleo confía en esa limpieza. Al terminar un túnel surge otra entrada. La integridad criptográfica puede demostrar que una marca sobrevivió sin cambios, pero no que el nuevo operador aceptó honrarla.

La posibilidad de escribir un dato no otorga potestad sobre quien lo lee.

Ni siquiera la transición a Wi-Fi preserva el significado sola

RFC 7657 advirtió en 2015 que un extremo no puede saber qué PHB selecciona un Class Selector en una red específica, mucho menos a lo largo de toda la ruta. CS1 puede ser Lower Effort, Default, un trato superior, una marca nueva o un descarte según el dominio.

RFC 8325 mostró en 2018 que DSCP y User Priority de IEEE 802.11 son espacios distintos. El punto de acceso traduce entre ambos y, cuando falta un servicio equivalente, puede volver a Default. La interoperabilidad exige una decisión informada en la frontera; copiar bits no basta.

La capa común funcionó porque no absorbió toda la autoridad

DiffServ hizo posible una coordinación del trato sin prometer un gobierno global de colas. El IETF definió valores y comportamientos comprobables. Cada operador asignó recursos y controló admisión. Clientes y redes vecinas acordaron perfiles. Los dispositivos de frontera conectaron esas capas.

Los seis bits podían pedir. Solo la red que ejecutaba el código podía responder. La calidad de servicio siguió siendo creíble porque la cabecera nunca adquirió el poder de obligar al siguiente dominio.

Fuentes y límites

RFC 791 y RFC 1349 documentan TOS; RFC 2474 y RFC 2475, el campo DS y la arquitectura; RFC 2597 y RFC 3246, AF y EF; RFC 3260, RFC 7657 y RFC 8325, las aclaraciones y límites posteriores. Las normas no prueban configuraciones actuales, derechos de clientes, acuerdos privados, adopción ni rendimiento medido.