Servicios diferenciados
Servicios diferenciados o DiffServ es 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 puede, por ejemplo, usarse para proporcionar baja latencia al tráfico de red crítico, como voz o transmisión de medios, al mismo tiempo que brinda 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 de 6 bits (DSCP) en el campo de servicios diferenciados de 8 bits (DS campo) en el encabezado IP para fines de clasificación de paquetes. El campo DS reemplaza el campo TOS de IPv4 obsoleto.
Antecedentes
Las redes de datos modernas transportan muchos tipos diferentes de servicios, incluidos voz, video, transmisión de música, páginas web y correo electrónico. Muchos de los mecanismos QoS propuestos que permitieron la coexistencia de estos servicios eran complejos y no se escalaron para satisfacer las demandas de la Internet pública. En diciembre de 1998, el IETF publicó RFC 2474 - Definición del campo de servicios diferenciados (campo DS) en los encabezados de IPv4 e IPv6, que reemplazó a los TOS y de IPv4. Campos de precedencia de IP con el campo DS. En el campo DS, se utiliza un rango de ocho valores (selectores de clase) para la compatibilidad con versiones anteriores del campo de precedencia de IP anterior. En la actualidad, DiffServ ha suplantado en gran medida a TOS y otros mecanismos 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 granularidad gruesa, basado en clases para la gestión del tráfico. Por el contrario, IntServ es un mecanismo de grano fino, basado en el 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 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 una cantidad limitada de clases de tráfico. Luego, cada enrutador en 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 el enrutador central, la funcionalidad puede mantenerse simple. Los enrutadores centrales simplemente aplican el tratamiento PHB a los paquetes en función de sus marcas. El tratamiento de PHB se logra mediante enrutadores centrales que utilizan una combinación de política de programación y política de administración de colas.
Un grupo de enrutadores que implementan políticas comunes de DiffServ definidas administrativamente se denominan dominio de DiffServ.
Si bien DiffServ recomienda un conjunto estandarizado de clases de tráfico, la arquitectura de DiffServ no incorpora juicios 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 (discutidas a continuación) sirven para simplificar la interoperabilidad entre diferentes redes y diferentes proveedores. equipo.
Clasificación y marcado
El tráfico de red que ingresa a un dominio DiffServ está sujeto a clasificación y acondicionamiento. 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 condicionarse aún más al someter el tráfico a limitadores de velocidad, policías de tráfico o modeladores.
El comportamiento por salto está determinado por el campo DS en el encabezado IP. El campo DS contiene el valor DSCP de 6 bits. La notificación de congestión explícita (ECN) ocupa los 2 bits menos significativos del campo TOS de IPv4 y el campo de clase de tráfico (TC) de IPv6.
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 requieren, ciertas codificaciones. Esto le da al operador de red una gran flexibilidad para definir las clases de tráfico. En la práctica, sin embargo, la mayoría de las redes utilizan los siguientes comportamientos por salto comúnmente definidos:
- Default Forwarding (DF) PHB - que suele ser el tráfico de la mejor manera
- Avance expedido (EF) PHB - dedicado al tráfico de baja pérdida y baja latencia
- Assured Forwarding (AF) PHB — gives assurance of delivery under prescribed conditions
- Selector de clase PHBs - que mantienen compatibilidad atrasada con el campo de precedencia IP.
Reenvío predeterminado
Un PHB de reenvío predeterminado (DF) es el único comportamiento requerido. Esencialmente, cualquier tráfico que no cumpla con los requisitos de ninguna de las otras clases definidas utiliza DF. Por lo general, DF tiene características de reenvío de mejor esfuerzo. El DSCP recomendado para DF es 0.
Reenvío acelerado
El IETF define el comportamiento del reenvío acelerado (EF) en RFC 3246. El EF PHB tiene las características de baja demora, 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 la cola por encima de todas las demás clases de tráfico. Debido a que una sobrecarga de tráfico EF causará retrasos en la cola y afectará la fluctuación y las tolerancias de retraso dentro de la clase, el control de admisión, la vigilancia del tráfico y otros mecanismos pueden aplicarse al tráfico EF. El DSCP recomendado para EF es 101110B (46 o 2EH).
Admisión de voz
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 Voice Admit mediante un procedimiento de control de admisión de llamadas (CAC). El DSCP recomendado para la admisión de voz es 101100B (44 o 2CH).
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 garantizar la entrega siempre que el tráfico no supere una tarifa suscrita. El tráfico que excede la tasa de suscripción enfrenta una mayor probabilidad de caída si se produce una congestión.
El grupo de comportamiento de AF define cuatro clases de AF separadas con todo el tráfico dentro de una clase que tiene la misma prioridad. Dentro de cada clase, a los paquetes se les asigna una prioridad de descarte (alta, media o baja, donde una precedencia más alta significa más descarte). La combinación de clases y precedencia de eliminación produce doce codificaciones DSCP separadas desde AF11 hasta AF43 (ver tabla).
Clase 1 | Clase 2 | Clase 3 | Clase 4 | |
---|---|---|---|---|
Baja probabilidad de caída | AF11 (DSCP 10) 001010 | AF21 (DSCP 18) 010010 | AF31 (DSCP 26) 011010 | AF41 (DSCP 34) 100010 |
Probabilidad de gota de med | AF12 (DSCP 12) 001100 | AF22 (DSCP 20) 010100 | AF32 (DSCP 28) 011100 | AF42 (DSCP 36) 100100 |
Alta probabilidad de caída | AF13 (DSCP 14) 001110 | AF23 (DSCP 22) 010110 | AF33 (DSCP 30) 011110 | AF43 (DSCP 38) 100110 |
Se define cierta medida de prioridad y equidad proporcional entre el tráfico en 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 congestión dentro de una clase, los paquetes con mayor prioridad de descarte 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.
Selector de clase
Clase de servicio | DSCP Nombre | DSCP Valor | IP precedence | Ejemplo de aplicación |
---|---|---|---|---|
Estándar | CS0 (DF) | 0 | 0 (000) | |
Datos de baja prioridad | CS1 | 8 | 1 (001) | Transferencia de archivos (FTP, SMB) |
Operaciones de red, administración y gestión (OAM) | CS2 | 16 | 2 (010) | SNMP, SSH, Ping, Telnet, syslog |
Video de radio | CS3 | 24 | 3 (011) |
|
interactivo en tiempo real | CS4 | 32 | 4 (100) | Gaming, videoconferencias de baja prioridad |
Firma | CS5 | 40 | 5 (101) | Peer-to-peer (SIP, H.323, H.248), NTP |
Control de redes | CS6 | 48 | 6 (110) | Protocolos de rotación (OSPF, BGP, ISIS, RIP) |
Reservado para uso futuro | CS7 | 56 | 7 (111) |
DF= Reenvío predeterminado
Antes de DiffServ, las redes IPv4 podían usar el campo de precedencia IP en el byte TOS del encabezado IPv4 para marcar la prioridad del tráfico. El octeto TOS y la precedencia de IP no se usaban mucho. El IETF acordó reutilizar el octeto TOS como el campo DS para las redes DiffServ. Para mantener la compatibilidad con versiones anteriores de los dispositivos de red que aún utilizan el campo Precedence, DiffServ define el Class Selector PHB.
Los puntos de código del selector de clase tienen la forma binaria 'xxx000'. Los tres primeros 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 no compatible con DiffServ que usó 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 proporcionan recomendaciones específicas para el uso de puntos de código de selector de clase.
Directrices de configuración
RFC 4594 ofrece recomendaciones detalladas y específicas para el uso y la configuración de puntos de código.
Clase de servicio | DSCP Nombre | DSCP Valor | Condición en el borde DS | PHB | Queu | AQM |
---|---|---|---|---|---|---|
Control de redes | CS6 | 48 | Véase la sección 3.1 | RFC 2474 | Tasa | Sí. |
Telefonía | EF | 46 | Policía usando sr+bs | RFC 3246 | Prioridad | No |
Firma | CS5 | 40 | Policía usando sr+bs | RFC 2474 | Tasa | No |
Conferencias multimedia | AF41, AF42, AF43 | 34, 36, 38 | Usando dos tipos de marcador de tres colores (como RFC 2698) | RFC 2597 | Tasa | Sí por DSCP |
interactivo en tiempo real | CS4 | 32 | Policía usando sr+bs | RFC 2474 | Tasa | No |
Transmisión multimedia | AF31, AF32, AF33 | 26, 28, 30 | Usando dos tipos de marcador de tres colores (como RFC 2698) | RFC 2597 | Tasa | Sí por DSCP |
Video de radio | CS3 | 24 | Policía usando sr+bs | RFC 2474 | Tasa | No |
Datos de baja frecuencia | AF21, AF22, AF23 | 18, 20, 22 | Usando un marcador de tres colores (como RFC 2697) | RFC 2597 | Tasa | Sí por DSCP |
OAM | CS2 | 16 | Policía usando sr+bs | RFC 2474 | Tasa | Sí. |
Datos de alto rendimiento | AF11, AF12, AF13 | 10, 12, 14 | Usando dos tipos de marcador de tres colores (como RFC 2698) | RFC 2597 | Tasa | Sí por DSCP |
Estándar | DF | 0 | No aplicable | RFC 2474 | Tasa | Sí. |
Datos de baja prioridad | CS1 | 8 | No aplicable | RFC 3662 | Tasa | Sí. |
sr+bs = velocidad única con control de tamaño de ráfaga.
Consideraciones de diseño
Bajo DiffServ, todas las políticas y clasificaciones 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 los acuerdos. Es decir, a diferencia de IntServ, DiffServ no requiere configuración previa, reserva ni negociaciones de extremo a extremo que consumen 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 tanto, 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 Gold de un proveedor puede ser Bronze de otro. DiffServ o cualquier otra marca de QoS basada en IP no garantiza la calidad del servicio o un acuerdo de nivel de servicio (SLA) específico. Al marcar los paquetes, el remitente indica que desea que los paquetes 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 asegurarse de que sus políticas se encarguen de los paquetes de manera adecuada.
Corredora de ancho de banda
(feminine)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. Para lograr una asignación de recursos de extremo a extremo a través de dominios separados, el agente de ancho de banda que administra un dominio deberá comunicarse con sus pares adyacentes, lo que permite construir servicios de extremo a extremo a partir de acuerdos puramente bilaterales.
RFC de DiffServ
- RFC 2474 — Definición del campo de servicios diferenciados (campo SDS) en los encabezados IPv4 y IPv6.
- RFC 2475 — Una arquitectura para servicios diferenciados.
- RFC 2597 — Assured forwarding PHB group.
- RFC 2983 — Servicios y túneles diferenciados.
- RFC 3086 — Definición de servicios diferenciados por comportamientos y reglas de su especificación.
- RFC 3140 — Códigos de identificación de comportamiento por hop. (Obsoletos RFC 2836.)
- RFC 3246 — An accelerated forwarding PHB. (Obsoletos RFC 2598.)
- RFC 3247 — Información suplementaria para la nueva definición de la EF PHB (comportamiento expedido por adelantado).
- RFC 3260 — Nueva Terminología y Aclaraciones para Diffserv. (Actualizaciones RFC 2474, RFC 2475 y RFC 2597.)
- RFC 4594 — Directrices de configuración para las clases de servicio DiffServ.
- RFC 5865 — Un punto de código de servicios diferenciado (DSCP) para el tráfico generado por la capacidad. (Actualiza RFC 4542 y RFC 4594.)
- RFC 8622 — A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services. (Actualiza RFC 4594 y RFC 8325, obsoleta RFC 3662.)
RFC de gestión de DiffServ
- RFC 3289 — Base de información de gestión para la arquitectura de servicios diferenciados.
- RFC 3290 — Modelo de gestión informal para routers de servicios diferenciados.
- RFC 3317 — Calidad diferenciada de los servicios de la base de información sobre políticas de servicios.
Contenido relacionado
Refugio nuclear
Telecomunicaciones en Eritrea
Rompecabezas Bobble