En redes informáticas , los servicios integrados o IntServ son una arquitectura que especifica los elementos necesarios para garantizar la calidad de servicio (QoS) en las redes. IntServ se puede utilizar, por ejemplo, para permitir que el vídeo y el sonido lleguen al receptor sin interrupciones.
IntServ especifica un sistema de calidad de servicio de grano fino , que a menudo se contrasta con el sistema de control de grano grueso de DiffServ .
En el marco de IntServ, cada enrutador del sistema implementa IntServ y cada aplicación que requiere algún tipo de garantía de calidad de servicio debe realizar una reserva individual. Las especificaciones de flujo describen para qué sirve la reserva, mientras que RSVP es el mecanismo subyacente para enviarla a través de la red.
Una especificación de flujo consta de dos partes:
Las TSPEC incluyen parámetros de algoritmo de depósito de tokens . La idea es que exista un depósito de tokens que se llena lentamente con tokens y que llegan a un ritmo constante. Cada paquete que se envía requiere un token y, si no hay tokens, no se puede enviar. Por lo tanto, la velocidad a la que llegan los tokens determina la velocidad promedio del flujo de tráfico, mientras que la profundidad del depósito determina qué tan "ráfaga" puede ser el tráfico.
Las TSPEC normalmente solo especifican la tasa de tokens y la profundidad del bucket. Por ejemplo, un video con una tasa de actualización de 75 cuadros por segundo, donde cada cuadro toma 10 paquetes, podría especificar una tasa de tokens de 750 Hz y una profundidad de bucket de solo 10. La profundidad del bucket sería suficiente para dar cabida a la "ráfaga" asociada con el envío de un cuadro completo de una sola vez. Por otro lado, una conversación necesitaría una tasa de tokens menor, pero una profundidad de bucket mucho mayor. Esto se debe a que a menudo hay pausas en las conversaciones, por lo que pueden arreglárselas con menos tokens al no enviar los espacios entre palabras y oraciones. Sin embargo, esto significa que la profundidad del bucket debe aumentarse para compensar el tráfico más explosivo.
Las RSPEC especifican qué requisitos existen para el flujo: puede ser el "mejor esfuerzo" normal de Internet, en cuyo caso no se necesita ninguna reserva. Es probable que esta configuración se utilice para páginas web, FTP y aplicaciones similares. La configuración "Carga controlada" refleja el rendimiento de una red con poca carga: puede haber fallos ocasionales cuando dos personas acceden al mismo recurso por casualidad, pero generalmente tanto el retraso como la tasa de caída son bastante constantes a la tasa deseada. Es probable que esta configuración la utilicen las aplicaciones de QoS blandas. La configuración "Garantizada" ofrece un servicio absolutamente limitado, en el que se promete que el retraso nunca superará una cantidad deseada y que los paquetes nunca se descartarán, siempre que el tráfico se mantenga dentro de las especificaciones.
El Protocolo de reserva de recursos (RSVP) se describe en RFC 2205. Todas las máquinas de la red capaces de enviar datos de QoS envían un mensaje PATH cada 30 segundos, que se propaga por las redes. Quienes desean escucharlos envían un mensaje RESV (abreviatura de "Reserve") correspondiente que luego rastrea la ruta hacia atrás hasta el remitente. El mensaje RESV contiene las especificaciones del flujo.
Los enrutadores entre el emisor y el receptor deben decidir si pueden admitir la reserva solicitada y, si no pueden, envían un mensaje de rechazo para informar al receptor. De lo contrario, una vez que aceptan la reserva, deben transportar el tráfico.
Los enrutadores almacenan la naturaleza del flujo y también lo controlan. Todo esto se hace en estado suave , por lo que si no se escucha nada durante un cierto período de tiempo, el lector se desconectará y se cancelará la reserva. Esto resuelve el problema si el remitente o el receptor fallan o se apagan incorrectamente sin cancelar primero la reserva. Los enrutadores individuales pueden, a su elección, controlar el tráfico para verificar que se ajuste a las especificaciones de flujo.
Para que IntServ funcione, todos los enrutadores a lo largo de la ruta de tráfico deben admitirlo. Además, se deben almacenar muchos estados en cada enrutador. Como resultado, IntServ funciona a pequeña escala, pero a medida que el sistema se amplía a redes más grandes o a Internet , se requiere mucho uso de recursos para realizar el seguimiento de todas las reservas. [1]
Una forma de resolver el problema de escalabilidad es mediante un enfoque de múltiples niveles, donde la reserva de recursos por microflujo (como la reserva de recursos para usuarios individuales) se realiza en la red de borde, mientras que en la red central los recursos se reservan solo para flujos agregados. Los enrutadores que se encuentran entre estos diferentes niveles deben ajustar la cantidad de ancho de banda agregado reservado de la red central para que las solicitudes de reserva para flujos individuales de la red de borde se puedan satisfacer mejor. [2]