stringtranslate.com

Servicios diferenciados

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 las redes IP modernas . DiffServ se puede utilizar, por ejemplo, para proporcionar baja latencia al tráfico de red crítico, como voz o transmisión de medios , y al mismo tiempo proporcionar un servicio de máximo esfuerzo 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 ) del encabezado IP para fines de clasificación de paquetes. El campo DS, junto con el campo ECN, reemplaza al campo TOS de IPv4 obsoleto . [1]

Fondo

Las redes de datos modernas transportan muchos tipos diferentes de servicios, incluidos voz, video, música en streaming, páginas web y correo electrónico. Muchos de los mecanismos de calidad de servicio propuestos que permitían que estos servicios coexistieran eran complejos y no lograban escalarse para satisfacer las demandas de la Internet pública . En diciembre de 1998, el IETF reemplazó los campos de precedencia TOS e IP en el encabezado IPv4 con el campo DS , que luego se dividió para referirse solo a los 6 bits superiores con el campo ECN en los dos bits inferiores. [2] [3] En el encabezado IPv6, el campo DS es parte del campo de 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 lograr compatibilidad con versiones anteriores del antiguo campo de precedencia IP de IPv4 . Hoy, DiffServ ha reemplazado en gran medida a TOS y otros mecanismos de QoS de capa 3 , como los servicios integrados (IntServ), como la arquitectura principal que utilizan los enrutadores para proporcionar QoS.

Mecanismos de gestión del tráfico

DiffServ es un mecanismo de gestión de tráfico basado en clases y de grano grueso . Por el contrario, IntServ es un mecanismo de flujo y de grano fino . DiffServ se basa en un mecanismo para clasificar y marcar los 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 la red en función de los requisitos de un flujo individual, DiffServ funciona según el principio de clasificación del tráfico , colocando cada paquete de datos en una de las clases de tráfico de un número limitado. A continuación, cada enrutador de la red se configura para diferenciar el tráfico en función de 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 y el control de paquetes, en el borde de la red. Dado que no se requiere clasificación ni control en los enrutadores centrales, la funcionalidad allí puede mantenerse simple. Los enrutadores centrales simplemente aplican el tratamiento PHB a los paquetes en función de sus marcas. El tratamiento PHB se logra mediante 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 DiffServ no incorpora criterios predeterminados sobre qué tipos de tráfico deben recibir un tratamiento prioritario. DiffServ simplemente proporciona un marco que permite 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.

Clasificación y marcado

El tráfico de red que entra en 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 marcación de DiffServ en los paquetes recibidos o pueden optar por ignorar o anular esas marcas. Para un control estricto de 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 condicionarse aún más sometiendo el tráfico a limitadores de velocidad , controladores 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. Las RFC de DiffServ recomiendan, pero no exigen, determinadas 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 definidos comúnmente:

Reenvío predeterminado

El único comportamiento requerido es un PHB de reenvío predeterminado (DF). 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]

Reenvío acelerado

El IETF define el comportamiento del reenvío acelerado (EF) en RFC  3246. El PHB EF tiene las características de bajo retardo, baja pérdida y baja fluctuación. Estas características son adecuadas para voz, video y otros servicios en tiempo real. El tráfico EF a menudo recibe una prioridad estricta en colas por sobre todas las demás clases de tráfico. Debido a que una sobrecarga de tráfico EF causará demoras en colas y afectará las tolerancias de fluctuación y demora dentro de la clase, se pueden aplicar al tráfico EF mecanismos de control de admisión , vigilancia de tráfico y otros. El DSCP recomendado para EF es 101110 B (46 o 2E H ).

Admisión de voz

El IETF define el comportamiento de Voice Admit en RFC  5865. El PHB de Voice Admit tiene características idénticas al PHB de reenvío acelerado. Sin embargo, el tráfico de Voice Admit también es admitido por la red mediante un procedimiento de control de admisión de llamadas (CAC). El DSCP recomendado para la admisión de voz es 101100 B (44 o 2C H ).

Reenvío asegurado

El IETF define el comportamiento del reenvío asegurado (AF) en RFC  2597 y RFC  3260. El reenvío asegurado permite al operador proporcionar seguridad de entrega siempre que el tráfico no supere una determinada tasa suscrita. El tráfico que supera la tasa suscrita enfrenta una mayor probabilidad de ser descartado si se produce una congestión.

El grupo de comportamiento AF define cuatro clases AF independientes, en las que 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 descarte (alta, media o baja, donde una prioridad más alta significa más descartes). La combinación de clases y prioridad de descarte produce doce codificaciones DSCP independientes, desde AF11 hasta AF43 (consulte la tabla).

