El campo de tipo de servicio ( ToS ) es el segundo byte del encabezado IPv4 . Ha tenido varios 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. Con base en estos valores de 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 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 hacer uso de estos ocho bits, lo que ha dado como resultado la definición actual del campo DS .
La redefinición moderna del campo ToS, también utilizado para el campo Traffic Class en paquetes IPv6 , es un campo de servicios diferenciados de 8 bits (campo DS) que consta de un campo de punto de código de servicios diferenciados (DSCP) 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 retrocompatibles con los términos de servicio, ECN no lo es.
Historia
El campo Tipo de servicio en el encabezado IP se definió originalmente en RFC 791 y se ha interpretado para 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 EE. UU., Que define la precedencia de los mensajes. Se 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 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, solo la parte del campo Precedencia IP se usó fuera de las redes del Departamento de Defensa de EE. UU.: 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 existían ambas rutas. IPv6 nunca ha tenido un campo ToS "tradicional" similar a 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 denomina 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 IP. Desde RFC 3168, los dos bits restantes (los dos bits menos significativos) se utilizan para la notificación de congestión explícita.
RFC 8622 agregó DS de menor esfuerzo (LE) para el tráfico que puede ser sustituido por otro tráfico (tráfico de mejor esfuerzo). Está diseñado para tráfico de fondo de baja precedencia, como transferencias de datos masivas con baja prioridad en el tiempo.
Asignación
Precedencia y ToS
Antes de su desaprobación, el campo Tipo de servicio se definió de la siguiente manera en RFC 791:
7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
---|---|---|---|---|---|---|---|
Precedencia | Tipo de servicio | Sin usar (0) |
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:
7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
---|---|---|---|---|---|---|---|
(Prioridad de IP) | retraso bajo | rendimiento | fiabilidad | bajo costo (RFC 1349) | (Debe ser cero) |
El nombre aquí sigue la convención de los sistemas operativos Unix. [5] RFC 1349 y RFC 1060 solo 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 configurarse nominalmente. Uno de esos usos se conoce por mod_iptos. [6]
Debido a que los últimos tres bits pasaron por muchas definiciones antes de RFC 2474 (ver más abajo), la documentación y las implementaciones pueden ser confusas y contradictorias.
DSCP y ECN
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 de congestión explícita .
7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
---|---|---|---|---|---|---|---|
DSCP | ECN |
DSCP define un selector de clase (CS) para nombrar cada valor que define, reflejando lo que se habría interpretado como Precedencia IP si se sigue la especificación anterior:
Nombre DSCP | Valor del campo DS (dic) | Precedencia de IP (descripción) |
---|---|---|
CS0 | 0 | 0: Mejor esfuerzo |
LE | 1 | n / A |
CS1, AF11-13 | 8,10,12,14 | 1: prioridad |
CS2, AF21-23 | 16,18,20,22 | 2: Inmediato |
CS3, AF31-33 | 24,26,28,30 | 3: Flash: se utiliza principalmente para señalización de voz |
CS4, AF41-43 | 32,34,36,38 | 4: anulación de flash |
CS5, EF | 40,46 | 5: Crítico - utilizado principalmente para voz RTP |
CS6 | 48 | 6: Control entre redes |
CS7 | 56 | 7: Control de red |
Nomenclatura DSCP:
- CS
- Selector de clases (RFC 2474)
- AFxy
- Reenvío asegurado (x = clase, y = precedencia de eliminación) (RFC 2597)
- EF
- Reenvío acelerado (RFC 3246)
- LE
- Esfuerzo menor (RFC 8622)
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):
DSCP dic | Valor ToS | Prec IP |
---|---|---|
0 | 0 | 0 |
8 | 32 | 1 |
10 | 40 | 1 |
14 | 56 | 1 |
18 | 72 | 2 |
22 | 88 | 2 |
24 | 96 | 3 |
28 | 112 | 3 |
34 | 136 | 4 |
36 | 144 | 4 |
38 | 152 | 4 |
40 | 160 | 5 |
46 | 184 | 5 |
48 | 192 | 6 |
56 | 224 | 7 |
Nota: En la tabla anterior, ToS se muestra en formato decimal. Sin embargo, muchos enrutadores expresan ToS en formato hexadecimal.
Ejemplo: interpretación mixta
Comencemos con una prioridad de IP de 1 o 0b001
en binario. Todo el campo ToS sería entonces 001 00000
, asumiendo que los 5 bits no utilizados son cero. El DSCP se puede interpretar volviendo a segmentar a 001000 00
, donde 001000
= 8 es el valor de DSCP.
Soporte de software
Aunque no se utiliza con frecuencia, las definiciones IP ToS se encuentran ampliamente en la netinet/ip.h
de tipo Unix o Unix sistemas que operan como IPTOS_FIELDNAME
macros. [5] El campo "lowcost" está comentado en OpenBSD debido a su nuevo uso para indicar soporte ECN. [5] Los restos de la antigua terminología RFC 1349 se pueden encontrar en Transmission 2.93 [7] , así como otras herramientas que apoyan la configuración de este campo.
Un antiguo módulo de Apache "mod_iptos", una vez empaquetado en Ubuntu, señala que una forma de usar múltiples bits de opciones RFC 1349 juntos surgió después de algún momento. [6]
Ver también
Referencias
- ^ RFC 791, RFC 1122, RFC 1349, RFC 2474 y RFC 3168. Para obtener un historial completo del campo ToS, consulte la sección 22 de RFC 3168.
- ^ http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.qdisc.classless.html Control de tráfico y enrutamiento avanzado de Linux
- ^ RFC 3260 Sección 4
- ^ RFC 3168 Sección 5
- ^ a b c "openbsd / src: sys / netinet / ip.h" . GitHub . Consultado el 10 de octubre de 2018 .
- ^ a b Gaudet, decano. "mod_iptos.c (mod_iptos 1.0)" . Archivado desde el original el 10 de octubre de 2018 . Consultado el 10 de octubre de 2018 .
- ^ "transmisión 2.93: libtransmission / session.c" . GitHub . Consultado el 10 de octubre de 2018 .
Otras lecturas
- John Evans, Clarence Filsfils (2007). Implementación de QoS IP y MPLS para redes multiservicio: teoría y práctica . Morgan Kaufmann. ISBN 978-0123705495.