El campo tipo de servicio ( ToS ) es el segundo byte del encabezado 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 podría especificar la prioridad de un datagrama y solicitar una ruta para un servicio de baja latencia, alto rendimiento o altamente confiable. Según estos valores ToS, un paquete se colocaría en una cola de salida priorizada [2] o tomaría una ruta con latencia, rendimiento o confiabilidad adecuados. En la práctica, el campo ToS nunca tuvo un uso generalizado fuera de las redes del Departamento de Defensa de EE. UU. Sin embargo, una gran cantidad de trabajo experimental, de investigación y de implementación se ha centrado en cómo utilizar estos ocho bits, lo que ha dado 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 de congestión explícita (ECN) de 2 bits . [4] Si bien los servicios diferenciados son algo compatibles con los ToS, ECN no lo es.
El campo Tipo de servicio en el encabezado IP se definió originalmente en RFC 791 y desde entonces se ha interpretado para la precedencia IP y los ToS . La definición se deriva en gran medida de la especificación JANAP-128 del Departamento de Defensa de EE. UU., que define la precedencia de los mensajes. Definía un mecanismo para asignar una prioridad 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 RFC 1349 se introduce el bit de Costo Monetario (este bit anteriormente estaba marcado como "Reservado para uso futuro"). La sección 2.4 de RFC 1583 (OSPFv2) presenta un método de enrutamiento compatible con ToS.
En la práctica, fuera de las redes del Departamento de Defensa de EE. UU., solo se utilizó la parte del campo Precedencia IP: cuanto mayor sea el valor del campo Precedencia IP, mayor será la prioridad del paquete IP. Algunas redes del Departamento de Defensa de EE. UU. utilizaron el bit de retardo para la selección de rutas entre rutas de cable oceánico y rutas de comunicación por satélite (SATCOM) cuando ambas rutas existían. IPv6 nunca ha tenido 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 RFC 2474 se cambió la definición de todo este campo. Ahora se llama campo "DS" (Servicios diferenciados, "DiffServ") y los 6 bits superiores contienen un valor llamado "DSCP" (Punto de código de servicios diferenciados). Los 3 bits superiores de DS mantienen la compatibilidad con la precedencia de IP. Desde 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ó 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 en segundo plano de baja prioridad, como transferencias masivas de datos con baja prioridad en el tiempo.
Antes de su desaprobación, el campo Tipo de servicio se definió de la siguiente manera en RFC 791:
La precedencia era un campo de 3 bits que trata 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 formaba parte de la versión 4 de IP, nunca se utilizó.
RFC 1349 introdujo un campo adicional de "bajo costo". Los cuatro bits ToS disponibles ahora se convierten en:
La denominación aquí sigue la convención de los sistemas operativos Unix. [5] RFC 1349 y RFC 1060 solo muestran ejemplos de un bit usado a la vez para valores predeterminados de la aplicación, aunque RFC 791 menciona que como máximo dos de las tres indicaciones que tiene deben configurarse nominalmente. Uno de esos usos se conoce por mod_iptos. [6]
Debido a que los últimos tres bits pasaron por muchas definiciones antes del RFC 2474 (ver más abajo), la documentación y las implementaciones pueden ser confusas y contradictorias.
RFC 2474 (que se publicó 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 RFC 3168 reservó los dos últimos bits para la notificación explícita de congestión .
DSCP define un nombre de selector de clase (CS) para 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, los ToS se muestran en formato decimal. Sin embargo, muchos enrutadores expresan los términos de servicio en formato hexadecimal.
Comencemos con una precedencia de IP de 1 o 001en binario. Entonces, todo el campo ToS sería 001 00000, suponiendo que los 5 bits no utilizados sean cero. El DSCP se puede interpretar resegmentando a 001000 00, donde 001000= 8 es el valor de DSCP, correspondiente a CS1.
Aunque no se utilizan con frecuencia, las definiciones de ToS de IP se encuentran ampliamente en netinet/ip.hsistemas operativos tipo Unix o Unix como IPTOS_FIELDNAMEmacros. [5] El campo "bajo costo" está comentado en OpenBSD debido a su uso más nuevo para indicar soporte ECN. [5] Se pueden encontrar restos de la antigua terminología RFC 1349 en Transmission 2.93 [7] , así como otras herramientas que admiten la configuración de este campo.
Un antiguo módulo de Apache "mod_iptos", una vez empaquetado en Ubuntu, señala que después de algún momento surgió una forma de usar múltiples bits de opción RFC 1349 juntos. [6]