Se define cierta medida de prioridad y equidad proporcional entre el tráfico de diferentes clases. Si se produce una congestión entre clases, se da prioridad al tráfico de la clase superior. En lugar de utilizar una cola de prioridad estricta, es probable que se utilicen algoritmos de servicio de cola más equilibrados, como la cola justa o la cola justa ponderada . Si se produce una congestión dentro de una clase, los paquetes con mayor precedencia de descarte se descartan primero. Para evitar problemas asociados con el descarte de cola , a menudo se utilizan algoritmos de selección de descarte más sofisticados, como la detección temprana aleatoria .

Selector de clase

DF= Reenvío predeterminado

Antes de DiffServ, las redes IPv4 podían utilizar 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 de IP no se utilizaban ampliamente. El IETF acordó reutilizar el octeto TOS como el campo DS para las redes DiffServ, y luego lo dividió en el campo DS y el campo ECN. Para mantener la compatibilidad con versiones anteriores de los dispositivos de red que aún utilizan el campo de 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, y así sucesivamente. 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 puede entender la codificación como un punto de código del Selector de clase.

En el RFC 4594 se ofrecen recomendaciones específicas para el uso de puntos de código del selector de clase.

Pautas de configuración

El RFC  4594 ofrece recomendaciones detalladas y específicas para el uso y la 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.

Consideraciones de diseño

En DiffServ, todo el control y la clasificación se realizan 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 reserva, ni negociación de extremo a extremo que consume mucho tiempo para cada flujo.

Los detalles de cómo cada enrutador individual trata el campo DS son específicos de la configuración, por lo que es difícil predecir el comportamiento de extremo a extremo. 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 Gold de un proveedor puede ser el Bronze de otro. DiffServ o cualquier otro marcado QoS basado 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 desea que se traten 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 ocupen de los paquetes de manera adecuada.

Broker de ancho de banda

Un agente de ancho de banda en el marco de DiffServ es un agente que tiene algún 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 en dominios separados, el agente de ancho de banda que administra un dominio tendrá que comunicarse con sus pares adyacentes, lo que permite construir servicios de extremo a extremo a partir de acuerdos puramente bilaterales.

RFC de DiffServ

RFC de gestión de DiffServ

Véase también

Referencias

  1. ^ D. Grossman (abril de 2002). Nueva terminología y aclaraciones para DiffServ. doi : 10.17487/RFC3260 . RFC 3260. Informativo. Actualizaciones RFC 2474, 2475 y 2597.
  2. ^ abcd K. Nichols; S. Blake; F. Baker ; D. Black (diciembre de 1998). Definición del campo de servicios diferenciados (campo DS) en los encabezados de IPv4 e IPv6. Grupo de trabajo de redes. doi : 10.17487/RFC2474 . RFC 2474. Norma propuesta. Deja obsoletas las RFC 1455 y 1349. Actualizada por las RFC 3168, 3260 y 8436.
  3. ^ ab K. Ramakrishnan; S. Floyd; D. Black (septiembre de 2001). La incorporación de la notificación explícita de congestión (ECN) a IP. Grupo de trabajo de redes. doi : 10.17487/RFC3168 . RFC 3168. Norma propuesta. Deja obsoleta la RFC 2481. Actualiza las RFC 2474, 2401 y 793. Actualizada por las RFC 4301, 6040 y 8311.
  4. ^ Guía de configuración de conmutadores Ethernet S3700HI - QoS, Huawei , pág. 7 , recuperado el 7 de octubre de 2016. Un dominio DiffServ está compuesto por un grupo de nodos DiffServ interconectados que utilizan la misma política de servicio y PHB.
  5. ^ abc J. Babiarz; K. Chan; F. Baker (agosto de 2006). Pautas de configuración para clases de servicio DiffServ. Grupo de trabajo de redes. doi : 10.17487/RFC4594 . STD 67. RFC 4594. Informativo. Actualizado por RFC 5865 y 8622.
  6. ^ J. Heinanen; F. Baker ; W. Weiss; J. Wroclawski (junio de 1999). Grupo de reenvío asegurado PHB. Grupo de trabajo de redes. doi : 10.17487/RFC2597 . RFC 2597. Norma propuesta. Actualizada por RFC 3260.
  7. ^ G. Tsirtsis; G. Giaretta; H. Soliman; N. Montavont (enero de 2011). Selectores de tráfico para enlaces de flujo. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC6088 . ISSN  2070-1721. RFC 6088. Norma propuesta.
  8. ^ Worldwide. "Implementación de políticas de calidad de servicio con DSCP". Cisco . Consultado el 16 de octubre de 2010 .
  9. ^ Filtrado DSCP Archivado el 29 de julio de 2016 en Wayback Machine .
  10. ^ K. Nichols; V. Jacobson; L. Zhang (julio de 1999). Una arquitectura de servicios diferenciados de dos bits para Internet. IETF. doi : 10.17487/RFC2638 . RFC 2638.

Lectura adicional

Enlaces externos