Hispanopedia WikiEl 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 podía especificar la prioridad de un datagrama y solicitar una ruta para un servicio de baja latencia, alto rendimiento o alta fiabilidad. Según estos valores de ToS, un paquete se colocaba en una cola de salida priorizada [ 2 ] o tomaba una ruta con la latencia, el rendimiento o la fiabilidad adecuados. En la práctica, el campo ToS nunca se utilizó de forma generalizada fuera de las redes del Departamento de Defensa de EE . UU. Sin embargo, se ha dedicado mucho esfuerzo a la experimentación, la investigación y el despliegue para aprovechar 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 del campo Traffic Class en los paquetes IPv6 ) divide este byte en un campo Differentiated Services (DS) de 6 bits [ 3 ] y un campo Explicit Congestion Notification (ECN) de 2 bits . [ 4 ] Si bien Differentiated Services es parcialmente compatible con ToS, ECN no lo es.
Historia
El campo Tipo de Servicio en la cabecera IP se definió originalmente en la RFC 791 y desde entonces se ha interpretado para la Precedencia IP y ToS . La definición se derivó en gran medida de la Especificación JANAP-128 del Departamento de Defensa de EE. UU., que define la precedencia y la preempción multinivel de 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 fiabilidad o baja latencia, etc. En la actualización de la RFC 1349, se introduce el bit de Coste Monetario (este bit estaba marcado anteriormente como "Reservado para uso futuro"). La Sección 2.4 de la RFC 1583 (OSPFv2) introduce un método de enrutamiento que tiene en cuenta ToS.
En la práctica, fuera de las redes del Departamento de Defensa de EE. UU., solo se utilizaba la parte de Precedencia IP del campo: cuanto mayor era el valor del campo Precedencia IP, mayor era la prioridad del paquete IP. Algunas redes del Departamento de Defensa de EE. UU. sí utilizaban el bit de retardo para la selección de ruta entre rutas de cable submarino y rutas de comunicación por satélite (SATCOM) cuando ambas rutas estaban disponibles. IPv6 nunca ha tenido un campo ToS "tradicional" como el de IPv4, en parte porque los autores estaban al tanto de los esfuerzos de DiffServ durante su redacción (RFC 2460, Sección 7).
En la RFC 2474, se modificó la definición de 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 la RFC 3168, los dos bits restantes (los dos menos significativos) se utilizan para la notificación explícita de congestión.
El RFC 8622 añadió el protocolo DS de menor esfuerzo (LE) para el tráfico que puede ser interrumpido por otro tráfico (tráfico de mejor esfuerzo). Está diseñado para el tráfico en segundo plano de baja precedencia, como las transferencias masivas de datos con baja prioridad temporal.
Asignación
Precedencia y Términos de Servicio
Antes de su desuso, el campo Tipo de servicio se definía de la siguiente manera según la RFC 791:
La precedencia era un campo de 3 bits que consideraba los paquetes de alta prioridad más importantes que los demás. Si un enrutador estaba congestionado y necesitaba descartar algunos paquetes, descartaría primero los de menor prioridad. Aunque el campo de precedencia formaba parte de la versión 4 del protocolo IP, nunca se utilizó.
RFC 1349 introdujo un campo adicional de "bajo costo". Los cuatro bits ToS disponibles ahora son:
La nomenclatura 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 estar configuradas nominalmente. Se conoce un uso de este tipo en mod_iptos. [ 6 ]
Debido a que los últimos tres bits pasaron por muchas definiciones antes de la RFC 2474 (ver más abajo), la documentación y las implementaciones pueden resultar confusas y contradictorias.
DSCP y ECN
El 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 el RFC 3168 reservó los dos últimos bits para la Notificación Explícita de Congestión .
DSCP define una nomenclatura de selector de clase (CS) para cada valor que define, reflejando lo que se habría interpretado como la precedencia IP si se siguiera la especificación anterior:
Nomenclatura DSCP:
- CS
- Selector de clase (RFC 2474)
- AFxy
- Reenvío garantizado (x=clase, y=eliminar precedencia) (RFC 2597)
- EF
- Envío acelerado (RFC 3246)
- LE
- Menor esfuerzo (RFC 8622)
La tabla anterior, con los 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, ToS se muestra en formato decimal. Sin embargo, muchos enrutadores expresan ToS en formato hexadecimal.
Ejemplo: interpretación mixta
Comencemos con una precedencia 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 resegmentando a 001000 00, donde 001000= 8 es el valor DSCP, correspondiente a CS1.
Soporte de software
Aunque no se usan con frecuencia, las definiciones de IP ToS se encuentran ampliamente en netinet/ip.hsistemas operativos tipo Unix o UnixIPTOS_FIELDNAME como macros. [ 5 ] El campo "lowcost" está comentado en OpenBSD debido a su uso más reciente para indicar soporte ECN. [ 5 ] Restos de la antigua terminología RFC 1349 se pueden encontrar 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", que alguna vez se incluyó en Ubuntu , señala que en algún momento surgió una forma de usar múltiples bits de opción RFC 1349 juntos. [ 6 ]
Véase 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 Enrutamiento avanzado y control de tráfico en Linux
- ↑ RFC 3260 Sección 4
- ↑ RFC 3168 Sección 5
- ^ " openbsd/src:sys/netinet/ip.h " . GitHub . Consultado el 10 de octubre de 2018 .
- 1 2 Gaudet, Dean. "mod_iptos.c (mod_iptos 1.0)" . Consultado el 10 de octubre de 2018 .
{{cite web}}: CS1 maint: servicio de archivado obsoleto ( enlace ) - ↑ "transmission 2.93:libtransmission/session.c" . GitHub . Consultado el 10 de octubre de 2018 .
Lecturas adicionales
- 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.
Enlaces externos
- Enrutamiento avanzado y control de tráfico en Linux. Cómo configurar el byte ToS mediante IPChains.
- Cola de tráfico simple por valores ToS
- Terminología de Internet
