Servicios integrados

En redes informáticas , los servicios integrados o IntServ son una arquitectura que especifica los elementos para garantizar la calidad del 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 QoS de grano fino , que a menudo se contrasta con el sistema de control de grano grueso de DiffServ .

Bajo IntServ, cada enrutador del sistema implementa IntServ, y cada aplicación que requiere algún tipo de garantía de QoS debe realizar una reserva individual. Las especificaciones de flujo describen para qué sirve la reserva, mientras que RSVP es el mecanismo subyacente para señalizarla a través de la red.

Una especificación de flujo consta de dos partes:

• ¿Cómo es el tráfico? Esto se realiza en la sección de Especificación de Tráfico, también conocida como TSPEC.
• ¿Qué garantías necesita? Se realiza en la parte de Especificación de Solicitud de Servicio, también conocida como RSpec .

Las especificaciones de tipo de transacción (TSPEC) incluyen parámetros para el algoritmo de depósito de tokens . La idea es que existe un depósito de tokens que se llena gradualmente, llegando tokens a un ritmo constante. Cada paquete que se envía requiere un token, y si no hay tokens disponibles, no se puede enviar. Por lo tanto, la velocidad de llegada de los tokens determina la velocidad promedio del flujo de tráfico, mientras que la profundidad del depósito determina la frecuencia e intensidad permitidas del tráfico.

Las especificaciones de tipo de transacción (TSPEC) suelen indicar únicamente la tasa de tokens y la profundidad del bucket. Por ejemplo, un vídeo con una frecuencia de actualización de 75 fotogramas por segundo , donde cada fotograma requiere 10 paquetes, podría especificar una tasa de tokens de 750  Hz y una profundidad de bucket de tan solo 10. Esta profundidad sería suficiente para gestionar el flujo de datos que implica el envío de un fotograma completo de una sola vez. En cambio, una conversación requeriría una tasa de tokens menor, pero una profundidad de bucket mucho mayor. Esto se debe a que las conversaciones suelen tener pausas, por lo que pueden prescindir de tokens al no enviar los espacios entre palabras y frases. Sin embargo, esto implica que la profundidad del bucket debe incrementarse para compensar el tráfico más irregular.

Las RSpecs especifican los requisitos del flujo: puede ser el estándar de Internet "mejor esfuerzo", en cuyo caso no se necesita 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 retardo como la tasa de pérdida son bastante constantes en la tasa deseada. Es probable que esta configuración se utilice para aplicaciones de QoS flexible. La configuración "Garantizado" proporciona un servicio absolutamente limitado, donde se promete que el retardo nunca superará una cantidad deseada y que los paquetes nunca se perderán, siempre que el tráfico se mantenga dentro de las especificaciones.

El Protocolo de Reserva de Recursos (RSVP) se describe en el RFC 2205. Todas las máquinas de la red capaces de enviar datos QoS envían un mensaje PATH cada 30 segundos, que se propaga por la red. Quienes desean recibirlos envían un mensaje RESV (abreviatura de "Reserve") correspondiente, que rastrea la ruta hacia atrás hasta el remitente. El mensaje RESV contiene las especificaciones de flujo.

Los enrutadores entre el emisor y el receptor deben decidir si pueden gestionar la reserva solicitada y, en caso contrario, envían un mensaje de rechazo para informar al receptor. Si aceptan la reserva, deben gestionar el tráfico.

Los enrutadores almacenan la naturaleza del flujo y lo supervisan. Todo esto se realiza en estado blando , de modo que si no se detecta ninguna actividad durante un tiempo determinado, el lector agotará el tiempo de espera y se cancelará la reserva. Esto resuelve el problema si el emisor o el receptor fallan o se apagan incorrectamente sin cancelar previamente la reserva. Los enrutadores individuales pueden, a su discreción, supervisar el tráfico para comprobar que cumple con las especificaciones del flujo.

Para que IntServ funcione, todos los enrutadores a lo largo de la ruta de tráfico deben ser compatibles con él. Además, cada enrutador debe almacenar numerosos estados. Por lo tanto, IntServ funciona a pequeña escala, pero a medida que el sistema se expande a redes más grandes o a Internet , el seguimiento de todas las reservas se vuelve muy costoso en términos de recursos. ^{[ 1 ]}

Una forma de resolver el problema de escalabilidad es mediante un enfoque multinivel, 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 de flujos individuales de la red de borde se puedan satisfacer mejor. ^{[ 2 ]}

• RFC 1633 - Servicios integrados en la arquitectura de Internet: una visión general 
• RFC 2211 - Especificación del servicio de elementos de red de carga controlada 
• RFC 2212 - Especificación de la calidad de servicio garantizada 
• RFC 2215 - Parámetros generales de caracterización para elementos de redes de servicios integrados 
• RFC 2205 - Protocolo de reserva de recursos (RSVP) 
• Cisco.com , documento técnico de Cisco sobre IntServ y DiffServ.