El campo de tipo de servicio ( ToS ) es el segundo byte del encabezado de IPv4 . Ha tenido diversos propósitos a lo largo de los años y ha sido definido de diferentes maneras por cinco RFC . [1]
Antes de la redefinición, el campo ToS podía especificar la prioridad de un datagrama y solicitar una ruta para un servicio de baja latencia, alto rendimiento o alta confiabilidad. Según estos valores ToS, un paquete se colocaría en una cola de salida priorizada [2] o tomaría una ruta con la latencia, el rendimiento o la confiabilidad adecuados. En la práctica, el campo ToS nunca se utilizó ampliamente fuera de las redes del Departamento de Defensa de los EE. UU. Sin embargo, una gran cantidad de trabajo experimental, de investigación y de implementación se ha centrado en cómo hacer uso de estos ocho bits, lo que dio como resultado la definición actual del campo DS .
La redefinición moderna del campo ToS (así como el campo Clase de tráfico en paquetes IPv6 ) divide este byte en un campo de Servicios diferenciados (DS) de 6 bits [3] y un campo de Notificación explícita de congestión (ECN) de 2 bits . [4] Si bien los Servicios diferenciados son algo compatibles con versiones anteriores de ToS, el ECN no lo es.
El campo Tipo de servicio en el encabezado IP se definió originalmente en RFC 791 y se ha interpretado para la precedencia IP y ToS desde entonces. La definición se derivó en gran medida de una especificación JANAP-128 del Departamento de Defensa de los EE. UU., que define la precedencia de los mensajes. Definió un mecanismo para asignar una precedencia a cada paquete IP, así como un mecanismo para solicitar un tratamiento específico, como alto rendimiento, alta confiabilidad o baja latencia, etc. En la actualización de RFC 1349, se introduce el bit de costo monetario (este bit estaba marcado anteriormente como "Reservado para uso futuro"). La sección 2.4 de RFC 1583 (OSPFv2) introduce un método de enrutamiento que tiene en cuenta ToS.
En la práctica, sólo la parte de precedencia IP del campo se utilizó fuera de las redes del Departamento de Defensa de los EE. UU.: cuanto mayor sea el valor del campo de precedencia IP, mayor será la prioridad del paquete IP. Algunas redes del Departamento de Defensa de los EE. UU. utilizaron el bit de demora para la selección de ruta entre rutas de cable oceánico y rutas de comunicación por satélite (SATCOM) cuando existían ambas rutas. IPv6 nunca tuvo un campo ToS "tradicional" similar al de IPv4, en parte porque los autores estaban al tanto de los esfuerzos de DiffServ en su redacción (RFC 2460 Sección 7).
En la RFC 2474 se modificó la definición de todo este campo. Ahora se denomina campo "DS" (Differentiated Services, "DiffServ") y los 6 bits superiores contienen un valor denominado "DSCP" (Differentiated Services Code Point). Los 3 bits superiores de DS mantienen la compatibilidad con la precedencia de IP. Desde la RFC 3168, los dos bits restantes (los dos bits menos significativos) se utilizan para la notificación explícita de congestión.
RFC 8622 agregó el DS de menor esfuerzo (LE) para el tráfico que puede ser reemplazado por otro tráfico (tráfico de mejor esfuerzo). Está destinado al tráfico de fondo de baja precedencia, como transferencias de datos en masa con baja prioridad en el tiempo.
Antes de su desuso, el campo Tipo de servicio se definía de la siguiente manera en RFC 791:
La precedencia era un campo de 3 bits que trataba a los paquetes de alta prioridad como más importantes que otros paquetes. Si un enrutador está congestionado y necesita descartar algunos paquetes, descartará primero los paquetes que tengan la prioridad más baja. Aunque el campo de precedencia era parte de la versión 4 de IP, nunca se utilizó.
La RFC 1349 introdujo un campo adicional de "bajo costo". Los cuatro bits de ToS disponibles ahora son:
La denominación que se da aquí sigue la convención de los sistemas operativos Unix. [5] RFC 1349 y RFC 1060 sólo muestran ejemplos de un bit utilizado a la vez para los valores predeterminados de la aplicación, aunque RFC 791 menciona que, como máximo, dos de las tres indicaciones que tiene deben establecerse nominalmente. Uno de esos usos se conoce de mod_iptos. [6]
Debido a que los últimos tres bits pasaron por muchas definiciones antes del RFC 2474 (ver a continuación), la documentación y las implementaciones pueden ser confusas y contradictorias.
El RFC 2474 (publicado en diciembre de 1998) reservó los primeros seis bits del campo DS (o IPv4 ToS) para el Punto de código de servicios diferenciados (DSCP), y el RFC 3168 reservó los dos últimos bits para la notificación explícita de congestión .
DSCP define un Selector de Clase (CS) que nombra cada valor que define, reflejando lo que se habría interpretado como la Precedencia de IP si se sigue la especificación anterior:
Nomenclatura DSCP:
La tabla anterior, con valores individuales escritos para los valores de todo el campo ToS (que no debe confundirse con la parte de 5 bits poco utilizada):
Nota: En la tabla anterior, el ToS se muestra en formato decimal. Sin embargo, muchos enrutadores expresan el ToS en formato hexadecimal.
Comencemos con una precedencia de IP de 1 o 001en binario. El campo ToS completo sería entonces 001 00000, suponiendo que los 5 bits no utilizados son cero. El DSCP se puede interpretar mediante la resegmentación a 001000 00, donde 001000= 8 es el valor DSCP, correspondiente a CS1.
Aunque no se utilizan con frecuencia, las definiciones de IP ToS se encuentran ampliamente en netinet/ip.hsistemas operativos Unix o similares a UnixIPTOS_FIELDNAME como macros. [5] El campo "lowcost" está comentado en OpenBSD debido a su uso más reciente para indicar compatibilidad con ECN. [5] Se pueden encontrar restos de la antigua terminología RFC 1349 en Transmission 2.93 [7] así como en otras herramientas que admiten la configuración de este campo.
Un antiguo módulo de Apache "mod_iptos", alguna vez empaquetado en Ubuntu, señala que después de algún tiempo surgió una forma de usar juntos múltiples bits de opción RFC 1349. [6]