Los servicios diferenciados o DiffServ son una arquitectura de redes informáticas que especifica un mecanismo para clasificar y gestionar el tráfico de red y proporcionar calidad de servicio (QoS) en redes IP modernas . DiffServ se puede utilizar, por ejemplo, para proporcionar baja latencia al tráfico de red crítico, como voz o medios de transmisión , y al mismo tiempo brindar el mejor servicio a servicios no críticos, como tráfico web o transferencias de archivos .
DiffServ utiliza un punto de código de servicios diferenciados ( DSCP ) de 6 bits en el campo de servicios diferenciados de 6 bits ( campo DS ) en el encabezado IP para fines de clasificación de paquetes. El campo DS, junto con el campo ECN, reemplaza el campo TOS IPv4 obsoleto. [1]
Las redes de datos modernas ofrecen muchos tipos diferentes de servicios, incluidos voz, vídeo, música en streaming, páginas web y correo electrónico. Muchos de los mecanismos de QoS propuestos que permitieron que estos servicios coexistieran eran complejos y no lograron escalar para satisfacer las demandas de la Internet pública . En diciembre de 1998, el IETF reemplazó los campos de precedencia IP y TOS en el encabezado IPv4 con el campo DS , que luego se dividió para hacer referencia solo a los 6 bits superiores con el campo ECN en los dos bits inferiores. [2] [3] En el encabezado IPv6 el campo DS forma parte del campo Clase de Tráfico donde ocupa los 6 bits más significativos. [2]
En el campo DS, se utiliza un rango de ocho valores (selectores de clase) para compatibilidad con el antiguo campo de precedencia de IP IPv4 . Hoy en día, DiffServ ha suplantado en gran medida a TOS y otros mecanismos de QoS de capa 3 , como los servicios integrados (IntServ), como arquitectura principal que utilizan los enrutadores para proporcionar QoS.
DiffServ es un mecanismo de grano grueso basado en clases para la gestión del tráfico. Por el contrario, IntServ es un mecanismo detallado basado en flujo . DiffServ se basa en un mecanismo para clasificar y marcar paquetes como pertenecientes a una clase específica. Los enrutadores compatibles con DiffServ implementan comportamientos por salto (PHB), que definen las propiedades de reenvío de paquetes asociadas con una clase de tráfico. Se pueden definir diferentes PHB para ofrecer, por ejemplo, un servicio de baja pérdida o baja latencia .
En lugar de diferenciar el tráfico de red según los requisitos de un flujo individual, DiffServ opera según el principio de clasificación del tráfico , colocando cada paquete de datos en una de un número limitado de clases de tráfico. Luego, cada enrutador de la red se configura para diferenciar el tráfico según su clase. Cada clase de tráfico se puede gestionar de forma diferente, lo que garantiza un tratamiento preferencial para el tráfico de mayor prioridad en la red. La premisa de Diffserv es que los enrutadores de borde pueden llevar a cabo funciones complicadas como la clasificación de paquetes y la vigilancia en el borde de la red. Dado que no se requiere clasificación ni vigilancia en los enrutadores centrales, la funcionalidad se puede mantener simple. Los enrutadores centrales simplemente aplican el tratamiento PHB a los paquetes según sus marcas. El tratamiento PHB lo logran los enrutadores centrales utilizando una combinación de política de programación y política de gestión de colas.
Un grupo de enrutadores que implementan políticas DiffServ comunes definidas administrativamente se denomina dominio DiffServ . [4]
Si bien DiffServ recomienda un conjunto estandarizado de clases de tráfico, [5] la arquitectura de DiffServ no incorpora criterios predeterminados sobre qué tipos de tráfico deben recibir tratamiento prioritario. DiffServ simplemente proporciona un marco para permitir la clasificación y el tratamiento diferenciado. Las clases de tráfico estándar (que se analizan a continuación) sirven para simplificar la interoperabilidad entre diferentes redes y equipos de diferentes proveedores.
El tráfico de red que ingresa a un dominio DiffServ está sujeto a clasificación y condicionamiento. Un clasificador de tráfico puede inspeccionar muchos parámetros diferentes en los paquetes entrantes, como la dirección de origen, la dirección de destino o el tipo de tráfico, y asignar paquetes individuales a una clase de tráfico específica. Los clasificadores de tráfico pueden respetar cualquier marca DiffServ en los paquetes recibidos o pueden optar por ignorar o anular esas marcas. Para un control estricto sobre los volúmenes y el tipo de tráfico en una clase determinada, un operador de red puede optar por no respetar las marcas en el ingreso al dominio DiffServ. El tráfico en cada clase puede verse condicionado aún más sometiéndolo a limitadores de velocidad , policías de tráfico o modeladores . [6] : §3
El comportamiento por salto está determinado por los campos DS y ECN en el encabezado IP. El campo DS contiene el valor DSCP de 6 bits. [2] La notificación de congestión explícita (ECN) ocupa los 2 bits menos significativos del campo TOS de IPv4 y del campo de clase de tráfico (TC) de IPv6. [7] [8] [9]
En teoría, una red podría tener hasta 64 clases de tráfico diferentes utilizando los 64 valores DSCP disponibles. Los RFC de DiffServ recomiendan, pero no exigen, ciertas codificaciones. Esto proporciona al operador de red una gran flexibilidad a la hora de definir las clases de tráfico. Sin embargo, en la práctica, la mayoría de las redes utilizan los siguientes comportamientos por salto comúnmente definidos:
Un PHB de reenvío predeterminado (DF) es el único comportamiento requerido. Básicamente, cualquier tráfico que no cumpla con los requisitos de ninguna de las otras clases definidas utiliza DF. Normalmente, DF tiene características de reenvío de mejor esfuerzo. El DSCP recomendado para DF es 0. [5]
El IETF define el comportamiento de reenvío acelerado (EF) en RFC 3246. El EF PHB tiene las características de bajo retraso, baja pérdida y baja fluctuación. Estas características son adecuadas para voz, vídeo y otros servicios en tiempo real. Al tráfico EF a menudo se le da una prioridad estricta en las colas sobre todas las demás clases de tráfico. Debido a que una sobrecarga de tráfico EF provocará retrasos en las colas y afectará las tolerancias de fluctuación y retraso dentro de la clase, se pueden aplicar control de admisión , vigilancia de tráfico y otros mecanismos al tráfico EF. El DSCP recomendado para EF es 101110 B (46 o 2E H ).
El IETF define el comportamiento de admisión de voz en RFC 5865. El PHB de admisión de voz tiene características idénticas al PHB de reenvío acelerado. Sin embargo, la red también admite el tráfico de admisión de voz mediante un procedimiento de control de admisión de llamadas (CAC). El DSCP recomendado para admisión de voz es 101100 B (44 o 2C H ).
El IETF define el comportamiento de reenvío asegurado (AF) en RFC 2597 y RFC 3260. El reenvío asegurado permite al operador brindar seguridad de entrega siempre que el tráfico no exceda alguna tarifa suscrita. El tráfico que supera la tarifa de suscripción tiene una mayor probabilidad de perderse si se produce una congestión.
El grupo de comportamiento AF define cuatro clases AF separadas y todo el tráfico dentro de una clase tiene la misma prioridad. Dentro de cada clase, a los paquetes se les asigna una prioridad de eliminación (alta, media o baja, donde una mayor precedencia significa más eliminación). La combinación de clases y prioridad de eliminación produce doce codificaciones DSCP separadas desde AF11 hasta AF43 (consulte la tabla).
Se define alguna medida de prioridad y equidad proporcional entre el tráfico de diferentes clases. En caso de congestión entre clases, se dará prioridad al tráfico de la clase superior. En lugar de utilizar colas de prioridad estricta, es probable que se utilicen algoritmos de servicio de colas más equilibrados, como colas justas o colas justas ponderadas . Si se produce congestión dentro de una clase, los paquetes con mayor prioridad de eliminación se descartan primero. Para evitar problemas asociados con la caída de cola , a menudo se utilizan algoritmos de selección de caída más sofisticados, como la detección temprana aleatoria .
DF= Reenvío predeterminado
Antes de DiffServ, las redes IPv4 podían usar el campo de precedencia de IP en el byte TOS del encabezado IPv4 para marcar el tráfico prioritario. El octeto TOS y la precedencia IP no se utilizaron ampliamente. El IETF acordó reutilizar el octeto TOS como campo DS para redes DiffServ, dividiéndolo luego en el campo DS y el campo ECN. Para mantener la compatibilidad con dispositivos de red que aún usan el campo Precedencia, DiffServ define el Selector de clase PHB.
Los puntos de código del selector de clase tienen la forma binaria 'xxx000'. Los primeros tres bits son los bits de precedencia de IP. Cada valor de precedencia de IP se puede asignar a una clase DiffServ. La precedencia de IP 0 se asigna a CS0, la precedencia de IP 1 a CS1, etc. Si se recibe un paquete de un enrutador que no es compatible con DiffServ y que utilizó marcas de precedencia de IP, el enrutador DiffServ aún puede entender la codificación como un punto de código de selector de clase.
En RFC 4594 se dan recomendaciones específicas para el uso de puntos de código del selector de clase.
RFC 4594 ofrece recomendaciones detalladas y específicas para el uso y configuración de puntos de código. Otros RFC, como el RFC 8622, han actualizado estas recomendaciones.
sr+bs = velocidad única con control de tamaño de ráfaga.
Bajo DiffServ, toda la vigilancia y clasificación se realiza en los límites entre los dominios de DiffServ. Esto significa que en el núcleo de Internet, los enrutadores no se ven obstaculizados por las complejidades de cobrar pagos o hacer cumplir acuerdos. Es decir, a diferencia de IntServ , DiffServ no requiere configuración previa, ni reservas ni negociaciones de extremo a extremo que requieran mucho tiempo para cada flujo.
Los detalles de cómo los enrutadores individuales manejan el campo DS son específicos de la configuración, por lo que es difícil predecir el comportamiento de un extremo a otro. Esto se complica aún más si un paquete cruza dos o más dominios DiffServ antes de llegar a su destino. Desde un punto de vista comercial, esto significa que es imposible vender diferentes clases de conectividad de extremo a extremo a los usuarios finales, ya que el paquete Oro de un proveedor puede ser el paquete Bronce de otro. DiffServ o cualquier otra marca de QoS basada en IP no garantiza la calidad del servicio ni un acuerdo de nivel de servicio (SLA) específico. Al marcar los paquetes, el remitente indica que quiere que los paquetes sean tratados como un servicio específico, pero no hay garantía de que esto suceda. Depende de todos los proveedores de servicios y sus enrutadores en la ruta garantizar que sus políticas se ocuparán de los paquetes de manera adecuada.
Un corredor de ancho de banda en el marco de DiffServ es un agente que tiene cierto conocimiento de las prioridades y políticas de una organización y asigna ancho de banda con respecto a esas políticas. [10] Para lograr una asignación de recursos de extremo a extremo entre dominios separados, el corredor de ancho de banda que administra un dominio tendrá que comunicarse con sus pares adyacentes, lo que permite que los servicios de extremo a extremo se construyan a partir de conexiones puramente bilaterales. acuerdos.
Un dominio DiffServ se compone de un grupo de nodos DiffServ interconectados que utilizan la misma política de servicio y PHB.